Beschreibung

Die Erfindung betrifft ein Verfahren und System zum Öffnen und/oder zur

Nutzung wenigstens eines Fahrzeugs.

Batteriebetriebene Fahrzeuge, insbesondere Elektrofahrräder (sogenannte E- Bikes) sowie Pkw oder elektrisch angetriebene Roller, erfreuen sich großer Beliebtheit.

Bei Kraftfahrzeugen haben sich Keyless Go-Systeme mit einem elektronischen bartlosen Schlüssel durchgesetzt. Dabei kann der bartlose Schlüssel

berührungslos ein Fahrzeug öffnen und verriegeln. Das Fahrzeug kann auch per Funk zum Start freigegeben werden.

Bei gängigen Keyless Go-Systemen befinden sich auf dem bartlosen Schlüssel sowie auf dem Fahrzeug Pseudozufallszahlengeneratoren, die mit einem gleichen Seed-Wert initialisiert sind. Ein Seed-Wert stellt einen Startwert für einen

Zufallszahlengenerator dar, mit dem dieser initialisiert wird. Dadurch erzeugen die Pseudozufallszahlengeneratoren auf dem bartlosen Schlüssel und auf dem Fahrzeug die gleiche Zahlenreihenfolge.

Um das Fahrzeug zu öffnen, generiert der bartlose Schlüssel einen Remotecode, der per Funk an das Fahrzeug gesendet wird. Das Fahrzeug generiert beim Empfang einen Lokalcode unter Verwendung des auf dem Fahrzeug gespeichert Seed-Wertes und vergleicht diesen mit dem empfangenen Remotecode. Sind die beiden Codes identisch, so wird das Fahrzeug geöffnet.

Ein Nachteil des bartlosen Schlüssels ist, dass der Seed-Schlüssel bei Auslieferung des Fahrzeugs bzw. des Schlüssels an den Kunden fest in diesen einprogrammiert wird. Der bartlose Schlüssel lässt sich daher nicht bei Car-Sharing-Diensten einsetzen, bei denen sich eine Vielzahl an Kunden dasselbe Fahrzeug teilen.

Car-Sharing-Anbieter verwenden einerseits eine RFID-basierte Lösung, bei der der Fahrer eine Karte mit integriertem RFID-Chip an ein Lesegerät am Fahrzeug halten muss. Die Karte überträgt einen Code an das Fahrzeug, der von dem Fahrzeug über eine Internet -Verbindung an einem Server gesendet wird und von diesem überprüft wird. Ist der Code bekannt, so sendet der Server einen entsprechenden Befehl an das Fahrzeug und das Fahrzeug wird Fahrzeug geöffnet.

Andererseits verwenden Car-Sharing-Anbieter Applikationen auf mobilen

Endgeräten, wie zum Beispiel Smartphones, um das Fahrzeug zu öffnen. Dabei sendet der Benutzer beispielsweise eine Anfrage zum Öffnen eines Fahrzeugs an einen Server, der eine Benutzerauthentifizierung durchführt und bei erfolgreicher Authentifizierung einen Befehl zum Öffnen des Fahrzeugs an das Fahrzeug sendet.

Zur Nutzung von Car-Sharing-Diensten ist es daher notwendig, entweder eine zusätzliche Karte mitzuführen oder aber eine Internet-Verbindung, die von einem Smartphone und dem Fahrzeug bereitgestellt wird.

Eine Offline-Kommunikation zwischen mobilem Endgerät und Fahrzeug ist bisher nicht möglich.

Ausgehend vom Stand der Technik ist es Aufgabe der vorliegenden Erfindung, ein System und ein Verfahren bereitzustellen, die die vorstehend beschriebenen Nachteile adressieren. Insbesondere ist es Aufgabe der vorliegenden Erfindung, ein System und Verfahren bereitzustellen, das es einem Fahrer ermöglicht, ein Fahrzeug ohne bestehende Internet-Verbindung durch ein mobiles Endgerät zu öffnen. Ferner soll es Flottenbetreibern ermöglicht werden, Auslastungsplanungen durchzuführen, auch wenn die Fahrer nicht über eine Internet-Verbindung verfügen.

Die Aufgabe wird gelöst durch ein Verfahren, umfassend die Schritte: a) Empfangen, durch ein mobiles Endgerät, insbesondere ein Smartphone, einer Identifikationskennung, die einem Zielfahrzeug zugeordnet ist; b) Übermittlung der Identifikationskennung, insbesondere über ein

Mobilfunknetzwerk, an einen Server; c) Empfangen eines Schlüsseldatensatzes von dem Server, insbesondere von einem mobilen Endgerät; d) Übermitteln des Schlüsseldatensatzes und/oder einen, basierend auf dem

Schlüsseldatensatz generierten Code als Remotecode an das Zielfahrzeug, insbesondere über eine Direktverbindung und/oder Adhoc-Netz zwischen dem Zielfahrzeug und dem mobilen Endgerät; e) Empfangen des Remotecodes durch das Zielfahrzeug; f) Generierung mindestens eines Lokalcodes durch das Zielfahrzeug; g) Vergleich des Remotecodes mit dem mindestens einen Lokalcode durch das Zielfahrzeug; h) Öffnen und/oder Freigeben des Zielfahrzeugs und/oder Ausführen eines

Fahrzeugbefehls auf dem Zielfahrzeug, wenn mindestens einer der Lokalcodes mit dem Remotecode übereinstimmt.

Ein wesentlicher Vorteil der Erfindung besteht darin, dass zwischen dem

Zielfahrzeug und dem mobilen Endgerät eine Verbindung zur Kommunikation besteht, z. B. eine Direktverbindung und/oder ein Ad hoc-Netz. Das mobile Endgerät kann daher, ohne eine Internet-Verbindung zu benötigen, einen Code zum Öffnen des Zielfahrzeugs an das Zielfahrzeug senden. Auch das Zielfahrzeug muss nicht über eine Internet -Verbindung verfügen, wodurch insbesondere der Energieverbrauch des Fahrzeugs im Standby-Betrieb gesenkt wird sowie keine Kosten für die Einrichtung einer Internetverbindung im Fahrzeug anfallen.

Erfindungsgemäß kann der gesamte Schritt b) optional sein. Der

erfindungsgemäße Effekt lässt sich auch erzielen, wenn an Stelle der

Identifikationskennung nur eine Gruppenauswahl von Zielfahrzeugen an den Server übermittelt wird und der Server, basierend auf der Gruppenauswahl, ein konkretes Zielfahrzeug mit zugehöriger Identifikationskennung auswählt. Die Gruppenauswahl kann in Form der Angabe/Übermittlung eines Fahrzeugtyps (Boot, Fahrrad, Auto) und/oder eines Standorts (alle Fahrzeuge, die in Augsburg, Bremen oder München stationiert sind) und/oder einer zeitlichen Verfügbarkeit (am Freitag zur Miete verfügbar) erfolgen. Das erfindungsgemäße Verfahren kann in dieser Form den Schritt des Auswählens eines Zielfahrzeugs unter

Berücksichtigung der übermittelten Gruppenauswahl umfassen. Sollten mehrere Fahrzeuge verfügbar sein, die die Gruppenkriterien erfüllen, kann die Auswahl innerhalb dieser Gruppe zufällig oder basierend auf weiteren Parametern, z. B. Auslastung des Fahrzeugs, vorgenommen werden. Vorzugsweise wird die

Identifikationskennung dann an das mobile Endgerät kommuniziert.

Ein weiterer Vorteil der Erfindung besteht darin, dass das mobile Endgerät zu einem frühen Zeitpunkt über den Code zum Öffnen bzw. Freigeben des

Zielfahrzeugs und/oder Ausführen des Fahrzeugbefehls auf dem Zielfahrzeug verfügt. So kann der Fahrer zum Beispiel zu Hause, wenn er über eine WLAN- Verbindung mit dem Internet verbunden ist, den Schlüsseldatensatz vom Server auf dem mobilen Endgerät empfangen.

Das beschriebene Verfahren kann dazu verwendet werden, eine Vielzahl von Fahrzeugen zu betreiben. Insbesondere können Flottenbetreiber (z. B.

Mietwagenfirmen, Firmenpools bestehend aus PKW, Fahrrädern und E-Bikes) effizient die Auslastung ihrer Flotte planen, indem Benutzer von Fahrzeugen frühzeitig mit entsprechenden Codes versorgt werden und die Nutzungszeit vorab in der Auslastungsplanung verwendet werden kann. Insbesondere in

Umgebungen, in denen Benutzer nicht über eine ständige Internet -Verbindung verfügen, zum Beispiel auf dem Wasser oder Golfclubs in ländlichen Gebieten, ist die Verwendung beschrieben Verfahrens von Vorteil. Wenn zum Beispiel ein mobiles Endgerät dazu verwendet wird, ein Boot, zum Beispiel ein Motorboot, zu starten, ist oftmals nicht sichergestellt, dass eine Internetverbindung besteht.

Durch die frühzeitige Code-Übermittlung kann das Verfahren auch sinnvoll für Ferienressorts oder Golfclubs oder Family- oder Social Community-Sharing- Modelle verwendet werden. So kann ein Ferienressort beispielweise alle

Mietfahrobjekte in Wasser und Erde verwalten und die Vergabe effizient managen (z.B. Golfwagen, Boote, Fahrräder, E-Bikes, Mietwagen, sonstige elektrische angetriebene Wasserfahrzeuge) und durch das Modell die Verwaltungskosten reduzieren sowie die Auslastung der Objekte maximieren, da die Vergabe automatisiert erfolgen kann. Auch ergeben sich Community-Sharing-Möglichkeiten für Freunde oder Vereinsmitglieder, die gemeinsam die Nutzung von werthaltigen Fahrzeugen in einem Pool verwalten. So kann eine Community gemeinsam z. B. auf Golfwägen, Wasserfahrzeuge und E-Bikes zugreifen.

In einer Ausführungsform handelt es sich bei dem mobilen Endgerät um ein Smartphone, welches mit einer App ausgestattet sein kann, die die entsprechende Funktionalität bereitstellt. Bei dem auszuführenden Fahrzeugbefehl kann es sich um eine Vielzahl an unterschiedlichen Befehlen handeln. Zum Beispiel Öffnen oder Verriegeln des Fahrzeugs, Starten des Motors, Öffnen oder Schließen des Kofferraums bzw. verschlossenen Räumen eines Bootes, Aktivieren einer

Heizung/Klimatisierung und/oder Aktivieren bzw. Deaktivieren einer Alarmanlage bzw. Aktivierung von elektrischen Aggregaten (z. B. Seilwinde eines Segelbootes, Außenbordmotor) . Das beschriebene Verfahren ist daher sehr flexibel einsetzbar.

In einer Ausführungsform kann der Lokalcode und/oder der Remotecode durch ein Rolling-Code-Verfahren generiert werden und/oder, basierend auf einem Rolling-Code-Verfahren, generiert werden.

Ein Rolling-Code-Verfahren ermöglicht das Verhindern sogenannter "Replay"- Angriffe. Bei Replay-Angriffen fängt ein Angreifer die Kommunikation zwischen dem mobilen Endgerät und dem Fahrzeug ab. Später kann der Angreifer dann die aufgezeichnete Kommunikation verwenden, um das Fahrzeug zu öffnen. Ein Rolling-Code-Verfahren bietet den Vorteil, dass bei jeder Kommunikation zwischen mobilem Endgerät und Fahrzeug ein neuer Remotecode bzw. Lokalcode verwendet wird. Hierzu können zum Beispiel der KeeLoq-Algorithmus oder der Dual KeeLoq-Algorithmus verwendet werden.

In einer Ausführungsform kann der Schlüsseldatensatz einen Seed-Schlüssel umfassen, wobei der Schlüsseldatensatz von einem/dem mobilen Endgerät empfangen werden kann und das mobile Endgerät den Remotecode unter

Verwendung des Seed-Schlüssels generieren kann.

In der beschriebenen Ausführungsform wird also dem mobilen Endgerät ein Seed- Schlüssel mitgeteilt. Unter Verwendung des Seed-Schlüssels, insbesondere mittels eines Pseudozufallszahlengenerators, kann das mobile Endgerät eine Vielzahl von Remotecodes in einem Rolling-Code-Verfahren generieren. Der Server selbst stellt also keinen Remotecode zur Verfügung, sondern das mobile Endgerät generiert diesen selbst. Dieses hat den Vorteil, dass das mobile Endgerät ohne eine

Verbindung zum Server ständig neue Remotecodes generieren kann.

In einer Ausführungsform können ein erster und mehrere weitere Lokalcodes generiert werden und ein Öffnen und/oder Freigeben des Zielfahrzeugs kann nur dann nicht erfolgen, wenn keiner der Lokalcodes mit dem Remotecode

übereinstimmt.

In der beschriebenen Ausführungsform können also mehrere Lokalcodes generiert werden, die mit den Remotecodes verglichen werden können. Nur wenn keiner der generierten Lokalcodes mit dem empfangenen Remotecode übereinstimmt, wird das Fahrzeug geöffnet und/oder freigegeben bzw. ein Befehl auf dem

Fahrzeug ausgeführt. Die beschriebene Ausführungsform hat den Vorteil, dass die Fehleranfälligkeit des Verfahrens verringert wird. So ist es zum Beispiel möglich, dass Übertragungsfehler beim Übertragen des Remotecodes kompensiert werden können. Zum Beispiel kann es beim Einsatz eines Rolling-Code-Verfahrens vorkommen, dass das mobile Endgerät und das Fahrzeug nicht synchron sind. Das bedeutet, dass das mobile Endgerät einen Remotecode sendet, den das Fahrzeug noch nicht generiert hat. Dies tritt auf, wenn die Verbindung beim Übertragen des Remotecodes abbricht.

In der beschriebenen Ausführungsform kann das Fahrzeug zum Beispiel die nächsten 1000 Lokalcodes, bevorzugt 256, weiter bevorzugt 64 Lokalcodes, generieren und diese mit dem empfangenen Remotecode vergleichen.

In einer Ausführungsform kann der Remotecode nach einmaliger Verwendung durch das Zielfahrzeug seine Gültigkeit verlieren. Für die Sicherstellung des Wiederstartes nach Ausschalten des Fahrzeuges kann dann eine zeitlich befriste Kopplung des mobilen Endgerätes genutzt werden. In einer anderen oder zusätzlichen Ausführungsform stellt das Fahrzeug nach dem (ersten)

Öffnen/Freigeben über die Direktverbindung und/oder das Adhoc-Netzwerk ein (weiteres) Geheimnis bereit, dass vorzugsweise auf dem mobilen Endgerät gespeichert und zur erneuten Öffnen/Freigabe genutzt wird . In einer

Ausführungsform implementiert ein Fahrzeug zur Umsetzung dieses Mechanismus mindestens zwei Zustände. In einem ersten Zustand kann das Fahrzeug oder eine beliebige Komponente des Fahrzeugs nur mittels eines Remotecodes des Servers geöffnet oder freigegeben werden. Nach der erfolgreichen Verifizierung dieses Remotecodes nimmt das Fahrzeug den zweiten Zustand ein, in dem ein

Öffnen/Freigeben mittels des (weiteren) Geheimnisses möglich ist. Dieser Zustand kann zeitlich, z. B. auf den Buchungszeitraum, die Gültigkeit des Remotecodes, etc. begrenzt sein. Alternativ oder zusätzlich implementiert das Fahrzeug ein Verfahren, bei dem der zweite Zustand nach einer Benutzereingabe oder dem Empfangen eines Befehls von dem mobilen Endgerät verlässt und wider in den ersten Zustand zurückkehrt. So kann der Benutzer die Buchung frühzeitig über eine manuelle Eingabe beenden.

In einer (anderen) Ausführungsform mit erhöhter Sicherheit für das erneute Öffnen/Freigeben ein weiterer Remotecode von dem Server erzeugt und übermittelt. Der weitere Remotecode kann zeitlich befristet sein (z. B. 1-10 min) und beispielsweise den Wiederstart des Fahrzeuges sicherstellen. Bei der erneuten Codegenerierung können die zeitliche Berechtigung des Nutzers durch den Server geprüft werden. In einer anderen Ausführungsform werden bereits im Schritt c) mehrere Remotecodes empfangen, die nacheinander gültig sind.

Vorzugsweise werden diese mehreren Remotecodes auf dem mobilen Endgerät gespeichert, so dass nach dem„Verbrauchen" des ersten Remotecodes ein (erneutes) Öffnen/Freigeben mit einem nachfolgenden, vorzugsweise schon auf dem Endgerät gespeicherten, Remotecode erfolgen kann.

Es ist von Vorteil, wenn der empfangene Remotecode bzw. optional alle zuvor generierten Remotecodes, ihre Gültigkeit verlieren, sobald ein Remotecode verwendet wurde. Dadurch ist es weiter gewährleistet, dass Replay-Angriffe nicht möglich sind.

In einer Ausführungsform kann ein Remotecode nach einer definierten Zeitspanne seine Gültigkeit verlieren.

Es ist in einer Ausführungsform also möglich, dass ein Remotecode nur über eine begrenzte Gültigkeit verfügt. Der Remotecode kann entweder unendlich lang gültig sein oder zum Beispiel weniger als 5 oder 10 Minuten, bevorzugt weniger als 1 Minute, und weiter bevorzugt weniger als 10 Sekunden, gültig sein. Durch die beschriebene Ausführungsform ist es möglich, dass der Fahrzeugbetreiber die Zeit einschränkt, die ein Fahrer das Fahrzeug nutzen kann. Auch in diesem

Zusammenhang können die bereits beschriebenen Mechanismen zum (erneuten) Öffnen/Freigeben verwendet werden.

Der Remotecode (43, 43\ 43") kann alternativ oder zusätzlich nur innerhalb eines vorgegebenen Zeitintervalls zum Öffnen und/oder Freigeben des Zielfahrzeugs verwendbar sein.

In einer Ausführungsform können das Zielfahrzeug und der Server oder das mobile Endgerät und der Server jeweils, insbesondere miteinander

synchronisierte, Zeitgeber aufweisen, wobei ein Remotecode und ein Lokalcode jeweils kontinuierlich in gleichen Zeitabständen generiert werden können.

Mobiles Endgerät, Zielfahrzeug oder Server können also Zeitgeber aufweisen, wobei ein Zeitgeber durch eine Clock nach dem Stand der Technik umgesetzt sein kann. Die Zeitgeber sind jeweils entweder zwischen Zielfahrzeug und Server oder zwischen mobilem Endgerät und Server miteinander synchronisiert. Das mobile Endgerät und der Server bzw. das Zielfahrzeug und der Server weisen in der beschriebenen Ausführungsform demnach die gleiche Zeitwahrnehmung auf.

Dieses kann dazu verwendet werden, dass jeweils zu gleichen Zeitpunkten Remote- bzw. Lokalcodes generiert werden können. So ist es in der

beschriebenen Ausführungsform möglich, dass alle 5 oder 10 Minuten bzw. jede Minute oder alle 10 Sekunden neue Remote- bzw. Lokalcodes generiert werden. Dies erhöht weiter die Sicherheit.

In einer Ausführungsform kann das Verfahren das Senden eines

Befehlsdatensatzes von dem mobilen Endgerät zu dem Zielfahrzeug umfassen, wobei der Befehlsdatensatz in mindestens einen Fahrzeugbefehl umfasse kann. Ferner kann das Verfahren in einer Ausführungsform das Empfangen des

Befehlsdatensatzes durch das Zielfahrzeug umfassen. Weiter kann in einer Ausführungsform das Verfahren das Ausführen des mindestens einen

Fahrzeugbefehls umfassen, wenn der Lokalcode mit dem Remotecode

übereinstimmt.

Mit der beschriebenen Ausführungsform ist es also möglich, eine beliebige Anzahl von Fahrzeugbefehlen unter Verwendung eines einzigen Remotecodes auszuführen. Durch die beschriebene Ausführungsform wird also die zu

übertragende Datenmenge reduziert.

In einer Ausführungsform kann die Direktverbindung als eine Bluetooth- Verbindung, eine Infrarot-Verbindung, NFC-Verbindung oder als eine WLAN- Verbindung ausgebildet sein.

Die genannten Verbindungstypen haben den Vorteil, dass diese bekannte

Techniken darstellen, die von einer Vielzahl von mobilen Endgeräten unterstützt werden.

In einer Ausführungsform kann Schritt d) das Übermitteln eines zukünftigen Zeitpunkts umfassen, wobei der generierte Remotecode zu dem zukünftigen Zeitpunkt gültig ist.

Es ist also möglich, nicht nur Remotecodes zu generieren, die zum Zeitpunkt der Generierung gültig sind, sondern auch Remotecodes, die erst in der Zukunft eine Gültigkeit erlangen. Dadurch ist es möglich, dass ein Fahrer zum Beispiel einen Remotecode bei einer bestehenden Internet-Verbindung von dem Server empfängt und diesen zu einem späteren Zeitpunkt verwendet, wenn keine Internet-Verbindung mehr sicher besteht. Dies erhöht die Übertragungssicherheit und ermöglicht auch eine frühzeitige Nutzungsplanung der Fahrzeuge durch den Betreiber/Eigentümer.

In einer Ausführungsform kann der Remotecode innerhalb eines Zeitfensters, beispielsweise um den zukünftigen Zeitpunkt herum gültig sein.

Es ist also möglich, dass der Remotecode nicht nur genau zu einem zukünftigen Zeitpunkt gültig ist, sondern dass der Remotecode innerhalb einer Zeitspanne, zum Beispiel ca. 60 oder 30 oder 5 Minuten oder 1 Minute lang, gültig ist. Dieses hat den Vorteil, dass nur ein einziger Remotecode für eine gewisse Zeitdauer generiert werden muss. Alternativ kann das Zeitfenster einen Beginn eines Freigebens/Öffnens und eine maximale Nutzungsdauer angeben. Es ist möglich zu planen, wann welcher Fahrer Zugang zu einem Fahrzeug erhält, wobei die Remotecodes in beliebiger Reihenfolge vergeben werden können. In diesem Zusammenhang ist der Server also dazu ausgebildet, mehrere Remotecodes für unterschiedliche Nutzungszeiträume und/oder Benutzer und/oder mobile Endgeräte zu generieren. Die entsprechenden Remotecodes können dann eine einmalige oder in dem Zeitraum fortlaufende Gültigkeit besitzen. Bei der

Ausführungsform mit der einmaligen Gültigkeit, können die bereits beschriebenen Mechanismen zum erneuten Öffnen/Freigeben eingesetzt werden.

In einer Ausführungsform kann das Fahrzeug erste und zweite Schlüsseldaten zur Generierung einer ersten Schlüsselsequenz bzw. zweiten Schlüsselsequenz aufweisen. Das Verfahren kann ferner umfassen :

- Empfangen einer Schlüsselinformation, insbesondere von dem mobilen Endgerät auf dem Fahrzeug;

- Auswählen der ersten oder zweiten Schlüsseldaten unter Verwendung der Schlüsselinformationen;

- Generieren mindestens eines Lokalcodes unter Verwendung der

ausgewählten Schlüsseldaten;

- Vergleichen des mindestens einen generierten Lokalcodes mit dem

empfangenen Remotecode;

- Öffnen und/oder Freigeben und/oder Ausführen eines Fahrzeugbefehls, wenn der Remotecode mit dem mindestens einen generierten Lokalcode der ausgewählten Schlüsseldaten übereinstimmt.

Wenn die Schlüsselinformationen an das Fahrzeug übertragen werden, kann das Fahrzeug unter Verwendung der Schlüsselinformationen erste oder zweite

Schlüsseldaten auswählen. Auf Grundlage der Schlüsseldaten kann das Fahrzeug einen Lokalcode generieren, der dann mit dem empfangenen Remotecode verglichen wird .

Durch die beschriebene Ausführungsform ist es möglich, dass ein Fahrer z. B. eine Gültigkeitsdauer des Remoteschlüssel als Schlüsselinformation an das Fahrzeug sendet. Das Fahrzeug kann überprüfen, ob ein generierter Lokalschlüssel, der zu der Gültigkeitsdauer korrespondiert mit dem Remoteschlüssel übereinstimmt. Es wird also eine einfache Möglichkeit geboten, die Gültigkeitsdauer eines Schlüssels dem Fahrzeug mitzuteilen.

Die Aufgabe wird ferner gelöst durch ein computerlesbares Speichermedium, welches Instruktionen enthält, die mindestens einen Prozessor dazu veranlassen, eines der oben beschriebenen Verfahren zu implementieren, wenn die

Instruktionen durch mindestens einen Prozessor ausgeführt werden. Es ergeben sich ähnliche oder identische Vorteile, wie sie bereits mit den oben stehenden Verfahren beschrieben wurden.

Die Aufgabe wird ferner gelöst durch ein System zur Öffnung und/oder Nutzung eines Fahrzeugs, umfassend :

- mindestens einen Server, der eine Datenbank umfasst und dazu ausgebildet ist, mindestens eine Identifikationskennung von mindestens einem mobilen Endgerät zu empfangen, wobei der Server dazu ausgebildet ist, unter

Verwendung der Datenbank und der Identifikationskennung ein Zielfahrzeug zu bestimmen;

- ein Fahrzeug, Folgendes aufweisend :

- eine Speichereinrichtung;

- eine Fahrzeugkommunikationseinrichtung, die dazu ausgebildet ist, einen Schlüsseldatensatz und/oder einen basierend auf dem Schlüsseldatensatz generierten Code als Remotecode über eine Direktverbindung und/oder über ein Ad hoc-Netz zu empfangen;

- eine Fahrzeugrecheneinheit, die dazu ausgebildet ist, einen Lokalcode zu generieren und die ferner dazu ausgebildet ist, den Remotecode mit dem Lokalcode zu vergleichen. Dabei ist die Fahrzeugrecheneinheit weiter dazu ausgebildet, das Fahrzeug zu öffnen und/oder freizugeben und/oder einen Fahrzeugbefehl auszuführen, wenn der Remotecode und der Lokalcode übereinstimmen.

In einer Ausführungsform können der Lokalcode und/oder der Remotecode durch ein Rolling-Code-Verfahren generiert werden, zum Beispiel durch den KeeLoq- Algorithmus oder den Dual KeeLoq-Algorithmus, und/oder basierend auf einem Rolling-Code-Verfahren generiert werden.

In einer Ausführungsform kann der Schlüsseldatensatz einen Seed-Schlüssel umfassen. Ferner kann das System ein mobiles Endgerät umfassen, wobei das mobile Endgerät umfassen kann :

- eine Endgeräte-Kommunikationseinrichtung, die dazu ausgebildet sein kann, einen Schlüsseldatensatz zu empfangen; - eine Endgeräte-Recheneinheit, die dazu ausgebildet sein kann, den

Remotecode unter Verwendung des Seed-Schlüssels, insbesondere mittels eines Pseudozufallszahlengenerators, zu generieren.

Es ergeben sich ähnliche oder identische Vorteile, wie sie bereits in

Zusammenhang mit den vorstehend beschriebenen Verfahren beschrieben wurden.

Das beschriebene System ist kann dazu ausgebildet sein, die vorstehend beschriebenen Verfahren zu implementieren.

Weitere Ausführungsformen ergeben sich aus den Unteransprüchen.

Nachfolgend wird die Erfindung mittels mehrerer Ausführungsbeispiele

beschrieben, die anhand von Abbildungen näher erläutert werden. Hierbei zeigen :

Figur 1 eine schematische Ansicht des erfindungsgemäßen Systems;

Figur 2 eine schematische Ansicht eines Fahrrads;

Figur 3 eine schematische Ansicht eines mobilen Endgeräts;

Figur 4 eine schematische Ansicht eines Servers;

Figur 5 eine beispielhafte Datenbanktabelle;

Figur 6 ein Flussdiagramm für ein Verfahren zum Öffnen eines Fahrzeugs; Figur 7 eine schematische Ansicht der Gültigkeitsdauer von Remotecodes; Figur 8 eine zeitliche Darstellung der Gültigkeitsdauer eines Remotecodes; Figur 9 eine Datenbanktabelle mit verschiedenen Seed-Schlüsseln; Figur 10 eine schematische Darstellung verschiedener Schlüsselsequenzen; und Figur 11 eine schematische Darstellung eines Fahrzeugs und eines mobilen Endgeräts ohne Internet-Verbindung.

Im Folgenden werden für gleiche oder gleich wirkende Teile dieselben

Bezugsziffern verwendet.

Figur 1 zeigt eine schematische Darstellung eines Systems 1 zum Öffnen eines Fahrzeugs 10 unter Verwendung eines mobilen Endgeräts 20. Das Fahrzeug 10 ist im beschriebenen Ausführungsbeispiel als ein Fahrrad 10 ausgebildet. Ferner verfügt das System 1 über ein mobiles Endgerät 20, welches im vorliegenden Ausführungsbeispiel als ein Smartphone 20 ausgebildet ist. Das Smartphone 20 ist über eine Mobilfunkverbindung 5 mit einem Server 30 verbunden.

Bei der Mobilfunkverbindung 5 kann es sich um eine Mobilfunkverbindung nach dem LTE-, UMTS- oder GSM-Standard handeln. Ferner kann es sich bei der Verbindung 5 auch um jede weitere denkbare Internet-Verbindung handeln. Die Verbindung 5 kann drahtlos oder drahtgebunden ausgebildet sein.

Zum Öffnen des Fahrrads 10 fordert das Smartphone 20 von dem Fahrrad 10 eine Identifikationskennung 15 an. Diese wird in dem beschriebenen

Ausführungsbeispiel über eine Direktverbindung 2 übertragen. Dabei handelt es sich im vorliegenden Beispiel um eine Bluetooth-Verbindung. Das Smartphone 20 befindet sich daher zur Abfrage der Identifkationskennung innerhalb eines Empfangsradius des Fahrrads 10, da sonst keine Bluetooth-Verbindung 6 hergestellt werden könnte.

In anderen Ausführungsbeispielen kann es sich bei der Direktverbindung 2 auch um eine WLAN-Verbindung 4 oder um ein Ad hoc-Netz 3 handeln.

Die Identifikationskennung 15 stellt eine eindeutige Identifikation des Fahrrads 10 sicher. Die Identifikationskennung 15 kann daher eine Global Unique Identifier (GUID) sein. Es ist jedoch nicht notwendig, eine global eindeutige Kennzeichnung zu verwenden. Auch ein im beschriebenen System eindeutige Zahl ist möglich.

Das Smartphone 20 sendet die empfangene Identifikationskennung 15 an den Server 30 und fordert einen Remotecode 43 vom Server 30 an. Im vorliegenden Ausführungsbeispiel sendet das Smartphone 20 die Identifikationskennung 15 über eine LTE-Verbindung 5 an den Server 30.

Der Server 30 führt im Anschluss eine Datenbankabfrage aus, wobei unter Verwendung der empfangenen Identifikationskennung 15 ein Remotecode 43 generiert wird. Zu diesem Zweck hat der Server 30 in einer Datenbank zu jedem Fahrzeug einen Seed-Schlüssel gespeichert. Unter Verwendung eines

Pseudozufallszahlengenerators generiert der Server 30 einen Remotecode 43, der nur durch das Fahrrad 10 verwendet werden kann.

Der Server 30 sendet den generierten Remotecode 43 an das Smart Phone 20.

In anderen Ausführungsbeispielen kann der Server 30 an Stelle des Remotecodes 43 einen Schlüsseldatensatz 40 an das Smart Phone 20 senden. Der

Schlüsseldatensatz 40 kann dabei den Seed-Schlüssel umfassen. Das Smart Phone 20 kann also auch dazu benutzt werden, einen Remotecode 43 zu generieren.

In einem weiteren Ausführungsbeispiel sendet der Server 30 nicht nur einen Remotecode 43 an das mobile Endgerät 20, sondern eine Vielzahl von

Remotecodes.

Die Kommunikation zwischen mobilem Endgerät 20 und Server 30 kann auch verschlüsselt ausgebildet sein, z. B. durch ein asymmetrisches

Verschlüsselungsverfahren wie PGP. So können das mobile Endgerät 20 und der Server jeweils einen privaten Schlüssel speichern, wobei die Nachrichten zwischen mobilen Endgerät 20 und dem Server 30 durch einen öffentlichen Schlüssel verschlüsselt sind . Die privaten Schlüssel werden jeweils zum Entschlüsseln der Nachrichten verwendet.

Der übertragene Schlüsseldatensatz 40 kann also einen verschlüsselten

Remotecode 43 umfassen.

Das Smartphone 20 kann den empfangenen Remotecode 43 dazu verwenden, das Fahrrad 20 zu entsperren. Dazu sendet das Smartphone 20 den empfangenen Remotecode 43 über eine Bluetooth-Verbindung 6 an das Fahrrad 10. Wie in Figur 2 gezeigt, verfügt das Fahrrad 10 über eine Fahrzeug-Kommunikationseinrichtung 11, über die der Remotecode 43 empfangen werden kann. Im aktuellen Ausführungsbeispiel ist die Fahrzeugkommunikationseinrichtung 11 als ein Bluetooth-Modul ausgebildet. Das Fahrrad 10 verfügt ferner über eine Speichereinrichtung 17, in die der Remotecode 43 nach Empfang durch die Fahrzeugkommunikationseinrichtung 11 geschrieben wird. Unter Verwendung eines Pseudozufallszahlengenerators 14 kann das Fahrrad 10 einen Lokalcode 42 generieren, der von einer Fahrzeugrecheneinheit 12 mit dem empfangenen Remotecode 43 verglichen wird. Stimmen Remotecode 43 und Lokalcode 42 überein, so wird das Fahrrad 10 entriegelt. Die Energieversorgung des Fahrrads 10 wird ferner über eine Batterie 16 sichergestellt.

Figur 3 zeigt eine schematische Darstellung eines mobilen Endgeräts 20. Das mobile Endgerät 20 umfasst eine Endgerätekommunikationseinrichtung 21, die im aktuellen Ausführungsbeispiel als Bluetooth-Kommunikationseinrichtung 21 ausgebildet ist. Die Endgerätekommunikationseinrichtung 21 steht in

kommunikativer Verbindung mit einer Endgerätespeichereinrichtung 23. Das mobile Endgerät 20 verfügt ferner über eine Endgeräterecheneinheit 22, die in kommunikativer Verbindung mit der Endgerätespeichereinrichtung 23 steht.

In einem Ausführungsbeispiel kann das mobile Endgerät 20 auch über einen Pseudozufallszahlengenerator 24 verfügen. Unter Verwendung des

Pseudozufallszahlengenerators 24 ist das mobile Endgerät in der Lage,

selbständig Remotecodes 43 zu generieren.

Figur 4 zeigt die schematische Darstellung eines Servers 30. Der Server 30 verfügt über eine Serverkommunikationseinrichtung 33, die im aktuellen

Ausführungsbeispiel dazu ausgebildet ist, eine Internetverbindung bereitzustellen. Die Serverkommunikationseinrichtung 33 ist in kommunikativer Verbindung mit einer Serverspeichereinrichtung 31, in der eine Datenbank 32, 32' (sh. Figuren 5 und 9) abgespeichert ist. Der Server 30 verfügt ferner über eine

Serverrecheneinheit 34. Auch der Server 30 ist in einem Ausführungsbeispiel dazu ausgebildet, Remotecodes 43 unter Verwendung eines

Pseudozufallszahlengenerators zu generieren. In einem weiteren

Ausführungsbeispiel kann jedoch auch eine große Anzahl von Remotecodes 43 in der Datenbank 32 gespeichert sein. Figur 5 zeigt eine Datenbanktabelle der Datenbank 32, die auf dem Server 30 gespeichert ist. Die dargestellte Datenbanktabelle umfasst zwei Spalten, wobei in einer ersten Spalte Fahrzeugidentifikationsnummern 15, 15', 15" gespeichert sind. Jeder Fahrzeugidentifikation 15, 15', 15" wird ein Seed-Schlüssel 45, 45', 45" zugeordnet. Da jedem Fahrzeug eindeutig eine

Fahrzeugidentifikationsnummer 15, 15', 15" zugeordnet ist, wird über die

Datenbank 32 jedem Fahrzeug 10 ein entsprechender Seed-Schlüssel 45, 45', 45" zugewiesen.

Der Server 30 ermittelt in einem Ausführungsbeispiel nach Empfang einer

Fahrzeugidentifikation 15, 15', 15" den zugehörigen Seed-Schlüssel 45, 45', 45". Unter Verwendung des ermittelten Seed-Schlüssels 45, 45', 45" generiert der Server 30 einen Remotecode 43, der über die Serverkommunikationseinrichtung 33 an das Smartphone 20 gesendet wird.

In anderen Ausführungsbeispielen übermittelt der Server 30 unmittelbar den ermittelten Seed-Schlüssel 45, 45', 45".

Figur 6 zeigt ein Flussdiagramm, welches die Schritte zum Öffnen eines Fahrzeugs 10 darstellt.

Im Schritt Sl empfängt ein mobiles Endgerät 20 eine Identifikationskennung 15 von einem Fahrzeug 10. Die Identifikationskennung 15 wird im Schritt S2 über ein Mobilfunknetzwerk 5 an den Server 30 übermittelt. Im Schritt S3 generiert der Server 30 einen Remotecode 43 und sendet den Remotecode 43 an das mobile Endgerät 20.

In einem weiteren Ausführungsbeispiel sendet der Server 30 einen Seed-Schlüssel 45 an das mobile Endgerät. In noch einem weiteren Ausführungsbeispiel sendet der Server 30 eine Vielzahl an Remotecodes 43 an das mobile Endgerät 20.

Nach dem Empfang des Remotecodes 43 von dem Server 30 auf dem mobilen Endgerät 20 übermittelt das mobile Endgerät 20 im Schritt S4 den Remotecode 43 an das Fahrzeug 10. Das Übermitteln wird im vorliegenden Ausführungsbeispiel über ein WLAN ausgeführt. Im Schritt S5 empfängt das Fahrzeug 10 den Remotecode 43 und generiert im Schritt S6 einen Lokalcode 42. Im Schritt S7 werden der generierte Lokalcode 42 und der empfangene Remotecode 43 miteinander verglichen. Wenn die beiden Codes nicht übereinstimmen, so wird im Schritt S9 eine Fehlermeldung an das mobile Endgerät 20 übermittelt. In einem weiteren Ausführungsbeispiel kann im Schritt S9 ein Zähler erhöht werden, so dass nach einer Anzahl von Versuchen, vorzugsweise drei Versuchen, das Fahrzeug permanent gesperrt wird.

Stimmen der generierte Lokalcode 42 und der empfangene Remotecode 43 überein, so wird im Schritt S8 das Fahrzeug 10 geöffnet. Beim Öffnen kann in einem Ausführungsbeispiel eine Steuerelektronik eingesetzt werden, um einen Stellmotor anzusteuern, der ein Schloss öffnet. Alternativ kann auch ein

Magnetschloss eingesetzt werden.

In einem weiteren Ausführungsbeispiel kann im Schritt S8 ein beliebiger

Fahrzeugbefehl ausgeführt werden, der zusammen mit dem Remotecode 43 im Schritt S4 an das Fahrzeug 10 übermittelt wurde.

Im anschließenden Schritt S10 wird der empfangene Remotecode (optional) als ungültig markiert. Das bedeutet, dass bei einem erneuten Empfang desselben Remotecodes 43 dieser nicht mehr funktioniert. Wird ein Rolling-Code-Verfahren verwendet, so wird nicht nur der aktuelle Remotecode 43 ungültig, sondern es werden auch alle zeitlich davor liegenden Remotecodes als ungültig markiert.

Figur 7 zeigt schematisch das Generieren von Lokalcodes 42, 42', 42" und

Remotecodes 43, 43', 43" in einem Ausführungsbeispiel, in dem synchronisierte Zeitgeber 13, 24 verwendet werden, um in kontinuierlichen Zeitabständen

Remote- bzw. Lokalcodes zu generieren. Im aktuellen Ausführungsbeispiel umfassen das Fahrzeug 10 und das mobile Endgerät 20 Zeitgeber 13, 24, die synchronisiert sind. Zu einem ersten Zeitpunkt Tl wird auf dem mobilen Endgerät 20 ein Remotecode 43 generiert und auf dem Fahrzeug 10 ein Lokalcode 42. Nach Ablauf einer Gültigkeitsdauer 47 werden der Lokalcode 42 und der Remotecode 43 als ungültig markiert. Anschließend wird zum Zeitpunkt T2 ein neuer Lokalcode 42 und ein neuer Remotecode 43 generiert. Diese werden wieder nach Ablauf der Gültigkeitsdauer 47 als ungültig markiert, worauf im Anschluss ein neuer

Lokalcode 42" und ein neuer Remotecode 43" generiert werden. Dadurch, dass die Remote- und Lokalcodes jeweils als ungültig markiert werden, ist es unbedingt notwendig, dass die verwendeten Zeitgeber 13, 24 synchronisiert werden. Die Synchronisation der Zeitgeber 13, 24 kann entweder durch ein entsprechendes Protokoll während des Betriebs durchgeführt werden oder bei Auslieferung der einzelnen Komponenten.

Figur 8 zeigt ein Ausführungsbeispiel, bei dem ein erzeugter Remotecode 43 in einem Zeitfenster TF um einen Zeitpunkt T gültig ist. Es ist also möglich, dass für einen Remotecode 43 ein Zeitpunkt T definiert wird, an dem der Remotecode 43 gültig sein soll. Ferner ist es möglich, ein Zeitfenster TF zu definieren, zum Beispiel 5 Minuten, welches als Puffer oder auch Ausleihdauer dient. Der

Remotecode 43 kann dann nur im Zeitraum T-TF und T+TF zum Öffnen eines Fahrzeugs 10 verwendet werden. Zeitpunkt T und Zeitdauer TF können als Information mit dem Remotecode 43 von dem mobilen Endgerät 20 an das Fahrzeug 10 übermittelt werden.

Figur 9 zeigt eine Tabelle einer Datenbank 32', in der einem Fahrzeug 10 eine Vielzahl von Seed-Schlüsseln 45, 45\ 45" unterschiedlichen Typs zugeordnet wird. Eine Identifikationskennung 15 wird im gezeigten Beispiel drei Seed- Schlüsseln 45, 45', 45" zugeordnet. Ein Seed-Schlüsseltyp 48, 48', 48" gibt die Gültigkeitsdauer der unter Verwendung der Seed-Schlüssel 45, 45', 45" erzeugten Remotecodes 43 an.

Zum Beispiel kann der Schlüsseltyp 48 angeben, dass die Remotecodes 43, die unter Verwendung des Seed-Schlüssels 45 generiert werden, eine Gültigkeit von 30 Minuten haben. Erzeugte Remotecodes des Schlüsseltyps 48' können eine Gültigkeit von 60 Minuten haben und Remotecodes des Schlüsseltyps 48" eine Gültigkeit von 3 Stunden. Das mobile Endgerät 20 generiert auf Grundlage des vom Server 30 empfangenen Seed-Schlüssels 45, 45', 45" einen Remotecode 43.

Der Remotecode 43 wird an das Fahrzeug 10 gesandt. Damit das Fahrzeug 10 bestimmen kann, von welchem Typ 48, 48', 48" der Remotecode 43 ist, verfügt das Fahrzeug 10 über dieselben Seed-Schlüssel 45, 45', 45" wie der Server 30. Das Fahrzeug 10 generiert nun für alle Seed-Schlüssel 45, 45', 45" Lokalcodes Kl bis K6 und vergleicht den empfangenen Remotecode 43 mit sämtlichen erzeugten Lokalcodes Kl bis K6. Je nachdem welcher Lokalcode Kl bis K6 mit dem empfangenen Remotecode 43 übereinstimmt, kann das Fahrzeug bestimmen, durch welchen Seed-Schlüssel 45, 45', 45" der Lokalcode Kl bis K6 generiert wurde. Daher lässt sich durch den Vergleich feststellen, von welchem

Schlüsseltyp 48, 48', 48" der empfangene Remotecode 43 ist.

Wird zum Beispiel festgestellt, dass der empfangene Remotecode 43 vom Typ 48' ist, so wird das Fahrzeug 10 für 60 Minuten freigeschaltet.

In einem Ausführungsbeispiel sendet des mobile Endgerät 20 den Schlüsseltyp 48, 48\ 48" als Information an das Fahrzeug 10 zusammen mit dem Remotecode 43. Das Fahrzeug 10 kann dann unter Verwendung des empfangenen Schlüsseltyp 48, 48\ 48" feststellen, welchen Seed-Schlüssel 45, 45\ 45" es verwenden muss, um einen Lokalcode 45 zu generieren.

Figur 10 zeigt verschiedene Schlüsselsequenzen 46, 46' 46", die auf dem

Fahrzeug 10 generiert wurden. Jeder Schlüsselsequenz 46, 46' 46" ist ein Seed- Schlüssel 45, 45\ 45", die jeweils einem anderen Schlüsseltyp 48, 48\ 48" zugeordnet sind.

Figur 11 zeigt, wie ein Smartphone 20 ohne eine bestehende Internetverbindung zu einem Server 30 ein Fahrrad 10 öffnen kann. Auf dem Smartphone 20 ist ein Remotecode 43 gespeichert. Der Remotecode 43 kann nun mittels einer

Bluetooth-Verbindung 6, einer WLAN-Verbindung oder über ein Ad hoc-Netz 3 an das Fahrrad 10 übermittelt werden. Das Fahrrad 10 vergleicht den empfangenen Remotecode 43 mit einem generierten Lokalcode 42 und gibt das Fahrrad 10 entsprechend frei.

Dem Fachmann ergibt sich, dass die vorstehend beschriebenen

Ausführungsbeispiele und Ausführungsformen lediglich beispielhaften Charakter haben und dass die einzelnen Aspekte der Ausführungsbeispiele miteinander kombiniert werden können, ohne vom Erfindungsgedanken abzuweichen.

Bezugszeichenliste:

1 System

2 Direktverbindung

3 Ad-Hoc-Netz

4 WLAN 5 Mobilfunknetzwerk

6 Bluetoothverbindung

10, 10\ 10" Fahrzeug, Zielfahrzeug, Fahrrad

11 Fahrzeug-Kommunikationseinrichtun

12 Fahrzeug -Recheneinheit

13, 24 Zeitgeber

14, 24 Pseudozufallszahlengenerator

15, 15\ 15" Identifikationskennung

16 Batterie, Energieversorgung

17, 31 Speichereinrichtung

20 mobiles Endgerät, Smartphone

21 Endgeräte-Kommunikationseinrichtu

22 Endgeräte-Recheneinheit

23 Endgeräte-Speichereinrichtung

30 Server

32, 32 ^Λ Datenbank

33 Server-Kommunikationseinrichtung

34 Server-Recheneinheit

40 Schlüsseldatensatz

41 Code

42, 42\ 42" Lokalcode

43, 43\ 43" Remotecode

Kl, K2 Schlüssel vom Typ 48

K3, K4 Schlüssel vom Typ 48'

K5, K6 Schlüssel vom Typ 48"

45, 45\ 45" Seed-Schlüssel

46, 46\ 46" Schlüsselsequenz

47 Gültigkeitsdauer

48, 48\ 48" Schlüsseltyp

50 Befehlsdatensatz

51 Fahrzeugbefehl

TS Zeitspanne

TA Zeitabstände

T, Tl, T2, T3 Zeitpunkt

TF Zeitfenster

Sl, S2, S3, Schritt

S4, S5, S6, S7, S8, S9, S10