DE60121987T2 - Zugreifen auf Daten, die bei einer Zwischenstation gespeichert sind, von einem Dienst aus - Google Patents

Zugreifen auf Daten, die bei einer Zwischenstation gespeichert sind, von einem Dienst aus Download PDF

Info

Publication number
DE60121987T2
DE60121987T2 DE60121987T DE60121987T DE60121987T2 DE 60121987 T2 DE60121987 T2 DE 60121987T2 DE 60121987 T DE60121987 T DE 60121987T DE 60121987 T DE60121987 T DE 60121987T DE 60121987 T2 DE60121987 T2 DE 60121987T2
Authority
DE
Germany
Prior art keywords
output
service
application
request
data
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
DE60121987T
Other languages
English (en)
Other versions
DE60121987D1 (de
Inventor
Jacob San Francisco CHRISTFORT
Jeremy San Francisco CHONE
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.)
Oracle International Corp
Original Assignee
Oracle International 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
Application filed by Oracle International Corp filed Critical Oracle International Corp
Application granted granted Critical
Publication of DE60121987D1 publication Critical patent/DE60121987D1/de
Publication of DE60121987T2 publication Critical patent/DE60121987T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/957Browsing optimisation, e.g. caching or content distillation
    • G06F16/9577Optimising the visualization of content, e.g. distillation of HTML documents
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/564Enhancement of application control based on intercepted application data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/568Storing data temporarily at an intermediate stage, e.g. caching
    • H04L67/5682Policies or rules for updating, deleting or replacing the stored data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/912Applications of a database
    • Y10S707/918Location
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99931Database or file accessing
    • Y10S707/99933Query processing, i.e. searching
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99931Database or file accessing
    • Y10S707/99933Query processing, i.e. searching
    • Y10S707/99936Pattern matching access

Description

  • GEBIET DER ERFINDUNG
  • Die Erfindung betrifft das Bereitstellen von Diensten für Clients und insbesondere das Zugreifen auf Daten, die bei einer Zwischenstation gespeichert sind, von einem Dienst aus.
  • HINTERGRUND DER ERFINDUNG
  • Das World Wide Web beinhaltet ein Netz von Servern im Internet, wobei jedem von diesen eine oder mehrere HTML-(Hypertext Markup Language)-Seiten zugehörig sind. Die einem Server zugehörigen HTML-Seiten stellen Informationen und Hypertext-Links zu weiteren auf diesem und (üblicherweise) weiteren Servern befindlichen Dokumenten bereit. Server kommunizieren mit Clients unter Verwendung des Hypertext-Transfer-Protokolls (HTTP). Die Server warten auf Anfragen von Clients nach ihren HTML-Seiten und werden daher häufig als "Listeners" ("Horcheinheiten") bezeichnet.
  • Benutzer des World Wide Web verwenden ein Client-Programm, das als "Browser" bezeichnet wird, um Informationen von den "Listenern" anzufordern, zu dekodieren und anzuzeigen. Wenn der Benutzer eines Browsers auf einer HTML-Seite einen Link auswählt, sendet der Browser, welcher die Seite anzeigt, über das Internet eine Anfrage an den "Listener", zu dem die im Link angegebene URL-(Universal Resource Locator)-Adresse gehört. Reagierend auf die Anfrage sendet der "Listener" die angeforderte Information an den Browser, von dem die Anfrage stammt. Der Browser empfängt die Information, präsentiert die empfangene Information dem Benutzer und wartet auf die nächste Benutzeranfrage.
  • Herkömmlicherweise liegt die auf den "Listenern" gespeicherte Information in Form von statischen HTML-Seiten vor. Statische HTML-Seiten sind bereits erzeugt und im "Listener" gespeichert, bevor eine Anfrage von einem Web- Browser erfolgt. Reagierend auf eine Anfrage wird lediglich eine statische HTML-Seite aus dem Speicher ausgelesen und an den anfordernden Browser gesendet. Momentan besteht ein Trend, "Listener" zu entwickeln, die auf Browseranfragen mit der Durchführung dynamischer Operationen reagieren. Beispielsweise kann ein "Listener" auf eine Anfrage antworten, indem er eine Suchanfrage an eine Datenbank ausgibt, dynamisch eine Webseite aufbaut, welche die Ergebnisse der Suchanfrage enthält, und die dynamisch aufgebaute HTML-Seite an den anfordernden Browser sendet.
  • Ein weiterer Trend besteht darin, den Internetzugang außer auf herkömmliche Computersysteme auch auf weitere Geräte auszudehnen. Beispielsweise wurden viele mobile Clients (oder Mobilgeräte), beispielsweise Funktelefone, entwickelt, welche eingebettete Web-Browser beinhalten. Bedingt durch Größen- und Kosteneinschränkungen haben die in diesen Geräten enthaltenen "Mikro-Browser" sehr eingeschränkte Funktionalität im Vergleich zu den Browsern, die für über vollen Leistungsumfang verfügende Computersysteme entwickelt wurden. Jedoch können Geräte mit eingebetteten Mikro-Browsern bei Umständen verwendet werden, bei denen ein herkömmliches Computersystem nicht praktisch einsetzbar ist.
  • Die Anzahl von Gerätetypen, die Web-Inhalte in der einen oder der anderen Form anzeigen können, steigt weiter an. Beispielsweise gibt es Desktop-, Laptop- und Pocket-Computer, Mobiltelefone, Pager und PDAs (Personal Digital Assistants), die als "internetfähig" eingestuft werden können, da sie zum Anzeigen von Web-Inhalten in der Lage sind. Mit zunehmender Anzahl der internetfähigen Gerätetypen nimmt auch die Schwankungsbreite der Fähigkeiten der Geräte zu. Beispielsweise kompensieren übliche Mehrzweck-Computersysteme ihre fehlende Mobilität durch Bereitstellen großer Farbbildschirme, einer aufwändigen Tonausgabe, einer beträchtlichen Rechenleistung, einer Eingabe über eine ergonomische Tastatur und einfach zu verwendende Auswahlgeräte, wie beispielsweise eine Maus, einen Trackball oder ein Trackpad. Umgekehrt wird die Tragbarkeit kleiner mobiler Geräte auf Kosten der Bildschirmgröße und der leichten Eingabemöglichkeiten des Benutzers erzielt.
  • Noch ein weiterer Trend besteht darin, dass man Clients über einen in einem Netz befindlichen Server Dienste anbietet. Typischerweise ist das Netz das Internet, der Client ist ein Benutzer und der Dienst kann vom Server über eine Website bezogen werden. Der Dienst kann Informationen, wie beispielsweise Restaurantkritiken, Wetterberichte, Börsennotierungen oder aktuelle Nachrichten bereitstellen. Bei dem Dienst kann es sich auch um einen eher interaktiven Dienst handeln, beispielsweise einen, der dem Benutzer das Einkaufen von Waren ermöglicht, beispielsweise Bücher oder Musik, oder ihm ermöglicht, Dienste zu kaufen, wie beispielsweise das Buchen von Reisearrangements. Der Begriff "Dienst", wie hier verwendet, bedeutet, dass für einen Client Informationen, Funktionen oder Fähigkeiten bereitgestellt werden.
  • Das Verfahren, durch das der Benutzer auf den Dienst zugreift, hängt vom Client-Typ ab, über den der Benutzer verfügt. Beispielsweise kann ein Desktop-Computer mit dem Internet über eine Einwählleitung, eine DSL-(Digital Subscriber Line)-Leitung, ein Kabelmodem, eine ISDN-(Integrated Services Digital Network)-Verbindung oder viele weitere verfügbare Verfahren verbunden sein. WAP-(Wireless Application Protocol)-Telefone können mit dem Internet über eine drahtlose Verbindung mittels eines WAP-zu-HTTP-Gateways verbunden sein. Üblicherweise loggt sich der Client in die Website ein, und es wird ihm eine Liste von verfügbaren Diensten präsentiert, aus denen der Client den gewünschten Dienst auswählt.
  • Üblicherweise wird ein Dienst in einer von zwei Arten bereitgestellt: als gehostete Anwendung oder als Portalanwendung. Bei einer typischen gehosteten Anwendung erzeugt ein Entwickler die Anwendung, jedoch erfolgt Installation und Pflege der Anwendung für einen Zugriff durch Endbenutzer oder Kunden durch einen Host (Verarbeitungsrechner) des Hostserver-Netzes. Im Gegensatz dazu erzeugt bei einer typischen Portalanwendung der Entwickler die Anwendung und stellt sie auch für einen Zugriff durch Endbenutzer, oder Kunden, über einen oder mehrere vom Entwickler betriebene Server bereit. Der Begriff "Entwickler", wie hier verwendet, kann eine Einzelperson, eine Firma oder eine juristische Person bezeichnen, die den Dienst bereitstellt (auch als Dienstanbieter oder Service-Provider bezeichnet), oder der Entwickler kann eine andere Einheit sein, die für den Dienstanbieter Software-Entwicklungsdienste bereitstellt.
  • Ein übliches Problem bei der Bereitstellung von Diensten mittels Anwendungen, unabhängig davon, ob es sich um gehostete Anwendungen oder Portalanwendungen handelt, besteht darin, dass die Anwendung ausgelegt sein muss, um mit allen Geräten zusammenzuarbeiten. Jedoch ergeben sich bei den Geräten große Unterschiede ihrer Fähigkeiten, abhängig sowohl vom Gerätetyp als auch den speziellen Fähigkeiten unterschiedlicher Gerätemodelle gleichen Typs oder gleicher Geräteklasse. Beispielsweise verfügt ein Desktop-Computer üblicherweise über einen volle Funktionalität aufweisenden Web-Browser, hingegen verfügt ein PDA über einen Mikro-Browser mit eingeschränkter Funktionalität. Auch können einige Mobiltelefone eine eingeschränkte Anzeige aufweisen, bei der lediglich ein einziges Wort in jeder Zeile der Anzeige angezeigt werden kann, hingegen können andere Mobiltelefone eine größere Anzeige aufweisen, welche mehrere Wörter in jeder Zeile anzeigen kann.
  • Die unterschiedlichen Fähigkeiten können es für einen Anwendungsentwickler schwierig machen, alle möglichen Geräte zu unterstützen. Beispielsweise kann ein Dienst die Anzeige von graphischen Bildern beinhalten, beispielsweise solchen von zum Verkauf angebotenen Produkten, welche problemlos auf dem volle Funktionalität aufweisenden Web-Browser eines Desktop-Computers dargestellt werden können, jedoch möglicherweise nicht auf der Anzeige eines Mobiltelefons dargestellt werden können. Sogar wenn der Entwickler lediglich mit einem bestimmten Gerätetyp oder -klasse befasst ist, können die Unterschiede bei den Fähigkeiten signifikant sein. Wenn beispielsweise der Anwendungs programmierer eine Ausgabe sendet, die mehrere Wörter enthält, welche mehrere Informationselemente beschreiben, ist es möglich, dass Mobiltelefone mit begrenzten Anzeigebildschirmen lediglich das erste Wort eines jeden Informationselementes auf jeder Zeile des Anzeigebildschirms darstellen können, oder dass die Ausgabe für ein einziges Informationselement mehrere Zeilen auf der Anzeige des Telefon füllt, was eine gleichzeitige Darstellung weiterer Informationselemente verhindert.
  • Ein Ansatz zur Lösung des Problems der Gestaltung von Geräten unterschiedlicher Fähigkeiten besteht darin, eine Gestaltung im Hinblick auf den "kleinsten gemeinsamen Nenner" vorzunehmen. Der Lösungsansatz des kleinsten gemeinsamen Nenners beinhaltet, dass die Anwendung so gestaltet wird, dass sie mit dem die größten Einschränkungen aufweisenden Gerät zusammenarbeitet. Wenn beispielsweise ein Menü von Optionen auf einem Client-Gerät, wie beispielsweise einem Mobiltelefon, angezeigt werden soll, kann ein Anwendungsprogrammierer für jede der Optionen kurze, aus einem Wort bestehende Bezeichnungen wählen, da alle Geräte, welche die Anwendung nutzen werden, aus einem Wort bestehende Bezeichnungen unterstützen können. Beispielsweise kann der Anwendungsentwickler bei einer Landkartenanwendung das aus einem einzigen Wort bestehende Menüelement "Rückkehr" ("Return") für die Option des Erzeugens von Rückkehranweisungen von einem gewählten Zielpunkt verwenden.
  • Jedoch besteht ein Nachteil des Lösungsansatzes des kleinsten gemeinsamen Nenners darin, dass die Ausgabe nicht die größeren Fähigkeiten der übrigen Geräte ausnützt. Wenn beispielsweise ein Client in der Lage ist, eine längere Bezeichnung anzuzeigen, wie beispielsweise "Erzeuge Rückkehranweisungen" ("Generate Return Directions"), würde man die längere Bezeichnung bevorzugen, da "Rückkehr" ("Return") zweideutig ist und vom Benutzer in nicht zutreffender Weise in der Bedeutung "Rückkehr zum vorhergehenden Menü" interpretiert werden könnte. Außerdem bleiben die in neue Geräte eingebauten Fähigkeiten weitgehend ungenutzt, wenn alle Anwendungen auf die minimalen Fähigkeiten der älteren Geräte abzielen.
  • Ein alternativer Lösungsansatz zur Lösung des Problems einer Gestaltung für Clients oder Geräte unterschiedlicher Fähigkeiten besteht darin, eine Gestaltung im Hinblick auf ein mittleres Fähigkeitsniveau vorzunehmen, beispielsweise für den am häufigsten vorkommenden Typ von Mobiltelefon. Jedoch funktioniert möglicherweise eine Anwendung, welche diesen Lösungsansatz des mittleren Niveaus verwendet, nicht in korrekter Weise auf Geräten mit geringeren Fähigkeiten, und weiterhin nutzt diese Anwendung nicht die besseren Fähigkeiten der anderen Geräte aus.
  • Ein weiteres Problem bei der Bereitstellung von Diensten mittels Anwendungen besteht darin, wie eine Unterstützung von zusätzlichen Geräten erfolgen soll, die erst nach der Entwicklung der Anwendung auf dem Markt kommen. Beispielsweise erfolgt mehrere Monate, nachdem ein Dienstanbieter eine Anwendung auf den Markt bringt, durch einen Gerätehersteller die Markteinführung eines neuen Gerätes. Das neue Gerät kann einen entwicklungsmäßigen Vorteil gegenüber aktuell erhältlichen Geräten bedeuten, durch den bestehende Leistungsmerkmale verbessert werden, oder das neue Gerät kann einen beträchtlichen Fortschritt in dieser Geräteklasse bedeuten, durch den signifikante neue Leistungsmerkmale hinzukommen, oder das neue Gerät kann ein neuer Gerätetyp sein, der über neue Fähigkeiten oder eine neue Kombination von Fähigkeiten verfügt.
  • Den neuen Geräten mit verbesserten Fähigkeiten kann unter Verwendung des Lösungsansatzes des kleinsten gemeinsamen Nenners Rechnung getragen werden, jedoch bleiben dann die verbesserten Leistungsmerkmale und Fähigkeiten der neuen Geräte, beispielsweise größere Anzeigen, größtenteils ungenutzt. Wenn beispielsweise die Anwendung lediglich aus einem Wort bestehende Menüoptionen bereitstellt, nutzt die Anwendung nicht ein verbessertes Gerät aus, das Mehrwortoptionen anzeigen kann. Weiter kann es bei einem später auf den Markt gebrachten Gerät durch den Lösungsansatz des kleinsten gemeinsamen Nenners passieren, dass eine Nutzung neuer Fähigkeiten, beispielsweise die Handhabung von Sprachdaten oder graphischen Elementen, vollständig ungenutzt bleiben. Sogar wenn die Anwendung für ein mittleres Fähigkeitsniveau ausgelegt ist, ist es möglich, dass die Anwendung weiterhin nicht alle Vorzüge und Verbesserungen von in der Zukunft konzipierten Geräten vollständig ausnutzt.
  • Noch ein weiteres Problem bei der Anwendungsentwicklung besteht im Erlangen eines einfachen Zugriffs auf die Tools, die dem Entwickler zur Erzeugung der Anwendung zur Verfügung stehen. Typischerweise verwendet ein Entwickler, welcher eine Anwendung für eine spezielle Plattform auslegt (z.B. eine Kombination aus Hardware, Betriebssystem und/oder Protokollen), eine Software-Entwicklungsbibliothek (SDK). Eine SDK enthält üblicherweise eine Anwendungsprogrammierumgebung, einige üblicherweise verwendete Bibliotheken für verschiedene Leistungsmerkmale, Anwendungsprogrammierschnittstellen, Hilfsprogramme, eine Dokumentation, einen Compiler zum Erzeugen von ausführbarem Code aus Quellcode und einen Debugger zur Diagnose von Programmierproblemen. Zur Verwendung dieser Tools erhält der Entwickler die Software, die Dokumentation und weitere Materialien von einem SDK-Dienstanbieter, und dann installiert der Entwickler die Software und weitere Tools auf einem lokalen Computer oder Netz. Später erfolgt, wenn der SDK-Dienstleister Verbesserungen und Upgrades vornimmt, durch den Entwickler ein Einbau derartiger Änderungen in die lokale Installation des SDK-Paketes. Somit ist es möglicherweise erforderlich, dass die Anwendungsentwickler für Installation und Pflege des SDK beträchtliche Ressourcen aufwenden. Außerdem werden bei einem herkömmlichen SDK typischerweise nicht nur für das eigentliche SDK signifikante Ressourcen benötigt, sondern auch für die Anwendungsentwicklung und die Infrastruktur für Einrichten, Testen und Entwickeln der Runtime-Anwendungen.
  • Außerdem ist es möglich, dass einzelne Dienstanbieter weitere Dienste anbieten möchten, die in Bezug zu ihren Kerndiensten stehen, um das Gesamtpaket für die Kunden des Dienstes zu verbessern. Wenn beispielsweise ein Benutzer Fahrtrouten zu einem speziellen Zielort von einem Dienstanbieter heraussucht, möchte der Fahrtrouten-Dienstleister möglicherweise dem Benutzer zusätzliche Information über das Wetter oder die Gastronomiemöglichkeiten an einem speziellen Zielort anbieten. Eine Art, wie der Fahrtrouten-Dienstleister derartige zusätzliche Information anbieten kann, besteht in der Erzeugung der erforderlichen zusätzlichen Dienste, was beträchtliche zusätzliche Entwicklungsressourcen nach sich ziehen kann. Ein weiterer Lösungsansatz besteht darin, dass der Dienstanbieter mit einem anderen Dienstanbieter Absprachen trifft, um die gewünschte Funktionalität zu erzielen. Jedoch kann für das Treffen von Absprachen mit anderen Dienstanbietern ein beträchtlicher Koordinationsaufwand erforderlich sein, sowohl für die Einrichtung der technischen Infrastruktur zur Verbindung der Dienste der beiden Dienstanbieter als auch um zu Zwecken der Rechnungsstellung eine Messeinrichtung für die Häufigkeit der Nutzung durch die Kunden des ersten Dienstanbieters einzurichten.
  • Noch eine weitere Problematik bei der Bereitstellung von Diensten mittels Anwendungen besteht darin, dass der Dienstanbieter möglicherweise in die Anwendungen dauerhaft gespeicherte Daten einbauen möchte, welche den Anwendungen bei der Ausführung zur Verfügung stehen. Der Dienstanbieter ist dann damit konfrontiert, sich mit einer aufwändigen Erstellung und Pflege der gespeicherten Daten zu beschäftigen, damit die Daten verfügbar sind, wenn sie von den Anwendungen benötigt werden.
  • Basierend auf dem zuvor Beschriebenen ist es wünschenswert, verbesserte Verfahren für die Gestaltung von Anwendungen bereitzustellen, welche effektiver mit allen Geräten zusammenarbeiten. Es ist auch erwünscht, über verbesserte Verfahren zur Erzeugung von Anwendungen zu verfügen. Weiter ist es erwünscht, über verbesserte Verfahren zu verfügen, welche Dienstanbietern das Anbieten zusätzlicher Dienste ermöglichen. Es ist ebenfalls erwünscht, über verbesserte Verfahren zum Einbau gespeicherter Daten in eine Anwendung zu verfügen.
  • Das US-Patent 5,960,432 offenbart eine Technik zum Verbessern der Darstellung von Daten, die durch einen Client von einem Server empfangen werden. Zunächst wird eine Stufe von einer Mehrzahl von Stufen der Komplexität oder Angemessenheit für unterschiedliche Zielgruppen bestimmt. Der Server erhält dann eine Anforderung für einen Basisdatensatz, z.B. ein Bild. Auf diese Anforderung reagierend, überträgt der Server den Basisdatensatz zum Client und bestimmt ferner, ob es einen dem Basisdatensatz zugeordneten Datensatz gibt, z.B. eine Erklärung des Bildes, wobei dessen Stufe zu der bestimmten Stufe passt. Wenn der Server einen zugeordneten Datensatz mit einer passenden Stufe findet, wird der zugeordnete Datensatz zum Client gesendet.
  • INHALT DER ERFINDUNG
  • Die Erfindung ist durch die unabhängigen Ansprüche definiert. Die abhängigen Ansprüche definieren bevorzugte Ausführungsformen der Erfindung.
  • Es werden Verfahren zum Zugriff auf Daten, die bei einer Zwischenstation gespeichert sind, von einem Dienst aus bereitgestellt. Gemäß einem Aspekt können Dienste auf Daten zugreifen, die bei einer Zwischenstation gespeichert sind. Die Ausgabe eines Dienstes wird, in Reaktion auf eine Anforderung von einem Endbenutzer, bei einer Zwischenstation empfangen. Die Ausgabe beinhaltet Variablen, die Daten entsprechen, welche bei einem der Zwischenstation zugeordneten Server gespeichert sind. Eine Abbildung wird verwendet, um festzustellen, welche Variablen welchen bei dem Server gespeicherten Daten entsprechen. In Reaktion auf die Anforderung wird eine Antwort erzeugt, die auf der von dem Dienst stammenden Ausgabe beruht und die, beruhend auf den Variablen in der Ausgabe, gespeicherte Daten enthält. Der Dienst kann bei dem Server gespei cherte Daten speichern oder aktualisieren und auch neue Variablen definieren, die in die Abbildung aufgenommen werden sollen.
  • Gemäß anderen Aspekten können die Variablen verwendet werden, um einem Endbenutzer den Zugriff auf einen vorherigen Dienst zu gestatten. Ein bei dem Server gespeicherter Datenwert kann einen vorherigen Dienst angeben, auf den der Endbenutzer zugegriffen hat. Ein Dienst, auf den später zugegriffen wurde, kann dann eine Variable enthalten, die diesem Datenwert des vorherigen Dienstes entspricht, um die Rückkehr des Endbenutzers zu dem vorherigen Dienst zu erleichtern. Der ursprüngliche Dienst kann auch einen Dienstbezeichner an einen anderen Dienst übermitteln, indem eine Variable verwendet wird, so dass der andere Dienst die Identität des vorherigen Dienstes erfahren kann, um dem Endbenutzer einen Pfad zur Rückkehr zu dem vorherigen Dienst bereitzustellen.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die Erfindung ist beispielhaft und nicht einschränkend in den Figuren der beiliegenden Zeichnungen dargestellt, in denen gleiche Bezugszeichen ähnliche Elemente bezeichnen und die zeigen:
  • 1A ein Blockdiagramm, welches eine problemorientierte Übersicht eines Systems gemäß einem Ausführungsbeispiel der Erfindung darstellt, welches Dienste mittels Anwendungen bereitstellt, auf die über eine Zwischenstation zugegriffen wird;
  • 1B ein Blockdiagramm, welches eine Übersicht eines Host-Servers gemäß einem Ausführungsbeispiel der Erfindung darstellt;
  • 2 ein Blockdiagramm, welches eine Bedingungshierarchie gemäß einem Ausführungsbeispiel der Erfindung darstellt;
  • 3 ein Ablaufdiagramm, welches einen Lösungsansatz zur Auswahl eines alternativen Ausgabesegmentes gemäß einem Ausführungsbeispiel der Erfindung darstellt;
  • 4 ein Blockdiagramm, welches ein Beispiel einer Erzeugung einer Ausgabe unter Verwendung einer aufgeteilt gehosteten Anwendung gemäß einem Ausführungsbeispiel der Erfindung darstellt; und
  • 5 ein Blockdiagramm, welches ein Computersystem darstellt, auf dem ein Ausführungsbeispiel implementiert werden kann.
  • DETAILLIERTE BESCHREIBUNG DES BEVORZUGTEN AUSFÜHRUNGSBEISPIELS
  • Es wird ein netzbasiertes Betriebssystem für Mobilgeräte beschrieben. In der folgenden Beschreibung werden zum Zweck der Erläuterung zahlreiche spezielle Details dargelegt, um für ein grundlegendes Verständnis der Erfindung zu sorgen. Für einen Fachmann ist es jedoch klar, dass die Erfindung ohne diese speziellen Details realisiert werden kann. Im übrigen sind allgemein bekannte Strukturen und Vorrichtungen in Blockdiagrammform dargestellt, um eine unnötige Komplizierung der Darstellung der Erfindung zu vermeiden.
  • In der folgenden Beschreibung werden die verschiedenen Funktionen unter Themenüberschriften erläutert, die in der folgenden Reihenfolge erscheinen:
    • I. STRUKTURELLE UND FUNKTIONALE ÜBERSICHT
    • A. Hosting von Anwendungen
    • B. Spezifische Anpassung von durch einen Dienst bereitgestelltem Inhalt
    • C. Bereitstellung von Inhalt von Mehrfachdiensten
    • D. Zugriff auf bei einer Zwischenstation gespeicherte Daten von einem Dienst
    • E. Online-Entwicklung von Anwendungen
    • II. ONLINE-ENTWICKLUNG VON ANWENDUNGEN
    • A. Erzeugung von Anwendungen und Diensten – Überblick
    • B. Entwicklung einer gehosteten Anwendung
    • C. Entwicklung einer aufgeteilt gehosteten Anwendung
    • D. Zugriff auf die neue Anwendung oder den neuen Dienst
    • III. GENERIEREN DES GERÄTESPEZIFISCHEN MARKUP-CODES
    • A. Generieren einer gerätespezifischen Formatierung
    • B. Erzeugung einer Ausgabe, die Anfragebedingungen berücksichtigt
    • C. Bedingungsunabhängige Ausgabe mit eingebetteten Hinweisen
    • D. Beispiel der Verwendung von eingebetteten Hinweisen zur Identifizierung eines Gerätetyps
    • E. Erzeugung einer Ausgabe basierend auf einer Bedingungshierarchie
    • F. Erzeugung einer Ausgabe durch Abgleichen mit den Anfragebedingungen
    • G. Auswahl der Ausgabe basierend auf der vom Client-Gerät unterstützten Sprache
    • H. Verwendung eines Middleware-Transformers zur Umwandlung einer bedingungsunabhängigen Ausgabe
    • I. Beispiel der Erzeugung der Ausgabe unter Verwendung einer aufgeteilt gehosteten Anwendung
    • IV ZUGRIFF AUF WEITERE ANWENDUNGEN UND DIENSTE
    • A. Mobile Module
    • B. Speichern von Daten bei einer Zwischenstation
    • V. HARDWARE-ÜBERSICHT
  • I. STRUKTURELLE UND FUNKTIONALE ÜBERSICHT
  • Verfahren sind vorgesehen, um Konzeption und Entwicklung von Anwendungen zu erleichtern, welche verwendet werden, um Dienste für einen Zugriff durch Geräte wie beispielsweise mobile Clients bereitzustellen. Diese Verfahren beinhalten die Entwicklung von Anwendungen, die auf einer Vielzahl unterschiedlicher Geräte ausgeführt werden können, dadurch, dass eine spezifische Anpassung der Ausgabe erfolgt, nachdem sie von der Anwendung erzeugt wurde, und zwar basierend auf den speziellen Umständen der Nutzung der Anwendung durch den Endbenutzer, beispielsweise den Fähigkeiten eines mobilen Client oder den Netzbedingungen, die zu dem Zeitpunkt vorhanden sind, bei dem ein Kunde von der Anwendung einen Dienst anfordert. Ebenso beinhalten diese Verfahren das Kombinieren der Ausgabe, der Fähigkeiten und der Leistungsmerkmale der Dienste, und schließen Verfahren ein, welche einem Endbenutzer gestatten, zu einem Dienst zurückzukehren, auf den er früher schon zugegriffen hat. Außerdem beinhalten diese Verfahren ein Speichern von Daten bei einer Zwischenstation für einen Zugriff durch die einem Dienst zugehörigen Anwendungen unter Verwendung von Variablen und ein Mapping (Zuordnen) der Variablen auf die gespeicherten Daten.
  • Weiter beinhalten diese Verfahren das Bereitstellen einer Online-Software-Entwicklungsbibliothek (SDK), so dass Anwendungsentwickler Anwendungen konzipieren, testen, modifizieren und entwickeln können, ohne dass sie irgendeine spezielle client-seitige Software haben. Entwickler können Code über eine Schnittstelle eingeben, die durch die Website der SDK über das Internet bereitgestellt wird. Da die Website der SDK auf XML- und HTTP-Standards basiert, kann der Entwickler bestehenden Code weiterverwenden. Wenn beispielsweise der Entwickler einen IIS-(Microsoft Internet Information Services)-Server hat, der ".asp"-Seiten liefert, kann die Online-SDK auf den bestehenden Server und bestehende Seiten des Entwicklers zugreifen.
  • Wie hier verwendet, bezeichnet der Begriff "Endbenutzer" eine beliebige Person, Organisation oder juristische Person, die ein Gerät für einen Zugriff auf einen Dienst oder Anwendung verwendet. Der Begriff "Endbenutzer" umfasst den Begriff "Kunde", auch wenn der Begriff "Kunde" nicht notwendigerweise eine geschäftliche Beziehung mit einem Dienstanbieter impliziert. Auch unterscheidet sich der Begriff "Endbenutzer" vom Begriff "Benutzer", welcher, wie später noch erläutert wird, sich auf Entwickler und Dienstanbieter bezieht, welche die Anwendungen oder Computerprogramme, die für die Endbenutzer Dienste bereitstellen, erzeugen und pflegen.
  • A. Hosting von Anwendungen
  • 1A ist ein Blockdiagramm, welches eine problemorientierte Übersicht eines Systems gemäß einem Ausführungsbeispiel der Erfindung darstellt, welches Dienste mittels Anwendungen bereitstellt, auf die über eine Zwischenstation zugegriffen wird. 1 zeigt ein Netz 100, das einen Host-Server 110 beinhaltet. Das Netz 100 kann ein beliebiger Typ von Netz sein, einschließlich, jedoch nicht eingeschränkt auf ein privates Netz, wie beispielsweise ein Intranet, ein öffentliches Netz, wie beispielsweise das Internet, oder eine Kombination unterschiedlicher Netze und Netztypen.
  • Der Host-Server 110 kann auf einem oder mehreren Servern bei einer Zwischenstation implementiert sein, beispielsweise einem Hosting-Dienstanbieter, auch als Host-Provider oder einfach als Host bezeichnet. Die Funktion des Host besteht darin, beispielsweise auf einem Host-Server 110 Anwendungen, die entweder vom Host-Provider oder anderen Anwendungsentwicklern entwickelt werden, zu installieren und zu pflegen. Die Anwendungen sind typischerweise Teil eines Dienstes, beispielsweise einer Website, eines Funkruf-(Paging)-Dienstes oder eines Telekommunikationsdienstes. Der Host kann auch ein "partielles" oder "aufgeteiltes" Hosting von Anwendungen bereitstellen, wobei die Anwendungen auf Servern gespeichert sind, die dem Anwendungsentwickler oder dem Dienstanbieter zugehörig sind, jedoch kann auf die Anwendungen über den Host zugegriffen werden. Ein partielles oder aufgeteiltes Hosting von Anwendungen unterscheidet sich von Portalanwendungen, die auf Servern gespeichert sind, welche dem Anwendungsentwickler oder dem Dienstanbieter zugehörig sind, auf die jedoch nicht über den Host zugegriffen wird. Endbenutzer greifen auf die von anderen Parteien und Firmen angebotenen Dienste über den Host durch Interagieren mit den gehosteten und teilweise gehosteten Anwendungen zu.
  • Das Netz 100 beinhaltet auch Benutzer 120, 122, 124, die, wie dargestellt, mit dem Host-Server 110 sowie untereinander im Netz 100 verbunden sind. In 1A können Benutzer 120, 122, 124 Dienstanbieter sein, welche Dienste zur Nutzung durch Endbenutzer anbieten. Die Benutzer 120, 122, 124 können auch Anwendungsentwickler sein, welche zu den Dienstanbietern gehören oder mit diesen assoziiert sind. Die Dienstanbieter, die Anwendungsentwickler und weitere Parteien erzeugen und pflegen Anwendungen, die Teil eines Dienstes sind, der Endbenutzern angeboten wird.
  • Die Anwendungen, die Teil eines Dienstes sind, können durch den Hosting-Provider beispielsweise auf einem Host-Server 110 gehostet werden. Die Anwendungen können auch teilweise gehostet sein, indem sie bei einem einem Benutzer zugehörigen Server gespeichert werden, wie anhand einer Anwendung 126 dargestellt, die sich bei einem Benutzer 124 befindet und indem auf sie über den Hosting-Provider, beispielsweise über den Host-Server 110, zugegriffen wird.
  • B. Spezifische Anpassung von durch einen Dienst bereitgestelltem Inhalt
  • 1A stellt auch Endbenutzer 130, 132, 134 dar, die mit dem Host-Server 110 über Verbindungen 140, 142, 144 verbunden sind. Auch wenn die Endbenutzer 130, 132, 134 in 1 als extern zum Netz 100 dargestellt sind, können die Benutzer 130, 132, 134 oder weitere nicht dargestellte Endbenutzer ebenfalls Teil des Netzes 100 sein. Es gibt zahlreiche unterschiedliche Typen von Endbenutzern und Verbindungen. Beispielsweise kann ein Endbenutzer 130 ein Desktop-Computer sein, der mit dem Host-Server 110 auf viele unterschiedliche Arten verbunden ist, beispielsweise über das Internet, eine DSL-Verbindung oder eine ISDN-Verbindung. Auch kann es sich bei einem Endbenutzer 132 um ein PDA handeln, das mit dem Host-Server 110 über eine zellulare Modemverbindung verbunden ist. Weiter kann der Endbenutzer 134 ein Mobiltelefon sein, das mit dem Internet, und dadurch mit dem Host-Server 110, über ein WAP-zu-HTTP-Gateway verbunden ist.
  • 1A zeigt auch eine Verbindung 150 zwischen einem Endbenutzer 130 und einem Benutzer 120, sowie eine Verbindung 152 zwischen einem Endbenutzer 134 und einem Benutzer 124. Die Verbindungen 150 und 152 erlauben eine direkte Kommunikation zwischen den Endbenutzern und den Benutzern, wodurch illustriert wird, dass nicht alle Verbindungen zwischen Endbenutzern und Benutzern über den Host-Server 110 verlaufen. Beispielsweise kann der Endbenutzer 130 ein Desktop-Computer sein und ist daher beim Anfordern eines Dienstes in der Lage, direkt mit einem Benutzer 120 zu interagieren. Jedoch kann der Dienst, den der Endbenutzer 130 vom Benutzer 120 anfordert, durch eine gehostete Anwendung geliefert werden, die sich auf dem Host-Server 110 befindet. Reagierend auf die Dienstanfrage vom Endbenutzer 130, kann ein Benutzer 120 über eine Verbindung eine Anfrage an den Host-Server 110 senden, den Endbenutzer 130 mit einer Ausgabe von der gehosteten Anwendung zu beliefern, welche die Anfrage erfüllt. Reagierend auf die Anfrage vom Benutzer 120, kann dann der Host-Server 110 die geeignete gehostete Anwendung ausführen und die sich ergebende Ausgabe über Verbindung 140 an den Endbenutzer 130 senden.
  • Als weiteres Beispiel kann es sich bei Endbenutzer 134 um ein Mobiltelefon handeln, das mit dem Host-Server 110 interagiert. Der Endbenutzer 134 kann über den Host-Server 110 einen Dienst anfordern, der durch eine aufgeteilt gehostete Anwendung bereitgestellt wird, beispielsweise eine Anwendung 126, die von einem Benutzer 124 geliefert wird. Der Host-Server 110 leitet dann die Dienstanfrage vom Endbenutzer 134 zum Benutzer 124 weiter. Der Benutzer 124 führt dann die geeignete Anwendung, beispielsweise Anwendung 126, aus und sendet die sich daraus ergebende Ausgabe über Verbindung 152 an den Endbenutzer 134.
  • 1A stellt ein repräsentatives Ausführungsbeispiel eines Systems dar, welches ein netzbasiertes Betriebssystem für mobile Geräte bereitstellt, hingegen können in der Praxis viel größere und komplexere Netze verwendet werden, welche gegenüber der in 1A dargestellten Konfiguration zahlreiche Variationen aufweisen. Beispielsweise kann ein netzbasiertes Betriebssystem für Mobilgeräte mehr als einen dem Host zugehörigen Server und eine praktisch unbegrenzte Anzahl von Benutzern und Endbenutzern umfassen. Außerdem ist es möglich, dass sich nicht alle Benutzer in einem einzigen Netz wie beispielsweise Netz 100 befinden. Stattdessen können sich die Benutzer in vielen Netzen befinden, einschließlich des Internets und mehreren Intranets. In ähnlicher Weise können sich Endbenutzer in einem Netz befinden, dass auch den Host-Server und einen oder mehrere Benutzer beinhaltet. Außerdem kann der Host-Provider Endbenutzern Dienste direkt anbieten, zusätzlich dazu, dass er ein Hosten von Anwendungen für andere durchführt. Weiter sind die zuvor erörterten Typen von Endbenutzern, Benutzern und Verbindungen lediglich repräsentative Beispiele.
  • 1B ist ein Blockdiagramm, welches eine Übersicht des Host-Servers 110 gemäß einem Ausführungsbeispiel der Erfindung darstellt. Der Host-Server 110 beinhaltet Anwendungen 160, 162, bei denen es sich um gehostete Anwendungen, die auf dem Host-Server 110 gespeichert sind, oder um Links zu aufgeteilt gehosteten Anwendungen handeln kann, die auf anderen Servern gespeichert sind, ähnlich Anwendung 126.
  • Der Host-Server 110 beinhaltet einen Middleware-Transformer 112, welcher eine Anwendungsausgabe in eine Ausgabe umwandelt, welche basierend auf einer Dienstanfrage zugehörigen Parametern oder Bedingungen individuell angepasst oder zugeschnitten wird. Beispielsweise können die Fähigkeiten der von den Endbenutzern verwendeten Client-Geräte stark variieren. Gemäß einem Ausführungsbeispiel gestaltet der Anwendungsentwickler die Anwendung so, dass sie eine generische Ausgabe erzeugt, welche mehrere – auch als Ausgabesegmente bezeichnete – Ausgabevariationen beinhaltet, um die Ausgabe auf dem Client- Gerät zu präsentieren oder anzuzeigen. Die generische Ausgabe wird vom Middleware-Transformer 112 empfangen. Der Middleware-Transformer 112 empfängt oder erfasst auch die mit der Dienstanfrage verbundenen Parameter oder Bedingungen. Der Middleware-Transformer 112 wählt dann, basierend auf den der Dienstanfrage zugehörigen Parametern oder Bedingungen eine spezielle Ausgabevariation oder -option aus.
  • Beispielsweise kann es sich bei dem Client oder Endbenutzer um ein Mobiltelefon handeln, das Fahrtinstruktionen von einem Landkarten-Dienstanbieter anfordert. Möglicherweise ist das Mobiltelefon nicht zu einer graphischen Darstellung in der Lage, und daher braucht der Landkarten-Dienstanbieter lediglich eine Anfrageantwort zu liefern, die zur Darstellung der gewünschten Fahrtroute Text und keine graphischen Elemente beinhaltet. Jedoch kann der Landkarten-Dienstanbieter weitere Kunden haben, die andere Geräte verwenden, beispielsweise Laptop-Computer, die zusätzlich zu Text auch zur Anzeige von Grafikelementen in der Lage sind.
  • Die vom Landkarten-Dienstanbieter verwendete Anwendung kann daher eine generische Ausgabe erzeugen, die mehrere Variationen der angeforderten Instruktionen beinhaltet, beispielsweise ein Ausgabesegment, welches lediglich Text enthält, und ein anderes, welches Text und graphische Elemente enthält. Die Anwendung liefert die generische Ausgabe an den Middleware-Transformer 112, welcher auch Parameter oder Informationen von der Anfrage empfängt, beispielsweise Daten, welche anzeigen, dass es sich bei dem Client-Gerät um ein Mobiltelefon handelt. Der Middleware-Transformer 112 wählt dann aus der generischen Ausgabe dasjenige Ausgabesegment aus, welches lediglich Text enthält, und erzeugt eine spezifisch angepasste Ausgabe, welche das lediglich Text umfassende Ausgabesegment der Anwendung enthält, und dann sendet der Middleware-Transformer die spezifisch angepasste Ausgabe an den Endbenutzer. Bei einem weiteren Ausführungsbeispiel erzeugt die Anwendung einen umfassenden Satz von Ausgabeinformation, basierend auf einem Style-Sheet (Formatspezifikation), das auf Basis des Client-Gerätes gewählt wird.
  • Der Lösungsansatz, bei dem ein Host verwendet wird, welcher eine generische Ausgabe empfängt und eine spezifisch angepasste Ausgabe erzeugt, bietet mehrere Vorteile. Beispielsweise braucht der Anwendungsentwickler nicht mehrere Anwendungen, oder unterschiedliche Ausgaberoutinen, für jede spezifische Bedingung zu schreiben, für die Änderungen der Ausgabe angezeigt scheinen. Tatsächlich braucht der Anwendungsentwickler nicht einmal in der Lage zu sein, auf diese Bedingungen hin zu testen. Vielmehr kann der Anwendungsentwickler für jede der speziellen Bedingungen lediglich eine einzige Anwendung mit Ausgabevariationen schreiben, die das spezielle Modell des Client-Gerätes, den Typ des Client-Gerätes und eine breit oder eng gefasste Klasse des Client-Gerätes, die Netzbedingungen etc. beinhalten kann. Bei einer Einführung von neuen Geräten und Fähigkeiten kann der Middleware-Transformer die Ausgabevariation auswählen, welche für die Fähigkeiten der neuen Client-Geräte am besten passt.
  • Als weiteres Beispiel können die Ausgabesegmente von den zum Zeitpunkt der Anfrage vorliegenden Bedingungen abhängen, beispielsweise eine Netzüberlastung, der Zeitpunkt der Anfrage oder der Ort des Benutzers, was es dem Middleware-Transformer ermöglicht, unter Berücksichtigung dieser Bedingungen eine Ausgabevariation auszuwählen oder die Ausgabe zu formatieren. Daher kann der Anwendungsentwickler die Anwendung so gestalten, dass sie eine generische Ausgabe liefert, welche Ausgabesegmente für jede von einer Vielzahl unterschiedlicher Bedingungen beinhaltet, und dann dem Host erlauben, die spezielle Ausgabe auszuwählen, welche dem Endbenutzer basierend auf den speziellen Bedingungen für die spezielle Anfrage geliefert werden soll.
  • C. Bereitstellung von Inhalt von Mehrfachdiensten
  • Der Host-Server 110 beinhaltet auch einen Dienste-Linker 114, welcher Dienstanfragen von Endbenutzern abwickelt und die Anfragen zur Beantwortung an den geeigneten Dienst oder Anwendung weiterleitet. Außerdem kann der Dienste-Linker 114 die Session (oder Transaktion) von anderen Diensten aktiv halten. Beispielsweise kann ein Endbenutzer ein Mobiltelefon sein, das mit dem Host kommuniziert. Der Host liefert dem Endbenutzer eine Liste von Optionen, die einen Landkarten-Dienst beinhalten kann. Wenn der Endbenutzer den Landkarten-Dienst unter Verwendung des Mobiltelefons auswählt, empfängt der Dienste-Linker 114 die Anfrage vom Endbenutzer und leitet die Anfrage an den Anbieter des geeigneten Dienstes weiter. Wenn beispielsweise der Dienst unter Verwendung einer aufgeteilt gehosteten Anwendung geliefert wird, kann die Anfrage zu einem dem Landkarten-Dienstanbieter zugehörigen Server über das World Wide Web weitergeleitet werden. Die Antwort auf die Anfrage der aufgeteilt gehosteten Anwendung kann dann beim Host in Form einer generischen Ausgabe empfangen werden, die speziell für das Mobiltelefon angepasst ist, beispielsweise wie zuvor erläutert unter Verwendung eines Middleware-Transformers.
  • In einem weiteren Ausführungsbeispiel sind in Anwendungen die Leistungsmerkmale und Ausgaben weiterer Anwendungen integriert. Die Anwendungen können auch als mobile Module oder einfach als Module bezeichnet werden. Wenn beispielsweise Anwendung 160 in 1B Landkarteninstruktionen bereitstellt, möchte der Landkarten-Dienstanbieter möglicherweise auch Information betreffend das Wetter an dem vom Endbenutzer angegebenen Zielort mitschicken. Anstatt eine separate Wetteranwendung zu entwickeln, kann der Landkarten-Dienstanbieter einen Link zu einer anderen gehosteten oder aufgeteilt gehosteten Anwendung setzen, die von einem Wetterinformations-Dienstanbieter bereitgestellt wird, der mit dem Host-Server 110 in Verbindung steht. Beispielsweise kann die Anwendung 162 eine Wetteranwendung oder ein Modul sein, das von einer anderen Firma als der den Landkartendienst bereitstellenden Firma bereitgestellt wird. Da jedoch beide Firmen Module haben, die dem Host-Server zugehörig sind, können beide einen Link zu den Modulen der anderen Firma in der Ausgabe ihrer Anwendung beifügen. Basierend auf den Links kann der Middleware-Transformer eine Ausgabe der einen Anwendung in eine andere Anwendung integrieren, oder dem Endbenutzer kann ein Link präsentiert werden, um ihm einen Zugriff auf die Leistungsmerkmale des anderen Dienstes zu ermöglichen.
  • Außerdem kann, da der Host-Server die Interaktion zwischen den zwei Diensten abwickelt, der Host zurück verfolgen, welche Module sich gegenseitig aufrufen, um eine Rechnungsstellung zwischen den Diensten zu erleichtern. Außerdem erlaubt dieses Zurückverfolgungsmerkmal, dass das eine Modul ein anderes Modul zurückruft, ohne dass es die Identität des anderen Moduls kennt. Wenn beispielsweise ein erstes Modul ein zweites Modul aufruft, erlaubt das Zurückverfolgungsmerkmal dem zweiten Modul, das erste Modul zurückzurufen. Demzufolge kann ein beliebiger Dienst als Modul verwendet werden, was sich so beschreiben lässt, dass ein wiederverwendbarer Web-Dienst für weitere Dienste bereitgestellt wird.
  • D. Zugriff auf bei einer Zwischenstation gespeicherte Daten von einem Dienst
  • Der Host-Server 110 beinhaltet auch eine Datenbank 170, um ein Speichern von Daten beim Host durch die Dienste für eine Verwendung durch die Anwendungen dieser Dienste zu unterstützen. Auch wenn die Datenbank 170 als Teil des Host-Servers 110 dargestellt ist, kann die Datenbank 170 durch einen weiteren Server oder ein weiteres Gerät unterstützt werden, der oder das sich zum Bereitstellen von Datenbankfunktionen eignet. Die Datenbank 170 kann eine Datenstruktur für ein Speichern von Daten und auch für ein Mapping von Variablen oder Kennungen auf spezielle Daten oder Informationselemente beinhalten. Die Dienste können die Datenbank 170 verwenden, um Information beim Host-Server dauerhaft zu speichern und zu pflegen, wodurch die Dienste vom Zwang befreit sind, eine derartige Datenbank selber zu unterstützen. Beispielsweise kann eine Anwendung eine Ausgabe mit einer Kennung "%xyzlogo" erzeugen, das im in der Datenbank 170 gespeicherten Mapping als einem speziellen graphischen Bild der XYZ-Firma zugeordnet identifiziert ist. Als weiteres Beispiel kann die Ausgabe der Anwendung "%date" beinhalten, um das aktuelle Datum anzuzeigen, wenn auf die Anwendung reagierend auf eine Anfrage eines Endbenutzers zugegriffen wird. Beim Empfangen der Ausgabe beim Middleware-Transformer wird das aktuelle Datum anstelle der Variablen %date in die Ausgabe eingesetzt.
  • E. Online-Entwicklung von Anwendungen
  • Der Host-Server 110 beinhaltet auch eine Online-Software-Entwicklungsbibliothek 116, die Dienste und Anwendungen bereitstellt, die Entwickler verwenden können, um Anwendungen oder Module, die dem Hosting-Dienst zugehörig sind, zu konzipieren, zu bearbeiten, zu testen, zu entwickeln und anderweitig zu verwalten. Gemäß einem Ausführungsbeispiel verwendet ein Anwendungsentwickler einen Browser, um sich in eine Online-Entwicklungs-Website einzuloggen, die dem Hosting-Dienst zugehörig ist, um auf die Online-Software-Entwicklungsbibliothek 116 zuzugreifen. Nach dem Einloggen stellt die Online-Software-Entwicklungsbibliothek 116 eine Benutzerschnittstelle zum Anzeigen auf dem Web-Browser des Entwicklers bereit. Die Benutzerschnittstelle präsentiert dem Benutzer verschiedene Optionen, beispielsweise das Erzeugen einer neuen Anwendung, das Modifizieren einer bestehenden Anwendung, das Testen einer Anwendung oder das Löschen einer bestehenden Anwendung. Beispielsweise führt der Anwender, um eine gehostete Anwendung zu erzeugen, eine Eingabe oder eine Modifikation von Programmcode unter Verwendung der Benutzerschnittstelle über den Browser des Entwicklers durch und speichert dann den Code beim Host-Server 110 unter einem Modul- oder Anwendungsnamen oder einer Kennung ab. Wenn der Entwickler eine aufgeteilt gehostete Anwendung einrichten möchte, loggt er sich in die Online-Entwicklungs-Website ein und gibt die URL der Anwendung ein. Die gehosteten und aufgeteilt gehosteten Anwendungen können dann unmittelbar zur Verfügung gestellt werden. Beispielsweise können sich Endbenutzer über eine Website beim Dienstanbieter einloggen, um auf eine Liste von verfügbaren Diensten zuzugreifen.
  • II. ONLINE-ENTWICKLUNG VON ANWENDUNGEN
  • A. Erzeugung von Anwendungen und Diensten – Überblick
  • Gemäß einem Ausführungsbeispiel verwendet ein Entwickler einen auf einem Client laufenden Browser, um sich in eine Website einzuloggen, über die der Entwickler dann auf die erforderlichen Tools zugreifen kann, um eine Anwendung ohne irgendeine spezielle client-seitige SDK-Software zu entwickeln. Die Website kann als Entwicklungs-Website oder "SDK-Website" bezeichnet werden, wenn die Website beispielsweise eine Online-Software-Entwicklungsbibliothek (SDK) bereitstellt oder hostet.
  • Wie hier verwendet, ist die Bezeichnung "Entwickler" synonym sowohl mit "Dienstanbieter" als auch "Benutzer" (da der Entwickler die Online-Entwicklungs-Website 'benutzt'). Außerdem unterscheidet sich ein "Benutzer" von einem Endbenutzer oder Kunden, der den vom Entwickler bereitgestellten Dienst verwendet.
  • Der Anbieter der Anwendungsentwicklungstools und Host der Online-Entwicklungs-Website kann als Entwicklungsanbieter, SDK-Anbieter, oder einfach als Host bezeichnet werden. Der Entwicklungsanbieter verwendet typischerweise einen oder mehrere Server, um die Entwicklungs-Website und die durch diese bereitgestellten Tools zu unterstützen.
  • Der Zugriff auf die Entwicklungs-Website kann dadurch gesteuert werden, dass der Benutzer einen Namen und ein Passwort haben muss. Nachdem der Benutzer Zugang zur Website erlangt hat, kann ihm eine Liste von mobilen Anwendungen (hier auch als Dienste bezeichnet) präsentiert werden, die der Entwickler oder Benutzer zuvor erzeugt hat. Der Benutzer kann auch Zugang zu weiteren Diensten haben, beispielsweise Testexemplaren, die vom Entwicklungs-Website-Anbieter bereitgestellt werden. Die Entwicklungs-Website kann dem Benutzer mehrere Optionen anbieten, beispielsweise einen neuen Dienst hinzuzufügen, einen bestehenden Dienst zu modifizieren oder einen bestehenden Dienst zu löschen. Wenn beispielsweise der Benutzer die "Dienst hinzufügen"-Option auswählt, wird dem Benutzer eine Benutzerschnittstelle präsentiert, welche dem Benutzer das Hinzufügen eines Dienstes erlaubt.
  • Gemäß einem Ausführungsbeispiel kann ein Dienst entweder eine gehostete Anwendung oder eine Portalanwendung sein. Eine gehostete Anwendung ist eine Anwendung, deren Code bei der Entwicklungs-Website, auch als Host-Website bezeichnet, gepflegt wird. Eine Portalanwendung ist eine Anwendung, deren Code bei einer anderen Website gepflegt wird, die mit dem Portalanwendungsentwickler in Verbindung steht und auf die typischerweise über die Website des Entwicklers von Kunden oder Endbenutzern zugegriffen wird. Jedoch kann gemäß einem weiteren Ausführungsbeispiel der Zugriff auf eine Portalanwendung oder das Liefern von dieser an Clients auch über die Entwicklungs-Website erfolgen, in welchem Fall die Portalanwendung als "aufgeteilte gehostete Anwendung" oder "teilweise gehostete Anwendung" bezeichnet werden kann.
  • B. Entwicklung einer gehosteten Anwendung
  • Das Entwickeln einer gehosteten Anwendung kann mehrere Schritte umfassen, beispielsweise wird zu Anfang die Anwendung konzipiert, anschließend die Anwendung bearbeitet und die Anwendung getestet. In einem Ausführungsbeispiel stellt die Entwicklungs-Website zur Erzeugung einer gehosteten Anwendung dem Entwickler oder Benutzer eine Schnittstelle zum Schreiben und Bearbeiten von Code für die Anwendung bereit. Die Schnittstelle kann ein Bearbeitungsfenster oder ein Bearbeitungsfeld beinhalten, das der Benutzer verwenden kann, um eine Tastatureingabe des Codes für die Anwendung vorzunehmen. In ähnlicher Weise wird zum Bearbeiten einer bestehenden Anwendung dem Benutzer eine Schnittstelle geboten, welche den bestehenden Anwendungscode dem Benutzer in einem Bearbeitungsfenster anzeigt, das dem Benutzer ein Bearbeiten des Codes der gewählten Anwendung ermöglicht.
  • Anwendungscode kann in einer geeigneten "Markup-Sprache" (Auszeichnungssprache – ML), wie beispielsweise XML (Extensible Markup Language – erweiterbare Auszeichnungssprache) geschrieben sein. Gemäß einem Ausführungsbeispiel ist der Code in einer Markup-Sprache geschrieben, die hier als "Portal-to-go-XML" bezeichnet wird. Die "Portal-to-go"-Sprache und die "Portal-to-go-XML"-Sprache wird auch als Oracle9iASWireless-Sprache bzw. Oracle9iASWireless-XML-Sprache (oder einfach IASWireless XML) bezeichnet.
  • Portal-to-go-XML besteht aus einem Satz von XML-Tags, die verwendet werden können, um Grenzen zwischen alternativen Ausgabesegmenten anzuzeigen. Jedes Ausgabesegment in einem Satz von Ausgabesegmenten kann speziell für bestimmte Geräte ausgelegt sein, beispielsweise Mobilgeräte, die typischerweise kleine Bildschirme haben, sowie weitere mit Sprachfähigkeiten.
  • Portal-to-go-XML kann mittels einer beliebigen der herkömmlichen Einrichtungen zur Erzeugung von dynamischem HTML erzeugt werden, beispielsweise Java-Server Pages, CGI oder Active Server Pages, derart, dass anstelle einer Erzeugung von HTML durch den Code oder Script eine Erzeugung von Portal-to-go-XML erfolgt. Die Details einer derartigen Markup-Sprache wie beispielsweise Portal-to-go-XML kann in einer Dokumenttyp-Definition (DTD) definiert sein. Beispielsweise findet sich eine Beschreibung einer DTD von einer Portal-to-go- XML, wie implementiert in einem Ausführungsbeispiel, in der provisorischen US-Anmeldung, Seriennummer 60/230,489, eingereicht am 6. September 2000.
  • Gemäß einem weiteren Ausführungsbeispiel wird sowohl der Anwendungscode für eine gehostete Anwendung als auch der Code, welcher die Erzeugung der Benutzerschnittstelle bewirkt, die zum Eingeben und Bearbeiten des Codes verwendet wird, auf einem oder mehreren mit dem Entwicklungsanbieter in Verbindung stehenden Servern gespeichert. Demzufolge ist die einzige clientseitige Software, die zum Entwickeln und einsetzbar Machen einer mobilen Anwendung benötigt wird, ein Web-Browser wie beispielsweise Netscape Navigator.
  • Wenn der Benutzer das Eingeben des Codes für eine neue Anwendung oder das Bearbeiten des Codes für eine bestehende Anwendung beendet, kann er den in der Schnittstelle dargestellten Code speichern. Die "Code speichern"-Funktion kann ein in der Schnittstelle enthaltenes Objekt wie beispielsweise eine Schaltfläche sein. Durch Anklicken des Objektes wird der Code an einen vom Server entfernt befindlichen Client weitergegeben oder gesendet, beispielsweise einen mit dem Entwicklungsanbieter in Verbindung stehenden Server. Wenn eine neue Anwendung erzeugt wird, legt der Benutzer einen Dienstnamen fest und der Code wird in Verbindung mit diesem Dienstnamen gespeichert. Nach dem Speichern des neuen Codes wird der neue Dienstname in einer Liste bestehender Dienste angezeigt, wenn sich Benutzer und Endbenutzer in die Entwicklungs-Website einloggen. Wenn eine bestehende Anwendung modifiziert wird, kann der Benutzer wählen, den Code unter dem bestehenden Dienstnamen oder unter einem neuen Dienstnamen zu speichern.
  • Um die Anwendung zu testen, kann der Benutzer auf die Anwendung oder den Dienst über die Entwicklungs-Website unter Verwendung eines Mobilgerätes oder eines Mobilgerät-Simulators zugreifen. Dies wird später noch detaillierter unter "Zugreifen auf die neue Anwendung oder Dienst" erörtert. Die gehostete Anwen dung, die über die Entwicklungs-Website eingesetzt wird, steht über die Host-Website dem Benutzer für ein Testen und den Endbenutzern für eine Verwendung unmittelbar zur Verfügung.
  • C. Entwicklung einer aufgeteilt gehosteten Anwendung
  • Bei einem weiteren Ausführungsbeispiel schreibt der Benutzer, um eine aufgeteilt gehostete Anwendung zu erzeugen, entweder ein Portal-to-go-XML-Dokument oder ein Anwendungsprogramm, das ein Portal-to-go-XML-Dokument als Ausgabe erzeugt. Die Begriffe "teilweise gehostete Anwendung" oder "aufgeteilt gehostete Anwendung" können verwendet werden, um entweder auf das XML-Dokument oder die Anwendung Bezug zu nehmen, welche ein XML-Dokument als Ausgabe erzeugt. Die aufgeteilt gehostete Anwendung kann beispielsweise auf der dem Anwendungsentwickler selbst gehörenden Website gespeichert werden. Der Benutzer verknüpft dann eine URL mit der aufgeteilt gehosteten Anwendung, beispielsweise unter Verwendung eines HTTP-Listeners/Web-Servers, der die Website des Anwendungsentwicklers bedient. Die aufgeteilt gehostete Anwendung wird dann als "Dienst" hinzugefügt, dadurch dass ein Einloggen in die Entwicklungs-Website oder die SDK-Website durchgeführt wird und der Name des Dienstes und die mit der aufgeteilt gehostete Anwendung verbundene URL eingegeben wird.
  • D. Zugriff auf die neue Anwendung oder den neuen Dienst
  • Sobald ein Dienst erzeugt wurde und/oder überarbeitet wurde, können Endbenutzer oder Kunden, die sich mit dem Netz verbinden können, in dem sich der Server befindet (z.B. dem Internet), auf den Dienst zugreifen. Das Verfahren, durch das auf den Dienst zugegriffen wird, kann basierend auf dem Typ des Endbenutzers variieren. Beispielsweise kann sich ein Desktop-Computer mit dem Internet über eine Einwahlverbindung, eine DSL-Verbindung, ein Kabelmodem, eine ISDN-Verbindung oder viele weitere zur Verfügung stehende Verfahren verbinden.
  • WAP-Telefone können sich mit dem Internet über eine drahtlose Verbindung unter Verwendung eines synchronen Protokolls verbinden, beispielsweise über ein WAP-zu-HTTP-Gateway, oder unter Verwendung eines asynchronen Protokolls, wie beispielsweise des SMTP (Simple Mail Transfer Protocol) oder des SMS-(Short Message Service)-Protokoll.
  • Im Allgemeinen loggt sich der Endbenutzer in die Entwicklungs-Website ein und es wird ihm eine Liste von verfügbaren Diensten angeboten. Der Endbenutzer kann den Dienst auswählen, der gerade erzeugt und/oder modifiziert wurde. Reagierend auf die Auswahl eines Dienstes wird die dem Dienst zugehörige Anwendung erzielt. Die Anwendung kann mit einem Portal-to-go-XML-Dokument oder einem anderen in einer geeigneten Markup-Sprache geschriebenen Dokument verbunden sein. Beispielsweise kann bei gehosteten Anwendungen das XML dadurch erzielt werden, dass das Portal-to-go-XML geladen wird, das bei einem Server gespeichert ist, der mit der Zwischenstation (z. B. dem Host) in Verbindung steht. Für Portalanwendungen kann eine Anfrage an die vom Entwickler für den Dienst spezifizierte URL gesendet werden. Der Web-Server, welcher die URL verwaltet, kann sich an die Portalanwendung wenden und die der Portalanwendung zugehörige Portal-to-go-XML an den mit der Zwischenstation in Verbindung stehenden Server zurückschicken. Sobald die Portal-to-go-XML für den Dienst entweder für eine gehostete oder eine Portalanwendung erhalten wurde, verwendet der mit der Zwischenstation in Verbindung stehende Server die Portal-to-go-XML, um den gewählten Dienst an den zum Endbenutzer gehörigen Client zu liefern.
  • III. GENERIEREN VON GERÄTESPEZIFISCHEM MARKUP-CODE
  • A. Generieren einer gerätespezifischen Formatierung
  • Gemäß einem Ausführungsbeispiel wird eine Ausgabe in der Markup-Sprache, beispielsweise Portal-to-go-XML, durch einen Dienst ungeachtet des Typs des Client-Gerätes erzeugt, welches den Dienst anfordert. Gemäß einem Ausführungsbeispiel werden, bevor die Ausgabe an einen Client geliefert wird, eine oder mehrere XSL-(Extensible Stylesheet Language)-Style-Sheets basierend auf dem Gerätetyp des Client ausgewählt. XSL-Style-Sheets sind detaillierter in der US-Anmeldung, Seriennummer 09/631,884, eingereicht am 4. August 2000, erläutert, deren gesamter Offenbarungsgehalt hiermit durch Bezugnahme in das vorliegende Dokument aufgenommen wird, als ob er vollständig darin wiedergegeben wäre.
  • Die ausgewählten Style-Sheets werden auf das vom Dienst ausgegebene XML angewandt, um eine spezifisch angepasste Ausgabe zu liefern, die speziell für den Client formatiert ist, welcher den Dienst angefordert hat. Beispielsweise kann sich die gleiche XML-Ausgabe einer mobilen Anwendung am Ende auf die folgenden drei Arten manifestieren, und zwar in Abhängigkeit vom Typ des Client, der den Dienst angefordert hat: (1) eine Liste von Optionen auf der Anzeige eines Mobiltelefons, (2) ein Pull-down-Menü in einem Browser und (3) eine von der Sprachschnittstelle eines Telefons mündlich dargebotene Liste von Optionen. Der Anwendungsentwickler erzielt eine Unterstützung eines beliebigen Gerätes, ohne dass er irgendeine spezielle Programmierung auszuführen braucht, da die Anwendungen so ausgelegt sind, dass sie die gleiche XML-Ausgabe ungeachtet des zur Anforderung des Dienstes verwendeten Gerätes erzeugen, und da die gerätespezifische Formatierung außerhalb der Anwendungen erfolgt, beispielsweise durch dazwischen geschaltete gerätespezifische XSL-Style-Sheets.
  • Da weiter die Ausführung des Codes und die Anwendung der XSL-Style-Sheets auf dessen Ausgabe über den Host erfolgen, erzielen alle gehosteten Anwendungen und Portalanwendungen automatisch eine gerätespezifische Unterstützung für neue Geräte, sobald auf dem Host die XSL-Style-Sheets für die neuen Geräte installiert sind. Der Anwendungsentwickler braucht keine Änderungen am Anwendungscode vorzunehmen, um beliebige zusätzliche oder neu entwickelte Client-Geräte zu unterstützen. Selbstverständlich kann der Entwickler, wenn er verbesserte oder hinzugekommene Fähigkeiten ausnützen möchte, die Anwendung aktualisieren, um zusätzliche Ausgabesegmente oder Variationen für derartige Fähigkeiten bereitzustellen.
  • B. Erzeugung einer Ausgabe, die Anfragebedingungen berücksichtigt
  • Ein weiteres Problem beim Bereitstellen von Diensten mittels Anwendungen besteht darin, dass die Funktion der Anwendungen unveränderlich ist, ungeachtet der spezifischen Bedingungen, die zum Zeitpunkt der Verwendung der Anwendungen bestehen. Beispielsweise kann es erwünscht sein, die Ausgabe der Anwendung basierend auf der Auslastung des Netzes zum Zeitpunkt eines Zugriffs auf die Anwendung durch den Benutzer zu modifizieren. Wenn das Netz stark ausgelastet ist, kann es besser sein, den in der Ausgabe bereitgestellten Detailumfang zu begrenzen, der während solcher Zeiten starker Auslastung bereitgestellt wird. Wiederum kann der Anwendungsprogrammierer hier den Lösungsansatz des kleinsten gemeinsamen Nenners verwenden und die Anwendung für "Worst-Case"-Bedingungen auslegen. Jedoch wird bei diesem Lösungsansatz versäumt, bessere Bedingungen zu nutzen, wenn diese zu anderen Zeiten gegeben sind. Wenn der Programmierer ein höheres Detailniveau wählt, dann leidet die Fähigkeit der Anwendung, dem Client-Gerät in Zeiten starker Netzauslastung eine Ausgabe zu liefern.
  • Verfahren sind vorgesehen, um eine Ausgabe zu erzeugen, welche mit einer Dienstanfrage verbundene Bedingungen, Parameter und besondere Merkmale berücksichtigt (welche auch als "Anfragebedingungen" bezeichnet werden). Anfragebedingungen können beispielsweise Information über den Typ des Client beinhalten, der den Dienst anfordert, beispielsweise einen Gerätetyp oder Umgebungsbedingungen, beispielsweise die Zeit, zu der die Dienstanfrage erfolgt oder zu der dieser entsprochen wird, oder die Auslastung des Netzes, über das der Dienst angefordert oder bereitgestellt wird.
  • Gemäß einem Ausführungsbeispiel erzeugt ein Anwendungsprogramm unverändert die gleiche Ausgabe, ungeachtet der Anfragebedingungen. Da die Ausgabe der Anwendung ungeachtet der Anfragebedingungen die gleiche ist, wird auf sie hier als "bedingungsunabhängige Ausgabe" Bezug genommen.
  • Gemäß einem weiteren Ausführungsbeispiel enthält die von einer Anwendung erzeugte bedingungsunabhängige Ausgabe "Hinweise" (oder Kriterien, Bedingungen und weitere Richtlinien), wie die Ausgabe unter bestimmten Anfragebedingungen bearbeitet werden sollte. Ein Middleware-Transformer ist vorgesehen, der die bedingungsunabhängige Ausgabe empfängt und die in dieser enthaltenen Hinweise zusammen mit der Kenntnis des Client und den Anfragebedingungen verwendet, um die bedingungsunabhängige Ausgabe in eine "bedingungsspezifische Ausgabe" umzuwandeln, welche auch als "bedingungsabhängige Ausgabe" bezeichnet werden kann. Die bedingungsspezifische Ausgabe wird dann an den Client geliefert, der den Dienst angefordert hat, welcher die Ausgabe erzeugt hat. Der Middleware-Transformer ist typischerweise dem Host zugehörig und kann durch einen einem Host zugehörigen Server bereitgestellt werden, jedoch ist der Middleware-Transformer nicht auf dem Host zugehörige Implementierungen eingeschränkt.
  • C. Bedingungsunabhängige Ausgabe mit eingebetteten Hinweisen
  • Gemäß einem Ausführungsbeispiel gestalten Anwendungsprogrammierer Anwendungen so, dass sie eine Ausgabe erzeugen, die "Hinweise" enthält, wie die Ausgabe basierend auf den Anfragebedingungen umgewandelt werden sollte. Gemäß einer Implementierung gestaltet der Anwendungsprogrammierer die Anwendungen so, dass sie eine Ausgabe erzeugen, die mehrere Variationen der Ausgabe benennt, wodurch der Anfrage an die Anwendung genügt wird, welche zur Erzeugung der Ausgabe geführt hat. Die Variationen der Ausgabe können auch als alternative Ausgabesegmente bezeichnet werden.
  • Die Ausgabe der Anwendung beinhaltet auch eines oder mehrere Kriterien oder Bedingungen, die jedem der alternativen Ausgabesegmente zugehörig sind. Ein Middleware-Transformer wird verwendet, um das alternative Ausgabesegment auszuwählen, bei dem die beste Übereinstimmung zwischen den Anfragebedingungen und den Kriterien oder Bedingungen besteht, welche jedem alternativen Ausgabesegment zugehörig sind. Eine Übereinstimmung kann basierend darauf bestimmt werden, ob der oder den Bedingungen, die einem speziellen alternativen Ausgabesegment zugehörig sind, genügt wird oder nicht (oder ob die Bedingungen erfüllt sind oder nicht).
  • Wenn beispielsweise die Anwendungsausgabe in Form einer Markup-Sprache, beispielsweise XML, vorliegt, kann die Ausgabe einen Code-Abschnitt beinhalten, welcher folgende Form hat:
    Figure 00320001
  • Die Anwendung erzeugt die obige Ausgabe ohne Berücksichtigung der Anfragebedingungen, die zu dem Zeitpunkt vorhanden sind, bei welchem eine Dienstanfrage durch einen Endbenutzer erfolgt. Der Middleware-Transformer bestimmt, ob irgendwelche der Bedingungen 1, 2 und 3 erfüllt sind, nachdem er die bedingungsunabhängige Ausgabe von der Anwendung empfangen hat. Bei diesem Beispiel führt, wenn Bedingung 1 erfüllt ist, der Middleware-Transformer dann eine Umwandlung der bedingungsunabhängigen Ausgabe durch, um die folgende bedingungsabhängige Ausgabe zu erzeugen:
    Figure 00330001
  • Wenn Bedingung 2 erfüllt ist, jedoch Bedingung 3 nicht erfüllt ist, dann wandelt der Middleware-Transformer die bedingungsunabhängige Ausgabe um, um die folgende bedingungsabhängige Ausgabe zu erzeugen:
    Figure 00330002
  • Wenn Bedingungen 2 und 3 erfüllt sind, dann wandelt der Middleware-Transformer die bedingungsunabhängige Ausgabe um, um die folgende bedingungsabhängige Ausgabe zu erzeugen:
    Figure 00330003
  • Wenn Bedingungen 1 und 2 nicht erfüllt sind, dann wandelt der Middleware-Transformer die bedingungsunabhängige Ausgabe um, um die folgende bedingungsabhängige Ausgabe zu erzeugen:
    Figure 00340001
  • In diesem Beispiel stehen die Bedingungen 2 und 3 in Beziehung zueinander. Speziell wird das Bedingung 3 zugehörige Ausgabesegment nur dann ausgeführt, wenn sowohl Bedingung 2 als auch Bedingung 3 erfüllt sind.
  • Das Verfahren einer Festlegung einer Hierarchie zwischen Bedingungen kann verwendet werden, wenn beispielsweise die eine Bedingung eine Untergruppe einer weiteren Bedingung ist. Beispielsweise kann Bedingung 2 sein, dass das Netz ein ungewöhnliches Verkehrsaufkommen (z.B. Netzauslastung) bezogen auf einem Schwellenwert erfährt, und Bedingung 3 kann darin bestehen, dass der Netzverkehr extrem groß ist, wie durch Überschreiten eines festgelegten Grenzwertes belegt ist. Daher kann bei normaler Netzauslastung, wenn Bedingung 2 erfüllt ist, jedoch nicht Bedingung 3, der tatsächliche Befehl oder die tatsächliche Anweisung, der/die "Verwende dies, wenn Bedingung 2 (condition 2) erfüllt ist und Bedingung 3 (condition 3) nicht erfüllt ist" entspricht, spezifizieren, dass keine ungewöhnlich detaillierten graphischen Elemente übertragen werden sollen. Und, falls Bedingung 3 erfüllt ist, wie dies beispielsweise bei extremer Netzauslastung der Fall sein kann, kann der tatsächliche Befehl oder die tatsächliche Anweisung, der/die "Verwende dies, wenn Bedingung 3 (condition 3) erfüllt ist" entspricht, spezifizieren, dass keine graphischen Elemente übertragen werden sollen.
  • Die Verwendung einer bedingungsunabhängigen Ausgabe mit eingebetteten Hinweisen erlaubt dem Anwendungsentwickler, dass er durch die Gestaltung die Dienstanwendung flexibel macht, so dass sie mit Variablen umgehen kann, die möglicherweise erst zu dem Zeitpunkt bekannt sind, an dem durch einen Client eine Dienstanforderung bei der Anwendung erfolgt. Durch das Einbauen dieser Flexibilität in die Ausgabe der Anwendung werden die Nachteile des Lösungsansatzes des kleinsten gemeinsamen Nenners vermieden, dadurch, dass der Anwendung ermöglicht wird, die Ausgabe für eine optimale Leistungsfähigkeit basierend auf den Umständen anzupassen, die zum Zeitpunkt der Anfrage des Client an die Anwendung vorliegen. Weiter braucht die Anwendung selbst nicht über die Fähigkeit zu verfügen, die Bedingungen zu erfassen, auf deren Basis alternative Ausgabesegmente ausgewählt werden, da der Host die Abwicklung dieser Funktion durchführt.
  • D. Beispiel der Verwendung von eingebetteten Hinweisen zur Identifizierung eines Gerätetyps
  • Zum Zweck der Erläuterung wird nachfolgend eine Implementierung beschrieben, bei der die Bedingungen, die den alternativen Ausgabesegmenten zugehörig sind, der Gerätetyp des anfordernden Clients sind. Bei einer solchen Implementierung kann die durch eine Anwendung erzeugt bedingungsunabhängige Ausgabe folgende Form haben:
    Figure 00350001
    Figure 00360001
  • Die Anwendung erzeugt diese Ausgabe ohne Berücksichtigung der Anfragebedingungen. Bei Empfang der bedingungsunabhängigen Ausgabe von der Anwendung bestimmt der Middleware-Transformer, ob der Client einem der Alternativsegment-Tags entspricht. Falls beispielsweise, bei Verwendung der obigen XML-Ausgabe, der Client ein Desktop-Computer ist, dann stimmt der Client mit dem <desktop>-Tag überein und der Middleware-Transformer wandelt die bedingungsunabhängige Ausgabe um, so dass die folgende bedingungsabhängige Ausgabe erzeugt wird:
    Figure 00360002
  • Falls der Client ein Telefon, jedoch kein WAP-Telefon ist, dann stimmt der Client mit dem <phone>-Tag überein und der Middleware-Transformer wandelt die bedingungsunabhängige Ausgabe um, so dass die folgende bedingungsabhängige Ausgabe erzeugt wird:
    Figure 00360003
  • Falls der Client ein WAP-Telefon ist, dann stimmt der Client sowohl mit dem <phone>-Tag als auch dem <WAP>-Tag überein. Das <WAP>-Tag ist spezifischer als das <phone>-Tag, und daher wandelt der Middleware-Transformer die bedingungsunabhängige Ausgabe um, so dass die folgende bedingungsabhängige Ausgabe erzeugt wird:
    Figure 00370001
  • Falls der Client weder ein Desktop-Computer noch ein Telefon ist, dann stimmt der Client mit keinem der Alternativsegment-Tags überein, und der Middleware-Transformer wandelt die bedingungsunabhängige Ausgabe um, so dass die folgende bedingungsabhängige Ausgabe erzeugt wird:
    Figure 00370002
  • Der Lösungsansatz der Verwendung von eingebetteten Hinweisen, um einen Gerätetyp zu identifizieren, ermöglicht dem Anwendungsentwickler, einen einzigen Code-Satz zu schreiben, der mit allen Geräten verwendet werden kann, jedoch kann der Anwendungscode Alternativsegment-Tags enthalten, um eine spezifische Anpassung der Anwendungsausgabe an unterschiedliche Geräte vorzunehmen, die unterschiedliche Fähigkeiten haben. Im obigen Beispiel können, falls das Client-Gerät ein Desktop-Computer ist, Volltext, graphische Elemente und Toninhalte gesendet werden, da ein Desktop-Computer problemlos alle drei Content-Typen handhaben kann. Falls jedoch das Client-Gerät ein Mobiltelefon ist, dann werden möglicherweise keine graphischen Elemente gesendet, da es ziemlich unwahrscheinlich ist, dass ein Mobiltelefon derartige graphische Elemente auf seiner Anzeige anzeigen kann. Weiter kann, falls es sich bei dem Telefon um ein WAP-Telefon handelt, die Anwendung eine für das WAP-Protokoll spezifische Ausgabe erzeugen.
  • Wenn weiter das Client-Gerät sich nicht unter den aufgelisteten Geräten befindet, kann eine Default-Konfiguration für die Ausgabe verwendet werden (z.B. das obige Alternativsegment-Tag "Verwende dies für jedes andere Gerät"). Eine Default-Bedingung kann eine Ausgabe basierend auf dem Lösungsansatz des kleinsten gemeinsamen Nenners spezifizieren, so dass ein beliebiger Client die Ausgabe handhaben kann. Jedoch braucht der Anwendungsentwickler nicht auf eine derartige Default-Konfiguration zurückzugreifen, wenn es sich bei dem Gerät um eines der speziell unterstützten Typen handelt, beispielsweise ein Desktop-Gerät, ein Telefon oder ein WAP-Telefon. Und schließlich können Client-Geräte, die nach Vollendung der Anwendung konzipiert werden, auch dann eine Ausgabe empfangen, die ihre größeren Fähigkeiten ausnutzt, wenn sie unter einen der spezifizierten Gerätetypen fallen, beispielsweise im zuvor angegebenen Beispiel ein Desktop-Computer oder Telefon. Weiter sind zukünftige Geräte nicht gezwungen, nur deshalb eine sehr einfache oder Default-Ausgabe zu verwenden, weil dem Anwendungsentwickler dieses zukünftige Gerät beim Schreiben des Codes für diesen Dienst nicht bekannt war.
  • E. Erzeugung einer Ausgabe basierend auf einer Bedingungshierarchie
  • Gemäß einem Ausführungsbeispiel wird eine Programmiersprache bereitgestellt, die Alternativsegment-Tags unterstützt, welche Knoten in einer Bedingungshierarchie entsprechen. Der allgemeinste ("höchste") Knoten in der Bedingungshierarchie ist der Default-Knoten. Die anderen Knoten entsprechen speziellen Bedingungen. Die speziellsten Knoten in der Bedingungshierarchie können beispielsweise speziellen Gerätemodellen oder sogar speziellen Versionen spezieller Modelle entsprechen. Weitere mittlere Knoten können Geräteklassen oder -typen entsprechen, beispielsweise Mobiltelefonen oder Pagern.
  • Gemäß einem Ausführungsbeispiel sind die Knoten in der Bedingungshierarchie miteinander in Eltern-Kind-Beziehungen verknüpft, wobei alle Kind-Knoten eines gegebenen Eltern-Knotens Unterkategorien zu der dem Eltern-Knoten zugeordneten Kategorie entsprechen.
  • 2 stellt eine derartige Bedingungshierarchie dar. In 2 ist ein "Alle-Geräte"-Knoten 200 in der dargestellten Hierarchie der höchste oder Default-Knoten. Unter dem "Alle-Geräte"-Knoten 200 befinden sich mehrere Kind-Knoten, speziell ein "Sprache"-Knoten 210, ein "Desktop"-Knoten 212, ein "PDA"-Knoten 214, ein "Pager"-Knoten 216 und ein "Telefon"-Knoten 218, welche weit gefassten Klassifizierungen der Gerätetypen entsprechen, die auf einen Dienst zugreifen können.
  • Der Desktop-Knoten 212 hat auch seine eigenen Kind-Knoten, speziell einen "Unix"-Knoten 220 und einen "Windows"-Knoten 222, die zwei Beispielen von Desktop-Betriebssystemen entsprechen. In ähnlicher Weise weist der Unix-Knoten 220 zwei Kind-Knoten auf, und zwar einen "Solaris"-Knoten 224 und einen "Linux"-Knoten 226, die zwei Versionen des Unix-Betriebssystems entsprechen.
  • In ähnlicher Weise weist der "Telefon"-Knoten 218 mehrere Kind-Knoten auf, speziell einen "WML"-Knoten 230, einen "HDML"-Knoten 232 und einen "CHTML"-Knoten 234, welche jeweils Telefonen entsprechen, die WML (Wireless Markup Language – Auszeichnungssprache für drahtlose Geräte), HDML (Handheld Device Markup Language – Auszeichnungssprache für in der Hand zu haltende Geräte) und CHTML (Compact Hypertext Markup Language – kompakte Hypertext-Auszeichnungssprache) verwenden. In ähnlicher Weise weist der WML-Knoten 230 drei Kind-Knoten auf: einen "Nokia 7110"-Knoten 240, einen "TC 4411 V1"-Knoten 242 und einen "TC 4411 V2"-Knoten 244, welche jeweils einem Mobiltelefon des Modells Nokia 7110 und den Versionen 1 und 2 des Modells TC 4411 entsprechen.
  • Anhand des Beispiels der in 2 dargestellten Bedingungshierarchie kann ein Anwendungsprogrammierer ein Programm gestalten, das für ein Menüelement die folgende Ausgabe erzeugt:
    Figure 00400001
  • Wenn der Middleware-Transformer diese bedingungsunabhängige Ausgabe empfängt, bestimmt der Transformer den Client-Typ, an den die Ausgabe gesendet wird, und erzeugt eine bedingungsspezifische Ausgabe. Insbesondere gilt für alle Clients außer Desktop-Clients (desktop), Sprach-Clients (voice) und Telefon-Clients (phone) das Menüelement "Rückkehr" ("Return"). Für Desktop-Clients, Sprach-Clients und das spezifische Telefonmodell TC 441 V2 lautet das Menüelement "Erzeuge Rückkehranweisungen" ("Generate Return Directions"). Und schließlich lautet für Telefonmodelle, außer TC 441 V2, das Menüelement "Rückk.-Anw." ("Rtrn. Dir."). Die spezielle Behandlung des Modells TC 441 V2 kann beispielsweise erwünscht sein, wenn das TC 441 V2 in der Lage ist, längere Menüelemente als herkömmliche Mobiltelefone anzuzeigen.
  • In einem Ausführungsbeispiel kann, nachdem die bedingungsspezifische Ausgabe erzeugt wurde, ein XSL-Style-Sheet angewandt werden, um die Ausgabe gemäß den Bedürfnissen des Client zu formatieren, an den die Ausgabe gesendet werden soll. In einem alternativen Ausführungsbeispiel formatiert, zusätzlich zur zuvor beschriebenen Verarbeitung der Ausgabe, der Middleware-Transformer die Ausgabe für ein spezifisches Gerät, und zwar entweder durch Anwenden eines oder mehrerer XSL-Style-Sheets, oder durch ein beliebiges anderes Mittel.
  • Damit der Middleware-Transformer die geeignete Umwandlung der Ausgabe durchführt, führt die Partei, welche den Middleware-Transformer steuert, auch bekannt als "Middleware-Host", eine Pflege der Daten durch, welche (1) die Bedingungshierarchie, (2) die Tags, die zu dem Knoten der Bedingungshierarchie gehören, und (3) die Korrelation zwischen dem Knoten der Bedingungshierarchie und den Anfragebedingungen angeben.
  • Beispielsweise sei angenommen, dass der Middleware-Transformer die in 2 dargestellte Bedingungshierarchie unterstützt. Der Middleware-Host kann Daten pflegen, welche verschiedene Typen von Informationen angeben, beispielsweise die Zuordnung der Tags im XML zu den Knoten der Bedingungshierarchie und die Beziehung der Knoten zueinander. Nachstehend sind repräsentative Beispiele der Daten aufgeführt, deren Pflege durch den Middleware-Host erfolgen kann:
    • (a) der Telefon-Knoten 218 ist ein Kind-Knoten des Alle-Geräte-Knotens 200;
    • (b) die Tags <phone> und </phone> sind dem Telefon-Knoten 218 zugeordnet;
    • (c) der WML-Knoten 230 ist ein Kind-Knoten des Telefon-Knotens 218;
    • (d) die Tags <WML> und </WML> sind dem WML-Knoten 230 zugeordnet;
    • (e) der TC 441 V1-Knoten 242 ist ein Kind-Knoten des WML-Knotens 230;
    • (f) die Tags <TC 441 V1> und </TC 441 V1> sind dem TC 441 V1-Knoten 242 zugeordnet; und
    • (g) die Anfragebedingung "Client-Gerät = TC 441 V1" ist dem TC 441 V1-Knoten 242 zugeordnet.
  • Die Bedingungshierarchie kann durch den Dienstanbieter oder den Entwicklungsanbieter entwickelt werden. Indem die Verwendung einer Bedingungshierarchie zu einem Bestandteil der Anwendung gemacht wird, kann der Dienstanbieter entweder weit gefasste Geräteklassen wie beispielsweise PDAs, enger gefasste Geräteklassen wie beispielsweise Unix-Desktop-Computer, oder spezielle Geräte wie beispielsweise ein Telefon vom Modell Nokia 7110 unterstützen. Der Anwendungsentwickler kann dann die Ausgabe des Dienstes basierend auf den Fähigkeiten der Geräte spezifisch anpassen, und zwar basierend auf einer weit gefassten Klasse, einer eng gefassten Klasse oder einem speziellen Gerät.
  • F. Erzeugen einer Ausgabe durch Abgleichen mit den Anfragebedingungen
  • Wenn der Middleware-Transformer eine bedingungsunabhängige Ausgabe empfängt, die an einen Client geliefert werden soll, und die bedingungsunabhängige Ausgabe einen Satz alternativer Ausgabesegmente beinhaltet, untersucht der Middleware-Transformer die betreffenden Anfragebedingungen. Wenn beispielsweise die alternativen Ausgabesegmente unterschiedlichen Typen von Client-Geräten zugehörig sind, bestimmt der Middleware-Transformer den Gerätetyp des Client, zu dem die Ausgabe gesendet werden soll. Basierend auf der/den anzuwendenden Anfragebedingung(en) wählt der Middleware-Transformer das Ausgabesegment, das mit der/den Ausgabebedingung(en) am genauesten übereinstimmt.
  • Gemäß einem Ausführungsbeispiel wählt der Middleware-Transformer, wenn er eine Ausgabe empfängt, die alternative Ausgabesegmente beinhaltet, das Ausgabesegment aus, das am genauesten mit den Anfragebedingungen übereinstimmt, und zwar mittels des im Ablaufdiagramm von 3 umrissenen Verfahrens. In Schritt 300 wird der höchste Knoten in der Bedingungshierarchie (z.B. der "Alle-Geräte"-Knoten 200 von 2) als aktueller Knoten festgelegt.
  • Als Nächstes werden in Schritt 310 die alternativen Ausgabesegmente, die dem Kind-Knoten des aktuellen Knotens entsprechen, identifiziert. Erneut Bezug nehmend auf 2 identifiziert dann, wenn der aktuelle Knoten der "Alle-Geräte"-Knoten 200 ist, der Middleware-Transformer die Kind-Knoten wie folgt: Sprach-Knoten 210, Desktop-Knoten 212, PDA-Knoten 214, Pager-Knoten 216 und Telefon-Knoten 218.
  • Im Schritt 320 wird bestimmt, ob irgendwelche der Bedingungen, die dem identifizierten Kind-Knoten des aktuellen Knotens zugehörig sind, erfüllt sind. Wenn beispielsweise das die Dienstanfrage durchführende Gerät ein Pager ist, dann wäre die zu dem Pager-Knoten 216 gehörende Bedingung erfüllt, jedoch wäre die dem Telefon-Knoten 218 sowie den anderen Kind-Knoten des "Alle-Geräte"-Knotens 200 zugehörige Bedingung nicht erfüllt. Im umgekehrten Fall wäre, wenn es sich bei dem Gerät um ein Telefon handelte, dann die dem Telefon-Knoten 218 zugehörige Bedingung erfüllt, und die übrigen Bedingungen, die den verbleibenden Kind-Knoten des "Alle-Geräte"-Knotens 200 zugehörig sind, wären nicht erfüllt.
  • Wenn eine Bedingung, die einem Kind-Knoten des aktuellen Knotens zugehörig ist, erfüllt ist, dann wird in Schritt 330 der Kind-Knoten als neuer aktueller Knoten festgelegt und der Prozess geht in einer Schleife zurück auf Schritt 310. Wenn beispielsweise der aktuelle Knoten der "Alle-Geräte"-Knoten 200 ist und das Gerät ein Pager ist, dann ist die Bedingung, die dem Pager-Knoten 216 zugehörig ist, erfüllt. In Übereinstimmung mit Schritt 330 wird der Pager-Knoten 216 als aktueller Knoten festgelegt, und der Prozess geht zurück auf Schritt 310.
  • Wenn keine Bedingung, die irgendeinem Kind-Knoten des aktuellen Knotens zugehörig ist, erfüllt ist, dann wird im Schritt 340 das Ausgabesegment ausgewählt, das dem aktuellen Knoten zugehörig ist. Wenn beispielsweise der aktuelle Knoten der "Alle-Geräte"-Knoten 200 ist und das den Dienst anfordernde Gerät ein brandneuer Typ eines zukünftigen Gerätes ist, das bei der Aufstellung der Bedingungshierarchie unbekannt war, dann wäre vielleicht keine der Bedingungen erfüllt, die irgendeinem der Kind-Knoten des "Alle-Geräte"-Knotens 200 zugehörig ist. Daher wird gemäß Schritt 340 das Ausgabesegment ausgewählt, das dem aktuellen Knoten zugehörig ist, welches in diesem Beispiel der "Alle-Geräte"-Knoten 200 ist. Beispielsweise kann die Ausgabe, die dem "Alle-Geräte"-Knoten 200 zugehörig ist, auf einem beliebigen Gerät anzeigefähig sein (z.B. Lösungsansatz des kleinsten gemeinsamen Nenners), oder die Ausgabe kann auf Geräten mit höherem minimalem Fähigkeitsniveau anzeigefähig sein.
  • Es sei beispielsweise angenommen, dass die bedingungsunabhängige Ausgabe einer Anwendung wie folgt lautet, wobei die Alternativsegment-Tags den in 2 dargestellten Knoten entsprechen:
    Figure 00440001
  • Weiter sei angenommen, dass der Client, an welchen die Ausgabe gesendet werden soll, ein durch die Bezeichnung "TC 441 V1" identifiziertes Gerät ist. Die Bedingung, die dem TC 441 V1-Knoten 442 in 2 zugehörig ist, so wie auch die Bedingungen, die all den Knoten zugehörig sind, von denen aus der TC 441 V1-Knoten absteigt (d.h. der Telefon-Knoten 218 und der WML-Knoten 230) sind erfüllt.
  • Um zu bestimmen, welches der alternativen Ausgabesegmente in dem oben angegebenen XML zu verwenden ist, setzt der Middleware-Transformer zu Anfang den "Alle-Geräte"-Knoten 200 als aktuellen Knoten, gemäß Schritt 300 von 3.
  • Der Middleware-Transformer identifiziert dann die alternativen Ausgabesegmente, die dem Kind-Knoten des aktuellen Knotens entsprechen. Im vorliegenden Beispiel sind die alternativen Ausgabesegmente, die dem Kind-Knoten des "Alle-Geräte"-Knotens 200 entsprechen, die Ausgabesegmente, die dem Sprach-Knoten 210, dem Desktop-Knoten 212 und dem Telefon-Knoten 218 zugehörig sind. Wie in der obigen bedingungsunabhängigen Ausgabe dargestellt, haben nicht alle in 2 dargestellten Kind-Knoten des "Alle-Geräte"-Knotens 200 ein zugehöriges alternatives Ausgabesegment. Daher ist es möglich, dass der Anwendungsentwickler lediglich einige der Klassen, Typen oder spezifischen Geräte unterstützt, die in der Bedingungshierarchie enthalten sind.
  • Der Middleware-Transformer bestimmt dann, ob irgendwelche der Bedingungen, die dem identifizierten Kind-Knoten des aktuellen Knotens zugehörig sind, erfüllt sind, wie in Schritt 310 festgelegt. Im vorliegenden Beispiel, bei dem angenommen wird, dass es sich bei dem Gerät um TC 441 V1 handelt, ist die Bedingung, welche dem Telefon-Knoten 218 zugehörig ist, erfüllt. Demzufolge wird durch den Schritt 330 der Telefon-Knoten 218 als neuer aktueller Knoten festgelegt.
  • Zurückkehrend zu Schritt 310, wobei der Telefon-Knoten 218 als aktueller Knoten festgelegt ist, identifiziert der Middleware-Transformer die alternativen Ausgabesegmente, die dem Kind-Knoten des Telefon-Knotens 218 entsprechen, das bedeutet den WML-Knoten 230, da keine alternativen Ausgabesegmente in dem obigen XML vorgesehen sind, die den anderen in 2 dargestellten Kind-Knoten des Telefon-Knotens 218 entsprechen.
  • Durch den Schritt 320 bestimmt der Middleware-Transformer, ob irgendwelche der Bedingungen, die dem identifizierten Kind-Knoten zugehörig sind, erfüllt sind. Im vorliegenden Beispiel ist das einzige alternative Ausgabesegment mit erfüllter Bedingung dasjenige alternative Ausgabesegment, welches dem WML-Knoten 230 zugehörig ist. Demzufolge wird durch Schritt 330 der WML-Knoten 230 als neuer aktueller Knoten festgelegt.
  • Zurückkehrend zu Schritt 310, wobei der WML-Knoten 230 als aktueller Knoten festgelegt ist, identifiziert der Middleware-Transformer die alternativen Ausgabesegmente, die dem Kind-Knoten des WML-Knotens 230 entsprechen. Im vorliegenden Beispiel ist das einzige alternative Ausgabesegment, das einem Kind-Knoten des WML-Knotens 230 entspricht, dasjenige Ausgabesegment, welches dem TC 441 V2-Knoten 244 zugehörig ist. Es sind keine alternativen Ausgabesegmente in dem obigen XML für die anderen in 2 dargestellten Kind-Knoten des WML-Knotens 230 vorgesehen (d.h. für den Nokia 7110-Knoten 240 und den TC 441 V1-Knoten 242).
  • Durch Schritt 320 bestimmt der Middleware-Transformer dann, ob irgendwelche der Bedingungen, die dem identifizierten Kind-Knoten des aktuellen Knotens zugehörig sind, erfüllt sind. Im vorliegenden Beispiel ist die Bedingung, die dem TC 441 V2-Knoten 244 zugehörig ist, nicht erfüllt, da der Client, zu dem die Ausgabe gesendet werden sollte, ein TC 441 V1 ist, und kein TC 441 V2. Demzufolge wird das dem WML-Knoten 230 zugehörige Ausgabesegment gewählt. Die bedingungsunabhängige Ausgabe kann somit umgewandelt werden in:
    Figure 00470001
  • Das obige Beispiel stellt dar, wie die beste Übereinstimmung für ein spezielles Gerät identifiziert werden kann, sogar wenn es keine exakte Übereinstimmung gibt. Das Fehlen einer genauen Übereinstimmung kann eine Reihe von Gründen haben, wie beispielsweise, dass eine gerätespezifische Ausgabe nicht erforderlich und/oder nicht erwünscht ist. Das Fehlen einer genauen Übereinstimmung kann auch dadurch bedingt sein, dass das Gerät neu ist und der Entwickler somit das neue Gerät und die Fähigkeiten des neuen Gerätes bei der Gestaltung der Anwendung nicht kannte. Trotzdem besteht weiter die Möglichkeit, dass das neue Gerät in dem obigen Beispiel eine für ein Telefon geeignete Ausgabe empfängt, anstatt eine Default-Ausgabe oder eine Ausgabe zu empfangen, die für eine andere Geräteklasse wie beispielsweise Desktop-Computer bestimmt ist.
  • Das vorhergehende Beispiel ist lediglich ein Verfahren, das vom Middleware-Transformer verwendet werden kann, um das Ausgabesegment zu wählen, das am genauesten mit den Anfragebedingungen übereinstimmt. Zahlreiche alternative Verfahren können verwendet werden. Beispielsweise kann bei einem alternativen Verfahren jedem Tag eine Nummer zugewiesen sein, welche in der Bedingungshierarchie dem Niveau des diesem zugehörigen Knoten entspricht. Somit könnte <WML> der Wert 3 zugewiesen sein und <phone> könnte 2 zugewiesen sein. Ein geeignetes Ausgabesegment eines Satzes alternativer Ausgabesegmente kann dann dadurch gewählt werden, dass (1) innerhalb der bedingungsunabhängigen Ausgabe die Tags identifiziert werden, welche den erfüllten Bedingungen entsprechen, und (2) derjenige Tag aus diesen Tags ausgewählt wird, dem der höchste Wert zugewiesen wurde.
  • In der vorhergehenden Beschreibung ist die Anfragebedingung, die verwendet wurde, um das geeignete Ausgabesegment auszuwählen, der Gerätetyp des Client, an den die Ausgabe geliefert werden soll. Jedoch kann die Anfragebedingung, die zur Auswahl zwischen alternativen Ausgabesegmenten verwendet wird, von Implementierung zu Implementierung variieren. Beispielsweise können in einer Implementierung die alternativen Ausgabesegmente eines Satzes jeweils einem unterschiedlichen Auslastungspegel des Netzes zugehörig sein. Bei einer weiteren Implementierung können die alternativen Ausgabesegmente eines Satzes jeweils einer unterschiedlichen Klasse von Endbenutzer zugehörig sein. In noch weiteren Implementierungen können die alternativen Ausgabesegmente Kombinationen von Faktoren zugehörig sein. Beispielsweise kann ein spezielles Ausgabesegment zur Verwendung festgelegt werden, wenn (1) eine spezielle Klasse von Benutzern (2) einen speziellen Typ von Client-Gerät verwendet und (3) über eine Verbindung verfügt, die eine spezielle Übertragungsgeschwindigkeit unterstützt.
  • Weiter liefert die vorhergehende Beschreibung Beispiele, bei denen die Ausgabe in Form einer Markup-Sprache, wie beispielsweise XML, vorliegt. Jedoch kann die Eigenschaft der Ausgabe von Implementierung zu Implementierung variieren. Die hier beschriebenen Verfahren können mit einer beliebigen Form von bedingungsunabhängiger Ausgabe verwendet werden, die (1) alternative Ausgabesegmente und (2) irgendeine Art von Hinweisen beinhaltet, welche verwendet werden können, um basierend auf Anfragebedingungen zwischen alternativen Ausgabesegmenten auszuwählen.
  • G. Auswahl der Ausgabe basierend auf der vom Client-Gerät unterstützten Sprache
  • Die Verwendung des <WML>-Tags im obigen Beispiel illustriert eine Situation, bei welcher die zur Auswahl eines alternativen Ausgabesegments verwendete Anfragebedingung die Markup- oder Programmiersprache betrifft, die vom Client-Gerät unterstützt wird, an das die Ausgabe gesendet werden soll. Gemäß einem Ausführungsbeispiel kann ein alternatives Ausgabesegment, das einer "Unterstützte-Programmiersprache"-Anfragebedingung zugehörig ist, ganz oder teilweise Code beinhalten, der in der unterstützten Programmiersprache geschrieben ist.
  • Beispielsweise kann das Ausgabesegment, das sich zwischen den <WML>- und </WML>-Tags befindet, vollständig aus WML-Code bestehen. Demzufolge liegt, wenn das Client-Gerät die WML-Sprache unterstützt, die an den Client gesendete Ausgabe in Form der WML-Sprache vor. Auch wenn in diesem Beispiel die WML-Sprache verwendet wird, kann das Verfahren für eine beliebige Programmiersprache verwendet werden, einschließlich jedoch nicht eingeschränkt auf "C++", HTML, Visual Basic oder Java.
  • H. Verwenden eines Middleware-Transformers zur Umwandlung einer bedingungsunabhängigen Ausgabe
  • Zahlreiche Vorteile werden dadurch realisiert, dass ein durch den Middleware-Host gehosteter Middleware-Transformer verwendet wird, um die bedingungsunabhängige Ausgabe umzuwandeln, bevor sie einem Client zugeführt wird. Beispielsweise erhält durch dieses Verfahren die mobile Anwendung den Vorzug, dass sie jedes Gerät unterstützt, und zwar dank des Middleware-Hosts, der bei Entwicklung neuer Geräte gerätespezifische Format- und Protokollumwandlungen für diese Geräte bereitstellt. Weiter ist der Entwickler der mobilen Anwendung in der Lage, wenn die mobile Anwendung die zuvor beschriebenen Verfahren der alternativen Ausgabesegmente verwendet, für die Benutzer eine Ausgabe bereitzustellen, deren Inhalt auf Bedingungen basiert, die der Anfrage zugehörig sind, ohne dass er Anwendungen zu gestalten braucht, die zur Erfassung dieser Bedingungen in der Lage sind.
  • In einem Ausführungsbeispiel kann der Inhalt der durch einen Client empfangenen Ausgabe auf den Gerätetyp des Client zugeschnitten werden, ohne dass der mobilen Anwendung der Gerätetyp des Client, an den die Ausgabe gesendet wird, bekannt ist. Beispielsweise kann das Client-Gerät ein Pager sein. Dadurch, dass, wie zuvor erläutert, ein XSL-Style-Sheet zur Umwandlung der Anwendungsausgabe, beispielsweise einer Ausgabe in Form von Portal-to-go-XML, verwendet wird, kann der Middleware-Transformer eine gerätespezifische Formatierung für den Pager erzeugen.
  • Weiter kann der Inhalt der von einem Client empfangenen Ausgabe automatisch auf neue Client-Typen zugeschnitten werden, basierend auf den Kategorien, die diesen neuen Clients zugewiesen wurden, ohne dass der Anwendungsentwickler diese neuen Client-Typen überhaupt zu kennen braucht. Wenn beispielsweise ein neuer Typ von WAP-Telefon entwickelt wird, ordnet der Middleware-Host das neue WAP-Telefon an der geeigneten Stelle in der Bedingungshierarchie ein. Demzufolge empfängt das neue WAP-Telefon automatisch die Ausgabesegmente, die WAP-Telefonen zugehörig sind, falls diese in der Ausgabe der Dienstanwendung spezifiziert sind.
  • Wenn ein spezieller Satz alternativer Ausgabesegmente nicht über ein Ausgabesegment verfügt, das WAP-Telefonen zugehörig ist, jedoch über ein Ausgabesegment verfügt, das Mobiltelefonen zugehörig ist, dann empfängt das neue Telefon automatisch das alternative Ausgabesegment, das den Mobiltelefonen zugehörig ist. Auf diese Weise ist der Inhalt der an neue Geräte gelieferten Ausgabe gerätespezifisch, wobei das Niveau der Spezifierung durch den Anwendungsentwickler festgelegt wird, und zwar sogar für neu entwickelte Geräte, über die der Entwickler bei der Erzeugung der Anwendung nichts weiß.
  • I. Beispiel der Erzeugung der Ausgabe unter Verwendung einer aufgeteilt gehosteten Anwendung
  • 4 ist ein Blockdiagramm, welches ein Beispiel der Erzeugung einer Ausgabe unter Verwendung einer aufgeteilt gehosteten Anwendung gemäß einem Ausfüh rungsbeispiel der Erfindung darstellt. 4 stellt ein Client-Gerät 410, wie beispielsweise einen Laptop-Computer oder ein Mobiltelefon, dar, das mit einem HTTP-Listener 420 wie beispielsweise einem Web-Server verbunden ist, der reagierend auf Anfragen Webseiten bereitstellt. Der HTTP-Listener 420 kann dem Client-Gerät 410 eine Webseite liefern, die eine Liste von Diensten enthält, welche zu einem Hosting-Dienst 430 gehören. Bei Auswahl eines speziellen Dienstes durch das Client-Gerät 410 sendet der HTTP-Listener 420 eine Anfrage nach einem speziellen Dienst an einen Dienste-Linker 432, der Teil des Hosting-Dienstes 430 ist. Der Dienste-Linker 432 kann auf einem oder mehreren Servern implementiert sein, der/die dem Hosting-Dienst 430 zugehörig ist/sind. Bei Empfang der Anfrage identifiziert der Dienste-Linker 432 den Dienst oder die Anwendung, welche Gegenstand der Anfrage ist, und leitet die Anfrage des Client-Geräts 410 an einen Dienstanbieter 440 weiter.
  • Der Dienstanbieter 440 verfügt über einen HTTP-Server 432 zur Abwicklung von Kommunikationsvorgängen zwischen dem Dienstanbieter 440 und weiteren Servern, beispielsweise einem Dienste-Linker 432 oder Servern, die miteinander als Teil des Internet verbunden sind. Der Dienstanbieter 440 verfügt auch über einen Anwendungsserver 446, welcher vom HTTP-Server 432 empfangene Anfragen an die geeignete Anwendung leitet.
  • Der Dienstanbieter 440 verfügt auch über eine Anwendung 450, die in diesem Beispiel Gegenstand der Anfrage des Client-Gerätes 410 ist. Beispielsweise kann Anwendung 450 ein Speiselokalverzeichnis-Modul sein, das eine Auflistung von Restaurants in einer Stadt bereitstellt, die von einem Endbenutzer über einen Client, wie beispielsweise das Client-Gerät 410, festgelegt wird. Die Anwendung 450 kann in der Lage sein, in Abhängigkeit von der Anfrage verschiedene Sätze von Ausgaben zu erzeugen, beispielsweise Ausgabe 452 und 454. Beispielsweise kann es sich bei Ausgabe 452 um eine Eingabeaufforderung für den Endbenutzer handeln, um den Namen einer Stadt einzugeben, für die er eine Restaurantliste erhalten möchte.
  • Der Dienstanbieter 440 verfügt auch über eine Datenbank 470. Beispielsweise kann, wenn die Anwendung 450 ein Speiselokalverzeichnis-Modul ist, die Datenbank 470 Informationen über Restaurants in mehreren Städten enthalten. Bei Auswahl einer speziellen Stadt durch den Endbenutzer kann die Anwendung 450 eine Ausgabe 454 erzeugen, die eine Auflistung von Restaurants in der gewählten Stadt beinhaltet.
  • Der Dienstanbieter 440 antwortet auf die Anfrage, die von einem Client-Gerät 410 über einen Dienste-Linker 432 empfangen wurde, mit einer generischen Ausgabe 480. Beispielsweise kann es sich bei der generischen Ausgabe um ein elektronisches Dokument handeln, das Portal-to-go-XML enthält.
  • Die generische Ausgabe 480 wird vom Dienstanbieter 440 zum Hosting-Dienst 430 gesendet, und die generische Ausgabe wird durch einen Geräte-Transformer 436 verarbeitet. Der Geräte-Transformer 436 kann ein Server sein, der als Middleware-Transformer fungiert, indem er Style-Sheets auf eine generische XML-Ausgabe anwendet, um eine spezifisch angepasste Ausgabe 490 zu erzeugen, wie zuvor beschrieben wurde. Eine spezifisch angepasste Ausgabe wird dann an das Client-Gerät 410 gesendet und dem Endbenutzer angezeigt.
  • IV. ZUGRIFF AUF WEITERE ANWENDUNGEN UND DIENSTE
  • A. Mobile Module
  • Dienstanbieter und Anwendungsentwickler können gehostete oder Portalanwendungen erzeugen, auf die mittels Dienstanfragen zugegriffen wird, die an die Zwischenstation wie beispielsweise einen Host gesendet werden, der einen Middleware-Transformer verwaltet. Gemäß einem Ausführungsbeispiel können die Dienste oder Anwendungen, die hier auch als "mobile Module" bezeichnet werden, eine Ausgabe erzeugen, die zur Folge hat, dass weitere mobile Module angerufen werden. Die Ausgabe kann beispielsweise einen speziellen Satz von Tags verwenden, beispielsweise <substitute> </substitute>, um einen Substitutionsbefehl zu bezeichnen, der sich auf ein weiteres mobiles Modul bezieht, und kann innerhalb der Tags eine Kennung des mobilen Moduls beinhalten.
  • Beispielsweise kann die Ausgabe, die vom mobilen Modul einer ersten Partei (Partei 1) erzeugt wurde, sich auf ein weiteres mobiles Modul einer zweiten Partei (Partei 2) beziehen, dadurch, dass es den folgenden Satz von Anweisungen beinhaltet:
    Figure 00530001
  • Reagierend auf den Empfang der unmittelbar zuvor aufgeführten Ausgabe kann der Middleware-Transformer das mobile Modul der zweiten Partei aufrufen, das durch die "Partei-2-Modul"-Kennung identifiziert ist, die Ausgabe dieses Moduls in die Ausgabe des mobilen Moduls der ersten Partei einbetten und die kombinierte Ausgabe an den Client liefern. Dieses Merkmal erlaubt dem Gestalter eines mobilen Moduls, die Funktionalität aller anderen mobilen Module auszunützen, die bei der Zwischenstation (z.B. dem Host) zur Verfügung stehen. Dieses Merkmal ermöglicht auch, dass die Transaktion mit dem vorhergehenden Dienst aktiv gehalten wird, so wie auch, dass die Dienste verwendet werden, ohne dass bekannt sein muss, wer die Dienste verwendet.
  • Auch unterscheidet sich dieses Merkmal von einer Link-Verbindung von Objekten bei Webseiten, bei denen der Browser auf einem Client läuft. Wenn beispielsweise ein Browser eine Webseite empfängt, die einen Link zu einem Objekt aufweist, sendet der Browser eine Anfrage an die durch den Link angegebene Adresse, empfängt als Antwort ein Objekt und baut dann das Objekt in die Webseite ein, die durch den Browser angezeigt wird. Somit erfolgen Anfrage, Empfang und Einbau des Objektes in die Webseite durch den auf dem Client laufenden Browser.
  • Im Gegensatz dazu empfängt die Zwischenstation eine von einem Modul kommende Ausgabe (z.B. beim Middleware-Transformer), führt eine Anfrage bei einem weiteren Modul durch, empfängt eine Ausgabe von diesem weiteren Modul und kombiniert dann die Ausgaben beider Module und sendet die kombinierte Ausgabe an den Client. Somit erfolgen Anfrage, Empfang und Einbau der Ausgabe des zweiten Dienstes in die Ausgabe des ersten Dienstes durch die Zwischenstation, nicht durch den Client.
  • Gemäß einem weiteren Ausführungsbeispiel kann nicht nur die Ausgabe eines mobilen Moduls, das als das "aufrufende" mobile Modul bezeichnet wird, das Aufrufen eines weiteren mobilen Moduls bewirken, das als "aufgerufenes" mobiles Modul bezeichnet wird, sondern das aufrufende mobile Modul kann auch Parameter an das aufgerufene mobile Modul weitergeben. Beispielsweise kann die Ausgabe des aufrufenden mobilen Moduls Code der folgenden Form beinhalten:
    Figure 00540001
  • Im unmittelbar vorhergehenden Beispiel würde eine Weitergabe der Parameter "Param1", "Param2" und "Param3" vom aufrufenden mobilen Modul an das aufgerufene mobile Modul erfolgen, das durch die "aufgerufenes-Modul"-Kennung identifiziert ist.
  • Gemäß einem weiteren Ausführungsbeispiel beabsichtigt der Gestalter des aufrufenden Moduls möglicherweise, dass, anstelle einer automatischen Einbettung der Ausgabe des aufgerufenen mobilen Moduls in die Ausgabe von ersterem, dem Benutzer einfach ein Link präsentiert wird, das, falls ausgewählt, einen Aufruf der Programmroutine des aufgerufenen mobilen Moduls bewirkt. Um anzugeben, dass ein Link gewünscht wird, kann ein unterschiedlicher Satz von Tags verwendet werden, beispielsweise <action> </action>, um anzugeben, dass eine Ausführungsanweisung basierend auf den Anweisungen zwischen den <action>- und </action>-Tags ausgeführt werden soll.
  • Der Zwischenstation ist bekannt, wenn ein erstes mobiles Modul einer ersten Partei durch ein zweites mobiles Modul einer zweiten Partei aufgerufen wird, da es in der Verantwortlichkeit der Zwischenstation liegt, den vom Substitutionsbefehl geforderten Aufruf oder den durch den Ausführungsbefehl geforderten Aufruf durchzuführen, beispielsweise die Auswahl eines Link.
  • Gemäß einem Ausführungsbeispiel speichert die Zwischenstation Information darüber, welche Module welche weiteren Module aufgerufen haben. Diese Information kann als Basis für Geschäftsbeziehungen zwischen Gestaltern von mobilen Modulen verwendet werden. Beispielsweise kann der Gestalter eines aufrufenden Moduls aushandeln, dass er dem Gestalter eines aufgerufenen Moduls eine gewissen Geldbetrag bezahlt, jedes Mal, wenn das aufrufende Modul das aufgerufene Modul anruft. Die Partei, welche die Zwischenstation (z.B. die Hosting-Dienste) bereitstellt, zeichnet die zwischen den Modulen erfolgenden Anrufe auf und stellt diese den verschiedenen Modulbesitzern zur Verfügung.
  • Das Verfolgen und Verwalten der Geschäftsbeziehungen zwischen Anwendungsanbietern oder Modulbesitzern lassen sich nicht ohne weiteres außerhalb des hier beschriebenen Hosting-Gerüstes implementieren. Beispielsweise kann im World Wide Web eine erste Partei eine erste Webseite gestalten, die einen Link zu einer URL enthält, die einer zweiten Webseite zugehörig ist, welche von einer zweiten Partei bereitgestellt wird. Es ist für die zweite Partei extrem schwierig (wenn nicht unmöglich) zu bestimmen, ob die zweite Webseite als Reaktion darauf angefordert wird, dass durch den Benutzer eine Auswahl des Link auf der ersten Webseite erfolgt ist, oder ob die zweite Webseite durch ein anderes Mittel angefordert wurde. Demzufolge ist es für die zweite Partei schwierig, eine auf die Benutzungshäufigkeit abgestellte Vereinbarung mit der ersten Datei auszuhandeln.
  • Gemäß noch einem weiteren Ausführungsbeispiel erfolgt beim Host bei einer Zwischenstation ein Pflegen von Statusinformation betreffend die Dienste, auf die von einem Endbenutzer zugegriffen wurde. Beispielsweise kann die Zwischenstation einen Informationsstapel für jede Sitzung eines Endbenutzers speichern. Der Informationsstapel gibt die Reihenfolge an, in welcher während der Sitzung Dienste oder mobile Module weitere mobile Module aufgerufen haben, sowie die Identitäten der mobilen Module.
  • Gemäß einem Ausführungsbeispiel können die den Diensten zugehörigen mobilen Module die bei der Zwischenstation gespeicherte Statusinformation unter Verwendung eines Rückrufmechanismus nutzen. Beispielsweise kann zusammen mit einem Link zum Aufruf des aufgerufenen Moduls das aufrufende Modul eine Rückruf-Information beifügen. Wenn der Host das aufgerufene Modul reagierend auf eine Auswahl des Link aufruft, wird in einem Datensatz bei der Zwischenstation die Rückruf-Information gespeichert, beispielsweise dadurch, dass die Rückruf-Information auf dem der Sitzung zugehörigen Stapel abgelegt wird, und das aufgerufene Modul kann eine "Fertiggestellt"- oder "Beenden"-Option, -Steuerelement oder -Objekt in dem durch das aufgerufene Modul bereitgestellten Inhalt bereitstellen. Der Endbenutzer kann die "Fertiggestellt"- oder "Beenden"-Option auswählen, wenn er mit dem vom angerufenen Modul bereitgestellten Dienst fertig ist. Das aufgerufene Modul braucht über keine Information oder Kenntnis bezüglich der Identität des aufrufenden Moduls zu verfügen. Stattdessen braucht das aufgerufene Modul lediglich den Dienst zu identifizieren, auf den "vorher" zugegriffen wurde (d.h. das zuvor verwendete mobile Modul), und die Zwischenstation identifiziert dann basierend auf der Stapelinformation den Dienst, auf den zuvor zugegriffen wurde.
  • Reagierend auf die Auswahl der "Fertiggestellt"-Option wird eine Nachricht an den Host gesendet, um zu bewirken, dass der Host den Befehl ausführt, der ganz oben auf dem Informationsstapel spezifiziert ist. Im zuvor beschriebenen Beispiel ist der ganz oben auf dem Informationsstapel spezifizierte Befehl die Rückruf-Information, die dort zum Zeitpunkt des Aufrufes des aufgerufenen Moduls abgelegt wurde. Typischerweise bewirkt die Rückruf-Information, dass das anrufende Modul erneut aufgerufen wird und der Inhalt oder die Ausgabe vom angerufenen Modul an den Endbenutzer geliefert wird. Aus der Perspektive des Endbenutzers scheint es, als würde er wieder zum aufrufenden Modul zurückkehren, wenn er mit dem aufgerufenen Modul fertig ist.
  • B. Speichern von Daten bei einer Zwischenstation
  • Gemäß einem Ausführungsbeispiel können Daten bei einer Zwischenstation für eine Verwendung durch Dienste gespeichert werden, auf welche über die Zwischenstation zugegriffen wird, und wenn die Anwendungen oder mobilen Module für den Dienst ausgeführt werden, fügt die Zwischenstation die gespeicherten Daten der Ausgabe der Anwendung anstelle der in der Ausgabe enthaltenen Variablen hinzu, und zwar basierend auf einem Mapping dieser Variablen auf die gespeicherten Daten. In der Zwischenstation, welche ein Host sein kann, sind sowohl die Daten oder Werte oder Informationselemente, als auch ein Mapping zwischen diesen Informationselementen und den Variablen oder Kennungen gespeichert. Ein Dienst kann Daten für eine bestehende Variable speichern oder aktualisieren, oder er kann Daten für eine neue Variable speichern, die dem Mapping hinzugefügt werden soll.
  • Der Inhalt oder die Ausgabe, die von einem mobilen Modul erzeugt wird, kann eine oder mehrere der Kennungen beinhalten. Reagierend darauf, dass die Zwischenstation eine Ausgabe antrifft, die sich auf eine der Kennungen bezieht, liefert sie das zugehörige Informationselement, bevor sie die Ausgabe dem Client bereitstellt, der die Ausgabe anfordert.
  • Beispielsweise kann bei einer speziellen Sitzung der Host das Datenelement "Mike" speichern, für das ein Mapping auf die Kennung "Name" vorliegt. Ein Modul kann folgende Ausgabe erzeugen:
    Figure 00580001
  • Wenn der Host bei einer speziellen Sitzung eine derartige Ausgabe antrifft, ersetzt er den "%name"-Verweis durch das zugehörige Datenelement "Mike", was zu folgender Ausgabe führt:
    Figure 00580002
  • Gemäß einem Ausführungsbeispiel können die Dienstanbieter und Entwickler der mobilen Module beim Host die Daten und Kennungen aufzeichnen, deren Pflege durch den Host erfolgt. Die Gestalter dieser Module können sich dadurch der Bürde einer dauerhaften Informationspflege entledigen und verfügen dennoch über den Vorzug einer dauerhaft gepflegten Information, indem sie ihrer Ausgabe lediglich die geeigneten Kennungen beifügen.
  • In einem weiteren Ausführungsbeispiel kann ein aufrufendes mobiles Modul ein Datenelement oder einen Verweis einrichten, um dem Endbenutzer zu erlauben, zum aufrufenden mobilen Modul zurückzukehren, wenn er mit dem aufgerufenen mobilen Modul fertig ist. Beispielsweise kann der Host für eine spezielle Sitzung der Kennung des aufrufenden Moduls das Datenelement "href" zuweisen. Ein Modul kann eine Ausgabe erzeugen, um einen Link zum aufgerufenen mobilen Modul herzustellen, und zwar, indem dieses Datenelement als erster Parameter wie folgt verwendet wird:
    Figure 00590001
  • Wenn der Host bei einer speziellen Sitzung diese Ausgabe antrifft, ersetzt er den "%href"-Verweis durch die Kennung des aufrufenden Moduls, was zu folgender Ausgabe führt:
    Figure 00590002
  • Als Ergebnis wird, wenn der Client den Link zum aufgerufenen Modul verwendet, die Kennung des aufrufenden Moduls an das aufgerufene Modul als Parameter weitergegeben. Das aufgerufene Modul kann die Kennung des aufrufenden Moduls verwenden, um den Client wieder zum aufrufenden Modul zurück zu verweisen, wenn der Client mit dem aufgerufenen Modul fertig ist.
  • Bei einem weiteren Ausführungsbeispiel kann, bevor ein Link zu einem weiteren Dienst oder einem aufgerufenen Modul ausgeführt wird, ein Datenelement bei der Zwischenstation gespeichert werden, das einen Verweis auf den vorhergehenden Dienst oder ein aufrufendes mobiles Modul enthält. Der weitere Dienst oder das aufgerufene mobile Modul kann dann ein Objekt, beispielsweise ein "Fertiggestellt"- oder ein "Beenden"-Steuerelement oder -Schaltfläche auf einer Webseite bereitstellen, welches die Kennung oder Variable, wie beispielsweise "%previous" beinhaltet. Wenn die Zwischenstation in der Ausgabe des anderen Dienstes die "%previous"-Variable antrifft, ersetzt die Zwischenstation diese durch einen Verweis auf den vorhergehenden Dienst oder das aufrufende mobile Modul, wodurch dem Endbenutzer eine Rückkehr zum vorhergehenden Dienst ermöglicht wird, indem er das Objekt auf der Webseite des aufgerufenen mobilen Moduls auswählt.
  • Auch wenn in den zuvor beschriebenen Beispielen Variablen oder Kennungen, wie beispielsweise "%name" verwendet werden, um den Namen eines Endbenutzers zu bezeichnen, bzw. "%href" verwendet werden, um die Kennung des aufrufenden Moduls an das aufgerufene Modul weiterzugeben, können weitere Variablen verwendet werden, um auf weitere Daten zu verweisen, die lediglich dann festgelegt oder bekannt sind, wenn die Anwendung ausgeführt wird. Beispielsweise können Kennungen verwendet wird, um das Datum oder die Zeit zu laden, zu der die Anwendung läuft oder eine spezifische Anfrage durch einen Client erfolgt.
  • V. HARDWARE-ÜBERSICHT
  • 5 ist ein Blockdiagramm, welches ein Computersystem 500 darstellt, auf dem ein Ausführungsbeispiel der Erfindung implementiert sein kann. Das Computersystem 500 beinhaltet einen Bus 502 oder einen anderen Übertragungsmechanismus zum Weitergeben von Information und einen mit dem Bus 502 verbundenen Prozessor 504 zur Verarbeitung von Information. Das Computersystem 500 beinhaltet auch einen Hauptspeicher 506, beispielsweise einen Direktzugriffsspeicher (RAM) oder ein anderes dynamisches Speicherbauelement, das mit dem Bus 502 verbunden ist, um Information und Anweisungen zu speichern, die durch den Prozessor 504 ausgeführt werden sollen. Der Hauptspeicher 506 kann auch zum Speichern von temporären Variablen oder weiterer während der Ausführung von durch den Prozessor 504 auszuführenden Anweisungen auftretender Zwischeninformation verwendet werden. Das Computersystem 500 beinhaltet weiter einen Festwertspeicher (ROM) 508 oder ein anderes statisches Speicherbauelement, das mit Bus 502 verbunden ist, um statische Information und Anweisungen für den Prozessor 504 zu speichern. Ein Speicherbauelement 510 wie beispiels weise eine Magnetplatte oder eine optische Platte ist vorgesehen und mit dem Bus 502 verbunden, um Information und Anweisungen zu speichern.
  • Das Computersystem 500 kann über den Bus 502 mit einer Anzeige 512 wie beispielsweise einer Kathodenstrahlröhre (CRT) verbunden sein, um einem Computerbenutzer Information anzuzeigen. Ein Eingabegerät 514, welches alphanumerische sowie weitere Tasten beinhaltet, ist mit dem Bus 502 verbunden, um Information und eine Befehlsauswahl an den Prozessor 504 weiterzugeben. Ein weiterer Typ von Benutzereingabegerät ist eine Cursor-Steuereinrichtung 516, wie beispielsweise eine Maus, ein Trackball, oder Cursor-Richtungstasten, welche eine Richtungsinformation und eine Befehlsauswahl an den Prozessor 504 weitergeben und die Cursor-Bewegung auf der Anzeige 512 steuern. Dieses Eingabegerät hat typischerweise zwei Freiheitsgrade in zwei Achsen, einer ersten Achse (z.B. x) und einer zweiten Achse (z.B. y), die dem Gerät ermöglichen, Positionen in einer Ebene festzulegen.
  • Die Erfindung betrifft die Verwendung des Computersystems 500 zur Implementierung der hier beschriebenen Verfahren. Gemäß einem Ausführungsbeispiel der Erfindung werden diese Verfahren durch ein Computersystem 500 reagierend darauf ausgeführt, dass der Prozessor 504 eine oder mehrere Sequenzen von einer oder mehreren im Hauptspeicher 506 enthaltenen Anweisungen ausführt. Derartige Anweisungen können in den Hauptspeicher 506 von einem weiteren computerlesbaren Medium wie beispielsweise einem Speichergerät 510 eingelesen werden. Eine Ausführung von im Hauptspeicher 506 enthaltenen Anweisungssequenzen bewirkt, dass der Prozessor 504 die hier beschriebenen Prozessschritte durchführt. In alternativen Ausführungsbeispielen können fest verdrahte Schaltkreise anstelle oder in Kombination mit Software-Anweisungen verwendet werden, um die Erfindung zu implementieren. Somit sind Ausführungsbeispiele der Erfindung nicht auf irgendeine spezielle Kombination von Hardware-Schaltkreisen und Software eingeschränkt.
  • Der Begriff "computerlesbares Medium" wie hier verwendet, bezieht sich auf ein beliebiges Medium, das an der Lieferung von Anweisungen an den Prozessor 504 für eine Ausführung durch diesen teilnimmt. Ein derartiges Medium kann viele Formen annehmen, einschließlich, jedoch nicht eingeschränkt auf nichtflüchtige Medien, flüchtige Medien und Übertragungsmedien. Nichtflüchtige Medien beinhalten beispielsweise optische oder magnetische Platten wie beispielsweise das Speichergerät 510. Flüchtige Medien beinhalten einen dynamischen Speicher wie beispielsweise den Hauptspeicher 506. Übertragungsmedien beinhalten Koaxialkabel, Kupferdrähte und Lichtwellenleiter, einschließlich der Drähte, die der Bus 502 aufweist. Übertragungsmedien können auch die Form von akustischen Wellen oder Lichtwellen annehmen, beispielsweise solchen, die bei Funkwellen- oder Infrarot-Datenübertragungen erzeugt werden.
  • Übliche Formen computerlesbarer Medien beinhalten beispielsweise eine Floppy-Disk, eine flexible Platte, eine Hard-Disk, ein Magnetband oder ein beliebiges anderes magnetisches Medium, eine CD-ROM, ein beliebiges anderes optisches Medium, Lochkarten, Lochstreifen, ein beliebiges anderes physisches Medium mit Lochmustern, eine RAM, ein PROM und ein EPROM, ein FLASH-EPROM und einen beliebigen anderen Speicherchip oder -kassette, eine Trägerwelle wie nachfolgend beschrieben, oder ein beliebiges anderes Medium, von dem ein Computer lesen kann.
  • Verschiedene Formen computerlesbarer Medien können daran beteiligt sein, eine oder mehrere Sequenzen von einer oder mehreren Anweisungen zum Prozessor 504 für eine Ausführung durch diesen zu tragen. Beispielsweise können sich die Anweisungen anfänglich auf einer Magnetplatte eines entfernt befindlichen Computers befinden. Der entfernt befindliche Computer kann die Anweisungen in seinen dynamischen Speicher laden und die Anweisungen unter Verwendung eines Modems über eine Telefonleitung senden. Ein lokal beim Computersystem 500 angeordnetes Modem kann die Daten über die Telefonleitung empfangen und eine Infrarot-Übertragungseinrichtung verwenden, um die Daten in ein Infrarot signal umzuwandeln. Ein Infrarotdetektor kann die im infraroten Signal transportierten Daten empfangen und eine geeignete Schaltung kann die Daten auf den Bus 502 bringen. Der Bus 502 bringt die Daten zum Hauptspeicher 506, von dem aus der Prozessor 504 die Anweisungen holt und ausführt. Die vom Hauptspeicher 506 empfangenen Anweisungen können optional im Speichergerät 510 gespeichert werden, und zwar entweder vor oder nach der Ausführung durch den Prozessor 504.
  • Das Computersystem 500 beinhaltet auch eine Kommunikationsschnittstelle 518, die mit dem Bus 502 verbunden ist. Die Kommunikationsschnittstelle 518 stellt eine Zweiweg-Datenkommunikationsverbindung zu einer Netzverbindung 520 bereit, die mit einem lokalen Netz 522 verbunden ist. Beispielsweise kann es sich bei der Kommunikationsschnittstelle 518 um eine ISDN-(Integrated Services Digital Network)-Karte oder ein Modem handeln, um eine Datenkommunikationsverbindung zu einem entsprechenden Typ von Telefonleitung bereitzustellen. Als weiteres Beispiel kann es sich bei der Kommunikationsschnittstelle 518 um eine LAN-(Local Area Network)-Karte handeln, um eine Datenkommunikationsverbindung zu einem kompatiblen LAN bereitzustellen. Drahtlose Verbindungen können ebenfalls implementiert werden. Bei jeder derartigen Implementierung führt die Kommunikationsschnittstelle 518 ein Senden und Empfangen von elektrischen, elektromagnetischen oder optischen Signalen durch, welche digitale Datenströme tragen, die verschiedene Typen von Information repräsentieren.
  • Die Netzverbindung 520 stellt typischerweise über eines oder mehrere Netze eine Datenkommunikation zu weiteren Datengeräten bereit. Beispielsweise kann die Netzverbindung 520 über ein lokales Netz 522 eine Verbindung zu einem Host-Computer 524 oder zu einem Datengerät bereitstellen, das durch einen Internet-Dienstanbieter (ISP) 526 betrieben wird. Der ISP 526 stellt seinerseits Datenkommunikationsdienste über das weltweite Paketdatenkommunikationsnetz bereit, das heutzutage üblicherweise als "Internet" 528 bezeichnet wird. Sowohl das lokale Netz 522 als auch das Internet 528 verwenden elektrische, elektro magnetische oder optische Signale, welche digitale Datenströme transportieren. Die über die verschiedenen Netze geschickten Signale und die Signale, die über die Netzverbindung 520 und die Kommunikationsschnittstelle 518 gesendet werden, welche digitale Daten zum Computersystem 500 hin und von diesem weg transportieren, sind beispielhafte Formen von die Information transportierenden Trägerwellen.
  • Das Computersystem 500 kann über das/die Netz(e), die Netzverbindung 520 und die Kommunikationsschnittstelle 518 Nachrichten senden und Daten, einschließlich Programmcode, empfangen. Beim Beispiel des Internets könnte ein Server 530 einen angeforderten Code für ein Anwendungsprogramm über das Internet 528, den ISP 526, das lokale Netz 522 und die Kommunikationsschnittstelle 518 senden.
  • Der empfangene Code kann bei Empfang durch den Prozessor 504 verarbeitet werden und/oder für eine spätere Ausführung im Speichergerät 510 oder einem anderen nichtflüchtigen Speicher gespeichert werden. Auf diese Weise kann das Computersystem 500 einen Anwendungscode in Form einer Trägerwelle erhalten.
  • In der obigen Beschreibung ist die Erfindung unter Hinweis auf bestimmte Ausführungsformen der Erfindung beschrieben worden. Es ist jedoch offensichtlich, dass verschiedene Abänderungen und Veränderungen vorgenommen werden können, ohne den Bereich der Erfindung zu verlassen. Die Beschreibung und die Zeichnungen sind demgemäß nicht als Einschränkung, sondern als Veranschaulichung aufzufassen.

Claims (9)

  1. Ein Verfahren, das es Diensten gestattet, in Reaktion auf eine erste Anforderung von einem Endbenutzer (130, 132, 134) auf Daten zuzugreifen, wobei in Reaktion auf die erste Anforderung eine Antwort an den Endbenutzer (130, 132, 134) gesendet wird, dadurch gekennzeichnet, dass die Daten bei einer Zwischenstation gespeichert werden, und das Verfahren die computerimplementierten Schritte aufweist: Empfangen, bei der Zwischenstation in Reaktion auf die erste Anforderung von dem Endbenutzer (130, 132, 134), einer ersten Ausgabe von einem ersten Dienst, wobei die erste Ausgabe eine oder mehrere Variablen enthält; Heranziehen einer Abbildung, die eine Mehrzahl von Variablen auf eine Mehrzahl von Datenwerten abbildet, wobei die Mehrzahl von Variablen die eine oder die mehreren Variablen aufweist; Identifizieren, beruhend auf der Abbildung, von einem oder mehreren Datenwerten, die auf einem mit der Zwischenstation in Beziehung stehenden Server (110) gespeichert sind, wobei der eine oder die mehreren Datenwerte der einen oder den mehreren Variablen zugeordnet sind; Erzeugen der Antwort in Reaktion auf die erste Anforderung, und zwar beruhend auf der ersten Ausgabe und dem einen oder den mehreren Datenwerten, die der einen oder den mehreren Variablen zugeordnet sind; und Senden der Antwort an den Endbenutzer (130, 132, 134) in Reaktion auf die erste Anforderung.
  2. Das Verfahren nach Anspruch 1, ferner mit dem computerimplementierten Schritt: Speichern, bei der Zwischenstation, von einem oder mehreren zusätzlichen Datenwerten in Reaktion auf eine Datenspeicheranforderung von dem ersten Dienst.
  3. Das Verfahren nach Anspruch 2, ferner mit dem computerimplementierten Schritt: Aktualisieren der Abbildung, um anzuzeigen, dass eine oder mehrere zusätzliche Variable dem einen oder den mehreren zusätzlichen Datenwerten zugeordnet sind.
  4. Das Verfahren nach Anspruch 1, bei dem der Schritt des Erzeugens der Antwort beruhend auf der ersten Ausgabe und dem einen oder den mehreren Datenwerten den computerimplementierten Schritt umfasst: Ersetzen mindestens einer der einen oder der mehreren Datenvariablen durch mindestens einen des einen oder der mehreren Datenwerte, der/die der mindestens einen der einen oder der mehreren Datenvariablen zugeordnet ist/sind.
  5. Das Verfahren nach Anspruch 1, bei dem die eine oder die mehreren Variablen eine bestimmte Variable zur Identifizierung eines vorherigen Dienstes umfasst/umfassen, von dem der Endbenutzer (130, 132, 134) eine vorherige Ausgabe angefordert hat, und bei dem das Verfahren ferner den computerimplementierten Schritt aufweist: Speichern, bei der Zwischenstation, eines bestimmten Datenwertes, der einen bestimmten vorherigen Dienst angibt, von dem der Endbenutzer (130, 132, 134) eine bestimmte vorherige Ausgabe angefordert hat, wobei die Abbildung anzeigt, dass der bestimmte Datenwert der bestimmten Variablen zugeordnet ist.
  6. Das Verfahren nach Anspruch 5, bei dem der Schritt des Erzeugens der Antwort basierend auf der ersten Ausgabe und dem einen oder den mehreren Datenwerten die computerimplementierten Schritte aufweist: Überprüfen der ersten Ausgabe, um die bestimmte Variable zu erkennen; Feststellen, dass die bestimmte Variable beruhend auf der Abbildung dem bestimmten Datenwert zugeordnet ist; und Aufnehmen einer Referenz auf den bestimmten vorherigen Dienst in die erste Ausgabe, beruhend auf dem bestimmten Datenwert.
  7. Das Verfahren nach Anspruch 6, bei dem der Schritt des Aufnehmens der Referenz auf den bestimmten vorherigen Dienst in die Ausgabe den computerimplementierten Schritt aufweist: Bereitstellen eines Objekts, das dem bestimmten vorherigen Dienst zugeordnet ist, so dass, wenn der Endbenutzer (130, 132, 134) das Objekt auswählt, eine neue Anforderung für eine neue Ausgabe an den bestimmten vorherigen Dienst gesendet wird.
  8. Das Verfahren nach Anspruch 1, bei dem die Ausgabe ein Objekt aufweist, das einem zweiten Dienst zugeordnet ist, wobei das Objekt eine bestimmte Variable als einen Parameter für das Objekt aufweist, wobei die bestimmte Variable einem bestimmten Datenwert zugeordnet ist, der den ersten Dienst angibt, und wobei der Schritt des Erzeugens der Antwort den computerimplementierten Schritt umfasst: Ersetzen der bestimmten Variablen durch den bestimmten Datenwert, so dass, wenn das Objekt von dem Endbenutzer (130, 132, 134) ausgewählt wird, eine zweite Anforderung für eine zweite Ausgabe des zweiten Dienstes durch die Zwischenstation an den zweiten Dienst gesendet wird, wobei die zweite Anforderung den ersten Dienst angibt.
  9. Ein computerlesbares Medium, das eine oder mehrere Befehlssequenzen trägt, um es Diensten zu ermöglichen, auf Daten, die bei einer Zwischenstation gespeichert sind, zuzugreifen, wobei die Ausführung der einen oder mehreren Befehlssequenzen durch einen oder mehrere Prozessoren den einen oder die mehreren Prozessoren veranlasst, die Schritte des Verfahrens nach einem der Ansprüche 1 – 8 auszuführen.
DE60121987T 2000-09-06 2001-09-06 Zugreifen auf Daten, die bei einer Zwischenstation gespeichert sind, von einem Dienst aus Expired - Lifetime DE60121987T2 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US948135 1992-09-21
US23048900P 2000-09-06 2000-09-06
US230489P 2000-09-06
US09/948,135 US6954751B2 (en) 2000-09-06 2001-09-05 Accessing data stored at an intermediary from a service
PCT/US2001/042068 WO2002021343A2 (en) 2000-09-06 2001-09-06 Accessing data stored at an intermediary from a service

Publications (2)

Publication Number Publication Date
DE60121987D1 DE60121987D1 (de) 2006-09-14
DE60121987T2 true DE60121987T2 (de) 2007-03-29

Family

ID=26924289

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60121987T Expired - Lifetime DE60121987T2 (de) 2000-09-06 2001-09-06 Zugreifen auf Daten, die bei einer Zwischenstation gespeichert sind, von einem Dienst aus

Country Status (9)

Country Link
US (1) US6954751B2 (de)
EP (1) EP1330739B1 (de)
JP (1) JP4975232B2 (de)
AT (1) ATE335241T1 (de)
AU (2) AU9325401A (de)
CA (1) CA2420023C (de)
DE (1) DE60121987T2 (de)
HK (1) HK1057635A1 (de)
WO (1) WO2002021343A2 (de)

Families Citing this family (72)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8090856B1 (en) 2000-01-31 2012-01-03 Telecommunication Systems, Inc. Intelligent messaging network server interconnection
US7003571B1 (en) 2000-01-31 2006-02-21 Telecommunication Systems Corporation Of Maryland System and method for re-directing requests from browsers for communication over non-IP based networks
US7111233B1 (en) 2000-03-09 2006-09-19 Electronic Data Systems Corporation Method and system for applying XML schema
US7114147B2 (en) * 2000-03-09 2006-09-26 Electronic Data Systems Corporation Method and system for reporting XML data based on precomputed context and a document object model
US7013340B1 (en) * 2000-05-18 2006-03-14 Microsoft Corporation Postback input handling by server-side control objects
US7483983B1 (en) * 2000-11-13 2009-01-27 Telecommunication Systems, Inc. Method and system for deploying content to wireless devices
EP1215547B1 (de) * 2000-12-15 2007-01-03 Siemens Aktiengesellschaft Verschlüsselung von Steuerungsprogrammen
US7302634B2 (en) 2001-03-14 2007-11-27 Microsoft Corporation Schema-based services for identity-based data access
US7024662B2 (en) 2001-03-14 2006-04-04 Microsoft Corporation Executing dynamically assigned functions while providing services
US7380250B2 (en) * 2001-03-16 2008-05-27 Microsoft Corporation Method and system for interacting with devices having different capabilities
CA2454740C (en) * 2001-07-23 2012-04-17 Evresearch, Ltd. Storage medium encoded with a server program and method using same
US7216294B2 (en) * 2001-09-04 2007-05-08 Microsoft Corporation Method and system for predicting optimal HTML structure without look-ahead
US7191233B2 (en) * 2001-09-17 2007-03-13 Telecommunication Systems, Inc. System for automated, mid-session, user-directed, device-to-device session transfer system
US7203927B2 (en) * 2001-09-20 2007-04-10 International Business Machines Corporation SQL debugging using XML dataflows
WO2003036481A1 (en) * 2001-10-24 2003-05-01 Bea Systems, Inc. System and method for rule-based entitlements
US7428725B2 (en) * 2001-11-20 2008-09-23 Microsoft Corporation Inserting devices specific content
US20030193967A1 (en) * 2001-12-31 2003-10-16 Gregg Fenton Method, apparatus and system for processing multimedia messages
GB2389925A (en) * 2002-06-18 2003-12-24 Hewlett Packard Co Provision of content to a client device
US20040025173A1 (en) * 2002-04-24 2004-02-05 Gil Levonai Interaction abstraction system and method
US7441047B2 (en) 2002-06-17 2008-10-21 Microsoft Corporation Device specific pagination of dynamically rendered data
US9886309B2 (en) 2002-06-28 2018-02-06 Microsoft Technology Licensing, Llc Identity-based distributed computing for device resources
US7426535B2 (en) * 2002-10-08 2008-09-16 Telecommunication Systems, Inc. Coordination of data received from one or more sources over one or more channels into a single context
US7574653B2 (en) * 2002-10-11 2009-08-11 Microsoft Corporation Adaptive image formatting control
US7415716B2 (en) * 2003-01-17 2008-08-19 International Business Machines Corporation Component integrator
US7483879B2 (en) * 2003-01-17 2009-01-27 International Business Machines Corporation System and method for accessing non-compatible content repositories
IL158282A0 (en) * 2003-10-02 2004-05-12 Netmask El Mar Internet Techno Configuration setting
US7376664B2 (en) * 2003-10-31 2008-05-20 Abb Research Ltd. Method for evaluating a transformer design
US7890604B2 (en) 2004-05-07 2011-02-15 Microsoft Corproation Client-side callbacks to server events
US9026578B2 (en) 2004-05-14 2015-05-05 Microsoft Corporation Systems and methods for persisting data between web pages
US7467389B2 (en) * 2004-11-23 2008-12-16 Sybase, Inc. System and methodology providing service invocation for occasionally connected computing devices
US8171138B2 (en) * 2005-02-15 2012-05-01 Microsoft Corporation System and method for applying flexible attributes to execute asynchronous network requests
FR2886802A1 (fr) * 2005-06-06 2006-12-08 France Telecom Acces a un service multimedia depuis un terminal mobile
US8688671B2 (en) 2005-09-14 2014-04-01 Millennial Media Managing sponsored content based on geographic region
US8666376B2 (en) 2005-09-14 2014-03-04 Millennial Media Location based mobile shopping affinity program
US10592930B2 (en) 2005-09-14 2020-03-17 Millenial Media, LLC Syndication of a behavioral profile using a monetization platform
US7702318B2 (en) 2005-09-14 2010-04-20 Jumptap, Inc. Presentation of sponsored content based on mobile transaction event
US8229914B2 (en) 2005-09-14 2012-07-24 Jumptap, Inc. Mobile content spidering and compatibility determination
US7660581B2 (en) 2005-09-14 2010-02-09 Jumptap, Inc. Managing sponsored content based on usage history
US7752209B2 (en) 2005-09-14 2010-07-06 Jumptap, Inc. Presenting sponsored content on a mobile communication facility
US20110313853A1 (en) 2005-09-14 2011-12-22 Jorey Ramer System for targeting advertising content to a plurality of mobile communication facilities
US8812526B2 (en) 2005-09-14 2014-08-19 Millennial Media, Inc. Mobile content cross-inventory yield optimization
US8805339B2 (en) 2005-09-14 2014-08-12 Millennial Media, Inc. Categorization of a mobile user profile based on browse and viewing behavior
US8615719B2 (en) 2005-09-14 2013-12-24 Jumptap, Inc. Managing sponsored content for delivery to mobile communication facilities
US8503995B2 (en) 2005-09-14 2013-08-06 Jumptap, Inc. Mobile dynamic advertisement creation and placement
US8532633B2 (en) 2005-09-14 2013-09-10 Jumptap, Inc. System for targeting advertising content to a plurality of mobile communication facilities
US8103545B2 (en) 2005-09-14 2012-01-24 Jumptap, Inc. Managing payment for sponsored content presented to mobile communication facilities
US9058406B2 (en) 2005-09-14 2015-06-16 Millennial Media, Inc. Management of multiple advertising inventories using a monetization platform
US7912458B2 (en) 2005-09-14 2011-03-22 Jumptap, Inc. Interaction analysis and prioritization of mobile content
US20100076994A1 (en) * 2005-11-05 2010-03-25 Adam Soroca Using Mobile Communication Facility Device Data Within a Monetization Platform
US8989718B2 (en) 2005-09-14 2015-03-24 Millennial Media, Inc. Idle screen advertising
US8238888B2 (en) 2006-09-13 2012-08-07 Jumptap, Inc. Methods and systems for mobile coupon placement
US8364521B2 (en) 2005-09-14 2013-01-29 Jumptap, Inc. Rendering targeted advertisement on mobile communication facilities
US8660891B2 (en) 2005-11-01 2014-02-25 Millennial Media Interactive mobile advertisement banners
US8819659B2 (en) 2005-09-14 2014-08-26 Millennial Media, Inc. Mobile search service instant activation
US7676394B2 (en) 2005-09-14 2010-03-09 Jumptap, Inc. Dynamic bidding and expected value
US7769764B2 (en) 2005-09-14 2010-08-03 Jumptap, Inc. Mobile advertisement syndication
US8209344B2 (en) 2005-09-14 2012-06-26 Jumptap, Inc. Embedding sponsored content in mobile applications
US10911894B2 (en) 2005-09-14 2021-02-02 Verizon Media Inc. Use of dynamic content generation parameters based on previous performance of those parameters
US8195133B2 (en) 2005-09-14 2012-06-05 Jumptap, Inc. Mobile dynamic advertisement creation and placement
US10038756B2 (en) 2005-09-14 2018-07-31 Millenial Media LLC Managing sponsored content based on device characteristics
US9703892B2 (en) 2005-09-14 2017-07-11 Millennial Media Llc Predictive text completion for a mobile communication facility
US8150816B2 (en) * 2005-12-29 2012-04-03 Nextlabs, Inc. Techniques of optimizing policies in an information management system
US7716240B2 (en) 2005-12-29 2010-05-11 Nextlabs, Inc. Techniques and system to deploy policies intelligently
US7877409B2 (en) 2005-12-29 2011-01-25 Nextlabs, Inc. Preventing conflicts of interests between two or more groups using applications
US8397161B1 (en) * 2006-10-06 2013-03-12 Juniper Networks, Inc. Content compilation and publishing system
WO2008096417A1 (ja) * 2007-02-06 2008-08-14 Panasonic Corporation コンテンツリスト表示装置およびコンテンツリスト表示方法
US9009292B2 (en) * 2007-07-30 2015-04-14 Sybase, Inc. Context-based data pre-fetching and notification for mobile applications
US8204870B2 (en) * 2007-08-03 2012-06-19 Sybase, Inc. Unwired enterprise platform
US8296445B1 (en) * 2007-11-12 2012-10-23 Google Inc. Software testing harness
JP5638761B2 (ja) * 2009-02-10 2014-12-10 富士通株式会社 画面生成方法、画面表示方法、画面生成装置、及びプログラム
US9741046B2 (en) 2012-07-06 2017-08-22 Oracle International Corporation Service design and order fulfillment system with fulfillment solution blueprint
US9268763B1 (en) * 2015-04-17 2016-02-23 Shelf.Com, Inc. Automatic interpretive processing of electronic transaction documents

Family Cites Families (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5115501A (en) 1988-11-04 1992-05-19 International Business Machines Corporation Procedure for automatically customizing the user interface of application programs
JP2522898B2 (ja) 1992-09-08 1996-08-07 インターナショナル・ビジネス・マシーンズ・コーポレイション 動的カストマイズ方法及びグラフィックリソ―ス・エディタ
US5850548A (en) 1994-11-14 1998-12-15 Borland International, Inc. System and methods for visual programming based on a high-level hierarchical data flow model
US5887172A (en) 1996-01-10 1999-03-23 Sun Microsystems, Inc. Remote procedure call system and method for RPC mechanism independent client and server interfaces interoperable with any of a plurality of remote procedure call backends
US5937163A (en) * 1996-03-26 1999-08-10 Industrial Technology Research Institute Method and system at a host node for hierarchically organizing the links visited by a world wide web browser executing at the host node
US5991535A (en) 1996-07-03 1999-11-23 Sun Microsystems, Inc. Visual composition tool for constructing application programs using distributed objects on a distributed object network
US5933811A (en) * 1996-08-20 1999-08-03 Paul D. Angles System and method for delivering customized advertisements within interactive communication systems
JPH10232899A (ja) * 1996-12-17 1998-09-02 Fuji Xerox Co Ltd サービス連携方法とサービス連携装置およびそれらの実施に利用できるパーツ生成管理方法
US5960432A (en) 1996-12-31 1999-09-28 Intel Corporation Multi-level captioning for enhanced data display
US6286029B1 (en) * 1997-04-28 2001-09-04 Sabre Inc. Kiosk controller that retrieves content from servers and then pushes the retrieved content to a kiosk in the order specified in a run list
US6073163A (en) 1997-06-10 2000-06-06 Oracle Corporation Method and apparatus for enabling web-based execution of an application
JPH11212911A (ja) * 1998-01-28 1999-08-06 Mitsubishi Electric Corp 分散サービス連携装置
JPH11316704A (ja) * 1998-05-01 1999-11-16 Nippon Telegr & Teleph Corp <Ntt> Htmlページのリンク変換方法及びリンク変換プログラムを格納した記憶媒体
US6578073B1 (en) * 1998-05-13 2003-06-10 Hewlett-Packard Development Company, L.P. Accelerated content delivery over a network using reduced size objects
US6510469B1 (en) * 1998-05-13 2003-01-21 Compaq Information Technologies Group,L.P. Method and apparatus for providing accelerated content delivery over a network
US6128655A (en) * 1998-07-10 2000-10-03 International Business Machines Corporation Distribution mechanism for filtering, formatting and reuse of web based content
US6324681B1 (en) 1998-10-01 2001-11-27 Unisys Corporation Automated development system for developing applications that interface with both distributed component object model (DCOM) and enterprise server environments
US6408360B1 (en) * 1999-01-25 2002-06-18 International Business Machines Corporation Cache override control in an apparatus for caching dynamic content
US6535896B2 (en) * 1999-01-29 2003-03-18 International Business Machines Corporation Systems, methods and computer program products for tailoring web page content in hypertext markup language format for display within pervasive computing devices using extensible markup language tools
US6313835B1 (en) * 1999-04-09 2001-11-06 Zapa Digital Arts Ltd. Simplified on-line preparation of dynamic web sites
US6345279B1 (en) * 1999-04-23 2002-02-05 International Business Machines Corporation Methods and apparatus for adapting multimedia content for client devices
US6477565B1 (en) * 1999-06-01 2002-11-05 Yodlee.Com, Inc. Method and apparatus for restructuring of personalized data for transmission from a data network to connected and portable network appliances
US6584548B1 (en) * 1999-07-22 2003-06-24 International Business Machines Corporation Method and apparatus for invalidating data in a cache
US6735741B1 (en) * 1999-07-30 2004-05-11 International Business Machines Corporation Method system, and program for dynamic resource linking when copies are maintained at different storage locations
JP2001060187A (ja) * 1999-08-24 2001-03-06 Nippon Telegr & Teleph Corp <Ntt> 分散サーバ連携システムおよび連携方法、ならびにそのプログラムを記録した記録媒体
US6430624B1 (en) * 1999-10-21 2002-08-06 Air2Web, Inc. Intelligent harvesting and navigation system and method
WO2001042990A2 (en) * 1999-12-13 2001-06-14 Inktomi Corporation File transmission from a first web server agent to a second web server agent
US20010034788A1 (en) * 2000-01-21 2001-10-25 Mcternan Brennan J. System and method for receiving packet data multicast in sequential looping fashion
US20010047517A1 (en) * 2000-02-10 2001-11-29 Charilaos Christopoulos Method and apparatus for intelligent transcoding of multimedia data
JP2001229106A (ja) * 2000-02-18 2001-08-24 Hitachi Ltd コンテンツ変換システム
US6757709B1 (en) * 2000-04-05 2004-06-29 Hewlett-Packard Development Company, L.P. Method and apparatus for providing a client system with information via a network
JP4319331B2 (ja) * 2000-06-23 2009-08-26 富士通株式会社 サービス連携システムおよび情報転用装置
US6704776B1 (en) * 2000-06-30 2004-03-09 Webtv Networks, Inc. Selecting attribute based content for server applications
US20020037709A1 (en) * 2000-09-22 2002-03-28 Ranjit Bhatia System, method and apparatus for facilitating the receipt of realtime information from telecommunications nodes
JP2002157232A (ja) * 2000-11-20 2002-05-31 Hitachi Ltd データ処理システム
WO2002046946A1 (en) * 2000-12-07 2002-06-13 Cincro Communications Corporation System and method for delivery of documents over a computer network

Also Published As

Publication number Publication date
HK1057635A1 (en) 2004-04-08
WO2002021343A3 (en) 2003-05-22
US6954751B2 (en) 2005-10-11
DE60121987D1 (de) 2006-09-14
JP4975232B2 (ja) 2012-07-11
ATE335241T1 (de) 2006-08-15
US20020129016A1 (en) 2002-09-12
CA2420023A1 (en) 2002-03-14
JP2004519757A (ja) 2004-07-02
AU9325401A (en) 2002-03-22
EP1330739A2 (de) 2003-07-30
WO2002021343A2 (en) 2002-03-14
AU2001293254B2 (en) 2006-09-14
CA2420023C (en) 2010-08-10
EP1330739B1 (de) 2006-08-02

Similar Documents

Publication Publication Date Title
DE60121987T2 (de) Zugreifen auf Daten, die bei einer Zwischenstation gespeichert sind, von einem Dienst aus
DE60108158T2 (de) Onlineentwicklung von applikationen
DE60126016T2 (de) Serverseitige Kontrollobjekte zur Verarbeitung von kundenseitigen Benutzerschnittstellenelementen
EP1330736B1 (de) Anbieten von inhalt aus mehreren diensten
US7089295B2 (en) Customizing content provided by a service
DE69838257T2 (de) Verfahren zum erweitern der hypertext markup sprache (html) zur unterstützung von unternehmungsanwendungsdatenbindung
US8260844B2 (en) Information messaging and collaboration system
DE69831307T2 (de) System und Verfahren zur Netzzugriffsverwaltung
US7406498B2 (en) Dynamic integration of web sites
US20030189585A1 (en) Template-driven process system
DE19962192A1 (de) Verfahren und System zur Inhaltskonvertierung von elektronischen Daten für drahtlose Vorrichtungen
AU2001293254A1 (en) Accessing data stored at an intermediary from a service
KR20090005097A (ko) 웹 커뮤니티 및 웹 애플리케이션에 대해 데이터를 변환하는시스템 및 방법
US20040143795A1 (en) Display data creating technique for automatically Providing efficient representation of portal pages with improved visual recognition
KR100918503B1 (ko) 웹사이트 링크정보를 이용한 웹페이지 정보 전달 방법 및 그 시스템
US20070233812A1 (en) Common communication framework for network objects
JP2000298646A (ja) Wwwサーバーシステム
DE10045409A1 (de) Modellierung von Verknüpfung und Navigation in einem Hostsystem mit alten Beständen
US20070240048A1 (en) A standard communication interface for server-side filter objects
DE10219899A1 (de) Mehrkanal-Übermittlungssystem
JP2003036264A (ja) マニュアル提供装置及びその方法
DE10313074A1 (de) Verfahren und Vorrichtung zur Informationsverbreitung in einem Datennetz mit mehreren Benutzerendgeräten

Legal Events

Date Code Title Description
8364 No opposition during term of opposition