DE112007000946T5

DE112007000946T5 - Navigationssystem und Framework zur Bereitstellung von Inhalten für einen Endbenutzer

Info

Publication number: DE112007000946T5
Application number: DE112007000946T
Authority: DE
Inventors: Matthew John Broadbent; Benjamin Peter Bodley
Original assignee: Mitac International Corp
Current assignee: Mitac International Corp
Priority date: 2006-04-20
Filing date: 2007-04-20
Publication date: 2009-04-02
Also published as: US20090276318A1; WO2007123422A1; SG136825A1

Abstract

Framework zur Bereitstellung von Navigationsinhalten, enthaltend:
eine Clientvorrichtung, die ein Basis-Navigationsframework zur Bereitstellung einer Basis-Navigationsfunktionalität hat, welches Basis-Navigationsframework eine festgelegte Gruppe von Plug-in-Softwareobjekten unterstützt.

Description

Gebiet der Erfindung
Die vorliegende Erfindung betrifft elektronische Navigationsvorrichtungen und ein Verfahren zur Versorgung von elektronischen Navigationsvorrichtungen mit Daten.
Hintergrund der Erfindung
Navigationsvorrichtungen, die Routenführung bieten, werden zunehmend populärer und eine große Anzahl unterschiedlicher Modelle ist im Handel verfügbar. Beinahe alle modernen Navigationssysteme für Endverbraucher bestimmen die Position unter Verwendung von GPS-Satellitensignalen. Aus einer Kartendatenbank wird dann eine Karte der örtlichen Umgebung auf der Grundlage der bestimmten Position abgerufen und die Position der Vorrichtung wird auf der Karte auf einem Anzeigebildschirm der Vorrichtung angezeigt.
Typischerweise wird auch Routenführung zur Verfügung gestellt. Ein Benutzer kann einen gewünschten Zielort in die Navigationsvorrichtung eingeben und diese stellt die Routenführung zu dem Zielort auf der Grundlage einer berechneten Route (unter Verwendung der Kartendatenbank und eines Routenwahlalgorithmus) und der fortgeführten Erfassung der Position des Benutzers bereit.
Um diese Funktionalität zur Verfügung zu stellen, benötigen Navigationsvorrichtungen GPS-Hardware, Datenspeicher für eine Kartendatenbank und Verarbeitungshardware.
Architektur des Navigationssystems
Eine typische Hardwarearchitektur einer Navigationsvorrichtung ist in 1 schematisch dargestellt. Die Navigationsvorrichtung 10 enthält einen Prozessor 11 und einen mit dem Prozessor 11 verbundenen Speicher 12, wobei der Speicher zur Speicherung von Anwendungsprogrammen zum Ablauf auf dem Prozessor dient. Der Speicher 12 ist typischerweise eine Kombination aus ROM und RAM. Die Vorrichtung 10 enthält ferner ein Speicherelement 13 zur Speicherung von geographischen Daten. Das Speicherelement 13 ist typischerweise eine CD-ROM, ein Festplattenlaufwerk oder ein Halbleiterspeicher, wie zum Beispiel eine Speicherkarte. Die Navigationsvorrichtung 10 enthält ferner eine Anzeige 14 zur Anzeige von Navigationsinformationen und eine Benutzerschnittstelle, um es dem Benutzer zu ermöglichen, Zielinformationen einzugeben und persönliche Einstellungen vorzunehmen. Die Navigationsvorrichtung enthält ferner ein Ortungssystem 15, das GPS-Daten von einer GPS-Antenne 16 erhält. Das Ortungssystem kann auch Daten von anderen Positionssensoren 17, wie zum Beispiel Kreiseln und Radimpulssensoren, empfangen.
Zur Unterstützung der in 1 gezeigten Hardware der Navigationsvorrichtung kann eine "Fat-client"-Softwarearchitektur (manchmal auch als "on-board" bezeichnet) verwendet werden, um die gesamte Karten- und Navigationsfunktionalität lokal in der Vorrichtung bereitzustellen. Eine typische Fat-client-Softwarearchitektur ist in 2 gezeigt und enthält eine Datenbank 20, ein Betriebssystem 21 und eine Verarbeitungsschicht 22. Die Datenbank enthält Kartengeometrie-, -topologie- und -attributdaten, Daten über Orte von Interesse (POI) und Adressnachschlagdaten. Das Betriebssystem kann auf einem im breiten Umfang eingesetzten Betriebssystem basieren, wie zum Beispiel dem Windows Compact Edition Betriebssystem von Microsoft, oder kann ein proprietäres Betriebssystem sein. Auf dem Betriebssystem ablaufende Anwendungen schließen eine Kartenzeichnungsanwendung, eine Zielnachschlaganwendung, eine Routenberechnungsanwendung, eine Kartenanpassungsanwendung und eine Routenführungsanwendung ein.
Fat clients besitzen die Vorteile, dass sie vollständig unabhängig von allen anderen Systemen und Infrastruktur arbeiten können, dass sie an jedem Ort genutzt werden können, sofern eine Karte verfügbar ist, dass sie sehr rasch auf Benutzereingaben reagieren, was für den Benutzer eine hohe Zuverlässigkeit darstellt, und dass sie keine laufenden Kosten haben. Ihre Nachteile sind, dass sie relativ großen Aufwand hinsichtlich Systemressourcen erfordern und schwierig einzusetzen und zu aktualisieren sind.
Eine vielfach eingesetzte Alternative für die Fat-client-Architektur für verbundene Vorrichtungen ist der "Thin client" (manchmal auch als "off-board" bezeichnet). Hier liegen die Kartendaten und die Funktionalität der Anwendungsprogramme auf einem entfernten Navigations-"Server", der von einer großen Anzahl von Navigationsvorrichtungen, typischerweise durch ein drahtloses Netz, genutzt wird. Eine typische Thin-client-Navi gationssystemarchitektur ist in 3 dargestellt. Client-Vorrichtungen 30 und 31 kommunizieren über ein drahtloses Netz 32 mit einem Netzbetreiber 33. Jedes beliebige Netz kann verwendet werden. Beispiele sind ein zelluläres Netz und ein 802.11 LAN. Der Drahtlos-Netzbetreiber 33 hat Einrichtungen, um Vorrichtungen im drahtlosen Netz mit dem Internet 36 zu verbinden, einschließlich eines spezifischen Servers 37 im Internet, der von einem Navigationsdienstanbieter betrieben wird. Der Server ist in der Lage, nach Erfordernis mit mehreren Clientvorrichtungen zu kommunizieren.
Die Clientvorrichtungen können beliebige geeignete verbundene Einrichtungen sein, einschließlich einer verbundenen Variante der in 1 gezeigten Vorrichtung. Typischerweise ist der Client ein verbundener PDA beziehungsweise ein verbundenes Mobiltelefon mit Ortserkennung, das für Benutzer des drahtlosen Netzes problemlos verfügbar ist. 4 zeigt die Hardwarearchitektur für eine Clientvorrichtung. Die Clientvorrichtung 40 enthält einen Prozessor 41, einen Speicher 42, eine Speichereinrichtung 43, eine Anzeige und Benutzerschnittstelle 44 und ein Ortungssystem 45. Der Client hat eine Kommunikationseinrichtung 46, die zur Kommunikation mit einem Navigationsserver verwendet wird. Auf der Clientvorrichtung läuft Clientsoftware, wie zum Beispiel ein Web-Browser, der zur Anzeige von HTML-Inhalt in der Lage ist, oder ein WAP-Microbrowser, der in der Lage ist, WML-Inhalt anzuzeigen. Die Funktionalität der Clientsoftware ist weitgehend auf die Kommunikation mit dem Server und die Darstellung von Informationen, die vom Server abgegeben werden, gewöhnlich in Form von HTML oder WML, vereinfacht. Der Client ist auch für das Empfangen und die Verarbeitung von Benutzereingaben und Positionsdaten von dem Ortungssystem 45 verantwortlich. Von dem Server gesendete Informationen können die Benutzerschnittstelle der Anwendung und Navigationsinformationen, wie zum Beispiel Karten und Abbiegeanweisungen einschließen, die von dem Server erzeugt wurden.
5 ist eine schematische Darstellung einer typischen Hardwarearchitektur eines Servers, wie etwa des unter Bezug auf 3 genannten Servers 37. Vorzugsweise ist der Server eine Mehrzweck-Hardwarevorrichtung, wie zum Beispiel ein PC oder ein im Gestell montierter Server, wie sie allgemein zum Ablauf von Server-basierten Anwendungen verwendet werden. Der Server 50 enthält einen Prozessor 51, einen Speicher 52, ein Speicherelement 53 zur Speicherung von Daten einschließlich geographischer Daten und Software zum Ablauf auf dem Prozessor. Das Speicherelement 53 ist typischerweise ein Festplattenlaufwerk. Damit der Server 50 von einer Bedienungsperson gesteuert werden kann, schließt die Serverhardware Steuereinrichtungen 54 zur Bedienersteuerung des Servers ein. Beispiele für Steuereinrichtungen sind ein Bildschirm, eine Tastatur oder eine Fernverbindung, wie zum Beispiel Telnet und ein entfernter Arbeitsplatz. Der Server 50 enthält ferner eine Kommunikationseinrichtung 55, die die Kommunikation zwischen Client- und Serverelementen erlaubt. Eine weitere Kommunikationseinrichtung 56, die gleich wie die Einrichtung 55 sein kann, erlaubt dem Server die Kommunikation mit dem Internet. In einigen Systemen werden viele Clients in Verbindung mit wenigen Servern verwendet, und in diesem Fall kann die Kommunikationseinrichtung 55 auf eine große Anzahl von gleichzeitigen Clientverbindungen skaliert werden. Ein Beispiel für eine Verbindungsskalierungseinrichtung ist ein Lastausgleichsserver, der Clientverbindungen erforderlichenfalls auf andere Server verteilt.
6 zeigt eine typische Softwarearchitektur für einen Navigationsserver, wie zum Beispiel den unter Bezug auf 5 genannten Server 50. Die Serversoftware enthält ein Betriebssystem 60, eine Basis-Serverplattform 61 und Dienstsoftware 63. Das Betriebssystem kann auf einem weit verbreiteten Betriebssystem, wie zum Beispiel Microsoft Windows oder Linux, basieren. Eine Basis-Serverplattform 61 bietet Komponenten, die allgemein von Softwareprogrammen verwendete Funktionalität enthalten. Diese Komponenten 61 können in Verbindung mit dem Betriebssystem von dem Lieferanten des Betriebssystems oder einem Drittanbieter zur Verfügung gestellt oder können zur Unterstützung von bestimmten Arten von Anwendungen speziell geschaffen werden. Beispiele sind eine C Standard Bibliothek, C++ Standard Bibliothek, Datenbanken, wie zum Beispiel Oracle oder Informix, und Laufzeitumgebungen und Bibliotheken für Sprachen, wie zum Beispiel Java und .NET. Der Server enthält Kartendaten 62 einschließlich Kartengeometrie-, -topologieund -attributdaten, Daten über Punkte von Interesse (POI) und Adressnachschlagdaten. Der Server betreibt eine Vielzahl von Navigationsdiensten 63 auf dem Betriebssystem, die die Komponenten der Basis-Serverplattform 61 und die Kartendaten 62 nutzen. Die Navigationsdienste 63 schließen einen Kartenzeichnungsdienst, einen Zielnachschlagdienst und einen Routenberechnungsdienst und einen Manövererzeugungsdienst ein. Die Funktionalität des Navigationsservers beinhaltet hauptsächlich die Nutzung der Navigationsdienste zur Erzeugung von Inhalt in einem Format, wie etwa HTML oder WML, der sowohl die Benutzerschnittstelle als auch die Navigationsbereitstellungsinformationen zur Verwendung auf Clientvorrichtungen enthält.
Thin-client-Systeme haben den Vorteil, dass der Kartendateninhalt und die von den Clientvorrichtungen genutzten Anwendungen leicht zu aktualisieren sind, dass sie bedingt durch die gewöhnlich große Speicherkapazität des Servers, auf dem alle Daten liegen, wesentlich umfangreichere Karten und POI-Daten haben können, dass sie durch die Vornahme von Veränderungen an einer Stelle am Server eingesetzt und aktualisiert werden können, und die Clientvorrichtungen gewöhnlich billiger sind als bei Fat-client-Systemen. Thin-client-Systeme haben den Nachteil, dass sie nur dann arbeiten, wenn eine Verbindung zum Server verfügbar ist, dass gewöhnlich laufende Kosten durch die Datenübertragung zwischen Client und Server und den Unterhalt der teuren Serverinfrastruktur entstehen, und dass sie aufgrund von Bandbreitenbeschränkungen, Netzverzögerungen oder hoher Systemlast dem Benutzer eine mangelhafte Nutzungsqualität bieten können.
Es gibt alternative verbundene Architekturen, die als Smart clients bezeichnet werden, die die Vorteile des Ansprechverhaltens sowie der Verfügbarkeit der Fat clients in Verbindung mit den Vorteilen des Zugriffs von Thin clients auf umfangreiche und aktuelle Informationen beizubehalten versuchen. Smart clients arbeiten lokal und bieten dem Benutzer eine adaptive, ansprechfreudige und umfangreiche Erfahrung, indem lokale Ressourcen, wie zum Beispiel Arbeitsspeicher, Massenspeicher, Grafik und Verarbeitungsfähigkeit ausgenutzt werden. Obgleich sie als Einzelgeräte arbeiten können, sind Smart Clients in der Lage, mit entfernten Systemen intelligent Verbindung aufzunehmen und Daten auszutauschen, um eine noch umfangreichere Nutzungserfahrung zu bieten. Smart clients können die Benutzung des Kommunikationskanals optimieren und Vorteile hinsichtlich Kosten und Leistungen bieten, da die Benutzerschnittstelle nicht konstant von einem Server übertragen wird und somit ansprechfreudiger ist. Da Smart clients verbunden sind, können sie sich oftmals im Hintergrund selbst aktualisieren, wenn neue Softwareversionen verfügbar sind, indem sie den Kommunikationskanal nutzen, wenn er ansonsten inaktiv wäre.
Probleme bei gegenwärtigen Vorgehensweisen
Während die vorhandenen Hardware- und Softwarearchitekturen für Benutzer gut funktionieren, kann das Hinzufügen von neuer Funktionalität unabhängig davon, ob eine Fat-, Thin- oder Smart-Client-Lösung verwendet wird, sowohl aus technischen als auch logistischen Gründen schwierig sein.
Als Reaktion auf die Verfügbarkeit von neuen Karten- und Inhaltsdaten, die verbesserte Abdeckung und bessere Attribute enthalten, entwickeln sich die Negationsprodukte rasch. Zusätzlich werden neue Formen von Inhalt verfügbar, wenn mehr Vorrichtungen verbunden sind und Zugriff auf eine überwältigende Vielzahl von Daten und Diensten haben. Inhalt ist ein Hauptunterscheidungsmerkmal und eine zentrale Quelle, aus der die Produktfunktionalität in großem Umfang bezogen wird. Größtenteils wird diese wichtige Rolle in der Konstruktion der gegenwärtigen Systeme nicht wiedergegeben, die danach streben, Inhaltsdaten zum Zeitpunkt des Systemaufbaus in eine gleichförmige und vorbestimmte Form umzugestalten. Derartige Navigationssysteme können nur diese spezifischen Datenformen nutzen und sind nicht in der Lage, neue Arten von Daten zu verwenden, die zur Verfügung gestellt werden, sofern diese nicht adaptiert werden. Sie sind nicht "inhaltszentriert" und können nicht ohne weiteres auf Veränderungen in Inhaltsdaten reagieren.
Das Problem wird weiter verstärkt, da zur Unterstützung einer Ausweitung der Funktionalität zum Zeitpunkt des Aufbaus Navigationsanwendungen zunehmend komplexer werden mit vielen wechselwirkenden Teilen, die häufig in monolithischen Systemen miteinander kombiniert sind. Abhängigkeiten zwischen Komponenten können es schwierig machen, einen Teil der Systemsoftware zu verändern, ohne andere Teile des Systems zu beeinflussen, und können bedeuten, dass anstatt einer Aktualisierung eines Teiles eines vorhandenen Produkts tatsächlich ein neues Produkt veröffentlicht wird. Zusätzlich führt das Erfordernis, die Entwicklung aller Komponenten abzuwarten, bevor ein Integrations- und Testzyklus vollendet wird, zu längeren Entwicklungszeiten. Die Verwaltung und Koordinierung derartiger großer Projekte und Entwicklungsteams ist logistisch schwierig.
Um zur Software neue Merkmale hinzuzufügen, müssen die in 7 gezeigten Schritte sequenziell durchgeführt werden. Zunächst wird ein neues Merkmal entwickelt 70, wenn zusätzliche Datenattribute zur Verfügung stehen. Ein Kartenproduktionswerkzeug, das Quelldaten in das physische Speicherformat des Systems umwandelt, wird erforderlichenfalls verändert 71, so dass es neue Attribute unterstützt, die mit dem Merkmal in Beziehung stehen. Kartendaten werden unter Verwendung des aktualisierten Kartenproduktionssystems aufgebaut 72, um Daten in einem systemspezifischen physischen Speicherformat zu produzieren. Die Navigationsmaschine wird aktualisiert 73, so dass sie an den Daten vorgenommene Veränderungen nutzen kann. Entsprechende Veränderungen zur Unterstützung der neuen Merkmale werden an verschiedenen Modulen vorgenommen 74, die Teile der Benutzeranwendung sind. Die Benutzerschnittstelle und die Grafik werden modifiziert, so dass sie die neue Funktionalität unterstützen, die erforderlich ist, und eine vollständig integrierte Anwendung wird aus allen genannten Komponenten aufgebaut 75.
Eine Folge dieses seriellen Gestaltungs- und Produktionsprozesses ist, dass speziell maßgeschneiderte Produkte, die spezielle Datenquellen nutzen, um die Erfordernisse von bestimmten Endbenutzern zu erfüllen, eine lange Entwicklungszeit haben. Anstelle dessen werden diese Produkte zu Gunsten allgemeiner Produkte, die allen gerecht zu werden versuchen, die am Ende jedoch oftmals eine redundante Funktionalität für viele Endbenutzer bereitstellen, oftmals an den Rand gestellt.
Es ist eine Aufgabe der vorliegenden Erfindung, einige der vorstehend genannten Probleme anzusprechen oder zumindest der Öffentlichkeit eine nützliche Alternative zu bieten.
Kurzbeschreibung der Erfindung
In der nachfolgenden Beschreibung betrifft der Begriff "Plug-in-Softwareobjekt" Inhaltselemente, die sowohl ausführbaren Programmcode als auch Informationsdaten enthalten. Der Begriff "Framework zur Bereitstellung von Navigationsinhalten" soll alle Elemente eines Navigationsbereitstellungssystems bezeichnen, das auch in der Lage ist, Plug-in-Softwareobjekte zu erzeugen, zu transportieren und zu nutzen. Der Begriff "Basis-Navigationsframework" bezieht sich auf diejenigen Elemente eines Frameworks zur Bereitstellung von Navigationsinhalten, die für eine Navigationsvorrichtung spezifisch sind, die eine Basis-Navigationsfunktionalität bereitstellt und die in der Lage ist, Plug-in-Softwareobjekte zu verwenden. "Basis-Navigationsfunktionalität" ist in diesem Kontext so zu verstehen, dass es eine allgemein verwendete Navigationsfunktionalität bezeichnet, wie etwa die Anzeige einer Karte in beliebiger Position, Ausrichtung und Maßstab; Funktionen zur Suche nach Zielinformationen, wie zum Beispiel Straßenadressen und Namen und Arten von Punkten von Interesse, und Auflösen derselben nach Breiten-/Längenkoordinaten; einen Algorithmus zur Berechnung eines optimalen Weges; einen Manövererzeugungsalgorithmus, der einen optimalen Weg in eine Reihe von entlang der Route durchzuführenden Manövern umwandelt; ein Fahrzeugortungsmodul, das die gegenwärtige Position durch Abstimmung von verfügbaren Ortungs- und Bewegungsinformationen mit Daten aus einer Karte bestimmt; einen Anweisungsmechanismus, der nach Erfordernis Hinweise als Text, Symbol oder in hörbarer Form erzeugt.
Gemäß einem ersten Aspekt schafft die vorliegende Erfindung ein Framework zur Bereitstellung von Navigationsinhalten, enthaltend:
eine Clientvorrichtung, die ein Basis-Navigationsframework zur Bereitstellung einer Basis-Navigationsfunktionalität hat, welches Basis-Navigationsframework eine festgelegte Gruppe von Plug-in-Softwareobjekten unterstützt.
Vorzugsweise enthält das Framework zur Bereitstellung von Inhalten ferner einen Server, der mit der Clientvorrichtung verbunden ist und der dafür konfiguriert ist, Plug-in-Softwareobjekte für die Clientvorrichtung bereitzustellen, welche Plug-in-Softwareobjekte der Clientvorrichtung zusätzliche Funktionalität verleihen.
Vorzugsweise sind die Clientvorrichtung und der Server über eine drahtlose Verbindung verbunden. Alternativ sind der Client und der Server physisch in derselben Vorrichtung angeordnet.
Gemäß einem zweiten Aspekt schafft die vorliegende Erfindung ein Verfahren zur Bereitstellung von zusätzlicher Funktionalität für eine Clientvorrichtung, die ein Basis-Navigationsframework zur Bereitstellung einer Basis-Navigationsfunktionalität hat, welches Basis-Navigationsframework eine festgelegte Gruppe von Plug-in-Softwareobjekten unterstützt, enthaltend den Schritt:
Bereitstellen von Plug-in-Softwareobjekten für die Clientvorrichtung, welche Plug-in-Softwareobjekte der Clientvorrichtung zusätzliche Funktionalität verleihen.
Vorzugsweise schließt der Schritt des Bereitstellens von Plug-in-Softwareobjekten die Bereitstellung von Plug-in-Softwareobjekten von einem Server über eine drahtlose Verbindung ein. Alternativ oder zusätzlich schließt der Schritt des Bereitstellens von Plug-in-Softwareobjekten das Einbetten der Plug-in-Softwareobjekte in geographischen Daten, die in der Clientvorrichtung gespeichert sind, ein.
Vorzugsweise werden in den Plug-in-Softwareobjekten enthaltener Programmcode und Daten in die Programmfunktionalität der Clientsoftware in der Clientvorrichtung integriert, während der Programmcode auf der Clientvorrichtung ausgeführt wird.
Vorzugsweise ist der in den Plug-in-Softwareobjekten enthaltene Programmcode in einem portierbaren Byte-Code, wie zum Beispiel Java, .NET oder P-Code formatiert und wird von einer in der Clientvorrichtung enthaltenen virtuellen Maschine ausgeführt. Ein portierbarer Byte-Code ist unabhängig von der Plattform, auf der er abläuft.
Gemäß einem dritten Aspekt schafft die vorliegende Erfindung ein Verfahren zur Bereitstellung zusätzlicher Funktionalität für eine Clientvorrichtung, die ein Basis-Navigationsframework zur Bereitstellung von Basis-Navigationsfunktionalität hat, welches Basis-Navigationsframework eine festgelegte Gruppe von Plug-in-Softwareobjekten unterstützt, enthaltend die Schritte:
Bereitstellen von Plug-in-Softwareobjekten für die Clientvorrichtung, und
Speichern der Plug-in-Softwareobjekte zeitweilig oder dauerhaft in der Clientvorrichtung, welche Plug-in-Softwareobjekte der Clientvorrichtung zusätzliche Funktionalität verleihen, wenn sie in der Clientvorrichtung ausgeführt werden.
Vorzugsweise enthält der Schritt des Bereitstellens von Plug-in-Softwareobjekten das Bereitstellen nur derjenigen Objekte, die nicht bereits dauerhaft oder vorübergehend in der Clientvorrichtung gespeichert sind.
Vorzugsweise enthält der Schritt des Speicherns der Plug-in-Softwareobjekte in der Clientvorrichtung das Speichern der Plug-in-Softwareobjekte, bis sie ungültig gemacht werden, da die Funktionalität oder Daten, die sie einschließen, zurückgezogen oder aktualisiert wurden. Alternativ oder zusätzliche enthält das Verfahren ferner das Löschen der Plug-in-Softwareobjekte, um Platz für in jüngerer Zeit erzeugte Plug-in-Softwareobjekte zu schaffen, bedingt durch die Einschränkungen des begrenzten Speicherraums der Speichereinrichtung für die Plug-in-Softwareobjekte.
Vorzugsweise enthält das Verfahren ferner den Schritt der Registrierung der Plug-in-Softwareobjekte in der Clientvorrichtung, um Bedingungen anzugeben, welche dann, wenn sie eintreten, die Löschung der Plug-in-Softwareobjekte verursachen.
Gemäß einem vierten Aspekt schafft die vorliegende Erfindung ein Framework zur Bereitstellung von Navigationsinhalten, enthaltend:
einen Server, der dafür konfiguriert ist, Plug-in-Softwareobjekte für Clientvorrichtungen bereitzustellen, welche Plug-in-Softwareobjekte den Clientvorrichtungen zusätzliche Funktionalität verleihen, wenn sie auf den Clientvorrichtungen ausgeführt werden.
Vorzugsweise ist der Server dafür konfiguriert, Details der verfügbaren Plug-ins an die Clientvorrichtungen zu senden.
Gemäß einem fünften Aspekt schafft die vorliegende Erfindung ein Framework zur Bereitstellung von Navigationsinhalten, enthaltend:
eine Clientvorrichtung, die ein Basis-Navigationsframework zur Bereitstellung einer Basis-Navigationsfunktionalität hat, welches Basis-Navigationsframework eine festgelegte Gruppe von Plug-in-Softwareobjekten unterstützt;
eine Eingabeeinrichtung, die mit der Clientvorrichtung verbunden ist oder ein Teil derselben ist, um in Übereinstimmung mit einer mit der Clientvorrichtung verbundenen Eigenschaft ein Eingabesignal abzugeben;
wobei die Plug-in-Softwareobjekte zur Ausführung auf der Clientvorrichtung ansprechend auf ein Signal von der Eingabeeinrichtung programmiert sind.
Vorzugsweise ist die Eingabeeinrichtung eine absolute Ortungseinrichtung, wie z. B. ein GPS-Sensor. Alternativ oder zusätzlich kann die Eingabeeinrichtung die Geschwindigkeit der Clientvorrichtung, die Umgebungstemperatur, Umgebungslichtpegel, Wassertiefe, die Zeit oder spezifische Formen von Benutzereingaben erfassen.
Vorzugsweise sind die Plug-in-Softwareobjekte zur Registrierung in der Clientvorrichtung programmiert, um relevante Auslösesignale und Bedingungen festzulegen.
Gemäß einem sechsten Aspekt schafft die vorliegende Erfindung ein Verfahren zur Bereitstellung von Navigationsfunktionalität oder Navigationsinformationen für einen Benutzer einer Clientvorrichtung, die ein Basis-Navigationsframework zur Bereitstellung von Basis-Navigationsfunktionalität hat, welches Basis-Navigationsframework eine festgelegte Gruppe von Plug-in-Softwareobjekten unterstützt, enthaltend den Schritt:
Bereitstellen von Plug-in-Softwareobjekten, die zur Ausführung auf der Clientvorrichtung ansprechend auf eine bestimmte Bedingung in Verbindung mit der Clientvorrichtung programmiert sind.
Vorzugsweise ist die bestimmte Bedingung auf die Position der Clientvorrichtung bezogen.
Gemäß einem siebten Aspekt schaffte die vorliegende Erfindung ein Framework zur Bereitstellung von Navigationsinhalten, enthaltend:
eine Clientvorrichtung, die ein Basis-Navigationsframework zur Bereitstellung von Basis-Navigationsfunktionalität hat, welches Basis-Navigationsframework eine festgelegte Gruppe von Plug-in-Softwareobjekten unterstützt; und
einen Server in Kommunikation mit der Clientvorrichtung und dem Internet;
wobei die Clientvorrichtung eine Einrichtung enthält, um eine Anforderung von Inhalten an den Server zu senden, und wobei der Server eine Einrichtung zur Anforderung des Inhalts von mit dem Internet verbundenen Quellen auf der Grundlage der Anforderung von der Clientvorrichtung, eine Einrichtung zum Empfangen des resultierenden Inhalts und eine Einrichtung zum Übertragen desselben an die Clientvorrichtung in Form eines Plug-in-Softwareobjekts einschließt.
Vorzugsweise enthält die Clientvorrichtung ein Positionsbestimmungssystem. Vorzugsweise gibt der Server ein Plug-in-Softwareobjekt an die Vorrichtung ab, das bei Ausführung in der Clientvorrichtung eine Einrichtung für einen Benutzer zur Anforderung von Inhalt bereitstellt.
Vorzugsweise wird die Position der Clientvorrichtung, wie sie durch das Positionsbestimmungssystem bestimmt wurde, mit der Anforderung von Inhalt gesendet, und der zu der Clientvorrichtung übertragene Inhalt wird in Abhängigkeit von der Position maßgeschneidert. Alternativ oder zusätzlich wird die Anforderung von Inhalt in Abhängigkeit von dem aktuellen Reiseweg, der Reisegeschwindigkeit, der Tageszeit, dem Datum oder bestimmten benutzerdefinierten Präferenzen maßgeschneidert.
Vorzugsweise stellt der Server Plug-in-Softwareobjekte für die Clientvorrichtung bereit, die der Clientvorrichtung zusätzliche Funktionalität zur Verfügung stellen.
Gemäß einem achten Aspekt schafft die vorliegende Erfindung ein Verfahren zur Anzeige von Inhalt von einer Inhaltsquelle auf einer Clientvorrichtung, die ein Display aufweist, enthaltend die Schritte:
Empfangen einer Anforderung von Inhalt von der Clientvorrichtung in einem entfernten Navigationsserver;
Senden der Anforderung von dem Navigationsserver zu einem Server, der den Inhalt im Internet bereitstellt;
Empfangen des Inhalts in dem Navigationsserver;
Umformatieren des Inhalts als ein Flug-in-Softwareobjekt; und
Senden des Plug-in-Softwareobjekts an die Clientvorrichtung;
welches Flug-in-Softwareobjekt zur Ausführung auf der Clientvorrichtung programmiert ist, um Informationen auf der Anzeige der Clientvorrichtung aufzubereiten.
Vorzugsweise wird eine Positionsangabe der Clientvorrichtung mit der Anforderung von Inhalt am Server empfangen.
Vorzugsweise ist das Flug-in-Softwareobjekt dafür programmiert, eine auf den Benutzer abgestimmte Informationsanzeige zu erzeugen, wenn es auf einer Clientvorrichtung ausgeführt wird. Vorzugsweise enthält die Clientvorrichtung ferner eine Kartenanzeige und das Plug-in-Softwareobjekt ist dafür programmiert, die Kartenanzeige zu ändern oder sie mit zusätzlichen Informationen zu ergänzen.
Vorzugsweise enthält das Verfahren ferner den Schritt des Sendens eines ersten Plug-in-Softwareobjekts von dem Server an die Clientvorrichtung, welches erste Plug-in-Softwareobjekt bei Ausführung auf der Clientvorrichtung die Anforderung von Inhalt erlaubt. Vorzugsweise erzeugt das erste Plug-in-Softwareobjekt bei der Ausführung auch eine Benutzerschnittstelle, um die Benutzeranpassung der Inhaltsanforderung zu unterstützen, wenn dies von einer Internet-Inhaltsquelle gefordert wird.
Gemäß einem neunten Aspekt schafft die vorliegende Erfindung ein Framework zur Bereitstellung von Navigationsinhalten, enthaltend:
eine Clientvorrichtung, die eine Anzeige hat; und
einen Server in Kommunikation mit der Clientvorrichtung und dem Internet; und der Einrichtungen hat, um auf Inhaltsquellen im Internet zuzugreifen;
wobei die Clientvorrichtung so arbeitet, dass sie Icons, die bevorzugte Inhaltsanforderungen darstellen, auf der Anzeige der Clientvorrichtung anzeigt, und wobei die Clientvorrichtung so arbeitet, dass sie eine vorbestimmte Inhaltsanforderung an die Internet-Inhaltsquelle ansprechend auf die Auswahl eines Icons auf der Anzeige durch einen Benutzer sendet.
Vorzugsweise sind die bevorzugten Inhaltsanforderungen darstellenden Icons in ein Icon-basiertes Menü der Clientvorrichtung integriert.
Vorzugsweise ist die Internet-Inhaltsquelle eine Datenbank, Suchmaschine oder eine Fernerfassungseinrichtung. Vorzugsweise ist die Inhaltsanforderung eine Suchanfrage oder ein Suchbefehl.
Gemäß einem zehnten Aspekt schafft die vorliegende Erfindung ein System zur Bereitstellung einer Navigationsbenutzerschnittstelle auf einer Clientvorrichtung, enthaltend:
eine Clientvorrichtung, die eine Anzeige hat, ein Basis-Navigationsframework zur Bereitstellung von Basis-Navigationsfunktionalität, welches Basis-Navigationsframework eine festgelegte Gruppe von Plug-in-Softwareobjekten unterstützt; und
einen Server in Kommunikation mit der Clientvorrichtung, der eine Zieldatenbank hat, die Einzelheiten von speziellen Zielen zusammen mit für jedes spezielle Ziel spezifischen Plug-in-Softwareobjekten enthält;
wobei bei der Benutzung dann, wenn ein Benutzer in der Clientvorrichtung ein Ziel zur Routenwahl auswählt, die Clientvorrichtung von dem Server abfragt, ob das ausgewählte Ziel in der Zieldatenbank ist, und dann, wenn das ausgewählte Ziel in der Zieldatenbank ist, an den Client ein Plug-in-Softwareobjekt sendet, das Funktionalität zu der Clientvorrichtung hinzufügt.
Gemäß einem elften Aspekt schafft die vorliegende Erfindung ein Verfahren zur Bereitstellung einer Navigationsbenutzerschnittstelle auf einer Clientvorrichtung, enthaltend die Schritte:
Bezeichnen eines Ziels als ein spezielles Ziel; und
dann, wenn der Benutzer Routenführung zu diesem Ziel anfordert, Bereitstellen einer zielspezifischen Benutzerschnittstelle auf der Clientvorrichtung.
Vorzugsweise ist die Clientvorrichtung mit einem zentralen Server verbunden, der eine Live-Datenbank spezieller Ziele enthält. Vorzugsweise wird die zielspezifische Benutzerschnittstelle für die Clientvorrichtung in Form eines oder mehrerer Software-plug-ins bereitgestellt.
Vorzugsweise ist das spezielle Ziel ein Geschäftsbetrieb. Vorzugsweise schließt die zielspezifische Benutzerschnittstelle ein Logo, Farben oder Werbung in Zusammenhang mit dem Ziel ein.
Gemäß einem zwölften Aspekt schafft die vorliegende Erfindung ein Framework zur Bereitstellung von Navigationsinhalten, enthaltend:
eine erste Vorrichtung, die ein Basis-Navigationsframework zur Bereitstellung von Basis-Navigationsfunktionalität und eine Einrichtung zur Verbindung mit einem drahtlosen Kommunikationsnetz hat;
wobei die erste Vorrichtung eine Benutzerschnittstelle hat, die es einem Benutzer der ersten Vorrichtung erlaubt, einen Ort anzugeben; und
wobei bei der Benutzung die erste Vorrichtung automatisch erzeugte Informationen in Abhängigkeit von dem Ort zu einer entfernten Vorrichtung sendet, die eine Einrichtung zur Verbindung mit dem drahtlosen Kommunikationsnetz hat.
Die Informationen können in jedem beliebigen Format vorliegen. Vorzugsweise sind die automatisch erzeugten Informationen in Form einer SMS- oder MMS-Mitteilung.
Vorzugsweise ist die erste Vorrichtung eine Clientvorrichtung gemäß dem ersten oder fünften Aspekt der vorliegenden Erfindung. Die entfernte Vorrichtung kann eine beliebige ähnliche oder unähnliche Vorrichtung sein, die mit dem drahtlosen Netz verbunden ist.
Vorzugsweise enthalten die automatisch erzeugten Informationen Informationen über den angegebenen Ort oder Routenführungsinformationen, die angeben, wie der angegebene Ort zu erreichen ist. Vorzugsweise enthalten die automatisch erzeugten Informationen Werbeinhalte für ein Geschäft.
Gemäß einem dreizehnten Aspekt schafft die vorliegende Erfindung ein Verfahren zur Bereitstellung von Navigationsinformationen für eine Vorrichtung, die mit einem Framework zur Bereitstellung von Navigationsinhalten verbunden ist, welches Framework zur Bereitstellung von Navigationsinhalten eine erste Vorrichtung enthält, die ein Basis-Navigationsframework zur Bereitstellung von Basis-Navigationsfunktionalitäten hat, sowie eine Einrichtung zur Verbindung mit einem drahtlosen Kommunikationsnetz, welches Basis-Navigationsframework eine festgelegte Gruppe von Plug-in-Softwareobjekten unterstützt, und einen Server, der Plug-in-Softwareobjekte für die erste Vorrichtung bereitstellen kann, welche Plug-in-Softwareobjekte zusätzliche Funktionalität für die erste Vorrichtung bieten, wenn sie auf der ersten Vorrichtung ausgeführt werden; enthaltend die Schritte:
Empfangen eines Plug-in-Softwareobjekts von dem Server in der ersten Vorrichtung;
Erlauben, dass ein Benutzer der ersten Vorrichtung einen Ort angibt; und
Senden von automatisch angepassten Informationen in Abhängigkeit von dem Ort zu einer entfernten Vorrichtung, die eine Einrichtung zur Verbindung mit dem drahtlosen Kommunikationsnetz hat;
wobei das Plug-in-Softwareobjekt automatisch in der ersten Vorrichtung ausgeführt wird und es erlaubt, dass die zu der entfernten Vorrichtung gesendete Information angepasst wird.
Die Informationen können in jedem beliebigen Format vorliegen. Vorzugsweise haben die Informationen die Form einer SMS- oder MMS-Mitteilung.
Vorzugsweise ist die erste Vorrichtung eine Clientvorrichtung gemäß dem ersten oder fünften Aspekt der vorliegenden Erfindung. Die entfernte Vorrichtung kann eine beliebige ähnliche oder unähnliche Vorrichtung sein, die mit dem drahtlosen Netz verbunden ist.
Vorzugsweise enthalten die von der ersten Vorrichtung an die entfernte Vorrichtung gesendeten Informationen Informationen über den angegebenen Ort oder Routenführungsinformationen, die angeben, wie der angegebene Ort zu erreichen ist.
Vorzugsweise enthalten die Informationen ferner Werbeinhalte für einen Geschäftsbetrieb.
Kurzbeschreibung der Zeichnungen
Beispiele der vorliegenden Erfindung werden nachfolgend im Detail unter Bezugnahme auf die beiliegenden Zeichnungen beschrieben.
1 ist eine schematische Darstellung einer persönlichen Navigationsvorrichtung gemäß dem Stand der Technik;
2 ist eine schematische Darstellung einer Softwarearchitektur, die in einem Fat-Client-System des in 1 dargestellten Typs nach dem Stand der Technik verwendet wird;
3 ist eine schematische Darstellung einer Thin-Client-Navigationssystemarchitektur nach dem Stand der Technik;
4 ist eine schematische Darstellung einer Hardwarearchitektur einer Thin-Client-Vorrichtung nach dem Stand der Technik;
5 ist eine schematische Darstellung einer Server-Hardwarearchitektur gemäß dem Stand der Technik;
6 ist eine schematische Darstellung einer Server-Softwarearchitektur nach dem Stand der Technik;
7 zeigt einen Merkmalsintegrationsprozess für Navigationssoftware nach dem Stand der Technik;
8 ist eine schematische Darstellung einer Systemarchitektur, bei der alle Elemente gemäß der vorliegenden Erfindung getrennt sind;
9 ist eine schematische Darstellung einer Systemarchitektur, die aus Client- und Server-Elementen gemäß vorliegender Erfindung besteht;
10 ist eine schematische Darstellung einer Systemarchitektur für eine kombinierte Client- und Server-Navigationsvorrichtung gemäß der vorliegenden Erfindung, die mit dem Internet verbunden ist;
11 ist eine schematische Darstellung einer Systemarchitektur für eine unabhängige Vorrichtung gemäß vorliegender Erfindung;
12 ist eine schematische Darstellung der Hardware- und Softwareelemente, die eine Clientvorrichtung gemäß vorliegender Erfindung enthält;
13 ist eine schematische Darstellung der Beziehung zwischen einer Basis-Navigationsplattform und einem Basis-Navigationsframework gemäß vorliegender Erfindung;
14 ist eine schematische Darstellung von Elementen, die mit einem Plug-in-Softwareobjekt-Framework gemäß vorliegender Erfindung in Beziehung stehen;
15 zeigt ein Beispiel einer Aktivierungslebensdauer eines Plug-in-Softwareobjekts gemäß vorliegender Erfindung;
16 ist eine schematische Darstellung der Softwarearchitektur eines Inhaltskanaldienstes gemäß vorliegender Erfindung;
17 zeigt einen beispielhaften Prozess zur Erzeugung und Übertragung von Plug-in-Softwareobjekten von einem Server gemäß vorliegender Erfindung;
18 zeigt einen beispielhaften Prozess für die Anforderung und Übertragung von Plug-in-Softwareobjekten von einem Server gemäß vorliegender Erfindung;
19 ist eine schematische Darstellung einer Systemarchitektur, die gemäß vorliegender Erfindung einen Verzeichnisserver enthält;
20 ist eine schematische Darstellung einer Verzeichnisdienst-Softwarearchitektur gemäß vorliegender Erfindung;
21 zeigt einen beispielhaften Prozess zur Anmeldung und Abmeldung eines Inhaltskanals bei einem Verzeichnisdienst gemäß vorliegender Erfindung;
22 zeigt einen beispielhaften Prozess zum Abonnieren eines Inhaltskanals gemäß vorliegender Erfindung;
23 ist eine schematische Darstellung von Elementen des Sicherheitsframeworks gemäß vorliegender Erfindung;
24 zeigt einen beispielhaften Prozess zum sicheren Abonnieren eines Inhaltskanals durch eine Clientvorrichtung gemäß vorliegender Erfindung;
25 ist eine schematische Darstellung der Beziehung zwischen einem Benutzerinteraktionsframework und anderen Systemelementen gemäß vorliegender Erfindung;
26 zeigt einen beispielhaften Prozess zum Erhalten von Internetinhalten in Übereinstimmung mit der vorliegenden Erfindung;
27 zeigt einen beispielhaften Prozess zum Abonnieren einer Website gemäß vorliegender Erfindung;
28 zeigt Beispiele von Benutzerschnittstellenbildschirmen von einem mehrschichtigen Menüsystem gemäß vorliegender Erfindung;
29 zeigt ein Beispiel einer Such-Wizard-Benutzerschnittstelle für die Google-Suche gemäß vorliegender Erfindung;
30 zeigt beispielhafte Benutzerschnittstellenbildschirme zur Ergebnisanzeige gemäß vorliegender Erfindung;
31 zeigt einen beispielhaften Prozess für eine Suche, die durch ein Icon-basiertes Menü gemäß vorliegender Erfindung betrieben wird;
32 zeigt ein Beispiel einer individuell angepassten Navigationsbenutzerschnittstelle gemäß vorliegender Erfindung;
33 zeigt ein Beispiel einer POI-Webportal-Benutzerschnittstelle gemäß vorliegender Erfindung;
34 zeigt einen beispielhaften Prozess zur Erzeugung einer angepassten Benutzerschnittstelle für ein gesponsertes Ziel gemäß vorliegender Erfindung;
35 ist eine schematische Darstellung eines Systems zur Mitteilungsübermittlung von Vorrichtung zu Vorrichtung gemäß vorliegender Erfindung;
36 zeigt ein Beispiel einer Verabredungseinladungs-Benutzerschnittstelle gemäß vorliegender Erfindung; und
37 zeigt ein Beispiel eines Verabredungseinladungs- und Annahmeprozesses gemäß vorliegender Erfindung.
Detaillierte Beschreibung der Erfindung
Wie bereits bei der Betrachtung gegenwärtiger Vorgehensweisen beim Aufbau von Navigationssystemen erörtert, können aktuelle Navigationssysteme nicht ohne weiteres dafür angepasst werden, neue Formen von Inhaltsdaten zu nutzen. Derartige Navigationssysteme, die nicht inhaltszentriert sind, können nur neue Arten von Daten nutzen, die durch einen in 7 gezeigten Adaptionsprozess verfügbar werden.
Die vorliegende Erfindung nimmt sich der gegenwärtigen Probleme an, indem sie auf eine inhaltszentrierte Gestaltung übergeht, bei der Veränderungen der Systemfunktionalität durch Veränderungen des Inhalts betrieben werden. Dies wird durch das Bereitstellen eines Frameworks zur Bereitstellung von Navigationsinhalten erzielt, das die Fähigkeit hat, sich in Navigationsvorrichtungen zu integrieren, auf Inhalt zuzugreifen, diesen zu liefern und zu integrieren sowie die Funktionalität des Basissystems zu erweitern. Inhalt kann in Form von Plug-in-Softwareobjekten geliefert werden, die die Programmfunktionalität erweitern. Plug-in-Softwareobjekte können in Basisnavigationsvorrichtungen integriert werden, die das Basis-Navigationsframework enthalten, um verschiedene "Skins" bereitzustellen, die das Basis-Navigationsframework für einen bestimmten Benutzer oder für einen bestimmten Zweck anpassen. An die Vorrichtung abgegebener zusätzlicher Inhalt kann aus vielen Quellen stammen, einschließlich externer Quellen in verbundenen Systemen. Die Bereitstellung eines derartigen Inhalts durch Plug-in-Softwareobjekte, als Plug-in-Softwareobjekte und für Plug-in-Softwareobjekte erleichtert die Lieferung von Diensten durch einen örtlich basierten Dienstanbieter oder eine Drittfirma.
Das Framework zur Bereitstellung von Navigationsinhalten erlaubt es nach seiner Implementierung, dass dieselbe Hardware und Basis-Navigationsplattform die Basis für viele unterschiedliche Arten von Navigations- und örtlich basierten Produkten bildet. Die Clienthardware und das Basis-Navigationsframework können für viele Produkte identisch sein und können unabhängig von der Funktionalität eines spezifischen Plug-in-Softwareobjekts sein. Die Entwicklung von maßgeschneiderten Produkten in Übereinstimmung mit der vorliegenden Erfindung ist wesentlich einfacher als bei früheren Navigationssystemarchitekturen, und Merkmale können hinzugefügt werden, nachdem das Basissystem aufgebaut und freigegeben wurde. Die Bereitstellung einer neuen oder angepassten Funktionalität auf diese Weise kann die Verzögerung zwischen dem Zeitpunkt, an dem Softwaremerkmale konzipiert werden, und dem Zeitpunkt, an dem sie für den Endbenutzer verfügbar sind, verringern. Die gelieferten Merkmale können so ausgerichtet werden, dass sie den Bedürfnissen bestimmter Benutzer entsprechen, wenn diese Bedürfnisse entstehen und wenn die Mittel zur Nutzbarmachung derartiger Bedürfnisse für Geschäftszwecke identifiziert werden.
Das erörterte Framework zur Bereitstellung von Navigationsinhalten kann aus Client- und Serverelementen bestehen, die in derselben physischen Vorrichtung eingebaut sein können, oder durch ein beliebiges Mittel verbunden sein können, einschließlich des Internets und per Funk. Ein Basis-Navigationsplattformelement des Systems bietet eine Basis-Navigationsfunktionalität, die durch Programmelemente erweitert werden kann, die zwischen Clients und einem Server dynamisch verteilt werden. Durch das Framework zur Bereitstellung von Navigationsinhalten können beliebige Inhaltsquellen und Dienste von Drittanbietern, einschließlich solcher, die durch Internet-Websites bereitgestellt werden, ohne weiteres integriert werden. Das Framework zur Bereitstellung von Navigationsinhalten ermöglicht gemäß definierten Mechanismen und Anwendungsprogrammschnittstellen den Aufbau von Systemen, die sich hinsichtlich Inhalt und Merkmalen unterscheidet.
In 8–37 sind eine Vielzahl von Systemkonfigurationen erörtert, die mögliche Ausführungsformen der Erfindung darstellen. Nachfolgende Abschnitte beschreiben den Aufbau, die Funktionalität und die Wechselwirkungen zwischen Systemelementen in Einzelheiten.
8 zeigt ein typisches System in Übereinstimmung mit der vorliegenden Erfindung, das mit vollständig getrennten Elementen konfiguriert ist. Der Navigationsclient 82 ist von dem Server 81 durch einen drahtgebundenen oder drahtlosen Kommunikationskanal 83 getrennt. Beispielhafte Kanäle sind seriell, USB, Ethernet, Bluetooth, 802.11 drahtlos und zellular. Der Server 81 ist in der Lage, über einen beliebigen drahtgebundenen oder drahtlosen Kommunikationskanal 84 (einschließlich der bereits unter Bezug auf 83 beschriebenen Kanäle) auf eine Vielzahl von Internet-Inhaltsanbieter 82, einschließlich Websites, Webdienste und im Internet sichtbare Live-Sensoreinrichtungen zuzugreifen. Beispiele für Anwendungen, die durch die Integration dieser Konfiguration ermöglicht werden, sind die Lieferung von Echtzeit-Verkehrsinformationen und eine lokale Suche, die von Internet-Suchmaschinen bereitgestellt wird.
9 zeigt eine vereinfachte Systemkonfiguration, die nur ein Navigationsclientelement 90 und ein Serverelement 91 enthält. Hier ist der Client 90 von dem Server 91 durch eine drahtgebundene oder drahtlose Verbindung 92 desselben Typs wie die Verbindung 83 getrennt. Der Server 91 kann mit dem Client kommunizieren, hat jedoch keine Einrichtungen zur Kommunikation mit dem Internet oder einer beliebigen externen Inhaltsquelle. Anstelle dessen wird Inhalt direkt auf dem Server gespeichert und es wird nach Bedarf durch den Client durch die Verbindung 92 auf diesen zugegriffen. Beispiele für Anwendungen, die durch Umsetzung dieser Konfiguration ermöglicht werden, sind ein erweiterter Geocodierungs(Adressnachschlag-)Dienst, der eine große Datenbank für Punkte von Interesse oder Straßen benutzt, sowie eine Schlüsselwortsuche von definiertem Inhalt, wie zum Beispiel eines proprietären Reise- oder Informationsführers.
10 veranschaulicht eine weitere Systemkonfiguration, die die vorliegende Erfindung inkorporiert, bei welcher eine Navigationsvorrichtung 100 sowohl Hardware- und Softwareelemente für den Navigationsclient 102 als auch den Server 103 enthält. Die Vorrichtung 100 ist in der Lage, über eine drahtgebundene oder drahtlose Kommunikationsverbindung 104, die bereits unter Bezug auf den Kommunikationskanal 84 beschrieben wurde, mit verschiedenen Quellen von Internet-Inhalt 101 zu kommunizieren, die bereits unter Bezug auf die Internet-Inhaltsanbieter 82 beschrieben wurden. Hier kommuniziert die Navigationsvorrichtung 100 selbst direkt mit den Inhaltsquellen 101 um live und aktuell Daten zu erhalten. Neue Funktionalität oder Veränderungen des Formats oder des Orts der Internet-Inhaltsquelle 101 müssen manuell installiert werden, typischerweise von dem Benutzer der Navigationsvorrichtung 100. Beispielhafte Anwendungen, die durch diese Systemkonfiguration ermöglicht werden, sind die Lieferung von Echtzeit-Verkehrsinformationen in einem Format wie zum Beispiel TMC und eine lokale Suche, die durch Webdienst-Schnittstellen von bestimmten Internet-Suchmaschinen bereitgestellt wird.
11 zeigt die einfachste Konfiguration eines Systems gemäß vorliegender Erfindung. In dieser Konfiguration arbeitet eine Navigationsvorrichtung 110 als unabhängige Vorrichtung, die mit keinem Netz verbunden ist, und enthält das Client- 112 und Server- 113 -Element des Systems in ähnlicher Weise wie bei dem unter Bezug auf 100 beschriebenen System. Diese Konfiguration ist jedoch insofern unterschiedlich, als die Clientvorrichtung direkt auf Inhalte zugreift. Inhalte werden in einem nicht flüchtigen permanenten oder entnehmbaren Speichermedium 111 gespeichert, das mit der oder durch die Clientvorrichtung bereitgestellt ist. Beispiele für Speichereinrichtungen sind ein Flash-Speicher, ein batteriegestütztes RAM, eine Festplatte, eine CD ROM und entnehmbare Speicherkarten, wie z. B. MMC, Compact Flash oder SD. Live-Inhalt von externen Quellen ist in dieser Konfiguration nicht verfügbar, anstelle dessen muss das Speichermedium 111 ausgetauscht oder aktualisiert werden, um neue Funktionalität oder aktuellere Daten zu erhalten. Aktualisierungen des Inhalts müssen manuell installiert werden, typischerweise durch den Benutzer der Navigationsvorrichtung 110. Eine beispielhafte Anwendung, die durch dieses System ermöglicht wird, ist ein touristisches Produkt, das die Kartenabbildung nutzt, um einen interaktiven Stadtführer für eine bestimmte Stadt oder ein bestimmtes Gebiet bereitzustellen.
Basis-Navigationsplattform
12 veranschaulicht den Aufbau einer Navigationsclientvorrichtung, die eine Basis-Navigationsplattform gemäß vorliegender Erfindung bereitstellt. Die Basis-Navigationsvorrichtung aus 12 besteht aus einer Hardwarevorrichtung 120, die die erforderliche Hardware zur Bereitstellung von Navigationsfunktionalität 121 und zum Ablauf von Basis-Navigationssoftware-Plattformsoftware 123 bereitstellt. Diese Basis-Navigationsplattform wird in Verbindung mit einem Basis-Navigationsframework genutzt, um Produkte bereitzustellen, die sich durch das Vorsehen von zusätzlicher Funktionalität unterscheiden. Die Basis-Navigationssoftwareplattform enthält eine Navigationsanwendung 124, die auf Karten- und/oder Inhaltsdaten 126 zugreift und greift typischerweise, jedoch nicht immer, auf das Vorhandensein eines Betriebssystems 122 zurück. Beispiele von Betriebssystemen, die zur Verwendung in der Basis-Navigationsplattform geeignet sind, sind Linux, Windows CE und QNX. Die Navigationsanwendungssoftware 124 bietet einem Endbenutzer Navigationsnutzung durch Bereitstellung einer Navigationsbenutzerschnittstelle, die eine Navigationsmaschine 125 nutzt, die eine Reihe von Navigationsfunktionen und -algorithmen unter Zugrundelegung der Kartendaten 126 enthält.
Die Basis-Navigationsplattformsoftware 123 stellt eine Anwendung bereit, die allgemein genutzte Basis-Navigationsfunktionalität enthält, die von der Navigationsmaschine 125 unterstützt wird. Basis-Navigationsfunktionalität enthält allgemein verwendete Navigationsfunktionalität, wie zum Beispiel Anzeige einer Karte in beliebiger Position, Ausrichtung und Maßstab, mit der Option zur Benutzeranpassung der Anzeige durch Platzierung oder Überlagerung von festgelegten Bildern, Anmerkungen oder Text auf der Karte; Funktionen, um von Menschen lesbare Zielinformationen, wie zum Beispiel Straßenadressen, Namen und Typen von Punkten von Interesse zu suchen und in Längen-/Breitenkoordinaten aufzulösen; einen Berechnungsalgorithmus für den optimalen Weg, der an den Benutzer anpassbar ist, indem Kostenkriterien und/oder Einschränkungen eingestellt werden, wie zum Beispiel der A*-Algorithmus; einen Manövererzeugungsalgorithmus, der einen optimalen Weg in eine Reihe von Manövern umwandelt, die entlang der Route durchzuführen sind, mit Benutzeranpassung der Manövererzeugungsbedingungen und -parameter; ein Fahrzeugpositionierungsmodul, das die gegenwärtige Position der Vorrichtung auf der Karte bestimmt, indem die verfügbaren Ortungs- und Bewegungsinformationen mit den Kartendaten abgestimmt werden; und einen Anweisungsabgabemechanismus, der die gegenwärtige Position mit der Manöverliste abgleicht, um Text-, Symbol- oder Audio-Aufforderungen in Echtzeit nach Erfordernis sowie in Übereinstimmung mit einer konfigurierten Sprachdatei und Anweisungsgrammatik zu erzeugen.
Definition des Frameworks zur Bereitstellung von Navigationsinhalten
13 veranschaulicht Navigationsclientsoftware 130, die Basis-Navigationsplattformsoftware 131 wie unter Bezug auf 123 beschrieben und ein Basis-Navigationsframework 132 gemäß vorliegender Erfindung enthält. Das Basis-Navigationsframework 132 ist klar von der Basis-Navigationsplattform getrennt und auf diese Weise selbst keine Navigationsanwendung; es erweitert jedoch Navigationsanwendungen, die die Basis-Navigationsfunktionalität bereitstellen. Die Basis-Navigationsplattform und andere Aspekte der Systeminfrastruktur, die später erörtert werden, bieten eine Plattform zur Nutzung für das Basis-Navigationsframework durch eine API 133, die von dem Basis-Navigationsframework definiert ist. Die Plattform-API 133 erlaubt es dem Basis-Navigationsframework, auf Basis-Navigationsfunktionen zuzugreifen, die von der Navigationsclientvorrichtung 130 bereitgestellt werden. In ähnlicher Weise kann die Basis-Navigationsplattform 131 durch eine Framework-API 134 auf das Basis-Navigationsframework 133 zugreifen, was es der Plattform erlaubt, nach Erfordernis Basis-Navigationsframework-Funktionalität aufzurufen.
Die Basis-Navigationsplattform ist typischerweise im Hinblick auf das Basis-Navigationsframework so ausgerichtet, dass sie mit dem Framework ordnungsgemäß arbeitet. Vorzugsweise enthält die Basis-Navigationsplattform-Software eine Kern-Navigationsmaschine 125, die sich im Hinblick auf das Basis-Navigationsframework nicht verändert, aber die Navigationsanwendung 124, die die Navigationsmaschine enthält, wird erweitert oder angepasst, um so die Plattform-API 133 bereitzustellen, welche das Basis-Navigationsframework erwartet, um in geeigneter Weise auf das Basis-Navigationsframework durch die Framework-API 134 zuzugreifen.
In einer bevorzugten Ausführungsform verändern sich die APIs 133 und 134 und die Implementierung des Basis-Navigationsframeworks nicht, wenn sie in Verbindung mit unterschiedlichen Basis-Navigationsplattformen verwendet werden. Die Standardisierung der Framework-API und die Erzeugung des Frameworks unter Bezugnahme auf Programmierrichtlinien stellt eine maximale Portabilität des Frameworks sicher. Das Basis-Navigationsframework wird ferner unter Verwendung geeigneter Sprachen und Technologien in der Weise implementiert, dass eine einzelne Implementierung mit verschiedenen Basis-Navigationsprodukten kompatibel ist, die hergestellt werden. Diese Maßnahmen, wenn sie in eine Basis- Navigationsframework-Implementierung integriert werden, sind dafür gestaltet, die schnellste Ausbreitung dieser Implementierung auf die größtmögliche Palette von Navigationsprodukten sicherzustellen.
Das Framework zur Bereitstellung von Navigationsinhalten besteht aus mehr als nur dem in einer Navigationsclientvorrichtung integrierten Basis-Navigationsframework. Tatsächlich ist in verschiedenen Ausführungsformen der vorliegenden Erfindung, die in 8 bis 11 gezeigt sind, die Funktionalität des Frameworks zur Bereitstellung von Navigationsinhalten zwischen Client- und Serverelementen verteilt. Einige Teile der verschiedenen Aspekte des Frameworks zur Bereitstellung von Navigationsinhalten, die in den nachfolgenden Abschnitten erörtert werden, beziehen sich nur auf den Client, einige auf den Server und einige auf beide Elemente des Systems.
Plug-in-Softwareobjekt-Framework
Ein Basis-Navigationsframework gemäß der Darstellung in 14 kann durch die Bereitstellung von Plug-in-Softwareobjekten 144 erweitert werden. Plug-in-Softwareobjekte werden von dem Plug-in-Softwareobjekt-Framework 141 verwendet, einer Komponente des Basis-Navigationsframeworks 140, um zusätzliche Funktionalität durch die Erfüllung von spezifischen Rollen in bestimmten Situationen bereitzustellen. Diese Rollen und auch die Gruppe der festgelegten Plug-in-Softwareobjekt-Typen werden für eine bestimmte Ausführungsform des Frameworks definiert. Der Bereich zusätzlicher Funktionalität, die bereitgestellt werden kann, ist potentiell sehr groß, und zwar bedingt durch die inhärente Flexibilität des Frameworks und die mögliche Variation der Plug-in-Softwareobjekt-Funktionalität. Die zusätzliche Funktionalität ist jedoch insgesamt während des Normalbetriebs des Frameworks eingeschränkt, hauptsächlich im Hinblick darauf, welche Aspekte des Frameworks den Plug-in-Softwareobjekten ausgesetzt sind und wann und wie die Plug-in-Softwareobjekte genutzt werden.
Die Plug-in-Softwareobjekte 144, die in Clientvorrichtungen genutzt werden, enthalten Code- und Datensegmente, die das Basis-Navigationsframework und die Navigationsanwendung erweitern können. Die Plug-in-Softwareobjekte werden durch eine Ausführungsmaschine 142 ausgeführt, die von dem Plug-in-Softwareobjekt-Framework 141 verwendet wird, um bestimmte Elemente der Plug-in-Softwareobjekt-Codesegmente nach Erfordernis ablaufen zu lassen. Die Ausführungsmaschine 142 ist gewöhnlich kein Teil des Basis-Navigationsframeworks 140, könnte jedoch einer sein. Anstelle dessen ist die Ausführungsmaschine entweder in die Basis-Navigationsplattform 131 integriert oder wird alternativ von einem Dritten bereitgestellt. Die Ausführungsmaschine kann eine beliebige Implementierung haben; Beispiele dafür sind Script-Maschinen, Regel-Datenbanken oder Maschinencode, der mit der Navigationsclientvorrichtung binär kompatibel ist. Vorzugsweise stimmt die Ausführungsmaschine mit einem Industriestandard zur Konstruktion von Ausführungsmaschinen überein und ist eine virtuelle Maschine, die einen Bytecode-Interpretierer oder Just-in-time-Compiler nutzt. Vorzugsweise ist zusätzlich das in den Plug-in-Softwareobjekten enthaltene Programm in einem Bytecode formatiert, der durch die virtuelle Maschine ausgeführt wird. Beispiele für derartige Schemata sind Java, .NET und P-Code.
Das Plug-in-Softwareobjekt-Framework 141 verwaltet die Akquisition, Speicherung und Anwendung von Plug-in-Softwareobjekten 144. Von dem Framework 141 verwendete Plug-in-Softwareobjekte können durch beliebige Mittel erhalten werden, die von der Navigationsclientvorrichtung 120 unterstützt werden. Beispiele sind eingebaute Plug-in-Softwareobjekte, die bereits Teil der Anwendung sind, Objekte von einer Speicherkarte, Objekte von Daten innerhalb von geographischen Kartendaten, auf die direkt von der Clientvorrichtung zugegriffen wird, oder Objekte, die durch eine beliebige drahtgebundene oder drahtlose Verbindung mit einem entfernten Server zugeführt werden. In bevorzugten Ausführungsformen, die die in 8 und 9 veranschaulichten Konfigurationen haben, werden Plug-in-Softwareobjekte von einem Server durch eine drahtlose Verbindung zugeliefert, wenn sie von dem Basis-Navigationsframework benötigt werden.
In einer Ausführungsform werden das Programm und die Daten, die in den Plug-in-Softwareobjekten 144 enthalten sind, in die Programmfunktionalität des Basis-Navigationsframeworks 140 integriert, während es noch ausgeführt wird. Das heißt, die Integration tritt nahtlos und während des normalen Betriebs der Clientvorrichtung auf, ohne dass die Clientvorrichtung einen Reset oder die Eingabe eines speziellen Programminstallationsstatus benötigt. Obgleich der Programmablauf unter dem Gesichtspunkt der Logik nahtlos weiterläuft, wird der Benutzer vorzugsweise über die Ursache einer Übertragung oder anderer latenter Vorgänge informiert, die das Ansprechverhalten und die Nutzbarkeit der Clientvorrichtung beeinflussen können, während Plug-in-Softwareobjekte übertragen und installiert werden.
In einer bevorzugten Ausführungsform ist in das Plug-in-Softwareobjekt-Framework 141 eine Einrichtung zur dauerhaften oder vorübergehenden Speicherung von Plug-in-Softwareobjekten in einem Plug-in-Softwareobjekt-Cache integriert, sobald sie erhalten wurden. Dieser Mechanismus solle die wiederholte Übertragung von identischen Plug-in-Softwareobjekten auf die Clientvorrichtung vermeiden. Eine beliebige zeitweilige oder dauerhafte Speichereinrichtung kann als ein Cache verwendet werden. Beispiele sind ein RAM oder eine Flash-Speichereinrichtung innerhalb der Clientvorrichtung, ein Festplattenlaufwerk, entnehmbare Speicherkarten, wie etwa Multimedia, Compact Flash und SD-Karten. Vorzugsweise werden die gespeicherten Objekte von dem Plug-in-Softwareobjekt-Framework 141 unter Verwendung einer Liste verwaltet, deren Priorität die am längsten zurückliegende Verwendung ist. Der Zweck der Prioritätsliste ist es, zu ermöglichen, die Plug-in-Softwareobjekte mit der am längsten zurückliegenden Verwendung zu verwerfen, um Platz für kürzlicher verwendete oder zugeführte Plug-in-Softwareobjekte zu machen, bedingt durch die endliche Natur der temporären oder dauerhaften Cache-Speichereinrichtung.
Die Ausführungsmaschine 142, die ein Teil des Plug-in-Softwareobjekt-Frameworks in einer bevorzugten Ausführungsform ist, führt das innerhalb der Plug-in-Softwareobjekte enthaltene Programm aus, erlaubt aber auch den Plug-in-Softwareobjekten den Zugriff auf Ressourcen der Frameworks 140 und 141 und somit der Ressourcen der Basis-Navigationsplattform 131. Dieser Zugriff wird durch das Vorsehen einer Framework-API 143 unterstützt, die dem innerhalb der Plug-in-Softwareobjekte enthaltenen Programmcode ausgesetzt ist. Vorzugsweise ist die den Plug-in-Softwareobjekten ausgesetzte Framework-API 143 frameworkintern, jedoch in Abhängigkeit von der Ausführungsform der Erfindung können Plug-in-Softwareobjekte zusätzlich Zugriff auf andere Unterstützungs-APIs und Funktionen haben, die für den regulären Betrieb von Plug-in-Softwareobjekten erforderlich sind, die durch die Ausführungsmaschine betrieben werden. Beispiele dieser APIs sind mathematische oder kalkulatorische Funktionen, String-Manipulationsfunktionen, Speicherverwaltungsfunktionen und andere Funktionen, die von der Basis-Navigationsplattform-API 133 definiert sind. In einer bevorzugten Ausführungsform ist die Framework-API 143 in dem Sinn sprachenunabhängig, dass eine ähnliche Funktionalität unabhängig davon unterstützt wird, welche Formen von Plug-in-Softwareobjekten verwendet werden oder in welcher Sprache sie entwickelt sind, und solang die korrekten Funktionen aufgerufen werden und die Konventionen der Weiterleitung von Funktionsargumenten befolgt werden. Die Plug-in-Softwareobjekte 144 haben ferner eine API 145, die von dem Plug-in-Softwareobjekt-Framework 141 zur Interaktion mit den Objekten verwendet werden kann. Sie wird in den nachfolgenden Abschnitten detaillierter beschrieben.
Objektlebensdauer-Framework
Plug-in-Softwareobjekte 144, die von dem Basis-Navigationsframework 140 beschafft wurden und die vorübergehend oder dauerhaft in der Clientvorrichtung 120 gespeichert werden, sind anfänglich in einem inaktiven Zustand. Das heißt, dass der in den Objekten enthaltene Code nicht ausgeführt wird, sondern darauf wartet, durch das Auftreten von bestimmten Ereignissen aktiviert zu werden, worauf er von der Ausführungsmaschine ausgeführt wird. Ereignisse werden von dem Basis-Navigationsframework 132 gewöhnlich ansprechend auf Eingangssignale erzeugt, die von der Basis-Navigationsplattform 131 empfangen werden. In einer bevorzugten Ausführungsform des Frameworks zur Bereitstellung von Navigationsinhalten wird eine vorbestimmte und festgelegte Gruppe von Ereignissen unterstützt, was die Arten der Plug-in-Softwareobjekt-Aktivierungen, die auftreten können, einschränkt.
Die Basis-Navigationsplattform 131 kann verschiedene Eingangssignale bereitstellen, die Ereignisse innerhalb des Frameworks 132 zum Aktivieren von Plug-in-Softwareobjekten erzeugen. Das Eingangssignal kann von einer Einrichtung kommen, die mit der Clientvorrichtung 120 verbunden ist oder ein Teil derselben ist, und gibt eine mit der Clientvorrichtung oder der Außenwelt in Zusammenhang stehende Eigenschaft wieder. Beispiele für Eigenschaften sind Zeit, Position, Benutzergeschwindigkeit, Temperatur, Lichtpegel, Eigenschaften eines zugehörigen Fahrzeugmotors und Wassertiefe in nautischer Umgebung. Jede Eingabe eines externen oder internen Umgebungssensors, wie zum Beispiel einer absoluten Ortungseinrichtung einschließlich GPS und/oder eines Koppelnavigationssensors kann verwendet werden, um Plug-in-Softwareobjekte zu aktivieren. Zusätzlich können Sensoreinrichtungen, die eine Eingabe direkt von dem Benutzer erfassen, wie zum Beispiel eine Tastatur oder ein Touchpad, Eingangssignale zur Aktivierung erzeugen. Das Aktivierungseingangssignal kann auch erzeugt werden, wenn eine Mitteilung durch einen drahtgebundenen oder drahtlos angeschlossenen Kommunikationskanal empfangen wird.
Die Ausführungsmaschine aktiviert Plug-in-Softwareobjekte ansprechend auf Ereignisse, die durch das Framework 132 erzeugt werden, wenn diese Objekte dem Framework ihr Interesse angezeigt haben, von bestimmten Ereignissen zu erfahren. Beispiele der Arten von Ereignissen, von welchen Plug-in-Softwareobjekte möglicherweise in Kenntnis gesetzt werden wollen, sind verschiedene Formen der Benutzer-Interaktionsaktivität, Ortsveränderungen oder der absolute Ort, Zeitübergänge, -fenster, oder verstrichene Zeit, und der Empfang von Mitteilungen. Ereignisse, die für ein Plug-in-Softwareobjekt von Interesse sind, liegen innerhalb des Ereignisumfangs des Plug-in-Softwareobjekts. Ereignisse außerhalb des Ereignisumfangs eines Plug-in-Softwareobjekts werden von dem Framework nicht an das Plug-in-Softwareobjekt weitergeleitet.
Ereignisse innerhalb des Ereignisumfangs des Plug-in-Softwareobjekts werden von dem Framework 140 an die Plug-in-Softwareobjekte 144 durch eine Ereignishandler-API weitergeleitet, die Teil einer API 145 bildet, die von dem Plug-in-Softwareobjekt zur Verfügung gestellt wird. Die API 145 wird von dem Framework zur Wechselwirkung mit den Plug-in-Softwareobjekten verwendet. Die Ereignishandler-API erlaubt es, den Ausführungsstatus von Plug-in-Softwareobjekten über drei Stufen von vollständig inaktiv bis vollständig aktiv zu steigern. In einem ersten vollständig inaktiven Zustand wird kein Code von dem Plug-in-Softwareobjekt durch die Ausführungsmaschine ausgeführt; der Ereignisumfang des Plug-in-Softwareobjekts wurde jedoch von dem Framework eingerichtet. In einem zweiten hintergrundaktiven Zustand wird ein in dem Plug-in- Softwareobjekt enthalten Hintergründ-Ereignishandler verwendet, um Ereignisse innerhalb des Ereignisumfangs zu bearbeiten. Der Ereignishandler bestimmt unter Verwendung des Programms und der Daten, die in dem Objekt gespeichert sind, ob der dritte Zustand der Objektaktivierung aufgerufen werden sollte. Vorzugsweise haben die Objekte einen eingeschränkten Zugang zu den von dem Framework zur Bereitstellung von Navigationsinhalten bereitgestellten APIs, während sie sich in dem zweiten Aktivierungszustand befinden. In einer bevorzugten Ausführungsform können von Objekten in dem zweiten Aktivierungszustand keine Framework-APIs mit Bezug auf Benutzerschnittstellen verwendet werden. In einem dritten, vollständig aktiven Zustand haben Plug-in-Softwareobjekte vollen Zugang zu Framework-APIs, was sie in die Lage versetzt, nützliche Aufgaben durchzuführen, indem sie die Ressourcen des Frameworks und somit der Basis-Navigationsplattform nutzen.
Das Framework unterstützt die Steigerung des Plug-in-Softwareobjekt-Zustands, so dass die Plug-in-Softwareobjekte ihre eigenen Aktivierungsbedingungen bestimmen können. Das Schema unterstützt Objekte, die sehr komplexe Aktivierungsbedingungen haben, die von innerhalb des Objekts enthaltenen Regeln und Daten bestimmt werden, während das Framework so einfach wie möglich gehalten wird. Beispielsweise können in einer bevorzugten Ausführungsform Plug-in-Softwareobjekte durch Veränderung der Position in Bezug auf ein definiertes eingegrenztes geographisches Gebiet oder einen Routenkorridor aktiviert werden. Beispiele für Anwendungen, die dieses Verfahren zur Aktivierung nutzen, sind Anwendungen der Einhaltung von Vorgaben durch Fahrzeuge sowie interaktive Tourführer, die an bestimmten Orten Tourismusinhalte abgeben. In einigen Ausführungsformen können Plug-in-Softwareobjekte an bestimmten Zeitpunkten oder nach dem Verstreichen einer bestimmten Zeitdauer aktiviert werden. Beispiele für Anwendungen, die diese Form der Aktivierung nutzen, sind ein Alarm zur persönlichen Erinnerung oder, in Verbindung mit der Aktivierung auf Basis der Position, eine Werbeanwendung, die Werbung während der Öffnungszeiten einer nahe gelegenen Einrichtung bereitstellt.
In dem dritten vollständig aktiven Zustand sind Plug-in-Softwareobjekte in der Lage, eine vollständige Gruppe von Framework-APIs zu nutzen. Welche APIs genau zugänglich sind, hängt von der exakten Implementierung des Frameworks ab; in bevorzugten Ausführungsformen stellen jedoch Plug-in-Softwareobjekte in diesem Zustand eine Benutzerschnittstelle bereit, die es ihnen erlaubt, direkt mit dem Benutzer der Client-Navigationsvorrichtung in Interaktion zu treten. Zusätzlich sind Plug-in-Softwareobjekte in dem dritten Zustand in der Lage, andere Ereignisse oder Objekte zu aktivieren, das Verhalten der Basis-Navigationsfunktionen, wie zum Beispiel Wegführung und Kartenanzeige, zu nutzen und zu ändern, Inhalte anzufordern und anzuzeigen, andere Ereignisse und Objekte zu aktivieren, und Mitteilungen zu senden und zu empfangen. Tatsächlich ist die Art der Aktivitäten, die von Objekten in diesem Zustand durchgeführt werden können, und verwandte Aspekte des Frameworks zur Bereitstellung von Navigationsinhalten, das diese Aktivitäten unterstützt, zum größten Teil der Gegenstand der nachfolgenden Erörterungen.
Wie früher erwähnt werden Plug-in-Softwareobjekte von der Clientvorrichtung gespeichert, bis sie gelöscht werden, da die Speicherkapazität des Plug-in-Softwareobjekt-Speichercaches der Clientvorrichtung erreicht wurde und dieser Platz für in jüngerer Vergangenheit benutzte oder erhaltene Plug-in-Softwareobjekte benötigt wird. In einer bevorzugten Ausführungsform können jedoch Plug-in-Softwareobjekte aus einer Vielzahl von anderen Gründen auch früher aus dem Plug-in-Softwareobjekt-Cache gelöscht werden, beispielsweise wenn das Objekt einem bestimmten Typ angehört und seine vorgesehene Funktion erfüllt hat, wenn das Zeitfenster zur Verwendung des Plug-in-Softwareobjekts abgelaufen ist und wenn das Objekt am Server annulliert wurde, da die Funktionalität oder die Daten, die es einschließt, zurückgezogen oder aktualisiert wurden. Ferner können in einer bevorzugten Ausführungsform Plug-in-Softwareobjekte ihre eigenen Ungültigkeitsbedingungen definieren. Vorzugsweise verwendet der Mechanismus, der dies ermöglicht, den Plug-in-Softwareobjekt-Ereignishandler, um Ereignisse von Interesse zu überwachen und Bedingungen zu bestimmen, welche dann, wenn sie eintreten, das Plug-in-Softwareobjekt veranlassen, das Framework durch eine geeignete API zu benachrichtigen, dass die Ungültigkeit eintreten sollte.
15 veranschaulicht verschiedene Punkte innerhalb der Lebensdauer eines Plug-in-Softwareobjekts, das so gestaltet ist, dass es eine einzelne Aufgabe vollendet und dann ungültig wird. Das Objekt wird durch das Basis-Navigationsframework 140 erfasst 150 und nachfolgend in dem Plug-in-Softwareobjekt-Cache der Clientvorrichtung 150 gespeichert 151. Das Framework befragt 152 das Plug-in-Softwareobjekt, indem es die in dem Plug-in-Softwareobjekt enthaltenen Informationen untersucht, um seinen Ereignisumfang zu bestimmen, wobei das Objekt in den ersten vollständig inaktiven Zustand eintritt. Das Framework bestimmt ansprechend auf Aktivierungen, die von der Basis-Navigationsplattform bereitgestellt werden, dass ein Ereignis innerhalb des Umfangs eingetreten ist 153, wobei das Framework den Ereignishandler des Plug-in-Softwareobjekts ausführt 154. Der Ereignishandler bestimmt 155 anhand des berichteten Ereignisses und interner Informationen, dass ausreichend Bedingungen für die vollständige Aktivierung erfüllt sind. Der Ereignishandler benachrichtigt 156 das Framework unter Verwendung der Framework-API 143, dass die vollständige Aktivierung des Objekts erforderlich ist. Das Framework nutzt die Objekt-Ausführungsmaschine 142, um die Vordergrundfunktion des Objektes zu aktivieren 157, wobei es in den dritten vollständig aktiven Zustand eintritt und seine gestellte Aufgabe vollendet 158. Nach Vollendung seiner gestellten Aufgabe zeigt das Objekt dem Framework an 159, dass die Ungültigkeit des Objektes fällig ist. Nach dem Empfangen der Ungültigkeitsmitteilung macht das Framework das Objekt ungültig, indem das Objekt aus dem Plug-in-Softwareobjekt-Cache gelöscht 15A wird.
Inhaltskanaldienst-Framework
In den in 8 bis 11 dargestellten Ausführungsformen des Frameworks zur Bereitstellung von Navigationsinhalten wird die Funktionalität eines Navigationsclientelements durch das Vorsehen von Plug-in-Softwareobjekten von Serverelementen erweitert, die Mittel zur Kommunikation mit Clientelementen haben. Wie 10 und 11 zeigen, können das Client- und Serverelement physisch in derselben Vorrichtung vorhanden sein, in welchem Fall die Kommunikationsmittel intern in der Vorrichtung sind. Wie in 8 und 9 gezeigt, können das Client- und das Serverelement in getrennten Vorrichtungen vorliegen, die über eine drahtgebundene oder drahtlose Verbindung verbunden sind. 3 zeigt ein früheres System, bei welchem eine drahtlose Verbindung verwendet wird und die Servervorrichtung in der Lage ist, nach Erfordernis mit mehreren Clientvorrichtungen zu kommunizieren. Ein derartiges System kann von einem örtlich basierten Dienstanbieter genutzt werden, um Clientvorrichtungen gemäß vorliegender Erfindung Plug-in-Softwareobjekte drahtlos zur Verfügung zu stellen.
Gemäß vorliegender Erfindung können die unter Bezug auf 6 beschriebenen, auf dem Server ablaufenden Softwaredienste 63 Dienste einschließen, die Plug-in-Objekte an Navigationsclients liefern. Die von dem Server gelieferten Plug-in-Objekte sind von einem Inhaltskanaldienst auf dem Server. Inhaltskanäle erweitern die Funktionalität des Systems und die Inhaltskanäle, die in dem System bereitgestellt werden, bestimmen den Umfang der Funktionalität, der für Benutzer der Navigationsclientvorrichtungen zur Verfügung steht. Inhaltskanäle sind die einzigen für den Benutzer anpassbaren Elemente, die für eine gegebene Implementierung des Frameworks zur Bereitstellung von Navigationsinhalten ein System von einem anderen unterscheiden. Inhaltskanäle sind ein entscheidender Teil des Frameworks zur Bereitstellung von Navigationsinhalten, obgleich die Implementierung der Inhaltskanäle von einem System zum nächsten variieren kann.
Ein Inhaltskanal ist eine einzelne Art von Inhalt, die von einem Endbenutzer der Navigationsclientvorrichtung "abonniert" werden kann. Beispiele sind Touristeninformationen für New York, Reiseinformationen, wie zum Beispiel Flugpläne, oder ein Restaurantführer. Inhaltskanäle werden von einem örtlich basierten Dienstanbieter bereitgestellt und in einer bevorzugten Ausführungsform der Erfindung bestimmen Endbenutzer die Art ihrer eigenen persönlichen Erfahrung mit den Clientvorrichtungen durch individuelle Auswahl von Inhaltskanälen. Vorzugsweise werden zusätzlich einige Inhaltskanäle vollständig kostenlos für Benutzer zur Verfügung gestellt, während andere ein oder mehrere Verfahren zur Erzeugung von Einkünften unterstützen, um fortgeführten Zugang zu finanzieren oder zu ermöglichen. Beinahe jedes Geschäftsmodell kann angewandt werden; Beispiele sind Abonnements, Zahlung pro Benutzung, proportionaler Verkaufsanteil, gesendete Werbung, Zahlung pro Klick oder Zahlung pro Betrachtung und zielgerichtetes Marketing.
16 veranschaulicht die Architektur eines Inhaltskanaldienstes in einer bevorzugten Ausführungsform des Frameworks zur Bereitstellung von Navigationsinhalten. Eine Inhaltszugriffsschicht 160 bietet eine Standardform der Schnittstelle zwischen Inhaltskanälen und dem Rest des Systems. Dies erlaubt es, den Inhaltskanal in dem System zu verwalten und Inhaltsobjekte für die Navigationsclientvorrichtung zu assemblieren und bereitzustellen. Durch die Inhaltszugriffsschicht empfängt der Inhaltskanal Anforderungen von Plug-in-Softwareobjekten, die von diesem Inhaltskanal stammen, die jedoch auf der Navigationsclientvorrichtung ablaufen. Ansprechend auf diese Anforderungen führt die Inhaltszugriffsschicht die erforderlichen Verarbeitungs-, Umsetzungs- und Umwandlungsoperationen durch, um den angeforderten Inhalt typischerweise in Form von Plug-in-Softwareobjekten zu assemblieren und dem Inhaltskanal zur Verfügung zu stellen.
Der Inhaltskanal stellt Inhalte für Endbenutzer bereit, indem Daten von einer Inhaltsquelle 161 genutzt werden. Die Inhaltsquelle kann in beliebiger Form vorliegen und kann auch mehrere tatsächliche Quellen kombinieren. Beispiele sind gespeicherte Daten oder Dateien, gespeicherte Daten in einer Datenbank, eine Live-Inhaltsquelle im Internet, in Echtzeit erzeugte Informationen und Live-Sensordaten, die für den Inhaltskanal verfügbar sind. In einer bevorzugten Ausführungsform enthalten gespeicherte baten und Dateien Objektschablonen, die Fragmente von ausführbarem Programmcode bereithalten, die von der Inhaltszugriffsschicht miteinander und mit Daten kombiniert werden können, um ein vollständiges Plug-in-Softwareobjekt zu bilden.
In einer bevorzugten Ausführungsform enthält der Inhaltskanal ein Abbildungs- und Navigationsmodul 162, das Kartendaten, Navigationsfunktionalität und Nutzfunktionen bereitstellt, die allgemein für den Zugriff auf oder die Verarbeitung von Kartengeometrie und Daten erforderlich sind. Die Navigations- und Nutzfunktionen werden von der Inhaltszugriffsschicht 160 der Inhaltskanäle genutzt und verändern sich sehr selten. Beispiele dafür sind geometrische Berechnungs- und Raumoperationen, Datenbankzugriffs-Grundelemente, Suchalgorithmen, Standard-Adresssuch- und Auflösungsalgorithmen und Routenberechnungsalgorithmen.
Ein Kundenverwaltungsmodul 163 verwaltet Inhaltskanalabonnements und Zugriffsrechte von einzelnen Benutzern. Es gibt keine "globalen" Passwörter oder Benutzeridentität in dem System, anstelle dessen ist jeder Inhaltskanal in dem System dafür verantwortlich, die spezifischen Benutzerinformationen, die er benötigt, beizubehalten. Beispiele für kundenspezifische Informationen sind Kontaktdetails, Einstellungen und Präferenzen, Sicherheitsinformationen und Abonnementstatus.
16 zeigt schließlich ein Transaktionsmodul 164, welches Informationen über die Benutzung des gesamten Inhaltskanaldienstes durch alle Kunden des Kanals, durch Kundengruppen oder durch Individuen sammelt. Die Informationen können beliebiger Art sein, Beispiele sind Einrichtung oder Beendigung eines Abonnements, die Nutzungszeit eines Kanals, das Alter des den Kanal benutzenden Kunden, das Volumen des gesendeten Inhalts und für den Inhaltskanal spezifische Aktivität. Vorzugsweise werden die Informationen verglichen, um Statistiken zu erzeugen, um das Nutzungsmuster des bereitgestellten Dienstes zu analysieren, und zum Zweck der Erzeugung von Einkünften. Es wird in dem System kein detaillierter Nachverfolgungsmechanismus für Transaktionen allgemein angewandt, anstelle dessen werden Transaktionsinformationen getrennt von örtlich basierten Dienstanbietern für jeden Inhaltskanal aufrechterhalten. Das Transaktionsberichtsmodul ist ein wichtiges Mittel, durch welches durch den örtlich basierten Dienstanbieter Einkünfte erzeugt werden können.
Inhaltskanal-Kommunikationsframework
In einer bevorzugten Ausführungsform ist die Kommunikation im Framework zwischen Navigationsclientvorrichtungen und Inhaltskanaldiensten als Teil des Inhaltskanal-Kommunikationsframeworks standardisiert. Dieses Framework stellt ein Mitteilungsprotokoll bereit, das die Übertragung von Plug-in-Softwareobjekten und Inhaltskanal-spezifischen Informationen unterstützt. Vorzugsweise ist das verwendete Kommunikationsprotokoll konsistent mit allgemein verwendeten Industriestandards. Beispiele sind SOAP und CORBA. Über diesen Mechanismus kann die Funktionalität der Clientvorrichtungen aktualisiert werden und Plug-in-Softwareobjekte der Clientvorrichtung können Zugriff auf Live-Informationen und aktuelle Informationen erhalten.
17 veranschaulicht die Schritte, die bei der Lieferung von Inhalt von einem Inhaltskanaldienst zu einem Navigationsclient auftreten. Plug-in-Softwareobjekte und/oder anderer Inhalt werden von dem Dienst assembliert 170, und zwar als Reaktion auf von dem Navigationsclient stammenden Anforderungen. Plug-in-Softwareobjekte und andere Inhaltselemente werden gemäß einem Kommunikationsprotokoll, das als Teil der Ausführungsform des Frameworks festgelegt ist, codiert 171. In einer bevorzugten Ausführungsform umfasst dies die Serialisierung der Elemente aus einem binären Format, wie zum Beispiel CIL, in ein Übertragungsformat, wie zum Beispiel MIME oder base 64, und die anschließende Verkapselung der Elemente unter Verwendung von XML gemäß dem SOAP-Protokoll, so dass sie später identifiziert und rückgewonnen werden können. Die codierten Daten werden über eine beliebige Einrichtung zu der Clientvorrichtung übertragen 172. Sobald sie von dem Client empfangen wurden, werden die codierten Daten decodiert 173, um die Plug-in-Softwareobjekte und/oder anderen Inhaltsdaten für das Basis-Navigationsframework der Clientvorrichtung verfügbar zu machen.
Wie vorstehend beschrieben enthält die Clientvorrichtung einen Plug-in-Softwareobjekt-Speichercache, dessen Zweck es ist, die wiederholte Übertragung von identischen Plug-in-Softwareobjekten zu vermeiden. Nur die Plug-in-Softwareobjekte, die nicht bereits in dem Client gespeichert sind, müssen durch den Inhaltskanal auf dem Server bereitgestellt werden. In einer bevorzugten Ausführungsform werden global einzigartige Identifier verwendet, um einzigartige Instanzen von Plug-in-Softwareobjekten zu identifizieren. Das Clientnavigationsframework vergleicht die global einzigartigen Identifier der benötigten Objekte mit den Identifiern aller gespeicherten Objekte, bevor Objektübertragungen von einem Inhaltskanal ausgelöst werden. Idealerweise enthält die Anforderung für Plug-in-Softwareobjekte nur die global einzigartigen Identifier von Objekten, die nicht bereits in der Clientvorrichtung gespeichert sind.
18 veranschaulicht die Abfolge von Aktionen, die in einer bevorzugten Ausführungsform der Erfindung auftreten, wenn das Basis-Navigationsframework ein Plug-in-Softwareobjekt beziehen muss. Die Clientvorrichtung durchsucht 180 den Plug-in-Softwareobjekt-Cache der Clientvorrichtung und bestimmt unter Verwendung von garantiert einzigartigen Identifiern, dass das erforderliche Objekt nicht bereits innerhalb der Clientvorrichtung vorliegt. Eine Inhaltsanforderungsmitteilung wird erzeugt 181, die den einzigartigen Identifier des fehlenden Objekts enthält. Die Inhaltsanforderungsmitteilung wird von dem Client codiert und unter Verwendung eines Prozesses ähnlich den Schritten 171 bis 173 an den Server gesendet 182, mit der Ausnahme, dass die Rollen von Client und Server vertauscht sind. Ansprechend auf die Anforderung wird von dem Server Inhalt assembliert und gemäß den Schritten 170 bis 173 zur Clientvorrichtung übertragen 183. Das Plug-in-Softwareobjekt steht zur Verwendung mit dem Basis-Navigationsframework zur Verfügung 184.
Verzeichnisdienst-Framework
19 zeigt die Beziehung zwischen Inhaltskanälen und einer Vorrichtung zur Verwendung für Ausführungsformen der Erfindung entsprechend 8 und 9. Das System ist in einen Verzeichnisserver 191, einen Inhaltskanalserver 192 und eine Navigationsclientvorrichtung 190 unterteilt, die in der Lage ist, Plug-in-Softwareobjekte auszuführen. Die Server 191 und 192 können getrennte Server sein, die eine Hardwarearchitektur gemäß der in 5 gezeigten haben. Alternativ können die Server 191 und 192 in derselben Vorrichtung untergebracht sein, welche dieselbe Vorrichtung wie der Client 190 in Systemen sein kann, die wie in 10 und 11 gezeigt konfiguriert sind. Plug-in-Softwareobjekte werden für die Navigationsclientvorrichtung 190 über eine Vielzahl von Inhaltskanälen 192 bereitgestellt, die optional Informationsquellen oder Dienste von dem Internet 193 nutzen, um einen bestimmten Typ von Inhalt bereitzustellen. Der Verzeichnisdienst wird durch einen örtlich basierten Dienstanbieter betrieben und regelt, welche Inhaltskanäle für Endbenutzer verfügbar sind. Inhaltskanäle erscheinen für den Verzeichnisdienst standardisiert, um die Verwaltung der Inhaltskanäle durch den Verzeichnisservice zu erleichtern und das bevorzugte Verfahren zur Erweiterung des Systems zu unterstützen, nämlich durch das Bereitstellen von mehr Inhaltskanälen. Der Verzeichnisdienst ist der erste Kontaktpunkt für die Kommunikation zwischen einer Clientvorrichtung und einem Inhaltskanal. Nachdem über den Verzeichnisdienst entdeckt wird, welche Inhaltskanäle zur Verfügung stehen, leitet eine Clientvorrichtung eine direkte Verbindung mit den einzelnen Inhaltskanälen nach Erfordernis ein und ansprechend auf die Aktivität des Benutzers finden die Übertragung von Plug-in-Softwareobjekten und eine für den Inhaltskanal spezifische Kommunikation statt.
20 zeigt die Elemente, die eine bevorzugte Ausführungsform der Verzeichnisdienstsoftware umfasst. Ein Kanalverwaltungsmodul 200 bietet einen Mechanismus, der es einem oder einer Vielzahl von Kanälen erlaubt, sich bei dem Verzeichnisdienst "anzumelden". Die gesamte Funktionalität des Systems zu jedem gegebenen Zeitpunkt ist davon abhängig, welche Kanäle angemeldet sind. Ein in dem Verzeichnisdienst enthaltenes Clientmodul 201 erlaubt es Clientvorrichtungen, zu erfassen, welche Inhaltskanäle verfügbar sind. Kanaldetails für jeden Kanal, wie zum Beispiel ein Name und eine Beschreibung, sind in einer Kanalinformationsdatenbank 202 gespeichert und werden von einem Clientverwaltungsmodul zu der Clientvorrichtung zur Anzeige für den Endbenutzer gesendet. Informationen über jede Vorrichtung, die das System benutzen kann, sind in einer Vorrichtungsinformationsdatenbank 203 gespeichert. Die Verwendung der Datenbanken 202 und 203 wird hier und ebenso in nachfolgenden Abschnitten beschrieben.
Inhaltskanäle können von jedem örtlich basierten Dienstanbieter bereitgestellt werden und können von einem anderen Anbieter als dem Anbieter des Verzeichnisdienstes kommen. Um von dem Verzeichnisdienst aufgeführt zu werden, müssen Inhaltskanäle in dem Verzeichnisdienst angemeldet werden und Kontakt halten, während sie aktiv bleiben. Inhaltskanäle können sich abmelden, wenn der Inhaltskanaldienst zur Wartung oder aus anderen Gründen heruntergefahren wird. Auf diese Weise hat der Verzeichnisdienst konstant Kenntnis darüber, welche Kanäle aktiv sind und welche inaktiv sind. Wenn der Verzeichnisdienst nicht aktiv ist, ist es möglich, dass Inhaltskanäle weiterhin normal für diejenigen Kunden funktionieren, die den Inhaltskanal bereits abonniert haben. 21 zeigt einen typischen Zyklus der Anmeldung, der fortgeführten Funktion und der Abmeldung eines Inhaltskanals. In Schritt 210 sendet der Inhaltskanal eine Anmeldungsanforderung an das Kanalverwaltungsmodul des Verzeichnisdiensts. Der Verzeichnisdienst fügt den Kanal zu der Liste von aktiven Kanälen hinzu und antwortete 211 mit einer Angemeldet-Mitteilung. Der Inhaltskanal hält seinen Status aufrecht, indem er eine "ich bin funktionsbereit"-Mitteilung an den Verzeichnisdienst sendet 212. Der Verzeichnisdienst antwortet 213 mit einer Bestätigung. In Schritt 214 werden die Schritte 212 und 213 periodisch wiederholt, während der Inhaltskanal bei dem Verzeichnisdienst angemeldet bleiben will. Wenn der Inhaltskanal sich von dem Verzeichnisdienst abmelden möchte, sendet er 215 eine Abmeldungsanforderungsmitteilung an den Verzeichnisdienst. Der Inhaltskanal wird aus der Kanalliste des Verzeichnisdienstes entfernt und der Verzeichnisdienst sendet 216 eine Bestätigungsmitteilung an den Inhaltskanal. Der Inhaltskanal wird anschließend deaktiviert 217.
22 zeigt den Prozess, in dem ein Benutzer einen Inhaltskanal über eine Clientvorrichtung abonniert. In einem ersten Schritt können Details von verfügbaren Inhaltskanälen, die durch den Verzeichnisdienst gespeichert sind, von einer Clientvorrichtung angefordert werden 220. In einem zweiten Schritt 221 sendet der Verzeichnisdienst eine Liste von angemeldeten Kanälen an die Clientvorrichtung. Die Liste der Kanäle wird in Schritt 222 in der Clientvorrichtung angezeigt und der Benutzer hat die Möglichkeit, einen Kanal auszuwählen. Wenn der Benutzer einen Kanal auswählt, hat der Verzeichnisdienst seine Aufgabe erfüllt und der Client leitet die Kommunikation direkt mit dem entsprechenden Inhaltskanaldienst ein. In Schritt 223 sendet die Clientvorrichtung eine Abonnementanforderung 224 für den Inhaltskanal. Erforderlichenfalls sendet in Schritt 225 der Inhaltskanal ein Authentifizierungsobjekt zurück an die Clientvorrichtung, um Benutzerdetails zum Zweck des Abonnements zu erhalten. Der Eintrag von Details kann von der Clientvorrichtung in Schritt 226 automatisch unter Verwendung von Details durchgeführt werden, wenn diese in der Clientvorrichtung gespeichert sind. Andernfalls, wenn der Benutzer sich entschlossen hat, keine Details zu speichern, müssen sie möglicherweise vom Benutzer jedes Mal eingegeben werden, wenn die Details erforderlich sind. Die erforderlichen Details werden in Schritt 227 zurück an den Inhaltskanal gesendet, wo sie von dem Kundenverwaltungsmodul gespeichert werden. Eine Mitteilung eines erfolgreichen Abonnements eines Inhaltskanals wird von dem Inhaltskanal in Schritt 228 an die Clientvorrichtung gesendet. Das Kanalabonnement wird in der Clientvorrichtung zur zukünftigen Verwendung bei der Kommunikation mit dem Inhaltskanal gespeichert 229. Die Kanalabonnementinformation kann beliebige für einen Benutzer spezifische Informationen enthalten, die der Inhaltskanaldienst für wichtig erachtet.
Sicherheitsframework
Da das System verbunden ist, ist ein Sicherheitsframework erforderlich, um die Kommunikation zwischen den Elementen des Systems zu sichern und die Identität jedes Elements zu authentifizieren. Die gesamte Kommunikation in dem System wird unter Verwendung eines Verschlüsselungssystems mit öffentlichem/privatem Schlüssel, wie etwa RSA, verschlüsselt. Ferner wird der sichere Inhalt unter Verwendung von digitalen Zertifikaten als von einer vertrauenswürdigen Quelle stammend signiert. Schließlich kontrolliert ein digitales Rechteverwaltungssystem die Teilnahme von einzelnen Clientvorrichtungen und Inhaltskanaldiensten in dem System. Die Einzelheiten der Gestaltung und Implementierung dieser Technologien sind nach dem Stand der Technik bekannt.
23 veranschaulicht Elemente, die innerhalb des Sicherheitsframeworks wichtig sind. Die Rolle und die Beziehungen zwischen verschiedenen Elementen werden nachfolgend unter Bezug auf 23 erörtert. In dem System wird die Kommunikation über einen Kommunikationskanal 233 zwischen Klienten 230 und einem Verzeichnisdienst 231 und über einen Kommunikationskanal 234 zwischen Klienten 230 und Inhaltskanaldiensten 233 gesichert. Die Kommunikation wird ferner über einen Kommunikationskanal 235 zwischen Inhaltskanaldiensten 233 und einem Verzeichnisdienst 231 gesichert.
Die Kommunikation über die Kanäle 233, 234 und 235 wird unter Verwendung einer Verschlüsselung mit öffentlichem/privatem Schlüssel verschlüsselt. Clients haben ein öffentliches/privates Schlüsselpaar 236/237, das im Client erzeugt wird. Inhaltskanäle haben ein öffentliches/privates Schlüsselpaar 23D/23E, das im Inhaltskanal erzeugt wird. Der Verzeichnisdienst hat ein öffentliches/privates Schlüsselpaar 23A/23B, das im Verzeichnisdienst erzeugt wird. Teilnehmer, die verschlüsselte Mitteilungen von anderen Teilnehmern empfangen möchten, übertragen ihren öffentlichen Schlüssel an den anderen Teilnehmer. Der andere Teilnehmer verschlüsselt die Mitteilung, die er an den ursprünglichen Teilnehmer senden möchte, unter Verwendung des öffentlichen Schlüssels, und der ursprüngliche Teilnehmer entschlüsselt die Mitteilung unter Verwendung eines geheimen privaten Schlüssels 237, 23B und 23E, den nur der ursprüngliche Teilnehmer kennt.
Die Identität eines Mitteilungen sendenden Teilnehmers kann durch digitale Signaturen und digitale Zertifikate 238 und 23F festgestellt werden. Ein Teilnehmer, der Mitteilungen an einen anderen Teilnehmer sendet, kann die Mitteilung unter Verwendung einer digitalen Signatur signieren. Die Signatur wird von dem sendenden Teilnehmer erzeugt, indem ein Mitteilungsdigest von der gesendeten Mitteilung erzeugt wird und das Mitteilungsdigest unter Verwendung des nur dem Sender bekannten privaten Schlüssels verschlüsselt wird. Das Mitteilungsdigest wird unter Verwendung eines bekannten Algorithmus, wie zum Beispiel MD5, berechnet. Der Empfänger benutzt den bekannten öffentlichen Schlüssel des Senders, um das Mitteilungsdigest zu entschlüsseln, und berechnet aus der Mitteilung sein eigenes Mitteilungsdigest, das mit der entschlüsselten digitalen Signatur verglichen wird. Wenn die beiden übereinstimmen, dann wurde die Mitteilung von dem Inhaber des bekannten öffentlichen Schlüssels gesendet. Um zu verifizieren, dass der öffentliche Schlüssel von einer vertrauenswürdigen Quelle ausgegeben wurde, anstatt von einer zwischengeschalteten Stelle, die alle Mitteilungen abfängt und sendet, kann ein von einer vertrauenswürdigen Quelle ausgegebenes digitales Zertifikat verwendet werden. Das digitale Zertifikat wird von einer Zertifikatstelle ausgegeben, die sowohl dem Sender als auch dem Empfänger bekannt ist. Das digitale Zertifikat wird an einen Sender ausgegeben, indem der öffentliche Schlüssel des Senders und eine bestimmte Information, die für den Sender einzigartig ist, unter Verwendung des privaten Schlüssels der Zertifikatstelle verschlüsselt werden. Die Mitteilung kann unter Verwendung des öffentlichen Schlüssels der Zertifikatstelle entschlüsselt werden. Nun kann jedes Mal, wenn ein Sender eine Mitteilung an einen Empfänger sendet, das den öffentlichen Schlüssel des Senders enthaltende digitale Zertifikat eingeschlossen werden. Das Zertifikat kann von dem empfangenden Teilnehmer unter Verwendung des bekannten öffentlichen Schlüssels der Zertifikatstelle entschlüsselt werden. Der öffentliche Schlüssel des Senders, der in dem Zertifikat enthalten ist, kann mit dem vom Sender berichteten öffentlichen Schlüssel verglichen werden. Wenn die beiden übereinstimmen, dann entspricht die Identität des Senders der angegebenen.
In dem Fall des in 23 gezeigten Systems ist die Zertifikatstelle der Verzeichnisdienst. Der Grund dafür ist, dass der Verzeichnisdienst die Zugriffsrechte sowohl von Individuen als auch Diensten auf das System kontrolliert. Er ist der Zugangsweg für alle Vorrichtungen zu allen Inhaltskanaldiensten. Ein digitales Zertifikat, das den Zugriff auf das System ermöglicht, muss einmal für jede Clientvorrichtung und für jeden Inhaltskanal erhalten werden, die Teil des Systems sein möchten. Die Ausgabe der Zertifikate wird durch den Verzeichnisdienst unter Verwendung eines Systems von "Registrierungs-"Schlüsseln 239 und 23H und eine Registrierungsdatenbank 23C auf dem Server kontrolliert. Die Registrierungsdatenbank 23C enthält alle Registrierungsschlüssel, die in dem System gültig sind, zusammen mit Details, ob der Schlüssel bereits zum Erhalten eines Zertifikats verwendet worden ist. Für einen bestimmten Inhaltskanal und eine Vorrichtung wird nur ein Zertifikat ausgegeben, anschließend wird dieses Zertifikat für die gesamte Kommunikation innerhalb des Systems verwendet. Registrierungsschlüssel werden von dem Verzeichnisdienst zusammen mit Kopien der Clientvorrichtungssoftware ausgegeben, oder wenn ein neuer Inhaltskanalvertrag zwischen dem Verzeichnisdienstanbieter und einem Inhaltskanalanbieter abgeschlossen wird. Eine Clientvorrichtung oder ein Inhaltskanal, die sich registrieren wollen, müssen einzigartige Informationen an den Verzeichnisdienst senden, einschließlich des Registrierungsschlüssels, sowie auf die einzigartige Identität der registrierenden Vorrichtung bezogene Informationen, so dass der Registrierungsschlüssel als benutzt markiert werden kann, wenn ein Zertifikat ausgegeben wurde.
Damit Clientvorrichtungen überhaupt in dem System benutzt werden können, müssen sie zunächst bei dem Verzeichnisdienst registriert werden. Der Verzeichnisdienst muss nicht wissen, wer die Kunden sind, nur dass die Clientvorrichtungssoftware gültig ist. Tatsächlich ist die Kundendatenbank eigentlich eine Vorrichtungsdatenbank, die der Verzeichnisdienst an Inhaltskanalanbieter weiterverkaufen kann, indem er diesen Inhaltskanälen den Zugriff auf das System erlaubt. Damit dieses Schema funktioniert, müssen die Vorrichtungen einzigartige Seriennummern enthalten, um eine Vorrichtung von einer anderen zu unterscheiden. Beispiele sind die Seriennummer einer Speichereinrichtung, eine interne Seriennummer oder eine IMEA-Nummer. Die Vorrichtungsseriennummer ist in der einzigartigen Information enthalten, die von der Clientvorrichtung an den Verzeichnisdienst gesendet wird und die dieser verwendet, um ein digitales Zertifikat auszugeben. Die Registrierungsdatenbank 23B enthält sowohl den Registrierungsschlüssel als auch die einzigartige Seriennummer der Clientvorrichtung, sobald ein Zertifikat ausgegeben wurde.
Clientvorrichtungen können auf den Verzeichnisdienst anfänglich nur für Registrierungszwecke zugreifen. Sobald eine Vorrichtung registriert wurde und ein Zertifikat ausgegeben wurde, kann es die durch den Verzeichnisdienst erhältlichen Inhaltskanäle überprüfen und kann direkt mit Inhaltskanälen kommunizieren. Inhaltskanäle müssen sich ebenfalls bei dem Verzeichnisdienst registrieren, bevor sie durch den Verzeichnisdienst zur Verfügung stehen. An Inhaltskanäle werden Zertifikate durch einen ähnlichen Registrierungsprozess wie für Clientvorrichtungen ausgegeben. Der Inhaltskanal verwendet sein Zertifikat bei allen zukünftigen Kommunikationsvorgängen mit dem Verzeichnisdienst und mit Clientvorrichtungen.
Clientvorrichtungen können in einigen Situationen vorab registriert werden. Wenn die Clientvorrichtungssoftware für die Bereitstellung von Navigation und Inhalt vom Hersteller vorab installiert ist, kann die Vorrichtung durch den Hersteller vorab registriert werden. Derselbe oder ein ähnlicher Mechanismus wie der soeben beschriebene wird verwendet, aber anstelle des Kunden kümmert sich der Hersteller um den Registrierungsprozess.
Die soeben beschriebenen Sicherheitseinrichtungen sind wichtig, da das Abonnement von Inhaltskanälen durch den Benutzer des Systems auf einer individuellen Basis erfolgt. Die Kenntnis, dass die Vorrichtung eine gültige Vorrichtung in dem System ist, ist für Verzeichnisdienstanbieter wichtig, da dies das Mittel zum Weiterverkaufen von Kunden ist. Die Kenntnis über die Identität des Kunden ist für Inhaltskanäle wichtig, da der Kunde möglicherweise für den Zugriff auf den Inhalt, den der Inhaltskanal bereitstellt, bezahlen muss. Eine bei dem Verzeichnisdienst registrierte Vorrichtung kann ihr Verzeichnisdienstzertifikat verwenden, um dem Verzeichnisdienst bekannte Inhaltskanäle zu abonnieren. Der Inhaltskanal verifiziert, dass die Clientvorrichtung mit dem System verbunden werden kann, da die Clientvorrichtung ein Zertifikat von dem Verzeichnisdienst übergibt. In ähnlicher Weise verifiziert die Clientvorrichtung, dass der Inhaltskanal gültig ist, da der Inhaltskanal ein Zertifikat von dem Verzeichnisdienst übergibt.
Wenn der Benutzer einen Inhaltskanal abonniert, führt der Inhaltskanal Informationen an die Clientvorrichtung zurück, die den zukünftigen Zugriff der Clientvorrichtung auf den Inhaltskanal erlaubten. Die zurückgeführte Information ist ein "sicheres Cookie" 23J, das für die Clientvorrichtung spezifisch ist. Sichere Cookies sind zu den gewöhnlichen Cookies analog, die von vielen Websites verwendet werden, um sich an benutzerspezifische Informationen zu erinnern, aber das Cookie wird durch den Inhaltskanal unter Verwendung eines geheimen Schlüssels verschlüsselt, der nur dem Inhaltskanal bekannt ist. Das sichere Cookie wird von der Clientvorrichtung jedes Mal dann an den Inhaltskanal weitergegeben, wenn sie mit dem Inhaltskanal kommuniziert. Das Cookie enthält Informationen, die der Inhaltskanal in der Clientvorrichtung speichern möchte, einschließlich Informationen über die Clientvorrichtung oder den Benutzer. Der Inhaltskanal kann das sichere Cookie jederzeit aktualisieren, wenn die gespeicherten Informationen geändert werden müssen. Sobald das sichere Cookie in der Clientvorrichtung gespeichert ist, gibt es dem Benutzer der Clientvorrichtung Zugriffsrechte auf den von einem bestimmten Inhaltskanal bereitgestellten Inhalt. Tatsächlich kann die Clientvorrichtung auf diese Weise alle Zugriffsrechte auf Inhaltskanäle in dem System auf einer Schlüsselkette in der Clientvorrichtung in einer der Clientvorrichtung unbekannten verschlüsselten Form speichern. Das Cookie wird unter Verwendung eines geheimen Schlüssels 23H, der nur dem Inhaltskanal bekannt ist, verschlüsselt, typischerweise unter Verwendung eines allgemein bekannten blocksymmetrischen Schlüssels, wie zum Beispiel RC5 oder 3DES. Alle abonnierten Kanäle und die Zugriffsrechte auf diese Kanäle sind lokal in der Clientvorrichtung gespeichert, da jedes sichere Cookie nur mit einem bekannten Inhaltskanal verbunden werden muss, damit dieser genutzt werden kann.
Da das Basis-Navigationsframework in der Lage ist, Plug-in-Softwareobjekte ablaufen zu lassen, die mit der Clientvorrichtung oder dem Benutzer in Interaktion treten, einschließlich Plug-in-Softwareobjekten, die den Benutzer nach persönlichen Informationen fragen, werden nur Inhaltsobjekte von einer vertrauenswürdigen Quelle von dem Basis-Navigationsframework akzeptiert. Um dieses Schema zu implementieren, werden von einem Inhaltskanal gesendete Plug-in-Softwareobjekte unter Verwendung eines Zertifikats signiert, das von dem Verzeichnisdienst an den Inhaltskanal ausgegeben wurde. Dies verhindert, dass Plug-in-Softwareobjekte, die nicht von einem durch den Verzeichnisdienst autorisierten Inhaltskanal stammen, ablaufen.
24 zeigt einen beispielhaften Prozess zum sicheren Abonnieren eines Inhaltskanals durch eine Clientvorrichtung. Anfangs in Schritt 240 wird angenommen, dass die Clientvorrichtung bei dem Verzeichnisdienst registriert ist, um ein Zertifikat von dem Verzeichnisdienst zu erhalten. Der Benutzer hat dann Zugriff auf den Verzeichnisdienst und wählt in Schritt 241 die Auflistung der verfügbaren Inhaltskanäle. In Schritt 242 wählt der Benutzer durch die Benutzerschnittstelle der Clientvorrichtung einen bestimmten Inhaltskanal zum Abonnieren. Die Clientvorrichtung erzeugt eine Mitteilung, die Informationen über die Vorrichtung und den öffentlichen Schlüssel enthält. Die Mitteilung wird unter Verwendung des privaten Schlüssels des Clients signiert und in Schritt 243 zusammen mit dem von dem Verzeichnisdienst ausgegebenen Zertifikat an den Inhaltskanal gesendet. Der Inhaltskanaldienst verifiziert in Schritt 344 die Clientvorrichtung durch Entschlüsseln der Mitteilungssignatur unter Verwendung des öffentlichen Schlüssels des Clients und durch Entschlüsseln des Zertifikats unter Verwendung des öffentlichen Schlüssels des vertrauenswürdigen Verzeichnisdienstes. Der Inhaltskanal, der den Sender authentifiziert hat, kann nun verschlüsselte Mitteilungen an die Clientvorrichtung unter Verwendung des öffentlichen Schlüssels der Clientvorrichtung senden. In Schritt 245 sendet der Inhaltskanaldienst seine einzigartige Information in einer Mitteilung, die unter Verwendung des privaten Schlüssels des Inhaltskanals zusammen mit dem an diesen von dem Verzeichnisdienst ausgegebenen Zertifikat signiert ist. In Schritt 246 kann die Clientvorrichtung die Mitteilung von dem Inhaltskanal unter Verwendung ihres privaten Schlüssels entschlüsseln und kann in Schritt 247 den Inhaltskanal unter Verwendung der signierten Mitteilung und des Zertifikats von dem Verzeichnisdienst authentifizieren. Die Clientvorrichtung kann nun verschlüsselte Mitteilungen an den Inhaltskanal unter Verwendung des öffentlichen Schlüssels des Inhaltskanals senden. In Schritt 248 tauscht die Clientvorrichtung verschlüsselte Informationen nach Erfordernis aus, und zwar gemäß den Schritten 224 bis 227, die unter Bezug auf 22 beschrieben wurden. Von dem Inhaltskanal benötigte Informationen für die Abonnierung schließen typischerweise den einzigartigen Vorrichtungs-Identifier ein. Der Inhaltskanal empfängt die Information und erzeugt ein sicheres Cookie unter Verwendung der einzigartigen Clientinformation, einschließlich des Vorrichtungs-Identifiers, und schließt das Cookie in die Antwort 249 an die Clientvorrichtung ein. Die Antwort wird in Übereinstimmung mit Schritt 228 erzeugt, der unter Bezug auf 22 beschrieben wurde. Die Clientvorrichtung aktualisiert ihre Abonnementdatenbank und speichert 24A das sichere Cookie in ihrer Schlüsselkette der zur Verwendung bei der gesamten zukünftigen Kommunikation mit dem Inhaltskanal.
Benutzerinteraktions-Framework
25 zeigt ein Diagramm einer Navigationsclientvorrichtung 250, die einen Bildschirm und eine Tastatur 251, die zur Bereitstellung einer Benutzerschnittstelle für Endbenutzer dienen, Basis-Navigationsplattform-Software 252 und ein Basis-Navigationsframework 253 enthält. Das Framework 253 nutzt Plug-in-Softwareobjekte 255, die von der Objektausführungsmaschine ausgeführt werden, in Verbindung mit einem Benutzerinteraktions-Framework 256, das für die Plug-in-Softwareobjekte verfügbar ist. Plug-in-Softwareobjekte nutzen das Benutzerinteraktions-Framework 256, während sie vollständig aktiv sind, um Informationen darzustellen und Eingaben von einem Benutzer der Clientvorrichtung 250 zu erhalten. Das Benutzerinteraktions-Framework wird durch die Implementierung der Benutzerinteraktions-Plattformsoftware 254 unterstützt, die Teil der Basis-Navigationsplattform 252 der Clientvorrichtung ist.
Das Benutzerinteraktions-Framework 156 ist der einzige Mechanismus, durch den Plug-in-Softwareobjekte in der Lage sind, Informationen für den Benutzer darzustellen. Das Framework bietet eine Reihe von APIs 259, die von Plug-in-Softwareobjekten 255 verwendet werden, um Informationen und Inhalt anzuzeigen. Beispiele für Grundelemente sind eine Arbeitsfläche, Linien, Kreise, Vielecke, Text und Bitmap-Bilder. In einer bevorzugten Ausführungsform sind die Grundelemente als standardisierte Grafik-API implementiert, welche meist direkt zu der Plattformschicht durchgeleitet werden, wo sie in plattformspezifische Funktionsaufrufe für die Plattform-API 25A umgewandelt werden. Ferner sind vorzugsweise die Grafik-API des Frameworks und der Plattformschicht übereinstimmend mit, jedoch gewöhnlich eine Untergruppe einer Industriestandard-Grafik-API. Die Plattformschicht muss möglicherweise diese API implementieren, wenn eine derartige übereinstimmende Implementierung für die Clientvorrichtung nicht bereits verfügbar ist. Beispiele für APIs sind Java AWT, open GL und Windows GDI. Vorzugsweise werden Standard-Grafikbildformate von der Grafik-API unterstützt; Beispiele sind .GIF, PNG, Jpeg und Windows BMP.
Zusätzlich zu der Grafik-API, die für die grundsätzliche Bildaufbereitung verwendet wird, stellt das Benutzerinteraktions-Framework eine festgelegte Gruppe von Informationsanzeigen höherer Ebene und Benutzerinteraktions-Widgets bereit. Beispiele dafür sind die Anzeige einer Textliste, Anzeige und Auswahl eines oder einer Anzahl von Elementen aus einer Liste, Anzeige einer Mitteilung und Erhalten einer Entscheidung, Erhalten von Texteingabe. In einer bevorzugten Ausführungsform erscheinen diese Widgets hinsichtlich ihrer API für die Plug-in-Softwareobjekte standardisiert, sie werden jedoch gemäß den plattformspezifischen Konventionen der Basis-Navigationsplattform implementiert. Dies erlaubt es, dass die Implementierung der Plug-in-Softwareobjekte über unterschiedliche Navigationsclientvorrichtungen gleichförmig ist, das Aussehen und die Bedienung der Benutzerschnittstelle jedoch mit jeder verschiedenen Basis-Navigationsplattform konsistent bleiben. Ferner erlaubt es, die Basis-Navigationsplattform-Software für eine bestimmte Umgebung zu optimieren. Beispielsweise kann die Basis-Navigationsplattform Spracherkennung implementieren, um bestimmte Formen der Eingabe zu erhalten, oder Text/Sprache-Umwandlung für die Ausgabe.
Framework zur Lieferung von Internetinhalt
8 und 10 zeigen Ausführungsformen der vorliegenden Erfindung, die einen Server in Kommunikation mit einem Client und dem Internet enthalten. Der Client ist in der Lage, von dem Server Inhalt von einem Inhaltskanal anzufordern, und der Inhaltskanal enthält Mittel zur Anforderung des Inhalts von Quellen, die mit dem Internet verbunden sind, und zwar auf der Grundlage der Anforderung von dem Client. Der angeforderte Inhalt wird von dem Inhaltskanal empfangen und wird in ein Plug-in-Softwareobjekt umgewandelt und an den Client gesendet, um die Funktionalität des Clients zu erweitern. Die Internet-Inhaltsquelle kann eine beliebige Quelle sein. In einer bevorzugten Ausführungsform ist die Inhaltsquelle eine Suchmaschine und der angeforderte Inhalt ist eine Webseite mit Suchergebnissen. Somit kann in dieser Ausführungsform das vorstehend beschriebene Framework zur Bereitstellung von Navigationsinhalten auf Internet-Suchdienste zugreifen, beispielsweise Google Local, Windows Live Local, MSN City Search und Zagat.
Die von dem Client an den Inhaltskanal gesendete Inhaltsanforderung enthält verschiedene Lageinformationen zusätzlich zu den bereits den Schritt 181 in 18 beschriebenen Informationen. Vorzugsweise enthält die Inhaltsanforderung Lageinformationen, die die Clientvorrichtung und/oder die früheren, gegenwärtigen und zukünftigen Aktivitäten des Benutzers betreffen. Beispiele für Lageinformationen sind die Position der Clientvorrichtung, bestimmt durch ein Positionsbestimmungssystem, das gegenwärtige Reiseziel oder der Reiseplan, die Reisegeschwindigkeit, die Tageszeit und/oder das Datum. Vorzugsweise wird der Inhalt von dem Inhaltskanal oder einer Internet-Inhaltsquelle, die von dem Inhaltskanal verwendet wird, in Abhängigkeit von der Lageinformation maßgeschneidert. In Übereinstimmung mit dem unter Bezug auf 18 beschriebenen Schritt 181 enthält die Inhaltsanforderung vorzugsweise persönliche Präferenzen des Benutzers und der Inhalt wird auch in Übereinstimmung mit den persönlichen Präferenzen maßgeschneidert. Beispiele für persönliche Präferenzen sind, dass keine Bilder gesendet werden sollen, dass nur zusammengefasste Ergebnisse gesendet werden sollen und dass der Standard-Radius des Suchgebiets 0,5 Meilen beträgt.
Inhaltskanäle arbeiten so, dass sie den angeforderten Inhalt, wie zum Beispiel Webseiten, über das Internet herunterladen und den Inhalt in aktive Objekte zur Übertragung zu den Navigationsclientvorrichtungen umformatieren. Der Inhaltskanal implementiert ein Proxy, das in die Inhaltszugriffsschicht 170 des Inhaltskanals integriert wird. In einer bevorzugten Ausführungsform, die Webseiten als die Quelle des Internetinhalts nutzt, fordert das Proxy automatisch die Webseite an, pflegt die Komponenten der Seite nach Erfordernis ein, um eine Informationsanforderung auszugeben, und untergliedert eine resultierende Webseite, um den angeforderten Inhalt zu extrahieren. Das Inhaltskanal-Proxy auf dem Server führt einen Großteil der Arbeit bei der Handhabung von Inhaltsanforderungen durch, die von der Clientvorrichtung erfolgen.
Inhaltsanforderungen, einschließlich derjenigen nach Plug-in-Softwareobjekten und Internetinhalt, können von Plug-in-Softwareobjekten erzeugt werden, die der Clientvorrichtung früher bereitgestellt wurden, wenn sie durch die Clientvorrichtung ausgeführt werden. Das anfordernde Plug-in-Softwareobjekt kann die Inhaltsanforderung nach Erfordernis an den Benutzer anpassen, indem automatisch die erforderlichen Details am Server bereitgestellt werden. Beispiele dafür sind Benutzerdetails, die für das Login und das Abonnieren einer Website erforderlich sind. Dies stellt sicher, dass der Aufwand des Benutzers minimiert wird und dass die Vertraulichkeit der persönlichen Details aufrechterhalten bleibt. Vorzugsweise kann das anfordernde Plug-in bei der Ausführung auch eine Benutzerschnittstelle erzeugen, um die Benutzeranpassung der Inhaltsanforderung zu unterstützen. Dies kann von Inhaltsquellen, wie zum Beispiel Internet-Inhaltsquellen, gefordert werden, wenn Datenfelder nicht automatisch vorhergesagt werden können, sondern als Teil der Inhaltsanforderung benötigt werden.
Während Schritt 181 in 18 erzeugt eine Clientvorrichtung eine Inhaltsanforderung, die Informationen enthält, die wie bereits erörtert auch Lageinformationen enthalten können. Zusätzlich enthalten diese Informationen in einer bevorzugten Ausführungsform den globalen einzigartigen Identifier des Plug-in-Softwareobjekts, das die Inhaltsanforderung erzeugt. Der globale einzigartige Identifier erlaubt es dem Server, wenn er gesendet wird, die Identität und die Aktualität von Plug-in-Softwareobjekten zu bestimmen, die Inhaltsanforderungen erteilen. Eine von dem Client an den Server von einem veralteten Plug-in-Softwareobjekt erteilte Anforderung kann von dem Server verweigert oder ignoriert werden oder von dem Server anderweitig verarbeitet werden, wenn die Anforderung immer noch verstanden wird. Ein Plug-in-Softwareobjekt kann aus verschiedensten Gründen veraltet sein. Ein Beispiel dafür ist, dass die Funktionalität, die das Plug-in-Softwareobjekt unterstützt, aktualisiert oder zurückgezogen wurde. In diesem Fall kann es möglich sein, dass der Server das Plug-in-Softwareobjekt automatisch am Client aktualisiert, indem eine aktualisierte Version des Plug-in-Softwareobjekts an den Client gesendet wird. Die Kenntnis des Ursprungs der Inhaltsanforderung kann aus anderen Gründen nützlich sein. Ein Beispiel dafür ist, dass es in zielgerichteten Marketinganwendungen möglich ist, dadurch Einkünfte zu erzeugen, dass bestimmt wird, ob eine Inhaltsanforderung das Resultat des Sendens eines eine bestimmte Werbung enthaltenden Plug-in ist.
Die vorliegende Erfindung schafft ein Benutzerinteraktions-Framework 256, das ein Verfahren zur Anzeige von Inhalt von einer Inhaltsquelle auf einer eine Anzeige enthaltenden Clientvorrichtung aufweist. In einer bevorzugten Ausführungsform stellt ein Server als Plug-in-Softwareobjekte formatierten Internetinhalt für eine Clientvorrichtung bereit. Vorzugsweise erzeugen die zugelieferten Plug-in-Softwareobjekte bei der Ausführung eine Informationsanzeige, die von dem empfangenen Internetinhalt abhängig ist. Die angezeigte Information kann eine beliebige Information sein, die durch das Benutzerinteraktions-Framework angezeigt werden kann. Beispiele für Informationsanzeigen sind eine Ergebnisliste, Details über ein bestimmtes Ergebnis und ein Bild. Vorzugsweise enthält die Clientvorrichtung ferner eine Kartenanzeige und das empfangene Plug-in-Softwareobjekt verändert die Kartenanzeige oder ergänzt die Karte mit zusätzlichen Informationen. Beispiele dafür sind Routenpläne, Abbiegeanweisungen, Bereichsabgrenzungen, detaillierterer Karteninhalt und Bilder. In einer bevorzugten Ausführungsform enthält die angezeigte Information Werbeinhalte und der Werbetreibende bezahlt den örtlich basierten Dienstanbieter für die Lieferung des Werbeinhalts.
26 veranschaulicht den Prozess, durch welchen Inhalt von dem Internet angefordert und auf der Clientvorrichtung angezeigt wird. Zunächst abonniert 260 der Benutzer einen Inhaltskanal, wie unter Bezug auf 22 beschrieben. Nach dem Abonnieren wird von der Clientvorrichtung ein erstes Plug-in-Softwareobjekt empfangen, was die Anforderung von weiteren Plug-in-Softwareobjekten ermöglicht. Der Inhaltskanal empfängt 262 eine von dem ersten Plug-in-Softwareobjekt erzeugte Anforderung wie unter Bezug auf die Schritte 180 bis 182 in 18 erläutert. Nach dem Empfangen der Inhaltsanforderung von der Clientvorrichtung übersetzt 263 das Inhaltskanal-Proxy in dem Inhaltskanal die Inhaltsanforderung in eine Internet-Inhaltsanforderung. Die Internet-Inhaltsanforderung wird zu der Internet-Inhaltsquelle übertragen 264, wobei die Internet-Inhaltsquelle den Inhalt in der Rohform assembliert 265 und an die Inhaltskanalanwendung überträgt 266. Der Inhalt in Rohform wird von dem Inhaltskanal empfangen 267, wo er codiert, übertragen und als ein Plug-in-Softwareobjekt gemäß den unter Bezug der 17 beschriebenen Schritten 170 bis 173 verfügbar gemacht 268 wird. Sobald das Plug-in-Softwareobjekt in der Clientvorrichtung verfügbar ist, wird es auf der Clientvorrichtung ausgeführt 269, um die Informationen in der Anzeige der Clientvorrichtung anzuzeigen.
22 zeigt einen beispielhaften Prozess zum Abonnieren eines Inhaltskanals. Dieser Prozess wird noch weiter erweitert, wenn der Inhaltskanal Inhalt von einer Internet-Inhaltsquelle nutzt, die ebenfalls ein Abonnement erfordert. Der Prozess des Abonnierens eines solchen Inhaltskanals ist in 27 veranschaulicht. Die anfänglichen Schritte 220 bis 224, die unter Bezug auf 22 beschrieben wurden, werden befolgt 270, um ein Abonnement anzufordern. Da jedoch die Internet-Inhaltsquelle ebenfalls ein Abonnement erfordert, wird die Abonnementinformation in Schritt 271 weiter zu dem Internet-Inhaltsanbieter gesendet. Die Details werden verwendet, um ein erfolgreiches Abonnement der Internet-Inhaltsquelle abzuschließen. Nach dem erfolgreichen Abonnieren der Internet-Inhaltsquelle wird eine Benachrichtigung in Schritt 272 zurück an den Inhaltskanal gesendet. Der Inhaltskanal sendet in Schritt 272 ein sicheres Cookie, das auf das Internetabonnement bezogene Informationen enthält, an die Clientvorrichtung und dieses wird in Schritt 274 in der Clientvorrichtung gespeichert, um den nachfolgenden Zugriff und das automatische Login der Internet-Inhaltsquelle zu ermöglichen.
Framework des Menüs auf Icon-Basis
In den in 8 bis 11 gezeigten Ausführungsformen des Framework hat einen Client Einrichtungen, um auf verschiedene Inhaltsquellen zuzugreifen, darunter lokale Inhaltsquellen, Inhalt von einem Server und Inhalt vom Internet. In einer bevorzugten Ausführungsform kann auf den von diesen Systemen bereitgestellten Inhalt effizient durch ein Menü auf Icon-Basis zugegriffen werden, das von dem Basis-Navigationsframework bereitgestellt wird. Die Verwendung von Icons auf diese Weise zur Darstellung von Menüoptionen erlaubt es Benutzern, Elemente von Interesse rascher zu erkennen und auszuwählen, und ist besonders nützlich bei tragbaren Navigationsvorrichtungen, die eine geringe Bildschirmgröße und kleine Dimensionen haben. Das Verfahren mit Icons ist nicht nur ästhetisch ansprechend, sondern auch sprachenunabhängig und auf verschiedenen Plattformen leicht zu implementieren. Dieses Verfahren unterstützt auch das Bereitstellen von Benutzerschnittstellenthemen auf der Clientvorrichtung; insbesondere Markenthemen können durch eine geeignete Auswahl von Menü-Icons eingerichtet werden.
Vorzugsweise wird das Icon-Menü durch das Benutzerinteraktions-Framework bereitgestellt und hat eine geschichtete Struktur, die konfigurierbar ist. Eine erste Schicht bezieht sich auf verschiedene Dienstkategorien, die durch den örtlich basierten Dienstanbieter bereitgestellt werden, eine zweite Schicht bezieht sich auf spezifische Dienste und andere Schichten beziehen sich auf mit diesen Diensten verbundene spezifische Funktionalitäten. Vorzugsweise sind die Dienste auf einen Inhaltskanal bezogen und werden von Plug-in-Softwareobjekten bereitgestellt, die durch den Inhaltskanal zugeliefert werden. Das Menüsystem ist lediglich Teil des Frameworks zur Nutzung der Plug-in- Softwareobjekte und das Hinzufügen von neuen Plug-in-Softwareobjekten kann veranlassen, dass das Menüsystem durch das Framework erweitert wird. Die Icons in dem Menü bieten ein Mittel für Benutzer, Plug-in-Softwareobjekte ablaufen zu lassen, die neue Funktionalität liefern, einschließlich einer Funktionalität, die das Menüsystem weiter erweitert.
28 zeigt ein Beispiel eines geschichteten Menüsystems, das drei Schichten enthält. Das Beispiel zeigt einen bevorzugten Typ der Benutzerschnittstelle für das Menüsystem, das eine Anordnung von Icons enthält. In diesem Beispiel stellt jedes Icon in einer ersten Schicht 280 eine Dienstkategorie dar, einschließlich Suchdiensten 281, eines Dienstes zum Auffinden von Freunden 282 und Hilfsdienste 283. Die Auswahl des Such-Icons 281 in diesem Beispiel führt zu einer zweiten Menüschicht 284, die dasselbe Benutzerschnittstellenformat wie die erste Schicht hat. Jedes Icon in der zweiten Menüschicht enthält Inhaltskanäle, die Google Local 285, Zagat 286 und New York Tourism POI 287 -Suchkanäle unterstützen. Die Kanäle Google Local und Zagat stellen Inhalt von einem entfernten Server bereit, aber der Kanal New York Tourism stellt Inhalt von einer Datenbank in dem Client bereit. In diesem Beispiel wird eine dritte Menüschicht 288 durch Auswahl des Google-Icon in der zweiten Menüschicht aktiviert. Tatsächlich führt die Aktivierung der dritten Menüschicht ein von dem Google Local Suchkanal bereitgestelltes Plug-in aus, und das Plug-in in Verbindung mit dem Benutzerinteraktions-Framework erzeugt die dritte Menüschicht. Die dritte Menüschicht für den Google Local Suchkanal enthält verschiedene Icons, ein Schlüsselwort-Icon 289, das eine Google-Suche unterstützt, und ein Starbucks- Icon 28a und ein McDonalds-Icon, die spezifische Google-Suchen darstellen.
Typischerweise sind die in der ersten Menüschicht 380 gezeigten Dienstkategorien von dem örtlich basierten Dienstanbieter bezeichnet und diese Information wird durch den Verzeichnisdienst bereitgestellt. Die durch den Verzeichnisdienst verfügbaren Inhaltskanäle werden einer Dienstkategorie zur gewesen, ebenfalls vorzugsweise durch den örtlich basierten Dienstanbieter. Die zweite Menüschicht 284 ist jedoch benutzerdefiniert. Vorzugsweise sind die in allen möglichen zweiten Menüschichten verfügbaren Icons mit den Zuordnungen der Dienstanbieter von Inhaltskanälen in Inhaltskanalkategorien konsistent. Ferner werden vorzugsweise Icons in der zweiten Ebene den vom Benutzer ausgewählten Inhaltskanälen entsprechend dargestellt. Daher konfiguriert der Benutzer selbst die Anordnung der zweiten Menüschichten durch die Auswahl von Inhaltskanälen.
Die dritte Menüschicht in dem in 28 gezeigten Beispiel ist für den Google-Suchkanal spezifisch und enthält ein Icon, das eine allgemeine Suche darstellt, sowie Icons, die eine Google-Suche nach Starbucks Coffee Shops und McDonald's-Restaurants darstellen. Die Icons von Starbucks und McDonald's sind spezifische Beispiele des allgemeineren Falles, in dem Icons in einem Menü eine vorbestimmte Inhaltsanforderung darstellen, die durch einfache Auswahl eines Icons ausgegeben werden kann. Inhaltsanforderungen werden an einen Inhaltskanal ausgegeben und vorzugsweise liefert der Inhaltskanal den angeforderten Inhalt einschließlich mit dem Inhalt in Bezug stehender Positionen in Länge und Breite an die Clientvorrichtung in Form eines Plug-in-Softwareobjekts. Jede beliebige Inhaltsquelle kann von dem Inhaltskanal verwendet werden, einschließlich Inhaltsquellen im Internet. Vorzugsweise wird eine Internet-Inhaltsquelle verwendet und die Inhaltsanforderung veranlasst die Ausgabe einer vorbestimmten Inhaltsanforderung an den Server durch das Inhaltskanal-Proxy an die Internet-Inhaltsquelle. Die Internet-Inhaltsquelle kann eine Datenbank, Suchmaschine, oder Fernerfassungsvorrichtung sein und die Inhaltsanforderung ruft eine Suchanfrage beziehungsweise einen -befehl auf. Vorzugsweise stellt der Inhaltskanal bevorzugte Inhaltsanforderungen des Benutzers als Icons dar und gibt diesen Benutzern die Fähigkeit, ihre eigenen Anforderungen auszuwählen und persönlich anzupassen. Auf diese Weise wird die Lieferung von bestimmten Informationen für bestimmte Benutzer dann, wenn sie diese benötigen, unter dem Gesichtspunkt der Nutzbarkeit beschleunigt.
Bei Navigationssystemen der vorstehend beschriebenen Art, die die Internet-Suche erlauben, können bevorzugte nächstliegende Suchvorgänge durch Icons in einem Menü auf Icon-Basis dargestellt sein. Der in 28 dargestellte Benutzerschnittstellen-Bildschirm enthält eine Anordnung von Icons, die spezifische Suchanforderungen darstellen. Ein Starbucks-Icon und ein McDonald's-Icon sind dargestellt. Ein Benutzer kann diese Icons auswählen, um Google Local zu durchsuchen, um die Lokale zu lokalisieren, die dem gegenwärtigen Standort der Clientvorrichtung, der durch eine Positionsbestimmungseinrichtung in der Clientvorrichtung bestimmt wird, am nächsten liegen. Suchmaschinen, wie etwa Google Local und Yahoo Local sind gegenwärtig textgesteuert. Die Bedienungsperson gibt Text entsprechend den Informationen ein, nach welchen sie sucht, und die Suchmaschine gewinnt eine Anzahl von übereinstimmenden Ergebnissen, einschließlich des Ortes des Ergebnisses. Eine durch Icons gesteuerte Suchfunktion nach dem nächstgelegenen Favoriten dieser Art in einer Navigationsvorrichtung ist wünschenswert, da sie das Erfordernis zur wiederholten Eingabe von alphanumerischen Daten durch den Benutzer beseitigt.
Mit einem Menü auf Icon-Basis gemäß vorliegender Erfindung besteht das Aufrufen einer Favoriten-Suche einfach in der Auswahl des entsprechenden Icons. Vorzugsweise enthält jedes Icon, das eine Suche darstellt, eine Gruppe von Suchparametern, die die Suche in gewisser Weise einschränken oder filtern. Beispiele für Suchparameter sind die Einschränkung der Suche auf eine bestimmte Distanz von der Clientvorrichtung, das Einschließen nur von Ergebnissen mit bestimmten Kosten oder darunter, oder die Suche nur nach Lokalen, die Sonderangebote haben. Vorzugsweise sind zusätzlich in der Definition der Suche Anzeigeparameter eingeschlossen, die die Art und Weise beeinflussen, wie die Ergebnisse dargestellt werden. Beispiele für Anzeigeparameter sind, dass eine Kartenansicht verwendet werden sollte, Orte darstellende Icons mit Namen versehen werden sollten, und dass kleiner Text verwendet werden sollte. Die verfügbaren Such- und Anzeigeparameter werden von dem Inhaltskanal und dem von dem Inhaltskanal bereitgestellten Plug-in-Softwareobjekt bestimmt, das die Suchanforderungen aufruft.
Vorzugsweise stellt ein favorisierte Suchen unterstützendes Plug-in-Softwareobjekt eine Benutzerschnittstelle bereit, die es dem Benutzer erlaubt, Suchanforderungen zu definieren und persönlich anzupassen, einschließlich der Suche selbst sowie gegebenenfalls zusätzlicher Such- und Anzeigeparameter. In einer bevorzugten Ausführungsform ist die Benutzerschnittstelle ein Wizard, der die einfache Eingabe und Editierung von Suchdefinitionen erlaubt, sowie das Speichern von Suchdefinitionen als eine favorisierte Suche. Vorzugsweise werden Suchen, die auf diese Weise eingegeben werden und nicht als favorisierte Suchen gespeichert werden, in einer Liste der kürzlichen Suchen gespeichert und können nachfolgend auch editiert, wieder verwendet und/oder als favorisierte Suchen gespeichert werden. In dem in 29 gezeigten Beispiel wird der Suchwizard von Google Local Suchkanälen aufgerufen, wenn das Google-Icon 289 in der dritten Suchmenüschicht 288 ausgewählt wird. 29 zeigt ein Beispiel eines Suchwizard-Bildschirms, der von einem Plug-in-Objekt von dem Google-Suchkanal bereitgestellt wird. Der Suchwizard-Bildschirm 290 stellt ein Schlüsselwortfeld 291 bereit, das die Eingabe von Schlüsselwörtern für die Suche durch das Benutzerinteraktions-Framework erlaubt. Zusätzlich enthält der Bildschirm ein Kategoriefeld 292, das es erlaubt, alle oder nur einen bestimmten Typ von Resultaten zu suchen, und ein Suchradiusfeld 293, das das Suchgebiet auf einen bestimmten Abstand von dem Ort der Clientvorrichtung beschränkt. Ein Anzeigetypfeld 294 erlaubt die Verwendung von mehreren unterschiedlichen Typen von Ergebnisanzeigen, und eine Anzeigedetailfeld 295 erlaubt es, detaillierte Informationen in einem größeren oder kleineren Ausmaß zu zeigen.
Das Bereitstellen von einem Menü auf Icon-Basis und Inhaltskanälen, die favorisierte Suchen unterstützen, kann verwendet werden, um die Erzeugung von Einkünften für den örtlich basierten Dienstanbieter und Geschäftsbetriebe Dritter zu unterstützen. Viele verschiedene Arten von Icon-Menü-plug-in-Funktionalität können bereitgestellt werden und beinahe jedes beliebige Geschäftsmodell kann zur Erzeugung von Einkünften verwendet werden. In einer beispielhaften Zielmarketinganwendung wird ein Inhaltskanal Benutzern frei zur Verfügung gestellt und der Inhaltskanal liefert Icons für ein Icon-Menü, das von dem Inhaltskanal unterstützt wird, welches Sonderangebote oder Rabatte für Produkte enthält, die für diese Benutzer von Interesse sind. In diesem Falle stellen die Icons favorisierte Suchen nach Orten, an denen die Produkte von Interesse verkauft werden, dar, und die Suchdefinition ist vordefiniert und automatisch durch den Inhaltskanal bereitgestellt. Das Geschäftsmodell für eine derartige Anwendung könnte ein Werbemodell sein, bei dem Werbetreibende für den Platz in dem Icon-Menü bezahlen, oder könnte ein Modell sein, bei dem Verkaufstransaktionen Einkünfte erzeugen. Anwendungen dieser Natur werden in dem System unterstützt, da das Kundenprofil einem örtlich basierten Dienstanbieter bekannt ist und das Transaktionsberichtsmodul eines Inhaltskanaldienstes das Benutzerverhalten einschließlich Produkt- und Zielauswahl überwachen kann. Diese Informationen erlauben es, besser zielgerichtete Marketingaktivitäten durchzuführen.
Wie früher erläutert, kann von der Clientvorrichtung empfangener Inhalt, wie zum Beispiel Suchergebnisse, auf verschiedene Arten durch das Benutzerinteraktions-Framework angezeigt werden. 30 zeigt eine bevorzugte Ausführungsform der Suchergebnisanzeige, in der Resultate als Ergebnisliste 300 oder als einen Radaranzeige 301 angezeigt werden und der Benutzer zwischen diesen beiden Anzeigearten problemlos umschalten kann. In der Listenanzeige 300 sind die Ergebnisse als eine Ergebnisliste dargestellt, die nach zunehmendem radialem Abstand von dem gegenwärtigen Ort der Navigationsvorrichtung geordnet ist. Jeder Eintrag in der Listenanzeige zeigt den Abstand des Ergebnisses von dem gegenwärtigen Standort, den Namen des Ergebnisses und die Art des gefundenen Ergebnisses. In diesem Anzeigemodus kann der Benutzer durch Auswahl des Radar-Icon 303 auf den Radaranzeigemodus umschalten. Die Suchergebnisse können auf einer Radar-artigen Anzeige 301 dargestellt werden, wo jedes Suchergebnis als ein Icon auf der Anzeige dargestellt wird. Die Icons sind relativ zur Position des Benutzers dargestellt, wobei die Benutzerposition in der Mitte des der Anzeige ist. Der Benutzer kann ohne weiteres durch Auswahl des Listen-Icon 304 auf die Listenanzeige 301 umschalten. In beiden Ergebnisanzeigen kann jedes Suchergebnis ausgewählt werden, um mehr Details über das Ergebnis anzuzeigen. Mehr Details werden durch eine Ergebnisdetailanzeige 302 dargestellt, die die bereits in der Listenanzeige 300 gezeigten Informationen sowie eine Detail-Kartenansicht der Ergebnisumgebung und weitere Informationen über das Ziel enthält, sofern diese verfügbar sind, wie zum Beispiel eine Beschreibung oder ein Bild, das auf das Suchergebnis bezogen ist. Das in der Ergebnisdetailanzeige gezeigte Ergebnis kann unter Verwendung des Auswahl-Icon ausgewählt werden und für verschiedene Zwecke verwendet werden. Beispiele für Zwecke der Ergebnisauswahl sind die Verwendung desselben als Ziel, das Hinzufügen desselben zu einem Routenplan, zur Verwendung als Treffpunkt und zur Speicherung als bevorzugtes Ziel. Weitere Beispiele in Bezug auf die auf diese Weise erhaltene Ergebnisauswahl werden in nachfolgenden Abschnitten erörtert.
28, 29 und 30 zeigen ein Beispiel des Frameworks für das Menü auf Icon-Basis, das für die Suche in Google Local gemäß vorliegender Erfindung verwendet wird. 31 zeigt die Schritte, die von dem System während der Suche in Google Local durchgeführt werden. In dem Anfangsschritt wird angenommen, dass die unter Bezug auf 18 beschriebenen Schritte 180 bis 184 durchgeführt wurden, um ein Plug-in-Objekt für den Google Local Kanal zu erhalten. Das Google Local Icon 289 in 28 wird in Schritt 310 von dem Benutzer ausgewählt, um eine Suche in Google Local einzuleiten. Der Benutzer gibt dann in Schritt 311 einen Suchbegriff, in diesem Fall "Tankstelle" in das in 29 gezeigte Schlüsselwortfeld 291 ein. In Schritt 313 werden die Suchbegriffe zusammen mit dem Ort der Navigationsvorrichtung an einen Google Local Inhaltskanaldienst auf dem Server in Übereinstimmung mit dem unter Bezug auf 26 beschriebenen Schritt 262 gesendet. In Schritt 314 werden die unter Bezug auf 26 beschriebenen Schritte 263 und 264 von dem Inhaltskanal-Proxy durchgeführt, um die Suchbegriffe und den Ort als eine HTTP-Anforderung an den Google Local Server umzuformatieren. Die Anforderung wird über das Internet gesendet, und zwar in derselben Weise wie eine beliebige Google Suchanforderung über das Internet von einem Web-Browser durchgeführt wird. Die von Google Local assemblierten Ergebnisse werden in Schritt 315 als eine HTML Webseite in Übereinstimmung mit den unter Bezug auf 26 beschriebenen Schritten 265 und 266 zurück zu dem Server gesendet. In Schritt 316 wird die Webseite von dem Inhaltskanal-Proxy auf dem Server in ein Plug-in-Softwareobjekt umgewandelt und zu der Clientvorrichtung übertragen. Der Umwandlungsprozess schließt eine Filterung auf der Grundlage des Vorrichtungstyps ein, auf welcher der Inhalt angezeigt werden soll, und kann eine Geocodierung einschließen. Wenn die Navigationsvorrichtung nur Text anzeigen kann, enthält das Objekt nur Text. Wenn sie komplexeren Inhalt darstellen kann, kann auch dieser eingeschlossen sein. Das Objekt könnte die Identität und den Ort einer Anzahl von Tankstellen in der Nähe der Clientvorrichtung einschließen und das Objekt wird in Schritt 317 durch den Client ausgeführt, wodurch eine Anzeige der Suchergebnisse in einer Anzahl von Formaten, als eine Liste ähnlich der Listenanzeige 300 aus 30 oder als eine Radaranzeige ähnlich der Radaranzeige 301 aus 30 erzeugt wird. Der Benutzer ist dann in der Lage, in Schritt 318 eine Tankstelle aus der Ergebnisliste auszuwählen und ein Ergebnisdetailbildschirm ähnlich 302 in 30 wird dargestellt.
Navigations-Benutzeranpassungs-Framework
Die meisten Navigationssysteme, die die Erzeugung einer automatischen Routenführung haben, liefern die Routenführung unter Verwendung einer Standardschnittstelle, die nicht von dem gegenwärtig ausgewählten Ziel abhängig ist. In einem weiteren Aspekt der vorliegenden Erfindung kann das Framework zur Bereitstellung von Navigationsinhalten unter Verwendung von Plug-in-Softwareobjekten erweitert werden, so dass es eine andere Routenführungsbenutzerschnittstelle als die von der Basis-Navigationsplattform normalerweise verwendete zur Verfügung stellt. Die Routenführung zu einem speziellen Ziel kann durch eine individuell angepasste Benutzerschnittstelle verfügbar gemacht werden, wenn ein Benutzer der Clientvorrichtung die Führung zu dem speziellen Ziel anfordert. Vorzugsweise ist die individuell angepasste Benutzerschnittstelle für das ausgewählte spezielle Ziel spezifisch und enthält Logos, Farben oder andere zu dem speziellen Ziel gehörende Informationen. Sobald das spezielle Ziel erreicht wurde oder ein alternatives Ziel ausgewählt wird, ist die Benutzerschnittstelle nicht länger für das Ziel spezifisch.
In der soeben beschriebenen Weise kann die Routenführungsbenutzerschnittstelle individuell angepasst werden, so dass Themen, ein Markenzeichen und mit einem speziellen Ziel in Beziehung stehende Werbung wiedergegeben werden, um für den örtlich basierten Dienstanbieter Einkünfte zu erzeugen. Vorzugsweise ist das spezielle Ziel ein Geschäftsbetrieb und der Geschäftsbetrieb bezahlt Sponsorgebühren an den Anbieter der Routenführungsinformationen. 32 zeigt, wie die Navigationsvorrichtung eine Werbeplattform für den Sponsor wird, wobei die Routenführung unter ein Thema gestellt wird, so dass sie der Marke des Sponsors entspricht. Wenn die Marke des Sponsors mit einer bestimmten Farbe verbunden ist, kann diese Farbe als die vorherrschende Farbe am Bildschirm verwendet werden. In ähnlicher Weise können ein Logo 320 am Bildschirm erscheinen und Details zu Produkten im Sonderangebot. Beinahe jedes beliebige Geschäftsmodell kann verwendet werden, um aus diesem System Einkünfte zu erzeugen. Beispiele dafür sind, dass der Sponsor pro Navigationsvorgang zu ihm oder eine pauschale Gebühr an den örtlich basierten Dienstanbieter bezahlt, und der Sponsor Kunden durch die Navigationsvorrichtung ein besonderes Angebot macht und den örtlich basierten Dienstanbieter bezahlt, wenn dieses Angebot angenommen wird. Die Erzeugung von Einkünften auf diese Weise wird durch ein Transaktionsberichtsmodul eines Inhaltskanaldienstes erleichtert.
Die individuelle Anpassung der Navigations-Routenführung, die bereits für ein besonderes Ziel erwähnt wurde, wird in Form eines Plug-in-Objekts bereitgestellt, das in der Clientvorrichtung ausgeführt wird. Das Plug-in-Objekt ist mit dem speziellen Ziel in einer Datenbank spezieller Ziele verbunden, bei welchen die individuelle Anpassung der Benutzerschnittstelle erforderlich ist. Die Clientvorrichtung hat eine Einrichtung zum Zugriff auf diese Datenbank, wobei bei der Benutzung dann, wenn ein Benutzer auf der Clientvorrichtung ein Ziel für die Routenwahl auswählt, die Clientvorrichtung von der Datenbank abfragt, ob das ausgewählte Ziel ein spezielles Ziel ist und dann, wenn das ausgewählte Ziel ein spezielles Ziel ist, ein entsprechendes Plug-in-Softwareobjekt, das in der Datenbank mit dem Ziel verbunden ist, die Routenführungsbenutzerschnittstelle der Clientvorrichtung individuell anpasst.
Zur Umsetzung des Schemas ist eine Datenbank mit Punkten von Interesse (POI) von Geschäftsstandorten erforderlich. Die POI-Datenbank enthält Informationen über die Namen, Arten und Standorte von Geschäftsbetrieben. Die POI-Datenbank kann an jeder beliebigen von der Clientvorrichtung zugreifbaren Position sein, einschließlich in der Clientvorrichtung selbst, auf einem mit der Clientvorrichtung verbundenen Server, oder im Internet durch einen Server zugreifbar, der mit dem Internet und der Clientvorrichtung verbunden ist. Die POI-Datenbank kann eine feste Datenbank sein, die niemals aktualisiert wird, eine Datenbank, die periodisch aktualisiert wird, oder eine Live-Datenbank, die kontinuierlich aktualisiert wird. In einer Einzelgeräte-Systemkonfiguration, wie in 9 gezeigt, können die Benutzer eine lokale POI-Datenbank auf einer Speicherkarte aktualisieren, indem unter Verwendung einer beliebigen verfügbaren Einrichtung periodisch eine Aktualisierung vom Internet herunter geladen wird. Beispiele für Einrichtungen sind das herunterladen einer Datei von einer Website auf einen PC, welche unter Verwendung eines Speicherkartenlese-/-schreibgeräts, das mit dem PC verbunden ist, auf die Speicherkarte kopiert wird.
Vorzugsweise ist die Clientvorrichtung mit einem Server verbunden und der Server enthält eine Live-Datenbank von speziellen Zielen, die von einem örtlich basierten Dienstanbieter oder einem Dritten unterhalten wird. Vorzugsweise wird zusätzlich Inhalt zu der Datenbank hinzugefügt, wenn ein Werbevertrag mit dem örtlich basierten Dienstanbieter oder dem Dritten abgeschlossen wird, oder von einem einzelnen Geschäftsbetrieb. Einzelne Geschäfte können ihre Details zur Datenbank hinzufügen, die durch ein Internet-Webportal über das Internet zugreifbar ist. Geschäftsbetriebe, die eine gesponserte Routenführung oder einen zielspezifischen Werbedienst abonnieren möchten oder abonniert haben, können dies durch das Webportal tun. Ein Beispiel für eine Webportal-Benutzerschnittstelle für eine POI-Datenbank ist in 33 gezeigt. Das Webportal zu der Datenbank erlaubt das Sammeln von Themeninformationen von Geschäftsbetrieben und erlaubt es Geschäftsbetrieben, ihre eigenen Erfordernisse zu verwalten. Das Webportal ist vorzugsweise einfach zu nutzen und erlaubt es einem Geschäftsbetrieb, seinen Namen, seine Art und Position und für Werbezwecke verwendete Informationen einzugeben. Die Informationen bestimmen, wie Farbschemata angewandt werden, und können kleine Logos einschließen, die als Teil des Navigationsinhalts gezeigt werden. Ein Vorschaumodus erlaubt es dem Werbetreibenden, die Markendarstellung zu betrachten, die Endbenutzer in den Navigationsprodukten sehen werden, während sie zu ihrem ausgewählten Ziel fahren.
32 zeigt ein Beispiel einer Benutzerschnittstelle 320, die für ein beabsichtigtes Ziel spezifisch ist, wobei es sich in diesem Beispiel um ein McDonald's Fastfood Restaurant handelt. 34 zeigt, was geschieht, wenn das Mcdonald's-Restaurant als Navigationsziel verwendet wird. In Schritt 340 wird eine Suche nach Fastfond-Restaurants durchgeführt und ein bestimmtes Restaurant von der Ergebnisliste wird ausgewählt. Die Clientvorrichtung sendet in Schritt 341 eine Anforderung nach mehr Details des Ergebnisses an den Inhaltskanal, der das Ergebnis bereitgestellt hat. In Schritt 342 prüft der Inhaltskanal seine Datenbank mit gesponserten Zielen und assembliert ein Ergebnisdetailobjekt, das auch ein Kennzeichen enthält, dass das Ziel ein gesponsertes Ziel ist. Das Ergebnisdetailobjekt wird in Schritt 343 an die Navigationsvorrichtung gesendet, wo es angezeigt wird. Das Ergebnisdetailobjekt kann erforderlichenfalls eine individuell angepasste Ergebnisdetailanzeige erzeugen. Beispielsweise könnte ein Sonderangebot oder eine Werbung dargestellt werden, um Kunden weiter dazu zu verleiten, zu dem Standort zu navigieren. Der Benutzer bestätigt 344 seine Auswahl und wählt die Navigation dorthin aus. Die Clientvorrichtung sendet in Schritt 345 eine Anforderung für ein individuelles Navigationsbenutzerschnittstellen-Plug-in an den Inhaltskanaldienst. Der Inhaltskanaldienst empfängt das Plug-in und antwortet in Schritt 346 mit einem Objekt, das verwendet werden kann, um die individuell angepasste Navigationsschnittstelle zu erzeugen. Die Navigationsvorrichtung führt die Routenführung zu dem ausgewählten Ziel unter Verwendung der individuell angepassten Benutzerschnittstelle in Schritt 347 aus. In diesem Beispiel wird eine McDonald's-spezifische Benutzerschnittstelle verwendet, einschließlich eines McDonald's-Logo 320 und eines Farbschemas. Wegführungsanweisungen können individuell angepasst werden, dass McDonald's genannt wird; beispielsweise "McDonald's auf der linken Seite in 1,5 Meilen".
Peer-to-Peer-Mitteilungs-Framework
In einer bevorzugten Ausführungsform kann ein Server zur Bereitstellung von Navigationsinhalten drahtlos mit einer oder mehreren angeschlossenen Navigationsclientvorrichtungen kommunizieren. Zusätzlich haben die Navigationsclientvorrichtungen Einrichtungen zur Kommunikation über ein drahtloses Netz mit anderen Navigationsclientvorrichtungen oder anderen Vorrichtungen eines unterschiedlichen Typs. Beispiele für Vorrichtungen eines unterschiedlichen Typs sind Mobiltelefone, PDAs, Computer, oder Fernsteuereinrichtungen. Das für die Kommunikation zwischen der Navigationsclientvorrichtung und anderen Vorrichtungen verwendete Netz kann das gleiche oder ein anderes Netz sein, das von dem Server zur Bereitstellung von Navigationsinhalten zur Kommunikation mit der Navigationsclientvorrichtung verwendet wird. Wenn das Netz keine direkte Kommunikation von Vorrichtung zu Vorrichtung unterstützt, kann die Kommunikation auch über einen Server erfolgen, wie z. B. einen Inhaltskanalserver. Beispiele für Netze, die für die Kommunikation von Vorrichtung zu Vorrichtung verwendet werden können, sind ein zelluläres Netz und ein 802.11 LAN. Die Information kann zwischen den Vorrichtungen durch eine beliebige von dem Navigationsclient und der zweiten Vorrichtung unterstützte Mitteilungseinrichtung gesendet werden. Beispiele dafür sind SMS, MMS und E-Mail. In einer bevorzugten Ausführungsform ist die zweite Vorrichtung ein Mobiltelefon, das zur Kommunikation mit anderen Vorrichtungen verwendete Netz ist zellulär und die gesendete Information ist eine SMS oder MMS Mitteilung.
Das Netz für die Kommunikation von Vorrichtung zu Vorrichtung kann von einer Navigationsclientvorrichtung verwendet werden, um örtlich basierte Informationen zu einer zweiten Vorrichtung über das drahtlose Netz zu senden. Die Informationen können beliebige Informationen sein. Beispiele sind Details eines Standorts, eine Karte, Routenführung zu dem Standort und Werbung. Vorzugsweise gibt der Benutzer des Navigationsclients den Standort durch die Benutzerschnittstelle des Clients an und von dem Standort abhängige Informationen werden automatisch erzeugt und zu einer zweiten Vorrichtung gesendet, die eine Einrichtung zur Verbindung mit dem drahtlosen Kommunikationsnetz hat. In diesem Beispiel kann die Navigationsclientvorrichtung Karten und Anweisungen zu jedem beliebigen MMS-fähigen Mobiltelefon und nur Text umfassende Anweisungen und Informationen an jedes beliebige SMS-fähige Mobiltelefon senden. Ferner können die gesendeten Informationen in beiden Fällen auf einem gewöhnlichen SMS- oder MMS-fähigen Telefon angezeigt werden, das keine Veränderungen oder spezielle Software hat. Die Navigationsclientvorrichtung stellt die gesamte zusätzliche Funktionalität bereit, die erforderlich ist, um örtlich basierte Informationen zu erzeugen und an jedes geeignete Telefon zu senden.
Navigationsclientsoftware, die Mitteilungsübermittlung von Vorrichtung zu Vorrichtung integriert, kann zum Organisieren von Treffen mit mehreren Teilnehmern verwendet werden, die zumindest ein Basis-Mobiltelefon haben, das zum Empfangen von SMS-Mitteilungen in der Lage ist. 35 ist eine schematische Darstellung einer tragbaren Navigationsvorrichtung 350, die für andere tragbare drahtlose Vorrichtungen 351 und 352 auf diese Weise arbeitet. In diesem Beispiel sendet der Organisator des Treffens Einladungen zu dem Treffen, die den Ort und andere Informationen als Textmitteilungen enthalten. In ähnlicher Weise können Einladungen zu dem Treffen von der Navigationsclientvorrichtung 350 an ein MMS-fähiges Telefon 353 als eine MMS-Mitteilung gesendet werden, die sowohl Textmitteilungen als auch Bilder enthält. 36 zeigt eine beispielhafte Benutzerschnittstelle, die zum Senden von Mitteilungen verwendet wird. Sobald ein Ort für das Treffen ausgewählt wurde und die Eingeladenen ausgewählt wurden, kann ein Zeitpunkt für das Treffen gewählt werden und eine kurze Mitteilung eingegeben werden.
In einem weiteren Aspekt der vorliegenden Erfindung kann eine Navigationsclientvorrichtung, die die Einrichtung zum drahtlosen Senden von Einladungen an andere drahtlose Vorrichtungen sowie eine Einrichtung zur Erzeugung von Navigationsanweisungen hat, als ein Navigationsserver für andere drahtlose Vorrichtungen dienen. Unter Fortführung des vorstehenden Beispiels und unter Bezug auf 35 können Routen für alle Eingeladenen zu dem Treffen, die die Einladung zur Teilnahme an dem Treffen annehmen und die einen Standort angegeben haben oder deren Standort bekannt ist, in der Navigationsclientvorrichtung 350 des Organisators erzeugt werden. Routenführungsanweisungen können als Teil einer Bestätigungsmitteilung an die Teilnehmer als reine Textanweisungen an die SMS-fähigen Telefone 351 und 352 und als Multimediaanweisungen an das MMS-fähige Mobiltelefon 353 gesendet werden. Das MMS-Telefon 353 kann eine Reihe von interaktiven grafischen oder akustischen Abbiegeanweisungen empfangen, die von einem Teilnehmer des Treffens unter Verwendung von Vorwärts- und Rückwärtspfeilen ohne weiteres durchgeblättert werden können. Wenn der Standort eines Teilnehmers nicht bekannt ist, können weitere Details des Treffens einschließlich Zeitpunkt und Ort nur in Textform an die SMS-fähigen Mobiltelefone 351 und 352 gesendet werden, oder als eine MMS-Mitteilung, die den Zeitpunkt und den Ort zusammen mit einer Karte des Ziels und seiner Umgebung enthält.
Es herrscht eine weit verbreitete Akzeptanz von Mobiltelefonen, die Standardmerkmale, wie zum Beispiel Textmitteilungen und Multimediamitteilungen bereitstellen. Trotz einer langsamen Zunahme besteht nur eine eingeschränkte Akzeptanz von Clientnavigationsvorrichtungen oder Allzweckvorrichtungen, auf welchen Navigationsclientsoftware abläuft. Um das Bewusstsein für die und das Wachstum der örtlich basierten Produkte und Dienste zu fördern, die von einem örtlich basierten Dienstanbieter bereitgestellt werden, oder um die Produkte und Dienste von Dritten zu fördern, können vorzugsweise die von einer Navigationsclientvorrichtung gesendeten Mitteilungen auch Werbeinhalte enthalten. Vorzugsweise wird der Werbeinhalt im Namen eines Drittgeschäftsbetriebs von dem örtlich basierten Dienstanbieter geliefert, und der Geschäftsbetrieb bezahlt den örtlich basierten Dienstanbieter für die Lieferung der Werbung. Jedes beliebige Geschäftsmodell kann verwendet werden. Beispiele dafür sind die Zahlung einer Pauschalgebühr für die Sendung, die Bezahlung pro gelieferter Werbemitteilung und die Teilung der Einkünfte durch Verkaufstransaktionen, die durch zielgerichtete Sonderangebote erzeugt werden.
Gemäß vorliegender Erfindung kann die Übertragung von Mitteilungen von Vorrichtung zu Vorrichtung durch Plug-in-Objekte eingeleitet oder individuell angepasst werden. Ferner können Plug-in-Objekte aktiviert werden, wenn Mitteilungen empfangen werden, um diese Mitteilungen automatisch zu verarbeiten oder automatisch weitere Mitteilungen in Abhängigkeit von den empfangenen Mitteilungen zu senden. Das Basis-Navigations-Framework bietet Unterstützung für die Mitteilungen von Vorrichtung zu Vorrichtung. Diese Unterstützung ist in Ausführungsformen des Frameworks durch die Bereitstellung von Peer-to-Peer-Mitteilungs-APIs und ein Benutzerinteraktions-Framework, das den Mitteilungsaustausch zwischen Vorrichtungen unterstützt, standardisiert. Die von den Inhaltskanälen zugelieferten Plug-in-Objekte können diese Mechanismen verwenden, um eine Reihe von Zielen für einen örtlich basierten Dienstanbieter oder einen Dritten zu erreichen. Beispiele dafür sind die einfache Erzeugung von Bewusstsein für ein Produkt oder einen Dienst oder das Leiten von Verkehr zu einem bestimmten Geschäftsstandort.
37 veranschaulicht, was typischerweise in dem System geschieht, wenn ein Benutzer einer Navigationsclientvorrichtung ein Treffen mit einer anderen Person organisiert, die ein MMS-fähiges Mobiltelefon gemäß vorliegender Erfindung hat. In Schritt 370 verwendet der Organisator des Treffens die Navigationsvorrichtung, um einen geeigneten Ort für das Treffen zu finden, und zwar unter Verwendung eines Zielsuchverfahrens, wie etwa des bereits unter Bezug in 31 beschriebenen Verfahrens. Ein Plug-in-Objekt in der Clientvorrichtung stellt eine Benutzerschnittstelle ähnlich der in 36 dargestellten bereit, die das Aufbauen einer Einladung für die andere Person zum Treffen in Schritt 371 erlaubt, die den Ort des Treffpunkts enthält. Der Ort wird typischerweise in der Einladung in einem vom Menschen lesbaren Format beschrieben und die Einladung kann auch ein Kartenbild des Ortes enthalten. Die Einladung wird in Schritt 373 an das Mobiltelefon der anderen Person gesendet, wo sie empfangen und gelesen wird. In der Einladung sind Anweisungen enthalten, wie das Treffen akzeptiert oder abgelehnt wird. Jeder Teilnehmer kann in Schritt 374 die Aufforderung zum Treffen akzeptieren, wie in der ursprünglichen Mitteilung angegeben, indem er antwortet (z. B. durch Senden von "J" = ja oder "N" = nein), und kann optional seinen gegenwärtigen Standort in der Antwortmitteilung (in einem freien Format) angeben. Wenn die Eingeladenen Mobiltelefone haben, deren Standort durch das Netz bekannt ist, können die Standorte der Teilnehmer von dem Navigationsclient automatisch erfasst werden, und in diesem Fall muss der gegenwärtige Standort in der Einladung nicht abgefragt werden. Beispiele für Mobiltelefonnetze, die diese Fähigkeit gegenwärtig in den Vereinigten Staaten bereitstellen, sind Sprint und Nextel.
Die Annahmemitteilung wird in Schritt 375 von der Clientvorrichtung des Organisators empfangen. Sofern verfügbar, kann die Anrufer-Kennung verwendet werden, um den Sender zu identifizieren. Der Standort des Senders wird in Schritt 375 automatisch durch das Netz, durch syntaktische Zerlegung der Mitteilung bestimmt, oder wird manuell von dem Organisator eingegeben. Sobald der Standort bekannt ist, verwendet in Schritt 376 die Navigationsvorrichtung diesen Standort, um Routenführungsanweisungen zwischen dem Standort der anderen Person und dem Standort des Treffpunkts zu berechnen. Die Anweisungen werden in Schritt 377 als MMS-Mitteilungen, die Abbiegeanweisungen enthalten, gesendet. Die andere Person empfängt die Mitteilung in Schritt 378 und kann dann auf die MMS-Anweisungen Bezug nehmen, während sie den Weg zum Treffpunkt zurücklegt. Zusammen mit der Routenführung sieht sie Werbung für ein Produkt oder einen Dienst.
Zusammenfassung
Die Erfindung betrifft Navigationsvorrichtungen und die Bereitstellung sowohl von Daten als auch von Funktionalität für Navigationsvorrichtungen. Die Erfindung schafft eine Navigationsvorrichtung, auf der Basis-Navigationsframework-Software abläuft, die ein Framework zur Bereitstellung eines vollständigen Navigationsinhalts unterstützt, wobei das Framework eine festgelegte Gruppe von Plug-in-Softwareobjekt-Typen unterstützt. Die unterstützte Plug-in-Software kann der Navigationsvorrichtung Daten und zusätzliche Funktionalität zur Verfügung stellen. Plug-in-Softwareobjekte können in die Navigationsvorrichtung von einem Server heruntergeladen werden, der auch Teil des Frameworks ist. Der Download kann über ein drahtloses Netz während des Betriebs der Navigationsvorrichtung und ansprechend auf Benutzer-Auswahlvorgänge an der Navigationsvorrichtung erfolgen.

Claims

Framework zur Bereitstellung von Navigationsinhalten, enthaltend: eine Clientvorrichtung, die ein Basis-Navigationsframework zur Bereitstellung einer Basis-Navigationsfunktionalität hat, welches Basis-Navigationsframework eine festgelegte Gruppe von Plug-in-Softwareobjekten unterstützt.
Framework zur Bereitstellung von Navigationsinhalten nach Anspruch 1, ferner enthaltend einen Server, der mit der Clientvorrichtung verbunden ist und der dafür konfiguriert ist, Plug-in-Softwareobjekte für die Clientvorrichtung bereitzustellen, welche Plug-in-Softwareobjekte der Clientvorrichtung zusätzliche Funktionalität verleihen.
Framework zur Bereitstellung von Navigationsinhalten nach Anspruch 2, bei welchem die Clientvorrichtung und der Server über eine drahtlose Verbindung verbunden sind.
Framework zur Bereitstellung von Navigationsinhalten nach Anspruch 2, bei welchem der Client und der Server physisch in derselben Vorrichtung angeordnet sind.
Verfahren zur Bereitstellung von zusätzlicher Funktionalität für eine Clientvorrichtung, die ein Basis-Navigationsframework zur Bereitstellung einer Basis-Navigationsfunktionalität hat, welches Basis-Navigationsframework eine festgelegte Gruppe von Plug-in-Softwareobjekten unterstützt, enthaltend den Schritt: Bereitstellen von Plug-in-Softwareobjekten für die Clientvorrichtung, welche Plug-in-Softwareobjekte der Clientvorrichtung zusätzliche Funktionalität verleihen.
Verfahren nach Anspruch 5, bei welchem der Schritt des Bereitstellens von Plug-in-Softwareobjekten die Bereitstellung von Plug-in-Softwareobjekten von einem Server über eine drahtlose Verbindung einschließt.
Verfahren nach Anspruch 5 oder Anspruch 6, bei welchem der Schritt des Bereitstellens von Plug-in-Softwareobjekten das Einbetten der Plug-in-Softwareobjekte in geographischen Daten, die in der Clientvorrichtung gespeichert sind, einschließt.
Verfahren nach einem der Ansprüche 5 bis 7, bei welchem in den Plug-in-Softwareobjekten enthaltener Programmcode und Daten in die Programmfunktionalität der Clientsoftware in der Clientvorrichtung integriert werden, während der Programmcode in der Clientvorrichtung ausgeführt wird.
Verfahren nach einem der Ansprüche 5 bis 8, bei welchem der in den Plug-in-Softwareobjekten enthaltene Programmcode in einem portierbaren Byte-Code formatiert ist und von einer in der Clientvorrichtung enthaltenen virtuellen Maschine ausgeführt wird.
Verfahren zur Bereitstellung zusätzlicher Funktionalität für eine Clientvorrichtung, die ein Basis-Navigationsframework zur Bereitstellung von Basis-Navigationsfunktionalität hat, welches Basis-Navigationsframework eine festgelegte Gruppe von Plug-in-Softwareobjekten unterstützt, enthaltend die Schritte: Bereitstellen von Plug-in-Softwareobjekten für die Clientvorrichtung, und Speichern der Plug-in-Softwareobjekte zeitweilig oder dauerhaft in der Clientvorrichtung, welche Plug-in-Softwareobjekte der Clientvorrichtung zusätzliche Funktionalität verleihen, wenn sie in der Clientvorrichtung ausgeführt werden.
Verfahren nach Anspruch 10, bei welchem der Schritt des Bereitstellens von Plug-in-Softwareobjekten das Bereitstellen nur derjenigen Objekte, die nicht bereits dauerhaft oder vorübergehend in der Clientvorrichtung gespeichert sind, enthält.
Verfahren nach Anspruch 10 oder 11, bei welchem der Schritt des Speicherns der Plug-in-Softwareobjekte in der Clientvorrichtung das Speichern der Plug-in-Softwareobjekte enthält, bis sie ungültig gemacht werden, da die Funktionalität oder die Daten, die sie einschließen, zurückgezogen oder aktualisiert wurden.
Verfahren nach Anspruch 10, 11 oder 12, ferner enthaltend den Schritt des Löschens der Plug-in-Softwareobjekte, um Platz für in jüngerer Zeit erzeugte Plug-in-Softwareobjekte zu schaffen.
Verfahren nach einem der Ansprüche 10 bis 13, ferner enthaltend den Schritt der Registrierung der Plug-in-Softwareobjekte in der Clientvorrichtung um Bedingungen anzugeben, welche dann, wenn sie eintreten, die Löschung der Plug-in-Softwareobjekte verursachen.
Framework zur Bereitstellung von Navigationsinhalten, enthaltend: einen Server, der dafür konfiguriert ist, Plug-in-Softwareobjekte für Clientvorrichtungen bereitzustellen, welche Plug-in-Softwareobjekte den Clientvorrichtungen zusätzliche Funktionalität verleihen, wenn sie in den Clientvorrichtungen ausgeführt werden.
Framework zur Bereitstellung von Navigationsinhalten nach Anspruch 15, bei welchem der Server dafür konfiguriert ist, Details der verfügbaren Plug-ins an die Clientvorrichtungen zu senden.
Framework zur Bereitstellung von Navigationsinhalten, enthaltend: eine Clientvorrichtung, die ein Basis-Navigationsframework zur Bereitstellung einer Basis-Navigationsfunktionalität hat, welches Basis-Navigationsframework eine festgelegte Gruppe von Plug-in-Softwareobjekten unterstützt; eine Eingabeeinrichtung, die mit der Clientvorrichtung verbunden ist oder ein Teil derselben ist, um in Übereinstimmung mit einer mit der Clientvorrichtung verbundenen Eigenschaft ein Eingabesignal abzugeben; wobei die Plug-in-Softwareobjekte zur Ausführung in der Clientvorrichtung ansprechend auf ein Signal von der Eingabeeinrichtung programmiert sind.
Framework zur Bereitstellung von Navigationsinhalten nach Anspruch 17, bei welchem die Eingabeeinrichtung eine absolute Ortungseinrichtung, wie z. B. ein GPS-Sensor ist.
Framework zur Bereitstellung von Navigationsinhalten nach Anspruch 17 oder 18, bei welchem das Eingabesignal von der Eingabeeinrichtung auf die Geschwindigkeit der Clientvorrichtung, die Umgebungstemperatur, Umgebungslichtpegel, Wassertiefe, die Zeit oder spezifische Formen von Benutzereingaben bezogen ist.
Framework zur Bereitstellung von Navigationsinhalten nach einem der Ansprüche 17 bis 19, bei welchem die Plug-in-Softwareobjekte zur Registrierung in der Clientvorrichtung konfiguriert sind, um relevante Auslösesignale und Bedingungen festzulegen.
Verfahren zur Bereitstellung von Navigationsfunktionalität oder Navigationsinformationen für einen Benutzer einer Clientvorrichtung, die ein Basis-Navigationsframework zur Bereitstellung von Basis-Navigationsfunktionalität hat, welches Basis-Navigationsframework eine festgelegte Gruppe von Plug-in-Softwareobjekten unterstützt, enthaltend den Schritt: Bereitstellen von Plug-in-Softwareobjekten, die zur Ausführung auf der Clientvorrichtung ansprechend auf eine bestimmte Bedingung in Verbindung mit der Clientvorrichtung konfiguriert sind.
Verfahren nach Anspruch 21, bei welchem die bestimmte Bedingung auf die Position der Clientvorrichtung bezogen ist.
Framework zur Bereitstellung von Navigationsinhalten, enthaltend: eine Clientvorrichtung, die ein Basis-Navigationsframework zur Bereitstellung von Basis-Navigationsfunktionalität hat, welches Basis-Navigationsframework eine festgelegte Gruppe von Plug-in-Softwareobjekten unterstützt; und einen Server in Kommunikation mit der Clientvorrichtung und dem Internet; wobei die Clientvorrichtung eine Einrichtung enthält, um eine Anforderung von Inhalten an den Server zu senden und wobei der Server eine Einrichtung zur Anforderung des Inhalts von mit dem Internet verbundenen Quellen auf der Grundlage der Anforderung von der Clientvorrichtung, eine Einrichtung zum Empfangen des resultierenden Inhalts und eine Einrichtung zum Übertragen desselben an die Clientvorrichtung in Form eines Plug-in-Softwareobjekts einschließt.
Framework zur Bereitstellung von Navigationsinhalten nach Anspruch 23, bei welchem der Server ein Plug-in-Softwareobjekt an die Vorrichtung abgibt, das bei Ausführung auf der Clientvorrichtung eine Einrichtung für einen Benutzer zur Anforderung von Inhalt von dem Server bereitstellt.
Framework zur Bereitstellung von Navigationsinhalten nach Anspruch 23 oder 24, bei welchem die Clientvorrichtung ein Positionsbestimmungssystem enthält.
Framework zur Bereitstellung von Navigationsinhalten nach Anspruch 25, bei welchem eine Position der Clientvorrichtung, wie sie durch das Positionsbestimmungssystem bestimmt wurde, mit der Anforderung von Inhalt gesendet wird, und der resultierende Inhalt in Abhängigkeit von der Position maßgeschneidert wird.
Framework zur Bereitstellung von Navigationsinhalten nach einem der Ansprüche 23 bis 26, bei welchem die Anforderung von Inhalt in Abhängigkeit von einem aktuellen Reiseweg, der Reisegeschwindigkeit, der Tageszeit, dem Datum oder bestimmten benutzerdefinierten Präferenzen maßgeschneidert wird.
Framework zur Bereitstellung von Navigationsinhalten nach einem der Ansprüche 23 bis 27, bei welchem der Server dafür konfiguriert ist, Plug-in-Softwareobjekte für die Clientvorrichtung bereitzustellen, die der Clientvorrichtung zusätzliche Funktionalität verleihen.
Verfahren zur Anzeige von Inhalt von einer Inhaltsquelle in einer Clientvorrichtung, die ein Display aufweist, enthaltend die Schritte: Empfangen einer Anforderung von Inhalt von der Clientvorrichtung in einem entfernten Navigationsserver; Senden der Anforderung von dem Navigationsserver zu einem Server, der den Inhalt im Internet bereitstellt; Empfangen des Inhalts in dem Navigationsserver; Umformatieren des Inhalts als ein Plug-in-Softwareobjekt; und Senden des Plug-in-Softwareobjekts an die Clientvorrichtung; welches Plug-in-Softwareobjekt zur Ausführung auf der Clientvorrichtung programmiert ist, um Informationen auf der Anzeige der Clientvorrichtung aufzubereiten.
Verfahren nach Anspruch 29, bei welchem eine Positionsangabe der Clientvorrichtung mit der Anforderung von Inhalt am Server empfangen wird.
Verfahren nach Anspruch 29 oder 30, bei welchem das Plug-in-Softwareobjekt dafür konfiguriert ist, eine auf individuell abgestimmte Informationsanzeige zu erzeugen, wenn es in einer Clientvorrichtung ausgeführt wird.
Verfahren nach einem der Ansprüche 29 bis 31, bei welchem die Clientvorrichtung ferner eine Kartenanzeige enthält und das Plug-in-Softwareobjekt dafür konfiguriert ist, die Kartenanzeige zu ändern oder sie mit zusätzlichen Informationen zu ergänzen.
Verfahren nach einem der Ansprüche 29 bis 32, ferner enthaltend den Schritt des Sendens eines ersten Plug-in-Softwareobjekts von dem Server an die Clientvorrichtung, welches erste Plug-in-Softwareobjekt bei Ausführung in der Clientvorrichtung die Anforderung von Inhalt von dem Server erlaubt.
Verfahren nach Anspruch 33, bei welchem das erste Plug-in-Softwareobjekt bei der Ausführung auch eine Benutzerschnittstelle erzeugt, um die individuelle Benutzeranpassung der Inhaltsanforderung zu unterstützen, wenn dies von einer Internet-Inhaltsquelle gefordert wird.
Framework zur Bereitstellung von Navigationsinhalten, enthaltend: eine Clientvorrichtung, die eine Anzeige hat; und einen Server in Kommunikation mit der Clientvorrichtung und dem Internet; und Einrichtungen aufweisend, um auf Inhaltsquellen im Internet zuzugreifen; wobei die Clientvorrichtung so konfiguriert ist, dass bei der Benutzung Icons, die bevorzugte Inhaltsanforderungen darstellen, auf der Anzeige der Clientvorrichtung angezeigt werden, und die Auswahl eines Icons veranlasst, dass eine vorbestimmte Inhaltsanforderung an die Internet-Inhaltsquelle gesendet wird.
Framework zur Bereitstellung von Navigationsinhalten nach Anspruch 35, bei welchem die bevorzugte Inhaltsanforderungen darstellenden Icons in ein Icon-basiertes Menü der Clientvorrichtung integriert sind.
Framework zur Bereitstellung von Navigationsinhalten nach Anspruch 35 oder 36, bei welchem die Internet-Inhaltsquelle eine Datenbank, Suchmaschine oder eine Fernerfassungseinrichtung ist.
Framework zur Bereitstellung von Navigationsinhalten nach einem der Ansprüche 35 bis 37, bei welchem die Inhaltsanforderung eine Suchanfrage oder ein Suchbefehl ist.
System zur Bereitstellung einer Navigationsbenutzerschnittstelle in einer Clientvorrichtung, enthaltend: eine Clientvorrichtung, die eine Anzeige hat, ein Basis-Navigationsframework zur Bereitstellung von Basis-Navigationsfunktionalität, welches Basis-Navigationsframework eine festgelegte Gruppe von Plug-in-Softwareobjekten unterstützt; und einen Server in Kommunikation mit der Clientvorrichtung, der eine Zieldatenbank hat, die Einzelheiten von speziellen Zielen zusammen mit für jedes spezielle Ziel spezifischen Plug-in-Softwareobjekten enthält; wobei bei der Benutzung dann, wenn ein Benutzer in der Clientvorrichtung ein Ziel zur Routenwahl auswählt, die Clientvorrichtung von dem Server abfragt, ob das ausgewählte Ziel in der Zieldatenbank ist, und dann, wenn das ausgewählte Ziel in der Zieldatenbank ist, an den Client ein Plug-in-Softwareobjekt sendet, das Funktionalität zu der Clientvorrichtung hinzufügt.
Verfahren zur Bereitstellung einer Navigationsbenutzerschnittstelle in einer Clientvorrichtung, die eine Routenführung an spezielle Ziele ermöglicht, enthaltend die Schritte: Bezeichnen eines Ziels als ein spezielles Ziel; und dann, wenn der Benutzer Routenführung zu diesem Ziel anfordert, Bereitstellen einer zielspezifischen Benutzerschnittstelle auf der Clientvorrichtung.
Verfahren nach Anspruch 40, bei welchem die Clientvorrichtung mit einem zentralen Server verbunden ist, der eine Live-Datenbank spezieller Ziele enthält, ferner enthaltend den Schritt des Abfragens der Datenbank spezieller Ziele jedes Mal dann, wenn ein Benutzer Routenführung zu einem Ziel anfordert.
Verfahren nach Anspruch 40 oder 41, bei welchem die zielspezifische Benutzerschnittstelle für die Clientvorrichtung in Form eines oder mehrerer Software-plug-ins bereitgestellt wird.
Verfahren nach einem der Ansprüche 40 bis 42, bei welchem das spezielle Ziel ein Geschäftsbetrieb ist.
Verfahren nach einem der Ansprüche 40 bis 43, bei welchem die zielspezifische Benutzerschnittstelle ein Logo, Farben oder Werbung in Zusammenhang mit dem Ziel einschließt.
Framework zur Bereitstellung von Navigationsinhalten, enthaltend: eine erste Vorrichtung, die ein Basis-Navigationsframework zur Bereitstellung von Basis-Navigationsfunktionalität und eine Einrichtung zur Verbindung mit einem drahtlosen Kommunikationsnetz hat; wobei die erste Vorrichtung eine Benutzerschnittstelle hat, die es einem Benutzer der ersten Vorrichtung erlaubt, einen Ort anzugeben; und wobei bei der Benutzung die erste Vorrichtung automatisch erzeugte Informationen in Abhängigkeit von dem Ort zu einer entfernten Vorrichtung sendet, die eine Einrichtung zur Verbindung mit dem drahtlosen Kommunikationsnetz hat.
Framework zur Bereitstellung von Navigationsinhalten nach Anspruch 45, bei welchem die automatisch erzeugten Informationen in Form einer SMS- oder MMS-Mitteilung vorliegen.
Framework zur Bereitstellung von Navigationsinhalten nach Anspruch 45 oder 46, bei welchem die erste Vorrichtung eine Clientvorrichtung gemäß einem der Ansprüche 1 bis 4 oder 17 bis 20 ist.
Framework zur Bereitstellung von Navigationsinhalten nach einem der Ansprüche 45 bis 47, bei welchem die automatisch erzeugten Informationen Informationen über den angegebenen Ort oder Routenführungsinformationen enthalten, die angeben, wie der angegebene Ort zu erreichen ist.
Framework zur Bereitstellung von Navigationsinhalten nach einem der Ansprüche 45 bis 48, bei welchem die automatisch erzeugten Informationen Werbeinhalte für einen Geschäftsbetrieb enthalten.
Verfahren zur Bereitstellung von Navigationsinformationen für eine Vorrichtung, die mit einem Framework zur Bereitstellung von Navigationsinhalten verbunden ist, welches Framework zur Bereitstellung von Navigationsinhalten eine erste Vorrichtung enthält, die ein Basis-Navigationsframework zur Bereitstellung von Basis-Navigationsfunktionalität hat, sowie eine Einrichtung zur Verbindung mit einem drahtlosen Kommunikationsnetz, welches Basis-Navigationsframework eine festgelegte Gruppe von Plug-in-Softwareobjekten unterstützt, und einen Server, der Plug-in-Softwareobjekte für die erste Vorrichtung bereitstellen kann, welche Plug-in-Softwareobjekte zusätzliche Funktionalität für die erste Vorrichtung bieten, wenn sie in der ersten Vorrichtung ausgeführt werden; enthaltend die Schritte: Empfangen eines Plug-in-Softwareobjekts von dem Server in der ersten Vorrichtung; Erlauben, dass ein Benutzer der ersten Vorrichtung einen Ort angibt; und Senden von automatisch individuell angepassten Informationen in Abhängigkeit von dem Ort zu einer entfernten Vorrichtung, die eine Einrichtung zur Verbindung mit dem drahtlosen Kommunikationsnetz hat; wobei das Plug-in-Softwareobjekt automatisch auf der ersten Vorrichtung ausgeführt wird und es erlaubt, dass die zu der entfernten Vorrichtung gesendete Information individuell angepasst wird.
Verfahren nach Anspruch 50, bei welchem die automatisch erzeugten Informationen die Form einer SMS- oder MMS-Mitteilung vorliegen.
Verfahren nach Anspruch 50 oder 51, bei welchem die erste Vorrichtung eine Clientvorrichtung gemäß einem der Ansprüche 1 bis 4 oder 17 bis 20 ist.
Verfahren nach einem der Ansprüche 50 bis 52, bei welchem die automatisch erzeugten Informationen Informationen über den angegebenen Ort oder Routenführungsinformationen enthalten, die angeben, wie der angegebene Ort zu erreichen ist.
Verfahren nach einem der Ansprüche 50 bis 53, bei welchem die automatisch erzeugten Informationen ferner Werbeinhalte für einen Geschäftsbetrieb enthalten.