DE69827435T2

DE69827435T2 - System und Verfahren zum Mehrparteienverrechnen von Webzugriff

Info

Publication number: DE69827435T2
Application number: DE69827435T
Authority: DE
Inventors: James P. Ridgefield Crosskey; Mark Gee-Gwo Yorktown Heights Mei; Harish Stamford Ragavan; Kun-Lung Yorktown Heights Wu; Philip Shi-Lung Chappaqua Yu
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1997-06-16
Filing date: 1998-05-21
Publication date: 2005-10-20
Anticipated expiration: 2018-05-22
Also published as: JPH1155252A; DE69827435D1; EP0891062A2; TW392403B; KR100297634B1; EP0891062A3; JP3224776B2; US6035281A; ES2227776T3; EP0891062B1; KR19990006458A

Description

Die vorliegende Erfindung betrifft allgemein die Abrechnung von Zugriffen auf das World Wide Web des Internet und insbesondere ein System zur Aufteilung der in Rechnung gestellten Gebühren für den Zugriff auf das World Wide Web unter mehreren Teilnehmern, die an der Bereitstellung von Informationsdiensten und/oder am elektronischen Handel im World Wide Web beteiligt sind.
Während die hier enthaltenen Begriffe im Allgemeinen die ihnen im Wörterbuch zugewiesene Bedeutung haben, werden die Begriffe in der folgenden Zusammenfassung zur Verdeutlichung näher bestimmt.
Internet: Das Netzwerk, das aus Netzwerken und Gateway-Computern besteht, die die TCP/IP-Folge von Protokollen verwenden.
Client: Ein Rechner, der Befehle an den Server ausgibt, welcher die mit dem Befehl verbundene Aufgabe ausführt.
Server: Jeder Rechner, der auf Befehl eines anderen Rechners eine Aufgabe ausführt. Ein Webserver unterstützt gewöhnlich einen oder mehrere Clients.
Netzwerkprotokolle: Standardmäßige Verfahren, die es Rechnern ermöglichen, miteinander zu kommunizieren. Die Protokolle geben an; wie Daten zum Empfang und zur Übertragung über Netzwerke formatiert werden müssen. Heterogene Rechner können mittels Standardprotokollen reibungslos über ein Netzwerk kommunizieren. Beispiele für standardmäßige Internet-Protokolle sind HTTP ("Hypertext Transfer Protocol"), SMTP ("Simple Mail Transfer Protocol") und FTP ("File Transfer Protocol").
World Wide Web (WWW oder Web): Die Internet-Anwendung, die es Benutzern, die im Internet nach Informationen suchen, ermöglicht, von Server zu Server und von Datenbank zu Datenbank zu springen, indem sie auf interessierende hervorgehobene Wörter oder Sätze (Hyperlinks) klicken. Ein Internet-Webserver unterstützt Clients und stellt Informationen bereit. Das Web kann als das Internet betrachtet werden, bei dem alle Ressourcen als Uniform Resource Locators (Verweisadressen, URLs) angesprochen werden und das HTML (siehe :nachstehend) verwendet, um die Informationen, die URLs entsprechen, anzuzeigen und eine Zeige-und-Klick-Schnittstelle zu anderen URLs bereitzustellen. Im Web stellen "Browser" Client-Programme dar, während die Programme, die Informationen an den Browser zurücksenden, Server-Programme darstellen.
Universal Resource Locator (URL): Eine Möglichkeit, Informationen im Internet eindeutig zu kennzeichnen oder zu adressieren. Kann als eine Art eMail-Adresse für ein Web-Dokument betrachtet werden. Auf URLs kann mit einem Hyperlink zugegriffen werden. Ein Beispiel für eine URL ist "http:/www.arun.com:80/table.html". Eine URL hat vier Bestandteile. Von links beginnend gibt der erste Bestandteil das zu verwendende Protokoll an, der vom Rest der Verweisadresse durch ":" getrennt ist. Der nächste Bestandteil ist der Hostname oder die IP-Adresse des ziel-Hosts; dieser wird links durch "//" und rechts durch "/" oder optional ":" abgegrenzt. Die Anschlussnummer (port number) ist optional und wird links vom Hostnamen durch ":" und rechts durch "/" abgegrenzt. Der vierte Bestandteil ist der eigentliche Dateioder Programmname. In diesem Beispiel bedeutet die Erweiterung ".html", dass es sich um eine HTML-Datei handelt.
HyperText Markup Language (HTML): Die von Webservern verwendete Sprache zur Erstellung und Verknüpfung von Dokumenten, die von Web-Clients betrachtet werden. HTML verwendet Hypertext-Dokumente.
Hypertext Transfer Protocol (HTTP): Ein Beispiel für ein zustandsloses Protokoll, was bedeutet, dass jede Anforderung von einem Client an einen Server eigenständig behandelt wird. Der Server hat kein Verzeichnis von vorangegangenen Verbindungen. Am Anfang einer URL gibt "http:" an, dass die Datei Hyperlinks enthält.
Internet-Browser oder Webbrowser: Ein grafisches Schnittstellenwerkzeug, das Internet-Protokolle wie HTTP ausführt und Ergebnisse auf dem Bildschirm des Client anzeigt. Der Browser kann als Internet-Führer dienen, zu dessen Umfang bildlich dargestellte Arbeitsplätze, Verzeichnisse und Suchwerkzeuge gehören, von denen Gebrauch gemacht wird, wenn ein Benutzer im Internet verschiedene Webseiten besucht ("surft"). In dieser Anwendung ist der Webbrowser ein Client-Dienst, der mit dem World Wide Web kommuniziert.
HTTP daemon (HTTPd): Ein Webserver, der über Hypertext-Markup-Language- und Common-Gateway-InterfaceFunktionen verfügt.
HTTPd wird gewöhnlich von einem Zugriffsagenten wie zum Beispiel TCP/IP unterstützt, der die Hardware-Verbindungen zu Rehnern im Intranet bereitstellt und den Zugriff auf das Internet ermöglicht.
Damit ein Benutzer auf Informationen im World Wide Web zugreifen oder Handel im World Wide Web treiben kann, verwendet er gewöhnlich einen (Client-)Rechner, um sich über eine Telefonleitung, ein Kabel oder ein anderes Mittel auf dem Serverrechner eines Online-Diensteanbieters (on-line service provider, OLSP) einzuwählen. Der OLSP-Serverrechner wird dann mit dem Internet verbunden, wo sich die Server von Inhalteanbietern und Händlern befinden. Alle Anforderungen vom Benutzer und alle Ergebnisse von den Servern der Inhalteanbieter/Händler werden über den Serverrechner des OLSP geleitet. Für die Bereitstellung der Dienste zum Zugriff auf das Web stellt der OLSP dem Benutzer gewöhnlich eine Bereitstellungsgebühr in Rechnung.
Um Benutzern für den Zugriff auf das Web Gebühren zu berechnen, bedienen sich OLSPs im Allgemeinen zweier gängiger Abrechnungsverfahren. Entweder wird Benutzern eine Pauschale (z.B. 19,95 US-Dollar pro Monat) berechnet, oder die Abrechnung erfolgt nach der Verbindungsdauer (z.B. 1,95 US-Dollar je Stunde). Diese beiden Vorgehensweisen bei der Rechnung sind jedoch mit Unzulänglichkeiten verbunden. Ein Problem bei dem Abrechnungsverfahren mit der Pauschale besteht darin, dass es nicht die vom Benutzer vorgenommene Gewichtung der Internet-Ressourcen nach Priorität widerspiegelt. Außerdem bestärkt dieses Verfahren Benutzer nicht darin, Internet-Ressourcen zu sparen. Folglich besteht die Möglichkeit, dass Benutzer, die das Web intensiv nutzen, einen Teil der Internet-Ressourcen ausschließlich für sich in Anspruch nehmen und damit andere daran hindern, auf diese Ressourcen zuzugreifen. Andererseits ist das auf der Verbindungsdauer beruhende Abrechnungsverfahren ebenfalls unfair gegenüber den Benutzern, denen fortlaufend Gebühren in Rechnung gestellt werden, obwohl sie möglicherweise aufgrund von Wartezeiten, die entweder durch Überlastung des Netzwerks oder Nichtverfügbarkeit von Servern verursacht werden, gar keine Informationen aus dem Web erhalten. Tatsächlich wird das Problem der Netzwerküberlastung immer einschneidender, je mehr Leute im Web surfen. Und zu guter Letzt stellen diese Abrechnungsmethoden kein Verfahren zur Ansammlung von Guthaben bereit, mit denen sich zu zahlende Gebühren für den Zugriff auf das Web verrechnen ließen, um so den Web-Verkehr attraktiver zu gestalten und den Geschäftswert des Internet zu steigen.
Ein flexibles Zahlungsschema ist in "Building an accounting infrastructure for the Internet" von WENJIA FANG, GLOBAL TELECOMMUNICATIONS CONFERENCE, 1996, GLOBECOM '96, "COMMUNICATIONS: THE KEY TO GLOBAL PROSPERITY, LONDON, UK, 18. bis 22. NOVEMBER 1996, NEW YORK, USA, IEEE, USA, 18. November 1996 (28.11.1996), Seiten 105 bis 109, XP01220161, ISBN: 0-7803-3336-5, beschrieben. Bei diesem Schema kann die Bezahlung für die Nutzung des Internet durch den Sender, den Empfänger oder durch beide erfolgen. Im Falle einer Videokonferenz beispielsweise können die Teilnehmer wählen, ob sie sich die Kosten teilen wollen.
Ein Onlinedienst-Entwicklungswerkzeug mit Gebührenfestsetzungsfunktion ist in WO 96/15505 beschrieben. Die vorgesehene Gebührenstruktur berücksichtigt sowohl Gebühren, die gegenüber Benutzern erhoben werden, als auch Gebühren, die gegenüber Inhalteanbietern als Drittanbieter erhoben werden.
Um ein Abrechungsverfahren bereitzustellen, das gegenüber dem Benutzer fairer ist und gleichzeitig auch verhindern kann, dass intensive Nutzer einen Teil der Internet-Ressourcen ausschließlich für sich in Anspruch nehmen, sollte der OLSP dem Benutzer Gebühren auf der Grundlage von dessen tatsächlicher Nutzung berechnen. Eine einfache, auf der Nutzung beruhende Preisbildung könnte den Benutzer jedoch davon abhalten, das Web zu erkunden, da er möglicherweise hohe Gebühren fürchtet. Folglich besteht Bedarf an einem besseren nutzungsbasierten Abrechnungsverfahren, das den Benutzer zur Erkundung des Web ermuntert oder verlockt und auf diese Weise Inhalteanbietern/Händlern und anderen Teilnehmern am elektronischen Marktplatz zu mehr Umsatz verhilft. Es besteht auch Bedarf an einem auf der Nutzung beruhenden und unter mehreren Teilnehmern abrechenbaren Verfahren (und System), das den Zugriff auf das World Wide Web des Internet und die Aufteilung der Zugriffskosten/des Zugriffsguthabens ermöglicht.
Die vorliegende Erfindung sieht ein System und ein Verfahren vor, die dazu dienen, einem oder mehreren Teilnehmern für den Zugriff eines Client auf das Internet Gebühren in Rechnung zu stellen und Folgendes umfassen: Mittel, um mindestens einen des einen oder der mehreren Teilnehmer als zahlungspflichtig anzugeben, wobei das Angabemitte ein Mittel zur Feststellung einer Hyperlink-Quelle und eines Hyperlink-Ziels für jeden Zugriff enthält; Mittel, um jedem zahlungspflichtigen Teilnehmer auf der Grundlage einer vorher festgelegten Funktion einen Teil der in Rechnung gestellten Gebühren zuzuweisen; und Mittel, um für jeden der zahlungspflichtigen Teilnehmer in Abhängigkeit von dem Anteil, der Bandbreitennutzung eines Client, der Hyperlink-Quelle und dem Hyperlink-Ziel einen Rechnungsbetrag zu berechnen.
In einem bevorzugten System und Verfahren beruht der Rechnungsbetrag außerdem auf der Uhrzeit des Zugriffs.
Vorzugsweise umfasst eine Client-Sitzung eine Folge von Teilsitzungen, die vom Client dynamisch gestartet und beendet werden, wobei jede Teilsitzung eine bestimmte Dauer hat und der Rechnungsbetrag auf der Dauer einer jeden Teilsitzung beruht.
Vorzugsweise erfasst das System auch den tatsächlichen Umfang einer Datenübertragung in Verbindung mit dem Zugriff auf eine Webseite und berechnet den Rechnungsbetrag eines jeden zahlungspflichtigen Teilnehmers in Abhängigkeit von dem tatsächlichen Umfang der Datenübertragung.
Das Verfahren der vorliegenden Erfindung beinhaltet vorzugsweise die Schritte der Angabe von mindestens einem der zahlungspflichtigen Teilnehmer als ein Teilnehmer, der ein Bonusguthaben erhält, und der Verwendung des Bonusguthabens zur Verrechnung mit einem Rechnungsbetrag. Der Schritt der Verwendung des Bonusguthabens beruht vorzugsweise auf einer Funktion einer Webseite, die eine Hyperlink-Quelle enthält.
Der Erfassungsschritt der Erfindung beinhaltet vorzugsweise den Schritt der Auswertung von Zugriffsprotokollen und Verweisseitenprotokollen (referrer logs), um jeden Webzugriff und den entsprechenden tatsächlichen Umfang der Datenübertragung festzustellen.
Zu den Teilnehmern gehören vorzugsweise ein Client, ein Onlinedienst-Proxyserver, ein oder mehrere Server von Inhalteanbietern und/oder ein oder mehrere Werbungtreibende. Der freie Client-Zugriff durch den Onlinedienst-Proxyserver auf eingefügte Objekte, die den örtlichen Gegebenheiten angepasst wurden, wird vorzugsweise ermöglicht. Clients werden vorzugsweise auf der Grundlage einer statischen IP-Adresse oder einer dynamischen IP-Adresse ausfindig gemacht.
Der Rechnungsbetrag eines jeden Client ist vorzugsweise abhängig von der Dienstebene des Client wie zum Beispiel der Echtzeitunterstützung, der Übertragungsgeschwindigkeit, dem Erfordernis der Filterung des Inhalts und/oder dem Erfordernis der Auswahl von Werbeanzeigen.
Gemäß einer anderen Erscheinungsform der vorliegenden Erfindung stellt das System über eine Client-Schnittstelle auf einer Quellenwebseite einen Hinweis bereit, ob ein Client zur Zahlung eines Rechnungsbetrags für den Zugriff auf eine Zielwebseite verpflichtet ist. Dieser Hinweis wird vorzugsweise gegeben, indem Objektverknüpfungen, die angeben, ob der Client zur Zahlung eines Rechnungsbetrags verpflichtet ist, und die dem Client auch die Höhe seines Rechnungsbetrags angeben, in verschiedenen Erscheinungsformen dargestellt werden. Die Darstellung der Erscheinungsformen der Objektverknüpfungen kann durch unterschiedliche Farbgebung, spezielle Markierungen oder verschiedene grafische Darstellungen erfolgen.
Vorzugsweise ist einer der Teilnehmer ein Onlinedienst-Proxyserver, der eine neu abgebildete Version der Quellenwebseite aus seinem Cachespeicher abruft, wenn eine Client-Anforderung empfangen wird. Vorzugsweise bleiben die neu abgebildeten Quellenwebseiten, die die Objektverknüpfungen enthalten, intakt, ohne dass der Inhalt der Quellenwebseiten vorab abgefragt und ausgewertet werden muss, und die URL der Zielwebseite wird beibehalten.
Schließlich werden die Onlinedienst-Proxyserver vorzugsweise hierarchisch angeordnet, und die Objekte auf den Quellenwebseiten werden von jedem Proxyserver neu abgebildet, um anzuzeigen, ob der Client einer der zahlungspflichtigen Teilnehmer ist, die neu abgebildeten Objekte werden in den hierarchisch angeordneten Proxyservern des Online-Diensteanbieters entsprechend der geografischen Verbindung zum Gegenstand des Objekts gespeichert, so dass die Neuabbildung der Objekte an jedem Proxyserver den örtlichen Gegebenheiten angepasst ist und dieselbe ursprüngliche URL für jedes neu abgebildete Objekt beibehalten wird.
Diese Erfindung stellt ein nutzungsbasiertes System und Verfahren für einen OLSP oder einen anderen Teilnehmer dar, die dazu dienen, für den Zugriff auf das Web in Rechnung gestellte Gebühren unter mehreren Teilnehmern aufzuteilen, die mit einem Web-Netzwerkrechnersystem arbeiten. Zu diesen Teilnehmern können OLSPs, Inhalteanbieter/Händler, Werbungtreibende und Benutzer gehören. Vorzugsweise wird ein neuartiges Abrechnungsverfahren bereitgestellt, das es gestattet, eine Guthabenansammlung mit zu leistenden Zahlungen zu verrechnen, so dass die Web-Nutzung über standardmäßige web-Protokollierungsmechanismen genau erfasst werden kann.
Webseiten können zur Anzeige von Zahlungsverpflichtungen der Benutzer für den Zugriff auf das Web genutzt werden. Benutzer haben folglich mehr Entscheidungsfreiheit darüber, auf welche Inhalte und/oder Werbeanzeigen sie zugreifen möchten. Die vorliegende Erfindung bietet nicht nur eine Kombination der Abrechnungsmöglichkeiten nach dem regulären Telefontarif, 1-800, 1-900, Hauptsprechzeit, Nebensprechzeit, Mobilfunk, Abrechnung je aufgerufener Seite (pay-per-view billing), sondern auch die Abrechnungsmöglichkeiten nach der Art des Web-Zugriffs, d.h., ob der Zugriff dynamisch, in Echtzeit, interaktiv, unplanmäßig oder als Teilsitzung erfolgt, sowie die Möglichkeit, die Abrechnung nutzungsabhängig vorzunehmen, wobei die in Rechnung gestellten Gebühren für den web-Zugriff auch unter mehreren Teilnehmern aufgeteilt werden können.
Zwar wird bei der Abrechnung von Telefongebühren das Konzept der 800er- und 900er-Nummern zur Unterscheidung der Gebührenempfänger verwendet, doch erfolgt die Abrechnung auf der Grundlage der Verbindungsdauer oder einer Pauschalgebühr. Beim Kabelfernsehen wird der Zuschauer zwar nach dem Pay-per-View-Verfahren (Abrechnung pro gesehener Sendung) entsprechend der Benutzersitzungen belastet, doch ist nur ein einziger Teilnehmer, der Zuschauer, verpflichtet, die Rechnung zu begleichen. Mobilfunksysteme schließlich orientieren sich ebenfalls an den Benutzersitzungen, wobei sich der Anrufer und der Angerufene den Rechnungsbetrag teilen, doch ändern sich die Teilnehmer, denen Gebühren in Rechnung gestellt werden können, nicht dynamisch, sobald eine Telefonsitzung einmal gestartet wurde, und bei der Aufteilung des Rechnungsbetrags, der auf der Verbindungsdauer beruht, werden vorher festgelegten Richtlinien befolgt.
Die vorliegende Erfindung unterscheidet sich auch von dem herkömmlichen Onlinedienstmodell wie America On-Line oder Prodigy, bei dem der Diensteanbieter wie ein Vermittler auftritt, um das Inkasso bei den Anschlussnehmern zu betreiben und die Einnahmen dann unter verschiedenen Inhalteanbietern erneut aufzuteilen. Hier teilen die Zugangsbereitsteller die in Rechnung gestellten Zugangskosten der Benutzer unter mehreren Teilnehmern auf und stellen jedem Teilnehmer seinen eigenen Anteil an den Kosten in Rechnung. Der Schwerpunkt der vorliegenden Erfindung liegt jedoch nicht darauf, mehreren Teilnehmern Gebühren neu zuzuteilen, sondern darauf, das Inkasso bei mehreren Teilnehmern zu betreiben. Außerdem beruht die Zahlung an einen Inhalteanbieter/Händler bei dem herkömmlichen Onlinediensteanbieter-Modell auf der Anzahl der Kunden, die sich bei dem Onlinediensteanbieter angemeldet haben, während die vorliegende Erfindung auf der tatsächlichen Nutzung durch die Benutzer oder Kunden beruht.
Es werden nun lediglich anhand eines Beispiels Ausführungsformen der Erfindung beschrieben, wobei auf die beigefügten Zeichnungen Bezug genommen wird, in denen:
1 eine Prinzipdarstellung eines Datenverarbeitungssystems gemäß der vorliegenden Erfindung ist;
2a ein Flussdiagramm einer bevorzugten Ausführungsform des nutzungsbasierten Mehrparteien-Abrechnungsverfahrens der vorliegenden Erfindung ist;
2b ein ausführlicheres Flussdiagramm des Schritts 203 des Verfahrens von 2a ist;
3a eine Darstellung von verschiedenen Erscheinungsformen einer Hypertextseite gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung ist; und
3b ein Flussdiagramm eines Verfahrens gemäß einer weiteren bevorzugten Ausführungsform der vorliegenden Erfindung ist.
1 stellt ein Netzwerkrechnersystem 11 grafisch dar, das zur Umsetzung der vorliegenden Erfindung verwendet werden kann. Das Netzwerkrechnersystem 11 enthält einen oder mehrere Server 4 von Inhalteanbietern (oder Händlern) und einen über ein Internetnetzwerk 3 angeschlossenen Proxyserver 5 eines Online-Diensteanbieters (OLSP). Die Server kommunizieren miteinander, wobei sie bestimmte Protokolle befolgen, die in der Technik bekannt sind, wie zum Beispiel HTTP und TCP/IP. Der Fachmann versteht, dass die Internet-Verbindung zwischen den Servern auf vielerlei Arten hergestellt werden kann. Um zwischen verschiedenen Teilnehmern eine Zahlungs- /Guthabenverrechnungsfunktion bereitzustellen, kann auch ein Guthabenbereitstellungsserver 10 an das Netzwerk 3 angeschlossen werden. Der Guthabenbereitstellungsserver 10 führt für den Server 4 des Inhalteanbieters und den OLSP-Proxyserver 5 eine Guthabenprüfung durch, berechnet den zu zahlenden Nettobetrag unter den verschiedenen Teilnehmern und sorgt für die Zahlung der jeweiligen Rechnungen.
Jeder Server 4 eines Inhalteanbieters ist vorzugsweise ein zustandsloses Hypertext-Serversystem, das einer Vielzahl von Client-Rechnern 1 Dienste bereitstellt. Ein Beispiel für ein solches System ist der World-Wide-Webserver, der eine Zentraleinheit 6, einen Hauptspeicher 7 und ein Plattenlaufwerk 8 enthält. Der Server 4 speichert Hypertext-Objekte wie zum Beispiel HTML-Dateien, Dateien mit grafischen Symbolen (z.B. GIF-Dateien), Audio-, Videoobjekte und CGI-Programme auf seiner lokalen Platte 8 und stellt diese Objekte verschiedenen Clients mittels HTTP über das Internet 3 bereit. Jeder Client-Rechner 1 ist ein Personal Computer oder ein Arbeitsplatzrechner (Workstation), wie dem Fachmann bekannt ist, und verfügt vorzugsweise über einen Software-Browser wie zum Beispiel den von Netscape Communications, Inc. angebotenen Netscape Navigator, um Hypertext-Objekte über den OLSP-Proxyserver 5 abzurufen und anzuzeigen.
Gemäß einer Ausführungsform der vorliegenden Erfindung stellt ein Client-Rechner 1 entweder über ein Kabel oder eine Telefonleitung 2 mittels Modem (nicht gezeigt) eine Wählverbindung zum OLSP-Proxyserver 5 her. Über den OLSP-Proxyserver 5 können die Benutzer der Client-Rechner auf Hypertext-Objekte zugreifen, die auf den Servern 4 der Inhalteanbieter gespeichert sind. Um den Abrufprozess zu beschleunigen, kann der OLSP-Proxyserver 5 einen Teil der Hypertext-Objekte auf seiner eigenen lokalen Platte 8 zwischenspeichern, wobei er in der Technik allgemein bekannte Algorithmen zur Zwischenspeicherung verwendet. Wenn ein Client-Rechner 1 Objekte anfordert, die im Cachespeicher abgelegt wurden, gibt der OLSP-Proxyserver 5 die zwischengespeicherten Objekte an den Client-Rechner 1 zurück. Wenn sie lokal nicht verfügbar sind, leitet der OLSP-Proxyserver 5 die Anforderung im Namen des Client-Rechners 1 an den Zielserver 4 des Inhalteanbieters weiter und sendet die Ergebnisse an den Client-Rechner 1 zurück, sobald die angeforderten Objekte von dem Plattenlaufwerk 8 des Servers 4 des Inhalteanbieters abgerufen worden sind.
Daher ruft der OLSP-Proxyserver 5 Hypertext-Objekte aus dem Speicher der Server 4 der Inhalteanbieter oder aus seinem eigenen Speicher für Hypertext-Objekte auf der Platte 8 ab und sendet die Ergebnisse an die Client-Rechner 1 zurück. Der Speicher für Hypertext-Objekte kann in Form eines Dateisystems oder eines Datenbanksystems realisiert werden. Die Hypertext-Objekte werden üblicherweise im nichtflüchtigen Speicher abgelegt und können in den Hauptspeicher abgerufen werden, wenn sie angefordert werden.
Der Proxyserver 5, der auch eine Art von Hypertext-Server ist, verwendet einen herkömmlichen HTTPd, um Anforderungen von den Client-Rechnern 1 zu verarbeiten. Ein Beispiel für einen HTTPd ist der von IBM vertriebene Internet Connection Server. Für jede Hypertext-Anforderung, die verarbeitet wird, protokolliert der Proxyserver 5 bestimmte Informationen über die Anforderung in einem Anforderungsprotokoll, das sich in seinem Hauptspeicher 7 befindet. Ein Agentenprogramm kann verwendet werden, um das Hypertext-Anforderungsprotokoll aus dem Hauptspeicher 7 abzurufen, die Daten in ein Format umzuwandeln, das von dem System der vorliegenden Erfindung gelesen werden kann, und die Felder und Datensätze in einer Anforderungsprotokoll-Datenbank für Hypertext-Objekte im Plattenlaufwerk 8 zu speichern. Die Anforderungsprotokoll-Datenbank für Hypertext-Objekte kann in regelmäßigen Abständen in Speichereinheiten hoher Kapazität wie zum Beispiel auf Bänder zu Sicherungszwecken und zur Freigabe von Speicherplatz im Plattenlaufwerk 8 zwischengespeichert werden.
Die nutzungsbasierte Mehrparteien-Abrechnungslogik 9 der vorliegenden Erfindung wird vorzugsweise als rechnerlesbarer Programmcode realisiert, der im Plattenlaufwerk 8 des Proxyservers 5 gespeichert wird. Alternativ dazu kann er auf einem anderen herkömmlichen Magnetdatenträger wie zum Beispiel einer Diskette oder einem optischen Datenträger wie CD-ROM gespeichert werden. Die Abrechnungslogik 9 kann auch auf den Servern 4 der Inhalteanbieter gespeichert werden, um eine Prüfung der Zahlungen durch den OLSP oder eine Aushandlung der Zahlungen mit dem OLSP zu gestatten. Der Fachmann versteht, dass die Abrechnungslogik 9 auch für sich allein auf dem Server eines Inhalteanbieters in einer Umgebung gespeichert werden kann, in der es keinen Proxyserver und auch keine Funktion, wie sie nachstehend beschrieben wird, gibt.
Bei Zugriffen auf das Internet über einen Webbrowser stellt jeder Zugriff auf eine Webseite eine Teilsitzung dar, und das Anklicken einer HTTP-Verknüpfung steuert die Beendigung der vorherigen und den Start der nächsten Teilsitzung. Gemäß der vorliegenden Erfindung beruht die Abrechnung auf der Nutzung der (tatsächlichen) Bandbreite durch den Client für die Übertragung von der Seite, auf die zugegriffen wird.
Entsprechend einem Protokollierungsmechanismus eines Webservers werden für jeden Zugriff auf ein Hypertext-Objekt eine Vielzahl von Informationen über den Zugriff aufgezeichnet, unter anderem die Adresse des Anfordernden, die Hyperlink-Quelle (d.h. das Hypertext-Objekt, das den Client auf das Zielobjekt verweist), das Hyperlink-Ziel (d.h. das Hypertext-Objekt, auf das zugegriffen wird) und der Zeitstempel des Zugriffs. Die Hyperlink-Quelle und das Hyperlink-Ziel bilden ein Hyperlink-Zugriffspaar (V_current_stop, V_next_stop), das einen Schritt im Durchlaufpfad des Benutzers bei den Hypertext-Objekten darstellt. Das Hyperlink-Zugriffspaar stellt eine Entscheidung und eine Aktion seitens eines Webbenutzers mit der Bezeichnung user_id dar, um von der aktuellen URL mit der Bezeichnung V_current_stop zur nächsten URL mit der Bezeichnung V_next_stop zu gelangen. Um alle Zugriffspaare zwischen dem Zeitpunkt, zu dem sich ein Benutzer anmeldet, und dem Zeitpunkt, zu dem er sich vom OLSP-Proxyserver abmeldet, zu verknüpfen, kann ein Durchlaufpfad P(user_id, session_id_s) gebildet werden. Ein Durchlaufpfad kann als (V_login_stop_0, V_stop_1, V_stop_2, ... V_logout_stop_n) festgelegt werden, der alle Hypertext-Objekte anzeigt, die vom Benutzer während dieser Anmeldesitzung besucht wurden, welche mit session_id_s bezeichnet wird. Sobald ein Durchlaufpfad P(user_id, session_id_s) ermittelt wurde, können die abrechenbaren Ereignisse in Verbindung mit der Anmeldesitzung berechnet werden.
Gemäß der vorliegenden Erfindung können sich andere Teilnehmer die Rechnung mit dem Benutzer teilen. Zur Veranschaulichung dient folgendes Beispiel: Bei der mit V_current_stop bezeichneten URL-Seite ist der ursprüngliche Inhalteanbieter gegebenenfalls bereit, die Kosten für den Zugriff zu übernehmen, wenn diese Seite eine Werbeseite ist. Ebenso ist der OLSP gegebenenfalls bereit, einen Teil der Kosten zu übernehmen (in Form eines dem Benutzer gewährten Preisnachlasses), weil die Inhaltseite zuvor vielleicht lokal zwischengespeichert war. Um diese Aufteilung des Rechnungsbetrags zu gestatten, wird ein Hyperlink-Zugriffspaar HAP(user_id, session_id, hap_id) = (V_current_stop, V_next_stop) in einen Satz von Zahlungen abgebildet, der mit Pay(HAP) = {pay(user_id), pay(OLSP_id), pay(advertiser_id), pay(contentprovider_n), ... usw.} bezeichnet wird und alle Teilnehmer ausweist, die sich an der Übernahme der Kosten für dieses bestimmte Zugriffspaar beteiligen, sowie die jeweils umgelegten Kosten berechnet. Die endgültige Gesamtzahlung an und von jedem Teilnehmer wird berechnet, indem die Zahlungen für alle Zugriffspaare summiert werden.
Die Zahlungsformel unter den beteiligten Teilnehmern kann entsprechend eines bestimmten Geschäftsmodells festgelegt werden. Der Fachmann versteht, dass verschiedene Abrechnungsverfahren auf der Grundlage der vom OLSP-Proxyserver 5 bereitgestellten Protokolle möglich sind.
Für jede Sitzung können zwei oder mehr Teilsitzungen (sub-sessions, SS) festgelegt werden, von denen jede aus (user_id, session_id, hap_id, sub_session_id) besteht. Die Teilsitzung SS enthält einen Satz von Parametern, die entsprechend der Protokolle des Proxyservers erfasst werden können. Zu den für die Abrechnung geltenden Parameter können unter anderem Folgende gehören:

• die Adresse des Anfordernden,
• die Hyperlink-Quelle,
• das Hyperlink-Ziel,
• der Zeitstempel des Zugriffs,
• die Größe der Nachricht und
• der Übertragungsstatus.

Die Adresse des Anfordernden ist die Netzwerkadresse (IP-Adresse) des Client-Rechners des Benutzers. Auf Hypertext-Objekte wird gewöhnlich über Hyperlinks zugegriffen, die in einem anderen Hypertext-Objekt wie zum, Beispiel einer HTML- Datei eingebettet sind, welche von dem Browser angezeigt wird, dem der Benutzer verwendet. Wie vorstehend erörtert wurde, ist das Hyperlink-Ziel, das mit V_next_stop bezeichnet wird, das angeforderte Objekt oder die angeforderte Seite, und die Hyperlink-Quelle, die mit V_current_stop bezeichnet wird, ist das Objekt oder die Seite, die auf das Ziel verweist (oder dieses herausstellt). Sowohl die Hyperlink-Quelle als auch das Hyperlink-Ziel werden in HTTP gewöhnlich von einer weltweit eindeutigen Kennung einer Ressource (universal resource identifier, URI) oder einer Verweisadresse (universal resource locator, URL) dargestellt, und sie bilden zusammen ein Hyperlink-Zugriffspaar, wie beschrieben wurde. Der Zeitstempel weist den Zeitpunkt aus, zu dem das angeforderte Hypertext-Objekt verarbeitet und vom Proxyserver zurückgesendet wird.
Um dem Benutzer (und/oder anderen Teilnehmern) entsprechend der tatsächlichen Nutzung Gebühren in Rechnung zu stellen, werden das Hyperlink-Zugriffspaar, der Zeitstempel, die URL, der Übertragungsstatus und die Größe der Übertragungsnachricht verwendet. Da das Hyperlink-Ziel angibt, wo sich der angeforderte Inhalt befindet, kann die Abrechnungsformel den Ziel-Inhalteanbieter als Zahlungspflichtigen feststellen. Die Abrechnungsformel kann auch den Quellen-Inhalteanbieter als Zahlungspflichtigen feststellen, da die Hyperlink-Quelle den aktuellen URL-Inhalt angibt. Da der Zeitstempel den Zeitpunkt angibt, zu dem der Webserver die Anforderung verarbeitet, kann die Abrechnungsformel von der Verbindungszeit, der Spitzenzeit, der Nebenzeit usw. abhängig sein. Und schließlich kann die Abrechnungsformel im Wesentlichen auf der Nutzung der tatsächlichen Netzwerkbankbreite beruhen, da der URL-Übertragungsstatus und die Größe der Übertragungsnachricht die tatsächliche Netzwerkbandbreite angeben, die vom Client in Anspruch genommen wird.
Das Folgende sind zwei Protokolleinträge von getrennten Protokollen, die eine bestimmte Anforderung an einen OLSP-Proxyserver 5 aufzeichnen. Ein Zugriffsprotokoll zeichnet Informationen über einen Seitenzugriff (oder "Treffer") auf. Ein Verweisseitenprotokoll zeichnet Informationen über die Seite auf, die den Client auf die Seite verwiesen hat, auf die zugegriffen wurde.
192.168.1.26 – – [01/Oct/1996:08:10:20 +0600] "POST /cgi-in/db2www/col_login.d2w/report HTTP/1.0" 200 2544
Der vorstehende Text zeigt einen typischen Eintrag in einem Zugriffsprotokoll, der von einem Proxyserver als Antwort auf eine Client-Anforderung erstellt wurde. Zu den Informationen gehören unter anderem:

• die Adresse des Anfordernden: 192.168.1.26
• das Hyperlink-Ziel: /cgi-in/db2www/col_login.d2w/report
• der Zeitstempel des Zugriffs: 01/Oct/1996:08:10:20
• die Größe der übertragenen URL-Nachricht: 2544
• der URL-Übertragungsstatus: 200.

Der vorstehende Text zeigt einen typischen Eintrag in einem Verweisseitenprotokoll, der von einem Proxyserver als Antwort auf die Client-Anforderung erstellt wurde. Zu den Informationen gehören unter anderem:

• die Adresse der Hyperlink-Quelle: colds.col.watson.ibm.com
• der Zeitstempel des Zugriffs: 01/Oct/1996:08:10:20

Diese beiden Protokolleinträge zeigen an, dass eine Anmeldeanforderung eines Benutzers /cgi-bin/db2www/col_login.d2w/input von der IP-Adresse 192.168.1.26 an die Hyperlink-Zieladresse colds.col.watson.ibm.com über den tcp-Anschluss (top port) 2080 gestellt wurde und dass am 01/Oct/1996:08:10:20 eine Anmeldebericht-Antwort mit einer Größe von 2544 Byte /cgi-in/db2www/col_login.d2w/report erfolgreich an die Client-IP-Adresse 192.168.1.26 übertragen wurde.
Die Hyperlink-Quelle colds.col.watson.ibm.com:2080/cgi-bin/db2www/col_login.d2w/input und das Hyperlink-Ziel colds.col.watson.ibm.com:2800/cgi-bin/db2www/coll_login.d2w/report bilden zusammen ein Hyperlink-Zugriffspaar, das von (V_current_stop, v_next_stop) dargestellt wird, wobei V_current_stop = colds.col.watson.ibm.com:2800/cgi-bin/db2www/col_login.d2w/input einen Anmeldebildschirm darstellt, der dem Benutzer angezeigt wurde. Nachdem sich der Benutzer angemeldet und auf die Schaltfläche "absenden" ("submit") geklickt hat, wurde die Anmeldeanforderung über den top-Anschluss 2080 an den Server colds.col.watson.ibm.com übertragen. Die von V_next_stop = colds.col.watson.ibm.com:2800/cgi- bin/db2www/col_login.d2w/report dargestellte Antwort-URL wurde an den Client-Rechner zurückübertragen.
Das Folgende sind Einträge in einem Verweisseitenprotokoll für eine Anmeldesitzung eines Benutzers:
[01/Oct/1996:08:10:20 +0600]
"http://colds.col.watson.ibm.com:2080/cgi-bin/db2www/col_login.d2w/input"
[01/Oct/1996:08:10:23 +0600]
"http://colds.col.watson.ibm.com:2080/cgi-bin/db2www/col_login.d2w/report"
[01/Oct/1996:08:10:57 +0600]
"http://colds.col.watson.ibm.com:2080/cgi-bin/db2www/col_pc_add.d2w/input"
[01/Oct/1996:08:10:59 +0600]
"http://colds.col.watson.ibm.com:2080/cgi-bin/db2www/col_pc_add.d2w/report."
Das Folgende sind Einträge in einem Zugriffsprotokoll für dieselbe Anmeldesitzung eines Benutzers:
192.168.1.26 – – [01/Oct/1996:08:10:20 +0600] "POST /cgi-bin/db2www/col_login.d2w/report HTTP/1.0" 200 2544
192.168.1.26 – – [01/Oct/1996:08:10:23 +0600] "POST /cgi-bin/db2www/col_pc_add.d2w/input HTTP/1.0" 200 2918
192.168.1.26 – – [01/Oct/1996:08:10:57 +0600] "POST /cgi-bin/db2www/col_pc_add.d2w/report HTTP/1.0" 200 2433
192.168.1.26 – – [01/Oct/1996:08:10:59 +0600] "POST /cgi-bin/db2www/col_logoff.d2w/report HTTP/1.0" 200 2928.
Der entsprechende Durchlaufpfad P(user_id, session_id_s) kann berechnet werden als (col_login.d2w/input, col_login.d2w/report, col_pc_add.d2w/input, col_pc_add.d2w/report, col_logoff.d2w/report). Dieser Durchlaufpfad zeigt alle Hypertext-Objekte an, die vom Benutzer während dieser mit session_id_s bezeichneten Anmeldesitzung besucht wurden. Diese Ausdrücke bedeuten:

• col_login.d2w/input: Die Anmeldung des Benutzers wurde übergeben.
• col_login.d2w/report: Die Anmeldung des Benutzers wurde genehmigt.
• col_pc_add.d2w/input: Der Benutzer hat eine PC-Komponente angefordert.
• col_pc_add.d2w/report: Die Anforderung des Benutzers für eine PC-Komponente wurde genehmigt.
• col_logoff.d2w/report: Die Abmeldung des Benutzers wurde übergeben.

Die folgende Tabelle beschreibt die Nutzungsdatensätze für einen Benutzer mit der IP-Adresse 192.168.1.26. Eine auf der Netzwerkbandbreite beruhende Nutzung lässt sich aus dieser Tabelle ableiten. Wie zu sehen ist, wurden insgesamt 10823 Byte erfolgreich an den Benutzer mit der IP-Adresse 192.168.1.26 übertragen.
Die folgende Tabelle zeigt ein mögliches Szenario für die Aufteilung der in Rechnung gestellten Nutzungsgebühren zwischen dem Benutzer, dem OLSP und dem Werbungtreibenden für PC-Komponenten. Hier zahlt der OLSP für die Übertragung des Anmelde- und des Abmeldebildschirminhalts, der Werbungtreibende zahlt für die Seite, die für den Kauf einer PC-Komponente durch den Benutzer übertragen wurde, und der Benutzer zahlt nichts oder bekommt sogar einen Bonus vom OLSP, der möglicherweise wiederum einen Bonus von dem Werbungtreibenden erhält, weil er diese Geschäftstransaktion möglich gemacht hat.
Die folgende Tabelle zeigt ein Mehrparteien-Abrechnungsverfahren mit Spitzenzeit- und Nebenzeit-Abrechnungsfunktion. Bei diesem Beispiel wird davon ausgegangen, dass der Beginn der Spitzenzeit 08:10:30 ist. Folglich zahlt der OLSP 2544 Byte im Nebenzeittarif und 2928 Byte im Hauptzeittarif. Der Werbungtreibende zahlt 2918 Byte im Nebenzeittarif und 2433 Byte im Hauptzeittarif sowie einen bestimmten Bonus an den OLSP.
Die folgende Tabelle zeigt ein Szenario für die Aufteilung der in Rechnung gestellten Nutzungsgebühren zwischen dem Benutzer, dem OLSP und dem Werbungtreibenden für PC-Komponenten, wenn ein Teil der Übertragung nicht erfolgreich war. Hier übernimmt der OLSP den Teil der Rechnung, der dem Ereignis der nicht erfolgreichen Übertragung entspricht.
Zur Beschreibung des Abrechnungsalgorithmus werden die folgenden Datenformate für die betreffenden Felder für die Protokolltabellen des Proxyservers einschließlich der Tabelle des Verweisseitenprotokolls und der Tabelle der Zugriffsprotokolls gezeigt. Die Tabelle des Verweisseitenprotokolls hat die folgenden Felder:

• die URL des Servers der Hyperlink-Quelle (SURL): varchar(32 Bit) (z.B. colds.watson.ibm.com/cgi-bin/db2www/col_login.d2w/input)
• den Zeitstempel des Zugriffs (TS): dd/mm/yr:hr:min:sec (z.B. 01/oct/1996:08:10:20).

Die Tabelle des Zugriffsprotokolls hat die folgenden Felder:

• die IP-Adresse des Kunden (CIP): IP1.IP2.IP3.IP4: Integer
• die URL des Servers des Hyperlink-Ziels (TURL): varchar (32 Bit) (z.B. http://colds.watson.ibm.com/cgi-bin/db2www/col_login.d2w/report)
• den Zeitstempel des Zugriffs (TS): dd/mm/yr:hr:min:sec
• die Größe der übertragenen RL-Nachricht (MS): Integer
• den URL-Übertragungsstatus: Integer (MTS); Integer.

Das Folgende ist eine Sichtweise einer Datenbank, die auf der Grundlage der obigen beiden Protokolltabellen erzeugt wurde. Auf diese Sichtweise wird für den folgenden Abrechnungsalgorithmus Bezug genommen:
2a zeigt das Flussdiagramm einer bevorzugten Ausführungsform des nutzungsbasierten Mehrparteien-Abrechnungsverfahrens gemäß der vorliegenden Erfindung. Dieses Verfahren führt die nutzungsbasierte Mehrparteien- Abrechnungslogik 9 aus, die in der in 1 gezeigten Weise gespeichert ist. In jedem Abrechnungszyklus (z.B. einem Monat) werden alle vorstehend beschriebenen Protokolldatensätze, die während des Zyklus gespeichert wurden, verarbeitet, um den Gesamtrechnungsbetrag für alle zahlungspflichtigen Teilnehmer zu berechnen. Im Schritt 201 stellt die Abrechnungslogik fest, ob es noch weitere Protokolldatensätze gibt, die verarbeitet werden müssen. Wenn ja, wird der nächste Protokolldatensatz im Schritt 202 abgerufen. Im Schritt 203 werden für jeden Protokolldatensatz alle Teilnehmer, die zahlungspflichtig sind, und alle Teilnehmer, die zum Empfang eines Bonusguthabens für den Zugriff auf die entsprechende Webseite berechtigt sind, ausgewiesen.
2b ist ein ausführlicheres Flussdiagramm des Schritts 203 von 2a. Im Schritt 210 wird festgestellt, ob die IP-Adresse des Kunden (CIP) statisch oder dynamisch ist. Zum Beispiel verwenden Wählleitungen üblicherweise dynamische IP-Adressen, wohingegen Standleitungen zugewiesene statische IP-Adressen verwenden. Der OLSP kann feststellen, ob eine CIP, die in Protokolldaten gespeichert ist, statisch oder dynamisch ist. Wenn festgestellt wird, dass die IP-Adresse statisch ist, wird die IP-Adresse im Schritt 211 direkt auf eine Kunden-Buchungskontonummer (CACNO) abgebildet. Wenn festgestellt wird, dass die IP-Adresse dynamisch ist, kann ein DHCP-Programm zur dynamischen Hostkonfiguration (dynamic host configuration protocol) im Schritt 212 die dynamische IP-Zuordnung zu einem CACNO mittels einer eindeutigen Kennung aufheben. Im Schritt 213 werden die Teilnehmer, die die Rechnung bezahlen, ermittelt. Dies kann entsprechend der jeweiligen Abrechnungsfunktion (Pay(HAP)) durch Ermittlung der Ziel-URL (TURL), die in dem Zugriffsprotokoll enthalten ist, vorgenommen werden. Im Schritt 214 werden die Teilnehmer, die zum Empfang von Bonuspunkten berechtigt sind, festgestellt. Dies kann ebenso entsprechend der jeweiligen Abrechnungsfunktion (Pay(HAP) durch Ermittlung der Quellen-URL (SURL) vorgenommen werden, die in dem Verzeichnisseitenprotokoll enthalten ist.
In 2a fortfahrend, werden im Schritt 204 entsprechend einer vorher festgelegten Funktion (z.B. Pay(HAP)), die die Größe der übertragenen Nachricht (MS) des Protokolldatensatzes berücksichtigt, der zu zahlende Betrag und das Bonusguthaben für jeden Teilnehmer berechnet, nachdem alle beteiligten Parteien ermittelt worden sind. Die Berechnung des zu zahlenden Betrags oder des Bonusguthabens wird nur durchgeführt, wenn der Nachrichtenübertragungsstatus (MTS) "erfolgreich" lautet. Andernfalls werden keinem der Teilnehmer Gebühren berechnet oder ein Bonus gutgeschrieben. In Abhängigkeit von dem Zeitstempel (TS) kann für dieselbe Nachrichtengröße eine unterschiedliche Preisgestaltung zur Anwendung kommen. Eine 2-MB-Nachricht kann tagsüber zum Beispiel 20 Cent kosten, nachts aber nur 10 Cent. Eine unterschiedliche Preisgestaltung kann auch auf der Grundlage der Dauer einer jeden Teilsitzung zur Anwendung kommen. Da die Protokolldaten im Zugriffsprotokoll und im Verweisseitenprotokoll genügend Informationen enthalten, um Benutzersitzungen festzustellen, von denen jede aus einer Folge von Teilsitzungen besteht, stellt die Dauer einer Teilsitzung den Zeitraum zwischen zwei aufeinanderfolgenden Benutzeranforderungen dar. Da Anforderungen von einem Benutzer auf der Grundlage von Echtzeitinteraktionen dynamisch ausgelöst werden, kann die Dauer einer Teilsitzung vom Benutzer gesteuert werden. Auf der Grundlage des Profils des Client kann entsprechend verschiedener Dienstebenen wie zum Beispiel der Übertragungsgeschwindigkeit (z.B. ein höherer Preis für eine schnelle Übertragung), der Echtzeitunterstützung (z.B. Börsennotierungen), der Filterung des Inhalts (z.B. Festlegung des Inhalts, der empfangen werden soll) und der Auswahl der Werbeanzeigen, die empfangen werden sollen (z.B. keine Werbung) außerdem auch eine andere Preisgestaltung zur Anwendung kommen. Nachdem alle Protokolldatensätze verarbeitet wurden, wird im Schritt 205 der gesamte Rechnungsbetrag für jeden Kunden und für jeden anderen Teilnehmer, der zahlungspflichtig ist, unter Berücksichtigung eines ihnen gegebenenfalls gutgeschriebenen Bonus berechnet.
Wenn die Kosten für einen Zugriff unter mehreren Teilnehmern aufgeteilt werden können, sollte auf dem Objekt, das auf die Webseite verweist, auf die zugegriffen wird, vorzugsweise angegeben werden, ob der Benutzer für einen Teil der Zugriffskosten zahlungspflichtig ist, und wenn ja, wie hoch sein Anteil an dem Betrag ist. Dies stellt einen Anreiz für Benutzer dar, weitere Webseiten im Internet zu besuchen. Dieser auffällige Hinweis kann realisiert werden, indem durch unterschiedliche Farbgebung, spezielle Markierungen oder grafische Darstellungen, wie nachstehend mit Bezug auf 3a erklärt wird, verschiedene Erscheinungsformen von Objektverknüpfungen erzeugt werden. Ein Bild einer Werbeanzeige kann zum Beispiel so verändert werden, dass die Informationen über die Rechnungsempfänger mit aufgenommen werden, und das veränderte Bild kann in der Platteneinheit 8 auf dem OLSP-Proxyserver 5 (im Cachespeicher) gespeichert werden. Wenn die Webseite, die die Werbeanzeige enthält, vom Webbrowser auf einem Client-Rechner angezeigt wird, wird das Bild der Werbeanzeige vom Proxyserver 5 angefordert. Nachdem der Proxyserver 5 die Anforderung für das Bild empfangen hat, schickt er das lokal zwischengespeicherte veränderte Bild zurück, das die Informationen über die Abrechnung enthält. In der bevorzugten Ausführungsform wird die Webseite, die das Bild der Werbeanzeige enthält, nicht geändert. Daher ist es nicht erforderlich, die Webseiten vorher abzufragen oder auszuwerten und ihren Inhalt zu ändern. Nur die Dateien mit den Bildern von Werbeanzeigen werden verändert. Dies kann vorgenommen werden, indem die Bilddatei durch eine andere ersetzt wird, die dieselbe URL hat, der aber die Abrechnungsinformationen hinzugefügt werden. Da die veränderten Bilddateien auf dem Proxyserver gespeichert werden, kann der OLSP die Aufteilung der Zugriffskosten unter dem Benutzer und anderen Teilnehmern auf der Grundlage der Quellenwebseite und des Ziels der HTTP-Verknüpfung, das zu jeder Bilddatei einer Werbeanzeige gehört, bewerkstelligen.
3a zeigt eine Darstellung von verschiedenen Erscheinungsformen einer Hypertext-Seite, die es dem Proxyserver ermöglichen, anzugeben, ob der Betrachter der Seite oder ein anderer Teilnehmer zahlungspflichtig ist. Eine Hypertext-Seite A.html 301 enthält eine Werbeanzeige, die eine Verknüpfung zu einer IBM-Webseite herstellt. Das Bild der Werbeanzeige ist eine gif-Datei mit der Bezeichnung a.gif 302. Wenn ein Benutzer am Client-Rechner 1 die Seite A.html 301 anfordert, kann der Proxyserver 5 diese Seite vom Inhalteanbieter 4 anfordern, oder er kann sie aus seinem Cachespeicher im Plattenlaufwerk 8 abrufen. Wenn der Proxyserver 5 die Seite A.html 301 an den Client-Rechner 1 sendet, kann er außerdem auch das veränderte Bild a.gif 303 aus seinem Cachespeicher im Plattenlaufwerk 8 senden. Das Erscheinungsbild von a.gif 303 unterscheidet sich vom Erscheinungsbild von a.gif 302. In 3a zeigt a.gif 302 dem Benutzer zum Beispiel an, dass die IBM-Seite gebührenfrei ist, wenn er auf diese Werbeanzeige klickt. Der Teilnehmer, der zahlungspflichtig ist, kann an anderer Stelle auf dem Proxyserver verzeichnet sein und während des Rechnungsverarbeitungsschrittes 203 in 2a mit den Kosten belastet werden. Wie vorstehend erwähnt wurde, können die verschiedenen Erscheinungsformen der im Cachespeicher abgelegten Hypertext-Objekte durch unterschiedliche Farbgebung, spezielle Markierungen oder grafische Darstellungen hervorgehoben werden. Es sei nochmals darauf hingewiesen, dass es bei einer auf HTML basierenden Webseite A.html 301 nicht erforderlich ist, den Inhalt der Webseite A.html vorab abzufragen und auszuwerten, wenn a.gif 302 durch a.gif 303 ersetzt werden soll. Vielmehr wird a.gif 303 für den Ersetzungsvorgang einfach vom Proxyserver abgerufen, statt a.gif 302 vom Inhalteanbieter zu beschaffen. An der Objektverknüpfung in A.html 301 sind keine Änderungen notwendig, da der Dateiname nach wie vor a.gif ist und lediglich ein anderes Erscheinungsbild hat.
Jeder Teilnehmer, der zahlungspflichtig ist, kann einen Satz von gif-Dateien an den Proxyserver senden. Mit diesen gif-Dateien werden dann ursprüngliche gif-Dateien neu abgebildet, wenn sie von einem Benutzer angefordert werden. Gemäß der vorliegenden Erfindung können die beteiligten Parteien einschließlich des Online-Diensteanbieters, des Inhalteanbieters, des Benutzers und des Werbungtreibenden für den zu zahlenden Betrag unter sich aufteilen. Der Proxyserver kann auch eine andere Dienstebene bereitstellen, indem er für einen Benutzer alle Werbeanzeigen aus einer Hypertext-Seite entfernt. Der Proxyserver 5 kann nämlich a.gif 303 aus A.html 301 entfernen, indem er a.gif 303 nicht an den Client-Rechner 1 sendet.
3b ist ein Flussdiagramm eines Verfahrens gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung, das dazu dient, Objekte neu abzubilden, um die Zahlungsverpflichtung anzuzeigen. Dieses Verfahren erlaubt den Einsatz einer hierarchischen Gruppe von Proxyservern, bei der die Neuabbildung von Objekten den örtlichen Gegebenheiten angepasst und derselbe ursprüngliche Name (URL) für ein neu abgebildetes Objekt verwendet werden kann. Zum Beispiel können Autohändler im Gebiet von White Plains, New York, und Orlando, Florida, die zur gleichen Autohandelskette gehören, gemeinsam Werbeanzeigen auf der Webseite eines nationalen Inhalteanbieters platzieren. Die Händler senden getrennte, den örtlichen Gegebenheiten angepasste gif-Dateien mit Werbeanzeigen an ihre jeweiligen lokalen OLSPs. Im Schritt 310 speichert der OLSP die neu abgebildeten Objekte in seiner Vielzahl von Proxyservern. Wenn Benutzer auf die Webseite des Inhalteanbieters zugreifen, auf der die Werbung angezeigt wird, wird die Werbeanzeige im Schritt 311 von dem jeweiligen lokalen OLSP in eine Werbeanzeige mit einem den örtlichen Gegebenheiten angepassten Erscheinungsbild neu abgebildet. Im Schritt 312 ist die ursprüngliche URL für ein neu abgebildetes Objekt dieselbe, ungeachtet des jeweiligen OLSP, von dem ein Benutzer auf das Objekt zugegriffen hat. Wenn ein Benutzer eine Seite anklickt, die eine gif-Datei mit Werbeanzeigen enthält, wählt der OLSP die den örtlichen Gegebenheiten angepasste Version der gif-Datei zur Anzeige durch den Browser des Benutzers aus. Auf diese Weise können die Autohändler dafür sorgen, dass ortsansässige Kunden ihre Werbeanzeige sehen, und sie sind nur für die Zugriffe durch ihre lokalen Kunden zahlungspflichtig.
Vorstehend wurden bestimmte Ausführungsformen der vorliegenden Erfindung beschrieben, doch wird sich der Fachmann verschiedene Änderungen und Verbesserungen daran vorstellen können. Es dürfte folglich klar sein, dass die bevorzugte Ausführungsform lediglich Beispielcharakter hat und nicht als Einschränkung zu verstehen ist. Der Umfang der Erfindung ist nur durch die beigefügten Ansprüche festgelegt.

Claims

Rechnersystem (5), das dazu dient, einem oder mehreren Teilnehmern für den Zugriff eines Client auf das Internet Gebühren in Rechnung zu stellen, wobei das Rechnersystem Folgendes umfasst: Mittel, um mindestens einen des einen oder der mehreren Teilnehmer als zahlungspflichtig anzugeben; Mittel (9), um jedem zahlungspflichtigen Teilnehmer auf der Grundlage einer vorher festgelegten Funktion einen Teil der in Rechnung gestellten Gebühren zuzuweisen; dadurch gekennzeichnet, dass es des Weiteren Folgendes umfasst: Mittel, um für jeden der zahlungspflichtigen Teilnehmer in Abhängigkeit von dem Anteil, der Bandbreitennutzung eines Client, der Hyperlink-Quelle und dem Hyperlink-Ziel einen Rechnungsbetrag zu berechnen; wobei das Angabemittel ein Mittel zur Feststellung einer Hyperlink-Quelle und eines Hyperlink-Ziels für jeden Zugriff enthält.
System nach Anspruch 1, wobei das Mittel zur Berechnung eines Rechnungsbetrags ein Mittel umfasst, um den Rechnungsbetrag auf der Grundlage der Uhrzeit des Zugriffs zu berechnen.
System nach Anspruch 1, wobei das Mittel zur Berechnung des Rechnungsbetrags Mittel umfasst, um den Rechnungsbetrag für eine Client-Sitzung zu berechnen, die eine Folge von Teilsitzungen umfasst, welche von dem Client dynamisch gestartet und beendet werden.
System nach Anspruch 3, wobei jede Teilsitzung eine bestimmte Dauer hat und das Mittel in Form der Hyperlink-Quelle und des Hyperlink-Ziels zur Berechnung des Rechnungsbetrags auf der Dauer einer jeden Teilsitzung beruht.
System nach Anspruch 1, wobei das Mittel zur Berechnung des Rechnungsbetrags ein Mittel umfasst, um den tatsächlichen Umfang einer Datenübertragung in Verbindung mit einem Zugriff auf eine Webseite zu erfassen, sowie ein Mittel, um den Rechnungsbetrag eines jeden zahlungspflichtigen Teilnehmers in Abhängigkeit von dem tatsächlichen Umfang der Datenübertragung zu berechnen.
System nach Anspruch 1, das des Weiteren Folgendes umfasst: Mittel, um mindestens einen der zahlungspflichtigen Teilnehmer als einen Teilnehmer anzugeben, der ein Bonusguthaben erhält; und Mittel, um das Bonusguthaben zur Verrechnung mit dem Rechnungsbetrag zu verwenden.
System nach Anspruch 6, wobei das Mittel zur Verwendung des Bonusguthabens ein Mittel umfasst, das dazu dient, eine Funktion einer Webseite anzugeben, die eine Hyperlink-Quelle enthält.
System nach Anspruch 5, wobei das Mittel zur Erfassung Mittel umfasst, um Zugriffsprotokolle und Verweisseitenprotokolle auszuwerten, um jeden Webzugriff und den entsprechenden tatsächlichen Umfang der Datenübertragung festzustellen.
System nach Anspruch 1, wobei zu den Teilnehmern ein Client, ein Onlinedienst-Proxyserver, ein oder mehrere Server von Inhalteanbietern und/oder ein oder mehrere Werbungtreibende gehören.
System nach Anspruch 9, wobei das Mittel zur Feststellung Mittel umfasst, um durch den Online-Proxyserver einen freien Client-Zugriff auf Objekt-Einfügungen zu ermöglichen, die den örtlichen Gegebenheiten angepasst wurden.
System nach Anspruch 1, wobei das Mittel zur Feststellung Mittel umfasst, die dazu dienen, Clients auf der Grundlage einer statischen IP-Adresse oder einer dynamischen IP-Adresse festzustellen.
System nach Anspruch 1, wobei das Mittel zur Berechnung Mittel umfasst, um den Rechnungsbetrag eines Client in Abhängigkeit von der Dienstebene des Client zu berechnen.
System nach Anspruch 12, wobei die Funktion auf der Echtzeitunterstützung, der Übertragungsgeschwindigkeit, dem Erfordernis der Filterung des Inhalts und/oder dem Erfordernis der Auswahl der Werbeanzeigen beruht.
System nach Anspruch 1, das des Weiteren ein Mittel umfasst, um über eine Client-Schnittstelle auf einer Quellenwebseite anzugeben, ob ein Client zur Zahlung eines Rechnungsbetrags für den Zugriff auf eine Zielwebseite verpflichtet ist.
System nach Anspruch 14, wobei das Mittel zur Angabe Mittel umfasst, um verschiedene Erscheinungsformen von Objektverknüpfungen darzustellen, die angeben, ob der Client zur Zahlung eines Rechnungsbetrags verpflichtet ist, und die die Höhe des Rechnungsbetrags angeben.
System nach Anspruch 15, wobei das Mittel zur Darstellung Mittel umfasst, um die Erscheinungsformen der Objektverknüpfungen durch eine unterschiedliche Farbgebung darzustellen.
System nach Anspruch 15, wobei das Mittel zur Darstellung Mittel umfasst, um die Erscheinungsformen der Objektverknüpfungen durch spezielle Markierungen darzustellen.
System nach Anspruch 15, wobei das Mittel zur Darstellung Mittel umfasst, um die Erscheinungsformen der Objektverknüpfungen durch verschiedene grafische Darstellungen darzustellen.
System nach Anspruch 15, wobei einer der Teilnehmer ein Onlinedienst-Proxyserver ist und der Schritt der Darstellung den Schritt des Abrufs einer neu abgebildeten Version der Quellenwebseite aus einem Cachespeicher des Onlinedienst-Proxyservers umfasst.
System nach Anspruch 19, wobei die neu abgebildeten Quellenwebseiten, die die Objektverknüpfungen enthalten, intakt bleiben, ohne dass der Inhalt der Quellenwebseiten vorab abgefragt und ausgewertet werden muss, und die URL der Zielwebseite beibehalten wird.
System nach Anspruch 15, das des Weiteren Folgendes umfasst: Mittel, um Objekte auf den Quellenwebseiten neu abzubilden, um anzugeben, ob der Client einer der zahlungspflichtigen Teilnehmer ist; Mittel, um die neu abgebildeten Objekte in einer Vielzahl von hierarchisch angeordneten Proxyservern von Onlinedienstanbietern zu speichern; Mittel, um die Neuabbildung von Objekten auf jedem Proxyserver an die örtlichen Gegebenheiten anzupassen; und Mittel, um dieselbe ursprüngliche URL für ein neu abgebildetes Objekt beizubehalten.