DE60116343T2

DE60116343T2 - Webserver

Info

Publication number: DE60116343T2
Application number: DE60116343T
Authority: DE
Inventors: Alexander Mark WATSON; Rhys Jonathan Winchester LEWIS
Original assignee: Volantis Systems Ltd
Current assignee: Volantis Systems Ltd
Priority date: 2000-09-26
Filing date: 2001-09-24
Publication date: 2006-08-31
Anticipated expiration: 2021-09-25
Also published as: GB0504877D0; CN1476712A; CN1268103C; GB2371896A; ES2256292T3; US7739658B2; GB0023570D0; GB0122959D0; GB2371896B; HK1049046B; AU2001287920A1; WO2002027543A2; WO2002027543A3; KR100874985B1; JP2004510254A; EP1641211A2; EP1320972B1; EP1641211B1; JP4865983B2; ATE314781T1

Description

Diese Erfindung betrifft Webserver und insbesondere, jedoch nicht ausschließlich, einen Webserver zum Antworten auf über das Internet von entfernten Benutzergeräten empfangene Abfragenachrichten und einen Webserver, der in der Lage ist, mit Webseitencode zu antworten, der eigens dafür ausgelegt ist, den Fähigkeiten des entfernten Benutzergeräts Rechnung zu tragen.
Die Verwendung des Internets ist in der letzten Zeit so weit verbreitet geworden, dass fast jede Firma ihre eigene Webseite aufweist, um Informationen und Online-Kaufmöglichkeiten bereitzustellen. Auf die Mehrzahl dieser Webseiten wurde in der Vergangenheit durch entfernte Benutzergeräte zugegriffen, die PCs (Personalcomputer) sind, bei denen eine von einer relativ kleinen Anzahl verfügbarer Browseranwendungen eingesetzt wird, so dass die Webseiten Webseitencode im Wesentlichen in einem einzigen Format zur Betrachtung am Benutzergerät ausgeben mussten.
Später haben sich neue internetfähige Geräte, wie PDA (Personal Digital Assistants – persönliche digitale Assistenten), Mobiltelefone mit WAP-(Wireless Application Protocol – drahtloses Anwendungsprotokoll)-Einrichtungen, IDTV (Interactive Digital Television – interaktives digitales Fernsehen), Informationskiosks, Spiele, Konsolen und Heimgeräte, verbreitet. Die Fähigkeiten dieser Geräte variieren, sowohl in ihrer Anzeigefunktion in Bezug auf die Bildschirmgröße und die Farbverarbeitungsfähigkeit, die Bandbreite und den verfügbaren Speicher sowie Variablen, die mit der Kommunikation unter Einschluss des Bildformats, des Kommunikationsprotokolls und der Auszeichnungssprache verbunden sind, in erheblichem Maße von Gerät zu Gerät.
Um Benutzer dieser verschiedenen Geräte in die Lage zu versetzen, auf ihre Webseiten zuzugreifen, sind viele Firmen dazu übergegangen, getrennte Webserver aufzubauen, um jeden Gerätetyp zu bedienen. Hierdurch werden jedoch Datenverwaltungsprobleme erzeugt, wenn ein Kunde die Option haben möchte, verschiedene Geräte zu verwenden, um mit dem Händler beispielsweise unter Verwendung derselben Kontoeinzelheiten zu kommunizieren, wobei der Händler dann eine Verbreitung verschiedener zu verwaltender und bei Bedarf mit neuem und zusätzlichem Material zu aktualisierender Webserveranwendungen fordert.
Ein alternativer Ansatz bestand darin, einen getrennten Ableger einer Webseite für den Zugriff durch einen alternativen Typ eines Benutzergeräts bereitzustellen, wobei der getrennte Ableger den erforderlichen Webseitencode durch Übersetzen des ursprünglichen PC-basierten Webseitencodes, der typischerweise im HyperText-Markup-Language-(HTML)-Format gehalten ist, in andere Geräteformate, wie Wireless Markup Language (WML), die für WAP-Telefone verwendet wird, erhält. Solche Lösungen waren jedoch im Allgemeinen nicht in der Lage, dem Benutzer des Geräts eine optimale Präsentation zu liefern. Der Übersetzungsprozess (häufig als "Transcodierung" bezeichnet) lässt sich nur schwer ausführen. Beispielsweise ist es erforderlich, eine geeignete Auswahl von Informationen bereitzustellen, die in dem Gerät mit geringeren Fähigkeiten als sie der PC aufweist, aus der Anzeige fortzulassen sind. Diese Schwierigkeit tritt in mehrfacher Weise auf, wenn es erforderlich ist, den ursprünglichen PC-Webseitencode zu aktualisieren, weil der Transcodierungsprozess auch neu ausgelegt werden muss.
Es wurde auch vorgeschlagen, dass die für den Zugriff auf Webseiteninformationen über das Internet verwendeten Protokolle durch die Verwendung von Standards vereinheitlicht werden sollten, um Probleme zu überwinden, die sich aus entfernten Benutzergeräten mit verschiedenen Fähigkeiten ergeben. Es wurde die Verwendung der Extensible Markup Language (XML) als ein Format für den Webseitencode vorgeschlagen. XML ist eine Auszeichnungssprache zum Definieren von Inhalt und kann mit XSL (Extensible Stylesheets Language) eingesetzt werden, die zum Transformieren von XML-Dokumenten mit Stylesheets am Präsentationspunkt verwendet wird. Bisher wurden solche Standards jedoch noch nicht eingesetzt, und diese Lösung wird nicht als für alle Gerätetypen optimal angesehen.
In WO-A-9 957 657 ist ein Proxy-Server beschrieben, über den ein Client-Gerät über das Internet auf Webseiten zugreifen kann, die von Webservern verfügbar sind. Der Proxy-Server ruft Webseiten ab und reduziert den Dateninhalt vor der Übertragung zum Client-Gerät auf der Grundlage von Eigenschaften des Client-Geräts.
Die vorliegende Erfindung strebt an, einen verbesserten Webserver mit Mehrkanalfähigkeiten bereitzustellen, der in der Lage ist, verschiedenen Typen entfernter Benutzergeräte zu dienen.
Aspekte der vorliegenden Erfindung sind in den anliegenden Ansprüchen dargelegt.
Gemäß einer Ausführungsform ist eine Vorrichtung zum Antworten auf eine Abfragenachricht von einem entfernten Benutzergerät nach Webseiteninformationen durch Erzeugen von Webseitencode, der für eine oder mehrere durch das Benutzergerät anzuzeigende Webseiten repräsentativ ist, und zum Ausgeben einer den Webseitencode aufweisenden Antwortnachricht offenbart.
Vorzugsweise beinhaltet die Vorrichtung eine Extraktionseinrichtung zum Extrahieren einer Gerätetypidentifikation, die das entfernte Benutzergerät als einen von einem Satz möglicher Gerätetypen mit verschiedenen Fähigkeiten identifiziert, aus der Abfragenachricht.
Die Vorrichtung weist vorzugsweise einen Prozessor zum Betreiben einer Codeerzeugungseinheit, um den Webseitencode zu erzeugen, eine erste Speichereinrichtung zum Speichern der Webseiteninformationen als einen Anweisungssatz und eine zweite Speichereinrichtung zum Speichern geräteabhängiger Informationen für jeden der verschiedenen Gerätetypen zum Auslegen des Webseitencodes für die Fähigkeiten des Gerätetyps auf.
Die Codeerzeugungseinheit beinhaltet vorzugsweise eine Interpretationseinrichtung zum Interpretieren der Anweisungen in Bezug auf ausgewählte geräteabhängige Informationen, die der Gerätetypidentifikation entsprechen, wobei die Codeerzeugungseinrichtung dabei in der Lage ist, den Webseitencode in einer Form zu erzeugen, in der der Webseitencode für die Fähigkeiten des entfernten Benutzergeräts ausgelegt ist.
Bevorzugte Ausführungsformen der vorliegenden Erfindung werden nun nur als Beispiel anhand der anliegenden Zeichnung beschrieben. Es zeigen:
1 einen schematischen Überblick über Verbindungen zwischen einem Webserver und entfernten Benutzergeräten,
2A ein schematisches Diagramm des Webservers aus 1,
2B ein Funktionsdiagramm zum Veranschaulichen des Signalflusses in dem Webserver aus 2A,
3 ein schematisches Diagramm von Behandlungstabellen zur Verwendung mit dem Webserver aus 2,
4 ein schematisches Diagramm, in dem der Betrieb der Codeerzeugungseinheit dargestellt ist,
5A ein Layout für einen PC,
5B ein Layout für ein Fernsehgerät,
5C ein Layout für einen PDA,
5D ein Layout für ein WAP-Telefon,
5E ein Layout für ein Gerät mit einem großen Bildschirm,
5F die Anzeige von Fragmenten in einem Gerät mit einem kleinen Bildschirm,
5G eine Mehrmenüstruktur in einem Gerät mit einem großen Bildschirm,
5H die Beziehung zwischen Steuersegmenten und Inhaltssegmenten in dem Layout aus 5G,
6 die Hierarchie einer Gerätebehandlungstabelle,
7 schematisch die dem Webserver bereitgestellte Software,
8 schematisch die vom Webserver benötigte Hardware,
9 schematisch die Trennung von Inhaltscode und der Präsentation von Informationen zur Verwendung durch die Codeerzeugungseinheit,
10 schematisch ein System, das einen Herstellungsserver und einen Entwicklungsserver aufweist,
11 den Austausch von Signalen in dem System aus 10, wenn ein neuer Typ eines Benutzergeräts zum ersten Mal angetroffen wird,
12 schematisch einen Server mit einem Cachespeicher,
13 ein Flussdiagramm, in dem das Verfahren zum Betrieb eines Gateway-Servers aus 12 dargestellt ist,
14 ein Flussdiagramm, in dem der Betrieb eines dynamischen Webseitenservers aus 12 dargestellt ist,
15 ein schematisches Diagramm, in dem ein Komponentenlogik-Softwaremodul dargestellt ist,
16 ein Flussdiagramm, in dem der Vorgang der Codeerzeugung unter Verwendung des Komponentenlogik-Softwaremoduls dargestellt ist,
17 ein Diagramm, in dem die Hierarchie von Datenobjekten dargestellt ist, die verschiedene durch einen einzigen Komponentennamen referenzierte Datenversionen sind,
18 die Hierarchie von Textobjekten mit verschiedenen Textcodegrößen und -sprachen,
19 den Signalfluss in einem Webserver, in dem eine Fensterzerlegung auftritt,
20 ein Flussdiagramm, in dem die Fensterzerlegung dargestellt ist,
21 die Zerlegung eines Fensters in Bruchstücke,
22 die Verwendung eines Benutzersitzungsspeichers während einer Formularausfüllung,
23 die Zerlegung eines bei der Formularausfüllung verwendeten Fensters,
24 die Funktion der graphischen Benutzerschnittstelle und
25 ein Flussdiagramm, in dem ein Verfahren zur Dateispeicherung dargestellt ist.
1 zeigt einen Webserver 1, der über das Internet 3 mit entfernten Benutzergeräten 2 verbunden ist. Die entfernten Benutzergeräte sind als ein PC, ein Fernsehgerät, ein PDA und ein Mobiltelefon mit einer WAP-Fähigkeit dargestellt, sie können jedoch eine beliebige Anzahl anderer internetfähiger Geräte sein. Der Webserver 1 ist mit einer Webserver-GUI (Graphical User Interface – graphische Benutzerschnittstelle) 4 versehen, die es einem Bediener des Webservers ermöglicht, Dokumente zu verfassen und den Betrieb des Webservers im Allgemeinen zu steuern und beizubehalten. Der Webserver 1 ist auch über das Internet 3 mit einem Dienstzentrum 5 verbunden, das alle neuen Typen von Benutzergeräten betreffende Informationen erfasst und dem Webserver 1 eine nachfolgende Softwarerevision zur Verfügung stellt, wenn dies erforderlich ist.
2A ist ein vereinfachtes schematisches Diagramm des Webservers 1 aus 1. Der Webserver 1 beinhaltet einen Prozessor 20, der eine Codeerzeugungseinheit 21 in Form einer Anwendung betreibt, die von dem Prozessor bei Bedarf ausgeführt wird, um Webseitencode zu erzeugen. Die Codeerzeugungseinheit 21 gemäß dieser Ausführungsform ist in der Programmiersprache Java geschrieben und existiert während des Betriebs des Webservers in kompilierter Form als Bytecodes im Arbeitsspeicher des Prozessors 20 und ist innerhalb einer Java-Laufzeitumgebung implementierbar.
Ein Speicher 22 speichert Inhaltscode 23, der Webseiteninformationen in Form in einer Auszeichnungssprache, die im vorliegenden Beispiel JSP1.1 (Java Server Pages) ist, geschriebener Dokumente definiert. Diese Dokumente werden typischerweise vom Bediener des Webservers 1 unter Verwendung der graphischen Benutzerschnittstelle 4 verfasst. Der Speicher 22 speichert auch Betriebsdaten 24, welche beispielsweise Daten, die möglicherweise in zur Laufzeit ansprechend auf spezifische Anfragen, die vom Benutzergerät 2 ausgehen, erzeugten Webseitencode aufgenommen werden müssen, und durch Überwachen der Verwendung des Webservers erfasste Daten einschließen. Datenobjekte, auf die vom Inhaltscode 23 verwiesen wird, sind in einer Datenbank 19 gespeichert. Diese Datenobjekte können Dateien, welche Bilder oder Text enthalten, und andere Formen von Datenobjekten, die ein Verfasser möglicherweise in den zu erzeugenden Webseitencode aufnehmen möchte, einschließen.
Geräteabhängige Informationen 25 sind auch im Speicher 22 gespeichert und bestehen in erster Linie aus nachstehend beschriebenen Behandlungstabellen. Der Speicher 22 speichert auch Programmcode 26, auf den während des Betriebs des Servers 1 durch den Prozessor 20 zugegriffen werden kann oder der verwendet werden kann, um Software, wie die Codeerzeugungseinheit 21, beim Einleiten abzurufen. Der Programmcode 26 umfasst auch Code, der eine Menge von Tags definiert, die in einer Auszeichnungssprache verwendet werden, in der die Dokumente wie nachstehend beschrieben verfasst werden.
Eine Schnittstelle 27 vermittelt zwischen einem Datenbus 28, der dem Prozessor 20 und dem Speicher 22 dient, und einer externen Verbindung zum Internet 3, um Abfragenachrichten zu empfangen und Antwortnachrichten zu senden.
Eine Geräteidentifikationseinheit 29 ist bereitgestellt, um aus empfangenen Nachrichten eine Gerätetypidentifikation zum Identifizieren des entfernten Benutzergeräts 2 nach dem Typ zu extrahieren. Die Geräteidentifikationseinheit 29 nach dem vorliegenden Beispiel ist durch den Prozessor 20 als Software implementiert. In diesem Beispiel enthält eine über das Internet empfangene Abfragenachricht einen HyperText-Transfer-Protocol-(HTTP)-Header, der eine Identifikations zeichenkette enthält, welche den Namen des Benutzeragenten erklärt, den die einleitende Vorrichtung verwendet hat, als sie die Abfragenachricht erzeugt hat. Der Name der Benutzeragentensoftware definiert beispielsweise die Browserversion und die Auszeichnungssprachenfähigkeit des Geräts und wird von der Geräteidentifikationseinheit 29 verwendet, um die einleitende Vorrichtung unter Verwendung der Gerätetypidentifikation zu identifizieren, die beispielsweise als eine Nachschlagetabelle gespeichert sein kann.
Der HTTP-Header kann auch Informationen liefern, die in einem Cookie enthalten sind und Einzelheiten über den Benutzer betreffen, der die Abfragenachricht eingeleitet hat. Diese Cookies können andere Daten enthalten, welche zur Personalisierung der vom Webserver 1 gegebenen Antwort verwendet werden.
2B ist eine weitere Darstellung des Webservers 1, worin Funktionselemente in einer den Signalfluss darstellenden Weise gezeigt sind. Ein Vorprozessor 300 stellt eine Kommunikationsschnittstelle für vom Internet 3 empfangene Abfragenachrichten und über das Internet zum Benutzergerät 2 gesendete Antwortnachrichten bereit. Der Vorprozessor 300 sendet URL-Informationen 301 zu einem Webanwendungsprozessor 302, der anhand der URL die geeigneten Informationen bestimmt, die in eine vom Benutzer aufgerufene Webseite aufzunehmen sind. Der Webanwendungsprozessor 302 hat Zugang zu einer Datenbank 303, die lokal zum Prozessor angeordnet sein kann oder sich an einem fernen Ort befinden kann, der über eine geeignete Kommunikationsstrecke zugänglich ist.
Der Webanwendungsprozessor 302 gibt ein Dokument 304 aus, das Anweisungen zum Erzeugen des Webseitencodes enthält. Das Dokument 304 kann nicht von sich aus durch einen Browser eines Benutzergeräts interpretiert werden und stellt daher für die Zwecke der vorliegenden Beschreibung keinen "Webseitencode" dar.
Das Dokument 304 wird in die Codeerzeugungseinheit 21 eingegeben, welche Webseitencode in Bezug auf die Inhaltsdatenstruktur 305 und den Satz der Behandlungstabellen 40 erzeugt. Die Ausgabe der Codeerzeugungseinheit ist ein Webseitencodedokument 306, das nun in einem Format vorliegt, das durch den Browser des Benutzergeräts 2 interpretiert werden kann. Das Webseitencodedokument 306 wird vom Vorprozessor 300 empfangen und als eine Antwortnachricht verpackt, die durch das Benutzergerät 2 über das Internet 3 übertragen wird.
Um die Codeerzeugungseinheit 21 in die Lage zu versetzen, die geeigneten Daten aus der Inhaltsdatenstruktur 305 auszuwählen und auf die geeigneten Behandlungstabellen 40 zuzugreifen, ist auch die Eingabe einer Gerätetypidentifikation 45 erforderlich, die ansprechend auf den Empfang eines Nachrichten-Headersignals 307 vom Vorprozessor 300 von der Geräteidentifikationseinheit 29 bereitgestellt wird, wobei dieses Signal aus dem Nachrichten-Header der vom Benutzergerät empfangenen Abfragenachricht extrahierte Informationen enthält.
3 zeigt schematisch die Behandlungstabellen 40, welche die geräteabhängigen Informationen 25 aus 2A bilden.
Im vorliegenden Zusammenhang wird der Begriff "Behandlung" bzw. "Behandlungsvorschrift" verwendet, um Informationen anzugeben, die von der Codeerzeugungseinheit 21 zu verwenden sind und die, entweder aus Notwendigkeit wegen verschiedener technischer Fähigkeiten verschiedener Gerätetypen oder infolge einer Auswahl durch den Verfasser des Inhaltscodes 23, für verschiedene Gerätetypen auf verschiedene Weise definiert werden können.
Die Behandlungstabellen 40 umfassen eine Gerätebehandlungstabelle 30, welche eine Anzahl von Feldern enthält, die sich auf verschiedene technische Aspekte des Gerätetyps beziehen. Beispielsweise sind in der nachstehenden Tabelle 1 eine kleine Anzahl von Gerätebehandlungsvorschriften angeführt, die dem Gerätetyp zugeordnet werden können und die jeweils einem Feld (d.h, einer Zeile) der Tabelle entsprechen. Werte sind für einen einzigen Gerätetyp (d.h. eine einzige Spalte) dargestellt. Die Gerätebehandlungstabelle 30 beinhaltet in der Praxis eine große Anzahl verschiedener Felder und Werte für mehrere Gerätetypen, wobei eine hierarchische Tabellenstruktur verwendet wird, um die Tabelle in kompakter Form darzustellen.
TABELLE 1 – Teil der Gerätebehandlungstabelle
Durch Zugreifen auf die Gerätebehandlungstabelle 30 ist die Codeerzeugungseinheit 21 in der Lage, eine Entscheidung in Bezug auf die Auswahl der Codeerzeugung vorzunehmen, um den technischen Fähigkeiten des Benutzergeräts 2 Rechnung zu tragen. Falls ein Bild beispielsweise als eine Bilddatei in den Webseitencode aufzunehmen ist, ist es erforderlich, dass die Codeerzeugungseinheit 21 Kenntnisse über das Format der Bilddatenkompression hat, die dem Benutzergerät 2 zur Verfügung steht, von dem die Abfragenachricht ausgegangen ist. Die Gerätebehandlungstabelle 30 weist Felder auf, die angeben, ob Bilder im GIF- oder im JPEG-Format von dem Gerät dekomprimiert werden können. Ähnlich können Audiodateien in einer Anzahl verschiedener Formate, einschließlich des MP3-Formats, komprimiert werden, und die Gerätebehandlungstabelle 30 weist auch ein Feld auf, das angibt, ob das Gerät MP3 unterstützt.
Die Protokollbehandlungstabelle 31 ist dafür verantwortlich, Entsprechungen zwischen Geräteausgabeprotokollen zuzuordnen, welche im Allgemeinen als Auszeichnungssprachen bezeichnet werden. Beispiele sind WML, HTML, Handheld Device Markup Language (HDML) und compact HTML (cHTML). Tabelle 2 ist ein Beispiel von sechs Feldern in der Protokollbehandlungstabelle 31 für einen einzigen der Gerätetypen.
TABELLE 2 – Teil der Protokollbehandlungstabelle
Eine Stilbehandlungstabelle 32 enthält eine Anzahl von Feldern, welche Parameter, wie Fontfamilie, Fontgröße, Fontgewicht und Farbe von Überschriften, Bildrändern und Absatzhintergrund definieren, wie in Tabelle 3 dargestellt ist, worin ein Teil der Stilbehandlungstabelle für einen einzigen der Gerätetypen gezeigt ist. Die Codeerzeugungseinheit 21 ist dadurch in der Lage, entsprechend einer vorgegebenen Entscheidung, die beispielsweise einen vereinbarten Stil widerspiegeln kann, der als ein allgemeiner Handelsstil von einer bestimmten Geschäftseinheit verwendet wird, Code zu erzeugen, der für den Gerätetyp geeignet ist.
Die Art, in der Stilinformationen behandelt werden, variiert zwischen verschiedenen Geräten und tatsächlich zwischen verschiedenen Geräteausgabeprotokollen. Für einige müssen Stilinformationen in den erzeugten Webseitencode aufgenommen werden. Für andere müssen Stilinformationen in getrennt erzeugtem Code, der häufig als "style sheet" bezeichnet wird, bereitgestellt werden.
TABELLE 3 – Teil der Stilbehandlungstabelle
Eine Motivbehandlungstabelle 33 enthält in ähnlicher Weise Felder, die sich auf dekorative Verzierungen und Logos beziehen, welche von Geschäftseinheiten für ihre Webseiten verwendet werden, und sie ermöglicht es dem Verfasser der Motivbehandlungsvorschrift, die dekorativen Merkmale und Aspekte von Logos, wie die Größe, für jeden der Gerätetypen eigens auszulegen.
Die Layoutbehandlungstabelle 35 enthält Felder, welche sich auf das Layout von Elementen beziehen, welche Text, Logos, Bilder usw. beim Rendern des Bilds im Benutzergerät einschließen, um beispielsweise eine andere Bildschirmform und -größe für verschiedene Gerätetypen zu berücksichtigen.
Eine dynamische Behandlungstabelle 36 enthält Felder, welche es ermöglichen, dass Code für verschiedene Gerätetypen entsprechend zeitlich veränderlichen Parametern eigens eingerichtet wird. Beispielsweise kann ein Mobiltelefon mit WAP-Fähigkeiten eine Bandbreite zum Empfangen von Antwortnachrichten aufweisen, die sich zeitlich entsprechend der Signalstärke ändert, die über das Mobiltelefonnetz verfügbar ist, das von dem Telefon zur Verbindung mit dem Internet verwendet wird. Die dynamische Behandlungsvorschrift kann konfiguriert werden, um Code zu erzeugen, der unter Bedingungen einer schmalen Bandbreite eine niedrige Bandbreite erfordert und der unter besseren Bedingungen eine höhere Bandbreite erfordert. Die Menge der Bilddaten kann beispielsweise geregelt werden, um die Bandbreite zu steuern, die erforderlich ist, um die Antwortnachricht zu übertragen. Durch einfaches Fortlassen eines Logos oder eines anderen Bilds kann die Geschwindigkeit, mit der die Antwortnachricht zu dem Gerät heruntergeladen werden kann, unter Bedingungen einer geringen Signalstärke beibehalten werden.
Eine Komponentenbehandlungstabelle 37 ist auch bereitgestellt, und ihr Zweck besteht darin, die Auswahl von Datenobjekten festzulegen, wie nachstehend beschrieben wird.
4 zeigt schematisch die Art, in der die Codeerzeugungseinheit 21 die Daten in der Behandlungstabelle 40 verwendet. Beim Hochfahren ruft der Prozessor 20 ein Hochfahrprogramm aus dem gespeicherten Programmcode 26 ab und führt das Hochfahrprogramm aus, um die Informationen in den Behandlungstabellen 40 in eine Reihe von Java-Objekten (Java beans) umzusetzen, die hier als Behandlungsobjekte 41 bezeichnet werden, welche dann innerhalb einer Laufzeitumgebung 46 der Codeerzeugungseinheit 21 verfügbar gemacht werden. Die Laufzeitumgebung wird durch eine geeignete Java Virtual Machine bereitgestellt. Die Behandlungsobjekte 41 behandeln jeweils spezifische Aspekte der Codeerzeugung und enthalten Logik- und Datenobjekte, die so konfiguriert sind, dass jedes Behandlungsobjekt Kenntnis über alle relevanten Informationen hat, die von den Behandlungstabellen 40 für jeden Gerätetyp verfügbar sind. Ein Behandlungsobjekt 41 kann beispielsweise die Bildformatfähigkeit betreffen, während ein anderes Behandlungsobjekt die Auswahl der Auszeichnungssprache für den ausgegebenen Code betreffen kann. Die Codeerzeugungseinheit 21 verarbeitet zur Laufzeit eine kompilierte Version eines Dokuments des Inhaltscodes 23, wobei der Code aus einer Reihe von Befehlen 42 besteht, wobei jeder Befehl einen Satz von Auszeichnungs-Tags 43 beinhaltet.
In 4 ist das Tag 43 als eines von einer Anzahl eigens ausgelegter Tags oder Smart-Tags dargestellt, wie in 4 schematisch gezeigt ist, und es bezieht sich, wenn es verarbeitet wird, auf einen Satz von Klassen 44, die geschrieben worden sind, um die erforderliche Funktion der Tags auszuführen. Diese Klassen 44 beziehen sich wiederum auf der Grundlage in den Behandlungstabellen 40 enthaltener Daten auf eines oder mehrere der Behandlungsobjekte 41, wann immer eine Programmentscheidung zu treffen ist, die vom Gerätetyp abhängt.
Beispiele eigens ausgelegter Tags 43, die gemäß der vorliegenden Ausführungsform vorgesehen sind, sind in den Tabellen 4 und 5 zusammengefasst. Alle Tags, die beim Definieren des Inhaltscodes 23 verwendet werden, sind in dem Sinne, dass sie als eigens ausgelegte JSP-Tags implementiert sind, gerätespezifisch und Java-Klassen zugeordnet, welche auf Java beans (Behandlungsobjekte 41) zugreifen, um geräteabhängige Entscheidungen zu treffen. Die primitiveren Tags werden hier einfach als In-Line-Tags bezeichnet, wie in Tabelle 4 dargestellt ist. Komplexere Tags werden in Tabelle 5 als wesentliche Block-Tags bezeichnet. Die wesentlichen Tags führen typischerweise zu mehr als einem Tag in der Auszeichnungssprache des sich ergebenden erzeugten Codes, beispielsweise HTML.
TABELLE 4
TABELLE 5
Die vom Prozessor 20 betriebene Geräteidentifikationseinheit 29 extrahiert aus einem Header der von einem entfernten Benutzergerät 2 empfangenen Abfragenachricht Informationen, welche den Gerätetyp identifizieren, und gibt eine Gerätetypidentifikation 45 aus, die in die Codeerzeugungseinheit 21 eingegeben wird, um es dem Satz von Klassen 44 zu ermöglichen, die erforderlichen Informationen aus den Behandlungsobjekten 41 zu extrahieren.
Ein Beispiel eines Dokuments ist in Anhang 1 angegeben und beinhaltet einen Befehlssatz 42 unter Einschluss von Tags 43 zur Bildung des Inhaltscodes 23 in der Auszeichnungssprache, der von der Codeerzeugungseinheit 21 ausgeführt wird. Auf der Zeile 2 wird beispielsweise das Tag <vt:canvas> beim Definieren des Themas und des Layouts der zu erzeugenden Webseite verwendet. Zwischen dem Öffnen und dem Schließen von canvas-Tags (was auf der zweiten Zeile und der letzten Zeile auftritt) befindet sich eine Liste von Komponenten, die auch unter Verwendung eigens ausgelegter Tags 43 implementiert werden. Die Komponenten beziehen sich auf Fenster in dem Layout, wobei der Begriff "Fenster" verwendet wird, um einen von einer Reihe (im Allgemeinen) rechteckiger Bereiche zu bezeichnen, in den ein Anzeigeschirm zu unterteilen ist, wenn die Webseite dem Benutzer auf dem Benutzergerät 2 präsentiert wird. Eine Sammlung von Fenstern und ihren relativen Positionen definiert das Layout für die Seite. Die Komponenten können verwendet werden, um zu definieren, wo in der gerenderten Seite die Ausgabe einer gegebenen Komponente erscheint, oder alternativ, um festzulegen, ob eine gegebene Komponente zu rendern ist, wenn die Webseite beispielsweise auf einem Benutzergerät mit einer begrenzten Bildschirmgröße anzuzeigen ist. Auf diese Weise können Layouts verwendet werden, um die Informationsmenge zu begrenzen, die auf dem Anzeigeschirm bestimmter Gerätetypen erscheint.
5A zeigt beispielsweise ein typisches Layout von Fenstern 50 zur Anzeige auf einem PC und beinhaltet Fenster, welche jeweils ein Logo, ein großes Farblogo, ein Seitenmenü, eine Begrüßung, eine erste, eine zweite und eine dritte Werbung und einen Nachrichtenticker, der kontinuierlich neue Informationen liefert, aufweisen.
Das Layout, das demselben Inhaltsdokument entspricht, wenn es zur Anzeige auf einem Fernsehschirm erzeugt wird, ist in 5B dargestellt und besteht aus einer verringerten Anzahl von Fenstern, die ein großes Farblogo, eine Begrüßung, ein Werbungsmenü, ein Seitenmenü bzw. ein Bild enthalten.
5C zeigt den entsprechenden gerenderten Bildschirm, der sich aus auf der Grundlage desselben Inhaltsdokuments erzeugtem Code ergibt, wenn es für einen PDA ausgelegt ist. Die Anzahl der Fenster wird während der Codeerzeugung erheblich verringert, um den begrenzten Fähigkeiten des PDA Rechnung zu tragen, und sie umfassen Fenster, welche ein schwarzes und weißes Logo mittlerer Größe, eine Begrüßung, ein Werbungsmenü bzw. ein Seitenmenü enthalten.
5D zeigt das Layout, das sich bei der Codeerzeugung auf der Grundlage desselben Dokuments ergibt, wenn es für ein WAP-Telefon ausgelegt ist. An Stelle einer einzigen Webseite wird der Inhalt auf einen Satz von Fragmenten, die häufig als Decks bezeichnet werden, reduziert, wobei jedes ein einziges Fenster aufweist, das über ein Menüdeck 50 zugänglich ist, wobei der Satz von Decks weiter einzelne Fensterdecks 51, 52 und 53 für Werbung 1, 2 bzw. 3 aufweist. "Deck" ist ein in den WAP-Standards verwendeter Begriff, um die Einheiten anzugeben, in denen Informationen zum drahtlosen Gerät gesendet werden.
Anhang 2 zeigt den unter Verwendung des Inhaltscodes aus Anhang 1 erzeugten Webseitencode, wobei der Gerätetyp einem PC mit einem Browser unter Verwendung des HTML-Protokolls entspricht.
Anhang 3 zeigt den entsprechenden Code, der erzeugt wird, wenn er an einen Gerätetyp ausgegeben wird, der einem Telefon mit WAP-Fähigkeiten unter Verwendung des WML-Protokolls entspricht. Anhang 3 enthält nur ein Deck eines Satzes in dem erzeugten Code enthaltener Decks, wobei der Benutzer aufeinander folgende Decks auswählen muss, um wiederum eine Anzahl aufeinander folgender Anzeigen der Webseiteninformationen zu betrachten. Die Fragmentierung des Antwortnachrichtencodes in Decks ist in 5D beispielhaft dargestellt.
Anhang 4 zeigt ein weiteres Deck, das sich aus dem WML-Code für das WAP-Telefon ergibt, wobei das Deck dieses Mal in der Hinsicht dem Menü-Deck 50 aus 5D entspricht, dass es eine Liste von Geschichten enthält, die in aufeinander folgenden Decks vom Benutzer betrachtet werden können.
Anhang 5 zeigt das für eine der Geschichten erzeugte Deck.
In dem vorstehenden Beispiel ist die Codeerzeugungseinheit 21 in der Lage, denselben Inhaltscode 23 zu verarbeiten, um entsprechend verschiedenen Gerätetypen ausgegebenen völlig verschiedenen Webseitencode zu erzeugen. Der erste Gerätetyp führt zu dem Code aus Anhang 2, und der zweite Gerätetyp, der geringere Fähigkeiten hat, führt zu dem Code aus den Anhängen 3, 4 und 5.
Die 5E und 5F zeigen die Art, in der das Bereitstellen verschiedener Layout-Definitionen für zwei verschiedene entfernte Benutzergeräte 2 ermöglicht, dass der gesamte Inhalt einer Webseite Geräten mit verschiedenen Fähigkeiten zugeführt wird.
In 5E hat das Layout für ein Gerät mit einem großen Bildschirm die Wirkung, den gesamten Inhalt in einem einzigen Bildschirm anzuzeigen, wobei Teile des Inhalts in jeweiligen Fenstern A, B, C, D, E und F enthalten sind. Bei einer Formatierung für das Gerät mit einem kleinen Bildschirm wird nur eines der Fenster A, B, C, D, E und F zu jeder gegebenen Zeit angezeigt, wobei der Inhalt in Fragmente A, B, C, D, E und F fragmentiert ist, wie in 5F dargestellt ist. Das Fragment A ist als ein Stammfragment bezeichnet, über das auf die restlichen Fragmente unter Verwendung eines Menüs zugegriffen werden kann.
Für das Gerät mit einer kleinen Bildschirmkapazität muss das Fragment möglicherweise umgeformt werden oder der Inhalt auf andere Weise präsentiert werden, so dass es beispielsweise erforderlich sein kann, dass der Benutzer durch Text scrollt, um den gesamten Inhalt eines Text enthaltenden gegebenen Fragments zu sehen.
Alternativ kann eine Menüstruktur verwendet werden, wie in den 5G und 5H dargestellt ist. Statt das Layout durch Fenster zu definieren, wird das Layout durch eine Reihe von Segmenten definiert, die Anzeigebereiche definieren und entweder als Steuersegmente oder als Inhaltssegmente festgelegt sind. In 5G enthält ein Steuersegment 55 einen Menübalken 56, der eine Reihe von Bildzeichen bildet, die vom Benutzer ausgewählt werden können.
Ein Inhaltssegment 57 definiert einen weiteren Bereich der Anzeige und enthält selbst ein weiteres Inhaltssegment 58. Das Inhaltssegment 57 enthält auch ein weiteres Steuersegment 59, das einen zweiten Menübalken 510 enthält.
In diesem Beispiel erfordert die Auswahl unter Verwendung des ersten Menübalkens 56 die Anzeige innerhalb des Steuersegments 59 eines ausgewählten Satzes zweiter Menübalken 510, wie in 5H dargestellt ist. Jeder der zweiten Menübalken 510 ermöglicht die Auswahl aus einem jeweiligen Satz von Inhaltselementen 511.
Das Beispiel aus den 5G und 5H zeigt ein alternatives Verfahren zur Seitenbeschreibung, wobei ein Montage-Tag das Seitenlayout in Bezug auf eine Reihe von Segmenten definiert, die Inhaltssegmente oder Steuersegmente sein können. Wie in diesem Beispiel dargestellt ist, ist es möglich, dass ein Inhaltssegment weitere Segmente enthält, welche sowohl Steuer- als auch Inhaltssegmente einschließen.
5G entspricht der auf einem Gerät mit einem großen Bildschirm betrachteten Webseite. Wenn es auf ein Gerät mit einem kleinen Bildschirm umgesetzt wird, könnte der Benutzer beispielsweise nur ein Segment zur Zeit sehen, wobei er zunächst das erste Steuersegment 55 betrachtet, um die Auswahl von einem der zweiten Menübalken 510 und die anschließende Auswahl von einem der Inhaltselemente 511 zu ermöglichen.
Das sich ergebende Layout aus 5G kann unter Verwendung des Inline-Rahmenmerkmals von HTML implementiert werden.
Die vorstehend erwähnten Beispiele aus den 5A bis 5H sind zwei Extremfälle von Anzeigefähigkeiten von Benutzergeräten. Für Geräte mit mittleren Fähigkeiten können alternative Layouts, die möglicherweise zwei oder drei Segmente oder Fenster zeigen, geeignet sein. Es kann auch angemessen sein, den Inhalt innerhalb jedes Fensters oder Segments entsprechend den Fähigkeiten des Geräts zu modifizieren. Beispielsweise ist ein PC im Allgemeinen zu einem höheren Standard oder einer besseren Bilddarstellung in der Lage, welche Farbbilder und bewegliche Bilder einschließt, während ein WAP-Telefon möglicherweise nicht farbfähig ist und eine begrenzte Bildschirmauflösung und eine begrenzte Auffrischungsrate aufweisen kann. Dies erfordert, dass für jedes Fenster oder Segment der Inhalt in einer Anzahl verschiedener Formen, die für die verschiedenen Geräte geeignet sind, gespeichert werden muss.
Die Behandlungstabellen 40 sind jeweils so angeordnet, dass sie eine hierarchische Struktur in der Art der beispielsweise in 6 dargestellten Struktur aufweisen, worin die Hierarchie der Gerätebehandlungstabelle 30 dargestellt ist. Die Eigenschaften eines angenommenen Stammgerätetyps definieren eine obere Ebene 61 der Hierarchie. Dieser Stammtyp kann als Standardwerte für die Gerätebehandlungstabelle 30 darstellend angesehen werden. Eine zweite Schicht 62 definiert Gerätetypen, die sich in einer Anzahl von Merkmalen vom Stammgerätetyp unterscheiden. Die Gerätebehandlungstabelle beinhaltet daher Einträge (Spalten) für jene Felder, in denen die Parameter, die den Stammgerätetyp beschreiben, nicht vererbt sind. Die dritte Schicht 63 der Hierarchie beinhaltet Unterteilungen der allgemeinen Gerätetypen der ersten Schicht, und es ist beispielsweise eine Anzahl verschiedener PDA-Geräte dargestellt. Jeder dieser Gerätetypen erbt viele der Parameter, die die Fähigkeiten des PDA in der ersten Schicht beschreiben, unterscheidet sich jedoch in einer Anzahl von Hinsichten, wodurch Einträge in jeweiligen Spalten der Gerätebehandlungstabelle für jene Felder erforderlich sind, die nicht vererbte Parameter enthalten.
Nachfolgende Schichten 64 und 65 der Hierarchie definieren weitere Unterteilungen des Gerätetyps.
Die Geräteidentifikation 45 identifiziert einen Knoten in diesem Hierarchiebaum, und der gesamte Satz von Merkmalen, die für den Gerätetyp relevant sind, kann dann durch Durchlaufen des von der Hierarchiestruktur definierten Baums von dem Knoten durch aufeinander folgende Schichten zum in der oberen Schicht 61 definierten Stammgerätetyp erfasst werden, wodurch weitere vererbte Merkmale jeder Schicht erworben werden.
Ein Vorteil des Organisierens jeder der Behandlungstabellen 40 in einer solchen hierarchischen Struktur besteht darin, dass, wenn es erforderlich ist, die Behandlungstabellen 40 zu erweitern, so dass sie Daten für einen zusätzlichen Gerätetyp aufweisen, dies durch Einfügen eines neuen Knotens in die hierarchische Baumstruktur und durch Verbinden des neuen Knotens mit einem Zweig von einem Elternknoten in einer benachbarten oberen Schicht erreicht werden kann. Der Elternknoten wird als der Knoten ausgewählt, von dem der Gerätetyp den vollständigsten Merkmalssatz erbt.
Falls beispielsweise ein Mobiltelefon bereits in den Behandlungstabellen 40 dargestellt ist und ein neues Modell des Mobiltelefons verfügbar wird, kann jede Änderung der Fähigkeiten des neuen Modells, die Änderungen der Behandlungsvorschrift erfordert, durch eine minimale Datenmenge dargestellt werden, die einem neuen Eintrag in jeder Behandlungstabelle entspricht, welche Werte nur in jenen Feldern enthält, für die Attribute nicht von dem existierenden Modell des Mobiltelefons geerbt werden, das durch einen existierenden Knoten in der Hierarchie dargestellt ist.
Informationen zum Aktualisieren der Behandlungstabellen 40 zur Aufnahme zusätzlicher Gerätetypen können von dem in 1 dargestellten Dienstzentrum 5 bereitgestellt werden und dem Webserver 1 beispielsweise über das Internet 3 zugeführt werden. Die geräteabhängigen Informationen 25 unter Einschluss der Behandlungstabellen 40 können dann durch den Betrieb des Datenmanagers 190, eines in 2 schematisch dargestellten Softwaremoduls des Webservers 1, aktualisiert werden. Diese Prozedur kann im Allgemeinen während des normalen Betriebs des Webservers 1 und des Betriebs der Codeerzeugungseinheit 21 ausgeführt werden. Ansprechend auf die Aktualisierung der Behandlungstabellen 40 aktualisieren sich die Behandlungsobjekte 41 automatisch selbst, während ihre gegenwärtige Verwendung in der Betriebsumgebung 46 der Codeerzeugungseinheit 21 verwaltet wird. Diese Aktivität wird so geregelt, dass kein Webseitencode unterbrochen wird, der gegenwärtig von der Codeerzeugungseinheit 21 erzeugt wird.
7 zeigt ein Beispiel von Software, die dem Webserver gemäß einer bevorzugten Ausführungsform zugeführt wird. Die Software beinhaltet den Satz von Behandlungstabellen 40 und einen Satz von Tags 70, welche sowohl Tag-Definitionen, welche die erforderlichen Informationen zum Ermöglichen des Verfassens von Inhalt bereitstellen, als auch Code zum Implementieren der Tags, d.h. den Programmcode, der ausgeführt wird, wenn jedes Tag in der Betriebsumgebung der Codeerzeugungseinheit 21 verwendet wird, umfassen.
Die Codeerzeugungseinheit 21 und die Geräteidentifikationseinheit 29 gehören zu den Elementen, die dem Webserver bereitgestellt werden. Weiterhin ist eine Berichtseinheit 71 bereitgestellt. Die Berichtseinheit wird vom Prozessor 20 betrieben, um Aufgaben, wie das Messen der Verwendung der Webseite, auszuführen. Diese Informationen können verwendet werden, um beispielsweise zu Werbezwecken das Ausmaß aufzuzeigen, bis zu dem die Seite verwendet wird, und auch, um zu ermöglichen, dass personalisiertes Marketing auf Benutzer der Seite gerichtet wird. Als ein Beispiel kann eine Datenbank von Benutzern verwendet werden, um eine Antwort auf eine Abfragenachricht von einem bestimmten Benutzer eigens einzurichten, so dass eine Antwortnachricht eine zusätzliche Seite enthält, die ein Sonderangebot zu einem Produkt enthält, das als einen bestimmten Benutzer interessierend registriert ist.
Die Software weist weiterhin eine Integrationseinheit 72 zum Kommunizieren mit Routineaktivitäten, wie Rechnungs- und Kaufauftragsaktivitäten, auf, die ansprechend auf die Verwendung der Webseite durch Benutzer der entfernten Benutzergeräte 2 auftreten können.
Die Software weist weiter einen Operationsmanager 73 zum Verwalten des Gesamtsystems für das Steuern des Betriebs, das Ermöglichen des Erkennens von Fehlern und das Ermöglichen des entsprechenden Steuerns von Betriebsmitteln auf.
Weiterhin ist ein Programm 74 für die Erzeugung der Behandlungsobjekte beim Hochfahren bereitgestellt, wie vorstehend mit Bezug auf 4 beschrieben wurde.
Die Geräteidentifikationseinheit 29 ist auch bereitgestellt, wie vorstehend beschrieben wurde.
Weiterhin verarbeitet eine Webanwendung 75 die empfangene URL-Anforderung zum Identifizieren der angeforderten Webseite und wählt das geeignete Dokument des Inhaltscodes 23 zum Importieren in die Codeerzeugungseinheit 21 aus.
8 zeigt schematisch eine typische Hardware, die zum Implementieren der vorliegenden Erfindung in einem kleinen bis mittelgroßen Webserver erforderlich ist. Ein Personalcomputer 80, der Fähigkeiten zum Empfangen von Programmen in der Art jener, die in 7 zusammengefasst sind, von einem tragbaren Speichermedium 81 aufweist, ist über eine Firewall 82 mit einem Router 83 verbunden. Der Router 83 ist über eine Mietleitung 84 hoher Bandbreite zur Verbindung mit dem Internet 3 mit einem Internetdienstanbieter 85 verbunden.
Programme und Daten, die zum Betreiben des Webservers 1 erforderlich sind, können vom Dienstzentrum 5 in Form des tragbaren Speichermediums 81 oder alternativ als über ein Netz in der Art des Internets 3 übermittelte Signale 86 übermittelt werden.
Wie in 9 schematisch dargestellt ist, ermöglicht die vorstehend beschriebene Webserver- und Softwarekonfiguration, dass Inhaltscode 23 getrennt von Präsentationsinformationen 90 gespeichert wird, so dass, wenn eine Abfragenachricht 91 von dem System empfangen wird, die Codeerzeugungseinheit 21 in der Lage ist, dynamisch eine Antwortnachricht 92 zu erzeugen, die neu erzeugten Webseitencode enthält, welcher die Kombination von Inhaltscode- und Präsentationsinformationen darstellt. Ein spezieller Vorteil dieser Anordnung besteht darin, dass es verhältnismäßig einfach ist, Präsentationsinformationen, wie den Stil und Motive, einschließlich beispielsweise Logos, einfach durch Aktualisieren der Präsentationsinformationen 90 zu ändern. Eine erhebliche Neuentwicklung des verfassten Codes wird dadurch vermieden. Eine getrennte Speicherung kann das Anordnen in getrennten Dateien auf derselben Festplatte oder in physikalisch getrennten Speichergeräten einschließen.
Zum Aktualisieren der Präsentationsinformationen 90 kann es einfach erforderlich sein, in der Stilbehandlungstabelle 32, in der Motivbehandlungstabelle 33 oder in der Layoutbehandlungstabelle 35 enthaltene Daten zu ändern.
10 zeigt schematisch eine bevorzugte Ausführungsform, in der der Webserver 1 dafür eingerichtet ist, in einer Geschäftsumgebung für ein mittleres bis großes Geschäft zu arbeiten. Der Webserver 1 beinhaltet einen Herstellungsserver 100, der für die Herstellung der Webseiteninformationen ansprechend auf Abfragenachrichten von entfernten Benutzergeräten 2 und die Ausgabe von den Webseitencode aufweisenden Antwortnachrichten verantwortlich ist. Der Herstellungsserver 100 als solcher führt die vorstehend beschriebenen Funktionen aus, die vom Webserver 1 der vorhergehenden Figuren ausgeführt werden. Hierbei beinhaltet der Webserver 1 auch einen Entwicklungsserver 101, der für den Austausch zwischen dem Webserver und dem Dienstzentrum 5 und das periodische Aktualisieren des Herstellungsservers 100 mit neuer Software verantwortlich ist.
Jeder von dem Herstellungsserver 100 und dem Entwicklungsserver 101 weist einen jeweiligen Prozessor cluster auf, der eine erheblich größere Rechenleistung hat als der vorstehend beschriebene Personalcomputer 80.
Der Entwicklungsserver 101 kann als eine Reihe von Prozessoren angesehen werden, die Entwicklungs- und Stufenprozesse ausführen, wodurch ermöglicht wird, dass mehrere Testebenen auf neue Software angewendet werden, bevor die neue Software zum Herstellungsserver 100 heruntergeladen wird.
Es ist erforderlich, dass die vom Herstellungsserver 100 ausgeführte Software periodisch aktualisiert wird, um die Evolution neuer Typen des entfernten Benutzergeräts 2 zu berücksichtigen und auch um neuen Inhalt aufzunehmen, der in Form von Webseiten auszuliefern ist.
Wie in 10 dargestellt ist, unterhält das Dienstzentrum 5 eine zentrale Referenzdatenbank 102, von der Daten, wie aktualisierte Behandlungstabellen, periodisch zum Entwicklungsserver 101 übermittelt werden. Diese Datenkommunikation geschieht unter Verwendung des Internets 3, wobei eine XML-Syntax verwendet wird, um die unter Verwendung des HTTP-Protokolls übertragenen Daten zu strukturieren. Wie in 10 dargestellt ist, fordert der Entwicklungsserver 101 periodisch eine Aktualisierung der Behandlungstabellen 40 durch Ausgeben einer Abfragenachricht 103 an und empfängt die angeforderten Daten in einer Antwortnachricht 104.
Der Entwicklungsserver 101 wird beim Empfang einer Antwortnachricht 104 verwendet, um Tests an den neuen Daten auszuführen, und er kann verwendet werden, um lokale Einstellungen vorzunehmen, um beispielsweise geeignete neue Layouts hinzuzufügen.
Nach dem Testen und Modifizieren werden neue Behandlungstabellen vom Entwicklungsserver 101 über geeignete Firewalls zum Herstellungsserver 100 übermittelt.
Wenn Datenbanken im Herstellungs- und im Entwicklungsserver aktualisiert werden, ist es im Allgemeinen nicht erforderlich, den gesamten Inhalt der Datenbank zu übertragen, und es wird stattdessen sich darauf verlassen, Befehle zu editieren, welche die übertragenen Daten im HTTP-Protokoll bilden, welche von Metadaten in der XML-Syntax begleitet werden.
In 10 ist auch eine Prüfseite 105 dargestellt, deren Funktion nachstehend beschrieben wird und die einen Server darstellt, der über das Internet 3 zugänglich ist und eine URL aufweist. Der physikalische Ort der Prüfseite 105 ist in dem vorliegenden Beispiel getrennt vom Ort des Webservers 1 dargestellt.
11 zeigt schematisch die Art, in der sich der Herstellungsserver 100, die Prüfseite 105 und das Dienstzentrum 5 ansprechend darauf austauschen, dass zum ersten Mal auf ein entferntes Benutzergerät 2 eines neuen Typs getroffen wird. Der neue Typ des Geräts 2 kann beispielsweise die letzte Version eines WAP verwendenden Mobiltelefons sein und Merkmale aufweisen, die gegenüber jenen vorhergehender Modelle eines gegebenen Herstellers erweitert sind und welche beispielsweise verschiedene Anzeigefähigkeiten in der Art einer erhöhten Größe und der Fähigkeit zum Anzeigen von Farbbildern aufweisen.
Der Benutzer des neuen Geräts 2, der auf die vom Webserver 1 bereitgestellte Webseite zugreifen möchte, betätigt Browsersoftware innerhalb des Geräts zum Erzeugen einer Abfragenachricht 110, die über das Internet 3 an die URL des Herstellungsservers 100 ausgegeben wird.
Der Herstellungsserver 100 empfängt die Abfragenachricht 110 und gibt die Nachricht in die in 2 dargestellte Geräteidentifikationseinheit 29 in einem Versuch ein, eine Gerätetypidentifikation aus der im HTTP-Header der Abfragenachricht enthaltenen Identifikationszeichenkette zu extrahieren. Die Geräteidentifikationseinheit 29 stellt jedoch fest, dass die Abfragenachricht 110 einen unbekannten Identifikationsstrom enthält. Der Herstellungsserver 100 benötigt jedoch eine Gerätetypidentifikation, um das Zugreifen auf die geeigneten Behandlungstabellen zu ermöglichen, wobei die Geräteidentifikation 45 eine wesentliche Eingabe in die Codeerzeugungseinheit 21 ist, wie in 4 dargestellt ist.
Der Herstellungsserver 100 reagiert auf diese Feststellung durch die Geräteidentifikationseinheit 29 durch Erzeugen einer Umleitungsnachricht 111, die zum neuen Gerät 2 gesendet wird und das Gerät veranlasst, die Abfragenachricht 110 zur URL der Prüfseite 105 umzuleiten. Dadurch wird eine neue Abfragenachricht 112 durch das Gerät 2 ausgegeben und zur Prüfseite 105 übertragen.
Die Prüfseite 105 analysiert die in der Abfragenachricht 112 enthaltene Identifikationszeichenkette und ist in der Lage, einige Grundinformationen in Bezug auf die Kommunikationsprotokolle und Fähigkeiten des Geräts 2 zu extrahieren. Diese begrenzten Informationen sind ausreichend, um die Prüfseite 105 in die Lage zu versetzen, eine Sonde 113 in Form eines Agenten zu erzeugen, der vom Browser des Geräts 2 verarbeitet werden kann und Software bildet, die vom Prozessor des Geräts ausgeführt werden kann.
Die Sonde 113 wird in einer weiteren Nachricht 114 zum Gerät 2 übertragen, und der Browser des Geräts zeigt beim Empfang dieser Nachricht dem Benutzer eine Standard-Antwortwebseite, während die Sonde im Hintergrund arbeitet.
Die Sonde 113 veranlasst das Gerät 2, eine weitere Abfragenachricht 115 zu erzeugen, die an die Prüfseite 105 adressiert wird und die, entsprechend den von der Sonde angeforderten Informationen, detailliertere Informationen über die Fähigkeiten und Protokolle enthält, die dem Gerät 2 zugeordnet sind.
Die Prüfseite 105 antwortet auf eine weitere Umleitungsnachricht 116, die zum Gerät 2 gesendet wird und das Gerät anweist, die Abfragenachricht 110 zum Herstellungsserver 100 umzuleiten. Das Gerät 2 folgt dieser Umleitung und gibt eine weitere Abfragenachricht 117 aus.
Gleichzeitig mit dem Ausgeben der Umleitungsnachricht 116 sendet die Prüfseite 105 eine Benachrichtigung 118 zum Dienstzentrum 5, um dieses über die Existenz des neuen Geräts 2 zu informieren und die unter Verwendung der Sonde 113 in der Nachricht 115 gewonnenen Informationen weiterzuleiten.
Das Dienstzentrum 5 speichert die empfangenen Informationen zur späteren Verwendung und verarbeitet die Informationen, um eine temporäre Aktualisierungsnachricht 119 zu erzeugen, die zum Herstellungsserver 100 gesendet wird und eine Geräteidentifikation enthält, um die Codeerzeugungseinheit 21 in die Lage zu versetzen, den Webseitencode zu erzeugen, wie vom Benutzer des Geräts 2 gefordert wurde. Der Webseitencode wird dann in einer abschließenden Antwortnachricht 120 zum Benutzer gesendet.
Die vom Dienstzentrum 5 erzeugte temporäre Aktualisierungsnachricht 119 führt dem Herstellungsserver 100 die nächstliegende geeignete existierende Gerätetypidentifikation zu. Folglich ist der erzeugte Webseitencode möglicherweise nicht vollkommen für das neue Gerät 2 geeignet, kann jedoch im Wesentlichen von dem Gerät interpretiert und angezeigt werden, beispielsweise unter Verwendung von Standardeinstellungen des Browsers.
Das Dienstzentrum 5 muss dann die zentrale Bezugsdatenbank 102 mit geeigneten Informationen unter Einschluss revidierter Behandlungstabellen aktualisieren. Diese Informationen können dann in die nächste zum Entwicklungsserver 101 übermittelte Aktualisierung aufgenommen werden, um schließlich verwendet zu werden, um die Datenbank des Herstellungsservers 100 zu aktualisieren.
Auf diese Weise ist das vorstehend erwähnte System in der Lage, fortlaufend auf die Entwicklung neuer Geräte, die über das Internet auf Webseiten zugreifen, zu reagieren und sich an diese anzupassen, ohne dass es von den Herstellern der neuen Geräte notwendigerweise zuvor informiert wird oder dass ihm von ihnen direkt detaillierte technische Daten zur Verfügung gestellt werden. Das Dienstzentrum 5 kann wahlweise solche Daten anfordern, indem es den Hersteller kontaktiert, dies ist jedoch möglicherweise nicht unbedingt notwendig, um einen zufrieden stellenden Betrieb zu erhalten.
12 zeigt eine Ausführungsform, in der der Webserver 1 mit einem Cachespeicher 120 versehen ist. Ein Gateway-Server 121 wirkt als ein Gateway, der eine Schnittstelle zum Internet 3 bildet, um Abfragenachrichten von entfernten Benutzergeräten 2 zu empfangen und durch Senden des angeforderten Webseitencodes 122 entweder durch Anfordern der dynamischen Erzeugung des Webseitencodes von einem dynamischen Webseitenserver 123 oder, falls der angeforderte Webseitencode bereits als eine statische Webseite im Cachespeicher 120 existiert, durch Abrufen des Webseitencodes aus dem Cachespeicher zu reagieren.
Der dynamische Webseitenserver 123 bewirkt das dynamische Erzeugen des Webseitencodes in der vorstehend beschriebenen Art unter Verwendung der aus der empfangenen URL-Anforderung extrahierten Gerätetypidentifikation 45 und des der URL entsprechenden gespeicherten Inhaltscodes 23.
13 zeigt schematisch die vom Prozessor des Gateway-Servers 121 ausgeführten Schritte. In Schritt 130 empfängt der Gateway-Server die URL-Anforderung und extrahiert die Gerätetypidentifikation 45 und identifiziert das Dokument des Inhaltscodes 23, das die zum Erzeugen des erforderlichen Webseitencodes erforderlichen Anweisungen enthält.
In Schritt 131 fragt der Gateway-Server 121, ob der Webseitencode bereits als eine statische Webseite im Cachespeicher 120 für diese Gerätetypidentifikation und diese URL existiert und ruft in Schritt 132 den Webseitencode ab, falls dieser verfügbar ist.
Falls er nicht vom Cachespeicher 120 verfügbar ist, fordert der Gateway-Server 121 in Schritt 133 vom dynamischen Webseitenserver 123 die Erzeugung des Webseitencodes und sendet die Gerätetypidentifikation und URL-Einzelheiten.
Dementsprechend empfängt der Gateway-Server 121 in Schritt 134 den neu erzeugten Webseitencode.
In Schritt 135 gibt der Gateway-Server 121 den Webseitencode über das Internet 3 an das entfernte Benutzergerät 2 aus.
14 zeigt schematisch die Schritte, die unter der Steuerung des Prozessors des dynamischen Webseitenservers ausgeführt werden. In Schritt 140 empfängt der dynamische Webseitenserver die Anforderung zur Erzeugung des Webseitencodes und auch die Gerätetypidentifikationsinformationen und von der URL abgeleitete Informationen, die erforderlich sind, um das Dokument des Inhaltscodes 23 zu identifizieren. Der angeforderte Inhaltscode 23 wird aus dem Speicher abgerufen und in der Laufzeitumgebung 46 der Codeerzeugungseinheit 21 verarbeitet, um in Schritt 142 den erforderlichen Webseitencode zu erzeugen.
In Schritt 143 stellt der dynamische Webseitenserver 123 anhand des Inhaltscodes 23 fest, ob der sich ergebende Webseitencode als geeignet ausgezeichnet ist, im Cachespeicher 120 gespeichert zu werden, und er stellt, falls dies der Fall ist, anhand des Inhaltscodes den Zeitraum fest, während dessen die Cachespeicherversion gültig bleiben soll. Diese Informationen werden in Schritt 144 verwendet, um Metadaten zu erzeugen, die zu der Datei hinzugefügt werden, welche den Webseitencode enthält und welche in Schritt 145 an den Cachespeicher 120 ausgegeben wird, um während des Gültigkeitszeitraums gespeichert zu werden.
In Schritt 146 gibt der dynamische Webseitenserver 123 den Webseitencode an den Gateway-Server 121 aus, welcher in Schritt 134 zu empfangen ist, wie vorstehend beschrieben wurde.
Wenn der Inhaltscode 23 verfasst wird, hat der Verfasser daher die Option, zusätzliche Attribute zu canvas-Tags hinzuzufügen, um zu definieren, ob die sich ergebende Seite Cache-gespeichert werden kann und wie lange sie im Cachespeicher gültig bleiben kann. Der Cachespeicher 120 schreibt neue Cache-gespeicherte Seiten in der Art in den Speicher, die jegliche gespeicherte Seiten überschreibt, deren Gültigkeit abgelaufen ist.
In 12 ist ein Satz von Seiten des Inhaltscodes 23 schematisch zusammen mit jeweiligen Cachespeicher-Steuerdaten 124 für jede Seite dargestellt, wobei die Steuerdaten vom Verfasser der Seite festgelegt sind, um die erwähnten Anweisungen zur Einlagerung im Speicher 120 festzulegen.
Die Erzeugung von Code durch die Codeerzeugungseinheit 21 wurde vorstehend mit Bezug beispielsweise auf Anhang 1 beschrieben, worin Anweisungen dargestellt sind, die zum Erzeugen von Inhaltscode 23 zum Herstellen einer als Beispiel dienenden Webseite verwendet werden. Typischerweise erfordert die Ausführung des Inhaltscodes 23 durch die Codeerzeugungseinheit 21 wie in diesem Beispiel, dass Inhalt aus dem Datenspeicher abgerufen wird. Datenobjekte, wie Bilddateien, werden daher zur Aufnahme in den Webseitencode, der durch die Codeerzeugungseinheit 21 auszugeben ist, importiert.
Der Verfasser der Webseite kann eine Komponente verfassen, um dem Namen nach auf ein zu importierendes Datenobjekt Bezug zu nehmen. Verschiedene Versionen des Datenobjekts sind in einer Datenstruktur gespeichert, die auf eine Weise hierarchisch ist, dass verschiedene Hierarchieebenen unterschiedlichen Fähigkeiten der entfernten Benutzergeräte 2 entsprechen. Der Verfasser des Inhaltscodes 23 kann für jedes Objekt die geeignete Version definieren, die für jede Gerätetypidentifikation 45 zu verwenden ist, indem er Daten in eine Komponentenbehandlungstabelle 37 eingibt, wie in 3 dargestellt ist. Die Komponentenbehandlungstabelle kann dann der Hierarchie aus 6A folgen, um zu ermöglichen, dass die Datenobjektversion für jede mögliche Gerätetypidentifikation definiert wird. Dieser Ansatz wird nachstehend als das Definieren von Datenobjekten in Bezug auf Zielinhalt bezeichnet, weil der Verfasser des Codes auf die bestimmte Version des Datenobjekts abzielt, die für jedes entfernte Benutzergerät 2 zu verwenden ist.
Alternativ kann eine Anzahl von Versionen des Datenobjekts in einer Hierarchie mit Merkmalen jeder Version des Datenobjekts, die in zugeordneten Metadaten für jede Version beschrieben sind, bereitgestellt werden. Eine automatische Auswahl der geeigneten Version kann dann unter Verwendung eines Komponentenlogik-Softwaremoduls 150 vorgenommen werden, wie in 15 schematisch dargestellt ist.
Das Komponentenlogik-Softwaremodul 150 wählt die geeignete Version auf der Grundlage der Datenobjekt-Metadaten, Layoutüberlegungen, die von der Layoutbehandlungstabelle 35 definiert sind, und Informationen über das Gerät, die von der Gerätebehandlungstabelle 30 bereitgestellt werden, aus. Dieser Ansatz zur Auswahl der Datenobjektversion wird nachstehend als ungezielte Inhaltsauswahl bezeichnet.
Die Codeerzeugungseinheit 21 kann entweder unter Verwendung einer gezielten Inhaltsauswahl oder einer ungezielten Inhaltsauswahl arbeiten. Alternativ und bevorzugt ist die Codeerzeugungseinheit 21 in der Lage, selektiv sowohl eine gezielte Inhaltsauswahl als auch eine ungezielte Inhaltsauswahl zu verwenden und dem Verfasser dadurch die Freiheit zu geben, beim Verfassen des Inhaltscodes 23 entweder Datenobjektversionen zu definieren oder die automatische Verarbeitung der Auswahl dem Komponentenlogik-Softwaremodul 150 zu überlassen.
16 zeigt schematisch die Art, in der sowohl gezielter als auch ungezielter Inhalt verwendet werden kann. In Schritt 160 wird Inhaltscode 23 zusammen mit der Gerätetypidentifikation 45 in die Codeerzeugungseinheit 21 eingegeben, und in Schritt 161 wird die Verarbeitung des Codes eingeleitet.
In jedem Fall, in dem eine Komponente des Inhaltscodes 23 das Importieren eines Datenobjekts notwendig macht, versucht die Codeerzeugungseinheit 21 in Schritt 162, eine vom Verfasser definierte Version des Datenobjekts zu importieren. Falls in Schritt 163 festgestellt wird, dass eine solche vom Verfasser definierte Version existiert und sie erfolgreich importiert wird, wird die Verarbeitung fortgesetzt, wobei in Schritt 164 festgestellt wird, ob noch weitere Datenobjekte zu importieren sind.
Falls es jedoch in Schritt 163 nicht möglich ist, erfolgreich eine vom Verfasser definierte Version zu importieren, wird die Verarbeitung in Schritt 165 fortgesetzt, worin der Betrieb des Komponentenlogik-Softwaremoduls erforderlich ist, um die geeignete Objektversion zu identifizieren. In Schritt 165 wird dann die ausgewählte Datenobjektversion importiert, und der Codeerzeugungsprozess wird fortgesetzt. Wenn in Schritt 164 festgestellt wird, dass keine weiteren Datenobjekte zu importieren sind, wird die restliche Verarbeitung zum Erzeugen des Webseitencodes in Schritt 167 abgeschlossen, und der fertige Webseitencode wird in Schritt 168 ausgegeben.
17 zeigt schematisch die Art, in der in der Datenbank 19 gespeicherte Datenobjekte in einer hierarchischen Datenstruktur gespeichert werden, um zu ermöglichen, dass das Komponentenlogik-Softwaremodul 150 automatisch die geeignete Datenobjektversion auswählt.
Falls der Verfasser beispielsweise eine Webseite entwickelt, in der ein Videoclip in einem definierten Bereich des Bildschirms eines Benutzergeräts in Form eines Personalcomputers anzuzeigen ist, wird der Videoclip in der Datenbank 19 als ein Videodatenobjekt 170 gespeichert und ein zugeordneter Komponentenname 171 erfunden, um zu ermöglichen, dass die Codeerzeugungseinheit 21 dem Namen nach auf das Videodatenobjekt 170 Bezug nimmt. Das Videodatenobjekt 170 ist durch Metadaten 172 charakterisiert, die zusammen mit dem Datenobjekt gespeichert sind und Datenfelder enthalten, die ausreichen, damit das Komponentenlogik-Softwaremodul 150 feststellt, ob ein von der Gerätetypidentifikation 45 definiertes gegebenes Benutzergerät 2 in der Lage ist, den Videoclip von dem Datenobjekt zu empfangen und anzuzeigen.
Der Verfasser kann, wie in 17 dargestellt ist, auch verschiedene Versionen des Videodatenobjekts speichern, die für die Verwendung durch verschiedene Gerätetypen geeignet sind, welche jeweils von jeweiligen Metadaten begleitet sind.
Der Verfasser speichert auch in der Datenbank ein photographisches Bilddatenobjekt 173 mit zugeordneten Metadaten 174. Ähnlich kann der Verfasser einen Satz verwandter photographischer Bilddatenobjekte 173 mit Merkmalen speichern, die für verschiedene Gerätetypen geeignet sind und von jeweiligen Metadaten begleitet sind, Falls das Komponentenlogik-Software-modul 150 anhand der Metadaten 172 feststellt, dass keines der Videodatenobjekte von einem Benutzergerät angezeigt werden kann, für das der Webseitencode gegenwärtig vorbereitet wird, stellt das photographische Bild eine Rückfallposition dar, die es ermöglicht, dass ein statisches photographisches Bild an Stelle des Videoclips gerendert wird. Das photographische Bild zeigt daher im Allgemeinen ein verwandtes Thema und kann beispielsweise ein von dem Videoclip entnommenes Standbild aufweisen.
Der Verfasser kann auch in die Datenbank ein Graphikbild-Datenobjekt 175 mit zugeordneten Metadaten 176 eingeben. Ähnlich kann der Verfasser einen Satz verwandter Graphikbild-Datenobjekte mit jeweiligen Metadaten eingeben, die für verschiedene Gerätetypen geeignet sind. Das Graphikbild bildet eine weitere Rückfallposition, die verwendbar ist, wenn eine geeignete Version eines photographischen Bilds nicht verfügbar ist.
Der Verfasser kann auch zusätzliche Rückfallpositionen, wie einfache Textobjekte 177 mit zugeordneten Metadaten 178, eingeben. Das Textdatenobjekt 177 stellt eine letzte Rückfallposition für Situationen dar, in denen das Komponentenlogik-Softwaremodul 150 feststellt, dass selbst das Graphikbild 175 nicht vom Benutzergerät 2 gerendert werden kann.
Die Datenobjekte 170, 173, 175 und 177 werden in einer hierarchischen Datenstruktur in der Datenbank 19 gespeichert, wie schematisch in 17 dargestellt ist, wobei verschiedene Ebenen der Hierarchie Ebenen der Fähigkeiten des Benutzergeräts entsprechen. Das Textdatenobjekt 177 ist in diesem Beispiel eine Stammebene der Hierarchie, welche die niedrigste Ebene der Fähigkeiten des Benutzergeräts 2 darstellt und daher die letzte Rückfallposition darstellt.
Falls beispielsweise das Benutzergerät 2 durch die Gerätetypidentifikation 45 als ein Personalcomputer identifiziert wird, wählt das Komponentenlogik-Softwaremodul 150 das Datenobjekt 170 aus. Falls das Benutzergerät 2 als ein Pocket-PC identifiziert wird, der nicht in der Lage ist, Videoclips zu rendern, jedoch in der Lage ist, photographische Bilder zu rendern, wählt das Komponentenlogik-Softwaremodul 150 das Datenobjekt 173 aus. Falls das Benutzergerät 2 als ein Mobiltelefon mit WAP-Fähigkeiten identifiziert wird, wählt das Modul 150 das Graphikbild-Datenobjekt 175 aus. Falls jedoch das Benutzergerät 2 als ein herkömmliches Mobiltelefon ohne WAP-Fähigkeiten identifiziert wird, wird dann das Textdatenobjekt 177 ausgewählt.
Die hierarchische Datenstruktur lässt sich auch auf andere Typen von Datenobjekten anwenden, um die Auswahl geeigneter Datenobjekte zu ermöglichen, beispielsweise im Fall des eine Verknüpfung irgendeiner Art definierenden Webseitencodes. Die Verknüpfung kann eine HTML-Verknüpfung, eine WML-Verknüpfung, eine Email-Verknüpfung oder einfach eine Telefonnummer für eine Selbstwählverbindung in dem Fall, dass das Benutzergerät 2 ein Mobiltelefon ist, einschließen.
Ein weiteres Beispiel von Datenobjekten, auf die unter Verwendung desselben Komponentennamens zugegriffen werden kann, ist durch Scriptkomponenten, wie JavaScript und WML Script, gegeben, wobei derselbe Inhalt in dem geeigneten Script zur Verwendung in verschiedenen Geräten geschrieben werden kann. Der Verfasser kann daher Datenobjekte in der Vielzahl erforderlicher Scriptsprachen zur Speicherung in der hierarchischen Struktur aus 17 und zum Abruf ansprechend auf den Komponentennamen schreiben. Wie in den vorhergehenden Beispielen kann die Auswahl auf der Grundlage der jedes Datenobjekt begleitenden Metadaten auf der Grundlage der Fähigkeiten des entfernten Benutzergeräts 2 erfolgen, wie mit Bezug auf die Gerätebehandlungstabelle unter Verwendung der Geräteidentifikation 45 bestimmt wird.
Die Verwendung der vorstehend erwähnten hierarchischen Datenstrukturen stellt ein wirksames Verfahren zur Vermögensverwaltung für das System dar, wobei die Vermögensgegenstände die Sammlung von Datenobjekten einschließen, welche in Form einer Webseite durch das System geliefert werden können.
18 zeigt die Art, in der Daten in Textform in einer hierarchischen Datenstruktur gespeichert werden können, um zu ermöglichen, dass verschiedene Versionen des Texts abgerufen werden, um den Fähigkeiten des Benutzergeräts 2 und den Vorlieben des Benutzers Rechnung zu tragen. Der auf Englisch geschriebene Volltext eines Dokumentobjekts ist in einem Kästchen GB TEXT 1 gespeichert, das beispielsweise zur Anzeige auf dem Bildschirm eines PCs geeignet ist. Eine reduzierte Version des Texts, der vom Verfasser bearbeitet worden ist, wird als Datenobjekt GB TEXT 2 gespeichert, welches zur Anzeige auf einem handgehaltenen Computer mit einer reduzierten Bildschirmgröße geeignet ist. Eine noch kleinere Version des editierten Texts wird in einem Datenobjekt GB TEXT 3 gespeichert, das zur Anzeige in einem handgehaltenen Gerät mit einem begrenzten Speicher geeignet ist, und schließlich enthält GB TEXT 4 eine minimale Textversion zur Anzeige auf einem Mobiltelefon.
Jede dieser Textversionen ist auf Englisch verfasst. Entsprechend sind in der französischen Sprache verfasste Textobjekte in FR TEXT 1, FR TEXT 2, FR TEXT 3 und FR TEXT 4 enthalten. Ähnlich sind Datenobjekte, die in der deutschen Sprache verfassten Text enthalten, in DE TEXT 1, DE TEXT 2, DE TEXT 3 und DE TEXT 4 enthalten.
Die Datenobjekte werden durch den Komponentennamen 171 und eine Sprachenidentifikation 180, die in diesem Beispiel angibt, ob die englische, französische oder deutsche Textversion erforderlich ist, adressiert.
Eine Sprachenidentifikation wird zusätzlich zur Geräteidentifikation 45 in die Codeerzeugungseinheit eingegeben und typischerweise, ansprechend auf die Eingabe einer Benutzervorgabe durch den Benutzer, aus dem Körper der vom Browser des entfernten Benutzergeräts 2 erzeugten Abfragenachricht extrahiert. Jedes der Textdatenobjekte in der Art von GB TEXT 1 weist zugeordnete Metadaten 181 auf, welche die relevanten Parameter des Objekts unter Einschluss insbesondere der Größe des den Text darstellenden Codes angeben. Dadurch kann eine Entscheidung auf der Grundlage der durch die Metadaten 181 angegebenen Größe des Codes getroffen werden, ob ein gegebenes Objekt zum Abruf für ein gegebenes entferntes Benutzerendgerät geeignet ist. Das optimale Datenobjekt kann auf diese Weise ausgewählt werden, indem die hierarchische Baumstruktur aus 18 durchlaufen wird, bis das geeignete Datenobjekt lokalisiert wurde.
19 zeigt eine weitere Ausführungsform, in der ein Fensterteiler 190 bereitgestellt ist, um die von der Codeerzeugungseinheit 21 erzeugte Ausgabe zu modifizieren. Eine solche Anordnung ist vorteilhaft, um die Übertragung einer Antwortnachricht zu verhindern, die eine Codemenge aufweist, die größer ist als die verfügbare Speicherkapazität des entfernten Benutzergeräts 2. Für Geräte mit einem kleinen Speicher, wie Mobiltelefone, kann ein Überladen der verfügbaren Kapazität bewirken, dass der Mikroprozessor des Geräts abstürzt oder sich aufhängt. Wenngleich der Verfasser des ansprechend auf Anfragen von solchen Geräten bereitzustellenden Inhalts die begrenzte Speicherkapazität des Geräts bemerken kann, ist es in der Praxis schwierig, die tatsächliche Codemenge genau vorherzusagen, die von der Codeerzeugungseinheit 21 ausgegeben wird, so dass eine Lösung darin besteht, zusätzlich ein Gerät in der Art des Fenster teilers 190 hinter der Codeerzeugungseinheit 21 anzuordnen, um den abgehenden Code einzufangen und die Codemenge zu messen.
Falls die Codemenge die angegebene verfügbare Datenkapazität des Benutzergeräts 2 übersteigt, wird der Teiler 190 angeordnet, um das Dokument automatisch in eine Anzahl hier als Bruchstücke bezeichneter Fragmente aufzuteilen oder zu zerlegen.
Wie in 19 dargestellt ist, empfängt der Fensterteiler 190 die Gerätetypidentifikation 45 von der Geräteidentifikationseinheit 29 und adressiert die Gerätebehandlungstabelle, um anhand der Gerätetypidentifikation die verfügbare Speicherkapazität des Benutzergeräts 2 festzustellen.
Falls die Unterteilung des Fensters geeignet ist, wird das erste der sich ergebenden Bruchstücke vom Vorprozessor 190 ausgegeben, und die restlichen Bruchstücke werden in einem Pufferspeicher 191 gespeichert. Der Vorprozessor 190 kann dann auf anschließende Anforderungen vom Benutzergerät 2 reagieren, indem er wiederum die restlichen Bruchstücke in jeweiligen Antwortnachrichten zuführt.
20 zeigt schematisch den Prozess des Zerlegens eines Fensters, wobei der Begriff Fenster in diesem Zusammenhang verwendet wird, um eine Webseite anzugeben, die zu einem entfernten Benutzergerät 2 gesendet werden soll.
In Schritt 200 wird der das Fenster darstellende Code von der Codeerzeugungseinheit 21 auf der Grundlage der Gerätetypidentifikation 45 und der Natur der über das Internet 3 empfangenen Abfragenachricht erzeugt.
In Schritt 201 wird der von der Codeerzeugungseinheit 21 ausgegebene Code vom Fensterteiler 190 empfangen und gemessen, und in Schritt 202 greift der Fensterteiler auf die Gerätebehandlungstabelle zu, um die Datenkapazität des entfernten Benutzergeräts 2 nachzuschlagen.
In Schritt 203 stellt der Fensterteiler 190 fest, ob die Codemenge kleiner oder gleich der Datenkapazität des entfernten Benutzerendgeräts 2 ist und gibt, falls dies der Fall ist, in Schritt 204 den Code aus, ohne einen Teilungsschritt auszuführen.
Falls die Codemenge jedoch größer als die verfügbare Datenkapazität ist, unterteilt der Teiler in Schritt 205 den Code in eine Anzahl von Bruchstücken, die jeweils eine Codemenge aufweisen, die kleiner als die verfügbare Datenkapazität ist. In Schritt 206 werden die Bruchstücke des unterteilten Fensters im Pufferspeicher 191 gespeichert. In Schritt 207 wird eines der Bruchstücke zur Aufnahme in eine Antwortnachricht für das entfernte Benutzergerät 2 an den Server ausgegeben.
21 zeigt ein Fenster 210, aus dem Bereiche A, B, C, D, E und F zur Bildung von Bruchstücken 211 bis 216 ausgeschnitten sind, die jeweils getrennt im Pufferspeicher 191 gespeichert werden und in getrennten Antwortnachrichten zum entfernten Benutzergerät 2 übertragen werden können.
22 zeigt die zusätzliche Verwendung eines nachstehend als Benutzersitzungsspeicher 220 bezeichneten Speichers zum Speichern von Informationen, die eine Benutzersitzung definieren, wobei die Nachrichten zwischen dem Server und dem Benutzergerät 2 fragmentiert werden, um die begrenzte Datenkapazität des Benutzergeräts zu berücksichtigen.
Ein typisches Beispiel eines Falls, in dem eine solche Anordnung geeignet ist, ergibt sich, wenn ein Formular in einer Benutzersitzung auszufüllen ist. Für Geräte hoher Kapazität, wie Personalcomputer, ist es üblich, dass ein Formular dem Benutzer in einem einzigen Bildschirm bereitgestellt wird und dass das Formular mehrere Felder zum Ausfüllen durch den Benutzer enthält.
Beispielsweise definiert in 23 das Formular 230 mehrere Datenfelder 231. Für ein Gerät 2 mit einer begrenzten Kapazität kann es erforderlich sein, das Formular in eine Anzahl von Fragmenten 232 bis 237 zu unterteilen, die Abschnitte A, B, C, D, E bzw. F des Formulars 230 enthalten.
Während einer Benutzersitzung wird das Formular 230 in die Fragmente 232 bis 237 zerlegt, und der entsprechende Code für jedes Fragment wird im Puffer 191 gespeichert. Anfänglich wird nur das Fragment 232 zum Benutzergerät 2 übertragen, und der Benutzer antwortet mit einer Antwortnachricht, die durch den Server 1 verarbeitet wird. Die Antwort, die im Bereich A des Formulars enthaltenen Datenfeldern entspricht, wird im Benutzersitzungsspeicher 220 gespeichert. Das nächste Fragment 233 wird zum Benutzergerät gesendet, und die entsprechende Antwort wird im Benutzersitzungsspeicher gespeichert. Dieser Prozess wird wiederholt, bis das letzte Fragment 237 übertragen wurde. Die Antwort auf dieses Fragment F des Formulars beinhaltet die Betätigung einer Absendetaste 238. Falls die Betätigung der Absendetaste 238 in der letzten Antwortnachricht enthalten ist, sind die im Benutzersitzungsspeicher 220 erforderlichen Informationen vollständig, und der vollständige Datensatz von der Ausfüllung des Formulars wird an eine Datenverarbeitungsanwendung 239 übergeben.
Die Art, in der das Formular in die Bereiche A, B, C, D, E und F unterteilt wird, wird als Teil der Layoutbehandlungsvorschrift durch den Verfasser definiert.
Der zum Benutzergerät 2 übertragene Code beinhaltet typischerweise auch Scriptdefinitionsanweisungen zum Betätigen des Browsers des entfernten Benutzergeräts 2, um eine Validierung und Gültigkeitsprüfung während des Ausfüllens des Formulars vom Benutzer eingegebener Daten vorzunehmen. Das Script wird von der Codeerzeugungseinheit 21 auf der Grundlage der vom Verfasser geschriebenen Tags erzeugt, wobei darin eine Definition von Validierungsregeln enthalten ist, die auf die während des Ausfüllens des Formulars vom Benutzer eingegebenen Daten anzuwenden sind.
Falls ein Datenfeld beispielsweise als ein numerisches Feld angegeben ist, können numerische Wertegrenzen für Validierungszwecke verwendet werden.
Die Art, in der der Scriptcode von der Codeerzeugungseinheit 21 erzeugt wird, hängt von der Version der Scriptsprache ab, die für das entfernte Benutzergerät 2 geeignet ist, wie durch die Protokollbehandlungsvorschrift angegeben wird.
In einem weiteren Beispiel ist das Benutzergerät 2 von einem Typ mit einer begrenzten Verarbeitungsleistung in der Art eines Mobiltelefons, wobei Validierungsregeln durch Software angewendet werden, die im Prozessor oder in der SIM-Karte des Geräts existiert. In diesem Fall braucht die Codeerzeugungseinheit 21 kein Script für die Übertragung zum Gerät zu erzeugen, um die Validierungsschritte auszuführen, weil es ausreicht, Validierungsparameter in einem von der existierenden Software innerhalb des Benutzergeräts vorgeschriebenen Format bereitzustellen.
Wenn auf ein entferntes Benutzergerät 2 angesprochen wird, welches ein Protokoll verwendet, das Stylesheets unterstützt, kann der Verfasser spezifizieren, dass ein Stylesheet von der Codeerzeugungseinheit 21 zu erzeugen ist. Das Stylesheet kann über mehrere Seiten gemeinsam verwendet werden. Für jene Geräte, bei denen das verfügbare Protokoll Stylesheets nicht unterstützt, wird zusätzlicher Code durch die Codeerzeugungseinheit 21 erzeugt, um eine sichtbare Wirkung in den sich ergebenden angezeigten Seiten zu erzeugen, wodurch die vom Verfasser definierte Style-Sheet-Definition emuliert wird.
Beispielsweise können HTML-4-Browser Stylesheets auf empfangenes HTML anwenden, während dies HTML-3-Browser nicht können. HTML-3-Browser müssen daher zusätzlichen HTML-Code empfangen, der Font-, Farb- und andere Merkmale hinzufügt, um die gleiche Wirkung zu erreichen, die von dem Stylesheet bereitgestellt wird.
Der Verfasser muss die Style-Sheet-Informationen definieren, und die Codeerzeugungseinheit 21 erzeugt, falls erforderlich, automatisch den zusätzlichen Code, der erforderlich ist, falls Stylesheets nicht unterstützt werden.
Einige Benutzergeräte stellen keine Sichtanzeige bereit, wie es beispielsweise bei jenen Geräten der Fall ist, welche für sehbehinderte Benutzer ausgelegt sind. Diese Geräte werden typischerweise von einem Dienstanbieter bedient, der einen Sprachbrowser auf einem seiner Computer betreibt, wodurch empfangener HTTP-Code in Sprachnachrichten übermittelnde Kommunikationssignale umgewandelt wird. Ein solcher Dienstanbieter könnte daher als eine Zwischenstelle zwischen dem Server 1 und dem entfernten Benutzergerät 2 gemäß den vorstehenden Ausführungsformen wirken. Der ausgegebene Webseitencode könnte dann vorteilhafterweise in voiceXML von der Codeerzeugungseinheit ausgegeben werden.
24 zeigt eine der Funktionen der graphischen Benutzerschnittstelle 4, die verwendet wird, wenn während der Verfassung von Webseiten erzeugte Dateien gespeichert werden. Eine übliche Situation ergibt sich, wenn dasselbe Hintergrundbild und derselbe Text in Webseiten aufzunehmen sind, die zu einer Anzahl verschiedener Gerätetypen, die unterschiedliche Formate erfordern, herunterzuladen sind. Ein Datenumwandler 241 ist gemäß einer weiteren Ausführungsform der vorliegenden Erfindung vorgesehen, um den Verfasser bei der Erzeugung geeigneter Dateien zu unterstützen. Wie in 24 dargestellt ist, ist ein Verfassungspaket 240 mit einem Datenumwandler 241 zum Umwandeln einer vom Verfassungspaket ausgegebenen Datendatei in einen Satz von Dateien versehen, die durch einen Dateimanager 242 in der Datenstruktur gespeichert werden.
25 zeigt die Schritte in dem Verfahren zum Betreiben der Elemente aus 24. In Schritt 250 empfängt der Datenumwandler 241 vom Verfassungspaket 240 eine Datei, die Daten enthält, welche als ein Datenobjekt zu speichern sind. Beispielsweise umfasst diese Datendatei ein Bild im GIF-Format.
In Schritt 251 bestimmt der Datenumwandler 241 den Datentyp (d.h. ob es sich um ein Bild, um Text oder einen anderen Datentyp handelt) und bezieht sich auf die Gerätebehandlungstabelle 30, um anhand des Werts der Gerätetypidentifikation 45 eine Liste verschiedener Dateiformate zu bestimmen, die während des Betriebs der Codeerzeugungseinheit 21 erforderlich sein können.
In Schritt 253 erzeugt der Datenumwandler 241 für jedes dieser Formate in der Liste eine umgewandelte Datei mit dem geeigneten Format und zugeordneten Metadaten. In Schritt 243 speichert der Dateimanager 242 die Dateien in der Datenstruktur.
Diese Anordnung ermöglicht es dem Verfasser, Text- und Graphikparameter nur einmal einzugeben, und der Datenumwandler und der Dateimanager können dann die Aufgabe übernehmen, Sätze von Dateien in verschiedenen Formaten zur Speicherung und anschließenden Verwendung als Datenobjekte zu erzeugen.
Die vorstehend beschriebenen Ausführungsformen haben sich auf Implementationen bezogen, bei denen beispielsweise JAVA verwendet wurde. Alternativen zu JAVA können beim Implementieren der vorliegenden Erfindung verwendet werden, und die Referenzen auf JAVA, JAVA beans und JAVA virtual machine sind nicht als den Schutzumfang der Erfindung einschränkend anzusehen.
Die vorliegende Erfindung kann durch ein Computerprogramm implementiert werden, das in Zusammenhang mit einem Webserver auf einem Computer ausgeführt wird. Ein Aspekt der vorliegenden Erfindung sieht demgemäß ein Speichermedium vor, das vom Prozessor implementierbare Anweisungen zum Steuern eines Prozessors, damit dieser das vorstehend beschriebene Verfahren ausführt, speichert.
Überdies kann das Computerprogramm in elektronischer Form beispielsweise durch Herunterladen des Codes über ein Netzwerk in der Art des Internets erhalten werden. Gemäß einem anderen Aspekt der vorliegenden Erfindung ist ein elektrisches Signal bereitgestellt, das vom Prozessor implementierbare Anweisungen zum Steuern eines Prozessors übertragen kann, um das vorstehend beschriebene Verfahren auszuführen.
Die vorliegende Erfindung hat andere Anwendungen auf Netze als das Internet unter Einschluss privater Netze und weiterer öffentlicher Netze.
Die Behandlungstabellen, die eigens eingerichteten Tags und die Codeerzeugungseinheit können als Softwareprodukte entweder getrennt oder in Kombination als eine Softwareausstattung bereitgestellt werden und stellen weitere Aspekte der vorliegenden Erfindung, ob in einem Speichermedium oder in Form elektrischer Signale verwirklicht, dar.
Die in 6 erwähnten Gerätenamen umfassen in den Schichten 63, 64 und 65 die Namen von Gerätetypen, die hiermit als Warenzeichen anerkannt werden.
Anhang 1 – für das Volantis-Produkt verfasste canvas

<%@ include file="Volantis.jsp" %>
<vt:canvas layoutName="eportal" themeName = "theme1>
<vt:anchor href="TestPortal.jsp" pane="logo1" image="stars"/>
<vt:logo pane="logo2" src="volantis" alt="volantis"/>
<vt:welcome pane="welcome"/>
<vt:h2 pane="shop">Kaufen Sie tolle Dinge bei
<a href="shopcart.jsp">Shop Volantis</a></vt:h2>
<vt:Headline pane="headlines" show="2"/>
<vt:Content pane="cpynews"/>
</vt:canvas>

Anhang 2 – zu einem Personalcomputer unter Verwendung von HTML gesendete Ergebnisseite

<html>
<head>
<link REL=STYLESHEET HREF="css/JSP-Styles.css" TYPE="text/css">
<script language="JavaScript">
<!-
//--></script>
</head>
<body>
<table border=0 cellpadding=0 columns=2><tr>
<td align=center valign=top>
<table border=0 cellpadding=0 columns=1>
<tr><td align=center valign=top>
<table border=0 cellpadding=0 columns=1>
<tr><td align=center valign=top>
<table border=0 cellpadding=0 columns=2><tr>
<td align=center valign=top>
<table border=0 cellpadding=0><tr>
<td>
<a href="TestPortal.jsp">
<img src="images/stars0.jpg"/>
</a>
</td></tr></table>
</td>
<td align=center valign=top>
<table border=0 cellpadding=0><tr>
<td>
<img src="images/volantis0.jpg" alt="volantis">
</td></tr></table>
</td>
</tr></table>
</td></tr>
<tr><td align=center valign=top>
<table border=0 cellpadding=0><tr>
<td>
<hr><b>Willkommen bei Volantis, Rhys
Lewis</b>
Sie können Ihre Nachrichtenvorlieben festlegen
<a href=e_setupnewsdevice.adp>hier</a>
<br><hr>
</td></tr></table>
</td></tr>
<tr><td align=center valign=top>
<table border=0 cellpadding=0><tr>
<td>
<h2>Kaufen Sie tolle Dinge bei <a href="shopcart.jsp">Shop Volantis</a></h2>
</td></tr></table>
</td></tr>
</table
</td></tr>
<tr><td align=center valign=top>
<table border=0 cellpadding=0 columns=2><tr>
<td align=center valign=top>
<table border=0 cellpadding=0><tr>
<td>
<table align=right border=0>
<tr><td><table borderwidth=1 bordercolor=cyan><tr><th class=headline align=left>XML- und Metadatennachrichten</th></tr>
<tr><td><a href=clickthru.jsp?cat=278&url=http://c.moreover.com/click/here.pl?x8102028> ThinkersGroup.com beendet den Betatest von Web-To-Wireless Application</a></td></tr>
<tr><td class=sub>07 Jul 2000 08:05AM</td></tr>
<tr><td><a href=clickthru.jsp?cat=278&url=http://c.moreover.com/click/here.pl?x8099873>XSL gibt Ihrem XML Stil</a></td></tr>
<tr><td class=sub>07 Jul 2000 06:59AM</td></tr>
</table></td></tr>
<tr><td><table borderwidth=1 bordercolor=cyan><tr><th class=headline align=left>Nachrichten aus dem Drahtlosgebiet</th></tr>
<tr><td><a href=clickthru.jsp?cat=277&url=http://c.moreover.com/click/here.pl?x8102312>Nokia und C&W verbünden sich, um mobile Internetdienste anzubieten</a></td></tr>
<tr><td class=sub>07 Jul 2000 08:16AM</td></tr>
<tr><td><a href=clickthru.jsp?cat=277&url=http://c.moreover.com/click/here.pl?x8102269>NASDAQ-Vorschau: Qualcomm wird bald seine Hausaufgaben beenden und könnte sich dann verdoppeln</a></td></tr>
<tr><td class=sub>07 Jul 2000 08:15AM</td></tr>
</table></td></tr>
<tr><td><table borderwidth=1 bordercolor=cyan><tr><th class=headline align=left>Hochtechnologie-Berichte</th></tr>
<tr><td><a href=clickthru.jsp?cat=273&url=http://c.moreover.com/click/here.pl?x8102034>PRIMUS Telecommunications und Inktomi schmieden strategische Allianz zum Aufbauen der globalen Infrastruktur für Streaming-Medien</a></td></tr>
<tr><td class=sub>07 Jul 2000 08:05AM</td></tr>
<tr><td><a href=clickthru.jsp?cat=273&url=http://c.moreover.com/click/here.pl?x8098274>Jesse Berst's Anchordesk: Das lange Warten auf Webtelefone</a></td></tr>
<tr><td class=sub>07 Jul 2000 06:19AM</td></tr>
</table
</td></tr></table>
</td>
<td align=center valign=top>
<table border=0 cellpadding=0><tr>
<td>
<table width=100% align=top>
<tr><td colspan=2><h2>Informix aktualisiert die Java-Datenbank</h2></td></tr>
<tr><td width=30% valign=top align=left><img src=database.gif border=0></td>
<td width=70%><p><b>Informix</b> (NASDAQ: IFMX) sagt, dass es seine Java-basierte Datenbank Cloudscape verbessert hat, um Windows CE und Pocket PC un unterstützen. Zusätzlich zum Hinzufügen von Plattformen weist Cloudscape 3.5 eine größere Sicherheit auf.</p>
<p>Cloudscape 3.5 besteht aus dem Cloudscape-Datenbankverwaltungssystem, Cloudsync zur Daten- und Anwendungssynchronisation und Cloudconnector, einem Serverrahmenwerk für Internetverbindungen zum Cloudscape-Datenbankverwaltungssystem.</p>
<p>Die Firma demonstriert die Aktualisierung auf der diese Woche in San Francisco stattfindenden JavaOne-Konferenz. Sie wird im Juli 2000 im Handel erhältlich sein. Die Serverpreise beginnen bei 1999 $.</p> </td></tr>
<tr><td colspan=2><h2>AT&T Wireless und Nortel testen GPRS</h2></td></tr>
<tr><td width=30% valign=top align=left><img src=wireless.gif border=0></td>
<td width=70%><p>AT&T Wireless Services (NYSE: AWE) und Nortel Networks (NYSE/TSE: NT) sagen, dass sie mit dem Testen des breitbandigeren General Packet Radio Service (GPRS) in den USA in diesem Sommer beginnen werden und an der schließlichen Auslieferung schnellerer Dienste der dritten Generation (3G) arbeiten.</p>
<p>Die GPRS-Tests werden in diesem Sommer in mehreren ungenannten größeren Städten der USA beginnen, wie die Firmen in einer Ankündigung gesagt haben. Die Firmen arbeiten zusammen, um schließlich die vollständige 3G-TDMA-EDGE-Technologie einzuführen.</p>
<p>"Diese Tests unter Verwendung der GPRS-Kernnetzlösungen von Nortel Networks sind ein wichtiger Schritt bei der Entwicklung von TDMA-EDGE und unterstreichen den schnellen Fortschritt, den die Industrie macht", sagte Roderick Nelson, Chefentwickler von AT&T Wireless Services. Das Endziel besteht darin, den Kunden der Firma weltweit eine breitbandige drahtlose Abdeckung anzubieten, wie er hinzufügte.</p>
<p>Die Firmen haben keine spezifischen Einzelheiten darüber gegeben, wann der GPRS-Dienst im Handel erhältlich sein wird.</p>
</td></tr>
</table>
</td></tr></table>
</td>
</tr></table>
</td></tr>
<tr><td align=center valign=top>
<table border=0 cellpadding=0><tr>
<td>
</td></tr></table>
</td></tr>
</table
</td>
<td align=Left valign=Center>
<table border=0 cellpadding=0><tr>
<td>
</td></tr></table>
</td>
</tr></table>
</body></html>

Anhang 3 – Ergebnisseite zu einem internetfähigen Mobiltelefon gesendet

<?xml version="1.0"?><!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml">
<wml><card>
<table align="center" columns="2"><tr>
<td>
<p>
<a href="TestPortal.jsp">
<img src="images/stars10.bmp"/>
</a>
</p>
</td>
<td>
<b>volantis</b>
</td>
</tr></table>
<p><em><a href="list1tmp1475618599.wml">Firmennachrichten </a></em></p>
<p><em><a href="list1tmp1484083075.wml">Schlagzeilen </a></em></p>
<p><a href="LoginForm.jsp">Bitte melden Sie sich an</a></p>
</card></wml>

Anhang 4 – das zum Festhalten der Firmennachrichten automatisch erzeugte Deck

<?xml version="1.0"?><!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "httpd://www.wapforum.org/DTD/wml_1.1.xml">
<wml><card>
<p><em><a href="list2tmp302605028.wml">Informix verbessert die Java-Datenbank</a></em></p>
<p><em><a href="list2tmp299142288.wml">AT&T Wireless und Nortel testen GPRS</a></em></p>
</card></wml>

Anhang 5 – das zum Festhalten des Berichts über AT&T automatisch erzeugte Deck

<?xml version="1.0"?><!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "httpd://www.wapforum.org/DTD/wml_1.1.xml">
<wml><card>
<p><em>AT&T Wireless und Nortel testen GPRS</em></p><p>AT&T Wireless Services (NYSE: AWE) und Nortel Networks (NYSE/TSE: NT) und Nortel sagen, dass sie mit dem Testen des breitbandigeren General Packet Radio Service (GPRS) in den USA in diesem Sommer beginnen werden und an der schließlichen Auslieferung schnellerer Dienste der dritten Generation (3G) arbeiten.</p>
<p>Die GPRS-Tests werden in diesem Sommer in mehreren ungenannten größeren Städten der USA beginnen, wie die Firmen in einer Ankündigung gesagt haben. Die Firmen arbeiten zusammen, um schließlich die vollständige 3G-TDMA-EDGE-Technologie einzuführen.</p>
<p>"Diese Tests unter Verwendung der GPRS-Kernnetzlösungen von Nortel Networks sind ein wichtiger Schritt bei der Entwicklung von TDMA-EDGE und unterstreichen den schnellen Fortschritt, den die Industrie macht", sagte Roderick Nelson, Chefentwickler von AT&T Wireless Services. Das Endziel besteht darin, den Kunden der Firma weltweit eine breitbandige drahtlose Abdeckung anzubieten, wie er hinzufügte.</p>
<p>Die Firmen haben keine spezifischen Einzelheiten darüber gegeben, wann der GPRS-Dienst im Handel erhältlich sein wird.</p>
</card></wml>

Claims

Vorrichtung (1) zum Beantworten einer Abfragenachricht von einem entfernten Benutzergerät (2) aus nach Webseiteninformationen mittels Erzeugen von Webseitencode, der vom Benutzergerät übersetzbar ist, zur Anzeige einer oder mehrerer Webseiten und zur Ausgabe einer den Webseitencode umfassenden Antwortnachricht, wobei die Vorrichtung umfaßt: eine Extraktionseinrichtung (29, 20) zum Extrahieren aus der Abfragenachricht von Informationen, die eine Gerätetypidentifikation bestimmen, welche das entfernte Benutzergerät als eines aus einer Menge von möglichen Gerätetypen mit verschiedenen technischen Merkmalen identifiziert; einen Prozessor (20) zum Betreiben einer Codeerzeugungseinheit (21) für die Erzeugung von Webseitencode; eine erste Speichereinrichtung (22, 23) zum Speichern der Webseiteninformationen als ein Inhaltsdokument, das eine Menge von in einer Scriptsprache geschriebenen Instruktionen (42) zur Erzeugung des Webseitencodes umfaßt; und eine zweite Speichereinrichtung (22, 25) zum Speichern von geräteabhängigen Informationen für jeden Gerätetyp aus der Menge der verschiedenen Gerätetypen; wobei die Codeerzeugungseinheit eine Übersetzungseinrichtung (40, 41, 44) zum Übersetzen der Instruktionen unter Bezug auf der Gerätetypidentifikation entsprechende auswählte geräteabhängige Information umfaßt, wodurch die Codeerzeugungseinheit dazu ausgelegt ist, den Webseitencode in einer Form zu erzeugen, in der dieser auf das entfernte Benutzergerät zugeschnitten ist; wobei die Vorrichtung ferner umfaßt: eine Codemeßeinrichtung (190) zum Messen der Menge von Code, der eine Seite repräsentiert, die von der Codeerzeugungseinheit erzeugt wurde; eine Feststellungseinrichtung (190) zum Feststellen, ob die technischen Merkmale des Benutzergeräts eine ausreichende Datenkapazität beinhalten, um die gemessene Menge von Code unterzubringen, und eine Aufteilungseinrichtung (190) zum Aufteilen des Codes in zwei oder mehrere Codeanteile bei einer negativen Feststellung, so daß jeder Anteil einen entsprechenden Anteil (211 bis 216) der Seite repräsentiert und eine Codemenge innerhalb der Datenkapazität des Benutzergeräts umfaßt.
Vorrichtung nach Anspruch 1, wobei die Scriptsprache eine erste Auszeichungssprache umfaßt.
Vorrichtung nach Anspruch 2, wobei das Inhaltsdokument die anzuzeigende Information definierenden Inhaltscode und vordefinierte Tags (43) zum Steuern der Darstellung der anzuzeigenden Information umfaßt; wobei die Übersetzungseinrichtung dazu ausgelegt ist, jeden Tag unter Bezug auf die ausgewählte geräteabhängige Information (40) zu übersetzen.
Vorrichtung nach Anspruch 3, wobei die geräteabhängige Information als eine Menge von Tabellen (40) gespeichert ist und wobei die Geräte abhängige Information in eine Menge von Objekten (41) aufgenommen ist, die den Tags in einer Laufzeitumgebung (46) der Codeerzeugungseinheit zugänglich sind.
Vorrichtung nach Anspruch 4, wobei die Laufzeitumgebung eine JAVA Virtual Machine (46) umfaßt und die Objektmenge JAVA Beans (41) umfaßt.
Vorrichtung nach einem der Ansprüche 4 oder 5, wobei die Tabellen in einen hierarchischen Baum (61–65) definierender hierarchischen Form sind, in dem Knoten den jeweiligen Gerätetypen in aufeinanderfolgenden hierarchischen Schichten entsprechen.
Vorrichtung nach Anspruch 6, wobei jede Gerätetypknoten von entsprechenden Einträgen in jeder der Tabellen repräsentiert ist, um solche Merkmale des Gerätetyps zu definieren, die sich von Merkmalen eines Elternknotens, von dem der Gerätetypknoten abzweigt, unterscheiden.
Vorrichtung nach einem der Ansprüche 4 bis 7, wobei die Menge von Tabellen eine technische Merkmale jedes Gerätetyps definierende Gerätebehandlungstabelle (30) umfaßt.
Vorrichtung nach einem der Ansprüche 4 bis 8, wobei die Menge von Tabellen eine Protokollbehandlungstabelle (31) umfaßt, die das Format des von der Codeerzeugungseinheit erzeugten Webseitencodes definiert.
Vorrichtung nach einem der vorhergehenden Ansprüche, wobei der Webseitencode in einer zweiten Auszeichnungssprache erzeugt ist.
Vorrichtung nach Anspruch 10, umfassend eine Einrichtung zur Auswahl der zweiten Auszeichnungssprache in Übereinstimmung mit der ausgewählten geräteabhängigen Information in der Protokollbehandlungstabelle aus einer Anzahl von Auszeichnungssprachen, die zumindest HTML und WML umfassen.
Vorrichtung nach einem der Ansprüche 4 bis 11, wobei die Menge von Tabellen eine Stilbehandlungstabelle (32) umfaßt, die den Darstellungsstil der Webseiteninformation definiert.
Vorrichtung nach Anspruch 12, wobei die Stilbehandlungstabelle Merkmale definiert, die zumindest eines der folgenden enthalten: (a) Fontmerkmale, (b) Farbe und (c) Hintergrund.
Vorrichtung nach einem der Ansprüche 4 bis 13, wobei die Menge von Tabellen eine Motivbehandlungstabelle (33) umfaßt, die mindestens eines der folgenden Merkmale definiert: (a) dekorative Merkmale und (b) ein Logo.
Vorrichtung nach einem der Ansprüche 4 bis 14, wobei die Menge von Tabellen eine Layoutbehandlungstabelle (35) umfaßt, die für jeden Gerätetyp das Layout der Webseiteninformation unter Bezug auf eine Darstellungsfläche jedes Gerätetyps definiert.
Vorrichtung nach Anspruch 15, wobei die Layoutbehandlungstabelle das Layout unter Bezug auf eine Menge von Fenstern (50) definiert, die Teile der Anzeigefläche umfassen und entsprechende Anteile der Webseiteninformation enthalten.
Vorrichtung nach Anspruch 16, wobei die Layoutbehandlung für jeden Gerätetyp die Anzahl und Konfiguration von Fenstern bestimmt.
Vorrichtung nach Anspruch 17, wobei, bei einem Gerätetyp mit minimaler Bildschirmfläche, die Layoutbehandlung die Seitenkonfiguration als eine Menge von Decks (51 bis 53), die einzelne Fenster (51 bis 53) umfassen, zur Benutzung bei der Anzeige der Webseiteninformation mittels aufeinanderfolgender Anzeige der Decks festlegt.
Vorrichtung nach einem der Ansprüche 4 bis 18, wobei der Inhaltscode mindestens einen eine entsprechende Datenkomponente identifizierenden Komponentennamen (171) umfaßt und wobei die Vorrichtung eine Datenstruktur umfaßt, in der mindestens eine Datenkomponente als eine Menge von Datenobjekten (170, 173, 175, 177) existiert, die mehrere Versionen der Datenkomponente definieren, wobei die Datenobjekte verschiedene für verschiedene entfernte Benutzergeräte geeignete Dateneigenschaften haben.
Vorrichtung nach Anspruch 19, umfassend eine Einrichtung zur Auswahl eines Datenobjekts aus der Menge von Datenobjekten, die durch einen Komponentennamen für die Einbindung in dem Webseitencode auf der Basis der Gerätetypidentifikation identifiziert wird.
Vorrichtung nach Anspruch 20, wobei die Auswahleinrichtung eine Komponentenbehandlungstabelle (37) für die Suche nach einer vorgegebenen Auswahl eines Datenobjekts umfaßt.
Vorrichtung nach Anspruch 20, wobei die Auswahleinrichtung dazu ausgelegt ist, die technischen Merkmale des entfernten Benutzergeräts zu bestimmen und das Datenobjekt durch Vergleich der technischen Merkmale mit Dateneigenschaften jedes Datenobjekts auszuwählen.
Vorrichtung nach Anspruch 22, wobei die Auswahleinrichtung dazu ausgelegt ist, die technischen Merkmale durch Rückgriff auf eine Gerätebehandlungstabelle (30) zu bestimmen.
Vorrichtung nach Anspruch 22 oder 23, wobei die Datenobjekte in einer Datenstruktur, in der Metadaten (172, 174, 176, 178) in Verbindung mit jedem Datenobjekt gespeichert sind, gespeichert werden und wobei die Dateneigenschaften jedes Datenobjekts durch die entsprechenden Metadaten definiert sind.
Vorrichtung nach einem der Ansprüche 16 bis 18, umfassend eine grafische Benutzeroberfläche (4) zum Empfangen von Benutzereingaben und eine auf die grafische Benutzeroberfläche ansprechende Dokumentverfassungseinrichtung (240) zum Erschaffen von Dokumenten aus den Webseitenerzeugungsinstruktionen.
Vorrichtung nach Anspruch 25, wobei die Verfassungseinrichtung eine Einrichtung zum Empfang von Daten und eine Datenumwandlungseinrichtung (241) zum Umwandeln der Daten in eine Menge von Datenobjekten umfaßt, die jeweils eine für die technische Merkmale eines entsprechenden Gerätetyps geeignete entsprechende Version der Daten enthalten.
Vorrichtung nach Anspruch 26, wobei die Menge von Datenobjekten ferner mehrere einer Menge von verfügbaren Benutzervorgaben entsprechende Versionen umfaßt.
Vorrichtung nach Anspruch 27, umfassend eine Einrichtung zum Bestimmen einer Benutzervorgabe aus der Abfragenachricht, wobei die Auswahleinrichtung ferner dazu ausgelegt ist, daß Datenobjekt entsprechend der Benutzervorgabe auszuwählen.
Vorrichtung nach Anspruch 28, wobei die mehreren Versionen Versionen in jeder Sprache aus einer Menge von Sprachen umfassen und wobei die Benutzervorgabe eine Vorzugssprache umfaßt.
Vorrichtung nach Anspruch 8, wobei die Festlegungseinrichtung dazu ausgelegt ist, die technischen Merkmale durch Rückgriff auf die Geräte-Behandlungstabelle zu bestimmen.
Vorrichtung nach einem der vorhergehenden Ansprüche, umfassend einen Pufferspeicher (191) zum Speichern der Teile des Codes für die darauffolgende Übertragung an das Benutzergerät.
Vorrichtung nach Anspruch 31, umfassend einen Sitzungsspeicher (220) zum Speichern von Kundendaten, die in aufeinanderfolgenden Nachrichten vom Benutzergerät in Antwort auf aufeinanderfolgende Übertragungen der entsprechende Teile des Fensters repräsentierenden Teile des Codes empfangen wurden, und einen Einrichtung zum Kombinieren von Kundendaten für eine abgeschlossene Sitzung, in der Kundendaten für alle Teile des Fensters empfangen wurden, als ein einzelnes Datenobjekt.
Vorrichtung nach Anspruch 32, wobei das Fenster ein Formular (239) definiert und wobei die Teile des Fensters entsprechende Datenfelder des Formulars umfassen.
Vorrichtung nach einem der Ansprüche 4 bis 18, wobei die Menge von Tabellen eine dynamische Behandlungstabelle (36) umfaßt, die Code-Erzeugungsmerkmale definiert, die entsprechend den Werten von zeitveränderlichen Parametern bestimmt sind.
Vorrichtung nach Anspruch 34, wobei die Code-Erzeugungsmerkmale Bildinhalt des Webseitencodes definieren und der zeitveränderliche Parameter die für die Kommunikation mit dem Gerät verfügbare Bandbreite ist.
Vorrichtung nach einem der vorhergehenden Ansprüche, umfassend einen Cachespeicher (120), der dazu ausgelegt ist, eine Kopie von in einer Antwortnachricht ausgegebenem Webseitencode zu speichern; und eine Einrichtung (121) zur Ausgabe von Webseitencode aus der gespeicherten Kopie in Antwort auf das Empfangen einer weiteren Abfragenachricht für dieselbe Webseiteninformation.
Vorrichtung nach Anspruch 36, wobei der Cachespeicher dazu ausgelegt ist, Webseitencode in ausgewählter Weise und abhängig davon zu speichern, ob eine Maßgabe für Cachespeicherung in dem Inhaltsdokument definiert ist, aus dem der Webseitencode erzeugt wird.
Vorrichtung nach Anspruch 37, wobei die Maßgabe zur Cachespeicherung durch die Betätigung eines im Inhaltsdokument eingefügten Tags gesetzt ist.
Vorrichtung nach Anspruch 38, wobei der Tag ferner eine Gültigkeitsdauer der Kopie des im Cachespeicher gespeicherten Webseitencodes definiert.
Vorrichtung nach einem der vorhergehenden Ansprüche, wobei die Extraktionseinrichtung dazu ausgelegt ist, Identifikationsinformationen aus einem Header der Abfragenachricht zu extrahieren und die Gerätetypidentifikation durch Rückgriff auf eine Tabelle von Gerätetypidentifikationen zu bestimmen, für die geräteabhängige Informationen in der zweiten Speichereinrichtung gespeichert sind.
Vorrichtung nach Anspruch 40, wobei die Extraktionseinrichtung dazu ausgelegt ist, für die aus dem Header erhaltene Identifikationsinformation, aus der Tabelle zu bestimmen, ob eine entsprechende Gerätetypidentifikation verfügbar ist, und, falls nicht, einen Hinweis zu erzeugen, daß das Benutzergerät unerkannt ist.
Vorrichtung nach Anspruch 41, umfassend eine auf den Hinweis, daß das Benutzergerät unerkannt ist, ansprechende Prüfeinrichtung zum Senden eines Prüfagenten (113) an das Benutzergerät zum Extrahieren von Geräteinformationen und eine Einrichtung zum Empfangen einer Antwortnachricht (115), die die Geräteinformationen vom Benutzergerät enthält.
Vorrichtung nach Anspruch 42, umfassend eine Einrichtung zum Vergleichen der empfangenen Geräteinformationen mit gespeicherten geräteabhängigen Informationen für bekannte Geräte und eine Einrichtung zum Bestimmen einer Gerätetypidentifikation, die einer besten Übereinstimmung zwischen den geräteabhängigen Informationen für bekannte Geräte und den Geräteinformationen für das unerkannte Gerät entspricht.
Vorrichtung nach Anspruch 43, wobei die Codeerzeugungseinheit dazu ausgelegt ist, Webseitencode unter Benutzung der Gerätetypidentifikation des bekannten Geräts zu erzeugen, das als eine beste Übereinstimmung mit dem unerkannten Gerät bestimmt wurde.
Vorrichtung nach einem der vorhergehenden Ansprüche, ferner umfassend: eine Empfangseinrichtung (1) zum Empfangen der Abfragenachricht über ein Netzwerk (3), mit dem die Vorrichtung im Betrieb verbunden ist; und eine Ausgabeeinrichtung (1) zur Ausgabe der den Webseitencode umfassenden Antwortnachricht an das Benutzergerät über das Netzwerk, mit dem die Vorrichtung im Betrieb verbunden ist.
Vorrichtung nach einem der vorhergehenden Ansprüche, umfassend eine Einrichtung zur Auswahl der Webseiteninformation aus der ersten Speichereinrichtung entsprechend dem Inhalt der Abfragenachricht und einer Einrichtung zur Eingabe der Webseiteninformation und der Gerätetypidentifikation an die Codeerzeugungseinheit.
Verfahren zum Beantworten einer Abfragenachricht von einem entfernten Benutzergerät (2) aus nach Webseiteninformationen mittels Erzeugen (200) von Webseitencode, der vom Benutzergerät übersetzbar ist, zur Anzeige einer oder mehrerer Webseiten und zur Ausgabe einer den Webseitencode umfassenden Antwortnachricht, wobei das Verfahren umfaßt: Extrahieren (130) aus der Abfragenachricht von Informationen, die eine Gerätetypidentifikation (45) bestimmen, welche das entfernte Benutzergerät als eines aus einer Menge von möglichen Gerätetypen mit verschiedenen technischen Merkmalen identifiziert; Betreiben (141) einer Codeerzeugungseinheit (21), um den Webseitencode zu erzeugen (142); Speichern der Webseiteninformationen in einer ersten Speichereinrichtung (22, 23) als ein Inhaltsdokument, das eine Menge von in einer Skriptsprache geschriebenen Instruktionen (42) zur Erzeugung des Webseitencodes umfaßt; und Speichern von geräteabhängigen Informationen für jeden Gerätetyp aus der Menge der verschiedenen Gerätetypen in einer zweiten Speichereinrichtung (42, 25); wobei die Codeerzeugungseinheit die Instruktionen unter Bezug auf ausgewählte geräteabhängige Informationen übersetzt, die der Gerätetypidentifikation entsprechen, wodurch die Codeerzeugungseinheit den Webseitencode in einer Form er zeugt, in der dieser auf das entfernte Benutzergerät zugeschnitten ist; ferner umfassend die folgenden Schritte: Messen (201) der Menge von Code, der eine Seite repräsentiert, die von der Codeerzeugungseinheit erzeugt wurde; Feststellen (203), ob die technischen Merkmale des Benutzergeräts eine ausreichende Datenkapazität beinhalten, um die gemessene Menge von Code unterzubringen, und, bei einer negativen Feststellung, Aufteilen (205) des Codes in zwei oder mehrere Codeanteile, so daß jeder Anteil einen entsprechenden Anteil der Seite repräsentiert und eine Codemenge innerhalb der Datenkapazität des Benutzergeräts umfaßt.
Verfahren nach Anspruch 47, wobei die Skriptsprache eine erste Auszeichnungssprache umfaßt.
Verfahren nach Anspruch 48, wobei das Inhaltsdokument die anzuzeigende Information definierenden Inhaltscode und vordefinierte Tags (43) zum Steuern der Darstellung der anzuzeigenden Information umfaßt; wobei die Übersetzungseinrichtung jeden Tag unter Bezug auf die ausgewählte geräteabhängige Information (40) übersetzt (165).
Verfahren nach Anspruch 49, wobei die geräteabhängige Information als eine Menge von Tabellen (40) gespeichert ist und wobei die geräteabhängige Information in eine Menge von Objekten aufgenommen ist, die den Tags in einer Laufzeitumgebung (46) der Codeerzeugungseinheit zugänglich sind.
Verfahren nach Anspruch 50, wobei die Laufzeitumgebung eine JAVA Virtual Machine (46) umfaßt und die Objektmenge JAVA BEANS (41) umfaßt.
Verfahren nach einem der Ansprüche 50 oder 51, wobei die Tabellen in einem hierarchischen Baum (61–65) definierender hierarchischen Form sind, in dem Knoten den jeweiligen Gerä tetypen in aufeinanderfolgenden hierarchischen Schichten entsprechen.
Verfahren nach Anspruch 52, wobei jeder Gerätetypknoten von entsprechenden Einträgen in jeder der Tabellen repräsentiert ist, um solche Merkmale des Gerätetyps zu definieren, die sich von Merkmalen eines Elternknotens, von dem der Gerätetypknoten abzweigt, unterscheiden.
Verfahren nach einem der Ansprüche 50 bis 53, wobei die Menge von Tabellen eine technische Merkmale jedes Gerätetyps definierende Gerätebehandlungstabelle umfaßt.
Verfahren nach einem der Ansprüche 50 bis 54, wobei die Menge von Tabellen eine Protokollbehandlungstabelle (31) umfaßt, die das Format des von der Codeerzeugungseinheit erzeugten Webseitencodes definiert.
Verfahren nach einem der Ansprüche 47 bis 55, wobei der Webseitencode in einer zweiten Auszeichnungssprache erzeugt ist.
Verfahren nach Anspruch 56, umfassend das Auswählen der zweiten Auszeichnungssprache in Übereinstimmung mit der ausgewählten geräteabhängigen Information in der Protokollbehandlungstabelle aus einer Anzahl von Auszeichnungssprachen, die zumindest HTML und WML umfassen.
Verfahren nach einem der Ansprüche 50 bis 57, wobei die Menge von Tabellen eine Stilbehandlungstabelle (32) umfaßt, die dem Darstellungsstil der Webseiteninformation definiert.
Verfahren nach Anspruch 58, wobei die Stilbehandlungstabelle Merkmale definiert, die zumindest eines der folgenden enthalten: (a) Fontmerkmale, (b) Farbe und (c) Hintergrund.
Verfahren nach einem der Ansprüche 50 bis 59, wobei die Menge von Tabellen eine Motivbehandlungstabelle (33) umfaßt, die mindestens einer der folgenden Merkmale definiert: (a) dekorative Merkmale und (b) ein Logo.
Verfahren nach einem der Ansprüche 50 bis 60, wobei die Menge von Tabellen eine Layoutbehandlungstabelle (35) umfaßt, die für jeden Gerätetyp das Layout der Webseiteninformation unter Bezug auf eine Darstellungsfläche jedes Gerätetyps definiert.
Verfahren nach Anspruch 61, wobei die Layoutbehandlungstabelle das Layout unter Bezug auf eine Menge von Fenstern (50) definiert, die Teile der Anzeigefläche umfassen und entsprechende Anteile der Webseiteninformation enthalten.
Verfahren nach Anspruch 62, wobei die Layoutbehandlung für jeden Gerätetyp die Anzahl und Konfiguration von Fenstern bestimmt.
Verfahren nach Anspruch 63, wobei, bei einem Gerätetyp mit minimaler Bildschirmfläche, die Layoutbehandlung die Seitenkonfiguration als eine Menge von Decks (51–53), die einzelne Fenster (51–53) umfassen, zur Benutzung bei der Anzeige der Webseiteninformation mittels aufeinanderfolgender Anzeige der Decks festlegt.
Verfahren nach einem der Ansprüche 50 bis 64, wobei der Inhaltscode mindestens einen eine entsprechende Datenkomponente identifizierenden Komponentennamen (171) umfaßt und wobei das Verfahren das Zugreifen auf eine Datenstruktur umfaßt, in der mindestens eine Datenkomponente als eine Menge von Datenobjekten existiert, die mehrere Versionen der Datenkomponente definieren, wobei die Datenobjekte verschiedene für verschiedene entfernte Benutzergeräte geeignete Dateneigenschaften haben.
Verfahren nach Anspruch 65, umfassend einen Auswahlschritt (165) eines Datenobjekts aus der Menge von Datenobjekten, die durch einen Komponentennamen für die Einbindung in dem Webseitencode auf der Basis der Gerätetypidentifikation identifiziert sind.
Verfahren nach Anspruch 66, wobei der Auswahlschritt das Zugreifen auf eine Komponentenbehandlungstabelle (37) für die Suche nach einer vorgegebenen Auswahl eines Datenobjekts umfaßt.
Verfahren nach Anspruch 66, wobei der Auswahlschritt die technischen Merkmale des entfernten Benutzergeräts bestimmt und das Datenobjekt durch Vergleich der technischen Merkmale mit Dateneigenschaften jedes Datenobjekts auswählt.
Verfahren nach Anspruch 68, wobei der Auswahlschritt die technischen Merkmale durch Rückgriff auf eine Gerätebehandlungstabelle (30) bestimmt.
Verfahren nach Anspruch 68 oder 69, wobei die Datenobjekte in einer Datenstruktur, in der Metadaten (172, 174, 176, 178) in Verbindung mit jedem Datenobjekt gespeichert sind, gespeichert werden und wobei die Dateneigenschaften jedes Datenobjekts durch die entsprechenden Metadaten definiert sind.
Verfahren nach einem der Ansprüche 62 bis 64, umfassend das Empfangen von Benutzereingaben über eine graphische Benutzeroberfläche (4) und das Betreiben einer auf die graphische Benutzeroberfläche ansprechenden Dokumentverfassungseinrichtung (240) zum Erschaffen von Dokumenten aus den Webseitenerzeugungsinstruktionen.
Verfahren nach Anspruch 71, umfassend das Empfangen von Daten und das Umwandeln der Daten in eine Menge von Datenobjekten, die jeweils eine für die technischen Merkmale eines entsprechenden Gerätetyps geeignete entsprechende Version der Daten enthalten.
Verfahren nach Anspruch 72, wobei die Menge von Datenobjekten ferner mehrere einer Menge von verfügbaren Benutzervorgaben entsprechende Versionen umfaßt.
Verfahren nach Anspruch 73, umfassend das Bestimmen einer Benutzervorgabe aus der Abfragenachricht, wobei der Auswahlschritt das Datenobjekt entsprechend der Benutzervorgabe auswählt.
Verfahren nach Anspruch 74, wobei die mehreren Versionen Versionen in jeder Sprache aus einer Menge von Sprachen umfassen und wobei die Benutzervorgabe eine Vorzugssprache umfaßt.
Verfahren nach Anspruch 54, wobei der Festlegungsschritt das Bestimmen der technischen Merkmale durch Rückgriff auf die Gerätebehandlungstabelle bestimmt.
Verfahren nach einem der vorhergehenden Ansprüche, umfassend das Speichern der Teile des Codes in einem Pufferspeicher für die darauffolgende Übertragung an das Benutzergerät.
Verfahren nach Anspruch 77, umfassend das Speichern von Kundendaten, die in aufeinanderfolgenden Nachrichten vom Benutzergerät in Antwort auf aufeinanderfolgende Übertragungen der entsprechende Teile der Seite repräsentierenden Teile von Code empfangen wurden, in einem Sitzungsspeicher und das Kombinieren von Kundendaten für eine abgeschlossene Sitzung, in der Kundendaten für alle Teile der Seite empfangen wurden, als eine einzelnes Datenobjekt.
Verfahren nach Anspruch 78, wobei die Seite ein Formular (239) definiert und wobei die Teile der Seite entsprechende Datenfelder des Formulars umfassen.
Verfahren nach einem der Ansprüche 50 bis 64, wobei die Menge von Tabellen eine dynamische Behandlungstabelle umfaßt, die Codeerzeugungsmerkmale definiert, die entsprechend den Werten von zeitveränderlichen Parametern bestimmt sind.
Verfahren nach Anspruch 80, wobei die Codeerzeugungsmerkmale Bildinhalt des Webseitencodes definieren und der zeitveränderliche Parameter die für die Kommunikation mit dem Gerät verfügbare Bandbreite ist.
Verfahren nach einem der Ansprüche 47 bis 81, umfassend das Speichern einer Kopie von in einer Antwortnachricht ausgegebenem Webseitencode in einem Cachespeicher; und das Ausgeben (132, 135) von Webseitencode aus der gespeicherten Kopie in Antwort auf das Empfangen einer weiteren Abfragenachricht für dieselbe Webseiteninformation.
Verfahren nach Anspruch 82, wobei der Cachespeicher in ausgewählter Weise und abhängig davon, ob eine Maßgabe für Cachespeicherung in dem Inhaltsdokument definiert ist, aus dem der Webseitencode erzeugt wird, Webseitencode speichert.
Verfahren nach Anspruch 83, wobei die Maßgabe zur Cachespeicherung durch die Betätigung eines im Inhaltsdokument eingefügten Tags gesetzt ist.
Verfahren nach Anspruch 84, wobei der Tag ferner eine Gültigkeitsdauer der Kopie des im Cachespeicher gespeicherten Webseitencodes definiert.
Verfahren nach einem der Ansprüche 47 bis 85, wobei der Extraktionsschritt (130) Identifikationsinformationen aus ei nem Header der Abfragenachricht extrahiert und die Gerätetypidentifikation durch Rückgriff auf eine Tabelle von Gerätetypidentifikationen bestimmt, für die geräteabhängige Informationen in der zweiten Speichereinrichtung gespeichert sind.
Verfahren nach Anspruch 86, wobei der Extraktionsschritt, für die aus dem Header erhaltene Identifikationsinformation, aus der Tabelle bestimmt, ob eine entsprechende Gerätetypidentifikation verfügbar ist, und, falls nicht, einen Hinweis erzeugt, daß das Benutzergerät unerkannt ist.
Verfahren nach Anspruch 87, umfassend das Betätigen einer Prüfeinrichtung, die auf den Hinweis anspricht, daß das Benutzergerät unerkannt ist, um einen Prüfagenten an das Benutzergerät zum Extrahieren von Geräteinformationen zu senden, sowie das Empfangen einer Antwortnachricht, die die Geräteinformation vom Benutzergerät enthält.
Verfahren nach Anspruch 88, umfassend das Vergleichen der empfangenen Geräteinformationen mit gespeicherten geräteabhängigen Informationen für bekannte Geräte und das Bestimmen einer Gerätetypidentifikation, die einer besten Übereinstimmung zwischen den geräteabhängigen Informationen für bekannte Geräte und den Geräteinformationen für das unbekannte Gerät entspricht.
Verfahren nach Anspruch 89, wobei die Codeerzeugungseinheit Webseitencode unter Benutzung der Gerätetypidentifikation des bekannten Geräts erzeugt, das als eine beste Übereinstimmung mit dem unerkannten Gerät bestimmt wurde.
Verfahren nach einem der Ansprüche 47 bis 90, ferner umfassend: das Empfangen der Abfragenachricht über ein Netzwerk; und das Ausgeben der dem Webseitencode umfassenden Antwortnachricht an das Benutzergerät über das Netzwerk.
Verfahren nach einem der Ansprüche 47 bis 91, umfassend das Auswählen der Webseiteninformation aus der ersten Speichereinrichtung entsprechend dem Inhalt der Abfragenachricht und das Eingeben der Webseiteninformation und der Gerätetypidentifikation an die Codeerzeugungseinheit.
Computerprogramm, umfassend prozessorimplementierbare Instruktionen zum Steuern eines Prozessors zum Ausführen des Verfahrens nach einem der Ansprüche 47 bis 92.
Speichermedium, umfassend prozessorimplementierbare Instruktionen zum Steuern eines Prozessors zum Ausführen des Verfahrens nach einem der Ansprüche 47 bis 92.
Elektrisches Signal, das prozessorimplementierbare Instruktionen zum Steuern eines Prozessors zum Ausführen des Verfahrens nach einem der Ansprüche 47 bis 92 trägt.