-
Gebiet der
Erfindung
-
Die
vorliegende Erfindung betrifft allgemein das Gebiet der Datenkommunikation
für Personalcomputer
(PCs) und insbesondere ein System zum dynamischen Transcodieren
von zwischen zwei Computern über
eine Kommunikationsverbindung übertragenen
Daten.
-
Verwandte
Technik
-
Das
Internet wird schnell zum bevorzugten Datenkommunikationsmedium
für eine
breite Kategorie von Computerbenutzern, die sich erstreckt von privaten
Individuen bis zu großen
multinationalen Unternehmen. Derartige Nutzer verwenden das Internet nun
routinemäßig, um
auf Informationen zuzugreifen, Informationen zu verteilen, elektronisch
zu korrespondieren und sogar um Personalkonferenzen durchzuführen. Eine
stetig wachsende Anzahl von Individuen, Organisationen und Firmen
hat eine Präsenz
in dem Internet über "Webseiten" in dem World Wide
Web (www) eingerichtet.
-
Aus
vielfältigen
Gründen
kann es wünschenswert
sein, zwischen einem lokalen Clientcomputer und einem Netzwerk-Servercomputer übertragene
Daten zu manipulieren. Beispielsweise kann es in bestimmten Fällen vorteilhaft
sein, von einem Internet-Servercomputer abgerufenen Inhalt dynamisch zu
ergänzen,
zu modifizieren oder zu löschen,
bevor der Inhalt einem Clientcomputer bereitgestellt wird. Umgekehrt
kann es vorteilhaft sein, eine Inhaltsanforderung von einem Clientcomputer
vor der Übertragung
der Anforderung an einen Internet-Servercomputer zu modifizieren.
Während
eine derartige dynamische Manipulation von Anforderungen und Antworten
wünschenswert
ist, ist es sinnlos, zu erwarten, daß die ausgedehnte Internetinfrastruktur
sich schnell ändern
wird, um eine derartige neue Möglichkeit
zur Verfügung
zu stellen. Aus diesem Grund ist es wünschenswert, derartige neue
Möglichkeiten bzw.
Kapa zitäten
auf eine Weise zu implementieren, welche weder Änderungen an den existierenden
Clientcomputer noch an den Internet-Servercomputer erfordert.
-
Es
ist bekannt, einen Proxy-Server oder Netzwerk-Proxy als Vermittler
zwischen einem oder mehreren Clientcomputern und einem externen Netzwerk,
beispielsweise dem Internet, einzusetzen. Netzwerk-Proxies sind
allgemein beschrieben in Jan S. Graham HTML Sourcebook: A complete
guide to HTML 3.0 403 (2. Ausgabe 1996). Eine übliche Anwendung für einen
Proxy-Server ist eine sogenannte "Firewall", wobei der Proxy-Server für die ganze Kommunikation
mit der Außenwelt
verantwortlich ist. Mit anderen Worten, lokale Einrichtungen dürfen nicht
direkt mit externen Netzwerkcomputern, wie beispielsweise Internet-Servern,
kommunizieren. Stattdessen richtet jede lokale Einrichtung Anforderungen
nach im Netzwerk befindlichen Daten an den Proxy-Server. Wenn der
Proxy-Server eine derartige Anforderung empfängt, sendet er die Anforderung
an den entsprechenden externen Computer, empfängt die Antwort von dem externen
Computer und leitet die Antwort dann an die lokale Einrichtung weiter.
Der externe Computer hat folglich keine Kenntnisse über die
lokalen Einrichtungen. Auf diese Weise sind die lokalen Einrichtungen
vor möglichen
Gefahren, beispielsweise unautorisierten Zugriffen, geschützt.
-
Existierende
Proxy-Server manipulieren die durch sie hindurchgeleiteten Daten
nicht. Im wesentlichen sind Proxy-Server nur funktionslose Leitungen für Anforderungen
und Antworten. Diese Beschränkung
der existierenden Proxy-Server verhindert, daß diese Einrichtungen mit vollem
Vorteil genutzt werden, wenn eine Kommunikation zwischen lokalen Einrichtungen
und Netzwerk-Einrichtungen ermöglicht
wird. Benötigt
wird daher ein sogenannter „intelligenter" bzw. "Smart"-Proxy, der für durch
ihn hindurch laufenden Daten untersuchen kann, ob es eine für eine externe
Netzwerkeinrichtung vorgesehene Anforderung ist oder an eine lokale
Einrichtung zurückgegebener
Netzwerk-Inhalt, und der dynamisch auf diese Daten einwirkt. Eine
derartige Einrichtung kann verwendet werden, um einen breiten Bereich von
Diensten bereitzustellen, welche zuvor ohne Modi fikation der existierende
Internetinfrastruktur unmöglich
waren.
-
Ein
weiteres Beispiel einer bekannten Anordnung ist beschrieben in FOX
A. et al. 'ADAPTING
TO NETWORK AND CLIENT VARIABILITY VIA ON DEMAND DYNAMIC DISTILLATION' ACM SIGPLAN NOTICES,
ASSOCIATION FOR COMPUTING MACHINERY, NEW YORK, US, Band 31, Nr.
9, 1. September 1996, Seiten 160-170, ISSN: 0362-1340.
-
ZUSAMMENFASSENDE DARSTSLLUNG
DER ERFINDUNG
-
Die
Ausführungsformen
der vorliegenden Erfindung betreffen Einrichtungen, Systeme und
Verfahren zum Transcodieren von zwischen Computern, beispielsweise
einem Netzwerk-Servercomputer und einem Netzwerk-Clientcomputer übermittelten
Informationen. Gemäß Aspekten
der vorliegenden Erfindung wird eine in den Ansprüchen 1 bis
2 definierte Einrichtung, ein in den Ansprüchen 3 bis 17 definiertes Verfahren
und ein in den Ansprüchen
18 bis 20 definierter Satz von Befehlen zur Ausführung durch einen Computer
bereitgestellt.
-
Gemäß einem
Ausführungsbeispiel
umfaßt eine
Einrichtung zur Datenübertragung
zwischen einem Netzwerk-Server und einem Netzwerk-Client über eine
Kommunikationsverbindung einen mit einem Transcodierdienstanbieter
gekoppelten Parser. Der Parser ist so konfiguriert, daß er selektiv
in Abhängigkeit
von einem vorher bestimmten Auswahlkriterium den Transcodierdienstanbieter
aufruft.
-
KURZE BESCHREIBUNG DER
ZEICHNUNGEN
-
1 zeigt
eine schematische Darstellung, die die Umgebung veranschaulicht,
in welcher Ausführungsformen
der vorliegenden Erfindung eingesetzt werden können.
-
2 zeigt
eine schematische Darstellung, die ein Transcodermodul gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung veranschaulicht.
-
3 zeigt
eine schematische Darstellung, die ein Ausführungsbeispiel der vorliegenden
Erfindung für
einen nicht aktivierten Netzwerk-Client veranschaulicht.
-
4 zeigt
eine schematische Darstellung, die ein Beispiel einer Benutzerschnittstelle
veranschaulicht, die einem nicht aktivierten Netzwerk-Client die
Steuerung der Transcodierfunktionalität ermöglicht.
-
5 zeigt
eine schematische Darstellung, die ein Ausführungsbeispiel der vorliegenden
Erfindung für
einen aktivierten Netzwerk-Client veranschaulicht.
-
6 zeigt
eine schematische Darstellung, die einen Netzwerk-Client mit in
einen Brower integrierter Transcodierfunktionalität gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung veranschaulicht.
-
7 bis 9 zeigen
Flußdiagramme,
welche eine Logik zur Präsentation
eines angeforderten URL-Objektes für einen Netzwerk-Client gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung veranschaulichen.
-
Detaillierte
Beschreibung
-
Ausführungsformen
der vorliegenden Erfindung stellen die Möglichkeit zur Verfügung, Informationen
dynamisch zu transcodieren, die beispielsweise zwischen einem Netzwerk-Servercomputer
und einem Netzwerk-Clientcomputer übertragen werden. So wie der
Begriff „Transcodieren" hier verwendet wird,
betrifft er eigentlich jede Manipulation von Daten, einschließlich des
Hinzufügens,
Modifizierens oder Löschens
von Daten, ist jedoch nicht hierauf beschränkt.
-
Es
wird nun auf 1 Bezug genommen, welche eine
Umgebung darstellt, in der Ausführungsformen
der vorliegenden Erfindung vorteilhafterweise eingesetzt werden
können.
Ein Netzwerk-Server 10 verwaltet die Datenübertragung
aus dem Internet 18 zu einem Netzwerk-Client 12.
Der Netzwerk-Client 12 kann jeder beliebige Computer mit
entsprechenden Datenkommunikationsmöglichkeiten sein.
-
Der
Netzwerk-Client 12 kommuniziert Informationsanforderungen über eine
Client/Server-Kommunikationsverbindung 14 an den Netzwerk-Server 10 und
empfängt
von diesem Informationen. Die Client/Server-Kommunikationsverbindung 14 kann
beispielsweise ein sogenanntes „langsames Netzwerk" sein, das beispielsweise
eine Einwahltechnologie von herkömmlichen
Telefonsystemen (POTS Plain Old Telephone System) oder drahtlose
Verbindungen verwendet. Alternativ kann die Client/Server-Kommunikationsverbindung
ein sogenanntes „schnelles Netzwerk" sein, beispielsweise
ein LAN oder WAN (Wide Area Network), das mit viel höheren Geschwindigkeiten
als langsame Netzwerke arbeiten kann. Kombinationen dieser Zugriffsverfahren
sind ebenfalls möglich.
Beispielsweise kann der Netzwerk-Client 12 eine POTS- oder eine drahtlose
Einwahlverbindung zu einer von einem ISP (Internet Service Provider)
geführten
Modembank verwenden, welche wiederum mit dem Netzwerk-Server 10 über LAN
verbunden ist. Der Netzwerk-Server 10 kommuniziert mit
im Internet 18 befindlichen Computern über eine Server/Netzwerk-Kommunikationsverbindung 16,
bei der es sich um ein beliebiges geeignetes Kommunikationsmedium
aus dem Stand der Technik handeln kann.
-
Gemäß einem
ersten allgemeinen Ausführungsbeispiel
der vorliegenden Erfindung, das schematisch in 2 dargestellt
ist, umfaßt
ein Transcoder 20, eine Parser 22 und eine Mehrzahl
von Transcodierdienstanbietern 24. Der Parser 22 ist
derart konfiguriert, daß er
auf von dem Transcoder 20 empfangene Daten einwirken kann,
beispielsweise auf eine von einer Client-Einrichtung erzeugte Anforderung
eines Netzwerkobjektes oder auf eine von einer Inhalt-Server-Einrichtung
bereitgestellte Antwort auf eine derartige Anforderung. Bei diesem
speziellen Ausführungsbeispiel
ist der Parser 22 für
das selektive Aufrufen eines oder mehrerer Transcodierdienstanbieter 24 auf
der Basis eines vorher bestimmten Auswahlkriteriums verantwortlich.
-
Der
Transcoder 20 kann beispielsweise als in einem Netzwerk-Proxy,
in einer Client-Einrichtung, in einer Netzwerk-Servereinrichtung oder in einer Inhalt-Servereinrichtung
installiertes Softwaremodul implementiert sein. Bei einer speziellen
Implementierung, die in 3 dargestellt ist, ist der Transcoder 20 in
einem entfernten Transcodierserver 34 installiert, der
zwischen dem Netzwerk-Client 12 und dem Internet 18 angeordnet
ist. Der Transcodierserver 34 kann einen Netzwerk-Server,
einen Stand-Alone-Computer in Kommunikation mit einem Netzwerk-Server
oder ein verteiltes Computersystem umfassen bzw. Teil dieser sein.
Der entfernte Transcodierserver 34 kann beispielsweise
mit einem ISP-Netzwerk,
einem Firmennetzwerk oder an beliebiger Stelle mit dem Internet 18 gekoppelt
sein und kann mehreren Nutzern (d. h. Clients) eine Möglichkeit
zur Erlangung von Inhalten im Internet 18 bereitstellen.
-
In
dem speziellen in 3 dargestellten Ausführungsbeispiel
umfaßt
der Transcodierserver 34 einen entfernten HTTP (Hypertext
Transfer Protocol)-Proxy bzw. HTTP-Remote-Proxy 36, der über eine
Server/Netzwerk-Kommunikationsverbindung 16 auf das Internet 18 zugreifen
kann. Der HTTP-Remote-Proxy 36 unterscheidet sich dadurch
von bekannten Netzwerk-Proxies, welche im allgemeinen wenig mehr
sind, als eine Leitung für
Anfragen an externe Internet-Ressourcen und für Antworten von diesen, daß er nicht
nur derartige Anforderungen und Antworten untersuchen kann, sondern
auch auf Befehle in den Anforderungen einwirken kann, indem er beispielsweise
bestimmen kann, ob der Inhalt zu transcodieren ist oder nicht. Darüber hinaus
ist der HTTP-Remote-Proxy 36 unter Verwendung des Transcoders 20 in
der Lage, von dem Internet 18 empfangenen Inhalt zu ändern, bevor
dieser an einen anfordernden Client 12 zurückgegeben
wird, wie weiter unten erläutert
wird.
-
Es
wird das Ausführungsbeispiel
in 3 näher
betrachtet. Der Transcoder 20 ist mit dem HTTP-Remote-Proxy 36 gekoppelt.
Der Parser 22 managt das Transcodieren von von dem Transcodierserver 34 an
den Netzwerk-Client 12 zu übertragenden Daten. Zu diesem
Zweck steuert der Parser 22 die Transcodierdienstanbieter 24,
so daß sie
Inhalt auf der Basis eines vorgegebenen Auswahlkriteriums selektiv
transcodieren. Beispielsweise kann ein oder können mehrere Transcodierdienstanbieter 24 die
Möglichkeit
anbieten, verschieden Typen von Dateninhalt zu komprimieren und/oder
zu skalieren, beispielsweise Bild, Video oder HTML (Hypertext Markup
Language). Derartige Anwendungen sind in der ebenfalls anhängigen US-Patentanmeldung
mit dem Aktenzeichen 08/772,164 mit dem Titel "System for Enhancing Data Access Over
a Communication Link",
angemeldet am 20. Dezember 1996 und Aktenzeichen Nr. 08/799,654
mit dem Titel "Method
and apparatus for Scaling Image Data", eingereicht am 11. Februar 1997, beide übertragen
an Intel Corporation, weiter beschrieben. Zur Veranschaulichung
bestimmter Merkmale der vorliegenden Erfindung ist eine Reihe von
Ausführungsbeispielen
weiter unten anhand der Inhalt-Skalierung/Kompression beschrieben;
wie jedoch erläutert
ist, können
die Transcodierdienstanbieter 24 vielfältige Transcodierfunktionen bereitstellen.
-
Wie
in 3 dargestellt ist, kann der Transcodierserver 34 ferner
einen Server-seitigen Cache-Speicher 30 umfassen, der von
einer Server-seitigen Cache-Schnittstelle 28 verwaltet
wird. Der Server-seitige Cache-Speicher 30 kann verwendet
werden, um sowohl die ursprünglichen
als auch die transcodierten Versionen von Inhalten zu speichern, und
zwar für
eine spätere Übertragung
an den Netzwerk-Client 12 ohne das Erfordernis des erneuten Abrufens
des Inhalts vom Internet 18 oder der erneuten Transcodierung
des Inhalts.
-
Der
Transcodierserver 34 ist mit einem Netzwerk-Client 12 über eine
Client/Server-Kommunikationsverbindung 14 gekoppelt. Der
Netzwerk-Client 12 umfaßt einen Browser 32,
beispielsweise den Browser Netscape Navigator V.3.0 (obwohl die
Erfindung in dieser Hinsicht nicht beschränkt ist), welcher die Darstellung
der Daten für
einen Benutzer managt. Bei diesem Ausführungsbeispiel ist der Netzwerk-Client 12 "nicht aktiviert", was bedeutet, daß keine
spezielle Transcodiersoftware auf den Netzwerk-Client 12 vorgeladen
wurde.
-
Der
Parser 22 kann eine relativ einfache, einheitliche Schnittstelle
zum HTTP-Remote-Proxy 36 umfassen und kann eine API (Application
Programming Interface bzw. Anwendungsschnittstelle) zum Transcodieren
von von dem HTTP-Remote-Proxy 36 empfangenen Daten umfassen.
Der Parser 22 managt einen oder mehrere Transcodierdienstanbieter 24,
auf die über
eine übliche
SPI (Service Provider Interface bzw. Dienstanbieterschnittstelle)
zugegriffen wird. Bei diesem speziellen Ausführungsbeispiel ist der Parser 22 entsprechend
der Windows Open Systems Architecture (WOSA) konzipiert und kann
als Win 32 DLL (Dynamic Link Library bzw. dynamische Laufzeit-Bibliothek)
implementiert sein. Die WOSA-Architektur, die beschrieben ist in
Readings on Microsoft Windows and WOSA (Microsoft Coporation 1995)
ermöglicht,
daß zusätzliche
Transcodierdienstanbieter 24 dynamisch zu dem System hinzugefügt werden
können,
um neue Merkmale und/oder bessere Transcodieralgorithmen bereitzustellen, während es
gleichzeitig nicht erforderlich ist, daß andere Softwarekomponenten
in dem System geändert oder
erneut getestet werden. Dieses Merkmal ist besonders vorteilhaft,
wenn der Transcodierserver 34 ferner mit "aktivierten" Netzwerk-Clients
wechselwirkt, die mit spezieller Transcodiersoftware ausgestattet
sind. Man beachte, daß einige
Merkmale des Parsers 22, die weiter unten beschrieben sind,
in dem Ausführungsbeispiel
des nicht aktivierten Clients gemäß 3 nicht
anwendbar sein können;
allerdings kann der Transcodierserver 34 vorteilhafterweise
flexibel genug konfiguriert sein, daß er sowohl Anforderungen von
nicht aktivierten und von aktivierten Netzwerk-Clients verarbeiten
kann.
-
In ähnlicher
Weise wie der Parser 22 kann die Serverseitige Cache-Schnittstelle 28 nach
einer Standard-Get/Set-Schnittstelle
moduliert sein. Der Server-seitige Cache-Speicher 30 "besitzt" im wesentlichen
alle Cache-gespeicherten Objekte, da er die Eigenschaften und die
Speicherung der Objekte managt und zu jeder Zeit ein beliebiges
nicht-verriegeltes Objekt ungültig
machen kann; allerdings ist das tatsächliche Format eines bestimmten
Cache-gespeicherten Objekts nur dem Parser 22 bekannt und
seinen zugehörigen
Transcodierdienstanbietern 24. Daher erfolgt bei diesem
Ausführungsbeispiel
aus Gründen
der Datenintegrität
und Transcodiereffizienz jeder Zugriff auf den Server-seitigen Cache-Speicher 30 über den
Parser 22.
-
Die
Server-seitige Cache-Schnittstelle 28 kann die folgenden
Aufrufe umfassen:
CreateEntry (URL, &Entry, ...);
GetEntry (URL, &Entry);
CreateStream
(Entry, &StreamEntry,
...);
GetStream (Entry, &StreamEntry,
...);
CloseEntry (Entry);
Close StreamEntry (StreamEntry);
GetProperties
(Entry, &Properties,
...);
SetProperties (Entry, &Properties,
...);
Read (StreamEntry, &OutStream,
...);
Write (StreamEntry, &InStream,
...).
-
Anders
als die meisten Cache-Speicher ermöglichen die Server-seitige
Cache-Schnittstelle 28 und der Server-seitige Cache-Speicher 30 das
Führen
von mehreren Darstellungen eines vorgegebenen Cache-gespeicherten
Objektes, wobei beschreibende Informationen über jede Darstellung im Server-seitigen
Cache-Speicher 30 enthalten
sind. Darüber
hinaus dient die Serverseitige Cache-Schnittstelle 28 und
der Server-seitige Cache-Speicher 30 als
Synchronisationspunkt für
Multithread-Zugriffe auf Cache-gespeicherte Objekte. Man beachte,
daß das
dargestellte Ausführungsbeispiel
keine spezielle Konfiguration der Server-seitigen Cache-Schnittstelle 28 und/oder
des Serverseitigen Cache-Speichers 30 erfordert. Tatsächlich kann
eine diesen Komponenten in den verschiedenen hier beschriebenen Ausführungsbeispielen
zugewiesene Funktionalität einfach
in anderen Systemkomponenten implementiert werden.
-
Der
CreateEntry()-Aufruf erzeugt für
ein spezielles Hypertext-Objekt einen Cache-Eintrag und gibt diesen
zurück.
Dieser Aufruf erzeugt ferner einen Eintragstrom für eine ursprüngliche
Version des Hypertext-Objektes. In ähnlicher Weise erlangt der
GetEntry()-Aufruf einen Cache-Eintrag für ein bereits im Cache-Speicher 30 existierendes
Hypertext-Objekt. Sowohl der CreateEntry()- als auch der GetEntry()-Aufruf
setzen Sperren (Locks) auf die zugehörigen Cache-gespeicherten Objekte,
bis ein CloseEntry()-Aufruf aufgerufen wird. Wenn eine Sperre gesetzt
ist, wird das Cache-gespeicherte Objekt nicht ersetzt oder von der
Cache-Schnittstelle 28 für ungültig erklärt, wobei dies einem oder mehreren
Transcodierdienstanbietern 24 ermöglicht, alle erforderlichen Cache-Operationen
sicher auszuführen,
beispielsweise das Abrufen eines Objekts und/oder die Speicherung.
-
Nachdem
ein Cache-Eintrag mit Hilfe eines CreateEntry()- bzw. GetEntry()-Aufrufs erzeugt oder geöffnet wurde,
können
die CreateStream()- oder GetStream()-Aufrufe einen Zusatzstromeintrag
für das
Cache-gespeicherte Objekt erzeugen oder öffnen. Jeder Zusatzstromeintrag
ist einer anderen transcodierten Version des Hypertext-Objektes
zugeordnet, die von einem der Transcodierdienstanbieter 24 abgerufen
oder angehängt
werden kann. Die Strom-basierte Verarbeitung von Cachegespeicherten
Objekten ermöglicht
Transcodierservern 34, das Senden einer transcodierten
Version eines Hypertext-Objektes an einen anfordernden Netzwerk-Client 12 zu
beginnen, selbst während
der Transcodierdienstanbieter 24 an die gleiche Version
zusätzlichen transcodierten
Inhalt anhängt.
Zu den Vorteilen dieser Strom-basierten Verarbeitung gehören die
Verringerung der Benutzerlatentzeit durch inkrementales Darstellen
von Objekten und das Vermeiden unnötiger Leerlaufzeit auf der
Client/Server-Kommunikationsverbindung 14, wodurch Benutzer
das "Gefühl" eines besseren Ansprechverhaltens
bereitgestellt wird.
-
Die
GetProperties()- und SetProperties()-Aufrufe gewinnen und speichern
Informationen über
Cache-gespeicherte Objekte, einschließlich von von dem Transcodierdienstanbieter 24 geführten Informationen,
die zur Bestimmung der Transcodiereigenschaften und des Transcodierstatus
eines Cache-gespeicherten Objektes verwendet werden. Der Transcodierdienstanbieter 24 kann
derartige Informationen beispielsweise zur Bestimmung des aktuellen
Kompressionsfortschritts für
skalierte Daten-Zugriffe
und gestufte Verfeinerungen verwenden.
-
Der
Read()-Aufruf liest Daten aus einem spezifizierten Cache-gespeicherten
Objektdatenstrom. Der Transcodierdienstanbieter 24 kann
beispielsweise diesen Aufruf aufrufen und Stromdaten durch den HTTP-Remote-Proxy 36 direkt
zum Netzwerk-Client 12 hindurch
tunneln. Der Write()-Aufruf speichert Daten aus einem neuen HTTP-Datenstrom
im Cache. Dieser Aufruf hängt
einen beispielsweise von einem Web-Server oder einem Transcodierdienstanbieter 24 empfangenen
eingehenden Datenstrom an einen geöffneten Cache-Strom an, der
gleichzeitig unter Verwendung des Read()-Aufrufs gelesen werden kann.
-
Bei
dem vorliegenden Ausführungsbeispiel umfaßt der Parser 22 die
folgenden Aufrufe:
GetObject (URL, InParams, &OutParams, &OutStream, ...);
GetScaledObject
(URL, InParams, &OutParams, &OutStream, Stage,
...);
PutObject (URL, InParamStruct, &InStream, &OutParams, &OutStream, ...).
-
Wie
unten angegeben verwendet der Parser 22 diese Aufrufe,
um das Bereitstellen von angefordertem Inhalt an den Netzwerk-Client 12 zu
managen.
-
Der
GetObject()-Aufruf wird zur Bedienung von nicht aktivierten Client-Anforderungen
verwendet, und gibt eine nicht-transcodierte
(d. h. ursprüngliche)
Version eines spezifizierten Hypertext-Ojektes zurück. Bei
diesem Ausführungsbeispiel
nimmt der Transcodierserver 34 an, daß jede HTTP-Anforderung einen
einzigartigen Thread aufweist, der blockiert werden kann, bis die
Anforderung erfüllt
ist. Dementsprechend wird der GetObject()-Aufruf blockieren, bis
er entweder den angeforderten Datenstrom zurückgibt oder einen Fehlversuch
mit einer Ursache angibt (z. B. Objekt existiert nicht). Diese Möglichkeit
zur Rückgabe
eines sogenannten Standard-Hypertext-Objektes ist aus Kompatibilitätsgründen vorteilhaft
und ermöglicht,
daß Ausführungsformen
der vorliegenden Erfindung mit existierenden Browsern verwendet
werden, die keine Unterstützung
für eine
bestimmte Transcodierfunktionalität umfassen (z. B. erweiterte
Datenkompression) und ermöglicht
Nutzern selektiv nicht-transcodierte Versionen abzurufen.
-
Der
GetScaledObject()-Aufruf ähnelt
dem GetObject() und wird ebenfalls zum Anfordern eines Objekts von
einem Server seitigen Cache-Speicher 30 verwendet; allerdings
bietet er zusätzlich
eine Unterstützung
für die
Anforderung einer bestimmten Version dieses Objekts, wie beispielsweise
eine Wiedergabe mit hoher Qualität.
Anders als traditionelle Cachespeichernde Proxies können Transcodierdienstanbieter 24 den
Server-seitigen Cache-Speicher 30 zur Speicherung mehrerer
verschiedener Versionen eines Objektes verwenden, um Clients mit verschiedenen
Kommunikations- und/oder Präsentationsmöglichkeiten
zu unterstützen.
Daher kann ein zusätzlicher "Stage"- bzw. Stufen-Parameter
verwendet werden, um anzuzeigen, welche Version des Cache-gespeicherten
Objektes an den Netzwerk-Client zurückgegeben werden soll. Wenn
der Transcodierdienstanbieter 24 zur Skalierung von Netzwerkinhalt konfiguriert
ist, kann er diesen Parameter verwenden, um eine Version eines Cache-gespeicherten Objektes
anzufordern, die beispielsweise eine skalierte Standardqualität, eine
Verfeinerung zu einer hochwertigeren Version oder die ursprüngliche nicht-skalierte Version
hat bzw. ist.
-
Wenn
der Netzwerk-Client 12 ein Hypertext-Objekt anfordert,
verwendet bei diesem Ausführungsbeispiel
der HTTP-Remote-Proxy 36 entweder den
GetObject()- oder den GetScaled-Objekt()-Aufruf (in
Abhängigkeit
davon, ob der Netzwerk-Client 12 skalierte/transcodierte
Datentypen empfangen kann), um das Hypertext-Objekt von dem Parser 22 abzurufen.
Wenn das Hypertext-Objekt nicht gefunden wird, verwendet der Parser 22 den
CreateEntry()-Aufruf, um einen Eintrag (tatsächlich einen Platzhalter) im
Server-seitigen Cache-Speicher 30 für das neue Objekt zu erzeugen.
Der neue Eintrag wird an den HTTP-Remote-Proxy 36 zurückgegeben,
welcher das Hypertext-Objekt vom Internet 18 anfordert. Wenn
ein Datenstrom für
das Hypertext-Objekt
zurückgegeben
wird, ruft der HTTP-Remote-Proxy 36 den Parser 22 mit
Hilfe des PutObject()-Aufrufs auf und führt in diesen Aufruf den neuen
Eintrag ein und das in den Eintrag zu platzierende Handle zu dem Datenstrom.
Der Parser 22 wählt
beispielsweise auf der Basis des Inhaltstyps des Datenstroms einen
geeigneten Transcodierdienstanbieter 24 aus. In diesem
Zusammenhang umfaßt
der Begriff Inhaltstyp einen Datentyp, einen HTTP-MIME (Multipurpose
Internet Mail Extension)-Typ, ein Inhaltsformat usw. Der ausgewählte Transcodierdienstanbieter 24 verwendet
einen separaten Thread zum Lesen des eingehenden Datenstroms, um
diesen zu transcodieren und ihn in dem Eintrag des Server-seitigen
Cache-Speichers 30 zu platzieren. Der aktuelle Thread kehrt
sofort zum HTTP-Remote-Proxy 36 zurück, welcher wiederum GetScaledObject()
(oder GetObject()) aufruft. Dieser Fall wird immer zu einem Cache-Treffer
führen.
Dieser Thread arbeitet dann gleichzeitig mit dem separaten Thread
in dem PutObject(), um (entweder ursprüngliche oder transcodierte)
Daten von dem Transcodierserver 34 zum Netzewerk-Client 12 zu
tunneln.
-
Die
Multithread-Verarbeitung verbessert die Effizienz des vorliegenden
Ausführungsbeispiels
dadurch, daß nicht
gewartet wird, bis ein Hypertext-Objekt ganz von dem HTTP-Remote-Proxy 36 empfangen
wird oder vollständig
in den Server-seitigen Cache-Speicher 30 hinzugefügt wird,
bevor mit dem Senden des Objekts an den Netzwerk-Client 12 begonnen
wird. Ein weiterer Vorteil der Multithread-Verarbeitung besteht
darin, daß der
Parser 22 Anforderungen des gleichen Hypertext-Objektes
von mehreren Netzwerk-Clients 12 effizient verarbeiten
kann. Das Hypertext-Objekt muß nur
einmal aus dem Internet 18 abgerufen werden, und entsprechende
Versionen können
gleichzeitig zu mehreren derartigen Netzwerk-Clients gesendet werden.
Man beachte jedoch, daß Ausführungsformen
der vorliegenden Erfindung ohne Multithread-Verarbeitung implementiert werden
können.
-
Wie
oben erwähnt,
kann der Parser 22 selektiv einen der Transcodierdienstanbieter 24 auf
der Basis der Erfüllung
eines vorgegebenen Auswahlkriteriums aufrufen. Ein derartiges Auswahlkriterium kann
beispielsweise in einem Header-Abschnitt eines von dem Transcodierserver 34 empfangenen Datenpakets
enthaltene Informationen umfassen, beispielsweise MIME-Typ, eine
URL (Uniform Resource Locater bzw. einheitlicher Quellenlokalisierer),
einen Zuletzt-Modifiziert-Zeit-Anzeige usw. Alternativ kann das
vorgegebene Auswahlkriterium in einem Datenabschnitt eines derartigen
Datenpakets enthaltene Informationen umfassen, beispielsweise einen
bestimmten Inhalt, Schlüsselwörter, Strukturen (beispielsweise
Heading-Levels bzw. Überschriftenebenen)
usw. Darüber
hinaus kann das vorgegebene Auswahlkriterim eine Bedingung der Einrichtung
umfassen, auf der der Transcodierserver 34 installiert
ist (beispielsweise eine aktuelle Verarbeitungsbelastung), eine
Bedingung einer Einrichtung, mit der der Transcodierserver 34 gekoppelt
ist oder eine Bedingung einer Kommunikationsverbindung. Der Transcodierserver 34 kann
die Möglichkeit
bereitstellen, ein derartiges vorgegebenes Auswahlkriterium dynamisch
zu aktualisieren.
-
Die
folgende Erörterung
gibt noch weitere Beispiele für
die Arten von Informationen, die verwendet werden können, um
vorzugeben, welche Transcodierdienstanbieter 24 aufgerufen
werden. Man beachte jedoch, daß diese
Beispiele nur zur Veranschaulichung angegeben sind und nicht dazu
dienen sollen, den Schutzbereich der hier beanspruchten Erfindung
zu beschränken.
Das vorgegebene Auswahlkriterium kann umfassen:
(1) für einen
Netzwerk-Client 12, beispielsweise eine Anzeigeabmessung,
Auflösung,
Anzahl von Farbtönen,
Prozessortyp, Speicher/Plattenkonfiguration, Modem- oder Netzwerkschnittstellentyp,
installierte Zusatzplatinen (zum Beispiel Hardware-Kompression/Dekompression),
Softwarekonfiguration (zum Beispiel Verfügbarkeit von vorinstallierten
Software-Dekompressionsmodulen), physikalischer Standort/Nähe (beispielsweise
bestimmt durch eine Telefonvorwahl), und Nutzeridentität; (2) Eigenschaften
des Transcodierservers 34 oder irgend eines anderen Netzwerk-Servers, einschließlich Belastungs-
und Identifikationsinformationen (zum Beispiel den Inhaber des Servers);
(3) Inhaltsmerkmale, beispielsweise dessen Datentyp, Codier/Kompressionstyp,
Größe und Abmessung;
(4) Netzwerkmerkmale, einschließlich
Latentzeit im günstigsten
und ungünstigsten
Fall sowie im Durchschnitt, Bandbreite und/oder Fehlerraten (beispielsweise
für eine
drahtlose Kommunikation) zwischen einem Netzwerk-Client 12 und einem
Proxy, und/oder zwischen einem Proxy und einem Server (dies kann
für garantierte
Band breitenverbindungen vorab bestimmt werden, wie ATM (Asynchronous
Transfer Mode) oder dynamisch gemessen/vorhergesagt werden für sogenannte "best effort" bzw. „beste
Leistung"-Verbindungen
wie viele IP (Internetprotokoll)-Verbindungen); (5) Proxy-Merkmale,
einschließlich
Systembelastung, verfügbarer Speicher,
physikalischer Standort/Nähe,
und Identität (Inhaber);
(6) Benutzerpräferenzen,
einschließlich bevorzugter
Kompromiß zwischen
Inhaltsqualität/Geschwindigkeit,
Sprache, Inhaltsrating, Exklusionsliste, Inklusionsliste, Datentyp-spezifische
Präferenzen
(beispielsweise "Lade
nie Bilder herunter"), Einschließen/Ausschließen von
Werbung, Menge der gewünschten
Werbung, Entfernung von anstößiger Sprache,
ob die definierten oder gelernten Präferenzen des Benutzers offenbart
werden können
(und an wen), kundenspezifische Regeln oder Programme zum Filtern,
Transcodieren, Verarbeiten von Daten und gemeinsame Präferenzen
mit entweder einem anderen Benutzer oder einer Gruppe von Benutzern (alle
voranstehenden Benutzerpräferenzen
können explizit
definiert sein oder auf dem System basieren, beispielsweise auf über die
Zeit zusammengestellten Benutzerstatistiken); (7) Gruppenpräferenzen
einschließlich
der Ergebnisse von gemeinsamen Rating-Systemen, entweder manuell
(z. B. kann ein früherer
Benutzer einer Webseite nach deren Betrachten ein Rating bzw. eine
Bewertung zuweisen) oder automatisch (in Anbetracht einer großen Anzahl
von Benutzern, die auf eine Verknüpfung auf einer vorgegebenen
Seite zugegriffen haben, beispielsweise die Wahrscheinlichkeit,
daß ein
bestimmter Benutzer im folgenden dieser Verknüpfung folgt); (8) Inhaltsanbieterpräferenzen,
u. a. den für
seinen Inhalt gewünschten Änderungsgrad,
die Priorität
zum Herunterladen und Anzeigen für
verschiedene Inhaltstypen, Cache-Beschränkungs- oder -Prioritätsparameter, beispielsweise
Aktualisierungsfrequenz oder Ersatzpräferenzen, die anzusprechenden
Benutzertypen, für kundenspezifischen
Inhalt abzuarbeitende Regeln oder Programme (beispielsweise Nachrichten
oder Werbung, kundenspezifische Sprachübersetzungssoftware) auf der
Basis von Benutzer- oder Client-Merkmalen, den Wunsch zum Empfang
bestimmter Typen von gesammelten Benutzer- oder Gruppendaten (beispiels weise
demografische Muster oder Zugriffsmuster) und die Art der mit dem
Austausch für
derartige Informationen angebotenen Bezahlung/des Entgelts; und
(9) andere Präferenzen, einschließlich Softwareverkäuferregeln
oder Programme zur dynamischen Überprüfung von
mit Hilfe von nicht autorisierter Software erzeugten oder verteilten
Inhalten und des Firmenwunsches, eine korrekte Benutzung von bestimmten
Inhaltsarten durchzusetzen (beispielsweise Marken und Bildzeichen).
-
Bei
Anwendung der oben aufgelisteten Auswahlkriterien oder von Kombinationen
dieser, können Ausführungsformen
der vorliegenden Erfindung verwendet werden, um einen eigentlich
unbegrenzten Bereich von dynamischen Transcodierdientsten bereitzustellen.
Beispielsweise kann physikalische Client- und/oder Proxynähe in Kombination
mit demografischen Daten zur extrem zielgerichteten Werbung verwendet
werden. Derartige Werbung kann zu jedem Inhalt hinzugefügt werden,
der beispielsweise einen Proxy oder einen anderen Mechanismus durchläuft. Dies
kann wiederum noch weiter zugeschnitten werden auf der Basis der
Bereitschaft des Benutzers, Werbung zu tolerieren oder demografische
Informationen gemeinsam zu nutzen, sowie der Möglichkeit/Bereitschaft des
Werbenden, den Benutzer für
seine Teilnahme zu subventionieren oder auf andere Weise zu entgelten.
-
Ausführungsformen
der vorliegenden Erfindung können
vorteilhafterweise zur Reduktion der Datenmenge verwendet werden,
die zum Netzwerk-Client 12 übertragen wird, wodurch ein
schnelleres Herunterladen und eine schnellere Wiedergabe von Inhalt
gefördert
wird. Geeignete Transcodiertechniken umfassen eine verlustbehaftete
Kompression und ein Transcodieren in ein effizienteres (und vielleicht
nicht weit verbreitet unterstütztes)
Format speziell für
die Übertragung.
In ähnlicher
Weise kann der HTTP-Remote-Proxy 36 so konfiguriert werden, daß er Webseiten
oder Gruppen von Webseiten „vorher
zusammenfaßt", um extreme kondensierte Überblicke über große Inhaltsmengen
bereitzustellen (beispielsweise eine Baumstruktur, Seiten mit nur
primären
oder sekundären Überschriften,
Miniatur ansichten von Seiten oder nur Teile einer Seite oder Site, die
sich seit des letzten Besuchs des Benutzers geändert haben). Derartige Anwendungen
können
speziell für
schlecht verbundene oder rechentechnisch beschränkte Einrichtungen, wie beispielsweise
PDAs (Personal Digital Assistant) vorteilhaft sein, da diese kurze
Zusammenfassung auf einem gut angebundenen Proxy-Server mit reichlich Rechenleistung durchgeführt werden
kann, und das genaue Ergebnis leicht auf die weiter eingeschränkten Einrichtung
heruntergeladen und dort wiedergegeben werden kann.
-
Ausführungsformen
der vorliegenden Erfindung können
alternativ zur dynamischen Übersetzung
von Daten, beispielsweise Webseiten, in die Muttersprache eines
Benutzers verwendet werden(, die durch Benutzerpräferenzen
oder automatisch durch den physikalischen Standort des Netzwerk-Clients 12 oder
des Transcodierservers 34 bestimmt wird). Eine derartige
Möglichkeit
vereinfacht die Herausforderung deutlich, Inhalt wirklich global
zu machen, und reduziert ferner den beim Inhaltsanbieter benötigten Speicherplatz
und Wartungsaufwand (d. h. es muß nur eine Kopie gewartet werden,
statt verschiedene Kopien für
eine Mehrzahl von verschiedenen Sprachen).
-
Ausführungsformen
der vorliegenden Erfindung können
verwendet werden, um bestimmte Inhaltsarten zu blockieren oder anstößige Sprache
automatisch zu zensieren (ähnlich
zu einem für
Fernsehübertragungen
verwendeten „Piepton"). Nur die speziell
anstößigen Teile
des Inhalts (beispielsweise obszöne
Wörter)
können
entfernt werden oder es können
ganze Websites blockiert werden. In ähnlicher Weise kann der Transcodierserver 34 so
konfiguriert sein, daß er
den Inhalt auf bestimmte Wörter oder
Fragen durchsucht, um sicherzustellen, daß Marken und Bildzeichen korrekt
verwendet werden (beispielsweise als Hinweis auf die Herkunft statt
als generische Produktbezeichnung). Dieses Merkmal kann als Dienstleistung
Firmen oder Organisationen angeboten werden, welche eine Liste von
Wörtern oder
Phrase an ein Flag liefern würden.
Eine ähnliche Möglichkeit
könnte
verwendet werden, um bei Detektion bestimmter Wörter oder Phrasen automatisch Verknüpfungen
in den Inhalt ein zufügen.
Beispielsweise könnte
es für
die Intel Corporation wünschenswert
sein, automatisch eine Verknüpfung
zu ihrer Firmen-Website hinzuzufügen,
wenn der Name „Intel" in einer Webseite
verwendet wird. Unter Verwendung einer Ausführungsform der vorliegenden
Erfindung können
derartige Verknüpfungen
dynamisch zum Inhalt hinzugefügt
werden, bevor er einem Benutzer angezeigt wird. In einer ähnlichen
Weise kann eine Ausführungsform
der vorliegenden Erfindung zum Suchen nach Inhalt verwendet werden,
der unter Verwendung unlizensierter Software erzeugt oder verteilt
wurde. Dieses Merkmal kann mit Hilfe spezieller Schlüssel (binärer Bitmuster)
implementiert werden, die in die Inhalte oder Header eingebettet
sind, die von der Inhaltserzeugungs- oder Verteilungssoftware eingesetzt
wurden. Die Durchsuchlogik und die Logik zur Ausführung einer
vorgegebenen Erwiderungsaktion, beispielsweise das Verweigern des
Dienstes oder die Absendung einer Warnung, können von dem Verkäufer der
betreffenden Software optional angeboten werden oder in den Transcodierserver 34 hineinkonfiguriert
sein.
-
Ausführungsformen
der vorliegenden Erfindung können
ebenfalls verwendet werden, um den Inhalt auf Computerviren hin
zu untersuchen, bevor dieser Inhalt an den Netzwerk-Client 12 gesendet wird.
Beispielsweise kann eine existierende Virusprüfroutine auf dem Transcodierserver 34 installiert werden,
möglicherweise
als Plug-In-Modul. Der Transcodierserver 34 kann dann so
konfiguriert werden, daß er
die Virusprüfroutine
aufruft, um sicherzustellen, daß jeder
an den Netzwerk-Client 12 gesendeter Inhalt virusfrei ist.
Ein signifikanter Vorteil einer derartigen Ausführungsform ist, daß die Virusprüfsoftware
nur auf dem Transcodierserver 34 gewartet werden muß und nicht
auf einer Mehrzahl von Netzwerk-Clients 12. Auf diese Weise
kann der Vorteil von Aktualisierungen der Virusprüfsoftware
effizient und schnell einer großen
Anzahl von Benutzern zugute kommen, wodurch das Problem vermieden wird,
daß sich
ein bestimmter Benutzer auf eine veraltete Virusprüfsoftware
verläßt.
-
Ausführungsformen
der vorliegenden Erfindung können
ferner verwendet werden, um kundenspezifischen Inhalt auf Verlangen gemäß benutzerspezifischer
Präferenzen
und/oder gemäß Zuordnungen
zu gemeinsamen Rating-Systemen zu erstellen. Bei einer Variante
einer derartigen Ausführungsform kann
der Transcodierserver 34 Präferenzen sammeln und diese
als Teil einer Client-Anforderung anhängen, die an einen Inhaltsanbieter
gesendet wird, so daß die
dynamische Inhaltserzeugung an dem Inhaltsserver ausgeführt werden
kann. In ähnlicher weise
kann ein Proxy-Provider (beispielsweise ein Internet Service Provider
(ISP)) Informationen sammeln und Inhaltsanbietern zur Verfügung stellen,
beispielsweise Benutzerpräferenzen
und Datenzugriffsstatistiken sowie Inhaltsanbieter-spezifische Statistiken
(beispielsweise, wie viele Benutzer aus einer vorgegebenen Region
oder mit einem vorgegebenen Profil auf eine bestimmte Website zugegriffen
haben und zu welcher Zeit im letzten Monat). Derartige Informationen
können
für Anwendungen,
wie zielgerichtete Werbung verwendet werden.
-
Ausführungsformen
der vorliegenden Erfindung können
ferner zur automatischen Überprüfung der
Gültigkeit
von Verknüpfungen
in einem Objekt verwendet werden und zum Korrigieren oder Entfernen
von ungültigen
Verknüpfungen,
bevor das Objekt zum Netzwerk-Client 12 übertragen
wird. Diese Möglichkeit
kann beispielsweise als Dienst Inhaltsanbietern zur Verfügung gestellt
werden, die möglicherweise
nicht die aktuellsten Informationen auf Websites haben, mit denen
sie verknüpft
sind und die verlegt oder gelöscht
wurden.
-
Zur
weiteren Veranschaulichung der allgemeinen Funktionsweise des in 3 veranschaulichten
Ausführungsbeispiels
sei angenommen, daß ein Nutzer
eines Netzwerk-Clients 12 auf eine bestimmte Webseite oder
URL (Uniform Resource Locator) im Internet 18 zugreifen
möchte.
Es sei ferner angenommen, daß sich
die gewünschte
URL auf dem Transcodierserver 34 befindet oder durch diesen
zugänglich
ist. Der Netzwerk-Client 12 sendet mit Hilfe des Browsers 32 eine
das Hypertext-Objekt betreffende HTTP-Anforderung über die
Client-Server-Kommunikationsverbindung 14 an den Transcodierserver 34. Wenn
der Browser 32 normalerweise über einen Proxy auf das Internet 18 zugreift,
ist der Browser 32 so konfiguriert, daß er alle Nut zeranforderungen
durch den Transcodierserver 34 über die Standard-Proxy-Konfigurationsprozedur
des Browsers 32 leitet. Wie im Stand der Technik bekannt
ist, kann der Browser 32 tatsächlich mehrere zusätzliche
HTTP-Anforderungen senden, die jeweils mehreren verschiedenen Hypertext-Objekten
zugeordnet sind, die in die Webseite eingebettet sein können. In
einem derartigen Fall kann der Transcodierserver 34 jede
derartige Anforderung in der weiter unten beschriebenen Weise verarbeiten.
-
Gemäß diesem
Ausführungsbeispiel
kann der HTTP-Remote-Proxy 36 zwischen
einem nicht aktivierten Netzwerk-Client 12 und einem aktivierten Netzwerk-Client 12 unterscheiden.
Dies kann beispielsweise unter Verwendung eines privaten Protokolls
zum Senden von Inhaltsanforderungen von einem aktivierten Netzwerk-Client
zu dem Transcodierserver 34 ausgeführt werden, so daß die Verwendung
eines anderen Kommunikationsprotokolls anzeigt, daß der Netzwerk-Client 12 nicht
aktiviert ist. Dieses Verfahren des Sendens eines privaten Protokolls
in jeder Anforderung an den HTTP-Remote-Proxy 36 ist eine
Verbesserung gegenüber
einen Prozeß vom
Registrierungstyp. Der erforderliche Overhead für die Aktiviert/Nicht-Aktiviert-Bestimmung
pro Anforderung ist relativ klein, während ein beträchtlicher Vorteil
geboten wird, da die Situation für
den HTTP-Remote-Proxy 36 behandelt wird, in der ein erster
Netzwerk-Client die Verbindung trennt und ein zweiter Netzwerk-Client
unter Verwendung der gleichen IP-Adresse erneut eine Verbindung
herstellt, der wahrscheinlich andere Kommunikations- und Präsentationsmöglichkeiten
hat.
-
Bei
der Bestimmung, daß der
Netzwerk-Client 12 nicht aktiviert ist, kann der HTTP-Remote-Proxy 36 die
IP-Adresse des Netzwerk-Clients in einer Client-Präferenztabelle 36 aufzeichnen,
die in einem lokalen Datenspeicher geführt wird (die Client-Präferenztabelle 26 kann
die Leistungsfähigkeit
dieser Ausführungsform
oder einer anderen verbessern, ist jedoch nicht erforderlich). Der
HTTP-Remote-Proxy 36 leitet das Hypertext-Objekt dann an
den Parser 22 weiter. Der HTTP-Remote-Proxy 36 kann den Parser 22 auch über alle
anwendbaren Nutzerpräferenzen informieren
(z. B. aus der Client-Präferenztabelle 26).
Nach dem Aufruf ruft der Parser 22 zunächst die Cache-Schnittstelle 28 mit
dem angeforderten Hypertext-Objekt auf, um zu bestimmen, ob sich
bereits eine Kopie der angeforderten Version in dem Server-seitigen
Cache-Speicher 30 befindet. Zur Veranschaulichung sei angenommen,
daß in
dem Serverseitigen Cache-Speicher 30 kein Eintrag für das angeforderte
Hypertext-Objekt existiert. Der HTTP-Remote-Proxy 36 ruft
dann einen Aufruf zum Abrufen des Hypertext-Objektes über die
Server/Netzwerk-Kommunikationsverbindung 18 aus dem Internet 18 ab.
Es sei angenommen, daß das
angeforderte Hypertext-Objekt gefunden wird. Der HTTP-Remote-Proxy 36 beginnt
mit dem Empfang eines HTTP-Datenstroms, der das Hypertext-Objekt
darstellt. Der HTTP-Remote-Proxy 36 leitet das Handle für diesen
eingehenden Datenstrom an den Parser 22 weiter.
-
Der
Parser 22 bestimmt dynamisch, ob dieser Datenstrom irgendein
anwendbares vorgegebenes Auswahlkriterium erfüllt. Wenn beispielsweise die
Transcodierdienstanbieter 24 so konfiguriert sind, daß sie Daten
von verschiedenen Typen einstufen, kann der Parser 22 den
Inhaltstyp für
den Datenstrom bestimmen (z. B. Bild/jpeg, Bild/gif, Video/mpeg),
indem er einen MIME-Typ
in dem Inhaltstyp-Header-Datensatz abfragt, der am Anfang des eingehenden
HTTP-Datenstroms erscheint. Wenn der Parser 22 eine Übereinstimmung
für ein
vorgegebenes Auswahlkriterium erfaßt, wird das HTTP-Strom-Handle
an den entsprechenden Transcodierdienstanbieter 24 gegeben.
Der Transcodierdienstanbieter 24 trancodiert dann den Datenstrom entsprechend,
und der HTTP-Remote-Proxy 26 sendet den transcodierten
Datenstrom an den Netzwerk-Client 12.
-
Ein
nicht aktivierter Netzwerk-Client 12 kann optional mit
der Möglichkeit
versehen werden, aktiv Aspekte des Transcodierprozesses zu steuern,
oder tatsächlich
zu steuern, ob der angeforderte Inhalt überhaupt transcodiert werden
soll. Zur Bereitstellung dieser Möglichkeit kann der HTTP-Remote-Proxy 36 zusätzliche
Befehle zu Beginn des HTML-Headers für die angeforderte URL einbetten,
bevor der zugehörige
Datenstrom an den Netzwerk-Client 12 übertragen wird. Diese eingebetteten Befehle
können
beispielsweise als Javascript-Codes, VB-Script-Codes oder Java-Applet-Codes implementiert
werden. Wenn der Browser 32 des Netzwerk-Clients 12 den
Datenstrom empfängt,
werden die eingebetteten Befehle automatisch ausgeführt, sofern
der Browser 32 zu deren Unterstützung ausgerüstet ist. Wenn
die eingebetteten Befehle beispielsweise als Javascript-Codes implementiert
sind, kann der Browser 32 ein Javascriptfähiger Browser
wie Netscape Navigator v.2.0 oder ein höherer Browser sein, oder ein
Internetexplorer v.3.0 oder ein höherer Browser. Wenn der Browser 32 nicht
für ein
derartiges HTML-Skripting
ausgerüstet
ist, stören
die eingebetteten Befehle die normale Verarbeitung des Browsers 32 nicht,
da derartige Browser 32 normalerweise so konfiguriert sind,
daß sie
alle Daten ignorieren, die sie nicht interpretieren können.
-
Die
an den Netzwerk-Client 12 gesendeten eingebetteten Befehle
können
dem Benutzer ermöglichen,
einige der Transcodiermöglichkeiten
des Transcodierservers 34 zu manipulieren. Wie in 4 dargestellt
ist, können
die eingebetteten Befehle eine Benutzerschnittstelle in Form eines
Pop-Up-Fensters 40 ansteuern, das oben in einem Browser-Fenster 38 angezeigt
wird. Das Pop-Up-Fenster 40 umfaßt einen Schalter 42 mit
drei Zuständen
mit den Einstellungen „EIN", „AUS" und „AUTO", und kann ferner eine
Hypertextverknüpfung 40 enthalten,
der der Nutzer folgen kann, um speziell Client-Software herunterzuladen,
um beispielsweise eine leistungsstärkere Transcodierfunktionalität zu unterstützen (d.
h. um „aktiviert" zu werden). Die
Anfangseinstellung des Dreizustandsschalters 42 kann auf
einer vorherigen Bestimmung durch den HTTP-Remote-Proxy 36 basieren,
ob der Netzwerk-Client 12 eine feststehende Präferenz für den Empfang
von transcodiertem Inhalt hat. Falls dies der Fall ist, kann der
Dreizustandsschalter 42 auf „EIN" gesetzt werden, falls nicht, kann der
Dreizustandsschalter 42 auf „AUS" gesetzt werden. Ein Ziel dieses Merkmals
ist es, dem Nutzer die Möglichkeit
zu bieten, dem HTTP-Remote-Proxy 36 eine Präferenz mitzuteilen,
die Aspekte von bestimmten Transcodiermerkmalen betrifft, beispielsweise
einen Inhaltsqualitäts/Latenzzeit-Kompromiß, wenn das
Transcodieren die Daten kompression/-skalierung umfaßt. Den
Fachleuten wird es klar sein, daß viele andere Mittel zur Bereitstellung
dieser Möglichkeit
denkbar sind und daß derartige
andere Mittel dem Nutzer ermöglichen
könnten,
Präferenzen
mitzuteilen, die über
eine einfache Ja/Nein-Angabe zum Transcodieren hinausgehen.
-
Wie
in 4 dargestellt ist, ermöglicht das Pop-Up-Fenster 40 dem
Benutzer seine oder ihre Präferenz
im Hinblick darauf zu ändern,
ob transcodierter Inhalt oder ursprünglicher Inhalt gewünscht wird,
und es teilt derartige Änderungen
dem HTTP-Remote-Proxy 36 mit. Das Pop-Up-Fenster 40 kann
mit dem Browser 32 wechselwirken oder nicht, was bedeutet,
daß die
Präferenz
des Nutzers sich nur dann auswirkt, wenn der Dreizustandsschalter 42 eingestellt
wird und auf die Schaltfläche 46 „NEULADEN" des Browsers 32 geklickt
wird, um zu veranlassen, daß der
Browser 32 den (transcodierten oder nicht transcodierten)
Inhalt zur Präsentation
für den Nutzer
anfordert. Nachfolgende Seiten in der aktuellen Sitzung können dann
entsprechend der neuen Einstellung des Dreizustandsschalters 42 ohne
weitere Zwischenschaltung des Nutzers wiedergegeben werden. Der
HTTP-Remote-Proxy 36 kann bei Empfang die Nutzerpräferenztabelle 26 entsprechend
aktualisieren. Alternativ kann das Pop-Up-Fenster 40 so
konfiguriert werden, daß es
automatisch die „NEULADEN"-Operation aufruft,
wenn der Benutzer eine Änderung
angibt (beispielsweise durch Umschalten des Dreizustandsschalters 42).
Wenn der Browser 32 ein Javascript-fähiger Browser ist, können von
dem HTTP-Remote-Proxy 36 in das HTML-Dokument eingefügte Javascript-Befehle den Zustand
des Dreizustandsschalters 42 an den HTTP-Remote-Proxy 36 senden
und ferner den Browser 32 zum „NEULADEN" der aktuellen URL veranlassen.
-
Einem
nicht aktivierten Netzwerk-Client 12 kann ermöglicht werden,
daß er
den Zustand des Dreizustandsschalters 42 auf dem Netzwerk-Client 12 über mehrere
Sitzungen des Browsers 32 speichert, und zwar unter Verwendung
einer Datei, die im Stand der Technik als „Cookie" bekannt ist. Mit anderen Worten ein
Cookie kann zur ständigen
Speicherung des Zustands des Dreizustandsschalters 42 verwendet
werden. Wenn eine neue Sitzung des Browsers 32 von einem
Nutzer initiiert wird, können diese
Zustandsinformationen von dem Netzwerk-Client 12 gelesen
werden und von dem Javascript-Code (der zu Beginn des HTML-Dokuments
eingefügt
ist) an den HTTP-Remote-Proxy 36 „GESENDET" bzw. „POSTed" werden, bevor irgendein Inhalt für das angeforderte
Hypertext-Objekt tatsächlich
an den Netzwerk-Client 12 gesendet wird. Dies ermöglicht dem HTTP-Remote-Proxy 36,
die Benutzerpräferenztabelle 26 mit
dem richtigen Zustand des Dreizustandsschalters 42 zu aktualisieren
und somit richtig transcodierten Inhalt an den Netzwerk-Client zu
senden. Bei einem derartigen Ausführungsbeispiel können die
Zustandsinformationen jedes Mal dann an den HTTP-Remote-Proxy 36 „GESENDET" bzw. „POSTed" werden, wenn eine
bestimmte URL von dem Browser 32 angefordert wird. Dies
ermöglicht
dem Netzwerk-Client 12 den Empfang von richtig transcodiertem
Inhalt, selbst wenn der HTTP-Remote-Proxy 36, mit dem er
gekoppelt ist, wechselt, beispielsweise aufgrund einer Veränderung
des geografischen Standorts des Netzwerk-Clients 12 oder
aufgrund von Prozeduren zum Netzwerklastausgleich.
-
Die
in 3 gezeigte Ausführungsform kann auch für Netzwerk-Clients 12 verwendet
werden, die bereits über
einen Standard-Proxy auf das Internet 18 zugreifen. Javascript
fähige
Browser 32 können die
lokale IP-Adresse des Netzwerk-Clients 12 abfrage
und diese Informationen an den HTTP-Remote-Proxy 36 „SENDEN" bzw. „POSTen". Der HTTP-Header dieser „POST"-Nachricht enthält die IP-Adresse
des Standard-Proxy, die sich nun von der IP-Adresse des Netzwerk-Clients 12 unterscheidet (die
im Inhalt der Nachricht enthalten ist). Ein Vergleich der beiden
IP-Adressen ergibt, ob sich der Netzwerk-Client 12 hinter einem Standard-Proxy
befindet. Der HTTP-Remote-Proxy
kann diese Informationen dann zur Aktualisierung der Transcodierinformationen über den
Netzwerk-Client 12 in der Nutzerpräferenztabelle 26 verwenden.
-
Gemäß einem
anderen Ausführungsbeispiel der
vorliegenden Erfindung, das in 5 dargestellt ist,
kann der Netzwerk-Client 12 „aktiviert" (befähigt) sein
und spezialisierte Software enthalten, um beispielsweise höher entwickelte
Transco diermerkmale als diejenigen der oben beschriebenen Ausführungsformen
zu unterstützen
oder um einige oder alle Transcodierfunktionen auf der Client-Seite
auszuführen.
Wie dargestellt ist, enthält
der Netzwerk-Client 12 einen lokalen HTTP-Proxy 48,
der mit einem Client-seitigen Parser 50 gekoppelt ist,
der ähnlich
wie der Parser 22 des Tanscodierservers 34 einen
oder mehrere Client-seitige Transcodierdienstanbieter 52 steuert.
Jeder Transcodierdienstanbieter 52 kann so konfiguriert
sein, daß er
beispielsweise Inhalt transcodiert, bevor er ihn für einen
Benutzer wiedergibt oder daß er
eine komplementäre
Transcodierfunktion (z. B. Decodieren, Dekompression) im Hinblick
auf eine von einem entsprechenden Transcodierdienstanbieter 24 des
Transcodierservers 34 ausgeführte Funktion ausführt. Wie
bei dem Transcodierserver 34 kann der Netzwerk-Client 12 einen
Client-seitigen Cache-Speicher 56 enthalten, der über eine
Client-seitige Cache-Schnittstelle 54 gemanagt wird. Die
Client-seitige Cache-Schnittstelle 54 kann eine bereits
existierende von dem Betriebssystem unterstützte Einrichtung sein, beispielsweise
WININET. Die Verwendung einer existierenden Einrichtung zum Cache-Speichern
verringert die Softwaremenge, die zum Netzwerk-Client 12 heruntergeladen werden
muß, um
diese Ausführungsform
zu implementieren, und ermöglicht
ferner anderen Anwendungen, beispielsweise nicht verbundenen Browsern,
den Client-seitigen Cache-Speicher 56 mit zu benutzen.
-
Der
lokale HTTP-Proxy 48, der Client-seitige Parser 50 und
die Client-seitigen Transcodierdienstanbieter 52 (gemeinsam
Client-Software genannt) können
zum Netzwerk-Client 12 auf Anforderung heruntergeladen
werden, beispielsweise durch Klicken einer Hypertext-Verknüpfung 44,
welche durch das in 4 dargestellte Pop-Up-Fenster 38 dargestellt
ist. Alternativ kann die Client-Software auf einem tragbaren Speichermedium,
beispielsweise einer Diskette oder einer CD-ROM an Nutzer verteilt werden,
oder sie kann auf einem Standard-Personalcomputer vorgeladen sein.
Bei der Ausführungsform gemäß 5 sind
die Client-Software und der Browser 32 getrennt ausgeführt; jedoch
kann die Client-Software bei noch einer anderen Ausführungsform
in den Browser 32 integriert sein (siehe 6).
-
Die
Ausführungsformen
mit aktiviertem Client bieten dem Netzwerk-Client 12 eine
erweiterte Flexibilität
für die
Wiedergabe von Hypertextobjekten. Wie bei den oben beschriebenen
Ausführungsformen
mit nicht aktiviertem Client, kann der aktivierte Netzwerk-Client 12 einen
transcodierten Datenstrom von dem HTTP-Remote-Proxy 36 in
einem Format empfangen, das bereits von der internen Standardwiedergabesoftware
des Browsers 32 unterstützt
wird (z. B. JPG, GIF). Dies wäre
beispielsweise der Fall, wenn der Transcodierprozeß das Hinzufügen oder
Löschen
von Text im Hypertext-Objekt umfaßte. Darüber hinaus kann der HTTP-Remote-Proxy 36 ein
Hypertext-Objekt zu einem Datenstrom mit einem neuen MIME-Typ transcodieren,
beispielsweise dort, wo der Transcodierprozeß ein Skalieren oder eine Datenkompression
enthält,
in welchem Fall ein Client-seitiger Transcodierdienstanbieter 52 vorgesehen
werden könnte,
um den Datenstrom zurück
zu einem vom Browser 32 unterstützten MIME-Typ zu konvertieren.
Beispielsweise könnte der
HTTP-Remote-Proxy 36 eine
Datei an den Netzwerk-Client 12 senden, die unter Verwendung
eines nicht standardmäßigen und
nicht gut unterstützten, sondern
eines Vorderflankenkompressions-Algorithmus komprimiert wurde, und
der Client-seitige Transcodierdienstanbieter 52 könnte die
Datei zurück
in ihr ursprüngliches
Format dekomprimieren. Diese Vorgehensweise hat den Vorteil, daß sie den
lokalen HTTP-Proxy 48 von der Notwendigkeit einer Benutzerschnittstelle
befreit, und sie beseitigt Beschränkungen, die durch Begrenzungen
der vom Browser 32 unterstützten Datentypen verursacht
werden. Auf diese Weise kann der Transcodierprozeß für Nutzer, Browser
und Web-Server selbst dann transparent bleiben, wenn eine Veränderung
des Inhalts in andere Datentypen damit verbunden ist.
-
Noch
eine weitere Möglichkeit
besteht darin, daß der
aktivierte Netzwerk-Client 12 ein oder mehrere Add-Ins 46 enthält, die
speziell zum Transcodieren, Wiedergeben oder Abspielen von von dem
Netzwerk-Client 12 empfangenem Inhalt konfiguriert sind. Add-Ins 46 können beispielsweise
unter Verwendung von Netscape-Plug-Ins oder ActiveX-Controls implementiert
werden. Darüber
hinaus können
Add-Ins 46 als Teil der Client-Software installiert werden,
wie in 5 dargestellt ist, oder in den Browser 32 integriert
werden. Derartige Add-Ins 46 sind insofern vorteilhaft,
daß sie
im allgemeinen so konfiguriert werden können, daß sie einem Nutzer das Anklicken
auf einem speziellen Objekt zum Erhalt einer Darstellung einer anderen
Version (z. B. mit einer höheren
Qualität)
ermöglichen.
Add-Ins 46 sind
ferner vorteilhaft im Hinblick darauf, daß sie für einen Nutzer in den Browser 32 integriert
erscheinen und leicht aktualisierbar sind. Auch Kombinationen der
oben beschriebenen Darstellungsmöglichkeiten
sind denkbar.
-
Bei
einer vorteilhaften optionalen Anwendung von Add-Ins 46 kann
der Netzwerk-Client 12 so konfiguriert sein, daß er das
Herunterladen eines geeigneten Add-Ins 46 von dem HTTP-Remote-Proxy 36 für den Fall
anfordert, daß der
Netzwerk-Client 12 bestimmt,
daß er
einen bestimmten empfangenen Datenstrom nicht transcodieren kann.
Der HTTP-Remote-Proxy 36 könnte dann das erforderliche
Add-In 46 herunterladen oder alternativ den Datenstrom
in einem anderen Format neu senden. Diese Möglichkeit schafft eine automatische
Erweiterung des Systems und stellt sicher, daß die Client-Software so aktuell
wie möglich
ist.
-
Bei
der Ausführungsform
gemäß 5 ist der
Browser 32 so konfiguriert, daß er alles HTTP-Anforderungen über den
lokalen HTTP-Proxy 48 sendet, wodurch er dem lokalen HTTP-Proxy 48 ermöglicht,
das Abrufen und die Wiedergabe von angeforderten Hypertext-Objekten
zu verbessern. Wenn beispielsweise der lokale HTTP-Proxy 48 eine HTTP-Anforderung
für ein
einer Webseite zugeordnetes Hypertext-Objekt von dem Browser 32 empfängt, leitet
er die URL an die Client-seitige Cache-Schnittstelle 54 weiter, um
zu überprüfen, ob eine
Kopie des Hypertext-Objektes im Client-seitigen Cache Speicher 56 bereits
existiert. Wenn das Hypertext-Objekt bereits im Cache gespeichert
ist, leitet der lokale HTTP-Proxy 48 das Cache gespeicherte Objekt
zur Wiedergabe an den Browser 32 weiter. Wenn das angeforderte
Hypertext-Objekt nicht im Cache gespei chert ist, sendet der lokale
HTTP-Proxy 48 eine HTTP-Anforderung zur Verarbeitung an
den Transcodierserver 34. Der lokale HTTP-Proxy 48 kann
eine übliche
Anforderung Get() zu diesem Zweck verwenden, um dem Transcodierserver 34 zu ermöglichen,
den Network-Client 12 als aktiviert zu identifizieren.
Wenn die oben beschriebene Verarbeitung in Bezug auf andere Ausführungsformen
ausgeführt
wird, gibt der Transcodierserver 34 eine Datenstrom für das Hypertext-Objekt
an den lokalen HTTP-Proxy 48 zurück.
-
Zur
weiteren Veranschaulichung der Merkmale und Vorteile der Ausführungsformen
der vorliegenden Erfindung dienen die in den 7 – 9 bereitgestellten
Flußdiagramme,
die die Logik für eine
Ausführungsform
eines Verfahrens darstellen, mit dem ein aktivierter Netzwerk-Client
ein sich im Internet befindendes Hypertext-Objekt wiedergeben kann.
Die Flußdiagramme
sollen nicht die gesamte ausgeführte
Verarbeitung vollständig
wiedergeben, sondern sollen nur den Gesamtablauf des Verfahrens
beschreiben. Detaillierte Erläuterungen
der verschiedenen Prozesse wurden weiter oben unter Bezugnahme auf
die verschiedenen beschriebenen Ausführungsformen gegeben. Wo es
sich als zweckmäßig erweist,
enthält
die folgende Beschreibung Bezugszeichen für zuvor beschriebene Strukturelemente,
obwohl das Verfahren nicht auf diese Strukturen beschränkt ist.
-
Es
wird nun auf 7 Bezug genommen. Die Verarbeitung
beginnt, wenn ein Nutzer an einem Netzwerk-Client 12 ein
Hypertext-Objekt vom Browser 32 anfordert (Schritt 100).
Dies könnte
in Form einer Anforderung einer speziellen Webseite geschehen, in
der mehrere Hypertext-Objekte dem Nutzer wahrscheinlich angezeigt
werden, oder in Form eines Anklickens eines bereits dem Nutzer angezeigten
Bildes. Der Browser 32 kann so konfiguriert sein, daß er alle
HTTP-Anforderungen über
den lokalen HTTP-Proxy 58 leitet, so daß der lokale HTTP-Proxy 48 die
HTTP (URL)-Anforderung vom Browser 32 abfangen kann (Schritt 110).
-
Bei
dieser speziellen Ausführungsform
prüft der
lokale HTTP-Proxy 48 zunächst, ob das angeforderte Hypertext-Objekt in
dem Client-seitigen Cache-Speicher 56 existiert (Schritt 120).
Dazu kann der lokale HTTP-Proxy 48 den Client-seitigen
Parser 50 aufrufen, und zwar mit Hilfe eines Aufrufs GetScaledObject
(URL), welcher wiederum einen Aufruf GetEntry an die Client-seitige
Cache-Schnittstelle 54 ausgibt, um einen Strom für das Cache-gespeicherte Objekt
zu öffnen.
Dies führt
zum effektiven „Abrufen" des Cache-gespeicherten
Objektes von dem Client-seitigen Cache-Speicher 56, sofern
es existiert (Schritt 140). Der lokale HTTP-Proxy 48 leitet
den Strom dann an den Browser 32 weiter, welcher das Cache-gespeicherte
Objekt dem Nutzer anzeigt (Schritt 150).
-
Es
wird nun auf 8 Bezug genommen. Wenn das angeforderte
URL-Objekt nicht in dem Client-seitigen Cache-Speicher 56 gefunden
wird, sendet der lokale HTTP-Proxy 48 eine Anforderung
für das
Objekt an den Transcodierserver 34, und zwar beispielsweise
unter Verwendung des Absendens bzw. Postings eines Aufrufs GetStage
(URL, Stufe = 0) (Schritt 160). Beim Empfang dieses Aufrufs
ruft der HTTP-Remote-Proxy 36 einen Parser 22 auf,
welcher wiederum einen Aufruf GetScaledObject() an eine Server-seitige
Cache-Schnittstelle 28 sendet, um festzustellen, ob eine
transcodierte Version des angeforderten Hypertext-Objektes bereits
in dem Server-seitigen Cache-Speicher 30 existiert (Schritt 170).
Wenn das Hypertext-Objekt Cache-gespeichert ist, gibt die Server-seitige
Cache-Schnittstelle 28 einen Aufruf GetEntry aus, um einen
Strom für
das Cache-gespeicherte Objekt zu öffnen (Schritt 200).
Zusätzlich
kann der Parser 22 einen Aufruf GetProperties (URL, ...)
an die Server-seitige Cache-Schnittstelle 28 ausgeben,
um Informationen über
die Transcodiereigenschaften und den Transcodierstatus (wie beispielsweise
den Verfeinerungsgrad) des Cachegespeicherten Objekts abzurufen.
-
Wenn
der Parser 22 bestimmt, daß das angeforderte Hypertext-Objekt
nicht in dem Server-seitigen Cache-Speicher 30 existiert,
gibt der HTTP-Remote-Proxy 36 eine HTTP-Anforderung aus,
um das Hypertext-Objekt aus dem Internet 18 abzurufen (Schritt 190).
Wenn das Objekt nicht gefunden wird, gibt der HTTP-Remote-Proxy 36 einen
Fehler an den Netzwerk-Client 12 zurück, dessen Browser 32 es dem
Nutzer mitteilen wird (Schritt 220); wenn das Objekt gefunden
wird, leitet der HTTP-Remote-Proxy 36 das
Handle für
den eingehenden Datenstrom an den Parser 22 weiter, welcher
wiederum die Cache-Speicherung einer ursprünglichen Version des abgerufenen
Hypertext-Objektes initiiert (Schritt 230).
-
Es
wird nun auf 9 Bezug genommen. Sobald der
Erhalt des angeforderten Hypertext-Objektes begonnen hat, bestimmt
der Parser 22, ob das Objekt vor dessen Sendung an den
Netzwerk-Client 12 zu transcodieren ist (und wie) (Schritt 240).
Sowohl der Prozeß der
Entscheidung als auch beispielhafte Transcodierprozesse sind detailliert
oben beschrieben. Aus Gründen
der vorliegenden Veranschaulichung sei angenommen, daß der Parser 22 bestimmt
hat, daß das
Transcodieren richtig sei und daher eine transcodierte Version des
angeforderten Hypertext-Objektes erzeugt hat (Schritt 250).
Der HTTP-Remote-Proxy 36 sendet einen Datenstrom für das transcodierte
Hypertext-Objekt
an den Netzwerk-Client 12 (Schritt 260). Bei Empfang
initiiert der lokale HTTP-Proxy 48 die Cache-Speicherung
des transcodierten Hypertext-Objektes (Schritt 270). Zusätzlich bestimmt
der Client-seitige Parser 50, ob eine weitere Verarbeitung
erforderlich ist, bevor das Hypertext-Objekt wiedergegeben wird
(z. B., ob ein neuer MIME-Typ von dem Transcodierserver 34 eingerichtet
wurde) (Schritt 280).
-
Sofern
keine zusätzliche
Transcodierung erforderlich ist, leitet der lokale HTTP-Proxy 48 das Handle
für den
empfangenen Datenstrom an den Browser 32 zur Anzeige für den Nutzer
weiter (Schritt 290). Sofern eine zusätzliche Transcodierung erforderlich
ist, leitet der Client-seitige Parser 50 das Handle an
einen entsprechenden Transcodierdienstanbieter 52 weiter
(Schritt 300). Das Ergebnis dieser letzteren Verarbeitung
kann ein Hypertext-Objekt sein, das der Browser 32 dem
Nutzer leicht anzeigen kann (Schritt 320) oder das Ergebnis
kann ein Hypertext-Objekt sein, das einen MIME-Typ hat, der kein
Standard ist, wobei der Browser 32 in diesem Fall ein Add-In 46 zur
Anzeige des Objekt aufrufen kann (Schritt 330).
-
Gemäß einer
anderen Ausführungsform
der vorliegenden Erfindung müssen
zusätzliche
Daten oder Programme nicht notwendigerweise als Teil einer Antwort
auf eine Client-Anforderung angefügt werden. Statt dessen können Daten
und Programme transparent zum Netzwerk-Client 12 „geschoben" werden, und zwar
ohne Detektion oder Intervention des Nutzers oder der Software des
Browsers 32. Ein Vorteil dieser Vorgehensweise ist, daß der Transcodierserver 34 detektieren
kann, wann die Client-Server-Kommunikationsverbindung 14 nicht
voll ausgenutzt ist, und somit Daten zum Netzwerk-Client 12 mit einem
begrenzten Risiko einer Störung
mit anderen Transaktionen schieben kann. Eine besonders vorteilhafte
Ausführungsform
verwendet wenigstens einen lokalen Proxy, der seine eigenen Anforderungen (statt
vom Nutzer gesteuert zu werden) an Inhaltsanbieter oder vernetzte
Proxy-Server ausgeben könnte, oder
unaufgeforderte Daten empfangen könnte, die vom Netzwerk zu ihm
geschoben wurden. Der lokale Proxy kann die Daten in einem Client-seitigen
Cache-Speicher speichern, sie als Programm installieren oder den
Nutzer auffordern, eine weitere Aktion auszuführen. Für eine derartige Ausführungsform sind
viele möglichen
Anwendungen denkbar. Beispielsweise kann ein Werbetreibender für Softwareprodukte
oder Musik auf den Netzwerk-Client 12 Testversionen von
Produkten vorladen, bevor er den Nutzer mit einer Anzeige auffordert,
wodurch eine sofortige Abspielmöglichkeit
geschaffen wird, ohne daß der
Benutzer auf das Herunterladen einer Demo warten muß (und möglicherweise
in der Zwischenzeit das Interesse verliert).
-
Viele
verschiedene Konfigurationen sind zur Implementierung von Ausführungsformen
der vorliegenden Erfindung möglich.
In einer ersten Konfiguration ist die einzige zusätzliche
Einrichtung, die erforderlich ist, ein Remote-Proxy. Das heißt, es muß keine
neue Software auf dem Netzwerk-Client 12 installiert werden.
Der Remote-Proxy kann irgendwo in einem geeigneten Netzwerk, beispielsweise
dem Internet angeordnet werden, insbesondere an speziellen Standorten
von Inhaltsanbietern. Alternativ kann der Remote-Proxy an dem lokalen
POP (Point Of Presence) bzw. im lokalen Einwahlknoten angeordnet sein,
bei spielsweise, wenn standortspezifische Merkmale als vorgegebenes
Auswahlkriterium verwendet werden. Selbstverständlich können derartige Informationen
mit anderen Verfahren genauso gesammelt werden, wie beispielsweise
mit Nutzerpräferenzeinstellungen
oder mit dem Zuweisen von standortspezifischen Domänennamen
zu Proxies. In einer zweiten Konfiguration kann eine neue als lokaler
Proxy agierende Software beispielsweise auf einer Client-Einrichtung
installiert werden. Der Nutzer würde dann
den Proxy der Client-Anwendung auf den lokalen Host hinweisen. Kombinationen
dieser beispielhaften Konfigurationen sind ebenfalls möglich. Außerdem können gleichzeitig
mehreren Knoten aktiv sein (beispielsweise ein lokaler Proxy, der
für einige Anforderungen
als Durchleitung wirkt und für
andere, die die Verwendung eines Remote-Proxy erfordern, als Keine-Durchleitung).
-
Sofern
der Netzwerk-Client 12 mit einem Remote-Proxy über eine
relativ langsame Kommunikationsverbindung verbunden ist, kann es
besonders vorteilhaft sein, auf Remote-Proxies ein Transcodieren
und eine Verbindungsgültigkeitsüberprüfung zu implementieren.
Kombinationen von entfernten bzw. Remote-Proxies und lokalen Proxies
können
manchmal zu effizienteren Implementierungen bestimmter Anwendungen
führen,
beispielsweise automatisches Daten/Programm/Herunterladen und interaktives
Anzeigen von vorher zusammengefaßtem Inhalt. Andere Anwendungen,
beispielsweise Übersetzungen und
eine Markendurchsetzung können
effizient allein auf lokalen Proxies ausgeführt werden, aber können noch
vorteilhafter auf Remote-Proxies ausgeführt werden, da die Ergebnisse
zur Verwendung durch andere Cache-gespeichert werden können, wobei Ressourcen
für spätere Anforderungen
eingespart werden. Noch andere Anforderungen, wie beispielsweise
eine Analyse des Anklickstroms, sind im allgemeinen besser auf einem
lokalen Proxy implementiert, da für den individuellen Nutzer
lokal mehr Ressourcen verfügbar
sind und ferner aus Gründen
der Privatsphäre.
-
Angesichts
der vorangegangenen Beschreibung sollte klar sein, daß es möglicherweise
mehr als einen sogenannten intelligenten bzw. „Smart"-Proxy gibt, der zwischen einer Client- Einrichtung und einer Content-
bzw. Inhalts-Server-Einrichtung angeordnet ist. Sofern dies nicht überprüft wird,
kann eine derartige Bedingung dazu führen, daß Inhalt exzessiv geändert wird
(beispielsweise zu viele eingefügte Add-Ins,
mehrere verlustbehaftete Kompressionen, die zu unkenntlichen Bildern
führen).
Zur Behandlung dieses Problems kann eine Ausführungsform der vorliegen Erfindung
ein Proxy-zu-Proxy-Protokoll verwenden, das die existierenden Anforderung/Antwort-Strukturen
erweitert, um anzuzeigen, ob bereits eine Transcodierung des Inhalts
ausgeführt
wurde, und auf welche Art und Weise. Ein derartiges spezialisiertes
Protokoll zusätzlich
zu anderen Proxy-zu-Proxy-Nachrichten, die bedarfsabhängig implementiert
werden können,
ermöglicht
mehreren Proxies, zusammenzuarbeiten, allerdings noch immer transparent
für Nutzer,
Client-Software,
existierende „Standard"-Proxies und Content-Server.
-
Gemäß noch einer
weiteren Ausführungsform
der vorliegenden Erfindung kann ein Proxy-Server verwendet werden,
um bestimmten Internet-Proxy- oder Server-Nutzern eine sogenannte „VIP"-Behandlung zu ermöglichen, wobei (entweder durch Bezahlung
oder auf der Basis irgendeines anderen Auswahlkriteriums, beispielsweise
des Nutzungsumfangs) berechtigte Nutzer identifiziert werden, die eine
höhere
Priorität
haben, wenn sie mit anderen Nutzern um Proxy-Ressourcen konkurrieren.
Im Vergleich dazu werden Nutzer bei existierenden Internet-Proxies
und Servern entweder auf einer zufälligen oder auf der Basis First-Come-First-Served
(bzw. wer zuerst kommt, mahlt zuerst) bedient.
-
Bei
einer bestimmten Implementierung einer derartigen Ausführungsform
kann der Transcodierserver 34 so konfiguriert sein, daß er Benutzer-IP-Adressen
aus von ihm verarbeiteten Anforderungen extrahiert und Informationen
führt,
beispielsweise wie oft oder für
welche Dauer ein Nutzer sich eine bestimmte Website ansieht. Solche
Informationen könnten
verwendet werden, um bei bestimmten Websites „frequent browser miles (häufige Browser-Meilen)" zu bestimmen. Nutzer
können
dann mit schnelleren Antwortzeiten für nachfolgende Besuche der
Site belohnt werden oder der Site-Inhaber könnte den Nut zer mit einer verbesserten
Leistungsfähigkeit auf
allen Sites, die durch denselben Proxy erreicht werden, belohnen.
Noch eine weitere Möglichkeit
besteht darin, daß der
Nutzer für
einen derartigen bevorzugten Dienst zahlt, wobei ihm ein Passwort
zugewiesen wird, welches dem Transcodierserver 34 zur Verfügung gestellt
werden kann. Noch eine weitere Möglichkeit
besteht darin, daß ein
Website-Eigentümer
einen Proxy-Provider dafür
bezahlen kann, daß er
die Leistungsfähigkeit
für alle
Nutzer verbessert, während
sie die Site des Eigentümers
besuchen.
-
Bei
einer anderen speziellen Implementierung können Informationen, die Nutzer
identifizieren, denen eine besondere VIP-Behandlung zugute kommen soll, an den
Transcodierserver 34 in Form einer Webseite weitergeleitet
werden. Bei Empfang einer derartigen Webseite kann der Proxy anschließend die
Behandlung von Threads so ermöglichen,
daß Arbeit
für von
VIP-Nutzern erzeugte Anforderungen zuerst ausgeführt wird. Hierzu kann der Transcodierserver 34 für den VIP-Dienst
Thread-Scheduling-Prioritäten anheben
(innerhalb des Betriebssystems), während sichergestellt wird,
daß kein
Thread verhungert (d. h. keinem Nutzer sollte aufgrund von VIP-Nutzern
der Zugriff völlig
verweigert werden). Darüber
hinaus kann der Transcodierserver 34 eine bevorzugte Cache-Speicherung
für bestimmte
Websites ermöglichen
und ein aggressiveres Pre-Fetching für VIP-Nutzer. Darüber hinaus
kann der Transcodierserver 34 Ressourcen-intensivere Kompressionsalgorithmen
verwenden, beispielsweise, um Inhalte mit besserer Qualität bei der
gleichen Latenzzeit bereitzustellen, und zwar auf Kosten der Verlangsamung
des Zugriffs für
Nicht-VIP-Nutzer.
-
Es
ist möglich,
daß bestimmte
Inhaltsanbieter oder Nutzer nicht möchten, daß ihr Inhalt in irgendeiner
Weise dynamisch geändert
wird. Daher können
Ausführungsformen
der vorliegenden Erfindung so implementiert werden, daß entweder
Inhaltsanbieter oder Nutzer die Möglichkeit erhalten, jeden möglicherweise
den Inhalt verändernden
Dienst auszuschalten.
-
Dies
kann beispielsweise mit Hilfe einer Durchleitungstechnik realisiert
werden, die von einem speziellen Tag ausgelöst wird, das in den Inhalt eingebettet
ist.
-
Wie
die vorangegangene Beschreibung zeigt, können Ausführungsformen der vorliegenden Erfindung
verwendet werden, um ein System zur Verbesserung der Kommunikationsmöglichkeiten
von Computern bereitzustellen, die auf Netzwerke wie das Internet
zugreifen. Ausführungsformen
der Erfindung können
vorteilhaft eingesetzt werden bei Computern mit begrenzter verfügbarer Kommunikationsbandbreite,
beispielsweise bei tragbaren Computern oder Personalcomputern, die über eine
Modemverbindung auf ein Netzwerk zugreifen. Die einzelnen Merkmale
derartiger Ausführungsformen
verbessern die Möglichkeit
dieser Computer, auf Daten im Netzwerk in einer rechtzeitigen Weise
mit verringerten für den
Nutzer erkennbaren Latenzzeiten zuzugreifen, wodurch es Inhaltsverfassern
ermöglicht
wird, reichhaltigen Inhalt zu produzieren, ohne Angst, daß nur Nutzer
mit hochentwickelten Datenkommunikations- und Anzeigemöglichkeiten
diesen nutzen können. Ausführungsformen
der vorliegenden Erfindung können
vorteilhafterweise auch für
andere Zwecke als für die
Verringerung der Latenzzeit verwendet werden. Zu derartigen Zwecken
gehören
beispielsweise das Konvertieren von Farbbildern in Grauwertbilder
für Nutzer,
die keine Farbanzeige haben; das Filtern und/oder Löschen von
unerwünschtem
Inhalt, beispielsweise Pornographie; das Hinzufügen von Inhalt, beispielsweise
Werbung; und die Sprachübersetzung.
-
Obwohl
die vorliegende Erfindung unter Bezugnahme auf Ausführungsformen
zum Zugreifen auf Daten aus dem Internet beschrieben wurde, werden
Fachleute erkennen, daß sie
auch auf andere Netzwerkumgebungen anwendbar ist. Beispielsweise
können
Ausführungsformen
der vorliegenden Erfindung verwendet werden, um die Datenkommunikation
zwischen einem Netzwerk-Clientcomputer und einem „Intranet" zu verbessern. Ein
Intranet ist üblicherweise
ein sicheres Firmennetzwerk, das der Internet-Architektur nachgebaut
ist; und enthält
im allgemeinen Mechanismen zum Kommunizieren mit externen Netzwerken,
beispielsweise dem Internet.
-
Im
vorstehenden wurden spezielle Ausführungsformen der vorliegenden
Erfindung detailliert beschrieben. Die Erfindung umfaßt alle
Alternativen, Modifikationen und Abwandlungen, die in den Schutzbereich
der Ansprüche
fallen, sowie alle Äquivalente
des beanspruchten Gegenstands. Beispielsweise können einige der Merkmale, die
oben beschrieben wurden, als wenn sie von einem Remote-Proxy bereitgestellt
werden, in einem Content-Server implementiert werden. In ähnlicher
Weise können einige
oder alle Merkmale, die oben als von einem lokalen Proxy bereitgestellt
beschrieben wurden, in einer Browser-Anwendung implementiert werden.