Verfahren zum Verarbeiten einer Transaktion

BESCH REIBUNG

TECH NISCH ES FELD

Die Erfindung betrifft ein Verfahren zur Verarbeitung einer Transaktion .

H INTERGRUND

Aus der WO 2013/134769 AI ist ein System bekannt, bei dem ein Mobiltelefon per„Near Field Communication" (N FC) gegenüber einem

Kassengerät identifiziert wird, um eine Transaktion durchzuführen .

Die Grundlage für die N FC-Funktionalität bildet ein spezieller N FC- Chip, der zusätzlich zu anderen, unterschiedliche Funkkommunikationen ermöglichenden Hardwarekomponenten im Mobiltelefon integrierte sein muss, was sich nachteilig auf den Preis des Geräts auswirkt. Zudem hat sich die Verwendung von N FC-Komponenten in mobilen Geräten als problematisch erwiesen, weil damit üblicherweise eine Speicherung von sicherheitsrelevanten Daten im N FC-System des mobilen Geräts einhergeht, was in Fachkreisen Bedenken hinsichtlich der Datensicherheit auslöste.

Die Erfindung hat sich die Aufgabe gestellt, ein verbessertes Verfahren anzugeben, sodass die eingangs erörterten Probleme vermieden sind .

ZUSAM MENFASSUNG DER ERFINDUNG

Diese Aufgabe wird durch ein Transaktionsverfahren gemäß

Anspruch 1 gelöst.

Der Gegenstand der Erfindung ist daher ein Verfahren, das die folgenden Verfahrensschritte aufweist, nämlich Erzeugen einer Session auf einem Server zur Verarbeitung einer Transaktion, wobei an der Session neben dem Server ein Benutzer-Gerät und ein Transaktions-Gerät, das zum Erfassen der Transaktion ausgebildet ist, zur Verarbeitung der Transaktion teilnehmen können, und wobei die Session durch eines der Geräte initiiert wird, und automatisches Erkennen des Unterschreitens eines Abstandsgrenzwerts zwischen den beiden Geräten, um eine kontaktlose Kommunikationsverbindung zwischen ihnen herzustellen und dem anderen Gerät mit Hilfe der Verbindung den Beitritt zur Session zu ermöglichen, und Beitreten des besagten anderen Geräts zur Session, und Ausführen der Transaktion mit Hilfe des Servers, wenn von dem an der Session teilnehmenden Benutzer-Gerät eine Ausführungs-Bestätigung empfange wird .

Das Benutzer-Gerät kann ganz allgemein ein mobiles, insbesondere programmierbares Benutzer-Gerät, wie z. B. ein Smartphone sein, auf dem z. B. eine Benutzer-Applikation ausgeführt wird, die z.B. für einen Benutzer des Benutzer-Geräts personalisiert ist und der Bearbeitung einer Transaktion dient. Das Benutzer-Gerät kann jedoch auch als ein Computer, wie z. B. ein Laptop oder ein Tablet (englisch tablet„Schreibtafel", US-engl. tablet„Notizblock") oder Tablet-Computer realisiert sein.

Das Transaktions-Gerät kann ebenso wie das Benutzer-Gerät ausgebildet sein und eine andere Applikation, z. B. eine Kassen-Applikation ausführen, sodass das Transaktions-Gerät ein Kassen-Gerät bildet. Das

Transaktions-Gerät kann jedoch auch ein fix installiertes Terminal, wie z. B. ein Kassenterminal sein. Das Transaktions-Gerät ist zum Erfassen einer Transaktion ausgebildet. So können z.B. zu bezahlende Gegenstände erfasst werden und ein dafür zu bezahlender Gesamtpreis angezeigt werden. Die Transaktion kann jedoch auch z. B. einen Eincheckvorgang in eine Flugzeug oder den Zugang zu einer Konzertveranstaltung betreffen.

Mit der Erfindung geht der Vorteil einher, dass alle Nachteile der N FC-Technologie vermieden sind, weil die involvierten Geräte ihre

Kommunikation untereinander unter Vermeidung der NFC-Technologie sowie ihrer inhärenten Probleme realisieren.

Im Rahmen der Erfindung kommt dem Benutzer-Gerät bzw. der Benutzer-Applikation eine zweifache Funktionalität zu, nämlich einerseits eine Start- oder Trigger-Funktion (im Rahmen eines ersten„TAP" eines Benutzers) zum Starten einer Bearbeitung der Transaktion aus Benutzerperspektive unter Einbeziehung des Benutzer-Geräts und andererseits eine Bestätigungs-Funktion (im Rahmen eines zweiten„TAP" eines Benutzers) zum Bestätigen des

Ausführens der Transaktion auf dem Server oder mit Hilfe des Servers. Beide Funktionaltäten erfordern eine Benutzerinteraktion (erster„TAP" bzw. zweiter „TAP") mit dem Benutzer-Gerät, sodass eine relativ hohe Sicherheit gegeben ist, weil der Benutzer in doppelter Weise mit Hilfe des Benutzer-Geräts aktiv seine Willenserklärung zum Ausführung der Transaktion bekunden muss.

Anders als bei der NFC-Technologie, bei der transaktionssensible Daten im NFC-Chip gespeichert werden, stellt die Benutzer-Applikation am

Benutzer-Gerät nur eine Visualisierung von für die Transaktion absolut

notwendigen Informationen für den Benutzer bereit, wie z. B.

Transaktionsbeträge, Zahlungsmittel und / oder Zahlungsmöglichkeiten usw. Die tatsächliche Speicherung jener für die Ausführung der Transaktion benötigten Daten oder Parametern kann auf dem Server in einer sicheren Umgebung statt finden. Dem Server kommt in dem System somit die Bedeutung des sicheren Speicher- und Verwaltungsorts von transaktionssensiblen Daten (z.B.

Benutzerkonto, ggf. auch Zahlungsmöglichkeiten, Treueprogramme, usw.) zu, diese können somit auch nicht durch ein kompromittiertes Benutzer-Gerät (oder auch ein kompromittiertes Transaktions-Gerät) ausgespäht werden.

Um mit Hilfe des Benutzer-Geräts den Prozess der Bearbeitung einer Transaktion zu starten, wird das Benutzer-Gerät von einem Benutzer in die Nähe zu dem Transaktions-Gerät gebracht und dabei automatisch das Unterschreiten eines Abstandsgrenzwertes zwischen den Geräten festgestellt, worauf eine kontaktlose Kommunikationsverbindung zwischen den beiden Geräten hergestellt wird, um beiden Geräten eine Teilnahme an ein und derselben Session am

Server zu ermöglichen. Das automatische Feststellen der örtlichen Nähe der beiden Geräte zueinander bringt nicht nur technisch den Vorteil mit sich, dass eine eindeutige Zuordnung der beiden an der Transaktion zur Verwendung kommenden Geräte getroffen werden kann. Vielmehr kommt noch der wichtige psychologische aber auch sicherheitstechnische Aspekt hinzu, dass ein Benutzer des Benutzer-Geräts durch eine entsprechende Bewegung (erster„TAP") zum Herstellen der benachbarten Positionierung der beiden Geräte, also z. B. eine Bewegung des Benutzer-Geräts hin zu dem Transaktions-Gerät, seine

Zustimmung zur Involvierung des Benutzer-Geräts in die Bearbeitung einer Transaktion gibt.

Eine Session ist im vorliegenden Kontext eine Datenstruktur zur temporären, logischen Verbindung von dem Benutzer-Gerät, dem Transaktions- Gerät, dem Server, sowie transaktionsrelevanten Daten, um die Transaktion nach Erhalt der Ausführungs-Bestätigung (verursacht durch den zweiten„TAP") auszuführen. Im Rahmen der Session können alle drei Beteiligten miteinander Daten austauschen. Insbesondere können die Gräte mit dem Server mit Hilfe eines sicheren Hypertext-Übertragungsprotokolls (HTTPS) kommunizieren. Dabei können die zu kommunizierenden Daten zusätzlich verschlüsselt sein.

Die Session wird durch eines der Geräte am Server initiiert. Die kontaktlose Kommunikation zwischen den Geräten dient dazu, dem anderen Gerät den Beitritt zu der Session zu ermöglichen. Sobald der Server und die beiden Geräte mit Hilfe der Session logisch verbunden sind, dient die kontaktlose Verbindung zwischen den Geräten dazu, das jeweils andere Gerät zu instruieren, seinen Satus mit dem des Servers abzugleichen. Mit Hilfe der kontaktlosen Kommunikation stößt das eine Gerät das andere Gerät an, sich neue Daten betreffend die Transaktion vom Server zu holen oder den Status am Server durch Übergabe von Daten zu verändern. Bei der kontaktlosen Kommunikation zwischen den Geräten erfolgt also kein Austausch von Daten, welche das einzelne Gerät dazu ermächtigen würden, die Transaktion tatsächlich alleine auszuführen. Gleiches gilt für den Datenaustausch der Geräte mit dem Server. Auch hierbei werden keine Daten ausgetauscht, welche im Zuge der Verarbeitung der Transaktion am Server vor finaler Freigabe der Ausführung der Transaktion den Server oder das jeweilige Gerät dazu ermächtigen würden, die Transaktion alleine auszuführen. Durch die Interaktion der Geräte mit dem Server ist vielmehr sichergestellt, dass auf eindeutige Weise eine bestimmte Transaktion gemeint und letztendlich auch zur Ausführung freigegeben ist und die

involvierten Geräte dazu autorisiert sind. Erst wenn mit Empfang der Daten der Ausführungs-Bestätigung am Server alle zur Ausführung der Transaktion nötigen Daten beim Server vorliegen, kann die Transaktion tatsächlich ausgeführt werden. Der Server kann abschließend je nach Realisierung die Transaktion ausführen bzw. zur Ausführung an einen Transaktions-Ausführungs-Server weiterleiten.

Erst wenn die Bestätigungs-Funktion des Benutzer-Geräts (zweiter „TAP") ausgeführt wird, wird dort eine Ausführungs-Bestätigung generiert und an den Server kommuniziert und mit Hilfe des Servers die Transaktion ausgeführt bzw. zur Ausführung weitergeleitet. Am Benutzer-Gerät wird nur mehr die Erledigung der Transaktion angezeigt. Aus Benutzersicht stellt sich das

Gesamtverfahren als eine Folge der folgenden Ereignisse dar: erste

Benutzerinteraktion zum Starten der Verarbeitung der Transaktion unter Einbeziehung des Benutzer-Geräts, zweite Benutzerinteraktion zur Zustimmung zur Transaktion und Erledigung der Transaktion. In der Nomenklatur des

Anmelders sind diese Ereignisse als erster„TA P", zweiter„TAP" und„DONE" bezeichnet.

Weitere, besonders vorteilhafte Ausgestaltungen und

Weiterbildungen der Erfindung ergeben sich aus den abhängigen Ansprüchen sowie der nachfolgenden Beschreibung .

Das Erkennen des Unterschreitens des Abstandsgrenzwerts sowie der Verbindungsaufbau zwischen den Geräten kann vor oder nach dem Erzeugen der Session erfolgen.

Gemäß einem Aspekt der Erfindung verfügen der Server und die beiden Geräte bzw. die auf ihnen ausgeführten Applikationen jeweils über ein Schlüsselpaar (bestehend aus einem privaten und öffentlichen Schlüssel), um abzugebenden Daten, Nachrichten oder Informationen zu signieren und/oder zu verschlüsseln und bei dem empfangenden Kommunikationspartner die Identität des die Daten usw. absenden Kommunikationspartners zu verifizieren. Die Geräte bzw. die auf ihnen ausgeführten Applikationen sind dem Server bekannt bzw. bei ihm registriert. Der Server kennt die öffentlichen Schlüssel der Geräte bzw. der auf ihnen ausgeführten Applikationen.

Gemäß einem weiteren Aspekt der Erfindung können in der

Kommunikation der Geräte untereinander oder auch in der Kommunikation zwischen den Geräten und dem Server Zeitstempel vorkommen. Diese

Zeitstempel stellen sicher, dass einzelne Abläufe im Verfahren nicht länger als zulässigerweise definiert dauern können. Mit Hilfe der Zeitstempel kann ein Überschreiten von als zulässig definierten Zeitspannen festgestellt werden und folglich das Verfahren aus ablauf- und/oder sicherheitstechnischen Überlegungen abgebrochen werden.

In der Kommunikation der Geräte kann auch eine für einen bestimmten Zeitraum, z. B. einen Tag, eindeutige Kennung (im vorliegenden Fall „DailyToken" genannt) involviert sein. Diese Kennung wird vom Server für den betreffenden Zeitraum generiert und kann unnötigen Kommunikationsaufwand zwischen potentiellen Kommunikationsteilnehmern vermeiden. Diese Kennung kann bei der Kommunikation der Geräte untereinander oder mit dem Server geprüft werden. Die automatische Bestimmung der Entfernung zwischen den Geräten kann z. B. auf optische Weise erfolgen, wobei z. B. eine in eines der Gräte integrierte Kamera zum Einsatz kommt. Mit der Kamera kann z.B. ein Bild (z.B. eines QR-Codes), das auf dem Display des anderen Geräts angezeigt wird, erfasst werden. Auch kann ein Bild, das auf dem Gehäuse des anderen Geräts angebracht ist erfasst werden und damit die Entfernung ermittelt werden.

Als besonders vorteilhaft hat es sich jedoch erwiesen, wenn das Erkennen des Unterschreitens des Abstandsgrenzwerts mit Hilfe einer Messung einer Signalstärke bzw. eines Signalpegels eines empfangenen Funksignals erfolgt. Bevorzugt handelt es sich um ein Funksignal gemäß dem Bluetooth- Standard, besonders bevorzugt gemäß der Spezifikation Bluetooth Low Energy, das mit Hilfe von Kommunikationsmitteln eines ersten Typs (Bluetooth- Kommunikationsmittel) von einem der Geräte, bevorzugt von dem Transaktions- Gerät, ausgesandt und bei dem anderen Gerät, bevorzugt dem Benutzer-Gerät, empfangen wird . Zum Feststellen, ob der Abstandsgrenzwert zwischen den Geräten unterschritten wurde, wird die gemessene Signalstärke bzw. der

Signalpegel mit einem Schwellwert verglichen und, wenn die Signalstärke bzw. der Signalpegel den Schwellwert übersteigt, das Unterschreiten des

Abstandsgrenzwerts festgestellt. Mit der Verwendung der Bluetooth-Technologie geht der Vorteil einher, dass eine Technologie zum Einsatz kommt, die im

Wesentlichen flächendeckend und de facto als standardisierte Komponente in mobile Geräte integriert ist. Das Gerät weist eine hinsichtlich der Funk- Kommunikationseigenschaften standardisierte Bluetooth- Kommunikationsstufe auf, die über eine Betriebssystemschnittstelle ansteuerbar ist, bzw. über die der Status der Kommunikationsstufe bzw. der Kommunikationsparameter abfragbar ist.

Als besonders vorteilhaft hat es sich daher erweisen, dass die Signalstärke durch einen Received Signal Strength Indicator (RSSI) repräsentiert ist. Sobald eines der Geräte ein Bluetooth-Signal eines anderen Geräts empfängt wird mit Hilfe der Kommunikationsstufe der RSSI bereitgestellt. Der RSSI bildet einen Indikator für die Empfangsfeldstärke. Da der RSSI üblicherweise keine festgelegte Einheit hat, muss der Wert des RSSI abhängig vom Datenblatt des Herstellers interpretiert werden, wobei für gewöhnlich ein höherer Wert des RSSI eine höhere Empfangsfeldstärke anzeigt. Der Wert des RSSI dient also als Maß für die Entfernung. Es wird folglich ein bestimmter Wert des RSSI definiert, der als Abstandsgrenzwert zur Anwendung kommt.

Es kann von Vorteil sein, dass bei der Beurteilung der ermittelten Signalstärke bzw. des Signalpegels über relativ kurze Zeitfenster, wie z.B. 0,2 bis 1,5 Sekunden, Mittelwerte und/oder Bereichsüber-oder -unterschreitungen zur Anwendung kommen, um Fehldiagnosen betreffend den Abstand zwischen den Geräten bedingt durch Signalfluktuationen zu vermeiden.

Da die Transaktion auf der Seite des Transaktions-Geräts erfasst wird, wobei z. B. im Fall einer Bezahltransaktion zu bezahlende Gegenstände erfasst und deren Preise aufsummiert werden, hat es sich als besonders vorteilhaft erwiesen, dass Bewegungsdaten erfasst mit Hilfe eines

Bewegungssensors eines der Geräte, insbesondere des Benutzer-Geräts, das an das andere Gerät, insbesondere das Transaktions-Gerät, angenähert wird, zur Verifizierung der Gültigkeit des Erkennens des Unterschreitens des

Abstandsgrenzwerts verwendet werden. Diese Maßnahme stellt ein weiteres Sicherheitskriterium dar Konkret kann beispielsweise mit Hilfe des

Bewegungssensors des Benutzer-Geräts das Abbremsen des Benutzer-Geräts bei der Annäherung an das Transaktions-Gerät (repräsentiert durch die

Bewegungsdaten des Bewegungssensors) gemessen werden. Zur Detektion der gültigen Annäherung wird also von dem Transaktions-Gerät ein Funksignal generiert und bei dem Benutzer-Gerät das Vorliege einer Funksignalfeldstärke dieses Funksignals über einem bestimmten Wert währen eines Zeitfensters von z. B. 0,8 Sekunden und gleichzeitig das Abbremsen erkannt. Damit stellt das Benutzer-Gerät das Ausführen der Start- oder Trigger-Funktion (erster„TA P" des Benutzers) fest und kann diesen Zustand (z. B. mit Hilfe von Bluetooth-Low- Energy) an das Transaktions-Gerät und, wenn nötig, über eine weitere

Kommunikationsmethode an den Server kommunizieren.

Gemäß einem weiteren Aspekt der Erfindung bauen die beiden Geräte nach Erkennung des Unterschreitens des Abstandsgrenzwerts eine kommunikative Verbindung zueinander auf. In diesem Verbindungsaufbau können Gerätekennungen aber auch angebotene Gerätedienste abgefragt bzw. ausgetauscht werden und in Folge auch zur Anwendung kommen.

Das Erzeugen der Session kann dann grundsätzlich von jedem der beiden Geräte aus initiiert werden. Gemäß einem bevorzugten

Ausführungsbeispiel der Erfindung erfolgt das Erzeugen einer Session mit Hilf des Transaktions-Geräts in einer Kommunikation mit Hilfe von

Kommunikationsmitteln eines dritten Typs, insbesondere einer

Internetkommunikation, mit dem Server. Besonders vorteilhaft ist es, wenn die Session nur dann am Server eingerichtet wird, wenn sie von einem bei dem Server bekannten Transaktions-Gerät initiiert wird, was erheblich zur Sicherheit beiträgt. Damit geht der Vorteil einher, dass eine betrügerisch motivierte

Manipulationen oder Simulation des Transaktions-Geräts mit dem Ziel der Einrichtung einer Session auf dem Server vermieden ist, was betrügerische Aktivitäten durchgeführt über das Transaktions-Gerät weiter erschwert Die Kommunikationsmittel des dritten Typs können durch beliebe internetfähige Kommunikationsmittel, wie z. B. kabelgebundene oder funkbasierte

Kommunikationsmittel realisiert sein.

Die Kommunikationsmittel des zweiten Typs sind vorteilhafterweise zur internetbasierten Kommunikation in einem Funknetz, wie z. B. WLAN usw. , oder einem Mobilfunknetz, wie z.B. UMTS, GSM, LTE, usw. ausgebildet.

Vorteilhafterweise erhält das die Session initiierende Gerät, bevorzugt das Transaktions-Gerät in einer Kommunikation mit Hilfe der

Kommunikationsmittel des dritten Typs, von dem Server eine Session-Kennung und kommuniziert diese Session-Kennung an das andere Gerät, bevorzugt das Benutzer-Gerät in einer Kommunikation mit Hilfe der Kommunikationsmittel des ersten Typs. Die Session-Kennung kann eine eindeutige Session-Nummer und auch eine Zeitmarke zur Definition des Erstellungszeitpunkts der Session oder auch eine Geräte-Signatur des die Session anlegenden Geräts aufweisen.

Gemäß einem weiteren Aspekt der Erfindung tritt das andere Gerät, insbesondere das Benutzer-Gerät in einer Kommunikation mit Hilfe von

Kommunikationsmitteln des zweiten Typs mit dem Server, mit Hilfe der erhaltenen Session-Kennung der Session bei. Der Beitritt zur Session kann von der Gültigkeit der zuvor erwähnten Geräte-Signatur abhängig sein. Die

Kommunikationsmittel des zweiten Typs sind bevorzugt zum Kommunizieren in einem Mobilfunknetz für mobile Datenübertragung eines Mobilfunknetzbetreibers ausgebildet.

Wie eingangs erörtert, ist das Transaktions-Gerät zum Erfassen der Transaktion ausgebildet. Das Transaktions-Gerät hinterlegt in einer

Kommunikation mit Hilfe der Kommunikationsmittel des dritten Typs mit dem Server die erfasste Transaktion am Server, bevorzugt zugeordnet der Session, besonders bevorzugt als Bestandteil der Session. Dies vermeidet unautorisierte Eingriffe und mögliche Manipulationen an der Transaktion. Die Transaktion kann am Server in Form von Transaktions-Daten in einer Datenbank hinterlegt werden.

Zum Zeitpunkt der Hinterlegung der Transaktion am Server hat das Benutzer-Gerät keine Informationen betreffend die Details der Transaktion. Es fand davor lediglich der Aufbau der Verbindung mit dem Transaktions-Gerät statt, um den Beitritt beider Geräte zu besagter Session zu ermöglichen, welcher die Transaktion nun zugeordnet ist. Um dem Benutzer-Gerät die Existenz der hinterlegten Transaktion mitzuteilen, stößt das Transaktions-Gerät in einer Kommunikation mit Hilfe der Kommunikationsmittel des ersten Typs mit dem Benutzer-Gerät am Benutzer-Gerät eine Abfrage der Transaktion vom Server an.

Als Folge des Erhalts der Abfrage kommuniziert der Server eine Repräsentation der Transaktion an das Benutzer-Gerät in einer Kommunikation mit Hilfe der Kommunikationsmittel des zweiten Typs und wartet danach auf einen Empfang der Ausführungs-Bestätigung von dem Benutzer-Gerät mit Hilfe der Kommunikationsmittel des zweiten Typs. Damit geht der Vorteil einher, dass nicht die für die Ausführung der Transaktion relevanten Daten, wie

Zugangsdaten zu einem Benutzerkonto, Zahlungsmittel bzw.

Zahlungsmöglichkeiten bzw. Verweise darauf, oder auch Zugangsdaten zu einem Treueprogramm oder Parameter des Treueprogramms usw. am Benutzer-Gerät zugänglich gemacht werden, sondern alle diese Daten im sicheren Server verwahrt bleiben, somit eine Manipulation der Session oder der zugeordneten erwähnten Daten ausgeschlossen ist. Vielmehr wird dem Benutzer-Gerät nur mitgeteilt, was das Benutzer-Gerät und der Benutzer zum Bestätigen oder Ablehnen der Transaktion wissen muss. So reicht beispielsweise bei einer

Bezahltransaktion bereits die Information des Gesamtpreises für den Benutzer aus, um seine Entscheidung zu treffen. Es können jedoch auch weitere

Informationen, wie bereits berücksichtigte Rabatte bzw. die Summe des Rabatts oder auch bei Ausführung der Transaktion neu hinzukommende

Rabattmöglichkeiten von dem Server zur Bereitstellung am Benutzer-Gerät zur Information des Benutzers übermittelt werden.

Die Ausführungs-Bestätigung kann am Benutzer-Gerät auf verschiedenste Weise, z. B. durch Bewegung des Benutzer-Geräts oder durch Empfang eines akustischen Signals verursacht durch den Benutzer oder durch eine Erkennung der Berührung des Benutzer-Geräts oder einer seiner Komponenten (z.B. Knopf, Bildschirm) durch den Benutzer initiiert werden. Als besonders vorteilhaft hat es ich erwiesen, wenn bei dem Benutzer-Gerät die Ausführungs-Bestätigung als Folge einer Erkennung einer vordefinierten

Interaktion verursacht durch einen Benutzer generiert und ausgesandt wird . Dies entspricht dem Detektieren der Bestätigungs-Funktion (zweiter„TAP" eines Benutzers). Die Ausführungs-Bestätigung wird repräsentiert durch digitale Daten mit Hilfe der Kommunikationsmittel des zweiten Typs an den Server

kommuniziert. Sie kann z.B. die Session-Kennung, die signierten Trinkgeld- und TAN-Informationen und die signierte Rechnungsinformation enthalten.

Als besonders vorteilhaft hat es sich erwiesen, wenn die Erkennung der vordefinierten Interaktion bei dem Benutzer-Gerät mit Hilfe eines

berührungsempfindlichen Bildschirms und einer damit erfolgten Detektion einer Streichbewegung oder Tastbewegung ausgeführt mit einem Finger eines

Benutzers oder einem dafür vorgesehenen Gegenstand in einem begrenzten Teilbereich der Bildschirmfläche erkannt wird . Damit können heutzutage de facto standardisierte Eingabemittel des Benutzer-Geräts zum Empfang der finalen Willenserklärung des Benutzers, die Transaktion auszuführen oder abzulehnen, genutzt werden.

Auf der Seite des Servers wird als Folge des Empfangs der

Ausführungs-Bestätigung die Transaktion direkt am Server oder an einem mit dem Server kommunikativ verbundenen Transaktions-Ausführungs-Server ausgeführt. So wird beispielsweise im Fall einer Kreditkartenbezahlung als Transaktion von dem Server aus eine Verbindung zu einem sogenannten „Payment Service Provider" oder auch„Payment Network" aufgebaut, dort die benutzerspezifische Zahlung mehrfach zertifiziert (z.B. Payment Card Industry (PCI) zertifiziert) ausgeführt und von dort der Status der Ausführung der

Zahlung bei dem Server empfangen.

Gemäß einem weiteren Aspekt der Erfindung ist es von Vorteil, wenn mit Hilfe des Servers oder mit Hilfe des Transaktions-Geräts automatisch Parameter eines Treueprogramms vor der Ausführung der Transaktion für die Transaktion berücksichtigt werden. Somit ist sichergestellt, dass der

Interaktions- bzw. Bestätigungsaufwand durch den Benutzer oder durch ein Bedienpersonal, welches das Transaktions-Gerät bedient, auf einem Minimum gehalten wird, somit eine aus Sicht des Benutzers wie auch aus Sicht eines Dienstleistungsanbieters möglichst einfache und barrierefreie Integration eines Treueprogramms in die Transaktion sichergestellt ist. Benutzer und

Bedienpersonale müssen tatsächlich keine Aktivitäten mehr setzen, um dass Treueprogramm in die Transaktion zu involvieren.

Da heutzutage im täglichen Leben bereits eine kaum noch überschaubare Vielzahl an Treueprogrammen unterschiedlichster Anbieter bzw. Dienstleister existieren, hat es sich als besonders vorteilhaft erwiesen, wenn die Auswahl des zutreffenden Treueprogramms unter Ausnutzung der Kenntnis des bei dem Benutzer-Gerät bzw. im Zusammenhang mit der auf dem Benutzer- Geräts ausgeführten Applikation angemeldeten Benutzers und / oder einer Kennung des Transaktions-Geräts erfolgt. Am Server oder auch dem

Transaktions-Gerät zugänglich existieren somit Zuordnungen in Form einer Datenbank, die es dem Server oder dem Transaktions-Gerät erlauben, das richtige Treueprogramm automatisch für die Transaktion zu aktivieren bzw. involvieren. Im Fall der serverseitigen Implementierung stellt z.B. ein

Handelsunternehmen dem Betreiber des Servers seine Treueprogramm-Daten sowie die eindeutigen Transaktions-Geräte-Kennungen zur Verfügung, so dass ein für einen bei dem betreffenden Treueprogramm bei dem

Handelsunternehmen registrierter Benutzer von dem Treueprogramm profitieren kann, wenn er eine Transaktion bei einem Transaktions-Gerät des betreffenden Handelsunternehmens bzw. Dienstleisters ausführen möchte. Im Fall der Verfügbarkeit des Treueprogramms am Transaktions-Gerät macht das

Handelsunternehmen selbst die Daten des eigenen Treueprogramms für die ihm zugeordneten Transaktions-Geräte zugänglich.

Gemäß einem bevorzugten Ausführungsbeispiel der Erfindung handelt es sich bei den Parametern des Treueprogramms um Rabattcoupons, die in ihrer digitalen Repräsentation gemäß den vorangehenden Erörterungen verarbeitet werden.

Im Rahmen der Erfindung ist es von Vorteil, wenn der finale Status der Ausführung der Transaktion vom Server aus an das Benutzer-Gerät und / oder an das Transaktions-Gerät kommuniziert wird. Dabei kommen individuelle Kommunikationsmittel (gemäß dem zweiten und dem dritten Typ) zum Einsatz. Somit können alle involvierten Geräte (das Benutzer-Gerät und das

Transaktions-Gerät) darüber informiert werden, ob die Transaktion entweder erfolgreich oder nicht erfolgreich abschlössen wurde. In jedem Fall wir die Bearbeitung der Transaktion sowohl am Server als auch auf den involvierten Geräten mit dem jeweils vorliegenden finalen Status beendet, somit

sichergestellt ist, das ein unklarer Zustand einer über längere Zeit anhängigen Transaktion vermieden werden kann.

Gemäß einem weiteren Aspekt der Erfindung wird auf dem

Benutzer-Gerät eine für einen bestimmten Benutzer personalisierte Applikation ausgeführt, welche zur Interaktion mit dem Benutzer, dem Transaktions-Gerät sowie dem Server dient und zur eindeutigen Identifikation gegenüber dem Server ausgebildet ist, und somit eine automatische Selektion von Parametern betreffend die Transaktion, wie z. B. die für den Benutzer zutreffende bzw.

verfügbare Zahlungsmethode, der Zahlungsdienstleister, das anzuwendende Treueprogramm, usw. ermöglicht ist.

Als besonders vorteilhaft hat es sich erwiesen, wenn es sich bei der Transaktion um eine Bezahl-Transaktion handelt.

Die zuvor erwähnten Kommunikationsmittel der drei Typen sind bei oder in Verbindung mit den zutreffenden Vorrichtungen (Benutzer-Gerät, Transaktions-Gerät, Server) realisiert und stellen sicher, dass unterschiedliche Kommunikationsmethoden bzw. -Kanäle bei der Kommunikation zwischen den betreffenden Vorrichtungen zur Anwendung kommen, wodurch eine betrügerisch motivierte Manipulation der Kommunikation zwischen den Vorrichtungen zuverlässig vermieden ist. Nur wenn die Kommunikation gemäß der drei

Kommunikationstypen zwischen den Vorrichtungen abläuft, können die involvierten Vorrichtungen ihre Aktivitäten durchführen, die für die finale

Ausführung der Transaktion nötig sind .

Aus sicherheitstechnischen Überlegungen hat es sich zudem als vorteilhaft erwiesen, wenn zum Ausführen der Transaktion (z. B. einer sicheren Bezahl-Transaktion) die Bedingung erfüllt sein muss, dass das Transaktions- Gerät bestätigt, dass genau diese Transaktion erfolgen soll, dies signiert und am Server hinterlegt hat, der Server dies geprüft und seinerseits signiert an das Benutzer-Gerät kommuniziert hat und das Benutzer-Gerät bzw. die dort laufenden Applikation dies freigegeben und seinerseits signiert an den Server kommuniziert hat. Erst das Zustandekommen dieser Bedingung ermöglicht beim Server eine Ausführung der Transaktion.

Um die Sicherheit des Verfahrens bzw. des Systems gegenüber betrügerischen Eingriffe von außen noch weiter zu erhöhen, hat es sich als besonders vorteilhaft erweisen, wenn das Ausführen der Transaktion (bevorzugt nur) genau zu jenem Zeitpunkt ausgelöst werden kann, zu dem die Bedingung zustande kommt. Beim Server kann also die Ausführung der Transaktion im Rahmen der Session vorbereitet werden. Sobald das Benutzer-Gerät die

Ausführungs-Bestätigung an den Server übermittelt hat, wird die Transaktion sofort ausgeführt. Dies bringt den Vorteil mit sich, dass die tatsächlich

ausführbare Transaktion nur für eine minimale Zeitspanne (einige Millisekunden) anhängig sein muss und folglich eine betrügerisch motivierte Manipulation einer anhängigen und bereits freigegebenen Transaktion mit sehr hoher

Wahrscheinlichkeit zuverlässig vermieden ist.

Um die Sicherheit weiter zu erhöhen, ist das Ausführen der

Transaktion genau einmal möglich. Wenn die Transaktion dabei erfolgreich abgeschossen werden kann, ist der Vorgang erwartungsgemäß erledigt. Auch wenn die Transaktion fehlschlagen sollte, wird der Vorgang als erledigt angesehen und die Transaktion steht am Server nicht mehr für ihre Ausführung zur Verfügung. Somit sind betrügerische Eingriffe in eine anhängige Transaktion zuverlässig vermieden.

Gemäß einem weiteren Aspekt der Erfindung wird als Folge des Empfangens der Ausführungs-Bestätigung mit ihrer Hilfe ein Verweis auf eine zum Ausführen der Transaktion erforderliche Information, bevorzugt gespeichert auf einem Transaktions-Ausführungs-Server, aus einem ersten Teil-Verweis und einem zweiten Teil-Verweis im Server zusammengesetzt. Die Zweiteilung des Verweises und ihre Zusammenfügung zum tatsächlich verwendbaren Verweis erst gegen Ende der Verarbeitung der Transaktion trägt Signifikat zur Sicherheit des Verfahrens bei.

Besonders bevorzugt wurde der erste Teil-Verweis vom Server und der zweite Teil-Verweis von einer auf dem Benutzer-Gerät ausgeführten

Applikation generiert. Dies hat den Vorteil, dass der erste Teil-Verweis und der zweite Teil-Verweis in keinem Fall gemeinsam zwischen dem Benutzer-Gerät und dem Server übertragen werden müssen.

Insbesondere die Maßnahme, dass der Server mit einem selbstgenerierten symmetrischen Schlüssel den zweite Teil-Verweis

verschlüsselte und der symmetrische Schlüssel mit einem asymmetrischen Schlüssel verschlüsselt und ebenso dem zweiten Teil-Verweis zugeordnet abgelegt wurde, erhöht die Sicherheit gegenüber Angriffen Dritter. In diesem Zusammenhang hat es sich als besonders vorteilhaft erweisen, wenn allein die Applikation in der Lage ist, den symmetrischen

Schlüssel über das asymmetrische Verschlüsselungsverfahren zu entschlüsseln, da der private Schlüssel dazu am Benutzer-Gerät mit der Applikation

abgespeichert ist.

Um die Sicherheit des Verfahrens gegenüber Angriffen von außen bestmöglich zu gewährleisten ist es von Vorteil, wenn während der Bearbeitung der Transaktion der verschlüsselte symmetrische Schlüssel vom Server an die Applikation übermittelt wird, die Applikation den symmetrischen Schlüssel entschlüsselt und den entschlüsselten symmetrischen Schlüssel dem Server übergibt und der Server den zweiten Teil-Verweis mit dem symmetrischen Schlüssel entschlüsselt. Der zweite Teilverweis steht somit erst nach der

Zustimmung des Benutzers zum Ausführen der Transaktion zur Verfügung und kann erst dann mit dem ersten Teil-Verweis kombiniert werden.

Gemäß einem weiteren Aspekt der Erfindung ist es auch von Vorteil, wenn ein Teil-Verweis zunächst vom Server ein erstes Mal verschlüsselt wurde, danach vom Server an das Benutzer-Gerät übermittelt wurde, beim Benutzer- Gerät ein zweites Mal verschlüsselt wurde und danach von dem Benutzer-Gerät an den Server übermittelt und dort in doppelt verschlüsselter Form gespeichert wurde.

Die erörterten sicherheitstechnischen Maßnahmen gewährleisten, dass eine Transaktion weder vom das Benutzer-Gerät (bzw. der auf diesem Benutzer-Gerät ausgeführten Applikation), vom Server oder vom Transaktions- Gerät (bzw. der auf dem Transaktions-Gerät ausgeführten Applikation) alleine ausgelöst werden kann. Das zur Anwendung kommende sicherheitstechnische Verhalten ähnelt dem eines Bankschließfaches. Im vorliegenden Fall muss jedes der involvierten Geräte (Benutzer- und Transaktions-Gerät, Server) seine

Zustimmung geben. Nur dann kann genau zu diesem Zeitpunkt, zu dem die Zustimmung aller Geräte vorliegt, für die von dem Transaktions-Gerät und dem Server vorgegeben Parameter, die zudem vom Benutzer-Gerät bestätigt wurden, genau einmal die Transaktion durchgeführt werden („das Schließfach" geöffnet werden). Diese Systematik gewährleistet optimale Sicherheit.

An dieser Stelle sei auch erwähnt, dass die vorangehend erörterten Verfahrensschritte auch Ausbildungen von Systemkomponenten des im Rahmen der Erörterung des Verfahrens erwähnten Systems betreffen können. Vorteile, die im Zusammenhang mit den entsprechenden Verfahrensschritten erwähnt sind, treffen auf analoge Weise auf das System bzw. seine Systemkomponenten zu .

FIGUREN KURZBESCH REIBUNG

Die Erfindung wird im Folgenden unter Hinweis auf die beigefügten Figuren anhand von Ausführungsbeispielen noch einmal näher erläutert, auf welche die Erfindung jedoch nicht beschränkt ist. Dabei sind in den

verschiedenen Figuren gleiche Komponenten mit identischen Bezugszeichen versehen. Es zeigen auf schematische Weise :

Fig . 1 ein Blockdiagramm eines erfindungsgemäßes Transaktionssystem; Fig . 2 ein Sequenzdiagramm visualisierend das erfindungsgemäße Verfahren; Fig . 3 auf analoge Weise wie die Fig . 2 ein weiteres Ausführungsbeispiel der

Erfindung .

BESCH REIBUNG DER AUSFÜHRU NGSBEISPIELE

In der Figur 1 ist ein Transaktionssystem 1 zur Ausführung einer Bezahl-Transaktion dargestellt, das als ein Benutzer-Gerät ein Mobiltelefon 2, als ein Transaktions-Gerät eine elektronisches Kassenterminal 3 und einen Server 4 aufweist.

Auf dem Mobiltelefon 2 wird eine für einen bestimmten Benutzer (nicht dargestellt) personalisierte Applikation 5 ausgeführt, welche am Bildschirm 6 mit dem Buchstaben„k" visualisiert ist und zur Interaktion mit dem Benutzer, dem Kassenterminal 3, sowie dem Server 4 dient und zur eindeutigen

Identifikation gegenüber dem Kassenterminal 3 und dem Server 4 ausgebildet ist. Das Mobiltelefon 2 weist Kommunikationsmittel eines ersten Typs 7 zum Kommunizieren gemäß der Spezifikation„Bluetooth Low Energy" und

Kommunikationsmittel eines zweiten Typs 8 zum internetbasierten, funkbasierten Kommunizieren gemäß einem Mobilfunkstandard (z. B. GPRS, GSM, UMTS, usw.) auf.

Das Kassenterminal 3 wird von einem Handelsunternehmen betrieben und ist zum Erfassen einer Bezahl-Transaktion ausgebildet, was auf automatische oder manuelle Weise erfolgen kann. Dabei werden Waren und zugehörige Preise registriert und ein zu bezahlender Gesamtpreis ermittelt. Das Kassenterminal 3 weist Kommunikationsmittel des ersten Typs 7 und Kommunikationsmittel des dritten Typs 9 zur internetbasierten,

leitungsgebundenen Kommunikation (z. B. LAN) auf. Dies kann Vorteile haben, allerdings können die Kommunikationsmittel des dritten Typs 9 auch eine

Ausbildung zur drahtlosen Kommunikation aufweisen. Das Kassenterminal 3 ist an eine Datenverarbeitungsanlage 10 des Handelsunternehmens zur Abwicklung administrativer Prozesse, wie z.B. Warenhaltung, Ein- u . Verkauf, Buchhaltung, usw. angeschlossen, die ebenfalls Kommunikationsmittel des dritten Typs 9 aufweist und zur Realisierung der genannten Prozesse eine erste

Verarbeitungsstufe 11 aufweist.

Der Server 4 wird von einem Dienstleistungsunternehmen

betrieben, dessen Dienstleistung die Bereitstellung einer innovativen

Bezahlmethode ist und dient zur Bearbeitung einer von dem Kassenterminal 3 erfassten Transaktion unter Berücksichtigung einer Benutzer- wie auch

Geräteinteraktion, worauf nachfolgend noch im Detail eingegangen ist. Von diesem Unternehmen wird auch die Applikation 5 für Benutzer eines

Mobiltelefons 2 bereitgestellt. Bei der Installation am Mobiltelefon 2 erfolgt eine Registrierung der Applikation 5 sowie des zur Verwendung der Applikation 5 autorisierten Benutzers am Server 4, sodass der Benutzer eindeutig über die am Mobiltelefon 2 installierte Applikation 5 identifizierbar ist. Am Server 4 sind zudem für jeden Benutzer Zahlungsmöglichkeiten (Kontoinformationen, verfügbare Kreditkarten, usw.) bzw. Verweise darauf sowie die für den Benutzer verfügbaren Treueprogramme verschiedenster Handelsunternehmen bzw.

Verweise darauf gespeichert. Der Server hat auch Kenntnisse über die

Zugehörigkeit eines Kassenterminals 3 zu dem jeweiligen Handelsunternehmen. Der Server 4 weist zu den genannten Zwecken eine zweite Verarbeitungsstufe 12 auf. Der Server 4 weist auch Kommunikationsmittel des dritten Typs 9 sowie eine Anbindung (z. B. über das Internet) an Kommunikationsmittel des zweiten Typs 8 auf, die in Form von Mobilfunkeinrichtungen 13 eines

Mobilfunknetzbetreibers (z.B. AI, 3, Telering, usw.) realisiert sind .

In der Figur 1 ist weiterhin eine Transaktions-Ausführungs-Server 14 dargestellt, der ebenfalls Kommunikationsmittel des dritten Typs 9 sowie eine dritte Verarbeitungsstufe 15 zur Durchführung von Bezahltransaktionen für einen Benutzer aufweist. Der Transaktions-Ausführungs-Server 14 wird von einem Payment Service Provider betrieben. Die drei Verarbeitungsstufen 11, 12 und 15 weisen in nicht abschließender Aufzählung z. B. einen Prozessor, Speicherbausteine,

Schnittstellenbausteine sowie Massenspeicher auf, welche aus Gründen der Übersichtlichkeit nicht dargestellt sind. Aus Gründen der Vollständigkeit sie auch erwähnt, dass neben anderen gerätespezifischen Komponenten derartige oder ähnliche Verarbeitungsstufen auch bei den Geräten 2 und 3 ausgebildet sind.

Im Folgenden sind die Kommunikationsmittel des ersten, zweiten und dritten Typs 7 - 9 mit Komtypl 7, Komtyp2 8 und Komtyp3 9 abgekürzt.

In der Figur 1 ist weiterhin die Bewegung des Mobiltelefons 2 ausgehend von einer ersten Position 16 hin zu einer zweiten Position 17 und weg von der zweiten Position 17 hin zu einer dritten Position 18 dargestellt. Der Bewegungsverlauf folgt dabei den beiden Pfeilen 19 und 20. Dabei erfolgt eine Positionsverlagerung von außerhalb (Position 16) eines Abstandsgrenzwerts R gemessen von den Komtypl des Kassenterminals 3 nach innerhalb (Position 17) von besagtem Abstandsgrenzwert R und wieder nach außerhalb (Position 18) des Abstandsgrenzwerts R. Ausgangsposition (Position 16) und Endposition (Position 18) können unterschiedlich oder auch identisch sein. Auch können die jeweiligen Bewegungsverläufe zwischen Anfangs- und Endposition identisch oder

unterschiedlich sein.

In der Figur 1 ist weiterhin dargestellt, dass die Applikation 5 zu Beginn der Bewegung aktiv ist, was durch einen Strichkranz, der auch rotierend animiert sein kann, rundum den Buchstaben„k" angedeutet ist. Sobald der Abstandsgrenzwert R unterschritten wurde, wird dies erkannt, was durch

Ausblendung des Strickkranzes angedeutet ist. In weiterer Folge wird am

Bildschirm 6 der mit Hilfe des Kassenterminals 3 ermittelte zu bezahlende Betrag (€ 20.-) angezeigt und dem Benutzer mit Hilfe von zwei Schaltflächen 22, 23 die Möglichkeit geboten, die Ausführung der Bezahltransaktion zu starten (erste Schaltfläche 22) oder abzulehnen (zweite Schaltfläche 23). Wird die erste

Schaltfläche 22 betätigt, wird die am Server 4 vom Kassenterminal 3 hinterlegte Transaktion ausgeführt, wobei nachfolgend mit Hilfe des in der Figur 2

dargestellten Sequenzdiagramms ein erstes Ausführungsbeispiel des

erfindungsgemäßen Transaktionsverfahren im Detail erörtert wird .

In dem Sequenzdiagramm sind am oberen Rand die in der Figur 1 dargestellten Vorrichtungen (Mobiltelefon 2, Kassenterminal 3, Server 4) und der zeitliche Ablauf des Verfahrens von oben nach unten in Form von Schritten des Verfahrens visualisiert. Ausgangspunkt der Erörterung ist eine mit Hilfe des Kassenterminals 3 erfasste Transaktion. Es wurde also die Erfassung von Waren und die Aufsummierung ihrer Preise zu einem Gesamtpreis abschlössen.

Daraufhin prüft das Kassenterminal 3 mit Hilfe der Komtypl 7 in einem ersten Schritt 101 ob es ein Funksignal gemäß Bluetooth Low Energy empfängt. Da die Applikation 5 am Mobiltelefon 2 bereits gestartet ist und das Mobiltelefon 2 mit Hilfe seiner Komtypl 7 ein solches Funksignal generiert, wird ein solches Funksignal bei dem Kassenterminal 2 empfangen und ausgewertet und ein Datensatz zur Identifikation bei dem Kassenterminal angelegt. Das Mobiltelefon 2 befindet sich zu diesem Zeitpunkt noch an der ersten Position 16, von der es nun in Richtung der zweiten Position 17 bewegt wird (siehe Figur 1).

Gemäß der Figur 2 prüft in einem zweiten Schritt 102 das Kassenterminal 3 automatisch, ob das Mobiltelefon 2 in einen Bereich innerhalb des Abstandsgrenzwerts R eingebracht wurde (z. B. entlang des in der Fig . 1 abgebildeten Pfeils 19), also der Abstandsgrenzwert R unterschritten wurde. Dies erfolgt durch eine Messung des Signalpegels des empfangen Funksignals und einen Vergleich des über ein Zeitfenster von beispielsweise 0,8 Sekunden gemittelten Messwerts mit einem vordefinierten Schwellwert. Sobald die

Unterschreitung des Abstandsgrenzwerts R festgestellt wurde, erfolgt in den Schritten 103 bis 109 ein Verbindungsaufbau zwischen den Geräten 2 und 3, bei dem Dienste von dem Mobiltelefon 2 abgefragt werden, Charakteristiken der Dienste ermittelt werden und abschließend ein verbundener Status hergestellt wird .

In den weiteren Schritten 110 bis 116 wird am Server eine Session erzeugt, an der sowohl das Mobiltelefon 2 als auch das Kassenterminal 3 beteiligt sind. Zu diesem Zweck wird in einem zehnten Schritt 110 eine bei dem

Kassenterminal 3 generierte Zufallszahl zusammen mit einer eindeutigen

Kennung des Kassenterminals 3 an das Mobiltelefon 2 mit Hilfe der Komtypl 7 kommuniziert. Der Erhalt wird in einem elften Schritt 111 mit Hilfe der Komtypl 7 bestätigt. In einem zwölften Schritt 112 wird eine Anfrage zum Anlegen einer Session von dem Mobiltelefon 2 mit Hilfe der Komtyp2 8 an den Server 4 gesandt, wo die Session eingerichtet wird. Vom Server 4 wird in einem

dreizehnten Schritt 113 eine Signatur der Session gebildet aus Kennung des Kassenterminals 3, der Zufallszahl, einer Session-Kennung und einem

Zeitstempel an das Mobiltelefon 2 mit Hilfe der Komtyp2 8 übermittelt. In einem vierzehnten Schritt 114 wird eine Aufforderung zum Beitritt zu dieser Session von dem Mobiltelefon 2 an das Kassenterminal 3 gesandt. Die empfangene Aufforderung wird bei dem Kassenterminal 3 zunächst daraufhin geprüft, ob tatsächlich das empfangende Kassenterminal 3 adressiert ist. Zu diesem Zweck wird die Aufforderung hinsichtlich der Kennung des Kassenterminals 3 sowie der Zufallszahl ausgewertet. Soweit diese Prüfung positiv abgeschlossen wird, kommuniziert das Kassenterminal 3 mit Hilfe der Komtyp3 9 in einem

fünfzehnten Schritt 115 seinen Beitritt zu der durch die Session-Kennung angezeigten Session an den Server 4; anderenfalls erfolgt ein Abbruch. Der Server 4 bestätigt in einem sechzehnten Schritt 116 mit Hilfe der Komptyp3 9 dem Kassenterminal 3 den Beitritt zur Session.

Im Rahmen der nun etablierten Session fragt das Kassenterminal 3 in einem siebzehnten Schritt 117 mit Hilfe der Komtyp3 9 von dem Server 4 die für die erfasste Bezahltransaktion zulässigen Rabatte ab. Dabei berücksichtigt der Server 4 einerseits die Identität des gemäß der installierten Applikation eindeutig festgelegten Benutzers. Andererseits berücksichtigt der Server 4 auch mit Hilfe der eindeutigen Kennung des Kassenterminals das damit eindeutig festgelegte Handelsunternehmen und kann somit das für die Transaktion zulässige Treueprogramm selektieren und in den Daten des Treueprogramms prüfen, ob für den Benutzer ein Rabat (z. B. in Form digitaler Rabatcoupons) des im Rahmen der Erfassung der Transaktion ermittelten Gesamtpreises möglich ist. Der von dem Server 4 an das Kassenterminal 3 in einem achtzehnten Schritt 118 mit Hilfe der Komtyp3 9 kommunizierte Rabat wird bei dem Kassenterminal 3 berücksichtigt und der um den Rabat reduzierte zu bezahlende Gesamtbetrag berechnet und in einem neunzehnten Schritt 119 mit Hilfe der Komtyp3 9 von dem Kassenterminal 3 an den Server 4 kommuniziert, wo die Transaktion in Form eines Zahlungsauftrags gekennzeichnet mit einer Zahlungskennung der Session zugeordnet hinterlegt wird . Die Identifikation des betroffenen Benutzers, wird über die Session gewährleistet. Von dem Server 4 wird in einem

zwanzigsten Schritt 120 eine Bestätigung des hinterlegten Zahlungsauftrags mit Zahlungskennung mit Hilfe der Komtyp3 9 an das Kassenterminal 3 übermittelt.

In weiter Folge wird in einem einundzwanzigsten Schritt 121 von dem Kassenterminal 3 mit Hilfe der Komtypl 7 an das Mobiltelefon 2 eine

Aufforderung zum Abfragen eines Zahlungsauftrags von dem Server 4

übermittelt. Daraufhin wird in einem zweiundzwanzigsten Schritt 122 unter Kenntnis der Session-Kennung von dem Mobiltelefon 2 mit Hilfe der Komtyp2 8 eine Abfrage eines Zahlungsauftrags an den Server 4 übermittelt. In einem dreiundzwanzigsten Schritt 123 wird dann vom Server 4 lediglich die für den Benutzer des Mobiltelefons 2 zum Entscheiden essentiellen Informationen des Zahlungsauftrags wie z. B. Zahlbetrag, gegebenenfalls auch ergänzt durch

Rabatinformation und / oder Trinkgeldbetrag sowie die für die Applikation 5 zum Kommunizieren der Entscheidung des Benutzers an den Server 4 essentielle Zahlungskennung übermittelt. Danach wartet der Server 4 auf die Entscheidung des Benutzers, die Transaktion auszuführen oder abzubrechen. Gleiches gilt für das Kassenterminal 3.

Zu diesem Zeitpunkt kann das in der Figur 1 dargestellte Mobiltelefon 2 noch innerhalb des Abstandsgrenzwerts R oder bereits wieder außerhalb lokalisiert sein. Jedenfalls erfolgt eine Anzeige der für den Benutzer zum Entscheiden essentiellen Information analog jener an der dritten Position 18 dargestellten. Sobald der Benutzer die zweite Schaltfläche 23 berührt wird sein Wunsch, die Transaktion abzubrechen an den Server 4 und an das

Kassenterminal 3 übermittelt, wonach die Transaktion storniert wird, was in der Fig . 2 nicht dargestellt ist. Berührt der Benutzer jedoch die erste Schaltfläche 22, wird das in der Figur 2 dargestellte Verfahren fortgesetzt.

Von dem Mobiltelefon 2 wird in einem vierundzwanzigsten Schritt 124 mit Hilfe der Komtyp2 8 eine Ausführungs-Bestätigung generiert und an den Server 4 kommuniziert. In einem fünfundzwanzigsten Schritt 125 wird die Transaktion durch Kontaktaufnahme des Servers 4 mit dem Transaktions- Ausführungs-Server 14 ausgeführt und der finale Status der Ausführung der Transaktion von dem Transaktions-Ausführungs-Server 14 empfangen. In einem sechsundzwanzigsten Schritt 126 wird dieser Status mit Hilfe der Komtyp2 8 an das Mobiltelefon 2 übertragen. In einem siebenundzwanzigsten Schritt 127 wird mit Hilfe der Komtypl 7 eine Repräsentation dieser Ausführungs-Bestätigung an das Kassenterminal 3 gesendet. Die Repräsentation der Ausführungs-Bestätigung zeigt dem Kassenterminal 3 lediglich die Zustimmung zum Ausführen der

Zahltransaktion an. Die Ausführungs-Bestätigung als solche bezieht sich auf die Session-Kennung und die Zahlungskennung und ist somit bei dem Server eindeutig zuordenbar. In einem achtundzwanzigsten Schritt 128 wird dieser Status mit Hilfe der Komtyp3 9 von dem Server 4 abgefragt und in einem neunundzwanzigsten Schritt 129 mit Hilfe der Komtyp3 9 an das Kassenterminal 3 kommuniziert. Beide Geräte 2 und 3 sowie der Server 4 beenden daraufhin die Session.

Nachfolgend wird mit Hilfe des in der Figur 3 dargestellten Sequenzdiagramms ein zweites Ausführungsbeispiel des erfindungsgemäßen Transaktionsverfahrens im Detail erörtert. Im vorliegen Fall ist auch der

Transaktions-Ausführungs-Server 14 in das Sequenzdiagramm an seinem rechten Rand aufgenommen. Die Kommunikation zwischen den Geräten 2, 3; 3, 4; sowie 2, 4 erfolgt mit Hilfe der Kommunitypl 7 - Komtyp3 9 wie eingangs im Zusammenhang mit den Figuren 1 und 2 erörtert, sodass nachfolgend nicht mehr darauf im Detail eingegangen ist. Ausgangspunkt der Erörterung ist, dass mit Hilfe des Kassenterminals 3 eine Gesamtsumme für eine Bezahltransaktion ermittelt wurde.

Sobald die Applikation 5 auf dem Mobiltelefon gestartet wird, prüft sie, ob sie für den betreffenden Tag von dem Server 4 bereits einen

„DailyTaken", erhalten hat. Der„DailyToken" ist eine für den jeweiligen Tag individuell vom Server 4 generierte, eindeutige und ursprünglich nur dem Server

4 bekannte Kennung, die somit nicht dem aktuellen Datum entspricht. Soweit dieser„DailyToken" bei der Applikation 5 noch nicht vorliegt, wird er in einem Schritt 201 von dem Mobiltelefon 2 bei dem Server 4 angefordert und in einem Schritt 202 von dem Server 4 an das Mobiltelefon 2 bzw. seine Applikation 5 kommuniziert.

Sobald am Kassenterminal 3 die Bezahlart„Applikation am Mobiltelefon" ausgewählt wurde, wird vom Kassenterminal 3 aus in einem weiteren Schritt 203 am Server 4 das Anlegen eine Session zur Verarbeitung einer Bezahltransaktion initiiert und dort angelegt. Der Server 4 übermittelt in einem weiteren Schritt 204 die für die soeben angelegte Session eindeutige Session-Kennung und den„DailyToken" an das Kassenterminal 3.

Daraufhin wird das Mobiltelefon 2 an das Kassenterminal 3

angenähert und letztendlich in einen Bereich innerhalb des Abstandsgrenzwerts R (siehe Fig . 1) eingebracht. Im Unterscheid zu dem in der Fig . 1 und 2

beschriebenen Verfahrensablauf prüft nun das Mobiltelefon 2 bzw. die darauf ausgeführte Applikation 5 automatisch, ob das Mobiltelefon 2 in einen Bereich innerhalb des Abstandsgrenzwerts R in Bezug auf das Kassenterminal 3

eingebracht wurde, also der Abstandsgrenzwert R unterschritten wurde. Sobald die Unterschreitung des Abstandsgrenzwerts R festgestellt wurde, erfolgt in einem weiteren Schritt 205 ein Verbindungsaufbau der

Applikation 5 mit dem Kassenterminal 3, bei dem von der Applikation 5 an das Kassenterminal 3 der bei der Applikation 5 bekannte„DailyToken" übermittelt wir. In einem weiteren Schritt 206 wird bei dem Kassenterminal 4 der von der Applikation 5 erhaltene„DailyToken" mit dem bei dem Kassenterminal 4 bekannten„DailyToken" geprüft, und bei Übereinstimmung in einem weiteren Schritt 207 die Session-Kennung zusammen mit einem Hash-Wert des bei dem Kassenterminal 3 bekannten„DailyToken" von dem Kassenterminal an die Applikation 5 übermittelt wird. Dort wird in einem weiteren Schritt 208 nochmals der„DailyToken geprüft und, soweit der vom Kassenterminal 3 erhaltene „DailyToken" als gültig eingestuft wird, in einem weiteren Schritt 209 mit Hilfe der bei dem Mobiltelefon 2 bekannten Session-Kennung ein Beitritt der

Applikation 5 zu der Session am Server 4 vollzogen und in einem weiteren Schritt 210 vom Server 4 der Beitritt bestätigt. Von diesem Zeitpunkt an sind der Server 4, das Kassenterminal 3 und das Mobiltelefon 2 bzw. dessen Applikation 5 mit Hilfe der Session logisch verbunden und können miteinander verschlüsselter Informationen austauschen.

In einem weiteren Schritt 211 wird der Beitritt zur Session von der Applikation 5 an das Kassenterminal 3 kommuniziert. Daraufhin wird in einem weiteren Schritt 212 vom Kassenterminal 3 aus am Server 4 ein Zahlungsauftrag eingerichtet, welcher der Session zugeordnet ist. Der Zahlungsauftrag wird vom Kassenterminal 3 signiert am Server 4 hinterlegt. Vom Server 4 wird in einem weiteren Schritt 213 die Einrichtung des Zahlungsauftrags bestätigt und ein TAN- Code (z. B. ein dreistelliger Zahlencode), also ein Einmalpasswort, an das

Kassenterminal 3 kommuniziert und dort in einem weiteren Schritt 214 mit Hilfe seiner Anzeigemittie dem Benutzer des Mobiltelefons 2 visualisiert. Das

Kassenterminal 3 fordert in einem weiteren Schritt 215 die Applikation 5 auf, die Existenz eines Zahlungsauftrags am Server 4 zur bekannten Session zu prüfen.

Unter Kenntnis der Session-Kennung fragt die Applikation 5 in einem weiteren Schritt 216 nun vom Server 4 den zu der Session anhängigen Zahlungsauftrag ab. Daraufhin generiert der Server 4 in einem weiteren Schritt 217 eine Rechnungsinformation und ergänzt in einem weiteren Schritt 218 den Zahlungsauftrag um die Rechnungsinformation. Der Server 4 überträgt sodann in einem weiteren Schritt 219 die Rechnungsinformation in von ihm signierter Form an die Applikation 5. Die Rechnungsinformation liegt somit in vom Server 5 geprüfter und signierter Form bei der Applikation 5 vor. Dort wird der zu bezahlende Betrag (z. B. EURO 37,50) mit Hilfe des Bildschirms 6 dem Benutzer des Mobiltelefons 2 visualisiert.

Da im vorliegenden Fall der zu bezahlende Betrag kleiner als ein Grenzwert (z. B. EURO 200.-) ist, wird in dem Schritt 219 auch der TAN-Code an die Applikation mitübertragen und mit Hilfe des Bildschirms 6 visualisiert. Er muss also nicht explizit eingetippt werden, was eine Erleichterung für den

Benutzer bei der Zahlung relativ niedriger Beträge mit sich bring. Der Benutzer kann vor Bestätigung der Transaktion den am Mobiltelefon 2 angezeigten TAN- Code mit jenem am Kassenterminal 3 angezeigten TAN-Code vergleichen und seine Bestätigung von der Identität der beiden angezeigten TAN-Code abhängig machen. Für den Fall, dass der zu bezahlende Betrag größer als der Grenzwert ist, entfällt die automatische Anzeige des TAN-Codes am Bildschirm 6 des

Mobiltelefons 2 und der TAN-Code wird lediglich am Kassenterminal 3 angezeigt, wo er vom Benutzer aus Sicherheitsgründen abzulesen und am Mobiltelefon 2 manuell einzugeben ist.

Soweit der Benutzer mit der Transaktion einverstanden ist, betätigt er die erste Schaltfläche 22 am Bildschirm 6 (ggf. nach Eingabe eines

Trinkgeldbetrags und / oder nach Eingabe des TAN-Codes), was in einem weiteren Schritt 220 von der Applikation 5 festgestellt wird . In einem

darauffolgenden Schritt 221 wird die Tatsache der Zustimmung des Benutzers als solches ohne weitere Daten von dem Mobiltelefon 2 an das Kassenterminal 3 kommuniziert. Zudem werden in einem weiteren Schritt 222 von der Applikation 5 zuvor erhaltenen Informationen (insbesondere die Session-Kennung) in von ihr signierter Form als Ausführungs-Bestätigung an den Server 4 übertragen.

Am Server 4 wird in einem weiteren Schritt 223 die Signatur des Zahlungsauftrags geprüft, der Zahlungsauftrag beispielsweise um Informationen zum Trinkgeld ergänzt, der Status des Zahlungsauftrags auf akzeptiert gesetzt, und ein ALIAS (ein Verweis auf ein Zahlungsverfahren bzw. eine

Zahlungsmethode gespeichert auf dem Transaktions-Ausführungs-Server 14, wo z. B. die tatsächlich zur Anwendung kommenden Kreditkarteninformationen liegen) erstellt.

Beim Erstellen des ALIAS werden ein ALIAS-Prefix (erster Teil- Verweis), gebildet durch z. B. die ersten m Stellen des ALIAS, und ein ALIAS- Suffix (zweiter Teil-Verweis), gebildet durch z. B. die den m Stellen folgenden n Stellen des ALIAS, zusammengefügt.

Die Generierung des ALIAS-Prefix und des ALIAS-Suffix erfolgte gemäß einem diesem Transaktionsverfahren vorgelagerten Verfahren im Rahmen der Erstellung einer neuen Bezahlmethode (Bezahlkarte). Dabei erfolgte eine Auswahl einer z. B. Kreditkarte (VISA / MasterCard / Diners Club / usw.) unter Eingabe der Kartendaten (Kartennummer, Karteninhaber, Ablaufdatum,

Sicherheitscode). Der Server 4 generierte den ALIAS-Präfix, der einer

Bezahlkarte in der Applikation 5 zugeordnet ist, und die Applikation 5 generiert für diese Bezahlkarte den ALIAS-Suffix.

Der Server 4 erhielt von der Applikation 5 den ALIS-Suffix. Der Server 4 verschlüsselte mit einem selbstgenerierten symmetrischen Schlüssel den ALIAS-Suffix und legte danach den ALIAS-Suffix in seiner Datenbank ab. Der symmetrische Schlüssel wurde mit einem asymmetrischen Schlüssel

verschlüsselt und ebenso dem ALIAS-Suffix zugeordnet abgelegt.

Allein die Applikation 5 ist in der Lage den symmetrischen Schlüssel über das asymmetrische Verschlüsselungsverfahren zu entschlüsseln, da der private Schlüssel dazu am Benutzer-Gerät 2 mit der Applikation 5 abgespeichert ist.

Während des Bezahlvorgangs wird bei dem Schritt 219 der verschlüsselte symmetrische Schlüssel vom Server 4 an die Applikation 5 übermittelt, die Applikation 5 entschlüsselt den symmetrischen Schlüssel und übergibt in dem Schritt 222 den entschlüsselten symmetrischen Schlüssel dem Server 4. Damit der Server 4 den gesamten ALIAS nun dem Transaktions- Ausführungs-Server für die Bezahlabwicklung übergeben kann, entschlüsselt der Server 4 den ALIAS-Suffix mit dem symmetrischen Schlüssel, setzt ALIAS-Prefix und ALIAS-Suffix zusammen und kann somit den ALIAS verwenden.

Soweit am Server 4 festgestellt wurde, dass die von der Applikation 5 erhaltenen Informationen in Ordnung sind, also ein gültiger Zahlungsauftrag vorliegt, wird vom Server 4 in einem weiteren Schritt 224 der Transaktions- Ausführungs-Server 14 mit den verschiedenen zahlungsrelevanten Daten kontaktiert und sämtliche benötigte Daten, insbesondere auch der ALIAS, der eine Zahlungskarte identifiziert, an ihn übergeben.

Soweit die Transaktion am Transaktions-Ausführungs-Server 14 erfolgreich durchgeführt werden konnte, wird dies in einem weiteren Schritt 225 dem Server 4 mitgeteilt und dort in einem weiteren Schritt 226 der Status des Zahlungsauftrags auf ausgeführt geändert.

Die Bestätigung der Durchführung der Bezahlung wird in einem weiteren Schritt 227 von dem Server 4 an die Applikation 5 kommuniziert, wo die Erledigung der Transaktion mit Hilfe des Bildschirms 6 für den Benutzer visualisiert wird. Die Applikation fordert in einer Kommunikation bei einem weiteren Schritt 228 das Kassenterminal 3 auf, seinen Status zum

Zahlungsauftrag auf Letztstand zu bringen. Daraufhin fragt das Kassenterminal 3 in einem weiteren Schritt 229 den Status zur Session-Kennung vom Server 4 ab. Der Server 4 kann, falls er noch keine Bestätigung vom Transaktions- Ausführungsserver 14 erhalten hat, in einem weiteren Schritt 230 mit dem Transaktions-Ausführungs-Server 14 klären, ob die Zahlung akzeptiert wurde und erhält in einem weiteren Schritt 231 eine Zahlungsbestätigung, die zum Zahlungsauftrag gespeichert wird und in einem weiteren Schritt 232 an das Kassenterminal 3 kommuniziert wird, sodass auch dort eine Visualisierung der Bestätigung der Durchführung der Transaktion erfolgen kann.

Zusammenfassend ist für beide Ausführungsformen des erfindungsgemäßen Verfahrens der Vorteil sichergestellt, dass eine Zahlung eines Betrags weder von dem Mobiltelefon, auf dem die Applikation 5 läuft, vom Server 4 oder vom Kassenterminal 3 allein ausgelöst werden kann. Im

übertragenen Sinne ist es wie bei einem Bankschließfach. Jeder der Teilnehmer 5 und 3 und 4 muss sein„ok" geben, damit sich das Schließfach öffnet. Nur wenn das Kassenterminal 3 bestätigt dass genau dieser Betrag bezahlt werden soll (Schritt 212), der Server 4 dies geprüft und signiert hat (Schritte 217 - 219) und vor allem die Applikation 5 dies durch (als Folge des Drücken der ersten

Schaltfläche 22 (ok) durch einen Benutzer) die Übermittlung der Ausführungs- Bestätigung freigegeben und signiert hat, kann für genau diesen Betrag zu genau diesem Zeitpunkt für die Parameter, die das Kassenterminal 3 und der Server 4 vorgegeben und von der Applikation bestätigt wurden, genau einmal die sichere Zahlung ausgelöst werden (resp. auf die Analogie des Schließfaches übertragen das Schließfach geöffnet werden).

Abschließend sei erwähnt, dass die im Zusammenhang mit einem Ausführungsbeispiel erwähnten Maßnahmen auch bei dem anderen zur

Anwendung kommen können. So können insbesondere die Maßnahmen betreffend den Daily-Token und / oder das Verschlüsselungsverfahren auch bei dem gemäß der Fig. 2 erörterten Ausführungsbeispiel zur Anwendung kommen.

Es wird abschließend noch einmal darauf hingewiesen, dass es sich bei den vorangehend detailliert beschriebenen Figuren nur um

Ausführungsbeispiele handelt, welche vom Fachmann in verschiedenster Weise modifiziert werden können, ohne den Bereich der Erfindung zu verlassen. Es wird der Vollständigkeit halber auch darauf hingewiesen, dass die Verwendung der unbestimmten Artikel„ein" bzw.„eine" nicht ausschließt, dass die betreffenden Merkmale auch mehrfach vorhanden sein können. Auch können individuell offenbarte Merkmale mit anderen Merkmalen kombiniert werden, ohne dass von dem Konzept der Erfindung abgewichen wird .