DE69728182T2

DE69728182T2 - Verfahren und gerät zum entfernten netzwerkzugriffseintrag und netzwerkzugriffsbericht

Info

Publication number: DE69728182T2
Application number: DE69728182T
Authority: DE
Inventors: B. David ANDERSEN
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 1996-12-19
Filing date: 1997-12-01
Publication date: 2004-10-14
Anticipated expiration: 2017-12-02
Also published as: DE69728182D1; AU5605698A; EP1008087B1; US6122740A; EP1008087A4; WO1998027502A1; EP1008087A1

Description

STAND DER TECHNIK
Gebiet der Erfindung
Die vorliegende Erfindung betrifft das Gebiet der Netzwerke. Im Besonderen betrifft die vorliegende Erfindung die Fernprotokollierung der Zugriffe in einem Netzwerk.
Beschreibung des Stands der Technik
Im Zuge der Weiterentwicklung der Computertechnologie hat der Einsatz von Netzwerken stetig zugenommen. Ein Netzwerk ist ein System, das zwei oder mehr Computersysteme miteinander verbunden kann, so dass die Systeme miteinander kommunizieren können. Ein in Verbindung mit der Nutzung von Netzwerken auftretendes Problem ist es, dass Netzwerke Einzelpersonen den Zugriff auf Systeme ermöglichen, die eigentlich nicht für den Zugriff auf die Netzwerke vorgesehen sind. Zum Beispiel können Kinder auf Systeme zugreifen, die nur für Erwachsene gedacht sind, oder Mitarbeiter bzw. Angestellte können auf Systeme zugreifen, die nicht mit dem Arbeitsverhältnis bzw. mit dem Tätigkeitsbereich verbunden sind.
Eine Lösung für das Problem des Zugriffs durch Einzelpersonen auf Systeme, die eigentlich nicht für den Zugriff vorgesehen sind, ist es an einem System einer Einzelperson eine Liste unzulässiger Computersysteme vorzusehen und es zu verhindern, dass die Einzelperson auf eines der unzulässigen Probleme zugreift. Eine andere Lösung ist es auf einem System einer Einzelperson einen Verlauf der Systeme zu speichern, auf welche die Einzelperson zugegriffen hat, und wobei eine Überwachungsperson periodisch den Verlaufsdatensatz überprüft, um den Zugriff auf unzulässige Systeme zu identifizieren.
Bei diesen beiden Lösungen besteht jedoch dass Problem, dass der Benutzer und im Besonderen ein erfahrener, gut ausgebildeter Computeranwender auf die entsprechenden Listen bzw. Verlaufslisten oder Datensätze auf seinem eigenen System zugreifen und diese nach eigenem Belieben modifizieren kann. Somit wäre es von Vorteil, ein Protokoll der Zugriffe auf unzulässige Systeme zu verwalten sowie möglichst eine Möglichkeit vorzusehen, um den Zugriff auf derartige Systeme zu verhindern, so dass ein Systembenutzer darauf keinerlei Zugriff hat.
Wie dies nachstehend im Text näher beschrieben ist, sieht die vorliegende Erfindung ein Verfahren und eine Vorrichtung für die Fernprotokollierung von Netzwerkzugriffen und zu deren Meldung vorzusehen, wobei diese und andere wünschenswerte Ergebnisse erreicht werden, die für den Fachmann auf dem Gebiet aus der folgenden Beschreibung deutlich werden.
ZUSAMMENFASSUNG DER ERFINDUNG
Vorgesehen sind gemäß der vorliegenden Erfindung ein Verfahren und eine Vorrichtung für eine Fernprotokollierung von Netzwerkzugriffen sowie deren Aufzeichnung gemäß den Definitionen in den entsprechenden gegenständlichen Ansprüchen 1 und 14. Gemäß der vorliegenden Erfindung wird eine Zugriffsanforderung an einem Client-System in einem Netzwerk abgefangen und Protokolldaten, welche die Zugriffsanforderung identifizieren, werden zu einem Protokollserver in dem Netzwerk übermittelt.
Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung empfängt das Client-System eine Zugriffsliste von dem Protokollserver und vergleicht die Zugriffsanforderung mit der Zugriffsliste. In dem vorliegenden Ausführungsbeispiel ist der Zugriff auf das Host-System nur dann zulässig, wenn die Anforderung in keinem Konflikt mit der Zugriffsliste steht. Gemäß einem weiteren Ausführungsbeispiel der vorliegenden. Erfindung empfängt das Client-System eine Zugriffsliste von dem Protokollserver und vergleicht die Zugriffsanforderung mit der Zugriffsliste. In dem vorliegenden Ausführungsbeispiel werden die Protokolldaten nur dann zu dem Protokollserver gesendet bzw. übermittelt, wenn die Anforderung einen Konflikt mit der Zugriffsliste aufweist.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die vorliegende Erfindung ist in den Abbildungen der beigefügten Zeichnungen beispielhaft und ohne einzuschränken veranschaulicht, wobei übereinstimmende Elemente in den Zeichnungen mit den gleichen Bezugszeichen bezeichnet sind. Es zeigen:
1 ein Blockdiagramm einer Netzwerkumgebung, in der die vorliegende Erfindung ausgeführt werden kann;
2 ein vereinfachtes Blockdiagramm einer Systemarchitektur, wie diese in einem Ausführungsbeispiel der vorliegenden Erfindung verwendet werden kann;
3 ein Flussdiagramm der Schritte zur Protokollierung von Netzwerkzugriffen gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
4 ein Flussdiagramm der Schritte zur Protokollierung von Netzwerkzugriffen gemäß einem alternativen Ausführungsbeispiel der vorliegenden Erfindung;
5 ein funktionales Blockdiagramm eines Protokollservers gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
6 ein Flussdiagramm der Schritte zum Aufzeichnen von Daten an einem Protokollserver gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
7 ein Flussdiagramm der Schritte für eine Meldung der Protokolldaten gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
8 eine Anzeige der Protokolldaten, die gemäß einem Ausführungsbeispiel der vorliegenden Erfindung angezeigt werden kann; und
9 ein Ausführungsbeispiel eines zur Verwendung in Verbindung mit der vorliegenden Erfindung geeigneten Hardwaresystems.
GENAUE BESCHREIBUNG
In der folgenden Beschreibung werden verschiedene Aspekte der vorliegenden Erfindung beschrieben. Der Fachmann auf dem Gebiet erkennt jedoch, dass die vorliegende Erfindung auch mit nur einigen sowie mit allen Aspekten der vorliegenden Erfindung ausgeführt werden kann. Die ausgeführten spezifischen Ziffern bzw. Nummern, Materialien und Konfigurationen dienen einem umfassenden Verständnis der vorliegenden Erfindung. Für den Fachmann auf dem Gebiet ist es ferner offensichtlich, dass die vorliegende Erfindung auch ohne diese spezifischen Details ausgeführt werden kann.
Bestimmte Abschnitte der folgenden genauen Beschreibung sind als Algorithmen und symbolische Darstellungen der Abläufe bzw. Operationen an Datenbits in einem Computerspeicher ausgeführt. Diese algorithmischen Beschreibungen und Darstellungen sind as von Fachleuten auf Gebiet der Datenverarbeitung verwendete Mittel, um den Kern ihrer Arbeiten anderen Fachleuten am wirksamsten zu vermitteln. Ein Algorithmus wird hierin allgemein als eine in sich widerspruchsfreie Folge von Schritten betrachtet, die zu einem gewünschten Ergebnis führen. Die Schritte verlangen physikalische Manipulationen physikalischer Größen. Für gewöhnlich, jedoch nicht unbedingt, sind diese Größen in Form von elektrischen oder magnetischen Signalen gegeben, die gespeichert, übertragen, kombiniert bzw. verknüpft, vergleichen und anderweitig manipuliert werden können. Es hat sich zeitweilig, hauptsächlich begründet durch die übliche Nutzung, als praktisch erwiesen, diese Signale als Bits, Werte, Elemente, Symbole, Zeichen, Begriffe, Ziffern oder dergleichen zu bezeichnen. Hiermit wird jedoch festgestellt, dass all diese und ähnliche Begriffe den entsprechenden physikalischen Größen zugeordnet werden müssen und lediglich praktische Bezeichnungen dieser Größen darstellen. Sofern in der folgenden Beschreibung keine anderweitigen Ausführungen vorgesehen sind, wird hiermit festgestellt, dass in der gesamten vorliegenden Erfindung Beschreibungen unter Verwendung der Begriffe wie "Verarbeiten" oder "Berechnen" oder "Errechnen" oder "Bestimmen" oder "Anzeigen" und dergleichen die Maßnahmen und Prozesse eines Computersystems oder einer ähnlichen elektronischen echenvorrichtung betreffen, welche Daten manipuliert und transformiert, die als physikalische (elektronische) Größen in den Registern und Speichern eines Computersystems dargestellt sind, und zwar zu bzw. in andere Daten, die ebenso als physikalische Größen in den Speichern oder Registern des Computersystems oder anderer derartiger Speicher-, Übertragungs- oder Anzeigevorrichtungen dargestellt sind.
Vorgesehen sind gemäß der vorliegenden Erfindung ein Verfahren und eine Vorrichtung zur Fernprotokollierung und -meldung von Netzwerkzugriffen. Wenn ein Benutzer auf ein Netzwerksystem zugreift, werden Protokolldaten über die Anforderung an ein entferntes System übertragen und in diesem gespeichert. Die gespeicherten Daten werden danach einer befugten Einzelperson zur Überprüfung zur Verfügung gestellt, welche Daten über die Netzwerkzugriffe des Benutzers empfangen kann.
Die Abbildung aus 1 zeigt ein Blockdiagramm einer Netzwerkumgebung, in der die vorliegende Erfindung ausgeführt werden kann. Gemäß der Abbildung weist die Netzwerkumgebung 100 eine Mehrzahl (N) von Client-Systemen 110 und eine Mehrzahl (M) von Host-Systemen 120 auf, die gemeinsam als Netzwerksysteme bezeichnet werden. Die Netzwerkumgebung 100 weist ferner eine Mehrzahl (X) von Internet-Serviceprovidern (ISPs) 130, das Internet 140 und einen Protokollserver 150 auf. Bei jedem Client-System 110 kann es sich um eine Vorrichtung eines umfassenden Bereichs von Rechenvorrichtungen handeln, die einem Benutzer bzw. einem Anwender einen Zugriff auf das Internet 140 ermöglichen.
Bei jedem ISP 130 handelt es sich für gewöhnlich um ein Computersystem mit einer großen Speicherkapazität (für gewöhnlich im Bereich von Hunderten von Gigabyte oder Terabyte) und einer Mehrzahl von Kommunikationsleitungen für den Zugriff sowohl auf Client-Systeme 110 als auch auf das Internet 140.
Jedes Host-System 120 ist ferner für gewöhnlich ein Computersystem, auf das durch die Client-Systeme 110 zugegriffen werden kann. Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung weist jedes Host-System 120 eine oder mehr Webseiten auf, die mit HyperText Markup Language (HTML) kompatibel sind und auf die über das HyperText Transfer Protocol (HTTP) zugegriffen werden kann und die durch einen HTML-kompatiblen Internetbrowser angezeigt werden können, der auf einem Client-System 110 ausgeführt wird. In dem vorliegenden Ausführungsbeispiel kann ein einzelner Anwender auf das Host-System 120 zugreifen, indem er in dem System eine Kennung einer Webseite eingibt, die als Uniform Resource Locator (URL) bezeichnet wird. Darüber hinaus kann jedes Host-System 120 ferner eine oder mehrere Datendateien aufweisen, auf welche die Client-Systeme 110 zugreifen können. Auf diese Datendatei(en) kann über HTTP oder alternativ auch andere Protokolle wie etwa das File Transfer Protocol (FTP) zugegriffen werden.
Jedes der Host-Systeme 120 weist für gewöhnlich Informationen zur "Seitenbeschreibung" auf. Die Seitenbeschreibungsinformationen für ein Host-System 120 sind eine kurze Beschreibung, welche die von dem Host-System verfügbaren Informationen identifiziert. Beispiele für die Seitenbeschreibungsinformationen sind unter anderem Schlüsselwortlisten bzw. Kennwortlisten und Zusammenfassungen. In einem Ausführungsbeispiel kann jedes Host-System 120 mehrere HTML-fähige Webseiten aufweisen, und wobei jede Webseite eigene Seitenbeschreibungsinformationen aufweisen kann.
Bei dem Protokollserver 150 handelt es sich ebenfalls für gewöhnlich um ein Computersystem mit einer großen Speicherkapazität zum Speichern von Protokolldaten gemäß der vorliegenden Erfindung. Die Protokolldaten werden von einem oder mehreren Client-Systemen 110 zu dem Protokollserver 150 übertragen und durch den Protokollserver 150 gespeichert, bis die Informationen von einem verifizierten Benutzer angefordert werden, wie dies nachstehend im Text näher beschrieben ist. Hiermit wird festgestellt, dass in der Abbildung aus 1 zwar nur ein Protokollserver 150 veranschaulicht ist, wobei jedoch jede beliebige Anzahl von Servern 150 mit dem Internet 140 gekoppelt werden kann.
Das Internet 140 ist eine Kombination aus einer Mehrzahl herkömmlicher Hardwarekomponenten, mit Computersystemen, Routern, Verstärkern, Gateways und Datenübermittlungsabschnitten, die über die ganze Welt verteilt angeordnet sind. Diese Hardwarekomponenten können hierarchisch organisiert werden, um mehrere Logikebenen für Netzwerke zu ermöglichen. Die Hardwarekomponenten des Internet 140 arbeiten so zusammen, dass sie Daten von einem Computersystem zu einem anderen leiten. Gemäß einer Implementierung werden Daten zwischen Computersystemen unter Verwendung des allgemein bekannten Transmission Control Protocol/Internet Protocol (TCP/IP) übertragen. Diese Daten werden für gewöhnlich in Einheiten übertragen, die als "Pakete" oder "Datengramme" bezeichnet werden. Kennzeichnenderweise enthält jedes Paket Daten, eine Ursprungsadresse, welche das System identifiziert, das das Paket initiiert hat, sowie eine Zieladresse, die das System identifiziert, an welche das Paket gesendet wird. Zusätzliche Steuerinformationen, wie etwa eine Prüfsumme, können ebenfalls in dem Paket vorgesehen sein. Die Anzahl der in einem Paket enthaltenen Datenbytes ist von dem verwendeten Netzwerkprotokoll abhängig.
Bei den in der Abbildung aus 1 veranschaulichten Datenübermittlungsabschnitten kann es sich um jedes einer umfassenden Vielzahl herkömmlicher Kommunikationsmedien handeln, und wobei sich die Medien für die verschiedenen Systeme 110, Host-Systeme 120, ISPs 130 und Protokollserver 150 unterscheiden können. Bei einem Datenübermittlungsabschnitt kann es sich zum Beispiel um ein Kabel, ein Lichtwellenleiterkabel oder um ein nichtphysikalisches Medium handeln, das elektromagnetische Signale in dem elektromagnetischen Spektrum übermittelt. Darüber hinaus kann ein Datenübermittlungsabschnitt ferner auch jede beliebige Anzahl herkömmlicher Routing- oder Verstärkervorrichtungen aufweisen, wie etwa Satelliten oder elektromagnetische Signalverstärker.
Hiermit wird festgestellt, dass die Client-Systeme 110 und die Host-Systeme 120 zwar als verschiedene Vorrichtungen bzw. Maschinen veranschaulicht sind, kann ein einziges Hardwaresystem auch sowohl ein Client-System als auch ein Host-System darstellen. Wenn das Hardwaresystem einen Zugriff für Informationen auf ein anderes System einleitet, so wird das Hardwaresystem als Client-System bezeichnet. Wenn jedoch durch ein anderes System auf das Hardwaresystem zugegriffen wird, um Informationen von dem Hardwaresystem zu erhaltne, so wird das Hardwaresystem als Host-System bezeichnet.
Hiermit wird festgestellt, dass die Netzwerkumgebung 100 ferner zusätzliche Netzwerke aufweisen kann. Zum Beispiel können mehrere Client-Systeme 110 in einem Ethernet Netzwerk, einem Token Ring Netzwerk oder einem anderen konventionellen Netzwerk gekoppelt werden und über das zusätzliche Netzwerk auf einen ISP 130 zugreifen.
Die Abbildung aus 2 zeigt ein vereinfachtes Blockdiagramm, das eine Systemarchitektur veranschaulicht, die gemäß einem Ausführungsbeispiel der vorliegenden Erfindung verwendet werden kann. Gemäß der Abbildung umfasst die Systemarchitektur einen Netzwerk-Browser 210, eine Windows Sockets-Schnittstelle 220, eine protokollierende dynamische Linkbibliothek bzw. Laufzeitbibliothek (DLL) 230, eine Zugriffsliste 235 und einen TCP/IP-Stapel 240. Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung sind die Elemente aus 2 in einem oder mehreren Client-Systemen 110 aus 1 vorgesehen.
Der Netzwerk-Browser 210 sieht eine Benutzerschnittstelle vor, wie zum Beispiel eine grafische Benutzeroberfläche (GUI), die es einer Einzelperson ermöglicht, Informationen an ein anderes Netzwerksystem zu senden sowie Informationen von einem anderen Netzwerksystem zu empfangen. Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung handelt es sich bei dem Netzwerk-Browser 210 um einen HTML-fähigen Internetbrowser wie etwa Navigator^TM, der von Netscape Communications, Mountain View, Kalifornien, USA, erhältlich ist. Hiermit wird jedoch festgestellt, dass es sich bei dem Browser 210 um jede einer Vielzahl von Schnittstellen handeln kann, die es einem Einzelanwender ermöglichen, auf andere Netzwerksysteme zuzugreifen.
Bei der Windows Sockets-Schnittstelle 220 handelt es sich gemäß einem Ausführungsbeispiel um eine Windows Socket 2 Schnittstelle gemäß der Definition in der Windows Sockets 2 Service Provider Interface Specification, Revision 2.2.0, vom 10. Mai 1996, der Windows Sockets 2 Application Programming Interface, Revision 2.2.0, vom 10. Mai 1996 und dem Windows Sockets 2 Protocol-Specific Annex, Revision 2.0.3, vom 10. Mai 1996. Alternativ kann es sich bei der Windows Sockets-Schnittstelle um eine Windows Sockets 1.1 Schnittstelle handeln, gemäß der Definition in der Windows Sockets Interface Specification, Version 1.1, vom 20. Januar 1993.
Die WinSock-Schnittstelle 222 sieht eine Application Programming Interface (engl. abgekürzt API, d. h. Programmierschnittstelle) vor, die dem Netzwerk-Browser 210 die Kommunikation mit der Windows Sockets-Schnittstelle 220 ermöglicht. Die Service-Provider Interface (SPI) 226 sieht eine Schnittstelle vor, die es dem Serviceprovider (zum Beispiel der protokollierenden DLL 230 oder dem TCP/IP-Stapel 240) ermöglicht, mit der Windows Sockets-Schnittstelle 220 zu kommunizieren. Die WinSock DLL 224 übersetzt über die Schnittstelle 226 empfangene Informationen in das vom Browser 210 erwartete Format und übersetzt in ähnlicher Weise über eine Schnittstelle 222 empfangene Informationen in das Format, das von den Objekten bzw. Entititäten erwartet wird, die die Winsock Service-Provider Interface unterstützten, wie etwa die protokollierende DLL 230 und der TCP/IP-Stapel 240.
Nach der Installation ruft die protokollierende DLL 230 die Funktion WSCInstallProvider der Windows Sockets-Schnittstelle 220 auf, wobei die protokollierende DLL 230 als Standardziel für Nachrichten von der Schnittstelle 226 der Windows Sockets-Schnittstelle 220 identifiziert wird. Somit sieht die Windows Sockets-Schnittstelle 220 Daten von dem Netzwerk-Browser 210 an die protokollierende DLL 230 anstatt direkt an den TCP/IP-Stapel 240 vor. Im Betrieb empfängt die protokollierende DL 230 Anforderungen von der Windows Sockets-Schnittstelle 220. Die von der Windows Sockets-Schnittstelle 220 empfangene Anforderung kann an den TCP/IP-Stapel 240 weitergeleitet werden, wie dies nachstehend im Text näher beschrieben ist.
Zusätzlich kann der Bezeichner des Host-Systems, auf das zugegriffen wird, wie zum Beispiel der URL des Host-Systems, auf das zugegriffen wird, aus der Anforderung extrahiert und mit in die Protokolldaten eingeschlossen werden, die an den Protokollserver 150 aus 1 weitergeleitet werden, wie dies nachstehend im Text in näheren Einzelheiten beschrieben ist. Zusätzliche Protokolldaten können ebenfalls durch die protokollierende DLL 230 eingeschlossen werden, wie etwa das Datum des Zugriffs, die Uhrzeit des Zugriffs, die seit dem letzten Zugriff auf das Host-System abgelaufene Zeit, etc. Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung kann die protokollierende DLL 230 ferner Seitenbeschreibungsinformationen als Teil der Protokolldaten vorsehen. Zum Beispiel kann der Browser 210 eine Liste von Schlüsselwörtern bzw. Kennwörtern oder Zusammenfassungen bestimmter Seiten verwalten, auf die der Einzelanwender zugreift. Wenn die Liste verwaltet wird, so werden die Schlüsselwörter oder Zusammenfassungen des Host-Systems, auf das zugegriffen wird, als Teil der Protokolldaten eingeschlossen.
Zusätzlich ist die protokollierende DLL 230 mit einer temporären Zugriffsliste 235 gekoppelt. Die temporäre Zugriffsliste 235 ist eine Liste von Host-Systemen, auf die durch den Benutzer des Systems nicht zugegriffen werden darf. Alternativ kann es sich bei der Zugriffsliste 235 um eine Liste nur der Systeme handeln, auf welche der Benutzer zugreifen kann. In dem veranschaulichten Ausführungsbeispiel wird die Zugriffsliste 235 von dem Protokollserver 150 erhalten und in einem flüchtigen Speicher gespeichert, wie etwa in dem Direktzugriffsspeicher (RAM) des Systems. Die Verwendung der Zugriffsliste 235 durch die protokollierende DLL 230 ist nachstehend im Text in näheren Einzelheiten beschrieben. Hiermit wird festgestellt, dass die Daten in der temporären Zugriffsliste 235 auch auf eine Vielzahl von herkömmlichen Möglichkeiten verschlüsselt und durch die protokollierende DLL 230 entschlüsselt werden können, wenn ein Zugriff erfolgt.
Der TCP/IP-Stapel 240 unterstützt die WinSock Service-Provider Interface 226 und kann somit sowohl mit der Windows Socket-Schnittstelle 220 als auch mit der protokollierenden DLL 230 wie auch mit dem Internet kommunizieren. Anforderungen für einen Zugriff auf Netzwerksysteme sowie Pakete von Protokolldaten, die für den Protokollserver 150 bestimmt sind, werden von dem TCP/IP-Stapel 240 empfangen und als Eingabe/Ausgabe 250 an den Zielort weitergeleitet. Zusätzlich werden von externen Quellen empfangene Datenpakete ans Eingabe/Ausgabe 250 empfangen und durch den TCP/IP-Stapel 240 an die Windows Socket-Schnittstelle 220 weitergeleitet.
Hiermit wird festgestellt, dass die vorliegende Erfindung zwar in Bezug auf die Windows Socket-Schnittstelle und konform mit dem TCP/IP-Protokoll beschrieben ist, wobei die vorliegende Erfindung jedoch in Verbindung mit jedem Protokoll eines umfassenden Bereichs konventioneller Netzwerkprotokolle verwendet werden kann.
Hiermit wird ferner festgestellt, dass die protokollierende DLL 230 in der Abbildung aus 2 zwar als zwischen der Windows Sockets-Schnittstelle 220 und dem TCP/IP-Stapel 240 implementiert veranschaulicht ist, wobei die vorliegende Erfindung jedoch auf jede der vielfältigen konventionellen Art und Weisen implementiert werden kann. Die vorliegende Erfindung kann zum Beispiel als eine Reihe von Softwareroutinen implementiert werden, die in dem Netzwerk-Browser 210 ausgeführt werden.
Die Abbildung aus 3 zeigt ein Flussdiagramm, welches die Schritte veranschaulicht, die bei der Protokollierung von Netzwerkzugriffen gemäß einem Ausführungsbeispiel der vorliegenden Erfindung ausgeführt werden. Zu Beginn ruft die protokollierende DLL, die auf einem Client-System ausgeführt wird, eine Zugriffsliste von einem protokollierenden Server ab und speichert die Zugriffsliste lokal auf dem Client-System in dem Schritt 305. In dem veranschaulichten Ausführungsbeispiel wird der Zugriff durchgeführt, wenn die protokollierende DLL mit der Ausführung beginnt. Hiermit wird jedoch festgestellt, dass dieser Abruf zu verschiedenen Zeitpunkten durchgeführt werden kann, wie etwa in periodischen Zeiträumen nachdem die protokollierende DLL mit der Ausführung begonnen hat.
Sobald die Zugriffsliste abgerufen worden ist, ist die protokollierende DLL in der Lage, Anforderungen von einem Benutzer bzw. Anwender zu empfangen (über den Netzwerk-Browser). Die protokollierende DLL empfängt in dem Schritt 310 eine Anforderung für einen Zugriff auf ein Host-System und vergleicht in dem Schritt 315 das Host-System mit der lokal gespeicherten Zugriffsliste. Die protokollierende DLL überprüft danach in dem Schritt 320, ob die Anforderung einen Konflikt mit der Zugriffsliste aufweist. Wenn die Anforderung keinen Konflikt mit der Zugriffsliste aufweist, leitet die protokollierende DLL die Anforderung in dem Schritt 330 an das Host-System weiter (über den in der Abbildung aus 2 dargestellten TCP/IP-Stapel 240). Wenn die Anforderung jedoch einen Konflikt mit der Zugriffsliste aufweist, so übermittelt die protokollierende DLL Protokolldaten für die Anforderung in dem Schritt 325 an den protokollierenden Server, und in dem Schritt 330 wird die Anforderung an das Host-System übermittelt. Wie dies bereits vorstehend im Text beschrieben worden ist, können diese Protokolldaten alle Daten eines umfassenden Bereichs von Daten aufweisen, einschließlich der Identifikation des angeforderten Host-Systems, dem Datum und der Uhrzeit der Anforderung, etc.
Hiermit wird festgestellt, dass ein in dem Schritt 320 geprüfter Konflikt durch eine Vielzahl von verschiedenen konventionellen Methoden identifiziert werden kann. Gemäß einer Implementierung weist die Zugriffsliste eine Liste von Netzwerkbezeichnern auf, auf die der Benutzer des Systems nicht zugreifen darf. Ein in dem Schritt 310 empfangener Bezeichner, der sich in dieser Liste befindet, weist einen Konflikt mit der Liste auf. Gemäß einer anderen Implementierung handelt es sich bei der Zugriffsliste um eine Liste von Wörtern oder Phrasen. Wenn der dem in dem Schritt 310 empfangenen Bezeichner entsprechende Host eines der Wörter oder eine der Phrasen aufweist (oder alternativ keines der Wörter oder keine der Phrasen), so weist der in dem Schritt 310 empfangene Bezeichner einen Konflikt mit der Liste auf. Verschiedene Host-Systeme und möglicherweise ISPs weisen Suchmaschinen auf, die es einer Einzelperson ermöglichen, nach bestimmten Host-Systemen zu suchen, die relevante Daten aufweisen. Die Suchmaschinen weisen häufig eine Liste von Wörtern auf, wie etwa eine Seitenbeschreibung, welche die von den Host-Systemen über das Internet verfügbare Informationen identifizieren. Die protokollierende DLL an einem Client-System kann die Seitenbeschreibungsinformationen von einem Host-System oder einer Suchmaschine kopieren und diese kopierte Liste daraufhin zur Identifikation von Konflikten verwenden. Wenn die protokollierende DLL einen Bezeichner empfängt, der einem Host-System entspricht, das Wörter aufweist, die sich in der Liste befinden, so ist ein Konflikt identifiziert.
Die Abbildung aus 4 zeigt ein Flussdiagramm, das die Schritte veranschaulicht, die bei der Protokollierung von Netzwerkzugriffen gemäß einem alternativen Ausführungsbeispiel der vorliegenden Erfindung durchgeführt werden. Zu Beginn ruft die protokollierende DLL, die auf einem Client-System ausgeführt wird, eine Zugriffsliste von einem protokollierenden Server ab und speichert die Zugriffsliste in dem Schritt 405 lokal auf dem Client-System. Die protokollierende DLL empfängt daraufhin in dem Schritt 410 eine Anforderung für den Zugriff auf ein Host-System, vergleicht in dem Schritt 415 das Host-System mit der lokal gespeicherten Zugriffsliste und prüft in dem Schritt 420, ob die Anforderung einen Konflikt mit der Zugriffsliste aufweist. Die Schritte 405, 410, 415 und 420 aus 4 sind analog zu den entsprechenden Schritten 305, 310, 315 und 320 der Abbildung, aus 3.
Wenn die Anforderung als mit einem Konflikt mit der Zugriffsliste in dem Schritt 420 identifiziert wird, so wird der Zugriff auf das angeforderte Host-System in dem Schritt 425 verweigert. In einem Ausführungsbeispiel wird der Zugriff durch die protokollierende DLL verweigert, indem die Anforderung nicht an den TCP/IP-Stapel 240 aus 2 weitergeleitet wird. Die protokollierende DLL ignoriert die Anforderung und gibt bei einer Implementierung eine Nachricht zurück an den Benutzer, dass der Zugriff auf das angeforderte Host-System verweigert worden ist. Bei einer alternativen Implementierung gibt die protokollierende DLL an den Benutzer eine Meldung zurück, dass das angeforderte System nicht lokalisiert werden konnte. Diese Meldung ist die gleiche Meldung, die der Browser empfangen würde, wenn auf ein bestimmtes System nicht zugegriffen werden kann (zum Beispiel, wenn die adressierte Position nicht gefunden werden konnte), um zu vermeiden, dass der Benutzer auf den Betrieb der vorliegenden Erfindung hingewiesen wird.
Wenn in erneutem Bezug auf den Schritt 420 die Anforderung nicht im Konflikt mit der Zugriffsliste steht, so übermittelt die protokollierende DLL in dem Schritt 430 Protokolldaten für die Anforderung an den protokollierenden Server. Wie dies bereits vorstehend im Text erörtert worden ist, können diese Protokolldaten alle Daten einer umfassenden Vielfalt von Daten aufweisen, einschließlich der Identifikation des angeforderten Host-Systems, dem Datum und der Uhrzeit der Anforderung, usw. Die protokollierende DLL leitet die Anforderung ferner in dem Schritt 435 an das Host-System weiter (über den TCP/IP-Stapel 240 aus 2).
Die Abbildung aus 5 zeigt ein funktionales Blockdiagramm, das einen Protokollserver gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht. Der in der Abbildung aus 5 veranschaulichte Protokollserver 150 weist eine Protokoll-/Zugriffssteuerung 510, einen Protokolldatenspeicher 520 und eine Datenbank 530 mit dauerhaftem Zugriff auf. Die Protokoll-/Zugriffssteuerung 510 steuert das Speichern und den Abruf von Daten sowohl in dem Protokolldatenspeicher 520 als auch in der Datenbank 530 mit dauerhaftem Zugriff.
Nach dem Empfang der Protokolldaten von einem Client-System speichert der Protokolldatenspeicherprozess 512 die empfangenen Protokolldaten sowie einen Bezeichner für das Client-System, von dem die Protokolldaten empfangen worden sind, in dem Protokolldatenspeicher 520. Der Protokolldatenspeicherprozess 512 erhält sofern vorhanden ferner Seitenbeschreibungsinformationen, die den empfangenen Protokolldaten entsprechen, wie dies nachstehend im Text in näheren Einzelheiten beschrieben ist.
Nach dem Empfang einer Anforderung von Protokolldaten in Bezug auf einen bestimmten Benutzer oder ein bestimmtes Client-System, verifiziert der Prozess 517 des Protokolldatenabrufs, dass der Benutzer berechtigt ist, auf die angeforderten Protokolldaten zuzugreifen, und die angeforderten Protokolldaten werden an den Benutzer weitergeleitet. Der Prozess 517 des Abrufs von Protokolldaten organisiert ferner die angeforderten Protokolldaten, sofern erforderlich, so dass diese mit den Präferenzen der die Anforderung stellenden Person übereinstimmen.
Der Steuerungsprozess 527 für die Zugriffsdatenbank steuert das Speichern der Zugriffsinformationen in der Datenbank 530 mit permanentem Zugriff sowie das Abrufen von Zugriffsinformationen aus dieser Datenbank. Die Datenbank 530 für einen permanenten Zugriff speichert Zugriffslisten, die den bestimmten Client-Systemen in dem nichtflüchtigen Speicher entsprechen. Nach dem Empfang einer Anforderung für eine Zugriffsliste ruft der Steuerprozess 527 eine Kopie der angeforderten Zugriffsliste aus der Datenbank 530 ab und gibt eine Kopie an die die Anforderung stellende Person zurück. Nach dem Empfang einer Anforderung für das Hinzufügen oder das Entfernen von Host-Systemen zu oder von einer bestimmten Zugriffsliste führt der Steuerprozess 527 die angeforderte Hinzufügung oder Entfernung durch.
Die Abbildung aus 6 zeigt ein Flussdiagramm, das die Schritte veranschaulicht, die beim Aufzeichnen von Daten an einem Protokollserver gemäß einem Ausführungsbeispiel der vorliegenden Erfindung durchgeführt wird. Der Protokollserver empfängt in dem Schritt 605 zuerst Protokolldaten von einem Client-System. In dem Schritt 610 prüft der Protokolldatenspeicherprozess danach ob die Protokolldaten Seitenbeschreibungsinformationen aufweisen. Wenn der Protokolldatenspeicherprozess keine Seitenbeschreibungsinformationen aufweist, so greift der Protokolldatenspeicherprozess in dem Schritt 615 auf das in den Protokolldaten identifizierte Host-System zu, um Seitenbeschreibungsinformationen für dieses Host-System zu erhalten. Nachdem die Seitenbeschreibungsinformationen entweder von dem Client-System als Teil der Protokolldaten oder in dem Schritt 615 erhalten worden sind, speichert der Protokolldatenspeicherprozess in dem Schritt 620 die Protokolldaten einschließlich der Seitenbeschreibungsinformationen an einem dem Benutzer entsprechenden Speicherplatz. In dem veranschaulichten Ausführungsbeispiel kann der Protokollserver mehrere Benutzer bzw. Anwender unterstützen und speichert jede ihrer Informationen separat.
Der Protokolldatenspeicherprozess kann die Seitenbeschreibungsinformationen auf jede Art und Weise einer Vielfalt verschiedener Möglichkeiten erhalten. Der Protokolldatenspeicherprozess kann die Seitenbeschreibungsinformationen zum Beispiel von dem Host-System erhalten oder alternativ kann der Protokolldatenspeicherprozess auf eine Suchmaschine oder ein anderes Host-System oder einen ISP zugreifen, um Seitenbeschreibungsinformationen zu erhalten. Gemäß einer Implementierung erhält der Protokolldatenspeicherprozess die Seitenbeschreibungsinformationen indem eine Nachricht an das Host-System (oder eine Suchmaschine) gesendet wird, welche ein bestimmtes Host-System identifiziert und entweder die Liste von Schlüsselwörtern für das System oder eine Zusammenfassung für das System anfordert.
In einem alternativen Ausführungsbeispiel werden die Seitenbeschreibungsinformationen nicht durch den Protokollserver erhalten. In dem vorliegenden Ausführungsbeispiel sind die Schritte 610 und 615 nicht enthalten und der Protokolldatenspeicherprozess speichert die Protokolldaten, sofern vorhanden, die durch das Client-System in dem Schritt 605 zu dem Speicher übertragen werden.
Die Abbildung aus 7 zeigt ein Flussdiagramm, das die Schritte veranschaulicht, die bei der Meldung der Protokolldaten gemäß einem Ausführungsbeispiel der vorliegenden Erfindung durchgeführt werden. Der Protokollserver empfängt in dem Schritt 705 zuerst eine Anforderung für die Protokolldaten von einem Supervisor bzw. von einer Überwachungsperson. Ein "Supervisor" betrifft einen Einzelanwender, der auf die Protokolldaten anderer Benutzer bzw. Anwender zugreifen möchte. Diese Anforderung kann von jedem der in der Abbildung aus 1 dargestellten Client-Systeme 110 empfangen werden. Der Prozess des Abrufens von Protokolldaten überprüft danach in dem Schritt 710, ob der Supervisor berechtigt ist, die Protokolldaten anzusehen. Für diese Verifizierung gibt es eine umfassende Vielzahl konventioneller Möglichkeiten, wie etwa die Notwendigkeit einer Benutzeridentifikation und eines Passworts. Wenn der Supervisor nicht autorisiert ist, so sieht der Prozess des Abrufens von Protokolldaten in dem Schritt 715 eine Zusammenfassung der Protokolldaten an den Supervisor vor.
Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung kann der Supervisor eine Benutzerpräferenz in Bezug auf den Protokollserver festlegen, welche anzeigt, welches Format eine Benutzerpräferenz aufweisen sollte. Gemäß einer Implementierung handelt es sich bei einer Benutzerpräferenz um eine hierarchische Festlegung. Der Prozess des Abrufens von Protokolldaten erhält alle Protokolldaten für den spezifizierten Benutzer bzw. Anwender seit der letzten Überprüfung der Protokolldaten durch den Supervisor, und wobei die Protokolldaten danach hierarchisch angezeigt werden, wie dies in der Abbildung aus 8 dargestellt ist. Gemäß der Veranschaulichung kann eine Webseite 805, auf die zuerst zugegriffen wird, einen URL von "www.intel.com" auf. Die zweite Webseite 810, auf die zugegriffen wird, kann einen URL "www.intel.com/intel/index.htm" aufweisen, und die dritte Webseite 815, auf welche zugegriffen wird, weist etwa den URL "www.intel.com/inten/contact/index.htm" auf. Wie dies veranschaulicht ist, werden somit die zweite Webseite 810 und die dritte Webseite 815 hierarchisch unterhalb und von der ersten Webseite 805 versetzt angezeigt. Hiermit wird festgestellt, dass ferner zusätzliche Seitenbeschreibungsinformationen (nicht abgebildet) gemeinsam mit den URLs angezeigt werden können, auf welche zugegriffen wird.
Hiermit wird festgestellt, dass andere Benutzerpräferenzen ebenfalls festgelegt werden können. Zum Beispiel kann ein Anwender bzw. ein Benutzer eine chronologische Anordnung anfordern oder alternativ einen Zugriff nur auf die Host- Systeme mit Seitenbeschreibungen, die ein bestimmtes oder mehrere durch den Supervisor identifizierte Wörter aufweisen.
Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung kann der Supervisor auch die Zugriffsliste für den Benutzer verändern, nachdem die Autorisierung bzw. die Berechtigung für den Supervisor für den Zugriff auf die Protokolldaten bestätigt worden ist. Wie dies bereits vorstehend im Text erörtert worden ist, wird eine dauerhafte bzw. permanente Zugriffsliste an dem Protokollserver gespeichert und zur temporären Speicherung und Nutzung in das Client-System kopiert. Somit können etwaige Änderungen, der permanenten Zugriffsliste durch den Supervisor beim Zugriff auf den Protokollserver durchgeführt werden.
Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung muss ein Supervisor fernre nicht auf den Protokollserver zugreifen, um die Protokolldaten zu überprüfen. In diesem Ausführungsbeispiel übermittelt der Prozess des Abrufens von Protokolldaten periodisch die Protokolldaten unter Verwendung von elektronischer Post bzw. E-Mail an den Supervisor. Alternativ kann der Prozess des Abrufens von Protokolldaten Protokolldaten mit einer vorbestimmten Liste von Wörtern oder Seiten an dem Protokollserver vergleichen (zum Beispiel mit der vorstehend im Text erörterten Zugriffsliste). Wenn ein Zugriff mit einem der Wörter in der vorbestimmten Wörterliste übereinstimmt, kann der Prozess des Abrufens von Protokolldaten den Supervisor auf einen unbefugten Zugriff hinweisen. Für das Hinweisen des Supervisors gibt es verschiedene jeweils geeignete. Möglichkeiten, wie etwa das Senden einer elektronischen Nachricht an den Supervisor, die anzeigt, das auf die Seite zugegriffen worden ist, das Senden einer Funkseite an einen von dem Supervisor benutzten herkömmlichen Pager oder das Anwählen einer Telefonnummer (z. B. für ein Mobiltelefon), die von dem Supervisor benutzt wird und eine akustische Warnmeldung bzw. einen akustischen Hinweis abspielt.
Die Abbildung aus 9 veranschaulicht ein Ausführungsbeispiel eines Hardwaresystems, das sich zur Verwendung in Verbindung mit der vorliegenden Erfindung eignet. In einem Ausführungsbeispiel stellen jedes der Client-Systeme 110, der Host-Systeme 120, der Protokollserver 150, die in der Abbildung aus 1 veranschaulicht sind, Hardwaresysteme 900 aus 9 dar. In dem veranschaulichten Ausführungsbeispiel weist das Hardwaresystem 900 den Prozessor 902 und den Cache-Speicher 904 auf, die gemäß der Abbildung miteinander gekoppelt sind. Darüber hinaus umfasst das Hardwaresystem 900 einen Hochleistungs-Ein-Ausgabebus (E/A-Bus) 906 und einen Standard-E/A-Bus 908. Die Host-Brücke 910 koppelt den Prozessor 902 mit dem Hochleistungs-E/A-Bus 906, während die E/A-Busbrücke 912 die beiden Busse 906 und 908 miteinander koppelt. Mit dem Bus 906 gekoppelt sind eine Netzwerk-/Kommunikationsschnittstelle 924, ein Systemspeicher 914 und ein Videospeicher 916. Die Anzeigevorrichtung 918 ist wiederum mit dem Videospeicher 916 gekoppelt. Mit dem Bus 908 gekoppelt sind ein Massenspeicher 920 und eine Tastatur- und Zeigevorrichtung 922.
Diese Elemente 902–922 führen ihre im Fach bekannten konventionellen Funktionen aus. Im Besonderen wird die Netzwerk-/Kommunikationsschnittstelle 924 verwendet, um eine Kommunikation zwischen dem System 900 und jedem Netzwerk eines umfassenden Bereichs konventioneller Netzwerke vorzusehen, wie etwa dem Ethernet, Token Ring, dem Internet, usw. Hiermit wird festgestellt, dass die Schaltkreisanordnung der Schnittstelle 924 von der Art des Netzwerks abhängig ist, mit dem das System 900 gekoppelt ist.
Der Massenspeicher 920 wird dazu verwendet, die Daten und Programmieranweisungen permanent zu speichern, um die vorstehend beschriebenen Funktionen zu implementieren, während der Systemspeicher 914 dazu verwendet wird, Daten und Programmieranweisungen vorübergehend zu speichern, wenn diese durch den Prozessor 902 ausgeführt werden. Der Massenspeicher 902 kann mit den Programmieranweisungen versehen werden, indem die Programmanweisungen von einem verteilenden Speichermedium (nicht abgebildet) geladen werden oder durch Herunterladen der Programmverteilungen von einem Server (nicht abgebildet), der über die Netzwerk-/Kommunikationsschnittstelle 924 mit dem Hardwaresystem 900 gekoppelt ist. Gemeinsam sollen diese Elemente eine umfassende Kategorie von Hardwaresystemen repräsentieren, zu denen unter anderem Allzweck-Computersysteme zählen, die auf einem von der Intel Corporation, Santa Clara, Kalifornien, USA, hergestellten Pentium^® Prozessor oder Pentium^® Prozessor basieren.
Hiermit wird festgestellt, dass verschiedene Komponenten des Hardwaresystems 900 auch anders angeordnet werden können. Zum Beispiel kann sich der Cache-Speicher 904 auf einem Chip mit dem Prozessor 902 befinden. Ferner erfordern oder umfassen bestimmte Implementierungen der vorliegenden Erfindung nicht alle der vorstehend genannten. Komponenten. Zum Beispiel können der Massenspeicher 920, die Tastatur- und Zeigevorrichtung 922 und/oder die Anzeigevorrichtung 918 und der Videospeicher 916 in dem System 900 nicht vorgesehen sein. Zusätzlich können die Peripheriegeräte, die in der Abbildung mit einem Standard-E/A-Bus 908 gekoppelt sind, auch mit dem Hochleistungs-E/A-Bus 906 gekoppelt sein; wobei bei bestimmten Implementierungen auch nur ein einziger Bus vorgesehen sein kann, wobei die Bestandteile des Hardwaresystems 900 mit dem einen Bus gekoppelt sind. Ferner kann das System 900 auch zusätzliche Komponenten aufweisen, wie etwa zusätzliche Prozessoren, Speichervorrichtungen oder Speicher.
In einem Ausführungsbeispiel sind das Verfahren und die Vorrichtung für die Protokollierung und Meldung eines Netzwerkszugriffs aus der Ferne gemäß den vorstehenden Ausführungen als eine Reihe von Softwareroutinen implementiert, die durch ein Hardwaresystem aus 9 ausgeführt werden. Diese Softwareroutinen umfassen eine Mehrzahl oder eine Reihe von Anweisungen, die durch einen Prozessor in einem Hardware-System ausgeführt werden sollen, wie etwa dem Prozessor 902 aus 9. Anfangs wird die Reihe von Anweisungen bzw. Befehlen in einer Speichervorrichtung gespeichert, wie etwa dem Massenspeicher 920. Die Anweisungen werden von einer Speichervorrichtung 920 in den Speicher 914 kopiert, und danach erfolgt ein Zugriff und eine Ausführung durch den Prozessor 902. Bei einer Implementierung sind die Softwareroutinen in der Programmiersprache C++ geschrieben. Hiermit wird festgestellt, dass diese Routinen jedoch auch in jeder anderen einer Vielzahl von Programmiersprachen implementiert werden können. Bei alternativen Ausführungsbeispielen ist die vorliegende Erfindung in diskreter Hardware und Firmware implementiert. Zum Beispiel kann ein anwendungsspezifischer Schaltkreis (ASIC) mit den vorstehend beschriebenen Funktionen der vorliegenden Erfindung programmiert werden.
In verschiedenen der vorstehenden Ausführungen ist die Netzwerkumgebung als das Internet beschrieben. Hiermit wird jedoch festgestellt, dass die vorliegende Erfindung in Verbindung mit jeder Art von Netzwerkumgebung verwendet werden kann und nicht auf das Internet beschränkt ist.
Hiermit wird ferner festgestellt, dass die vorliegende Erfindung zur Fernprotokollierung einer umfassenden Vielfalt von Aktivitäten verwendet werden kann, die auf einem Client-System ausgeführt werden können. Zum Beispiel kann ein Client-System 110 aus 1 Fernsehprogrammsendungen empfangen und anzeigen. Somit können der Fernsehkanal und die Uhrzeit sowie das Datum des Betrachtens als die Protokolldaten zu dem Protokollserver übertragen werden. Zusätzlich können die Kanalbeschreibungsinformationen weitergeleitet werden, wie etwa ausgesuchter Text von Titelinformationen oder eine elektronische Fernsehzeitung. Diesbezüglich ist eine Übertragung während dem vertikalen Austastintervall möglich, wobei es sich auch um Daten von einem Vorschaukanal handeln kann.
Vorgesehen sind gemäß der vorliegenden Erfindung somit ein Verfahren und eine Vorrichtung zur Protokollierung und Meldung des Netzwerkzugriffs aus der Ferne. Ein Datensatz der Protokolldaten, die zumindest die zugegriffenen Host-Systeme identifizieren sowie möglicherweise zusätzliche Informationen, können in vorteilhafter Weise an einem entfernten Standort verwaltet werden. Ein Supervisor kann daraufhin willentlich auf den entfernten Standort zugreifen, wobei die Daten durch einen einzelnen Anwender oder Benutzer nicht verändert werden können, da die Daten entfernt gespeichert werden. Ferner kann in vorteilhafter Weise der Zugriff auf bestimmte Host-Systeme auf der Basis der Zugriffsliste verhindert werden, die von einem entfernten Standort zu dem Zeitpunkt erhalten wird, an dem die Ausführung der vorliegenden Erfindung einsetzt. Die Zugriffsliste wird somit entfernt verwaltet, wodurch Versuche einer Einzelperson, die Liste zu verändern, abgewehrt werden können.
Für einen Fachmann auf dem Gebiet sind nach dem Lesen der vorstehenden Beschreibung zahlreiche Abänderungen und Modifikationen in Bezug auf die vorliegende Erfindung erkennbar, wobei hiermit festgestellt wird, dass die dargestellten besonderen Ausführungsbeispiele, die zu Veranschaulichungszwecken beschrieben wurden, in keiner Weise einschränkend auszulegen sind. Verweise auf Einzelheiten spezieller Ausführungsbeispiele schränken den Umfang der Ansprüche nicht ein.

Claims

Verfahren, das folgendes umfasst: Abfangen einer Zugriffsanforderung an einem Client-System (110) für einen Zugriff auf Informationen an einem Host-System (120) in einem Netzwerk (140), wobei die genannte Zugriffanforderung ihren Ursprung an dem Client-System hat; Senden von Protokolldaten von dem Client-System zu einem Protokollserver (150) in dem Netzwerk, wobei die genannten Protokolldaten zur Identifikation der Zugriffsanforderung dienen; und Empfangen einer Zugriffszusammenfassung von dem Protokollserver an dem Client-System, wobei die Zusammenfassung zumindest einen Teil der von dem Client-System empfangenen Protokolldaten zusammenfasst.
Verfahren nach Anspruch 1, wobei es sich bei der Zugriffsanforderung um eine Anforderung für einen Zugriff auf eine Seite im World Wide Web handelt, die von dem Client-System empfangen wird.
Verfahren nach Anspruch 1, wobei das Verfahren ferner folgendes umfasst: Empfangen einer Zugriffsliste (235) an dem Client-System von dem Protokollserver; Vergleichen der Zugriffsanforderung mit der Zugriffsliste; und Einleiten eines Zugriffs von dem Client-System an das Host-System nur dann, wenn die Zugriffsanforderung keinen Konflikt mit der Zugriffsliste aufweist.
Verfahren nach Anspruch 1, wobei das Verfahren ferner. folgendes umfasst: Zugriff des Protokollservers auf das Host-System als Reaktion auf den Empfang der Protokolldaten von dem Client-System an dem Protokollserver; und Erhalten von Seitenbeschreibungsinformationen über das Host-System von dem Host-System an dem Protokollserver.
Verfahren nach Anspruch 1, wobei das Senden folgendes umfasst: Vergleichen der Zugriffsanforderung an dem Client-System mit einer von dem Protokollserver empfangenen Zugriffsliste (235); und Senden der Protokolldaten von dem Client-System an den Protokollserver nur dann, wenn die einen Konflikt mit der Zugriffsliste aufweist.
Verfahren nach Anspruch 1, wobei die Protokolldaten eine Quelle der Zugriffsanforderung identifizieren sowie Seitenbeschreibungsinformationen, die der Zugriffsanforderung entsprechen.
Verfahren nach Anspruch 1, wobei das Verfahren ferner folgendes umfasst: Vergleichen der Protokolldaten durch den Protokollserver mit einer Mehrzahl von vorbestimmten Host-Systemen; und Erteilen eines Hinweises durch den Protokollserver an einen vorbestimmten Benutzer als Reaktion auf eine Übereinstimmung der Protokolldaten mit mindestens einem System einer Mehrzahl vorbestimmter Host-Systeme.
Verfahren nach Anspruch 7, wobei das Erteilen eines Hinweises das Senden einer elektronischen E-Mail-Nachricht an den vorbestimten Benutzer umfasst.
Maschinenlesbares Medium, auf dem eine Mehrzahl von Anweisungen gespeichert ist, die so beschaffen sind, dass sie durch einen Prozessor ausgeführt werden, um eine Funktion zu implementieren, wobei die Implementierung der Funktion folgendes umfasst: Abfangen einer Zugriffsanforderung an einem Client-System (110) für einen Zugriff auf Informationen an einem Host-System (120) in einem Netzwerk (140), wobei die genannte Zugriffanforderung ihren Ursprung an dem Client-System hat; Senden von Protokolldaten von dem Client-System zu einem Protokollserver (150) in dem Netzwerk, wobei die genannten Protokolldaten zur Identifikation der Zugriffsanforderung dienen; und Empfangen einer Zugriffszusammenfassung von dem Protokollserver an dem Client-System, wobei die Zusammenfassung zumindest einen Teil der von dem Client-System empfangenen Protokolldaten zusammenfasst.
Maschinenlesbares Medium nach Anspruch 9, wobei es sich bei der Zugriffsanforderung um eine Anforderung für einen Zugriff auf eine spezifizierte Datei in dem Host-System handelt.
Maschinenlesbares Medium nach Anspruch 9, wobei die Implementierung der Funktion ferner folgendes umfasst: Empfangen einer Zugriffsliste (235) an dem Client-System von dem Protokollserver; Vergleichen der Zugriffsanforderung mit der Zugriffsliste; und Einleiten eines Zugriffs von dem Client-System an das Host-System nur dann; wenn die Zugriffsanforderung keinen Konflikt mit der Zugriffsliste aufweist.
Maschinenlesbares Medium nach Anspruch 9, wobei die Implementierung der Funktion ferner folgendes umfasst: Vergleichen der Zugriffsanforderung an dem Client-System mit einer von dem Protokollserver empfangenen Zugriffsliste; und Senden der Protokolldaten von dem Client-System an den Protokollserver nur dann, wenn die einen Konflikt mit der Zugriffsliste aufweist.
Verfahren nach Anspruch 7, wobei der Protokollserver ferner dazu dient, eine Zugriffsliste (235) zu speichern, wobei das genannte Client-System dazu dient, die Zugriffsliste von dem Protokollserver abzurufen und eine erste Zugriffsanforderung mit der Zugriffsliste zu vergleichen; wobei das genannte Client-System die die erste Zugriffsanforderung identifizierenden ersten Protokolldaten nur dann an den Protokollserver sendet, wenn die erste Zugriffsanforderung einen Konflikt mit der Zugriffsliste aufweist.
Vorrichtung, die folgendes umfasst: eine Schnittstelle zum Abfangen einer Zugriffsanforderung an einem Client-System (110) für einen Zugriff auf Informationen an einem Host-System (120) in einem Netzwerk (140), wobei die genannte Zugriffanforderung ihren Ursprung an dem Client-System hat; und eine Protokollverarbeitungseinheit, die Protokolldaten von dem Client-System an einen Protokollserver (150) in dem Netzwerk senden kann, wobei die genannten Protokolldaten dazu dienen, die Zugriffsanforderung zu identifizieren, und wobei die. genannte Protokollverarbeitungseinheit an dem Client-System eine Zugriffszusammenfassung von dem Protokollserver empfangen kann, welche zumindest einen Teil der Protokolldaten zusammenfasst.
Vorrichtung nach Anspruch 14, wobei es sich bei der genannten Zugriffsanforderung um eine Anforderung für einen Zugriff auf eine bestimmte Datei an dem Host-System handelt.
Vorrichtung nach Anspruch 14, wobei der Protokollierungsprozess auch dazu dient, eine Zugriffsliste von dem Protokollserver abzurufen, die Zugriffsanforderung mit der Zugriffsliste zu vergleichen und einen Zugriff von dem Client-System auf das Host-System nur dann einzuleiten, wenn die Zugriffsanforderung keinen Konflikt mit der Zugriffsliste aufweist.
Vorrichtung nach Anspruch 14, wobei der Protokollierungsprozess auch dazu dient, die Zugriffsanforderung an dem Client-System mit einer von dem Protokollserver empfangenen Zugriffsliste zu vergleichen und die Protokolldaten nur dann an den Protokollserver zu senden, wenn die Zugriffsanforderung einen Konflikt mit der Zugriffsliste aufweist.