[0001] Die vorliegende Erfindung betrifft ein Verfahren zur automatischen Ermittlung der
Nutzung von Fahrzeugen. Im Kern geht es um die automatische Ermittlung der Nutzung
kostenpflichtiger Transportmittel als Grundlage für die Abrechnung des Fahrpreises.
Dabei wird davon ausgegangen, dass aus dem Vorhandensein eines mobilen Endgeräts im
Fahrzeug auf die Nutzung des Fahrzeugs durch einen Nutzer geschlossen wird. Seit mehreren
Jahren gibt es im Stand der Technik unterschiedliche Ansätze, eine Fahrgeldabrechnung
auf Basis der technisch festgestellten Anwesenheit von Fahrgästen in einem Fahrzeug
durchzuführen. Dazu werden zwischen einer Fahrzeuginfrastruktur und einem Nutzerendgerät
periodisch und drahtlos Daten ausgetauscht. Diese Daten können im Nutzerendgerät gegen
einen (zuvor aufgeladenen) Fahrwert verbucht werden, oder die Daten werden an einen
Zentralrechner übermittelt, und dort werden die Fahrt ermittelt und der Fahrpreis
berechnet. Diese Verfahren sind unter dem Stichwort "Be-In / Be-Out" bekannt, kurz
"BIBO".
[0002] Für den Datenaustausch zwischen der Fahrzeuginfrastruktur und den Nutzerendgeräten
gibt es im Stand der Technik unidirektionale BIBO-Verfahren, bei denen ein Fahrzeugsender
Funksignale mit digitalen Dateninhalten ("Datentelegramme") aussendet, die von den
im Fahrzeug anwesenden Nutzerendgeräten empfangen werden können. Weiter gibt es bidirektionale
BIBO-Verfahren, bei denen Datentelegramme zwischen dem Fahrzeugsender und der Vielzahl
von Nutzerendgeräten hin- und her gesendet werden. Der Nachteil der unidirektionalen
BIBO-Verfahren ist, dass auf Seiten der Fahrzeuginfrastruktur nicht oder zumindest
nicht unmittelbar bekannt ist, welche Nutzermedien aktuell im Fahrzeug anwesend sind;
der Nachteil der bidirektionalen BIBO-Verfahren ist, dass das Hin- und Hersenden von
Datentelegrammen ein erhebliches Aufkommen von Funkverkehr im Fahrzeug bedeutet und
dass die Sende- und Empfangsvorgänge von der Fahrzeuginfrastruktur aufwendig synchronisiert
werden müssen, um Signalkollisionen zu vermeiden, die zu Datenverlust in relevantem
Ausmaß führen können.
[0003] Im Stand der Technik ist eine Reihe von BIBO-Verfahren bekannt, so z.B. aus
DE 199 57 660 (bidirektionaler Datenaustausch) und
EP 1 667 074 A1 (unidirektionaler Datenaustausch).
[0004] BIBO-Verfahren können grundsätzlich mit verschiedenartigen Nutzerendgeräten durchgeführt
werden. Es können dezidierte Geräte verwendet werden, die spezifisch dazu eingerichtet
sind, Datentelegramme von der Fahrzeuginfrastruktur zu empfangen und ggf. auch Datentelegramme
an die Fahrzeuginfrastruktur zurückzusenden. Jedenfalls müssen die Nutzerendgeräte
über eine Funkschnittstelle mit der Fahrzeuginfrastruktur über einige Meter Distanz
drahtlos kommunizieren können. Das setzt voraus, dass die Nutzerendgeräte eine eigene
Energieversorgung haben. Wenn nun dezidierte Nutzerendgeräte verwendet werden, so
müssen diese nicht nur eigens für diesen Zweck hergestellt und an die Nutzer verteilt
werden, sondern es muss auch sichergestellt sein, dass die Nutzerendgeräte entweder
über ein ausgeklügeltes Energiemanagement verfügen, so dass ihre Energieversorgung
- in der Regel über eine Batterie - für eine lange Zeit ausreicht, oder die Nutzerendgeräte
müssen über einen Akku verfügen, der von den Nutzern nachgeladen werden muss.
[0005] Die weite Verbreitung mobiler Endgeräte aus dem IT-Sektor hat nun angeregt, anstelle
dezidierter Nutzerendgeräte massenmarkt-verfügbare mobile Endgeräte, z.B. Smartphones,
für BIBO-Verfahren anzuwenden. Eine Vielzahl von Nutzern führt diese Geräte praktisch
immer mit sich und lädt sie auch regelmäßig auf. Mit der Nutzung massenmarkt-verfügbarer
mobiler Endgeräte als BIBO-Nutzerendgerät entfällt sowohl die Notwendigkeit, dezidierte
BIBO-Nutzerendgeräte zu produzieren und zu verteilen, als auch der Zwang zu einem
ausgeklügelten Energiemanagement. BIBO-Verfahren lassen sich auf einem massenmarkt-verfügbaren
mobilen Endgerät durch mobile Applikationen, also so genannte "Apps", realisieren.
[0006] Im Stand der Technik beschäftigten sich beispielweise die
EP 2 657 900 A1 und die
EP 2 658 291 A1 mit dem Einsatz massenmarkt-verfügbarer mobiler Endgeräte für BIBO-Verfahren.
[0007] Ein weiterer Vorteil der Verwendung massenmarkt-verfügbarer mobiler Endgeräte als
BIBO-Nutzerendgerät besteht darin, dass diese Endgeräte über eine Vielzahl von funkbasierten
Datenschnittstellen verfügen, die für BIBO-Verfahren genutzt werden können.
[0008] Der Nachteil dieser Schnittstellen ist, dass sie zumeist "offen" sind, d.h. die massenmarkt-verfügbaren
mobilen Endgeräte sind in der Lage, über ihre Funkschnittstellen digitale Daten aus
verschiedenen Quellen zu empfangen. Damit ist nicht sichergestellt, dass Datentelegramme,
die von den mobilen Endgeräten empfangen werden, auch wirklich authentische und für
die Fahrtabrechnung heranzuziehende Daten darstellen. Massenmarkt-verfügbare mobile
Endgeräte verfügen i.d.R. über eine Schnittstelle für digitale Mobilfunknetze (GSM,
GPRS, UMTS, LTE), die meist für Telefonie und den Datenaustausch in die Mobilfunknetze
verwendet wird. Lediglich diese Schnittstelle ist über eine SIM-Karte gesichert und
im Mobilfunknetz autorisiert; die Mobilfunkschnittstelle kann aber nicht zum Empfang
von BIBO-Datentelegrammen aus der Fahrzeuginfrastruktur genutzt werden, da Mobilfunknetze
die BIBO-Anforderungen hinsichtlich einer stark begrenzten Lokalisation nicht erfüllen.
Andere Funkschnittstellen massenmarkt-verfügbarer mobilen Endgeräte sind offen und
können nicht für ein BIBO-Verfahren eigens gesichert werden.
[0009] Eine weitere Schwierigkeit aller BIBO-System liegt darin, sicher zu bestimmen, dass
ein Nutzer mit einem Nutzerendgerät - sei es ein dezidiertes Gerät für ein Fahrausweissystem
oder ein massenmarkt-verfügbares mobiles Endgerät - eine bestimmte Fahrt unternommen
hat. Dazu muss sicher bestimmt werden, dass sich der Nutzer mit seinem Endgerät über
eine Abfolge von Zeitpunkten in einem bestimmten Fahrzeug aufgehalten hat. Die Abfolge
von Zeitpunkten stellt dabei die Fahrtdauer dar. Der Weg, den das Fahrzeug dabei zurückgelegt
hat, ist die Fahrtstrecke, welche in der Regel Grundlage der Fahrpreisberechnung ist.
Ein kritischer Aspekt ist dabei die Möglichkeit, dass Fahrzeuge - z.B. Busse, Straßenbahnen
- an Bushöfen, Ampeln oder beim Fahren nebeneinander einen so geringen Abstand haben,
dass ein Nutzerendgerät Datentelegramme von mehreren Fahrzeugen gleichzeitig erhält.
[0010] Im Stand der Technik ist dazu eine Reihe von Verfahren bekannt. So wird in der
EP 1 669 935 ein Verfahren vorgeschlagen, bei dem ein Nutzerendgerät, welches Datentelegramme
von mehreren Fahrzeugen empfängt, anhand der zeitlichen Änderung der Signalstärke
der Datentelegramme bestimmt, welche Datentelegramme "gültig" sind, d.h. von einem
Fahrzeug stammen, in dem der Nutzer wirklich mitfährt. Dabei lehrt die
EP 1 669 935 das Bestimmen des benutzen Fahrzeugs durch das Nutzerendgerät in Echtzeit, also noch
während der Fahrt.
[0011] In der
EP 2 658 291 A1 wird ein BIBO-Verfahren mit massenmarkt-verfügbaren mobilen Endgeräten vorgeschlagen,
bei welchem mit dem Einsatz der Sensorik, die in solchen Endgeräten vorhanden ist,
der Aufenthaltsort des Endgeräts - also z.B. das benutze Fahrzeug - bestimmt werden
kann, ohne dass das mobile Endgerät fahrzeugspezifische Datentelegramme zu empfangen
braucht, d.h. es braucht dafür keine spezifische Fahrzeuginfrastruktur aufgebaut zu
werden. Dabei lehrt die
EP 2 658 291 A1 das Bestimmen des benutzen Fahrzeugs durch einen Zentralrechner und damit nicht notwendigerweise
in Echtzeit. Allerdings ist das Bestimmen des benutzen Fahrzeugs, ohne dass das Endgerät
fahrzeugspezifische Datentelegramme empfängt, nicht sehr genau und damit als Grundlage
für eine Fahrgeldabrechnung durchaus anzweifelbar. Die Aufgabe der Erfindung ist es
daher, ein robustes Verfahren vorzuschlagen, das die Bestimmung des Aufenthalts eines
mobilen Endgeräts in einem Fahrzeug ermöglicht und die Authentizität der dazu verwendeten
Datentelegramme sicherstellt, selbst dann, wenn die Nutzerendgeräte offene Schnittstellen
für das Verfahren verwenden.
[0012] Zur technischen Lösung dieser Aufgabe wird ein Verfahren mit den Merkmalen des Patentanspruches
1 vorgeschlagen. Weitere Vorteile und Merkmale ergeben sich aus den Unteransprüchen.
Hinsichtlich des Systems schlägt die Erfindung ein System mit den Merkmalen des Patentanspruches
13 vor. Weitere Vorteile und Merkmale ergeben sich aus den Unteransprüchen.
[0013] Erfindungsgemäß sind in einem Fahrzeug wenigstens ein Fahrzeugsender und wenigstens
ein Fahrzeugempfänger installiert. Der wenigstens eine Fahrzeugsender ist dazu eingerichtet,
fahrzeugeigene Datentelegramme drahtlos auszusenden, welche Datentelegramme das Fahrzeug
eindeutig identifizieren. Datentelegramme sind dabei modulierte Funksignale, die digitale
Daten enthalten.
[0014] Fahrzeugdatentelegramme sind solche Datentelegramme, deren digitale Daten wenigstens
eine systemweit eineindeutige Kennung des Fahrzeugs enthalten, dessen Fahrzeugsender
die Telegramme gesendet hat..Fremddatentelegramme sind solche Datentelegramme, die
deren digitale Daten zwar eine Kennung eines Fahrzeugs enthalten, die aber in einem
anderen Fahrzeug empfangen werden. Damit kann ein Datentelegramm in dem Fahrzeug,
in dem es ausgesandt wurde, ein Fahrzeugdatentelegramm sein, wenn es aber in einem
anderen Fahrzeug empfangbar ist, dann ist es dort ein Fremddatentelegramm. Weiter
können Fremddatentelegramme dadurch entstehen, dass innerhalb eines Fahrzeugs missbräuchlich
Datentelegramme ausgesandt werden, die nicht zu diesem Fahrzeug gehören.
[0015] Neben der Kennung des Fahrzeugs können Fahrzeugdatentelegramme (und damit auch Fremddatentelegramme)
weitere Daten enthalten wie z.B. Datums-/Zeitstempel, Zufallszahlen und/oder Ortsdaten
des Fahrzeugs.
[0016] Der wenigstens eine Fahrzeugempfänger ist erfindungsgemäß eingerichtet, die fahrzeugeigenen
und fahrzeugfremde Datentelegramme drahtlos zu empfangen und die darin enthaltenen
Daten weiterzuverarbeiten und an eine fahrzeugseitige Kommunikationseinrichtung weiterzuleiten,
welche ihrerseits eingerichtet ist, Daten mit einem Zentralrechner auszutauschen.
In einer bevorzugten Ausführungsform ist die fahrzeugseitige Kommunikationseinrichtung
der Bordrechner eines Fahrzeugs, also beispielsweise der Bordrechner eines Busses,
einer Straßenbahn, einer U-Bahn, eines Zuges, eines Schiffes, eines Taxis oder eines
vergleichbaren Fahrzeugs.
[0017] Der fahrzeugseitigen Kommunikationseinrichtung ist für das erfindungsgemäße Verfahren
der Ort des Fahrzeugs bekannt; in der Praxis wird zu Bestimmung des Fahrzeugorts auf
vorhandene Fahrzeuginfrastruktur zurückgegriffen, welche Ortsdaten für das Fahrzeug
liefert. Ortsdaten können Längen- und Breitengrade sein, Streckenkilometer für eine
Fahrt, Zellendaten aus mobilen Kommunikationsnetzen, in denen die fahrzeugseitige
Kommunikationseinrichtung betrieben wird, Tarifzonen oder andere Datensätze, deren
geografische Auflösung hinreichend fein ist, um das Tarifsystem für die Fahrgeldberechnung
abzubilden. Ortsdaten können somit bestimmt werden aus Globalen Navigationssatellitensystemen
(wie GPS, Galileo, etc.), aus Streckenzählern des Fahrzeugs, aus Funkbaken oder Balisen
entlang des Fahrwegs, aus Triangulationsdaten von mobilen Kommunikationsnetzen oder
jeder anderen geeigneten Methode zur Ortbestimmung.
[0018] Die Datenkommunikation zwischen der fahrzeugseitigen Kommunikationseinrichtung und
dem Zentralrechner kann dabei permanent aktiv sein oder zeitlich periodisch aktiviert
werden oder abhängig vom Ort des Fahrzeugs oder der Anzahl empfangener Datentelegramme
aktiviert werden. Die Datenkommunikation kann basieren auf einem digitalen Mobilfunknetz
(GSM, GPRS, UMTS, LTE), einer WLAN-Verbindung, einer Bluetooth-Kopplung, einer Infrarot-Ankopplung
oder jeder anderen geeigneten verdrahteten oder drahtlosen Datenverbindung. Verdrahtete
oder anderweitig lokale begrenzte Datenverbindungen können dabei selbstverständlich
nur dann aktiv sein, wenn das Fahrzeug sich im Bereich der Datenverbindung aufhält,
beispielweise auf einem Bushof, Bahnhof, an einem Schiffsanleger oder an Haltestellen,
die mit einer entsprechenden Datenverbindung ausgestattet sind.
[0019] Mobile Endgeräte im Sinne der Erfindung sind tragbare Einheiten mit wenigstens einem
digitalen Datenprozessor, einem digitalen Datenspeicher, einer Energieversorgung und
Kommunikationsmitteln. Mobile Endgeräte sind dazu eingerichtet, fahrzeugeigene und
fahrzeugfremde Datentelegramme drahtlos zu empfangen, die darin enthaltenen digitalen
Daten weiterzuverarbeiten und an den Zentralrechner weiterzuleiten. Mobile Endgeräte
können dezidiert für den Zweck des erfindungsgemäßen Verfahrens entworfen und hergestellt
sein oder es können, in einer bevorzugten Ausführungsform, massenmarkt-verfügbare
mobile Endgeräte sein wie Smartphones, Tablet-Computer, Spielkonsolen, Laptop-Computer,
Netbooks, Datenbrillen, Smart-Watches oder andere körpernah getragene Endgeräte, usw.
[0020] Die Datenkommunikation zwischen einem mobilen Endgerät und dem Zentralrechner kann
permanent aktiv sein oder zeitlich periodisch aktiviert werden oder abhängig vom Ort
des Endgeräts oder der Anzahl empfangener Datentelegramme aktiviert werden. Die Datenkommunikation
kann basieren auf einem digitalen Mobilfunknetz (GSM, GPRS, UMTS, LTE) oder auf einem
lokalen Datenfunknetz wie beispielsweise eine WLAN-, Bluetooth- oder Bluetooth Low
Energy (BLE) Verbindung (über eine fahrzeugseitige Relais-Station, die ihrerseits
mit dem Zentralrechner kommuniziert) oder auf jeder anderen geeigneten drahtlosen
Datenverbindung.
[0021] Das Weiterverarbeiten der empfangenen Daten durch den wenigstens einen Fahrzeugempfänger
und die mobilen Endgeräte kann im Sinne der Erfindung umfassen: Das Unverändertlassen
der Daten, das Ergänzen der Daten mit geräteeigenen oder weiteren vom Gerät erhaltenen
oder erzeugen Daten (z.B. Kenner des Geräts, Telefonnummer des Geräts, Uhrzeit, Ort,
Prüfsumme, Zählerstände), das Verschlüsseln der Daten, das Maskieren der Daten (sogenanntes
"hashen"), das Speichern der Daten oder das Anwenden anderer in der Informationstechnologie
üblicher Datenverarbeitungsmechanismen auf die Daten sowie jedwede Kombination solcher
Handhabungen.
[0022] Es können nun fahrzeugfremde Sender vorhanden sein, die fremde Datentelegramme aussenden.
Diese fahrzeugfremden Sender können im Fahrzeug selbst vorhanden sein, indem beispielweise
von täuschungswilligen Nutzern versucht wird, das BIBO-System zu stören oder zu sabotieren.
Die fahrzeugfremden Sender können aber auch außerhalb des Fahrzeugs vorhanden sein,
beispielsweise dadurch verursacht, dass zwei Busse, die mit dem erfindungsgemäßen
BIBO-System ausgestattet sind, nebeneinander an eine Ampel stehen oder auf zwei Fahrspuren
nebeneinander fahren. Verfahrenswesentlich ist, dass die fremden Datentelegramme in
gleicher Weise durch die mobilen Endgeräte und den wenigstens einen Fahrzeugempfänger
empfangbar sein können. Es kann dabei sein, dass die fremden Datentelegramme digitale
Fremddaten enthalten, die durch die mobilen Endgeräte und den wenigstens einen Fahrzeugempfänger
in gleicher Weise gehandhabt werden können, wie die digitalen Fahrzeugdaten. Wesentlich
für das erfindungsgemäße Verfahren ist jedenfalls, dass die mobilen Endgeräte auch
fremde Datentelegramme empfangen können und nicht "wissen" und auch nicht zu "wissen"
brauchen, dass diese Signal fahrzeugfremd sind, denn die mobilen Endgeräte "wissen"
nicht sicher, in welchem Fahrzeug sie sich befinden.
[0023] Erfindungsgemäß sendet in einem Fahrzeug wenigstens ein Fahrzeugsender wiederholt
Fahrzeugdatentelegramme aus. Diese Fahrzeugdatentelegramme werden durch den wenigstens
einen Fahrzeugempfänger wenigstens teilweise empfangen, d.h. wenigstens ein Fahrzeugempfänger
empfängt wenigsten ein vollständiges Fahrzeugdatentelegramm. Aus den empfangenen Fahrzeugdatentelegrammen
liest der Fahrzeugempfänger die darin enthaltenen digitalen Fahrzeugdaten aus. Die
digitalen Fahrzeugdaten aus den Fahrzeugdatentelegrammen enthalten eine Zeitangabe
(z.B. Datum und Uhrzeit) oder sie werden von dem Fahrzeugempfänger oder dem Bordrechner
mit einer aktuellen Zeitangabe ergänzt. Weiter ergänzt der Fahrzeugempfänger oder
der Bordrechner die Daten mit einer systemweit eineindeutigen Kennung des eigenen
Fahrzeugs und dem Ort des Fahrzeugs. Aus einem empfangenen Fahrzeugdatentelegramm
wird damit ein digitaler Fahrzeugreferenz-Datensatz erstellt; jeder Fahrzeugreferenz-Datensatz
repräsentiert also ein Datentelegramm, das im Fahrzeug empfangbar war. Der Fahrzeugempfänger
oder der Bordrechner leitet die digitalen Fahrzeugreferenz-Datensätze an die fahrzeugseitige
Kommunikationseinrichtung weiter. Dazu sind der Fahrzeugempfänger und die fahrzeugseitige
Kommunikationseinrichtung datentechnisch vernetzt. Diese Vernetzung nutzt bevorzugt
ein vorhandenes Bordnetz des Fahrzeugs und kann beispielweise eine verdrahtetes LAN,
ein Datenbus, ein CAN-Bus, ein WLAN oder jede andere geeignete verdrahtete oder drahtlose
Datenverbindung innerhalb des Fahrzeugs sein. Fahrzeugempfänger und/oder fahrzeugseitige
Kommunikationseinrichtung können jedoch auch Bestandteile des Bordrechners sein.
[0024] Ein "Fahrzeug" im Sinne der Erfindung kann auch ein Segment eines Transportmittels
sein, wie z.B. ein Waggon, welches über wenigsten einen Fahrzeugsender und wenigstens
einen Fahrzeugempfänger verfügt. Ein Zug aus mehreren Waggons ist damit mehrere "Fahrzeuge"
im Sinne der Erfindung.
[0025] Das Aussenden der Fahrzeugdatentelegramme durch den Fahrzeugsender erfolgt drahtlos
in einem Datenfunknetz, für welches auch die mobilen Endgeräte eingerichtet sind,
beispielweise: Bluetooth, Bluetooth Low Energy, WLAN, ANT, WiMax, WPAN, ZigBee oder
Z-Wave.
[0026] Die Häufigkeit, mit der der wenigstens eine Fahrzeugsender Fahrzeugdatentelegramme
aussendet, bestimmt die bei der Durchführung des erfindungsgemäßen Verfahrens anfallende
Datenmenge und damit auch die Netzwerklast in allen am Verfahren beteiligten Netzwerken.
Um die Netzwerklast zu reduzieren, kann dabei im erfindungsgemäßen Verfahren berücksichtigt
werden, dass mehr Datentelegramme nicht notwendigerweise zu einem besseren BIBO-Verfahren
führen (also zur besseren Ermittlung des Aufenthalts von Nutzern in einem Fahrzeug).
Dies ist insbesondere der Fall, wenn ohnehin niemand zu- oder aussteigen kann. Damit
kann für ein Fahrzeug in Fahrt der wenigstens eine Fahrzeugsender Datentelegramme
weniger häufig aussenden, während es in Situationen, in denen aktuell Passagiere zu-
oder aussteigen können oder gerade zu- oder ausgestiegen sein könnten, ein häufigeres
Aussenden von Fahrzeugdatentelegrammen besonders sinnvoll ist. Gleiches kann gelten,
wenn das Fahrzeug sich im Bereich einer Tarifzonengrenze befindet. Demnach kann das
wiederholte Aussenden von Fahrzeugdatentelegrammen durch den wenigstens einen Fahrzeugsender
im Sinne der Erfindung bedeuten: ein Aussenden mit gleichbleibenden Zeitintervallen
zwischen zwei Sendevorgängen, ein Aussenden mit variablem Zeitintervallen zwischen
zwei Sendevorgängen, ein Aussenden in Zeitintervallen, die abhängig sind von wenigstens
einem der folgenden beispielhaften Kriterien: Fahrtgeschwindigkeit, Aufenthaltsort
des Fahrzeugs innerhalb des Tarifgebiets eines Fahrgeldsystems, Erreichen oder Überschreiten
von Tarifzonengrenzen durch das Fahrzeug, Zustand der Fahrzeugtüren ("auf" oder "zu"
oder gerade geschlossen worden, wobei "gerade geschlossen" ein Zeit von wenigen Sekunden
nach Schließen der letzten Fahrzeugtür bedeutet, typischerweise bis zu 5 Sekunden)
sowie aus einer Kombination solcher und/oder anderer Kriterien.
[0027] Die fahrzeugseitige Kommunikationseinrichtung sendet die erhaltenen digitalen Fahrzeugreferenz-Datensätze
an den Zentralrechner. Dies kann erfolgen in Echtzeit, also unmittelbar nachdem die
fahrzeugseitige Kommunikationseinrichtung einen Fahrzeugreferenz-Datensatz von einem
der Fahrzeugempfänger erhalten hat, in Quasi-Echtzeit, worunter hier verstanden werden
soll, dass zwischen dem Empfangen eines Datentelegramms und dem Senden des Fahrzeugreferenz-Datensatzes
bis zu X Minuten Zeit verstreichen. Weiterhin kann das Senden eines Fahrzeugreferenz-Datensatzes
durch die fahrzeugseitige Kommunikationseinrichtung mit einem Zeitverzug erfolgen,
worunter hier verstanden werden soll, dass zwischen dem Empfangen eines Datentelegramms
und dem Senden des Fahrzeugreferenz-Datensatzes mehr als X Minuten Zeit verstreichen.
Die fahrzeugseitige Kommunikationseinrichtung kann die Fahrzeugreferenz-Datensätze
zwischenspeichern und somit eine Vielzahl von Fahrzeugreferenz-Datensätze an den Zentralrechner
gebündelt senden. Dies ist insbesondere dann der Fall, wenn die Datenverbindung zwischen
der fahrzeugseitigen Kommunikationseinrichtung und dem Zentralrechner nicht permanent
aktiv ist. Die Fahrzeugreferenz-Datensätze, die der Zentralrechner von der fahrzeugseitigen
Kommunikationseinrichtung empfängt, werden dort in wenigstens einer Datenbank gespeichert.
Der Zentralrechner empfängt dabei von einer Vielzahl von Fahrzeugen entsprechende
Fahrzeugreferenz-Datensätze.
[0028] Falls für den wenigstens einen Fahrzeugempfänger auch Datentelegramme von einem fahrzeugfremden
Sender empfangbar sind, so verarbeitet der Fahrzeugempfänger die empfangenen Fremddatentelegramme
in genau der gleichen Weise wie die empfangenen Fahrzeugdatentelegramme: Die digitalen
Fremddaten aus den Fremddatentelegrammen enthalten eine Zeitangabe (z.B. Datum und
Uhrzeit) oder sie werden von dem Fahrzeugempfänger oder dem Bordrechner mit einer
aktuellen Zeitangabe ergänzt. Weiter ergänzt der Fahrzeugempfänger oder der Bordrechner
die Daten mit der eindeutigen Kennung des eigenen Fahrzeugs und dem Ort des eigenen
Fahrzeugs. Aus einem empfangenen Fremddatentelegramm wird damit ein digitaler Fremddatensatz,
aber in jedem Fall versehen mit der Kennung des eigenen Fahrzeugs, also desjenigen
Fahrzeugs, in der der Fahrzeugempfänger installiert ist. Aus den empfangenen Fremddatentelegrammen
sind damit wiederum Fahrzeugreferenz-Datensätze erstellt worden, die wiederum in der
oben beschriebenen Weise an den Zentralrechner gesendet und dort in der wenigstens
einen Datenbank gespeichert werden.
[0029] Falls in einem Fahrzeug mehrere Fahrzeugempfänger vorhanden sind, so werden diese
fast immer identische Datentelegramme (fahrzeugeigene und fahrzeugfremde) empfangen.
Ausnahmen gehen dabei auf solche Datentelegramme zurück, die etwa für einen Fahrzeugempfänger
empfangbar waren, für einen anderen Fahrzeugempfänger im selben Fahrzeug aber nicht.
Eine Mehrzahl von Fahrzeugempfängern in einem Fahrzeug wird also eine große Zahl von
identischen Fahrzeugreferenz-Datensätze ("Doubletten") zum Weiterleiten an den Zentralrechner
generieren. Erfindungsgemäß wird daher vorgeschlagen, zur Reduktion des Datenvolumens
und der Netzwerklast die Datensätze aller in einem Fahrzeug installierten Fahrzeugempfänger
zunächst im Bordrechner des Fahrzeugs zu speichern, Doubletten zu löschen und die
dann verbleibenden Datensätze wie beschrieben an den Zentralrechner zu senden.
[0030] Wie oben beschrieben, sendet in einem Fahrzeug erfindungsgemäß wenigstens ein Fahrzeugsender
wiederholt Fahrzeugdatentelegramme aus. Diese Fahrzeugdatentelegramme werden durch
ein mobiles Endgerät eines Nutzers wenigstens teilweise empfangen, d.h. das mobile
Endgerät empfängt wenigsten ein vollständiges Fahrzeugdatentelegramm. Aus den empfangenen
Fahrzeugdatentelegrammen liest das mobile Endgerät die darin enthaltenen digitalen
Fahrzeugdaten aus. Die digitalen Fahrzeugdaten aus den Fahrzeugdatentelegrammen enthalten
eine Zeitangabe (z.B. Datum und Uhrzeit) oder sie werden vom mobilen Endgerät mit
einer aktuellen Zeitangabe ergänzt; weiter können die digitalen Fahrzeugdaten den
Fahrzeugort enthalten. Das mobile Endgerät ergänzt die Daten mit seiner systemweit
eineindeutigen Kennung. Aus den Daten eines empfangenen Fahrzeugdatentelegramms wird
damit ein digitaler Endgeräte-Datensatz erstellt.
[0031] Die systemweit eineindeutige Kennung des mobilen Endgeräts kann eine Mobilfunk-Telefonnummer
sein, eine Mobiltelefon-ID, eine IMEI-Nummer (International Mobile Station Equipment
Identity), eine MAC-Adresse (Media-Access-Control-Adresse, auch bekannt als Ethernet-ID,
Airport-ID oder WiFi-ID), eine Bluetooth MAC-Adresse, eine Nutzerkennung, unter der
ein Nutzer sein Nutzerkonto in dem Fahrgeldmanagementsystem führt, eine Nutzerkennung,
unter der ein Nutzer seine BIBO-App, mit der das erfindungsgemäße Verfahren durchgeführt
wird, registriert hat, eine Nutzer-Identifikation, unter der die BIBO-App erworben
wurde, oder jedwede andere systemweit eineindeutige Kennung, die es erlaubt, das mobile
Endgerät zu identifizieren.
[0032] In einer Ausführungsform des erfindungsgemäßen Verfahrens kann das mobile Endgerät
den digitalen Fahrzeugdatensatz mit eigenen Ortsdaten ergänzen, um die nachgelagerte
Fahrtrekonstruktion im Zentralrechner mit diesen Daten zu unterstützen. Diese Ergänzung
der digitalen Fahrzeugdatensätze kann das mobile Endgerät für jeden Datensatz vornehmen
oder nur für einen Teil der Datensätze, beispielsweise beim Einschalten der BIBO-App
oder beim Empfangen eines ersten Datentelegramms mit einer neuen Fahrzeugkennung oder
zeitlich periodisch, beispielsweise alle 5 Minuten, oder periodisch nach einer bestimmten
Anzahl empfangener Datentelegramme, beispielsweise bei jedem zehnten Datentelegramm.
Ortsdaten des mobilen Endgeräts können Längen- und Breitengrade sein oder Zellendaten
aus mobilen Kommunikationsnetzen, in denen das mobile Endgerät betrieben wird, oder
andere Ortsdaten, wie sie sich aus der Gerätausstattung des mobilen Endgeräts ermitteln
lassen. Ortsdaten können damit bestimmt werden aus Globalen Navigationssatellitensystemen
(wie GPS, Galileo, etc.), aus Triangulationsdaten von mobilen Kommunikationsnetzen,
aus Feldstärkedaten und/oder Accesspoints von mobilen Kommunikationsnetzen, aus Access-Points
oder SSID-Informationen von WLAN oder Bluetooth-Netzen oder jeder anderen im mobilen
Endgerät verfügbaren Methode zur Ortbestimmung.
[0033] Das mobile Endgerät sendet die Endgeräte-Datensätze an den Zentralrechner. Dies kann
erfolgen in Echtzeit, also unmittelbar nachdem das mobile Endgerät einen Datentelegramm
erhalten hat, in Quasi-Echtzeit, worunter hier verstanden werden soll, dass zwischen
dem Empfangen eines Datentelegramms und dem Senden des Endgeräte-Datensatzes bis zu
X Minuten Zeit verstreichen. Weiterhin kann das Senden eines Endgeräte-Datensatzes
durch das mobile Endgerät mit einem Zeitverzug erfolgen, worunter hier verstanden
werden soll, dass zwischen dem Empfangen eines Datentelegramms und dem Senden des
Endgeräte-Datensatzes mehr als X Minuten Zeit verstreichen. Das mobile Endgerät kann
die Endgeräte-Datensätze zwischenspeichern und somit eine Vielzahl von Endgeräte-Datensätzen
an den Zentralrechner gebündelt senden. Diese ist insbesondere dann der Fall, wenn
die Datenverbindung zwischen dem mobilen Endgerät und dem Zentralrechner nicht permanent
aktiv ist. Die Endgeräte-Datensätze, die der Zentralrechner von dem mobilen Endgerät
empfängt, werden dort in der wenigstens einen Datenbank gespeichert. Der Zentralrechner
empfängt dabei von einer Vielzahl mobiler Endgeräten entsprechende Endgeräte-Datensätze.
[0034] Falls für das mobile Endgerät auch Datentelegramme von einem fahrzeugfremden Sender
empfangbar sind, so verarbeitet das mobile Endgerät die empfangenen Fremddatentelegramme
in genau der gleichen Weise wie die empfangenen Fahrzeugdatentelegramme: Die digitalen
Fremddaten aus den Fremddatentelegrammen enthalten eine Zeitangabe (z.B. Datum und
Uhrzeit) oder sie werden vom mobilen Endgerät mit einer aktuellen Zeitangabe ergänzt.
Weiter ergänzt das mobile Endgerät die Daten mit seiner eineindeutigen Kennung. Aus
den empfangenen Fremddatentelegrammen werden damit digitale Endgeräte-Datensätze erstellt,
versehen mit der Kennung des mobilen Endgeräts, die wiederum in der oben beschriebenen
Weise an den Zentralrechner gesendet und dort in der wenigstens einen Datenbank gespeichert
werden.
[0035] In der Praxis werden ein mobiles Endgerät und ein Fahrzeugempfänger im selben Fahrzeug
nicht immer genau dieselben Datentelegramme empfangen; sie werden aber so viele identische
Datentelegramme empfangen, dass daraus im Zentralrechner (auf Basis der Endgeräte-Datensätze
und der Fahrzeugreferenz-Datensätze) sicher auf die Anwesenheit des mobilen Endgeräts
in dem Fahrzeug geschlossen werden kann.
[0036] Der Zentralrechner empfängt Fahrzeugreferenz-Datensätze von allen am Verfahren beteiligten
Fahrzeugen, sobald deren fahrzeugseitigen Kommunikationseinheiten Datensätze senden
und die Datensätze über das externe Fahrzeugdatennetz für den Zentralrechner empfangbar
sind. Weiter empfängt der Zentralrechner Endgeräte-Datensätze von allen am Verfahren
beteiligten mobilen Endgeräten, sobald diese mobilen Endgeräte Datensätze senden und
die Datensätze über das mobile Datennetz für den Zentralrechner empfangbar sind.
[0037] Im Zentralrechner wird nun für jedes mobile Endgerät bestimmt, in welchem Fahrzeug
es wann und wo gefahren ist. Die Verkettung von zeitlich aufeinanderfolgenden Aufenthaltsorten
eines mobilen Endgeräts in einem bewegten Fahrzeug stellt also eine Fahrt dar, die
abgerechnet werden kann. Das Abrechnen kann dabei zum Beispiel gegen ein am Zentralrechner
geführtes Fahrgeldkonto oder einen dort gespeicherten Dauerfahrschein erfolgen, oder
die Fahrt wird dem Nutzer in Rechnung gestellt. Details der eigentlichen Fahrgeldabrechnung
sind nicht Gegenstand der Erfindung.
[0038] Der Zentralrechner im Sinne des erfindungsgemäßen Verfahrens kann physisch aus einer
oder mehreren Rechnereinheiten (Servern) und Datenbanken bestehen, die an einem Ort
oder an mehreren geographischen Orten aufgestellt und datennetzwerkmäßig miteinander
verbunden sind. Der wenigstens eine geographische Ort des Zentralrechners ist verfahrensgemäß
nicht relevant; insbesondere können der Zentralrechner und seine wenigstens eine Datenbank
Bestandteil wenigstens eines Rechenzentrums sein. Insbesondere können der Zentralrechner
und seine wenigstens eine Datenbank als virtueller Server eingerichtet sein. Insbesondere
können der Zentralrechner und seine wenigstens eine Datenbank über Internetschnittstellen
adressierbar und als "cloud"-Implementierung eingerichtet sein.
[0039] Aus dem bisher beschriebenen Verfahren sind in der wenigstens einen Datenbank des
Zentralrechners nun folgende zwei Arten von Datensätzen gespeichert:
Endgeräte-Datensätze: Das sind diejenigen Datensätze, die von einem mobilen Endgerät
an den Zentralrechner weitergeleitet wurden. Diese Datensätze stammen aus den Datentelegrammen
derjenigen Fahrzeugsender, die das mobile Endgerät während einer Fahrt empfangen konnte.
Dies sind Datentelegramme des für die Fahrt benutzten Fahrzeugs, und solche Datentelegramme,
die von Fremdsendern stammen und die (zumindest zeitweise) für das Endgerät im benutzten
Fahrzeug empfangbar waren. Wie oben beschrieben, enthält jeder Endgeräte-Datensatz
wenigstens die Kennung des verwendeten mobilen Endgeräts, die Fahrzeugkennung aus
dem Datentelegramm und einen Zeitstempel. Jeder Endgeräte-Datensatz ist also genau
einem mobilen Endgerät zugeordnet und gibt an, welches Datentelegramm das Endgerät
zu einem bestimmten Zeitpunkt "gehört" hat.
Fahrzeugreferenz-Datensätze: Das sind diejenigen Datensätze, die von einem Fahrzeug
(über die fahrzeugseitige Kommunikationseinrichtung) an den Zentralrechner weitergeleitet
wurden. Diese Datensätze stammen aus den Datentelegrammen derjenigen Fahrzeugsender,
die der wenigstens eine Fahrzeugempfänger während seiner Fahrt empfangen konnte. Dies
sind Datentelegramme des Fahrzeugs selbst und solche Datentelegramme, die von Fremdsendern
stammen und (zumindest zeitweise) im Fahrzeug empfangbar waren. Wie oben beschrieben,
enthält jeder Fahrzeugreferenz-Datensatz wenigstens die Kennung des eigenen Fahrzeugs
und einen Zeitstempel. Weiter kann der Fahrzeugreferenz-Datensatz die Ortsdaten des
Fahrzeugs enthalten. Jeder Fahrzeugreferenz-Datensatz ist also genau einem Fahrzeug
zugeordnet und gibt an, welches Datentelegramm in dem Fahrzeug zu einem bestimmten
Zeitpunkt an einem bestimmten Ort "gehört" wurde, wobei der Ort auch im Zentralrechner
indirekt über die Fahrtroute und der Zeitinformation bestimmt werden kann
[0040] Es ist in der wenigstens einen Datenbank des Zentralrechners eine Vielzahl von Endgeräte-Datensätzen
vorhanden, die von einer Vielzahl von mobilen Endgeräten stammen. Weiter ist in der
wenigstens einen Datenbank des Zentralrechners eine Vielzahl von Fahrzeugreferenz-Datensätzen
vorhanden, die von einer Vielzahl von Fahrzeugen stammen.
[0041] Um für ein konkretes mobiles Endgerät eine Fahrt zu bilden, wird nun durch Vergleich
der zugehörigen Endgeräte-Datensätze mit allen verfügbaren Fahrzeugreferenz-Datensätzen
ein zeitliche Abfolge von Orten rekonstruiert, an denen sich das Endgerät mit größter
Wahrscheinlichkeit aufgehalten hat. Dafür wird zu jedem Endgeräte-Datensatz bestimmt,
ob es einen zeitgleichen Fahrzeugreferenz-Datensatz gibt und ob beide Datensätze von
dem gleichen empfangenen Datentelegramm stammen. Jede Übereinstimmung gibt dabei an,
dass ein Fahrzeugempfänger und das mobile Endgerät zur gleichen Zeit dasselbe Datentelegramm
"hören" konnten. Dabei ist es irrelevant, ob das fragliche Datentelegramm von dem
Fahrzeug selbst stammt oder fahrzeugfremd war.
[0042] Dieser Vergleich wird mit allen in der wenigstens einen Datenbank gespeicherten,
noch nicht einer Fahrt zugeordneten Endgeräte-Datensätzen des einen mobilen Endgeräts
durchführt und hat zum Resultat eine zeitliche Abfolge von identischen Datentelegrammen,
die ein Fahrzeugempfänger und das mobile Endgerät zur gleichen Zeit dasselbe Datentelegramm
"hören" konnten. Ab einer Vielzahl von Übereinstimmungen wird klar, dass das mobile
Endgerät in einem bestimmten Fahrzeug mitgefahren ist, und anhand der Zeitstempel
und der Abfolge von Fahrzeugorten (aus den Fahrzeugreferenz-Datensätzen) kann konkret
bestimmt werden, wann das mobile Endgerät von wo nach wo gefahren ist. Damit ist eine
konkrete Fahrt für das eine konkrete Endgerät rekonstruiert und kann abgerechnet werden.
Der Vergleich der Datensätze der Endgeräte und der Fahrzeugreferenzdatensätze kann
beispielsweise über Korrelations-, Regressions- und/oder Merkmalsanalysen /-vektoren
und entsprechenden Klassifikatoren wie Bayes-Klassifikator, Maximum-Likelihood-Methoden
und/oder über künstlich neuronale Netze erfolgen.
[0043] Diese Fahrtrekonstruktion wird für alle in der wenigstens einen Datenbank des Zentralrechners
gespeicherten, noch nicht einer Fahrt zugeordneten Endgeräte-Datensätze durchführt;
auf diese Weise werden für alle zum Zentralrechner hochgeladenen Endgeräte-Datensätze
nach und nach Fahrten rekonstruiert. Damit ist ein erheblicher Rechenaufwand verbunden,
der mindestens an zwei Stellen der Fahrtrekonstruktion wie folgt verringert werden
kann:
Zu jedem Endgeräte-Datensatz gehört ein Nutzer, ein Nutzerkonto und damit - zumindest
nach einer Zeit der Teilnahme am BIBO-Verfahren - eine Nutzerhistorie. Die Fahrtrekonstruktion
am Zentralrechner kann sich die Historie zunutze machen, indem die neu eingegangenen
Endgeräte-Datensätze eines Nutzers zunächst mit denjenigen neu eingegangene Fahrzeugreferenz-Datensätzen
verglichen werden, die zu Fahrtenstrecken gehören, die der Nutzer in der Vergangenheit
häufig genutzt hat. Dieser Ansatz wird für eine Vielzahl von regelmäßigen Nutzern
dazu führen, dass ihre aktuelle Fahrt mit weniger Aufwand rekonstruiert werden kann,
weil der Algorithmus zur Fahrtrekonstruktion "weiß", in welchen Fahrzeugreferenz-Datensätzen
er am wahrscheinlichsten erfolgreich sucht.
Wenn eine Fahrtrekonstruktion für ein mobiles Endgerät begonnen wurde und die ersten
Übereinstimmungen von Endgeräte-Datensätzen und Fahrzeugreferenz-Datensätzen gefunden
wurden, dann wird ein entsprechend optimierter Algorithmus für die verbleibenden Endgeräte-Datensätze
die passenden Fahrzeugreferenz-Datensätze zunächst bei dem wahrscheinlich benutzten
Fahrzeug suchen. Nachdem also eine Fahrtrekonstruktion begonnen wurde, kann die Suche
nach weiteren passenden Fahrzeugreferenz-Datensätzen sehr eingeschränkt werden; nach
einer Vielzahl von Übereinstimmungen mit großer Wahrscheinlichkeit sogar auf genau
ein Fahrzeug.
[0044] Die erfindungsgemäße Fahrtrekonstruktion am Zentralrechner für jedes benutzte mobile
Endgerät ist also in besonderer Weise "robust" und unempfindlich gegen mögliche fahrzeugfremde
Datentelegramme, die ein Endgerät potenziell empfängt, da über die Fahrzeugreferenz-Datensätze
dem Zentralrechner bekannt ist, welche - auch fahrzeugfremde - Datentelegramme zu
der rekonstruierten Fahrt gehören.
[0045] Sobald der Zentralrechner Endgeräte-Datensätze und Fahrzeugreferenz-Datensätze empfangen
hat, kann er mit der Fahrtrekonstruktion für das Endgerät beginnen durch einen Abgleich
der Datensätze. Wenn die Endgeräte-Datensätze und Fahrzeugreferenz-Datensätze in "Echtzeit"
- also während der Fahrt - an den Zentralrechner gesendet werden, dann kann dieser
den Aufenthalt des mobilen Endgeräts im Fahrzeug noch während der Fahrt feststellen
und eine Look-Up Table an das mobile Endgerät wenigstens einmal senden. Die Look-Up
Table kann Daten enthalten über die aktuelle Fahrt aus einem Rechnergestützten Betriebsleitsystem,
welches im Zentralrechner ausgeführt wird. Daraus kann die App auf dem mobilen Endgerät
aktuelle Fahrtinformationen extrahieren und dem Nutzer auf dem mobilen Endgerät zur
Anzeige bringen. Die Look-Up Table kann beispielsweise Daten enthalten zur Abfolge
der Haltepunkte bei der aktuellen Fahrt, die Namen der Haltepunkte, erwartetet Ankunftszeiten
des Fahrzeugs an den Haltepunkten, erreichbare Anschlussverbindungen, Wetterdaten,
Warndaten über Wetter oder Straßenzustände etc. Diese Daten sind dem Nutzer der App
als Fahrtinformationen anzeigbar.
[0046] Die Daten in der Look-Up Table können statisch sein (etwa aus dem Fahrplan) oder
dynamisch (auf dem aktuellen Betriebsdaten des Betriebsleitsystems) oder eine Kombination
statischer und dynamischer Daten. Die Look-Up Table kann an das mobile Endgerät einmal
während einer Fahrt gesendet werden oder mehrfach aktualisiert werden. Aktualisierungen
können durchgeführt werden durch das Senden einer vollständigen aktualisierten Look-Up
Table an das mobile Endgerät oder durch eine inkrementelle Aktualisierung von Teilen
der Look-Up Table. Insbesondere kann die Look-Up Table aktualisiert werden, wenn die
Fahrtrekonstruktion am Hintergrundsystem feststellt, dass das mobile Endgerät von
einem Fahrzeug in ein anderes umgestiegen ist.
[0047] Wie oben erläutert, enthalten Fahrzeugdatentelegramme in ihren digitalen Daten eine
systemweit eineindeutige Kennung des Fahrzeugs, dessen Fahrzeugsender die Telegramme
gesendet hat. In einer besonders bevorzugten Ausführungsform des erfindungsgemäßen
Verfahrens enthalten diese digitalen Daten einen Code. Dieser Code kann eine nummerische
Zahl sein, eine Buchstabenkombination, eine Mischung von Zahlen und Buchstaben oder
ein sonstwie für die Datenübertragung geeigneter Dateninhalt oder ein Kombination
von ASCII-Zeichen. Der Code kann aus einem Zufallszahlengenerator entstammen und zeitabhängig
(z.B. alle X Minuten) oder nach bestimmten Anzahl X von Datentelegrammen neu generiert
werden, ggf. für jedes Datentelegramm individuell. In einer Ausführungsform kann der
Code aus Zustandsdaten generiert werden, beispielsweise aus den aktuellen Ortsdaten
des Fahrzeugs, z.B. als Hash-Wert aus den Längen- und Breitengraden des Fahrzeugorts
oder aus der Fahrtstrecke. In einer weiteren Ausführungsform kann der Code aus einem
Datums/Zeitstempel generiert werden, z.B. als Hash-Wert daraus.
[0048] Dieser Code wird dazu genutzt, die Authentizität der von den mobilen Endgeräten und
dem wenigstens einen Fahrzeugempfänger empfangenen Fahrzeugdatentelegramme im Zentralrechner
zu überprüfen. Damit wird verhindert, dass etwa missbräuchlich in ein Fahrzeug eingebrachte
Sender gefälschte Datentelegramme aussenden, die ggf. vom Zentralrechner nicht als
solche erkannt werden.
[0049] Für den Fall, dass die Fahrzeugdatentelegramme die genannten Codes enthalten, werden
diese Codes mit den Endgeräte-Datensätzen und mit den Fahrzeugreferenz-Datensätzen
in der beschriebenen Weise an den Zentralrechner weitergeleitet.
[0050] Damit der Zentralrechner nun überprüfen kann, ob die in den Datensätzen erhaltenen
Codes aus einem authentisch im Fahrzeug installierten Fahrzeugsender stammen, gibt
es erfindungsgemäß zwei Möglichkeiten:
Der dem Fahrzeugdatentelegramm zugehörige Code wird im Fahrzeug (beispielweise im
Bordrechner) generiert, das Datentelegramm wird innerhalb des Fahrzeugs ausgestrahlt,
und die Daten des ausgesendeten Datentelegramms werden als zusätzlich Kontrolldatentelegramm
von der fahrzeugseitigen Kommunikationseinrichtung an den Zentralrechner gesendet.
Das Senden an den Zentralrechner kann dabei wie oben beschrieben in unterschiedlichem
Zeitverhalten erfolgen, von "Echtzeit" bis zum nachgelagerten Senden von gebündelten
Kontrolldatentelegrammen. Der Zentralrechner hat damit eine Mitschrift aller in einem
Fahrzeug authentisch ausgesendeten Datentelegramme und der zugehörigen Codes und kann
die Endgeräte-Datensätze und die Fahrzeugreferenz-Datensätze auf das Vorhandensein
des identischen Codes prüfen. Der Code kann dabei bei jedem Datentelegramm neu generiert
werden oder in bestimmten zeitlichen Abständen oder nach bestimmten gefahrenen Strecken
oder beim Erreichen von Tarifzonengrenzen oder nach dem Öffnen oder Schließen der
Fahrzeugtüren, etc. Auf diese Weise kann der Code zeitlich, örtlich, in Abhängigkeit
von bestimmten Ereignissen oder mit jedem neuen Datentelegramm variiert werden.
Der dem Fahrzeugdatentelegramm zugehörige Code wird im Zentralrechner generiert und
wird dem Bordrechner des Fahrzeugs zur Verfügung gestellt, beispielweise als Liste
von Codes sortiert nach Gültigkeitsdatum und Uhrzeit, so dass der Code zeitabhängig
variiert wird. Beim Generieren eines Fahrzeugdatentelegramms fügt der Bordrechner
dem Fahrzeugdatentelegramm den aktuell gültigen Code zu, entnommen gemäß Datum und
Uhrzeit aus der Liste von Codes. Diese Variante hat den Vorteil, dass sie ohne Kontrolldatentelegramme
auskommt und dass das Datenvolumen, das von der fahrzeugseitigen Kommunikationseinrichtung
an den Zentralrechner gesendet werden muss, somit geringer wird. Weiterer Vorteil
dieser Variante ist, dass der Zentralrechner die Codes bereits kennt und damit die
Authentizität der erhaltenen Endgeräte-Datensätze besonders sicher prüfen kann. Die
Liste von Codes kann dem Bordrechner des Fahrzeugs dann zur Verfügung gestellt werden,
wenn die Datenkommunikation zwischen der fahrzeugseitigen Kommunikationseinrichtung
aktiviert ist. Insbesondere kann die Liste von Codes für eine Gültigkeitszeit von
wenigstens einem Arbeitstag des Fahrzeugs zur Verfügung gestellt werden.
[0051] Der Zentralrechner prüft jedenfalls die erhaltenen Endgeräte-Datensätze und Fahrzeugreferenz-Datensätze
auf das Vorhandensein des korrekten Codes, und die positiv überprüften Datensätze
werden als authentisch angesehen und für die oben beschriebene Fahrtrekonstruktion
herangezogen. Negativ geprüfte Datensätze werden für die Fahrtrekonstruktion vernachlässigt.
[0052] Weiter möglich ist das Auswerten der Anzahl negativ geprüfter Datensätze, wobei ein
gehäuftes Auftreten ein Hinweis darauf ist, dass das BIBO-System missbräuchlichen
Angriffen ausgesetzt sein kann.
[0053] Die erfindungsgemäße Authentizitätsprüfung wird besonders sicher, wenn die Codes
häufig gewechselt werden. Die Authentizitätsprüfung basiert dann nicht auf der Übereinstimmung
eines oder weniger Codes in mehreren Endgeräte- und Fahrzeugreferenz-Datensätzen,
sondern auf einer Folge von häufig variierten Codes, so dass auch mit relativ kurzen
Codes eine gute Verfahrenssicherheit erreicht wird.
[0054] In einer bevorzugten Ausführungsform werden für das erfindungsgemäße Verfahren als
Fahrzeugsender Bluetooth-Sender verwendet, die in eine besonders bevorzugte Ausführungsform
als sogenannte Bluetooth Low Energie Beacons ("BLE-Beacons") eingerichtet sind. BLE-Beacons
haben den Vorteil, dass sie preiswert und massenmarktverfügbar sind. Damit geht andererseits
der Nachteil einher, dass BLE-Beacons durch Dritte in missbräuchlicher Weise in ein
Fahrzeug eingebracht sein können und nichtauthentische Datentelegramme aussenden können.
Diesem Nachteil wird in der oben beschriebenen Weise durch einen Code in den Dateninhalten
der Datentelegramme begegnet.
[0055] BLE-Beacons können unterschieden werden in zwei Typen: erste BLE-Beacons, deren Datentelegramme
für ein mobiles Endgerät mit marktüblichem Betriebssystem in allen Betriebsmodi empfangbar
sind, und zweite BLE-Beacons, für die ein mobiles Endgerät zunächst konfiguriert werden
muss, damit es von ihnen Datentelegramme empfangen kann. Als marktübliche Betriebssysteme
werden hierbei im Sinne der Erfindung wenigstens verstanden: Apple iOS, Google Android,
Microsoft Windows Mobile, Microsoft Mobile Phone, Blackberry OS, Symbian OS, Firefox
OS, Tizen, Aliyun OS und ihre jeweiligen Nachfolger und Fortentwicklungen. Das Empfangen
von Datentelegrammen, die im drahtlosen Bluetooth-Netz gesendet werden, setzt dabei
selbstverständlich voraus, dass die Bluetooth-Funktion am jeweiligen mobilen Endgerät
eingeschaltet (aktiviert) ist.
[0056] In der Ausführungsform mit BLE-Beacons als Fahrzeugsender werden beide Typen der
BLE Beacons verwendet:
Wenigstens ein erstes BLE-Beacon sendet als erster Fahrzeugsender wiederholt über
das BLE-Datenprotokoll erste Fahrzeugdatentelegramme aus, welche von mobilen Endgeräten
der Nutzer in allen Betriebsmodi empfangbar sind, insbesondere auch dann, wenn auf
dem Endgerät eine vorinstallierte App zur Durchführung des BIBO-Verfahren nicht gestartet
ist. Insbesondere kann der wenigstens eine erste Fahrzeugsender ein iBeacon sein.
Die digitalen Daten des ersten Fahrzeugdatentelegramms enthalten die Art der Kommunikationsanwendung
(hier: die Aufenthaltsermittlung eines mobilen Endgeräts in einem Fahrzeug), ggf.
eine Kennung für den Betreiber des Fahrzeugs und ggf. eine Fahrzeugkennung. Das wiederholte
Aussenden der ersten Fahrzeugdatentelegramme durch das wenigstens eine erste BLE-Beacon
kann im Sinne der Erfindung bedeuten: ein Aussenden mit gleichbleibenden Zeitintervallen
zwischen zwei Sendevorgängen, ein Aussenden mit variablem Zeitintervallen zwischen
zwei Sendevorgängen, ein Aussenden in Zeitintervallen, die abhängig sind von wenigstens
einem der folgenden Kriterien: Fahrtgeschwindigkeit, Aufenthaltsort des Fahrzeugs
innerhalb des Tarifgebiets eines Fahrgeldsystems, Erreichen oder Überschreiten von
Tarifzonengrenzen durch das Fahrzeug, Zustand der Fahrzeugtüren (auf oder zu oder
gerade geschlossen worden) sowie aus einer Kombination solcher Kriterien.
[0057] Da die variablen Daten in einem BLE-Funkdatensignal sehr begrenzt sind, wird vorgeschlagen,
dass die Daten des wenigstens einen ersten Beacons in zwei verschiedenen Weisen für
das erfindungsgemäße Verfahren verwertbar sind:
Erstens enthalten die Daten des wenigstens einen ersten Beacons Daten zur Fahrterfassung,
wie zum Beispiel die Betreibernummer (einen systemgemäßen Kenner für die Verkehrsgesellschaft),
die Fahrzeugnummer, einen Verweis auf die Look-Up Table, die Fahrtnummer (z.B. Buslinie,
Zugnummer, etc), Fahrtrichtung, die Nummer des nächsten Haltepunktes oder jedwede
andere Art von Daten oder Kombination von Daten, die für die sichere Durchführung
des erfindungsgemäßen Verfahrens genutzt werden können und die im Rahmen der verfügbaren
Datenmenge im BLE-Funkdatensignal darstellbar sind.
[0058] Zweitens identifizieren die Daten des wenigstens einen ersten Beacons eine UUID des
zweiten Fahrzeugsenders, welcher ebenfalls als BLE-Beacon ausgeführt ist. Beispielsweise
kann die UUID des zweiten Fahrzeugsenders gebildet werden als eine Funktion eines
Hashwerts der variablen Daten des ersten Fahrzeugdatentelegramms. Nach Empfang wenigstens
eines ersten Datentelegramms wird eine App auf einem mobilen Endgeräte gestartet und
weiß, nach welchen UUIDs sie scannen muss, um zweite Datentelegramme zu empfangen.
[0059] Wenigstens ein zweites BLE-Beacon sendet als zweiter Fahrzeugsender wiederholt über
das BLE-Datenprotokoll zweite Fahrzeugdatentelegramme, welche für mobile Endgeräte
dann empfangbar sind, wenn sie zuvor wenigstens ein zugehöriges erstes Fahrzeugdatentelegramm
empfangen haben.
[0060] Die zweiten Fahrzeugdatentelegramme enthalten wenigstens einen Code. Dieser Code
kann eine nummerische Zahl sein, eine Buchstabenkombination, eine Mischung von Zahlen
und Buchstaben oder ein sonstwie für die Datenübertragung geeigneter Code oder ein
Kombination von ASCII-Zeichen. Der Code kann aus einem Zufallszahlengenerator entstammen
und zeitabhängig (z.B. alle X Minuten) oder nach bestimmten Anzahl X von Datentelegrammen
neu generiert werden, ggf. für jedes Datentelegramm individuell. In einer Ausführungsform
kann der Code aus Zustandsdaten generiert werden, beispielsweise aus den aktuellen
Ortsdaten des Fahrzeugs, z.B. als Hash-Wert aus den Längen- und Breitengraden des
Fahrzeugorts oder aus der Fahrtstrecke. In einer weiteren Ausführungsform kann der
Code aus einem Datums/Zeitstempel generiert werden, z.B. als Hash-Wert daraus. Weiter
können die zweiten Fahrzeugdatentelegramme Daten über zurückgelegte Fahrtstrecke des
Fahrzeugs enthalten, wie z.B. einen Fahrwegzähler. Bei Überschreiten des maximalen
Zählerwertes wird der Zähler beim Wert 0 wieder gestartet. Erfindungsgemäß können
die zweiten Fahrzeugdatentelegramme jedwede Kombination von Daten enthalten, die für
die sichere Durchführung des erfindungsgemäßen Verfahrens genutzt werden können und
die im Rahmen der verfügbaren Datenmenge im BLE-Funkdatensignal darstellbar sind.
[0061] Auch für ein BIBO-Verfahren, das auf BLE-Beacons basiert, ist es damit insbesondere
möglich, eine Authentisierung der Fahrzeugdatentelegramme mittels Codes in der oben
beschriebenen Weise durchzuführen.
[0062] Zur Durchführung des Verfahrens sind beide Fahrzeugsender (also beide BLE-Beacons)
mit dem Bordrechner des Fahrzeugs verbunden, welcher die Änderung der Dateninhalte
für beide das erste und das zweite Fahrzeugdatentelegramm durchführt und die UUID
des zweiten Fahrzeugsenders dynamisch so konfiguriert, dass sie von einer verfahrensgemäßen
App aus den ersten Fahrzeugdatentelegrammen entnommen werden kann.
[0063] Es ist dabei möglich, dass die App auch fahrzeugfremde erste Datentelegramme empfängt
und in der Folge nach fahrzeugfremden zweiten Datentelegrammen sucht.
[0064] Die App des mobilen Endgeräts schreibt eine Log-Datei, in der die Sequenz der extrahierten
Daten aus den empfangenen Datentelegrammen, versehen mit einem Zeitstempel, protokolliert
wird. Die App des mobilen Endgeräts leitet diese Daten aus der Log-Datei (fahrzeugeigene
wie fahrzeugfremde Daten) als Endgeräte-Datensätze in der oben beschrieben Weise an
den Zentralrechner weiter.
[0065] In gleicher Weise kann ein im Fahrzeug installierter Fahrzeugempfänger die Daten
aus empfangenden ersten und zweiten Fahrzeugdatendiagrammen extrahieren, mit Zeitstempel
protokollieren und als Fahrzeugreferenz-Datensätze wie oben beschrieben an den Zentralrechner
weitergeben.
[0066] Zur Sicherung des Verfahrens wird erfindungsgemäß weiter vorgeschlagen, dass die
Daten des wenigstens einen ersten Beacons verfahrensgemäß in jedem Fall variiert werden.
Wäre dies nicht der Fall, so könnte ein Angriff auf das System gestartet werden, indem
ein Täter den (in diesem Fall konstanten) Dateninhalt eines ersten Beacons abhört
und ein erfindungsgemäßes System mit gefälschten Beacons nachbaut und - beispielweise
- Fahrten unter einer falschen Betreibernummer generiert. Wenn die Daten des wenigstens
einen ersten Beacons variiert werden, so wird die logische Verknüpfung zwischen erstem
und zweiten Beacon immer neu hergestellt (koordiniert durch den Bordrechner). Die
Daten des wenigstens einen ersten Beacons enthalten - wie oben erwähnt - Daten zur
Fahrterfassung, wie zum Beispiel die Betreibernummer (einen systemgemäßen Kenner für
die Verkehrsgesellschaft), die Fahrzeugnummer, einen Verweis auf die Look-Up Table,
die Fahrtnummer (z.B. Buslinie, Zugnummer, etc), Fahrtrichtung, die Nummer der nächsten
Haltepunktes. Im ungünstigen Fall sind diese Daten statisch, z.B. nur die Betreibernummer
und die Fahrzeugnummer, weil bespielweise die Fahrzeuginfrastruktur keine dynamischen
Fahrtdaten liefert. Für diesen Fall wird vorgeschlagen, die Daten des wenigstens einen
ersten Beacons zu variieren, z.B. mit einer zeitlich variablen Zufallszahl oder dem
Hash eines Datums/Zeitstempels o.ä.
[0067] Mit der Erfindung werden ein Verfahren und ein System bereitgestellt, mit welchem
die Anwesenheit eines Endgerätes und damit des mit dem Endgerät ausgestatteten Nutzers
in einem Fahrzeug automatisch ermittelt werden kann. Es kann somit auf einfache Weise
automatisch die Nutzung des Verkehrsmittels in Bezug auf das Mobilfunkendgerät und
seinen Nutzer festgestellt und daraufhin die erforderliche Bearbeitung zur Farbpreisberechnung
und dergleichen durchgeführt werden. Weitere Vorteile und Merkmale der Beschreibung
ergeben sich aus der folgenden Beschreibung anhand der Figuren.
[0068] Im Folgenden zeigen die Figuren
- Fig 1:
- ein Ausführungsbeispiel, bei dem zwei Fahrzeugsender als BLE-Beacons in einem Bus
ausgeführt sind
- Fig 2:
- den Aufbau eines ersten und eines zweiten Fahrzeugdatentelegramms für das Ausführungsbeispiel
- Fig 3:
- den beispielhaften Empfang einer Sequenz von neun Fahrzeugdatentelegrammen durch ein
mobiles Endgerät und durch den Fahrzeugempfänger für das Ausführungsbeispiel
- Fig 4:
- den beispielhaften Dateninhalt von fünf Endgeräte-Datensätzen für das Ausführungsbeispiel
- Fig 5:
- den beispielhaften Dateninhalt von fünf Fahrzeugreferenz-Datensätzen für das Ausführungsbeispiel.
[0069] Die folgenden Ausführungen sind beispielhaft und nicht beschränkend.
[0070] In
Figur 1 ist ein Beispiel für ein System 100 gegeben, in welchem das erfindungsgemäße Verfahren
angewandt wird. Das Beispiel beschreibt die Ausführungsform mit BLE-Beacons.
[0071] In einem Bus 101 mit der Fahrzeugnummer "4711" sind installiert: ein erster Fahrzeugsender
102, ein zweiter Fahrzeugsender 103 und ein Fahrzeugempfänger 104. Die beiden Fahrzeugsender
102, 103 sind jeweils als BLE-Beacons ausgeführt; der Fahrzeugempfänger 104 ist eingerichtet,
Funksignale von beiden Fahrzeugsendern zu empfangen.
[0072] Insbesondere ist der erste Fahrzeugsender 102 als sogenanntes iBeacon ausgeführt,
dessen Funksignale für ein mobiles Endgerät mit dem iOS-Betriebssystem standardmäßig
und ohne besondere Konfiguration empfangbar sind, sobald an dem Endgerät das Bluetooth-Netzwerk
eingeschaltet ist. D.h. das mobile Endgerät befindet sich im sogenannten "Monitoring"-Betrieb
für iBeacons, wenn sein Bluetooth-Netzwerk eingeschaltet ist.
[0073] Der zweite Fahrzeugsender 103 ist ein sogenanntes Travelbeacon, dessen Funksignale
für ein mobiles Endgerät nur dann empfangbar sind, wenn das Endgerät entsprechend
konfiguriert wurde.
[0074] Die beiden Fahrzeugsender 102, 103 und der Fahrzeugempfänger 104 sind datennetzwerkmäßig
verbunden mit einem Bordrechner 105, welcher seinerseits mit einer fahrzeugseitigen
Kommunikationseinheit 106 datennetzwerkmäßig verbunden ist.
[0075] Weiter ist der Bordrechner 105 datennetzwerkmäßig verbunden mit einem GPS-Empfänger
107, so dass im Bordrechner 105 der aktuelle Ort des Busses 101 als Ortsdaten (Längen-
und Breitengrad) bekannt ist.
[0076] Die fahrzeugseitige Kommunikationseinheit 106 ist mit einem Zentralrechner 109 über
ein externes Fahrzeugdatennetz 108 datennetzwerkmäßig verbunden, in diesem Beispiel
über ein digitales Mobilfunknetz.
[0077] Im Fahrzeug befinden sich mobile Endgeräte 110 von Nutzern, deren Fahrt zu erfassen
und später abzurechnen ist. Die mobilen Endgeräte 110 sind über ein mobiles Datennetz
111 datennetzwerkmäßig verbunden mit dem Zentralrechner 109. Das mobile Datennetz
111 kann dabei dasselbe Datennetz sein wie das externe Fahrzeugdatennetz 108.
[0078] Für das vorliegende Beispiel wird angenommen, dass die mobilen Endgeräte 110 mit
dem Betriebssystem iOS betrieben werden.
[0079] Der erste Fahrzeugsender 102 sendet periodisch ein erstes Fahrzeugdatentelegramm
301.1, und zwar als iBeacon-Funksignal (der Inhalt dieses ersten Fahrzeugdatentelegramms
ist in Fig. 2 erläutert). Ein mobiles Endgerät 110 empfängt wenigstens ein erstes
Fahrzeugdatentelegramm und startet eine vorinstallierte App zur Teilnahme am automatisierten
BIBO-Verfahren.
[0080] Nach dem Empfang des ersten Fahrzeugdatentelegramms 301.1 ist das mobile Endgerät
110 konfiguriert, nach zweiten Fahrzeugdatentelegrammen zu suchen, und zwar dergestalt,
dass die App auf dem mobilen Endgerät kontinuierlich nach zweiten Fahrzeugdatentelegrammen
scannt.
[0081] Der zweite Fahrzeugsender 103 sendet periodisch ein zweites Fahrzeugdatentelegramm
302.1 (der Inhalt dieses zweiten Fahrzeugdatentelegramms ist in Fig. 2 erläutert).
Ein mobiles Endgerät 110 empfängt dieses zweite Fahrzeugdatentelegramm 302.1 und weitere
der periodisch ausgesendeten zweiten Fahrzeugdatentelegramme 302.1.
[0082] Gleichzeitig "monitort" das mobile Endgerät weiterhin nach periodisch ausgesendeten
ersten Fahrzeugdatentelegramm 301.1, also nach iBeacon-Funksignalen, und empfängt
auch diese.
[0083] Es befindet sich nun ein weiterer Bus 201 mit der Nummer "0815" in der Nähe des Busses
101, so dass auch erfindungsgemäße Datentelegramme aus diesem weiteren Bus 201 im
Bus 101 empfangbar sind. Dies kann in der Praxis vorkommen beim Befahren von parallelen
Fahrspuren, vor Ampeln, an Bushöfen, an Haltestellen, etc. Der weitere Bus 201 verfügt
in gleicher Weise über einen ersten Fahrzeugsender 202 und einen zweiten Fahrzeugsender
203. Diese senden in gleicher Weise periodisch Fahrzeugdatentelegramme, welche für
die Fahrterfassung in Bus 101 "fahrzeugfremd" sind. Diese Fremddatentelegramme 301.2,
302.2 werden vom mobilen Endgerät in genau dergleichen Weise empfangen, wie die Fahrzeugdatetelegramme
301.1, 302.1.
[0084] Die App des mobilen Endgeräts 110 extrahiert Daten aus den empfangenen Fahrzeugdatentelegrammen
301.1, 302.1 und den Fremddatentelegrammen 301.2, 302.2. Aus den extrahierten Daten
schreibt die App eine erste Log-Datei, in der die Sequenz der digitalen Daten aus
den empfangenen Datentelegrammen 301.1, 302.1, 301.2, 302.2 protokolliert wird. Die
App des Endgeräts 110 leitet diese Daten aus der ersten Log-Datei (fahrzeugeigene
wie fahrzeugfremde Daten) als Endgeräte-Datensätze 400 über das mobile Datennetz 111
an den Zentralrechner 109 weiter. Die App tut dies, sobald 100 Datentelegramme 302.1,
302.2 des zweiten Fahrzeugsenders 103, 203 empfangen wurden, spätestens jedoch alle
zehn Minuten. Dabei sendet die App nur solche Endgeräte-Datensätze 400 an den Zentralrechner
109, die bisher noch nicht gesendet wurden. Dazu wird in der ersten Log-Datei jeder
an den Zentralrechner 109 gesendete Datensatz mit einem Kenner markiert, damit er
kein zweites Mal gesendet wird. (Der Inhalt der Endgeräte-Datensätze 400 wird in Fig.
4 erläutert).
[0085] In gleicher Weise wie das mobile Endgerät, empfängt auch der Fahrzeugempfänger 104
die Fahrzeugdatentelegramme 301.1, 302.1 und Fremddatentelegramme 301.2, 302.2. Er
extrahiert Daten aus den empfangenen Datentelegrammen und leitet diese an den Bordrechner
105 weiter. Der Bordrechner 105 schreibt mit diesen Daten eine zweite Log-Datei, in
der die Sequenz der digitalen Daten aus den empfangenen Datentelegrammen 301.1, 302.1,
301.2, 302.2 protokolliert wird. Die zweite Log-Datei wird im Bordrechner 105 abgelegt
und verwaltet. Der Bordrechner 105 versieht jeden Eintrag in der zweiten Log-Datei
mit dem aktuellen Ort des Fahrzeugs, der über einen GPS-Empfänger 107 ermittelt wird.
Der Bordrechner veranlasst die fahrzeugseitige Kommunikationseinheit 106, diese Daten
aus der zweiten Log-Datei (fahrzeugeigene wie fahrzeugfremde Daten) als Fahrzeugreferenz-Datensätze
500 über das externe Fahrzeugdatennetz 108 an den Zentralrechner 109 weiter zu leiten.
Der Bordrechner 105 tut dies, sobald 100 Datentelegramme 302.1, 302.2 des zweiten
Fahrzeugsenders 103, 203 empfangen wurden, spätestens jedoch alle zehn Minuten. Dabei
sendet der Bordrechner 105 nur die Dateninhalte solcher Datentelegramme an den Zentralrechner
109, die bisher noch nicht gesendet wurden. Dazu wird in der zweiten Log-Datei jeder
an den Zentralrechner 109 gesendete Datensatz mit einem Kenner markiert, damit er
kein zweites Mal gesendet wird. (Der Inhalt der Fahrzeugreferenz-Datensätze 500 wird
in Fig. 5 erläutert).
[0086] Sobald der Zentralrechner 109 Endgeräte-Datensätze 400 und Fahrzeugreferenz-Datensätze
500 empfangen hat, beginnt er mit der Fahrtrekonstruktion für das Endgerät 110 durch
einen Abgleich der Datensätze 400, 500. Die Endgeräte-Datensätze 400 und Fahrzeugreferenz-Datensätze
500 werden in Echtzeit an den Zentralrechner 109 gesendet, so dass dieser den Aufenthalt
des Endgeräts 110 in Bus 101 noch während der Fahrt feststellt und eine Look-Up Table
600 an das mobile Endgerät 110 sendet. Die Look-Up Table enthält Daten über die aktuelle
Fahrt aus einem Rechnergestützten Betriebsleitsystem, welches im Zentralrechner 109
ausgeführt wird. Daraus extrahiert die App auf dem mobilen Endgerät Fahrtinformationen
und bringt sie dem Nutzer auf dem mobilen Endgerät zur Anzeige.
[0087] Figur 2 beschreibt den Aufbau eines ersten und eines zweiten Fahrzeugdatentelegramms für
das Ausführungsbeispiel.
[0088] Im Ausführungsbeispiel stammt das erste Fahrzeugdatentelegramm 301 von einem iBeacon.
Es ist damit empfangbar für mobile Endgeräte mit dem Betriebssystem iOS, ohne dass
diese hierfür besonders konfiguriert sein müssen; lediglich muss an dem jeweiligen
Endgerät das Bluetooth-Funknetz aktiviert sein.
[0089] Das erste Fahrzeugdatentelegramm 301 enthält eine UUID 303 gemäß dem iBeacon-Standard
(16 Byte Datenlänge) und sogenannte Major- und Minor-Daten 304 gemäß dem iBeacon-Standard
(4 Byte Datenlänge). Die UUID-Daten 303 sind so gewählt, dass ein mobiles Endgerät
erste Fahrzeugdatentelegramme 301 als von einem iBeacon stammend erkennt, d.h. sie
entsprechen dem iBeacon-Standard. Die Major- und Minor-Daten 304 sind frei konfigurierbar,
und das iBeacon erhält diese Daten durch eine datennetzwerkmäßige Verbindung vom Bordrechner
des Busses.
[0090] Die Major- und Minor-Daten 304 erfüllen zwei Zwecke:
Erstens enthalten sie Daten zur Fahrterfassung für den Bus, in dem Ausführungsbeispiel
die Betreibernummer (einen systemgemäßen Kenner für die Verkehrsgesellschaft), die
Busnummer und eine Zufallszahl, die vom Busrechner alle 5 Minuten geändert wird. Die
App auf dem mobilen Endgerät extrahiert diese Daten; sie werden ein Teil der Daten,
die die App in die erste Log-Datei schreibt.
[0091] Zweitens identifizieren die Major- und Minor-Daten 304 die ServiceUUID 305 des zweiten
Fahrzeugsenders. Im Beispiel wird die ServiceUUID 305 des zweiten Fahrzeugsenders
gebildet als eine Funktion eines Hashwerts aus den Major- und Minor-Daten 304. Nach
Empfang wenigstens eines ersten Datentelegramms 301 weiß die App, nach welchen ServiceUUIDs
305 sie scannen muss, um zweite Datentelegramme 302 zu empfangen.
[0092] Der Bordrechner, der für den ersten Fahrzeugsender (das iBeacon) die Major- und Minor-Daten
304 generiert, konfiguriert über eine datennetzwerkmäßige Verbindung auch den zweiten
Fahrzeugsender (das Travelbeacon), nach dessen zweiten Datentelegrammen 302 die App
sucht.
[0093] Das zweite Fahrzeugdatentelegramm 302 enthält eine ServiceUUID 305, die gemäß der
Funktion des Hashwerts aus den Major- und Minor-Daten 304 gebildet ist; die zweiten
Fahrzeugdatentelegramme 302 sind gemäß dem zuvor Gesagten damit für die App auffindbar
und empfangbar. Die zweiten Fahrzeugdatentelegramme 302 enthalten als Nutzdaten für
die Fahrterkennung ein GeoLog 306 von 4 Bytes Länge und einen RunCounter von 2 Bytes
Länge. Das GeoLog 306 wird dabei im Ausführungsbeispiel gebildet aus einem Hashwert
des aktuellen Orts des Fahrzeugs. Das GeoLog 306 stellt den im Fahrzeugdatentelegramm
enthaltenen Code im Sinne der obigen Beschreibung dar; im Ausführungsbeispiel ist
der Code also ortsabhängig. Der RunCounter 307 bildet im Ausführungsbeispiel den Fahrweg
des Busses in Vielfachen von 100 Metern ab. Bei Überschreiten des maximalen Zählerwertes
wird der RunCounter beim Wert 0 wieder gestartet. Die App auf dem mobilen Endgerät
extrahiert auch diese Daten; sie werden ebenfalls ein Teil der Daten, die die App
in die erste Log-Datei schreibt.
[0094] In der gleichen Weise wie die App auf dem mobilen Endgerät empfängt auch der Fahrzeugempfänger
erste und zweite Datentelegramme 301, 302. Er extrahiert ebenfalls aus den Major-
und Minor-Werten 304, aus dem GeoLog 306 und aus dem RunCounter 307 Daten zur Fahrterfassung;
diese werden ein Teil der Daten, die der Bordrechner in die zweite Log-Datei schreibt.
[0095] Figur 3 beschreibt den beispielhaften Empfang einer Sequenz von 9 Fahrzeugdatentelegrammen
durch ein mobiles Endgerät und durch den Fahrzeugempfänger. Das mobile Endgerät befindet
sich in Bus "4711"; der Fahrzeugempfänger ist derjenige des Busses "4711". Im Beispiel
der Fig. 3 befindet sich zeitweilig ein weiterer Bus "0815" in der Nähe, so dass dessen
Datentelegramme auch im Bus "4711" zeitweise empfangen werden.
[0096] In Fig. 3 empfängt das mobile Endgerät zunächst ein erstes Datentelegramm 301.1 vom
iBeacon des Busses "4711". Es scannt nun nach zugehörigen Travelbeacons und empfängt
zwei zweite Datentelegramme 302.1 des Busses "4711". (Datentelegramme # 1 - 3 aus
Figur 3).
[0097] Der Bordrechner des Busses wechselt die Zufallszahl in den Major- und Minorwerten
des iBeacons und die zugehörige ServiceUUID des Travelbeacons. Die Datentelegramme
des iBeacons ändern sich. Das mobile Endgerät empfängt ein solches geändertes erstes
Datentelegramm 301.1 und danach zwei weitere zweite Datentelegramme 302.1. (Datentelegramme
# 4 - 6 aus Figur 3)
[0098] Bus "0815" kommt in die Nähe des benutzten Busses "4711", und seine Datentelegramme
werden in Bus "4711" empfangbar. Das mobile Endgerät empfängt ein erstes Datentelegramm
301.2 vom iBeacon des Busses "0815". Es scannt nun nach zugehörigen Travelbeacons
und empfängt ein zweites Datentelegramm 302.2 des Busses "0815". (Datentelegramme
# 7 - 8 aus Figur 3).
[0099] Das mobile Endgerät empfängt wieder ein erstes Datentelegramm 301.1 vom iBeacon des
Busses "4711". Es scannt nun wieder nach zugehörigen Travelbeacons aus Bus "4711".
(Datentelegramm # 9 aus Figur 3).
[0100] Das heißt, gemäß den empfangenen ersten Datentelegrammen 301 (von iBeacons) sucht
das mobile Endgerät nach zugehörigen zweiten Datentelegrammen 302 (von Travelbeacons).
Im Umkehrschluss kann kein zweites Datentelegramm 302 von einem Travelbeacon empfangen
werden, wenn nicht vorher das zugehörige erste Datentelegramm 301 von einem iBeacon
empfangen wurde.
[0101] Dabei ist das mobile Endgerät für erste Datentelegramme 301 von iBeacons gemäß dem
Bluetooth-Standard für iOS-Betriebssystem immer empfangsbereit, vorausgesetzt natürlich,
dass sein Bluetooth-Funknetz eingeschaltet ist.
[0102] In genau der gleichen Weise empfängt der Fahrzeugempfänger im Ausführungsbeispiel
diese neun Datentelegramme.
[0103] Figur 4 zeigt den beispielhaften Dateninhalt von fünf Endgeräte-Datensätzen 400 für das Ausführungsbeispiel.
In Figur 3 hat das mobile Endgerät insgesamt neun Datentelegramme empfangen, nämlich
vier erste Datentelegramme (von einem iBeacon) und fünf zweite Datentelegramme von
einem Travelbeacon. Die Daten, die zur Fahrtrekonstruktion erforderlich sind, waren
dabei teilweise in den ersten Datentelegrammen enthalten und teilweise in den zweiten
Datentelegrammen. Das bedeutet, dass ein mobiles Endgerät nur so viele Endgeräte-Datensätze
400 anlegen und an den Zentralrechner senden kann, wie es zweite Datentelegramme empfangen
hat, denn erst das Empfangen eines zweiten Datentelegramms liefert die Datenbasis
für einen kompletten Endgeräte-Datensatz 400.
[0104] Aus den in Fig. 3 empfangenen Datentelegrammen erstellt das mobile Endgerät nun die
Endgeräte-Datensätze 400 gemäß Fig. 4. Der Endgeräte-Datensatz 400 besteht zum Teil
aus empfangenen Daten 401 und zum Teil aus eigenen Daten des Endgeräts 402.
[0105] Aus den empfangenden Datentelegrammen extrahiert die App des mobilen Endgeräts gemäß
dem Beispiel die Daten empfangener GeoLog 403, empfangener RunCounter 404 und empfangene
Fahrzeugnummer 405 (alle gezeigt in Dezimaldarstellung). Diese Daten werden ergänzt
mit Daten, die das mobile Endgerät beifügt, hier die Gerätenummer 406 (im Beispiel:
die Telefonnummer) und ein Datums/Zeitstempel 407. - Diese Daten stellen gemäß dem
Ausführungsbeispiel den Kern des Dateninhalts der Endgeräte-Datensätze 400 dar. Für
den Fachmann wird klar sein, dass Endgeräte-Datensätze in der Praxis andere, zusätzliche
oder weniger Datenfelder enthalten können.
[0106] In Fig. 4 stammt der Endgeräte-Datensatz 499 aus dem letzten empfangenen zweiten
Datentelegramm (von dem benachbarten Bus "0815"). Darum springt der Wert des RunCounter
404 beim Datensatz 499 im Vergleich zu den anderen Werten, und die empfangende Fahrzeugnummer
405 ist beim Datensatz 499 anders als in den anderen Datensätzen.
[0107] Figur 5 zeigt den beispielhaften Dateninhalt von fünf Fahrzeugreferenz-Datensätzen 500 für
das Ausführungsbeispiel. Wie zuvor für das mobile Endgerät erläutert, kann auch ein
Bordrechner eines Fahrzeugs nur so viele Fahrzeugreferenz-Datensätze 500 anlegen und
an den Zentralrechner senden, wie er zweite Datentelegramme empfangen hat.
[0108] Aus den in Fig. 3 empfangenen Datentelegrammen erstellt der Bordrechner nun die Fahrzeugreferenz-Datensätze
500 gemäß Fig. 5. Der Fahrzeugreferenz-Datensatz 500 besteht zum Teil aus empfangenen
Daten 501 und zum Teil aus eigenen Daten des Fahrzeugs 502.
[0109] Aus den empfangenden Datentelegrammen extrahiert der Bordrechner gemäß dem Beispiel
die Daten empfangener GeoLog 503, empfangener RunCounter 504 und empfangene Fahrzeugnummer
505 (alle gezeigt in Dezimaldarstellung). Diese Daten werden ergänzt mit Daten, die
der Bordrechner beifügt, hier der eigene GeoLog 506, der eigene RunCounter 507, die
eigene Fahrzeugnummer 508 (alle gezeigt in Dezimaldarstellung), die eigene Ortsdaten
509 und einen Datums/Zeitstempel 510. - Diese Daten stellen gemäß dem Ausführungsbeispiel
den Kern des Dateninhalts der Fahrzeugreferenz-Datensätze 500 dar. Für den Fachmann
wird klar sein, dass Fahrzeugreferenz-Datensätze in der Praxis andere, zusätzliche
oder weniger Datenfelder enthalten können.
[0110] Wenn, wie im Beispiel, der Fahrzeugempfänger exakt dieselben Datentelegramme empfängt
wie ein mobiles Endgerät, dann sind die empfangenen Daten 501 in den Fahrzeugreferenz-Datensätzen
500 gleich den empfangene Daten 401 in den Endgeräte-Datensätzen 400.
[0111] In Fig. 5 stammt der Fahrzeugreferenz-Datensatz 599 aus dem letzten empfangenen zweiten
Datentelegramm (von dem benachbarten Bus "0815"). Darum weichen der empfangen RunCounter
504 und die empfangene Fahrzeugnummer 505 von den entsprechenden eigenen Daten des
Fahrzeugs 507, 508 ab.
Bezugszeichen
[0112]
- 100
- System
- 101
- Fahrzeug (hier: Bus "4711")
- 102
- erster Fahrzeugsender (hier: iBeacon)
- 103
- zweiter Fahrzeugsender (hier: Travelbeacon)
- 104
- Fahrzeugempfänger
- 105
- Bordrechner
- 106
- fahrzeugseitige Kommunikationseinheit
- 107
- GPS-Empfänger
- 108
- externes Fahrzeugdatennetz
- 109
- Zentralrechner
- 110
- mobile Endgeräte
- 111
- mobiles Datennetz
- 201
- fremdes Fahrzeug (hier: weiterer Bus "0815")
- 202
- fahrzeugfremder erster Fahrzeugsender (iBeacon)
- 203
- fahrzeugfremder zweiter Fahrzeugsender (hier: Travelbeacon)
- 301
- erstes Fahrzeugdatentelegramm
- 301.1
- erstes Fahrzeugdatentelegramm von Bus 4711
- 301.2
- fahrzeugfremdes erstes Fahrzeugdatentelegramm von Bus 0815
- 302
- zweites Fahrzeugdatentelegramm
- 302.1
- zweites Fahrzeugdatentelegramm von Bus 4711
- 302.2
- fahrzeugfremdes zweites Fahrzeugdatentelegramm von Bus 0815
- 303
- UUID eines ersten Fahrzeugdatentelegramms
- 304
- Major und Minor-Daten eines ersten Fahrzeugdatentelegramms
- 305
- Service-UUID eines zweiten Fahrzeugdatentelegramms
- 306
- GeoLog eines zweiten Fahrzeugdatentelegramms
- 307
- RunCounter eines zweiten Fahrzeugdatentelegramms
- 400
- Endgeräte-Datensätze
- 401
- empfange Daten der Endgeräte-Datensätze
- 402
- geräteeigene Daten der Endgeräte-Datensätze
- 403
- empfangene GeoLog-Daten der Endgeräte-Datensätze
- 404
- empfangene RunCounter-Daten der Endgeräte-Datensätze
- 405
- empfangene Fahrzeugnummern der Endgeräte-Datensätze
- 406
- Endgerätekenner
- 407
- geräteigener Zeitstempel
- 499
- Beispiel-Endgeräte-Datensatz
- 500
- Fahrzeugreferenz-Datensätze
- 501
- empfangene Daten der Fahrzeugreferenz-Datensätze
- 502
- fahrzeugeigene Daten der Fahrzeugreferenz-Datensätze
- 503
- empfangene GeoLog-Daten der Endgeräte-Datensätze
- 504
- empfangene RunCounter-Daten der Endgeräte-Datensätze
- 505
- empfangene Fahrzeugnummern der Endgeräte-Datensätze
- 506
- fahrzeugeigene GeoLog-Daten
- 507
- fahrzeugeigene RunCounter-Daten
- 508
- Fahrzeugnummer
- 509
- fahrzeugeigene Ortsdaten (hier: Längen- / Breitengrad)
- 510
- fahrzeugeigener Zeitstempel
- 599
- Beispiel-Fahrzeugreferenz-Datensatz
- 600
- Look-Up-Table
1. Verfahren zur automatischen Ermittlung der Anwesenheit eines mit einem mobilen Endgerät
ausgestatteten Nutzers in einem Fahrzeug, wobei im Fahrzeug wenigstens ein Fahrzeugsender
installiert ist,
mit den Schritten:
a) Aussenden, durch den Fahrzeugsender, wenigstens eines Fahrzeugdatentelegramms,
wobei das Fahrzeugdatentelegramm einen Code enthält,
b) Empfangen, durch das mobile Endgerät, wenigstens eines Fahrzeugdatentelegramms,
c) Erstellen, durch das mobile Endgerät, eines Endgeräte-Datensatzes,
d) Senden, durch das mobile Endgerät, des wenigstens einen Endgeräte-Datensatzes an
einen Zentralrechner,
e) Empfangen, durch den Zentralrechner, des wenigstens einen Endgeräte-Datensatzes
von wenigstens einem mobilen Endgerät.
f) Bestimmen, durch den Zentralrechner, der Authentizität des empfangenen wenigstens
einen Endgeräte-Datensatzes anhand des Codes.
g) Bestimmen, durch den Zentralrechner, der Anwesenheit des mobilen Endgeräts im Fahrzeug.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Verfahrensschritte wiederholt durchlaufen werden.
3. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass der Code ortsabhängig generiert wird.
4. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass der Code zeitabhängig variiert wird.
5. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass der Code fahrzeugseitig generiert wird und von einer fahrzeugseitigen Kommunikationseinrichtung
an den Zentralrechner gesendet wird.
6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass für jedes Fahrzeugdatentelegramm ein neuer Code generiert wird.
7. Verfahren nach einem der Ansprüche 5 bis 6, dadurch gekennzeichnet, dass die fahrzeugseitige Kommunikationsvorrichtung mehrere Codes speichert und gebündelt
an den Zentralrechner sendet.
8. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass nach Schritt c) das mobile Endgerät mehrere Endgeräte-Datensätze speichert und gebündelt
an den Zentralrechner sendet.
9. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass als Fahrzeugsender ein Bluetooth-Beacon verwendet wird.
10. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass als Fahrzeugsender ein Bluetooth-Low-Energy Beacon verwendet wird.
11. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die Verfahrensschritte auf dem mobilen Endgerät durch eine mobile Applikation ("App")
gesteuert werden.
12. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass das mobile Endgerät ein Smartphone, ein Tablet-Computer, eine Spielkonsole, ein Laptop-Computer,
ein Netbook, eine Datenbrille oder eine Smart-Watch ist.
13. System zur automatischen Ermittlung der Anwesenheit eines mit einem mobilen Endgerät
ausgestatteten Nutzers in einem Fahrzeug, bestehend aus
wenigstens einem Fahrzeug,
wenigstens einem Fahrzeugsender in dem Fahrzeug,
einem Zentralrechner mit wenigsten einer Datenbank,
und einem mobilen Datennetz,
wobei durch den wenigstens einen Fahrzeugsender Fahrzeugdatentelegramme aussendbar
sind, die einen Code enthalten und die durch das mobile Endgerät empfangbar sind,
wobei durch das mobile Endgerät Endgeräte-Datensätze erstellbar sind,
wobei durch das mobile Endgerät die Endgeräte-Datensätze an den Zentralrechner sendbar
sind,
wobei durch den Zentralrechner die Endgeräte-Datensätze empfangbar sind,
wobei durch den Zentralrechner die Authentizität der empfangenen Endgeräte-Datensätze
anhand des Codes bestimmbar ist,
und wobei durch den Zentralrechner die Anwesenheit des mobilen Endgerätes in dem Fahrzeug
bestimmbar ist.
14. System nach Anspruch 13, dieses weiterhin umfassend
eine fahrzeugseitige Kommunikationseinrichtung,
und ein externes Fahrzeugdatennetz,
wobei fahrzeugseitig erstellte Codes durch die fahrzeugseitige Kommunikationseinrichtung
an den Zentralrechner sendbar sind.
15. System nach einem der Ansprüche 13 bis 14, dieses weiterhin umfassend
eine fahrzeugseitige Kommunikationseinrichtung,
und ein externes Fahrzeugdatennetz,
wobei zentralrechnerseitig erstellte Codes durch die die fahrzeugseitige Kommunikationseinrichtung
empfangbar sind.
16. System nach einem der Ansprüche 13 bis 15, dadurch gekennzeichnet, dass der Fahrzeugsender ein Bluetooth-Beacon ist.
17. System nach einem der Ansprüche 13 bis 17, dadurch gekennzeichnet, dass der Fahrzeugsender ein Bluetooth-Low-Energy Beacon ist.
18. System nach einem der Ansprüche 13 bis 17, dadurch gekennzeichnet, dass das mobile Endgerät durch eine mobile Applikation ("App") steuerbar ist.
19. System nach einem Ansprüche 13 bis 18, dadurch gekennzeichnet, dass das mobile Endgerät ein Smartphone, ein Tablet-Computer, eine Spielkonsole, ein Laptop-Computer,
ein Netbook, eine Datenbrille oder eine Smart-Watch ist.
Geänderte Patentansprüche gemäss Regel 137(2) EPÜ.
1. Verfahren zur automatischen Ermittlung der Anwesenheit eines mit einem mobilen Endgerät
ausgestatteten Nutzers in einem Fahrzeug, wobei im Fahrzeug wenigstens ein Fahrzeugsender
installiert ist,
mit den Schritten:
a) Aussenden, durch den Fahrzeugsender, wenigstens eines Fahrzeugdatentelegramms,
b) Empfangen, durch das mobile Endgerät, wenigstens eines Fahrzeugdatentelegramms,
c) Erstellen, durch das mobile Endgerät, eines Endgeräte-Datensatzes,
d) Senden, durch das mobile Endgerät, des wenigstens einen Endgeräte-Datensatzes an
einen Zentralrechner,
e) Empfangen, durch den Zentralrechner, des wenigstens einen Endgeräte-Datensatzes
von wenigstens einem mobilen Endgerät.
f) Bestimmen, durch den Zentralrechner, der Anwesenheit des mobilen Endgeräts im Fahrzeug.
dadurch gekennzeichnet,
dass das Fahrzeugdatentelegramm einen Code enthält
und dass der Zentralrechner die Authentizität des empfangenen wenigstens einen Endgeräte-Datensatzes
anhand des Codes bestimmt.
2. Verfahren nach Anspruch 1), dadurch gekennzeichnet, dass die Verfahrensschritte wiederholt durchlaufen werden.
3. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass der Code ortsabhängig generiert wird.
4. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass der Code zeitabhängig variiert wird.
5. Verfahren nach einem der Ansprüche 1) bis 3), dadurch gekennzeichnet, dass der Code fahrzeugseitig generiert wird und von einer fahrzeugseitigen Kommunikationseinrichtung
an den Zentralrechner gesendet wird.
6. Verfahren nach Anspruch 5), dadurch gekennzeichnet, dass für jedes Fahrzeugdatentelegramm ein neuer Code generiert wird.
7. Verfahren nach einem der Ansprüche 5) bis 6), dadurch gekennzeichnet, dass die fahrzeugseitige Kommunikationsvorrichtung mehrere Codes speichert und gebündelt
an den Zentralrechner sendet.
8. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass nach Schritt c) das mobile Endgerät mehrere Endgeräte-Datensätze speichert und gebündelt
an den Zentralrechner sendet.
9. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass als Fahrzeugsender ein Bluetooth-Beacon verwendet wird.
10. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass als Fahrzeugsender ein Bluetooth-Low-Energy Beacon verwendet wird.
11. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die Verfahrensschritte auf dem mobilen Endgerät durch eine mobile Applikation ("App")
gesteuert werden.
12. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass das mobile Endgerät ein Smartphone, ein Tablet-Computer, eine Spielkonsole, ein Laptop-Computer,
ein Netbook, eine Datenbrille oder eine Smart-Watch ist.
13. System zur automatischen Ermittlung der Anwesenheit eines mit einem mobilen Endgerät
ausgestatteten Nutzers in einem Fahrzeug, bestehend aus
wenigstens einem Fahrzeug,
wenigstens einem Fahrzeugsender in dem Fahrzeug, einem Zentralrechner mit wenigsten
einer Datenbank, und einem mobilen Datennetz,
wobei durch den wenigstens einen Fahrzeugsender Fahrzeugdatentelegramme aussendbar
sind, die durch das mobile Endgerät empfangbar sind,
wobei durch das mobile Endgerät Endgeräte-Datensätze erstellbar sind,
wobei durch das mobile Endgerät die Endgeräte-Datensätze an den Zentralrechner sendbar
sind,
wobei durch den Zentralrechner die Endgeräte-Datensätze empfangbar sind,
und wobei durch den Zentralrechner die Anwesenheit des mobilen Endgerätes in dem Fahrzeug
bestimmbar ist,
dadurch gekennzeichnet,
dass die Fahrzeugdatentelegramme einen Code enthalten
und dass durch den Zentralrechner die Authentizität der empfangenen Endgeräte-Datensätzt anhand
des Codes bestimmbar ist.
14. System nach Anspruch 13), dieses weiterhin umfassend
eine fahrzeugseitige Kommunikationseinrichtung
und ein externes Fahrzeugdatennetz,
wobei fahrzeugseitig erstellte Codes durch die fahrzeugseitige Kommunikationseinrichtung
an den Zentralrechner sendbar sind.
15. System nach einem der Ansprüche 13) bis 14), dieses weiterhin umfassend
eine fahrzeugseitige Kommunikationseinrichtung
und ein externes Fahrzeugdatennetz,
wobei zentralrechnerseitig erstellte Codes durch die die fahrzeugseitige Kommunikationseinrichtung
empfangbar sind.
16. System nach einem der Ansprüche 13) bis 15), dadurch gekennzeichnet, dass der Fahrzeugsender ein Bluetooth-Beacon ist.
17. System nach einem der Ansprüche 13) bis 16), dadurch gekennzeichnet, dass der Fahrzeugsender ein Bluetooth-Low-Energy Beacon ist.
18. System nach einem der Ansprüche 13) bis 17), dadurch gekennzeichnet, dass das mobile Endgerät durch eine mobile Applikation ("App") steuerbar ist.
19. System nach einem Ansprüche 13) bis 18), dadurch gekennzeichnet, dass das mobile Endgerät ein Smartphone, ein Tablet-Computer, eine Spielkonsole, ein Laptop-Computer,
ein Netbook, eine Datenbrille oder eine Smart-Watch ist.