DE102014204589A1

DE102014204589A1 - Verfahren und vorrichtung zur einwilligungsabwicklung für einen transfer sicherer daten

Info

Publication number: DE102014204589A1
Application number: DE102014204589.4A
Authority: DE
Inventors: David Chase Mitchell; Julius Marchwicki; Mike Raymond Westra; Elizabeth Halash
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2013-03-15
Filing date: 2014-03-12
Publication date: 2014-09-18
Also published as: US20140282827A1; CN104050421B; CN104050421A

Abstract

Ein fahrzeugbasiertes System weist einen Prozessor auf, der dazu konfiguriert ist, Richtlinientabellenaktualisierungen, die von einem entfernten Server ausgegeben werden, zu empfangen. Der Prozessor ist weiterhin dazu konfiguriert, eine lokale Richtlinientabelle auf der Basis der Aktualisierungen zu aktualisieren. Der Prozessor ist zusätzlich dazu konfiguriert, eine Anforderung von Datenzugriff von einer entfernten Anwendung zu empfangen. Der Prozessor ist weiterhin dazu konfiguriert, auf der Basis der lokalen Richtlinientabelle zu bestimmen, ob der Datenzugriff eine Benutzerzustimmung erfordert. Der Prozessor ist außerdem dazu konfiguriert zu bestimmen, ob die erforderliche Zustimmung in der lokalen Richtlinientabelle gespeichert ist, und Datenzugriff für die entfernte Anwendung auf der Basis der gespeicherten erforderlichen Zustimmung bereitzustellen.

Description

Die veranschaulichenden Ausführungsformen betreffen im Allgemeinen ein Verfahren und eine Vorrichtung zur Einwilligungsabwicklung für einen Transfer sicherer Daten.
Smartphones, Tablet-PC, Laptops und andere tragbare Geräte sind zunehmend dazu in der Lage, eine Verbindung mit anderen entfernten Datenverarbeitungssystemen herzustellen, wie – jedoch nicht darauf beschränkt – ein Fahrzeug-Infotainment-System. Da die Datenverarbeitungs- und Kommunikationsfähigkeiten von Infotainment-Systemen zunehmen, kann es insbesondere wünschenswert sein, dass diese Systeme mit entfernten Geräten und Anwendungen, die auf entfernten Geräten laufen, eine Verbindung herstellen und mit diesen Informationen austauschen.
In einigen Fällen kann ein Informationstransfer den Transfer sicherer oder quasi sicherer Informationen beinhalten, wie – jedoch nicht darauf beschränkt – eine FIN, eine Fahreridentifizierung, einen Fahrerstandort usw. Des Weiteren kann es in Bezug auf den Transfer bestimmter Arten von Informationen vorgeschrieben sein, dass die Informationen nicht ohne eine gewisse Form einer Fahrereinwilligung übertragen werden.
In einer ersten veranschaulichenden Ausführungsform weist ein fahrzeugbasiertes System einen Prozessor auf, der dazu konfiguriert ist, Richtlinientabellenaktualisierungen, die von einem entfernten Server ausgegeben werden, zu empfangen. Der Prozessor ist weiterhin dazu konfiguriert, eine lokale Richtlinientabelle auf der Basis der Aktualisierungen zu aktualisieren. Der Prozessor ist zusätzlich dazu konfiguriert, eine Anforderung von Datenzugriff von einer entfernten Anwendung zu empfangen. Der Prozessor ist weiterhin dazu konfiguriert, auf der Basis der lokalen Richtlinientabelle zu bestimmen, ob der Datenzugriff eine Benutzerzustimmung erfordert. Der Prozessor ist außerdem dazu konfiguriert zu bestimmen, ob die erforderliche Zustimmung in der lokalen Richtlinientabelle gespeichert ist, und Datenzugriff für die entfernte Anwendung auf der Basis der gespeicherten erforderlichen Zustimmung bereitzustellen.
In einer zweiten veranschaulichenden Ausführungsform beinhaltet ein computerimplementiertes Verfahren das Empfangen von Richtlinientabellenaktualisierungen, die von einem entfernten Server ausgegeben werden. Das Verfahren beinhaltet außerdem das Aktualisieren einer lokalen Richtlinientabelle auf der Basis der Aktualisierungen. Das Verfahren beinhaltet weiterhin das Empfangen einer Anforderung von Datenzugriff von einer entfernten Anwendung. Das Verfahren beinhaltet zusätzlich dazu das Bestimmen, ob der Datenzugriff eine Benutzerzustimmung erfordert, auf der Basis der lokalen Richtlinientabelle. Außerdem beinhaltet das Verfahren das Bestimmen, ob die erforderliche Zustimmung in der lokalen Richtlinientabelle gespeichert ist, und das Bereitstellen von Datenzugriff für die entfernte Anwendung auf der Basis der gespeicherten erforderlichen Zustimmung.
In einer dritten veranschaulichenden Ausführungsform speichert ein nichtflüchtiges computerlesbares Speichermedium Befehle, die bei Ausführung durch einen Prozessor bewirken, dass der Prozessor ein Verfahren durchführt, das das Empfangen von Richtlinientabellenaktualisierungen, die von einem entfernten Server ausgegeben werden, beinhaltet. Das Verfahren beinhaltet außerdem das Aktualisieren einer lokalen Richtlinientabelle auf der Basis der Aktualisierungen. Das Verfahren beinhaltet weiterhin das Empfangen einer Anforderung von Datenzugriff von einer entfernten Anwendung. Das Verfahren beinhaltet zusätzlich dazu das Bestimmen, ob der Datenzugriff eine Benutzerzustimmung erfordert, auf der Basis der lokalen Richtlinientabelle. Außerdem beinhaltet das Verfahren das Bestimmen, ob die erforderliche Zustimmung in der lokalen Richtlinientabelle gespeichert ist, und das Bereitstellen von Datenzugriff für die entfernte Anwendung auf der Basis der gespeicherten erforderlichen Zustimmung.
1 zeigt ein veranschaulichendes Fahrzeugdatenverarbeitungssystem;
die 2A–2D zeigen ein veranschaulichendes Beispiel eines umfassenden, nicht einschränkenden Einwilligungsabwicklungssystems und
3 zeigt ein veranschaulichendes Beispiel eines Einwilligungsabwicklungsvorgangs.
Detaillierte Ausführungsformen der vorliegenden Erfindung sind erforderlichenfalls hierin offenbart; es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich beispielhaft für die Erfindung sind, die in verschiedenen und alternativen Formen verkörpert werden kann. Die Figuren sind nicht unbedingt maßstabgetreu; einige Merkmale können übertrieben oder minimiert sein, um Einzelheiten bestimmter Komponenten zu zeigen. Folglich sollten hierin offenbarte spezifische strukturelle und funktionelle Einzelheiten nicht als einschränkend betrachtet werden, sondern lediglich als eine repräsentative Grundlage, um einem Fachmann das verschiedenartige Einsetzen der vorliegenden Erfindung zu lehren.
1 stellt eine beispielhafte Blocktopologie für ein fahrzeugbasiertes Datenverarbeitungssystem (vehicle-based computing system, VCS) 1 für ein Fahrzeug 31 dar. Ein Beispiel eines derartigen fahrzeugbasierten Datenverarbeitungssystems 1 ist das von THE FORD MOTOR COMPANY hergestellte SYNC-System. Ein Fahrzeug, das mit einem fahrzeugbasierten Datenverarbeitungssystem aktiviert ist, kann eine visuelle Front-End-Schnittstelle 4 enthalten, die sich in dem Fahrzeug befindet. Der Benutzer kann auch dazu in der Lage sein, mit der Schnittstelle zu interagieren, wenn sie beispielsweise mit einem Berührungsbildschirm versehen ist. In einer anderen veranschaulichenden Ausführungsform erfolgt die Interaktion durch Tastendrücke, akustische Sprache und Sprachsynthese.
In der in 1 gezeigten veranschaulichenden Ausführungsform 1 steuert ein Prozessor 3 zumindest einen Teil des Betriebs des fahrzeugbasierten Datenverarbeitungssystems. Der in dem Fahrzeug vorgesehene Prozessor ermöglicht die Bordverarbeitung von Befehlen und Routinen. Des Weiteren ist der Prozessor mit sowohl einem nicht-permanenten Speicher 5 und einem permanenten Speicher 7 verbunden. In dieser veranschaulichenden Ausführungsform ist der nicht-permanente Speicher ein Direktzugriffsspeicher (random access memory, RAM) und der permanente Speicher ist ein Festplattenlaufwerk (hard disk drive, HDD) oder ein Flash-Speicher.
Der Prozessor ist außerdem mit einer Reihe unterschiedlicher Eingänge versehen, die dem Benutzer ermöglichen, eine Verbindung mit dem Prozessor herzustellen. In dieser veranschaulichenden Ausführungsform sind ein Mikrofon 29, ein Hilfseingang 25 (für einen Eingang 33), ein USB-Eingang 23, ein GPS-Eingang 24 und ein BLUETOOTH-Eingang 15 alle vorgesehen. Ein Eingangswähler 51 ist ebenfalls vorgesehen, um einem Benutzer zu ermöglichen, zwischen verschiedenen Eingängen zu wechseln. Eine Eingabe in sowohl das Mikrofon als auch den Hilfsanschluss wird durch einen Wandler 27 von analog in digital umgewandelt, bevor sie an den Prozessor geleitet wird. Obwohl nicht gezeigt, können zahlreiche der Fahrzeugkomponenten und Hilfskomponenten in Kommunikation mit dem VCS ein Fahrzeugnetz (wie – jedoch nicht darauf beschränkt – einen CAN-Bus) dazu verwenden, Daten an das und von dem VCS (oder Komponenten davon) zu leiten.
Ausgänge zu dem System können eine optische Anzeige 4 und einen Lautsprecher 13 oder einen Stereosystemausgang beinhalten, sind jedoch 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-Analog-Wandler 9. Eine Ausgabe kann auch zu einem entfernten BLUETOOTH-Gerät, wie einem PND 54, oder einem USB-Gerät, wie einem Fahrzeugnavigationsgerät 60, entlang der bidirektionalen Datenströme, die bei 19 bzw. 21 gezeigt sind, erfolgen.
In einer veranschaulichenden Ausführungsform verwendet das System 1 den BLUETOOTH-Transceiver 15, um mit einem nomadischen Gerät 53 des Benutzers (z. B. Mobiltelefon, Smartphone, PDA oder ein beliebiges anderes Gerät mit drahtloser Remote-Netzkonnektivität) zu kommunizieren 17. Das nomadische Gerät kann dann dazu verwendet werden, mit einem Netz 61 außerhalb des Fahrzeugs 31 durch beispielsweise eine Kommunikation 55 mit einem Mobilfunkmast 57 zu kommunizieren 59. In einigen Ausführungsformen kann der Mast 57 ein WiFi-Zugangspunkt sein.
Eine beispielhafte Kommunikation zwischen dem nomadischen Gerät und dem BLUETOOTH-Transceiver ist durch ein Signal 14 dargestellt.
Das Paaren eines nomadischen Geräts 53 und des BLUETOOTH-Transceivers 15 kann durch eine Taste 52 oder eine ähnliche Eingabe angewiesen werden. Dementsprechend wird der CPU angewiesen, dass der Bord-BLUETOOTH-Transceiver mit einem BLUETOOTH-Transceiver in einem nomadischen Gerät gepaart wird.
Daten können zwischen dem CPU 3 und dem Netz 61 unter Nutzung von beispielsweise einem Datenplan, Data-over-Voice oder DTMF-Tönen, die mit dem nomadischen Gerät 53 in Zusammenhang stehen, kommuniziert werden. Alternativ dazu kann es wünschenswert sein, ein Bordmodem 63 mit einer Antenne 18 zu integrieren, um Daten zwischen dem CPU 3 und dem Netz 61 über das Sprachband zu kommunizieren 16. Das nomadische Gerät 53 kann dann dazu verwendet werden, mit einem Netz 61 außerhalb des Fahrzeugs 31 durch beispielsweise eine Kommunikation 55 mit einem Mobilfunkmast 57 zu kommunizieren 59. In einigen Ausführungsformen kann das Modem 63 eine Kommunikation 20 mit dem Mast 57 zum Kommunizieren mit dem Netz 61 herstellen. Als ein nicht einschränkendes Beispiel kann das Modem 63 ein USB-Mobilfunkmodem sein und die Kommunikation 20 kann eine Mobilfunkkommunikation sein.
In einer veranschaulichenden Ausführungsform ist der Prozessor mit einem Betriebssystem versehen, das eine API beinhaltet, um mit Modemanwendungssoftware zu kommunizieren. Die Modemanwendungssoftware kann auf ein eingebettetes Modul oder Firmware auf dem BLUETOOTH-Transceiver zugreifen, um eine drahtlose Kommunikation mit einem entfernten BLUETOOTH-Transceiver (wie dem in einem nomadischen Gerät vorgefundenen) abzuschließen. Bluetooth ist eine Untermenge der IEEE-802-PAN-Protokolle (PAN = personal area network, persönliches Netz). IEEE-802-LAN-Protokolle (LAN = local area network, lokales Netz) beinhalten WiFi und haben eine beträchtliche Kreuzfunktionalität mit IEEE 802 PAN. Beide sind für eine drahtlose Kommunikation innerhalb eines Fahrzeugs geeignet. Andere Kommunikationsmittel, die in diesem Gebiet verwendet werden können, sind eine optische Freiraumkommunikation (wie IrDA) und nicht standardisierte Verbraucher-IR-Protokolle.
In einer anderen Ausführungsform beinhaltet das nomadische Gerät 53 ein Modem für Sprachband- oder Breitbanddatenkommunikation. In der Data-over-Voice-Ausführungsform kann eine Technik, die als Frequenzmultiplexen bekannt ist, implementiert werden, wobei der Besitzer des nomadischen Geräts über das Gerät sprechen kann, während Daten übertragen werden. Zu anderen Zeitpunkten, wenn der Besitzer das Gerät nicht verwendet, kann der Datentransfer die gesamte Bandbreite (in einem Beispiel 300 Hz bis 3,4 kHz) verwenden. Obgleich Frequenzmultiplexen für analoge Mobilfunkkommunikation zwischen dem Fahrzeug und dem Internet üblich sein mag und immer noch verwendet wird, wurde es weitgehend durch Hybride mit Mehrfachzugriff im Codebereich (Code Domain Multiple Access, CDMA), Mehrfachzugriff im Zeitbereich (Time Domain Multiple Access, TDMA), Mehrfachzugriff im Raumbereich (Space Domain Multiple Access, SDMA) für digitale Mobilfunkkommunikation ersetzt. Dies sind alles ITU-IMT-2000-konforme (3G-konforme) Standards und sie bieten Datenübertragungsgeschwindigkeiten von bis zu 2 Mbs für stationäre oder gehende Benutzer und 385 Kbs für Benutzer in einem sich bewegenden Fahrzeug. 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 einen Datenplan hat, der mit dem nomadischen Gerät in Zusammenhang steht, ist es möglich, dass der Datenplan eine Breitbandübertragung zulässt, und das System könnte eine viel weitere Bandbreite verwenden (wodurch der Datentransfer beschleunigt wird). In noch einer anderen Ausführungsform wird das nomadische Gerät 53 durch ein Mobilfunkkommunikationsgerät (nicht gezeigt) ersetzt, das an dem Fahrzeug 31 installiert ist. In noch einer anderen Ausführungsform kann das NG 53 ein drahtloses LAN-Gerät sein (LAN = local area network, lokales Netz), das zur Kommunikation über beispielsweise (und ohne Einschränkung) ein 802.11g-Netz (d. h. WiFi) oder ein WiMax-Netz fähig ist.
In einer Ausführungsform können eingehende Daten durch das nomadische Gerät über eine Data-over-Voice-Verbindung oder einen Datenplan, durch den Bord-BLUETOOTH-Transceiver und in den internen Prozessor 3 des Fahrzeugs geleitet werden. Im Fall bestimmter temporärer Daten beispielsweise können die Daten auf dem HDD oder einem anderen Speichermedium 7 gespeichert werden, bis zu einem Zeitpunkt, zu dem die Daten nicht mehr benötigt werden.
Zu zusätzlichen Quellen, die eine Verbindung mit dem Fahrzeug herstellen können, zählen ein persönliches Navigationsgerät 54 mit beispielsweise einer USB-Verbindung 56 und/oder einer Antenne 58, ein Fahrzeugnavigationsgerät 60 mit einer USB-Verbindung 62 oder einer anderen Verbindung, ein Bord-GPS-Gerät 24 oder ein entferntes Navigationssystem (nicht gezeigt) mit Konnektivität zu dem Netz 61. USB ist eines einer Klasse von seriellen Vernetzungsprotokollen. IEEE 1394 (FireWire), 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 Gerüst der seriellen Gerät-zu-Gerät-Standards. Die meisten der Protokolle können für entweder elektrische oder optische Kommunikation implementiert werden.
Des Weiteren könnte der CPU in Kommunikation mit einer Vielfalt von anderen Hilfsgeräten 65 stehen. Diese Geräte können durch eine drahtlose Verbindung 67 oder eine drahtgebundene Verbindung 69 verbunden werden. Das Hilfsgerät 65 kann persönliche Media-Player, drahtlose Gesundheitsgeräte, tragbare Computer und dergleichen beinhalten, ist jedoch nicht darauf beschränkt.
Zudem oder alternativ dazu könnte der CPU mit einem fahrzeugbasierten drahtlosen Router 73 unter Verwendung beispielsweise eines WiFi-Transceivers 71 verbunden werden. Dies könnte dem CPU ermöglichen, sich mit Remote-Netzen im Bereich des lokalen Routers 73 zu verbinden.
Zusätzlich zu beispielhaften Vorgängen, die von einem Fahrzeugdatenverarbeitungssystem ausgeführt werden, das sich in einem Fahrzeug befindet, können die beispielhaften Vorgänge in bestimmten Ausführungsformen von einem Datenverarbeitungssystem in Kommunikation mit einem Fahrzeugdatenverarbeitungssystem ausgeführt werden. Ein derartiges System kann ein drahtloses Gerät (z. B. und ohne Einschränkung ein Mobiltelefon) oder ein entferntes Datenverarbeitungssystem (z. B. und ohne Einschränkung ein Server), der durch das drahtlose Gerät verbunden ist, beinhalten, ist jedoch nicht darauf beschränkt. Zusammengefasst können derartige Systeme als mit einem Fahrzeug in Verbindung stehende Datenverarbeitungssysteme (vehicle-associated computing systems, VACS) bezeichnet werden. In bestimmten Ausführungsformen können bestimmte Komponenten des VACS bestimmte Teile eines Vorgangs in Abhängigkeit von der bestimmten Implementierung des Systems durchführen. Beispielhaft und nicht einschränkend, wenn ein Vorgang einen Schritt des Sendens oder Empfangens von Informationen mit einem gepaarten drahtlosen Gerät aufweist, ist es wahrscheinlich, dass das drahtlose Gerät nicht den Vorgang durchführt, da das drahtlose Gerät Informationen nicht mit sich selbst „senden und empfangen“ würde. Ein Durchschnittsfachmann wird verstehen, wann es unangebracht ist, ein bestimmtes VACS für eine gegebene Lösung anzuwenden. In allen Lösungen wird in Erwägung gezogen, dass zumindest das Fahrzeugdatenverarbeitungssystem (vehicle computing system, VCS), das sich in dem Fahrzeug selbst befindet, die beispielhaften Vorgänge durchführen kann.
Neue Landes- und Bundesgesetze könnten von Fahrzeugbesitzern verlangen, dass sie das Teilen von Fahrzeugdaten mit anderen Geräten ausdrücklich autorisieren. Dies kann eine weitere Ebene des Schutzes gegen unautorisierte Datenentfernung bereitstellen und kann dazu dienen, gesetzlich vorgeschriebene Persönlichkeitsrechte zu schützen. Der Umfang und die Art dieser Anforderungen können jedoch eher eine dynamische Form haben und die Einhaltung könnte zu einer Reihe von Aktualisierungen und Änderungen bestehender Protokolle auf einer kontinuierlichen Basis führen.
Gemäß veranschaulichenden Ausführungsform kann ein Administrator Datentypen und Anwendungsabläufe, die eine Authentifizierung erfordern, aktualisieren und definieren, Authentifizierungsbestätigungsdatensätze zu speichern und zusammenzustellen und die Benutzerzustimmung für einen Datentransfer allgemein zu erleichtern. Zustimmungsvereinbarungen können an ein Fahrzeug geliefert und an diesem gesammelt werden, können jedoch auf der Basis aktueller Normen dezentral („remote“) definiert werden.
Änderungen von Zustimmungsvereinbarungen und Datentypen können dezentral unabhängig (falls gewünscht) von Softwareaktualisierungen abgewickelt werden. Des Weiteren können Zustimmungsdatensätze dezentral zur Lieferung auf Anfrage durch Schnittstellensysteme gespeichert werden, so dass, wenn ein Fahrzeug den Besitzer wechselt oder die Zustimmungsvereinbarungen anderweitig unzugänglich sind, Datensätze der Zustimmung bewahrt werden können.
Die 2A–2D zeigen ein veranschaulichendes Beispiel eines umfassenden, nicht einschränkenden Einwilligungsabwicklungssystems. 2A zeigt Vorgänge und die Datenabwicklung in einem Fahrzeugdatenverarbeitungssystemmodul, wobei die Rechtecke Datenelemente darstellen und die Ovale Vorgangsschritte darstellen.
In diesem veranschaulichenden, nicht einschränkenden Beispiel startet ein Fahrer eine Anwendung 201 auf einem entfernten Gerät, das mit einem Fahrzeugdatenverarbeitungssystem verbunden ist, in diesem Fall durch Verwendung des Fahrzeugdatenverarbeitungssystems. Das Starten der Anwendung leitet Anmeldungsberechtigungen 202, einen Zustimmungsdatensatz 203 (der erstellt wird, wenn der Benutzer die Einwilligung zum Transferieren von Daten an die Anwendung bereitstellt) und falls erforderlich eine Anwendungsregistrierungsanforderung 235 (2B).
Die Anwendungsberechtigungen werden an einen Vorgang geleitet, der die Zugriffsgenehmigungen einer bestimmten Anwendung verifiziert 206. Da verschiedene Anwendungen verschiedene Genehmigungen in Bezug auf zugängliche Datentypen, zugängliche Fahrzeugsysteme, API-Funktionsgebrauchsrechte usw. haben, kann der Vorgang die Genehmigungen für die bestimmte gestartete Anwendung prüfen und/oder einstellen.
Das Verifizieren der Anwendungszugriffsgenehmigungen 206 kann auch eine Startanforderung 210 an einen Vorgang zum Konfigurieren eines Anwendungskontextes 211 senden. Diese Kontextkonfiguration 211 kann dabei helfen, Anwendungsprioritäten und Zugriffsrechte festzulegen. Die Kontextkonfiguration 211 kann Gebrauchs- und Fehlerdaten 209 (während die Anwendung sich im Gebrauch befindet) an einen Vorgang zum Aktualisieren und Ersetzen einer lokalen Richtlinientabelle 208 leiten. Der Vorgang 208 zum Aktualisieren/Ersetzen der lokalen Richtlinientabelle kann auch Daten in der Form eines Zustimmungsdatensatzes 203, die aus dem Anwendungsstart 201 resultieren, Gerätedaten 217, die das drahtlos verbundene Mobilfunkgerät betreffen, und aktualisierte Richtlinien 216, die aus einer Kommunikation mit einem entfernten Server zur Richtlinienkonfiguration resultieren, empfangen, die später ausführlicher erörtert werden.
Der Kontextkonfigurationsvorgang 211 kann weiterhin etwaige „Remote Procedure Calls“ (RPC) 213 und LUA-Bibliotheken 212 beide an einen Vorgang zum Erleichtern der Anwendungskommunikation und -ausführung 214 leiten. Die RPC und Bibliotheken können die Anwendung bei der Ausführung und Kommunikation unterstützen, wenn sie in Verbindung mit dem Fahrzeugdatenverarbeitungssystem (vehicle computing system, VCS) läuft.
Zusätzlich dazu kann der Kontextkonfigurationsvorgang 211 einen Nachrichtencode 226 zur Lieferung an einen Fahrer (allein oder in Verbindung mit anderen Nachrichtencodes) leiten. Schließlich kann der Kontextkonfigurationsvorgang 211 in diesem veranschaulichenden Beispiel eine Benachrichtigung über etwaige Genehmigungsänderungen an ein Mobilfunkgerät senden, was in Bezug auf 2B erörtert wird.
Lokale Richtlinienänderungen können durch einen entfernten Server in Kommunikation mit dem Fahrzeugdatenverarbeitungssystem durch ein nomadisches Gerät implementiert werden. Gesichtspunkte dieser Steuerung werden in Bezug auf die 2A–2D in Verbindung mit einer anderen Funktionalität erörtert. In dieser Figur empfängt ein Antwortübermittlungsvorgang 227 (der in diesem Teil des Beispiels eine eingehende Richtlinienaktualisierung übermittelt) eine Nachricht, die etwaige Richtlinienänderungen enthält.
Wenn die Nachricht etwaige Nachrichtencodes für den Fahrer 226 enthält, können diese zur Nachrichtenlieferung 225 gesendet werden. Gleichzeitig können etwaige Nachrichten für das VCS 224 an einen Vorgang 222 zur Übermittlung (Abwicklung) lokaler Nachrichten geleitet werden. Da die Nachrichten 224 sicher sein können, kann der Vorgang 222 zur Übermittlung lokaler Nachrichten die eingehenden Nachrichten bei Bedarf authentifizieren, entschlüsseln und decodieren. Die unverschlüsselte, authentifizierte, decodierte Nachricht 221 kann dann an einen Vorgang geleitet werden, um Nachrichtenkennungen zu validieren 220.
Der Validierungsvorgang 220 kann etwaige empfangene, aktualisierte Richtlinien 216 an einen Vorgang zum Aktualisieren von Richtlinien 208 leiten. Dies hilft dabei sicherzustellen, dass die Richtlinien – wie sie dezentral definiert wurden – in dem Fahrzeug implementiert werden, wenn sie an das Fahrzeug gesendet werden, wodurch das Bewahren der Einhaltung unterstützt wird. Die aktualisierten Richtlinien können auch an eine lokale Richtlinientabelle 207 zur Verwendung durch sowohl den Vorgang 206 zur Verifizierung von Zugriffsgenehmigungen als auch als Reaktion auf eine Anforderung eines Richtlinientabellenaustauschs 205, die von dem entfernten Server ausgegeben wird (später hierin erörtert), geleitet werden. Die Richtlinientabellenaustauschanforderung kann beispielsweise als Reaktion auf ein N-tes Key-On-Ereignis oder unter einem anderen geeigneten Protokoll implementiert werden. Er kann auch einen Speicherauszug lokaler Richtlinien 204 (derzeit umgesetzt) empfangen und diese zusammen 215 mit der Anforderung leiten, so dass der entfernte Server einen akkuraten Speicherauszug lokaler Richtlinien sowie etwaige Zustimmungsdatensätze 203 in der lokalen Richtlinientabelle, wie sie durch den Richtlinientabellenaktualisierungsvorgang 208 aktualisiert wurde, empfängt.
Der Vorgang 205 zum Aktualisieren der lokalen Richtlinien kann eine Anforderung an eine Nachrichtenübermittlungsroutine 218 leiten, die etwaige Nachrichtenkennungen 219 an ein Nachrichtensicherheitsmodul leiten kann. Das Nachrichtensicherheitsmodul wird auch Nachrichtenkennungen von dem Validierungsvorgang 220 empfangen. Zusätzlich dazu kann der Validierungsvorgang einen Nachrichtencode 223 zur Lieferung an einen Fahrer 225, falls erforderlich, leiten.
Die Nachrichtenübermittlungsroutine 218 kann eine Nachricht 228 (beispielsweise die Anforderung zum Aktualisieren der Richtlinie) an ein Nachrichtenwarteschlangenmodul zur Lieferung an einen entfernten Server leiten, wenn eine Verbindung verfügbar ist und die Nachricht „turn“ (Umdrehen) in der Warteschlange oben steht. Das Nachrichtenwarteschlangemodul kann abgehende Nachrichten in die Warteschlange stellen 229 und die aktualisierte Warteschlange 230 an einen Vorgang 231 zum Senden abgehender Nachrichten leiten. Der Sendevorgang 231 kann dann die abgehende Nachricht zu einem passenden Zeitpunkt senden. Da eine Verbindung zu dem entfernten Server nicht immer hergestellt werden kann und da mehrere Systeme versuchen können, abgehende Nachrichten zu senden, kann die Warteschlange das Priorisieren und Liefern von Nachrichten mit einem Schwerpunkt auf eine korrekte Lieferreihenfolge (falls gewünscht) unterstützen.
2B zeigt ein Mobilfunkgerät und ein Remote-Softwaremodul zur sekundären Nachrichtenübermittlung/Anforderungsflussabwicklung. Beide sind beispielhaft und nicht einschränkend und werden lediglich zu Veranschaulichungszwecken bereitgestellt. Das Mobilfunkgerät stellt in diesem Beispiel eine Kommunikationsverbindung für das VCS aus 2A bereit, um mit einem entfernten Server zu sprechen, was später erörtert wird. Dementsprechend empfängt es eine Reihe von Datenelementen von dem VCS und von dem sekundären Abwicklungsmodul und leitet eine Reihe von Datenelementen an das VCS und das sekundäre Abwicklungsmodul.
In diesem Beispiel wird ein RPC 232 (wie beispielsweise eine Anforderung einer aktualisierten Richtlinientabelle) an das Mobilfunkgerät geleitet. Diese asynchrone Nachricht 232 wird von dem Gerät 236 empfangen und eine VCS-Nachricht 241 kann als Teil der Nachricht eingebunden werden. Die VCS-Nachricht kann – falls erforderlich/gewünscht – 240 an einen dritten Teilnehmer geroutet werden, wobei in diesem Fall die Nachricht 246 an den entsprechenden Teilnehmer gesendet wird.
Zusätzlich oder alternativ dazu kann die Nachricht 241 an einen Weiterleitungsvorgang 247 gesendet werden. Der Weiterleitungsvorgang kann als Teil einer OEM-Code-Bibliothek/Anwendung (OEM = original equipment manufacturer, Originalhersteller) bereitgestellt werden, die sich in dem Mobilfunkgerät befindet und die zum Zwecke der Kommunikation zu/von dem entfernten Server bereitgestellt ist. Die Nachricht 249 – falls gewünscht in einer verschlüsselten, codierten, signierten Form – kann an den sekundären Abwicklungsvorgang zur weiteren Verarbeitung gesendet werden.
Der sekundäre Abwicklungsvorgang kann die Nachricht empfangen und etwaige Nachrichtenkennungen validieren 251. Eine validierte Nachricht 252 kann dann an einen anderen Weiterleitungsvorgang 255 zur Weitergabe an den entfernten Server gesendet werden. Eine oder mehrere Nachrichtenkennungen 253 können auch beispielsweise an einen Fehlerabwicklungsvorgang geleitet werden, wenn ein Fehler identifiziert wird, um einen Fehlercode für ein Modul 256 zu erzeugen.
Derselbe sekundäre Vorgang kann eingehende Nachrichten von dem Server empfangen (wie beispielsweise jene, die aktualisierte Richtlinientabellen enthalten) und die Nachrichten an eine mobile Anwendung routen 254. Falls etwaige Nachrichtenkennungen 253, die auf Fehlerzustände hinweisen, in diesen vom Server gesendeten Nachrichten enthalten sind, können diese wiederum von dem Fehlercodiervorgang 256 abgewickelt werden.
Rückmeldenachrichten für das VCS 250 können an die OEM-Anwendung/den OEM-Code gesendet werden, die bzw. der sich auf dem Mobiltelefon befindet und die bzw. der die Nachricht empfängt und das Weiterleiten der Nachricht an das VCS vorbereitet 248. Die verschlüsselte, signierte, codierte Nachricht 242 kann als Teil eines RPC 237 an ein entsprechendes Modul in dem VCS gesendet werden. Die „RPC-Call“- und Begleitdaten 233 können beispielsweise an den Nachrichtenübermittlungsvorgang in dem VCS gesendet werden.
Zusätzlich dazu können etwaige Genehmigungsänderungsbenachrichtigungen, die von VCS-Vorgängen identifiziert werden 234, an das Mobilfunkgerät gesendet werden. Diese Genehmigungsänderungen können die Fähigkeit einer bestimmten Anwendung, mit dem VCS zu interagieren, beeinflussen. Die Genehmigungsänderungen 234 können von dem OEM-Bibliotheksvorgang zur Abwicklung dieser Änderungen 238 empfangen werden und der mobilen Anwendung kann dann ein Satz Genehmigungen 243, wie sie von dem VCS definiert/identifiziert wurden, übergeben werden.
Des Weiteren kann ein Vorgang, der auf dem Mobilfunkgerät läuft, eine Kommunikation mit dem VCS 245 herstellen (zu einem Punkt, der nicht unbedingt mit der anderen Verarbeitung in Verbindung steht). In mindestens einem Beispiel können Kommunikationsherstellungsvorgänge vor einer anderen Kommunikation mit dem VCS ausgeführt werden. Die Berechtigungen einer oder mehrerer mobiler Anwendungen 244 können sich in dem Mobilfunkgerät befinden und können an einen OEM-Bibliotheksvorgang zum Registrieren einer Schnittstelle 239 mobiler Anwendungen geleitet werden. Die Registrierungsanforderung und jegliche Antwort von dem VCS 235 können nach Bedarf zwischen dem VCS und dem Mobilfunkgerät weitergeleitet werden.
2C zeigt ein veranschaulichendes Beispiel mehrerer Remote-Vorgänge (auf OEM-Seite) zur Nachrichtenübermittlung. In diesem veranschaulichenden Beispiel wurde eine Nachricht 257 (wie beispielsweise eine Nachricht, die eine Richtlinientabellenaktualisierung anfordert) von dem sekundären Abwicklungsvorgang weitergeleitet und wird von einem Vorgang auf OEM-Seite empfangen, der die Nachricht auspackt 261. Die Nachricht – in einer decodierten, entschlüsselten, authentifizierten Form 260 – wird dann entsprechend geroutet 262. In dieser veranschaulichenden Ausführungsform wird beispielsweise eine Anforderung 264 zum Austausch der lokalen Richtlinientabelle an einen entfernten Server gesendet, der zur Abwicklung derartiger Anforderungen bestimmt wurde.
Die Nachricht kann auch an ein IVSS-System zum Decodieren 269 und Codieren 268 gesendet werden. Unter Verwendung einer Signatur 272, die von einem GIVIS-System gesendet wurde 271, kann der Vorgang den Schlüssel 270 nehmen und ihn für zum Decodieren 269 und Codieren 268 einer Nachricht 266, 267 verwenden.
Zudem können etwaige abgehende Nachrichten von dem Server hier abgewickelt werden, wie beispielsweise eine aktualisierte Richtlinientabelle 265 als Reaktion auf die Aktualisierungsanforderung. Der Nachrichtenübermittlungsvorgang kann die Nachricht verpacken (codieren, verschlüsseln und signieren) und die Nachricht an den sekundären Abwicklungsvorgang zum entsprechenden Routen, zur Lieferung und zur Fehlererkennung senden.
Schließlich können Nachrichtencodes von der Back-End-Fehlercodierung 258 von dem OEM-Nachrichtenübermittlungsvorgang empfangen werden und können zur entsprechenden Lieferung an andere entfernte Systeme und/oder zurück an das VCS zur Abwicklung/Berichterstellung verpackt werden 263.
2D zeigt eine Rückseiten-Server-Anordnung zur Nachrichtenübermittlung, in diesem Fall Abwicklung von Richtlinientabellenaktualisierungen und Zustimmungsprotokollierung. Nachrichten, wie Richtlinientabellenanforderungen, Zustimmungsvereinbarungen, Gebrauchsdaten usw., werden von dem Server empfangen. Etwaige Ersatzrichtlinientabellen werden nach Bedarf zur späteren Lieferung an das VCS vorbereitet 274. Ein Speicherauszug der lokalen Richtlinientabelle (für das Fahrzeug lokal) 273 wird gesendet, der unter anderem Zustimmungsdatensätze, Gebrauchsdaten und Gerätedaten enthalten kann.
VCS-Gerätedaten können aus dem Richtlinientabellenspeicherauszug extrahiert werden 277 und die Gerätedaten 280 können von einem Administrator dazu verwendet werden, einen Gerätegebrauchsbericht 288 anzusehen. Daten zum Gebrauch der mobilen Anwendung und/oder Fehlerdaten können ebenfalls extrahiert werden 278 und die Gebrauchs-/Fehlerdaten 281 können von dem Administrator dazu verwendet werden, Statistiken/Informationen zum Anwendungsgebrauch und zu Fehlerdaten anzusehen 289. Ebenfalls können in diesem Beispiel Zustimmungsdaten extrahiert und gespeichert werden 279. Dies stellt eine Remote-Datensicherung von Zustimmungsdatensätzen bereit. Zu einem gewünschten Zeitpunkt können die gespeicherten Zustimmungsdatensätze 282 von dem Administrator oder einem beliebigen anderen Teilnehmer, der einen Beleg von Zustimmungsvereinbarungen anfordert, angesehen werden 290.
Zusätzlich dazu ist in diesem Beispiel ein Administrator für das Pflegen und Aktualisieren von Informationen in Bezug auf die Richtlinientabelle verantwortlich. Beispielsweise und ohne Einschränkung kann der Administrator Zustimmungsgruppen verwalten 291. Diese Gruppen können unter anderem verschiedene Datentypen spezifizieren, die Zustimmungsvereinbarungen erfordern, und können in Übereinstimmung mit der OEM-Richtlinie, staatlichen Normen oder in Übereinstimmung mit einer anderen geeigneten Richtlinie (z. B. und ohne Einschränkung vom Benutzer vorgeschriebene „sichere“ Daten) aktualisiert werden.
Der Administrator kann weiterhin elektronische Seriennummern aus der Entwicklung verwalten 292. Des Weiteren kann, wenn Entwickler eine neue Software zur Interaktion mit einem VCS produzieren, diese Software eine gewisse Lizenzform erfordern, um bestimmte Aspekte des VCS zu nutzen oder auf bestimmte Daten zuzugreifen. Lizenzanforderungen können von dem Administrator gebilligt werden 293. Nachrichtencodekartierungen 294 können weiterhin von dem Administrator abgewickelt werden wie auch Nachrichtenmodulkonfigurationsparameter 295.
Alle der verschiedenen Aspekte der VCS-Steuersysteme, die von dem Administrator verwaltet werden können, können von einem Vorgang 274 zur Aktualisierung einer lokalen Richtlinie zum Vorbereiten einer aktualisierten Richtlinientabelle genutzt werden. Beispielsweise und ohne Einschränkung können Zustimmungsgruppen 283, Entwicklungsmodulauflistungen 284, eine Master-Richtlinientabelle 285, die Informationen wie – jedoch nicht darauf beschränkt – Lizenzbilligungen, Nachrichtencodekartierungen 286 und Modulkonfigurationsparameter 287 enthält, alle in den Vorgang 274 zur Aktualisierung der lokalen Richtlinie zum Erstellen einer aktualisierten lokalen Richtlinientabelle eingespeist werden. Die aktualisierte lokale Richtlinientabelle 275, sobald sie vorbereitet wurde, kann zurück an das VCS als eine Ersatzrichtlinientabelle gesendet werden 276.
Obwohl lediglich veranschaulichend und nicht einschränkend und weiterhin nicht erschöpfend zeigt dieses Beispiel mindestens einen verhältnismäßig umfassenden Fall eines robusten Systems zur Abwicklung der Erstellung, Präsentation und Informationssammlung für eine Zustimmungsrichtlinie.
3 zeigt ein veranschaulichendes Beispiel eines Einwilligungsabwicklungsvorgangs. In diesem veranschaulichenden Beispiel versucht ein Benutzer, auf eine Anwendung zuzugreifen, die unter anderem Zugriff auf eine gewisse Form sensibler Daten 301 erfordert. Für die Zwecke dieses Beispiels zählen zu sensiblen Daten Daten, die aus dem einen oder anderen Grund eine Zustimmung eines Benutzers vor dem Transfer von einem Fahrzeug an einen entfernten Anfordernden erfordern.
In diesem veranschaulichenden Ablauf empfängt der Vorgang ein oder mehrere Erfordernisse (beispielsweise und ohne Einschränkung von einem entfernten Server) zur Abwicklung der sensiblen Daten 303. Eine lokale Richtlinientabelle (die eine vor kurzem aktualisierte lokale Richtlinientabelle beinhalten kann) wird geprüft 305, um zu sehen, ob ein Zustimmungseintrag bereits für diese Anwendung und Daten vorliegt 307. Mit anderen Worten, hat der Benutzer zuvor eine Zustimmung für das Transferieren dieser Daten zu dieser Anwendung bereitgestellt.
Wenn kein Eintrag vorliegt, wird eine Zustimmung benötigt, also wird ein Eintrag der lokalen Richtlinientabelle hinzugefügt 309, wenn eine Zustimmung (oder ein Fehlen einer solchen) gespeichert werden kann. Wenn der Zustimmungseintrag vorliegt, ist es möglich, dass eine Richtlinie in Bezug auf diese Daten und Anwendung sich geändert hat. Beispielsweise und ohne Einschränkung ist es möglich, dass zusätzliche Daten, die von der Anwendung angefordert werden, nun einem Zustimmungserfordernis unterliegen. Wenn etwaige neue Richtlinien nicht mit alten Richtlinien (für die eine Zustimmung zuvor bezogen worden sein kann) übereinstimmen 313, fährt der Vorgang damit fort, eine Zustimmungsrichtlinie in der Tabelle zu aktualisieren 311, um die Richtlinien für diese Anwendung auf den neuesten Stand zu bringen.
Wenn eine Zustimmung nicht vorlag oder wenn die Richtlinien sich geändert hatten, wird der Vorgang dann eine Zustimmung von dem Benutzer anfordern 315. In einigen Fällen kann die Zustimmungsanforderung Teil eines Anwendungsstarts sein; in anderen Fällen kann sie ausdrücklich als eine sekundäre Anforderung erforderlich sein. Wenn die Zustimmung gegeben wird 323, kann der Vorgang dann damit fortfahren, ein Zustimmungsprotokoll als Teil der Richtlinientabelle zu aktualisieren 325. Wenn die Zustimmung nicht gegeben wird, kann der Vorgang zusätzlich dazu das Zustimmungsprotokoll aktualisieren 327 und kann dann den Zugriff der Anwendung auf die bestimmten Daten verweigern 329. Welche Auswirkung dies auf eine gegebene Anwendung hat, kann von der Anwendung abhängen.
Andererseits kann es der Fall sein, dass vorherige Zustimmungseinträge und -richtlinien mit dem vorliegenden Protokoll übereinstimmen. In einem derartigen Fall kann der Vorgang prüfen, um festzustellen, ob eine Zustimmung in der Tat zu einem früheren Zeitpunkt gegeben wurde 317. In diesem Beispiel wird, selbst wenn ein Benutzer den Zugriff zuvor verweigert hatte, die Zustimmungsanforderung erneut präsentiert werden, für den Fall, dass der Benutzer seine Meinung geändert hat. In anderen Fällen kann die frühere Ablehnung für spätere Ablehnungen dienen.
Sobald eine Zustimmung gegeben wird (oder aus einem früheren Fall erkannt wird), kann der Vorgang etwaige Gebrauchsdaten zu der laufenden Anwendung protokollieren 319. Gleichzeitig kann, wenn ein beliebiger Zugriff auf sichere Daten angefordert wird, der Vorgang den Zugriff auf die Daten in Übereinstimmung mit der bereitgestellten Zustimmung zulassen 321. Zu einem gewissen Punkt kann es auch wünschenswert sein, den Vorgang etwaige protokollierte Gebrauchsdaten, Richtlinientabellenänderungen usw. melden zu lassen 331.
Obwohl beispielhafte Ausführungsformen oben beschrieben sind, ist nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen der Erfindung beschreiben. Vielmehr sind die in der Spezifikation verwendeten Wörter beschreibende und nicht einschränkende Wörter und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Sinn und Schutzumfang der Erfindung abzuweichen. Darüber hinaus können die Merkmale verschiedener Umsetzungsausfü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-Protokolle [0019]
IEEE-802-LAN-Protokolle [0019]
IEEE 1394 [0022]
IEEE 1284 [0022]

Claims

Fahrzeugbasiertes System, das Folgendes umfasst: einen Prozessor, der zu Folgendem konfiguriert ist: Empfangen von Richtlinientabellenaktualisierungen, die von einem entfernten Server ausgegeben werden; Aktualisieren einer lokalen Richtlinientabelle auf der Basis der Aktualisierungen; Empfangen einer Anforderung von Datenzugriff von einer entfernten Anwendung; Bestimmen, ob der Datenzugriff eine Benutzerzustimmung erfordert, auf der Basis der lokalen Richtlinientabelle; Bestimmen, ob die erforderliche Zustimmung in der lokalen Richtlinientabelle gespeichert ist; und Bereitstellen von Datenzugriff für die entfernte Anwendung auf der Basis der gespeicherten erforderlichen Zustimmung.
System nach Anspruch 1, wobei der entfernte Server ein von einem Originalhersteller gesteuerter Server ist.
System nach Anspruch 1, wobei die Richtlinientabellenaktualisierungen Änderungen von Definitionen von sicheren Daten beinhalten.
System nach Anspruch 3, wobei Definitionen von sicheren Daten sichere Daten betreffen, die Daten beinhalten, die für den Transfer von einem Fahrzeug zu einem entfernten Gerät eine Benutzereinwilligung erfordern.
System nach Anspruch 1, wobei die Anforderung von der entfernten Anwendung von einem Gerät empfangen wird, das drahtlos mit dem Prozessor verbunden ist.
System nach Anspruch 1, wobei der Prozessor weiterhin dazu konfiguriert ist, eine Benutzerzustimmung anzufordern und eine Antwort auf die Anforderung in der lokalen Richtlinientabelle zu speichern.
System nach Anspruch 6, wobei die gespeicherte erforderliche Zustimmung aus einer Benutzerzustimmungsanforderung resultierte, die während einer vorherigen Kommunikationssitzung zwischen dem Prozessor und der entfernten Anwendung ausgegeben wurde.
System nach Anspruch 6, wobei der Prozessor weiterhin dazu konfiguriert ist, die gespeicherte Antwort dem entfernten Server zu melden.