-
Das
Folgende bezieht sich im Allgemeinen auf das Anzeigen von Inhalt
auf mobilen Kommunikationsgeräten
und insbesondere auf ein Verfahren zum Finden einer Zeichenkette
in einem Dokumentanhang und zum Anzeigen des entsprechenden Abschnitts
auf einem mobilen Kommunikationsgerät, ohne den vollständigen Dokumenteninhalt
abzurufen.
-
Mobile
Kommunikationsgeräte
werden aufgrund eines in relativ jüngster Zeit erfolgten Anstiegs
der Anzahl von Dienstleistungen und Merkmalen, die von den Geräten und
Infrastrukturen unterstützt
werden, für geschäftliche
und private Anwendung immer beliebter. Mobile Handheld-Kommunikationsgeräte, die
oft auch als Mobilstationen bezeichnet werden, sind im Wesentlichen
tragbare Computer mit Drahtlosfähigkeit
und können
verschiedene Formen haben. Dazu zählen Personal Digital Assistants
(PDAs), Mobiltelefone und Smart-Phones. Während ihre geringe Größe ein Vorteil
in Bezug auf ihre Tragbarkeit darstellt, bringen die Beschränkungen
bei Bandbreite und Rechenleistung dieser Geräte Herausforderungen mit sich,
wenn es um das Herunterladen und Anzeigen von Dokumenten geht, beispielsweise
von Textverarbeitungsdokumenten, Tabellen und Bildern.
-
Eine
Beschreibung von Verfahren zum Formatieren von Webseiten in ganzer
Größe zum Anzeigen
auf einem kleinen Bildschirm eines tragbaren Geräts erfolgt durch N. Milic-Frayling
et al in "SmartView
and SearchMobil: Providing Overview and Detail in Handheld Browsing" in Mobile and Ubiquitous
Information Access. Mobile HCl 2003 International Workshop. Revised
and Invited Papers (Lecture Notes in Computer Science Vol. 2954)
Springer-Verlag Berlin, Deutschland, 8. August 2003 (2003-08-08),
Seiten 158-171, XP002318043 ISBN: 3-540-21003-2 www.springerlink.com/index/H8K7GF5F6EXK19KR.pdf
[abgerufen am 16.02.2005].
-
Die
Erstellung von elektronischen Dokumenten erfolgt unter Verwendung
verschiedenster Computerprogramme wie z. B. Textverarbeitungsprogramme,
Tabellenkalkulationsprogramme, Finanzsoftware und Präsentationssoftware.
Es ist üblich,
dass derartige Programme einen Befehl "Suchen" enthalten, um in einem Dokument usw.
schnell eine Zeichenkette von Interesse finden zu können, ohne
dass der Benutzer dazu das gesamte Dokument durchlesen muss.
-
Das
Herunterladen eines gesamten Dokuments auf ein mobiles Kommunikationsgerät nimmt
eine große
Menge an Bandbreite in Anspruch, insbesondere wenn das Dokument
sehr umfangreich ist. Außerdem
verbraucht das Anzeigen selbst nur eines Abschnitts eines solchen
heruntergeladenen Dokuments auf dem Gerät beträchtliche Geräteressourcen
hinsichtlich CPU, Arbeitsspeicher und Batterie.
-
Wenn
ein Benutzer beispielsweise nur einen Absatz in einem Abschnitt
in der Mitte eines 400-Seiten-Dokuments anzeigen möchte, dann
muss der Abschnitt, welcher einige der Standardeigenschaften für den Absatz
enthält,
oder sogar das gesamte Dokument zum mobilen Kommunikationsgerät übertragen
werden. Und das obwohl der Benutzer nur einen kleinen Ausschnitt
des Dokuments auf dem mobilen Kommunikationsgerät anschaut.
-
Demzufolge
ist es nach dem Stand der Technik bekannt, einen Attachment-Server
bereitzustellen, der die Lieferung von On-Demand-Inhalt an den Benutzer
eines mobilen Kommunikationsgeräts übernimmt,
um die Inanspruchnahme von Bandbreite und Geräte-CPU/Arbeitsspeicher zu minimieren.
Dieser Inhalt kann dann mit einem Attachment-Viewer auf dem Gerät angezeigt
werden.
-
Ein
Beispiel für
ein solches System ist in
WO01/65354 beschrieben,
wo in Abhängigkeit
von den Eigenschaften eines anfordernden Mobilgeräts ein Dokumentobjektmodell
(Document Object Model – DOM)
eines Dokuments mit einer Anzahl von Seiten erstellt wird, wobei
diese Seiten des Dokuments je nach Anforderung durch den Benutzer
zum Mobilgerät
heruntergeladen werden.
-
Gegenwärtig kann
der Befehl "Suchen" im Attachment-Viewer
eines mobilen Kommunikationsgeräts einen
vom Benutzer eingegebenen Suchbegriff nur dann finden, wenn der
Inhalt des Attachments – also
des Anhangs – bereits
auf dem Gerät
vorhanden ist (d. h. wenn er bereits auf das Gerät abgerufen/heruntergeladen wurde).
-
Einige
Dokument-Attachments können
sich leicht im Bereich von mehreren hundert Seiten bewegen oder
große
Mengen an Textinformationen enthalten, wie oben schon angedeutet.
Damit ein Benutzer in der Lage ist, jedes Vorkommen eines Suchbegriffs
für ein
derartig großes
Dokument-Attachment zu finden, muss der gesamte Inhalt in einer
sequentiellen Weise vom Server auf das Gerät abgerufen werden. Das ist
ein sehr zeitaufwändiger
Prozess, der zudem auch viel Bandbreite und Geräte-CPU/Arbeitsspeicher in Anspruch nimmt.
-
ALLGEMEINES
-
Das
Problem der Notwendigkeit des Abrufens des gesamten Inhalts eines
Dokument-Attachments zu einem mobilen Kommunikationsgerät, um jedes
Vorkommen einer Zeichenkette innerhalb des Dokuments zu finden,
kann durch die vorliegende Beschreibung gelöst werden. Eine Server-Suchfunktion
wird bereitgestellt, um eine Suche auf dem Attachment-Server zu
initiieren und um nur den entsprechenden Abschnitt bzw. die entsprechenden
Abschnitte zum Gerät
zurückzugeben,
in dem bzw. in denen der Suchbegriff enthalten ist. Der Benutzer
kann dabei optisch auf möglicherweise übersprungener
Inhalt (d. h. nicht abgerufener Inhalt) des Dokuments hingewiesen
werden, damit dieser später
abgerufen werden kann. Der nicht-sequentielle Zugriff gemäß der vorliegenden
Server-Suchfunktion ermöglicht
eine minimierte Beanspruchung von Bandbreite und ein besseres Erlebnis
beim On-Demand-Anzeigen von Attachments.
-
Die
hier erläuterte
Server-Suchfunktion ist eine geräte-
und serverseitige Funktion, die es einem Benutzer ermöglicht,
einen Suchbegriff für
ein Dokument-Attachment
in sein mobiles Kommunikationsgerät einzugeben. Wenn kein (oder
kein weiteres) Vorkommen des Begriffs auf dem Gerät gefunden
wird, dann fordert das Gerät
den Benutzer auf, eine serverseitige Suche zu initiieren. Wenn der
Benutzer dem zustimmt, dann durchsucht der Server das Dokument-Attachment
und gibt den ersten Abschnitt des Texts an das Gerät zurück, der
den Suchbegriff enthält,
so dass dieser durch den Benutzer betrachtet werden kann. Diese
Vorgehensweise kann dann wiederholt werden, bis die Server-Suchfunktion
meldet, dass keine weiteren "Treffer" auf dem Server gefunden
wurden.
-
Insbesondere
wird gemäß einem
Aspekt ein Server bereitgestellt, der in der Lage ist, eine Zeichenkette
in einem Dokument zu finden, das auf dem Server gespeichert ist,
umfassend: Mittel zum Aufbauen und Zwischenspeichern einer Grafikstruktur
innerhalb des Servers, welche eine Abbildung des Dokuments repräsentiert,
wobei die Grafikstruktur das Dokument in individuelle Segmente paginiert;
Mittel zum Übertragen
aufeinander folgender Segmente des Dokuments zusammen mit einer
Gesamtanzahl der individuellen Segmente; Mittel zum Durch suchen
der restlichen Segmente innerhalb des Servers nach einer Zeichenkette;
und Mittel zum Übertragen
von jedem der restlichen Segmente, welche die Zeichenkette enthalten,
falls die Zeichenkette in den restlichen Segmenten gefunden wird;
wobei das Mittel zum Durchsuchen des Weiteren umfasst:
Mittel
zum Empfangen der Zeichenkette und eines Indexbereichs der restlichen
Segmente;
Mittel zum Durchsuchen der restlichen Segmente innerhalb
des Indexbereichs nach der Zeichenkette; und
Mittel zum Übertragen
eines ersten Segments, welches die Zeichenkette enthält, und
eines assoziierten Segment-Index, falls die Zeichenkette gefunden
wird.
-
Das
Mittel zum Durchsuchen kann des Weiteren umfassen:
Mittel zum
Extrahieren der Zeichenkette und des zu durchsuchenden Indexbereichs;
Mittel
zum Iterieren der Grafikstruktur und für jeden Knoten in dem Bereich
der restlichen Segmente zum Parsen aller Absatz- und Textbefehle,
und für
jeden Absatzbefehl zum Abrufen und Speichern allen Textinhalts aus
den Textbefehlen in einer Absatzinhaltsvariablen und zum Durchsuchen
des Textinhalts in der Absatzinhaltsvariablen nach der Zeichenkette;
und
Mittel zum Beibehalten der Grafikstruktur für jedes
der restlichen Segmente, welche die Zeichenkette enthalten, beim
Finden der Zeichenkette, und zum Übertragen von jedem der restlichen
Segmente und der assoziierten Segment-Indexe.
-
Der
Server kann des Weiteren umfassen: Mittel zum Extrahieren von Suchoptionen
zusammen mit der Zeichenkette und dem Indexbereich und zum Neuordnen
des Indexbereichs basierend auf den Suchoptionen. Der Server kann
in der Lage sein, die Zeichenkette auf einem Mobilgerät anzuzeigen.
Die individuellen Segmente können
auf dem Mobilgerät
angezeigt werden. Das Übertragen
der aufeinander folgenden Segmente kann vom Benutzer initiiert werden.
Die aufeinander folgenden Segmente können von dem Server zu dem
Mobilgerät übertragen
werden, um durch das Mobilgerät
angezeigt zu werden.
-
Gemäß einem
anderen Aspekt wird ein Prozess zum Finden einer Zeichenkette in
einem auf dem Server gespeicherten Dokument und zum Anzeigen der
Zeichenkette auf einem Mobilgerät
bereitgestellt, umfassend: das Aufbauen und das Zwischenspeichern
einer Grafikstruktur innerhalb des Servers, welche eine Abbildung
des Dokuments repräsentiert,
wobei die Grafikstruktur das Dokument in individuelle Segmente zur
Anzeige auf dem Mobilgerät
paginiert; das vom Benutzer initiierte Übertragen aufeinander folgender
Segmente des Dokuments von dem Server zu dem Mobilgerät zur Anzeige
durch das Mobilgerät
zusammen mit einer Gesamtanzahl der individuellen Segmente; das
vom Benutzer initiierte Durchsuchen von mindestens einem der aufeinander
folgenden Segmente innerhalb des Mobilgeräts; und falls die Zeichenkette
nicht gefunden wird und die Gesamtanzahl der individuellen Segmente
noch nicht durchsucht wurde, das anschließende Initiieren eines weiteren
Durchsuchens der restlichen Segmente innerhalb des Servers; falls
die Zeichenkette innerhalb der restlichen Segmente gefunden wird,
das Übertragen
eines ersten Segments, welches die Zeichenkette enthält; und
falls die Zeichenkette entweder in dem mindestens einen der aufeinander
folgenden Segmente oder in den restlichen Segmenten gefunden wird,
das Hervorheben der Zeichenkette innerhalb eines Segments auf dem
Mobilgerät
und ansonsten das Bereitstellen einer Anzeige auf dem Mobilgerät, dass
keine Übereinstimmungen
gefunden wurden. Das Initiieren des weiteren Durchsuchens kann umfassen:
das
Senden der Zeichenkette und eines Indexbereichs der restlichen Segmente
im Anschluss an das letzte der aufeinander folgenden Segmente von
dem Mobilgerät
zu dem Server;
das Durchsuchen der restlichen Segmente innerhalb
des Indexbereichs nach der Zeichenkette; und
falls die Zeichenkette
gefunden wird, das anschließende Übertragen
des ersten Segments, welches die Zeichenkette enthält, und
eines assoziierten Segment-Index von dem Server zu dem Gerät.
-
Das
Hervorheben kann das Aktualisieren einer Anzeige des Geräts umfassen,
um die Position in dem Dokument widerzuspiegeln, wo sich die Zeichenkette
befindet. Der Prozess kann des Weiteren umfassen: das Erzeugen einer
Anzeige auf dem mobilen Kommunikationsgerät zum Auffordern des Benutzers,
das weitere Durchsuchen der restlichen Segmente innerhalb des Servers
zu initiieren. Der Prozess kann des Weiteren umfassen: das Erzeugen
einer Anzeigeleiste für übersprungenen
Inhalt auf der Anzeige zwischen den aufeinander folgenden Segmenten,
wodurch dem Benutzer angezeigt wird, welche der restlichen Segmente
innerhalb des Servers noch nicht zum Gerät übertragen wurden. Das Durchsuchen
der restlichen Segmente innerhalb des Servers kann umfassen: das
Extrahieren der Zeichenkette und des zu durchsuchenden Indexbereichs
(73, 75);
das Iterieren der Grafikstruktur
(81) und für
jeden Knoten in dem Bereich der restlichen Segmente das Parsen aller
Absatz- und Textbefehle (85, 87, 89),
und für
jeden Absatzbefehl das Abrufen und Speichern allen Textinhalts aus
den Textbefehlen in einer Absatzinhaltsvariablen (93) und
das Durchsuchen des Textinhalts in der Absatzinhaltsvariablen nach
der Zeichenkette (95); und
beim Finden der Zeichenkette
das Beibehalten (97) der Grafikstruktur für jedes
der restlichen Segmente, welche die Zeichenkette enthalten, und
das Übertragen
von jedem der restlichen Segmente und der assoziierten Segment-Indexe
zu dem Mobilgerät.
-
In
einer anderen Ausführungsform
kann ein in einem Server implementierbarer Prozess zum Suchen einer
Zeichenkette in einem auf dem Server gespeicherten Dokument bereitgestellt
werden, umfassend:
das Aufbauen (34) und das Zwischenspeichern
(35) einer Grafikstruktur innerhalb des Servers (28),
welche eine Abbildung eines Dokuments (30) repräsentiert,
wobei die Grafikstruktur das Dokument in individuelle Segmente paginiert;
das Übertragen
aufeinander folgender Segmente des Dokuments zusammen mit einer
Gesamtanzahl der individuellen Segmente;
das Durchsuchen der
restlichen Segmente innerhalb des Servers nach einer Zeichenkette
(61); und
falls die Zeichenkette in den restlichen
Segmenten gefunden wird, das anschließende Übertragen von jedem der restlichen
Segmente, welche die Zeichenkette enthalten (65);
wobei
das Durchsuchen des Weiteren umfasst:
das Empfangen der Zeichenkette
und eines Indexbereichs der restlichen Segmente;
das Durchsuchen
der restlichen Segmente innerhalb des Indexbereichs nach der Zeichenkette;
und
falls die Zeichenkette gefunden wird, das anschließende Übertragen
eines ersten Segments, welches die Zeichenkette enthält, und
eines assoziierten Segment-Index.
-
Das
Durchsuchen kann des Weiteren umfassen:
das Extrahieren der
Zeichenkette und des zu durchsuchenden Indexbereichs (73, 75);
das
Iterieren der Grafikstruktur (81) und für jeden Knoten in dem Bereich
der restlichen Segmente das Parsen aller Absatz- und Textbefehle
(85, 87, 89), und für jeden Absatzbefehl das Abrufen
und Speichern allen Textinhalts aus den Textbefehlen in einer Absatzinhaltsvariablen
(93) und das Durchsuchen des Textinhalts in der Absatzinhaltsvariablen
nach der Zeichenkette (95); und
beim Finden der Zeichenkette
das Beibehalten (97) der Grafikstruktur für jedes
der restlichen Segmente, welche die Zeichenkette enthalten, und
das Übertragen
von jedem der restlichen Segmente und der assoziierten Segment-Indexe.
-
Die
Prozesse können
des Weiteren umfassen: das Extrahieren von Suchoptionen zusammen
mit der Zeichenkette und dem Indexbereich und das Neuordnen des
Indexbereichs basierend auf den Suchoptionen. Die Grafikstruktur
kann ein Dokumentobjektmodell (Document Object Model – DOM) sein.
-
Gemäß einem
anderen Aspekt wird ein auf einem Mobilgerät implementierbarer Prozess
zum Suchen einer Zeichenkette in einem auf einem Server gespeicherten
Dokument bereitgestellt, umfassend: das Empfangen und Anzeigen von
aufeinander folgenden Segmenten eines Dokuments; das Durchsuchen
von mindestens einem der aufeinander folgenden Segmente nach einer
vom Benutzer eingegebenen Zeichenkette, und falls die Zeichenkette
gefunden wird, das anschließende
Hervorheben der Zeichenkette; falls die Zeichenkette nicht gefunden
wird, das Auffordern des Benutzers, das weitere Durchsuchen der
restlichen entfernt gespeicherten Segmente innerhalb des Servers
zu initiieren; und ansonsten das Bereitstellen einer Anzeige auf dem
Mobilgerät,
dass keine Übereinstimmungen
gefunden wurden.
-
Gemäß einem
anderen Aspekt wird ein Server bereitgestellt, der in der Lage ist,
eine Zeichenkette in einem Dokument zu finden, das auf dem Server
gespeichert ist, umfassend: Mittel zum Aufbauen und Zwischenspeichern
einer Grafikstruktur innerhalb des Servers, welche eine Abbildung
eines Dokuments repräsentiert,
wobei die Grafikstruktur das Dokument in individuelle Segmente paginiert;
Mittel zum Übertragen
aufeinander folgender Segmente des Dokuments zusammen mit einer
Gesamtanzahl der individuellen Segmente; Mittel zum Durchsuchen
der restlichen Segmente innerhalb des Servers nach einer Zeichenkette;
und Mittel zum Übertragen
von jedem der restlichen Segmente, welche die Zeichenkette enthalten,
falls die Zeichenkette in den restlichen Segmenten gefunden wird;
wobei das Mittel zum Durchsuchen des Weiteren umfasst:
Mittel
zum Empfangen der Zeichenkette und eines Indexbereichs der restlichen
Segmente;
Mittel zum Durchsuchen der restlichen Segmente innerhalb
des Indexbereichs nach der Zeichenkette; und
Mittel zum Übertragen
eines ersten Segments, welches die Zeichenkette enthält, und
eines assoziierten Segment-Index, falls die Zeichenkette gefunden
wird.
-
Gemäß einem
anderen Aspekt wird ein Mobilgerät
bereitgestellt, das in der Lage ist, eine Zeichenkette in einem
Dokument zu finden, das auf einem Server gespeichert ist, umfassend:
Mittel zum Abrufen und Anzeigen von aufeinander folgenden Segmenten
eines Dokuments; Mittel zum Durchsuchen von mindestens einem der
aufeinander folgenden Segmente nach einer vom Benutzer eingegebenen
Zeichenkette, und zum anschließenden
Hervorheben der Zeichenkette, falls die Zeichenkette gefunden wird;
Mittel zum Auffordern des Benutzers, das weitere Durchsuchen der
restlichen entfernt gespeicherten Segmente innerhalb des Servers zu
initiieren, falls die Zeichenkette nicht gefunden wird; und Mittel
zum Bereitstellen einer Anzeige auf dem Mobilgerät, dass keine Übereinstimmungen
gefunden wurden, falls keine Übereinstimmungen
gefunden wurden. Das Mobilgerät
kann des Weiteren Mittel zum Aktualisieren einer Anzeige des Geräts umfassen,
um die Position in dem Dokument widerzuspiegeln, wo sich die Zeichenkette
befindet. Das Mobilgerät
kann des Weiteren Mittel zum Erzzeugen einer Anzeigeleiste für übersprungenen
Inhalt auf der Anzeige zwischen den aufeinander folgenden Segmenten,
wodurch dem Benutzer angezeigt wird, welche der restlichen Segmente
innerhalb des Servers noch nicht zum Gerät übertragen wurden.
-
Gemäß einem
anderen Aspekt wird ein computerlesbares Medium bereitgestellt,
das auf einem Prozessor eines Servers gemäß Anspruch 22 ausführbar ist.
Gemäß einem
anderen Aspekt wird ein computerlesbares Medium bereitgestellt,
das auf einem Prozessor eines Mobilgeräts gemäß Anspruch 23 ausführbar ist.
-
Weitere
Aspekte und Vorteile werden dem durchschnittlichen Fachmann auf
dem Gebiet der Technik aus den nachfolgend detaillierter beschriebenen
und beanspruchten Details der Konstruktion und des Betriebs deutlich,
wobei Bezug auf die beiliegenden Zeichnungen genommen wurde.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Es
erfolgt nun eine detaillierte Beschreibung der bevorzugten Ausführungsform
unter Bezugnahme auf die beigefügten
Zeichnungen, welche folgende Bedeutung haben:
-
1 ist
ein Blockdiagramm einer Netzwerkumgebung, in der die bevorzugte
Ausführungsform
praktisch umgesetzt werden kann;
-
2 ist
ein Baumdiagramm zur Darstellung der grundlegenden Struktur eines
in der bevorzugten Ausführungsform
verwendeten Dokumentobjektmodells (Document Object Model – DOM);
-
3 zeigt
die oberste Ebene der DOM-Struktur aus 2;
-
4 zeigt
eine exemplarische DOM-Struktur für ein Textverarbeitungsdokument;
-
5 zeigt
eine exemplarische DOM-Struktur für ein Tabellendokument;
-
6 zeigt
eine exemplarische DOM-Struktur für ein Textverarbeitungsdokument,
welches als Subdokument ein Bild enthält;
-
7 ist
ein Flussdiagramm zur Darstellung des DOM-Struktur-Aufbaus und der
Paginierung eines Dokuments;
-
8A und 8B zeigen
eine grafische Benutzeroberfläche
auf dem mobilen Kommunikationsgerät zum Aufrufen des Server-Suchbefehls;
-
9 zeigt
eine Nachricht auf der grafischen Benutzeroberfläche, die angibt, dass eine
Zeichenkette nicht gefunden wurde;
-
10 ist
ein Flussdiagramm zur Darstellung der Schritte zur Durchführung einer
geräteseitigen
Anforderung zur Initiierung des Server-Suchbefehls gemäß einer
bevorzugten Ausführungsform;
und
-
11 ist
ein Flussdiagramm zur Darstellung der Schritte zur Ausführung des
Suchbefehls innerhalb des Servers gemäß der bevorzugten Ausführungsform.
-
DETAILLIERTE
BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM
-
Unter
Bezug auf 1 ist die Netzwerkumgebung 10 dargestellt,
in der die bevorzugte Ausführungsform
praktisch umgesetzt werden kann. Die Netzwerkumgebung 10 enthält die Mobilgeräte 12,
die über
ein Drahtlosnetzwerk 14 mit einem Server 28 kommunizieren,
um Dokument-Attachments auf die Mobilgeräte 12 herunterzuladen.
Obwohl zu Darstellungszwecken nur ein einziger Server 28 gezeigt
wird, dürfte
es dem Fachmann auf dem Gebiet der Technik verständlich sein, dass die Netzwerkumgebung 10 mehrere
solcher Server zum Hosten von Websites oder von Grafik-Download-Sites
enthalten kann, die den Zugriff auf Bilddateien ermöglichen,
beispielsweise in den Formaten JPEG, TIFF, BMP, PNG, SGI, MP4, MOV,
GIF, SVG usw. Wie es dem durchschnittlichen Fachmann auf dem Gebiet
der Technik einleuchten dürfte,
zählen
zu den Drahtlosnetzwerken 14 Netzwerke der Typen GSM/GPRS,
CDPD, TDMA, iDEN Mobitex, DataTAC oder zukünftige Netzwerke wie EDGE oder
UMTS sowie Breitbandnetzwerke wie Bluetooth und Varianten von 802.11.
-
Eine
Verbindung zu einem festen Dienst erfordert spezielle Beachtung
und kann eine spezielle Genehmigung erfordern, deren Autorisierung
durch einen NAP (Network Access Point) 16 erfolgt. Für generische Dienste,
wie z. B. Web-Zugriff,
kann ein Proxy-Gateway oder NAT (Network Address Translator) 18 bereitgestellt
werden, so dass ein Netzwerkbetreiber den Zugriff steuern und abrechnen
kann. Die NATs 18 ermöglichen
die Verwaltung einer eingeschränkten
Bereitstellung von öffentlichen
Internet-Adressen für
große
Populationen von drahtlosen Mobilgeraten. Zu den durch ein Proxy-Gateway
oder NAT 18 angebotenen Lösungen gehört oft eine komplexe Infrastruktur,
und sie können
somit durch VASPs (Value-Added
Service Providers) verwaltet werden, die beispielsweise WAP-Gateways,
WAP-Proxy-Gateway-Lösungen,
MMSs (Multi-Media Messaging Servers) und IMSs (Internet Multi-Media
Services) bereitstellen.
-
Private
Intranet-Dienste 26 können
ein zugehöriges
Private Intranet Proxy Gateway 24 zum Zugriff auf Inhalt
auf dem Server 28 benötigen.
Zu solchen privaten Diensten zählen
der WML-Zugriff auf unternehmenseigene Mail-Systeme, der HTML-Zugriff auf CRM-Datenbanken
oder alle anderen Dienste, die Informationen in Form von formatierten
Daten mit eingebetteten Links und URLs liefern. Wie gezeigt wird, ist
es möglich,
dass ein privater Dienst 26 direkt mit dem Drahtlosnetzwerk 14 verbunden
ist, also im Gegensatz zu einer Verbindung über das Internet 20.
-
Im
gesamten vorliegenden Dokument wird zum Zweck der Beschreibung der
bevorzugten Ausführungsform
Bezug auf die Struktur eines Dokumentobjektmodells (Document Object
Model – DOM)
für ein
Dokument-Attachment genommen, das auf einem Mobilgerät 12 angezeigt
werden soll.
-
Der
Attachment-Server 28 verwendet in der bevorzugten Ausführungsform
einen Datei-Parsing-Distiller für
einen speziellen Dateityp, um eine speicherinterne DOM-Struktur
aufzubauen, die ein Attachment dieses Dokumenttyps repräsentiert.
Die Dokument-DOM-Struktur wird in einem Speicher-Cache des Servers 28 gespeichert
und kann bidirektional iteriert werden.
-
Wie
in 2 gezeigt wird, besteht die grafikbasierte Dokument-DOM-Struktur aus Knoten
und Blättern.
Die Knoten dienen als die übergeordneten
Elemente (Parents) von Blättern
und Knoten, während
die Blätter
in der Grafik die Endpunkte eines Zweigs bilden. Jeder Knoten und
jedes Blatt kann über
ein Set von Attributen verfügen,
die seine eigenen Eigenschaften spezifizieren. Beispielsweise kann
ein Absatzknoten Attribute zur Spezifizierung seiner Ausrichtung,
seines Stils, zum Eintrag in das Dokument-Inhaltsverzeichnis usw. enthalten.
Außerdem
verfügt
jeder der Knoten und jedes der Blätter über eine eindeutige Kennung,
die als DOM-ID bezeichnet
wird, um sich selbst in der DOM-Struktur zu identifizieren.
-
Die
Dokument-DOM-Struktur ist in drei Teile unterteilt: oberste Ebene,
Komponente und Referenzen. Die oberste Ebene bezieht sich auf die
Dokumentstammstruktur, während
das Hauptdokument in der Komponente gebildet ist und die Referenzen
Dokumentreferenzen zu entweder internen oder externen Subdokumentteilen
repräsentieren.
Die folgenden Absätze
untersuchen jedes Teil im Detail.
-
Der
Stammknoten einer Dokument-DOM-Struktur, der als "Dokument" bezeichnet wird,
enthält
mehrere untergeordnete Knoten, die als "Inhalte" bezeichnet werden, welche unterschiedliche
Aspekte der Dokumentinhalte repräsentieren.
Jeder "Inhalte"-Knoten enthält einen
oder mehrere "Container"-Knoten, die zum Speichern
verschiedener globaler Dokumentattribute verwendet werden. Die untergeordneten
Elemente (Children) der "Container"-Knoten sind Komponenten,
die zum Speichern der strukturellen und navigationsbezogenen Informationen
des Dokuments dienen.
-
Wenn
der Attachment-Server 28 erstmalig die DOM-Struktur für eine Attachment-Datei aufbaut, entspricht
die Struktur der obersten Ebene einer einzelnen Parent-Child-Kette, wie
sie in 3 gezeigt ist.
-
Durch
den Attachment-Server 28 werden drei Typen von Komponenten
definiert: Textkomponenten, Tabellenkomponenten und Bildkomponenten,
die jeweils Text, Tabellen bzw. Bilder in einem Dokument repräsentieren.
Die Text- und Tabellenkomponenten werden unten im Detail beschrieben,
und die Struktur der Bildkomponente ist identisch.
-
Eine
Komponente besteht aus einer Hierarchie von Befehlsknoten. Jeder
Befehl repräsentiert
eine physische Entität,
eine Eigenschaft oder eine Referenz, die in einem Dokument definiert
ist. Für
die Textkomponente sind die physischen Entitätsbefehle Seiten-, Abschnitts-,
Absatz-, Textsegment-, Kommentar-, Fußnoten- und Endnotenbefehle, die entsprechend
ihrem Namen die entsprechende in einem Dokument enthaltene Entität definieren.
Die Eigenschaftsbefehle für
die Textkomponente sind Schriftart-, Textfarbe-, Texthintergrundfarbe-,
Hyperlink-Start/Ende- und
Bookmark-Befehle. Die Textkomponente hat nur einen einzigen Referenzbefehl,
der als der Textreferenzbefehl bezeichnet wird und der verwendet
wird, um ein Subdokument zu referenzieren, das im Hauptteil eines
Dokuments definiert ist. Üblicherweise
sind die untergeordneten Elemente einer Textkomponente Seiten- oder
Abschnittsbefehlsknoten, die ihrerseits ein Set aus Absatzbefehlsknoten enthalten.
Der Absatzbefehl kann einen oder mehrere Knoten für die restlichen
Befehlstypen enthalten.
-
Unter
Verwendung des folgenden Mustertextdokuments wird die entsprechende
Dokument-DOM-Struktur in
4 gezeigt:
-
Wie 4 zeigt,
besteht der Abschnittsbefehl, der das untergeordnete Element der
Textkomponente ist, aus zwei Absatzbefehlen. Der erste Absatzbefehl
enthält
einen Textsegmentbefehl, und der Textinhalt für diesen Absatz ist als ein
Attribut dem Textsegmentbefehl hinzugefügt. Der zweite Absatzbefehl
hat eine vergleichsweise komplexere Struktur, da die Texteigenschaften
in dem Absatz viel umfangreicher sind. Jedes Mal wenn eine Texteigenschaft
(Schriftart, Textfarbe usw.) sich ändert, wird ein entsprechender
Texteigenschaftsbefehl erstellt, und der Änderungswert wird diesem Befehl
als ein Attribut hinzugefügt.
Der nachfolgende Textsegmentbefehl zeichnet den Text mit derselben
Texteigenschaft als ein Attribut auf. Wenn die Dokumentstruktur
umfangreicher und komplexer wird, werden mehr Befehle der entsprechenden
Typen erstellt, und die Dokumenteigenschaften werden diesen Befehlen
als Attribute hinzugefügt.
-
Die
Tabellenkomponente hat dieselben drei Typen von Befehlen wie die
Textkomponente, jedoch andere Befehlsnamen. Die Dokument-DOM-Struktur
für das
folgende Mustertabellendokument ist in
5 gezeigt:
-
Wie
in 5 gezeigt wird, verfügt die Tabellenkomponente über die
physischen Entitätstypbefehle
Tabelle, Tabellenzeile und Tabellenzelle, wobei der Tabellenzellenbefehl
alle verfügbaren
Befehle für
die Textkomponente enthalten kann. Im obigen Beispiel ist für den ersten
untergeordneten Tabellenzeilenbefehl des Tabellenbefehls ein Attribut "Index" durch den Wert 0
definiert. Damit wird angegeben, dass die entsprechende Tabellenzeile
die erste in der Tabelle definierte Zeile ist. Das Attribut des
ganz linken Tabellenzellenbefehls in 5 hat dieselbe
Bedeutung.
-
Ein
Dokument enthält
manchmal Subdokumente, beispielsweise Bilder, Tabellen, Textfelder
usw. Die hier dargelegte DOM-Struktur verwendet einen Referenzbefehl,
um auf die Grafik von solchen Subdokumenten zu verweisen. Für das folgende
Musterdokument erzeugt der Attachment-Server
28 die in
6 gezeigte DOM-Struktur:
-
Die
in 6 gezeigte Struktur ist identisch mit der oben
in Verbindung mit 4 und 5 erläuterten Struktur,
mit Ausnahme der Attribute der beiden Referenzbefehle. Der Attachment-Server 28 baut
das Bild in "Muster
Drei" als eine separate
Bildkomponente auf, die sämtliche
Bilddaten in ihrer eigenen DOM-Hierarchie enthält. In der
DOM-Struktur für
das Hauptdokument, verweisen die Werte der "Ref"-Attribute
dieser beiden Referenzbefehle auf den Bildinhalt, was durch die gestrichelten
Linien angezeigt wird, so dass die DOM-Struktur alle Teile des Dokuments
miteinander verbindet.
-
Nachdem
nun die Dokument-DOM-Struktur beschrieben wurde, die zur hier erläuterten
Ausführungsform
verwendet wird, folgt jetzt eine detaillierte Erläuterung
des Aufbauens der Dokument-DOM-Struktur und der Paginierung, die
ebenfalls bei der Implementierung der Ausführungsform zur Anwendung kommen.
-
Die
Paginierungsfunktion ist eine client- und serverseitige Operation. 7 zeigt
die Verarbeitungsschritte, aus denen hervorgeht, dass der Server 28 eine
Abbildung (Map) im Arbeitsspeicher zur Zwischenspeicherung (Caching)
der Dokument-DOM-Struktur verwendet, und der Schlüssel zu
der Abbildung ist die Dokument-ID. Anfänglich, wenn der Benutzer eines
mobilen Kommunikationsgeräts 12 eine
Anforderung an den Server 28 zum Anzeigen eines Dokuments
sendet, sendet das Gerät 12 zwei
Attribute und die Anzahl der Bytes (RequireSize), die es als Antwort
vom Server anfordert (z. B. 3 KByte). Die beiden Attribute geben
an, ob es sich bei dem Gerät
um ein Farb- oder Monochromgerät
handelt und welche Bildschirmgröße (Breite × Höhe × Farbtiefe)
in Pixel das Gerät
hat. Auch andere Informationen über
das Gerät 12 können zum
Server 28 übertragen
werden (z. B. Größe des Arbeitsspeichers).
Nachdem der Server 28 eine Anforderung zum Betrachten eines
Dokuments empfangen hat, startet er den Paginierungsprozess (Schritt 30)
und initialisiert die Variablen Pagelndex und PageSize.
-
Die
folgenden Begriffe und Variablen werden in 7 verwendet:
-
Die
Pagelndex-Variable wird im Server 28 definiert und von
diesem verwendet, um den aktuellen Seitenindex aufzuzeichnen, der
durch den Server paginiert wird. Dieser Seitenindex ist anfänglich auf
0 gesetzt, um "Seite
1" anzugeben.
-
PageSize
ist eine Variable, die im Server 28 definiert wird und
von dem Server verwendet wird, um die aktuelle Größe für die Seite
aufzuzeichnen, die gerade paginiert wird, und sie wird auf 0 zurückgesetzt,
wenn eine neue Seite paginiert wird.
-
Hyperlink
map ist eine Variable, die im Server 28 definiert wird
und bei der es sich um einen Container handelt, der aus dem Elementtyp
des Hyperlink-Knotens in der Dokument-DOM-Struktur besteht. Der
Schlüssel
(ID) für
jedes Element in dem Container ist die Hyperlink-Zielzeichenfolge.
-
Bookmark
map ist eine Variable, die im Server 28 definiert wird
und bei der es sich um einen Container handelt, der aus dem Elementtyp
des aktuellen Seitenindex (Pagelndex-Wert) für den Bookmark in der Dokument-DOM-Struktur
besteht. Der Schlüssel
(ID) für
jedes Element in dem Container ist die Bookmark-Zeichenfolge.
-
Der
Serverprozess baut basierend auf den Dokumentinhalten eine Dokument-ID
auf (Schritt 32) und verwendet die ID zur Überprüfung des
Dokument-DOM-Cache
(Schritt 33), um zu ermitteln, ob die Dokument-DOM-Struktur
für dieses
Dokument bereits aufgebaut wurde. Wenn die Dokument-DOM-Struktur
im Cache nicht existiert, baut der Server die DOM-Struktur für das Dokument
auf (Schritt 34) und fügt
diese dem Cache hinzu (Schritt 35).
-
Zum
Aufbauen der Dokument-ID wird die originale Dokumentdatei im Lese-
und Binärmodus
geöffnet. Der
Server
28 erstellt eine MD5-Kontextstruktur, hasht die
MD5-Kontextstruktur Byte für
Byte mit binären
Rohdaten aus der Datei und finalisiert die MD5-Kontextstruktur und
ruft den 16-Byte-Schlüssel
für die
Datei ab. Die MD5-Kontextstruktur weist die folgende Struktur in
der Syntax der Sprache C+++ auf:
-
Die
Zwischenspeicherung (Caching) der Dokument-DOM-Struktur nimmt beträchtlichen
Arbeitsspeicher in Anspruch und erhöht deshalb die Hardware-Gesamtbereitstellungskosten.
Andererseits ist der Aufbau der DOM-Struktur für ein Dokument sogar noch zeit-
und CPU-intensiver als die Operation zum Dokumentschlüsselaufbau,
besonders bei großen
Dokumenten. Da diese Prozessorzeit beim Drahtlosbetrieb eine kritischere
Größe ist als
die Hardware-Bereitstellungskosten, ist das Caching der Dokument-DOM-Struktur
die für die
bevorzugte Ausführungsform
verwendete Vorgehensweise, anstatt jedes Mal die DOM-Struktur für das Dokument
aufzubauen, wenn der Server eine Betrachtungsanforderung erhält, und
dann die Struktur zu verwerfen, nachdem die Antwort zurück zum Client-Gerät 12 gesendet
wurde.
-
Sobald
die Dokument-DOM-Struktur aufgebaut und im Cache zwischengespeichert
wurde, ermittelt der Server 28, ob im Stamm bereits eine
Seitenmarke gesetzt wurde (Schritt 36). Wenn das nicht
der Fall ist, durchläuft
der Server die DOM-Struktur (Schritte 38, 39, 40 und 41)
und berechnet die Ausgabegröße (PageSize)
für jeden
Knoten in der DOM-Struktur basierend auf der Anzahl der Bytes (RequireSize),
die durch das Gerät 12 bereitgestellt
wurde. Der Server inkrementiert den Pagelndex (Schritt 42),
fügt diesen
als ein Attribut zu jedem Knoten hinzu, um den Start von jeder Seite
zu markieren, und fügt
jeden Knoten als ein Attribut zum Stammknoten mit der Zeichenfolgenrepräsentation
Pagelndex als den Attributnamen hinzu (Schritt 43). Im
Anschluss an diese Paginierungsfunktion, überträgt der Attachment-Server 28 das
Dokument Seite für
Seite zum anfordernden Mobilgerät 12,
und zwar auf der Basis der clientseitig erzeugten Anforderungen
(Schritt 44).
-
Der
Seitenmarken-Attributname ist mit den Geräteinformationen und der erforderlichen
Antwortgröße (RequireSize)
verbunden, die durch das Gerät 12 bereitgestellt
werden, um es dem Server zu ermöglichen,
die Dokument-DOM-Struktur
durchgängig
zu paginieren und die Antwort basierend auf der Gerätefähigkeit
zu erzeugen. Wenn es sich bei dem Gerät beispielsweise um ein Monochromgerät handelt,
werden die in der DOM-Struktur enthaltenen Farbinformationen während der
Server-Operationen zur Paginierung und zur Antworterzeugung ignoriert,
wodurch die Ausnutzung der Drahtlosbandbreite optimiert wird.
-
Da
der Schlüssel
zur Speicherabbildung die Dokument-ID ist, muss der zur Berechnung
der Dokument-ID (Schritt 32) verwendete Algorithmus die
Einzigartigkeit des Schlüssels
gewährleisten.
Gemäß dem oben
erläuterten
besten Modus entspricht der im Server 28 verwendete Algorithmus
dem MD5 Messaging Encryption Algorithm, der von Professor Ronald
L. Rivest von MIT Laborstory for Computer Science and RSA Data Security,
Inc. erfunden wurde. Es gibt noch verschiedene andere Hashing-Optionen,
die verwendet werden können.
Allerdings ist MD5 angesichts der breiten Vielfalt von unterschiedlichem
Dokumentinhalt, der durch den Server 28 verarbeitet werden
muss, die effizienteste und zuverlässigste Option.
-
Betrachten
wir nun das Beispiel, dass ein Benutzer das Anzeigen eines Dokument-Attachments
anfordert, das aus 200 Seiten Textinhalt besteht. Der Server 28 empfängt die
anfängliche
Konvertierungsanforderung vom Gerät 12 zur Konvertierung
des Dokument-Attachments und baut als Reaktion darauf ein Dokumentobjektmodell
(DOM) für
den Dokumentinhalt auf. Der Server gibt dann das erste Segment (d.
h. Seite) des Inhalts an das Gerät
zurück.
Der Server gibt auch eine Anzeige zur Gesamtzahl der Segmente an
den Client zurück
(z. B. 40 Segmente oder anzeigbare Seiten in der Dokument-DOM-Struktur).
In der vorliegenden Anmeldung kann ein "Segment" bis zu 3000 Bytes an Daten einschließen, was
je nach Schriftarten, Formatierung, Farben oder Dokumentinhalt mehr
oder weniger als eine Seite tatsächlichen
Texts sein kann. Zur Vereinfachung der Beschreibung können jedoch
die Begriffe "Seite" und "Segment" austauschbar verwendet
werden.
-
Beim
Empfangen des ersten Dokumentinhalts (d. h. des ersten Segments
von Daten) vom Server 28 parst das Gerät 12 den Inhalt und
zeigt ihn an (Schritt 45 in 10). Wie
beim Stand der Technik bekannt, kann der Benutzer den "Suchen"-Befehl im Attachment-Viewer aufrufen,
und als Reaktion darauf wird der Benutzer aufgefordert, einen alphanumerischen
Suchbegriff einzugeben (Schritt 47). Der Befehl "Server-Suche" der vorliegenden
Anmeldung ist mit den herkömmlichen
Befehlen "Suchen" und "Nächstes suchen" verknüpft, die
im Attachment-Viewer des Geräts 12 vorhanden
sind. Die 8A zeigt eine grafische Benutzeroberfläche auf
dem Mobilgerät 12 zur
Eingabe einer Suchzeichenkette zum Durchsuchen eines Dokument-Attachments, das
auf dem Gerät
angezeigt werden soll. Nach dem Eingeben des Suchbegriffs (Schritt 49)
durchsucht der Attachment-Viewer (d. h. der Client) das erste Segment
des Inhalts im Gerät.
-
Wird
eine Übereinstimmung
gefunden (d. h. ein JA in Schritt 51), so wird der Client-Bildschirm
aktualisiert (Schritt 53) um die gefundene Position des
Suchbegriffs zu widerspiegeln, indem der Cursor über dem ersten Buchstaben des übereinstimmenden
alphanumerischen Textsegment oder Worts platziert wird, wie das weiter
unten detaillierter unter Bezug auf 9 beschrieben
wird. Um das Durchsuchen des anfänglich
abgerufenen und nunmehr auf dem Client-Gerät 12 befindlichen
Dokumentinhalts fortzusetzen (d. h. ein JA in Schritt 55),
ruft der Benutzer immer wieder den Befehl "Nächstes
suchen" auf (Schritt 57).
-
Für jede Übereinstimmung
in dem anfänglich
abgerufenen und sich bereits auf dem Gerät 12 befindlichen
Inhalt nimmt der Client eine optische Aktualisierung des Displays
vor, um wie oben angedeutet die Position im Dokumentinhalt widerzuspiegeln,
an der auf den Suchbegriff gestoßen wurde.
-
Wenn
innerhalb des auf dem Client-Gerät 12 befindlichen
Dokumentinhalts keine weiteren Übereinstimmungen
für die
Befehle "Suchen" oder "Nächstes suchen" gefunden werden
(d. h. ein NEIN in Schritt 51), dann wird eine Nachricht
angezeigt, die den Benutzer darüber
informiert, dass der gesuchte Text in dem Abschnitt des Dokuments,
der sich auf dem Gerät
befindet, nicht gefunden wurde. Wie in 8B gezeigt
wird, fordert diese Nachricht den Benutzer auf, eine serverseitige
Suche nach der gesuchten Textzeichenfolge zu initiieren.
-
Wenn
der Benutzer die Antwort "Ja" wählt, wird
eine Suche durch den restlichen Dokumentinhalt auf dem Attachment-Server 28 initiiert,
der noch nicht durch das Gerät 12 abgerufen
wurde (d. h. ein JA in Schritt 59). Konkret sendet das
Client-Gerät 12 einen "Server-Suche"-Befehl an den Server 28,
der die zu suchende Zeichenkette und einen zu durchsuchenden Segment-Indexbereich
enthält
(Schritt 61). Für
das Beispiel von 8A gibt der Client einen "Server-Suche"-Befehl mit dem Suchbegriff "comments" und einen zu durchsuchenden
Segment-Indexbereich, z. B. "2-40" an den Server aus.
Der Segment-Indexbereich enthält
nicht das Segment 1, weil das Segment 1 sich bereits auf dem Gerät 12 befindet.
-
Der
Server 28 durchsucht dann das DOM in den Segmenten 2 bis
40 nach jeglichem Dokumentinhalt, der das Suchwort "comments" enthält.
-
Wenn
der Attachment-Server 28 auf eine Übereinstimmung mit der eingegebenen
Zeichenkette stößt (d. h.
ein JA in Schritt 63), dann gibt er den Attachment-Abschnitt
an den Attachment-Viewer des Client-Geräts 12 zurück (Schritt 65),
und zwar zusammen mit dem Segmentindex, wo die Übereinstimmung gefunden wurde (wenn
Z. B. die nächste Übereinstimmung
sich in Segment 20 befindet, dann wird der Segmentinhalt
zusammen mit dem Segment-Index 20 an den Client zurückgegeben).
Der Client 12 garst dann den Inhalt (d. h. von Segment 20),
zeigt ihn an und hebt die Position des Such-"Treffers" für
den Benutzer hervor. Außerdem
wird der Benutzer optisch darüber
informiert, dass der Inhalt der Segmente 2 bis 19 sich noch auf
dem Server 28 befindet, indem zwischen die Inhalte von
Segment 1-20 eine optische Anzeigeleiste "Übersprungener
Inhalt" eingefügt wird
(Schritt 67). Die Übereinstimmung
wird in herkömmlicher
Weise auf dem Gerät 12 kenntlich
gemacht (Schritt 53), indem das erste Zeichen der im abgerufenen
Inhalt gefundenen Zeichenkette hervorgehoben wird, wie das weiter
unten detailliert erläutert
wird.
-
Wenn
der Benutzer die Suche fortsetzt, indem er den herkömmlichen
Befehl "Nächstes suchen" wählt, während noch
immer Inhalt auf dem Server 28 verbleibt (Schritt 57),
dann wird jede nachfolgende Übereinstimmung
innerhalb des Inhalts von Segment 20 angezeigt (Schritt 53),
wie das zuvor beschrieben wurde. Wenn keine weiteren Übereinstimmungen
innerhalb des Segments 20 gefunden wird, dann wird der
Benutzer erneut aufgefordert (8B), eine
Server-Such-Operation
durchzuführen,
wenn das erwünscht
ist.
-
Der
Befehl "Server-Suche" mit dem Suchbegriff
wird erneut ausgegeben (Schritt 61), aber dieses Mal ist
der angeforderte Segment-Index 21 bis 40, da der
Client bereits weiß,
dass Segment 1 bis 20 bereits durchsucht wurden.
Wenn eine weitere Übereinstimmung
gefunden wird (z. B. in Segment 39), dann wird der Inhalt von
Segment 39 und die Segment-Indexnummer 39 zum
Client zurückgegeben
(Schritt 65) wo der Inhalt geparst und angezeigt wird.
Wiederum wird zwischen den Inhalt des Segments 20 und des
Segments 39 eine optische Anzeigeleiste "Übersprungener Inhalt" eingefügt (Schritt 67),
um den Benutzer darüber
zu informieren, dass noch immer Inhalt auf dem Server 28 verblieben
ist, der noch nicht zum Gerät 12 abgerufen
wurde.
-
Die
serverseitige Suche kann wiederholt durchgeführt werden, bis alle Abschnitte,
die Übereinstimmungen
mit der Zeichenkette enthalten, zum Gerät 12 heruntergeladen
wurden. Bei Ausführung
des letzten Befehls "Server-Suche" durchsucht der Server 28 die
DOM-Inhalte nach Segment 40. In diesem Fall werden im verbleibenden
Segment keine weiteren Übereinstimmungen
mit dem Suchbegriff gefunden. Wenn das auftritt, wird dem Benutzer
ein Dialog "Ende
des Abschnitts erreicht" angezeigt
(Schritt 69), wie das in 9 gezeigt
ist. Wie oben angedeutet, wird eine Übereinstimmung auf dem Gerät 12 kenntlich
gemacht, indem das erste Zeichen der Zeichenkette hervorgehoben
wird, die in dem abgerufenen Inhalt gefunden wurde. Das wird in 9 gezeigt
(wo die Zeichenkette das Wort "comments" ist und der erste
Buchstabe "c" hervorgehoben ist).
-
Abschließend und
unter Verwendung des oben beschriebenen Beispiels kann gesagt werden,
dass die Operation "Server-Suche" es dem Client ermöglicht,
ein 200-Seiten-Dokument zu durchsuchen, wobei lediglich die Segmente
des Inhalts, in denen eine Übereinstimmung
gefunden wird, abgerufen, geparst und angezeigt werden (z. B. die
Segmente 1, 20 und 39), im Gegensatz zum Abrufen sämtlicher 40 Segmente
des Inhalts zum Gerät
zum Parsen und Anzeigen, um dasselbe Ergebnis zu erzielen. Deshalb
bewirkt der "Server-Suche"-Befehl eine enorme
Optimierung der Bandbreitennutzung, der Nutzung des Gerätespeichers
und der Gesamtreaktionszeit beim Durchsuchen von Dokumenten, indem
nur die relevanten Segmente oder Abschnitte zum Gerät 12 zurückgegeben
werden, um sie dort durch den Benutzer zu betrachten.
-
Wenden
wir uns nun dem in 11 dargestellten serverseitigen
Prozess zu: Wenn der Attachment-Server 28 eine Serversuchanforderung
für ein
Attachment empfängt
(Schritt 71), dann extrahiert er zunächst das zu suchende Textmuster
(Schritt 73) zusammen mit den verschiedenen Suchoptionen,
z. B. Großschreibung
beachten, Vorwärts-
oder Rückwärtssuche
usw. Außerdem
extrahiert der Attachment-Server aus der Anforderung den zu durchsuchenden
Segmentbereich und nimmt eine Neuordnung des Segmentbereichs basierend
auf den Suchoptionen vor (Schritt 75).
-
Nach
dem Abrufen der vorpaginierten Dokument-DOM-Struktur für das Attachment
aus dem speicherinternen Dokument-DOM-Cache (Schritt 79)
durchläuft
der Attachment-Server 28 die DOM-Struktur (Schritt 81),
bis er den Startknoten für
das erste Segment in dem Segmentbereich erreicht. Er fährt mit
dem Durchlaufen der DOM-Struktur fort (d. h. ein JA in Schritt 83,
gefolgt von Schritt 85) und mit dem Handling der Knoten des
Befehlstyps Absatz (Schritt 87) oder Textsegment (Schritt 89)
in der DOM-Struktur. Beim Parsen der Absatzbefehle setzt der Attachment-Server 28 die
interne Variable der Absatztextinhalte zurück (Schritt 91), ruft die
in dem Textsegmentbefehl gespeicherten Textinhalte ab und fügt den Text
zu den Absatzinhalten zu (Schritt 93). Der Server durchsucht
dann die nächsten
Inhalte nach dem Textmuster (Schritt 95). Der Attachment-Server
iteriert die gesamte DOM-Struktur,
bis das nächste
Textmuster gefunden wurde oder bis alle Segmente in dem Segmentbereich
durchsucht wurden (d. h. ein NEIN in Schritt 83). Wenn
in der durch den Segmentbereich spezifizierten DOM-Struktur kein
solches Textmuster gefunden wird, gibt der Attachment-Server einen
Fehler zurück
(Schritt 99). Ansonsten gibt der Server die Inhalte des
ersten Segments zurück,
welches das Textmuster enthält
(Schritt 97).
-
Der
Attachment-Server 28 kann die übereinstimmenden Textinhalte
in mehrere Segmente aufteilen, behält aber immer die DOM-Struktur
für das
Segment, wo der übereinstimmende
Text startet, bei und gibt in der Antwort zum Client 12 die
Anzahl der Zeichen des Testmusters an, die in der beibehaltenen
DOM-Struktur enthalten sind.
-
Für den Fachmann
auf dem Gebiet der Technik sind nach dem Lesen dieser Beschreibung
der bevorzugten Ausführungsform
möglicherweise
Varianten und alternative Beispiele vorstellbar.