DE202008018625U1

DE202008018625U1 - Kommunikation zwischen Domänen

Info

Publication number: DE202008018625U1
Application number: DE202008018625.0U
Authority: DE
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2007-05-28
Filing date: 2008-05-27
Publication date: 2017-02-14
Anticipated expiration: 2018-05-28
Also published as: US20080298342A1; US8032584B2; JP5241827B2; EP2171675A1; CN101772780A; CN101772780B; US8316078B2; AU2008256604A1; EP2171675A4; CA2689255A1; US20110022730A1; WO2008148111A1; CN107093093A; US20120066296A1; AU2008256604B2; JP2010530570A; CA2689255C; US7809785B2

Abstract

Computerimplementiertes System für die Durchführung von Kommunikation zwischen Domänen in einem Webbrowser, wobei das System eingerichtet ist Folgendes zu implementieren: das Empfangen erster Daten von einer ersten Domäne an einem Router, der mit einer oder mehreren Domänen außer der ersten Domäne verbunden ist; das Identifizieren der einen oder mehreren Domänen für den Empfang von Daten, die mit den empfangenen Daten verbunden sind, am Router; und das Übertragen der zweiten Daten, die mit den empfangenen Daten verbunden sind, an die eine oder mehreren Domänen.

Description

TECHNISCHES GEBIET
Dieses Dokument erörtert Mechanismen und Techniken für die Kommunikation zwischen Webseiten, wie z. B. iframes, die mit verschiedenen Domänen verbunden sind.
Unter Schutz gestellt werden und Gegenstand des Gebrauchsmusters sind dabei, entsprechend den Vorschriften des Gebrauchsmustergesetzes, lediglich Vorrichtungen wie in den beigefügten Schutzansprüchen definiert, jedoch keine Verfahren. Soweit nachfolgend in der Beschreibung gegebenenfalls auf Verfahren Bezug genommen wird, dienen diese Bezugnahmen lediglich der beispielhaften Erläuterung der in den beigefügten Schutzansprüchen unter Schutz gestellten Vorrichtung oder Vorrichtungen.
HINTERGRUND
Viele von Internetnutzern durchgeführte Suchen beinhalten gewisse geografische Komponenten. Die Suche selbst kann geografische Informationen umfassen, z. B. eine Adresse, für die eine Karte und Wegbeschreibungen gesucht werden. Die Suche kann außerdem implizit geografische Ergebnisse erfordern, zum Beispiel wenn die Suche den Namen eines Unternehmens mit einem physischen Ort umfasst. Solche Suchen können von einem Informationsdienstanbieter, wie Google Maps, empfangen und/oder die Ergebnisse können von einem solchen geliefert werden.
Anwendungsprogrammierschnittstellen (Application Programming Interfaces, API) können es Fremdanbietern erlauben, die Funktionalität eines geografischen Informationsanbieterdienstes zu erweitern. Zum Beispiel haben Programmierer mithilfe einer API Daten aus Wohnungs- und Hausverzeichnissen genommen und Anwendungen erstellt, die diese Auflistungen auf einer Karte anzeigen, z. B. mit Google Maps (z. B. http://www.housingmaps.com/).
KURZDARSTELLUNG
Dieses Dokument beschreibt Mechanismen und Techniken, die eingesetzt werden können, um eine Interaktion mit Webanwendungen bereitzustellen, die Komponenten aus verschiedenen Domänen umfassen können, z. B. die Bereitstellung interaktiver Karten von einem Dienst wie Google Maps. Zum Beispiel können tragbare Programmmodule in Form von Gadgets in eine Webanwendungshauptseite integriert werden und sie können mit der Hauptseite kommunizieren, wobei de Gadgets von einer Domäne gehostet werden und die Hauptanwendung von einer anderen Domäne gehostet wird. Die Kommunikation kann erfolgen, auch wenn ein Webbrowser sich bemüht, die Kommunikation zwischen Domänen zu beschränken.
In einer Implementierung wird ein computerimplementiertes Verfahren für die Durchführung von Kommunikation zwischen Domänen in einem Webbrowser offenbart. Das Verfahren umfasst den Empfang erster Daten von einer ersten Domäne an einem Router, der mit einer oder mehreren Domänen außer der ersten Domäne verbunden ist, die Identifizierung der einen oder mehreren Domänen am Router für dem Empfang von Daten, die mit den empfangenen Daten verbunden sind, und das Senden zweiter Daten, die mit den empfangenen Daten verbunden sind, an eine oder mehrere Domänen. Die zweiten Daten können die ersten Daten umfassen und die zweiten Daten können vom Router zu der einen oder den mehreren Domänen gesendet werden. Außerdem können die erste Domäne und die eine oder mehreren Domänen außer der ersten Domäne jeweils durch einen Frame identifiziert werden und der Router kann durch einen Frame identifiziert werden. Die Frames können iframe-Elemente umfassen.
In einem Aspekt können die eine oder mehreren Domänen jeweils Programmmodule, z. B. Gadgets, implementieren. Das Verfahren kann auch den Empfang von Fremddaten von einer der einen oder mehreren Domänen am Router und die Bereitstellung der Fremddaten für die erste Domäne umfassen. Außerdem kann das Verfahren die Bereitstellung der Fremddaten an mindestens einigen der einen oder mehreren Domänen umfassen. Das Verfahren kann außerdem das Senden der ersten Daten des Routers, der mit der einen oder den mehreren Domänen außer der ersten Domäne verbunden ist, von einem Router umfassen, der mit der ersten Domäne verbunden ist. Außerdem kann das Verfahren den Empfang mehrerer Gruppen von Daten am Router umfassen, der mit der ersten Domäne verbunden ist, und die Kombination der mehreren Gruppen von Daten in einem einzigen Paket vor dem Senden der mehreren Gruppen von Daten an den Router, der mit der einen oder den mehreren Domänen verbunden ist. Das Verfahren kann außerdem die Sortierung der mehreren Gruppen von Daten vor Senden des Pakets umfassen.
In einer anderen Implementierung wird ein computerimplementiertes System offenbart. Das System umfasst eine erste Anwendung, die auf einer Webseite angezeigt wird und in einer ersten Domäne betrieben wird, die mit einer Webanwendung verbunden ist, eine oder mehrere Anwendungen, die auf der Webseite angezeigt werden und in einer oder mehreren der Domänen betrieben werden, die mit der Webanwendung verbunden sind, und ein erstes Relais, das der ersten Anwendung entspricht, und den Empfang von Daten von der ersten Anwendung und die Verteilung der empfangenen Daten für den Empfang durch die eine oder mehreren Anwendungen bewirkt. Das System kann außerdem ein zweites Relais umfassen, das der einen oder den mehreren Anwendungen entspricht, um Daten vom ersten Relais zu empfangen und die Daten an die eine oder die mehreren Anwendungen zu verteilen. Das erste Relais kann so konfiguriert sein, dass es Daten vom zweiten Relais empfängt und die empfangenen Daten der ersten Anwendung bereitstellt.
In einem Aspekt sind die erste Anwendung und die eine oder mehreren anderen Anwendungen so konfiguriert, dass sie auf einer gemeinsamen Webseite angezeigt werden. Außerdem kann das erste Relais mehrere Datengruppen in einem einzelnen Paket verpacken, bevor es das einzelne Paket an das zweite Relais sendet. Das System kann außerdem eine Vielzahl von Frames umfassen, worin ein Frame der Vielzahl von Frames eine Anzeige der ersten Anwendungen definiert, und die anderen Frames der Vielzahl von Frames Anzeigen der einen oder mehreren anderen Anwendungen definieren. Die erste Anwendung kann eine Kartenanwendung umfassen und die eine oder mehreren Anwendungen können Gadgets umfassen.
In noch einer anderen Implementierung wird ein computerimplementiertes System offenbart. Das System umfasst eine erste Anwendung, die auf einer Webseite angezeigt wird und in einer ersten Domäne betrieben wird, die mit einer Webanwendung verbunden ist, eine oder mehrere Anwendungen, die auf der Webseite angezeigt werden und in einer oder mehreren der Domänen betrieben werden, die mit der Webanwendung verbunden sind, und Mittel für die Kommunikation von Daten zwischen der ersten Anwendung und der einen oder mehreren Anwendungen.
Die Details einer oder mehrerer Ausführungsformen sind in den begleitenden Zeichnungen und der nachfolgenden Beschreibung dargelegt. Andere Merkmale, Objekte und Vorteile sind aus der Beschreibung und den Zeichnungen sowie aus den Patentansprüchen ersichtlich.
BESCHREIBUNG DER ZEICHNUNGEN
1A ist eine exemplarische Anzeige einer Kartenanwendung, die mit zwei tragbaren Programmmodulen interagiert.
1B zeigt Elemente aus der Anzeige von 1A basiert.
2 zeigt ein konzeptionelles Diagramm eines Systems und Prozesses für die Koordination einer Kartenanwendung mit zwei tragbaren Programmmodulen.
3 ist ein schematisches Diagramm eines exemplarischen Systems für die Integration tragbarer Programmmodule mit einem Kartensystem.
4A und 4B sind Ablaufdiagramme von Prozessen für den Betrieb kartenbasierter tragbarer Programmmodule.
5A und 5B sind Schwimmbahn-Diagramme von Prozessen für die Koordination des Betriebs tragbarer Programmmodule und einer Kartenanwendung.
6 ist ein Ablaufdiagramm eines Prozesses für die Koordination der Kommunikation zwischen Domänen, die von einem Webbrowser angezeigt werden.
7 ist ein Schwimmbahn-Diagramm eines Prozesses für das Senden von Daten zwischen Domänen auf einer von einem Browser angezeigten Webseite.
8 ist ein Screenshot, der ein Beispiel einer Kartenanwendung zeigt, die in Koordination mit zwei tragbaren Programmmodulen betrieben wird.
9 zeigt eine exemplarische Anordnung eines Containerdokuments, das eine Reihe von tragbaren Programmmodulen und eine Kartenanwendung enthält.
10 ist ein schematisches Diagramm eines exemplarischen Systems für die dynamische Erzeugung von Karten, Werbung und anderen Elementen.
11 zeigt ein Beispiel eines Computergeräts und eines mobilen Computergeräts, das zur Implementierung der hier beschriebenen Techniken verwendet werden kann.
Gleiche Verweissymbole in den verschiedenen Zeichnungen zeigen gleich Elemente an.
DETAILLIERTE BESCHREIBUNG
1A ist eine exemplarische Anzeige 100 einer Kartenanwendung, die mit zwei tragbaren Programmmodulen interagiert. Im Allgemeinen zeigt die Anzeige 100 eine Kombination der Vorhersage von hohen Temperaturen und Schneehöhen für eine Vielzahl von Skihängen. In einem Beispiel hat ein Fremdanbieter ein Gadget entwickelt, das hier als „Mapplet” bezeichnet wird, da es mit einer Kartenanwendung (mapping application) interagiert, die auf öffentliche Wetterdaten zugreift, um eine Vorhersagekarte anzuzeigen. Ein anderer Fremdanbieter hat ein Mapplet entwickelt, das auf Schneehöheninformationen von anderen öffentlichen Quellen zugreift. Im Beispiel kann, falls eine solche integrierte Anzeige nicht vorhanden ist, ein Benutzer die beiden Anwendungen getrennt betreiben müssen, um zum Beispiel mehrere Hütten mit guten Schneehöhen zu finden, sich dann diese Hütten zu merken und nach den Temperaturen bei diesen Hütten zu suchen. Im Beispiel dagegen wird jede Information, die möglicherweise von den Mashups bereitgestellt wurde, die auf eine Kartenanwendung, wie Google Maps, zugreifen, auf kombinierte Weise bereitgestellt. Außerdem werden die kombinierten Informationen auf der Kartenseite selbst angezeigt, und somit von ihr verwaltet.
In bestimmten Implementierungen kann ein solcher Ansatz eine oder mehrere der folgenden Vorteile haben. Verschiedene Module können mit einer Kartenanwendung verbunden sein und Benutzer, die eine Webseite besuchen, die mit der Kartenanwendung verbunden ist, können darauf zugreifen. Solche Benutzer können nach Modulen suchen und die Module auswählen, die ihre besonderen Anforderungen behandeln, ähnlich wie Benutzer der personalisierten Google-Startseite, oder iGoogle, allgemeine Module für die Verwendung auf einer personalisierten Seite identifizieren können. Die Kartenmodule können außerdem zusammen mit anderen Modulen, die nicht mit Karten verbunden sind, in eine personalisierte Startseite integriert werden. Außerdem können solche Kartenmodule als Ergebnis von Suchanfragen automatisch bereitgestellt werden, wenn die Auswahl eines Steuerelements in einem Suchergebnis dazu führt, dass eine Karten angezeigt wird, die Daten enthält, die für das Suchergebnis relevant sind.
Darüber hinaus können solche Module Transaktionsverarbeitungsfähigkeiten enthalten. Eine Suche nach Hotels kann zum Beispiel ein Suchergebnis produzieren, das auf ein Modul für die Anzeige relevanter Hotelsuchergebnisse auf einer Karte gerichtet ist. Die Auswahl eines bestimmten Hotels auf der Karte kann zur Weiterleitung von Informationen über das Hotel (z. B. Zimmerpreise und Verfügbarkeit) an das Modul führen, sodass ein Benutzer über das Modul ein Zimmer buchen kann.
Die Ausgabe mehrerer Module kann außerdem auf verschiedene Weise, die vom Benutzer ausgewählt werden kann, auf einer einzigen Karte kombiniert werden. Auf diese Weise können Benutzer mehrere Sätze von Daten in einer einzigen grafischen Darstellung kombinieren, die für sie wichtig sind. Solche Kombinationen können verschiedene Quellen von mit der Geografie verbundenen Inhalten nutzen, z. B. Unternehmenssuche, Wegbeschreibung, ein persönliches Adressbuch, KML(Keyhole Markup Language)-Dateien, Fahrtinformationen und andere solche Informationsquellen. Eine solche Kombination kann als Mashup von Mashups bezeichnet werden.
Unter Bezugnahme auf 1A zeigt Anzeige 100 ein Mashup von Mashups in Form von zwei tragbaren Programmmodulen 106, 108, die als Gadgets oder Mapplets implementiert sind, die die Anzeige einer Karte 112 aus einer Kartenanwendung beeinflussen. Anzeige 100 kann allgemein durch ein Suchsteuerelement 102 gesteuert werden, in das ein Benutzer mit der Geografie verbundene Suchabfrage eingeben kann. Eine Registerkarte „Karte durchsuchen” 102a wird als für das Steuerelement 102 ausgewählt angezeigt, sodass Suchabfragen auf einen Korpus allgemeiner geografischer Ortsinformationen angewandt werden. Eine Registerkarte „Unternehmen finden” 102b kann ebenfalls ausgewählt werden, auf der gesendete Abfragen einem Korpus von Unternehmensnamen entsprechen, und die Ergebnisse umfassen bestimmte Orte für übereinstimmende Unternehmen auf der Karte 112. Eine Registerkarte „Wegbeschreibung erhalten” 102c führt, wenn sie ausgewählt wird, zur Erzeugung von Wegbeschreibungen auf vertraute Weise von einem Ort zu einem anderen, z. B. von einem in einem Benutzerprofil gespeicherten Standardort zum eingegebenen Ort.
Ein Kartensteuerbereich beinhaltet einen Registerkartenbereich 104, ein Modul 106 in Form eines „Hochtemperatur”-Mapplets, ein Modul 108 in Form eines „Basislinien”-Mapplets und ein minimiertes Modul 110 in Form eines „Entfernungsmesser”-Gadgets. Der Registerkartenbereich 104 beinhaltet eine Suchergebnis-Registerkarte, die, wenn sie ausgewählt wird, die Anzeige geografischer Ergebnisse auf eine Suchabfrage veranlasst. Außerdem beinhaltet der Registerkartenbereich 104 eine MyMaps-Registerkarte, die, wenn sie ausgewählt ist, die Anzeige einer Reihe von mit dem Benutzer verbundenen Karten veranlasst. Ein Benutzer kann zum Beispiel eine Karte haben, die eine Gegend rund um seinen Heimatort anzeigt. Außerdem kann es sein, dass der Benutzer eine Karte gespeichert hat, die alle White Castle-Restaurants in einer Gegend anzeigt, wobei ein Texteingabefeld (nicht dargestellt) bereitgestellt werden kann, um eine Postleitzahl oder ähnliche Informationen für das Identifizieren der richtigen Gegend zu empfangen (oder die Gegend kann aus den Informationen empfangen werden, die in Suchsteuerelement 102 eingegeben werden). Die MyMaps-Anzeige kann zur Anzeige von Karten zusammen mit Applets führen, die vom Benutzer mit diesen Karten verbunden wurden.
Eine Mapplets-Registerkarte wird im Registerkartenbereich 104 als zurzeit ausgewählt angezeigt. Die Mapplets-Registerkarte stellt einen Frame dar, der ein oder mehrere iframes enthalten kann, die tragbare Programmmodule implementieren, zum Beispiel in Form von Mapplets. Modul 106 ist ein erweitertes Modul, das auf eine Datenbank mit Wetterinformationen zugreift, die vorhergesagte hohe Temperaturen in einem gesamten interessanten Gebiet enthält, zum Beispiel in den gesamten Vereinigten Staaten. Die Temperaturen sind mit der Geografie verbunden und können somit auf einer Karte, z. B. Karte 112, angezeigt werden. Es werden zwei Steuerelemente angezeigt, die von Modul 106 erzeugt wurden, und ihre Auswahl kann dazu führen, dass Temperaturen für den aktuellen Tag oder den nächsten Tag abgerufen werden. Die Auswahl der Steuerelemente kann, wie unten näher beschrieben, dazu führen, dass Temperaturdaten aus einer Datenquelle abgerufen und dann an einen Kartenserver gesendet werden, der Code für Karte 112 erzeugt.
Modul 108 zeigt ein „Basislinien”-Gadget, das Informationen über die „Basis”-Höhe des Schnees in verschiedenen Skigebieten erhält. Modul 108 gibt die Informationen dann an eine Engine weiter, die mit Karte 112 verbunden ist, sodass die Basisinformationen auf Karte 112 an den entsprechenden geografischen Orten grafisch dargestellt werden. Außerdem wird Modul 110 in komprimierter Form dargestellt und kann erweitert werden, falls und wenn ein Benutzer das Modul verwenden möchte. Modul 110 wird als „Entfernungsmesser” bezeichnet und es kann, wenn es aufgerufen wird, mit Karte 112 interagieren, um die Auswahl von Punkten auf Karte 112 durch einen Benutzer zu erfahren, und es kann dann eine Entfernung zwischen zwei gewählten Punkten berechnen. Andere Module können ebenfalls bereitgestellt werden und ein Benutzer kann von einem zentralen Clearinghouse der Module auf sie zugreifen, ähnlich wie Benutzer auf allgemeine Gadgets von iGoogle aus zugreifen können.
Karte 112 zeigt die Ergebnisse, die durch Verwendung der anderen abgebildeten Komponenten erzeugt werden. Karte 112 beinhaltet eine Standardkarte, die gemäß der Benutzerauswahl positioniert und dimensioniert ist, zum Beispiel auf eine Postleitzahl zentriert, die im Suchsteuerelement 102 durch den Benutzer eingegeben wurde. Als Teil der Karte 112 überlagert sind Temperatur 114 und Basisindikator 116. Temperatur 114 kann eine von mehreren mit der Geografie verbundenen Temperaturen sein, die durch Modul 106 an eine Kartenanwendung weitergegeben wurden, z. B. maps.google.com. Ähnlich kann Basisindikator 116 einer von mehreren verschiedenen, mit der Geografie verbundenen Indikatoren sein, die durch Modul 108 an die Kartenanwendung weitergegebenen wurden. Indem die Kartenanwendung gemeinsam auf Sendungen sowohl von Modul 106 als auch von Modul 108 reagiert, können einem Benutzer zwei verschiedene Informationen präsentiert werden, die andernfalls in einer einzelnen, praktischen Anzeige nicht verfügbar wären.
1B zeigt Elemente aus der Anzeige von 1A als generische Objekte, die die tatsächliche Anzeige überlagern in 1A basiert. Verschiedene Elemente für eine bestimmte Implementierung einer Webseite, die Module anzeigt und Karten anzeigt, werden hier zur Erklärung dargestellt, die Auswahl bestimmter Elemente ist aber nicht als einschränkend gedacht. Die Module werden als Code implementiert, der hier als Mapplet-Stub bezeichnet wird, in einem iframe, das in einer Karten-HTML-Seite 120 eingebettet ist. Mapplet-Stub 122 kann zum Beispiel Code für die Implementierung von Steuerelement 106 darstellen in 1A basiert. Ähnlich kann Mapplet-Stub 123 Code für die Implementierung von Steuerelement 108 darstellen in 1A basiert. Das HTML-Dokument im iframe, das zum Hosten des Mapplets verwendet wird, wird als die Mapplet-Seite bezeichnet und kann zum Beispiel HTML-, CSS- und Scriptcode enthalten. Das Mapplet-Stub 122, 123 kann außerdem eine Mapplet-API (und zugehörige Bibliothek) für die Kommunikation mit einem Server beinhalten, auf dem eine Anwendung für die Erzeugung von Karte 120 läuft.
Jedes Mapplet, das eine besondere Form eines tragbaren Programmmoduls ist (d. h. ein Programm, das eine festgelegte Funktion durchführt und in eine Vielzahl von Umgebungen eingefügt werden kann, z. B. in verschiedene iframes auf verschiedenen Webseiten), kann Metadateneigenschaften, Benutzervoreinstellungen mit Standardwerten, HTML-Text und Scriptcode enthalten. Das Script ermöglicht es dem Mapplet, Verhalten und Funktionen zu implementieren. Der Code wird in einem iframe ausgeführt, das auf einer Domäne gehostet wird, die sich von der Domäne für die Kartenanwendung unterscheidet, und er kommuniziert mithilfe von frameübergreifenden Aufrufen oder Aufrufen zwischen Domänen mit der Kartenanwendung. Eine solche Trennung des Codes durch Frames sorgt für ein gewisses Sicherheitsniveau, da die Bearbeitung der Karte durch den Mapplet-Code auf den Umfang der bereitgestellten API eingeschränkt ist, und nicht den vollständigen Umfang der DOM API umfasst. Solche Einschränkungen werden normalerweise durch den Browser auferlegt, der den Code ausführt.
Dem Mapplet-Code kann außerdem Zugriff auf externe Daten-Feeds gegeben werden, wie unten näher erklärt. Ein HTTP-Proxydienst kann solchen Zugriff bereitstellen und der Proxy kann unter bestimmten Umständen die Daten zwischenspeichern oder Transaktionen mit einem Backend ausführen. In dieser Situation können Standardmechanismen der Implementierung eines Proxys verwendet werden. In bestimmten Implementierungen kann der Mapplet-Code auch Zugriff auf benutzerspezifische Daten haben, z. B. das Adressbuch des Benutzers, das auf einem lokalen Client oder in einer zentralen Datenbank gespeichert ist. Außerdem kann Sicherheit für den Zugriff auf solche Informationen bereitgestellt werden, z. B. indem ein Inhaber-Token gefordert wird, das erst gewährt wird, nachdem der Benutzer explizit für einen solchen Zugriff auf einen Dienst angegeben wurde. Eine solche Implementierung könnte zum Beispiel einen automatischen oder halbautomatischen Zugriff auf Adressinformationen bei der Erzeugung von Wegbeschreibungen auf einer Karte erlauben (z. B. von der Adresse eines Benutzers zur Wohnung eines Freundes). Außerdem kann der Mapplet-Code auf andere externe Datenanbieter zugreifen, z. B. den Google Base-Datenspeicher.
Der Teil der HTML-Seite 120, der außerhalb der iframes aufgeführt wird, wird Mapplet-Host 126 genannt. Objekte, die in der Kartenanwendung in dieser Gegend leben, werden Hostobjekte genannt, und ihre Proxys im Mapplet-Stub können Stub-Proxys genannt werden. Hostobjekte können aus Informationen erzeugt werden, die von einem Mapplet-Stub bereitgestellt werden, und sie können ein Verhalten haben, das von einem Mapplet-Stub verfolgt werden kann. In der Figur können zum Beispiel Hostobjekte 128, 130 jeweils Temperaturen mit Informationen, die mit der Geografie verbunden sind, darstellen, die dem Host 126 von Mapplet-Stub 122 geliefert wurden. Die Stub- und Hostfunktionen können durch entsprechend bereitgestellte Bibliotheken unterstützt werden.
In bestimmten Implementierungen, z. B. wenn der Mapplet-Code aus einer vertrauenswürdigen Quelle stammt, kann der Mapplet-Code von derselben Domäne aus ausgeführt werden, wie die Kartenanwendung selbst. Eine solche Implementierung kann einen schnelleren, synchronen und effizienteren Betrieb erlauben. Die Interaktion mit der Kartenanwendung in solchen Implementierungen kann über eine Standard-API für die Kartenanwendungen erfolgen, z. B. die Google Maps-API.
2 zeigt ein konzeptionelles Diagramm eines Systems 200 und Prozesses für die Koordination einer Kartenanwendung mit zwei tragbaren Programmmodulen. Im abgebildeten Beispiel umfasst System 100 ein Clientgerät 202 und eine Reihe von Servern 204, 210, 212 und 214, die Daten für den Betrieb von Clientgerät 202 bereitstellen. Im Allgemeinen ist das System 200 so konfiguriert, dass es Funktionen wie jene bereitstellt, die in 1A gezeigt werden, mit der Verwendung von tragbaren Programmmodulen (z. B. Gadgets/Mapplets), um mit einer Kartenanwendung zu interagieren. Als Folge kann ein Benutzer von Clientgerät 202 bestimmte Module für die Bereitstellung benutzerdefinierter Ergebnisse wählen, die mit einer Karte verbunden sind, und er kann dann Daten ansehen, die für die Anzeige auf der Karte oder auf mehreren Karten formatiert sind.
Das Clientgerät 202 kann mit einem Webbrowser oder einer anderen, mit dem Internet verbundenen Anwendung bereitgestellt werden. Der Webbrowser kann Mark-up-Code und anderen ähnlichen Code wie JavaScript-Code ausführen, den er von verschiedenen Servern erhält, an die er Anfragen stellt. Der tragbare Codeserver 210 kann zum Beispiel Mark-up-Code für den Browser bereitstellen, einschließlich Code für Module, die mit einem Benutzer des Clientgeräts 202 verbunden sind. Der Benutzer kann zum Beispiel ein Konto haben, das mit dem tragbaren Codeserver 204 verbunden ist, und er kann durch den Codeserver 204 identifiziert werden (z. B. über serverseitige Informationen oder über clientseitige Informationen wie ein Cookie), und ihm kann eine Liste von MyMaps bereitgestellt werden, die der Benutzer vorher konfiguriert hat. Er kann dann eine der Karten auswählen und Code, der mit der Karte verbunden ist, kann für die Ausführung im Browser geliefert werden.
Zum Beispiel kann Mark-up-Code geliefert werden, der verschiedene Formen von HTML-Code umfassen kann, z. B. Code für die Erzeugung eines tragbare Programmmoduls (z. B. Mapplet) auf einem Display von Clientgerät 202. Das tragbare Programmmodul kann Teil eines iframe auf einer Webseite sein, das durch ein Containerdokument dargestellt wird. Im Allgemeinen ist ein iframe ein HTML-Dokument, das in einem andere HTML-Dokument mithilfe eines iframe-Elements eingebettet sein kann. Das Dokument, in dem der iframe eingebettet ist, in diesem Beispiel das Containerdokument, kann rund um den iframe erzeugt werden, während das iframe selbst noch erzeugt wird. Der Code für das Containerdokument und für den iframe kann durch den tragbaren Codeserver 210 oder aus anderen Quellen bereitgestellt werden.
HTML-Beispielcode für die Bereitstellung eines iframe in einer Webseite umfasst Folgendes:
Wie dieser Code zeigt, kann sich das iframe-Element auf ein Dokument beziehen, das in den iframe eingefügt werden soll, Abmessungen für den iframe und darauf, ob das Blättern im iframe erlaubt sein soll. Das Dokument im iframe kann durch ein anderes Dokument ersetzt werden oder es kann geändert oder aktualisiert werden, ohne das Containerdokument (z. B. die umgebende Seite) zu aktualisieren, indem das „Ziel”-Attribut eines HTML-Ankers oder JavaScript verwendet wird, wie zum Beispiel in einer AJAX-Implementierung. Ähnliche Anzeigen können zum Beispiel durch Bearbeiten des DOM-Baums eines Dokuments erzeugt werden.
Das vom Clientgerät 202 erhaltene tragbare Programmmodul kann mit dem Containerdokument, mit dem tragbaren Codeserver und mit den anderen Servern 204, 212 und 214 kommunizieren. Der Kartenserver 204 empfängt Anfragen vom Clientgerät 202 und stellt grafische geografische Informationen bereit, im Allgemeinen in Form von Karten, die 2D-Karten, 3D-Karten oder andere Formen von Karten sein können. Außerdem kann Kartenserver 204 Geodaten vom Clientgerät 202 oder von anderen Quellen erhalten, und er kann die Informationen mit Orten auf einer Karte verbinden und die Informationen auf eine Weise zurückgeben, dass das Clientgerät 202 die Daten über die Karte anzeigen kann. Die Kommunikation zwischen Code, der auf dem Clientgerät 202 (z. B. wie durch den tragbaren Codeserver 210 bereitgestellt) ausgeführt wird, und dem Kartenserver 204 kann gemäß einer veröffentlichten Anwendungsprogrammierschnittstelle (API) erfolgen, wie unten näher erklärt.
Der Werbeserver 214 kann außerdem Anfragen von Code empfangen, der auf dem Clientgerät 202 betrieben wird, und er kann Werbung erzeugen, die auf die Anfragen zielt. Zum Beispiel können Anfragen für Informationen in einer bestimmten Gegend, neben der Erzeugung einer Karte für diese Gegend, auch dazu führen, dass Werbeserver 214 Werbung erzeugt, die mit der Gegend verbunden ist. Die Werbung kann auch auf mehr als eine Geografie der Anfrage zielen. Wenn eine Anfrage zum Beispiel „Doughnuts 02128” lautet, kann die Werbung auf Konzepte, wie „Doughnut”, „Frühstück” oder „Essen”, abzielen und die Geografie kann auf die Gegend von Boston zielen.
Die erzeugte Werbung kann als Textwerbung am Rand des Bildschirms präsentiert werden, oder sie kann in eine Karte einbezogen werden, die einem Benutzer präsentiert wird. Wenn die Werbung in einer Karte präsentiert wird, können die Ergebnisse vom Werbeserver 214 in einem geeigneten Format an den Kartenserver 204 oder direkt an den Client 202 gesendet werden. Als Folge können die verschiedenen Dunkin Donut-Läden auf der Karte als Teil eines Suchergebnisses angezeigt werden, wenn Dunkin Donuts sich für Werbung über das System entschieden hat.
Der Werbeserver 214, tragbare Codeserver 210 und Kartenserver 204 sind in 2 als mit einem gemeinsamen Netzwerk 208 verbunden dargestellt, das getrennt von einem zentralen Netzwerk 206, z. B. dem Internet, besteht. Das Netzwerk 208 kann angeben, dass die Server 204, 210 und 214 durch einen einzigen Informationsanbieter betrieben werden, z. B. Google. Auch wenn zur Klarheit als getrennte, einzelne Server dargestellt, können die hierin erörterten Dienste auf eine Vielzahl von Arten bereitgestellt werden, auch wenn Kartendienste im Allgemeinen aus Effizienzgründen von einem Teilsystem bereitgestellt werden, das von Werbediensten getrennt ist, und die Bereitstellung des tragbaren Code kann in einer Domäne erfolgen, die von der Domäne für die Kartendienste getrennt ist, sowohl aus Effizienz- als auch aus Sicherheitsgründen (z. B. so, dass die tragbaren Programmmodule, die von Dritten gesendet werden, die Kartenanwendung nicht anders als über eine Standard-API beeinflussen können).
Der tragbare Code-Server 210 ist so dargestellt, dass er Code von derselben Organisation bereitstellen, wie Werbung und Karten. In verschiedenen Implementierungen kann jedoch Clientgerät 202 Code, und insbesondere Code für tragbare Programmmodule, von Fremdanbietern erhalten. In solchen Situationen können Karteninformationen vom Kartenserver 204 erhalten werden und Code, der Teil der Webseite des Benutzers ist, kann auf andere Orte verweisen (z. B. mithilfe der oben gezeigten iframe-Definition), damit Code in den tragbaren Programmmodulen ausgeführt wird. Das System 200 kann außerdem so implementiert sein, dass es die Verwendung von tragbarem Programmmodulcode nur von der Organisation erlaubt, die die Kartenanwendung liefert (auch wenn er von einer anderen Domäne stammt), sodass die Integrität des Codes problemlos überprüft und aufrechterhalten werden kann.
Pfeile mit Buchstaben in 2 zeigen ein Beispiel einer Reihe von Operationen, die von den Komponenten in System 200 durchgeführt werden. Wie durch Pfeil A dargestellt, fordert das Clientgerät 202 anfänglich eine Webseite (z. B. durch einen Benutzer, der einen MyMaps-Link auswählt) vom Kartenserver 204 an, zum Beispiel, indem er eine HTTP-Anfrage an maps.google.com richtet. Die Zielorganisation (in diesem Beispiel Google, Inc.) kann die Anfrage einem Kartenserver und einem oder mehreren anderen Servern liefern. Die Organisation kann zum Beispiel den Benutzer von Clientgerät 202 als registriertes Mitglied der Organisation identifizieren, zum Beispiel durch Abfragen eines Cookies, das auf Clientgerät 202 gespeichert ist, oder durch Abstimmen einer Sitzungs-ID mit einem angemeldeten Benutzer. Die Organisation kann dann die Anfrage des Benutzers an den tragbaren Codeserver 210 weiterleiten, der bestimmen kann, dass eines oder mehrere tragbare Programmmodule mit der personalisierten Kartenseite oder personalisierten Webseite des Benutzers verbunden sind. Der Kartenserver 204 kann außerdem anfänglich Code für eine Hauptseite liefern und dieser Code kann sich auf den tragbaren Codeserver 210 beziehen, z. B. in den Definitionen von iframes auf der Seite. Die Server 204, 210 können dann Kartenseitencode und tragbaren Programmmodulcode liefern, auf den durch iframes im Kartenseitencode verwiesen wird, wie durch Pfeile B1 (für Kartendaten) und B2 (für tragbaren Programmmodulcode) dargestellt.
Das Clientgerät 202 kann dann die Kartenseite anzeigen, die Standardwerte beinhalten kann, die auf der Karte angezeigt werden, zum Beispiel durch Anzeigen einer leeren Karte, die auf einen „Heimat”-Ort zentriert ist, der mit dem Benutzer verbunden ist. Das tragbare Programmmodul kann Initialisierungswerte an die Hauptkartenseite weitergeben, zum Beispiel als unten erörterte Kommunikation zwischen Domänen. Die tragbaren Programmmodule auf der Kartenseite können dann vom Benutzer bearbeitet werden, um Daten zu identifizieren, die für die Anzeige auf der Karte gesammelt werden sollen. In einem Immobilienmodul kann der Benutzer zum Beispiel Arten von anzuzeigenden Häusern anzeigen (z. B. Reihen- oder Einfamilienhäuser) und er kann außerdem einen Preisbereich auswählen, z. B. aus Dropdown-Feldern. Nach Auswählen der entsprechenden Parameter kann der Benutzer sich entscheiden, die Parameter zu senden, was die Erzeugung einer Anfrage durch den Code in den relevanten Programmmodulen verursachen kann, wobei die Anfrage an den Geodatenserver 212 gerichtet ist (Pfeil C). Der Geodatenserver 212 kann alle Arten von Daten enthalten und kann besonders relevant sein, wenn die Daten mit einer geografischen Kennung verbunden sind. Wenn zum Beispiel Immobilienlisten gesucht werden, können die Adressen von Häusern in einer Datenbank mit der Geoinformationen für die Listen darstellen.
Die mit den Listen verbundenen Daten können dann an das Modul zurückgegeben werden, die diese anfordert (Pfeil D) und sie können dann dem Kartenserver 204 zur Interpretation und Hinzufügung zur Karte gesendet werden, die dem Benutzer angezeigt wird (Pfeil E). Die Daten können, in einigen Implementierungen, auch direkt vom Geodatenserver 212, dem Kartenserver 204 oder einem ähnlichen Server bereitgestellt werden, ohne sie über das tragbare Programmmodul auf dem Clientgerät 202 zu leiten.
Beim Empfang am Kartenserver 204 kann es sein, dass die Informationen nicht entsprechend geocodiert sind. Die Informationen können zum Beispiel so formatiert sein, dass sie die Straßenadresse beschreiben. Der Kartenserver 204 kann somit anfänglich die empfangenen Informationen in geocodierte Informationen umwandeln, zum Beispiel durch Umwandeln von Straßenadressen in Paare aus Breitengrad/Längengrad. Die geocodierten Informationen können dann in Bezug auf die Karte lokalisiert werden und jede Information kann demgemäß formatiert sein. Die Informationen können dann an das Clientgerät 202 für die Anzeige mit und Überlagerung auf den Karten weitergeleitet werden (Pfeil F1.)
In bestimmten Implementierungen kann auch zielgerichtete Werbung vom System 200 bereitgestellt werden. Diese Werbung kann auf Basis von Wörtern oder Konzepten ausgewählt werden, die in den Geodaten enthalten sind, die anfänglich zusammen mit einem Hinweis auf das geografische Gebiet, das einem Benutzer auf der Karte angezeigt werden soll, an den Werbeserver 214 gesendet werden können. Der Werbeserver 214 kann dann entsprechende Werbung auswählen, die auf das bestimmten Konzept und das geografische Gebiet gerichtet ist, und er kann diese Werbung bereitstellen, einschließlich geocodierter Daten, damit die Werbung an den entsprechenden Orten auf der Karte platziert werden kann. Der Werbeserver 214 kann zum Beispiel eine bestimmte Restaurantkette als relevant für einen Benutzer identifizieren, er kann Adressen verschiedener der Restaurantketten in ein geocodiertes Format (z. B. Breitengrad/Längengrad) umwandeln, und er kann die Werbung dem Clientgerät 202 direkt oder indirekt über den Kartenserver 204 liefern, sodass die Werbung für den Empfang durch das Clientgerät 202 formatiert und auf der Karte angezeigt wird.
Schlüsselwörter für die Auswahl von Werbung können ebenfalls mit dem bestimmten Modul verbunden werden, um Informationen aufzurufen. Zum Beispiel kann ein Modul so programmiert sein, dass es ein bestimmtes Schlüsselwort in die Anfrage einbezieht, sodass das Schlüsselwort für ausgewählte zielgerichtete Werbung verwendet werden kann. Das Beispielmodul für die Anzeige von Häusern für den Verkauf kann zum Beispiel mit seiner Sendung einen Begriff, wie „Immobilien”, enthalten, damit einem Benutzer Werbung für Baumaterialien und Renovierungsdienstleistungen bereitgestellt werden kann. Außerdem können Schlüsselwörter für ein Modul bei einem Server, zum Beispiel Werbeserver 214, gespeichert werden, sodass eine Kennung für das bestimmte Modul nur dem Werbeserver bereitgestellt werden muss und der Werbeserver dann den/die entsprechenden Begriff(e) für dieses Modul nachschlägt.
Das Sammeln von Informationen aus dem Containerdokument auf dem Clientgerät, die Sendung dieser Informationen zum Kartenserver 204 und zum Geodatenserver 212 sowie die Bereitstellung von Werbung kann alles in entsprechenden Implementierungen zumindest teilweise erfolgen, während die Seite, die mit dem Containerdokument verbunden ist, geladen wird. Daher kann die Anzeige, die vom tragbaren Programmmodul erstellt wird, zum Beispiel eine bestimmte Karte, die Daten anzeigt, die mit einem tragbaren Programmmodul verbunden sind, durch einen Benutzer sofort nach Zugreifen auf und Laden der verbundenen Webseite angezeigt werden.
Die tragbaren Programmmodule können außerdem mit zusätzlichen Funktionen für das Zugreifen auf Informationen für die Anzeige mit der Webseite auf Clientgerät 202 bereitgestellt werden. Aufrufe, die durch die tragbaren Programmmodule durchgeführt werden, können bedingt oder iterativ sein. Als ein Beispiel für bedingte Aufrufe können Anfragen an den Geodatenserver 212 nur dann gesendet werden, wenn vom Modul erzeugte Steuerelemente auf eine bestimmte Weise eingestellt wurden. Es ist zu beachten, dass verschiedene Funktionen, die von einer Sprache, wie JavaScript und JavaFX, bereitgestellt werden, ebenfalls vom tragbaren Programmmodul implementiert werden können, was eine Vielzahl von Interaktionen ermöglicht.
Die von den tragbaren Programmmodulen produzierten Anzeigen können Metadaten, wie Hyperlinks, enthalten, die es einem Benutzer ermöglichen, mit den Ergebnissen zu interagieren. Text, der bestimmte Informationen auf einer Karte anzeigt, kann zum Beispiel mit einem Hyperlink verbunden werden, dessen Auswahl den Benutzer zu einer Webseite leitet, die mit dem Element verbunden ist. Außerdem kann das „Darübergehen” über ein auf einer Karte bereitgestellten Element zur Anzeige zusätzlicher Informationen in Verbindung mit dem Elemente auf herkömmliche Weise führen.
3 ist ein schematisches Diagramm eines exemplarischen Systems 300 für die Integration tragbarer Programmmodule mit einem Kartensystem. Im Allgemeinen beinhaltet System 300 ein Clientgerät 302, das über Netzwerk 304, z. B. dem Internet, mit einer Reihe von Servern kommuniziert, um Daten für die Erzeugung einer Karte auf Clientgerät 302 bereitzustellen. Näher dargestellt sind besondere Strukturen am Clientgerät 302, die Teile verschiedener Domänen sind, die mit Teilen einer Webseite verbunden sind, die von einem Webbrowser erzeugt wird. Das veranschaulichte Beispiel zeigt eine Anordnung für die Ermöglichung der Kommunikation zwischen den verschiedenen Domänen im Browser. Im Allgemeinen ist eine solche Kommunikation nicht empfehlenswert und schwierig, da Browser verschiedene Funktionen beinhalten, um die Kommunikation zwischen Domänen zu verhindern, die von Software verwendet werden kann, um in Teile der Software einzudringen oder sie zu übernehmen.
Unter Bezugnahme auf 3 kann das Clientgerät 302 Anfragen an Datenserver 310 senden, um Daten zu erhalten, die für Kartenanwendungen zugänglich sind, z. B. Daten, die mit Informationen verbunden sind, aus denen ein Breitengrad-/Längengrad-Ort gefolgert werden kann. Außerdem kann das Clientgerät 302 Anfragen an den Kartenserver 308 senden und Anfragen vom Clientgerät 302 können auch zum Werbeserver 306 geleitete werden, wie solche, die dargestellt sind für 2.
Konzeptionell im Clientgerät 302 dargestellt, sind eine Reihe von Softwarekomponenten für die Erzeugung einer mit Kartenabbildungen verbunden Webseite. Die Komponenten sind verschiedene Teile der Seite oder Teile von Code für die Implementierung der Seite. Die Komponenten werden zum Beispiel so implementiert, dass sie die Kommunikation zwischen Domänen zwischen einer Komponente ermöglichen, die das Containerdokument erzeugt, und den Komponenten, die tragbare Programmmodule enthalten, die mit dem Containerdokument angezeigt werden. In diesem besonderen Beispiel ist das Containerdokument eine Kartenseite, wie www.google.com, während die tragbare Programmmodule Gadgets, hier Mapplets genannt, sind, die auf der Kartenseite erzeugt werden und mit der angezeigten Karte interagieren.
Im Allgemeinen erfolgt die Kommunikation durch Verwendung unsichtbarer iframes, die als Relais für Informationen dienen, die von der Anwendung an eines oder mehrere der Module gesendet werden, und umgekehrt. Jedes einfarbige Kästchen im Clientgerät 302 stellt einen iframe auf einer Hauptkartenseite dar, während das gestrichelte Kästchen einen Zustand der Kartenanwendung 324 darstellt. Die Kommunikation zwischen den Modulen verwendet normalerweise Remote Procedure Calls (RPCs) mit flüchtigen Verbindungen, wobei eine Anfrage, die eine Antwort erwartet, die Details (z. B. Quellen-iframe, zu verwendenden Relais-URL) liefert, durch die sie die Antwort zu empfangen erwartet.
Ein Kartenrouter 322 verwaltet die Kommunikation mit der Kartenanwendung 324, und ein Modulrouter 318 verwaltet die Kommunikation mit den verschiedenen Modulen. Das Hauptfenster erstellt einen iframe für jeden Router. Ein Router-iframe ist mit jeder Domäne der iframes auf der Seite verbunden, die miteinander kommunizieren. Jedem Router-iframe werden ein Name und eine ID zugewiesen und sein src-Attribut ist auf den Ort der Router-HTML-Datei am Host eingestellt, für den der Router agiert. Die ID ist eine Kennung, mit der der Router lokalisiert werden kann, und sie wird zum Beispiel eindeutig vom Hostnamen des Routers abgeleitet. Ein Mapplet-Host in der Domäne gmodules.com kann zum Beispiel einen iframe wie folgt nehmen:
Die Router können über DOM-Manipulation durch Verzögerung ihrer Einfügung in der Seite erstellt werden, bis bekannt ist, dass sie nötig sind (z. B., wenn ein Benutzer die Registerkarte „Mapplet” auswählt). Die Erstellung der Router erfolgt ebenfalls im Allgemeinen asynchron, dahingehend, dass die Erstellung jedes Routers im Allgemeinen unabhängig von der Erstellung der anderen Router ist. Als Folge können die verschiedenen Prozesse, die Router erstellen, unter bestimmten Bedingungen eine Race-Bedingung verursachen, sodass ein Router vor einem anderen Router für die Kommunikation bereit sein kann. Um die Routerinteraktionen zu koordinieren, erstellt die Hauptseite einen Router für jede Domäne, fügt Onload-Handler (JavaScript-Funktionen) hinzu, um zu beobachten, wann jeder Router geladen wurde, und wartet, bis alle Router geladen sind, bevor die Mapplet-iframes geladen werden.
Wenn die Router erstellt sind, registriert sich jeder iframe selbst bei einem Router, damit der Router Pakete ordnungsgemäß zum iframe weiterleiten kann. Wenn die Hauptseite ein Mapplet-iframe (oder einen anderen Frame, der versuchen kann, das Kommunikationssystem zu verwenden) erstellt, sucht es den Router, der dieser Domäne entspricht, und registriert die ID des Mapplet-iframe bei jedem Router, der mit diesem Mapplet-iframe kommuniziert. Dabei kann sie (1) den Hostnamen des Mapplet-iframe aus der src dieses iframe berechnen, (2) einen eindeutigen Router/ID-Namen bilden, (3) diesen Router durch Aufrufen von „window.top.frames[nameOfRouter]” lokalisieren, (4) das Mapplet-iframe durch Aufrufen von „router.registerlframe(iframeID, relayUrl)” registrieren. In diesem Beispiel ist iframeID die ID des Mapplet-iframe und relayUrl ist die URL des Relais-iframe für die Domäne des Mapplets. Der Relais-iframe ist der Mechanismus, mit dem Datenpakete von anderen iframes zu diesem Ziel-Mapplet-iframe über den Router für die Domäne dieses Mapplets gesendet werden.
Jeder Router 318, 322 kann mit einem verbundenen Packetizer 318a bzw. 322a bereitgestellt werden, um kleine Pakete zusammenzuführen, die an eine gemeinsame Domäne gesendet werden, und die Pakete am Zielrouter aufzuteilen. Die Pakete können Datengruppen aus Anfragen durch mehrere iframes enthalten und müssen keine bestimmte Form annehmen. Die Router 318, 322 empfangen Pakete, während sie ankommen, entweder von der verbundenen Kartenanwendung 324 oder von einem oder mehreren der verbundenen Applets 312–316. Die empfangenen Pakete können Gruppen von Daten von mehreren oder für mehrere Quellen enthalten. Zum Beispiel kann Modulrouter 318 Daten von Modulen 312–316 empfangen und Kartenrouter 322 kann Daten für die Module 312–316 von der Kartenanwendung empfangen. Solche Situationen mit mehreren Geräten können in bestimmten Implementierungen häufig sein. Zum Beispiel kann Code für die Erstellung eines Markers auf einer Karte und für dessen Hinzufügung zur Karte ein Paket erfordern, um den Marker zu erstellen, und ein anderes, um ihn zur Karte hinzuzufügen. In einer solchen Implementierung würde das Hinzufügen von zehn Markern zur Karte (z. B., um zehn Suchergebnisse darzustellen) zwanzig Pakete erfordern. Als weiteres Beispiel kann es häufig vorkommen, dass die Module gleichzeitig auf Kartenereignisse, wie das Bewegungsende-Ereignis, achten. In solchen Situationen werden Pakete, die durch die Karte gesendet werden, durch den Kartenrouter 322 zusammengeführt und zu den Modulen 312–316 durch den Modulrouter 318 gesendet.
Für Übertragungen vom Kartenrouter 322 zum Modulrouter 318 kombiniert der Packetizer 322a die empfangenen Pakte und der Router 322 sendet sie über die Domänengrenze. Ein serialisierter Befehl für die Erstellung eines Markers könnte wie folgt aussehen:
101&-33.86,151.20&http://some.domain.com/marker.png
In diesem Beispiel ist 101 die ID der Methode „neuen Marker erstellen”, -33.86,151.20 ist ein serialisiertes Paar aus Breitengrad/Längengrad, das den Ort des Markers angibt, und http://.../marker.png ist das Symbol, das bei Wiedergabe des Markers verwendet wird.
Das Hinzufügen dieses Markers zur Karte wäre dann ein weiterer serialisierter Befehl wie:
15&1&17
Hier ist 15 die ID einer Methode „Überlagerung auf der Karte hinzufügen”, 1 ist die ID der Karte, zu der die Überlagerung hinzugefügt werden soll, und 17 ist die ID des Markers, der zur Karte hinzugefügt werden soll.
Die Erstellung eines zweiten Markers (mit ID 18) und sein Hinzufügen zur selben Karte (mit ID 1) würden dann zwei weitere serialisierte Befehle beinhalten
101&33.87,153.05&http://some.domain.com/marker2.png
und
15&1&18
Aus Effizienzgründen könnte der Packetizer beobachten, dass diese 4 Befehle in schneller Folge zur einer einzigen Domäne gehen. Als Folge könnte er ein einziges Paket wie folgt bilden:
101&33.86,151.20&http://some.domain.com/marker.png;15&1&17;101&33
.87,153.05&http://some.domain.com/marker2.png;15&1&18
Das Beispiel verwendet ein Semikolon, um die einzelnen Befehle in einem Paket abzugrenzen; in der Praxis kann jedes umkehrbare Schema für die Aneinanderreihung von Befehlen verwendet werden, um Pakete zu bilden. Im Allgemeinen kann das bestimmte Format der Pakete jede geeignete Form annehmen; die bestimmte, hier dargestellte Form dient der Veranschaulichung.
Der Packetizer ist so konfiguriert, dass er wartet, bevor er eine Gruppe vom Paketen gemäß einer vorher bestimmten akzeptablen Latenz für die Übertragungen sendet, und er wartet auf eine akzeptable Paketgröße. Zum Beispiel begrenzt Internet Explorer Pakete auf 4096 Bytes im URL + Hash-Fragment und auf ca. 2048 Bytes für die GET-URL. Der Router kann die verstrichene Zeit seit Ankunft des ersten zurzeit gespeicherten Geräts und die Größe der zurzeit gespeicherten Gruppe der Pakete verfolgen, und er kann das Senden einer Gruppe von Paketen auslösen, wenn ein vorher festgelegter Wert in einem der Parameter überschritten wird.
Der Router kann außerdem in bestimmten Implementierungen sicherstellen, dass die Nachrichtenreihenfolge beibehalten wird, z. B. so, dass Anfragen zum Erstellen eines Markers vor einer Anfrage zum Hinzufügen des Markers zu einer Karte verarbeitet werden. Die unsichtbaren Relais-iframes (die verwendet werden, um Pakete zwischen Routern zu senden) können mithilfe der JavaScript DOM durch Aufrufen von document.body.appendChild in den Text des HTML-Dokuments eingefügt und zur Durchsetzung der Reihenfolge verwendet werden. Außerdem kann die Sortierung in Browsern beibehalten werden, die eine Permutation der Paketreihenfolge (durch Ermöglichung der Permutation der Reihenfolge, in der iframes geladen werden) durch explizites Kennzeichnen jedes Pakets mit einem Zähler und am Empfänger durch Neuordnung der Pakete in aufsteigender Reihenfolge des Zählers ermöglichen.
Für ihren Betrieb können iframes auf Bibliotheken zurückgreifen, die die ordnungsgemäße Aktion der iframes definieren. Zum Beispiel können die Router auf eine Routerbibliothek zurückgreifen, die die Kommunikation zwischen Domänen behandelt, z. B. Bestätigungen, Zusammenführen und Aufteilen großer und kleiner Pakete und ähnliche Aufgaben. Die andere iframes können auf eine Clientbibliothek zurückgreifen, die eine API definiert und Kontext, wie Rückrufe und Servicehandler, speichert.
Die Clientbibliothek kann verschiedene Services bereitstellen, zum Beispiel einen Aufrufservice, einen Registerservice und einen Initialisierungsservice. Der Aufrufservice sendet eine Nachricht über den Router an einen anderen iframe. Die Aufrufanfrage kann Parameter für einen Ziel-iframe-ID, eine Service-ID für den Service zum Aufrufen (z. B. Hinzufügen einer Überlagerung (z. B. Marker) zu einer Karte, Öffnen eines Infofensters an einem Punkt auf der Karte, die Karte, die ein Ereignis, wie einen Mausklick, an ein Mapplet meldet und fortschrittlichere Services, wie Geocodierung (Umwandlung einer Adresszeichenfolge in einen Breitengrad und einen Längengrad) und Anfordern von Wegbeschreibungen zwischen zwei oder mehr Punkten auf einer Karte), alle Argumente, die vom Service benötigt werden, und einen Indikator, ob ein Rückruf bei Antwort erfolgen sollte, umfassen.
Ein Beispiel eines JavaScript-Aufrufs in einer Mapplet-API ist:
map.getCenterAsync();
Dies fordert an, dass die Karte den Breitengrad und Längengrad der Mitte des aktuellen Ansichtsfensters (auf der Karte dargestelltes Gebiet) zurückgibt. Dieser Aufruf erfolgt durch einen Mapplet-iframe an die Hauptseite, die die Karten enthält. Der serialisierte Befehl, der diesen Aufruf enthält, kann wie folgt aussehen:
4&1&callback5
In diesem Beispiel ist 4 die ID des Service „aktuelle Mitte der Karte erhalten”, 1 ist die ID der abgefragten Karte und callback5 ist eine ID, die der Antwort durch das Mapplet zugewiesen wird. Die serialisierte Antwort auf diese Anfrage kann wie folgt aussehen:
callbackService&callback5&33.5,-27.3
wobei callbackService die ID für den speziellen Service ist, die angibt, dass dies eine Antwort auf eine Abfrage ist, callback5 ist die ID die dem Rückruf zugewiesen ist (damit das Mapplet-Javascript weiß, wohin das Ergebnis geleitet werden soll), und 33.5,-27.3 ist der Breitengrad und Längengrad der Mitte der Karte (die an den Rückruf weitergeleitete Antwort).
Der Registerserviceaufruf registriert einen neuen Service und verbindet ihn mit einem bestimmten Handler. Nachfolgende Aufrufe an den Frame, der als Handler zugewiesen ist, können dann den Service nutzen. Aufrufe zum Registrieren eines Service können eine ID für den Service (von den iframes zu verwenden, die später den Service verwenden möchten) und einen Service-Handler umfassen. Zum Beispiel kann in einem Service, der Mapplets die Abfrage eines Kartenmittelpunkts ermöglicht, die Karte einen Service beim Kommunikationssystem registrieren, was die Service-ID (4 oben) und einen Service-Handler umfassen kann. Der Service-Handler würde wie folgt aussehen:
GMap.prototype.getCenter(){return this.center;}
Dieser Service würde die Mitte der Karte an den Aufrufer zurückgeben. Wenn ein Aufruf an die Karte erfolgt, wird die Service-ID verwendet, um zu bestimmen, an welchen Service-Handler der Aufruf erfolgt. Dieser Service-Handler wird aufgerufen und das Ergebnis (in diesem Fall die aktuelle Mitte der Karte) wird über das Kommunikationssystem an den Anrufer zurückgegeben.
Der Initialisierungsaufruf initiiert einen Client zwischen den Domänen, indem er den Client über die ID des aufrufenden Frame informiert (wie vom übergeordneten Frame aus gesehen). Ein solcher Aufruf kann einen Parameter umfassen, der eine Quell-Frame-ID identifiziert. Nach Information über die ID für einen bestimmten Frame kann das System die Weiterleitung der Informationen an den Frame bereitstellen.
Betrachten wir eine Nachricht, die von iframe „A” (dem iframe mit dem Namen/der ID „A”) an iframe „B” (den iframe mit dem Namen/der ID „B”) gesendet wird. Zuerst kontaktiert iframe A den Router wegen seiner Domäne und stellt dabei die zu sendende Nachricht, den iframe der Ziel-ID und einen Rückruf-Handler (Funktion) bereit, wenn eine Antwort erwartet wird. Danach muss der Router für den Quell-iframe A den Router für den Ziel-iframe B kontaktieren. Damit er erfährt, welchen Router er kontaktieren muss, sollte er bereits eine Zuordnung von der iframe-ID zu Routerdomäne erhalten haben. Dies wird im Initialisierungsaufruf bereitgestellt. Wenn die Hauptseite einen neuen Mapplet-iframe (oder einen beliebigen iframe, der das Kommunikationssystem verwendet) erstellt, stellt sie außerdem diese iframe-ID und seine Domäne für jeden anderen Router bereit. Dies ermöglicht es fremden iframes, diesen neuen Mapplet-iframe zu kontaktieren, wenn sie nur den Namen/die ID dieses iframe kennen.
Die Routerbibliothek stellt im Allgemeinen die Paketierung und Pflege eines Pool von iframes bereit, die für die Kommunikation verwendet werden können, um zu vermeiden, dass viele iframes erstellt und zerstört werden müssen. Eine Klasse, die mit dem Pool verbunden ist, verfolgt den aktuellen Zustand jedes iframe, der mit einem bestimmten Router verbunden ist, und bezieht durch Markierung einen iframe als gesperrt ein, wenn er erstellt wird oder wenn seine src auf ein bestimmtes Paket eingestellt ist. Wenn der iframe geladen wird, nimmt die Poolklasse an, dass das Paket geliefert wurde, und markiert den iframe als entsperrt (oder für die Wiederverwendung frei). Wenn sich verschiedene Mapplets auf verschiedene Domänen beziehen, kann ein Router für jede Domäne erstellt und mit den Mapplets für diese Domäne verbunden werden.
Ein Beispiel für die Verwendung solcher Kommunikationsstrukturen und Techniken mit einer Kartenanwendung kann eine Übertragung von einem Mapplet, z. B. Modul A 312, zum Ausfüllen einer Karten in einer Kartenanwendung 324 mit Markern umfassen, die mit „heißen” Angelplätzen verbunden sind, die auf einer mit dem Angeln verbundenen Website identifiziert werden. Das Mapplet kann anfänglich geladen und dann von einem Benutzer bearbeitet werden, um zum Beispiel eine bestimmte Art von Fisch, z. B. Schwarzbarsch, zu identifizieren. Der Benutzer kann sich dann entscheiden, die Auswahl zu senden, was dazu führen kann, dass der Mapplet-Code auf Datenserver 310 zugreift, der ein Server sein kann, auf dem lokale Angelberichte gespeichert sind, die Namen und Arten von Seen, Zahlen und Größen der im See am letzten Wochenende gefangenen Fische umfassen können.
Das Mapplet in Modul A 312 kann einen solchen Datenserver 310 auf einer Reihe von Arten kontaktieren. Erstens kann es direkt Anfragen an einen solchen Server 310 mithilfe von domänenübergreifenden Kommunikationstechniken (wie Site-übergreifende Scriptinganfragen) stellen. Zweitens kann es einen Proxyserver verwenden, z. B. den Google-Proxyserver, der von iGoogle als Teil der Google Gadgets-API bereitgestellt wird. Drittens kann es in einigen Fällen (z. B. bei Verwendung einer Kartengeocodierungs-API) fordern, dass die enthaltende Seite (die Kartenanwendung) eine Anfrage an einen Dienst (z. B. einen Google-Dienst) in ihrem Auftrag ausführt.
Der Datenserver 310 kann dann eine Liste aller solcher Seen zusammen mit Informationen über Schwarzbarsche zurückgeben, die im jeweiligen See gefangen wurden. Nach Empfang der Informationen kann die Kartenanwendung 324 veranlassen, dass die Informationen an den Kartenserver 308 weitergeleitet werden, der die mit dem Ort verbundenen Informationen in Form von Seenamen analysieren und versuchen kann, diese Informationen in Paare aus Breitengrad/Längengrad oder andere spezifische Ortsdaten umzuwandeln. Der Server 308 kann dann die Informationen in Verbindung mit den Orten der Seen an das Clientgerät 302 zurückgeben. In der ersten obigen Methode empfängt das Mapplet die Daten direkt vom Server. In der zweiten obigen Methode gehen die Anfrage und Antwort über einen Service, z. B. den Service http://gmodules.com/ig/proxy, der von Google als Teil der Google Gadgets-API bereitgestellt wird, ein Proxyserver, wie der Google-Proxyserver, leitet die Anfrage an den Remote-Server weiter, der dem Google-Proxyserver antwortet, der die Antwort an das Mapplet weiterleitet. In der dritten obigen Methode führt die Hostseite (die Kartenanwendung) die Anfrage an den Remote-Server durch, empfängt die Antwort vom Remote-Server und sendet dann diese Antwort über das Kommunikationssystem zwischen Domänen an das Mapplet.
Modul A 312 kann dann Befehle für die Erstellung von Markern für jeden See und Platzierung der Marker an jedem identifizierten See erzeugen. Wenn zum Beispiel zehn Seen durch den Datenserver 310 zurückgegeben wurden, können zwanzig Befehle erzeugt und Modulrouter 318 bereitgestellt werden. Der Packetizer kann alle diese Pakete in einem größeren Paket zusammenführen und kann einen Zeitraum warten, der mit einer angenommenen Latenz verbunden ist, die im System für die Lieferung von Paketen akzeptabel ist. Sobald der Zeitraum erreicht ist, sendet der Modulrouter 318 das Paket über die Domäne zum Kartenrouter 322, dessen Packetizer dann die inneren Pakete (die Datengruppen sind, die durch ein bestimmtes Modul gesendet werden) auseinander nimmt und sie der Kartenanwendung 324 zur Ausführung sendet, sodass Marker sich richtig auf der Karte befinden. Andere Objekte können auf ähnliche Weise ebenfalls zur Karte hinzugefügt werden.
Als Teil des Prozesses kann die Kartenanwendung 324 veranlassen, dass Werbung auf oder rund um die Karte platziert wird. Zum Beispiel kann der Webserver mithilfe von Ortsinformationen, die vom Kartenserver 308 erzeugt werden, und anderen Informationen bei der Anfrage an Datenserver 310 (z. B. „Schwarzbarsch”) Werbung abfragen, die für den bestimmten Ort und für die anderen gesammelten Informationen relevant ist. Als Folge kann Werbeserver 306 eine oder mehrere Werbungen zurückgeben, die nicht ortsspezifisch sind und die bei Empfang durch die Kartenanwendung angezeigt werden können, zum Beispiel im speziellen Werbebereich, der über einer angezeigten Karte angezeigt wird. Werbeserver 306 kann außerdem eine oder mehrere ortsspezifische Werbungen zurückgeben, die Kartenanwendung 324 veranlassen, einen Marker und andere detaillierte Informationen auf der Karte für einen Werbekunden zu erzeugen.
Diese besonderen beschriebenen Techniken für die Kommunikation, z. B. die Kommunikation zwischen Domänen, werden zur Veranschaulichung bereitgestellt. Es können auch andere geeignete Techniken verwendet werden. In bestimmten Implementierungen können die beschriebenen Techniken einen effizienten und praktischen Mechanismus erlauben, der es Objekten aus verschiedenen Domänen erlaubt, miteinander zu kommunizieren, aber auf eine Weise, die angemessen definiert und vor unehrlichen Parteien geschützt ist.
4A und 4B sind Ablaufdiagramme von Prozessen für den Betrieb kartenbasierter tragbarer Programmmodule. 4A zeigt im Allgemeinen Operationen, die von einem oder mehreren Servern durchgeführt werden können, die mit einer Kartenanwendung interagieren. Bei Kästchen 402 können die Server anfänglich einen GET-Befehl erhalten, der auf eine bestimmte URL gerichtet ist, und sie können Mark-up-Code bereitstellen, der mit der URL verbunden ist, z. B. Code für die Bildung eines oder mehrerer iframes für Mapplets und für den Betrieb von Mapplets in den iframes. Der angeforderte Code kann anfänglich Code für eine Startseite sein, zum Beispiel von einer ersten Domäne, die Code für die Erzeugung von iframes beinhalten kann, die Code von einer anderen Domäne aufrufen. Wenn der Code ausgeführt wird, kann er seine Standardparameter verwenden, um Kartendaten anzufordern, die mit den Standardparametern verbunden sind, z. B. Anzeigen einer breiten Ansicht einer Karte, die rund um den Standard- oder Heimatort eines Benutzers zentriert ist.
Es kann sein, dass ein Benutzer dem Mapplet neue Parameter bereitgestellt und angefordert hat, dass die neuen Parameter durch den Client gesendet werden. Eine solche Anfrage kann dazu führen, dass eine Meldung an einen Server einer Drittpartei (nicht dargestellt) gesendet wird, zum Beispiel einem Server, der Preise von Mietimmobilien in einem geografischen Gebiet verfolgt. Eine Reaktion vom Server einer Drittpartei kann vom Clientgerät verarbeitet und/oder an den Kartenserver in einem Format weitergeleitet werden, das mit einer API für den Kartenserver kompatibel ist (Kästchen 406). Der Kartenserver kann dann die empfangenen Informationen geografisch verbinden, zum Beispiel durch Umwandlung von Adressen in Breitengrad-/Längengradkoordinaten, und er kann Kartendaten in Verbindung mit der Anfrage bereitstellen. Der Kartenserver kann zum Beispiel Kacheln für eine Karte in einer geeigneten Zoomstufe in einem entsprechenden Gebiet übertragen und er kann außerdem Breitengrad-/Längengradinformationen für Objekte zurückgeben, die über der Karte angezeigt werden.
4B zeigt einen Prozess 420 ähnlich dem Prozess in 4A, aber aus Sicht des Clientgeräts. Bei Kästchen 422 fordert das Clientgerät anfänglich eine Kartenseite an, zum Beispiel durch einen Benutzer, der eine URL für maps.google.com auswählt, durch eine Suchmaschine, die ein Ergebnis zurückgibt, das auf die Karte weist (und das Ergebnis auswählt) oder durch andere geeignete Mechanismen. Der Kartenserver überträgt dann Code als Reaktion auf die Anfrage und kann außerdem die Art und Weise beeinflussen, wie der Code geliefert wird, wenn er bestimmt, dass der Anforderer des Codes ein registrierter Benutzer des Service ist (z. B. durch Hinzufügen von Mapplets zum Code, die für den bestimmten Benutzer personalisiert sind). Bei Kästchen 424 hat das Clientgerät den Code empfangen und kann ihn ausführen, um eine allgemeine Anzeige zu erzeugen, zum Beispiel eine Anzeige, die eine Karte der USA anzeigt, und eines oder mehrere Applets mit minimalen Informationen, die in den Mapplets bereitgestellt sind. Der Code für die Mapplets kann, wenn sie zum Beispiel in iframes implementiert werden, dazu führen, dass zusätzliche Informationen oder zusätzlicher Code für die Seite von anderen Servern abgerufen wird.
Bei Kästchen 426 gibt ein Benutzer Parameter für eines der Mapplets an, zum Beispiel durch Auswählen von Werten aus Dropdown-Listen oder durch Eingeben bestimmter Werte für leere Felder. Wenn der Benutzer sich entscheidet, die Parameter zu senden, kann das Clientgerät Daten in Verbindung mit dem Mapplet von einem Fremdanbieter (z. B. Craigslist-Listen) anfordern. Wenn Fremddaten geliefert werden, kann das Clientgerät dies dann (vielleicht nach dem Bearbeiten und/oder Neuformatieren) an den Kartenserver (Kästchen 430) für die Interpretation senden, um geokorrelierte Daten für die Ergebnisse zu erzeugen. Nachdem der Kartenserver die Anfrage verarbeitet hat, kann das Clientgerät die Kartendaten (Kästchen 432) empfangen und die Kartendaten (die auch neue Kacheln für ein anderes Gebiet der Karte enthalten können) auf der Karte mithilfe einer Kartenanwendung (Kästchen 434) anzeigen.
5A und 5B sind Schwimmbahn-Diagramme von Prozessen für die Koordination des Betriebs tragbarer Programmmodule und einer Kartenanwendung. Im Allgemeinen zeigt der Prozess 500, der in 5A dargestellt ist, einen einfachen Prozess der Bereitstellung von Kartendaten als Reaktion auf Sendungen von einem Benutzer von zwei verschiedenen Mapplets, die mit einer bestimmten Kartenanwendung verbunden sind, während der Prozess 530, der in 5B dargestellt ist, die Auswahl und Hinzufügung eines Mapplets zur personalisierten Seite eines Benutzers zeigt.
Unter Bezugnahme auf 5A greift ein Benutzer in Kästchen 502 anfänglich auf eine mit einer Karte verbundenen Seite zu und ein Server, der Mark-up-Code enthält, überträgt den Code (Kästchen 504), während ein Server, der bestimmte Kartendaten enthält, diese Daten (Kästchen 506), die mit Karten verbundene Bibliotheken und eine allgemeine Karte für die anfängliche Anzeige in der Anwendung enthalten können, liefert. Die Bereitstellung von Code und Karteninformationen kann ebenfalls durch einen einzigen Server erzeugt werden. Die allgemeinen Informationen, die durch den Codeserver und/oder Kartenserver bereitgestellt werden, können eine Liste möglicher Mapplets enthalten, die von einem Benutzer verwendet werden können.
In bestimmten Situationen können die identifizierten Mapplets kontextabhängig sein. Die Bereitstellung der Kartenanwendung kann zum Beispiel als Reaktion auf eine Suchanfrage erfolgt sein, und die Analyse der Begriffe in der Suchanfrage kann darauf hinweisen, dass eine bestimmte Art von Funktionalität in Bezug auf die Karte gewünscht wird, sodass Mapplets, die diese Funktionen behandeln, mit der allgemeinen Karte angezeigt werden. Die Mapplets können somit in einer solchen Situation mit der Karte bereitgestellt werden. In einer solchen Situation kann die Karte außerdem so positioniert werden, wie dies für die Suchanfrage relevant ist (z. B. um eine Postleitzahl in der Anfrage), und/oder Standardwerte für die Mapplets können auf Basis der Suchanfrage ausgewählt werden. Alternativ kann eine Benutzerdatenbank eingesehen werden, um Mapplets zu bestimmen, die früher durch einen bestimmten Benutzer ausgewählt wurden, und diese können als Teil einer personalisierten Anzeige erneut angezeigt werden.
Bei Kästchen 510 wählt der Benutzer bestimmte Parameter für ein erstes Gadget und sendet sie an einen Datenserver, der dann Daten zurückgibt, die für die gesendete Anfrage relevant sein könnten (Kästchen 512). Die zurückgegebenen Informationen können Informationen, wie Adressen, enthalten, die Orte angeben. Nach Empfang der Daten kann der Client Karteninformationen anfordern, die mit den Daten verbunden sind (Kästchen 514), und der Kartenserver kann die Anfrage interpretieren und die Karteninformationen bereitstellen (Kästchen 516). Nach Empfang der Informationen vom Kartenserver kann der Client eine Darstellung der Informationen auf der Karte in der Kartenanwendung hinzufügen (Kästchen 518).
Nach einiger Zeit kann sich der Benutzer dann entscheiden, Parameter für ein anderes Mapplet bereitzustellen, um ein Mashup von Mashups zu erstellen (Kästchen 520). Es kann ein ähnlicher Prozess erfolgen wie für das erste Mapplet, mit der Anfrage und der Bereitstellung von Daten (Kästchen 522), der darauffolgenden Anfragen von Karteninformationen, die mit den bereitgestellten Daten verbunden sind (Kästchen 524), der Bereitstellung von Karteninformationen vom Kartenserver (Kästchen 526), und der Anzeige der vom Kartenserver bereitgestellten Informationen (Kästchen 528). Eine solche Anzeige kann zusammen mit der früheren Anzeige aus der Interaktion mit dem ersten Mapplet erfolgen. Als Folge kann der Benutzer fähig sein, zwei bestimmte Mapplet-Anwendungen auszuwählen und eine Anzeige zu erzeugen, die Informationen aus beiden Mapplet-Anwendungen kombiniert.
Unter Bezugnahme auf 5B, die im Allgemeinen die Auswahl eines Mapplets durch einen Benutzer zur Anzeige mit einer Kartenseite und die nachfolgende Verwendung des Mapplets zeigt, wobei der Benutzer anfänglich (über den Client) auf eine Kartenseite (Kästchen 532) zugreift, und Code und allgemeine Karteninformationen empfangen kann (Kästchen 534, 536). In diesem Fall wurden jedoch vorher keine Mapplets oder Gadgets ausgewählt. Stattdessen wird dem Benutzer eine Anzeige einer Reihe verfügbarer Mapplets bereitgestellt (Kästchen 540), die wie die Gadget-Auswahl auf der personalisierten Google-Startseite oder iGoogle implementiert werden können. Die Mapplets können in Kategorien angeordnet sein und ein Benutzer kann eine der Kategorien auswählen (Kästchen 542) und ihm können des Weiteren Steuerelemente für die Auswahl bestimmter Gadgets bereitgestellt werden, die sich in der ausgewählten Kategorie befinden (Kästchen 544).
Der Benutzer kann dann ein bestimmtes Mapplet oder Gadget auswählen (Kästchen 546), das einen Codeserver veranlassen kann, das Profil des Benutzers zu aktualisieren, um anzugeben, dass das ausgewählte Mapplet in Zukunft geladen werden soll, wenn der Benutzer auf das System zugreift (Kästchen 548). Der Server kann außerdem den Code für das Mapplet übertragen, sodass das Mapplet auf der Kartenseite in einem neu erstellten iframe angezeigt wird. Der Mapplet-Code kann nach Lieferung ausgeführt werden (Kästchen 550), um Daten von einem Datenserver anzufordern (Kästchen 552), er kann die empfangen Daten verwenden, um Karteninformationen (Kästchen 554) von einem Kartenserver anzufordern (Kästchen 556), und er kann Daten auf der Karte anzeigen (Kästchen 558).
6 ist ein Ablaufdiagramm eines Prozesses für die Koordination der Kommunikation zwischen Domänen, die von einem Webbrowser angezeigt werden. Dieser Prozess und andere ähnliche können im Allgemeinen von den Komponenten ausgeführt werden, die dargestellt sind in 3. 6 zeigt allgemein die Übertragung einer Reihe paketierter Pakete über eine Domänengrenze. Anfänglich wird eine Datengruppe (die ein Paket oder eine andere bestimmte Gruppe von Daten sein kann, die durch eine Seite übertragen wird) an einem Relais oder Router empfangen. Der Router kann die Datengruppe oder Datengruppen empfangen und er kann ihre Paketierungsregeln prüfen, um eine Reihenfolge für die Paketierung der empfangenen Gruppen zu bestimmen, und um auch zu bestimmen, ob ein weiteres Halten der Pakete gerechtfertigt ist (d. h. Erstellung eines größeren und effizienteren kombinierten Pakets für die Übertragung). Falls die Übertragung des kombinierten Pakets von der Regel nicht ausgelöst wird (Kästchen 606), wird die empfangene Datengruppe zum Paketpuffer hinzugefügt (Kästchen 608), und falls die Übertragung ausgelöst wird, verpackt und überträgt der Router die Datengruppe und andere Datengruppen, die er hält (Kästchen 610).
Die Übertragung quert die Domänengrenze und bei Kästchen 612 empfängt der entsprechende Router das kombinierte Paket. Dieser Router kann dann, gemäß den vorher festgelegten Regeln, das kombinierte Paket zerlegen, um die gesendeten Datengruppen aus dem Paket zu extrahieren (Kästchen 614). Und schließlich kann der empfangende Router die einzelnen Datengruppen zu den Frames in dieser bestimmten Domäne weiterleiten (Kästchen 616).
7 ist ein Schwimmbahn-Diagramm eines Prozesses für das Senden von Daten zwischen Domänen auf einer von einem Browser angezeigten Webseite. Bei Kästchen 702–712 werden drei verschiedene Datengruppen von einer Kartenanwendung empfangen, die mit einer bestimmten Domäne auf der Seite verbunden ist. Zum Beispiel könnte ein Benutzer eine Karte verschoben oder die Karte auf eine andere Weise beeinflusst haben, die für die drei verschiedenen Mapplets relevant ist, die mit der Karte verbunden sind, und die Kartenanwendungen können eine solche Aktion melden. Der Kartenrouter hält die ersten beiden Datengruppen und nach Empfang der dritten bestimmt er, dass die Latenz oder Größe eines kombinierten Pakets die Übertragung des kombinierten Pakets über die Domänengrenze hinweg erfordert. Bei Kästchen 714 bestimmt der Router die Zieldomäne und sendet das Paket an diese Domäne.
Der Modulrouter, ein Router, der mit einer Domäne verbunden ist, in der mehrere tragbare Programmmodule in Form von Mapplets vorhanden sind, empfängt das kombinierte Paket (Kästchen 716) und zerlegt das Paket, um die Datengruppen zu extrahieren, die sich darin befinden (Kästchen 718). Nach Extrahieren der Datengruppen aus dem kombinierten Paket kann der Modulrouter die Adresse jeder Datengruppe bestimmen und diese Gruppe gemäß dem entsprechenden Mapplet weiterleiten (Kästchen 720, 724, 728), wobei mehrere Mapplets mit einer Kartenanwendung auf einer Seite verbunden sind. Die Daten können dann in jedem Mapplet ausgeführt werden (Kästchen 722, 726, 730).
8 ist ein Screenshot, der ein Beispiel einer Kartenanwendung zeigt, die in Koordination mit zwei tragbaren Programmmodulen betrieben wird. Das erste Modul bietet einem Benutzer die Möglichkeit, zusätzliche Module auszuwählen, die zur Anzeige hinzugefügt werden. Zum Beispiel kann ein Server, der mit den Modulen verbunden ist, Code für Module in Verbindung mit der Abbildung von Verbrechen in Chicago, Wetter, das auf eine Karte angewandt wird (z. B. Temperaturen und Sonne/Regen/Schnee) und andere verschiedene Module speichern. Dem Benutzer werden Kontrollkästchen für die Auswahl der Module bereitgestellt, die er zu seiner Seite hinzufügen möchte (und die Seite kann als personalisierte Kartenseite gespeichert werden). Außerdem können farbige Punkte neben jeder Auswahl angezeigt werden, um einen Wert für die Auswahl anzugeben, zum Beispiel einen Mapplet-Typ oder eine Untergruppe, in die das Mapplet fällt (z. B. Messtools, soziale Tools, geschäftliche Tools, Kartenerstellungstools usw.).
Ein Entfernungsmesstoolmodul wurde vorher vom Benutzer ausgewählt und wird in erweiterter Form angezeigt. Das Entfernungsmesstool interagiert mit der Hauptkartenanwendung, um es einem Benutzer zu erlauben, zwei oder mehr Punkte auf einer Karte auszuwählen (oder zwei oder mehr Orte zu identifizieren, zum Beispiel nach Bundesland, Ort und Straßenadresse) und dann die Entfernungen zu berechnen, die die Punkte verbinden, und die Entfernung für einen Benutzer anzuzeigen.
Andere Module können, wenn sie ausgewählt werden, ihre Ausgabe mit dem Entfernungsmesstool kombinieren. Wenn der Benutzer zum Beispiel ein Verbrechensmodul für Chicago auswählt, kann die Karte so umgewandelt werden, dass sie Chicago vergrößert und Indikatoren für Gegenden anzeigt, in denen Verbrechen in Chicago verübt wurden. Der Benutzer kann dann das Entfernungsmesstool verwenden, um die Entfernung zwischen Verbrechensorten oder anderen Informationen zu messen. Auf diese Weise können es die angezeigten Anwendungen einem Benutzer erlauben, mehrere Anwendungen auf eine Weise zu verbinden, die für ihn individuell angepasst ist, und die direkt auf einen Kartenservice, wie Google Maps, zugreift.
9 zeigt eine exemplarische Anordnung eines Containerdokuments 900, das eine Reihe von tragbaren Programmmodulen enthält. Es sind eine Reihe von Methoden der Einbeziehung möglich, zum Beispiel die Verwendung von iframe- und Inline-HTML-Techniken. 9 stellt eine Vielzahl von Modulen mit einem Bestandsmodul 905, einem E-Mail-Modul 906, einem Echtzeit-Werbemodul 908, Werbemodulen 910, 912, Mapplet-Modul 916 und einem Kartenmodul 914 dar. Abhängig von den Spezifikationen, die er Erstellen des Moduls liefert, können die verschiedenen Module unterschiedliche Formate haben. Einige Module können Blätterleisten bereitstellen und andere nicht. Einige Module können unterschiedliche Größen oder Formen haben als andere Module. Außerdem können einige Module dem Benutzer die Möglichkeit bieten, die Anzeigevoreinstellungen und/oder Daten pro Nutzung, die mit dem Modul verbunden sind, zu bearbeiten.
In einer Implementierung können Inline-Module automatisch durch ein Containerdokument in der Größe angepasst werden, sodass keine Blätter-, Höhen- oder Skalisierungsinformationen bereitgestellt werden. Wenn ein Modulentwickler möchte, dass das Modul diese Eigenschaften hat, kann ein Inline-Modul mit eine <DIV>-Tag für feste Größe und Inhalt, der im Tag abgelegt wird, umgebrochen werden. Blätterleiste, Höhe und andere Eigenschaften können dann für den Inline-Inhalt angegeben werden. Eines der Attribute ermöglicht die Spezifizieren von scaling = „...”, damit der Entwickler angeben kann, wie ein Modul für unterschiedliche Größen der Anordnungen, in den Containerdokumenten nach oben oder unten skaliert werden kann.
Eine der mit diesem exemplarischen Containerdokument 900 bereitgestellten Funktionen ist die Möglichkeit, Inhalt durch Auswählen des Elements „Gadgets hinzufügen” 903 zur Containerseite hinzuzufügen. Nach Auswählen des Elements „Gadgets hinzufügen” 903 kann das System dem Benutzer die Möglichkeit bieten, interaktiv ein zusätzliches Element anzugeben, das in die Containerseite einbezogen werden soll. Es können verschiedene Formen einer Schnittstelle, die diesen Eintrag empfangen soll, vorhanden sein.
Außerdem kann es beim Hinzufügen, Bearbeiten oder Löschen von Modulen wünschenswert sein, dass diese Aktivitäten ohne eine Aktualisierung des Containerdokuments erfolgen. Eine veranschaulichende Technik, um dies zu erreichen, kann die Verwendung von AJAX-Programmiertechniken umfassen, damit ein Modul zu einem Containerdokument ohne eine Aktualisierung der Containerdokumentseite hinzugefügt werden kann (vielleicht nur eine Aktualisierung des iframe, in dem der neue Container vorhanden ist), oder die Verwendung von AJAX, um ein Modul zu entfernen, ohne dass das Containerdokument aktualisiert wird, oder wenn ein Entwickler ein Modul entwickelt, er Module ändern kann, ohne dass das Containerdokument, in dem sie ausgefüllt werden, eine Seitenaktualisierung benötigt, damit das geänderte Modul einbezogen wird.
Unter Bezugnahme auf bestimmte Module kann das Mapplet-Modul 916 in einem iframe angezeigt werden, der auf Code für ein tragbares Programmmodul verweist, wie das oben eröterte. Das Mapplet-Modul 916 kann mit anderen Modulen, wie Kartenmodul 914, interagieren, das mit einer Domäne für einen Kartenserver verbunden sein kann, z. B. maps.google.com, und das so konfiguriert sein kann, dass es Kacheln für Karten empfängt und anzeigt, um Objekte anzuzeigen, die durch Mapplet-Modul 916 bereitgestellt werden, und dem Mapplet-Modul 916 Feedback zu liefern.
Andere Module können ebenfalls im System kommunizieren. Zum Beispiel kann E-Mail-Modul 906 auch eine Kalenderfunktion beinhalten, die Informationen für Termine für einen Benutzer hat. E-Mail-Modul 906 kann eine Anfrage für Zeit-, Orts- oder andere Informationen für kommende Termine für einen Benutzer vom Mapplets-Modul 916 empfangen und solche Informationen dem Mapplets-Modul 916 zurückgegeben. Das Mapplet-Modul 916 kann dann Adressinformationen an einen Kartenserver weiterleiten, um mit der Geografie verbundene Daten für die Termine zu erhalten. Das Mapplet-Modul 916 kann dann veranlassen, dass mit jedem Termin verbundene Objekte auf einer Karte veröffentlicht werden, die durch Kartenmodul 914 angezeigt wird. Auf ähnliche Weise können Kartenmodule 910, 912 geografische Informationen zum Beispiel vom Mapplet-Modul 916 oder Kartenmodul 914 empfangen und zielgerichtete Werbung abrufen, die auf eine bestimmte Optik und/oder Orte in den Informationen gerichtet ist.
10 ist ein schematisches Diagramm eines exemplarischen Systems 1000 für die dynamische Erzeugung von Werbung und anderen Elementen. System 1000 ist eine allgemeine Darstellung eines Systems, das tragbare Programmmodule, zum Beispiel Gadgets, für verschiedene Operationen nutzt. Die hier beschriebenen allgemeinen Operationen gelten, wo zutreffend, für die in 1A, 1B, 2 und 3 dargestellten Systeme.
System 1000 kann ein Hostserversystem 1010 mit einer Vielzahl von Modulen beinhalten, die damit verbunden sein können. Solche Module können einen Containerserver 1012, einen Modulserver 1014, einen Spezifikationsserver 1016, einen Backend-Server 1018, ein Analysemodul 1028, einen Modulerstellungsserver 1032, einen Syndikationsserver 1034 und einen Werbeserver 1036 umfassen. Wie veranschaulicht, kann Hostserversystem 1010 sich über ein Netzwerk 1026 mit einer Vielzahl anderer System oder Teilsysteme verbinden.
Andere Systeme, die mit dem Netzwerk verbunden sind, können ein oder mehrere Benutzersysteme 1022, ein oder mehrere Remote-Elementserver 1024, ein oder mehrere Modulentwicklersysteme 1030 und ein oder mehrere Syndikationsempfangsserver 1038 umfassen. Außerdem können ein oder mehrere Datenbanksysteme 1020 zusammen mit den verschiedenen Modulen des Hostserversystems 1010 betrieben werden.
Insbesondere kann ein getrennter Server ein Kartenserver 1031 sein, der geografische Daten als Reaktion auf Anfragen bereitstellt, die mit einer bestimmten API übereinstimmen. Der Kartenserver kann alternativ Teil von Hostserversystem 1010 sein, wird hier aber zum Zweck der Veranschaulichung, dass Anwendungen, die System 1000 nutzen, über mehrere Systeme kommunizieren können, getrennt dargestellt. Der Kartenserver kann zum Beispiel Anfragen von Benutzersystemen 1022 empfangen, die Code ausführen, der von Komponenten in Hostserversystem 1010 bereitgestellt wird, um Mapplets oder andere tragbare Programmmodule zu erzeugen.
Unter erneuter Bezugnahme auf Hostserversystem 1010 kann Containerserver 1012 Containerdokumente für Benutzersysteme 1022 über Netzwerk 1026 bereitstellen. Containerserver 1012 kann einen Webserver oder verbundene Serversysteme verwenden, die Daten und/oder Anweisungen nehmen und Container für die Übertragung über das Netzwerk zu Benutzersystem 1022 formulieren. Dieser Containerserver 1012 kann sich jedoch auch auf Benutzersystem 1022 befinden, sodass keine Netzwerkverbindung verwendet werden muss. In dem Beispiel, in dem das Containerdokument z. B. ein Textverarbeitungsdokument beinhaltet, kann Containerserver 1012 ein Textverarbeitungsmodul beinhalten.
Modulserver 1014 kann Containerserver 1012 Daten von Modulen für die Einbeziehung in ein Containerdokument bereitstellen. In einer Ausführungsform können Containerserver 1012 und Modulserver 1014 eine einzelne Einheit umfassen, die beide Funktionen ausführt, wie dies andere hierin beschriebene Server und Module tun können. Modulserver 1014 kann Daten für das Containerdokument bereitstellen, indem er Anweisungen in einer Modulspezifikation, die mit dem Modul verbunden ist, interpretiert und/oder analysiert. Gemäß einer Ausführungsform kann Modulserver 1014 den Modulinhalt dem Containerdokument durch Verwendung eines Browser-iframe bereitstellen.
Um die Anzeige der Containerdokumente zu beschleunigen, kann das Modul inline innerhalb des Containerdokuments angezeigt werden. Die Inline-Anzeige kann so verstanden werden, dass sie sich auf die Anzeige mit anderen Dokumentelementen bezieht. Ein Beispiel ist eine Anzeige, die aus einem Code für HTML im Textkörper, gemäß HTML-Standards, generiert wird. In einer Ausführungsform kann Modulserver 1014 oder eine andere Komponente aufgrund der Risiken verschiedener Sicherheitsprobleme, die ein Inline-Modul schaffen könnte, bestimmen, ob das Modul als vertrauenswürdig betrachtet wird, bevor es in das Containerdokument einbezogen wird. Gemäß einer Implementierung kann das Modul einen Vermerk für die Genehmigung (z. B. digitales Zertifikat) enthalten, das vom Containermodul oder einer Entität ausgestellt wurde, die mit dem Containermodul verbunden ist. Wenn der Vermerk der Genehmigung vorhanden ist, kann Modulserver 1014 die Daten von einem Modul für die Inline-Darstellung im Containerdokument wiedergeben.
Spezifikationsserver 1016 stellt eine Modulspezifikationsdatei für Modulserver 1014 bereit. Die Modulspezifikation kann zwischengespeichert und in einer Datenbank gespeichert werden, die für den Modulserver 1014 und/oder den Spezifikationsserver 1016 zugänglich ist, und sie kann von einem Ort abgerufen werden, der mit der Spezifikation verbunden ist, wie später näher ausgeführt. Spezifikationsserver 1016 kann sich zum Beispiel auf einem Remote-Elementserver 1024 befinden. Außerdem kann Spezifikationsserver 1016 mit Modulserver 1014 über ein Netzwerkverbunden sein, wobei sich die Modulspezifikation an einem anderen Ort im Netzwerk befindet, die für den Spezifikationsserver 1016 zugänglich ist.
Backend-Server 1018 kann für die Interaktion mit einer oder mehreren Datenbanken bereitgestellt werden (z. B. große oder dynamische Informationsdatenbanken). Für ein Nachrichtenmodul, das häufige Aktualisierungen erhält und einen Datenfluss fordert (z. B. von einem RSS-Feed) kann Backend-Server 1018 die Daten in HTML für den Container formatieren.
In einem spezifischen Beispiel kann jemand ein Modul erstellen (z. B. ein Kartenmodul), wie zum Beispiel ein Modul, das eine Anwendungsprogramm-Schnittstelle (API) zu einem bestehenden Kartenprogramm verwendet, um ein Modul zu erstellen, das einen Stadtplan des Stadtzentrums von Mountain View in Kalifornien darstellt. Das Modul kann eine XML-Spezifikationsdatei oder eine Modulspezifikationsdatei enthalten, die auf einem Spezifikationsserver gespeichert ist. Der Spezifikationsserver kann jeden geeigneten Server umfassen, einschließlich einen an einem Standort, an dem die Containerseite gehostet wird. Der Benutzer oder eine andere Person kann dann dieses neue Modul auf einer personalisierten Startseite oder einer anderen Form von Webseite einbeziehen (Containerdokument). Der Server, der das Containerdokument bereitstellt, kann als Modulserver betrieben werden, und der Server, der die Kartendaten über eine Anfrage von seiner API erzeugt, kann als Backend-Server betrachtet werden.
In einer Ausführungsform kann Analysemodul 1028 Module zu verschiedenen Zeiten analysieren (z. B., wenn das Modul erstmals von einem Benutzer ausgewählt wird, jedes Mal, wenn das Modul von einem Container für die Einbeziehung aufgerufen wird, oder zu jeder anderen Zeit, die für den Schutz und die Sicherheit als vorteilhaft betrachtet wird, und andere Zeiten).
Analysemodul 1028 kann eine Reihe von Aktionen durchführen, zum Beispiel den Vergleich des Moduls mit einer Liste nicht zugelassener oder gefährlicher Module oder einer Liste zugelassener Module. Der Datenabgleich kann in Form eines Vergleichs des gesamten Strings oder eines Teilstrings (z. B. Präfix, Suffix und reguläre Ausdrücke), des Namens oder des Speicherorts (z. B. URL), der Inhalte der Spezifikation, der Inhalte des Speicherorts, wo diese Spezifikation sich befindet, oder der Informationen, die über das Modul erfassbar sein können, erfolgen.
Analysemodul 1028 kann eine oder mehrere Maßnahmen als Reaktion auf eine Bestimmung ergreifen, dass das Modul nicht zugelassen oder gefährlich ist, zum Beispiel das stille Blockieren der Anfrage (d. h. Angabe eines allgemeinen Fehlers), Blockieren der Anfrage mit einem Fehler, der den Grund für das Blockieren erklärt, oder Umleiten der Anfrage an eine andere Modulspezifikation, die als sicher bestimmt wurde und mit dem nicht zugelassenen Modul verbunden ist (z. B. ein anderes Modul, das mit Karten verbunden ist, wenn das erste eine nicht zugelassene Karten-Site war, oder ein Modul, das das Schlüsselwort „Basketball” enthält, wenn das nicht zugelassene Modul ein Basketball-Modul war).
Durch Umleitung kann zum Beispiel die URL des ursprünglichen Moduls an das „sichere” Modul weitergegeben werden. Das sichere Modul kann dann zum Abrufen des Inhalts der Original-URL einen Proxy Server verwenden. Entwickler können dann den Error Handler ersetzen, um kleine Fehler im Original-Modul zu beheben, damit der Inhalt im Original-Modul angezeigt werden kann. In einer anderen Ausführungsform kann Analysemodul 128 den Modulinhalt analysieren, um zu bestimmen, ob er sicher ist, z. B. durch Kompilieren von JavaScript oder anderen Skripten, die im Modul enthalten sind, um zu versuchen, unsichere oder unerwünschte Aktionen zu identifizieren, die das Modul ausführen kann.
Ein oder mehrere Erstellungsserver 1032 können bereitgestellt werden. Diese Server können als „Wizards” betrieben werden, um es Modulerstellern zu ermöglichen, ein Modul durch einen interaktiven Prozess zu erstellen. Zum Beispiel kann Modulerstellungsserver 1032 eine Reihe von Benutzerschnittstellen bereitstellen, die es einer Person, die ein Modul erstellt, ermöglicht, Eingaben bereitzustellen, die verwendet werden, um automatisch eine Modulspezifikation zu erzeugen. Es können beispielsweise verschiedene Modulspezifikationstemplates mit den zugehörigen Einträgen geliefert werden. Modulerstellungsserver 1032 kann dann Eingaben nehmen, die von einem Benutzer geliefert wurden, sie in eine Vorlage einfügen und eine Modulspezifikation für das Modul erzeugen. Eine Vorschau-, Test- und Debugging-Funktion kann ebenfalls als Teil der „Wizards” angeboten werden. Dieses Modul kann auch auf den Client heruntergeladen werden.
Ein Syndikationsserver 1034 kann Daten für die Übertragung an einen oder mehrere Syndikationsempfangsserver 1038 erstellen, die mit Modulen verbunden sind. Syndikationsserver 1034 kann eine Anfrage für ein Modul und/oder Modulinhalte empfangen und dieses Modul oder die Inhalte einem Syndikationsempfangsserver 1038 über Netzwerk 1026 bereitstellen. Syndikationsserver 1034 kann sich auf Hostserverystem 1010 oder an einem anderen Ort im Netzwerk befinden.
Wenn ein Betreiber einer Sport-Website (ein Beispiel eines Syndikationsempfängersystems 1038) ein Werbemodul einbeziehen möchte, das von einem Remote-Quellsystem 1024 erstellt wurde, kann er dies durch eine Anfrage an Syndikationsserver 1034 tun. Syndikationsserver 1034 kann dann mit Modulserver 1014 zusammenarbeiten, um Daten für das Containerdokument zu erzeugen (hier die Sport-Website des Syndikationsempfängersystems 1038). Dies kann das Abrufen der Modulspezifikation vom Remote-Quellsystem 1024, die Lieferung von Voreinstellungen, die vom Syndikationsempfängerserver 1038 empfangen wurden (z. B. Ortsinformationen für das Sportteam einer Seite, die angezeigt wird), und/oder das Erzeugen von Daten für den Container umfassen. Es ist außerdem möglich, Daten am Syndikationsempfängerserver 1038 in seinem Containerdokument entweder in einem iframe oder inline wiederzugeben. Syndikationsserver 1034 kann somit Module syndizieren, die für ihn zugänglich sind. Er kann dies auf Basis von Anfragen für Module oder andere Kriterien tun, die er bestimmt (zum Beispiel Inhaltsübereinstimmungen, Schlüsselwortsuchen, monetäre Werte, die mit Modulen und/oder Syndikationsanforderern verbunden sind, usw.).
Werbeserver 1036 kann Containern Werbung bereitstellen, die mit Modulen verbunden ist, und/oder Daten für die Erstellung einer Anzeige für solche Module. Eine Werbung kann beispielsweise in Moduldaten eingebettet werden, wenn die Daten an ein Containerdokument geliefert werden. Werbeserver 1036 kann mit Syndikationsserver 1034 zusammenarbeiten, um Werbung für Syndikationsempfängerserver 1038 auf Basis einer Syndikationsanfrage für ein Modul zu liefern. Die Werbung kann von Werbeserver 1036 auf Basis einer Vielzahl von Kriterien ausgewählt werden, zum Beispiel u. a. der Beziehung zwischen dem Inhalt des oder der Informationen über den Container, das Modul, andere Module im Container, Syndikationsempfängerserver-Informationen, monetäre Elemente/Beziehungen in Verbindung mit einem der vorstehenden Punkte und/oder Kombinationen davon.
Werbeserver 1036 kann gemäß einer Implementierung das Google AdSense-System umfassen. Insbesondere kann Werbeserver 1036 Online-Werbung durch Verbindung von zwei oder mehr Konzepten in Verbindung mit einem Modul mit einer Werbung und Verbindung eines Angebots zusammen mit den zwei oder mehreren Schlüsselwörtern verwalten. Außerdem kann Syndikationsserver 1034 oder Werbeserver 1036 auf Anfragen von syndizierten Modulen antworten, z. B. mit Werbung verbundenen Modulen, die Anfragen für Informationen senden, die Containerseiten beschreiben, die mit den Modulen verbunden sind.
Ein oder mehrere Datenbanksysteme 1020 können bereitgestellt werden, die in beliebiger Zahl oder geeigneter Weise, Containerinformationen, Modulspezifikationen und/oder verbundene Informationen, Formatierungsdaten, Voreinstellungsdaten pro Benutzer und pro Modul, Remote-Modul-ID-Daten, Remote-Modul-Ortsreferenzdaten, Werbedaten, Werbekundendaten, Inhalts-/monetäre Daten, Syndikationsempfängerdaten, Vorlagen für Module, Eingaben für Module, Listen vertrauenswürdiger und nicht vertrauenswürdiger Module, Genehmigungskriterien und verbundene Informationen und/oder alle anderen Informationen speichern, die von Modulen verwendet werden, um wie hierin beschrieben zu funktionieren. Auch wenn eine einzelne Datenstruktur angezeigt ist, können die Daten an einer Reihe von Orten und in einem oder mehreren Systemen gespeichert werden.
In einer Implementierung werden Systeme und Verfahren für die Einbeziehung von Modulen in ein Containerdokument bereitgestellt. Ein Beispiel eines Containerdokuments wäre eine personalisierte Startseite, zum Beispiel die personalisierte Google-Startseite, oder iGoogle, die zurzeit Benutzer der Google-Dienste im Internet verfügbar ist. Statt die Arten des Inhalts einzuschränken, die ein Benutzer in ein Containerdokument, wie eine personalisierte Startseite, einbeziehen kann, können es eine oder mehrere Implementierungen Benutzern ermöglichen, Module aus anderen Quellen als der Quelle des Containerdokuments auszuwählen. So kann beispielsweise ein/e Benutzer/in ein Modul einer Quelle, die nicht mit Google in Verbindung steht, in seine oder ihre personalisierte Google Homepage einbinden.
11 zeigt ein Beispiel eines Computergeräts 1100 und eines mobilen Computergeräts 1150, das zur Implementierung der hier beschriebenen Techniken verwendet werden kann. Computergerät 1100 soll verschiedene Formen von Digitalcomputern darstellen, zum Beispiel Laptops, Desktops, Workstations, Personal Digital Assistants, Server, Blade Server, Mainframes und andere geeignete Computer.
Computergerät 1150 soll verschiedene Formen mobiler Geräte, wie Personal Digital Assistants, Mobiltelefone, Smartphones und andere ähnliche Computergeräte, darstellen. Die hier gezeigten Komponenten, ihre Verbindungen und Beziehungen und ihre Funktionen sollen nur exemplarisch sein und sollen Implementierungen der in diesem Dokument beschriebenen und/oder beanspruchten Erfindungen nicht einschränken.
Das Computergerät 1100 beinhaltet einen Prozessor 1102, Speicher 1104, ein Speichergerät 1106, eine Hochgeschwindigkeitsschnittstelle 1108, die mit dem Speicher 1104 und Hochgeschwindigkeits-Erweiterungsanschlüssen 1110 verbindet, und eine langsame Schnittstelle 1112, die mit einem langsamen Bus 1114 und dem Speichergerät 1106 verbindet. Alle der Komponenten 1102, 1104, 1106, 1108, 1110 und 1112 sind mithilfe verschiedener Busse miteinander verbunden und können an einer gemeinsamen Hauptplatine oder auf andere Weise, wie geeignet, angebracht sein. Der Prozessor 1102 kann Anweisungen für die Ausführung im Computergerät 1100 verarbeiten, zum Beispiel Anweisungen, die im Speicher 1104 oder Speichergerät 1106 gespeichert sind, um grafische Informationen für eine grafische Benutzeroberfläche auf einem externen Eingabe-/Ausgabegerät anzuzeigen, zum Beispiel Display 1116, das mit der High-Speed-Schnittstelle 1108 gekoppelt ist. In anderen Implementierungen können mehrere Prozessoren und/oder mehrere Busse verwendet werden, wie angemessen, zusammen mit mehreren Speichern und Speichertypen. Außerdem können mehrere Computergeräte 1100 verbunden sein, wobei jedes Gerät Teile der nötigen Operationen bereitstellt (z. B. als Serverbank, eine Gruppe von Blade Servern oder ein Multiprozessor-System).
Der Speicher 1104 zeichnet Informationen im Computergerät 1100 auf. In einer Implementierung ist der Speicher 1104 ein flüchtiges Speichergerät oder flüchtige Speichergeräte. In einer anderen Implementierung ist der Speicher 1104 ein nicht flüchtiges Speichergerät oder nicht flüchtige Speichergeräte. Der Speicher 1104 kann auch eine andere Form von computerlesbarem Medium sein, zum Beispiel ein magnetischer oder optischer Datenträger.
Das Speichergerät 1106 ist geeignet, Massenspeicherung für das Computergerät 1100 bereitzustellen. In einer Ausführungsform kann das Speichergerät 1106 ein computerlesbares Medium sein oder enthalten, zum Beispiel ein Diskettengerät, ein Festplattengerät, ein optisches Datenträgergerät oder ein Bandgerät, ein Flash-Speicher oder ein anderes ähnliches Solid-State-Speichergerät oder eine Reihe von Geräten, zum Beispiel Geräte in einem Storage Area Network oder anderen Konfigurationen. Ein Computerprogrammprodukt kann greifbar in einem Informationsträger ausgeführt sein. Das Computerprogrammprodukt kann auch Anweisungen enthalten, die, wenn sie ausgeführt werden, ein oder mehrere Verfahren durchführen, wie die oben beschriebenen. Der Informationsträger ist ein computer- oder maschinenlesbares Medium, wie zum Beispiel der Speicher 1104, das Speichergerät 1106, Speicher auf Prozessor 1102 oder ein propagiertes Signal.
Der Hochgeschwindigkeitscontroller 1108 managt bandbreitenintensiver Operationen für das Computergerät 1100, während der Niedriggeschwindigkeitscontroller 1112 weniger bandbreitenintensive Operationen managt. Eine solche Zuordnung von Funktionen ist nur exemplarisch. In einer Ausführungsform ist der High-Speed-Controller 1108 mit Speicher 1104, Display 1116 (z. B. über einen Grafikprozessor oder -beschleuniger) und mit High-Speed-Erweiterungsanschlüssen 1110 gekoppelt, die verschiedene Erweiterungskarten aufnehmen können (nicht dargestellt). In der Implementierung ist Low-Speed-Controller 1112 mit Speichergerät 1106 und Low-Speed-Erweiterungsanschluss 1114 gekoppelt. Der langsame Erweiterungsanschluss, der verschiedene Kommunikationsanschlüsse (z. B. USB, B, Ethernet, Funkethernet) beinhalten kann, kann an ein oder mehrere Eingabe-/Ausgabe-Geräte, wie eine Tastatur, ein Zeigegerät, einen Scanner oder ein Netzwerkgerät, wie einen Switch oder Router, z. B. durch einen Netzwerkadapter gekoppelt sein.
Das Computergerät 1100 kann in einer Reihe verschiedener Formen implementiert werden, wie in der Figur gezeigt. Es kann zum Beispiel als Standardserver 1120 oder mehrmals in einer Gruppe solcher Server implementiert sein. Es kann auch als Teil eines Rackserversystems 1124 implementiert sein. Außerdem kann es in einem Personal Computer, wie Laptop-Computer 1122, implementiert sein. Alternativ können Komponenten von Computergerät 1100 mit anderen Komponenten in einem mobilen Gerät kombiniert sein (nicht dargestellt), z. B. Gerät 1150. Jedes solcher Geräte kann eines oder mehrere Computergeräte 1100, 1150 enthalten, und ein gesamtes System kann aus mehreren Computergeräten 1100, 1150 bestehen, die miteinander kommunizieren.
Das Computergerät 1150 beinhaltet einen Prozessor 1152, Speicher 1164, ein Eingabe-/Ausgabegerät, wie eine Anzeige 1154, eine Kommunikationsschnittstelle 1166 und einen Sende-Empfänger 1168, unteranderen Komponenten. Das Gerät 1150 kann auch mit einem Speichergerät ausgestattet sein, zum Beispiel einem Microdrive oder anderem Gerät, um zusätzlichen Speicher bereitzustellen. Alle der Komponenten 1150, 1152, 1164, 1154, 1166 und 1168 sind mithilfe verschiedener Busse miteinander verbunden und mehrere der Komponenten können an einer gemeinsamen Hauptplatine oder auf andere Weise, wie geeignet, angebracht sein.
Der Prozessor 1152 kann Anweisungen im Computergerät 1150 ausführen, einschließlich im Speicher 1164 gespeicherter Anweisungen. Der Prozessor kann als ein Chipsatz von Chips implementiert werden, die separate und mehrere analoge und digitale Prozessoren beinhalten. Der Prozessor kann zum Beispiel für die Koordination der anderen Komponenten des Geräts 1150 sorgen, zum Beispiel die Kontrolle von Benutzeroberflächen, Anwendungen, die vom Gerät 1150 ausgeführt werden, und die drahtlose Kommunikation durch Gerät 1150.
Der Prozessor 1152 kann mit einem Benutzer durch eine Steuerschnittstelle 1158 und eine Anzeigeschnittstelle 1156 kommunizieren, die an eine Anzeige 1154 gekoppelt ist. Das Display 1154 kann zum Beispiel ein TFT(Thin-Film-Transistor Liquid Crystal Display)-Display oder ein OLED(Organic Light Emitting Diode)-Display oder eine andere geeignete Displaytechnologie sein. Die Displayschnittstelle 1156 kann eine geeignete Schaltung enthalten, die das Display 1154 dazu bringt, einem Benutzer grafische und andere Informationen zu präsentieren. Die Steuerschnittstelle 1158 kann Befehle von einem Benutzer empfangen und sie für die Sendung an Prozessor 1152 umwandeln. Außerdem kann eine externe Schnittstelle 1162 in Kommunikation mit Prozessor 1152 bereitgestellt werden, um die Nahbereichskommunikation von Gerät 1150 mit anderen Geräten zu ermöglichen. Die externe Schnittstelle 1162 kann zum Beispiel in einigen Implementierungen eine kabelgebundene Kommunikation bereitstellen, oder in anderen Implementierungen eine drahtlose Kommunikation und es können auch mehrere Schnittstellen verwendet werden.
Der Speicher 1164 zeichnet Informationen im Computergerät 1150 auf. Der Speicher 1164 kann als ein oder mehrere computerlesbare Medien, eine flüchtige Speichereinheit oder -einheiten oder eine nichtflüchtige Speichereinheit oder -einheiten implementiert werden. Erweiterungsspeicher 1174 kann ebenfalls bereitgestellt und mit dem Gerät 1150 über Erweiterungsschnittstelle 1172 verbunden werden, die zum Beispiel eine SIMM(Single In Line Memory Module)-Kartenschnittstelle umfassen kann. Ein solcher Erweiterungsspeicher 1174 kann zusätzlichen Speicherplatz für Gerät 1150 bereitstellen oder er kann auch Anwendungen oder andere Informationen für Gerät 1150 speichern. Insbesondere kann Erweiterungsspeicher 1174 Anweisungen zum Ausführen oder Ergänzen der oben beschriebenen Prozesse enthalten und er kann außerdem sichere Informationen enthalten. Somit kann Erweiterungsspeicher 1174 zum Beispiel als Sicherheitsmodul für Gerät 1150 bereitgestellt werden und er kann mit Anweisungen programmiert sein, die die sichere Verwendung von Gerät 1150 erlauben. Zusätzlich dazu können über die SIMM-Cards sichere Anwendungen bereitgestellt werden, zusammen mit zusätzlichen Informationen, wie das Ablegen von Identifizierungsinformationen auf der SIMM-Card auf eine Weise, die nicht gehackt werden kann.
Der Speicher kann beispielsweise Flash Speicher und/oder NVRAM-Speicher beinhalten, wie nachstehend erörtert. In einer Implementierung ist ein Computerprogrammprodukt greifbar in einem Informationsträger ausgeführt. Das Computerprogrammprodukt enthält Anweisungen, die, wenn sie ausgeführt werden, ein oder mehrere Verfahren durchführen, wie die oben beschriebenen. Der Informationsträger ist ein computer- oder maschinenlesbares Medium, zum Beispiel Speicher 1164, Erweiterungsspeicher 1174, Speicher auf Prozessor 1152 oder ein propagiertes Signal, das zum Beispiel über Sender 1168 oder die externe Schnittstelle 1162 empfangen werden kann.
Das Gerät 1150 kann drahtlos über die Verbindungsschnittstelle 1166 kommunizieren, die digitale Signalverarbeitungsschaltkreise beinhalten kann, falls erforderlich. Kommunikationsschnittstelle 1166 kann Kommunikation unter verschiedenen Modi oder Protokollen bereitstellen, zum Beispiel u. a. GSM-Sprachanrufe, SMS-, EMS- oder MMS-Messaging, CDMA, TDMA, PDC, WCDMA, Containerdokument 102MA2000 oder GPRS. Eine solche Kommunikation kann zum Beispiel über Funkfrequenzempfänger 1168 erfolgen. Zusätzlich kann eine Kurzstreckenkommunikation stattfinden, wie unter Verwendung eines Bluetooth-, WLAN- oder anderen solchen Sende-Empfängers (nicht gezeigt). Außerdem kann GPS(Global Positioning System)-Empfängermodul 1170 zusätzliche mit der Navigation und dem Ort verbundene drahtlose Daten für Gerät 1150 bereitstellen, die ggf. von Anwendungen verwendet werden können, die auf Gerät 1150 ausgeführt werden.
Das Gerät 1150 kann mithilfe des Audio-Codec 1160 auch akustisch kommunizieren, das gesprochene Informationen von einem Benutzer empfangen und diese in nutzbare digitale Informationen konvertieren kann. Audio-Codec 1160 kann ebenfalls akustische Töne für einen Benutzer erzeugen, zum Beispiel durch einen Lautsprecher zum Beispiel in einem Handgerät von Gerät 1150. Solche Töne können Töne von Sprachtelefonanrufen beinhalten, können aufgezeichnete Töne (z. B. Sprachnachrichten, Musikdateien usw.) beinhalten und er kann außerdem Tone enthalten, die durch Anwendungen erzeugt werden, die auf Gerät 1150 betrieben werden.
Das Computergerät 1150 kann in einer Reihe verschiedener Formen implementiert werden, wie in der Figur gezeigt. Es kann zum Beispiel als Mobiltelefon 1180 implementiert werden. Es kann außerdem als Teil eines Smartphones 1182, Personal Digital Assistant oder eines anderen ähnlichen mobilen Geräts implementiert werden.
Verschiedene Implementierungen der hier beschriebenen Systeme und Techniken können in digitalen elektrischen Schaltungen, integrierten Schaltungen, speziell entwickelten Werbeserver-ASICs (anwendungsspezifische, integrierte Schaltungen), Computerhardware, Firmware, Software und/oder Kombinationen realisiert werden. Diese verschiedenen Implementierungen können eine Implementierung in einem oder mehreren Computerprogrammen beinhalten, die auf einem programmierbaren System ausführbar und/oder interpretierbar sind, das mindestens einen programmierbaren Prozessor beinhaltet, der ein spezieller oder für allgemeine Zwecke sein kann und der zum Empfangen von Daten und Anweisungen von und zum Übertragen von Daten und Anweisungen an ein Speichersystem, mindestens eine Eingabevorrichtung und mindestens eine Ausgabevorrichtung gekoppelt ist.
Diese Computerprogramme (auch bekannt als Programme, Software, Softwareanwendungen oder Code) beinhalten Maschinenanweisungen für einen programmierbaren Prozessor und können in einer höheren prozeduralen und/oder objektorientierter Programmiersprache und/oder in Assembler-/Maschinensprache implementiert werden. Wie hierin verwendet, bedeuten die Begriff „maschinenlesbares Medium”, „computerlesbares Medium” bezieht sich auf alle Computerprogrammprodukte, Apparate und/oder Geräte (z. B. magnetische und optische Speicherplatten, Speicher, Programmable Logic Devices [PLD]), verwendet zur Übergabe von Maschinenanweisungen und/oder -daten zu einem programmierbaren Prozessor, einschließlich eines maschinenlesbaren Mediums, das Maschinenanweisungen als maschinenlesbare Signale empfängt. Der Begriff „maschinenlesbares Signal” bezeichnet ein beliebiges Signal, das verwendet wird, um einem programmierbaren Prozessor Maschinenanweisungen und/oder Daten bereitzustellen.
Zur Interaktion mit einem Benutzer können die hier beschriebenen Systeme und Techniken auf einem Computer mit einem Anzeigegerät (z. B. ein CRT-[Kathodenstrahlröhre] oder ein LCD-[Flüssigkristallanzeige]Monitor) implementiert werden, um Informationen für den Benutzer anzuzeigen, und eine Tastatur und ein Pointergerät (z. B. Maus oder Trackball), mit denen der Benutzer Eingaben in den Computer vornehmen kann. Andere Arten von Geräten können auch verwendet werden, um eine Interaktion mit einem Benutzer bereitzustellen; zum Beispiel kann eine dem Benutzer bereitgestellte Rückmeldung irgendeine Form von Sinnesrückmeldung sein (z. B. visuelle Rückmeldung, auditive Rückmeldung oder Tastrückmeldung); und eine Eingabe vom Benutzer kann in einer beliebigen Form empfangen werden, einschließlich akustischer, Sprach- oder Tasteingaben.
Die hierin beschriebenen Systeme und Techniken könne in einem Computersystem implementiert werden, das eine Back-End-Komponente beinhaltet (z. B. als Datenserver), oder das eine Middleware-Komponente beinhaltet (z. B. einen Anwendungsserver), oder das eine Front-End-Komponente beinhaltet (z. B. ein Client-Computer mit einer grafischen Benutzeroberfläche oder einem Webbrowser, über welche ein Benutzer mit einer Implementierung der hier beschriebenen Systeme und Techniken interagieren kann) oder Kombination derartiger Back-End-, Middleware- und Front-End-Komponenten. Die Komponenten des Systems können durch eine beliebige Form oder ein beliebiges Medium von digitaler Datenkommunikation (z. B. ein Kommunikationsnetzwerk) miteinander verbunden sein. Beispiele von Kommunikationsnetzwerken beinhalten ein lokales Netzwerk („LAN”), ein Fernnetz („WAN”) und das Internet.
Das Computersystem kann Clients und Server beinhalten. Ein Client und Server befinden sich im Allgemeinen ortsfern voneinander und interagieren typischerweise über ein Kommunikationsnetz. Die Beziehung von Client und Server ergibt sich durch Computerprogramme, die auf den jeweiligen Computern laufen und eine Client-Server-Beziehung zueinander aufweisen.
Eine Anzahl von Ausführungsformen wurden beschrieben. Dennoch ist selbstverständlich, dass verschiedene Modifizierungen vorgenommen werden können. Zum Beispiel können verschiedene Formen der oben dargestellten Abläufe verwendet werden, wobei Schritte neu geordnet, hinzugefügt oder entfernt werden können. Darüber hinaus sollte, wenn verschiedene Anwendungen von Inhaltsliefersystemen und -verfahren beschrieben wurden, erkannt werden, dass zahlreiche andere Anwendungen erwägt werden. Darüber hinaus können, auch wenn viele der Ausführungsformen in Bezug auf dynamisch erstellte Echtzeit-Werbung beschrieben wurden, andere Inhaltslieferungen in anderen verschiedenen Formen ebenfalls bereitgestellt werden. Dementsprechend liegen andere Ausführungsformen im Umfang der folgenden Ansprüche.

Claims

Computerimplementiertes System für die Durchführung von Kommunikation zwischen Domänen in einem Webbrowser, wobei das System eingerichtet ist Folgendes zu implementieren: das Empfangen erster Daten von einer ersten Domäne an einem Router, der mit einer oder mehreren Domänen außer der ersten Domäne verbunden ist; das Identifizieren der einen oder mehreren Domänen für den Empfang von Daten, die mit den empfangenen Daten verbunden sind, am Router; und das Übertragen der zweiten Daten, die mit den empfangenen Daten verbunden sind, an die eine oder mehreren Domänen.
Computerimplementiertes System nach Anspruch 1, worin die zweiten Daten die ersten Daten enthalten.
Computerimplementiertes System nach Anspruch 1, worin die zweiten Daten vom Router zu der einen oder den mehreren Domänen übertragen werden.
Computerimplementiertes System nach Anspruch 1, worin die erste Domäne und die eine oder mehreren Domänen außer der ersten Domäne jeweils durch einen Frame definiert sind.
Computerimplementiertes System nach Anspruch 4, worin der Router durch einen Frame definiert ist.
Computerimplementiertes System nach Anspruch 5, worin das Verfahren iframe-Elemente umfasst.
Computerimplementiertes System nach Anspruch 1, worin die eine oder mehreren Domänen jeweils tragbare Programmmodule implementieren.
Computerimplementiertes System nach Anspruch 7, worin die tragbaren Programmmodule Gadgets umfassen.
Computerimplementiertes System nach Anspruch 1, das des Weiteren dazu eingerichtet ist, das Empfangen von Fremddaten von einer der einen oder mehreren Domänen am Router und das Bereitstellen der Fremddaten für die erste Domäne zu implementieren.
Computerimplementiertes System nach Anspruch 9, des Weiteren dazu eingerichtet ist, das Bereitstellen von Drittanbieterdaten für mindestens einige des ersten oder der weiteren Domänen zu implementieren.
Computerimplementiertes System nach Anspruch 1, des Weiteren dazu eingerichtet, das Senden der ersten Daten des Routers, der mit der einen oder den mehreren Domänen außer der ersten Domäne verbunden ist, von einem Router, der mit der ersten Domäne verbunden ist, zu implementieren.
Computerimplementiertes System nach Anspruch 11, des Weiteren dazu eingerichtet, das Empfangen mehrerer Gruppen von Daten am Router umfassen, der mit der ersten Domäne verbunden ist, und Kombinieren der mehreren Gruppen von Daten in einem einzigen Paket vor dem Senden der mehreren Gruppen von Daten an den Router, der mit der einen oder den mehreren Domänen verbunden ist, zu implementieren.
Computerimplementiertes System nach Anspruch 12, des Weiteren dazu eingerichtet, das Bestellen der multiplen Gruppen von Daten vor dem Übertragen des Pakets, zu implementieren.
Computerimplementiertes System, umfassend: eine erste Anwendung, die auf einer Webseite angezeigt wird und in einer ersten Domäne betrieben wird, die mit einer Webanwendung verbunden ist; eine oder mehrere Anwendungen, die auf der Webseite angezeigt werden und in einer oder mehreren Domänen betrieben werden, die mit der Webanwendung verbunden sind; und ein erstes Relais, das der ersten Anwendung entspricht, ausgeführt, um Daten von der ersten Anwendung zu empfangen und die empfangenen Daten für den Empfang durch die eine oder die mehreren anderen Anwendungen zu verteilen.
Computerimplementiertes System nach Anspruch 14, des Weiteren umfassend ein zweites Relais, das der einen oder den mehreren Anwendungen entspricht, um Daten vom ersten Relais zu empfangen und die Daten an die eine oder die mehreren Anwendungen zu verteilen.
Computerimplementiertes System nach Anspruch 15, worin das erste Relais so konfiguriert ist, dass es Daten vom zweiten Relais empfängt und die empfangenen Daten der ersten Anwendung bereitstellt.
Computerimplementiertes System nach Anspruch 14, worin die erste Anwendung und die eine oder mehreren anderen Anwendungen so konfiguriert sind, dass sie auf einer gemeinsamen Webseite angezeigt werden.
Computerimplementiertes System nach Anspruch 14, worin das erste Relais mehrere Datengruppen in einem einzelnen Paket verpackt, bevor es das einzelne Paket an das zweite Relais sendet.
Computerimplementiertes System nach Anspruch 14, des Weiteren umfassend eine Vielzahl von Frames, worin ein Frame der Vielzahl von Frames eine Anzeige der ersten Anwendungen definiert, und die anderen Frames der Vielzahl von Frames Anzeigen der einen oder mehreren anderen Anwendungen definieren.
Computerimplementiertes System nach Anspruch 14, worin die erste Anwendung eine Kartenanwendung umfasst und die eine oder mehreren anderen Anwendungen Gadgets umfassen.
Computerimplementiertes System, umfassend: eine erste Anwendung, die auf einer Webseite angezeigt wird und in einer ersten Domäne betrieben wird, die mit einer Webanwendung verbunden ist; eine oder mehrere Anwendungen, die auf der Webseite angezeigt werden und in einer oder mehreren Domänen betrieben werden, die mit der Webanwendung verbunden sind; und Mittel zur Übermittlung von Daten zwischen der ersten Anwendung und der einen oder den mehreren anderen Anwendungen.