METHOD FOR AUTOMATIC DETERMINATION OF VEHICLE USE

Description

[0001] The present invention relates to a method for automatically determining vehicle usage. Essentially, it involves automatically determining the usage of fee-based means of transport as a basis for billing the fare. It is assumed that the presence of a mobile device in the vehicle is used to determine whether the vehicle is being used by a user. For several years, various approaches to fare billing based on the technically detected presence of passengers in a vehicle have existed in the prior art. 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 can be transmitted to a central computer, where the journey is determined and the fare is calculated.These procedures are known under the keyword "Be-In / Be-Out", or "BIBO" for short.

[0002] For data exchange between the vehicle infrastructure and the user terminals, the state of the art includes unidirectional BIBO methods, in which a vehicle transmitter transmits radio signals with digital data content ("data telegrams") that can be received by the user terminals present in the vehicle. There are also bidirectional BIBO methods, in which data telegrams are sent back and forth between the vehicle transmitter and the multitude of user terminals.The disadvantage of unidirectional BIBO methods is that the vehicle infrastructure does not know, or at least not directly, which user media are currently present in the vehicle; the disadvantage of bidirectional BIBO methods is that the back-and-forth transmission of data telegrams results in a significant volume of radio traffic in the vehicle, and that the transmission and reception processes must be synchronized by the vehicle infrastructure in a complex manner to avoid signal collisions, which can lead to significant data loss.

[0003] A number of BIBO methods are known in the prior art, for example from DE 199 57 660 (bidirectional data exchange) and EP 1 667 074 A1 (unidirectional data exchange).

[0004] BIBO processes can generally be implemented with various types of user devices. Dedicated devices can be used that are specifically configured to receive data telegrams from the vehicle infrastructure and, if necessary, also send data telegrams back to the vehicle infrastructure. In any case, the user devices must be able to communicate wirelessly with the vehicle infrastructure over a distance of several meters via a radio interface. This requires that the user devices have their own power supply.If dedicated user devices are used, they must not only be manufactured specifically for this purpose and distributed to users, but it must also be ensured that the user devices either have sophisticated energy management so that their power supply - usually via a battery - is sufficient for a long time, or the user devices must have a rechargeable battery that must be recharged by the users.

[0005] The widespread use of mobile devices from the IT sector has encouraged the use of mass-market mobile devices, such as smartphones, for BIBO processes instead of dedicated user devices. Many users carry these devices with them practically all the time and charge them regularly. Using mass-market mobile devices as BIBO user devices eliminates both the need to produce and distribute dedicated BIBO user devices and the requirement for sophisticated energy management. BIBO processes can be implemented on mass-market mobile devices using mobile applications, so-called "apps."

[0006] In the prior art, for example, EP 2 657 900 A1 and EP 2 658 291 A1 dealt with the use of mass-market available mobile terminals for BIBO processes.

[0007] A further advantage of using mass-market available mobile devices as BIBO user devices is that these devices have a variety of radio-based data interfaces that can be used for BIBO procedures.

[0008] The disadvantage of these interfaces is that they are mostly "open," meaning that mass-market mobile devices are capable of receiving digital data from various sources via their radio interfaces. This does not guarantee that the data telegrams received by the mobile devices actually represent authentic data that can be used for trip accounting. Mass-market mobile devices typically have an interface for digital mobile networks (GSM, GPRS, UMTS, LTE), which is usually used for telephony and data exchange with mobile networks. Only this interface is secured via a SIM card and authorized in the mobile network; however, the mobile interface cannot be used to receive BIBO data telegrams from the vehicle infrastructure, as mobile networks do not meet the BIBO requirements regarding highly limited localization.Other radio interfaces of mass-market mobile devices are open and cannot be specifically secured for a BIBO procedure.

[0009] A further difficulty of all BIBO systems is to reliably determine that a user with a user terminal - be it a dedicated device for a ticketing system or a mass-market mobile device - has undertaken a specific journey. To do this, it must be reliably determined that the user with their device was in a specific vehicle for a sequence of points in time. The sequence of points in time represents the journey duration. The path traveled by the vehicle is the route, which is generally the basis for calculating the fare. A critical aspect is the possibility that vehicles - e.g. buses, trams - are so close together at bus stations, traffic lights, or when driving next to each other that a user terminal receives data telegrams from several vehicles simultaneously.

[0010] A number of methods for this are known in the prior art. For example, EP 1 669 935 proposes a method in which a user terminal receiving data telegrams from multiple vehicles determines, based on the temporal change in the signal strength of the data telegrams, which data telegrams are "valid," i.e., originate from a vehicle in which the user is actually traveling. EP 1 669 935 teaches the user terminal to determine the vehicle being used in real time, i.e., while the vehicle is still in motion.

[0011] EP 2 658 291 A1 proposes a BIBO method using mass-market mobile devices. Using the sensors incorporated in such devices, the location of the device—e.g., the vehicle being used—can be determined without the mobile device needing to receive vehicle-specific data telegrams, i.e., no specific vehicle infrastructure needs to be set up for this. EP 2 658 291 A1 teaches determining the vehicle being used by a central computer, and thus not necessarily in real time. However, determining the vehicle being used without the device receiving vehicle-specific data telegrams is not very accurate and therefore highly questionable as a basis for fare calculation.

[0012] Furthermore, according to US 2015 / 0348334 A1, a method for generating travel data by a user's mobile device is known from the prior art. The mobile device receives data transmitted by one or more beacons of a transportation system.

[0013] US 2015 / 0235477 A1 discloses a method for automated fare calculation, according to which a beacon identifier and / or a vehicle identifier is sent to a mobile device from a beacon located in the vehicle. In addition, boarding and alighting times are recorded, allowing automated fare calculation to be performed on this basis, either by the mobile device itself or by a central computer.

[0014] From DE 10 2012 101 638 A1 a method and a system for determining means of transport / route data to a mobile radio device is known.

[0015] Finally, EP 2 811 444 A1 discloses a method and a device for determining the use of a public transport service.

[0016] The Task The invention therefore proposes a robust method that enables the determination of the location of a mobile terminal in a vehicle and ensures the authenticity of the data telegrams used for this purpose, even if the user terminals use open interfaces for the method.

[0017] To technically solve this problem, a method having the features of patent claim 1 is proposed. Further advantages and features are set out in the subclaims. Regarding the system, the invention proposes a system having the features of patent claim 11. Further advantages and features are set out in the subclaims.

[0018] According to the invention, at least one vehicle transmitter is installed in a vehicle. The at least one vehicle transmitter is configured to wirelessly transmit vehicle-specific data telegrams, which data telegrams uniquely identify the vehicle. Data telegrams are modulated radio signals containing digital data.

[0019] Vehicle data telegrams are those data telegrams whose digital data contain at least a system-wide, unique identifier of the vehicle whose vehicle transmitter sent the telegram. External data telegrams are those data telegrams whose digital data contain a vehicle identifier but are received in another vehicle. Thus, a data telegram can be a vehicle data telegram in the vehicle in which it was sent, but if it is receivable in another vehicle, it is a external data telegram. Furthermore, external data telegrams can arise from the improper transmission of data telegrams within a vehicle that do not belong to that vehicle.

[0020] In addition to the vehicle identification, vehicle data telegrams (and thus also external data telegrams) can contain further data such as date / time stamps, random numbers and / or location data of the vehicle.

[0021] According to an unclaimed embodiment, at least one vehicle receiver is configured to wirelessly receive data telegrams from within the vehicle and from outside the vehicle, to further process the data contained therein, and to forward it to a vehicle-mounted communication device, which in turn is configured to exchange data with a central computer. In a preferred embodiment, the vehicle-mounted communication device is the on-board computer of a vehicle, for example, the on-board computer of a bus, tram, subway, train, ship, taxi, or similar vehicle.

[0022] For the method according to the invention, the location of the vehicle is known to the on-board communications device; in practice, existing vehicle infrastructure, which supplies location data for the vehicle, is used to determine the vehicle location. Location data can be longitude and latitude, route kilometers for a journey, cell data from mobile communications networks in which the on-board communications device is operated, fare zones, or other data sets whose geographical resolution is sufficiently fine to map the fare system for fare calculation. Location data can thus be determined from global navigation satellite systems (such as GPS, Galileo, etc.), from the vehicle's odometers, from radio beacons or balises along the route, from triangulation data from mobile communications networks, or from any other suitable method for determining location.

[0023] Data communication between the vehicle-based communication device and the central computer can be permanently active, activated periodically, or activated depending on the vehicle's location or the number of data telegrams received. 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.

[0024] Mobile terminals within the meaning of the invention are portable units with at least one digital data processor, a digital data memory, a power supply, and communication means. Mobile terminals are configured to wirelessly receive data telegrams from within and outside the vehicle, further process the digital data contained therein, and forward them to the central computer. Mobile terminals can be specifically designed and manufactured for the purpose of the method according to the invention or, in a preferred embodiment, they can be mass-market mobile terminals such as smartphones, tablet computers, game consoles, laptop computers, netbooks, data glasses, smartwatches, or other devices worn close to the body, etc.

[0025] Data communication between a mobile device and the central computer can be permanently active, periodically activated, or activated depending on the location of the device or the number of data telegrams received. Data communication can be based on a digital cellular network (GSM, GPRS, UMTS, LTE) or a local radio data network such as a Wi-Fi, Bluetooth, or Bluetooth Low Energy (BLE) connection (via an on-board relay station, which in turn communicates with the central computer), or any other suitable wireless data connection.

[0026] According to an unclaimed embodiment, the further processing of the data received by the at least one vehicle receiver and the mobile terminals may comprise the following: leaving the data unchanged, supplementing the data with device-specific data or other data received or generated by the device (e.g., device identifier, device telephone number, time, location, checksum, meter readings), encrypting the data, masking the data (so-called "hashing"), storing the data or applying other data processing mechanisms customary in information technology to the data, as well as any combination of such handling.

[0027] External transmitters may be present that transmit external data telegrams. These external transmitters may be present in the vehicle itself, for example, if deceitful users attempt to disrupt or sabotage the BIBO system. However, the external transmitters may also be present outside the vehicle, for example if two buses equipped with the BIBO system according to the invention are parked next to each other at a traffic light or driving side by side in two lanes. It is essential to the method that the external data telegrams can be received in the same way by the mobile devices and the at least one vehicle receiver. The external data telegrams may contain external digital data that can be handled by the mobile devices and the at least one vehicle receiver in the same way as the digital vehicle data.In any case, it is essential for the method according to the invention that the mobile terminals can also receive external data telegrams and do not "know" and do not need to "know" that these signals are external to the vehicle, because the mobile terminals do not "know" for sure in which vehicle they are located.

[0028] According to an embodiment not claimed, 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 information (e.g. date and time) or they are supplemented by the vehicle receiver or the on-board computer with a current time information. The vehicle receiver or the on-board computer further supplements the data with a system-wide unique identifier of the host vehicle and the location of the vehicle.A digital vehicle reference data set is created from a received vehicle data telegram; each vehicle reference data set thus represents a data telegram that was receivable in the vehicle. The vehicle receiver or the on-board computer forwards the digital vehicle reference data sets to the on-board communication device. For this purpose, the vehicle receiver and the on-board communication device are networked. This network preferably uses an existing on-board network of the vehicle and can, for example, be a wired LAN, a data bus, a CAN bus, a WLAN, or any other suitable wired or wireless data connection within the vehicle. However, the vehicle receiver and / or the on-board communication device can also be components of the on-board computer.

[0029] A "vehicle" can also be a segment of a means of transport, such as a railcar, which has at least one vehicle transmitter and at least one vehicle receiver. A train consisting of several railcars thus constitutes several "vehicles" within the meaning of the invention.

[0030] The vehicle data telegrams are transmitted wirelessly by the vehicle transmitter in a data radio network for which the mobile devices are also set up, for example: Bluetooth, Bluetooth Low Energy, WLAN, ANT, WiMax, WPAN, ZigBee or Z-Wave.

[0031] The frequency with which the at least one vehicle transmitter transmits vehicle data telegrams determines the amount of data generated when carrying out the method according to the invention and thus also the network load in all networks involved in the method. In order to reduce the network load, the method according to the invention can take into account that more data telegrams do not necessarily lead to a better BIBO method (i.e., to better determination of the location of users in a vehicle). This is particularly the case when no one can get in or out anyway. This means that for a vehicle in motion, the at least one vehicle transmitter can transmit data telegrams less frequently, whereas in situations where passengers can currently get in or out or could have just gotten in or out, a more frequent transmission of vehicle data telegrams is particularly useful.The same may apply if the vehicle is located within a fare zone boundary. Accordingly, the repeated transmission of vehicle data telegrams by the at least one vehicle transmitter within the meaning of the invention may mean: transmission with constant time intervals between two transmissions, transmission with variable time intervals between two transmissions, transmission at time intervals that depend on at least one of the following exemplary criteria: driving speed, location of the vehicle within the fare zone of a fare system, whether the vehicle has reached or crossed fare zone boundaries, the status of the vehicle doors ("open" or "closed" or just closed, where "just closed" means a time of a few seconds after the last vehicle door has been closed, typically up to 5 seconds), and a combination of these and / or other criteria.

[0032] 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 elapse between the receipt of a data telegram and the transmission of the vehicle reference data set. The vehicle-side communication device can buffer 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.

[0033] As described above, according to the invention, 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; furthermore, the digital vehicle data can 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.

[0034] The system-wide unique identifier of the mobile terminal device can be a mobile phone number, a mobile phone 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 device to be identified.

[0035] In one embodiment of the method according to the invention, the mobile device can supplement the digital vehicle data record with its own location data in order to support the downstream journey reconstruction in the central computer with this data. The mobile device can perform this supplementation of the digital vehicle data records for each data record or only for some of the data records, for example when the BIBO app is switched on or when a first data telegram with a new vehicle identifier is received, or periodically, for example every 5 minutes, or periodically after a certain number of received data telegrams, for example every tenth data telegram. Location data of the mobile device can be longitude and latitude or cell data from mobile communication networks in which the mobile device is operated, or other location data that can be determined from the device configuration of the mobile device.Location data can be determined from global navigation satellite systems (such as GPS, Galileo, etc.), from triangulation data from mobile communication networks, from field strength data and / or access points from mobile communication networks, from access points or SSID information from WLAN or Bluetooth networks or any other method for determining location available in the mobile device.

[0036] 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, which here means that more than X minutes can elapse between the receipt of a data telegram and the transmission of the device data record. The mobile device can buffer the device data records and thus send a large number of device data records to the central computer in a bundle. This is particularly the case when the data connection between the mobile device and the central computer is not permanently active.The terminal device data records that the central computer receives from the mobile device are stored there in at least one database. The central computer receives corresponding terminal device data records from a plurality of mobile devices.

[0037] If the mobile device can also receive data telegrams from a transmitter outside the vehicle, the mobile device processes the received external data telegrams in exactly the same way as the received vehicle data telegrams: The digital external data from the external data telegrams contain a time stamp (e.g., date and time) or are supplemented by the mobile device with a current time stamp. Furthermore, the mobile device supplements the data with its unique identifier. Digital device data records are thus created from the received external data telegrams, provided with the identifier of the mobile device. These digital device data records are then sent to the central computer in the manner described above and stored there in at least one database.

[0038] In practice, a mobile terminal and a vehicle receiver in the same vehicle will not always receive exactly the same data telegrams; however, they will receive so many identical data telegrams that the central computer can reliably conclude (based on the terminal data sets and the vehicle reference data sets) that the mobile terminal is present in the vehicle.

[0039] The central computer receives vehicle reference data records from all vehicles participating in the process as soon as their on-board communication units transmit data records and the data records are receivable by the central computer via the external vehicle data network. Furthermore, the central computer receives terminal device data records from all mobile devices participating in the process as soon as these mobile devices transmit data records and the data records are receivable by the central computer via the mobile data network.

[0040] The central computer then determines for each mobile device which vehicle it traveled in, when, and where. The concatenation of consecutive locations of a mobile device in a moving vehicle thus represents a trip that can be billed. Billing can be done, for example, against a fare account maintained on the central computer or a season ticket stored there, or the trip can be invoiced to the user. Details of the actual fare billing are not the subject of the invention.

[0041] The central computer within the meaning of the method according to the invention can physically consist of one or more computer units (servers) and databases that are located at one location or at several geographical locations and connected to one another via a data network. The at least one geographical location of the central computer is not relevant to the method; in particular, the central computer and its at least one database can be part of at least one data center. In particular, the central computer and its at least one database can be configured as a virtual server. In particular, the central computer and its at least one database can be addressable via internet interfaces and configured as a "cloud" implementation.

[0042] From the process described so far, the following two types of data records are now stored in at least one database of the central computer: Terminal device data records: These are the data records that were forwarded from a mobile device to the central computer. These data records originate from the data telegrams of those vehicle transmitters that the mobile device was able to receive during a journey. These are data telegrams from the vehicle used for the journey, as well as data telegrams that originate from external transmitters and that were (at least temporarily) receivable by the terminal device in the vehicle used. As described above, each terminal device data record contains at least the identifier of the mobile device used, the vehicle identifier from the data telegram, and a timestamp. Each terminal device data record is therefore assigned to exactly one mobile device and indicates which data telegram the terminal device "heard" at a specific time.Vehicle reference data records: These are the data records that were forwarded from a vehicle (via the vehicle-side communication device) to the central computer. As described above, each vehicle reference data record contains at least the identification of the vehicle and a timestamp. Furthermore, the vehicle reference data record can contain the vehicle's location data. Each vehicle reference data record is thus assigned to exactly one vehicle and indicates which data telegram was "heard" in the vehicle at a specific time and location. The location can also be determined indirectly in the central computer via the route and time information.

[0043] The at least one database of the central computer contains a plurality of terminal device data records originating from a plurality of mobile terminal devices. Furthermore, the at least one database of the central computer contains a plurality of vehicle reference data records originating from a plurality of vehicles.

[0044] To create a journey for a specific mobile device, a chronological sequence of locations where the device was most likely located is reconstructed by comparing the associated device data records with all available vehicle reference data records. For each device data record, it is determined whether there is a concurrent vehicle reference data record and whether both data records originate from the same received data telegram.

[0045] This comparison is performed with all device data records of the one mobile device stored in at least one database that have not yet been assigned to a trip. The result is a chronological sequence of identical data telegrams that a vehicle receiver and the mobile device could "hear" the same data telegram at the same time. If there are a large number of matches, it becomes clear that the mobile device was traveling in a specific vehicle, and based on the timestamps and the sequence of vehicle locations (from the vehicle reference data records), it can be determined specifically when the mobile device traveled from where to where. This reconstructs a specific trip for the one specific device and can be billed.The comparison of the data sets of the end devices and the vehicle reference data sets can be carried out, for example, using correlation, regression and / or feature analyses / vectors and corresponding classifiers such as Bayes classifiers, maximum likelihood methods and / or artificial neural networks.

[0046] This trip reconstruction is performed for all device data records stored in at least one database of the central computer that have not yet been assigned to a trip. In this way, trips are gradually reconstructed for all device data records uploaded to the central computer. This involves considerable computational effort, which can be reduced at least at two points in the trip reconstruction as follows: Each device data record is associated with a user, a user account, and thus—at least after a period of participation in the BIBO process—a user history. Trip reconstruction on the central computer can leverage this history by first comparing a user's newly received device data records with the newly received vehicle reference data records that correspond to routes the user has frequently used in the past. This approach will allow a large number of regular users to reconstruct their current trip with less effort, because the trip reconstruction algorithm "knows" which vehicle reference data records it is most likely to successfully search.Once a journey reconstruction has been initiated for a mobile device and the first matches between device data sets and vehicle reference data sets have been found, a correspondingly optimized algorithm will first search for the matching vehicle reference data sets for the remaining device data sets, starting with the vehicle likely used. Thus, once a journey reconstruction has been initiated, the search for further matching vehicle reference data sets can be significantly narrowed down; after a large number of matches, the search is likely to narrow down to exactly one vehicle.

[0047] The inventive journey reconstruction 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.

[0048] Once the central computer has received the terminal device data sets and vehicle reference data sets, it can begin reconstructing the journey for the terminal device by comparing the data sets. If the terminal device data sets and vehicle reference data sets are sent to the central computer in real time—i.e., during the journey—the central computer can determine the location of the mobile device in the vehicle while the journey is still in progress and send a look-up table to the mobile device at least once. The look-up table can contain data about the current journey from a computer-based operations control system running on the central computer. From this, the app on the mobile device can extract current journey information and display it on the mobile device.The look-up table can, for example, contain data on the sequence of stops on the current journey, the names of the stops, expected arrival times of the vehicle at the stops, accessible connecting connections, weather data, warning data on weather or road conditions, etc. This data can be displayed to the app user as journey information.

[0049] The data in the look-up table can be static (e.g., from the timetable) or dynamic (based on current operating data from the operations control system), or a combination of static and dynamic data. The look-up table can be sent to the mobile device once during a trip or updated multiple times.

[0050] Updates can be performed by sending a fully updated look-up table to the mobile device or by incrementally updating parts of the look-up table. In particular, the look-up table can be updated when the trip reconstruction on the background system detects that the mobile device has switched from one vehicle to another.

[0051] As explained above, vehicle data telegrams contain in their digital data a system-wide, unique identifier of the vehicle whose vehicle transmitter sent the telegrams. In a particularly preferred embodiment of the method according to the invention, these digital data contain a code. This code can be a numeric number, a combination of letters, a mixture of numbers and letters, or any other data content suitable for data transmission, or a combination of ASCII characters. The code can originate from a random number generator and be regenerated time-dependently (e.g., every X minutes) or after a certain number X of data telegrams, optionally individually for each data telegram. In one embodiment, 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's location or from the route traveled.In a further embodiment, the code can be generated from a date / time stamp, e.g. as a hash value thereof.

[0052] In the event that the vehicle data telegrams contain the codes mentioned, these codes are forwarded to the central computer with the terminal device data sets and the vehicle reference data sets in the manner described.

[0053] In order for the central computer to be able to check whether the codes contained in the data sets originate from an authentic vehicle transmitter installed in the vehicle, there are two possibilities according to the invention: The code associated with the vehicle data telegram is generated in the vehicle (e.g., in the on-board computer). The data telegram is transmitted within the vehicle, and the data of the transmitted data telegram is sent as an additional control data telegram from the vehicle's communication device to the central computer. As described above, transmission to the central computer can occur in various timing modes, from "real time" to the subsequent transmission of bundled control data telegrams. The central computer thus maintains a record of all authentically transmitted data telegrams and the associated codes and can check the terminal device data records and the vehicle reference data records for the presence of the identical code.The code can be regenerated with each data telegram, at specific intervals, after certain distances have been traveled, when fare zone boundaries are reached, after the vehicle doors are opened or closed, etc. In this way, the code can be varied temporally, spatially, depending on specific events, or with each new data telegram. The code associated with the vehicle data telegram is generated in the central computer and made available to the vehicle's on-board computer, for example as a list of codes sorted by validity date and time, so that the code varies over time. When generating a vehicle data telegram, the on-board computer adds the currently valid code to the vehicle data telegram, taken from the list of codes according to the date and time.This variant has the advantage of eliminating the need for control data telegrams, thus reducing the data volume that must be sent from the vehicle's communications device to the central computer. Another advantage of this variant is that the central computer already knows the codes and can therefore verify the authenticity of the received terminal device data records with particular reliability. The list of codes can be made available to the vehicle's on-board computer when data communication between the vehicle's communications device and the central computer is enabled. In particular, the list of codes can be made available for a validity period of at least one working day of the vehicle.

[0054] In any case, the central computer checks the received terminal device data records and vehicle reference data records for the presence of the correct code. Those that pass the code are considered authentic and used for the journey reconstruction described above. Those that fail the code are ignored for journey reconstruction.

[0055] It is also possible to evaluate the number of negatively checked data records, whereby a frequent occurrence is an indication that the BIBO system may be exposed to abusive attacks.

[0056] 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.

[0057] In a preferred embodiment, Bluetooth transmitters are used as vehicle transmitters for the method according to the invention, which, in a particularly preferred embodiment, are configured as so-called Bluetooth Low Energy Beacons ("BLE Beacons"). BLE beacons have the advantage of being inexpensive and available on the mass market. However, this comes with the disadvantage that BLE beacons can be improperly introduced into a vehicle by third parties and transmit inauthentic data telegrams. This disadvantage is counteracted in the manner described above by a code in the data content of the data telegrams.

[0058] BLE beacons can be divided into two types: first, BLE beacons, whose data telegrams are receivable by a mobile device with a commercially available operating system in all operating modes, and second, BLE beacons, for which a mobile device must first be configured in order to receive data telegrams from them. For the purposes of the invention, commercially available operating systems are understood to include at least: Apple iOS, Google Android, Microsoft Windows Mobile, Microsoft Mobile Phone, Blackberry OS, Symbian OS, Firefox OS, Tizen, Aliyun OS, and their respective successors and further developments. Receiving data telegrams sent over the wireless Bluetooth network naturally requires that the Bluetooth function on the respective mobile device is switched on (activated).

[0059] In the embodiment with BLE beacons as vehicle transmitters, both types of BLE beacons are used: At least one first BLE beacon, as the first vehicle transmitter, repeatedly transmits first vehicle data telegrams via the BLE data protocol, which can be received by users' mobile devices in all operating modes, in particular even if a pre-installed app for implementing the BIBO method is not started on the device. In particular, the at least one first vehicle transmitter can be an iBeacon. The digital data of the first vehicle data telegram contains the type of communication application (here: determining the location of a mobile device in a vehicle), possibly an identifier for the vehicle operator, and possibly a vehicle identifier.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.

[0060] Since the variable data in a BLE radio data signal is very limited, it is proposed that 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 contain 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 stop 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.

[0061] Second, the data from the at least one first beacon identifies a UUID of the second vehicle transmitter, which is also implemented as a BLE beacon. For example, the UUID of the second vehicle transmitter can be formed as a function of a hash value of the variable data of the first vehicle data telegram. After receiving at least one first data telegram, an app is launched on a mobile device and knows which UUIDs to scan for in order to receive second data telegrams.

[0062] At least one second BLE beacon, as a second vehicle transmitter, repeatedly sends second vehicle data telegrams via the BLE data protocol, which can be received by mobile devices if they have previously received at least one associated first vehicle data telegram.

[0063] The second vehicle data telegrams contain at least one code. This code can be a numeric number, a combination of letters, a mixture of numbers and letters, or any other code suitable for data transmission, or a combination of ASCII characters. The code can originate from a random number generator and be regenerated over time (e.g., every X minutes) or after a certain number X of data telegrams, optionally individually for each data telegram. In one embodiment, 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's location or from the route traveled. In a further embodiment, the code can be generated from a date / time stamp, e.g., as a hash value thereof. Furthermore, the second vehicle data telegrams can contain data about the distance traveled by the vehicle, such as a mileage counter.If the maximum counter value is exceeded, the counter is restarted at the value 0. According to the invention, 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 within the available data volume in the BLE radio data signal.

[0064] For a BIBO procedure based on BLE beacons, it is also possible to authenticate the vehicle data telegrams using codes in the manner described above.

[0065] To carry out the procedure, both vehicle transmitters (i.e. both BLE beacons) are connected to the on-board computer of the vehicle, 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 process-compliant app.

[0066] It is possible that the app also receives first data telegrams from outside the vehicle and then searches for second data telegrams from outside the vehicle.

[0067] The mobile device's app writes a log file containing the sequence of extracted data from the received data telegrams, along with a timestamp. The mobile device's app forwards this data from the log file (both vehicle-specific and external data) to the central computer as device data records in the manner described above.

[0068] To secure the method, the invention further proposes that the data of the at least one first beacon be varied in each case. If this were not the case, an attack on the system could be launched by a perpetrator intercepting the (in this case constant) data content of a first beacon and replicating a system according to the invention with fake beacons and - for example - generating trips under a false operator number. If the data of the at least one first beacon is varied, the logical link between the first and second beacon is always re-established (coordinated by the on-board computer). The data of the at least one first beacon contains - as mentioned above - 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 route, train number, etc.), direction of travel, and the number of the next stop. In the worst case, this data is static, e.g., only the operator number and the vehicle number, because, for example, the vehicle infrastructure does not provide dynamic travel data. In this case, it is proposed to vary the data of at least one first beacon, e.g., with a time-varying random number or the hash of a date / time stamp, or similar.

[0069] The invention provides a method and a system with which the presence of a terminal, and thus of the user equipped with the terminal, in a vehicle can be automatically determined. This allows the use of the means of transport in relation to the mobile terminal and its user to be easily and automatically determined, and the necessary processing for calculating the color price and the like can then be performed. Further advantages and features of the description will become apparent from the following description with reference to the figures.

[0070] The following figures show Fig 1: an embodiment in which two vehicle transmitters are designed as BLE beacons in a bus Fig 2: the structure of a first and a second vehicle data telegram for the embodiment Fig 3: the exemplary reception of a sequence of nine vehicle data telegrams by a mobile terminal and by the vehicle receiver for the embodiment Fig 4: the exemplary data content of five terminal data sets for the embodiment Fig 5: the exemplary data content of five vehicle reference data sets for the embodiment.

[0071] The following statements are exemplary and not restrictive.

[0072] In Figure 1 An example of a system 100 in which the method according to the invention is applied is given. The example describes the embodiment with BLE beacons.

[0073] A bus 101 with the vehicle number "4711" is equipped with: a first vehicle transmitter 102, a second vehicle transmitter 103, and a vehicle receiver 104. The two vehicle transmitters 102 and 103 are each implemented as BLE beacons; the vehicle receiver 104 is configured to receive radio signals from both vehicle transmitters.

[0074] In particular, the first vehicle transmitter 102 is designed as a so-called iBeacon, whose radio signals are receivable by a mobile device running the iOS operating system by default and without special configuration as soon as the Bluetooth network is enabled on the device. This means that the mobile device is in so-called "monitoring" mode for iBeacons when its Bluetooth network is enabled.

[0075] The second vehicle transmitter 103 is a so-called travel beacon, whose radio signals can only be received by a mobile device if the device has been configured accordingly.

[0076] The two vehicle transmitters 102, 103 and the vehicle receiver 104 are connected via a data network to an on-board computer 105, which in turn is connected via a data network to a vehicle-side communication unit 106.

[0077] Furthermore, 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).

[0078] The vehicle-side communication unit 106 is connected to a central computer 109 via an external vehicle data network 108, in this example via a digital mobile radio network.

[0079] The vehicle contains mobile devices 110 belonging to users whose journeys are to be recorded and subsequently billed. The mobile devices 110 are connected to the central computer 109 via a mobile data network 111. The mobile data network 111 can be the same data network as the external vehicle data network 108.

[0080] For the present example, it is assumed that the mobile devices 110 are operated with the iOS operating system.

[0081] The first vehicle transmitter 102 periodically sends 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.

[0082] After receiving the first vehicle data telegram 301.1, the mobile terminal 110 is configured to search for second vehicle data telegrams, in such a way that the app on the mobile terminal continuously scans for second vehicle data telegrams.

[0083] The second vehicle transmitter 103 periodically sends a second vehicle data telegram 302.1 (the content of this second vehicle data telegram is in Fig. 2 explained). A mobile terminal 110 receives this second vehicle data telegram 302.1 and further periodically transmitted second vehicle data telegrams 302.1.

[0084] At the same time, the mobile device continues to monitor for and receive the periodically transmitted first vehicle data telegram 301.1, i.e., iBeacon radio signals.

[0085] Another bus 201 with the number "0815" is now located near bus 101, so that data telegrams according to the invention from this additional bus 201 can also be received on bus 101. This can occur in practice when driving in parallel lanes, at traffic lights, at bus stations, at stops, etc. The additional bus 201 similarly has a first vehicle transmitter 202 and a second vehicle transmitter 203. These periodically transmit vehicle data telegrams in the same way, which are "external to the vehicle" for trip recording in bus 101. These external data telegrams 301.2, 302.2 are received by the mobile terminal in exactly the same way as the vehicle data telegrams 301.1, 302.1.

[0086] The app of the mobile terminal 110 extracts data from the received vehicle data telegrams 301.1, 302.1 and the external data telegrams 301.2, 302.2. From the extracted data, the app writes a first 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 app of the terminal 110 forwards this data from the first log file (both vehicle-specific and external data) as terminal data records 400 via the mobile data network 111 to the central computer 109. The app does this as soon as 100 data telegrams 302.1, 302.2 from the second vehicle transmitter 103, 203 have been received, but at the latest every ten minutes. The app only sends those terminal device data records 400 to the central computer 109 that have not yet been sent. For this purpose, each data record sent to the central computer 109 is marked with an identifier in the first log file so that it is not sent a second time.(The content of the terminal data records 400 is stored in . Fig. 4 explained).

[0087] In the same way as the mobile terminal, 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 on-board computer causes the vehicle-side communication unit 106 to forward these data from the second log file (vehicle-specific and external data) as vehicle reference data records 500 via the external vehicle data network 108 to the central computer 109.The on-board computer 105 does this as soon as 100 data telegrams 302.1, 302.2 from the second vehicle transmitter 103, 203 have been received, but at least every ten minutes. The on-board computer 105 only sends the data contents of those data telegrams that have not yet been sent to the central computer 109. For this purpose, each data record sent to the central computer 109 is marked with an identifier in the second log file so that it is not sent a second time. (The content of the vehicle reference data records 500 is stored in . Fig. 5 explained).

[0088] As soon as the central computer 109 has received terminal device data records 400 and vehicle reference data records 500, it begins the journey reconstruction for the terminal device 110 by comparing the data records 400, 500. The terminal device data records 400 and vehicle reference data records 500 are sent in real time to the central computer 109, so that the central computer 109 determines the location of the terminal device 110 in bus 101 while the journey is still in progress and sends a look-up table 600 to the mobile terminal device 110. The look-up table contains data about the current journey from a computer-aided operations control system, which is executed in the central computer 109. From this, the app on the mobile terminal device extracts journey information and displays it to the user on the mobile terminal device.

[0089] Figure 2 describes the structure of a first and a second vehicle data telegram for the embodiment.

[0090] In the exemplary embodiment, 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.

[0091] The first vehicle data telegram 301 contains a UUID 303 according to the iBeacon standard (16 bytes of data length) and so-called major and minor data 304 according to the iBeacon standard (4 bytes of data length). The UUID data 303 are selected such that a mobile device recognizes first vehicle data telegrams 301 as originating from an iBeacon, i.e., they comply with the iBeacon standard. The major and minor data 304 are freely configurable, and the iBeacon receives this data from the bus's on-board computer via a data network connection.

[0092] The major and minor data 304 serve two purposes: First, they contain data for recording the bus's journeys. In this example, this includes the operator number (a system-specific identifier for the transport company), the bus number, and a random number that is changed by the bus computer every 5 minutes. The app on the mobile device extracts this data; it becomes part of the data that the app writes to the first log file.

[0093] Second, the major and minor data 304 identify the service UUID 305 of the second vehicle transmitter. In the example, the service UUID 305 of the second vehicle transmitter is formed as a function of a hash value from the major and minor data 304. After receiving at least a first data telegram 301, the app knows which service UUIDs 305 it needs to scan for in order to receive second data telegrams 302.

[0094] 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.

[0095] The second vehicle data telegram 302 contains a ServiceUUID 305, which is formed from the major and minor data 304 according to the hash value function; the second vehicle data telegrams 302 can thus be found and received by the app, as previously stated. The second vehicle data telegrams 302 contain, as payload data for trip detection, a GeoLog 306 of 4 bytes in length and a RunCounter of 2 bytes in length. In this exemplary embodiment, the GeoLog 306 is formed from a hash value of the current location of the vehicle. The GeoLog 306 represents the code contained in the vehicle data telegram as described above; in this exemplary embodiment, the code is therefore location-dependent. In this exemplary embodiment, the RunCounter 307 maps the bus's route in multiples of 100 meters. If the maximum counter value is exceeded, the RunCounter is restarted at the value 0.The app on the mobile device also extracts this data; it also becomes part of the data that the app writes to the first log file.

[0096] In the same way as the app on the mobile device, the vehicle receiver also receives first and second data telegrams 301, 302. It also extracts trip recording data from the major and minor values ​​304, from the GeoLog 306, and from the RunCounter 307; these become part of the data that the on-board computer writes to the second log file.

[0097] 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". In the example of Fig. 3 There is temporarily another bus "0815" nearby, so that its data telegrams are also temporarily received on bus "4711".

[0098] In Fig. 3 The mobile device first receives a first data telegram 301.1 from the iBeacon of bus "4711". It then scans for associated travel beacons and receives two second data telegrams 302.1 from bus "4711". (Data telegrams # 1 - 3 from Figure 3 ).

[0099] 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 )

[0100] Bus "0815" approaches the used bus "4711," and its data telegrams become receivable on bus "4711." The mobile device receives a first data telegram 301.2 from the iBeacon of bus "0815." It then scans for associated travel beacons and receives a second data telegram 302.2 from bus "0815." (Data telegrams #7-8 from Figure 3 ).

[0101] The mobile device receives a first data telegram 301.1 from the iBeacon of bus "4711". It now scans again for associated travel beacons from bus "4711". (Data telegram # 9 from Figure 3 ).

[0102] This means that, based on the received first data telegrams 301 (from iBeacons), the mobile device searches for corresponding second data telegrams 302 (from travel beacons). Conversely, no second data telegram 302 can be received from a travel beacon unless the corresponding first data telegram 301 has previously been received from an iBeacon.

[0103] 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.

[0104] In exactly the same way, the vehicle receiver in the exemplary embodiment receives these nine data telegrams.

[0105] Figure 4 shows the exemplary data content of five terminal data records 400 for the embodiment. In Figure 3The 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.

[0106] From the Fig. 3 The mobile device now creates the device data records 400 according to the received data telegrams Fig. 4 The terminal device data record 400 consists partly of received data 401 and partly of the terminal device's own data 402.

[0107] According to the example, the mobile device app extracts the received GeoLog 403, received RunCounter 404, and received vehicle number 405 (all shown in decimal notation) from the received data telegrams. This data is supplemented with data added by the mobile device, here the device number 406 (in the example: the telephone number) and a date / time stamp 407. According to the exemplary embodiment, this data represents the core data content of the device data records 400. It will be clear to those skilled in the art that in practice, device data records may contain other, additional, or fewer data fields.

[0108] In Fig. 4 The terminal data record 499 originates from the last received second data telegram (from the neighboring bus "0815"). Therefore, the value of RunCounter 404 jumps in data record 499 compared to the other values, and the receiving vehicle number 405 is different in data record 499 than in the other data records.

[0109] Figure 5 shows the exemplary data content of five vehicle reference data sets 500 for the exemplary embodiment. As previously explained for the mobile terminal, a vehicle's on-board computer can only create and send to the central computer as many vehicle reference data sets 500 as it has received second data telegrams.

[0110] From the Fig. 3 The on-board computer now creates the vehicle reference data sets 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.

[0111] According to the example, 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, in this case, the on-board computer's own GeoLog 506, its own RunCounter 507, its own Vehicle Number 508 (all shown in decimal notation), its own location data 509, and a date / time stamp 510. According to the exemplary embodiment, 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.

[0112] If, as in the example, the vehicle receiver receives exactly the same data telegrams as a mobile terminal, then the received data 501 in the vehicle reference data sets 500 is equal to the received data 401 in the terminal data sets 400.

[0113] In Fig. 5 The vehicle reference data set 599 originates from the last received second data telegram (from the neighboring bus "0815"). Therefore, the received run counter 504 and the received vehicle number 505 differ from the corresponding vehicle data 507, 508. Reference symbol

[0114] 100System 101Vehicle (here: bus "4711") 102First vehicle transmitter (here: iBeacon) 103Second vehicle transmitter (here: Travelbeacon) 104Vehicle receiver 105On-board computer 106Vehicle-side communication unit 107GPS receiver 108External vehicle data network 109Central computer 110Mobile devices 111Mobile data network 201External vehicle (here: another bus "0815") 202External first vehicle transmitter (iBeacon) 203External second vehicle transmitter (here: Travelbeacon) 301First vehicle data telegram 301.1First vehicle data telegram from bus 4711 301.2External first vehicle data telegram from bus 0815 302Second vehicle data telegram 302.1Second vehicle data telegram from bus 4711 302.2Second vehicle data telegram from bus 0815 303UUID of a first vehicle data telegram 304Major and minor data of a first vehicle data telegram 305Service UUID of a second vehicle data telegram 306GeoLog of a second vehicle data telegram 307RunCounter of asecond vehicle data telegram 400 terminal data sets 401 received data of the terminal data sets 402 device-specific data of the terminal data sets 403 received GeoLog data of the terminal data sets 404 received RunCounter data of the terminal data sets 405 received vehicle numbers of the terminal data sets 406 terminal identifier 407 device-specific timestamp 499 example terminal data set 500 vehicle reference data sets 501 received data of the vehicle reference data sets 502 vehicle-specific data of the vehicle reference data sets 503 received GeoLog data of the terminal data sets 504 received RunCounter data of the terminal data sets 505 received vehicle numbers of the terminal data sets 506 vehicle-specific GeoLog data 507 vehicle-specific RunCounter data 508 vehicle number 509 vehicle-specific Location data (here: longitude / latitude) 510 Vehicle-specific timestamp 599 Example vehicle reference data set 600 Look-up table

Claims

1. Method for automatically detecting the presence of a user equipped with a mobile terminal device in a vehicle, wherein at least a vehicle transmitter is installed in the vehicle and wherein the mobile terminal device is connected via a mobile data network to a central computer, the method comprising the steps of: a) repeated transmission, by the vehicle transmitter, of at least one vehicle data telegram, wherein the vehicle data telegram at least contains a system-wide unique identification of the vehicle, b) receiving, by the mobile terminal device, at least one vehicle data telegram, c) creating, by the mobile terminal device, a terminal device data set from the vehicle data telegram, wherein the terminal device data set at least contains the system-wide unique identification of the vehicle, a system-wide unique identification of the terminal device and a time stamp, d) transmitting, by the mobile terminal device, the at least one terminal device data set to the central computer, e) receiving, by the central computer, the at least one terminal device data set from at least one mobile terminal device, f) determining, by the central computer, the presence of the mobile terminal device in the vehicle based on the terminal device data set, characterized in that the vehicle data telegram contains a code in addition to the system-wide unique identification of the vehicle, that the code is varied in a time-dependent manner, that the code is generated on the vehicle side and is transmitted to the central computer from a vehicle-side communication device, and that the central computer determines authenticity of the received at least one terminal device data set on the basis of the code.

2. Method according to claim 1, characterized in that the method steps are repeated.

3. Method according to any one of the preceding claims, characterized in that the code is generated in location-dependent manner.

4. Method according to claim 1, characterized in that for each vehicle data telegram a new code is generated.

5. Method according to any one of the preceding claims, characterized in that the vehicle-side communication device stores several codes and transmits them to the central computer in a bundle.

6. Method according to any one of the preceding claims, characterized in that after step c) the mobile terminal device stores several terminal device data sets and transmits them to the central computer in a bundle.

7. Method according to any one of the preceding claims, characterized in that a Bluetooth beacon is used as a vehicle transmitter.

8. Method according to any one of the preceding claims, characterized in that a Bluetooth Low Energy Beacon is used as a vehicle transmitter.

9. Method according to any one of the preceding claims, characterized in that the method steps are controlled by a mobile application ("app") on the mobile terminal device.

10. Method according to any one of the preceding claims, characterized in that the mobile terminal device is a smartphone, a tablet computer, a gaming device, a laptop computer, a netbook, data goggles or a smart watch.

11. System for automatically detecting the presence of a user equipped with a mobile terminal device in a vehicle, the system consisting of at least one vehicle, at least one vehicle transmitter in the vehicle, a central computer with at least one data base, a mobile data network a vehicle-side communication device and an external vehicle data network, wherein the at least one vehicle transmitter is configured to repeatedly transmit vehicle data telegrams, wherein a vehicle data telegram contains at least one system-wide unique identification of the vehicle, wherein the mobile terminal device is configured to receive vehicle data telegrams and to create terminal device data sets from received vehicle data telegrams, wherein a terminal device data set at least contains the system-wide unique identification of the vehicle, a system-wide identification of the terminal device and a time stamp, wherein the mobile terminal device is configured to transmit the terminal device data sets to the central computer, wherein the central computer is configured to receive the terminal device data sets, and wherein the central computer is configured to determine the presence of the mobile terminal device in the vehicle on the basis of the terminal device data set, characterized in that the vehicle data telegrams contain a code in addition to the system-wide unique identification of the vehicle, that the code is generated on the vehicle-side before its transmission to the central computer, that the code is varied in a time-dependent manner, that the vehicle-side communication device is configured to transmit codes created on the vehicle-side to the central computer, and that the central computer is configured to determine authenticity of the received terminal device data sets on the basis of the code.

12. System according to claim 11, characterized in that the vehicle transmitter is a Bluetooth beacon.

13. System according to claim 11, characterized in that the vehicle transmitter is a Bluetooth Low Energy beacon.

14. System according to any one of claims 11 to 13, characterized in that the mobile terminal device is controllable by a mobile application ("app").

15. System according to any one of claims 11 to 14, characterized in that the mobile terminal device is a smartphone, a tablet computer, a gaming device, a laptop computer, a netbook, data goggles or a smart watch.