DE102014220734A1

DE102014220734A1 - Verfahren und vorrichtung für die handhabung von anwendungsauslöseereignissen

Info

Publication number: DE102014220734A1
Application number: DE201410220734
Authority: DE
Inventors: Perry Robinson MacNeille; Yimin Liu; Oleg Yurievitch Gusikhin; Joe Phillip Pierucci
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2013-10-16
Filing date: 2014-10-14
Publication date: 2015-04-16
Also published as: US9854061B2; CN104580347A; CN104580347B; US20150106474A1; US10715631B2; US20180115629A1

Abstract

Ein System umfasst einen Prozessor, der dafür konfiguriert ist, eine Rundsendung von fahrzeugbezogenen Statusänderungen zu abonnieren. Der Prozessor ist außerdem dafür konfiguriert, mindestens eine fahrzeugbezogene Statusänderung in der Rundsendung zu erkennen, die einen Anwendungsstart auslöst, und eine der erkannten fahrzeugbezogenen Statusänderung entsprechende Anwendung zu starten.

Description

Die veranschaulichenden Ausführungsformen betreffen allgemein ein Verfahren und eine Vorrichtung für die Handhabung von Anwendungsauslöseereignissen.
In einem fahrzeuginternen Computersystem (Vehicle Computing System, VCS)/Anwendungsprogrammierschnittstellen (Application Programming Interface, API) Framework können Dienste-Apps auf einem Mobilgerät ausgeführt, aber durch eine VCS-Mensch-Maschine-Schnittstelle gesteuert werden. Die API-Software verbindet das VCS mit dem Mobilgerät, um die Steuerung der Apps zu unterstützen. Das Starten von Mobil-Apps oder Apps auf dem VCS, in dem Fahrzeugnetzwerk oder in der Internet-Cloud unter Verwendung von API-Software, kann derzeit ein schwieriger und stark benutzerinitiierter Prozess sein, bei dem der Fahrer zuerst das VCS in einen Hilfsmodus versetzt, dann zu Mobilanwendungen wechselt, einen Befehl eingibt, um die verfügbaren Mobil-Apps aufzulisten, dann eine der Apps auswählt und diese dann gestartet wird. Der Betrieb kann so komplex sein, dass Fahrer des Fahrzeugs nie bemerken, dass es ihn gibt; er kann den Fahrer ablenken, er kann leicht fehlschlagen, was bewirkt, dass etwas schief geht, und er muss sehr vorsätzlich sein.
Fehlende Systeminitiative-Merkmale sind ebenfalls eine potenzielle Ursache für Blockierungen. So kann beispielsweise ein Halter sein Fahrzeug zur Reparatur zu einem Händler bringen und ein Erstausrüster (Original Equipment Manufacturer, OEM) würde den Halter gerne bitten, eine Qualitätsüberprüfung durchzuführen, bevor das nächste Ziel erreicht wird. Bei dem derzeitigen System müsste der Fahrer unter Umständen die Überprüfungsanwendung auf seinem Mobilgerät geladen haben, dann durch den Händler angewiesen werden, die vorstehenden Schritte zu durchlaufen, um die Überprüfungsanwendung zu starten.
EP2523436 betrifft ganz allgemein ein Mobilgerät, das eine Inhaltsauswahlvorrichtung für das Auswählen empfohlener Mobilanwendungen aus den für das Gerät verfügbaren Anwendungen auf Basis von mindestens: Kontextinformationen; benutzerdefinierten Präferenzen; und Kontextereignissen umfasst. Enthalten ist ein erster Benutzerschnittstellenbereich für das Anzeigen von empfohlenen Anwendungen, die durch die Inhaltsauswahlvorrichtung ausgewählt werden. Enthalten ist ferner ein zweiter Benutzerschnittstellenbereich für das Anzeigen von Anwendungen, die durch den Benutzer für einen gegebenen Kontext ausgewählt werden. Der erste Benutzerschnittstellenbereich kann gegebenenfalls gemäß der Benutzeraktivität und/oder auf Benutzeranfrage dynamisch aktualisiert werden. In einer Ausführungsform wählt die Inhaltsauswahlvorrichtung Mobilanwendungen aus den im Gerät gespeicherten Anwendungen und aus extern gespeicherten Anwendungen aus.
In einer ersten veranschaulichenden Ausführungsform umfasst ein System einen Prozessor, der dafür konfiguriert ist, eine Rundsendung von fahrzeugbezogenen Statusänderungen zu abonnieren. Der Prozessor ist außerdem dafür konfiguriert, mindestens eine fahrzeugbezogene Statusänderung in der Rundsendung zu erkennen, die einen Anwendungsstart auslöst und eine der erkannten fahrzeugbezogenen Statusänderung entsprechende Anwendung zu starten.
In einer zweiten veranschaulichenden Ausführungsform umfasst ein computerseitig implementiertes Verfahren das Abonnieren einer Rundsendung von fahrzeugbezogenen Statusänderungen. Das Verfahren beinhaltet außerdem das Erkennen von mindestens einer fahrzeugbezogenen Statusänderung in der Rundsendung, die einen Anwendungsstart auslöst, und das Starten einer der erkannten fahrzeugbezogenen Statusänderung entsprechenden Anwendung.
In einer dritten veranschaulichenden Ausführungsform speichert ein computerlesbares Speichermedium Anweisungen, die, wenn sie durch einen Prozessor ausgeführt werden, den Prozessor veranlassen, ein Verfahren auszuführen, welches das Abonnieren einer Rundsendung von fahrzeugbezogenen Statusänderungen beinhaltet. Das Verfahren beinhaltet außerdem das Erkennen von mindestens einer fahrzeugbezogenen Statusänderung in der Rundsendung, die einen Anwendungsstart auslöst, und das Starten einer der erkannten fahrzeugbezogenen Statusänderung entsprechenden Anwendung.
zeigt ein veranschaulichendes fahrzeuginternes Computersystem;
zeigt ein veranschaulichendes Beispiel für ein Mobilanwendungs-Framework;
zeigt ein veranschaulichendes Beispiel für einen Diensteinsatzprozess;
zeigt ein veranschaulichendes Beispiel für einen AppLink-Dienst-Verbindungsprozess;
zeigt ein veranschaulichendes Beispiel für einen GSM-Dienst-Verbindungsprozess;
zeigt ein veranschaulichendes Beispiel für einen Auslöseprozess;
zeigt ein veranschaulichendes Beispiel für weiteren Auslöseprozess;
zeigt ein veranschaulichendes Beispiel für noch einen weiteren Auslöseprozess;
zeigt ein veranschaulichendes Beispiel für ein Server-Netzwerk; und
zeigt einen veranschaulichenden Dateisynchronisierungs-Übergabeprozess.
Wie erforderlich werden hier ausführliche Ausführungsformen der vorliegenden Erfindung offenbart; es ist jedoch einzusehen, dass die offenbarten Ausführungsformen lediglich beispielhaft für die Erfindung sind, welche in verschiedenen und alternativen Formen ausgeführt werden kann. Die Abbildungen sind nicht notwendigerweise maßstabgetreu; einige Merkmale können übertrieben oder verkleinert sein, um Einzelheiten bestimmter Komponenten zu zeigen. Daher sind spezifische, hier offenbarte strukturelle und funktionale Einzelheiten nicht als einschränkend zu verstehen, sondern lediglich als repräsentative Grundlage, die dem Fachmann auf diesem Gebiet der Technik Anleitung bieten, um die vorliegende Erfindung auf vielfältige Weise einzusetzen.
veranschaulicht eine beispielhafte Blocktopologie für ein fahrzeuginternes Computersystem 1 (Vehicle-based Computing System, VCS) für ein Fahrzeug 31. Ein Beispiel für ein solches fahrzeuginternes Computersystem 1 ist das von der THE FORD MOTOR COMPANY hergestellte SYNC-System. Ein Fahrzeug, das mit einem fahrzeuginternen Computersystem ausgestattet ist, kann eine visuelle Frontend-Schnittstelle 4 aufweisen, die in dem Fahrzeug angeordnet ist. Der Benutzer kann möglicherweise mit der Schnittstelle interagieren, wenn sie bereitgestellt wird, beispielsweise mit einem berührungsempfindlichen Bildschirm. In einer anderen veranschaulichenden Ausführungsform erfolgt die Interaktion über Tastendruck, gesprochene Sprache und Sprachsynthese.
In der veranschaulichenden Ausführungsform 1, die in dargestellt ist, steuert ein Prozessor 3 mindestens einen Teil des Betriebs des fahrzeuginternen Computersystems. Indem der Prozessor innerhalb des Fahrzeugs bereitgestellt wird, erlaubt er die bordinterne Verarbeitung von Befehlen und Routinen. Ferner ist der Prozessor sowohl mit dem nichtpersistenten 5 und dem persistenten Speicher 7 verbunden. In dieser veranschaulichenden Ausführungsform ist der nichtpersistente Speicher ein Speicher mit wahlfreiem Zugriff (Random Access Memory, RAM) und der persistente Speicher ein Festplattenlaufwerk (Hard Disk Drive, HDD) oder ein Flash-Speicher.
Der Prozessor ist außerdem mit einer Anzahl verschiedener Eingänge ausgestattet, die dem Benutzer die Kommunikation mit dem Prozessor ermöglichen. In dieser veranschaulichenden Ausführungsform werden ein Mikrofon 29, ein Zusatzgeräte-Eingang (Aux) 25 (für Eingang 33), ein „Universal Serial Bus“-Eingang (USB) 23, ein „Global Positioning System“-Eingang (GPS) 24 und ein BLUETOOTH-Eingang 15 bereitgestellt. Ein Eingangswahlschalter 51 wird ebenfalls bereitgestellt, um dem Benutzer zu ermöglichen, zwischen verschiedenen Eingängen zu wechseln. Eingaben über das Mikrofon und den Auxiliary-Anschluss werden durch einen Wandler 27 von analog zu digital umgesetzt, bevor sie an den Prozessor weitergegeben werden. Auch wenn dies hier nicht dargestellt ist, können zahlreiche Fahrzeugkomponenten und Hilfskomponenten, die in Kommunikationsverbindung mit dem VCS stehen, ein Fahrzeugnetzwerk (beispielsweise, jedoch nicht beschränkt auf einen „Controller Area Network“-Bus (CAN-Bus)) verwenden, um Daten an das und von dem VCS (oder Komponenten davon) weiterzuleiten.
Ausgänge zum System können eine visuelle Anzeige 4 und einen Lautsprecher 13 oder einen Stereosystemausgang umfassen, sind jedoch nicht hierauf beschränkt. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt sein Signal von dem Prozessor 3 über einen Digital/Analog-Wandler 9. Die Ausgabe kann auch an ein entferntes BLUETOOTH-Gerät wie ein persönliches Navigationsgerät (Personal Navigation Device, PND) 21 oder ein USB-Gerät wie ein Fahrzeugnavigationsgerät 60 entlang den bidirektionalen Datenströmen erfolgen, die bei 19 bzw. 21 gezeigt werden.
In einer veranschaulichenden Ausführungsform verwendet das System 1 einen BLUETOOTH-Sendeempfänger 15, um mit einem ortsungebundenen Gerät, einem sog. Nomadic Device (ND), 53 eines Benutzers (z. B. einem Mobiltelefon, Smartphone, Personal Digital Assistant (PDA) oder einem anderen Gerät mit drahtloser Netzwerkfernanbindung) zu kommunizieren 17. Das ortsungebundene Gerät kann dann verwendet werden, um mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59, beispielsweise durch Kommunikation 55 mit einem Mobilfunkmast 57. In manchen Ausführungsformen kann der Mast 57 ein WiFi-Zugangspunkt sein.
Eine beispielhafte Kommunikation zwischen dem ortsungebundenen Gerät und dem BLUETOOTH-Sendeempfänger wird durch das Signal 14 dargestellt.
Eine Kopplung eines ortsungebundenen Geräts 53 und des BLUETOOTH-Sendeempfängers 15 kann über eine Taste 52 oder eine ähnliche Eingabe veranlasst werden. Entsprechend wird die zentrale Verarbeitungseinheit (Central Processing Unit, CPU) angewiesen, dass der bordeigene BLUETOOTH-Sendeempfänger mit einem BLUETOOTH-Sendeempfänger in einem ortsungebundenen Gerät gekoppelt wird.
Daten können zwischen der CPU 3 und dem Netzwerk 61 übertragen werden, beispielsweise mit einem Datenplan, Daten über Sprache (Data-over-Voice) oder MFV-Tönen (Dual-Tone Multi-Frequency, DTMF), wie sie mit dem ortsungebundenen Gerät 53 verknüpft sind. Alternativ kann es wünschenswert sein, ein bordeigenes Modem 3 einzuschließen, das eine Antenne 61 besitzt, um Daten zwischen der CPU 3 und dem Netzwerk 61 über das Sprachband zu übertragen 16. Das ortsungebundene Gerät 53 kann dann verwendet werden, um mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59, beispielsweise durch Kommunikation 55 mit einem Mobilfunkmast 57. In manchen Ausführungsformen kann das Modem 63 eine Kommunikationsverbindung zu dem Mast 57 herstellen 20, um mit dem Netzwerk 61 zu kommunizieren. Als nichteinschränkendes Beispiel kann das Modem 63 ein USB-Mobilfunkmodem sein und kann die Kommunikation 20 eine Mobilfunkkommunikation sein.
In einer veranschaulichenden Ausführungsform ist der Prozessor mit einem Betriebssystem ausgestattet, das eine API für die Kommunikation mit der Modemanwendungssoftware aufweist. Die Modemanwendungssoftware kann auf ein eingebettetes Modul oder eine eingebettete Firmware in dem BLUETOOTH-Sendeempfänger zugreifen, um die drahtlose Kommunikationsverbindung mit einem entfernten BLUETOOTH-Sendeempfänger (wie er beispielsweise in einem ortsungebundenen Gerät zu finden ist) herzustellen. Bluetooth ist ein Teilbereich der IEEE 802 PAN(Personal Area Network, persönliches Netzwerk)-Protokolle. IEEE 802 LAN(Local Area Network, Ortsnetzwerk)-Protokolle beinhalten WiFi und weisen erhebliche Kreuzfunktionalitäten mit IEEE 802 PAN auf. Beide eignen sich für die drahtlose Kommunikation in einem Fahrzeug. Weitere Kommunikationsmittel, die in diesem Bereich eingesetzt werden können, sind die optische Freiraumkommunikation (etwa IrDA) und nichtstandardisierte Infrarot(IR)-Fernbedienungsprotokolle.
In einer weiteren Ausführungsform weist das ortsungebundene Gerät 53 ein Modem für die Sprachband- oder Breitband-Datenkommunikation auf. In der Daten-über-Sprache-Ausführungsform kann ein Verfahren namens Frequenzmultiplex (Frequency Division Multiplexing) implementiert sein, wenn der Besitzer des ortsungebundenen Geräts über das Gerät sprechen kann, während gleichzeitig Daten übertragen werden. Zu anderen Zeiten, wenn der Besitzer das Gerät gerade nicht nutzt, kann die Datenübertragung die gesamte Bandbreite (300 Hz bis 3,4 kHz in einem Beispiel) belegen. Während das Frequenzmultiplexverfahren für die analoge Mobilfunkkommunikation zwischen dem Fahrzeug und dem Internet gängig sein mag und auch weiterhin verwendet wird, ist es in weiten Bereichen durch Hybride mit Codemultiplex-(Code Domain Multiple Access, CDMA), Zeitmultiplex-(Time Domain Multiple Access, TDMA), Raummultiplex-(Space Domain Multiple Access, SDMA)Verfahren für die digitale Mobilfunkkommunikation ersetzt worden. Dies sind alles ITU IMT-2000(3G)-konforme Standards, und sie bieten Datenraten von bis zu 2 Mbit/s für stationäre oder umhergehende Benutzer bzw. 365 kbit/s für Benutzer in einem fahrenden Fahrzeug. 3G-Standards werden heute zunehmend durch IMT-Advanced (4G) ersetzt, das Benutzern in einem Fahrzeug 100 Mbit/s und stationären Benutzern 1 Gbit/s bietet. Wenn der Benutzer über einen Datenplan zu seinem ortsungebundenen Gerät verfügt, erlaubt der Datenplan möglicherweise Breitbandübertragung, und das System könnte eine erheblich größere Bandbreite nutzen (und damit die Datenübertragung beschleunigen). In noch einer weiteren Ausführungsform wird das ortsungebundene Gerät 53 durch ein (nicht dargestelltes) Mobilfunkgerät ersetzt, das in dem Fahrzeug 31 installiert ist. In noch einer anderen Ausführungsform kann das ND 53 ein drahtloses Ortsnetz(LAN)-Gerät sein, das beispielsweise (und ohne Einschränkung) über ein 802.11g-Netzwerk (d. h. WiFi) oder ein WiMax-Netzwerk kommunizieren kann.
In einer Ausführungsform können ankommende Daten durch das ortsungebundene Gerät per Daten-über-Sprache oder Datenplan über den bordeigenen BLUETOOTH-Sendeempfänger und in den internen Prozessor 3 des Fahrzeugs weitergeleitet werden. Im Fall bestimmter temporärer Daten, beispielsweise, können die Daten auf der HDD oder einem anderen Speichermedium 7 so lange gespeichert werden, bis die betreffenden Daten nicht mehr benötigt werden.
Zusätzliche Quellen, die mit dem Fahrzeug kommunizieren können, beinhalten ein persönliches Navigationsgerät 54, das beispielsweise einen USB-Anschluss 56 und/oder eine Antenne 58 besitzt, ein Fahrzeugnavigationsgerät 60, das einen USB-62 oder sonstigen Anschluss besitzt, ein bordeigenes GPS-Gerät 24 oder ein (nicht dargestelltes) entferntes Navigationssystem, das an das Netzwerk 61 angebunden ist. USB ist eines aus einer Klasse von seriellen Netzwerkprotokollen. IEEE 1394 (FireWire), die seriellen EIA(Electronics Industry Association)-Protokolle, IEEE 1284 (Centronics Port), S/PDIF (Sony/Philips Digital Interconnect Format) und USB-IF (USB Implementers Forum) bilden das Rückgrat der seriellen Standards für die Gerät-zu-Gerät-Kommunikation. Die meisten dieser Protokolle können sowohl für die elektrische als auch für die optische Kommunikation implementiert werden.
Ferner könnte die CPU in Kommunikationsverbindung mit einer Vielzahl anderer Zusatzgeräte 65 stehen. Diese Geräte können über einen drahtlosen 69 oder einen drahtgebundenen 69 Anschluss angeschlossen sein. Zusatzgeräte 65 können persönliche Medienwiedergabegeräte, drahtlose medizinische Geräte, tragbare Computer und dergleichen sein, sind jedoch nicht auf diese beschränkt.
Ebenso, oder alternativ, könnte die CPU mit einem fahrzeuginternen Drahtlos-Router 73 verbunden sein, beispielsweise mithilfe eines WiFi-Sendeempfängers 71. Dies könnte es der CPU erlauben, sich mit entfernten Netzwerken in Reichweite des lokalen Routers 73 zu verbinden.
Zusätzlich zur Ausführung beispielhafter Prozesse durch ein fahrzeuginternes Computersystem in einem Fahrzeug können die beispielhaften Prozesse auch von einem Computersystem ausgeführt werden, das mit einem fahrzeuginternen Computersystem in Kommunikationsverbindung steht. Ein derartiges System kann ein drahtloses Gerät (z. B., jedoch ohne Einschränkung, ein Mobiltelefon) oder ein entferntes Computersystem (z. B., jedoch ohne Einschränkung, einen Server), das über das drahtlose Gerät angeschlossen ist, beinhalten, ist jedoch nicht hierauf beschränkt. Zusammenfassend können derartige Systeme als fahrzeugassoziierte Computersysteme (Vehicle Associated Computing Systems, VACS) bezeichnet werden. In bestimmten Ausführungsformen können bestimmte Komponenten des VACS bestimmte Teile eines Prozesses ausführen, abhängig von der jeweiligen Implementierung des Systems. Wenn beispielsweise, jedoch ohne Einschränkung, ein Prozess einen Schritt umfasst, Informationen an ein gekoppeltes drahtloses Gerät zu senden oder von diesem zu empfangen, dann ist es wahrscheinlich, dass das drahtlose Gerät den Prozess nicht ausführt, da das drahtlose Gerät schwerlich Informationen in Kommunikation mit sich selbst „sendet und empfängt“. Ein Durchschnittsfachmann auf diesem Gebiet der Technik wird verstehen, wann es unangemessen ist, ein bestimmtes VACS in einer gegebenen Lösung einzusetzen. In allen Lösungen wird davon ausgegangen, dass mindestens das fahrzeuginterne Computersystem (VCS), das im Fahrzeug selbst angeordnet ist, in der Lage ist, die beispielhaften Prozesse auszuführen.
Es gibt einige andere Mechanismen für das Starten einer Anwendung, die als Teil desselben Problems berücksichtigt werden sollten, da zu einem gegebenen Zeitpunkt nur eine Mobilanwendung die Mensch-Maschine-Schnittstelle (HMI) des SYNC (bei dem es sich um ein nichteinschränkendes Beispiels eines VCS handelt) aktiv nutzen kann, und es kann erforderlich sein, den Zugang zu der HMI zu verwalten, wenn mehrere Mobil- und andere Apps gleichzeitig ausgelöst werden. Einige dieser Mechanismen beinhalten das Starten einer Mobilanwendung von einem fahrzeuginternen Computersystem wie vorstehend beschrieben, gestartet durch SYNC, gestartet durch eine Anwendung auf dem Mobilgerät oder gestartet von der Internet Cloud/dem Server. Mobil-Apps auf dem Telefon, die unter Umständen gute Kandidaten für das Auslösen von AppLink (bei dem es sich um ein nichteinschränkendes Beispiel einer API handelt) Mobil-Apps darstellen, sind die Telefonanwendung (damit die Anwendung mit einem Telefonanruf gestartet werden kann), die SMS-Anwendung (damit eine AppLink-Mobilanwendung mit einer Textnachricht gestartet werden kann), eine Sprachanwendung (damit eine AppLink-Mobilanwendung durch gesprochene Befehle gestartet werden kann), eine Aktivität (die eine Aktivierung über den Berührungsbildschirm ermöglicht) oder eine kontextgesteuerte Anwendung, welche das Starten einer Anwendung mit Regeln auslösen könnte, die auf Kontextbedingungen basieren, beispielsweise einem Sperrgebiet (Geofence) oder einer Wetterbedingung.
Innerhalb des AppLink Mobilgeräte-Frameworks wäre es auch möglich, eine AppLink-Anwendung auszulösen, wenn AppLink nicht verbunden ist, beispielsweise wenn der Fahrer das Fahrzeug parkt und verlässt. Die Mobilanwendung könnte in diesem Fall über ähnliche Merkmale verfügen, aber sie könnte auch anstelle der SYNC HMI die Mobilgeräte-HMI verwenden. Bei nicht verbundenem AppLink (in einem Abstand, der größer ist als der Bluetooth-Bereich), kann es schwierig sein, Auslöser von den Fahrzeugcomputern oder von SYNC-Befehlen zu empfangen, es sei denn das Fahrzeug ist eingeschaltet und mit dem Internet verbunden; in diesem Fall können die AppLink-Apps über das Internet ausgelöst werden. So könnte ein Benutzer beispielsweise zu seinem Auto zurückkehren und feststellen, dass er sein Mobiltelefon verloren hat. Der Benutzer könnte das Fahrzeug starten und eine Anwendung auf dem Telefon ausführen, welche die GPS-Position des Telefons auf einer Karte im Fahrzeug anzeigt. Die Anwendung kann sogar ein paar Marketing-Fragen als Gegenleistung für das Auffinden des Telefons stellen.
Wenn eine Mobilanwendung ausgelöst wird, können im Allgemeinen einige Informationen aus dem Internet benötigt werden, einschließlich der Eingabedaten für die Anwendung und vielleicht die Anwendung selbst. Drahtlose Internetverbindungen zu fahrenden Fahrzeugen neigen dazu, langsam und unzuverlässig zu sein, was ein Rücksetzen erfordert, wenn die Signalverbindung unterbrochen wird oder eine Übergabe zwischen Servern erfolgt. Die Eingabedateien können groß sein, insbesondere wenn es sich um Mediendateien handelt. Es kann daher am besten sein, sich nicht auf Streaming-Daten in Echtzeit zu verlassen; stattdessen können so viele Eingabedaten wie möglich in das Dateisystem des Mobilgeräts heruntergeladen werden, bevor die Mobilanwendung ausgeführt wird. Um die Drahtlos-Bandbreite zu reduzieren, können teilweise heruntergeladene Dateien vervollständigt und nicht ersetzt werden, und veraltete Dateien können, sofern möglich, korrigiert bzw. aktualisiert und nicht ersetzt werden. Der Prozess entspricht mehr einer Synchronisation als einem Dateitransfer. Das Auslösen einer Anwendung ist potenziell ein dreistufiger Prozess: Anwendung herunterladen, Eingabedaten herunterladen, Anwendung ausführen.
zeigt ein veranschaulichendes Beispiel für ein Anwendungsauslösesystem. In diesem veranschaulichenden Beispiel enthält ein Mobilgeräte-Framework 201 verschiedene Module, welche die Aktivierung von Anwendungen ermöglichen. Verschiedene Auslöser, welche automatisch initiiert werden können (beispielsweise durch das Auftreten eines Ereignisses) oder durch Benutzeraktionen initiiert werden können (beispielsweise, aber nicht beschränkt auf eine Anwendungsanforderung), werden durch das Mobilgeräte-Framework empfangen. Das Framework handhabt die Auslöser entsprechend und startet oder aktiviert gegebenenfalls eine entsprechende Anwendung.
In diesem veranschaulichenden Beispiel stellt ein AppLink-Dienst 207 Verbindungen zu einem VCS her und verwaltet und schließt diese Verbindungen. Der Dienst kann zum Boot-Zeitpunkt gestartet werden, wenn Bluetooth und USB aktiv werden. Er kann versuchen, VCS-Module, die sich im Bluetooth-Bereich befinden oder mit einem VCS USB-Gerät verbunden sind, zu erkennen, zu koppeln und zur Autorisierung zu verbinden. Der Dienst kann Nachrichten an das Betriebssystem senden, wenn die Verbindung geöffnet oder geschlossen wird.
Das Framework beinhaltet außerdem einen GSM-Dienst 223. Dieser Dienst richtet Verbindungen zu Ressourcen im Internet ein und erhält diese Verbindungen aufrecht. Die Anwendung startet, wenn die GSM-Verbindung (drahtlose zellulare Breitbandverbindung) bei Systemstart gestartet wird. Der Dienst signalisiert dem Betriebssystem, wann die Verbindung besteht und wann diese unterbrochen ist. Angemeldete Anwendungen empfangen die Signale und reagieren hierauf. Anwendungen können unterschiedlich arbeiten, wenn eine Verbindung unterbrochen wird, aber ein Dateisynchronisationsdienst 221 trägt zur Minderung dieses Problems bei.
Wenn kein GSM-Dienst auf dem Mobilgerät vorliegt, kann das GSM-Modul ein GSM-Modem auf dem VCS nutzen, wobei die Verbindung beispielsweise über Bluetooth, WiFi, USB etc. hergestellt werden kann. Ist kein GSM-Modem für das Mobilgerät verfügbar, dann können die mobilen AppLink-Anwendungen in einem Nicht-GSM-Modus ausgeführt werden, wobei Daten verwendet werden, die auf andere Weise, durch den Synchronisationsdienst, synchronisiert werden.
Eine Webdienstermittlung und ein Kommunikationsdienst 209 können sich bei Dienstermittlungs- und Kommunikationssystemen für Inhaltbereitstellungsnetze in der Internet-Cloud anmelden. Der Dienst kann Routeninformationen von einem Veröffentlichungs-/Abonnement-System 205 empfangen, um die Internet-Ermittlungssysteme beim Verfolgen der Fahrzeugbewegungen durch ein Inhaltbereitstellungsnetzwerk zu unterstützen.
Der Veröffentlichungs-/Abonnement-Dienst 205 beinhaltet nachrichtenorientierte Middleware, die frei als Veröffentlichungs-/Abonnement-System bezeichnet wird. Das System startet, wenn der AppLink-Dienst startet, und verbindet eine Anwendung in dem Framework unter Verwendung von Nachrichten mit Computern des Fahrzeugsystems. Der Dienst filtert Nachrichten und wendet Sicherheitsrichtlinien in beiden Richtungen an, aber er leitet auch Nachrichten weiter, die eine Anwendung in dem Framework oder dem VCS angefordert hat, was das erforderliche Kommunikationsvolumen stark reduzieren kann.
Abonnierte Nachrichten können durch mehrere Mechanismen bereitgestellt werden. Beispielsweise in einem Sofortmodus, in dem die Nachrichten direkt bei Empfang an eine abonnierende Anwendung weitergeleitet werden, in einem Warteschlangenmodus, in dem die Nachrichten eine Warteschlange füllen, die von einem Teilnehmer bei Bedarf ausgelesen werden kann, etc. Im Allgemeinen kann es viele Teilnehmer für eine einzelne Nachricht geben, aber es kann auch nur einen Veröffentlicher geben. Dies ist nicht immer der Fall, aber recht gängig. Das Veröffentlichungs-/Abonnement-System wendet Zeit- und Veröffentlichungsstempel auf die Nachrichten an, wodurch eine einheitliche Zeitbasis für das System bereitgestellt wird. Es ist außerdem für Anwendungen im Internet möglich, Nachrichten in dem Veröffentlichungs-/Abonnement-System zu abonnieren, aber im Allgemeinen mit strengeren Sicherheitsrichtlinien.
Da die Übertragungsraten zu Fahrzeugen im drahtlosen Internet ziemlich variabel sind, kann es sein, dass die für Desktopsysteme entwickelten Strategien für das Streamen von Daten in einer mobilen Umgebung nicht gleich gut arbeiten. Ferner verfügen Mobilgeräte über einen großzügig bemessenen Datenspeicher. Der Dateisynchronisationsdienst 221 stellt die Parallelität zwischen den Dateien des Mobilgeräts und den Dateien in der Cloud sicher, und in dieser Hinsicht ist dieser Dienst vergleichbar mit anderer Dateisynchronisationssoftware. Es gibt außerdem einige zusätzliche Herausforderungen bei Mobil-Apps, beispielsweise das Synchronisieren in einem fahrenden Fahrzeug, bei dem Übergaben zwischen Internet-Servern erforderlich sind, und das Synchronisieren bei nicht bestehender Verbindung zum Fahrzeug an WiFi-Hotspots, über eine USB-Verbindung zu einem Desktop-Computer, USB-Laufwerke und Bluetooth-Verbindungen zum Internet.
Ein Medienwiedergabedienst 203 streamt Audiodaten von dem Medienwiedergabegerät des Mobilgeräts an ein VCS über eine drahtlose oder drahtgebundene Verbindung und dann an ein fahrzeuginternes Audiosystem. Wenn die Verbindung zu dem VCS 225 nicht verfügbar ist, können die Medien an die Mobilgeräteausgabe gestreamt werden, entweder Lautsprecher oder einen Mobilgeräte-Audioausgang. Das Mobilgerät kann stummgeschaltet werden; in diesem Fall gibt es unter Umständen keine Audioausgabe. Mobilanwendungen können die Art der Audioausgabe erkennen und anpassen.
Das Mobilgerät kann eine Berührungsanzeige 219 als Aktivität aufweisen, die mit der Anzeige interagiert, um Auslösedienstmerkmale zu unterstützen. In mindestens einer Ausführungsform kann nur eine Aktivität mit einer Anzeige auf dem Mobilgerät gekoppelt sein, und die meisten Mobilgeräte verfügen nur über eine Anzeige. Daher wird diese Aktivität im Allgemeinen durch den Benutzer aktiviert und schließt andere Aktivitäten aus, während diese Aktivität ausgeführt wird.
Ein Auslösedienst 211 bestimmt, wann die beste Zeit für das Ausführen eines Anwendungsdienstes oder einer Dateisynchronisation ist. Zuerst ermittelt der Dienst eine Anwendung, die für den Fahrer wiedergegeben werden sollte. Die Auswahl der Anwendung basiert auf verschiedenen Faktoren, einschließlich, aber nicht beschränkt auf, Verfügbarkeit, Benutzerpräferenzen, Medienanbieter, Anwendungsanbieter etc. Um eine Anwendung auszulösen, fordert der Dienst die Dateisynchronisation an, um sicherzustellen, dass der Anwendungscode auf dem Mobilgerät auf dem aktuellen Stand ist; dann beantragt der Dienst, dass die ausgewählten Eingabedaten synchronisiert werden, um sicherzustellen, dass die Anwendung über die richtige Version aller Eingabedaten verfügt. Wenn dies erfolgt ist, wartet der Prozess, bis ein geeigneter Zeitpunkt gefunden ist, um die Anwendung zu starten.
Eine entsprechende Zeitsteuerung kann durch verschiedene Faktoren vorgegeben werden. Diese umfassen, sind aber nicht hierauf beschränkt, voreingestellte Auslöser (beispielsweise eine Ölwechselerinnerung), Zahlungs-/Werbungsauslöser (beispielsweise Fahrzeugaufrüstungen, Leasingzeit-Ende), Geofence-Auslöser, adaptive Auslöser, Arbeitslasthemmer, pragmatische Sequenzierung, Höflichkeitshemmer, Verfügbarkeitssequenzierung etc. Die Anwendung kann eine Anwendung beinhalten, die in der Lage ist, durch einen Transaktionsdialog, beispielsweise über eine HMI, mit einer Person zu interagieren. Die Anwendung kann sich an aktuelle Bedingungen anpassen, beispielsweise wann die HMI verfügbar ist, und kann über das Veröffentlichungs-/Abonnement-System mit dem VCS und Fahrzeugcomputern, Sensoren und Stellgliedern kommunizieren. Außerdem kann die Anwendung auf Daten von Internet-Servern und vom Dateisystem zugreifen.
Einige nichteinschränkende Beispiele für Auslösersituationen werden hier besprochen, aber hierbei handelt es sich nur um beispielhafte Situationen, die nicht dazu bestimmt sind, den Geltungsbereich der Erfindung einzuschränken. Ein Beispiel für einen voreingestellten Auslöser beinhaltet einen Händlerwartungsauslöser. Wenn beispielsweise ein Händler eine Wartung durchführt, wird ein Auslöser in einem der Fahrzeugcomputer eingestellt, der aktiviert wird, wenn die Wartung wiederholt werden sollte. Wenn beispielsweise ein Ölwechsel fällig ist, kann der Mechaniker einen Auslöser einstellen, der zu einem empfohlenen Zeitpunkt eine Benachrichtigung an den Fahrer für einen weiteren Wechsel ausgibt. Auch könnte eine Überprüfung auf Basis eines voreingestellten Auslösers durchgeführt werden, beispielsweise wenn seit der letzten Wartung eine bestimmte Zeit verstrichen ist oder ein bestimmter Kilometerstand überschritten wurde. Fahrer können ebenfalls Auslöser voreinstellen, beispielsweise um eine Newsreader-Anwendung wiederzugeben, wenn der Fahrer allein im Fahrzeug ist.
Bestimmte Zahlungsfälligkeitstermine können ebenfalls eine Anwendung auslösen. So könnte beispielsweise ein kraftfahrzeugbezogener Fälligkeitstermin eine Zahlungserinnerung auslösen. Fahrzeuge, deren Leasingvertrag nahezu ausgelaufen ist, oder die bereits eine Zeit im Einsatz sind, können über eine Erinnerung verfügen, die an den Kauf eines neuen Fahrzeugs gekoppelt ist, welches in dieser Erinnerung präsentiert wird. Geofences können ebenfalls Anwendungen oder die Aktivierung von Werbung auslösen, beispielsweise auf Basis der Nähe zu einem Standort.
Da Anwendungen in einer Fahrzeugumgebung oder auf einem tragbaren Gerät ausgeführt werden können, ist es unter Umständen nützlich, über Auslöser zu verfügen, die sich für Fahrzeug- und Handbetrieb-Interaktionen anpassen lassen. Außerdem kann es passieren, dass Auslöseereignisse auftreten, wobei aber aufgrund von Arbeitslasteinschränkungen des Fahrers (z. B. starker Verkehr) die entsprechenden Anwendungsstarts für einige Zeit verzögert werden können. Auslöser können auch pragmatisch sequenziert werden, basierend auf dem Auftreten von bekannten oder vermuteten Ereignissen. So kann beispielsweise das Vorbeifahren an einem Restaurant eine Werbung auslösen. Das Einfahren in die Restaurantzone kann eine Speisekartenanwendung auslösen. Das Verlassen des Restaurants kann eine Umfrage zu dem Restaurant auslösen. Es wäre jedoch nicht zweckmäßig, die Umfrage durchzuführen, bevor gegessen wurde; der Prozess würde somit in diesem Fall sicherstellen, dass der Benutzer den Parkplatz des Restaurants betreten hat, eine angemessene Zeit abgewartet worden ist (die dem Einnehmen einer Mahlzeit entspricht) und der Parkplatz wieder verlassen wurde. Dies würde anzeigen, dass Speisen bestellt und konsumiert wurden, so dass es angebracht ist, eine Umfrage auszulösen.
Anwendungen können auch der Höflichkeit halber vorübergehend angehalten werden, beispielsweise wenn ein Gespräch in dem Fahrzeug geführt wird. Anwendungen können auch nach Verfügbarkeit sequenziert werden. Bei dieser Sequenzierung wird mindestens ein Teil eines Blocks von erforderlichen Medien heruntergeladen, bevor eine Anwendung gestartet wird. Wenn eine ausreichende Medienmenge vorliegt, wird die Anwendung angeboten. Dies wird als Verfügbarkeitssequenzierung bezeichnet.
Anwendungen können, ohne jedoch hierauf beschränkt zu sein, digitale Direktmarketing-Anwendungen (DDM) beinhalten. Solche Anwendungen können Auslöser nutzen, um Benutzern zu geeigneten Zeiten Werbung zu präsentieren, wodurch sich die Wahrscheinlichkeit einer Reaktion erhöht. Andere Anwendungen sind ebenfalls auslösbar und beinhalten nahezu jede beliebige Anwendung, die in der jeweiligen Situation geeignet sein könnte.
zeigt ein veranschaulichendes Beispiel für einen Diensteinsatzprozess. In diesem veranschaulichenden Beispiel beginnt der Prozess mit einer Boot-Prozedur 202, die eine Reihe von Modulen initialisiert. Der Boot-Prozess beinhaltet die Einrichtung eines Dateisystems 204. Dieser Prozess registriert eine beliebige Anzahl von Diensten, die von dem Mobilanwendungs-Framework 206 genutzt werden. Dies hilft bei der Überprüfung hinsichtlich des Vorhandenseins und der Nutzbarkeit gewünschter Dienste.
So prüft der Prozess in dieser Ausführungsform beispielsweise, ob ein GSM-Dienst verfügbar ist 208. Das Vorhandensein des GSM-Dienstes wird anzeigen, dass das mobile Framework bei Bedarf in der Lage sein wird, Zellulardienste zu nutzen. Die Cloud kann auch eine Reihe von Anwendungsdiensten bereitstellen, beispielsweise, aber nicht beschränkt auf, Werbungen, Coupons, Umfragen, Transferinformationen, Notdienste und Internetdienste.
Wenn GSM-Dienste verfügbar sind 208, registriert der Prozess den GSM-Dienst 210. Der GSM-Dienst wird gestartet, nachdem der Dienst registriert wurde 214. Außerdem können auch AppLink-Dienste erkannt 212 werden. AppLink-Dienste können das mobile Framework mit dem Fahrzeug verbinden und können beispielsweise einen Zugang zu einem Fahrzeug-BUS (beispielsweise einem CAN BUS), einem Medien-BUS, einer HMI etc. beinhalten. Wenn AppLink-Dienste verfügbar sind, kann der Prozess den AppLink-Dienst 216 registrieren und den AppLink-Dienst 218 starten.
zeigt ein veranschaulichendes Beispiel für einen AppLink-Dienst-Verbindungsprozess. Dieser Prozess erlaubt es dem Mobilanwendungs-Framework, den AppLink-Dienst zu nutzen, um Auslöser von dem VCS zu empfangen. Der AppLink-Dienst stellt eine Verbindung zu dem VCS 301 her und sendet eine Verbindungsnachricht 303 an das Betriebssystem.
Sobald die Verbindung besteht, meldet sich der Prozess bei dem Veröffentlichungs-/Abonnement-Dienst an. Dann kann der Veröffentlichungs-/Abonnement-Dienst gestartet werden 305. Der Veröffentlichungs-/Abonnement-Dienst ermöglicht es Anwendungen und Prozessen, Daten auszutauschen. Auslöser und andere Informationen können an den Veröffentlichungsteil des Dienstes ausgegeben werden. Abonnierende Entitäten können dann relevante Informationen, die an den Dienst ausgegeben werden, empfangen.
So interessiert sich beispielsweise eine Tankanwendung unter Umständen nur für Informationen, welche die verfügbare Kraftstoffmenge betreffen. Wenn die Kraftstoffanlage eines Fahrzeugs kraftstoffbezogene Informationen an den Veröffentlichungsdienst ausgegeben hat, kann die Kraftstoffanwendung ein Abonnent dieser Informationen sein. Andere Informationen würden von der Tankanwendung ignoriert, aber veröffentlichte Informationen, welche die verfügbare Kraftstoffmenge betreffen, würden an die abonnierende Tankanwendung gesendet.
Der den Veröffentlichungsdienst ausführende Prozess kann Daten von einer beliebigen Entität empfangen, die Daten an den Veröffentlichungsdienst 307 ausgeben möchte. Diese Daten können nahezu unbegrenzt sein, aber im Allgemeinen handelt es sich um Daten, die eine andere abonnierende Entität nützlich findet. Die empfangenen Daten können dann veröffentlicht 309 werden. In diesem Beispiel meldet sich der Prozess für einen Auslösedienst 311 bei dem Veröffentlichungsdienst an, so dass der Auslösedienst veröffentlichte Daten empfangen kann, die ein Auslöseereignis bilden können.
zeigt ein veranschaulichendes Beispiel für einen GSM-Dienst-Verbindungsprozess. Dieser Dienst stellt die Anbindung und einen Ferndienstezugang zu dem Framework bereit. Über den GSM-Dienst können Dateien synchronisiert und Internet-Auslöseereignisse realisiert werden. Wenn ein GSM-Dienst verfügbar ist, stellt der GSM-Dienst eine Verbindung zu dem Framework her und sendet eine GSM-Verbindungsnachricht an das Betriebssystem (OS) 401. Der Prozess kann auch eine Webdienstermittlung 403 starten.
Die Webdienstermittlung kann verwendet werden, um verfügbare Dienste zur Nutzung durch das Framework zu ermitteln. Dies kann eine beliebige Anzahl von cloud-basierten Diensten beinhalten. Der Prozess kann die Webdienstermittlung auch nutzen, um sich bei Internetdienstermittlungssystemen 405 anzumelden. Der Prozess kann auch die Dateisynchronisation 407 einleiten.
Wenn es zu synchronisierende Dateien gibt, kann der Prozess auch die Dateisynchronisation starten 407. Solange es noch zu synchronisierende Dateien gibt, kann der Synchronisationsprozess fortgesetzt werden 409. Sobald alle erforderlichen Dateien synchronisiert 411 worden sind, kann der Prozess Nachrichten von den Internetdiensten 413 empfangen. Diese Nachrichten können als Auslöser fungieren, in ähnlicher Weise wie die Fahrzeugereignisse. Dienste können über das Internet ausgelöst werden, beispielsweise durch eine Benutzerfernanfrage. Wenn ein Internetdienstauslöser existiert 415, kann der Prozess eine Auslösenachricht an das Auslöser-Handhabungsmodul senden und dann die entsprechende Aktion durch das Framework vornehmen. Die Internetdienstauslöser können auf Wunsch auch an den Veröffentlichungs-/Abonnement-Feed ausgegeben werden.
zeigt ein veranschaulichendes Beispiel für einen Auslöseprozess. Dies ist ein Beispiel dafür, wie eine Anwendung von einer entfernten Quelle ausgelöst werden kann. Der Prozess empfängt ein Auslösesignal 501. Hierbei kann es sich um ein Signal handeln, das beispielsweise von einer Benutzeraktion in einem Fahrzeug oder einem Fahrzeugsystembus empfangen wird. Bei Empfang des Auslösesignals signalisiert der Prozess einen Synchronisationsdienst 503. Dieser Dienst kann dazu beitragen sicherzustellen, dass alle erforderlichen Medien auf dem Gerät vorliegen.
Der Synchronisationsdienst wird Medien von einem entfernten Server herunterladen, so dass ein Gerät eine Anwendung auch dann ausführen kann, wenn eine Fernverbindung unterbrochen wird oder ausfällt. Außerdem stellt der Dienst Medien in ausreichender Menge für ein Gerät bereit, so dass eine Anwendung diese nicht abgehackt wiedergibt. Bei der geräteseitig erforderlichen Medienmenge kann es sich um eine beliebige Menge handeln, und diese Menge kann von Fall zu Fall variieren. Benötigte Dateien oder Dateiteile können durch den Synchronisationsdienst 505 heruntergeladen werden, bis das Herunterladen abgeschlossen ist 507.
Außerdem können Auslöser eine Anwendung initiieren, aber nicht immer umgehend. Wenn die Anwendung hierbei eine Verzögerung aufweist oder beispielsweise einen zweiten Auslöser erfordert, wartet der Prozess, bis 509 der entsprechende Zeitpunkt gekommen ist. Außerdem gilt: Wenn gerade ein Unterdrückungsereignis vorliegt (z. B. Fahrer führt Gespräch oder hohe Arbeitslast), kann der Prozess warten, bis ein geeigneter Zeitpunkt gekommen ist. Dann kann die Anwendung ausgeführt werden 511.
zeigt ein veranschaulichendes Beispiel für einen weiteren Auslöseprozess. In diesem veranschaulichenden Beispiel wird der Prozess durch eine Mobilgeräteaktivität ausgelöst, beispielsweise durch eine Textnachricht. Der Prozess empfängt die Mobilgeräteaktivität 601 und wiederholt den Synchronisationsprozess wie vorstehend besprochen 603, 605.
Da der Auslöser durch das Mobilgerät empfangen wurde, ist es in diesem Fall möglich, dass das Gerät zu dem Zeitpunkt, zu dem der Auslöser empfangen wurde, noch nicht einmal mit einem Fahrzeug verbunden ist. Dementsprechend wird das Gerät prüfen und feststellen, ob es sich derzeitig in einem Fahrzeug befindet/mit einem Fahrzeug verbunden ist oder nicht 609. Wenn sich das Gerät nicht in einem Fahrzeug 611 befindet, wird der Prozess eine ausgelöste Anwendung auf dem Gerät selbst starten 613. Andernfalls kann der Prozess das Gerät in dem Fahrzeug starten und die fahrzeuginterne HMI für die Geräteinteraktion nutzen.
zeigt ein veranschaulichendes Beispiel für noch einen weiteren Auslöseprozess. In diesem veranschaulichenden Beispiel kann ein Auslöser durch einen Internetdienst gesendet werden. Dies könnte beispielsweise nützlich sein, wenn sich der Fahrer und ein Mobilgerät an unterschiedlichen Standorten befinden. Der Fahrer könnte das Internet nutzen, um ein Signal an das Mobilgerät zu senden, um beispielsweise eine Standortanwendung zu aktivieren, die beim Auffinden des Mobilgeräts helfen könnte.
In diesem veranschaulichenden Beispiel empfängt der Prozess einen Auslöser von einer Verbindung zum Internet 701. Um das Verarbeiten der Anwendung zu ermöglichen, auch wenn die Verbindung unterbrochen ist, signalisiert der Prozess dann einen Synchronisationsdienst 703 und fährt mit dem Herunterladen von Dateien 705 fort. Dieses Herunterladen wird fortgesetzt, bis eine ausreichende Synchronisation erfolgt ist 707.
Da eine unterschiedliche Funktionalität aktiviert werden kann, basierend darauf, wo sich das Gerät befindet, kann der Prozess den Gerätestandort prüfen, um den aktuellen Standort des Geräts 709 zu ermitteln. Wenn sich das Gerät in einem Fahrzeug 711 befindet, kann der Prozess einen fahrzeuginternen Modus 713 signalisieren. Dies kann eine Interaktion mit dem Gerät über eine fahrzeuginterne HMI ermöglichen.
Wenn sich das Gerät fern vom Internet 717 befindet, kann der Prozess einen HTML5-Modus 719 signalisieren. Dies kann bewirken, dass eine Anwendung auf dem Gerät während des Ausführens in einem HTML5-Modus 721 ausgeführt wird. Bei einer dritten Option kann der Prozess der Anwendung signalisieren, in einem standardmäßigen „Telefonmodus” 723 zu arbeiten, was bewirkt, dass die Anwendung auf dem Telefon 725 in einem Telefonmodus ausgeführt wird.
zeigt ein veranschaulichendes Beispiel für ein Server-Netzwerk. In diesem veranschaulichenden Beispiel enthalten mehrere Ursprungsserver 817, 819 Anwendungen, auf die über ein Mobilgerät zugegriffen werden kann, welches in diesem Fall in einem fahrenden Fahrzeug mitgeführt wird. Die Ursprungsserver stehen in Kommunikationsverbindung mit einem Internet-Backbone 801, welcher selbst eine weitere Verbindung zu einer Reihe von Wiederholungsservern 809, 811, 813, 815 bereitstellt.
Die Anwendung und zugehörige Daten können für einen Wiederholungsserver 809 bereitgestellt werden, um die Kommunikation mit einem Mobilfunkmast zu ermöglichen 807A, 807B, welcher dann mit dem Gerät in dem Fahrzeug kommunizieren kann 805A, 805B. Während sich das Fahrzeug auf der Straße bewegt 803, erfolgt ein Zugriff auf unterschiedliche Mobilfunkmasten, die in einer Kommunikationsverbindung mit unterschiedlichen Wiederholungsservern stehen.
Informationen werden zwischen dem Fahrzeug und den Wiederholungsservern weitergeleitet, und zwischen den Wiederholungsserver selbst. Wenn sich ein Fahrzeug einem Übergabepunkt nähert, an dem die Steuerung von einem Wiederholungsserver an einen anderen übergeben wird, beispielsweise bei einem Übergang von 805B zu 805C, kann der Prozess das Fahrzeug mit einem neuen Server verbinden 813. Der neue Server kommuniziert mit dem Fahrzeug in diesem Fall über einen neuen Mast 807D. Da eine bestimmte Datenmenge wahrscheinlich bereits synchronisiert worden ist, ist es unwahrscheinlich, dass es erwünscht ist, die Synchronisation bei jeder Steuerungsübergabe erneut einzuleiten. Dementsprechend kann der Prozess, wie zwischen 813 und 815 gezeigt, Informationen von einem Wiederholungsserver an einen anderen weiterleiten. Diese Informationen können Informationen zu den bereits übertragenen Teilen beinhalten, und Informationen dazu, welche Informationen noch synchronisiert werden müssen. Die Handhabung der Synchronisation kann dann durch 815 gesteuert werden und dort ansetzen, wo der Server 813 aufgehört hat.
zeigt einen veranschaulichenden Prozess für die Übergabe der Dateisynchronisierung. In diesem veranschaulichenden Beispiel sendet der Prozess eine Übergabenachricht an einen neuen Server und an ein Mobilgerät, das in einem Synchronisationsprozess 901 eingebunden ist. Dies weist darauf hin, dass eine Übergabe unmittelbar bevorsteht. Übergaben können beispielsweise erfolgen, wenn man sich einem neuen Mobilfunkmast nähert oder wenn eine Verbindung zu einem neuen Mast hergestellt worden ist.
Der Prozess sendet außerdem einen neuen Servernamen an den aktuellen Server 903, damit der aktuelle Server weiß, wohin er die Daten zu dem Synchronisationsprozess übergeben muss. Sobald der neue Server identifiziert worden ist, kann der Prozess bestimmen, welche Dateien derzeit verwendet werden und welche Dateien noch synchronisiert werden müssen 905. Diese Dateien können dann von dem aktuellen Server an den neuen Server übertragen 907 oder von einem Ursprungsserver bereitgestellt werden. Sobald die Synchronisation zwischen den Servern erfolgt ist 909, kann der Prozess fortgesetzt werden.
Eine Nachricht wird dann an das Mobilgerät übertragen, in der mitgeteilt wird, dass ein Serverwechsel erfolgen wird 911. Die Nachricht beinhaltet auch eine Kennung des neuen Servers für die Handhabung des Synchronisationsprozesses. Sobald die Nachricht übertragen worden ist, kann der Prozess eine aktuelle Gerätesynchronisation beenden, so dass die neue Synchronisation beginnen kann 913. Das Gerät versucht weiterhin, eine Verbindung zu dem neuen Synchronisationsserver 915 herzustellen, bis eine Verbindung hergestellt werden kann 917. Sobald die Verbindung hergestellt worden ist 917, kann die Dateisynchronisation fortgesetzt werden.
Obwohl vorstehend beispielhafte Ausführungsformen beschrieben werden, ist nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen der Erfindung beschreiben. Vielmehr sind die in dieser Spezifikation verwendeten Ausdrücke lediglich Ausdrücke beschreibender Art und beinhalten keinerlei Einschränkung. Es ist einzusehen, dass verschiedene Änderungen vorgenommen werden können, ohne den Geist und Schutzbereich der Erfindung zu verlassen. Zusätzlich können die Merkmale von verschiedenen Implementierungsausführungen kombiniert werden, um weitere Ausführungsformen der Erfindung zu bilden.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

EP 2523436 [0004]

Zitierte Nicht-Patentliteratur

IEEE 802 PAN(Personal Area Network, persönliches Netzwerk)-Protokolle [0027]
IEEE 802 LAN(Local Area Network, Ortsnetzwerk)-Protokolle [0027]
IEEE 1394 [0030]
IEEE 1284 [0030]

Claims

System, umfassend: einen Prozessor, der dafür ausgelegt ist: eine Rundsendung von fahrzeugbezogenen Statusänderungen zu abonnieren; mindestens eine fahrzeugbezogene Statusänderung in der Rundsendung zu erkennen, die einen Anwendungsstart auslöst; und eine der erkannten fahrzeugbezogenen Statusänderung entsprechende Anwendung zu starten.
System nach Anspruch 1, ferner umfassend den Prozessor, wobei der Prozessor dafür konfiguriert ist: Daten von einer entfernten Quelle entsprechend der Anwendung anzufordern; die angeforderten Daten herunterzuladen; und den Anwendungsstart zu verzögern, bis mindestens eine vorgegebene Datenmenge heruntergeladen worden ist.
System nach Anspruch 1, wobei die Statusänderung einen Fahrzeugstandort beinhaltet.
System nach Anspruch 1, wobei die Statusänderung eine Fahrzeugdienstanforderung beinhaltet.
System nach Anspruch 1, wobei die Statusänderung einen anstehenden Fälligkeitstermin für eine Kreditzahlung beinhaltet.
System nach Anspruch 1, wobei der Prozessor dafür konfiguriert ist, die von einem drahtlos verbundenen fahrzeuginternen Computersystem zu handhabende Anwendung zu starten.
System nach Anspruch 1, wobei der Prozessor dafür konfiguriert ist: zu bestimmen, ob sich ein den Prozessor enthaltendes Mobilgerät in einem Fahrzeug oder außerhalb eines Fahrzeugs befindet; und wobei der Start ferner das Starten einer auf der Bestimmung basierenden Version der Anwendung umfasst.