Stand der Technik Aus US 2009/0222353 AI und GB 2 362 012 A sind Zahlungssysteme bekannt, welche bargeldlos erfolgen und zu deren Implementierung ein Mobiltelefon benutzt wird.

Den obenstehend skizzierten Lösungen gemäß US 2009/0222353 AI und gemäß GB 2 362 012 A wohnt der Nachteil inne, dass die gemäß dieser Systeme abgewickelten Transaktio- nen mit einer erheblichen Unsicherheit behaftet sein können. Dies hat seine Ursache darin, dass die Überprüfungsroutinen gemäß der Lösungen GB 2 362 012 A bzw. US 2009/0222353 AI nicht oder nur in einem einmaligen Durchlauf auf Plausibilität untersucht werden. Offenbarung der Erfindung

Der vorliegenden Erfindung liegt die Aufgabe zugrunde, ein hochsicheres, bargeldloses Zahlungs- und Transaktionssystem für einen oder mehrere Benutzer zur Verfügung zu stellen.

Erfindungsgemäß wird ein bargeldloses Zahlungssystem vorgeschlagen, bei dem an Stelle der bisher eingesetzten Kreditkarte, in der Regel eine Kreditkarte oder eine EC- Karte aus Kunststoffmaterial, das Mobiltelefon tritt. Der Bezahlvorgang erfolgt nun anhand eines Authentifizierungsprozesses mittels eines Barcodes oder eines anderen opti- schen/grafi sehen oder elektromagnetischen wie z.B. das NFC-Verfahrtens (NFC = Near Field Communication) oder auf Schall basierenden Identifikationssignais für das Mobiltelefon bzw. einen PDA (Personal Digital Assistant) oder für ein anderes Kommunikationsgerät. Weiterhin können auch zwischen zwei Nutzern Transaktionen ausgeführt werden, wobei gegenseitiges Einscannen der Mobiltelefone bzw. PDAs oder anderer Kommunika- tionsgeräte denkbar ist. Die Authentifizierung bzw. die Identifikation über einen Barcode oder per NFC-Verfahren, oder über ein anderes optisches/grafisches oder elektromagnetisches oder auf Schall basierendes Identifikationssignal in Kombination mit einem Mobilte- lefon oder einem PDA kann auch für andere Zwecke genutzt werden, so z.B. als Kundenkarte oder zum Identifizieren von Mitarbeitern.

Der erfindungsgemäß vorgeschlagene Transaktionsprozess beginnt damit, dass ein Bar- code oder ein anderes diesem entsprechendes optisches oder grafisches, elektromagnetisches oder auf Schall basierendes Signal von einem Benutzer manuell oder automatisch über das Mobiltelefon, den Personal Digital Assistant (PDA) oder ein anderes Kommunikationsgerät angefordert wird. Bei einem NichtZustandekommen einer Funknetzwerkverbindung, so z.B. innerhalb gut nach außen isolierter Gebäude, wird eine drahtlose Verbin- dung mit dem Transaktionsterminal aufgebaut, welches eine gesicherte Verbindung des Mobiltelefons, des PDAs oder des anderen Kommunikationsgerätes mit dem zentralen Systemserver sicherstellt. Über diese bei fehlender Funknetzwerkverbindung hergestellte sichere drahtlose Verbindung wird ein Barcode oder eine andere Identifikation über diese Verbindung angefordert.

Der Barcode oder das andere optische/grafische oder elektromagnetische Informationsbzw. Identifikationssignal (z.B. NFC) wird vom zentralen Systemserver generiert und an das anfordernde Mobiltelefon bzw. den anfordernden PDA bzw. das anders ausgestaltete anfordernde Kommunikationsgerät gesandt. Der Barcode oder ein alternatives opti- sches/grafisches oder elektromagnetisches Signal wird am Transaktionsterminal, so z.B. einem modifizierten Kartenlesegerät, wie es heute vielfältig zum Einsatz kommt, gescannt bzw. ausgelesen. Die generierte ausgelesene bzw. gescannte Identifikation wird zusammen mit Transaktionsinformationen an den zentralen Systemserver übermittelt. Der Barcode kann auch als Zahlenkombination auf dem Display des Mobiltelefons dargestellt werden. Hierdurch ist die Nutzung des mobilfunkbasierten Transaktionssystems auch dann möglich, wenn das Transaktionsterminal keine Leseeinheit für Barcodes besitzt bzw. diese beschädigt ist.

In einem dritten Schritt überprüft dieser zentrale Systemserver, der den Barcode bzw. die andere Identifikation generiert hat, die Identifikation, die Transaktionsinformationen, Sicherheitskriterien, so z.B. Ort und Zeit, und eventuell andere Restriktionen, so z.B. ein möglicherweise bestehendes Transaktionslimit, so z.B. ein Kontolimit bei einem Kreditinstitut. Der zentrale Systemserver sendet die Transaktionsanfrage über die Funknetzverbindung oder bei NichtZustandekommen über die geschützte drahtlose Verbindung über das Transaktionsterminal an den anfordernden Benutzer (User). Dieser bestätigt die Transaktion oder lehnt sie ab. Bei Bestätigung wird die Transaktion ausgeführt und als ausgeführt an das Transaktionsterminal gesendet. Bei Ablehnung durch den Benutzer (User) erfolgt ein Abbruch der Transaktion. Alternativ kann der Transaktionsprozess auch wie folgt dargestellt werden. Der Barcode oder das andere optische/grafische oder elektromagnetische Informations- bzw. Identifikationssignal wird direkt im Mobiltelefon bzw. dem PDA bzw. einem anders ausgestalteten Kommunikationsgerät generiert. Der Barcode oder ein alternatives optisches/grafisches oder elektromagnetisches Signal wird dann am Transaktionsterminal, so z.B. einem modifizierten Kartenlesegerät, wie es heute vielfältig zum Einsatz kommt, gescannt bzw. ausgelesen. Die generierte ausgelesene bzw. gescannte Identifikation wird zusammen mit Transaktionsinformationen an den zentralen Systemserver übermittelt.

In einem weiteren Schritt überprüft dieser zentrale Systemserver, der auf die gleiche Art und Weise den Barcode generiert wie das Mobiltelefon, die vom Transaktionsterminal übermittelte Identifikation, die Transaktionsinformationen, Sicherheitskriterien, so z.B. Ort und Zeit, und eventuell andere Restriktionen, so z.B. ein möglicherweise bestehendes Transaktionslimit, so z.B. ein Kontolimit bei einem Kreditinstitut. Der zentrale Systemserver sendet die Transaktionsanfrage an das Transaktionsterminal zur Bestätigung zurück. Der Benutzer bestätigt die Transaktion oder lehnt sie ab. Zur Bestätigung kann der Benutzer z.B. eine PIN-Nummer am Transaktionsterminal eingeben. Die Eingabe einer PIN- Nummer am Transaktionsterminal kann entweder direkt nach dem Scannen des Barcodes erfolgen oder erst nachdem der zentrale Systemserver die vom Transaktionsterminal übermittelte Identifikation, die Transaktionsinformationen und Sicher-heitskriterien überprüft hat. Alternativ kann der Benutzer auch am Mobiltelefon bzw. PDA einen PIN-Code eingeben bevor der Barcode generiert wird. Bei Bestätigung wird die Transaktion ausgeführt und als ausgeführt an das Transaktionsterminal gesendet. Bei Ablehnung durch den Benutzer (User) erfolgt ein Abbruch der Transaktion. Dieser Transaktionsprozess ist insbesondere dann vorteilhaft, wenn sich der Benutzer im Ausland aufhält und somit hohe Gebühren für die Datenkommunikation zwischen dem zentralen Systemserver und dem Mobiltelefon anfallen würden.

Der obenstehend kurz skizzierte, im Wesentlichen dreistufig ablaufende Transaktionsprozess ist mit verschiedenen Sicherheitsstufen unterlegt. So wird in einer ersten Sicherheits- stufe der vom zentralen Systemserver generierte Barcode oder alternativ das andere grafische/optische oder elektromagnetische Signal im Systemserver generiert und die Gültigkeit des generierten Barcodes oder der alternativen Identifikation zeitlich begrenzt. Die zeitliche Begrenzung kann z.B. auf 300 Sekunden limitiert sein. Alternativ erfolgt, wie zuvor beschrieben, die Generierung des Barcodes innerhalb des Mobiltelefons bzw. PDA oder einem anders ausgestalteten Kommunikationsmittel.

In einer 2. Sicherheitsstufe kann über ein Ortungssystem, wie z.B. das Global Positioning System (GPS) oder ein anderes satellitengestütztes Ortungssystem, der Standort des Benutzers (Users) mit dem Ort, an dem die Identifikation gewünscht ist, sei es eine Kasse, sei es ein anderes Identifikationsterminal, abgeglichen werden. Neben dem GPS kommt auch eine Ermittlung des Standortes des Benutzers (Users) über das Funknetz in Frage, so z.B. über das Netz, in dem das Mobiltelefon Kommunikationsdienstleistungen erbringt. Stimmen der Standort des Benutzers und der Ort der Identifikation nicht überein, wird die Transaktion abgelehnt. Weiterhin erfolgt eine Ablehnung der Transaktion dann, wenn die Entfernung zwischen zwei oder mehreren Identifikationsorten zu groß ist, um in einer definierten Zeitspanne zurückgelegt werden zu können. Innerhalb der 2. Sicherheitsstufe zur Abwicklung des vorstehend skizzierten dreistufigen Transaktionsprozesses lässt sich der Standort des Benutzers entweder bei Bedarf, d.h. willkürlich, kontinuierlich oder in wohldefinierten Zeitabständen ermitteln, was die Plausibili- tät eines Abgleiches des Standortes, d.h. des Aufenthaltsortes des Benutzers mit dem Ort, an dem die Identifikation erfolgen soll, zusätzlich plausibilisiert und die Aussagefähigkeit drastisch erhöht.

Innerhalb dieser zweiten Sicherheitsstufe lässt sich über das satellitengestützte Ortungssystem, wie z.B. das Global Positioning System (GPS), oder ein anderes satellitengestütztes Ortungssystem der Standort des Benutzers ermitteln. Alternativ zum satellitengestützten Ortungssystem kann der Standort des Benutzers über das Funknetz, in dem das Mobiltelefon oder der PDA des Benutzers eingebunden ist, über das dementsprechende Funknetz bzw. Mobilfunknetz ermittelt werden. Befindet sich der Benutzer - je nach Sichtweise - innerhalb oder außerhalb eines definierten geographischen Ortes, kann die angeforderte Transaktion abgelehnt werden. Definitionssache ist die Lokalisierung des Benutzers, der sich entweder innerhalb oder außerhalb eines definierten geographischen Ortes befinden muss, um die Plausibilisierung der angeforderten Transaktion durchzuführen.

In einer weiteren, und hinterlegten 3. Sicherheitsstufe ist ein Diebstahlschutz implementiert. Der Diebstahlschutz bezieht sich vor allem auf den Diebstahl des Kommunikations- gerätes, d.h. im vorliegenden Falle auf den Diebstahl des Mobiltelefons oder den des PDAs (Personal Digital Assistant). In einer ersten Ausführungsmöglichkeit eines zu implementierenden Diebstahlschutzes wird die Eingabe einer ΡΓΝ bei Bestätigung der Transaktion gefordert. Alternativ dazu besteht die Möglichkeit, ein separates Freischaltmodul, welches der Benutzer stets bei sich trägt, zu betätigen, welches z.B. durch ein Bluetooth-Dongle oder ein RFID-Chip dargestellt sein kann. In einer weiteren, dritten Ausführungsmöglichkeit des obenstehend innerhalb der Sicherheitsstufe 3 implementierten Diebstahlschutzes besteht die Möglichkeit, ein Foto des Benutzers auf dem Transaktionsterminal anzuzeigen. Dies bedeutet, dass der zentrale Server ein dort hinterlegtes Foto des Benutzers an das betreffende, die Identifikation vor Ort durchführende Transaktionsterminal sendet. Schließ- lieh besteht eine Möglichkeit zur Identifikation darin, dass eine Identifikation anhand persönlicher Identifikationsmerkmale durchgeführt wird, so z.B. ein Scannen von Fingerabdrücken oder der Iris des Auges an dem entsprechenden Transaktionsterminal vorgenommen wird. Ein Vergleich der am Transaktionsterminal eingescannten Daten mit den Daten, die auf dem zentralen Server gespeichert sind, führt sehr schnell zu einer aussagekräftigen Identifikation oder Nicht-Identifikation.

In einer weiteren vorteilhaften Ausgestaltung des erfindungsgemäß vorgeschlagenen bargeldlosen Zahlungssystems kann die Zahlungsfähigkeit auch dann erhalten werden, wenn keine Funkverbindung zwischen dem Mobiltelefon bzw. dem PDA oder einem anderen elektronischen Kommunikationsgerät zu einem regulären Funknetz besteht. In diesem Falle wird über eine Datenfunkverbindung, so z.B. Bluetooth, eine Verbindung zum Kassenterminal hergestellt, über welches dann eine direkte Verbindung mit dem zentralen Server, der über das reguläre Funknetz nicht erreichbar war, hergestellt wird. In diesem Falle dient z.B. ein Kassenterminal als Datenfunkverbindung zum Server. Alternativ kann auch hier die zuvor beschriebene Ausführungsvariante eingesetzt werden, bei der ein Barcode im Mobiltelefon bzw. PDA oder einem anderen Kommunikationsgerät generiert und dann gescannt wird. Bei dieser Ausführungsvariante kann gänzlich auf eine direkte Verbindung zwischen Mobiltelefon und Server verzichtet werden.

Der erfindungsgemäß vorgeschlagenen Lösung folgend, können auch Transaktionen zwischen mehreren Benutzern durch gegenseitiges Einscannen des Barcodes oder des anderen grafischen oder optischen Identifikationsmerkmals ausgeführt werden. Dazu besteht lediglich das Erfordernis, dass das Mobiltelefon bzw. der Personal Digital Assistant eine Kame- ra aufweist. In dieser Hinsicht ist zu festzuhalten, dass die Sicherheit wieder durch die Position gegeben ist, da beim Scannen eines Barcodes von einem Gerät A auf ein Gerät B beide Geräte die gleiche Position haben müssen.

In einer weiteren vorteilhaften Ausführungsmöglichkeit einer Abwicklung von Transaktio- nen, kann unter Einbindung des Internets der zentrale Server einen Barcode oder ein anderes geeignetes optisches oder elektromagnetisches Signal an eine Website senden. Der Benutzer scannt eben diesen Barcode, der am Monitor eines Transaktionsterminals dargestellt ist, vom Bildschirm desselben ab. Dazu benutzt der Benutzer sein Mobiltelefon, welches den eingescannten Barcode an den zentralen Server sendet. Dieser wiederum sendet die Zahlungsanfrage an das Mobiltelefon, wo diese noch vom Benutzer zu bestätigen ist, bevor die Transaktion ausgeführt wird.

Die erfindungsgemäß vorgeschlagenen Transaktionen können sowohl im Einzel- als auch im Mehrbenutzermodus durchgeführt werden. Dazu kann ein Benutzer ein Einzelbenutzer- konto eröffnen oder auch ein Mehrbenutzerkonto anlegen. Bei einem Mehrbenutzerkonto, welches insbesondere für Firmen, Behörden und Familien interessant sein kann, können über ein Hauptkonto mehrere Benutzerkonten verwaltet werden. Der Benutzer kann über eine dementsprechend konfigurierte Website im Internet das Benutzerkonto, sei es ein Ein- zelbenutzer-, sei es ein Mehrbenutzerkonto, verwalten, geographische und zeitliche Limitierungen setzen. Der Benutzer kann für Orte und Zeiten Transaktionslimitierungen setzen, die sowohl für ein Einzelbenutzerkonto als auch ein Mehrbenutzerkonto gültig sind.

Der Barcode oder ein NFC-Signal kann z.B. als Bilddatei zwischen den einzelnen Parteien ausgetauscht werden oder in Form von Daten, die dann vom Client in einen Barcode umgewandelt werden können. Die obenstehend beschriebenen Sicherheitsstufen 1 bis 3 ermöglichen eine Zwei-Faktoren-Authentifizierung auf Basis der Faktoren "Wissen" und "Besitzen". Unter Verweis auf eine EC-Karte sei hier ausgeführt, dass der Faktor "Wissen" durch persönliche Geheimzahl (PIN) und der Faktor "Besitzen" durch die "EC-Karte" ge- bildet wird. Nur durch die Kombination der beiden Faktoren ist es möglich, am Geldautomaten Geld abzuheben oder an EC-Terminals zu bezahlen.

Insbesondere im IT-Bereich etablierten sich in den vergangenen Jahren verschiedene Zwei- Faktoren- Authentifizierungssysteme, die Nutzern z.B. sicheren Zugang zu Firmennetzwer- ken oder Software-Anwendungen geben. Dazu wird ein Einmal-Passwort generiert, welches in Verbindung mit der PIN den Nutzer autorisiert. Das Einmal-Passwort wird entweder über einen handlichen Passwort-Generator (Client) oder unter Zwischenschaltung einer Software generiert. Voraussetzung für das Einmal-Passwort-Verfahren ist, dass beide Beteiligten, d.h. Client und Server, ein gemeinsames, geheimes Kennwort haben. Aus diesem gemeinsamen geheimen Kennwort wird nun eine Reihe von Einmal-Passwörtern (One Time Passwords: OTP's) erzeugt.

Grundsätzlich kann bei diesen Systemen zwischen drei verschiedenen Typen differenziert werden:

A Zeitsteuerung

Bei diesem Typ berechnen Server und Client in festgestellten Zeitintervallen immer neue Passwörter. Obwohl der Server jeweils dieselbe Berechnung wie der Client ausführt, ak- zeptiert und berechnet der Server im Allgemeinen innerhalb eines Toleranzbereiches mehrere Einmal-Kennwörter. Dadurch kann dem Umstand Rechnung getragen werden, dass die im Token eingebaute Uhr eventuell nicht hundertprozentig synchron geht. Dennoch hat jedes Einmal-Kennwort ein genau definiertes Zeitintervall für seine Gültigkeit, im Regelfall zwischen 1 bis maximal 15 Minuten. B Ereignissteuerung

Bei ereignisgesteuerten Verfahren führt der Server wie beim zeitgesteuerten Verfahren dieselbe Berechnung aus, die auf der Client-Seite bereits stattgefunden hat, und auch hier berechnet und akzeptiert der Server in einem Toleranzbereich mehrere Einmai- Kennwörter, ausgenommen bereits verwendete Einmal-Kennwörter. Der Grund dafür liegt darin, dass der Besitzer gelegentlich ein generiertes Kennwort nicht verwenden könnte. Dieses Verfahren ist viel schonender für die Batterien eines entsprechenden Gerätes (To- ken). Es besteht auch die Möglichkeit, das Verfahren ohne permanente Stromversorgung zu betreiben, indem einfach der letzte verwendete und damit ohnehin entwertete Wert gespeichert wird.

C Anforderungs-Antwort- Verfahren

Synchronisationsprobleme gibt es im Falle des Anforderungs-Antwort-Verfahrens nicht. Bei diesem Verfahren gibt der Server eine Aufgabe, d.h. die Anforderung vor, die der Client beantworten muss (Antwort). Der Client enthält also einen Wert des Servers als Eingabe und berechnet darauf basierend ein Einmal-Kennwort.

Die Implementierung der Zwei-Faktoren-Authentifizierung in das Transaktionssystem, Stichwort "Wissen" und "Besitz", erfolgt wie folgt:

In einer ersten Variante sendet die Applikation auf dem Mobiltelefon, den Client darstel- lend, neben der Nutzer-ID auch ein Einmal-Passwort an den Server. Daraus generiert der Server einen Barcode, den er wieder an den Client sendet. Der Barcode wird dann am Transaktionsterminal gescannt und zusammen mit den Transaktionsdaten an den Server verschickt. Der Server sendet dann eine Zahlungsanfrage an den Client, die vom Nutzer durch Eingabe der ΡΓΝ bestätigt wird. Zur Beschleunigung der Transaktion kann bis zu einem zuvor festgelegten Betrag auf die Eingabe der PIN verzichtet werden.

In einer weiteren vorteilhaften Ausführungsvariante sendet die Applikation auf dem Mobiltelefon, welches den Client darstellt, die Nutzer-ID an den Server. Daraus generiert der Server Daten für einen Barcode, der wiederum an den Client retour gesendet wird. Der Client erweitert diese Barcode-Daten durch ein Einmal-Passwort und generiert den endgültigen Barcode. Dieser wird dann am Transaktionsterminal gescannt und zusammen mit den Transaktionsdaten an den Server übermittelt. Der Server vergleicht die Daten des Barcodes mit den zuvor gesendeten Daten und dem Einmal-Passwort. Danach sendet der Server eine Zahlungsanfrage an den Client, die vom Benutzer durch Eingabe der PIN bestätigt wird. Die PIN kann entweder am Client oder am Transaktionsterminal eingegeben werden. Zur Beschleunigung der Transaktion kann bis zu einem zuvor festgelegten Betrag auf die Eingabe der PIN verzichtet werden. In einer weiteren vorteilhaften Ausführungsvariante generiert die Applikation auf dem Mobiltelefon, welches den Client darstellt, einen Barcode aus der persönlichen Benutzer- ID und einem Einmal-Kennwort. Wie zuvor beschrieben, berechnet der zentrale Systemserver parallel das gleiche Einmal-Kennwort. Der generierte Barcode wird dann am Transaktionsterminal gescannt und zusammen mit den Transaktionsdaten an den Server übermit- telt. Der Server vergleicht das in den Daten des Barcodes enthaltene Einmal-Passwort mit dem für diesen Benutzer berechneten Einmal-Passwort. Stimmen beide Einmal-Passwörter überein und die Überprüfung weiter Sicherheitskriterien (Transaktionslimit, Positionsbestimmung) war positiv, sendet der Server danach eine Zahlungsanfrage entweder an den Client oder an das Transaktionsterminal, die vom Benutzer durch Eingabe der PIN bestä- tigt wird. Die PIN kann entweder am Client oder am Transaktionsterminal eingegeben werden. Zur Beschleunigung der Transaktion kann bis zu einem zuvor festgelegten Betrag auf die Eingabe der PIN verzichtet werden. Alternativ kann die PIN auch schon zu Beginn im Mobiltelefon eingegeben werden, um z.B. die Generierung des Barcodes zu starten. Zusätzlich kann innerhalb dieser Ebene eine weitere Sicherheitsüberprüfung eingebaut werden. Da die Berechnung des Einmal-Kennwortes parallel im Mobiltelefon als auch im Systemserver erfolgt, kann hierdurch auch die Identität des Servers überprüft werden. Um diesen Schutzmechanismus zusätzlich zu implementieren, sendet der Server während des Transaktionsprozesses ein Einmal-Kennwort an das Mobiltelefon. Da dieses mit dem vom Mobiltelefon zu diesem Zeitpunkt berechneten Einmal-Kennwort übereinstimmen muss, kann das Mobiltelefon sicher überprüfen, ob es sich um "echten" Systemserver handelt.

In einer weiteren, dritten Sicherheitsebene neben den ersten beiden vorstehend skizzierten standardmäßig implementierten Sicherheitsebenen kann eine nutzerbezogene Sicherheits- ebene eingezogen werden. Hierzu können entweder biometrische Merkmale des Benutzers abgeglichen werden, so z.B. Finger- oder Handabdrücke, Iris oder Gesicht, oder Informationen aus einem Ausweisdokument. Alternativ dazu kann hier auch ein Bluetooth-Dongle eingesetzt werden, welches die Anwendung im Client freischaltet oder aber gegebenenfalls eine RFID-Karte.

Aufgrund des Umstandes, dass insbesondere in Gebäuden oftmals eingeschränkte Funkverbindungen vorherrschen, stellt das Transaktionsterminal in diesem Fall eine Alternativverbindung bereit. Hierzu stellt die Client-Applikation eine Datenfunkverbindung zwischen dem Transaktionsterminal her, so z.B. Bluetooth, welche entweder eine konstante Verbindung zum Autorisierungsserver unterhält, so z.B. über das Internet, oder zur Autorisierung eine Wählverbindung aufbaut. Über diesen Datenkanal kommuniziert dann die Client-Applikation mit dem Server. Die Standortbestimmung ist in diesem Falle durch das Transaktionsterminal gegeben, die restlichen Bestandteile der Sicherheitsüberprüfung lau- fen wie vorstehend beschrieben ab.

In allen Ausführungsvarianten kann der Barcode auch als Zahlenkombination auf dem Display des Mobiltelefons dargestellt werden. Hierdurch ist die Nutzung des mobilfunkba- sierten Transaktionssystems auch dann möglich, wenn z.B. das Transaktionsterminal keine Leseeinheit für Barcodes besitzt bzw. diese beschädigt ist.

Im vorliegenden Zusammenhang wird gleichbedeutend der Applikation mit Mobiltelefon und Barcode noch eine Applikation mit dem Mobiltelefon und mit NFC (Near-Field- Communication) verstanden. Das NFC-Verfahren ist das gegenwärtig von den Kreditkar- ten-Unternehmen favorisierte Verfahren für kontaktloses Zahlen. Unter Near-Fild- Communication (NFC) wird ein Übertragungsstandard bezeichnet, der zum kontaktlosen Austausch von Daten über kurze Strecken dient. Mittels NFC soll der Austausch verschiedener Information wie z.B. Telefonnummern, Bildern, MP3-Dateien oder digitalen Berechtigungen zwischen zwei Geräten ermöglichen, die nahe aneinander- gehalten werden. NFC dient als Zugriffsschlüssel auf Inhalte und für Services wie bargeldlöse Zahlungen, Ticketbestellung, Online-Unterhaltung sowie auch für die Zugangskontrolle. Die notwendigen Sicherheitsfunktionen sind im Allgemeinen in der NFC-Hardware integriert.

Mit dem NFC-Verfahren kann im erfindungsgemäßen Zusammenhang das Mobiltelefon als

Zahlungsgerät benutzt werden, in dem die Benutzer des Mobiltelefons dieses nahe an ein Zahlungsterminal halten, so dass eben die Near-Field-Communication erfolgen kann. Die Zahlfunktion an einem Mobiltelefon erfordert eine Integration dieser in bestehende SIM- Karten-Infrastrukturen. Die NFC-Technik basiert auf der Kombination aus Smart-card und kontaktlosen Verbindungstechniken. Die NFC arbeitet in einem Frequenzbereich von 13,56 Megaherz und bietet eine Datenübertragungsrate von maximal 424 kBIT/Sek. Bei einer Reichweite von nur 10cm. Dies ist gewünscht, damit eine Kontaktaufnahme als Zustimmung zu einer Transaktion ausgelegt werden kann. NFC ist durch die ISO 14443, 18092, 21481 ECMA 340, 352, 356, 362 bzw. ETSI TS 102 und 190 standardisiert.

Die Kommunikation zwischen NFC-technikfähigen Geräten, d.h. Mobiltelefon und Zahlungsterminal kann sowohl aktiv-passiv, als auch aktiv-aktiv sein (Peer-to-Peer) im Gegensatz zur herkömmlichen Kontaktlos-Technik in diesem Frequenzbereich, der im allgemeinen nur aktiv-passiv abläuft. Die Nutzung des NFC-Verfahrens stellt somit eine Verbin- dung zu RFID-Umgebung dar. Der NFC-Standard ist größtenteils kompatibel mit weithin verwendeter verwendeter Smartcard-Infrastruktur basierend beispielsweise auf ISO/IEC 14443-A bzw. ISO/IEC 14443-B. Der NFC-Standard kann als Ersatz für Barcodes, z.B. beim elektronischen Ticketkauf oder wie erfindungsgemäß vorgeschlagen, zur Abwicklung von Zahlungstransaktionen eingesetzt werden, insbesondere da wo die nötigen Datenmengen nicht mehr in einer sinnvollen Anzahl von Barcodes übertragen werden können.

Bei NFC-Standard bietet sich alternativ zu Barcodes insbesondere dann an, wenn zwei Geräte kryptografisch gesichert, miteinander kommunizieren wie das bei Bezahlanwendungen in der Regel der Fall ist.

Kurze Beschreibung der Zeichnung

Anhand der Zeichnung wird die Erfindung nachstehend eingehender beschrieben.

Es zeigt:

Figur 1 den prinzipiellen Aufbau des erfindungsgemäß vorgeschlagenen Mehrebenen-Sicherheitssystems,

Figur 2 eine erste Ausführungsvariante einer Kommunikation zwischen einem

bilfunknetz, einem Transaktionsterminal und einem Systemserver,

Figur 3 eine weitere Ausführungsvariante eines Kommunikationsschemas zwischen

Mobilfunknetz, Transaktionsterminal und Systemserver,

Figur 4 eine Ausfuhrungsvariante einer Kommunikation zwischen einem Systemserver, einem Mobiltelefon und einem Transaktionsterminal, wobei das Transaktionsterminal eine normale Verbindung zum Systemserver aufrechterhält und eine davon verschiedene Funkverbindung zum Mobiltelefon und

Figur 5 den prinzipiellen Aufbau des erfindungsgemäß vorgeschlagenen

Mehrebenensicherheitssystems mit drei unterschiedlichen Zwei-Faktoren- Authentifizierungsverfahren.

Figur 6 eine Ausführungsvariante wenn das Mobiltelefon das Einmal-Kennwort und den Barcode ohne direkte Verbindung zum Systemserver berechnet.

Figur 7 eine Ausführungsvariante, die es dem Mobiltelefon ermöglicht, die Echtheit des Systemservers zu überprüfen und Figur 8 ein Mobiltelefon welches zur Übermittlung eines Barcodes einer Rechnung an ein Kreditinstitut benutzt wird. Ausführungsvarianten

Der Darstellung gemäß Figur 1 ist in schematischer Weise der Aufbau des Mehrebenen- Sicherheitssystems zu entnehmen. Im vorliegenden Zusammenhang wird NFC, d.h. Near-Field-Communication gleichbedeutend und austauschbar mit dem Begriff Barcode verwendet.

Innerhalb des erfindungsgemäß vorgeschlagenen mobilfunkbasierten Transaktionssystems zur Abwicklung eines bargeldlosen Zahlungsverkehrs werden sichere Transaktionen durch verschiedene Sicherheitsmechanismen auf mehreren Ebenen 12, 14, 20 gewährleistet. Die erste Ebene 12 und die zweite Ebene 14 ermöglichen mit ihren dort durchgeführten Prozessen die Erzeugung hochsicher ablaufender Transaktionen. Innerhalb der ersten Ebene 12 erfolgt die Zwei-Faktoren- Authentifizierung 18. Innerhalb der zweiten Ebene 14 erfolgt ein Standortabgleich 16 zwischen dem Standort des Nutzers, d.h. dem aktuellen Standort eines Mobiltelefons 36, welches mit einem Mobilfunknetz 32 kommuniziert, mit dem Standort eines Transaktionsterminals 34, an dem gerade eine aktuelle Transaktion abzuwickeln ist.

Optional umfasst das Mehrebenen-Sicherheitssystem 10 neben der ersten Ebene 12 und der zweiten Ebene 14 eine weitere, dritte Ebene 20. Während die ersten beiden Ebenen 12, 14 standardmäßig implementiert sind, kann die Sicherheit durch die weitere, nutzerbezogene dritte Ebene 20 erweitert werden. Dazu können innerhalb der dritten Ebene entweder biometrische Merkmale des Benutzers (Client) abgeglichen werden. Bei den biometrischen Merkmalen kann es sich z.B. um Finger- oder Handabdrücke, die Iris des Auges oder die Züge des Gesichtes handeln. Alternativ dazu können in der dritten Ebene Informationen aus einem amtlichen Ausweisdokument hinterlegt sein. Alternativ kann hier auch ein Blue- tooth-Dongle eingesetzt werden, welches die Anwendung im Client freischaltet oder aber eine RFID-Karte. Der Client überprüft, ob ein Bluetooth-Dongle bzw. die RFID-Card sich in der näheren Umgebung, so z.B. in der Hosentasche oder am Schlüsselbund, des Nutzers befinden. Da es sich hierbei um Kurzstreckenfunktechnologien handelt, bricht die Verbindung automatisch ab, wenn Bluetooth-Dongle bzw. RFID sich nicht mehr in der Nähe des Clients befinden. Ist dies der Fall, wird die Anwendung blockiert und eine Anforderung eines Barcodes ist nicht möglich. Den Darstellungen gemäß der Figuren 2 und 3 sind Ausfuhrungsvarianten der Implementierung des erfindungsgemäß vorgeschlagenen mobilfunkbasierten Transaktionssystems zu entnehmen. Das mobilfunkbasierte Transaktionssystem umfasst, vergleiche Darstellung gemäß Figur 2, ein Mobilfunknetz 32, in welchem der Benutzer durch Benutzung des mindestens einen Mobiltelefons 36 eingebunden ist, ein Transaktionsterminal 34 an einer Tankstelle in einem Kaufhaus oder an einem Flughafen, um ein Beispiel zu nennen, sowie mindestens einen Systemserver 38.

Die aufgezählten Komponenten sind in allen drei Figuren, d.h. den Figuren 2, 3 und 4, identisch.

Der in der zweiten Ebene 14 des Mehrebenen-Sicherheitssystems 10 gemäß Figur 1 durch- zuführende Standortabgleich 16 erfolgt derart, dass der Client, d.h. der Benutzer des mindestens einen Mobiltelefons 36, einen Barcode von dem mindestens einen Systemserver 38 anfordert. Mit dieser Anforderung sendet er neben anderen Daten auch seinen aktuellen Standort, d.h. den Standort, an dem der jeweilige Benutzer das jeweilige mindestens eine Mobiltelefon 36 gerade und in diesem Moment benutzt. Die Ermittlung dieses Standortes kann entweder aus einer ersten Positionsdatenübermittlung 40, die von dem GPS-System 30 vorgenommen wird, durchgeführt werden oder aus einer Ortung des mindestens einen Mobiltelefons 36 und damit dessen Benutzers innerhalb des Mobilfunknetzes 32 gewonnen werden. Während des Ablaufs der aktuellen Transaktion wird über eine Identifikation des mindestens einen Transaktionsterminals 34, an dem die aktuelle Transaktion jeweils gera- de abläuft, der Standort desselben ermittelt. Stimmen die beiden Standorte, d.h. der Standort, an dem sich der Benutzer des mindestens einen Mobiltelefons 36 aufhält, und der Standort des Transaktionsterminals 34, an dem die jeweilige Transaktion gerade abzuwickeln ist, nicht überein, so wird die Durchführung der Transaktion abgelehnt. Innerhalb des in der zweiten Ebene 14 des Mehrebenen-Sicherheitssystems 10 ablaufenden Standortvergleiches kann - gewissermaßen als zweiter Baustein - ein Vergleich des Standortes der Durchführung der jeweils aktuellen Transaktion mit dem Standort einer vorher durchgeführten Transaktion verglichen werden. Basierend auf der Annahme, dass der Benutzer des mindestens einen Mobiltelefons 36 nur mit einer bestimmten Geschwindigkeit seinen Standort ändern kann, werden Transaktionen, deren räumlicher Abstand nicht mit dem zeitlichen Abstand plausibilisierbar ist, abgelehnt.

Neben diesen systemseitigen Sicherheitsvorkehrungen, die in der zweiten Ebene 14 des Mehrebenen-Sicherheitssystems 10 implementiert sind, kann der Benutzer, d.h. der Benut- zer des mindestens einen Mobiltelefons 36, weitere standortabhängige Einschränkungen vornehmen. Dazu zählen z.B. geographische Beschränkungen hinsichtlich des Web- Interfaces. Es besteht die Möglichkeit, dass sich der Nutzer via Website in seinen Webaccount einloggt. Dort kann der Nutzer dann z.B. auf einer Straßenkarte Bereiche markieren, in denen die Nutzung erlaubt sein soll bzw. untersagt werden soll. Bei dieser Vorgehensweise sind verschiedene Ausprägungsmuster möglich, so z.B. können Postleitzahlen, Städte, Bundesländer oder andere Benutzungsgebiete über entsprechende Codierungen zugelassen oder nicht zugelassen werden. Der auf der zweiten Ebene 14 des Mehrebenen-Sicherheitssystems 10 ablaufende Standortvergleich 16 kann entweder kontinuierlich durchgeführt werden oder zu vorher festgelegten Zeitpunkten, so z.B. alle 10 Minuten. Ein Standortabgleich 16 kann in der zweiten Ebene 14 auch dann vorgenommen werden, wenn eine entsprechende Anfrage an den mindestens einen Systemserver 38 gesandt wird. Da jedoch der Satellitenempfang hinsichtlich der Abschirmung innerhalb eines Gebäudes bei Einsatz eines Positionssystems 30 oftmals schwierig ist und in diesem Falle nur eine Standortbestimmung über das Mobilfunknetz 32, innerhalb dessen das mindestens eine Mobiltelefon 36 und damit zwangsläufig der Benutzer kommuniziert, möglich wäre, sind die kontinuierlichen oder zu festgelegten Zeitpunkten erfolgten Standortabgleiche 16 vorzuziehen, die jedoch einen relativ hohen Energieein- satz erfordern.

Anhand der Figuren 2 und 3 wird die Zwei-Faktoren-Authentifizierung 18, die innerhalb der ersten Ebene 12 des Mehrebenen-Sicherheitssystems 10 abläuft, nachstehend eingehender beschrieben.

In der in Figur 2 dargestellten Ausführungsform des erfindungsgemäß vorgeschlagenen mobilfunkbasierten Transaktionssystems sendet der Benutzer, d.h. der Client in Gestalt des mindestens einen Mobiltelefons 36, im Rahmen einer ersten Verbindung 44 neben einer Nutzer-ID ein Einmal-Passwort und den aktuellen Standort an den mindestens einen Sys- temserver 38. Der Standort kann entweder über das Mobilfunknetzwerk 32 oder ein satellitengestütztes Navigationssystem 30 ermittelt werden. Daraus generiert der mindestens eine Systemserver 38 einen Barcode, der innerhalb eines zweiten Verbindungsschrittes 46 an den Nutzer des mindestens einen Mobiltelefons 36, d.h. den Client, zurückgemeldet wird. Der Barcode wird anschließend innerhalb einer dritten Verbindung 48 an das mindestens eine Transaktionsterminal 34 gesandt oder von diesem gescannt und von dort, vergleiche Position 34, im Rahmen eines vierten Verbindungsschrittes 50 an den mindestens einen Systemserver 38 übermittelt, vergleiche Position 50 in Figur 2. Der Systemserver 38 vergleicht den in Verbindung 50 übermittelten Barcode mit dem in Verbindung 46 übermittelten Barcode. Sind beide Barcodes identisch, sendet der mindestens eine Systemserver 38 eine Zahlungsanfrage, vergleiche fünfte Verbindung 52, an den Client, d.h. den Benutzer des mindestens einen Mobiltelefons 36. Diese wird von dem Benutzer, d.h. im vorliegenden Falle des Clients des mindestens einen Mobiltelefons 36, im Rahmen eines sechsten Verbindungsschrittes 54 mit einer persönlichen PIN bestätigt. Nach der Bestätigung ver- läuft ein siebter Verbindungsschritt 56, wonach die Bestätigung der Transaktion vom mindestens einen Systemserver 38 an das mindestens eine Transaktionsterminal 34 bestätigt wird.

In der in Figur 3 dargestellten Ausführungsvariante des erfindungsgemäß vorgeschlagenen mobilfunkbasierten Transaktionssystems sind die Komponenten 30, 32, 34, 36 und 38 identisch, ebenso wie die Verbindungsschritte 44 bis 56. Die Unterschiede zwischen der in Figur 2 dargestellten Ausführungsvariante und der in Figur 3 dargestellten Ausführungsvariante werden nachstehend kurz beschrieben. Der Client, d.h. der Benutzer des mindestens einen Mobiltelefons 36, sendet im Rahmen des ersten Verbindungsschrittes 44 eine Nut- zer-ID sowie Standortinformationen an den mindestens einen Systemserver 38. Im Rahmen des zweiten Verbindungsschrittes 46 generiert dieser aus den Daten einen Barcode, der wieder an den Benutzer des mindestens einen Telefons 36 im Rahmen des zweiten Verbindungsschrittes 46 zurückgemeldet wird. Der Client, d.h. der Benutzer des mindestens einen Mobiltelefons 36, erweitert diese Barcodedaten durch ein Einmal-Passwort und generiert den endgültigen Barcode, der vom Client, d.h. dem Benutzer des mindestens einen Mobiltelefons 36, im Rahmen des dritten Verbindungsschrittes 48 an das mindestens eine Transaktionsterminal 34 übermittelt wird. Im Rahmen des vierten Verbindungsschrittes 50 werden die Transaktionsdaten sowie der endgültige Barcode an dem mindestens einen Transaktionsterminal 34 gescannt und im Rahmen des vierten Verbindungsschrittes 50 an den mindestens einen Systemserver 38 zurückmeldet. Der mindestens eine Systemserver 38 vergleicht dann die Daten des endgültigen Barcodes mit den zuvor gesendeten Daten und dem Einmal-Passwort. Danach sendet der mindestens eine Systemserver 38 eine Zahlungsanfrage im Rahmen des fünften Verbindungsschrittes 52 an den Client, d.h. den Benutzer des mindestens einen Mobiltelefons 36. Diese Anfrage wird vom Client, d.h. dem Benutzer des mindestens einen Mobiltelefons 36, durch Eingabe einer PIN bestätigt, was am Transaktionsterminal 34 oder an dem Mobiltelefon 36 selbst erfolgen kann. Zum Beschleunigen der Transaktion kann bis zu einem zuvor festgelegten Betrag auf die Eingabe der PIN im Rahmen der Bestätigung verzichtet werden. Im Rahmen des sechsten Verbindungsschrittes 54 erfolgt die Bestätigung der Transaktion im Rahmen des siebten Verbin- dungsschrittes 56 von dem mindestens einen Systemserver 38 unmittelbar an das mindestens eine Transaktionsterminal 34, an dem die Transaktion gerade durchgeführt wird.

Figur 4 zeigt in schematischer Wiedergabe einen geänderten Datenfluss bei mangelhafter Funkabdeckung. Da insbesondere in Gebäuden eingeschränkte Funkverbindungen vorherrschen, stellt das mindestens eine Transaktionsterminal 34 für diesen Fall eine Alternativverbindung bereit. Hierzu stellt die Client-Applikation, d.h. der Benutzer des mindestens einen Mobiltelefons 36, eine Datenfunkverbindung, d.h. eine gesonderte Verbindung 60 zum Transaktionsterminal 34 z.B. über Bluetooth her. Dieses Transaktionsterminal 34 baut entweder eine konstante Verbindung zum Systemserver 38 im Wege einer normalen Verbindung 58 auf oder implementiert diese über Internet. Über die "normale" Datenverbindung 58 kommuniziert dann der Benutzer der Applikation, d.h. der Client, d.h. der Benutzer des mindestens einen Mobiltelefons 36, mit dem mindestens einen Systemserver 38. Hierzu baut der Client eine geschützte Verbindung, so z.B. ein so genanntes Virtual Private Network (VPN), zu dem Systemserver 38 auf. Die Standortbestimmung erfolgt in diesem Falle durch das mindestens eine Transaktionsterminal 34, die restlichen Bestandteile der Sicherheitsprüfung im Rahmen der Zwei-Faktoren- Authentifizierung 18 verlaufen wie im Zusammenhang mit den Figuren 2 und 3 bereits beschrieben ab.

Figur 5 zeigt das erfindungsgemäß vorgeschlagene Mehrebenensicherheitssystem 10 und insbesondere drei mögliche Ausprägungen der Zwei-Faktoren-Authentifizierung in der zweiten Ebene 14. Die erste Möglichkeit stellt die zeitgesteuerte Variante dar (62), bei der Client und Server in definierten Zeitabständen neue Einmal-Passwörter berechnen. Hierbei kann die Einmalpasswort-Berechnung softwaremäßig in die Clientapplikation implementiert werden. Das generierte Einmal-Passwort kann dann direkt weiterverwendet werden und muss nicht erneut vom User eingegeben werden. Die zweite Möglichkeit (64) ist die ereignisgesteuerte Zwei-Faktoren-Authentifizierung. Hierbei berechnet der Client das Einmal-Passwort nicht in definierten Zeitabständen sondern erst bei Eintritt eines Ereignisses, z.B. wenn der User einen Barcode anfordert bzw. die Berechnung manuell auslöst. Im Vergleich zu erstgenannter Variante (62) ist die ereignisgesteuerte Variante (64) ressourcenschonender.

Die dritte Variante (66) ist das Herausforderungs-Antwort bzw. Challenge-Response- Verfahren. Hierbei sendet der Server eine "Herausforderung" an den Client, z.B. einen Zahlenwert. Der Client erfüllt dann die Aufgabe, z.B. führt er eine Berechnung basierend auf dem gesendeten Zahlenwert des Servers aus, und sendet das Ergebnis an den Server zurück. Da der Server die gleiche Berechnung ausführt, kennt er das Ergebnis und kann es mit der gesendeten Antwort des Clients vergleichen. Bei allen drei Möglichkeiten erfolgt entweder die Autorisierung auf dieser Ebene wenn das Einmal-Passwort (Variante 62, 64) bzw. die Antwort (Variante 66) korrekt ist oder die Transaktion wird abgelehnt. Figur 6 zeigt eine weitere Ausführungsvariante, die insbesondere dann vorteilhaft ist, wenn sich das Mobiltelefon des Benutzers z.B. in ein Roaming-Netzwerk eingebucht hat, z.B. bei einem Aufenthalt im Ausland. Bei dieser Ausführungsvariante generiert das Mobiltelefon 36 auf Basis der Nutzer-ID und eines Einmal -Passwortes einen Barcode. Zusätzlich können im Rahmen des mehrschichtigen Sicherheitssystems weitere Informationen, wie z.B. Positionsdaten 32, 30, mit in den Barcode integriert werden. Dieser Barcode wird dann am Transaktionsterminal 34 gescannt 68. Zusätzlich kann der Benutzer 76 am Transaktionsterminal 34 einen PIN-Code eingeben 70. Die Transaktionsinformationen werden dann durch das Transaktionsterminal 34 an den zentralen Systemserver 38 übermittelt 72. Basierend auf dem Einmal-Passwort-System berechnet der zentrale Systemserver 38 paral- lel zu dem Client 36 das individuelle Einmal-Passwort dieses Clients 36. Wie auch in den anderen Ausführungsvarianten kann der zentrale Systemserver 38 nun die übermittelten Transaktionsinformationen überprüfen und die Transaktion bestätigen oder ablehnen. Die Bestätigung oder Ablehnung wird dann vom zentralen Systemserver 38 an das Transaktionsterminal 34 übermittelt 74.

Figur 7 zeigt die mögliche Überprüfung der Echtheit des Systemservers 38 durch das Mobiltelefon bzw. PDA oder ein anderes Kommunikationsmittel 36. Hierzu generiert der Systemserver 38 ein Einmal-Kennwort und sendet es entweder über eine Datenverbindung oder Kurznachricht (SMS) 78 direkt an das Mobiltelefon 36 oder, bei fehlender Funkver- bindung, an das Transaktionsterminal 34. Der Benutzer 76 kann dann das vom Server 38 gesendete Einmal-Kennwort mit dem vom Mobiltelefon errechneten Einmal-Kennwort vergleichen 80. Hierdurch kann der Benutzer die Echtheit des Systemservers 38 überprüfen und verhindern, dass z.B. Betrüger sich in das System einschleichen und Transaktionen manipulieren. Wird das Einmal-Kennwort direkt vom Server38 an das Mobiltelefon ge- sendet, kann die Überprüfung innerhalb des Mobiltelefons 36 ohne weitere Aktion des Benutzers erfolgen. Diese Echtheitsüberprüfung ist mit allen drei beschriebenen Einmal- Kennwort Varianten 62, 64, 66 möglich.

Figur 8 zeigt ein Mobiltelefon, mit welchem ein Barcode eingescannt werden kann, der Details einer Rechnung enthält und der über den Server an ein Kreditinstitut übermittelt wird. Aus Figur 8 geht hervor, dass in dieser Ausführungsvariante des mobilfunkbasierten Transaktionssystems mittels des Mobiltelefons 36 bzw. des dieses handhabenden Benutzers 76, ein Scannen eines Barcodes 100 vgl. Position 48 in Figur 8 erfolgt. Der Barcode 100 befindet sich auf einer Rechnung 102. Der Barcode 100 enthält Zahlungsinformationen wie z.B. den Namen einer Firma 1 10, die Kontonummer, Bankleitzahl, Swiftcode, Iban, Rechnungsnummer, Rechnungsbetrag, Zahlungsziel, Sconti und dergleichen mehr. Durch Einlesen des Barcodes 100 durch das Mobiltelefon 36 besteht die Möglichkeit, die eingescannten Daten mittels einer ersten Datenübermittlung 104 an den Server 38 zu übersenden. Hierbei wird neben den notwendigen Zahlungsdaten aus dem eingelesenen Barcode 100 ebenfalls die Benutzerkennung sowie ein Einmal-Kennwort übermittelt. Vom Server 38 werden sowohl die Zahlungsdaten als auch die Benutzerkennung und das Einmal-Kennwort überprüft. Die Überprüfung des Einmal-Kennwortes erfolgt in der ersten Ebene 12 des Mehrebenensicherheitssystems 10. Bei positiver Überprüfung, d.h. Feststellung, dass sowohl die Zahlungsdaten zu einem beim Server 38 registrierten Zahlungsempfänger, d.h. einer Firma 1 10 gehören, als auch dass das Einmal-Kennwort korrekt ist, werden im Rahmen einer zweiten Datenübermittlung 106 diese Zahlungsdaten an ein Kreditinstitut 1 12 übersandt. Das Kreditinstitut 1 12 gibt gegebenenfalls eine Überweisung durch eine Freigabe 108 frei, so dass der Rechnungsbetrag, der sich auf der Firmenrechnung 102 befindet an die die Rechnung 102 ausstellende Firma 1 10 überwiesen werden kann, gegebenenfalls unter Berücksichtigung ebenfalls im Barcode 100 hinterlegter Details wie z.B. Zahlungsziel, Skonti etc. .

Bezugszeichenliste

10 Mehrebenen-Sicherheitssystem

12 erste Ebene

14 zweite Ebene

16 Standortabgleich (Satellitenoder Netzwerkortung)

18 Zwei-Faktoren- Authentifizierung

20 dritte Ebene

22 biometrische Merkmale

30 GNSS-Ortungssystem (Global Navigation Satellite System)

32 Mobilfunknetz

34 Transaktionsterminal

36 Mobiltelefon

38 Systemserver

40 erste Positionsdatenübermittlung

42 zweite Positionsdatenübermittlung

44 erste Verbindung (Info one time password OTP, Standort) 46 zweite Verbindung (Barcode) 48 dritte Verbindung (Scannen Barcode)

50 vierte Verbindung (Übermittlung von Transaktionsdaten)

52 fünfte Verbindung (Zahlungsanfrage)

54 sechste Verbindung (Bestätigung mit PIN)

56 siebte Verbindung (Bestätigung

Transaktion)

58 normale Verbindung

60 gesonderte Verbindung

62 zeitgesteuerte Zwei-Faktoren-

Authenti fizierung

64 ereignisgesteuerte Zwei- Faktoren-Authentifizierung 66 Herausforderungs-Antwort- Verfahren Zwei-Faktoren- Authentifizierung

Scannen des im Mobiltelefon generierten Barcode (mit Info über Benutzer-ID, One-Time- Password, Standort)

Eingabe PIN am Transaktionsterminal

Übermittlung der Transaktionsinformationen

Bestätigung der Transaktion Benutzer

Einmal-Passwort zur Echtheitsüberprüfung des Servers 38 Vergleich des vom Server 38 gesendeten Einmal-Passworts mit dem vom Mobiltelefon 36 errechneten Einmal-Passworts Barcode

Firmenrechnung

1. Datenübermittlung an

Server 38

2. Datenübermittlung an Kredit institut 1 12

Freigabe der Überweisung Firma, Firmenname

Kreditinstitut