DE102017107795A1

DE102017107795A1 - Fahrzeugcomputersystem zum autorisieren von versicherungs- und zulassungsbescheinigungen

Info

Publication number: DE102017107795A1
Application number: DE102017107795.2A
Authority: DE
Inventors: David Hamilton; Oliver Lei; Andrea Bowes Chowanic
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2016-04-19
Filing date: 2017-04-11
Publication date: 2017-10-19
Also published as: US20170297529A1; CN107451921A

Abstract

Ein Fahrzeugcomputersystem umfasst einen Prozessor, der so konfiguriert ist, dass er einen Fahrer eines Fahrzeugs unter Verwendung von Fahrerprofildaten identifiziert, die von einer Fahrervorrichtung empfangen werden, die mit dem Fahrzeug kommuniziert, und in Reaktion darauf, dass die Fahrerprofildaten und Fahrzeugzulassungsdaten, die von einem Remote-Server empfangen werden, ein Problem mit einer Fahrzeugbescheinigung angeben, Fahren des Fahrzeugs deaktiviert.

Description

TECHNISCHES GEBIET
Die vorliegende Offenbarung betrifft Systeme und Verfahren für ein Fahrzeugcomputersystem, das so konfiguriert ist, dass es in Bezug auf Versicherungs- und Zulassungsbescheinigungen eines Fahrzeugs mit fahrzeugexternen Servern arbeitet.
HINTERGRUND
Es kann sein, dass ein Fahrzeug gültige Versicherungs- und Fahrzeugzulassungsinformationen gemäß lokalen Strafverfolgungsrichtlinien aufweisen muss. Ein Fahrzeug kann so konfiguriert sein, dass es mit verschiedenen Vorrichtungen und Remote-Servern kommuniziert, um Daten auszutauschen. Außerdem kann ein Fahrzeug in der Lage sein, einen Fahrer unter Verwendung verschiedener Fahrervorrichtungen zu identifizieren.
KURZDARSTELLUNG
Eine erste veranschaulichende Ausführungsform offenbart ein Fahrzeugcomputersystem, das einen Prozessor umfasst, der so konfiguriert ist, dass er einen Fahrer eines Fahrzeugs unter Verwendung von Fahrerprofildaten identifiziert, die von einer Fahrervorrichtung empfangen werden, die mit dem Fahrzeug kommuniziert, und in Reaktion darauf, dass die Fahrerprofildaten und Fahrzeugzulassungsdaten, die von einem Remote-Server empfangen werden, ein Problem mit einer Fahrzeugbescheinigung angeben, Fahren des Fahrzeugs deaktiviert.
Eine zweite veranschaulichende Ausführungsform offenbart ein Fahrzeugcomputersystem, das einen Prozessor umfasst, der so konfiguriert ist, dass er einen Fahrer eines Fahrzeugs unter Verwendung von Fahrerprofildaten identifiziert, die von einer Fahrervorrichtung empfangen werden, und basierend auf den Fahrerprofildaten und Fahrzeugbescheinigungsdaten, die von einem Remote-Server empfangen werden, eine Nachricht am Fahrzeugcomputersystem ausgibt, die einen Status einer Fahrzeugversicherungsbescheinigung in Bezug auf den Fahrer angibt, und in Reaktion darauf, dass der Status eine abgelaufene Versicherungsbescheinigung oder einen nicht autorisierten Fahrer angibt, Fahren des Fahrzeugs verhindert.
Eine dritte veranschaulichende Ausführungsform offenbart einen Server, der einen Prozessor umfasst, der so konfiguriert ist, dass er von einer Fahrervorrichtung Fahrerprofildaten, die einen Fahrer in einem Fahrzeug identifizieren, und Fahrzeugbescheinigungsdaten empfängt, die Fahrzeugzulassungsinformationen angeben, und unter Verwendung der Fahrerprofildaten und Fahrzeugbescheinigungsdaten eine Statusnachricht, die eine Fahrzeugfahrerbescheinigung angibt, an einem Fahrzeugcomputersystem des Fahrzeugs ausgibt.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 ist eine veranschaulichende Blocktopologie für ein Fahrzeugcomputersystem (VCS) für ein Fahrzeug.
2 ist eine veranschaulichende Blocktopologie eines Fahrzeugs, das mit der Cloud und einem Webserver interagiert.
3 ist ein Flussdiagramm, welches das Fahrzeugcomputersystem veranschaulicht, das Fahrerzulassungsinformationen verifiziert.
4 ist ein Flussdiagramm, das einen Fahrzeugserver veranschaulicht, der Fahrerzulassungsinformationen verifiziert.
AUSFÜHRLICHE BESCHREIBUNG
Es werden hierin Ausführungsformen der vorliegenden Offenbarung beschrieben. Es versteht sich jedoch von selbst, dass die offenbarten Ausführungsformen lediglich Beispiele sind und andere Ausführungsformen verschiedene und alternative Formen annehmen können. Die Figuren sind nicht unbedingt maßstabsgetreu; einige Merkmale könnten übertrieben oder minimiert sein, um Einzelheiten von bestimmten Komponenten darzustellen. Daher sollen hier offenbarte spezifische strukturelle und funktionelle Einzelheiten nicht als einschränkend interpretiert werden, sondern lediglich als eine repräsentative Basis, um einem Fachmann zu lehren, wie die vorliegende Erfindung auf verschiedene Art und Weise einzusetzen ist. Wie für Durchschnittsfachleute zu erkennen ist, können verschiedene Merkmale, die unter Bezugnahme auf eine beliebige der Figuren veranschaulicht und beschrieben werden, mit Merkmalen kombiniert werden, die in einer oder mehreren anderen Figuren veranschaulicht werden, um Ausführungsformen zu bilden, die nicht ausdrücklich veranschaulicht oder beschrieben werden. Die Kombinationen von veranschaulichten Merkmalen stellen repräsentative Ausführungsformen für typische Anwendungen bereit. Für bestimmte Anwendungen oder Implementierungen könnten jedoch verschiedene Kombinationen und Modifikationen der Merkmale im Einklang mit den Lehren dieser Offenbarung gewünscht sein.
1 veranschaulicht eine beispielhafte Blocktopologie für ein fahrzeuggestütztes Datenverarbeitungssystem 100 (VCS für engl. vehicle based computing system) für ein Fahrzeug 131. Ein Beispiel für solch ein fahrzeuggestütztes Datenverarbeitungssystem 100 ist das SYNC-System, das von THE FORD MOTOR COMPANY hergestellt wird. Ein Fahrzeug, das mit einem fahrzeuggestützten Datenverarbeitungssystem versehen ist, kann eine grafische Frontend-Schnittstelle 104 enthalten, die im Fahrzeug angeordnet ist. Der Benutzer kann außerdem in der Lage sein, mit der Schnittstelle zu interagieren, wenn sie zum Beispiel mit einem Berührungsbildschirm versehen ist. In einer beispielhaften Ausführungsform 100 erfolgt die Interaktion durch Drücken von Tasten, ein sprachliches Dialogsystem mit automatischer Spracherkennung und Sprachsynthese.
In der veranschaulichenden Ausführungsform 100, die in 1 dargestellt ist, steuert ein Prozessor 103 mindestens einen gewissen Teil des Betriebs des fahrzeuggestützten Datenverarbeitungssystems 100. Der innerhalb des Fahrzeugs vorgesehene Prozessor ermöglicht fahrzeuginterne Verarbeitung von Befehlen und Routinen. Ferner ist der Prozessor sowohl mit einem nichtpersistenten 105 als auch einem persistenten Speicher 107 verbunden. In dieser veranschaulichenden Ausführungsform ist der nichtpersistente Speicher ein Direktzugriffsspeicher (RAM), und der persistente Speicher ist ein Festplattenlaufwerk (HDD) oder ein Flash-Speicher. Im Allgemeinen kann ein persistenter (nicht-transitorischer) Speicher alle Formen von Speicher umfassen, welche Daten bewahren, wenn ein Computer oder eine andere Vorrichtung ausgeschaltet wird. Diese umfassen, ohne darauf beschränkt zu sein, HDDs, CDs, DVDs, Magnetbänder, Festkörperlaufwerke, tragbare USB-Laufwerke und jede andere geeignete Form von persistentem Speicher.
Der Prozessor ist außerdem mit einer Anzahl von verschiedenen Eingängen versehen, die es dem Benutzer ermöglichen, über eine Schnittstelle eine Verbindung mit dem Prozessor herzustellen. In dieser beispielhaften Ausführungsform sind ein Mikrofon 129, ein Zusatzeingang 125 (für Eingang 133), ein USB-Eingang 123, ein GPS-Eingang 124, ein Bildschirm 104, der eine Touchscreen-Anzeige sein kann, und ein BLUETOOTH-Eingang 115 vorgesehen. Es ist auch ein Eingangswähler 151 vorgesehen, um einem Benutzer zu ermöglichen, zwischen verschiedenen Eingängen zu wechseln. Sowohl die Eingabe in das Mikrofon als auch in den Zusatzanschluss wird durch einen Wandler 127 von analog in digital umgewandelt, bevor sie zum Prozessor weitergegeben wird. Obwohl nicht dargestellt, können zahlreiche der Fahrzeugkomponenten und Zusatzkomponenten in Kommunikation mit dem VCS ein Fahrzeugnetzwerk (wie beispielsweise einen CAN-Bus, ohne darauf beschränkt zu sein) verwenden, um Daten an das oder von dem VCS (oder Komponenten davon) weiterzugeben.
Ausgänge zum System können eine optische Anzeige 104 und einen Lautsprecher 113 oder einen Stereosystemausgang umfassen, ohne darauf beschränkt zu sein. Der Lautsprecher ist mit einem Verstärker 111 verbunden und empfängt sein Signal vom Prozessor 103 durch einen Digital-Analog-Wandler 109. Die Ausgabe kann zusammen mit den bidirektionalen Datenströmen, die bei 119 bzw. 121 dargestellt sind, auch an eine abgesetzte BLUETOOTH-Vorrichtung, wie beispielsweise eine PND (personal navigation device) 154, oder eine USB-Vorrichtung, wie beispielsweise eine Fahrzeugnavigationsvorrichtung 160, erfolgen.
In einer beispielhaften Ausführungsform verwendet das System 100 den BLUETOOTH-Sendempfänger 115, um mit einer nomadischen Vorrichtung (ND für engl. nomadic device) 153 eines Benutzers (z. B. Zellulartelefon, Smartphone, PDA oder einer beliebigen anderen Vorrichtung mit Anschlussmöglichkeit an ein drahtloses Remote-Netzwerk) zu kommunizieren 117. Die nomadische Vorrichtung kann dann verwendet werden, um mit einem Netzwerk 161 außerhalb des Fahrzeugs 131 zum Beispiel durch Kommunikation 155 mit einem Mobilfunkmast 157 zu kommunizieren 159. In einigen Ausführungsformen kann der Mast 157 ein WiFi-Zugangspunkt sein.
Eine beispielhafte Kommunikation zwischen der nomadischen Vorrichtung und dem BLUETOOTH-Sendeempfänger ist durch das Signal 114 dargestellt.
Die Kopplung einer nomadischen Vorrichtung 153 und des BLUETOOTH-Sendeempfängers 115 kann durch eine Taste 152 oder eine ähnliche Eingabe angewiesen werden. Demgemäß wird die CPU angewiesen, dass der fahrzeuginterne BLUETOOTH-Sendeempfänger mit einem BLUETOOTH-Sendeempfänger in einer nomadischen Vorrichtung gekoppelt wird.
Daten können zum Beispiel unter Verwendung eines Datentarifs, Data-over-Voice oder von DTMF-Tönen, die mit der nomadischen Vorrichtung 153 assoziiert sind, zwischen der CPU 103 und dem Netzwerk 161 kommuniziert werden. Alternativ kann es wünschenswert sein, ein fahrzeuginternes Modem 163 mit einer Antenne 118 einzubeziehen, um Daten zwischen der CPU 103 und dem Netzwerk 161 über das Sprachband zu kommunizieren 116. Die nomadische Vorrichtung 153 kann dann verwendet werden, um mit einem Netzwerk 161 außerhalb des Fahrzeugs 131 zum Beispiel durch Kommunikation 155 mit einem Mobilfunkmast 157 zu kommunizieren 159. In einigen Ausführungsformen kann das Modem 163 Kommunikation 120 mit dem Mast 157 zum Kommunizieren mit dem Netzwerk 161 herstellen. Als ein nicht einschränkendes Beispiel kann das Modem 163 ein zellulares USB-Modem sein, und die Kommunikation 120 kann zellulare Kommunikation sein.
In einer beispielhaften Ausführungsform ist der Prozessor mit einem Betriebssystem versehen, das eine API (application programming interface) umfasst, um mit Modem-Anwendungssoftware zu kommunizieren. Die Modem-Anwendungssoftware kann auf ein eingebettetes Modul oder auf eingebettete Firmware auf dem BLUETOOTH-Sendeempfänger zugreifen, um drahtlose Kommunikation mit einem abgesetzten BLUETOOTH-Sendeempfänger (wie beispielsweise dem, der in einer nomadischen Vorrichtung zu finden ist) durchzuführen. Bluetooth ist ein Teilsatz der IEEE 802 PAN (Netzwerk für den persönlichen Bereich)-Protokolle. IEEE 802 LAN(lokales Netzwerk)-Protokolle umfassen WiFi und weisen eine erhebliche Kreuzfunktionalität mit IEEE 802 PAN auf. Beide sind für drahtlose Kommunikation innerhalb eines Fahrzeugs geeignet. Andere Kommunikationsmittel, die in diesem Bereich verwendet werden können, sind freiraumoptische Kommunikation (wie beispielsweise IrDA) und nichtstandardisierte Consumer IR-Protokolle.
In einer anderen Ausführungsform umfasst die nomadische Vorrichtung 153 ein Modem für Sprachband- oder Breitband-Datenkommunikation. Bei der Data-over-Voice-Ausführungsform kann eine Technik, die als Frequenzmultiplexverfahren bekannt ist, implementiert werden, wenn der Besitzer der nomadischen Vorrichtung über die Vorrichtung sprechen kann, während Daten übertragen werden. Zu anderen Zeiten, wenn der Besitzer die Vorrichtung nicht benutzt, kann der Datentransfer die gesamte Bandbreite (in einem Beispiel 300 Hz bis 3,4k Hz) verwenden. Obwohl das Frequenzmultiplexverfahren für analoge zellulare Kommunikation zwischen dem Fahrzeug und dem Internet üblich sein kann und auch noch verwendet wird, wurde es im Wesentlichen durch Hybride von Codemultiplexzugriff (CDMA), Zeitmultiplexzugriff (TDMA), Raummultiplexzugriff (SDMA) für digitale zellulare Kommunikation ersetzt. Dies sind allesamt ITU IMT-2000(3G)-kompatible Standards und bieten Datenraten von bis zu 2 Mbit/s für stationäre oder gehende Benutzer und 385 kbit/s für Benutzer in einem fahrenden Fahrzeug. 3G-Standards werden nun durch IMT-Advanced (4G) ersetzt, der 100 Mbit/s für Benutzer in einem Fahrzeug und 1 Gbit/s für stationäre Benutzer bietet. Wenn der Benutzer einen Datentarif hat, der mit der nomadischen Vorrichtung assoziiert ist, ist es möglich, dass der Datentarif Breitbandübertragung ermöglicht, und das System eine wesentlich breitere Bandbreite (Beschleunigung des Datentransfers) verwenden könnte. In noch einer anderen Ausführungsform ist die nomadische Vorrichtung 153 durch eine zellulare Kommunikationsvorrichtung (nicht dargestellt) ersetzt, die im Fahrzeug 131 installiert ist. In noch einer weiteren Ausführungsform kann die ND 153 eine WLAN (wireless local area network)-Vorrichtung sein, die zum Beispiel (und ohne Einschränkung) zur Kommunikation über ein 802.11g-Netzwerk (d. h. WiFi) oder ein WiMax-Netzwerk imstande ist.
In einer Ausführungsform können ankommende Daten durch die nomadische Vorrichtung über Data-over-Voice oder einen Datentarif durch den BLUETOOTH-Sendeempfänger an Bord und in den fahrzeuginternen Prozessor 103 übermittelt werden. Im Falle von bestimmten temporären Daten zum Beispiel können die Daten auf dem HDD oder einem anderen Speichermedium 107 solange gespeichert werden, bis die Daten nicht mehr benötigt werden.
Zusätzliche Quellen, die mit dem Fahrzeug über eine Schnittstelle verbunden sein können, umfassen eine persönliche Navigationsvorrichtung 154 zum Beispiel mit einem USB-Anschluss 156 und/oder einer Antenne 158, eine Fahrzeugnavigationsvorrichtung 160 mit einem USB 162 oder einem anderen Anschluss, eine fahrzeuginterne GPS-Vorrichtung 124 oder ein Fernnavigationssystem (nicht dargestellt) mit Anschlussmöglichkeit an das Netzwerk 161. USB ist eines einer Klasse von seriellen Netzwerkprotokollen. Die seriellen IEEE 1394 (FireWire^TM (Apple), i.LINK^TM (Sony) und Lynx^TM (Texas Instruments)), 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 Vorrichtung-Vorrichtung-Standards. Die meisten der Protokolle können für elektrische oder optische Kommunikation implementiert werden.
Ferner könnte die CPU mit einer Vielzahl von anderen Zusatzvorrichtungen 165 in Kommunikation sein. Diese Vorrichtungen können durch eine drahtlose 167 oder drahtgebundene 169 Verbindung angeschlossen sein. Die Zusatzvorrichtungen 165 können persönliche Medienabspielgeräte, drahtlose medizinische Vorrichtungen, tragbare Computer und dergleichen umfassen, ohne darauf beschränkt zu sein.
Außerdem oder alternativ könnte die CPU zum Beispiel unter Verwendung eines WiFi (IEEE 803.11) 71-Sendeempfängers mit einem fahrzeuggestützen drahtlosen Router 173 verbunden sein. Dies könnte der CPU den Anschluss an Remote-Netzwerke in Reichweite des lokalen Routers 173 ermöglichen.
Zusätzlich dazu, dass beispielhafte Prozesse durch ein in einem Fahrzeug befindliches Fahrzeugdatenverarbeitungssystem ausgeführt werden, können die beispielhaften Prozesse in bestimmten Ausführungsformen durch ein Datenverarbeitungssystem in Kommunikation mit einem Fahrzeugdatenverarbeitungssystem ausgeführt werden. Solch ein System kann, ohne darauf beschränkt zu sein, eine drahtlose Vorrichtung (z. B. und ohne Einschränkung ein Mobiltelefon) oder ein abgesetztes Datenverarbeitungssystem (z. B. und ohne Einschränkung einen Server) umfassen, das durch die drahtlose Vorrichtung verbunden ist. Zusammen können solche Systeme als fahrzeugassoziierte Datenverarbeitungssysteme (VACS für engl. vehicle associated computing systems) bezeichnet werden. In bestimmten Ausführungsformen können bestimmte Komponenten des VACSs in Abhängigkeit von der jeweiligen Implementierung des Systems bestimmte Abschnitte eines Prozesses ausführen. Als ein Beispiel und ohne Einschränkung ist es dann, wenn ein Prozess einen Schritt des Sendens oder Empfangens von Informationen mit einer gekoppelten drahtlosen Vorrichtung aufweist, wahrscheinlich, dass den Prozess nicht die drahtlose Vorrichtung ausführt, da die drahtlose Vorrichtung Informationen nicht an und von sich selbst „senden und empfangen“ würde. Ein Durchschnittsfachmann weiß, wann es unangebracht ist, ein bestimmtes VACS auf eine bestimmte Lösung anzuwenden. Bei allen Lösungen ist vorgesehen, dass wenigstens das Fahrzeugdatenverarbeitungssystem (VCS), das sich innerhalb des Fahrzeugs befindet, die beispielhaften Prozesse selbst ausführen kann.
2 ist eine veranschaulichende Blocktopologie eines Fahrzeugs, das mit der Cloud und einem Webserver interagiert. Ein Fahrzeug 201 kann eine Schnittstelle umfassen, um zur Bereitstellung von Funktionalität mit einem Benutzer zu interagieren. Das Fahrzeug 201 kann verwendet werden, um Fahrerzulassungs- und Versicherungsdatensätze der verschiedenen Fahrer im Fahrzeug zu pflegen. Das Fahrzeug kann ein Mobiltelefon oder einen Schlüsselanhänger eines Benutzers verwenden, um zu erfahren, welcher Benutzer genau das Fahrzeug fährt. Das Mobiltelefon kann mit einem Fahrer assoziiert sein und Fahrererkennungsdaten, die den Benutzer identifizieren, während des Kopplungsprozesses an das VCS senden. Der Schlüsselanhänger des Fahrzeugs kann ebenfalls mit einem Fahrer assoziiert sein und Fahrzeugerkennungsdaten beim Einsteigen in das Fahrzeug oder Einschalten der Zündung an das VCS senden. Das VCS kann bestimmen, welcher Fahrer gerade im Fahrzeug ist, um Versicherungs- und Zulassungsinformationen zu vergleichen.
Das VCS des Fahrzeugs kann dem Fahrer erlauben, Versicherungs- und Zulassungsinformationen über eine Schnittstelle des VCS einzugeben. Zum Beispiel kann das VCS eine grafische Schnittstelle umfassen, die Informationen, wie beispielsweise Name, Adresse, Zulassungsnummer, Kraftfahrzeugkennzeichen, Versicherungsinformationen (z. B. Versicherer, Bescheinigungsnummer, Anmeldetag, Ablaufdatum, autorisierte Fahrer, Fahrzeugidentifizierungsnummer (VIN) usw.) und andere Informationen vom Fahrer anfordert. Das VCS kann diese Informationen entweder auf einem nicht-persistenten 105 oder einem persistenten Speicher 107, einschließlich eines HDD- oder USB-Laufwerks, lokal speichern. Das VCS kann außerdem mit der „Cloud“ 203 oder einer beliebigen anderen Art von Servernetz, das für verschiedene Funktionen und Dienste verwendet werden kann, zum Speichern dieser Informationen interagieren. Das VCS kann Fahrzeugzulassungsinformationen oder Versicherungsinformationen unter Verwendung einer eingebetteten Telematikeinheit oder eines fahrzeuginternen Mobiltelefons, das mit dem VCS (z. B. unter Verwendung von Bluetooth) in Kommunikation ist, an die Cloud senden.
Die Fahrzeugzulassung 202 und die Versicherungsinformationen 204 können auch über eine mobile Vorrichtung 205 an die Cloud gesendet werden. Die mobile Vorrichtung 205 kann eine Anwendung zum Unterstützen der Eingabe von Fahrzeugzulassungsdaten 202 oder Versicherungsinformationsdaten 204 umfassen, oder sie kann eine Website zum Eingeben solch einer Anwendung verwenden. Zusätzlich kann das Mobiltelefon 205 verwendet werden, um ein Bild der Fahrzeugzulassung und der Versicherungsinformationen zum Senden an die Cloud 203 aufzunehmen. Die Cloud 203 kann die Bilder analysieren, um die Fahrzeugzulassungsdaten 202 und die Versicherungsinformationsdaten 204 zu extrahieren. Die mobile Vorrichtung 205 kann zum Senden der Fahrzeugzulassungsdaten 202 und der Versicherungsinformationsdaten 204 an die Cloud 203 außerdem mit einem Fahrzeug 201 zusammenarbeiten, das mit einem VCS ausgestattet ist.
Die Fahrzeugzulassung 202 und die Versicherungsinformationen 204 können auch über ein Webportal 207 an die Cloud gesendet werden. Das Webportal 207 kann eine Anwendung zum Unterstützen der Eingabe von Fahrzeugzulassungsdaten 202 oder Versicherungsinformationsdaten 204 sein, oder es kann einfach eine Website zum Eingeben solcher Informationen sein. Das Webportal 207 kann fordern, dass der Benutzer sich und sein Fahrzeug identifiziert, indem es ein Anmeldekonto und die Eingabe einer Fahrzeugidentifizierungsnummer (VIN) verlangt. Das Webportal 207 kann Fahrzeugzulassungsdaten 202 und Versicherungsinformationsdaten 204 sowie jegliche anderen Fahreridentifizierungsdaten oder Fahrzeugidentifizierungsdaten an die Cloud 203 senden.
Die Cloud 203 kann außerdem mit einem Fahrzeugserver 209, wie beispielsweise einem Cloudserver der FORD MOTOR COMPANY, in Kommunikation sein. Der Fahrzeugserver 209 kann in der Lage sein, eine Verbindung mit einem Regierungsserver oder einem Versicherungsserver 211 herzustellen, um relevante Maßnahmen zu bestimmen, die zum Unterhalten des Versicherungs- und Fahrzeugzulassungskontos des Benutzers erforderlich sind. Der Fahrzeugserver 209 kann die Cloud 203 zum Kommunizieren von Daten von der Regierungsbehörde oder Versicherungsagentur 211 an das Fahrzeug 201 verwenden. Der Fahrzeugserver 209 kann basierend auf den von der Regierung oder der Versicherungsgesellschaft 211 gesendeten Daten bestimmen, wann der Benutzer das Fahrzeug anmelden oder die Versicherung erneuern muss. Der Fahrzeugserver 209 kann das Fahrzeug durch Warnhinweise während eines vordefinierten Zeitraums (z. B. 7 Tage, 1 Monat usw.), bevor eine Maßnahme erforderlich ist (z. B. Ablauf der Zulassungs- oder Versicherungsbescheinigung), informieren, wann solch eine Maßnahme in Bezug auf die Bescheinigungen (z. B. Erneuerung) erforderlich ist. Außerdem können andere Fahrzeugdaten vom Fahrzeug 201 an den Fahrzeugserver 209 gesendet werden, darunter Fahrzeugdaten, welche die auf Fahrzeugumgebung (z. B. GPS-Daten, Fahrzeuggeschwindigkeit, Beschleunigungsdaten, Gyroskopdaten, Navigationsdaten, Streckendaten usw.) hinweisen.
3 ist ein Flussdiagramm, welches das Fahrzeugcomputersystem veranschaulicht, das Fahrerzulassungsinformationen verifiziert. Ein Fahrzeugcomputersystem (VCS), wie beispielsweise in 1 offenbart, kann unter Verwendung eines Mobiltelefons oder eines eingebetteten Telematiksystems eine Verbindung mit einem Server herstellen 301. Durch Herstellen einer Verbindung mit dem Server kann das Fahrzeug Daten mit verschiedenen fahrzeugexternen Servern austauschen und an diese kommunizieren. Die Server können zum Sammeln und Verarbeiten von Daten verwendet werden. Der Server kann außerdem Daten oder Anforderungen hinsichtlich Maßnahmen, die an anderen Servern, Fahrzeugen oder Vorrichtungen ergriffen werden sollen, an das Fahrzeug oder den Server senden. Es versteht sich, dass die Beschreibungen von Prozessen, die am Server stattfinden, auch durch das VCS durchgeführt werden können.
Das VCS kann Fahrzeugdaten an den Server senden 303, um dem Benutzer bei der Fahrzeugzulassungs- und Versicherungsbescheinigung zu helfen. Das VCS kann die Fahrzeugzulassungsdaten 202 und die Versicherungsinformationsdaten 204 basierend darauf, dass der Benutzer die erforderlichen Daten in das VCS eingibt, an den Server senden. In einer anderen Ausführungsform kann der Benutzer die Fahrzeugzulassungsdaten 202 und die Versicherungsinformationsdaten 204 in eine mobile Vorrichtung 205 eingeben, die eine Verbindung mit dem VCS herstellen kann, und dann an den Server senden. Andere Ausführungsformen können die Zulassungsdaten 202 und die Versicherungsdaten 204 ohne Verwenden des VCS senden, wie beispielsweise einfach durch Verwenden eines Webportals 207 oder der mobilen Vorrichtung 205 selbst. Die Cloud 203 oder der Fahrzeugserver 209 kann die Zulassungsdaten 202 und die Versicherungsdaten 204 verwenden, um zu bestimmen, ob die Bescheinigungen erneuert werden müssen oder Warnhinweise an den Fahrer erforderlich sind. Das VCS oder der Fahrzeugserver 209 können vordefinierte Zeiten vor dem Ablauf der Bescheinigungen bestimmt haben, um einen Benutzer zu benachrichtigen. Der Server kann Anforderungen für das Fahrzeug zum Ausgeben solcher Warnhinweise senden, oder der Server sendet zum Warnen eines Benutzers Daten an das Fahrzeug, das erkennt, dass die Bescheinigung nicht innerhalb eines vordefinierten Zeitraums ist. Außerdem kann in einigen Ausführungsformen die Cloud 203 oder der Fahrzeugserver 209 Anforderungen oder Daten zur Verarbeitung zurück an das VCS senden oder kommunizieren.
Das VCS kann Daten, die von der Cloud empfangen werden, analysieren, um zu bestimmen, ob die Fahrzeuginformationen richtig sind 305. Zum Beispiel kann der Server 209 Daten an das Fahrzeug senden, das erkennt, dass keine Maßnahmen ergriffen werden müssen. In einem anderen Beispiel kann der Fahrzeugserver 209 eine Anforderung an das VCS senden, eine Nachricht auszugeben, die den Benutzer benachrichtigt, dass die Versicherungsbescheinigung zu einem bestimmten Datum ablaufen kann, so dass eine Maßnahme ergriffen werden muss (darunter z. B. Zahlung der Versicherungsbescheinigung oder Fahrzeuganmeldung unter Verwendung des VCS). Das VCS selbst kann Daten, die durch den Fahrzeugserver 209 oder die Cloud 203 kommuniziert werden, außerdem analysieren, um den Status der Fahrzeuginformationen und -bescheinigungen zu bestimmen. Das VCS kann die Daten verwenden, um basierend auf den Fahrzeugzulassungsdaten 202 und den Versicherungsinformationsdaten 204 zu bestimmen, dass alle Daten in Ordnung sind 307 und keine Maßnahme erforderlich ist. Falls bestimmt wird, dass die Daten in Ordnung sind, kann das VCS entweder selbst oder zusammen mit fahrzeugexternen Servern einfach mit dem Überwachen solcher Daten fortfahren.
Das VCS kann außerdem eine Verbindung zu anderen Vorrichtungen herstellen, um Daten, die von der Vorrichtung empfangen werden, zum Bestimmen von Informationen zu verwenden, die von der Vorrichtung abgeleitet sind. Das Fahrzeug kann eine Smartwatch, ein Mobiltelefon oder einen Schlüsselanhänger eines Fahrers zur Verbindungsherstellung und zum Empfang von Daten verwenden, die den Fahrer angeben. Die Fahrervorrichtung kann mit einem Fahrer assoziiert sein und Fahrerprofildaten, die den Benutzer identifizieren helfen, an das VCS senden. Der Schlüsselanhänger des Fahrzeugs kann ebenfalls mit einem Fahrer assoziiert sein und Fahrzeugprofildaten beim Einsteigen in das Fahrzeug oder Einschalten der Zündung an das VCS senden. Das VCS kann bestimmen, welcher Fahrer gerade im Fahrzeug ist, um Versicherungs- und Zulassungsinformationen zu vergleichen. Demnach kann das VCS nicht nur in der Lage sein, zu gewährleisten, dass eine Bescheinigung für das Fahrzeug gültig ist, sondern auch dass die Bescheinigung zum aktuellen Fahrer gehört, der das Fahrzeug verwendet.
Falls bestimmt wird, dass die Fahrzeugzulassungsdaten 202 oder die Versicherungsinformationsdaten 204 überholt oder abgelaufen sind oder andere Probleme enthalten, kann das VCS über eine Schnittstelle aktualisierte Informationen vom Benutzer anfordern 309. In einem Beispiel kann das Fahrzeug eine Nachricht ausgeben, die einen Fehler oder ein Problem identifiziert und anfordert, dass der Benutzer Informationen in Bezug auf die Fahrzeugzulassungsdaten 202 oder die Versicherungsinformationen 204 hinzufügt, verifiziert oder modifiziert. Der Benutzer kann dann solche angeforderten Informationen über eine Schnittstelle des VCS oder unter Verwendung des Mobiltelefons 205 oder eines Webportals 207 Mobiltelefon eingeben. Das VCS kann solche aktualisierten Informationen 311 empfangen, die es an die Cloud 203 oder den Fahrzeugserver 209 weiterleiten kann.
Das VCS kann dann mit den Fahrzeuginformationen auf Fehler oder Probleme prüfen 313. Das VCS kann die neuen Daten selbst verarbeiten, um zu bestimmen, ob solche Fehler oder Probleme korrekt sind. Zum Beispiel kann das VCS bestimmen, dass eine abgelaufene Bescheinigung verwendet wird, und anfordern, dass der Benutzer eine neue Bescheinigung mit einem entsprechenden Ablaufdatum eingibt. Das VCS kann das aktuelle Datum mit dem Ablaufdatum der Bescheinigung vergleichen, um zu bestimmen, ob die Bescheinigung gültig ist. Wenn das VCS bestimmt, dass die Fahrzeugbescheinigung nicht gültig ist, kann es verhindern, dass der Fahrer das Fahrzeug verwendet oder fährt. Das VCS kann Nachrichten mit der Anforderung, dass das Fahrzeug nicht betrieben werden kann, bis alle Probleme mit der Fahrzeugbescheinigung gelöst sind, über den Kommunikationsbus des Fahrzeugs an verschiedene Fahrzeugsteuerungen senden. Außerdem kann das VCS auch Nachrichten mit der Anforderung, dass das Fahrzeug betrieben werden kann, falls die Probleme mit der Fahrzeugbescheinigung gelöst sind, über den Kommunikationsbus des Fahrzeugs an die Fahrzeugsteuerungen senden. Zum Beispiel kann das VCS eine Nachricht an das Motorsteuermodul (ECM) des Fahrzeugs senden, die das ECM benachrichtigt, dass der Motor nicht gestartet werden oder den Betrieb einstellen sollte. Außerdem kann das VCS das ECM auch benachrichtigen, dass der Motorbetrieb den Betrieb fortsetzen oder aktiviert werden könnte, falls bestimmt wird, dass die Fahrzeugbescheinigung gültig ist oder alle Probleme in Bezug auf die Fahrzeugbescheinigung gelöst sind.
In einer anderen Ausführungsform kann der VCS den Server zum Kommunizieren von Daten zur Verarbeitung verwenden. Der Server kann die aktualisierten Daten, die vom VCS sowie von andern Servern, dem Versicherungsserver oder dem Regierungsserver 211 empfangen werden, zum Bestimmen verwenden, ob irgendwelche Fehler vorliegen. Der Server kann außerdem Daten, die direkt von einem Webportal 207 der einem Smartphone 205 kommuniziert werden, verwenden, um basierend auf den aktualisierten Daten zu bestimmen, ob es noch irgendwelche Fehler gibt.
Das VCS kann dann bestimmen, ob die aktualisierten Informationen in Bezug auf die Fahrzeugbescheinigung richtig sind 315. Das VCS kann die Bestimmung unter Verwendung der Fahrzeugbescheinigungsdaten selbst durchführen, oder das VCS kann die aktualisieren Informationen an den Server senden 316. Falls bestimmt wird, dass die Fahrzeugzulassungsbescheinigung oder die Versicherungsbescheinigung Fehler enthält, kann das VCS eine Fehlernachricht 317 oder eine Statusnachricht ausgeben. Die Meldung kann zum Beispiel angeben, welche Probleme mit der Zulassungs- oder Versicherungsbescheinigung verbunden sind. In einem anderen Beispiel kann die Fehlernachricht, die ausgeben wird 317, angeben, dass der Fahrer, der das Fahrzeug gerade verwendet, nicht zum Verwenden des Fahrzeugs geeignet ist. Zum Beispiel kann eine Versicherungsbescheinigung eines Benutzers keinen Versicherungsschutz für den identifizierten Fahrer umfassen, der das Fahrzeug gerade betreibt. Das VCS kann außerdem in der Lage sein, andere Nachrichten oder Informationen in Bezug auf die Fahrzeugbescheinigung auszugeben. Zum Beispiel kann das VCS eine Schnittstelle umfassen, die eine Eingabetaste zum Aktivieren einer „Schnellzugriffs“-Taste für Versicherungs- oder Zulassungsinformationen umfasst. Auf diese Weise kann der Fahrer in einem Szenario, in dem der Fahrer auf diese Information zugreifen muss, zum Beispiel wenn der Fahrer am Straßenrand angehalten wird, eine Schnittstelle des VCS (z. B. Spracherkennung oder Berührungsbildschirm) zum Ausgeben eines Bildschirms verwenden, um die relevanten Informationen für die Fahrzeugzulassung darzustellen.
4 ist ein Flussdiagramm, das einen Fahrzeugserver veranschaulicht, der Fahrerzulassungsinformationen verifiziert. Der Fahrzeugserver kann zu einem Hersteller des Fahrzeugs gehören, oder er kann ein anderer Typ von Server sein, der Zugriff auf relevante Datenbanken (am Server oder remote gespeichert) zum Verifizieren von Fahrzeugbescheinigungen aufweist. Der Server kann entweder direkt oder durch eine „Cloud“ mit einem Fahrzeug 401 verbunden werden, um Daten zwischen dem Server und dem Fahrzeug zu kommunizieren. Der Server kann nur mit Fahrzeugen desselben Herstellers verbunden sein, während der Server in anderen Ausführungsformen mit Fahrzeugen verschiedener Hersteller in Kommunikation sein kann.
Der Server kann bei Herstellung einer Verbindung Fahrzeugdaten empfangen 403. Der Server kann außerdem in der Lage sein, Daten an das Fahrzeug zu senden, die remote gespeichert werden, oder auf die fahrzeugextern zugegriffen wird. Der Server kann Fahrzeugdaten anfordern, die mit verschiedenen Fahrzeugbescheinigungen verbunden sind, darunter Versicherungsinformationen, Zulassungsinformationen, Fahrerprofildaten und andere Fahrzeugdaten (z. B. VIN, Daten von Sensoren usw.).
Der Server kann Bescheinigungsdaten auch von einem anderen Remote-Server empfangen 405. Außerdem kann der Server andere Daten von Servern empfangen, die bei der Bestimmung des Status der Versicherungs- und Zulassungsbescheinigung des Fahrzeugs helfen können. Zum Beispiel kann der Server Versicherungsdaten von einer Versicherungsagentur oder einem Versicherungsserver empfangen, die/der Fahrzeugversicherungsdaten speichert, die Versicherungsbescheinigungsinformationen des Fahrzeugs angeben. In einem anderen Beispiel kann der Server Fahrzeugzulassungsdaten von einem anderen Server empfangen, wie beispielsweise einem Regierungsserver (z. B. Verkehrsministerium oder Kraftfahrzeugamt), der eine Datenbank von Daten in Bezug auf Fahrzeugzulassungs- und andere Bescheinigungen unterhält. In noch einem anderen Beispiel kann der Server mit einer Regierungsbehörde oder einem Regierungsserver kommunizieren, um Daten in Bezug auf Gesetze und Vorschriften (z. B. Bundesgesetzte oder lokale Vorschriften) zu empfangen, welche die Fahrzeugbescheinigung eines aktuellen Bereichs des Fahrzeugs betreffen.
Der Server kann die Daten analysieren, die von anderen Fahrzeugen und Servern empfangen werden, und bestimmen, ob ein Fehler bei irgendwelchen Fahrzeugbescheinigungen vorliegt 407. Der Server kann zum Beispiel Fahrzeugzulassungsdaten und Fahrzeugversicherungsdaten in Verbindung mit Fahrzeugprofildaten, die vom Fahrzeug empfangen werden, zum Bestimmen verwenden, ob ein autorisierter Fahrer das Fahrzeug verwendet. In einem anderen Beispiel kann der Server unter Verwendung der Fahrzeugzulassungsdaten und anderer Daten bestimmen, ob die Fahrzeugzulassung abgelaufen ist. Zum Beispiel kann der Server das Ablaufdatum einer Fahrzeugbescheinigung extrahieren und sie mit den aktuellen Daten vergleichen, um zu bestimmen, ob die Fahrzeugbescheinigung abgelaufen ist. In noch einem anderen Beispiel kann der Server unter Verwendung der Fahrzeugversicherungsdaten und anderer Daten bestimmen, ob die Fahrzeugversicherungsbescheinigung abgelaufen ist. Falls der Server bestimmt, dass die Fahrzeugbescheinigung gültig ist, kann der Server eine Validierungsnachricht an das Fahrzeug senden 409. Falls der Server bestimmt, dass es Fehler bei oder Probleme mit der Fahrzeugbescheinigung gibt, kann der Server eine Fehlernachricht an das Fahrzeug senden, die solch ein Problem angibt 411. Der Server kann basierend darauf, dass der Server eine Fahrzeugbescheinigung erkennt, eine Anforderung zum Deaktivieren des Fahrens oder Blockieren des Fahrzeugs an das Fahrzeug senden. Die Anforderung kann eine Nachricht zum Verhindern des Fahrens des Fahrzeugs umfassen, die an verschiedenen Fahrzeugsteuerungen empfangen wird. Außerdem kann die Anforderung auch eine Nachricht umfassen, um die Verhinderung des Fahrens des Fahrzeugs aufzuheben und dem Fahrer des Fahrzeugs das Fahren des Fahrzeugs zu erlauben. Zum Beispiel kann der Server eine Nachricht an das ECM des Fahrzeugs senden, um den Betrieb des Fahrzeugs zu erlauben, falls die Fahrzeugbescheinigung gültig ist.
Die hierin offenbarten Prozesse, Verfahren oder Algorithmen können für eine Verarbeitungsvorrichtung, eine Steuerung oder einen Computer, welche/r jede bestehende programmierbare elektronische Steuereinheit oder dedizierte elektronische Steuereinheit umfassen kann, bereitstellbar sein oder dadurch implementiert werden. Ähnlich können die Prozesse, Verfahren oder Algorithmen als Daten und Anweisungen, die durch eine Steuerung oder einen Computer ausgeführt werden können, in vielen Formen gespeichert werden, die, ohne darauf beschränkt zu sein, Informationen, die dauerhaft auf nicht beschreibbaren Speichermedien, wie beispielsweise ROM-Vorrichtungen, gespeichert werden, und Informationen umfassen, die veränderlich auf beschreibbaren Speichermedien, wie beispielsweise Disketten, Magnetbändern, CDs, RAM-Vorrichtungen und anderen magnetischen und optischen Medien, gespeichert werden, umfassen. Die Prozesse, Verfahren oder Algorithmen können auch in einem Objekt implementiert sein, das in Software ausgeführt werden kann. Alternativ können die Prozesse, Verfahren oder Algorithmen ganz oder teilweise unter Verwendung von geeigneten Hardwarekomponenten, wie beispielsweise anwendungsspezifischen integrierten Schaltungen (ASICs), feldprogrammierbaren Gate-Arrays (FPGAs), Zustandsmaschinen, Steuerungen, oder anderen Hardwarekomponenten oder -vorrichtungen oder einer Kombination von Hardware-, Software- und Firmwarekomponenten implementiert sein.
Die in der Spezifikation verwendeten Ausdrücke sind beschreibende statt einschränkende Ausdrücke, und es versteht sich von selbst, dass verschiedene Änderungen vorgenommen werden können, ohne vom Wesen und Schutzbereich der Offenbarung abzuweichen. Wie bereits erwähnt, können die Merkmale von verschiedenen Ausführungsformen kombiniert werden, um weitere Ausführungsformen der Erfindung zu bilden, die möglicherweise nicht ausdrücklich beschrieben oder veranschaulicht werden. Für Durchschnittsfachleute ist zu erkennen, dass, obwohl verschiedene Ausführungsformen so hätten beschrieben werden können, dass sie gegenüber anderen Ausführungsformen oder Implementierungen des Standes der Technik in Bezug auf eine oder mehrere gewünschte Charakteristiken Vorteile bereitstellen oder bevorzugt werden, auf ein oder mehr Merkmale oder eine oder mehr Charakteristiken verzichtet werden kann, um gewünschte Gesamtsystemeigenschaften zu erreichen, welche von der spezifischen Anwendung und Implementierung abhängen. Diese Eigenschaften können Kosten, Festigkeit, Haltbarkeit, Lebenszykluskosten, Vermarktbarkeit, Erscheinung, Verpackung, Größe, Gebrauchstauglichkeit, Gewicht, Herstellbarkeit, leichte Montage usw. umfassen, ohne darauf beschränkt zu sein. Entsprechend liegen Ausführungsformen, die als weniger wünschenswert als andere Ausführungsformen oder Implementierungen des Standes der Technik in Bezug auf eine oder mehr Charakteristiken beschrieben wurden, nicht außerhalb des Schutzbereichs der Offenbarung und können für bestimmte Anwendungen wünschenswert sein.
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 [0019]
IEEE 802 LAN [0019]
802.11g-Netzwerk [0020]
IEEE 1394 [0022]
IEEE 1284 [0022]
IEEE 803.11 [0024]

Claims

Fahrzeugcomputersystem, umfassend: einen Prozessor, der so konfiguriert ist, dass er einen Fahrer eines Fahrzeugs unter Verwendung von Fahrerprofildaten identifiziert, die von einer Fahrervorrichtung empfangen werden, die mit dem Fahrzeug kommuniziert, und in Reaktion darauf, dass die Fahrerprofildaten und Fahrzeugzulassungsdaten, die von einem Remote-Server empfangen werden, ein Problem mit einer Fahrzeugbescheinigung angeben, Fahren des Fahrzeugs deaktiviert.
Fahrzeugcomputersystem nach Anspruch 1, wobei der Prozessor ferner so konfiguriert ist, dass er das Problem zur Anzeige ausgibt.
Fahrzeugcomputersystem nach Anspruch 1, wobei der Prozessor ferner so konfiguriert ist, dass er eine Fehlernachricht zur Anzeige ausgibt, die eine Anforderung zusätzlicher Informationen in Bezug auf die Fahrzeugbescheinigung angibt.
Fahrzeugcomputersystem nach Anspruch 1, wobei das Problem ein nicht autorisierter Fahrer des Fahrzeugs ist, der die Fahrerprofildaten und Fahrzeugzulassungsdaten verwendet.
Fahrzeugcomputersystem nach Anspruch 1, wobei der Prozessor ferner so konfiguriert ist, dass er in Reaktion auf Fahrzeugversicherungsdaten, die von einem Remote-Server empfangen werden, Fahren des Fahrzeugs deaktiviert.
Fahrzeugcomputersystem, umfassend: einen Prozessor, der so konfiguriert ist, dass er einen Fahrer eines Fahrzeugs unter Verwendung von Fahrerprofildaten identifiziert, die von einer Fahrervorrichtung empfangen werden, und basierend auf den Fahrerprofildaten und Fahrzeugbescheinigungsdaten, die von einem Remote-Server empfangen werden, eine Nachricht am Fahrzeugcomputersystem ausgibt, die einen Status einer Fahrzeugversicherungsbescheinigung in Bezug auf den Fahrer angibt, und in Reaktion darauf, dass der Status eine abgelaufene Versicherungsbescheinigung oder einen nicht autorisierten Fahrer angibt, Fahren des Fahrzeugs verhindert.
Fahrzeugcomputersystem nach Anspruch 6, wobei der Prozessor ferner so konfiguriert ist, dass er eine Fahrzeugsteuerung blockiert oder deaktiviert, wenn der Status der Fahrzeugversicherungsbescheinigung eine abgelaufene Versicherungsbescheinigung oder einen nicht autorisierten Fahrer angibt.
Fahrzeugcomputersystem nach Anspruch 6, wobei der Prozessor ferner so konfiguriert ist, dass er die Fahrerprofildaten an den Server sendet, um unter Verwendung der Fahrzeugbescheinigungsdaten und der Fahrerprofildaten zu bestimmen, dass ein autorisierter Fahrer das Fahrzeug betreibt.
Fahrzeugcomputersystem nach Anspruch 6, wobei die Fahrervorrichtung von mindestens einem von einem Mobiltelefon, einer Smartwatch oder einem Schlüsselanhänger empfangen wird.
Fahrzeugcomputersystem nach Anspruch 6, wobei der Prozessor ferner so konfiguriert ist, dass er in Reaktion auf den Status der Fahrzeugbescheinigung Anweisungen an einen Punkt von Interesse ausgibt.
Fahrzeugcomputersystem nach Anspruch 10, wobei der Punkt von Interesse eine Fahrzeugzulassungsbehörde ist, wenn der Status der Fahrzeugbescheinigung ein Problem angibt.
Fahrzeugcomputersystem nach Anspruch 6, wobei die Fahrzeugbescheinigungsdaten Fahrzeugversicherungsdaten oder Fahrzeugzulassungsdaten umfassen.
Fahrzeugcomputersystem nach Anspruch 6, wobei der Prozessor ferner so konfiguriert ist, dass er unter Verwendung einer Schnittstelle des Fahrzeugcomputersystems eine Eingabe von Fahrzeugbescheinigungsinformationen empfängt.
Fahrzeugcomputersystem nach Anspruch 6, wobei der Prozessor ferner so konfiguriert ist, dass er die Fahrerprofildaten an den Remote-Server sendet.
Server, umfassend: einen Prozessor, der so konfiguriert ist, dass er von einer Fahrervorrichtung Fahrerprofildaten, die einen Fahrer in einem Fahrzeug identifizieren, und Fahrzeugbescheinigungsdaten empfängt, die Fahrzeugzulassungsinformationen angeben, und unter Verwendung der Fahrerprofildaten und Fahrzeugbescheinigungsdaten eine Statusnachricht, die eine Fahrzeugfahrerbescheinigung angibt, an einem Fahrzeugcomputersystem des Fahrzeugs ausgibt.
Server nach Anspruch 15, wobei die Statusnachricht basierend auf dem Fahrer angibt, dass die Fahrzeugfahrerbescheinigung Probleme aufweist.
Server nach Anspruch 15, wobei die Statusnachricht basierend auf dem Fahrer angibt, dass die Fahrzeugfahrerbescheinigung gültig ist.
Server nach Anspruch 15, wobei der Server so konfiguriert ist, dass er nur mit Fahrzeugen eines gleichen Herstellers kommuniziert.
Server nach Anspruch 15, wobei der Prozessor ferner so konfiguriert ist, dass er Versicherungsbescheinigungsdaten von mindestens einem von einem Fahrzeugserver oder einem Versicherungsserver empfängt.
Server nach Anspruch 15, wobei der Prozessor ferner so konfiguriert ist, dass er Fahrzeugzulassungsdaten von mindestens einem von einem Fahrzeugserver oder einem Regierungsserver empfängt.