DE60133701T2 - Beglaubigungsverfahren und -system, Bezahlungssystem, Gebrauchervorrichtung und Aufzeichnungsmedium mit Programm zum Durchführen der Beglaubigung - Google Patents

Beglaubigungsverfahren und -system, Bezahlungssystem, Gebrauchervorrichtung und Aufzeichnungsmedium mit Programm zum Durchführen der Beglaubigung Download PDF

Info

Publication number
DE60133701T2
DE60133701T2 DE60133701T DE60133701T DE60133701T2 DE 60133701 T2 DE60133701 T2 DE 60133701T2 DE 60133701 T DE60133701 T DE 60133701T DE 60133701 T DE60133701 T DE 60133701T DE 60133701 T2 DE60133701 T2 DE 60133701T2
Authority
DE
Germany
Prior art keywords
user
transaction
key
authentication
authentication system
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.)
Expired - Lifetime
Application number
DE60133701T
Other languages
English (en)
Other versions
DE60133701D1 (de
Inventor
Mitsuru Kawasaki-shi Nakajima
Yoshiaki Kawasaki-shi Imajima
Takayoshi Kawasaki-shi Handa
Hitoshi Kawasaki-shi Monma
Toshihiro Kawasaki-shi Kodaka
Mikako Kawasaki-shi Fujii
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.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
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 Fujitsu Ltd filed Critical Fujitsu Ltd
Publication of DE60133701D1 publication Critical patent/DE60133701D1/de
Application granted granted Critical
Publication of DE60133701T2 publication Critical patent/DE60133701T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • 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/085—Payment architectures involving remote charge determination or related payment systems
    • G06Q20/0855—Payment architectures involving remote charge determination or related payment systems involving a third party
    • 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/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking 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/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G06Q20/203—Inventory monitoring
    • 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/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • 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/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • 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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, 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
    • 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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, 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/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • 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
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • 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/321—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 a third party or a trusted authority
    • 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/3226—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 predetermined code, e.g. password, passphrase or PIN
    • 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/3271—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 challenge-response
    • H04L9/3273—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 challenge-response for mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Game Theory and Decision Science (AREA)
  • Marketing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Description

  • HINTERGRUND DER ERFINDUNG
  • 1. Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft ein Authentifizierungsverfahren, ein Authentifizierungssystem, ein Zahlungssystem, ein Nutzergerät und ein Aufzeichnungsmedium, das ein Programm zum Ausführen einer Authentifizierung enthält, um eine Reihe von kommerziellen Transaktionen zu erleichtern.
  • 2. Beschreibung der verwandten Technik
  • Falls bei Transaktionen von Angesicht zu Angesicht der Käufer Bargeld hat, wird die Transaktion dann gewöhnlich in bar abgewickelt, und falls nicht, wird der Kauf meistens mittels Kreditkarte vollzogen. Kreditkarten funktionieren so, dass eine Unterschrift allein genügt, wodurch der Karteninhaber Einkäufe bis zu einer gewissen Grenze in beteiligten oder Mitgliedsläden tätigen kann.
  • Kreditkarten sind so praktisch (insofern als sie das Mitführen von Bargeld überflüssig machen), dass die moderne Gesellschaft manchmal als bargeldlose Gesellschaft oder Kreditkartengesellschaft bezeichnet wird.
  • Zudem ist es einhergehend mit der jüngsten rapiden Verbreitung des Internets und anderer derartiger Kommunikationsnetze nun möglich geworden, über das Internet online einzukaufen. In diesem Fall erfolgt die Zahlung mittels Übertragung eines Mitglieds-ID oder Passwortes.
  • Jedoch gehen verschiedenartige Sicherheitsprobleme und Nachteile mit Transaktionen von Angesicht zu Angesicht einher, die mit einer Kreditkarte und dergleichen abgewickelt werden, worin die Authentifizierung von beteiligten Mitgliedsläden und das Ausspähen der Kartennummer eingeschlossen sind. Was den beteiligten Laden anbelangt, ist es zusätzlich schwierig, mit Sicherheit die wahre Identität des Karteninhabers zu bestimmen.
  • Zusätzlich besteht im Falle des Online-Einkaufs und dergleichen die Möglichkeit, dass heikle Informationen, wie beispielsweise Mitglieds-ID-Nummern und Passwörter (die typischerweise über das Internet übertragen werden müssen, um die Transaktion zu vollziehen), unterwegs abgefangen und unberechtigt verwendet werden, das heißt, verwendet werden, um betrügerische Käufe zu tätigen.
  • US-A-5 883 810 beschreibt ein Online-Handelssystem, das den Online-Handel über ein öffentliches Netz unter Verwendung einer Online-Handelskarte erleichtert. Die "Karte" existiert nicht in physischer Form, stattdessen aber in digitaler Form. Die Online-Handelskarte wird für einen Kunden durch eine ausstellende Institution elektronisch ausgestellt. Die ausgestellte Karte ist einer permanenten Kundenkontonummer zugeordnet, die im Namen des Kunden in der ausstellenden Institution geführt wird, um das Risiko der verlorengegangenen oder gestohlenen Nummer zu beseitigen. Wenn der Kunde eine Online-Transaktion vornehmen möchte, bittet der Kunde die ausstellende Institution um Ausstellung einer Transaktionsnummer für eine einzelne Transaktion. Die ausstellende Institution erzeugt eine temporäre Transaktionsnummer und ordnet sie der permanenten Kontonummer in einem Datenprotokoll zu. Der Kunde empfängt die Transaktionsnummer und legt jene Nummer dem Händler stellvertretend für die Kundenkontonummer vor. Die Transaktionsnummer sieht wie eine echte Kartennummer aus, und der Händler behandelt die Transaktionsnummer genauso wie jede reguläre Kreditkartennummer. Wenn der Händler eine Anfrage zur Autorisierung vorlegt, erkennt die ausstellende Institution die Nummer als Transaktionsnummer für eine Online-Handelskarte. Das ausstellende Institut nimmt Bezug auf die Kundenkontonummer unter Verwendung der Transaktionsnummer als Index und verarbeitet die Autorisierungsanfrage unter Verwendung der tatsächlichen Kundenkontonummer anstelle der stellvertretenden Nummer. Sobald die Autorisierungsanfrage verarbeitet ist, setzt die ausstellende Institution noch einmal die Transaktionsnummer für die Kundenkontonummer ein und sendet eine Autorisierungsantwort unter der Transaktionsnummer zurück an den Händler.
  • Die vorliegende Erfindung ist in den beigefügten unabhängigen Ansprüchen definiert, auf die nun Bezug genommen werden sollte. Ferner sind bevorzugte Merkmale in den ihnen beigefügten Unteransprüchen zu finden.
  • Daher ist es eine Aufgabe der vorliegenden Erfindung, ein verbessertes und brauchbares Authentifizierungsverfahren, ein Authentifizierungssystem, ein Zahlungssystem, ein Nutzergerät und ein Aufzeichnungsmedium vorzusehen, das ein Programm zum Ausführen einer Authentifizierung enthält.
  • Die oben beschriebenen Ziele der vorliegenden Erfindung werden in einem Authentifizierungssystem zum Authentifizieren von Nutzern, die Beteiligte an einer Transaktion sind, durch ein Authentifizierungsverfahren erreicht, das die Schritte umfasst:
    • (a) Liefern eines passenden Schlüssels für eine künftige Transaktion an einen ersten Nutzer (Käufer);
    • (b) Empfang des an den ersten Nutzer gelieferten passenden Schlüssels durch einen zweiten Nutzer (Verkäufer); und
    • (c) Vergleichen des von dem ersten Nutzer an den zweiten Nutzer gelieferten Schlüssels mit dem Schlüssel, der an den ersten Nutzer geliefert wurde, nachdem der zweite Nutzer den Schlüssel von dem ersten Nutzer empfangen hat.
  • Gemäß diesem Aspekt der Erfindung kann die Verwendung von temporären Informationen zum Authentifizieren von Transaktionen zwischen Nutzern A und B ein sicheres, komfortables und hochzuverlässiges Authentifizierungssystem vorsehen.
  • Andere Ziele, Merkmale und Vorteile der vorliegenden Erfindung gehen aus der folgenden eingehenden Beschreibung in Verbindung mit den beiliegenden Zeichnungen deutlicher hervor.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • 1 ist ein Diagramm, das eine Konfiguration eines Authentifizierungs- und Zahlungssystems gemäß der vorliegenden Erfindung zeigt;
  • 2 ist ein Flussdiagramm, das Schritte in einer beispielhaften Konfiguration zur beiderseitigen Authentifizierung und Bezahlung zeigt;
  • 3 ist ein Diagramm, das einen Bildschirm einer beispielhaften Transaktionsseite zeigt;
  • 4 ist ein Diagramm, das Schritte bei einem Prozess zur Gleichheitsprüfung von Transaktionen zeigt;
  • 5A und 5B sind Flussdiagramme, die Schritte bei einem beispielhaften Vorverarbeitungsprozess zeigen;
  • 6 ist ein Diagramm, das Schritte bei einem Prozess zum Starten einer Transaktion zeigt, die beginnt, bevor ein Kunde ein Restaurant betritt;
  • 7 ist ein Diagramm, das Schritte bei einem Prozess zum Verarbeiten einer Transaktion an der Rezeption eines Restaurants zeigt;
  • 8A und 8B sind schematische Diagramme, die Typen von Transaktionsgleichheitsprüfungen zeigen;
  • 9 ist ein Blockdiagramm, das wichtige Funktionsblöcke in einem Authentifizierungs- und Zahlungssystem zeigt;
  • 10 ist ein Diagramm, das eine beispielhafte Hardware-Konfiguration eines Anbieters zeigt;
  • 11 ist ein Diagramm, das wichtige Funktionsblöcke in Nutzerterminals zeigt; und
  • 12 ist ein schematisches Diagramm, das ein Authentifizierungsverfahren zeigt, an dem ein Server und zwei Nutzer beteiligt sind.
  • EINGEHENDE BESCHREIBUNG DER ERFINDUNG
  • Unter Bezugnahme auf die beiliegenden Zeichnungen folgt nun eine Beschreibung von Ausführungsformen der vorliegenden Erfindung. Es sei erwähnt, dass identische oder entsprechende Elemente in den Ausführungsformen in allen Zeichnungen mit identischen oder entsprechenden Bezugszeichen versehen sind, wobei eingehende Beschreibungen solcher Elemente einmal vorgenommen und danach weggelassen werden.
  • 1 ist ein Diagramm, das eine Konfiguration eines Authentifizierungs- und Zahlungssystems gemäß der vorliegenden Erfindung zeigt.
  • In 1 umfasst das System Terminals 101 bis 10N eines Nutzers A (eines ersten Nutzers, wie z. B. einer Einzelperson), Terminals 201 bis 20M eines Nutzers B (eines zweiten Nutzers, wie z. B. eines Ladens), ein Internet-Kommunikationsnetz 30 und einen Anwendungsdienst-Anbieter 40. Zusätzlich hat der Anbieter 40 ein Authentifizierungs-/ Zahlungssystem 41, eine Datenbank 42 des Nutzers A und eine Datenbank 43 des Nutzers B.
  • Der Nutzer A ist ein Nutzer dieses Systems, das heißt, eine Person, die eine Dienstleistung in Anspruch nimmt oder ein Produkt kauft. Der Nutzer B ist auch ein Nutzer dieses Systems und führt eine Transaktion mit dem Nutzer A durch und bietet eine Dienstleistung an oder verkauft ein Produkt.
  • Die Datenbank 42 des Nutzers A enthält eine ID-Nummer des Nutzers A, ein Passwort, die Zahlung oder Zahlungsinformationen und Informationen bezüglich der Autorisierung zum Kaufen von Ware. Ähnlich enthält die Datenbank 43 des Nutzers B eine ID-Nummer des Nutzers B, ein Passwort, die Zahlung oder Zahlungsinformationen und die Autorisierung zum Kaufen von Ware.
  • Das Authentifizierungs- und Zahlungssystem 41 verwendet temporäre Informationen, wie später beschrieben, um Transaktionen zwischen den Nutzern A und B zu authentifizieren, um ein sicheres, komfortables und hochzuverlässiges Zahlungssystem vorzusehen. Zusätzlich prüft das Authentifizierungs- und Zahlungssystem 41 auch, ob die Nutzer A und B dazu autorisiert sind, das System zu verwenden, und ob die Nutzer A und B dazu autorisiert sind, die besondere künftige Transaktion durchzuführen.
  • Zudem brauchen die Terminals 101 bis 10N des Nutzers A und die Terminals 201 bis 20M des Nutzers B keine ortsfesten Terminals zu sein. Durch Installieren eines Browsers und Verbinden mit einem Anwendungsdienst-Anbieter 40 über das Kommunikationsnetz 30 ist es möglich, die Webseite anzuschauen, die durch den Anbieter 40 bereitgestellt wird.
  • 2 ist ein Flussdiagramm, das Schritte in einer beispielhaften Konfiguration zur beiderseitigen Authentifizierung und Bezahlung zeigt.
  • Wenn zum Beispiel ein reisender Handelsvertreter (Nutzer B) die Wohnung besucht, möchte der Wohnungsinhaber (Nutzer A) wissen, ob der Vertreter legitimiert ist und der Preis vernünftig ist, und umgekehrt möchte der Vertreter wissen, ob die Person, die ihm die Tür öffnet, für die Ware zahlungsfähig ist. Beide Fragestellungen können mit Hilfe eines tragbaren Terminals beantwortet werden.
  • Mit anderen Worten: durch Ausführen einer Autorisierung unter Anwendung der folgenden Schritte kann die Ware in dem Wissen, dass kein Beteiligter für den anderen ein Problem darstellt, sicher übergeben werden.
  • Es wird angenommen, dass die Nutzer A und B (im Folgenden manchmal als Käufer und Verkäufer bezeichnet) dieses Systems Abonnenten des Anwendungsdienst-Anbieters 40 sind und dass der Käufer und der Verkäufer bei dem Schritt S10 jeweils individuell registriert worden sind.
  • Wenn als Nächstes der Verkäufer den Käufer in dessen Wohnung anruft, hat jeder im Voraus ein tragbares Terminal und dergleichen bereitgestellt. Dabei geben der Käufer und der Verkäufer ihre jeweiligen Passwörter A und B ein, wobei der Anbieter bei Schritt S11 die Authentifizierung vorsieht, dass auf den Dienst zugegriffen werden kann.
  • Als Nächstes wird bei Schritt S12 bestimmt, ob der Käufer und der Verkäufer jeweilig dazu in der Lage sind oder nicht, sich an der Transaktion zu beteiligen. Zum Beispiel wird bestimmt, ob der Käufer dazu autorisiert ist oder nicht, die Ware zu kaufen, und ob der Verkäufer dazu autorisiert ist, die Ware zu verkaufen.
  • Der Anbieter 40 prüft die Datenbank 42 des Käufers (des Nutzers A) und die Datenbank 43 des Verkäufers (des Nutzers B). Daher kann ein Käufer, bei dem festgestellt wird, dass er keine Autorisierung zum Kauf der Ware besitzt, keine weiteren Transaktionen mehr durchführen. Ähnlich kann ein Verkäufer, bei dem festgestellt wird, dass er keine Autorisierung zum Verkaufen der Ware besitzt, keine weiteren Transaktionen mehr durchführen. Dadurch wird es möglich, jene Käufer, die nicht zahlungsfähig sind, und jene Verkäufer, die nicht zum Verkauf befähigt sind, zu eliminieren, wodurch eine sichere geschäftliche Transaktion ermöglicht wird.
  • Falls festgestellt wird, dass sowohl der Käufer zum Kauf befähigt ist als auch der Verkäufer zum Verkauf befähigt ist, erfolgt dann bei Schritt S13 die Selektion von Transaktionsschlüsseln.
  • 3 ist ein Diagramm, das einen Bildschirm für eine beispielhafte Transaktionsseite zeigt.
  • Wie in 3 gezeigt, hat der Bildschirm der Transaktionsseite Transaktionsschlüssel 1–N sowie Schaltflächen 501 bis 50N des Nutzers A (des Käufers) und Schaltflächen 511 bis 51N des Nutzers B (des Verkäufers), die jenen Schlüsseln entsprechen.
  • Die Nutzer A und B schauen auf den Bildschirm mit der gleichen Transaktionsseite. Der Bildschirm mit der Transaktionsseite zeigt die Transaktionsschlüssel, die verwendet werden können.
  • Bei Schritt S13 entscheiden der Käufer und der Verkäufer gemeinsam, welche Transaktionsschlüssel sie verwenden wollen, wobei sie im weiteren Verlauf die Schaltflächen anklicken. Falls zum Beispiel der Transaktionsschlüssel 2 verwendet werden soll, klickt dann der Käufer auf die Schaltfläche 502 und klickt der Verkäufer auf die Schaltfläche 512 .
  • Wenn diese Schaltflächen betätigt sind, werden die Nutzer jeweils mit separaten Schlüsseln beliefert, die zusammenpassen (im Folgenden passende Schlüssel, die nicht mit identischen Schlüsseln zu verwechseln sind), wobei solche Schlüssel auf den jeweiligen Bildschirmen des Käufers und Verkäufers bei Schritt S15 angezeigt werden.
  • Als Nächstes teilen der Nutzer A und der Nutzer B dem jeweils anderen mündlich die passenden Schlüssel mit, die von dem Anbieter 40 geliefert wurden.
  • Als Nächstes geben die Nutzer A und B bei Schritt S16 jeweils den passenden Schlüssel, der durch den anderen geliefert wurde, bei der gemeinsamen Transaktionsnummer ein (hier die Nummer, die dem Transaktionsschlüssel 2 entspricht).
  • Bei Schritt S17 bestimmt der Anbieter 40, ob die gemeinsame Transaktionsnummer und die zwei passenden Schlüssel von dem Käufer und Verkäufer dieselben Schlüssel sind oder nicht, die durch den Anbieter 40 geliefert wurden, indem die Schlüssel verglichen werden.
  • Bei Schritt S18 führt der Anbieter 40 dann die Resultate der Bestimmung dem Käufer und Verkäufer zu.
  • Falls der Vergleich gut ist, ist dann klar, dass es mit den Beteiligten keine Probleme gibt und die Ware den Besitzer wechselt, womit die Transaktion endet.
  • Als Nächstes verwendet der Anbieter 40 die Zahlungsfunktion, um bei Schritt S19 die Zahlung auszuführen.
  • Es sei erwähnt, dass bei Bedarf, wenn durch den Anbieter 40 jedem der passende Schlüssel des anderen mitgeteilt wird, den Nutzern A und B der zur Zahlung erforderliche und festgelegte Geldbetrag mitgeteilt werden kann.
  • Zusätzlich sei erwähnt, dass der Verkäufer B, auch wenn er in dem oben beschriebenen Fall eine Person ist, eine Korporation sein kann.
  • Unter Verwendung von 4 wird nun der Prozess zum Vergleichen der Schlüssel (Schritte S14–S18 in der obigen 2) beschrieben.
  • 4 ist ein Diagramm, das Schritte bei einem Prozess zur Gleichheitsprüfung von Transaktionen zeigt.
  • In 3 klickt der Nutzer A, wie oben beschrieben, für den Transaktionsschlüssel 2 die Schaltfläche 502 an und klickt der Nutzer B die Schaltfläche 512 an, mit dem Ergebnis, dass bei den Schritten S21 bzw. S22 ein persönlicher Schlüssel (passender Schlüssel) A an den Nutzer A geliefert wird und ein persönlicher Schlüssel (passender Schlüssel) B an den Nutzer B geliefert wird.
  • Der persönliche Schlüssel A und der persönliche Schlüssel B sind verschiedene Schlüssel, und beide Schlüssel stellen Informationen dar, die für den Transaktionsschlüssel 2 relevant sind. Falls die persönlichen Schlüssel A und B passen, können dann Informationen erhalten werden, die für den Transaktionsschlüssel 2 relevant sind.
  • Der Transaktionsschlüssel 2 ist beiden Nutzern gemeinsam. Jedoch stellt der persönliche Schlüssel A Informationen dar, die nur dem Nutzer A bekannt sind, und gleichfalls ist der persönliche Schlüssel B nur dem Nutzer B bekannt.
  • Die Nutzer A und B tauschen persönliche Schlüssel A und B bei Schritt S23 aus. Bei den Schritten S25, S26 werden auf einem durch den Anbieter 40 bereitgestellten Bildschirm die von jedem der Nutzer an den anderen gelieferten Schlüssel bezüglich des Transaktionsschlüssels 2 eingegeben.
  • Die individuellen Schlüsseleingaben werden, wie zum Beispiel bei den Schritten S25, S26 in 4 gezeigt, durch die Nutzer, für die die Bildschirme bereitgestellt worden sind, in die Bildschirme A und B eingegeben, wobei die Bildschirme dieselben wie jener sind, der durch den Anbieter 40 bereitgestellt wurde.
  • Es sei erwähnt, dass der persönliche Schlüssel selbst bei Schritt S26 nicht dargestellt ist, wie im Diagramm gezeigt.
  • Der Anbieter 40 bestimmt dann, ob der persönliche Schlüssel A des Nutzers A und der persönliche Schlüssel B, der von dem anderen Beteiligten für die Transaktion erhalten wurde, passen oder nicht, und bei Schritt S27 werden die Resultate jener Bestimmung dem Nutzer A zugeführt. Ähnlich bestimmt der Anbieter auch, ob der persönliche Schlüssel B des Nutzers B und der persönliche Schlüssel A, der von dem anderen Beteiligten für die Transaktion erhalten wurde, passen oder nicht, und bei Schritt S28 werden die Resultate jener Bestimmung dem Nutzer B zugeführt.
  • Falls sie passen, ist dann durch den Anbieter 40 entschieden worden, dass die Personen, die tatsächlich präsent sind, dazu autorisiert sind, die Transaktionen durchzuführen.
  • Die vorliegende Erfindung kann auch in einem Restaurant zum Einsatz kommen, wobei eine Beschreibung einer Ausführungsform der vorliegenden Erfindung unter Bezugnahme auf dieselbe und auf 5A, 5B, 6 und 7 erfolgt.
  • 5A und 5B sind Flussdiagramme, die Schritte in einem beispielhaften Diagramm eines Vorverarbeitungsprozesses darstellen, das eine Variante der in 4 abgebildeten Grundlage zeigt. 6 ist ein Diagramm, das Schritte bei einem Prozess zum Starten einer Transaktion zeigt, die beginnt, bevor ein Kunde ein Restaurant betritt.
  • Es wird angenommen, dass sowohl der Kunde des Restaurants als auch das Restaurant, die dieses System nutzen, Abonnenten bei demselben Anwendungsdienst-Anbieter sind und sich individuell registrieren lassen haben.
  • In 5A lässt sich der Restaurantbenutzer bei Schritt S30 bei einem Anbieter registrieren und empfängt bei Schritt S31 ein persönliches ID und Passwort.
  • In 5B lässt sich das Restaurant bei Schritt S32 bei dem Anbieter registrieren und empfängt bei Schritt S33 ein persönliches ID und Passwort.
  • 6 ist ein Diagramm, das Schritte bei einem Prozess zum Starten einer Transaktion zeigt, die beginnt, bevor ein Kunde ein Restaurant betritt.
  • Der Kunde des Restaurants setzt sich unter Verwendung eines Terminals, wie etwa eines Personalcomputers oder eines tragbaren Terminals, mit einem Anbieter in Verbindung, gibt ein ID/Passwort ein und loggt sich ein (bei Schritt S40). Als Nächstes spezifiziert der Restaurantkunde bei Schritt S41 einen Transaktionstyp oder einen Authentifizierungsbereich. Speziell gibt der Kunde an, dass er von dem betreffenden Restaurant eine besondere Dienstleistung in Anspruch nehmen oder einen Artikel kaufen möchte.
  • Dabei kann der Restaurantkunde bei Bedarf Bedingungen der Transaktion spezifizieren (zum Beispiel ob ein privater Raum benötigt wird usw.).
  • Bei Schritt S42 wird ein Transaktionsschlüssel ausgewählt und wird ein persönlicher Schlüssel A erhalten.
  • Der Kunde wählt dann bei Schritt S42 einen Transaktionsschlüssel aus und erhält einen persönlichen Schlüssel A von dem Anbieter.
  • Danach informiert jener Anbieter bei Schritt S43 das bezeichnete Restaurant per E-Mail, dass eine Transaktionsanfrage (hier eine Reservierung) vorliegt, und sieht einen Transaktionsschlüssel vor.
  • Im Restaurant wird die Reservierung bei Schritt S44 empfangen. Das Restaurant setzt sich bei Schritt S45 mit dem Anbieter in Verbindung, gibt ein ID/Passwort ein und loggt sich ein. Als Nächstes wird bei Schritt S46 der vorgesehene Transaktionsschlüssel entweder ausgewählt oder eingegeben und wird ein persönlicher Schlüssel B von dem Anbieter erhalten.
  • 7 ist ein Diagramm, das Schritte bei einem Prozess zum Verarbeiten einer Transaktion an der Rezeption des Restaurants zeigt. Der Kunde ist jetzt eingetroffen.
  • Der Restaurantkunde kommt bei Schritt S50 an der Rezeption an und teilt der Person an der Rezeption mündlich den Transaktionsschlüssel und den persönlichen Schlüssel A mit.
  • Es sei erwähnt, dass die Lieferung des Transaktionsschlüssels A und des persönlichen Schlüssels an das Restaurant per E-Mail erfolgen kann und anstelle des Kunden durch den Anbieter vorgenommen werden kann.
  • Die Person an der Rezeption des Restaurants teilt dann bei Schritt S51 dem Kunden mündlich den Transaktionsschlüssel und den persönlichen Schlüssel B mit.
  • Danach setzen sich das Restaurant und der Restaurantkunde bei den Schritten S52 und S54 jeweils separat mit dem Anbieter in Verbindung, geben ihre jeweiligen IDs und Passwörter ein und loggen sich ein.
  • Der Restaurantkunde gibt bei Schritt S53 den Transaktionsschlüssel, den persönlichen Schlüssel B und einen Geldbetrag auf einem durch den Anbieter bereitgestellten Bildschirm ein. Ähnlich gibt auch das Restaurant bei Schritt S55 den Transaktionsschlüssel, den persönlichen Schlüssel A und einen Geldbetrag ein.
  • Der Anbieter bestimmt dann, ob die separaten Transaktionsschlüssel für den Transaktionsschlüssel passen, und informiert bei Schritt S56 das Restaurant und den Restaurantkunden über die Resultate jener Bestimmung.
  • Bei den Schritten S57 und S58 werden die Gleichheitsprüfungsresultate an den jeweiligen Terminals des Restaurants und des Restaurantkunden angezeigt.
  • Als Resultat kann der Restaurantkunde, der eine Reservierung vornimmt, eine Dienstleistung mit den gewünschten Konditionen in Anspruch nehmen.
  • Es sei erwähnt, dass nicht unbedingt eine Spalte für den Betrag vorgesehen sein muss und auch nicht unbedingt ein Betrag zugeführt werden muss, um die Authentifizierung auszuführen.
  • Der Anbieter 40 bestimmt, wie oben beschrieben, ob der gemeinsame Transaktionsschlüssel auf der einen Seite und die individuellen Schlüssel A und B auf der anderen Seite tatsächlich passen. Solche Bestimmungen erfolgen nach zwei Typen, wie in 8A und 8B gezeigt.
  • 8A und 8B sind schematische Diagramme, die Typen von Transaktionsgleichheitsprüfungen zeigen. Ein Typ ist der von 8A, bei dem der Anbieter persönliche Schlüssel A und B für einen gemeinsamen Transaktionsschlüssel vorsieht. Der oben beschriebene Prozess ist ein Beispiel für solch einen Bestimmungstyp.
  • Im Gegensatz dazu zeigt 8B ein Beispiel, bei dem persönliche Schlüssel A und B jeweils einzigartige Informationen liefern und in der Kombination den gemeinsamen Transaktionsschlüssel bilden.
  • Solche einzigartigen Informationen können zum Beispiel die persönlichen IDs sein, die zur Authentifizierung verwendet werden. Als Alternative und zusätzliche Sicherheitsvorkehrung kann das persönliche ID selbst, das zur Verifizierung verwendet wird, zum Beispiel durch ein temporäres persönliches ID ersetzt werden, das nur zum Zweck des Einloggens verwendet wird.
  • Der gemeinsame Transaktionsschlüssel selbst wird einfach zum Identifizieren der Transaktion verwendet und braucht nicht unbedingt geheimgehalten werden. Um jedoch einen besonderen Transaktionsschlüssel von einem anderen zu unterscheiden, ist es wünschenswert, einen spezifischen Transaktionsschlüssel zu erzeugen.
  • Um zum Beispiel einen gemeinsamen Transaktionsschlüssel zu bilden, genügt es, die zwei persönlichen Schlüssel A und B einfach zusammenzuführen, um eine einzigartige dritte Nummer zu bilden. Oder es kann, als Alternative, solch eine einzigartige Nummer durch Ausführen irgendeiner logischen Berechnung auf der Basis der persönlichen Schlüssel A und B erzeugt werden.
  • Falls zum Beispiel der persönliche Schlüssel A aus der Zahl 1234 besteht und der persönliche Schlüssel B aus den Zahlen 5678 besteht, kann die gemeinsame Transaktion einfach 12345678 lauten. Alternativ dazu können die zwei Zahlen des persönlichen Schlüssels multipliziert werden, woraus sich ein gemeinsamer Transaktionsschlüssel ergibt, der aus der Zahl 7006652 besteht. Ein anderer alternativer gemeinsamer Transaktionsschlüssel kann unter Verwendung eines Logarithmus der zwei persönlichen Schlüssel A und B erzeugt werden.
  • Als vorteilhaft wird empfunden werden, dass es bei dem Bestimmungsprozess des in 8B gezeigten Typs nicht erforderlich ist, einen persönlichen Schlüssel zu erzeugen und bereitzustellen.
  • Die vorliegende Erfindung kann auch in Hotelreservierungssystemen zum Einsatz kommen.
  • Wenn zum Beispiel eine Reservierung in einem Hotel vorgenommen wird, das diesen Dienst abonniert hat, kann der Kunde ein Internet-fähiges Terminal (ein tragbares oder ein anderes) verwenden, um eine Reservierung vorzunehmen und einen persönlichen Schlüssel A (eine Reservierungsnummer) zu erhalten. In dem Hotel, in dem die Reservierung erfolgt, wird die Reservierung des Kunden bestätigt und wird ein persönlicher Schlüssel B (eine Bestätigungsnummer) an den Kunden geliefert, der die Reservierung vornimmt.
  • Der Kunde, der die Reservierung vornimmt, gibt dann die Bestätigungsnummer ein, um eine Prüfung des Hotels zu vollenden. Beim Einchecken verwendet das Hotel die Reservierungsnummer von dem Kunden, um den Kunden zu authentifizieren und die Zahlung zu bestätigen.
  • Zudem kann die vorliegende Erfindung auch an die Verwendung beim Vornehmen von Reservierungen in einem Vergnügungspark, einem Kino oder dergleichen angepasst werden.
  • Beim Vornehmen einer Reservierung beispielsweise in einem teilnehmenden Vergnügungspark oder einer anderen derartigen Einrichtung erwirbt der Kunde zuerst eine Reservierungsnummer, tauscht etwaige erforderliche Informationen aus und kann Zugang zu der Einrichtung erlangen, indem er die Reservierungsnummer an einem Computer vor Ort eingibt.
  • 9 ist ein Blockdiagramm, das die wichtigsten Funktionsblöcke in einem Authentifizierungs- und Zahlungssystem zeigt.
  • Eine Zahlungseinheit 54 wickelt die Transaktion ab, wenn eine Authentifizierung und Transaktion ausgeführt worden sind. Eine Mitteilungseinheit 55 beliefert beide Nutzer der Transaktion mit verschiedenen Schlüsseln, versieht die Nutzer mit Informationen diesbezüglich, ob die Schlüssel passen, und beliefert die Nutzer im Allgemeinen mit Informationen hinsichtlich der Transaktion.
  • Eine Empfangseinheit 56 empfängt die passenden Schlüssel, die an jeden Nutzer geliefert wurden und die die Nutzer austauschen. Nachdem ein zweiter Nutzer den Schlüssel von dem ersten Nutzer empfangen hat, prüft und authentifiziert die Vergleichseinheit 57 den Schlüssel. Ähnlich authentifiziert die Vergleichseinheit 57 den Schlüssel, nachdem der erste Nutzer den Schlüssel von dem zweiten Nutzer empfangen hat.
  • Die Glaubwürdigkeitsprüfeinheit 58 überprüft, dass die Nutzer des Systems dazu autorisiert sind, das System zu verwenden, und dazu befähigt sind, sich an der Transaktion zu beteiligen.
  • 10 ist ein Diagramm, das eine beispielhafte Hardware-Konfiguration 40 eines Anbieters zeigt.
  • Die Hardware-Konfiguration 40 umfasst, wie in 10 gezeigt, eine Eingabevorrichtung 61, die eine Tastatur, eine Zeigevorrichtung und dergleichen enthält; eine zentrale Verarbeitungseinheit (CPU) 62; einen Nur-Lese-Speicher (ROM) 63; einen Speicher mit wahlfreiem Zugriff (RAM) 64; eine Schnittstelle (IF) 65, die mit einem Kommunikationsnetz 20 verbindet; einen internen Bus 66; eine Schnittstelle (IF) 65, die mit einem Festplattenlaufwerk (HDD), Drucker und Scanner verbindet; ein anderes HDD 68; ein Diskettenlaufwerk (FDD) 69, das Informationen von einer Diskette (FD) liest und Informationen auf diese schreibt; eine CD-ROM-Laufwerkseinheit 70, die Informationen von einer CD-ROM liest; und einen Controller 71, der die Anzeige einer Anzeigeeinheit 74 steuert.
  • Die Funktionen der verschiedenartigen Hardwareelemente sind gemeinhin bekannt, so dass eine Beschreibung davon weggelassen wird. Als vorteilhaft kann empfunden werden, dass der Zweck solch einer Konfiguration das Vornehmen der Authentifizierung unter Verwendung eines Aufzeichnungsmediums ist, auf dem ein Programm zum Ausführen der Authentifizierung gemäß der vorliegenden Erfindung aufgezeichnet ist, um zu bewirken, dass die CPU 62 das Programm ausführt und die Authentifizierung vornimmt.
  • Es sei erwähnt, dass das Aufzeichnungsmedium, auf dem das Programm zum Vornehmen der Authentifizierung gemäß der vorliegenden Erfindung aufgezeichnet ist, eines von einer Reihe von Medien sein kann, die durch einen Computer verwendbar sind und die Magnetplatten wie etwa Disketten, Festplatten, optische Platten (CD-ROM, CD-R, CD-R/W, DVD-ROM, DVD-RAM, etc.), magnetooptische Platten und Speicherkarten enthalten.
  • 11 ist ein schematisches Diagramm, das wichtige Funktionsblöcke in Nutzerterminals A und B zeigt.
  • Die Konfiguration umfasst, wie in dem Diagramm gezeigt, eine Sendeeinheit 80, eine Empfangseinheit 81, eine Eingabeeinheit 82 und eine Ausgabeeinheit 83.
  • Die Sendeeinheit 80 sendet Informationen, die die künftige Transaktion betreffen, an einen Server und sendet ferner Schlüssel zwischen Nutzern.
  • Die Empfangseinheit 81 empfängt die passenden Schlüssel für die Transaktion von dem Server und empfängt ferner auch die Gleichheitsprüfungsresultate.
  • Die Eingabeeinheit 82 wird verwendet, um Positionen einzugeben, die für die Authentifizierung und Zahlung benötigt werden, wie etwa IDs, Passwörter und passende Schlüssel.
  • Die Ausgabeeinheit 83 zeigt die an die Nutzerterminals gesendeten Informationen bezüglich der Authentifizierung und Bezahlung an.
  • Als günstig wird empfunden werden, wie oben beschrieben, dass es durch die Ausführungsformen der vorliegenden Erfindung unnötig wird, Kreditkarten oder Bargeld mit sich zu führen, was einen Vorteil insofern darstellt, als Bargeld und Kreditkarten verlorengehen oder gestohlen werden können und, im Falle von Kreditkarten, die Kartennummern gestohlen und missbraucht werden können, ohne die Karten selbst zu stehlen. Dadurch, dass keine Kreditkarten und auch kein Bargeld mehr mitgeführt werden müssen, werden diese Sicherheitssorgen eliminiert.
  • Unter Bezugnahme auf 12 folgt nun eine Beschreibung eines Verfahrens zum Authentifizieren einer Transaktion, die einen Reservierungsserver, der als Authentifizierungszentrale wirkt, und ein Nutzer-Paar einschließt.
  • 12 ist ein schematisches Diagramm, das ein Authentifizierungsverfahren zeigt, an dem ein Server und zwei Nutzer beteiligt sind. Das Verfahren schließt einen Server 100, einen Käufer (der ebensogut ein Verkäufer sein könnte) 101 und einen Verkäufer (der ebensogut ein Käufer sein könnte) 102 ein, wie in 12 gezeigt.
  • Bei Schritt
    Figure 00200001
    gibt der Server an den Käufer 101 einen passenden Schlüssel für eine künftige Transaktion als Antwort auf eine Anfrage von dem Käufer 101 aus. Dieser passende Schlüssel ist ein temporärer Schlüssel und soll für Dritte unbekannt bleiben.
  • Bei Schritt
    Figure 00200002
    informiert der Käufer 101 den Verkäufer 102 über den passenden Schlüssel, der von dem Server bereitgestellt wurde.
  • Bei Schritt
    Figure 00200003
    führt der Verkäufer 102 den passenden Schlüssel, der durch den Käufer 101 vorgesehen wurde, dem Server 100 zu.
  • Bei Schritt
    Figure 00200004
    erifiziert der Server 100, dass der passende Schlüssel, den er an den Käufer 101 geliefert hat, derselbe wie der passende Schlüssel ist, der durch den Verkäufer 102 an den Server 100 geliefert wurde.
  • Bei Schritt
    Figure 00200005
    werden dann, falls die Resultate ergeben, dass die Schlüssel passen, der Käufer 101 und der Verkäufer 102 diesbezüglich benachrichtigt.
  • Der Server 100 kann, wie oben beschrieben, eine Beziehung zwischen einem Käufer 101 und einem Nutzer 102, der den Schlüssel von dem Käufer 101 erhält, auf der Basis der Ausstellung eines temporären passenden Schlüssels einrichten, wobei beide Nutzer über die Resultate informiert werden.
  • Zusätzlich sieht in dem Fall, dass sich der Käufer 101 und der Verkäufer 102 registrieren lassen müssen, um dieses System zu nutzen, das oben beschriebene Verfahren eine Authentifizierung derart vor, dass die Teilnehmer an der Transaktion autorisierte Nutzer des Systems sind, wodurch zusätzliche Sicherheit geboten wird.
  • Die obige Beschreibung ist vorgesehen, um jeden Fachmann in die Lage zu versetzen, die Erfindung zu verwenden, und stellt den Modus dar, den die Erfinder zum Umsetzen der Erfindung als den besten erachten.
  • Die vorliegende Erfindung ist nicht auf die speziell offenbarten Ausführungsformen begrenzt, und Veränderungen und Abwandlungen können vorgenommen werden, ohne vom Umfang der vorliegenden Erfindung abzuweichen.
  • Die vorliegende Anmeldung basiert auf der japanischen Prioritätsanmeldung Nr. 2000-256340 , eingereicht am 25. August 2000.

Claims (6)

  1. Authentifizierungsverfahren (41) zum Authentifizieren von Nutzern, die Teilnehmer an einer Transaktion in einem Authentifizierungssystem sind, welches Verfahren durch die Schritte gekennzeichnet ist: Senden (S21) eines ersten passenden Schlüssels von dem Authentifizierungssystem an eine Terminalvorrichtung (10) eines ersten Nutzers, um einen ersten Nutzer mit dem ersten passenden Schlüssel für eine künftige Transaktion als Antwort auf die Feststellung zu beliefern, dass der erste Nutzer Bedingungen erfüllt, die zum Durchführen der künftigen Transaktion erforderlich sind; Senden (S22) eines zweiten passenden Schlüssels von dem Authentifizierungssystem an eine Terminalvorrichtung (20) eines zweiten Nutzers, um einen zweiten Nutzer mit dem zweiten passenden Schlüssel für eine künftige Transaktion als Antwort auf die Feststellung zu beliefern, dass der zweite Nutzer Bedingungen erfüllt, die zum Durchführen der künftigen Transaktion erforderlich sind; Senden (S25), von der Terminalvorrichtung (10) des ersten Nutzers, des zweiten passenden Schlüssels, der von dem Authentifizierungssystem an die Terminalvorrichtung (20) des zweiten Nutzers gesendet worden ist, an das Authentifizierungssystem, und Senden (S26), von der Terminalvorrichtung des zweiten Nutzers, des ersten passenden Schlüssels, der von dem Authentifizierungssystem an die Terminalvorrichtung des ersten Nutzers gesendet worden ist (S24), an das Authentifizierungssystem; und Vergleichen, in dem Authentifizierungssystem, des ersten passenden Schlüssels, der von der Terminalvorrichtung des zweiten Nutzers geliefert wurde, mit dem ersten passenden Schlüssel, der an den ersten Nutzer geliefert wurde, und Vergleichen, in dem Authentifizierungssystem, des zweiten passenden Schlüssels, der von der Terminalvorrichtung des ersten Nutzers geliefert wurde, mit dem zweiten passenden Schlüssels, der an den zweiten Nutzer geliefert wurde.
  2. Authentifizierungsverfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Authentifizierungssystem (41) die Identität der Nutzer vor dem Schritt des Belieferns des ersten Nutzers mit dem passenden Schlüssel authentifiziert.
  3. Authentifizierungsverfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Authentifizierungssystem (41) bestimmt, ob die geplante Transaktion innerhalb einer zuvor bestimmten finanziellen Grenze liegt.
  4. Authentifizierungsverfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Authentifizierungssystem (41) bestimmt, ob die geplante Transaktion zuvor bestimmte Bedingungen erfüllt.
  5. Authentifizierungsverfahren nach Anspruch 1, dadurch gekennzeichnet, dass bei dem Schritt zum Liefern von passenden Schlüsseln beide Nutzer mit verschiedenen Schlüsseln beliefert werden.
  6. Authentifizierungsverfahren nach einem der Ansprüche 1 bis 5, das ferner dadurch gekennzeichnet ist, dass der Schritt zum Bezahlen der Transaktion auf der Basis der Vergleichsresultate erfolgt, die bei dem Authentifizierungsverfahren erhalten wurden.
DE60133701T 2000-08-25 2001-02-26 Beglaubigungsverfahren und -system, Bezahlungssystem, Gebrauchervorrichtung und Aufzeichnungsmedium mit Programm zum Durchführen der Beglaubigung Expired - Lifetime DE60133701T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2000256340A JP2002074223A (ja) 2000-08-25 2000-08-25 認証処理方法、認証処理システム、決済方法、利用者装置及び認証処理を行うためのプログラムを格納した記憶媒体
JP2000256340 2000-08-25

Publications (2)

Publication Number Publication Date
DE60133701D1 DE60133701D1 (de) 2008-06-05
DE60133701T2 true DE60133701T2 (de) 2009-05-14

Family

ID=18744967

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60133701T Expired - Lifetime DE60133701T2 (de) 2000-08-25 2001-02-26 Beglaubigungsverfahren und -system, Bezahlungssystem, Gebrauchervorrichtung und Aufzeichnungsmedium mit Programm zum Durchführen der Beglaubigung

Country Status (4)

Country Link
US (1) US7310608B2 (de)
EP (1) EP1189184B1 (de)
JP (1) JP2002074223A (de)
DE (1) DE60133701T2 (de)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6757903B1 (en) * 1999-04-05 2004-06-29 Gateway, Inc. Object driven software architecture method and apparatus
US20020138769A1 (en) * 2001-03-23 2002-09-26 Fishman Jayme Matthew System and process for conducting authenticated transactions online
US20040139028A1 (en) * 2001-03-23 2004-07-15 Fishman Jayme Matthew System, process and article for conducting authenticated transactions
JP4076954B2 (ja) * 2002-01-28 2008-04-16 富士通株式会社 取引方法及びそれを実行するための取引システム
US20070156592A1 (en) * 2005-12-22 2007-07-05 Reality Enhancement Pty Ltd Secure authentication method and system
AU2015100744B4 (en) * 2011-08-30 2015-08-06 Ov Loop Inc. Systems and methods for authorizing a transaction with an unexpected cryptogram
BR112014004374B1 (pt) 2011-08-30 2021-09-21 Simplytapp, Inc Método para participação com base em aplicação segura em um processo de autorização de transação de cartão de pagamento por um dispositivo móvel, sistema para participação com base em aplicação segura por um dispositivo móvel em interrogações de ponto de venda
US10832278B2 (en) * 2013-11-04 2020-11-10 Mastercard International Incorporated System and method for card-linked services
CN103825746B (zh) * 2014-03-17 2017-03-01 联想(北京)有限公司 信息处理方法和装置
EP3360116A1 (de) 2015-10-09 2018-08-15 Diebold Nixdorf, Incorporated Bargeldzugang mit automatischer transaktionsmaschine mit mobiltelefon
CN106533695B (zh) * 2016-11-15 2019-10-25 北京华大智宝电子系统有限公司 一种安全认证方法以及设备

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE3775924D1 (de) * 1987-04-22 1992-02-20 Ibm Verwaltung von geheimuebertragungsschluesseln.
US5585787A (en) * 1991-12-09 1996-12-17 Wallerstein; Robert S. Programmable credit card
US5369705A (en) * 1992-06-03 1994-11-29 International Business Machines Corporation Multi-party secure session/conference
US5729608A (en) * 1993-07-27 1998-03-17 International Business Machines Corp. Method and system for providing secure key distribution in a communication system
US5461217A (en) * 1994-02-08 1995-10-24 At&T Ipm Corp. Secure money transfer techniques using smart cards
EP0760565B1 (de) * 1995-08-28 1998-07-08 Ofra Feldbau Einrichtung und Verfahren zur Authentifizierung der Absendung und des Inhalts eines Dokuments
JP3365599B2 (ja) 1996-02-08 2003-01-14 株式会社エヌ・ティ・ティ・データ 電子小切手システム
JPH1078991A (ja) 1996-09-02 1998-03-24 A L K Kk 電子決済方法
US5903652A (en) * 1996-11-25 1999-05-11 Microsoft Corporation System and apparatus for monitoring secure information in a computer network
US5982896A (en) * 1996-12-23 1999-11-09 Pitney Bowes Inc. System and method of verifying cryptographic postage evidencing using a fixed key set
US5890136A (en) * 1997-03-12 1999-03-30 Kipp; Ludwig Quick stop mass retail system
US5883810A (en) * 1997-09-24 1999-03-16 Microsoft Corporation Electronic online commerce card with transactionproxy number for online transactions
US6000832A (en) * 1997-09-24 1999-12-14 Microsoft Corporation Electronic online commerce card with customer generated transaction proxy number for online transactions
JPH11134303A (ja) 1997-10-31 1999-05-21 Fujitsu Ltd 取引処理装置
US6378072B1 (en) * 1998-02-03 2002-04-23 Compaq Computer Corporation Cryptographic system
JPH11256340A (ja) 1998-03-10 1999-09-21 Victor Co Of Japan Ltd Ｄｌｃ膜の成膜方法及びそれにより製造された磁気記録媒体
WO2000002150A1 (en) 1998-07-01 2000-01-13 Webcard Inc. Transaction authorisation method
EP1028401A3 (de) 1999-02-12 2003-06-25 Citibank, N.A. Verfahren und System zum Durchführen einer Bankkartentransaktion
US6874683B2 (en) * 1999-10-08 2005-04-05 Canon Kabushiki Kaisha User programmable smart card interface system for an image album
US6824045B2 (en) * 2000-04-20 2004-11-30 Canon Kabushiki Kaisha Method and system for using multiple smartcards in a reader
AUPQ983500A0 (en) * 2000-08-31 2000-09-28 Canon Kabushiki Kaisha Hyperlink access system

Also Published As

Publication number Publication date
DE60133701D1 (de) 2008-06-05
US20020026414A1 (en) 2002-02-28
EP1189184B1 (de) 2008-04-23
EP1189184A3 (de) 2004-05-26
US7310608B2 (en) 2007-12-18
EP1189184A2 (de) 2002-03-20
JP2002074223A (ja) 2002-03-15

Similar Documents

Publication Publication Date Title
DE69727519T2 (de) Datennetzwerk mit Stimmkontrollmitteln
DE69019037T2 (de) Mehrebenen-Sicherheitsvorrichtung und -verfahren mit persönlichem Schlüssel.
DE69938500T2 (de) Authentifizierungskartensystem mit einer entfernten zertifizierungsinstanz
DE60106569T2 (de) vERFAHREN ZUR DURCHFÜHRUNG EINER ONLINE FINANZTRANSAKTION DURCH EINEN BENUTZER
DE69913929T2 (de) Gesichertes Bezahlungsverfahren
DE69630713T2 (de) Identifikationssystem ohne identitätsmarker
DE10296919T5 (de) System und Verfahren zur sicheren Rückzahlung
DE10296888T5 (de) System und Verfahren zur sicheren Eingabe und Authentifikation von verbraucherzentrierter Information
DE60133701T2 (de) Beglaubigungsverfahren und -system, Bezahlungssystem, Gebrauchervorrichtung und Aufzeichnungsmedium mit Programm zum Durchführen der Beglaubigung
DE20220745U1 (de) Sicheres Online-Zahlungssystem
DE60008669T2 (de) Verfahren zum Durchführen einer On-Line Zahlungstransaktion mit einer vorausbezahlten Karte und zugeordnete Karte
DE60102469T2 (de) Verfahren, system und datenträger zum authentifizieren eines kunden mit dem wunsch eine dienstleistung oder ein produkt von einem lieferanten zu bekommen
DE102005008610A1 (de) Verfahren zum Bezahlen in Rechnernetzen
WO2001095167A2 (de) Virtueller marktplatz
DE10022973A1 (de) Verfahren zur Abwicklung von Geldgeschäften über elektronische Übertragungsmedien
DE212019000441U1 (de) Einkaufsmanagementsystem
DE60109331T2 (de) Universeller bezahlungsaktivierer, der das mobiltelefonnetz verwendet
DE60122912T2 (de) Verfahren zum liefern von identifikationsdaten einer bezahlkarte an einen anwender
WO2001065510A1 (de) Im internetfähigen bargeldlosen zahlungsverkehr
DE202019106383U1 (de) Elektronische Zahlungsvorrichtung
EP1172770B1 (de) Verfahren und System zur Authentifizierung eines Teilnehmers an einem Geschäftsvorgang
DE69730435T2 (de) System, verfahren und hergestellter gegenstand für die architektur virtueller verkaufspunkte mit mehreren eingangspunkten
DE60122940T2 (de) Verfahren zum Online-Einkaufen mit hoher Betriebssicherheit
DE102018112795A1 (de) Verfahren zur Erzeugung eines Finanzierungsangebots
EP2885752A1 (de) Verfahren und system zur durchführung einer finanz-transaktion

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8328 Change in the person/name/address of the agent

Representative=s name: SEEGER SEEGER LINDNER PARTNERSCHAFT PATENTANWAELTE