Die Erfindung betrifft ein Verfahren zur Autorisierung einer elektronischen Transaktion in einem Ziel-Endgerät mit den Merkmale des Anspruchs 1, ein Verfahren zur Autorisierung einer elektronischen Transaktion in einem Autori- sierungsserver mit den Merkmalen des Anspruchs 2, ein Verfahren zur Autorisierung einer elektronischen Transaktion in einem Initiator-Endgerät mit den Merkmalen des Anspruchs 3 sowie ein C o m pu terp rog ram m mit den Merkmalen des Anspruchs 15.

Durch die zunehmende Verbreitung von tragbaren elektronischen Geräten mit weitreichenden Kommunikationsfahigkeiten, 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ählt 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 Hotspot 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 Magnetstrei fenkarte 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 Empfanger oder das Ziel vorgenommen werden, 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 V erwendung 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 I denti fi kationsnummer (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 o- der 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.

Aus der WO 2012/003892 AI 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 A I bekannte Verfahren hat aber erstens den Nachteil, dass aufsehen 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 Mobiltelefone 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 aufsei- ten 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 Ziel-Endgerät durch die Merkmale des Anspruchs 1 , bezogen auf ein solches Verfahren zur Autorisierung einer elektronischen Transaktion in einem Autorisierungsserver durch die Merkmale des Anspruchs 2, bezogen auf ein Verfahren zur Autorisierung einer elektronischen Transaktion in einem Initiator-Endgerät durch die Merkmale des Anspruchs 3 und bezogen auf ein Computerprogramm durch die Merkmale des Anspruchs 15 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 Hotspot 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- ndgerät genau vertauscht sind. Als Initiator- oder Ziel-Endgeräte kommen insbesondere Smart- phones, Tablets, Personal Digital Assistants (PDAs), Pocket PCs und jedwede weiteren vergleichbare Geräte infrage. 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 zu sammenwi rkende 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 Serv eraufgaben 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 mithilfe 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- ndgerä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, v ollstä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 Initi a tor- E n dgeräts ohne das Risiko eines„Hackens" möglich ist.

Die bevorzugten Ausgestaltungen gemäß der Unteransprüche 5 und 6 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 7 bis 9 wiederum verbessern die Sicherheit der Kommunikation zwischen den Endgeräten und dem Autorisie- rungsserver. Sie ermöglichen die dynamische Bestimmung verschiedener Kommunikationsparameter, wodurch ein M i tte 1 s ma n nangr i ff in der Kommunikation zwischen dem Autorisierungsserver und den Endgeräten deutlich erschwert wird.

Auch die bevorzugten Ausgestaltungen der Ansprüche 10 bis 12 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

Fig. 1 die Konstellation der Endgeräte, des Autorisierungsservers und der dazugehörigen Infrastruktur für die vorschlagsgemäßen Verfahren und

Fig. 2 ein paralleles Ablaufdiagramm für die vorsch lagsgemäßen Verfahren in dem Initiator-Endgerät, dem Ziel-Endgerät sowie dem Autorisierungsserver.

In der Fig. 1 sind ein Ziel-Endgerät 1, in diesem Falle ein stationärer Kassencomputer la, 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- Anbi ndung 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 la mehrere Sensoren zum Datenempfang umfassen, wel- che entweder per Kabel oder sogar nur per Funk mit dem Hauptgehäuse des Kassencomputers 1 a 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 l a, 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 Zahlungs weisen 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 Pay al, 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 Verfugung, 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 Grundeinstellun 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 Uberblick über die Zahlungsbel astungen 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 der nachfolgenden vorschlagsgemäßen Verfahren 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), sodass die Bezeichnungen, Menge und Preisinformationen der zu bezahlenden Waren am Ziel- Endgerät 1 vorliegen.

Das vorschlagsgemäße 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 Fig. 2 für den mittleren Ablaufstrang dargestellt ist, welcher dem Ziel-Endgerät 1 zugeordnet ist.

Ein erster vorschlagsgemäßer 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 Zahlungs weise 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 bewu st 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 l a identifiziert, was durch den soeben beschriebenen Schritt des Empfangens 9 geschieht, bevor die Waren von dem Kassencomputer l a 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 l a gelegt werden, so etwa am Beginn des Förderbandes und also am entgegengesetzten Ende zum Kassencomputer l a.

Ein weiterer vorschlagsgemäßer Verfahrensschritt umfasst das Senden 10 einer Transaktionsnachricht, welche die Initiatorinformation sowie eine Zielinformation umfasst, an den Autorisierungsserver 2. Analog zu der Initiatorinformation er- laubt 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.

Vorschlagsgemäß sieht ein weiterer Verfahrensschritt das Empfangen 1 1 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.

Weiter vorschlagsgemäß 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.

I einer bevorzugten Ausgestaltung dieses vorschlagsgemäßen 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-Referenzcodes 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 I nitiator-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 1 1 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-Referenzcode basiert. Dieser Vergleich kann eine Überprüfung der Identität der beiden Referenzcodes oder aber eine Uberprü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 positive Korrelation bzw. einen positiven Vergleich des Ziel- Referenzcodes zu dem Initiator-Referenzcode ist also, dass eine lückenlose Identifikationskette der an der elektronischen Transaktion 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 einem 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 1 1 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 vorschlagsgemäß in dem Autorisierungsserver 2 ablaufenden Verfahrensschritte beschrieben. Diese sind in der Fig. 2 in dem rechten Ablaufstrang dargestellt. Vorschlagsgemäß werden dabei mindestens die folgenden Verfahrenssc hri tte durchlaufen: Ein vorschlagsgemäßer 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 1 7 auch eine grundsätzliche Zulässigkeitsprüfung dieser Angaben umfassen. Dieses Überprüfen 17 kann also die Frage betreffen, ob 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 oder ob eine Sperrung o. dgl. vorliegt.

Ein weiterer vorschlagsgemäßer 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 Parametern 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 können Adresse und Firma des Zahlungsempfängers vorgesehen sein. Dieses Senden 1 8 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 mithilfe 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.

Vorschlagsgemäß sieht ein weiterer Verfahrensschritt 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 vorschlagsgemäß 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- eferenzcode als auch der Initiator- Referenzcode vom Autorisierungsserver 2 dynamisch erzeugt, und zwar insbesondere nach Erhalt der positiven Bestätigungsantwort. Dieses Erzeugen des Ziel-Referenzcodes und des Initiator- Referenzcodes erfolgt insbesondere nach einer vorbestimmten, aber bevorzugt geheim gehaltenen Vorschrift. 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 I ni tiator-Referenzcode bevorzugt einmalig. Ebenso bevorzugt kann vorgesehen sein, dass ein gesendetes Paar von Ziel-Referenzcode und Initiator- Referenzcode während einer vorbestimmten Sperrzeit durch den Autorisierungsserver 2 von einer Wiederverwendung ausgeschlossen ist.

Um die Sicherheit der Transaktion weiter zu erhöhen, kann das Senden 2 1 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 2 1 , 22 beginnt, bevor der jeweils andere abgeschlossen ist. Gleichzeitigkeit in diesem Sinne ist wiederum etwa dann gegeben, wenn beide Sende- Vorgänge 2 1 ,22 mit dem gleichen Zeitstempel versehen sind.

Bevorzugt beruht auch das Senden 2 1 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 o- der, 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 Fig. 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ätigun des Benutzers des 1 nitiator- 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 I n iti ator- 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 Parametern 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 vorzugsweise mit der positiven Bestä- tigungsantwort an den Autorisierungsserver 2 gesandt. Aber auch wenn dies bereits mit der Initi ator- Informa t i on 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- E ndgerä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 iässt sich ebenso auch für die Bezahlung bei einem Online- Einkauf i 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 - befinde 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 Yerortung 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 Z i el - Re ferenzcode ist. Auf diese Weise kann die Kenntnis über die spezielle Codierung und Erzeugungsweise der beiden Referenzcodes innerhalb des Auto- risierungsservers 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 Informationen sich mit den bekannten Parametern der elektronischen Transaktion decken. Diese Analyse kann in der Art einer Blackbox, etwa durch eine geschlossene und proprietäre Software erfolgen, sodass 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 Ausfuhrungsform, bei der der 1 n itiator- R eferenzcode 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 Initiatorinfonnation 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 I n i ti ator- 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 I gesendet wird, wobei hier w iederum die Begriffe optischer Kurzstrec kenü 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 z wei di m ens i on a 1 en 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 Übertragungsme- chanismus und insbesondere denselben unidirektionalen Ubertragungsmecha- nismus 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 In i ti atorinformation 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- S eri ennu mmer, ein I I erstel 1 ungsdatum und/oder eine IM EI (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 Initiatorin formation Formati erungsdaten umfasst. Diese Formatierungsdaten dienen dem Autorisierungsserver 2 bevorzugt zur Formatierung der Bestätigungsanfrage. Daher ist bevorzugt, dass die Bestätigungsanfrage, vorzugsweise zumindest teilweise, gemäß diesen Formatierungsdaten formatiert ist. Vorzugsweise ist alternativ oder zusätzlich die Initiato- rinformation, insbesondere zumindest teilweise, gemäß den Formatierungsdaten formatiert. Auf diese Weise kann das Initiator- Endgerät 3 die Korrektheit der Bestätigungsanfrage bestätigen oder der Autorisierungsserver 2 die Formatierung der Initiatorinformation prüfen. Es kann die Initiatorinformation als XML (Ex- tensible Markup Language)-Dokument vorliegen und entsprechend einer Schema-Definition formatiert sein, wobei eben diese Schema-Definition als Formatierungsdaten und somit als 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 18 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. Eine andere Möglichkeit für einen solchen protokollbezogenen Initiator- Kommunikationsparameter ist die IP- Adresse selbst, ein vorzugsweise software- seitig vergebener Handle oder ein anderer eindeutiger Referenzwert, welcher z.B. aus einer potenziellen Vielzahl von zum Autorisierungsserver bestehenden Verbindungen diejenige des Initiator- Endgeräts 3 kennzeichnet.

Vorteilhaft ist es ebenso, wenn der Inhalt der I ni ti atori n förmat ion 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. Bevorzugt umfasst die Transaktionsnachricht also die I nitiatorinformation verschlüsselt. 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 Initia- tor-Endgerät 3 ermöglicht wird, ist vorteilhafterweise vorgesehen, dass die Zielinformation benutzerbezogene Daten und/oder gerätebezogene Daten um- fasst. 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 Autonsierungsserver 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 Autonsierungsserver 2 identifiziert und prüfen, ob dies sich mit seiner Erwartung deckt.

Ebenso kann die Ziel Information bevorzugt protokollbezogene Ziel- Kommunikationsparameter umfassen, wozu wiederum eine Portnummer wie bereits für die Initiatorinformation beschrieben zählen kann. Die weiteren oben im Zusammenhang mit der Initiatorinformation beschriebenen protokoll bezogenen Kommunikationsparameter kommen sinngemäß gleich auch hier in frage. Das Ziel-Endgerät 1 kann dann entsprechend das Empfangen 1 1 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 Grandlage 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 femer ein C o mputerprogra mm mit Programmcode zur Durchführung aller Verfahrensschritte eines vorschlagsgemäßen Verfahrens, wenn das Computerprogramm in einem Computer ausgeführt wird.

Weiter betrifft die Erfindung ein Computerprogrammprodukt, das direkt in den internen Speicher eines digitalen Computers geladen werden kann und Softwarecodeabschnitte umfasst, mit denen die Schritte gemäß einem vorschlagsgemäßen Verfahren ausgeführt werden, wenn das Produkt auf einem Computer läuft. Die Erfindung betrifft auch ein Computerprogramm, das Instruktionen aufweist, die zur Durchführung eines vorschlagsgemäßen Verfahrens eingerichtet sind.

Ferner betrifft die Erfindung ein Computerprogrammprodukt, welches ein computerlesbares Medium mit Computerprogrammcode-Mitteln aufweist, bei dem jeweils nach dem Laden des Computerprogramms ein Computer zur Durchführung eines vorschlagsgemäßen Verfahrens veranlasst wird.

Schließlich betrifft die Erfindung ein Computerprogrammprodukt, welches ein Computerprogramm auf einem elektronischen Datenträgersignal aufweist, bei dem jeweils nach dem Laden des Computerprogramms ein Computer zur Durchführung eines vorschlagsgemäßen Verfahrens veranlasst wird.

Hier bedeutet Computerprogramm und Computerprogrammprodukt ein ablauffähiges Programm für einen beliebigen Prozessor mit einem beliebigen, ggf. vorhandenen Betriebssystem. Entsprechend umfassen die Begriffe Programmcode, Softwarecodeabschnitte und Computerprogrammcode-Mittel nicht nur Code zum Ablauf auf einem Personalcompu ter, 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 Mikro- controller 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.