EP3559883A1 - System zum offline-bezahlen mit e-geld mit mobilem gerät mit kurzer transaktionszeit und abschliessendem settlement - Google Patents

System zum offline-bezahlen mit e-geld mit mobilem gerät mit kurzer transaktionszeit und abschliessendem settlement

Info

Publication number
EP3559883A1
EP3559883A1 EP17835630.9A EP17835630A EP3559883A1 EP 3559883 A1 EP3559883 A1 EP 3559883A1 EP 17835630 A EP17835630 A EP 17835630A EP 3559883 A1 EP3559883 A1 EP 3559883A1
Authority
EP
European Patent Office
Prior art keywords
terminal
money
token
payment
donation
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
EP17835630.9A
Other languages
English (en)
French (fr)
Inventor
Stephan WULLSCHLEGER
Markus Knecht
Dominik GRUNTZ
Christof ARNOSTI
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.)
Pbv Kaufmann Systeme GmbH
Original Assignee
Pbv Kaufmann Systeme 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 Pbv Kaufmann Systeme GmbH filed Critical Pbv Kaufmann Systeme GmbH
Publication of EP3559883A1 publication Critical patent/EP3559883A1/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/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • 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/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • 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/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3678—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes e-cash details, e.g. blinded, divisible or detecting double spending

Definitions

  • the server (7) stores the telegrams received by the devices (2, 2 "), processes them, blocks at least one device (2, 2") for the system (1), and other telegrams via the devices (2, 2 ") to the terminal (5), and / or
  • the load token TL (41) is stored on the device (2) and comprises at least the amount of a credit note of the electronic money (4 * ) stored on the device (2),
  • At least one server (7) At least one server (7).
  • the electronic money (4) preferably used in the system (1) according to the invention is the electronic money (4 * ) used according to the invention and / or according to the invention.
  • the secure payment with electronic money (4) in the inventive system (1) and with the inventive method is preferably contactless, ie that a radio link between the device (2) and / or the smart card (6) with the terminal (5) is necessary ,
  • the pool account typically has no knowledge of the e-money (4, 4 * ) accounts on the individual devices (2, 2 ") and is not informed about the individual payment transactions and has no significance for the execution of a final settlement.
  • the book or paper money on the pool account belongs, for example, to the operator of the charging station or to a financial institution, but not to the owner of the device (2) and therefore the e-money (4, 4 * )
  • the pool account is also irrelevant in the case of a payment process If e-money (4) is paid for using the device (2) and / or smartcard (6), the value of the purchased goods will become the e-money (4) on the device (2) or on the smartcard (6) subtracted and the terminal (5) or the attached to the terminal (5) or connected cash register - and thus the seller - credited.
  • the information on this transfer, ie the payment process is transmitted to the server (7) , which can then cause the seller to de credited to the cash register Amount transferred from the pool account, for example, as book money to the bank account of
  • the information on the payment process can be transmitted from the terminal (5), for example by means of NFC to the device (2), but not from the device (2) to the server (7 ) and not from the terminal (5) to the server (7).
  • this information may be available at a later time, i. if the device (2) again can establish a connection with the server (7) and thus online, be transmitted from the device (2) to the server (7).
  • the terminal (5) also stores transacted transactions for billing and control purposes, and sends the stored transactions as transaction telegrams via the device (2) and / or the plurality of devices (2 ") to the server (7). 5) are commercially available and known in the art.
  • the value of goods represented in the donation token TS (42) is subtracted from the balance on the device (2) and / or the smartcard (6) and at the same time credited to the terminal (5), the credit on the device (2) being represented by the difference all load tokens TL (41) and donation tokens TS (42) stored on the device (2) are represented and the credit in the terminal (5) is represented by the newly created donation token TS (42).
  • the e-money (4 * ) stored on the device (2) after payment transactions at a plurality of terminals (5) for each currency comprises i) a load token (41) and ii) for each terminal (5 ) another donation token (42) and thus a plurality of donation tokens (42).
  • the electronic money (4 * ) and / or the electronic money (4 * ) preferably used according to the invention are based on at least two different hash chains.
  • a first hash chain comprises at least one load token TL (41), possibly the older load tokens (41) as a history, and optionally at least one donation token (42).
  • a second hash chain comprises at least one donation token TS (42) of the first hash chain and possibly the older donation tokens (42) as a history.
  • the inventive method for secure payment with e-money (4, 4 * ) with the device (2) with the inventive system (1) comprises at least one of the following steps a) to d). If the method comprises two or more of the following steps, the steps may be performed in any order and / or concurrently. be combined.
  • Step a) of the method according to the invention comprises the storage of electronic money (4 * ) preferably used in the system (1) on the device (2) and / or a terminal (5), the preferably used electronic money (4 * ) at least one load token TL (41) and after a first transaction also at least one donation token TS (42).
  • At least the device (2) and / or one of the multiplicity of devices (2 ") reestablishes a connection to the server (7) within a few hours or at the latest after a few days, whereby the at least one telegram
  • the device (2) and / or at least one of the multiplicity of devices (2 ") receive a telegram with the acknowledgment of receipt at the same time, ie with a short time delay.
  • the payment process at the terminal (5) by means of a smart card (6) the payment process is offline because the smart card (6) can not communicate with the server (7).
  • the terminal (5) transmits after completion of the payment process with the smart card (6) at least one subsequent payment transaction with at least one device (2, 2 ") at least one telegram of the payment process with the smart card (6) to the at least one device (2, 2 "). This transmission to at least one device (2, 2 ") lasts until the terminal (5) has received a telegram from the server (7) with the acknowledgment of receipt.
  • the server can block the device (2, 2") by sending corresponding telegrams to the devices (2, 2 "). These transmit the telegrams to at least one, preferably to a plurality of, in particular to all, terminal 5.
  • the terminals (5) recognize a locked device (2). analogously forward other telegrams with, for example, control information about the devices (2, 2 ") to the terminal (5). This further increases the safety standard of the system (1) and acts preventatively against abuse and forgery.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Cash Registers Or Receiving Machines (AREA)

Abstract

Beansprucht wirdein System (1) zum sicheren Bezahlen mit E-Geld (4) umfassend mindestens ein mobiles Gerät (2) mit E-Geld(4), mindestens ein Terminal (5) und mindestens einen Server (7). Das E-Geld (4) liegt in einer bevorzugten Ausführungsfrom als E-Geld (4*) vor, wobei E-Geld (4*) mindestens ein Load-Token TL (41) und gegebenenfalls mindestens ein Spend-Token TS (42)umfasst. Alternativ, oder zusätzlich, umfasst das Terminal (5) ein Sicherheitselement SEALS-SE (3), wobei das Sicherheitselement SEALS-SE (3) für die Aufbewahrung und Übertragung von E-Geld mit abschliessendem Settlement auch mit einem Gerät(2)ohne Sicherheitselement SE und ohne Internet-Anbindung zum Zeitpunkt des Bezahlvorgangs geeignet ist. Auch wird E-Geld (4*) beschrieben zum sicheren Bezahlen mit dem Gerät (2) an einem Terminal (5) gemäss System (1). Beanspruchtwird auch ein Verfahren zum sicheren Bezahlen mit E-Geld (4, 4*) mit dem Gerät (2), sowie die Verwendung des Systems (1) und eines physischen Sicherheitselements SEALS-SE (3) in einem Terminal (5). Erfindungsgemäss müssen das Terminal (5) und das Gerät (2) zum Zeitpunkt eines Bezahlvorgangs für ein abschliessendes Settlement nicht mit dem Server (7) verbunden sein und können somit offline sein.

Description

System zum offline-Bezahlen mit E-Geld mit mobilem Gerät mit kurzer Transaktionszeit und abschliessendem Settlement
Die vorliegende Erfindung bezieht sich auf ein System zum sicheren Bezahlen mit elektronischem Geld mit einem mobilen Gerät, insbesondere mit einem unsicheren mobilen Gerät (2) ohne ein geeignetes Sicherheitselement, auf das elektronische Geld, auf ein Verfahren zum sicheren Bezahlen mit elektronischem Geld sowie auf deren Verwendung.
Bargeldloses Bezahlen von Waren wird je länger desto wichtiger. Gerade beim Bezahlen von kleineren Geldbeträgen weist das bargeldlose Bezahlen gegenüber Bargeld grosse Vorteile auf. So fallen beispielsweise für den Handel die Kosten für die Verwaltung von Bargeld wie Personal kosten, Transportkosten, Versicherungskosten und Wartungskosten weg. Auch wird beim Bezahlvorgang kein Wechselgeld mehr notwendig, da immer der exakte Betrag von der Karte abgezogen wird. Diese Aspekte sind gerade auch beim Zahlen von Kleinbeträgen und Kleinstbeträgen, beim Automatenverkauf und im Event-Bereich von steigender Bedeutung.
Es sind verschiedene Zahlmethoden zum bargeldlosen Bezahlen bekannt, wobei die Kreditkarten-Zahlung und die Debitkarten-Zahlung am bekanntesten sind. Bei einer Debitkarten-Zahlung kann an einem Zahlterminal bezahlt werden, indem dem der Debitkarte zugewiesenen Giro-Konto bei einem Geldinstitut der entsprechende Geldbetrag direkt belastet und dem Giro-Konto des Verkäufers gutgeschrieben wird. Dabei ist die Debitkarte direkt an ein spezifisches Giro-Konto gebunden und das Zahlterminal muss während dem Bezahlvorgang mit einem Zahlungsdienstleister, d.h. Payment Service Provider, PSP, verbunden, d.h. online, sein. Dementsprechend ist auf der Debitkarte kein Geld gespeichert, sondern die Karte dient nur zur Identifikation des Nutzers. Offline-Zahlungen können keine gemacht werden.
Bei der Kreditkarten-Zahlung wird der bezahlte Betrag zunächst einem Kreditinstitut belastet. Dieses fordert dann den Betrag beim Käufer nachträglich ein. Dementsprechend ist auch bei dieser Zahlungsart kein Geld auf der Karte gespeichert. Auch muss, um Missbrauch zu verhindern, das Zahlterminal während dem Bezahlvorgang mit dem Zahlungsdienstleister verbunden sein, d.h. online sein. Offline können Kreditkarten-Zahlungen nur provisorisch gemacht werden und nur, wenn sie sowohl vom Kreditinstitut als auch vom Vendor, d.h. Anbieter resp. Verkäufer, akzeptiert werden. Somit erfolgt eine offline Zahlung temporär, die aber noch nicht bindend ist. Eine definitive Zahlung mit abschliessendem und somit bindendem Settlement kann erst erfolgen, wenn die Zahlung online durch einen oder mehrere Server und/oder Menschen geprüft wurden. Um ein damit verbundenes erhöhtes Ausfallrisiko zu kompensieren, sind bei Kreditkarten-Zahlungen entsprechend die Transaktionsgebühren grösser.
Bargeldloses Bezahlen mittels Debitkarten und Kreditkarten haben sich in sehr vielen Lebensbereichen durchgesetzt und sind kaum mehr wegzudenken. So erstaunt es wenig, dass es in neuerer Zeit verschiedene Ansätze gibt, Debitkarten- und Kreditkarten-Zahlmethoden auf das Mobiltelefon zu bringen. Denn das Mobiltelefon ist meistens zur Hand und geht selten verloren. Und bei Verlust kann es in aller Regel schnell geortet oder remote gesperrt werden. Auch wird der Zugang zum eigenen Mobiltelefon beispielsweise durch einen geheimen Zugangscode geschützt. Zudem wird kein Geld auf dem Mobiltelefon gespeichert, wodurch eine gewisse Sicherheit vor Fälschung und Missbrauch gewährleistet wird. Denn diese wird gerade bei Debitkarten- und Kreditkarten-Zahlmethoden durch einen zentralen Server von Geld- und Kredit-Instituten sichergestellt. Seit einigen Jahren zirkulieren auch verschiedene Arten von Kryptowährungen wie beispielsweise Bitcoin. Diese Kryptowährungen sind - nicht zuletzt um hohen Sicherheitsanforderungen zu genügen - nicht auf einem Gerät, wie beispielsweise einem Mobiltelefon, sondern in einem dezentralen Netzwerk gespeichert, bei welchem sich - vereinfacht ausgedrückt - alle Teilnehmer des Netzwerks untereinander verständigen und einen Konsens darüber etablieren, wer zu welchem Zeitpunkt wie viel Geld besitzt. Um daher mit einer Kryptowährung bezahlen zu können, muss ein an der Zahlung beteiligtes Gerät zwingend online sein, d.h. einen Kontakt zu mindestens einem Server aufweisen. Zudem wird, um die Sicherheit der Kryptowährung zu gewährleisten, jede Transaktion von einer Vielzahl von weiteren Geräten, von welchen typischerweise mit der gleichen Kryptowährung bezahlt werden kann, überprüft und autorisiert. Eine solche Überprüfung ist äusserst aufwändig und dauert beispielsweise bei Bitcoin aktuell ca. zehn Minuten oder mehr. Zudem bildet jedes dieser Produkte wie Bitcoin eine eigene, spezifische Währung, wodurch sich auch der Wechselkurs zu Landeswährungen ändern kann. Je nach momentanem Vertrauen in das jeweilige Produkt kann der Wechselkurs innerhalb von kurzer Zeit stark schwanken. Da in der Regel der Verkäufer wie auch der Käufer jedoch Zahlungssicherheit wünschen und keine Währungsspekulation eingehen wollen, sind solche Produkte gerade auch für das Bezahlen von Kleinbeträgen ungeeignet. Zudem können mit Produkten wie Bitcoin aufgrund des fehlenden Vertrauensverhältnisses zwischen Käufer und/oder Verkäufer keine Offline-Zahlungen, insbesondere kein Übertrag von E-Geld mit abschliessendem Settlement ohne Anbindung ans Internet zum Zeitpunkt der Zahlung, erfolgen.
Bei allen diesen vorgenannten bargeldlosen Zahlungssystemen ist eine Internetverbindung zum Zeitpunkt des Bezahlvorgangs empfohlen oder gar unabdingbar und wird von den Betreibern immer häufiger vorausgesetzt. Ist jedoch zum Zeitpunkt des Bezahlvorgangs keine Internetverbindung verfügbar - beispielsweise in einem Mobilfunkloch oder bei plötzlichem Versagen des Internets - kann der Bezahlvorgang im Extremfall nicht durchgeführt werden. Wird ein Geldwert, und somit Geld, elektronisch auf ein portables Medium, z.B. auf eine Smartcard gespeichert, spricht man von elektronischem Geld, auch E-Geld genannt.
Bei einer E-Geld-Karte, auch Guthabenkarte, Wertkarte oder Prepaid-Karte genannt, wird ein Geldbetrag elektronisch direkt auf der Karte gespeichert. Bei einem Bezahlvorgang wird dann der entsprechende Betrag direkt von dieser Karte abgebucht. Der Benutzer kann von einer solchen Guthabenkarte anschliessend so lange Geld abbuchen um Käufe zu tätigen bis der Geldbetrag aufgebraucht ist. Da bei Zahlungen mit einer Guthabenkarte die Bonität des Käufers, d.h. des Benutzers der Guthabenkarte, gegeben ist, fallen auch keine oder nur sehr geringe Transaktionsgebühren an, was in der Regel sowohl für den Käufer als auch für den Verkäufer vorteilhaft ist. Im Gegensatz zu den Debitkarten und Kreditkarten kann mit Guthabenkarten auch bei Zahlterminals bezahlt werden die zum Zeitpunkt des Bezahlvorgangs offline sind, resp. nicht mit dem Internet oder einem zentralen Server verbunden sind. Die Bedeutung solcher Offline-Zahlungen, also Zahlungen, bei denen sowohl das Geld-gebende als auch das Geldannehmende Medium offline und nicht mit dem Internet verbunden sind, darf nicht unterschätzt werden. In der Vending-Branche beispielsweise sind die Verkaufsautomaten und deren Zahlungsterminals nur sehr selten mit einer Vernetzung ins Internet ausgestattet. Ausserdem sind Zahlungssysteme auf Basis von E-Geld resp. Guthabenkarten oder PrePaid-Karten gegenüber von Zahlungssystemen auf Basis von Debitkarten und insbesondere Kreditkarten vergleichsweise preisgünstig für den Verkäufer, denn bei jedem Bezahlvorgang mit Debitkarte und Kreditkarte fallen nicht vernachlässigbare Gebühren an. Nicht zu unterschätzen sind auch die Kosten für die benötigte Infrastruktur für Debit- und Kreditkarten und deren Unterhalt, wodurch die Gebühren weiter erhöht werden.
Ein zentraler Punkt bei elektronischen Zahlmethoden wie Zahlungen mit einer Guthabenkarte ist die Diebstahl-, Fälschungs- und Missbrauchssicherheit. Während der Benutzer nicht zuletzt durch die Verwendung von Bargeld gewohnt ist auf sein Eigentum acht zu geben, ist Diebstahl von E- Geld viel schwieriger zu entdecken. Auch Fälschungen und Missbrauch von E-Geld sind viel schwieriger zu erkennen. Damit das Bezahlen mittels einer Guthabenkarte mit E-Geld das Vertrauen von Geldinstituten und Benutzern erhalten und sich somit durchsetzen kann, muss das E-Geld jedoch zwingend ein sehr hohes Mass an Fälschungs- und Missbrauchssicherheit aufweisen. Guthabenkarten umfassen - um die notwendige Sicherheit gegen Fälschung und Missbrauch zu gewährleisten - ein Sicherheitselement. Solche Karten werden auch Smartcards genannt. Sie sind relativ teuer und werden in der Regel von einer vertrauenswürdigen Stelle, beispielsweise einem Vertrauenspartner von einem Geldinstitut, ausgestellt. Um die Sicherheit von solchen Guthabenkarten zusätzlich zu erhöhen sind sie oft nur für eine beschränkte Zeit gültig und sind in der Regel für gewisse Verkaufsstellen limitiert. Für einen Betreiber von Verkaufsstellen mit Guthabenkarten sind die Guthabenkarten zudem relativ aufwändig zum Verwalten. Und der Benutzer kann das aktuelle Guthaben auf einer Guthabenkarte nicht ohne weiteres abfragen. Zudem besitzt er oft verschiedene Guthabenkarten, was als unübersichtlich und nachteilig empfunden wird.
Aufgrund der obgenannten Gründe erstaunt es wenig, wenn der Benutzer den Wunsch äussert, mit seinem Mobiltelefon auch Zahlungen analog einer Guthabenkarte vornehmen zu können. Denn wenn er sein Mobiltelefon wie eine Guthabenkarte einsetzen kann, dann kann er problemlos auch Kleinbeträge, wie sie beispielsweise beim Automatenverkauf und im Event- Bereich vorkommen, bargeldlos bezahlen. Damit eine solche Mobiltelefon- basierte Guthabenkarte alle Vorteile einer normalen Guthabenkarte aufweist, ist es zentral, dass mit ihr auch bezahlt werden kann, wenn zum Zeitpunkt des Bezahlvorgangs das Mobiltelefon keine Internet Verbindung aufweist, d.h. dass auch offline mit der Mobiltelefon-basierten Guthabenkarte bezahlt werden kann.
Um eine Mobiltelefon-basierte Guthabenkarte bereit zu stellen, muss somit ein Geldbetrag elektronisch direkt auf dem Mobiltelefon gespeichert werden. Allerdings gelten Mobiltelefone als unsicher, d.h. der Sicherheitsstandard für Mobiltelefone gilt insbesondere in Bezug auf E-Geld als ungenügend, da die Fälschungs- und Missbrauchssicherheit von E-Geld nicht auf allen Mobiltelefonen gewährleistet werden kann. Somit sind Mobiltelefone per se ungeeignet, um elektronisches Geld darauf sicher zu speichern. Demzufolge ist es mit den heute vorhandenen Technologien nicht möglich, Mobiltelefon- basierte Guthabenkarten bereit zu stellen, die den geforderten Sicherheitsstandards genügen, ohne nicht die Guthabenkarte selbst oder eine äquivalente Hardware direkt ins Mobiltelefon einzubauen, resp. entsprechende vorhandene Hardware im Mobiltelefon zu nutzen.
Mit heutigen Technologien ist die Verwendung eines spezifischen Sicherheitselements, welches für Offline-Zahlungen mit E-Geld ausgelegt ist essentiell, um einem Gerät wie einem Mobiltelefon ausreichende Sicherheitseigenschaften für auf dem Gerät gespeichertes E-Geld zu verleihen. Diese Sicherheitselemente sind im Vergleich zu äquivalenten Guthabenkarten verhältnismässig teuer und nicht jedes Mobiltelefon kann überhaupt mit einem entsprechenden Sicherheitselement nachgerüstet werden. Einige Mobiltelefone der neusten Generation weisen zwar Sicherheitselemente auf, anhand welcher beispielsweise eingegebene Kreditkarten-Daten sicher gespeichert werden können. Der Zugriff auf möglicherweise vorhandene Sicherheitselemente ist jedoch meistens eingeschränkt oder vollständig verwehrt.
Tabelle A: Bekannte elektronische Zahlungsmittel und Aufgabe der Erfin- dung in Bezug auf Art und Weise des Geld-Transfers,
Speicherung von E-Geld sowie Offline-Zahlmöglichkeiten. Alle genannten Zahlungsmittel weisen eine grosse Verbreitung und eine allgemeine Akzeptanz durch Kreditinstitute, Banken und den Benutzern auf.
a) E-Banking wird im weiteren Sinne verstanden, d.h. neben Online- Banking-Systemen zur Erfassung von Überträgen zwischen Bankkonten sind auch Software-Tools für die Verwaltung von proprietärem Netzgeld- Guthaben und dergleichen mit eingeschlossen.
b) E-Geld (4) umfasst jegliches elektronische E-Geld.
c) K*>K steht für Konto^Konto, d.h. von Konto zu Konto. Ein Geld-Transfer bei einem Bezahlvorgang von Konto zu Konto heisst, dass das Geld von einem Konto eines Geldinstituts zu einem anderen Konto des gleichen oder anderen Geldinstituts transferiert wird, wobei das Geld gegebenenfalls auch über Zwischenkonti transferiert werden kann.
d) Ein Sicherheitselement SE vom Typ 1 erlaubt das sichere Speichern von Schlüsseln und Daten wie einen PIN-Code und Angaben zur Karte, d.h. zum Zahlungsmittel, sowie das Ausführen von Krypto-Algorithmen in einer sicheren Umgebung (siehe Tabelle D). Dies ist für die Kernaufgabe einer Debitkarte, das Beziehen von Bargeld an einem Bankomaten, heutzutage unabdingbar.
e) Eine bekannte Kryptowährung ist Bitcoin.
f) Unter Guthabenkarte wird eine Smartcard verstanden, auf welcher E- Geld gespeichert werden kann.
g) GK*>T steht für Transfer zwischen Guthabenkarte und Terminal und G*>T steht für Transfer zwischen Gerät und Terminal. Der Geld-Transfer auf die Guthabenkarte resp. auf das Gerät ist nicht aufgeführt.
h) Ein Sicherheitselement SE vom Typ 2 erlaubt neben der Funktionalität eines Typ 1 SE zusätzlich das Speichern von E-Geld (siehe Tabelle D). i) Temporär heisst, dass eine Zahlung offline vorübergehend erfolgen kann, diese aber noch nicht bindend ist. Ein abschliessendes und somit bindendes Settlement kann erst erfolgen, wenn die Zahlung online durch einen oder mehrere Server und/oder Menschen geprüft wurde,
j) Die Unterscheidung zwischen Debitkarte und Kreditkarte erfolgt hier aus Gründen der Unterscheidung der Zahlungsverfahren. Moderne Bezahlkarten erfüllen heute oft die Aufgaben beider Kartentypen. Je nach selektiertem Zahlungsverfahren wird sie entweder als Kreditkarte oder als Debitkarte verwendet. Somit bleiben die Eigenschaften der Kartentypen auch als Hybrid erhalten,
k) Für die Integrität und den Schutz des erfindungsgemässen Systems (1 ) ist ein Sicherheitselement SE nicht notwendig. Zum Schutz der privaten Daten oder des eigenen Geldes vor Diebstahl, z. B. mittels einer bösartigen Software, kann ein Sicherheitselement SE vom Typ 1 verwendet werden.
I) Unter Geld-Schlupf wird verstanden, dass bei einer Geld-Transaktion Geld irrtümlich verloren geht oder doppelt gutgeschrieben wird.
Somit ist es die Aufgabe der vorliegenden Erfindung ein System zum sicheren bargeldlosen Bezahlen mittels einer Mobiltelefon-basierten Guthabenkarte bereit zu stellen, wobei der Bezahlvorgang mit abschliessendem Settlement auch ohne Internet-Anbindung und somit offline, d.h. ohne Mobilfunk- und/oder Internetverbindung zum Zeitpunkt und am Ort des Bezahlvorgangs, erfolgen kann. Das auf dem Mobiltelefon gespeicherte Geld muss eine sehr hohe Fälschungs-, Missbrauchs und Zahlungssicherheit aufweisen und im Wesentlichen in derjenigen Landeswährung verfügbar sein, welche am Ort des Bezahlvorgangs üblich ist. Trotzdem soll das Mobiltelefon keine spezifischen Sicherheitsanforderungen erfüllen müssen, d.h. bargeldloses Bezahlen soll auch mit sogenannten unsicheren Geräten möglich sein. Das bargeldlose Bezahlen muss jeweils schnell abgewickelt werden können, d.h. eine kurze Transaktionsdauer aufweisen, damit das System von seinen Nutzern akzeptiert wird. Auch soll das bargeldlose Bezahlen in allen Fällen ein abschliessendes Settlement beinhalten, damit es entsprechend von den Terminal-Betreibern, und somit von den Verkaufsstellen, akzeptiert wird. Zudem soll das System den Geld-Schlupf, d.h. das irrtümliche Verlorengehen oder doppeltes Gutschreiben von Geld, verhindern. Überraschenderweise konnte diese komplexe und herausfordernde Aufgabe mit einem System (1 ) zum sicheren Bezahlen mit elektronischem Geld (4), d.h. E-Geld (4), gelöst werden, umfassend
- mindestens ein mobiles Gerät (2) mit E-Geld (4), wobei das E-Geld (4) gegebenenfalls mit einer Software verwaltet wird,
- gegebenenfalls mindestens eine Smartcard (6) mit E-Geld (4), wobei E-Geld (4) auf der Smartcard (6) aufbewahrt wird,
- mindestens ein Payment-Terminal (5), und
- mindestens einen Server (7),
dadurch gekennzeichnet, dass
I. das E-Geld (4) als E-Geld (4*) vorliegt, wobei das E-Geld (4*) mindestens ein Load-Token TL (41 ) und nach einem ersten Bezahlvorgang auch mindestens ein vom Load-Token TL (41 ) verschiedenen Spend-Token TS (42) umfasst, und/oder
II. das Terminal (5) mindestens ein Sicherheitselement SEALS-SE (3) umfasst, wobei das Sicherheitselement SEALS-SE (3) für die Aufbewahrung und Übertragung von E-Geld (4, 4*) mit abschliessendem Settlement auch mit einem Gerät (2) ohne Sicherheitselement SE und ohne Internet-Anbindung zum Zeitpunkt des Bezahlvorgangs geeignet ist, und das Terminal (5) und das
Gerät (2) zum Zeitpunkt eines Bezahlvorgangs für ein abschliessendes Settlement nicht mit dem Server (7) verbunden sein müssen und somit offline sein können. Beansprucht wird auch Elektronisches Geld (4*) zum sicheren Bezahlen mit dem Gerät (2), insbesondere mit dem unsicheren Gerät (2), an einem Terminal (5) gemäss System (1 ), dadurch gekennzeichnet, dass das E-Geld (4*) mindestens ein Load-Token TL (41 ) und nach einem ersten Bezahlvorgang auch mindestens ein vom Load-Token TL (41 ) verschiedenes Spend-Token TS (42) umfasst, wobei - das Load-Token TL (41 ) auf dem Gerät (2) gespeichert ist und mindestens den Betrag einer Gutschrift des auf dem Gerät (2) gespeicherten E-Gelds (4*) umfasst,
- das Spend-Token TS (42) mindestens den Warenwert der beim Bezahlvorgang gekauften/verkauften Waren und gegebenenfalls weitere Informationen zum Bezahlvorgang, insbesondere zu dem am Bezahlvorgang beteiligten Gerät (2) und Terminal (5), umfasst und damit einen Bezahlvorgang mit E-Geld (4*) vom Gerät (2) zum Terminal (5) repräsentiert, wobei das Spend-Token TS (42) mindestens auf dem Gerät (2) und/oder Terminal (5) gespeichert ist, und
- der aktuelle Wert des auf dem Gerät (2) gespeicherte E-Geldes (4*) durch die Summe der Load-Token TL (41 ) abzüglich der Summe der Spend-Token TS (42) repräsentiert wird, wobei das mindestens eine Load-Token TL (41 ) und das gegebenenfalls mindestens eine Spend-Token TS (42) bevorzugt eine Information enthält, welche eine chronologische Anordnung erlaubt.
Auch wird ein Verfahren zum sicheren Bezahlen mit E-Geld (4, 4*) mit dem Gerät (2) mit dem erfindungsgemässen System (1 ) beansprucht, wobei das Verfahren mindestens einen der folgenden Schritte a) bis d) umfasst:
a) das Speichern von E-Geld (4) auf dem Gerät (2) und/oder einem Terminal (5), wobei das E-Geld (4) mindestens ein Load-Token TL (41 ) und nach einer ersten Transaktion auch mindestens ein Spend-Token TS (42) umfasst,
b) einen Bezahlvorgang mit E-Geld (4, 4*) mit abschliessendem Settlement ohne Internet-Anbindung zum Zeitpunkt des Bezahlvorgangs umfassend eine Transaktion eines Guthabens von Gerät (2) an Terminal (5) und/oder von Terminal (5) an Gerät (2), wobei das Terminal (5) mindestens ein physisches Sicherheitselement SEALS-SE (3) umfasst, das Gerät (2) und das Terminal (5) miteinander kommunizieren und die Transaktion des Guthabens bevorzugt in mindestens einem Spend-Token TS (42) repräsentiert wird,
das Austauschen von mindestens einem Telegramm zwischen Terminal (5) und Server (7) und/oder zwischen Server (7) und Terminal (5), wobei der Austausch des mindestens einen Telegramms über das Gerät (2) und/oder eine Vielzahl von Geräten (2") stattfindet, und/oder
das Überwachen und Erkennen von Missbrauch im Systems (1 ) mit E-Geld (4, 4*), wobei
- der Server (7) die von den Geräten (2, 2") empfangenen Telegramme speichert, verarbeitet, gegebenenfalls mindestens ein Gerät (2, 2") für das System (1 ) sperrt, und andere Telegramme über die Geräte (2, 2") an das Terminal (5) weiterleitet, und/oder
- das Terminal (5) unter Verwendung des Sicherheitselements SEALS-SE (3) mindestens die von den Geräten (2, 2") empfangenen Spend-Token TS (42) auf deren Korrektheit hin überprüft, gegebenenfalls mindestens ein Gerät (2, 2") für das System (1 ) sperrt und/oder ablehnt, und gegebenenfalls mindestens ein Telegramm über die Geräte (2, 2") an den Server (7) weiterleitet,
sowie gegebenenfalls ein Rückkauf des am Terminal (5) kumulierten E-Geld (4, 4*) mit Geldübertrag zum Bankkonto des Verkäufers.
Beansprucht wird zudem auch ein Verfahren zum sicheren bargeldlosen Bezahlen mit dem erfindungsgemässen elektronischem Geld (4*) mit dem Gerät (2) an einem Terminal (5), dadurch gekennzeichnet, dass das E-Geld (4*) mindestens ein Load-Token TL (41 ) und nach einem ersten Bezahlvorgang auch mindestens ein vom Load-Token TL (41 ) verschiedenes Spend-Token TS (42) umfasst, wobei
- das Load-Token TL (41 ) auf dem Gerät (2) gespeichert ist und mindestens den Betrag einer Gutschrift des auf dem Gerät (2) gespeicherten E-Gelds (4*) umfasst,
- das Spend-Token TS (42) mindestens den Warenwert der beim Bezahlvorgang gekauften/verkauften Waren und gegebenenfalls weitere Informationen zum Bezahlvorgang, insbesondere zu dem am Bezahlvorgang beteiligten Gerät (2) und Terminal (5), umfasst und damit einen Bezahlvorgang mit E-Geld (4*) vom Gerät (2) zum Terminal (5) repräsentiert, wobei das Spend-Token TS (42) mindestens auf dem Gerät (2) und/oder Terminal (5) gespeichert ist, und
- der aktuelle Wert des auf dem Gerät (2) gespeicherte E-Geldes (4*) durch die Summe der Load-Token TL (41 ) abzüglich der
Summe der Spend-Token TS (42) repräsentiert wird, wobei das mindestens eine Load-Token TL (41 ) und das gegebenenfalls mindestens eine Spend-Token TS (42) bevorzugt eine Information enthält, welche eine chronologische Anordnung erlaubt.
Beansprucht wird auch die Verwendung des erfindungsgemässen Systems (1 ) und des erfindungsgemässen Verfahrens zum sicheren Bezahlen mit E- Geld (4) mit dem Gerät (2) auch wenn das Gerät (2) und das Terminal (5) während dem Bezahlvorgang keinen Kontakt zum Server (7) aufweisen und somit offline sind.
Ebenfalls wird die Verwendung eines physischen Sicherheitselements SEALS-SE (3) für Offline-Zahlungen mit E-Geld (4) an einem Terminal (5) zum sicheren Bezahlen mit E-Geld (4) mit dem Gerät (2) an einem Terminal (5) unter Verwendung des erfindungsgemässen Systems (1 ) und des erfindungsgemässen Verfahrens beansprucht, wobei das Sicherheitselement SEALS-SE (3) für die Aufbewahrung und Übertragung von E-Geld mit abschliessendem Settlement auch mit einem Gerät (2) ohne Sicherheitselement SE und ohne Internet-Anbindung zum Zeitpunkt des Bezahlvorgangs geeignet ist, wodurch der Bezahlvorgang auch erfolgen kann, wenn das Gerät (2) und das Terminal (5) während dem Bezahlvorgang keinen Kontakt zum Server (7) aufweisen und somit offline sind.
Mit dem erfindungsgemässen System (1 ) umfassend E-Geld (4, 4*), dem erfindungsgemässen E-Geld (4*), den erfindungsgemässen Verfahren und den erfindungsgemässen Verwendungen kann überraschenderweise mit einem unsicheren mobilen Gerät (2), wie beispielsweise mit einem Mobiltelefon ohne Sicherheitselement SE, bargeldlos nicht nur online, sondern auch offline, d.h. auch an Orten mit E-Geld (4, 4*) bezahlt werden, welche zum Zeitpunkt und/oder am Ort des Bezahlvorgangs keine Mobilfunk- und/oder Internetverbindung aufweisen. Somit kann beispielsweise das unsichere Mobiltelefon als Gerät (2) als sichere Guthabenkarte eingesetzt werden, mit welcher auch offline bezahlt werden kann. Darüber hinaus können im System (1 ) anstelle - oder auch zusätzlich - von unsicheren Geräten (2) auch mobile Geräte (2) eingesetzt werden, die ein Sicherheitselement SE umfassen und somit als sicher gelten. Zudem weist das E-Geld (4*) der vorliegenden Erfindung und das im erfindungsgemässen System (1 ) bevorzugt eingesetzte E-Geld (4) eine sehr hohe Fälschungs-, Missbrauchs- und Zahlungssicherheit auf. Trotzdem kann der Bezahlvorgang mit dem E-Geld (4) schnell - und bevorzugt auch kontaktlos - abgewickelt werden, auch wenn die für einen Bezahlvorgang relevanten Geräte wie das Gerät (2), d.h. beispielsweise das Mobiltelefon, und das Terminal (5), d.h. beispielsweise der Point-of-Sale (POS) bei einer Kasse oder ein Verkaufsautomat, zum Zeitpunkt und/oder am Ort des Bezahlvorgangs offline sind. Somit wird mit dem erfindungsgemässen System (1 ) überraschenderweise beim bargeldlosen Bezahlen in allen Fällen, insbesondere auch wenn sowohl das Gerät (2) wie auch das Terminal (5) offline sind, ein unbedingtes und abschliessendes Settlement des Zahlvorgangs erzielt.
Tabelle B: Die vorliegende Erfindung im Vergleich zu bekannten elektronischen Zahlungsmitteln bei online Zahlungen in Bezug auf den Einsatz von E-Geld (4), Sicherheitselemente SE im Zahlungsmittel und im Terminal (5), sowie die jeweilige Transaktionsdauer.
a) Siehe Tabelle A.
b) Siehe Tabelle A.
c) Die Transaktionsdauer ist die Zeit, bis ein Bezahlvorgang am Point-of- Sale, z.B. am Terminal (5), temporär oder definitiv, d.h. abschliessend, vollzogen ist. d) E-Banking mit Mobiltelefon ohne Sicherheitselement SE, d.h. mit einem unsicheren Gerät (2), kann aufgrund bekannter, individueller Autorisierungen nur online durchgeführt werden. Die Transaktionsdauer eines Bezahlvorgangs kann nicht mit der Transaktionsdauer der anderen aufgeführten Zahlungsmittel verglichen werden. Je nach Implementierung kann die Transaktion von wenigen Sekunden bis einige Tage dauern.
e) Ein Sicherheitselement SE vom Typ 1 erlaubt das Speichern des kryptographischen Schlüssels und von Daten wie beispielsweise Angaben zur Karte (siehe Tabelle D).
f) Siehe Tabelle A, Fussnote k).
g) Ein Sicherheitselement SE vom Typ 2 erlaubt neben dem Speichern des kryptographischen Schlüssels und von Daten zusätzlich das Speichern von E-Geld (siehe Tabelle D).
h) Ein Sicherheitselement SE vom Typ 3 erlaubt erfindungsgemäss - zusätzlich zu den Fähigkeiten eines SE vom Typ 2 - auch das Aufbewahren von E-Geld in einem Zahlungsmittel ohne SE, d.h. Gerät (2), und das Transferieren von E-Geld von einem Zahlungsmittel ohne SE, d.h. Gerät (2), zu einem Terminal, d.h. Terminal (5), wobei nur das Terminal (5) zwingend ein solches Sicherheitselement SE benötigt. Ein hierzu geeignetes Sicherheitselement SE vom Typ 3 ist das Sicherheitselement SEALS-SE (siehe Tabelle D).
Zudem kann das E-Geld (4, 4*) gemäss der vorliegenden Erfindung nicht nur in jeglicher Landeswährung vorhanden sein, sondern E-Geld (4, 4*) kann auf dem gleichen Gerät (2) auch gleichzeitig in verschiedenen Landeswährungen sowie Komplementärwährungen aufbewahrt werden. Überraschenderweise kann das erfindungsgemässe System (1 ), das erfindungsgemässe Verfahren sowie die erfindungsgemässe Verwendung auch durch eine Smartcard (6) erweitert werden, wodurch lediglich diese und nicht das Gerät (2) selber mitgetragen werden muss. Dies kann beispielsweise für Benutzer, die sich innerhalb eines Firmengeländes aufhalten und während dieser Zeit mit E- Geld (4, 4*) an Verkaufsautomaten und/oder in der Kantine bezahlen möchten, von grossem Nutzen sein. Die vorliegende Erfindung erlaubt zudem auch, dass das auf dem Gerät (2) gespeicherte E-Geld (4) auf dem Display mit Eingabefeld des Geräts (2) eingesehen und/oder verwaltet werden kann. So können beispielsweise mit geeigneter Software auch Bezugslimiten selber definiert werden. Aus den Tabellen A, B und C ist klar ersichtlich, dass das System (1 ) der vorliegenden Erfindung überraschenderweise die Vorteile der Guthabenkarte in Mobiltelefonen, und somit in bestehenden mobilen Geräten (2), integriert. Insbesondere braucht das mobile Gerät (2) kein Sicherheitselement SE, um bei einem Bezahlvorgang auch offline ein abschliessendes Settlement innerhalb von höchstens wenigen Sekunden zu erzielen. Trotzdem kann E- Geld (4, 4*) auf dem somit unsicheren Gerät (2) gespeichert und an einem Terminal (5) damit bezahlt werden. Zudem kann mit dem erfindungsgemässen System ein Bezahlvorgang nicht nur online sondern auch offline definitiv abgeschlossen werden, d.h. das Settlement wird auch offline und somit ohne Internet-Anbindung abschliessend durchgeführt. Mit Kryptowährungen kann hingegen analog zu Kreditkarten offline nur ein temporäres Settlement durchgeführt werden. Um das damit verbundene erhöhte Ausfallrisiko zu kompensieren, sind die Transaktionsgebühren entsprechend grösser. Zudem beträgt die Transktionszeit, d.h. die Zeit, bis ein Bezahlvorgang abgeschlossen ist, bei Kryptowährungen typischerweise mehr als 5 Minuten, und somit um ein Vielfaches länger als bei der vorliegenden Erfindung.
Tabelle C: Die vorliegende Erfindung im Vergleich zu bekannten elektronischen Zahlungsmitteln bei offline Zahlungen in Bezug auf den Einsatz von E-Geld (4), Sicherheitselennente SE im Zahlungsmittel und im Terminal (5), sowie Offline-Settlement.
a) Siehe Tabellen A und B.
b) Siehe Tabellen A und B.
c) Siehe Tabelle B, Fussnote h).
d) Siehe Tabelle B, Fussnote g). e) Temporär heisst, dass eine Zahlung offline vorübergehend erfolgen kann, die aber noch nicht bindend ist. Ein abschliessendes und somit bindendes Settlement kann erst erfolgen, wenn die Zahlung online durch einen oder mehrere Server und/oder Menschen geprüft wurde. Kryptowährungen verhalten sich bei Offline-Bezahlvorgängen ähnlich wie Kreditkarten.
f) Siehe Tabelle A, Fussnote k).
g) Ist ein Offline Settlement nicht gegeben, muss zum Zeitpunkt des Bezahlvorgangs das elektronische Zahlungsmittel eine Internet- Anbindung aufweisen, oder es erfolgt - sofern möglich - eine temporäre Offline-Zahlung und somit offline ein temporäres Settlement, welches zu einem späteren Zeitpunkt bestätigt werden muss, um ein abschliessendes Settlement zu erzielen.
h) Bei einem Bezahlvorgang mit dem entsprechenden Zahlungsmittel wird das Geld direkt einem Guthaben belastet und einem anderen Guthaben gutgeschrieben (siehe Tabelle A, Fussnote g)).
Überraschenderweise wurde auch gefunden, dass mit dem erfindungs- gemässen E-Geld (4*) der Geld-Schlupf bei Transaktionen ganz verhindert werden kann, da das Spend-Token TS (42) bei einem Bezahlvorgang typischerweise sowohl auf dem Gerät (2, 2") als auch in Form einer identischen Kopie auf dem Terminal (5) gespeichert wird. Sollte nun irrtümlicherweise das Spend-Token TS (42) nicht oder nicht korrekt auf dem Terminal (5) gespeichert werden, wird dies bei einer nächsten Interaktion am gleichen Terminal (5) übermittelt. Bis zu einem weiteren Kontakt bleibt das Spend-Token TS (42) auf dem Gerät (2, 2") gespeichert und als nicht abgeschlossene Ausgabe erkennbar und für das Terminal (5) reserviert. Falls das Terminal (5) ein Spend-Token (42) mehrfach erhält so wird es dennoch nur genau einmal verwendet. Die US-A-2016224977 beschreibt ein Verfahren mit welchem durch ein erstes, insbesondere mobiles, Gerät ein erstes Token erhalten wird, wobei das erste Token mit einem Geldbetrag und einem Startdatum bezüglich der Verfügbarkeit des Geldbetrags verbunden ist. Nachdem das erste Token durch das erste Gerät erhalten wurde, erzeugt das erste Gerät ein zweites Token, das mit dem ersten Token und dem Erzeugungsdatum des zweiten Tokens verknüpft ist, wobei das erste Gerät das zweite Token und das Erzeugungsdatum des zweiten Tokens zu einem zweiten, insbesondere mobilen, Gerät bereitstellt. Die mobilen Geräte sind mit einem Server des Service Providers verbunden, wobei dieser wiederum mit einem Verarbeitungsnetzwerk in Verbindung steht. Das Verarbeitungsnetzwerk steht in Verbindung mit einem Autorisierungs-Server, welcher neue Tokens autorisiert. Die Token auf den Geräten repräsentieren eine Art Scheck, d.h. Check, welcher als Ganzes oder in Teilen in Form eines zweiten oder weiteren Tokens an ein weiteres Gerät weiter gegeben werden kann. Relevante Informationen zu jedem Token werden in einem vom Gerät unabhängigen, separaten Aufbewahrungsraum, beispielsweise einem Tresorraum aufbewahrt oder einem in einem zentral öffentlichen Register eingetragen. Mit den Token, d.h. Schecks, können an einem Computer eines Händlers Zahlungen vorgenommen werden. Dazu kann das mobile Gerät offline sein. Allerdings muss der Händlercomputer zum Zeitpunkt der Transaktion zwingend online und in synchroner Verbindung mit dem Verarbeitungsnetzwerk und somit mit dem Aufbewahrungsraum oder dem öffentlichen Register sein, um zu bestätigen, dass der Token ausreichend gedeckt ist und dem Zahlenden gehört. Somit beinhaltet ein Token nicht elektronisches Geld und stellt auch keine Guthabenkarte dar, sondern ein Token bildet in Form eines Schecks Geld ab, welches auf einem zentralen Server wie dem Autorisierungs-Server gespeichert ist. Wird ein Token auf ein neues Gerät übertragen, wird dies im öffentlichen Register ebenfalls eingetragen. Somit berechtigt ein Token, Geld einzufordern, ist jedoch nicht selber Geld. Der erste und der zweite Token unterscheiden sich zudem nicht im Aufbau und im Zweck der Token, sondern beinhalten lediglich andere Informationen. Echte Offline-Zahlungen ohne Internet Anbindung können nicht durchgeführt werden, denn zumindest der Händlercomputer muss eine aktive Verbindung mit dem Verarbeitungsnetzwerk aufweisen, da ein exerner Server eine Zahlung validiert, d.h. ein abschliessendes Settlement durchführt. Externe Netzwerke, Server und Computer sind essentiell für den Abschluss einer Zahlung und für das definitive Settlement der Zahlung. Das mobile Gerät weist typischerweise ein Sicherheitselement SE auf, nicht aber der Händlercomputer.
Das System (1 )
Das erfindungsgemässe System (1 ) und das im erfindungsgemässen Verfahren verwendete System (1 ) zum sicheren Bezahlen mit E-Geld (4) umfasst
- mindestens ein mobiles Gerät (2) mit E-Geld (4), wobei das E-Geld (4) auf dem Gerät (2) gespeichert ist und gegebenenfalls mit einer
Software verwaltet wird,
- gegebenenfalls mindestens eine Smartcard (6) mit E-Geld (4), wobei E-Geld (4) auf der Smartcard (6) aufbewahrt wird,
- mindestens ein Payment-Terminal (5), und
- mindestens einen Server (7).
Im erfindungsgemässen System (1 ) können sichere wie auch unsichere mobile Geräte (2) eingesetzt werden. Unter sicheren Geräte (2) werden Geräte (2) verstanden, welche ein Sicherheitselement SE vom Typ 2 oder Typ 3 enthalten, welches für die sichere Aufbewahrung und Übertragung von E-Geld und somit für Offline-Zahlungen mit E-Geld verfügbar und zur Verwendung durch Dritte freigegeben ist. Unsichere Geräte (2) weisen dementsprechend kein geeignetes Sicherheitselement SE auf, resp. das vorhandene geeignete Sicherheitselement SE steht nicht zur Verwendung zur Verfügung. Erfindungsgemäss wird unter dem System (1 ) auch ein System mit umfasst, in welchem im Wesentlichen nur mobile Geräte (2) - und gegebenenfalls eine oder mehrere Smartcards (6) - eingesetzt werden, welche ein Sicherheitselement SE für die sichere Aufbewahrung und/oder Übertragung von E-Geld (4) umfassen - und somit als sichere mobile Geräte gelten - solange im System (1 ) auch mit unsicheren mobilen Geräten (2, 2"), die kein Sicherheitselement SE für die sichere Aufbewahrung und/oder Übertragung von E-Geld (4) enthalten, mit E-Geld (4) bezahlt werden kann.
Mit dem erfindungsgemässen System (1 ) wird beim bargeldlosen Bezahlen in allen Fällen, insbesondere auch wenn sowohl das Gerät (2) wie auch das Terminal (5) offline sind, ein unbedingtes und abschliessendes Settlement des Zahlvorgangs erzielt. Dadurch entsteht ein E-Geld-Bezahlvorgang mit unbedingtem Settlement, im Folgenden auch nur Settlement genannt, mit abschliessender Wirkung.
Das System (1 ) umfasst das sichere Bezahlen mit jeglichem E-Geld, d.h. mit E-Geld (4). Somit umfasst das System (1 ) auch das Bezahlen mit dem erfindungsgemässen und/oder erfindungsgemäss eingesetzten E-Geld (4*).
In einer bevorzugten Ausführungsform umfasst das System (1 ) das sichere Bezahlen mit jeglichem E-Geld (4), aber ohne Kryptowährungen. Somit umfasst E-Geld (4) in dieser Ausführungsform insbesondere das erfindungsgemässe und erfindungsgemäss eingesetzte E-Geld (4*) sowie E- Geld in Form von Landeswährungen, das beispielsweise auf Guthabenkarten gespeichert wird.
In einer besonders bevorzugten Ausführungsform ist das im erfindungs- gemässen System (1 ) bevorzugt eingesetzte E-Geld (4) das erfindungsgemässe und/oder erfindungsgemäss eingesetzten E-Geld (4*). Das sichere Bezahlen mit elektronischem Geld (4) im erfindungsgemassen System (1 ) und mit den erfindungsgemassen Verfahren erfolgt bevorzugt kontaktlos, d.h. dass eine Funkverbindung zwischen dem Gerät (2) und/oder der Smartcard (6) mit dem Terminal (5) notwendig ist.
Mit dem erfindungsgemassen System (1 ) transferiert der Benutzer Geld über eine Ladestation oder Bankkonto auf das Gerät (2) und/oder die Smartcard (6), wo es als E-Geld (4) gespeichert wird. Papiergeld, das beispielsweise in eine Ladestation gegeben wird, und Buchgeld, welches von einem Bankkonto auf das Gerät (2) überwiesen wird, wird vom Betreiber der Ladestation resp. vom Geldinstitut, bei welchem das Bankkonto angelegt ist, auf ein Pool-Konto transferiert. Dessen Gegenwert wird als E-Geld (4) auf dem Gerät (2) oder der Smartcard (6) gespeichert. Auf dem Gerät (2) gespeichertes E-Geld (4) kann gegebenenfalls auch weiter auf eine Smartcard (6) transferiert werden. Das Pool-Konto hat typischerweise keine Kenntnis der E-Geld (4, 4*) Konti auf den einzelnen Geräten (2, 2") und wird über die einzelnen Bezahlvorgänge nicht unterrichtet. Zudem hat es für die Durchführung eines abschliessenden Settlements keine Bedeutung. Das Buch- oder Papiergeld auf dem Pool-Konto gehört beispielsweise dem Betreiber der Ladestation oder einem Geldinstitut, aber nicht dem Inhaber des Geräts (2) und somit des E-Gelds (4, 4*). Das Pool-Konto ist auch nicht relevant bei einem Bezahlvorgang Wird nun mit E-Geld (4) mittels Gerät (2) und/oder Smartcard (6) bezahlt, wird der Wert der gekauften Ware dem E-Geld (4) auf dem Gerät (2) resp. auf der Smartcard (6) subtrahiert und dem Terminal (5) resp. der an das Terminal (5) angehängten resp. verbundenen Kasse - und somit dem Verkäufer - gutgeschrieben. Die Information zu diesem Transfer, d.h. zum Bezahlvorgang, wird an den Server (7) übermittelt, welcher anschliessend veranlassen kann, dass der dem Verkäufer an der Kasse gutgeschriebene Betrag vom Pool-Konto beispielsweise als Buchgeld auf das Bankkonto des Verkäufers transferiert wird. Zudem wird beispielsweise der entsprechende Betrag vom E-Geld (4) auf dem Terminal (5) subtrahiert, resp. vernichtet, d.h. gelöscht. Durch diese Schritte wird E-Geld (4) wieder in Geld, insbesondere in Buchgeld, umgewandelt.
Das Terminal (5) muss keine direkte Verbindung mit dem Server (7) aufweisen, insbesondere muss das Terminal (5) auch zum Zeitpunkt eines Bezahlvorganges, unabhängig ob es mit einer Kasse verbunden ist oder nicht, nicht direkt mit dem Server (7) verbunden sein und kann somit offline sein. Da das Terminal (5) jedoch beispielsweise mittels Kurzstrecken- Funkverbindung wie NFC mit dem Gerät (2) kommunizieren kann, und das Gerät (2) wiederum mittels Daten-Netzwerkverbindung mit dem Server (7) kommunizieren kann, wird die Information zu diesem Transfer vom Terminal (5) über das Gerät (2) zum Server (7) weiter geleitet. Falls nun zum Zeitpunkt und/oder am Ort des Bezahlvorgangs weder das Terminal (5) noch das Gerät (2) mit dem Server verbunden sind, d.h. wenn sowohl das Terminal (5) wie auch das Gerät (2) offline sind, kann die Information zum Bezahlvorgang zwar vom Terminal (5) beispielsweise mittels NFC zum Gerät (2) übermittelt werden, nicht aber vom Gerät (2) zum Server (7) und auch nicht vom Terminal (5) zum Server (7). Allerdings kann diese Information zu einem späteren Zeitpunkt, d.h. wenn das Gerät (2) wieder eine Verbindung mit dem Server (7) aufbauen kann und somit online ist, vom Gerät (2) zum Server (7) übermittelt werden.
Das erfindungsgemässe E-Geld (4*) und das im erfindungsgemässen System (1 ) bevorzugt als E-Geld (4*) vorliegende E-Geld (4) umfasst nicht nur eine Art von Token, sondern mindestens ein Load-Token TL (41 ) und, spätestens nach einer ersten Transaktion, auch mindestens ein vom Load- Token TL (41 ) verschiedenes Spend-Token TS (42). In einer anderen besonders bevorzugten Ausführungsform des erfindungsgemässen Systems (1 ) umfasst das Terminal (5) mindestens ein Sicherheitselement SEALS-SE (3), wobei das Sicherheitselement SEALS-SE (3) für die Aufbewahrung und Übertragung von E-Geld (4, 4*) mit abschliessendem Settlement auch mit einem Gerät (2) ohne Sicherheitselement SE und ohne Internet-Anbindung zum Zeitpunkt des Bezahlvorgangs geeignet ist, wobei das Terminal (5) und das Gerät (2) zum Zeitpunkt eines Bezahlvorgangs für ein abschliessendes Settlement des Bezahlvorgangs nicht mit dem Server (7) verbunden sein müssen und somit offline sein können.
In einer weiteren besonders bevorzugten Ausführungsform des erfindungsgemässen Systems (1 ) liegt das E-Geld (4) als E-Geld (4*) vor, wobei das E-Geld (4*) mindestens ein Load-Token TL (41 ) und, spätestens nach einer ersten Transaktion, auch mindestens ein vom Load-Token TL (41 ) verschiedenes Spend-Token TS (42) umfasst. Zudem umfasst das Terminal (5) mindestens ein Sicherheitselement SEALS-SE (3), wobei das Terminal (5) und das Gerät (2) zum Zeitpunkt eines Bezahlvorgangs für ein abschliessendes Settlement des Bezahlvorgangs nicht mit dem Server (7) verbunden sein müssen und somit offline sein können.
In einer bevorzugten Ausführungsform kommunizieren das Gerät (2) und das Terminal (5) und gegebenenfalls die Smartcard (6) und das Terminal (5) miteinander mittels i) Kurzstrecken-Funkverbindung wie beispielsweise RFID, NFC, Bluetooth, Bluetooth Low Energy (BLE) und/oder WiFi, ii) kontaktbehafteter Verbindung wie beispielsweise USB und/oder Firewire, iii) optischer Verbindung wie beispielsweise IR, IRDA und/oder NIR, iv) akustischer Verbindung und/oder v) Datennetzwerke wie beispielsweise TCP/IP. In einer weiteren bevorzugten Ausführungsform kommunizieren das Gerät (2) und der Server (7) miteinander mit einer Datennetzwerkverbindung, insbesondere mit einer Datenfunkverbindung und/oder einer TCP/IP- Verbindung.
In einer anderen bevorzugten Ausführungsform müssen das Terminal (5) und der Server (7) miteinander zum Zeitpunkt und am Ort des Bezahlvorgangs weder eine direkte noch eine indirekte, beispielsweise über ein Gerät (2, 2"), Datennetzwerkverbindung aufweisen.
Das Gerät (2), 12') und die Geräte (2")
Das Gerät (2) des erfindungsgemässen Systems (1 ) und des erfindungsgemässen Verfahrens ist ein mobiles Gerät (2) mit oder ohne Sicherheitselement SE für die sichere Aufbewahrung und/oder Übertragung von E-Geld. Als mobiles Gerät ist das Gerät (2) ein tragbares Gerät, welches auch ohne feste Anbindung an eine Installation funktionsfähig ist. Das Gerät (2) umfasst gegebenenfalls eine Software, d.h. beispielsweise eine App, mit welcher das auf dem Gerät (2) gespeicherte E-Geld (4) verwaltet wird.
Unsichere Geräte (2), (2") sind Geräte (2), welche kein Sicherheitselement SE für die sichere Aufbewahrung und/oder Übertragung von E-Geld (4) verfügbar haben und zur Verwendung durch Dritte freigegeben ist, d.h. unsichere Geräte (2), (2") umfassen kein Sicherheitselement SE oder ein Sicherheitselement SE vom Typ 1 , welches lediglich das Speichern des kryptographischen Schlüssels und von privaten Daten, beispielsweise Angaben zur Kreditkarte, erlaubt, sowie zum Schutz des gespeicherten Geldes vor Diebstahl, z. B. mittels einer bösartigen Software, eingesetzt werden kann (siehe auch Tabelle D). Somit ist ein unsicheres mobiles Gerät (2) ein mobiles Gerät, in welchem private Daten und Software weder sicher verwahrt noch vor Fremdzugriff geschützt sind, da das unsichere Gerät (2) keine geeignete und/oder verfügbare Hardware umfasst.
Als unsichere Geräte (2), (2") gelten erfindungsgemäss auch Mobiltelefone der neueren Generation, in welche ein Sicherheitselennent SE eingebaut ist um beispielsweise Kreditkarten-Daten sicher zu speichern. Solche Sicherheitselemente SE sind in aller Regel Sicherheitselemente vom Typ 1 und können somit nicht zum sicheren bargeldlosen Bezahlen mit E-Geld (4) verwendet werden.
Erfindungsgemäss umfasst der Begriff Gerät (2) auch ein Gerät (2'), welches um ein Sicherheitselement SEALS-SE (3) und gegebenenfalls um eine Software erweitert ist. Durch diese Erweiterung bildet das Gerät (2') ein Terminal (5). Somit gilt das Gerät (2') als sicheres Gerät (2).
Die Vielzahl von Geräte (2") umfassen eine Vielzahl verschiedener Geräte (2), die typischerweise unterschiedlichen Benutzern gehören, die keinen Kontakt miteinander haben müssen. Geeignete Geräte (2, 2', 2") sind kommerziell erhältlich und dem Fachmann bekannt. Nicht-Iimitierende Beispiele von bevorzugten Geräten (2, 2', 2"), die oft auch als unsichere Geräte gelten, umfassen Mobiltelefon, Smartphone, Tablet, Notebook, Laptop und/oder Smart Wearables, auch nur Wearables genannt. Das Gerät (2) kann jedoch auch ein spezielles, typischerweise unsicheres, beispielsweise speziell für das System (1 ) bereitgestelltes und somit für den Zweck des sicheren, bargeldlosen Zahlen bestimmtes, mobiles Gerät sein.
In einer bevorzugten Ausführungsform umfasst das Gerät (2) mindestens - einen Prozessor,
- einen Speicher, - eine Stromversorgung,
- gegebenenfalls ein Display und/oder ein Eingabefeld,
- einen Mobilfunktransceiver, WLAN-Transceiver und/oder eine andere Sende/Empfangseinheit zur Kontaktaufnahme mit dem Server (7), sowie
- eine Verbindung für den Datentransfer zwischen dem Gerät (2) und dem Terminal (5), insbesondere einen Kurzstrecken-Funk- transceiver, eine kontaktbehaftete Verbindung, eine optischer Verbindung, eine akustische Verbindung und/oder eine Daten- netzwerkverbindung.
Geeignete Mobilfunktransceiver zur Kontaktaufnahme mit dem Server (7) sind dem Fachmann bekannt und kommerziell erhältlich. Geeignete Verbindungen für den Datentransfer zwischen dem Gerät (2) und dem Terminal (5) sind dem Fachmann bekannt. Nicht-Iimitierende Beispiele geeigneter Kurzstrecken-Funktransceiver, auch Nahfeld-Funktranseiver genannt, umfassen Bluetooth, Bluetooth low energy (BLE), RFID, NFC, WiFi und/oder WiFi Direct. Nicht-Iimitierende Beispiele geeigneter kontakt- behaftete Verbindung umfassen Verbindungen mittels USB und/oder Firewire. Nicht-Iimitierende Beispiele geeigneter optischer Verbindung umfassen IR (Infrarot), IRDA (Infrarot Industriestandard) und/oder NIR (Nahes Infrarot). Zudem umfassen nicht-limitierende Beispiele geeigneter Datennetzwerkverbindung TCP/IP Verbindungen. Als Datentransfer zwischen dem Gerät (2) und dem Terminal (5) werden Bluetooth, Bluetooth low energy (BLE), RFID, NFC, ZigBee, und/oder WiFi bevorzugt.
Das Sicherheitselement SEALS-SE (3) Unter dem Begriff Sicherheitselement, d.h. Sicherheitselement SE, wird erfindungsgemäss ein Chip verstanden, welcher beliebige Operationen, inklusive kryptographische Operationen in sicherer Umgebung, ermöglicht und welcher einen sicheren Schlüssel- und Daten-Speicher umfasst.
Das erfindungsgemäss eingesetzte Sicherheitselement SEALS-SE (3) ist ein Sicherheitselement SE vom Typ 3 (siehe Tabelle D) mit spezifischen kryptographischen Fähigkeiten, welche lokal ein abschliessendes Settlement eines Bezahlvorgangs ermöglichen, auch wenn das Gerät (2) und das Terminal (5) offline sind. Zudem ist das Sicherheitselement SEALS-SE (3) geeignet für die Aufbewahrung und Übertragung von E-Geld (4) mit abschliessendem Settlement auch mit einem Gerät (2) ohne Sicherheitselement SE und ohne Internet-Anbindung zum Zeitpunkt des Bezahlvorgangs. Die Abkürzung SEALS-SE steht für Secure E-money Accounting & Local Settlement - Secure Element.
Tabelle D: Definition der Sicherheitselemente SE vom Typ 1 , Typ 2 und Typ
3. Der Sicherheitselement Typ 3 entspricht dem Sicherheitselement SEALS-SE (3).
Kryptographische
Sicherer
Operationen in sicherer Accounting/
SicherheitsE-Geld- Umgebung möglich & Settlement element SE Speicher
sicherer Schlüssel- und möglich? vorhanden?
Daten-Speicher vorhanden?
Kein SE nein nein nein
Typ 1 a) ja nein nein
Typ 2 b) ja ja nein
Typ 3 c) ja ja ja a) Ein Sicherheitselement SE vom Typ 1 erlaubt das sichere Speichern des kryptographischen Schlüssels und von Daten, wie beispielsweise Angaben zur Kreditkarte.
b) Ein Sicherheitselement SE vom Typ 2 erlaubt neben dem Speichern des kryptographischen Schlüssels und von Daten zusätzlich das sichere Speichern von E-Geld (4).
c) Ein Sicherheitselement SE vom Typ 3 erlaubt zusätzlich zu den Fähigkeiten eines Sicherheitselement SE vom Typ 2 auch das Aufbewahren von E-Geld (4) in einem Zahlungsmittel ohne Sicherheitselement SE, d.h. Gerät (2), und das Transferieren von E-Geld (4) von einem Zahlungsmittel ohne Sicherheitselement SE, beispielsweise Gerät (2), zu einem Terminal, d.h. Terminal (5), wobei nur das Terminal (5) zwingend ein Sicherheitselement SE vom Typ 3 benötigt. Ein hierzu geeignetes Sicherheitselement SE ist das Sicherheitselement SEALS- SE. Zudem erlaubt das Sicherheitselement Typ 3 das Settlement des Bezahlvorgangs, auch wenn das Zahlungsmittel, z.B. das Gerät (2), und das Terminal (5) offline sind.
Das Sicherheitselement SEALS-SE (3), nachfolgend auch nur Sicherheitselement (3), SEALS-SE (3) oder Sicherheitselement SEALS-SE genannt, ist sowohl für die sichere Aufbewahrung, d.h. Speicherung, von E-Geld (4) wie auch für die sichere Übertragung von E-Geld (4) von einem Gerät zu einem anderen Gerät mit abschliessendem Settlement geeignet, wobei für das abschliessende Settlement zum Zeitpunkt des Bezahlvorgangs mit dem Sicherheitselement SEALS-SE (3) keine Internet-Anbindung notwendig ist. Weist ein Gerät, beispielsweise ein Terminal (5), ein solches Sicherheitselement SEALS-SE (3) auf, kann - aufgrund der Fähigkeiten des Sicherheitselements SEALS-SE (3) - das andere Gerät ein unsicheres Gerät (2) ohne spezifische Sicherheitsfunktionen sein. Somit ist das Sicherheitselement SEALS-SE (3) insbesondere geeignet für die sichere Aufbewahrung von E-Geld (4) auf einem Gerät (2) und die sichere Übertragung von E-Geld (4), insbesondere für Offline-Zahlungen mit E-Geld (4, 4*) von einem Gerät (2) an einem Terminal (5) und/oder von einer Smartcard (6) an einem Terminal (5). Dieser Bezahlvorgang kann in der Regel auch kontaktlos erfolgen.
Das Sicherheitselement SEALS-SE (3) des erfindungsgemässen Systems (1 ) ist zudem ein registriertes und nicht fälschbares Sicherheitselement SE, welches dahingehend qualifiziert ist, dass damit, ohne die zusätzliche Autorisierung durch einen zentralen Server und somit offline, ein E-Geld- Bezahlvorgang mit unbedingtem Settlement mit abschliessender Wirkung durchgeführt werden kann. Im erfindungsgemässen System (1 ) ist das Sicherheitselement SEALS-SE (3) für sicherheitsrelevante Aufgaben bei Transaktionen zwischen Gerät (2) und Terminal (5) und zwischen Smartcard (6) und Terminal (5) zuständig. Das Sicherheitselement SEALS-SE (3) schützt das E-Geld (4, 4*) vor Missbrauch, ungewollter Fremdeinwirkung und/oder Manipulation. Das Sicherheitselement SEALS-SE (3) kann auf einem herkömmlichen Sicherheitselement SE basieren, welches beispielsweise mit einer SpezialSoftware zu einem SEALS-SE (3) verarbeitet wird. Der Fachmann kann solche Sicherheitselemente SEALS-SE (3) beispielsweise mittels geeigneter Software herstellen. Das Sicherheitselement SEALS-SE (3) unterscheidet sich somit von einem herkömmlichen, kommerziell erhältlichen Sicherheitselement SE dergestalt, dass das Sicherheitselement SEALS-SE (3) für die E-Geld-Übertragung von einem Gerät (2) auf ein Terminal (5) und/oder umgekehrt ausgelegt ist, wobei nur das Terminal (5) mit einem entsprechenden SEALS-SE ausgestattet sein muss und nicht das Gerät (2), und das E-Geld auf dem Gerät (2) - ohne den Schutz durch ein lokales Sicherheitselement SEALS-SE - im herkömmlichen unsicheren Datenspeicher hinterlegt ist. Das Sicherheitselement SEALS-SE (3) im Terminal (5) übernimmt dabei nebst dem Settlement auch die Zahlung vorbereitende Aufgabe der Missbrauchs- und Fälschungsprüfung. Das Sicherheitselement SEALS-SE (3) kann bis zu einem sehr hohen Grad eine Doppelverwendung von ein und demselben E-Geld (4) - z.B. infolge eines System-Backups - erkennen und verhindern. Somit weist das Sicherheitselement SEALS-SE (3) wesentlich höhere kryptographische Eigenschaften aus als ein herkömmliches, kommerziell erhältliches Sicherheitselement SE vom Typ 1 oder Typ 2.
Demzufolge stellt das Sicherheitselement SEALS-SE (3) ein Sicherheitselement SE vom Typ 3 dar und erlaubt neben dem Speichern von Daten wie kryptographische Schlüssel, d.h. Schlüssel, und Angaben zur Kreditkarte (Typ 1 ) und dem Speichern von E-Geld (Typ 2) zusätzlich das Transferieren von E-Geld (4) zwischen Zahlungsmittel, d.h. Gerät (2) und Terminal, d.h. Terminal (5), wobei nur das Zahlungsmittel oder das Gerät zwingend ein solches Sicherheitselement SE benötigt.
Das erfindungsgemäss eingesetzte Sicherheitselement SEALS-SE (3) unterscheidet sich somit deutlich von Sicherheitselementen SE, welche teilweise in Mobiltelefonen der neusten Generation eingesetzt werden (Sicherheitselemente vom Typ 1 ). Denn solche, kommerziell erhältliche Sicherheitselemente SE eignen sich aufgrund ihrer Ausprägung, beispielsweise aufgrund der in den Sicherheitselementen enthaltenen Software, nicht für sichere Offline-Zahlungen mit E-Geld (4).
Die vom erfindungsgemäss eingesetzten Sicherheitselement SEALS-SE (3) ausgeführten sicherheitsrelevanten Aufgaben umfassen typischerweise Authentifizierung des Geräts (2), die Stellvertretung des Servers (7) im Terminal (5), beispielsweise durch Verifizierung und/oder Signierung der Spend- und Load-Tokens, sowie das Erkennen von bestimmten Betrugsversuchen am Terminal, wie zum Beispiel Doppel- oder Mehrfachzahlung mit nur einer Verrechnung. Zudem kann das Sicherheitselement SEALS-SE (3) vorteilhafterweise Signaturen generieren und überprüfen, die Load-Token TL (41 ) und/oder Spend-Token TS (42) Zwischenspeichern, neue E-Geld Token (41 , 42) generieren, sowie bestimmte Manipulations- und Betrugsversuche verhindern. Das Sicherheitselement SEALS-SE (3) überwacht auch, welcher Betrag vom Gerät (2) zum Terminal (5) transferiert wird. Ferner stellt das SEALS-SE (3) Werkzeuge für die Telegramm-Verschlüsselung zur Verfügung.
Das Sicherheitselement SEALS-SE (3) kann das erhaltene E-Geld (4, 4*) im Terminal (5) nicht ohne die Beteiligung von E-Geld (4, 4*) eines Geräts (2, 2") verändern. Auch tritt das Sicherheitselement SEALS-SE (3) im System (1 ) als Schiedsrichter auf, vertritt die Interessen des Systems (1 ), bietet Schutz vor Betrug, und schützt die Integrität des Systems (1 ).
In einer sehr bevorzugten Ausführungsform des Systems (1 ) wird das Sicherheitselement SEALS-SE (3) in jedem Terminal (5) eingesetzt. Dadurch können im erfindungsgemässen System (1 ) auch mit mobilen Geräten (2, 2") ohne Sicherheitselement, d.h. auch mit unsicheren Geräten (2, 2"), Bezahlvorgänge durchgeführt werden.
In einer anderen bevorzugten Ausführungsform stellt das Sicherheitselement SEALS-SE (3) im Terminal (5) ein physisches Sicherheitselement dar und umfasst vorteilhafterweise einen Prozessor mit kryptographischer Tauglichkeit.
Das Terminal (5) Unter Ternninal (5) wird erfindungsgemäss ein beliebiger Point-of-Sale (POS) verstanden, bei welchem ein Bezahlvorgang mit einem Gerät (2, 2") mit E- Geld (4, 4*) durchgeführt werden kann. Wird im erfindungsgemassen System (1 ) das erfindungsgemasse E-Geld (4*) eingesetzt, kann ein Bezahlvorgang an einem Terminal (5) mit oder ohne Sicherheitselement SEALS-SE durchgeführt werden. Für eine erhöhte Sicherheit des Systems (1 ) ist es jedoch in der Regel vorteilhaft, wenn der Bezahlvorgang mit E-Geld (4*) an einem Terminal (5) mit einem Sicherheits- element SEALS-SE durchgeführt wird. Dadurch kann auch mit einem Gerät (2, 2") ohne Sicherheitselement ein sicherer Bezahlvorgang an einem Terminal (5) offline und mit abschliessendem Settlement durchgeführt werden. Wird im erfindungsgemässen System (1 ) nicht spezifisch E-Geld (4*), sondern ein beliebiges E-Geld (4) eingesetzt, umfasst das Terminal (5) erfindungsgemäss ein Sicherheitselement SEALS-SE. Dadurch kann auch mit einem Gerät (2, 2") ohne Sicherheitselement ein sicherer Bezahlvorgang an einem Terminal (5) offline und mit abschliessendem Settlement durchgeführt werden.
Das Terminal (5), d.h. Payment-Terminal (5), im erfindungsgemässen System (1 ) führt die Guthaben-Transaktionen vom Gerät (2) zum Terminal (5) aus, sofern das Gerät (2) dem Terminal (5) seine Einwilligung dazu gibt, und vom Terminal (5) zum Gerät (2) aus, sofern das Terminal (5) dem Gerät (2) seine Einwilligung dazu gibt. Eine Einwilligung ist gegeben, wenn sowohl das Gerät (2) als auch das Terminal (5) im Glauben ist, sein Gegenüber sei integer, authentisch und kooperativ. Somit erfüllt das Terminal die Aufgaben des Verkaufsprozesses, wie die Übergabe eines Betrags vom Gerät zum Terminal, Start der Produktausgabe oder Dienstleistung - gegebenenfalls nach Erstellung und Übermittlung einer Quittierung an das Gerät (2), sowie gegebenenfalls Streuung der Quittungen über eine Vielzahl von Geräten (2") zur Übermittlung an den Server (7). Diese Streuung wird bevorzugt so lange durchgeführt, bis beim Terminal (5) mindestens eine Empfangsbestätigung vom Server (7) eingetroffen ist, welche den Erhalt der Quittung durch den Server (7) bestätigt.
Das Terminal (5) speichert zudem getätigte Transaktionen für Abrechnungsund Kontroll-Zwecke, und versendet die gespeicherten Transaktionen als Transaktions-Telegramme über das Gerät (2) und/oder die Vielzahl der Geräte (2") zum Server (7). Geeignete Terminals (5) sind kommerziell erhältlich und dem Fachmann bekannt.
Der Begriff Terminal (5) umfasst bevorzugt einen Prozessor, einen Speicher und/oder eine Software. Das Terminal wird bevorzugt über eine Benutzer- schnittsteile bedient und/oder über eine Maschinenschnittstelle gesteuert. Das Terminal (5) ist typischerweise auch Teil einer Kasse oder mit einer Kasse verbunden.
Das Terminal (5), d.h. das Payment-Terminal (5), des erfindungsgemässen Systems (1 ) und des erfindungsgemässen Verfahrens umfasst mindestens ein Sicherheitselement SEALS-SE (3). Das Sicherheitselement SEALS-SE (3) verifiziert zu Beginn eines Bezahlvorgangs, ob das auf dem Gerät (2) gespeicherte E-Geld (4, 4*) vertrauenswürdig und konsistent, d.h. fehlerfrei, ist und erkennt und verhindert die lokal erkennbaren Betrugsversuche indem es mindestens die betreffenden Signaturen der jüngsten Load-Token TL (41 ) und/oder Spend-Token TS (42) nachrechnet und nach Token-Duplikaten, und somit Doppelzahlungen, sogenannte „Double-Spends", sucht. Nach erfolgtem Bezahlvorgang am Terminal (5) bestätigt typischerweise das Sicherheitselement SEALS-SE (3) im Terminal (5) die Gültigkeit des Load- Token TL (41 ) und/oder des Spend-Token TS (42) mit einer Signatur, d.h. es versieht den Token mit einem komplizierten, mit ihm in eindeutigem Zusammenhang stehenden Bitmuster, dessen Originalität und Echtheit im Wesentlichen jedermann erkennen und validieren kann, aber nur das Sicherheitselement SEALS-SE (3) selbst und der Server (7) erstellen können.
Tabelle E: Einfluss der Sicherheitselemente SE-Typen im Zahlungsmittel und im Terminal (5) auf Bezahlvorgänge mit E-Geld (4). Alle aufgeführten Zahlungsmittel erlauben mit dem entsprechenden Sicherheitselement im Terminal das Laden, d.h. Aufbuchen, und das Abbuchen von E-Geld (4), Offline-Transaktionszeiten von unter 5 Sekunden sowie ein abschliessendes Offline-Settlement.
a) Siehe Tabelle A.
b) Siehe Tabellen A, B, C und D zu Sicherheitselement SE Typ 1 , 2 und 3. c) Siehe Tabellen A, B und C.
d) Da das Sicherheitselement SE im Terminal (5) ein Sicherheitselement vom Typ 1 ist, welches kein E-Geld speichern kann, kann kein E-Geld von der Guthabenkarte zum Terminal (5) verschoben werden, d.h. es kann nur eine Entwertung der Guthabenkarte durchgeführt werden.
Die Tabelle E zeigt deutlich, dass alleine im Zahlungsmittel der vorliegenden Erfindung, d.h. im Gerät (2), kein Sicherheitselement SE vorhanden sein muss und trotzdem ein abschliessendes Settlement des Bezahlvorgangs erzielt werden kann. Zudem bleibt die Transaktionszeit bei einer Offline Zahlung höchstens im niedrigen Sekundenbereich. Dies geschieht erfindungsgemass im Wesentlichen dadurch, dass das Terminal (5) mit einem Sicherheitselement SE vom Typ 3, d.h. ein Sicherheitselement SEALS-SE (3), ausgerüstet wird.
Somit wird durch das erfindungsgemass eingesetzte und erfindungsgemass verwendete Sicherheitselement SEALS-SE (3) im Terminal (5) ermöglicht, dass insbesondere auch mit einem unsicheren Gerät (2) an einem Terminal (5) unter Verwendung eines hohen Sicherheitsstandards mittels E-Geld (4) bezahlt werden kann, sogar wenn sowohl das Gerät (2) wie auch das Terminal (5) zum Zeitpunkt eines Bezahlvorgangs keine Verbindung mit einem sicheren Server (7) aufweisen und somit offline sind.
Somit muss erfindungsgemäss das Terminal (5) zum Zeitpunkt eines Bezahlvorgangs nicht mit dem Server (7) verbunden sein und kann - auch permanent - offline sein.
Das Terminal (5) ist ein Point-of-Sale, insbesondere ein Verkaufsautomat, eine sog. Vending Machine, wie beispielsweise ein Getränke-, Kaffee-, Münz-, Zeitungs-, Snack-, Briefmarken-, Parkschein- und/oder Zigarettenautomat sein. Geeignete Terminals (5) sind dem Fachmann bekannt. Das Terminal (5) kann mit einer Kasse verbunden sein oder das Terminal (5) kann in eine Kasse integriert sein. Weder das Terminal (5) noch die Kasse müssen zu irgendeiner Zeit - auch nicht während einem Bezahlvorgang - mit dem Server (7) verbunden sein. Somit muss das Terminal (5) - und die Kasse, sofern vorhanden - zu keiner Zeit einen Telefon und/oder Internet- anschluss aufweisen und es kann permanent offline sein.
In einer besonders bevorzugten Ausführungsform umfasst das Terminal (5) einen Kurzstrecken-Funktransceiver, eine kontaktbehaftete Verbindung, eine optischer Verbindung, eine akustische Verbindung und/oder eine Datennetzwerkverbindung für den Datentransfer zwischen dem Gerät (2) und dem Terminal (5).
In einer bevorzugten Ausführungsform umfasst das Terminal (5) mindestens - einen Prozessor,
- einen Speicher,
- eine Stromversorgung,
- eine Benutzer-Schnittstelle, insbesondere ein Touch-Display, und/oder eine Maschinen-Schnittstelle, wie beispielsweise ein USB Anschluss,
- einen Kurzstrecken-Funktransceiver, eine kontaktbehaftete Verbindung, eine optische Verbindung, eine akustische Verbindung und/oder eine Datennetzwerkverbindung für den Datentransfer zwischen dem Gerät (2) und dem Terminal (5), sowie
- das Sicherheitselement SEALS-SE (3).
In einer anderen bevorzugten Ausführungsform ist das Terminal (5) des erfindungsgemässen Systems (1 ) durch ein Gerät (2') gebildet, wobei das Gerät (2') ein Gerät (2) umfasst, welches um ein Sicherheitselement SEALS- SE (3) und gegebenenfalls um eine Software und/oder eine Hardware erweitert ist. Dabei kann das Sicherheitselement SEALS-SE (3) fest im Gerät (2') integriert und/oder extern an das Gerät (2') angeschlossen sein. Diese Ausführungsform ist insbesondere dann von Vorteil, wenn ein mobiles Multifunktions-Terminal (5) gewünscht wird, welches beispielsweise auch alle Vorteile eines Geräts (2') aufweist. Ein solches mobiles Terminal (5) umfassend ein Gerät (2') mit Sicherheitselement SEALS-SE (3) kann beispielsweise bei bargeldlosen Strassen- und/oder Strandverkäufen äusserst vorteilhaft sein.
Die Smartcard (6)
Die Smartcard (6) des erfindungsgemässen Systems (1 ) ist optional und kann vom Benutzer des Geräts (2) und/oder von einem anderen Benutzer, welcher kein Gerät (2) haben muss, unabhängig von einem Gerät (2) eingesetzt werden. Auf der Smartcard (6) wird E-Geld (4) gespeichert, mit welchem bargeldlos und offline bezahlt werden kann.
Die Smartcard (6) ist typischerweise eine herkömmliche, kommerziell erhältliche Guthabenkarte. Sie umfasst in der Regel ein Sicherheitselement SE vom Typ 2 für die sichere Aufbewahrung und/oder Übertragung von E- Geld, um die notwendige Sicherheit gegen Fälschung und Missbrauch zu gewährleisten. Geeignete Smartcards (6) sind dem Fachmann bekannt.
Erfindungsgemäss gilt die Smartcard (6) als sicher, falls sie über ein Sicherheitselement vom Typ 2 oder Typ 3 verfügt und zur Verwendung durch Dritte freigegeben ist. Somit umfasst die erfindungsgemäss eingesetzte Smartcard (6) ein Sicherheitselement vom Typ 2 oder Typ 3.
Das E-Geld (4) Elektronisches Geld, d.h. E-Geld, ist auch unter den Begriffen E-Cash, Computergeld, digitales Geld und Cybergeld bekannt. Neben dem Geld von Zentralbanken, auch Papiergeld genannt, und dem Buchgeld der Geschäftsbanken ist das E-Geld eine dritte, neuere Erscheinungsform von Geld.
Der Begriff E-Geld (4) umfasst alle Arten von E-Geld, insbesondere auch das erfindungsgemässe und erfindungsgemäss eingesetzte E-Geld (4*). Wird im erfindungsgemassen System (1 ) E-Geld (4, 4*) zu einem mobilen Gerät (2) transferiert, wird das E-Geld (4, 4*) auf der Guthabenkarte des mobilen Geräts (2) gespeichert. Bei einem Bezahlvorgang wird das E-Geld (4, 4*) - oder ein Teil davon - vom Gerät (2) zum Terminal (5) transferiert. Somit ist der Besitzer des E-Geldes (4, 4*) auch der Besitzer des mobilen Geräts (2) resp. des Terminals (5). Im erfindungsgemässen System (1 ) ist es daher nicht notwendig, dass der Besitzer des E-Geldes (4, 4*) im Pool-Konto, in einem Register oder anderweitig eingetragen ist.
In einer bevorzugten Ausführungsform umfasst der Begriff E-Geld (4) das E- Geld (4*) sowie E-Geld in Form von Landeswährungen, das beispielsweise auf Guthabenkarten gespeichert werden kann, jedoch keine Krypto- währungen.
In einer besonders bevorzugten Ausführungsform umfasst der Begriff E-Geld (4) das erfindungsgemässe und/oder erfindungsgemäss eingesetzte E-Geld (4*).
Der Begriff E-Geld (4*) umfasst das erfindungsgemäss eingesetzte E-Geld (4*) umfassend mindestens ein Load-Token TL (41 ) und nach einem ersten Bezahlvorgang auch mindestens ein vom Load-Token TL verschiedenes Spend-Token TS (42), sowie das erfindungsgemässe E-Geld (4*). Das E-Geld (4) wird auf dem Gerät (2) und gegebenenfalls auf der Smartcard (6) gespeichert und bevorzugt in einer sogenannten elektronische Geldbörse, auch E-Geldbörse oder E-Purse genannt, mit einer Software verwaltet. Das E-Geld (4) kann in einer beliebigen Währung gespeichert werden. Es ist auch möglich, E-Geld (4) in verschiedenen Währungen zu speichern und gegebenenfalls mit der entsprechenden Währung zu zahlen.
Das im erfindungsgemässen System (1 ) und im erfindungsgemässen Verfahren eingesetzte E-Geld (4) umfasst in einer besonders bevorzugten Ausführungsform E-Geld (4*) umfassend mindestens zwei voneinander unterschiedliche Token, nämlich ein Load-Token TL (41 ) und ein Spend- Token TS (42). Das E-Geld (4*) kann auch weitere Token umfassen, wobei die weiteren Token andere Aspekte einer Transaktion festhalten und/oder übermitteln können.
Das erfindungsgemässe E-Geld (4*) zum sicheren Bezahlen mit dem Gerät (2), insbesondere zum sicheren bargeldlosen Bezahlen mit einem unsicheren Gerät (2), an einem Terminal (5) gemäss System (1 ), umfasst mindestens ein Load-Token TL (41 ) und nach einem ersten Bezahlvorgang auch mindestens ein vom Load-Token TL (41 ) verschiedenes Spend-Token TS (42). Dabei unterscheidet sich das Load-Token TL (41 ) vom Spend-Token TS (42) nicht nur im Inhalt der Token, sondern die Art der Informationen, die im Load-Token TL (41 ) enthalten sind, unterscheiden sich von den Informationen, die im Spend-Token TS (42) enthalten sind, deutlich.
Das Load-Token TL (41 ) ist auf dem Gerät (2) und/oder der Smartcard (6) gespeichert und umfasst mindestens den Betrag einer Gutschrift und vorzugsweise auch den zum Zeitpunkt der Erstellung dieses Tokens aktuellen Wert des auf dem Gerät (2) und/oder der Smartcard (6) gespeicherten E-Gelds (4*). Zudem umfasst das Load-Token TL (41 ) bevorzugt auch Informationen zum Gerät (2) resp. zum Inhaber des Geräts (2).
Das Spend-Token TS (42) hingegen umfasst mindestens den Warenwert der bei einem spezifischen Bezahlvorgang gekauften/verkauften Waren und bevorzugt weitere Informationen zum jeweiligen Bezahlvorgang wie beispielsweise Datum, Restguthaben, Produktname und/oder Transaktionszähler, insbesondere zu dem am Bezahlvorgang beteiligten Gerät (2) und/oder der Smartcard (6) sowie dem am Bezahlvorgang beteiligten Terminal (5), und repräsentiert damit einen Bezahlvorgang mit E-Geld (4*) vom Gerät (2) zum Terminal (5), wobei das Spend-Token TS (42) mindestens auf dem Gerät (2) und/oder Terminal (5) gespeichert ist. Wird mit einem Gerät (2) an mindestens zwei unterschiedlichen Terminals (5) ein Bezahlvorgang abgewickelt, wird für jedes einzelne Terminal (5) und jede Währung ein separates Spend-Token TS (42) erstellt.
Zudem wird der aktuelle Wert des auf dem Gerät (2) gespeicherte E-Geldes (4*) durch die Summe der Load-Token TL (41 ) abzüglich der Summe der Spend-Token TS (42) repräsentiert, wobei das mindestens eine Load-Token TL (41 ) und das gegebenenfalls mindestens eine Spend-Token TS (42) bevorzugt eine Information enthält, welche eine chronologische Anordnung erlaubt. Eine solche Information kann beispielsweise ein Zeitstempel, ein Token-Index und/oder ein Transaktionszähler sein. Bei einem Bezahlvorgang repräsentiert das Spend-Token TS (42) den Warenwert der beim Bezahlvorgang gekauften/verkauften Waren, der als E- Geld (4*) in Form des Spend-Tokens TS (42) vom Gerät (2) und/oder der Smartcard (6) zum Terminal (5) übertragen wird. Der im Spend-Token TS (42) repräsentierte Warenwert wird vom Guthaben auf dem Gerät (2) und/oder der Smartcard (6) subtrahiert und gleichzeitig dem Terminal (5) gutgeschrieben, wobei das Guthaben auf dem Gerät (2) durch die Differenz aller auf dem Gerät (2) gespeicherten Load-Token TL (41 ) und Spend-Token TS (42) repräsentiert wird und die Gutschrift im Terminal (5) durch den neu erzeugten Spend-Token TS (42) repräsentiert wird. In einer bevorzugten Ausführungsform umfasst das auf dem Gerät (2) gespeicherte E-Geld (4*) nach Bezahlvorgängen an einer Vielzahl von Terminals (5) für jede Währung i) ein Load-Token (41 ) und ii) für jedes Terminal (5) ein anderes Spend-Token (42) und somit eine Vielzahl an Spend-Token (42).
In einer Ausführungsform wird das Spend-Token TS (42) des im System (1 ) bevorzugt eingesetzten E-Gelds (4*) und/oder des erfindungsgemässen E- Gelds (4*) durch ein Transfer-Token TT (421 ) und ein Terminierungs-Token TR (422) dargestellt. Das Transfer-Token TT (421 ) repräsentiert ein Guthaben, d.h. ein Warenwert, welches von einem Gerät (2) an ein Terminal (5) und/oder von einem Terminal (5) an ein Gerät (2) übertragen wurde. Das Terminierungs-Token TR (422) repräsentiert einen Kauf, d.h. Informationen zu dem oder den gekauften Waren, mit dem transferierten Guthaben am Terminal (5). In dieser Ausführungsform wird die Übertragung des Guthabens zum Verkäufer vom konkreten Kauf getrennt. Überraschenderweise steigt dadurch die Robustheit gegen Verbindungs-Unterbrüche zwischen Terminal (5) und Gerät (2). Für die Rückumwandlung von E-Geld (4*) in Buchgeld werden nun sowohl das entsprechende Transfer-Token TT (421 ) sowie das Terminierungs-Token TR (422) benötig, welche zusammen das Spend-Token TS (42) repräsentieren. Somit wird mit dem Begriff Spend- Token TS (42) auch die beiden Begriffe Transfer-Token TT (421 ) und Terminierungs-Token TR (422) mitumfasst.
Das mindestens eine Load-Token TL (41 ) des E-Gelds (4*) ist auf dem Gerät (2) gespeichert und alle Load-Token TL (41 ) des E-Gelds (4*) auf dem Gerät (2) zusammen umfassen die Summe der Gutschriften des auf dem Gerät (2) gespeicherten E-Gelds (4*) einer Währung.
Das gegebenenfalls mindestens eine Spend-Token TS (42) des E-Gelds (4*) ist auf dem Gerät (2) gespeichert und alle Spend-Token TS (42) des E-Gelds (4*) auf dem Gerät (2) zusammen umfassen die Summe der Zahlungen des auf dem Gerät (2) gespeicherten E-Gelds (4*) einer Währung.
In einer Ausführungsform des E-Gelds (4*) umfasst ein Load-Token TL (41 ) nur die Informationen zu einer Gutschrift und ein Spend-Token TS (42) nur die Informationen zu einer Zahlung. Die einzelnen Load-Token TL (41 ) und einzelnen Spend-Token TS (42) der aktuellen und von früheren Transaktionen werden zu unterschiedlichen Ketten, sogenannte Chains, aneinander gereiht, wobei diese Chains jeweils unterschiedlichen Zwecken dienen können:
- Eine Kette kann beispielsweise alle Load-Token TL (41 ) und Spend-Token TS (42) von einem einzigen Gerät (2) umfassen und so eine sogenannte Value-Chain CV des Geräts (2) bilden, wodurch das Guthaben eines Geräts (2) dargestellt werden kann. - Eine andere, zweite Kette kann beispielsweise aus allen Spend-
Token TS (42) von einem einzigen Gerät (2) mit einem einzigen, spezifischen Terminal (5) eine sogenannte Transfer-Chain CT bilden. Dadurch repräsentiert eine solche Transfer-Chain CT alles E-Geld (4*), welches vom Gerät (2) zum spezifischen Terminal (5) übertragen wurde.
- Eine weitere, dritte Kette kann beispielsweise aus allen Spend- Token TS (42) aller Geräte (2, 2") mit einem einzigen Terminal (5) eine sogenannte POS-Chain CP bilden. Dadurch repräsentiert eine solche POS-Chain CP alles vom Terminal (5) eingenommene E- Geld. Zudem können mit den Load-Token TL (41 ) und/oder Spend-Token TS (42) auch weitere zweckdienliche Ketten gebildet werden.
In einer anderen Ausführungsform beinhaltet eine Kette gegebenenfalls mindestens ein Load-Token TL (41 ) und gegebenenfalls mindestens ein Spend-Token TS (42). Die Summe aller Gutschriften der Load-Token TL (41 ) abzüglich der Summe aller Zahlungen der Spend-Token TS (42) bildet den monetären Nominalwert einer Kette. Bei einer neuen Gutschrift resp. Zahlung wird die gesamte bisherige Kette in stark komprimierter Form zum neuen Load-Token TL (41 ) respektive neuen Spend-Token TS (42) angehängt. Somit umfasst der jeweils neuste, und somit aktuellste, Token (41 , 42) auch die Historie aller früheren Transaktionen als sogenannter Hash. Solche Ketten mit komprimierter Historie werden Hash-Chain oder Hash-Ketten genannt.
In einer bevorzugten Ausführungsform des erfindungsgemässen Systems (1 ) und des erfindungsgemässen E-Geldes (4*) ist auf dem Gerät (2) und gegebenenfalls der Smartcard (6) für jede vorhandene Währung eine Chain, oder eine Hash-Chain, mit mindestens einem Load-Token TL (41 ) und nach einem ersten Bezahlvorgang auch mindestens ein vom Load-Token TL (41 ) verschiedenes Spend-Token TS (42) gespeichert. Durch die Reihenfolge der Token ist somit die Historie der Gutschriften und Belastungen in der jeweiligen Währung abgebildet. Durch diese Anordnung enthält das Load-Token TL (41 ) im Wesentlichen die Information über eine Gutschrift auf das auf dem Gerät (2) bevorzugt gespeicherte E-Geld (4*) sowie die Historie der älteren Load-Token TL (41 ) als Hash, d.h. in stark komprimierter Form. Und ein entsprechendes Spend- Token TS (42) enthält im Wesentlichen nur die Information zum aktuellsten Bezahlvorgang zwischen dem Gerät (2) und einem spezifischen Terminal (5), respektive der Smartcard (6) und einem spezifischen Terminal (5), sowie die Historie der älteren Spend-Token TS (42) als Hash, d.h. in stark komprimierter Form. Dies führt zu wesentlichen Verbesserungen beispielsweise bei der Missbrauchserkennung und bei der Zahlungsabwicklung, einer schnelleren Übermittlung der Informationen zum Gerät (2), der Vielzahl von Geräten (2") sowie zum Server (7) und somit zur Beschleunigung der Bezahlvorgänge.
In einer bevorzugten Ausführungsform basiert das erfindungsgemäss bevorzugt eingesetzte E-Geld (4*) und/oder das erfindungsgemässe E-Geld (4*) auf einer Hash-Chain, wobei mindestens eine Hash-Chain verwendet wird umfassend mindestens einen Load-Token TL (41 ) und gegebenenfalls mindestens einen Spend-Token TS (42).
In einer weiteren bevorzugten Ausführungsform basiert das erfindungsgemäss bevorzugt eingesetzte E-Geld (4*) und/oder das erfindungsgemässe E-Geld (4*) auf mindestens zwei unterschiedlichen Hash-Chains. Eine erste Hash-Chain umfasst mindestens einen Load-Token TL (41 ), gegebenenfalls die älteren Load-Token (41 ) als Historie, sowie gegebenenfalls mindestens einen Spend-Token (42). Eine zweite Hash- Chain umfasst mindestens einen Spend-Token TS (42) der ersten Hash- Chain und gegebenenfalls die älteren Spend-Token (42) als Historie.
Die Unterteilung des im erfindungsgemässen System (1 ) bevorzugt eingesetzten E-Geld (4*) sowie im erfindungsgemässen E-Geld (4*) und in dem erfindungsgemässen Verfahren eingesetzte E-Geld (4*) in mindestens zwei voneinander unterschiedliche Token (41 , 42) weist überraschenderweise eine Vielzahl von Vorteilen auf. So können damit unterschiedliche Chains und Hash-Chains erstellt werden. Dadurch ist es möglich, Transaktionen mit äusserst hohen Sicherheitsanforderungen offline zu tätigen, was mit heutigen Systemen unter Verwendung von mobilen - typischerweise unsicheren - Geräten alleine nicht möglich ist. Zudem wird die Anzahl der zur RückVerfolgbarkeit notwendigen Hash-Chain-Elemente, d.h. Token (41 , 42), stark reduziert, wodurch eine viel schnellere Verarbeitung erlaubt wird. Mit anderen Worten: Das Speichern, Verarbeiten und/oder Übermitteln kann mit zwei voneinander unabhängigen Arten von Hash- Chains viel schneller durchgeführt werden als wenn alle Informationen auf einer einzelnen Hash-Chain vorhanden sind. Somit wird der Bezahlvorgang deutlich beschleunigt und es wird weniger Speicherplatz benötigt. Zudem wird das System (1 ) wesentlich weniger anfällig auf Fehler, was die Sicherheit des Systems (1 ) wiederum erhöht.
Auch kann eine Hash-Chain, mit welchem der Wert des E-Gelds (4*) repräsentiert wird, auf einem unsicheren Gerät, d.h. beispielsweise auf dem Gerät (2), sicher gespeichert werden, obwohl das Gerät (2) kein Sicherheitselement aufweist, welches das E-Geld (4*) vor ungewollten Manipulationen schützt. Dies wird unter anderem dadurch unterstützt, wenn einzelne Load Token TL (41 ) und/oder Spend Token TS (42) der im Gerät (2) gespeicherten Chain resp. Hash-Chain auch in anderen Chains resp. Hash- Chains vorhanden sind. Dadurch wird eine Manipulation in der Regel schon beim Zahlungsversuch und spätestens auf dem Server erkannt und sofort korrigiert, beispielsweise durch Nachbelastung und/oder indem das Gerät, auf welchem eine Manipulation erkannt wurde, im System (1 ) gesperrt wird.
Der Server (7)
Das erfindungsgemässe System (1 ) umfasst einen oder mehrere Server (7), Der Server (7) ist typischerweise mittels einer unsteten und hochgradig asynchronen Verbindung mit den Geräten (2, 2") verbunden. Der Server (7) muss gemäss System (1 ) nicht mit dem Terminal (5) direkt in Verbindung stehen, sondern nur indirekt über die Geräte (2, 2"). Zudem ist der Server (7) für offline Bezahlvorgänge mit abschliessendem Settlement nicht notwendig, d.h. er validiert keinen Bezahlvorgang und nimmt somit am abschliessenden Settlement eines Bezahlvorgangs nicht teil.
Der im System (1 ) erfindungsgemäss eingesetzte Server (7) ist typischerweise ein zentraler Server (7), welcher beispielsweise im Internet, der Cloud und/oder innerhalb eines Firmengeländes angeordnet ist. Geeignete Server (7) sind kommerziell erhältlich und dem Fachmann bekannt. Der Server (7) ist verantwortlich für das Überwachen und die Kontrolle der bei den Bezahlvorgängen vorgenommenen Zahlungen, kann Inkonsistenzen, Fälschungen und Missbrauch mit E-Geld (4) im System (1 ) erkennen und gegebenenfalls korrigierende Massnahmen ergreifen. Bei Bedarf kann der Server (7) sogar die Pseudonymität eines Benutzers aufheben und den Rechtsweg einleiten. Somit ist der Server (7) ein Routing-, Protokoll- und Überwachungsserver und nicht zuständig für die Durchführung von einzelnen online- und/oder offline-Transaktionen, inkl. deren abschliessenden Settlements. Mit anderen Worten: Mit dem System (1 ) können Bezahlvorgänge auch ohne Server (7) offline und mit abschliessendem Settlement durchgeführt werden. Der Server (7) detektiert und verhindert einen allfälligen Missbrauch des Systems (1 ), ermöglicht dem Inhaber des Terminal (5) und dem Betreiber des Systems (1 ) den Zugang zu einem Transaktionsjournal und ermöglicht es dem Inhaber des Terminal (5) und dem Betreiber des Systems (1 ) E-Geld (4, 4*) korrekt in Buch- oder Papiergeld einzutauschen.
Der Server (7) empfängt, speichert und verarbeitet zudem die von den Geräten (2, 2") empfangenen Telegramme, wie Spend-Telegramme, resp. Quittungen, und verschickt selbst Telegramme wie Empfangsbestätigungen, Alarminformationen, Sperrmeldungen, etc. an die Geräte (2, 2', 2") und über die Geräte (2, 2") an die Terminals (5). Er kann zudem E-Geld (4) und gegebenenfalls dazugehörige Signaturen und/oder Zertifikate erstellen, den Geräten (2, 2', 2") Gültigkeitszertifikate ausstellen, administriert die auf den Geräten (2, 2', 2") und der Smartcard (6) befindlichen Geldbörsen und prüft deren Konsistenz, der Server (7) initiiert gegebenenfalls auch den Ausgleich eines Bezahlvorgangs oder einer Sammlung von Bezahlvorgängen mit Geldübertrag zum Bankkonto des Verkäufers.
Der Server (7) ist typischerweise ein trusted Server, d.h. ein vertrauensvoller Server. Dem Fachmann sind die Kriterien bekannt, um einem Server das Prädikat „trusted Server", zu verleihen. So umfasst ein trusted Server typischerweise einen ganzen Katalog von Massnahmen, die ihn vertrauenswürdig machen, wie beispielsweise der Standort und das physische Sicherheitspositiv des Servers, die vorhandenen Firewalls, Überwachungskreisläufe, Redundanz, Trusted/Secure Elemente sowie die Daten-Diffusion. Dadurch kann das System (1 ) darauf vertrauen, dass die Operationen des Servers (7) korrekt und im Sinne des Systems (1 ) ausgeführt werden und dass diese Operationen nicht durch den Einfluss Dritter manipuliert, verfälscht oder anderweitig zu Ungunsten des Systems (1 ) beeinflusst werden.
Das Verfahren
Das erfindungsgemässe Verfahren zum sicheren Bezahlen mit E-Geld (4, 4*) mit dem Gerät (2) mit dem erfindungsgemässen System (1 ), d.h. unter Verwendung des erfindungsgemässen Systems (1 ), umfasst mindestens einen der nachfolgend genannten Schritte a) bis d). Wenn das Verfahren zwei oder mehr der folgenden Schritte umfasst, können die Schritte in beliebiger Reihenfolge und/oder gleichzeitig durchgeführt resp. kombiniert werden. Schritt a) des erfindungsgemässen Verfahrens umfasst das Speichern von im System (1 ) bevorzugt eingesetztes E-Geld (4*) auf dem Gerät (2) und/oder einem Terminal (5), wobei das bevorzugt eingesetzte E-Geld (4*) mindestens ein Load-Token TL (41 ) und nach einer ersten Transaktion auch mindestens ein Spend-Token TS (42) umfasst. Dadurch können für Load- Token TL (41 ) und für Spend-Token TS (42) unterschiedliche Berechtigungen vergeben werden, wodurch sichere Offline-Zahlungen durchgeführt werden können. Schritt b) des erfindungsgemässen Verfahrens umfasst einen Bezahlvorgang mit unbedingtem, d.h. abschliessendem, Settlement, mit E-Geld (4, 4*) umfassend eine Transaktion, d.h. Übergabe, eines Guthabens von Gerät (2) an Terminal (5) und/oder von Terminal (5) an Gerät (2), wobei das Terminal
(5) mindestens ein physisches Sicherheitselement SEALS-SE (3) umfasst und das Gerät (2) und das Terminal (5) miteinander kommunizieren, d.h. das
Gerät (2) und das Terminal (5) weisen während der Transaktion eine permanente, zeitlich limitierte stehende bidirektionale Verbindung auf. Dabei wird die Transaktion des Guthabens bevorzugt in mindestens einem Spend- Token TS (42) repräsentiert. Durch das Sicherheitselement SEALS-SE (3) im Terminal (5) wird das E-Geld (4, 4*) vom Gerät (2) und/oder der Smartcard
(6) , insbesondere das Spend-Token TS (42), signiert. Dadurch wird ein unbedingtes und abschliessendes Settlement und somit ein sicherer Bezahlvorgang mit E-Geld (4, 4*) zwischen Gerät (2) und/oder Smartcard (6) und Terminal (5) ermöglicht, auch wenn das Gerät (2), die Smartcard (6) und das Terminal (5) zum Zeitpunkt des Bezahlvorgangs offline sind.
Unter dem Begriff „abschliessendes Settlement eines Bezahlvorgangs" wird erfindungsgemäss verstanden, dass die Bonität des Käufers gegeben ist, der Bezahlvorgang rechtskräftig und abgeschlossen ist und somit eine abschliessende Wirkung aufweist. Ein solches abschliessendes Settlement ist im Gegensatz zu einem temporären, d.h. noch nicht definitiven, Settlement, wie dies beispielsweise bei Zahlung ohne Internet-Anbindung mittels Kreditkarte der Fall ist.
Schritt c) des erfindungsgemässen Verfahrens umfasst das Austauschen von mindestens einem Telegramm, d.h. Meldung, Nachricht resp. Information, zwischen Terminal (5) und Server (7) und/oder zwischen Server (7) und Terminal (5), wobei der Austausch des mindestens einen Telegramms über das Gerät (2) und/oder eine Vielzahl von Geräten (2") stattfindet. Dabei wird unter dem Begriff Austausch erfindungsgemäss Übermittlung mit Empfangsbestätigung verstanden.
Der Austausch des mindestens einen Telegramms zwischen Terminal (5) und Gerät (2, 2") findet bevorzugt zum Zeitpunkt eines Bezahlvorgangs statt und der Austausch zwischen Gerät (2, 2") und Server (7) kann zu einem anderen Zeitpunkt stattfinden. Somit kann das Gerät (2) zum Zeitpunkt eines Bezahlvorgangs online oder offline sein. Auch ist es möglich am Terminal (5) mittels Smartcard (6) zu bezahlen, wobei das zum Bezahlvorgang mittels Smartcard (6) zugeordnete Telegramm zu einem späteren Zeitpunkt über ein Gerät (2, 2") mit dem Server (7) ausgetauscht wird.
Schritt c) umfasst verschiedene spezifische Ausführungsformen i) bis iv), die gegebenenfalls auch in Kombination miteinander durchgeführt werden können und nachfolgend näher erläutert werden. Ist in einer Ausführungsform i) das Gerät (2) zum Zeitpunkt eines Bezahlvorgangs mit dem Server (7) verbunden und somit online, tauscht das Terminal (5) mit dem Server (7) über das Gerät (2) mindestens ein Telegramm des Bezahlvorgangs aus. Dabei wird vorteilhafterweise mindestens ein Telegramm vom Terminal (5) über das Gerät (2) zum Server (7) übermittelt. Der Server (7) sendet anschliessend über das Gerät (2) an das Terminal (5) ein Telegramm mit der Empfangsbestätigung. Durch den Erhalt der Empfangsbestätigung wird dem Terminal (5) bestätigt, dass der Bezahlvorgang korrekt abgelaufen ist und dass dem Bankkonto des Verkäufers der entsprechende Geldbetrag überwiesen wird. Entsprechend kann der Bezahlvorgang beispielsweise mit Schritt e) des erfindungs- gemässen Verfahrens ausgeglichen werden.
Ist in einer weiteren Ausführungsform ii) das Gerät (2) zum Zeitpunkt eines Bezahlvorgangs nicht mit dem Server (7) verbunden und somit offline, übermittelt das Terminal (5) mindestens ein Telegramm, bevorzugt alle beim Bezahlvorgang generierten Telegramme, des Bezahlvorgangs an das Gerät (2). Da das Gerät (2) offline ist, kann es das mindestens eine Telegramm nicht an den Server (7) weiterleiten und entsprechend auch kein Telegramm mit einer Empfangsbestätigung erhalten und zurück an das Terminal (5) übermitteln. Solange nun am Terminal (5) vom Server (7) noch kein Telegramm mit der Empfangsbestätigung für das Telegramm der aktuellen Zahlung eingegangen ist, übermittelt das Terminal (5) bei nachfolgenden Bezahlvorgängen an eine Vielzahl von weiteren Geräten (2") das mindestens eine Telegramm. Das Gerät (2) und jedes der Geräte (2") senden dann das mindestens eine Telegramm mindestens einmal an den Server (7), bis das mindestens eine Telegramm an den Server (7) übermittelt ist und der Server (7) über mindestens ein Gerät (2, 2") ein Telegramm mit der Empfangsbestätigung an das Terminal (5) übermittelt. Dadurch wird auf einfache Art und Weise ein Bezahlvorgang offline erlaubt, ohne dass das Gerät (2) und das Terminal (5) zum Zeitpunkt des Bezahlvorgangs eine online-Verbindung mit dem Server (7) aufweisen müssen.
Ist in einer anderen Ausführungsform iii) das Gerät (2) unabhängig von einem Bezahlvorgang mit dem Server (7) verbunden und somit online, kann der Server (7) pendente Telegramme, insbesondere pendente Telegramme betreffend mindestens einen Bezahlvorgang mit dem gleichen Gerät (2) und/oder mit einem anderen Gerät (2"), d.h. mit mindestens einem der Vielzahl von Geräten (2"), an mindestens einem Terminal (5), an das Gerät (2) übermitteln, welches dieses später an das Terminal (5) übermittelt. Diese Verfahrensweise erlaubt überraschenderweise auf einfache Art und Weise, dass ein Benutzer mit einem Gerät (2) am Terminal (5), selbst offline, nur ein einziges Mal eine Zahlung durchführen kann, resp. präsent sein muss, und trotzdem wird die Quittung durch den Server (7) gegenüber dem Terminal (5) bestätigt.
Die in den Ausführungsformen ii) und iii) des Verfahrensschritts c) erwähnte Verfahrensweise zur Übermittlung von Telegrammen von einem Terminal (5) über eine Vielzahl von Geräten (2, 2") zum Server (7) und/oder vom Server (7) über eine Vielzahl von anderen Geräten (2, 2") zum gleichen Terminal (5) wird erfindungsgemäss Schwärm Kommunikation genannt. Dadurch wird auch bei einem offline-Bezahlvorgang der allfällige Geldübertrag vom Pool- Konto zum Geldkonto des Verkäufers, beispielsweise durch nachfolgenden Schritt e) des erfindungsgemässen Verfahrens, sichergestellt, wobei der Geldübertrag durch den Server (7) veranlasst wird.
Dass, wie in den Ausführungsformen ii) und iii) des Verfahrensschritts c) erwähnt, sowohl das Gerät (2) wie auch das Terminal (5) zum Zeitpunkt des Bezahlvorgangs offline sind, ist selbst in stark industrialisierten Gebieten nicht selten der Fall. Nicht-Iimitierende Beispiele umfassen Automatenverkäufe in Kellergeschossen, Events in Erholungsgebieten mit Mobilfunkloch und kurzzeitige Unverfügbarkeit des Internets und/oder Servers (7). Allerdings gilt es als äusserst wahrscheinlich, dass zumindest das Gerät (2) und/oder eines der Vielzahl an Geräten (2") innerhalb weniger Stunden oder spätestens nach einigen Tagen wieder eine Verbindung mit dem Server (7) aufbaut, wodurch das mindestens eine Telegramm vom Terminal (5) an den Server (7) übermittelt werden kann. Praktisch gleichzeitig, d.h. zeitlich kurz versetzt, empfängt das Gerät (2) und/oder mindestens eines der Vielzahl an Geräten (2") ein Telegramm mit der Empfangsbestätigung. Dieses Telegramm wird nach Erhalt von dem oder den Geräten (2, 2") an das Terminal (5) weitergeleitet. Dabei kann die Vielzahl an Geräten (2"), welche das mindestens eine Telegramm vom Terminal (5) empfangen und typischerweise verzögert an den Server (7) weiterleiten, gleich oder verschieden sein mit der Vielzahl an Geräten (2"), welche vom Server (7) das Telegramm mit der Empfangsbestätigung erhalten. Dabei zeigten Simulationen, dass - im Verhältnis zu den Terminals - die Anzahl der Geräte (2, 2") und die Anzahl Bezahlvorgänge pro Gerät (2, 2") erstaunlich gering sein kann um die Funktionsfähigkeit des erfindungsgemässen Systems (1 ) und des erfindungsgemässen Verfahrens zu gewährleisten.
Erfolgt in einer zusätzlichen Ausführungsform iv) der Bezahlvorgang am Terminal (5) mittels einer Smartcard (6), ist der Bezahlvorgang offline, da die Smartcard (6) nicht mit dem Server (7) kommunizieren kann. Das Terminal (5) übermittelt nach Abschluss des Bezahlvorgangs mit der Smartcard (6) bei mindestens einem nachfolgenden Bezahlvorgang mit mindestens einem Gerät (2, 2") mindestens ein Telegramm des Bezahlvorgangs mit der Smartcard (6) an das mindestens eine Gerät (2, 2"). Diese Übermittlung an mindestens ein Gerät (2, 2") dauert so lange, bis beim Terminal (5) vom Server (7) ein Telegramm mit der Empfangsbestätigung eingegangen ist.
Mit anderen Worten: Wird nach einem Bezahlvorgang mit Smartcard (6) mit einem Gerät (2) ein weiterer Bezahlvorgang durchgeführt, übermittelt das Terminal (5) an das Gerät (2) nicht nur das Telegramm des Bezahlvorgangs vom Gerät (2) mit dem Terminal (5), sondern auch das Telegramm des früheren Bezahlvorgangs von der Smartcard (6) mit dem Terminal (5).
Ist nun das Gerät (2) online, übermittelt - analog zu Ausführungsform i) - das Gerät (2) an den Server (7) nicht nur das Telegramm des Bezahlvorgangs vom Gerät (2) mit dem Terminal (5), sondern auch das Telegramm des früheren Bezahlvorgangs mit der Smartcard (6). Der Server (7) wiederum übermittelt an das Gerät (2) sowohl das Telegramm mit der Empfangsbestätigung des Bezahlvorgangs vom Gerät (2) mit dem Terminal (5), wie auch das Telegramm mit der Empfangsbestätigung des Bezahlvorgangs von der Smartcard (6) mit dem Terminal (5). Das Gerät (2) wiederum übermittelt beide Telegramme an das Terminal (5) zur Bestätigung beider Bezahlvorgänge. Diese Vorgänge dauern bei guten Verbindungen lediglich Bruchteile von Sekunden oder höchstens wenige Sekunden.
Ist das Gerät (2) jedoch offline, erhält - analog zu Ausführungsform ii) - das Terminal (5) beim nachfolgenden Bezahlvorgang mit dem Gerät (2) kein Telegramm mit einer Empfangsbestätigung der Bezahlvorgänge. Dementsprechend übermittelt das Terminal (5) an mindestens ein weiteres Gerät, typischerweise an eine Vielzahl von weiteren Geräten (2"), das Telegramm des aktuellen Bezahlvorgangs vom Gerät (2") mit dem Terminal (5), wie auch die Telegramme der früheren Bezahlvorgänge von der Smartcard (6) mit dem Terminal (5), vom Gerät (2) mit dem Terminal und gegebenenfalls von anderen Geräten (2") mit dem Terminal (5). Die Geräte (2, 2") wiederum übermitteln die Telegramme mindestens einmal an den Server (7). Der Server (7) quittiert typischerweise sofort den Erhalt des Telegramms indem der Server (7) eine Empfangsbestätigung an das jeweilige Gerät (2, 2") zurück schickt. Sobald ein Gerät (2, 2") mit einer Empfangsbestätigung wieder in Kontakt mit dem Terminal (5) tritt, wird diese vom Gerät (2, 2") an das Terminal (5) übermittelt und das Terminal (5) stoppt das Übermitteln von Telegrammen an weitere Geräte (2, 2"). Durch diese Vorgehensweise kann das Terminal (5) gegebenenfalls eine Vielzahl von Empfangsbestätigungen zum gleichen Bezahlvorgang erhalten, wobei nur die erste erhaltende Empfangsbestätigung eine Bedeutung hat.
Schritt d) des erfindungsgemässen Verfahrens umfasst das Überwachen und Erkennen von Missbrauch im System (1 ) mit E-Geld (4, 4*), wobei - der Server (7) die von den Geräten (2, 2") empfangenen Telegramme speichert, verarbeitet, gegebenenfalls mindestens ein Gerät (2, 2") für das System (1 ) sperrt, und andere Telegramme über die Geräte (2, 2") an das Terminal (5) weiterleitet, und/oder - das Terminal (5) unter Verwendung des Sicherheitselements
SEALS-SE (3) mindestens die von den Geräten (2, 2") empfangenen Spend-Token TS (42) auf deren Korrektheit hin überprüft, gegebenenfalls mindestens ein Gerät (2, 2") für das System (1 ) sperrt und mittels mindestens einem Telegramm über die Geräte (2, 2") an den Server (7) weiterleitet.
Denn weisen beispielsweise vom Server (7) erhaltene Telegramme, die von einem Gerät (2, 2") stammen, Unregelmässigkeiten auf, kann der Server das Gerät (2, 2") sperren, in dem er entsprechende Telegramme an die Geräte (2, 2") schickt. Diese leiten die Telegramme an mindestens ein, bevorzugt an eine Vielzahl von, insbesondere an alle, Terminal (5) weiter. Somit erkennen die Terminal (5) ein gesperrtes Gerät (2). Auch kann der Server (7) analog andere Telegramme mit beispielsweise Steuerinformationen über die Geräte (2, 2") an das Terminal (5) weiterleiten. Dies erhöht weiter den Sicherheitsstandard des Systems (1 ) und wirkt präventiv gegen Missbrauch und Fälschung.
Schritt e) des erfindungsgemässen Verfahrens ist optional und erfolgt typischerweise im Anschluss an mindestens einen der vorgenannten Schritte a) bis d), wobei Schritt e) den Rückkauf des am Terminal (5) kumulierten E- Geld (4, 4*) mit Geldübertrag zum Bankkonto des Verkäufers, und somit die Umwandlung von E-Geld (4, 4*) in physisches Geld umfasst.
Beim Verfahren zum sicheren bargeldlosen Bezahlen mit dem erfindungs- gemässen elektronischen Geld (4*) mit einem Gerät (2) an einem Terminal (5) umfasst das E-Geld (4*) mindestens ein Load-Token TL (41 ) und nach einem ersten Bezahlvorgang auch mindestens ein vom Load-Token TL (41 ) verschiedenes Spend-Token TS (42).
Das mindestens eine Load-Token TL (41 ) des E-Gelds (4*) ist auf dem Gerät (2) gespeichert und alle Load-Token TL (41 ) des E-Gelds (4*) auf dem Gerät (2) zusammen umfassen die Summe der Gutschriften des auf dem Gerät (2) gespeicherten E-Gelds (4*).
Das gegebenenfalls mindestens eine Spend-Token TS (42) umfasst mindestens den Warenwert der beim Bezahlvorgang gekauften/verkauften Waren und gegebenenfalls weitere Informationen zum Bezahlvorgang, insbesondere zu dem am Bezahlvorgang beteiligten Gerät (2) und Terminal (5). Damit repräsentiert es einen Bezahlvorgang mit E-Geld (4*) vom Gerät (2) zum Terminal (5), wobei das Spend-Token TS (42) mindestens auf dem Gerät (2) und/oder Terminal (5) gespeichert ist.
Zudem wird der aktuelle Wert des auf dem Gerät (2) gespeicherten E-Geldes (4*) durch die Summe der Load-Token TL (41 ) abzüglich der Summe der Spend-Token TS (42) repräsentiert, wobei das mindestens eine Load-Token TL (41 ) und das gegebenenfalls mindestens eine Spend-Token TS (42) bevorzugt eine Information enthält, welche eine chronologische Anordnung erlaubt. Eine solche Information ist beispielsweise ein Zeitstempel, ein Token-Index und/oder ein Transaktionszähler. Bei dem erfindungsgemässen Verfahren zum sicheren Bezahlen mit E-Geld (4*) mit einem Gerät (2) und gegebenenfalls der Smartcard (6) vom E-Geld (4*) für jede vorhandene Währung mindestens ein Load-Token TL (41 ) und nach einem ersten Bezahlvorgang auch mindestens ein vom Load-Token TL (41 ) verschiedenes Spend-Token TS (42) gespeichert wird, wobei das mindestens eine Load-Token TL (41 ) und das mindestens eine Spend-Token TS (42) bevorzugt chronologisch in Bezug auf die Gutschriften und Belastungen in der jeweiligen Währung aneinander gereiht und bevorzugt als eine Hash-Chain miteinander verknüpft werden.
Im Folgenden werden nicht-limitierende, bevorzugte Ausführungsformen des erfindungsgemassen System (1 ) zum sicheren Bezahlen mit E-Geld (4), dem erfindungsgemassen E-Geld (4*) und dem Verfahren zum sicheren Bezahlen mit E-Geld (4) mit einem Gerät (2) mit dem System (1 ) resp. dem E-Geld (4) anhand der nachfolgenden Zeichnungen beschrieben. Diese sind nicht einschränkend auszulegen und werden als Bestandteil der Beschreibung verstanden:
Fig. 1 zeigt beispielhaft einen Server (7), zwei verschiedene Arten von Terminal (5), die beide ein Sicherheitselement SEALS-SE (3) für Offline-Zahlungen mit E-Geld von einem Gerät (2) und/oder einer
Smartcard (6) umfassen und einen Verkaufsautomaten resp. ein Terminal (5) an einer Kasse darstellen, sowie die Geräte (2), (2') und (2"). Die Geräte (2, 2', 2") sind mit dem Server (7) bevorzugt über eine typischerweise unstete Datennetzwerkverbindung verbunden. Die Unstetigkeit der Datennetzwerkverbindung ist mit unterbrochenen Pfeilen dargestellt. Das Gerät (2), stellvertretend auch für die Vielzahl der Geräte (2"), ist mit den Terminals (5) beispielsweise über eine Kurzstrecken-Funkverbindung wie NFC verbunden, wobei das Gerät (2'), welches durch ein Sicherheitselement SEALS-SE (3) erweitert ist, ebenfalls ein Terminal (5) darstellt.
Fig. 2 zeigt beispielhaft, dass a) ein Gerät (2) mit dem Terminal (5) offline, d.h. ohne Verbindung mit dem Server, einen Bezahlvorgang mit abschliessendem Settlement abwickeln kann. Ist das Gerät (2) später wieder online, d.h. mit dem Server (7) verbunden, werden b) die für einen allfälligen Rückkauf des am Terminal (5) kumulierten E- Geld (4, 4*) notwendigen Informationen sowie zur Überwachung des Systems, d.h. zum Detektieren von allfälligen Unregelmässigkeiten wie Manipulation oder Fälschung am E-Geld (4, 4*), in Form von mindestens einem Telegramm an den Server (7) übermittelt. Dieser quittiert den Erhalt des Telegramms in Form einer Empfangsbestätigung.
Fig. 3 zeigt beispielhaft a) einen offline Bezahlvorgang mit abschliessendem Settlement am Terminal (5) mit einer Smartcard (6), welche keine Verbindung mit dem Server (7) aufbauen kann und somit permanent offline ist, wobei für den Bezahlvorgang mit der Smartcard (6) kein Gerät (2) notwendig ist. Bei einem nächsten Kontakt des Terminal (5) mit einem Gerät (2, 2"), welches zum Zeitpunkt des Kontakts, beispielsweise bei einem Bezahlvorgang, online ist, werden b) für den Abschluss des Bezahlvorgangs, d.h. für einen allfälligen Rückkauf des am Terminal (5) kumulierten E-Geld (4, 4*), sowie zur Überwachung des Systems die notwendigen Informationen in Form von mindestens einem Telegramm an den Server (7) übermittelt. Dieser quittiert den Erhalt des Telegramms in Form einer Empfangsbestätigung, welche vom Server (7) über das Gerät (2, 2") zum Terminal (5) zurückgeschickt wird.
Fig. 4 zeigt beispielhaft einen offline Bezahlvorgang am Terminal (5) mit einem Gerät (2), welches a) offline ist, da sich beispielsweise das Terminal und das Gerät (2) in einem Funkloch oder in einem
Kellergeschoss ohne Internetanbindung befinden. Obwohl weder das Terminal (5) noch das Gerät (2) online sind, wird mit dem erfindungsgemässen System (1 ) ein abschliessendes Settlement durchgeführt. Bei einem nächsten Kontakt am Terminal (5) mit einer Vielzahl von Geräten (2"), welche demzufolge zum Zeitpunkt des
Kontakts ebenfalls offline sind, werden b) die für einen Rückkauf des am Terminal (5) kumulierten E-Geld (4, 4*) notwendigen Informationen als Quittung in Form von mindestens einem Telegramm an die Vielzahl von Geräten (2") übermittelt. Sobald nun c) das Gerät (2) und/oder mindestens eines der Geräte (2") wieder online sind, werden diese Telegramme an den Server (7) weiter geleitet. Dieser bestätigt den Erhalt aller Quittungs-Telegramme indem er eine entsprechende Empfangsbestätigung an alle Geräte (2, 2") schickt, von denen er die Telegramme erhalten hat (quadratisch dargestellt).
Der Server (7) schickt diese Empfangsbestätigung bevorzugt auch zusätzlich an weitere Geräte (2"), welche vom Terminal (5) keine entsprechenden Telegramme erhalten haben (rund dargestellt), da möglicherweise ein solches Gerät (2") früher einen Kontakt mit dem Terminal (5) aufbaut. Sobald nun d) ein Gerät (2, 2") mit der Empfangsbestätigung einer Quittung eines früheren Bezahlvorgangs mit dem Terminal (5) Kontakt aufnimmt, wird die Empfangsbestätigung des Servers (7) an das Terminal (5) übermittelt und der Bezahlvorgang auf Seiten des Terminals (5) als quittiert gekennzeichnet. zeigt beispielhaft erfindungsgemässes und erfindungsgemäss bevorzugt eingesetztes E-Geld (4, 4*) welche auf einem Gerät (2) gespeichert werden und mindestens ein Load-Token TL (41 ) und nach einem ersten Bezahlvorgang auch mindestens ein vom Load- Token TL verschiedenen Spend-Token TS (42) umfasst, wobei unter a) das Load-Token TL (41 ) dargestellt ist, welches mindestens eine Gutschrift des auf dem Gerät (2) gespeicherten E-Gelds (4, 4*) umfasst,
b) bei einem Bezahlvorgang mit dem Gerät (2) am Terminal (5), welches ein Sicherheitselement SEALS-SE (3) umfasst, wird das Spend-Token TS (42) vom Gerät (2) erzeugt und eine Kopie des Spend-Tokens TS (42) zum Terminal (5) übermittelt. Das Spend- Token TS (42) umfasst mindestens den Warenwert der beim Bezahlvorgang gekauften/verkauften Waren sowie Angaben zum Käufer und Verkäufer. Damit repräsentiert das Spend-Token (42) einen Bezahlvorgang mit E-Geld (4, 4*) vom Gerät (2) zum Terminal (5). Der Pfeil mit Symbol zwischen Gerät (2) und Terminal (5) stellt eine aufgebaute Verbindung mit bidirektionalem Datenaustausch dar und ist somit eine physikalische Verbindung mit Signalübermittlung. Die Verbindung kann beispielsweise mittels NFC erfolgen,
Nach erfolgtem Settlement, ist das Spend-Token TS (42) mindestens auf dem Gerät (2) und/oder dem Terminal (5) gespeichert. Damit wird der Warenwert dem auf dem Gerät (2) gespeicherten E-Geld (4, 4*) belastet und dem Terminal (5) resp. der damit verbundenen Kasse gutgeschrieben. Da das Spend- Token TS (42) sowohl auf dem Gerät (2) als auch auf dem Terminal (5) gespeichert wird, ist ein allfälliger und irrtümlicher Geld-Schlupf ausgeschlossen. Dadurch kann der getätigte Bezahlvorgang auch nachträglich problemlos nachverfolgt werden und eine allfällige Fehlbuchung korrigiert werden.

Claims

System (1 ) zum sicheren Bezahlen mit elektronischem Geld (4), d.h. E- Geld (4), umfassend
- mindestens ein mobiles Gerät
(2) mit E-Geld (4), wobei das E- Geld (4) gegebenenfalls mit einer Software verwaltet wird,
- gegebenenfalls mindestens eine Smartcard (6) mit E-Geld (4), wobei E-Geld (4) auf der Smartcard (6) aufbewahrt wird,
- mindestens ein Payment-Terminal (5), und
- mindestens einen Server (7),
dadurch gekennzeichnet, dass
I. das E-Geld (4) als E-Geld (4*) vorliegt, wobei das E-Geld (4*) mindestens ein Load-Token TL (41 ) und nach einem ersten Bezahlvorgang auch mindestens ein vom Load-Token TL verschiedenen Spend-Token TS (42) umfasst, und/oder
II. das Terminal (5) mindestens ein Sicherheitselement SEALS-SE (3) umfasst, wobei das Sicherheitselement SEALS-SE
(3) für die Aufbewahrung und Übertragung von E-Geld (4,
4*) mit abschliessendem Settlement auch mit einem Gerät (2) ohne Sicherheitselement SE und ohne Internet-Anbindung zum Zeitpunkt des Bezahlvorgangs geeignet ist, und das Terminal (5) und das Gerät (2) zum Zeitpunkt eines Bezahlvorgangs für ein abschliessendes Settlement nicht mit dem Server (7) verbunden sein müssen und somit offline sein können.
System (1 ) nach Anspruch 1 , dadurch gekennzeichnet, dass das Gerät (2) und das Terminal
(5) und gegebenenfalls die Smartcard
(6) und das Terminal (5) miteinander mittels i) Kurzstrecken-Funkverbindung wie beispielsweise RFID, NFC, Bluetooth, Bluetooth Low Energy (BLE) und/oder WiFi, ii) kontaktbehafteter Verbindung wie beispielsweise USB und/oder Firewire, iii) optischer Verbindung wie beispielsweise IR, IRDA und/oder NIR, iv) akustischer Verbindung und/oder v) Datennetzwerke wie beispielsweise TCP/IP, kommunizieren.
System (1 ) nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass das Gerät (2) und der Server (7) miteinander mit einer Datennetzwerkverbindung, insbesondere mit einer Datenfunkverbindung, kommunizieren.
System (1 ) nach mindestens einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass das Gerät (2) ein Mobiltelefon, Smartphone, Tablet, Notebook, Laptop, Smart Wearables und/oder ein anderes, beispielsweise speziell für das System (1 ) bereitgestelltes mobiles Gerät ist.
System (1 ) nach mindestens einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass das Sicherheitselement SEALS-SE (3) im Terminal (5) ein physisches Sicherheitselement darstellt und einen Prozessor mit kryptographischer Tauglichkeit umfasst.
System (1 ) nach mindestens einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass das Gerät (2) mindestens
- einen Prozessor,
- einen Speicher,
- eine Stromversorgung,
- gegebenenfalls ein Display mit Eingabefeld
- einen Mobilfunktransceiver, WLAN-Transceiver und/oder eine andere Sende/Empfangseinheit zur Kontaktaufnahme mit dem Server (7), sowie
- eine Verbindung für den Datentransfer zwischen dem Gerät (2) und dem Terminal (5), insbesondere einen Kurzstrecken- Funktransceiver, eine kontaktbehaftete Verbindung, eine optischer Verbindung, eine akustische Verbindung und/oder eine Datennetzwerkverbindung,
umfasst.
7. System (1 ) nach mindestens einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass das Terminal (5) mindestens
- einen Prozessor,
- einen Speicher,
- eine Stromversorgung,
- eine Benutzer-Schnittstelle, insbesondere ein Touch-Display, und/oder eine Maschinen-Schnittstelle, insbesondere ein USB Anschluss,
- einen Kurzstrecken-Funktransceiver, eine kontaktbehaftete Verbindung, eine optische Verbindung, eine akustische Verbindung und/oder eine Datennetzwerkverbindung für den Datentransfer zwischen dem Gerät (2) und dem Terminal (5), sowie
- das Sicherheitselement SEALS-SE (3) umfasst.
8. System (1 ) nach mindestens einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass das Terminal (5) durch ein Gerät (2') gebildet wird, wobei das Gerät (2') ein Gerät (2) umfasst, welches um ein Sicherheitselement SEALS-SE (3) und gegebenenfalls um eine Software und/oder eine Hardware erweitert ist.
9. Elektronisches Geld (4*) zum sicheren Bezahlen mit dem Gerät (2), insbesondere mit dem unsicheren Gerät (2), an einem Terminal (5) gemäss System (1 ), dadurch gekennzeichnet, dass das E-Geld (4*) mindestens ein Load-Token TL (41 ) und nach einem ersten Bezahlvorgang auch mindestens ein vom Load-Token TL (41 ) verschiedenes Spend-Token TS (42) umfasst, wobei - das Load-Token TL (41 ) auf dem Gerät (2) gespeichert ist und mindestens den Betrag einer Gutschrift des auf dem Gerät (2) gespeicherten E-Gelds (4) umfasst,
- das Spend-Token TS (42) mindestens den Warenwert der beim Bezahlvorgang gekauften/verkauften Waren und gegebenenfalls weitere Informationen zum Bezahlvorgang, insbesondere zu dem am Bezahlvorgang beteiligten Gerät (2) und Terminal (5), umfasst und damit einen Bezahlvorgang mit E-Geld (4*) vom Gerät (2) zum Terminal (5) repräsentiert, wobei das Spend-Token TS (42) mindestens auf dem Gerät (2) und/oder Terminal (5) gespeichert ist, und
- der aktuelle Wert des auf dem Gerät (2) gespeicherten E-Geldes (4*) durch die Summe der Load-Token TL (41 ) abzüglich der Summe der Spend-Token TS (42) repräsentiert wird, wobei das mindestens eine Load-Token TL (41 ) und das gegebenenfalls mindestens eine Spend-Token TS (42) bevorzugt eine Information enthält, welche eine chronologische Anordnung erlaubt.
10. System (1 ) nach mindestens einem der Ansprüche 1 bis 8 und E-Geld (4*) nach Anspruch 9, dadurch gekennzeichnet, dass auf dem Gerät (2) und gegebenenfalls der Smartcard (6) für jede vorhandene Währung mindestens ein Load-Token TL (41 ) und nach einem ersten Bezahlvorgang auch mindestens ein vom Load-Token TL (41 ) verschiedenes Spend-Token TS (42) gespeichert ist und in der Reihenfolge aller Tokens die Historie der Gutschriften und Belastungen in der jeweiligen Währung abgebildet ist.
1 1 . Verfahren zum sicheren Bezahlen mit E-Geld (4, 4*) mit dem Gerät (2) mit dem System (1 ) nach mindestens einem der Ansprüche 1 bis 8 und 10 und/oder dem E-Geld (4*) nach Anspruch 9 und 10, dadurch gekennzeichnet, dass das Verfahren mindestens einen der folgenden Schritte a) bis d) umfasst:
a) das Speichern von E-Geld (4*) auf dem Gerät (2) und/oder einem Terminal (5), wobei das E-Geld (4*) mindestens ein Load-Token TL (41 ) und nach einer ersten Transaktion auch mindestens ein Spend-Token TS (42) umfasst,
b) einen Bezahlvorgang mit E-Geld (4, 4*) mit abschliessendem Settlement ohne Internet-Anbindung zum Zeitpunkt des Bezahlvorgangs umfassend eine Transaktion eines Guthabens von Gerät (2) an Terminal (5) und/oder von Terminal (5) an Gerät (2), wobei das Terminal (5) mindestens ein physisches Sicherheitselement SEALS-SE (3) umfasst, das Gerät (2) und das Terminal (5) miteinander kommunizieren und die Transaktion des Guthabens bevorzugt in mindestens einem Spend-Token TS (42) repräsentiert wird,
c) das Austauschen von mindestens einem Telegramm zwischen Terminal (5) und Server (7) und/oder zwischen Server (7) und Terminal (5), wobei der Austausch des mindestens einen Telegramms über das Gerät (2) und/oder eine Vielzahl von Geräten (2") stattfindet, und/oder
d) das Überwachen und Erkennen von Missbrauch im System (1 ) mit E-Geld (4, 4*), wobei
- der Server (7) die von den Geräten (2, 2") empfangenen Telegramme speichert, verarbeitet, gegebenenfalls mindestens ein Gerät (2, 2") für das System (1 ) sperrt, und andere Telegramme über die Geräte (2, 2") an das Terminal (5) weiterleitet, und/oder
- das Terminal (5) unter Verwendung des Sicherheitselements SEALS-SE (3) mindestens die von den Geräten (2, 2") empfangenen Spend-Token TS (42) auf deren Korrektheit hin überprüft, gegebenenfalls mindestens ein Gerät (2, 2") für das System (1 ) sperrt und/oder ablehnt, und gegebenenfalls mindestens ein Telegramm über die Geräte (2, 2") an den Server (7) weiterleitet,
e) sowie gegebenenfalls ein Rückkauf des am Terminal (5) kumulierten E-Geld (4, 4*) mit Geldübertrag zum Bankkonto des Verkäufers.
12. Verfahren zum sicheren bargeldlosen Bezahlen mit elektronischem Geld (4*) mit dem Gerät (2) an einem Terminal (5) nach mindestens einem der Ansprüche 9 bis 10, dadurch gekennzeichnet, dass das E-Geld (4*) mindestens ein Load-Token TL (41 ) und nach einem ersten Bezahlvorgang auch mindestens ein vom Load-Token TL (41 ) verschiedenes Spend-Token TS (42) umfasst, wobei
- das Load-Token TL (41 ) auf dem Gerät (2) gespeichert ist und mindestens den Betrag einer Gutschrift des auf dem Gerät (2) gespeicherten E-Gelds (4*) umfasst,
- das Spend-Token TS (42) mindestens den Warenwert der beim Bezahlvorgang gekauften/verkauften Waren und gegebenenfalls weitere Informationen zum Bezahlvorgang, insbesondere zu dem am Bezahlvorgang beteiligten Gerät (2) und Terminal (5), umfasst und damit einen Bezahlvorgang mit E-Geld (4*) vom Gerät (2) zum Terminal (5) repräsentiert, wobei das Spend-Token TS (42) mindestens auf dem Gerät (2) und/oder Terminal (5) gespeichert ist, und
- der aktuelle Wert des auf dem Gerät (2) gespeicherte E-Geldes (4*) durch die Summe der Load-Token TL (41 ) abzüglich der Summe der Spend-Token TS (42) repräsentiert wird, wobei das mindestens eine Load-Token TL (41 ) und das gegebenenfalls mindestens eine Spend-Token TS (42) bevorzugt eine Information enthält, welche eine chronologische Anordnung erlaubt.
13. Verfahren nach Anspruch 1 1 und/oder 12, dadurch gekennzeichnet, dass auf dem Gerät (2) und gegebenenfalls auf der Smartcard (6) vom E-Geld (4*) für jede vorhandene Währung mindestens ein Load-Token TL (41 ) und nach einem ersten Bezahlvorgang auch mindestens ein vom Load- Token TL (41 ) verschiedenes Spend-Token TS (42) gespeichert wird und wobei das mindestens eine Load-Token TL (41 ) und das mindestens eine Spend-Token TS (42) bevorzugt chronologisch in Bezug auf die Gutschriften und Belastungen in der jeweiligen Währung abgebildet werden.
14. Verwendung des Systems (1 ) nach mindestens einem der Ansprüche 1 bis 1 1 und der Verfahren nach mindestens einem der Ansprüche 12 bis 13 zum sicheren Bezahlen mit E-Geld (4) mit dem Gerät (2) auch wenn das Gerät (2) und das Terminal (5) während dem Bezahlvorgang keinen Kontakt zum Server (7) aufweisen und somit offline sind.
15. Verwendung eines physischen Sicherheitselements SEALS-SE (3) an einem Terminal (5) zum sicheren Bezahlen mit E-Geld (4) mit dem Gerät (2) an einem Terminal (5) unter Verwendung des Systems (1 ) nach mindestens einem der Ansprüche 1 bis 1 1 und des Verfahrens nach mindestens einem der Ansprüche 12 bis 13, wobei das Sicherheitselement SEALS-SE (3) für die Aufbewahrung und Übertragung von E-Geld (4) mit abschliessendem Settlement auch mit einem Gerät (2) ohne Sicherheitselement SE und ohne Internet- Anbindung zum Zeitpunkt des Bezahlvorgangs geeignet ist, wodurch der Bezahlvorgang auch erfolgen kann, wenn das Gerät (2) und das Terminal (5) während dem Bezahlvorgang keinen Kontakt zum Server (7) aufweisen und somit offline sind.
EP17835630.9A 2016-12-20 2017-12-15 System zum offline-bezahlen mit e-geld mit mobilem gerät mit kurzer transaktionszeit und abschliessendem settlement Ceased EP3559883A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP16205267 2016-12-20
PCT/EP2017/082995 WO2018114654A1 (de) 2016-12-20 2017-12-15 System zum offline-bezahlen mit e-geld mit mobilem gerät mit kurzer transaktionszeit und abschliessendem settlement

Publications (1)

Publication Number Publication Date
EP3559883A1 true EP3559883A1 (de) 2019-10-30

Family

ID=57614171

Family Applications (1)

Application Number Title Priority Date Filing Date
EP17835630.9A Ceased EP3559883A1 (de) 2016-12-20 2017-12-15 System zum offline-bezahlen mit e-geld mit mobilem gerät mit kurzer transaktionszeit und abschliessendem settlement

Country Status (4)

Country Link
US (1) US20190347626A1 (de)
EP (1) EP3559883A1 (de)
CN (1) CN110088791A (de)
WO (1) WO2018114654A1 (de)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11704663B2 (en) * 2017-03-31 2023-07-18 Vijay Madisetti Method and system for blockchain-based vehicle identifiers and wallets for decentralized payments
CN107665427A (zh) 2017-08-22 2018-02-06 阿里巴巴集团控股有限公司 一种离线支付、业务处理、支付处理的方法及装置
WO2019185791A1 (de) 2018-03-29 2019-10-03 Pbv Kaufmann Systeme Gmbh System zum speichern, teilen und verbindlichen, schlupffreien offline-übertragen von e-werten mit mobilem gerät mit kurzer transaktionszeit
US10924269B1 (en) * 2018-08-02 2021-02-16 Inphi Corporation Compact optical module integrated for communicating cryptocurrency transaction
US11501278B2 (en) * 2019-08-09 2022-11-15 KoamTad, Inc. Internet of things (IoT) box for mobile payment retail system and in store mobile charging solution
CN110827146A (zh) * 2019-10-23 2020-02-21 支付宝(杭州)信息技术有限公司 数字货币交易的执行方法及装置和电子设备
US12099997B1 (en) 2020-01-31 2024-09-24 Steven Mark Hoffberg Tokenized fungible liabilities
CN112308546A (zh) * 2020-05-18 2021-02-02 神州融安科技（北京）有限公司 一种离线数字货币收单系统及方法
CN111899007B (zh) * 2020-08-10 2024-01-26 天翼电子商务有限公司 数字货币双离线支付方法及支付系统
CN113052984B (zh) * 2021-03-09 2023-06-30 西安艾润物联网技术服务有限责任公司 一种基于数字货币支付的车辆通行管理方法、装置及系统
CN115564414B (zh) * 2022-08-22 2023-06-06 昆明理工大学 一种数字货币双离线交易方法及系统

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002084569A1 (en) * 2001-03-29 2002-10-24 Ebestcard Ltd. Card transaction system and method on on-line and/or off-line
AU2014310337A1 (en) * 2013-08-21 2016-01-21 Visa International Service Association Methods and systems for transferring electronic money
US11250391B2 (en) 2015-01-30 2022-02-15 Visa International Service Association Token check offline

Also Published As

Publication number Publication date
WO2018114654A1 (de) 2018-06-28
CN110088791A (zh) 2019-08-02
US20190347626A1 (en) 2019-11-14

Similar Documents

Publication Publication Date Title
EP3559883A1 (de) System zum offline-bezahlen mit e-geld mit mobilem gerät mit kurzer transaktionszeit und abschliessendem settlement
DE69225197T2 (de) Elektronisches Zahlungsverkehrsystem
EP0992025B1 (de) Transaktionsverfahren mit einem tragbaren Identifizierungselement
DE69602265T2 (de) Treuhandvermittler zur offenen ausgabe von elektronischem geld
CN103413389B (zh) 基于银行账户对非银行账户管理和支付方法
DE102011100144B4 (de) Sicheres drahtloses Zahlungssystem und Verfahren zu dessen Anwendung
EP2577579A2 (de) Verfahren zum erzeugen eines transaktionssignals
EP2061001A1 (de) Zahlungsverfahren, Zahlungssystem und dazu geeignete Vorrichtungen
AT512070A1 (de) Verfahren und vorrichtung zum durchführen von bargeldlosen zahlungen
DE102011116489A1 (de) Mobiles Endgerät, Transaktionsterminal und Verfahren zur Durchführung einer Transaktion an einem Transaktionsterminal mittels eines mobilen Endgeräts
WO2010089049A1 (de) Mobiles zahlungsverfahren und vorrichtungen
KR100873363B1 (ko) 게임통장 운용 방법 및 시스템
DE102011079317A1 (de) Mobiles system für finanztransaktionen
DE102005008610A1 (de) Verfahren zum Bezahlen in Rechnernetzen
EP3699851B1 (de) Ableitung eines tokens mittels eines transaktions-bezogenen einmalschlüssels
KR101599908B1 (ko) 가맹점 단말을 통한 대출 서비스 제공 방법
WO2019185791A1 (de) System zum speichern, teilen und verbindlichen, schlupffreien offline-übertragen von e-werten mit mobilem gerät mit kurzer transaktionszeit
EP2820600A1 (de) Authentisierte transaktionsfreigabe
DE102013022434B3 (de) Elektronisches Transaktionsverfahren und Computersystem
DE102013022433B3 (de) Elektronisches Transaktionsverfahren und Computersystem
EP1274971A2 (de) Verfahren zur sicheren bezahlung von lieferungen und leistungen in offenen netzwerken
KR101785587B1 (ko) 가맹점 단말을 통한 대출 서비스 제공 방법
DE102013000967B4 (de) Verfahren zur Autorisierung einer elektronischen Transaktion
DE102013022438B3 (de) Elektronisches Transaktionsverfahren und Computersystem
DE102021130197A1 (de) Verfahren und Vorrichtung zum Verarbeiten von Daten

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

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

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

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

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20190701

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

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20200403

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

Free format text: STATUS: EXAMINATION IS IN PROGRESS

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: 20220127