DE19938695A1 - Verfahren und Vorrichtung zur elektronischen Abwicklung von bargeldlosen Zahlungen mittels Sicherheitsmodulen - Google Patents

Verfahren und Vorrichtung zur elektronischen Abwicklung von bargeldlosen Zahlungen mittels Sicherheitsmodulen

Info

Publication number
DE19938695A1
DE19938695A1 DE19938695A DE19938695A DE19938695A1 DE 19938695 A1 DE19938695 A1 DE 19938695A1 DE 19938695 A DE19938695 A DE 19938695A DE 19938695 A DE19938695 A DE 19938695A DE 19938695 A1 DE19938695 A1 DE 19938695A1
Authority
DE
Germany
Prior art keywords
dealer
customer
security module
card
payment
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.)
Withdrawn
Application number
DE19938695A
Other languages
English (en)
Inventor
Roland Weber
Horst Henn
Thomas Schaeck
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.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
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 International Business Machines Corp filed Critical International Business Machines Corp
Priority to DE19938695A priority Critical patent/DE19938695A1/de
Priority to EP00114891A priority patent/EP1079347A3/de
Priority to US09/638,745 priority patent/US6829597B1/en
Publication of DE19938695A1 publication Critical patent/DE19938695A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821Electronic credentials
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825Use of electronic signatures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401Transaction verification
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409Device specific authentication in transaction processing
    • G06Q20/4097Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • G06Q20/40975Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • G06Q30/0601Electronic shopping [e-shopping]
    • G06Q30/0613Third-party assisted
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0806Details of the card
    • G07F7/0813Specific details related to card security
    • G07F7/082Features insuring the integrity of the data on or in the card

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Marketing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Die vorliegende Erfindung beschreibt eine Vorrichtung und ein Verfahren zur Durchführung von bargeldlosen Zahlungen zwischen Kunden und Händler über eine Vertragsbank. Die Erfindung unterteilt sich in ein Online-Verfahren zwischen Kunden und Händler zur Festlegung der Zahlungsart, Überprüfung des Verfügungsrahmens, Erstellen eines Belegs zur Beschreibung des Geschäftsvorgangs, Erstellen einer Zahlungsanweisung, Signierung des erstellten Belegs durch den Händler und Signieren der Zahlungsanweisung durch den Händler und den Kunden, wobei die Bank Offline geschaltet ist, und einem nachgeschalteten Online-Verfahren zwischen Händler und Bank zur Übertragung der signierten Zahlungsanweisung und des signierten Belegs, Überprüfung der Händler- und Kundensignatur, Überprüfung der Zuordnung zwischen Zahlungsanweisung und Beleg, Ersetzen der Identitätsdaten von Händler und Kunden durch Informationen zur Ausführung der Zahlungsanweisung, Durchführung der Zahlungsanweisung und Ablage der Belege. Ein wesentlicher Vorteil des Verfahrens liegt darin, dass keine sensitiven Kundendaten wie Kontonummer, Kreditkartennummer u. a. auf der Kundenkarte gespeichert werden und damit ein Mißbrauch durch Unbefugte ausgeschlossen wird. Darüber hinaus dient das Verfahren dazu, die vom Kunden gewünschten Zahlungsarten für maschinelle Verarbeitung zu definieren und das Risiko, dass der Kunde beim Verlust der Kundenkarte eingeht, zu minimieren. Weiterhin erlaubt das Verfahren, dass Kunden, die kein ...

Description

Die vorliegende Erfindung beschreibt ein Verfahren und Vorrichtung zur elektronischen Abwicklung von bargeldlosen Zahlungen mittels Sicherheitsmodulen, insbesondere Chipkarten, zwischen Händler und Kunden.
Bargeldloses Zahlen mit Chipkarten hat sich in vielen Bereichen des täglichen Lebens durchgesetzt. Hierbei wird zwischen kontogebundenen und nicht kontogebundenen bargeldlosen Zahlungen mit Chipkarten unterschied. Eine kontogebundene Chipkarte setzt ein Konto bei der kartenausgebenden Bank voraus. Möchte der Kunde eine bargeldlose Zahlung mit seiner Chipkarte abwickeln, bringt er gewöhnlicherweise seine Chipkarte in ein Kartelesegerät des Händlers ein, es wird eine Datenverbindung zur Bank des Kunden aufgebaut, die Banküberprüft das Vorhandensein eines gedeckten Kontos des Chipkarteninhabers und weist bei ausreichender Deckung des Kontos eine Zahlung an den Händler an. Ein Nachteil dieser kontogebundenen Chipkarten liegt darin, dass der Aufbau der Online-Verbindung zur Bank des Kunden sehr lange dauern kann oder dass wegen Überlastung des Systems der Bank überhaupt kein Verbindungsaufbau möglich ist. Der Kunde muß in diesem Fall mit Bargeld oder sonstigen Zahlungsmitteln zahlen. Verfügt der Kunde über eine weitere kontogebundene Chipkarte einer anderen kartenausgebenden Bank, kann er das gleiche Verfahren mit dieser Chipkarte wiederholen.
Eine Alternative zu der kontogebundene Chipkarte ist die sogenannte Geldkarte. Auf der Geldkarte befindet sich ein bestimmter Geldbetrag in Form von Bytes, die im Fall einer Zahlung auf das Händlersystem übertragen werden. Der Vorteil der Geldkarte liegt darin, dass der Kunde ohne Online- Verbindung zu seiner Bank direkt an den Händler zahlen kann. Ein Nachteil der Geldkarte liegt jedoch in ihrer derzeit geringen Akzeptanz durch Kunden und die dadurch bedingte fehlende Infrastruktur.
Es ist daher Aufgabe der vorliegenden Erfindung, ein Verfahren und eine Vorrichtung zum bargeldlosen Zahlungsverkehr bereitzustellen, das die Vorteile der kontogebundenen und nicht kontogebundenen Chipkarte in sich vereinigt ohne jedoch deren Nachteile zu übernehmen.
Diese Aufgabe wird durch die Merkmale der Ansprüche 1, 18, 24, 25, 27 und 28 gelöst.
Weitere vorteilhafte Ausführungsformen der vorliegenden Erfindung sind in den Unteransprüchen niedergelegt.
Die Vorteile der vorliegende Erfindung liegen darin, dass der Kunde mit seiner Kundenkarte mehrere Zahlungsarten mit individuell gestaltbaren Zahlungsmerkmalen durchführen kann. Er erhält von der Bank einen standardisierten Vertrag für alle Zahlungsarten und einen konsolidierten Bericht über die erfolgten Zahlungen sowie elektronische Belege, die integriert in einer e-Business Anwendung weiterverarbeitet werden können. Der Kunde kann dabei optional vollkommen anonym beim Händler bezahlen, da nur die Bank eventuell eine Zuordnung der Kundenkartennummer zu einem Kunden vornehmen kann.
Der Händler kann mit einem Händler-Terminal und einer standardisierten Händleranwendung alle gängigen Zahlungsarten durchführen, wobei die Bank als alleiniger Partner für alle Vertragsbedingungen, Definition der Terminal-Hardware, Rückfragen usw. zuständig ist.
Umständliche Prozesse wie Abfragen der gewünschten Zahlungsart, Kundenadresse, Verwendungszweck usw. beim Bezahlen entfallen. Der Händler kann auf die elektronischen Belege im Falle von Kundenreklamationen zurückgreifen.
Die Bank kann sowohl Händlern als auch Kunden ein umfassendes standardisiertes System anbieten und auch attraktiven Gebührensätzen gewinnbringend arbeiten.
Die vorliegende Erfindung wird anhand eines bevorzugten Ausführungsbeispiels mit Figuren beschrieben, wobei
Fig. 1A eine Zahlungsarchitektur für bargeldlose Zahlungen über eine Online-Verbindung zwischen Kunden und Händler zeigt, wie sie derzeit implementiert ist;
Fig. 1B eine Zahlungsarchitektur für bargeldlose Zahlungen über eine Offline-Verbindung zwischen Kunden und Händler zeigt, wie sie derzeit implementiert ist.
Fig. 2A das erfinderische Verfahren zur bargeldlosen Zahlung zeigt
Fig. 2B die erfinderische Architektur zeigt, die dem Verfahren nach Fig. 2A zugrunde liegt
Fig. 3 den Aufbau und Inhalt der "Zahlungsanweisung" zeigt, wie sie der Erfindung nach Fig. 2A/B zugrunde liegt.
Fig. 4 den Aufbau und Inhalt des Belegs zeigt, wie er der Erfindung nach Fig. 2A/B zugrunde liegt Fig. 5 die erfinderische Implementierung eines Verfügungsrahmens (Kreditlinie) in der Kundenkarte zeigt
Fig. 6A den Inhalt der Kundenkarte des Kunden zur Durchführung des Verfahrens nach Fig. 2A/B zeigt
Fig. 6B den Inhalt der Händlerkarte zur Durchführung des Verfahrens nach Fig. 2A/B zeigt.
In Fig. 1A wird eine Online-Architektur zur bargeldlosen Zahlung zwischen einem Kunden und einem Händler und einem Händler und einer Bank gezeigt.
Die Architektur besteht aus einem Bank-Terminal (B), einem Händler-Terminal (H) und einem Kunden-Terminal (K). Die Kommunikation zwischen Kunden und Händler-Terminäl erfolgt über eine Online-Datenverbindung. Das gleiche gilt für die Kommunikation zwischen Händler- und Banken-Terminal. Das Händler-Terminal besteht aus einem Datenverarbeitungsgerät (DV) mit einem angeschlossenen Kartenlesegerät (KLH) und einem Sicherheitsmodul in Form einer Chipkarte (CKH). Auf dem Datenverarbeitungsgerät des Händlers läuft ein Zahlungsanwendungsprogramm (ZAP). Das Kunden-Terminal (K) besteht ebenfalls aus einem Datenverarbeitungsgerät (DV), einem Kartenlesegerät (KLK) und einem Sicherheitsmodul in Form einer Chipkarte (CKK). Auf dem Kunden-Terminal läuft ebenfalls ein Zahlungsanwendungsprogramm (ZAP) oder der Kunde lädt sich bestimmte Applets zur Abwicklung einer Zahlung auf sein Terminal. Dies erfolgt vorzugsweise über das Händlersystem.
In Fig. 1B wird eine Offline-Architektur zur bargeldlosen Zahlung zwischen einem Kunden (K) und einem Händler (H) gezeigt, wobei die Kommunikation zwischen Händler (H) und Bank (B) bei Bedarf online erfolgt. Im Gegensatz zu Fig. 1A gibt es in dieser Architektur kein Kunden-Terminal (K). Das Händler-Terminal (H) besteht daher aus einem Datenverarbeitungsgerät (DV), einem Händlerkartenleser (KLH) für die Händlerchipkarte und einem Kundenkartenleser für die Kundenchipkarte (CKK).
In Fig. 2A wird eine bevorzugte Ausführungsform des erfinderische Verfahrens anhand der einzelnen Verfahrensschritte beim bargeldlosen Zahlen über eine Online-Verbindung zwischen Kunden und Händler dargestellt. Der Kunde verfügt über ein Kunden-Terminal wie in Fig. 1A beschrieben.
Er steckt die Kundenchipkarte (Kundenkarte (CKK)) in den Kartenleser und stellt eine Verbindung mit Hilfe seines Browsers zum Händler-Terminal(DVH) her. Dort wählt sich der Kunde z. B. in eine Online-Shopping-Anwendung ein, wählt Produkte aus und gibt eine Lieferadresse an. Dieser Online- Geschäftsvorgang wird gewöhnlichweise durch Eingabe einer Zahlungsart und Bestätigung des Kaufs beendet.
Bei Anwendung des erfinderischen Verfahrens wird der Kunde als Zahlungsart die Chipkarte auswählen. Die bargeldlose Zahlung über die Kundenkarte erfolgt in folgenden Schritten:
1. Einstecken der Kundenkarte (CKK) in den Kundenkartenleser falls dies nicht schon vorher erfolgt ist. Die Kundenkarte kommuniziert über ein Applet mit der Händlerzahlungs­ anwendung auf dem Server des Händlers. Das Applet generiert Chipkartenbefehle in Form von APDUs, sendet diese an die Kundenkarte (CCKK) und wertet diese aus. Die ausgewerteten Ergebnisse werden vom Applet an die Händlerzahlungsanwendung gesandt. Für das erfinderische Verfahren muß die Kundenkarte (CKK) vorbereitet sein.
Im nicht flüchtigen Speicher der Kundenkarte (CKK) sind zumindest folgende Daten abgelegt:
  • a) Identifikationsdaten über den Kunden oder Kundenchipkarte (CKK)
  • b) Geheimer Schlüssel, den die Bank auf die Chipkarte aufgebracht hat
  • c) Kreditlinie oder Verfügungsrahmen, den die Bank dem Kunden einräumt
  • d) Zahlungsarten, die die Bank für diesen Kunden akzeptiert
  • e) PIN-Persönliche Identifikationsnummer oder Paßwort. Die Information zu e) ist nur erforderlich, wenn der Kunde online bezahlt.
2. Auslesen der Daten a), c) und d) der Kundenkarte über Chipkartenbefehle. Diese Daten werden vom Applet mittels des HTTP-Protokolls zum Händlerzahlungsanwendung übertragen und im flüchtigen Speicher des Händler-Terminals (DVH) abgelegt.
3. Die Händlerzahlungsanwendung liest von der Händlerkarte (CKH) oder dem stationären Sicherheitsmodul folgende Daten und speichert sie im flüchtigen Speicher des Händlersystems:
  • a) Identifikationsdaten über den Händler oder Händlerkarte (CKH) bzw. des Sicherheitsmoduls des Händlers
  • b) Zahlungsarten, die der Händler gemäß Bankvereinbarung akzeptiert
4. Die Händlerzahlungsanwendung bestimmt anhand der eingelesenen Daten beider Karten die möglichen Zahlungsarten. Bei mehreren Zahlungsmöglichkeiten erfolgt die Auswahl durch den Kunden mit Hilfe des Applets, das ihm die Auswahl über eine grafische Benutzeroberfläche (GUI) darstellt. Erfolgt keine Auswahl durch den Kunden, ergibt sich die Zahlungsart aus einer Prioritätsreihenfolge. Weiterhin überprüft die Händlerzahlungsanwendung, ob der Verfügungsrahmen durch den Zahlungsbetrag nicht überschritten wird. Im Fall, dass der Verfügungsrahmen überschritten wird, wird automatisch eine Online-Verbindung zur Bank hergestellt. Die Bank setzt den Verfügungsrahmen bei ausreichender Deckung auf einen neuen Betrag fest und sendet den neuen Verfügungsrahmen zur Kundenkarte (CKK), wo der alte Verfügungsrahmen durch den neuen Verfügungsrahmen ersetzt wird. Setzt die Bank keinen neuen Verfügungsrahmen fest, bedarf es der Bestätigung durch den Händler, ob der Zahlungsvorgang unterbrochen wird oder mit Risiko des Händlers weitergeführt wird.
5. Erstellen eines Belegs durch die Händlerzahlungs­ anwendung. Der Beleg enthält Informationen über den getätigten Geschäftsvorgang in einer Form, die der visuellen Darstellung zugänglich ist. Der Beleg enthält bei einem Kauf vorzugsweise folgende Daten:
  • a) Namen oder Artikelnummer der gekauften Produkte
  • b) Einzelpreis der Produkte
  • c) Stückzahl der Produkte
  • d) Gesamtpreis
  • e) Mehrwertsteuer
  • f) Lieferkosten
6. Berechnen des Fingerabdrucks des Belegs durch Anwenden einer Hash-Funktion.
7. Signieren des Fingerabdrucks mit Hilfe eines privaten Schlüssels, der auf der Händlerkarte (Sicherheitsmodul (CKH)) im nicht flüchtigen Speicher abgelegt ist.
8. Erstellen einer Zahlungsanweisung (ZA) durch die Händlerzahlungsanwendung. Die Zahlungsanweisung (ZA) enthält zumindest folgende Informationen:
  • a) Identifikationsdaten des Händlers oder des Sicherheitsmoduls des Händlers/Händlerkarte (CKH)
  • b) Identifikationsdaten des Kunden oder der Kundenchipkarte (CKK)
  • c) Zahlungsbetrag in einer bestimmten Währung
  • d) Zahlungsart
  • e) Fingerabdruck des Belegs oder Teile des Fingerabdrucks
Optional kann die Zahlungsanweisung noch durch Datum der Zahlung oder andere Parameter erweitert werden.
9. Einfügen einer laufenden Nummer in die Zahlungsanweisung mittels der Händlerkarte (CKH), wobei auf der Händlerkarte (CKH) eine Funktion implementiert ist, die laufende Nummern generiert.
10. Signieren der Zahlungsanweisung nach Schritt 9 durch die Händlerkarte (CKH). Vorzugsweise erfolgt die Signierung über ein symmetrisches Verfahren mit Hilfe eines geheimen Schlüssels, der von der Bank auf die Händlerkarte (CKH) aufgebracht worden ist. Alternativ ist auch die Signierung über ein asymmetrisches Verfahren mit Hilfe eines privaten Schlüssels möglich.
11. Senden der händlersignierten Zahlungsanweisung an das Applet im Kunden-Terminal (DVK).
12. Im Fall einer Online-Zahlung wird nun eine PIN-Eingabe bzw. Paßwort-Eingabe durch den Kunden gefordert. Die Kundenkarte (CKK) erlaubt den nachfolgenden Schritt nur dann, wenn die richtiger PIN oder das richtige Paßwort eingegeben worden ist.
13. Verringern des Verfügungsrahmen auf der Kundenkarte (CKK) um den zu zahlenden Betrag.
14. Signieren der Zahlungsanweisung durch die Kundenkarte (CKK) mit einem symmetrischen Verfahren. Alternativ kann auch ein asymmetrisches Verfahren wie zu Verfahrensschritt 10 angewandt werden. Optional kann vor der Signierung durch die Kundenkarte eine laufende Kundenseriennummer eingefügt werden.
15. Zurücksenden der händher- und kundensignierten Zahlungsanweisung an die Händlerzahlungsanwendung.
16. Abspeichern der signierten Zahlungsanweisung nach Schritt 14 und des signierten Belegs nach Schritt 7 auf einem nichtflüchtigen Speicher des Händler-Terminals (DVH) zur späteren Übertragung an die Bank. Verfahrensschritte 1-16 können vom Händler mit verschiedenen Kunden durchgeführt werden, bevor mit Verfahrensschritt 17 fortgesetzt wird. 17. Herstellen einer Online-Verbindung mit der Bank und Übertragen der Daten nach Schritt 16) auf das Bank-Terminal (DVB), wobei die Bankenzahlungsanwendung folgende Verfahrensschritte durchführt:
  • a) Prüfen der digitalen Händler- und Kundensignatur der Zahlungsanweisung (ZA) auf ihre Authentizität. Bei symmetrischen Verfahren ist die Bank im Besitz des geheimen Schlüssel. Bei asymmetrischen Verfahren ist die Bank im Besitz des öffentlichen Schlüssels. Optional prüft die Bank auch die Authentizität des Belegs
  • b) Prüfen des Bezugs zwischen Zahlungsanweisung und Beleg durch Überprüfen des Fingerabdrucks in der Zahlungsanweisung durch die Bankenzahlungsanwendung
  • c) Ersetzen der Identifikationsdaten des Kunden durch Kontonummer und Bankleitzahl des Kunden oder eine Kreditkartennummer oder vergleichbare Informationen, die zur Abwicklung der Zahlung an den Händler erforderlich sind. Ersetzen der Identifikationsdaten des Händlers durch Kontonummer und Bankleitzahl
  • d) Durchführung der Zahlungstransaktionen nach der Zahlungsanweisung
  • e) optional kann dem Kunden mitgeteilt werden, dass die Zahlung erfolgt ist.
Fig. 2B zeigt die Hauptkomponenten der vorliegenden Erfindung. Die Hauptkomponenten sind:
Kundenkarte (Chipkarte)
Händlerkarte (Chipkarte oder Sicherheitsmodul)
Bank-Server
Händler-Terminal
Kunden-Terminal
Netzwerk (Internet).
Kundenkarte
Die Kundenkarte, die für die beabsichtigte Anwendung vorbereitet ist, wird als anonyme Karte ähnlich wie eine Telefonkarte von der Bank herausgegeben. Die Karte wird durch eine eindeutige Kartennummer identifiziert. Die Karte kann als übliche Kundenkarte, als SIM Modul in einem Mobiltelephon oder als eingebautes Sicherheitsmodul in einem PC, Taschenrechner oder einem anderen Konsumentengerät eingebaut sein. Bei der Ausgabe können Funktionen wie Kreditkarte oder elektronische Börse aktiviert sein. Der Kunde gibt bei der Beantragung der Zusatzfunktionen für die multifunktionale Zahlungskarte die von ihm gewünschten Zahlungsarten, seine Bankverbindungen mit Bankleitzahl und Kontonummer und eventuell seine Kreditkartennummern mit Verfalldatum ein. Außerdem kann der Kunde Höchstbeträge absolut oder als Summe nach der Online Autorisierung für die Karte und/oder für die verschiedenen Zahlungsarten durch die Bank festlegen. Diese Höchstwerte, sogenannte Verfügungsrahmen, werden bei erfolgter Zahlung entsprechend verringert und bei einer ONLINE Transaktion wieder aufgefüllt, sofern die Portal-Bank den Kunden als kreditwürdig einstuft. Der Kunde kann auch bestimmen welche Zahlungsarten zusätzlich durch Eingabe einer Persönlichen Identifikationsnummer (PIN) geschützt werden sollen, sofern dies nicht bereits bei bestimmten Zahlungsarten gefordert wird. Die Angaben können über ein Formular oder Online an Kiosk oder PC im Netzwerk gemacht werden. Insbesondere kann eine für die jeweilige Zahlungsart vorgesehene Karte für die Identifizierung des Kunden benutzt werden. Die Zusatzfunktionen können auch vor der Ausstellung beantragt und vor der Ausgabe der Karte auf der Karte freigeschaltet werden. Die Aktivierung der Anwendungen auf der Karte erfolgt mit der ersten Online Transaktion mit Kundenkarte am Bank-Server.
Das Kundenprofil, das alle erweiterten Zahlungsfunktionen definiert, wird auf dem Bank-Server sicher gespeichert.
Referenzen zu den gewünschten Zahlungsarten und die Grundwerte der Verfügungsrahmen werden mit einem nur der Bank bekannten Schlüssel verschlüsselt, zur Kundenkarte geschickt und dort gespeichert.
Ein wesentlicher Vorteil des Verfahrens liegt darin, dass keine sensitiven Kundendaten wie Kontonummer, Kreditkartennummer u. a. auf der Kundenkarte gespeichert werden und damit ein Mißbrauch durch Unbefugte ausgeschlossen wird. (Kreditkartennummern sind bei heutigen Verfahren zum Beispiel frei zugänglich und nur durch die PIN, die relativ leicht ausgespäht werden kann geschützt.)
Die Summe der Maßnahmen dient dazu, die vom Kunden gewünschten Zahlungsarten für maschinelle Verarbeitung zu definieren und das Risiko, dass der Kunde beim Verlust der Karte eingeht, zu minimieren. Ein Kunde kann z. B. Zahlungen ohne Eingabe der PIN auf z. B. 50 DM und Zahlungen mit PIN auf 500 DM Gesamtsumme nach der letzten Online Transaktion begrenzen. Gleichzeitig mit dem Kundenrisiko wird hierdurch auch das Risiko der Bank begrenzt.
Diese Methode erlaubt es auch Kunden, die kein Bankkonto unterhalten wie zum Beispiel Kindern, ein elektronischer Zahlungsmittel mit beschränktem Verfügungsrahmen zur Verfügung zu stellen.
Zusätzlich enthält die Kundenkarte einen geheimen Signierschlüssel (symmetrisch - DES oder asymmetrisch - RSA) mit dem Belege signiert werden können.
Die Kundenkarte kann als kontaktbehaftete Karte oder als kontaktlose Karte ausgeführt sein. Ein Konsument kann mehrere Kundenkarten im Besitz haben z. B. Kleingeldkarte mit Verfügungsrahmen Null und mehrere Karten für bestimmte Verwendungszwecke.
Händlerkarte
Die Händlerkarte wird durch die Bank ausgegeben. Sie kann ähnlich wie die Kundenkarte als vorstrukturierte Karte ausgegeben und anschließend aktiviert werden. Die Händlerkarte speichert die Händleridentifikation, eine Kontonummer(n) auf welche die Einnahmen verbucht werden, interne Identifikationsmerkmale z. B. Verkäufer ID u. a. Die Händlerkarte enthält auch alle Schlüssel und kryptographischen Funktionen, die für den Zugriff auf die Kundenkarte notwendig sind. Eine Funktion z. B. entschlüsselt das aus der Kundenkarte verschlüsselt abgelegte Kundenprofil und die dazugehörigen Verfügungsrahmen.
In der Händlerkarte ist ein geheimer Schlüssel (asymmetrisch - RSA) der von der Bank oder einer anderen vertrauenswürdigen Instanz zertifiziert wurde. Mit diesem Schlüssel werden Angebote an den Kunden und Belege signiert.
Bank-Server
Der Bank-Server dient als Portal zu allen Finanzdiensten. Er verarbeitet die vom Händler eingehenden Zahlungsbelege und generiert daraus konventionelle Zahlungsanweisungen (Lastschrift, Überweisung, Kreditkarte usw.) sowie elektronische Belege, die zum Beispiel im XML Format auf dem Server abgelegt werden. Ein wesentlicher Vorteil des vorgeschlagenen Verfahrens besteht darin, dass vorhandene Systeme des Zahlungsverkehrs nicht geändert werden müssen. Zugriff auf diese Belege erfolgt zum Beispiel über das Internet - der Zugriff ist nur dem Kunden möglich. Dies kann zum Beispiel durch eine mit der Kunden- oder Händlerkarte durchgeführte Authentisierung erfolgen (Challenge/Response Verfahren).
Händler-Terminal
Das Händler-Terminal ist vorzugsweise eine PC Kasse, an die entweder ein Smartcard Leser mit zwei Lesestationen (Slots) oder zwei Smartcard Leser angeschlossen sind. Der Leser für den Kunden kann speziell auch mit drahtloser Übertragung (z. B. Infrarot, Bluetooth u. a.) Angeschlossen werden. Das Kundenkartenlesegerät kann auch im Besitz des Kunden sein (Mobiltelephon, Taschenrechner usw.) Die Händlerkarte ist in der Regel im Betrieb dauernd aktiv. Die Kundenkarte wird nur für den Bezahlvorgang benötigt. Leser für Kunden können zusätzlich mit Tastatur für PIN Eingabe und zusätzlicher Anzeige ausgestattet sein. Das Verfahren erfordert aber grundsätzlich keine Leser mit besonderen Sicherheitsfunktionen (wie zum Beispiel Geldkarte). Die Sicherheit wird allein durch gesicherte Interaktionen zwischen Kundenkarte und Händlerkarte erzielt.
Das Händler-Terminal kann auch in einem der üblichen Kartenlesegerät mit programmierbaren Funktionen implementiert werden.
Das Händler-Terminal kann auch als Client/Server System implementiert werden. Wobei der Leser für die Händlerkarte am Server und der Leser für die Kundenkarte am Clienten des Kunden PCs, Mobiltelephons, Taschenrechner usw. angeschlossen ist.
Alle Geräte verfügen über einen Netzwerkanschluß, mit dem sie auf den Bank Server zugreifen können. Dieser Anschluss wird typisch nur für den Datenaustausch zwischen Händler, Kunden und Bank-Server benötigt. Während des eigentlichen Zahlungsvorgangs ist keine Verbindung über das Netzwerk erforderlich.
Kunden-Terminal
Das Kunden-Terminal ist entweder ein PC, ein Taschenrechner (Organizer), ein Mobiltelephon oder ein anderes Konsumentengerät jeweils mit Smartcard Leser. Alle Geräte verfügen über einen Netzwerkanschluß, mit dem sie auf den Bank Server zugreifen können.
Netzwerk
Alle Komponenten haben temporär Zugriff auf ein Netzwerk. Vorzugsweise wird hierfür ein Internet oder ein INTRANET verwendet werden. Das Verfahren benötigt keine besonderen Sicherheitsfunktionen für den Betrieb der Systemkomponenten. Es wird empfohlen, die Händlerkarte oder die Kundenkarte zusätzlich zu verwenden, um den Zugriff zum Bank-Portal Server abzusichern.
Fig. 3 zeigt den Mindestinhalt der Zahlungsanweisung, so wie sie im erfinderischen Verfahren generiert wird. Hierbei enthält die Zahlungsanweisung folgende Informationen:
  • - die Identifikation des Händlers, Händlerkarte oder Sicherheitsmodul
  • - die Identifikation des Kunden oder Kundenkarte
  • - Zahlungsbetrag (optional mit Währung)
  • - Zahlungsart,(Gutschrift, Lastschrift, Kredit . . .)
  • - Fingerabdruck des Belegs
Folgende Informationen sind optional:
  • - Laufende Nummer der Kundenkarte
  • - Datum der Zahlungsanweisung
  • - Verwendungszweck
  • - eventuell weitere Informationen
Nachträglich werden folgende Informationen zur Zahlungsanweisung hinzugefügt:
  • - Signatur des Händlers
  • - Signatur des Kunden
Fig. 4 zeigt den Mindestinhalt des Belegs, so wie er im erfinderischen Verfahren generiert wird.
Der Beleg dient zur Beschreibung des jeweiligen Geschäftsvorgangs zwischen dem Kunden und Händler. Er hat Beweisfunktion hinsichtlich des Inhalts des getätigten Geschäfts. Vorzugsweise enthält der Beleg einige oder alle der folgenden Informationen:
  • a) Namen oder Artikelnummer der gekauften Produkte
  • b) Einzelpreis der Produkte
  • c) Stückzahl der Produkte
  • d) Gesamtpreis
  • e) Mehrwertsteuer
  • f) Lieferkosten
  • g) Zahlungsbetrag(optional mit Währung)
  • h) Identifikation des Kunden(z. B. Karten- oder Kundennummer)
  • i) Verwendungszweck
  • j) weitere Informationen zur Beschreibung des getätigten Geschäfts
Nachträglich wird folgende Information zum Beleg hinzugefügt:
Signatur des Händlers.
Der Beleg wird vorzugsweise in einer Darstellung generiert, aus der er über eine Benutzeroberfläche lesbar dargestellt werden kann.
Fig. 5 zeigt anhand eines beispielhaften Verlaufs die Implementierung des Verfügungsrahmens/Kreditlinie.
Auf der Kundenkarte im nichtflüchtigen Speicher wird der von der Bank eingeräumte Verfügungsrahmen (Betragslimit) als Betrag gespeichert. Der Kunde macht die Zahlungen 1 und 2, die zur Verringerung des Verfügungsrahmens um die Beträge b1 und b2 führen. Zahlung 3 führt zur Überschreitung des Verfügungsrahmens. Die Händlerzahlungsanwendung baut automatisch eine Online-Verbindung zur Bank auf und es wird geprüft, ob dem Kunden ein neuer Verfügungsrahmen eingeräumt wird. Wird dem Kunden ein neuer Verfügungsrahmen durch die Bank eingeräumt, wird über die Händlerzahlungsanwendung ein Heraufsetzen des Verfügungsrahmen auf der Kundenkarte im nichtflüchtigen Speicher initiiert. Alternativ hierzu kann die Verbindung zur Bank auch von der Kundenzahlungsanwendung initiiert werden.
Vorzugsweise erfolgt die Überprüfung des existierenden Verfügungsrahmen durch die Händlerzahlungsanwendung beim Auslesen der Kundendaten von der Kundenkarte. Deckt der existierende Verfügungsrahmen die Zahlung nicht ab und erhöht die Bank nicht den Verfügungsrahmen auf einen neuen Betrag, erhält der Händler von der Händlerzahlungsanwendung die Mitteilung, dass er die Zahlung auf sein eigenes Risiko übernehmen kann.
Fig. 6A zeigt den Kundenkarteninhalt zur Durchführung der vorliegenden Erfindung.
Hierbei muß die Kundenkarte zumindest folgende Informationen enthalten:
  • - Identifikationsdaten des Kunden oder der Kundenkarte
  • - Geheimer Schlüssel zum Signieren der Zahlungsanweisung (nur der Bank bekannt)
  • - PIN oder Paßwort (nur dem Kunden bekannt)
  • - Zahlungarten, die die Bank erlaubt
  • - Verfügungsrahmen
Optional sind folgende Informationen:
Laufende Nummer für Zahlungsanweisungen
Verwendungszweck (zum Einfügen in den Beleg)
Logbuch der letzten n signierten Zahlungsanweisung
Geheimer Schlüssel zum Zugriff auf Kartendaten (nur der Bank bekannt aber auf der Händlerkarte bzw. Sicherheitsmodul verfügbar).
Diese Informationen sind im nichtflüchtigen Speicher der Kundenkarte abgelegt und werden von den Händlerzahlungsanwendung gelesen und in die Zahlungsanweisung übernommen.
Fig. 6B zeigt den Händlerkarteninhalt bzw. Inhalt des Sicherheitsmoduls des Händlers zur Durchführung der vorliegenden Erfindung. Das Sicherheitsmodul des Händlers enthält zumindest folgende Informationen:
  • - Identifikationsdaten des Händlers oder des Händlersicherheitsmoduls
  • - Geheimer Schlüssel zum Signieren der Zahlungsanweisung (nur der Bank bekannt)
  • - Zahlungsarten, die mit der Bank vereinbart sind
  • - Laufende Nummer für die Zahlungsanweisung
Optional sind folgende Informationen:
  • - Privater Schlüssel zum Signiereü der Belege (nur dem Händler bekannt; passender öffentlicher Schlüssel ist bei der Bank hinterlegt)
  • - Geheimer Schlüssel zum Zugriff auf Kundenkartendaten
  • - Laufende Summe über signierte Zahlungsanweisungen
  • - Logbuch der letzten n signierten Zahlungsanweisungen

Claims (31)

1. Verfahren zur automatischen Durchführung von bargeldlosen Zahlungen mittels einer Kundenchipkarte oder eines vergleichbaren mobilen Sicherheitsmoduls, wobei eine Kommunikationsarchitektur mit zumindest folgenden Komponenten vorausgesetzt wird:
  • a) ein Händler-Terminal mit einer Händlerzahlungsanwendung zur Abwicklung einer bargeldlosen Zahlung
  • b) ein Händler-Sicherheitsmodul oder eine Händlerkarte
  • c) ein Lesegerät zum Lesen der Kundenchipkarte oder eines mobilen Sicherheitsmoduls
  • d) zumindest eine Kundenchipkarte oder ein mobiles Sicherheitsmodul
  • e) ein Bank-Terminal mit einer Anwendung zur Abwicklung einer bargeldlosen Zahlung,
gekennzeichnet durch folgende Schritte:
  • a) Herstellen einer Kommunikationsverbindung zwischen Händler-Terminal und Kundenchipkarte oder mobilen Sicherheitsmodul
  • b) elektronisches Auslesen folgender Informationen von der Kundenchipkarte oder des mobilen Sicherheitsmoduls durch die Händlerzahlungsanwendung:
    • a) Identifikationsdaten über den Kunden oder die Kundenchipkarte oder das mobile Sicherheitsmodul
    • b) Kreditlinie oder Verfügungsrahmen, den die Bank dem Kunden einräumt
    • c) Zählungsarten, die die Bank für diesen Kunden akzeptiert
  • c) elektronisches Auslesen folgender Informationen von dem Händler-Sicherheitsmodul oder der Händlerchipkarte durch die Händleranwendung:
    • a) Identifikationsdaten über den Händler oder das Händler-Sicherheitsmodul/­ Händlerchipkarte
    • b) Zahlungsarten, die der Händler gemäß Bankvereinbarung akzeptiert
  • d) elektronisches Bestimmen der Zahlungsart unter Berücksichtigung der Informationen ccc) und eee) und Überprüfen des Verfügungsrahmens unter Berücksichtigung der Information bbb) und des Zahlungsbetrags durch die Händlerzahlungsanwendung,
weiterfahren mit Schritt ee), wenn der Verfügungsrahmen nicht erschöpft ist oder
weiterfahren mit Schritt fff), wenn der Verfügungsrahmen erschöpft ist:
  • a) Herstellen einer Datenverbindung mit der Bank
  • b) elektronisches Überprüfen des Verfügungsrahmens des Kunden durch die Bank
  • c) elektronisches Hochsetzen des Verfügungsrahmens auf der Kundenchipkarte auf einen neuen Wert
  • a) elektronisches Erstellen eines Belegs zur Erfassung aller wesentlichen Informationen zur Beschreibung des jeweiligen Geschäftsvorgangs
  • b) Berechnen eines Fingerabdrucks des Belegs durch Anwenden einer Hash-Funktion
  • c) Signieren des Fingerabdrucks mit Hilfe eines Schlüssels, der auf der Händlerchipkarte (Sicherheitsmodul) im nichtflüchtigen Speicher abgelegt ist, und Hinzufügen zum Beleg
  • d) elektronisches Erstellen einer Zahlungsanweisung durch die Händlerzahlungsanwendung mit zumindest folgenden Informationen:
    • a) Identifikationsdaten des Händlers oder des Sicherheitsmoduls des Händlers /Händlerchipkarte
    • b) Identifikationsdaten des Kunden oder der Kundenchipkarte oder des mobilen Sicherheitsmoduls
    • c) Zahlungsbetrag
    • d) Zahlungsart
    • e) Fingerabdruck oder Teile des Fingerabdrucks des Belegs
  • e) Signieren der Zahlungsanweisung nach Schritt hh) durch die Händlerchipkarte oder durch das Sicherheitsmodul des Händlers
  • f) Vetringern des Verfügungsrahmen auf der Kundenchipkarte um den zu zahlenden Betrag
  • g) Signieren der Zahlungsanweisung durch die Kundenchipkarte oder durch das mobile Sicherheitsmodul
  • h) Abspeichern der Zahlungsanweisung nach Schritt kk) und des Belegs nach Schritt gg) auf einem nichtflüchtigen Speicher des Händler-Terminals zur späteren Übertragung an die Bank
  • i) Herstellen einer Datenverbindung zwischen dem Händler-Terminal und der Bank und Übertragen der abgespeicherten Daten nach Schritt ll) auf das Bank-Terminal, wobei die Bankenanwendung folgende weitere Verfahrensschritte durchführt:
  • j) Prüfen der digitalen Händler- und Kundensignatur der Zahlungsanweisung auf ihre Authentizität
  • k) Prüfen des Bezugs zwischen Zahlungsanweisung und Belegs mittels des Fingerabdrucks in der Zahlungsanweisung durch die Bankenanwendung
  • l) elektronisches Ersetzen der Identifikationsdaten des Kunden und des Händlers durch Informationen zur Abwicklung der Zahlung durch die Bankenanwendung
  • m) elektronische Durchführung der Zahlung gemäß den Informationen nach Schritt ppp)
2. Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass das Händler-Terminal eine PC-Kasse oder ein Datenverarbeitungsgerät mit einem Lesegerät mit einer Lesestation für die Kundenchipkarte oder einem mobilen Sicherheitsmodul und einer Lesestation für das Händlersicherheitsmodul oder Händlerkarte ist oder jeweils ein Lesegerät für die Kundenchipkarte oder ein mobiles Sicherheitsmodul und ein Lesegerät für das Händler-Sicherheitsmodul oder Händlerkarte ist.
3. Verfahren nach Anspruch 2 dadurch gekennzeichnet, dass das Lesegerät für die Händlerkarte oder das Händler-Sicherheitsmodul eine fest installierbare Komponente der PC Kasse oder des Datenverarbeitungsgeräts ist.
4. Verfahren nach Anspruch 2 dadurch gekennzeichnet, dass das Datenverarbeitungsgerät ein Client-Server- System ist, wobei das Lesegerät für die Händlerkarte oder das Händler-Sicherheitsmodul am Server und das Lesegerät für die Kundenchipkarte oder das mobile Sicherheitsmodul am Client-System angeordnet ist.
5. Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass das Lesegerät für die Kundenchipkarte ein Mobiltelefon ist und dass die Kommunikation zwischen Mobiltelefon und dem Händler-Terminal über eine drahtlose Datenverbindung erfolgt.
6. Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass das Lesegerät für die Kundenkarte oder das mobile Sicherheitsmodul in einem mobilen Datenverarbeitungsgerät angeordnet ist, wobei über das mobile Datenverarbeitungsgerät eine Datenverbindung zum Bank-Terminal aufgebaut wird.
7. Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass die Informationen über die Zahlungsart auf der Kundenchipkarte oder dem mobilen Sicherheitsmodul sowie der Händlerchipkarte oder Sicherheitsmodul für den Händler nicht gespeichert sind, sondern von der Bankenanwendung vorgeben sind.
8. Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass die Informationen aaa)-ccc) auf der Kundenchipkarte oder dem mobilen Sicherheitsmodul über ein Applet ausgelesen und zur Händleranwendung gesendet werden.
9. Verfahren nach Anspruch 2 dadurch gekennzeichnet, dass das Applet im Händler-Terminal abgelegt ist und beim Aufbau der Kommunikation zwischen Händler- Terminal und Kundenchipkarte oder dem mobilen Sicherheitsmodul auf das Kunden-Terminal übertragen wird.
10. Verfahren nach Ansprüch 1 dadurch gekennzeichnet, dass die ausgelesenen Informationen aaa)-eee) im flüchtigen Speicher des Händler-Terminals abgelegt werden.
11. Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass die Bestimmung der Zahlungsart über eine Prioritätsliste anhand der Informationen ccc) und eee) erfolgt.
12. Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass der Beleg einige oder alle der folgenden Informationen enthält:
  • - Namen und/oder Artikelnummer der gekauften Produkte
  • - Einzelpreis der Produkte
  • - Stückzahl der Produkte
  • - Gesamtpreis
  • - Mehrwertsteuer
  • - Lieferkosten
  • - Zahlungsbetrag
  • - Identifikation des Kunden
  • - Verwendungszweck.
13. Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass das Signieren des Fingerabdrucks mit Hilfe eines privaten Schlüssels erfolgt.
14. Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass beim Erstellen der Zahlungsanweisung folgende weitere Informationen berücksichtigt werden:
  • - Laufende Nummer der Händlerkarte
  • - Laufende Nummer der Kundenchipkarte
  • - Datum der Zahlungsanweisung
  • - Verwendungszweck
15. Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass das Signieren der Zahlungsanweisung durch die Händlerkarte oder das Händler-Sicherheitsmodul nach Schritt ii) über ein symmetrisches Verfahren mit Hilfe eines geheimen Schlüssels, der von der Bank auf die Händlerchipkarte oder Händlersicherheitsmodul aufgebracht worden ist, erfolgt oder die Signierung über ein asymmetrisches Verfahren mit Hilfe eines privaten Schlüssels erfolgt.
16. Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass die Signierung durch die Kundenchipkarte oder das mobile Sicherheitsmodul nach Schritt kk) die Eingabe einer PIN oder eines Paßworts voraussetzt.
17. Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass das Signieren der Zahlungsanweisung durch die Kundenchipkarte oder das mobile Sicherheitsmodul nach Schritt kk) mit einem symmetrischen Verfahren oder einem asymmetrischen Verfahren erfolgt.
18. Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass die Durchführung des Zahlungsvorgangs nach Schritt qqq) durch eine Überweisung, Lastschrift oder Abbuchung von einer Kreditkarte erfolgen kann.
19. Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass die Verfahrensschritte bb) und cc) sowie die Verfahrensschritte ii) und kk) in umgekehrter Reihenfolge durchgeführt werden.
20. Vorrichtung zur Abwicklung von bargeldlosen Zahlungen zwischen Händler und Kunden zumindest enthaltend:
  • a) ein Händler-Terminal zumindest enthaltend:
  • b) ein Datenverarbeitungsgerät auf dem ein Computerprogrammprodukt zur Durchführung der Verfahrensschritte aa)-mm) nach Anspruch 1 installiert ist
  • c) ein Lesegerät zum Lesen der Informationen auf der Händlerkarte oder dem Händler- Sicherheitsmodul
  • d) ein Kunden-Terminal enthaltend zumindest:
  • e) ein Datenverarbeitungsgerät mit einem, Computerprogrammprodukt zum Lesen und Verarbeiten von Informationen von der Kundenchipkarte oder dem mobilen Sicherheitsmodul und zur Kommunikation mit dem Computerprogrammprodukt auf dem Händler-Terminal
  • f) ein Lesegerät zum Lesen der Informationen auf der Kundenkarte
  • g) Bank-Terminal enthaltend zumindest:
  • h) ein Datenverarbeitungsgerät mit einem Computerprogrammprodukt zur Durchführung der Verfahrensschritte mm-qqq) nach Anspruch 1.
21. Vorrichtung nach Anspruch 20 dadurch gekennzeichnet, dass das Händler-Terminal eine PC-Kasse oder ein Datenverarbeitungsgerät mit einem Lesegerät mit einer Lesestation für die Kundenchipkarte oder einem mobilen Sicherheitsmodul und einer Lesestation für das Händlersicherheitsmodul oder Händlerkarte ist oder jeweils ein Lesegerät für die Kundenchipkarte oder ein mobiles Sicherheitsmodul und ein Lesegerät für das Händler-Sicherheitsmodul oder Händlerkarte ist.
22. Vorrichtung nach Anspruch 21 dadurch gekennzeichnet, dass das Lesegerät für die Händlerkarte oder das Händler-Sicherheitsmodul eine fest installierbare Komponente der PC Kasse oder des Datenverarbeitungsgeräts ist.
23. Vorrichtung nach Anspruch 21 dadurch gekennzeichnet, dass das Datenverarbeitungsgerät ein Client-Server- System ist, wobei das Lesegerät für die Händlerkarte oder das Händler-Sicherheitsmodul am Server und das Lesegerät für die Kundenchipkarte oder das mobile Sicherheitsmodul am Client-System angeordnet ist.
24. Vorrichtung nach Anspruch 20 dadurch gekennzeichnet, dass das Lesegerät für die Kundenchipkarte ein Mobiltelefon ist und dass die Kommunikation zwischen Mobiltelefon und dem Händler-Terminal über eine drahtlose Datenverbindung erfolgt.
25. Vorrichtung nach Anspruch 20 dadurch gekennzeichnet, dass das Lesegerät für die Kundenkarte oder das mobilen Sicherheitsmodul in einem mobilen Datenverarbeitungsgerät angeordnet ist, wobei über das mobile Datenverarbeitungsgerät eine Datenverbindung zum Bank-Terminal aufgebaut wird.
26. Kunden-Terminal zur Durchführung von bargeldlosen Zahlungen zumindest enthaltend:
  • a) ein Datenverarbeitungsgerät mit einem Computerprogrammprodukt zum Lesen und Verarbeiten von Informationen von der Kundenchipkarte oder dem mobilen Sicherheitsmodul und zur Kommunikation mit dem Computerprogrammprodukt auf einem Händler- Terminal zur Durchführung der Verfahrensschritte aa-ll) nach Anspruch 1
  • b) ein Lesegerät zum Lesen der Informationen auf der Kundenchipkarte oder dem mobilen Sicherheitsmodul
  • c) Kommunikationsmodul zur Herstellung einer Online-Datenverbindung.
27. Händler-Terminal zur Durchführung von bargeldlosen Zahlungen enthaltend zumindest:
  • a) ein Datenverarbeitungsgerät mit einem installierten Computerprogrammprodukt zur Durchführung der Verfahrensschritte aa)-ll) nach Anspruch 1
  • b) ein Lesegerät zum Lesen der Informationen auf der Händlerchipkarte oder dem Händler- Sicherheitsmodul
  • c) Kommunikationsmodul zur Herstellung einer Online-Datenverbindung.
28. Banken-Terminal zur Durchführung von bargeldlosen Zahlungen zumindest enthaltend:
  • a) ein Datenverarbeitungsgerät mit einem installierten Computerprogrammprodukt zur Durchführung der Verfahrensschritte mm)-qqq) nach Anspruch 1
  • b) ein Kommunikationsmodul zur Herstellung einer Online-Datenverbindung.
29. Händlerchipkarte oder das Händler-Sicherheitsmodul zumindest enthaltend:
  • a) einen Prozessor
  • b) einen nichtflüchtigen Speicher mit zumindest folgenden Informationen:
    Identifikationsdaten für Händler oder Händlerkarte oder Händler-Sicherheitsmodul Zahlungsarten, die der Händler vorgibt Schlüssel zum kryptografischen Signieren der Zahlungsanweisung
    zum Auslesen durch die Händlerzahlungsanwendung nach Anspruch 1.
30. Kundenchipkarte oder mobiles Sicherheitsmodul zumindest enthaltend:
  • a) einen Prozessor
  • b) einen nichtflüchtigen Speicher mit zumindest folgenden Informationen:
    Identifikationsdaten über den Kunden oder Kundenchipkarte oder mobiles Sicherheitsmodul
    Geheimer Schlüssel zum Signieren von Zahlungsanweisungen
    Kreditlinie oder Verfügungsrahmen, den die Bank dem Kunden einräumt
    Zahlungsarten, die die Bank für diesen Kunden akzeptiert
    PIN-Persönliche Identifikationsnummer oder Paßwort zum teilweisen Auslesen durch die Händleranwendung nach Anspruch 1.
31. Computerprogrammprodukt, das im internen Speicher eines digitalen Rechner gespeichert ist, enthaltend Teile von Softwarecode zur Ausführung des Verfahrens nach Anspruch 1-17, wenn das Produkt, auf dem Rechner ausgeführt wird.
DE19938695A 1999-08-14 1999-08-14 Verfahren und Vorrichtung zur elektronischen Abwicklung von bargeldlosen Zahlungen mittels Sicherheitsmodulen Withdrawn DE19938695A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
DE19938695A DE19938695A1 (de) 1999-08-14 1999-08-14 Verfahren und Vorrichtung zur elektronischen Abwicklung von bargeldlosen Zahlungen mittels Sicherheitsmodulen
EP00114891A EP1079347A3 (de) 1999-08-14 2000-07-12 Verfahren und Vorrichtung zur elektronischen Verarbeitung von bargeldlosen Zahlungen mittels Sicherheitsmodulen
US09/638,745 US6829597B1 (en) 1999-08-14 2000-08-14 Method, apparatus and computer program product for processing cashless payments

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE19938695A DE19938695A1 (de) 1999-08-14 1999-08-14 Verfahren und Vorrichtung zur elektronischen Abwicklung von bargeldlosen Zahlungen mittels Sicherheitsmodulen

Publications (1)

Publication Number Publication Date
DE19938695A1 true DE19938695A1 (de) 2001-02-15

Family

ID=7918486

Family Applications (1)

Application Number Title Priority Date Filing Date
DE19938695A Withdrawn DE19938695A1 (de) 1999-08-14 1999-08-14 Verfahren und Vorrichtung zur elektronischen Abwicklung von bargeldlosen Zahlungen mittels Sicherheitsmodulen

Country Status (3)

Country Link
US (1) US6829597B1 (de)
EP (1) EP1079347A3 (de)
DE (1) DE19938695A1 (de)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10009710A1 (de) * 2000-03-01 2001-09-13 Roland Eckert Verfahren zum Austausch von Zahlungsinformationen im internetfähigen bargeldlosen Zahlungsverkehr
DE10136080A1 (de) * 2000-11-21 2002-06-06 Wolfgang Zint Verfahren zum Durchführen einer bargeldlosen Finanztransaktion
DE10122506A1 (de) * 2001-05-10 2002-11-14 Giesecke & Devrient Gmbh Zahlungsbeleg und Zahlungsbelegsystem
DE10131648A1 (de) * 2001-06-29 2003-01-23 Informatik-Zentrum Bayern, Softwaregesellschaft Der Bayerischen Sparkassen Gmbh & Co. Kg Webserver und Verfahren zum Betreiben desselben zur Durchführung eines Bezahlvorgangs im Internet
US7353210B2 (en) 2002-06-10 2008-04-01 Ralf Hochwimmer Electronic means of payment with individually settable security features for the internet or for mobile networks
EP3486852A3 (de) * 2017-11-15 2019-08-07 Rubean AG Verfahren und anordnung zum auslösen einer elektronischen zahlung

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040103060A1 (en) * 2002-11-22 2004-05-27 Pitney Bowes Incorporated Secure payment system and method having one-time use authorization
EG23422A (en) * 2002-11-24 2005-07-10 Ashraf Kamal Salem Mashhour Scheme for spreading and easy use of electronic services and remote payments.
US8433647B1 (en) 2004-08-25 2013-04-30 Vectorsgi, Inc. Method and system for processing electronic checks
US8556165B2 (en) * 2005-09-21 2013-10-15 Bank Of America Corporation Method and system for enabling teller presentation of pre-approved credit offers
US20090015374A1 (en) * 2007-07-09 2009-01-15 Riddhiman Ghosh User authentication system and method
CN111080284B (zh) * 2019-12-17 2024-04-16 北京东方国信科技股份有限公司 基于双向验证的移动付款码扫码支付方法和顾客支付端

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09116960A (ja) * 1995-10-18 1997-05-02 Fujitsu Ltd キャッシュレスシステム及び該システムで使用する携帯機
US5671279A (en) * 1995-11-13 1997-09-23 Netscape Communications Corporation Electronic commerce using a secure courier system
US5915022A (en) * 1996-05-30 1999-06-22 Robinson; Rodney Aaron Method and apparatus for creating and using an encrypted digital receipt for electronic transactions
US6341353B1 (en) * 1997-04-11 2002-01-22 The Brodia Group Smart electronic receipt system
US6282522B1 (en) * 1997-04-30 2001-08-28 Visa International Service Association Internet payment system using smart card
US6098053A (en) * 1998-01-28 2000-08-01 Citibank, N.A. System and method for performing an electronic financial transaction
US6609102B2 (en) * 1998-07-20 2003-08-19 Usa Technologies, Inc. Universal interactive advertizing and payment system for public access electronic commerce and business related products and services

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10009710A1 (de) * 2000-03-01 2001-09-13 Roland Eckert Verfahren zum Austausch von Zahlungsinformationen im internetfähigen bargeldlosen Zahlungsverkehr
DE10136080A1 (de) * 2000-11-21 2002-06-06 Wolfgang Zint Verfahren zum Durchführen einer bargeldlosen Finanztransaktion
DE10122506A1 (de) * 2001-05-10 2002-11-14 Giesecke & Devrient Gmbh Zahlungsbeleg und Zahlungsbelegsystem
DE10131648A1 (de) * 2001-06-29 2003-01-23 Informatik-Zentrum Bayern, Softwaregesellschaft Der Bayerischen Sparkassen Gmbh & Co. Kg Webserver und Verfahren zum Betreiben desselben zur Durchführung eines Bezahlvorgangs im Internet
US7353210B2 (en) 2002-06-10 2008-04-01 Ralf Hochwimmer Electronic means of payment with individually settable security features for the internet or for mobile networks
EP3486852A3 (de) * 2017-11-15 2019-08-07 Rubean AG Verfahren und anordnung zum auslösen einer elektronischen zahlung

Also Published As

Publication number Publication date
EP1079347A3 (de) 2005-11-30
US6829597B1 (en) 2004-12-07
EP1079347A2 (de) 2001-02-28

Similar Documents

Publication Publication Date Title
DE69900169T3 (de) Kreditkartensystem und verfahren
DE69829684T2 (de) Chipkarten verwendendes system zum bezahlen und laden im internet
DE69913929T2 (de) Gesichertes Bezahlungsverfahren
DE69534441T2 (de) System und Verfahren zum Verkaufen von elektronischen Wertkarten
DE10296888T5 (de) System und Verfahren zur sicheren Eingabe und Authentifikation von verbraucherzentrierter Information
DE69601787T2 (de) Verfahren zum elektronischen bezahlen bei der durchführung von kauf-transaktionen in einem rechnernetzwerk
DE10296919T5 (de) System und Verfahren zur sicheren Rückzahlung
AT512070B1 (de) Verfahren und vorrichtung zum durchführen von bargeldlosen zahlungen
DE10297521T5 (de) Verbraucher-zentrisches kontext-bewußtes Vermittlungsmodell
DE212010000059U1 (de) Veränderbarer Sicherheitswert
DE69908382T2 (de) Verfahren zum elektronischen bezahlen
DE19844677C2 (de) Verfahren und Vorrichtung zur drahtlosen elektronischen Abwicklung von Transaktionen
DE19938695A1 (de) Verfahren und Vorrichtung zur elektronischen Abwicklung von bargeldlosen Zahlungen mittels Sicherheitsmodulen
DE10297517T5 (de) Automatisiertes digitales Rechte-Management und Zahlungssystem mit eingebettetem Inhalt
WO2014206659A1 (de) Elektronisches transaktionsverfahren und computersystem
DE10022973A1 (de) Verfahren zur Abwicklung von Geldgeschäften über elektronische Übertragungsmedien
DE60217713T2 (de) Verfahren, system und vorrichtung zur authentifierung von durch einen benutzer übertragener und/oder empfangener daten
DE60122912T2 (de) Verfahren zum liefern von identifikationsdaten einer bezahlkarte an einen anwender
DE202019106383U1 (de) Elektronische Zahlungsvorrichtung
DE60210270T2 (de) Verfahren, bei de, elektronische Zahlkarten zum Sichern der Transaktionen eingesetzt werden
DE102013016119B4 (de) Verfahren zur Bezahlung
DE60110388T2 (de) Vorrichtung und verfahren zum ermöglichen eines freiwilligen austausches von daten gegen elektronische punkte
EP1128340A1 (de) Verfahren zum Aufladen eines Kundenkontos für Telekommunikationsdienste und entsprechendes Aufladesystem
DE102013022436B3 (de) Elektronisches Transaktionsverfahren und Computersystem
EP2816515A1 (de) Verfahren und System zum Bezahlen von Produkten an einem Verkaufsautomaten mit einem Mobilendgerät

Legal Events

Date Code Title Description
8139 Disposal/non-payment of the annual fee