EP3358532B1 - Verfahren zur automatischen ermittlung der nutzung von fahrzeugen - Google Patents

Verfahren zur automatischen ermittlung der nutzung von fahrzeugen Download PDF

Info

Publication number
EP3358532B1
EP3358532B1 EP17154545.2A EP17154545A EP3358532B1 EP 3358532 B1 EP3358532 B1 EP 3358532B1 EP 17154545 A EP17154545 A EP 17154545A EP 3358532 B1 EP3358532 B1 EP 3358532B1
Authority
EP
European Patent Office
Prior art keywords
vehicle
data
terminal device
central computer
mobile terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
EP17154545.2A
Other languages
English (en)
French (fr)
Other versions
EP3358532A1 (de
Inventor
Manfred Feiter
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Scheidt and Bachmann GmbH
Original Assignee
Scheidt and Bachmann GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Scheidt and Bachmann GmbH filed Critical Scheidt and Bachmann GmbH
Priority to EP17154545.2A priority Critical patent/EP3358532B1/de
Publication of EP3358532A1 publication Critical patent/EP3358532A1/de
Application granted granted Critical
Publication of EP3358532B1 publication Critical patent/EP3358532B1/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
    • G07B15/02—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points taking into account a variable factor such as distance or time, e.g. for passenger transport, parking systems or car rental systems

Definitions

  • the present invention relates to a method for automatically determining vehicle usage. Essentially, it involves automatically determining the use of fee-based means of transport as a basis for calculating fares. It is assumed that the presence of a mobile device in the vehicle indicates the user's use of the vehicle. For several years, various approaches have existed in the prior art for calculating fares based on the technically determined presence of passengers in a vehicle. For this purpose, data is periodically and wirelessly exchanged between a vehicle infrastructure and a user terminal. This data can be credited to a (previously loaded) travel value in the user terminal, or the data is transmitted to a central computer, where the journey is determined and the fare is calculated. These methods are known under the keyword "Be-In/Be-Out,” or "BIBO" for short.
  • the data communication between the vehicle-side communication device and the central computer can be permanently active or activated periodically or depending on the location of the vehicle or the number of data telegrams received.
  • the data communication can be based on a digital mobile network (GSM, GPRS, UMTS, LTE), a Wi-Fi connection, a Bluetooth connection, an infrared connection, or any other suitable wired or wireless data connection.
  • Wired or otherwise locally limited data connections can, of course, only be active when the vehicle is within the data connection range, for example, at a bus station, train station, a pier, or at stops equipped with a corresponding data connection.
  • At least one vehicle transmitter in a vehicle repeatedly transmits vehicle data telegrams. These vehicle data telegrams are at least partially received by the at least one vehicle receiver, i.e., at least one vehicle receiver receives at least one complete vehicle data telegram.
  • the vehicle receiver reads the digital vehicle data contained in the received vehicle data telegrams.
  • the digital vehicle data from the vehicle data telegrams contain a time specification (e.g., date and time) or is supplemented by the vehicle receiver or the on-board computer with a current time specification.
  • the vehicle receiver or the on-board computer further supplements the data with a system-wide, unique identifier of the vehicle's own vehicle and the vehicle's location.
  • the vehicle-side communication device sends the received digital vehicle reference data sets to the central computer. Furthermore, the transmission of a vehicle reference data set by the vehicle-side communication device can occur with a time delay, which here means that more than X minutes pass between the receipt of a data telegram and the transmission of the vehicle reference data set.
  • the vehicle-side communication device can temporarily store the vehicle reference data sets and thus send a large number of vehicle reference data sets to the central computer in a bundle. This is particularly the case when the data connection between the vehicle-side communication device and the central computer is not permanently active.
  • the vehicle reference data sets that the central computer receives from the vehicle-side communication device are stored there in at least one database. The central computer receives corresponding vehicle reference data sets from a large number of vehicles.
  • At least one vehicle transmitter in a vehicle repeatedly transmits vehicle data telegrams.
  • These vehicle data telegrams are at least partially received by a user's mobile terminal, i.e. the mobile terminal receives at least one complete vehicle data telegram.
  • the mobile terminal reads the digital vehicle data contained in the received vehicle data telegrams.
  • the digital vehicle data from the vehicle data telegrams contain a time specification (e.g. date and time) or they are supplemented by the mobile terminal with a current time specification; the digital vehicle data can also contain the vehicle location.
  • the mobile terminal supplements the data with its system-wide unique identifier.
  • a digital terminal data set is thus created from the data of a received vehicle data telegram.
  • the system-wide unique identifier of the mobile terminal can be a mobile telephone number, a mobile telephone ID, an IMEI number (International Mobile Station Equipment Identity), a MAC address (Media Access Control address, also known as Ethernet ID, Airport ID or WiFi ID), a Bluetooth MAC address, a user ID under which a user maintains his user account in the fare management system, a user ID under which a user has registered his BIBO app with which the method according to the invention is carried out, a user identification under which the BIBO app was purchased, or any other system-wide unique identifier that allows the mobile terminal to be identified.
  • the mobile device sends the device data records to the central computer. This can occur in real time, i.e., immediately after the mobile device has received a data telegram, or in quasi-real time, which here means that up to X minutes can elapse between the receipt of a data telegram and the transmission of the device data record. Furthermore, the transmission of a device data record by the mobile device can occur with a time delay. What this means here is that more than X minutes elapse between the receipt of a data telegram and the transmission of the terminal data record.
  • the mobile terminal can temporarily store the terminal data records and thus send a large number of terminal data records to the central computer in a bundle. This is particularly the case when the data connection between the mobile terminal and the central computer is not permanently active.
  • the terminal data records that the central computer receives from the mobile terminal are stored there in the at least one database.
  • the central computer receives corresponding terminal data records from a large number of mobile terminals.
  • the journey reconstruction according to the invention on the central computer for each mobile terminal used is therefore particularly "robust" and insensitive to possible non-vehicle data telegrams that a terminal potentially receives, since the central computer knows via the vehicle reference data sets which data telegrams - even non-vehicle ones - belong to the reconstructed journey.
  • the look-up table can, for example, contain data on the sequence of stops on the current journey, the names of the stops, the expected arrival times of the vehicle at the stops, accessible connecting connections, weather data, warning data about weather or road conditions, etc. This data can be displayed to the app user as journey information.
  • the code can be generated from status data, for example, from the current location data of the vehicle, e.g., as a hash value from the longitude and latitude of the vehicle location or from the route.
  • the code can be generated from a date/time stamp, e.g., as a hash value from it.
  • the authenticity check according to the invention becomes particularly secure when the codes are changed frequently.
  • the authenticity check is then not based on the match of one or a few codes in multiple terminal and vehicle reference data sets, but rather on a sequence of frequently varied codes, so that good procedural security is achieved even with relatively short codes.
  • the repeated transmission of the first vehicle data telegrams by the at least one first BLE beacon can mean, in the sense of the invention: transmission with constant time intervals between two transmission processes, transmission with variable time intervals between two transmission processes, transmission in time intervals that depend on at least one of the following criteria: driving speed, location of the vehicle within the fare zone of a fare system, reaching or crossing fare zone boundaries by the vehicle, state of the vehicle doors (open or closed or just closed) and a combination of such criteria.
  • the data of the at least one first beacon can be used in two different ways for the method according to the invention: Firstly, the data of the at least one first beacon contains data for trip recording, such as the operator number (a system-specific identifier for the transport company), the vehicle number, a reference to the look-up table, the trip number (e.g. bus line, train number, etc.), direction of travel, the number of the next Breakpoint or any other type of data or combination of data that can be used for the secure implementation of the method according to the invention and that can be represented in the BLE radio data signal within the scope of the available data volume.
  • the operator number a system-specific identifier for the transport company
  • the vehicle number e.g. bus line, train number, etc.
  • the trip number e.g. bus line, train number, etc.
  • direction of travel e.g. bus line, train number, etc.
  • the code can be generated from a date/time stamp, e.g., as a hash value thereof.
  • the second vehicle data telegrams can contain data about the distance traveled by the vehicle, such as a travel counter. If the maximum counter value is exceeded, the counter is restarted at the value 0.
  • the second vehicle data telegrams can contain any combination of data that can be used for the secure implementation of the method according to the invention and that can be represented in the BLE radio data signal within the scope of the available data volume.
  • both vehicle transmitters i.e. both BLE beacons
  • the vehicle's on-board computer which carries out the change of the data contents for both the first and the second vehicle data telegram and dynamically configures the UUID of the second vehicle transmitter so that it can be extracted from the first vehicle data telegrams by a procedural app.
  • the data of the at least one first beacon contains - as above mentioned - data for trip recording, such as the operator number (a system-specific identifier for the transport company), the vehicle number, a reference to the look-up table, the trip number (e.g. bus line, train number, etc.), direction of travel, and the number of the next stop.
  • this data is static, e.g., only the operator number and the vehicle number, because, for example, the vehicle infrastructure does not provide dynamic trip data.
  • it is proposed to vary the data of at least one first beacon e.g., with a time-variable random number or the hash of a date/time stamp, or similar.
  • the on-board computer 105 is connected to a GPS receiver 107 via a data network, so that the current location of the bus 101 is known in the on-board computer 105 as location data (longitude and latitude).
  • the first vehicle transmitter 102 periodically transmits a first vehicle data telegram 301.1, namely as an iBeacon radio signal (the content of this first vehicle data telegram is in Fig. 2
  • a mobile terminal 110 receives at least a first vehicle data telegram and starts a pre-installed app to participate in the automated BIBO process.
  • the vehicle receiver 104 also receives the vehicle data telegrams 301.1, 302.1 and external data telegrams 301.2, 302.2. It extracts data from the received data telegrams and forwards them to the on-board computer 105.
  • the on-board computer 105 uses this data to write a second log file in which the sequence of digital data from the received data telegrams 301.1, 302.1, 301.2, 302.2 is logged.
  • the second log file is stored and managed in the on-board computer 105.
  • the on-board computer 105 tags each entry in the second log file with the current location of the vehicle, which is determined via a GPS receiver 107.
  • the first vehicle data telegram 301 originates from an iBeacon. It can thus be received by mobile devices running the iOS operating system without requiring any special configuration; only the Bluetooth radio network must be activated on the respective device.
  • the on-board computer which generates the major and minor data 304 for the first vehicle transmitter (the iBeacon), also configures the second vehicle transmitter (the Travelbeacon) via a data network connection, for whose second data telegrams 302 the app searches.
  • the vehicle receiver also receives first and second data telegrams 301, 302. It also extracts from the major and minor values 304, from the GeoLog 306 and from the RunCounter 307 Trip recording data; this will be part of the data that the on-board computer writes to the second log file.
  • Figure 3 Describes the exemplary reception of a sequence of 9 vehicle data telegrams by a mobile device and by the vehicle receiver.
  • the mobile device is located on bus "4711"; the vehicle receiver is the one on bus "4711".
  • the bus's on-board computer changes the random number in the major and minor values of the iBeacon and the associated service UUID of the travel beacon.
  • the iBeacon's data telegrams change.
  • the mobile device receives such a changed first data telegram 301.1 and then two further second data telegrams 302.1. (Data telegrams #4-6 from Figure 3 )
  • the mobile device is always ready to receive the first 301 data telegrams from iBeacons according to the Bluetooth standard for iOS operating systems, provided, of course, that its Bluetooth radio network is switched on.
  • Figure 4 shows the exemplary data content of five terminal data records 400 for the embodiment.
  • the mobile device received a total of nine data telegrams, namely four first data telegrams (from an iBeacon) and five second data telegrams from a travel beacon.
  • the data required for journey reconstruction was contained partly in the first data telegrams and partly in the second data telegrams. This means that a mobile device can only create and send to the central computer as many device data sets 400 as it has received second data telegrams, because only the receipt of a second data telegram provides the database for a complete device data set 400.
  • Figure 5 shows the exemplary data content of five vehicle reference data sets 500 for the exemplary embodiment.
  • an on-board computer of a vehicle can only create and send to the central computer as many vehicle reference data sets 500 as it has received second data telegrams.
  • the on-board computer now creates the vehicle reference data records 500 according to Fig. 5
  • the vehicle reference data set 500 consists partly of received data 501 and partly of the vehicle's own data 502.
  • the on-board computer extracts the received GeoLog 503, received RunCounter 504, and received Vehicle Number 505 (all shown in decimal notation) from the received data telegrams.
  • This data is supplemented with data added by the on-board computer, here the on-board computer's own GeoLog 506, the on-board RunCounter 507, the on-board vehicle number 508 (all shown in decimal notation), the on-board location data 509, and a date/time stamp 510.
  • this data represents the core data content of the vehicle reference data sets 500. It will be clear to those skilled in the art that vehicle reference data sets may contain other, additional, or fewer data fields in practice.

Landscapes

  • Business, Economics & Management (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

  • 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".
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Aus dem Stand der Technik ist ferner gemäß der US 2015/0348334 A1 ein Verfahren zum Generieren von Reisedaten durch ein mobiles Endgerät eines Benutzers bekannt. Dabei ist vorgesehen, dass das mobile Endgerät Daten empfängt, die von einem oder mehreren Beacons eines Transportsystems ausgesandt werden.
  • Aus der US 2015/0235477 A1 ist ein Verfahren zur automatisierten Fahrpreisberechnung bekannt, demgemäss an ein mobiles Endgerät von einem im Fahrzeug befindlichen Beacon eine Beaconkennung und/oder einer Fahrzeugkennung übersandt wird. Zudem werden Einstiegs- und Ausstiegszeiten erfasst, so dass auf dieser Basis eine automatisierte Fahrpreisberechnung erfolgen kann, die entweder vom mobilen Endgerät selbst oder von einem zentralen Rechner durchgeführt wird.
  • Aus der DE 10 2012 101 638 A1 ist ein Verfahren und ein System zur Ermittlung von Verkehrsmittel-/Fahrstreckendaten an ein Mobilfunkgerät bekannt.
  • Die EP 2 811 444 A1 offenbart schließlich noch ein Verfahren sowie eine Vorrichtung zur Ermittlung der Inanspruchnahme einer Dienstleistung eines öffentlichen Verkehrsmittels.
  • 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.
  • 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 11 vor. Weitere Vorteile und Merkmale ergeben sich aus den Unteransprüchen.
  • Erfindungsgemäß ist in einem Fahrzeug wenigstens ein Fahrzeugsender 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.
  • 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.
  • 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.
  • Gemäß einer nicht beanspruchten Ausführungsform ist wenigstens ein Fahrzeugempfänger dazu ausgelegt, fahrzeugeigene 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Gemäß einer nicht beanspruchten Ausführungsform kann die Weiterverarbeitung der von dem mindestens einen Fahrzeugempfänger und den mobilen Endgeräten empfangenen Daten Folgendes 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.
  • 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.
  • Gemäß einer nicht beanspruchten Ausführungsform 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.
  • Ein "Fahrzeug" 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.
  • 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.
  • 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.
  • Die fahrzeugseitige Kommunikationseinrichtung sendet die erhaltenen digitalen Fahrzeugreferenz-Datensätze an den Zentralrechner. 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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. 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Es ist dabei möglich, dass die App auch fahrzeugfremde erste Datentelegramme empfängt und in der Folge nach fahrzeugfremden zweiten Datentelegrammen sucht.
  • 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.
  • 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.ä.
  • 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.
  • 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.
  • Die folgenden Ausführungen sind beispielhaft und nicht beschränkend.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Die fahrzeugseitige Kommunikationseinheit 106 ist mit einem Zentralrechner 109 über ein externes Fahrzeugdatennetz 108 datennetzwerkmäßig verbunden, in diesem Beispiel über ein digitales Mobilfunknetz.
  • 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.
  • Für das vorliegende Beispiel wird angenommen, dass die mobilen Endgeräte 110 mit dem Betriebssystem iOS betrieben werden.
  • 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.
  • 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.
  • 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.
  • Gleichzeitig "monitort" das mobile Endgerät weiterhin nach periodisch ausgesendeten ersten Fahrzeugdatentelegramm 301.1, also nach iBeacon-Funksignalen, und empfängt auch diese.
  • 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 der gleichen Weise empfangen, wie die Fahrzeugdatetelegramme 301.1, 302.1.
  • 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).
  • 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).
  • 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.
  • Figur 2 beschreibt den Aufbau eines ersten und eines zweiten Fahrzeugdatentelegramms für das Ausführungsbeispiel.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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)
  • 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).
  • 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).
  • 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.
  • 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.
  • In genau der gleichen Weise empfängt der Fahrzeugempfänger im Ausführungsbeispiel diese neun Datentelegramme.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
    • 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

Claims (15)

  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, und wobei das mobile Endgerät über ein mobiles Datennetz mit einem Zentralrechner verbunden ist, mit den Schritten:
    a) Wiederholtes Aussenden, durch den Fahrzeugsender, wenigstens eines Fahrzeugdatentelegramms, wobei das Fahrzeugdatentelegramm wenigstens eine systemweit eineindeutige Kennung des Fahrzeugs enthält,
    b) Empfangen, durch das mobile Endgerät, wenigstens eines Fahrzeugdatentelegramms,
    c) Erstellen, durch das mobile Endgerät, eines Endgeräte-Datensatzes aus dem Fahrzeugdatentelegramm, wobei der Endgeräte-Datensatz wenigstens die systemweit eindeutige Kennung des Fahrzeugs, eine systemweit eineindeutige Kennung des Endgeräts und einen Zeitstempel enthält,
    d) Senden, durch das mobile Endgerät, des wenigstens einen Endgeräte-Datensatzes an den 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 auf Basis des Endgeräte-Datensatzes,
    dadurch gekennzeichnet,
    dass das Fahrzeugdatentelegramm zusätzlich zu der systemweit eindeutigen Kennung des Fahrzeugs einen Code enthält,
    dass der Code zeitabhängig variiert wird,
    dass der Code fahrzeugseitig generiert wird und von einer fahrzeugseitigen Kommunikationseinrichtung an den Zentralrechner gesendet wird,
    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 Anspruch 1, dadurch gekennzeichnet, dass für jedes Fahrzeugdatentelegramm ein neuer Code generiert wird.
  5. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die fahrzeugseitige Kommunikationsvorrichtung mehrere Codes speichert und gebündelt an den Zentralrechner sendet.
  6. 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.
  7. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass als Fahrzeugsender ein Bluetooth-Beacon verwendet wird.
  8. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass als Fahrzeugsender ein Bluetooth-Low-Energy Beacon verwendet wird.
  9. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die Verfahrensschritte auf dem mobilen Endgerät durch eine mobile Applikation ("App") gesteuert werden.
  10. 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.
  11. 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 wenigstens einer Datenbank,
    einem mobilen Datennetz,
    einer fahrzeugseitigen Kommunikationseinrichtung,
    und einem externen Fahrzeugdatennetz,
    wobei der wenigstens eine Fahrzeugsender konfiguriert ist wiederholt Fahrzeugdatentelegramme auszusenden, wobei ein Fahrzeugdatentelegramm wenigstens eine systemweit eineindeutige Kennung des Fahrzeugs enthält,
    wobei das mobile Endgerät konfiguriert ist, Fahrzeugdatentelegramme zu empfangen und aus empfangenen Fahrzeugdatentelegrammen Endgeräte-Datensätze zu erstellen, wobei ein Endgeräte-Datensatz wenigstens die systemweit eindeutige Kennung des Fahrzeugs, eine systemweit eineindeutige Kennung des Endgeräts und einen Zeitstempel enthält,
    wobei das mobile Endgerät konfiguriert ist, die Endgeräte-Datensätze an den Zentralrechner zu senden,
    wobei der Zentralrechner konfiguriert ist, die Endgeräte-Datensätze zu empfangen,
    und wobei der Zentralrechner konfiguriert ist, die Anwesenheit des mobilen Endgerätes in dem Fahrzeug auf Basis der Endgeräte-Datensätze zu bestimmen,
    dadurch gekennzeichnet,
    dass die Fahrzeugdatentelegramme zusätzlich zu der systemweit eindeutigen Kennung des Fahrzeugs einen Code enthalten,
    dass der Code vor der Übertragung an den Zentralrechner fahrzeugseitig generiert wird,
    dass der Code zeitabhängig variiert wird,
    dass die fahrzeugseitige Kommunikationseinrichtung konfiguriert ist, fahrzeugseitig erstellte Codes an den Zentralrechner zu senden
    und dass der Zentralrechner konfiguriert ist, die Authentizität der empfangenen Endgeräte-Datensätze anhand des Codes zu bestimmen.
  12. System nach Anspruch 11, dadurch gekennzeichnet, dass der Fahrzeugsender ein Bluetooth-Beacon ist.
  13. System nach Anspruch 11, dadurch gekennzeichnet, dass der Fahrzeugsender ein Bluetooth-Low-Energy Beacon ist.
  14. System nach einem der Ansprüche 11 bis 13, dadurch gekennzeichnet, dass das mobile Endgerät durch eine mobile Applikation ("App") steuerbar ist.
  15. System nach einem der Ansprüche 11 bis 14, 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.
EP17154545.2A 2017-02-03 2017-02-03 Verfahren zur automatischen ermittlung der nutzung von fahrzeugen Active EP3358532B1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP17154545.2A EP3358532B1 (de) 2017-02-03 2017-02-03 Verfahren zur automatischen ermittlung der nutzung von fahrzeugen

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP17154545.2A EP3358532B1 (de) 2017-02-03 2017-02-03 Verfahren zur automatischen ermittlung der nutzung von fahrzeugen

Publications (2)

Publication Number Publication Date
EP3358532A1 EP3358532A1 (de) 2018-08-08
EP3358532B1 true EP3358532B1 (de) 2025-04-09

Family

ID=58158770

Family Applications (1)

Application Number Title Priority Date Filing Date
EP17154545.2A Active EP3358532B1 (de) 2017-02-03 2017-02-03 Verfahren zur automatischen ermittlung der nutzung von fahrzeugen

Country Status (1)

Country Link
EP (1) EP3358532B1 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4120212A1 (de) * 2021-07-16 2023-01-18 Deutsche Telekom AG Verfahren zur präsenzdetektion und/oder eventregistrierung an einem ort oder in einem räumlichen bereich, system zur präsenzdetektion und/oder eventregistrierung, stationäres kurzreichweiten-funkmodul oder mobiles kurzreichweiten-funkmodul, computerprogramm und computerlesbares medium
DE102023201555A1 (de) * 2023-02-22 2024-08-22 Zf Friedrichshafen Ag Tracking von Kindern mittels CiCo- oder BiBo-System
DE102023116909A1 (de) * 2023-06-27 2025-01-02 Scheidt & Bachmann Gmbh Fahrzeuganordnung für ein Personentransportfahrzeug
WO2025011757A1 (de) * 2023-07-11 2025-01-16 Sonobeacon Gmbh Verfahren und system zur verkehrsmittel-nutzungs-analyse

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000033258A1 (de) 1998-11-30 2000-06-08 Joachim Albrecht Verfahren zur abrechnung des fahrpreises bei der benutzung öffentlicher verkehrsmittel
EP1667074B1 (de) 2004-12-02 2019-10-30 mcity GmbH Verfahren zur automatisierten Erfassung der Benutzung kostenpflichtiger Transportmittel und zur Abrechnung des Fahrpreises
DE102012101638A1 (de) * 2012-02-29 2013-08-29 Rainer Söllner Verfahren und System zur Übermittlung von Verkehrsmittel-/Fahrstreckendaten in einem Verkehrsmittel an ein Mobilfunkgerät und zur Ermittlung von abrechnungsrelevanten Daten
EP2658291B1 (de) 2012-04-24 2018-06-13 Scheidt & Bachmann GmbH Verfahren zur automatisierten Ermittlung des Aufenthaltsortes einer Person
EP2657900A1 (de) 2012-04-24 2013-10-30 Scheidt & Bachmann GmbH Verfahren zur automatischen Erfassung von Nutzungsinformationen
EP2811444A1 (de) * 2013-06-07 2014-12-10 Scheidt & Bachmann GmbH Verfahren und Vorrichtung zur Ermittlung der Inanspruchnahme einer Dienstleistung eines öffentlichen Verkehrsmittels
WO2015127095A1 (en) * 2014-02-19 2015-08-27 Swyft Technologies Inc. Automatic wireless transportation monitoring and transactions for mobile drvices
GB2527499A (en) * 2014-05-29 2015-12-30 Mastercard International Inc Travel data of transport system users

Also Published As

Publication number Publication date
EP3358532A1 (de) 2018-08-08

Similar Documents

Publication Publication Date Title
EP3358532B1 (de) Verfahren zur automatischen ermittlung der nutzung von fahrzeugen
EP2624233A1 (de) Verfahren zur Kontrolle in einem Straßenmautsystem
EP2924662B1 (de) Onboard-Unit und Verfahren zur Funktionsüberwachung in einem Straßenmautsystem
EP2325807B2 (de) Verfahren und Vorrichtungen zum Erzeugen von Mautinformationen in einem Strassenmautsystem
DE102012101638A1 (de) Verfahren und System zur Übermittlung von Verkehrsmittel-/Fahrstreckendaten in einem Verkehrsmittel an ein Mobilfunkgerät und zur Ermittlung von abrechnungsrelevanten Daten
EP2500869B1 (de) Verfahren zum Zurverfügungstellen von ortsbezogenen Datendiensten
EP3383094B1 (de) System und verfahren zur übertragung von inhalten mit grossen datenvolumen in kurzer zeit
EP2360646A1 (de) Verfahren zur DSRC-Kommunikation
EP2541502A1 (de) Verfahren zum Ermitteln von Mautgebühren in einem Straßenmautsystem
EP2490183B1 (de) Fahrzeuggerät, ad-hoc-Netzwerk und Verfahren für ein Strassenmautsystem
DE102009054795A1 (de) Fahrzeug-zu-X Kommunikation über mobile Geräte, die mit dem Fahrzeug verbunden sind
DE112019003236T5 (de) Fahrzeug-zu-Fahrzeug-Kommunikationssystem und Fahrzeugkommunikationsvorrichtung
EP3358533B1 (de) Verfahren zur automatischen ermittlung der nutzung von fahrzeugen
DE102013226532A1 (de) Verfahren zur Vorbereitung und Durchführung einer Fahrt einer Mehrzahl zu einem Verbund zusammengeschlossener Fahrzeuge und Kommunikationssystem
WO2017167568A1 (de) Verfahren und system zur anwesenheitserfassung und/oder fahrpreisermittlung für einen fahrgast in einem fahrzeug
EP3817406B1 (de) Verfahren zum betreiben einer auf einem mobilen endgerät installierten dienstleistungsanwendung
EP4099182B1 (de) Verfahren zum aufbauen und aktualisieren einer datenbank für ladeeinrichtungen und kraftfahrzeug
DE202016001371U1 (de) Fahrzeugeinrichtung, System und straßenseitige Einrichtung zur Durchführung wenigstens einer Transaktion
DE102016212163A1 (de) Verfahren und Steuervorrichtung zum Betreiben einer Basisstation
DE102020121114A1 (de) Verfahren und System zum Aufbauen einer digitalen Umgebungskarte für Verkehrsteilnehmer sowie Kraftfahrzeug für das System
DE102014201664B4 (de) Verfahren und Fortbewegungsmittel zur Bereitstellung von mobilen Sensordaten auf einem stationären Server
DE102022202678B3 (de) Kommunikationsmodul, Fahrzeug, Verfahren für ein Kommunikationsmodul und Computerprogramm
EP2242024B1 (de) Verfahren, Komponenten und Systeme zum Erzeugen von Mauttransaktionen
DE102010033478A1 (de) Identifikation von Teilnehmern in Nahkommunikationsnetzen
EP2413292B1 (de) Verfahren zur Analyse der Funktion und/oder Daten einer Vielzahl von Vorrichtungen

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20171222

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20210520

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230525

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20241114

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 502017016781

Country of ref document: DE

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: GERMAN

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20250409

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250409

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250409

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250409

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250811

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG9D

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250709

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250710

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250409

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250409

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250409

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250709

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250809

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250409

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 502017016781

Country of ref document: DE

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250409

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250409

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250409

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250409

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250409

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250409

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250409

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

REG Reference to a national code

Ref country code: CH

Ref legal event code: L10

Free format text: ST27 STATUS EVENT CODE: U-0-0-L10-L00 (AS PROVIDED BY THE NATIONAL OFFICE)

Effective date: 20260218

REG Reference to a national code

Ref country code: CH

Ref legal event code: U11

Free format text: ST27 STATUS EVENT CODE: U-0-0-U10-U11 (AS PROVIDED BY THE NATIONAL OFFICE)

Effective date: 20260301

26N No opposition filed

Effective date: 20260112

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: CH

Payment date: 20260301

Year of fee payment: 10