DE60221988T2 - Gesichertes zahlungsverfahren und -system - Google Patents

Gesichertes zahlungsverfahren und -system Download PDF

Info

Publication number
DE60221988T2
DE60221988T2 DE60221988T DE60221988T DE60221988T2 DE 60221988 T2 DE60221988 T2 DE 60221988T2 DE 60221988 T DE60221988 T DE 60221988T DE 60221988 T DE60221988 T DE 60221988T DE 60221988 T2 DE60221988 T2 DE 60221988T2
Authority
DE
Germany
Prior art keywords
product
request
transaction
user
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60221988T
Other languages
English (en)
Other versions
DE60221988D1 (de
Inventor
Ian David Tree
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.)
Virtual Access Ltd
Original Assignee
Virtual Access Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from GB0110808A external-priority patent/GB2375214B/en
Application filed by Virtual Access Ltd filed Critical Virtual Access Ltd
Application granted granted Critical
Publication of DE60221988D1 publication Critical patent/DE60221988D1/de
Publication of DE60221988T2 publication Critical patent/DE60221988T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/14—Payment architectures specially adapted for billing systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/24—Credit schemes, i.e. "pay after"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/28—Pre-payment schemes, e.g. "pay before"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/403—Solvency checks

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Marketing (AREA)
  • Information Transfer Between Computers (AREA)
  • Cash Registers Or Receiving Machines (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Crystals, And After-Treatments Of Crystals (AREA)
  • Control Of Vending Devices And Auxiliary Devices For Vending Devices (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Storage Device Security (AREA)

Description

  • Die vorliegende Erfindung betrifft ein Verfahren und ein System zur gesicherter elektronischer Zahlungen über ein Netzwerk.
  • Online-Transaktionen zwischen Kunden und Händlern über das Internet erfahren zunehmende Verbreitung. Derartige Transaktionen können den Kauf von Erzeugnissen in elektronischer Form, wie beispielsweise von Software, Video, Bildern, Text, Daten und beliebigem anderem Material in elektronischer Form umfassen, das über ein Netzwerk, wie beispielsweise das Internet, geliefert werden kann. Die Transaktionen können auch herkömmliche Waren einschließen, wobei in diesem Fall die Waren offline geliefert werden.
  • Das Problem bei Online-Transaktionssystemen besteht in der Gewährleistung gesicherter Zahlung für die gekauften Waren. Eine Form der Zahlung, die verbreitet eingesetzt worden ist, ist die Zahlung mit Kredit- oder Zahlkarten. Dieses Verfahren eignet sich besonders für elektronische Zahlungen über das Internet, da es lediglich die Übertragung einer Kreditkartennummer erfordert. Dieses Zahlungsverfahren hat jedoch erhebliche öffentliche Aufmerksamkeit erregt, da es keine Sicherheit bietet, weil die Kreditkarte des Kunden über das Internet für Betrüger zugänglich gemacht wird. Obwohl große Anstrengungen unternommen worden sind, um die Sicherheit von Transaktionen unter Verwendung von Kreditkartennummern zu erhöhen, beispielsweise durch Einsatz von Verschlüsselung, digitalen Zertifikaten und sicheren Kommunikationskanälen (beispielsweise SSL), besteht nach wie vor eine Anfälligkeit dahingehend, dass die Kreditkartennummer zum Zahlen übertragen und von Servern gespeichert wird.
  • Über das Internet angebotene Erzeugnisse können bezüglich des Preises erheblich variieren. Für Transaktionen mit einem Mindestwert, beispielsweise einem Dollar oder mehr, ist eine Kreditkartenaktion wirtschaftlich vertretbar.
  • Wenn jedoch über das Internet getätigte Käufe einen erheblich niedrigeren Wert haben, ist die Zahlung für einzelne Transaktionen mit Kreditkarte aufgrund der von den Kreditkartengesellschaften erhobenen Transaktionskosten wirtschaftlich nicht vertretbar. Daher sind so genannte Micropayment-Systeme entwickelt worden, um Zahlungen kleiner Beträge von Kunden an Händler abzuwickeln und Zahlung kleiner Beträge zu sammeln, um die Rechnungsstellung für Kunden, beispielsweise mit Kreditkarte, wirtschaftlich vertretbar zu machen.
  • Ein Beispiel eines Micropayment-Systems nach dem Stand der Technik ist das QPass-System, das in WO 00/3322 offenbart wird. Bei diesem System registrieren sich Kunden und Händler für den Dienst. Der Kunde und der Händler sind über ein Transaktions-Netzwerk miteinander verbunden, an das eine Zahlungsabwicklungseinrichtung (payment processor) angeschlossen ist. Wenn ein Kunde einen Kauf bei einem Händler tätigen möchte, meldet er sich bei dem System unter Verwendung eines Benutzernamens und eines Passworts an. Der verwendete Benutzername muss nicht einmalig sein und wird von dem Benutzer während des Prozesses zum Registrieren für den Dienst ausgewählt. Während der Registrierung wird eine eindeutige Kennung für den Benutzer erzeugt und als ein Cookie auf dem Computer des Kunden gespeichert. So wird, wenn sich ein Benutzer anmeldet und seinen Benutzernamen und die Benutzerkennung angibt, das Cookie in seinem Computer gelesen, und die eindeutige Kennung wird mit der Datenbank des Benutzers verglichen. Wenn sich der Benutzer angemeldet hat, wird ein Session-Cookie auf dem Computer des Benutzers gespeichert, das für einen bestimmten Zeitraum gültig ist. Dies ermöglicht es dem Benutzer, Transaktionen mit Händlern abzuwickeln, und die Transaktionen werden in der Zahlungsabwicklungseinrichtung gespeichert. Auf diese Weise können von Kunden für Waren von Händlern getätigte Zahlungen gesammelt werden, und dem Kunden kann von der Zahlungsabwicklungseinrichtung eine Rechnung gestellt werden, wenn dies angemessen ist, d. h., wenn die Gesamtsumme einen Mindestwert erreicht.
  • Obwohl das QPass-System ein Transaktions-Netzwerk schafft, das Benutzer in die Lage versetzt, sich zu registrieren und authentifiziert zu werden, um Zahlungen kleiner Beträge zu sammeln, beruht das System auf Cookies. Cookies gewährleisten lediglich eine niedrige Sicherheitsstufe, da sie ohne Weiteres gelesen und auf sie zugegriffen werden kann. Des Weiteren macht es dieses System erforderlich, dass ein Benutzer seinen Browser so einstellt, dass Cookies akzeptiert werden.
  • US 65,157,917 offenbart ein weiteres Zahlungssystem, das Objekte in der Art von Cookies zur Abwicklung von Zahlungen verwendet.
  • Aspekte der Erfindung werden in den unabhängigen Ansprüchen offenbart.
  • In der vorliegenden Erfindung bezieht sich der Begriff "Endgerätevorrichtung" auf jeden beliebigen Typ Verarbeitungsvorrichtung, die von einem Benutzer betrieben werden kann und als eine Produktquelle für den Benutzer dienen kann. Die Endgerätevorrichtung des Händlers muss nicht von einem Händler betrieben werden, sondern kann für einen Händler eines Erzeugnisses betrieben werden. Die Endgerätevorrichtung des Händlers umfasst eine Quelle von Erzeugnissen in elektronischer Form. Die Verarbeitungsvorrichtung kann in ei ner Ausführung jede beliebige geeignete programmierte Verarbeitungsvorrichtung umfassen, die über ein Kommunikationsnetzwerk verbunden werden kann.
  • Die vorliegende Erfindung kann bei jeder beliebigen Form von Kommunikationsnetzwerk eingesetzt werden, das die Endgerätevorrichtung eines Kunden in die Lage versetzen kann, ein Erzeugnis in elektronischer Form von der Endgerätevorrichtung eines Händlers anzufordern. Die vorliegende Erfindung eignet sich besonders für Implementierung über ein Internet-Protokoll-Netzwerk, das eine vorherrschend eingesetzte Form des Netzwerks ist. So kann die vorliegende Erfindung beispielsweise zur Implementierung über das Internet, ein Intranet, ein Extranet oder ein lokales Netzwerk eingesetzt werden.
  • Die Endgerätevorrichtung des Kunden implementiert vorzugsweise eine Clientanwendung zur Kommunikation über das Kommunikationsnetzwerk, und eine Endgerätevorrichtung eines Händlers implementiert eine Serveranwendung zur Kommunikation über das Kommunikationsnetzwerk. In dieser Ausführung wird eine ausführbare Anwendung unabhängig von der Clientanwendung an der Endgerätevorrichtung des Kunden ausgeführt, um von dem Benutzer eingegebene Anforderungen unter Verwendung der Clientanwendung zu erfassen und die Verwendung von Transaktionsquittungen und damit die Rechnungsstellung des Kunden zum Beziehen des Erzeugnisses zu steuern. So wird gemäß dieser Ausführung der vorliegenden Erfindung ein einfaches gesichertes Zahlungssystem geschaffen, bei dem der Kunde nicht in einzelnen Transaktionen einbezogen werden muss. Der Kunde fordert lediglich ein Erzeugnis an, und eine Transaktion wird automatisch für den ersten Abruf des Erzeugnisses aufgezeichnet, so dass der Benutzer die Informationen über einen Zeitraum danach frei abrufen kann.
  • Die Clientanwendung an der Endgerätevorrichtung des Kunden umfasst einen Webbrowser, und die Serveranwendung, die an der Endgerätevorrichtung des Händlers implementiert ist, umfasst einen Webserver. In dieser Ausführung ist die ausführbare Anwendung unabhängig von dem Webbrowser und kann geeigneterweise als Proxyserver arbeiten oder HTTP-Anforderungen auf der Socket Layer überwachen.
  • Die ausführbare Anwendung ist so ausgelegt, dass sie identifiziert, ob die Anforderung eine Anforderung für ein gebührenpflichtiges Erzeugnis ist, und die Anforderung unverändert über das Kommunikationsnetzwerk sendet, wenn sich die Anforderung nicht auf ein gebührenpflichtiges Erzeugnis bezieht. Dies ermöglicht es dem Anwendungsprogramm, transparent zu arbeiten, wenn kein in Rechnung zu stellendes Erzeugnis angefordert wird. Wenn sich eine Anforderung auf ein in Rechnung zu stellendes Erzeugnis bezieht, wird, falls ver fügbar, ein Transaktionsbeleg zu der Anforderung zum Senden über das Kommunikationsnetzwerk durch die ausführbare Anforderung hinzugefügt.
  • Die Clientanwendung umfasst einen Webbrowser an der Endgerätevorrichtung des Kunden, und die Serveranwendung an der Endgerätevorrichtung des Händlers umfasst einen Webserver. So umfasst die Anforderung eine HTTP (Hypertext-Transfer-Protocol)-Anforderung, wobei Code hinzugefügt werden kann, um die Anforderung als eine Anforderung eines gebührenpflichtigen Erzeugnisses zu identifizieren. Der Typ der Anforderung kann so durch die ausführbare Anwendung identifiziert werden, indem zu der HTTP-Anforderung hinzugefügter Code identifiziert wird. Geeigneterweise wird dieser Code als ASCII-Code ohne HTTP-Bedeutung hinzugefügt. Gemäß dem ersten Aspekt der Erfindung schaffen die Erzeugung von Transaktionsbelegen oder Token an der Endgerätevorrichtung des Händlers und die Speicherung der Transaktionsbelege an der Endgerätevorrichtung des Kunden ein einfaches, sicheres und automatisches Zahlungssystem für Erzeugnisse in elektronischer Form. Der Einsatz von lokaler Speicherung von Transaktionsbelegen schafft ein sicheres Mittel, mit dem ein Benutzer weitere Kopien des Erzeugnisses ohne weitere Rechnungsstellung abrufen kann. So umfasst dieser Aspekt der vorliegenden Erfindung das Verfahren und die Vorrichtung der Endgerätevorrichtung des Kunden sowie das Verfahren und die Vorrichtung der Endgerätevorrichtung des Händlers.
  • In einer Ausführung des ersten Aspektes der vorliegenden Erfindung kann die Endgerätevorrichtung des Kunden Transaktionsbelege über das Kommunikationsnetzwerk zu einem entfernten Zahlungsserver senden. Dies ermöglicht den Abgleich von Transaktionen, die mittels der in der Endgerätevorrichtung des Kunden gespeicherten Transaktionsbelege aufgezeichnet werden, mit den an der Endgerätevorrichtung des Händlers gespeicherten Transaktionsdaten.
  • In einer alternativen Ausführung des ersten Aspektes der vorliegenden Erfindung empfängt eine Endgerätevorrichtung des Kunden über das Kommunikationsnetzwerk Transaktionsinformationen von einem entfernten Zahlungsserver, und die empfangenen Transaktionsinformationen werden mit den gespeicherten Transaktionsbelegen verglichen. Informationen über das Ergebnis des Vergleichs werden dann zu dem Zahlungsserver zurückgeleitet. In dieser Ausführung wird der Großteil des Abgleichs von Transaktionen für einen Benutzer innerhalb der Endgerätevorrichtung des Kunden durchgeführt. Nur das Ergebnis des Abgleichprozesses wird zu dem Zahlungsserver zurückgeleitet.
  • In einer weiteren Ausführung der vorliegenden Erfindung stellt das System zusätzlich zu individuellen Transaktionsbelegen Abonnementsbelege für Abonnements regelmäßig be reitgestellter Erzeugnisse, wie beispielsweise elektronischer Zeitschriften oder jedes beliebige andere Erzeugnis bereit, das regelmäßig veröffentlicht bzw. verfügbar gemacht wird. In dieser Ausführung der vorliegenden Erfindung kann der Benutzer eine Abonnementanforderung eingeben, und diese Anforderung wird über das Kommunikationsnetzwerk zu der Endgerätevorrichtung des Händlers übertragen. An der Endgerätevorrichtung des Händlers wird ein Abonnementsbeleg erzeugt, und die Abonnementtransaktion wird in dem Transaktions-Datenspeicher aufgezeichnet. Der Abonnementsbeleg wird über das Kommunikationsnetzwerk zu der Engerätevorrichtung des Kunden gesendet, wo er auf ähnliche Weise wie der Transaktionsbelege gespeichert und verwendet wird. Der Abonnementsbeleg kann von einer Endgerätevorrichtung des Kunden verwendet werden, um festzustellen, ob das von dem Kunden angeforderte Erzeugnis eines ist, das der Kunde abonniert hat, beispielsweise eine Ausgabe einer von dem Kunden abonnierten Zeitschrift oder ein Medientyp, beispielsweise ein Film, auf dessen Empfang der Kunde abonniert ist. So umfasst der Abonnementsbeleg einen speziellen Fall eines Transaktionsbeleges, der eine Transaktion nicht nur für ein spezifisches abrufbares Erzeugnis, sondern stattdessen für eine Sammlung abrufbarer Erzeugnisse darstellt.
  • In einer Ausführung der vorliegenden Erfindung enthält die Anforderung des Erzeugnisses, die von der Endgerätevorrichtung des Kunden gestellt wird, um erhöhte Sicherheit zu bieten, eindeutige Benutzeridentifikations-Informationen. Dies ermöglicht es der Endgerätevorrichtung des Händlers, eine Überprüfung der Benutzeridentifikations-Informationen durchzuführen, um zu verhindern, dass auf nicht autorisierte Anforderungen von Informationen geantwortet wird.
  • Die vorliegende Erfindung kann in jeder beliebigen geeigneten Form, beispielsweise unter Einsatz spezieller Hardware oder einer Kombination aus spezieller Hardware und Software, implementiert werden. Die vorliegende Erfindung eignet sich besonders zur Implementierung als Computer-Software bei der Implementierung mittels eines Netzwerks von Verarbeitungsvorrichtungen. Das Kommunikationsnetzwerk kann jedes beliebige herkömmliche terrestrische oder Drahtlos-Kommunikationsnetzwerk umfassen. Die Verarbeitungsvorrichtungen können beliebige geeignete programmierbare Vorrichtungen, wie beispielsweise Mehrzweckcomputer, PDA, Mobiltelefon (beispielsweise ein WAP-Telefon) usw. umfassen. Da die vorliegende Erfindung als Software implementiert werden kann, schließt somit jeder Aspekt der vorliegenden Erfindung Computersoftware ein, die auf einer programmierbaren Vorrichtung implementiert werden kann. Die Computer-Software kann der programmierbaren Vorrichtung unter Verwendung jedes beliebigen herkömmlichen Trägermediums bereitgestellt werden. Das Trägermedium kann ein flüchtiges Trägermedium, wie beispielsweise ein elektrisches, optisches oder akustisches Signal oder Mikrowellen- oder Funkfrequenzsignal umfassen, das den Computercode transportiert. Ein Beispiele eines derartigen flüchtigen Mediums ist ein TCP/IP-Signal, das Computercode über ein IP-Netzwerk, beispielsweise das Internet, transportiert. Das Trägermedium kann auch ein Speichermedium zum Speichern von durch Prozessoren lesbarem Code, wie beispielsweise eine Diskette, Festplatte, CD-ROM, Magnetbandeinrichtung oder Festkörper-Speichereinrichtung, umfassen.
  • Ausführungen der vorliegenden Erfindung werden im Folgenden unter Bezugnahme auf die beigefügten Zeichnungen beschrieben, wobei:
  • 1 eine schematische Darstellung des gesicherten Zahlungssystems gemäß einer Ausführung der vorliegenden Erfindung ist;
  • 2 ein schematisches Funktionsdiagramm eines Benutzer-Computers in der Ausführung der vorliegenden Erfindung ist;
  • 3 eine schematisches Darstellung der Struktur des Benutzer-Computers in der Ausführung der vorliegenden Erfindung ist;
  • 4 ein schematisches Funktionsdiagramm eines Informationsservers in der Ausführung der vorliegenden Erfindung ist;
  • 5 eine schematische Darstellung des Aufbaus des Informationsservers in der Ausführung der vorliegenden Erfindung ist;
  • 6a und 6b ein Flussdiagramm der Funktion der Zahlungsanwendung in dem Computer des Benutzers in der Ausführung der vorliegenden Erfindung für den Prozess des Anforderns von Informationen sind;
  • 7 ein Flussdiagramm der Funktion der Zahlungsanwendung in dem Computer des Benutzers beim Empfangen der Informationen von dem Informationsserver sind;
  • 8 ein Flussdiagramm der Funktion der CGI-Anwendung 2 an dem Informationsserver in der Ausführung der vorliegenden Erfindung ist;
  • 9 ein Flussdiagramm ist, das die Funktion der CGI-Anwendung 1 an dem Informationsserver in der Ausführung der vorliegenden Erfindung darstellt;
  • 10 ein Flussdiagramm ist, das den Prozess des Abonnierens in der Ausführung der vorliegenden Erfindung darstellt;
  • 11 ein Flussdiagramm der Funktion der CGI-Anwendung 3 an dem Informationsserver in der Ausführung der vorliegenden Erfindung ist;
  • 12a eine Tabelle der Informationen ist, die in einen Transaktionsbeleg enthalten sind;
  • 12b eine Tabelle der Informationen ist, die in einem Abonnement-Beleg enthalten sind;
  • 13 ein Schema der Benutzerschnittstelle ist, die durch die Zahlungsanwendung erzeugt wird, um es einem Benutzer zu ermöglichen, Ausgabenlimit-Daten einzugeben;
  • 14 ein Flussdiagramm ist, das die Funktion der Zahlungsanwendung beim Kontrollieren von Ausgaben durch den Benutzer in der Ausführung der vorliegenden Erfindung darstellt;
  • 15 ein schematisches Funktionsdiagramm des zentralen Servers in der Ausführung der vorliegenden Erfindung ist;
  • 16 eine schematische Ansicht des Aufbaus des zentralen Servers in der Ausführung der vorliegenden Erfindung ist;
  • 17 ein Flussdiagramm des Benutzer-Registrierungsprozesses ist;
  • 18 ein Flussdiagramm des Website-Registrierungsprozesses ist;
  • 19 ein Flussdiagramm des Herausgeber-Registrierungsprozesses ist;
  • 20 ein Flussdiagramm des Abfragevorgangs ist, der durch den Upload-Client in dem zentralen Server in der Ausführung der vorliegenden Erfindung implementiert wird;
  • 21 ein Flussdiagramm des Abgleichprozesses ist, der durch den Upload-Client und die Transaktionseinrichtung in den zentralen Server in der Ausführung der vorliegenden Erfindung durchgeführt wird;
  • 22 ein Schema der Benutzerschnittstelle ist, die durch den Website-Manager an den Informationsserver zum Eingeben von Indexdaten und Kostendaten in der Ausführung der vorliegenden Erfindung bereitgestellt wird;
  • 23 ein Schema der Benutzerschnittstelle zum Eingeben von Informationen über Publikationen ist;
  • 24 ein Schema der Benutzerschnittstelle zum Konstruieren der Index-Hierarchie in der Ausführung der vorliegenden Erfindung ist;
  • 25 ein Schema der Benutzerschnittstelle zum Eingeben von Website-Standardinformationen ist;
  • 26 ein Schema der Benutzerschnittstelle zum Auswählen des Standorts der Dateien ist, die die Ausgabe einer Publikation bilden.
  • 27 ein Schema der Benutzerschnittstelle zum Definieren zugelassener Basisverzeichnisse (Permitted Base Directories) ist;
  • 28 ein Schema einer Webbrowser-Schnittstelle ist, die eine Index-Webseite für Publikationen anzeigt, die von dem Website-Manager erzeugt wird,
  • 29 ein Flussdiagramm des Prozesses zum Erzeugen der Index-Webseite ist,
  • 30 ein Flussdiagramm eines Zeitsynchronisations-Prozesses an dem Informationsserver gemäß einer Ausführung der vorliegenden Erfindung ist;
  • 31 ein Flussdiagramm eines Zeitsynchronisations-Prozesses an dem Benutzer-Computer gemäß einer Ausführung der vorliegenden Erfindung ist; und
  • 32a und 32b Flussdiagramme eines Verfahrens zum Vermeiden mehrfacher unbeabsichtigter Anforderungen gemäß einer Ausführung der vorliegenden Erfindung sind.
  • In der Ausführung der vorliegenden Erfindung, die im Folgenden unter Bezugnahme auf die beigefügten Zeichnungen beschrieben wird, wird das vom dem Benutzer gekaufter verkäufliche Erzeugnis als „Inhalt" oder „Informationen" bezeichnet. Das heißt, die Informationen umfassen den Inhalt von Zeitschriften-Publikationen. Es versteht sich jedoch, dass die vorliegende Erfindung nicht auf das Abrufen von Informationen beschränkt ist. Die vorliegende Erfindung schließt das Abrufen jedes beliebigen Inhaltes bzw. Erzeugnisses ein, für das Gebühren erhoben werden können, und das von einem Benutzer über ein Netzwerk abgerufen werden kann. So schließt die vorliegende Erfindung den elektronischen Kauf von Videos, Bildern, Dokumenten, Computer-Datendateien, Computer-Software, Tonerzeugnissen usw. ein.
  • Die spezifische Ausführung wird im Folgenden unter Bezugnahme auf den Abruf des Inhaltes von Zeitschriften-Publikationen beschrieben.
  • 1 ist eine schematische Darstellung eines Systems, in dem Computer 1a und 1c von Benutzern auf Informationsserver 2a und 2b zugreifen, um in dieser Ausführung auf Informationen in Form des Inhalts von Zeitschriften-Publikationen zurückzugreifen. Um den Inhalt von den Informationsservern 2a und 2b zu kaufen, muss sich der Benutzer zunächst registrieren und ein Konto bei dem zentralen Zahlungsserver 3 einrichten. Dies ist in 1 so dargestellt, dass ein Computer 1b eines Benutzers auf den zentralen Zahlungsserver 3 zugreift, um sich für den Dienst zu registrieren und ein Konto einzurichten. So führt der zentrale Zahlungsserver 3 ein Benutzerkonto, auf das durch den Benutzer-Computer 1b zugegriffen werden kann, um das Konto zu prüfen. Der zentrale Zahlungsserver 3 führt des Weiteren einen zentralen Index aller an den Informationsservern 2a und 2b verfügbaren Informationen. Darauf kann von dem Benutzer-Computer 1b zugegriffen werden, um Informationsserver 2a oder 2b zu identifizieren, die die zu kaufenden gewünschten Informationen speichern. Direkte Verbindung wird auch zwischen dem zentralen Zahlungsserver 3 und dem Benutzer-Computer 1b hergestellt, um Transaktionen von Benutzern abzugleichen. Belege für unter Verwendung des Systems gekaufte Informationen werden an dem Benutzer-Computer gespeichert, und Informationen bezüglich der Belege werden während eines Abgleichsprozesses, wie weiter unten ausführlicher beschrieben wird, zu dem zentralen Zahlungsserver 3 übertragen.
  • Die Informationsserver 2a und 2b stellen den Benutzer-Computern 1a und 1c Informationen zur Verfügung, wenn diese angefordert werden. Sie stellen auch Belege für die Informationen bereit, wie es weiter unten ausführlich beschrieben wird. Jeder Informationsserver 2a und 2b kommuniziert mit dem zentralen Zahlungsserver 3, um sich am Anfang zu registrieren und den Dienst zu nutzen und anschließend Informationen der Transaktionen zu dem zentralen Zahlungsserver 3 zu senden. Des Weiteren werden Index-Informationen über die an den Informationsservern 2a und 2b gespeicherten Informationen, die für die Benutzer-Computer 1a und 1b verfügbar sind, zu dem zentralen Zahlungsserver 3 weitergeleitet, um einen zentralen Index zu erzeugen, der Benutzern zur Verfügung gestellt wird. Informationsserver 2a und 2b werden mit Informationen über die Benutzer versorgt, für die der Dienst ausgesetzt ist, d. h. mit einer Liste gesperrter Konten.
  • Der zentrale Zahlungsserver 3 kommuniziert auch mit einem Kreditkarten-Zahlungsserver, um Mittel zum Ausgleichen eines Benutzerkontos zu empfangen.
  • Ein Herausgeberserver 5 umfasst eine Quelle von Informationsinhalten, der den Informationsservern 2a und 2b zur Verfügung gestellt wird. Der Herausgeber-Computer 5 kommuniziert mit dem zentralen Zahlungsserver 3, um die anfängliche Registrierung zur Nutzung des Dienstes durchzuführen und dann das Herausgeber-Konto prüfen zu können.
  • So ermöglicht, wie in 1 dargestellt, das System der vorliegenden Erfindung die Bereitstellung von Informationen für die Benutzer von den Informationsservern gegen eine Gebührt die an einem zentralen Zahlungsserver 3 in einem Benutzerkonto gesammelt wird. Ein besonderes Sicherheitsmerkmal der Ausführung der vorliegenden Erfindung besteht darin, dass Belege für Transaktionen an dem Benutzer-Computer 1a und 1c gespeichert werden, um zu verhindern, dass ein Benutzer noch einmal für Informationsinhalte bezahlt, für die er bereits bezahlt hat. Diese Belege werden mit den an einem zentralen Zahlungsserver gespeicherten und akkumulierten Transaktionsinformationen abgeglichen, um mögliche betrügerische Transaktionen zu erfassen.
  • 2 ist ein schematisches Funktionsdiagramm eines Benutzer-Computers 10, der in der in 1 dargestellten Ausführung der vorliegenden Erfindung als der Benutzer-Computer 1a, 1b, oder 1c verwendet wird.
  • Der Benutzer-Computer kann jede beliebige Verarbeitungs-Vorrichtung umfassen, die mit dem Internet 20 zur Kommunikation mit dem Informationsservern 2a und 2b und dem zentralen Zahlungsserver 3 verbunden ist.
  • Der Benutzer-Computer 10 umfasst eine Zahlungsanwendung 12, die als Zwischenglied zwischen einem Webbrowser 13 und dem Internet 20 dient. Alle Datenübertragungen zu und von dem Webbrowser 13 werden von der Zahlungsanwendung 12 überwacht. So erfasst die Zahlungsanwendung 12 alle (HTTP)-Anforderungen von dem Webbrowser 13 und Antworten aus dem Internet 20. In dieser bevorzugten Ausführung ist die Zahlungsanwendung 12 als ein Webproxy konfiguriert, und die Verbindung zwischen der Zahlungsanwendung 12 und dem Webbrowser 13 wird dadurch erreicht, dass der Webbrowser 13 so konfiguriert ist, dass er über einen lokalen Port auf dem Webproxy zugreift.
  • Die Zahlungsanwendung 12 hat Zugriff auf Ausgabenlimit-Daten in einem Limit-Datenspeicher 10, Belegdaten in Belegspeicher 14, die Benutzeridentifikations-Daten in einem Benutzerkennungs-Speicher 15 und Wechselkurs-Daten in einem Wechselkurs-Datenspeicher 16. Wie diese Daten verwendet werden, wird weiter unten ausführlich beschrieben.
  • In dieser Ausführung der vorliegenden Erfindung umfasst der Benutzer-Computer 10 einen Universalcomputer, beispielsweise einen Personal-Computer, der mit geeigneter Software konfiguriert ist, die einen Webbrowser 13 und eine Zahlungsanwendung 12 umfasst, wobei geeignete Daten in einem Datenspeicher, wie beispielsweise eine Festplatte, gespeichert sind.
  • 3 ist eine schematische Darstellung der Architektur eines Benutzer-Computers gemäß der Ausführung der vorliegenden Erfindung. Der Benutzer-Computer umfasst eine Zeigevorrichtung 32, beispielsweise eine Maus, eine Anzeigeeinrichtung 33 und eine Tastatur 34. Eine Internet-Schnittstellenvorrichtung 30, wie beispielsweise ein Modem oder eine LAN-Schnittstelle, ist vorhanden, um den Benutzer-Computer mit dem Internet 20 zu verbinden. Ein Programmspeicher 36, beispielsweise ein Festplattenlaufwerk, eine CD-ROM, eine Diskette oder eine programmierbare Festwertspeichereinrichtung ist vorhanden, um Programmcode zum Steuern eines Prozessors 31 zu speichern, der in dem Computer vorhanden ist. Der Prozessor 31 liest in Funktion den in dem Programmspeicher 36 gespeicherten Programmcode und implementiert ihn. Webbrowser-Programmcode wird von dem Prozessor 31 gelesen, um einen Webbrowser 31a zu implementieren. Zahlungsanwendungs-Programmcode wird aus dem Programmspeicher 36 gelesen, um die Zahlungsanwendung 31b zu implementieren. Die Datenspeichereinrichtung 35, beispielsweise ein Festplattenlaufwerk, eine CD-ROM oder ein Direktzugriffsspeicher (RAM), speichert von dem Prozessor 31 während der Implementierung des Webbrowers 31a und der Zahlungsanwendung 31b verwendete Daten. Insbesondere werden Belege, die Benutzerkennung, Ausgabenlimit-Daten und Wechselkurs-Daten zur Nutzung durch die Zahlungsanwendung 31b gespeichert.
  • Die Komponenten des Benutzer-Computers sind durch einen Steuer-und-Daten-Bus 37 miteinander verbunden.
  • 4 ist ein schematisches Funktionsdiagramm eines Informationsservers 40 gemäß einer Ausführung der vorliegenden Erfindung. Informationsserver 40 ist über das Internet 20 mit Benutzer-Computern und dem zentralen Server verbunden.
  • Ein Webserver 41 ist mit dem Internet 20 verbunden, um auf freie Webseiten zuzugreifen, die in dem Speicher 49 für freie Webseiten gespeichert sind. Webserver 41 ermöglicht auch Zugriff auf Informationsindex-Webseiten, die in dem Speicher 50 für Informationsindex-Webseiten gespeichert sind. Auf die Webseiten in den Speichern 49 und 50 kann von dem Webserver 41 unter Verwendung eines herkömmlichen Webbrowsers zugegriffen werden. Im Hintergrund hinter dem Server 41 arbeiten drei CGI (Common Gateway Interface)-Anwendungen 41, 43 und 44, die Informationen von dem Webserver 41 unter Verwendung des CGI-Standards empfangen. Jede dieser Anwendungen führt spezielle Funktionen durch, wie dies weiter unten ausführlicher beschrieben wird. Die zweite CGI-Anwendung 42 verarbeitet Informationen in dem Informationsgebühren-Datenspeicher 51, um Dateiidentifikations-Information bereitzustellen. Die erste CGI-Anwendung 43 führt die Haupt-Transaktionsfunktion innerhalb des Informationsservers 40 durch und greift so auf einen Transakti ons-Datenspeicher 45 zu, um Transaktionsinformation zu speichern, und hat Zugriff auf einen Datenspeicher 46 für gesperrte Benutzerkonten, um festzustellen, ob ein Benutzer, der eine Transaktion anfordert, von Nutzung des Dienstes ausgeschlossen ist. Die erste CGI-Anwendung 43 hat auch Zugriff auf den Informationsgebühren-Datenspeicher, um Gebühreninformationen zu bestimmen. Die erste CGI-Anwendung 43 hat auch Zugriff auf den Speicher 52 für gebührenpflichtige Information, der die von einem Benutzer angeforderten Informationen enthält. So speichert die erste CGI-Anwendung 43 nicht nur Transaktionsinformationen, sondern antwortet auch mit angeforderten Informationen, für die eine Gebühr anfällt. Die dritte CGI-Anwendung 44 führt eine Abonnementfunktion durch, wie sie weiter unten ausführlicher beschrieben wird. Diese Anwendung hat Zugriff auf den Transaktions-Datenspeicher 45, um Abonnement-Transaktionen zu speichern, und Zugriff auf den Datenspeicher für gesperrte Benutzerkonten, um festzustellen, ob der Benutzer, der ein Abonnement für Informationen anfordert, von dem Dienst ausgeschlossen ist. Auch die dritte CGI-Anwendung 44 hat Zugriff auf den Informationsgebühren-Datenspeicher 51, um gebührenpflichtige Information zu beziehen, wenn Benutzer über Abonnementsbelege verfügen.
  • Ein Uploadserver 47 ist in dem Informationsserver 40 vorhanden, um Transaktionsdaten in dem Transaktions-Datenspeicher 45 über das Internet 20 zu dem entfernten Zahlungsserver hochzuladen. Ein Transaktions-Online-Archiv-Datenspeicher 59 ist für das Speichern von Transaktionsdateien nach der Übertragung der Transaktionsdatei vorhanden, wenn der Uploadserver 47 abgefragt wird, wie dies weiter unten ausführlicher erläutert wird. Der Informationsserver 40 ist des Weiteren mit einem Webbrowser 48 versehen, der mit dem Internet 20 verbunden ist und von einem Betreiber des Informationsservers 40 (beispielsweise einem Webmaster oder Administrator) verwendet wird, um den Informationsserver 40 zu registrieren (das heißt, als eine Website, die für Benutzer verfügbare Informationen enthält).
  • Der Informationsserver 49 ist des Weiteren mit einer Website-Manager-Anwendung 53 versehen, die mit dem Internet 20 verbunden ist, um zu ermöglichen, dass Indexinformationen in einem Site-Index-Informationsspeicher 58 zu dem zentralen Zahlungsserver zur Erzeugung eines zentralen Index gesendet werden. Der Website-Manager 53 erfüllt die Funktion des Konfigurierens und Verwaltens der Informationen in dem Speicher 52 für gebührenpflichtige Informationen, die Kunden verfügbar gemacht werden. So hat die Website-Manager-Anwendung 53 Zugriff auf den Speicher 52 für gebührenpflichtige Informationen. Die Website-Manager-Anwendung erzeugt und verwaltet die Informationsgebührendsten in dem Informationsgebühren-Datenspeicher 51, Indexinformation in dem Site-Index-Informations-Speicher 58 und die Informationsindex-Webseiten in dem Informationsindex-Websei tenspeicher 50. Zur Erzeugung der Informationsindex-Webseiten verwendet die Website-Manager-Anwendung 53 HTML-Vorlagen, die in dem HTML-Vorlagenspeicher 56 gespeichert sind. Die HTML-Vorlagen in dem HTML-Speicher werden mit einem HTML-Editor 57 erzeugt.
  • Die Website-Manager-Anwendung 53 hat auch Zugriff auf Miniaturbilder, die in einem Miniaturbild-Speicher 55 gespeichert sind. Ein Bild-Editor 54 greift auf gebührenpflichtige Information in dem Speicher 52 für gebührenpflichtige Informationen zu, um die Miniaturbilder in dem Miniaturbild-Speicher 55 zu erzeugen. Die Miniaturbilder in dem Miniaturbild-Speicher 55 dienen dazu, Links für Informationen durch den Website-Manager 53 in der Informationsindex-Webseite zu erzeugen, die in dem Informationsindex-Webseiten-Speicher 50 gespeichert sind.
  • Der Informationsserver 40 kann unter Verwendung jeder beliebigen geeigneten Programmverarbeitungsvorrichtung implementiert werden.
  • 5 ist eine schematische Darstellung der Architektur des Informationsservers in dieser Ausführung der vorliegenden Erfindung, wobei der Programmcode auf einem Universalcomputer implementiert ist.
  • Der Informationsserver 40 ist mit einer Zeigevorrichtung 62, beispielsweise einer Maus, einer Anzeigeeinrichtung 63 zum Ausgeben von Information an einen Benutzer und einer Tastatur 64 zum Eingeben von Daten versehen. Eine Internet-Schnittstelleneinrichtung 60, wie beispielsweise ein Modem oder eine LAN-Schnittstelle, ist vorhanden, um den Informationsserver 40 mit dem Internet 20 zu verbinden. Ein Programmspeicher 66, wie beispielsweise ein Festplattenlaufwerk, eine CD-ROM, ein Diskettenlaufwerk, eine programmierbare Speichereinrichtung oder ein Festwertspeicher, ist zum Speichern von Programmcode zum Steuern eines Prozessors 61 in dem Informationsserver vorhanden. Der Programmspeicher 61 speichert Webserver-Programmcode, der von dem Prozessor 61 gelesen und implementiert wird, um einen Webserver 61a zu implementieren. Programmcode für die drei CGI-Anwendungen wird von dem Prozessor 61 gelesen und implementiert, um die drei CGI-Anwendungen 61b, 61c und 61d zu implementieren. Uploadserver-Programmcode wird aus dem Programmspeicher 66 gelesen und von dem Prozessor 61 implementiert, um den Uploadserver 61e zu implementieren. Website-Manager-Programmcode wird aus dem Programmspeicher 66 gelesen und von dem Prozessor 61 implementiert, um den Website-Manager 61f zu implementieren. Webbrowser-Programmcode wird von dem Prozessor 61 aus dem Programmspeicher 66 gelesen und implementiert, um den Webbrowser 61g zu implementieren. HTML-Editor-Programmcode wird von dem Prozessor 61 aus dem Pro grammspeicher 66 gelesen und implementiert, um den HTML-Editor 61h zu implementieren. Bild-Editor-Programmcode wird von dem Prozessor 61 aus dem Programmspeicher 66 gelesen und implementiert, um den Bild-Editor 61i zu implementieren.
  • Der Informationsserver 40 ist mit einer Datenspeichereinrichtung 65, beispielsweise einem Festplattenlaufwerk, einer CD-ROM, einem Diskettenlaufwerk oder einem Direktzugriffsspeicher (RAM) versehen, um die von dem Prozessor 61 während der Implementierung des aus dem Programmspeicher 66 gelesenen Programmcodes verwendeten Daten zu speichern. Die Datenspeichereinrichtung 65 speichert die Informationsindex-Webseiten, die Site-Index-Informationen, die Informationsgebühren-Daten, die Transaktionsdaten, die freien Webseiten, die Daten gesperrter Benutzerkonten, die HTML-Vorlagen, den Speicher für gebührenpflichtige Informationen und die Miniaturbild-Dateien. Alle Komponenten des Informationsservers werden durch einen Steuer-und-Daten-Bus 67 miteinander verbunden.
  • Der Vorgang des Einsatzes des Computers und des Informationsservers wird im Folgenden unter Bezugnahme auf die Flussdiagramme in 6–11 beschrieben.
  • 6a und 6b umfassen ein Flussdiagramm, das die Schritte darstellt, die von der Zahlungsanwendung zu implementieren sind, wenn eine Anforderung von dem Webbrowser 13 empfangen wird, und die Funktion der Zahlungsanwendung 12 beim Empfang einer Anforderung von dem Webbrowser wird im Folgenden beschrieben.
  • Der Webbrowser 13 an dem Benutzer-Computer 10 greift auf eine Webseite zu, die einen Link enthält (Schritt S1). Der Link wird von dem Benutzer ausgewählt (Schritt S2), und der Webbrowser 13 gibt eine HTTP-Anforderung an die Informations-Anwendung aus, die als ein Webproxy arbeitet (Schritt S3). Die Zahlungsanwendung 12 empfängt die HTTP-Anforderung und sucht in der Anforderung nach einem CGI-Programmnamen (Schritt S4). Die HTTP-Anforderung hat die folgende Form:
    http:\\server.com\cgi-bin\cgil.exe?abc+def+ghi
  • In dieser HTTP-Anforderung identifiziert der Teil server.com den Domainnamen für den Informationsserver. Der Dateipfad cgi-bin zeigt an, dass der folgende Teil eine CGI-Anwendung identifiziert. Der Dateinahme cgil.exe identifiziert die CGI-Anwendung. Die auf das Fragezeichen folgenden und durch das Pluszeichen abgegrenzten Parameter umfassen Parameter, die zu der CGI-Anwendung weitergeleitet werden.
  • In Schritt S5 stellt die Zahlungsanwendung fest, ob die CGI-Anwendung die CGI-Anwendung 1 umfasst. Wenn dies nicht der Fall ist, stellt in Schritt 36 die Zahlungsanwendung fest, ob die CGI-Anwendung die CGI-Anwendung 3 ist. Wenn dies nicht der Fall ist, wird im Schritt S7 die HTTP-Anforderung durch die Zahlungsanwendung 12 unverändert weitergeleitet und an das Internet 20 ausgegeben, da sie keine Anforderung von gebührenpflichtigen Informationen an einen Informationsserver 40 ist. Es könnte sich um eine Anforderung von freien Informationen handeln, die an freien Webseiten an dem Informationsserver 40 zur Verfügung stehen, so könnte die Anforderung beispielsweise wie folgt lauten:
    http:\\server.com\freepages.htm
  • Wenn in Schritt 56 die Zahlungsanwendung 12 feststellt, dass der Name der CGI-Anwendung die dritte CGI-Anwendung ist, wird festgestellt, dass dies eine Anforderung zum Implementieren des Abonnementprozesses ist (Schritt S18). Dies wird weiter unten ausführlicher unter Bezugnahme auf 10 beschrieben.
  • Wenn in Schritt S5 festgestellt wird, dass der Name der CGI-Anwendung die erste CGI-Anwendung ist, werden die auf den Dateinamen der CGI-Anwendung folgenden Parameter von der Zahlungsanwendung geprüft, um festzustellen, ob einer dieser Parameter eine Datei-Identifikationsnummer umfasst. Die Parameter müssen mindestens einen Dateiweg für die angeforderten Informationen enthalten. Der Dateipfad kann sowohl den Dateinamen, beispielsweise 001.pdf (Identifizierungsseite 1), als auch den Dateipfad, beispielsweise /magazines/PCW/1999/sept/, umfassen, der den Dateipfad als die Septemberausgabe der Zeitschrift Personal Computer World von 1999 identifiziert. Der Dateiidentifikations-Parameter besteht aus einer Inhaltsidentifikation, die eine eindeutige Identifikation für die Informationen umfasst, einer Publikationsidentifikation, die eine eindeutige Identifikation bzw. Kennung für die Publikation umfasst, zu der die Informationen gehören, sowie einer Haupt-Site-Kennung (master site ID), die eine Site identifiziert, auf der die Gebührendetails einer Originalkopie der Informationen definiert sind und die Dateikennung ausgegeben wird. Dies wird bereitgestellt, da Kopien der Informationen an Mirror-Seiten vorhanden sein können.
  • Das Format der durch die Zahlungsanwendung 12 empfangenen HTTP-Anforderung wird durch Links definiert, die in Webseiten eingefügt sind, auf die mit dem Webbrowser zugegriffen werden kann. Um Informationsinhalte anzufordern, wird auf die Informationsindex-Webseiten zugegriffen, die in dem Informationsindex-Webseitenspeicher 50 an dem Informationsserver 40 gespeichert sind. Die Informationsindex-Webseiten sind so aufgebaut, dass sie Links zu gebührenpflichtigen Informationen in dem Speicher 52 für gebührenpflichtige Informationen enthalten, und sie können die Dateikennung enthalten oder nicht. Sie müssen den Namen der ersten CGI-Anwendung 43 und den Domainnamen des Webser vers 41 sowie den Dateipfad für die gebührenpflichtigen Informationen in dem Informationsspeicher 52 enthalten.
  • Wenn in Schritt S9 festgestellt wird, dass die HTTP-Anforderung die Dateikennung enthält, verwendet im Schritt S13 die Zahlungsanwendung 12 die Dateikennung, um in dem Belegspeicher 14 zu suchen und festzustellen, ob ein Beleg für die Dateikennung vorhanden ist. Zunächst wird nach einem Abonnementsbeleg gesucht (Schritt S14), und wenn ein derartiger nicht identifiziert wird, wird in Schritt S19 nach einem Transaktionsbeleg gesucht. Wenn kein Transaktionsbeleg identifiziert wird und die Zahlungsanwendung 12 von dem Benutzer gesperrt worden ist (Schritt S22), wird eine Fehlermeldung zu dem Browser des Benutzers gesendet (Schritt S23), und die Transaktion wird abgebrochen. (Der Prozess des Sperrens der Zahlungsanwendung 12 wird weiter unten ausführlicher unter Bezugnahme auf 13 beschrieben). Falls kein Transaktionsbeleg identifiziert wird und die Zahlungsanwendung 12 von dem Benutzer nicht gesperrt worden ist, liest die Zahlungsanwendung 12 die Benutzer-Identifizierung aus dem Speicher 15 für Benutzer-Identifizierung, verschlüsselt sie und fügt sie als einen der Parameter zu der HTTP-Anforderung hinzu (Schritt S21). Die modifizierte HTTP-Anforderung wird dann durch die Zahlungsanwendung 12 an das Internet 20 ausgegeben (Schritt S18). Die modifizierte HTTP-Anforderung wird zu der ersten CGI-Anwendung 43 in dem Informationsserver 40 geleitet und enthält die Benutzer-Identifizierung sowie den Dateipfad der angeforderten gebührenpflichtigen Informationen als die Parameter, die sich hinter dem Fragezeichen befinden und durch ein Plus-Zeichen abgegrenzt werden.
  • Wenn in Schritt S19 ein Transaktionsbeleg für die Dateikennung in dem Belegspeicher 14 identifiziert wird, wird ein Prüfprozess (Schritt S20) an dem Beleg durchgeführt.
  • 12 stellt die Struktur eines Transaktionsbeleges dar. Er umfasst eine Anzahl von Parametern, die als eine Datenstruktur gespeichert sind. "ProtocolVersion" und "StructureVersion" definieren Versionsinformationen, die System- und Software-Upgrades ermöglichen. "ReceiptType" definiert den Typ des Belegs, d. h. ob es sich um einen Transaktionsbeleg oder einen Abonnementsbeleg handelt. "MasterSite Id" identifiziert die Originalseite, an der das spezielle Informationselement zuerst verfügbar war. "Contentld unique" identifiziert das Informationselement bzw. Inhaltselement, das zuvor von dem Benutzer angefordert und bezahlt worden ist. "Siteld" identifiziert die Seite, von der die Informationen abgerufen wurden. "Userld" umfasst die Benutzerkennung für den Benutzer, der die Informationen angefordert hat. "TransactionDate" gibt Datum und Zeit der Erzeugung des Transaktionsbeleges an. "ValidPeriod" definiert den Gültigkeitszeitraum des Transaktionsbeleges. "Currency" definiert die Währung der Transaktion, d. h. Dollar oder Pfund Sterling. "Amount" definiert die Transaktionssumme. "AdditionalData" ist ein Feld, das zusätzlich Informationen, wie beispielsweise den Pfadnamen des Informationsinhaltes, enthält. Dieses Feld kann auch Prüfsummen enthalten, um die Erfassung von Manipulation an dem Beleg zu erleichtern.
  • Um den Prüfvorgang durchzuführen (Schritt S20), ist es notwendig, festzustellen, ob das aktuelle Datum und die aktuelle Zeit, die durch eine Systemuhr in dem Benutzer-Computer bereitgestellt werden, eine Zeit identifizieren, die nach dem "TransactionDate" plus "Valid-Period" liegt. Das heißt, es wird festgestellt, ob der Beleg abgelaufen ist. Diese Einrichtung ermöglicht es dem Betreiber eines Informationsservers, Benutzer in die Lage zu versetzen Informationen zu bezahlen und über einen Zeitraum zu empfangen ohne wieder dafür bezahlen zu müssen, d. h., sie haben über einen begrenzten Zeitraum freien Zugang zu den Informationen. Dieser Zeitraum kann je nach Wunsch durch einen Informations-Provider ausgewählt werden, indem das "ValidPeriod"-Feld eingestellt wird.
  • Wenn als Ergebnis des Prüfvorgangs (Schritt S20) festgestellt wird, dass der Beleg abgelaufen ist, wird der Beleg ignoriert, und wenn die Zahlungsanwendung 12 von dem Benutzer gesperrt worden ist (Schritt S22) wird eine Fehlermeldung zu dem Browser des Benutzers gesendet (Schritt S23), und die Transaktion wird abgebrochen. Wenn der Beleg ignoriert wird und die Zahlungsanwendung 12 von dem Benutzer nicht gesperrt worden ist, verschlüsselt der Zahlungsanwendung 12 in Schritt S21 die Benutzeridentifizierung und fügt sie zu der HTTP-Anforderung hinzu, so als ob kein Transaktionsbeleg vorhanden wäre. Die modifizierte Anforderung wird dann von der Zahlungsanwendung 12 an das Internet 20 ausgegeben (Schritt S18).
  • Wenn der Prüfvorgang (Schritt S20) feststellt, dass der Transaktionsbeleg gültig ist, liest die Zahlungsanwendung 12 die Benutzeridentifizierung aus dem Speicher 15 für Benutzerkennungen, verschlüsselt sie und die Beleginformationen und fügt die verschlüsselten Informationen zu der HTTP-Anforderung hinzu. Der modifizierte HTTP-Anforderung wird dann durch die Zahlungsanwendung 12 an das Internet 20 ausgegeben.
  • Die an der HTTP-Anforderung vorgenommenen Modifizierungen umfassen das Hinzufügen von Parametern, die sich hinter dem Fragezeichen befinden und durch die Plus-Zeichen abgegrenzt werden. HTTP-Anforderungen müssen aus ASCII-Zeichen bestehen. So müssen nach dem Verschlüsselungsprozess, der erforderlich ist, um eine Sicherheitsstufe zu gewährleisten, die verschlüsselten Informationen in ASCII-Zeichen umgewandelt werden. Ein bekanntes Verfahren dafür ist UU-Codierung.
  • Die Zahlungsanwendung gibt daher die HTTP-Anforderung aus, die zu der ersten CGI-Anwendung 43 geleitet wird, wenn kein Abonnementsbeleg oder Transaktionsbeleg vorhanden ist oder wenn ein Transaktionsbeleg vorhanden ist.
  • Das Format des Abonnementsbeleges ähnelt dem des Transaktionsbeleges sehr und ist in 12b dargestellt. "ReceiptType" identifiziert den Beleg als einen Abonnementsbeleg. Im Unterschied zu dem Transaktionsbeleg gibt es keine "ContentID", die ein spezifisches Element von Information identifiziert, da sich der Abonnementsbeleg auf ein ganzes Spektrum von Informationselementen bezieht, das mit "PublicationID" bereitgestellt wird. Der Abonnementsbeleg enthält ein zusätzliches Feld "SubscriptionDate", das das Datum des Beginns des Abonnements angibt. "TransactionDate" identifiziert das Datum und die Zeit, zu der das Abonnement abgeschlossen wurde. Dies kann sich von dem Abonnementdatum unterscheiden. "ValidPeriod" definiert den Abonnement-Zeitraum mit dem Abonnementdatum. „Currency" und "Amount" definieren die Währung und den Betrag des Abonnements.
  • Wenn der Zahlungsserver feststellt, dass ein Abonnementsbeleg für eine Dateikennung in dem Belegspeicher 14 vorhanden ist (Schritt S14), wird ein Prüfprozess ausgeführt (Schritt S15). Um den Prüfprozess durchzuführen, enthält die HTTP-Anforderung einen zusätzlichen Parameter, der das Veröffentlichungsdatum des Informationsinhaltes identifiziert, der Gegenstand der Anforderung ist. So kann der Prüfvorgang (Schritt S15) das Veröffentlichungsdatum mit dem Abonnementdatum und dem Gültigkeitszeitraum vergleichen, um festzustellen, ob das Veröffentlichungsdatum in den Abonnement-Zeitraum fällt, d. h. zwischen das Abonnementdatum und den Term, der die Summe aus Abonnementdaten und Gültigkeitszeitraum umfasst. Wenn festgestellt wird, dass der Abonnementsbeleg nicht gültig ist, und keinen freien Abruf der Informationen zulässt (Schritt S15), sucht die Zahlungsanwendung 12 nach einem Transaktionsbeleg für die Dateikennung in dem Belegspeicher 14 (Schritt S19).
  • Wenn der Prüfvorgang (Schritt S15) feststellt, dass der Abonnementsbeleg für die angeforderten Informationen gültig ist, wird die HTTP-Anforderung modifiziert, indem der Name der CGI-Anwendung von der ersten CGI-Anwendung zu der dritten CGI-Anwendung geändert wird (Schritt 16).
  • Dann liest die Zahlungsanwendung 12 die Benutzeridentifizierung aus dem Benutzeridentifizierungs-Speicher (15), verschlüsselt sie und der Abonnementsbeleg-Informationen, unterzieht sie UU-Codierung und fügt sie zu der HTTP-Anforderung hinzu (Schritt S17). Die HTTP-Anforderung wird dann von der Zahlungsanwendung 12 an das Internet 20 ausgegeben (Schritt S18).
  • So empfängt die dritte CGI-Anwendung 44 in dem Informationsserver 40 Anforderungen von gebührenpflichtigen Informationen, für die in dem Benutzer-Computer ein gültiger Abonnementsbeleg verfügt und antwortet darauf.
  • Die Links, die in der Informationsindex-Website vorhanden sind, die in dem Speicher 50 für Informationsindex-Website gespeichert ist, müssen, wie oben erwähnt, die Dateikennungen nicht enthalten. Dies dienst dazu, zu ermöglichen, dass Link beispielsweise in PDF-Dateien vorhanden sein können, ohne dass erhebliche Modifikationen an den PDF-Dateien erforderlich sind, indem eindeutige Dateikennungen eingeschlossen werden. Daher wird, wenn die Zahlungsanwendung die HTTP-Anforderung empfängt, die die erste CGI-Anwendung identifiziert, wenn keine Dateikennung in der HTTP-Anforderung vorhanden ist (Schritt S9), eine HTTP-Anforderung durch die Zahlungsanwendung 12 an die zweite CGI-Anwendung 42 mit dem Dateipfad ausgegeben. Auf diese Weise leitet die Zahlungsanwendung die erste HTTP-Anforderung nicht von dem Webserver 13 weiter. Sie wird gehalten, wenn eine zweite Anforderung an die zweite CGI-Anwendung 42 erzeugt wird, um die Dateikennung zu ermitteln. Wenn die Dateikennung von der zweiten CGI-Anforderung 42 nicht zurückgeführt wird (S11), wird eine Nachricht zu dem Webbrowser 13 zurückgesendet (Schritt S12), um anzuzeigen, dass die Informationen nicht abgerufen werden können. Wenn die Dateikennung von der zweiten CGI-Anwendung 42 zurückgesendet wird (Schritt S12), verwendet die Zahlungsanwendung 12 die Dateikennung, um nach Belegen für die angeforderten Informationen in dem Belegspeicher 14 zu suchen (Schritt S13) und der Prozess läuft weiter, als ob die Dateikennung in der HTTP-Anforderung von dem Webbrowser 13 empfangen worden wäre.
  • So ist die zweite CGI-Anwendung 42 in dem Informationsserver 40 vorhanden, um die in dem Informationsgebühren-Datenspeicher verfügbaren Informationen zu nutzen und die Dateikennung für die Zahlungsanwendung zu ermitteln. Sie kann auch das Veröffentlichungsdatum (für Prüfung von Abonnementsbelegen, wie oben beschrieben) und Kosten- sowie Währungsinformationen (für Ausgabenlimit-Kontrolle, wie dies weiter unten ausführlicher beschrieben wird) bereitstellen. So kann die zweite CGI-Anwendung 42 alle diese Parameter der Zahlungsanwendung 12 unter Verwendung des Dateipfades bereitstellen, wenn sie sich nicht in der HTTP-Anforderung von dem Webbrowser 13 befinden, d. h. nicht in den Links, die in der Index-Webseite vorhanden sind.
  • Die Funktion der Zahlungsanwendung beim Empfangen einer HTTP-Antwort wird im Folgenden unter Bezugnahme auf das Flussdiagramm in 7 beschrieben.
  • Die Zahlungsanwendung 12 empfängt den HTTP-Header für die Informationen (Schritt S30) und stellt fest, ob der HTTP-Header Beleginformationen enthält (Schritt S31). Wenn Beleginformationen enthalten sind, müssen sie zuerst UU-Codierung unterzogen und dann entschlüsselt werden, bevor sie in dem Belegspeicher 14 nach der Dateikennung indexiert gespeichert werden (Schritt S32). Die Zahlungsanwendung 12 leitet dann die entweder von der ersten CGI-Anwendung 43 oder der dritten CGI-Anwendung 44 empfangenen Informationen über den Webserver 41 zu dem Webbrowser 13 weiter (Schritt S33). So wird, wenn einem Benutzer Informationsabruf in Rechnung gestellt worden ist, eine Transaktion aufgezeichnet, und ein an dem Benutzer-Computer 10 gespeicherter Beleg wird in dem Belegspeicher 14 gespeichert. Wenn der Benutzer bereits für die Informationen bezahlt hat und ein gültiger Beleg gespeichert ist, gibt es keine Transaktion, da keine Zahlung stattfindet, und so wird kein Transaktionsbeleg in Schritt S31 empfangen, und die Zahlungsanwendung 12 leitet die Informationen einfach zu den Webbrowser 13 weiter (Schritt S33). Der Webbrowser 13 zeigt die Informationen dann dem Benutzer an (Schritt S34).
  • Die Funktion der zweiten CGI-Anwendung 42 an dem Informationsserver 40 wird im Folgenden unter Bezugnahme auf das Flussdiagramm in 8 beschrieben.
  • Die zweite CGI-Anwendung 42 empfängt HTTP-Anforderungen von der Zahlungsanwendung 12, die einen Dateipfad für gebührenpflichtige Informationen enthalten (Schritt S40). Die zweite CGI-Anwendung 42 verwendet den Dateipfad in der HTTP-Anforderung, um die Dateikennung (und Veröffentlichungsdatum, Kosten und Währung) für die Informationen (Dateien) in dem Informationsgebühren-Datenspeicher 51 zu suchen (Schritt S41). Wenn eine Dateikennung gefunden wird (Schritt S42), wird die Dateikennung als die HTTP-Antwort über den Webserver 41 zu der Zahlungsanwendung 12 gesendet (Schritt 43). Wenn von der zweiten CGI-Anwendung 42 keine Dateikennung gefunden wird (Schritt 42), wird ein Fehlercode über dem Webserver 41 zu der Zahlungsanwendung gesendet (Schritt S44). Die Funktion der ersten CGI-Anwendung 43 an dem Informationsserver 40 wird im Folgenden unter Bezugnahme auf das Flussdiagramm in 9 beschrieben.
  • Die erste CGI-Anwendung 43 empfängt über den Webserver 41 Anforderungen von der Zahlungsanwendung 12 (Schritt S45). Die erste CGI-Anwendung unterzieht mit der HTTP-Anforderung weitergeleitete Parameter UU-Decodierung und entschlüsselt sie (Schritt S46). Die erste CGI-Anwendung 43 stellt dann fest, ob die Anforderung eine Benutzeridentifizierung enthält (Schritt S47). Wenn dies nicht der Fall ist, wird eine Fehlermeldung zu dem Webbrowser des Benutzers oder der Zahlungsanwendung gesendet (Schritt S49) (eine fehlende Benutzeridentifizierung zeigt an, dass der Benutzer versucht, gebührenpflichtige Informationen direkt und nicht über die Zahlungsanwendung 12 erlangen). Wenn die erste CGI-Anwendung 43 feststellt, dass die Anforderung keine Benutzeridentifizierung enthält (Schritt S47), stellt sie fest, ob die Benutzeridentifizierung eine gültige Form hat (Schritt S48). Wenn festgestellt wird, dass die Benutzeridentifizierung keine gültige Form hat (Schritt S48), wird eine Fehlermeldung zu dem anfordernden Webbrowser oder der Zahlungsanwendung gesendet (Schritt S49) (eine ungültige Benutzeridentifizierung zeigt an, dass der Benutzer versucht, gebührenpflichtige Informationen mit nicht autorisierten Mitteln und nicht über die Zahlungsanwendung 12 zu erlangen). Wenn die Benutzeridentifizierung gültig ist, stellt die erste CGI-Anwendung 43 fest, ob ein gültiger Beleg in den Parametern weiter geleitet wird (Schritt S50). Dieser Prozess umfasst das Identifizieren einer gültigen Transaktionsbeleg-Datenstruktur und eine Feststellung der Gültigkeit. Das Feststellen der Gültigkeit umfasst, dass festgestellt wird, ob der Beleg noch gültig ist, indem das aktuelle Datum und die Zeit aus der inneren Uhr des Informationsservers bestimmt werden und diese mit dem Transaktionsdatum zuzüglich des Gültigkeitszeitraums verglichen wird. So wird identifiziert, ob der Beleg noch gültig ist. Wenn festgestellt wird, dass der Transaktionsbeleg gültig ist, sucht der erste CGI-Anwendung 43 in dem Datenspeicher 46 für gesperrte Benutzerkonten, um festzustellen, ob die Benutzerkennung einen Benutzer identifiziert, der von dem Dienst ausgeschlossen worden ist (Schritt S52). Wenn ein gesperrter Nutzer durch die Benutzeridentifizierung identifiziert wird und festgestellt wird, dass die Sperrung vollständig ist (Schritt S56), wird eine Fehlermeldung zu der Zahlungsanwendung 12 gesendet (Schritt S57). Wenn ein gesperrter Benutzer durch die Benutzerkennung identifiziert wird und festgestellt wird, dass die Sperrung nicht vollständig ist (Schritt S56), das heißt, dass es dem Benutzer nur nicht gestattet ist, weiter unter Verwendung des Systems einzukaufen, werden die angeforderten Informationen aus dem Speicher 52 für gebührenpflichtige Informationen abgerufen und über den Webserver 41 und das Internet 20 an die Zahlungsanwendung 12 ausgegeben (Schritt S55). Wenn kein gesperrter Benutzer identifiziert wird (Schritt S52), werden die angeforderten Informationen aus dem Speicher 52 für gebührenpflichtige Informationen abgerufen und über den Webserver 41 und das Internet 20 an die Zahlungsanwendung 12 ausgegeben (Schritt S55). Wenn festgestellt wird, dass der Transaktionsbeleg nicht gültig ist, das heißt abgelaufen ist, sucht die erste CGI-Anwendung 43 in dem Speicher 46 für gesperrte Benutzerkonten, um festzustellen, ob die Benutzerkennung einen Benutzer identifiziert, der von der Nutzung des Dienstes ausgeschlossen worden ist (Schritt S51). Wenn der Benutzer entweder vollständig ausgeschlossen worden ist oder von weiterem Kauf unter Verwendung des Systems ausgeschlossen worden ist, wird eine Fehlermeldung zu der Zahlungsanwendung 12 gesendet (Schritt S57). Wenn der Benutzer nicht gesperrt ist, erzeugt die erste CGI-Anwendung 43 einen neuen Transaktionsbeleg durch Abrufen von Informationen aus dem Informationsgebühren-Datenspeicher 51 unter Verwendung des Dateipfades für die angeforderten gebührenpflichtigen Informationen unter Verwendung der Benutzerkennung. Der erzeugte Transaktionsbeleg wird dann verschlüsselt, um eine Sicherheitsstufe zu gewährleisten, wird UU-Codierung unterzogen und zu dem HTTP-Header hinzugefügt (Schritt S53). Da die Erzeugung eines Transaktionsbeleges bedeutet, dass dem Benutzer der Abruf der Informationen in Rechnung gestellt wird, wird ein Abruf der Transaktion in dem Transaktions-Datenspeicher 45 aufgezeichnet (Schritt S54). Informationen über die Kosten und die Währung für die Transaktion stehen über den Informationsgebühren-Datenspeicher 51 zur Verfügung, der Informationen über die Kosten, das heißt Währung und Summe, für den Abruf von Informationen speichert. Der Informationsgebühren-Datenspeicher 51 enthält auch die Haupt-Site-Kennung, die Publikationskennung, die Inhaltskennung und den Gültigkeitszeitraum für den angeforderten Informationsinhalt. Das heißt, der Informationsgebühren-Datenspeicher 51 enthält alle Informationen zum Erzeugen eines gültigen Belegs und zum Ausbilden von Transaktionsdaten zum Speichern in dem Transaktions-Datenspeicher 45. So erzeugt der Transaktions-Datenspeicher 45 einen Abruf aller Transaktionen durch alle Benutzer. Auf diese Weise enthält der Transaktions-Datenspeicher 45 Informationen, die mit Belegdaten verglichen werden können, die am Benutzer-Computer 10 gespeichert sind, um eine Stufe der Bestätigung der Gültigkeit von Transaktionen sowohl an dem Informationsserver 40 als auch dem Benutzer-Computer 10 herzustellen. Wenn die Transaktion in dem Transaktions-Datenspeicher 45 aufgezeichnet worden ist (Schritt S54), werden die durch die Zahlungsanwendung 12 angeforderten Informationen über den Webserver 41 und das Internet 20 an die Zahlungsanwendung 12 ausgegeben (Schritt S55).
  • Das Verfahren zum Abonnieren einer Publikation wird im Folgenden unter Bezugnahme auf das Flussdiagramm in 10 beschrieben. Das Flussdiagramm in 10 geht von Schritt S8 in 6a aus.
  • An dem Informationsserver 40 sind zusätzlich zu Informationsindex-Webseiten, die in dem Speicher 50 für Informationsindex-Webseiten gespeichert sind, Abonnementindex-Webseiten vorhanden, die Links zu der dritten CGI-Anwendung 44 mit Parametern enthalten, die die Publikationskennung umfassen, die die Publikation identifiziert, die der Benutzer abonnieren möchte.
  • Die Zahlungsanwendung 12 durchsucht den Belegspeicher 14 (Schritt S60) nach Abonnementsbelegen für die Publikation. Die Zahlungsanwendung 12 empfängt die Benutzer-Kennung, die aus dem Benutzerkennungs-Speicher 15 gelesen wird, zusammen mit einer Liste von Abonnementsbelegdaten und -zeiten, die im Schritt S60 gefunden werden, verschlüsselt sie, und unterzieht sie UU-Codierung und fügt sie zu der HTTP-Anforderung hinzu (Schritt S61). Die dritte CGI-Anwendung 44 empfängt die HTTP-Anforderung über den Webserver 41 und berechnet unter Bezugnahme auf die Veröffentlichungsdaten der Ausgabe der Publikation im Datenspeicher 51 und einen Vorschlag für ein Abonnement-Anfangsdatum und eine Liste alternativer Anfangsdaten und erzeugt eine Webseite und gibt sie zur Anzeige durch den Webbrowser 13 an den Benutzer-Computer 10 aus (Schritt S62), um dem Benutzer zu ermöglichen, das vorgeschlagene Abonnement-Anfangsdatum zu bestätigen oder ein anderes Anfangsdatum auszuwählen und auch einen Abonnement-Zeitraum auszuwählen (Schritt S63). Die dritte CGI-Anwendung 44 empfängt die HTTP-Anforderung für ein Abonnement-Anfangsdatum und einen Abonnement-Zeitraum (Schritt 64) und verwendet die Benutzer-Kennung, um in dem Speicher 46 für gesperrte Benutzerkonten zu suchen und festzustellen, ob der Benutzer vom Kauf unter Verwendung des Dienstes ausgeschlossen ist (65). Wenn festgestellt worden ist, dass der Benutzer vom Kauf unter Verwendung des Dienstes ausgeschlossen worden ist, wird eine Fehlermeldung zu der Zahlungsanwendung 12 gesendet (Schritt 66). Wenn festgestellt worden ist, dass der Benutzer vom Kauf unter Verwendung des Dienstes ausgeschlossen worden ist, kann die CGI-Anwendung 44 einen Abonnementsbeleg der in 12b gezeigten Form erzeugen, verschlüsseln, UU-Codierung unterziehen und an die Zahlungsanwendung 12 ausgeben (Schritt S67). Die dritte CGI-Anwendung 44 zeichnet dann die Transaktion in dem Transaktions-Datenspeicher 45 auf (Schritt S68). Die Zahlungsanwendung 12 empfängt den Abonnementsbeleg, unterzieht ihn UU-Decodierung, entschlüsselt ihn und speichert ihn in dem Belegspeicher 14 (Schritt 69).
  • Die Funktion der dritten CGI-Anwendung 44 in Reaktion auf eine HTTP-Anforderung von der Information wird im Folgenden unter Bezugnahme auf das Flussdiagramm in 11 beschrieben. Die dritte CGI-Anwendung 44 empfängt eine HTTP-Anforderung von Informationen, wenn die Zahlungsanwendung 12 feststellt, dass ein gültiger Abonnementsbeleg vorhanden ist. So empfängt die dritte CGI-Anwendung die HTTP-Anforderung (Schritt S70). In der HTTP-Anforderung weitergeleitete Parameter werden UU-Decodierung unterzogen und entschlüsselt (Schritt S71). Die dritte CGI-Anwendung 44 stellt dann fest, ob die Anforderung eine Benutzer-Kennung enthält (Schritt S72). Wenn dies nicht der Fall ist, wird eine Fehlermeldung zu dem Browser des Benutzers oder der Zahlungsanwendung gesendet (Schritt S74) (eine fehlende Benutzer-Kennung zeigt an, dass der Benutzer versucht, gebührenpflichtige Informationen direkt und nicht über die Zahlungsanwendung 12 zu beziehen). Wenn die dritte CGI-Anwendung 44 feststellt, dass die Anforderung eine Benutzer-Kennung enthält (Schritt S72), stellt sie fest, ob die Benutzer-Kennung gültige Form hat (Schritt S73). Wenn festgestellt wird, dass die Benutzer-Kennung keine gültige Form hat (Schritt S73), wird eine Fehlermeldung zu dem Webbrowser oder der Zahlungsanwendung gesendet (Schritt S74) (eine ungültige Benutzer-Kennung zeigt an, dass der Benutzer ver sucht, gebührenpflichtige Informationen mit nicht autorisierten Mitteln und nicht über die Zahlungsanwendung 12 zu beziehen). Wenn festgestellt wird, dass die Benutzer-Kennung gültige Form hat (Schritt S73), stellt die dritte CGI-Anwendung 44 fest, ob ein gültiger Abonnementsbeleg in den Parametern weitergeleitet wird (Schritt S75). Dieser Überprüfungsvorgang verwendeten Veröffentlichungsdatum der angeforderten Informationen, das als ein Parameter mit der HTTP-Anforderung weitergeleitet, um festzustellen, ob die angeforderten Informationen innerhalb des Abonnement-Zeitraums liegen, das heißt innerhalb des Zeitraums, der durch die Summe des Abonnementdatums und der gültigen Periode definiert wird. Wenn festgestellt wird, dass der Beleg nicht gültig ist, sendet die dritte CGI-Anwendung 44 eine Fehlermeldung zu der Zahlungsanwendung 12 (Schritt S76). Wenn festgestellt wird, dass der Beleg gültig ist, verwendet die dritte CGI-Anwendung 44 die Benutzer-Kennung, um in dem Datenspeicher 46 für gesperrte Benutzerkonten zu suchen (Schritt S77) und festzustellen, ob der entsprechende Benutzer vollständig von der Nutzung des Dienstes ausgeschlossen worden ist (Schritt S789) (im Unterschied dazu, dass er vom Kauf unter Verwendung des Dienstes ausgeschlossen ist). Wenn festgestellt wird, dass der Benutzer vollständig von der Nutzung des Dienstes ausgeschlossen worden ist, wird eine Fehlermeldung zu der Zahlungsanwendung 12 gesendet (Schritt S76). Wenn festgestellt wird, dass die Benutzer-Kennung sich nicht in der Liste gesperrter Benutzer befindet (Schritt S77) oder dass der Benutzer nicht vollständig von der Nutzung des Dienstes ausgeschlossen worden ist (Schritt S78), werden die Informationen wie angefordert ausgegeben (Schritt S79).
  • Die Fähigkeit der Zahlungsanwendung 12 in dem Benutzer-Computer 10 Ausgaben für Erzeugnisse zu kontrollieren, die über den Webbrowser 13 angefordert werden, wird im Folgenden unter Bezugnahme auf 13 und 14 beschrieben.
  • Wenn eine HTTP-Anforderung für ein Erzeugnis empfangen wird, enthält die Anforderung die Kennung der ersten CGI-Anwendung 43 und den Dateipfad der angeforderten Datei. Wenn die Informationsindex-Webseiten so eingestellt worden sind, dass sie weitere Informationen enthalten, enthält die HTTP-Anforderung die Datei-Kennung, ein Veröffentlichungsdatum, Kosten und Währung für die Informationen. Als Alternative dazu können diese weiteren Informationen über die Datei-Kennung, das Veröffentlichungsdatum, die Kosten und die Währung erlangt werden, indem der Dateipfad zu der zweiten CGI-Anwendung 42 gesendet wird, damit die zweite CGI-Anwendung 42 die Informationen in dem Informationsgebühren-Datenspeicher 51 sucht. Wenn die Anforderung von dem Webbrowser 30 eine Anforderung eines Abonnements einer Publikation ist, identifiziert die Anforderung die dritte CGI-Anwendung 44. Die HTTP-Anforderung enthält Publikationskennung, Veröffentli chungsdatum, Gültigkeitszeitraum, Kosten und Währung für das Abonnement der Publikation. So ist bei einem Abonnement die Inhaltskennung in der Datei-Kennung leer, da diese nicht erforderlich ist.
  • Die Zahlungsanwendung 12 empfängt so Information über die Kosten der angeforderten Informationen des angeforderten Abonnements und die Währung. Diese werden entweder in der Anforderung oder an der zweiten CGI-Anwendung 42 empfangen. Der Empfang der Kosten- und Währungsinformationen mit der Anforderung, bevor sie zu dem Informationsserver gesendet wird, ermöglicht es der Zahlungsanwendung 12, Kostenüberwachung durchzuführen und zu hohe Ausgaben durch den Benutzer zu verhindern. Um dies zu ermöglichen, ist die Zahlungsanwendung 12 mit einer grafischen Benutzerschnittstelle versehen, auf die ein Benutzer zugreifen kann, und die in 13 dargestellt ist. Wenn die Zahlungsanwendung 12 auf dem Benutzer-Computer 10 in dieser Ausführung implementiert wird, in der sie in einer Umgebung mit dem Betriebssystem Microsoft Windows 95, 98, 200 oder NT (Warenzeichen) implementiert ist, erscheint ein Objekt für die Zahlungsanwendung in der Aufgabenleiste. Wenn ein Benutzer mit der rechten Maustaste auf das Element klickt, wird ein Menü angezeigt, das es einem Benutzer ermöglicht, Sperrung der Zahlungsanwendung 12 auszuwählen. Dies verhindert weitere Ausgaben unter Verwendung der Zahlungsanwendung, bis die Zahlungsanwendung entsperrt wird. Es verhindert jedoch nicht, dass der Benutzer Informationen bezieht, für die er bereits gezahlt hat und für die er über einen gültigen Beleg verfügt. So wirkt die Sperrung als ein Mittel zum Kontrollieren von Ausgaben. Das Entsperren der Zahlungsanwendung macht die Eingabe eines Passworts durch den Benutzer erforderlich, das unter Verwendung des in der 13 angezeigten Fensters ausgewählt wird. Der Benutzer kann auch die Anzeige des in 13 gezeigten Fensters aus dem angezeigten Menü auswählen. Dies ermöglicht weitere Ausgabenkontrolle.
  • Es können, wie in 13 zu sehen ist, verschiedene auf die Ausgaben bezogene Parameter eingestellt und in dem Ausgabenlimit-Datenspeicher 13 gespeichert werden, um sie bei der Überwachung von Ausgaben durch den Benutzer zu verwenden. Es gibt zwei Typen von Ausgabenlimits, die von dem Benutzer eingestellt werden können. Es gibt ein Limit für eine einzelne Transaktion, das ein Limit für eine einzelne Transaktion festlegt. Es gibt, wie in 13 zu sehen ist, drei Stufen von Reaktion oder Aktion für drei verschiedene einstellbare Ausgabestufen. Bei diesem Beispiel besteht für jede einzelne Transaktion über 0,05 Dollar die Aktion darin, dass der Benutzer aufgefordert wird, zu bestätigen, dass die Transaktion durchgeführt wird. Für Transaktionen über 4 Dollar muss der Benutzer ein Passwort eingeben, um die Abwicklung der Transaktion zu autorisieren. Transaktionen über 10 Dollar werden abgelehnt und nicht zugelassen. Der zweite Typ von Ausgabenlimits be steht in einem Ausgabenlimit pro Zeitraum. Bei dieser Ausführung gibt es vier Ausgabenlimit-Zeiträume, die eingestellt werden können. In diesem Beispiel gibt es eine Gruppe von Ausgabenlimits von 7 Dollar pro Tag, 40 Dollar pro Woche, 150 Dollar pro Monat und 500 Dollar pro Jahr. Der Benutzer kann auswählen, dass ein Ausgabenlimit pro Zeitraum ignoriert wird, wenn das Passwort eingegeben wird, indem das Kontrollkästchen neben dem betreffenden Limit angekreuzt wird. Der Benutzer kann auch die Hauptwährung des Benutzers auswählen, die in diesem Fall auf US-Dollar eingestellt ist. Diese Auswahl der Währung wählt die Landeswährung des Benutzers aus, die für Ausgabenlimits relevant ist. Es kann ein Ton ausgewählt werden, der abgespielt wird, wenn eine geringfügige Ausgabe getätigt wird. Dieser wird abgespielt, wenn die Transaktion dem niedrigsten einzelnen Transaktions-Ausgabenlimit gleich ist oder darunter liegt. Es kann ein Ton ausgewählt werden, der abgespielt wird, wenn eine größere Ausgabe getätigt wird. Dieser wird abgespielt, wenn die Transaktion über dem niedrigsten einzelnen Transaktions-Ausgabenlimit liegt. Der Benutzer kann wählen, dass ein Ton abgespielt wird, wenn die Zahlungsanwendung eine Meldung anzeigt. Der Benutzer kann das Passwort einstellen, das die Zahlungsanwendung für die Einschränkung von Zugriff und das Ignorieren von Ausgabenlimits erfordert.
  • Wenn ein Benutzer alle Benutzer-Präferenzen wofür die Ausgabenlimit-Daten eingegeben hat und die OK-Schaltfläche angeklickt hat, werden die Ausgabenlimit-Daten in dem Ausgabenbegrenzungs-Datenspeicher zur Verwendung bei der Kontrolle von Ausgabenlimits durch den Benutzer durch Überwachung der Kosten und der Währung jeder einzelnen Transaktion bzw. Abonnementtransaktion beim Empfangen jeder Anforderung von dem Webbrowser 13 durch die Zahlungsanwendung 12 gespeichert.
  • 14 ist ein Flussdiagramm, das das Verfahren zum Kontrollieren von Ausgaben durch den Benutzer darstellt. Die Ausgabenlimits werden, wie oben beschrieben, durch den Benutzer definiert und in dem Ausgabenlimit-Datenspeicher gespeichert (Schritt S90). Wenn der Benutzer einen Browser verwendet, um gebührenpflichtige Informationen anzufordern (Schritt S81), stellt die Zahlungsanwendung fest, ob die Anforderung die Dateikennung und Zahlungsinformationen enthält (Schritt S82). Wenn dies nicht der Fall ist, fordert die Zahlungsanwendung 12 die Dateikennung und Zahlungsinformationen von der zweiten CGI-Anwendung 42 an dem Informationsserver 40 an und empfängt sie (Schritt S83). Da die Zahlungsanwendung 42 nun über die Dateikennung verfügt, kann sie feststellen, ob in dem Belegspeicher 14 ein gültiger Beleg gespeichert ist. Zunächst stellt sie fest, ob überhaupt ein Beleg vorhanden ist, d. h. ein Transaktionsbeleg oder ein Abonnementsbeleg, und wenn dies der Fall ist, stellt sie fest, ob der Beleg abgelaufen ist. Wenn ein Beleg vorhanden ist und dieser gültig ist, fordert die Zahlungsanwendung die Informationen von dem Informationsserver 40 an und sendet den Beleg als Zahlungsbeweis (Schritt S85). Wenn ein gültiger Beleg vorhanden ist, ist es nicht notwendig, ein Ausgabenlimit-Kontrollfunktion zu initiieren, da der Benutzer nicht erneut für die Informationen bezahlt.
  • Wenn kein Beleg vorhanden ist oder der Beleg ungültig ist (Schritt S84) und die Zahlungsanwendung durch den Benutzer gesperrt worden ist (Schritt S86), d. h. die Ausgaben aufgehoben sind, wird eine Fehlermeldung von der Zahlungsanwendung zu dem Browser des Benutzers gesendet (Schritt S91). Wenn kein Beleg vorhanden ist oder der Beleg ungültig ist (Schritt S84) und die Anwendung von dem Benutzer nicht gesperrt worden ist (Schritt S86), wandelt die Zahlungsanwendung die Kosten der Transaktion, falls erforderlich, unter Verwendung der in dem Wechselkurs-Datenspeicher gespeicherten Wechselkurs-Daten in die Währung des Benutzers um (Schritt S87). Die Zahlungsanwendung 12 ist nunmehr in der Lage, die angeforderte Transaktion mit dem gespeicherten Ausgabenlimit-Daten in dem Ausgabenlimit-Datenspeicher 11 zu vergleichen (Schritt S88). Wenn die Transaktionssumme für alle vorhergehenden Transaktionen zuzüglich der angeforderten Transaktion eines der Ausgabenlimits übersteigt, oder wenn der Transaktion eines der Einzel-Transaktionslimits übersteigt, wird eine Warnung an den Benutzer in Form einer Anzeige und wahlweise eines Tons ausgegeben (Schritt S89). Da die zwei unteren einzelnen Transaktionen und die Ausgabenlimits für Zeiträume entweder mit einem Passwort oder lediglich durch Bestätigung ignoriert werden können (Schritt S90), kann ein Benutzer die Warnung ignorieren. Wenn der Benutzer sie nicht ignoriert, wird die Anforderung verworfen, und es wird eine Anzeige an den Benutzer ausgegeben, um ihn zu informieren, dass die Anforderung verworfen worden ist (Schritt S91). Wenn der Benutzer die Ausgabenlimit-Warnung ignoriert (Schritt S90), sendet die Zahlungsanwendung die Anforderung von Informationen zu dem Informationsserver 40 (Schritt S92). Die Zahlungsanwendung 12 empfängt dann die Informationen und einen Transaktionsbeleg von dem Informationsserver (Schritt S93) und berechnet dann eine neue Transaktions-Gesamtsumme für die Ausgabenlimits pro Zeitraum (Schritt S94). Der Transaktions-Gesamtbetrag wird in dem Ausgabenlimit-Datenspeicher 11 zusammen mit den Ausgabenlimits gespeichert, die in Schritt 88 für die Feststellung dahingehend zu verwenden sind, ob die nächste Anforderung von gebührenpflichtigen Informationen die Ausgabenlimits pro Zeitraum übersteigen wird. Die Zahlungsanwendung 12 wartet dann auf den Empfang der nächsten Anforderung von gebührenpflichtigen Informationen (Schritt S81).
  • Der zentrale Server wird im Folgenden unter Bezugnahme auf 15 und 16 beschrieben. 15 ist ein schematisches Funktionsdiagramm des zentralen Servers 70. Der zentrale Server ist mit einem Webserver 71 versehen, der mit dem Internet 20 verbunden ist, um Benutzern, Administratoren von Website (Informationsserver) oder Web-Mastern und Informationsanbietern Zugriff auf der durch den zentralen Server 70 bereitgestellten Dienste zu ermöglichen. Der zentrale Server 70 speichert so Webseiten in einem Webseiten-Datenspeicher 72, die frei verfügbar sind. Des Weiteren werden Zentral-Informationsindex-Webseiten in einem Zentral-Informationsindex-Webseiten-Speicher 73 gespeichert, um einen Zentral-Index von Informationen bereitzustellen, die an allen teilnehmenden Informationsservern 40 verfügbar sind. Ein Server 74, der einen Zentral-Informationsindex führt, ist über das Internet 20 verbunden vorhanden, um Indexinformationen von Informationsservern 40 zu beziehen und die Zentral-Informationsindex-Webseiten in dem Datenspeicher 73 für Zentral-Informationsindex-Webseiten zu führen und zu aktualisieren. Der Server 74, der den Zentral-Informationsindex führt, nimmt Bezug auf eine Informationsindex-Datenbank 45, die die Indexinformationen für alle Informationsserver 40 speichert, die an dem Dienst teilnehmen, und aktualisiert sie. Der Server 74, der den Informationsindex führt, greift auch auf eine Datenbank 77 von Websites (Informationsserver) zu, die Informationen über alle teilnehmenden Informationsserver 40 speichert. Der zentrale Server 70 speichert auch eine Benutzer-Datenbank 76, die Informationen über alle teilnehmenden Benutzer speichert. Des Weiteren ist eine Verlags-Datenbank 78 vorhanden, die alle Informationen über teilnehmende Verlage speichert. Drei Anwendungen 86, 88 und 90 sind zum Registrieren von Benutzern, Websites (Informationsserver) bzw. Verlagen vorhanden. Eine CGI 86 zum Registrieren von Benutzern ist über den Webserver 71 implementiert, um Benutzer in der Benutzerdatenbank 76 zu registrieren und es Benutzern zu ermöglichen, einen Installationscode für eine Zahlungsanwendung aus einem Speicher 87 für den Installationscode der Zahlungsanwendung herunterzuladen. Ein CGI 88 zum Registrieren von Websites ist vorhanden, um es Administratoren von Websites (Informationsserver) zu ermöglichen, die Website bei dem Dienst als eine Website zu registrieren, von der gebührenpflichtige Informationen heruntergeladen werden können. Der CGI 88 zum Registrieren von Websites speichert die Registrierungsinformationen in der Website-Datenbank 77. Die CGI 88 zum Registrieren von Websites ermöglicht es dem Administrator auch, den Installationscode für eine Website-Verwaltungsanwendung aus dem Speicher 89 für den Installationscode der Website Verwaltungsanwendung über den Webserver 71 herunterzuladen. Die CGI 90 zum Registrieren von Herausgebern ermöglicht es Hausgebern von Informationen, sich bei dem Dienst zu registrieren, wenn sie Informationen an Websites verfügbar gemacht haben. Ein Herausgeber muss nicht Host seiner eigenen Website sein und kann stattdessen die herausgegebenen Informationen Websites (Informationsservern) zur Verfügung stellen, so dass Benutzer darauf zugreifen können. Der CGI 90 zum Registrieren von Herausgebern speichert die Registrierungsinformationen für Herausgeber in der Herausgeber-Datenbank 78.
  • Eine Upload-Client 79 ist in dem zentralen Server 70 zum Empfangen von Informationen von dem Uploadserver 47 über das Internet 20 vorhanden. Dies ermöglicht das periodische Abfragen von Informationsservern 40, um Transaktionsdaten von jeweiligen Transaktions-Datenspeichern 45 abzurufen. Die hochgeladenen Transaktions-Datendateien werden in einem Website-Transaktions-Datenspeicher 92 gespeichert. Eine Transaktionseinrichtung 80 ist mit dem Upload-Client 79 verbunden vorhanden, um die abgerufenen Transaktionsdaten in dem Website-Transaktions-Datenspeicher 92 zu verarbeiten. Die Transaktionsdaten werden in eine Kontendatenbank 83 eingegeben, die jeweilige Einträge für Benutzer und Herausgeber speichert. Jedes der Herausgeberkonten und der Benutzerkonten enthält Transaktionen, die abgeglichen, nicht abgeglichen, nicht akzeptiert oder beglichen sind, wie dies weiter untern ausführlicher beschrieben wird. Der Upload-Client 79 verwendet Informationen über den Standort von Websites aus der Website-Datenbank 77, um den Abfragevorgang auszuführen und die jeweiligen Uploadserver 77 zu kontaktieren. Auch die Transaktionseinrichtung 80 nutzt Informationen in der Website-Datenbank 77, Informationen in der Benutzer-Datenbank 76 und Informationen in der Herausgeber-Datenbank 78, um die Transaktionen zu verarbeiten und die entsprechenden Transaktionen den entsprechenden Benutzern und Herausgebern zuzuschreiben.
  • Der zentrale Server 70 ist des Weiteren mit einem Abgleichserver 84 versehen, der über das Internet 20 verbunden ist, so dass der Abgleichserver 84 mit einer Zahlungsanwendung 12 in Benutzer-Computern 10 verbunden werden kann. Der Abgleichserver 84 wird periodisch von Zahlungsanwendungen 12 kontaktiert, um einen Abgleichprozess der in dem Belegspeicher 14 in dem Benutzer-Computer 10 gespeicherten Belege mit Transaktionsinformationen für die Benutzer, die aus dem Benutzerkonto in der Kontodatenbank 83 gewonnen werden, und Transaktionsdaten, die in dem Website-Transaktions-Datenspeicher 92 gespeichert sind, durchzuführen. Der Abgleichserver 84 greift weiterhin auf die Benutzerdatenbank 76 zu, um den Abgleichvorgang zu ermöglichen, und auf einen Wechselkurs-Datenspeicher 91, um der Zahlungsanwendung 12 Wechselkurs-Daten bereitzustellen.
  • Der zentrale Server 70 ist des Weiteren mit einem Zahlungsserver 85 zum Abwickeln von Zahlungen über einen gesicherten Zahlungskanal zu Herausgeberkonten, Kunden und zum Empfangen von Zahlungen über den gesicherten Zahlungskanal von Benutzerkonten, beispielsweise einem entfernten Kreditkartenserver 4, versehen. Der Zahlungsserver 85 greift so auf die Kontendatenbank 83, die Benutzer-Datenbank 76 und die Herausgeber-Datenbank 78 zu, um den Zahlungsvorgang zu ermöglichen.
  • Der zentrale Server 70 ist des Weiteren mit einer Herausgeberkonten-Seiten CGI 81 und einer Benutzerkonten-Seiten-CGI 82 versehen, die auf die Konten-Datenbank 83 zugreifen, um es Herausgebern bzw. Benutzern zu ermöglichen, auf ihre Konteninformationen über das Internet 20 und den Webserver 71 zuzugreifen, so dass sie ihre Konten prüfen können. Die Herausgeberkonten-Seiten-CGI 81 greift auf die Herausgeber-Datenbank 78 zu, um die Schnittstellenverbindung zu dem Herausgeber zu ermöglichen, und die Benutzerkonten-Seiten-CGI 82 greift auf die Benutzer-Datenbank 76 zu, um die Schnittstellenverbindung zu dem Benutzer zu ermöglichen.
  • Der zentrale Server 70 kann auf jeder beliebigen geeigneten Verarbeitungsvorrichtung implementiert werden, die Computerprogramme implementiert. 16 ist eine schematische Darstellung der Struktur des zentralen Servers gemäß dieser Ausführung der vorliegenden Erfindung, der auf einem Universal-Computer implementiert ist. Der zentrale Server 70 weist eine Zeigeeinrichtung 102, beispielsweise eine Maus, eine Anzeigeeinrichtung 103 und eine Tastatur 104 auf. Eine Internet-Schnittstelleneinrichtung 101 ist vorhanden, um Verbindung zu dem Internet 20 zu ermöglichen. Die Internet-Schnittstellen-Einrichtung 101 kann ein Modem umfassen, umfasst jedoch normalerweise eine Einrichtung für dauerhafte Netzwerkverbindung, so beispielsweise eine LAN-Karte. Ein Programmspeicher 106, beispielsweise ein Festplattenlaufwerk, ein CD-ROM, ein Diskettenlaufwerk oder eine programmierbare Festwertspeichereinrichtung, wie beispielsweise eine Festkörperspeichereinrichtung ist vorhanden, um Programmcode zu speichern, der von einem Prozessor heruntergelesen und implementiert werden kann. Der Prozessor 100 liest Programmcode für einen Webserver aus dem Programmspeicher 106 und implementiert einen Webserver 100a. Der Prozessor 100 liest Programmcode für eine Benutzerregistrierungs-CGI aus dem Programmspeicher 106 und implementiert die Benutzerregistrierungs-CGI 100b. Programmcode für eine Herausgeberregistrierungs-CGI wird von dem Prozessor 100 aus dem Programmspeicher 106 gelesen, um eine Herausgeberregistrierungs-CGI 100c zu implementieren. Programmcode für eine Website-Registrierungs-CGI wird aus dem Programmspeicher 106 von dem Prozessor 100 gelesen, um eine Website-Registrierungs-CGI 100d zu implementieren. Programmcode für eine Benutzerkonten-Seiten-CGI wird aus dem Programmspeicher 106 durch den Prozessor 100 gelesen, um Benutzerkonten-Seiten-CGI 100e zu implementieren. Programmcode für eine Herausgeberkonten-Seiten-CGI wird aus dem Programmspeicher 106 von dem Prozessor 100 gelesen, um die Benutzerkonten-Seiten-CGI 100f zu implementieren. Programmcode für einen Upload-Client wird aus dem Programmspeicher 106 von dem Prozessor 100 gelesen, um den Upload-Client 100g zu implementieren. Programmcode für eine Transaktionseinrichtung wird aus dem Programmspeicher 106 von dem Prozessor 100 gelesen, um die Transaktionseinrichtung 100h zu implementieren. Programmcode für einen Abgleichserver wird aus dem Programmspeicher 106 von dem Prozessor 100 gelesen, um einen Abgleichserver 100i zu implementieren.
  • Programmcode für einen Zahlungsserver wird von dem Prozessor 100 aus dem Programmspeicher 106 gelesen, um einen Zahlungsserver 100j zu implementieren. Programmcode für einen Server zum Führen eines Informationsindex wird von dem Prozessor 100 aus dem Programmspeicher 106 gelesen, um einen Server 100k zum Führen eines Informationsindex zu implementieren.
  • Eine Speichereinrichtung 105, beispielsweise ein Festplattenlaufwerk, ein Diskettenlaufwerk, ein CD-ROM oder ein Direktzugriffsspeicher (RAM), ist vorhanden, um von dem Prozessor 100 in dem zentralen Server 70 verwendete Daten zu speichern. Obwohl die Datenspeichereinrichtung 105 als eine einzelne Datenspeichereinrichtung dargestellt ist, kann diese Vorrichtung natürlich als eine Vielzahl von Speichereinrichtungen, beispielsweise eine Anzahl von Festplattenlaufwerken, vorhanden sein. Die Datenspeichereinrichtung 105 speichert die Informationsindex-Datenbank, die Wechselkurs-Daten, die Benutzer-Datenbank, die Website-Datenbank, die Webseiten-Daten, die Herausgeber-Datenbank, die Konten-Datenbank, den Installationscode für die Website-Verwaltung, die Zentral-Informationsindex-Webseiten und die Website-Transaktionsdaten.
  • Alle Komponenten des zentralen Servers 70 sind durch einen Steuer-und-Daten-Bus 107 miteinander verbunden.
  • Die von dem zentralen Server 70 erfüllten Funktionen werden im Folgenden ausführlicher unter Bezugnahme auf die Flussdiagramme in 17–21 beschrieben.
  • Bevor ein Benutzer einen Service nutzen kann, muss er sich zunächst registrieren, und dieser Prozess ist in dem Flussdiagramm in der 17 dargestellt. Ein Benutzer verwendet seinen Webbrowser 13 zur Verbindung mit dem Webserver 71 über das Internet 20, um auf das Benutzerregistrierungs-Formular zuzugreifen (Schritt S100). Der Benutzer gibt die erforderlichen Registrierungsdaten ein (Schritt S101). Die Benutzerregistrierungs-CGI 86 empfängt die Registrierungsformular-Daten (Schritt 102) und weist dem Benutzer eine eindeutige Kennung zu (Schritt S103). Die Benutzerdaten werden dann durch die Benutzerregistrierungs-CGI 86 in die Benutzer-Datenbank 76 eingegeben, und die Daten werden nach der Benutzer-Kennung indexiert (Schritt S104). Die Benutzerregistrierungs-CGI 86 lädt dann den Zahlungsanwendungs-Installationscode, der in dem Speicher 87 für den Zahlungsanwendungs-Installationscode gespeichert ist, auf den Benutzer-Computer 10 herunter (Schritt S105). Die Installationsanwendung für die Zahlungsanwendung kann dann durch den Benutzer ausgeführt werden, um die Zahlungsanwendung 12 auf dem Benutzer-Computer 1 zu installieren. Der Installationsprozess speichert auch die eindeutige Kennung des Benutzers in einem Benutzererkennungs-Speicher 15, beispielsweise dem Festplatten laufwerk des Benutzer-Computers 10. Der Benutzer-Computer 10 ist somit bereit, den Dienst zu nutzen. Zunächst ist der belegte Speicher 14 leer, da keine früheren Transaktionen vorhanden sind. Der Benutzer kann auf die Ausgabenlimit-Schnittstelle zugreifen, um Ausgabenlimit-Daten in den Ausgabenlimit-Datenspeicher einzugeben. Der Belegspeicher 14 und der Ausgabenlimit-Datenspeicher können Segmente der Festplatte des Benutzer-Computers umfassen. Die Wechselkurs-Daten können durch den zentralen Server 70 periodisch auf den Benutzer-Computer zur Speicherung in dem Wechselkurs-Datenspeicher 16 heruntergeladen werden. Dies kann während des Abgleichprozesses stattfinden, der von dem Abgleichserver 84 durchgeführt wird und weiter unten ausführlicher beschrieben wird.
  • Der Prozess des Registrierens einer Website (Informationsserver) wird im Folgenden unter Bezugnahme auf das Flussdiagramm von 18 beschrieben. Ein Webmaster oder Administrator der Website (Informationsserver) verwendet den Webbrowser 48 auf dem Informationsserver 40, um über das Internet 20 auf den Webserver 71 zuzugreifen und Zugang zu dem Website-HTML-Registrierungsformular zu erhalten, das an dem zentralen Server 70 bereitgestellt wird (Schritt S110). Der Webmaster gibt die Daten der Website in das HTML-Registrierungsformular ein (Schritt S111). Die Registrierungsformular-Daten werden zu der Website-Registrierungs-CGI 88 gesendet (Schritt S112). Die Website-Registrierungs-CGI 88 weist der Website dann eine eindeutige Website-Kennung zu (Schritt S113), und die Website-Daten werden in die Website-Datenbank 77 nach der Website-Kennung indexiert eingegeben (Schritt S114). Die Website-Registrierungs-CGI 88 lädt den Installationscode für die Website-Verwaltungsanwendung von dem Speicher 89 für den Installationscode für die Website-Verwaltungsanwendung auf den Informationsserver 40 herunter (Schritt S115). Der Installationscode für die Website-Verwaltungsanwendung kann dann an dem Informationsserver ausgeführt werden, um alle erforderlichen Komponenten für die Implementierung des Dienstes zu installieren, das heißt den Website-Manger 53 und die drei CGI-Anwendungen 42, 43 und 44.
  • Das Verfahren zum Registrieren von Herausgebern von Informationen für den Dienst wird im Folgenden unter Bezugnahme auf das Flussdiagramm von 19 beschrieben.
  • Ein Herausgeber verwendet einen Computer mit einem Webbrowser, um auf den Webserver 71 zuzugreifen und Zugang zu dem Herausgeber-HTML-Registrierungsformular zu erhalten, das von dem zentralen Server 70 bereitgestellt wird (Schritt S120). Der Herausgeber gibt Daten in das Registrierungsformular ein (Schritt S121). Die Registrierungsformular-Daten werden zu der Herausgeber-Registrierungs-CGI 90 gesendet (Schritt S122) und die Herausgeber-Registrierungs-CGI weist dem Herausgeber eine eindeutige Kennung zu (Schritt S123). Die Herausgeber-Daten werden dann durch die Herausgeber-Registrie rungs-CGI 90 nach der Herausgeber-Kennung indexiert in die Herausgeber-Datenbank 88 eingegeben (Schritt S124).
  • Die Funktion des zentralen Servers 70 beim Aufrufen von Informationsservern 40 zum Abstimmen und Sammeln der Transaktionen wird im Folgenden unter Bezugnahme auf das Flussdiagramm in 20 beschrieben.
  • Der Upload-Client 79 an dem zentralen Server 70 ist so eingerichtet, dass er Websites aus der Website-Datenbank 77 identifziert und sie periodisch abfragt, um ihre jeweiligen Upload-Server 47 zu kontaktieren (Schritt S130). Der Upload-Server 47 an dem Informations-Server 40 benennt die aktuelle Transaktionsdatei nach Datum und Zeit, zu der sie zuerst von dem Upload-Client 79 angefordert wurde, gemäß UTC (Universal Coordinated Time) in der Form YYYYMMDDHHMMSS um (Schritt S131) und überträgt die Datei zu dem Transaktions-Online-Archiv-Datenspeicher 59 an dem Informations-Server 40 (Schritt S132). Der Upload-Server 47 fügt dann den Transaktions-Dateinamen in einen Index von Transaktions-Dateien an dem Informations-Server ein und setzt den Status auf "nicht gesendet". Der Upload-Server 47 verschlüsselt die umbenannte Transaktions-Datendatei und sendet sie zu dem Upload-Client 79 an dem zentralen Server (Schritt S132) und ändert bei Erfolg den Index-Status auf "gesendet". Der Upload-Client 79 liest die Transaktions-Daten und speichert diese in dem Website-Transaktions-Datenspeicher 92 an dem zentralen Server 70.
  • Der Upload-Client 79 des zentralen Servers untersucht dann die Benutzer-Datenbank 76 an dem zentralen Server 70 und sendet eine Liste von Änderungen an dem Status gesperrter Benutzer. Diese Informationen werden von dem Upload-Server 47 verwendet, um den Datenspeicher 46 für gesperrte Benutzerkonten an dem Informations-Server 40 zu aktualisieren (Schritt S133). Benutzer können von der Tätigung weiterer Käufe ausgeschlossen werden, wenn beispielsweise ihr Konto nicht ausgeglichen ist, das Konto geschlossen worden ist oder die Kreditkarte des Benutzers als gestohlen gemeldet ist oder aus einem anderen Grund nicht verwendet werden kann. Benutzer können vollständig von der Nutzung des Dienstes ausgeschlossen werden, wenn sie den Dienst beispielsweise missbraucht haben.
  • Der Upload-Server 47 kann das erneute Senden einer Datei oder eines Teils einer Datei von dem Online-Archiv-Datenspeicher 92 an dem Informations-Server anfordern. So kann der zentrale Server 70 den Verlust von Daten ausgleichen. Transaktions-Dateien in dem Online-Archiv-Datenspeicher 92 an dem Informations-Server 70 werden periodisch zu einem Offline-Archiv übertragen, so beispielsweise einem Magnetband- oder einem anderen Offline-Speichermedium, wenn das Alter einer Transaktions-Datei einen benutzerdefinierten Wert überschreitet oder wenn festgestellt wird, dass der freie Speicherplatz des Online-Archiv-Datenspeichers 92 knapp wird. Auf diese Weise speichern die in dem Transaktions-Datenspeicher 45 jedes Informations-Servers 40 gespeicherten Transaktionsdaten nur Transaktionsdaten für aktuelle Transaktionen. Dadurch wird die Menge an Informationen reduziert, auf die nicht autorisiertes Personal zugreifen könnte, und der Speicherbedarf an dem Informations-Server 40 wird verringert.
  • Die Transaktionseinrichtung 80 in dem zentralen Server 70 verarbeitet dann die von dem Upload-Client 79 empfangenen Transaktionsdaten und fügt die Transaktion zu den Benutzer- und Herausgeberkonten in der Konto-Datenbank 83 hinzu (Schritt S134). Die zu den Benutzerkonten und Herausgeberkonten hinzugefügten Transaktionen werden als nicht abgeglichene Transaktionen hinzugefügt, da diese lediglich Daten darstellen, die von den Informations-Servern empfangen werden. So enthalten die Benutzerkonten eine Summe nicht abgeglichener Transaktionen, die Kosten für den Benutzer darstellen, und die Herausgeberkonten weisen nicht abgeglichene Transaktionen für jeden Herausgeber für eine Anzahl von Benutzern auf, wobei dies Guthaben darstellt. Der Vorgang des Hinzufügens der Transaktionen zu der Konten-Datenbank 83 (Schritt S134) stellt jedoch keine Geldmittel bereit, auf die die Herausgeber zugreifen können. Die Geldmittel sind erst verfügbar, wenn sie abgeglichen worden sind. Periodisch findet der Abgleichvorgang durch die Zahlungs-Anwendung 12 auf dem Benutzer-Computer 10 statt (Schritt S135), der den Abgleich-Server 84 an dem zentralen System 70 kontaktiert. Dieser Vorgang wird im Folgenden unter Bezugnahme auf das Flussdiagramm in 21 ausführlicher beschrieben.
  • Das Ergebnis des Abgleichvorgangs besteht darin, dass entweder die Transaktionen abgeglichen werden, d. h. dass eine Übereinstimmung zwischen den von dem Informations-Server empfangenen Transaktionsdaten und den in dem Belegspeicher 14 gespeicherten Belegdaten an dem Benutzer-Computer vorhanden ist oder keine Übereinstimmung vorhanden ist und die Transaktion nicht akzeptiert wird. Die Transaktionseinrichtung 80 führt Sammeln der Transaktionen in der Konten-Datenbank 83 durch. Benutzer erhalten periodisch auf Basis ihrer gesammelten abgeglichenen Transaktionen auf ihrem Konto Rechnungen (Schritt S136). Diese Rechnungsstellung wird von dem Zahlungs-Server 85 in dem zentralen Server 70 ausgeführt, der eine Verbindung über einen gesicherten Zahlungs-Kanal zu einem Kreditkarten-Server 40 herstellt, um das Kreditkartenkonto des Benutzers zu belasten. Dazu greift er auf eine Benutzer-Datenbank 76 zu, um die erforderlichen Autorisierungsinformationen zum Autorisieren der Transaktion von dem Kreditkartenserver zu erlangen. Die Rechnungsstellung für die Benutzer findet periodisch statt, wenn die akkumulierte Summe einen bestimmten Schwellenwert erreicht, durch den die Transaktion kom merziell vertretbar wird, wenn beispielsweise der einzuziehende Betrag ausreichend hoch ist, um die Zahlung der Servicegebühr an die Kreditkartengesellschaft für die Transaktion vertretbar zu machen. Wenn die gesammelten abgeglichenen Transaktionen während eines bestimmten Zeitraums den Schwellenwert nicht erreicht haben, fordert der Zahlungs-Server 85 dennoch eine Zahlung einer Mindestsumme, beispielsweise 10 Dollar, die dem Benutzerkonto gutzuschreiben ist. Dadurch weist das Benutzerkonto ein Guthaben auf. Mit dieser periodischen Rechnungsstellung wird, selbst wenn ein Minimum nicht erreicht worden ist, die Möglichkeit umgangen, dass ein Benutzer weniger als das Minimum ausgibt und dafür keine Rechnung erhält. Stattdessen wird dem Benutzer eine Mindestsumme in Rechnung gestellt, und sein Konto weist solange ein Guthaben auf, bis der Benutzer das Guthaben ausgibt. Wenn das Guthaben des Benutzers verbraucht ist, wird die Zeit, nach der dem Benutzerkonto der Mindestbetrag in Rechnung gestellt wird, aus dem Datum der ersten Transaktion berechnet, die von einem Benutzer getätigt wird, nachdem das Guthaben verbraucht ist.
  • Wenn die Zahlung von der Kreditkarte des Benutzers durch den Zahlungsserver 85 empfangen wird (Schritt S137), werden die Transaktionen in der Kontendatenbank 83 in den Benutzer- und Herausgeber-Konten als beglichen markiert (Schritt S138). Wenn die gesamten beglichenen Transaktionen in einem Herausgeberkonto einen Schwellenwert erreichen (Schritt S139) wird der Zahlungsserver 85 angewiesen, eine Zahlung über den gesicherten Kanal auf das Herausgeberkonto zu veranlassen. Die akkumulierten beglichenen Transaktionen sollten wieder einen Mindestwert erreichen, um die Überweisung des Geldes auf ein Herausgeberkonto wirtschaftlich vertretbar zu machen. Geld wird nur auf das Herausgeberkonto überwiesen, wenn Zahlung von dem Benutzer empfangen worden ist.
  • Der Abgleichvorgang (Schritt 135 in 20) wird im Folgenden ausführlicher unter Bezugnahme auf das Flussdiagramm in der 21 beschrieben.
  • Wenn eine Zahlungsanwendung 12 initialisiert wird (Schritt S140), wartet sie eine vorgegebene Verzögerungszeit ab (Schritt S141), bevor eine TCP/IP-Verbindung über das Internet 20 zu dem Abgleichserver 84 in dem zentralen Server 70 hergestellt wird (Schritt S142). Die eindeutige Benutzerkennung, die in dem Benutzerkennungs-Speicher 15 an dem Benutzer-Computer 10 gespeichert ist, wird zu dem Abgleichserver 84 gesendet, um den Benutzer zu identifizieren. Wenn die Verbindung nicht erfolgreich ist (Schritt S143), wartet die Zahlungsanwendung eine vorgegebene Zeit nach dem letzten Abgleich-Versuch ab (Schritt S141), bevor sie erneut versucht, mit dem Abgleichserver 84 in Verbindung zu treten. Wenn die Verbindung erfolgreich ist (Schritt S143), stellt die Zahlungsanwendung fest, ob der Abgleichserver besetzt ist (Schritt 144). Wenn der Abgleichserver besetzt ist, sendet der Ab gleichserver der Zahlungsanwendung einen Vorschlag für eine Kontaktzeit und die Zahlungsanwendung berechnet eine neue Verzögerungszeit (Schritt S145). Die Zahlungsanwendung wartet dann die Verzögerungszeit ab (Schritt S141), bevor sie erneut versucht, mit dem Abgleichserver in Verbindung zu treten (Schritt S142). Wenn der Abgleichserver nicht besetzt ist (Schritt S144), sendet der Abgleichserver 84 der Zahlungsanwendung 12 alle nicht abgeglichenen Transaktionen für den Benutzer in der Konten-Datenbank 83 (Schritt S141). Die Zahlungsanwendung 12 vergleicht die Transaktionen mit Belegen in den Beleg-Speicher 14 und markiert die übereinstimmenden Belege als abgeglichen (Schritt 147). Der Abgleichserver 84 sendet auch die Wechselkurs-Daten aus einem Wechselkurs-Datenspeicher 91 in dem zentralen Server 70 zu der Zahlungsanwendung 12, und der Zahlungsanwendung 12 aktualisiert die in dem Wechselkurs-Datenspeicher 16 gespeicherten Wechselkurs-Daten (Schritt 148). Wenn alle Transaktionen mit Belegen in dem Belegspeicher 14 übereinstimmen (Schritt 149), sendet die Zahlungsanwendung 12 eine OK-Nachricht zu dem Abgleichserver 84 (Schritt S153). Der Abgleichserver 84 markiert alle Transaktionen für den Benutzer in der Konten-Datenbank 83 als abgeglichen (Schritt S154). Die Zahlungsanwendung 12 beendet dann die Verbindung zu dem Abgleichserver 84 (Schritt S155), und die Transaktionseinrichtung modifiziert die Benutzer- und Herausgeberkontenstände in der Konten-Datenbank 83 (Schritt S155).
  • Wenn nicht alle Transaktionen mit Belegen übereinstimmen (Schritt S149) sendet die Zahlungsanwendung 12 eine Liste abgelehnter Transaktionen zu dem Abgleichserver 84 (Schritt S150). Der Abgleichserver 84 markiert die übereinstimmenden Transaktionen als abgeglichen und die nicht übereinstimmenden Transaktionen als nicht akzeptiert (Schritt 155). Die Zahlungsanwendung beendet dann die Verbindung mit dem Abgleichserver 84 (Schritt 155) und die Benutzer- und Herausgeberkontenstände werden durch die Transaktionseinrichtung 80 modifiziert (Schritt S152).
  • Aus dem oben unter Bezugnahme auf 20 und 21 beschrieben Verfahren ist zu ersehen, dass der zentrale Server die Transaktionsdaten für die Informationsserver für Benutzer und Herausgeber sammelt und einen Abgleichprozess ausführt, um eine Sicherheitsstufe zu gewährleisten und zu bestätigen, dass übereinstimmende Transaktionsdaten an dem Informationsserver 40 und dem Benutzer-Computern 10 vorhanden sind. Für nicht übereinstimmende Transaktionen wird dem Benutzer keine Rechnung gestellt, und der Herausgeber wird dafür nicht bezahlt. Transaktionen, die in der Konten-Datenbank als nicht akzeptiert markiert sind, können auf an den Informationsserver ausgeführte nicht autorisierte Transaktionen hinweisen. Dies ermöglicht eine Prüfung, um korrekte Rechnungsstellung zu gewährleisten.
  • Da die Zahlungsanwendung 12 Belege als abgeglichen markiert, muss, wenn der nächste Abgleichvorgang ansteht, die Zahlungs-Anweisung nur nicht markierte Belege prüfen, um den Verarbeitungsaufwand zu verringern, der erforderlich ist, um Transaktionen mit nicht abgeglichenen Belegen zu vergleichen.
  • Der Zahlungs-Anwendung kann auch Belege als abgelaufen markieren oder Belege löschen, die abgelaufen sind, wenn erfasst wird, dass der Gültigkeitszeitraum zuzüglich des Transaktionsdatums jenseits des aktuellen Datums der Uhr des Benutzer-Computers liegt. Dadurch wird die Speicherkapazität verringert, die für den Belegspeicher 14 erforderlich ist, da es nicht notwendig ist, nutzlose abgelaufene Belege zu speichern. Natürlich werden, wenn die Belege verglichen mit den von dem Benutzer eingegebenen Ausgabelimit kurzlebig sind, die gesamte Transaktionsdaten, die in dem Ausgabelimit-Datenspeicher zum Überwachen der Ausgaben gespeichert sind, nicht beeinflusst. Die Transaktions-Gesamtsumme wird als eine Gesamtsumme gespeichert, bei der Datum und Zeit mit jeder Transaktion verknüpft sind, so dass bei diesem Beispiel die Transaktionen von gestern nicht für die heutige Ausgabelimit-Gesamtsumme von 7 Dollar zählen, wie dies in 13 dargestellt ist.
  • Der zentrale Server 70 enthält, wie in 15 zu sehen ist, eine Herausgeberkonten-Seiten-CGI 81 und eine Benutzerkonten-Seiten-CGI 82, die es dem Herausgeber bzw. dem Benutzer ermöglichen, auf ihre Konteninformationen über den Websurfer 71 und die entsprechende CGI 81 oder 82 zuzugreifen. Die Benutzer, der Herausgeber und der Website-Manager können auf ihre in den Datenbanken 76, 77 und 78 gespeicherten Details über den Webserver 71, der entsprechende HTML-Formulare bereitstellt, zugreifen und sie ändern. Um dies zu tun, gibt der Benutzer, Herausgeber oder Website-Manager eine Kennung und ein Passwort auf einer gesicherten HTML-Seite ein, die von dem Webserver 71 bereitgestellt wird. Die jeweilige CGI 86, 88 oder 90 liefert das HTML-Formular mit den Kontendetails, so dass der Benutzer, der Herausgeber oder der Website-Manager das Formular ändern kann. Der entsprechende CGI 86, 88 oder 90 (oder eine zugehörige CGI) prüft und aktualisiert dann die Kontendetails in der jeweiligen Datenbank 76, 77 oder 78.
  • Die durch die Transaktionseinrichtung 80 gesammelten Transaktionen in der Kontendatenbank 83 können in unterschiedlichen Währungen vorliegen, und daher werden die Wechselkurs-Daten in den Wechselkurs-Datenspeicher 91 verwendet, um die Währung in eine Währung des Benutzers umzuwandeln, so dass das Benutzerkonto in der von dem Benutzer gewählten Währung geführt wird. Jede Gruppe von Wechselkurs-Daten enthält eine Seriennummer, so dass, wenn die Wechselkurs-Daten in dem Benutzer-Computer aktualisiert werden müssen, dies einfach erreicht werden kann, indem die Seriennummern der Wechselkurs-Daten in dem Wechselkurs-Datenspeicher 91 in dem zentralen Server 70 und die Seriennummer der Wechselkurs-Daten in dem Wechselkurs-Datenspeicher 16 an dem Benutzer-Computer verglichen werden. Wenn sie sich unterscheiden, werden die Wechselkurs-Daten durch den Abgleichserver über das Internet 20 zu dem Wechselkurs-Datenspeicher 16 gesendet (Schritt S148), wie dies oben beschrieben ist.
  • Die Funktion des Website-Managers 53 an dem Informationsserver 40 zum Einrichten und Verwalten der Website, an der Informationen für Benutzer verfügbar gemacht werden, wird im Folgenden unter Bezugnahme auf 22 bis 29 beschrieben.
  • 22 stellt die Benutzerschnittstelle 110 dar, die durch die Implementierung des Website-Managers 53 erzeugt wird. Der Website-Manager 53 ermöglicht es dem Webmaster, die Site-Index-Informationen in dem Site-Index-Informationsspeicher 58 zu konfigurieren, Gebührenparameter in dem Informationsgebühren-Datenspeicher 51 einzustellen und das Verfahren zu organisieren, nach dem die Informationen für den Benutzer indexiert werden.
  • Es können Site-Gebühren-Standarddetails können eingegeben werden, die die Gebühr anzeigen, die für alle Inhalte erhoben wird, die an der Website verkauft werden, wenn diese nicht anders festgelegt werden. Die in 25 gezeigte Schnittstelle wird von dem Admin-Menü 109 aufgerufen, das in 22 dargestellt ist. Das Standardverfahren, mit dem die Reihenfolge bestimmt wird, in der Publikationsausgabe-Titel in dem Drop-Down-Kästchen 122 der 22 dargestellten Schnittstelle angezeigt werden, kann unter Verwendung von Steuerelementen 191, 192 und 193 in 25 definiert werden. Die Schaltfläche 195 ermöglicht es, eine HTML-Vorlage der Seite auszuwählen, die zum Erzeugen von Index-Webseiten verwendet wird, wenn keine Vorlage für eine Publikation unter Verwendung der Steuerelemente 158 und 159 in 23 definiert worden ist. Der HTML-Vorlagen-Dateipfad ist in Kästchen 197 dargestellt. Eine HTML-Vorlage umfasst eine Webseiten-Vorlage (HTML-Code), die so erzeugt wird, dass sie spezielle benutzerdefinierte Tags enthält, beispielsweise <XYZ> und </XYZ>, die keine Standard-HTML-Tags sind und verwendet werden können, um die Position für die Webseiten-Vorlage zu identifizieren, an der Index-Links automatisch einzufügen sind, wie dies im Folgenden ausführlicher erläutert wird. Optionsfelder 198 ermöglichen es, die Publikation entweder pro Ausgabe oder pro Seite zu berechnen. Wenn eine Publikation so definiert ist, dass sie pro Ausgabe berechnet wird, erscheint für einen Benutzer, der Download einer gebührenpflichtigen Seite oder Datei anfordert, eine Gebühr für die gesamte Ausgabe. Weitere Seiten der Ausgabe werden dem Benutzer ohne weiter Berechnung heruntergeladen. Bei diesem Beispiel sind die Berechnungsdetails pro Seite eingestellt. Eine Herausgeberkennung wird aus einer Liste von Herausgebern ausgewählt, um die Herausgeberkennung in dem Kästchen 203 anzuzeigen. Eine Währungstyp (in diesem Fall US-Dollar) wird in Kästchen 199 ausgewählt, und Kosten können in Kästchen 200 eingegeben werden. Die Auswahl in Kästchen 201 bestimmt die Beschreibung der Berechnungseinheit, die im Index anzuzeigen ist. Bei diesem Beispiel würde "$ 0,02 pro Seite" angezeigt. In Kästchen 202 wird der Gültigkeitsdauer-Parameter eingegeben, der bei diesem Beispiel als ein Jahr angegeben ist. Der Standard-Dateityp, der in Kästchen 115 in 22 anzuzeigenden Datei wird in Drop-Down-Kästchen 204 ausgewählt. Diese Informationen werden für die zu verwendende Site gespeichert, wenn die Schnittstelle in 23 angezeigt wird und die Publikation unter Verwendung des Drop-Down-Kästchens 151 ausgewählt wird und Kontrollkästchen 156 angekreuzt wird, um anzuzeigen, dass die Seiten-Standard-Gebührendaten für dies Publikation verwendet werden sollten. 23 Standardparameter für eine Website einzugeben, die für eine bestimmte Publikation in der in 23 dargestellten Schnittstelle oder eine spezielle Ausgabe oder spezielle Seite oder Datei der in 22 dargestellten Schnittstelle geändert werden können.
  • Ein Drop-Down-Kästchen 121 steht, wie in 22 zu sehen ist, zur Verfügung, um die Publikation auszuwählen. Schaltfläche 112 ruft die Schnittstelle auf, wie sie in 23 dargestellt ist. 23 ermöglicht es, Parameter für eine Publikation, bei der sich in diesem Fall um "Personal-Computer World" handelt, einzustellen. Drop-Down-Kästchen 151 ermöglicht die Auswahl der Veröffentlichung. Schaltfläche 152 ruf eine Schnittstelle auf, die es ermöglicht, den Titel der Publikation zu ändern. In diesem Fall wird die Publikation als monatliche Publikation angegeben. Das Verfahren, mit dem die Reihenfolge bestimmt wird, in Titel von Ausgabe der Publikation der in dem Drop-Down-Kästchen 122 der in 22 gezeigten Schnittstelle angezeigt werden, kann unter Verwendung von Steuerelementen 153, 154 und 155 definiert werden. Wenn Kontrollkästchen 156 angekreuzt wird, werden die Standard-Gebührendaten der Seite für die Publikation verwendet. Die Schaltfläche 159 ermöglicht es, eine HTML-Vorlage für die Publikation auszuwählen, die zum Erzeugen von Index-Webseiten für alle Inhaltsseiten für die Publikation zu verwenden ist. Der HTML-Vorlagen-Dateipfad ist in Kästchen 158 dargestellt. Eine HTML-Vorlage umfasst eine Webseiten-Vorlage (HTML-Code), die so erzeugt wird, dass sie spezielle benutzerdefinierte Tags, beispielsweise <XYZ> und </XYZ>, die keine Standard-HTML-Tags sind, die verwendet werden können, um die Position in der Webseiten-Vorlage zu identifizieren, an der Index-Links automatisch einzufügen ist, wie dies weiter unten ausführlich beschrieben wird.
  • Es können Publikationsgebühren-Standarddetails eingegeben werden, die die Gebühr anzeigen, die für die Publikation erhoben wird, wenn dies nicht geändert wird. Optionsfelder 160 ermöglichen es, die Publikation entweder pro Ausgabe oder pro Seite zu berechnen. Wenn eine Publikation als pro Seite zu berechnen definiert ist, erscheint einem Benutzer, der Download einer gebührenpflichtigen Seite oder Datei anfordert, eine Gebühr für die gesamte Ausgabe. Weitere Seiten der Ausgabe werden dem Benutzer ohne weitere Gebühren heruntergeladen. Bei diesem Beispiel sind die Gebührendetails pro Seite eingestellt. Eine Herausgeberkennung wird aus einer Liste von Herausgebern ausgewählt, um die Herausgeberkennung in dem Kästchen 165 zu zeigen. Eine Währungstyp (in diesem Fall US-Dollar) wird in Kästchen 161 ausgewählt, und Kosten pro gebührenpflichtige Einheit (entweder Ausgabe oder Seite oder Datei) können in Kästchen 162 eingegeben werden. Die Auswahl in Kästchen 163 bestimmt die Beschreibung der in dem Index anzuzeigenden Gebühreneinheit. Bei diesem Beispiel würde "0,05 Dollar pro Seite" angezeigt. In Kästchen 164 wird der Gültigkeitsdauer-Parameter eingegeben, der bei diesem Beispiel als unbegrenzt angegeben ist. In Kästchen 167 können Abonnementzeiträume und Kosten eingegeben werden, so dass ein Benutzer eine Anzahl bestimmter Ausgaben abonnieren kann. Die Ausgaben, auf die ein Benutzer bei einem Abonnement zugreifen kann, werden durch die Veröffentlichungsdaten der Ausgaben und das Anfangsdatum sowie die Dauer des erworbenen Abonnements bestimmt. Die Benutzer können weiter auf Ausgaben zugreifen, die sie abonniert haben, nachdem der Abonnement-Zeitraum verstrichen ist. Diese Informationen werden für die Publikation gespeichert, um sie zu verwenden, wenn die Schnittstelle in 22 angezeigt wird und die Ausgabe der Publikation unter Verwendung des Drop-Down-Kästchens 122 ausgewählt wird und das Kontrollkästchen 128 angekreuzt wird und anzeigt, dass die Publikations-Standard Gebührendaten für diese Ausgabe verwendet werden sollten. 23 ermöglicht es so, Standardparameter für eine Publikation anzugeben, die für eine bestimmte Ausgabe oder bestimmte Seite oder Datei in der in 22 gezeigten Schnittstelle geändert werden können.
  • In 22 können Details der Ausgabe der Publikation eingegeben und ausgewählt werden. Die Ausgabe kann im Drop-Down-Kästchen 122 ausgewählt werden. Schaltfläche 114 ruft die in 26 dargestellte Schnittstelle auf, aus der das Verzeichnis ausgewählt werden kann, das die Dateien enthält, die die Ausgabe der Publikation bilden. Das ausgewählte Ausgabenverzeichnis ist in Kästchen 123 dargestellt.
  • Die in der in 26 gezeigte Schnittstelle zur Auswahl angebotenen Verzeichnisse sind auf diejenigen beschränkt, die durch den System-Administrator als zugelassene Grundverzeichnisse definiert sind. Diese werden in der in 27 gezeigten Schnittstelle definiert, die von dem Admin-Menü 109 aus zugänglich ist, das in 22 gezeigt wird. Nach Definition wird dem zugelassenen Verzeichnis, das in Spalte 182 von 27 definiert ist, ein in Spalte 181 gezeigter Token-Wert zugeordnet. Der durch eine rechteckige Klammer abgegrenzte Token-Wert wird in den URL-Links verwendet, die in den HTML-Indexdateien und Inhalts dateien erzeugt werden, um auf den entsprechenden Pfad des zugelassenen Grundverzeichnisses zu verweisen. Benutzer können als ein Ausgaben-Verzeichnis 123 jedes Verzeichnis auswählen, das ein zugelassenes Grundverzeichnis ist, oder ein Verzeichnis, das ein zugelassenes Grundverzeichnis an seiner Wurzel aufweist. So wird verhindert, dass Benutzer-Inhalte in Verzeichnissen zum Verkauf einstellen, die nicht autorisiert, und damit ein potentielles Sicherheitsrisiko sind. Zusätzlich kann die gesamte Struktur der Rechner oder Netzwerke oder Speichereinrichtungen oder Verzeichnisse geändert werden, ohne dass der Standort jeder Gruppe von Dateien neu definiert werden muss, die die verschiedenen Ausgaben der Publikation bilden. Zusätzlich verstärkt diese Verschleierung die die Widerstandsfähigkeit des Systems gegenüber böswilligen Angriffen über das Internet.
  • In Kästchen 115 in 22 sind die in dem Ausgaben-Verzeichnis enthaltenen Dateien aufgelistet. Diese Dateien enthalten normalerweise die Seiten, Kapitel oder andere Unterteilungen der Ausgabe der Publikation. Die in Kästchen 115 aufgelisteten Dateien können auf diejenigen mit dem Dateityp beschränkt sein, der in dem Drop-Down-Kästchen 124 ausgewählt wird, so dass Dateien, die nicht zur Veröffentlichung bestimmt sind, so beispielsweise administrative Datendateien, von der Veröffentlichung ausgeschlossen werden. Indexeinträge identifizieren die Indexstruktur für die Informationen. Eine Zentral-Indexkategorie kann eingegeben und unter Verwendung der Schaltfläche 116 ausgewählt werden. Diese zeigt die zentrale Indexkategorie an, in der der Titel der Ausgabe der Publikation, die in Kästchen 119 definiert ist, in der Informationsindex-Datenbank 75 an dem zentralen Server 70 angeordnet wird. Eine Site-Indexkategorie kann unter Verwendung der Schaltfläche 118 eingegeben und ausgewählt werden, um die in 24 gezeigte Schnittstelle anzuzeigen. Bis zu sechs Zentral-Index- und sechs Site-Index-Einträge können für eine Ausgabe definiert werden, wobei jeder separate Eintrag mit einem Steuerelement 126 ausgewählt wird. Das heißt, bis zu sechs separate Werte können in Kästchen 117, 119 und 142 eingegeben werden.
  • 24 zeigt die Lokal-Index-Kategorien und stellt eine hierarchische Organisation von Informationen bereit. In diesem Fall können die Ausgaben von fünf Jahrgängen der Zeitschrift "Personal Computer World" ausgewählt werden. So können diese Indexdaten für die Organisation der Informationen verwendet werden. In Kästchen 119 in 22 ist der Titel der Ausgabe definiert. Steuerfläche 120 ruft eine Schnittstelle auf, in der eine Bilddatei ausgewählt werden kann, die die Ausgabe darstellt. Der Pfad der Bilddatei wird in Kästchen 127 angezeigt. So ist für die September-Ausgabe von "Personal Computer World" aus dem Jahr 1999 ein Miniaturbild verfügbar.
  • Wenn Kontrollkästchen 128 angekreuzt wird, verwendet die ausgewählte Ausgabe die Publikations-Standard-Gebührendaten. Wenn Kontrollkästchen 128 nicht angekreuzt wird, bezieht die ausgewählte Ausgabe ihre Standard-Gebühreninformationen von den Steuerelementen 129, 130, 131, 132, 133 und 134 in 22. Mit Steuerelement 129 kann ein Benutzer auswählen, ob die in Kästchen 131 definierte Gebühr für eine gesamte Ausgabe oder eine einzelne Seite oder Datei erhoben wird. Ein Benutzer kann die Währung mit den Kästchen 130 und die Kosten mit dem Kästchen 131 auswählen. Die Auswahl in dem Kästchen 132 bestimmt die Beschreibung der Gebühreneinheit, die in dem Index angezeigt wird. Bei diesem Beispiel würde "3,95 Dollar pro Zeitschrift" angezeigt. Der Gültigkeitszeitraum kann ebenfalls mit Kästchen 133 ausgewählt werden, und die Herausgeberkennung kann mit Kästchen 134 ausgewählt werden. Auch die Publikationsdaten können mit Kästchen 135 ausgewählt werden.
  • Die Gebühreninformationen für einzelne Seiten oder Dateien können separat definiert werden, um die Standard-Gebühreninformationen für die Ausgabe zu ändern. Einzelne Seiten oder Dateien können in Kästchen 115 ausgewählt werden. Wenn Kästchen 136 angekreuzt wird, verwendet die Seite oder Datei, die in Kästchen 115 ausgewählt wird, die Standardwerte der Gebühreninformation für die Ausgabe. Wenn Kästchen 136 nicht angekreuzt wird, bezieht die Seite oder Datei, die in Kästchen 115 ausgewählt wird, ihre Gebühreninformationen von Steuerelementen 137, 138, 139, 140 und 141 in 22. Ein Benutzer kann die Währung für die Seite oder Datei mit dem Kästchen 137, die Kosten für die Seite oder Datei mit dem Kästchen 138 auswählen. Die Auswahl in Kästchen 139 bestimmt die Beschreibung der Gebühreneinheit, die in dem Index angezeigt wird. Der Gültigkeitszeitraum für die Seite oder Datei kann ebenfalls mit Kästchen 140 ausgewählt werden, und die Herausgeberkennung für die Seite oder Datei kann mit Kästchen 141 ausgewählt werden.
  • So können die Gebühreninformationen für eine große Menge an Inhalten zum Verkauf mit minimalem Eingabeaufwand definiert werden, und dennoch für eine einzelnen Ausgabe oder eine einzelne Seite oder Datei leicht geändert werden.
  • In Kästchen 125 können Textinformationen für jede Seite oder Datei als ein Indextitel eingegeben werden. Dadurch ist es möglich, den Text als Link statt als Bild einzugeben.
  • Unter Verwendung des Website-Managers 53 können Details über die hierarchische Indexstruktur der Site konstruiert werden, um einen Site-Index auszubilden, der die Organisation von Informationen identifiziert. Dieser wird in dem Site-Informations-Indexspeicher 58 gespeichert, und die Gebühreninformation, die Haupt-Site-Kennung, Site-Kennung, Dateikennung, Inhaltskennung, Herstellerkennung, Währung, Gültigkeitszeitraum, Herausgeberken nung, Veröffentlichungsdatum und die Einheit, auf die sich die Kosten beziehen, werden in dem Informationsgebühren-Datenspeicher 51 gespeichert. Auf diese Informationen kann durch die erste und die dritte CGI-Anwendung 43 und 44 unter Verwendung der Dateikennung für CGI-Anwendung 1 und der Anwendungskennung für CGI-Anwendung 3, das heißt für Abonnements, zugegriffen werden. Für Abonnements werden auch Abonnement-Informationen in Informationsgebühren-Datenspeicher eingegeben, jedoch werden diese nicht nach Datei-Kennung (die Inhaltskennung einschließt) indexiert, sondern nach Publikationskennung. Informationen in dem Informationsgebühren-Datenspeicher 51 enthalten alle Informationen, die zum Erzeugen des Transaktionsbeleges und des Abonnementsbeleges erforderlich sind.
  • Wenn ein Benutzer die Site-Index-Hierarchie konstruiert hat und die Informationen in gewünschter Weise angeordnet hat, muss/müssen entweder ein Titel oder mehrere Titel in Kästchen 125 oder ein Bild unter Verwendung von Kästchen 127 für jeden Knoten in dem Index-Baum, das heißt für jede Seite von Informationen (das Blatt des Baums) oder für jeden Knoten, wie beispielsweise eine Ausgabe, ein Jahr oder eine Publikation, wie beispielsweise "Personal Computer World", bereitgestellt werden.
  • Nachdem die hierarchische Konstruktion von Index-Daten konstruiert worden ist und als Link auf einer Index-Webseite zu verwendende Daten eingegeben worden sind, kann der Benutzer Schaltfläche 111 auswählen, und der Website-Manager verwendet die geeigneten HTML-Vorlagen, um automatisch Index-Webseiten wie die in 28 gezeigte zu erzeugen. Wie in der in Website-Adresse in 28 zu sehen ist, identifiziert das Ausgabe-Verzeichnis den Verzeichnisweg für die Index-Webseite. Bei diesem Beispiel sind 3 Miniaturbilder in einer Vorlage angeordnet. Die Index-Webseite enthält auch Code, um einem Benutzer Kosteninformationen bereitzustellen. In dieser Ausführung ist zu sehen, dass die Webseite die Möglichkeit aufweist, Mouse-over-Bedienung bereitzustellen, durch die dem Benutzer die Kosten pro Seite angezeigt werden können.
  • 27 ist ein Flussdiagramm, das das Verfahren zum Erzeugen der Index-Webseiten darstellt. Zunächst verwendet ein Benutzer den HTML-Editor 57, um HTML-Vorlagen für Index-Webseiten für verschiedene Knoten in dem Index-Baum zu erzeugen (Schritt S160). Die HTML-Vorlagen sind in dem HTML-Vorlagen-Speicher 56 gespeichert, der von dem Website-Manager 53 gelesen werden kann. Der HTML-Editor 57 kann jeden proprietären HTML-Editor oder auch einen Text-Editor zum Schreiben von HTML-Code umfassen.
  • Der Benutzer verwendet auch einen Bild-Editor 54 zum Zugreifen auf Information in dem Speicher 52 für gebührenpflichtige Informationen, um Miniaturbilder für die Informationen zu erzeugen (Schritt S161). Die Miniaturbilder werden in dem Miniaturbild-Speicher 55 gespeichert, und mit dem Website-Manager kann auf sie zugegriffen werden. Der Bild-Editor 54 kann jedes herkömmliche Bildbearbeitungsprogamm umfassen.
  • Der Benutzer verwendet dann den Website-Manager 53, um Daten über Preis, Währung, Gültigkeitszeitraum, Herausgeberkennung, Site-Kennung, Veröffentlichungsdaten usw. einzugeben, wie dies oben beschrieben ist (Schritt S162). Wenn der Benutzer die Schaltfläche 111 auswählt, verwendet der Website-Manager die HTML-Vorlagen, die Miniaturbilder und die von dem Benutzer eingegebenen Informationen, um Index-Webseiten für Informationen und Informationsgebühren-Daten zu erzeugen (Schritt S163). Die Index-Webseiten werden in dem Speicher 50 für Informationsindex-Webseiten gespeichert, und die Informationsgebühren-Daten werden in dem Informationsgebühren-Datenspeicher 51 gespeichert.
  • Der Server 74 zum Führen des Zentral-Informationsindex führt und aktualisiert den Datenspeicher 73 für Zentral-Informationsindex-Webseiten. Dazu kann der Server 74 zum Führen des Zentral-Informationsindex auch Anforderungen von dem Website-Manager 53 zum Hinzufügen oder Editieren von Zentral-Index-Knoten empfangen. Eine Website kann beispielsweise wünschen, einen neuen Publikationstitel zu einer Zentral-Indexkategorie oder einem Knoten hinzuzufügen. Die Gewährung dieser Forderung wird von der "Vertrauensstufe" der betreffenden Website gesteuert. Einer Website mit einer hohen "Vertrauensstufe" wird ohne Einschränkungen gestattet, Index-Kategorien hinzuzufügen oder zu editieren. Eine Forderung von einer Website mit einer niedrigeren "Vertrauensstufe", eine Indexkategorie oder einen Knoten hinzuzufügen oder zu addieren, löst den manuellen Eingriff einer Bewegungsperson an dem zentralen Server 70 aus.
  • Die automatische Erzeugung der Informationsindex-Webseiten verwendet die hierarchischen Index-Informationen, um zu bestimmen, wie die in die HTML-Vorlage eingefügten Links organisiert und angeordnet werden. So ist der Webmaster in der Lage, den Website-Manager zu verwenden, um die Reihenfolge der Dateien auszuwählen und die Reihenfolge auszuwählen, in der sie auf der Index-Webseite auftauchen. Der Website-Manager ordnet die Miniaturbilder automatisch auf der Index-Webseite entsprechend der Reihenfolge der Indexdaten an und gewährleistet so eine logische Ordnung der Links zu den Informationen für den Benutzer zum Zugreifen darauf.
  • Das Verfahren zur zeitlichen Synchronisation an dem Informationsserver und dem Benutzer-Computer wird im Folgenden unter Bezugnahme auf 30 und 31 beschrieben.
  • Ein wichtiger Faktor für die Sicherheit des Systems ist die Prüfung von Belegen durch die Informationsserver und die Benutzer-Computer. Ein Prüfungsvorgang beruht darauf, dass festgestellt wird, ob die Belege abgelaufen sind. Dies macht eine Bezugszeit erforderlich. Eine Bezugszeit kann von der inneren Uhr des Benutzer-Computers und des Informationsservers bezogen werden. Diese Uhren sind jedoch möglicherweise nicht synchronisiert und können von dem Benutzer oder von dem Webmaster verstellt werden. Dies würde es einem Benutzer oder Webmaster ermöglichen, den Grundvorgang zu umgehen, indem die innere Uhr des Computers verstellt wird. So könnte ein Benutzer beispielsweise die innere Uhr des Benutzer-Computers zurückstellen, so dass der Beleg als gültig bestätigt und gesendet wird. Des Weiteren könnte ein Website-Manager die Uhr an einem Informationsserver vorstellen, so dass Belege stets als ungültig beurteilt werden und Benutzer stets neu für Informationen zahlen müssen und neue Belege ausgestellt werden.
  • Ein Verfahren, mit dem dies überwunden werden könnte, würde darin bestehen, die innere Uhr des Benutzer-Computers und der Informationsserver periodisch neu zu synchronisieren. Die Neusynchronisation innerer Uhren kann jedoch erhebliche Probleme für andere Vorgänge verursachen, die von den Computern ausgeführt werden.
  • Daher wird in dieser Ausführung der vorliegenden Erfindung die Neusynchronisation der Uhren an den Computern vermieden, indem eine Offset-Zeit an jedem Computer bestimmt wird und die Offset-Zeit für die Verarbeitung von Daten verwendet wird.
  • 30 ist ein Flussdiagramm, das einen Prozess darstellt, der an dem Informationsserver gemäß einer Ausführung der vorliegenden Erfindung implementiert wird. Periodisch tritt der Informationsserver mit einem Bezugs-Computer in Verbindung, um eine Bezugszeit abzurufen (Schritt S170). Eine Offset-Zeit zwischen der Zeit der inneren Uhr der Informationsserver und der Bezugszeit wird berechnet (S171). Eine tatsächliche Zeit wird dann unter Verwendung der Zeit der inneren Uhr des Informationsservers und der berechneten Offset-Zeit berechnet (Schritt S172). Wenn der Informationsserver die Anforderung von Informationen empfängt, stellt er fest, ob ein Beleg mit einer Anforderung von Informationen vorhanden ist (Schritt S173). Wenn dies nicht der Fall ist, wird ein Beleg unter Verwendung der tatsächlichen Zeit erzeugt (Schritt S175). Ein Beleg kann dann zu dem Benutzer gesendet werden. Wenn ein Beleg mit der Anforderung von Informationen von dem Benutzer-Computer empfangen wird (Schritt S173), wird der Beleg unter Verwendung der berechneten tatsächlichen Zeit geprüft (Schritt S175).
  • 31 ist ein Flussdiagramm, das den Prozess darstellt, der an dem Benutzer-Computer in einer Ausführung der vorliegenden Erfindung implementiert wird.
  • Periodisch tritt der Benutzer-Computer mit einem Bezugs-Computer in Verbindung, um eine Bezugszeit abzurufen (Schritt S180). Der Bezugs-Computer kann derselbe sein wie der, mit dem der Informationsserver in Verbindung tritt, oder auch nicht, solange die Bezugszeit im Wesentlichen synchronisiert ist. Eine Offset-Zeit wird unter Verwendung der Zeit der inneren Uhr des Benutzer-Computers und der Bezugszeit berechnet (Schritt S181). Eine tatsächliche Zeit wird unter Verwendung der Zeit der inneren Uhr des Benutzer-Computers und der Offset-Zeit berechnet (Schritt S182). Die Feststellung der Gültigkeit eines Belegs wird unter Verwendung der berechneten tatsächlichen Zeit ausgeführt (Schritt S183).
  • So werden sowohl an dem Informationsserver als auch an dem Benutzer-Computer Offset-Zeiten gespeichert. An dem Informationsserver wird die Offset-Zeit bei der Erzeugung von Belegen verwendet. An dem Benutzer-Computer wird die Offset-Zeit bei der Prüfung der Offset-Belege verwendet. So ist es bei Speicherung einer Offset-Zeit nicht notwendig, die innere Uhr des Informationsservers und des Benutzer-Computers zurückzusetzen, wodurch Kompensationen für andere Verarbeitungsvorgänge vermieden werden.
  • Alle Zeiten, die zum Bestimmen von Transaktionszeiten und der Gültigkeit von Belegen verwendet werden, sind Zeiten nach UTC (Universal Coordinated Time), die auch als GMT (Greenwich Mean Time) bezeichnet wird. Die Bezugszeit kann durch den Benutzer-Computer und den Informationsserver von dem gleichen Zeitserver über das Internet ermittelt werden, dies ist jedoch nicht notwendig. Normalerweise ist mehr als ein Zeitserver verfügbar, was bedeutet, dass der Informationsserver und der Benutzer-Computer auf verschiedene Zeitserver zugreifen könnten. Jeder Zeitserver gibt mit einem sehr geringen Fehlergrad die gleiche Zeit, normalerweise UTC (GMT), an. Selbst wenn geringfügige Ungenauigkeiten beim Berechnen der Round-Trip-Zeit des Netzwerkes berücksichtigt werden, beträgt der Fehler selten mehr als einen kleinen Bruchteil einer Sekunde. Internet-Protokolle arbeiten im Allgemeinen mit einer Genauigkeit von einer Sekunde beim Bestimmen des Alters einer Einheit. Somit ist dies ein Grad der Synchronizität, der für diese Ausführung ausreicht.
  • Als eine Alternative zur Nutzung eines Zeitservers zum Bestimmen einer Offset-Zeit sowohl für den Anwendungsserver als auch den Benutzer-Computer zum Aufzeichnen der Zeit der Erzeugung eines Belegs und zum Prüfen eines Belegs synchronisiert in einer anderen Ausführung der Anwendungsserver seine Uhr mit einem Bezugs-Zeitserver, und GMT wird als der Standard-Zeitrahmen für die Belege verwendet. Um den Benutzer-Computer zu synchronisieren, kann bei dieser Ausführung die Bezugs-GMT-Zeit dem Benutzer-Computer von der CGI-Anwendung 2 zum Zeitpunkt des Sendens der Datei-Kennung bereitgestellt werden. Diese kann als eine Bezugs-GMT-Zeit verwendet werden. Eine Betriebssystemfunktion innerhalb des Benutzer-Computers kann die GMT-Zeit für den Benutzer-Computer angeben, indem sie die lokale Zeiteinstellung des Computers ausgleicht. Diese "lokale GMT-Zeit" kann mit der von dem Anwendungsserver abgerufenen Bezugs-GMT-Zeit vergli chen werden, um einen Offset zu erzeugen, der bei der Prüfung von Belegen zu verwenden ist. So verwendet der Prüfvorgang GMT-Zeit, und lokale GMT-Zeit wird bestimmt, indem die aktuelle Systemzeit bestimmt wird und die Zeitzoneninformationen des Systems, die von dem Betriebssystem verfügbar sind, verwendet werden, um eine lokale GMT-Zeit zu bestimmen. Diese wird dann mit dem bestimmten Offset modifiziert und zum Vergleich mit den Beleg-Zeitparametern verwendet. So kompensiert dieses Verfahren den Mangel an Synchronizität des Benutzer-Computers und gewährleistet, dass der Zeitrahmen, der zur Prüfung der Belege verwendet wird, GMT entspricht, so dass Zeitunterschiede für weltweit verteilte Benutzer vermieden werden. Wenn ein Benutzer Informationen über Transaktionen anzeigen möchte, kann der lokale Zeitrahmen unter Verwendung der Betriebssystemfunktion berücksichtigt werden, die die lokale Zeitzone des Benutzers anzeigt. Die GMT-Werte werden unter Verwendung der Informationen über die lokale Zeitzone in lokale Zeitwerte umgewandelt. Dadurch wird ein Benutzer befähigt, die Transaktionsinformationen in Bezug auf Ereignisse in ihrer lokalen Zeitzone zu prüfen.
  • Mit einer Ausführung der vorliegenden Erfindung kann vermieden werden, dass mehrere unbeabsichtigte Anforderungen zu dem Informationsserver gesendet werden. Derartige mehrfache unbeabsichtigte Anforderungen können aus mehrfacher Mausklick-Betätigung durch einen ungeschickten Benutzer resultieren, aus dem Auftreten von Schaltergrellen in der Maus oder mehrfachen Klickbetätigungen, die von einem ungeduldigen Benutzer verursacht werden, der eine Anforderung erneut sendet, während er auf eine Antwort von dem Informationsserver wartet, weil er glaubt, dass der Server die Anforderungen nicht empfängt oder nicht auf sie antwortet. Derartige mehrfache unbeabsichtigte Anforderungen könnten mehrfache Gebühren für die Informationen bewirken, die der Benutzer anfordern möchte, da zu dem Zeitpunkt, zu dem eine Anforderung gestellt wurde, eine vorangehende Anforderung möglicherweise noch nicht abgeschlossen ist und so kein Beleg für die Informationen erzeugt werden würde, um erneute Berechnung von Gebühren für die gleichen Informationen zu verhindern. Diese Verzögerung beim Erzeugen eines gespeicherten Belegs am Benutzer des Computers resultiert aus der Verzögerung im Kommunikationsnetzwerk beim Senden der Anforderung und bei der Zustellung der Informationen sowie jeglicher Verzögerung der Antwort des Servers auf die Anforderung.
  • In dieser Ausführung werden Anforderungen in einem Anforderungs-Register gespeichert, da sie durch die Bereitstellung der Informationen und die Speicherung eines Belegs an dem Benutzer-Computer erfüllt sind. 32a und 32b sind Flussdiagramme der Verfahrensschritte, die in dieser Ausführung zusätzlich zu den Schritten des Verfahrens in 6a und 7 durchgeführt werden.
  • Die Zahlungsanwendung stellt, wie in 32a zu sehen ist, fest, ob eine Anforderung von Informationen eingegeben ist (als eine HTTP-Anforderung identifiziert, die den Namen der CGI-Anwendung 1 oder 3 enthält) (Schritt S190). Wenn die Anforderung keinen der Namen der CGI-Anwendungen enthält, leitet die Zahlungsanwendung die Anforderung transparent zum Internet weiter (Schritt S7 in 6a). Wenn die Anforderung eine Anforderung von Informationen ist, wird die Anforderung zu dem Anforderungs-Register hinzugefügt (Schritt S191). Dann wird festgestellt, ob frühere nicht erfüllte Anforderungen der gleichen Informationen vorhanden sind, indem die gleichen Anforderungen in dem Anforderungs-Register identifiziert werden (Schritt S192). Wenn frühere Anforderungen vorhanden sind, werden diese früheren Anforderungen zugunsten der aktuellsten Anforderung verworfen (Schritt S193). Der Grund dafür, dass in dieser Ausführung die früheren Anforderungen verworfen werden und nicht die späteren Anforderungen, liegt in der Funktionalität des Webbrowsers, bei dem sich in dieser Ausführung um den Internet-Explorer (Warenzeichen) von Microsoft handelt. Die vorliegende Erfindung ist jedoch nicht auf das Verwerfen der früheren Anforderungen beschränkt. Wenn keine früheren Anforderungen vorhanden sind oder wenn die früheren Anforderungen gelöscht sind, geht der Prozess zu Schritt S5 in 6a weiter. So vermeidet dieser Prozess, dass mehrere Anforderungen zu dem Informationsserver gesendet werden. Das hat nicht nur den Vorteil, dass die Möglichkeit vermieden wird, dass mehr als einmal für das gleiche Informationselement Gebühren erhoben werden, sondern auch die Bandbreitennutzung wird reduziert.
  • Wie in 32b in Verbindung mit 7 zu sehen ist, wird in dieser Ausführung, wenn der Header für die Informationen durch die Zahlungsanwendung empfangen wird, die Anforderung in dem Anforderungs-Register gelöscht (Schritt S200). So ist, wenn die Anforderung beantwortet wird, kein Schutz mehr vor mehrfachen Anforderungen erforderlich. Dies ist so, weil, wenn es die erste Anforderung war, nunmehr ein Beleg durch die Zahlungsanwendung gespeichert ist (Schritt S32 in 7) und daher keine Gefahr mehrfacher Gebührenberechnung besteht und auch der Benutzer eine Antwort auf seine Anforderung sehen kann und es daher unwahrscheinlich ist, dass er aus Ungeduld weitere Anforderungen erzeugt.
  • Obwohl die vorliegende Erfindung oben unter Bezugnahme auf eine spezifische Ausführung beschrieben wurde, gibt es Abwandlungen innerhalb des Geistes und des Schutzumfangs der vorliegenden Erfindung, wie dies für den Fachmann auf der Hand liegt.
  • Obwohl die Ausführung der vorliegenden Erfindung unter Bezugnahme auf Vernetzung über das Internet beschrieben worden ist, kann die vorliegende Erfindung auf Vernetzung über jeden beliebigen Typ Kommunikationsnetzwerk angewendet werden. Die vorliegende Erfindung kann beispielsweise auf Vernetzung über ein lokales Netzwerk, ein Intranet oder ein Extranet angewendet werden. Des Weiteren kann das Kommunikationsnetzwerk ein terrestrisches oder drahtloses Kommunikationsnetzwerk oder eine Kombination aus beiden umfassen.
  • In der Ausführung der vorliegenden Erfindung wird eine Datei-Kennung zum Identifizieren jedes Informationselementes verwendet. Obwohl ein Dateipfad ein Informationselement an einem Informationsserver eindeutig identifiziert, ist es möglich, dass eine Mirror-Site die gleichen Informationen bereitstellt. So gewährleistet der Einsatz einer Datei-Kennung, dass dieses Informationselement eindeutig identifiziert wird, und die Datei-Kennung kann die Kennung der Haupt-Site identifizieren, aus der die Datei-Kennung, die die Inhaltskennung für die Informationen enthält, ursprünglich erzeugt wurde.
  • In einer Ausführung der vorliegenden Erfindung umfasst die Zahlungsanwendung eine unabhängige ausführbare Anwendung. Die Anwendung ist unabhängig von dem Browser und gewährleistet so Unabhängigkeit von den Sicherheitsfunktionen des Browsers und schafft die zusätzlichen Sicherheitsfunktionen des Abgleichens. Die ausführbare Anwendung kann in jedem beliebigen geeigneten Programmiercode einschließlich C++ und Java (Warenzeichen) geschrieben werden. Die Zahlungsanwendung wird in der Ausführung als Proxy-Webserver implementiert, über den HTTP-Anforderungen von dem Browser geleitet werden und über den alle Antworten geleitet werden. In einer alternativen Ausführung könnte die Zahlungsanwendung die HTTP-Anforderungen und Antworten an der Socket Layer durch Patchen in die Datei "Winsock.dll" in dem Betriebssystem Microsoft Windows 95 und 98 (Warenzeichen) überwachen. Die Zahlungsanwendung und der Webbrowser sind zwei simultan implementierte Anwendungen, die miteinander zusammenwirken. Durch den Einsatz der Zahlungsanwendung erübrigt sich beispielsweise die Notwendigkeit, dass ein Benutzer Sicherheitswarnungen durch einen Browser einstellt und kontinuierlich ignoriert, wenn Sicherheitsmerkmale eines Browsers, beispielsweise die Secure Socket Layer, Cookies oder Java-Applets verwendet werden.
  • In einer Ausführung der vorliegenden Erfindung werden die Benutzerkennung und die Beleginformationen, die zwischen der Zahlungsanwendung und dem Informationsserver übertragen werden, verschlüsselt. Die Verschlüsselung kann jede beliebige proprietäre Form haben und bietet eine zusätzliche niedrige Sicherheitsstufe.
  • Obwohl die Ausführung der vorliegenden Erfindung unter Bezugnahme auf den Zugriff auf Dateien beschrieben wird, die ein Bild einer Zeitschriftenseite umfassen, kann die vorliegende Erfindung auch auf die Zahlung für und die Bereitstellung von elektronischem Inhalt in jeder beliebigen Form angewendet werden, für den dem Empfänger der Informationen eine Gebühr erhoben wird. Die Informationen können beispielsweise Ton, Video, Bilder, Text, Dokumente, Computerdaten, Computerdateien usw. umfassen. Die vorliegende Erfindung kann beispielsweise auch für Pay-TV eingesetzt werden.
  • Die vorliegende Erfindung ist nicht auf Micropayments beschränkt. Die Kosten der Transaktion können jede beliebige Summe umfassen, die einem Kunden in Rechnung gestellt werden kann. Wenn die Summen groß sind, müssen diese nicht an dem zentralen Server zusammengestellt werden, sondern können unmittelbar in Rechnung gestellt werden.
  • Obwohl in der beschriebenen Ausführung der Informationsserver und der zentrale Server so beschrieben sind, dass sie einen einzelnen Server umfassen, schließt die vorliegende Erfindung die Konfiguration des Informationsservers und des zentralen Servers als eine Dateiserver-Konfiguration ein, bei der ein Betreiber mit einem Verteilserver zum Zugreifen, Konfigurieren und Steuern des Systems verbunden ist. So müssen in dieser Konfiguration der Informationsserver und der zentrale Server keine Benutzerschnittstellen-Fähigkeit aufweisen, d. h. es sind kein Monitor, keine Maus und keine Tastatur erforderlich. Die Benutzerschnittstellen-Fähigkeit kann für ein lokales Netzwerk zum Verbinden eines anderen Computers mit dem Dateiserver bereitgestellt werden.
  • Des Weiteren liegen Abwandlungen, die in den Schutzumfang der vorliegenden Erfindung fallen, für einen Fachmann auf der Hand.

Claims (27)

  1. Endgerätevorrichtung zur Verwendung durch einen Kunden in einem gesicherten Zahlungssystem zur Zahlung für ein Produkt in elektronischer Form, wobei die Endgerätevorrichtung umfasst: eine Netzwerkschnittstelle (30) zur Verbindung mit einem Kommunikationsnetzwerk; einen Prozessor (31); eine Webbrowseranwendung (31a), die durch den Prozessor ausgeführt wird, um es einem Benutzer zu erlauben, HTTP-Anforderungen zu generieren, wobei die Anforderungen eine Anforderung eines besagten Produkts beinhalten, umfassend eine HTTP-Anforderung mit Code, um die Anforderung als Anforderung eines besagten Produkts zu identifizieren; Datenspeichermittel (35) zum Speichern von Transaktionsbelegen, Daten umfassend, die Produkte identifizieren, für die Zahlungen während mindestens einer vorangegangenen Transaktion geleistet wurden; und ausführbaren Anwendungscode (31b), der durch den Prozessor ausgeführt wird, um als Webproxy zu agieren, um die Anforderung vom Webbrowsermittel zu empfangen, um durch Ermitteln, ob die Anforderung den Code beinhaltet oder nicht, zu ermitteln, ob die Anforderung eine Anforderung eines besagten Produkts ist oder nicht, und die Anforderung unverändert über das Kommunikationsnetzwerk zu übertragen, wenn die Anforderung keine Anforderung eines besagten Produkts ist, um, falls die Anforderung die eines besagten Produkts ist, durch Identifizieren, ob es einen entsprechenden, in dem Datenspeichermittel gespeicherten Transaktionsbeleg gibt, zu ermitteln, ob für das Produkt vorher gezahlt worden ist, und die Netzwerkschnittstelle zu steuern, um die Anforderung des besagten Produkts über das Kommunikationsnetzwerk mit jedwedem identifizierten Transaktionsbeleg für das Produkt an ein Händlerendgerät zu übertragen, um das Produkt vom Händlerendgerät zu empfangen und zum Webbrowser weiterzuleiten und um einen Transaktionsbeleg für das Produkt vom Händlerendgerät über das Kommunikationsnetzwerk zu empfangen und den empfangenen Transaktionsbeleg in dem Datenspeichermittel zu speichern; wobei der ausführbare Anwendungscode ausgelegt ist, jedweden Beleg als ASCII zu codieren und das ASCII der Anforderung vor dem Übertragen der Anforderung über das Kommunikationsnetzwerk hinzuzufügen.
  2. Endgerätevorrichtung nach Anspruch 1, wobei der ausführbare Anwendungscode ausgelegt ist, Transaktionsbelege, die in dem Datenspeichermittel gespeichert sind, an einen Zahlungsserver zu übertragen.
  3. Endgerätevorrichtung nach einem der vorhergehenden Ansprüche, wobei der ausführbare Anwendungscode ausgelegt ist, Transaktionsinformationen von einem Zahlungsserver zu empfangen, die Transaktionsinformationen mit den Transaktionsbelegen in dem Datenspeichermittel zu vergleichen und Informationen über das Ergebnis des Vergleichs an den Zahlungsserver zu senden.
  4. Endgerätevorrichtung nach einem der vorhergehenden Ansprüche, wobei der Webbrowser ausgelegt ist, es einem Benutzer zu erlauben, ein Abonnement für ein regelmäßig bereitgestelltes Produkt anzufordern, wobei der ausführbare Anwendungscode ausgelegt ist, die Abonnementsanforderung über das Kommunikationsnetzwerk an das Händlerendgerät zu übertragen, einen Abonnementsbeleg vom Händlerendgerät über das Kommunikationsnetzwerk zu empfangen, den empfangenen Abonnementsbeleg in dem Datenspeichermittel zu speichern und durch Identifizieren, ob es einen entsprechenden, in dem Datenspeichermittel gespeicherten Transaktionsbeleg oder Abonnementsbeleg gibt, zu ermitteln, ob für das Produkt vorher gezahlt worden ist.
  5. Endgerätevorrichtung nach einem der vorhergehenden Ansprüche, wobei der ausführbare Anwendungscode ausgelegt ist, mit der Anforderung eindeutige Benutzeridentifikations-Informationen über das Kommunikationsnetzwerk zu übertragen, und der Transaktionsbeleg die eindeutigen Benutzeridentifikations-Informationen beinhaltet.
  6. Verfahren des Erlangens eines Produkts und des Zahlen dafür in elektronischer Form, wobei das Verfahren umfasst: Empfangen einer Benutzerauswahl (S2) in einem Webbrowser (31a) und Generieren von HTTP-Anforderungen, wobei die Anforderungen eine Anforderung eines besagten Produkts beinhaltet, umfassend eine HTTP-Anforderung mit Code, um die Anforderung als Anforderung eines besagten Produkts zu identifizieren (S3); in einem Webproxy (31b) Empfangen der Anforderung vom Webbrowser, Ermitteln, ob die Anforderung eine Anforderung eines besagten Produkts ist oder nicht, durch Ermitteln, ob die Anforderung den Code beinhaltet oder nicht, und Übertragen der Anforderung unverändert über das Kommunikationsnetzwerk, wenn die Anforderung keine Anforderung eines besagten Produkts ist, Ermitteln, falls die Anforderung die eines besagten Produkts ist, ob für das Produkt vorher gezahlt worden ist, durch Identifizieren, ob es einen entsprechenden, in einem Datenspeichermittel, das Transaktionsbelege speichert, die Daten umfassen, die Produkte identifizieren, für die Zahlungen während mindestens einer vorangegangenen Transaktion geleistet wurden, gespeicherten Transaktionsbeleg gibt, und Übertragen der Anforderung des Produkts über das Kommunikationsnetzwerk mit jedwedem identifizierten Transaktionsbeleg für das Produkt an ein Händlerendgerät, Empfangen und Weiterleiten des Produkts vom r Händlerendgerät zum Webbrowser und Empfangen eines Transaktionsbelegs für das Produkt vom Händlerendgerät über das Kommunikationsnetzwerk und Speichern des empfangenen Transaktionsbelegs in dem Datenspeichermittel; wobei der Webproxy jedweden Beleg als ASCII codiert und den codierten Beleg der Anforderung vor dem Übertragen der Anforderung über das Kommunikationsnetzwerk hinzufügt.
  7. Verfahren nach Anspruch 6, wobei der Webproxy gespeicherte Transaktionsbelege an einen Zahlungsserver überträgt.
  8. Verfahren nach Anspruch 6 oder Anspruch 7, wobei der Webproxy Transaktionsinformationen von einem Zahlungsserver empfängt, die Transaktionsinformationen mit den gespeicherten Transaktionsbelegen vergleicht und Informationen über das Ergebnis des Vergleichs an den Zahlungsserver sendet.
  9. Verfahren nach einem der Ansprüche 6 bis 8, wobei der Webbrowser eine Benutzer-Abonnementsauswahl empfängt und eine Anforderung eines Abonnements für ein regelmäßig bereitgestelltes Produkt generiert und der Webproxy die Abonnementsanforderung empfangt und über das Kommunikationsnetzwerk an den Anbieter überträgt, einen Abonnementsbeleg vom Anbieter über das Kommunikationsnetzwerk empfangt, den empfangenen Abonnementsbeleg in dem Datenspeichermittel speichert und durch Identifizieren, ob es einen entsprechenden gespeicherten Transaktionsbeleg oder Abonnementsbeleg gibt, ermittelt, ob für das Produkt vorher gezahlt worden ist.
  10. Verfahren nach einem der Ansprüche 6 bis 9, wobei der Webproxy mit der Anforderung eindeutige Benutzeridentifikations-Informationen über das Kommunikationsnetzwerk überträgt und der Transaktionsbeleg die eindeutigen Benutzeridentifikations-Informationen beinhaltet.
  11. Händlerendgerätevorrichtung zum Bereitstellen von Produkten in elektronischer Form für die Endgerätevorrichtung gemäß einem der Ansprüche 1 bis 6 über ein Kommunikationsnetzwerk, wobei die Vorrichtung umfasst: einen Prozessor (61); Produktspeichermittel (65) zum Speichern von Produkten in elektronischer Form; Transaktionsspeichermittel (65) zum Speichern von Transaktionsdaten, um zu ermöglichen, dass die Benutzer für bereitgestellte besagte Produkte belastet werden; eine Webserveranwendung (61b), die durch den Prozessor implementiert ist, zum Empfangen einer Anforderung eines besagten Produkts von einem Webproxy einer Benutzerendgerätevorrichtung über das Kommunikationsnetzwerk, wobei die Anforderung eine HTTP-Anforderung mit Code, um die Anforderung als Anforderung eines besagten Produkts zu identifizieren, und einen Transaktionsbeleg für jedwedes besagte Produkt umfasst, das vorher durch den Benutzer erworben wurde; und ein Anwendungsprogramm (61b–d), das durch den Prozessor implementiert und an die Webserveranwendung angekoppelt ist, zum Ermitteln, ob ein gültiger Transaktionsbeleg für das Produkt mit der Anforderung beinhaltet ist, zum Bereitstellen des angeforderten Produkts für die Webserveranwendung, falls ein gültiger Transaktionsbeleg für das Produkt von der Benutzerendgerätevorrichtung des Benutzen empfangen worden ist, und zum Generieren und Bereitstellen eines Transaktionsbelegs für das angeforderte Produkt für die Webserveranwendung, falls kein gültiger Transaktionsbeleg mit der Anforderung beinhaltet ist; wobei die Webserveranwendung (61b) ausgelegt ist, das angeforderte Produkt über das Kommunikationsnetzwerk an das Benutzerendgerät zu übertragen, falls ein gültiger Transaktionsbeleg für das Produkt vom Webproxy des Benutzerendgeräts empfangen worden ist, und das angeforderte Produkt mit dem generierten Transaktionsbeleg für das Produkt über das Kommunikationsnetzwerk an die Benutzerendgerätevorrichtung zu übertragen, falls kein gültiger Transaktionsbeleg für das Produkt mit der Anforderung beinhaltet ist; und das Anwendungsprogramm (61) ausgelegt ist, den generierten Transaktionsbeleg in dem Transaktionsspeichermittel aufzuzeichnen; wobei der Transaktionsbeleg, so vorhanden, in der Anforderung als ASCII codiert ist; und das Anwendungsprogramm ausgelegt ist, jedweden Transaktionsbeleg in einer empfangenen Anforderung zu decodieren und einen generierten Transaktionsbeleg als ASCII zu codieren und das ASCII einem HTTP-Header hinzuzufügen, der mit dem Produkt gesendet wird, bevor das Produkt über das Kommunikationsnetzwerk durch den Webserver übertragen wird.
  12. Händlerendgerätevorrichtung nach Anspruch 11, wobei die Anforderung eindeutigen Benutzeridentifikationscode beinhaltet, wobei das Anwendungsprogramm ausgelegt ist, eine Validierung des empfangenen eindeutigen Benutzeridentifikationscodes vorzunehmen und die Übertragung des angeforderten Produkts zu verhindern, falls die Validierung fehlschlägt.
  13. Händlerendgerätevorrichtung nach Anspruch 12, die Speichermittel für unberechtigte Benutzer zum Speichern von Informationen über Benutzer beinhaltet, die nicht berechtigt sind, Produkte zu empfangen, wobei das Anwendungsprogramm ausgelegt ist, den empfangenen eindeutigen Benutzeridentifikationscode mit den Informationen in dem Speichermittel für unberechtigte Benutzer zu vergleichen und die Übertragung des angeforderten Produkts zu verhindern, falls der Vergleich aufzeigt, dass der Benutzer nicht berechtigt ist.
  14. Händlerendgerätevorrichtung nach einem der Ansprüche 11 bis 13, wobei der Webserver ausgelegt ist, eine Abonnementsanforderung eines Produkts von einem Benutzerendgerät zu empfangen, und das Anwendungsprogramm ausgelegt ist, einen Abonnementsbeleg für das Produkt bereitzustellen, wobei der Webserver ausgelegt ist, den Abonnementsbeleg an die Benutzerendgerätevorrichtung zu übertragen, wobei das Anwendungsprogramm ausgelegt ist, zu ermitteln, ob ein gültiger Abonnementsbeleg für das Produkt mit der Anforderung des Produkts beinhaltet ist; und der Webserver ausgelegt ist, das angeforderte Produkt gebührenfrei über das Kommunikationsnetzwerk an die Benutzerendgerätevorrichtung zu übertragen, falls mit der Anforderung des Produkts ein gültiger Abonnementsbeleg für das Produkt von der Benutzerendgerätevorrichtung empfangen worden ist, und das angeforderte Produkt mit dem Transaktionsbeleg für das Produkt über das Kommunikationsnetzwerk an die Benutzerendgerätevorrichtung zu übertragen, falls mit der Anforderung des Produkts kein gültiger Transaktions- oder Abonnementsbeleg für das Produkt von der Benutzerendgerätevorrichtung empfangen worden ist.
  15. Händlerendgerätevorrichtung nach einem der Ansprüche 11 bis 14, die Transaktionsspeichersteuerungsmittel zum Übertragen der Transaktionsdaten, die in dem Transaktionsspeichermittel gespeichert sind, über das Kommunikationsnetzwerk an einen Zahlungsserver beinhaltet.
  16. Händlerendgerätevorrichtung nach Anspruch 15, wobei das Transaktionsspeichersteuerungsmittel ausgelegt ist, die Transaktionsdaten, die in dem Transaktionsspeichermittel gespeichert sind, nach der Übertragung der Transaktionsdaten über das Kommunikationsnetzwerk an den Zahlungsserver zu löschen.
  17. Händlerendgerätevorrichtung nach einem der Ansprüche 11 bis 16, die ein Indexspeichermittel zum Speichern eines Index der Produkte, die in dem Produktspeichermittel gespeichert sind, als Webseiten mit Hypertextlinks beinhaltet, die Anforderungen von Produkten umfassen, wobei der Webserver ausgelegt ist, es einem Webbrowser, der durch einen Benutzer bedient wird, zu erlauben, auf das Indexspeichermittel zuzugreifen, um den Index zu verwenden, um eine Anforderung eines Produkts zu generieren.
  18. Händlerendgerätevorrichtung nach einem der Ansprüche 11 bis 17, wobei der Webserver ausgelegt ist, das angeforderte Produkt gebührenfrei an das Benutzerendgerät zu übertragen, wenn ein gültiger Transaktionsbeleg für das Produkt vom Benutzer aus empfangen worden ist.
  19. Verfahren des Bereitstellens von Produkten in elektronischer Form über ein Kommunikationsnetzwerk von einer Benutzerendgerätevorrichtung aus, wobei das Verfahren umfasst: Empfangen einer Anforderung eines besagten Produkts von einem Webproxy einer Benutzerendgerätevorrichtung über das Kommunikationsnetzwerk an einer Webserveranwendung (61b), wobei die Anforderung eine HTTP-Anforderung mit Code, um die Anforderung als Anforderung eines besagten Produkts zu identifizieren, und einen Transaktionsbeleg für jedwedes besagte Produkt umfasst, das vorher durch den Benutzer erworben wurde; und Ermitteln an einem Anwendungsprogramm (61b–d), das an die Webserveranwendung angekoppelt ist, ob ein gültiger Transaktionsbeleg für das Produkt mit der Anforderung beinhaltet ist, Bereitstellen des angeforderten Produkts für die Webserveranwendung, falls ein gültiger Transaktionsbeleg für das Produkt von der Benutzerendgerätevorrichtung des Benutzers aus empfangen worden ist, und Generieren und Bereitstellen eines Transaktionsbelegs für das angeforderte Produkt an die Webserveranwendung, falls kein gültiger Transaktionsbeleg mit der Anforderung beinhaltet ist; Übertragen des angeforderten Produkts von der Webserveranwendung (61b) über das Kommunikationsnetzwerk an den Webproxy der Benutzerendgerätevorrichtung, falls ein gültiger Transaktionsbeleg für das Produkt von der Benutzerendgerätevorrichtung aus empfangen worden ist, und Übertragen des angeforderten Produkts mit dem generierten Transaktionsbeleg für das Produkt von der Webserveranwendung (61b) über das Kommunikationsnetzwerk an die Benutzerendgerätevorrichtung, falls kein gültiger Transaktionsbeleg für das Produkt mit der Anforderung beinhaltet ist; und Aufzeichnen des generierten Transaktionsbelegs in einem Transaktionsspeichermittel, das Transaktionsdaten speichert, um zu ermöglichen, dass die Benutzer für bereitgestellte besagte Produkte belastet werden; wobei der Transaktionsbeleg, so vorhanden, in der Anforderung als ASCII codiert ist; und das Anwendungsprogramm jedweden Transaktionsbeleg in einer empfangenen Anforderung decodiert und einen generierten Transaktionsbeleg als ASCII codiert und das ASCII einem HTTP-Header hinzufügt, der mit dem Produkt gesendet wird, bevor das Produkt über das Kommunikationsnetzwerk durch den Webserver übertragen wird.
  20. Verfahren nach Anspruch 19, wobei die Anforderung eindeutigen Benutzeridentifikationscode beinhaltet, wobei das Anwendungsprogramm eine Validierung des empfangenen eindeutigen Benutzeridentifikationscodes vornimmt und die Übertragung des angeforderten Produkts verhindert, falls die Validierung fehlschlägt.
  21. Verfahren nach Anspruch 20, das Speichermittel für unberechtigte Benutzer zum Speichern von Informationen über Benutzer beinhaltet, die nicht berechtigt sind, Produkte zu empfangen, wobei das Anwendungsprogramm den empfangenen eindeutigen Benutzeridentifikationscode mit den Informationen in dem Speichermittel für unberechtigte Benutzer vergleicht und die Übertragung des angeforderten Produkts verhindert, falls der Vergleich aufzeigt, dass der Benutzer nicht berechtigt ist.
  22. Verfahren nach einem der Ansprüche 19 bis 21, wobei der Webserver eine Abonnementsanforderung für ein Produkt von einer Benutzerendgerätevorrichtung empfängt, das Anwendungsprogramm einen Abonnementsbeleg für das Produkt bereitstellt, der Webserver den Abonnementsbeleg an das Benutzerendgerät überträgt, das Anwendungsprogramm ermittelt, ob ein gültiger Abonnementsbeleg für das Produkt mit der Anforderung des Produkts beinhaltet ist und der Webserver das angeforderte Produkt gebührenfrei über das Kommunikationsnetzwerk an die Benutzerendgerätevorrrichtung überträgt, falls mit der Anforderung des Produkts ein gültiger Abonnementsbeleg für das Produkt von der Benutzerendgerätevorrichtung aus empfangen worden ist, und das angeforderte Produkt mit dem Transaktionsbeleg für das Produkt über das Kommunikationsnetzwerk an die Benutzerendgerätevorrichtung überträgt, falls mit der Anforderung des Produkts kein gültiger Transaktions- oder Abonnementsbeleg für das Produkt von der Benutzerendgerätevorrichtung aus empfangen worden ist.
  23. Verfahren nach einem der Ansprüche 19 bis 22, das Übertragen der Transaktionsdaten, die in dem Transaktionsspeichermittel gespeichert sind, über das Kommunikationsnetzwerk an einen Zahlungsserver beinhaltet.
  24. Verfahren nach Anspruch 23, das Löschen der Transaktionsdaten, die in dem Transaktionsspeichermittel gespeichert sind, nach der Übertragung der Transaktionsdaten über das Kommunikationsnetzwerk an den Zahlungsserver beinhaltet.
  25. Verfahren nach einem der Ansprüche 19 bis 24, das Speichern eines Index der Produkte, die in dem Produktspeichermittel gespeichert sind, als Webseiten mit Hypertextlinks beinhaltet, die Anforderungen von Produkten umfassen, und der Webserver erlaubt es einem Webbrowser, der durch einen Benutzer bedient wird, auf das Indexspeichermittel zuzugreifen, um den Index zu verwenden, um eine Anforderung eines Produkts zu generieren.
  26. Verfahren nach einem der Ansprüche 19 bis 25, wobei der Webserver das angeforderte Produkt gebührenfrei an die Benutzerendgerätevorrichtung überträgt, wenn ein gültiger Transaktionsbeleg für das Produkt vom Benutzer aus empfangen worden ist.
  27. Trägermedium, das computerlesbaren Code zum Steuern eines Computers trägt, um alle Schritte des Verfahrens nach einem der Ansprüche 6 bis 10 oder 19 bis 26 auszuführen.
DE60221988T 2001-05-02 2002-05-01 Gesichertes zahlungsverfahren und -system Expired - Lifetime DE60221988T2 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
GB0110808A GB2375214B (en) 2001-05-02 2001-05-02 Secure payment method and system
GB0110808 2001-05-02
US09/859,206 US7110979B2 (en) 2001-05-02 2001-05-16 Secure payment method and system
US859206 2001-05-16
PCT/GB2002/002004 WO2002089075A2 (en) 2001-05-02 2002-05-01 Secure payment method and system

Publications (2)

Publication Number Publication Date
DE60221988D1 DE60221988D1 (de) 2007-10-04
DE60221988T2 true DE60221988T2 (de) 2008-05-15

Family

ID=29252429

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60221988T Expired - Lifetime DE60221988T2 (de) 2001-05-02 2002-05-01 Gesichertes zahlungsverfahren und -system

Country Status (6)

Country Link
US (1) US20070011093A1 (de)
EP (1) EP1407432B1 (de)
AT (1) ATE371240T1 (de)
AU (1) AU2002256770A1 (de)
DE (1) DE60221988T2 (de)
WO (1) WO2002089075A2 (de)

Families Citing this family (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7584869B2 (en) * 2004-04-15 2009-09-08 Redbox Automated Retail, Llc Article dispensing system and method for same
US8060247B2 (en) * 2005-04-22 2011-11-15 Redbox Automated Retail, Llc System and method for communicating secondary vending options
CA2605563C (en) * 2005-04-22 2015-06-23 Redbox Automated Retail, Llc System and method for offline vending of a media product
TW200834446A (en) * 2006-10-11 2008-08-16 Visa Int Service Ass Method and system for processing micropayment transactions
US10068220B2 (en) 2006-10-11 2018-09-04 Visa International Service Association Systems and methods for brokered authentication express seller links
US20100223184A1 (en) * 2006-10-11 2010-09-02 Visa International Service Association Sponsored Accounts For Computer-Implemented Payment System
US7886964B2 (en) * 2007-04-17 2011-02-15 Steinecker Jeffrey T System and method for personalized e-commerce
EP2186331A4 (de) 2007-07-27 2010-12-29 Synergy Sports Technology Llc Systeme und verfahren zur erzeugung von videofingerabdrücken für lesezeichen
US9886809B2 (en) 2007-09-28 2018-02-06 Redbox Automated Retail, Llc Article dispensing machine and method for auditing inventory while article dispensing machine remains operational
US20090089187A1 (en) * 2007-09-28 2009-04-02 Redbox Automated Retail, Llc Article Vending Machine And Method for Auditing Inventory While Article Vending Machine Remains Operational
US8768789B2 (en) 2012-03-07 2014-07-01 Redbox Automated Retail, Llc System and method for optimizing utilization of inventory space for dispensable articles
US8712872B2 (en) 2012-03-07 2014-04-29 Redbox Automated Retail, Llc System and method for optimizing utilization of inventory space for dispensable articles
US20090248449A1 (en) * 2008-03-28 2009-10-01 Stat Physician P.C. Care Plan Oversight Billing System
US7827108B2 (en) * 2008-11-21 2010-11-02 Visa U.S.A. Inc. System and method of validating a relationship between a user and a user account at a financial institution
US9280771B2 (en) 2009-02-13 2016-03-08 International Business Machines Corporation Secure personal information profile
US20110047010A1 (en) * 2009-08-21 2011-02-24 Redbox Automated Retail, Llc Article vending machine and method for receiving restricted discount codes
US9104990B2 (en) 2009-09-05 2015-08-11 Redbox Automated Retail, Llc Article vending machine and method for exchanging an inoperable article for an operable article
US8996162B2 (en) * 2009-09-05 2015-03-31 Redbox Automated Retail, Llc Article vending machine and method for exchanging an inoperable article for an operable article
US8676639B2 (en) 2009-10-29 2014-03-18 Visa International Service Association System and method for promotion processing and authorization
US8280788B2 (en) * 2009-10-29 2012-10-02 Visa International Service Association Peer-to-peer and group financial management systems and methods
US20110106674A1 (en) * 2009-10-29 2011-05-05 Jeffrey William Perlman Optimizing Transaction Scenarios With Automated Decision Making
US9569911B2 (en) 2010-08-23 2017-02-14 Redbox Automated Retail, Llc Secondary media return system and method
US8538581B2 (en) 2010-09-03 2013-09-17 Redbox Automated Retail, Llc Article vending machine and method for authenticating received articles
US8639778B2 (en) 2011-02-01 2014-01-28 Ebay Inc. Commerce applications: data handshake between an on-line service and a third-party partner
WO2012174171A2 (en) 2011-06-14 2012-12-20 Redbox Automated Retail, Llc System and method for substituting a media article with alternative media
CA2842293C (en) 2011-07-20 2019-10-22 Redbox Automated Retail, Llc System and method for providing the identification of geographically closest article dispensing machines
EP2740092A4 (de) 2011-08-02 2015-03-11 Redbox Automated Retail Llc System und verfahren zur erzeugung von benachrichtigungen bezüglich neuer medien
FR2978889B1 (fr) * 2011-08-04 2013-09-20 Centre Nat Etd Spatiales Systeme et procede de gestion multiple de ressources de transmission d'un systeme spatial de radiocommunication multicellulaire.
WO2013025392A2 (en) 2011-08-12 2013-02-21 Redbox Automated Retail, Llc System and method for applying parental control limits from content providers to media content
US9747253B2 (en) 2012-06-05 2017-08-29 Redbox Automated Retail, Llc System and method for simultaneous article retrieval and transaction validation
US9576279B2 (en) * 2012-06-05 2017-02-21 Autoscribe Corporation System and method for registering financial accounts
US9678986B2 (en) * 2012-12-05 2017-06-13 Wgrs Licensing Company, Llc Systems and methods for registering, administering, and using non-locational identifiers as locational addresses through location name and identifier registries
WO2014158582A1 (en) * 2013-03-14 2014-10-02 American Express Travel Related Services Company, Inc. Systems and methods for expense management
KR102015955B1 (ko) * 2013-03-27 2019-10-21 한화테크윈 주식회사 클라이언트 인증 방법
US9443268B1 (en) 2013-08-16 2016-09-13 Consumerinfo.Com, Inc. Bill payment and reporting
US10325314B1 (en) 2013-11-15 2019-06-18 Consumerinfo.Com, Inc. Payment reporting systems
US10262362B1 (en) 2014-02-14 2019-04-16 Experian Information Solutions, Inc. Automatic generation of code for attributes
US10191992B2 (en) * 2014-12-29 2019-01-29 Surveymonkey Inc. Unified profiles
US11023880B2 (en) * 2016-07-23 2021-06-01 Vray Inc. Online mobile payment system and method using authentication codes
CN107067244B (zh) * 2016-11-03 2020-09-29 阿里巴巴集团控股有限公司 业务实现方法、支付方法、业务实现装置及支付服务端
CN107070858B (zh) 2016-12-21 2021-09-21 创新先进技术有限公司 一种业务处理方法及装置
CA3050976A1 (en) * 2017-01-23 2018-07-26 Alkira Software Holdings Pty Ltd Facilitated user interaction
CN109472525B (zh) * 2017-09-08 2022-08-09 北京京东振世信息技术有限公司 用于订单签收的方法、装置、电子设备及终端设备
US11265324B2 (en) 2018-09-05 2022-03-01 Consumerinfo.Com, Inc. User permissions for access to secure data at third-party
USD959552S1 (en) 2021-07-21 2022-08-02 Speedfind, Inc Display sign

Family Cites Families (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US1410396A (en) * 1921-11-01 1922-03-21 Rudolph M Fiala Antiskid or traction chain for wheels
US4142069A (en) * 1977-06-20 1979-02-27 The United States Of America As Represented By The Secretary Of The Army Time reference distribution technique
US4992940A (en) * 1989-03-13 1991-02-12 H-Renee, Incorporated System and method for automated selection of equipment for purchase through input of user desired specifications
US5122950A (en) * 1989-11-02 1992-06-16 Moneyfax, Inc. Method of and system for electronic funds transfer via facsimile machines
US5336870A (en) * 1992-05-26 1994-08-09 Hughes Thomas S System for remote purchase payment transactions and remote bill payments
US5694546A (en) * 1994-05-31 1997-12-02 Reisman; Richard R. System for automatic unattended electronic information transport between a server and a client by a vendor provided transport software with a manifest list
US5696909A (en) * 1995-01-27 1997-12-09 Hypercom, Inc. Virtual POS terminal
US5768385A (en) * 1995-08-29 1998-06-16 Microsoft Corporation Untraceable electronic cash
US6138107A (en) * 1996-01-04 2000-10-24 Netscape Communications Corporation Method and apparatus for providing electronic accounts over a public network
US5903880A (en) * 1996-07-19 1999-05-11 Biffar; Peter C. Self-contained payment system with circulating digital vouchers
US5913203A (en) * 1996-10-03 1999-06-15 Jaesent Inc. System and method for pseudo cash transactions
US6058381A (en) * 1996-10-30 2000-05-02 Nelson; Theodor Holm Many-to-many payments system for network content materials
GB9624127D0 (en) * 1996-11-20 1997-01-08 British Telecomm Transaction system
US5999919A (en) * 1997-02-26 1999-12-07 At&T Efficient micropayment system
US7324972B1 (en) * 1997-03-07 2008-01-29 Clickshare Service Corporation Managing transactions on a network: four or more parties
US5930777A (en) * 1997-04-15 1999-07-27 Barber; Timothy P. Method of charging for pay-per-access information over a network
US5915093A (en) * 1997-04-24 1999-06-22 Howard Berlin Computer network debit disk used for prepayment to transfer information from a central computer
US6157917A (en) * 1997-07-11 2000-12-05 Barber; Timothy P. Bandwidth-preserving method of charging for pay-per-access information on a network
US6047268A (en) * 1997-11-04 2000-04-04 A.T.&T. Corporation Method and apparatus for billing for transactions conducted over the internet
US20020004783A1 (en) * 1997-11-12 2002-01-10 Cris T. Paltenghe Virtual wallet system
AU3674599A (en) * 1998-04-24 1999-11-16 Claridge Trading One (Proprietary) Limited Prepaid access for information network
US6473740B2 (en) * 1998-11-29 2002-10-29 Qpass, Inc. Electronic commerce using a transaction network
WO2000039721A1 (en) * 1998-12-28 2000-07-06 Walker Digital Llc Apparatus and method for a flexible-product voucher
US7571139B1 (en) * 1999-02-19 2009-08-04 Giordano Joseph A System and method for processing financial transactions
CA2264351A1 (en) * 1999-03-12 2000-09-12 Mark Van Roon Computer based matching system for party and counterparty exchanges
US6957334B1 (en) * 1999-06-23 2005-10-18 Mastercard International Incorporated Method and system for secure guaranteed transactions over a computer network
US6675153B1 (en) * 1999-07-06 2004-01-06 Zix Corporation Transaction authorization system
EP1214696A1 (de) * 1999-09-22 2002-06-19 Trintech Limited Verfahren zum gesicherten überweisung von geldern
US7389915B1 (en) * 1999-09-22 2008-06-24 Dyor Elizabeth R Financial management system
US20010044787A1 (en) * 2000-01-13 2001-11-22 Gil Shwartz Secure private agent for electronic transactions
US20010029484A1 (en) * 2000-02-03 2001-10-11 Schultz R. Steven Electronic transaction receipt system and method
JP2001283118A (ja) * 2000-03-30 2001-10-12 Internatl Business Mach Corp <Ibm> オンライン決済システム、オンラインショッピングにおける決済方法、サーバおよび販売者端末
US7346577B1 (en) * 2000-08-28 2008-03-18 Javien Digital Payment Solutions, Inc. Third-party billing system and method
US6938019B1 (en) * 2000-08-29 2005-08-30 Uzo Chijioke Chukwuemeka Method and apparatus for making secure electronic payments

Also Published As

Publication number Publication date
WO2002089075A3 (en) 2003-11-06
AU2002256770A1 (en) 2002-11-11
EP1407432B1 (de) 2007-08-22
WO2002089075A2 (en) 2002-11-07
DE60221988D1 (de) 2007-10-04
ATE371240T1 (de) 2007-09-15
US20070011093A1 (en) 2007-01-11
EP1407432A2 (de) 2004-04-14

Similar Documents

Publication Publication Date Title
DE60221988T2 (de) Gesichertes zahlungsverfahren und -system
US7110979B2 (en) Secure payment method and system
DE69908610T2 (de) Gerät und Verfahren für die automatische Zusammenstellung und Übertragung von Transaktionen welche persönliche elektronische informationen oder Daten enthalten
DE69809800T2 (de) Verfahren und system um urheberrechtsgebühren im internet für urheberrechtsgeschützte digitalisierte daten zu erheben
DE60131300T2 (de) Ein Informationsverwaltungssystem
DE69534052T2 (de) System zur Steuerung der Verteilung und Benutzung von Digitalwerken
US6856970B1 (en) Electronic financial transaction system
EP1146459A1 (de) Verfahren und System für die Benachrichtigung von Kunden über Transaktionsgelegenheiten
DE60114024T2 (de) Verfahren zur vergebührung von online-rufnummernauskunftsdiensten
DE69529963T2 (de) System zur Steuerung der Verteilung und Benutzung von Digitalwerken unter Verwendung von Digitalkarten
WO2003042938A2 (de) Bezahlungsprotokoll sowie datenübertragungsverfahren und -anordnung für bezahlvorgänge
DE60036713T2 (de) System und verfahren für gesicherte netzwerkstransaktionen
DE10320615A1 (de) Verwendung erweiterbarer Markup-Sprache in einem System und Verfahren zum Beeinflussen einer Position auf einer Suchergebnisliste, die von einer Computernetzwerksuchmaschine erzeugt wird
EP1525546A2 (de) Bestimmung von steuern durch anwenden von steuerregeln, die mit konfigurierbaren schablonen spezifiziert werden
EP1854261A1 (de) Verfahren zur übertragung von digitalen inhalten eines inhalteanbieters an die nutzer eines online-inhalteübertragungssystems
DE60010479T2 (de) Kommunikationsverfahren und -gerät
DE102011077512A1 (de) Verfahren zur sicheren Verarbeitung von in einem elektronischen Safe gespeicherten Daten
DE60306974T2 (de) Verfahren, Rechner, und Rechnerprogramm für die Übertragung und Bezahlung von Dateninhalten
DE69730435T2 (de) System, verfahren und hergestellter gegenstand für die architektur virtueller verkaufspunkte mit mehreren eingangspunkten
WO2019180152A1 (de) Automatisiertes verfahren zum schutz von elektronischen daten zum zwecke der datenverarbeitung durch dritte unter einbezug transparenter und unterbrechungssicherer vergütung
DE102005025489B4 (de) Verfahren und Computerprogramm zum Kontrollieren eines Zugriffs auf einen Informationsinhalt
DE202023104568U1 (de) Ein intelligentes System zur Entwicklung eines sicheren und effizienten elektronischen Ticketings mithilfe intelligenter Verträge
EP1654713A2 (de) Verfahren und system zur durchführung von bezahlvorgängen in einem rechnerbasierten kommunikationsnetzwerk
EP1959636A1 (de) Verfahren zum Austausch von Daten
DE10021756A1 (de) Computersystem und Verfahren zur variablen Tarifierung von Internetgebühren in Abhängigkeit von gewählten Internetangeboten

Legal Events

Date Code Title Description
8364 No opposition during term of opposition