EP3358533B1 - Procédé de détermination automatique de l'utilisation de véhicules - Google Patents

Procédé de détermination automatique de l'utilisation de véhicules Download PDF

Info

Publication number
EP3358533B1
EP3358533B1 EP17154547.8A EP17154547A EP3358533B1 EP 3358533 B1 EP3358533 B1 EP 3358533B1 EP 17154547 A EP17154547 A EP 17154547A EP 3358533 B1 EP3358533 B1 EP 3358533B1
Authority
EP
European Patent Office
Prior art keywords
vehicle
data
terminal device
central computer
telegrams
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
EP17154547.8A
Other languages
German (de)
English (en)
Other versions
EP3358533A1 (fr
Inventor
Elmar Noll
Manfred Feiter
Stephan Bichmann
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 EP17154547.8A priority Critical patent/EP3358533B1/fr
Publication of EP3358533A1 publication Critical patent/EP3358533A1/fr
Application granted granted Critical
Publication of EP3358533B1 publication Critical patent/EP3358533B1/fr
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 the use of vehicles. Essentially, it is about the automatic determination of the use of paid means of transport as the basis for billing the fare. It is assumed that the presence of a mobile device in the vehicle indicates whether a user is using the vehicle. For several years, there have been different approaches in the state of the art to bill 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 recorded in the user terminal against a (previously charged) driving value, or the data is transmitted to a central computer, where the trip is determined and the fare is calculated. These procedures are known under the keyword “Be-In / Be-Out”, “BIBO” for short.
  • the disadvantage of the unidirectional BIBO process is that the vehicle infrastructure does not know, or at least not immediately, which user media is currently present in the vehicle;
  • the disadvantage of the bidirectional BIBO method is that sending data telegrams back and forth means a significant amount of radio traffic in the vehicle and that the sending and receiving processes have to be synchronized in a complex manner by the vehicle infrastructure in order to avoid signal collisions that lead to data loss in relevant areas extent.
  • 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).
  • BIBO procedures can basically be carried out with different types of user devices.
  • Dedicated devices can be used that are specifically set up to receive data telegrams from the vehicle infrastructure and, if necessary, also send data telegrams back to the vehicle infrastructure.
  • 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 energy supply. If dedicated user devices are used, they must not only be manufactured specifically for this purpose and distributed to the users, but it must also be ensured that the user devices either have sophisticated energy management so that their energy supply - usually via a battery - is sufficient for a long time, or the user devices must have a battery that needs to be recharged by the users.
  • Another advantage of using mass-market 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.
  • a further difficulty of all BIBO systems is to reliably determine that a user has undertaken a specific journey with a user device - be it a dedicated device for a ticket system or a mass-market mobile device. To do this, it must be reliably determined that the user was in a specific vehicle with his device over a sequence of times. The sequence of times represents the duration of the journey. The distance that the vehicle has traveled is the route, which is usually 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 device receives data telegrams from several vehicles at the same time.
  • EP 1 669 935 A method is proposed in which a user terminal, which receives data telegrams from several vehicles, uses the temporal change in the signal strength of the data telegrams to determine which data telegrams are "valid", that is, they come from a vehicle in which the user is actually traveling. This teaches EP 1 669 935 determining the vehicle being used by the user device in real time, i.e. while the vehicle is still driving.
  • EP 2 658 291 A1 A BIBO method with mass-market mobile devices is proposed, in which the location of the device - for example the vehicle in use - can be determined by using the sensor technology present in such devices, without the mobile device sending vehicle-specific data telegrams needs to be received, meaning that no specific vehicle infrastructure needs to be set up for this.
  • This teaches EP 2 658 291 A1 the determination of the vehicle used by a central computer and therefore not necessarily in real time.
  • determining which vehicle is being used without the end device receiving vehicle-specific data telegrams is not very accurate and is therefore certainly questionable as a basis for fare billing.
  • the object of the invention is therefore to propose a robust method that enables the location of a mobile terminal in a vehicle to be determined and ensures the authenticity of the data telegrams used for this purpose, even if the user terminals use open interfaces for the method.
  • At least one vehicle transmitter and at least one vehicle receiver are installed in a vehicle.
  • the at least one vehicle transmitter is set up to wirelessly send the vehicle's own data telegrams
  • Data telegrams clearly identify the vehicle.
  • Data telegrams are modulated radio signals that contain digital data.
  • Vehicle data telegrams are data telegrams whose digital data contain at least one system-wide unique identifier of the vehicle whose vehicle transmitter sent the telegrams.
  • External data telegrams are data telegrams whose digital data contain an identifier for a vehicle, but which are received in another vehicle. This means that a data telegram can be a vehicle data telegram in the vehicle in which it was sent, but if it can be received in another vehicle, then it is an external data telegram there.
  • external data telegrams can arise because data telegrams that do not belong to this vehicle are improperly sent within a vehicle.
  • vehicle data telegrams can contain other data such as date/time stamp, random numbers and/or location data of the vehicle.
  • the at least one vehicle receiver is set up to receive the vehicle's own and external data telegrams wirelessly and to further process the data contained therein and forward it to a vehicle-side communication device, which in turn is set up to exchange data with a central computer.
  • the vehicle-side communication device is the on-board computer of a vehicle, for example the on-board computer of a bus, a tram, a subway, a train, a ship, a taxi or a comparable vehicle.
  • the location of the vehicle is known to the vehicle-side communication device for the method according to the invention;
  • existing vehicle infrastructure is used to determine the vehicle location, which provides location data for the vehicle.
  • Location data can be longitude and latitude, route kilometers for a trip, cell data from mobile communication networks in which the vehicle-side communication device is operated, tariff zones or other data sets whose geographical resolution is sufficiently fine to map the tariff system for fare calculation.
  • Location data can thus be determined from global navigation satellite systems (such as GPS, Galileo, etc.), from vehicle route counters, from radio beacons or balises along the route, from triangulation data from mobile communication networks or any other suitable method for determining location.
  • 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.
  • Data communication can be based on one digital cellular network (GSM, GPRS, UMTS, LTE), a WLAN 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 in the area of the data connection, for example at a bus station, train station, at a jetty or at stops that are equipped with a corresponding data connection.
  • Mobile terminals within the meaning of the invention are portable units with at least one digital data processor, a digital data storage, a power supply and communication means.
  • Mobile devices are set up to wirelessly receive vehicle-specific and non-vehicle data telegrams, further process the digital data contained therein and forward it to the central computer.
  • Mobile devices can be designed and manufactured specifically for the purpose of the method according to the invention or, in a preferred embodiment, they can be mass-market mobile devices such as smartphones, tablet computers, game consoles, laptop computers, netbooks, data glasses, smart watches or other devices worn close to the body, etc.
  • the data communication between a mobile terminal and the central computer can be permanently active or activated periodically or depending on the location of the terminal or the number of data telegrams received.
  • the data communication can be based on a digital mobile network (GSM, GPRS, UMTS, LTE) or on a local radio data network such as a WLAN, Bluetooth or Bluetooth Low Energy (BLE) connection (via a vehicle-side relay station, which in turn is connected to the central computer communicates) or on any other suitable wireless data connection.
  • GSM digital mobile network
  • GPRS Global System for Mobile communications
  • UMTS Long Term Evolution
  • LTE local radio data network
  • BLE Bluetooth Low Energy
  • Further processing of the received data by the at least one vehicle receiver and the mobile terminals can include, within the meaning of the invention: leaving the data unchanged, supplementing the data with data belonging to the device or other data received or generated by the device (e.g. identifier of the device, telephone number of the device, time, location, checksum, counter readings), encrypting the data, masking the data (so-called “hashing"), storing the data or applying other data processing mechanisms standard in information technology to the data, as well as any combination of such treatments.
  • Non-vehicle transmitters can be present in the vehicle itself, for example when users who are willing to deceive attempt to disrupt or sabotage the BIBO system.
  • the non-vehicle transmitters can also be present outside the vehicle, for example caused by two buses that are equipped with the BIBO system according to the invention standing next to each other at a traffic light or driving next to each other in two lanes. It is essential to the process that the external data telegrams can be received in the same way by the mobile terminal devices and the at least one vehicle receiver.
  • the external data telegrams contain external digital data that can be handled by the mobile terminals and the at least one vehicle receiver in the same way as the digital vehicle data.
  • 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 which vehicle they are located.
  • At least one vehicle transmitter repeatedly sends out vehicle data telegrams in a vehicle. These vehicle data telegrams are at least partially received by the at least one vehicle receiver, ie at least one vehicle receiver receives at least one complete vehicle data telegram.
  • the vehicle receiver reads the digital vehicle data contained therein from 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 with a current time specification by the vehicle receiver or the on-board computer.
  • the vehicle receiver or the on-board computer also supplements the data with a system-wide unique identifier of the 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 record therefore represents a data telegram that could be received in the vehicle.
  • the vehicle receiver or the on-board computer forwards the digital vehicle reference data sets to the vehicle-side communication device.
  • the vehicle receiver and the vehicle-side communication device are networked in terms of data technology. This networking preferably uses an existing on-board network of the vehicle and can be, for example, a wired LAN, a data bus, a CAN bus, a WLAN or any other suitable wired or wireless data connection within the vehicle.
  • vehicle receiver and/or vehicle-side communication device can also be components of the on-board computer.
  • a “vehicle” in the sense of the invention can also be a segment of a means of transport, such as a wagon, which has at least one vehicle transmitter and at least one vehicle receiver.
  • a train consisting of several wagons is therefore several “vehicles” in the sense of the invention.
  • the vehicle data telegrams are sent wirelessly by the vehicle transmitter in a radio data network for which the mobile devices are also set up, for example: Bluetooth, Bluetooth Low Energy, WLAN, ANT, WiMax, WPAN, ZigBee or Z-Wave.
  • the frequency with which the at least one vehicle transmitter sends out 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.
  • 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 a better determination of the location of users in a vehicle). This is particularly the case if no one can get on or off anyway. This means that for a vehicle in motion, the at least one vehicle transmitter can send out data telegrams less frequently, while it is particularly useful to send out vehicle data telegrams more frequently in situations in which passengers can currently get on or off or have just got on or off.
  • the repeated transmission of vehicle data telegrams by the at least one vehicle transmitter in the sense of the invention can mean: transmission with constant time intervals between two Transmission processes, transmission with variable time intervals between two transmission processes, transmission at time intervals that depend on at least one of the following exemplary criteria: driving speed, location of the vehicle within the tariff area of a fare system, reaching or exceeding tariff zone boundaries by the vehicle, condition 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 was closed, typically up to 5 seconds) as well as a combination of such and / or other criteria.
  • the vehicle-side communication device sends the received digital vehicle reference data sets to the central computer. This can be done in real time, i.e. immediately after the vehicle-side communication device has received a vehicle reference data set from one of the vehicle receivers, in quasi-real time, which is to be understood here as meaning that between receiving a data telegram and sending the vehicle reference data set up to X Minutes pass. Furthermore, the sending of a vehicle reference data set by the vehicle-side communication device can take place with a time delay, which is to be understood here as meaning that more than X minutes of time elapse between receiving a data telegram and sending the vehicle reference data set.
  • the vehicle-side communication device can temporarily store the vehicle reference data sets and thus send a plurality of vehicle reference data sets to the central computer in a bundled manner. This is particularly the case if 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.
  • the vehicle receiver 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 indication (e.g. date and time) or they are supplemented with a current time by the vehicle receiver or the on-board computer. Further the vehicle receiver or the on-board computer supplements the data with the unique identifier of your own vehicle and the location of your own vehicle.
  • a received external data telegram becomes a digital external data record, but in each case it is provided with the identification of your own vehicle, i.e. the vehicle in which the vehicle receiver is installed.
  • Vehicle reference data sets have been created from the external data telegrams received, which in turn are sent to the central computer in the manner described above and stored there in the at least one database.
  • vehicle receivers If there are several vehicle receivers in a vehicle, they will almost always receive identical data telegrams (vehicle's own and external to the vehicle). Exceptions relate to data telegrams that could be received by one vehicle receiver, but not by another vehicle receiver in the same vehicle. A plurality of vehicle receivers in a vehicle will therefore generate a large number of identical vehicle reference data sets ("doublets") for forwarding to the central computer. According to the invention, in order to reduce the data volume and the network load, it is therefore proposed to first store the data sets of all vehicle receivers installed in a vehicle in the vehicle's on-board computer, delete duplicates and then send the remaining data sets to the central computer as described.
  • At least one vehicle transmitter in a vehicle repeatedly sends out vehicle data telegrams.
  • These vehicle data telegrams are at least partially received by a user's mobile terminal, ie the mobile terminal receives at least one complete vehicle data telegram.
  • the mobile device reads the digital vehicle data contained therein from 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 mobile device with a current time information;
  • the digital vehicle data can contain the vehicle location.
  • the mobile device supplements the data with its system-wide unique identifier.
  • a digital terminal data record is created from the data of a received vehicle data telegram.
  • the system-wide unique identifier of the mobile 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 uses his BIBO app, with which the method according to the invention is carried out, registered, a user identification under which the BIBO app was purchased, or any other system-wide unique identifier that allows the mobile device to be identified.
  • the mobile terminal can supplement the digital vehicle data set with its own location data in order to support the downstream trip reconstruction in the central computer with this data.
  • the mobile device can make this addition to the digital vehicle data sets for each data set or only for part of the data sets, for example when switching on the BIBO app or when receiving a first data telegram with a new vehicle ID 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 such as can be determined from the device equipment 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 anyone other method for determining location available in the mobile device.
  • global navigation satellite systems such as GPS, Galileo, etc.
  • triangulation data from mobile communication networks
  • field strength data and/or access points from mobile communication networks from access points or SSID information from WLAN or Bluetooth networks or anyone other method for determining location available in the mobile device.
  • the mobile device sends the device data records to the central computer. This can be done in real time, i.e. immediately after the mobile device has received a data telegram, in quasi-real time, which is meant here to mean that up to X minutes of time elapse between receiving a data telegram and sending the device data set. Furthermore, the sending of a terminal data record by the mobile terminal can take place with a time delay, What is meant here is that more than X minutes elapse between receiving a data telegram and sending the terminal data record.
  • the mobile device can temporarily store the device data sets and thus send a large number of device data sets to the central computer in a bundle. This is particularly the case if the data connection between the mobile device 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 sets from a large number of mobile devices.
  • 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 indication (e.g. date and time) or they are supplemented by the mobile device with a current time.
  • the mobile device also supplements the data with its unique identifier.
  • Digital terminal data sets are created from the external data telegrams received, provided with the identifier of the mobile terminal, which in turn are sent to the central computer in the manner described above and stored there in the at least one database.
  • a mobile device 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 presence of the mobile device in the vehicle can be reliably concluded in the central computer (based on the terminal data sets and the vehicle reference data sets).
  • the central computer receives vehicle reference data sets from all vehicles involved in the process as soon as their vehicle-side communication units send data sets and the data sets can be received by the central computer via the external vehicle data network. Furthermore, the central computer receives terminal data records from all mobile terminals involved in the process as soon as these mobile terminals send data records and the data records are sent via the mobile data network for the Central computers can be received.
  • the central computer now determines for each mobile device in which vehicle it was driven, when and where.
  • the chaining of successive locations of a mobile device in a moving vehicle therefore represents a journey that can be billed.
  • Billing can be done, for example, against a fare account maintained on the central computer or a recurring ticket stored there, or the journey can be invoiced to the user. Details of the actual fare billing are not the subject of the invention.
  • the central computer in the sense of the method according to the invention can physically consist of one or more computer units (servers) and databases that are set up at one location or at several geographical locations and are connected to one another via a data network.
  • the at least one geographical location of the central computer is not relevant;
  • the central computer and its at least one database can be part of at least one data center.
  • the central computer and its at least one database can be set up as a virtual server.
  • the central computer and its at least one database can be addressable via Internet interfaces and set up as a “cloud” implementation.
  • a temporal sequence of locations at which the device has most likely been located is now reconstructed by comparing the associated device data sets with all available vehicle reference data sets. For this purpose, it is determined for each terminal data record whether there is a simultaneous vehicle reference data record and whether both data records come from the same received data telegram. Each match indicates that a vehicle receiver and the mobile device were able to “hear” the same data telegram at the same time. It is irrelevant whether the data telegram in question came from the vehicle itself or was external to the vehicle.
  • This comparison is carried out with all the terminal data sets of the one mobile terminal that are stored in the at least one database and have not yet been assigned to a trip, and the result is a chronological sequence of identical data telegrams that a vehicle receiver and the mobile terminal "hear" the same data telegram at the same time " could.
  • the comparison of the data sets of the end devices and the vehicle reference data sets can be carried out, for example, via correlation, regression and/or feature analyzes/vectors and corresponding classifiers such as Bayes classifiers, maximum likelihood methods and/or via artificial neural networks.
  • the trip reconstruction according to the invention on the central computer for each mobile device used is therefore particularly "robust" and insensitive to possible data telegrams from outside the vehicle that a terminal potentially receives, since the central computer knows via the vehicle reference data sets which data telegrams - including those from outside the vehicle - belong to the reconstructed ride.
  • the central computer can begin the journey reconstruction for the terminal by comparing the data sets. If the terminal data sets and vehicle reference data sets are sent to the central computer in "real time" - i.e. while driving - then it can determine the location of the mobile device in the vehicle while the vehicle is still driving and send a look-up table to the mobile device send at least once.
  • the look-up table can contain data about the current trip from a computer-based operations control system, which is executed in the central computer. From this, the app on the mobile device can extract current trip information and display it to the user on the mobile device.
  • the look-up table can contain, for example, data on the sequence of stops on the current trip, the names of the stops, expected arrival times of the vehicle at the stops, accessible connections, weather data, warning data about weather or road conditions, etc. This data is available to the user of the app can be displayed as trip information.
  • the data in the look-up table can be static (e.g. from the timetable) or dynamic (based on the current operating data from the operations control system) or a combination of static and dynamic data.
  • the look-up table can be connected to the mobile device can be sent once during a journey or updated several times. Updates can be performed by sending a complete 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 determines that the mobile device has changed from one vehicle to another.
  • vehicle data telegrams contain in their digital data a system-wide unique identifier of the vehicle whose vehicle transmitter sent the telegrams.
  • this digital data contains 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 come from a random number generator and be regenerated depending on time (e.g. every X minutes) or after a certain number of data telegrams, if necessary individually for each data telegram.
  • 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, for example as a hash value from it.
  • This code is used to check the authenticity of the vehicle data telegrams received from the mobile devices and the at least one vehicle receiver in the central computer. This prevents transmitters that are improperly installed in a vehicle from sending out fake data telegrams that may not be recognized as such by the central computer.
  • the central computer checks the received terminal data sets and vehicle reference data sets for the presence of the correct code, and the positively checked data sets are considered authentic and used for the journey reconstruction described above. Negatively checked data sets are ignored for the journey reconstruction.
  • the authenticity check according to the invention becomes particularly secure if the codes are changed frequently.
  • the authenticity check is then not based on the agreement of one or a few codes in several terminal and vehicle reference data sets, but on a sequence of frequently varied codes, so that good procedural security is achieved even with relatively short codes.
  • Bluetooth transmitters are used as vehicle transmitters for the method according to the invention, which in a particularly preferred embodiment are set up as so-called Bluetooth low energy beacons ("BLE beacons").
  • BLE beacons have the advantage of being inexpensive and available on the mass market.
  • BLE beacons can be improperly inserted into a vehicle by third parties and can send out non-authentic data telegrams. This disadvantage is countered in the manner described above by a code in the data contents of the data telegrams.
  • BLE beacons can be differentiated into two types: first BLE beacons, whose data telegrams can be received by a mobile device with a standard operating system in all operating modes, and second BLE beacons, for which a mobile device must first be configured so that they can be used by them can receive data telegrams.
  • first BLE beacons whose data telegrams can be received by a mobile device with a standard operating system in all operating modes
  • second BLE beacons for which a mobile device must first be configured so that they can be used by them can receive data telegrams.
  • the following are at least understood to be commercially available operating systems: Apple iOS, Google Android, Microsoft Windows Mobile, Microsoft Mobile Phone, Blackberry OS, Symbian OS, Firefox OS, Tizen, Aliyun OS and their respective successors and developments.
  • Receiving data telegrams that are sent in the wireless Bluetooth network naturally requires that the Bluetooth function is switched on (activated) on the respective mobile device.
  • At least a first BLE beacon is the first vehicle transmitter to repeatedly send out first vehicle data telegrams via the BLE data protocol, which can be received by the user's mobile devices in all operating modes, in particular even if the device does not have a pre-installed app for carrying out the BIBO method has started.
  • 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 operator of the vehicle and, if necessary, 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 are dependent on at least one the following criteria: speed of travel, location of the vehicle within the tariff area of a fare system, reaching or exceeding tariff zone boundaries by the vehicle, condition 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 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, the number of the next one 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 amount.
  • the operator number a system identifier for the transport company
  • the vehicle number e.g. bus route, train number, etc.
  • Direction of travel e.g. bus route, train number, etc.
  • Direction of travel e.g. bus route, train number, etc.
  • the number of the next one Breakpoint e.g. bus route, train number, etc.
  • Direction of travel e.g. bus route, train number
  • the data of the at least one first beacon identifies a UUID of the second vehicle transmitter, which is also designed as a BLE beacon.
  • 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.
  • At least a 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.
  • the second vehicle data telegrams contain at least its code.
  • This code can be a numeric number, a combination of letters, a mixture of numbers and letters or another code suitable for data transmission or a combination of ASCII characters.
  • the code can come from a random number generator and be regenerated depending on time (e.g. every X minutes) or after a certain number of data telegrams, if necessary individually for each data telegram.
  • the code can be generated from status data, for example from the current location data of the vehicle, for example 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, for example as a hash value from it.
  • the second vehicle data telegrams can contain data about the distance traveled by the vehicle, such as a route counter. If the maximum counter value is exceeded, the counter is restarted at value 0.
  • the second vehicle data telegrams can contain any combination of data that can be used to safely carry out the method according to the invention and that can be represented in the BLE radio data signal within the scope of the available data amount.
  • both vehicle transmitters i.e. both BLE beacons
  • the vehicle's on-board computer which carries out the change in 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 is derived from a method according to the method App can be taken from the first vehicle data telegrams.
  • the app can also receive first data telegrams from outside the vehicle and subsequently search for second data telegrams from outside the vehicle.
  • the app on the mobile device writes a log file in which the sequence of extracted data from the received data telegrams, provided with a time stamp, is recorded.
  • the mobile device app forwards this data from the log file (vehicle-specific and non-vehicle data) to the central computer as device data records in the manner described above.
  • a vehicle receiver installed in the vehicle can extract the data from receiving first and second vehicle data diagrams, log it with a time stamp and pass it on to the central computer as vehicle reference data sets as described above.
  • the data of the at least one first beacon be varied in each case according to the method. If this were not the case, an attack on the system could be launched by a perpetrator listening to 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 beacons is always re-established (coordinated by the on-board computer).
  • the data of the at least one first beacon contains - as above mentioned - data for trip recording, such as the operator number (a system 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, 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 journey data.
  • it is proposed to vary the data of the at least one first beacon for example with a time-varying random number or the hash of a date/time stamp or similar.
  • the invention provides a method and a system with which the presence of a terminal and thus the user equipped with the terminal in a vehicle can be automatically determined.
  • the use of the means of transport in relation to the mobile phone terminal and its user can therefore be automatically determined in a simple manner and the necessary processing for color price calculation and the like can then be carried out. Further advantages and features of the description result from the following description based on the figures.
  • Figure 1 an example of a system 100 is given in which the method according to the invention is used.
  • the example describes the embodiment with BLE beacons.
  • Installed in a bus 101 with the vehicle number "4711" are: a first vehicle transmitter 102, a second vehicle transmitter 103 and a vehicle receiver 104.
  • the two vehicle transmitters 102, 103 are each designed as BLE beacons; the vehicle receiver 104 is set up to receive radio signals from both vehicle transmitters.
  • the first vehicle transmitter 102 is designed as a so-called iBeacon, the radio signals of which can be received by a mobile terminal with the iOS operating system as standard and without any special configuration as soon as the Bluetooth network is switched on on the terminal.
  • the mobile device is in so-called “monitoring” mode for iBeacons when its Bluetooth network is switched on.
  • 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.
  • the two vehicle transmitters 102, 103 and the vehicle receiver 104 are connected via data network to an on-board computer 105, which in turn is connected via data network to a vehicle-side communication unit 106.
  • the on-board computer 105 is connected via data network to a GPS receiver 107, so that the current location of the bus 101 is known in the on-board computer 105 as location data (longitude and latitude).
  • the vehicle-side communication unit 106 is connected to a central computer 109 via a external vehicle data network 108 connected via data network, in this example via a digital mobile radio network.
  • the mobile terminals 110 In the vehicle there are mobile terminals 110 of users whose journey must be recorded and billed later.
  • the mobile terminals 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.
  • the mobile devices 110 are operated with the iOS operating system.
  • 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 explained).
  • 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 mobile terminal 110 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.
  • 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 of the periodically sent second vehicle data telegrams 302.1.
  • the mobile device continues to “monitor” for the periodically transmitted first vehicle data telegram 301.1, i.e. for iBeacon radio signals, and also receives these.
  • bus 201 with the number "0815" near bus 101, so that data telegrams according to the invention from this further bus 201 can also be received in bus 101.
  • the other bus 201 has a first vehicle transmitter 202 and a second vehicle transmitter 203 in the same way. These periodically send vehicle data telegrams in the same way, which are "external to the vehicle” for trip recording in bus 101 " are.
  • 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.
  • 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 (vehicle-specific and non-vehicle data) as terminal data sets 400 to the central computer 109 via the mobile data network 111. 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 no later than every ten minutes.
  • the app only sends those terminal data sets 400 to the central computer 109 that have not yet been sent.
  • 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 in Fig. 4 explained).
  • the vehicle receiver 104 also receives the vehicle data telegrams 301.1, 302.1 and external data telegrams 302.1, 301.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 provides 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 this data from the second log file (vehicle-specific and non-vehicle data) to the central computer 109 as vehicle reference data sets 500 via the external vehicle data network 108.
  • the on-board computer 105 does this as soon as 100 data telegrams 302.1, 302.2 from the second vehicle transmitter 103, 203 are received but no later than every ten minutes.
  • the on-board computer 105 only sends the data contents of those data telegrams 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 second log file so that it is not sent a second time. (The content of the vehicle reference data sets 500 is in Fig. 5 explained).
  • the central computer 109 As soon as the central computer 109 has received terminal data sets 400 and vehicle reference data sets 500, it begins the journey reconstruction for the terminal 110 by comparing the data sets 400, 500.
  • the terminal data sets 400 and vehicle reference data sets 500 are sent to the central computer in real time 109 sent so that it detects the location of the terminal 110 in bus 101 while the vehicle is still driving and sends a look-up table 600 to the mobile terminal 110.
  • the look-up table contains data about the current trip from a computer-based operations control system, which is executed in the central computer 109.
  • the app on the mobile device extracts trip information from this and displays it to the user on the mobile device.
  • Figure 2 describes the structure of a first and a second vehicle data telegram for the exemplary embodiment.
  • the first vehicle data telegram 301 comes from an iBeacon. It can therefore be received by mobile devices with the iOS operating system without having to be specially configured; The Bluetooth radio network simply needs to be activated on the respective device.
  • the first vehicle data telegram 301 contains a UUID 303 according to the iBeacon standard (16 byte data length) and so-called major and minor data 304 according to the iBeacon standard (4 byte data length).
  • the UUID data 303 are selected so that a mobile terminal recognizes first vehicle data telegrams 301 as coming from an iBeacon, i.e. they correspond to 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.
  • the major and minor data 304 serve two purposes:
  • the operator number a system identifier for the transport company
  • the bus number a random number that is changed by the bus computer every 5 minutes.
  • the app on the mobile device extracts this data; they become part of the data the app writes to the first log file.
  • the major and minor data 304 identify the second vehicle transmitter's ServiceUUID 305.
  • the ServiceUUID 305 of the second vehicle transmitter is formed as a function of a hash value from the major and minor data 304.
  • the app After receiving at least a first data telegram 301, the app knows which ServiceUUIDs 305 it has to scan for in order to receive second data telegrams 302 .
  • 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 travel beacon) via a data network connection, whose second data telegrams 302 the app searches for.
  • the second vehicle data telegram 302 contains a ServiceUUID 305, which is formed from the major and minor data 304 according to the function of the hash value; According to what was said above, the second vehicle data telegrams 302 can be found and received by the app.
  • the second vehicle data telegrams 302 contain a GeoLog 306 of 4 bytes in length and a RunCounter of 2 bytes in length as user data for trip detection.
  • 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 in the sense of the description above; In the exemplary embodiment, the code is location-dependent.
  • the RunCounter 307 maps the route of the bus 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; they also become part of the data that the app writes to the first log file.
  • 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 data for trip recording, this becomes part of the data that the on-board computer writes into 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 on bus “4711”; the vehicle receiver is that of the bus "4711".
  • the vehicle receiver is that of the bus "4711”.
  • Fig. 3 the mobile device first receives a first data telegram 301.1 from the iBeacon of the bus “4711”. It now scans for associated travel beacons and receives two second data telegrams 302.1 from the bus "4711”. (Data telegrams # 1 - 3 out Figure 3 ).
  • the bus's on-board computer changes the random number in the major and minor values of the iBeacon and the associated ServiceUUID of the travel beacon.
  • the iBeacon's data telegrams change.
  • the mobile terminal receives such a modified first data telegram 301.1 and then two further second data telegrams 302.1. (Data telegrams # 4 - 6 out Figure 3 )
  • Bus “0815” comes close to the used bus "4711", and its data telegrams can be received in bus "4711".
  • the mobile device receives a first data telegram 301.2 from the iBeacon of the “0815” bus. It now scans for associated travel beacons and receives a second data telegram 302.2 from the bus "0815”. (Data telegrams # 7 - 8 out Figure 3 ).
  • the mobile device again receives a first data telegram 301.1 from the iBeacon of the bus “4711”. It now scans again for associated travel beacons from bus “4711”. (Data telegram # 9 out Figure 3 ).
  • the mobile terminal searches for associated second data telegrams 302 (from travel beacons). Conversely, no second data telegram 302 can be sent from one Travelbeacon can be received if the associated first data telegram 301 has not been received from an iBeacon beforehand.
  • the mobile device is always ready to receive the first data telegrams 301 from iBeacons in accordance with the Bluetooth standard for the iOS operating system, provided of course that its Bluetooth radio network is switched on.
  • the vehicle receiver in the exemplary embodiment receives these nine data telegrams.
  • Figure 4 shows the exemplary data content of five terminal data sets 400 for the exemplary 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 trip reconstruction was partly contained in the first data telegrams and partly in the second data telegrams.
  • This means that a mobile terminal can only create and send to the central computer as many terminal data sets 400 as it has received second data telegrams, because only receiving a second data telegram provides the database for a complete terminal data set 400.
  • the mobile device now creates the device data records 400 according to the received data telegrams Fig. 4 .
  • the terminal data record 400 consists partly of received data 401 and partly of the terminal 402's own data.
  • the mobile device app extracts the data of received GeoLog 403, received RunCounter 404 and received vehicle number 405 (all shown in decimal representation) from the received data telegrams.
  • This data is supplemented with data that the mobile device adds, here the device number 406 (in the example: the telephone number) and a date/time stamp 407.
  • these data represent the core of the data content of the device data sets 400.
  • terminal data sets may contain other, additional or fewer data fields.
  • the terminal data record 499 comes from the last received second data telegram (from the neighboring bus “0815”). That's why 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.
  • 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 sets 500 according to the data telegrams received 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 data of received GeoLog 503, received RunCounter 504 and received vehicle number 505 (all shown in decimal representation) from the received data telegrams.
  • This data is supplemented with data that the on-board computer adds, here your own GeoLog 506, your own RunCounter 507, your own vehicle number 508 (all shown in decimal representation), your own location data 509 and a date/time stamp 510.
  • These data are in accordance with The exemplary embodiment represents the core of the data content of the vehicle reference data sets 500. It will be clear to those skilled in the art that in practice vehicle reference data sets can contain other, additional or fewer data fields.
  • 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.
  • the vehicle reference data record 599 comes from the last received second data telegram (from the neighboring bus "0815"). That's why they give way receive RunCounter 504 and the received vehicle number 505 from the corresponding own data of the vehicle 507, 508.

Landscapes

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

Claims (17)

  1. Procédé de détection automatique de la présence d'un utilisateur équipé d'un terminal mobile dans un véhicule, dans lequel au moins un émetteur de véhicule, au moins un récepteur de véhicule et au moins un dispositif de communication pour la communication avec un ordinateur central sont installés dans le véhicule, le récepteur de véhicule et le dispositif de communication côté véhicule étant mis en réseau en termes de technologie de données et le terminal mobile étant connecté en termes de technologie de données à l'ordinateur central par l'intermédiaire d'un réseau de données mobiles,
    le procédé comprenant les étapes suivantes:
    a) transmission répétée, par l'émetteur de véhicule, d'au moins un télégramme de données du véhicule,
    b) réception, par l'au moins un récepteur de véhicule, d'au moins un télégramme de données du véhicule,
    c) création, par l'au moins un récepteur de véhicule, d'un ensemble de données de référence du véhicule à partir du télégramme de données du véhicule,
    d) envoi, par le dispositif de communication côté véhicule, de l'ensemble de données de référence du véhicule à l'ordinateur central,
    e) réception, par le terminal mobile, d'au moins un télégramme de données du véhicule,
    f) création, par le dispositif terminal mobile, d'un ensemble de données du dispositif terminal à partir du télégramme de données du véhicule,
    g) envoi, par le terminal mobile, de l'ensemble de données du terminal à l'ordinateur central,
    h) réception, par l'ordinateur central, d'au moins un ensemble de données du terminal provenant d'au moins un terminal mobile et d'au moins un ensemble de données de référence du véhicule provenant d'au moins un véhicule,
    i) déterminer, par l'ordinateur central, la présence du terminal mobile dans le véhicule au moyen des ensembles de données du terminal et des ensembles de données de référence du véhicule,
    dans lequel un télégramme de données du véhicule contient au moins un identifiant unique à l'échelle du système du véhicule,
    dans lequel un ensemble de données du terminal contient au moins un identifiant unique à l'échelle du système du terminal et un horodatage, et
    dans lequel un ensemble de données de référence du véhicule contient au moins l'identifiant unique à l'échelle du système du véhicule et un horodatage.
  2. Procédé selon la revendication 1, caractérisé en ce que les étapes du procédé sont exécutées de manière répétée.
  3. Procédé selon l'une quelconque des revendications précédentes, caractérisé par les étapes supplémentaires suivantes si des télégrammes de données provenant d'un émetteur hors du véhicule peuvent également être reçus par l'au moins un récepteur de véhicule:
    j) réception, par l'au moins un récepteur de véhicule, d'au moins un télégramme de données provenant d'un émetteur hors du véhicule,
    k) création, par l'au moins un récepteur de véhicule, d'un ensemble de données de référence du véhicule à partir de l'au moins un télégramme de données reçu de l'émetteur hors du véhicule,
    l) envoi, par le dispositif de communication côté véhicule, de l'ensemble de données de référence du véhicule créé à partir d'au moins un télégramme de données reçu de l'émetteur hors du véhicule, à l'ordinateur central.
  4. Procédé selon l'une quelconque des revendications précédentes, caractérisé par les étapes supplémentaires suivantes, si des télégrammes de données provenant d'un émetteur hors du véhicule peuvent également être reçus par le terminal mobile:
    m) création, par le terminal mobile, d'au moins un télégramme de données provenant d'un émetteur hors du véhicule,
    n) création, par le dispositif terminal mobile, d'un ensemble de données du dispositif terminal à partir d'au moins un télégramme de données reçu de l'émetteur hors du véhicule,
    o) envoi à l'ordinateur central, par le dispositif terminal mobile, de l'ensemble de données du dispositif terminal créé à partir d'au moins un télégramme de données reçu de l'émetteur hors du véhicule.
  5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que, après l'étape c) et/ou k), le dispositif de communication côté du véhicule stocke plusieurs ensembles de données de référence du véhicule et les envoie à l'ordinateur central sous forme d'ensembles de données groupées.
  6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que, après l'étape f) et/ou n), le dispositif terminal mobile stocke plusieurs ensembles de données du dispositif terminal et les envoie à l'ordinateur central sous forme d'ensembles de données groupées.
  7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'émetteur du véhicule est un Beacon Bluetooth.
  8. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'émetteur du véhicule est un Beacon Bluetooth Low Energy.
  9. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les étapes du procédé sont commandées sur le terminal mobile par une application mobile ("app").
  10. Procédé selon l'une quelconque des revendications précédentes, caractérisé par le fait que le terminal mobile est un smartphone, une tablette, un appareil de jeu, un ordinateur portable, un netbook, des lunettes intelligentes ou une smartwatch.
  11. Système de détection automatique de la présence d'un utilisateur équipé d'un terminal mobile dans un véhicule, le système comprenant
    au moins un véhicule
    au moins un émetteur dans le véhicule,
    au moins un récepteur de véhicule dans le véhicule,
    un dispositif de communication embarqué dans le véhicule,
    un réseau externe de données de véhicule,
    un réseau de données mobile et
    un ordinateur central comprenant au moins une base de données,
    dans lequel au moins un émetteur de véhicule est configuré pour transmettre de manière répétée des télégrammes de données du véhicule,
    dans lequel au moins un récepteur de véhicule est configuré pour recevoir des télégrammes de données du véhicule et pour créer des ensembles de données de référence du véhicule à partir des télégrammes de données du véhicule reçus,
    le dispositif de communication côté véhicule est configuré pour transmettre, par le dispositif de communication côté véhicule, les ensembles de données de référence du véhicule à l'ordinateur central,
    le terminal mobile est configuré pour recevoir des télégrammes de données du véhicule et créer des ensembles de données du terminal à partir des télégrammes de données du véhicule reçus,
    le terminal mobile est configuré pour transmettre, par le réseau de données mobiles, l'ensemble de données du terminal à l'ordinateur central,
    l'ordinateur central est configuré pour recevoir les ensembles de données de référence du véhicule et les ensembles de données du dispositif terminal,
    l'ordinateur central est configuré pour déterminer la présence de l'appareil terminal mobile dans le véhicule au moyen des ensembles de données de l'appareil terminal reçus et des ensembles de données de référence du véhicule reçus,
    dans lequel le télégramme de données du véhicule contient un identifiant unique à l'échelle du système du véhicule,
    dans lequel un ensemble de données relatives à l'appareil terminal contient au moins un identifiant unique à l'échelle du système de l'appareil terminal et un horodatage, et
    dans lequel un ensemble de données de référence du véhicule contient l'identifiant unique à l'échelle du système du véhicule et un horodatage.
  12. Système selon la revendication 11, caractérisé en ce que le récepteur de véhicule est configuré pour créer des ensembles de données de référence du véhicule à partir de télégrammes de données reçus d'un émetteur hors du véhicule.
  13. Système selon l'une des revendications 11) à 12), caractérisé en ce que le terminal mobile est configuré pour créer des ensembles de données de référence du véhicule à partir de télégrammes de données reçus d'un émetteur hors du véhicule.
  14. Système selon l'une des revendications 11) à 13), caractérisé en ce que l'émetteur du véhicule est un Beacon Bluetooth.
  15. Système selon l'une des revendications 11) à 14), caractérisé en ce que l'émetteur du véhicule est un Beacon Bluetooth Low Energy.
  16. Système selon l'une des revendications 11) à 15), caractérisé en ce que le procédé est commandé sur le terminal mobile par une application mobile ("app").
  17. Système selon l'une des revendications 11) à 16), caractérisé en ce que le terminal mobile est un smartphone, une tablette, un appareil de jeu, un ordinateur portable, un netbook, des lunettes intelligentes ou une montre intelligente.
EP17154547.8A 2017-02-03 2017-02-03 Procédé de détermination automatique de l'utilisation de véhicules Active EP3358533B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP17154547.8A EP3358533B1 (fr) 2017-02-03 2017-02-03 Procédé de détermination automatique de l'utilisation de véhicules

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP17154547.8A EP3358533B1 (fr) 2017-02-03 2017-02-03 Procédé de détermination automatique de l'utilisation de véhicules

Publications (2)

Publication Number Publication Date
EP3358533A1 EP3358533A1 (fr) 2018-08-08
EP3358533B1 true EP3358533B1 (fr) 2024-03-27

Family

ID=58158771

Family Applications (1)

Application Number Title Priority Date Filing Date
EP17154547.8A Active EP3358533B1 (fr) 2017-02-03 2017-02-03 Procédé de détermination automatique de l'utilisation de véhicules

Country Status (1)

Country Link
EP (1) EP3358533B1 (fr)

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19957660A1 (de) 1998-11-30 2000-07-20 Albrecht Joachim Verfahren zur Abrechnung des Fahrpreises bei der Benutzung öffentlicher Verkehrsmittel
EP1667074B1 (fr) 2004-12-02 2019-10-30 mcity GmbH Méthode automatique de détecter l'utilisation des vehicules payants et de facturer le prix du voyage
US9544075B2 (en) * 2012-02-22 2017-01-10 Qualcomm Incorporated Platform for wireless identity transmitter and system using short range wireless broadcast
EP2657900A1 (fr) 2012-04-24 2013-10-30 Scheidt & Bachmann GmbH Procédé de détermination automatique d'informations utiles
EP2658291B1 (fr) 2012-04-24 2018-06-13 Scheidt & Bachmann GmbH Procédé de détermination automatique du lieu de résidence d'une personne
US20150235477A1 (en) * 2014-02-19 2015-08-20 Swyft Technologies Inc. Automatic Wireless Transportation Monitoring and Transactions for Mobile Devices
GB2527499A (en) * 2014-05-29 2015-12-30 Mastercard International Inc Travel data of transport system users

Also Published As

Publication number Publication date
EP3358533A1 (fr) 2018-08-08

Similar Documents

Publication Publication Date Title
EP2624233B1 (fr) Procédé de contrôle dans un système de péage routier
EP2660793B1 (fr) Procédé et dispositifs destinés à l'identification d'un véhicule utilisant un lieu
EP2709051B1 (fr) Procédé de traitement électronique d'une infraction routière et unité embarquée à cet effet
EP1669934A1 (fr) Méthode automatique de détecter l'utilisation des vehicules payants et de facturer le prix de voyage
DE102012101638A1 (de) Verfahren und System zur Übermittlung von Verkehrsmittel-/Fahrstreckendaten in einem Verkehrsmittel an ein Mobilfunkgerät und zur Ermittlung von abrechnungsrelevanten Daten
EP2325807B2 (fr) Procédé et dispositifs de production d'informations de péage dans un système de péage routier
DE102018126363A1 (de) Psm-mitteilungsbasierte einrichtungserkennung für ein fahrzeugmaschennetzwerk
DE102018221933A1 (de) Verteiltes Datenaustauschsystem für ein Fahrzeug
EP2500869B1 (fr) Procédé de mise à disposition de services de données en fonction du lieu
EP2541502A1 (fr) Procédé de détermination du paiement automatique dans un système de péage routier
DE102009054795A1 (de) Fahrzeug-zu-X Kommunikation über mobile Geräte, die mit dem Fahrzeug verbunden sind
EP2690601A2 (fr) Procédé de contrôle de péage et installations de contrôle de péage ainsi que le système de péage doté des installations de contrôle de péage de ce type
WO2017167568A1 (fr) Procédé et système de détection de la présence et/ou de détermination du prix de transport d'un passager d'un véhicule
EP2490183B1 (fr) Appareil de véhicule, réseau ad hoc et procédé pour un système de péage routier
EP3358533B1 (fr) Procédé de détermination automatique de l'utilisation de véhicules
CN204801823U (zh) 列控设备动态监测系统
EP3358532A1 (fr) Procédé de détermination automatique de l'utilisation de véhicules
DE102013226532A1 (de) Verfahren zur Vorbereitung und Durchführung einer Fahrt einer Mehrzahl zu einem Verbund zusammengeschlossener Fahrzeuge und Kommunikationssystem
DE10015069A1 (de) Straßenbenutzungsgebühren-Abrechnungssystem
DE102014201156A1 (de) Verfahren und Vorrichtung zum Melden eines Kennzeichens eines gesuchten Fahrzeugs
EP3817406B1 (fr) Procédé de fonctionnement d'une application de service installée sur un dispositif terminal mobile
EP3211605A1 (fr) Dispositif de vehicule, systeme, dispositif cote route et procede d'execution d'au moins une transaction
EP3317848A1 (fr) Système et procédé de mise à disposition d'informations concernant des possibilités de transport sur un appareil électronique d'un utilisateur
DE102016124007A1 (de) Verfahren zur Übertragung einer Nachricht
DE102010033478A1 (de) Identifikation von Teilnehmern in Nahkommunikationsnetzen

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: 20210527

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

Free format text: STATUS: EXAMINATION IS IN PROGRESS

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: 20231011

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: 502017015958

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