DE69926459T2

DE69926459T2 - Verfahren und vorrichtung zur umlenkung von serverexternen hyperlink-referenzen

Info

Publication number: DE69926459T2
Application number: DE69926459T
Authority: DE
Inventors: T. Steven KIRSCH; J. Christopher LINDBLAD
Original assignee: Infoseek Corp
Current assignee: Disney Enterprises Inc
Priority date: 1998-05-01
Filing date: 1999-04-28
Publication date: 2006-04-20
Anticipated expiration: 2019-04-29
Also published as: US9021115B2; US20060253452A9; EP0993726B1; US9497255B2; JP4851636B2; US20030046361A1; ES2247800T3; CA2294935A1; US8543662B2; DK0993726T3; JP2002507308A; US20140040348A1; US6189030B1; JP4763748B2; US20050125416A1; AU3769699A; US6466966B1; JP2011159323A; US6859833B2; WO1999057865A1

Description

Hintergrund der Erfindung
Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich im allgemeinen auf die Steuerung von Netzwerkinformationsserversystemen, die Datenseiten, die auf das World Wide Web bezogen sind, unterstützen und insbesondere auf ein Serversystem und auf ein Verfahren zum effizienten Umleiten von Hyperlink-Verweisungen von externen Servern für die Zwecke der Steuerung, Moderierung und Abrechnung solcher Verweisungen.
Beschreibung des Standes der Technik
Das seit kurzem stattfindende beträchtliche Anwachsen und die Verwendung des international verbundenen Netzwerks, welches im allgemeinen als das Internet bekannt ist, ist zu einem großen Anteil auf die weitverbreitete Unterstützung des Hypertext-Übertragungsprotokolls (HTTP) zurückzuführen. Dieses Protokoll ermöglicht es Clientsystemen, die über Internet-Serviceanbieter (ISP) verbunden sind, zu unabhängigen und geographisch gestreuten Serversystemen, die auch mit dem Internet verbunden sind, Zugriff zu gewähren. Clientseitenbrowser, wie Netscape Mozilla^® und Navigator^® (Netscape Communications Corp.), Microsoft Internet Explorer^® und NCSA Mosaic^TM stellen effiziente, grafische, auf Clientanwendungen basierende Anwenderschnittstellen bereit, die den Clientseitenanteil des HTTP-Protokolls ausführen.
Serverseitenanwendungsprogramme, die im allgemeinen als HTTPd-Server bezeichnet werden, führen den Serverseitenanteil des NTTP-Protokolls aus. HTTP- Serveranwendungen sind sowohl kommerziell von Firmen, wie Netscape, als auch als urheberrechtlich geschützte Freeware in Quellcodeform von NCSA erhältlich.
Das verteilte System der Kommunikation und des Informationstransfers, das durch das HTTP-Protokoll ermöglicht wurde, ist im allgemeinen als das World Wide Web (WWW oder W3) oder vereinfacht als „das Netz" bekannt. Von einer Perspektive einer Clientseitenanwenderschnittstelle wird ein System aus einheitlichen Quellenangaben (URL'S) verwendet, um die Operation eines Netzbrowsers beim Ausführen von Transaktionskommunikationssitzungen auf kleinster Basis mit vorgesehenen Netzservercomputersystemen zu veranlassen. Im allgemeinen weist jede URL die Grundform:
http://<server_name>.<sub-domain.top_level-domain>/<path>
auf. Der server_name ist typischerweise „www" und die sub_domain.top-level-domain ist eine Standardinternetdomainverweisung. Der path ist eine optionale zusätzliche URL-Kennzeichnung.
Das Abfragekriterium durch die Anwenderauswahl einer URL auf der Clientseite führt zu einer Transaktion, welche durchgeführt wird, indem der Client dem Server eine HTTP-Nachricht sendet, die auf einen Fehler oder auf ein explizit benanntes Datenfile, welches in Übereinstimmung mit der Hypertext-Auszeichnungssprache (HTML) gebildet wurde, hinweist. Dieses Datenfile oder die Netzseite wird in einer oder mehrere Antwortphasen-HTTP-Nachrichten durch den Server im allgemeinen für die Anzeige durch den Clientbrowser zurückgegeben. Zusätzlich eingefügte Bildverweisungen können in der zurückgegebenen Netzseite identifiziert werden, was dazu führt, dass der Clientbrowser nachfolgende HTML-Transaktionen initiiert, um typischerweise eingefügte Grafikfiles abzufragen. Es wird anschließend ein vollständig rekonstruiertes Netzseitenbild durch den Browser durch die grafische Anwenderschnittstelle des Browsers wiedergegeben.
Aufgrund der vollständig verteilten Client/Serverarchitektur des Netzes, wie es durch das URL-System ermöglicht wurde, wird es des weiteren durch den bestehen den Internetnamenauflösungsservice und durch Routenkonventionen unterstützt. HTTP-Server können unabhängig voneinander mit geringen Schwierigkeiten eingerichtet werden. Demzufolge weist das Netz keine zentrale oder sogar regional eingerichtete Organisation auf, sondern nur lose nach dem Namen der Topleveldomain. Das Suchen nach Information, die durch individuelle HTTP-Server oder anderen Quellen bereitgestellt wird, ist demnach nahezu definitionsgemäß problematisch. Aufgrund der Zeit, Kosten und Komplexität der umfangreichen Vorrichtungen wurden sogar effizient durchsuchbare Datenbanken an Netzinformation und Quellen, sogenannte kommerzielle Internet Business Dienstleistungen (IBS) errichtet, um typischerweise auf Gebühren basierende oder durch Werbeeinnahmen getragene Suchmaschinendienstleister bereitzustellen, die für die Zusammenstellungen der Information und der Quellen, die über das Netz, welches mit der Quelle an URL's zusammen arbeitet, tätig sind. Der Zugriff zu solchen Suchmaschinen wird gewöhnlich durch lokale Servernetzseiten, die durch die Internet Business Dienstleistung angeboten werden, bereitgestellt. Die Ergebnisse solch einer Suche werden in Form von lokalen Netzseiten mit geeignet integrierter Fernabfrage oder mit Hyperlink-URL's, welche über den Server des Internet Business Service dynamisch konstruiert werden, angeboten.
Aufgrund der Möglichkeit, die von höchstwahrscheinlich wiederholtem Clientzugriff und der Abfrage von Suchmaschinen- und Suchergebnisnetzseiten bereitgestellt wird, haben Anbieter von anderen Dienstleistungen, die auf dem Internet basieren, damit begonnen, aktiv Werbungen auf diesen Netzseiten zu plazieren. Wie es für Werbungsmedien typisch ist, definiert die Häufigkeit der Anzeige einer Werbung im allgemeinen die Vergütung, die an den Veröffentlicher der Werbung gezahlt wird. Somit stellt die Häufigkeit, mit der eine Werbeanzeige einfach zu einem Clientbrowser transferiert wird, einen Hinweis bereit, wie effektiv die Werbeanzeige veröffentlicht wird. Eine direktere Messung der Effektivität einer besonderen Werbung auf einer bestimmten Netzseite ist die Häufigkeit, die ein Clientnetzbrowser wählt, um aktiv die URL, welche durch die Werbung wiedergegeben wird, abzufragen. Somit besteht ein Bedürfnis, Information, die von einem Clientbrowser erhältlich ist, wenn eine Hyperlink-Werbeanzeiger-URL ausgewählt wird, zu verfolgen.
Die Schwierigkeit beim Erhalt von direkter Verweisungsinformation stellt sich aufgrund der Tatsache dar, dass eine Netzseite mit integrierter Werbeanzeige und korrespondierender Fernabfrage-URL in ihrer Gesamtheit dem Clientbrowser bei der ersten Verweisung auf die Netzseite zur Verfügung gestellt wird. Die Auswahl einer besonderen Werbeanzeige-URL wird dann definiert durch eine unabhängige Transaktion, auf den HTTPd-Server gerichtet, der mit dem Werbeanbieter verbunden ist, durchgeführt. Da der HTTPd-Server, der den Werbeanbieter veröffentlicht, nicht Teil dieser nachfolgenden Transaktion ist, ist der veröffentlichende Server in der Regel nicht in der Lage, die Client-Browser-Hyperlinks, die tatsächlich zu einer Werbeanbieter-URL oder zu anderen URL's ausgeführt werden, die in eine Netzseite, die zuvor dem Clientbrowser dient, integriert sind, zu verfolgen.
Einfache Netzseitenzugriffszähler sind relativ gut bekannt und werden im Netz verwendet. Diese Zugriffszähler basieren auf einer gewöhnlichen Programmierschnittstelle (CGI), die durch moderne HTTPd-Server unterstützt wird. Die CGI-Schnittstelle ermöglicht es, im allgemeinen kleinen Programmen, wenigstens typischerweise als Funktion, dass diese durch einen Server in Antwort auf eine Client-URL-Anfrage ausgeführt wird. Dies bedeutet, dass die HTML-Netzseitendefinition das Integrieren einer spezifischen HTML-Verweisung vorsieht, die eine Ausführung eines Serverseiten-CGI-Programms als Teil des Prozesses des Netzbrowsers, der ein Bild auf einer angebotenen Netzseite rekonstruiert, spezifiziert. Solch eine HTML-Verweisung weist typischerweise die Form:
<img src=http://www.target.com/cgi-bin/count.cgi>
auf. Somit stellt ein Zählwert, der mit jeder diskreten Ausführung des CGI-Programms (Count.cgi) steigt, dynamisch einen Teil des darstellbaren Bilds auf der rekonstruierten Netzseite bereit. Die Zeit, die Fernzugriff-Clientanfrage, die Clientdomain, die Clientbrowserart und andere Information, welche durch die Operation des HTTP-Protokolls bekannt gemacht werden, kann als ein Teil der CGI-Programmfunktion protokolliert werden. Dementsprechend gibt es eine beträchtliche Anzahl an Zähl- und Auditvorgängen für bestimmte Netzseitenzugriffe.
Zugriffszähler zeichnen aber prinzipbedingt nur lokale Netzseitenzugriffe des Servers auf. Der Clientbrowserzugriff auf das CGI-Programm wird vom Client bewertet, im Zusammenhang mit dem ersten Bereitstellen der Netzseite für den Clientbrowser. Das anfängliche Bereitstellen der Netzseite an den Clientbrowser kann verbunden werden, aber irgendeine nachfolgende Auswahl einer URL, welche eine Hyperlink-Verweisung zu einem externen Server bereitstellt, wird nicht beobachtet und dementsprechend nicht von einem CGI-Programm, das auf einen Zugriffszähler basiert, gezählt. Andere Beschränkungen der Zugriffszählungen rühren von der Tatsache her, dass das ausgeführte CGI-Programm ein unabhängig ladbares ausführbares Programm ist. Das CGI-Programm muss diskret geladen werden und von dem Servercomputersystem in Antwort auf jede URL-Verweisung auf das CGI-Programm ausgeführt werden. Das wiederholte Programmladen und der Ausführungsmehraufwand können, obwohl er für jedes individuelle Aufrufen des CGI-Programms möglicherweise gering ist, eine signifikante, wenn nicht sogar beträchtliche Belastung des Servercomputersystems darstellen. Das häufige Ausführen des CGI-Programms ist gewöhnlich mit einer Herabsetzung der effektiven Durchschnittszugriffszeit des HTTPd-Servers in Antwort auf die Client-URL-Anfragen verbunden. Da eine Internet Business Dienstleistung, die einen Zugriff zu einer Suchmaschine bereitstellt, jeden Tag Millionen an Anfragen protokolliert, können sogar kleinere Verminderungen bei der Leistungsfähigkeit der bereitstellenden Netzseiten das Kosten-Nutzen-Verhältnis der Internet Business Dienstleistung beträchtlich vermindern. Im Dezember 1995 hatte insbesondere Infoseek Corporation im Durchschnitt fünf Millionen Zugriffe pro Tag.
Die Ausführungsmehrbelastung im Zusammenhang mit CGI-Programmen ist oft sehr bedeutend. Viele CGI-Programme sind wenigstens teilweise durch die Verwendung einer Interpretersprache, wie beispielsweise Perl oder TCL, implementiert. Dementsprechend ist ein beträchtlicher Verarbeitungsmehraufwand bei den mehrfachen Massenspeichertransfers involviert, um sowohl den Interpreter als auch die CGI-Programmskripts zu laden, die Skripts durch die Ausführung des Interpreters zu verarbeiten und dann tatsächlich zu protokollieren, welche nützlichen Daten erzeugt worden sind, was typisch ist für eine fortwährende Massenspeicherung. Schließlich können der Interpreter und/oder das CGI-Programm entladen werden müssen.
Zusätzlich führen externe CGI-Programme zu einem beträchtlichen Problem bezüglich der Wartung einschließlich initialer und fortdauernder Serverkonfiguration und Steuerung und bei der Sicherheit im Zusammenhang mit einem ausgelasteten Serversystem. Individuelle CGI-Programme werden wahrscheinlich für jede unabhängige Netzseite benötigt, um separat Netzseitenservicezählungen zu identifizieren. Alternativ kann ein CGI-Programm ausreichend komplex gestaltet werden, um in der Lage zu sein, die präzise Art, mit der ein Programm aufgerufen wird, zu unterscheiden, um eine besondere Netzseite zu identifizieren und um eine geeignete unverwechselbare Zugriffszählung zu protokollieren. Die Wartung solcher CGI-Programme auf einem Serversystem, bei dem große Anzahlen an Seitenzugängen getrennt voneinander gezählt werden, ist nicht trivial.
Des weiteren ist das Auftreten von externen Programmen, insbesondere von Skripten, die dynamisch interpretiert werden, ein potentielles Sicherheitsproblem. Insbesondere müssen der Zugriff und die Zulassungsausführung der Interpreterskripts sorgfältig gehandhabt und überwacht werden, um zu verhindern, dass irgendein nicht authorisiertes Skript ausgeführt wird, welches auf der anderen Seite die Integrität der gesammelten Daten oder die fundamentale Integrität des Servercomputersystems selbst gefährdet. Als Folge stellen bekannte Zugriffszähler keine direkte vollständige oder teilweise Lösung bezüglich des Bedürfnisses des Zugriffs oder der Audit-URL-Verweisungen an externe Server, die auf Hyperlinks von zuvor angebotenen Netzseiten basieren, bereit.
Das HTTP-Protokoll selbst sorgt für ein grundlegendes serverbasiertes System der URL-Umleitung für Server und Clients, die die 1.5-Version oder spätere Versionen des HTTP-Protokolls unterstützen. Ein Konfigurationsfile, das mit einem HTTP-Server verbunden ist (typischerweise srm.conf), kann eine umgeleitete Anweisung, die effektiv eine lokale Serververzeichnis-URL-Verweisung zu einer externen URL-Verweisung abbildet, durch die Verwendung einer Konfigurationsanwendung der Form:
Redirect/dir1 http://newServer.widget.com/dir1
spezifizieren.
Wenn eine 1.5-Version oder höhere Version des HTTP-Servers eine URL-Verweisung zu einem lokalen Verzeichnis (/dir1), das wie oben für die Umleitung spezifiziert ist, erhält, wird eine umgeleitete Nachricht zu dem Clientbrowser, umfassend eine neue Adresse in der Form einer
URL(http://newserver.widget.com/dir1), zurückgegeben. Diese umgeleitete URL wird dann durch den Clientbrowser als Basis für eine konventionelle URL-Anfrage verwendet.
Diese vorhandene serverbasierte Umleitungsfunktion ist nicht ausreichend, um eine externe Serverzugriffsverfolgung zu unterstützen, da die Umleitung in ihrer üblichen Form die gesamte Verzeichnishierarchie umfasst, die ein gemeinsam umgeleitetes Basisverzeichnis mitumfasst. Sogar in der am meisten beschränkten Form wird die Umleitung auf einer Verzeichnungsverweisungsbasis durchgeführt. Somit wird jeder Zugriff zu dem Verzeichnis, unabhängig von der besonderen Netzseite oder dem grafischen Bild oder dem CGI-Programm, welcher das spezifische Objekt einer Zugriffsanfrage ist, dennoch diskret ohne Unterscheidung umgeleitet. Irgendeine potentielle Verwendung der vorhandenen Serverumleitungsfunktion wird somit außerordentlich eingeschränkt, wenn sie nicht durch die HTTP-Protokoll definierte Operation der Umleitungsanweisung in der Praxis unterdrückt wird.
Darüber hinaus stellt die Umleitungsanweisungsleistungsfähigkeit des HTTP-Protokoll-Servers nicht die Ausführung eines CGI-Programms oder anderer ausführbarer Programme gleichzeitig mit der Durchführung der Umwandlung bereit, wobei im Wesentlichen irgendeine Wirkung ausgeschlossen wird, um Information, die mit der umgeleiteten URL-Anfrage verbunden ist, zu sammeln. Zusätzlich erhöht die Komplexität des Quellenkonfigurationsfiles, das notwendig ist, um die Umleitung zu einer Verzeichniskonfiguration zu spezifizieren, wiederum signifikant die Konfiguration, Instandhaltung und zu einem geringeren Ausmaß die Sicherheitsbestimmungen. Somit weist die Serverumleitung nicht einmal die Grundmöglichkeiten auf, die notwendig sind, um ein(e) externe(s) URL-Hyperlink-Verweisungsaudit oder -abrechnung zu unterstützen.
Schließlich könnte eine Art der Umleitung durch die Verwendung eines relativ komplexen CGI-Programms verwirklicht werden. Ein solches Umleit-CGI-Programm würde vermutlich eine Form einer anderen alternativen Quellenidentifizierung, als nötig ausführen müssen, um eine Umleitungsziel-URL zu identifizieren. Unter der Annahme, dass eine einzigartige Ziel-URL identifiziert werden kann, kann dann eine Umleitungsnachricht zu einem Clienten von dem CGI-Programm über den HTTP-Server, wenn notwendig, zurückgegeben werden, um eine Umleitungs-URL zu dem Clientbrowser bereitzustellen.
Bedauerlicherweise würde irgendein solches CGI-Programm all die Nachteile, die sogar mit dem einfachsten Zugriffszählprogrammen in Verbindung stehen, umfassen. Es würden nicht nur Probleme bei der Ausführungsbelastung und bei der Latenz wie auch bei der Konfiguration, Instandhaltung und Sicherheit verbleiben, sondern ein solcher Ansatz bei der Bereitstellung der Umleitung ist auch inhärent anfällig für Zugriffsspionage. Die Zugriffsspionage ist ein für CGI-Programme eigenes Problem, was von der Tatsache stammt, dass die HTML-Verweisung zu dem CGI-Programm ohne Bezug auf irgendeine besondere Netzseite ausgegeben werden kann. Dementsprechend kann irgendein CGI-Programm, dass einen Zugriffszähler oder ein anderes Audit- oder Abrechnungsdatenzählprogramm beeinhaltet, eine künstlich erhöhte Zugriffszählung von einer wiederholten Verweisung auf die CGI-Programm-HTML-Anweisung von außen und unabhängig von einer integren Netzseite erzeugen. Die Zugriffsspionage untergräbt in hohem Ausmaß die scheinbare, wenn nicht sogar tatsächliche Integrität jeglicher, von einem CGI-Programm gesammelter Daten. Somit würde zumindest die Fähigkeit, die Genauigkeit von sogar einer einfachen Zugriffszählung zu versichern, für einen Internetservicewerbeanbieter von fundamentaler Bedeutung sein, wobei die Verwendung von CGI-Programmen zur Bereitstellung von sogar Basisabrechnungs- oder -Auditfunktionen von begrenzter praktischer Verwendung sind. Schließlich stellt HTML keinen manipulationssicheren Weg für zwei URL's bereit, damit diese in Folge mit nur einem URL- Verweisungsknopf zugänglich werden, wie beispielsweise eine Server-CGI-Zähler-URL-Verweisung mit nachfolgender externer Server-URL-Verweisung.
Das Dokument WO 98/03923 offenbart Anwenderschnittstellen, um Information in verteilten Computersystemen abzurufen und insbesondere die Verwendung eines Barcodescanners als eine Anwenderschnittstelle, um Zugriff zu Information über das World Wide Web (WWW) des Internets abzurufen.
Das Dokument US-A-5 572 643 betrifft Computernetzwerke und insbesondere Verfahren zur Verbesserung der Leistung eines Clientbrowsers, der in einer Multi-Servercomputerumgebung arbeitet.
Zusammenfassung der Erfindung
Somit liegt ein allgemeiner Zweck der vorliegenden Erfindung darin, ein System und ein Verfahren zum zuverlässigen Verfolgen und Umleiten von Hyperlinks-Verweisungen zu externen Serversystemen bereitzustellen.
Dies wird durch die vorliegende Erfindung durch die Bereitstellung einer Nachricht an ein Verfolgungsserversystem in Antwort auf eine Verweisung eines Clientsystems auf eine vorbestimmte Quellenangabe, die einer Quelle außerhalb des Verfolgerserversystems entspricht, erreicht. Das Verfolgungsserversystem stellt für das Clientsystem indirekt ein Informationselement bereit, welches von dem Clientsystem auswählbar ist, wobei das Informationselement an dem Clientsystem grafisch identifizierbar ist mit einem Informationsinhalt, der von einem Inhaltsserversystem unter Verwendung einer Inhaltsquellenangabe beziehbar ist. Das Informationselement beinhaltet eine auf ein Verfolgungserversystem verweisende Quellenangabe und das Informationselement identifizierende Daten. Die Auswahl des Informationselements veranlasst das Clientsystem, die Verfolgungsquellenangabe zu verwenden, um Daten für das Verfolgungsserversystem bereitzustellen und um die Inhaltsquellenangabe zu verwenden, um den Informationsinhalt von dem Inhaltsserversystem zu beziehen.
Somit liegt ein Vorteil der vorliegenden Erfindung darin, dass URL-Verweisungsdaten in angemessener Weise gesammelt werden, wobei ein Minimum an Latenz der letztendlich verwiesenen Netzseiten zurückgebracht wird, während ein Minimum an Sichtbarkeit des Umleitungsprotokolls der Clientverwender dazwischengeschaltet wird.
Ein anderer Vorteil der vorliegenden Erfindung liegt darin, dass unabhängige Aufrufe von externen Serversupportprogrammen und multipler externer Datenverweisungen als Folge der vorliegenden Erfindung nicht erforderlich sind, wodurch die CPU und eine speicherintensive Belastung und die resultierende Latenz minimiert werden.
Ein weiterer Vorteil der vorliegenden Erfindung liegt darin, dass die Verweisungsindentifizierer und eine Umleitungsdirektive sowohl innerhalb der URL-Spezifikation, welche diskret von einer Client-HTML-Anfrage bereitgestellt wird, aufrechterhalten werden kann. Somit ist die vorliegende Erfindung sowohl bei der Effektivität als auch gegenüber Instandhaltungsanforderungen an einen CGI-Zähler oder an irgendein Verfahren, welches einen CGI-Zähler beinhaltet, herausragend.
Noch ein anderer Vorteil der vorliegenden Erfindung liegt darin, dass Programmodifikationen, die notwendig sind, um das Protokoll der vorliegenden Erfindung vollständig auf der Serverseite einer Protokolltransaktion zu unterstützen, durchgeführt werden. Eine Teilnahme der Clientseite bei der Transaktion liegt innerhalb des vorliegenden definierten HTML-Protokolls der Clientseite.
Noch ein weiterer Vorteil der vorliegenden Erfindung liegt darin, dass die Ausführung der Erfindung ein minimales Aussetzen an zusätzlichen Sicherheitslücken aufgrund der geschlossenen Form des Protokolls einführt, während eine beträchtliche Sicherheit gegen unpassende URL- und Protokollverweisungen bereitge stellt werden. Dies wird vorzugsweise durch den Einschluss von Validierungscodes innerhalb der URL-Spezifizierung vervollständigt.
Kurze Beschreibung der Zeichnungen
Diese und andere Vorteile und Eigenschaften der vorliegenden Erfindung werden unter Berücksichtigung der folgenden detaillierten Beschreibung der Erfindung ersichtlich, wenn sie im Zusammenhang mit den beigefügten Zeichnungen betrachtet wird, wobei Verweisungsbezeichnungen Teile innerhalb der Figuren bezeichnen und worin:
1 eine schematische Darstellung von Client- und Servercomputersystemen zeigt, die über das Internet miteinander im Netzwerkverbund stehen;
2 ein Blockdiagramm eines Servercomputersystems bereitstellt, das einen http-Dämon (HTTPd)-Server gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung zeigt;
3 ein Fließdiagramm bereitstellt, das das durchgeführte Verfahren bei einer bevorzugten Ausführungsform der vorliegenden Erfindung beim Erhalt und Verarbeiten von Client-URL-Anfragen zeigt;
4 ein Fließdiagramm bereitstellt, das die Serverseitenverarbeitung von speziellen Umleitungs-URL's gemäß einer anderen bevorzugten Ausführungsform der vorliegenden Erfindung zeigt,
5 eine verallgemeinerte Verfahrensdarstellung von Client- und Servercomputersystemen zeigt, das alternierende Verfahren der vorliegenden Erfindung ausführt;
6 ein Fießdiagramm ist, welches ein Server-Seitenverfahren zeigt, das die Verteilung einer Umfangsanfragenachricht gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung zeigt; und
7 ein Fließdiagramm ist, welches einen Client-Seitenprozess zeigt, der die Verteilung einer Verfolgernachricht gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung bereitstellt.
Detaillierte Beschreibung der Erfindung
In 1 ist ein typischer Arbeitsplatz 10 gezeigt, der das Internet für Netzwerkdienstleistungen zeigt. Ein Clientcomputersystem ist direkt oder über einen Internetdienstleistungsanbieter (ISP) mit dem Internet 14 verbunden. Es kann über eine logische Verweisung über eine einheitliche Quellenangabe auf ein korrespondierendes Internetanbietersystem 16, 18 zugegriffen werden. Es wird eine im allgemeinen geschlossene Hypertexttransferprotokolltransaktion zwischen einer Clientbrowseranwendung, die auf dem Clientsystem 12 ausgeführt wird und einer HTTPd-Serveranwendung, die auf dem Serversystem 16 ausgeführt wird, durchgeführt. In einer bevorzugten Ausführungsform der vorliegenden Erfindung stellt das Serversysten 16 eine Internet-Business-Dienstleistung (IBS) dar, welche Netzseiten, die Hyperlinkverweisungen zu anderen HTTPd-Serversystemen, die mit dem Internet 14 verbunden sind, einbettet, und welche wenigstens logisch extern an das Serversystem 16 angeschlossen sind, unterstützt oder anbietet.
Innerhalb dieses allgemeinen Systems ermöglicht die vorliegende Erfindung das Verfolgen der Auswahl von eingebetteten Hyperlinkverweisungen durch das Clientsystem 12. Das bedeutet, dass eine eingebettete Hyperlinkverweisung mit einem grafischen Banner oder einem anderen Netzseitenelement, das von einem Anwender des Clientsystems 12 auswählbar oder anklickbar ist, verbunden ist. Ein Anklicken des Banners auf einem Clientsystem wird typischerweise durchgeführt, um Information, welche auf irgendeine Art durch die Bannergrafik, welche für den Clientsystemanwender von Interesse ist, zu erhalten. Das Verfolgen wird vorzugsweise ermöglicht, indem HTML-Information in der Netzseite, die dem Clientsystem 12 zur Verfügung gestellt wird, eingebettet wird. Diese Information wird von irgend einem voreingestellten HTTPd-Serversystem an das Clientsystem 12 geliefert. Die Voreinstellung erfolgt mit einem IBS, um Banneranklickungen auf Netzseiten zu verfolgen, die durch einen oder aufgrund eines vorgesehenen Verfolgungs-HTTPd-Serversystems wie System 16 bereitgestellt wird, welches arbeitet, um die angebotene Seite, die die Verfolgungsinformation bereitstellt, zu sammeln.
Gemäß der vorliegenden Erfindung ist die eingebettete Information ausreichend, um zu ermöglichen, dass das Clientcomputersystem 12 Verfolgungsinformation an das HTTPd-Serversystem 16 bereitstellt. Wie es ersichtlich ist, ist diese Information auch direkt oder indirekt ausreichend, um zu ermöglichen, dass der Clientcomputer die Information, die mit der Bannergrafik verbunden ist, abfrägt. Wie es ersichtlich ist, gibt es eine Anzahl an möglichen Anwendungen der vorliegenden Erfindung. Diese Anwendungen können im allgemeinen hauptsächlich unter Verwendung entweder eines Serverseiten- oder Clientseitenverfahrens, verbunden mit urheberrechtlich geschützten Einschub- und interpretierten Kontrollverfahren und über die Verwendung einer Anzahl von spezifischen Datentransferprotokollen kategorisiert werden.
Die bevorzugte Ausführungsform der vorliegenden Erfindung verwendet ein Serverseitenverfahren, das als eine urheberrechtlich geschützte Modifizierung der HTTPd-Serveranwendung, die durch das Serversystem 16 durchgeführt wird, ausgeführt wird und das die HTTP-Umleitungsanordnung verwendet. Somit umfasst eine Netzseite, die von einem HTTPd-Serversystem, wie beispielsweise dem Serversystem 16 oder einem anderen Serversystem (nicht gezeigt), dem Client 12 bereitgestellt wird, eine URL-Verweisung auf eine Netzseite, die von dem logischen externen Serversystem bereitgestellt wird. Die Auswahl dieser eingebetteten URL durch den Clientbrowser des Clientcomputersystems 12 führt zunächst eher zu einer HTTP-Transaktion mit dem Serversystem 16 als mit dem externen Server. Die Information, die in der eingebetteten URL enthalten ist, die als erste mit der Netzseite an das Clientsystem 12 bereitgestellt wird, wird so an das Serversystem 16 zurück bereitgestellt und zwar auf die Auswahl der URL hin, obwohl sogar das ersichtliche Ziel der URL das externe Serversystem ist. Es wird dann durch das Serversystem 16 eine Umleitungsantwort an das Clientsystem 12 bereitgestellt, das die korrespondierende Umleitungs-URL bereitstellt.
Wie es in 2 gezeigt ist, empfängt das Serversystem 16 die Umleitungsanfrageinformation über eine Netzwerkverbindung 20 zu einer Netzwerkschnittstelle 22 innerhalb des Serversystems 16. Die Netzwerkschnittstelle 22 ist durch einen internen Bus 24 mit einer zentralen Verarbeitungseinheit (CPU) 26 verbunden. Die CPU 26 führt ein Netzwerkbetriebssystem 28 mit Unterstützung der Netzwerkschnittstelle 22 und anderen funktionalen Aspekten des Serversystems 16 aus. Das Netzwerkbetriebssystem 28 unterstützt die Ausführung einer HTTPd-Serveranwendung 30 durch die CPU 26, die die darauffolgende Operation des Serversystems 16 auf die über das Netzwerk 20 hin empfangene HTTP-Anforderung hin festlegt. Schließlich stellt das Netzwerkbetriebssystem 28 die temporäre und permanente Speicherung der Daten in einer Massenspeichervorrichtung 32 bereit, die vorzugsweise ein Permanentspeichermedium umfasst, wie sie beispielsweise durch ein herkömmliches Festplattenlaufwerk bereitgestellt wird.
Gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung wird die eingebettete Umleitungsinformation, die als Teil einer URL-HTTP-Anfrage bereitgestellt wird, durch den HTTPd-Server 30 verarbeitet. Das Verarbeiten durch den HTTPd-Server 30 wird vorzugsweise durch die Ausführung des Servers 30 anstelle der Ausführung irgendwelcher externer CGI-Programme oder dergleichen durchgeführt. Die Umleitungsinformation wird durch die Ausführung des Servers 30 verarbeitet, um die besondere URL-Verweisung zu identifizieren und zu validieren, welche die Umleitungsinformation bereitgestellt hat und um ein Umleitungsziel-URL zu erzeugen.
In einer bevorzugten Ausführungsform der vorliegenden Erfindung wird eine eingebettete URL, die eine Umleitungsinformation enthält, wie folgt formatiert:
http://<direct_server>/redirect?<data>?http://<redirect_server>
Der direct_server-Anteil der eingebetteten URL spezifiziert das HTTP-Serverziel einer Transaktion, welche zunächst durch das Clientsystem 12 aufgebaut werden soll. Die verbleibende Information wird dem Verfolgungsserver oder dem direkten Zielserver bereitgestellt. Der direkte Zielserver kann irgendein HTTPd-Server sein, der von dem Clientserver 12 zugänglich ist, der dafür vorgesehen ist, erfindungsgemäße Umleitungsanfragen zu verwenden.
Der Ausdruck „Umleitung" in der eingebetteten Umleitungs-URL ist ein Schlüsselwort, welches von dem HTTPd-Server 30 voridentifiziert wird, um zu spezifizieren, dass die URL zu einer Umleitungsanfrage gemäß der vorliegenden Erfindung korrespondiert. Obwohl der Ausdruck „Umleitung" der bevorzugte Ausdruck ist, kann irgendein Ausdruck oder Code ausgewählt werden, vorausgesetzt, dass der Ausdruck durch den HTTPd-Server 30 einheitlich identifiziert werden kann, um eine Umleitungs-URL zu bestimmen. Der Identifizierungsablauf des Ausdrucks „Umleitung" wird vorzugsweise durch die Ausführung des Servers 30 durch eine korrespondierende Modifizierung der HTTPd-Serveranwendung durchgeführt. Das bedeutet, dass die HTTPd-Serveranwendung modifiziert wird, um den Ausdruck „Umleitung" als ein Schlüsselwort zu erkennen und ein Unterprogramm durchzuführen, welches den Serverseitenprozeß der bevorzugten Ausführungsform ausführt. Als Alternative kann die Modifizierung der HTTPd-Serveranwendung als ein „plug in"-Binärprogrammvorgang über eine herkömmliche Schnittstelle unter Bereitstellung der HTTPd-Serveranwendung ausgeführt werden, um im wesentlichen die gleiche Funktionalität zu erhalten. Es kann auch eine in einer Serveranwendung eingebettete Sprache wie Java^→ oder JavaScript^→ alternativ verwendet werden, obwohl sie wahrscheinlich weniger Leistungsfähigkeit besitzt, um das Serverseitenverfahren der Wiedererkennung des „Umleitungs"-Schlüsselwortes zu erkennen und um das weitere Verarbeiten durchzuführen, um die vorliegende Erfindung auszuführen.
Der Ausdruck „Daten" der Umleitungs-URL stellt Verweisungsidentifizierungsdaten an den HTTPd-Server 30 bereit, welche verwendet werden können, um des weiteren eine Umleitungs-URL an den HTTPd-Server 30 zu identifizieren und möglicherweise zu validieren. Die Daten ermöglichen somit einen Zugriff zu der Umleitungs-URL, welcher durch den HTTPd-Server 30 hergestellt wird. Im Zusammenhang mit einer Werbeanzeige können die Daten einen bestimmten Werbeclient codieren, für den die Zugriffsdaten bereitgestellt werden können, ein besonderes Beispiel des Grafikbildes, welches einem Clientsystem 12 in Zusammenhang mit der Umleitungs-URL bereitgestellt wird und möglicherweise ein Validierungscode, der dazu dient, zu gewährleisten, dass unpassende Clienten, die eine Umleitungs-URL verwenden, durch den HTTPd-Server unterschieden und abgelehnt werden.
Eine beispielhafte Umleitungs-URL, die unter Verwendung von HTML gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung konstruiert wurde, ist die nachfolgende:
<a href="http://www.infoseek.com/IS/redirect?NwPg-003-AA?http://www.newspage.com">
Innerhalb der Umleitungsdaten dient der Datenbestandteil „NwPg" als ein Client- oder als ein Zugriffsidentifizierer. Der Datenbestandteil „003" ist ein Serienidentifizierer, der ein bestimmtes Grafikbild anzeigt, welches mit der Umleitungs-URL in der Netzseite, die dem Clientsystem 12 dient, eingebettet ist. Schließlich kann der Datenbestandteil „AA" verwendet werden, um einen Basisvalidierungsidentifizierer bereitzustellen, welcher dazu dient, dem HTTPd-Server 30 zu ermöglichen, wiederholte ungeeignete Eingaben der Umleitungs-URL zu dem Serversystem 16 oder solche, welche durch Konvention als obsolet bestimmt worden sind, zu identifizieren.
In einer alternativen Ausführungsform der vorliegenden Erfindung codieren die Validierungsdaten eine Datenwiedergabe, die im Zusammenhang mit dem HTTP-Protokoll verwendet werden kann, um Information in Bezug zu dem Clientsystem 12, welche durch die Umleitungs-URL eingegeben wurden, und gegebenenfalls Grafikserienidentifizierungsdaten, um die wiederholte Verwendung der Umleitungs-URL durch das gleiche Clientsystem 12 innerhalb einer definierten kurzen Zeitperiode zu vermindern. Somit kann ein ungeeigneter Zugriff durch einen dritten Client, der mit den Daten, die von dem Serversystem 16 bezüglich irgendeiner besonderen Umleitungs-URL mit relativer, wenn nicht mit vollständiger Sicherheit identizifiert werden kann, gestoppt werden. Zusätzlich können die Datencodes, die älter sind als ein bestimm tes Zeitintervall, durch den Computer für ungültig erklärt werden. Demzufolge kann eine Kopie der eingebetteten Umleitungs-URL nicht auf einem Clientsystem 12 gespeichert werden und bleibt für die Verwendung für länger als eine Zeitperiode, die exklusiv durch das Servercomputersystem 16 bestimmt wird, sichtbar.
Jeder der Datenterme innerhalb einer Umleitungs-URL kann statisch oder dynamisch durch den HTTPd-Server 30 als Teil des Verfahrens der ursprünglichen Bedienung einer Netzseite mit der eingebettten Umleitungs-URL zu einem Clientcomputersystem 12 gebildet werden. Mit der dynamischen Erzeugung können unterschiedliche Grafikbilder, die einem einzelnen Werbeanbieter oder irgendeinem der Werbeanbieter entsprechen, wirksam mit einer anderweitig statisch definierten Netzseite bedient werden. Die Datenterme der eingebetteten Umleitungs-URL können in Bezug auf die Identität der Werbeanbieter und des Grafikbildes dynamisch zusätzlich zum getrennten Errichten eines Hypertextlinks zu dem grafischen Bild als Teil eines Beispiels zum Bedienen einer besonderen Netzseite durch den HTTPd-Server 30 ausgeführt werden. Tatsächlich konnte die Auswahl eines Werbeanbieters und grafischen Bildes wenigstens teilweise durch die Identität des Clientcomputersystems 12, wie es durch Information, die durch konventionelle Operation des HTTP-Protokolls und auf den Clientprofil bereitgestellt werden, falls bekannt, festgestellt werden.
Der Validierungscode kann auch dynamisch erzeugt werden. In einer alternativen Ausführungsform der vorliegenden Erfindung kodiert der Validierungscode eine Wiedergabe des Tags des Jahres mit den Zugriffs- und Bildidentifizierungsdatentermen, um einen Identifizierer zu erzeugen, vorzugsweise zweistellig kodiert, wobei ein ausreichender Level an Einzigartigkeit bereitgestellt wird, um zu ermöglichen, dass eine eingebettete Umleitungs-URL auf einer täglichen Basis dem Alter her bewertet wird. Darüber hinaus bleibt der Validierungscode auf einer täglichen Basis konstant und ermöglicht somit die Anzahl an Verweisungen an einem Tag pro spezifischer Clientsystembasis 12, welche durch den HTTPd-Server 30 verfolgt werden, um die Frequenz, mit der ein spezifischer Aufruf der Netzseite wiederholt dem spezifischen Client 12 bereitgestellt wird, zu limitieren. Zusätzlich kann der HTTPd-Server 30 als ein Blockvorgang auf einer erreichten Umleitungs-URL operieren, wobei die korres pondierende Netzseite nicht kürzlich dem Client 12, der eine Anfrage getätigt hat, gedient hat.
Verschiedene Bit-Shifts-, Checksummen- und arithmetische Modulo-Algorithmen können verwendet werden, um den Validierungscode in einer konsistenten Art, die dem HTTPd-Server 30 bekannt ist, zu erzeugen, die aber bei der Prüfung der resultierenden Umleitungs-URL durch ein spezifisches Clientcomputersystem 12 nicht leicht erkannt werden. Alternativ kann der Validierungscode ein zufällig ausgewählter Wert sein, der implizit durch den HTTPd-Server 30 für eine programmierbare Zeitperiode von einem Tag bis zu einigen Wochen oder länger implizit erkannt wird. Im Extremfall und in Konsistenz mit der anfänglich bevorzugten Ausführungsform der vorliegenden Erfindung ist der Validierungscode ein statischer Wert, der als Teil der eingebetteten Umleitungs-URL bereitgestellt wird.
Unabhängig von der besonderen Art, mit der der Validierungscode erzeugt wird oder von der zugeordneten Zeitlänge, mit der der Code durch den HTTPD-Server 30 als gültig ernannt wird, wird die Bewertung der Datenterme einer Umleitungs-URL vorzugsweise vollständig intern an den HTTPd-Server 30 durchgeführt. Die Datenterme sind vorzugsweise ausreichend vollständig, um eindeutig einen besonderen Aufruf einer eingebetteten Umleitungs-URL ohne bedeutsamen Zugriff, wenn überhaupt, zu dem Laden und Ausführen eines externen Programms oder sogar bedeutsam, um Look-up-Dateien zu befragen, die durch die Dauerspeichervorrichtung 32 gespeichert werden. Dementsprechend wird der Aufwand bei der Bewertung einer Umleitungs-URL gemäß der vorliegenden Erfindung nahezu vollständig durch den Computer durchgeführt. Wie es gewöhnlicherweise bewertet wird, ist die Leistungsfähigkeit eines Servercomputersystems 16 nicht typischerweise an den Computer gebunden, sondern eher an die Geschwindigkeit des Eingang/Ausgang(I/O)-Zugriffs, an die Permanentspeichervorrichtung 32 und an das Netzwerk 20 gebunden. Indem die Bewertung der Umleitungs-URL durch einen Computervorgang beträchtlich oder sogar vollständig limitiert wird, mit nur einer limitierten I/O-Operation, um Audit- oder Abrechnungsdaten zu sichern, die im Zusammenhang mit einer Umleitungs-URL erhalten werden, wird eine optimale minimale Belastung des Servercomputersystems 16 durch die Ausführung der vorliegenden Erfindung erzielt.
Somit kann das Sichern von Zugriffs- oder Auditdaten durch das Netzwerkbetriebssystem 28 zwischengespeichert werden, um den Schreib-I/O-Vorgang zu der Permanentspeichervorrichtung 32 zu verschieben, bis andererseits ein Überschuss der I/O-Bandbreite in der permanenten Ausführung des Servercomputersystems 16 erhältlich ist.
Der letzte Abschnitt der bevorzugten Struktur einer Umleitungs-URL ist eine zweite URL. Diese zweite URL identifiziert vorzugsweise direkt das Zielserversystem für die Umleitung. Vorzugsweise wird irgendein Pfadabschnitt, der als Teil der direkten Serverspezifikation der Umleitungs-URL bereitgestellt wird, als ein Pfadbestandteil des Umleitungsserverabschnitts der Umleitungs-URL wiederholt. Es ist jedoch keine Pfadabschnittsidentität erforderlich. Im allgemeinen ist alles, was gemäß der vorliegenden Erfindung erforderlich ist, eine eins-zu-eins-Korrespondenz zwischen den direkten Server- und Umleitungsservertermen der Umleitungs-URL. Es kann ein weniger stringentes Verhältnis verwendet werden, wenn die Auswirkung auf die Audit- oder Abrechnungsdaten, die durch den Vorgang der vorliegenden Erfindung gesammelt werden, mit den erwünschten Eigenschaften dieser Daten konsistent sind. Es können beispielsweise unterschiedliche direkte Serverspezifikationen mit der Verwendung eines gewöhnlichen Umleitungsservers als eine Einrichtung zur weiteren Identifizierung einer besonderen Initiierung irgendeiner eingebetteten Umleitungs-URL korrelieren. Alternativ können auf der anderen Seite identische Aufrufe einer eingebetteten Umleitungs-URL auf irgendeine Anzahl an Umleitungsserver verweisen. Somit stellt die eingebettete Umleitungs-URL nur eine indirekte Verweisung auf den zu letzten bedienenden Umleitungsserver bereit und verlässt sich auf den durch das Serversystem identifizierten direct_server oder auf die umgeleiteten Server selbst, um die zweite URL in eine direkte Verweisung zu einen letzten bedienenden Umleitungsserver aufzulösen. Dies kann durchgeführt werden, indem die Beladung auf den kooperativ arbeitenden Umleitungsservern verteilt wird, oder indem eine Einrichtung zum Überprüfen der Audit- oder Abrechnungsdaten, welche durch die fortlaufende Operation der vorliegenden Erfindung gesammelt wurden, bereitgestellt wird. Somit kann die zweite URL einer Umleitungs-URL selbst eine Umleitungs-URL sein, wenngleich Sorge dafür getragen werden muss, damit keine endlose Umleitungsschleife erzeugt wird.
Ein bevorzugtes Verfahren 40 der Verarbeitung von Umleitungs-URL's, welche zu einem Servercomputersystem 16 von einem Clientcomputersystem 12 bereitgestellt werden, ist in 3 abgebildet. Da jede Clientanfrage 42 erreicht, werden die Daten, die als Teil der Anfrage bereitgestellt werden, untersucht, um zu überprüfen, ob die Anfrage das Umleitungsschlüsselwort 44 einbettet. Wenn die URL-Daten keine Umleitungsanfrage spezifizieren, die mit der vorliegenden Erfindung im Einklang ist, werden die URL-Daten überprüft, 46, um zu bestimmen, ob die URL-Daten konventionell eine existierende lokale Netzseite spezifizieren. Wenn die Netzseite nicht existiert oder in Bezug auf die clientbezogenen Identifizierungsdaten, die über das HTTP-Protokoll in Zusammenhang mit der URL-Clientanfrage bereitgestellt werden, erhält der bestimmte Client keinen Zugriff zu der vorhandenen Netzseite, wobei der HTTPd-Server 30 eine entsprechenden Fehlermeldung 48 bestimmt, die an das Clientcomputersystem 12 zurückgegeben wird. Auf der anderen Seite fährt der HTTPd-Server 30 fort und leitet die lokale Netzseite 50 an das Clientcomputersystem 12.
Wenn die URL-Daten wenigstens eine Umleitungsanfrage 52 spezifizieren, werden die URL-Daten ferner auf Gültigkeit überprüft. Es kann eine Tabelle aus gültigen Kombinationen des Client- und Grafikbildidentifizierers, welche vorzugsweise in den Datenspeicher in dem Serversystem 16 zwischengespeichert wird, verwendet werden, um die Gültigkeit der Umleitungsanfrage zunächst zu überprüfen. Der Validierungscode kann entweder durch Rekalkulierung bezogen auf die bereitgestellten Umleitungsdaten überprüft werden oder mit einer anderen Tabelle an Validierungscodes abgeglichen werden, welche aktuell sind. Wie dem auch sei, die relative Pünktlichkeit der Umleitungsanfrage kann durch das Alter des Validierungscodes bestimmt werden und dient somit als Basis, um zu bestimmen, ob die aktuelle Umleitungsanfrage zeitlich korrekt oder fehlerverdächtig ist. Darüber hinaus können zusätzliche Überprüfungen vorgenommen werden, die nachprüfen, ob die korrespondierende Netzseite tatsächlich kürzlich von dem Servercomputersystem 16 zu dem bestimmten anfragenden Clientcomputersystem 12 bedient worden ist, bezogen auf einen kurzen Zeitlog auf lokale Netzseiten, die tatsächlich von dem Servercomputersystem 16 bedient worden sind. Schließlich können Zugriffsgenehmigungen, die von dem Servercomputersystem 16 durchgeführt worden sind, mit der Identifizierung des Clientcomputersystems 12 überprüft werden, um kategorisch die Umleitung zu definierten Klassen an Clients zu vermindern. Wenn die Anfrage aus irgendeinem Grund für ungültig erklärt wird, wird eine geeignete Zugriffsverweigerung erzeugt und ausgegeben, 48.
Wenn eine Umleitungsanfrage als gültig festgestellt wird, können irgendwelche oder alle Daten, die als Teil der Umleitungsanfrage oder die von dem HTTPd-Server 30 durch einen konventionellen Vorgang des HTTP-Protokolls bereitgestellt wurden, durch das Netzwerkbetriebssystem 28 zu der Permanentspeichervorrichtung 32 für eine nachfolgende Bearbeitung, Analyse und Bericht protokolliert werden. Die Umleitungsanfrage wird dann weiter verarbeitet, um die zweite URL zu erhalten, was den Zielumleitungsserver 56 identifiziert. Diese zweite URL wird dann in dem Anzeigefeld einer Umleitungsnachricht spezifiziert, vorzugsweise eine temporäre Umleitungsnachricht, welche zu dem Clientcomputersystem 12 zurückgegeben wird, 58, welches zunächst die Umleitungs-URL ausstellt.
Das Verfahren 40 gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung wird im wesentlichen innerhalb des HTTPd-Servers 30 durchgeführt. Die Ausführung des Verfahrens 40 kann durch eine Modifikation und Ausweitung des Verfahrensflusses, der durch den HTTPd-Server 30 durchgeführt wird, durch eine korrespondierende Veränderung des Serverquellencodes ausgeführt werden. Diese Modifikationen und Zusätze können unter Verwendung von konventionellen Programmtechniken durchgeführt werden.
Die Umleitungsleistungsfähigkeit, die durch die vorliegende Erfindung bereitgestellt wird, ist vollständig mit existierenden de-facto Standardumleitungsleistungsfähigkeiten konsistent, die durch herkömmliche HTTPd-Server bereitgestellt werden. In 4 wird ein weiterer detaillierter Abschnitt 60 des Verfahrens 40 gezeigt. Innerhalb der Operation des HTTPd-Servers 30 werden die URL-Daten 62 empfangen und zunächst analysiert, 64, um das geeignete Vorliegen des Umleitungsschlüsselwortes zu identifizieren. Wenn die spezifische Form der Umleitungs-URL der vorliegenden Erfindung nicht identifiziert wird, 66, wird die URL auf konventionelle Weise weiter verarbeitet, um zu bestimmen, ob irgendeine andere Form der Umleitung anwendbar ist. Zusätzlich kann auch letztendlich eine Bewertung eines konventionellen Zugriffs, der für eine lokale Netzseite privilegiert ist, bei der keine konventionelle Umleitung spezifiziert ist, durchgeführt werden, wobei eine geeignete Antwortnachricht erstellt wird, 68.
In dem bestimmten Fall, bei dem die URL-Anfrage von spezieller Umleitungsform ist, die mit der vorliegenden Erfindung im Gegensatz zu konventionellen HTML-Umleitungsleistungsfähigkeiten konsistent ist, werden die URL-Daten verarbeitet, 70, und in Kombination mit den HTTP-Protokoll-bereitgestellten Daten, die von dem Clientcomputersystem 12 identifiziert werden, wird eine Datenbankaufzeichnung in der Permanentspeichervorrichtung 32 gebildet oder aktualisiert, 72. Die zweite URL wird dann extrahiert, 74, und eine Umleitungsnachricht, spezifischerweise vom Typ 302 temporäre Umleitungsnachricht, wird vorbereitet. Wie zuvor kann die zweite URL eine direkte oder buchstabengetreue URL sein oder eine indirekte Umleitungszielserveridentifizierung, welche durch den HTTPd-Server 30 in eine URL auflösbar ist, die wenigstens ausreichend ist, um den Zielumleitungsserver zu identifizieren. Da die zweite URL, die in eine Netzseite eingebettet ist, durch eine Voreinstellung mit der Operation des HTTPD-Servers 30 definiert wird, ist eine Auflösung von irgendeiner indirekten Umleitungszielserveridentifizierung vollständig durch den HTTPd-Server 30 durch beispielsweise einen Nachschlagvorgang in einer Datenbank möglich.
Eine Umleitungsnachricht, die ein Angabefeld umfasst, wird dann durch den HTTPd-Server 30 gebildet. Dieses Angabefeld wird mit dem direkten oder aufgelösten Zielumleitungsserver URL bereitgestellt. Die Umleitungsmeldung wird dann an das ursprüngliche Anfrageclientcomputersystem 12 geleitet, 58.
Andere funktionsfähige Serverseitenausführungsformen der Erfindung können andere spezifische Protokolle verwenden, um die Verfolgungsinformation von dem Clientsystem 12 zu dem HTTPd-Server 30 zu übertragen. Diese anderen HTTP-Protokollverfahren umfassen beispielsweise GET, FORMS, OPTIONS, HEAD, PUT, DELETE, AND TRACE. Die Verwendung von diesen anderen Protokollverfahren sind im allgemeinen ähnlich, wobei sie sich in ihren Anforderungen für die spezifische Browserunterstützung für die Protokollverfahren und Details ihrer spezifischen HTML-Auszeichnungscodierung in Netzseiten unterscheiden.
Als ein Beispiel der Verwendung von diesen anderen Protokollverfahren kann das HTTP GET Verfahren durch Einbetten der folgenden NTML-Codemarkierungen in den Netzseiten, die einem Clientcomputersystem dienen, ausgeführt werden.
</a> Dieser HTML-Code definiert "MTCH1073.gif" als die Netzseitenbannergrafik, www.infoseek.com als die direkt URL, „MTCH-2009-1073-GEN" als die Daten und „www.match.com" als den Zielumleitungsserver.
Wenn die obigen HTML-Markierungen zu dem Clientcomputersystem geleitet werden, wird eine anfängliche HTTP GET-Anfrage zu „www.online.com" durchgeführt, um die Bannergrafik zu erhalten. Als Antwort auf einen Bannerklick, wird eine zweite GET-Anfrage zu www.infoseek.com unter Verwendung der URL:
Der HTTPd-Server 30 nimmt die Werte der MIME-Information (als Cookies) und die Formvariablen (in diesem Fall ak und rd) auf. Es wird dann eine HTTP-Umleitungsnachricht durch den HTTPd-Server 30 erzeugt und zu dem Clientcomputersystem zurückgegeben. Eine dritte und letzte GET-Anfrage wird dann zu „www.match.com" in Antwort auf die Umleitungsnachricht durchgeführt.
Als ein anderes Beispiel kann ein HTTP-POST-Verfahren verwendet werden. Die in der Netzseite eingebetteten HTML-Markierungen können folgendermaßen kodiert werden:
Dieser HTML-Code wird zu einer GET-Anfrage führen, welche automatisch von „www.online.com" durchgeführt wird, um die Bannergrafik zurückzuziehen. Ein Bannerklick wird zu einer HTTP-POST-Anfrage führen, welche zu www.infoseek.com zusammen mit den FORM-, NAME- und VALUE-Daten gesendet wird. In diesem Fall werden die Daten nicht in die URL kodiert, sondern eher in den Hauptteil der POST-Anfrage selbst kodiert. In diesem Beispiel wird die Post-Anfrage die Form aufweisen:
Wenn die zurückgegebene Umleitungsnachricht empfangen wird, wird eine andere GET-Anordnung durch das Clientcomputersystem zu dem Umleitungszielserver angegeben, die wieder „www.match.com" ist.
Gemäß der vorliegenden Erfindung kann auch ein Clientseitenverfahren verwendet werden, um codeunabhängig die Bekanntgabe der Auswahl eines Netzseitenelements durch ein Clientcomputersystem bereitzustellen. 5 zeigt eine Darstellung 78 des Datentransferflusses, der sowohl das Serverseitenverfahren als auch das Clientseitenverfahren beinhaltet, das die vorliegende Erfindung durchführt, ein Clientcomputersystem 80 führt zusammen mit beiden Serverseiten- und Clientseitenverfahren eine anfängliche Netzseitenanfrage über das Internet (nicht gezeigt) zu einem Netzseitenserversystem 82 durch. Eine korrespondierende Netzseite 84, die ein Netzseitenelement 86 umfassst, wird zu dem Clientcomputersystem 80 zurückgegeben.
Es wird wiederum zusammen mit beiden Serverseiten- und Clientseitenverfahren der vorliegenden Erfindung das Netzseitenelement 86 durch das Einbetten von Information in der Netzseite 84 bereitgestellt. Im Falle eines Serverseitenverfahrens, wie es im allgemeinen in 6 dargestellt ist, führt das Verfahren der vorliegenden Erfindung gefolgt von einer Banneranklickung 96 zu einer Clientbrowseraktion. Insbesondere steuert die eingebetttete Information den Vorgang des Webbrowsers auf dem Clientcomputersystem, was ausreichend ist, um eine Benachrichtigungs-URL 98, die zu dem Umleitungszielserversystem geleitet wird, zu erlassen, 88, wie es in 5 gezeigt ist. Das Serververfahren 100, welches als Folge der Benachrichtigung des URL-Erhalts initiiert wird, erzeugt die Umleitungsnachricht, die zu dem Clientcomputersystem 80 zurückgegeben wird. In Verbindung mit der Erzeugung der Um leitungsnachricht zeichnet das Serversystem 88 auch die Daten, die als Teil der Benachrichtigung URL 98 erhalten worden sind, auf, und verarbeitet diese gegebenenfalls.
Unter Bezugnahme auf die Umleitungsnachricht erstellt das Clientcomputersystem 80 anschließend vorzugsweise eine HTTP-Anfrage 102, die auf die Information bezogen ist, die auf der Umleitungsmeldung basiert. Unter wiederholter Bezugnahme auf 5 wird die HTTP-Anfrage 102 über das Internet 14 zu einem anderen Netzseitenserversystem 90 bereitgestellt, der auf konventionelle Weise über das Liefern der Netzseite 92 zu dem Clientcomputersystem 80 als die Netzseite 104 reagiert, auf die anfänglich durch das Netzseitenelement 86 Bezug genommen wurde.
Das Verfahren der vorliegenden Erfindung, das ein Clientseitenverfahren verwendet, ist im allgemeinen in 7 gezeigt. Das Verfahren 106, zum Zwecke der Erläuterung, beginnt im allgemeinen in Antwort auf einen Bannerklick 108, um ein Clientverfahren 110 zu initiieren, das in Verbindung mit der Operation des Webbrowsers auf dem Clientcomputersystem 80 ausgeführt wird. In einer bevorzugten Ausführungsform der vorliegenden Erfindung wird das Clientverfahren 110 mit der Netzseite 84 zu dem Clientcomputersystem 80 bereitgestellt. Das Clientverfahren 110 wird in Antwort auf den Bannerclick aufgerufen und arbeitet, um zunächst eine Benachrichtigungs-URL-Nachricht 112 zu erlassen und um zweitens eine HTTP-Anfrage 114 zu erlassen. Beide Nachrichten werden über das Internet 14 und zu dem Zielserversystem 88 beziehungsweise zu dem Netzseitenserver 90 durchgeführt. Der Befehl, dass das Clientverfahren 110 die Benachrichtigung URL 112 und die HTTP-Anfrage 114 erstellt, ist nicht von Bedeutung. Ferner ist eine Bestätigung des Erhalts der Benachrichtigungs-URL von dem Zielserversystem 88 nicht erforderlich, bevor die HTTP-Anfrage 114 durchgeführt wird. In der Tat ist die einzige Reaktion, wie es dem Anwender des Clientcomputersystems 80 ersichtlich ist, die als signifikant erachtet wird, der Erhalt 116 der Netzseite 92.
Wie im Falle des Serverseitenverfahrens kann das Clientseitenverfahren auf eine Anzahl von verschiedenen Weisen zum Zwecke der vorliegenden Erfindung durchgeführt werden, wobei jede zu der Abgabe von Daten an das Zielserversystem 88 und an eine URL-Anfrage zu einen Netzseitenserversystem 90 führt, um eine Netzseite 92 mit einer voreingestellten Korrespondenz mit dem Netzseitenelement 86 bereitzustellen. Insbesondere kann das Clientseitenverfahren direkt in die Browseranwendung oder als ein Browser plug-in, der eine konventionelle Browseranwendung unterstützt, codiert werden. Das Clientseitenverfahren kann auch durch die Verwendung von Java und JavaScripttypapplets durchgeführt werden.
Ein beispielhaftes Clientseitenverfahren wird durch die Verwendung eines Java Applets durchgeführt. Der HTML-Code, der in die Netzseite 84 für dieses Beispiel eingebettet ist, ist wie nachfolgend:
wobei die drei Appletparameter wie folgt definiert sind:
„img"- die URL-Verweisung zu einer grafischen Bannerwerbeanzeige
„notifyURL"- die „Benachrichtigungs"-URL, die die Abrechnungsdaten beinhaltet
„pageURL"- die „Umleitungs"-URL für die Verwendung.
Der Appletsource lautet wie nachfolgend:
Die obigen Beispiele verwenden zwei HTTP-Anfragen, um zunächst die „notifyURL"-Nachricht und dann die „pageURL"-Nachricht zu erzeugen. Es können jedoch im Zusammenhang mit der Erfindung verschiedene andere Protokolle verwendet werden. Beispielsweise kann das Java-Applet verändert werden, um die Benachrichtigungsdaten an das Zielserversystem 88 durch die Verwendung einer TCP-Verbindung bereitzustellen. Eine beispielhafte Durchführung eines Applets unter Verwendung einer TCP-Verbindung wird unten bereitgestellt. Das Applet verwendet vier Parameter:
„img"- die URL-Verweisung zu einer grafischen Bannerwerbeanzeige
„port"- die TCP-Anschlussnummer für die Verwendung auf dem Zielserver
„data"- die Abrechnungsdaten zur Sendung an den Zielserver
„pageURL"- die „Umleitungs"-URL für die Verwendung.
Der Appletsource ist wie nachfolgend:
import java.applet.Applet;
Schließlich kann auf das obige Applet für die Ausführung zum Einbetten des folgenden HTML-Codes in die Netzseite 84 verwiesen werden.
Somit wurde ein umfangreiches System und ein Verfahren zum Abrechnen oder Auditieren von Zugängen durch Clientcomputersysteme zu externen Hyperlinkservern beschrieben. Die Auditierungsleistungsfähigkeit von diesem Systemverfahren stellt einen optimalen minimalen Mehraufwand auf das Umleitungsserversystem bereit, während es ermöglicht wird, dass Daten, welche zur Bewertung gesammelt werden und vernünftig gesichert werden, um bone fide-Zugängen zu einem Umleitungszielserversystem zu entsprechen.
Während die Erfindung insbesondere unter Bezugnahme auf die bevorzugten Ausführungsformen gezeigt und beschrieben worden ist, ist dem Fachmann klar, dass zahlreiche Abwandlungen in der Form und in den Details vorgenommen werden können, ohne von dem Umfang der Erfindung abzuweichen.

Claims

Verfahren der Bereitstellung einer Nachricht an ein Verfolgungsserversystem in Antwort auf eine Verweisung eines Clientsystems auf eine vorbestimmte Quellenangabe, die einer Quelle außerhalb des Serversystems entspricht, wobei das Verfahren folgende Schritte aufweist: a) Bereitstellen eines Informationselementes für das Clientsystem, welches von dem Clientsystem auswählbar ist, wobei das Informationselement an dem Clientsystem grafisch identifizierbar ist mit einem Informationsinhalt, der von einem ersten Serversystem unter Verwendung einer ersten Quellenangabe beziehbar ist und wobei das Informationselement eine auf ein zweites Serversystem verweisende Quellenangabe beinhaltet und das Informationselement identifizierende Daten; b) Vorsehen, dass das Clientsystem die zweite Quellenangabe zur Bereitstellung der Daten an das zweite Serversystem benutzt in Antwort auf die Auswahl des Informationselements; und c) Vorsehen, dass das Clientsystem die erste Quellenangabe zur Gewinnung des Informationsinhalts von dem ersten Serversystem in Antwort auf die Auswahl des Informationselements benutzt.
Verfahren nach Anspruch 1, wobei das Clientsystem in Antwort auf die Auswahl des Informationselements autonom fortfährt, die erste Quellenangabe zu benutzen, um den Informationsinhalt von dem ersten Serversystem zu beziehen und die zweite Quellenangabe zu benutzen, um dem zweiten Serversystem die Daten zur Verfügung zu stellen.
Verfahren nach Anspruch 2, weiterhin umfassend den Schritt der Versorgung des Clientsystems mit der ersten Quellenangabe in Antwort auf den Empfang der Daten.
Verfahren nach Anspruch 2, weiterhin umfassend den Schritt der Versorgung des Clientsystems mit einem Steuerprogramm, welches für die Ausführung eines Clientprozesses sorgt in Antwort auf die Auswahl des Informationselements durch das Clientsystem.
Verfahren nach Anspruch 3 oder 4, wobei die Daten zur Identifizierung des Informationselements ausreichende Abrechnungsdaten beinhalten.
Verfahren der Verfolgung des Auftretens von Netzseiten-Banner-Anklickverweisungen durch Benutzer von Clientcomputersystemen auf zugehörige Netzseiten, auf denen dieses Auftreten von einem Verfolgungscomputersystem transparent unter Bezug auf die Clientcomputer-Systembenutzer verfolgt werden, wobei das Verfahren folgende Schritte umfasst: a) Ermöglichen, dass ein Netzseitenelement einem vorbestimmten Clientcomputersystem zur Verfügung gestellt wird derart, dass das Netzseitenelement durch den Benutzer des vorbestimmten Clientcomputersystems auswählbar ist und derart, dass das Netzseitenelement mit einem Computersystem eines Inhaltanbieters identifiziert wird; und b) Vorsehen, dass eine vorbestimmte Verfolgungsinformation dem vorbestimmten Clientcomputersystem mit dem Webseitenelement zur Verfügung gestellt wird, um von dem Clientcomputersystem in Relation zu dem Webseitenelement aufrechterhalten zu werden derart, dass in Antwort auf die Auswahl des Webseitenelements durch den Benutzer des vorbestimmten Clientcomputersystems die vorbestimmte Verfolgungsinformation automatisch von dem Clientcomputersystem zur Versorgung des Verfolgungscomputersystems mit Verfolgungsdaten und des Computersystems des Inhaltanbieters mit einer Inhaltanfrage benutzt wird.
Verfahren nach Anspruch 6, wobei das Webseitenelement einen für den Benutzer des vorbestimmten Clientcomputersystems beziehbaren Inhalt identifiziert und wobei die Inhaltanfrage von dem vorbestimmten Clientcomputersystem mit der vorbestimmten Verfolgungsinformation aufrechterhalten wird.
Verfahren nach Anspruch 7, wobei die Auswahl des Netzseitenelements auf der Clientseite für den Start eines Prozesses sorgt, der die vorbestimmte Verfol gungsinformation an das Verfolgungscomputersystem und die Inhaltanfrage an das Computersystem des Inhaltanbieters überträgt.
Verfahren nach Anspruch 8, wobei das Verfolgungscomputersystem die vorbestimmte Verfolgungsinformation verarbeitet zur Bereitstellung einer Identifikation des Computersystems des Inhaltanbieters an das vorbestimmte Clientcomputersystem und wobei das vorbestimmte Clientcomputersystem die Identifikation benutzt zur Versorgung des Computersystems des Inhaltanbieters mit der Inhaltanfrage.
Verfahren nach Anspruch 8, wobei der Prozess auf der Clientseite für die autonome Übertragung der vorbestimmten Verfolgungsinformation an das Verfolgungscomputersystem und die Inhaltanfrage an das Computersystem des Inhaltanbieters sorgt, wobei die Inhaltanfrage eine Identifikation des Computersystems des Inhaltanbieters beinhaltet, die ausreichend ist zur Versorgung des Computersystems des Inhaltanbieters mit der Inhaltanfrage.
Verfahren nach Anspruch 10, wobei das vorbestimmte Clientcomputersystem eine Browseranwendung ausführt zum Empfangen und Verarbeiten des Netzseitenelements und wobei der Prozess auf der Clientseite ausgeführt wird durch die Ausführung eines Steuerskripts durch die Browseranwendung.
Verfahren nach Anspruch 10, wobei das vorbestimmte Clientcomputersystem eine Browseranwendung ausführt zum Empfangen und Verarbeiten des Netzseitenelements und wobei der Prozess auf der Clientseite ausgeführt wird durch die Ausführung eines in die Browseranwendung eingekoppelten Zusatzmodul-Steuerprogramms.
Verfahren nach Anspruch 10, wobei das vorbestimmte Clientcomputersystem eine Browserapplikation ausführt zum Empfangen und Verarbeiten des Netzseitenelements und wobei der Prozess auf der Clientseite ausgeführt wird durch ein Anwendungsprogramm, welches von dem vorbestimmten Clientcomputersystem unter der Steuerung der Browseranwendung ausgeführt wird.
Verfahren der Verfolgung der Auswahl von Werbebannern durch Anklicken, die auf den Webseiten bereitstehen, die den Clientcomputersystemen von dem Netzseiten-Server-Computersystemen zur Verfügung gestellt werden, wobei das Verfahren folgende Schritte umfasst: a) Bereitstellen einer Netzseite mit einem vorbestimmten Netzelement zur Übertragung in eine Browseranwendung, die von einem Clientcomputersystem ausgeführt wird, wobei die Netzseite vorbestimmte codierte Abrechnungsdaten umfasst und eine Identifikation eines Netzseiten-Server-Computersystems, die von dem Clientcomputersystem in Verbindung mit dem vorbestimmten Seitenelement gespeichert wird; b) Vorsehen der Ausführung eines Prozesses auf der Clientseite in Verbindung mit der Browseranwendung nach der Auswahl des vorbestimmten Seitenelements durch einen Benutzer des Clientcomputersystems, wobei der Prozess auf der Clientseite für eine Übertragung der codierten Abrechnungsdaten an ein Rechnungsprüfungs-Computersystem sorgt und die Ausgabe einer vorbestimmten Netzseitenanfrage an das Netzseiten-Serversystem in Übereinstimmung mit der Identifikation.