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 Zahlungsbetrag 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öglichkei- ten 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 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 wird, so- dass 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.

5) 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. 6) Das Kommunikationsmodul meldet sich beim Provider ab und beendet die Verbindung. Manche Terminals bleiben immer online .

7) Der Drucker erstellt ein Protokoll über Zahlung bzw. Abweisung. Das Display zeigt Entsprechendes an.

8) 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 Telekommunikationsendgeräten in einfacher Weise ermöglicht werden, ohne dass Einbußen in Bezug auf die Sicherheit des Zahlungsvorganges hinge- nommen werden müssen.

Gerade mobile Telekommunikationsendgeräte sind aus sicherheitstechnischer Sicht besonders gefährdet, weil sie leichter ent- wendet werden können und über keine ausgereiften Absicherungstechnologien (Firewall etc.) verfügen.

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 und wenigstens einer elektronischen Zahlungsabwicklungsstelle vorgesehen, wobei jedes Telekommunikationsendgerät eine Teilnehmerkennung gespeichert hat und die Zahlungsabwicklungsstelle die Teilnehmerkennungen der teilnehmenden Telekommunikationsendgeräte und den Teilnehmerkennungen jeweils zugeordnete Zahlungslimits gespeichert hat, umfassend die Schritte:

a) Generieren eines für den Zahlungsvorgang spezifischen Transaktionscodes unter Verwendung eines Algorithmus, b) Speichern des Transaktionscodes und Zuordnen des Transaktionscodes zu einer Teilnehmerkennung und dem dieser zugeordneten Zahlungslimit,

c) Übermitteln des Transaktionscodes an ein mobiles Telekommunikationsendgerät,

d) Übermitteln des Transaktionscodes vom mobilen Telekommunikationsendgerät an ein Kassensystem des Zahlungsempf ngers im Rahmen eines bargeldlosen Zahlungsvorganges,

e) Übermitteln eines Datensatzes von dem Kassensystem an die Zahlungsabwicklungsstelle, wobei der Datensatz zumindest den Transaktionscode und den gewünschten Zahlungsbetrag enthält,

f) Autorisierung des Transaktionscodes in der Zahlungsabwicklungsstelle,

g) Ermitteln des dem Transaktionscode zugeordneten Zahlungslimits,

h) Freigeben der Zahlung, wenn der gewünschte Zahlungsbetrag innerhalb des zugeordneten Zahlungslimits liegt, i) Speichern der freigegebenen Zahlung in der Zahlungsabwicklungsstelle für eine spätere oder sofortige Veranlassung eines Abbuchungsauftrages. Im Rahmen der Erfindung erfolgt die Autorisierung der Zahlung somit primär in der Zahlungsabwicklungsstelle. Die Autorisierung des Transaktionscodes umfasst hierbei bevorzugt den Abgleich des vom Kassensystem an die Zahlungsabwicklungsstelle übermittelten Transaktionscodes mit den in Schritt b) gespei- cherten Transaktionscodes.

Nur bei einem Ausfall der Datenverbindung zwischen dem Kassensystem und der Zahlungsabwicklungsstelle erfolgt die Autorisierung der Zahlung im Kassensystem. In diesem Fall entfällt die Notwendigkeit einer ständigen Onlineverbindung zu einer Bank. Bei einem Fehlschlagen der Übermittlung des Datensatzes gemäß Schritt e) wird bevorzugt wie folgt vorgegangen: der gewünschte Zahlungsbetrag wird mit einem im Kassensystem gespeicherten generellen Zahlungslimit verglichen, die Zahlung wird freigege- ben, wenn der gewünschte Zahlungsbetrag innerhalb des generellen Zahlungslimits liegt und der Transaktionscode gültig ist, und die freigegebene Zahlung wird im Kassensystem für eine spätere oder sofortige Weitergabe an die Zahlungsabwicklungsstelle zur Veranlassung eines Abbuchungsauftrages gespeichert. Bevor- zugt umfasst die Autorisierung des Transaktionscodes hierbei die Überprüfung der Gültigkeit des Transaktionscodes im Kassensystem unter Verwendung eines im Kassensystem gespeicherten Prüfalgorithmus, um festzustellen, ob der Transaktionscode von der Zahlungsabwicklungsstelle erstellt wurde.

Dadurch, dass im Kassensystem oder in einer Programmerweiterung des Kassensystems das allgemeine Zahlungslimit pro Transaktionscode geprüft wird, steht dem Zahlungsempfänger das allgemei- ne Zahlungslimit der Zahlungslösung zur Verfügung, ohne dass eine diesbezügliche Rückfrage bzw. Kontrolle bei dem kartenausgebenden Institut bzw. bei der Bank erforderlich ist. Wenn das Bankennetzwerk das Zahlungslimit eines Kontos, welches mit einem Telekommunikationsendgerät verbunden ist, ändert, so wird dies bevorzugt unmittelbar an die Zahlungsabwicklungsstelle gemeldet. Die Zahlungsabwicklungsstelle ändert aufgrund dieser Meldung das Zahlungslimit der schon an das Telekommunikati- onsendgerät ausgelieferten Transaktionscodes des betreffenden Zahlungspflichtigen in der Datenbank.

Damit wird sichergestellt, dass auch schon im Umlauf befindliche Transaktionscodes jederzeit mit einem neuen Limit versehen werden können. Da die Autorisierung der Zahlung bevorzugt in der Zahlungsabwicklungsstelle erfolgt und diese das aktuelle Zahlungslimit jedes Zahlungspflichtigen kennt, kann sichergestellt werden, dass im Rahmen des Zahlungsvorganges nur die aktuellen Zahlungslimits zur Anwendung kommen ohne dass die schon versandten Transaktionscodes ausgetauscht werden müssen.

Zur Authentifizierung des mobilen Telekommunikationsendgeräts des Zahlungspflichtigen wird der 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 oder in einer Programmerweiterung des Kassensystems kann der Transaktionscode bei einer bevorzugten Verfahrensweise vorab unter Verwendung eines gespeicherten Prüfalgorithmus ei- ner Gültigkeitsprüfung unterzogen werden, wobei die Weiterleitung an die Zahlungsabwicklungsstelle nur dann erfolgt, wenn die Gültigkeitsüberprüfung positiv abgeschlossen wurde. Zur Gültigkeitsprüfung ist somit lediglich der im Kassensystem ge- speicherte 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 des im Rahmen des Zahlungsvorganges übermittelten Transaktionscodes. 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 der Transaktionscode weder die Nummer einer Kredit-, Debit- oder Geldkarte noch die Nummer eines Bankkontos ist. Wenn weiters der Transaktionscode in keinem Bezug zu einer Rufnummer des mobilen Telekommunikationsendgeräts steht, kann auch auf diesem Weg keine Zuordnung zu einer bestimmten Person erfolgen.

Wenn die Autorisierung bzw. Freigabe der Zahlung bei einem Ausfall der Datenverbindung zwischen dem Kassensystem und der Zahlungsabwicklungsstelle im Umfeld des Kassensystem erfolgt, 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 . In der Mehrzahl der Fälle wird eine Datenverbindung zwischen dem Kassensystem und der Zahlungsabwicklungsstelle bestehen. In diesem Fall werden die Zahlungen unverzüglich an die Zahlungsabwicklungsstelle weitergegeben. Sobald die Zahlung in der Zahlungsabwicklungsstelle freigegeben wird, erfolgt die Überweisung des Zahlungsbetrages, wobei bevorzugt vorgesehen ist, dass die Überweisung von einem Konto des Teilnehmers (Käufers) direkt auf ein Konto des Zahlungsemp- fängers erfolgt. Es erfolgt somit insgesamt nur eine einzige Überweisung, um den Betrag vom Käufer an den Verkäufer zu transferieren. Eine Zwischenstation zB bei einem gesonderten Provider, bei dem ein Guthabenkonto zunächst durch Überweisung vom Bankkonto oder durch Angabe einer Kreditkartennummer aufgefüllt werden muss und von dem die Überweisung an den endgültigen Zahlungsempfänger erfolgt, ist hierbei nicht erforderlich.

Eine bevorzugte Verfahrensweise sieht in diesem Zusammenhang vor, dass die Veranlassung des Buchungsauftrages folgende Schritte umfasst:

Ermitteln der dem vom Kassensystem an die Zahlungsabwicklungsstelle übermittelten Transaktionscode in der Zahlungsabwicklungsstelle zugeordneten Teilnehmerkennung und

Übermitteln der Teilnehmerkennung und des Zahlungsbetrages 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 zugeordnet wird und eine Abbuchung von einem Konto unter Verwendung der Kontonummer vorgenommen wird wobei eine entsprechende Gutschrift bevorzugt unmittelbar auf ein Konto des Zahlungsempfängers erfolgt.

Wesentlich ist hierbei, dass auch die Zahlungsabwicklungsstelle im Sinne des Datenschut es über keine personenbezogenen Daten verfügt. Die Zahlungsabwicklungsstelle verfügt lediglich über von dem Kassensystem zur Verfügung gestellte Datensätze, die zumindest den Transaktionscode und den Zahlungsbetrag enthalten. Der Datensatz enthält in der Regel auch weitere den Zah- lungsvorgang 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 Kontonum- mer des Zahlungspflichtigen übersetzt, sondern es ist eine virtuelle 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 Schnittstelle 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 verwertba- ren 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.

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 Kassensysteme, 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 oder einer anderen Übertragungstechnologie am POS (Point of Sale) 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 Falle der vorübergehenden Nichterreichbarkeit der Zahlungsabwicklungsstelle im Kassensystem mit Hilfe eines Prüfalgorithmus dahingehend überprüfen, ob der Transaktionscode a) von der Zahlungsabwicklungs- stelle generiert wurde und b) im Rahmen des allgemeinen Zahlungslimits für Transaktionscodes liegt. Eine besonders bevorzugte Ausführungsform ergibt sich hierbei, wenn der Prüfalgorithmus und der für die Generierung des Transaktionscode ver- wende 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 aus- schließ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 verwendete 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 Zahlungsabwicklungs- stelle generiert wird.

Es ist denkbar, dass das jeweilige Zahlungslimit vom Zahlungspflichtigen bei jedem Zahlungsvorgang zur Verfügung gestellt wird, 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. Besonders bevorzugt ist es, wenn das in der Zahlungsabwicklungsstelle einer Teilnehmer- kennung zugeordnete Zahlungslimit mit einem der jeweiligen Teilnehmerkennung 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 auf 0 gesetztes Zahlungslimit dem der Teilnehmerkennung entsprechenden mobilen Telekommunikationsendgerät derart wei- tergegeben wird, dass das Telekommunikationsendgerät keinen neuen Transaktionscode übermittelt erhält und der schon bestehende Transaktionscode auf der Programmapplikation gelöscht wird. Zur weiteren Erhöhung der Sicherheit ist bevorzugt vorgesehen, dass die Applikation den Transaktionscode vor dessen Übermittlung an das Kassensystem aus einem Speicher lädt und beim Laden des Transaktionscodes ein Zeitstempel generiert wird, der an die Zahlungsabwicklungsstelle übermittelt und dem Transaktions- code zugeordnet gespeichert wird und dass die Autorisierung des Transaktionscodes in der Zahlungsabwicklungsstelle gemäß Schritt f) den Vergleich des Zeitstempels mit der aktuellen Uhrzeit umfasst, wobei Freigeben der Zahlung gemäß Schritt h) unter der zusätzlichen Bedingung erfolgt, dass die Differenz zwischen der aktuellen Uhrzeit und dem Zeitstempel einen definierten Wert nicht übersteigt. Beim Öffnen eines Transaktionscodes in der Programmapplikation wird somit zusätzlich ein Zeitstempel erstellt und an die Zahlungsabwicklungsstelle gemeldet. Dieser Zeitstempel wird in der Datenbank abgelegt. Transaktionscodes haben eine definierte Gültigkeitsdauer. Die Zahlungsabwicklungsstelle kann anhand des Zeitstempels Transaktionscodes abweisen, die diese Gültigkeitsdauer überschritten haben. 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 entspre- chend benutzerfreundliche und ansprechende Benutzeroberfläche zur Verfügung stellen. In die Programmapplikation kann auch die Funktion der Kodierung der zu übermittelnden Daten implementiert sein, wobei ein entsprechend großflächiges Anzeigeelement auch die bevorzugt vorgesehene Anzeige eines Strichcodes ermög- licht. 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 der Übermittlung des Transaktionscodes 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: a) Die Applikation erhält den Transaktionscode zu einem Zeitpunkt, zu dem das Mobiltelefon online ist - unter Umständen schon lange bevor die Applikation zur Zahlung aktiviert wird.

b) Wenn der PIN in der Applikation eingegeben wird, wird bevorzugt nochmals geprüft, ob der in der Applikation schon bereit gehaltene Transaktionscode mit dem Zahlungslimit in Einklang steht. Wenn das Zahlungslimit zwischenzeitlich auf 0 gestellt wurde, so erhält die Applikation keinen neuen Transaktionscode und der auf der Applikation verfügbare Transaktionscode wird gelöscht. Die Applikation ist in diesem Fall nicht mehr zur Zahlung einsetzbar.

c) Wenn das Zahlungslimit veraltet ist, wird der alte Transaktionscode durch einen Neuen ersetzt.

d) Wenn keine Onlineverbindung zum Zeitpunkt der PIN-Eingabe verfügbar ist, wird der bereit gehaltene Transaktionscode verwendet .

Mobiletelefone können im Vergleich zu Stand-Computern oder Notebooks relativ leicht entwendet werden und verfügen meist nicht über Sicherheitseinrichtungen wie zum Beispiel Firewalls. Damit bietet das Mobiltelefon mehr Angriffsfläche für Hacker und eine leichtere Auslesbarkeit des gespeicherten Inhalts, wie z.B. sensible Daten. Um sicherzustellen, dass die Programmapplikation am Mobiltelefon nicht manipuliert, kopiert oder missbräuchlich verwendet wird, ist in bevorzugter Weise vorgesehen, dass bei der Generierung eines Transaktionscodes gemäß Schritt a) ein Prüfcode generiert und dem Transaktionscode zugeordnet gespeichert wird, dass bei der Übermittlung des Transaktionscodes an das mobiles Telekommunikationsendgerät gemäß Schritt c) gleichzeitig der Prüfcode übermittelt wird, dass mit der Anforderung eines neuen Transaktionscodes durch die mobile Telekommunikationsendgerät an die Zahlungsabwick- lungsstelle der Prüfcode an die Zahlungsabwicklungsstelle rückübermittelt wird, dass der Prüfcode in der Zahlungsabwicklungsstelle mit dem dort gespeicherten Prüfcode verglichen wird und die Übersendung des neuen Transaktionscodes an das mobile Telekommunikationsendgerät freigegeben wird, wenn der rückübermittelte und der gespeicherte Prüfcode übereinstimmen. Bei dem Prüfcode handelt es sich mit Vorteil um einen 72stelligen Hexa- dezimalwert, der in der Zahlungsabwicklungsstelle erstellt wird und auf dem mobilen Telekommunikationsendgerät in einem sicheren Element abgelegt wird. Der Prüfcode stellt einen Identifizierungsparameter der Programmapplikation für die Zahlungsab- wicklungsstelle dar, der sich mit jeder Abfrage ändert, die Funktionsfähigkeit der Programmapplikation belegt und die Unversehrtheit der Programmapplikation (nicht manipuliert, nicht gehackt, Programmapplikation wurde nicht auf anderes Mobiltelefon verlegt) belegt.

Um sicherzustellen, dass die Programmapplikation auch funktioniert, wenn das mobile Telekommunikationsendgerät keine Datenverbindung hat, kann die Programmapplikation mehr als einen Transaktionscode in einem sicheren Element am Mobiltelefon ab- speichern. Die abgelegten Transaktionscodes werden nach dem Prinzip "First In - First Out" von der Programmapplikation aufgerufen. Wenn das Mobiltelefon wieder eine Datenverbindung aufbauen kann, wird das "Transaktionscode - Lager" am Mobiltelefon wieder aufgefüllt. In diesem Zusammenhang wird das erfindungs- gemäße Verfahren bevorzugt so durchgeführt, dass in den Schritten a) , b) und c) jeweils wenigstens zwei Transaktionscodes generiert, übermittelt und im mobilen Kommunikationsendgerät gespeichert werden. 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 Teilnehmerkennungen von mobilen Telekommunikationsendgeräten und den Teilnehmerkennungen zugeordnete Zahlungslimits gespeichert hat, einen Transaktionscodegenerator, der einen für den jewei- ligen Zahlungsvorgang spezifischen Transaktionscode unter Verwendung eines Algorithmus generiert, und Übertragungsmittel zum Übermitteln des Transaktionscodes an das mobile Telekommunikationsendgerät aufweist, und wobei das Kassensystem ausgebildet ist, um den im Rahmen eines bargeldlosen Zahlungsvorganges von einem mobilen Telekommunikationsendgerät übermittelten Transaktionscode zu empfangen, wobei das Kassensystem Eingabemittel aufweist, um einen Zahlungsbetrag einzugeben, wobei das Kassensystem weiters Übertragungsmittel aufweist zum Übertragen eines Datensatzes umfassend den Transaktionscode und den Zahlungsbetrag an die Zahlungsabwicklungsstelle, wobei die Zahlungsab- wicklungsstelle Verarbeitungsmittel aufweist, die ausgebildet sind, um den erhaltenen Transaktionscode zu autorisieren und um das dem Transaktionscode zugeordnete Zahlungslimit zu ermit- teln, wobei die Zahlungsabwicklungsstelle 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 die Zahlungsabwicklungsstelle weiters einen Speicher auf- weist zum Speichern der freigegebenen Zahlung, wobei der Speicher mit Übertragungsmittel zusammenwirkt, um die Zahlung später oder sofort zur Veranlassung eines Abbuchungsauftrages weiterzugeben . Bevorzugte Weiterbildungen der erfindungsgemäßen Vorrichtungen sind in den Unteransprü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 be- finden. 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 Zahlungsabwicklungsstelle ist mit 7 bezeichnet und umfasst einen Zahlungsserver 8 sowie eine Datenbank 9. Die Zahlungsabwicklungsstelle 7 kann eine Datenverbindung sowohl zum Kassensystem 1 als auch zum mobilen Telekommunikationsendgerät 5 aufbauen.

Weiters ist die Zahlungsabwicklungsstelle 7 an einen Austauschserver 10 angebunden, der wiederum mit einer Bank 11 oder ent- sprechenden elektronischen Bankennetzwerken in Verbindung steht .

Die Abwicklung einer bargeldlosen Zahlung gemäß der vorliegen- den 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 bar- geldlose 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 mittels einer PIN-Abfrage. Die Programmapplikation stellt auf der Anzeigeeinheit des mobilen Te- lekommunikationsendgeräts 5 einen Einmalbarcode dar, der von einem Barcodeleser der Registrierkasse 2 eingelesen wird. Der auf diese Art und Weise übermittelte Transaktionscode wird von dem Kassensystem 3 an die Zahlungsabwicklungsstelle 7 übermit- telt und dort überprüft. Für den Fall, dass die Zahlungsabwicklungsstelle 7 nicht erreichbar ist, wird der Transaktionscode in der Programmerweiterung 4 auf Validität geprüft. Wenn die Überprüfung positiv abgeschlossen werden konnte, wird der Bar- code als Zahlung angenommen und der Zahlungsbetrag wird in der Folge vom Bankkonto des Kunden eingezogen.

Um den oben beschriebenen bargeldlosen Zahlungsvorgang zu ermöglichen, ist die technische Umsetzung wie folgt vorgesehen. Die Bank 11 ist über den Austauschserver 10 mit der Zahlungsabwicklungsstelle 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 gemeinsam 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 Teilnehmerkennung übermittelt. Dies führt dazu, dass die Zahlungsabwicklungsstelle 7 über keine realen Kontodaten des Bankkunden verfügt, sodass die in der Zahlungsabwicklungsstelle 7 vorhan- denen 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 Zahlungsab- wicklungsstelle 7. Sofern sich das Zahlungslimit eines Kunden in der Folge ändert, kann die Bank 11 jederzeit ein neues Zah- lungslimit an die Zahlungsabwicklungsstelle 7 über den Schnittstellenserver 10 senden.

Die Zahlungsabwicklungsstelle · 7 hat die Teilnehmerkennung und das jeweils zugeordnete Zahlungslimit in der Datenbank 9 ge- speichert. 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 Transaktionscodes erstellt werden können. Zur Vorbereitung eines bargeldlosen Zahlungsvorganges mit Hilfe des mobilen Telekommunikationsendgeräts 5 generiert der Zahlungsserver 8 einen Transaktionscode und speichert diesen so, dass dieser einer Teilnehmerkennung und dem jeweiligen Zahlungslimit zugeordnet ist. Dann übermittelt der Zahlungsserver 8 den Transaktionscode an die Pro- grammap likation 6 des mobilen Telekommunikationsendgeräts 5 in Form eines Barcodes, wobei überprüft wird, ob die Teilnehmerkennung der Programmapplikation derjenigen Teilnehmerkennung entspricht, die dem zu übertragenden Transaktionscode im Zahlungsserver als zugeordnet gespeichert ist. Die Datenübertra- gung kann entweder auf Anfrage der Programmapplikation 6 erfolgen oder durch den Zahlungsserver 8 veranlasst sein.

Die Programmapplikation 6 stellt in der Folge den Transaktionscode in Form eines Barcodes auf der Anzeigeeinheit des mobilen Telekommunikationsendgeräts 5 dar. Die Registrierkasse 2 scannt den angezeigten Barcode mit Hilfe eines Barcodescanners ein und übermittelt diesen gemeinsam mit dem gewünschten Zahlungsbetrag an den Kassenserver 3. Die im Kassenserver 3 implementierte Programmerweiterung 4 leitet den übermittelten Transaktionscode und den Zahlungsbetrag zur Prüfung an die Zahlungsabwicklungs- stelle 7 weiter. In der Zahlungsabwicklungsstelle 7 wird dann überprüft, ob der vom Kassensystem erhaltene Transaktionscode einen im Zahlungsserver gespeicherten Transaktionscode entspricht. Wenn dies der Fall ist, wird das dem im Zahlungsserver gespeicherten Transaktionscode zugeordnete Zahlungslimit ermittelt und überprüft, ob der gewünschte Zahlungsbetrag innerhalb des Zahlungslimits liegt. Wenn beide Prüfungen positiv abgeschlossen worden sind, meldet die Zahlungsabwicklungsstelle 7, dass die Zahlung angenommen werden kann. Im Falle, dass die Zahlungsabwicklungsstelle vom Kassensystem aus nicht erreichbar ist, kann die Programmerweiterung 4 anhand eines lokal gespeicherten Prüfalgorithmus überprüfen, ob der übermittelte Transaktionscode von der Zahlungsabwicklungsstelle generiert wurde und ob der Zahlbetrag innerhalb des allgemeinen Zahlungslimits liegt. Nach positiver Überprüfung der Zahlung meldet das Kassensystem 3 bzw. die Programmerweiterung 4 an die Registrierkasse 2, dass die Zahlung angenommen werden kann. Sobald die Datenverbindung zwischen dem Kassensystem 3 und der Zahlungsabwicklungsstelle wieder hergestellt ist, werden die zahlungsrelevanten Daten der freigegebenen Zahlungen an die Zahlungsabwicklungsstelle 7 zur Veranlassung von Abbuchungsaufträgen weitergegeben. Das Kassensystem 3 ist mit dem Zahlungsserver 8 verbunden, wodurch der im Kassensystem 3 gespeicherte Prüfalgorithmus jederzeit geändert werden kann.

Sofern die Zahlung freigegeben wurde, wird der Transaktionscode sowie zusätzlich der Zahlungsbetrag und weitere zahlungsrelevante Daten wie beispielsweise eine Identifizierung der Regist- rierkasse und des Händlers in der Datenbank 9 abgespeichert. 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 Zahlungsabwicklungsstelle 7 einen Datensatz enthaltend die Teilnehmerkennung, den Zahlungsbetrag und eine Identifizierung des Händlers und ggf. weiters den Zeitstempel, eine Rech- nungsnummer 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 entspre- chendes 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.