CH710912B1

CH710912B1 - Sichere Transaktionsverarbeitung in einem Kommunikationssystem.

Info

Publication number: CH710912B1
Application number: CH01024/16A
Authority: CH
Inventors: Gautschi Peter
Original assignee: Gautschi Peter
Priority date: 2014-02-11
Filing date: 2015-02-11
Publication date: 2019-07-15
Also published as: EP2905735A1; US10387886B2; US20160342998A1; WO2015121801A1; DE112015000746T5

Abstract

Die vorliegende Erfindung betrifft ein Verfahren zur Verarbeitung einer Transaktion zwischen einem Zahlungsempfänger und einem Zahler in einem Kommunikationssystem, das aus einem Serviceprovider-Server (3 2 ) eines Zahlers, einem Serviceprovider-Server (3 1 ) eines Zahlungsempfängers und einem tragbaren, vom Zahler betriebsfähigen, drahtlosen Kommunikationsgerät (2) besteht. Das Verfahren besteht aus: Serviceprovider-Server (3 2 ) des Zahlers, der vom tragbaren drahtlosen Kommunikationsgerät (2) eine Transaktionskennung und eine Serviceproviderkennung des Zahlungsempfängers erhält (19); dem Serviceprovider-Server (3 2 ) des Zahlers, der Transaktionsdaten vom Serviceprovider-Server (3 1 ) des Zahlungsempfängers – identifiziert durch die Serviceproviderkennung des Zahlungsempfängers – anfordert (21); dem Serviceprovider-Server (3 2 ) des Zahlers, der die angeforderten Transaktionsdaten erhält (23); dem Serviceprovider-Server (3 2 ) des Zahlers, der die Transaktionsdaten an das tragbare drahtlose Kommunikationsgerät (2) überträgt (27); und dem Serviceprovider-Server (3 2 ) des Zahlers, der vom tragbaren drahtlosen Kommunikationsgerät (2) eine Transaktionsbestätigungsanforderung erhält (29).

Description

Beschreibung

Technischer Bereich [0001] Die Erfindung betrifft ein Verfahren zur Verarbeitung von Transaktionen in einem Kommunikationssystem. Die Erfindung bezieht sich auf ein Kommunikationselement zur Ausführung des Verfahrens, ein Computerprogrammprodukt für das Kommunikationselement und ein Kommunikationssystem, das das Kommunikationselement aufweist.

Hintergrund der Erfindung [0002] Kreditkarten, Bankkarten, Prepaid-Karten und Mitgliedskarten sind zu einem weitverbreiteten bargeldlosen Zahlungsmittel geworden. Es besteht jedoch die Gefahr, dass die Zahlungskarten für betrügerische Zwecke verwendet werden, und es ist sowohl für den Kunden als auch für den Kartenaussteller sehr lästig zu gewährleisten, dass die Karte nicht missbräuchlich verwendet werden kann.

[0003] Die Nutzung von Zahlungskarten birgt auch das Problem, dass die persönlichen Daten des Kartenhalters und insbesondere sicherheitsrelevante Elemente - wie beispielsweise Passwörter - an ein Auszahlungsendgerät des Zahlungsempfängers übertragen werden müssen. Bei modernen Zahlungssystemen, wie sie zum Beispiel in Supermärkten und in verschiedenen Geschäften genutzt werden, können persönliche Daten, wie zum Beispiel die Bankkontonummer/Kre-ditkartennummer, die Nummer der Bankleitzahl, Name und Anschrift des Kunden usw. von der Zahlungskarte ausgelesen und an das Lesegerät des Ladenbesitzers übertragen werden. Die übermittelten personenbezogenen Daten können vom Ladenbesitzer verwendet werden, um Zahlungstransaktionen einzuleiten, indem eine entsprechende Anforderung an einen Server des Finanzdienstleisters gesendet wird. Die Übermittlung personenbezogener Daten von einer Zahlungskarte des Kunden an das Endgerät des Zahlungsempfängers stellt ein Sicherheitsrisiko dar. Um die Probleme im Zusammenhang mit dem direkten Einsatz von Zahlungskarten zu überwinden, wurden einige Zahlungslösungen vorgeschlagen, die das Endgerät des Kunden, wie etwa ein Mobiltelefon, verwenden. In einigen dieser Lösungen, die auch als mobile Zahlungslösungen bekannt sind, tastet ein Endgerät des Kunden an der Verkaufsstelle (POS) einen Barcode ab, um eine Zahlungstransaktion einzuleiten. Jedoch weisen viele dieser Lösungen bei der Verarbeitung der Transaktion einige Fehler auf, ganz besonders in Bezug auf die Sicherheit und Anonymität der Transaktion. Diese bekannten Lösungen setzen den Zahler nicht vertrauenswürdigen Netzwerkeinrichtungen aus und fördern ihn auf, vertrauliche Informationen an sogenannte «untrusted»-Netzwerkelemente zu übermitteln, d.h. Netzwerkelemente, mit denen er kein Vertrauensverhältnis hat. Dies stellt natürlich ein Sicherheitsrisiko dar und sollte deshalb minimiert werden.

[0004] Die Aufgabe der vorliegenden Erfindung ist es, solche Probleme bei aktuellen Transaktionsverarbeitungsverfahren zu überwinden, indem sie bei der Transaktionsverarbeitung eine anspruchsvollere Lösung bietet, die nicht nur in Geschäften angewendet werden kann, sondern beispielsweise auch bei Online-Transaktionen oder Geldautomaten (ATM).

Kurze Beschreibung der Erfindung [0005] Gemäss einem ersten Aspekt der Erfindung wird ein Verfahren zur Verarbeitung einer Transaktion gemäss Anspruch 1 geboten. Die vorgeschlagene neue Lösung hat den Vorteil, dass die Transaktionsverarbeitung schnell, sicher und anonym durchgeführt werden kann. Im vorliegenden Verfahren wird die zweite Transaktionspartei mit der ersten Transaktionspartei keine vertraulichen Informationen austauschen, wie etwa Einzelheiten des Zahlers. Die zweite Transaktionspartei, die die Transaktionskennung und die Kennung des Zahlungsdienstleisters des Zahlers von der ersten Transaktionspartei erhalten hat, handelt nur mit ihrem eigenen Trusted-Dienstleistungsanbieter, [d.h. mit dem sie ein Vertrauensverhältnis hat - nachstehend auch als «vertrauenswürdig» übersetzt]. Letzterer kann weitere gesicherte und vertrauenswürdige Verbindungen haben, zum Beispiel mit verschiedenen Finanzinstituten. Der Server des zweiten Dienstleistungsanbieters kann die zweite Transaktionspartei zuverlässig identifizieren und somit sicherstellen, dass die zweite Transaktionspartei in der Tat diejenige ist, die sie vorgibt zu sein. Dies kann durch herkömmliche Identifikationsschritte erreicht werden, die von der zweiten Transaktionspartei durchgeführt werden - wie beispielsweise die Eingabe von Passwörtern usw. Des Weiteren werden in der vorliegenden Erfindung mit anderen Kommunikationsgeräten nur Kommunikationselemente kommuniziert, mit denen eine Vertrauensbeziehung bereits hergestellt ist. Die Transaktionsverarbeitung kann auch anonym erfolgen, da die erste Transaktionspartei nicht in jeder Phase der Transaktion die Identität der zweiten Transaktionspartei kennen muss. Eine Bestätigung, dass eine Transaktion erfolgreich abgeschlossen wurde, kann an die erste Transaktionspartei gesendet werden (und wahlweise an die zweite Transaktionspartei), aber in den meisten Anwendungen müssen die Details der zweiten Transaktionspartei nicht an die erste Transaktionspartei übermittelt werden.

[0006] Gemäss einem zweiten Aspekt der Erfindung wird für die Durchführung der Transaktionsverarbeitungsverfahren gemäss dem ersten Aspekt ein Server bereitgestellt.

[0007] Gemäss einem dritten Aspekt der Erfindung wird ein eingerichtetes Computerprogrammprodukt zur Verfügung gestellt, um das Verfahren gemäss dem ersten Aspekt der vorliegenden Erfindung durchzuführen.

[0008] Gemäss einem vierten Aspekt der vorliegenden Erfindung wird ein Kommunikationssystem bereitgestellt, das einen Server gemäss dem zweiten Aspekt der vorliegenden Erfindung aufweist.

[0009] Andere Aspekte der Erfindung sind in den hier beigefügten abhängigen Ansprüchen angegeben.

Kurze Beschreibung der Zeichnungen [0010] Weitere Merkmale und Vorteile der Erfindung werden anhand der folgenden Beschreibung eines nicht einschränkenden Ausführungsbeispiels unter Bezugnahme auf die beigefügten Zeichnungen ersichtlich, in denen:

Abb. 1 einige der Kommunikationsnetzwerkelemente des Kommunikationssystems veranschaulicht, in dem das Verfahren der vorliegenden Erfindung durchgeführt werden kann; und

Abb. 2 ein Ablaufschaubild ist, das die sichere Transaktionsverarbeitungsverfahren gemäss eines Ausführungsbeispiels veranschaulicht.

Detaillierte Beschreibung einer Ausführung der Erfindung [0011] Eine Darstellung der vorliegenden Erfindung wird unter Bezugnahme auf die beigefügten Abbildungen nachfolgend detaillierter beschrieben. Identischen oder entsprechenden Funktions- und Strukturelementen, die in den unterschiedlichen Zeichnungen erscheinen, sind die gleichen Referenzzahlen zugeordnet.

[0012] Abb. 1 veranschaulicht das Beispiel eines vereinfachten Kommunikationsnetzdiagramms, das die Elemente zeigt, die für das Verständnis der Lehren der vorliegenden Erfindung nützlich sind. Dieses beispielgebende Diagramm zeigt fünf Netzwerkelemente, nämlich ein Zahlungsempfänger- oder POS-Endgerät 1, ein vom Zahler, Kunden oder Anwender betreibbares Mobilgerät 2, einen ersten Serviceprovider-Server, auch als Zahlungsempfänger- oder POS-Server 3Ί bezeichnet, einen zweiten Serviceprovider-Server, auch bezeichnet als Serviceprovider-Server 32 des Zahlers oder Nutzers, und ein Bankennetzwerk 4, welches zum Beispiel Netzelemente verschiedener Finanzinstitute wie Banken oder Kreditkartengesellschaften aufweist. Diese Bankennetzwerkelemente wie Server sind zum Beispiel in der Lage, nach Erhalt der Genehmigung seitens eines Kunden Kundenkonten oder Kreditkarten zu belasten, um den Betrag dem Konto eines Zahlungsempfängers gutzuschreiben. Der POS-Server 3Ί ist ein Netzwerkelement des Serviceproviders einer ersten Transaktionspartei, die manchmal der Zahlungsempfänger ist; während der Serviceprovider-Server 32 des Benutzers ein Netzwerkelement des Serviceproviders einer zweiten Transaktionspartei ist, die manchmal der Zahler oder der Benutzer ist. Die Serviceprovider können z.B. Telekommunikationsbetreiber oder Anbieter von Zahlungsanwendungen oder Lösungen sein.

[0013] In der vorliegenden Erfindung kann sich die erste Transaktionspartei mit dem vertrauenswürdigen ersten Serviceprovider-Server 3i verbinden, mit dem sie eine erste Vertrauensbeziehung etabliert hat, während sich die zweite Transaktionspartei mit dem zweiten Serviceprovider-Server 32 verbinden kann, mit dem sie eine zweite Vertrauensbeziehung errichtet hat. Es kann somit eine sichere Kommunikationsverbindung zwischen dem ersten Serviceprovider-Server 3Ί und einem betriebsfähigen Gerät einer ersten Transaktionspartei (beispielsweise einem POS-Endgerät des Zahlungsempfängers) einerseits und zwischen dem zweiten Serviceprovider-Server 32 und einem betriebsfähigen Gerät einer zweiten Transaktionspartei (z, B. einem Mobiltelefon des Benutzers) auf der anderen Seite geben. Um diese gesicherte Kommunikationsverbindung zu erhalten, kann eine verschlüsselte Kommunikation verwendet werden.

[0014] Wie in Abb. 1 gezeigt, kann zumindest einer der Server 3Ί, 32 auch mit dem Bankennetzwerk 4 verbunden sein. Diese Verbindung kann entweder eine drahtgebundene, drahtlose oder optische Verbindung sein. Der POS-Server 3Ί ist auch in der Lage, mit dem POS-Endgerät 1 zu kommunizieren, während der Serviceprovider-Server 32 des Benutzers mit dem Mobilgerät 2 kommunizieren kann. Auch hier können diese Kommunikationsverbindungen entweder drahtgebundene, drahtlose oder optische Verbindungen sein. Allerdings gibt es eine drahtlose Verbindung zwischen dem Mobilgerät 2 und dem Serviceprovider-Server 32 des Benutzers.

[0015] In dem unten beschriebenen Beispiel ist das Endgerät 1 ein POS-Endgerät, aber es könnte alternativ auch jede andere Einheit sein, die eingerichtet ist, um bestimmte Informationen entweder aktiv oder passiv an das Mobilgerät 2 zu übermitteln. Dementsprechend kann abhängig von der Anwendung, in der die Lehren der Erfindung angewendet werden, das Endgerät 1 ein Geldautomat, ein Display, das eine Website anzeigt, ein Poster, ein Etikett, ein Ticket, ein tragbares drahtloses Handgerät usw. sein.

[0016] Die Mobilgeräte 2 sind digitale Kommunikationsgeräte wie Mobiltelefone (z.B. Smartphone), Laptops, Tablets, PCs usw., die die Fähigkeit haben, mit Serviceprovidern vorzugsweise drahtlos zu kommunizieren. Die Mobilgeräte 2 sind auch eingerichtet, um Daten vom POS-Endgerät 1 zu empfangen, und möglichst keine identifizierenden Daten an das POS-Endgerät 1 des Zahlers zu senden.

[0017] Die Mobilgeräte 2 können die Daten optisch und akustisch empfangen, indem sie ein Nahfeldkommunikationsverfahren usw. verwenden. Wenn die Daten optisch empfangen werden, kann das POS-Endgerät 1 zum Beispiel einen Barcode anzeigen, den das Mobilgerät 2 scannen kann. Ein Barcode ist eine maschinenlesbare optische Kennzeichnung, die Informationen über das Element enthält, an das es gebunden oder mit dem es verknüpft ist. Der Barcode kann ein eindimensionaler Strichcode oder ein zweidimensionaler Strichcode sein, der auch als Matrix-Barcode bekannt ist. Wenn in der vorliegenden Erfindung ein zweidimensionaler Barcode verwendet wird, dann kann dieser Barcode beispielsweise ein Quick-Response™(QR)-Code sein. Ein QR-Code besteht im allgemeinen aus schwarzen Modulen (quadratischen Punkten), die auf weissen Hintergrund in einem quadratischen Gitter angeordnet sind und von einem Bilderfassungsgerät (beispielsweise einer Kamera) gelesen und verarbeitet werden können, wobei eine Reed-Solomon-Fehlerkorrektur ver- wendet wird, bis das Bild angemessen interpretiert werden kann. Die Daten können dann aus Mustern extrahiert werden, die sowohl in den horizontalen als auch in den vertikalen Komponenten des Bildes vorhanden sind.

[0018] Der Ablaufplan von Abb. 2 zeigt die unternommen Schritte und die verschiedenen Nachrichten, die zwischen unterschiedlichen Einheiten, die an diesem Verfahren beteiligt sind, gesendet werden, um gemäss einer Ausführungsform der vorliegenden Erfindung eine gesicherte Zahlungstransaktion durchzuführen. Sobald der Zahlungsempfänger die vorliegende Transaktionsverarbeitungsmethode gewählt hat, um dem Benutzer oder dem Zahler zu erlauben, seine Einkäufe zu bezahlen, sendet in Schritt 11 das POS-Endgerät eine Anforderung, um eine Transaktions-ID zum POS-Server 3Ί zu bekommen. Diese Meldung kann auch eine Serviceprovider-Kennung des POS enthalten und einige Informationen in Bezug auf die Transaktion. Diese Informationen können zum Beispiel eine Identität des Unternehmens enthalten, das die Transaktion anbietet (ein Firmenname zum Beispiel), Kontaktdaten dieses Unternehmens, die Höhe der Transaktion, die Währung, Garantieinformationen, Bedingungen und Konditionen, und/oder eine Beschreibung des Produkts oder der Dienstleistung, das/die Gegenstand der Transaktion ist, usw. In diesem speziellen Beispiel enthält die Meldung folgende Informationen:

- Serviceprovider-ID: 01AB-1234-AF12-09AB - Betrag: 150

- Währung: CHF - Produktbeschreibung: Buch: «TheArt of Fly Fishing» [0019] Sobald der POS-Server 3Ί diese Informationen erhalten hat, speichert er sie in Schritt 13 und erzeugt eine Trans-aktions-ID. Diese Transaktions-ID ist in Verbindung mit der Serviceprovider-ID auf der ganzen Welt möglichst einmalig. In diesem Beispiel hat der Serviceprovider mit der ID 01AB-1234-AF12-09AB jetzt die folgenden Informationen in seiner Datenbank gespeichert: - Transaktions-ID: FAC4-ABGC-AFFA-0901 - Betrag: 150

- Währung: CHF - Produktbeschreibung: Buch: «The Art of Fly Fishing» [0020] Dann sendet in Schritt 15 der POS-Server 3Ί die Transaktions-ID an das POS-Endgerät 1. Jetzt möchte der Benutzer des Mobilgeräts 2 das Produkt oder die Dienstleistung kaufen, das oder die vom Zahlungsempfänger angeboten wurde. In diesem Beispiel wird vom POS-Endgerät 1 auf einem Pin-Pad ein QR-Code angezeigt. Dieser QR-Code enthält in diesem Beispiel die Transaktions-ID und die Serviceprovider-ID des POS-Endgeräts 1, jedoch ist das Letztere nicht erforderlich, wenn es nur einen Service-Provider gibt. Dann scannt in Schritt 17 das Mobilgerät 2 den QR-Code und liest dadurch optisch die Daten aus, die im QR-Code enthalten sind. In diesem Beispiel extrahiert es die Transaktions-ID und die Serviceprovider-ID. Das Mobilgerät 2 empfängt vom POS-Endgerät 1 keine weiteren Angaben.

[0021] Als Nächstes sendet in Schritt 19 das Mobilgerät 2 die Transaktions-ID zusammen mit der Serviceprovider-ID aus dem QR-Code an den Serviceprovider des jeweiligen Benutzers und fordert somit auf, Informationen darüber zu erhalten, ob er willens ist, die Transaktion zu akzeptieren. In diesem Beispiel wird folgendes an den Serviceprovider-Server 32 des Benutzers gesendet: - Transaktions-ID: FAC4-ABCC-AFFA-0901

- Serviceprovider-ID: 01AB-1234-AF12-09AB

[0022] Da der Serviceprovider des Benutzers nicht der gleiche wie der Serviceprovider des POS ist, leitet der Serviceprovider-Server 32 des Benutzers in Schritt 21 dieses Beispiels die Anforderung einschliesslich der Transaktions-ID an den Serviceprovider des POS weiter. Der Serviceprovider-Server 32 des Benutzers weiss, welchen Serviceprovider er kontaktieren sollte, da er in Schritt 19 die Serviceprovider-ID erhalten hat.

[0023] In Reaktion auf die in Schritt 21 erhaltene Anforderung sendet der POS-Server 3Ί die Informationen, die sich auf die Transaktion in Schritt 23 beziehen, an den Serviceprovider-Server 32 des Benutzers. Diese Informationen enthalten die Daten, die in Schritt 11 an den POS-Server 3Ί gesendet wurden. In diesem Beispiel werden vom Serviceprovider-Server 32 des Benutzers folgende Information empfangen: - Transaktions-ID: FAC4-ABCC-AFFA-0901

- Serviceprovider-ID: 01AB-1234-AF12-09AB - Betrag: 150

- Währung: CHF - Produktbeschreibung: Buch: «The Art of Fly Fishing» [0024] Jetzt in Schritt 25 speichert der Serviceprovider-Server 32 des Benutzers die empfangenen Informationen, sodass sie später verwendet werden können. Im nächsten Schritt 27 leitet der Serviceprovider-Server 32 des Benutzers diese Informationen an das Mobilgerät 2 weiter. Wenn die Artikel oder Dienstleistung in Fremdwährung gekauft wurden, kann an das Mobilgerät 2 auch ein gültiger Wechselkurs gesendet werden. Dieser Wechselkurs kann auch an den POS-Server 3i in Schritt 15 gesendet werden, damit er dem Zahlungsempfänger angezeigt wird. Nun kann das Mobilgerät 2 die empfangenen Informationen anzeigen, sodass der Benutzer die relevanten Informationen in Bezug auf die Transaktion, die er zu akzeptieren plant, sehen kann. Es sei hier angemerkt, dass einige Informationen - wie beispielsweise der Preis - dem

Benutzer bereits in Klartext angezeigt worden sein können, zum Beispiel in Verbindung mit der Anzeige des QR-Codes. In diesem Beispiel wird somit dem Benutzer auf dem Display des Mobilgeräts 2 das Folgende angezeigt: - Betrag: 150

- Währung: CHF - Produktbeschreibung: Buch: «The Art of Fly Fishing» [0025] Nun kann der Anwender entscheiden, ob er mit der Transaktion fortfahren will oder nicht. Falls die Entscheidung positiv ausfällt, wird das Mobilgerät 2 in Schritt 29 an den Serviceprovider-Server 32 des Benutzers eine Transaktionsbestätigungsanforderung schicken. Diese Anforderung kann auch festlegen, wie der Benutzer für die Transaktion bezahlen möchte. Zum Beispiel kann der Benutzer hier festlegen, ob eine Kredit-, Bank-, Mitglieds- oder Prepaid-Karte belastet werden soll, oder, falls er eine Überweisung machen will, kann er seine Kontonummer angeben usw. Er könnte auch sein Passwort eingeben müssen. Die Notwendigkeit, ein Passwort einzugeben, kann von der Höhe der Transaktion oder den Leitlinien oder Regeln des jeweiligen Finanzinstituts abhängen. Wenn beispielsweise der Betrag einen bestimmten Schwellenwert übersteigt, wird ein Passwort erforderlich sein, damit die Zahlungstransaktion fortgesetzt werden kann. In der Anwendung kann auch eine Standardzahlungsmethode, zum Beispiel eine bestimmte Kredit-, Bank-, Mitglieds- oder Prepaid-Karte festgelegt sein. In dem Fall, dass der Benutzer keine Zahlungsmethode angibt, kann davon ausgegangen werden, dass der Benutzer die Standardzahlungsmethode verwendet, die seinem Serviceprovider bekannt ist. In diesem Beispiel wird dem Serviceprovider-Server 32 des Benutzers Folgendes gesendet; - Transaktions-ID: FAC4-ABCC-AFFA-0901 - Kreditgeber: Swiss Bank 001 - Passwort: ***** - Kontonummer: 1234 5678 9999 0 (im Falle eines Bankkontos wird die IBAN angegeben) [0026] Sobald der Serviceprovider-Server 32 des Benutzers die Transaktionsbestätigungsanforderung empfängt, bestimmt er den Inhalt der Anforderung und in Schritt 31 sendet er gemäss der Anforderung des Benutzers eine Zahlungstransaktionsanweisung mit wenigstens dem zu belastenden Betrag an ein Finanzinstitut. Diese Institution kann gemäss den Angaben, die in der Transaktion-Bestätigungsanforderung des Benutzers in Schritt 29 enthalten sind, z.B. eine Bank oder ein Kreditkartenunternehmen sein. In Schritt 33 belastet das Finanzinstitut das Konto des Benutzers mit einem Betrag, der dem Betrag der Transaktion entspricht. Es ist jedoch auch möglich, dass die Transaktion nicht durchgeführt, d.h., das Konto des Benutzers nicht belastet werden kann. Dies kann zum Beispiel passieren, wenn der Benutzer auf seinem Konto nicht über ausreichende Mittel verfügt, oder er sein Kreditkartenlimit oder seine monatliche oder jährliche Ausgabegrenze überschritten hat. In Schritt 35 sendet das Finanzinstitut an den Serviceprovider-Server 32 des Benutzers eine Statusmeldung der Abbuchungstransaktionen zurück. Wenn das Finanzinstitut in der Lage war, das Benutzerkonto zu belasten, wird die Statusmeldung der Abbuchungstransaktion eine positive Bestätigung sein, die den erfolgreichen Abschluss der Abbuchung anzeigt, gegebenenfalls auch den belasteten Betrag bestätigt und/oder zeigt, wie der Betrag belastet wurde. In diesem Beispiel können vom Finanzinstitut an den Serviceprovider-Server 32 des Benutzers die folgenden Informationen gesendet werden - Transaktions-ID: FAC4-ABCC-AFFA-0901

- Status: OK

[0027] In Schritt 36 aktualisiert der Serviceprovider-Server des Benutzers 32 seine Datenbank entsprechend, sodass in diesem Beispiel jetzt das Folgende in der Datenbank gespeichert werden kann: - Transaktions-ID: FAC4-ABCC-AFFA-0901

- Serviceprovider-ID: 01AB-1234-AF12-09AB - Betrag: 150

- Währung: CHF - Produktbeschreibung: Buch: «The Art of Fly Fishing»

- Zahler-Status: OK

[0028] Im Schritt 37 sendet der Serviceprovider-Server 32 des Benutzers eine Statusmeldung der Abbuchungstransaktionen an den POS-Server 3i. Dank der gespeicherten Informationen in Schritt 25 weiss der Serviceprovider-Server 3^ des Benutzers, welchen POS-Server 3i er kontaktieren sollte. Sobald der POS-Server 3i die Statusmeldung der Abbuchungstransaktion empfangen hat und anzeigt, dass dem Benutzer der Betrag belastet wurde, kann er nun in Schritt 39 an das Finanzinstitut des Zahlungsempfängers eine Anforderung senden, ihn dem Konto des Zahlungsempfängers gutzuschreiben. Zuvor wurden dem Serviceprovider des Zahlungsempfängers das Finanzinstitut des Zahlungsempfängers, die Bankkontodaten usw. mitgeteilt. Im nächsten Schritt 41 schreibt das Finanzinstitut dem Konto des Zahlungsempfängers den Transaktionsbetrag gut. Damit dies möglich ist, müssen die Finanzinstitute des Zahlungsempfängers und des Benutzers miteinander kommunizieren können. Als nächstes wird in Schritt 43 die Statusmeldung der Kredittransaktion vom Finanzinstitut des Zahlungsempfängers an den POS-Server 3i gesendet. Wenn die Gutschrift erfolgreich war, bestätigt die Statusmeldung der Kredittransaktion, dass die Transaktion erfolgreich war, andernfalls wird eine negative Statusmeldung der Kredittransaktion gesendet. Jetzt in diesem Beispiel hat der POS-Server3-i in der Datenbank die folgenden Informationen gespeichert: - Transaktions-ID: FAC4-ABCC-AFFA-0901 - Betrag: 150

- Währung: CHF - Produktbeschreibung: Buch: «The Art of Fly Fishing»

- Zahler-Status: OK - Kontonummer: CH01 0000 1234 1234 1234 5

- Zahlungsempfänger-Status: OK

[0029] Danach informiert der POS-Server 3Ί in Schritt 45 das POS-Endgerät 1 über die Statusmeldung der Kredittransaktion, sodass dieses Unternehmen das Produkt liefern oder die Dienstleistung für den Benutzer durchführen kann. In Schritt 47 informiert der POS-Server 3Ί den Serviceprovider-Server 32 des Benutzers über den Zahlungstransaktionsstatus, der wiederum den Benutzer über den Zahlungstransaktionsstatus in Schritt 49 informiert. In diesem Beispiel wird somit die folgende Information in der Datenbank des Serviceprovider-Servers 32 des Benutzers gespeichert und auch an den Benutzer gesendet: - Transaktions-ID: FAC4-ABCC-AFFA-0901

- Serviceprovider-ID: 01AB-1234-AF12-09AB - Betrag: 150

- Währung: CHF - Produktbeschreibung: Buch: «The Art of Fly Fishing»

- Zahler-Status: OK

- Zahlungsempfänger-Status: OK

[0030] Es ist auch möglich, dass der Zahlungsempfänger und/oder der Benutzer den Zahlungstransaktionsstatus anfordert. Der Zahlungsempfänger kann diese Informationen unmittelbar vom POS-Server 3Ί anfordern, während der Benutzer diese Informationen vom Serviceprovider-Server 32 des Benutzers anfordern kann. Diese Anforderungen enthalten zumindest die Transaktions-ID. Einige andere Informationen, wie beispielsweise die Identität des POS, kann auch gesendet werden. Es ist dem Zahlungsempfänger auch möglich, den Zahlungstransaktionsstatus zu bestimmen, indem er seine Bankkontotransaktionen verfolgt.

[0031] Die obigen Lehren können nicht nur in einfache Kauftransaktionen, sondern auch nutzbringend in andere Anwendungen implementiert werden. Zum Beispiel kann das Endgerät 1 ein Geldautomat sein. In diesem Fall möchte der Benutzer aus dem Geldautomaten etwas Bargeld ziehen. Dementsprechend wählt der Benutzer wie üblich erst den Betrag, den er ziehen möchte. Jedoch gemäss der vorliegenden Erfindung kann der Geldautomat dann dem Geldautomatenbenutzer einen Strichcode anzeigen, wie zum Beispiel einen QR-Code. Zum Beispiel kann jeder Bargeldabhebung eine Transaktions-ID zugeordnet werden. Die Bargeldabhebung kann den Prinzipien folgen, die im Zusammenhang mit der Beschreibung des Ablaufplans in Abb. 2 erklärt wurden. Jedoch kann der Benutzer aufgefordert werden, die Abhebung vor Ort am Geldautomaten zu bestätigen, beispielsweise per Knopfdruck oder über das Eingabesystem des Geldautomaten. Gemäss dieser Anwendung muss der Benutzer bei Nutzung des Geldautomaten weder Passwort noch persönliche Identifikationsnummer (PIN) eingeben. Dadurch werden Betrugsmöglichkeiten reduziert.

[0032] Die Lehren der Erfindung können auch zum Online-Shopping im Internet verwendet werden. In diesem Fall kann der Strichcode durch einen Internet-Browser angezeigt werden. Der Benutzer kann auch aufgefordert werden, eine Lieferadresse für die Produkte einzugeben, die er oder sie kauft. Die Lieferadresse kann jederzeit während des Transaktionsverlaufs an den Zahlungsempfänger gesendet werden. Das Verfahren folgt den Prinzipien des Ablaufplans in Abb. 2.

[0033] Die Lehren der Erfindung können auch auf eine Situation angewendet werden, in der das Endgerät 1 ein tragbares drahtloses Kommunikationsgerät ist, wie beispielsweise ein Smartphone. In dieser Anwendung kann der Benutzer des tragbaren Geräts der Zahlungsempfänger sein, während der Benutzer eines zweiten tragbaren drahtlosen Kommunikationsgeräts der Zahler ist. Der Barcode beinhaltet die Transaktions-ID, und die Serviceprovider-ID des Zahlungsempfängers kann somit auf dem Gerätebildschirm des Zahlungsempfängers angezeigt werden. Wieder folgt das Verfahren den Prinzipien, die oben in Verbindung mit dem Ablaufplan der Abb. 2 beschrieben sind. Das Endgerät 1 kann einfach ein Poster sein, das einen Barcode-wie einen QR-Code-zeigt. In dem Fall könnte die gleiche Transaktions-ID von mehreren Benutzern verwendet werden. Es kann auch notwendig sein, für bestimmte Arten gekaufter Produkte dem Zahlungsempfänger eine Lieferadresse zur Verfügung zu steilen. Die Prinzipien des obigen Ablaufplans gelten bei dieser besonderen Anwendung ebenfalls.

[0034] Die vorliegende Erfindung kann zum Beispiel auch bei Drehkreuzen angewendet werden, die den Zugang zu einer U-Bahn oder zu einem Zug gewähren. In dieser Anwendung kann ein Barcode am Drehkreuz gezeigt werden, das sich nur dann öffnet, wenn ein Zahlungsvorgang erfolgreich abgeschlossen wurde. Die Lehren der vorliegenden Erfindung gelten auch, wenn das Endgerät 1 ein Ticket wie eine Konzert-, Flug-, Bahnkarte usw. ist. In diesem Fall kann der Barcode auf das Ticket aufgedruckt werden und sobald eine erfolgreiche Transaktion abgeschlossen ist, kann der Abschlussstatus der Transaktion in einer Datenbank gespeichert werden, um sicherzustellen, dass das Ticket kein zweites Mal verkauft und dazu verwendet werden kann, ein entsprechendes Ereignis zu besuchen oder ein Transportmittel zu betreten.

[0035] Es ist auch möglich, die Lehren der vorliegenden Erfindung an Tankstellen anzuwenden. In diesem Fall kann der Benutzer einen festen Geldbetrag wählen, sagen wir 100 in einer lokalen Währung, und wenn der Benutzer nicht in der Lage ist, die Menge an Kraftstoff zu tanken, die diesem Befrag entspricht, kann das Restgeld auf das Konto des Benutzers erstattet werden. Die Erstattung kann automatisch oder auf Antrag erfolgen. Sobald das Verfahren des Ablaufplans von Abb. 2 beendet worden ist, kann das Endgerät.1 zum Beispiel den Serviceprovider-Server 3Ί des Benutzers kontaktieren, um das Erstattungsverfahren einzuleiten. In dieser Situation können die beiden beteiligten Provider miteinander und mit den relevanten Finanzinstituten kommunizieren, um das Erstattungsverfahren abzuschliessen. Wieder kann eine Statusbestätigung der Erstattungstransaktion an den Zahlungsempfänger und/oder an den Zahler gesendet werden, um sie über das Ergebnis der Erstattungstransaktion zu informieren.

[0036] Während die Erfindung in den Zeichnungen und der vorstehenden Beschreibung im Detail beschrieben und veranschaulicht wurde, müssen diese Darstellung und Beschreibung als illustrativ oder beispielhaft und nicht als einschränkend erwogen werden, da die Erfindung nicht auf die offengelegte Ausführungsform beschränkt ist. Andere Ausführungsformen und Varianten werden nachvollzogen und können durch Fachleute erreicht werden, wenn die beanspruchte Erfindung basierend auf einer Studie der Zeichnungen, der Offenlegung und der beigefügten Ansprüche ausgeführt wird. Zum Beispiel kann das vorgeschlagene Verfahren auch dazu verwendet werden, um einen Ort, ein Produkt oder eine Dienstleistung zu reservieren. Die tatsächliche Zahlungstransaktion muss nicht unbedingt sofort, sondern kann auch später erfolgen. Das vorgeschlagene sichere Transaktionsverarbeitungsverfahren könnte auch bei diesen Anwendungsverfahren verwendet werden. Es ist auch möglich, dass der POS-Server 3Ί und der Serviceprovider-Server 32 des Benutzers nicht direkt, sondern über ein anderes Netzwerkelement miteinander kommunizieren. In diesem Fall würde sowohl der POS-Server 3i als auch der Serviceprovider-Server 32 des Benutzers mit diesem anderen Netzwerkelement eine vertrauenswürdige Kommunikation führen. In dieser Situation müssen jedoch weder der POS-Server 3Ί noch der Serviceprovider-Server 32 des Benutzers miteinander eine vertrauenswürdige Kommunikation aufbauen.

[0037] In den Ansprüchen schliesst das Wort «aufweist» andere Elemente oder Schritte nicht aus, und der unbestimmte Artikel «ein» oder «eine» schliesst nicht deren Mehrzahl aus. Die blosse Tatsache, dass verschiedene Merkmale in untereinander verschiedenen abhängigen Ansprüchen genannt werden, bedeutet nicht, dass eine Kombination dieser Merkmale nicht in vorteilhafter Weise verwendet werden kann. Etwaige Bezugszeichen in den Ansprüchen sollten nicht als Einschränkung des Umfangs der Erfindung ausgelegt werden.

Claims

Patentansprüche

1. Verfahren zur Verarbeitung einer Transaktion zwischen einer ersten Transaktionspartei und einer zweiten Transaktionspartei in einem Kommunikationssystem, das einen ersten Serviceprovider-Server (3i), mit dem die erste Transaktionspartei kommunizieren kann, und einen zweiten Serviceprovider-Server (3^), mit dem die zweite Transaktionspartei mittels eines tragbaren drahtlosen Kommunikationsgeräts (2) eine Trusted-Path-Kommunikation aufbauen kann, aufweist, wobei das Verfahren aufweist: - der zweite Serviceprovider-Server (32) empfängt (19) vom tragbaren drahtlosen Kommunikationsgerät (2) eine Transaktionskennung und eine Serviceprovider-Kennung der ersten Transaktionspartei, wobei die Serviceprovider-Kennung der ersten Transaktionspartei den ersten Serviceprovider-Server (3i) identifiziert; - der zweite Serviceprovider-Server (32) fordert Transaktionsdaten vom durch die Serviceprovider-Kennung der ersten Transaktionspartei identifizierten ersten Serviceprovider-Server (30 an; - der zweite Serviceprovider-Server (32) empfängt (23) die angeforderten Transaktionsdaten; - der zweite Serviceprovider-Server (32) überträgt (27) die Transaktionsdaten auf das tragbare drahtlose Kommunikationsgerät (2); und - der zweite Serviceprovider-Server (32) empfängt (29) vom tragbaren drahtlosen Kommunikationsgerät (2) eine Transaktionsbestätigungsanforderung.
2. Verfahren gemäss Anspruch 1, wobei das Kommunikationssystem ferner ein Netzwerk von Kommunikationsverbindungen zwischen Servern mindestens einer Bank, nachstehend Bankennetzwerk genannt, (4) aufweist, und wobei in Reaktion auf die Transaktionsbestätigungsanforderung der zweite Serviceprovider-Server (32) dem Bankennetzwerk (4) eine Zahlungsanweisung ausstellt (31).
3. Verfahren gemäss Anspruch 1 oder 2, wobei das Kommunikationssystem ferner eine durch die erste Transaktionspartei betreibbare Transaktionseinheit (1) aufweist und wobei das Verfahren ferner aufweist: der erste Serviceprovider-Server (3i) empfängt (11) von der Transaktionseinheit (1) eine Anforderung, eine Transaktionskennung auszustellen.
4. Verfahren gemäss Anspruch 3, wobei der erste Serviceprovider-Server (3Ί) ferner die Transaktionsdaten von der Transaktionseinheit (1) empfängt (11).
5. Verfahren gemäss Anspruch 4, wobei das Verfahren ferner aufweist: der erste Serviceprovider-Server (3Ί), in Reaktion auf die empfangene Anforderung, stellt die Transaktionskennung aus (13), und überträgt (15) die Transaktionskennung an die Transaktionseinheit (1).
6. Verfahren gemäss einem der Ansprüche 2 oder 3, wobei das Kommunikationssystem ferner eine durch die erste Transaktionspartei betreibbare Transaktionseinheit (1) aufweist und wobei das Verfahren ferner aufweist: das tragbare drahtlose Kommunikationsgerät (2) empfängt (17) von der Transaktionseinheit (1) die Transaktionskennung und die Serviceprovider-Kennung der ersten Transaktionspartei.
7. Verfahren gemäss Anspruch 6, wobei die Transaktionskennung und die Serviceprovider-Kennung der ersten Transaktionspartei von dem tragbaren drahtlosen Kommunikationsgerät (1) empfangen werden, indem das tragbare drahtlose Kommunikationsgerät (1) einen Barcode scannt (17), der von der Transaktionseinheit (1) angezeigt wird.
8. Verfahren gemäss einem der vorhergehenden Ansprüche, wobei die Transaktionskennung, zusammen mit der Ser-viceprovider-Kennung der ersten Transaktionspartei, eine eindeutige Identität darstellt.
9. Serviceprovider-Server (32), nachstehend zweiter Serviceprovider-Server (32) genannt, zur Verarbeitung einer Transaktion zwischen einer ersten Transaktionspartei und einer zweiten Transaktionspartei in einem Kommunikationssystem, das ferner einen anderen Serviceprovider-Server (3), nachstehend erster Serviceprovider-Server (30 genannt, aufweist, mit dem die erste Transaktionspartei kommunizieren kann, wobei der zweite Serviceprovider-Server (32) mittels eines tragbaren drahtlosen Kommunikationsgeräts (2) eine Trusted-Path-Kommunikation mit der zweiten Transaktionspartei aufbauen kann, wobei der zweite Serviceprovider-Server (32) aufweist: - Empfangsmittel zum Empfangen einer Transaktionskennung und einer Serviceprovider-Kennung der ersten Transaktionspartei, welche Serviceprovider-Kennung den ersten Serviceprovider-Server (30 identifiziert vom tragbaren drahtlosen Kommunikationsgerät (2); - Anforderungsmittel zur Anforderung von Transaktionsinformationen vom ersten Serviceprovider-Server (3i) - identifiziert durch die Serviceprovider-Kennung der ersten Transaktionspartei; -wobei das/die Empfangsmittel zum Empfangen der angeforderten Transaktionsinformationen ausgebildet ist/sind; - Übertragungsmittel zur Übertragung der Transaktionsinformationen an das tragbare drahtlose Kommunikationsgerät (2); und - wobei das/die Empfangsmittel zum Empfangen einer Transaktionsbestätigungsanforderung vom tragbaren drahtlosen Kommunikationsgerät (2) ausgebildet ist/sind.
10. Kommunikationssystem, das einen ersten Serviceprovider-Server (3Ί), mit dem eine erste Transaktionspartei kommunizieren kann, einen zweiten Serviceprovider-Server (32) gemäss Anspruch 9, und ein tragbares drahtloses Kommunikationsgerät (2) aufweist, wobei eine zweite Transaktionspartei mittels des tragbaren drahtlosen Kommunikationsgeräts (2) eine Trusted-Path-Kommunikation mit dem zweiten Serviceprovider-Server (32) aufbauen kann.