DE102022100426A1

DE102022100426A1 - Progressive sperrrichtlinie für einen gerätelosen fahrzeugzugriff und eine entfernte schnittstelle zur verwaltung der sperre

Info

Publication number: DE102022100426A1
Application number: DE102022100426.0A
Authority: DE
Inventors: Ryan Edwin Hanson; Ali Hassani; Hemanth Yadav Aradhyula; John Robert Van Wiemeersch; Hamid Golgiri
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2021-01-11
Filing date: 2022-01-10
Publication date: 2022-07-14
Also published as: US20220219643A1; US11945403B2; CN114758432A

Abstract

Es wird ein Fahrzeug zur verbesserten Benutzerauthentifizierung bereitgestellt. Das Fahrzeug beinhaltet einen biometrischen Sensor und eine Steuerung, die dazu programmiert ist, eine biometrische Authentifizierung eines Benutzers innerhalb einer Nähe eines Fahrzeugs unter Verwendung von Daten, die von dem biometrischen Sensor empfangen werden, einzuleiten und als Reaktion auf das Auftreten einer sekundären Auslösebedingung, die durch den Benutzer eingeleitet wird, um Zugriff auf das Fahrzeug zu erlangen, die Authentifizierung abzuschließen, um dem Benutzer Zugriff zu gewähren oder zu verweigern. Es wird ein System zur entfernten Verwaltung von Sperrzuständen für ein Fahrzeug bereitgestellt. Ein Server ist dazu programmiert, als Reaktion auf das Auftreten eines fehlgeschlagenen Zugriffsversuchs unter Verwendung einer Zugriffsmodalität eine Sperrbenachrichtigung von dem Fahrzeug zu empfangen, wobei die Sperrbenachrichtigung Kontextinformationen in Bezug auf das Auftreten des fehlgeschlagenen Zugriffsversuchs beinhaltet; und als Reaktion auf die Sperrbenachrichtigung eine Angabe einer administrativen Handlung, die von dem Fahrzeug durchgeführt werden soll, zu senden.

Description

GEBIET DER TECHNIK
Aspekte der Offenbarung betreffen im Allgemeinen eine progressive Sperrrichtlinie für einen gerätelosen Fahrzeugzugriff sowie eine entfernte Schnittstelle zum Verwalten von Sperrzuständen.
ALLGEMEINER STAND DER TECHNIK
Funkschlüssel von Fahrzeugen können verwendet werden, um einem Benutzer den Zugriff auf ein Fahrzeug zu gewähren. Einige Funkschlüsselvorrichtungen werden derart betrieben, dass, wenn ein Knopf an dem Funkschlüssel gedrückt wird, die Vorrichtung einen Code an das Fahrzeug sendet, um das Fahrzeug anzuweisen, das Fahrzeug zu entriegeln. Funkschlüssel zum passiven Zugang und passivem Start (passive entry passive start - PEPS) werden betrieben, um eine Antwort auf eine Abfrageimpulsabfolge bereitzustellen, die von dem Fahrzeug gesendet wird, wobei die Tür entriegelt werden kann, wenn eine angemessene Antwort von dem Fahrzeug empfangen wurde, indem ein Benutzer den Türgriff greift.
Es werden Telefon-als-Schlüssel-Systeme (Phone-as-a-key systems - PaaK-Systeme) eingeführt, um es Benutzern zu ermöglichen, ihre Telefone zu nutzen, um ein Fahrzeug zu entriegeln, ohne eine Funkschlüsselvorrichtung zu benötigen. Diese Systeme können ähnlich wie ein Funkschlüssel betrieben werden, wobei das Telefon jedoch über BLUETOOTH LOW ENERGY (BLE), Ultra-Breitband (Ultra-Wide Band - UWB) oder andere Drahtlostechnologien für mobile Vorrichtungen mit dem Fahrzeug kommuniziert.
Tastenfelder können am Äußeren eines Fahrzeugs positioniert sein und können auch dazu verwendet werden, das Fahrzeug zu verriegeln und zu entriegeln. Der Fahrer kann die Tür als Reaktion auf das erfolgreiche Eingeben eines Werkscodes in das Tastenfeld entriegeln, bei dem es sich um einen Code handelt, der eine Abfolge von Zahlen oder anderen derartigen Zeichen beinhaltet. Der Fahrer kann den Werkscode auch dazu verwenden, einen neuen, manchmal als personalisierter Code bezeichneten Code zu programmieren, der sich leichter merken lässt als der Werkscode und zum Entriegeln des Fahrzeugs mit dem Tastenfeld verwendet werden kann.
KURZDARSTELLUNG
In einer ersten veranschaulichenden Ausführungsform ist ein Fahrzeug zur verbesserten Benutzerauthentifizierung bereitgestellt. Das Fahrzeug beinhaltet einen biometrischen Sensor und eine Steuerung mit einem Hardware-Prozessor. Die Steuerung ist dazu programmiert, eine biometrische Authentifizierung eines Benutzers innerhalb einer Nähe eines Fahrzeugs unter Verwendung von Daten, die von dem biometrischen Sensor empfangen werden, einzuleiten und als Reaktion auf das Auftreten einer sekundären Auslösebedingung, die durch den Benutzer eingeleitet wird, um Zugriff auf das Fahrzeug zu erlangen, die Authentifizierung abzuschließen, um dem Benutzer Zugriff zu gewähren oder zu verweigern.
In einer zweiten veranschaulichenden Ausführungsform wird ein Fahrzeug bereitgestellt, das eine progressive Sperre umsetzt. Eine Steuerung beinhaltet einen Hardware-Prozessor und ist dazu programmiert, einen ersten Sperrzähler als Reaktion auf das Auftreten eines fehlgeschlagenen Zugriffsversuchs unter Verwendung einer ersten Zugriffsmodalität zu erhöhen und für einen ersten vordefinierten Zeitraum weitere Authentifizierungsversuche an dem Fahrzeug unter Verwendung der ersten Zugriffsmodalität als Reaktion darauf zu verhindern, dass der erste Sperrzähler einen ersten vordefinierten Wert erreicht. Die Steuerung ist außerdem dazu programmiert, einen zweiten Sperrzähler als Reaktion auf das Auftreten eines zweiten fehlgeschlagenen Zugriffsversuchs unter Verwendung einer zweiten Zugriffsmodalität zu erhöhen und für einen zweiten vordefinierten Zeitraum weitere Authentifizierungsversuche an dem Fahrzeug unter Verwendung der zweiten Zugriffsmodalität als Reaktion darauf zu verhindern, dass der zweite Sperrzähler einen zweiten vordefinierten Wert erreicht.
In einer dritten veranschaulichenden Ausführungsform wird ein System zur entfernten Verwaltung von Sperrzuständen für ein Fahrzeug bereitgestellt. Der Server beinhaltet einen Hardware-Prozessor, der dazu programmiert ist, als Reaktion auf das Auftreten eines fehlgeschlagenen Zugriffsversuchs unter Verwendung einer Zugriffsmodalität eine Sperrbenachrichtigung von dem Fahrzeug zu empfangen, wobei die Sperrbenachrichtigung Kontextinformationen in Bezug auf das Auftreten des fehlgeschlagenen Zugriffsversuchs beinhaltet; und als Reaktion auf die Sperrbenachrichtigung eine Angabe einer administrativen Handlung, die von dem Fahrzeug durchgeführt werden soll, zu senden.
Figurenliste

1 veranschaulicht ein beispielhaftes schlüsselloses Zugangssystem für eine progressive Sperrrichtlinie für einen gerätelosen Zugriff auf ein Fahrzeug sowie eine entfernte Schnittstelle zum Verwalten von Sperrzuständen;
2 veranschaulicht eine beispielhafte Sperrrichtlinie, die durch die Sperrverwaltung des Fahrzeugs umgesetzt wird;
3 veranschaulicht ein Beispiel für administrative Handlungen, die durch den Cloud-Server in Kommunikation mit der Administratorvorrichtung umgesetzt werden;
4 veranschaulicht einen beispielhaften Prozess zur verbesserten biometrischen Benutzerauthentifizierung über eine sekundäre Auslösebedingung;
5 veranschaulicht einen beispielhaften Prozess für den Betrieb der Sperrrichtlinie durch das Fahrzeug; und
6 veranschaulicht einen beispielhaften Prozess für den Betrieb der administrativen Handlungen durch den Cloud-Server.

DETAILLIERTE BESCHREIBUNG
Den Anforderungen entsprechend werden in dieser Schrift detaillierte Ausführungsformen der vorliegenden Erfindung offenbart; es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich beispielhaft für die Erfindung sind, die in vielseitigen und alternativen Formen umgesetzt werden kann. Die Figuren sind nicht unbedingt maßstabsgetreu; einige Merkmale können stark vergrößert oder verkleinert sein, um Details bestimmter Komponenten zu zeigen. Demnach sind in dieser Schrift offenbarte konkrete strukturelle und funktionelle Details nicht als einschränkend auszulegen, sondern lediglich als repräsentative Grundlage, um den Fachmann die vielseitige Verwendung der vorliegenden Erfindung zu lehren.
1 veranschaulicht ein beispielhaftes schlüsselloses Zugangssystem 100, das eine progressive Sperrrichtlinie für einen gerätlosen Zugriff auf ein Fahrzeug 102 sowie eine entfernte Schnittstelle zum Verwalten eines Sperrzustands umsetzt. Im hierin verwendeten Sinne ist ein Sperrzustand eine Situation, in der der Zugriff auf das Fahrzeug 102 verweigert wird, unabhängig davon, ob weitere Zugriffsversuche vorgenommen werden oder ob ein autorisierter Benutzer anwesend ist. In vielen Beispielen gelten Sperren für einen vordefinierten Zeitraum. Es ist jedoch anzumerken, dass in anderen Beispielen eine Sperre beibehalten werden kann, bis eine vordefinierte Handlung erfolgt, wie etwa das Freigeben der Sperre über eine Administratorvorrichtung 144.
Gerätelose Schlüssel, wie etwa Biometrik- oder Tastenfeldauthentifizierungscodes, geben böswilligen Benutzern die Möglichkeit, Brute-Force-Angriffe durchzuführen, um eine Authentifizierung zu erlangen. Herkömmliche Sperrverfahren können zur Tastenfeldauthentifizierung verwendet werden, wie etwa Deaktivierung nach einer vordefinierten Anzahl von falschen Codeeingaben. Diese Ansätze können jedoch für passive, kamerabasierte Biometrik nicht anwendbar sein, die die Möglichkeit des unbeabsichtigten Sperrens des Fahrzeugs beinhalten, nachdem eine bestimmten Anzahl von nicht erkannten Gesichtern an den kamerabasierten Sensoren vorbeigelaufen ist. Somit kann das Fahrzeug 102 eine Richtlinie umsetzen, um die Absicht des Benutzers, in das Fahrzeug 102 einzusteigen, zusammen mit Ansätzen für den Fehlerzustand für vom Benutzer beabsichtigte Anforderungen, die Sperrdauer und das Zurücksetzen des Sperrzustands zu bestimmen. Wenn ein oberer Sperrzustand erreicht wird (d. h. eine vollständige Sperre), kann die Administratorvorrichtung 144 über einen Cloud-Server 138 benachrichtigt werden. Dies kann der Administratorvorrichtung 144 Kontextinformationen und eine Reihe von möglichen durchzuführenden Handlungen darlegen. Diese Handlungen können zum Beispiel ein Zurücksetzen der Sperre ermöglichen, wodurch es der Administratorvorrichtung 144 ermöglicht wird, sofortigen Zugriff zu gewähren, oder können eine Sperrung mit zusätzlichen Authentifizierungsmodalitäten erzwingen, um die Sicherheit zu verbessern.
Das Fahrzeug 102 kann verschiedene Arten von Automobilen, Softroadern (crossover utility vehicle - CUV), Geländelimousinen (sport utility vehicle - SUV), Trucks, Wohnmobilen (recreational vehicle - RV), Booten, Flugzeugen oder anderen mobilen Maschinen zum Befördern von Personen oder Gütern beinhalten. Derartige Fahrzeuge 102 können von Menschen angetrieben oder autonom sein. In vielen Fällen kann das Fahrzeug 102 durch eine Brennkraftmaschine angetrieben werden. Als eine andere Möglichkeit kann das Fahrzeug 102 ein Batterieelektrofahrzeug (battery electric vehicle - BEV) sein, das durch einen oder mehrere Elektromotoren mit Leistung versorgt wird. Als eine weitere Möglichkeit kann das Fahrzeug 102 ein Hybridelektrofahrzeug (hybrid electric vehicle - HEV) sein, das sowohl durch eine Brennkraftmaschine als auch einen oder mehrere Elektromotoren angetrieben wird, wie etwa ein Plug-In-Hybrid-Elektrofahrzeug (plug-in hybrid electrical vehicle - PHEV). Alternativ kann das Fahrzeug 102 ein autonomes Fahrzeug (autonomous vehicle - AV) sein. Der Automatisierungsgrad kann zwischen verschiedenen Stufen der Fahrerassistenztechnologie und einem vollautomatischen, fahrerlosen Fahrzeug variieren. Da die Art und die Konfiguration des Fahrzeugs 102 variieren können, können dementsprechend auch die Eigenschaften des Fahrzeugs 102 variieren. Als einige andere Möglichkeiten können Fahrzeuge 102 unterschiedliche Fähigkeiten in Bezug auf die Fahrgastkapazität, die Schleppfähigkeit und -kapazität und den Stauraum aufweisen. Zu Registrierungszwecken, Inventarzwecken und anderen Zwecken können Fahrzeugen 102 eindeutige Kennungen zugeordnet sein, wie etwa Fahrzeugidentifizierungsnummern (FINs).
Das Fahrzeug 102 beinhaltet eine Karosseriesteuerung 104 in Kommunikation mit einem Funkfrequenz-(RF-)Sendeempfänger 106. Um Zugriff auf das Fahrzeug zu erhalten, nutzt eine Zugriffsvorrichtung 110 in Kommunikation mit dem RF-Sendeempfänger 106 einen Zugriffssendeempfängers 112, der durch eine Batterie 114 angetrieben werden kann. Die Karosseriesteuerung 104 kann auch mit einem Tastenfeld 122 in Kommunikation stehen, sodass die Eingabe eines korrekten Codes in das Tastenfeld 122 Zugriff auf das Fahrzeug 102 gewährt. Die Karosseriesteuerung 104 kann auch mit biometrischen Sensoren 142 in Kommunikation stehen, die einen autorisierten Benutzer des Fahrzeugs 102 identifizieren und Zugriff auf das Fahrzeug 102 gewähren können.
Ein Verriegelungs-/Entriegelungsmechanismus 118 kann betriebsfähig an die Steuerung 104 gekoppelt sein. Die Steuerung 104 kann dazu konfiguriert sein, den Verriegelungs-/Entriegelungsmechanismus 118 zu steuern, um Türen des Fahrzeugs 102 als Reaktion auf die von der Zugriffsvorrichtung 110 übertragenen RF-Signale zu entriegeln/zu verriegeln. Die Zugriffsvorrichtung 110 kann eine oder mehrere Zugriffssteuerungen 120 beinhalten, wie etwa einen Verriegelungsschalter und einen Entriegelungsschalter. Dementsprechend kann die Steuerung 104 den Verriegelungs-/Entriegelungsmechanismus 118 steuern, um die Türen des Fahrzeugs 102 als Reaktion darauf zu verriegeln, dass ein Benutzer eine Verriegelungszugriffssteuerung 120 der Zugriffsvorrichtung 110 herunterdrückt, und die Türen des Fahrzeugs 102 als Reaktion darauf zu entriegeln, dass der Benutzer eine Entriegelungszugriffssteuerung 120 der Zugriffsvorrichtung 110 herunterdrückt.
Die Zugriffsvorrichtung 110 kann in Verbindung mit einem Basisfernzugangssystem, einem PEPS-System oder einem passiven Diebstahlsicherungssystem (Passive Anti-Theft System - PATS) umgesetzt sein. Mit dem PEPS-System kann die Steuerung 104 den Verriegelungs-/Entriegelungsmechanismus 118 steuern, um die Tür als Reaktion darauf zu entriegeln, dass die Steuerung 104 bestimmt, dass sich die Zugriffsvorrichtung 110 in einer vorbestimmten Entfernung von dem Fahrzeug 102 befindet. In einem derartigen Fall überträgt die Zugriffsvorrichtung 110 automatisch (oder passiv) verschlüsselte RF-Signale (z. B. ohne Benutzereingriff), damit die Steuerung 104 die RF-Signale entschlüsseln (oder decodieren) und bestimmen kann, ob sich die Zugriffsvorrichtung 110 innerhalb der vorbestimmten Entfernung befindet und autorisiert ist. mit der PEPS-Umsetzung erzeugt die Zugriffsvorrichtung 110 auch RF-Signale, die codierten Verriegelungs-/Entriegelungssignalen entsprechen, als Reaktion darauf, dass ein Benutzer eine Verriegelungszugriffssteuerung 120 oder eine Entriegelungszugriffssteuerung 120 herunterdrückt. Zusätzlich ist es möglich, dass bei dem PEPS-System kein physischer Schlüssel benötigt wird, um das Fahrzeug 102 zu starten. In diesem Fall kann es erforderlich sein, dass der Benutzer den Bremspedalschalter herunterdrückt oder einen vorbestimmten Vorgang durchführt, bevor ein Startschalter gedrückt wird, nachdem der Benutzer in das Fahrzeug 102 eingestiegen ist. In der PATS-Umsetzung kann die Zugriffsvorrichtung 110 als herkömmlicher Funkschlüssel betrieben werden, um das Fahrzeug 102 zu verriegeln/zu entriegeln. Mit der PATS-Umsetzung wird im Allgemeinen ein physischer Schlüsselhalm (nicht gezeigt) benötigt, um das Fahrzeug 102 zu starten. Der Schlüssel kann einen darin eingebetteten RF-Sender beinhalten, um den Schlüssel dem Fahrzeug 102 gegenüber zu authentifizieren.
In einem anderen Beispiel kann eine mobile Vorrichtung 134 eine Zugriffsanwendung 136 beinhalten, die in einem Speicher der mobilen Vorrichtung 134 installiert ist. Die Zugriffsanwendung 136 kann es dem Benutzer ermöglichen, die mobile Vorrichtung 134 als Zugriffsvorrichtung 110 zu nutzen, um Zugang zum Fahrzeug 102 bereitzustellen. Zusätzlich kann die Zugriffsanwendung 136 in der Lage sein, Informationen von dem Fahrzeug 102 zu empfangen, die z. B.von dem Fahrzeug 102 über das Weitverkehrsnetz 132 unter Verwendung einer Telematiksteuereinheit (telematics control unit - TCU) 130 übertragen werden. In einem Beispiel kann die Zugriffsanwendung 136 dem Benutzer ermöglichen, von dem Fahrzeug 102 Informationen zu empfangen, die die Position des Fahrzeugs 102 angeben, die durch das Fahrzeug 102 unter Verwendung einer Steuerung 140 eines globalen Navigationssatellitensystems (GNSS) bestimmt werden kann.
Es kann jedoch wünschenswert sein, Zugriff auf das Fahrzeug 102 bereitzustellen, ohne dass eine Zugriffsvorrichtung 110 vorhanden sein muss. Zum Beispiel kann ein derartiger geräteloser Zugriff unter Verwendung des Tastenfelds 122 und/oder der biometrischen Sensoren 142 erreicht werden.
Das Tastenfeld 122 kann in elektrischer Kommunikation mit der Steuerung 104 stehen. Das Tastenfeld 122 kann an einem äußeren Abschnitt oder Teilbereich des Fahrzeugs 102 positioniert sein. In einem Beispiel kann das Tastenfeld 122 mit der Steuerung 104 festverdrahtet sein. In einem weiteren Beispiel kann das Tastenfeld 122 in RF-Kommunikation mit der Steuerung 104 stehen. Das Tastenfeld 122 beinhaltet eine Vielzahl mechanischer Pads oder kapazitiver Pads oder anderer Tasten 124a-124n, die numerischen Zeichen, Alphazeichen oder einer beliebigen Kombination aus alphanumerischen Zeichen entsprechen. Somit kann der Benutzer zum Eingeben einer Ziffer eines Zugriffscodes, wie etwa eines persönlichen Codes oder eines Werkscodes, einfach die entsprechende Taste 124 berühren oder drücken.
In einem Beispiel kann das Tastenfeld 122 als Reaktion darauf, dass der Benutzer verschiedene Tasten 124a-124n auswählt, Befehle über festverdrahtete Signale an die Steuerung 104 übertragen, die einer Abfolge von numerischen Zeichen, Alphazeichen oder alphanumerischen Zeichen entsprechen. In einem anderen Beispiel kann das Tastenfeld 122 als Reaktion darauf, dass der Benutzer verschiedene Tasten 124a-124n auswählt, Befehle über RF-Signale an die Steuerung 104 übertragen, die den numerischen Zeichen, Alphazeichen oder alphanumerischen Zeichen entsprechen. Die Steuerung 104 kann den Verriegelungs-/Entriegelungsmechanismus 118 steuern, um die Türen als Reaktion auf das Empfangen der Befehle zu verriegeln/zu entriegeln, z. B.zwei oder mehr Signale (RF oder festverdrahtet), die einer gültigen Sequenz von Alphazeichen, numerischen oder alphanumerischen Zeichen entsprechen.
Das Fahrzeug 102 kann zudem einen oder mehrere biometrische Sensoren 142 beinhalten. Diese können als einige Beispiele einen Fingerabdruckscanner, der zum Identifizieren eines Fingerabdrucks konfiguriert ist, eine Kamera, die zum Identifizieren von Gesichts- oder anderen Merkmalen konfiguriert ist, und/oder ein Audiosystem, das zum Identifizieren eines Sprachabdrucks konfiguriert ist, beinhalten. In einigen Beispielen können die biometrischen Sensoren 142 verwendet werden, um einen Benutzer zu identifizieren, um Zugriff auf das Fahrzeug 102 bereitzustellen.
Die Steuerung 104 kann eine Sperrverwaltung 126 beinhalten. Die Sperrverwaltung 126 kann dazu konfiguriert sein, eine Authentifizierungsanforderung zum Betreten und/oder Starten des Fahrzeugs 102 zu authentifizieren. Zum Beispiel wird bei der PATS-Umsetzung der Schlüssel in einen Zündschalter eingeführt, um das Fahrzeug 102 zu starten. In einem derartigen Fall überträgt der RF-Sender des Schlüssels RF-Signale mit darin verschlüsselten Daten an den Empfänger der Sperrverwaltung 126. Die Sperrverwaltung 126 entschlüsselt die Daten, um den Schlüssel zu authentifizieren, bevor dem Benutzer gestattet wird, das Fahrzeug 102 zu starten. Bei einer PEPS-Umsetzung, wie vorstehend angemerkt, muss kein Schlüssel in einem Schlüsselzylinder gedreht werden, um das Fahrzeug 102 zu starten. In einem derartigen Fall kann die Sperrverwaltung 126 die durch den Zugriffssendeempfänger 112 passiv übertragenen RF-verschlüsselten Daten authentifizieren, um den Benutzerzugriff zu ermöglichen. Mit einer Umsetzung des Tastenfelds 122 kann die Sperrverwaltung 126 validieren, dass der eingegebene Schlüsselcode ein gültiger Code ist, um den Benutzerzugriff zu ermöglichen. Mit biometrischen Sensoren 142 kann die Sperrverwaltung 126 validieren, dass die Biometrik gültig ist, um den Benutzerzugriff zu ermöglichen.
Biometrik stellt eine nahtlose Möglichkeit zum Authentifizieren eines Benutzers für den Fahrzeugzugriff und/oder -start bereit. Wie bei den Zugriffsvorrichtungen 110 kann eine Sperrrichtlinie durch die Sperrverwaltung 126 umgesetzt werden, um die Wahrscheinlichkeit eines Eindringens eines Angreifers zu reduzieren. Zum Beispiel kann die Sperrverwaltung 126 für den Zugriff auf das Tastenfeld 122 eine Anti-Scan-Methodik einsetzen, bei der fünfunddreißig kontinuierliche falsche Tastenbetätigungen an dem Tastenfeld 122 zu einer Sperre des Tastenfelds 122 für eine vordefinierte Unterbrechung führen können. Dies kann erfolgen, um Brute-Force-Angriffe, wie etwa einen Zufallszahlengenerator auf einem Computer, zu verhindern, führt aber gleichzeitig nicht zu einer unerwünschten Kundenerfahrung.
Da jedoch die biometrische Authentifizierung passiv ausgelöst werden kann, kann es für die Sperrverwaltung 126 des Fahrzeugs 102 schwierig sein, zu bestimmen, wann eine passive biometrische Analyse durchgeführt werden sollte. Zum Beispiel können in Bezug auf kamerabasierte biometrische Sensoren 142 (wie etwa Gesichts- oder Iris-Scanner, die Personen in einer nahegelegenen Umgebung identifizieren, um die Latenz zu reduzieren) Personen, die keinen Zugriff auf das Fahrzeug 102 wünschen, im Sichtfeld der biometrischen Sensoren 142 erscheinen. Dies kann zu fehlgeschlagenen Authentifizierungen führen, wenn diese unbeabsichtigten Benutzer als fehlgeschlagene Authentifizierungsversuche identifiziert werden. Das Umsetzen einer Sperre allein auf Grundlage einer fehlgeschlagenen Identifizierung über die biometrischen Sensoren 142 kann daher viele unnötige Sperren verursachen, was die Wahrscheinlichkeit mit sich bringt, dass die auch für einen Kunden, der zu einem unzugänglichen, gesperrten Fahrzeug 102 zurückgekehrt ist, lästig ist.
Somit kann es zusätzlich dazu, dass die Sperrverwaltung 126 die verschlüsselten RF-Daten, den Schlüsselcode und/oder Nutzerbiomerie authentifiziert, für den Benutzer erforderlich sein, einen vorbestimmten Vorgang (z. B. am Griff einer Tür ziehen oder die Tür öffnen, den Bremspedalschalter kippen oder ein anderer Vorgang) durchzuführen, um anzufordern, das Fahrzeug 102 zu betreten und/oder zu starten. Diese vorbestimmten Vorgänge können durch den Sperrverwaltung 126 als Auslöser verwendet werden, um eine Validierung durchzuführen und/oder um sicherzustellen, dass der korrekte vorbestimmte Vorgang als Teil der Benutzerauthentifizierung durchgeführt wird.
Die TCU 130 kann eine Netzwerkhardware beinhalten, die dazu konfiguriert ist, eine Kommunikation zwischen dem Fahrzeug und mit anderen Vorrichtungen des schlüssellosen Zugangssystems 100 zu erleichtern. Die TCU 130 kann zum Beispiel ein Mobilfunkmodem, das dazu konfiguriert ist, eine Kommunikation mit einem Weitverkehrsnetz 132 zu erleichtern, beinhalten oder anderweitig darauf zugreifen. Das Weitverkehrsnetz 132 kann ein oder mehrere miteinander verbundene Kommunikationsnetzwerke, wie etwa als einige nicht einschränkende Beispiele das Internet, ein Kabelfernsehverteilungsnetzwerk, ein Satellitenverbindungsnetzwerk, ein lokales Netzwerk und ein Telefonnetzwerk, beinhalten. Als ein anderes Beispiel kann die TCU 130 eines oder mehrere von einer Vernetzung über ein BLUETOOTH-, UWB-, Wi-Fi- oder drahtgebundenes Universal-Serial-Bur (USB)-Netzwerk nutzen, um eine Kommunikation mit dem Weitverkehrsnetz 132 über eine mobile Vorrichtung des Benutzers 134 zu ermöglichen.
Das Fahrzeug 102 kann die TCU 130 nutzen, um mit einem Cloud-Server 138 zu kommunizieren. Der Cloud-Server 138 kann ein Beispiel für eine vernetzte Rechenvorrichtung sein, auf die das Fahrzeug 102 und/oder die mobile Vorrichtung 134 über das Weitverkehrsnetz 132 zugreifen kann/können. Die Administratorvorrichtung 144 ist ein Beispiel für eine vernetzte Rechenvorrichtung, auf die über das Weitverkehrsnetz 132 zugegriffen werden kann. Der Cloud-Server 138 kann dazu konfiguriert sein, Kommunikation von dem Fahrzeug 102 in Bezug auf erfolgreiche oder nicht erfolgreiche Authentifizierungen durch die Sperrverwaltung 126 zu empfangen sowie diese Informationen an die Administratorvorrichtung 144 zu kommunizieren. Die Administratorvorrichtung 144 kann für einen Administrator zugänglich sein, um etwaige von der Sperrverwaltung 126 auferlegte Sperren zu bestätigen und/oder einzustellen.
Wenn zum Beispiel ein oberer Sperrzustand auftritt, gibt dies eine Bestimmung durch die Sperrverwaltung 126 an, dass ein oder mehrere Benutzer wiederholt und erfolglos versucht haben, Zugriff zu erlangen. Im Falle eines Angreifers würde ein progressives Backoff diesen Benutzer oder die Benutzer verlangsamen, aber eine derartige Richtlinie kann nicht notwendigerweise Versuche für andere Modalitäten einschränken. Zum Beispiel kann das Tastenfeld 122 gesperrt sein, aber eine Zugriffsvorrichtung 110 oder ein Zugriff über biometrische Sensoren 142 kann immer noch zulässig sein.
Im Falle eines gültigen Benutzers kann der Benutzer aufgrund von Umgebungsbedingungen gesperrt worden sein (z. B. Authentifizierungsfehler, wenn eine Kamera durch Regen beeinträchtigt ist). In einem derartigen Szenario wünscht der Benutzer möglicherweise Unterstützung, kann jedoch aufgrund des Verlassens auf eine gerätelose Lösung für den Zugriff möglicherweise nicht in der Lage sein, Hilfe anzufordern. Daher kann die Administratorvorrichtung 144 zusätzlich zu einer progressiven Richtlinie auch für die Fernverwaltung von Sperrzuständen nützlich sein.
2 veranschaulicht ein Beispiel 200 einer Sperrrichtlinie 202, die durch die Sperrverwaltung 126 des Fahrzeugs 102 umgesetzt wird. In einem Beispiel können Daten, die für die Sperrrichtlinie 202 repräsentativ sind, in einem Speicher oder einer anderen Speichervorrichtung, die der Karosseriesteuerung 104 für den Zugriff durch die Sperrverwaltung 126 zur Verfügung steht, gespeichert werden. Wie angemerkt, kann die Sperrverwaltung 126 dazu programmiert sein, eine progressive Sperre selektiv zu steuern. Darüber hinaus kann diese progressive Sperre für jede Modalität (z. B. Zugriffsvorrichtung 110, Tastenfeld 122, biometrische Sensoren 142 usw.) unabhängig arbeiten. Dieser Ansatz kann dazu genutzt werden, Brute-Force-Angriffe zu vermeiden, während das Risiko des Sperrens eines gültigen Benutzers minimiert wird.
In einem Beispiel können Sperren auf einer Modalitätsstufe mit Steuerung von Dauer und Standort umgesetzt werden. Das heißt, eine Sperre auf eine bestimmte Authentifizierungstechnologie, die gesperrt wird, isoliert werden. Somit würde sich die gesamte Modalität in einem Sperrzustand befinden, wenn eine Rate der fehlgeschlagenen Authentifizierung für eine bestimmte Authentifizierungstechnologie einen gegebenen Frequenzschwellenwert für eine Sperre überschreitet (wie durch die Sperrrichtlinie 202 definiert). Dies kann Kontextlogik für äußere gegenüber inneren Sperren beinhalten. Zum Beispiel kann eine äußere Sperre nicht notwendigerweise eine Sperre des Innenraums des Fahrzeugs 102 erfordern, während innere Sperren in einem Beispiel ein Sperren des Äußeren erfordern müssen oder umgekehrt.
Somit kann, wie vorstehend angemerkt, eine Sperre vorhanden sein, die nicht alle Modalitäten verbietet. Dies wäre der Fall, wenn eine Modalität gesperrt ist (z. B. Schlüsselcode gegenüber Biometrik) oder ein einzelner Benutzer gesperrt ist (z. B. ein Benutzer der biometrischen Gesichtserkennung gegenüber allen Benutzern des Fahrzeugs 102 unter Verwendung der biometrischen Gesichtserkennung). In diesen Szenarien kann das zugehörige Konfidenzniveau, das für die verbleibende gültige Authentifizierung während Sperren erforderlich ist, erhöht werden. Wenn zum Beispiel ein erstes Konfidenzniveau, das für die Authentifizierung während Nicht-Sperrbedingungen erforderlich ist, 75 % beträgt, kann die Sperrverwaltung 126 den Schwellenwert während eines ersten Sperrniveaus (z. B. Modus A) auf 85 % erhöhen, während eines weiteren Sperrniveaus (z. B. Modus B) auf 90 % erhöhen und so weiter. Die Sperrverwaltung 126 kann auch andere Anforderungen beinhalten, um das Vertrauen zu erhöhen, wie etwa unter anderem das Entfernen von Brillen, Hüten, Haaren im Gesicht.
Es ist anzumerken, dass die Sperrkonfidenzanpassung auch Standort- und Verlaufsverhalten beinhalten kann. Zum Beispiel kann ein relatives Risiko der Anwesenheit eines böswilligen Benutzers (oder dessen Fehlen) dazu verwendet werden, die Konfidenzanpassung für die biometrische Authentifizierung, die durch die Sperrverwaltung 126 umgesetzt wird, zu beeinflussen. In einem Beispiel könnten Kontextdaten verwendet werden, wie etwa das Risiko von Hackern in einem bestimmten Bereich, so wie durch die Daten des Verlaufsverhaltens angegeben.
Für Schlüsselmodalitäten, die kontinuierlich Benutzer authentifizieren, wie etwa eine kamerabasierte Gesichtserkennung, kann die Sperrrichtlinie 202 einen sekundären Auslöser definieren. Zum Beispiel kann die Sperrverwaltung 126 einen Benutzer über eine Gesichtserkennung bei Annäherung des Benutzers authentifizieren (da die Authentifizierung einige Zeit dauern kann), aber die Autorisierungsprüfung kann erst erfolgen, wenn der Benutzer den Türgriff ergreift. Sollte die Sperrverwaltung 126 über Gesichtserkennung identifizieren, dass der Benutzer autorisiert ist, kann eine nahtlose Entriegelung gewährt werden. Sollte die Sperrverwaltung 126 über Gesichtserkennung identifizieren, dass der Benutzer nicht autorisiert ist, kann die Sperrrichtlinie 202 eingreifen. Dies ermöglicht eine Vorauthentifizierung, die die scheinbare Geschwindigkeit der Authentifizierung aus der Benutzerperspektive erhöht, indem die Verarbeitungsverzögerung zum Durchführen der Authentifizierung reduziert oder beseitigt wird (da die Biometrie bestimmt werden kann, bevor der Benutzer den sekundären Auslöser durchführt), während gleichzeitig das Risiko reduziert wird, dass zufällige Umstehende die Sperre automatisch aktivieren.
Unter konkreterer Bezugnahme auf die beispielhafte Sperrrichtlinie 202 kann jedes Mal, wenn eine fehlgeschlagene Authentifizierung einer gegebenen Modalität zugeordnet ist, ein Sperrzähler um eins erhöht werden. Der Zählwert des Sperrzählers kann ferner einem Sperrzustand zugeordnet sein, sodass die Sperrverwaltung 126 eine gegebene Sperrdauer und die Möglichkeit einer Rückmeldung in Bezug auf den aktuellen Sperrzähler aktivieren kann. Es ist anzumerken, dass die Absicht des Benutzers als Auslöser für passive Technologien fungieren kann. Das heißt, eine zufällige vorbeigehende Person sollte die Gesichtserkennung nicht sperren, und zum Beispiel würde ein Ergreifen eines Türgriffs oder eine andere Geste dazu verwendet werden, die Durchführung einer Authentifizierung und, falls die Authentifizierung fehlschlägt, ein potentielles Erhöhen des Sperrzählers auszulösen.
Wie in der veranschaulichten Sperrrichtlinie 202 aus 2 gezeigt, kann der 1. bis 6. fehlgeschlagene Versuch in einer Modalität zu der Darstellung einer Ablehnungsrückmeldung führen (wie etwa eine Angabe, dass der Zugriff verweigert wird), aber es kann keine weitere Sperraktion durchgeführt werden. Jedoch kann die Sperrverwaltung 126 bei dem 7. Fehler den Sperrmodus A einleiten, der einen ersten Sperrzeitraum aktiviert, während dessen keine Benutzerauthentifizierung über die Modalität akzeptiert werden kann (z. B. eine einminütige Unterbrechung). Unter Fortsetzung des veranschaulichten Beispiels können der 8. und der 9. fehlgeschlagene Versuch in der Modalität zu der Darstellung einer Ablehnungsrückmeldung führen, es kann jedoch keine weitere Sperraktion durchgeführt werden. Jedoch kann die Sperrverwaltung 126 bei dem 10. fehlgeschlagenen Versuch den Sperrmodus B einleiten, der einen zweiten Sperrzeitraum aktiviert, während dessen keine Benutzerauthentifizierung über die Modalität akzeptiert werden kann (z. B. eine fünfminütige Unterbrechung oder ein anderer Zeitraum, der länger als der erste Sperrzeitraum ist). Dann kann die veranschaulichte Sperrrichtlinie 202 für jeden zusätzlichen Sperrversuch zwischen der Darstellung einer Ablehnungsrückmeldung und dem Einleiten von Sperrmodus C, der einen dritten Sperrzeitraum aktiviert, während dessen keine Benutzerauthentifizierung über die Modalität akzeptiert werden kann (z. B. eine zehnminütige Unterbrechung oder ein anderer Zeitraum, der länger als der zweite Sperrzeitraum ist), wechseln.
Somit erhöht die beispielhafte Sperrrichtlinie 202 die Unterbrechungsdauer sowie die Häufigkeit von Unterbrechungen, wenn fehlgeschlagene Versuche am Sperrzähler anlaufen. Dementsprechend nimmt in diesem Beispiel die Sperrdauer zu, wenn die Anzahl der fehlgeschlagenen Versuche zunimmt, und die Sperre wird empfindlicher für Authentifizierungsfehler. Es ist anzumerken, dass dies lediglich ein Beispiel ist und unterschiedliche Ansätze für die Sperrrichtlinie 202 möglich sind. Zum Beispiel kann in einem Beispiel die Häufigkeit der Unterbrechungen erhöht werden, aber nicht ihre Dauer. Oder die Dauer der Unterbrechungen kann erhöht werden, aber nicht ihre Häufigkeit.
Darüber hinaus kann die Aktivierung der Sperre die Identifizierung von persönlichen Vorrichtungen berücksichtigen, die keine Schlüssel sind. Zum Beispiel kann eine Vorrichtung eines Benutzers (Smartphone, Wearable usw.), die auf Grundlage einer hohen Signalstärke (z. B. Indikator für empfangene Signalstärke (Received Signal Strength Indicator - RSSI)) oder einer kurzen Entfernung (z. B. Dauer der Umlaufzeit (Round Trip Time-of-Flight- ToF)) durch das Fahrzeug 102 als nahe erkannt wird, eine erhöhte Wahrscheinlichkeit angeben, dass sich ein gültiger Benutzer in der Nähe befindet. Dies kann auch die ergänzende Verwendung von potentiell nichtbestimmenden, aber nützlichen Biometriken, wie etwa Sprecher- und Gangerkennung, sowie Verhaltenserkennung (z. B. Tageszeit, Standort usw., die mit typischen Verhaltensweisen übereinstimmen) beinhalten.
Als Reaktion darauf, dass die Sperrverwaltung 126 bewirkt, dass das Fahrzeug 102 in einen höheren Sperrmodus oder ein höheres Sperrniveau eintritt, kann ein progressiver Warnmechanismus angepasst werden. Zum Beispiel kann in dem Sperrmodus C ein Vollwarnmeldemechanismus aktiviert werden, wie etwa ein Alarmsystem des Fahrzeugs 102 ertönen zu lassen, Leuchten des Fahrzeugs 102 blinken zu lassen usw., um zukünftige Versuche abzuwehren und auch die Aufmerksamkeit von Menschen in der Nähe des Fahrzeugs 102 auf sich zu ziehen. Wenn für eine ausgewählte Dauer keine Aktivität erfasst wird, kann ein derartiger Alarm abgeschaltet werden, obwohl der Sperrmodus aktiv bleiben kann.
Als eine andere Möglichkeit können andere verdächtige Ereignisse als die fehlgeschlagene Authentifizierung verwendet werden, um den Sperrzustand zu erhöhen. Wenn zum Beispiel ein böswilliger Benutzer ein Fenster einbricht und/oder Vibrationen verursacht, die durch Sensoren des Fahrzeugs 102 erfasst werden, können alle Startmodalitäten sofort von null in den höchsten oberen Sperrmodus übergehen. In diesem Szenario werden die äußeren Zugriffsmodalitäten möglicherweise nicht gesperrt. Zusätzlich kann eine gültige äußere Authentifizierung eine innere Sperre aufgrund dieser Verbesserung zurücksetzen (da es sich um einen gültigen Benutzer handeln könnte, der die Vibrationserkennung versehentlich ausgelöst hat).
Der Sperrzähler kann als Reaktion darauf, dass die Sperrverwaltung 126 bestätigt, dass eine gültige Authentifizierung erfolgt, automatisch zurückgesetzt werden. Dies kann für die Modalität spezifisch sein oder kann auf eine beliebige Modalität verallgemeinert werden und alle Modalitäten zurücksetzen. Eine Unterbrechung kann ebenfalls umgesetzt werden, wie etwa das automatische Zurücksetzen aller Zähler auf null nach einem vordefinierten Zeitraum von Inaktivität (z. B. werden innerhalb von 10 Minuten keine Authentifizierungsversuche berücksichtigt).
Es ist anzumerken, dass die Unterbrechung als Sicherheitsmaßnahme für die obere Sperrmodalität ausgeschlossen werden kann. Das heißt, in dem höchsten Zustand (z. B. Sperrmodus C in der veranschaulichten Sperrrichtlinie 202) kann nur eine gültige Authentifizierung oder eine autorisierte Anforderung zum Zurücksetzen der Sperre verwendet werden, um die Sperrzähler zurückzusetzen. Das heißt, die Anforderung zum Zurücksetzen der Sperre könnte entfernt oder als Serviceroutine über den Cloud-Server 138 und/oder über die Administratorvorrichtung 144 durchgeführt werden. Dies kann dementsprechend eine hohe Backoff-Richtlinie für diejenigen erzwingen, die das Fahrzeug 102 kontinuierlich angreifen.
3 veranschaulicht ein Beispiel 300 für administrative Handlungen 302, die durch den Cloud-Server 138 in Kommunikation mit der Administratorvorrichtung 144 umgesetzt werden. Im Allgemeinen kann der Cloud-Server 138 einen Sperrbenachrichtigungsansatz umsetzen, bei dem eine Administratorvorrichtung 144 dazu in der Lage sein kann, eine Fernsteuerung der Authentifizierung des Fahrzeugs 102 auszuüben. Das Fahrzeug 102 kann entweder ausgewählte oder alle Sperrzustandsinformationen zu Nachverfolgungszwecken an den Cloud-Server 138 senden. Wenn bestimmte Bedingungen erfüllt sind, wie etwa, dass das Fahrzeug 102 in den oberen Sperrzustand eintritt, kann der Cloud-Server 138 eine Benachrichtigung an die Administratorvorrichtung 144 senden. Dies kann zum Beispiel ermöglichen, dass die Administratorvorrichtung 144 einen Administrator des Fahrzeugs 102 über das Ereignis informiert.
Die Benachrichtigung kann relevante Kontextinformationen enthalten. Die Kontextinformationen können unter anderem einen Standort des Fahrzeugs 102, einen Zeitpunkt des letzten Zugriffsversuchs auf das Fahrzeug 102, einen letzten bekannten Benutzer des Fahrzeugs 102 beinhalten. In einigen Beispielen können die Kontextinformationen Kameraeinspeisungsdaten (z. B. von den biometrischen Sensoren 142) beinhalten, von denen der Sensor die Sperre ausgelöst hat (z. B. ein biometrischer Sensor 142 der Fahrertürkamera, der die Sperre ausgelöst hat). (Es ist anzumerken, dass in einigen Umsetzungen Fahrzeugkameraeinspeisungsdaten unabhängig davon, was die Sperre ausgelöst hat, bereitgestellt werden können.) Die Kontextinformationen können auch ein Zeitstempelprotokoll jedes kürzlich erfolgten/fehlgeschlagenen Versuchs, gepaart mit dem Status und der Modalität des Fahrzeugs 102, beinhalten, wie etwa Zugriff durch Fingerabdruck oder Zugriff durch Türgriff. Wenn zum Beispiel der Administrator, der die Administratorvorrichtung 144 verwendet, äußere Zugriffsfehler identifiziert, wobei der Verriegelungszustand des Fahrzeugs 102 verriegelt bleibt, gefolgt von einer inneren Sperre, könnte dies angeben, dass jemand in das Fahrzeug 102 eingebrochen ist.
Die Sperrbenachrichtigung kann auch Informationen über den vorhergesagten Benutzer enthalten. Wenn zum Beispiel eine durch das Fahrzeug 102 durchgeführte Gesichtserkennung die Anwesenheit eines ersten Benutzers (z. B. John) angibt, der Benutzer jedoch durch eine Antispoofing-Funktion des Fahrzeugs 102 abgelehnt wurde, kann diese Ablehnung an den Administrator weitergeleitet werden. Zusätzlich oder alternativ kann der Cloud-Server 138 eine Benachrichtigung von dem Fahrzeug 102 an die mobile Vorrichtung 134 des Benutzers, dem der Zugriff verweigert wird, übermitteln, selbst wenn dieser Benutzer kein Administrator ist.
Die Sperrbenachrichtigung kann über das Weitverkehrsnetz 132 über mehrere entfernte Schnittstellen, wie etwa Webanwendungsprogrammierschnittstellen (wide-area network - API), SMS (short message service - Kurznachrichtendienst)-Textnachrichten, ein anderes Textnachrichtenprotokoll, einen Telefonanruf, E-Mail, oder eine Kombination von Schnittstellen, erfolgen. Der Modus zum Senden der Benachrichtigung kann von der Benutzerpräferenz und/oder von mobilen Einstellungen, wie etwa Flugzeugmodus, deaktiviertem Internet, Vorhandensein oder Fehlen einer WLAN-Verbindung usw., abhängen. Wenn kein Dienst zum Empfangen von Benachrichtigungen erkannt wird (z. B. durch die mobile Vorrichtung 134 des Benutzers), dann kann der Benutzer benachrichtigt werden, um die erforderlichen Dienste zu aktivieren, um es dem Benutzer die Fähigkeit zu geben, Benachrichtigungen zu empfangen.
Unter konkreterer Bezugnahme auf die administrativen Handlungen 302 kann der Administratorvorrichtung 144 eine administrative Benachrichtigung bereitgestellt werden, wenn der Cloud-Server 138 über eine Sperre benachrichtigt wird. In einem Beispiel kann die administrative Benachrichtigung angeben, welche administrativen Handlungen 302 in Bezug auf die Sperre verfügbar sind. Diese administrativen Handlungen 302 können dem administrativen Benutzer der Administratorvorrichtung 144 dargelegt werden. Der Administrator kann aus den verfügbaren administrativen Handlungen 302 auswählen und die Administratorvorrichtung 144 kann eine Angabe der Auswahloption an den Cloud-Server 138 zurücksenden. Diese Auswahl kann durch den Cloud-Server 138 umgesetzt werden, z. B. durch Zurücksenden von Nachrichten an das Fahrzeug 102.
Die gezeigten administrativen Handlungen 302 beschreiben einige der damit verbundenen Handlungen, die vorzunehmen sind. Zum Beispiel kann eine Option eine Handlung zum Abweisen einer Sperre sein, was keine Änderung der Sperre verursachen würde, wie durch die Sperrrichtlinie 202 spezifiziert, und die Sperre kann ohne Unterbrechung fortgesetzt werden. Eine weitere Option kann eine Handlung zum Zurücksetzen der Sperre sein, die den Cloud-Server 138 dazu veranlassen kann, dem Fahrzeug 102 eine Nachricht zum Zurücksetzen des Sperrzählers auf null zu senden. Noch eine weitere Option kann eine Handlung zum entfernten Entriegeln sein, die den Cloud-Server 138 dazu veranlassen kann, dem Fahrzeug 102 eine Nachricht zum Entriegeln zu senden. Noch eine weitere Option kann eine Handlung zum entfernten Starten sein, die den Cloud-Server 138 dazu veranlassen kann, dem Fahrzeug 102 eine Nachricht zum Starten zu senden. Eine weitere Option kann eine Sperrungshandlung sein, die den Cloud-Server 138 dazu veranlassen kann, dem Fahrzeug 102 eine Nachricht für eines oder mehrere von einem Einstellen aller Authentifizierungsmodalitäten auf das oberste Sperrniveau für das Fahrzeug 102 oder kein weiteres Zulassen von beliebigen Authentifizierungen durch das Fahrzeug 102 zu senden.
Es ist zu beachten, dass es sich bei diesen Handlungen nur um Beispiele handelt und dass mehr, weniger und andere Optionen verwendet werden können. Es ist auch anzumerken, dass diese Handlungen Zwischenzustände aufweisen könnten, wie etwa Entriegeln der Fahrertür gegenüber Entriegeln aller Türen und Sperrung der biometrischen Authentifizierung gegenüber Sperrung aller Authentifizierungsmodalitäten.
In einigen Fällen kann der Administrator für eine sofortige Reaktion nicht verfügbar sein und kann sich dafür entscheiden, den Cloud-Server 138 so einzurichten, dass für das Fahrzeug 102 für Sperren nach einem Unterbrechungszeitraum ohne Reaktion eine automatische Reaktion umgesetzt wird. Dies kann entweder einen bestimmten Ersatzkontoinhaber beinhalten, der vorübergehend erhöhte Berechtigungen erhalten kann, oder es kann sich um eine Voreinstellung von umsetzbaren Elementen auf Grundlage des Kontexts handeln. Beispiele für kontextbezogene automatische Handlungen könnten das automatische Zurücksetzen der Sperre auf Grundlage der Entfernung zu einem Standort sein (z. B. das Fahrzeug 102 befindet sich am Wohnsitz des Hauptbenutzers) oder die Verbindung einer bekannten Vorrichtung mit dem Fahrzeug 102 (z. B. ein Wearable, ein Telefon usw., das das Vorhandensein eines autorisierten Benutzers angibt) oder die Übertragung eines Zugriffscodes an ein vertrauenswürdiges Benutzerkonto für den Zugriff sein.
4 veranschaulicht einen beispielhaften Prozess 400 zur verbesserten biometrischen Benutzerauthentifizierung über eine sekundäre Auslösebedingung. In einem Beispiel kann der Prozess 400 durch das Fahrzeug 102 im Rahmen des schlüssellosen Zugangssystems 100 durchgeführt werden. Es ist anzumerken, dass, obwohl der Prozess 400 linear veranschaulicht ist, der Prozess 400 kontinuierlich durchgeführt werden kann und ein oder mehrere Vorgänge des Prozesses 400 gleichzeitig durchgeführt werden können.
Bei Vorgang 402 empfängt das Fahrzeug 102 Benutzerbiometrik. Zum Beispiel kann das Fahrzeug 102 Daten von den biometrischen Sensoren 142 des Fahrzeugs 102 empfangen. Diese Daten können unter anderem passive kamerabasierte Biometrik von einem visuellen biometrischen Sensor 142, Fingerabdruckdaten von einem biometrischen Berührungssensor 142, Sprachabdruckdaten von einem biometrischen Audiosensor 142 usw. beinhalten.
Bei Vorgang 404 initiiert das Fahrzeug 102 eine biometrische Authentifizierung. In einem Beispiel versucht das Fahrzeug 102 als Reaktion auf den Empfang der biometrischen Daten des Benutzers aus Vorgang 402, die empfangenen biometrischen Daten mit gespeicherten biometrischen Daten eines gültigen Benutzers zu vergleichen.
Bei Vorgang 406 empfängt das Fahrzeug 102 eine sekundäre Auslösebedingung. In einem Beispiel ist die sekundäre Auslösebedingung, dass der Benutzer ein Körperglied zu einem oder auf einen Türgriff des Fahrzeugs 102 bewegt.
Bei Vorgang 408 bestimmt das Fahrzeug 102, ob der Benutzer validiert ist. In einem Beispiel ist die bei Vorgang 404 eingeleitete biometrische Authentifizierung vor dem Auftreten der sekundären Auslösebedingung bei Vorgang 406 abgeschlossen. In einem anderen Beispiel ist die bei Vorgang 404 eingeleitete biometrische Authentifizierung nicht abgeschlossen und die Bestimmung ist bei Vorgang 408 abgeschlossen. In jedem Fall wird ein Ergebnis der biometrischen Authentifizierung dazu verwendet, zu bestimmen, ob zu Vorgang 410 übergegangen werden soll, um dem Benutzer den Zugriff zu verweigern, oder zu Vorgang 414 übergegangen werden soll, um dem Benutzer Zugriff zu gewähren.
Bei Vorgang 410 verweigert das Fahrzeug 102 dem Benutzer den Zugriff. Dies kann unter anderem beinhalten, dass das Fahrzeug 102 in einem verriegelten Zustand gehalten wird, um dem Benutzer den Zugang zu dem Fahrzeug 102 zu verweigern, und/oder dass verhindert wird, dass das Fahrzeug 102 gestartet wird. Nach Vorgang 410 geht die Steuerung zu Vorgang 412 über, um den Sperrzähler zu erhöhen. In vielen Beispielen kann jede Zugriffsmodalität ihren eigenen Sperrzähler aufweisen. Somit kann, wenn eine kamerabasierte Biometrie fehlschlägt, ein kamerabasierter Modalitätssperrzähler erhöht werden. In anderen Beispielen können die Sperrzeitgeber weniger spezifisch sein und zum Beispiel kann ein Sperrzähler für alle Arten von Biometrik verwendet werden und ein zweiter Sperrzähler kann zum Beispiel für Tastenfeldsperrungen verwendet werden.
Bei Vorgang 414, der den anderen Abzweig aus Vorgang 408 nimmt, gewährt das Fahrzeug 102 dem Benutzer Zugriff. Dies kann unter anderem ein Entriegeln des Fahrzeugs 102, um dem Benutzer den Zugang zu dem Fahrzeug 102 zu gewähren, und/oder ein Starten des Fahrzeugs 102 beinhalten. Nach Vorgang 414 geht die Steuerung zu Vorgang 416 über, um den Sperrzähler zurückzusetzen. Das Zurücksetzen kann zum Beispiel das Einstellen des Sperrzählers auf null sein.
Nach einem der Vorgänge 412 oder 416 geht die Steuerung zu Vorgang 418 über. Bei Vorgang 418 wendet das Fahrzeug 102 die Sperrrichtlinie 202 an. Dies kann, wie vorstehend erörtert, die Anwendung eines Sperrzustands oder -niveaus beinhalten, sodass die Sperrverwaltung 126 auf Grundlage des aktualisierten Werts des Sperrzählers eine gegebene Sperrdauer aktivieren kann, die Möglichkeit einer Rückmeldung bereitstellen kann und/oder eine Sperrbenachrichtigung an den Cloud-Server 138 senden kann. Eine beispielhafte Umsetzung der Anwendung der Sperrrichtlinie 202 wird in Bezug auf 5 nachstehend erörtert. Nach Vorgang 418 endet der Prozess 400.
5 veranschaulicht einen beispielhaften Prozess 500 für den Betrieb der Sperrrichtlinie 202 durch das Fahrzeug 102. In einem Beispiel kann der Prozess 500 durch das Fahrzeug 102 in Bezug auf den Vorgang 418 des Prozesses 400 durchgeführt werden. In anderen Beispielen kann der Prozess 500 durch das Fahrzeug 102 auf Grundlage anderer Authentifizierungsansätze unabhängig von dem des Prozesses 400 durchgeführt werden. Wie bei dem Prozess 400 kann, obwohl der Prozess 500 linear veranschaulicht ist, der Prozess 500 kontinuierlich durchgeführt werden und ein oder mehrere Vorgänge des Prozesses 500 können gleichzeitig durchgeführt werden.
Bei Vorgang 502 identifiziert das Fahrzeug 102 einen Sperrzählerwert. Unter anderem kann das Fahrzeug 102 den Sperrwert als Reaktion auf ein Erhöhen des Sperrwerts oder ein Zurücksetzen des Sperrzählers auf null identifizieren.
Bei Vorgang 504 greift das Fahrzeug 102 auf die Sperrrichtlinie 202 zu, um eine Handlung zu identifizieren, die als Reaktion auf den neuen Wert des Sperrzählers vorzunehmen ist. Zum Beispiel kann die Sperrrichtlinie 202 für jeden Wert des Sperrzählers eines oder mehrere davon festlegen, ob eine gegebene Dauer der Sperrung aktiviert werden soll, dem Benutzer, der eine Authentifizierung versucht, eine Rückmeldung bereitgestellt werden soll und/oder eine Sperrbenachrichtigung an den Cloud-Server 138 gesendet werden soll. In einigen Fällen wird die Sperrbenachrichtigung an den Cloud-Server 138 unabhängig von der Sperrrichtlinie 202 immer versucht.
Bei Vorgang 506 bestimmt das Fahrzeug 102, ob es die identifizierte Handlung beinhaltet, den Benutzer zu benachrichtigen. Ist dies der Fall, geht die Steuerung zu Vorgang 508 über, um die Benachrichtigung durchzuführen. Diese Benachrichtigung kann unter anderem ein Anzeigen einer Nachricht in Bezug darauf, dass die Authentifizierung genehmigt oder verweigert wird, ein Bereitstellen einer akustischen Angabe in Bezug darauf, dass die Authentifizierung genehmigt oder verweigert wird, ein Nachahmen des Alarms des Fahrzeugs 102 usw. beinhalten. Nach dem Vorgang 508, oder wenn bei Vorgang 506 keine Benachrichtigung angegeben wird, geht die Steuerung zu Vorgang 510 über.
Bei Vorgang 510 bestimmt das Fahrzeug 102, ob es die identifizierte Handlung beinhaltet, den Cloud-Server 138 zu benachrichtigen. Wenn dies der Fall ist, geht die Steuerung zu Vorgang 512 über, um eine Sperrbenachrichtigung an den Cloud-Server 138 zu senden. Weitere Aspekte der Sperrbenachrichtigung sind vorstehend erörtert. Nach Vorgang 512, oder wenn bei Vorgang 510 keine Benachrichtigung angegeben wird, geht die Steuerung zu Vorgang 514 über.
Bei Vorgang 514 bestimmt das Fahrzeug 102, ob es die identifizierte Handlung beinhaltet, die Sperre eines Fahrzeugs 102 zu aktualisieren. Wenn dies der Fall ist, geht die Steuerung zu Vorgang 516 über. Zum Beispiel können als Reaktion auf ein Erhöhen des Sperrzählers weitere Authentifizierungen von der Modalität, die fehlgeschlagen sind, für einen vordefinierten Zeitraum ignoriert werden, oder es können als Reaktion auf ein Zurücksetzen des Sperrzählers weitere Authentifizierungen von der Modalität (oder von anderen Modalitäten) erneut durch das Fahrzeug 102 verarbeitet werden. Weitere Aspekte des Sperrzählers sind vorstehend erörtert. Nach Vorgang 516, oder wenn bei Vorgang 512 keine Benachrichtigung angegeben wird, geht die Steuerung zu Vorgang 518 über.
Bei Vorgang 518 bestimmt das Fahrzeug 102, ob eine Handlung von dem Cloud-Server 128 empfangen wird. Wenn dies der Fall ist, geht die Steuerung zu Vorgang 520 über. Zum Beispiel kann das Fahrzeug 102 als Reaktion auf die bei Vorgang 512 gesendete Sperrbenachrichtigung eine Angabe empfangen, die durch die Sperrrichtlinie 202 festgelegten Handlungen zu übergehen. Dies kann zum Beispiel das Zurücksetzen des Sperrzählers, das Sperren des Fahrzeugs 102, das Zulassen des Zugriffs aus das Fahrzeug 102, das Starten des Fahrzeugs 102 usw. beinhalten. Weitere Aspekte der vom Cloud-Server 138 empfangenen Handlungen sind vorstehend detailliert beschrieben. Nach Vorgang 520, oder wenn keine Handlung bei Vorgang 518 empfangen wird, endet der Prozess 500.
6 veranschaulicht einen beispielhaften Prozess 600 für den Betrieb der adminsitrativen Handlungen 302 durch den Cloud-Server 138. In einem Beispiel kann der Prozess 600 als Reaktion auf den Empfang einer Sperrbenachrichtigung bei Vorgang 602, die von dem Fahrzeug 102 in Vorgang 512 des Prozesses 500 empfangen wurde, durchgeführt werden. In anderen Beispielen kann die Sperrbenachrichtigung unabhängig von dem Prozess 500 an dem Cloud-Server 138 empfangen werden. Wie bei den Prozessen 400 und 500 können die Vorgänge des Prozesses 600 auch kontinuierlich und/oder gleichzeitig durchgeführt werden.
Unabhängig davon identifiziert der Cloud-Server 138 bei Vorgang 604 die Administratorvorrichtung 144, die dem Fahrzeug 102 entspricht. In einem Beispiel kann der Cloud-Server 138 eine Zuordnung von Fahrzeugen 102 zu entsprechenden Administratorvorrichtungen 144, z. B. Flottenverwaltung für die Fahrzeuge 102, führen. In einem anderen Beispiel kann der Cloud-Server 138 für eine Flotte spezifisch sein und kann dazu programmiert sein, unabhängig von dem Fahrzeug 102 an einen Satz von einer oder mehreren Administratorvorrichtungen 144 zu senden.
Bei Vorgang 606 sendet der Cloud-Server 138 eine administrative Benachrichtigungsnachricht an die Administratorvorrichtung(en) 144. In einem Beispiel kann die administrative Benachrichtigung angeben, welche administrativen Handlungen 302 in Bezug auf eine Sperre eines Fahrzeugs 102 verfügbar sind. Beispiele für die administrativen Handlungen 302 sind vorstehend erörtert.
Bei Vorgang 608 bestimmt der Cloud-Server 138, ob eine Handlungsreaktion empfangen wurde. Zum Beispiel können die administrativen Handlungen 302, die bei Vorgang 606 angegeben sind, dem administrativen Benutzer der Administratorvorrichtung 144 dargelegt werden. Der Administrator kann aus den verfügbaren administrativen Handlungen 302 auswählen und die Administratorvorrichtung 144 kann eine Angabe der Auswahloption an den Cloud-Server 138 zurücksenden. Wenn eine derartige Handlungsreaktion empfangen wird, geht die Steuerung zu Vorgang 610 über, um die Handlung in der empfangenen Handlungsreaktion durchzuführen. Diese Durchführung kann ein Senden eines Befehls an das Fahrzeug 102 beinhalten, z. B. um die Sperre aufzuheben, eine weitere Sperre einzuleiten, die Türen des Fahrzeugs 102 zu entriegeln, das Fahrzeug 102 zu starten usw. Nach Vorgang 610 endet der Prozess 600.
Wenn jedoch bei Vorgang 608 keine Handlungsreaktion empfangen wurde (z. B. innerhalb eines vordefinierten Unterbrechungszeitraums, wie etwa einer Minute, einer Stunde usw.), geht die Steuerung zu Vorgang 612 über, um zu bestimmen, ob eine Standardhandlungsreaktion eingestellt wurde. In einigen Beispielen kann die Administratorvorrichtung 144 dazu verwendet werden, eine Standardhandlung festzulegen, die durchgeführt werden soll, um die Sperrrichtlinie 202 zu übergehen, selbst wenn die Administratorvorrichtung 144 bei Vorgang 608 keine Reaktion bereitstellt. Ist dies der Fall, geht die Steuerung zu Vorgang 614 über, um die Standardhandlung durchzuführen. Nach Vorgang 614 endet der Prozess 600.
Wenn jedoch bei Vorgang 612 keine Standardhandlung eingestellt ist und bei Vorgang 608 auch keine Handlungsreaktion empfangen wird, geht die Steuerung zu Vorgang 616 über, um keine Handlung in Bezug auf die bei Vorgang 602 empfangene Sperrbenachrichtigung durchzuführen. Nach Vorgang 616 endet der Prozess 600.
Variationen des Prozesses 600 sind möglich. Wenn zum Beispiel eine Standardhandlung festgelegt ist, kann diese Handlung durchgeführt werden, außer es wurde oder wird eine Handlungsreaktion von der Administratorvorrichtung 144 empfangen. In noch einer anderen Variation kann eine Handlungsreaktion durch den Cloud-Server 138 empfangen und verarbeitet werden, um an dem Fahrzeug 102 betrieben zu werden, unabhängig davon, ob eine Sperrbenachrichtigung empfangen wurde oder nicht.
Hierin beschriebene Rechenvorrichtungen, wie etwa die Karosseriesteuerung 104, die Zugriffsvorrichtung 110, die mobile Vorrichtung 134 und der Cloud-Server 138 beinhalten im Allgemeinen computerausführbare Anweisungen, wobei die Anweisungen durch eine oder mehrere Rechenvorrichtungen, wie etwa die vorangehend aufgelisteten, ausgeführt werden können. Computerausführbare Anweisungen können von Computerprogrammen kompiliert oder interpretiert werden, die unter Verwendung einer Vielfalt von Programmiersprachen und/oder -techniken erstellt wurden, einschließlich unter anderem und entweder für sich oder in Kombination JAVA™, C, C++, C#, VISUAL BASIC, JAVASCRIPT, PYTHON, JAVASCRIPT, PERL, Structured Query Language (SQL) usw. Im Allgemeinen empfängt ein Prozessor (z. B. ein Mikroprozessor) Anweisungen, z. B. von einem Speicher, einem computerlesbaren Medium usw., und führt diese Anweisungen aus, wodurch ein oder mehrere Prozesse, einschließlich eines oder mehrerer der in der vorliegenden Schrift beschriebenen Prozesse, durchgeführt werden. Derartige Anweisungen und andere Daten können unter Verwendung vielfältiger computerlesbarer Medien gespeichert und übertragen werden.
Hinsichtlich der in dieser Schrift beschriebenen Prozesse, Systeme, Verfahren, Heuristiken usw. versteht es sich, dass die Schritte derartiger Prozesse usw. zwar als gemäß einer bestimmten Reihenfolge erfolgend beschrieben worden sind, derartige Prozesse jedoch umgesetzt werden könnten, wobei die beschriebenen Schritte in einer Reihenfolge durchgeführt werden, die von der in dieser Schrift beschriebenen Reihenfolge abweicht. Ferner versteht es sich, dass bestimmte Schritte gleichzeitig durchgeführt, andere Schritte hinzugefügt oder bestimmte in dieser Schrift beschriebene Schritte weggelassen werden könnten. Anders ausgedrückt, dienen die Beschreibungen von Prozessen in dieser Schrift dem Zweck der Veranschaulichung bestimmter Ausführungsformen und sollten keinesfalls dahingehend ausgelegt werden, dass sie die Patentansprüche einschränken.
Dementsprechend versteht es sich, dass die vorstehende Beschreibung veranschaulichend und nicht einschränkend sein soll. Aus der Lektüre der vorstehenden Beschreibung ergeben sich viele andere Ausführungsformen und Anwendungen als die aufgeführten Beispiele. Der Umfang sollte nicht unter Bezugnahme auf die vorstehende Beschreibung, sondern stattdessen unter Bezugnahme auf die beigefügten Patentansprüche bestimmt werden, zusammen mit der gesamten Bandbreite an Äquivalenten, zu denen diese Patentansprüche berechtigen. Es ist davon auszugehen und beabsichtigt, dass es zukünftige Entwicklungen im in dieser Schrift erörterten Stand der Technik geben wird und dass die offenbarten Systeme und Verfahren in derartige zukünftige Ausführungsformen aufgenommen werden. Insgesamt versteht es sich, dass die Anmeldung modifiziert und verändert werden kann.
Allen in den Patentansprüchen verwendeten Ausdrücken sollen deren umfassendste nachvollziehbare Konstruktionen und deren allgemeine Bedeutungen zugeordnet sein, wie sie den mit den hier beschriebenen Techniken vertrauten Fachleuten bekannt sind, sofern hier kein ausdrücklicher Hinweis auf das Gegenteil erfolgt. Insbesondere ist die Verwendung der Singularartikel, wie etwa „ein“, „eine“, „der“, „die“, „das“ usw., dahingehend zu verstehen, dass eines oder mehrere der angegebenen Elemente genannt werden, sofern ein Patentanspruch nicht eine ausdrückliche gegenteilige Einschränkung nennt.
Die Zusammenfassung der Offenbarung wird bereitgestellt, um dem Leser einen schnellen Überblick über den Charakter der technischen Offenbarung zu ermöglichen. Sie wird unter der Voraussetzung eingereicht, dass sie nicht zum Auslegen oder Einschränken des Umfangs oder der Bedeutung der Ansprüche verwendet wird. Des Weiteren geht aus der vorangehenden detaillierten Beschreibung hervor, dass zum Zwecke der vereinfachten Darstellung der Offenbarung verschiedene Merkmale in verschiedenen Ausführungsformen zu Gruppen zusammengefasst sind. Dieses Verfahren der Offenbarung ist nicht als Absicht zu verstehen, dass die beanspruchten Ausführungsformen mehr Merkmale erfordern sollen als jeweils in jedem Anspruch ausdrücklich genannt. Wie die folgenden Ansprüche widerspiegeln, liegt der Gegenstand der Erfindung vielmehr in weniger als allen Merkmalen einer einzelnen offenbarten Ausführungsform. Somit werden die folgenden Ansprüche hiermit in die detaillierte Beschreibung aufgenommen, wobei jeder Anspruch für sich als separat beanspruchter Gegenstand steht.
Wenngleich vorangehend beispielhafte Ausführungsformen beschrieben sind, ist nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen der Erfindung beschreiben. Vielmehr sind die in der Beschreibung verwendeten Ausdrücke beschreibende und keine einschränkenden Ausdrücke und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Wesen und Umfang der Erfindung abzuweichen. Des Weiteren können die Merkmale verschiedener umsetzender Ausführungsformen kombiniert werden, um weitere Ausführungsformen der Erfindung zu bilden.
Gemäß der vorliegenden Erfindung ist ein Fahrzeug zur verbesserten Benutzerauthentifizierung bereitgestellt, aufweisend: einen biometrischen Sensor; und eine Steuerung mit einem Hardware-Prozessor, die zu Folgendem programmiert ist: eine biometrische Authentifizierung eines Benutzers innerhalb einer Nähe des Fahrzeugs unter Verwendung von Daten, die von dem biometrischen Sensor empfangen werden, einzuleiten und als Reaktion auf das Auftreten einer sekundären Auslösebedingung, die durch den Benutzer eingeleitet wird, um Zugriff auf das Fahrzeug zu erlangen, die biometrische Authentifizierung abzuschließen, um dem Benutzer Zugriff zu gewähren oder zu verweigern.
Gemäß einer Ausführungsform ist der Prozessor ferner dazu programmiert, einen Sperrzähler des Fahrzeugs auf Grundlage der biometrischen Authentifizierung als Reaktion auf das Auftreten der sekundären Auslösebedingung zu aktualisieren, wodurch das Risiko verringert wird, dass Umstehende den Sperrzähler versehentlich erhöhen.
Gemäß einer Ausführungsform ist der Prozessor ferner zu Folgendem programmiert: einen Sperrzähler als Reaktion auf eine Zugriffsverweigerung zu erhöhen; und weitere Authentifizierungsversuche an dem Fahrzeug unter Verwendung des biometrischen Sensors für einen vordefinierten Zeitraum als Reaktion darauf, dass der Sperrzähler einen vordefinierten Wert erreicht, zu verhindern.
Gemäß einer Ausführungsform wird die biometrische Authentifizierung vor dem Auftreten der sekundären Auslösebedingung abgeschlossen, wodurch die Verarbeitungsverzögerung zum Gewähren oder Verweigern des Zugriffs reduziert wird.
Gemäß einer Ausführungsform ist der biometrische Sensor dazu konfiguriert, Gesichtsbilddaten zu erfassen, und die biometrische Authentifizierung ist eine Gesichtserkennung unter Verwendung der Gesichtsbilddaten.
Gemäß einer Ausführungsform besteht die sekundäre Auslösebedingung darin, dass der Benutzer ein Körperglied zu einem Türgriff des Fahrzeugs bewegt.
Gemäß der vorliegenden Erfindung wird ein Fahrzeug, das eine progressive Sperre umsetzt, bereitgestellt, aufweisend: eine Steuerung mit einem Hardware-Prozessor, der zu Folgendem programmiert ist: einen ersten Sperrzähler als Reaktion auf das Auftreten eines ersten fehlgeschlagenen Zugriffsversuchs unter Verwendung einer ersten Zugriffsmodalität zu erhöhen; weitere Authentifizierungsversuche an dem Fahrzeug unter Verwendung der ersten Zugriffsmodalität für eine erste vordefinierte Dauer als Reaktion darauf, dass der erste Sperrzähler einen ersten vordefinierten Wert erreicht, zu verhindern; einen zweiten Sperrzähler als Reaktion auf das Auftreten eines zweiten fehlgeschlagenen Zugriffsversuchs unter Verwendung einer zweiten Zugriffsmodalität zu erhöhen; und weitere Authentifizierungsversuche an dem Fahrzeug unter Verwendung der zweiten Zugriffsmodalität für eine zweite vordefinierte Dauer als Reaktion darauf, dass der zweite Sperrzähler einen zweiten vordefinierten Wert erreicht, zu verhindern.
Gemäß einer Ausführungsform ist die erste Zugriffsmodalität die Verwendung einer biometrischen Authentifizierung und ist die zweite Zugriffsmodalität die Verwendung einer Hardware-Zugriffsvorrichtung oder eines Hardware-Zugriffscodes.
Gemäß einer Ausführungsform ist die Steuerung ferner zu Folgendem programmiert: den ersten Sperrzähler, jedoch nicht den zweiten Sperrzähler, als Reaktion auf das Auftreten eines erfolgreichen Zugriffsversuchs unter Verwendung der ersten Zugriffsmodalität zurückzusetzen; und den zweiten Sperrzähler, jedoch nicht den ersten Sperrzähler, als Reaktion auf das Auftreten eines erfolgreichen Zugriffsversuchs unter Verwendung der zweiten Zugriffsmodalität zurückzusetzen.
Gemäß einer Ausführungsform ist die Steuerung ferner zu Folgendem programmiert: den ersten Sperrzähler und den zweiten Sperrzähler als Reaktion auf das Auftreten eines erfolgreichen Zugriffsversuchs unter Verwendung der ersten Zugriffsmodalität zurückzusetzen.
Gemäß einer Ausführungsform ist die Steuerung ferner dazu programmiert, weitere Authentifizierungsversuche an dem Fahrzeug unter Verwendung der ersten Zugriffsmodalität für eine dritte vordefinierte Dauer als Reaktion darauf zu verhindern, dass der erste Sperrzähler einen dritten vordefinierten Wert erreicht, wobei die dritte vordefinierte Dauer größer als die erste vordefinierte Dauer ist, wobei der dritte vordefinierte Wert größer als der erste vordefinierte Wert ist.
Gemäß einer Ausführungsform ist die Steuerung ferner zu einem oder mehreren der Folgenden programmiert: (i) die Sperrdauer zu erhöhen, wenn der erste Sperrzähler zunimmt, oder (ii) eine Anzahl von fehlgeschlagenen Authentifizierungsversuchen zwischen Sperren zu reduzieren, wenn der erste Sperrzähler zunimmt.
Gemäß einer Ausführungsform ist die Steuerung ferner zu Folgendem programmiert: als Reaktion auf das Auftreten des ersten fehlgeschlagenen Zugriffsversuchs unter Verwendung entweder der ersten Zugriffsmodalität oder der zweiten Zugriffsmodalität eine Sperrbenachrichtigung zu senden, wobei die Sperrbenachrichtigung Kontextinformationen in Bezug auf das Auftreten des ersten fehlgeschlagenen Zugriffsversuchs beinhaltet; als Reaktion auf das Senden der Sperrbenachrichtigung eine Angabe einer administrativen Handlung, die von dem Fahrzeug durchgeführt werden soll, zu empfangen; und die administrative Handlung durchzuführen.
Gemäß einer Ausführungsform beinhalten die Kontextinformationen eines oder mehrere der Folgendem: (i) einen Standort des Fahrzeugs, (ii) einen Zeitpunkt eines letzten versuchten Zugriffs auf das Fahrzeug, (iii) einen letzten bekannten Benutzer des Fahrzeugs, (iv) Bilddaten, die die Sperrbenachrichtigung ausgelöst haben, oder (v) ein Protokoll mit Zeitstempel jedes kürzlich erfolgreichen oder fehlgeschlagenen Zugriffsversuchs auf das Fahrzeug.
Gemäß der vorliegenden Erfindung ist ein System zur entfernten Verwaltung von Sperrzuständen für ein Fahrzeug bereitgestellt, aufweisend: einen Server mit einem Hardware-Prozessor, der zu Folgendem programmiert ist: als Reaktion auf das Auftreten eines fehlgeschlagenen Zugriffsversuchs unter Verwendung einer Zugriffsmodalität eine Sperrbenachrichtigung von dem Fahrzeug zu empfangen, wobei die Sperrbenachrichtigung Kontextinformationen in Bezug auf das Auftreten des fehlgeschlagenen Zugriffsversuchs beinhaltet; und als Reaktion auf die Sperrbenachrichtigung eine Angabe einer administrativen Handlung, die von dem Fahrzeug durchgeführt werden soll, zu senden.
Gemäß einer Ausführungsform ist der Server ferner zu Folgendem programmiert: eine dem Fahrzeug entsprechende Administratorvorrichtung zu identifizieren; eine Administratorbenachrichtigung an die identifizierte Administratorvorrichtung zu senden; und die administrative Handlung von der Administratorvorrichtung als Reaktion auf die Administratorbenachrichtigung zu empfangen.
Gemäß einer Ausführungsform gibt die administrative Handlung eines oder mehrere der Folgenden an: (i) das Fahrzeug entriegeln, (ii) das Fahrzeug starten, (iii) einen Sperrzähler des Fahrzeugs zurücksetzen oder (iv) den Zugriff auf das Fahrzeug sperren.
Gemäß einer Ausführungsform ist der Server ferner dazu programmiert, die Kontextinformationen in die Administratorbenachrichtigung einzuschließen.
Gemäß einer Ausführungsform beinhaltet die Sperrbenachrichtigung die Kontextinformationen in Bezug auf das Auftreten des fehlgeschlagenen Zugriffsversuchs und die Kontextinformationen beinhalten eines oder mehrere der Folgendem: (i) einen Standort des Fahrzeugs, (ii) einen Zeitpunkt eines letzten versuchten Zugriffs auf das Fahrzeug, (iii) einen letzten bekannten Benutzer des Fahrzeugs, (iv) Bilddaten, die die Sperrbenachrichtigung ausgelöst haben, oder (v) ein Protokoll mit Zeitstempel jedes kürzlich erfolgreichen oder fehlgeschlagenen Zugriffsversuchs auf das Fahrzeug.
Gemäß einer Ausführungsform ist der Server ferner zu Folgendem programmiert: eine Standardhandlung von der Administratorvorrichtung entsprechend dem Fahrzeug vor dem Empfang der Sperrbenachrichtigung von dem Fahrzeug zu empfangen; und die Standardhandlung als die durch das Fahrzeug durchzuführende administrative Handlung zu nutzen.

Claims

Fahrzeug zur verbesserten Benutzerauthentifizierung, umfassend: einen biometrischen Sensor; und eine Steuerung mit einem Hardware-Prozessor, der zu Folgendem programmiert ist: eine biometrische Authentifizierung eines Benutzers innerhalb einer Nähe des Fahrzeugs unter Verwendung von Daten, die von dem biometrischen Sensor empfangen werden, einzuleiten und als Reaktion auf das Auftreten einer sekundären Auslösebedingung, die durch den Benutzer eingeleitet wird, um Zugriff auf das Fahrzeug zu erlangen, die biometrische Authentifizierung abzuschließen, um dem Benutzer Zugriff zu gewähren oder zu verweigern.
Fahrzeug nach Anspruch 1, wobei der Prozessor ferner dazu programmiert, einen Sperrzähler des Fahrzeugs auf Grundlage der biometrischen Authentifizierung als Reaktion auf das Auftreten der sekundären Auslösebedingung zu aktualisieren, wodurch das Risiko verringert wird, dass Umstehende den Sperrzähler versehentlich erhöhen.
Fahrzeug nach Anspruch 1, wobei der Prozessor ferner zu Folgendem programmiert ist: einen Sperrzähler als Reaktion auf eine Zugriffsverweigerung zu erhöhen; und weitere Authentifizierungsversuche an dem Fahrzeug unter Verwendung des biometrischen Sensors für einen vordefinierten Zeitraum als Reaktion darauf, dass der Sperrzähler einen vordefinierten Wert erreicht, zu verhindern.
Fahrzeug nach Anspruch 1, wobei die biometrische Authentifizierung vor dem Auftreten der sekundären Auslösebedingung abgeschlossen wird, wodurch die Verarbeitungsverzögerung zum Gewähren oder Verweigern des Zugriffs reduziert wird.
Fahrzeug nach Anspruch 1, wobei der biometrische Sensor dazu konfiguriert ist, Gesichtsbilddaten zu erfassen, und die biometrische Authentifizierung eine Gesichtserkennung unter Verwendung der Gesichtsbilddaten ist.
Fahrzeug nach Anspruch 1, wobei die sekundäre Auslösebedingung darin besteht, dass der Benutzer ein Körperglied zu einem Türgriff des Fahrzeugs bewegt.
Fahrzeug, das eine progressive Sperre umsetzt, umfassend: eine Steuerung mit einem Hardware-Prozessor, der zu Folgendem programmiert ist: einen ersten Sperrzähler als Reaktion auf das Auftreten eines ersten fehlgeschlagenen Zugriffsversuchs unter Verwendung einer ersten Zugriffsmodalität zu erhöhen; weitere Authentifizierungsversuche an dem Fahrzeug unter Verwendung der ersten Zugriffsmodalität für eine erste vordefinierte Dauer als Reaktion darauf, dass der erste Sperrzähler einen ersten vordefinierten Wert erreicht, zu verhindern; einen zweiten Sperrzähler als Reaktion auf das Auftreten eines zweiten fehlgeschlagenen Zugriffsversuchs unter Verwendung einer zweiten Zugriffsmodalität zu erhöhen; und weitere Authentifizierungsversuche an dem Fahrzeug unter Verwendung der zweiten Zugriffsmodalität für eine zweite vordefinierte Dauer als Reaktion darauf, dass der zweite Sperrzähler einen zweiten vordefinierten Wert erreicht, zu verhindern.
Fahrzeug nach Anspruch 7, wobei die erste Zugriffsmodalität die Verwendung einer biometrischen Authentifizierung ist und die zweite Zugriffsmodalität die Verwendung einer Hardware-Zugriffsvorrichtung oder eines Hardware-Zugriffscodes ist.
Fahrzeug nach Anspruch 7, wobei die Steuerung ferner zu Folgendem programmiert ist: den ersten Sperrzähler, jedoch nicht den zweiten Sperrzähler, als Reaktion auf das Auftreten eines erfolgreichen Zugriffsversuchs unter Verwendung der ersten Zugriffsmodalität zurückzusetzen; und den zweiten Sperrzähler, jedoch nicht den ersten Sperrzähler, als Reaktion auf das Auftreten eines erfolgreichen Zugriffsversuchs unter Verwendung der zweiten Zugriffsmodalität zurückzusetzen.
Fahrzeug nach Anspruch 7, wobei die Steuerung ferner zu Folgendem programmiert ist: den ersten Sperrzähler und den zweiten Sperrzähler als Reaktion auf das Auftreten eines erfolgreichen Zugriffsversuchs unter Verwendung der ersten Zugriffsmodalität zurückzusetzen.
Fahrzeug nach Anspruch 7, wobei die Steuerung ferner dazu programmiert ist, weitere Authentifizierungsversuche an dem Fahrzeug unter Verwendung der ersten Zugriffsmodalität für eine dritte vordefinierte Dauer als Reaktion darauf zu verhindern, dass der erste Sperrzähler einen dritten vordefinierten Wert erreicht, wobei die dritte vordefinierte Dauer größer als die erste vordefinierte Dauer ist, wobei der dritte vordefinierte Wert größer als der erste vordefinierte Wert ist.
Fahrzeug nach Anspruch 7, wobei die Steuerung ferner zu einem oder mehreren der Folgenden programmiert ist: (i) die Sperrdauer zu erhöhen, wenn der erste Sperrzähler zunimmt, oder (ii) eine Anzahl von fehlgeschlagenen Authentifizierungsversuchen zwischen Sperren zu reduzieren, wenn der erste Sperrzähler zunimmt.
Fahrzeug nach Anspruch 7, wobei die Steuerung ferner zu Folgendem programmiert ist: als Reaktion auf das Auftreten des ersten fehlgeschlagenen Zugriffsversuchs unter Verwendung entweder der ersten Zugriffsmodalität oder der zweiten Zugangsmodalität eine Sperrbenachrichtigung zu senden, wobei die Sperrbenachrichtigung Kontextinformationen in Bezug auf das Auftreten des ersten fehlgeschlagenen Zugriffsversuchs beinhaltet; als Reaktion auf das Senden der Sperrbenachrichtigung eine Angabe einer administrativen Handlung, die von dem Fahrzeug durchgeführt werden soll, zu empfangen; und die administrative Handlung durchzuführen.
Fahrzeug nach Anspruch 13, wobei die Kontextinformationen eines oder mehrere der Folgendem beinhalten: (i) einen Standort des Fahrzeugs, (ii) einen Zeitpunkt eines letzten versuchten Zugriffs auf das Fahrzeug, (iii) einen letzten bekannten Benutzer des Fahrzeugs, (iv) Bilddaten, die die Sperrbenachrichtigung ausgelöst haben, oder (v) ein Protokoll mit Zeitstempel jedes kürzlich erfolgreichen oder fehlgeschlagenen Zugriffsversuchs auf das Fahrzeug.
System zur entfernten Verwaltung von Sperrzuständen für ein Fahrzeug, umfassend: einen Server mit einem Hardware-Prozessor, der zu Folgendem programmiert ist: als Reaktion auf das Auftreten eines fehlgeschlagenen Zugriffsversuchs unter Verwendung einer Zugriffsmodalität eine Sperrbenachrichtigung von dem Fahrzeug zu empfangen, wobei die Sperrbenachrichtigung Kontextinformationen in Bezug auf das Auftreten des fehlgeschlagenen Zugriffsversuchs beinhaltet; und als Reaktion auf die Sperrbenachrichtigung eine Angabe einer administrativen Handlung, die von dem Fahrzeug durchgeführt werden soll, zu senden.