DE112009000137T5 - System und Verfahren zur Datenvervollständigung mit Anschubkennung - Google Patents

System und Verfahren zur Datenvervollständigung mit Anschubkennung Download PDF

Info

Publication number
DE112009000137T5
DE112009000137T5 DE112009000137T DE112009000137T DE112009000137T5 DE 112009000137 T5 DE112009000137 T5 DE 112009000137T5 DE 112009000137 T DE112009000137 T DE 112009000137T DE 112009000137 T DE112009000137 T DE 112009000137T DE 112009000137 T5 DE112009000137 T5 DE 112009000137T5
Authority
DE
Germany
Prior art keywords
payee
information
payment
computer
transaction
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE112009000137T
Other languages
English (en)
Inventor
Matthew Danville Mullen
Mark San Mateo Rockelman
Barbara South San Francisco Patterson
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.)
Visa USA Inc
Original Assignee
Visa USA Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Visa USA Inc filed Critical Visa USA Inc
Publication of DE112009000137T5 publication Critical patent/DE112009000137T5/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102Bill distribution or payments
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/12Accounting

Abstract

Computerimplementiertes Verfahren zum Durchführen einer Transaktion, mit
Empfangen einer Zahlungsanweisungsnachricht an einem Servercomputer, wobei die Zahlungsanweisungsnachricht zum Durchführen einer Zahlung an einen Zahlungsempfänger dient, der ein mit einem Ausgeber verbundenes Konto nutzt, wobei die Zahlungsanweisungsnachricht zumindest eine unvollständige Zahlungsempfängerinformation enthält und wobei die Zahlungsanweisungsnachricht des Weiteren von einer von dem Zahlungsempfänger abweichenden Entität erzeugt wird;
Überprüfen der Zahlungsanweisungsnachricht;
Ermitteln einer im Wesentlichen vollständigen Zahlungsempfängerinformation; und
Senden einer Autorisierungsanforderungsnachricht an den Ausgeber nach dem Prüfen der Zahlungsanweisungsnachricht, wobei die Autorisierungsanforderung eine Anschubkennung (Push-Kennung) enthält.

Description

  • KREUZREFERENZEN ZU VERWANDTEN ANMELDUNGEN
  • Bei dieser Anmeldung handelt es sich um eine nicht-provisorische Anmeldung, die die Priorität der US-Patentanmeldung 61/021,289, eingereicht am 15. Januar 2008 beansprucht, und hier in Gänze und für alle Zwecke als Bezugnahme einbezogen wird.
  • HINTERGRUND
  • Es existieren einige Zahlungsmethoden und -systeme. Beispielsweise kann ein Käufer einem Händler eine Kreditkarte vorlegen, der die Kreditkarte „durchziehen” und die Zahlung von einer mit der Kreditkarte verbundenen Bank erhalten kann. Dieses Verfahren weist viele Vorteile auf, wie etwa verbesserte Betrugserkennung und Sicherheit. Allerdings muss die Kreditkarte (oder die Kartennummer und Sicherheitscodes) zunächst dem Händler präsentiert werden, bevor die Transaktionsbearbeitung erfolgen kann. Somit müssen der Händler und etwaige händlerbezogene Banken von Anfang an in eine Transaktion einbezogen werden, selbst wenn eine solche Transaktion nicht abgeschlossen ist. Des Weiteren kann der Käufer nur schwer einplanen, wann die Zahlungen an den Händler überwiesen werden.
  • Es existieren weitere Zahlungsmethoden, wie beispielsweise Schecks, die Verwendung automatischer Clearing-House-Systeme (ACH), Banküberweisungen usw. Diese Verfahren sind dahingehend vorteilhaft, dass der Händler nicht in die Bearbeitung der Transaktion einbezogen werden muss, wie bei einer Kreditkartentransaktion. Die Transaktionsverfahren sind allerdings begrenzt. Beispielsweise stellen sie keine erweiterte Risikobeurteilung oder Belohnungsprogramme für die Käufer oder Händler bereit. Banküberweisungen können hinsichtlich ihrer Ausführungen mühsam sein, und die Terminierung und transferierbaren Beträge sind begrenzt. Schecks können einige Zeit in Anspruch nehmen, bis sie durch den Empfänger eingelöst werden. Während einer solchen Zeitdauer kann der Käufer den Status des Schecks oder den Zeitpunkt der Abbuchung der Finanzmittel von dem Käuferkonto nicht in Erfahrung bringen. Des Weiteren besteht die inhärente Gefahr verloren gegangener oder gestohlener Schecks.
  • Ausführungsbeispiele der Erfindung richten sich auf die vorgenannten Probleme und weitere Probleme einzeln und in ihrer Gesamtheit.
  • KURZE ZUSAMMENFASSUNG
  • Ausführungsbeispiele der Erfindung enthalten Systeme und Verfahren zum Durchführen einer Push-Transaktion (im Folgenden als Anschubtransaktion bezeichnet), wobei ein Zahlender Zahlungen an einen Zahlungsempfänger initiieren kann, bei geringer Kenntnis der Interaktion seitens des Zahlungsempfängers.
  • Ein Ausführungsbeispiel ist auf ein computerimplementiertes Verfahren zur Durchführung einer Transaktion gerichtet. Das Verfahren umfasst Empfangen einer Zahlungsanweisungsnachricht an einem Servercomputer, wobei die Zahlungsanweisungsnachricht zur Durchführung einer Zahlung an einen Zahlungsempfänger unter Verwendung eines mit einem Ausgeber geknüpften Kontos dient, wobei die Zahlungsanweisungsnachricht zumindest eine unvollständige Zahlungsempfängerinformation enthält und wobei die Zahlungsanweisungsnachricht des Weiteren von einer von dem Zahlungsempfänger verschiedenen Entität erzeugt wird, Überprüfen der Zahlungsanweisungsnachricht, Ermitteln einer im Wesentlichen vollständigen Information über den Zahlungsempfänger, und Senden einer Autorisierungsanforderungsnachricht an den Ausgeber nach Überprüfung der Zahlungsanweisungsnachricht, wobei die Autorisierungsanforderung eine Push-Kennung (im Folgenden als Anschubkennung bezeichnet) enthält.
  • Ein weiteres Ausführungsbeispiel ist auf ein computerimplementiertes Verfahren zur Durchführung einer Zahlung gerichtet. Das Verfahren umfasst Senden einer Zahlungsanweisungsnachricht mit zumindest einer unvollständigen Information über den Zahlungsempfänger, einem Transaktionsbetrag und einem Zahlungszeitpunkt an einen Servercomputer, wobei die Zahlungsanweisungsnachricht durch den Servercomputer analysiert wird, um eine im Wesentliche vollständige Information über den Zahlungsempfänger zu ermitteln, und ein Autorisierungsprotokoll wird an den mit dem Zahlungsempfänger verbundenen Erwerber gesendet, und Überweisen der Finanzmittel an den Zahlungsempfänger.
  • Ein weiteres Ausführungsbeispiel ist auf ein computerimplementiertes Verfahren zum Empfangen einer Push-Zahlungstransaktion (im Folgenden als Anschubzahlungstransaktion bezeichnet) gerichtet. Das Verfahren umfasst Empfangen eines auf eine Transaktion bezogenen Autorisierungsprotokolls, wobei das Autorisierungsprotokoll eine Berichtssystemdatei und eine Abwicklungsdatei enthält, Senden einer Nachricht hinsichtlich des Finanzmittelflusses für die Transaktion, Empfangen von auf die Transaktion bezogenen Finanzmitteln, Überweisen der Finanzmittel an einen Zahlungsempfänger, und Senden einer Transaktionsinformation zu dem Zahlungsempfänger.
  • Ein weiteres Ausführungsbeispiel ist auf ein computerlesbares Medium zum Durchführen von Anschubtransaktionen gerichtet. Das Medium umfasst einen Code zum Empfangen einer Zahlungsanweisungsnachricht zur Durchführung einer Zahlung und Verwendung eines mit einem Ausgeber verbundenen Kontos, wobei die Zahlungsanweisung zumindest eine unvollständige Zahlungsempfängerinformation enthält, und wobei die Zahlungsanweisungsnachricht des Weiteren von einer von dem Zahlungsempfänger verschiedenen Entität herrührt, einen Code zum Überprüfen der Zahlungsanweisungsnachricht, einen Code zum Ermitteln einer im Wesentlichen vollständigen Information über den Zahlungsempfänger, und einen Code zum Senden einer Autorisierungsanforderung an den Ausgeber, wobei die Autorisierungsanforderung eine Anschubkennung enthält.
  • Ein weiteres Ausführungsbeispiels der Erfindung ist auf ein computerlesbares Medium zum Identifizieren eines Zahlungsempfängers in einer Transaktion gerichtet. Das Medium umfasst einen Code zum Empfangen einer Zahlungsanweisungsnachricht, einen Code zum Überprüfen der Zahlungsanweisungsnachricht und zum Ermitteln ob die Zahlungsanweisungsnachricht eine Information zur Bestimmung eines Zahlungsempfängers enthält, und einen Code zum Verwenden eines Fuzzy-Logik-Abgleichs zum Vergleichen der Information in der Zahlungsanweisungsnachricht mit mehreren Datenspeichern, um einen mit der Zahlungsanweisung verbundenen Zahlungsempfänger im Wesentlichen zu identifizieren, wobei die mehreren Datenspeicher eine Vielzahl von Kennungen für zumindest einen Händler enthalten, wobei die Vielzahl von Kennungen eine Kennung für einen Namen, eine Kennung für eine Telefonnummer und eine Kennung für eine Adresse enthalten.
  • Diese und weitere Ausführungsbeispiele der Erfindung werden im Folgenden unter Bezugnahme auf die Zeichnungsfiguren und die detaillierte Beschreibung näher erläutert.
  • KURZBESCHREIBUNG DER ZEICHNUNGSFIGUREN
  • 1 zeigt ein Blockschaltbild eines Systems gemäß einem Ausführungsbeispiel der Erfindung.
  • 2 zeigt ein Flussdiagramm zur Darstellung eines Verfahrens gemäß einem Ausführungsbeispiels der Erfindung.
  • 3 zeigt ein Flussdiagramm zur Darstellung eines Verfahrens gemäß einem Ausführungsbeispiels der Erfindung.
  • 4(a) bis 4(b) zeigen Bockschaltbilder tragbarer Endverbrauchergeräte.
  • 5 zeigt ein Blockschaltbild einer Computervorrichtung.
  • DETAILIERTE BESCHREIBUNG
  • Ausführungsbeispiele der vorliegenden Erfindung sind auf Systeme und Verfahren für Zahlungstransaktionen gerichtet, die durch diejenige Partei initiiert werden, die die Zahlung durchführt. Mit anderen Worten werden Transaktionen von dem Zahlenden angeschoben („gepusht”), statt von dem Zahlungsempfänger angeregt („gepullt”) zu werden. In bestimmten Ausführungsbeispielen kann eine erste Partei (wie beispielsweise ein Käufer in der Transaktion) standardisierte Kreditkartenbearbeitungssysteme zur Überweisung von Zahlungsfinanzmitteln an eine zweite Partei (wie beispielsweise einen Verkäufer) verwenden, ohne jegliche Interaktion mit der zweiten Partei. Die zweite Partei kann eine Mitteilung dahingehend empfangen, dass eine Zahlung durch die erste Partei erfolgt ist, und dass die damit verknüpften Finanzmittel auf ein Konto der zweiten Partei eingezahlt wurde.
  • Ausführungsbeispiele der Erfindung können von Unternehmen verwendet werden, um Zahlungen an andere Entitäten durchzuführen. Beispielsweise kann ein Käufer Waren von einem Anbieter erwerben. In einem solchen Beispiel kann ein Restaurantunternehmen Taschentücher en gros von einem Taschentuchanbieter erwerben. Der Käufer kann eine Rechnung für die Waren erhalten. Gemäß einem herkömmlichen Vorgang, kann der Käufer die Rechnung mittels eines zu dem Anbieter gesendeten Schecks begleichen. Die Zahlung per Schecks leidet jedoch unter den vorgenannten Beschränkungen. In bestimmten Ausführungsbeispielen der Erfindung kann der Käufer stattdessen eine Anschubzahlung zum Begleichen der Rechnung durchführen. Der Käufer kann eine Zahlungsanweisungsnachricht vorbereiten. Ausführungsbeispiele sehen vor, dass die Zahlungsanweisungsnachricht auf elektronischem Wege zu der Bank des Käufers (ein „Ausgeber”) oder an ein Zahlungsbearbeitungsnetzwerk, wie beispielsweise Visa-NetTM oder BanknetTM gesendet werden kann.
  • Die Zahlungsanweisungsnachricht kann bestimmte Informationen enthalten, wie beispielsweise den Namen des Anbieters, den Zahlungsbetrag, den Zahlungszeitpunkt usw. Das Zahlungsbearbeitungsnetzwerk kann die Information in der Zahlungsanweisungsnachricht verwenden, um die geeignete Entität zu ermitteln, der die Zahlung zuzuführen ist. Beispielsweise können einige Zahlungsanweisungsnachrichten lediglich unvollständige Informationen über den Zahlungsempfänger enthalten, wie beispielsweise lediglich einen Teil des Anbieternamens oder der Anbieteradresse. In dem vorgenannten Beispiel kann der Taschentuchanbieter die „The Napkin Company” sein. Das Restaurantunternehmen kann diesen jedoch nur als „Napkin Co.” bezeichnen. Das Zahlungsbearbeitungsnetzwerk kann dann die im Wesentlichen vollständige Zahlungsempfängerinformation basierend auf der zugeführten Information ermitteln. Dies kann durch einen Fuzzy-Logik-Abgleich erfolgen, wobei die unvollständige Information mit Datenbanken mit Anbieterlisten verglichen wird, und durch weiteren Techniken gemäß den Ausführungsbeispielen der Erfindung, wie im Folgenden näher erläutert wird. Auf diese Weise kann das Zahlungsbearbeitungsnetzwerk feststellen, dass es sich bei dem eigentlichen Zahlungsempfänger um die „The Napkin Company” handelt.
  • Sobald die vollständige Zahlungsempfängerinformation des Anbieters ermittelt wurde, kann das Zahlungsbearbeitungsnetzwerk eine Nachricht generieren, um eine Zahlung von dem Ausgeber (eine „Autorisierungsanforderungsnachricht”) anzufordern. In einigen Ausführungsbeispielen kann die Autorisierungsanforderungsnachricht an ein bestimmtes Standardnachrichtensystem angeglichen werden (d. h. das Zahlungsbearbeitungssystem übersetzt die Zahlungsanweisungsnachricht in ein Industriestandardformat). Bei anderen Ausführungsbeispielen kann die Autorisierungsanforderungsnachricht ein einheitliches Format aufweisen.
  • Sobald der Ausgeber die Autorisierungsanforderung empfängt, kann er die Transaktion genehmigen oder ablehnen. Im Falle einer Ablehnung kann eine Ablehnungsnachricht an den Käufer zurückgesendet werden. Im Falle einer Autorisierung kann das Zahlungsbearbeitungsnetzwerk ein Autorisierungsprotokoll an eine mit dem Anbieter verbundene Bank senden. In exemplarischen Ausführungsbeispielen handelt es sich bei diesem Autorisierungsprotokoll um die erste Mitteilung an diese Bank, dass eine solche Transaktion durch den Käufer initiiert wurde. Der Vorgang des Autorisierens der Transaktion durch den Ausgeber wird als „Autorisation” bezeichnet. Der Autorisationsschritt macht die Bank und den Käufer darauf aufmerksam, dass die Transaktion weitergeführt werden kann. Die Zahlung erfolgt im Allgemeinen nach dem Autorisationsschritt. Die Zahlung erfolgt dann, wenn Finanzmittel von dem Ausgeber an den Anbieter und an die Bank oder eine andere mit dem Anbieter verbundene Institution überwiesen wird.
  • Spezielle Ausführungsbeispiele der Erfindung können unter Bezugnahme auf die 1 bis 5 beschrieben werden.
  • I. Beispielhafte Systeme
  • 1 zeigt ein System 20 gemäß einem Ausführungsbeispiel der Erfindung. Weitere Systeme gemäß den Ausführungsbeispielen der Erfindung können weniger oder mehr Komponenten als die speziell in 1 gezeigten enthalten.
  • 1 zeigt einen Käufer 30, ein Zugangsgerät 34, einen Verkäufer 22, einen Erwerber 24, ein Zahlungsbearbeitungsnetzwerk 26, und einen Ausgeber 28, die miteinander in operativer Kommunikation stehen. Der Erwerber 24 und der Ausgeber 28 können über das Zahlungsbearbeitungsnetzwerk 26 miteinander kommunizieren. Wie oben beschrieben, handelt es sich bei dem „Ausgeber” typischerweise um eine Geschäftsentität (z. B. ein Bank), die Finanzkonten für die Käufer verwaltet und oft ein tragbares Endverbrauchergerät, wie beispielsweise eine Kredit- oder Kundenkarte für den Käufer ausstellt. Bei einem „Verkäufer” handelt es sich typischerweise um ein Entität, die sich mit Transaktionen beschäftigt, wie beispielsweise ein Geschäft, ein Anbieter, ein Händler, eine Person oder ein Dienstanbieter. Das Zugangsgerät 34 wird von den Käufer 30 verwendet, um mit anderen Parteien in dem System zu kommunizieren, und kann einen Computer, ein Telefon oder andere Kommunikationsmittel umfassen.
  • Bei einer typischen Zahlungstransaktion kann ein Käufer (d. h. der „Zahlende”) 30 Waren oder Dienstleistungen von dem Verkäufer 22 ordern. Der Käufer 30 kann dann eine Zahlungsanweisung unter Verwendung eines Zugangsgeräts 34 zum Zwecke des Erwerbs versenden. Das Zugangsgerät 34 kann die Zahlungsanweisung an den Ausgeber 28 oder direkt an das Zahlungsbearbeitungsnetzwerk 26 übertragen. Das Zahlungsbearbeitungsnetzwerk 26 kann ein Identifizierungssystem 49 verwenden, um die Zahlungsanweisung zu analysieren und die Identität des eigentlichen Verkäufers zu ermitteln. Das Zahlungsbearbeitungsnetzwerk kann dann den mit einem Zahlungskonto des Käufers 30 verbundenen Ausgeber 28 kontaktieren, um entweder eine Autorisation oder eine Ablehnung für die Transaktion zu empfangen. Falls die Transaktion genehmigt ist, wird der Erwerber 24 darauf aufmerksam gemacht, und Finanzmittel werden zwischen den eigentlichen Parteien transferiert.
  • Im vorliegenden Kontext handelt es sich bei einem „Erwerber” typischerweise um eine Geschäftsentität, z. B. eine Geschäftsbank, die eine Geschäftsbeziehung mit einem bestimmten Händler oder einer anderen Entität unterhält. Einige Entitäten können sowohl Ausgeber- als auch Erwerberfunktionen innehaben. Ausführungsbeispiele der Erfindung umfassen auch solche Einzelentitäts-Ausgeber-Erwerber.
  • Bei dem Käufer 30 kann es sich um eine individuelle Person oder eine Organisation wie beispielsweise eine Geschäftseinheit handeln, die Waren oder Dienstleistungen erwerben kann.
  • Das Zahlungsbearbeitungsnetzwerk 26 kann einen Servercomputer 44 und auch eine Datenbank 48 aufweisen. Der Servercomputer 44 ist typischerweise ein leistungsfähiger Computer oder eine Gruppe von Computern. Beispielsweise kann es sich bei dem Servercomputer um einen großen Zentralrechner (Mainframe), eine Minicomputergruppe oder eine Gruppe von als Einheit fungierenden Servern handeln. In einem Beispiel kann es sich bei dem Servercomputer um einen mit einem Webserver gekoppelten Datenbankserver handeln. Der Servercomputer kann ein computerlesbares Medium umfassen mit einem Code zum Verarbeiten von Transaktionen gemäß nachfolgender Beschreibung, einem Code zum Empfangen von Nachrichten von Händlern, Erwerbern und Ausgebern, einem Code zum Erzeugen einer einheitlichen Transaktionskennung und Verknüpfen dieser mit spezifischen Transaktionen, einem Code zum Senden von Nachrichten, einem Code zum Identifizieren von Ausgebern und einem Code zum Freigeben und Abwickeln von Transaktion und Rückbuchungsanforderungen im Wesentlichen in Echtzeit.
  • Der Servercomputer 44 kann auch ein computerlesbares Medium umfassen mit einem Code zum Empfangen einer Zahlungsanweisungsnachricht zum Durchführen einer Zahlung unter Verwendung eines mit einem Erwerber verbundenen Kontos, wobei die Zahlungsanweisung zumindest eine unvollständige Zahlungsempfängerinformation enthält und wobei die Zahlungsanweisungsnachricht des Weiteren von einer von dem Zahlungsempfänger verschiedenen Entität erzeugt wird, einem Code zum Überprüfen der Zahlungsanweisungsnachricht; einem Code zum Ermitteln einer im Wesentlichen vollständigen Zahlungsempfängerinformation; und einem Code zum Senden einer Autorisierungsanforderung zu dem Ausgeber, wobei die Autorisierungsanforderung eine Anschubkennung enthält.
  • Der Servercomputer 44 kann auch einen Code umfassen zum Empfangen einer Zahlungsanweisungsnachricht, einen Code zum Lesen der Zahlungsanweisungsnachricht und zum Ermitteln, ob die Zahlungsanweisungsnachricht eine Information zum Bestimmen eines Zahlungsempfängers enthält, und einen Code zum Verwenden eines Fuzzy-Logik-Abgleichs zum Vergleichen der Information in der Zahlungsanweisungsnachricht mit mehreren Datenspeichern, um einen mit der Zahlungsanweisung verbundenen Zahlungsempfänger im Wesentlichen zu identifizieren, wobei die mehreren Datenspeicher eine Vielzahl von Kennungen für zumindest einen Händler enthalten, wobei die Vielzahl von Kennungen eine Kennung für einen Namen, eine Kennung für eine Telefonnummer und eine Kennung für eine Adresse enthalten.
  • Das Zahlungsbearbeitungsnetzwerk 26 kann ein Zahlungsbearbeitungsnetzwerk wie beispielsweise VisaNetTM oder BanknetTM umfassen oder verwenden. Das Zahlungsbearbeitungsnetzwerk 26 und ein beliebiges Kommunikationsnetzwerk, das mit dem Zahlungsbearbeitungsnetzwerk 26 kommuniziert, können jedes andere beliebige geeignete drahtgebundene oder drahtlose Netzwerk verwenden, auch das Internet. Das Zahlungsbearbeitungsnetzwerk 26 kann ausgestaltet sein zum Verarbeiten gewöhnlicher Kunden- oder Kreditkartentransaktionen, nebst den hier erwähnten Anschubzahlungstransaktionen.
  • Das Identifizierungssystem 49 kann verwendet werden zum Bestimmen der Identität des Zahlungsempfängers einer Transaktion, selbst wenn nur unvollständige Transaktionsinformationen vorhanden sind, wie später im Einzelnen erläutert wird. Das Identifizierungssystem 49 kann einen oder mehrerer Servercomputer, eine oder mehrere Datenbanken oder eine geeignete Kombination aus diesen umfassen. In bestimmten Ausführungsbeispielen kann das Identifizierungssystem 49 ein Teil eines Zahlungsbearbeitungsnetzwerks 26 sein, so dass Teile des Zahlungsbearbeitungsnetzwerks 26 einige oder alle Funktionen des Identifizierungssystems 49 übernehmen können. In alternativen Ausführungsbeispielen kann das Identifizierungssystem ein getrenntes Netzwerk oder Computersystem sein, das mit dem Zahlungsbearbeitungsnetzwerk 26 kommuniziert. In bestimmten Implementierungen kann das Identifizierungssystem 49 mehrere Datenbanken mit auf verschiedenen unabhängigen und miteinander kommunizierenden Computersystem befindlichen Informationen umfassen.
  • Ausführungsbeispiele des Zahlungsbearbeitungsnetzwerks 26 können auch enthalten oder getrennt kommunizieren mit einem zentralen Datenknoten, nicht gezeigt, der mehrere Zahlungsmethoden („MMOP”) bewerkstelligen kann. Der zentrale Datenknoten kann eine Profilverwaltung, eine Dateiverwaltung, eine Nachrichtenübersetzung durchführen, Geschäftsregeln speichern und ausführen und mit verschiedenen anderen Netzwerken Verbindungen herstellen. Beispielhafte zentrale Datenknoten sind beschrieben in der US Patentanmeldung 11/929,033 mit dem Titel „System and Method for Processing Multiple Methods of Payment”, die hier in Gänze und für alle Zwecke als Bezugsdokument aufgenommen wird. In bestimmten Ausführungsbeispielen kann das Kennungs-system 49 einen solchen zentralen Datenknoten umfassen.
  • Obwohl das Zahlungsbearbeitungsnetzwerk 26 und das Identifizierungssystem 49 als operativer Bestandteil zwischen einem Erwerber 24 und einem Ausgeber 28 dargestellt sind, müssen sie das nicht in anderen Ausführungsbeispielen der Erfindung. Jede oder beide können eine beliebige geeignete Kombination von Computervorrichtungen enthalten, die die in dieser Anmeldung beschriebene Bearbeitung vereinfachen können.
  • Der Käufer 30 kann ein Zugangsgerät 34 zum Kommunizieren mit dem Ausgeber 28 oder dem Zahlungsverarbeitungsnetzwerk 26 verwenden. Das Zugangsgerät gemäß den Ausführungsbeispielen der Erfindung kann jede geeignete Form aufweisen. Beispiele für Zugangsgeräte enthalten Zahlungsortsgeräte (Point of Sale, POS), Mobiltelefone, PDAs, Personal Computer (PCs), Tablet-PCs, für Handgerät spezialisierte Lesevorrichtungen, Set-Top-Boxen, elektronische Registrierkassen (Electronic Cash Registers, ECRs), Geldautomaten (Automated Teller Machines, ATMs), virtuelle Registrierkassen (Virtual Cash Registers, VCRs), Kioske, Sicherheitssysteme, Zugangssysteme und dergleichen. Das Zugangsgerät kann eine praktische Schnittstelle wie beispielsweise ein Webbrowser auf einem Computer umfassen, der über das Internet kommuniziert, und in bestimmten Ausführungsbeispielen kann der Käufer 30 ein tragbares Endverbrauchergerät besitzen, wie beispielsweise eine Zahlungskarte, die mit von dem Ausgeber 28 verwalteten Konten verknüpft ist. Gemäß einem Aspekt kann die Zahlungskarte mit dem Zugangsgerät 34 zusammenwirken, um eine Zahlungsanweisungsnachricht zum Absenden zu erstellen. In anderen Aspekten kann die Zahlungskarte die relevante Zahlungskontoinformation enthalten. Der Käufer kann die relevante Zahlungskontoinformation, die auf der Zahlungskarte enthalten ist, dem Zugangsgerät 34 oder direkt entweder dem Ausgeber 28 oder dem Zahlungsverarbeitungsnetzwerk 26 zuführen.
  • Das Zugangsgerät 34 kann einen Prozessor und ein computerlesbares Medium umfassen, wobei das computerlesbare Medium einen Code umfasst zum Erhalten einer mit einem Endverbraucher verknüpften Kontonummer; einen Code zum Senden einer Autorisierungsanforderungsnachricht mit der Kontonummer und einem Betrag für die Transaktion an ein Zahlungsbearbeitungsnetzwerk; und einen Code zum Empfangen einer Autorisierungsantwortnachricht mit einer eindeutigen Transaktionskennung für die Transaktion.
  • Zur Vereinfachung der Illustration sind ein Käufer 30, ein Verkäufer 20, ein Zugangsgerät 34, ein Erwerber 24 und ein Ausgeber 28 gezeigt. Es ist jedoch ersichtlich, dass in Ausführungsbeispielen der Erfindung mehrere Endverbraucher, tragbare Endverbrauchergeräte, Händler, Zugangsgeräte, Erwerber, Ausgeber, und auch Servercomputer, Datenbanken, Konten, usw. vorhanden sein können.
  • II. Beispielhafte Prozesse
  • 2 zeigt ein Flussdiagramm eines beispielhaften Transaktionsprozesses 100, der mittels des Systems 20 gemäß 1 ausgeführt wird. In bestimmen Ausführungsbeispielen können die Transaktionsprozesse in Abhängigkeit der Natur der Transaktion und der spezifischen involvierten Parteien voneinander abweichen.
  • Im Schritt 101 wird ein Käufer eine Transaktion initiieren. Wie vorstehend erläutert kann die Transaktion eine Finanztransaktion sein, bei der der Käufer/Zahlende einen Händler/Zahlungsempfänger für Waren oder Dienstleistungen bezahlt. Diese Bezahlung kann eine Rechnungsbegleichung in Antwort auf eine Rechnung, eine Kartentransaktion für einen Erwerb, oder eine andere geeignete Transaktion sein. In bestimmtem Ausführungsbeispielen können mehrere Zahlungen an einen bestimmten Händler zusammengefasst und in einer Transaktion bezahlt werden. Zum Initiieren einer Transaktion bereitet der Käufer eine Zahlungsanweisungsnachricht oder eine Zahlungsdatei vor. Diese Zahlungsanweisungsnachricht wird die zur Bearbeitung einer Transaktion minimal erforderliche Information enthalten. In exemplarischen Ausführungsbeispielen wird die Zahlungsanweisungsnachricht zumindest die Information über die zu bezahlende Person (Zahlungsempfängerinformation) und über den Zahlungsbetrag für die Transaktion („Transaktionsbetrag”) enthalten. In einigen Ausführungsbeispielen kann die Zahlungsanweisungsnachricht andere Informationen wie beispielsweise Zahlungszeitpunkt, eine zugehörige Rechnungsnummer, eine zugehörige Bestellnummer, die Währung, in der die Transaktion durchgeführt werden wird, den Namen des Ausgebers und eine Kennung für das Käuferbankkonto mit dem in der Transaktion verwendeten Ausgeber, usw.
  • In exemplarischen Ausführungsbeispielen wird die Zahlungsanweisungsnachricht eine unvollständige Zahlungsempfängerinformation enthalten. Zahlungsanweisungsnachrichten werden Daten enthalten, die zur Kennung des Zahlungsempfängers verwendet werden. In den hier verwendeten exemplarischen Ausführungsbeispielen kann der Begriff „unvollständige Zahlungsinformation” auf Zahlungsempfänger bezogene Daten hinweisen, in denen bestimmte Informationen fehlen, sodass die Daten den Zahlungsempfänger nicht mit hundertprozentiger Genauigkeit identifizieren können. Unvollständige Informationen über den Zahlungsempfänger können jede oder alle Information bestehend aus dem Namen des Zahlungsempfängers, einer Telefonnummer, einer E-Mail- oder Webseiteninformation, einer Adresse, und anderen Kennungen (wie beispielsweise eine von einer Regierung bereitgestellte Steuerkennung, oder eine spezifische durch eine Bank oder ein Zahlungsbearbeitungsnetzwerk zugewiesene Kennung). Bei der unvollständigen Zahlungsempfängerinformation kann jedoch eine Zahlungsinformation fehlen. Die Information kann einen unvollständigen Zahlungsempfängernamen oder eine alte oder unrichtige Adresse enthalten. Die unvollständige Zahlungsinformation kann auch eine unklare Information enthalten wie beispielsweise einen Namen oder eine Adresse eines Zahlungsempfängers, die mit mehreren anderen Organisationen geteilt wird. Sobald die Zahlungsanweisungsnachricht empfangen wird, wird das System 20 gemäß 1 die Zahlungsanweisungsnachricht analysieren, um eine im Wesentlichen vollständige Zahlungsempfängerinformation zu ermitteln, gemäß den Schritten 104 bis 106. In exemplarischen Ausführungsbeispielen kann die „im Wesentlichen vollständige Zahlungsempfängerinformation” eine Information über den Zahlungsempfänger enthalten, die eine Zahlung an den korrekten Zahlungsempfänger ermöglicht. Falls die unvollständige Zahlungsempfängerinformation beispielsweise einen unvollständigen Zahlungsempfängernamen und eine falsche Adresse enthält, so werden Ausführungsbeispiele des Zahlungsbearbeitungssystems 20 den vollständigen Zahlungsempfängernamen und die korrekte Adresse ermitteln. In bestimmten Ausführungsbeispielen kann die im Wesentlichen vollständige Zahlungsempfängerinformation eine Genauigkeit innerhalb einer vorbestimmten Schwelle aufweisen. Beispielsweise kann die im Wesentlichen vollständige Zahlungsempfängerinformation die Information über einen Zahlungsempfänger mit einer 95%igen Genauigkeit umfassen. Andere Ausführungsbeispiele behandeln höhere oder niedrigere vorbestimmte Genauigkeiten, wie beispielsweise 70%, 85% oder 99%. Im Vergleich dazu kann die Zahlungsempfängerinformation bei einer durch einen Zahlungsempfänger initiierten Transaktion (wie beispielsweise eine Standardkreditkartentransaktion, bei der eine Kreditkarte bei dem Zahlungsempfänger/Händler „durchgezogen” wird) eine Genauigkeit von 100% erreichen. Dies liegt daran, dass die Zahlungsempfängerinformation bei Standardtransaktionen durch den Zahlungsempfänger selbst bereitgestellt wird. Somit handelt es sich gemäß einem Aspekt bei der im Wesentlichen vollständigen Zahlungsempfängerinformation um eine Information über den Zahlungsempfänger, die genau genug ist, um eine Transaktion abzuschließen.
  • Der Käufer kann eine Transaktion im Schritt 101 auf eine beliebige Zahl ausreichender Wege initiieren. Ausführungsbeispiele behandeln die Erstellung und Übertragung der Zahlungsanweisungsnachricht durch: proprietäre Software, und danach eine Weitergabe an das Zahlungsverarbeitungsnetzwerk durch ein beliebiges Übertragungssystem, wie beispielsweise das Dateitransferprotokoll (File Transfer Protocol, FTP) oder das abgesicherte FTP, E-Mail, usw.; durch geschriebene oder mündliche Anweisungen per Telefon, Post oder persönlich; durch einen mit einer sicheren Website verbundenen Webbrowser; durch Händlerdirektaustauschsysteme (merchant direct exchange, MDEX); oder andere geeignete Verfahren. Exemplarische Ausführungsbeispiele behandeln des Weiteren die Erzeugung der Zahlungsanweisungsnachrichten durch Eingeben der erforderlichen Information in durch allgemein verfügbare Softwareprogramme wie beispielsweise Microsoft Word oder Excel erzeugte Dateien. In bestimmten Ausführungsbeispielen wird die Zahlungsanweisungsnachricht direkt zu dem Zahlungsbearbeitungsnetzwerk übertragen. In anderen Ausführungsbeispielen kommuniziert der Käufer eine Zahlungsanforderung an die Käuferbank (den Ausgeber), die dann die Zahlungsanweisungsnachricht an das Zahlungsbearbeitungsnetzwerk überträgt.
  • Sobald die Zahlungsanweisungsnachricht an das Zahlungsbearbeitungsnetzwerk gesendet wurde, wird der Datei im Schritt 102 eine Anschubkennung hinzugefügt. Diese Anschubkennung kennzeichnet die Transaktion als eine Anschubtransaktion. In exemplarischen Ausführungsbeispielen werden Anschubtransaktionen eine existierende Zahlungstransaktionsinfrastruktur nutzen. Die Anschubkennung ermöglicht eine korrekte Erkennung und Bearbeitung der Anschubtransaktion durch die existierenden Systeme im Unterschied zu Standardtransaktionen, und ermöglicht es dem System, über die ggf. erforderliche Durchführung der speziellen Anschubverarbeitung bei der Transaktion in Kenntnis gesetzt zu werden. In den Schritten 103a und 103b wird die Zahlungsanweisungsnachricht analysiert, um festzustellen, ob die Zahlungsanweisung vollständig ist. In speziellen Ausführungsbeispielen kann die Zahlungsanweisung vollständig sein, wenn alle erforderlichen Zahlungsfelder (wie beispielsweise unvollständiger Zahlungsempfängername, Zahlungsbetrag, usw.) vorhanden sind und alle anderen Erfordernisse für die Zahlungsanweisungsnachricht erfüllt sind, was durch das Zahlungsbearbeitungsnetzwerk festgestellt wird. Falls die Zahlungsanweisungsnachricht in Schritt 103a oder 103b als unvollständig bestimmt wird, so wird eine Mitteilungsnachricht an den Käufer gesendet, um weitere den Zahlungsempfänger identifizierende Informationen abzufragen und eine vollständige Zahlungsanweisungsnachricht zu erzeugen. Weitere Informationen zum Identifizieren des Zahlungsempfängers können solche Informationen enthalten, die auf den Zahlungsempfänger bezogen sind und zuvor nicht in der Zahlungsanweisungsnachricht vorhanden waren, wie beispielsweise Telefonnummern, Adressen oder alternative Schreibweisen von zuvor bereitgestellter Information.
  • Falls die Zahlungsanweisungsnachricht in den Schritten 103a und 103b als vollständig bestimmt wurde, so wird die Zahlungsnachricht in den Schritten 104 bis 106 weiter validiert und bearbeitet. Die Schritte 104 bis 106 können teilweise oder vollständig durch das Zahlungsbearbeitungsnetzwerk 26 gemäß 1 erledigt werden. In bestimmten Ausführungsbeispielen können Teile oder die Gesamtheit der Schritte 104 bis 106 durch das Identifizierungssystem 49 erledigt werden. Im Schritt 104 wird die Zahlungsanweisungsnachricht analysiert, um die unvollständige Zahlungsempfängerinformation zu extrahieren. Wie vorstehend beschrieben, wird die unvollständige Zahlungsempfängerinformation in eine vollständige Zahlungsempfängerinformation übersetzt. Falls die vollständige Zahlungsempfängerinformation bereits bereitgestellt wurde, wird die Zahlungsanweisungsnachricht zum Schritt 105 bewegt. In exemplarischen Ausführungsbeispielen enthält die Zahlungsanweisungsnachricht lediglich eine unvollständige Zahlungsempfängerinformation, und ein exakter Abgleich mit dem eigentlichen Zahlungsempfänger kann nicht prima facie erfolgen. Dies kann beispielsweise auftreten, wenn der Zahlungsempfängername unrichtig geschrieben ist oder eine Information fehlt („Payee Corp.” wird bereitgestellt, wobei aber „The Payee Corp.” der volle Name ist). Es können auch verschiedene Abkürzungen in der unvollständigen Information über den Zahlungsempfänger vorhanden sein, wie beispielsweise „Corp.” oder „Co” für „Corporation” oder „rd” für „Road”. Eine unvollständige Information kann auch auftreten, wenn mehrere Zahlungsempfänger denselben Namen besitzen. Beispielsweise kann ein Auftragnehmer Lieferungen von einem Home-Depot-Laden erwerben. Es gibt hunderte von Home-Depot-Läden in dem Land, und die Zahlungsanweisungsnachricht kann gegebenenfalls nicht spezifizieren, an welchen bestimmten Laden die Zahlung erfolgen soll. Des Weiteren können andere Bestandteile der Zahlungsempfängerinformation, die nicht mit dem Namen verknüpft sind, fehlende oder inkorrekte Informationen in der in der Zahlungsanweisungsnachricht bereitgestellten unvollständigen Information über den Zahlungsempfänger enthalten. Beispielsweise kann ein Zahlungsempfänger seine Sitz in Albuquerque, New Mexico haben. „Albuquerque” kann jedoch in der unvollständigen Information über den Zahlungsempfänger falsch geschrieben sein, wie beispielsweise „Alberquerque” oder es kann falsch identifiziert werden als in dem Staat New Jersey gelegen. Es können auch Abkürzungen in der Adresse vorhanden sein, wie oben beschrieben. In einigen Beispielen kann die einzige bereitgestellte Information die Telefonnummer des Zahlungsempfängers sein. Für jedes in der Zahlungsanweisungsnachricht durch den Käufer bereitgestellte Feld können Unstimmigkeiten, fehlende oder unrichtige Informationen vorhanden sein.
  • Der Vorgang des Abgleichs der Information im Schritt 104 kann ein wünschenswerter Teil der Ausführungsbeispiele der Erfindung sein. Ausführungsbeispiele des Identifizierungssystems 49 können die Gesamtheit der gegebenen Information betrachten. Falls der bereitgestellte Name somit nicht mit der Telefonnummer übereinstimmt, können beide mit der Adresse verglichen werden. In einigen Ausführungsbeispielen kann ein Abgleich als durchführbar betrachtet werden, falls zwei dieser drei Datenelemente miteinander übereinstimmen und das Dritte innerhalb einer vorbestimmten Abweichung liegt, und eine im Wesentlichen vollständige Zahlungsempfängerinformation wurde bestimmt. Beispielsweise kann die nachfolgende Information in Datenfeldern einer Zahlungsanweisungsnachricht enthalten sein:
    Name des Zahlungsempfängers: Payee Corp.
    Telefonnummer des Zahlungsempfängers: (800) 555-5555
    Adresse des Zahlungsempfängers: 15 Lincoln Rd.
    Arlington, VA 22202
  • Diese Information kann eine unvollständige Zahlungsempfängerinformation umfassen. Im Schritt 104 können Systeme, wie beispielsweise die in Bezug auf 1 beschriebenen Computersysteme, die unvollständige Zahlungsempfängerinformation aus einer Zahlungsanweisungsnachricht extrahieren und analysieren. Die Datenfelder können mit verschiedenen Datenbanken mit durch das Identifizierungssystem 49 gespeicherten oder zugänglichen Entitäten verglichen werden. Diese Datenbanken können Listen mit Zahlungsempfängernamen enthalten. In bestimmten Ausführungsbeispielen können eine oder mehrere dieser Datenbanken Listen mit solchen Zahlungsempfängern enthalten, die Zahlungen über ein Zahlungsbearbeitungsnetzwerk akzeptieren. Zahlungsempfängerinformation, die in den Datenbanken zusammengestellt ist, kann aus mit dem Zahlungsempfänger von verschiedenen Zahlenden durchgeführten Transaktionen abgeleitet werden. Die Transaktion können Kundenkartentransaktionen, Kreditkartentransaktionen, gespeicherte Werttransaktionen, usw. enthalten. Nach einem Vergleich mit den verschiedenen Datenbanken kann das Identifizierungssystem festellen, dass keine „Payee Corp.” unter der gegebenen Adresse gelistet ist. Eine Entität mit dem Namen „Payee Services International” ist unter der gegebenen Adresse gelistet und hat die angegebene Telefonnummer. Des Weiteren wird festgestellt, dass „Payee Corporation” eine hundertprozentige Tochtergesellschaft der „Payee Services International” ist. Somit wird die im Wesentlichen vollständige Zahlungsempfängerinformation aus der „Payee Corporation” mit der bereitgestellten Telefon- und Adressinformation bestehen.
  • In einigen Ausführungsbeispielen kann eine Datenbank mit unvollständiger und zusätzlicher Zahlungsempfängerinformation aufgebaut werden, sodass zukünftige Zahlungsnachrichten mit höherer Genauigkeit und Geschwindigkeit bestimmt werden können. Für verschiedene dritte Parteien ist es auch möglich, die Datenbank nach solchen unvollständigen und zusätzlichen Zahlungsempfängerinformationen zu durchsuchen, sodass eine im Wesentlichen vollständige Zahlungsempfängerinformation ermittel werden kann. Eine Gebühr kann durch die die Daten verwaltende Partei gegenüber der die Daten abfragenden Partei bemessen werden.
  • In anderen Beispielen könnten Tippfehler oder andere unrichtige Informationen vorhanden sein. Die Adresse kann als „13 Linkin Lane” vorhanden sein oder die Telefonnummer kann als „(888) 555-5555” vorhanden sein. Das Identifizierungssystem 49 kann die unvollständige Zahlungsempfängerinformation mit verschiedenen Datenbanken gemäß vorstehender Beschreibung vergleichen. In exemplarischen Ausführungsbeispielen kann das Identifizierungssystem 49 auch eine Fuzzy-Logik bei der Ermittlung der im Wesentlichen vollständigen Zahlungsempfängerinformation verwenden. Das Identifizierungssystem 49 kann einen Fuzzy-Logik-Abgleich zum Vergleichen der unvollständigen Zahlungsempfängerinformation mit einzelnen oder mehreren Datenspeichern verwenden, die Listen mit im Wesentlichen vollständiger Zahlungsempfängerinformation enthalten. Fuzzy-Logik umfasst Techniken zur Schlussfolgerung bei Ungewissheit und ist in modernen industriellen und Endverbraucherwarensteuersystemen und auch in Berichtssystemen weit verbreitet. Die Fuzzy-Logik kann im Allgemeinen als eine Obermenge der Booleschen Logik betrachtet werden, wobei die Booleschen Wahrheitswerte durch dazwischen liegende Wahrheitsgrade ersetzt werden.
  • Während die Boolesche Logik lediglich Wahrheitswerte von Null und Eins zulässt, sind somit bei der Fuzzy-Logik Wahrheitswerte mit beliebigen Realzahlen zwischen Null und Eins möglich. In bestimmten Implementierungen kann das Identifizierungssystem 49 mit Datenbanken und Abgleichsystemen dritter Parteien in Verbindung stehen oder andernfalls darauf Zugriff haben, wie beispielsweise Dun & Bradstreet-Produkte, die D&W MarketMatch enthalten. Das Identifizierungssystem 49 kann auch andere geeignete Prozesse wie beispielsweise ein Hidden-Markov-Modell (HMM), ein dynamisches Programmierungsmodel, ein neuronales Netzwerk, ein Vorlagenabgleicher (Template Matcher), usw. enthalten. Diese Datenbanken, Techniken und Modelle können einzeln oder in Kombination verwendet werden.
  • Das Identifizierungssystem 49 kann einen Fuzzy-Logik-Abgleich oder andere geeignete Systeme verwenden. In dem vorgenannten Beispiel kann das Identifizierungssystem eine Fuzzy-Logik verwenden, um die in der Zahlungsanweisungsnachricht vorhandene Telefonnummer „(888) 555-5555” mit verschiedenen Datenbanken zu vergleichen. Das Identifizierungssystem kann mit 96%iger Genauigkeit feststellen, dass die im Wesentlichen vollständige Zahlungsempfängerinformation die Telefonnummer „(800) 555-5555” umfasst. Die Genauigkeit kann mit einer vorbestimmten Genauigkeitsschwelle verglichen werden. Diese Schwelle kann durch das Zahlungsbearbeitungsnetzwerk, den Zahlenden, den Ausgeber, den Erwerber, oder andere mit Anschubtransaktionen gemäß den hier offenbarten Ausführungsbeispielen beschäftigte Parteien eingestellt werden. Das Identifizierungssystem 49 kann eine vorbestimmte Genauigkeitsschwelle von 95% aufweisen. In dem vorgenannten Beispiel weist die im Wesentlichen vollständige Zahlungsempfängerinformation eine ausreichende Genauigkeit auf und die Zahlungsbearbeitung wird im Schritt 105 fortgeführt. In anderen Implementierungen kann das Identifizierungssystem eine vorbestimmte Schwelle von 99% aufweisen. In dem vorgenannten Beispiel weist die im Wesentlichen vollständige Zahlungsempfängerinformation keine ausreichende Genauigkeit auf. Falls kein Abgleich mit höherer Genauigkeit erfolgen kann, wird die Transaktionsbearbeitung im Schritt 105 gestoppt und eine Nachricht wird an den Käufer gesendet, dass die Anschubzahlung nicht ohne weitere den Zahlungsempfänger identifizierende Information erfolgen kann.
  • Jedes in der unvollständigen Zahlungsempfängerinformation bereitgestellte Datenfeld kann mit geeigneten Datenbanken verglichen und durch einen Fuzzy-Logik-Abgleich analysiert werden, wie vorstehend in Bezug auf Schritt 104 beschrieben wurde. Verschiedene Datenfelder können während der Analyse gesichtet werden. Beispielsweise kann der in der unvollständigen Zahlungsempfängerinformation vorhandene Name ein höheres Gewicht erhalten als die E-Mail Adresse, oder umgekehrt. Sobald alle Felder bearbeitet wurden, individuell und in Kombination, wird eine im Wesentlichen vollständige Zahlungsempfängerinformation mit der größtmöglichen Genauigkeit ermittelt. Dann wird im Schritt 105 jede weitere Information ermittelt, die bei der Ausführung einer Transaktion erforderlich sein könnte, und an die Zahlungsanweisungsnachricht angehängt. Diese Information kann eine Zahlungsweiterleitungsinformation, Netzwerkkennungen usw. enthalten. Das Zahlungsbearbeitungssystem kann auch beliebige Risikobeurteilungsprozesse für die Transaktion einsetzten, wie sie aus dem Stand der Technik bekannt sind. Im Schritt 106 wird die Zahlungsanweisungsnachricht übersetzt und gemäß dem Schritt 107 verarbeitet, falls die Genauigkeit der im Wesentlichen vollständigen Zahlungsempfängerinformation größer ist als eine vorbestimmte Schwelle. In bestimmten Ausführungsbeispielen muss die Genauigkeit größer oder gleich der vorbestimmten Schwelle sein, während in anderen Ausführungsbeispielen die Genauigkeit größer als die vorbestimmte Schwelle sein muss.
  • Bei der ersten Anschubzahlung gemäß den hier offenbarten Ausführungsbeispielen durch einen Käufer kann der Abgleich der unvollständigen Zahlungsempfängerinformation mit der im Wesentlichen vollständigen Zahlungsempfängerinformation in der vorstehend beschriebenen Weise erforderlich sein. Sobald eine im Wesentlichen vollständige Zahlungsempfängerinformation ermittelt wurde, kann das Identifizierungssystem 49 dem Zahlungsempfänger eine eindeutige Zahlungsempfängerkennung, oder „Händlerkennung”, zuweisen, die in künftigen Anschubzahlungen zu verwenden ist. Das Identifizierungssystem 49 kann auch dem Käufer eine Käuferkennung zuweisen. Diese Käuferkennung kann zum schnellen Identifizieren derjenigen Person verwendet werden, die eine Anschubzahlung durchführt und des verwendeten Finanzkontos. Die Händlerkennung und die Käuferkennung können zu dem Käufer gesendet werden. Der Käufer kann dann diese von dem Zahlungsbearbeitungsnetzwerk erzeugten Kennungen in künftigen Anschubzahlungen verwenden, um eine erhöhte Genauigkeit und schnellere Transaktionen zu erzielen.
  • Das Identifizierungssystem 49 kann auch Datenbanken erstellen oder modifizieren, die die Händlerkennungen und die Käuferkennungen mit einer anderen gegebenen Information korrelieren. Diese kann Kennungen enthalten, die ein Käufer intern einem Veräußerer zuweist, und umgekehrt. Beispielsweise kann ein Unternehmen X des öfteren Computerzubehör von einem Veräußerer Y erwerben. Das Unternehmen X kann dem Veräußerer Y die ID „VY123” zuweisen und der Veräußerer Y kann dem Unternehmen X die ID „CX-AB5” zuweisen. Falls eine dieser Kennungen in der Zahlungsanweisungsnachricht vorhanden ist, die die Transaktion initiiert (oder dem Identifizierungssystem 49 auf andere Weise bekannt ist), kann das Identifizierungssystem 49 die Kennungen in einer Datenbank speichern, wie beispielsweise die Datenbank 48. Die Datenbank kann die Kennungen auf eine andere Kennungsinformation abbilden. Beispielsweise können die Kennungen „VY123” und „CX-AB5” jeweils auf eine durch das Zahlungsbearbeitungsnetzwerk zugewiesene eindeutige Kennung abgebildet werden, und auch auf den Namen und die Adresse der jeweiligen Unternehmen. Somit kann eine 100%ige Genauigkeit bei der Bestimmung der im Wesentlichen vollständigen Zahlungsempfängerinformation erzielt werden, wenn das Unternehmen X eine Anschubzahlung initiiert, um eine Zahlung an den Veräußerer Y unter Verwendung der Kennung VY123 durchzuführen.
  • Bezugnehmend auf Schritt 107 wird die Zahlungsanweisungsnachricht (die die zuvor bestimmte im Wesentlichen vollständige Zahlungsinformation enthält) in das Format einer Autorisierungsanforderung übersetzt. Diese Autorisierungsanforderungsnachricht kann das von einer herkömmlichen Kreditkartenverarbeitungsnachricht verwendete Format aufweisen. In bestimmten Implementierungen wird die Zahlungsanweisungsnachricht in eine BASE-1-Autorisierungsanforderungsnachricht gemäß dem Stand der Technik übersetzt. In herkömmlichen Transaktionen werden Autorisierungsanforderungsnachrichten durch den Zahlungsempfänger/Verkäufer erzeugt. In bestimmten Ausführungsbeispielen erstellt jedoch das Zahlungsbearbeitungsnetzwerk die Autorisierungsanforderungsnachricht im Schritt 107 unter Verwendung einer von dem Käufer bereitgestellten und durch das Netzwerk bearbeiteten Information. Die im Schritt 107 erstellte übersetzte Autorisierungsanforderungsnachricht kann alle zum Fortsetzen der Transaktion erforderlichen Informationen enthalten, inklusive der im Wesentlichen vollständigen Zahlungsempfängerinformation, des Transaktionsbetrags und des von dem Käufer zur Durchführung der Zahlung verwendeten Kontos. Die Autorisierungsanforderungsnachricht kann nahezu identisch mit einer durch herkömmliche Kreditkarten erzeugten Nachricht sein. In exemplarischen Ausführungsbeispielen kann die Autorisierungsanforderungsnachricht mit herkömmlichen übereinstimmen, mit der Ausnahme dass die im Schritt 107 erstellte Autorisierungsanforderungsnachricht die im Schritt 102 erzeugte Anschubkennung enthält.
  • Die Autorisierungsanforderungsnachricht kann dann im Schritt 108 durch das Zahlungsbearbeitungsnetzwerk an den Ausgeber gesendet werden. Der Ausgeber kann eine Bank sein, die ein mit dem Käufer verbundenes Bankkonto verwaltet. Dieses Bankkonto kann die bei der Zahlungstransaktion verwendeten Finanzmittel enthalten. In bestimmten Ausführungsbeispielen hat der Käufer die Transaktion durch den Ausgeber initiiert, der dann das Zahlungsbearbeitungsnetzwerk kontaktiert. In anderen Ausführungsbeispielen kann der Käufer den Ausgeber in der Zahlungsanweisungsnachricht spezifizieren. Im Schritt 109 ermittelt der Ausgeber, ob die Transaktion autorisiert (d. h. genehmigt) ist. Der Ausgeber kann bestimmte Risikosysteme und andere Autorisierungsprozesse gemäß dem Stand der Technik ausführen. Der Ausgeber kann die Transaktion autorisieren, falls ausreichend Guthaben und/oder Finanzmittel auf dem Käuferkonto vorhanden sind. Der Ausgeber kann die Transaktion nicht autorisieren, falls nicht ausreichend Guthaben oder Finanzmittel vorhanden sind. Des Weiteren kann der Ausgeber bestimmte spezialisierte Prozesse für Anschubzahlungsanforderungen (aufgrund der Anschubkennung in der Nachricht) anwenden, wie beispielsweise spezielle Belohnungen oder Nachlässe.
  • Falls die Transaktion abgelehnt wird, wird die Transaktion beendet und eine Ablehnungsnachricht wird zu dem Zahlungsbearbeitungsnetzwerk gesendet, das die Nachricht an den Käufer weiterleitet. Falls die Transaktion autorisiert wird, wird der Ausgeber das Zahlungsbearbeitungsnetzwerk davon in Kenntnis gesetzt. Eine Autorisierungsantwortnachricht mit einem Autorisierungsprotokoll wird in den Schritten 110a und 110b erstellt. Dieses Autorisierungsprotokoll kann durch das Zahlungsbearbeitungsnetzwerk oder durch den Ausgeber erstellt und an das Zahlungsbearbeitungsnetzwerk weitergeleitet werden. Das Autorisierungsprotokoll kann Berichts- und Abwicklungsdaten gemäß dem Stand der Technik enthalten, wie beispielsweise eine Berichtssystemdatei und eine Abwicklungsdatei. Das Autorisierungsprotokoll kann auch um weitere Informationen für Anschubtransaktionen erweitert werden, wie beispielsweise das Aufnehmen der Anschubkennung. Das Autorisierungsprotokoll kann auch eine Information über die zugrundeliegende Transaktion enthalten, wie beispielsweise die zugehörige Rechnungsnummer, die zugehörige Bestellnummer, und den Namen des Käufers. In bestimmten Implementierungen kann das Autorisierungsprotokoll kundenspezifisch ausgestaltet sein, um mit den Erfordernissen spezifischer Erwerber übereinzustimmen. Die Autorisierungsantwortnachricht (mit dem Autorisierungsprotokoll) wird im Schritt 111 durch den Erwerber empfangen. In exemplarischen Ausführungsbeispielen handelt es sich bei der Autorisierungsantwortnachricht um die erste Mitteilung, die der Erwerber hinsichtlich der Transaktion erhält. Die Autorisierungsantwortnachricht kann als Hinweis für den Erwerber fungieren, dass eine Zahlung von dem Käufer an den Zahlungsempfänger erfolgen wird. Somit kann der Erwerber in einigen Ausführungsbeispielen erst nach der Autorisierung einer Transaktion durch den Ausgeber kontaktiert werden (d. h. die Autorisierungsanforderungsnachricht wird an den Ausgeber gesendet, bevor eine Kommunikation mit dem Erwerber initiiert wurde). Dadurch kann die Transaktionsgeschwindigkeit und Effizienz erhöht werden, da der Erwerber in wenige Schritte der Transaktion involviert ist, und keine Transaktionen bearbeitet, die letztlich ohne Autorisierung beendet werden.
  • Nachdem die Transaktion genehmigt ist, findet ein normaler Freigabe- und Abwicklungsprozess statt. Der Erwerber wird eine Abstimmungsnachricht (d. h. einen Abstimmungsbericht) hinsichtlich des Finanzmittelflusses zu dem Zahlungsbearbeitungsnetzwerk senden, dass die Nachricht dann an den Ausgeber weiterleitet. Diese Abstimmungsnachricht kann eine Information über den Zahlenden (wie beispielsweise den Käufername), die Rechnungsnummer, die Bestellnummer enthalten. Der Erwerber wird die Abstimmungsnachricht im Schritt 113 auch an den Händler senden. Im Schritt 112 werden Finanzmittel von dem Finanzkonto des Käufers bei dem Ausgeber an den Erwerber überwiesen. In bestimmten Ausführungsbeispielen kann der Ausgeber auf die Transaktion bezogene Finanzmittel an das Zahlungsbearbeitungsnetzwerk senden. Das Zahlungsbearbeitungsnetzwerk kann dann die Geldmittel an den Zahlungsempfänger überweisen, oder auf ein mit dem Zahlungsempfänger verbundenes Konto (wie beispielsweise ein Konto bei dem Erwerber). In bestimmten Ausführungsbeispielen kann die Abstimmungsnachricht zeitgleich mit der Überweisung der Geldmittel an den Zahlungsempfänger gesendet werden. Das Konto des Zahlungsempfängers, das mit dem Erwerber verbunden ist, wird dann um den zur Bezahlung der zugrundliegenden Transaktion verwendeten Finanzmittelbetrag anwachsen, abzüglich etwaiger anfallender Gebühren. Das mit dem Ausgeber verbundende Konto des Käufers wird um denselben Finanzmittelbetrag zuzüglich etwaiger anfallender Gebühren verringert. Durch dieses Verfahren kann Geld transferiert werden. Dieser Finanzmittelfluss kann die Information in der Abstimmungsnachricht abbilden, sodass alle Parteien den Zweck des Geldflusses und die entsprechende Transaktionsinformation kennen können. Somit kann ein Käufer durch das vorstehend beschriebene Verfahren eine Zahlung an einen Händler „anschieben”. Dies ermöglicht dem Käufer eine stärkere Kontrolle über Zahlungsmethoden und Abläufe im Vergleich zu herkömmlichen Zahlungsmethoden. Des Weiteren können Systeme und Prozesse für Kreditkartenverarbeitungstransaktionen in angeregt werden. Dies führt zu allen Vorteilen einer Kreditkartentransaktion in einem Anschubmodell (Push-Modell), wie beispielsweise Zahlungen für Bestellungen. Die Vorteile umfassen eine höhere Sicherheit und Betrugsabsicherung, Risikoabschätzungen in Echtzeit oder nahezu Echtzeit während der Verarbeitung, die Möglichkeit zum Zugreifen auf Belohnungsprogramme wie beispielsweise kumulative Punktrückerstattungen (point refunds), usw. Des Weiteren verbessern die vorstehend beschriebenen Ausführungsbeispiele des Systems und Verfahrens auch existierende Kreditkartentransaktionen durch Verwenden eines erweiterten Prozessflusses, der Erwerber erst nach einer Autorisierung einer Zahlung einbindet. Ausführungsbeispiele enthalten diese und andere Vorteile, wie im Folgenden näher erläutert wird.
  • 3 zeigt ein Ausführungsbespiel einer Anschubtransaktion mit Fokus auf den Abgleichvorgang zum Bestimmen einer im Wesentlichen vollständigen Zahlungsempfängerinformation. Bei diesem Ausführungsbeispiel wird eine Zahlungsanforderungsnachricht durch einen Käufer gemäß vorstehender Offenbarung vorbereitet, und von einem Zahlungsbearbeitungsnetzwerk wie beispielsweise ein in 1 gezeigter Servercomputer empfangen. Im Schritt 1 kann das Zahlungsbearbeitungsnetzwerk 26 die Zahlungsanweisungsnachricht überprüfen (d. h. „validieren”), um festzustellen, ob alle erforderlichen Informationen, wie beispielsweise die unvollständige Zahlungsempfängerinformation, enthalten sind. Falls in der Zahlungsanweisungsnachricht eine kritische Information fehlt, so wird die Transaktion nicht fortgeführt, wie im Schritt 1a gezeigt ist. Falls die Zahlungsanweisungsnachricht validiert wird, so wird sie an das Identifizierungssystem 49 zur Ermittlung des Zahlungsempfängers gesendet. Im Schritt 2 analysiert (d. h. überprüft) das Identifizierungssystem 49 die Zahlungsanweisungsnachricht, um festzustellen, ob die Nachricht eine Käuferkennung enthält und ob die unvollständige Zahlungsempfängerinformation eine Händlerkennung enthält. Ausführungsbeispiele dieser Kennungen sind oben unter Bezugnahme auf 2 beschrieben. In bestimmten Ausführungsbeispielen werden diese Kennungen in Datenbanken innerhalb des Identifizierungssystems 49 gespeichert, und bei jeder Übereinstimmung einer speziellen einzelnen Einheit bestätigt. Somit kann das Identifizierungssystem 49 bei Vorliegen einer Händlerkennung und einer Käuferkennung, die im Wesentlichen vollständige Zahlungsempfängerinformation mit nahezu völlig kompletter (hundertprozentiger) Genauigkeit ermittelt. Das Zahlungsbearbeitungsnetzwerk 26 kann dann eine beliebige erforderliche Information anfügen, um im Schritt 6 eine Autorisierungsanforderungsnachricht zu erstellen, und dann die Autorisierungsanforderungsnachricht im Schritt 7 mit herkömmlichen Mitteln zu bearbeiten (d. h. Autorisierung, Abwicklung und Freigabe).
  • Falls die Zahlungsanweisungsnachricht nicht zumindest eine Händlerkennung enthält, wird das Identifizierungssystem, das einen Servercomputer umfassen kann, dann fortschreiten zum Analysieren der vorhandenen unvollständigen Zahlungsempfängerinformation, um eine im Wesentlichen vollständige Zahlungsempfängerinformation zu ermitteln. Die unvollständige Zahlungsempfängerinformation kann im Schritt 3 mit verschiedenen Datenbanken verglichen werden, um festzustellen, ob die Information mit einem durch das Identifizierungssystem gespeicherten Zahlungsempfängereintrag übereinstimmt, basierend auf vorbestimmten Kriterien. Falls kein Treffer ermittelt wird, wird eine Transaktionsfehlernachricht im Schritt 2a an den Käufer gesendet. In exemplarischen Ausführungsbeispielen kann ein Fuzzy-Logik-Abgleich verwendet werden. Wird ein Treffer ermittelt, so wird die unvollständige Zahlungsempfängerinformation im Schritt 4 analysiert, um festzustellen, ob mehr als ein übereinstimmender Eintrag vorhanden ist. In bestimmten Ausführungsbeispielen ist lediglich ein einzelner Treffer erforderlich, und die Transaktion kann mit dem Schritt 6 fortgeführt werden, falls keine weiteren Einträge im Schritt 4 aufgefunden werden. In anderen exemplarischen Ausführungsbeispielen muss die unvollständige Zahlungsempfängerinformation mit mehr als einem in einer von dem Identifizierungssystem 49 zugegriffenen Datenbank gespeicherten Eintrag übereinstimmen. Somit wird in diesen Ausführungsbeispielen des Schritts 4 eine Transaktionsfehlernachricht im Schritt 2a an den Käufer gesendet, falls keine weiteren Einträge mit der unvollständigen Zahlungsempfängerinformation übereinstimmen.
  • Falls mehr als ein übereinstimmender Eintrag aufgefunden wird, können alle übereinstimmenden Einträge zur Ermittlung des genauesten Eintrags verglichen werden. In einer Implementierung kann das Identifizierungssystem 49 verschiedene Datenfelder der übereinstimmenden Einträge nach deren Wichtigkeit ordnen, und der übereinstimmende Eintrag mit übereinstimmenden Datenfeldern der höchsten Rangordnung kann ausgewählt werden. Beispielsweise kann der übereinstimmende Eintrag Datenfelder für eine Steuerkennung des Händlers, einen Händlernamen, eine Adresse und eine Postleitzahl enthalten. Das Identifizierungssystem kann die Felder nach deren Wichtigkeit ordnen. Somit kann das Steuerkennungsfeld am Wichtigsten sein, der Name am Zweitwichtigsten, die Adresse am Drittwichtigsten und die Postleitzahl am Viertwichtigsten.
  • In einem Fall kann das Identifizierungssystem drei zu mindestens einem gewissen Grad übereinstimmende Einträge feststellen, wobei die unvollständige Zahlungsempfängerinformation wie folgt vorgegeben ist: FredCo, 15 Broadlawn Drive, OH, 11111, wobei keine Steuerkennung vorhanden ist. Der erste übereinstimmende Eintrag kann mit der Postleitzahl exakt übereinstimmen, mit der Straßenadresse übereinstimmen, nicht aber nicht mit der Hausnummer (z. B. 12 Broadlawn Drive) und kann von dem in der unvollständigen Zahlungsinformation vorhandenen Händlernamen abweichen. Der zweite übereinstimmende Eintrag kann mit dem Händlernamen übereinstimmen, kann mit der Adresse innerhalbe einer vorbestimmten erlaubten Abweichung übereinstimmen (z. B. 15 Broadlawn Dr., Ohio) und kann mit der Postleitzahl übereinstimmen. Der dritte übereinstimmende Eintrag kann weder mit dem Namen noch mit der Postleitzahl übereinstimmen, aber mit der Adresse. In dem oben angegebenen Beispiel würde der zweite übereinstimmende Eintrag übereinstimmende Datenfelder mit der höchsten Rangordnung enthalten und würde daher der gewählte übereinstimmende Eintrag sein.
  • Im Schritt 5 könnte der gewählte übereinstimmende Eintrag analysiert werden, um die Genauigkeit festzustellen, und Abwicklungsdaten könnten ermitteln werden. Falls die Genauigkeit unterhalb einer vorbestimmten Schwelle liegt, wird eine Transaktionsfehlernachricht im Schritt 2a an den Käufer gesendet. Falls die Genauigkeit oberhalb der vorbestimmten Schwelle liegt, wurde eine im Wesentlichen vollständige Zahlungsempfängerinformation ermittelt. Abwicklungsdaten können für den durch die im Wesentlichen vollständige Zahlungsempfängerinformation identifizierten Zahlungsempfänger ermittelt werden. Die Abwicklungsdaten können eine Information wie beispielsweise eine Kontaktinformation für den mit dem Zahlungsempfänger verbundenen Erwerber enthalten. Die Abwicklungsdaten können mit der Zahlungsanforderungsnachricht, der im Wesentlichen vollständigen Zahlungsempfängerinformation und einer Anschubkennung kombiniert werden, um im Schritt 6 eine Autorisierungsanforderungsnachricht zu erstellen. Eine Verarbeitung gemäß vorgehender Beschreibung kann dann zur Vervollständigung der Transaktionen stattfinden.
  • III. Tragbare Geräte und Computervorrichtungen
  • Die 4(a) bis 4(b) zeigen Blockschaltbilder tragbarer Endverbrauchergeräte und Subsysteme, die in Computervorrichtungen in Systemen gemäß Ausführungsbeispielen der Erfindung vorhanden sein können.
  • Das in Ausführungsbeispielen der Erfindung verwendete tragbare Endverbrauchergerät kann jede geeignete Form aufweisen. Beispielsweise können geeignete tragbare Endverbrauchergeräte handgehalten und kompakt sein, sodass sie in eine Geldbörse und/oder Tasche eines Endverbraucher passen (z. B. Taschenformat). Sie können Smartcards, gewöhnliche Kredit- oder Kundenkarten (mit einem magnetischen Streifen und ohne Mikroprozessor) wie beispielsweise Zahlungskarten, Schlüsselanhängergeräte (wie beispielsweise das von der Exxon-Mobil Corp. kommerziell verfügbare SpeedpassTM), usw. enthalten. Weitere Beispiele für tragbare Endverbrauchergeräte enthalten Mobiltelefone, Personal Digital Assistants (PDAs), Pager, Zahlungskarten, Sicherheitskarten, Zugangskarten, Smartmedia-Karten, Transponder und dergleichen. Die tragbaren Endverbrauchergeräte können auch Abbuchungsgeräte (z. B. eine Kundenkarte (Debit Card)), Kreditgeräte (z. B. eine Kreditkarte) oder Speicherwertgeräte (z. B. eine Speicherwertkarte) sein.
  • Ein beispielhaftes tragbares Endverbrauchergerät 32' in der Form eines Telefons kann ein computerlesbares Medium und ein Gehäuse gemäß 4(a) umfassen. (4(a) zeigt eine Anzahl von Komponenten, und das tragbare Endverbrauchergerät gemäß den Ausführungsbeispielen der Erfindung kann jede geeignete Kombination oder Untergruppe solcher Komponenten umfassen). Das computerlesbare Medium 32(b) kann innerhalb des Korpus 32(h) vorhanden sein oder es kann von diesem abnehmbar sein. Der Korpus 32(h) kann die Form eines Plastiksubstrats, eines Gehäuses oder einer anderen Struktur aufweisen. Das computerlesbare Medium 32(b) kann ein Speicher sein, der Daten speichert und jede geeignete Form aufweist, wie beispielsweise ein Magnetstreifen, ein Speicherchip, Verschlüsselungsalgorithmen, private oder private Schlüssel, usw. Der Speicher speichert auch vorzugsweise Informationen wie beispielsweise Finanzinformationen, Transitinformationen (z. B. wie in einem U-Bahn- oder Zugpass), eine Zugangsinformation (z. B. wie in Zugangsplaketten) usw. Die Finanzinformation kann eine Information enthalten wie beispielsweise eine Bankkontoinformation, eine Bankkennungsnummer (BIN), eine Information über eine Kredit oder Kundenkartennummer, eine Kontoguthabeninformation, ein Ablaufdatum, eine Endverbraucherinformation wie beispielsweise Name, Geburtsdatum, usw.
  • Die Information in dem Speicher kann auch in der Form von Datenspuren vorhanden sein, die traditionell mit Kreditkarten verknüpft sind. Solche Spuren können eine Spur 1 und eine Spur 2 enthalten. Die Spur 1 („International Air Transport Association”) speichert mehr Information als die Spur 2, und enthält den Namen des Karteninhabers und auch eine Kontonummer und andere Diskretionsdaten. Die Spur wird manchmal von den Fluglinien beim Absichern von Reservierungen mittels einer Kreditkarte verwendet. Spur 2 („American Banking Association”) wird derzeit am meisten genutzt. Dies ist die Spur, die durch ATMs und Kreditkartenprüfer gelesen wird. Die ABA (American Banking Association) entwarf die Spezifikationen für diese Spur und alle Weltbanken müssen sie befolgen. Sie enthält das Konto des Karteninhabers, eine verschlüsselte PIN, plus andere Diskretionsdaten.
  • Das tragbare Endverbrauchergerät 32' kann des Weiteren ein kontaktloses Element 32(g) enthalten, das typischerweise in Form eines Halbleiterchips (oder eines anderen Datenspeicherelements) mit einem zugehörigen drahtlosen Übertragungselement (zum Beispiel Datenübertragung) wie beispielsweise eine Antenne implementiert ist. Das kontaktlose Element 32(g) steht in Beziehung mit (zum Beispiel darin eingebettet) dem tragbaren Endverbrauchergerät 32' und über ein zellulares Netz übertragene Daten oder Steueranweisungen können dem kontaktlosen Element 32(g) mittels einer (nicht gezeigten) Schnittstelle des kontaktlosen Elements zugeführt werden. Die Schnittstelle des kontaktlosen Elements dient zum Ermöglichen des Austausches von Daten und/oder Steueranweisungen zwischen dem Mobilgeräteschaltkreis (und damit dem zellularen Netz) und einem optionalen kontaktlosen Element 32(g).
  • Das kontaktlose Element 32(g) kann Daten übertragen und Empfangen unter Verwendung einer Nahfeldkommunikationsfähigkeit („NFC”) (oder einem Nahfeldkommunikationsmedium) typischerweise in Übereinstimmung mit einem standardisierten Protokoll oder Datentransfermechanismus (zum Beispiel ISO 14443/NFC). Bei der Nahfeldkommunikationsfähigkeit handelt es sich um eine Kurzstreckenkommunikationsfähigkeit, wie beispielsweise RFID, BluetoothTM, Infrarot, oder eine andere Datentransferfähigkeit, die zum Austausch von Daten zwischen dem tragbaren Endverbrauchergerät 32 und einem abfragenden Gerät verwendet werden kann. Somit kann das tragbare Endverbrauchergerät 32 Daten und/oder Steueranweisungen sowohl über das zellulare Netz als auch mittels der Nahfeldkommunikationsfähigkeit kommunizieren und übertragen.
  • Das tragbare Endverbrauchergerät 32' kann auch einen Prozessor 32(c) (zum Beispiel einen Mikroprozessor) zum Bearbeiten der Funktionen des tragbaren Endverbrauchergeräts 32' und eine Anzeige 32(d) enthalten, um dem Endverbraucher das Erkennen von Telefonnummern und anderer Information und Nachrichten zu ermöglichen. Das tragbare Endverbrauchergerät 32' kann des Weiteren Eingabeelemente 32(e) enthalten, um einem Endverbraucher die Eingabe einer Information in das Gerät zu ermöglichen, einen Lautsprecher 32(f) um einem Endverbraucher das Hören einer Sprachkommunikation, Musik, usw. zu ermöglichen, und ein Mikrofon 32(i), um einem Endverbraucher das Übertragen seiner Stimme über das tragbare Endverbrauchergerät 32' zu ermöglichen. Das tragbare Endverbrauchergerät 32' kann auch eine Antenne 32(a) für drahtlosen Datentransfer (z. B. Datenübertragung) enthalten.
  • Das tragbare Endverbrauchergerät 32' kann von einem Käufer zum Initiieren von Anschubzahlungen verwendet werden. In einigen Implementierungen kann das tragbare Endverbrauchergerät 32' eine Schnittstelle zum Ermöglichen des Erstellens einer Zahlungsanforderungsnachricht durch den Käufer enthalten. Das tragbare Endverbrauchergerät 32' kann dann die Zahlungsanforderungsnachricht an ein Zahlungsbearbeitungsnetzwerk unter Verwendung des kontaktlosen Elements 32(g) oder über eine drahtlose oder drahtgebundene Kommunikation senden.
  • Ein Beispiel für ein tragbares Endverbrauchergerät 32'' in der Form einer Karte ist in 4(b) gezeigt. 4(b) zeigt ein Plastiksubstrat 32(m). Ein kontaktloses Element 32(o) zur Kopplung mit einem Zugangsgerät 34 kann auch auf dem Plastiksubstrat 32(m) oder darin eingebettet vorhanden sein. Endverbraucherinformation 32(p) wie beispielsweise eine Kontonummer, ein Ablaufdatum und ein Endverbrauchername kann auf die Karte gedruckt oder gestanzt sein. Es kann auch ein Magnetstreifen 32(n) auf dem Plastiksubstrat 32(m) vorhanden sein.
  • Wie in 4(b) gezeigt ist, kann das tragbare Endverbrauchergerät 32'' sowohl einen Magnetstreifen 32(n) als auch ein kontaktloses Element 32(o) enthalten. In anderen Ausführungsbeispielen können sowohl der Magnetstreifen 32(n) als auch das kontaktlose Element 32(o) in dem tragbaren Endverbrauchergerät 32'' vorhanden sein. In anderen Ausführungsbeispielen kann entweder der Magnetstreifen 32(n) oder das kontaktlose Element 32(o) in dem tragbaren Endverbrauchergerät 32'' vorhanden sein. In einigen Implementierungen kann das tragbare Endverbrauchergerät 32'' eine Erwerbskarte umfassen. Die Erwerbskarte 32'' kann eine mit dem Käufer verbundene Käuferkennung, eine mit einem von dem Käufer gesteuerten und für Zahlungen verwendeten Konto verbundene Kontonummer oder eine andere identifizierende Information enthalten. Diese identifizierende Information kann durch den Käufer verwendet werden, wenn Zahlungsanweisungsnachrichten in vorstehend beschriebener Weise erstellt werden.
  • Die zahlreichen Teilnehmer und Elemente in 1 können einen oder mehrere Computervorrichtungen bedienen oder verwenden, um die hier beschriebenen Funktionen zu vereinfachen. Jedes der Elemente in 1 (z. B. das Zugangsgerät 34, der Händler 22, der Erwerber 24, usw.) können eine beliebige geeignete Zahl von Subsystemen verwenden, um die hier beschriebenen Funktionen zu vereinfachen. Beispiele solcher Subsysteme oder Komponenten sind in 5 gezeigt. Die in 5 gezeigten Subsysteme sind über einen Systembus 775 miteinander verbunden. Zusätzliche Subsysteme wie beispielsweise ein Drucker 774, eine Tastatur 778, eine Festplatte 779 (oder ein anderer Speicher mit einem computerlesbaren Medium), ein Monitor 776, der mit einem Anzeigeadapter 782 gekoppelt ist, und andere sind gezeigt. Peripheriegeräte und Eingabe/Ausgabe-(I/O)-Geräte, die mit einem I/O-Kontroller 771 gekoppelt sind, können mit dem Computersystem mittels einer beliebigen Zahl von aus dem Stand der Technik bekannten Mitteln wie beispielsweise ein serieller Port 777 verbunden sein. Es können beispielsweise der serielle Port 777 oder eine externe Schnittstelle 781 verwendet werden, um die Computervorrichtung mit einem Weitbereichsnetz (Wide Area Network) wie beispielsweise das Internet, einem Mauseingabegerät, oder einem Scanner zu verbinden. Die Zusammenschaltung über den Systembus ermöglicht es dem Zentralprozessor 773, mit jedem Subsystem zu kommunizieren und die Ausführung von Instruktionen von einem Systemspeicher 772 oder der Festplatte 779 und auch den Austausch von Information zwischen den Subsystemen zu steuern. Der Systemspeicher 772 und/oder die Festplatte 779 können ein computerlesbares Medium verkörpern.
  • Ausführungsbeispiele der Erfindung sind nicht auf die vorstehend beschriebenen Ausführungsbeispiele beschränkt. Beispielsweise können aus der Tatsache, dass separate funktionelle Blöcke für einen Ausgeber, ein Zahlungsbearbeitungssystem und einen Erwerber gezeigt sind, einige Einheiten auch alle dieser Funktionen ausführen und in Ausführungsbeispielen der Erfindung enthalten sein.
  • Es ist ersichtlich, dass die vorstehend beschriebene, vorliegende Erfindung in der Form einer Steuerlogik unter Verwendung einer Computersoftware in einer modularen oder integrierten Weise implementiert werden kann. Basierend auf der hier bereitgestellten Offenbarung und Lehre kann ein Durchschnittsfachmann andere Wege und/oder Verfahren zum Implementieren der vorliegenden Erfindung unter Verwendung von Hardware oder einer Kombination aus Hardware und Software erkennen und schätzen.
  • Jede der in dieser Anmeldung beschriebenen Softwarekomponenten oder -funktionen können als Softwarecode implementiert werden, der mittels eines Prozessors unter Verwendung einer geeigneten Computersprache wie beispielsweise Java, C++ oder Perl unter Verwendung beispielsweise konventioneller oder objektorientierter Techniken auszuführen ist. Der Softwarecode kann als eine Folge von Instruktionen oder Befehlen auf einem computerlesbaren Medium wie beispielsweise einem Speicher mit wahlfreiem Zugriff (RAM), einem Nur-Lese-Speicher (ROM), einem Zwischenmedium wie beispielsweise einer Festplatte oder Floppy Disc oder einem optischen Medium wie beispielsweise einer CD-ROM gespeichert werden. Jedes dieser computerlesbaren Medien kann auf oder innerhalb einzelner Computervorrichtung untergebracht sein und kann auf oder innerhalb verschiedener Computervorrichtungen innerhalb eines Systems oder Netzwerks vorhanden sein.
  • Ausführungsbeispiele der Erfindung enthalten eine Anzahl von Vorteilen. In bestimmten Implementierungen braucht sich der Begünstigte der Zahlungstransaktion (d. h. der Zahlungsempfänger) nicht in einem System zu registrieren oder einzuwilligen. Ein Zahlender kann eine Zahlung für jede Entität die bereits zum Annehmen einer Zahlung befähigt ist, anschieben, wie beispielsweise durch eine Kreditkarte oder andere Mittel. Des Weiteren behält der Zahlende Kontrolle über die Beträge und Zeitpunkte der Transaktion. Der Zahlungsempfänger und verbundene Entiäten (wie beispielsweise der Erwerber) müssen nicht mit Transaktionen, die nicht abschließend vom Ausgeber genehmigt werden, belästigt werden, wodurch die Systemeffizienz erhöht wird und Verluste verhindert werden. Alle Parteien in der Transaktion können Zugriff auf eine verbesserte Betrugs- und Risikoerfassung und auch Belohnungs- und andere nützliche Programme erhalten.
  • Die vorstehende Beschreibung dient zur Illustration und ist nicht beschränkend. Viele Variationen der Erfindung werden für den Fachmann anhand der Offenbarung ersichtlich. Der Umfang der Erfindung sollte daher nicht unter Bezugnahme auf die vorstehende Beschreibung bestimmt werden, sondern stattdessen unter Bezugnahme auf die beigefügten Ansprüche samt deren vollständigem Umfang oder Äquivalenten ermittelt werden.
  • Eines oder mehrere Merkmale eines jeden Ausführungsbeispiels kann mit einem oder mehreren Merkmalen eines anderen Ausführungsbeispiels kombiniert werden, ohne vom Umfang der Erfindung abzuweichen.
  • Eine Nennung von „ein”, oder „der” soll die Bedeutung „ein oder mehr” erhalten, solange nichts Gegenteiliges speziell angegeben ist. Eine Nennung von „sie” hat eine geschlechtsneutrale Bedeutung und kann als „er” oder „sie” gelesen werden, solange nichts Gegenteiliges speziell angegeben ist.
  • Alle vorstehend erwähnten Patente, Patentanmeldungen, Veröffentlichungen und Beschreibungen werden hier als Bezug in ihrer Gesamtheit und für alle Zwecke einbezogen. Nichts wird als Stand der Technik eingestanden.
  • Zusammenfassung
  • System und Verfahren zum Bearbeiten von Anschubtransaktionen (Push-Transaktionen). Ein Zahlender kann eine Transaktion ohne Eingabe seitens des Zahlungsempfänger initiieren. Ein System kann ausgehend von einer durch den Zahlenden bereitgestellten unvollständigen Information feststellen, wer der Zahlungsempfänger ist, und die Transaktion an die richtige Partei leiten.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Nicht-Patentliteratur
    • - ISO 14443/NFC [0067]

Claims (22)

  1. Computerimplementiertes Verfahren zum Durchführen einer Transaktion, mit Empfangen einer Zahlungsanweisungsnachricht an einem Servercomputer, wobei die Zahlungsanweisungsnachricht zum Durchführen einer Zahlung an einen Zahlungsempfänger dient, der ein mit einem Ausgeber verbundenes Konto nutzt, wobei die Zahlungsanweisungsnachricht zumindest eine unvollständige Zahlungsempfängerinformation enthält und wobei die Zahlungsanweisungsnachricht des Weiteren von einer von dem Zahlungsempfänger abweichenden Entität erzeugt wird; Überprüfen der Zahlungsanweisungsnachricht; Ermitteln einer im Wesentlichen vollständigen Zahlungsempfängerinformation; und Senden einer Autorisierungsanforderungsnachricht an den Ausgeber nach dem Prüfen der Zahlungsanweisungsnachricht, wobei die Autorisierungsanforderung eine Anschubkennung (Push-Kennung) enthält.
  2. Computerimplementiertes Verfahren nach Anspruch 1, wobei die Zahlungsanweisungsnachricht von dem Zahlenden erzeugt wird.
  3. Computerimplementiertes Verfahren nach Anspruch 2, des Weiteren umfassend Unterrichten des Zahlenden darüber, dass die Transaktion nicht ohne eine weitere Zahlungsempfängerkennungsinformation abgeschlossen werden kann, vor dem Senden der Autorisierungsanforderungsnachricht.
  4. Computerimplementiertes Verfahren nach Anspruch 1, des Weiteren umfassend: Empfangen einer Autorisierungsantwortnachricht für die Transaktion von dem Ausgeber; und Senden eines Autorisierungsprotokolls an einen mit dem Zahlungsempfänger verbundenen Erwerber.
  5. Computerimplementiertes Verfahren nach Anspruch 4, wobei die Autorisierungsanforderungsnachricht vor einer Kommunikation mit dem Erwerber an den Ausgeber gesendet wird.
  6. Computerimplementiertes Verfahren Anspruch 1, des Weiteren umfassend: vor dem Senden der Autorisierungsanforderungsnachricht, Anhängen der Anschubkennung an die Zahlungsanweisung und Übersetzen der Zahlungsanweisung in eine BASE-1-Nachricht, wobei die Autorisierungsanforderung die BASE-1-Nachricht umfasst.
  7. Computerimplementiertes Verfahren nach Anspruch 1, wobei das Ermitteln der im Wesentlichen vollständigen Zahlungsempfängerinformation ein Ermitteln eines Zahlungsempfängers mit einer Genauigkeit von zumindest einer vorbestimmten Schwelle enthält.
  8. Computerimplementiertes Verfahren nach Anspruch 7, wobei die vorbestimmte Schwelle 85% umfasst.
  9. Computerimplementiertes Verfahren nach Anspruch 1, wobei die Ermittlung der im Wesentlichen vollständigen Zahlungsempfängerinformation eine Verwendung einer Fuzzy-Logik umfasst, um Informationen in der Zahlungsanweisungsnachricht mit einer oder mehreren Listen von Zahlungsempfängernamen in einer oder mehreren Datenbanken abzugleichen.
  10. Computerimplementiertes Verfahren nach Anspruch 9, wobei die eine oder mehrere Datenbanken Datenbanklisten von Zahlungsempfängern enthalten, die Zahlungen über ein Zahlungsbearbeitungsnetzwerk akzeptieren.
  11. Computerimplementiertes Verfahren zum Durchführen einer Zahlung, mit: Senden einer Zahlungsanweisungsnachricht mit zumindest einer unvollständigen Zahlungsempfängerinformation, einem Transaktionsbetrag und einem Zahlungszeitpunkt an einen Servercomputer, wobei die Zahlungsanweisungsnachricht durch den Servercomputer analysiert wird, um eine im Wesentlichen vollständige Zahlungsempfängerinformation zu ermitteln, und ein Autorisierungsprotokoll wird an einen mit dem Zahlungsempfänger verbundenen Erwerber gesendet; und Transferieren von Finanzmitteln zu dem Zahlungsempfänger.
  12. Computerimplementiertes Verfahren nach Anspruch 11, wobei die zumindest unvollständige Zahlungsempfängerinformation einen Namen des Zahlungsempfängers enthält.
  13. Computerimplementiertes Verfahren nach Anspruch 11, wobei die zumindest unvollständige Zahlungsempfängerinformation eine Telefonnummer des Zahlungsempfängers enthält.
  14. Computerimplementiertes Verfahren zum Empfangen einer Anschubzahlungstransaktion (Push-Zahlungstransaktion), mit: Empfangen eines mit einer Transaktion verbundenen Autorisierungsprotokolls, wobei das Autorisierungsprotokoll eine Berichtssystemdatei und eine Abwicklungsdatei enthält; Senden einer Nachricht hinsichtlich eines Finanzmittelflusses für die Transaktion; Empfangen der mit der Transaktion verbunden Finanzmittel; Überweisen der Finanzmittel an einen Zahlungsempfänger; und Senden einer Transaktionsinformation an den Zahlungsempfänger.
  15. Computerimplementiertes Verfahren nach Anspruch 14, des Weiteren umfassend Unterrichtetwerden über die Transaktion mittels des Autorisierungsprotokolls.
  16. Computerimplementiertes Verfahren nach Anspruch 14, wobei die Transaktionsinformation einen Abstimmungsbericht umfasst, der eine Rechnungsnummer, eine Bestellnummer und eine Information über den Zahlenden enthält.
  17. Computerimplementiertes Verfahren nach Anspruch 16, wobei der Abstimmungsbericht zeitgleich mit der Überweisung der Finanzmittel gesendet wird.
  18. Computerimplementiertes Verfahren nach Anspruch 16, wobei die Information über den Zahlenden den Namen des Zahlenden enthält.
  19. Computerlesbares Medium zum Durchführen von Anschubtransaktionen (Push-Transaktionen), mit einem Code zum Empfangen einer Zahlungsanweisungsnachricht zum Durchführen einer Zahlung unter Verwendung eines mit einem Ausgeber verbundenen Kontos, wobei die Zahlungsanweisungsnachricht zumindest eine unvollständige Zahlungsempfängerinformation enthält und wobei die Zahlungsanweisungsnachricht des Weiteren von einer von dem Zahlungsempfänger abweichenden Entität erzeugt wird; einem Code zum Überprüfen der Zahlungsanweisungsnachricht, einem Code zum Ermitteln einer im Wesentlichen vollständigen Zahlungsempfängerinformation; und einem Code zum Senden einer Autorisierungsanforderung an den Ausgeber, wobei die Autorisierungsanforderung eine Anschubkennung (Push-Kennung) enthält.
  20. Computerlesbares Medium nach Anspruch 19, wobei das Ermitteln der im Wesentlichen vollständigen Zahlungsempfängerinformation ein Ermitteln eines Zahlungsempfängers mit einer Genauigkeit von zumindest einer vorbestimmten Schwelle umfasst.
  21. Computerlesbares Medium nach Anspruch 20, wobei die vorbestimmte Schwelle 85% umfasst.
  22. Computerlesbares Medium zum Identifizieren eines Zahlungsempfängers in einer Transaktion mit: einem Code zum Empfangen einer Zahlungsanweisungsnachricht; einem Code zum Überprüfen der Zahlungsanweisungsnachricht und zum Feststellen ob die Zahlungsanweisungsnachricht eine Information zum Ermitteln eines Zahlungsempfängers enthält; und einem Code zur Verwendung eines Fuzzy-Logik-Abgleichs, um die Information in der Zahlungsanweisungsnachricht mit mehreren Datenspeichern zu vergleichen und einen mit der Zahlungsanweisung verbundenen Zahlungsempfänger im Wesentlichen zu identifizieren, wobei die mehreren Datenspeicher eine Vielzahl von Kennungen für zumindest einen Händler enthalten, wobei die Vielzahl von Kennungen eine Kennung für einen Namen, eine Kennung für eine Telefonnummer und eine Kennung für eine Adresse enthalten.
DE112009000137T 2008-01-15 2009-01-13 System und Verfahren zur Datenvervollständigung mit Anschubkennung Withdrawn DE112009000137T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US2128908P 2008-01-15 2008-01-15
US61/021,289 2008-01-15
PCT/US2009/030830 WO2009091722A1 (en) 2008-01-15 2009-01-13 System and method for data completion including push identifier

Publications (1)

Publication Number Publication Date
DE112009000137T5 true DE112009000137T5 (de) 2011-02-17

Family

ID=40456982

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112009000137T Withdrawn DE112009000137T5 (de) 2008-01-15 2009-01-13 System und Verfahren zur Datenvervollständigung mit Anschubkennung

Country Status (7)

Country Link
US (1) US8249957B2 (de)
JP (1) JP5518740B2 (de)
CA (1) CA2711936A1 (de)
DE (1) DE112009000137T5 (de)
GB (1) GB2468817A (de)
TW (1) TWI490798B (de)
WO (1) WO2009091722A1 (de)

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002041114A2 (en) * 2000-10-30 2002-05-23 Raf Technology, Inc. Verification engine for user authentication
US7958030B2 (en) 2004-09-01 2011-06-07 Visa U.S.A. Inc. System and method for issuer originated payments for on-line banking bill payments
US9292850B2 (en) 2007-09-10 2016-03-22 Visa U.S.A. Inc. Host capture
DE112009000137T5 (de) 2008-01-15 2011-02-17 Visa U.S.A. Inc., San Francisco System und Verfahren zur Datenvervollständigung mit Anschubkennung
US8219489B2 (en) * 2008-07-29 2012-07-10 Visa U.S.A. Inc. Transaction processing using a global unique identifier
CN102227742A (zh) * 2008-11-26 2011-10-26 Sc控股私人有限公司 信用额度提供系统和方法
US20110093325A1 (en) * 2009-10-21 2011-04-21 Tellermetrix, Inc. Automated Financial Institution Customer Reward Program
US10255591B2 (en) 2009-12-18 2019-04-09 Visa International Service Association Payment channel returning limited use proxy dynamic value
US8484104B1 (en) * 2010-04-30 2013-07-09 Intuit Inc. Methods and systems for automatic bill pay setup for online bill pay systems
US8407776B2 (en) * 2011-02-11 2013-03-26 Good Technology Corporation Method, apparatus and system for provisioning a push notification session
US8731523B1 (en) 2011-06-14 2014-05-20 Urban Airship, Inc. Push notification delivery system with feedback analysis
US8554855B1 (en) 2011-06-14 2013-10-08 Urban Airship, Inc. Push notification delivery system
US11049110B2 (en) * 2011-06-17 2021-06-29 Zelis Payments, Llc Healthcare transaction facilitation platform apparatuses, methods and systems
US8560447B1 (en) 2011-07-27 2013-10-15 Intuit Inc. Intelligent account selection for electronic bill payment
MX2014002613A (es) * 2011-09-06 2014-07-24 Mastercard International Inc Aparato, metodo y producto de programa de computadora para limpieza de datos y/o depuracion de facturador.
IL219597A0 (en) 2012-05-03 2012-10-31 Syndrome X Ltd Malicious threat detection, malicious threat prevention, and a learning systems and methods for malicious threat detection and prevention
US9524501B2 (en) 2012-06-06 2016-12-20 Visa International Service Association Method and system for correlating diverse transaction data
US20140214675A1 (en) * 2013-01-25 2014-07-31 Pankaj Sharma Push payment system and method
US10878422B2 (en) * 2013-06-17 2020-12-29 Visa International Service Association System and method using merchant token
US10949870B2 (en) 2013-06-25 2021-03-16 Brian Booth Techniques for user-controlled real-time data processing
US20140379453A1 (en) * 2013-06-25 2014-12-25 Brian Booth Automated Payment, Reward Program Enrollment, and Redemption
CN104618415B (zh) * 2014-03-13 2018-06-19 腾讯科技(深圳)有限公司 信用账户创建方法、装置及系统
US10726415B2 (en) * 2014-06-06 2020-07-28 Tyson Kopczynski Token-based transaction system and method to facilitate non-cash payments without using personally identifiable information data
US10692156B2 (en) * 2014-09-05 2020-06-23 Thomas Skala Payment system and method
CN105592034B (zh) * 2014-12-31 2018-11-27 中国银联股份有限公司 用于安全性信息交互的风险识别方法及装置
JP6598462B2 (ja) * 2015-01-06 2019-10-30 株式会社ディスコ 人事管理システム
US9449320B1 (en) 2015-06-08 2016-09-20 Vantiv, Llc Closed-loop testing of integrated circuit card payment terminals
US11295293B2 (en) * 2016-01-07 2022-04-05 Worldpay, Llc Point of interaction device emulation for payment transaction simulation
WO2019031627A1 (ko) 2017-08-09 2019-02-14 주식회사 센스톤 가상코드제공시스템, 가상코드생성장치, 가상코드검증장치, 가상코드제공방법 및 가상코드제공프로그램
US11257134B2 (en) * 2019-06-28 2022-02-22 American Express Travel Related Services, Inc. Supplier invoice reconciliation and payment using event driven platform
CN111382360B (zh) * 2020-03-11 2023-06-16 支付宝(杭州)信息技术有限公司 信息推送方法及装置
WO2022061182A1 (en) * 2020-09-21 2022-03-24 Visa International Service Association Alias directory

Family Cites Families (93)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4341951A (en) 1980-07-02 1982-07-27 Benton William M Electronic funds transfer and voucher issue system
US4755872A (en) 1985-07-29 1988-07-05 Zenith Electronics Corporation Impulse pay per view system and method
US5023904A (en) 1987-08-04 1991-06-11 Science Dynamics Corporation Direct telephone dial ordering service
US5008930A (en) 1989-10-24 1991-04-16 At&T Bell Laboratories Customer definable integrated voice/data call transfer technique
US5220501A (en) 1989-12-08 1993-06-15 Online Resources, Ltd. Method and system for remote delivery of retail banking services
USRE36788E (en) 1990-09-06 2000-07-25 Visa International Service Association Funds transfer system
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
CA2100134C (en) 1992-09-29 1999-06-22 Raymond Otto Colbert Secure credit/debit card authorization
FI100137B (fi) 1994-10-28 1997-09-30 Vazvan Simin Reaaliaikainen langaton telemaksujärjestelmä
US5591949A (en) 1995-01-06 1997-01-07 Bernstein; Robert J. Automatic portable account controller for remotely arranging for payment of debt to a vendor
US5778313A (en) 1995-12-08 1998-07-07 Cellexis International, Inc. Pre-paid cellular telephone system
US5729460A (en) 1995-12-14 1998-03-17 Francotyp-Postalia Ag & Co. Method for payment of the recrediting of an electronic postage meter and arrangement for the operation of a data central
US5787159A (en) 1996-02-27 1998-07-28 Hamilton; Chris Use of caller ID information
CA2197930A1 (en) 1996-02-29 1997-08-29 Masayuki Ohki Electronic wallet and method for operating the same
US5991749A (en) 1996-09-11 1999-11-23 Morrill, Jr.; Paul H. Wireless telephony for collecting tolls, conducting financial transactions, and authorizing other activities
US5937396A (en) 1996-12-04 1999-08-10 Konya; Arpad System for ATM/ATM transfers
US5991748A (en) 1996-12-06 1999-11-23 American Express Travel Related Services Company, Inc. Methods and apparatus for regenerating a prepaid transaction account
US6868391B1 (en) 1997-04-15 2005-03-15 Telefonaktiebolaget Lm Ericsson (Publ) Tele/datacommunications payment method and apparatus
US20020174016A1 (en) 1997-06-16 2002-11-21 Vincent Cuervo Multiple accounts and purposes card method and system
US6295522B1 (en) 1997-07-11 2001-09-25 Cybercash, Inc. Stored-value card value acquisition method and apparatus
JPH1196275A (ja) * 1997-07-24 1999-04-09 Fuji Shintaku Ginkou Kk 買掛金一括支払信託システム
US6173272B1 (en) * 1998-04-27 2001-01-09 The Clearing House Service Company L.L.C. Electronic funds transfer method and system and bill presentment method and system
US6206283B1 (en) 1998-12-23 2001-03-27 At&T Corp. Method and apparatus for transferring money via a telephone call
US6418420B1 (en) 1998-06-30 2002-07-09 Sun Microsystems, Inc. Distributed budgeting and accounting system with secure token device access
AU4528799A (en) 1998-07-14 2000-02-07 Marc V. Wintriss A method and apparatus for facilitating business transactions between buyers nodes and vendors nodes over network by providing a verification node
US6169974B1 (en) 1998-10-08 2001-01-02 Paymentech, Inc. Method for closed loop processing of transactions utilizing bank card association
WO2000030051A1 (en) 1998-11-18 2000-05-25 Wintriss Marc V A method and apparatus for facilitating business transactions over a network by providing a reliable verification source
AU4501600A (en) 1999-04-30 2000-11-17 X.Com Corporation System and method for electronically exchanging value among distributed users
US6609113B1 (en) 1999-05-03 2003-08-19 The Chase Manhattan Bank Method and system for processing internet payments using the electronic funds transfer network
US6704714B1 (en) 1999-05-03 2004-03-09 The Chase Manhattan Bank Virtual private lock box
US7664703B2 (en) 1999-10-26 2010-02-16 The Western Union Company Value transfer systems and methods
US6847953B2 (en) 2000-02-04 2005-01-25 Kuo James Shaw-Han Process and method for secure online transactions with calculated risk and against fraud
US20030083042A1 (en) 2000-02-11 2003-05-01 Maher Abuhamdeh Remote rechargeable prepaid cellular service peripheral device
US6612487B2 (en) 2000-02-14 2003-09-02 Mas Inco Corporation Method and system for account activation
US7827115B2 (en) * 2000-04-24 2010-11-02 Visa International Service Association Online payer authentication service
US10185936B2 (en) 2000-06-22 2019-01-22 Jpmorgan Chase Bank, N.A. Method and system for processing internet payments
US20020152168A1 (en) 2000-07-11 2002-10-17 First Data Corporation Automated transfer with stored value fund
US20030105710A1 (en) 2000-07-11 2003-06-05 Ellen Barbara Method and system for on-line payments
US6769605B1 (en) 2000-07-21 2004-08-03 Jason P. Magness Money transfer system
US20020029193A1 (en) * 2000-09-01 2002-03-07 Infospace, Inc. Method and system for facilitating the transfer of funds utilizing a telephonic identifier
US7415442B1 (en) 2000-09-26 2008-08-19 Integrated Technological Systems, Inc. Integrated technology money transfer system
WO2002041114A2 (en) * 2000-10-30 2002-05-23 Raf Technology, Inc. Verification engine for user authentication
US6993507B2 (en) 2000-12-14 2006-01-31 Pacific Payment Systems, Inc. Bar coded bill payment system and method
US20020128981A1 (en) 2000-12-28 2002-09-12 Kawan Joseph C. Method and system for facilitating secure customer financial transactions over an open network
JP2002215756A (ja) * 2001-01-12 2002-08-02 Takayuki Miyashita インターネット不動産仲介システム
WO2002063432A2 (en) 2001-02-07 2002-08-15 I4 Commerce Inc. Method and system for completing a transaction between a customer and a merchant
US8498932B2 (en) 2001-05-24 2013-07-30 Daniel W. Davis Card based transfer account
US7742984B2 (en) 2001-07-06 2010-06-22 Hossein Mohsenzadeh Secure authentication and payment system
US7225156B2 (en) 2001-07-11 2007-05-29 Fisher Douglas C Persistent dynamic payment service
JP2003067663A (ja) * 2001-08-24 2003-03-07 Ntt Data Corp 決済処理装置及びコンピュータプログラム
US20030055756A1 (en) 2001-09-17 2003-03-20 Allan Frederick Aley Method of making money payments
US20030120608A1 (en) 2001-12-21 2003-06-26 Jorge Pereyra Secure method for purchasing and payment over a communication network and method for delivering goods anonymously
US20030144935A1 (en) 2002-01-30 2003-07-31 Sobek Michael F. Methods and systems for processing, accounting, and administration of stored value cards
US7797233B2 (en) 2002-01-30 2010-09-14 Store Financial Services, Llc Methods and systems for processing, accounting, and administration of stored value cards
US7890393B2 (en) 2002-02-07 2011-02-15 Ebay, Inc. Method and system for completing a transaction between a customer and a merchant
GB0204620D0 (en) 2002-02-28 2002-04-10 Europay Internat N V Chip authentication programme
CA2488730A1 (en) 2002-06-11 2003-12-18 First Data Corporation Value processing network and methods
US7251656B2 (en) 2002-07-26 2007-07-31 Checkfree Corporation Electronic payments using multiple unique payee identifiers
JP2004178377A (ja) * 2002-11-28 2004-06-24 E Bank Corp 決済システム及び決済方法
US7207479B2 (en) 2002-12-11 2007-04-24 American Express Travel Related Services Company, Inc. Systems and methods for automatically establishing merchant accounts for transaction card usage
US7003493B2 (en) 2003-01-22 2006-02-21 First Data Corporation Direct payment with token
US7831490B2 (en) * 2003-02-28 2010-11-09 Payment Pathways, Inc. Enhanced system for electronic funds transfer and elimination of the payee's need for encryption and privacy
US20040188515A1 (en) 2003-03-26 2004-09-30 Ivan Jimenez Pre-paid internet credit card
US20040210520A1 (en) * 2003-04-02 2004-10-21 Fitzgerald Daleen R. Bill payment payee information management system and method
US20050080697A1 (en) 2003-10-14 2005-04-14 Foss Sheldon H. System, method and apparatus for providing financial services
US8082210B2 (en) 2003-04-29 2011-12-20 The Western Union Company Authentication for online money transfers
US7895119B2 (en) 2003-05-13 2011-02-22 Bank Of America Corporation Method and system for pushing credit payments as buyer initiated transactions
AU2003903229A0 (en) 2003-06-25 2003-07-10 Ewise Systems Pty Ltd A system and method for facilitating on-line payment
US20050177510A1 (en) * 2004-02-09 2005-08-11 Visa International Service Association, A Delaware Corporation Buyer initiated payment
US7711638B2 (en) 2004-03-17 2010-05-04 The Western Union Company System and method for transferring money
US20060218086A1 (en) * 2005-03-24 2006-09-28 Heather Campbell Payee aliasing
US20060277148A1 (en) 2005-06-06 2006-12-07 Thackston James D Payment system and method for on-line commerce operations
US7494056B2 (en) 2005-08-23 2009-02-24 Kenneth Sturm Retail package for prepaid debit cards and method for debit card distribution
US20070057043A1 (en) 2005-09-13 2007-03-15 Billetel, Llc Calling card with integrated banking functions
US20070094132A1 (en) 2005-10-25 2007-04-26 Waterson Vincent A System and method for person to person electronic fund transfer using video payphones
US7818264B2 (en) * 2006-06-19 2010-10-19 Visa U.S.A. Inc. Track data encryption
JP5139715B2 (ja) * 2006-04-25 2013-02-06 Kddi株式会社 携帯電話を利用した金融取引サービス方法および金融取引サービスシステム
US8732044B2 (en) 2006-05-23 2014-05-20 Mastercard International Incorporated Electronic transaction apparatus and method
WO2007144708A1 (en) 2006-06-09 2007-12-21 Kean Hoe Au Method of secure payment over a network
US20080010204A1 (en) * 2006-07-06 2008-01-10 Firethorn Holdings, Llc Methods and Systems For Making a Payment Via a Paper Check in a Mobile Environment
US8510223B2 (en) 2006-08-03 2013-08-13 The Western Union Company Money transfer transactions via pre-paid wireless communication devices
WO2008052114A2 (en) 2006-10-25 2008-05-02 Nakfoor Brett A Systems and methods for user authorized customer-merchant transactions
US20080120231A1 (en) 2006-11-16 2008-05-22 Charles Megwa Money refillable credit card
US7848980B2 (en) * 2006-12-26 2010-12-07 Visa U.S.A. Inc. Mobile payment system and method using alias
US20080172344A1 (en) 2007-01-17 2008-07-17 William Eager Social networking platform for business-to-business interaction
US8261974B2 (en) 2007-09-14 2012-09-11 Robert E. Hull Integrated financial transaction and access system
US20090089211A1 (en) 2007-10-02 2009-04-02 Patricia Morse System and method for person to person fund transfer
US20090106152A1 (en) 2007-10-17 2009-04-23 The Western Union Company Money transfers utilizing unique receiver identifier
US7958052B2 (en) 2007-12-31 2011-06-07 Mastercard International Incorporated Methods and systems for cardholder initiated transactions
SG154345A1 (en) 2008-01-09 2009-08-28 Banking Comp Services Private Electronic payment method of presentation to an automated clearing house (ach)
DE112009000137T5 (de) 2008-01-15 2011-02-17 Visa U.S.A. Inc., San Francisco System und Verfahren zur Datenvervollständigung mit Anschubkennung
US7720764B2 (en) 2008-02-01 2010-05-18 Kenneth James Emerson Method, device, and system for completing on-line financial transaction
US8756161B2 (en) 2008-02-11 2014-06-17 Accenture Global Services Limited Customer initiated payment method using mobile device

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ISO 14443/NFC

Also Published As

Publication number Publication date
US8249957B2 (en) 2012-08-21
JP5518740B2 (ja) 2014-06-11
CA2711936A1 (en) 2009-07-23
TWI490798B (zh) 2015-07-01
GB201011864D0 (en) 2010-09-01
GB2468817A (en) 2010-09-22
WO2009091722A1 (en) 2009-07-23
JP2011510399A (ja) 2011-03-31
US20090182654A1 (en) 2009-07-16
TW200937323A (en) 2009-09-01

Similar Documents

Publication Publication Date Title
DE112009000137T5 (de) System und Verfahren zur Datenvervollständigung mit Anschubkennung
US20210398121A1 (en) Systems and methods for a private sector monetary authority
US20200042989A1 (en) Asset-backed tokens
KR102103931B1 (ko) 식별 가능 태그와 인공지능을 이용한 결제수단과 문서 전산관리 방법 및 시스템
Dahlberg et al. Understanding changes in consumer payment habits-do mobile payments and electronic invoices attract consumers?
US9070122B1 (en) Host-managed gift card program
CN111882412B (zh) 一种用于不懂会计知识的普通人完成企业复式记账的方法
CN110648135A (zh) 一种基于对象的电子支付与清算方法
CN107945013A (zh) 一种货车司机贷款风险控制的系统及控制方法
CN107636717A (zh) 提供在线定金、抵押物、债券和/或担保品的自动化担保的融资
DE112013004894T5 (de) Verfahren, System und zugehöriger ausführbarer Computercode zur Vermittlung von Kredittransaktionen
US20130339244A1 (en) Methods and systems for check cashing risk analysis
US20170140365A1 (en) Systems and methods using check document images to create pre-paid payment cards
WO2014143720A2 (en) Systems and methods for a private sector monetary authority
TW200903373A (en) From indirect finance to direct finance debt-clearing system and method
CN111008891A (zh) 一种可流转电子外制原始凭证、系统、终端
CN114331105A (zh) 电子汇票的处理系统、方法、电子设备和存储介质
DE202019106383U1 (de) Elektronische Zahlungsvorrichtung
Samudrala Retail Banking Technology: The Smart Way to Serve Customers
DE202018006361U1 (de) Zahlungssystem
KR100932313B1 (ko) 오브젝트금융 평가 방법 및 시스템과 이를 위한 기록매체
TWI359386B (de)
Qiu Build Alipay ecosystem in Brazil
Anugrah Fraud Prevention in online Travel Agency
Alam et al. IT in Islamic Banks

Legal Events

Date Code Title Description
R012 Request for examination validly filed

Effective date: 20120711

R016 Response to examination communication
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee