DE69811947T2

DE69811947T2 - Datenübertragungen

Info

Publication number: DE69811947T2
Application number: DE69811947T
Authority: DE
Inventors: Charles Leveridge
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 1997-12-15
Filing date: 1998-12-15
Publication date: 2003-12-11
Anticipated expiration: 2018-12-16
Also published as: JP2002509300A; EP1040437B1; JP4339514B2; AU753258B2; CA2313388C; CA2313388A1; DE69811947D1; CN1282432A; EP1040437A1; WO1999031610A1; AU1570399A; NZ505057A

Description

Diese Erfindung bezieht sich auf die Datenkommunikation und insbesondere, aber nicht ausschließlich, auf den Abruf elektronischer Güter, wie z. B. Seiten des World Wide Web ("Web"-Seiten) über ein Datenkommunikationsnetz, wie z. B. das internet, und die Gebührenberechnung dafür durch den Lieferanten.
Die Gebührenberechnung für Inhalte des Internets ist bekannt. Sie umfaßt eine Übertragung der Finanzinformationen, wie z. B. der Kreditkartennummern usw., über das Internet über die Herstellung eines periodisch belasteten Kontos mit dem Inhalteanbieter. Wenn jedoch der Anwender Zugriff auf Inhalte wünscht, die von einer Anzahl verschiedener Lieferanten geliefert werden, oder wenn ein Lieferant wünscht, die Inhalte an unbekannte Personen zu liefern, besitzen diese Gebührenbelastungsschemata Nachteile. Die Anwender zögern, persönliche Finanzinformationen an viele verschiedene Lieferanten freizugeben, wohingegen die Inhalteanbieter zögern, gebührenbelastbare Inhalte ohne die unmittelbare Begleichung der Gebühr durch den Anwender oder die Herstellung einer langfristigen Kreditvereinbarung mit dem Anwender zu liefern.
Ein weiteres bekanntes System für die Lieferung gebührenbelastbarer Inhalte durch eine Anzahl von Lieferanten umfaßt einen Vermittler, der die Finanztransaktion mit dem Anwender ausführt und ein "digitales Angebot" erzeugt, das als eine akzeptable Währung durch eine Anzahl der dritten Inhalteanbieter behandelt wird. Die Inhalteanbieter werden durch den Vermittler periodisch für ihre Inhalte bezahlt. Die dritten Inhalteanbieter müssen jedoch "für den Handel befähigte" Web-Server verwenden, die die durch den Vermittler bereitgestellten digitalen Angebote bearbeiten und entschlüsseln können.
WO 97/03410 beschreibt ein Internet-Gebührenabrechnungsverfahren, in dem ein Internet-Zugangsanbieter Vereinbarungen mit Verkäufern trifft, die Güter an Kunden des Anbieters verkaufen wollen, wobei der Anbieter die Kunden für die von den Verkäufern erworbenen Produkte und Dienstleistungen belastet. Wenn ein Kunde mit dem Internet verbunden ist, kann der Kunde mit irgendeinem der Verkäufer eine Schnittstelle bilden, um etwas über die durch die Verkäufer angebotenen Produkte oder Dienstleistungen herauszufinden. Der Kunde kann dann eine Entscheidung treffen, um ein Produkt zu bestellen, wobei ein Austausch der Transaktionsinformationen zwischen dem Kunden und dem Verkäufer auftritt. Dieser Austausch enthält die Informationen, die den Kunden identifizieren, und Informationen, die das Produkt oder die Dienstleistungen betreffen, das bzw. die zu erwerben sind, einschließlich des Transaktionsbetrages, die Art und den Zeitpunkt der Lieferung und eine Referenznummer, um diese Bestellung zu identifizieren. Die Transaktionsinformationen werden durch den Anbieter entweder durch eine separate Sendung durch den Verkäufer oder den Kunden zum Anbieter erhalten, oder indem der Anbieter die Informationen aus der Kommunikation zwischen dem Kunden und dem Verkäufer extrahiert.
WO 97/41539 beschreibt ein System für die sichere elektronische Bezahlung und das sichere Eintreiben von Kreditschulden über das Netz. Zwischen einem Kunden und einem Kaufmann wird eine verschlüsselte Kommunikationssitzung aufgebaut, während der die finanziellen Einzelheiten des Kunden zum Kaufmann gesendet werden. Der Kaufmann kann nicht alle Einzelheiten entschlüsseln. Der Kaufmann baut eine weitere verschlüsselte Kommunikationssitzung mit einem "Bezahlungs-Gateway" auf, wodurch die finanziellen Einzelheiten des Kunden bestätigt und die Bezahlung genehmigt wird.
EP-A-0 801 479 beschreibt ein Datennetzsicherheits-System und -Verfahren, durch die die Übermittlung von Kreditkarteninformationen oder - anderen schutzbedürftigen Informationen durch eine separate unabhängige Verbindung zwischen dem Internet-Zugangsanbieter des Kunden und einem Inhalteanbieter ausgeführt wird. Die separate Verbindung erfolgt anstatt über das Internet über ein öffentliches Fernsprechnetz.
Gemäß einem Aspekt der Erfindung wird ein Verfahren zum Steuern von Anwenderanforderungen in einem Server-System geschaffen, das mit einem Anwender und mit einem dritten Teilnehmer über ein Datenkommunikationssystem kommuniziert, wobei das Verfahren umfaßt:
Empfangen einer digitalen Anforderung für Güter vom Anwender über das Datenkommunikationssystem;
Weiterleiten der Anforderung an den dritten Teilnehmer über das Datenkommunikationssystem;
Empfangen eines digitalen Codes, der auf die Güter bezogen ist;
vom dritten Teilnehmer über das Datenkommunikationssystem;
Festsetzen eines Preises, mit dem der Anwender für die Güter belastet wird, in Abhängigkeit von dem Code in dem Server-System;
Bestimmen auf der Grundlage des Preises, ob die Güter vom dritten Teilnehmer bereitgestellt werden sollen; und
Anordnen der durch den dritten Teilnehmer bereitzustellenden Güter, falls das Ergebnis der Bestimmung positiv ist.
Gemäß einem weiteren Aspekt der Erfindung wird ein Verfahren für die Bereitstellung von Gütern für Anwender geschaffen, die über ein Datenkommunikationssystem kommunizieren, wobei das Verfahren die folgenden Schritte umfaßt:
Empfangen einer digitalen Anforderung für Güter von einem zweiten Server-System, das von einem Anwender ausgehende Anforderungen steuert, bei einem ersten Server-System über das Datenkommunikationssystem;
in Reaktion auf den Empfang der digitalen Anforderung beim ersten Server Senden eines digitalen Codes, der auf die Güter bezogen ist, über das Datenkommunikationssystem zum zweiten Server- System; und
Bereitstellen der Güter, falls nach dem Senden des digitalen Codes eine Bestätigung der Anforderung vom zweiten Server-System durch das erste Server-System über das Datenkommunikationssystem empfangen wird,
wobei der digitale Code auf einen Preis bezogen ist, der vom zweiten Server-System festgelegt wird und mit dem der Anwender für die Güter belastet werden soll.
In den Ausführungsformen der Erfindung kann ein Gateway-Server den Zugriff auf die im Güter der dritten Teilnehmer steuern. In den Fällen, in denen die angeforderten Güter nicht durch einen Anwender gewünscht werden oder möglicherweise nicht einem Anwender bereitgestellt werden sollten, informiert ein dritter Teilnehmer das Gateway mit einem digitalen Code, der dem Gateway-Server erlaubt, zu bestimmen, ob die Güter bereitzustellen sind. Wenn eine Anzahl dritter Teilnehmer durch den Gateway-Server bedient werden, müssen die Anwender, die auf die Güter der dritten Teilnehmer zugreifen, nur eine Beziehung mit dem Teilnehmer aufbauen, der den Gateway- Server steuert, der wiederum einzelne Beziehungen mit jedem der dritten Teilnehmer aufbauen kann.
Außerdem kann ein tatsächlicher Preis, der dem Anwender durch ein Gateway zu belasten ist, durch einen Gateway-Server unabhängig von irgendwelchen Preisfestsetzungsvereinbarungen verändert werden, die mit einem Inhalteanbieter getroffen worden sind oder die durch einen Inhalteanbieter angewendet werden. Es kann z. B. ein anderes Belastungsschema im Gateway-Server ausgewählt werden, um den Preis, der dem gleichen Anwender für Inhalte, die dem gleichen digitalen Code zugeordnet sind, belastet werden würde, mit der Zeit zu ändern und dadurch eine zeitliche Flexibilität im zu belastenden Preis bereitzustellen. In Abhängigkeit vom Anwender können außerdem andere Belastungsschemata ausgewählt werden. Dies erlaubt, daß durch den Gateway-Server Mengenrabatte, Sonderangebote usw. für ausgewählte Anwender gelten.
Weitere Merkmale und Vorteile der vorliegenden Erfindung in ihren verschiedenen Aspekten werden aus der folgenden Beschreibung einer bevorzugten Ausführungsform der Erfindung offensichtlich, die unter Bezugnahme auf die beigefügte Zeichnung gegeben wird, worin:
Fig. 1 ein Blockschaltplan ist, der ein Dateninhalte-Abrufsystem gemäß einer Ausführungsform der vorliegenden Erfindung schematisch veranschaulicht;
Fig. 2 ein Blockschaltplan ist, der einen Abschnitt der Anordnung nach Fig. 1 ausführlicher schematisch veranschaulicht;
Fig. 3 ein Ablaufplan ist, der die zwischen einem Anwenderendgerät und dem Gateway-Server nach den Fig. 1 und 2 ausgeführten Authentifizierungsprozeduren veranschaulicht;
Fig. 4 ein Ablaufplan ist, der die während des Abrufs von Dokumenten durch den Anwender durch ein Anwenderendgerät, einen Gateway-Server und einen Server eines dritten Teilnehmers ausgeführten Prozeduren veranschaulicht; und
Fig. 5 ein Ablaufplan ist, der die für den Abruf eines Dokuments durch einen Client, einen Gateway-Server und einen Server eines dritten Teilnehmers ausgeführten weiteren Prozeduren veranschaulicht.
Fig. 1 ist ein Blockschaltplan, der ein Dateninhalte-Abrufsystem gemäß einer Ausführungsform der vorliegenden Erfindung veranschaulicht. Das System umfaßt einen Gateway-Server GS und mehrere Server TPS1, TPS2, ..., TPSn der dritten Teilnehmer. Es sind drei verschiedene Beispiele des Anwenderendgerätes T1, T2, T3 veranschaulicht, von denen jedes über ein Datenkommunikationsnetz, in dieser Ausführungsform das Internet, mit dem System verbunden ist.
Die Server TPS1, TPS2, ..., TPSn der dritten Teilnehmer sind über sichere Kommunikationsverbindungen 2 (die separate physikalische Verbindungen und/oder logische Verbindungen sein können, die während den Übermittlungen eine sichere Verschlüsselung verwenden) mit dem Gateway-Server fernverbunden und/ oder befinden sich mit dem Authentifizierungs-Server am gleichen Aufstellungsort.
Jeder der in Fig. 1 veranschaulichten Server kann in einem Computer-Betriebsmittel, wie z. B. einem Arbeitsplatz-Computer, implementiert sein. Jedes der Anwenderendgeräte T1, T2, T3 usw. kann in der Form eines Arbeitsplatz-Computers, eines Netz-Computers, eines mobilen Kommunikationsendgerätes usw. implementiert sein.
Fig. 2 veranschaulicht schematisch weitere Einzelheiten des Datenabrufsystems, das ein einzelnes Anwenderendgerät T1 und einen einzelnen Server TPS1 eines dritten Teilnehmers veranschaulicht. Sowohl der Gateway-Server GS als auch der Server TPS1 des dritten Teilnehmers sind Server, wobei das Anwenderendgerät T1 mit der Anwendungs-Software in der Form eines Web-Clients oder Browsers versehen ist, wie z. B. dem Netscape-Navigator (Markenzeichen) oder dem Microsoft Internet Explorer (Markenzeichen).
Der Gateway-Server GS enthält Software-Anwendungen in der Form eines Web-Servers 10, einer Such-Befehls-Gateway-Schnittstelle (Such-CGI) 12, einer Kontobetrachtungs-CGI 14, einer Preisbetrachtungs-CGI 16 und einer Proxy-CGI 18. Es sind außerdem eine Preisfestsetzungsdatenbank 20, die verschiedene Belastungsschemata speichert, eine Kreditgrenzendatenbank 22, die die Kreditgrenzen pro Anwender speichert, eine Betreiber-Steuerschnittstelle 24 und eine Gebührenabrechnungsmaschine 26 enthalten. Außerdem ist der Gateway-Server mit einer Authentifizierungsdatenbank AD versehen, die die Authentifizierungseinzelheiten auf einer Grundlage pro Anwender speichert.
Der Server TPS1 des dritten Teilnehmers enthält indessen eine Suchmaschine 30, eine Inhaltsmaschine 32, eine Preisfestsetzungsdatenbank 34 und eine Belastungsdatenbank 36. Die Inhaltsmaschine 32 speichert und überträgt Daten, einschließlich Web-Seiten, in Reaktion auf Anforderungen vom Gateway-Server. Die Preisfestsetzungsdatenbank speichert Preiscodes für jedes Element der in der Inhaltsmaschine 32 gespeicherten gebührenpflichtigen Inhalte.
Um auf den Gateway-Server GS zuzugreifen, sendet der Web-Client eine Anforderung für ein Dokument über das Internet. Um ein Dokument in einem Web-Server zu kennzeichnen und zu lokalisieren, sind die Dateien durch einen einheitlichen Fundstellenanzeiger (URL) gekennzeichnet. Der URL ist strukturiert, um das Server-Protokoll (das in dieser Ausführungsform das HTTP ist), die "Domäne" des Internet-Servers, das Verzeichnis der Datei im Internet-Server und den Dateinamen zu kennzeichnen. Eine typische URL-Struktur für Dokumente auf dem Gateway-Server ist wie folgt:
HTTP:https://gatewaydomain/directory/filename
Folglich sendet der Web-Client, um ein Dokument direkt vom Gateway-Server abzurufen, einen geeigneten URL, in dem die Domäne die des Gateway-Servers ist.
Andererseits ist eine typische URL-Struktur für die Dokumente auf dem Server eines dritten Teilnehmers wie folgt:
HTTP:https://thirdparty.gatewaydomain/directory/filename
Folglich werden die Dokumente, die sich auf dem Server TPS1 des dritten Teilnehmers befinden, ebenfalls unter Verwendung der Domäne des Gateway-Servers gekennzeichnet und lokalisiert. Eine Dokumentenanforderung wird anfangs zum Gateway-Server geleitet, der die Anforderung in Übereinstimmung mit dem im URL spezifizierten dritten Teilnehmer zum Server des dritten Teilnehmers weiterleitet.
Fig. 3 veranschaulicht eine Authentifizierungsprozedur, die zwischen dem Web-Client und dem Gateway-Server GS ausgeführt wird. In der veranschaulichten Prozedur ist der Anwender anfangs nicht angemeldet (d. h. noch nicht authentifiziert).
Die Authentifizierungsprozedur verwendet die web-gestützte Funktionalität der "beständigen Informationen auf der Client-Seite", die häufiger als "Cookies" bezeichnet werden. Die Cookies können von einem Web-Server in ein auf Anforderung durch diesen Server gesendetes Dokument eingebettet gesendet werden. Beim Empfang eines Cookies speichert der Web-Client automatisch die Informationen im Cookie, wobei er danach die Informationen in einer Dokumentenanforderung automatisch sendet, wann immer der Web-Client versucht, ein Dokument von einem Server in der gleichen Domäne wie ein Server, von dem er das ursprüngliche Cookie empfangen hat, abzurufen. Der in der vorliegenden Ausführungsform verwendete Web- Client ist ein Browser, der Cookies unterstützt, wie z. B. diejenigen, die oben erwähnt sind.
In Fig. 3 sendet der Web-Client, um einen Anwender anzumelden, eine Dokumentenanforderung (URL) zum Gateway-Server, Schritt 100. In Reaktion auf die Dokumentenanforderung von einem momentan nicht authentifizierten Anwender erzeugt der Gateway-Server einen Token, der aus einer großen Zufallszahl besteht. Dieser Token wird dann in der Form eines Token-Cookies zum Client gesendet, Schritt 102. Beim Empfang des Cookies speichert es der Client, Schritt 104, und führt einen Authentifizierungsalgorithmus unter Verwendung des Tokens, der ihm gerade gesendet worden ist, aus, Schritt 106. Der Authentifizierungsalgorithmus nimmt den Anwendernamen und das Paßwort, die durch den Anwender in das Client- Endgerät T1 eingegeben worden sind, und führt eine Einweg-Hashing-Funktion an diesen Parametern in Kombination mit dem Token aus. Das Ergebnis der Berechnung wird dann zurück zum Gateway- Server gesendet, Schritt 108.
Beim Empfang der Antwort vom Client ruft der Gateway-Server das Paßwort für den Anwender aus der Authentifizierungsdatenbank AD ab und führt den Authentifizierungsalgorithmus auf der Seite des Gateway-Servers unter Verwendung des vorausgehend gesendeten Tokens erneut aus. Falls die empfangene Antwort und das unabhängig berechnete Ergebnis des Algorithmus übereinstimmen, Schritt 110, wird der Anwender in der Authentifizierungsdatenbank AD durch das Speichern des Tokens im Datensatz des Anwenders als angemeldet markiert, wobei die ursprüngliche Anforderung verarbeitet wird, Schritt 112.
Wenn der Anwender in der Authentifizierungsdatenbank AD als angemeldet markiert ist, wird in der Authentifizierungsdatenbank für den Anwender ein Zeitgeber eingestellt, der schließlich den Anmeldestatus seines Anwenders beendet. Jedesmal, wenn eine Dokumentenanforderung vom Anwender-Client empfangen wird, die ein gültiges Token-Cookie enthält, wird von der Authentifizierungsdatenbank AD sowohl der momentane angemeldete Status des Anwenders am Gateway-Server 10 bestätigt als auch der Zeitgeber des Anwenders zurückgesetzt. Folglich wird, falls während einer vorgegebenen Zeitperiode, z. B. 5 Minuten, keine Dokumentenanforderung vom angemeldeten Anwender empfangen wird, der Anwender automatisch abgemeldet, so daß, wenn das nächste Mal eine Dokumentenanforderung von dem Anwender empfangen wird, die das gleiche Token- Cookie enthält, der sich der Anwender neu authentifizieren muß.
Falls im Schritt 110 der Gateway-Server bestimmt, daß keine gültige Antwort empfangen wird, was am wahrscheinlichsten auf das fehlerhafte Eingeben des Paßworts des Anwenders zurückzuführen ist, und falls es der erste Fehlschlag für den Anwender ist, wird der Fehlschlag-Merker einmal inkrementiert, wobei der Gateway-Server einen neuen Adressen-Token, der den Fehlschlag-Merker in einem neuen Cookie enthält, zum Anwender-Client sendet, Schritt 102. Sobald der Anwender dreimal erfolglos war, sich zu authentifizierten, sendet der Gateway-Server eine Fehlernachricht an den Anwender-Client, die anzeigt, daß der Anwender nicht angemeldet werden wird, Schritt 116.
Sobald sich der Anwender authentifiziert hat, wird jede Anforderung für ein Dokument, entweder vom Gateway-Server selbst oder von einem der Server TPS1, TPS2, ..., TPSn der dritten Teilnehmer, als eine Anforderung von einem gültigen Anwender behandelt, weil die Anforderung von einem Cookie begleitet wird, das den Token enthält, der anzeigt, daß der Anwender momentan angemeldet ist. Der Gateway-Server bestimmt beim Überprüfen des in dem die Dokumentenanforderung begleitenden Cookie enthaltenen Tokens gegen den in der Authentifizierungsdatenbank AD aufgezeichneten Token, daß der Anwender momentan angemeldet ist:
Fig. 4 veranschaulicht die ausgeführten Prozeduren; wenn ein authentifizierter Anwender ein Dokument entweder vom Gateway- Server selbst oder von einem der Server der dritten Teilnehmer anfordert, Schritt 200.
Falls die Anforderung an den Gateway-Server selbst gerichtet ist, sendet der Gateway-Server das angeforderte Dokument (eine HTML- Web-Seite) an den Client, Schritt 202, der das Dokument parst und anzeigt, Schritt 204. Ein derartiges Dokument kann z. B. eine Homepage sein, die Hypertext-Verknüpfungen zu jedem der Server der dritten Teilnehmer enthält.
Falls andererseits die durch das Gateway empfangene Dokumentenanforderung für einen Server eines dritten Teilnehmers bestimmt ist, leitet der Gateway-Server die Dokumentenanforderung zum geeigneten dritten Teilnehmer weiter, Schritt. 206. Der Server das dritten Teilnehmers bestimmt dann aus seiner Preisfestsetzungsdatenbank 34, ob das Dokument gebührenpflichtige Inhalte enthält, d. h., ob für das Dokument ein Preis zu berechnen ist. Falls nicht, wird das Dokument (eine HTML-Web-Seite) gesendet, Schritt 208. Der Gateway-Server leitet das Dokument weiter, Schritt 210, wobei das Dokument im Client-Endgerät geparst und angezeigt wird, Schritt 212.
Falls andererseits für das Dokument mit Inhalten des dritten Teilnehmers ein Preis zu berechnen ist, bestimmt der Server des dritten Teilnehmers aus der Preisfestsetzungsdatenbank 34, welcher von mehreren Preiscodes dem Dokument zugewiesen worden ist. Diese Preiscodes werden durch den Teilnehmer vorgegeben, der den Gateway-Server steuert, wobei sie häufig durch alle Server der dritten Teilnehmer verwendet werden. Der Server des dritten Teilnehmers schickt dann eine Fehlernachricht "402" des Hypertext-Übertragungsprotokolls (HTTP) (die in der RFC 2068 als "Bezahlung erforderlich" definiert ist), die den Preiscode für das angeforderte Dokument enthält, an den Gateway-Server zurück, Schritt 216.
Beim Empfang der HTTP-"402"-Fehlemachricht, die den Preiscode vom dritten Teilnehmer enthält, wählt die Proxy-CGI 18 eines von mehreren Belastungsschemata, die in der Preisfestsetzungsdatenbank 20 gehalten werden, in Abhängigkeit von der Anwenderkennung und/oder vom aktuellen Datum/von der aktuellen Uhrzeit aus und setzt einen dem Anwender zu belastenden Preis fest, wie er durch das ausgewählte Belastungsschema bestimmt wird, Schritt 218.
Die Tabelle im folgenden zeigt ein beispielhaftes Format der Einträge in der Preisfestsetzungsdatenbank 20 an, das durch die Proxy-CGI 18 verwendet wird, um den dem Anwender zu belastenden Preis beim Empfang verschiedener Preiscodes PC1 und PC2 festzusetzen. In dieser Ausführungsform hängt der Preis, der einem Anwender für die Güter zu belasten ist, die den Preiscodes entsprechen, sowohl von einer Anwenderkategorie, zu der der Anwender gehört, der die Güter empfängt, als auch dem aktuellen Datum ab. In dem in der Tabelle angegebenen Beispiel gibt es drei Anwenderkategorien A, B und C. Es sind drei Grenzen des Datums/der Uhrzeit in der Tabelle veranschaulicht, die X, Y und Z heißen. Die Preise L, M, N, R, S und T sind für die Periode gültig, die sich von X bis Y erstreckt. Die Preise O, P, Q, U, V, W werden beim Empfang der gleichen Preiscodes PC1, PC2 erhoben, die aber zu anderen Zeitpunkten empfangen werden, nämlich innerhalb der Periode, die sich von Y bis Z erstreckt.
Die Proxy-CGI 18 kann mittels einer einem Gateway-Server zugeordneten Anwenderdatenbank, z. B. der in der Gebührenabrechnungsmaschine 26 gehaltenen Gebührenabrechnungsdatenbank, über die Anwenderkategorie informiert werden. Die Anwenderkategorien können verwendet werden, um verschiedene Niveaus des Rabattes anzuwenden, die durch den Betreiber des Gateway-Servers zuerkannt werden.
Wie aus der Tabelle offensichtlich ist, können mehrere den Anwendern belastete Preise mit einem Preiscode übereinstimmen. Die sechs verschiedenen Preise L, M, N, O, P und Q können z. B. für Inhalte belastet werden, die einem einzelnen Preiscode PC1 in der Preisfestsetzungsdatenbank 34 des Servers des dritten Teilnehmers zugeordnet sind. Das Belastungsschema in diesem Beispiel wird sowohl auf der Grundlage einer Anwenderkategorie als auch eines aktuellen Datums/einer aktuellen Uhrzeit ausgewählt. In alternativen Ausführungsformen kann sich der auf den Empfang eines Preiscodes vom Server eines dritten Teilnehmers einem Anwender auferlegte Preis nur auf der Grundlage der Kennung des Anwenders oder des aktuellen Datums/der aktuellen Uhrzeit verändern oder es kann eine Kombination von Parametern (einschließlich derjenigen, die bis jetzt erwähnt worden sind) verwendet werden, um den Preis zu bestimmen, der dem Anwender zu belasten ist.
In der sich auf die Tabelle beziehenden Beschreibung schlägt die Proxy-CGI einen dem Anwender zu belastenden Preis auf der Grundlage des Preiscodes und eines weiteren Parameters nach. In einer weiteren Alternative kann der zu belastende Preis nur durch das Nachschlagen eines Preises festgesetzt werden, der direkt mit einem Preiscode aus der Preisfestsetzungsdatenbank 20 übereinstimmt. Dieses Eins-zu-eins-Nachschlagen im Gateway-Server erlaubt trotzdem, daß der Preis mit der Uhrzeit verändert wird, indem die Preiseinträge in der Preisfestsetzungsdatenbank geändert werden, die jedem Preiscode entsprechen.
Als eine Alternative kann die Proxy-CGI einen dem Anwender zu belasten den Preis berechnen, in dem sie eine Preisfestsetzungsformel anwendet, die dem Preiscode in der Preisfestsetzungsdatenbank 20 zugeordnet ist.
Als nächstes überprüft die Proxy-CGI jede von einer oder mehreren Kreditgrenzen, die für den Anwender in der Kreditgrerlzendatenbank 22 gehalten werden, um die Annehmbarkeit des Einkaufs der Güter zu sichern. Diese Kreditgrenzen können eine durch einen Manager des Gateway-Servers festgesetzte Kreditgrenze und/oder eine durch einen Manager, der im Interesse des Anwenders handelt, festgesetzte Grenze enthalten. Vorausgesetzt, die Kreditgrenze wird durch den Käufer nicht überschritten, erzeugt die Proxy-CGI ein HTML-Formular, das den zu belastenden Preis anzeigt und die Bestätigung der Bestellung anfordert, und sendet es zum Client-Endgerät, Schritt 222.
Das Client-Endgerät parst das HTML-Formular und zeigt es an, Schritt 224, das den Anwender auffordert, die Bestellung bestätigen oder abzuweisen, Schritt 226. Alternativ kann die Web-Client-Anwendung vorkonfiguriert sein, um alle Dokumente, für die ein Preis berechnet wird, oder die Dokumente, die einen bestimmten Preis überschreiten, abzuweisen. Das ausgefüllte Formular wird dann durch den Web-Client zurückgeschickt, Schritt 228.
Falls das zurückgeschickte Formular die Bestellung abweist, schließt im Gateway-Server das Gateway die Verbindung mit dem dritten Teilnehmer, wobei keine weitere Wechselwirkung auftritt, bis eine weitere Anforderung vom Client-Endgerät hervorgebracht wird. Falls andererseits das zurückgeschickte Formular die Bestätigung der Bestellung anzeigt, erzeugt die Proxy-CGI eine Transaktionskennung (TXID), Schritt 230, und sendet eine Dokumentenanforderung (den URL der Web-Seite mit gebührenpflichtigen Inhalten) zusammen mit der Transaktionskennung, Schritt 232.
Beim Empfang einer von einer erkennbaren Transaktionskennung begleiteten Dokumentenanforderung vom Gateway-Server zeichnet der Server des dritten Teilnehmers die Transaktionskennung und den Preiscode für das angeforderte Dokument in seiner Belastungsdatenbank 36 auf und sendet das Dokument (eine HTML-Web-Site) an dem Gateway-Server, Schritt 236.
Beim Empfang der Web-Seite mit gebührenpflichtigen Inhalten vom Server des dritten Teilnehmers belastet der Gateway-Server das Konto des Anwenders und zeichnet die Transaktionskennung zum Nachteil des Kontos des Anwenders in der Gebührenabrechnungsmaschine 26 für die anschließende Gebührenabrechnung auf, Sehritt 238. Die Web-Seite selbst wird zum Web-Client weitergeleitet, Schritt 240, der die Web-Seite parst und anzeigt.
In der obenbeschriebenen Prozedur überprüft der Server des dritten Teilnehmers mit dem Gateway-Server, um zu bestimmen, ob eine Web-Seite mit gebührenpflichtigen Inhalten zum Anwender zu senden ist. Während der Überprüfung muß der dritten Teilnehmer gar keine Kenntnis besitzen, die sich spezifisch auf den Anwender bezieht, der die Web-Seite mit gebührenpflichtigen Inhalten anfordert. Falls gewünscht, können jedoch eine oder mehrere Einzelheiten, die sich auf den Anwender beziehen (z. B. die Anwenderkennung) durch den Gateway-Server zusammen mit einer Dokumentenanforderung zum Server des dritten Teilnehmers geleitet werden, um dem Server des dritten Teilnehmers zu erlauben, die Inhalte der Web-Seite vor der Sendung zum Gateway-Server zu personalisieren.
Fig. 5 ist ein Ablaufplan, der die durch die Preisbetrachtungs-CGI 16 bereitgestellte Funktionalität erklärt, die erlaubt, daß die Inhalte durch den Gateway-Server kundenspezifisch angepaßt werden. Die Preisbetrachtungs-CGI 16 verwendet einen in die HTML-Inhalte einer Web-Seite eines dritten Teilnehmers eingefügten Preiscode und erzeugt eine Bilddatei, die einen durch den Gateway-Server berechneten entsprechenden Preis enthält, die in die durch den dritten Teilnehmer gelieferte Seite einzufügen ist. Die Preisbetrachtungs-CGI nimmt den Preiscode als ein Argument und schickt die Bilddatei (ein Graphikaustauschformat oder GIF) zurück, die den Preis zeigt. Der in der Bilddatei gezeigte Preis wird in der gleichen Weise berechnet, wie im Schritt 218 des Verhandlungsprozesses für die Bestellung einer Web-Seite mit gebührenpflichtigen Inhalten, wie in Fig. 4 gezeigt ist, die Berechnung durch die Proxy-CGI ausgeführt wird. Es wird nämlich ein Belastungsschema abhängig von der Kennung des Anwenders und/oder des Datums/der Uhrzeit ausgewählt, wobei ein entsprechender Belastungsalgorithmus verwendet wird, um den Preiscode in einen tatsächlichen Preis, der anzuzeigen ist, umzusetzen.
In Fig. 5 leitet das Client-Endgerät die Prozedur durch das Senden einer Dokumentenanforderung von einem authentifizierten Anwender, die für den Server des dritten Teilnehmers bestimmt ist, ein, Schritt 300, die am Gateway-Server empfangen und zum Server des dritten Teilnehmers weitergeleitet wird, Schritt 302. Der Server des dritten Teilnehmers sendet in Erwiderung das Dokument, Schritt 304. Wie bekannt ist, werden, falls das Dokument eine Seite mit gebührenpflichtigen Inhalten ist, die in Fig. 4 veranschaulichten Schritte 214 bis 234 ausgeführt, bevor das Dokument im Schritt 304 gesendet wird. Das im Schritt 304 gesendete Dokument enthält primäre Inhalte in der Form einer HTML-Seite, wobei eine HTML- Zeile einen Preis- oder Produktcode enthält. Dies kann eine HTML- Zeile wie z. B.:
< img src = "https://gatewaydomain/cgi-Bin/VIEWPRICE.cgi?code = 014"> Sein.
Diese HTML-Zeile zeigt an, daß eine Bilddatei vom Gateway-Server abzurufen ist, die einen Preis in der Form eines Bildes bereitstellt, das abhängig vom Preiscode, der in dem oben angegebenen Beispiel 014 lautet, durch die Preisbetrachtungs-CGI 16 erzeugt oder ausgewählt worden ist.
Beim Empfang des Dokuments leitet der Gateway-Server das Dokument direkt zum Client-Endgerät, Schritt 306. Im Client-Endgerät parst die Web-Client-Anwendung die HTML, Schritt 308. Beim Parsen der obenbeschriebenen HTML-Zeile fordert der Web-Client die Bilddatei vom Gateway-Server an, Schritt 310.
Beim Empfang der Anforderung setzt der Gateway-Server den in der Bilddatei-Anforderung enthaltenen Preiscode in eine GIF-Bilddatei um, die den entsprechenden Preis für diesen Anwender anzeigt, Schritt 312, und schickt sie zum Anwender-Client zurück, Schritt 314. Das Anwenderendgerät zeigt dann die vollständige Web-Seite an, Schritt 316, die die direkt vom dritten Teilnehmer empfangenen primären Inhalte und die sekundären Inhalte in der Form der Bilddatei, die den vom Gateway-Server empfangenen Preis anzeigt, enthält. Die Seite selbst kann z. B. eine Homepage für den Server des dritten Teilnehmers sein, die Hypertext-Verknüpfungen zu einer oder mehreren seiner Web-Seiten mit gebührenpflichtigen Inhalten enthält, wobei der zu belastende Preis als ein Bild (oder einfach Text) neben der Hypertext-Verknüpfung angezeigt wird.
Die Verwendung der in Fig. 5 veranschaulichten Funktionalität stellt eine flexible Preisfestsetzungsfähigkeit ohne die Notwendigkeit bereit, daß der Gateway-Server alle Web-Seiten der dritten Teilnehmer nach spezifischen Metazeichen, die sich auf den Preis beziehen, parst. Außerdem erlaubt die Funktionalität dem Gateway-Server nicht nur, die anzuzeigenden Preise in Abhängigkeit vom Anwender und/oder vom Datum/von der Uhrzeit zu definieren, sondern er kann außerdem das Format der anzuzeigenden Preise in Abhängigkeit vom Anwender und/oder vom Datum/von der Uhrzeit definieren, falls gewünscht.
Die Kontobetrachtungs-CGI 14 bildet mit der Gebührenabrechnungsmaschine 26 eine Schnittstelle, um einem Anwender zu erlauben, alle Gebühren der gebührenpflichtigen Inhalte auf seinem Konto von irgendeinem oder allen der dritten Inhalteanbieter gleichzeitig zu betrachten. Außerdem erlaubt die Kontobetrachtungs-CGI einem Manager, der im Interesse des Anwenders wirkt, die in der Datenbank 22 gespeicherte anwenderdefinierte Kreditgrenze zu ändern.
Die Such-CGI 12 erlaubt einem Anwender, eine Suche über einen oder mehrere Server der dritten Teilnehmer auszuführen, die mit dem Gateway-Server verbunden sind. Die Such-CGI ruft die Informationen von jeder Suchmaschine 30 der dritten Teilnehmer ab und formatiert die Informationen in ein für die Darstellung für den Anwender übliches Format um.
In bezug auf die obenbeschriebene Ausführungsform könnte eine ganze Menge von Variationen verwendet werden.
Obwohl im obigen der durch den Server des dritten Teilnehmers in bezug auf ein Element der gebührenpflichtigen Inhalte gesendete Code eine Preisfestsetzungseigenschaft der Inhalte beschreibt, wird davon ausgegangen, daß eine ähnliche Funktionalität verwendet werden könnte, um andere Eigenschaften der Inhalte zu codieren. Der Code könnte z. B. das minimale Alter einer Person, an die die Inhalte gerichtet sind, erkennen lassen, wohingegen der Gateway- Server die Alterseinzelheiten seiner Anwenderbasis aufrechterhält. Dadurch könnte der Gateway-Server wirken, um die Inhalte zu filtern, um zu sichern, daß das Alter des Anwenders berücksichtigt wird, bevor die Inhalte zum Anwender weitergeleitet werden. Falls das Material für das Alter des betreffenden Anwenders ungeeignet ist, wie durch etwas angezeigt wird, das in diesem Fall ein Alterscode sein würde, kann der Gateway-Server die Inhalte blockieren, bevor sie den Anwender erreichen.
Obwohl in der obigen Ausführungsform die Einheit der Inhalte, der der Preiscode und die Gebühr zugeteilt sind, eine einzelne Web-Seite ist, kann die Einheit der Inhalte verschieden gemessen werden, sie kann z. B. aus einer Anzahl von Web-Seiten oder einer Dauer des Zugriffs auf einen Bereich der Inhalte in irgendeinem speziellen Server eines dritten Teilnehmers bestehen.
Einen besonders vorteilhaftes Authentifizierungsschema, das die Funktionalität der Cookies verwendet, wird in der obigen Ausführungsform verwendet. Es können jedoch andere web-gestützte Authentifizierungsschemata außerdem durch den Gateway-Server verwendet werden, um die Anwender zur authentifizierten, bevor der Zugriff auf die gebührenpflichtigen Inhalte auf den Servern der dritten Teilnehmer gewährt wird.
Es wird davon ausgegangen, daß weitere Variationen und Alternativen verwendet werden können, ohne vom Umfang der vorliegenden Erfindung abzuweichen, der durch die beigefügten Ansprüche definiert ist.

Claims

1. Verfahren zum Steuern von Anwenderanforderungen in einem Server-System (GS), das mit einem Anwender und mit einem dritten Teilnehmer über ein Datenkommunikationssystem kommuniziert, wobei das Verfahren umfaßt:

Empfangen einer digitalen Anforderung (300) für Güter vom Anwender über das Datenkommunikationssystem;

Weiterleiten (206) der Anforderung an den dritten Teilnehmer über das Datenkommunikationssystem;

Empfangen eines digitalen Codes (216), der auf die Güter bezogen ist, vom dritten Teilnehmer über das Datenkommunikationssystem;

Festsetzen (218) eines Preises, mit dem der Anwender für die Güter belastet wird, in Abhängigkeit von dem Code in dem Server- System;

Bestimmen (222-228) auf der Grundlage des Preises, ob die Güter vom dritten Teilnehmer bereitgestellt werden sollen; und

Anordnen (236-240) der durch den dritten Teilnehmer bereitzustellenden Güter, falls das Ergebnis der Bestimmung positiv ist.

2. Verfahren nach Anspruch 1, das das Empfangen einer weiteren digitalen Anforderung und das Festsetzen eines anderen Preises, mit dem ein Anwender belastet werden soll, wenn derselbe digitale Code empfangen wird, umfaßt.

3. Verfahren nach Anspruch 1 oder 2, bei dem der Preis aus dem Code durch das Server-System unter Bezugnahme auf eine Preisfestsetzungsdatenbank abgeleitet wird.

4. Verfahren nach Anspruch 1, 2, oder 3, bei dem der Bestimmungsschritt die Bezugnahme auf ein für den Anwender festgesetztes Akzeptanzkriterium umfaßt.

5. Verfahren nach Anspruch 4, bei dem das Akzeptanzkriterium eine monetäre Grenze ist.

6. Verfahren nach einem vorhergehenden Anspruch, bei dem der Bestimmungsschritt das Senden des Preises zum Anwender und das Anfordern einer Bestätigungsantwort vom Anwender umfaßt.

7. Verfahren nach einem vorhergehenden Anspruch, bei dem der Preis aus dem Code durch ein ausgewähltes Belastungsschema abgeleitet wird.

8. Verfahren nach Anspruch 7, das das Auswählen des Belastungsschemas in Abhängigkeit vom Anwender umfaßt.

9. Verfahren nach Anspruch 7 oder 8, das das Auswählen des Belastungsschemas in Abhängigkeit von einem Zeitwert umfaßt.

10. Verfahren nach einem vorhergehenden Anspruch, das das Ausführen einer Authentifizierung des Anwenders vor dem Weiterleitungsschritt umfaßt.

11. Verfahren nach einem vorhergehenden Anspruch, bei dem die Güter elektronische Güter umfassen.

12. Verfahren nach einem vorhergehenden Anspruch, bei dem das Datenkommunikationssystem ein System auf Internetbasis ist.

13. Verfahren nach Anspruch 12, bei dem der Code von der dritten Partei in einer HTTP-Nachricht gesendet wird.

14. Verfahren für die Bereitstellung von Gütern für Anwender, die über ein Datenkommunikationssystem kommunizieren, wobei das Verfahren die folgenden Schritte umfaßt:

Empfangen einer digitalen Anforderung (300) für Güter von einem zweiten Server-System (GS), das von einem Anwender ausgehende Anforderungen steuert, bei einem ersten Server-System (TPS 1) über das Datenkommunikationssystem;

in Reaktion auf den Empfang der digitalen Anforderung beim ersten Server Senden eines digitalen Codes (216), der auf die Güter bezogen ist, über das Datenkommunikationssystem zum zweiten Server-System; und

Bereitstellen (236-240) der Güter, falls nach dem Senden des digitalen Codes eine Bestätigung (232) der Anforderung vom zweiten Server-System durch das erste Server-System über das Datenkommunikationssystem empfangen wird,

wobei der digitale Code einem Preis entspricht, der vom zweiten Server-System festgelegt wird und mit dem der Anwender für die Güter belastet werden soll.