DE102013000967B4

DE102013000967B4 - Verfahren zur Autorisierung einer elektronischen Transaktion

Info

Publication number: DE102013000967B4
Application number: DE102013000967.7A
Authority: DE
Inventors: Marcus Seiler; Ngoc-Khanh Le
Original assignee: Individual
Current assignee: Individual
Priority date: 2013-01-22
Filing date: 2013-01-22
Publication date: 2016-01-07
Anticipated expiration: 2033-01-23
Also published as: DE102013000967A1; WO2014114675A1

Abstract

Verfahren zur Autorisierung einer elektronischen Transaktion in einem Initiator-Endgerät (3), wobei mindestens folgende Verfahrensschritte durchlaufen werden: – Senden (24) einer Initiatorinformation auf einem Kurzstreckenübertragungsweg an ein Ziel-Endgerät (1), vorzugsweise in einer unidirektionalen Übertragung, wobei die Initiatorinformation protokollbezogene Initiator-Kommunikationsparameter umfasst; – Empfangen (25) einer von einem Autorisierungsserver (2) gemäß den Initiator-Kommunikationsparametern gesendeten Bestätigungsanfrage; – Senden (27) einer Bestätigungsantwort an den Autorisierungsserver (2); – Empfangen (28) eines von dem Autorisierungsserver (2) gemäß den Initiator-Kommunikationsparametern gesendeten Initiator-Referenzcodes und – Senden (29) des Initiator-Referenzcodes auf einem Kurzstreckenübertragungsweg an das Ziel-Endgerät (1), vorzugsweise in einer unidirektionalen Übertragung.

Description

Die Erfindung betrifft ein Verfahren zur Autorisierung einer elektronischen Transaktion in einem Initiator-Endgerät mit den Merkmalen des Anspruchs 1 sowie ein Computerprogramm mit den Merkmalen des Anspruchs 8.
Durch die zunehmende Verbreitung von tragbaren elektronischen Geräten mit weit reichenden Kommunikationsfähigkeiten, insbesondere Mobiltelefonen und Smartphones, bietet es sich an, verschiedene Vorgänge, bei denen eine Identifikation und ggf. zusätzlich oder alternativ ein Vermögensübergang stattfindet und welche herkömmlich auf anderem Wege durchgeführt werden, mittels dieser tragbaren elektronischen Geräte zu verrichten. Hierzu zählen beispielsweise das Bezahlen beim Einkauf, die Identifikation unter Zusatz von Kasseninformationen beim Arztbesuch, die Benutzung oder das Anmieten von Verkehrsmitteln, das Abstimmen bei einer Wahl, das Einbuchen in einen Hot-Spot oder das Ausleihen von Medien in einer Bibliothek oder in einer Videothek.
Herkömmlicherweise werden diese Vorgänge entweder mit Bargeld oder mit einer jeweils für diesen Vorgang vorgesehenen Chip- oder Magnetstreifenkarte abgewickelt, also etwa einer Kreditkarte, einer Dauerfahrkarte, einer Versicherungskarte, einer Mitgliedskarte, einer Bonusprogrammkarte usw. und so fort. Jeder dieser genannten Vorgänge, bei denen eine Identifikation und ggf. die Übermittlung weiterer Informationen von dem Initiator des jeweiligen Vorgangs an den betreffenden Empfänger oder das Ziel vorgenommen wird, kann ganz allgemein und speziell im Kontext der vorliegenden Erfindung als Transaktion und insbesondere als elektronische Transaktion bezeichnet werden.
Entsprechend der Vielzahl solcher Situationen und der Verwendung dedizierter Mittel oder Karten ergibt sich die Notwendigkeit, alle diese Karten bei sich führen zu müssen und ggf. auch die der jeweiligen Karte zugeordnete persönliche Identifikationsnummer (PIN) – welche sich von allen anderen PINs der Person unterscheiden sollte – im Gedächtnis zu behalten.
Eine Vereinfachung dieses Karten- und PIN-Vielerleis ließe sich erreichen, wenn viele oder alle dieser elektronischen Transaktionen mittels des Mobiltelefons oder Smartphones der betreffenden Person abgewickelt werden könnten. Ein Mobiltelefon oder Smartphone bietet eine Funktionalität, welcher der eines Personalcomputers gleicht oder nahekommt. Diese Geräte bieten also viele technische Möglichkeiten zur Umsetzung einer solchen Transaktion, zumal sie schon durch ihre jeweilige SIM(Subscriber Identity Module)-Karte in der Regel eindeutig einem Benutzer zugeordnet sind.
In diesem Zusammenhang hat die Frage große Bedeutung, wie ein Verfahren zur Autorisierung einer solchen elektronischen Transaktion ausgestaltet werden könnte, welches allen Sicherheitsrisiken Rechnung trägt und gleichzeitig komfortabel für den Benutzer ist. Unter der Autorisierung einer elektronischen Transaktion ist vorliegend die positive Feststellung zu verstehen, dass die Transaktion sowohl hinsichtlich ihres Inhalts als auch hinsichtlich der beteiligten Parteien authentifiziert wurde und folglich durchgeführt werden darf. Wenn eine solche Feststellung nicht möglich ist, wird die elektronische Transaktion nicht durchgeführt.
Die amerikanische Patentanmeldung US 2010/0114776 A1 beschreibt eine Anwendung, durch die sich Inhaber von Kreditkarten in Echtzeit für eine Online-Transaktion durch ein Challenge-Response-Verfahren authentifizieren können. Das Challenge-Response-Verfahren basiert auf einer Risikoabschätzung für die jeweilige Online-Transaktion.
Die amerikanische Patentanmeldung US 2011/0178925 A1 betrifft ein tokenbasiertes Authentifizierungssystem, bei welchem Kartenausgabestellen, Händler und ein Zahlungsverarbeitungsnetzwerk Nachrichten untereinander sowie einen Kunden authentifizieren. Die Authentifizierung des Kunden erfolgt wiederum über einen web-basierten oder einen mobilen Kanal.
Die amerikanische Patentanmeldung US 2011/0302089 A1 beschreibt eine Methode zum Verifizieren der Benutzungserlaubnis einer Kreditkarte mit einem tragbaren Kommunikationsgerät wie ein Smartphone. Der Kunde präsentiert dem Händler das Kommunikationsgerät, so dass der Händler Informationen extrahieren kann, worauf basierend der Händler eine Identitätsbestätigungsanfrage absendet. Eine Information bezüglich des Kreditkartenbenutzers, wie etwa eine Fotodarstellung, wird dann auf das Kommunikationsgerät des Kreditkartenbenutzers übertragen.
Die europäische Patentanmeldung EP 1 339 030 A1 beschreibt ein Verfahren zur Authentifizierung eines Internetbenutzers über ein Daten- bzw. Telekommunikationsnetz bei der Registrierung bei einem Anbieter von Waren oder Dienstleistungen im Internet, wobei durch einen Datenaustausch eine eindeutige Zuordnung eines wählbaren Benutzernamens und Passwortes und der MSISDN des Internetbenutzers zueinander hergestellt werden, mit denen dann eine eindeutige Authentifizierung des Nutzers bei der Registrierung gewährleistet ist.
Aus der WO 2012/003892 A1 ist ein Verfahren zur Kreditkartenbezahlung bekannt, bei der ein tragbares Kartenlesegerät mit einem Mobiltelefon zur Abwicklung einer Kreditkartenbezahlung eingesetzt wird.
Das aus der WO 2012/003892 A1 bekannte Verfahren hat aber erstens den Nachteil, dass auf Seiten des Käufers neben dem Mobiltelefon noch als weiteres Gerät sowohl das Kartenlesegerät als auch wie bisher die Kreditkarte selbst verwendet werden muss. Im Ergebnis sind also mehr körperliche Einzelteile notwendig als vor Einführung der Mobiltelefon und Smartphones.
Zweitens bleibt auch das ohnehin bekannte Problem der Kreditkartenzahlung bestehen, dass nämlich der Käufer seine Kreditkarteninformationen angibt und also alles von seiner Seite aus Notwendige für die Bezahlung veranlasst, ohne dass es zu einer Bestätigung seinerseits des zu zahlenden Betrags kommt. Hier muss der Käufer also auf die korrekte Abwicklung durch den Verkäufer vertrauen. Dies mag bei Kreditkarten oder anderen Vorgängen noch gerade akzeptabel sein, bei ähnlichen Zahlvorgängen wie etwa bei Debitkarten wäre es allerdings schon nicht mehr akzeptabel, von der Übertragung sensibler Daten ganz zu schweigen.
Die Aufgabe der Erfindung besteht also darin, ein aus dem Stand der Technik bekanntes Verfahren zur Autorisierung einer elektronischen Transaktion unter Einbezug eines Autorisierungsservers dahingehend zu verbessern, dass es auf Seiten des Initiators allein mit einem herkömmlichen mobilen elektronischen Gerät durchgeführt werden kann und dem Benutzer zusätzliche Transaktionssicherheit bietet.
Diese Aufgabe wird, bezogen auf ein Verfahren zur Autorisierung einer elektronischen Transaktion in einem Initiator-Endgerät durch die Merkmale des Anspruchs 1 und bezogen auf ein Computerprogramm durch die Merkmale des Anspruchs 8 gelöst.
Zu den hier gegenständlichen elektronischen Transaktionen zählen – neben den bereits in der Einleitung genannten Vorgängen – auch die Benutzung von Geldautomaten, Kassensystemen sowie Bonus- und Rabattsystemen. Ferner gehört zu den elektronischen Transaktionen in diesem Sinne sowohl das Ausleihen oder Anmieten von beliebigen Gegenständen wie etwa Fahrzeugen, Maschinen oder Medien als auch die Selbst-Identifikation oder das Ausweisen, etwa bezüglich einer Mitgliedschaft, einer Firmenmitgliedschaft oder bei der Einwahl in einen Hot-Spot sowie jeder andere, vergleichbare Vorgang.
Das der sendenden Partei entsprechende Endgerät wird dabei vorliegend und nachfolgend als Initiator-Endgerät bezeichnet, da es dadurch gekennzeichnet ist, dass es die betreffende elektronische Transaktion veranlasst und also initiiert. Das Endgerät, welchem gegenüber die elektronische Transaktion veranlasst werden soll, wird entsprechend nachfolgend als Ziel-Endgerät bezeichnet und die Genehmigungsstelle als Autorisierungsserver. Dabei ist jedwedes Endgerät nur im Kontext der jeweiligen elektronischen Transaktion Initiator-Endgerät oder Ziel-Endgerät. Nach Abschluss dieser speziellen elektronischen Transaktion oder sogar zeitgleich zu ihr kann eine weitere gleichartige elektronische Transaktion stattfinden, bei der die Rollen als Initiator-Endgerät und als Ziel-Endgerät genau vertauscht sind. Als Initiator- oder Ziel-Endgeräte kommen insbesondere Smartphones, Tablets, Personal Digital Assistants (PDAs), Pocket PCs und jedwede weitere vergleichbare Geräte in Frage. Insbesondere für das Ziel-Endgerät, welches in bestimmten Ausgestaltungen wesentlich ortsfest verwendet werden kann, kommt aber auch jedwedes andere stationäre elektronische Gerät wie ein Kassencomputer, ein Terminal, ein herkömmlicher Personalcomputer aber auch ein einfaches Scangerät in Betracht.
Die jeweils beschriebene Funktionalität auf dem Initiator- und dem Ziel-Endgerät kann dabei durch eine beliebige Hardware- oder Softwarekomponente oder eine zusammenwirkende Vielzahl dieser implementiert sein. Ebenso kann der Autorisierungsserver entweder durch einen dedizierten Computer bzw. die auf ihm ablaufende Software gebildet werden oder durch einen Softwareprozess verwirklicht sein, welcher auf einem Server abläuft, der noch weitere Serveraufgaben wahrnimmt. Sofern die Funktionalität des Autorisierungsservers durch mehrere Softwareprozesse verwirklicht wird, so können diese auch auf mehrere, physikalisch getrennte Recheneinheiten verteilt sein.
Wesentlich ist die Erkenntnis, dass bei einer solchen Autorisierung einer elektronischen Transaktion zwischen zwei Endgeräten mit Hilfe einer dritten Stelle – also dem Autorisierungsserver – sowohl die Sicherheit der Authentifizierung der beteiligten Endgeräte bzw. ihres jeweiligen Benutzers als auch die Richtigkeit der Transaktionsdaten, also etwa des zu zahlenden Betrages bei einem Kauf, schon dadurch gewährleistet werden kann, dass zwischen den Endgeräten zweimal eine Übertragung von dem Initiator-Endgerät zu dem Ziel-Endgerät erfolgt. Dabei ist es schon ausreichend, dass diese Übertragung unidirektional von dem Initiator-Endgerät zu dem Ziel-Endgerät erfolgt.
Bei diesem Vorgang identifiziert die erste Übertragung das Initiator-Endgerät und ggf. die Art der gewünschten Transaktion gegenüber dem Ziel-Endgerät. Das Ziel-Endgerät übermittelt dann die empfangene Identifikation des Initiator-Endgeräts zusammen mit eigenen, identitäts- oder transaktionsbezogenen Daten, etwa einem Zahlbetrag, an den Autorisierungsserver. Nach einer ggf. erfolgenden Prüfung sendet der Autorisierungsserver wiederum eine Bestätigungsanfrage an das mittels der Identifikation bestimmte Initiator-Endgerät. Transaktionsdaten wie etwa der genannte Zahlbetrag sowie Angaben zu Art und Identität des Ziel-Endgeräts, welche von dem Initiator-Endgerät oder dem Benutzer des Initiator-Endgeräts nach Prüfung zu bestätigen sind, werden zusammen mit dieser Bestätigungsanfrage übermittelt. Sobald der Autorisierungsserver eine positive Bestätigungsantwort von dem Initiator-Endgerät erhalten hat, sendet er einen jeweiligen Referenzcode zeitgleich sowohl an das Initiator- als auch an das Ziel-Endgerät.
Wenn das Initiator-Endgerät nun seinen Referenzcode an das Ziel-Endgerät im Rahmen der zweiten Übertragung vom Initiator-Endgerät zum Ziel-Endgerät gesendet und das Ziel-Endgerät die geeignete Korrelation oder Übereinstimmung zwischen den beiden Referenzcodes festgestellt hat, kann die Transaktion freigegeben und durchgeführt werden.
Ein solcher zweimaliger, nur einen unidirektionalen Informationsfluss erfordernder Kommunikationsvorgang ist einerseits technisch robust, also mit weitgehender Kompatibilität zwischen verschiedenen Endgeräten, zu verwirklichen, da eine häufig Inkompatibilitäten erzeugende Datenflusssteuerung, welche etwa durch einen „handshake” ausgehandelt werden müsste, vollständig entfallen kann.
Er ist andererseits auch für den Benutzer des Initiator-Endgeräts, also die sendende oder zahlende Partei, sehr komfortabel ist. Im einfachsten Fall wird das Initiator-Endgerät einfach nur in die Nähe des Ziel-Endgeräts gebracht. Darüber hinaus wird dem Benutzer des Initiator-Endgeräts auch eine bessere Kontrolle über die weiteren Parameter der Transaktion, so etwa über den Zahlbetrag, geboten und es ist gewährleistet, dass eine sehr sichere Authentifizierung des Benutzers des Initiator-Endgeräts ohne das Risiko eines „Hackens” möglich ist.
Die bevorzugten Ausgestaltungen gemäß der Unteransprüche 2 und 3 stellen eine besonders elegante Art der unidirektionalen Kommunikation von dem Initiator-Endgerät zu dem Ziel-Endgerät vor, nämlich zweidimensional codiert über einen optischen Übertragungsweg. Diese Art der Übertragung gewährleistet eine besonders gute Kompatibilität mit einer Vielzahl unterschiedlicher Hardware und über einen langen Einsatzzeitraum, da bei Aktualisierungen oder Erweiterungen bei optischen Codes eher von einer Rückwärtskompatibilität auszugehen ist als etwa bei drahtlosen Funkprotokollen. Folglich werden ältere Geräte nicht so schnell oder gar nicht obsolet.
Zudem lässt sich die Kommunikation auf einfache und ersichtliche Art und Weise herstellen und wieder abbauen, nämlich einfach indem die jeweiligen Endgeräte zueinander ausgerichtet und dann wieder getrennt werden.
Die bevorzugten Ausgestaltungen der Ansprüche 4 und 5 wiederum verbessern die Sicherheit der Kommunikation zwischen den Endgeräten und dem Autorisierungsserver. Sie ermöglichen die dynamische Bestimmung verschiedener Kommunikationsparameter, wodurch ein Mittelsmannangriff in der Kommunikation zwischen dem Autorisierungsserver und den Endgeräten deutlich erschwert wird.
Auch die bevorzugten Ausgestaltungen der Ansprüche 6 und 7 erhöhen durch die Verwendung digitaler Signaturen die Sicherheit, indem nämlich die Identität der an der elektronischen Transaktion beteiligten Benutzer oder Endgeräte korrekt festgestellt werden kann.
In der lediglich Ausführungsbeispiele wiedergebenden Zeichnung zeigt
1 die Konstellation der Endgeräte, des Autorisierungsservers und der dazugehörigen Infrastruktur für die vorschlagsgemäßen Verfahren und
2 ein paralleles Ablaufdiagramm für die vorschlagsgemäßen Verfahren in dem Initiator-Endgerät, dem Ziel-Endgerät sowie dem Autorisierungsserver.
In der 1 sind ein Ziel-Endgerät 1, in diesem Falle ein stationärer Kassencomputer 1a, ein Autorisierungsserver 2, welcher vorliegend in einem Rechenzentrum aufgestellt ist, sowie ein Initiator-Endgerät 3, hier ein Smartphone 3a, zu erkennen. Das Ziel-Endgerät 1 unterhält eine Verbindung zum Internet 4, vorliegend und beispielhaft mittels einer drahtgebundenen Kommunikationsverbindung, nämlich einer Ethernet-Anbindung 5. Das Ziel-Endgerät 1 kann auch aus einer Reihe von physikalisch in verschiedenen Gehäusen angeordneten Einzelteilen bestehen, welche aber eine funktionale Einheit bilden. So kann der beispielhafte Kassencomputer 1a mehrere Sensoren zum Datenempfang umfassen, welche entweder per Kabel oder sogar nur per Funk mit dem Hauptgehäuse des Kassencomputers 1a in Verbindung stehen.
Auch der Autorisierungsserver 2 ist mit dem Internet 4 verbunden, und zwar hier beispielhaft über eine Standleitung 6.
Das Initiator-Endgerät 3 kann eine drahtlose Verbindung mit dem Internet 4 herstellen und zwar wahlweise über ein WLAN (Wireless Local Area Network) 7 oder über eine Mobilfunkverbindung 8, welches etwa auf GSM (Global System for Mobile Communications), GPRS (General Packet Radio Service), UMTS (Universal Mobile Telecommunications System), DECT (Digital Enhanced Cordless Telecommunications), LTE (Long Term Evolution) oder einem anderen vergleichbaren Protokoll basiert.
In der hier beispielhaften Situation möchte der Benutzer des Initiator-Endgeräts 3, also des Smartphones 3a, in einem Supermarkt eine Reihe von Waren an der Kasse des Supermarkts, entsprechend dem Kassencomputer 1a, in einer elektronischen Transaktion bezahlen, wobei die Autorisierung der elektronischen Transaktion gemäß dem vorschlagsgemäßen Verfahren durchgeführt wird.
Für diese angestrebte elektronische Bezahlung und im Kontext des vorliegenden Beispiels kann dabei der Benutzer des Initiator-Endgeräts 3 aus einer Vielzahl von Zahlungsweisen und zugeordneten Konten auswählen, welche ihm zur Verfügung stehen. Als unterschiedliche Zahlungsweisen in diesem Sinne kommen dabei die Zahlung per Kreditkarte, per Bankkonto, per Wertkarte, per Online-Bezahldienst wie etwa PayPal, per Lastschrift, über ein laufendes Kundenkonto oder eine beliebige andere Zahlungsweise in Betracht.
Bei dem Initiator-Endgerät 3 können jeder natürlichen Person, die als Benutzer des Initiator-Endgeräts 3 vorgesehen ist, ein oder mehrere Benutzerkonten eingerichtet und zugewiesen sein. Unterschiedliche Benutzerkonten derselben natürlichen Person können dann jeweils für Transaktionen im privaten Bereich, im gewerblichen Bereich oder z. B. im Vereinsbereich vorgesehen sein. Ein Benutzer des Initiator-Endgeräts 3, welcher etwa als Gewerbetreibender selbständig ist und gleichzeitig Vereinsvorstand ist, könnte so drei zugeordnete Benutzerkonten auf dem Initiator-Endgerät 3 haben. Bevorzugt ist dabei auf dem Initiator-Endgerät 3 für jedes solche Benutzerkonto eine entsprechende Auswahlliste von Zahlungsweisen und Konten abgespeichert. Je nachdem, in welches Benutzerkonto er aktuell eingebucht ist, steht eine andere Auswahlliste von Zahlungsweisen und Konten zur Verfügung, nämlich erstens eine solche mit Privatkonten, zweitens eine mit Konten des Gewerbebetriebs und drittens eine mit Konten des Vereins. Alternativ können diese drei Auswahllisten auch demselben Benutzerkonto zugewiesen sein oder zu einer einzelnen Auswahlliste zusammengeführt sein.
Insbesondere kann der Benutzer des Initiator-Endgeräts 3 eine entsprechende, ggf. von dem Benutzerkonto abhängige, Vorauswahl über die bevorzugte Zahlungsweise und das zugeordnete Konto getroffen haben, welche dann im Initiator-Endgerät 3 als Grundeinstellung eingespeichert wird. Diese Vorauswahl kann dann aber auch jederzeit von dem Benutzer des Initiator-Endgeräts 3 durch eine nachträglich vorgenommene Auswahl außer Kraft gesetzt werden. Die umfassende Verwaltung aller möglichen Zahlungsweisen und zugehörigen Konten in dem Initiator-Endgerät 3 erlaubt es dem Benutzer des Initiator-Endgeräts 3, sich stets einen aktuellen Überblick über die Zahlungsbelastungen aller Konten, auf die der Benutzer des Initiator-Endgeräts 3 Zugriff hat, zu verschaffen.
Zurückkehrend zum eigentlichen Verfahren sei vorab ausdrücklich festgestellt, dass im Rahmen des nachfolgenden vorschlagsgemäßen Verfahrens neben den ausdrücklich beschriebenen Verfahrensschritten ebenso weitere Verfahrensschritte vor, nach oder zwischen den vorschlagsgemäßen Verfahrensschritten vorgesehen sein können.
In einer ersten Variante der Ausgangssituation sind die zu bezahlenden Waren von dem Ziel-Endgerät 1 bereits vor Beginn des vorschlagsgemäßen Verfahrens erfasst, etwa durch eine herkömmliche Barcode-Erfassung oder aber mittels Identifikation durch RFID (radio-frequency identification), so dass die Bezeichnungen, Menge und Preisinformationen der zu bezahlenden Waren am Ziel-Endgerät 1 vorliegen.
Ein Verfahren zur Autorisierung einer elektronischen Transaktion in einem Ziel-Endgerät 1 zeichnet sich dadurch aus, dass mindestens die nachfolgend beschriebenen Verfahrensschritte durchlaufen werden. Diese sind, neben weiteren, bevorzugten Verfahrensschritten, in der 2 für den mittleren Ablaufstrang dargestellt ist, welcher dem Ziel-Endgerät 1 zugeordnet ist.
Ein erster Verfahrensschritt umfasst das Empfangen 9 einer von dem Initiator-Endgerät 3 gesendeten Initiatorinformation. Diese Initiatorinformation erlaubt die Identifizierung des Initiator-Endgeräts 3. Sie kann darüber hinaus auch weitere transaktionsbezogene Daten enthalten. Wenn es sich bei der Transaktion etwa um einen Wahlvorgang handelt, dann kann die Initiatorinformation auch die von dem Benutzer des Initiator-Endgeräts 3 getroffene Auswahl für den Wahlvorgang enthalten. Bei dem hier beispielhaften Bezahlvorgang kann die Initiator-Information auch bereits eine Angabe der Zahlungsweise gemäß der bereits genannten Beispiele und des zugeordneten Kontos enthalten. Bei dieser Angabe kann es sich sowohl um eine Grundeinstellung wie oben beschrieben als auch um eine von dem Benutzer des Initiator-Endgeräts 3 bewusst für diese elektronische Transaktion vorgenommene Auswahl einer Zahlungsweise und eines entsprechenden Kontos handeln.
Bevorzugt wird die Initiatorinformation dabei in einer unidirektionalen Übertragung gesendet, was bedeutet, dass bei dieser Übertragung ausschließlich Daten an das Initiator-Endgerät 3 übertragen werden und keinerlei Daten von dem Initiator-Endgerät 3 ausgehen. Das Empfangen eines UKW-Radiosignals stellt ein Beispiel für eine solche unidirektionale Übertragung dar.
Alternativ zu der ersten Variante der Ausgangssituation kann ein Erfassen der zu bezahlenden Waren durch das Ziel-Endgerät 1 auch erst nach dem Schritt des Empfangens 9 erfolgen. So wäre denkbar, dass der Benutzer sich an der Kasse des Geschäfts und also am Kassencomputer 1a identifiziert, was durch den soeben beschriebenen Schritt des Empfangens 9 geschieht, bevor die Waren von dem Kassencomputer 1a erfasst wurden. In der Praxis könnte das Empfangen 9 also erfolgen, bevor die Waren aus einem Einkaufswagen auf ein entsprechendes Förderband beim Kassencomputer 1a gelegt werden, so etwa am Beginn des Förderbandes und also am entgegengesetzten Ende zum Kassencomputer 1a.
Ein weiterer Verfahrensschritt umfasst das Senden 10 einer Transaktionsnachricht, welche die Initiatorinformation sowie eine Zielinformation umfasst, an den Autorisierungsserver 2. Analog zu der Initiatorinformation erlaubt die Zielinformation die Identifikation des Ziel-Endgeräts 1. Daneben kann die Zielinformation aber auch weitere transaktionsbezogene Informationen enthalten. Bei dem hier beispielhaft beschriebenen Kaufvorgang umfasst dies etwa Bezeichnung und Anzahl der zu kaufenden Waren, des jeweiligen Einzelpreises sowie der sich daraus ergebende Gesamtpreis.
Dabei ist die Adresse des Autorisierungsservers 2 seitens des Ziel-Endgeräts 1 entweder schon vorbekannt oder wird von einer dritten Partei bezogen, etwa von einem DNS(Domain Name System)-Server. Unter Adresse und Adressierung wird hier und nachfolgend stets eine logische Adresse oder Adressierung innerhalb eines Kommunikationsnetzwerks verstanden, beispielsweise also eine IP(Internet Protocol)-Adresse.
Die Transaktionsnachricht kann dabei sowohl als einzelne Nachricht oder einzelnes Datenpaket als auch in Gestalt mehrerer einzelner Nachrichten oder Datenpakete an den Autorisierungsserver 2 gesendet werden. Das Senden 10 kann über einen beliebigen Kanal unter Verwendung eines beliebigen Protokolls erfolgen, bei dem vorliegenden Beispiel also über die Ethernet-Anbindung 5 und von da weiter über das Internet 4. Dabei wird hier beispielhaft TCP(Transmission Control Protocol)/IP verwendet.
Ein weiterer Verfahrensschritt sieht das Empfangen 11 eines von dem Autorisierungsserver 2 gesendeten Ziel-Referenzcodes vor. Dieser Ziel-Referenzcode kann dabei auf eine Art und Weise codiert sein, dass er von dem Ziel-Endgerät 1 nicht entziffer- oder interpretierbar ist und also keine semantische Bedeutung hat.
Es wird als weiterer Verfahrensschritt ein von dem Initiator-Endgerät 3 gesendeter Initiator-Referenzcode empfangen 12. Auch der Initiator-Referenzcode kann wie für den Ziel-Referenzcode beschrieben codiert sein. Bevorzugt wird der Initiator-Referenzcode dabei in einer unidirektionalen Übertragung gesendet. Eine solche unidirektionale Übertragung ist hier und nachfolgend wie obenstehend definiert.
In einer bevorzugten Ausgestaltung dieses Verfahrens ist als weiterer Verfahrensschritt das Entscheiden 13 einer Freigabe der elektronischen Transaktion basierend auf einer Korrelation des Ziel-Referenzcodes mit dem Initiator-Referenzcode vorgesehen. Unter einer Korrelation ist jedwede Verarbeitung des Ziel-Referenzcodes und des Initiator-Referenzcode zu verstehen, deren Ergebnis eine Grundlage für das Entscheiden 13 bilden kann. So kann etwa nach einer gemeinsamen Vorschrift eine Prüfziffer jeweils aus dem Ziel-Referenzcode und dem Initiator-Referenzcode gebildet werden und dann ein Vergleich der beiden Prüfziffern vorgenommen werden. Alternativ können der Ziel-Referenzcode und der Initiator-Referenzcode als Argumente einer beliebigen Funktion dienen, deren Funktionswert dann die Grundlage für das Entscheiden 13 bildet. Ganz allgemein geht es hier darum zu prüfen, ob der von dem Autorisierungsserver 2 beim Empfangen 11 direkt erhaltene Ziel-Referenzcode zu dem von dem Initiator-Endgerät 3 beim Empfangen 12 erhaltenen Initiator-Referenzcode passt. Dieses Entscheiden 13 kann insbesondere durch einen Software-Programmablauf und damit automatisch ohne Eingabe eines Benutzers erfolgen.
Besonders bevorzugt ist, dass das Entscheiden 13 der Freigabe der elektronischen Transaktion auf einem Vergleich des Ziel-Referenzcodes mit dem Initiator-Referenzcodes basiert. Dieser Vergleich kann eine Überprüfung der Identität der beiden Referenzcodes oder aber eine Überprüfung auf eine wie auch immer definierte Ähnlichkeit der beiden Referenzcodes bedeuten, z. B. eine Überprüfung auf eine Komplementarität der beiden Referenzcodes.
Falls die Freigabe also bejaht werden kann, bedeutet dies, dass der Autorisierungsserver 2 sowohl die elektronische Transaktion als solche erlaubt – was voraussetzt, dass etwa das durch seine Initiatorinformation identifizierte Initiator-Endgerät 3 bzw. dessen Benutzer noch eine den Kaufpreis deckende Summe auf einem Guthaben aufweist oder zumindest eine entsprechende Kreditlinie innehat – als auch, dass das Initiator-Endgerät 3 genau dasjenige Endgerät ist, als das es sich ausgibt. Wäre dem nicht so, hätte es nicht von dem Autorisierungsserver 2 auf Grundlage seiner in dem Autorisierungsserver 2 hinterlegten Daten mit dem passenden Initiator-Referenzcode versorgt werden können. Voraussetzung für eine positiven Korrelation bzw. einen positiven Vergleich des Ziel-Referenzcodes zu dem Initiator-Referenzcode ist also, dass eine lückenlose Identifikationskette der an der elektronischen Transaktion beteiligten Endgeräte gebildet werden kann.
Das Ergebnis dieses Entscheidens 13 ist entweder eine Bestätigung oder eine Ablehnung der Freigabe. Dabei kann die Entscheidungsvorschrift, also wie genau basierend auf der Korrelation entschieden wird, grundsätzlich frei gewählt werden.
Der Bestätigung der Freigabe entspricht, dass die elektronische Transaktion planmäßig fortgesetzt und durchgeführt wird, beispielhaft also der Kauf abgeschlossen und die entsprechende Zahlung getätigt wird. Im Gegenzug führt das Ablehnen der Freigabe zu einem Abbruch der elektronischen Transaktion. Es würde also bei einem solchen Abbruch weder ein Kauf noch eine Zahlung erfolgen.
Der der Freigabe entsprechende Vorgang, also die elektronische Transaktion selbst, kann dabei entweder innerhalb des Ziel-Endgeräts 1 selbst, in dem Autorisierungsserver 2 oder an einer beliebigen anderen Stelle erfolgen, so etwa in eifern Bank-Server 14. Sofern die elektronische Transaktion also nicht in dem Ziel-Endgerät 1 vollzogen wird, kann zur Veranlassung der elektronischen Transaktion eine Kommunikationsverbindung mit der entsprechenden Stelle durch das Ziel-Endgerät 1 hergestellt werden.
Ferner kann in einem weiteren, vorzugsweise ausgeführten Verfahrensschritt ein Senden 15 einer Abschlussnachricht darüber, wie die Freigabe entschieden wurde, an den Autorisierungsserver 2 erfolgen.
Bevorzugt ist ferner vorgesehen, dass, wenn innerhalb einer vorbestimmten Wartezeit ab Empfangen 11 des Ziel-Referenzcodes die Freigabe nicht bestätigt wurde, die Freigabe abgelehnt wird. Mit anderen Worten hat der Benutzer des Initiator-Endgeräts 3 nur eine begrenzte Zeit für das untenstehend näher beschriebene Senden 29 des – richtigen – Initiator-Referenzcodes an das Ziel-Endgerät 1 bevor es zu einem Abbruch der elektronischen Transaktion kommt. Das Vorsehen derartiger Zeitfenster erhöht die Sicherheit des Autorisierungsvorgangs weiter.
Nachfolgend werden die in dem Autorisierungsserver 2 ablaufenden Verfahrensschritte beschrieben. Diese sind in der 2 in dem rechten Ablaufstrang dargestellt. Es werden dabei mindestens die folgenden Verfahrensschritte durchlaufen:
Ein Verfahrensschritt umfasst das Empfangen 16 der von dem Ziel-Endgerät 1 gesendeten Transaktionsnachricht, welche die Initiatorinformation sowie die Zielinformation umfasst und bereits obenstehend erwähnt wurde.
Bevorzugt erfolgt ein Überprüfen 17 der Transaktionsnachricht auf grundlegende Plausibilität. Wenn also entweder die Initiatorinformation oder die Zielinformation keinem dem Autorisierungsserver 2 bekannten Initiator-Endgerät 3 oder Ziel-Endgerät 1 zugeordnet werden kann, dann wird bereits an dieser Stelle abgebrochen. Falls die Initiator-Information, wie bereits beschrieben, eine Angabe der Zahlungsweise und des entsprechenden Kontos enthält, dann kann das Überprüfen 17 auch eine grundsätzliche Zulässigkeitsprüfung dieser Angaben umfassen, ob also etwa ein solches Konto überhaupt existiert, ob es dem Benutzer des Initiator-Endgeräts 3 zugeordnet ist, ob es für die gewünschte Zahlungsweise freigegeben ist und ob keine Sperrung o. dgl. vorliegt.
Ein weiterer Verfahrensschritt sieht das Senden 18 einer Bestätigungsanfrage an das Initiator-Endgerät 3 vor. Diese Bestätigungsanfrage enthält grundlegende Informationen zu der elektronischen Transaktion und soll dem Benutzer des Initiator-Endgeräts 3 die Möglichkeit geben, die elektronische Transaktion mit den zugehörigen Parameter zu bestätigen oder ggf. abzulehnen. Bevorzugt enthält die Bestätigungsanfrage auch die Ziel-Information oder jedenfalls eine auf der Ziel-Information basierende Identifikation des Ziel-Endgeräts 3 oder des Benutzers des Ziel-Endgeräts 3, welcher ja den Empfänger der elektronischen Transaktion darstellt.
Im beispielhaften Falle eines Supermarkteinkaufs könnten zu diesen Informationen der Bestätigungsanfrage weiter etwa Bezeichnung und Anzahl der zu kaufenden Waren, ihre Preise sowie der Gesamtreis zählen. Als Ziel-Information kann Adresse und Firma des Zahlungsempfängers vorgesehen sein. Dieses Senden 18 erfolgt bevorzugt verschlüsselt und/oder über eine gesicherte Verbindung. Die Adressierung des Initiator-Endgeräts 3 basiert darauf, dass das Initiator-Endgerät 3 mit Hilfe der Initiatorinformation aus der vormals empfangenen Transaktionsnachricht durch den Autorisierungsserver identifiziert werden kann.
Auf Grundlage dieser Initiatorinformation ermittelt der Autorisierungsserver 2 die für dieses Initiator-Endgerät 3 hinterlegte Adresse aus seiner Datenbank und sendet die Bestätigungsanfrage an diese Adresse. Damit ist sichergestellt, dass die Adressierung nicht aufgrund einer womöglich gefälschten Initiatorinformation in der Transaktionsnachricht erfolgt.
Ein weiterer Verfahrensschritt sieht das Empfangen 19 einer von dem Initiator-Endgerät 3 gesendeten Bestätigungsantwort vor. Diese Bestätigungsantwort ist als positiv zu bezeichnen, wenn mit ihr bestätigt wird, dass die elektronische Transaktion weitergeführt werden soll. Diese Bestätigungsantwort kann dem Autorisierungsserver 2 erstmalig die gewünschte Zahlungsweise und das entsprechende Konto mitteilen, falls diese Angaben nicht bereits mit der Initiator-Information wie oben beschrieben übermittelt wurden. Es ist aber auch möglich, dass die von dem Initiator-Endgerät 3 gesendete Bestätigungsantwort eine Angabe einer Zahlungsweise und eines Kontos enthält, mit der die mit der Initiator-Information übermittelten Angaben abgeändert werden sollen. Dies kann etwa dann geschehen, wenn der Benutzer des Initiator-Endgeräts 3 wegen des mit der Bestätigungsanfrage übermittelten Gesamtkaufpreises ein anderes Konto bei der elektronischen Transaktion belasten möchte, als ursprünglich beabsichtigt oder voreingestellt war. Durch die Möglichkeit einer Änderung an dieser Stelle des Verfahrens muss das Verfahren nicht wieder neu aufgesetzt werden.
Wenn hingegen die Bestätigungsantwort negativ ausfällt, das Initiator-Endgerät 3 bzw. der Benutzer des Initiator-Endgeräts 3 die in der Bestätigungsanfrage beschriebene elektronische Transaktion also ablehnt, oder aber nicht innerhalb eines vorgegebenen Bestätigungszeitfensters die Bestätigungsantwort durch den Autorisierungsserver 2 empfangen wird, dann findet ein Abbrechen 20 der elektronischen Transaktion durch den Autorisierungsserver 2 statt. Ein solches Abbrechen 20 der elektronischen Transaktion durch den Autorisierungsserver 20 findet auch dann statt, wenn die Bestätigungsantwort Informationen enthält, welche einer etwaigen weiteren Prüfung durch den Autorisierungsserver 2 nicht genügen, worauf nachfolgend noch näher eingegangen wird.
Insbesondere beim rechtzeitigen Erhalt der positiven Bestätigungsantwort folgen dann hingegen zwei weitere Verfahrensschritte: das Senden 21 des bereits erwähnten Ziel-Referenzcodes an das Ziel-Endgerät 1 sowie das Senden 22 des ebenfalls bereits beschriebenen Initiator-Referenzcodes an das Initiator-Endgerät 3. Aus Sicht des Autorisierungsservers 2 wurde die elektronische Transaktion grundsätzlich freigegeben, nun soll nur noch der Abgleich der beiden Referenzcodes stattfinden, um die sichere Zuordnung der elektronischen Transaktion zu den beteiligten physikalischen Endgeräten zu gewährleisten. Vorzugsweise werden sowohl der Ziel-Referenzcode als auch der Initiator-Referenzcode vom Autorisierungsserver 2 dynamisch nach einer vorbestimmten, aber bevorzugt geheim gehaltenen Vorschrift erzeugt. Dabei können von dem Autorisierungsserver 2 entweder in der Transaktionsnachricht und/oder in der Bestätigungsantwort erhaltene Informationen oder andere Parameter einfließen. Jedenfalls ist jedes gesendete Paar von Ziel-Referenzcode und Initiator-Referenzcode bevorzugt einmalig und wird – jedenfalls während einer gewissen Sperrzeit – von demselben Autorisierungsserver 2 nicht wiederverwendet.
Um die Sicherheit der Transaktion weiter zu erhöhen, kann das Senden 21 des Ziel-Referenzcodes an das Ziel-Endgerät 1 und das Senden 22 des Initiator-Referenzcodes an das Initiator-Endgerät 3 zeitlich überlappend, also parallel, und insbesondere gleichzeitig erfolgen. Eine zeitliche Überlappung bedeutet hier, dass einer der beiden Schritte des Sendens 21, 22 beginnt bevor der jeweils andere abgeschlossen ist. Gleichzeitigkeit in diesem Sinne ist wiederum etwa dann gegeben, wenn beide Sende-Vorgänge 21, 22 mit dem gleichen Zeitstempel versehen sind.
Bevorzugt beruht auch das Senden 21 des Ziel-Referenzcodes an das Ziel-Endgerät 1 auf einer Adressermittlung des Ziel-Endgeräts 1 gemäß einer Hinterlegung in einer Datenbank des Autorisierungsservers 2. Die Identifikation des Ziel-Endgeräts 1 kann dabei auf Grundlage der mit der Transaktionsnachricht übermittelten Zielinformation erfolgen. Diese Vorgehensweise ist sicherer, als einfach den Ziel-Referenzcode an den protokolltechnischen Absender der Transaktionsnachricht zu senden. Gleiches gilt entsprechend auch für das Senden 22 des Initiator-Referenzcodes an das Initiator-Endgerät 3.
Es handelt sich hier nämlich um zwei durchaus unterschiedliche Arten der Identifikation: In einem Fall wird schlicht der Absender gemäß Übertragungsprotokoll als Empfänger vorgesehen, wie es etwa beim Antworten auf eine E-Mail oder, auf einer niedrigeren Protokollebene, durch Verwendung einer bereits hergestellten Socket-Verbindung möglich ist. Im anderen Fall wird auf eine Identifikation im Inhalt oder in der Nutzlast der Transaktionsnachricht abgestellt, welche Identifikation möglicherweise sogar verschlüsselt ist und basierend auf dieser Identifikation eine unabhängige Adressierung vorgenommen, was ggf. zu der Herstellung einer neuen, unabhängigen Verbindung führen kann.
Schließlich umfasst ein optionaler Verfahrensschritt das Empfangen 23 der bereits beschriebenen Abschlussnachricht, welche von dem Ziel-Endgerät 1 im Verfahrensschritt des Sendens 15 gesendet wurde.
Mit Bezug auf den linken Ablaufstrang der 2 werden nun nachfolgend die vorschlagsgemäßen Verfahrensschritte zur Autorisierung einer Transaktion in dem Initiator-Endgerät 3 beschrieben. Dabei werden mindestens die folgenden Verfahrensschritte durchlaufen:
Ein vorschlagsgemäßer Verfahrensschritt umfasst das Senden 24 einer Initiatorinformation an das Ziel-Endgerät 1, welche Initiatorinformation bereits obenstehend charakterisiert wurde. Vorzugsweise erfolgt dies in einer unidirektionalen Übertragung. Dieses Senden 24 kann durch eine manuelle Betätigung des Benutzers des Initiator-Endgeräts 3 oder durch eine Bewegung des Initiator-Endgeräts 3 in die Nähe oder in einen entsprechenden Erfassungsbereich des Ziel-Endgeräts 1 erfolgen.
In dem beschriebenen Fall eines Supermarkteinkaufs kann, wie bereits beschrieben, dieses Senden 24 auch schon beim Erreichen des Kassenbereichs erfolgen, also noch bevor die zu kaufenden Waren erfasst wurden. Denn die Initiatorinformation dient nur zur Identifikation des Initiators der elektronischen Transaktion und enthält bevorzugt noch keine Informationen zu dem – meist variablen – Inhalt der spezifischen elektronischen Transaktion. Abweichungen hiervon können in der bereits genannten Angabe der bevorzugten Zahlungsweise und des entsprechenden Kontos bestehen, entsprechend einer Grundeinstellung oder einer bereits zu diesem Zeitpunkt im Verfahren von dem Benutzer des Initiator-Endgeräts 3 getroffenen Auswahl.
Ein weiterer vorschlagsgemäßer Verfahrensschritt sieht das Empfangen 25 der von dem Autorisierungsserver 2 gesendeten Bestätigungsanfrage vor. Diese Bestätigungsanfrage beinhaltet, wie ebenfalls bereits beschrieben, die wesentlichen Punkte und also Parameter der von dem Initiator-Endgerät 3 durch das Senden 24 begonnenen elektronischen Transaktion, welche somit gleichsam zur Bestätigung dem Benutzer des Initiator-Endgeräts 3 wieder vorgelegt werden können.
Grundsätzlich kann diese Bestätigungsanfrage in dem Initiator-Endgerät 3 automatisch, also etwa durch ein Softwareprogramm überprüft und weiterverarbeitet werden, so dass im Prinzip keine Benutzereingabe notwendig ist.
Bevorzugt ist jedoch, dass in einem weiteren Schritt ein Entscheiden 26 durch den Benutzer darüber stattfindet, ob die mit der Bestätigungsanfrage gesendeten grundlegenden Informationen zur elektronischen Transaktion und die zu ihr gehörenden Parameter so bestätigt werden können. Speziell im vorliegenden Fall geht es also darum, ob der Käufer – also der Benutzer des Initiator-Endgeräts 3 – mit der durch die Bestätigungsanfrage übermittelten Liste der gekauften Waren mit ihren jeweiligen Preisen und der Gesamtsumme sowie mit der Identität des Ziel-Endgeräts 1 bzw. dem Benutzer des Ziel-Endgeräts 1 oder des dem Ziel-Endgerät 1 zugeordneten Unternehmens und also der Identität des Zahlungsempfängers einverstanden ist.
Vorschlagsgemäß ist dann das Senden 27 der Bestätigungsantwort an den Autorisierungsserver 2 vorgesehen. Wenn der Benutzer des Initiator-Endgeräts 3 mit der Transaktion gemäß den in der Bestätigungsanfrage mitgeteilten Parameter einverstanden ist, wird eine positive Bestätigungsantwort versandt, andernfalls eine negative Bestätigungsantwort. Die negative Bestätigungsantwort führt zum Abbruch der Transaktion. Sofern eine Angabe der bevorzugten Zahlungsweise und des entsprechenden Kontos nicht bereits mit der Initiator-Information übermittelt wurde, so wird eine solche Angabe vorzugweise mit der positiven Bestätigungsantwort an den Autorisierungsserver 2 gesandt hat. Aber auch wenn dies bereits mit der Initiator-Information geschah kann – wie bereits beschrieben – mit der Bestätigungsantwort eine abweichende entsprechende Angabe übermittelt werden, welche gegenüber der vorherigen Initiator-Information maßgeblich ist.
Im Falle einer positiven Bestätigungsantwort ist vorschlagsgemäß dann das Empfangen 28 des von dem Autorisierungsserver 2 gesendeten Initiator-Referenzcodes vorgesehen, worauf dann ebenfalls vorschlagsgemäß das Senden 29 dieses Initiator-Referenzcodes an den Ziel-Client 1 vorgesehen ist. Bevorzugt erfolgt dies auch in einer unidirektionalen Übertragung.
Dieses Senden 29 kann auf dieselbe Art und Weise erfolgen wie das bereits beschriebene Senden 24 der Initiatorinformation, also durch eine manuelle Betätigung des Benutzers des Initiator-Endgeräts 3 oder durch eine Bewegung des Initiator-Endgeräts 3 in die Nähe oder in einen entsprechenden Erfassungsbereich des Ziel-Endgeräts 1. Auf diese Weise findet eine Verifizierung gegenüber dem Ziel-Endgerät 1 dahingehend statt, dass es sich bei dem Initiator-Endgerät 3 um dasjenige Endgerät handelt, für das von dem Autorisierungsserver 2 die gerade gegenständliche elektronische Transaktion mit positivem Ergebnis geprüft wurde und welches dann – entweder selbst oder seinen Benutzer – die elektronische Transaktion mit ihren Parametern bestätigt hat.
Das vorschlagsgemäße Verfahren lässt sich ebenso auch für die Bezahlung bei einem Online-Einkauf in einem Online-Shop verwenden. In diesem Fall ist beispielhaft als Initiator-Endgerät 3 wieder ein Smartphone 3a vorgesehen und als Ziel-Endgerät 1 ebenso beispielhaft entweder ein Personalcomputer mit einem integrierten oder angeschlossenen Sensor oder aber ein eigenes Lesegerät mit einer entsprechenden Logik, welche zur Kommunikation mit dem Personalcomputer per Kabel oder auch drahtlos verbunden sein kann. Die beschriebenen Verfahrensschritte laufen ebenso wie bereits beschrieben ab. Statt einer Erfassung von körperlichen Waren entweder auf einem Band oder in einem Einkaufswagen, wie es in einem Supermarkt üblich wäre, findet ein herkömmlicher Online-Einkauf in dem Online-Shop durch den Benutzer des Initiator-Endgeräts 3 statt, wobei die vorschlagsgemäßen Schritte in entsprechender Weise im Verhältnis zu den Einzelschritten des Online-Einkaufs stattfinden. Hieraus ist ersichtlich, dass das Ziel-Endgerät 1 sich nicht notwendigerweise in räumlicher Nähe zu dem Transaktionsempfänger – hier also dem Online-Shop bzw. dessen Betreiber – befinden muss, sondern räumlich unabhängig von diesem angeordnet sein kann. Ohnehin kann bei bestimmten Zahlungsempfängern wie etwa einem solchen Online-Shop eine räumliche Verortung nicht sinnvoll oder überhaupt möglich sein.
Dies beeinträchtigt aber nicht, wie gezeigt wurde, die Anwendbarkeit des vorschlagsgemäßen Verfahrens.
Ferner kann auch ein und dasselbe Ziel-Endgerät 1, etwa ein spezielles Lesegerät, als Ziel-Endgerät 1 für die Durchführung des vorschlagsgemäßen Verfahrens für eine ganze Reihe von unterschiedlichen Online-Shops und ähnlichen Transaktionsempfängern vorgesehen sein.
Besondere Vorteile ergeben sich, wenn der Initiator-Referenzcode identisch zu dem Ziel-Referenzcode ist. Auf diese Weise kann die Kenntnis über die spezielle Codierung und Erzeugungsweise der beiden Referenzcodes innerhalb des Autorisierungsservers 2 verbleiben, die Referenzcodes bleiben dabei intransparent und sind folglich schwerer zu knacken. Seitens des Ziel-Endgeräts 1 wiederum müssen dann – etwa während des Verfahrensschrittes des Entscheidens 13 – der Initiator-Referenzcode und der Ziel-Referenzcode nur noch auf ihre Identität überprüft werden, ohne dass es einer weitergehenden Analyse bedürfen würde. Denn eine solche Prüfung auf Gleichheit setzt kein Verständnis der Bedeutung oder Erzeugungsweise der Referenzcodes voraus.
Auch bei der geforderten Identität zwischen Initiator-Referenzcode und Ziel-Referenzcode ist es aber nichtsdestotrotz möglich, dass etwa in der entsprechenden Verarbeitungssoftware des Ziel-Endgeräts 1 eine Analyse des empfangenen Referenzcodes dahingehend stattfindet, ob darin etwaig codierte Information sich mit den bekannten Parameter der elektronischen Transaktion decken. Diese Analyse kann in der Art einer Black-Box, etwa durch eine geschlossene und proprietäre Software erfolgen, so dass der Benutzer des Ziel-Endgeräts 1 oder andere Programme auf dem Ziel-Endgerät 1 nur über das Ergebnis und nicht über den Hergang der Analyse in Kenntnis gesetzt werden. Bei Unstimmigkeiten in der Analyse kann ein Abbruch der elektronischen Transaktion eine Folge der Analyse sein.
Jedenfalls kann bei der Ausführungsform, bei der der Initiator-Referenzcode identisch zu dem Ziel-Referenzcode ist bzw. sein soll, das Entscheiden 13 der Freigabe einfach dergestalt erfolgen, dass die Freigabe dann und nur dann bestätigt wird, wenn der empfangene Ziel-Referenzcode zu dem empfangenen Initiator-Referenzcode tatsächlich identisch ist.
Vorteile ergeben sich weiter, wenn die Initiatorinformation auf einem Kurzstreckenübertragungsweg von dem Initiator-Endgerät 3 an das Ziel-Endgerät 1 gesendet wird. Unter einem solchen Kurzstreckungsübertragungsweg ist jedwede drahtlose oder drahtgebundene Nahbereichskommunikation zu verstehen. Dazu zählen etwa NFC (Near Field Communication), RFID, eine Übertragung per Infrarot-Schnittstelle oder gar eine Übertragung über eine lösbare Kabelverbindung. Ein solcher Kurzstreckenübertragungsweg zeichnet sich dadurch aus, dass er von dem Benutzer des Initiator-Endgeräts 3 durch eine entsprechende Positionierung oder Handhabung hergestellt und auch wieder gelöst werden kann. Im Gegensatz hat etwa ein WLAN eine solch große Reichweite, dass regelmäßig auf einer großen Fläche unabhängig von der Position eine Verbindung besteht oder hergestellt werden kann.
Besonders bevorzugt ist, dass die Initiatorinformation auf einem optischen Kurzstreckenübertragungsweg und weiter vorzugsweise zweidimensional codiert von dem Initiator-Endgerät 3 an das Ziel-Endgerät 1 gesendet wird. Zu dem Zweck der optischen Kurzstreckenübertragung bedarf es lediglich einer grafischen Anzeige 30 auf dem Initiator-Endgerät 3, welche etwa bei einem Smartphone 3a stets vorhanden ist, und einer Scanvorrichtung 31 auf dem Ziel-Endgerät 1. Insbesondere kann es sich bei der zweidimensional codierten Initiatorinformation um eine rechteckige Matrix handeln. Zu den bekannten solchen zweidimensionalen Codierungen zählen der QR(Quick Response)-Code sowie die darauf aufbauenden Weiterentwicklungen Design-QR-Code, Micro-QR-Code, Secure-QR-Code und iQR-Code.
Ebensolche Vorteile ergeben sich, wenn der Initiator-Referenzcode auf einem Kurzstreckenübertragungsweg von dem Initiator-Endgerät 3 an das Ziel-Endgerät 1 gesendet wird. Der Begriff Kurzstreckenübertragungsweg ist dabei wie obenstehend beschrieben zu verstehen.
Auch hier ist besonders bevorzugt, dass der Initiator-Referenzcode auf einem optischen Kurzstreckenübertragungsweg, weiter vorzugsweise zweidimensional codiert, von dem Initiator-Endgerät 3 an das Ziel-Endgerät 1 gesendet wird, wobei hier wiederum die Begriffe optischer Kurzstreckenübertragungsweg und zweidimensional codiert wie bereits beschrieben zu verstehen sind. Wiederum wie bereits für die Initiatorinformation beschrieben kann es sich bei der zweidimensional codierten Quellen-Vergleichsinformation um eine rechteckige Matrix handeln, wobei wiederum die genannten bekannten zweidimensionalen Codierungen auch hier in Frage kommen.
Die Verwendung eines optischen Übertragungswegs sowohl für das Senden 24 der Initiatorinformation als auch für das Senden 29 des Initiator-Referenzcodes schafft die Möglichkeit, für beide Sendevorgänge denselben Übertragungsmechanismus und insbesondere denselben unidirektionalen Übertragungsmechanismus zu gebrauchen.
Die obenstehenden Feststellungen bezüglich des Sendens 24 und des Sendens 29 gelten dann auch für das entsprechende Empfangen 9 und/oder das entsprechende Empfangen 12 durch das Ziel-Endgerät 1.
Weiter ist bevorzugt vorgesehen, dass die Initiatorinformation benutzerbezogene Daten und/oder gerätebezogene Daten umfasst. Die benutzerbezogenen Daten dienen der Identifikation des Benutzers des Initiator-Endgeräts 3 und können beispielsweise den Namen, Vornamen, das Geburtsdatum oder die Anschrift dieses Benutzers umfassen. Die gerätebezogenen Daten wiederum dienen der Identifikation des Initiator-Endgeräts 3 selbst und können dementsprechend eine Geräte-Seriennummer, ein Herstellungsdatum und/oder eine IMEI(International Mobile Station Equipment Identity)-Nummer des Initiator-Endgeräts 3 umfassen. Die Initiatorinformation kann auch einen aktuellen Zeitstempel umfassen.
Insbesondere ist es bevorzugt, dass die Initiatorinformation Formatierungsdaten umfasst und die Initiatorinformation auch gemäß diesen Formatierungsdaten formatiert ist. So kann die Initiatorinformation als XML(Extensible Markup Language)-Dokument vorliegen und entsprechend einer Schema-Definition formatiert sein, wobei eben diese Schema-Definition als Formatierungsdaten und Teil der Initiatorinformation mitgesendet werden. Ein bekanntes Beispiel für eine Schema-Definition stellt DTD (Document Type Definition) dar.
Ebenso ist es bevorzugt, dass die Initiatorinformation protokollbezogene Initiator-Kommunikationsparameter umfasst. Diese sind etwa für das Senden 25 der Bestätigungsanfrage oder das Senden 22 des Initiator-Referenzcodes von dem Autorisierungsserver 2 an das Initiator-Endgerät 3 von Bedeutung. Es könnte etwa eine Portnummer im Kontext von TCP (Transmission Control Protocol) über IP (Internet Protocol) als Initiator-Kommunikationsparameter vorgesehen sein, welche derjenigen Portnummer entspricht, über die das Initiator-Endgerät 3 eine Kommunikation mit dem Autorisierungsserver 2 erwartet. Auf diese Weise kann die Sicherheit der Transaktion erhöht werden, weil ein Kommunikationsversuch etwa über einen anderen Port als ungültig abgelehnt werden kann.
Vorteilhaft ist es ebenso, wenn der Inhalt der Initiatorinformation so verschlüsselt ist, dass sie nur von dem Autorisierungsserver 2 entschlüsselt werden können. Denn eine Überprüfung des Inhalts der Initiatorinformation durch das Ziel-Endgerät 1 ist nicht erforderlich. Folglich kann diese Überprüfung in Gänze auf den Autorisierungsserver 2 verlagert werden. Das Ziel-Endgerät 1 müsste also die beim Empfangen 9 erhaltene Initiatorinformation in so einem Fall einfach nur beim Senden 10 durchreichen.
Analog zu der soeben beschriebenen bevorzugten Ausgestaltung der Initiatorinformation, wodurch etwa eine eindeutige Zuordnung zu einem bestimmten Initiator-Endgerät 3 ermöglicht wird, ist vorteilhafterweise vorgesehen, dass die Zielinformation benutzerbezogene Daten und/oder gerätebezogene Daten umfasst. Dabei beziehen sich die Daten auf den Benutzer des Ziel-Endgeräts 1 bzw. auf das Ziel-Endgerät 1 selbst. Unter dem Benutzer des Ziel-Endgeräts 1 ist nicht ausschließlich der körperliche Bediener des Ziel-Endgeräts 1 zu verstehen, sondern jedwede natürliche oder juristische Person, welcher das Ziel-Endgerät 1 in dem Sinne zugeordnet ist, dass die über das Ziel-Endgerät 1 abgewickelte elektronische Transaktion an diese Person gerichtet ist. Für den vorliegenden Beispielfall des Einkaufs würde es sich also um das Unternehmen handeln, welches als Verkäufer dieses Kaufvorgangs auftritt.
Damit der Benutzer des Initiator-Endgeräts 3 die Möglichkeit hat, die Identität des Ziel-Endgeräts 1 und/oder die Identität des Benutzers des Ziel-Endgeräts 1 in diesem Sinne zu überprüfen, können die benutzerbezogenen Daten und alternativ oder zusätzlich die gerätebezogenen Daten der Zielinformation durch den Autorisierungsserver 2 mittels der Bestätigungsanfrage an das Initiator-Endgerät 3 übertragen werden. Der Benutzer des Initiator-Endgeräts 3 kann dann kontrollieren, auf welche Weise sich das Ziel-Endgerät 1, also der Empfänger der elektronischen Transaktion, gegenüber dem Autorisierungsserver 2 identifiziert und prüfen, ob dies sich mit seiner Erwartung deckt.
Ebenso kann die Zielinformation bevorzugt protokollbezogene Ziel-Kommunikationsparameter umfassen, wozu wiederum eine Portnummer wie bereits für die Initiatorinformation beschrieben zählen kann. Das Ziel-Endgerät 1 kann dann entsprechend das Empfangen 11 der Ziel-Vergleichsinformation auf dieser Portnummer erwarten.
Auf diesen beiden bevorzugten Ausführungsbeispielen aufbauend kann weiter vorgesehen sein, dass das Senden 22 des Initiator-Referenzcodes an das Initiator-Endgerät 3 wie bereits erwähnt gemäß den Initiator-Kommunikationsparametern erfolgt. Alternativ oder zusätzlich kann vorgesehen sein, dass das Senden 21 des Ziel-Referenzcodes an das Ziel-Endgerät 1 gemäß den Ziel-Kommunikationsparametern erfolgt. Beispiele hierfür ergeben sich aus den obenstehenden Beispielen für die Initiator-Kommunikationsparameter oder die Ziel-Kommunikationsparameter.
Auch das Senden 18 der Bestätigungsanfrage an das Initiator-Endgerät 3 erfolgt bevorzugt gemäß diesen Initiator-Kommunikationsparametern.
Die Sicherheit des vorschlagsgemäßen Verfahrens wird dadurch weiter erhöht, dass die Initiatorinformation eine digitale Initiatorsignatur aufweist. Diese Initiatorsignatur kann entweder dem Benutzer des Initiator-Endgeräts 3 oder dem Initiator-Endgerät 3 selbst zugeordnet sein. Es kann auch eine jeweilige digitale Initiatorsignatur für den Benutzer des Initiator-Endgeräts 3 einerseits und zusätzlich für das Initiator-Endgerät 3 selbst andererseits vorgesehen sein.
Gleichermaßen ergeben sich Vorteile, wenn die Zielinformation eine digitale Zielsignatur aufweist, welche wiederum dem Benutzer des Ziel-Endgeräts 1 – im Sinne wie oben beschrieben – oder dem Ziel-Endgerät 1 selbst zugeordnet sein kann. Wie bereits im Hinblick auf die digitale Initiatorsignatur beschrieben, können beide diese digitalen Zielsignaturen vorgesehen sein. Alternativ kann die beschriebene digitale Zielsignatur (oder die beschriebenen digitalen Zielsignaturen) auch ein Bestandteil der Transaktionsnachricht insgesamt sein.
Die verlässliche Bestätigung der Transaktion durch den Benutzer des Initiator-Endgeräts 3 kann dadurch weiter sichergestellt werden, dass die Bestätigungsantwort eine Identifizierungsinformation umfasst. Es kann sich dabei beispielsweise um einen von dem Benutzer des Initiator-Endgeräts 3 eingegeben PIN-Code handeln, welcher mit dem im Autorisierungsserver 2 hinterlegten PIN-Code des Benutzers verglichen werden kann. Alternativ oder zusätzlich kann es sich bei der Identifizierungsinformation um biometrische Daten handeln, so etwa um einen Fingerabdruck des Benutzers des Initiator-Endgeräts 3 bzw. den Minutien eines solchen Fingerabdrucks. Diese biometrischen Daten, zu denen auch eine Iriserkennung zählen kann, können dann ebenfalls mit einer im Autorisierungsserver 2 hinterlegten entsprechenden Referenz verglichen werden können. Das Vorhandensein dieser Identifizierungsinformation in der Bestätigungsantwort bestätigt, dass der Benutzer des Initiator-Endgeräts 3 die Transaktion gebilligt und durch eigenes Handeln bestätigt hat. Sollte die Identifizierungsinformation durch den Autorisierungsserver 2 nicht mit positivem Ergebnis geprüft werden, so wird regelmäßig das bereits beschriebene Abbrechen 20 der elektronischen Transaktion erfolgen.
Bevorzugt weist die Bestätigungsantwort auch eine digitale Initiatorsignatur auf. Dabei kann es sich um dieselbe digitale Initiatorsignatur handeln wie für die Initiatorinformation beschrieben.
Schließlich ist bevorzugt vorgesehen, dass bei einer Bestätigung der Freigabe ein Protokoll angelegt wird, wobei das Protokoll die Initiatorinformation, die Bestätigungsantwort und/oder den Initiator-Referenzcode umfasst. Unter einem solchen Protokoll ist ein beliebiges Informationsdatum mit diesen Angaben zu verstehen. Insbesondere kann es sich bei diesem Protokoll um einen Datenbankeintrag handeln. Weiter ist bevorzugt, dass das Protokoll in dem Initiator-Endgerät 3 und/oder in einem elektronischen Postfach 32, wie es beispielsweise für E-Mail verwendet wird, und/oder in einem Cloud-Datenspeicher 33 abgespeichert wird. Unter einem Cloud-Datenspeicher 33 ist ein Datenspeicher in einer Datenbank zu verstehen, auf den über das Internet 4 (unter Berücksichtigung von Zugangsbeschränkungen) zugegriffen werden kann.
Auf Grundlage eines solchen Protokolls kann – bei Teilnahme des Benutzers des Initiator-Endgeräts 3 an einem Bonus- oder Rabattprogramm – eine automatische Gutschrift auf dem entsprechenden Punktekonto erfolgen. Dieses Protokoll kann auch eine elektronische Quittung darstellen, welche entsprechend die Kaufliste, Mietpreise oder die Teilnahme an einer bestimmten Veranstaltung dokumentiert. Sie ist grundsätzlich papierlos aber nichtsdestotrotz ausdruckbar.
Die Erfindung betrifft ferner ein Computerprogramm mit Programmcode zur Durchführung aller Verfahrensschritte eines vorschlagsgemäßen Verfahrens, wenn das Computerprogramm in einem Computer ausgeführt wird.
Hier bedeutet Computerprogramm ein ablauffähiges Programm für einen beliebigen Prozessor mit einem beliebigen, ggf. vorhandenen Betriebssystem. Entsprechend umfasst der Begriff Programmcode nicht nur Code zum Ablauf auf einem Personalcomputer, sondern auch jedweden Code zum Ablauf auf einem beliebigen Prozessor oder Rechensystem mit Prozessor. Zu solchen Rechensystemen zählen sowohl Mobiltelefone und Smartphones als auch Mikrocontroller mit integriertem Prozessor und Arbeitsspeicher. Der Begriff Computer bzw. digitaler Computer ist ebenfalls so zu verstehen, dass diese Mikroprozessorsysteme darunter fallen.
Ein elektronisches Datenträgersignal ist durch eine beliebige digitale Signalfolge gegeben, welche auf einem flüchtigen oder nicht-flüchtigen elektronischen Speicher abgelegt werden kann.

Claims

Verfahren zur Autorisierung einer elektronischen Transaktion in einem Initiator-Endgerät (3), wobei mindestens folgende Verfahrensschritte durchlaufen werden: – Senden (24) einer Initiatorinformation auf einem Kurzstreckenübertragungsweg an ein Ziel-Endgerät (1), vorzugsweise in einer unidirektionalen Übertragung, wobei die Initiatorinformation protokollbezogene Initiator-Kommunikationsparameter umfasst; – Empfangen (25) einer von einem Autorisierungsserver (2) gemäß den Initiator-Kommunikationsparametern gesendeten Bestätigungsanfrage; – Senden (27) einer Bestätigungsantwort an den Autorisierungsserver (2); – Empfangen (28) eines von dem Autorisierungsserver (2) gemäß den Initiator-Kommunikationsparametern gesendeten Initiator-Referenzcodes und – Senden (29) des Initiator-Referenzcodes auf einem Kurzstreckenübertragungsweg an das Ziel-Endgerät (1), vorzugsweise in einer unidirektionalen Übertragung.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Initiatorinformation auf einem optischen Kurzstreckenübertragungsweg, weiter vorzugsweise zweidimensional codiert, insbesondere als rechteckige Matrix, von dem Initiator-Endgerät (3) an das Ziel-Endgerät (1) gesendet wird.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass der Initiator-Referenzcode auf einem optischen Kurzstreckenübertragungsweg, weiter vorzugsweise zweidimensional codiert, insbesondere als rechteckige Matrix, von dem Initiator-Endgerät (3) an das Ziel-Endgerät (1) gesendet wird.
Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die Initiatorinformation benutzerbezogene Daten und/oder gerätebezogene Daten umfasst, vorzugsweise, dass die Initiatorinformation Formatierungsdaten umfasst und gemäß den Formatierungsdaten formatiert ist.
Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass das Senden (21) des Ziel-Referenzcodes an das Ziel-Endgerät (1) gemäß den Ziel-Kommunikationsparametern erfolgt.
Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass die Initiatorinformation eine digitale Initiatorsignatur aufweist.
Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass die Bestätigungsantwort eine Identifizierungsinformation umfasst, vorzugsweise, dass die Bestätigungsantwort ferner eine digitale Initiatorsignatur aufweist.
Computerprogramm mit Programmcode zur Durchführung aller Verfahrensschritte nach einem der Ansprüche 1 bis 7, wenn das Computerprogramm in einem Computer ausgeführt wird.