DE102015118577A1

DE102015118577A1 - Verfahren und Gerät für dynamisches Aktualisieren der Ankunftszeit am Ziel

Info

Publication number: DE102015118577A1
Application number: DE102015118577.6A
Authority: DE
Inventors: Heath Williams; Stefan Bankowski; Edward Wehrman; Elizabeth Halash; Kevin BURDETTE
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2014-10-31
Filing date: 2015-10-30
Publication date: 2016-05-04
Also published as: US20160123753A1; CN105574321B; CN105574321A; US9915541B2

Abstract

Ein System enthält einen Prozessor, der konfiguriert ist, Fahrzeuginformationen zu empfangen, die zumindest Ort und Kraftstoffstand enthalten. Der Prozessor ist außerdem konfiguriert, eine gegenwärtige geschätzte Ankunftszeit (ETA) zu einem ereignisassoziierten Ziel basierend auf Fahrzeit von dem Ort zu bestimmen. Der Prozessor ist ferner konfiguriert, eine Auswirkung des Kraftstoffstands auf die gegenwärtige ETA zu bestimmen. Der Prozessor ist außerdem konfiguriert, als Reaktion darauf, dass die gegenwärtige ETA um mehr als eine Schwellenwertabweichung von einer vorherigen ETA abweicht, eine Aktualisierung einer entfernten Partei bereitzustellen, die die gegenwärtige ETA enthält.

Description

TECHNISCHES GEBIET
Die veranschaulichenden Ausführungsformen betreffen allgemein ein Verfahren und ein Gerät zum dynamischen Aktualisieren der Ankunftszeit am Ziel.
HINTERGRUND
Da wir in einer hochgradig verschalteten Auf-Abruf-Welt leben, besteht ein großes Verlangen nach unmittelbarem Zugang zu Informationsveränderungen. Kommunikationsplattformen stellen fast sofortige Zugreifbarkeit auf entfernte Parteien unabhängig von Tageszeit oder Ort bereit. Als ein Ergebnis sind die Erwartungen hinsichtlich von Pünktlichkeit und/oder Veränderungen der erwarteten Ankunftszeiten beträchtlich gestiegen. Während es (in einer Ära vor mobilen Vorrichtungen) normal war, eine erwartete Ankunftszeit festzusetzen und dann, falls auf Verkehr gestoßen wurde, so bald wie möglich anzukommen, diktiert die Auf-Abruf-Natur der Kommunikation, dass der Fahrer jetzt andere Parteien per Anruf/Text/E-Mail benachrichtigen sollte, um sie über Veränderungen von Plänen zu informieren. Leider wird der Fahrer nicht immer über perfekte Informationen über die vorausliegende Straße verfügen, um derartige Aktualisierungen bereitzustellen.
ZUSAMMENFASSUNG
In einer ersten veranschaulichenden Ausführungsform beinhaltet ein System einen Prozessor, der konfiguriert ist, Fahrzeuginformationen zu empfangen, die zumindest Ort und Kraftstoffstand enthalten. Der Prozessor ist außerdem konfiguriert, eine gegenwärtige geschätzte Ankunftszeit (ETA) zu einem ereignisassoziierten Ziel basierend auf Fahrzeit von dem Ort zu bestimmen. Der Prozessor ist ferner konfiguriert, eine Auswirkung des Kraftstoffstands auf die gegenwärtige ETA zu bestimmen. Der Prozessor ist außerdem konfiguriert, als Reaktion darauf, dass die gegenwärtige ETA um mehr als eine Schwellenwertabweichung von einer vorherigen ETA abweicht, eine Aktualisierung eines entfernten Dritten bereitzustellen, die die gegenwärtige ETA enthält.
In einer zweiten veranschaulichenden Ausführungsform beinhaltet ein computerimplementiertes Verfahren, Fahrzeuginformationen zu empfangen, die zumindest Ort und Kraftstoffstand enthalten. Das Verfahren enthält außerdem, eine gegenwärtige geschätzte Ankunftszeit (ETA) zu einem ereignisassoziierten Ziel basierend auf Fahrzeit von dem Ort zu bestimmen. Das Verfahren enthält ferner, als Reaktion auf eine Abweichung der gegenwärtigen ETA von einer vorherigen ETA, die einen Abweichungsschwellenwert übersteigt, eine Auswirkung des Kraftstoffstands auf die gegenwärtige ETA zu bestimmen und eine Aktualisierung einer entfernten Partei, einschließlich der gegenwärtigen ETA, bereitzustellen.
In einer dritten veranschaulichenden Ausführungsform speichert ein nichtflüchtiges Speichermedium Anweisungen, die, wenn sie ausgeführt werden, bewirken, dass ein Prozessor ein Verfahren ausführt, das beinhaltet, Fahrzeuginformationen zu empfangen, die zumindest Ort und Kraftstoffstand enthalten. Das Verfahren enthält außerdem, eine gegenwärtige geschätzte Ankunftszeit (ETA) zu einem ereignisassoziierten Ziel basierend auf Fahrzeit von dem Ort zu bestimmen. Das Verfahren enthält ferner, als Reaktion auf eine Abweichung der gegenwärtigen ETA von einer vorherigen ETA, die einen Abweichungsschwellenwert übersteigt, eine Auswirkung des Kraftstoffstands auf die gegenwärtige ETA zu bestimmen und eine Aktualisierung einer entfernten Partei, einschließlich der gegenwärtigen ETA, bereitzustellen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 zeigt ein veranschaulichendes Fahrzeugrechnersystem;
2 zeigt einen veranschaulichenden Aktualisierungsprozess der geschätzten Ankunftszeit (ETA);
3 zeigt einen veranschaulichenden ETA-Berechnungsprozess;
4 zeigt einen veranschaulichenden Ereignisaktualisierungsprozess; und
5 zeigt einen veranschaulichenden Ereignisauswahlprozess.
AUSFÜHRLICHE BESCHREIBUNG
Ausführliche Ausführungsformen der vorliegenden Erfindung werden hierin nach Erfordernis offenbart; es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich beispielhaft für die Erfindung sind, die in verschiedenen und alternativen Formen ausgeführt werden kann. Die Figuren sind nicht notwendigerweise maßstabsgetreu; einige Merkmale können überbetont oder minimiert sein, um Einzelheiten von bestimmten Komponenten zu zeigen. Daher sind hierin offenbarte spezifische strukturelle und funktionale Einzelheiten nicht als einschränkend zu interpretieren, sondern lediglich als eine repräsentative Basis, um einem Fachmann zu lehren, die vorliegende Erfindung verschiedenartig anzuwenden.
1 stellt eine beispielhafte Blocktopologie für ein fahrzeugbasiertes Rechnersystem 1 (VCS) für ein Fahrzeug 31 dar. Ein Beispiel eines derartigen fahrzeugbasierten Rechnersystems 1 ist das System SYNC, hergestellt von THE FORD MOTOR COMPANY. Ein Fahrzeug, das mit einem fahrzeugbasierten Rechnersystem ausgestattet ist, kann eine visuelle vorgeschaltete Schnittstelle 4 enthalten, die sich in dem Fahrzeug befindet. Der Benutzer kann außerdem imstande sein, mit der Schnittstelle zu interagieren, wenn sie zum Beispiel mit einem berührungsempfindlichen Bildschirm versehen ist. In einer anderen veranschaulichenden Ausführungsform erfolgt die Interaktion durch Betätigung von Tasten, ein Sprache-Dialogsystem mit automatischer Spracherkennung und Sprachsynthese.
In der in 1 dargestellten veranschaulichenden Ausführungsform 1 steuert ein Prozessor 3 mindestens einen Anteil des Betriebs des fahrzeugbasierten Rechnersystems. Der Prozessor, der in dem Fahrzeug bereitgestellt ist, gestattet Verarbeitung von Befehlen und Routinen an Bord. Ferner ist der Prozessor mit sowohl dem nicht dauerhaften Speicher 5 als auch dem dauerhaften Speicher 7 verbunden. In dieser veranschaulichenden Ausführungsform ist der flüchtige Speicher ein Direktzugriffspeicher (RAM) und ist der Festspeicher ein Festplattenlaufwerk (HDD) oder Flash-Speicher. Im Allgemeinen kann ein dauerhafter (nichtflüchtiger) Speicher sämtliche Speicherformen enthalten, die Daten beibehalten, wenn ein Rechner oder eine andere Vorrichtung ausgeschaltet ist. Diese enthalten, sind aber nicht darauf beschränkt, HDDs, CDs, DVDs, Magnetbänder, Festkörperlaufwerke, tragbare USB-Laufwerke und jede andere geeignete Form von dauerhaftem Speicher.
Der Prozessor ist außerdem mit einer Anzahl verschiedener Eingänge versehen, die dem Benutzer gestatten, an den Prozessor anzuschalten. In dieser veranschaulichenden Ausführungsform sind ein Mikrofon 29, ein Hilfseingang 25 (für Eingang 33), ein USB-Eingang 23, ein GPS-Eingang 24, ein Bildschirm 4, der eine berührungsempfindliche Anzeige sein kann, und ein BLUETOOTH-Eingang 15 alle bereitgestellt. Ein Eingangswahlschalter 51 ist außerdem bereitgestellt, um einem Benutzer zu gestatten, zwischen verschiedenen Eingängen zu wechseln. Eingang in sowohl den Mikrofon- als auch den Hilfsanschluss wird von einem Wandler 27 von analog zu digital umgewandelt, bevor er zum Prozessor weitergeleitet wird. Obwohl nicht dargestellt, können zahlreiche der Fahrzeugkomponenten und Hilfskomponenten in Kommunikation mit dem VCS ein Fahrzeugnetzwerk (wie, aber nicht darauf beschränkt, ein CAN-Bus) nutzen, um Daten zu und von dem VCS (oder Komponenten davon) zu leiten.
Ausgänge aus dem System können eine visuelle Anzeige 4 und einen Lautsprecher 13 oder Stereosystem-Ausgang beinhalten, sind aber nicht darauf beschränkt. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt sein Signal von dem Prozessor 3 durch einen Digital-zu-Analog-Wandler 9. Ausgang kann auch zu einer entfernten BLUETOOTH-Vorrichtung wie PND 54 oder eine USB-Vorrichtung wie ein Fahrzeug-Navigationssystem 60 entlang den bei 19 bzw. 21 dargestellten bidirektionalen Datenströmen erfolgen.
In einer veranschaulichenden Ausführungsform verwendet das System 1 einen BLUETOOTH-Transceiver 15 zum Kommunizieren 17 mit dem Mobilgerät 53 (z. B. Funktelefon, Smartphone, PDA oder eine beliebige andere Vorrichtung, die über drahtlose Konnektivität mit einem entfernten Netzwerk verfügt) eines Benutzers. Das Mobilgerät kann dann zum Kommunizieren 59 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 durch zum Beispiel Kommunikation 55 mit einem Funkmast 57 verwendet werden. In einigen Ausführungsformen kann der Mast 57 ein W-LAN-Zugangspunkt sein.
Beispielhafte Kommunikation zwischen dem Mobilgerät und dem BLUETOOTH-Transceiver wird durch das Signal 14 repräsentiert.
Koppeln eines Mobilgeräts 53 und des BLUETOOTH-Transceivers 15 kann durch eine Taste 52 oder ähnliche Eingabe angewiesen werden. Dementsprechend wird die CPU angewiesen, dass der BLUETOOTH-Transceiver an Bord mit einem BLUETOOTH-Transceiver in einem Mobilgerät gekoppelt wird.
Daten können zwischen der CPU 3 und dem Netzwerk 61 unter Nutzung zum Beispiel eines Datentarifs, Daten-über-Sprache oder DTMF-Tönen, die mit dem Mobilgerät 53 assoziiert sind, kommuniziert werden. Alternativ kann es wünschenswert sein, ein Modem 63 an Bord vorzusehen, das über eine Antenne 18 verfügt, um Daten zwischen der CPU 3 und dem Netzwerk 61 über das Sprachband zu kommunizieren 16. Das Mobilgerät 53 kann dann zum Kommunizieren 59 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 durch zum Beispiel Kommunikation 55 mit einem Funkmast 57 verwendet werden. In einigen Ausführungsformen kann das Modem 63 Kommunikation 20 mit dem Mast 57 zum Kommunizieren mit dem Netzwerk 61 herstellen. Als ein nicht einschränkendes Beispiel kann das Modem 63 ein USB-Funkmodem sein und die Kommunikation 20 kann Funkkommunikation sein.
In einer veranschaulichenden Ausführungsform ist der Prozessor mit einem Betriebssystem versehen, das eine API zur Kommunikation mit Modem-Anwendungssoftware beinhaltet. Die Modem-Anwendungssoftware kann auf ein eingebettetes Modul oder eingebettete Firmware in dem BLUETOOTH-Transceiver zugreifen, um drahtlose Kommunikation mit einem entfernten BLUETOOTH-Transceiver (wie dem in einem Mobilgerät) durchzuführen. Bluetooth ist ein Teilsatz der Protokolle IEEE 802 PAN (persönliches Bereichsnetzwerk). Die Protokolle IEEE 802 LAN (lokales Bereichsnetzwerk) enthalten W-LAN und weisen eine beträchtliche Kreuzfunktionalität mit IEEE 802 PAN auf. Ein weiteres Kommunikationsmittel, das in diesem Bereich verwendet werden kann, ist optische Freiraumkommunikation (wie IrDA) und nicht standardisierte Kunden-IR-Protokolle.
In einer anderen Ausführungsform beinhaltet das Mobilgerät 53 ein Modem für Sprachband- oder Breitband-Datenkommunikation. In der Daten-über-Sprache-Ausführungsform kann eine als Frequenzmultiplexing bekannte Technik implementiert werden, mit der der Besitzer des Mobilgeräts über das Gerät sprechen kann, während Daten übertragen werden. Zu anderen Zeiten, wenn der Benutzer das Gerät nicht verwendet, kann die Datenübertragung die gesamte Bandbreite (300 Hz bis 3,4 kHz in einem Beispiel) nutzen. Während Frequenzmultiplexing für analoge zellulare Kommunikation zwischen dem Fahrzeug und dem Internet üblich sein mag und noch verwendet wird, wurde es in großem Ausmaß durch Hybride davon wie Codemultiplexzugriff (CDMA), Zeitmultiplexzugriff (TDMA), Raummultiplexzugriff (SDMA) für digitale zellulare Kommunikation ersetzt. Dies sind alles Standards, die mit ITU IMT-2000 (3G) kompatibel sind und Datenraten bis zu 2 mbs für stationäre oder gehende Benutzer und 385 kbs für Benutzer in einem fahrenden Fahrzeug bieten. 3G-Standards werden jetzt durch IMT-Advanced (4G) ersetzt, das 100 mbs für Benutzer in einem Fahrzeug und 1 gbs für stationäre Benutzer bietet. Wenn der Benutzer über einen mit dem Mobilgerät assoziierten Datentarif verfügt, ist es möglich, dass der Datentarif Breitbandübertragung bietet, und das System könnte eine viel größere Bandbreite verwenden (wodurch die Datenübertragung beschleunigt wird). In noch einer anderen Ausführungsform ist das Mobilgerät 53 durch eine Funkkommunikationsvorrichtung (nicht dargestellt) ersetzt, das im Fahrzeug 31 installiert ist. In einer weiteren Ausführungsform kann das ND 53 eine drahtlose Lokalnetzwerk- bzw. LAN-Vorrichtung sein, die imstande ist, über zum Beispiel (und ohne Einschränkung) ein 802.11g-Netzwerk (d. h. W-LAN) oder ein WiMax-Netzwerk zu kommunizieren.
In einer Ausführungsform können eingehende Daten durch das Mobilgerät über einen Daten-über-Sprache- oder Datentarif durch den BLUETOOTH-Transceiver an Bord und in den internen Prozessor 3 des Fahrzeugs geleitet werden. Im Fall von zum Beispiel bestimmten temporären Daten können die Daten in dem HDD oder einem anderen Speichermedium 7 bis zu einem Zeitpunkt, zu dem die Daten nicht mehr benötigt werden, gespeichert werden.
Weitere Quellen, die an das Fahrzeug anschalten können, beinhalten eine persönliche Navigationsvorrichtung 54, die zum Beispiel eine USB-Verbindung 56 und/oder eine Antenne 58 aufweist, eine Fahrzeugnavigationsvorrichtung 60 mit einer USB- 62 oder anderen Verbindung, eine GPS-Vorrichtung 24 an Bord oder ein entferntes Navigationssystem (nicht dargestellt), das Konnektivität zum Netzwerk 61 aufweist. USB ist eines einer Klasse von Protokollen für serielle Netzwerkanbindung. IEEE 1394 (FireWire^TM (Apple), i.LINK^TM (Sony) und Lynx^TM (Texas Instruments)), serielle Protokolle der EIA (Electronics Industry Association), IEEE 1284 (Centronics Port), S/PDIF (Sony/Philips Digital Interconnect Format) und USB-IF (USB Implementers Forum) bilden das Rückgrat der seriellen Standards von Vorrichtung zu Vorrichtung. Die meisten der Protokolle können für entweder elektrische oder optische Kommunikation implementiert werden.
Ferner könnte die CPU mit einer Vielfalt anderer Hilfsvorrichtungen 65 in Kommunikation stehen. Diese Vorrichtungen können über eine drahtlose 67 oder verdrahtete 69 Verbindung angeschlossen sein. Hilfsvorrichtungen 65 können persönliche Medien-Abspielgeräte, drahtlose Gesundheitsvorrichtungen, tragbare Computer und dergleichen beinhalten, sind aber nicht darauf beschränkt.
Außerdem oder alternativ könnte die CPU mit einem fahrzeugbasierten drahtlosen Router 73 unter Verwendung zum Beispiel eines W-LAN-Transceivers (IEEE 803.11) 71 verbunden sein. Dies könnte der CPU gestatten, Verbindung mit entfernten Netzwerken im Bereich des lokalen Routers 73 herzustellen.
Zusätzlich zu beispielhaften Prozessen, die von einem Fahrzeugrechnersystem, das sich in einem Fahrzeug befindet, ausgeführt werden, können die beispielhaften Prozesse in bestimmten Ausführungsformen von einem Rechnersystem in Kommunikation mit einem Fahrzeugrechnersystem ausgeführt werden. Ein derartiges System kann eine drahtlose Vorrichtung (z. B., und ohne Einschränkung, ein Mobiltelefon) oder ein entferntes Rechnersystem (z. B., und ohne Einschränkung, ein Server), die durch die drahtlose Vorrichtung angeschlossen ist, beinhalten, ist aber nicht darauf beschränkt. Zusammen können derartige Systeme als fahrzeugassoziierte Rechnersysteme (VACS) bezeichnet werden. In bestimmten Ausführungsformen können besondere Komponenten des VACS besondere Abschnitte eines Prozesses in Abhängigkeit von der besonderen Implementierung des Systems ausführen. Lediglich als Beispiel und nicht als Einschränkung ist es wahrscheinlich, dass, wenn ein Prozess einen Schritt des Sendens oder Empfangens von Informationen mit einer gekoppelten drahtlosen Vorrichtung aufweist, die drahtlose Vorrichtung diesen Teil des Prozesses nicht durchführt, da die drahtlose Vorrichtung keine Informationen mit sich selbst „senden und empfangen“ würde. Ein Durchschnittsfachmann im Fachgebiet wird verstehen, wann es angemessen ist, ein besonderes Rechnersystem für eine gegebene Lösung anzuwenden.
In jedem der hierin diskutierten veranschaulichenden Ausführungsformen wird ein beispielhaftes, nicht einschränkendes Beispiel eines Prozesses, der von einem Rechnersystem ausführbar ist, dargestellt. In Bezug auf jeden Prozess ist es möglich, dass das Rechnersystem, das den Prozess ausführt, für den begrenzten Zweck der Ausführung des Prozesses als ein Spezialprozessor zum Ausführen des Prozesses konfiguriert wird. Alle Prozesse müssen nicht in ihrer Ganzheit ausgeführt werden und es versteht sich, dass sie Beispiele von Prozesstypen sind, die ausgeführt werden können, um Elemente der Erfindung zu erzielen. Den beispielhaften Prozessen können zusätzliche Schritte nach Wunsch hinzugefügt oder davon entfernt werden.
In den veranschaulichten Ausführungsformen stellen Prozesse, die in zum Beispiel einer mobilen Vorrichtung, einem Fahrzeugrechnersystem oder in der Cloud (und mit dem Fahrzeugrechnersystem verbunden) ausgeführt werden, dynamische Echtzeit-Aktualisierungen eines ETA eines Benutzers. Anstatt dass der Fahrer manuell auf einen Kalender oder ein Konto sozialer Medien, wo ein Ereignis aufgelistet ist, zugreifen und eine ETA manuell aktualisieren muss, gestatten die Prozesse automatische ETA-Aktualisierungen, die die wahre ETA basierend auf gegenwärtig bekannten Bedingungen (z. B., ohne Einschränkung, gegenwärtiger Ort und gegenwärtige Geschwindigkeit, Verkehr, Wetter, Kraftstoffstände usw.) genau reflektieren.
Nachdem sie von einem Benutzer gestartet wurde, kann eine Anwendung im Hintergrund in Ausführung fortbestehen und über mehreren Zündzyklen auf einen Fahrzeugcomputer zugreifen. Die Anwendung hat Zugriff auf Fahrzeugdaten, die zum Bestimmen einer gegenwärtigen ETA verwendbar sind, und hat Zugriff auf soziale Medien, Kalender und andere Planungsformate zur Verwendung bei Ereignisbestimmung und ETA-Aktualisierungen.
Während das Fahrzeug fährt, kann der Prozess Fahrzeugdaten zum Bestimmen einer gegenwärtigen ETA nutzen. Falls eine ausreichende Abweichung von einer prognostizierten ETA vorliegt, kann die Anwendung auf Anforderung durch den Benutzer und/oder über regelmäßige Intervalle eine zielrelevante Ereignisveröffentlichung aktualisieren, um die neue ETA für den Benutzer zu reflektieren. Das Ereignis könnte zum Beispiel in einer Kalender-Anwendung des Benutzers aufgelistet oder in einem Konto sozialer Medien vorhanden sein.
2 zeigt einen veranschaulichenden Aktualisierungsprozess der geschätzten Ankunftszeit (ETA). Hinsichtlich der in dieser Figur beschriebenen veranschaulichenden Ausführungsformen ist zu beachten, dass ein Allzweck-Prozessor zeitweise als ein Spezialprozessor zum Zweck der Ausführung einiger oder sämtlicher der hierin gezeigten beispielhaften Verfahren aktiv wird. Bei der Ausführung von Code, der Anweisungen zum Ausführen einiger oder sämtlicher Schritte des Verfahrens bereitstellt, kann der Prozessor vorübergehend bis zum Zeitpunkt des Abschlusses des Verfahrens als ein Spezialprozessor umfunktioniert werden. In einem anderen Beispiel kann Firmware, die in Übereinstimmung mit einem im Voraus konfigurierten Prozessor wirkt, zu einem angemessenen Ausmaß bewirken, dass der Prozessor als ein Spezialprozessor fungiert, bereitgestellt zum Zweck der Ausführung des Verfahrens oder einer angemessenen Abwandlung davon.
In dem in 2 gezeigten veranschaulichenden Beispiel startet ein Benutzer eine Anwendung zur ETA-Schätzung und -Aktualisierung 201. Während sie als ein einzelner Prozess dargestellt sind, versteht es sich, dass die hierin diskutierten Verfahren und Geräte in mehreren Prozessen verkörpert werden könnten, die an verschiedenen Orten durchgeführt werden könnten, wie es für eine gegebene Implementierung angemessen ist. Ferner sind alle hierin dargestellten Prozesse lediglich veranschaulichend und sollen den Schutzumfang der Erfindung in keiner Weise einschränken.
Sobald der Prozess läuft, wird er eine Verbindung mit einem Fahrzeugrechnersystem detektieren. Informationen wie zum Beispiel Geschwindigkeit, GPS-Daten und Kraftstoffstand werden von einem Fahrzeugcomputer empfangen. Während GPS-Daten und Geschwindigkeitsdaten von einer mobilen Vorrichtung selbst berechnet werden könnten, müssen spezifische Informationen unter Umständen noch direkt vom Fahrzeug kommen, wenn sie bei der ETA-Vorhersage verwendet werden. In mindestens einem Beispiel wird angenommen, dass ein Kraftstoffstand eine erwartete Wirkung auf die ETA bestimmen wird, und der Kraftstoffstand wird in diesem Beispiel von einem Fahrzeugrechnersystem bereitgestellt. Sobald das Fahrzeugrechnersystem verfügbar ist 205, kann der Prozess unter Verwendung der angemessenen Verbindung (z. B., ohne Einschränkung, WiFi, BLUETOOTH usw.) verbinden 207.
Sobald eine Verbindung mit dem Fahrzeugcomputer hergestellt ist, kann der Prozess ein Ziel für ETA-Erwägung auswählen 208. Hinsichtlich der veranschaulichenden Ziel-Erwägung wird mehr in Bezug auf die 4 und 5 diskutiert. Im Allgemeinen kann das Ziel ein gegenwärtiges Ziel oder ein Ziel in Bezug auf ein bevorstehendes, im Kalender oder in sozialen Medien verfolgtes Ereignis sein. In mindestens einem Beispiel könnte der Fahrer ein spezifisches Ziel für Zwecke der ETA-Erwägung eingeben, selbst wenn gegenwärtig ein anderes Ziel von einem Navigationssystem verwendet würde.
In dem veranschaulichenden Prozess werden anschließend Fahrzeugdaten von dem Fahrzeugrechnersystem empfangen. In Bezug auf 3 wird ein spezifisches Beispiel des Empfangs von Fahrzeugdaten dargestellt, aber im Allgemeinen sind diese Daten Daten, die zum Bestimmen der wahrscheinlichen ETA eines fahrenden Fahrzeugs verwendet werden können. Die Fahrzeugdaten werden analysiert, um eine wahrscheinliche ETA zu bestimmen 211. Dies kann Schätzen einer geschätzten Ankunftszeit basierend auf gegenwärtiger Geschwindigkeit, gegenwärtigem Ort, bevorstehendem Verkehr, Wetter und etwaigen möglichen vorhersagbaren Stopps wie ein Tankstopp, wenn der Kraftstoffstand des Fahrzeugs unter einem abstimmbaren Schwellenwertniveau ist oder prognostiziert wird, dass er darunter sein wird, enthalten, ist aber nicht darauf beschränkt.
Hinsichtlich von Stopppunkten in Bezug auf Dinge wie Kraftstoffstand kann ein festes Niveau (z. B. 10 %, 20 Meilen verbleibend usw.) als ein Schwellenwert verwendet werden, wenn ein Stopp wahrscheinlich ist, und/oder das Niveau kann durch Beobachtung des Fahrerverhaltens bestimmt werden (z. B. stoppt der Benutzer immer bei 20 % verbleibend, 40 Meilen verbleibend usw.). In einem Modell kann die Vorhersage bei dem vom Benutzer abstimmbaren Niveau vorgenommen und dann verstärkt werden, wenn ein unterer Schwellenwert eines minimalen Sicherheitsniveaus erreicht wird (wodurch die Wahrscheinlich eines Stopps von möglich zu fast sicher erhöht wird).
Wenn die prognostizierte ETA um mehr als einen Schwellenwert von einer vorher geschätzten ETA verschieden ist (oder wenn eine erstmalige ETA-Berechnung vorgenommen wird) 213, kann der Prozess den Fahrer auf die erwartete Veränderung aufmerksam machen 217. Dies könnte eine positive oder negative Veränderung sein, aber in diesem Beispiel erhält der Fahrer die Option, etwaige ETA-Aktualisierungen zu bestätigen.
In einem anderen Beispiel kann es sein, dass der Fahrer die Aktualisierungen nur einmal bestätigt und sie dann fortgeführt werden, wie es während der Fahrt angemessen ist, oder in noch einem anderen Beispiel kann der Fahrer einfach Aktualisierungen anweisen oder aktivieren und die Aktualisierungen werden automatisch veröffentlicht, sobald ein abstimmbarer Schwellenwert überquert wird.
Der Schwellenwert für ETA-Aktualisierungen kann basierend auf Fahrerpräferenzen variiert werden und kann zum Beispiel basierend auf Nähe (zeitlich oder physikalisch) zu einem Ziel abstimmbar sein. Das heißt, wenn ein Benutzer mehr als 50 Meilen oder 1 Stunde entfernt ist (nur veranschaulichende Zahlen), wird der Prozess unter Umständen nur Aktualisierungen bereitstellen, wenn die ETA sich um mehr als 5 Minuten verändert. Sobald das Fahrzeug 25 Meilen oder 0,5 Stunden entfernt ist, können die Aktualisierungen auf Veränderungen von 3 Minuten basieren. Wenn das Fahrzeug sich innerhalb von 5 Meilen und/oder 10 Minuten befindet, können die ETA-Aktualisierungen auf Veränderungen von Minute zu Minute oder Bruchteilen einer Minute basieren. In einem anderen Beispiel verändert sich der ETA-Schwellenwert für Aktualisierungen bei Annäherung des Ereignisses, so dass kleine zeitliche Aktualisierungen näher und näher zum Beginn des Ereignisses verwendet werden, so dass ankommende Parteien mit hoher Genauigkeit wissen, wann andere Parteien wahrscheinlich ankommen werden. In mindestens einem Beispiel wird, wenn der Aktualisierungsprozess einen ETA-Schwellenwert verwendet, der wahrscheinlich in mehreren ETA-Änderungen alle paar Minuten resultieren wird, der Prozess zum Aufmerksammachen des Fahrers deaktiviert, um den Fahrer nicht übermäßig abzulenken, und die Aktualisierungen werden einfach vorgenommen.
Sobald der Fahrer die ETA-Aktualisierung bestätigt hat 219, fährt der Prozess fort, mit einem Konto zu verbinden, in dem Ereignisdaten gespeichert sind 221, (oder um Ereignisteilnehmer zu kontaktieren, falls vorgezogen) und das geeignete Ereignis für Aktualisierung auszuwählen 223. Eine Fahrer-ETA wird dann in Bezug auf das ausgewählte Ereignis aktualisiert 225. Informationen wie das mögliche Erfordernis eines Tank-/Aufladungsstopps können ebenfalls veröffentlicht werden und das System könnte dann, wenn ein Tankstopp beobachtet wird, entsprechend aktualisieren.
So kann der Prozess zum Beispiel beginnen, wenn ein Fahrer eine Fahrt anfängt. Eine Überprüfung der bevorstehenden Ereignisse des Fahrers auf Facebook zeigt, dass der Fahrer die Teilnahme an einem Firmenessen um 17:00 Uhr bestätigt hat. Der Fahrer ist gegenwärtig dreißig Meilen von dem Ziel entfernt, dass mit dem Essen assoziiert ist. Die gegenwärtige Uhrzeit ist 16:00 Uhr und eine anfängliche ETA ist 16:45, die über den veranschaulichenden Aktualisierungsprozess mit Genehmigung des Fahrers auf Facebook veröffentlicht wurde.
Während der Fahrer fährt, verlangsamt ein Unfall infolge des Feierabendverkehrs den Fahrer, und das System berechnet eine neue ETA von 16:57 Uhr. Da in diesem Beispiel der abstimmbare Schwellenwert für Aktualisierungen zum Beispiel drei Minuten beträgt, liegt die Abweichung von zwölf Minuten außerhalb des Schwellenwerts, und der Fahrer erhält eine Option zum Aktualisieren der ETA. Da der Fahrer möchte, dass Mitarbeiter wissen, wann der Fahrer ankommen wird, bestätigt der Fahrer ETA-Aktualisierungen und weist das System an, das System automatisch zu aktualisieren. In diesem Beispiel wird dem Fahrer an diesem Punkt außerdem eine Option der ETA-Abweichung bereitgestellt und der Fahrer weist Aktualisierungen der ETA-Abweichungen über fünf Minuten an.
Der Verkehr setzt sich mit dem langsamen Kriechtempo fort und die nächste ETA-Berechnung ermittelt 17:00 Uhr für die Ankunft des Fahrers. Da dies nicht außerhalb des Schwellenwerts von fünf Minuten liegt, wird keine Aktualisierung vorgenommen. Bei der nächsten ETA-Berechnung (diese können in regelmäßigen Abständen oder in einer laufenden Berechnung vorgenommen werden) wurde der Unfall behoben und der Verkehr fließt wieder bei der Geschwindigkeitsbegrenzung. Demgemäß ist 16:54 Uhr die neue prognostizierte Ankunftszeit des Fahrers. Obwohl dies mehr als fünf Minuten von der vorherigen Berechnung abweicht, resultierte die vorherige Berechnung nicht in einer Aktualisierung, so dass die Grundlage für den ETA-Vergleich in diesem Beispiel die vorher veröffentlichte Aktualisierung von 16:57 ist. Da die Veränderung wieder nicht außerhalb des Schwellenwerts von fünf Minuten liegt, aktualisiert der Prozess die ETA nicht.
Beim Fahren auf Oberflächenstraßen trifft der Fahrer auf eine Stecke mit grünen Ampeln und die ETA verbessert sich auf 16:51 Uhr. Da dies außerhalb des Schwellenwerts von fünf Minuten liegt, kann der Prozess die ETA an diesem Punkt aktualisieren. Diese Weise der Aktualisierung kann nach Wunsch fortgesetzt werden, bis der Fahrer das Ziel erreicht (oder sich innerhalb einer abstimmbaren Nähe zum Ziel befindet).
Der für Aktualisierungen verwendete Schwellenwert der ETA-Abweichungen kann auch basierend auf einem Typ der Aktualisierung abgestimmt werden. Wenn zum Beispiel, ohne Einschränkung, Text- oder E-Mail-Aktualisierungen zum Aktualisieren einer ETA verwendet werden, kann ein größerer Schwellenwert verwendet werden, um einen Strom von Texten mit geringen Unterschieden zu vermeiden. Wenn die Zeit lediglich als eine abrufbare Quelle aktualisiert wird, kann der Prozess jedoch eine geringere Abweichung verwenden, weil der Prozess einen Posteingang nicht unnötig überfüllen wird.
3 zeigt einen veranschaulichenden ETA-Berechnungsprozess. Hinsichtlich der in dieser Figur beschriebenen veranschaulichenden Ausführungsformen ist zu beachten, dass ein Allzweck-Prozessor zeitweise als ein Spezialprozessor zum Zweck der Ausführung einiger oder sämtlicher der hierin gezeigten beispielhaften Verfahren aktiv wird. Bei der Ausführung von Code, der Anweisungen zum Ausführen einiger oder sämtlicher Schritte des Verfahrens bereitstellt, kann der Prozessor vorübergehend bis zum Zeitpunkt des Abschlusses des Verfahrens als ein Spezialprozessor umfunktioniert werden. In einem anderen Beispiel kann Firmware, die in Übereinstimmung mit einem im Voraus konfigurierten Prozessor wirkt, zu einem angemessenen Ausmaß bewirken, dass der Prozessor als ein Spezialprozessor fungiert, bereitgestellt zum Zweck der Ausführung des Verfahrens oder einer angemessenen Abwandlung davon.
In diesem veranschaulichenden Prozess werden nicht einschränkende Beispiele von Fahrzeugdaten und ETA-Berechnungen gezeigt. Der Prozess empfängt GPS-Daten 301 (z. B. Fahrzeugort), Fahrzeuggeschwindigkeit 303 und Fahrzeug-Kraftstoff-/Leistungsstand-Daten 305 vom Fahrzeug (in diesem Fall). In diesem Beispiel ist ein Ziel, für das die ETA zu berechnen ist, bereits bekannt.
Außerdem ist der Prozess in diesem Beispiel imstande, Verkehrsdaten (und außerdem Wetterdaten, falls nützlich) zu empfangen, die zur Bestimmung der Auswirkung des Verkehrs auf die ETA verwendet werden können. In diesem Beispiel verbindet der Prozess mit einem entfernten Verkehrs-/Wetterserver 307 und empfängt die Daten 309 von diesem. Wenn die Verkehrs- und/oder Wetterdaten der Vorrichtung oder dem Fahrzeug bereits von einer anderen Anwendung zur Verwendung bereitgestellt wurden, könnten die Daten als eine Alternative direkt von einer dieser Quellen abgerufen werden.
Basierend auf den empfangenen oder erfassten Daten wird eine neue ETA berechnet 311. Außerdem bestimmt der Prozess in diesem Beispiel, ob der Kraftstoff/die Leistung, der/die zum Erreichen des Ziels erforderlich ist, eine verbleibende Menge über einem im Voraus bestimmten Schwellenwert lässt 313. Wie vorher erwähnt, könnte dieser Schwellenwert fest oder variabel sein, und könnte im Voraus bestimmt oder vom Benutzer abhängig sein. Wenn der verbleibende Kraftstoff/die verbleibende Leistung wahrscheinlich unter dem Schwellenwert liegen wird 313, wird der Prozess eine geschätzt Zeit für einen Tank-/Aufladungsstopp für Berechnungszwecke zur ETA addieren 315. Dies könnte eine sekundäre Berechnung sein (z. B. eine zweite ETA, falls ein Stopp gemacht wird) oder könnte, basierend zum Beispiel auf einer Wahrscheinlich eines Stopp, automatisch zu einer einzelnen ETA-Berechnung addiert werden. Die neue(n) ETA(s) werden mit der vorher aktualisierten ETA (falls vorhanden) verglichen und der Prozess kann dann zum Beispiel wie im beispielhaften Schritt 213 fortfahren.
Wenn der Fahrer in dem vorher präsentierten veranschaulichenden Beispiel des Fahrers, der zu einem Firmenessen fährt, zu Beginn der Fahrt über 25 % verbleibenden Kraftstoff verfügte und geschätzt wurde, dass die Fahrt zu dem Essen 7 % des gesamten möglichen Kraftstoffs verbraucht (was bedeutet, dass 18 % verbleiben), könnte der Prozess die ETA mit einer sekundären ETA von sieben Minuten später mit einer Angabe, dass diese ETA auf einem Tankstopp basiert, aktualisieren. Außerdem könnte der Fahrer gefragt werden, ob Kraftstoff getankt würde oder nicht, und diese Daten könnten zum Verifizieren der primären oder sekundären ETA verwendet werden. Wenn zu Beginn der Fahrt nur 8 % Kraftstoff verblieben wären und prognostiziert wurde, dass der Fahrer 7 % verbraucht, könnte das System entscheiden, automatisch einen Tankstopp in etwaige ETA-Berechnungen aufzunehmen.
4 zeigt einen veranschaulichenden Ereignisaktualisierungsprozess. Hinsichtlich der in dieser Figur beschriebenen veranschaulichenden Ausführungsformen ist zu beachten, dass ein Allzweck-Prozessor zeitweise als ein Spezialprozessor zum Zweck der Ausführung einiger oder sämtlicher der hierin gezeigten beispielhaften Verfahren aktiv wird. Bei der Ausführung von Code, der Anweisungen zum Ausführen einiger oder sämtlicher Schritte des Verfahrens bereitstellt, kann der Prozessor vorübergehend bis zum Zeitpunkt des Abschlusses des Verfahrens als ein Spezialprozessor umfunktioniert werden. In einem anderen Beispiel kann Firmware, die in Übereinstimmung mit einem im Voraus konfigurierten Prozessor wirkt, zu einem angemessenen Ausmaß bewirken, dass der Prozessor als ein Spezialprozessor fungiert, bereitgestellt zum Zweck der Ausführung des Verfahrens oder einer angemessenen Abwandlung davon.
In dem in 4 dargestellten veranschaulichenden Beispiel stellt der Prozess einem Benutzer zum Beispiel beim Verbinden mit einem Computer eine Option bereit, automatische ETA-Aktualisierungen auszuwählen 401. Dies könnte ein freigegebenes Merkmal der Anwendung sein, so dass zum Beispiel, wenn die Anwendung freigegeben ist, automatische ETA-Aktualisierungen freigegeben sind. In einem anderen Beispiel wartet der Prozess darauf, dass ein Benutzer ETA-Aktualisierungen manuell anweist 427 oder automatische Aktualisierungen freigibt, bevor er fortfährt.
Sobald die Aktualisierungen angewiesen wurden, greift der Prozess auf ein oder mehrere Ereignis speichernde Konten des Benutzers zu. Diese können Kalender mobiler Vorrichtungen, PC-Kalender, Konten sozialer Medien und beliebige andere Quellen mit aktualisierbaren Kalenderinformationen enthalten, sind aber nicht darauf beschränkt. In einigen Beispielen kann, selbst wenn das Ereignis selbst nicht aktualisierbar ist, eine Möglichkeit bestehen, einen oder mehrere andere Teilnehmer zu kontaktieren, die für Zwecke der Einbeziehung als „aktualisierbar“ betrachtet werden können. Oder zum Beispiel, wenn ein aktualisierbares Konto besteht und Ereignisse aus einer nicht aktualisierbaren Quelle einbezogen werden können, und Aktualisierungen einer ETA können alternativ in dem aktualisierbaren Konto veröffentlicht werden. Z. B. empfängt eine Person eine EVITE-Einladung, kann aber eine erwartete Ankunftszeit nicht auf EVITE aktualisieren. Stattdessen kann sich der Prozess entscheiden, FACEBOOK mit der erwarteten Ankunftszeit für das EVITE-Ereignis zu aktualisieren. Der Ereignisplaner kann wissen oder ihm kann mitgeteilt werden, FACEBOOK auf Aktualisierungen zu überprüfen.
Für die Konten, auf die zugegriffen wird, wird der Prozess bevorstehende Ereignisse identifizieren 405. Weitere Einzelheiten in Bezug auf einen nicht einschränkenden Ereignisidentifizierungsprozess werden in Bezug auf 5 bereitgestellt. In diesem Beispiel prüft der Prozess, wenn ein Ereignis die Kriterien für ein „bevorstehendes Ereignis“ erfüllt 405, ob ein gegenwärtiges Fahrzeugziel existiert 413.
Wenn kein gegenwärtiges Ziel vorhanden ist, kann der Prozess annehmen, dass das zeitlich nächste (d. h. nächste bevorstehende) Ereignis das intendierte Ziel ist 415. In diesem Beispiel werden nur Ereignisse mit einem abstimmbaren Ereignisfenster als bevorstehend ausgewählt. Zum Beispiel kann jedes Ereignis an diesem Kalenderdatum als „bevorstehend“ angesehen werden, aber es ist weniger wahrscheinlich, dass sich ein Benutzer am Montag mit der Absicht in einem Fahrzeug befindet, zu einem Ereignis zu fahren, das am Freitag beginnt. Der Schwellenwert für „bevorstehende“ Ereignisse kann vom Benutzer auswählbar oder im Voraus definiert sein. In einigen Fällen kann er je nach Ereignis variieren. Zum Beispiel kann der Schwellenwert alle Ereignisse enthalten, die bis zu 2 Stunden vor der geplanten Anfangszeit erreicht werden können. Wenn zum Beispiel ein Benutzer am Montagmittag drei Ereignisse hatte, eines, das zwanzig Minuten entfernt war und um 16 Uhr begann, eines, das vierzig Minuten entfernt war und um 13 Uhr begann, und eines, das vier Tage Fahrt entfernt war und Freitagmittag begann, könnten das zweite und dritte Ereignis aufgenommen werden (weil die ETA für diese Ereignisse basierend auf der gegenwärtigen Zeit innerhalb von zwei Stunden vor dem Beginn des Ereignisses ist, obwohl das Ereignis am Freitag noch vier Tage entfernt ist, wären vier Tage Fahrt erforderlich, um dorthin zu gelangen). Das Ereignis am Montag um 16 Uhr würde erst nach 13:40 in die „bevorstehenden“ Ereignisse aufgenommen werden, basierend auf den in diesem Beispiel verwendeten nicht einschränkenden Parametern. In anderen Beispielen kann der Benutzer das Einbeziehen aller Ereignisse an einem gegebenen Tag, aller Ereignisse innerhalb eines bestimmten Zeitrahmens vorgeben oder einfach im Voraus definierten Systemparametern gestatten, zu bestimmen, welche Ereignisse berücksichtigt werden sollten.
Wenn ein gegenwärtiges Ziel bereits in das Fahrzeug eingegeben wurde, kann der Prozess prüfen, ob das gegenwärtige Ziel mit einem der Ereignisse (bevorstehend oder andere) übereinstimmt. Unter Verwendung der vorstehend beschriebenen drei Ereignisse kann das System zum Beispiel erkennen, dass das eingegebene Ziel tatsächlich mit dem Ereignis am Montag um 16 Uhr korrespondiert 417. Wenn in diesem Beispiel das Ziel mit einem Ereignis in der Kategorie „bevorstehendes Ereignis“ übereinstimmt, kann das System dieses Ziel als das Ereignis verwenden, für das Aktualisierungen bereitgestellt werden 415. Wenn daher zum Beispiel die „bevorstehenden Ereignisse“ das 16-Uhr-Ereignis basierend auf der Definition von bevorstehenden Ereignissen enthalten würde, kann der Prozess das 16-Uhr-Ereignis verwenden, weil es mit einem gegenwärtigen Fahrzeugziel übereinstimmt. Da ein zwischenliegendes Ereignis (das 13-Uhr-Ereignis) vorhanden ist, kann das System außerdem den Fahrer fragen, ob Aktualisierungen alternativ oder zusätzlich für das näherliegende Ereignis bereitgestellt werden sollen.
Wenn das gegenwärtige Ziel nicht mit einem der bevorstehenden Ereignisse übereinstimmt, kann der Prozess den Fahrer darauf aufmerksam machen, dass es basierend auf dem Ziel so aussieht, dass der Fahrer unter Umständen nicht zu dem Ereignis fährt 419. Da das 16-Uhr-Ereignis nicht im Modell der „bevorstehenden Ereignisse“ enthalten war, würde in diesem Beispiel daher keine Übereinstimmung des gegenwärtigen Ziels (das 16-Uhr-Ereignis) mit einem der definierten bevorstehenden Ereignisse bestehen. Da Ziele aus verschiedenen Gründen eingestellt werden können, möchte der Fahrer unter Umständen ein anderes Navigationsziel als das Ereignisziel, weil der Fahrer bereits weiß, wie er zu dem Ereignis fährt. Daher hat der Fahrer in diesem Fall zum Beispiel die Option, den ETA-Aktualisierungsprozess anzuweisen, das Ereignisziel als das ETA-Aktualisierungsziel zu verwenden 421, selbst wenn das tatsächliche Navigationsziel verschieden ist. Zum Beispiel könnte der Fahrer das System anweisen, ETA-Aktualisierungen für das 13-Uhr-Ereignis zu verarbeiten, selbst wenn das Navigationssystem für den Ort des 16-Uhr-Ereignisses eingestellt war.
Wenn der Fahrer sich entscheidet, keines der Ziele bevorstehender Ereignisse als ETA-Aktualisierungsziele zu verwenden, kann der Prozess annehmen, dass der Fahrer diese Ziele nicht besucht. Es kann natürlich auch sein, dass der Fahrer einfach keine ETA-Aktualisierungen zu diesen Zielen möchte oder dass sie ihm egal sind.
Demgemäß fragt der Prozess in diesem Beispiel den Fahrer, ober der Fahrer noch am Ereignis teilnimmt 423. Wenn der Fahrer das Ereignis nicht ignorieren möchte, werden keine weiteren Maßnahmen in Bezug auf dieses Ereignis ergriffen, außer wenn sie explizit angewiesen werden (weil der Fahrer an diesem Punkt im Prozess keine ETA-Aktualisierungen für dieses Ereignis angegeben hat, aber auch, dass das Ereignis nicht ignoriert wird). Stattdessen prüft der Prozess jetzt ein gegenwärtiges Ziel gegen nicht bevorstehende Ereignisse. Da in diesem Beispiel das gegenwärtige Ziel mit dem als nicht bevorstehend klassifizierten Ereignis (16-Uhr-Ereignis) korrespondiert, würde eine Übereinstimmung zwischen Ziel und Ereignisort bestehen 407, und der Prozess könnte das gegenwärtige Ziel 409 als die Grundlage für Ereignisaktualisierungen verwenden 411.
Würde keine Übereinstimmung bestehen (d. h. das gegenwärtige Ziel stimmte nicht mit dem Ort des 16-Uhr-Ereignisses überein), könnte der Prozess fortfahren, Konten zu überprüfen, bis zum Beispiel das 16-Uhr-Ereignis als ein „bevorstehendes Ereignis“ klassifiziert würde und dem Fahrer gegenüber folglich als ein möglicher Kandidat für ETA-Aktualisierung identifiziert wäre 421.
Wenn der Fahrer sich entscheidet, ein bestimmtes bevorstehendes Ereignis zu „ignorieren“, was zum Beispiel Nichtteilnahme angibt, kann der Prozess außerdem den Teilnahmestatus des Fahrers für dieses Ereignis als „nicht teilnehmend“ aktualisieren 425. Dies kann helfen, das Ereignis aus künftiger Betrachtung in ETA-Aktualisierungszyklen auszunehmen.
5 zeigt einen veranschaulichenden Ereignisauswahlprozess. Hinsichtlich der in dieser Figur beschriebenen veranschaulichenden Ausführungsformen ist zu beachten, dass ein Allzweck-Prozessor zeitweise als ein Spezialprozessor zum Zweck der Ausführung einiger oder sämtlicher der hierin gezeigten beispielhaften Verfahren aktiv wird. Bei der Ausführung von Code, der Anweisungen zum Ausführen einiger oder sämtlicher Schritte des Verfahrens bereitstellt, kann der Prozessor vorübergehend bis zum Zeitpunkt des Abschlusses des Verfahrens als ein Spezialprozessor umfunktioniert werden. In einem anderen Beispiel kann Firmware, die in Übereinstimmung mit einem im Voraus konfigurierten Prozessor wirkt, zu einem angemessenen Ausmaß bewirken, dass der Prozessor als ein Spezialprozessor fungiert, bereitgestellt zum Zweck der Ausführung des Verfahrens oder einer angemessenen Abwandlung davon.
In diesem veranschaulichenden Beispiel wird der Prozess „bevorstehende“ Ereignisse aus Ereignissen identifizieren, die in verschiedenen Konten, auf die der Prozess Zugriff hat, veröffentlicht wurden. Der Benutzer kann die Anwendung mit Zugriffsrechten auf bestimmte Konten, von denen Ereignisinformationen bezogen und/oder zu denen ETA-Informationen aktualisiert werden können, vorkonfigurieren. Diese enthalten Kalenderkonten, Konten sozialer Medien, E-Mail-Konten, Textnachrichtenkonten usw., sind aber nicht darauf beschränkt. Einige Konten sind unter Umständen von einigen Prozessen nicht zum Abrufen von Ereignisinformationen verwendbar (d. h. Text ist unter Umständen nur verwendbar, wenn der Prozess bevorstehende Ereignisse aus dem Text extrahieren kann), aber diese Konten können trotzdem noch für Aktualisierungen nutzbar sein und könnten als „Nur-Aktualisierung“-Konten bezeichnet werden.
In diesem Beispiel greift der Prozess auf mindestens ein Konto zu, von dem Informationen erhalten werden können 501. Da das Ereignis abgerufen wird, um eine ETA bereitzustellen, ist eine Identifikation des Ereignisorts erforderlich, das zum Beispiel entweder im Ereignis enthalten ist, aus dem Ereignisnamen identifizierbar ist (z. B. kann ein Profi-Football-Spiel mit dem Teamnamen verwendet werden, um den Ort als das Stadium zu bestimmen) oder vom Benutzer eingegeben wird. In diesem Beispiel werden alle geplanten Ereignisse von dem Konto, auf das zugegriffen wurde, abgerufen 503 und lokal gespeichert 505. Dies könnten zum Beispiel alle Ereignisse an einem gegebenen Tag, in einer gegebenen Woche, in einem gegebenen Monat oder in einer anderen Zeitperiode sein. Wenn weitere Konten verbleiben 507, wird der Prozess für die weitere Ereignisse bereitstellenden Konten wiederholt.
Nachdem die Ereignisse lokal gespeichert wurden, kann der Prozess alle Ereignisse nach Anfangszeit sortieren 509, um eine geordnete Liste bevorstehender Ereignisse zu erhalten. Wenn ein Fenster für „bevorstehende Ereignisse“ definiert wurde (z. B. 2 Stunden), wird der Prozess bestimmen, welche der Ereignisse, falls irgendwelche 511, in das Schwellenwertfenster als „bevorstehend“ fallen 513. Wenn keine Ereignisse in das Fenster fallen 513, kann der Prozess auf eine alternative Ereignisbestimmung zurückgreifen, wie veranschaulichend in 4 dargestellt, beginnend mit Element 407.
Nachdem die „bevorstehenden Ereignisse“ bestimmt wurden, prüft der Prozess, ob ein Navigationsziel eingestellt ist 515. In diesem Beispiel gibt es an diesem Punkt im Prozess mindestens ein Ereignis, von dem bestimmt wurde, dass es die Kriterien für „bevorstehend“ erfüllt. Wenn ein Ziel eingestellt wurde, prüft der Prozess auf eine Übereinstimmung zwischen dem Ziel und einem der bevorstehenden Ereignisse 517. Wenn eine Übereinstimmung gefunden wird, wird mindestens dieses Ereignis mit ETA-Aktualisierungen versehen 519. Wie vorher erwähnt, könnte der Fahrer auch die Option erhalten, Aktualisierungen für andere bevorstehende Ereignisse bereitzustellen, wobei die Aktualisierungen eine Ankunftszeit basierend auf zum Beispiel dem gegenwärtigen Ort des Fahrers und einer Route von diesem Ort zu den anderen Ereignissen aktualisieren würden. Alternativ könnte der ETA-Aktualisierungsprozess, wenn die anderen Ereignisse später als das ausgewählte Ereignis wären, diese ETAs basierend auf der Endzeit des gegenwärtig genutzten Ereignisses + einer Fahrtzeit von diesem Ereignis zu dem oder den nächsten Ereignissen aktualisieren.
Wenn keine Übereinstimmung zwischen dem gegenwärtigen Ziel und irgendwelchen der bevorstehenden Ereignisse besteht, kann der Prozess auf eine Übereinstimmung zwischen dem gegenwärtigen Ziel und einem der heruntergeladenen Ereignisse außerhalb des Schwellenwerts für „bevorstehende Ereignisse“ prüfen 521. Wenn eine Übereinstimmung besteht, kann der Prozess den Fahrer aufmerksam machen 523 und den Fahrer fragen, ob dieses Ereignis (das übereinstimmende Ereignis) als das Ereignis für ETA-Aktualisierung verwendet werden sollte. Falls ja, wird der Prozess dieses Ereignis für ETA-Aktualisierungen verwenden. Wenn der Fahrer eine ETA für dieses Ereignis zu dieser Zeit nicht aktualisieren möchte (zum Beispiel vielleicht, weil das Ereignis noch mehrere Stunden bevorsteht), kann der Prozess damit fortfahren, dem Fahrer die identifizierten bevorstehenden Ereignisse einzeln zur Bestimmung, welches oder welche Ereignisse für ETA-Aktualisierungen zu verwenden sind, präsentieren.
Obwohl in diesen Beispielen nur die ETA eines einzelnen Ereignisses aktualisiert wird, ist es sehr wohl möglich, die ETAs für mehrere Ereignisse basierend auf zum Beispiel, ohne Einschränkung, dem gegenwärtigen Ort des Fahrers und der Zeit zu jedem der Ereignisse von diesem Ort, der Endzeit vorheriger Ereignisse + der Fahrtzeit von diesen Ereignissen zu nächsten Ereignissen oder anderen geeigneten Faktoren zu aktualisieren.
In diesem Beispiel präsentiert der Prozess das zeitlich (oder physikalisch) nächste Ereignis als ein nächstes Ereignis 527 und fragt den Fahrer, ob dieses Ereignis für ETA-Aktualisierungen verwendet werden sollte 529. Wenn der Fahrer die Verwendung dieses Ereignisses bestätigt 531, kann der Prozess Aktualisierungen für dieses Ereignis bereitstellen 533. Wenn der Fahrer die Verwendung dieses Ereignisses ablehnt, kann der Prozess den Fahrer fragen, ob das Ereignis ignoriert wird 535 (d. h. nicht daran teilgenommen wird). Falls ja, kann der Prozess die ETA des Fahrers als „nicht teilnehmend“ aktualisieren 537. Wenn irgendwelche Ereignisse verbleiben 539, wird der Prozess zu einem zeitlich (oder physikalisch) nächsten Ereignis weitergehen und wiederholen, bis keine Ereignisse verbleiben oder ein Ereignis ausgewählt wurde. Wenn kein Ereignis ausgewählt wurde, kann der Prozess enden oder auf einen späteren Zeitpunkt warten, bis Bedingungen für angemessene Ereignisauswahl erfüllt werden.
Während vorstehend beispielhafte Ausführungsformen beschrieben werden, ist es nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen der Erfindung beschreiben. Die in der Patentschrift verwendeten Wörter sind vielmehr Wörter der Beschreibung und nicht der Einschränkung, und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne das Wesen und den Schutzumfang der Erfindung zu verlassen. Zusätzlich können die Merkmale der verschiedenen implementierenden Ausführungsformen 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 Nicht-Patentliteratur

IEEE 802 PAN [0020]
IEEE 802 LAN [0020]
IEEE 802 PAN [0020]
IEEE 1394 [0023]
IEEE 1284 [0023]
IEEE 803.11 [0025]

Claims

System, umfassend: einen Prozessor, konfiguriert zum: Empfangen von Fahrzeuginformationen, die zumindest Ort und Kraftstoffstand enthalten; Bestimmen einer gegenwärtigen geschätzten Ankunftszeit (ETA) zu einem ereignisassoziierten Ziel basierend auf Fahrzeit von dem Ort; Bestimmen einer Auswirkung des Kraftstoffstands auf die gegenwärtige ETA; und Bereitstellen, als Reaktion darauf, dass die gegenwärtige ETA um mehr als eine Schwellenwertabweichung von einer vorherigen ETA abweicht, einer Aktualisierung einer entfernten Partei, die die gegenwärtige ETA enthält.
System nach Anspruch 1, wobei der Prozessor konfiguriert ist zum: Zugreifen auf ein ereignisbereitstellendes Benutzerkonto; Abrufen eines Ereignisses von dem Konto, auf das zugegriffen wurde; und Bestimmen des ereignisassoziierten Ziels in Bezug auf das abgerufene Ereignis.
System nach Anspruch 2, wobei das ereignisassoziierte Ziel basierend auf Abrufen einer Ereignisadresse von dem ereignisbereitstellenden Benutzerkonto bestimmt wird.
System nach Anspruch 2, wobei das ereignisassoziierte Ziel basierend auf Ereignisinformationen bestimmt wird.
System nach Anspruch 2, wobei das ereignisassoziierte Ziel basierend auf Benutzereingabe bestimmt wird.
System nach Anspruch 2, wobei der Prozessor ferner konfiguriert ist, das ereignisbereitstellende Konto mit der gegenwärtigen ETA zu aktualisieren, um die entfernte Aktualisierung bereitzustellen.
System nach Anspruch 6, wobei das ereignisbereitstellende Konto ein Kalenderkonto enthält.
System nach Anspruch 6, wobei das ereignisbereitstellende Konto ein Konto sozialer Medien enthält.
System nach Anspruch 1, wobei der Prozessor konfiguriert ist, eine Benachrichtigung direkt an einen anderen Ereignisteilnehmer als den gegenwärtigen Fahrzeugfahrer zu senden, um die Aktualisierung der entfernten Partei bereitzustellen.
System nach Anspruch 1, wobei der Prozessor konfiguriert ist zum: Schätzen einer Kraftstoffmenge, die am Ziel verbleibt; Vergleichen der verbleibenden geschätzten Kraftstoffmenge mit einem Schwellenwert-Minimum; und Bestimmen der Kraftstoffstand-Auswirkung als eine geschätzte Auftankzeit enthaltend, basierend auf der geschätzten Kraftstoffmenge, die unter dem Schwellenwert-Minimum verbleibt.
Computerimplementiertes Verfahren, umfassend: Empfangen von Fahrzeuginformationen, die zumindest Ort und Kraftstoffstand enthalten; Bestimmen einer gegenwärtigen geschätzten Ankunftszeit (ETA) zu einem ereignisassoziierten Ziel basierend auf Fahrzeit von dem Ort; Bestimmen einer Auswirkung des Kraftstoffstands auf die gegenwärtige ETA; und Bereitstellen, als Reaktion auf Abweichung der gegenwärtigen ETA um mehr als eine Schwellenwertabweichung von einer vorherigen ETA, einer Aktualisierung einer entfernten Partei, die die gegenwärtige ETA enthält.
Verfahren nach Anspruch 11, ferner umfassend: Zugreifen auf ein ereignisbereitstellendes Benutzerkonto; Abrufen eines Ereignisses von dem Konto, auf das zugegriffen wurde; und Bestimmen des ereignisassoziierten Ziels in Bezug auf das abgerufene Ereignis.
Verfahren nach Anspruch 12, wobei das ereignisassoziierte Ziel basierend auf Abrufen einer Ereignisadresse von dem Benutzerkonto bestimmt wird.
Verfahren nach Anspruch 12, wobei das ereignisassoziierte Ziel basierend auf Ereignisinformationen bestimmt wird.
Verfahren nach Anspruch 12, wobei das ereignisassoziierte Ziel basierend auf Benutzereingabe bestimmt wird.
Verfahren nach Anspruch 12, wobei Bereitstellen der entfernten Aktualisierung ferner enthält, das ereignisbereitstellende Konto mit der gegenwärtigen ETA zu aktualisieren.
Verfahren nach Anspruch 16, wobei das ereignisbereitstellende Konto ein Kalenderkonto enthält.
Verfahren nach Anspruch 16, wobei das ereignisbereitstellende Konto ein Konto sozialer Medien enthält.
Verfahren nach Anspruch 11, ferner umfassend: Schätzen einer Kraftstoffmenge, die am Ziel verbleibt; Vergleichen der verbleibenden geschätzten Kraftstoffmenge mit einem Schwellenwert-Minimum; und Bestimmen der Kraftstoffstand-Auswirkung als eine geschätzte Auftankzeit enthaltend, basierend darauf, dass der geschätzte verbleibende Kraftstoff unter dem Schwellenwert-Minimum ist.
Nichtflüchtiges Speichermedium, das Anweisungen speichert, die, wenn sie ausgeführt werden, bewirken, dass ein Prozessor ein Verfahren ausführt, umfassend: Empfangen von Fahrzeuginformationen, die zumindest Ort und Kraftstoffstand enthalten; Bestimmen einer gegenwärtigen geschätzten Ankunftszeit (ETA) zu einem ereignisassoziierten Ziel basierend auf Fahrzeit von dem Ort; Bestimmen einer Auswirkung des Kraftstoffstands auf die gegenwärtige ETA; und Bereitstellen, als Reaktion auf Abweichung der gegenwärtigen ETA um mehr als eine Schwellenwertabweichung von einer vorherigen ETA, einer Aktualisierung einer entfernten Partei, die die gegenwärtige ETA enthält.