DE69935848T2 - System zur lieferung von daten über einen übertragungskanal mit niedrigen bitraten - Google Patents

System zur lieferung von daten über einen übertragungskanal mit niedrigen bitraten Download PDF

Info

Publication number
DE69935848T2
DE69935848T2 DE69935848T DE69935848T DE69935848T2 DE 69935848 T2 DE69935848 T2 DE 69935848T2 DE 69935848 T DE69935848 T DE 69935848T DE 69935848 T DE69935848 T DE 69935848T DE 69935848 T2 DE69935848 T2 DE 69935848T2
Authority
DE
Germany
Prior art keywords
data
script
information
file
mobile device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69935848T
Other languages
English (en)
Other versions
DE69935848D1 (de
Inventor
Dave Bothell WECKER
Vinay Bellevue DEO
John Mark Kirkland MILLER
David Redmond TUNIMAN
Michael J. Redmond O'LEARY
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Corp
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/107,666 external-priority patent/US6311058B1/en
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of DE69935848D1 publication Critical patent/DE69935848D1/de
Application granted granted Critical
Publication of DE69935848T2 publication Critical patent/DE69935848T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26Power supply means, e.g. regulation thereof
    • G06F1/32Means for saving power
    • G06F1/3203Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3206Monitoring of events, devices or parameters that trigger a change in power modality
    • G06F1/3209Monitoring remote activity, e.g. over telephone lines or network connections
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00Handling natural language data
    • G06F40/10Text processing
    • G06F40/103Formatting, i.e. changing of presentation of documents
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00Handling natural language data
    • G06F40/10Text processing
    • G06F40/12Use of codes for handling textual entities
    • G06F40/123Storage facilities
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00Handling natural language data
    • G06F40/10Text processing
    • G06F40/12Use of codes for handling textual entities
    • G06F40/14Tree-structured documents
    • G06F40/143Markup, e.g. Standard Generalized Markup Language [SGML] or Document Type Definition [DTD]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00Handling natural language data
    • G06F40/10Text processing
    • G06F40/12Use of codes for handling textual entities
    • G06F40/149Adaptation of the text data for streaming purposes, e.g. Efficient XML Interchange [EXI] format
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00Handling natural language data
    • G06F40/10Text processing
    • G06F40/12Use of codes for handling textual entities
    • G06F40/151Transformation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00Handling natural language data
    • G06F40/10Text processing
    • G06F40/197Version control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227Filtering policies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227Filtering policies
    • H04L63/0263Rule management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04Protocols for data compression, e.g. ROHC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M1/00Substation equipment, e.g. for use by subscribers
    • H04M1/72Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H04M1/72406User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by software upgrading or downloading
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M1/00Substation equipment, e.g. for use by subscribers
    • H04M1/72Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H04M1/72409User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by interfacing with external accessories
    • H04M1/72412User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by interfacing with external accessories using two-way short-range wireless interfaces
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08Access security
    • H04W12/088Access security using filters or firewalls
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/18Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02Terminal devices
    • H04W88/022Selective call receivers
    • H04W88/023Selective call receivers with message or information receiving capability
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/104Grouping of entities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M1/00Substation equipment, e.g. for use by subscribers
    • H04M1/26Devices for calling a subscriber
    • H04M1/27Devices whereby a plurality of signals may be stored simultaneously
    • H04M1/274Devices whereby a plurality of signals may be stored simultaneously with provision for storing more than one subscriber number at a time, e.g. using toothed disc
    • H04M1/2745Devices whereby a plurality of signals may be stored simultaneously with provision for storing more than one subscriber number at a time, e.g. using toothed disc using static electronic memories, e.g. chips
    • H04M1/2753Devices whereby a plurality of signals may be stored simultaneously with provision for storing more than one subscriber number at a time, e.g. using toothed disc using static electronic memories, e.g. chips providing data content
    • H04M1/2757Devices whereby a plurality of signals may be stored simultaneously with provision for storing more than one subscriber number at a time, e.g. using toothed disc using static electronic memories, e.g. chips providing data content by data transmission, e.g. downloading
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12Messaging; Mailboxes; Announcements

Description

  • HINTERGRUND DER ERFINDUNG
  • Die vorliegende Erfindung betrifft persönliche mobile Rechenvorrichtungen, welche im Allgemeinen als Mobilvorrichtungen bekannt sind. Insbesondere betrifft die vorliegende Erfindung ein System und ein Verfahren zur Lieferung und zum Empfang von Informationen auf einer Mobilvorrichtung.
  • Mobilvorrichtungen sind kleine elektronische Rechenvorrichtungen, welche oft als persönliche digitale Assistenten bezeichnet werden. Viele derartige Mobilvorrichtungen sind tragbare Vorrichtungen oder handtellergroße Vorrichtungen, welche bequem in die Hand passen. Eine kommerziell erhältliche Mobilvorrichtung wird unter dem Markennamen HandHeld PC. (oder H/PC) mit Software vertrieben, welche durch die Microsoft Corporation aus Redmond, Washington bereitgestellt wird.
  • Im Allgemeinen umfasst die Mobilvorrichtung einen Prozessor, einen Direktzugriffspeicher (RAM) und eine Eingabevorrichtung, wie beispielsweise eine Tastatur und eine Anzeige. Die Tastatur kann in die Anzeige integriert sein, wie beispielsweise wenn die Tastatur als berührungsempfindliche Anzeige integriert ist. Eine Kommunikationsschnittstelle wird optional bereitgestellt und im Allgemeinen zur Kommunikation mit einem Desktop-Computer verwendet. Eine ersetzbare oder wiederaufladbare Batterie treibt die Mobilvorrichtung an. Optional kann die Mobilvorrichtung Energie von einer externen Energiequelle empfangen, welche die eingebaute Batterie übergeht oder wiederauflädt.
  • In einigen vorherigen Anmeldungen wird die Mobilvorrichtung in Verbindung mit einem Desktop-Computer verwendet. Beispielsweise muss der Benutzer der Mobilvorrichtung möglicherweise auf einen Desktop-Computer in der Arbeit oder zu Hause, oder beides, zugreifen und diesen verwenden. Der Benutzer betreibt typischerweise dieselben Arten von Anwendungen sowohl auf dem Desktop-Computer als auch auf der Mobilvorrichtung. Somit ist es recht vorteilhaft, wenn die Mobilvorrichtung so konstruiert ist, dass sie mit dem Desktop-Computer gekoppelt werden kann, um Informationen mit dem Desktop-Computer auszutauschen und zu teilen.
  • Ein weiteres Verfahren zur Bereitstellung von Informationen für derartige Mobilvorrichtungen besteht über eine drahtlose Übertragungsleitung. Derartige Informationen können elektronische Mails oder Nachrichten, Wetter, Sport, Verkehr und Informationen über lokale Ereignisse umfassen. Die Informationen werden typischerweise von einem Desktop-Computer erhalten, welcher mit dem Internet verbunden ist, und über eine Drahtverbindung übertragen. Jedoch kann es erwünscht sein, derartige Informationen auch über eine drahtlose Verbindung zu liefern. Ein drahtloser Empfänger an der Mobilvorrichtung kann zum Empfang der Informationen betrieben werden, wenn diese an die Mobilvorrichtung gesendet werden.
  • Gegenwärtig existiert keine vernünftige Art der Lieferung von Schubinhalt (wie beispielsweise hypertext markup language- oder HTML-Inhalt, welcher auf einem globalen Netz, wie beispielsweise dem Internet und dem World Wide Web, bereitgestellt wird) an derartige Vorrichtungen auf drahtlose Weise und in einer offenen und verfügbaren Architektur. Die Bitgeschwindigkeit von herkömmlichen drahtlosen Kanälen ist sehr niedrig. Somit ist die Lie ferung von sehr großem Inhalt (wie beispielsweise HDML-Inhalt) höchst unpraktisch.
  • Ein herkömmliche Art der Herangehensweise an die Lieferung derartiger Informationen besteht darin, den Inhalt in einem vorrichtungsfreundlichen Format, wie beispielsweise HTML, neu zu verfassen. Der Inhalt wird dann über ein Zugmodell erhalten. Eine weitere Herangehensweise, welche gegenwärtig zur Lieferung von Informationen über ein drahtloses Medium verwendet wird, ist ein geschlossenes Modell. In einem geschlossenen Modell kann ein Bereitsteller von Inhalt nur Inhalt bereitstellen, welcher in einem Format verfasst ist, das zum Empfang durch eine bestimmte Vorrichtung geeignet ist, welche eine bestimmte Art von Software implementiert. Dies bedeutet, dass die große Mehrheit von Web-Inhalt für die Sichtung auf derartigen Vorrichtungen nicht verfügbar ist.
  • KAASHOEK M F ET AL: "DYNAMIC DOCUMENTS: MOBILE WIRELESS ACCESS TO THE WWW" PROCEEDINGS, WORKSHOP ON MOBILE COMPUTING SYSTEMS AND APPLICATIONS, 8. Dezember 1994 (1994-12-09), Seiten 179 bis 184, offenbart dynamische Dokumentenprogramme für die Ausführung auf einer Mobilvorrichtung zur Erzeugung eines Dokuments.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Bereitgestellt wird ein System zur Bereitstellung von Informationsinhalt von einem Bereitsteller von Inhalt für eine Mobilvorrichtung wie in Anspruch 1 ausgeführt. Bereitgestellt wird auch ein computerlesbarer Datenträger, welcher Anweisungen enthält, die von einer Mobilvorrichtung lesbar sind, wie in Anspruch 17 ausgeführt, einer Mobilvorrichtung wie in Anspruch 29 ausgeführt, sowie ein Verfahren der Wiedergabe von Informationen auf einer Mobilvorrichtung, wie in Anspruch 30 ausgeführt.
  • Die vorliegende Erfindung stellt ein System bereit, durch welches Informationsinhalt an eine Mobilvorrichtung geliefert wird.
  • Der Web-Inhalt wird in Daten- und Skriptinformationen aufgeteilt. Die Skriptinformationen werden zur Operation der Daten zur Wiedergabe der Daten in einem vorgegebenen Format verwendet.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • 1 ist ein vereinfachtes Blockdiagramm, welches eine Ausführungsform einer Mobilvorrichtung in einem System in Übereinstimmung mit der vorliegenden Erfindung zeigt;
  • 2 ist ein detaillierteres Blockdiagramm einer Ausführungsform einer in 1 gezeigten Mobilvorrichtung;
  • 3 ist eine vereinfachte piktographische Darstellung einer Ausführungsform der in 2 gezeigten Mobilvorrichtung;
  • 4 ist eine vereinfachte piktographische Darstellung einer weiteren Ausführungsform der in 2 gezeigten Mobilvorrichtung;
  • 5 ist ein Blockdiagramm einer Ausführungsform eines Desktop-Computers in Übereinstimmung mit einem Aspekt der vorliegenden Erfindung;
  • 6 ist ein Ablaufdiagramm, welches den Betrieb einer Mobilvorrichtung in Übereinstimmung mit einem Aspekt der vorliegenden Erfindung zeigt;
  • 7 stellt eine allgemeine Datenstruktur eines Pakets dar, welches an die Mobilvorrichtung in Übereinstimmung mit einem Aspekt der vorliegenden Erfindung übertragen wird;
  • 8 ist ein detaillierteres Ablaufdiagramm, welches eine Routing- und Übersetzungsschicht sowie die Vorbereitung von Paketen für die Übertragung in Übereinstimmung mit einem Aspekt der vorliegenden Erfindung zeigt.
  • AUSFÜHRLICHE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
  • 1 stellt ein System 10 dar, in welchem die vorliegende Erfindung illustrativ realisiert ist. Das System 10 weist den Inhaltslieferanten 12, den drahtlosen Träger 14, den Desktop-Computer 16 und die Mobilvorrichtung 18 auf. Der Inhaltslieferant 12 stellt jegliche geeignete Art von Daten aus einer Datenbank oder einer anderen Datenquelle bereit. Beispielsweise wird der Inhaltslieferant 12 nachfolgend als Bereitsteller von Inhalten aus dem World Wide Web des Internet beschrieben. In der bevorzugten Ausführungsform wird der Inhalt in einem Standardformat, wie beispielsweise HTML, JPEG, GIF, WAV etc. bereitgestellt. Der Web-Inhalt wird ebenfalls bevorzugt in einer CDF-Datei (CDF = channel definition formst oder Kanaldefinitionsformat) beschrieben. Ein einziger Inhaltsabschnitt (wie beispielsweise eine Webseite oder eine Website) wird nachfolgend als ein Mobilkanal beschrieben.
  • Ein Mobilkanal ist eine selbstbeschreibende Website, welche alle Informationen enthält, die zum effizienten Herunterladen von Web-Inhalt auf die Mobilvorrichtung 18 nötig sind. Drei Komponenten werden in einem bevorzugten Mobilkanal bereitgestellt. Die Komponenten umfassen eine CDF-Datei, einen Satz von Skript-Dateien zur Wiedergabe des Kanals und einen Satz wiederzugebender Daten-Dateien. Die CDF-Dateien werden ausführlicher im US-Patent Nr. 6,449,638 mit dem Titel CHANNEL DEFINITION ARCHITECTURE EXTENSION beschrieben. Kurz gesagt ist CDF ein Inventar an Inhalt, welcher auf dem Mobilkanal enthalten ist.
  • Die Skript-Dateien enthalten Skrip, welches Schablonen definiert, die das Erscheinungsbild der Daten auf dem Bildschirm der Mobilvorrichtung 18 spezifizieren. Skripte sind bevorzugt in VBS (visual basic script, visuelles Basisskript) abgefasst.
  • Die Daten-Dateien entsprechen einer oder mehreren Skript-Dateien und weisen Daten auf, welche den substantiven Inhalt des wiederzugebenden Kanals anzeigen. Die Daten sind in kleinen und ein fachen Textdateien verpackt. Alle diese Informationen werden zur Definition von Web-Inhalt verwendet.
  • Der drahtlose Träger 14 wird ausführlicher später in der Anmeldung beschrieben. Kurz gesagt ist der drahtlose Träger 14 jedoch zum Empfang von Web-Inhalb von dem Web-Inhaltslieferanten 12 über eine Einwahl- oder direkte Internetverbindung oder eine Netzwerkverbindung ausgelegt. Der drahtlose Träger 14 weist auch einen drahtlosen Schubserver 20 auf. Der Server 20 teilt den vom Inhaltslieferanten 12 empfangenen Inhalt in Stücke, welche mit der speziellen Art von Transport kompatibel sind, der durch den drahtlosen Träger 14 verwendet wird. Beispielsweise kann der Server 20 die Daten derart aufteilen, dass sie mit Beschränkungen der maximalen Paketgröße, mit Anforderungen an den Zeichensatz etc., für die verwendete Kanalart oder Transportart konform gehen. Vor der Übertragung werden die Daten bevorzugt in eine andere Form übersetzt. Wie später in der Anmeldung ausführlicher beschrieben, kann eine derartige Übersetzung die Kompression, Verschlüsselung, Codierung und dann Verpackung umfassen. Wurden die Daten erst einmal in geeigneter Weise aufgeteilt, so dass sie mit den Transportbeschränkungen konform gehen, werden die Daten dann für die Übertragung über Luft durch ein drahtloses Netzwerk konfiguriert (wie beispielsweise über einen Paging-Kanal), um direkt auf der Mobilvorrichtung 18 empfangen zu werden. Die übertragenen Daten werden durch einen drahtlosen Empfänger und einer Treiberkomponente 22 auf der Mobilvorrichtung 18 empfangen, wo die Daten für die Verwendung durch die Mobilvorrichtung 18 vorbereitet werden.
  • Bevorzugt weist die Mobilvorrichtung 18 auch ein Modem 24 auf. Somit kann der Web-Inhalt, statt durch den drahtiosen Träger 14 übertragen zu werden, direkt vom Web-Inhaltslieferanten 12 durch eine direkte Einwahl-Modemverbindung an die Mobilvorrichtung 18 übertragen werden.
  • Der Desktop-Computer 16 wird ebenfalls später in der Beschreibung ausführlicher beschrieben. Kurz gesagt wird der Desktop- Computer 16 jedoch mit einem Standard-Webbrowser, wie beispielsweise dem Internet Explorer 4.0 bereitgestellt, welcher im Handel von der Microsoft Corporation aus Redmond, Washington erhältlich ist. Ist dies der Fall, so können die Benutzer des Desktop 16 bevorzugt Kanäle auf Standardweise abonnieren, welche dem Benutzer einen bestimmten Kanalinhalt bereitstellen, der offline oder online gebrowst werden kann. Der Desktop-Computer 16 wird bevorzugt mit einem ladbaren Transport (in Übereinstimmung mit einem Aspekt der vorliegenden Erfindung) bereitgestellt, welcher auf die Skriptdateien zugreift und an den entsprechenden Datendateien (in Übereitstimmung mit dem Skript) agiert, um den Inhalt dort wiederzugeben, wo der Desktop-Computer 16 die Daten wiedergibt. Der Desktop-Computer 16 kann durch den Transport periodisch neue und aktualisierte Skript-, Daten- und CDF-Dateien entweder zur weiteren Übertragung an die Mobilvorrichtung 18 oder einfach zur Wiedergabe der Daten abrufen oder empfangen. Die Skript-, Daten- und CDF-Dateien können entweder zusammen oder unabhängig voneinander übertragen werden. Da Skriptingdateien typischerweise wesentlich weniger häufig aktualisiert werden müssen als die Datendateien, liefert dies dem Benutzer die Fähigkeit, den Webinhalt auf dem Desktop (offline) zu betrachten, während nur geringe Mengen an Bandbreite zur inkremetalen Aktualisierung der Datendateien nötig sind.
  • Der Desktop-Computer 16 weist ebenfalls bevorzugt die Synchronisationskomponente 26 auf. Kurz gesagt, ist die Synchronisationskomponente 16 zur Interaktion mit einer ähnlichen Synchronisationskomponente 28 auf der Mobilvorrichtung 18 derart ausgelegt, dass Dateien, welche der Synchronisation unterliegen, vom Desktop-Computer 16 aus auf der Mobilvorrichtung 18 aktualisiert werden können, oder umgekehrt. Sind sie synchronisiert, so enthalten beide Dateien (diejenigen auf dem Computer 16 und diejenigen auf der Mobilvorrichtung 18) aktuelle Informationen.
  • Insbesondere kann in der bevorzugten Ausführungsform die Mobilvorrichtung 18 mit entweder dem Desktop-Computer 16 oder einer anderen Mobilvorrichtung 18 oder beiden synchronisiert werden.
  • In diesem Fall ähneln die Eigenschaften der in einem Objektspreicher auf der Mobilvorrichtung 18 gespeicherten Objekte den Eigenschaften anderer Fälle desselben in einem Objektspeicher auf dem Desktop-Computer 16 oder einer anderen Mobilvorrichtung 18 gespeicherten Objekts. Wenn somit beispielsweise ein Benutzer einen Fall eines in einem Objektspeicher auf dem Desktop-Computer 16 gespeicherten Objekts ändert, wird der zweite Fall dieses Objekts, welcher in dem Objektspeicher der Mobilvorrichtung 18 gespeichert ist, das nächste Mal, wenn die Mobilvorrichtung 18 mit dem Desktop-Computer 16 verbunden wird, aktualisiert, so dass beide Fälle desselben Objekts aktuelle Daten enthalten. Dies wird als Synchronisation bezeichnet.
  • Zur Erzielung von Synchronisation laufen Synchronisationskomponenten 26 und 28 sowohl auf der Mobilvorrichtung 18 als auch auf dem Desktop-Computer 18 (oder einer anderen Mobilvorrichtung 18). Die Synchronisationskomponenten kommunizieren miteinander durch wohldefinierte Schnittstellen, um eine Kommunikation und Synchronisation zu erzielen.
  • Die Mobilvorrichtung 18 ist ebenfalls bevorzugt mit einem Skriptenübersetzer ausgestatten, welcher in einer bevorzugten Ausführungsform derselbe oder ein ähnlicher ist wie der ladbare Transport auf dem Desktop-Computer 16. Ein derartiger Transport kann beispielsweise ein verringerter visueller Basisübersetzer sein, welcher das Formatierungsskript empfängt und übersetzt. Das Skript steht im Zusammenhang mit einer bestimmten Datendatei (typischerweise einer Textdatei), welche die Rohdaten für den Webinhalt hält. Somit operiert der Skriptenübersetzer an den Daten im Zusammenhang mit einem bestimmten Skript zur Bereitstellung des Webinhalts für den Benutzer der Mobilvorrichtung 18.
  • Durch Trennung des Skripts von den Daten im Webinhalt kann Webinhalt an die Mobilvorrichtung 18 über Kanäle mit sehr langsamer Bitgeschwindigkeit übertragen werden. Das Skript muss typischerweise nur sehr selten übertragen werden. Da eine einzelne Datei typischerweise auch viel kleiner ist als die Skriptdateien, können die Daten recht häufig aktualisiert werden, wodurch dem Benutzer der Mobilvorrichtung 18 aktuelle Webinhalts-Informationen geliefert werden, ohne das neue Skript zu übertragen. Somit erlaubt die Teilung von Skript und Daten die Übertragung von Webinhalts-Informationen auf sehr effiziente Weise über Kanäle mit geringer Bitgeschwindigkeit.
  • Es sollte sich verstehen, dass in der bevorzugten Ausführungsform, während die Mobilvorrichtung 18 ebenfalls an den Desktop-Computer 16 gekoppelt werden kann, sie ebenfalls an eine andere Mobilvorrichtung 18 gekoppelt werden kann. Diese Verbindung kann mit Hilfe einer beliebigen geeigneten und im Handel erhältlichen Kommunikationsleitung und mit Hilfe eines geeigneten Kommunikationsprotokolls erfolgen. Beispielsweise kommuniziert in einer bevorzugten Ausführungsform die Mobilvorrichtung 18 entweder mit dem Desktop-Computer 16 oder mit einer anderen Mobilvorrichtung 18 mit einem physikalischen Kabel, welches mit Hilfe eines seriellen Kommunikationsprotokolls kommuniziert. Andere Kommunikationsmechanismen werden durch die vorliegende Erfindung ebenfalls unterstützt, so beispielsweise die Infrarotkommunikation, oder IR-Kommunikation, oder andere geeignete Kommunikationsmechanismen.
  • 2 ist ein detaillierteres Blockdiagramm der Mobilvorrichtung 18. Die Mobilvorrichtung 18 weist bevorzugt den Mikroprozessor 30, den Speicher 32, Eingabe-/Ausgabe- oder I/O-Komponenten 34, die Desktop-Kommunikationsschnittstelle 36, den drahtlosen Empfänger 37 und die Antenne 39 auf. In einer bevorzugten Ausführungsform werden diese Komponenten des Mobilteils 10 zur Kommunikation miteinander über einen geeigneten Bus 38 gekoppelt.
  • Der Speicher 32 ist bevorzugt als nichtflüchtiger Elektronikspeicher, wie beispielsweise ein Direktzugriffs- oder RAM-Speicher mit einem Batterie-Unterstützungsmodul (nicht gezeigt) realisiert, so dass Informationen, welche im Speicher 32 gespei chert sind, nicht verlorengehen, wenn die allgemeine Energieversorgung der Mobilvorrichtung 18 abgeschaltet wird. Ein Abschnitt des Speichers 32 ist bevorzugt als adressierbarer Speicher zur Programmausführung ausgelegt, während ein anderer Abschnitt des Speichers 32 bevorzugt zur Speicherung verwendet wird, wie beispielsweise zur Simulation von Speicherung auf einem Diskettenlaufwerk.
  • Der Speicher 32 weist das Betriebssystem 40, ein Anwendungsprogramm 42 (wie beispielsweise eine persönliche Informationsverwaltung PIM) sowie einen Objektspeicher 44 auf. Während des Betriebs wird das Betriebssystem 40 bevorzugt durch den Prozessor 30 vom Speicher 32 aus ausgeführt. Das Betriebssystem 40 ist in einer bevorzugten Ausführungsform ein Betriebssystem der Marke Windows CE, welches im Handel von der Microsoft Corporation erhältlich ist. Das Betriebssystem 40 ist bevorzugt für Mobilvorrichtungen konstruiert und realisiert Datenbank-Merkmale, welche durch die PIM 42 durch einen Satz exponierter Anwendungsprogramm-Schnittstellen und -Verfahren verwendet werden können. Die im Objektspeicher 44 gespeicherten Objekte werden bevorzugt durch die PIM 42 und das Betriebssystem 40 aufrechterhalten, und zwar wenigstens teilweise auf Anrufe an die exponierten Anwendungsprogramm-Schnittstellen und -Verfahren hin.
  • Die I/O-Komponenten 34 sind in einer bevorzugten Ausführungsform bereitgestellt, um Eingabe- und Ausgabe-Operationen durch einen Benutzer der Mobilvorrichtung 18 zu vereinfachen. Die I/O-Komponenten 34 werden ausführlicher mit Bezug auf 3 und 4 beschrieben.
  • Die Desktop-Kommunikationsschnittstelle 36 wird optional als eine beliebige geeignete Kommunikationsschnittstelle bereitgestellt. Die Schnittstelle 36 wird bevorzugt zur Kommunikation mit dem Desktop-Computer 16, dem Inhaltsanbieter 12, dem drahtlosen Träger 14 und optional einer weiteren Mobilvorrichtung 18, wie mit Bezug auf 1 beschrieben, bereitgestellt. Somit weist die Kommunikationsschnittstelle 36 bevorzugt die Synchro nisationskomponenten 28 zur Kommunikation mit dem Desktop-Computer 16 und das Modem 24 zur Kommunikation mit dem Inhaltsanbieter 12 auf. Der drahtlose Empfänger und der Treiber 22 werden zur Kommunikation mit dem drahtlosen Träger 14 verwendet.
  • 3 ist eine vereinfachte piktographische Darstellung einer bevorzugten Ausführungsform einer Mobilvorrichtung 10, welche in Übereinstimmung mit der vorliegenden Erfindung verwendet werden kann. Die Mobilvorrichtung 10, wie in 3 dargestellt, kann ein Desktop-Assistent sein, welcher unter der Bezeichnung H/PC mit Software verkauft wird, die von der Microsoft Corporation bereitgestellt wird. In einer bevorzugten Ausführungsform weist die Mobilvorrichtung 18 eine Miniatur-Tastatur 43, die Anzeige 45 und den Griffel 46 auf. In der in 3 gezeigten Ausführungsform ist die Anzeige 45 eine Flüssigkristall- oder LCD-Anzeige, welche einen kontaktempfindlichen Anzeige-Bildschirm in Verbindung mit einem Griffel 46 verwendet. Der Griffel 46 wird dazu verwendet, auf die Anzeige 45 an bestimmten Koordinaten zu drücken oder sie zu berühren, um bestimmte Anwender-Eingabefunktionen zu realisieren. Die Miniatur-Tastatur 43 ist bevorzugt als alpha-numerische Miniatur-Tastatur mit beliebigen geeigneten und erwünschten Funktionstasten realisiert, welche auch zur Erzielung bestimmter Anwender-Eingabefunktionen bereitgestellt sind.
  • 4 ist eine weitere vereinfachte piktographische Darstellung der Mobilvorrichtung 18 in Übereinstimmung mit einer weiteren bevorzugten Ausführungsform der vorliegenden Erfindung. Die Mobilvorrichtung 18, wie in 4 dargestellt, weist einige Komponenten auf, welche denjenigen mit Bezug auf 3 beschriebenen ähneln und mit ähnlichen Bezugszeichen bezeichnet sind. Beispielsweise weist die Mobilvorrichtung 18, wie in 4 gezeigt, ebenfalls den berührungsempfindlichen Bildschirm 45 auf, welcher in Verbindung mit dem Griffel 46 verwendet werden kann, um bestimmte Benutzer-Eingabefunktionen zu erzielen. Es sollte sich verstehen, dass die Anzeige 45 für die Mobilvorrichtung wie in 3 und 4 gezeigt dieselbe Größe aufweisen kann oder unterschiedliche Größen aufweisen kann, jedoch typischerweise sehr viel kleiner ist als eine herkömmliche Anzeige, welche bei einem Desktop-Computer verwendet wird. Beispielsweise können die in 3 und 4 gezeigten Anzeigen 45 durch eine Matrix von lediglich 240 × 320 Koordinaten, oder 160 × 160 Koordinaten, oder eine beliebige andere geeignete Größe, definiert sein.
  • Die in 4 gezeigte Mobilvorrichtung 18 weist auch eine Reihe von Benutzer-Eingabetasten oder -knöpfen wie beispielsweise die Rollknöpfe 47) auf, welche dem Benutzer ein Rollen durch Menüoptionen oder andere Anzeigeoptionen erlauben, die auf der Anzeige 45 angezeigt werden, oder welche dem Benutzer einen Wechsel der Anwendungen erlauben, ohne die Anzeige 45 zu berühren. Zusätzlich weist die in 4 ebenfalls gezeigte Mobilvorrichtung 18 auch bevorzugt einen Energieknopf 49 auf, welcher zum Ein- und Ausschalten der allgemeinen Energieversorgung der Mobilvorrichtung 18 verwendet werden kann.
  • Es sollte sich auch verstehen, dass in der in 4 gezeigten Ausführungsform die Mobilvorrichtung 18 ein Handschriftgebiet 51 aufweist. Das Handschriftgebiet 51 kann in Verbindung mit dem Griffel 46 derart verwendet werden, dass der Benutzer Nachrichten verfassen kann, welche im Speicher 42 für eine spätere Verwendung durch die Mobilvorrichtung 18 gespeichert werden. In einer beispielhaften Ausführungsform werden die handschriftlichen Nachrichten einfach in handschriftlicher Form gespeichert und können durch den Benutzer abgerufen und auf dem Anzeigebildschirm 45 angezeigt werden, so dass der Benutzer die in die Mobilvorrichtung 18 eingegebenen handschriftlichen Nachrichten erneut betrachten kann. In einer weiteren bevorzugten Ausführungsform verfügt die Mobilvorrichtung 18 über ein Zeichenerkennungsmodul, so dass der Benutzer alphanumerische Informationen in die Mobilvorrichtung 18 durch Schreiben dieser alphanumerischen Informationen auf das Gebiet 51 mit dem Griffel 46 eingeben kann. In diesem Fall erkennt das Zeichenerkennungsmodul in der Mobilvorrichtung 18 die alphanumerischen Zeichen und wandelt die Zeichen in computererkennbare alphanumerische Zeichen um, welche durch die Anwendungsprogramme 42 in der Mobilvorrichtung 18 verwendet werden können.
  • 5 und die zugehörige Beschreibung sollen eine kurze, allgemeine Beschreibung eines geeigneten Desktop-Computers 16 liefern, in welchem Abschnitte der Erfindung realisiert sein können. Obgleich dies nicht erforderlich ist, wird die Erfindung mindestens teilweise in dem allgemeinen Kontext computerausführbarer Befehle, wie beispielsweise Programmmodulen, beschrieben, welche durch einen Personalcomputer 16 oder eine Mobilvorrichtung 18 ausgeführt werden. Im Allgemeinen schließen Programmmodule Routineprogramme, Objekte, Komponenten, Datenstrukturen etc. ein, welche bestimmte Aufgaben durchführen oder bestimmte abstrakte Datentypen implementieren. Darüber hinaus wird sich für Fachleute auf dem Gebiet verstehen, dass der Desktop-Computer 16 mit anderen Computersystem-Konfigurationen realisiert werden kann, einschließlich Multiprozessorsystemen, mikroprozessorbasierter oder programmierbarer Verbraucherelektronik, Netzwerk-PCs, Minicomputern, Mainframe-Computern und ähnlichem. Die Erfindung kann auch in verteilten Rechenumgebungen realisiert werden, wo Aufgaben durch entfernte Verarbeitungsvorrichtungen durchgeführt werden, welche durch ein Kommunikationsnetzwerk verbunden sind. In einer verteilten Rechenumgebung können Programmmodule sowohl in lokalen als auch in entfernten Speichervorrichtungen angeordnet sein.
  • Mit Bezug auf 5 weist ein beispielhaftes System zur Realisierung eines Desktop-Computers eine Rechenvorrichtung für allgemeine Zwecke in Form eines herkömmlichen Personalcomputers 16 auf, welcher die Verarbeitungseinheit 48, einen Systemspeicher 50 und einen Systembus 52 einschließt, der verschiedene Systemkomponenten einschließlich des Systemspeichers 50 an die Verarbeitungseinheit 48 koppelt. Der Systembus 52 kann ein beliebiger aus mehreren Arten von Busstrukturen sein, einschließlich eines Speicherbusses oder einer Speicherregelung, eines Peripheriebusses und eines lokalen Busses, welcher eine aus einer Vielzahl von Busarchitekturen verwendet. Der Systemspei cher 50 weist den Nur-Lese-Speicher (ROM) 54 und einen Direktzugriffspeicher (RAM) 55 auf. Ein grundlegendes Eingabe-Ausgabe-System (BIOS) 46, welches die Basisroutine enthält, die die Informationsübertragung zwischen Elementen innerhalb des Desktop-Computers 16 unterstütz, wie beispielsweise während des Hochfahrens, ist im ROM 54 gespeichert. Der Desktop-Computer 16 weist weiter ein Festplattenlaufwerk 57 zum Lesen von und Schreiben auf eine Festplatte (nicht gezeigt), ein Magnetplattenlaufwerk 58 zum Lesen von oder Schreiben auf eine entnehmbare Magnetplatte 59, sowie ein optisches Plattenlaufwerk 60 zum Lesen von oder Schreiben auf eine entnehmbare optische Platte 61, wie beispielsweise eine CD-ROM oder ein anderes optisches Medium, auf. Das Festplattenlaufwerk 57, das Magnetplattenlaufwerk 58 und das optische Plattenlaufwerk 60 sind mit dem Systembus 52 durch eine Festplattenlaufwerks-Schnittstelle 62, eine Magnetplattenlaufwerks-Schnittstelle 63 bzw. eine optische Platten-Schnittstelle 64 verbunden. Die Laufwerke und die zugehörigen computerlesbaren Medien stellen eine nichtflüchtige Speicherung von computerlesbaren Befehlen, Datenstrukturen, Programmmodulen und anderen Daten für den Desktopcomputer 16 bereit.
  • Obgleich die hierin beschriebene beispielhafte Umgebung eine Festplatte, eine entnehmbare Magnetplatte 59 und eine entnehmbare optische Platte 61 verwendet, sollte sich für Fachleute verstehen, dass andere Arten von computerlesbaren Medien, welche Daten speichern können, auf die ein Computer zugreifen kann, wie beispielsweise Magnetband-Kassetten, Fiash-Memory-Karten, digitale Videoplatten (DVDs), Bernoulli-Kassetten, Direktzugriffspeicher (RAMs), Nur-Lese-Speicher (ROMs) und ähnliches in der beispielhaften Betriebsumgebung ebenfalls verwendet werden können.
  • Eine Reihe von Programmmodulen kann auf der Festplatte, der Magnetplatte 59, der optischen Platte 61, dem ROM 54 oder dem RAM 55 gespeichert werden, einschließlich eines Betriebssystems 65, eines oder mehrerer Anwendungsprogramme 66 (welche PIMs ein schließen können), anderer Programmmodule 67 (welche die Synchronisationskomponente 26 einschließen können) und Programmdaten 68. Ein Benutzer kann Befehle und Informationen in den Desktop-Computer 16 durch Eingabevorrichtungen, wie beispielsweise eine Tastatur 70, eine Zeigevorrichtung 72 und ein Mikrophon 74 eingeben. Andere Eingabevorrichtungen (nicht gezeigt) können einen Joystick, ein Game-Pad, eine Satellitenschüssel, einen Scanner oder ähnliches einschließen. Diese und andere Eingabevorrichtungen sind häufig mit der Verarbeitungseinheit 48 durch eine serielle Schnittstelle 76 verbunden, welche mit dem Systembus 52 gekoppelt ist, können jedoch durch andere Schnittstellen verbunden sein, wie beispielsweise eine Soundkarte, einen parallelen Anschluss, eine Game-Port oder einen universellen Seriellbus (USB). Ein Monitor 77 oder eine andere Art von Anzeigevorrichtung ist ebenfalls mit dem Systembus 52 über eine Schnittstelle verbunden, wie beispielsweise ein Video-Adapter 78.
  • Zusätzlich zu dem Monitor 77 können Desktop-Computer typischerweise über andere periphere Ausgabevorrichtungen verfügen, wie beispielsweise den Lautsprecher 75 und Drucker.
  • Der Desktop-Computer 16 kann in einer vernetzten Umgebung unter Verwendung von logischen Verbindungen mit einem oder mehreren entfernten Computern (mit Ausnahme der Mobilvorrichtung 18), wie beispielsweise einem entfernten Computer 79, arbeiten. Der entfernte Computer 79 kann ein weiterer Personal-Computer sein, weiter ein Server, ein Router, ein Netzwerk-PC, eine gleichwertige Vorrichtung oder ein anderer Netzwerkknoten, und weist typischerweise viele oder alle der vorstehend mit Bezug auf den Desktop-Computer 16 beschriebenen Elemente auf, obgleich nur eine Speicherungsvorrichtung 80 in 4 dargestellt ist. Die in 4 aufgezeigten logischen Verbindungen umfassen ein lokales Netzwerk (LAN) 81 und ein globales Netzwerk (WAN) 82. Derartige Netzwerkverbindungen sind in Büros, unternehmensweiten Computernetzwerk-Intranetzen sowie dem Internet allgemein üblich.
  • Bei der Verwendung in einer LAN-vernetzen Umgebung ist der Desktop-Computer 16 mit dem lokalen Netzwerk 81 durch eine Netzwerkschnittstelle oder einen Adapter 83 verbunden. Bei der Verwendung in einer WAN-vernetzten Umgebung weist der Desktop-Computer 16 typischerweise ein Modem 84 oder eine andere Einrichtung zur Herstellung von Kommunikationen über das globale Netzwerk 82, wie beispielsweise das Internet, auf. Das Modem 84, welches intern oder extern sein kann, ist mit dem Systembus 52 über die serielle Anschlussschnittstelle 76 verbunden. In einer Netzwerkumgebung können Programmmodule, welche mit Bezug zum Desktop-Computer 16 dargestellt sind, oder Abschnitte davon, in den entfernten Speicherungsvorrichtungen gespeichert sein. Es sollte sich verstehen, dass die gezeigten Netzwerkverbindungen beispielhaft sind und andere Einrichtungen zur Herstellung einer Kommunikationsverbindung zwischen den Computern verwendet werden können.
  • Auf dem Desktop-Computer 16 läuft das Betriebssystem 65, welches typischerweise in dem nichtflüchtigen Speicher 54 gespeichert ist und auf dem Prozessor 48 ausgeführt wird. Ein geeignetes Betriebssystem ist ein Betriebssystem der Marke Windows, welches durch die Microsoft Corporation vertrieben wird, wie beispielsweise ein Windows95- oder WindowsNT-Betriebssystem, andere abgeleitete Versionen von Betriebssystemen der Marke Windows, oder ein beliebiges anderes geeignetes Betriebssystem. Andere geeignete Betriebssysteme umfassen Systeme wie beispielsweise Macintosh OS, welches durch die Apple Corporation vertrieben wird, und den OS/2 Presentation Manager, welcher durch International Business Machines (IBM) aus Armonk, New York, vertrieben wird. Anwendungsprogramme sind bevorzugt im Programmmodul 67, in einem flüchtigen oder nicht flüchtigen Speicher, gespeichert, oder können in eine beliebige der in 5 gezeigten Komponenten von einer Floppy-Diskette 59, einem CD-ROM-Laufwerk 61 geladen, aus einem Netzwerk über den Netzwerkadapter 83 heruntergeladen oder mit Hilfe eines anderen geeigneten Mechanismus geladen werden.
  • Eine dynamisch verbundene Bibliothek (dynamically linked library, DLL), welche eine Vielzahl ausführbarer Funktionen aufweist, steht mit PIMs in dem Speicher zur Ausführung durch den Prozessor 48 in Zusammenhang. Interprozessor- und Interkomponentenrufe werden durch Verwendung des Komponenten-Objekt-Modells (component object model, COM) vereinfacht, wie es in Programmen allgemein üblich ist, welche für Betriebssysteme der Marke Microsoft Windows verfasst wurden. Bei Verwendung des COM weist kurz gesagt eine Software-Komponente, wie beispielsweise eine DLL, eine Vielzahl derartiger Schnittstellen auf. Jede Schnittstelle legt eine Vielzahl von Verfahren offen, welche einzeln aufgerufen werden können, um unterschiedliche Dienste zu verwenden, welche durch die Software-Komponente angeboten werden. Zusätzlich werden Schnittstellen bereitgestellt, so dass Verfahren oder Funktionen von anderen Software-Komponenten abgerufen werden können, welche optional eines oder mehrere Parameterargumente empfangen und zurücksenden.
  • Im allgemeinen ist die mit dem bestimmten PIM in Zusammenhang sthende DLL speziell darauf ausgelegt, in Verbindung mit diesem PIM zu arbeiten und Desktop-Synchronisationsschnittstellen freizulegen, welche wie vorstehend beschrieben funktionieren, und zwar gemäß einem Synchronisationsprotokoll. Die DLL ruft wiederum Schnittstellen auf, welche durch den PIM freigelegt werden, um auf Daten zuzugreifen, welche individuelle Eigenschaften von Objekten darstellen, die in einem Objektspeicher gehalten werden. Der Objektspeicher 6 kann selbstverständlich in einer beliebigen der geeigneten Speicherkomponenten angeordnet sein, welche mit Bezug auf 4 beschrieben sind.
  • ARCHITEKTUR-BLOCKDIAGRAMM
  • 6 ist ein Blockdiagramm, welches die funktionale Architektur der Mobilvorrichtung 18 darstellt. 6 zeigt ähnliche Punkte wie diejenigen, die vorab in der Beschreibung gezeigt wurden. Ähnliche Komponenten sind ähnlich bezeichnet. 6 veranschaulicht, dass die Mobilvorrichtung 18 Webinhaltsinforma tionen entweder über die Synchronisationskomponente 26, den drahtlosen Empfänger (Funkempfänger und Treiber) 22 oder das Modem 24 empfängt. In jedem dieser Fälle werden die CDF-Dateien sowie die Skriptenmuster und Datendateien, welche durch die Blöcke 202 und 204 dargestellt sind, schließlich an den Cache-Speicher 206 geliefert. An der Stelle, an welcher die Webinhaltsinformationen durch die Synchronisationskomponente 26 empfangen werden, werden die Skriptenmuster und Datendatein möglicherweise nicht verschlüsselt oder codiert oder anderweitig auf dieselbe Weise formatiert wie es für die Übertragung über einen drahtlosen Kanal oder Modemkanal der Fall ist. Daher werden die Skriptenmuster 204 und Datendateien 202 direkt an die Cache-Verwaltung 208 geliefert. Die Cache-Verwaltung 208 empfängt die Skriptenmuster und Datendateien und liefert sie an den Cache-Speicher 206. Die Cache-Verwaltung 208 weist Speicherhandhabung und Zeitgebungskomponenten sowie Datenübertragungskomponenten auf, welche zur Übertragung der Skriptenmuster und Datendateien an eine bestimmte Position im Cache-Speicher 206 und zur Nachspürung dieser Position geeignet sind.
  • Wenn andererseits der Webinhalt über den drahtlosen Empfänger und Treiber 22 oder das Modem 24 empfangen wird, müssen zusätzliche Verarbeitungsschritte unternommen werden, ehe die Daten in den Cache-Speicher gelangen. Der drahtlose Empfänger und Treiber 22 ist eine physikalische Schicht, welche Nachrichten empfängt und filtert und Aufweck-Ereignisse an die Mobilvorrichtung 18 erzeugt. In einer bevorzugten Ausführungsform wird, wie später mit Bezug auf 8 beschrieben, die übertragene Information zunächst übersetzt (wie beispielsweise komprimiert, verschlüsselt, codiert und verpackt), ehe sie übertragen wird. Somit müssen die Daten zurück in ihre ursprüngliche Form übersetzt werden, ehe sie durch die Mobilvorrichtung 18 weiter verwendet werden. Daher werden die Daten zunächst an den Nachrichten-Router 210 geliefert. Der Nachrichten-Router 210 fungiert zur Speicherung der Nachricht und zum Routing der empfangenen Nachricht an eine Übersetzungsschicht 209. In 6 weist die Übersetzungsschicht 209 die Auspack- und Füge-Komponente 212, eine Gruppe zusätzlicher Übersetzter, welche kollektiv mit 214 bezeichnet sind, und eine weitere Routing-Komponente 216 auf.
  • Der Auspack- und Fügeblock 212 fungiert zum Empfang, Auspacken und Ordnen einer übertragenen Gruppe von Paketen. Der Auspacker fügt Pakete einer beliebigen langen Nachricht wieder zusammen, welche durch den drahtlosen Träger 15 aufgespalten wurden. Die geordneten Daten werden an die Übersetzungskomponenten 214 geliefert.
  • Die Übersetzungskomponenten 214 fungieren zur Neuformatierung oder Übersetzung der Daten in eine geeignete Form zur Handhabung durch den Inhaltshandhaber 216. Beispielsweise können, wenn die Pakete, welche eine Nachricht aufweisen, ausgepackt und durch den Auspacker und Füger 212 erneut zusammengefügt wurde, die Übersetzungskomponenten 214 typischerweise diese Pakete dekomprimieren, entschlüsseln und decodieren.
  • Der Inhaltshandhaber 216 liefert die ausgepackte, zusammengefügte und übersetzte Nachricht an das geeignete registrierte Ziel (d.h. an die geeignete Anwendung oder einen anderen funktionalen Block) auf der Mobilvorrichtung 18. In der in 5 dargestellten Ausführungsform liefert der Inhaltshandhaber 216 die Informationen an die Cache-Verwaltung 208, welche sie im Cache 206 speichert.
  • Wenn der Anwender Off-Line den im Cache 206 gespeicherten Webinhalt browsen möchte, startet der Anwender ein geeignetes Anwendungsprogramm, welches durch den Kanal-Browser-Block 218 in 5 angezeigt wird. Der Kanal-Browser 218 erzeugt bevorzugt geeignete Anwenderschnittstellen auf der Anzeige 45, welche dem Anwender die Fähigkeit liefern, einen bestimmten zu betrachtenden Kanal zu wählen.
  • Der Kanal-Browser 218 ist darauf ausgelegt, mit einem ladbaren Transport 220 zu interagieren, welcher wiederum mit der Cache-Verwaltung 208 gekoppelt ist. Auf die Anfrage des Anwenders hin, die über den gewählten Kanal bereitgestellten Informationen zu sichten, fordert der ladbare Transport 220 die Cache-Verwaltung 208 auf, die entsprechenden Webinhaltsinformationen (in Form von Skriptenmustern und Datendateien) aus dem Cache 206 abzurufen. Die erwünschten Skriptenmuster 204 und Datendateien 202 werden von der Cache-Verwaltung 208 an den ladbaren Transport 220 bereitgestellt.
  • Der Skriptenübersetzer im Transport 220 ist bevorzugt ein visueller Basisskriptenübersetzer, welcher Skriptenmuster 204 übersetzt und die Datendateien 204 manipuliert, um eine erwünschte Wiedergabe des Webinhalts bereitzustellen. In der in 5 dargestellten Ausführungsform wird der Webinhalt als herkömmliche Hypertext-Markup-Language-Seite (HTML-Seite) 224 wiedergegeben. Der ladbare Transport 220 liefert dann die HTML-Seiten-Wiedergabe an den Kanal-Browser 218 für die Sichtung durch den Anwender der Mobilvorrichtung 18 auf der Anzeige 45.
  • INFORMATIONS-LOGGING
  • Ein Aspekt der vorliegenden Erfindung ermöglicht das Logging der erwünschten Informationen zur Verwendung durch den Inhaltslieferanten 12. Anders gesagt, können die Inhaltslieferanten durch Bereitstellung eines Eintrags in der CDF-Datei bestimmte Punkte markieren, welche sie nachspüren möchten (d.h. sie können bestimmte Punkte markieren, für welche sie wissen möchten, wann und für wie lange diese Punkte durch irgend einen bestimmten Anwender gesichtet wurden). Die vorliegende Erfindung realisiert diese Funktion.
  • Wenn der Anwender beispielsweise den Kanalbrowser 218 startet und Informationen von dem ladbaren Transport 220 anfordert, bestimmt der ladbare Transport 220, ob die angeforderten Informationen das entsprechende CDF-Tag einschließen, welches anzeigt, dass der Inhaltslieferant die Informationen bezüglich der Zeit und Dauer loggen möchte, für welche die Informationen gesichtet wurden. Ist dies der Fall, so loggt der ladbare Trans- Port 220 Informationen, welche die Zeit und Dauer darstellen, für welche die Informationen durch den Anwender gesichtet wurden. Diese Informationen werden im Cache 206 in einer Position gespeichert, welche dieser bestimmten Webinhaltsinformation entspricht.
  • Das nächste Mal, wenn die Mobilvorrichtung 18 mit dem Desktop-Computer 16 synchronisiert wird, wird nicht nur die Mobilvorrichtung 18 mit dem aktuellen durch den Desktop-Computer 16 empfangenen Webinhalt aktualisiert, sondern der Desktop-Computer 16 wird mit den aktuellen durch die Mobilvorrichtung 18 gehaltenen Logging-Informationen aktualisiert. Auf ähnliche Weise werden das nächste Mal, wenn der Browser auf dem Desktop-Computer 16 auf den entsprechenden Webinhalt vom Inhaltslieferanten 12 zugreift, die Logging-Informationen vom Desktop-Computer 16 zum Inhaltslieferanten 12 übertragen. In einer bevorzugten Ausführungsform werden, da der Browser auf dem Desktop-Computer 16 der Internet Explorer 4.0 ist, Logging-Informationen, welche auf den Desktop-Computer 16 synchronisiert wurden, zum Inhaltslieferanten 12 übertragen, wenn der Zeitgeber des Internet Explorer 4.0 das nächste Mal auf dem Desktop-Computer 16 aufgerufen wird.
  • DATENSTRUKTUR UND FILTERUNG
  • 7 stellt eine Ausführungsform eines Pakets von Webinhaltsdaten an, welche durch den Funkempfänger und Treiber 10 empfangen wurden. Der Funkempfänger kann bevorzugt Nachrichten in im Wesentlichen jedem beliebigen Format empfangen. Zahlreiche unterschiedliche Arten von Anfangsblock-Formaten können für den Empfang durch Funk definiert sein. 7 zeigt nur eine beispielhafte Art von Paketformat an.
  • Das Paket 230 weist bevorzugt eine Vielzahl von Abschnitten auf, wie beispielsweise den Funktransport-Anfangsblock 232, die Gruppen- und Themen-Filterungs-Bytes 234, den Routing-Anfangsblock 236 und die Daten 238. Der Funktransport-Anfangsblock 232 weist bevorzugt Adresseninformationen auf. Die Adresseninformationen stellen eine Identifikation dar, welche verwendet wird, um eine Funknachricht an den Funkempfänger 22 (oder eine beliebige andere Art von Funkkarte) zu senden. Beispielsweise weist in einem handelsüblich erhältlichen Paging-Übertragungsprotokoll die Adresseninformation im Funktransport-Anfangsblock 232 einen Capcode auf. Der Capcode bezieht sich auf eine Speicherposition auf der physikalischen Hardware-Funkkartenvorrichtung 22, welche Addressierungsinformationen speichert. Der Funktransport-Anfangsblock 232 unterstützt in einer bevorzugten Ausführungsform sechzehn unterschiedliche Adressen. Der Funkempfänger und Treiber 22 filtert und verwirft jegliche Nachrichten, welche nicht zu irgend einer der Adressen passen. Wird eine Übereinstimmung beobachtet, so hat der Funkempfänger 22 eine Nachricht erfasst, welche potentiell an ihn adressiert ist, und muss die Nachricht empfangen und weiter verarbeiten. Die Nachricht wird dann an den Nachrichten-Router 210 weitergeleitet, welcher in Verbindung mit der Übersetzungsschicht 209 bestimmt, welche Komponenten auf der Mobilvorrichtung 18 zur Verarbeitung der Nachricht nötig sind.
  • Gruppen- und Themen-Filterbytes 234 sind ebenfalls bevorzugt bereitgestelt. Eine Gruppe gemäß Bezeichnung hierin ist eine Unterklasse einer Adresse, welche in Übereinstimmung mit der vorliegenden Erfindung verwendet wird, um die Filterungskapazität einer Adresse auszuweiten. Weiter ist ein Thema eine Unterklasse einer Gruppe, welche ebenfalls bereitgestellt ist um die Filterungskapazität der Adressen- und Gruppeninformation auszuweiten.
  • Es sollte sich verstehen, dass Nachrichten, welche am Funkempfänger und Treiber 22 mit einer entsprechenden Adresse eintreffen, möglicherweise keine Gruppen- und Themen-Filterungsbytes 234 aufweisen, welche hieran im Voraus angehängt wurden. Falls diese Bytes jedoch vorhanden sind, fungiert der Funkempfänger und Treiber 22 zur Filterung der Nachricht basierend auf den Gruppen- und Themen-Filterungsbytes.
  • Der Treiber im Funkempfänger und Treiber 22 realisiert eine Logik, welche zunächst das Paket 230 überprüft, um zu bestimmen, ob irgendwelche Gruppen- und Themen-Filterungsbytes 234 im Paket 230 eingeschlossen sind. In einer bevorzugten Ausführungsform unterstützt der Treiber im Funkempfänger und Treiber 22 eine Bibliothek, welche eine Funktion AnalyzeMessage() umfasst. Die AnalyzeMessage-Funktion isoliert Dienstgruppen-Codes und andere Informationen in der eingehenden Nachricht. Falls Gruppen- und Themen-Filterungsbytes vorhanden sind, müssen die Gruppen- und Themen-Filterungsfunktionen durchgeführt werden.
  • In der bevorzugten Ausführungsform weist die Mobilvorrichtung 18 einen Speicher auf, welcher eine Gruppentabelle enthält, wie sie ausführlicher in den vorstehenden Anwendungen beschrieben ist. Kurz gesagt, enthält die Gruppentabelle Einträge von Dienstgruppen, von welchen jede mit jeder beliebigen geeigneten Adresse in Zusammenhang gebracht werden kann. Auch kann bevorzugt jede beliebige geeignete Anzahl von Dienstgruppen vorhanden sein, welche mit einer Adresse im Zusammenhang stehen. Somit werden in der bevorzugten Ausführungsform Gruppeneinträge in der Gruppentabelle durch Adressennummern sortiert, dann durch Dienstgruppen-Codes. Der Inhalt einer bevorzugten Ausführungsform der Gruppentabelle ist ausführlicher in der vorstehend angeführten Anwendung dargelegt.
  • Falls Gruppen- oder Themen-Filterungsbytes erfasst werden, durchsucht der Treiber im Funkempfänger und Treiber 22 die Gruppentabelle, um zu bestimmen, ob der im Paket 230 erfasste Dienstgruppencode in der Gruppentabelle aufgelistet ist, und ob er aktiv oder inaktiv ist. Falls der Dienstgruppencode in der Tabelle nicht gefunden wird, oder falls er gefunden wird, aber deaktiviert (oder ausgeschaltet) wurde, verwirft der Treiber 22 die Nachricht, und keine weitere Verarbeitung erfolgt mit Bezug auf diese Nachricht. Falls der Treiber 22 jedoch bestimmt, dass die Gruppen- und Themen-Filterungsbytes 234 in der Gruppentabelle eingeschlossen sind, so wird bestimmt, dass die Nachricht für diese bestimmte Mobilvorrichtung 18 gedacht war, und die weitere Verarbeitung fährt fort.
  • Da die gesamte Gruppen- und Themen-Filterung auf dem Niveau des Treibers 22 erfolgt, erscheint. sie relativ weit unten im Protokollstapel, oder der Systemarchitektur, der Mobilvorrichtung 18. Somit findet die Filterung früh in dem Prozess statt, und der für die Adresse und Nachricht erforderliche Speicherplatz ist relativ gering. Zusätzlich erlauben es, da der Treiber selbst viel von dieser Filterung vornimmt, die Gruppen- und Themen-Filterungsbytes 234 jeder beliebigen auf der Mobilvorrichtung 18 laufenden Anwendung, korrekte Filterungsinformationen nach unten an die Gruppen- und Thementabellen für eine Filterung auf dem Niveau des Treibers 22 weiterzuleiten. Dies verbessert den Energieverbrauch gegenüber früheren Konstruktionen signifikant, da die Nachrichten nicht empfangen, verarbeitet und den ganzen Weg hinauf zum Anwendungsniveau im Protokollstapel, oder der Architektur, der Mobilvorrichtung 18 weitergeleitet werden müssen, ehe sie gefiltert werden.
  • UBERTRAGUNGS- UND UBERSETZUNGS-ARCHITEKTUR
  • 8 ist ein ausführlicheres Blockdiagramm, welches die Übertragung von Datenpaketen von der drahtlosen Schubserverkomponente (WPS-Komponente) 20 an die Mobilvorrichtung 18 darstellt. Der drahtlose Schubserver 20 weist bevorzugt den Webinhalts-Cache 250, den Zeitgeber 252, die Übersetzungsschicht 254, die Verpackungsvorrichtung 256 und den Funksender 258 auf. Die Übersetzungsschicht 254 weist bevorzugt eine beliebige geeignete und erwünschte Anzahl von Übersetzern auf. Die Übersetzer werden bevorzugt verwendet, um an dem Webinhalt zu arbeiten (z.B. an den Datendateien, den Skriptendateien und den CDF-Dateien) und den Inhalt in einer erwünschten Form der Verpackungsvorrichtung 256 des Funksenders 258 zur Übertragung an die Mobilvorrichtung 18 zu liefern. In der in 8 gezeigten Ausführungsform weist die Übersetzungsschicht 254 die Komprimierungsvorrichtung 260, die Verschlüsselungsvorrichtung 262 und die Codierungsvorrichtung 264 auf.
  • 8 zeigt ebenfalls einen Abschnitt der Mobilvorrichtung 18 detaillierter. Ähnliche Elemente sind ähnlich den in 6 gezeigten bezeichnet. Jedoch stellt 8 eine Übersetzungsschicht 209 detaillierter dar. Die Übersetzungsschicht 209 weist bevorzugt eine erwünschte Anzahl und Art von Übersetzern auf, welche zur Umkehrung der in der Übersetzungsschicht 254 auf dem WPS 20 durchgeführten Übersetzung fungieren. Somit weist die in 8 gezeigte Ausführungsform die Auspackvorrichtung 212, die Decodiervorrichtung 266, die Verschlüsselungsvorrichtung 268 und die Dekomprimierungsvorrichtung 270 auf.
  • Im Betrieb greift die Zeitgebungsvorrichtung 252 periodisch auf den Webinhalts-Cache 250 zu, um Aktualisierungen oder zusätzlichen Webinhalt an die Mobilvorrichtung 18 zu liefern. Diese Informationen werden zunächst an die Übersetzungsschicht 254 geliefert. Jede Übersetzungsvorrichtung in der Übersetzungsschicht 254 führt bevorzugt die Übersetzungsoperation an den eingehenden Daten durch und stellt einen Identifikator an die Datenausgabe ab, wie beispielsweise einen Anfangsblock oder ein Tag, um dadurch die Art der durchgeführten Übersetzung anzuzeigen. Zum Beispiel wird in der bevorzugten Ausführungsform ein Abschnitt des Webi nhalts, welcher aus dem Webinhalts-Cache 250 durch die Zeitgebungsvorrichtung 252 extrahiert (und für die Übersetzungsschicht 254 durch die Zeitgebungsvorrichtung 252 vorbereitet) wurde, zunächst an die Kompressionsvorrichtung 260 geliefert. Die Kompressionsvorrichtung 260 komprimiert den dadurch empfangenen Informationsblock und stellt einen Anfangsblock von vier Byte ab, um das Kompressionsschema zu identifizieren, welches zur Komprimierung der Daten verwendet wurde. Die Kompression erfolgt bevorzugt vor der Verschlüsselung, da reiner Text typischerweise eine bessere Komprimierung liefert als verschlüsselter Text.
  • Die Verschlüsselungsvorrichtung 262 empfängt die komprimierten Daten von der Kompressionsvorrichtung 260 und verschlüsselt die Ausgabe der Kompressionsvorrichtung 260 und stellt ebenfalls einen Anfangsblock von vier Byte ab, um das Verschlüsselungsschema zu identifizieren, welches zur Verschlüsselung der Daten verwendet wurde. Die Verschlüsselungsvorrichtung 262 liefert dann verschlüsselte Daten an die Codierungsvorrichtung 264.
  • Die Codierungsvorrichtung 264 codiert die Ausgabe der Verschlüsselungsvorrichtung 262, um den Datenstrom in einen Strom umzuwandeln, welcher aus Zeichen besteht, die für die Übertragung über das gewählte drahtlose Medium geeignet sind. Dort, wo beispielsweise das drahtlose Medium ein herkömmlicher Paging-Kanal ist, codiert die Codierungsvorrichtung 264 die Daten in einen Strom, welcher lediglich aus druckbaren ASCII-Zeichen besteht, so dass er über die drahtlose Leitung übertragen werden kann. Die Codierunsvorrichtung 264 fügt ebenfalls einen Anfangsblock von vier Byte an die Daten an, um das spezielle Codierungsschema zu identifizieren, welches zur Codierung der Daten verwendet wurde.
  • Wie vorstehend ausführlicher beschrieben, spaltet die Packvorrichtung 256 die Ausgabe der Codierungsvorrichtung 264 in kleinere Pakete auf, welche für die Übertragung über die drahtlose Leitung geeignet sind. Die Packvorrichtung 256 fügt einen Anfangsblock vor das Datenpaket an, so dass die Pakete eindeutig durch den Empfänger der Information identifiziert werden können. Wenn die Daten, welche in die Übersetzungsschicht 254 eingegeben werden, beispielsweise zunächst komprimiert, dann verschlüsselt, dann codiert werden, kann die Ausgabe der Codierungsvorrichtung 264 dargestellt werden durch:
    (Codierungsschema, [CodierungsID {KompressionsID, Daten}]).
  • Somit verwendet die Packvorrichtung die vorstehenden Daten und erzeugt Pakete im Allgemeinen in der in 7 gezeigten Form, welche dargestellt wird durch:
    {Hdr, Daten}, {Hdr, Daten}...[Hdr, Daten]
  • Die Packvorrichtung 256 (welche auch als Übersetzungsvorrichtung betrachtet werden kann) liefert die Daten und Anfangsblöcke an den Funksender 258, welcher die Daten an den Funkempfänger und Treiber 22 liefert. Insbesondere bricht die Packvorrichtung 256 Eingangsdaten vom Inhaltslieferanten 12 in eine Reihe von Paketen mit einer Größe von zwischen ca. 128 bis 500 Bytes in Abhängigkeit von dem bestimmten Träger auf. Jedes Paket wird an einen Paging-Gateway (z.B. den Funksender 258), beispielsweise über das Internet, E-Mail, einen drahtlosen Träger oder über ein Modem gesendet. Pakete können in einer beliebigen Reihenfolge den Pager-Kanal hinunter gesendet werden.
  • In einer bevorzugten Ausführungsform enthält jeder Speicher oder jedes Paket 11 bis 23 Byte von Paket-Anfangsblockinformationen und N Byte an Paket-Dateninformationen, im Allgemeinen in Form des in 7 dargestellten Pakets 230. Der Funktransport-Anfangsblock in den Paket-Anfangsblockinformationen weist bevorzugt eine IP-Adresse, eine Reihenfolgenummer, eine Paketnummer und eine Reihe optionaler Anfangsblöcke (z.B. Gruppen- und Themen-Filterungsbytes 234 und den Routing-Anfangsblock 236) auf.
  • Die IP-Adresse ist die Adresse des Dienstanbieters. Die Reihenfolgenummer liefert eine bestimmte Reihenfolgenummer für einen übertragenen Paketstrom. Die IP-Adresse und die Reihenfolgenummer (in Kombination) liefern eine eindeutige Identifikation an den Paketstrom und erlauben es einem Empfänger, wie beispielsweise der Mobilvorrichtung 18, eine Vielzahl von Paketströmen zusammenzusetzen, welche in Multiplexweise eintreffen.
  • Der Funkempfänger und Treiber 22 filtert die Daten, wie vorstehend beschrieben, und liefert zu empfangende Daten an den Router 210. Der Router 210 überprüft die Anfangsblockinformationen an jedem Paket. Die Anfangsblockinformationen liefern dem Router 210 eine Anzeige darüber, welche Übersetzungsvorrichtung auf gerufen werden muss, um an den Daten zu arbeiten. In der in 8 gezeigten Ausführungsform sind die Übersetzungsvorrichtungen 212, 266, 268 und 270 einfach in umgekehrter Reihenfolge als Übersetzungsvorrichtungen 256, 260, 262 und 264 bereitgestellt. Der Router hält eine Tabelle aller verfügbaren Übersetzungsvorrichtungen mit Bezug auf die dynamisch verbundenen Bibliotheken DLL dieser Übersetzungsvorrichtungen aufrecht. Der Anfangsblock oder Tag mit vier Byte wird zur Lokalisierung der geeigneten Übersetzungsvorrichtung verwendet. Die Übersetzungsvorrichtung ist verantwortlich für die Entfernung dieses Tag und die Versendung oder Rücksendung der übersetzten Daten.
  • Die meisten der Übersetzungsvorrichtungen sind Teil einer Kette von Übersetzungsvorrichtungen, in welcher die Ausgabe der Übersetzungsvorrichtung in eine weitere Übersetzungsvorrichtung eingegeben werden kann. Dies liefert Flexibilität an den Inhaltslieferanten, da sie die Reihenfolge der Übersetzungsvorrichtungen an ihre Bedürfnisse und bestimmte Daten anpassen können. Jedoch können auch Übersetzungsvorrichtungen bereitgestellt werden, welche die Eingabe in dem Sinn konsumieren, dass sie die Ausgaben anderswo in dem System platzieren und dadurch die Übersetzungskette anhalten.
  • Der Router fährt mit der Anwendung von Übersetzungsvorrichtungen fort, bis der Artikel durch eine der Terminations-Übersetzungsvorrichtungen konsumiert wird. In einer bevorzugten Ausführungsform werden, wenn keine verbleibenden Tags oder Anfangsblöcke gefunden werden und der Artikel noch immer nicht konsumiert wird, die Daten an die E-Mail-Eingangsbox 272 weitergeleitet.
  • Somit erhält der Router 210 ein erstes Datenpaket, liefert es an die Auspackvorrichtung 212 und empfängt die ausgepackten und zusammengefügten Daten von der Auspackvorrichtung 212 zurück. Die Auspack- und Fügevorrichtung 212 speichert alle empfangenen Pakete und fügt sie zusammen. Sie kann Pakete ohne Rücksicht auf die Reihenfolge empfangen, kann eine Vielzahl von Strömen (von unterschiedlichen Inhaltslieferanten oder demselben Inhaltslie feranten) empfangen. Zusammenfassend lässt sich sagen, dass die Auspackvorrichtung 212 ein einfaches Dateisystem realisiert, in welchem eine Datei die vollständigen Daten enthält, welche gesendet wurden, ehe die Paketisierung erfolgt.
  • Der Dateiname wird aus der IP-Adresse gebildet, welche diejenige des Dienstanbieters ist, und zwar zusammen mit der Reihenfolgenummer, welche zusätzlich zur Anzeige eines Paketstrom-Reihenfolgemitglieds anzeigt, ob dieses bestimmte Paket das letzte Paket in einer übertragenen Sequenz ist. Die Pakete werden empfangen und in einer geordneten, verlinkten Liste durch die Auspack- und Fügevorrichtung 212 gespeichert.
  • Der Funkempfänger und Treiber 22 empfängt und puffert eine vollständige Seite von Informationen. Er leitet diese Seite dann an den Nachrichtenrouter 210, welcher die Seite in eine Datei schreibt. Der Router 210 ruft dann die Auspack- und Fügevorrichtung 212 an. Das Paket wird an eine Datei angehängt, deren Name aus der IP-Adresse und Reihenfolgenummern-Kombination abgeleitet ist, welche in dem bestimmten Paket enthalten ist. Falls die Datei noch nicht existiert, wird sie durch die Auspackvorrichtung 212 neu erzeugt.
  • Wenn das Paket, welches als letztes Paket markiert ist, empfangen wird, weiß die Auspackvorrichtung 212, wie viele Pakete sie zu erwarten hat. Es versteht sich, dass das letzte Paket nicht zeitlich als letztes eintreffen muss. Die Auspackvorrichtung 212 zählt die Anzahl der bereits empfangenen Pakete und speichert die Anzahl der Pakete, welche sie erwartet, in einem Zähler. Jedes Mal, wenn ein nicht doppeltes Paket angefügt wird, wird der Zähler um eins herabgesetzt. Fällt er auf null, so wurden alle Pakete empfangen. Die Auspackvorrichtung 212 durchläuft dann die Indexdatei, welche sie erzeugt hat, und welche einen Zeitstempel enthält, der die Reihenfolge der empfangenen Pakete anzeigt. Die Auspackvorrichtung erzeugt eine Datendatei in der korrekten Reihenfolge und leitet die Datendatei zur weiteren Verarbeitung weiter.
  • Sobald alle Pakete eingetroffen sind, wird die Datendatei, welche die geordnete verlinkte Liste enthält, aus dem Dateisystem in der Auspackvorrichtung 212 entfernt und wird entweder an zusätzliche Übersetzungsvorrichtungen in der Übersetzungsschicht 209 oder zurück an den Router 210 geleitet.
  • Um mit verlorenen, doppelten und falschen Paketen zurechtzukommen, wird ein Prüfummen-Fehlererfassungs-Verfahren, welches das zyklische Zufallscode-32-Verfahren (CRC-32-Verfahren) verwendet, über die gesamte Datei von Datenbytes implementiert (d.h. es schließt alle Anfangsblock-Bytes aus).
  • Zur Erfassung verlorener Pakete wird der Zeitstempel des letzten in der Indexdatei empfangenen Pakets gespeichert. Die Auspackvorrichtung 212 überprüft diesen Zeitstempel jedes Mal dann, wenn sie ein Paket für die momentane Datendatei oder für eine beliebige andere Datendatei verarbeitet. Falls der Zeitunterschied zwischen einer momentanen Zeit und der Zeit des letzten empfangenen Pakets über einer erwünschten Anzahl von Minuten (oder einem beliebigen anderen geeigneten Zeitintervall) liegt, wird angenommen, dass jegliche verbleibenden Pakete für die. Datendatei verloren sind, und die Datendatei wird gelöscht.
  • Doppelte Pakete werden durch Bezugnahme auf die Indexdatei erfasst, welche bereits einen initialisierten Eintrag für dieses Paket enthalten wird. Zwei Optionen können bei der Handhabung doppelter Pakete realisiert werden. Erstens kann das neue Paket verworfen werden, und das alte kann erhalten werden. Zweitens kann das neue Paket an die Datendatei durch Überschreibendes Indexeintrags für das erste (oder alte) Paket angehängt werden. Dies wird die Auswirkung der Verwerfung des alten Pakets haben.
  • In jedem Fall überprüft zum Abschluss des in 8 bereitgestellten Beispiels der Router 210, wenn die Pakete ausgepackt und zusammengefügt wurden, die Anfangsblöcke an den Daten, um herauszufinden, dass die Daten zunächst an die Decodiervorrich tung 266 geliefert werden müssen. Die Decodiervorrichtung 266 decodiert die Daten und liefert sie zurück an den Router 210. Der nächste Anfangsblock an den Daten wird durch den Router 210 überprüft und zeigt an, dass die Daten an die Entschlüsselungsvorrichtung 268 geliefert werden müssen. Die Entschlüsselungvorrichtung 268 entschlüsselt die Daten und sendet sie dann zum Router 210 zurück. Der Router 210 liefert die Daten dann an die Dekompressionsvorrichtung 270, und zwar basierend auf den Anfangsblockinformationen, welche bei den entschlüsselten Daten verbleiben. Die Dekompressionsvorrichtung 270 dekomprimiert die Daten und sendet sie entweder zum Router 210 zurück oder liefert sie an die Routerkomponente 216, welche das bestimmte Ziel für die Daten identifiziert. In der bevorzugten Ausführungsform ist die Routingkomponente 216 mit dem Webinhalts-Cache 208 und der E-Mail-Eingangsbox 272 gekoppelt. Natürlich können auch andere Ziele bereitgestellt sein.
  • Eine bestimmte Implementierung einer Übersetzungsvorrichtung ist zusammen mit einer ausführlicheren Beschreibung beispielhafter Komprimierungs-, Verschlüsselungs- und Codierungs-Übersetzungsvorrichtungen in den vorstehend angeführten ebenfalls anhängigen US-Patentanmeldungen bereitgestellt, sowie ebenfalls in Anhang A.
  • Somit liefert die vorliegende Erfindung durch Aufteilung des Inhalts in separate Skriptenmuster und Datendateien die Fähigkeit, Inhalt an eine Mobilvorrichtung über einen Kanal mit geringer Bitgeschwindigkeit in ökonomischer und effizienter Weise zu liefern. Kleine Segmente von Daten können anstelle vollständiger HTML-Seiten geliefert werden. Die vorliegende Erfindung stellt ebenfalls einen Mechanismus bereit, durch welchen das Logging und Filtern in effizienter Weise erzielt werden können.
  • Obgleich die vorliegende Erfindung mit Bezug auf bevorzugten Ausführungsformen beschrieben wurde, werden Fachleute erkennen, dass Änderungen in Form und Detail vorgenommen werden können, ohne vom Schutzumfang der Erfindung abzuweichen.
  • Anhang
  • Mobile Channels Skripting-Umgebung
  • Das Mobile Channels Skriptingmodell basiert auf den aktiven Serverseiten (Active Server Pages, ASP), gemäß Definition in IIS. Der ASP-Code ist in VBS verfasst. In Mobile Channels werden sowohl ASP als auch VBS herabgestuft, um den Beschränkungen von Vorrichtungen mit Windows CE gerecht zu werden. Das vereinheitlichte ASP ist auch als Taschen-ASP (pocket ASP, pASP) bekannt. Zusammen werden pASP und VBS als Mobile Channels Skriptingumgebung bezeichnet. Die hier vorgestellten Besprechungen konzentrieren sich auf die Unterschiede zwischen pASP/VBS für Mobile Channels und ASP/VBS für Active Channels.
  • Arten
  • Es existieren drei legale Datenarten für das Mobile Channels Skripting: STRING, NUMERISCH und BOOLEAN. Jedoch wird nur STRING intern unterstützt. Die beiden anderen werden aus STRING abgeleitet. String-Zeichen können mit Hilfe des doppelten Anführungszeichens (") zur Einklammerung des Ausdrucks spezifiziert werden. Numerische Zeichen können ohne Anführungszeichen spezifiziert werden. Zahlen können nur aus Integern bestehen, und ihre Werte reichen von –32.768 bis 32.767. Boolean-Ausdrücke belaufen sich auf 1 für wahr und 0 für falsch. Sie können nicht WAHR und FALSCH zugewiesen werden, wie in Visual Basic. Beispielsweise
    Datenart Wert Beschreibung
    STRING "Beispiel Stringzeichen"
    NUMERISCH Ergebnis = 3 + 4 Das Ergebnis beläuft sich auf 7. Doch Ergebnis wird als Stringwert gespeichert.
    BOOLEAN (a) 3 = 3, (b) 3 = 5 (a) beläuft sich auf 1 und (b) auf 0.
  • Datenstrukturen
  • Mobile Channels unterstützt die folgenden Datenstrukturen.
    Datenstruktur Beschreibung
    Variable Elementare Datenstruktur einfacher Datentypen wie vorstehend dargestellt. Variablennamen sind alphanumerisch und müssen mit einem Alphazeichen beginnen. Das Unterstreichungs-Zeichen kann mit Ausnahme des führenden Zeichens verwendet werden. Variablennamen sollten kurz sein, um Speicher zu sparen und können in jedem Fall nicht länger als 255 Zeichen sein.
    Feld Eine geordnete Sammlung mit numerischen Tasten. Der Index zählt von Null (0). Beispielsweise Ergebnis = a(0) + a(1). Das Verfahren Array.Count setzt die Gesamtanzahl von Elementen in dem Feld zurück.
  • Schlüsselwörter
  • Die folgenden Schlüsselwörter sind reserviert und kennen nicht als Variablennamen verwendet werden:
    If, Then, Else, ElseIf, End If
    For, Next, Do While, Loop, Exit For, Exit While
    Set, Response, Request, MobileChannels
    Now LocDate, Len, Mid, Split, Asc, Chr, StrComp, Random
  • Kommentare
  • Kommentare werden mit dem einfachen Anführungszeichen (') begonnen und können überall auf einer Zeile erscheinen. REM aus VBS wird für das Mobile Channels Skripting nicht unterstützt. Folgendes ist ein Beispiel eines Kommentars
    • ' dies ist ein beispielhafter Kommentar.
    Operatoren und Präzedenz
    Operator Art Präzedenz Beschreibung
    * Numerisch 1 Multiplikation
    / Numerisch 1 Division
    Mod Numerisch 1 Modulo-Division
    + Numerisch 2 Addition
    - Numerisch 2 Subtraktion
    & String 2 Konkatenation
    < Boolean 3 Weniger als
    <= Boolean 3 Weniger als oder gleich
    > Boolean 3 Größer als
    >= Boolean 3 Größer als oder gleich
    = Boolean 3 Gleich
    <> Boolean 6 Nicht gleich
    And Boolean 4 Logisches UND
    Or Boolean 4 Logisches ODER
    Not Boolean 5 Logisches NICHT
  • Ausdrücke werden gemäß Operatoren-Präzedenz evaluiert. Operatoren von höherer Präzedenz (wobei 1 die höchste ist) werden zuerst evlauiert. Operatoren desselben Niveaus werden von links nach rechts evaluiert. Die Präzedenz kann mit Hilfe einer Klammer übergangen werden, welche verschachtelt. sein kann. Die innerste Klammer wird zuerst evaluiert.
  • Anders als in VBS werden alle Ausdrücke innerhalb einer Aussage immer evaluiert. In dem nachstehenden Beispiel werden, falls arr.count nicht größer als null ist, arr(1) und arr(2) evaluiert, und die Referenzen zu arr(j) führen zu einem Fehler.
  • Figure 00350001
  • Falls der erste logische Ausdruck falsch ist, sind die nachfolgenden. Ausdrücke ungültig. Die korrekte Implementierung sollte wie folgt lauten.
  • Figure 00350002
  • Vermeidung von Spezialzeichen
  • Spezialzeichen, wie beispielsweise das doppelte Anführungszeichen, können innerhalb eines String-Ausdrucks "vermieden" werden, indem ihnen ein Back-Slash-Zeichen (\) vorangestellt wird. Das Back-Slash-Zeichen kann in einem String eingeschlossen sein, indem es ebenfalls vermieden wird. Beispielsweise:
    "Dies ist ein String, welcher \" doppelte Anführungszeichen\" enthält."
    "Dies ist ein String, welcher Back-Slashes wie in einem Dateipfad enthält: \\c:\\windows."
  • Aussagen
  • In der Mobile-Channels-Skriptingumgebung existieren fünf Klassen von Aussagen:
  • Zuordnung
  • Die Zuordnungs-Aussage weist folgende Form auf:
    <Variable> = <Ausdruck>
  • Konditional
  • Die If-Aussage liefert einen konditionalen Regelfluss. Der Teil End If ist erforderlich. Die Aussagen nach einem logischen Ausdruck werden nicht evaluiert, außer der logische Ausdruck wird als wahr (1) evaluiert. Die konditionale Aussage kann eine der nachstehenden Formen aufweisen:
    Figure 00360001
    Figure 00370001
  • Schleife
  • Es existieren zwei Arten von Schleifen-Aussagen: For/Next und Do/While: Die For-Schleife steuert durch die Schleife, indem sie die Variable anfänglich auf den numerischen Ausdruck1 setzt und diesen Wert um die Menge Step (Ausdruck 3) mit jedem Durchgang durch die Schleife erhöht. Wenn der optionale Step-Satz weggelassen wird, wird der Standardsatz von Step 1 aufgerufen. Die Schleife endet, wenn die Variable einen Wert erreicht, der größer ist als Ausdruck2.
  • Figure 00370002
  • Die Do While-Schleife fährt fort, bis der logische Ausdruck logExpression falsch (0) wird. Die Exit-Aussagen liefern einen Weg, eine Schleife zu beenden, ohne die normalen Beendigungs-Kriterien zu erfüllen. Wenn auf Exit getroffen wird, bricht die Schleife ab, und die Ausführung wird bei der Aussage wieder aufgenommen, welche unmittelbar auf die Schleife folgt. Exit wird gewöhnlich in Verbindung mit einer konditionalen Aussage verwendet.
  • Figure 00370003
  • Aktivserver
  • Aktivserver-Aussagen beziehen sich auf die Verfahren von pASP-Objekten wie beispielsweise Response und Request. Die Response.Write-Aussage führt ein Ausgangssignal zum HTML-Strom zurück. Beispielsweise:
    Response.write("<A Href=MCTP://MSNBC/ch2> Hier klicken, um zu Sport zu springen </A>").
  • Die Mobile Channels-Skriptingumgebung zeigt bestimmte Server-Variablen an. Die Request.ServerVariables-Aussage kann verwendet werden, um die Server-Variablen anzufordern. Sie nimmt einen Sting-Namensausdruck an und führt einen String-Wertausdruck zurück, welcher mit dem Namen im Zusammenhang steht. So erhält
    newURL=Request.ServerVariables("URL")
    die Wurzel-URL für den Kanal der Seite. Und
    platStr=Request.ServerVariables("Platform")
    führt den Platform-String als eines der folgenden zurück:
    String Plattform
    "WIN32 CE" Windows CE
    "WIN32 WINDOWS" Windows 95/Windows 98
    "WIN32 NT" Windows NT
  • Auf ähnliche Weise führt die Request.QueryString-Aussage den Wert eines bestimmten Arguments zurück, welches als Teil der URL an die Seite geschickt wurde. Falls die URL für eine Seite beispielsweise als "MCTP://msnbc/ch2 ? city=seattle" benannt wurde, weist die Aussage
    theCity = Request.QueryString("city")
    Seattle der Variable theCity zu.
  • Set
  • Die Set-Aussage weist eine Variable einem Fall eines Objekts zu. Jedoch unterstützt die Mobile Channels-Skriptingumgebung lediglich das MobileChannels.Utilities-Pseudo-Objekt. Die einzige Verwendung der Set-Aussage die Erzeugung eines MobileChannels.Utilities-Objekts und seine Zuweisung zu einer Fall-Variablen:
    Set mc variable = Server.Create("MobileChannels.Utilities")
    Zeilenumbrüche werden bei der Evaluierung einer Aussage ignoriert. Somit können Aussagen mehr als eine Zeile umfassen. Das Aussagen-Fortsetzungszeichen("_") wird empfohlen, ist jedoch nicht verpflichtend. Beispielsweise:
    MyVar = "Dies ist ein Beispiel für " &
    "eine Aussage, welche auf " &
    "mehreren Zeilen auftaucht." & MyVar
  • Funktionen
  • Die folgenden Funktionen erscheinen in der Mobile Channels-Skriptingumgebung.
  • Now
  • Führt das aktuelle Datum zurück und nimmt kein Argument an. Beispielsweise Response.Write("Heute haben wir den " & Now).
  • LocDate
  • Führt das Datum mit Hilfe der aktuellen regionalen Einstellungen zur Formatierung des Datums zurück. Beispielsweise
    Response.Write( "Date: " & LocDate )
  • Len (<string>)
  • Führt die Länge eines Strings zurück. Beispielsweise führt
    Len ("Hello?")
    6 zurück.
  • Mid(aStringExpression, startNumExpression,(length))
  • Führt einen Sub-String eines existierenden String zurück. Der resultierende Sub-String ist length Zeichen lang und beginnt bei der Start-Zeichennummer (ab eins zählend, nicht ab null) in dem ursprünglichen String-Ausdruck. Beispielsweise
    Foo = Mid("Das ist mein String", 9, 4).
    Foo wird nun auf "mein" gesetzt.
  • Split(aStringExpression, delimiterStringExpression)
  • Teilt einen String in Sub-Strings basierend auf einer bestimmten Abgrenzung auf. Das Ergebnis wird als ein Feld von Strings zurückgeführt. Beispielsweise ergibt
    Names = Split ("Bob; Fred; Joe;",";")
    die folgenden Sub-Strings:
    Names(0)="Bob"
    Names(1)="Fred"
    Names(2)="Joe"
    Names(3)=""
  • Asc (aStringExpression)
  • Wandelt einen Zeichen-String in seinen numerischen ASCII-Wert um und führt einen numerischen Ausdruck zurück. Falls aStringExpression länger als ein Zeichen ist, führt die Funktion nur den ASCII-Wert des ersten Zeichens zurück.
  • Chr (numericExpression)
  • Wandelt einen numerischen ASCII-Wert in das zugehörige Zeichen um und führt einen 1 Zeichen langen String-Ausdruck zurück. Um beispielsweise einen String zu erzeugen, welcher ein Neuzeilen-Zeichen enthält, verwendet man
    str = Chr(10)
  • StrComp (S1, S2 [, Compare])
  • Diese Funktion. vergleicht zwei Strings, S1 und S2, wobei optional der Vergleichsmodus Compare spezifiziert wird. Das Compare-Argument kann 0 oder 1 sein. Falls Compare weggelassen wird, wird ein binärer Vergleich durchgeführt.
  • Diese Funktion führt einen der folgenden Werte zurück:
    Bedingung Rückführwert
    S1 ist kleiner als S2 –1
    S1 ist gleich S2 0
    51 ist großer als S1 1
  • Raudom (range)
  • Die Funktion erzeugt eine Zufallszahl im Bereich 0 bis eins weniger als range. Beispielsweise erzeugt
    num = Random (10)
    Zufallszahlen von 0 bis 9 einschließlich.
  • Mobile Channels Scripting-Objekt
  • MobileChannels.Utilities ist ein Pseudo-Objekt in der Mobile Channels-Skriptingumgebung, welches Unterstützung für die Navigation und Handhabung von Objekten innerhalb einer CDF-Datei liefert. Das Utilities-Objekt stellt eine Reihe von Verfahren für das Mobile Channels-Scripting bereit. Diese Verfahren sind in der nachstehenden Tabelle zusammengefasst.
    Verfahren Beschreibung
    Data Liest einen Datenblock aus einem Datenpunkt
    Debug Gibt ein Debug-Ausgangssignal aus, um der Skriptenentwicklung zu helfen
    Href Führt ein Element HREF zurück
    HrefExists Führt wahr zurück, falls ein Punkt im Cache existiert
    IsSubscribed Führt einen abonnierten Zustand eines Kanals/Subkanals zurück.
    IsUnread Führt einen gelesen/nicht gelesen-Zustand eines Punktes oder Kanals/Unterkanals zurück
    LibraryCall Greift auf eine spezielle DLL-Funktion zu
    Locate Springt zu einer bestimmten ID innerhalb der CDF
    Navigate Quert eine CDF-Datei
    Tag Führt das Tag eines Elements in einer CDF-Datei zurück
    Title Führt den Titel eines Elements zurück
    Value Führt den Wert eines Elements in einer CDF-Datei zurück
  • Zur Verwendung dieser Dienste muss das Utilities-Objekt zunächst mit Hilfe der Set-Objekts wie folgt vorbereitet werden:
    Set MC = Server.Create("MobileChannels.Utilities")
    MC wird nachstehend als Abkürzung für das MobileChamiels.Utilities-Scripting-Objekt verwendet, jedoch kann das Objekt jedem beliebigen Variablennamen zugeordnet werden.
  • Navigate-Verfahren der Utilities-Objekte
  • Der MC.Navigate()-Befehl ist ein starkes, häufig verwendetes und bei weitem das wichtigste Verfahren in pASP. Er ist darauf ausgelegt, die Untersuchung der Struktur eines Mobilkanals, wie in CDF dargestellt, beim Laufen zu unterstützen. Zum Verstandnis des Verhaltens dieses Befehls ist eine kurze Erläuterung des Hintergrundes und der Terminologie hilfreich.
  • Der Grund-Operand des Navigate-Befehls ist ein Element, welches die kleinste Informationseinheit in einer CDF-Datei ist. Jedes Element weist ein Tag auf sowie optional einen Wert (value). Das MC.Tag()- und MC.Value()-Verfahren von pASP kann zur Abholung dieser Strings für jedes beliebige Element verwendet werden. Die Elemente werden in einer Baumstruktur organisiert, wie durch XML spezifiziert, wenn die CDF-Datei aufgeteilt wird. Der Navigate-Befehl erlaubt eine Bewegung zu bestimmten Elementen innerhalb des Baumes sowie eine Bewegung zwischen Elementen mit bestimmten Beziehungen. Diese Information kann sehr hilfreich für die Kanal-Skripten sein, welche CDF zur dynamischen Erzeugung der HTML-Seiten für den Kanal beim Laufen verwenden.
  • Die nachstehenden Erläuterungen beziehen sich häufig auf die Beispiel-CDF-Datei und ihren zugehörigen Baum, welche am Ende dieses Dokuments bereitgestellt sind. Der Baum zeigt die interne Vertretung der Beispiel-CDF-Datei. Jede Zeile des Baumes entspricht einem Element, und alle beginnen mit dem Tag für das Element. Die eingerückteren Elemente sind Kinder ihrer weniger eingerückten Eltern. Elemente auf demselben Einrückungsniveau sind Geschwister. In der CDF-Datei ist beispielsweise das BASE-Element ein Kind des CHANNEL-Elements auf höherem Niveau. Das erste HREF-Element ist ein Geschwister des BASE-Elements. Das INTERVALTIME-Element ist ein Kind des SCHEDULE-Elements.
  • Viele Elemente werden als mit einem Standardwert behaftet betrachtet. Diese sind in dem Baum durch einen "=[string]"-Ausdruck angezeigt, welcher auf das Tag des Elements folgt. Der Standardwert wird in folgendem Schema bestimmt. Zunächst ist, falls das betrachtete Element einen direkt damit zusammenhängenden String aufweist, der String der Standardwert. Als nächstes wird, falls ein Kind-VALUE-Wert existiert, der Wert des Kindes zum Standard. Falls kein VALUE-Element bereitgestellt ist, doch ein Kind-HREF-Element gefunden wird, wird sein Wert zum Standardwert. Falls keiner davon gefunden werden kann, ist VALUE leer. Beispielsweise ist der Wert des ersten ID-Tag ein direkter String, das TITLE-Tag weist ein explizites VALUE-Element auf, also wird dieses verwendet, und der Wert des ersten LOGO-Tag ist sein HREF. Das SCHEDULE-Tag weist keinen direkten String, VALUE- oder HREF-Kinder auf, also ist sein Wert leer.
  • Die Navigate-Funktion weist die folgende Syntax auf:
    NewElem = MCNavigate( StartElem, NavAction, [,Match] )
  • Die Funktion führt ein neues Element zurück, oder aber 0, falls der Befehl das bestimmte Element nicht finden konnte. Diese Rückführung lässt sich mit Hilfe von Standard-VBS-Vergleichen überprüfen, wie beispielsweise
    Figure 00430001
  • Der StartElem-Parameter ist das Startelement, von welchem Relativbewegungs-Befehle zu basieren sind. Falls der Absolutbewegungs-Befehl "Jump" verwendet wird, muss "" als StartElem-Parameter verwendet werden. Doch in allen anderen Fällen muss er ein gültiges Element sein, welches von einem vorherigen Navigate()-Befehl zurückgeführt wird.
  • Der NavAction-Parameter muss einer der folgenden Strings sein:
  • "Jump"
  • Die "Jump"-Aktion ist der erste Befehl, welcher zum Erhalt eines Startelements verwendet wird. Er entspricht dem MC.Locate()-Befehl (s.u.). Der StartElem-Parameter muss ein leerer String sein. Die "Jump"-Aktion navigiert direkt zu einem bestimmten Element in der CDF gemäß Identifikation durch die gelieferte ID. Beispielsweise springt die folgende Aussage
    NewElem = MC.Navigate( "", "Jump", "D1" )
    zum ersten Datenpunkt-Element in der Beispiel-CDF-Datei. NewElem wird zum ITEM-Elternelement für das ID-Element ("D1", ca. auf halber Höhe der Beispiel-CDF-Datei).
  • "First"
  • Die "First"-Aktion bewegt sich zum ersten Element auf einem bestimmten Niveau. Von dem ID-Element des ersten LOGO-Elements in der Beispiel-CDF-Datei bewegt sich eine "First"-Aktion beipsielsweise zum STYLE-Tag dieses LOGO. Praktischere Szenarien bestehen darin, diese Aktion zu verwenden, um sich zurück zum Anfang der Liste von ITEMs unter einem Subkanal zu bewegen.
    NewElem = MC.Navigate( StartElem, "First" )
  • "Out"
  • Die "Out"-Aktion bewegt sich zum Elternelement des gegenwärtigen Elements, oder zur linken Einrückung in dem Baumdiagramm. Vom TITLE-Element der Beispiel-CDF führt die "Out"-Aktion beispielsweise zur Bewegung zum Channel-Element des höchsten Niveaus.
    NewElem = MC.Navigate( StartElqem, "Out" )
  • "In"
  • Die "In"-Aktion bewegt sich zum ersten Kindelement unterhalb des aktuellen Elements. Von dem ersten USAGE-Element in der Beispiel-CDF-Datei führt die "In"-Aktion beispielsweise zu einer Bewegung zum VALUE-Element.
    NewElem = MC.Navigate( StartElem, "In" )
  • "Prev"
  • Die "Prev"-Aktion bewegt sich zu dem Element auf gleichem Niveau, welches unmittelbar vor dem aktuellen Element liegt. Falls es kein vorangehendes Element auf demselben Niveau findet, kehrt es zu 0 zurück; es rückt nicht zum Elternelement aus. Falls sie beispielsweise von dem BASE-Element in der Beispiel-CDF-Datei ausgeht, führt die "Prev"-Aktion zu einer Bewegung zum HREF-Element rechts davor. Ein erneuter Aufruf von "Prev" führt 0 zurück, da keine Geschwister mehr auf diesem Niveau existieren.
    NewElem = MC.Navigate( StartElem, "Prev" )
  • "Next"
  • Die "Next"-Aktion bewegt sich zum nächsten Element auf demselben Niveau. Wie bei der "Prev"-Aktion führt sie Null zurück, falls sie kein derartiges Geschwisterelement findet. Von dem ersten LOGO-Tag in der Beispiel-CDF-Datei aus führt die "Next"-Aktion beispielsweise zu einer Bewegung zum zweiten LOGO-Element.
    NewElem = MC.Navigate( StartElem, "Next" )
  • "Match"
  • Die "Match"-Aktion versucht ein Geschwisterelement mit einem Tag zu finden, welches mit dem spezifizierten Match-String übereinstimmt. Sie überquert so viele Geschwister wie nötig, bis sie entweder eine Übereinstimmung findet oder keine weiteren Geschwister finden kann. Falls die "Match"-Aktion von einem übereinstimmenden Element aus startet, führt sie einfach das aktuelle Element zurück. Um über das aktuelle Element hinaus übereinzustimmen, muss die "Match"-Aktion auf eine "Next"-Aktion. folgen.
    NewElem = MC.Navigate( StartElem, "Match", "TagToMatch" )
  • "InMatch"
  • Die "InMatch"-Aktion entspricht dem vorstehenden "Match", mit der Ausnahme, dass sie ihre Suche beim ersten Kind des aktuellen Elements beginnt. Dies kann nützlich für die Suche nach bestimmten Sub-Tags sein, welche das einschließende Element modifizieren. So suchen beispielsweise die folgenden Aussagen
    Figure 00450001
    nach dem USAGE-Tag für ein bestimmtes Element.
  • Die einzigen Aktionen, welche den optionalen dritten Parameter verwenden, sind "Match" und "InMatch".
  • Andere Verfahren des Utilities Object
  • Tag
  • Dieses Verfahren führt den Tag-Namen eines Elements zurück: tagString=MC.Tag(elementID)
  • Value
  • Dieses Verfahren führt den Wert eines Elements zurück: valString=MC.Value(elementID)
  • Data
  • Dieses Verfahren erhält Daten aus einer Mobile Channels-Datendatei und führt ein Feld von Namen-Wert-Paarungen basierend auf der aktuellen Position und der spezifizierten Blocknummer zurück.
  • Die Namen sind die Feldnamen wie in einer ITEMFORMAT-Aussage spezifiziert, und die Werte sind die Datenelemente (Zeilen) wie aus der Datendatei abgeholt. In dem nachfolgenden Beispiel ist dataItems ein Feld zum Halten der Datenelemente:
    DataItems=MC.Data(elementID, blockNum)
    wobei elementID die aktuelle Position innerhalb der CDF-Datei ist, beispielsweise das ID-Element für die MCD-Datei, und block-Num die Blocknummer innerhalb der Datei ist. Blöcke beginnen mit Null. So ist der erste Wiederholungsblock, falls vorhanden, immer Block Nummer eins (selbst wenn kein Anfangsblock existiert). Das resultierende Feld, dataItems, enthält ein Element für jeden Punkt (Zeile) innerhalb des Blocks. Die Punkte in einem Block zählen ab Null.
  • Jedes Datenelement ist tatsächlich ein Objekt, welches das Tag-, Type- und Value-Verfahren zur Ausstellung seiner eigenen Eigenschaften unterstützt.
  • Tag
  • dataItems(index).Tag führt den Feldnamen für die angegebene Feldposition zurück, wie im <ITBMFORMAT>-Element erklärt.
  • Value
  • dataItems (index).Value führt den Wert des Feldes für die angegebene Feldposition zurück.
  • Type
  • dataItems (index).Type führt den Typ gemäß Spezifikation in der <ITEMFORMAT>-Aussage zurück. Falls kein Typ aufgelistet ist oder falls das <ITBMFORMAT>-Tag fehlt, führt das Type-Verfahren "HTML" zurück. Andere Typen sind unter anderem "TEXT", "IMG" und "HREF".
    Typ Beschreibung
    HTML Das Zeilenelement ist von HTML-formatiertem Inhalt. Dies ist der Standard-Typ.
    HREF Die Zeile ist eine URL, (entweder http:// oder mctp://)
    IMG Die Zeile enthält die ID eines Bildelements in der CDF-Datei
    TEXT ebenso wie HTML
  • Locate
  • Die Funktion weist folgende Form auf:
    newElem = MC.Locate("ID")
    und ist eine Abkürzung für die "Jump"-Aktion des Navigate-Verfahrens:
    newElem = MC.Navigate( "", "Jump", "ID" )
  • LibraryCall
  • Diese Funktion erlaubt den Zugriff eines Skripts auf eine Custom-DLL zur Durchführung von Funktionen, welche durch Standard-Skripting nicht verfügbar sind. Das Verfahren weist die folgende Form auf:
    Result = MC.LibraryCall( LibName, FuncName [,param]* )
  • Zunächst prüft das Verfahren die Sicherheit, um zu garantieren, dass die DLL korrekt für Zugriff über pASP-Skripting registriert wurde. Eine zugängliche DLL muss einen Registrierungseintrag in \HKLM\Software\Microsoft\Mobile Channels\Components aufweisen, welcher mit dem Namen der DLL übereinstimmt.
  • Dann lädt das LibraryCall-Verfahren dynamisch die spezifizierte DLL durch Aufrufen der GetProcAddress-Funktion zur Suche nach der spezifizierten Funktion. Jegliche zusätzliche Parameter werden dann vor der Weiterleitung an die DLL-Funktion beseitigt. Bis zu 8 optionale Parameter können weitergeleitet werden.
  • Die DLL-Funktion muss einen LPWSTR-Wert zurückführen. Falls der Rückführwert NULL ist, kehrt LibraryCall zu null (0) zurück. Andernfalls führt sie den String selbst als Standard-pVBS-Stringwert zurück.
  • Debug (Mesg)
  • Das Debug-Verfahren erlaubt das Ausschreiben eines Debug-String während der Ausführung des Skripts. Dies kann während der Entwicklung zur Unterstützung der Untersuchung des Programmflusses nützlich sein. Die Debug-Nachrichten erscheinen im Konsolenfenster jegliches angehängten Debuggers, ähnlich dem OutputDebug-String API.
  • Die Funktion führt keinerlei Wert zurück.
  • HrefExists (Href)
  • Dieses Verfahren prüft zur Bestimmung, ob die spezifizierte URL im Cache gefunden werden kann. Dies erlaubt einem Skript die behutsame Handhabung fehlender Bilder, Datenelmente oder anderer Komponenten, welche durch das Skript benötigt werden. Die URL muss eine voll qualifizierte http-Art URL sein.
  • Dieses Verfahren führt 1 zurück, falls im Cache gefunden, sonst 0.
  • Href(Elem)
  • Dieses Verfahren führt die volle URL für das spezifizierte Element zurück, falls es in der CDF-Datei spezifiziert ist. Es führt 0 zurück, falls keine URL gefunden werden kann.
  • IsSubscribed(ChanElem)
  • Dies prüft, um zu sehen ob der spezifizierte Kanal oder Subkanal momentan durch den Anwender abonniert ist. Es führt 1 zurück, falls der Kanal abonniert ist, oder 0, falls er nicht gefunden wird oder nicht abonniert ist.
  • N.B.: dies funktioniert nicht mit Elementen, nur mit Kanälen. Weiterhin führt es stets 1 zurück, wenn es auf dem Desktop (in IE4) läuft.
  • Title
  • Dieses Verfahren weist die folgende Form auf:
    titleString = MC.Title( ElemString )
    und versucht, den Titel eines bestimmten Elements wie folgt zu entziffern:
    Falls ein ausdrückliches TITLE-Tag für dieses Element vorliegt, wird dessen Wert zurückgeführt;
    Falls es ein .mcd-Datenelement mit einem ITEMFORMAT ist, welches ein TITLE-Feld spezifiziert, wird das Datenelement geöffnet und der Titel daraus extrahiert;
    Falls ein ID-Element bereitgestellt ist, wird sein Wert zurückgeführt;
    In jedem anderen Fall wird NULL zurückgeführt.
  • Es sollte sich verstehen, dass dieses Verfahren das Datenelement beim Abholen des Titels nicht als "Read" oder "gelesen" markiert. Dies unterscheidet sich von der Verwendung von Navigate zum Erhalt des Titels. Letzteres Verfahren markiert das Element als "Read", selbst dann, wenn der Anwender es nicht tatsächlich gesehen hat.
  • IsUnread
  • Dieses Verfahren führt ein Boolean zurück, welches anzeigt, ob das zugehörige Element oder der zugehörige Kanal gelesen wurde.
    newContent = MC.IsUnread( Elem )
  • Die Funktion führt einen nicht-null-Wert zurück, falls sie direkt an einem ungelesenen Element aufgerufen wird. Wenn sie an einem Subkanal aufgerufen wird, führt sie nicht-null zurück, falls irgendwelche Elemente oder anderen Subkanäle innerhalb des Subkanals nicht gelesen wurden.
  • SetUnread
  • Dieses Verfahren setzt den gelesen/ungelesen-Status für ein Element und führt keinen Wert zurück. Und es weist das folgende Format auf:
    SetUnread(Elem [,Flag])
  • Der Elem-Parameter sollte ein gültiges Element aus einem vorhergehenden Navigate()- oder Locate()-Ruf sein. Der optionale Flag-Parameter ist ein Boolean, welcher zur Markierung des Status von Elem verwendet wird: 0 für "unread" oder "ungelesen", und 1 für "read" oder "gelesen". Der Standardwert von Flag ist "unread".
    N.B. Aufgrund einer Beschränkung der Realisierung der Version 1.0 von Mobile Channels werden Bildelemente nicht automatisch als "gelesen" markiert (wie es bei MDC-Elementen der Fall ist). Dies führt dazu, dass das Bild weiterhin als "ungelesen" markiert ist, obgleich es gelesen wurde. Weiter zeigen sich alle Eltern-Subkanäle ebenfalls als "ungelesen", solange irgendwelche Bilder darin ungelesen sind. Um in dieser Situation Abhilfe zu schaffen, sollte der Skriptenautor manuell jedes Bild jedes Mal dann, wenn es angezeigt wird, als "ungelesen" markieren. Die SetUnread()-Anwendung ist die richtige Art und Weise, um dies zu erzielen.
  • Channel Browser und Active Desktop-HTML-Extensionen
  • Eine Reihe von HTML-Extensionen stellen eine zusätzliche Funktionalität zum Schreiben fortgeschrittenerer Skripten für Active Desktop und zur Regelung von Seitenaktualisierungen in Channel Browser bereit.
  • Anwendungs-Links
  • Windows CE Active Desktop unterstützt eine spezielle HTML-Href zum Start einer Anwendung von einem Hyperlink aus. Das Format ist folgendes:
    <A HREF="mcexe://[appname]">Launch Text</A>
    appname ist der Name der Anwendung, welche gestartet werden soll, wenn der Link angeklickt wird.
  • Die Anwendung muss registriert worden sein, indem ein Wert desselben Namens wie der .exe in das Register bei \HKLM\Software\Microsoft\Mobile Channels\Components platziert wurde.
  • MBTA-Tags
  • Channel Browser und Active Desktop erkennen die nachfolgenden speziellen META-Tags. Die Einbettung dieser META-Tags in den Anfangsblock einer Seite, entweder direkt oder über Skripting, kann bewirken, dass die Seite automatisch gehandhabt oder auf eine bestimmte Weise aktualisiert wird. Es sollte sich verstehen, dass diese META-Tags (mit der Ausnahme von Refresh) durch IE4 ignoriert werden.
  • Die META-Tags sind in der nachfolgenden Tabelle zusammengefasst.
    Http_Equiv Beschreibung Unterstützung
    Notify Abholung von Cache- oder Datenbank-Aktualisierung Aktive Desktop und Channel Browser
    Refresh Neuladen nach Zeitintervall Active Desktop
    LaunchApp Ausführen der Anwendung für Desktop-Komponente Active Desktop
    Autosize Regelung Bildskalierung Channel Browser
  • Nachfolgend einige detaillierte Beschreibungen jedes Tag.
  • Notify
  • Dieses META-Tag ermöglicht die automatische Aktualisierung einer Seite, wenn eine Aktualisierung auf eine bestimmte Datenbank exisitert, oder dann, wenn ein bestimmtes Element im Cache aktualisiert wird. Dies kann zur automatischen Regeneration einer Seite verwendet werden, wenn eine neue Version davon (oder von einer ihrer Komponenten) über Sync oder andere Mechanismen hereinkommt. Die beiden Formen dieses META-Tag sind:
    Figure 00510001
  • DBname ist der Name der Datenbank, die nach Aktualisierungen überwacht werden soll.
  • WatchUrl ist die URL eines Elements, welches beobachtet werden soll, ob es Cache-Aktualisierungen aufweist.
  • RefreshUrl ist die URL, welche geladen werden soll, falls eine Aktualisierung detektiert wird.
  • Refresh
  • Dieses META-Tag veranlasst das automatische Neuladen einer Seite nach einem bestimmten Zeitintervall. Die Form ist folgende:
    <META HTTP-EQUIV="Refresh" CONTENT="[secs];URL=[RefreshUrl]">
    secs setzt die Anzahl von Sekunden, bis die Seite neu geladen wird.
  • RefreshUrl ist die URL, welche nach dem bestimmten Zeitintervall geladen werden soll.
  • LaunchApp
  • Dieses META-Tag ermöglicht den Start einer Anwendung durch Klicken auf den Anfangsblock einer Active Desktop-Komponente auf der Vorrichtung. Die Form ist folgende:
    <META HTTP-EQUIV="LaunchApp" CONTENT=[appname][?params]">
    appname ist der Name der zu startenden Ausführung.
    params ist eine optionale, durch Kommas getrennte Liste von params, welche nach der Aufrufung an die Anwendung weitergeleitet werden sollen.
  • Die Anwendung muss registriert worden sein, indem ein Wert desselben Namens wie die .exe in das Register in \HRLM\Software\Microsoft\Mobile Channels\Components platziert wurde.
  • Autosize
  • Dieses META-Tag erlaubt die Sperrung des Standard-Bildskalierungs-Verhaltens für eine bestimmte Seite. Die HTML-Regelung versucht standardmäßig, Bilder zur Anzeige auf dem Bildschirm mit kleinerem Formfaktor zu skalieren. Falls dieses META jedoch im Anfangsblock der Seite spezifiziert ist, werden die Bilder in voller Größe angezeigt, wodurch Scroll-Leisten erscheinen, falls dies nötig ist. Die Form ist folgende:
    <META HTTP-EQUIV="Autosize" CONTENT="Off">
  • Es sollte sich verstehen, dass, da der Standardwert immer "Ein" ist, keine Notwendigkeit für einen anderen Wert im CONTENT-Feld besteht. Parse-Baum der Beispiel-CDF-Datei
    Figure 00530001
    Beispiel einer CDF-Datei
    Figure 00540001

Claims (30)

  1. System zur Bereitstellung eines Informationsinhalts von einem Inhaltsanbieter (12) an eine Mobilvorrichtung (18), welches Folgendes umfasst: eine Anbieterkomponente, die Folgendes aufweist: einen ersten Speicher, welcher den Inhalt als eine Datendatei und eine dazugehörige separate Skriptdatei speichert, wobei die Datendatei Daten enthält, die den wiederzugebenden Inhalt angeben, und die Skriptdatei ein Skript enthält, das ein bestimmes Erscheinungsbild angibt, das die Daten bei ihrer Wiedergabe annehmen sollen, wobei die Skriptdatei und die Datendatei unabhängig voneinander übertragen werden können; und Mittel zur Implementierung einer ersten Übersetzerschicht (254), die mit dem ersten Speicher gekoppelt sind und zum Abrufen der Datendatei und der Skriptdatei und zum Übersetzen der Daten und des Skripts von einer nicht übersetzten Form in eine übersetzte Form konfiguriert sind, wobei die erste Übersetzerschicht (254) zur Bereitstellung von Tag-Informationen, die die auf das Skript und die Daten angewendeten Übersetzungsvorgänge angeben, und zur Bereitstellung der Tag-Informationen zusammen mit dem Skript und den Daten in der übersetzten Form konfiguriert ist; einen Sender (258), der mit dem ersten Datenspeicher koppelbar und zur Übertragung des Inhalts an die Mobilvorrichtung (18) konfiguriert ist; und eine Mobilvorrichtungs (18) komponente, welche Folgendes aufweist: einen Empfänger (22), der zum Empfang des Inhalts von dem Sender konfiguriert ist; Mittel zur Implementierung einer zweiten Übersetzerschicht (209), die mit dem Empfänger (22) gekoppelt sind und zum Übersetzen der Daten und des Skripts von der übersetzten Form in die nicht übersetzte Form basierend auf den Tag-Informationen konfiguriert sind; einen zweiten Speicher; einen Router (210), der mit dem Empfänger (22) und dem zweiten Speicher gekoppelt ist und zur Bereitstellung der Skriptdatei und der Datendatei an den zweiten Speicher konfiguriert ist; und einen Transport, der mit dem zweiten Speicher gekoppelt ist und zum selektiven Abrufen der Datendatei und zum Ausführen des Skripts zur Wiedergabe der Daten gemäß dem bestimmten Erscheinungsbild konfiguriert ist.
  2. System nach Anspruch 1, dadurch gekennzeichnet, dass die erste Übersetzerschicht (254) einen Komprimierer (260) aufweist, der zum Komprimieren der Daten und des Skripts von einer unkomprimierten Form in eine komprimierte Form konfiguriert. ist, und dass die zweite Übersetzerschicht (209) einen Dekomprimierer (270) aufweist, der mit dem Empfänger (22) gekoppelt ist und zum Dekomprimieren der Daten und des Skripts von der komprimierten Form in die dekomprimierte Form konfiguriert ist.
  3. System nach Anspruch 1, dadurch gekennzeichnet, dass die erste Übersetzerschicht (254) einen Verschlüsseler (262) aufweist, der zum Verschlüsseln des Skripts und der Daten konfiguriert ist, und dass die zweite Übersetzerschicht (209) einen Entschlüsseler (268) aufweist, der zum Entschlüsseln der Daten und des Skripts konfiguriert ist.
  4. System nach Anspruch 1, dadurch gekennzeichnet, dass die erste Übersetzerschicht (254) einen Codierer (264) aufweist, der zum Codieren des Skripts und der Daten konfiguriert ist, und dass die zweite Übersetzerschicht (209) einen Decodierer (266) aufweist, der zum Decodieren des Skripts und der Daten konfiguriert ist.
  5. System nach Anspruch 1, dadurch gekennzeichnet, dass die erste Übersetzerschicht (254) einen Paketierer (256) aufweist, der zum Aufteilen des Skripts und der Daten in Teile und zum Umwandeln der Teile in Pakete, die zur Übertragung geeignet sind, konfiguriert ist, und dass die zweite Übersetzerschicht (209) einen Depaketierer (212) aufweist, der zum Rückwandeln und Anordnen der Pakete konfiguriert ist.
  6. System nach Anspruch 1, dadurch gekennzeichnet, dass der Sender (258) Folgendes umfasst: einen drahtlosen Sender zur Übertragung des Inhalts über eine drahtlose Übertragungsleitung, und wobei der Empfänger (22) einen drahtlosen Empfänger (37) aufweist, der zum Empfang des Inhalts über die drahtlose Übertragungsleitung konfiguriert ist.
  7. System nach Anspruch 1, welches des Weiteren umfasst: einen Desktopcomputer (16), der selektiv an die Anbieterkomponente koppelbar ist und der eine Abrufkomponente, die zum Abrufen der Datendatei und der Skriptdatei konfiguriert ist, sowie eine Synchronisationskomponente (26), die so konfiguriert ist, dass sie selektiv an die Mobilvorrichtung koppelbar ist, aufweist.
  8. System nach Anspruch 7, dadurch gekennzeichnet, dass der Empfänger (22) Folgendes umfasst: eine Synchronisationskomponente (28) auf der Mobilvorrichtung (18), die mit der Synchronisationskomponente (26) auf dem Desktopcomputer (16) koppelbar ist, wobei die Synchronisationskomponente (26) auf dem Desktopcomputer (16) und die Synchronisationskomponente (28) auf der Mobilvorrichtung (18) zum selektiven Synchronisieren der Skriptdatei und der Datendatei mit der Mobilvorrichtung (18) konfiguriert sind.
  9. System nach Anspruch 8, dadurch gekennzeichnet, dass der erste Speicher eine Definitionsdatei enthält, die Eigenschaften des Informationsinhalts einschließlich einer Protokolleigenschaft beschreibt, und dass der Transport Wiedergabeinformati onen, die die Wiedergabe des Informationsinhalts auf der Mobilvorrichtung (18) angeben, protokolliert.
  10. System nach Anspruch 9, dadurch gekennzeichnet, dass die Synchronisationskomponente (28) auf der Mobilvorrichtung (18) zum Synchronisieren der Wiedergabeinformationen mit dem Desktopcomputer (16) konfiguriert ist, und dass die Abrufkomponente zur Bereitstellung der Wiedergabeinformationen an die Anbieterkomponente konfiguriert ist.
  11. System nach Anspruch 10, dadurch gekennzeichnet, dass die Wiedergabeinformationen eine Wiedergabezählung, die die Anzahl der Male angibt, die der Informationsinhalt auf der Mobilvorrichtung (18) wiedergegeben wird, und eine Wiedergabedauer, die die Zeitdauer angibt, die der Informationsinhalt auf der Mobilvorrichtung (18) wiedergegeben wird, umfasst.
  12. System nach Anspruch 7, dadurch gekennzeichnet, dass die Anbieterkomponente des Weiteren Folgendes aufweist: einen drahtlosen Sender zur Übertragung des Inhalts über eine drahtlose Übertragungsleitung, und wobei der Empfänger (22) des Weiteren einen drahtlosen Empfänger (37) aufweist, der zum Empfang des Inhalts über die drahtlose Übertragungsleitung konfiguriert ist.
  13. System nach Anspruch 1, dadurch gekennzeichnet, dass der Informationsinhalt Informationen aufweist, die unter Verwendung einer prozessorunabhängigen Sprache wiedergegeben werden.
  14. System nach Anspruch 13, dadurch gekennzeichnet, dass der Informationsinhalt Informationen aufweist, die unter Verwendung von HTML bzw. hyper text markup language wiedergegeben werden.
  15. System nach Anspruch 1, dadurch gekennzeichnet, dass die erste Übersetzerschicht (254) zur Bereitstellung des Skripts und der Daten in der übersetzten Form mit einer Vielzahl von separaten Filtersegmenten ausgelegt ist, wobei der Empfänger (22) auf der Mobilvorrichtung (18) zum selektiven Empfang und Verwerfen des Skripts und der Daten basierend auf einem ersten aus einer Vielzahl von Filtersegmenten ausgelegt ist, und dass die zweite Übersetzungsschicht (209) zum selektiven Empfang und Verwerfen des Skripts und der Daten basierend auf einem zweiten aus einer Vielzahl von Filtersegmenten ausgelegt ist.
  16. System nach Anspruch 15, dadurch gekennzeichnet, dass der Informationsinhalt Gruppeninformationen und Themeninformationen auf einem abonnierbaren Kanal aufweist, wobei das zweite aus der Vielzahl von Filtersegmenten einen den Gruppeninformationen entsprechenden ersten Filterabschnitt und einen den Themeninformationen entsprechenden zweiten Filterabschnitt aufweist, und dass die zweite Übersetzerschicht derart ausgelegt ist, dass sie basierend auf den Gruppen- und Themenfilterabschnitten unabhängig voneinander filtert.
  17. Computerlesbarer Datenträger mit Anweisungen, die von einer Mobilvorrichtung (18) gelesen werden können, die bei ihrer Implementierung die Mobilvorrichtung (18) veranlassen, Informationen durch Ausführung von Schritten zu verarbeiten, wobei die Schritte Folgendes aufweisen: periodischer Empfang einer Datendatei, einer dazugehörigen Skriptdatei sowie von Tag-Informationen, wobei die Datendatei und die dazugehörige Skriptdatei in einer übersetzten Form empfangen werden, wobei die Datendatei Daten enthält, die Informationen angeben, und die Skriptdatei Skriptinformationen enthält, die ein bestimmtes Erscheinungsbild angeben, das die Informationen bei ihrer Wiedergabe annehmen sollen, wobei die Datendatei und dazugehörige Skriptdatei von der Mobilvorrichtung (18) unabhängig empfangen werden können; Konvertierung der Daten- und Skriptdatei in eine nicht übersetzte Form basierend auf den Tag-Informationen; Speichern der Skriptdatei und der Datendatei; und Abrufen der Daten von der Datendatei und Ausführen des Skripts in der dazugehörigen Skriptdatei zur Wiedergabe der Daten.
  18. Computerlesbarer Datenträger nach Anspruch 17, welcher Anweisungen enthält, die von einer Mobilvorrichtung (18) gelesen werden können, die bei ihrer Implementierung die Mobilvorrichtung (18) veranlassen, Informationen durch Ausführung von Schritten zu verarbeiten, wobei die Schritte Folgendes aufweisen: periodischer Empfang einer aktualisierten Datendatei einschließlich aktualisierter Daten; und Ausführen des Skripts in der dazugehörigen Skriptdatei, die schon auf der Mobilvorrichtung (18) gespeichert ist, zur Wiedergabe der aktualisierten Daten.
  19. Computerlesbarer Datenträger nach Anspruch 18, dadurch gekennzeichnet, dass der Schritt der Ausführung des Skripts in der dazugehörigen Skriptdatei, die schon auf der Mobilvorrichtung (18) gespeichert ist, ansprechend auf den Empfang der aktualisierten Daten durchgeführt wird.
  20. Computerlesbarer Datenträger nach Anspruch 19, dadurch gekennzeichnet, dass die Ausführung des Skripts Folgendes umfasst: Wiedergabe der Daten in einer prozessorunabhängigen Form.
  21. Computerlesbarer Datenträger nach Anspruch 20, dadurch gekennzeichnet, dass die Ausführung des Skripts Folgendes umfasst: Wiedergabe der Daten in HTML-Form.
  22. Computerlesbarer Datenträger nach Anspruch 17, welcher des Weiteren von einer Mobilvorrichtung (18) lesbare Anweisungen aufweist, die bei ihrer Implementierung die Mobilvorrichtung (18) veranlassen, die Informationen durch Ausführung folgender Schritte zu verarbeiten: periodischer Empfang einer aktualisierten Skriptdatei einschließlich aktualiertem Skript; und Ausführung des aktualisierten Skripts auf Daten in der dazugehörigen Datendatei, die schon auf der Mobilvorrichtung (18) gespeichert ist, zur Wiedergabe der Daten gemäß dem aktualisierten Skript.
  23. Computerlesbarer Datenträger nach Anspruch 17, welcher des Weiteren von einer Mobilvorrichtung (18) lesbare Anweisungen aufweist, die bei ihrer Implementierung die Mobilvorrichtung (18) veranlassen, die Informationen durch Ausführung folgender Schritte zu verarbeiten: periodischer Empfang zusätzlicher Skriptdateien einschließlich zusätzlichem Skript; und periodischer Empfang zusätzlicher, zu den zusätzlichen Skripdateien gehörenden, Datendateien einschließlich zusätzlicher Daten.
  24. Computerlesbarer Datenträger nach Anspruch 23, welcher des Weiteren von einer Mobilstation (18) lesbare Anweisungen aufweist, die bei ihrer Implementierung die Mobilvorrichtung (18) veranlassen, die Informationen durch Ausführung folgender Schritte zu verarbeiten: Ausführung des zusätzlichen Skripts in den zusätzlichen Skriptdateien auf Daten in den dazugehörigen zusätzlichen Datendateien zur Wiedergabe der zusätzlichen Daten gemäß dem zusätzlichen Skript.
  25. Computerlesbarer Datenträger nach Anspruch 17, welcher des Weiteren von einer Mobilstation (18) lesbare Anweisungen aufweist, die bei ihrer Implementierung die Mobilvorrichtung (18) veranlassen, die Informationen durch Ausführung folgender Schritte zu verarbeiten: Protokollieren der Wiedergabedaten basierend auf der Wiedergabe der Informationen.
  26. Computerlesbarer Datenträger nach Anspruch 25, welcher des Weiteren von einer Mobilstation (18) lesbare Anweisungen aufweist, die bei ihrer Implementierung die Mobilvorrichtung (18) veranlassen, die Informationen durch Ausführung folgender Schritte zu verarbeiten: Synchronisierung der Wiedergabedaten mit einem Desktopcomputer.
  27. Computerlesbarer Datenträger nach Anspruch 17, welcher des Weiteren von einer Mobilstation (18) lesbare Anweisungen aufweist, die bei ihrer Implementierung die Mobilvorrichtung (18) veranlassen, die Informationen durch Ausführung folgender Schritte zu verarbeiten: Empfang der Skriptdatei und der Datendatei mit einer Vielzahl von separaten Filtersegmenten; und selektiver Empfang und selektives Verwerfen des Skripts und der Daten basierend auf der Vielzahl von Filtersegmenten.
  28. Computerlesbarer Datenträger von Anspruch 27, dadurch gekennzeichnet, dass der Informationsinhalt Gruppeninformationen und Themeninformationen auf einem abonnierbaren Kanal und des Weiteren von einer Mobilstation (18) lesbare Anweisungen aufweist, die bei ihrer Implementierung die Mobilvorrichtung (18) veranlassen, die Informationen durch Ausführung folgender Schritte zu verarbeiten: selektiver Empfang und selektives Verwerfen des Skripts und der Daten basierend auf einem den Gruppeninformationen entsprechenden ersten Filterabschnitt und einem den Themeninformationen entsprechenden zweiten Filterabschnitt, wobei das Filtern auf den Gruppen- und Themenfilterabschnitten unabhängig voneinander basiert.
  29. Mobilvorrichtung (18), die Folgendes aufweist: einen Empfänger (22), der zum periodischen Empfang einer Datendatei, einer dazugehörigen Skriptdatei sowie von Tag-Informationen konfiguriert ist, wobei die Datendatei und die dazugehörige Skriptdatei in einer übersetzten Form empfangen werden, wobei die Datendatei Daten enthält, die wiederzugebende Informationen angeben, und die Skriptdatei Skriptinformationen enthält, die ein bestimmtes Erscheinungsbild angeben, das die Daten bei der Wiedergabe annehmen sollen, wobei die Datendatei und die dazugehörige Skriptdatei von der Mobilvorrichtung (18) unabhängig empfangen werden können; einen Übersetzer, der zur Übersetzung der Daten und des dazugehörigen Skripts von der übersetzten Form in eine nicht übersetzte Form basierend auf den Tag-Informationen konfiguriert ist; einen Speicher (206) zum Speichern der Skriptdatei und der Datendatei; und einen Router (210), der mit dem Empfänger (22) und dem Speicher (206) gekoppelt ist und zur Bereitstellung der Skriptdatei und der Datendatei an den Speicher (206) konfiguriert ist; und einen Transport, der mit dem Speicher (206) gekoppelt ist und zum selektiven Abrufen der Datendatei und zum Ausführen des Skripts zur Wiedergabe der Daten gemäß dem bestimmten Erscheinungsbild konfiguriert ist.
  30. Verfahren zur Wiedergabe von Informationen auf einer Mobilvorrichtung (18), welches Folgendes umfasst: periodischer Empfang einer übersetzten Datendatei, einer dazugehörigen übersetzten Skriptdatei sowie von Tag-Informationen, wobei die Tag-Informationen die Übersetzungsvorgänge angeben, die zur Übersetzung der Datendatei und der dazugehörigen Skriptdatei verwendet wurden, wobei die Datendatei Daten enthält, die wiederzugebende Informationen angeben und die Skriptdatei Skriptinformationen enthält, die ein bestimmtes Erscheinungsbild angeben, das die Daten bei der Wiedergabe annehmen sollen, wobei die Datendatei und die dazugehörige Skriptdatei von der Mobilvorrichtung (18) unabhängig empfangen werden können; Konvertierung der Daten und des Skripts in eine nicht übersetzte Form basierend auf den Tag-Informationen; Speichern der Skriptdatei und der Datendatei; und Abrufen der Daten von der Datendatei und Ausführen des Skripts in der dazugehörigen Skriptdatei zur Wiedergabe der Daten.
DE69935848T 1998-01-07 1999-01-07 System zur lieferung von daten über einen übertragungskanal mit niedrigen bitraten Expired - Lifetime DE69935848T2 (de)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US7072098P 1998-01-07 1998-01-07
US70720P 1998-01-07
US7512398P 1998-02-13 1998-02-13
US75123P 1998-02-13
US09/107,666 US6311058B1 (en) 1998-06-30 1998-06-30 System for delivering data content over a low bit rate transmission channel
US107666 1998-06-30
PCT/US1999/000336 WO1999035802A2 (en) 1998-01-07 1999-01-07 System for delivering data content over a low bit rate transmission channel

Publications (2)

Publication Number Publication Date
DE69935848D1 DE69935848D1 (de) 2007-05-31
DE69935848T2 true DE69935848T2 (de) 2008-01-10

Family

ID=27371759

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69935848T Expired - Lifetime DE69935848T2 (de) 1998-01-07 1999-01-07 System zur lieferung von daten über einen übertragungskanal mit niedrigen bitraten

Country Status (5)

Country Link
EP (1) EP1051823B1 (de)
JP (1) JP4404480B2 (de)
CA (1) CA2315392A1 (de)
DE (1) DE69935848T2 (de)
WO (1) WO1999035802A2 (de)

Families Citing this family (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6353614B1 (en) 1998-03-05 2002-03-05 3Com Corporation Method and protocol for distributed network address translation
US6088340A (en) * 1998-06-23 2000-07-11 Motorola, Inc. Method and apparatus in a wireless communication system for controlling a display of template data by a protable subscriber unit
DE19936314A1 (de) * 1998-08-05 2000-02-17 Spyglass Inc Verfahren und System zur Inhaltskonvertierung von elektronischen Daten unter Verwendung von Konvertierungspräferenzen
US6925595B1 (en) 1998-08-05 2005-08-02 Spyglass, Inc. Method and system for content conversion of hypertext data using data mining
US6584490B1 (en) 1998-10-30 2003-06-24 3Com Corporation System and method for providing call-handling services on a data network telephone system
US6446127B1 (en) 1998-10-30 2002-09-03 3Com Corporation System and method for providing user mobility services on a telephony network
US6356529B1 (en) * 1999-08-12 2002-03-12 Converse, Ltd. System and method for rapid wireless application protocol translation
US8595308B1 (en) 1999-09-10 2013-11-26 Ianywhere Solutions, Inc. System, method, and computer program product for server side processing in a mobile device environment
US6779042B1 (en) 1999-09-10 2004-08-17 Ianywhere Solutions, Inc. System, method, and computer program product for enabling on-device servers, offline forms, and dynamic ad tracking on mobile devices
US7987420B1 (en) 1999-09-10 2011-07-26 Ianywhere Solutions, Inc. System, method, and computer program product for a scalable, configurable, client/server, cross-platform browser for mobile devices
US20010047394A1 (en) 1999-09-10 2001-11-29 Kloba David D. System, method, and computer program product for executing scripts on mobile devices
US6681252B1 (en) 1999-09-27 2004-01-20 3Com Corporation System and method for interconnecting portable information devices through a network based telecommunication system
US6857072B1 (en) 1999-09-27 2005-02-15 3Com Corporation System and method for enabling encryption/authentication of a telephony network
US6744759B1 (en) 1999-09-27 2004-06-01 3Com Corporation System and method for providing user-configured telephone service in a data network telephony system
US6795429B1 (en) 1999-09-27 2004-09-21 3Com Corporation System and method for associating notes with a portable information device on a network telephony call
US7016675B1 (en) 1999-09-27 2006-03-21 3Com Corporation System and method for controlling telephone service using a wireless personal information device
US6937699B1 (en) 1999-09-27 2005-08-30 3Com Corporation System and method for advertising using data network telephone connections
WO2001065820A2 (en) * 2000-02-29 2001-09-07 3Com Corporation System and method for enabling a portable information device for use in a data network telephone system
US6731630B1 (en) 2000-02-29 2004-05-04 3Com Corporation Flexible dial plan for a data network telephony system
US6804224B1 (en) 2000-02-29 2004-10-12 3Com Corporation System and method for providing telephone service having private branch exchange features in a voice-over-data network telephony system
US6650901B1 (en) 2000-02-29 2003-11-18 3Com Corporation System and method for providing user-configured telephone service in a data network telephony system
US7324635B2 (en) 2000-05-04 2008-01-29 Telemaze Llc Branch calling and caller ID based call routing telephone features
IL146744A0 (en) * 2000-08-05 2002-07-25 Idesta Group Ltd Mobile computing system architecture
AU2001278099A1 (en) * 2000-08-15 2002-02-25 Nokia Inc. Remotely commanded entities for wireless terminals
FR2813735B1 (fr) * 2000-09-01 2003-01-31 In Fusio Procede pour l'exploitation d'applications graphiques sur un terminal mobile
FR2818409B1 (fr) * 2000-12-18 2003-03-14 Expaway Procede pour diviser des documents structures en plusieurs parties
US7418254B2 (en) * 2001-02-20 2008-08-26 Microsoft Corporation Mobile communication device dynamic service application and dynamic service application scripting
JP4325954B2 (ja) * 2002-12-27 2009-09-02 ヤマハ株式会社 ファイル作成端末
US7873353B2 (en) 2003-09-30 2011-01-18 Ianywhere Solutions, Inc. Method and system for accessing applications and data, and for tracking of key indicators on mobile handheld devices
US8135803B2 (en) 2004-08-23 2012-03-13 Ianywhere Solutions, Inc. Method, system, and computer program product for offline advertisement servicing and cycling
US7945853B2 (en) * 2005-09-12 2011-05-17 Microsoft Corporation Script markup
CN100562144C (zh) * 2005-09-29 2009-11-18 北京握奇数据系统有限公司 无打扰业务管理系统及业务实现方法
KR101350661B1 (ko) * 2011-09-30 2014-01-10 엔에이치엔엔터테인먼트 주식회사 웹 기술을 이용한 하이브리드 어플리케이션 구동 장치 및 방법

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07210324A (ja) * 1994-01-13 1995-08-11 Hitachi Ltd 記憶装置
JP3704374B2 (ja) * 1994-04-22 2005-10-12 新日鉄ソリューションズ株式会社 ドキュメント管理システム
US5740549A (en) * 1995-06-12 1998-04-14 Pointcast, Inc. Information and advertising distribution system and method
JP4588128B2 (ja) * 1996-03-22 2010-11-24 ソニー株式会社 表示装置及び方法
US5673322A (en) * 1996-03-22 1997-09-30 Bell Communications Research, Inc. System and method for providing protocol translation and filtering to access the world wide web from wireless or low-bandwidth networks
JP3437373B2 (ja) * 1996-04-16 2003-08-18 株式会社野村総合研究所 情報利用状況把握方法およびその方法を利用した情報提供システム
JPH09305408A (ja) * 1996-05-09 1997-11-28 Hitachi Ltd アプリケーション実行方法

Also Published As

Publication number Publication date
WO1999035802A2 (en) 1999-07-15
WO1999035802A8 (en) 1999-08-19
DE69935848D1 (de) 2007-05-31
JP4404480B2 (ja) 2010-01-27
EP1051823A1 (de) 2000-11-15
CA2315392A1 (en) 1999-07-15
EP1051823B1 (de) 2007-04-18
JP2002501241A (ja) 2002-01-15

Similar Documents

Publication Publication Date Title
DE69935848T2 (de) System zur lieferung von daten über einen übertragungskanal mit niedrigen bitraten
DE69927787T2 (de) Kanaldefinitionsarchitekturerweiterung
US6311058B1 (en) System for delivering data content over a low bit rate transmission channel
CN100593780C (zh) 为与无线设备进行通信而压缩/解压数据的方法和系统
WO1999035802A1 (en) System for delivering data content over a low bit rate transmission channel
DE69928277T2 (de) Verfahren und vorrichtung zur ausführung von fehlerkorrektur durch kombination von zwei instanzen einer nachricht
US6604149B1 (en) Method and apparatus for identifying individual messages in a single compressed data packet
DE60033011T2 (de) Aufteilung einer datei zur emulation eines datenstroms
EP2381649B1 (de) Verfahren und System zur Erweiterung der Kapazitäten von eingebetteten Vorrichtungen durch Netzwerk-Clients
US7089560B1 (en) Architecture for building web applications
US8683328B2 (en) Multimedia communication and presentation
DE60308462T2 (de) Verfahren zur Übertragung von Antworten zu abgekürzter elektronischer Post
US20070219991A1 (en) System and method for delivering targeted data to a subscriber base via a computer network
CN101331486B (zh) 对门户中的导航状态进行有效地串行化的方法和系统
CN1226709A (zh) 与硬件设备进行远程交互的方法和装置
JP2004318188A (ja) 構造化データの受信プログラム
CN101512519B (zh) 封装uri方案以标识并引用包的多个部分
KR101066610B1 (ko) Xml과 json 데이터의 압축 및 분할 전송시스템
KR20050032035A (ko) Html 어플리케이션의 방송 방법
Foo et al. Delivery of video mail on the World Wide Web
Foo et al. System architectural design for delivering video mail over the World-Wide-Web
Schubert et al. Delivery of Video Mail on the World Wide Web
Ozden A Binary Encoding for Efficient XML Processing
Ridgway Open Hypermedia and Streaming Audio
JP2004234672A (ja) 構造化データの送信装置

Legal Events

Date Code Title Description
8364 No opposition during term of opposition