DE69534982T2

DE69534982T2 - Computer-zahlungssystem zum kaufen von informationsprodukten mittels elektronischem transfer auf dem internet

Info

Publication number: DE69534982T2
Application number: DE69534982T
Authority: DE
Inventors: H. Lee Rancho Santa Fe STEIN; A. Einar Huntington Beach STEFFERUD; S. Nathaniel Morristown BORENSTEIN; T. Marshall Mountain View ROSE
Original assignee: PayPal Inc
Current assignee: PayPal Inc
Priority date: 1994-09-16
Filing date: 1995-09-14
Publication date: 2007-01-04
Anticipated expiration: 2015-09-15
Also published as: EP0791202B1; JPH10508708A; EP1693795A3; US6246996B1; EP1693795A2; DE69534982D1; US5826241A; EP0791202A1; WO1996008783A1; EP0791202A4; AU696475B2; ATE326043T1; AU3630995A; NZ293783A; US20110137751A1

Description

HINTERGRUND DER ERFINDUNG
Die vorliegende Erfindung bezieht sich auf ein System zum Ermöglichen einer Zahlung für Informationsprodukte, die elektronisch über ein nicht sicheres Netz transferiert werden können, und insbesondere bezieht sich die vorliegende Erfindung auf ein Zahlungssystem, das verwendet werden kann, um einen Internetanwender in die Lage zu versetzen, an einen anderen Internetanwender für Informationsprodukte von Wert, die elektronisch über das Internet transferiert werden können, eine Zahlung zu leisten.
Das Internet hat sich zu einer großen Gemeinschaft von elektronisch verbundenen Benutzern, die sich überall auf der Welt befinden, entwickelt, die bedeutende Mengen an Informationen bereitwillig und regelmäßig austauscht. Das Internet dient weiterhin seinen ursprünglichen Zwecken, einen Zugang zu und einen Austausch von Informationen zwischen Regierungsbehörden, Laboratorien und Universitäten für Forschung und Ausbildung bereitzustellen. Zusätzlich hat sich das Internet dazu entwickelt, einer Vielzahl von Interessen und Foren zu dienen, die über seine ursprünglichen Ziele hinausgehen.
Das Internet ist als ein möglicher neuer Marktplatz für Informationsprodukte betrachtet worden. Es ist jetzt physikalisch möglich, Informationsprodukte wie Artikel, Software, Cartoons, etc. über das Internet zu transferieren.
Die Verwendung des Internets als Marktplatz hat einige Vorteile. Informationsprodukte können ohne physikalische Verpackung elektronisch geliefert werden. Da Informationen leicht per Mausklick auf einer Workstation eines Benutzers dupliziert werden, gehen die Kosten für das Produzieren und Reproduzieren des Warenbestands Richtung Null und lassen die Kosten für das Erzeugen oder Herstellen der Informationen als die dominierenden Kosten übrig. Sobald ein Informationsprodukt entwickelt worden ist, können geringe oder keine Kosten für die Produktion oder für den Warenbestand anfallen, da eine Kopie des Produkts versendet werden kann, wann immer ein Käufer einen Kauf tätigt, vorausgesetzt, dass der Händler die verfügbare Bandbreite aufweist. In Anbetracht, dass Kosten für den Warenbestand auf dem Internet beinahe Null sind, gibt es möglicherweise im Internet Zehntausende von Informationsverkäufern, d.h. von Leuten mit zu verkaufenden Ideen oder Informationsprodukten.
Ein weiterer Vorteil der Verwendung des Internets als Marktplatz ist, dass, abhängig von der Art des betroffenen Informationsproduktes, die Verarbeitung eines Käuferauftrags automatisiert werden kann, sodass es nicht notwendig ist, dass ein Arbeiter manuell eingreift, um eine Transaktion abzuschließen.
Obgleich das Internet momentan in der Lage ist, als Marktplatz für neue Informationsprodukte zu dienen, hat sich der Gebrauch des Internets zu diesem Zweck langsam entwickelt. Ein Grund, der diesen Mangel an Entwicklung erklärt, ist, dass es schwierig ist, unter Verwendung des Internets für Informationsprodukte zu zahlen. Ein Benutzer kann über das Internet nicht Bargeld oder einen Scheck senden und das Senden eines Schecks über physikalische Zustelldienste ist langsam. Das Senden einer Kreditkartennummer über das Internet wirft Sicherheitsprobleme auf. Selbst wenn es halbwegs sicher wäre, Kreditkartennummern zu senden, gäbe es eine Menge potentieller Verkäufer von Informationsprodukten, welche nicht die erforderlichen Handelskonten haben -und sich dafür nicht qualifizieren könnten-. Um ein Handelskonto zu haben, benötigen Kreditkartenfirmen einen Verkäufer, der Kreditkarten zur Zahlung akzeptiert. Konventionelle Handelskonten erfordern einen verhältnismäßig hohen Standard an Kreditwürdigkeit und eine finanzielle Garantie. Die Notwendigkeit eines konventionellen Handelskontos behindert den Handel im Internetmarktplatz, weil ein durchschnittlicher Internetanwender Schwierigkeiten haben kann, sich für ein Handelskonto zu qualifizieren.
Dementsprechend gibt es einen Bedarf an einem System, welches das Zahlungsproblem im Internet löst, um die Entwicklung eines kommerziellen Marktes zu ermöglichen.
US-5,283,829 beschreibt ein elektronisches Rechnungszahlungssystem und eine Rechnungszahlungsmethode, die eine Rechnungsstellungseinrichtung umfassen, zum Erzeugen von Zulassungsaufzeichnungen und zum Generieren von Zulassungsnummern für jeden vor-autorisierten Bezieher. Das System schließt auch eine interaktive Zahlungszulassungsvorrichtung ein, in die sich Bezieher einwählen, um eine Zahlung zuzulassen und die aufgrund von gesammelten Informationen bestimmt, ob ein elektronischer Kapitaltransfer eingeleitet wird. Eine Zulassungsaufzeichnungsdatenbank und eine Abrufverlaufprotokolldatenbank sind ebenfalls Teil des Rechnungszahlungssystems. Um eine elektronische Rechnungszahlung zuzulasssen muss ein Bezieher, sobald er vor-autorisiert ist, nur die Zahlungszulassungsvorrichtung anwählen und die zugewiesene Zulassungsnummer eingeben. Eine Reihe von Sicherheitsüberprüfungen und Vergleichen werden durchgeführt, um vor versehentlichen und böswilligen Eingaben von Zulassungsnummern zu schützen. Sobald alle Sicherheitsüberprüfungen erledigt sind, wird dem Bezieher eine Bestätigungsnummer bekannt gegeben, und ein elektronischer Kapitaltransfer wird eingeleitet.
US 4,799,156 beschreibt ein System für interaktive elektronische Online-Kommunikationen und Verarbeitung von Geschäftstransaktionen zwischen einer Mehrzahl von unterschiedlichen Arten von unabhängigen Benutzern, die mindestens eine Mehrzahl von Verkäufern einschließt und eine Mehrzahl von Käufern, sowie Geldinstitute und Frachtdienstanbieter. Jeder Benutzer kann mit dem System von entfernten Terminals kommunizieren, die dazu ausgelegt sind, auf Kommunikationsverbindungen zuzugreifen, und das System kann entfernte Terminals umfassen, die geeignet sind, eine entfernte Datenbank zu speichern. Das System schließt eine Datenbank ein, die Benutzerinformationen enthält. Auf die Datenbank wird mittels eines Validierungsverfahrens zugegriffen, um während interaktiver Geschäftstransaktionssitzungen Geschäftstransaktionen in einem interaktiven Online-Betrieb zwischen Benutzern zuzulassen, wobei eine Partei für die Transaktion gezielt von der anderen Partei ausgewählt wird. Das System erlaubt gleichzeitige interaktive Geschäftstransaktionssitzungen zwischen unterschiedlichen Benutzern.
ÜBERSICHT DER ERFINDUNG
Die vorliegende Erfindung stellt ein System nach Anspruch 1 zur Verfügung. Eine bevorzugte Ausführungsform der vorliegenden Erfindung stellt ein Zahlungssystem zur Verfügung, um einen ersten Internetanwender in die Lage zu versetzen, eine Zahlung an einen zweiten Internetanwender vorzunehmen, gewöhnlich für den Erwerb eines Informationsproduktes, das über das Internet lieferbar ist. Das Zahlungssystem stellt Karteninhaberkonten für den ersten und zweiten Internetanwender zur Verfügung. Wenn der zweite Benutzer das Informationsprodukt über das Internet an den ersten Benutzer schickt, macht der zweite Benutzer über das Internet auch eine Anfrage an einen Front-End-Teil des Zahlungssystems, wobei um Zahlung vom ersten Benutzer gebeten wird. Der Front-End-Teil des Zahlungssystems fragt den ersten Benutzer über das Internet, ob mit der Zahlung an den zweiten Benutzer fortgefahren werden soll. Wenn der erste Benutzer bestätigend antwortet, wird eine Gebühr vom ersten Benutzer aus dem Internet heraus erhoben; wenn jedoch der erste Benutzer negativ antwortet, wird dem ersten Benutzer das Informationsprodukt nicht in Rechnung gestellt. Das Zahlungssystem informiert den zweiten Benutzer bezüglich der Entscheidung des ersten Benutzers und bezahlt den zweiten Benutzer nach Einzug der Gebühren vom ersten Benutzer. Sicherheit wird beibehalten, indem Finanz- und Kreditinformationen über Karteninhaberkonten der Benutzer vom Front-End-Teil des Zahlungssystems getrennt sind und indem die Kontoidentifizierungsinformationen von der zugehörigen Email-Adresse getrennt sind.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Diese und andere Eigenschaften, Aspekte und Vorteile der vorliegenden Erfindung werden Bezug nehmend auf die folgende Beschreibung, die angefügten Ansprüche und die begleitenden Zeichnungen besser verstanden, wobei:
1 ein Blockdiagramm ist, welches die Beziehung zwischen einem Zahlungssystem einer ersten Ausführungsform der vorliegenden Erfindung und einem großen Netz veranschaulicht.
2 ein Blockdiagramm einer Hardwarekonfiguration für das Zahlungssystem von 1 ist.
3 ein Blockdiagramm der Programmanordnung für das Zahlungssystem von 1 ist;
4 ein Diagramm von Daten für ein Karteninhaberkonto zur Verwendung mit dem Zahlungssystem von 1 ist;
5 ein Flussdiagramm ist, das den Nachrichtenfluss für die Anfangsschritte einer Kapitaltransaktion unter Verwendung des Zahlungssystems von 1 darstellt;
6A–6P Diagramme der Datennachrichten sind, die in Verbindung mit dem Zahlungssystem von 1 verwendet werden;
7 ein Flussdiagramm ist, das den Nachrichtenfluss für eine Karteninhaberprüfungsanfrage unter Verwendung des Zahlungssystems von 1 zeigt;
8 ein Flussdiagramm ist, das den Nachrichtenfluss für eine Transferrückfrage-Anfrage und eine Antwort unter Verwendung des Zahlungssystems von 1 zeigt;
9 ein Flussdiagramm ist, das den Nachrichtenfluss für einen Zahlungsfehler unter Verwendung des Zahlungssystems von 1 zeigt;
10 ein Flussdiagramm ist, das den Nachrichtenfluss für eine Zahlungsmeldung unter Verwendung des Zahlungssystems von 1 zeigt;
11 ein Flussdiagramm ist, das den Nachrichtenfluss für einen Rückverrechnungsprozess unter Verwendung des Zahlungssystems von 1 zeigt;
12 ein Flussdiagramm ist, das den Nachrichtenfluss für einen Leistungs-Anfrageprozess unter Verwendung des Zahlungssystems von 1 zeigt; und
13 ein Nachrichtenflussdiagramm ist, das Mitteilungen für eine neue Kontotransaktion zwischen einem Benutzer und dem Zahlungssystem von 1 darstellt.
AUSFÜHRLICHE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
I. GESAMTSYSTEM
1 zeigt ein Blockdiagramm einer ersten Ausführungsform der vorliegenden Erfindung für ein Zahlungssystem 10. Das Zahlungssystem 10 wird in Bezug auf das Internet 12 gezeigt. Das Internet 12 ist ein großes, quasi-öffentliches Netz mit vielen Benutzern 14. Das Internet 12 ist von einem Typ, auf den die Benutzer 14 mit verschiedenen Mitteln, wie beispielsweise mit herkömmlichen kommerziellen Fernsprechsystemen, zugreifen können. Das Netz 12 stellt zahlreiche Dienstleistungen, wie Email oder World Wide Web (WWW), für seine Benutzer zur Verfügung.
Obgleich das Zahlungssystem 10 speziell für das Internet von Nutzen ist, kann es in Verbindung mit anderen Email-basierten Systemen mit einer Mehrzahl von Benutzern verwendet werden.
In der Ausführungsform von 1 möchte einer der Benutzer 14 (bezeichnet als Informationskäufer 20) ein Informationsprodukt 26 von einem anderen Benutzer (bezeichnet als Informationsverkäufer 28) erwerben. Der Informationsverkäufer 28 kann jeder Benutzer mit einem zu verkaufenden Informationsprodukt sein. Das Informationsprodukt 26 kann irgendein Objekt sein, das über das Internet 12 transferierbar ist. Das Informationsprodukt 26 kann eine Nachricht sein, ein Artikel, eine Autorenoriginalfassung, eine Komposition, ein Schriftstück, Musik, ein bildhaftes Werk, eine Zeichnung, eine Karikatur, eine Geschichte, ein Software-Programm, ein Rezept, Witze und so weiter. Der Informationsverkäufer 28 möchte eine Kopie des Informationsproduktes 26 an den Informationskäufer 20 zu einem Preis verkaufen. Der Preis kann ein angezeigter Verkaufspreis sein (angezeigt beispielsweise über das Internet, auf einem Anschlagbrett oder über andere Medien) oder kann ein ausgehandelter Preis sein (ausgehandelt beispielsweise über Email-Austausch). Obgleich das Beispiel von 1 nur einen Informationsverkäufer 28 und einen Informationskäufer 20 zeigt, erstreckt sich das Zahlungssystem 10 selbstverständlich derart, dass es mehrere Käufer von einem Verkäufer umfasst, mehrere Verkäufer an einen Käufer, und mehrere Verkäufer und mehrere Käufer. Auch kann ein Käufer oder ein Verkäufer eine Einzelperson, eine Firma oder eine Institution sein.
In 1 ist auch ein Finanztransaktionsabwicklungssystem 30 gezeigt. Das Finanztransaktionsabwicklungssystem 30 repräsentiert derzeit verfügbare kommerzielle Institutionen, die Kredite und andere Finanztransaktionen abwickeln. Beispielsweise kann das Finanztransaktionsabwicklungssystem 30 handelsübliche Kredikartenbearbeitungsinstitutionen repräsentieren (z.B. Visa, Master Card, Discover und so weiter). Das Finanztransaktionsabwicklungssystem 30 umfasst zwei Komponenten: einen Aussteller 32 und einen Bezieher 34. Der Aussteller 32 umfasst Banken oder andere Institutionen, die Kreditkarten an Personen herausgeben, regelmäßig Abrechnungen und Rechnungen an Kreditkartenbesitzer schicken und Zahlungen von den Kreditkartenbesitzern einziehen. Diese Funktionen werden nicht im Internet durchgeführt, sondern verwenden herkömmliche Postzustellung, autorisierte direkte Abhebungen von Bankkonten und so weiter. Das Zahlungssystem 10 der vorliegenden Ausführungsform benutzt diese handelsüblichen Aussteller 32, um Benutzern eine Rechnung zu stellen und eine Zahlung von Benutzern für ihre Transaktionen im Internet 12 unter Verwendung des Zahlungssystems 10 einzuziehen. Beispielsweise würden Transaktionen eines Benutzers unter Verwendung des Internets auf der Kreditkartenabrechnung des Benutzers als eine Gebühr vom Zahlungssystem 10 auftauchen, obgleich einzelne Transaktionen unter Verwendung des Zahlungssystems 10 im Internet 12 auf der Kreditkartenabrechnung möglicherweise nicht ausdrücklich aufgelistet sind. Das Finanztransaktionsabwicklungssystem 30 schließt auch die Bezieherkomponente 34 ein. Diese Bezieherkomponente 34 ist eine Bank oder andere Institution, die dem Zahlungssystem 10 ein Handelskonto zur Verfügung stellt. Das dem Zahlungssystem 10 zur Verfügung gestellte Handelskonto ist ähnlich oder identisch wie die herkömmlichen Händlerkonten, die anderen Unternehmen zur Verfügung gestellt werden. Mittels des Händlerkontos leitet das Zahlungssystem 10 Benutzergebühren an die Bezieherkomponente 34, wodurch Benutzergebühren in ein konventionelles, handelsübliches Abwicklungssystem gebracht werden. Wie oben erwähnt bearbeitet der Bezieher 34 die vom Zahlungssystem empfangenen Benutzergebühren und leitet diese Informationen an die Ausstellerkomponente 32 für die Vorbereitung und das Senden von monatlichen Abrechnungen und Rechnungen an Benutzer und für das Einziehen von Zahlungen von Benutzern.
2 ist ein Blockdiagramm, das eine mögliche Konfiguration von Hardwarekomponenten veranschaulicht, die benutzt werden, um das Zahlungssystem 10 von 1 zu implementieren. Das Zahlungssystem 10 umfasst zwei Computer: einen Front-End-Computer 50 und einen Back-End-Computer 52. Der Front-End-Computer 50 und der Back-End-Computer 52 sind über ein privates Netz 53 miteinander verbunden. In einer bevorzugten Ausführungsform ist das private Netz ein Ethernet. Der Front-End-Computer 50 umfasst eine Front-End-Systemplatine 54, die assoziiert ist mit einem Front-End-Speicher 56, mit einer Speichervorrichtung 58, wie beispielsweise einem Festplattenlaufwerk, mit einem Back-Up-Magnetbandlaufwerk 60, mit einem Laufwerk für entfernbare Medien 62, mit einem Monitor 64 und mit einer Spannungsversorgung 66. Der Front-End-Computer 50 ist mittels einer T1 Standleitung 69 an das Internet 12 angeschlossen.
Der Back-End-Computer 52 umfasst eine Back-End-Computersystemplatine 68, die assoziiert ist mit einem Back-End-Computerspeicher 70, mit einer Back-End-Computerspeichervorrichtung 72, wie beispielsweise einem Festplattenlaufwerk, mit einem Back-Up-Magnetbandlaufwerk 74, mit einem Laufwerk für entfernbare Medien 76, mit einem Monitor 78 und mit einer Spannungsversorgung 80. Der Back-End-Computer 52 ist mittels eines Ethernet-Kabels an den Front-End-Computer 50 angeschlossen. Der Back-End-Computer 52 weist auch ein Novell LAN 81 auf, das eine Kommunikationsverbindung zum Abwicklungssystem 30 zur Verfügung stellt.
Sowohl der Front-End-Computer 50 als auch der Back-End-Computer 52 in dieser Ausführungsform sind vorzugsweise handelsübliche Sun Microsystems SS1000 Computer. Vorzugsweise sind der Front-End-Computer 50 und der Back-End-Computer 52 mit einem 64 MB Speicher ausgerüstet. Das dedizierte private Netz ist ein Ethernet und umfasst einen SBus Host Adapter. Der Kommunikations-Server ist ein Sun Microsystems SPARCserver 1000. Sowohl der Front-End-Monitor 64 als auch der Back-End-Monitor 78 sind handelsübliche Sun 17'' Monitore. Die Front-End- und Back-End-Magnetbandlaufwerke sind Python 5GB Magnetbandlaufwerke, die von Sony Inc. erhältliches 4mm Band verwenden. Das Front-End-Laufwerk 58 und das Back-End-Laufwerk 72 sind handelsübliche Seagate 1.7GB Laufwerke. Der Host-Adapter ist ein Sun Microsystems SBus Host Adapter. Der Netzwerk-Server ist ein handelsübliches Sun Microsystems SSarray 101.
Auf 3 bezugnehmend, führt der Front-End-Computer 50 ein Front-End-Programm 90 aus. Das Front-End-Programm 90 ist ein Software-Programm, das für eine Kommunikation mit Benutzern 14 auf dem Internet 12 sorgt. Das Front-End-Programm 90 umfasst einige Module, die von Internetbenutzern 14 aufgerufen und verwendet werden können. Die Module, die auf dem Front-End-Programm enthalten sind, umfassen Module, die es Benutzern 14 ermöglichen, eine Kapitaltransfer-Transaktion 91 durchzuführen, einen Bezieher-Status 92 zu überprüfen, sich als Bezieher 93 zu registrieren, etc..
Der Back-End-Computer 52 führt ein Back-End-Programm 92 aus. So ist das Front-End-Programm 90 physikalisch getrennt und isoliert vom Back-End-Programm 92. Das Back-End-Programm 92 erhält Informationen vom und schickt Informationen zum Front-End-Programm 90 nur mittels Stapelverarbeitung. Dies ergibt eine in sich selbst sichere Methode einer Kommunikation zwischen dem öffentlich zugänglichen Teil des Zahlungssystems, d.h. dem Front-End-Computer 50, und dem sicheren Teil des Zahlungssystems, d.h. dem Back-End-Computer 52.
II. ANFORDERUNGEN EINES BEZIEHERS
Um das Zahlungssystem 10 für Transaktionen zu verwenden, müssen sowohl der Informationskäufer 20 als auch der Informationsverkäufer 28 Bezieher- oder Karteninhaberkonten bei dem Zahlungssystem 10 haben. Als Bezieher können Internetbenutzer 12 kommerzielle Transaktionen miteinander durchführen, wie beispielsweise Bezahlung für Informationsprodukte 26, Leisten von wohltätigen Beiträgen, etc..
Bezugnehmend auf 4 umfasst ein Karteninhaberkonto 100 mindestens die folgenden Informationen: eine Kartennummer 102, eine Internet-Email-Adresse 104, einen Status 106, eine Einzahlungswahl 108, eine Auszahlungswahl 110 und eine Währungspräferenz 112. Jedes dieser Objekte wird unten erklärt.
Die Kartennummer 102 identifiziert eindeutig das Karteninhaberkonto 100. Die Kartennummer 102 ist eine alphanumerische Zeichenkette, die leicht von einem Menschen getippt und gelesen wird. Auch ist die Kartennummer 102 verhältnismäßig schwer zu erraten und weist keine ableitbare Beziehung auf zu irgendeinem Finanzprodukt, wie beispielsweise einer Kreditkartennummer oder einer Bankkontonummer, noch zu irgendeiner Email-Adresse.
Die Karteninhaber-Internet-Email-Adresse 104 ist die Email-Adresse des Karten inhabers, die für jeden Internetbenutzer eindeutig ist.
Der Status 106 ist entweder „aktiv", „hängend" oder „ungültig".
Die Einzahlungswahl 108 ist die Art, wie der Karteninhaber Kapital an das Zahlungssystem 10 transferiert, d.h. eine Zahlung leistet. Gewöhnlich kann dies getan werden, indem eine herkömmliche Berechtigung verwendet wird, eine Kreditkarte zu belasten. Die Einzahlungswahl ist nicht in der Kartennummer kodiert oder direkt aus ihr ableitbar.
Die Auszahlungswahl 110 ist die Art, wie das Zahlungssystem 10 Kapital an den Karteninhaber transferiert, d.h. zahlt. Dies kann den Gebrauch eines direkten Anlagebankkontos etc. umfassen. Die Auszahlungswahl 110 ist nicht in der Kartennummer kodiert oder direkt aus ihr ableitbar.
Die Währungspräferenz 112 ist die für die Einzahlungswahl 108 und Auszahlungswahl 110 zwischen dem Zahlungssystem 10 und dem Bezieher verwendete Landeswährung.
Bezieherkontoinformationen sind im Zahlungssystem 10 verteilt. Wieder auf 3 verweisend, befindet sich nur ein Teil der Bezieherkontoinformationen auf dem Front-End-Computer 50, wo er durch das Front-End-Programm 90 zugänglich ist. Jedoch befindet sich eine vollständige Kopie der gesamten Karteninhaberkontoinformationen auf dem Back-End-Computer 52, wo sie durch das Back-End-Programm 92 zugänglich ist. Auf dem Back-End-Computer 52 enthalten ist eine Kopie des Teils der Karteninhaberinformationen auf dem Front-End-Computer 50. Insbesondere befindet sich der Teil der Bezieherkontoinformationen, der sich auf dem Front-End-Computer 50 befindet, in einer auf der Front-End-Computerspeichervorrichtung 58 gespeicherten Datei 113. Die Bezieherkontoinformationen, die sich auf dem Back-End-Computer 52 befinden, befinden sich in einer auf der Back-End-Computerspeichervorrichtung 72 gespeicherten Datei 114.
Insbesondere hinsichtlich der Informationsobjekte in einem Karteninhaberkonto befindet sich auf der mit dem Front-End-Computer 50 assoziierten Speichervorrichtung 58 der Teil der Bezieherkontoinformationen 106, welcher die Bezieherkontonummer 102, die Internet-Email-Adressinformationen 104, den Status 106 und die Währungspräferenz 112 umfasst. Jedoch enthält der Front-End-Computer 50 keine Einzahlungs- 108 oder Auszahlungsinformationen 110, wie beispielsweise mit irgendeinem der Bezieher assoziierte Kreditkarteninformationen. Kreditkarten- oder andere Zahlungsinformationen befinden sich nur in der Datei 114 auf der Speichervorrichtung 72 des Back-End-Computers 52.
Um das Front-End-Programm 90 über das Internet aufzurufen, können Benutzer 14 ein Benutzerschnittstellen-Software-Programm 118 verwenden, das auf ihrem eigenen Computer für interaktiven Zugriff laufen gelassen werden kann, oder alternativ können Benutzer 14 über herkömmliche Email-Programme das Zahlungssystem 90 für Speicher- und Vermittlungszugriff in Anspruch nehmen. Die Programme 90 und 118 können in irgendeiner geeigneten Programmiersprache geschrieben sein, wie beispielsweise in Tcl oder C. Die Software-Module können mit dem Betriebssystem UNIX, DOS verwendet werden und können auf viele andere Betriebssystemen übertragen werden. Eine Veröffentlichung mit dem Titel „The application/green-commerce MIME Content-type" umfasst ein Format für eine Internet-Kommunikation zum Gebrauch zwischen Internetbenutzern und dem Zahlungssystem 10.
III. ARBEITSWEISEN DES ZAHLUNGSSYSTEMS
Wie oben erwähnt stellt das Zahlungssystem 10 Internetbenutzern eine Vielzahl von Dienstleistungen und Funktionen zur Verfügung, einschließlich des Ausführens einer Kapitaltransfer-Transaktion, der Validierung des Status eines Beziehers und des Registrierens als Bezieher. Mehrere dieser Dienstleistungen und Funktionen sind unten beschrieben.
A. Kapitaltransfer-Transaktion
Eine Kapitaltransfer-Transaktion findet statt, wenn ein Internetanwender, der ein Bezieher ist, d.h. der ein Karteninhaberkonto auf dem Zahlungssystem 10 hat, als ein Informationsverkäufer 28 tätig ist und eine Zahlung von einem anderen Karteninhaber anfordert, der als ein Informationskäufer 20 tätig ist. Gewöhnlich kann dies eintreten, wenn ein Käufer 20 ein Informationsprodukt 26 über das Internet 12 erwirbt. Jedoch kann diese Transaktion auch aus anderen Gründen erfolgen, beispielsweise um karitative Beiträge zu leisten, um für Computer- oder Software-Kundenbetreuung zu zahlen etc..
Zwecks des unten beschriebenen Beispiels, wird angenommen, dass der Käufer 20 bereits Kenntnis davon hat, dass der Verkäufer 28 ein Informationsprodukt 26 zu verkaufen hat und dass ein Preis festgesetzt worden ist. Der Käufer 20 kann vom Verkäufer 28 und seinem Informationsprodukt Kenntnis haben über Werbung im Internet oder anderen Medien, durch Andere, von einem Anschlagbrett, von einem Produktlager im Internet oder irgendwie anders. Der Käufer 20 kennt ein Mittel, um mit dem Verkäufer über das Internet in Verbindung zu treten. Der Käufer 20 kann mit dem Verkäufer 28 durch Senden einer Nachricht an die Internetadresse des Verkäufers oder durch ein interaktives Protokoll, das World Wide Web (WWW), FTP, etc. in Verbindung treten, so dass eine Nachricht an den Verkäufer 28 geschickt werden kann. Die Mittel, um mit dem Verkäufer in Verbindung zu treten, können in der Werbung etc. enthalten sein.
5 zeigt einen Anfangsteil des Nachrichtenflusses für eine Kapitaltransfer-Transaktion entsprechend der ersten Ausführungsform der vorliegenden Erfindung. Der Internetanwender, welcher der Käufer 20 ist, schickt über das Internet 12 eine Nachricht 128 zum (oder verständigt ansonsten mittels interaktiver Protokolle, WWW etc. den) Internetanwender, welcher der Verkäufer 28 ist. Die vom Käufer 20 an den Verkäufer 28 geschickte Benachrichtigung 128 umfasst die Kartennummer des Käufers 102B („102B" = Kartennummer „102" + Käufer „B"), wie in 6A veranschaulicht. Die Nachricht 128 des Käufers ist der erste Schritt beim Einleiten der Kapitaltransfer-Transaktion unter Verwendung des Zahlungssystems 10. Alternativ kann der Käufer 20 die Kartennummer 102B als Benutzernamen in einer Datei einbinden, die vom Käufer 20 zum Verkäufer 28 unter Verwendung des Internets 12 transferiert wird.
B. Überprüfungs-Transaktionen
In diesem Stadium wünscht der Verkäufer 28 vielleicht, mit dem Zahlungssystem 10 zu kommunizieren, damit eine Kartennummer-Überprüfungs-Transaktion an der Karteninhabernummer des Käufers durchgeführt wird. Eine Kartennummer- Überprüfungs-Transaktion geschieht, wenn ein Karteninhaber wünscht, den Status 106 eines anderen Karteninhaberkontos zu ermitteln. Gewöhnlich findet eine Kartennummer-Überprüfungs-Transaktion statt, wenn ein als Verkäufer agierender Karteninhaber entscheidet, ob er ein Informationsprodukt 26 einem anderen Karteninhaber schickt, der behauptet ein Karteninhaber zu sein und der daran interessiert ist, das Informationsprodukt vom Verkäufer 28 zu erwerben.
Bezugnehmend auf 7 kann der Verkäufer 28 eine Überprüfungsanfrage-Nachricht 216, welche die Kartennummer des Käufer 102B enthält, unter Verwendung des Internets 12 zum Front-End-Programm 90 senden. Wie in 6B gezeigt, enthält die Überprüfungsanfrage-Nachricht 216 zumindest die Kartennummer des Käufer 102B. Als Antwort sendet das Front-End-Programm 90 dem Verkäufer 28 eine Überprüfungsergebnis-Nachricht 218. Wie in 6C gezeigt, enthält die Überprüfungsergebnis-Nachricht 218 die Kartennummer des Käufer 102B und den zum Konto des Käufers gehörigen Status 106B. Wenn der Karteninhaberkontostatus des Käufers 106B „aktiv" ist, ist der Käufer vermutlich gut angesehen und der Verkäufer 28 kann mit der Transaktion fortfahren, indem er dem Käufer 20 das Informationsprodukt 26 über das Internet schickt. Wenn der Karteninhaberkontostatus des Käufer 106B „ungültig" ist, weiß der Verkäufer 28, dass das Konto nicht gut ist, und dass Kapitaltransfer-Transaktionen durch dieses Konto nicht abgewickelt werden können. Wenn der Karteninhaberkontostatus 106B des Käufers „hängend" ist, weiß der Verkäufer, dass der Käufer 20 jüngsten Transaktionsversuchen nicht nachgekommen ist. Der Verkäufer 28 kann dennoch entscheiden, das Informationsprodukt 26 dem Käufer 20 zu schicken und eine Kapitaltransfer-Transaktion wird durchgeführt. Jedoch wird keine Zahlungsgarantie gegeben.
Obgleich ein Informationsverkäufer 28 es vorziehen kann, vor dem Senden eines Informationsproduktes an den Käufer 20 eine Überprüfungsanfrage 216 zum Zahlungssystem 10 zu senden, kann der Verkäufer 28 es vorziehen, den Überprüfungsanfrageschritt zu überspringen.
In diesem Stadium schickt der Verkäufer 28 dem Käufer 20 das Informationsprodukt 26 über das Internet.
Kapitaltransfer-Transaktion (Fortsetzung)
Wieder auf 5 bezugnehmend, sendet der Verkäufer 28 eine Transfer-Anfrage-Nachricht 129 über das Internet 12 zum Zahlungssystem 10 zu annähernd der gleichen Zeit, zu der der Verkäufer 28 dem Käufer 20 das Informationsprodukt über das Internet schickt. Insbesondere sendet der Verkäufer 28 die Transferanfrage-Nachricht 129 zum Front-End-Programm 90 auf dem Front-End-Computer 50. Die Transferanfrage-Nachricht 129 kann entweder durch Email oder durch Verwendung eines interaktiven Protokolls auf dem Internet 12 gesendet werden. Auf 6D bezugnehmend, enthält die Transferanfrage-Nachricht 129 die folgenden Informationen: die Käuferkartennummer 102B, die Verkäuferkartennummer 102S, einen Transfer-Typ 130 (beispielsweise den Verkauf von Informationen), eine Textbeschreibung 132 der Transaktion, einen Transferbetrag 134, die Währung 112S (beispielsweise USD) und optional die Transaktionskennung 136 des Händlers.
Nachdem die Transferanfrage-Nachricht 129 empfangen wurde, fragt das Front-End- Programm 90 den Käufer 20, ob der Käufer 20 die Zahlung für die Transaktion 132 zum Verkäufer 28 autorisieren möchte. Insbesondere sendet das Front-End-Programm 90 eine Transferrückfrage-Nachricht 140 zum Käufer 20, wie in 8 gezeigt. Unter Verwendung der Informationen, die in der Transferanfrage-Nachricht 129 vom Verkäufer 28 enthalten sind, speziell die Kartennummer des Käufer 102B und die Kartennummer des Verkäufers 102S, schlägt das Front-End-Programm 90 den Namen 103B des Käufer und den Namen 103S des Verkäufers nach. Wie in 6E gezeigt, umfasst die Transferrückfrage-Nachricht 140: eine Transaktionskennung 142, die durch das Front-End-Programm 90 eindeutig generiert ist, den Namen 103B des Käufers, den Namen 103S des Verkäufers, den Transfer-Typ 130, die Textbeschreibung der Transaktion 132 und einen Transferbetrag 135 in der dem Karteninhaberkonto des Käufer zugehörigen Währungspräferenz 112B (was einen Währungsumtausch des Transaktionsbetrags 134 in die Währungspräferenz 112B des Käufers darstellen kann und ferner den Transferbetrag in Bezug auf Währungsschwankungen in der vom Käufer verwendeten Währung festlegt). Wenn ein Währungsnennwertumtausch stattfand, sind zusätzlich die Originalwährung 112S und der Betrag 134 in der Nachricht 140 vermerkt. In der Transferrückfrage-Nachricht 140 werden der Name 103B des Käufer und der Name 103S des Verkäufers anstelle der Kartennummer 102B des Käufer und der Kartennummer 102S des Verkäufers verwendet, um die Übermittlung der Kartennummerninformationen über das Internet zu minimieren, wodurch die Sicherheit des Systems verbessert wird. Nach dem Senden der Transferrückfrage-Nachricht 140 wartet das Front-End-Programm 90 auf eine Antwort vom Käufer 20.
Der Käufer 20 kann antworten, indem er eine Transferantwort-Nachricht 150 über das Internet zum Front-End-Computer 50 sendet, wie in 8 gezeigt ist. Wie in 6F veranschaulicht, enthält die Transferantwort-Nachricht 150 die folgenden Daten: die vom Zahlungssystem erzeugte Transaktionskennung 142 und eine Meldung 152 der Bereitschaft des Käufer, Kapitaltransfer zuzulassen. Die Bereitschaftsmeldung 152 ist entweder "ja", „nein" oder „Betrug".
In einer bevorzugten Ausführungsform erleichtert die Struktur der Transferrückfrage-Nachricht 140 die Vorbereitung der Transferantwort-Nachricht 150 durch den Käufer 20. In der Transferrückfrage-Nachricht 140 wird die Transaktionskennung 142 in das „Betreff" der Transferrückfrage-Nachricht 140 gesetzt und die Email-Adresse, an welche die Transferantwort-Nachricht 150 des Käufer geschickt werden sollte (z.B. „response@card.com"), wird in die „Adresse des Absenders" der Transferrückfrage-Nachricht 140 gesetzt. Viele herkömmliche Email-Programme, die im Internet verwendet werden, einschließlich vieler älterer Programme, haben ein Feature, das automatisch das „Betreff" und die „Adresse des Absenders" einer empfangenen Nachricht liest und eine Antwortnachricht formatiert, die an die Adresse des Absenders mit dem gleichen „Betreff" wie die empfangene Nachricht gerichtet ist. Wenn der Käufer 20 dieses gebräuchliche Feature verwendet, um seine Transferantwort-Nachricht 150 zurück an das Zahlungssystem 10 zu senden, ist die einzige Information, die der Käufer 20 hinzufügen muss, die Bereitschaftsmeldung 152, die nur eine aus einem Wort bestehende Rückmeldung ist (d.h. "ja", „nein" oder „Betrug").
Wieder unter Bezugnahme auf 8, schickt das Front-End-Programm 90 dem Verkäufer 28 dann über das Internet 12 eine Transferergebnis-Nachricht 160, wenn der Käufer 20 in der Bereitschaftsmeldung 152 "ja" anzeigt. Wie in 6G dargestellt, enthält die Transferergebnis-Nachricht 160 die folgenden Informationen: die Transaktionskennung 142, den Namen 103S des Verkäufers, den Namen 103B des Käufers, den Transfer-Typ 130, die Textbeschreibung der Transaktion 132, den Transferbetrag 135 in der mit dem Karteninhaberkonto des Käufers assoziierten Währung 112B, die Meldung 152 der Bereitschaft des Käufers, Kapitaltransfer zu erlauben, und die Transaktionskennung 136 des Verkäufers, wenn sie in der Ursprungstransferanfrage-Nachricht 129 vorliegt. Zusätzlich werden, wenn ein Währungsnennwertumtausch stattfand, die ursprüngliche Währung 112S und der Betrag 134 in der Transferergebnis-Nachricht 160 vermerkt. Das Front-End-Programm 90 übermittelt die Transaktionsinformationen per Stapelverarbeitung an das Back-End-Programm 92, das die Transaktionsinformationen zu einer Abwicklungswarteschlange 168 hinzufügt. Die Abwicklungswarteschlange 168 ist eine Datei, die auf der Speichervorrichtung 72 des Back-End-Computers 52 gelegen ist.
Zurück auf den Schritt in 8 verweisend, wo der Käufer 20 die Transferantwort-Nachricht 150 zurück zu dem Zahlungssystem 10 sendet, sendet das Front-End-Programm 90 dem Verkäufer 28 ein Transferergebnis 160 mit einer „nein" Meldung 152, wenn der Käufer 20 „nein" in der Bereitschaftsmeldung 152 anzeigt. Zusätzlich kann eine Bearbeitungsgebühr für den Käufer 20 erhoben werden. Informationen bezüglich der „nein" Erwiderung des Käufers in der Transferantwort 150 werden vom Front-End-Programm 90 zum Back-End-Programm 92 stapelweise verarbeitet, wo Bearbeitungsgebühren der Abwicklungswarteschlange 168 für den Käufer 20 hinzugefügt werden können. Ferner, wenn eine „nein" Meldung mehr als eine bestimmte Anzahl an Malen in einer bestimmten Anzahl von Transaktionen über einen bestimmten Zeitabschnitt erhalten ist, dann wird der Status 106B des Käuferkontos 100B „hängend". Dies geschieht, um einen Benutzer daran zu hindern, ein Bestellen und Empfangen von Informationsprodukten zu praktizieren, ohne für sie zu bezahlen. Wenn der Käuferkontostatus 106B hängend wird, werden diese Informationen auch per Stapelverarbeitung vom Front-End-Programm 90 an das Back-End-Programm 92 übermittelt, damit die Karteninhaberkontoinformationen auf dem Back-End-Computer 52 mit denen auf dem Front-End-Computer 50 übereinstimmen.
Wieder zurück auf den Schritt in 8 verweisend, wo der Käufer 20 die Transferantwort-Nachricht 150 zurück zum Zahlungssystem 10 sendet, ändert das Zahlungssystem 10 den Status 106B des Karteninhaberkontos 100B des Käufers zu „ungültig", wenn der Käufer 20 „Betrug" in der Bereitschaftsmeldung 152 anzeigt. Eine Antwort von Betrug zeigt an, dass der Käufer 20 das Informationsprodukt 26 nie anforderte. Die Information, dass der Käufer 20 mit „Betrug" auf die Bereitschaftsmeldung 152 antwortete, wird auch per Stapelverarbeitung vom Front-End-Programm 90 zum Back-End-Programm 92 übermittelt, so dass die Karteninhaberkontoinformationen auf dem Back-End-Computer 52 mit denen auf dem Front-End-Computer 50 übereinstimmen.
Unter Verweis zurück zu dem in 8 veranschaulichten Schritt, wo das Front-End-Programm 90 die Transferrückfrage-Nachricht 140 an den Käufer 20 sendet, sendet das Front-End-Programm erneut die Transferrückfrage-Nachricht 140, d.h. eine zweite Nachricht, wenn eine Zeitspanne abläuft und das Front-End-Programm 90 keine Transferantwort-Nachricht 150 vom Käufer 20 empfängt. Das Front-End-Programm 90 kann die Transferrückfrage-Nachricht mehrmals zum Käufer 20 senden, bis eine Antwort vom Käufer 20 erhalten wurde. Wenn mehr als eine bestimmte Anzahl an Tagen abläuft oder mehr als eine bestimmte Anzahl an Transferrückfrage-Nachrichten 140 für den Käufer 20 ausstehen und das Front-End-Programm keine Transferantwort-Nachricht 150 vom Käufer 20 erhält, dann veranlasst das Front-End-Programm 90, dass das Karteninhaberkonto 100B des Käufers hängend wird. Dies geschieht, indem der Karteninhaberstatus 106B des Käufers von „aktiv" nach „hängend" geändert wird. Wenn eine Transferantwort 150 empfangen wird und/oder die Anzahl der ausstehenden Transferrückfrage-Nachrichten 140 für den Käufer 20 auf weniger als einen bestimmten Schwellwert fällt, kann das Konto 100B des Käufer jedoch in einen „aktiv" Status zurückgebracht werden. Außerdem können irgendwelche ausstehenden Transferrückfrage-Nachrichten 140 einige Zeit später erneut gesendet werden.
C. Kumulierung und Abwicklung von Transaktionen
1. Bearbeitungsgebühren für Käufer
Die Verarbeitung der Gebühren und der Gutschriften zwischen dem Back-End-Computer 52 und dem Abwicklungssystem 30 wird weg vom Internet unter Verwendung von sicheren Kommunikationskanälen geleitet. Dies isoliert die Käufer-Verkäufer-Aktivität, die im Internet stattfindet, von der Finanz- und Kredit-Aktivität, die weg vom Internet stattfindet.
Auf 1 und 3 bezugnehmend, überprüft das Back-End-Programm 92 regelmäßig die kumulierten Kauftransaktionen für jeden Karteninhaber in der Abwicklungswarteschlange 168 auf Alter und Betrag. Beispielsweise überprüft das Back-End-Programm 92, ob die kumulierten Kauftransaktionen für einen Karteninhaber entweder 30 Tage alt sind oder einen Schwellwert von mindestens $10,00 erreichen. Wenn die kumulierten Kauftransaktionen für einen Karteninhaber entweder das Alter oder den Schwellwert erreichen, verarbeitet das Back-End-Programm 92 die kumulierten Transaktionen stapelweise in einer einzigen Kapitaltransfer-Transaktion unter Verwendung der Einzahlungswahl 108B, die mit dem Karteninhaberkonto 100B des Käufers assoziiert ist. Dieses wird gewöhnlich durchgeführt, indem dem Käuferkreditkartenkonto eine Gebühr 194 berechnet wird. Um eine Gebühr auf dem Käuferkreditkartenkonto zu berechnen, übermittelt das Back-End-Programm 92 dem Kreditkartensystemnetzwerk 30 eine kumulierte Gebühr 194 über die Bezieherkomponente 34, wo das Zahlungssystem 10 ein herkömmliches Handelskonto beibehält. Das Kreditkartennetzwerk umfasst eine Komponente 196, die zuerst die Gültigkeit der Kreditkartennummer des Käufers überprüft, beispielsweise eine Einzahlungswahl 108B, um festzustellen, ob die Kreditkarte verloren, gestohlen, abgelaufen, überzogen etc. ist.
Wenn das Kreditkartennetz 30 es ablehnt, die Kreditkartennummer des Käufers zu verarbeiten, wenn die Kreditkarte beispielsweise verloren, gestohlen, annulliert, abgelaufen etc. ist, dann gilt der Einzug vom Käufer als fehlgeschlagen. Das Back-End-Programm 92 ändert den Karteninhaberstatus 106B des Käufers in „hängend". Das Back-End-Programm 92 sendet die Fehlerinformation auch per Stapel verarbeitung zum Front-End-Programm 90, damit der Karteninhaberstatus 106B des Käufers auf dem Front-End-Computer 50 ebenfalls in „hängend" geändert wird.
Auf 9 bezugnehmend, schickt das Front-End-Programm 90 dann eine Einzahlungsfehlermeldungs-Nachricht 210 über das Internet zum Käufer 20. Wie in 6H gezeigt, enthält die Einzahlungsfehlermeldungs-Nachricht 210, die mit der Einzahlungsmethode 108 assoziierte Meldungskennung 144, den Transferbetrag 134 und die Währung 112S.
Zusätzlich schickt das Front-End-Programm 90 für jede mit der Einzahlungsfehlermeldungs-Nachricht 210 assoziierte Transaktion auch eine Einzugsfehlermeldungs-Nachricht 211 an den Verkäufer 28 über das Internet. Wie in 6I dargestellt, enthält diese Einzugsfehlermeldungs-Nachricht 211 die Transaktionskennung 138 des Servers und den mit der Transaktion assoziierten Betrag 134 und die Währung 112.
Zurück auf den Schritt verweisend, bei dem das Back-End-Programm 92 die kumulierten Gebühren 194 an das Kreditkartennetz 30 übermittelt, verarbeitet der Bezieher 34 dann die kumulierten Gebühren 194 im Kreditkartensystem 30, um die Gebühren auf der Käuferkreditkarte in der üblichen Weise durch Senden der entsprechenden Informationen an den Käuferkreditkartenaussteller 32 zu verbuchen, wenn das Kreditkartennetz 30 die Karte des Käufers akzeptiert. Der Käuferkreditkartenaussteller 32 schickt dem Käufer 20 üblicherweise eine Kreditkartenrechnung 190 über das Postwesen. Die Kreditkartenrechnung 190 führt die kumulierten Gebühren 194 als einen Buchungsposten auf der Benutzerkreditkartenrechnung auf. Da die kumulierten Gebühren 194 für einen Karteninhaber an den Bezieher 34 gesendet werden, wenn sie einen bestimmten Schwellwertbetrag erreichen, können mehr als eine kumulierte Gebühr auf der Kreditkartenrechnung verzeichnet sein, die dem Käufer 20 durch den Käuferkreditkartenaussteller 32 geschickt wird.
Die zuvor dargelegte Beschreibung erklärt, wie das Zahlungssystem eine Gebühr an den Benutzer unter Verwendung des herkömmlichen, handelsüblichen Kreditkartensystems verarbeiten kann. Es gibt Variationen und Modifikationen der zuvor dargelegten Anordnung, die genutzt werden können. Beispielsweise kann der Aussteller 32 eine Lastschrift an ein Bankkonto des Käufers 20 ausführen, anstatt eine Kreditkartenrechnung zu senden. Alternativ kann der Aussteller 32 dem Käufer eine Rechnung (eine andere als eine Kreditkartenrechnung) für die kumulierten Gebühren schicken.
Zurück auf den Schritt verweisend, bei dem das Back-End-Programm 92 die kumulierten Gebühren 194 zum Kreditkartensystem 30 schickt, sendet das Back-End-Programm 92 via Stapelverarbeitung eine Meldung über diese Akzeptanz an das Front-End-Programm 90, wenn das Kreditkartensystem 30 die Kreditkartennummer des Käufers akzeptiert. Das Front-End-Programm 90 schickt dem Käufer 20 eine Einzahlungsmeldungs-Nachricht 212 über das Internet, wie in 10 gezeigt. Wie in 6J gezeigt, umfasst die Einzahlungsmeldungs-Nachricht 212 die Kartennummer 102, den Einzahlungsbetrag 134 in der mit dem Konto des Käufers assoziierten Währung 112, die mit der Einzahlungsmethode 108 assoziierte Meldungskennung 144, eine Liste kumulierter Transaktionen 146 und optional eine Bearbeitungsgebühr 148.
2. Verarbeitung von Zahlungen an Verkäufer
Auf 10 bezugnehmend, behandelt das Back-End-Programm 92 die Zahlung als vom Käufer geleistet, wenn das Kreditkartensystem 30 die kumulierte Transaktion 194 vom Back-End-Programm 92 akzeptiert. Das Back-End-Programm 92 berechnet Kosten, die mit der Transaktion verbunden sind. Beispielsweise zieht das Back-End-Programm die durch das Kreditkartensystem 30 angewandte Gebühr von dem Betrag ab, der vom Käufer gezahlt wird. Das Back-End-Programm 92 zieht auch eine Bearbeitungsgebühr für das Zahlungssystem 10 ab. Das Back-End-Programm 92 berechnet dem Verkäufer dann eine Nettoabrechnung für die Transaktion. Die Nettoabrechnung wird zur auf dem Back-End-Computer 52 gelegenen Abwicklungswarteschlange 168 für den Verkäufer 28 gebucht.
Das Back-End-Programm 92 überprüft regelmäßig die Abwicklungswarteschlange 168, um zu sehen, ob Zahlungen für den Verkäufer 28 kumuliert sind. Regelmäßig verarbeitet das Back-End-Programm 92 stapelweise die kumulierten Zahlungstransaktionen in einer einzelnen Off-Internet-Transaktion unter Verwendung der mit dem Konto 100S des Verkäufers assoziierten Auszahlungsmethode 110S. In einer bevorzugten Ausführungsform können Transaktionen, die sich für einen Verkäufer kumuliert haben, für einen Zeitraum zurückgehalten werden, bevor die einzelne Off-Internet-Zahlungstransaktion zum Verkäufer gemacht wird. Dieser Zeitraum kann abhängig vom Zahlungsverhalten des Verkäufers variieren. Beispielsweise kann eine Zahlung, die vom Kreditkartensystem 30 erhalten wird, für eine Dauer von 60 Tagen zurückgehalten werden, bevor sie mit anderen kumulierten Transaktionen kombiniert wird und dem Verkäufer mittels der vom Verkäufer angezeigten Off-Internet- Zahlungsmethode gezahlt wird.
Ein Weg, wie eine Zahlung an den Verkäufer geleistet werden kann, ist durch eine direkte Gutschrift zu einem Bankkonto, das vom Verkäufer beibehalten wird. Das Back-End-Programm 92 übermittelt dem Abwicklungssystem 30 Informationen 197, um eine direkte Gutschrift 198 zum Bankkonto 199 des Verkäufers vorzunehmen. Wenn die Bezieherkomponente 34 ein Kreditinstitut ist, kann die Back-End-Komponente 92 den Bezieher 34 dazu benutzen, die direkte Gutschrift-Informationen von der Bezieherbank zu der Bank des Verkäufers für eine direkte Gutschrift zum Bankkonto 199 des Verkäufers zu übermitteln.
Zusätzlich zum Senden der Informationen zum Abwicklungssystem 30, um eine Zahlung an den Verkäufer zu bewirken, beispielsweise indem eine direkte Gutschrift zum Bankkonto des Verkäufers gemacht wird, schickt das Back-End-Programm 92 auch Informationen via Stapelverarbeitung zum Front-End-Programm 90, dass eine kumulierte Zahlung an den Verkäufer eingeleitet worden ist. Das Front-End-Programm 90 sendet dann eine Nachricht über das Internet, die den Verkäufer 28 darüber informiert, dass eine Zahlung zum Konto des Verkäufers vorgenommen wurde. Das Front-End-Programm 90 schickt dann eine Auszahlungsmeldungs-Nachricht 214 zur mit dem Karteninhaberkonto des Verkäufers assoziierten Email-Adresse 104S. Wie in 6K gezeigt, enthält die Auszahlungsmeldungs-Nachricht 214 die Kartennummer 102S, den Auszahlungsbetrag 150 in der mit dem Konto des Karteninhabers assoziierten Währung 112, die mit der Auszahlungsmethode 110 assoziierte Meldungskennung 152, die Liste der kumulierten Transaktionen 146 und optional eine Bearbeitungsgebühr 149.
D. Rückzahlungs-Transaktionen
Eine Rückzahlungstransaktion findet statt, wenn ein mit einer vorhergehenden Einzahlungsmeldungs-Nachricht assoziierter Kapitaltransfer zu einer Rückzahlung führt. Typischerweise geschieht dies, wenn ein Käufer 20, dessen Einzahlungsmethode 108B eine Kreditkarte ist, eine Gebühr auf seiner Kreditkartenabrechnung anfechtet. 11 zeigt den Nachrichtenfluss für eine Rückzahlungs-Transaktion, welche die folgenden Schritte aufweist:
Das Front-End-Programm 90 sendet eine Einzahlungs-Rückzahlungsmeldungs-Nachricht 220 an den Käufer 20 über das Internet. Wie in 6L gezeigt, enthält die Einzahlungs-Rückzahlungsmeldungs-Nachricht 220 die mit der Einzahlungsmethode 108 assoziierte Meldungskennung 144 und den Einzahlungsbetrag 134 in der mit dem Konto 100 des Käufer assoziierten Währung 112.
Wie in 11 gezeigt, sendet das Front-End-Programm 90 auch für jede mit dieser Rückzahlung assoziierte kumulierte Transaktion eine Auszahlungs-Rückzahlungsmeldungs-Nachricht 222 zum Verkäufer 28 über das Internet. Wie in 6M gezeigt, enthält die Auszahlungs-Rückzahlungsmeldungs-Nachricht 212 die Transaktionskennung 138 des Servers, den Betrag 134 und die Währung 112 der Rückzahlung an den Käufer 20.
E. Zahlungssystem-Leistungs-Transaktion
Eine Zahlungssystem-Leistungs-Transaktion findet statt, wenn ein Benutzer die Leistungen eines Zahlungssystems 10 ermitteln möchte. 12 zeigt einen Nachrichtenfluss für eine Zahlungssystem-Leistungs-Transaktion, der folgende Schritte aufweist:
Ein Benutzer 14 verwendet das Internet 12, um eine Leistungsanfrage-Nachricht 224 zum Zahlungssystem 90 zu senden. Wie in 6N gezeigt, hat die Leistungsanfrage-Nachricht 224 keine speziellen Attribute, d.h. sie enthält keine speziellen Informationsfelder und kann nur eine Abfrage sein. Das Zahlungssystem 90 schickt dem Benutzer 14 eine Leistungsergebnis-Nachricht 226. Wie in 6O gezeigt, enthält die Leistungsergebnis-Nachricht 226 eine Liste von unterstützten Transaktionsarten und Parametern 156, eine Liste von unterstützten Währungen 158 und eine Liste von unterstützten Sprachen 159.
F. Karteninhaber-Antragstellung
Eine Karteninhaberantragstellungs-Transaktion findet statt, wenn ein Internetanwender 14 ein Karteninhaberkonto 100 einrichten möchte. 13 zeigt die Schritte für das Antragsstellungsverfahren für eine Karteninhaberantragsstellung.
Der Benutzer 14 sendet eine Antragsstellungsanfrage-Nachricht 227 über das Internet 12 zum Zahlungssystem 90. Dieser Antrag kann entweder mit elektronischer Post oder durch Verwenden eines interaktiven Protokolls gesendet werden. Das Zahlungssystem 90 sendet eine Antragsstellungsergebnis-Nachricht 228 zum Benutzer 14. Wie in 6P gezeigt, ist die Antragsstellungsergebnis-Nachricht 228 im Wesentlichen ein unausgefülltes Formular, in das der Benutzer folgende Informationen einträgt: Name des Antragstellers, Adresse, Telefonnummer, Internet-Email-Adresse 104 und die Währungspräferenz 112, die Sprache und die bevorzugte Kontokennung ID.
Der Benutzer 34 trägt Parameter in die Antragsstellungsergebnis-Nachricht 228 ein und sendet eine Neues-Konto-Anfrage-Nachricht 230 an das Zahlungssystem 10. Das Zahlungssystem 10 schickt dem Benutzer 14 eine Neues-Konto-Ergebnis-Nachricht 232. Wie in 6Q gezeigt, enthält die Neues-Konto-Ergebnis-Nachricht 232 den Status 106 der Antragsstellung und, wenn die Antragsstellung genehmigt ist, die dem Benutzer 14 zugewiesene Kartennummer 102.
Es wird angemerkt, dass Kreditkartennummern oder andere sensitive Informationen bezüglich Finanztransaktion nicht über das Internet gesendet werden. Der Benutzer, der ein Karteninhaberkonto eröffnen möchte, sendet nur einen Teil der benötigten Karteninhaberinformationen in der Neues-Konto-Anfrage-Nachricht über das Internet. Um das Karteninhaberantragsstellungsverfahren abzuschließen, stellt der Benutzer 14 seine Kreditkarteninformationen, Bankkontoinformationen oder andere finanzielle Informationen dem Zahlungssystem 10 über Nicht-Internet-Kanäle zur Verfügung. Diese Kreditkarteninformationen, Bankkontoinformationen oder anderen Finanzinformationen werden auf dem Back-End-Computer 52 des Zahlungssystems 10 in der sicheren Datei 114 geführt. Der Benutzer 14 ruft eine Telefonnummer 280 an. Dies kann eine 800er-Nummer in den USA oder in eine kostenpflichtige Nummer für Auslandsanrufe sein. Der Benutzer 14 wird aufgefordert, seine Kreditkarteninformationen 282 über eine Tastatur-Ton-Eingabe einzugeben. So werden die Kreditkarteninformationen des Benutzers nicht jedes Mal über das Internet übertragen, was zur Sicherheit des Systems beiträgt.
IV. VORTEILE DES ZAHLUNGSSYSTEMS
In der oben beschriebenen Ausführungsform der Erfindung wird ein neues Modell für Internethandel, bei dem ein Informationsverkäufer 28 das Risiko von Nicht-Bezahlung trägt, zur Verfügung gestellt. Durch die Verschiebung des Risikos von Nicht-Bezahlung vermeidet die Ausführungsform der vorliegenden Erfindung die Notwendigkeit von Kreditwürdigkeitsgarantien für Verkäufer. Dies erlaubt jedem teilnehmenden Internetbenutzer, sowohl Käufer als auch Verkäufer von Informationen im Internet zu sein. Jedoch wird angemerkt, dass verschiedene Aspekte des Modells (beispielsweise Bestätigung des Käufers, Begrenzung der Ablehnungen der Käufer, zu zahlen etc.) das Risiko eines Verkäufers bis zu dem Punkt herabsetzen, wo es durch die geschaffene erweiterte Handelbasis ausgeglichen ist.
Käufer von Informationsprodukten können häufig keine Kaufentscheidung treffen, wenn sie das Produkt nicht in der Hand haben. Angenommen, es gäbe praktisch keine Kosten für die Herstellung und Verteilung, dann müssten unerwünschte Informationsprodukte nicht „zurückgegeben" werden; es ist weniger teuer, das unerwünschte Informationsprodukt nur zu löschen. Käufer von Informationsprodukten zahlen nur für Informationen, die sie verwenden können, wobei die Enttäuschung bei der Rückgabe unerwünschter Waren und das Fragen nach einer Rückerstattung vermieden wäre, wie es bei einem herkömmlichen Marktplatz der Fall ist.
Kartennummern sind bi-direktional, d.h. ein Karteninhaber kann sich im Handel entweder als Käufer oder Verkäufer engagieren. Folglich sind die Begriffe „Verkäufer" und „Käufer" nur Beschreibungen für Rollen hinsichtlich einer gegebenen Transaktion, beispielsweise kann die Kartennummer, die in einer Transaktion als ein Käufer fungiert, für eine andere Transaktion in der Rolle eines Händlers verwendet werden. Ferner sind der Begriffe Verkäufer und Käufer dahingehend generisch, dass sie nur auf die Richtung des Kapitaltransfers für eine Transaktion verweisen. Folglich wird ein Karteninhaber auch als Käufer bezeichnet, wenn der Karteninhaber einen wohltätigen Beitrag an eine gemeinnützige Organisation leistet, und die gemeinnützige Organisation als Verkäufer, obwohl kein tatsächlicher „Verkauf" stattgefunden hat.
Ein weiterer Vorteil des Zahlungssystems ist, dass es jedem, der ein Informationsprodukt zu verkaufen hat, ermöglicht, einen verfügbaren Markt vorzufinden. Es gibt keine Altersgrenze für Informationsverkäufer.
Das oben beschriebene Zahlungssystem ist besonders vorteilhaft für den Gebrauch in Netzen, die keine zentralisierte Managementbehörde haben, so wie das Internet.
Andere solche Systeme umfassen FIDOnet und UUCP/Usenet, obgleich es bekannt ist, dass diese Systeme von manchen als ein Teil von oder assoziiert mit dem Internet betrachtet werden. Das oben beschriebene Zahlungssystem könnte auch bei zukünftigen Versionen, Generationen, etc. des Internets verwendet werden. Das Zahlungssystem könnte auch auf zentral gemanagten Computersystemen, wie America Online, Prodigy etc. verwendet werden.
Ein weiterer Aspekt des oben beschriebenen Zahlungssystems ist, dass es Benutzern ermöglicht, Informationsprodukte über ein quasiöffentliches Netz, wie beispielsweise das Internet, zu kaufen und zu verkaufen, unabhängig davon, wo die Benutzer sich aufhalten oder wo sich das Zahlungssystem befindet. Entweder der Käufer oder der Verkäufer kann sich in den USA oder außerhalb der USA befinden.
Das gleiche gilt für einige oder alle Zahlungssystemkomponenten; so können sich der Front-End-Computer oder der Back-End-Computer entweder in den USA oder außerhalb der USA befinden.

Claims

System, um Internetanwender in die Lage zu versetzen, Zahlungen an andere Internetanwender unter Verwendung des Internets (12) vorzunehmen, wobei das System umfasst: ein Computersystem (10), auf dem Benutzerkonten (100) für Internetanwender gespeichert sind, wobei die Benutzerkonten (100) Internetadressinformationen (104) und Finanzinformationen (108, 110) enthalten, wobei das Computersystem (10) umfasst: einen ersten Computer (50), der mit dem Internet (12) verbunden ist, um die Internetadressinformationen (104) zu führen, und um Mitteilungen von Internetanwendern zu senden und zu empfangen; einen vom Internet isolierten, zweiten Computer (52), um die Finanzinformationen (108, 110) getrennt von den Internetadressinformationen (104) zu führen, um mit einem System zur Abwicklung von finanziellen Transaktionen (30) zu verbinden, und um Kreditkartenbearbeitungsinformationen für Internetanwender auf dem zweiten Computer (52) gespeichert zu haben; Programmcode auf dem ersten Computer (50), welcher auf den Erhalt einer Transaktionsanfrage (129) von einem zweiten Internetanwender (28) reagiert, um von einem ersten Internetanwender (20) zu erfragen, ob der erste Internetanwender (20) eine in der Transaktionsanfrage (129) identifizierte Zahlung freigeben möchte; und Programmcode auf dem zweiten Computer (52) zur Bearbeitung der Zahlung vom ersten Internetanwender (20) unter Verwendung der Finanzinformationen (108, 110) in Reaktion auf eine Benachrichtigung (150) durch den ersten Internetanwender (20) zur Freigabe der Zahlung.
System nach Anspruch 1, wobei der erste Computer (52) und der zweite Computer (50) durch Stapelverarbeitung kommunizieren.
System nach Anspruch 1, ferner umfassend Mittel zum Führen einer Anzeige für ein Fehlen einer Zahlungsermächtigung in einem dem ersten Internetanwender (20) zugeordneten Datensatz (100), wenn der erste Internetanwender (20) eine Geldzahlung per Internet (12) nicht freigibt.
System nach Anspruch 3, ferner umfassend Mittel zum Empfangen einer Anfrage via Internet (12) von einem dritten Internetanwender bezüglich eines Fehlens einer Zahlungsermächtigung durch den ersten Internetanwender (20); und Mittel zum Informieren (218) des dritten Internetanwenders via Internet (12) bezüglich des Fehlens einer Zahlungsermächtigung durch den ersten Internetanwender (20).
System nach Anspruch 1, ferner umfassend Mittel zum Führen von Benutzerkonten (100) für Anwender des Internets (12).
System nach Anspruch 1, ferner umfassend Mittel zum Senden von Informationen (194) an ein System (30) abseits des Internets (12) zum Bearbeiten einer Zahlung für die Transaktion in Reaktion auf eine Benachrichtigung (150) durch den ersten Internetanwender (20) zur Freigabe einer Zahlung.
System nach Anspruch 1, wobei die Benutzerkonten (100) ferner persönliche Identifikationsnummern (102) umfassen, die zu Internet-Emailadress-Informationen (104) jeweiliger Anwender gehören, und wobei das Computersystem (10) ferner umfasst: Programmcode auf dem Computersystem, um im Benutzerkonto (100) einen der Mitteilungsinformation zugeordneten Namen (103B, 103S) nachzuschlagen, in Reaktion auf den Erhalt der die Mitteilungsinformation enthaltenden Transaktionsanfrage (129) über das Internet (12) vom zweiten Internetanwender (28); Programmcode auf dem Computersystem (10) zum Senden einer Transfer-Rückfragemitteilung (140) über das Internet (12) an eine dem ersten Internetanwender (20) zugeordnete Internet-Emailadresse, wobei der Programmcode zum Senden der Transfer-Rückfragemitteilung (140) auf den, den Namen (103B, 103S) nachschlagenden, Programmcode reagiert; und Programmcode auf dem Computersystem zum Senden einer Mitteilung (160) an den zweiten Internetanwender (28), wobei die Mitteilung (160) eine Anzeige (152) bereitstellt, dahingehend, ob die Benachrichtigung (150) von der dem ersten Internetanwender (20) zugeordneten Internet-Emailadresse erhalten wurde, in Reaktion auf die Transfer-Rückfragemitteilung (140).
System nach Anspruch 7, wobei die Transfer-Rückfragemitteilung (140) eine Adresse des Absenders enthält.
System nach Anspruch 8, wobei die Transfer-Rückfragemitteilung (140) eine Emailmitteilung ist.
System nach Anspruch 1, wobei die Transaktionsanfrage (129) entweder aus einer Emailmitteilung oder einer interaktiven Internet-Protokoll-Mitteilung besteht.
System nach Anspruch 1, wobei die Transaktionsanfrage (129) ferner eine textliche Beschreibung einer Transaktion (132) und einen Geldbetrag der Transaktion (134) enthält.