EP2724304A1 - Verfahren und vorrichtung zum durchführen von bargeldlosen zahlungen - Google Patents

Verfahren und vorrichtung zum durchführen von bargeldlosen zahlungen

Info

Publication number
EP2724304A1
EP2724304A1 EP12732946.4A EP12732946A EP2724304A1 EP 2724304 A1 EP2724304 A1 EP 2724304A1 EP 12732946 A EP12732946 A EP 12732946A EP 2724304 A1 EP2724304 A1 EP 2724304A1
Authority
EP
European Patent Office
Prior art keywords
payment
subscriber identifier
code
mobile telecommunication
transaction code
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
EP12732946.4A
Other languages
English (en)
French (fr)
Inventor
Michael SUITNER
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.)
Secure Payment Technologies GmbH
Original Assignee
Secure Payment Technologies GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Secure Payment Technologies GmbH filed Critical Secure Payment Technologies GmbH
Publication of EP2724304A1 publication Critical patent/EP2724304A1/de
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/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; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/18—Payment architectures involving self-service terminals [SST], vending machines, kiosks or multimedia terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/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/327—Short range or proximity payments by means of M-devices
    • G06Q20/3274—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being displayed on the M-device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/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/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/383—Anonymous user system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes

Definitions

  • the invention relates to a method and a device for performing cashless payments by means of mobile telecommunication terminals.
  • Cashless payment is usually through credit institutions and involves payments in the form of book money between current accounts where no cash is moved.
  • the customer's account will be debited with the payment amount and the recipient will have a corresponding credit note in his account.
  • the credit institutions bring the service of the transfer and usually receive a fee credit ev. In the context of Konto Unitspauschalen.
  • the order to make a cashless payment may be made either by the payee or by the payer.
  • the payor makes a transfer, for example, by means of electronic banking.
  • the commissioning by the payee is usually done by direct debit due to a corresponding contractual relationship between payee and payer.
  • direct debit due to a corresponding contractual relationship between payee and payer.
  • the card payments generally use one of the above-mentioned basic payment methods. In most cases, the amounts are collected from the cardholder by means of guaranteed non-repayable direct debits and debited to his account.
  • the functions of the cards are mainly used for cash procurement and the credit card for short-term borrowing.
  • the payee is known, for example, the name of the cardholder, his card number and the PIN code.
  • additional data is added, such as the purchased item and the account number of the payer.
  • a conventional payment transaction with an electronic payment card usually proceeds as follows: 1) Amount is input
  • Card is requested and read out with the help of the card reader.
  • the security module is activated and requires the entry of the PIN.
  • the communication module establishes the connection to the provider and registers there for the data exchange.
  • Plausibility checks are carried out via the communication connection via data exchange.
  • An online connection with the bank checks whether a) there is no entry of the card used in the lock file; b) the entered PIN is correct; c) the payment amount is within the available financial envelope. The payment will be rejected if one of the conditions is not met.
  • the communication module logs off the provider and terminates the connection. Some terminals are always online.
  • the printer creates a protocol for payment or rejection.
  • the display shows the corresponding.
  • the result "payment made” guarantees the merchant his payment.
  • the present invention now aims to improve a method and a device of the type mentioned in that the effort for the authorization and the risk of data misuse are reduced.
  • the cashless payment should be made possible with the help of mobile telecommunication terminals in a simple manner, without having to accept losses in terms of the security of the payment process.
  • a method for performing cashless payments by means of mobile telecommunication terminals comprising the steps:
  • the authorization of the payment is thus exclusively in the payee's cash register system, eliminating the need for an online connection to a bank.
  • the payee has the payment limit of the data subject available to him without any querying or checking thereof required at the card issuing institution or at the bank.
  • a transaction code is used, which is generated before the execution of the payment process and has been transmitted to the mobile telecommunication terminal of the debtor.
  • the transaction code is subsequently validated using a check algorithm stored in the checkout system, the release of the payment being made only if the validity check has been completed positively.
  • To carry out the authentication of the debtor is thus only the cashier system stored test algorithm required, wherein the test algorithm to increase the safety at regular intervals can be renewed.
  • the identification of the payer takes place exclusively on the basis of the subscriber identifier transmitted during the payment process.
  • Person-specific data is not available to the payee as part of the payment process, so that the highest possible level of data protection can be achieved, in particular if the subscriber ID is neither the number of a credit, debit or cash card nor the number of a bank account. Furthermore, if the subscriber identifier is not related to a telephone number of the mobile telecommunication terminal, no assignment to a specific person can take place in this way.
  • the authorization or release of the payment according to the invention is carried out exclusively in the POS system and therefore no online connection to a bank or the like. Is required, a variety of payments can be collected in the POS system before the payments for the actual implementation of the transfer or for instigating the Direct debit be forwarded. Alternatively, it is also possible that the payments will be passed on without delay.
  • a preferred procedure provides that the ordering of the booking order comprises the following steps:
  • the payment processing center only has data records provided by the POS system which contain at least the subscriber identifier and the payment amount. As a rule, the data record also contains further data enabling the payment transaction, such as an identification of the payee and the like.
  • the data record is subsequently transmitted by the payment processing station either directly or indirectly to a banking network, where only then does the assignment of the subscriber identifier to an account number. This means that only with the bank the assignment of the payment to a certain person can take place.
  • the person-specific account number is a virtual account number
  • virtual account numbers and real account numbers are stored in the banking network assigned to each other and assigned as part of a debit order the virtual account number of the corresponding real account number.
  • the subscriber identifier is thus not translated directly into a real account number of the debtor, but a virtual account number is interposed, so that even in the possibly used interface between the banking network and the payment processing agency, the actual person-specific account number of the debtor is not available , Rather, the translation of the subscriber identifier into a virtual account number takes place in the said interface, so that even in the event that the payment processing agency would gain access to the data records of the interface in an inadmissible manner, no useable personal data could be obtained. Only after the forwarding of the payment data records to the bank is a translation of the virtual account number into the real account number made, so that an allocation of the payment to a certain person actually becomes possible in the bank itself.
  • the subscriber identifier In order to prevent unauthorized reading out of the data transmitted between the mobile telecommunication terminal and the POS system of the payee, it is preferred to proceed by coding the subscriber identifier, the transaction code and the payment limit in the mobile telecommunication terminal and transmitting this as a code to the payee's POS system with the code being decoded in the POS system.
  • the data transmission between the mobile telecommunication terminal and the POS system can be done using conventional data transmission standards for which the plurality of telecommunication terminals are equipped.
  • modern mobile phones have the option of a Bluetooth, WLAN or NFC connection.
  • this requires a corresponding retrofitting of existing cash register systems in order to achieve the respectively required hardware adaptation and to implement the respective transfer protocols by software technology.
  • the code is an opto-electronically readable code, in particular a bar code, which is displayed on a display unit of the mobile telecommunication terminal.
  • Such opto-electronically readable code in particular a bar code
  • the system according to the invention can also be used by means of NFC technology without further ado.
  • the verification of the validity of the data provided by the debtor is based in the context of the method according to the invention mainly on the transmitted transactions. on code.
  • the transaction code is in this case generated using an algorithm and is checked in the POS system using a test algorithm in terms of its validity.
  • a particularly preferred embodiment results here when the test algorithm and the algorithm used for the generation of the transaction code are matched to one another.
  • the checking algorithm and the algorithm used to generate the transaction code must be mathematically linked such that the checking algorithm only validates those transactions that were generated using the algorithm provided for generating the transaction code.
  • the algorithm used for generating the transaction code is stored in the payment processing station. The algorithm used to generate the transaction code is thus outside the influence of the debtor, making manipulation more difficult.
  • the transaction code is generated in the payment processing center.
  • the respective payment limit is made available by the payer with each payment transaction, so that the creditor's side accounts for the expense of the relevant verification.
  • the payment limit can be set by the debtor himself, which can be done for example by setting a corresponding default value in the mobile telecommunication terminal.
  • the setting of the payment limit can also be made separately for each payment.
  • the setting of the payment limit by the debtor has the disadvantage that the corresponding cover on the account is not guaranteed.
  • the payment limits are managed centrally.
  • the subscriber identifications are stored in the payment processing station and each subscriber identifier is assigned a respective payment limit, and the payment limit is transmitted from the payment processing center to the mobile telecommunication terminal. It is particularly preferred if the payment limit associated with a subscriber identifier in the payment processing station is matched with a stored payment limit associated with the respective subscriber identifier in a banking network.
  • the procedure according to the invention can be such that a payment limit changed after a matching process is transmitted to the mobile telecommunication terminal corresponding to the subscriber identifier together with a new transaction code.
  • a timestamp is transmitted from the mobile telecommunication terminal to the POS system, preferably in coded form, and the time stamp in the POS system is compared with the current time and releasing the payment in the POS system occurs if the difference between the current time and the timestamp does not exceed a defined value.
  • the functions required for carrying out the cashless payment procedure are designed such that they can be readily implemented on conventional mobile telephones.
  • a particularly convenient and user-friendly embodiment provides here that the process steps that can be carried out on the mobile telecommunication terminal are implemented in a program application loadable on the device.
  • Such a program application can simultaneously provide a correspondingly user-friendly and appealing user interface.
  • the function of coding the data to be transmitted can also be implemented in the program application, with a correspondingly large-area display element also allowing the display of a bar code which is preferably provided.
  • the subscriber identifier can further in simple Way the subscriber identifier be embedded, in which context it is preferably provided that the subscriber identifier is an application-specific identifier, which is generated for example by the banking network and stored in the Programmapplika- tion. To increase security, it may further be preferred that the application starts a PIN request before transmitting the subscriber identifier, the transaction code, the payment limit and possibly the time stamp from the mobile telecommunication terminal to the cash register system and the transfer takes place only if the PIN is entered correctly.
  • the process can be provided in detail, for example, as follows:
  • the application receives subscriber identification, transaction codes and payment limit at a time when the mobile phone is online - possibly long before the application is activated for payment.
  • the PIN is entered in the application, it is preferably again checked whether the code already held ready in the application still contains the correct payment limit, that is, a comparison is made with the payment limit stored in the payment processing point.
  • a device for making cashless payments by means of mobile telecommunication terminals comprising an electronic payment processing center and at least one electronic cash register system of a payee, wherein the payment processing center comprises at least one database, the subscriber identifiers of mobile telecommunication terminals and the subscriber identifications stored payment limits, a transcoding code generator that has one for the respective transaction code using an algorithm, and transmission means for transmitting the transaction code and the associated payment limit to the mobile telecommunication terminal, and wherein the POS system is adapted to in a cashless payment transaction from a mobile telecommunication terminal transmitted data, namely the subscriber identifier, receiving and checking the transaction code and the payment limit, the POS system having input means for entering a payment amount, the POS system further comprising processing means adapted to compare the transmitted payment limit with the desired payment amount and the validity of the payment Checking transaction codes using a check algorithm stored in the checkout system, the checkout system further having release means to release the payment if follow conditions are met: the desired
  • the invention will be explained in more detail with reference to an embodiment schematically illustrated in the drawing. 1 with a cash register system of a payee is referred to, which comprises at least one cash register 2, which is connected to a central cash register 3.
  • the cash register server 3 can be located locally at the location of the cash register 2. Particularly in the case of cash register systems with a multiplicity of spatially distributed cash registers 2, the cash register server 3 can also be arranged at a remote location.
  • the cash register server 3 is a conventional billing system, the data of which is handled by the individual cash registers 2 Payments are transmitted. Typically, the payment amount, an identification of the cash register 2 as well as the time of payment are transmitted for each payment.
  • the cash registers are suitable for both cash payments and electronic cashless payments.
  • the connections of the individual cash registers 2 to the checkout server 3 via conventional protocols, such as an XML web service.
  • the conventional POS server 3 is supplemented in the present embodiment by a program extension 4, which allows the implementation of the present invention.
  • a mobile telecommunication terminal of a user is designated 5. This is a conventional mobile phone, in particular smartphones are suitable. On the mobile telecommunication terminal 5, a program application 6 is installed, which allows the processing of the cashless payment method according to the invention.
  • the central settlement point is denoted by 7 and comprises a payment server 8 and a database 9.
  • the payment processing center 7 can set up a data connection both to the POS system 1 and to the mobile telecommunication terminal 5.
  • the payment processing point 7 is connected to an exchange server 10, which in turn communicates with a bank 11 or corresponding electronic banking networks.
  • the processing of a cashless payment according to the present invention from the point of view of a customer who wants to make a cashless payment is as follows. This assumes that the customer maintains an account with a bank. First, the bank customer must load the program application 6 on his mobile telecommunication terminal 5. Prefers > this is done so that the bank customer logs into the online banking area of his bank and connects the program application 6 with his bank account. Once the customer has loaded the program application 6 on his mobile telecommunication terminal 5 and installed there, the terminal 5 is ready for cashless payment transactions. Previously, a subscriber identifier generated by the bank 11 was stored in the program application 6.
  • the storage process can be carried out either due to a manual input of the subscriber identifier by the customer or may already have been stored on the bank side in the program application provided for downloading. It is essential that the subscriber identifier is a unique and unique identifier, so that it is subsequently possible to uniquely identify the subscriber based on the subscriber identifier.
  • the program application 6 is on the display unit of the mobile telecommunication terminal 5 is a disposable barcode that is read by a barcode reader of the cash register 2. The code transmitted in this way is checked for validity in the POS system 1. If the quality check has been completed successfully, the barcode will be accepted as payment and the payment amount will subsequently be withdrawn from the customer's bank account.
  • the bank 11 is connected to the payment processing center 7 via the exchange server 10. When a bank customer downloads the program application 6, this is reported by the bank 11 to the payment processing point 7. In this case, the bank 11 first transmits the subscriber identifier assigned to the bank customer together with an anonymous virtual account number to the exchange server 10. The virtual account number is not the real account number of that checking account. that the subscriber maintains at Bank 11. In the exchange server 10, the subscriber identifier and the subscriber identifier respectively associated virtual account number is stored. The payment processing center 7 receives in the sequence only the subscriber identification transmitted.
  • the payment processing point 7 does not have any real account data of the bank customer, so that the data available in the payment processing point 7 are basically anonymous, which means that the security standard in the payment processing point 7 and also in the POS system 1 can be chosen to be lower Any data theft does not bring any usable or personal data.
  • the further data exchange between the payment processing point 7 and the bank 11 takes place exclusively via the virtual account number, that is, by means of the exchange server 10.
  • the bank 11 sends the payment limit associated with the relevant account to the payment processing point 7. If the payment limit of a customer changes as a result, the bank 11 can at any time send a new payment limit to the payment processing point 7 via the interface server 10.
  • the payment processing center 7 has stored the subscriber identifier and the respective assigned payment limit in the database 9. This data is transmitted to the payment server 8, which comprises a transaction code generator with which unique transaction code can be created using an algorithm stored in the payment server 8. To prepare for a cashless payment transaction with the aid of the mobile telecommunication terminal 5, the payment server 8 creates a code which preferably contains the subscriber identifier, the payment limit and the automatically generated transaction code in encrypted form and transmits this code to the program application 6 of the mobile telecommunication terminal 5.
  • the data transmission can either on request of program application 6 or be caused by the payment server 8. It is essential here that the data transmission takes place only if it has previously been established that the program application 6 contains the subscriber identifier which corresponds to the subscriber identifier contained in the code to be transmitted.
  • the code obtained from the payment server 8 is supplemented by a time stamp.
  • the program application 6 creates in the sequence of the subscriber identifier, the payment limit, the transaction code and the time stamp a bar code, which is displayed on the display unit of the mobile telecommunication terminal 5.
  • the cash register 2 scans the displayed barcode with the aid of a barcode scanner and transmits it to the checkout server 3.
  • the program extension 4 implemented in the checkout server 3 decodes the transmitted code and can use a locally stored check algorithm to check whether the transmitted transaction code is valid. Furthermore, the transmitted timestamp determines whether the transmitted code is still valid. Furthermore, it is checked whether the desired payment amount, which was transmitted from the cash register 2 together with the code to the cash register system 3, is compatible with the likewise transmitted payment limit.
  • the checkout system 3 is connected to the payment server 8, whereby the check algorithm stored in the checkout system 3 can be changed at any time.
  • the checkout system 3 If the check of the code transmitted to the checkout system 3 has shown that the code is valid, the checkout system 3 notifies the cash register 2 that the payment can be accepted.
  • the cash register system 3 transmits the accepted code containing the subscriber identifier, the payment limit, the transaction code and the time stamp and additionally the payment amount and other payment-relevant data, such as an identification of the cash register and the merchant to the payment processing agency 7 and in particular to the database 9.
  • the payment processing center 7 transmits a data record containing the subscriber identifier, the payment amount and an identification of the merchant and possibly the time stamp, an invoice number and further payment-relevant data to the exchange server 10.
  • the exchange server 10 can assign the subscriber identifier to a virtual account number and send a debit order and the transaction details together with the virtual account number to the bank 11 or to a corresponding banking network.
  • the virtual account number is used to assign the customer's real account and the account is debited with the corresponding payment amount.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (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)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Bei einem Verfahren zum Durchführen von bargeldlosen Zahlungen, mit Hilfe von mobilen Telekommunikationsendgeräten (5), wobei jedes Telekommunikationsendgerät (5) eine Teilnehmerkennung und ein dieser Teilnehmerkennung zugeordnetes Zahlungslimit gespeichert hat, wird ein für den Zahlungsvorgang spezifischer Transaktionscode unter Verwendung eines Algorithmus generiert und an das mobile Telekommunikationsendgerät (5) übermittelt. Das Telekommunikationsendgerät (5) übermittelt die Teilnehmerkennung, den Transaktionscode und das Zahlungslimit an ein Kassensystem (1) eines bargeldlosen Zahlungsvorganges, wo das übermittelte Zahlungslimit mit dem gewünschten Zahlungsbetrag verglichen und die Gültigkeit des Transaktionscodes unter Verwendung eines im Kassensystem (1) gespeicherten Prüfalgorithmus überprüft wird. Bei positiver Prüfung erfolgt die Freigabe der Zahlung im Kassensystem (1).

Description

Verfahren und Vorrichtung zum Durchführen von bargeldlosen Zahlungen
Die Erfindung betrifft ein Verfahren sowie eine Vorrichtung zum Durchführen von bargeldlosen Zahlungen mit Hilfe von mobilen Telekommunikationsendgeräten.
Der bargeldlose Zahlungsverkehr erfolgt üblicherweise über Kreditinstitute und betrifft Zahlungen in der Form von Buchgeld zwischen Girokonten, bei denen kein Bargeld bewegt wird. Das Konto des Auftraggebers wird mit dem Zahlüngsbetrag belastet, der Empfänger enthält eine entsprechende Gutschrift auf seinem Konto. Die Kreditinstitute bringen die Dienstleitung des Transfers und erhalten meist eine Gebührengutschrift ev. im Rahmen von Kontoführungspauschalen.
Der Auftrag für die Durchführung einer bargeldlosen Zahlung kann entweder vom Zahlungsempfänger oder vom Zahlungspflichtigen erteilt werden. Bei einer Auftragserteilung durch den Zah- lungspflichtigen führt dieser eine Überweisung beispielsweise mittels Electronic Banking durch. Die Beauftragung durch den Zahlungsempfänger erfolgt meist im Wege des Lastschriftverfahrens aufgrund einer entsprechenden Vertragsbeziehung zwischen Zahlungsempfänger und Zahlungspflichtigem. Neben der klassi- sehen Überweisung und dem Lastschriftverfahren existiert eine Vielzahl von elektronisch basierten Zahlungsmöglichkeiten, wie beispielsweise die Geldkarten, Debitkarten und Kreditkarten. Die Kartenzahlungen bedienen sich in der Regel einer der oben genannten Grundzahlungsverfahren. Meist werden die Beträge per garantierter nichtrückgebbarer Lastschriften beim Karteninhaber eingezogen und seinem Konto belastet. Neben der Funktion der Karten als bargeldloses Zahlungsmittel dienen sie hauptsächlich der Bargeldbeschaffung und bei der Kreditkarte der kurzfristigen Kreditinanspruchnahme.
Obwohl die genannten elektronisch basierten Zahlungsmöglichkeiten den Vorteil einer schnellen und bequemen Zahlung sowie eine hohe Sicherheit aufgrund der geringen Bargeldhaltung mit sich bringen, gibt es eine Reihe von Nachteilen. Beispielsweise ist der Aufwand für die meist erforderliche Onlineautorisierung der verwendeten Karte im Zuge des Zahlungsvorganges mit einem hohen Aufwand verbunden. Die Onlineautorisierung erfordert eine direkte Datenverbindung des Kassensystems des Zahlungsempfängers mit der Rechenzentrale des kartenausgebenden Instituts bzw. der Bank. Die Onlineautorisierung verzögert den Zahlungsvorgang und verursacht Datenübertragungskosten. Der Zahlungsvorgang wird zudem durch zusätzliche Kontrollen wie beispielsweise eine PIN- Eingabe noch weiter verzögert, sodass die Kundenfreundlichkeit sowie die Effizienz gering sind. Nachteilig bei den herkömmlichen Zahlungsverfahren ist weiters, dass eine Reihe von persönlichen Daten des Zahlungspflichtigen bekannt gegeben werden, sodass die Gefahr eines Missbrauchs besteht. Bei herkömmlichen elektronisch basierten Zahlungsmöglichkeiten ist dem Zahlungsempfänger beispielsweise der Name des Karteninhabers, dessen Kartennummer sowie der PIN-Code bekannt. Im Zuge der Durchführung einer Transaktion kommen noch weitere Daten hinzu, wie beispielsweise der gekaufte Artikel sowie die Kontonummer des Zahlungspflichtigen. Gemeinsam mit den zuvor genannten personenbezogenen Daten ist somit eine eindeutige Zuordenbarkeit verschiedener sicherheitsrelevanter und vertraulicher Daten zu einzelnen Personen gegeben, sodass das Risiko eines Missbrauchs der Daten groß ist.
Ein herkömmlicher Zahlungsvorgang mit einer elektronischen Zahlkarte läuft üblicherweise wie folgt ab: 1) Betrag wird eingegeben
2) Karte wird verlangt und mit Hilfe des Kartenlesers ausgelesen. Das Sicherheitsmodul wird aktiviert und verlangt die Eingabe der Geheimzahl.
3 ) Das Kommunikationsmodul baut die Verbindung zum Provider auf und meldet sich dort für den Datenaustausch an.
4 ) Per Datenaustausch werden über die Kommunikationsverbindung die Plausibilitätsprüfungen durchgeführt. Per Onlineverbindung mit der Bank wird überprüft, ob a) kein Eintrag der verwendeten Karte in der Sperrdatei vorliegt; b) die eingegebene Geheimzahl korrekt ist; c) der Zahlbetrag innerhalb des verfügbaren Finanzrahmens liegt. Die Zahlung wird abgelehnt falls eine der Bedingungen nicht erfüllt ist.
Das Kommunikationsmodul meldet sich beim Provider ab und beendet die Verbindung. Manche Terminals bleiben immer online .
Der Drucker erstellt ein Protokoll über Zahlung bzw. Abweisung. Das Display zeigt Entsprechendes an.
Das Ergebnis "Zahlung erfolgt" garantiert dem Händler seine Zahlung. Die vorliegende Erfindung zielt nun darauf ab, ein Verfahren sowie eine Vorrichtung der eingangs genannten Art dahingehend zu verbessern, dass der Aufwand für die Autorisierung und das Risiko für einen Datenmissbrauch verringert werden. Die bargeldlose Zahlung soll mit Hilfe von mobilen Telekommunikations- endgeräten in einfacher Weise ermöglicht werden, ohne dass Einbußen in Bezug auf die Sicherheit des Zahlungsvorganges hingenommen werden müssen.
Zur Lösung dieser Aufgabe ist gemäß einem ersten Aspekt der Erfindung ein Verfahren zum Durchführen von bargeldlosen Zahlungen mit Hilfe von mobilen Telekommunikationsendgeräten vorgesehen, wobei jedes Telekommunikationsendgerät eine Teilnehmerkennung und ein dieser Teilnehmerkennung zugeordnetes Zahlungslimit gespeichert hat, umfassend die Schritte:
- Generieren eines für den Zahlungsvorgang spezifischen Transaktionscodes unter Verwendung eines Algorithmus,
Übermitteln des Transaktionscodes an das mobile Telekommunikationsendgerät ,
Übermitteln der Teilnehmerkennung, des Transaktionscodes und des Zahlungslimits vom mobilen Telekommunikationsendgerät an ein Kassensystem des Zahlungsempfängers im Rahmen eines bargeldlosen Zahlungsvorganges, Vergleichen des übermittelten Zahlungslimits mit dem gewünschten Zahlungsbetrag im Kassensystem,
Überprüfen der Gültigkeit des Transaktionscodes im Kassensystem unter Verwendung eines im Kassensystem gespeicherten Prüfalgorithmus ,
Freigeben der Zahlung im Kassensystem wenn folgende Bedingungen erfüllt sind: der gewünschte Zahlungsbetrag liegt innerhalb des Zahlungslimits und der Transaktionscode ist gültig,
Speichern der freigegebenen Zahlung im Kassensystem für eine spätere oder sofortige Weitergabe an eine Zahlungsab- wicklungsstelle zur Veranlassung eines Abbuchungsauftrages . Im Rahmen der. Erfindung erfolgt die Autorisierung der Zahlung somit ausschließlich im Kassensystem des Zahlungsempfängers, sodass die Notwendigkeit einer Onlineverbindung zu einer Bank entfällt. Dadurch, dass der Zahlungspflichtige im Rahmen des bargeldlosen Zahlungsvorganges nicht nur seine Teilnehmerken- nung, sondern auch das der Teilnehmerkennung zugeordnete Zahlungslimit an das Kassensystem des Zahlungsempfängers übermittelt, steht dem Zahlungsempfänger das Zahlungslimit der betroffenen Person zur Verfügung, ohne dass eine diesbezügliche Rückfrage bzw. Kontrolle bei dem kartenausgebenden Institut bzw. bei der Bank erforderlich ist.
Zur Authentifizierung des mobilen Telekommunikationsendgeräts des Zahlungspflichtigen wird ein Transaktionscode herangezogen, der vor der Durchführung des Zahlungsvorganges generiert wird und an das mobile Telekommunikationsendgerät des Zahlungspflichtigen übermittelt wurde. Im Kassensystem des Zahlungsempfängers wird der Transaktionscode in der Folge unter Verwendung eines im Kassensystem gespeicherten Prüfalgorithmus einer Gültigkeitsprüfung unterzogen, wobei die Freigabe der Zahlung nur dann erfolgt, wenn die Gültigkeitsüberprüfung positiv abgeschlossen wurde. Zur Durchführung der Authentifizierung des Zahlungspflichtigen ist somit lediglich der im Kassensystem gespeicherte Prüfalgorithmus erforderlich, wobei der Prüfalgorithmus zur Erhöhung der Sicherheit in regelmäßigen Abständen auch erneuert werden kann. Die Identifizierung des Zahlungspflichtigen erfolgt ausschließlich aufgrund der im Rahmen des Zahlungsvorganges übermittelten Teilnehmerkennung. Personenspezifische Daten stehen dem Zahlungsempfänger im Rahmen des Zahlungsvorganges nicht zur Verfügung, sodass ein höchstmöglicher Datenschutz erreicht werden kann und zwar insbesondere, wenn die Teilnehmerkennung weder die Nummer einer Kredit-, Debit- oder Geldkarte noch die Nummer eines Bankkontos ist. Wenn weiters die Teilnehmerkennung in keinem Bezug zu einer Rufnummer des mobilen Telekommunikationsendgeräts steht, kann auch auf diesem Weg keine Zuordnung zu einer bestimmten Person erfolgen.
Da die Autorisierung bzw. Freigabe der Zahlung erfindungsgemäß ausschließlich im Kassensystem erfolgt und hierfür somit keine Onlineverbindung zu einer Bank oder dgl. erforderlich ist, kann eine Vielzahl von Zahlungen im Kassensystem gesammelt werden, bevor die Zahlungen zur tatsächlichen Durchführung der Überweisung bzw. zur Veranlassung der Lastschrift weitergegeben werden. Alternativ ist aber auch möglich, dass die Zahlungen unverzüglich weitergegeben werden. Eine bevorzugte Verfahrenswei- se sieht in diesem Zusammenhang vor, dass die Veranlassung des Buchungsauftrages folgende Schritte umfasst:
Übermitteln eines Datensatzes vom Kassensystem an eine Zahlungsabwicklungsstelle, wobei der Datensatz zumindest die Teilnehmerkennung und den Zahlungsbetrag enthält, und - Übermitteln der Teilnehmerkennung von der Zahlungsabwicklungsstelle an ein Bankennetzwerk im Rahmen eines Abbuchungsauftrages, wobei im Bankennetzwerk oder in einer Schnittstelle zwischen dem Bankennetzwerk und der Zahlungsabwicklungsstelle personenspezifische Kontonummern und Teilnehmerkennungen einander zugeordnet gespeichert sind und die von der Zahlungsabwicklungsstelle übermittelte Teilnehmerkennung der entsprechenden Kontonummer zuge- ordnet wird und eine Abbuchung von einem Konto unter Verwendung der Kontonummer vorgenommen wird.
Wesentlich ist hierbei, dass auch die Zahlungsabwicklungsstelle im Sinne des Datenschutzes über keine personenbezogenen Daten verfügt. Die Zahlungsabwicklungsstelle verfügt lediglich über vom Kassensystem zur Verfügung gestellte Datensätze, die zumindest die Teilnehmerkennung und den Zahlungsbetrag enthalten. Der Datensatz enthält in der Regel auch weitere den Zahlungs- organg ermöglichende Daten, wie beispielsweise eine Identifizierung des Zahlungsempfängers und dgl. Der Datensatz wird in der Folge von der Zahlungsabwicklungsstelle entweder direkt oder indirekt an ein Bankennetzwerk übermittelt, wobei erst dort die Zuordnung der Teilnehmerkennung zu einer Kontonummer erfolgt. Dies bedeutet, dass erst bei der Bank die Zuordnung der Zahlung zu einer bestimmten Person erfolgen kann. Zur weiteren Erhöhung der Sicherheit ist bevorzugt vorgesehen, dass die personenspezifische Kontonummer eine virtuelle Kontonummer ist, wobei virtuelle Kontonummern und reale Kontonummern im Bankennetzwerk einander zugeordnet gespeichert sind und im Rahmen eines Abbuchungsauftrages die virtuelle Kontonummer der entsprechenden realen Kontonummer zugeordnet wird. Die Teilnehmerkennung wird somit nicht unmittelbar in eine reale Kontonummer des Zahlungspflichtigen übersetzt, sondern es ist eine vir- tuelle Kontonummer zwischengeschaltet, sodass auch in der ggf. zum Einsatz gelangenden Schnittstelle zwischen dem Bankennetzwerk und der Zahlungsabwicklungsstelle die tatsächliche personenspezifische Kontonummer des Zahlungspflichtigen nicht zur Verfügung steht. Vielmehr erfolgt in der genannten Schnittstel- le die Übersetzung der Teilnehmerkennung in eine virtuelle Kontonummer, sodass auch für den Fall, dass die Zahlungsabwicklungsstelle sich in unzulässiger Weise einen Zugang zu den Datensätzen der Schnittstelle verschaffen würde, keine verwertbaren personenspezifischen Daten gewonnen werden könnten. Erst nach der Weiterübermittlung der Zahlungsdatensätze an die Bank wird eine Übersetzung der virtuellen Kontonummer in die reale Kontonummer vorgenommen, sodass eine Zuordnung der Zahlung zu einer bestimmten Person tatsächlich erst in der Bank selbst möglich wird.
Um ein unberechtigtes Auslesen der zwischen dem mobilen Tele- ko munikationsendgerät und dem Kassensystem des Zahlungsempfängers übertragenen Daten zu verhindern, wird bevorzugt so vorgegangen, dass die Teilnehmerkennung, der Transaktionscode und das Zahlungslimit im mobilen Telekommunikationsendgerät codiert werden und als Code an das Kassensystem des Zahlungsempfängers übermittelt werden, wobei der Code im Kassensystem decodiert wird.
Die Datenübertragung zwischen dem mobilen Telekommunikationsendgerät und dem Kassensystem kann unter Verwendung herkömmli- eher Datenübertragungsstandards erfolgen, für welche die Mehrzahl der Telekommunikationsendgeräte ausgestattet ist. Beispielsweise verfügen moderne Mobiltelefone über die Möglichkeit einer Bluetooth-, WLAN- oder NFC-Verbindung. Dies erfordert jedoch eine entsprechende Nachrüstung bestehender Kassensyste- me, um die jeweils erforderliche hardwaremäßige Anpassung zu erreichen und die jeweiligen Übertragungsprotokolle softwaretechnisch zu implementieren. Um den diesbezüglichen Aufwand zu verringern und um gleichzeitig eine möglichst sichere und keine Zusatzausstattung erfordernde Datenübertragung zu realisieren, ist bevorzugt vorgesehen, dass der Code ein optoelektronisch auslesbarer Code, insbesondere ein Strichcode, ist, der auf einer Anzeigeeinheit des mobilen Telekommunikationsendgeräts angezeigt wird. Ein derartiger optoelektronisch auslesbarer Code, insbesondere ein Strichcode, kann mit herkömmlichen und weit verbreiteten Barcodescannern auf der Anzeigeeinheit des Telekommunikationsendgeräts ausgelesen werden. Das erfindungsgemäße System kann aber ohne Weiteres auch mittels NFC- Technologie zum Einsatz kommen. Die Überprüfung der Gültigkeit der vom Zahlungspflichtigen zur Verfügung gestellten Daten beruht im Rahmen des erfindungsgemäßen Verfahrens hauptsächlich auf dem übermittelten Transakti- onscode. Der Transaktionscode wird hierbei unter Verwendung eines Algorithmus generiert und wird im Kassensystem mit Hilfe eines Prüfalgorithmus hinsichtlich seiner Gültigkeit überprüft. Eine besonders bevorzugte Ausführungsform ergibt sich hierbei, wenn der Prüfalgorithmus und der für die Generierung des Transaktionscode verwende Algorithmus aufeinander abgestimmt sind. Dies bedeutet, dass der Prüfalgorithmus und der für die Generierung des Transaktionscodes verwendete Algorithmus mathematisch derart miteinander verknüpft sein müssen, dass der Prüfalgorithmus ausschließlich diejenigen Transaktionen für gültig erachtet, die unter Verwendung des für die Generierung des Transaktionscodes vorgesehenen Algorithmus generiert wurden. Zur Erhöhung der Sicherheit ist hierbei bevorzugt vorgesehen, dass der für die Generierung des Transaktionscodes verwen- dete Algorithmus in der Zahlungsabwicklungsstelle gespeichert wird. Der für die Generierung des Transaktionscodes verwendete Algorithmus ist somit außerhalb des Einflussbereichs des Zahlungspflichtigen, sodass eine Manipulation erschwert wird. Bevorzugt ist weiters vorgesehen, dass der Transaktionscode in der Zahlungsabwicklungsstelle generiert wird.
Wie bereits erwähnt, wird das jeweilige Zahlungslimit vom Zahlungspflichtigen bei jedem Zahlungsvorgang zur Verfügung gestellt, sodass aufSeiten des Zahlungsempfängers der Aufwand für die diesbezügliche Überprüfung entfällt. Im einfachsten Fall kann das Zahlungslimit vom Zahlungspflichtigen selbst festgelegt werden, was beispielsweise durch Einstellung eines entsprechenden Standardwertes im mobilen Telekommunikationsendgerät erfolgen kann. Die Einstellung des Zahlungslimits kann aber auch für jede Zahlung gesondert erfolgen. Die Einstellung des Zahlungslimits durch den Zahlungspflichtigen hat jedoch den Nachteil, dass die entsprechende Deckung am Konto nicht gewährleistet ist. Bevorzugt ist daher vorgesehen, dass die Zahlungslimits zentral verwaltet werden. Bevorzugt ist hierbei vorgese- hen, dass die Teilnehmerkennungen in der Zahlungsabwicklungsstelle gespeichert werden und jeder Teilnehmerkennung ein jeweiliges Zahlungslimit zugeordnet ist, und das Zahlungslimit von der Zahlungsabwicklungsstelle an das mobile Telekommunikationsendgerät übermittelt wird. Besonders bevorzugt ist es, wenn das in der Zahlungsabwicklungsstelle einer Teilnehmerkennung zugeordnete Zahlungslimit mit einem der jeweiligen Teil- nehmerkennung in einem Bankennetzwerk zugeordneten, gespeicherten Zahlungslimit abgeglichen wird.
Um sicherzustellen, dass für einen Zahlungsvorgang jeweils das aktuelle Zahlungslimit zur Verfügung steht, kann im Rahmen der Erfindung so vorgegangen werden, dass ein nach einem Abgleichvorgang geändertes Zahlungslimit dem der Teilnehmerkennung entsprechenden mobilen Telekommunikationsendgerät gemeinsam mit einem neuen Transaktionscode übermittelt wird. Zur weiteren Erhöhung der Sicherheit ist bevorzugt vorgesehen, dass im Rahmen des bargeldlosen Zahlungsvorganges zusätzlich ein Zeitstempel vom mobilen Telekommunikationsendgerät an das Kassensystem übermittelt wird, vorzugsweise in codierter Form, und der Zeitstempel im Kassensystem mit der aktuellen Uhrzeit verglichen wird und das Freigeben der Zahlung im Kassensystem erfolgt, wenn die Differenz zwischen der aktuellen Uhrzeit und dem Zeitstempel einen definierten Wert nicht übersteigt.
Die für die Durchführung des bargeldlosen Zahlungsvorganges erforderlichen Funktionen sind derart gestaltet, dass sie ohne weiteres auf herkömmlichen Mobiltelefonen realisiert werden können. Eine besonders komfortable und anwenderfreundliche Ausführungsform sieht hierbei vor, dass die am mobilen Telekommunikationsendgerät ausführbaren Verfahrensschritte in einer auf das Gerät ladbaren Programmapplikation implementiert sind. Eine derartige Programmapplikation kann gleichzeitig eine entsprechend benutzerfreundliche und ansprechende Benutzeroberfläche zur Verfügung stellen. In die Programmapplikation kann auch die Funktion der Kodierung der zu übermittelnden Daten implemen- tiert sein, wobei ein entsprechend großflächiges Anzeigeelement auch die bevorzugt vorgesehene Anzeige eines Strichcodes ermöglicht. In die Programmapplikation kann weiters in einfacher Weise die Teilnehmerkennung eingebettet sein, wobei in diesem Zusammenhang bevorzugt vorgesehen ist, dass die Teilnehmerkennung eine applikationsspezifische Kennung ist, die beispielsweise vom Bankennetzwerk generiert und in der Programmapplika- tion gespeichert wird. Zur Erhöhung der Sicherheit kann weiters bevorzugt vorgesehen sein, dass die Applikation vor Übermittlung der Teilnehmerkennung, des Transaktionscodes, des Zahlungslimits und ggf. des Zeitstempels vom mobilen Telekommunikationsendgerät an das Kassensystem eine PIN-Abfrage startet und die Übermittlung nur bei korrekter PIN-Eingabe erfolgt. Der Ablauf kann im Detail beispielsweise wie folgt vorgesehen sein:
Die Applikation erhält Teilnehmerkennung, Transaktionscodes und Zahlungslimit zu einem Zeitpunkt, zu dem das Mobiltelefon online ist — unter Umständen schon lange bevor die Applikation zur Zahlung aktiviert wird.
Wenn der PIN in der Applikation eingegeben wird, wird bevorzugt nochmals geprüft, ob der in der Applikation schon bereit gehaltene Code noch das korrekte Zahlungslimit enthält, das heißt es wird ein Abgleich mit dem in der Zah- lungsabwicklungsstelle gespeicherten Zahlungslimit vorgenommen .
Wenn das Zahlungslimit veraltet ist, wird es durch ein neues ersetzt.
Wenn keine Onlineverbindung zum Zeitpunkt der PIN-Eingabe verfügbar ist, wird das bereit gehaltene Zahlungslimit verwendet .
Gemäß einem zweiten Aspekt der Erfindung wird eine Vorrichtung zum Durchführen von bargeldlosen Zahlungen mit Hilfe von mobilen Telekommunikationsendgeräten vorgeschlagen, umfassend eine elektronische Zahlungsabwicklungsstelle und wenigstens ein elektronisches Kassensystem eines Zahlungsempfängers, wobei die Zahlungsabwicklungsstelle wenigstens eine Datenbank, die Teil- nehmerkennungen von mobilen Telekommunikationsendgeräten und den Teilnehmerkennungen zugeordnete Zahlungslimits gespeichert hat, einen Transkationscodegenerator , der einen für den jewei- ligen Zahlungsvorgang spezifischen Transaktionscode unter Verwendung eines Algorithmus generiert, und Übertragungsmittel zum Übermitteln des Transaktionscodes und des zugeordneten Zahlungslimits an das mobile Telekommunikationsendgerät aufweist, und wobei das Kassensystem ausgebildet ist, um im Rahmen eines bargeldlosen Zahlungsvorganges von einem mobilen Telekommunikationsendgerät übermittelte Daten, nämlich die Teilnehmerkennung, den Transaktionscode und das Zahlungslimit zu empfangen und zu überprüfen, wobei das Kassensystem Eingabemittel auf- weist, um einen Zahlungsbetrag einzugeben, wobei das Kassensystem weiters Verarbeitungsmittel aufweist, die ausgebildet sind, um das übermittelte Zahlungslimit mit dem gewünschten Zahlungsbetrag zu vergleichen und um die Gültigkeit des Transaktionscodes unter Verwendung eines im Kassensystem gespeicherten Prüfalgorithmus zu überprüfen, wobei das Kassensystem weiters Freigabemittel aufweist, um die Zahlung freizugeben, wenn folgende Bedingungen erfüllt sind: der gewünschte Zahlungsbetrag liegt innerhalb des Zahlungslimits und der Transaktionscode ist gültig, wobei das Kassensystem weiters einen Speicher aufweist zum Speichern der freigegebenen Zahlung, wobei der Speicher mit einem Übertragungsmittel zusammenwirkt, um die Zahlung später oder sofort an die Zahlungsabwicklungsstelle zur Veranlassung eines Abbuchungsauftrages weiterzugeben. Bevorzugte Weiterbildungen der erfindungsgemäßen Vorrichtungen sind in den Unteran- Sprüchen definiert.
Die Erfindung wird nachfolgend anhand eines in der Zeichnung schematisch dargestellten Ausführungsbeispiels näher erläutert. Mit 1 ist ein Kassensystem eines Zahlungsempfängers bezeichnet, das wenigstens eine Registrierkasse 2 umfasst, die an einen zentralen Kassenserver 3 angebunden ist. Der Kassenserver 3 kann sich hierbei lokal am Standort der Registrierkasse 2 befinden. Insbesondere bei Kassensystemen mit einer Vielzahl von räumlich verteilten Registrierkassen 2 kann der Kassenserver 3 auch an einem entfernten Ort angeordnet sein. Beim Kassenserver 3 handelt es sich um ein herkömmliches Abrechnungssystem, dem Daten der von den einzelnen Registrierkassen 2 abgewickelten Zahlungen übermittelt werden. Typischerweise werden dabei zu jeder Zahlung der Zahlungsbetrag, eine Identifizierung der Registrierkasse 2 sowie der Zeitpunkt der Zahlung übermittelt. Die Registrierkassen sind dabei geeignet, sowohl Bargeldzahlun- gen abzuwickeln als auch elektronische bargeldlose Zahlungen. Die Anbindungen der einzelnen Registrierkassen 2 an den Kassenserver 3 erfolgt über herkömmliche Protokolle, wie beispielsweise über ein XML-Webservice. Der herkömmliche Kassenserver 3 ist im vorliegenden Ausführungsbeispiel um eine Programmerweiterung 4 ergänzt, welche die Implementierung der vorliegenden Erfindung erlaubt.
Ein mobiles Telekommunikationsendgerät eines Benutzers ist mit 5 bezeichnet. Dabei handelt es sich um ein herkömmliches Mobiltelefon, wobei insbesondere Smartphones geeignet sind. Auf dem mobilen Telekommunikationsendgerät 5 ist eine Programmapplikation 6 installiert, welche die Abwicklung des erfindungsgemäßen bargeldlosen Zahlungsverfahrens erlaubt.
Die zentrale Abwicklungsstelle ist mit 7 bezeichnet und umfasst einen Zahlungsserver 8 sowie eine Datenbank 9. Die Zahlungsab- wicklungsstelle 7 kann eine Datenverbindung sowohl zum Kassensystem 1 als auch zum mobilen Telekommunikationsendgerät 5 auf- bauen.
Weiters ist die Zahlungsabwicklungsstelle 7 an einen Austauschserver 10 angebunden, der wiederum mit einer Bank 11 oder entsprechenden elektronischen Bankennetzwerken in Verbindung steht.
Die Abwicklung einer bargeldlosen Zahlung gemäß der vorliegenden Erfindung aus der Sicht eines Kunden, der eine bargeldlose Zahlung abwickeln möchte, läuft wie folgt ab. Vorausgesetzt wird hierbei, dass der Kunde ein Konto bei einer Bank unterhält. Zunächst muss der Bankkunde die Programmapplikation 6 auf sein mobiles Telekommunikationsendgerät 5 laden. Bevorzugt > läuft dies so ab, dass der Bankkunde sich in den Onlinebankingbereich seiner Bank anmeldet und dort die Programmapplikation 6 mit seinem Bankkonto verbindet. Sobald der Kunde die Programmapplikation 6 auf sein mobiles Telekommunikationsendgerät 5 geladen und dort installiert hat, ist das Endgerät 5 für bargeldlose Zahlungsvorgänge bereit. Zuvor wurde in die Programmapplikation 6 noch eine von der Bank 11 generierte Teilnehmerkennung gespeichert. Der Speichervorgang kann entweder aufgrund einer manuellen Eingabe der Teilnehmerkennung durch den Kunden erfolgen oder kann bereits bankseitig in die zum Herunterladen bereitgestellte Programmapplikation gespeichert worden sein. Wesentlich ist, dass es sich bei der Teilnehmerkennung um eine eindeutige und einzigartige Kennung handelt, sodass es in der Folge möglich ist den Teilnehmer aufgrund der Teilnehmerkennung eindeutig zu identifizieren.
Wenn der Kunde in einem Geschäft bargeldlos bezahlen will, öffnet er die Programmapplikation 6 auf seinem mobilen Telekommunikationsendgerät 5. Die Programmapplikation stellt auf der Anzeigeeinheit des mobilen Telekommunikationsendgeräts 5 einen Einmalbarcode dar, der von einem Barcodeleser der Registrierkasse 2 eingelesen wird. Der auf diese Art und Weise übermittelte Code wird im Kassensystem 1 auf Validität geprüft. Wenn die Qualitätsüberprüfung positiv abgeschlossen werden konnte, wird der Barcode als Zahlung angenommen und der Zahlungsbetrag wird in der Folge vom Bankkonto des Kunden eingezogen.
Um den oben beschriebenen bargeldlosen Zahlungsvorgang zur ermöglichen ist die technische Umsetzung wie folgt vorgesehen. Die Bank 11 ist über den Austauschserver 10 mit der Zahlungsab- wicklungsstelle 7 verbunden. Wenn ein Bankkunde die Programmapplikation 6 herunterlädt, wird dies von der Bank 11 an die Zahlungsabwicklungsstelle 7 gemeldet. Die Bank 11 übermittelt hierbei die dem Bankkunden zugewiesene Teilnehmerkennung ge- meinsam mit einer anonymen virtuellen Kontonummer zunächst an den Austauschserver 10. Bei der virtuellen Kontonummer handelt es sich nicht um die reale Kontonummer desjenigen Girokontos, das der Teilnehmer bei der Bank 11 unterhält. Im Austauschserver 10 wird die Teilnehmerkennung und die der Teilnehmerkennung jeweils zugeordnete virtuelle Kontonummer gespeichert. Die Zahlungsabwicklungsstelle 7 erhält in der Folge nur die Teilneh- merkennung übermittelt. Dies führt dazu, dass die Zahlungsabwicklungsstelle 7 über keine realen Kontodaten des Bankkunden verfügt, sodass die in der Zahlungsabwicklungsstelle 7 vorhandenen Daten grundsätzlich anonym sind, was dazu führt, dass der Sicherheitsstandard in der Zahlungsabwicklungsstelle 7 und auch im Kassensystem 1 geringer gewählt werden kann und dass ein allfälliger Datendiebstahl keine verwertbaren bzw. personenbezogenen Daten bringt. Der weitere Datenaustausch zwischen der Zahlungsabwicklungsstelle 7 und der Bank 11 erfolgt ausschließlich über die virtuelle Kontonummer, d.h. unter Vermittlung des Austauschservers 10 .
Gemeinsam mit der Teilnehmerkennung sendet die Bank 11 das dem betreffenden Konto zugeordnete Zahlungslimit an die Zahlungsabwicklungsstelle 7 . Sofern sich das Zahlungslimit eines Kunden in der Folge ändert, kann die Bank 11 jederzeit ein neues Zahlungslimit an die Zahlungsabwicklungsstelle 7 über den Schnittstellenserver 10 senden.
Die Zahlungsabwicklungsstelle 7 hat die Teilnehmerkennung und das jeweils zugeordnete Zahlungslimit in der Datenbank 9 gespeichert. Diese Daten werden an den Zahlungsserver 8 übermittelt, welcher einen Transaktionscodegenerator umfasst, mit welchem unter Verwendung eines im Zahlungsserver 8 gespeicherten Algorithmus einmalig verwendbare, eindeutige Transaktionscode erstellt werden können. Zur Vorbereitung eines bargeldlosen Zahlungsvorganges mit Hilfe des mobilen Telekommunikationsendgeräts 5 erstellt der Zahlungsserver 8 einen Code, der bevorzugt in verschlüsselter Form die Teilnehmerkennung, das Zahlungslimit und den automatische generierten Transaktionscode enthält und übermittelt diesen Code an die Programmapplikation 6 des mobilen Telekommunikationsendgeräts 5. Die Datenübertragung kann entweder auf Anfrage der Programmapplikation 6 erfol- gen oder durch den Zahlungsserver 8 veranlasst sein. Wesentlich ist hierbei, dass die Datenübermittlung nur dann erfolgt, wenn zuvor festgestellt wurde, dass die Programmapplikation 6 diejenige Teilnehmerkennung enthält, die der im zu übermittelnden Code enthaltenen Teilnehmerkennung entspricht.
In der Programmapplikation 6 wird der vom Zahlungsserver 8 erhaltene Code um einen Zeitstempel ergänzt. Die Programmapplikation 6 erstellt in der Folge aus der Teilnehmerkennung, dem Zahlungslimit, dem Transaktionscode und dem Zeitstempel einen Barcode, der auf der Anzeigeeinheit des mobilen Telekommunikationsendgeräts 5 angezeigt wird. Die Registrierkasse 2 scannt den angezeigten Barcode mit Hilfe eines Barcodescanners ein und übermittelt diesen an den Kassenserver 3. Die im Kassenserver 3 implementierte Programmerweiterung 4 decodiert den übermittelten Code und kann anhand eines lokal gespeicherten Prüfalgorithmus überprüfen, ob der übermittelte Transaktionscode gültig ist. Weiters wird anhand des übermittelten Zeitstempels festgestellt, ob der übermittelte Code noch gültig ist. Weiters wird überprüft, ob der gewünschte Zahlbetrag, der von der Registrierkasse 2 gemeinsam mit dem Code an das Kassensystem 3 übermittelt wurde, mit dem ebenfalls übermittelten Zahlungslimit vereinbar ist. Das Kassensystem 3 ist mit dem Zahlungsserver 8 verbunden, wodurch der im Kassensystem 3 gespeicherte Prüfalgo- rithmus jederzeit geändert werden kann.
Sofern die Überprüfung des an das Kassensystem 3 übermittelten Codes ergeben hat, dass der Code gültig ist, meldet das Kassensystem 3 an die Registrierkasse 2, dass die Zahlung angenommen werden kann.
Sofern die Zahlung freigegeben wurde, übermittelt das Kassensystem 3 den akzeptierten Code enthaltend die Teilnehmerkennung, das Zahlungslimit, den Transaktionscode und den Zeitstem- pel sowie zusätzlich den Zahlungsbetrag und weitere zahlungsrelevante Daten wie beispielsweise eine Identifizierung der Registrierkasse und des Händlers an die Zahlungsabwicklungsstelle 7 und insbesondere an die Datenbank 9. Nach Empfang dieser Daten in der Datenbank 9 wird die Generierung eines neuen Transaktionscodes durch den Zahlungsserver 8 sowie die Übermittlung desselben an die Programmapplikation 6 des betreffenden Kunden freigegeben, sodass ein neuer bargeldloser Zahlungsvorgang initiiert werden kann. Weiters übermittelt die Zahlungsabwick- lungsstelle 7 einen Datensatz enthaltend die Teilnehmerkennung, den Zahlungsbetrag und eine Identifizierung des Händlers und ggf. weiters den Zeitstempel, eine Rechnungsnummer und weitere zahlungsrelevante Daten an den Austauschserver 10. Der Austauschserver 10 kann die Teilnehmerkennung einer virtuellen Kontonummer zuordnen und sendet einen Abbuchungsauftrag sowie die Transaktionsdetails gemeinsam mit der virtuellen Kontonummer an die Bank 11 bzw. an ein entsprechendes Bankennetzwerk. In der Bank 11 wird anhand der virtuellen Kontonummer das reale Konto des Kunden zugeordnet und es wird das Konto mit dem entsprechenden Zahlungsbetrag belastet.

Claims

Patentansprüche :
1. Verfahren zum Durchführen von bargeldlosen Zahlungen, mit Hilfe von mobilen Telekommunikationsendgeräten, wobei jedes Telekommunikationsendgerät eine Teilnehmerkennung und ein dieser Teilnehmerkennung zugeordnetes Zahlungslimit gespeichert hat, umfassend die Schritte:
Generieren eines für den Zahlungsvorgang spezifischen Transaktionscodes unter Verwendung eines Algorithmus, - Übermitteln des Transaktionscodes an das mobile Telekommunikationsendgerät ,
Übermitteln der Teilnehmerkennung, des Transaktionscodes und des Zahlungslimits vom mobilen Telekommunikationsendgerät an ein Kassensystem des Zahlungsempfängers im Rahmen eines bargeldlosen Zahlungsvorganges,
Vergleichen des übermittelten Zahlungslimits mit dem gewünschten Zahlungsbetrag im Kassensystem,
Überprüfen der Gültigkeit des Transaktionscodes im Kassensystem unter Verwendung eines im Kassensystem gespeicher- ten Prüfalgorithmus ,
Freigeben der Zahlung im Kassensystem wenn folgende Bedingungen erfüllt sind: der gewünschte Zahlungsbetrag liegt innerhalb des Zahlungslimits und der Transaktionscode ist gültig,
- Speichern der freigegebenen Zahlung im Kassensystem für eine spätere oder sofortige Weitergabe an eine Zahlungsab- wicklungsstelle zur Veranlassung eines Abbuchungsaufträges .
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Veranlassung des Buchungsauftrages folgende Schritte um- fasst :
Übermitteln eines Datensatzes vom Kassensystem an die Zah- lungsabwicklungsstelle, wobei der Datensatz zumindest die Teilnehmerkennung und den Zahlungsbetrag enthält, und
Übermitteln der Teilnehmerkennung von der Zahlungsabwick- lungsstelle an ein Bankennetzwerk im Rahmen eines Abbu- chungsaufträges , wobei im Bankennetzwerk oder in einer Schnittstelle zwischen dem Bankennetzwerk und der Zahlungsabwicklungsstelle personenspezifische Kontonummern und Teilnehmerkennungen einander zugeordnet gespeichert sind und die von der Zahlungsabwicklungsstelle übermittelte Teilnehmerkennung der entsprechenden Kontonummer zugeordnet wird und eine Abbuchung von einem Konto unter Verwendung der Kontonummer vorgenommen wird.
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die personenspezifische Kontonummer eine virtuelle Kontonummer ist, wobei virtuelle Kontonummern und reale Kontonummern im Bankennetzwerk einander zugeordnet gespeichert sind und im Rahmen eines Abbuchungsauftrages die virtuelle Kontonummer der entsprechenden realen Kontonummer zugeordnet wird.
4. Verfahren nach Anspruch 1, 2 oder 3 dadurch gekennzeichnet, dass die Teilnehmerkennung, der Transaktionscode und das Zahlungslimit im mobilen Telekommunikationsendgerät codiert werden und als Code an das Kassensystem des Zahlungsempfängers übermittelt werden, wobei der Code im Kassensystem decodiert wird.
5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass der Code ein optoelektronisch auslesbarer Code, insbesondere ein Strichcode, ist, der auf einer Anzeigeeinheit des mobilen Telekommunikationsendgeräts angezeigt wird.
6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch ge- kennzeichnet, dass der Prüfalgorithmus und der für die Generierung des Transaktionscode verwende Algorithmus aufeinander abgestimmt sind.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch ge- kennzeichnet, dass der für die Generierung des Transaktionscodes verwendete Algorithmus in der Zahlungsabwicklungsstelle gespeichert wird.
8 . Verfahren nach einem der Ansprüche 1 bis 7 , dadurch gekennzeichnet, dass der Prüfalgorithmus in der Zahlungsabwick- lungsstelle generiert und an das Kassensystem übermittelt wird.
9 . Verfahren nach einem der Ansprüche 1 bis 8 , dadurch gekennzeichnet, dass der Transaktionscode in der Zahlungsabwick- lungsstelle generiert wird.
10 . Verfahren nach einem der Ansprüche 1 bis 9 , dadurch gekennzeichnet, dass die Teilnehmerkennung eine gerätespezifische Kennung ist.
11 . Verfahren nach einem der Ansprüche 1 bis 10 , dadurch ge- kennzeichnet, dass die Teilnehmerkennungen in der Zahlungsab- wicklungsstelle gespeichert werden und jeder Teilnehmerkennung ein jeweiliges Zahlungslimit zugeordnet ist, und das Zahlungslimit von der Zahlungsabwicklungsstelle an das mobile Telekommunikationsendgerät übermittelt wird.
12 . Verfahren nach Anspruch 11 , dadurch gekennzeichnet, dass das in der Zahlungsabwicklungsstelle einer Teilnehmerkennung zugeordnete Zahlungslimit mit einem der jeweiligen Teilnehmerkennung in einem Bankennetzwerk gespeicherten Zahlungslimit abgeglichen wird.
13 . Verfahren nach Anspruch 12 , dadurch gekennzeichnet, dass ein nach einem Abgleichvorgang geändertes Zahlungslimit dem der Teilnehmerkennung entsprechenden mobilen Telekommunikationsend- gerät gemeinsam mit einem neuen Transaktionscode übermittelt wird.
14 . Verfahren nach einem der Ansprüche 1 bis 13 , dadurch gekennzeichnet, dass im Rahmen des bargeldlosen Zahlungsvorganges zusätzlich ein Zeitstempel vom mobilen Telekommunikationsendgerät an das Kassensystem übermittelt wird, vorzugsweise in codierter Form, und der Zeitstempel im Kassensystem mit der aktu- eilen Uhrzeit verglichen wird und das Freigeben der Zahlung im Kassensystem erfolgt, wenn die Differenz zwischen der aktuellen Uhrzeit und dem Zeitstempel einen definierten Wert nicht übersteigt.
15. Verfahren nach einem der Ansprüche 1 bis 14, dadurch gekennzeichnet, dass die am mobilen Telekommunikationsendgerät ausführbaren Verfahrensschritte in einer auf das Gerät ladbaren Programmapplikation implementiert sind.
16. Verfahren nach Anspruch 15, dadurch gekennzeichnet, dass die Teilnehmerkennung eine applikationsspezifische Kennung ist, die vom Bankennetzwerk generiert in der Programmapplikation gespeichert wird.
17. Verfahren nach Anspruch 15 oder 16, dadurch gekennzeichnet, dass die Applikation vor Übermittlung der Teilnehmerkennung, des Transaktionscodes, des Zahlungslimits und ggf. des Zeitstempels vom mobilen Telekommunikationsendgerät an das Kas- sensystem eine PIN-Abfrage startet und die Übermittlung nur bei korrekter PIN-Eingabe erfolgt.
18. Vorrichtung zum Durchführen von bargeldlosen Zahlungen, mit Hilfe von mobilen Telekommunikationsendgeräten (5), insbe- sondere zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 17, umfassend eine elektronische Zahlungsabwick- lungsstelle (7) und wenigstens ein elektronisches Kassensystem (1) eines Zahlungsempfängers, wobei die Zahlungsabwicklungs- stelle (7) wenigstens eine Datenbank (9), die Teilnehmerkennun- gen von mobilen Telekommunikationsendgeräten und den Teilnehmerkennungen zugeordnete Zahlungslimits gespeichert hat, einen Transkationscodegenerator, der einen für den jeweiligen Zahlungsvorgang spezifischen Transaktionscode unter Verwendung eines Algorithmus generiert, und Übertragungsmittel zum Über- mittein des Transaktionscodes und des zugeordneten Zahlungslimits an das mobile Telekommunikationsendgerät (5) aufweist, und wobei das Kassensystem (1) ausgebildet ist, um im Rahmen eines bargeldlosen Zahlungsvorganges von einem mobilen Telekommunikationsendgerät (5) übermittelte Daten, nämlich die Teilnehmerkennung, den Transaktionscode und das Zahlungslimit zu empfangen und zu überprüfen, wobei das Kassensystem (1) Eingabemittel aufweist, um einen Zahlungsbetrag einzugeben, wobei das Kassensystem (1) weiters Verarbeitungsmittel aufweist, die ausgebildet sind, um das übermittelte Zahlungslimit mit dem gewünschten Zahlungsbetrag zu vergleichen, und um die Gültigkeit des Transaktionscodes unter Verwendung eines im Kassensystem (1) gespei- cherten Prüfalgorithmus zu überprüfen, wobei das Kassensystem weiters Freigabemittel aufweist, um die Zahlung freizugeben, wenn folgende Bedingungen erfüllt sind: der gewünschte Zahlungsbetrag liegt innerhalb des Zahlungslimits und der Transaktionscode ist gültig, wobei das Kassensystem (1) weiters einen Speicher aufweist zum Speichern der freigegebenen Zahlung, wobei der Speicher mit Übertragungsmittel zusammenwirkt, um die Zahlung später oder sofort an die Zahlungsabwicklungsstelle (7) zur Veranlassung eines Abbuchungsauftrages weiterzugeben.
19. Vorrichtung nach Anspruch 18, dadurch gekennzeichnet, dass die Übertragungsmittel des Kassensystems (1) ausgebildet ist, um einen Datensatzes an die Zahlungsabwicklungsstelle (7) zu übermitteln, wobei der Datensatz zumindest die Teilnehmerkennung und den Zahlungsbetrag enthält, und dass die Zahlungsab- wicklungssteile (7) an ein Bankennetzwerk angebunden ist, wobei die Zahlungsabwicklungsstelle ausgebildet ist, um die Teilnehmerkennung im Rahmen eines Abbuchungsauftrages an das Bankennetzwerk zu übermitteln.
20. Vorrichtung nach Anspruch 19, dadurch gekennzeichnet, dass im Bankennetzwerk oder in einer Schnittstelle zwischen dem Bankennetzwerk und der Zahlungsabwicklungsstelle (7) personenspezifische Kontonummern und Teilnehmerkennungen einander zugeordnet gespeichert sind und das Bankennetzwerk ausgebildet ist, um die von der Zahlungsabwicklungsstelle (7) übermittelte Teilnehmerkennung der entsprechenden Kontonummer zuzuordnen und eine Abbuchung von einem Konto unter Verwendung der Kontonummer vorzunehmen.
21. Vorrichtung nach Anspruch 20, dadurch gekennzeichnet, dass die personenspezifische Kontonummer eine virtuelle Kontonummer ist, wobei virtuelle Kontonummern und reale Kontonummern im Bankennetzwerk einander zugeordnet gespeichert sind und im Rahmen eines Abbuchungsauftrages die virtuelle Kontonummer der entsprechenden realen Kontonummer zuordenbar ist.
22. Vorrichtung nach einem der Ansprüche 18 bis 21, dadurch gekennzeichnet, dass Codierungsmittel vorgesehen sind, um die Teilnehmerkennung, den Transaktionscode und das Zahlungslimit zu codieren und als Code an das Kassensystem des Zahlungsemp- fängers zu übermitteln und dass das Kassensystem Decodierungs- mittel umfasst, um den übermittelten Code zu decodieren.
23. Vorrichtung nach Anspruch 22, dadurch gekennzeichnet, dass der Code ein optoelektronisch auslesbarer Code, insbesondere ein Strichcode, ist, der auf einer Anzeigeeinheit eines mobilen Telekommunikationsendgeräts (5) anzeigbar ist.
24. Vorrichtung nach einem der Ansprüche 18 bis 23, dadurch gekennzeichnet, dass der Prüfalgorithmus und der für die Gene- rierung des Transaktionscode verwende Algorithmus aufeinander abgestimmt sind.
25. Vorrichtung nach einem der Ansprüche 18 bis 24, dadurch gekennzeichnet, dass die Zahlungsabwicklungsstelle (7) einen Speicher für den für die Generierung des Transaktionscodes verwendeten Algorithmus umfasst.
26. Vorrichtung nach einem der Ansprüche 18 bis 25, dadurch gekennzeichnet, dass die Teilnehmerkennung eine gerätespezifische Kennung ist.
27 . Vorrichtung nach einem der Ansprüche 18 bis 26 , dadurch gekennzeichnet, dass die Zahlungsabwicklungsstelle ( 7 ) mit dem Bankennetzwerk zusammenwirkende Abgleichmittel umfasst, um das in der Zahlungsabwicklungsstelle ( 7 ) einer Teilnehmerkennung zugeordnete Zahlungslimit mit einem der jeweiligen Teilnehmerkennung in einem Bankennetzwerk gespeicherten Zahlungslimit abzugleichen.
28 . Vorrichtung nach Anspruch 17 , dadurch gekennzeichnet, dass die Abgleichmittel mit einer Triggerschaltung ausgebildet sind, um die Übermittlung eines nach einem Abgleichvorgang geänderten Zahlungslimits dem der Teilnehmerkennung entsprechenden mobilen Telekommunikationsendgerät gemeinsam mit einem neuen Transaktionscode zu triggern.
29 . Vorrichtung nach einem der Ansprüche 18 bis 28 , dadurch gekennzeichnet, dass ein Uhrenmodul vorgesehen ist, das geeignet ist im Rahmen des bargeldlosen Zahlungsvorganges zusätzlich einen Zeitstempel an das Kassensystem ( 1 ) zu übermitteln, vor- zugsweise in codierter Form, dass das Kassensystem ( 1 ) ein Uhrenmodul aufweist und dass die Verarbeitungsmittel des Kassensystems ( 1 ) ausgebildet sind, um den Zeitstempel mit der vom Uhrenmodul des Kassensystems ( 1 ) bereitgestellten aktuellen Uhrzeit zu vergleichen, wobei die Freigabemittel ausgebildet sind, um die Zahlung freizugeben, wenn die Differenz zwischen der aktuellen Uhrzeit und dem Zeitstempel einen definierten Wert nicht übersteigt.
30 . Vorrichtung nach einem der Ansprüche 18 bis 29 , dadurch gekennzeichnet, dass eine am mobilen Telekommunikationsendgerät
( 5 ) ausführbare Programmapplikation ( 6 ) vorgesehen ist.
31 . Vorrichtung nach Anspruch 30 , dadurch gekennzeichnet, dass die Teilnehmerkennung eine applikationsspezifische Kennung ist, die in der Programmapplikation ( 6 ) gespeichert ist.
32. Vorrichtung nach Anspruch 30 oder 31, dadurch gezeichnet, dass die Applikation eine PIN-Abfrage umfasst, um vor Übermittlung der Teilnehmerkennung, des Transaktionscodes, des Zahlungslimits und ggf. des Zeitstempels an das Kassensystem einen PIN abzufragen, wobei die Übermittlung nur bei korrekter PIN- Eingabe erfolgt.
EP12732946.4A 2011-06-22 2012-06-19 Verfahren und vorrichtung zum durchführen von bargeldlosen zahlungen Ceased EP2724304A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
ATA912/2011A AT511626B1 (de) 2011-06-22 2011-06-22 Verfahren und vorrichtung zum durchführen von bargeldlosen zahlungen
PCT/AT2012/000173 WO2012174579A1 (de) 2011-06-22 2012-06-19 Verfahren und vorrichtung zum durchführen von bargeldlosen zahlungen

Publications (1)

Publication Number Publication Date
EP2724304A1 true EP2724304A1 (de) 2014-04-30

Family

ID=46466012

Family Applications (1)

Application Number Title Priority Date Filing Date
EP12732946.4A Ceased EP2724304A1 (de) 2011-06-22 2012-06-19 Verfahren und vorrichtung zum durchführen von bargeldlosen zahlungen

Country Status (4)

Country Link
US (1) US20140156530A1 (de)
EP (1) EP2724304A1 (de)
AT (1) AT511626B1 (de)
WO (1) WO2012174579A1 (de)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11392955B2 (en) 2015-05-20 2022-07-19 Ripple Luxembourg S.A. Temporary consensus networks in a resource transfer system
US11481771B2 (en) 2015-05-20 2022-10-25 Ripple Luxembourg S.A. One way functions in a resource transfer system
US11386415B2 (en) 2015-05-20 2022-07-12 Ripple Luxembourg S.A. Hold condition in a resource transfer system
US11367072B2 (en) 2015-05-20 2022-06-21 Ripple Luxembourg S.A. Private networks and content requests in a resource transfer system
US10740732B2 (en) * 2015-05-20 2020-08-11 Ripple Luxembourg S.A. Resource transfer system
US11392944B2 (en) 2015-05-20 2022-07-19 Ripple Luxembourg S.A. Transfer costs in a resource transfer system
US10839369B1 (en) * 2019-07-22 2020-11-17 Capital One Services, Llc Dynamic electronic communication with variable messages using encrypted quick response codes
US11914617B2 (en) * 2021-04-19 2024-02-27 Wealthfront Corporation Executing updates of records in a distributed database system

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010126509A2 (en) * 2009-04-30 2010-11-04 Donald Michael Cardina Systems and methods for randomized mobile payment
US20110022472A1 (en) * 2009-02-25 2011-01-27 Zon Ludwik F Payment system and method

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7376583B1 (en) * 1999-08-10 2008-05-20 Gofigure, L.L.C. Device for making a transaction via a communications link
US6584309B1 (en) * 1999-12-16 2003-06-24 The Coca-Cola Company Vending machine purchase via cellular telephone
DE10005487A1 (de) * 2000-02-08 2001-08-09 Siemens Ag Verfahren zur Nutzeridentitätskontrolle
JP2001344545A (ja) * 2000-03-29 2001-12-14 Ibm Japan Ltd 処理システム、サーバ、処理端末、通信端末、処理方法、データ管理方法、処理実行方法、プログラム
US7209903B1 (en) * 2000-07-13 2007-04-24 Ctech Global Services Corporation Limited Method and system for facilitation of wireless e-commerce transactions
CA2354896A1 (en) * 2001-08-09 2003-02-09 Scott Edward James Garratt Method to activate a vending machine
EP1316929B1 (de) * 2001-12-01 2008-02-27 Scheidt & Bachmann Gmbh Verfahren zur bargeldlosen Abwicklung von Automaten-Nutzungsvorgängen
US20080223918A1 (en) * 2007-03-15 2008-09-18 Microsoft Corporation Payment tokens
WO2009070114A1 (en) * 2007-11-30 2009-06-04 Skycash Sp.Z O.O. A server of a check issuer and a merchant system in a proximity payment system
US20090281904A1 (en) * 2008-04-02 2009-11-12 Pharris Dennis J Mobile telephone transaction systems and methods

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110022472A1 (en) * 2009-02-25 2011-01-27 Zon Ludwik F Payment system and method
WO2010126509A2 (en) * 2009-04-30 2010-11-04 Donald Michael Cardina Systems and methods for randomized mobile payment

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of WO2012174579A1 *

Also Published As

Publication number Publication date
AT511626B1 (de) 2014-09-15
AT511626A1 (de) 2013-01-15
WO2012174579A1 (de) 2012-12-27
US20140156530A1 (en) 2014-06-05

Similar Documents

Publication Publication Date Title
AT512070B1 (de) Verfahren und vorrichtung zum durchführen von bargeldlosen zahlungen
AT511626B1 (de) Verfahren und vorrichtung zum durchführen von bargeldlosen zahlungen
WO2002011082A1 (de) Elektronischer zahlungsverkehr mit sms
DE19903363C2 (de) Verfahren und System zur Durchführung von bargeldlosen Finanztransaktionen
WO2009003605A9 (de) Virtuelle prepaid- oder kreditkarte und verfahren und system zur bereitstellung einer solchen und zum elektronischen zahlungsverkehr
WO2002043020A2 (de) Verfahren und vorrichtung zur übermittlung von daten über mobiltelefone im bargeldlosen, elektronischen zahlungsverkehr
DE102005017374A1 (de) Verfahren zur Bestätigung einer Dienstleistungsanforderung
WO2013011043A1 (de) Mobiles system für finanztransaktionen
DE10054633C2 (de) Verfahren und System zum Kontrollieren des Zugangs zu Waren und Dienstleistungen
DE60122912T2 (de) Verfahren zum liefern von identifikationsdaten einer bezahlkarte an einen anwender
WO2000039758A1 (de) Verfahren für die sichere handhabung von geld- oder werteeinheiten mit vorausbezahlten datenträgern
EP1081919A1 (de) Verfahren zur Autorisierung in Datenübertragungssystemen zur Bezahlung von über das Internet angebotenen Waren und/oder Dienstleistungen
WO2011141062A1 (de) Bezahlsystem, verfahrung zur erzeugung mindestens eines codepaares zur autorisierung eines abbuchungsvorgangs und verfahren zur durchführung eines bezahlvorgangs
DE102012101091B4 (de) Verfahren und Vorrichtung zur Abwicklung bargeldloser Zahlungstransaktionen
DE10218729B4 (de) Verfahren zum Authentifizieren und/oder Autorisieren von Personen
EP1274971A2 (de) Verfahren zur sicheren bezahlung von lieferungen und leistungen in offenen netzwerken
WO2003101082A1 (de) Verfahren, computerprogramm u. computersystem für einen prepaid tele­kommunikationsdienst
DE10229619A1 (de) Verfahren zur Durchführung eines Zahlungsvorganges
EP1371038B1 (de) Verfahren und vorrichtung zum durchführen mindestens eines gegen zahlung eines entgelts abzuwickelnden geschäfts
DE102017003245A1 (de) Direkte Bezahlung von überschaubaren Geldbeträgen an Automaten durch das eigene Smartphone des zu Zahlenden ohne Bargeldeinsatz oder Übermittlung von Daten des Smartphone-Eigentümers an den Betragsempfänger
DE10115171B4 (de) Verfahren und Einrichtung zum Aufladen von Prepaid-Konten
DE10210792B4 (de) Verfahren und System zur Freischaltung eines kostenpflichtigen Mobilfunk- oder Online-Dienstes
WO2002071353A1 (de) Vorrichtung und verfahren zum bargeldlosen bezahlen
DE202010017920U1 (de) Bezahlsystem
DE10200588A1 (de) Buchungsverfahren und Buchungsautomat

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20131218

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

17Q First examination report despatched

Effective date: 20150312

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20180707