DE10310527B4 - Verfahren zum Initiieren und/oder Durchführen einer Zahlungstransaktion - Google Patents

Verfahren zum Initiieren und/oder Durchführen einer Zahlungstransaktion Download PDF

Info

Publication number
DE10310527B4
DE10310527B4 DE10310527A DE10310527A DE10310527B4 DE 10310527 B4 DE10310527 B4 DE 10310527B4 DE 10310527 A DE10310527 A DE 10310527A DE 10310527 A DE10310527 A DE 10310527A DE 10310527 B4 DE10310527 B4 DE 10310527B4
Authority
DE
Germany
Prior art keywords
transaction
payment
parties
instance
data
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 - Fee Related
Application number
DE10310527A
Other languages
English (en)
Other versions
DE10310527A1 (de
Inventor
Christian Hogl
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.)
HOGL, CHRISTIAN, 81371 MUENCHEN, DE
Original Assignee
Individual
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
Priority to DE10310527A priority Critical patent/DE10310527B4/de
Application filed by Individual filed Critical Individual
Priority to CA002518448A priority patent/CA2518448A1/en
Priority to AU2004219478A priority patent/AU2004219478A1/en
Priority to PCT/EP2004/002520 priority patent/WO2004081892A2/de
Priority to US10/548,492 priority patent/US7702581B2/en
Priority to CN200480012808.6A priority patent/CN1788292A/zh
Priority to JP2006504645A priority patent/JP2006524938A/ja
Priority to EP04719443A priority patent/EP1602088A2/de
Publication of DE10310527A1 publication Critical patent/DE10310527A1/de
Application granted granted Critical
Publication of DE10310527B4 publication Critical patent/DE10310527B4/de
Priority to US12/728,544 priority patent/US8065232B2/en
Priority to US13/285,201 priority patent/US8566238B2/en
Priority to US13/941,807 priority patent/US8831990B2/en
Priority to US14/476,780 priority patent/US20140372292A1/en
Anticipated expiration legal-status Critical
Expired - Fee Related 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/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/405—Establishing or using transaction specific rules
    • 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/04—Payment circuits
    • 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/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • 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
    • G06Q20/105—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems involving programming of a portable memory device, e.g. IC cards, "electronic purses"
    • 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
    • G06Q20/108—Remote banking, e.g. home banking
    • G06Q20/1085—Remote banking, e.g. home banking involving automatic teller machines [ATMs]
    • 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/22—Payment schemes or models
    • G06Q20/223—Payment schemes or models based on the use of peer-to-peer networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3227—Aspects of commerce using mobile devices [M-devices] using secure elements embedded in M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3229—Use of the SIM of a M-device as secure element
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment 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/3674—Payment 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
    • 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/383—Anonymous user system
    • 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/385—Payment protocols; Details thereof using an alias or single-use codes
    • 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
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207—Discounts or incentives, e.g. coupons or rebates
    • G06Q30/0213—Consumer transaction fees
    • 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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • 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
    • G06Q50/00—Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/26—Government or public services
    • G06Q50/265—Personal security, identity or safety

Abstract

Verfahren zum Initiieren und/oder Durchführen einer Zahlungstransaktion zwischen mindestens zwei Transaktionsparteien, denen jeweils ein Kommunikationsgerät zugeordnet ist, über eine Abwicklungsinstanz, bei dem
a) mindestens zwei der Transaktionsparteien Daten an die Abwicklungsinstanz übermitteln, wobei diese Daten Merkmale enthalten, die die Zuordnung der Transaktionsparteien untereinander ermöglichen, und wobei die Übermittlung der Daten innerhalb eines begrenzten Zeitfensters erfolgt, und
b) die Initiierung der Datenübermittlung dieser Transaktionsparteien aktiv durch die Transaktionsparteien und nicht durch die Abwicklungsinstanz (3) erfolgt,
dadurch gekennzeichnet,
c) dass die von den mindestens zwei Transaktionsparteien bereits bei der Initiierung übertragenen Daten jeweils den zu zahlenden Betrag an Geld oder Werteinheiten enthalten und
d) dass die von jeweils einer Transaktionspartei übermittelten Daten hinreichend sind, um eine eindeutige Identifikation dieser Transaktionspartei zu ermöglichen, aber nicht hinreichend sind, um eine Identifikation der anderen Transaktionspartei zu ermöglichen.

Description

  • Die vorliegende Erfindung betrifft ein Verfahren zum Initiieren und/oder Durchführen einer Zahlungstransaktion zwischen mindestens zwei Transaktionsparteien, denen jeweils ein Kommunikationsgerät zugeordnet ist, über eine Abwicklungsinstanz.
  • Zahlungstransaktionen stellen aufgrund ihrer Häufigkeit und wirtschaftlichen Bedeutung das hauptsächliche Anwendungsgebiet der vorliegenden Erfindung dar.
  • Es sind eine Vielzahl von Verfahren zur Durchführung von Zahlungstransaktionen mit Hilfe von Mobiltelefonen bekannt. Die Vorteile dieser Verfahren sind z. B. in der DE 1990 38 22 beschrieben.
  • Diese Verfahren sind in der Regel so ausgestaltet, dass die Transaktionsparteien mit einer Abwicklungsinstanz und ggf. untereinander Daten austauschen.
  • Hierbei ist zu unterscheiden zwischen zwei Verfahrenstypen, die im folgenden als „standardkompatible Verfahren des Typs A" und „zukunftsabhängige Verfahren des Typs B" bezeichnet werden sollen.
  • „Standardkompatible Verfahren des Typs A" bezieht sich auf solche Verfahren, die innerhalb der gesamten gegenwärtigen „Installed Base" von Mobiltelefonen einsetzbar sind (d. h. mit allen oder dem überwiegenden Teil der nach dem Stand der Technik verbreiteten Mobiltelefone/SIM-Modul-Chipkarten), ohne dass ein Austausch oder technische Modifikationen der Mobiltelefone oder der SIM-Modul-Chipkarten nötig wird.
  • „Zukunftsabhängige Verfahren des Typs B" bezieht sich auf solche Verfahren, die nur mit speziellen Mobiltelefonen oder SIM-Modulen (in der Regel neueren Typs) eingesetzt werden können, welche erst in geringer Stückzahl auf dem Markt verbreitet sind oder erst in Zukunft auf den Markt kommen werden.
  • Bei den zukunftsabhängigen Verfahren des Typs B geschieht der Datenaustausch zumindest einer Transaktionspartei in der Regel über Protokolle bzw. Verfahren wie WAP (Wireless Application Protocol) oder i-Mode (überwiegend in Japan verbreitet) („i-Mode” ist eine Marke der Firma NTT DoCoMo, Inc., Japan) sowie über lokal auf den Mobiltelefonen oder den SIM-Modul-Chipkarten ausgeführten Java- oder SIM-Application-Toolkit-Applikationen („JAVA” ist eine Marke der Firma Sun Microsystems, Inc., USA), wobei der Datenaustausch z. B. über GPRS (GSM Packet Radio Service) erfolgt.
  • Nachteilig an den zukunftsabhängigen Verfahren des Typs B ist, dass sie von der Verbreitung und dem Erfolg der zugrundeliegenden technologischen Basis abhängig sind. Ein Betreiber, der ein solches Verfahren einführen möchte, steht vor der Wahl, sich auf eine sehr kleine potentielle Nutzerbasis zu stützen oder potentielle Nutzer (z. B. durch Subventionen) dazu zu bewegen, sich neue Mobiltelefon-Endgeräte anzuschaffen. Dies stellt eine sehr große Hürde für die Einführung eines solchen Verfahrens dar.
  • Weiterhin nachteilig an den zukunftsabhängigen Verfahren des Typs B ist, dass sie in der Regel nur in Mobilfunk-Netzen mit einem bestimmten Standard (wie z. B. GSM) sowie nicht mit einfachen Festnetztelefonen einsetzbar sind.
  • Bei den standardkompatiblen Verfahren des Typs A geschieht der Datenaustausch zumindest einer Transaktionspartei in der Regel über eine stehende Telefonverbindung mit Sprachansagen (z. B. durch ein IVR-System (Interactive Voice Response)) und DTMF-Ton-Übermittlung (Dual Tone Multi Frequency) oder per SMS (Short Message System). In der Regel erfolgt bei diesen Verfahren die Übermittlung der vollständigen Mobiltelefon-Nummer (ANI bzw. MSISDN) oder eines eindeutigen Alias vom Zahler bzw. Empänger an den Empfänger bzw. Zahler, die Übermittlung eines dauerhaft gültigen PIN-Codes vom Zahler an eine Abwicklungsinstanz zur Autorisierung und ggf. die Übermittlung von einmal gültigen TAN-Codes als Autorisisierungs- oder Zahlungsnachweis von der Abwicklungsinstanz zum Zahler und vom Zahler zum Empfänger.
  • Eines dieser Verfahren, das sogenannte Paybox-Verfahren, ist als zweites Ausführungsbeispiel der DE 1990 38 22 bekannt. Dieses Verfahren soll beispielhaft als Vertreter eines standardkompatiblen Verfahrens des Typs A kurz dargestellt werden:
    Der Zahler (im folgenden Z genannt) übermittelt zunächst mündlich seine Mobiltelefon-Nummer (ANI bzw. MSISDN) oder einen der Mobiltelefon-Nummer eindeutig zugeordneten Alias an den Empfänger (E). Daraufhin übermittelt E an die Abwicklungsinstanz (AI) über einen Anruf seines Mobiltelefons implizit seine eigene Mobiltelefon-Nummer und explizit per DTMF-Ton-Übermittlung die Mobiltelefon-Nummer von Z, sowie den zu zahlenden Betrag. (Die Telefonverbindung von E zur AI bleibt dabei bis zum letzten Schritt bestehen). Die Abwicklungsinstanz prüft daraufhin, ob Z ein zugelassener Teilnehmer ist und ob die Bonität von Z zur Zahlung des Betrages ausreicht. Daraufhin initiiert die AI einen Anruf auf die Mobiltelefon-Nummer von Z. Z nimmt den Anruf an. Ein Sprachcomputer der AI erzeugt eine akustische Ansage der Zahlungsinformationen (Empfänger, Zahlungsbetrag). Zur Bestätigung und Autorisierung der Zahlung gibt Z per DTMF-Ton-Übermittlung einen PIN-Code ein. Nach erfolgreicher Autorisierung übermittelt die AI an E über die noch bestehende Telefonverbindung akustisch eine Bestätigung der Zahlung.
  • Nachteilig an dem Paybox-Verfahren sind vor allem die hohen Telekommunikationskosten und die lange Abwicklungsdauer.
  • Im Paybox-Verfahren dauert der Anruf von E an die AI und die Übermittlung der Daten ca. 30 Sekunden. Etwa gleich lange dauert auch der danach erfolgende Anruf der AI an Z inklusive Ansage der Zahlungsinformationen und Abfrage der Autorisierungs-PIN. Während des zweiten Anrufs bleibt die Verbindung des ersten Anrufs bestehen. Insgesamt entstehen so Telekommunikationskosten für 90 Sekunden Mobiltelefon-Verbindungen. Sofern die Abwicklung über eine kostenfreie Rufnummer erfolgt und der Betreiber der AI die Telekommunikationskosten trägt, entstehen ihm nach dem Stand der Technik dadurch Kosten von ca. 30 Euro-Cent
  • Dadurch ist die Anwendung des Paybox-Verfahrens für kleinpreisige Zahlungstransaktionen in der Regel nicht wirtschaftlich.
  • Im Paybox-Verfahren dauert die Abwicklung der Transaktion insgesamt ca. 75 Sekunden.
  • Dadurch ist die Anwendung dieses Verfahrens in allen zeitkritischen Mobile-Commerce-Einsatzszenarien wie z. B. bei Zahlungen an Kassen im Einzelhandel sehr problematisch.
  • Die am Beispiel des Paybox-Verfahrens veranschaulichten Nachteile gelten in ähnlicher Form für viele andere standardkompatible Verfahren des Typs A.
  • So bleibt z. B. die Zeitrestriktion auch bei Einsatz eines alternativen Übertragungsverfahrens wie SMS bestehen. So ist z. B. die Zustellgeschwindigkeit einer SMS nicht gesichert und beträgt oft mehr als 30 Sekunden, im Einzelfall deutlich länger. Hinzu kommt (je nach Verfahren) die Zeit für die Eingabe und das Versenden einer SMS. (Gleiches gilt auch bei bestimmten zukunftsabhängigen Verfahren des Typs B, z. B. Einsatz des WAP-Protokolls – die Dauer von Verbindungsaufbau, Navigation und Dateneingabe sind zu lang für einen Einsatz in zeitkritischen Mobile-Commerce-Szenarien).
  • Weiterhin nachteilig an den genannten standardkompatiblen Verfahren des Typs A ist die Tatsache, dass in der Regel die vollständige Mobiltelefon-Nummer des Zahlers bzw. des Empfängers gegenüber dem Empfänger bzw. Zahler offengelegt werden müssen. Dadurch ist keine Anonymität der Transaktionsparteien untereinander gegeben. Durch Einsatz eines Rufnummern-Alias (wie z. B. im Paybox-Verfahren) ist zwar eine teilweise Anonymität hinsichtlich der tatsächlichen Mobiltelefon-Nummer des Teilnehmers gegeben, dennoch ist eine prinzipiell eindeutige Identität einer Transaktionspartei der anderen Transaktionspartei bekannt.
  • Weiterhin nachteilig an der Verwendung der vollständigen Mobiltelefon-Nummer oder des Rufnummern-Alias ist deren Länge (in der Regel 12 Stellen) und die damit verbundene längere Eingabe- und Übertragungsdauer sowie die Wahrscheinlichkeit von Fehleingaben.
  • Weiterhin nachteilig an den genannten standardkompatiblen Verfahren des Typs A ist die geringe Beweissicherheit bzw. das Risiko der Abstreitbarkeit für Zahler, Empfänger und Betreiber der Abwicklungsinstanz. Eine Möglichkeit zur Erhöhung dieser Beweissicherheit besteht in der Einschaltung einer „Trusted Third Party", d. h. einer von Zahler, Empfänger und Betreiber der Abwicklungsinstanz anerkannten zusätzlichen Partei. Als eine solche zusätzliche Partei kommt insbesondere der Telekommunikations-Provider in Frage. Jedoch darf der Inhalt der innerhalb einer stehenden Telefon- oder WAP-Datenverbindung übertragenen Daten vom Telekommunikations-Provider aufgrund rechtlicher Bestimmungen in der Regel nicht protokolliert werden, ebensowenig der Inhalt von versendeten SMS.
  • Protokolliert werden daher in der Regel lediglich die Rufnummern der Kommunikationspartner, der Zeitpunkt und die Dauer der Kommunikation sowie die Menge der übertragenen Daten. Die Tatsache, dass eine Transaktion abgewickelt wurde, lässt sich so zwar grundsätzlich relativ gut beweisen. Sollte jedoch ein Streit über die Höhe des autorisierten Betrages entstehen, ist die Nachweisbarkeit problematisch. Aus diesem Grunde ist es bei Verfahren wie Paybox in der Regel notwendig, zur Reduzierung der Irrtumswahrscheinlichkeit und Vermeidung späterer Reklamationen z. B. eine SMS zur Bestätigung zu verschicken, wodurch weitere Kosten entstehen.
  • Weiterhin nachteilig an den genannten standardkompatiblen Verfahren des Typs A ist, dass ein Irrtum über den autorisierten Betrag leicht möglich ist. Dieses Risiko ergibt sich dadurch, dass der Betrag in der Regel nur von einer der Transaktionsparteien aktiv angegeben und von der anderen Transaktionspartei nur passiv bestätigt wird, z. B. nach Anzeige auf dem Mobiltelefon-Display oder nach einer akustischen Ansage der Betragshöhe.
  • Aufgabe der vorliegenden Erfindung ist es daher, ein Verfahren zum Initiieren und/oder Durchführen einer Zahlungstransaktion zwischen mindestens zwei Transaktionsparteien über eine Abwicklungsinstanz bereitzustellen, welches die vorstehend beschriebenen Probleme löst. Dies bedeutet insbesondere, dass das Verfahren mit allen oder dem überwiegenden Teil der nach dem Stand der Technik verbreiteten Mobiltelefone/SIM-Modul-Chipkarten, in Mobilfunk-Netzen mit unterschiedlichen Standards sowie mit einfachen Festnetztelefonen einsetzbar sein soll, und ferner eine kurze Abwicklungsdauer, geringe Transaktionskosten, die Anonymität der Transaktionsparteien untereinander, eine niedrige Fehlerwahrscheinlichkeit sowie eine hohe Nachweissicherheit bereitstellen soll.
  • Diese Aufgabe wird durch das Verfahren nach Anspruch 1 gelöst, wobei sich vorteilhafte Ausgestaltungen aus den Unteransprüchen ergeben.
  • Erfindungsgemäß übermitteln mindestens zwei der Transaktionsparteien Daten an die Abwicklungsinstanz, wobei diese Daten Merkmale enthalten, die die Zuordnung der Willenserklärungen untereinander ermöglichen und wobei die Initiierung der Datenübermittlung dieser Transaktionsparteien aktiv durch die Transaktionsparteien und nicht durch die Abwicklungsinstanz erfolgt. Das Merkmal der Initiierung der Datenübermittlung durch die Transaktionsparteien bedeutet, dass vor der erstmaligen Übermittlung von transaktionsrelevanten Daten von den Transaktionsparteien zur Abwicklungsinstanz keine Übermittlung von transaktionsrelevanten Daten von der Abwicklungsinstanz zu den Transaktionsparteien erfolgt.
  • Bei dem erfindungsgemäßen Verfahren erfolgt die Übermittlung der Daten simultan oder innerhalb eines begrenzten Zeitfensters (Zeitintervalls).
  • Durch die simultane und in Richtung von den Transaktionsparteien zur Abwicklungsinstanz erfolgende Datenübertragung werden Abwicklungsdauer und Transaktionskosten reduziert. Bei herkömmlichen Verfahren wie z. B. Paybox erfolgt in der Regel eine sequentielle Datenübertragung, bei einer Zahlungstransaktion z. B. erst vom Zahler zum Empfänger, dann vom Empfänger zur Abwicklungsinstanz, dann von der Abwicklungsinstanz zum Zahler, dann vom Zahler wieder zur Abwicklungsinstanz und von dieser wieder zum Empfänger.
  • Durch die simultane und aktiv von den Transaktionsparteien in Richtung zur Abwicklungsinstanz initiierte Datenübertragung wird ferner bewirkt, dass nur wenig Merkmals-Daten übermittelt werden müssen, um eine Zuordnung der Willenserklärungen und damit der Transaktionsparteien untereinander zu ermöglichen. Denn das schmale Zeitfenster beschränkt die Größe des Pools der einander zuzuordnenden Transaktionen. Durch die reduzierte Datenmenge wird einerseits eine weitere Vereinfachung und Beschleunigung der Abwicklung erreicht, andererseits die Anonymität der Transaktionsparteien untereinander ermöglicht.
  • Durch die simultane Datenübertragung wird weiterhin eine Erhöhung der Sicherheit gegen Abstreitbarkeit erreicht, da im Gegensatz zu Verfahren, bei denen eine Transaktion alleine von einer Partei initiiert oder ausgelöst werden kann, die aktive und zeitgleiche Mitwirkung von zwei Transaktionsparteien erforderlich ist. Ebenso wird hierdurch eine höhere Sicherheit gegen versehentliche Auslösung oder versehentlich doppelt erfolgende Auslösung einer Transaktion erreicht.
  • Bei dem erfindungsgemäßen Verfahren sind die von einer Transaktionspartei übermittelten Daten gerade hinreichend, um eine Identifikation dieser Transaktionspartei zu ermöglichen, aber nicht hinreichend, um eine Identifikation der anderen Transaktionspartei zu ermöglichen.
  • Bei dem erfindungsgemäßen Verfahren stehen vorteilhafterweise die von den Transaktionsparteien an die Abwicklungsinstanz übermittelten Daten zueinander nach einer bestimmten Vorschrift in Beziehung.
  • Durch diese Merkmale wird die Anonymität der Transaktionsparteien untereinander unter Beibehaltung der Zuordenbarkeit sichergestellt. (Gegenüber der Abwicklungsinstanz sind die Transaktionsparteien jedoch eindeutig identifiziert, was die prinzipielle Möglichkeit eröffnet, z. B. im Streitfall und mit Einwilligung der Transaktionsparteien zwischen diesen zu vermitteln oder eine Verbindung zwischen ihnen herzustellen.)
  • Bei dem erfindungsgemäßen Verfahren genügt es insbesondere, wenn Partei A gegenüber Partei B beispielsweise nur die letzten n Ziffern seiner Mobiltelefon-Nummer offenlegt. Partei B übermittelt nun die eigene Mobiltelefon-Nummer und die besagten n Ziffern an die Abwicklungsinstanz. Zeitgleich übermittelt Partei A nur die eigene Mobiltelefon-Nummer an die Abwicklungsinstanz. Durch das schmale Zeitfenster ist der Pool der einander zuzuordnenden Transaktionen so klein, dass die n Ziffern zur Zuordnung ausreichen. (Die n Ziffern, die Partei B übermittelt, sind nicht hinreichend, um Partei A zu identifizieren; ferner stehen die n Ziffern zur Mobiltelefon-Nummer von Partei A nach einer bestimmten Vorschrift in Beziehung) Alternativ kann das Verfahren auch so funktionieren, dass beide Parteien A und B einander z. B. die letzten n bzw. m Ziffern ihrer jeweiligen Mobiltelefon-Nummern offenlegen.
  • Im Paybox-Verfahren, das nicht mit simultaner Übermittlung arbeitet, muss Partei A gegenüber Partei B die vollständige Mobiltelefon-Nummer oder einen eindeutigen Alias offenlegen, um eine eindeutige Adressierung zu ermöglichen.
  • Im Falle einer Zahlungstransaktion enthalten die übermittelten Daten vorteilhafterweise den zu zahlenden Betrag an Geld oder Werteinheiten.
  • Durch die doppelte Übermittlung der relevanten Daten wird die Fehlerwahrscheinlichkeit gesenkt und die Nachweissicherheit erhöht. Bei herkömmlichen Verfahren wird der Betrag in der Regel nur von einer der Transaktionsparteien aktiv angegeben und von der anderen Transaktionspartei nur passiv bestätigt, z. B. nach Anzeige auf dem Mobiltelefon-Display oder nach einer akustischen Ansage der Betragshöhe. Dadurch ist ein Irrtum über den autorisierten Betrag leicht möglich. So kann es z. B. bei dem Paybox-Verfahren auftreten, dass der nur akustisch angesagte Betrag aufgrund einer schlechten Funkverbindung oder lauter Umgebungsgeräusche nicht oder falsch verständlich ist.
  • Weiterhin wird durch das Teilen einer gemeinsamen Information in Form der Betragshöhe und die doppelte aktive Angabe dieses Betrages eine Bezeugungswirkung durch beide Transaktionsparteien erreicht. Damit wird eine zusätzliche Erhöhung der Sicherheit gegen Abstreitbarkeit erreicht.
  • Eine Festlegung des Zahlbetrages durch eine aktive Eingabe des Betrages im Vergleich zu einer nur passiven Bestätigung eines angezeigten oder angesagten Betrages führt generell zu einer Reduktion der Irrtumswahrscheinlichkeit.
  • Im folgenden werden Ausführungsformen des erfindungsgemäßen Verfahrens unter Bezugnahme auf die Zeichnungen dargestellt:
    Eine Ausführungsform des Verfahrens kann wie folgt aussehen:
    Die Transaktionsparteien umfassen einen Zahler 1 (bzw. ein Kommunikationsgerät des Zahlers) und einen Zahlungsempfänger 2 (bzw. ein Kommunikationsgerät des Zahlungsempfängers). Der Zahler 1 initiiert einen Telefonanruf 5 an die Abwicklungsinstanz 3. Die dabei gewählte Telefonnummer enthält eine Ziffernfolge 7, die dem Zahlbetrag entspricht. Simultan oder zeitnah zum Anruf des Zahlers übermittelt der Zahlungsempfänger 2 Daten an die Abwicklungsinstanz 3, die den Zahlbetrag 7 enthalten. Zusätzlich übermittelt der Zahlungsempfänger 2 einen Zahlungszuordnungs-Referenzcode 8 an die Abwicklungsinstanz 3, der nach einer bestimmten Vorschrift aus der Rufnummer 12 des Zahlers 1 gebildet wird (z. B. aus den letzten vier Ziffern der Rufnummer des Zahlers besteht). Eine Prüfinstanz 9 prüft, ob die von Zahler 1 und Zahlungsempfänger 2 übermittelten Daten einander eindeutig zuordenbar sind und mindestens die enthaltenen Zahlbeträge 7 übereinstimmen. Eine Transaktionsinstanz 10 prüft, ob anhand der übermittelten Daten eine Identifikation und/oder Legitimation von Zahler 1 und Zahlungsempfänger 2 möglich ist und/oder ob die Verarbeitung des Zahlungsvorgangs möglich ist. Bei positiver Prüfung von Prüfinstanz 9 und Transaktionsinstanz 10 führt die Transaktionsinstanz 10 die Weiterverarbeitung der Zahlung durch oder veranlasst diese. Der Anruf des Zahlers 1 wird von der Signalisierungsinstanz 11 angenommen und ggf. erfolgt eine akustische Ansage, aus der hervorgeht, dass die Zahlung erfolgt ist. An den Zahlungsempfänger 2 wird ein Bestätigungssignal über die erfolgte Zahlung übermittelt. Für den Fall, dass eine der vorangegangenen Prüfungen negativ ausfällt, wird der Anruf des Zahlers 1 von der Abwicklungsinstanz 3 nicht angenommen oder verzögert angenommen und/oder es erfolgt eine akustische Ansage, aus der hervorgeht, dass die Zahlung nicht erfolgt ist.
  • Eine weitere Unter-Ausgestaltung dieser Ausgestaltung des Verfahrens kann wie folgt aussehen:
    Auch die Übermittlung der Daten des Zahlungsempfängers 2 an die Abwicklungsinstanz 3 erfolgt dadurch, dass der Zahlungsempfänger einen Telefonanruf 6 an die Abwicklungsinstanz 3 initiiert. Die dabei gewählte Telefonnummer enthält ebenfalls eine Ziffernfolge 7', die dem Zahlbetrag entspricht, sowie den Zahlungszuordnungs-Referenzcode als Ziffernfolge 8', also z. B. die letzten vier Ziffern 8 der Rufnummer 12 des Zahlers 1. Bei positiver Prüfung von Prüfinstanz 9 und Transaktionsinstanz 10 nach erfolgter Zahlung wird das Bestätigungssignal auch an den Zahlungsempfänger 2 dadurch übermittelt, dass der Anruf 6 des Zahlungsempfängers von der Signalisierungsinstanz 11 angenommen wird und ggf. eine akustische Ansage erfolgt, aus der hervorgeht, dass die Zahlung erfolgt ist. Für den Fall, dass eine der vorangegangenen Prüfungen negativ ausfällt, wird auch der Anruf des Zahlungsempfängers 2 nicht angenommen oder verzögert angenommen wird und/oder es erfolgt eine akustische Ansage, aus der hervorgeht, dass die Zahlung nicht erfolgt ist
  • Im folgenden soll die Durchführung einer Zahlungstransaktion an einem detaillierten Beispiel erläutert werden:
    Partei A (1) mit einem Mobiltelefon mit der Mobiltelefon-Nummer 0171-1234567 (12) möchte an Partei B (2) mit einem Mobiltelefon mit der Mobiltelefon-Nummer 0171-9876543 (13) einen Betrag von EUR 23,50 (7) zahlen. Hierzu teilt Partei A der Partei B die letzten vier Ziffern seiner Mobiltelefon-Nummer (8), also „4567" mit (4). A wählt mit seinem Mobiltelefon die Nummer 0800-55555-2350 an (5). Quasi-zeitgleich wählt B mit seinem Mobiltelefon die Nummer 0800-55555-2350-4567 (6) an. Wenn die Zahlung erfolgreich durchgeführt ist, werden die Anrufe angenommen und A und B erhalten eine kurze akustische Ansage „Zahlung erfolgt".
  • Detailliert arbeiten die Abwicklungsinstanz sowie weitere Instanzen wie folgt:
    Die Abwicklungsinstanz 3 ist unter der Kopf-Rufnummer 0800-55555 erreichbar. Zunächst werden die eingehenden Anrufe durch die Abwicklungsinstanz 3 registriert.
  • Vorteilhafterweise werden dabei die Mobiltelefon-Nummern 12 und 13 der Anrufer (MSISDN bzw. ANI) automatisch übermittelt. Aus den gewählten Rufnummern (DNIS) werden die signifikanten Anteile „2350" (7) bzw. „23504567" (7' und 8') extrahiert. Daraus leitet die Abwicklungsinstanz die Transaktions-Datensätze (Teilnehmer-Nummer = 0171-1234567; Funktion = Senden; Betrag = 23.50; Sender-Kurzkennung = 4567) sowie (Teilnehmerhummer = 0171-9876543, Funktion = Empfangen; Betrag = 23.50; Sender-Kurzkennung = 4567) ab. Die Transaktions-Datensätze werden in einen Transaktions-Pool zuzuordnender Transaktionen eingestellt.
  • Eine Prüfinstanz 9, die von der Abwicklungsinstanz 3 umfasst oder mit dieser verbunden sein kann, prüft, ob eine Zuordnung der Transaktionsparteien 1 und 2 anhand der übermittelten Daten möglich ist. Im aktuellen Beispiel der Zahlungstransaktion ergibt sich daraus auch die Prüfung, ob die jeweiligen Willenserklärungen korrespondieren. Dies geschieht durch einen Vergleich der Datensätze im Transaktions-Pool auf Übereinstimmung der Felder „Betrag" und „Sender-Kurzkennung" (7 und 8 gegen 7' und 8'). Da die Quasi-Simultanität als Zusatzkriterium bewirkt, dass der Transaktions-Pool stets sehr klein ist, ist auch bei einer hohen Transaktionslast sehr wahrscheinlich, dass eine Zuordnung allein anhand der Kriterien „Betrag" und „Sender-Kurzkennung" möglich ist.
  • Die Abwicklungsinstanz 3 kann in den seltenen Fällen, in denen eine eindeutige Zuordnung deshalb nicht möglich ist, weil mehrere Datensätze mit übereinstimmenden Kriterien im Transaktions-Pool vorliegen, die Eingabe zusätzlicher Merkmale anfordern, z. B. den Zahler 1 über ein IVR-System (Interactive Voice Response) darum bitten, auch die letzten vier Ziffern der Mobiltelefon-Nummer des Empfängers einzugeben.
  • Es kann eine Signalisierungsinstanz 11 vorgesehen sein, die von der Abwicklungsinstanz umfasst oder mit dieser verbunden sein kann. Bei nicht erfolgreicher Prüfung der Prüfinstanz gibt diese an beide Parteien A und B (1 und 2) eine Fehlermeldung aus. Dies kann z. B. durch Annahme der Anrufe und eine akustische Ansage erfolgen.
  • Es kann eine Transaktionsinstanz 10 vorgesehen sein, die von der Abwicklungsinstanz umfasst oder mit dieser verbunden sein kann. Diese Transaktionsinstanz 10 prüft, ob eine Durchführung des Zahlungsvorgangs möglich ist.
  • Hierzu wird zunächst überprüft, ob die Teilnehmer-Nummern im System registriert und für die Zahlungsfunktion zugelassen sind. Bei nicht erfolgreicher Prüfung gibt die Signalisierungsinstanz 11 an die jeweiligen Parteien eine entsprechende Fehlermeldung aus. Dies kann z. B. durch Annahme der Anrufe und eine akustische Ansage erfolgen.
  • Im nächsten Schritt prüft die Transaktionsinstanz 10, ob eine Durchführung der Zahlung möglich ist. Dies hängt insbesondere von der Betragshöhe und der Bonität des Zahlers ab. Wenn z. B. der aktuelle Zahlbetrag oder eine aggregierte Summe von Zahlbeträgen ein Limit (das z. B. von der Bonität des Zahlers abhängt) überschreitet, kann die Transaktionsinstanz 10 die Durchführung bzw. Weiterverarbeitung der Zahlungstransaktion ablehnen oder eine zusätzliche Legitimationsprüfung durch Anforderung eines weiteren Autorisierungsmerkmals durchführen (z. B. Eingabe einer PIN über ein IVR-Interface). Generell kann die Transaktionsinstanz 10 vor der Durchführung der Transaktion unter bestimmten Bedingungen, z. B. ab einer gewissen Betragshöhe, noch eine weitere Bestätigung (auch z. B. durch einfaches Drücken einer Taste und Übermittlung eines DTMF-Tones) anfordern. Weiterhin ist z. B. auch möglich, dass unter bestimmten Bedingungen wie z. B. ab einer gewissen Betragshöhe vor Durchführung der Transaktion der Betrag nochmals explizit angesagt wird und danach die Bestätigung abgefragt wird.
  • Die weiteren Ausführungen folgen nun ohne Bezugnahme auf die Zeichnung.
  • Es ist weiterhin auch möglich, dass Zusatzmerkmale abgefragt werden, die eine buchhalterische getrennte Erfassung oder Untergruppierung der getätigten Transaktion ermöglichen, z. B. durch eine Ansage wir „Drücken Sie 1 für eine private Zahlung, 2 für eine geschäftliche Zahlung".
  • Es ist weiterhin auch möglich, dass für den Fall, dass mehrere Nutzer über ein Mobil- oder Festnetztelefon Transaktionen ausführen, Merkmale abgefragt werden, die die Zuordnung der Transaktion zu nutzerspezifischen Unterkonten ermöglichen, z. B. durch Eingabe verschiedener PINs für verschiedene Nutzer.
  • Anstelle von PINs kann die Abfrage von zusätzlichen Autorisierungsmerkmalen auch über andere Verfahren, z. B. biometrische Verfahren wie Stimmvergleiche (Voice-Sampling) erfolgen.
  • Die Weiterverarbeitung der Zahlungstransaktion kann durch die Transaktionsinstanz durch Legitimationsprüfung und/oder Aggregation und/oder eine zeitgleich oder zeitverzögert, online oder offline erfolgende Weiterleitung an andere Verarbeitungsinstanzen erfolgen. Beispielsweise können auf Seiten des Zahlers bzw. Empfängers einzelne Transaktionen gesammelt und nur als Gesamtbetrag monatlich einem Bankkonto oder einer Kreditkarte belastet bzw. gutgeschrieben werden. Die Sammel-Aufträge werden in diesem Fall an Banken oder Kreditkartenunternehmen als weitere Verarbeitungsinstanzen weitergeleitet. Alternativ können einzelne Transaktionen (insbesondere bei höheren Beträgen) auch zeitgleich zur Online-Autorisierung an Kreditkartenunternehmen weitergeleitet werden.
  • Alternativ kann die Transaktionsinstanz auch eine Kontoführungsinstanz umfassen oder direkt mit einer Kontoführungsinstanz verbunden sein. Wenn die Abrechnung z. B. über einen „Stored Value Account", d. h. ein vorausbezahltes Guthaben erfolgt, kann das „Settlement", d. h. die Durchführung des Zahlungsvorgangs, besonders rationell, schnell und risikolos durchgeführt werden, da keine Kommunikationsverbindung zu einer externen Verarbeitungsinstanz notwendig ist, keine umfangreichen Transaktionshistorien verwaltet werden müssen und ein Kredit-, Inkasso- und Charge-Back-Risiko ausgeschlossen wird.
  • Generell kann eine Unterscheidung der Weiterverarbeitung nach bestimmten Kriterien erfolgen. Z. B. können automatisch kleine Beträge direkt gegen einen „Stored Value Account" abgerechnet, mittlere Beträge aggregiert und zeitversetzt gegen ein Bankkonto abgerechnet und höhere Beträge online bei einem Kreditkartenunternehmen autorisiert werden. Hierbei kann auch eine je nach Modus unterschiedliche Form der Speicherung und Verwaltung der Transaktions-Historie realisiert werden. So können z. B. Transaktionen mit niedrigen Beträgen für den Fall von Reklamationen nur kurzzeitig oder gar nicht und solche mit höheren Beträgen über längere Zeiträume gespeichert werden. Weiterhin ist es möglich, dem Nutzer für einzelne Transaktion individuell die Entscheidungsmöglichkeit über den Abrechnungsmodus zu geben, z. B. durch eine IVR-basierte Abfrage („Drücken Sie 1, um diese Zahlung per Kreditkarte abzurechnen, 2, um sie per Bankeinzug abzurechnen").
  • Weiterhin kann z. B. eine je nach Betragshöhe unterschiedliche Art der Signalisierung und Bestätigung der Transaktion erfolgen. So könnte z. B. bei höheren Beträgen nach erfolgter Transaktion zusätzlich eine SMS zur Bestätigung verschickt werden.
  • In allen Abrechnungsvarianten kann die Wahrscheinlichkeit von Reklamationen sowie das generelle Missbrauchsrisiko reduziert werden, indem kombiniert mit einer Signalisierung über den Transaktionserfolg Informationen über zurückliegende Transaktionen an die Transaktionsparteien übermittelt werden. Dies bedeutet z. B., dass nach jeder Transaktion eine kurze Ansage der des Guthabens des „Stored Value Accounts" bzw. die Summe der seit der letzten Abrechnung aggregierten Einzeltransaktionen erfolgen kann. Zusätzlich erhöht wird die Sicherheit, indem Datum und Betrag der letzten zurückliegenden Transaktion angesagt wird.
  • Über die von der Signalisierungsinstanz ausgelöste Signalisierung bzw. über die von der Signalisierungsinstanz übermittelten Daten für die Transaktionsparteien sind Rückschlüsse auf den Status der Durchführung von Transaktionen durch die Transaktionsinstanz (sowie auf das Ergebnis der Prüfinstanz) möglich.
  • Diese Signalisierung ist vorteilhafterweise wie folgt realisiert:
    Nach Eingang der beiden Anrufe werden in der Abwicklungsinstanz zunächst alle Prüfungs- und Verarbeitungsschritte durch die Prüfinstanz und die Transaktionsinstanz durchgeführt. Während dieser Zeit werden die Anrufe von der Abwicklungsinstanz noch nicht angenommen, d. h. den Transaktionsparteien wird zunächst ein Freizeichen signalisiert, wodurch vorteilhafterweise die Telekommunikationskosten reduziert werden.
  • Die weitere Signalisierung ist wie folgt realisiert: Sobald ein abschließender Status erreicht ist (d. h. ein Fehler vorliegt oder alle vorbereitenden Prüfschritte vor Durchführung der Zahlung erledigt sind), werden beide Anrufe von der Abwicklungsinstanz angenommen. Wenn ein Fehler vorliegt, erfolgt eine kurze Ansage mit dem Fehlergrund (z. B. „Einzelbetrags-Limit überschritten” oder „Kein korrespondierender Zahlungsempfänger vorliegend") und unmittelbar danach ein Auflegen durch die Abwicklungsinstanz. Wenn die Zahlung durchgeführt werden kann, erfolgt eine längere Ansage (z. B. „Zahlung von EUR 23,50 erfolgt jetzt"), gefolgt von einem akustischen Signal und danach einer optionalen Kontostand-Ansage.
  • Diese Ausgestaltung hat folgenden Vorteil: Nicht erfolgreiche Transaktionen führen immer zu Verbindungsdauern von z. B. 5 Sekunden oder kürzer, ausschliesslich erfolgreiche Transaktionen führen zu Verbindungsdauern von z. B. 10 Sekunden oder länger.
  • Hieraus ergibt sich vorteilhafterweise, dass ein Einzelverbindungsnachweis der Telefon- oder Mobiltelefon-Rechnung des Telekommunikationsproviders ohne weitere Modifikation direkt als Zahlungsnachweis und Beleg dienen kann. Dies führt zu einer Kostensenkung, da auf die Erstellung und Zusendung einer separaten Abrechnung verzichtet werden kann. Ein Eintrag über einen ausgehenden Anruf an Rufnummer „0800-55555-2350-4567" von 11 Sekunden Länge könnte demnach als ein Nachweis über eine empfangene Zahlung i. H. v. EUR 23,50 dienen. Vorteilhaft an der erfindungsgemäßen Eigenschaft, derzufolge beide Transaktionsparteien einen Anruf zur Abwicklungsinstanz initiieren, ist, dass für jede der Transaktionsparteien ein Beleg existiert.
  • Hierbei ist zu beachten, dass Anrufe zu kostenlosen Rufnummern, die z. B. mit 0800 beginnen, im Regelfall nicht im Einzelverbindungsnachweis des Anrufers erfasst werden. In diesem Fall müsste die Abwicklung über eine alternative Zugangsnummer erfolgen. Andererseits erfolgt die Abrechnung von Anrufen zu kostenlosen Rufnummern in der Regel über die angerufene Partei, in diesem Fall also über den Betreiber der Abwicklungsinstanz, so dass die betreffenden Anrufe hier auf dem Einzelverbindungsnachweis der Abwicklungsinstanz erfasst würden. Hierdurch erfüllt der Einzelverbindungsnachweis des Telekommunikations-Providers ebenfalls die Funktion eines Zahlungsnachweises und Belegs, allerdings nicht für die Transaktionsparteien, sondern für den Betreiber der Abwicklungsinstanz.
  • Die Abwicklungsinstanz oder die Transaktionsinstanz wird vorteilhafterweise von einem Telekommunikations-Provider umfasst oder betrieben.
  • Ein Vorteil der oben dargestellten Ausgestaltung des Verfahrens besteht nämlich darin, dass eine sehr einfache Integration der Zahlungsvorgänge in die Abrechnungssysteme der Telefon- oder Mobilfunk-Provider möglich ist. Vorteilhafterweise geschieht nämlich die Verarbeitung der Zahlungstransaktionen zusammen mit der Abrechnung der Telekommunikationsdienstleistungen. Bei dem vorliegenden Verfahren kann eine Implementierung der Abrechnungsfunktionalität z. B. einfach dadurch erfolgen, dass der Anruf, über den die Zahlungstransaktion ausgeführt wird, direkt mit dem in der Telefonnummer enthaltenen Betrag tarifiert wird, sofern die Verbindungsdauer z. B. länger als 10 Sekunden war. Eine Verbindung zur Rufnummer 0800-55555-2350 von z. B. 11 Sekunden Länge würde dann mit einem Betrag von EUR 23,50 in Rechnung gestellt, eine Verbindung zur Rufnummer 0800-55555-2350-4567 von z. B. 11 Sekunden Länge mit einem Gutschriftsbetrag von EUR 23,50 abgerechnet. Diese Funktionalität wäre mit minimalen Software-Updates in den Abrechnungssystemen implementierbar. Es müssten nur wenige weitergehende technische Vorrichtungen oder Schnittstellen geschaffen werden. Vorteilhafterweise funktioniert das Verfahren für Zahler wie Empfänger symmetrisch – im Unterschied zu herkömmlichen Verfahren, bei denen auf Empfängerseite andere Systeme und Schnittstellen zum Einsatz kommen als auf Zahlerseite.
  • Die Aussendung des oben beschriebenen akustischen Signals erfolgt vorteilhafterweise exakt synchron an beide Transaktionsparteien und zusätzlich vorteilhafterweise genau in dem Moment, in dem der eigentliche Zahlungsvorgang logisch erfolgt (in Informatik-Fachsprache ausgedrückt: in dem Moment, in dem das „Commit" der Transaktion erfolgt, die den eigentlichen Zahlungsvorgang darstellt). Hierdurch wird die Wahrscheinlichkeit von Szenarien verringert, in denen an eine oder alle der Transaktionsparteien keine eindeutige Signalisierung über den Erfolg oder den Status der Transaktion erfolgen kann. (Solche Szenarien können z. B. eintreten, wenn die Telekommunikationsverbindung während der Durchführung der Transaktion abbricht.)
  • Die Ausgestaltung, dass die Verbindungsdauer einer erfolgreichen Transaktion länger ist als die einer nicht erfolgreichen Transaktion hat den Vorteil, dass vorzeitiges Auflegen eines Transaktionspartners dazu führt, dass die Transaktion abgebrochen und das „Commit" des eigentlichen Zahlungsvorgangs nicht ausgeführt wird. Dadurch wird eine Manipulation des oben beschriebenen Effektes auf die Einzeiverbindungsnachweise durch vorzeitiges Auflegen ausgeschlossen (Eine solche Manipulation wäre möglich, wenn lange Verbindungsdauern ein Kennzeichen für nicht erfolgreiche und kurze Verbindungsdauern ein Kennzeichen für erfolgreiche Transaktionen wären.)
  • Das oben beschriebene Verfahren kann auch so ausgestaltet sein, dass nicht der Zahler dem Zahlungsempfänger die letzten vier Ziffern seiner Mobiltelefon-Nummer offenlegt und der Zahlungsempfänger diese – als Teil der Rufnummer – an die Abwicklungsinstanz übermittelt, sondern umgekehrt, d. h. dass der Zahlungsempfänger dem Zahler die letzten vier Ziffern seiner Mobiltelefon-Nummer offenlegt und der Zahler diese – als Teil der Rufnummer – an die Abwicklungsinstanz übermittelt.
  • In einer weiteren Ausgestaltung können beide Varianten auch kombiniert werden, d. h. der Zahler und Zahlungsempfänger legen einander die letzten zwei Ziffern ihrer jeweiligen Mobiltelefon-Nummern offen und übermitteln jeweils die von der anderen Partei erhaltenen zwei Ziffern – als Teil der Rufnummer – an die Abwicklungsinstanz. (Die Abwandlung des obigen Beispiels sähe dann wie folgt aus: A legt B die Ziffern „67" offen, B legt A die Ziffern „43" offen. A wählt „0800-55555-2350-43, B wählt „0800-66666-2350-67. In diesem Fall ist die Anwahl einer unterschiedlichen Kopf-Rufnummer „0800-55555" ggü. „0800-66666" durch die Transaktionsparteien notwendig, um Zahler vom Empfänger zu unterscheiden. Ansonsten funktioniert das Verfahren analog.)
  • Der Zahlbetrag könnte auch nicht als Klartext, sondern als verschlüsselte Ziffernfolge übermittelt und/oder um eine Prüfziffer oder Prüfziffernfolge ergänzt werden.
  • Eine weiteren Ausgestaltung könnte wie folgt aussehen: In Anwendungs-Szenarien, bei denen eine räumliche Nähe zwischen Zahler und Empfänger besteht, kann die Information über den Aufenthaltsort der Transaktionsparteien als zusätzliches Kriterium herangezogen werden, um eine Zuordnung der Transaktionsparteien über die Datensätze im Transaktions-Pool zu erleichtern. Unter dem Begriff „Location Dependent Services" sind Verfahren bekannt, bei denen die Ortsinformation von Mobiltelefon-Nutzern übertragen und ausgewertet werden kann.
  • In den oben dargestellten Beispielen wurde davon ausgegangen, dass die Mobiltelefon-Nummern der Anrufer (MSISDN bzw. ANI) automatisch übermittelt werden, was die Abwicklung vereinfacht und einen Schutz gegen Missbrauch bewirkt. Diese Übermittlung kann z. B. durch eine spezielle Schaltung des Telekommunikations-Providers auf Seiten der Abwicklungsinstanz erreicht werden, die es ermöglicht, auch solche Anrufer-Nummern anzuzeigen, deren Anzeige normalerweise unterdrückt ist. Dies hat den Vorteil, dass auch Anrufer mit standardmäßiger Rufnummern-Unterdrückung das System ohne Umstellung des Anzeigemodus im Einzelfall nutzen können.
  • Alternativ kann das Verfahren auch so ausgestaltet werden, dass bei Anrufen von Mobiltelefonen mit unterdrückter Rufnummernanzeige z. B. durch ein IVR-System die Abfrage von Identifizierungsmerkmalen (z. B. der Mobiltelefon-Nummer in Verbindung mit einer PIN oder einer nicht zu einer Mobiltelefon-Nummer korrelierten freien Kundennummer) erfolgt. Die Ausgestaltung freier Kundennummern, die nicht mit einer Mobiltelefon-Nummer verknüpft sind, bietet für die Nutzer des Systems eine Möglichkeit zur Erreichung zusätzlicher Anonymität auch gegenüber der Abwicklungsinstanz.
  • Die Datenübermittlung mindestens einer der Transaktionsparteien erfolgt (wie in den Beispielen beschrieben) vorteilhafterweise durch die Initiierung eines Telefonanrufs zur Abwicklungsinstanz.
  • Weiterhin erfolgt vorteilhafterweise die Übermittlung mindestens eines Teils der von mindestens einer der Transaktionsparteien übermittelten Daten durch die beim Aufbau eines Telefonanrufs zur Abwicklungsinstanz gewählte Telefonnummern-Ziffernfolge.
  • Dabei ist vorteilhafterweise die Telefonnummern-Ziffernfolge so kurz, dass sie von den Vermittlungsstellen und/oder Übermittlungssystemen vollständig übertragen werden kann.
  • Die implizite Übermittlung der relevanten Daten als Teil der Rufnummer hat einerseits den Vorteil von Sicherheit, Schnelligkeit und Einfachheit in der Bedienung. Die Auslösung eines Zahlungsvorganges ist nämlich so einfach wie das Wählen einer Telefonnummer, wobei gleichzeitig die in Mobiltelefonen implementierten Sicherheits-Funktionen, die ein unbeabsichtigtes oder unbefugtes Wählen verhindern, auch die Zahlungsfunktion schützen.
  • Andererseits hat diese Ausgestaltung (wie bereits oben beschrieben) den Vorteil, dass der Einzelverbindungsnachweis des Telekommunikations-Providers als Zahlungsnachweis und Beleg dienen kann sowie dass eine sehr einfache Integration der Zahlungstransaktion in die Abrechnungssysteme des Telekommunikations-Providers möglich ist.
  • Ein weiterer Vorteil der Datenübermittlung als Teil der Rufnummer besteht darin, dass – im Unterschied zur DTMF-Ton-Übermittlung – eine visuelle Kontrolle (vor dem Versand der Daten) über das Display des Mobiltelefons möglich ist. Weiterhin ist diese Art der Übertragung wesentlich weniger fehleranfällig als DTMF-Töne, die bei schlechten Funkverbindungen häufig zu Problemen führen.
  • Gleichwohl sind sowohl für die Übermittlung der Daten und/oder Signalisierungen sowohl von den Transaktionsparteien zur Abwicklungsinstanz als auch von der Abwicklungsinstanz oder Signalisierungsinstanz zu den Transaktionsparteien beliebige andere Übertragungsmethoden denkbar, wobei der Umfang dieser Erfindung diese mit einschließt.
  • Diese Übertragungsmethoden können dabei ganz oder teilweise alternativ oder ergänzend zu den oben beschriebenen Methoden angewendet werden. Beispielsweise kann im Falle einer Zahlungstransaktion die Übermittlung des Betrages, einer PIN, einer Kundennummer, eines Zahlungszuordnungs-Referenzcodes oder einer anderen Information über ein oder mehrere alternative Verfahren erfolgen.
  • Die Übermittlung der Daten und/oder Signalisierungen könnte so z. B. für den Fall, dass beide Transaktionsparteien ein Telefon bzw. Mobiltelefon verwenden, ganz oder teilweise durch Mehrfrequenz-Töne (DTMF) und/oder IVR-Systeme (Interative Voice Response) und/oder über Spracherkennungssysteme und/oder durch Sprache und/oder über SMS-Kurzmitteilungen und/oder über das USSD-Protokoll (Unstructured Supplementary Services Data) und/oder über das WAP-Protokoll (Wireless Application Protocol) und/oder über das GPRS-Protokoll (GSM Packet Radio Service) des GSM-Standards und/oder ein vergleichbares Protokoll eines anderen Mobilfunk-Standards und/oder über das i-Mode-Protokoll und/oder unter Nutzung einer Java- und/oder SIM-Application-Toolkit-Anwendung und/oder über die Nutzung einer Bluetooth-Schnittstelle und/oder einer Infrarot-Schnittstelle erfolgen („BLUETOOTH” ist eine Marke der Firma Bluetooth SIG, Inc., USA).
  • Nachteilig an der Verwendung von DTMF-Tönen, IVR-Systemen, Spracherkennungssystemen, Sprache und SMS-Mitteilungen ist die längere Abwicklungsdauer im Vergleich zur Datenübermittlung als Teil der Rufnummer eines Telefonanrufes. Nachteilig an der Verwendung des USSD-Protokolls ist die nicht einheitliche Implementierung von Statusmeldungen in verschiedenen Endgeräten und die Tatsache, dass USSD (in der Variante USSD Stage 2) nicht von allen Mobilfunk-Netzbetreibern unterstützt wird sowie die Tatsache, dass eine Implementierung durch einen vom Mobilfunk-Netzbetreiber unabhängigen Anbieter nicht ohne weiteres möglich ist. Nachteilig an der Verwendung von WAP, GPRS, i-Mode, Java, SIM-Application-Toolkit und ähnlichen Verfahren ist, dass sie – sofern kein Endgeräte-Austausch und ggf. Wechsel des Mobilfunk-Netzbetreibers oder Wechsel des Tarifs erfolgt – nach dem Stand der Technik nur von einem relativ kleinen oder sehr kleinen Teil der Mobilfunk-Nutzer verwendet werden können.
  • Für den Fall, dass nur eine der Transaktionsparteien ein Telefon bzw. Mobiltelefon verwendet, kann die Übermittlung der Daten und/oder Signalisierungen ganz oder teilweise über ein Computernetzwerk und/oder über das Internet und/oder per E-Mail und/oder über den Aufruf eines Webservice und/oder mittels Verwendung des HTTP- und/oder des XML-Prokolls und/oder über die Nutzung einer Bluetooth-Schnittstelle und/oder einer Infrarot-Schnittstelle und/oder eines Wireless LAN und/oder über ein digitales oder analoges Modem und/oder die Nutzung eines sonstigen Übertragungsverfahrens erfolgen.
  • Im folgenden soll eine Ausgestaltung des erfindungsgemäßen Verfahrens in einem E-Commerce-Szenario beschrieben werden am Beispiel einer Zahlungstransaktion im Internet, bei der ein Zahler eine Zahlung an z. B. einen Anbieter von Waren oder Dienstleistungen durchführt.
  • Der Zahler mit der Mobiltelefon-Nummer 0171-1234567 gibt auf der Internet-Seite des Anbieters, auf der auch der Zahlbetrag, z. B. EUR 23,50 angezeigt ist, die letzten vier Ziffern seiner Mobiltelefonnummer, also „4567" ein und wählt gleichzeitig an seinem Mobiltelefon die Nummer „0800-55555-2350". Die weitere Abwicklung des Verfahrens geschieht im Prinzip analog zu dem oben dargestellten Beispiel, mit dem Unterschied, dass die Datenübertragung von dem Computersystem des Anbieters zu der Abwicklungsinstanz z. B. über einen HTTP-Request oder den Aufruf eines Webservice geschieht. Hierbei übermittelt das Computersystem des Anbieters eine Kennung der eigenen Identität, den Betrag sowie die letzten vier Ziffern der Mobiltelefonnummer des Zahlers. Die Rücksignalisierung von der Signalisierungsinstanz zum Computersystem des Anbieters kann wiederum über eine HTTP-Response oder den Rückgabewert des Webservice geschehen. Vorteilhafterweise wird die Datenübertragung zwischen Computersystem und Abwicklungsinstanz bzw. Signalisierungsinstanz durch kryptographische Verfahren zusätzlich gesichert.
  • Im folgenden wird ein Beispiel für eine Implementierungvariante des beschriebenen Verfahrens dargestellt, welches insbesondere zur Anwendung in POS-Kassensystemen geeignet ist, die in der Regel anstelle eines Internet-Anschlusses nur über Festnetz-Telefonanschlüsse zur Kommunikation von Kreditkarten-Terminals oder vergleichbaren Geräten mit einer Autorisierungszentrale verfügen.
  • Der Kunde teilt dem Kassierer die letzten vier Ziffern seiner Mobiltelefon-Nummer mit. Diese wird vom Kassierer in eine Kasse oder ein Kreditkarten-Terminal oder ein vergleichbares Gerät (im folgenden „Terminal" genannt) eingegeben und von dem Terminal an ein verbundenes oder integriertes Festnetz- oder Mobilfunk-Modem übergeben, das einen Telefonanruf zur Abwicklungsinstanz initiiert und dabei wie im ersten dargestellten Beispiel als Telefonnummer die „0800-55555-2350-4567" wählt. Sofern die oben beschriebene Verfahrensvariante zum Einsatz kommt, bei der eine Mindestdauer der Verbindung Kennzeichen für eine erfolgreiche Transaktion ist, genügt für das Terminal zur Entscheidung, ob die Zahlung erfolgreich war, prinzipiell allein die Prüfung, ob die Modemverbindung länger als die Mindestdauer bestand. Dadurch kann die Abwicklung des Verfahrens gegenüber Protokollen, bei denen ein zeitaufwendiger Modemprotokoll-Verbindungsaufbau erfolgt, stark beschleunigt werden. Dies führt auch zu einer Reduktion der Telekommunikationskosten. Eine detailliertere Rückmeldung der Abwicklungsinstanz an das Kassensystem im Fehlerfall ist in der Regel nicht nötig, da der Zahler bzw. Kunde seinerseits eine akustische Rückmeldung über eine Fehlerursache erhält.
  • Wie oben bereits beschrieben, ist das Verfahren in den Fallen, in denen die Datenübermittlung an die Abwicklungsinstanz über Telefonanrufe erfolgt, so ausgestaltet, dass ein Teil der Verarbeitungsschritte bereits abgewickelt wird, bevor der Anruf von der Abwicklungsinstanz angenommen wird und ferner so, dass die Verbindungsdauer einer erfolgreichen Transaktion sich von der einer nicht erfolgreichen Transaktion unterscheidet.
  • Ebenso sind Ausgestaltungen des Verfahrens möglich, bei denen die Signalisierung dadurch erfolgt, dass der Anruf durch Abheben der Abwicklungsinstanz angenommen wird oder unter Signalisierung eines Freizeichens nicht angenommen wird oder ein Besetzt-Signal oder ein anderes Signal signalisiert wird oder dass unterschiedlich lange Zeitintervalle zwischen dem Übergang verschiedener Rufaufbau-Signale und/oder Rufabbau-Signale liegen.
  • Beispielsweise könnte das Verfahren so funktionieren, dass im Falle einer erfolgreichen Transaktion ein dreimaliges Freizeichen-Signal erzeugt wird, bevor ein Besetzt-Signal auftritt, wohingegen im Fall einer nicht erfolgreichen Transaktion bereits nach einem Freizeichen-Signal ein Besetzt-Signal auftritt. Vorteilhaft an dieser Ausgestaltung ist, dass theoretisch überhaupt keine Telekommunikationskosten entstehen.
  • Das Verfahren könnte weiterhin z. B. auch so realisiert werden, dass ausschließlich im Falle einer erfolgreichen Transaktion der Anruf von der Abwicklungsinstanz durch Abheben angenommen und bei einer nicht erfolgreichen Transaktion ein Freizeichen- und/oder Besetzt-Signal signalisiert wird. Diese Variante hätte den Vorteil, dass Transaktionen generell dann (und nur dann) zu Einträgen in Einzelverbindungsnachweisen führen, wenn sie erfolgreich sind. In dieser Variante könnte vorteilhafterweise bei nicht erfolgreichen Transaktionen ein Rückruf der Signalisierungsinstanz an eine oder alle der Transaktionsparteien erfolgen verbunden mit einer akustischen Ansage der Fehlerursache. Alternativ kann die Fehlerursache auch z. B. per SMS übermittelt werden.
  • Ferner könnte das Verfahren beispielsweise auch so arbeiten, dass die Signalisierung alternativ zu oder kombiniert mit Freizeichen- oder Besetzt-Signalen über andere gebührenfreie Ansagen wie z. B. „Kein Anschluss unter dieser Nummer" oder spezielle neu einzuführende gebührenfreie Ansagen erfolgt.
  • Ebenso sind ferner Ausgestaltungen des Verfahrens möglich, bei denen zwischen beiden Transaktionsparteien eine Telefonverbindung hergestellt wird (sofern beide Transaktionsparteien ein Festnetztelefon oder Mobiltelefon verwenden). Diese Variante ist insbesondere dann sinnvoll, wenn z. B. eine Zahlungstransaktion für eine telefonische Beratung o. ä. erfolgt und die Dienstleistung gleich über die hergestellte Telefonverbindung erbracht wird.
  • Für den Fall, dass z. B. innerhalb einer bestehenden Mobil-Telefonverbindung zwischen den Transaktionsparteien eine Zahlungstransaktion unter Nutzung der Mobiltelefone erfolgen soll, könnte das im ersten Beispiel beschriebene Verfahren so abgewandelt sein, dass die Übermittlung des Zahlbetrages und der letzten vier Ziffern der Mobiltelefon-Nummer des Zahlers über DTMF-Töne erfolgt, die innerhalb der Verbindung von den Transaktionsparteien gesendet werden. In diesem Fall könnten die DTMF-Töne vom Vermittlungssystem ausgefiltert und an die Abwicklungsinstanz weitergeleitet werden oder es könnte eine temporäre Telefon-Verbindung der Transaktionsparteien mit der Abwicklungsinstanz initiiert werden.
  • Ebenso sind ferner Ausgestaltungen des Verfahrens möglich, bei denen die Signalisierung generell dadurch erfolgt, dass von der Signalisierungsinstanz ein Rückruf an mindestens eine der Transaktionsparteien initiiert wird. Diese Variante hat den Vorteil, dass auch in den Einzelverbindungsnachweisen des Betreibers der Signalisierungsinstanz bzw. Abwicklungsinstanz Belege für die durchgeführten Transaktionen erfasst werden.
  • Diese Variante kann unter Nutzung eines Rückrufs wiederum so ausgestaltet sein, dass unterschiedlich lange Zeitintervalle zwischen dem Übergang verschiedener Rufaufbau-Signale und/oder Rufabbau-Signale liegen. So kann z. B. der Rückruf bei einer erfolgreichen Transaktion nach 10 Sekunden, bei einer nicht erfolgreichen Transaktion nach 20 Sekunden erfolgen, oder der Rückruf kann in beiden Fallen sofort erfolgen, und im Falle einer erfolgreichen Transaktion eine längere Ansage (vor dem Auflegen durch die Signalisierungsinstanz bzw. Abwicklungsinstanz) erfolgen als im Falle einer nicht erfolgreichen Transaktion.
  • Ebenso ist es möglich, die Variante unter Nutzung eines Rückrufs weiterhin so zu gestalten, dass die Signalisierung dadurch erfolgt, dass bei dem von der Abwicklungsinstanz initiierten Rückruf von der Abwicklungsinstanz eine spezielle Anrufer-Rufnummer (ANI) generiert und übergeben wird, wobei aus dieser ANI Rückschlüsse auf das Ergebnis der Prüfinstanz und/oder auf den Status der Durchführung von Transaktionen durch die Transaktionsinstanz möglich sind. Beispielsweise könnte das oben dargestellte erste Beispiel wie folgt abgewandelt werden: statt der Signalisierung eines Freizeichens während der Abwicklung der Transaktion werden die Anrufe von Zahler und Empfänger direkt nach dem Eingang bei der Abwicklungsinstanz von dieser durch eine spezielle Signalisierungsnachricht an die Vermittlungsstelle abgelehnt, wodurch bei Zahler und Empfänger z. B. ein Besetzt-Signal ertönt. Wenige Sekunden später erhalten Zahler und Empfänger einen eingehenden Anruf von der Signalisierungsinstanz, wobei von der Signalisierungsinstanz als Anrufer-Nummer (ANI) die spezielle Anrufer-Rufnummer „0800-55555-2350" generiert wird, sofern die Zahlung erfolgt ist, bzw. „0800-55555-0000", wenn die Zahlung nicht durchgeführt werden kann. Aus der im Display angezeigten Anrufer-Nummer können Zahler und Empfänger so ersehen, ob die Zahlung erfolgreich war oder nicht. Vorteilhafterweise bleibt der Eintrag weiterhin in der Anruferliste des Mobiltelefons gespeichert, was ein späteres nochmaliges Überprüfen ermöglicht. Vorteilhaft gegenüber einer Signalisierung durch Versand einer SMS ist die schnellere und gesichert kurze Übertragungsdauer.
  • Vorteilhafterweise kann die Variante unter Nutzung eines Rückrufs und ggf. Nutzung einer speziellen Anrufer-Rufnummer so ausgestaltet sein, dass die von der Abwicklungsinstanz ausgehenden Rückrufe in den Telekommunikationsgeräten der Transaktionsparteien nur signalisiert, aber von diesen nicht angenommen werden. Vorteilhaft an dieser Ausgestaltung ist, dass theoretisch überhaupt keine Telekommunikationskosten entstehen.
  • Vorteilhafterweise kann die Rückmeldung der Signalisierungsinstanz über die durchgeführte Transaktion dadurch gegen Missbrauch gesichert werden, dass ein eindeutiger Buchungs-Referenz-Code oder eine kryptographisch signierte Bestätigungsnachricht, z. B. per E-Mail oder per SMS übermittelt wird.
  • Verallgemeinert dient das erfindungsgemäße Verfahren dem Initiieren und/oder Durchführen einer mit mindestens zwei korrespondierenden Willenserklärungen in Beziehung stehenden Transaktion.
  • Dabei eignet sich das Verfahren insbesondere für solche Willenserklärungen, die mindestens auf den Abschluss eines Vertrages gerichtet sind.
  • In diesem Fall beinhaltet vorteilhafterweise die zu initiierende oder durchzuführende Transaktion mindestens die Durchführung des Vertragsabschlusses.
  • Die zu initiierende oder durchzuführende Transaktion beinhaltet vorteilhafterweise ferner mindestens die Dokumentation des Vertragsabschlusses.
  • Dabei sind im spezialisierteren erfindungsgemäßen Fall von Zahlungstransaktionen die Willenserklärungen allgemein mindestens auf die Durchführung eines Zahlungsvorgangs betreffend Geld- oder Werteinheiten gerichtet.
  • Die Transaktion kann ferner mindestens in der Veranlassung oder Durchführung eines Zahlungsvorgangs betreffend Geld oder Werteinheiten bestehen.
  • Werteinheiten können z. B. oder insbesondere Bonuspunkte in Rabattsystemen, „Statusmeilen" oder ähnliches sein. Vorteilhafterweise können zusammen mit Zahlungstransaktionen betreffend Geldeinheiten auch parallel Bonuspunkte o. ä. verbucht werden.
  • Vorteilhafterweise enthalten bei dem erfindungsgemäßen Verfahren die von den Transaktionsparteien an die Abwicklungsinstanz übermittelten Daten den wesentlichen Teil der Inhalte der jeweiligen Willenserklärungen und/oder oder einen digitalen Abdruck (Digest, Hash-Wert) der Inhalte der jeweiligen Willenserklärungen und/oder eine eindeutige Referenz auf ggf. an anderer Stelle erfasste Inhalte der jeweiligen Willenserklärungen.
  • Im folgenden soll ein Beispiel für die Anwendung des erfindungsgemäßen Verfahrens für die Durchführung und Dokumentation eines Vertragsabschlusses, kombiniert mit der Durchführung einer Zahlungstransaktion dargestellt werden.
  • Prinzipiell funktioniert das Verfahren analog zum oben beschriebenen E-Commerce-Szenario am Beispiel einer Zahlungstransaktion im Internet, bei der ein Zahler eine Zahlung an z. B. einen Anbieter von Waren oder Dienstleistungen durchführt.
  • Zusätzlich zur reinen Zahlung vom Zahler an den Anbieter soll in diesem Beispiel jedoch auch ein Kauf- oder Dienstleistungsvertrag zwischen Anbieter und Zahler abgeschlossen und dokumentiert werden. Im folgenden wird der Zahler daher als Zahler/Käufer bezeichnet.
  • Dazu wird von dem Inhalt des Vertrages ein digitaler Abdruck (Digest) gebildet, z. B. über einen Hash-Algorithmus wie MD5. Dieser digitale Abdruck wird dabei vorteilhafterweise auf eine relativ kurze, z. B. sechsstellige Ziffernfolge (z. B. „141516) reduziert. Diese sechsstellige Ziffernfolge wird dem Zahler/Käufer auf der Internet-Seite angezeigt und/oder z. B. per E-Mail an den Zahler/Käufer geschickt.
  • Zusätzlich und/oder alternativ kann der Inhalt des Vertrages auch gespeichert und dauerhaft erfasst werden, indem z. B. an den Zahler/Käufer eine E-Mail mit den Vertragsbedingungen geschickt wird, wobei in der E-Mail eine Referenznummer des Vertrages enthalten ist. Die Referenznummer kann z. B. auch aus einer sechsstelligen Ziffernfolge bestehen (z. B. „949596") und vorteilhafterweise noch Datum, Uhrzeit oder andere Daten miteinschließen.
  • Abweichend vom oben beschriebenen E-Commerce-Szenario übermittelt der Zahler/Käufer nun (zusätzlich zum Betrag) auch die Referenznummer zur Abwicklungsinstanz, z. B. indem er die gewählte Rufnummer („0800-55555-2350") um die besagten sechs Ziffern erweitert, also „0800-55555-2350-949596" wählt.
  • Alternativ kann auch der digitale Abdruck übermittelt werden, z. B. als Teil der Rufnummer, indem „0800-55555-2350-141516” gewählt wird.
  • Alternativ können auch sowohl der digitale Abdruck als auch die Referenznummer übermittelt werden.
  • Alternativ kann auch auf die Übermittlung des Zahlbetrages verzichtet werden.
  • Alternativ kann auch der zahlungsspezifische Teil des beschriebenen Verfahrens ausgelassen und das Verfahren nur für die Durchführung und/oder Dokumentation des Vertragsabschlusses genutzt werden. So kann beispielsweise die Zahlung über eine herkömmliche Kreditkarte erfolgen und die Kreditkartenzahlung inklusive der Kreditkartendaten Teil des abgeschlossenen Vertrages sein.
  • In einer weiteren Ausgestaltung kann sogar ausschließlich eine separat erfolgende herkömmliche Kreditkartenzahlung Gegenstand der Willenserklärung und/oder des Vertragsabschlusses sein. In diesem Fall könnte der digitale Abdruck und/oder die Referenznummer z. B. aus einer Quersumme, Checksumme oder einem Teil der Kreditkartennummer oder aus dem der Kreditkartennummer ergänzend zugeordneten sogenannten CVC-Code bestehen.
  • Alle Daten können ganz oder teilweise auch per DTMF-Töne oder per SMS oder ein anderes Verfahren übertragen werden.
  • Durch die dargestellten Verfahrensausgestaltungen wird eine hohe Dokumentations- und Nachweissicherheit über den abgeschlossenen Vertrag erreicht. Dadurch, dass die Datenübermittlung des digitalen Abdrucks (Digests) und/oder der Referenznummer parallel zum Internet über das Mobiltelefon des Benutzers übertragen wird, werden die Daten insgesamt gegen Manipulation im Internet geschützt.
  • Zusätzlich kommen die nach dem Stand der Technik bekannten systemimmanenten Sicherheitsvorteile der Nutzung von Mobiltelefonen für E-Commerce- und/oder M-Commerce-Transaktionen zum Tragen (Besitz bzw. physischer Zugriff auf das Mobiltelefon, Sicherung durch SIM-Karten-PIN und/oder Geräte-PIN).
  • Weiterhin kann (sofern die Übermittlung der Daten als Teil der Rufnummer erfolgt), die oben beschriebene Beleg-Funktion der Einzelverbindungsnachweis des Telekommunikations-Providers ausgenutzt werden.

Claims (25)

  1. Verfahren zum Initiieren und/oder Durchführen einer Zahlungstransaktion zwischen mindestens zwei Transaktionsparteien, denen jeweils ein Kommunikationsgerät zugeordnet ist, über eine Abwicklungsinstanz, bei dem a) mindestens zwei der Transaktionsparteien Daten an die Abwicklungsinstanz übermitteln, wobei diese Daten Merkmale enthalten, die die Zuordnung der Transaktionsparteien untereinander ermöglichen, und wobei die Übermittlung der Daten innerhalb eines begrenzten Zeitfensters erfolgt, und b) die Initiierung der Datenübermittlung dieser Transaktionsparteien aktiv durch die Transaktionsparteien und nicht durch die Abwicklungsinstanz (3) erfolgt, dadurch gekennzeichnet, c) dass die von den mindestens zwei Transaktionsparteien bereits bei der Initiierung übertragenen Daten jeweils den zu zahlenden Betrag an Geld oder Werteinheiten enthalten und d) dass die von jeweils einer Transaktionspartei übermittelten Daten hinreichend sind, um eine eindeutige Identifikation dieser Transaktionspartei zu ermöglichen, aber nicht hinreichend sind, um eine Identifikation der anderen Transaktionspartei zu ermöglichen.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Festlegung des Zahlbetrages durch eine aktive Eingabe des Betrages und nicht durch passive Bestätigung eines angezeigten oder angesagten Betrages erfolgt.
  3. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die von mindestens zwei der Transaktionsparteien an die Abwicklungsinstanz übermittelten Daten zueinander nach einer bestimmten Vorschrift in Beziehung stehen.
  4. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die von den Transaktionsparteien an die Abwicklungsinstanz übermittelten Daten a) den wesentlichen Teil der Inhalte der jeweiligen Zahlungstransaktion b) und/oder einen digitalen Abdruck (Digest, Hash-Wert) der Inhalte der jeweiligen Zahlungstransaktion c) und/oder eine Referenz auf an anderer Stelle erfasste Inhalte der jeweiligen Zahlungstransaktion enthalten
  5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Abwicklungsinstanz eine Prüfinstanz umfasst oder mit einer Prüfinstanz verbunden ist, die prüft, ob eine Zuordnung der Transaktionsparteien anhand der jeweils übermittelten Daten möglich ist.
  6. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Abwicklungsinstanz eine Transaktionsinstanz umfasst oder mit einer Transaktionsinstanz verbunden ist, welche die Transaktionen durchführt.
  7. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Abwicklungsinstanz eine Signalisierungsinstanz umfasst oder mit einer Signalisierungsinstanz verbunden ist, die Signalisierungen auslöst und/oder Daten an die Transaktionsparteien oder an andere Empfänger übermittelt.
  8. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Datenübermittlung mindestens einer der Transaktionsparteien durch die Initiierung eines Telefonanrufs zur Abwicklungsinstanz erfolgt.
  9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass die Übermittlung mindestens eines Teils der von mindestens einer der Transaktionsparteien übermittelten Daten durch die beim Aufbau eines Telefonanrufs zur Abwicklungsinstanz gewählte Telefonnummern-Ziffernfolge erfolgt.
  10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass die Telefonnummern-Ziffernfolge so kurz ist, dass sie von den Vermittlungsstellen und/oder Übermittlungssystemen vollständig übertragen werden kann.
  11. Verfahren nach den Ansprüchen 7 und 8, dadurch gekennzeichnet, dass die Signalisierung dadurch erfolgt, dass der Anruf a) durch Abheben der Abwicklungsinstanz angenommen wird b) oder unter Signalisierung eines Freizeichens nicht angenommen wird c) oder ein Besetzt-Signal oder ein anderes Signal signalisiert wird d) oder dass unterschiedlich lange Zeitintervalle zwischen dem Übergang verschiedener Rufaufbau-Signale und/oder Rufabbau-Signale liegen.
  12. Verfahren nach den Ansprüchen 7 und 8, dadurch gekennzeichnet, dass beide Transaktionsparteien ein Festnetztelefon oder Mobiltelefon verwenden und dass zwischen beiden Transaktionsparteien eine Telefonverbindung hergestellt wird.
  13. Verfahren nach den Ansprüchen 7 und 8, dadurch gekennzeichnet, dass die Signalisierung dadurch erfolgt, dass von der Abwicklungsinstanz ein Rückruf an mindestens eine der Transaktionsparteien initiiert wird.
  14. Verfahren nach Anspruch 13, dadurch gekennzeichnet, dass die Signalisierung dadurch erfolgt, dass bei dem von der Abwicklungsinstanz initiierten Rückruf von der Abwicklungsinstanz eine spezielle Anrufer-Rufnummer (ANI) generiert und übergeben wird, wobei aus dieser ANI Rückschlüsse auf das Ergebnis der Prüfinstanz und/oder auf den Status der Durchführung von Transaktionen durch die Transaktionsinstanz möglich sind.
  15. Verfahren nach Anspruch 13, dadurch gekennzeichnet, dass die von der Abwicklungsinstanz ausgehenden Rückrufe in den Telekommunikationsgeräten der Transaktionsparteien signalisiert, aber von diesen nicht angenommen werden.
  16. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass a) die Transaktionsparteien einen Zahler und einen Zahlungsempfänger umfassen, b) der Zahler einen Telefonanruf an die Abwicklungsinstanz initiiert, c) die dabei gewählte Telefonnummer eine Ziffernfolge enthält, die dem Zahlbetrag entspricht, d) der Zahlungsempfänger simultan oder zeitnah zum Anruf des Zahlers Daten an die Abwicklungsinstanz übermittelt, die den Zahlbetrag enthalten e) eine Prüfinstanz prüft, ob die von Zahler und Zahlungsempfänger übermittelten Daten einander eindeutig zuordenbar sind und mindestens die enthaltenen Zahlbeträge übereinstimmen f) eine Transaktionsinstanz prüft, ob anhand der übermittelten Daten eine Identifikation und/oder Legitimation von Zahler und Zahlungsempfänger möglich ist und/oder ob die Verarbeitung des Zahlungsvorgangs möglich ist g) bei positiver Prüfung von Prüfinstanz und Transaktionsinstanz – die Transaktionsinstanz die Weiterverarbeitung durchführt oder veranlasst – der Anruf des Zahlers von einer Signalisierungsinstanz angenommen wird und ggf. eine akustische Ansage erfolgt, aus der hervorgeht, dass die Zahlung erfolgt ist, – ein Bestätigungssignal über die erfolgte Zahlung an den Zahlungsempfänger übermittelt wird h) für den Fall, dass eine der vorangegangenen Prüfungen negativ ausfällt, der Anruf des Zahlers von der Abwicklungsinstanz nicht angenommen wird oder verzögert angenommen wird und/oder eine akustische Ansage erfolgt, aus der hervorgeht, dass die Zahlung nicht erfolgt ist.
  17. Verfahren nach Anspruch 16, dadurch gekennzeichnet. dass a) auch die Übermittlung der Daten des Zahlungsempfängers an die Abwicklungsinstanz dadurch erfolgt, dass der Zahlungsempfänger einen Telefonanruf an die Abwicklungsinstanz initiiert b) die dabei gewählte Telefonnummer eine Ziffernfolge enthält, die dem Zahlbetrag entspricht c) bei positiver Prüfung von Prüfinstanz und Transaktionsinstanz nach erfolgter Zahlung das Bestätigungssignal an den Zahlungsempfänger dadurch übermittelt wird, dass auch der Anruf des Zahlungsempfängers von der Signalisierungsinstanz angenommen wird und ggf. eine akustische Ansage erfolgt, aus der hervorgeht, dass die Zahlung erfolgt ist, d) für den Fall, dass eine der vorangegangenen Prüfungen negativ ausfällt, auch der Anruf des Zahlungsempfängers nicht angenommen wird oder verzögert angenommen wird und/oder eine akustische Ansage erfolgt, aus der hervorgeht, dass die Zahlung nicht erfolgt ist
  18. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass zusätzlich ein Zahlungszuordnungs-Referenzcode übertragen wird, der die eindeutige Zuordnung der Transaktionsparteien ermöglicht oder erleichtert.
  19. Verfahren nach Anspruch 18, dadurch gekennzeichnet, dass der Zahlungszuordnungs-Referenzcode aus einem Teil der Ziffern der Rufnummer (ANI) mindestens einer anderen Transaktionspartei besteht, die ein Festnetztelefon oder Mobiltelefon oder ein mobiles Kommunikationsgerät zur Übermittlung der Daten benutzt, oder über eine bestimmte Vorschrift aus dieser Rufnummer gebildet wird.
  20. Verfahren nach einem der Ansprüche 16, 17 oder 18, dadurch gekennzeichnet, dass der Zahlbetrag nicht im Klartext, sondern als verschlüsselte Ziffernfolge übermittelt und/oder um eine Prüfziffer oder Prüfziffernfolge ergänzt wird.
  21. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die erfolgreiche Durchführung der Transaktion oder ein anderer Status den Transaktionsparteien synchron durch ein akustisches Signal signalisiert wird
  22. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass ein Stimmenvergleich (Voice-Sampling) oder ein anderes biometrisches Verfahren als Autorisierungsmechanismus dient.
  23. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass Informationen über den Aufenthaltsort der Transaktionsparteien als zusätzliches Zuordnungskriterium verwendet werden.
  24. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass Prüfungs- und/oder Verarbeitungsschritte bereits ausgeführt werden, bevor der Anruf durch Abheben der Abwicklungsinstanz angenommen wird.
  25. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass der Anruf nur im Falle einer erfolgreichen Durchführung der Transaktion durch Abheben der Abwicklungsinstanz angenommen wird.
DE10310527A 2003-03-11 2003-03-11 Verfahren zum Initiieren und/oder Durchführen einer Zahlungstransaktion Expired - Fee Related DE10310527B4 (de)

Priority Applications (12)

Application Number Priority Date Filing Date Title
DE10310527A DE10310527B4 (de) 2003-03-11 2003-03-11 Verfahren zum Initiieren und/oder Durchführen einer Zahlungstransaktion
EP04719443A EP1602088A2 (de) 2003-03-11 2004-03-11 Verfahren und system zum initiieren und/oder durchführen einer mit mindestens zwei korrespondierenden willenserklärungen in beziehung stehenden transaktion
PCT/EP2004/002520 WO2004081892A2 (de) 2003-03-11 2004-03-11 Verfahren und system zum initiieren und/oder durchführen einer mit mindestens zwei korrespondierenden willenserklärungen in beziehung stehenden transaktion
US10/548,492 US7702581B2 (en) 2003-03-11 2004-03-11 Method and system for initiating and/or conducting a transaction that is associated with at least two corresponding declarations of intent
CN200480012808.6A CN1788292A (zh) 2003-03-11 2004-03-11 用于启动和/或执行与至少两个对应的意图声明相关联的交易的方法和系统
JP2006504645A JP2006524938A (ja) 2003-03-11 2004-03-11 少なくとも２つの対応する意思表示に関連づけられたトランザクションを開始および／または実行する方法およびシステム
CA002518448A CA2518448A1 (en) 2003-03-11 2004-03-11 Method and system for initiating and/or conducting a transaction that is associated with at least two corresponding declarations of intent
AU2004219478A AU2004219478A1 (en) 2003-03-11 2004-03-11 Method and system for initiating and/or carrying out a transaction that is associated with at least two professed intentions
US12/728,544 US8065232B2 (en) 2003-03-11 2010-03-22 Method and system for initiating and/or conducting a transaction that is associated with at least two corresponding declarations of intent
US13/285,201 US8566238B2 (en) 2003-03-11 2011-10-31 Method for a payment transaction associated with two corresponding declarations of intent
US13/941,807 US8831990B2 (en) 2003-03-11 2013-07-15 Method and system for a payment transaction associated with a declaration of intent
US14/476,780 US20140372292A1 (en) 2003-03-11 2014-09-04 Method and system for a payment transaction associated with a declaration of intent

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10362252 2003-03-11
DE10310527A DE10310527B4 (de) 2003-03-11 2003-03-11 Verfahren zum Initiieren und/oder Durchführen einer Zahlungstransaktion

Publications (2)

Publication Number Publication Date
DE10310527A1 DE10310527A1 (de) 2004-09-23
DE10310527B4 true DE10310527B4 (de) 2008-11-20

Family

ID=32892028

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10310527A Expired - Fee Related DE10310527B4 (de) 2003-03-11 2003-03-11 Verfahren zum Initiieren und/oder Durchführen einer Zahlungstransaktion

Country Status (8)

Country Link
US (5) US7702581B2 (de)
EP (1) EP1602088A2 (de)
JP (1) JP2006524938A (de)
CN (1) CN1788292A (de)
AU (1) AU2004219478A1 (de)
CA (1) CA2518448A1 (de)
DE (1) DE10310527B4 (de)
WO (1) WO2004081892A2 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7784684B2 (en) 2002-08-08 2010-08-31 Fujitsu Limited Wireless computer wallet for physical point of sale (POS) transactions
US7877605B2 (en) 2004-02-06 2011-01-25 Fujitsu Limited Opinion registering application for a universal pervasive transaction framework

Families Citing this family (51)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7822688B2 (en) 2002-08-08 2010-10-26 Fujitsu Limited Wireless wallet
US7353382B2 (en) 2002-08-08 2008-04-01 Fujitsu Limited Security framework and protocol for universal pervasive transactions
US7801826B2 (en) 2002-08-08 2010-09-21 Fujitsu Limited Framework and system for purchasing of goods and services
DE10310527B4 (de) * 2003-03-11 2008-11-20 Christian Hogl Verfahren zum Initiieren und/oder Durchführen einer Zahlungstransaktion
US7341180B2 (en) * 2004-01-29 2008-03-11 Alpha Network Co., Ltd. Card settlement system
WO2005076523A1 (en) * 2004-02-05 2005-08-18 Veritas Mobile Solutions Pte. Ltd. System and method for authenticating the identity of a user
US10862994B1 (en) * 2006-11-15 2020-12-08 Conviva Inc. Facilitating client decisions
US7734463B1 (en) * 2004-10-13 2010-06-08 Intervoice Limited Partnership System and method for automated voice inflection for numbers
US8874725B1 (en) 2006-11-15 2014-10-28 Conviva Inc. Monitoring the performance of a content player
US20080126258A1 (en) * 2006-11-27 2008-05-29 Qualcomm Incorporated Authentication of e-commerce transactions using a wireless telecommunications device
US7848980B2 (en) * 2006-12-26 2010-12-07 Visa U.S.A. Inc. Mobile payment system and method using alias
FR2919742B1 (fr) * 2007-08-01 2010-10-22 Phoum Lib Procede technique de securisation permettant de certifier les actions utilisateur lors de transactions sur terminaux mobiles
US9177313B1 (en) * 2007-10-18 2015-11-03 Jpmorgan Chase Bank, N.A. System and method for issuing, circulating and trading financial instruments with smart features
US8249985B2 (en) * 2007-11-29 2012-08-21 Bank Of America Corporation Sub-account mechanism
US9558485B2 (en) * 2008-01-30 2017-01-31 Paypal, Inc. Two step near field communication transactions
WO2010086879A1 (en) * 2009-01-16 2010-08-05 Mchek India Payment Systems Pvt. Ltd. A system and method for carrying out a financial transaction
WO2010141886A1 (en) * 2009-06-04 2010-12-09 Mobile Messenger Global, Inc. Method and system for providing real-time access to mobile commerce purchase confirmation evidence
US9203913B1 (en) * 2009-07-20 2015-12-01 Conviva Inc. Monitoring the performance of a content player
CN101996451B (zh) * 2009-08-14 2012-07-25 中国工商银行股份有限公司 银行自助设备系统的测试方法及服务器
US8818882B2 (en) * 2009-08-24 2014-08-26 Visa International Service Association Alias identity and reputation validation engine
JP5527857B2 (ja) * 2009-09-24 2014-06-25 日本電信電話株式会社 電子決済方法、システム、サーバ及びそのプログラム
US8781393B2 (en) * 2009-09-30 2014-07-15 Ebay Inc. Network updates of time and location
US20110076941A1 (en) * 2009-09-30 2011-03-31 Ebay Inc. Near field communication and network data/product transfer
US20110195748A1 (en) * 2010-02-09 2011-08-11 Jonathan Main Enhanced security feature for payment-enabled mobile telephone
US9665864B2 (en) 2010-05-21 2017-05-30 Intel Corporation Method and device for conducting trusted remote payment transactions
US8995630B1 (en) 2010-08-01 2015-03-31 Tulsa Holdings, Llc Telephony and applications communication in a non-mobile telephone system
USD774529S1 (en) 2010-11-04 2016-12-20 Bank Of America Corporation Display screen with graphical user interface for funds transfer
US9836737B2 (en) 2010-11-19 2017-12-05 Mastercard International Incorporated Method and system for distribution of advertisements to mobile devices prompted by aural sound stimulus
US9384499B2 (en) 2010-11-19 2016-07-05 Mastercard International Incorporated Method and system for indirect control of a website
US10043209B2 (en) 2010-11-19 2018-08-07 Mastercard International Incorporated Method and system for consumer transactions using voice or human based gesture actions
US9836780B2 (en) 2010-11-19 2017-12-05 Mastercard International Incorporated Method and system for consumer transactions using voice or human based gesture actions
USD774526S1 (en) 2011-02-21 2016-12-20 Bank Of America Corporation Display screen with graphical user interface for funds transfer
USD774528S1 (en) 2011-02-21 2016-12-20 Bank Of America Corporation Display screen with graphical user interface for funds transfer
USD774527S1 (en) 2011-02-21 2016-12-20 Bank Of America Corporation Display screen with graphical user interface for funds transfer
WO2013106047A1 (en) * 2011-04-07 2013-07-18 Fotec Group Llc Broker-mediated payment systems and methods
US8725586B2 (en) * 2011-08-17 2014-05-13 Douglas Levin Accounting system and management methods of transaction classifications that is simple, accurate and self-adapting
DE102011087959A1 (de) * 2011-12-08 2013-06-13 Ford Global Technologies, Llc Verfahren und Vorrichtung zur Abwicklung einer straßennutzungsabhängigen Finanztransaktion sowie Computerprogrammprodukt
US10127540B2 (en) * 2011-12-19 2018-11-13 Paypal, Inc. System and method for facilitating electronic financial transactions during a phone call
CN103457913B (zh) * 2012-05-30 2017-10-13 阿里巴巴集团控股有限公司 数据处理方法、通信终端、服务器及系统
US9246965B1 (en) 2012-09-05 2016-01-26 Conviva Inc. Source assignment based on network partitioning
US10182096B1 (en) 2012-09-05 2019-01-15 Conviva Inc. Virtual resource locator
USD770478S1 (en) 2012-09-07 2016-11-01 Bank Of America Corporation Communication device with graphical user interface
US8959032B2 (en) 2012-10-10 2015-02-17 Quisk, Inc. Self-authenticating peer to peer transaction
US20150095239A1 (en) * 2013-09-30 2015-04-02 Fiserv , Inc. Card account identifiers associated with conditions for temporary use
CN105338480B (zh) * 2014-06-24 2020-01-24 创新先进技术有限公司 基于lbs的用户匹配方法、消息客户端、服务器及系统
US10178043B1 (en) 2014-12-08 2019-01-08 Conviva Inc. Dynamic bitrate range selection in the cloud for optimized video streaming
US10305955B1 (en) 2014-12-08 2019-05-28 Conviva Inc. Streaming decision in the cloud
GB2535433A (en) * 2014-12-12 2016-08-24 Aeriandi Ltd Method and apparatus for call correlation
DE102015118999A1 (de) * 2015-11-05 2017-05-11 Deutsche Post Ag Vorzeitige Auslösung des Bezahlprozesses für Nachnahme-Sendungen
US10762788B2 (en) * 2017-08-01 2020-09-01 Swoppz, LLC Method and system for requesting and granting priority between vehicles
JP7030043B2 (ja) * 2018-11-27 2022-03-04 本田技研工業株式会社 対価を伴う優先的な通行を行うための情報処理装置、情報処理装置の制御方法、通信装置、通信装置の制御方法、およびプログラム

Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19903822A1 (de) * 1999-02-02 2000-08-10 Mathias Entenmann Verfahren zur Durchführung bargeldloser Zahlungen und System zur Durchführung des Verfahrens
DE19905054A1 (de) * 1999-02-08 2000-08-17 Siemens Ag Verfahren und Anordnung zur Administration eines Zahlungsvorgangs über ein Telekommunikationsnetz
DE19934981A1 (de) * 1999-07-26 2001-02-01 Alcatel Sa Verfahren zur Abgabe einer Ware oder zum Erbringen einer Dienstleistung unter Einsatz eines Mobilfunk-Endgeräts, Mobilfunk-Endgerät zur Durchführung des Verfahrens und Einrichtung zur Abgabe einer Ware oder zum Erbringen einer Dienstleistung
EP1081919A1 (de) * 1999-09-06 2001-03-07 GEBIT Gesellschaft für EDV-Beratung und Informatik-Technologien mbH Verfahren zur Autorisierung in Datenübertragungssystemen zur Bezahlung von über das Internet angebotenen Waren und/oder Dienstleistungen
DE19946539A1 (de) * 1999-09-28 2001-04-19 Deutsche Telekom Mobil Verfahren zur Abrechnung von Internet-Geschäften über Mobilfunk
WO2001031594A1 (de) * 1999-10-25 2001-05-03 Swisscom Mobile Ag Zahlungstransaktionsverfahren und zahlungstransaktionssystem
JP2001306966A (ja) * 2000-04-19 2001-11-02 Nikon Gijutsu Kobo:Kk 電子商取引方法
JP2001331561A (ja) * 2000-05-24 2001-11-30 Nippon Denki Information Technology Kk 端末機取扱システム
WO2001093218A1 (de) * 2000-05-26 2001-12-06 Hoeffle Christian System, verfahren und programm zur zahlung in einem telekommunikationsnetz
DE10039569C1 (de) * 2000-08-09 2001-12-06 Mannesmann Ag Verfahren zur Bezahlung an beliebigen Verkaufs- bzw. Dienstleistungsstellen mit Mobiltelefon
DE10040799A1 (de) * 2000-08-21 2002-04-25 Siemens Ag Verfahren für sichere Transaktionen im Zusammenhang mit elektronischem Handel
EP1231578A2 (de) * 2001-02-01 2002-08-14 Siemens Aktiengesellschaft Verfahren und Anordnung zur Durchführung einer bargeldlosen Zahlungsaktion
WO2002071353A1 (de) * 2001-03-01 2002-09-12 Peter Ligezinski Vorrichtung und verfahren zum bargeldlosen bezahlen

Family Cites Families (92)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4960981A (en) * 1989-01-17 1990-10-02 Moneyfax, Inc. Method of and system for electronic funds transfer via facsimile machines
US5122950A (en) * 1989-11-02 1992-06-16 Moneyfax, Inc. Method of and system for electronic funds transfer via facsimile machines
US5383113A (en) * 1991-07-25 1995-01-17 Checkfree Corporation System and method for electronically providing customer services including payment of bills, financial analysis and loans
US5557518A (en) * 1994-04-28 1996-09-17 Citibank, N.A. Trusted agents for open electronic commerce
US5504677A (en) * 1992-10-15 1996-04-02 Pollin; Robert E. Automated payment system
US5465206B1 (en) * 1993-11-01 1998-04-21 Visa Int Service Ass Electronic bill pay system
US5583759A (en) * 1993-11-22 1996-12-10 Huntington Bancshares, Inc. Mechanism for expediting the deposit, transport and submission of checks into the payment system
US6996542B1 (en) * 1994-06-03 2006-02-07 Midwest Payment Systems System and method for paying bills and other obligations including selective payor and payee controls
US5608778A (en) * 1994-09-22 1997-03-04 Lucent Technologies Inc. Cellular telephone as an authenticated transaction controller
US5577100A (en) * 1995-01-30 1996-11-19 Telemac Cellular Corporation Mobile phone with internal accounting
EP1643340B1 (de) * 1995-02-13 2013-08-14 Intertrust Technologies Corp. Sicheres Transaktionsmanagement
US7069451B1 (en) * 1995-02-13 2006-06-27 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US6424249B1 (en) * 1995-05-08 2002-07-23 Image Data, Llc Positive identity verification system and method including biometric user authentication
FI102860B (fi) * 1995-11-07 1999-02-26 Nokia Telecommunications Oy Menetelmä ja järjestelmä elektronisen maksutapahtuman suorittamiseksi
US5991749A (en) * 1996-09-11 1999-11-23 Morrill, Jr.; Paul H. Wireless telephony for collecting tolls, conducting financial transactions, and authorizing other activities
JP3660101B2 (ja) * 1996-11-14 2005-06-15 松下電器産業株式会社 パーソナル電子決済システム
US6199761B1 (en) * 1996-12-09 2001-03-13 Drexler Technology Corporation Validation method for electronic cash cards and digital identity cards utilizing optical data storage
GB2321751B (en) * 1997-04-22 1999-02-10 Searchspace Limited A monitoring system and method
ATE220814T1 (de) 1997-06-27 2002-08-15 Swisscom Mobile Ag Transaktionsverfahren mit einem tragbaren identifizierungselement
US5978780A (en) * 1997-11-21 1999-11-02 Craig Michael Watson Integrated bill consolidation, payment aggregation, and settlement system
EP1617389A3 (de) * 1999-02-18 2006-09-27 Matsushita Electric Industrial Co., Ltd. Servergerät und Terminal von einem Nutzer zum Gebrauch in einem Gebrauchssystem für elektronische Vermögenswerte
KR100314210B1 (ko) * 1999-02-23 2001-11-17 김용훈 이동통신단말기를 이용한 물품대금 결제방법
US6873691B1 (en) * 1999-04-06 2005-03-29 Bellsouth Intellectual Property Corporation Methods and systems for using the public switched telephone network to conduct a transaction between customer accounts
EP1175656A2 (de) * 1999-04-27 2002-01-30 I3E Holdings, Llc System zum fernbestellen
US6289323B1 (en) * 1999-06-18 2001-09-11 United States Postal Service System and method for completing monetary transactions by presentment of postage value to a postal authority
DE19928341C2 (de) 1999-06-21 2002-06-20 Inb Vision Ag Verfahren zur dreidimensionalen optischen Vermessung von Objektoberflächen
DE19946537A1 (de) * 1999-09-28 2001-04-05 Deutsche Telekom Mobil Verfahren zur Abrechnung von Internet-Dienstleistungen über Mobilfunk
US7127427B1 (en) * 1999-10-05 2006-10-24 Andrew Casper Secure transaction processing system and method
US7124101B1 (en) * 1999-11-22 2006-10-17 Accenture Llp Asset tracking in a network-based supply chain environment
US8571975B1 (en) * 1999-11-24 2013-10-29 Jpmorgan Chase Bank, N.A. System and method for sending money via E-mail over the internet
AU784041B2 (en) * 1999-11-30 2006-01-19 Citibank, N.A. System and method for performing an electronic transaction using a transaction proxy with an electronic wallet
US6464134B1 (en) * 1999-12-10 2002-10-15 Terri Page System and method for verifying the authenticity of a check and authorizing payment thereof
CN1434956A (zh) * 1999-12-17 2003-08-06 世界剧院公司 允许顾客从参与商提供的产品中订购产品的系统和方法
AU780943B2 (en) * 1999-12-30 2005-04-28 International Business Machines Corporation Method of payment by means of an electronic communication device
DE10008280C1 (de) * 2000-02-23 2001-06-13 Wire Card Ag Verfahren und System zur automatischen Abwicklung von bargeldlosen Kaufvorgängen
US7366695B1 (en) * 2000-02-29 2008-04-29 First Data Corporation Electronic purchase method and funds transfer system
AU2656500A (en) 2000-02-29 2001-09-12 Swisscom Mobile Ag Transaction confirmation method, authentication server and wap server
AU779316B2 (en) * 2000-03-16 2005-01-13 Harex Infotech Inc. Optical payment transceiver and system using the same
US20010037284A1 (en) * 2000-03-27 2001-11-01 Finkelstein Ephraim Brian Negotiated right exchange system and method
US20010037308A1 (en) * 2000-03-28 2001-11-01 Mark Kotlarsky Fully secure identification and transmission system
JP2001290874A (ja) * 2000-04-07 2001-10-19 Nec Corp 入金管理方法およびシステム
WO2001082243A2 (en) * 2000-04-20 2001-11-01 Innovative Payment Systems, Llc Method and system for ubiquitous enablement of electronic currency
US6917853B2 (en) * 2000-05-23 2005-07-12 Munroe Chirnomas Method and apparatus for controlling rented or leased or loaned equipment
US7890433B2 (en) * 2000-06-30 2011-02-15 Tara Chand Singhal Private and secure payment system
EP1182625A1 (de) * 2000-08-25 2002-02-27 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Einleitung einer elektronischen Zahlungstransaktion
US7415442B1 (en) * 2000-09-26 2008-08-19 Integrated Technological Systems, Inc. Integrated technology money transfer system
US20020152179A1 (en) * 2000-10-27 2002-10-17 Achiezer Racov Remote payment method and system
JP3581094B2 (ja) * 2000-10-31 2004-10-27 株式会社プロトコーポレーション 残価予測システム及びその方法、並びにコンピュータ上で動作する残価予測プログラムを記録した記録媒体
GB0027922D0 (en) * 2000-11-15 2001-01-03 Haidar Mahmoud N Y Electronic payment and associated systems
US20020073027A1 (en) * 2000-12-11 2002-06-13 Hui Helen Shan-Shan Mobile payment system
WO2002050788A2 (en) * 2000-12-18 2002-06-27 in medias res Gesellschaft für Kommunikationstechnologien mbH Accounting method and accounting machine
GB2372615A (en) * 2000-12-27 2002-08-28 Robert Joseph Gerard Macnamee Telephone based payment system
WO2002077888A1 (fr) * 2001-03-26 2002-10-03 Makoto Dojo Dispositif de facturation, procede de facturation, dispositif acceptant les transactions et procede acceptant les transactions
US20020143638A1 (en) * 2001-03-28 2002-10-03 August Katherine G. System and method for conducting wireless customer/vendor transactions
US7117183B2 (en) * 2001-03-31 2006-10-03 First Data Coroporation Airline ticket payment and reservation system and methods
US7165052B2 (en) * 2001-03-31 2007-01-16 First Data Corporation Payment service method and system
US7107249B2 (en) * 2001-03-31 2006-09-12 First Data Corporation Electronic identifier payment systems and methods
US7184989B2 (en) * 2001-03-31 2007-02-27 First Data Corporation Staged transactions systems and methods
US20020143655A1 (en) * 2001-04-02 2002-10-03 Stephen Elston Remote ordering system for mobile commerce
WO2002086829A1 (en) * 2001-04-16 2002-10-31 Mobile Solutions And Payment Services Pte Ltd Method and system for performing a transaction utilising a thin payment network (mvent)
US7752136B2 (en) * 2001-05-18 2010-07-06 Meadow William D Check authorization system and method
WO2003009243A1 (en) * 2001-07-19 2003-01-30 W3 Infocomm Group Pte Ltd Mobile electronic funds transfer system and method
EP1282087A1 (de) * 2001-08-02 2003-02-05 Alcatel Verfahren zur Durchführung von Transaktionen von elektronischen Geldbeträgen zwischen Teilnehmerendgeräten eines Kommunikationsnetzes, Transaktionsserver und Programmmodul hierfür
ATE452390T1 (de) * 2001-08-03 2010-01-15 Ericsson Telefon Ab L M Verfahren und vorrichtungen für bezahlungen zwischen endgeräten
US7103576B2 (en) * 2001-09-21 2006-09-05 First Usa Bank, Na System for providing cardless payment
DE10151213B4 (de) * 2001-10-15 2006-03-16 Siemens Ag Verfahren zum Genehmigen von Zahlungen in einem Kommunikationsnetz
US20030074209A1 (en) * 2001-10-15 2003-04-17 Tobin Christopher M. User device with service finding and purchasing functionality
US7337229B2 (en) * 2001-11-08 2008-02-26 Telefonktiebolaget Lm Ericsson (Publ) Method and apparatus for authorizing internet transactions using the public land mobile network (PLMN)
WO2003054819A2 (en) * 2001-12-12 2003-07-03 Paradata Systems Inc. Global integrated payment system
US20030130942A1 (en) * 2002-01-08 2003-07-10 Bottomline Technologies (De) Inc. Automated invoice receipt and management system with automated loading systems
WO2003065260A1 (fr) 2002-01-28 2003-08-07 Fujitsu Limited Procede de transaction et dispositif de transaction automatique permettant de mettre en oeuvre ledit procede
HU224788B1 (hu) * 2002-02-07 2006-02-28 Enigma Software Rt Architektúra kiterjedt ügyfélkörben végrehajtható bankkártyás fizetési tranzakciók egyszerûsített hardverigényû lebonyolításához, tranzakciós terminálegység, bõvített funkciós SIM kártya, valamint eljárások megszemélyesítésre és tranzakciók lebonyolítására
US8909557B2 (en) * 2002-02-28 2014-12-09 Mastercard International Incorporated Authentication arrangement and method for use with financial transaction
US20020107007A1 (en) * 2002-03-27 2002-08-08 Howard Gerson Method for wireless telephony payment and an apparatus therefor
EP1367516A1 (de) * 2002-05-29 2003-12-03 SubClearing AS System, Methode und Mittel für elektronische Transaktionen
DE10229477A1 (de) * 2002-07-01 2004-01-29 Siemens Ag Bezahlsystem für bargeldlosen Zahlungsverkehr
US7822688B2 (en) * 2002-08-08 2010-10-26 Fujitsu Limited Wireless wallet
DE10249612A1 (de) * 2002-10-18 2004-05-06 Siemens Ag Verfahren zum Vorbereiten eines Bezahlvorganges in einem Kommunikationsnetz
US20040083170A1 (en) * 2002-10-23 2004-04-29 Bam Ajay R. System and method of integrating loyalty/reward programs with payment identification systems
US7360694B2 (en) * 2003-01-23 2008-04-22 Mastercard International Incorporated System and method for secure telephone and computer transactions using voice authentication
DE10310527B4 (de) * 2003-03-11 2008-11-20 Christian Hogl Verfahren zum Initiieren und/oder Durchführen einer Zahlungstransaktion
US20050209964A1 (en) * 2003-07-25 2005-09-22 Allen Robert M Method of Providing Secure Payment and Transaction Reconciliation
US20050031051A1 (en) * 2003-08-04 2005-02-10 Lowell Rosen Multiple access holographic communications apparatus and methods
US7835971B2 (en) * 2003-12-12 2010-11-16 Michael Stockton Method and system configured for facilitating management of international trade receivables transactions
CA2503740A1 (en) * 2005-03-11 2006-09-11 Dushyant Sharma Electronic payment system for financial institutions and companies to receive online payments
CA2647602A1 (en) * 2006-03-30 2008-03-06 Obopay Inc. Mobile person-to-person payment system
US20070265984A1 (en) * 2006-04-24 2007-11-15 Prakash Santhana Financial transaction using mobile devices
US9911114B2 (en) * 2006-07-06 2018-03-06 Qualcomm Incorporated Methods and systems for making a payment via a stored value card in a mobile environment
US7606766B2 (en) * 2006-12-21 2009-10-20 American Express Travel Related Services Company, Inc. Computer system and computer-implemented method for selecting invoice settlement options
US7630937B1 (en) * 2008-04-30 2009-12-08 Intuit Inc. Method and system for processing a financial transaction
US8069115B2 (en) * 2008-06-25 2011-11-29 Douglas Schoenberg Method and system to process payment
DE202012100620U1 (de) 2011-11-22 2012-06-13 Square, Inc. System zur Bearbeitung von kartenlosen Bezahlungstransaktionen

Patent Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19903822A1 (de) * 1999-02-02 2000-08-10 Mathias Entenmann Verfahren zur Durchführung bargeldloser Zahlungen und System zur Durchführung des Verfahrens
DE19905054A1 (de) * 1999-02-08 2000-08-17 Siemens Ag Verfahren und Anordnung zur Administration eines Zahlungsvorgangs über ein Telekommunikationsnetz
DE19934981A1 (de) * 1999-07-26 2001-02-01 Alcatel Sa Verfahren zur Abgabe einer Ware oder zum Erbringen einer Dienstleistung unter Einsatz eines Mobilfunk-Endgeräts, Mobilfunk-Endgerät zur Durchführung des Verfahrens und Einrichtung zur Abgabe einer Ware oder zum Erbringen einer Dienstleistung
EP1081919A1 (de) * 1999-09-06 2001-03-07 GEBIT Gesellschaft für EDV-Beratung und Informatik-Technologien mbH Verfahren zur Autorisierung in Datenübertragungssystemen zur Bezahlung von über das Internet angebotenen Waren und/oder Dienstleistungen
DE19946539A1 (de) * 1999-09-28 2001-04-19 Deutsche Telekom Mobil Verfahren zur Abrechnung von Internet-Geschäften über Mobilfunk
WO2001031594A1 (de) * 1999-10-25 2001-05-03 Swisscom Mobile Ag Zahlungstransaktionsverfahren und zahlungstransaktionssystem
JP2001306966A (ja) * 2000-04-19 2001-11-02 Nikon Gijutsu Kobo:Kk 電子商取引方法
JP2001331561A (ja) * 2000-05-24 2001-11-30 Nippon Denki Information Technology Kk 端末機取扱システム
WO2001093218A1 (de) * 2000-05-26 2001-12-06 Hoeffle Christian System, verfahren und programm zur zahlung in einem telekommunikationsnetz
DE10039569C1 (de) * 2000-08-09 2001-12-06 Mannesmann Ag Verfahren zur Bezahlung an beliebigen Verkaufs- bzw. Dienstleistungsstellen mit Mobiltelefon
DE10040799A1 (de) * 2000-08-21 2002-04-25 Siemens Ag Verfahren für sichere Transaktionen im Zusammenhang mit elektronischem Handel
EP1231578A2 (de) * 2001-02-01 2002-08-14 Siemens Aktiengesellschaft Verfahren und Anordnung zur Durchführung einer bargeldlosen Zahlungsaktion
WO2002071353A1 (de) * 2001-03-01 2002-09-12 Peter Ligezinski Vorrichtung und verfahren zum bargeldlosen bezahlen

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
CHAN, H. u.a: E-Commerce-Fundamentals and Applications, Wiley & Sons, NY, USA,2001, ISBN 0471493031, Kapitel 10, S. 285-313 *
ELLIOT, J.: Signing on the digital Line. IEEReview, Vol. 45, Issue 5, 1999, S. 222-225 *
INSIK HONG u.a.: The implementation of electronic money for E-Commerce using Jaya card. Internat. Symposiums on Industrial Electronics. ISIE 2001, Vol. 2, Juni 2001, S. 1369-1372 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7784684B2 (en) 2002-08-08 2010-08-31 Fujitsu Limited Wireless computer wallet for physical point of sale (POS) transactions
US7877605B2 (en) 2004-02-06 2011-01-25 Fujitsu Limited Opinion registering application for a universal pervasive transaction framework

Also Published As

Publication number Publication date
US20120047067A1 (en) 2012-02-23
CA2518448A1 (en) 2004-09-23
JP2006524938A (ja) 2006-11-02
WO2004081892A2 (de) 2004-09-23
US20100174651A1 (en) 2010-07-08
US8065232B2 (en) 2011-11-22
WO2004081892A3 (de) 2004-10-28
US7702581B2 (en) 2010-04-20
US8831990B2 (en) 2014-09-09
US8566238B2 (en) 2013-10-22
AU2004219478A1 (en) 2004-09-23
US20140372292A1 (en) 2014-12-18
US20070055632A1 (en) 2007-03-08
US20130304650A1 (en) 2013-11-14
EP1602088A2 (de) 2005-12-07
DE10310527A1 (de) 2004-09-23
CN1788292A (zh) 2006-06-14

Similar Documents

Publication Publication Date Title
DE10310527B4 (de) Verfahren zum Initiieren und/oder Durchführen einer Zahlungstransaktion
DE69723333T2 (de) Vorausbezahlungsverfahren für Telefonkommunikationsnutzung
DE102008011192A1 (de) Verfahren und Diensterechner sowie System zur Transaktion eines Geldbetrages
DE102008035391A1 (de) Verfahren zur Authentifizierung
WO2009003605A9 (de) Virtuelle prepaid- oder kreditkarte und verfahren und system zur bereitstellung einer solchen und zum elektronischen zahlungsverkehr
WO2002011082A1 (de) Elektronischer zahlungsverkehr mit sms
DE10156177A1 (de) Verfahren und Anordnung zur Durchführung einer bargeldlosen Zahlungstransaktion
DE19903363A1 (de) Verfahren, System und Mobilstation zur Durchführung von bargeldlosen Transaktionen
EP1264490A2 (de) Verfahren zum festellen der authentizität der identität eines dienste-nutzers und vorrichtung zum durchführen des verfahrens
EP1249996B1 (de) Verfahren zum Abrechnen von Leistungen in einem Kommunikationsnetz
DE10235798A1 (de) Verfahren und eine Vorrichtung zum Anmelden und Verbinden von R-Gesprächen mit intelligenten Netzwerkdiensten (IN-Diensten)
WO2005031667A1 (de) Verfahren zur abwicklung einer elektronischen transaktion
EP0957624B1 (de) Verfahren zur Übernahme von Anrufsgebühren in einzelnen Verbindungen sowie Telefonnetz und Endgerät
DE10054633C2 (de) Verfahren und System zum Kontrollieren des Zugangs zu Waren und Dienstleistungen
DE19738707C2 (de) Verfahren zur Zuordnung einer für begrenzte Zeiteinheiten zur Telekommunikation in einem Telekommunikationsnetz berechtigenden Temporär-Zugangsberechtigung
DE10223282B3 (de) Verfahren, Computerprogramm und Computersystem für einen prepaid Telekommunikationsdienst
EP1175664B1 (de) Verfahren zum verteilen von wertcodes
WO2004070492A2 (de) Kontrolle von kreditkarten-transaktionen
EP2757514B1 (de) Verfahren und Anordnung zum Einrichten einer Datenübertragungsverbindung
DE10210792B4 (de) Verfahren und System zur Freischaltung eines kostenpflichtigen Mobilfunk- oder Online-Dienstes
WO2005022869A2 (de) Zahlungsplattform für netzwerkbetreiber und telekommunikationsendgeräte zur realisierung eines elektronischen zahlungsverkehrs sowie zugehörige verfahren
EP1457939A1 (de) Verfahren zur Übertragung von Zahlungsdienstinformationen
DE19939913A1 (de) Verfahren zur Abrechnung von Geldbeträgen
WO2002071353A1 (de) Vorrichtung und verfahren zum bargeldlosen bezahlen
EP1296298A1 (de) Verfahren zur automatisierten Bezahlung von Waren oder Dienstleistungen

Legal Events

Date Code Title Description
OM8 Search report available as to paragraph 43 lit. 1 sentence 1 patent law
OP8 Request for examination as to paragraph 44 patent law
8127 New person/name/address of the applicant

Owner name: HOGL, CHRISTIAN, 20099 HAMBURG, DE

8127 New person/name/address of the applicant

Owner name: HOGL, CHRISTIAN, 81371 MUENCHEN, DE

8172 Supplementary division/partition in:

Ref document number: 10362252

Country of ref document: DE

Kind code of ref document: P

Q171 Divided out to:

Ref document number: 10362252

Country of ref document: DE

Kind code of ref document: P

AH Division in

Ref document number: 10362252

Country of ref document: DE

Kind code of ref document: P

8364 No opposition during term of opposition
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee