DE102014017710A1 - Erstellen einer Rechnung aus einem statischen und einen dynamischen Teil eines Transaktionsdatensatzes - Google Patents

Erstellen einer Rechnung aus einem statischen und einen dynamischen Teil eines Transaktionsdatensatzes Download PDF

Info

Publication number
DE102014017710A1
DE102014017710A1 DE102014017710.6A DE102014017710A DE102014017710A1 DE 102014017710 A1 DE102014017710 A1 DE 102014017710A1 DE 102014017710 A DE102014017710 A DE 102014017710A DE 102014017710 A1 DE102014017710 A1 DE 102014017710A1
Authority
DE
Germany
Prior art keywords
transaction
dat
bill
transaction data
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
DE102014017710.6A
Other languages
English (en)
Inventor
Jens Hohmann
Henning Daum
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Giesecke and Devrient GmbH
Original Assignee
Giesecke and Devrient GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke and Devrient GmbH filed Critical Giesecke and Devrient GmbH
Priority to DE102014017710.6A priority Critical patent/DE102014017710A1/de
Publication of DE102014017710A1 publication Critical patent/DE102014017710A1/de
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/42—User authentication using separate channels for security data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3276—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being read by the M-device
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3215—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a plurality of channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/102—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measure for e-commerce

Abstract

Die Erfindung schafft System zum Erstellen einer Rechnung ausgehend von einem Transaktionsdatensatz (DAT), der einen statischen Teil (stat) und einen dynamischen Teil (dyn) umfasst, wobei mit der Rechnung ein Rechnungssteller zur Durchführung einer Zahlungsverkehrs-Transaktion auffordert, und wobei das System einen Rechnungssteller-Computer (HS) umfasst, sowie einen Transaktionsdatenserver (PS), auf dem der Transaktionsdatensatz (DAT) zum Erstellen der Rechnung bereitstellbar ist. Über einen ersten Kommunikations-Kanal (C1) zwischen dem Rechnungssteller-Computer und dem Transaktionsdatenserver (PS), ist der statische Teil (stat) des Transaktionsdatensatzes (DAT) veränderbar. Über einen zweiten Kommunikation-Kanal (C2) zwischen dem Rechnungssteller-Computer (HS) und dem Transaktionsdatenserver (PS) ist der dynamische Teil (dyn) des Transaktionsdatensatzes (DAT) veränderbar.

Description

  • Die Erfindung betrifft ein System zum Erstellen einer Rechnung ausgehend von einem Transaktionsdatensatz, der einen statischen Teil und einen dynamischen Teil umfasst, gemäß dem Oberbegriff von Anspruch 1, ein Verfahren zum Bearbeiten einer Rechnungsinfrastruktur zum Erstellen von Rechnungen in dem System, sowie ein Verfahren zum Erstellen einer Rechnung in dem System.
  • Der Transaktionsdatensatz einer Rechnung umfasst einen statischen Teil, der sich höchstens selten ändert, wie z. B. Händlername, Kontonummer, Bank des Rechnungsstellers. Daneben umfasst der Transaktionsdatensatz einer Rechnung einen dynamischen Teil, der in der Regel für jede Rechnung neu festzulegen ist, z. B. Rechnungsempfänger (häufig der nachfolgende Zahlungsleistende), Betrag, Referenz (z. B. Rechnungsnummer, Kundennummer) und dergleichen spezifische Daten.
  • Im Online-Handel besteht für einen verkaufenden Händler die Notwendigkeit, einem kaufenden Kunden eine durch einen Transaktionsdatensatz dargestellte Rechnung zukommen zu lassen, so dass der Kunde den Händler bezahlen kann. In diesem Szenario hat der Händler die Rolle eines Rechnungsstellers inne, und der Kunde die Rolle eines Rechnungsempfängers.
  • Der Händler/Rechnungssteller stellt den Transaktionsdatensatz auf einem Server (Transaktionsdatenserver) bereit. Bei der direktesten Lösung sendet der Rechnungssteller dem Rechnungsempfänger den Transaktionsdatensatz, beispielsweise gedruckt auf einer Papierrechnung. Bei der weiteren Lösung sendet der Rechnungssteller dem Rechnungsempfänger eine Zugriffsinformation (z. B. URL = Uniform Ressource Locator), kurz Link genannt, auf den Transaktionsdatensatz zu, mittels welcher der Rechnungsempfänger den Transaktionsdatensatz vom Server herunterladen kann. Weiter ist es bekannt, eine solche Zugriffsinformation (URL) in ein maschinenlesbares Merkmal zu codieren, z. B. in einen 2D-Barcode. Das maschinelesebare Merkmal wird z. B. auf eine Papierrechnung aufgedruckt, die dem Rechnungsempfänger zugestellt wird.
  • Statt in Papierform oder zusätzlich zur Papierform können Rechnung, maschinenlesbares Merkmal (z. B. 2D-Barcode) oder/und Zugriffsinformation (URL) einem Rechnungsempfänger in elektronischer Form bereitgestellt werden, insbesondere auf sein mobiles Endgerät (Smartphone, Tablet PC) gesendet werden.
  • Um die Durchführung der Zahlungsverkehrs-Transaktion zu veranlassen, erfasst (fotografiert, scannt, empfängt in elektronischer Form) der Zahlungsempfänger das maschinenlesbare Merkmal z. B. mit einem Endgerät wie z. B. Smartphone, Tablet-PC etc., decodiert es und erhält hierdurch die Zugriffsinformation (URL). Mittels der Zugriffsinformation lädt der Rechnungsempfänger den Transaktionsdatensatz vom Händlerserver in sein Endgerät.
  • Sobald der Rechnungsempfänger die Transaktionsdaten in sein Endgerät geladen hat, bestätigt er den Transaktionsdatensatz und veranlasst hierdurch die Durchführung der Zahlungsverkehrs-Transaktion.
  • Der Händlerserver des Rechnungsstellers ist, sofern er eine Verbindung zum Internet hat, Angriffen ausgesetzt, durch welche bei der Rechnungserstellung der Transaktionsdatensatz manipuliert werden könnte. Insbesondere könnte ein Angreifer im Transaktionsdatensatz unbemerkt das Empfängerkonto oder dergleichen statische Transaktionsdaten ändern. Hierdurch würden alle nachfolgend erzeugten Rechnungen unbemerkt zu Zahlungen auf ein falsches Konto auffordern.
  • Eine direkte Lösung des Problems bestünde darin, den Händlerserver des Rechnungsstellers niemals mit dem Internet zu verbinden. Allein schon Betriebssystems-Updates waren bei dieser Lösung stark erschwert, so dass diese direkte Lösung Nachteile hat.
  • Der Erfindung liegt die Aufgabe zu Grunde, ein sicheres System und Verfahren zur Rechnungserstellung schaffen.
  • Die Aufgabe wird gelöst durch ein System nach Anspruch 1. Zwei einander ergänzende Teil-Verfahren bei der Rechnungserstellung sind in den Ansprüchen 6 und 7 angegeben. Vorteilhafte Ausgestaltungen der Erfindung sind in den abhängigen Ansprüchen angegeben.
  • Das Erstellen einer Rechnung im System erfolgt ausgehend von einem Transaktionsdatensatz, der einen statischen Teil und einen dynamischen Teil umfasst. Mit der Rechnung fordert ein Rechnungssteller (Händler) zur Durchführung einer Zahlungsverkehrs-Transaktion auf. Das System umfasst zur Rechnungserstellung einen Händlerserver des Rechnungsstellers.
  • Gemäß der Erfindung umfasst das System zusätzlich zum lokalen Händlerserver einen Transaktionsdatenserver, auf dem der Transaktionsdatensatz zum Erstellen der Rechnung bereitstellbar ist. Zwischen dem Händlerserver und dem Transaktionsdatenserver ist ein erster Kommunikations-Kanal betreibbar, über den der statische Teil des Transaktionsdatenatzes vom Rechnungssteller-Computer aus am Transaktionsdatenserver veränderbar ist. Weiter ist zwischen dem Händlerserver und dem Transaktionsdatenserver ein zweiter Kommunikations-Kanal betreibbar, über den der dynamische Teil des Transaktionsdatenatzes vom Händlerserver aus am Transaktionsdatenserver veränderbar ist, über den der statische Teil des Transaktionsdatensatzes hingegen vom Händlerserver aus am Transaktionsdatenserver nicht veränderbar ist.
  • Die Rechnungserstellung erfolgt somit nicht am lokalen Händlerserver, sondern auf einem entfernten Transaktionsdatenserver, der mit dem Händlerserver über ein Kommunikationsnetz (wahlweise drahtgebunden oder drahtlos) verbindbar ist. Der Händlerserver dient nur als Terminal zum Zugriff auf den Transaktionsdatenserver. Ein professioneller Betreiber eines solchen Transaktionsdatenservers hat häufig umfassendere Möglichkeiten Sicherheitsmaßnahmen vorzusehen als ein lokaler Händler für seinen Händlerserver.
  • Dadurch, dass sich bei dem Verfahren nach Anspruch 1 die statischen Transaktionsdaten über den zur Rechnungserstellung eingerichteten zweiten Kommunikations-Kanal nicht verändern lassen, können durch Manipulationen bei der Rechnungserstellung höchsten die dynamischen Daten verändert werden, z. B. also die Höhe des Betrags. Ein Umleiten einer Zahlung auf ein falsches Konto ist hingegen nicht möglich, da die statischen Transaktionsdaten nicht veränderbar sind.
  • Folglich ist gemäß Anspruch 1 ein sicheres System zur Rechnungserstellung geschaffen.
  • Wahlweise wird das maschinenlesbare Merkmal (z. B. 2D-Barcode, QR-Code, RFID-Etikett etc.) in durch das Mobilgerät erfassbarer Weise bereitgestellt und durch das Mobilgerät erfasst. Insbesondere wird das maschinenlesbare Merkmal wahlweise aufgedruckt auf einer Rechnung zur Zahlungsverkehrs-Transaktion bereitgestellt, auf an sich bekannte Weise. Alternativ kann das maschinenlesbare Merkmal (z. B. 2D-Barcode, QR-Code etc.) auf einem Display des Mobilgeräts dargestellt werden.
  • Wahlweise ist nur ein einziger Kommunikations-Kanal von dem ersten und dem zweiten Kommunikations-Kanal auf einmal betreibbar ist. Hierdurch ist eine besonders zuverlässige Trennung der beiden Kommunikations-Kanäle sichergestellt
  • Wahlweise umfasst der statische Teil sicherheitskritische Transaktionsdaten, insbesondere Kontoverbindungsdaten eines Zielkontos der Zahlungsverkehrs-Transaktion. Für diese Daten ist es besonders wichtig, dass sie vor Manipulation geschützt sind und nur über den ersten Kanal zugänglich sind.
  • Wahlweise sind der erste und der zweite Kommunikations-Kanal über unterschiedliche Zugriffsdaten geschützt. Beispielsweise müssen für Login für den ersten und den zweiten Kommunikations-Kanal unterschiedliche Login-Sätze von Benutzername und Passwort eingegeben werden. Wahlweise ist der erste Kommunikations-Kanal, über den sich die statischen Transaktionsdaten ändern lassen, über Zugriffsdaten geschützt, die eine höheres Maß an Sicherheit bieten als die Zugriffsdaten für den weniger kritischen zweiten Zugriffskanal.
  • Dankbar ist, dass über den ersten Kommunikationskanal umfassendere Bearbeitungsrechte vorgesehen sind als über den zweiten. Dies würde erlauben, statische Daten zu bearbeiten und in derselben Login-Sitzung eine vollständige Rechnung zu erstellen. Vorzugsweise sind jedoch über den ersten Kommunikations-Kanal keine Rechnungen erstellbar und über den zweiten Kommunikations-Kanal Rechnungen erstellbar, insbesondere durch Einfügen von dynamischen Transaktionsdaten. Hierdurch wird eine stringente Trennung der Bearbeitungsmöglichkeiten für statische und dynamische Daten verwirklicht.
  • Das in Anspruch 6 angegebene erfindungsgemäße Verfahren zum Bearbeiten einer Rechnungsinfrastruktur zum Erstellen von Rechnungen, jeweils ausgehend von einem Transaktionsdatensatz, ist gekennzeichnet durch die Schritte: Betreiben des ersten Kommunikations-Kanal zwischen dem Händlerserver und dem Transaktionsdatenserver; und Bearbeiten, insbesondere Neu-Erstellen oder/und Ändern, des statischen Teils des Transaktionsdatensatzes vom Händlerserver aus am Transaktionsdatenserver. Ein Erstellen vollständiger Rechnungen ist hierbei vorzugsweise nicht möglich.
  • Das in Anspruch 7 angegebene erfindungsgemäße Verfahren zum Erstellen einer Rechnung ausgehend von einem Transaktionsdatensatz ist gekennzeichnet durch die Schritte: Bereitstellen des statischen Teils des Transaktionsdatensatzes auf dem Transaktionsdatenserver; Betreiben des zweiten Kommunikations-Kanal zwischen dem Händlerserver und dem Transaktionsdatenserver; Bearbeiten, insbesondere Neu-Erstellen oder/und Ändern, des dynamischen Teils des Transaktionsdatensatzes vom Händlerserver aus am Transaktionsdatenserver; Zusammenführen des statischen und des dynamischen Teils des Transaktionsdatensatzes zum Transaktionsdatenatz; und Erstellen der Rechnung mit dem Transaktionsdatensatz. Eine Änderung des statischen Teils ist hierbei nicht möglich.
  • Wahlweise umfasst das Verfahren zum Erstellen einer Rechnung weiter die Schritte: Erstellen einer Zugriffsinformation (z. B. URL), die ein Zugreifen auf den auf dem Transaktionsdatenserver hinterlegten Transaktionsdatenatz der erstellten Rechnung ermöglicht; Bereitstellen der Zugriffsinformation an einen Rechnungsempfänger, als Aufforderung an den Rechnungsempfänger zur Durchführung Zahlungsverkehrs-Transaktion gemäß der Rechnung. Vorzugsweise wird die Zugriffsinformation durch den oder zumindest auf Veranlassung des Transaktionsdatenserver(s) erzeugt. Die Zugriffsinformation ermöglicht es dem Rechnungsempfänger, die Transaktionsdaten zu ermitteln und gemäß ihnen die Rechnung zu bezahlen.
  • Wahlweise umfasst das Verfahren weiter die Schritte: Erstellen, vorzugsweise durch den Transaktionsserver (oder auf seine Veranlassung), eines maschinenlesbaren Merkmals, insbesondere 2D-Barcodes oder RFID-Etiketts, ausgehend von der Zugriffsinformation; Bereitstellen des maschinenlesbaren Merkmals an den Rechnungsempfänger, um die Zugriffsinformation an ihn bereitzustellen.
  • Ein erfindungsgemäßes Verfahren zur Veranlassung der Durchführung einer Zahlungsverkehrs-Transaktion ist gekennzeichnet durch die Schritte:
    • a) Entgegennehmen, durch ein mobiles Endgerät des Rechnungsempfängers, einer bereitgestellten Zugriffsinformation;
    • b) Übermitteln der Zugriffsinformation vom Endgerät des Rechnungsempfängers an den Transaktionsdatenserver;
    • c) beim Transaktionsdatenserver, Bereitstellen des Transaktionsdatensatzes an das Endgerät des Rechnungsempfängers;
    • d) beim Endgerät des Rechnungsempfängers Bestätigen des Transaktionsdatensatzes, um die Durchführung der Zahlungsverkehrs-Transaktion zu veranlassen.
  • Wahlweise wird in Schritt c) beim Transaktionsdatenserver zusätzlich ein Authentisierungsschritt durchgeführt, in welchem überprüft wird, ob der Rechnungsempfänger zum Empfang des Transaktionsdatensatzes berechtigt ist, und nur falls dies der Fall ist, das Bereitstellen des Transaktionsdatensatzes an das Endgerät des Rechnungsempfängers durchgeführt wird. Wahlweise wird die Authentisierung an Hand einer Signatur durchgeführt. Ein Verfahren zur Erstellung einer Rechnung, die eine Authentisierung mittels Signatur ermöglicht, ist Gegenstand einer weiteren Patentanmeldung derselben Anmelderin.
  • Wahlweise ist dem Transaktionsdatensatz ein durch den Transaktionsdatenserver erzeugter oder erzeugbarer Identifikator (eine ID) zugeordnet. Anlässlich eines Bereitstellens oder Übermitteln von Transaktionsdaten zwischen dem Transaktionsserver und dem Endgerät des Rechnungsempfängers wird dabei auch der Identifikator bereitgestellt bzw. übermittelt. Der Identifikator wird wahlweise beim Transaktionsdatenserver verwendet, für eine Rechnung, deren Zugriffsinformation er von einem Endgerät zugesandt bekommt, den richtigen Transaktionsdatensatz zu identifizieren.
  • Im Folgenden wird die Erfindung an Hand von Ausführungsbeispielen und unter Bezugnahme auf die Zeichnung näher erläutert, in der zeigen:
  • 1 einen in einen dynamischen Teil und einen statischen Teil aufgeteilten Satz von Transaktionsdaten und einen zum dynamischen Teil gebildeten 2D-Barcode, gemäß einer Ausführungsform der Erfindung;
  • 2 einen Kommunikationsvorgang zwischen einem Händler-Server und einem Server eines Provisioning Service;
  • 3 einen Kommunikationsvorgang mit Durchführung einer Zahlungsverkehrstransaktion, gemäß einer Ausführungsform der Erfindung.
  • 1 zeigt einen in einen dynamischen Teil dyn und einen statischen Teil stat aufgeteilten Satz von Transaktionsdaten DAT, gemäß einer Ausführungsform der Erfindung. Der dynamische Teil dyn und der statische Teil stat ergeben zusammengefügt den gesamten Transaktionsdatensatz DAT.
  • 2 zeigt einen Kommunikationsvorgang zwischen einem Händler-Server HS und, als Transaktionsdatenserver PS eines Provisioning Service, im Admin-Zugang-Modus. Im Admin-Modus ist ein erster Kommunikations-Kanal C1 zwischen dem Händler-Server HS und dem Transaktionsdatenserver PS in Betrieb, der es dem Händler (Rechnungssteller) ermöglicht, die statischen Transaktionsdaten zu bearbeiten und so z. B. Konten für die nachfolgende Erstellung von Rechnungen einzurichten. Rechnungen selbst können im Admin-Modus, über den ersten Kanal C1, nicht erstellt werden.
  • 3 zeigt einen Kommunikationsvorgang mit Durchführung einer Zahlungsverkehrs-Transaktion, gemäß einer Ausführungsform der Erfindung, im User-Zugang-Modus. Im User-Zugangs-Modus kann der Händler einzelne Rechnungen erstellen, aber nicht seine Händlerkontodaten, d. h. die statischen Transaktionsdaten stat, ändern. Die Zahlungsverkehrs-Transaktion hat das Ziel, dass ein Rechnungsempfänger E (d. h. der Käufer) für gekaufte Ware einen in einer Rechnung bestimmten Betrag auf ein Händlerkonto des Rechnungsstellers, in der Regel des Händlers, bezahlt. Der Vorgang umfasst die folgenden Schritte. (1) Der Händler erstellt eine Rechnung, die durch Transaktionsdaten DAT bestimmt ist. Die Transaktionsdaten umfassen einen dynamischen Teil dyn, hier Referenz und Betrag, und einen statischen Teil stat, hier Empfängerkonto, Händlerkonto. (2) Der Händler meldet sich mit User-Kennung und User-Passwort am Transaktionsdatenserver PS des Provisioning Service an. (3) Der Händler überträgt die dynamischen Transaktionsdaten Referenz und Betrag an den Provisioning Server PS. (4) Der Transaktionsdatenserver PS erzeugt eine eindeutige ID zu den empfangenen dynamischen Transaktionsdaten Referenz und Betrag und (5) speichert die ID und die dynamischen Transaktionsdaten Referenz und Betrag. Zudem fügt der Transaktionsdatenserver die zur Rechnung gehörigen statischen Transaktionsdaten stat an, um den Transaktionsdatensatz DAT zu komplettieren. (6) Der Provisioning Server PS erzeugt eine Zugriffsinformation URL des Provisioning Service zum Zugreifen auf die Transaktionsdaten DAT, sowie mittels eines kryptographischen Schlüssels Key eine Signatur SIGN über URL und ID. (7) Der Provisioning Server sendet URL, ID und die Signatur SIGN an den Händler-Server des Händlers. (8) Der Händler erzeugt eine Papier-Rechnung sowie aus URL, ID und SIGN einen 2D-Barcode, den er auf die Rechnung aufdruckt. (9) Der Händler sendet die Ware und die Rechnung an den Käufer (= Zahlenden = Empfänger). (10) Der Käufer/Empfänger fotografiert den 2D-Barcode mit seinem Mobilgerät („Mobile”). (11) Der Käufer decodiert den 2D-Barcode im Mobilgerät und extrahiert so die Zugriffsinformation URL, den Identifikator ID und die Signatur SIGN und (12) überträgt die extrahierte Information URL, ID, SIGN an eine im Mobilgeräte implementierte sichere Ausführungsumgebung, z. B. ein Secure Element SE (z. B. SIM-Karte, eUICC etc.) oder eine sichere Laufzeitumgebung „Trusted Execution Environment” TEE im Mobilgerät-Chip selbst. (13) Die sichere Ausführungsumgebung TEE stellt eine Verbindung zum Server her, und die sichere Ausführungsumgebung TEE und der Server authentisieren sich mittels der Signatur SIGN gegenseitig. (14) Die sichere Ausführungsumgebung TEE überträgt zum Server die Zugriffsinformation URL, den Identifikator ID und die Signatur SIGN. (15) Der Server prüft die Signatur mittels des Schlüssels Key und, falls die Signaturprüfung positiv war, (16) überträgt die an URL Transaktionsdaten DAT an die sichere Ausführungsumgebung SE/TEE. Auf die in der sicheren Ausführungsumgebung SE/TEE befindlichen Transaktionsdaten kann der Käufer/Empfänger keinen Einfluss nehmen.
  • (17) Die Transaktionsdaten werden am Display des Mobilgeräts angezeigt. Der Käufer prüft und ggf. bestätigt die Transaktionsdaten durch Eingabe am Keyboard (ggf. Touchpad auf dem Display) des Mobilgeräts, vorzugsweise gibt er auch eine PIN (Personal Identification Number) ein. (18) Nach erfolgreicher Bestätigung wird durch die sichere Ausführungsumgebung SE/TEE die Durchführung der Zahlungsverkehrs-Transaktion und damit das Bezahlen der Rechnung veranlasst. (19) Die Bank des Käufers transferiert den auf der Rechnung angegebenen Betrag an die Bank des Händlers.
  • Nach Schritt (18) kann optional das TEE/SE den Transaktionsdatenserver PS des Provisioning Service kontaktieren, welcher die Rechnung als bezahlt markiert, um Doppelbezahlungen zu vermeiden und/oder den Händler über die erfolgte Zahlung zu informieren. Der Signaturschlüssel Key kann wahlweise symmetrisch oder asymmetrisch sein. Wahlweise wird für jede Rechnung ein individueller Signaturschlüssel verwendet.

Claims (12)

  1. System zum Erstellen einer Rechnung ausgehend von einem Transaktionsdatensatz (DAT), der einen statischen Teil (stat) und einen dynamischen Teil (dyn) umfasst, wobei mit der Rechnung ein Rechnungssteller (H) zur Durchführung einer Zahlungsverkehrs-Transaktion auffordert, und wobei das System einen Händlerserver (HS) des Rechnungsstellers (H) umfasst, dadurch gekennzeichnet, dass das System weiter umfasst: – einen Transaktionsdatenserver (PS), auf dem der Transaktionsdatensatz (DAT) zum Erstellen der Rechnung bereitstellbar ist; – einen ersten Kommunikations-Kanal (C1) zwischen dem Händlerserver (HS) und dem Transaktionsdatenserver (PS), über den der statische Teil (stat) des Transaktionsdatensatzes (DAT) vom Händlerserver (HS) aus am Transaktionsdatenserver (PS) veränderbar ist; und – einen zweiten Kommunikations-Kanal (C2) zwischen dem Händlerserver (HS) und dem Transaktionsdatenserver (PS), über den der dynamische Teil (dyn) des Transaktionsdatensatzes (DAT) vom Händlerserver (HS) aus am Transaktionsdatenserver (PS) veränderbar ist, und über den der statische Teil (stat) des Transaktionsdatensatzes (DAT) vom Händlerserver (HS) aus am Transaktionsdatenserver (PS) nicht veränderbar.
  2. System nach Anspruch 1, wobei nur ein einziger Kommunikations-Kanal von dem ersten (C1) und dem zweiten (C2) Kommunikations-Kanal auf einmal betreibbar ist.
  3. System nach Anspruch 1 oder 2, wobei der statische Teil (stat) sicherheitskritische Transaktionsdaten (DAT) umfasst, insbesondere Kontoverbindungsdaten eines Zielkontos der Zahlungsverkehrs-Transaktion.
  4. System nach einem der Ansprüche 1 bis 3, wobei der erste und der zweite Kommunikations-Kanal (C1, C2) über unterschiedliche Zugriffsdaten geschützt sind.
  5. System nach einem der Ansprüche 1 bis 4, wobei über den ersten Kommunikations-Kanal (C1) keine Rechnungen erstellbar sind und über den zweiten Kommunikations-Kanal (C2) Rechnungen erstellbar sind.
  6. Verfahren zum Bearbeiten einer Rechnungsinfrastruktur zum Erstellen von Rechnungen, jeweils ausgehend von einem Transaktionsdatensatz (DAT), der einen statischen Teil (stat) und einen dynamischen Teil (dyn) umfasst, wobei mit der Rechnung ein Rechnungssteller zur Durchführung einer Zahlungsverkehrs-Transaktion auffordert, mittels eines Systems nach einem der Ansprüche 1 bis 5, gekennzeichnet durch die Schritte: – Betreiben des ersten Kommunikations-Kanal (C1) zwischen dem Händlerserver (HS) und dem Transaktionsdatenserver (PS); und – Bearbeiten, insbesondere Neu-Erstellen oder/und Ändern, des statischen Teils (stat) des Transaktionsdatensatzes (DAT) vom Händlerserver (HS) aus am Transaktionsdatenserver (PS).
  7. Verfahren zum Erstellen einer Rechnung ausgehend von einem Transaktionsdatensatz (DAT), der einen statischen Teil (stat) und einen dynamischen Teil (dyn) umfasst, wobei mit der Rechnung ein Rechnungssteller zur Durchführung einer Zahlungsverkehrs-Transaktion auffordert, mittels eines Systems nach einem der Ansprüche 1 bis 5, gekennzeichnet durch die Schritte: – Bereitstellen des statischen Teils (stat) des Transaktionsdatensatzes (DAT) auf dem Transaktionsdatenserver (PS); – Betreiben des zweiten Kommunikations-Kanal (C2) zwischen dem Händlerserver (HS) und dem Transaktionsdatenserver (PS); – Bearbeiten, insbesondere Neu-Erstellen oder/und Ändern, des dynamischen Teils (dyn) des Transaktionsdatensatzes (DAT) vom Händlerserver (HS) aus am Transaktionsdatenserver (PS); – Zusammenführen des statischen (stat) und des dynamischen (dyn) Teils des Transaktionsdatensatzes zum Transaktionsdatensatz (DAT); und – Erstellen der Rechnung mit dem Transaktionsdatensatz (DAT).
  8. Verfahren nach Anspruch 7, weiter umfassend die Schritte: – Erstellen, vorzugsweise durch den Transaktionsdatenserver (PS), einer Zugriffsinformation (URL) zum Zugreifen auf den Transaktionsdatensatz (DAT) der erstellten Rechnung auf dem Transaktionsdatenserver (PS); – Bereitstellen der Zugriffsinformation (URL) an einen Rechnungsempfänger (E), als Aufforderung an den Rechnungsempfänger (E) zur Durchführung Zahlungsverkehrs-Transaktion gemäß der Rechnung.
  9. Verfahren nach Anspruch 8, weiter umfassend die Schritte: – Erstellen, vorzugsweise durch den Transaktionsserver (PS), eines maschinenlesbaren Merkmals, insbesondere 2D-Barcodes oder RFID-Etiketts, ausgehend von der Zugriffsinformation (URL); – Bereitstellen des maschinenlesbaren Merkmals an den Rechnungsempfänger (E), um die Zugriffsinformation (URL) an ihn bereitzustellen.
  10. Verfahren zur Veranlassung der Durchführung einer Zahlungsverkehrs-Transaktion, gekennzeichnet durch die Schritte: a) Entgegennehmen, durch ein mobiles Endgerät des Rechnungsempfängers (E), einer gemäß Anspruch 8 oder 9 bereitgestellten Zugriffsinformation (URL); b) Übermitteln der Zugriffsinformation (URL) vom Endgerät des Rechnungsempfängers (E) an den Transaktionsdatenserver (PS); c) beim Transaktionsdatenserver (PS), Bereitstellen des Transaktionsdatensatzes (DAT) an das Endgerät des Rechnungsempfängers (E); d) beim Endgerät des Rechnungsempfängers (E) Bestätigen des Transaktionsdatensatzes (DAT), um die Durchführung der Zahlungsverkehrs-Transaktion zu veranlassen.
  11. Verfahren nach Anspruch 10, wobei in Schritt c) beim Transaktionsdatenserver (PS) ein Authentisierungsschritt durchgeführt wird, in dem überprüft wird, ob der Rechnungsempfänger (E) zum Empfang des Transaktionsdatensatzes berechtigt ist, und nur falls dies der Fall ist, das Bereitstellen des Transaktionsdatensatzes (DAT) an das Endgerät des Rechnungsempfängers (E) durchgeführt wird.
  12. Verfahren nach einem der Ansprüche 1 bis 11, wobei dem Transaktionsdatensatz (DAT) ein durch den Transaktionsdatenserver (TS) erzeugter oder erzeugbarer Identifikator (ID) zugeordnet ist, und wobei anlässlich eines Bereitstellens oder Übermitteln von Transaktionsdaten zwischen dem Transaktionsserver (TS) und dem Endgerät des Rechnungsempfängers (E) auch der Identifikator (ID) bereitgestellt bzw. übermittelt wird.
DE102014017710.6A 2014-12-01 2014-12-01 Erstellen einer Rechnung aus einem statischen und einen dynamischen Teil eines Transaktionsdatensatzes Ceased DE102014017710A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE102014017710.6A DE102014017710A1 (de) 2014-12-01 2014-12-01 Erstellen einer Rechnung aus einem statischen und einen dynamischen Teil eines Transaktionsdatensatzes

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102014017710.6A DE102014017710A1 (de) 2014-12-01 2014-12-01 Erstellen einer Rechnung aus einem statischen und einen dynamischen Teil eines Transaktionsdatensatzes

Publications (1)

Publication Number Publication Date
DE102014017710A1 true DE102014017710A1 (de) 2016-06-02

Family

ID=55967656

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102014017710.6A Ceased DE102014017710A1 (de) 2014-12-01 2014-12-01 Erstellen einer Rechnung aus einem statischen und einen dynamischen Teil eines Transaktionsdatensatzes

Country Status (1)

Country Link
DE (1) DE102014017710A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018162099A1 (en) * 2017-03-08 2018-09-13 Sicpa Holding Sa Advanced methods, systems and devices for registering information in a database
EP3407533A1 (de) * 2017-05-24 2018-11-28 Sicpa Holding Sa Erweiterte verfahren, systeme und vorrichtungen zur registrierung von informationen in einer datenbank

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10040644A1 (de) * 2000-08-14 2002-02-28 Arndt Jablonowski Verfahren zur Übertragung von Datensätzen an Datenverarbeitungsanlagen
WO2013144930A1 (en) * 2012-03-30 2013-10-03 Fireid Payments (Proprietary) Limited Method and system for making payments using scanned bar codes

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10040644A1 (de) * 2000-08-14 2002-02-28 Arndt Jablonowski Verfahren zur Übertragung von Datensätzen an Datenverarbeitungsanlagen
WO2013144930A1 (en) * 2012-03-30 2013-10-03 Fireid Payments (Proprietary) Limited Method and system for making payments using scanned bar codes

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018162099A1 (en) * 2017-03-08 2018-09-13 Sicpa Holding Sa Advanced methods, systems and devices for registering information in a database
EP3407533A1 (de) * 2017-05-24 2018-11-28 Sicpa Holding Sa Erweiterte verfahren, systeme und vorrichtungen zur registrierung von informationen in einer datenbank
EA038684B1 (ru) * 2017-05-24 2021-10-04 Сикпа Холдинг Са Усовершенствованные способы, системы и устройства для регистрации информации в базе данных

Similar Documents

Publication Publication Date Title
DE112012006324T5 (de) Mobile Zahlung über ein virtuelles Peripheriegerät
EP2776999A1 (de) Verfahren und vorrichtung zum durchführen von bargeldlosen zahlungen
EP3246865A1 (de) Verfahren und anordnung zur übermittlung von transaktionsdaten unter nutzung eines öffentlichen datennetzes
CH710912B1 (de) Sichere Transaktionsverarbeitung in einem Kommunikationssystem.
WO2008092770A1 (de) Verfahren und vorrichtung zur elektronischen zahlung
CN105931035A (zh) 一种支付标记生成方法及装置
WO2013093026A1 (de) Verfahren zur durchführung authentifizierter zahlungen
DE102014017710A1 (de) Erstellen einer Rechnung aus einem statischen und einen dynamischen Teil eines Transaktionsdatensatzes
DE102011079317A1 (de) Mobiles system für finanztransaktionen
EP1213689B1 (de) Verfahren zur automatischen Abwicklung von Zahlungsvorgängen im Electronic Commerce sowie zugehörige Vorrichtung
WO2019121469A1 (de) Elektronisches rechnungsverwaltungssystem
DE102013016119B4 (de) Verfahren zur Bezahlung
DE102012003859A1 (de) Verfahren und System zum Durchführen eines Bezahlvorgangs
WO2021122763A1 (de) Verfahren zum auslösen eines bezahlvorganges
EP3035270A1 (de) Kartenbasierte offline-token generierung
EP2790145A1 (de) Verfahren und System zum bargeldlosen Bezahlen oder Geldabheben mit einem mobilen Kundenterminal
EP1437668B1 (de) Verfahren zur bargeldlosen Zahlung von Waren oder Dienstleistungen unter Verwendung eines Mobilfunkendgerätes
DE102010036037A1 (de) Verfahren zur Durchführung bargeldioser Zahlungstransaktionen und Transaktionsystem zur Durchführung des Verfahrens
WO2015176772A1 (de) Verfahren zum verarbeiten einer transaktion
EP2523155B1 (de) Verfahren zum datentechnischen Zuordnen eines NFC-fähigen Endgerätes, einer NFC-Chipkarte und einer Transaktion
DE102012005952A1 (de) Verfahren zur evidenzbasierten Absicherung mobiler Zahlungstransaktionen
DE102013000967B4 (de) Verfahren zur Autorisierung einer elektronischen Transaktion
EP1274971A2 (de) Verfahren zur sicheren bezahlung von lieferungen und leistungen in offenen netzwerken
WO2014029744A1 (de) Verfahren und system zur durchführung einer finanz-transaktion
DE102021003724A1 (de) Verfahren zur ldentifikation einer Person durch eine Kreditkartennummer und ldentifikationssystem

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R002 Refusal decision in examination/registration proceedings
R003 Refusal decision now final