WO2017190794A1 - Système de circulation - Google Patents

Système de circulation Download PDF

Info

Publication number
WO2017190794A1
WO2017190794A1 PCT/EP2016/060171 EP2016060171W WO2017190794A1 WO 2017190794 A1 WO2017190794 A1 WO 2017190794A1 EP 2016060171 W EP2016060171 W EP 2016060171W WO 2017190794 A1 WO2017190794 A1 WO 2017190794A1
Authority
WO
WIPO (PCT)
Prior art keywords
peer
vehicle
module
application
traffic
Prior art date
Application number
PCT/EP2016/060171
Other languages
English (en)
Inventor
Carsten STÖCKER
Original Assignee
Rwe International Se
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 Rwe International Se filed Critical Rwe International Se
Priority to EP16726486.0A priority Critical patent/EP3453005A1/fr
Priority to PCT/EP2016/060171 priority patent/WO2017190794A1/fr
Publication of WO2017190794A1 publication Critical patent/WO2017190794A1/fr

Links

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/01—Detecting movement of traffic to be counted or controlled
    • G08G1/0104—Measuring and analyzing of parameters relative to traffic conditions
    • G08G1/0108—Measuring and analyzing of parameters relative to traffic conditions based on the source of data
    • G08G1/0112—Measuring and analyzing of parameters relative to traffic conditions based on the source of data from the vehicle, e.g. floating car data [FCD]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • G06F21/35—User authentication involving the use of external additional devices, e.g. dongles or smart cards communicating wirelessly
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • 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/06—Arrangements for road pricing or congestion charging of vehicles or vehicle users, e.g. automatic toll systems
    • G07B15/063—Arrangements for road pricing or congestion charging of vehicles or vehicle users, e.g. automatic toll systems using wireless information transmission between the vehicle and a fixed station
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00—Individual registration on entry or exit
    • G07C9/00174—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys
    • G07C9/00571—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys operated by interacting with a central unit
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/01—Detecting movement of traffic to be counted or controlled
    • G08G1/0104—Measuring and analyzing of parameters relative to traffic conditions
    • G08G1/0137—Measuring and analyzing of parameters relative to traffic conditions for specific applications
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/14—Traffic control systems for road vehicles indicating individual free spaces in parking areas
    • G08G1/141—Traffic control systems for road vehicles indicating individual free spaces in parking areas with means giving the indication of available parking spaces
    • G08G1/144—Traffic control systems for road vehicles indicating individual free spaces in parking areas with means giving the indication of available parking spaces on portable or mobile units, e.g. personal digital assistant [PDA]
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/14—Traffic control systems for road vehicles indicating individual free spaces in parking areas
    • G08G1/145—Traffic control systems for road vehicles indicating individual free spaces in parking areas where the indication depends on the parking areas
    • G08G1/148—Management of a network of parking areas
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • the invention relates to a traffic system comprising at least one vehicle and at least one sensor module.
  • the invention relates also to methods, an arrangement for a vehicle, a vehicle, and a peer-to-peer application.
  • Traffic systems for providing traffic information to one or more vehicles or to navigation module(s) of respective vehicles are known from prior art.
  • a typical prior art system 100 is shown in figure 1.
  • the depicted traffic system 100 usually comprises a plurality of vehicles 102, 104.
  • each vehicle 102, 104 comprises a transceiver module 112.
  • the transceiver module 112 is connected to a navigation module 114.
  • a central instance 106, such as a server 106 is adapted to send traffic information data to the navigation module 114 via a suitable communication channel 118 and the transceiver module 112.
  • the traffic information data may comprise current traffic status data about the traffic situation of the traffic routes of the vehicles 102, 104. For instance, traffic jam information can be included in the sent traffic information.
  • a vehicle may comprise a sensor module 121 e.g. in form of a GPS (Global Positioning System) sensor. Such a sensor may be included in the navigation module 114.
  • the sensor module 121 is configured to detect the current location of a vehicle 102, 104 based on a communication with a satellite system 110. For instance, via a specific communication channel 120 and the transceiver module, respective location parameter values can be received by the vehicles 102, 104.
  • a conventional navigation module 114 is configured to calculate an optimal traffic path/route for each vehicle 102, 104 based on the received traffic information and the received location parameter of the vehicle 102, 104.
  • Environmental data e.g. video data, temperature, air quality, precipitation, humidity, traffic density data, traffic way damages or congestions
  • a sensor module 121 of the vehicle 104 may also be configured to detect a further motion parameter (besides the location parameter) relating to the vehicle 104 in form of the current velocity of the vehicle 104.
  • the transceiver module 112 is configured to regularly transmit the motion parameters (current location and current velocity) of the vehicle 104 to a further central server 108 via communication channel 123. It shall be understood that central server 106 and central server 108 may be realized by one server.
  • the central server 108 is configured to evaluate the motion parameter values received from the one or more vehicle(s) 104 and additionally traffic information received from further sources 126, such as traffic information providers. The evaluated data is used by the central server 106 to prepare and transmit traffic information to the vehicles 102, 104, as described above.
  • traffic systems mobile terminals (operated while using a vehicle) such as a smart phone or mobile embedded device can be used instead of navigation or communication modules built into a vehicle via a fixed installation.
  • a central subsystem a central process and/or a central organization or instance is provided in order to manage and provide the traffic information and to control a traffic action.
  • the evaluation and transmission of traffic information are centrally controlled by a central subsystem, a central process and/or a central organization or instance.
  • a corresponding traffic system is realized according to prior art by a client-server structure.
  • the central organization or instance is created by one or a plurality of central servers.
  • a server of this kind or a platform can be distributed and located on different computing devices, for example.
  • This means that a virtual server can be realized by a cloud.
  • a centrally arranged database can be provided.
  • a central instance/server is configured to evaluate motion data of user's vehicles and to transmit, based on the evaluation, traffic information to the vehicles.
  • the central server is used as a confidential instance for the vehicle's data.
  • the central instance such as a server or a platform, defines the rules.
  • the central server ensures that the processes are carried out correctly for all entities/vehicles involved. In other words, a central instance prevents tampering by one of the participating entities and/or by third parties.
  • server-client structures of this kind particularly the server (or platform), apart from the high transaction costs, is that the central instance or central server manages the confidential user data of the users of vehicles.
  • a persistent problem affecting the central instance is that of protecting the user data stored on one server or a plurality of servers from access by unauthorized third parties.
  • a high degree of security expenditure is required in order to prevent user data (e.g. registered identifications), billing data, location data of the user, etc. from being tampered. This in turn leads to higher transaction costs.
  • the object of the present invention is to provide a traffic system which simplifies an operation of the traffic system and, at the same time, offers a high level of security.
  • the traffic system comprises at least one vehicle.
  • the traffic system comprises at least one sensor module configured to detect at least one motion parameter relating to the vehicle.
  • the traffic system comprises at least one peer-to- peer module assigned to the vehicle and configured to communicate with at least one peer-to-peer application of at least one peer-to-peer network.
  • the peer-to-peer module is configured to transmit at least the detected motion parameter to the peer- to-peer application.
  • the peer-to-peer module is configured to receive at least traffic information data from the peer-to-peer application.
  • a traffic action can be easily performed and controlled - without a central instance - by means of a peer-to-peer application of a peer-to-peer network and a peer-to-peer module assigned to the vehicle.
  • the peer-to-peer module is capable of communicating with the peer-to-peer application and peer-to- peer network, respectively.
  • a peer-to-peer network also called a framework
  • peer-to-peer network In the case of a peer-to-peer network, high security standards are achieved in that all computers (peer nodes or simply nodes] in the peer-to-peer network, at least a part of the peer computers in the peer-to-peer network, monitor(s) at least the accuracy of the data relating to a vehicle and/or traffic information data. Transaction costs can be reduced. No central, superior platform, server, cloud, etc. is required.
  • the traffic system may be configured to support the controlling of one or more traffic process(es) and action(s), respectively.
  • a traffic system according to the invention comprises at least one vehicle.
  • a traffic system may comprise a plurality of vehicles.
  • a vehicle may be any mobile transport unit. Exemplified vehicles are cars, trucks, ships, railway vehicles, planes, bicycles, motor bicycles, drones, mobile machines, boats, planes, submarines, space vehicles, etc.
  • the traffic system comprises at least one sensor module.
  • a sensor module may comprise one or more sensor(s) configured to detect or sense one or more motion parameters].
  • the sensor module can be a single device or can be formed by two or more separate units, such as separate sensors.
  • the sensor module can be at least partly integrated in the at least one vehicle.
  • the sensor module can be at least partly formed by one or more sensor(s) already integrated in the vehicle, such as a velocity sensor, location sensor, acceleration sensor, a sensor for monitoring a state of a component of the vehicle, measuring environmental data, traffic way data, video/photo camera, etc.
  • the sensor module may be at least partly formed by an external unit.
  • An external unit is not arranged in the vehicle.
  • an external unit may be positioned at a path of the vehicle for detecting passing vehicles.
  • Such a sensor may be configured to detect an identification (e.g. number plate) of the passing vehicle.
  • the at least one detectable motion parameter relates to the vehicle.
  • a motion parameter is characterized in that it comprises any kind of information about a movement state of the vehicle.
  • detecting at least one motion parameter means in particular that a current value of said motion parameter is detected.
  • the at least one detected motion parameter and its value, respectively, can be provided by the sensor module to the peer-to-peer module. For instance, a communication connection can be established between these modules in order to provide the motion parameter to the peer-to-peer module.
  • the traffic system comprises at least one peer-to-peer module.
  • the peer-to- peer module is (uniquely) assigned to the vehicle. This means that the peer-to-peer module can at least communicate and/or act on behalf of the vehicle.
  • the peer-to-peer module can be (indirectly) assigned to the at least one user.
  • the peer-to-peer module can be (directly) assigned to a user and via the user (indirectly) to a vehicle of the user.
  • the peer-to-peer module can be integrated in the vehicle or it can be formed by separate processing device, such as mobile terminal, owned by a user of the mobile unit, or it can run on a remote processing device (e.g. in a data centre).
  • the peer-to-peer module may be configured to access an (electronic) wallet of a cryptocurrency for a vehicle or a user.
  • the wallet may be part of a vehicle.
  • a mobile terminal can be a smart phone or an embedded device. Such a device may be configured to communicate with one or more (electronic) modules of the vehicle (sensor module, transceiver module or navigation module) via wired or wireless communication.
  • An embedded device comprising the peer-to-peer module module and preferably the peer-to-peer application can also be connected to the vehicle via an interface.
  • An interface can be a standard On-board diagnostics (OBD) connector or another vehicle specific connector.
  • OBD On-board diagnostics
  • a user can connect a peer-to-peer module module via OBD to a vehicle in order to enable the vehicle to participate in the peer-to-peer module application and network, respectively.
  • the peer-to-peer module module may get access to vehicle data via the OBD connector.
  • the peer-to- peer module module may act as an OBD adapter.
  • the (OBD) adapter can be an installed module that is fixed to a vehicle or a mobile module that a user can plug into the actual vehicle
  • the peer-to-peer module module can be a connected with a battery of an electric vehicle.
  • the peer-to-peer module module can be integrated in one or more battery connector(s) of the battery of the vehicle.
  • the peer-to-peer module module can be comprised in or connected with a navigation module or entertainment module of the vehicle.
  • the vehicle may encrypt data on application level or may have a secure communication channel to the processing device of the data centre and the processing device itself may have a connection to the peer-to-peer network.
  • the remote processing device may be a gateway to the peer-to-peer network. This means that the mobile unit has a secure access to the peer-to-peer network via a communication channel with the gateway.
  • there may be further peer-to-peer modules For instance, a further peer-to-peer module may be (uniquely) assigned to a previously described external sensor module.
  • a mixed architecture can be used comprising at least one peer-to-peer application and a central system. A central system can for example be used to manage traffic control parameter(s) from a central authority. These parameters can be uploaded into the peer-to-peer application.
  • a central system can for example be used to manage traffic control parameter(s) from a central authority. These parameters can be uploaded into the peer-to-peer application.
  • the peer-to-peer application can communicate with a central service to execute optimisation algorithm(s) in order to optimize traffic flows or prevention of traffic accidents or propose traffic way changes or upgrades to improve the traffic flow or reduce accidents.
  • a central system may be configured to control traffic lights, signals or access systems to further improve or control traffic flows. Control traffic lights, signals or access systems can be managed via the peer-to-peer application.
  • each participant of the peer-to-peer network can use a service and the like and offer such a service.
  • a peer-to-peer network is self-determined and/or self-organized (without any higher-level units).
  • each computer of the peer-to-peer network comprises a peer-to-peer application.
  • the peer-to- peer module is configured to transmit data e.g. by sending one or more message(s) to the peer-to-peer application and/or receive data by e.g. reading data stored in the peer-to-peer application or receiving one or more messages from the peer-to-peer application.
  • the peer-to-peer module may be a peer of the peer-to-peer network.
  • the peer-to-peer module is configured to communicate with the peer-to-peer application of the peer-to-peer network.
  • the peer-to-peer module is configured to transmit at least the detected motion parameter to the peer-to-peer application.
  • the peer-to-peer application can evaluate said received data.
  • traffic information data can be generated.
  • the peer-to-peer module receives traffic information data. Traffic information data relates to or comprises data regarding traffic status data and/or regarding any traffic action.
  • the list of all (anonymised or pseudonymised) participants or entities of the at least one peer-to-peer network can preferably be made known to each participant, so in particular to each entity of the traffic system, as a peer-to-peer identification, e.g. in the form of a communications address.
  • a mixer logic i.e. mixing of identifications and using random identifications for a specific vehicle or user for its individual transactions
  • a peer-to-peer module can be at least partially formed by a software module and/or at least partially formed by a hardware module. There may be two or more different peer-to-peer networks each configured for one or more different traffic action(s).
  • the at least one motion parameter relating to the vehicle may be at least one of the group comprising velocity of the vehicle, acceleration of the vehicle, a state of a component of the vehicle, in particular, the state of the motor of the vehicle, and/or the location of the vehicle and/or environmental data (e.g. video data, radar/lidar data, temperature, air quality, precipitation, humidity, traffic density data, traffic way damages, traffic way conditions or congestions) in the surroundings of the vehicle.
  • at least the velocity of the vehicle and the location of the vehicle can be detected by suitable sensors of the sensor module.
  • the current value of the respective motion parameters can be detected and preferably transmitted to the peer-to-peer application.
  • the data about the user such as the location data of the user, is particularly secure handled.
  • the traffic system may comprise at least one navigation module assigned to the vehicle and connectable with the at least one peer-to-peer module.
  • the navigation module may be configured to display the received traffic information data. More particularly, based on a plurality of motion parameters of a plurality of vehicles and/or other traffic state data from other sources the peer-to-peer application may determine the current traffic state of different areas (road, street, etc.). The current traffic state can be provided to the at least one navigation module via the respective peer-to-peer module.
  • the navigation module may provide further data, such as a desired destination of the vehicle, at least one specific criterion, such as avoiding toll roads or highways, preferring shortest or fastest route, etc.
  • the peer-to-peer application may be configured to calculate based on the plurality of motion parameters of the plurality of vehicles and/or other traffic state data from other sources and said further data the optimal route to the desired destination.
  • the route data can be provided to the at least one navigation module via the respective peer-to-peer module.
  • a secure, accurate and powerful navigation system can be provided.
  • the sensor module may comprise a location sensor, in particular, a satellite positioning sensor, such as a GPS or Galileo sensor, a ground-based location sensor, or a combination of both (e.g. differential GPS) configured to locate the (current) location of the vehicle.
  • a satellite positioning sensor such as a GPS or Galileo sensor, a ground-based location sensor, or a combination of both (e.g. differential GPS) configured to locate the (current) location of the vehicle.
  • the sensor module may comprise a camera sensor configured to detect at least one optical marking unit positioned on a path of the vehicle. Each marking unit may comprise a detectable (unique) identification. Based on this identification, the location of the marking unit, and thus, the (current) position of the vehicle can be determined.
  • the sensor module may comprise one or more sensor(s) configured to detect environmental parameter(s) (e.g. temperature, traffic density, C02 data, surrounding data, photos, geo data, radar/lidar data, traffic way conditions, congestions). Further, technical status of components of the vehicle can be detected by one or more sensors of the sensor module.
  • the sensor module may comprise a reader configured to detect at least one electromagnetic field emitted by at least one marking unit positioned on a path of the vehicle. The emitted field may comprise an (unique) identification of the emitting marking unit. Based on this identification, the location of the marking unit, and thus, the (current) position of the vehicle can be determined.
  • the sensor module may comprise a vehicle identification sensor configured to detect the identification of a vehicle passing the vehicle identification sensor.
  • a vehicle identification sensor configured to detect the identification of a vehicle passing the vehicle identification sensor.
  • an optical or electromagnetic sensor can be configured to detect an (unique)
  • the sensor can be arranged on a bridge, traffic light, traffic sign, surveillance system, gates, law enforcement device (e.g. speeding camera) or the like.
  • This sensor module may be connectable with a further peer-to-peer module.
  • the further peer-to-peer module may be configured to transmit the at least one detected identification together with location information of said sensor to the peer-to-peer application. Based on this information the current location of a vehicle can be determined by the peer-to-peer application.
  • Such an external sensor may additionally detect further motion parameter (e.g. speed, direction, vehicle traffic dynamics / user behaviour) or location parameters (e.g. vehicle inside or outside allowed traffic ways). This may allow to detect the current traffic situation (e.g. traffic jam or not) or to monitor a toll-liable route by means of the peer-to-peer application and/or to monitor whether the vehicle is operated in compliance with traffic laws for law enforcement purposes (e.g.
  • the sensor module comprises at least one sensor configured to monitor the movement of a vehicle (at least one tire and/or axis rotation sensor and/or speed sensor) in order to provide Vehicle Logbook or Tachograph data (e.g. speed, operating times, rest periods).
  • the sensor can be registered as a smart asset in the peer-to-peer application of the peer-to-peer network.
  • the data measured by the sensor can be transmitted to the peer-to-peer application.
  • the data to be transmitted can be hashed, time-stamped, signed and/or encrypted [via e.g. telemetry systems) by the sensor.
  • the sensor can comprise a peer-to-peer module and/or can be connectable with a peer-to-peer module.
  • Said provided Vehicle Logbook data can be stored in the peer-to-peer application. Further (authorized) entities (of the peer-to-peer network) can access this data and can, preferably, use said data for e.g. law enforcement and/or for monitoring of operating and rest periods. Data can be stored in decentral file storage (e.g. IPFS) or decentral database (BigchainDB). It shall be understood that a user of a vehicle can authenticate himself via his peer-to-peer identification prior to conducting a vehicle operation. Vehicle peer-to-peer identification and/or user peer-to-peer identification may be stored in the Vehicle Logbook. By analysing user peer-to-peer identification across multiple logbooks single user behaviours can be monitored.
  • decentral file storage e.g. IPFS
  • BigchainDB decentral database
  • the registration process of a vehicle and a Vehicle Logbook sensor can be validated by a central system which is connectable to a peer-to-peer network via a peer-to-peer module and operated by government authorities or by authorities using the peer-to-peer application to validate the registration process.
  • This validation process can make use of production data stored during the manufacturing process of the sensor (e.g. sensor ID, quality assurance data).
  • the peer-to-peer network and a peer-to-peer application can be configured to assist a vehicle for autonomous driving.
  • a mixed architecture can be used comprising at least one peer-to-peer application and a central system.
  • environmental data and/or analytics can be gathered and provide for a one or more vehicle(s) about e.g. road obstacles, constructions sites, weather conditions and/or road conditions (e.g. ice on the road), passing manoeuvre or platooning of vehicles in a convoy.
  • the at least one peer-to-peer application can be configured to facilitate the process of exchanging secure messages between one or many vehicles and/or a central system and or amongst individual vehicles by mans of secure identities or smart assets.
  • Peer-to-peer and/or peer-to-central system communication can be conducted via hashed and/or signed and/or time-stamped and/or encrypted message(s) to ensure authenticity and correctness of
  • one or more individual sensor(s) in a vehicle can be registered in the peer-to-peer application with a (unique) peer-to-peer identification.
  • Data/Messages sent by a registered sensor can be hashed, signed, time-stamped and/or encrypted to ensure authenticity and correctness of the data.
  • one or more individual actors(s) in a vehicle can be registered in the peer-to-peer application with a (unique) peer-to-peer identification.
  • An actor can validate authenticity and/or correctness of messages sent from a peer of the peer-to- peer network, such as one or more peer vehicles (or central system or traffic systems), by means of the peer-to-peer identification, and preferably, by means of (proper) hashing, signing, time-stamping and/or encrypting. It shall be understood that an actor can be connected to a peer-to-peer application via a peer-to-peer module.
  • Examples for actors are components in a vehicle and/or traffic lights, signals or access systems.
  • At least one peer-to-peer module may be configured to cause generating of at least one access transaction agreement about at least one access action of the vehicle by means of the at least one peer-to-peer application (e.g. for managing authorised or paid access to private or otherwise restricted areas).
  • a peer-to-peer module such as the peer-to-peer module assigned to the vehicle or another peer-to-peer module may initiate or cause the generation of an access transaction agreement.
  • access of a vehicle on a particular private or public space may require that a peer-to-peer module is configured to cause or trigger the generation of an agreement between e.g. the user of the car and the provider of the space.
  • the access transaction agreement can comprise data, such as involved entities (e.g.
  • identifications of the vehicle, access areas space, time of use, user, provider, etc. and at least one access transaction criterion (e.g. amount of cryptocurrency to be paid e.g. per time unit).
  • access transaction criterion e.g. amount of cryptocurrency to be paid e.g. per time unit.
  • one or more (external) actor(s) may be connected to the peer- to-peer application.
  • a vehicle or user of the vehicle can trigger an actor (e.g. the gate that opens when the vehicle user is in front of the gate or a traffic light that is switched from red to green).
  • the external actor can be configured with an external sensor to identify a vehicle or user in order to ensure that access it granted in accordance to the access transaction agreement.
  • Trigger or access events may be stored in the peer-to- peer application for monitoring or reporting purposes.
  • the access transaction agreement may include on-ground mobility, mobility in or under water or for mobility in air or space. Accessing restricted spaces with no access transaction agreement can be prohibited and/or penalised.
  • Law enforcement, military and/or emergency vehicles can be registered in a peer-to- peer application to get (automatic, priority) access to an area. These vehicles are registered in the peer-to-peer application with e.g. a flag as priority vehicles.
  • At least one peer-to-peer module may be configured to cause generating of at least one parking transaction agreement about at least one parking action of the vehicle by means of the at least one peer-to-peer application.
  • a peer-to-peer module such as the peer-to-peer module assigned to the vehicle or another peer-to-peer module may initiate or cause the generation of a parking transaction agreement.
  • parking of a vehicle on a particular parking space may require that a peer-to-peer module is configured to cause or trigger the generation of an agreement between e.g. the user of the car and the provider of the parking space.
  • the parking transaction agreement can comprise data, such as involved entities (e.g.
  • identifications of the vehicle, parking space, user, provider, etc. and at least one parking transaction criterion (e.g. amount of cryptocurrency to be paid e.g. per time unit).
  • a parking transaction agreement can cause the generation of a parking transaction agreement in a simple manner.
  • the peer-to-peer application may be preferably configured to detect based on the at least one motion parameter relating to the vehicle whether the vehicle is in a parking state within a predefined area.
  • a predefined area is a specific geographic area (e.g. defined by geographic coordinates) comprising at least one parking space.
  • the location parameter(s) provided by the peer-to-peer module of the vehicle can be compared with the stored location parameter(s) defining the at least one predefined area.
  • the vehicle based on at least one further motion parameter relating to said vehicle, such as the current velocity, current state of the motor, and motion parameter(s) (e.g. velocity of the respective vehicles) of further vehicles located in vicinity to the other vehicle, it can be determined whether the vehicle is in a parking state or e.g. in a driving state.
  • a further motion parameter relating to said vehicle such as the current velocity, current state of the motor, and motion parameter(s) (e.g. velocity of the respective vehicles) of further vehicles located in vicinity to the other vehicle.
  • the access and/or parking within a predefined area requires the conduction of a parking transaction criterion transaction.
  • the peer-to-peer application may be configured to conduct an access and/or a parking criterion transaction action based on the generated parking transaction agreement.
  • the peer-to-peer application can initiate, control and / or conduct the transfer of an agreed amount of cryptocurrency from an user of a vehicle and a provider of the parking space of the predefined area.
  • the peer-to-peer application may be configured to detect the duration of the access and/or parking state of the vehicle.
  • the sensor module assigned to the vehicle may be configured to detect the duration of the access and/or parking state vehicle.
  • the vehicle checks the duration, the correct calculation of the amount of cryptocurrency depending on said duration can be verified by the user of the vehicle.
  • the one or more vehicle may be registered vehicle(s] in a access and/or parking peer-to-peer network.
  • one or more predefined areas having one or more access and/or parking space(s) may be registered in said peer-to-peer network.
  • private providers can generate such a peer-to-peer network in order to offer parking places to each other.
  • this access and/or parking network one or more (general) access and/or parking transaction agreements may be generated. Based on the at least one access and/or parking transaction and by means of the peer- to-peer application and network, respectively, each access and/or parking action can be conducted and charged in an automatic and simple and at the same time secure way.
  • Pricing data for access and/or parking can be defined in the peer-to-peer application by dynamic or user-/vehicle specific pricing schemes.
  • at least one peer-to-peer module may be configured to cause generating of at least one toll transaction agreement about at least one toll-liable action of the vehicle by means of the at least one peer-to-peer application. For instance, for the use of at least one specific road or other route tolls or similar user charges have to be paid.
  • the control of such a traffic system can be performed by the peer-to-peer application.
  • User or vehicles may be registered with the peer-to-peer application via an identification or a wallet, as will be described hereinafter. Based on received motion parameters of a vehicle and e.g.
  • a toll-liable action can be controlled and charged (e.g. via cryptocurrencies) by means of the peer- to-peer application.
  • the peer-to-peer application may be configured to conduct a toll criterion transaction action based on the generated (general) toll-liable action transaction agreement.
  • This action agreement may be an agreement valid for all vehicles passing said toll-liable route.
  • the at least one toll criterion may be a location-based and/or dynamic toll criterion (e.g. between a minimum and maximum value to be paid) wherein the actual value may depend on a location, an expected traffic state or current traffic state (e.g. low traffic volume or high traffic volume) of said toll-liable route and/or time (e.g. higher toll prices at peak times).
  • at least one toll criterion may be a priority toll criterion (e.g. between a minimum and maximum value to be paid) for using less congested traffic ways with higher priorities (e.g. fast lane or fast track). Traffic jams may be at least reduced and/or better controlled.
  • Pricing schemes of toll-liable actions can depend on dynamic traffic parameters and/or user- /vehicle specific attribute(s) which are defined in the peer-to-peer application (e.g. different prices for cars or trucks depending on density of traffic). Dynamic pricing via the peer-to-peer application can be used to steer or optimise traffic flows.
  • At least one peer-to-peer module may be configured to cause generating of at least one law enforcement agreement about at least one law enforcement action of the vehicle by means of the at least one peer-to-peer
  • the law enforcement external sensor data and the vehicle data may be written into the peer-to-peer application and linked to the identification of the vehicle.
  • the external sensor e.g. speeding camera
  • a penalty can be paid.
  • the proof(s) may be stored in the peer-to-peer application.
  • one or more traffic law enforcement algorithm(s) including penalties can be directly build into the vehicle.
  • Data of the vehicle may be used to detect breaches of law(s). In this case, an external sensor is not needed.
  • Penalties can be payments, locking and/or stopping of a vehicle or a vehicle/user operating licence restriction.
  • a build in law enforcement logic can be considered as "Law Enforcement in Advance”. Taxes schemes can incentivise this logic with specific tax cuts (for e.g. vehicle registration or operating taxes).
  • a check of a vehicle/user operating licence restriction may require that vehicle(s) check by means of the peer-to-peer application whether a user has the right to operate a vehicle.
  • the peer-to-peer application may hold user or vehicle data about user or vehicle operating licences.
  • a vehicle can be for example unlocked for operations only if a user has a valid (e.g. signed by central authorities) operating licence without relevant restrictions or limitations (maybe caused by breach of laws or missing licence for a specific vehicle type; e.g. a truck or a plane).
  • the control of a traffic system in form of a law enforcement and vehicle operating licence system can be performed by the peer-to-peer application.
  • User or vehicles may be registered with the peer-to-peer application via an identification and/or a wallet.
  • vehicle operating licence information e.g. a vehicle identification (e.g. number plate, RFID or another identification that can be read our via optical or electromagnetic waves) of said vehicle, a law enforcement action can be controlled and charged via
  • the peer-to-peer application may be configured to conduct a law enforcement criterion transaction action based on the generated (general) law enforcement(-liable) transaction agreement.
  • This transaction agreement may be an agreement valid for all vehicles passing said route.
  • route side infrastructure can be used by a vehicle (i.e.
  • sensors along a route such as differential GPS sensors.
  • a vehicle can be allowed to use sensor data and pay in cryptocurrency.
  • sensor data of vehicle(s) can be shared with other entities (traffic analysis systems, weather systems, air quality system, etc.).
  • another entity can be allowed to use vehicle sensor data (swarm intelligence) and pay in cryptocurrency.
  • a peer-to-peer application in combination with off-chain algorithms can provide analytics traffic system and environmental analyses for further optimisation options for authorities or private owners or for an accident prevention system or for environmental or authority reporting purposes.
  • the at least one peer-to- peer module may be configured to cause generating of at least one vehicle
  • a vehicle autonomous driving agreement may comprise an autonomous driving service and/or vehicles in the surrounding.
  • the autonomous driving service may be provided, facilitated and/or paid via the peer-to-peer application.
  • the autonomous driving service may provide (reliable) data beyond the "(visible) sight" of a vehicle (e.g. obstacles, road conditions, accidents, objects hidden from the sensors of a vehicle, etc.) in order to improve security and/or convenience of vehicle operations.
  • one or more vehicle(s) in the surrounding of said vehicle may generate an autonomous driving agreement to share data in the (visible) sight of each vehicle in order to improve the (visible) sight of said (individual) vehicle. This may improve security and/or convenience of vehicle operations.
  • the peer-to- peer application may be configured to conduct a vehicle autonomous driving transaction action for improving the sight of individual cars.
  • environmental data are gathered, shared and/or analysed (e.g. road obstacles, constructions sites, weather / road conditions (e.g. ice on the road) or passing manoeuvres).
  • Another example may be platooning of vehicles in a convoy. This platooning can be agreed in a vehicle autonomous driving agreement.
  • One or more new vehicle(s) joining a traffic way browse the peer-to-peer application for an already existing platoon and/or
  • a vehicle may register itself in the peer-to- peer application.
  • the peer-to-peer application may then adjust speed and/or distance of the two or more vehicles in a platoon accordingly.
  • Secure data exchange among sensor(s) and/or actor(s) can be done via peer-to-peer communication with e.g.
  • the at least one peer-to-peer module may be configured to cause generating of at least one vehicle sharing transaction agreement about at least one vehicle sharing action of the vehicle by means of the at least one peer-to-peer application.
  • a vehicle sharing transaction agreement may be generated in a similar way as described above in connection with e.g. the parking transaction agreement.
  • the peer-to-peer application may be configured to conduct a vehicle sharing criterion transaction action based on the generated vehicle sharing action transaction agreement. For instance, based on a vehicle sharing criterion (e.g. a particular amount of cryptocurrency per time unit) the peer-to-peer application may cause the transmission of said agreed amount from e.g.
  • a vehicle sharing criterion e.g. a particular amount of cryptocurrency per time unit
  • the price for using a vehicle may depend on the user's operating licence information stored in the peer-to-peer application (e.g. experience in number of years or distance driven, traffic law enforcement penalties, operating behaviour data from previous sharing agreements). It shall be understood that validity of a vehicle sharing transaction agreement (checked by business logic in the agreement) or activation of a vehicle can depend of law enforcement and operating licence data of the user stored in the peer-to-peer application (checked by the vehicle prior to operations).
  • the peer-to-peer application may be a vehicle sharing peer-to-peer application of a vehicle sharing peer-to-peer network.
  • One or more providers of one or more vehicle can generate such a peer-to-peer application and network, respectively, to offer the at least one vehicle to each other (and further user), wherein the provider may define the rules for a car sharing action.
  • the at least one vehicle may comprise at least one locking module configured to lock an access unit of the vehicle and/or an activation of at least one function of the vehicle.
  • the locking module may be configured to release the access unit of the vehicle and/or to activate the function of the vehicle based on a receipt of a release information provided by the peer-to-peer application.
  • the release information can be generated by the peer-to-peer application based on a generated vehicle sharing transaction agreement.
  • an identification assigned (directly or indirectly) to a user may be stored in said agreement.
  • an identification received from an user e.g. from an user terminal of the user
  • the interface module can comprise a peer- to-peer module or can be connectable with a peer-to-peer module.
  • the release information can be provided to the locking module.
  • the locking module can comprise a peer-to-peer module or can be connectable with a peer-to-peer module. Then, the user can use the vehicle.
  • a vehicle may store sensor data in the peer-to-peer application for the purpose of maintenance (physical and/or chemical parameters, technical system status (of e.g. embedded device(s)), usage parameters of component of the vehicle).
  • the peer-to-peer application can propose maintenance activities (based on data of other vehicles of the same or a similar type). Maintenance proposals can be predicted via machine learning or artificial intelligence algorithms (partly off- chain). Vehicle maintenance activities can be planned and coordinated in accordance to location, usage or route planning data. This type of coordination may be especially important for (logistic) transport units, such as trucks, that are maintained along their logistics route.
  • At least one received identification assigned to a mobile unit or an entity assigned to said vehicle can be checked.
  • all identifications of all entities of a peer-to-peer network are stored and registered, respectively, in the peer-to-peer application and/or in a database or decentral file system (such as IPFS) or decentral database (such as BigchainDB) controlled by the peer-to-peer application, such as by a smart contract of the peer-to-peer application.
  • a traffic system may comprise a distributed block chain database such as BigChainDB.
  • the advantages of the immutable distributed block chain database may be that the data are immutable and any units or smart contracts or user in the system can run queries to analyse data and further optimise and automate a process.
  • Data stored either on a decentral file storage or a distributed block chain database may be encrypted.
  • the peer-to-peer application, such as a block chain is then used to facilitate access management to the data by handling the encryption keys. Then, the at least one identification can be compared with the registered
  • At least one identification is a valid identification, i.e. corresponds to at least one registered identification, a communication between said entity and the peer-to-peer application is enabled.
  • a decentral and trustful authorization process can be provided by means of the peer-to-peer application without the need of a central server or the like.
  • a user can participate in the traffic system by having a peer-to-peer module in the vehicle or connected to the vehicle. It is also possible that a user participates by using a mobile terminal.
  • a user can participate by registering as a user or a vehicle at web service or at a stationary terminal (e.g. stationary toll terminal).
  • the central system of the web service or the stationary terminal may then be connected via a peer-to-peer module to the peer-to-peer application.
  • the user may register via its identification or the identification of his vehicle.
  • the user may do a pre-payment in a (crypto-) currency to use the service.
  • a peer-to-peer application detecting a vehicle that is not registered for a toll-liable service may send a message to a law enforcement unit including a proof (e.g. photo) stored in the peer-to-peer application.
  • each entity e.g. vehicle, mobile terminal, predefined area, user, stationary terminal, existing back-end system, etc.
  • a peer-to- peer module assigned to an entity may be configured to cause a registration of the entity (or peer-to-peer module) in the peer-to-peer application by transmitting a registering message comprising at least an identification assigned to the entity.
  • the identification might be already a peer-to-peer application identification or another identification suitable to uniquely identify the entity, such as a serial number of e.g.
  • the peer-to-peer application may be configured to generate a unique peer-to- peer identification for the vehicle and/or user and/or any other entity involved in the traffic system.
  • the peer-to-peer application may register the respective entities by storing at least the peer-to-peer identification in the peer-to-peer application or a database controlled by the peer-to-peer application.
  • the peers of the peer-to-peer network may check whether the registering requirements predefined by the peer-to-peer network are met by the entity requesting registration. In order to perform the check, preferably, further data may be included in the registering message.
  • the peers of the peer-to-peer network may provide registering rules or registering requirements which must be fulfilled by an entity to be regarded as a trustful entity.
  • each entity to be registered must comprise an account and/or a particular amount of a cryptocurrency.
  • Other rules/requirements may be individually defined by the peers of a peer-to-peer network. E.g.
  • a reputation factor can be calculated e.g. by way of algorithms (e.g. by using parameters, such as user or vehicle location, law
  • reputation score can be used to determine (user-/vehicle specific) pricing data within the traffic system.
  • the registering process also further e.g. technical details of the vehicle, predefined area, and/or user terminal can be stored together with the respective peer-to-peer identification in the peer-to-peer application or the database accessible by the peer-to-peer application.
  • Example of technical details may be a maximum parking capacity of a predefined area
  • a vehicle can select a predefined area having at least one parking space which is particular suitable for the vehicle.
  • a communication module of a vehicle can be shared for the purpose of the peer-to-peer application and/or other car communication application(s).
  • the communication module can be part of other components in the car and connected to the peer-to-peer module.
  • Communication networks can be mobile data
  • the peer-to-peer application may provide a peer-to-peer communication capability.
  • nodes in a network can directly communicate with each other (e.g. via signed and/or encrypted direct messages). Movement, location and environmental data can be shared via the peer-to-peer application.
  • vehicle(s) and its (their) respective peer-to-peer module(s) may know which other vehicle(s) is(are) in its(their) direct surroundings.
  • a vehicle can directly communicate via signed/encrypted messages to its surrounding vehicle(s) in order to trigger collision prevention or emergency response action(s). For example a status of a broken breaking system of a vehicle can be shared in a secure way and surrounding vehicles might trigger response actions to prevent a further collision.
  • a collision prevention module or a “foreign object identification” module may identify physical objects, humans or animals on a traffic way or on a collision path. It may trigger an emergency response that is shared with surroundings vehicles to ensure they react accordingly (and in advance).
  • a traffic system a secure way to exchange messages via a peer-to-peer communication is established and manipulation of communication data can be avoided.
  • Real-time traffic jam, foreign object or traffic way damage/congestion data can be shared via the peer-to-peer application with other entities and used for traffic rerouting, further optimisation of traffic routes.
  • traffic way environmental data can be used for improving of a geo database or traffic way data base [e.g. road damages).
  • Traffic way database may be used to prioritise and trigger traffic way maintenance actions.
  • a peer-to-peer application may store geo data and traffic way data into decentral file storage or decentral database or a cloud database. Geo data may be used for traffic control, navigation or other geo service purposes.
  • the peer-to-peer application may comprise a reputation store and/or may be configured to access a reputation store.
  • the reputation store comprises at least the peer-to-peer identification of at least one of a registered vehicle and/or other entity together with a reputation factor assigned to the respective vehicle and/or other entity.
  • the peer-to-peer application may be configured to update the at least one reputation factor based on a validation result, preferably a plurality of validation results. For instance, a conducted traffic action can be analyzed by the peer-to-peer network and used for updating reputation factors. For instance, if a traffic action was performed correctly, a reputation factor can be increased while a reputation factor can be reduced if issues occurred in connection with a traffic action.
  • further information such as feedback data about the satisfaction of the entities involved in a traffic action, can be provided by at least one peer-to-peer module to the peer-to-peer application. Also this data can be used for adapting reputation factors.
  • the reputation system can be provided by the peer-to-peer application to preferably all participants of the peer-to-peer network.
  • a vehicle and/or a provider of a vehicle, tool-liable route, access to public or private areas, and/or a parking space can select authorized vehicles based on the (current) reputation factor assigned to the vehicles.
  • the at least one peer-to-peer application can be a decentralized register or a shared database storing transaction and data with given certain proofs or signatures.
  • the decentral register can store computer code acting as e.g. means for evaluating or sending data.
  • the code can be invoked by a transaction to the address of the code in so called 'smart contracts'. This code is processed on the nodes of decentral register.
  • a decentralized register can be readable at least by a part of the participants of the peer-to-peer network.
  • every computer node including e.g. the at least one peer-to-peer module assigned to vehicle can comprise the peer-to-peer application.
  • the decentralized register may be read at least by each participant of the peer-to-peer network.
  • all peer-to-peer modules and all other computers of the peer-to-peer network can preferably read all information in the peer-to-peer application formed as a register. Preference is also that all peer-to-peer modules and all other computers of the peer-to-peer network can send messages to or write messages to the peer-to-peer application.
  • a message or transaction sent to a smart contract will start the execution of the code of the smart contract while using data stored in the smart contract.
  • the peer-to-peer application can be built upon the following elements: PEER-TO- PEER network, Consensus System / Protocol, Data Structure, Merkle Trees, Public Key Signatures, Byzantine Fault Tolerance. It replicates data based on a consensus principle. It is auditable and traceable. In a simple way information can be made available to preferably all participants. This allows to carry out a review of the information stored in the decentral register or the code executed in the decentral register.
  • each computer in the peer-to-peer network can be configured to review new information, in particular based on older information stored in the peer-to-peer application.
  • each computer can in each case comprise the complete data content, but include at least a portion of the data contents of the peer-to-peer application, in particular of the decentral register.
  • each computer can in each case comprise the complete data content, but include at least a portion of the data contents of the peer-to-peer application, in particular of the decentral register.
  • this information is saved by all computers, at least by a part of the computers. The tamper resistance of the data stored in the peer-to-peer application can thereby be further improved.
  • the peer-to-peer application can comprise encryption means and/or signature means and/or verification means, wherein at least one of the encryption means and/or signature means and/or verification means is configured to store data, such as motion parameter(s) and/or traffic information.
  • data such as motion parameter(s) and/or traffic information.
  • the hash function a link is established with at least one previously stored information in the decentral register. Further data, such as request messages, ordinary, contextual and/or transaction data of an entity, such as a vehicle, can be stored.
  • the peer-to-peer application may be formed by a Directed Acyclic Graph (DAG).
  • a directed acyclic graph such as IOTA or Tangle, means that blocks (or nodes of the graph) are coupled to each other via directed edges. Thereby, direct means that the (all) edges have (always) a same direction similar to time. In other words, it is not possible to step back.
  • acyclic means that loops do not exist.
  • the peer-to-peer application can be a block chain or decentral ledger comprising at least two blocks coupled to each other (e.g. Ethereum Block chain with Smart Contracts).
  • the block chain technology or "decentral ledger technology” is already used in the payment by means of a crypto currency, such as Bitcoin. It has been recognized that by a particular configuration of a block chain, at least the correctness of a received or provided data can be checked without the need of a central server.
  • the block chain can be used to generate a release information caused by at least the peer-to-peer module in a tamper-proof manner.
  • the block chain according to the present embodiment is particularly a decentralized, peer-to-peer-based register in which all data related to a traffic action and other messages sent by peer-to-peer modules can be logged.
  • a block chain is particularly suitable as a technical means to replace a central entity/server in a simple and secure manner.
  • the block chain can be a permissionless or permissioned block chain.
  • the block chain can be public, consortium or private block chain.
  • peer-to-peer application can be formed by multiple block chains which are connected via mechanisms such as side chains or smart contracts.
  • Data of the peer-to-peer application can be stored on the "decentral ledger
  • decentral ledger steers (encrypted) data storage accessible via the internet and preferably in de-central data storage entity such as Interplanetary File System (IPFS) or in a distributed Blockchain database (e.g. BigChainDB). Access to the encrypted data to third party entities is managed via identity and access management transactions or smart contracts via the block chain.
  • IPFS Interplanetary File System
  • BigChainDB distributed Blockchain database
  • data feeds can be provided by the peer-to-peer application (so called “smart oracles", e.g. information about prices, weather, etc.).
  • Data can be captured from trusted sources off-chain and stored on the block chain or stored via the block chain on a decentral data storage entity.
  • Information among peer-nodes can be exchanged by a peer-to-peer messaging system.
  • a peer node can send a message to another peer node to submit an information or to trigger an action.
  • Messages can be clear text, signed and / or encrypted. This means that not all data exchanged among peer nodes must be stored on the block chain.
  • the at least one peer-to-peer network can be formed by a plurality of computer nodes and a peer-to-peer module, such as the peer-to-peer module of a vehicle or a peer-to-peer module of a mobile terminal, etc., is only configured to communicate with the plurality of computer nodes.
  • the peer-to-peer module is not a computer node of the peer-to-peer network but only a participant.
  • Such a peer-to-peer module does not comprise the peer-to-peer application but only provides an interface module, such as an application
  • a peer-to-peer module can either send clear text or encrypted information or generate a secure connection (e.g. tunnel) to a peer-to-peer gateway (or so called "remote node”) in order to communicate with the peer-to-peer network. This allows reducing the required processing power of the peer-to-peer module.
  • the peer-to-peer network there can be only one validating peer or full node, e.g. only one node can be configured to perform a validation process, and one or more observing nodes.
  • An observing node can validate transactions to establish a trust level but does not validate all transactions which is done by the validating peer.
  • the peer-to-peer module is one of the computer nodes.
  • the peer-to-peer module comprises at least a part of the peer-to-peer application.
  • the peer-to-peer module can comprise preferably the total data content of the peer-to-peer application or can access the information stored in another node.
  • the peer-to-peer module might be a so called "light node” or a decentral application (DAPP) connected to a remote node.
  • DAPP decentral application
  • the peer-to-peer module comprises at least an API configured to communicate with the peer-to-peer application, such as the block chain.
  • the peer-to-peer module comprises a decentral application of software comprising local algorithms at least configured to create and transmit data, transactions or the measured quantity parameter to the peer-to-peer application via the API.
  • the decentral application so called “Dapp” is at least configured to process and transmit the meter data.
  • the data is signed or encrypted or can be transmitted via a
  • the peer-to-peer application itself is implemented in the peer-to-peer module, i.e. the peer-to-peer module is a node of the peer-to-peer network comprising the decentral application, the API and the peer-to-peer application, such as the block chain or decentral ledger.
  • Further processing of data can be done on-chain or off-chain.
  • Off-chain data processing, evaluating and/or validation can be managed by the peer-to-peer application, like the code on the block chain. Powerful means in particular a high computing power.
  • Powerful means in particular a high computing power.
  • a valid entry in the peer-to-peer application, such as a block chain is assumed if (only] a part of the peers comes to a positive result. It shall be understood that only a single, especially particularly powerful peer can perform the processing or validation process.
  • the block chain may delegate computing tasks to one or more resources. It either trusts one resource or it applies a consensus principle while delegating similar processing tasks to many resources.
  • Data and transactions stored on the block chain do not provide "transactional privacy". Transactions between pseudonyms may be (often) stored in clear text on the block chain. In some cases data stored on the block chain are encrypted and the keys may be handled via the block chain. Privacy preserving, secure transactions or execution of computer code can be achieved with cryptographic tools such as zero knowledge (zk) proofs or zk Succinct Non-interactive Arguments (zk-SNARK).
  • a privacy preserving protocol ensures the privacy of data and the correctness of code execution (SNARK verification is done via the smart contract on chain).
  • the private contract computation can be done by a set of nodes, off-chain computers or done in measured launch environment or a secure HW enclave for attestation and sealing that cannot be manipulated by other software code running on the devices.
  • secure Multi-Party-Computing (sMPC) systems can be used for transactional privacy. Examples for privacy preserving protocols and computation are HAWK and MIT Enigma. With zero knowledge proof (zk Proofs) the parties can see that the algorithm is executed correctly in a private contract, but the input data are not disclosed to the party.
  • a particularly large peer-to-peer network may be divided in two or more (physical or logical or dynamically virtual) clusters.
  • a validation (of a subset of transactions) may only be carried out by the members of one cluster (a subset of nodes; e.g. sharding of a block chain to improve the scalability).
  • the peer-to-peer application can be formed using multiple block chains. These block chains are connected via frameworks such as sidechains or smart contracts.
  • Financial values can be (instantaneously) exchanged with a transaction via a cryptocurrency.
  • micropayment channels are used for a constant payment stream that can be handled party off-chain to reduce the amount of on-chain transactions.
  • so called state channels or state networks e.g. Raiden Network
  • Opening and/or closing of state channels may be registered on the block chain. This means that individual transactions may not be stored on the block chain in order to improve scalability and avoid movement tracking of pseudonyms on the block chain.
  • a man-in-the-middle is not necessary. Fully automated processes from authentication to charging and billing can be provided.
  • at least one entity of the traffic system may have a digital wallet to exchange value in form of digital tokens and/or cryptocurrency.
  • At least one financial and/or traffic system transaction among at least two entities may be secured via at least one smart contract.
  • a transaction may invoke the execution of the smart contract.
  • a deposit or escrow in form of a cryptocurrency may be stored in the smart contract by the entity that orders a product.
  • the entity may send a signed confirmation to the smart contract when it has triggered or executes (e.g. entering a toll and/or access area or parking space) the activity.
  • the deposit may be send to a unit or an entity of a traffic system when activities are performed as defined in the transaction agreement and/or it receives the signed confirmation message (or in accordance to any other payment conditions defined in the transaction agreement).
  • a traffic journey e.g. planned route or car sharing agreement or traffic way usage agreement
  • all remaining funds may be sent back to the entity that provided the deposit.
  • a traffic journey e.g. planned route or car sharing agreement or traffic way usage agreement
  • all remaining funds may be sent back to the entity that provided the deposit.
  • a traffic journey e.g. planned route or car sharing agreement or traffic way usage agreement
  • all remaining funds may be sent back to the entity that provided the deposit.
  • a traffic journey e.g. planned route or car sharing agreement or traffic way usage agreement
  • payment condition(s) such as pre- or post-payments can be implemented in the smart contract logic as well.
  • Overall the smart contract provides a secure and transparent payment process with no middle man involved.
  • Micropayment Channels are used.
  • the peer-to-peer application can be connected to a central system (e.g. central system connected to a peer-to-peer module or a remote node). Central government or private authorities can provide access, law enforcement or pricing parameters into the peer- to-peer application. Or the peer-to-peer application is connected with a central traffic system control or optimisation service that dynamically adjusts traffic system parameters or provides traffic control and route optimisation data.
  • a central system e.g. central system connected to a peer-to-peer module or a remote node.
  • Central government or private authorities can provide access, law enforcement or pricing parameters into the peer- to-peer application.
  • the peer-to-peer application is connected with a central traffic system control or optimisation service that dynamically adjusts traffic system parameters or provides traffic control and route optimisation data.
  • vehicle data are shared with central or decentral maintenance applications.
  • a further aspect of the invention is a method.
  • the method comprises:
  • the method can be used for operating a previously described traffic system.
  • the peer- to-peer module can be assigned to a vehicle and/or a sensor module configured to detect the at least one motion parameter relating to at least one vehicle.
  • vehicle data can be shared with a traffic or environmental control system.
  • a further aspect of the invention is an arrangement for a vehicle.
  • the arrangement comprises at least one sensor module configured to detect at least one motion parameter relating to the vehicle.
  • the arrangement comprises at least one peer-to- peer module assigned to the vehicle and configured to communicate with at least one peer-to-peer application of at least one peer-to-peer network.
  • the peer-to-peer module is configured to transmit at least the detected motion parameter to the peer- to-peer application and/or to receive at least traffic information data from the peer- to-peer application.
  • the arrangement can be formed by a single device including hardware and/or software modules. Such a single device can be integrated into a vehicle. Alternatively, the arrangement can be formed by two or more separate components including hardware and/or software modules. Some components may be already installed in a vehicle and connectable to the further installable components.
  • an aspect of the invention is a vehicle comprising at least one of the previously described arrangement.
  • At least one peer-to-peer module assigned to the vehicle may be connected to the vehicle via an interface of the vehicle, in particular, via an on-board diagnostics connector of the vehicle.
  • a still further aspect of the invention is a further method.
  • the method comprises: generating at least traffic information data by evaluating at least one motion parameter relating to at least one vehicle by means of at least one peer-to-peer application, and
  • the method can be realised as a computer program.
  • the method can be performed by at least one peer-to-peer application.
  • a further aspect of the invention is a peer-to-peer application.
  • the peer-to-peer application comprises means for generating at least traffic information data by evaluating at least one motion parameter relating to at least one vehicle.
  • the peer-to- peer application comprises means for providing the generated traffic information data to at least one peer-to-peer module assigned to at least one vehicle.
  • the means for generating and/or the means for providing may be preferably formed by code of one or more smart contracts.
  • the features of the methods, systems or networks, devices, units, arrangements, modules and computer programs can be freely combined with one another.
  • features of the description and/or the dependent claims, even when the features of the dependent claims are completely or partially avoided, may be independently inventive in isolation or freely combinable with one another.
  • Fig. 1 a schematic view of an embodiment of a traffic system according to prior art
  • Fig. 2 a schematic view of a first embodiment of a traffic system according to the present invention
  • Fig. 3 a schematic view of a further embodiment of a traffic system according to the present invention
  • Fig. 4 a schematic view of a further embodiment of a traffic system according to the present invention
  • Fig. 5 a schematic view of an embodiment of a peer-to-peer application
  • Fig. 6 a schematic view of a further embodiment of a traffic system according to the present invention
  • Fig. 7 a diagram of an embodiment of a method according to the present invention
  • Fig. 8 a diagram of a further embodiment of a method according to the present invention.
  • FIG. 2 shows a first embodiment of a traffic system 200 according to the present invention.
  • the traffic system 200 comprises at least one vehicle 202.
  • the traffic system 200 comprises a plurality of vehicles.
  • Exemplified vehicles are cars, trucks, ships, railway vehicles, planes, bicycles, drones, etc.
  • aspects of the invention will be described in connection with a car. However, the statements made can be easily transferred to other kinds of vehicles.
  • the car 202 comprises a navigation module 214.
  • the navigation module 214 may comprise a display unit configured to display traffic information data. Additionally or alternatively, traffic information data can be displayed using other user interfaces, such as loud speakers.
  • the traffic system 200 comprises a peer-to-peer network 222 or a computer-computer network 222.
  • the peer-to-peer network 222 comprises a plurality of nodes 226.1, 226.2, 226.3 or computers 226.1, 226.2, 226.3.
  • a peer-to-peer network 222 is characterized in the present case in that each node 226.1, 226.2, 226.3 and/or participant 228 is preferably connectable to every other node 226.1, 226.2, 226.3 and/or participant 228.
  • at least one physical standard network can be used for connection.
  • suitable transceiver modules may be arranged the respective entities.
  • computers 226.1, 226.2, 226.3 have equal rights, something which distinguishes them from a server-client structure.
  • the depicted nodes 226.1, 226.2, 226.3 (each) comprise a peer-to-peer application 224.
  • the peer-to-peer application 224 is preferably implemented on each node 226.1, 226.2, 226.3.
  • the peer-to-peer application 224 may preferably be a public register 224 that can, in particular, be inspected by all participants 226.1, 226.2, 226.3, 228 (not only the nodes 226.1, 226.2, 226.3) of the peer-to-peer network 222.
  • Each node 226.1, 226.2, 226.3 preferably has the (entire) public register 224. It may also be envisaged that only part of the register can be provided on a node (light node).
  • the peer-to- peer application 224 may be a block chain 224 which will be explained in more details hereinafter.
  • the at least one car 202 comprises an arrangement 230 with a peer-to-peer module 228 and a sensor module 221.
  • the peer-to-peer module 228 and a sensor module 221 assigned to the car 202 can be fixedly integrated in the car 202.
  • at least parts of the modules 221, 228 can be formed as separate units.
  • a peer-to-peer module 228 is (generally) configured to communicate at least with the peer-to-peer network 222, i.e. the nodes 226.1 to 226.3 of the peer-to-peer network 222. In other words, the peer-to-peer module 228 or the car/entity 202
  • a communication module in a car can be shared for the purpose of the peer-to-peer application and/or other car communication applications.
  • the communication module can be part of other components in the car and connected to the peer-to-peer module.
  • Communication networks can be mobile data
  • Protocols for the communication modules and firmware for other modules can be deployed in a secure way using the peer-to-peer application. These protocols can for example define a quality of service for prioritising emergency data (e.g. for collision prevention). Therefore it may be important that communication protocols and firmware upgrades for other component are deployed in a secure way in order to guarantee proper working of system effecting health and security of vehicles and users.
  • Car-to-Car communication access to the internet can be shared among many cars.
  • the car that provides the access may be incentivised via the mean of crypto currency.
  • all participants 226.1, 226.2, 226.3, 228 (including all nodes) of the peer- to-peer network 222 are known to each participant 226.1, 226.2, 226.3, 228 of the peer-to-peer network 222.
  • the at least one peer-to-peer module 228 is not a node of the peer- to-peer network 222 but only a participant 228. While the nodes 226.1, 226.2, 226.3 or computers 226.1, 226.2, 226.3 in the peer-to-peer network 222 comprise at least a part of the peer-to-peer application 224 a participant of a peer-to-peer network, like the present peer-to-peer module 228, does not comprise the peer-to-peer application 224. Such a peer-to-peer module 228 is configured to provide access to the peer-to- peer application 224 e.g. via an API.
  • Each peer-to-peer module (also a node) may comprise a decentral application and at least an API.
  • the peer-to-peer module is formed as a node the peer-to-peer module (also) comprises at least partly the peer-to-peer application 224.
  • the peer-to-peer module 228 may comprise a communication connection to the sensor module 221 and/or the navigation module 214.
  • the sensor module 221 may be configured to sense or detect at least one motion parameter (or environmental parameter) relating to the vehicle 202.
  • the sensor module 221 may comprise a sensor (e.g. already implemented in the car 202) for sensing the current velocity of the car 202.
  • the sensor module 221 comprises a location sensor, in particular, a satellite positioning sensor, (e.g. already implemented in the car 202) configured to detect the current location of the car 202. Further movement parameters can be directly and/or indirectly detected e.g. by detecting further state parameters of the car, such as a state parameter of a component (e.g. active state of the motor or inactive state of the motor, system status or technical component data). From an inactive state it can be followed that the car 202 is currently not moving.
  • the sensor module 221 is configured to provide at least one of the above mentioned motion parameters relating to the car 202 to the peer-to-peer module 228.
  • the sensor module 221 can at least provide the current location of the car 202 and the current velocity of the car 202 to the peer-to-peer module 228.
  • the peer-to-peer module 228 may provide the at least one motion parameter value to the peer-to-peer application 224 e.g. by transmitting or writing said data to the peer-to-peer
  • the peer-to-peer application 224 By providing said data to the peer-to-peer application 224 e.g. the current traffic situation can be monitored and evaluated by the peer-to-peer application 224 or by an algorithm (running maybe off-chain) that is controlled by the PEER-TO-PEER application.
  • the peer-to-peer application 224 is configured to provide traffic information data to the peer-to-peer module 228 of the car 202.
  • This traffic information data may comprise an optimized route for arriving at a particular destination.
  • the navigation module 214 may provide the set destination of the car 202 to the peer-to-peer module 228.
  • the peer- to-peer module 228 may forward this destination to the peer-to-peer application 224.
  • the peer-to-peer application may comprise means to determine an optimal route based on the set destination, movement parameters of this and further vehicles and/or further traffic status information, such as current traffic jams, closed roads, usage restrictions, and the like.
  • Such further traffic status information can be provided by the peer-to-peer application e.g. using decentral or central data feeds and/or traffic optimization algorithm(s) (running maybe off-chain) that are controlled by the peer- to-peer application 224.
  • the peer-to-peer application may provide data to a vehicle about allowed or restricted ground, water or air traffic ways (e.g. allowed air traffic corridors for drone movements). Breaches can be penalised by the peer-to-peer application.
  • Breaches can be penalised by the peer-to-peer application.
  • an emergency control logic module (not shown) can take over control of a vehicle to bring it back into the allowed traffic ways or an automatic message is sent to one or more law and/or traffic way enforcement unit(s).
  • Control logic can be agreed in advance in an access transaction agreement. Allowed and restricted areas can be defined by governmental or private parties. Allowed and restricted area data, control logic can be stored in the peer-to-peer application.
  • the peer-to-peer application 224 provides traffic status information to the peer-to-peer module 228.
  • the navigation module 214 may be configured to determine the optimal route based on the set destination and the provided traffic status information on its own.
  • FIG 3 shows a further embodiment of a traffic system 300 according to the present invention.
  • the depicted system 300 comprises two cars 302, 304.
  • Each of these cars 302, 304 comprises an arrangement 330 with a peer-to-peer module 328 and a sensor module 321.
  • each of the peer-to-peer modules 328 is a participant 328 of the peer-to- peer network 322.
  • the peer-to-peer network 322 comprises two nodes 326.1, 326.2 each comprising the peer-to-peer application 324.
  • two predefined geographic areas 332.1, 332.2 are provided.
  • Such an area 332.1, 332.2 may be defined by location parameters, such as coordinate parameters (e.g. latitude, longitude and/or elevation parameters) of a specific geographic coordinate system.
  • a geographic area 332.1, 332.2 may be defined by its outer boundaries 331, 332 and their location parameter values, respectively.
  • the respective data of said predefined geographic areas 332.1, 332.2 can be stored in the peer-to-peer application 324 and/or a database controlled by the peer-to-peer application 324.
  • a predefined area 332.1, 332.2 at least one parking space may be provided. It may be possible that a predefined area 332.1, 332.2 comprises only one parking space. It may be possible that there is a plurality of predefined areas comprising one or more parking space(s).
  • the parking space may be provided/offered by an owner of the parking place. Access to the parking space may be provided via an access transaction agreement (which can be part of the parking transaction agreement).
  • the providence of a parking space may be associated with a parking transaction criterion, as will be described in more details hereinafter. Thereby, the parking transaction criterion of the first predefined area 332.1 may be different from the parking transaction criterion of the further predefined area 332.2.
  • These data may be stored in the peer-to-peer application and/or a file storage, such as a decentral file storage system, controlled by the peer-to-peer network 324.
  • the sensor module 321 of a car 302, 304 is configured to detect at least the current location of the car 302, 304 and the current velocity of the car 302, 304 and/or the current state of the motor of the car 302, 304.
  • the current location can be detected using a satellite positioning system 310, such as GPS or Galileo System.
  • a satellite positioning sensor may communicate with the satellites of the satellite positioning system 310 via a specific communication channel 320.
  • the current values of these motion parameters can be transmitted by the peer-to-peer module 328 to the peer-to-peer application 324.
  • the peer-to-peer application 324 comprises means to evaluate the provided data.
  • the peer-to-peer application 324 comprises means configured to detect whether a car is in a parking state/condition within a predefined area 332.1, 332.2.
  • the peer-to-peer application can comprise means or can access to means which are configured to evaluate the provided current location parameter(s) by comparing said value(s) with the stored location parameter value(s) of the one or more predefined area(s) 332.1, 332.2. As a result of the comparison process it can be determined whether a car 302, 304 is within a predefined area 332.1, 332.2 or not.
  • the velocity data and/or motor state data of the car 302, 304 can be evaluated by the peer-to-peer application 324.
  • a predefined duration e.g. 1 min or the like
  • the motor state of the car 302, 304 can be checked by the peer-to-peer application 324. If the motor state is "inactive”, it can be followed that the car 302, 304 is in a parking state. On the other hand, if the motor state is "active”, it can be followed that the car 302, 304 is still in a driving state.
  • the peer-to-peer application and/or the car 302, 304 may measure the duration of the parking state of the car 302, 304 within a predefined area 332.1, 332.2. Based on the actual duration and at least one parking transaction criterion, a parking transaction can be conducted by means of the peer-to-peer application, as it will be described in more details in the following.
  • the sensor module 321 and the peer-to-peer application can measure the time in order to verify whether the duration was correctly measured.
  • the above motion parameter(s) may be detected by a sensor module 321 and/or transmitted from a peer-to-peer module 328 (almost) continuously, regularly or at predefinable time points. For example, a transmission can be initiated each time the motor is activated. Then, data, such as the current location and the duration of the inactive motor state can be transmitted to the peer-to-peer application 324. Based on these values, a parking criterion transaction can be initiated by the peer-to-peer application 324
  • the location sensor may be configured to detect marking units located at the predefined areas.
  • the marking units are arranged in order to define said predefined areas.
  • electromagnetic marking units configured to send an electromagnetic field having a predefined range (corresponding to the predefined area) and an unique field identification can be provided.
  • the location sensor of a car may be configured to sense such a field.
  • the read field identification may be transmitted by the peer-to-peer module to the peer-to-peer application in order to determine the current location of the car, in particular, the predefined area corresponding to the detected field identification.
  • FIG. 4 shows a further embodiment of a traffic system 400 according to the present invention.
  • the traffic system 400 comprises a peer-to-peer network 422 with two depicted nodes 426.1, 426.2 wherein each of the nodes 426.1, 426.2 comprises the peer-to-peer application 424.
  • the peer-to-peer module 426.2 of the car 402 is formed as a node 426.2.
  • the present car 402 comprises a locking module 436 and a first interface module 438.
  • the locking module 436 comprises at least a communication connection with the peer-to-peer module 426.2 and/or the first interface module 438.
  • the first interface module 438 may also comprise a
  • the locking module 436 may be configured to lock an access unit, such as a car door, of the car 402. In addition, it may lock the activation of the motor of the car 402. The access unit and/or the activation of the motor of the car 402 may be released if the locking module 436 receives a release information preferably provided by the peer- to-peer application 424.
  • the present system 400 comprises a user terminal 440, such as a mobile phone, tablet computer, notebook, smart card, portable navigation device, etc.
  • the user terminal 440 is a (conventional) mobile phone 440.
  • Said mobile phone 440 comprises at least one further interface module 442 configured to communicate with the first interface module 438.
  • the interface modules 442, 438 may be configured to establish a nearfield connection, such as a RFID connection, Bluetooth connection, infrared connection and/or the like.
  • the depicted mobile phone 440 comprises a peer-to-peer module 428.
  • the peer-to-peer module 428 may be a software module installable on the mobile phone 440.
  • the identification of an user authorized to use car 402 and an identification of the car 402 can be stored.
  • a nearfield communication between the respective interface modules 442 and 438 can be established in order to transmit the identification of the user to the peer-to-peer module 426.2 of the car 402.
  • the received identification and the identification of the car 402 can be written to the peer-to-peer application by the peer-to-peer module 426.2.
  • generating means of the peer-to-peer module can generate traffic information data in form of a release information.
  • a car sharing criterion transaction can be performed.
  • an agreed amount of cryptocurrency can be transferred from an account of the user to an account of the provider of the car 402. It shall be understood that when a sharing transaction agreement is initiated the user may put a defined amount of
  • the usage of a vehicle can be paid for with Micropayment Channels.
  • the sharing transaction agreement may define minimum usage units (e.g. usage per second).
  • Micropayments can be streamed to the vehicle and/or its owner per each minimum usage unit. In case micropayment transactions stop, operations of the vehicle can be stopped accordingly (considering health and/or safety requirements for when stopping the vehicle).
  • FIG. 5 shows a schematic view of an embodiment of a peer-to-peer application 524 according to the present invention.
  • the depicted peer-to-peer application 524 is a register readable, in particular, by the participants of the peer-to-peer network. Thereby, data e.g. in form of messages can be written and/or read into/from the register 524 by a peer-to-peer module of a vehicle/entity and/or any other participants in the peer-to-peer network.
  • the peer-to-peer application 524 may be a block chain 524.
  • a directed acyclic graph such as IOTA or Tangle, means that blocks (or nodes of the graph) are coupled to each other via directed edges.
  • direct means that the (all) edges have (always) a same direction similar to time. In other words, it is not possible to step back.
  • acyclic means that loops do not exist.
  • the block chain can be a permissionless or permissioned block chain.
  • the block chain can be public, consortium or private block chain. Or it can be a combination of block chains.
  • the peer-to-peer application can be formed with multiple block chains which are connected via mechanisms such as side chains or smart contracts.
  • the block chain 524 is formed by at least one block 551, 553, 555, preferably by a plurality of interconnected blocks 551, 553, 555.
  • the first block 551 may also be called genesis block 551.
  • a block 553, 555 [except for the first block 551) refers to each previous block 551, 553.
  • a new block can be created by a computationally intensive process [for example, so called “mining” or through another appropriate process, such as voting) and will be particularly provided to all participants of the peer-to-peer network.
  • the present block chain 524 is particularly adapted to receive data/messages from a peer-to-peer module of a previously described vehicle and/or user terminal and/or from another peer-to-peer device/unit of another participant of the peer-to-peer network. Further, block chain 524 is particularly adapted to save these data/messages in the block chain 524. Furthermore, the block chain 524 is configured to generate data/messages e.g. based on a validation process and/or caused by a peer-to-peer module.
  • a (newly) received message can be saved and published in the current block 555 of the block chain 524. Due to the configuration of a block chain 524 as a public register 524, said data message of e.g. a peer-to-peer module of a vehicle can be read by preferably all participants of the peer-to-peer network and/or data of the message will be stored on decentral file service or distributed block chain database.
  • the message 570 comprises a generated parking transaction agreement 570.
  • a parking transaction agreement 570 can be e.g. generated between an user of a vehicle and a provider of a predefined geographic area having one or more parking places.
  • An example of a generation of such a parking transaction agreement 570 will be described in the following:
  • a parking transaction agreement 570 may comprise the following data:
  • Identification ⁇ Identification assigned to vehicle or user of vehicle and/or identification assigned to predefined area (or parking space) or provider of said area
  • Parking criterion criterion that must be fulfilled by vehicle/user of vehicle for conducting the parking action
  • the parking criterion may be e.g. an amount of cryptocurrency e.g. per time unit which has to be transferred e.g. after a parking action (e.g. from the user of the vehicle to the provider of the parking space).
  • the parking criterion may be a dynamic criterion.
  • an amount can range between a maximum value and a minimum value depending on e.g. parking duration of a vehicle, start (and/or end) parking time, vehicle dimensions, vehicle type, a reputation factor, etc.
  • at least a part of the agreed amount of cryptocurrency can be locked by the peer-to-peer application 524 prior to the parking action.
  • More information/criteria can be, for example, a time stamp, geographic coordinates about the predefined area, an ID of the transaction and other criteria, such as an indication of the motor type (electromotor), a provided electrical charging station, etc.
  • a parking transaction agreement 570 may be valid for only one parking action, a predefined plurality of parking actions or unlimited number of parking actions. The latter case may be a general parking transaction agreement 570.
  • a general parking transaction agreement 570 may be generated during a registration process of an entity for e.g. a specific parking action peer-to-peer network configured to control parking actions.
  • a peer-to-peer module of a computing device of a provider or user of the vehicle can exchange parking request and response (acceptance) messages via the peer-to-peer application.
  • a request message may comprise indications about the above data (identifications, transaction criteria).
  • a provider of a predefined area with one or more parking spaces can send by a peer-to-peer module a message 566 to the peer-to-peer application 524 comprising data, such as an identification assigned to the provider, geographic coordinates of the predefined area and/or at least one parking transaction criterion.
  • Another message 568 may be an acceptance message 568.
  • An acceptance message 568 may comprise identical or at least similar data details as compared with a request message 566. Additionally, the acceptance message 568 can comprise a reference indication to a previous request, such as the ID of the request message 566.
  • the acceptance message 568 can be called a counter-offer message.
  • This can be accepted by the peer-to-peer module of the requester through an acceptance message.
  • a peer-to-peer module e.g. of the computing device of the requester
  • Each entity can give guidelines, according to which at least one parking transaction agreement or other agreements can be generated.
  • each request message can be associated to an optimally corresponding acceptance message.
  • the block chain 524 may also be configured to generate, based on the messages of a peer-to-peer module, a parking transaction agreement 570.
  • Another message may be a toll transaction agreement 572 or a vehicle sharing transaction agreement 574 or an access transaction agreement 576 or a law enforcement transaction agreement 578 or a data sharing agreement 580.
  • a toll transaction agreement 572 may comprise following indications.
  • Identification of the toll route identification, such as a name, coordinates, etc. of the one or more toll routes
  • Toll criterion which must be fulfilled for using at least part of at least one toll route
  • the toll transaction agreement 572 may be generated in a similar manner as a parking transaction agreement.
  • the toll criterion may be a dynamic criterion.
  • Identifications of involved entities identification assigned to a user and an
  • Vehicle sharing criterion criterion which must be fulfilled for using said vehicle and terms and conditions for car sharing pricing
  • a access transaction agreement 576 can comprise the following details:
  • Identification of access area identification, such as a name, coordinates, etc.
  • Access criterion criterion which must be fulfilled for using at least part of at least one access area
  • a law enforcement transaction agreement 578 can comprise the following details:
  • Identification of access area identification, such as a name, coordinates, etc.
  • Law enforcement criterion criterion defining the traffic laws and penalties if a vehicle or user breaches them
  • a law enforcement transaction agreement can be agreed in advance and in combination with a vehicle sharing, toll, access or parking transaction agreement.
  • a data sharing transaction agreement for providing movement and environmental data in order to analyze and/or optimize the traffic system or optimize the route of a vehicle can comprise the following details:
  • Identification of shared data identification of movement and environmental data to be sent by the vehicle and/or data received by the vehicle (traffic system data, differential GPS data, etc.)
  • Shared data criterion (send) criterion which must be fulfilled for using the vehicle data by an analysis or optimization system (e.g. system pays for gathering the data via the vehicle)
  • analysis or optimization system service e.g. vehicle pays for traffic, route optimization or least cost routing data
  • a vehicle logbook transaction agreement 580 can comprise the following details:
  • Identification(s) identification assigned to vehicle or user of vehicle and/or identification assigned to data store (logbook) and/or identities assigned to entities entitled to monitor logbook entries
  • Logbook sensor identification of the sensor(s), data format(s) and protocol (s) to exchange data
  • Logbook service Logbook analytics provided by the peer-to- peer application
  • a vehicle autonomous driving transaction agreement 582 can comprise the following details:
  • Identification(s) identification assigned to vehicle or user of vehicle and/or identification assigned to predefined autonomous driving service or vehicles in the surroundings
  • IPFS decentral file system
  • BigchainDB distributed block chain database
  • separate peer-to-peer applications such as two or more block chains can exist for different traffic systems, such as a parking system, a vehicle sharing system, an access system, a law enforcement system, a traffic control system, a data sharing system and/or a toll system.
  • traffic systems such as a parking system, a vehicle sharing system, an access system, a law enforcement system, a traffic control system, a data sharing system and/or a toll system.
  • At least the above described messages can be hashed together in pairs in a block of the block chain by a Merkle tree.
  • the so-called root hash is noted as a checksum in the header of a block.
  • the block can be coupled with the previous block. Chaining of the blocks can be performed using this root hashes.
  • Each block can include the hash of the entire previous block header in its header. This makes it possible to clearly define the order of the blocks. In addition, this may also prevent the subsequent modification of previous blocks and the messages stored in the previous blocks, since, in particular, the hashes of all subsequent blocks would have to be recalculated in a short time.
  • data feeds can be provided by the peer-to-peer application (so called smart oracles, e.g. information about current traffic situation).
  • Figure 6 shows a schematic view of another embodiment of a traffic system 600 of the invention.
  • nodes and participants 602.2 to 648.2 of the peer-to-peer network 622 are shown.
  • the nodes 602.2, 604.2 may be cars and the peer-to-peer modules of the cars (or mobile terminals or OBD adapters), respectively.
  • the node 640.1 may be realized by a peer-to-peer module integrated in a user terminal.
  • Node 643.2, 644.1 may be the peer- to-peer modules of other vehicles, such as a truck, train, and/or drone.
  • Further nodes 646.1 and 648.2 may be computing devices, e.g. of owner of parking places and/or of vehicle sharing providers.
  • peers 640.1, 644.1, 646.1 and 602.2, 604.2, 643.2, 648.2 are presently illustrated. All peers 640.1, 644.1, 646.1 and 602.2, 604.2, 643.2, 648.2 are comprised by the peer-to-peer network 622. In the present embodiment, however, only a part of the peers 640.1, 644.1, 646.1 and 602.2, 604.2, 643.2, 648.2, in the present case, the peers 640.1, 644.1, 646.1, check the validity of the data stored in the peer-to-peer application messages, such as the motion parameter data, agreements, traffic information data, request messages, and the like. Furthermore, only a part of the entire peers can be configured to store the peer-to-peer application and/or only a part of the peers can be configured to execute the algorithms of a smart contract. Since the validation/verification of e.g.
  • peers 640.1, 644.1, 646.1 especially particularly powerful peers 640.1, 644.1, 646.1, perform the validation and/or optimization algorithms taking more complex pricing or the state of the traffic system into consideration.
  • Validation and optimization can be done on-chain or off-chain.
  • Off-chain validation and/or optimization can be managed by the peer-to-peer application, like the code on the block chain. Powerful means in particular a high computing power. In other words, in the present case a valid entry in the peer-to-peer application, such as a block chain, is assumed if (only) a part of the peers 640.1, 644.1, 646.1 comes to a positive result.
  • a particularly large peer-to-peer network may be divided in two or more clusters.
  • a validation (of a subset of transactions) may only be carried out by the members of one cluster (subset of nodes, e.g. sharding of a block chain to improve the scalability).
  • the peer-to-peer application can be formed using multiple block chains. These block chains are connected via frameworks such as sidechains or smart contracts.
  • Figure 7 shows a diagram of an embodiment of a method according to the present invention.
  • This method can be in particular performed by an arrangement for a vehicle, wherein the arrangement can comprise a peer-to-peer module and a sensor module, as described above.
  • a sensor module senses or detects at least one motion parameter of at least one vehicle. The current value of the detected motion parameter is provided to a peer-to-peer module.
  • the peer-to-peer module transmits the respective value of the motion parameter to a peer-to-peer application.
  • the transmitted data can be saved and/or evaluated by the peer-to-peer application, as described above.
  • Figure 8 shows a diagram of a further embodiment of a method according to the present invention. This method can be in particular performed by a peer-to-peer application, as described above.
  • traffic information data to be provided to one or more vehicles is generated by evaluating at least one motion parameter of at least one vehicle by means of at least one peer-to-peer application. For instance, the at least one motion parameter has been received from a peer-to-peer module of a vehicle.
  • the generated traffic information can be provided to at least peer-to-peer module assigned to at least one vehicle.
  • a secure and automated payment by means of a peer-to-peer network, smart contracts and/or deposits without central authority can be provided. Transaction costs can be further reduced.

Landscapes

  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Chemical & Material Sciences (AREA)
  • Analytical Chemistry (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Traffic Control Systems (AREA)

Abstract

L'invention concerne un système de circulation (200, 300, 400, 600) comprenant au moins un véhicule (202, 302, 304, 402, 602.2, 604.2), au moins un module capteur (221, 321, 421) conçu pour détecter au moins un paramètre de mouvement relatif au véhicule (202, 302, 304, 402, 602.2, 604.2), au moins un module poste à poste (228, 328, 426.2) attribué au véhicule (202, 302, 304, 402, 602.2, 604.2) et conçu pour communiquer avec au moins une application poste à poste (224, 324, 424, 524) d'au moins un réseau poste à poste (222, 322, 422, 622), le module poste à poste (228, 328, 426.2) servant à transmettre au moins le paramètre de mouvement détecté à l'application poste à poste (224, 324, 424, 524) et/ou à recevoir au moins des données d'informations de circulation en provenance de l'application poste à poste (224, 324, 424, 524).
PCT/EP2016/060171 2016-05-06 2016-05-06 Système de circulation WO2017190794A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP16726486.0A EP3453005A1 (fr) 2016-05-06 2016-05-06 Système de circulation
PCT/EP2016/060171 WO2017190794A1 (fr) 2016-05-06 2016-05-06 Système de circulation

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2016/060171 WO2017190794A1 (fr) 2016-05-06 2016-05-06 Système de circulation

Publications (1)

Publication Number Publication Date
WO2017190794A1 true WO2017190794A1 (fr) 2017-11-09

Family

ID=56097071

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2016/060171 WO2017190794A1 (fr) 2016-05-06 2016-05-06 Système de circulation

Country Status (2)

Country Link
EP (1) EP3453005A1 (fr)
WO (1) WO2017190794A1 (fr)

Cited By (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108961807A (zh) * 2018-07-25 2018-12-07 佛山市高明曦逻科技有限公司 无人驾驶汽车智能车位共享系统
CN109087409A (zh) * 2018-07-13 2018-12-25 网云区块链（深圳）有限公司 一种数据处理、信息获取方法、电子设备及存储介质
CN109274768A (zh) * 2018-11-02 2019-01-25 陕西科技大学 一种基于区块链的动力电池状态监测装置与方法
CN109407663A (zh) * 2018-09-04 2019-03-01 上海交通大学 基于区块链的无人驾驶信息安全保障方法和系统
US20190172057A1 (en) * 2016-07-29 2019-06-06 nChain Holdings Limited Blockchain-implemented method and system
WO2019120493A1 (fr) * 2017-12-19 2019-06-27 HELLA GmbH & Co. KGaA Procédé et système d'authentification numérique décentralisée
DE102018201417A1 (de) 2018-01-30 2019-08-01 Volkswagen Aktiengesellschaft Verfahren zum Bereitstellen verifizierter Informationen über ein Verkehrszeichen, Verkehrszeichenanlage sowie Verfahren für ein Navigationssystem zur Verifikation eines Verkehrszeichens
DE102018202592A1 (de) * 2018-02-21 2019-08-22 Audi Ag Verfahren zum Betreiben eines Rechenpools sowie Rechenvorrichtung und Kraftfahrzeug
DE102018202676A1 (de) * 2018-02-22 2019-08-22 Bayerische Motoren Werke Aktiengesellschaft Verfahren zum Authentifizieren eines Benutzers
JP2019177809A (ja) * 2018-03-30 2019-10-17 トヨタ自動車株式会社 制御装置、制御装置用のプログラム、及び制御方法
EP3557459A1 (fr) * 2018-04-17 2019-10-23 Panasonic Intellectual Property Corporation of America Procédé, dispositif de traitement d'informations, système de gestion et programme pour contrôler l'ouverture et la fermeture d'une consigne
CN110533909A (zh) * 2019-09-10 2019-12-03 重庆大学 一种基于交通环境的驾驶行为分析方法及系统
JP2019208200A (ja) * 2018-03-12 2019-12-05 ザ・ボーイング・カンパニーＴｈｅＢｏｅｉｎｇ Ｃｏｍｐａｎｙ ブロックチェーンで強化された航空機空地データ通信システム（ａｃａｒｓ）の通信
CN110602664A (zh) * 2018-06-12 2019-12-20 通用汽车有限责任公司 用于车辆的分布式账本技术通信的方法和系统
IT201800007632A1 (it) * 2018-08-02 2020-02-02 Park Smart Srl Sistema distribuito ad alta innovazione per la gestione di aree delimitate
WO2020033033A1 (fr) * 2018-08-09 2020-02-13 Hrl Laboratories, Llc Attribution anonyme et vote majoritaire dans un environnement compromis
JP2020076877A (ja) * 2018-11-08 2020-05-21 矢崎総業株式会社 セキュアロギングシステム
TWI696374B (zh) * 2018-03-30 2020-06-11 香港商阿里巴巴集團服務有限公司 基於區塊鏈的業務執行方法及裝置、電子設備
US10699574B1 (en) 2019-01-29 2020-06-30 Ford Global Technologies, Llc Parking information sharing system using blockchain
CN111510496A (zh) * 2020-04-16 2020-08-07 山东交通学院 基于区块链信息共享的交通诱导系统及方法
DE102019203990A1 (de) * 2019-03-22 2020-09-24 Robert Bosch Gmbh Verfahren zur Kommunikation zwischen Fahrzeugen eines Fahrzeug-Platoons, um Fahrzeuge in einem Fahrzeug-Platoon zu identifizieren, sowie entsprechende Vorrichtung und Verwendung einer Blockchain zum Identifizieren von Fahrzeugen in einem Fahrzeug-Platoon
DE102019205308A1 (de) * 2019-04-12 2020-10-15 Robert Bosch Gmbh Verfahren und Aktualisierungsvorrichtung zum Aktualisieren eines Umfeldmodells für ein Fahrzeug oder eine Infrastruktureinrichtung
WO2020213516A1 (fr) * 2019-04-18 2020-10-22 三菱電機株式会社 Système de gestion d'entrée/sortie, dispositif d'authentification pour système de gestion d'entrée/sortie, dispositif de gestion pour système de gestion d'entrée/sortie, terminal portatif pour système de gestion d'entrée/sortie, unité mobile pour système de gestion d'entrée/sortie, structure de données pour données de gestion d'entrée/sortie, programme de gestion d'entrée/sortie, et procédé de construction pour système de gestion d'entrée/sortie
EP3731206A1 (fr) * 2019-04-26 2020-10-28 BlackBerry Limited Procédé et système de détection de comportement de trafic et d'alarmes
CN111868772A (zh) * 2018-03-15 2020-10-30 罗伯特·博世有限公司 用于分散地实施交易的系统和方法
US10862908B2 (en) 2018-08-09 2020-12-08 Hrl Laboratories, Llc System and method for consensus ordering of broadcast messages
CN112119420A (zh) * 2018-02-09 2020-12-22 大众汽车股份公司 用于第一道路资源使用者和用于道路资源分配实体的方法、装置和计算机程序
US20200410416A1 (en) * 2018-03-23 2020-12-31 Deutsche Bahn Ag Method for scheduling or controlling the movements of a plurality of vehicles over a network of routes
US10922757B2 (en) 2018-05-29 2021-02-16 Advanced New Technologies Co., Ltd. Blockchain-based commodity claim method and apparatus, and electronic device
CN112733197A (zh) * 2019-10-28 2021-04-30 本田技研工业株式会社 信息管理系统
CN113168661A (zh) * 2018-11-27 2021-07-23 美光科技公司 由去中心化、分布式数据库供电的停车基础设施
US20210253116A1 (en) * 2018-06-10 2021-08-19 Osr Enterprises Ag System and method for enhancing sensor operation in a vehicle
US11132899B1 (en) * 2020-03-26 2021-09-28 Toyota Motor North America, Inc. Acquiring vacant parking spot
EP3764292A4 (fr) * 2019-02-27 2021-12-01 Launch Tech Co., Ltd Procédé d'analyse de données, dispositif électronique et support lisible par ordinateur
US11195365B2 (en) 2018-05-31 2021-12-07 Advanced New Technologies Co., Ltd. Parking charging method, apparatus, and electronic device
WO2022024088A1 (fr) * 2020-07-31 2022-02-03 Pado-Community Gmbh Système de stationnement communautaire
US11288762B2 (en) 2020-03-26 2022-03-29 Toyota Motor North America, Inc. Vacancy processing
CN114648884A (zh) * 2020-12-18 2022-06-21 宝能汽车集团有限公司 车联网区块链系统及基于其的出行方法和存储介质
US11402853B2 (en) * 2019-08-20 2022-08-02 Lg Electronics Inc. Method for controlling platooning and autonomous vehicle based on blockchain
US11752930B2 (en) 2020-03-04 2023-09-12 BlueOwl, LLC Systems and methods for displaying contextually-sensitive braking information
US11801832B2 (en) 2020-03-26 2023-10-31 Toyota Motor North America, Inc. Transport relocation
US11989725B2 (en) 2018-02-09 2024-05-21 Nchain Licensing Ag Blockchain-implemented systems and methods for secure access control
CN112733197B (zh) * 2019-10-28 2024-05-28 本田技研工业株式会社 信息管理系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080132223A1 (en) * 2006-12-04 2008-06-05 Chun-Fu Lin Systems and methods for providing traffic information
US20100302068A1 (en) * 2009-06-01 2010-12-02 Navteq North America, Llc Street parking community application and method
US20140180914A1 (en) * 2007-01-12 2014-06-26 Raj Abhyanker Peer-to-peer neighborhood delivery multi-copter and method
WO2016015041A1 (fr) * 2014-07-25 2016-01-28 Blockchain Technologies Corporation Système et procédé pour créer une chaîne de blocs multi-branche au moyen de règles de protocole configurables

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080132223A1 (en) * 2006-12-04 2008-06-05 Chun-Fu Lin Systems and methods for providing traffic information
US20140180914A1 (en) * 2007-01-12 2014-06-26 Raj Abhyanker Peer-to-peer neighborhood delivery multi-copter and method
US20100302068A1 (en) * 2009-06-01 2010-12-02 Navteq North America, Llc Street parking community application and method
WO2016015041A1 (fr) * 2014-07-25 2016-01-28 Blockchain Technologies Corporation Système et procédé pour créer une chaîne de blocs multi-branche au moyen de règles de protocole configurables

Cited By (68)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11669832B2 (en) * 2016-07-29 2023-06-06 Nchain Licensing Ag Blockchain-implemented method and system for access control on remote internet-enabled resources
US20230360036A1 (en) * 2016-07-29 2023-11-09 Nchain Licensing Ag Blockchain-implemented method and system for access control on remote internet-enabled resources
US20190172057A1 (en) * 2016-07-29 2019-06-06 nChain Holdings Limited Blockchain-implemented method and system
WO2019120493A1 (fr) * 2017-12-19 2019-06-27 HELLA GmbH & Co. KGaA Procédé et système d'authentification numérique décentralisée
CN111512658A (zh) * 2017-12-19 2020-08-07 海拉有限双合股份公司 用于分散式数字认证的方法和系统
CN111512658B (zh) * 2017-12-19 2023-05-02 海拉有限双合股份公司 用于分散式数字认证的方法和系统
US11657665B2 (en) 2017-12-19 2023-05-23 HELLA GmbH & Co. KGaA Method and system for decentralized digital authentication
DE102018201417A1 (de) 2018-01-30 2019-08-01 Volkswagen Aktiengesellschaft Verfahren zum Bereitstellen verifizierter Informationen über ein Verkehrszeichen, Verkehrszeichenanlage sowie Verfahren für ein Navigationssystem zur Verifikation eines Verkehrszeichens
CN112119420A (zh) * 2018-02-09 2020-12-22 大众汽车股份公司 用于第一道路资源使用者和用于道路资源分配实体的方法、装置和计算机程序
US11989725B2 (en) 2018-02-09 2024-05-21 Nchain Licensing Ag Blockchain-implemented systems and methods for secure access control
DE102018202592A1 (de) * 2018-02-21 2019-08-22 Audi Ag Verfahren zum Betreiben eines Rechenpools sowie Rechenvorrichtung und Kraftfahrzeug
DE102018202676A1 (de) * 2018-02-22 2019-08-22 Bayerische Motoren Werke Aktiengesellschaft Verfahren zum Authentifizieren eines Benutzers
JP2019208200A (ja) * 2018-03-12 2019-12-05 ザ・ボーイング・カンパニーＴｈｅＢｏｅｉｎｇ Ｃｏｍｐａｎｙ ブロックチェーンで強化された航空機空地データ通信システム（ａｃａｒｓ）の通信
JP7249821B2 (ja) 2018-03-12 2023-03-31 ザ・ボーイング・カンパニー ブロックチェーンで強化された航空機空地データ通信システム（ａｃａｒｓ）の通信
CN111868772A (zh) * 2018-03-15 2020-10-30 罗伯特·博世有限公司 用于分散地实施交易的系统和方法
US20200410416A1 (en) * 2018-03-23 2020-12-31 Deutsche Bahn Ag Method for scheduling or controlling the movements of a plurality of vehicles over a network of routes
RU2728806C1 (ru) * 2018-03-30 2020-07-31 Алибаба Груп Холдинг Лимитед Способ и аппаратура для выполнения услуг на основе цепочек блоков и электронное устройство
US11049188B2 (en) 2018-03-30 2021-06-29 Advanced New Technologies Co., Ltd. Blockchain-based service execution method and apparatus, and electronic device
US11113769B2 (en) 2018-03-30 2021-09-07 Advanced New Technologies Co., Ltd. Blockchain-based service execution method and apparatus, and electronic device
TWI696374B (zh) * 2018-03-30 2020-06-11 香港商阿里巴巴集團服務有限公司 基於區塊鏈的業務執行方法及裝置、電子設備
JP2019177809A (ja) * 2018-03-30 2019-10-17 トヨタ自動車株式会社 制御装置、制御装置用のプログラム、及び制御方法
US10719884B2 (en) 2018-03-30 2020-07-21 Alibaba Group Holding Limited Blockchain-based service execution method and apparatus, and electronic device
EP3557459A1 (fr) * 2018-04-17 2019-10-23 Panasonic Intellectual Property Corporation of America Procédé, dispositif de traitement d'informations, système de gestion et programme pour contrôler l'ouverture et la fermeture d'une consigne
US10684783B2 (en) 2018-04-17 2020-06-16 Panasonic Intellectual Property Corporation Of America Control method, information processing device, management system, and recording medium
US11500551B2 (en) 2018-04-17 2022-11-15 Panasonic Intellectual Property Corporation Of America Control method, information processing device, management system, and recording medium
US10922757B2 (en) 2018-05-29 2021-02-16 Advanced New Technologies Co., Ltd. Blockchain-based commodity claim method and apparatus, and electronic device
US11023981B2 (en) 2018-05-29 2021-06-01 Advanced New Technologies Co., Ltd. Blockchain-based commodity claim method and apparatus, and electronic device
US11195365B2 (en) 2018-05-31 2021-12-07 Advanced New Technologies Co., Ltd. Parking charging method, apparatus, and electronic device
EP3803529A4 (fr) * 2018-06-10 2022-01-19 OSR Enterprises AG Système et procédé permettant d'améliorer un fonctionnement de capteur dans un véhicule
US20210253116A1 (en) * 2018-06-10 2021-08-19 Osr Enterprises Ag System and method for enhancing sensor operation in a vehicle
CN110602664A (zh) * 2018-06-12 2019-12-20 通用汽车有限责任公司 用于车辆的分布式账本技术通信的方法和系统
CN109087409A (zh) * 2018-07-13 2018-12-25 网云区块链（深圳）有限公司 一种数据处理、信息获取方法、电子设备及存储介质
CN108961807A (zh) * 2018-07-25 2018-12-07 佛山市高明曦逻科技有限公司 无人驾驶汽车智能车位共享系统
WO2020026098A1 (fr) * 2018-08-02 2020-02-06 Park Smart S.R.L. Système réparti à haut niveau d'innovation pour la gestion de zones délimitées
IT201800007632A1 (it) * 2018-08-02 2020-02-02 Park Smart Srl Sistema distribuito ad alta innovazione per la gestione di aree delimitate
WO2020033033A1 (fr) * 2018-08-09 2020-02-13 Hrl Laboratories, Llc Attribution anonyme et vote majoritaire dans un environnement compromis
US10887092B2 (en) 2018-08-09 2021-01-05 Hrl Laboratories, Llc Anonymous allocation and majority voting in a compromised environment
US10862908B2 (en) 2018-08-09 2020-12-08 Hrl Laboratories, Llc System and method for consensus ordering of broadcast messages
CN109407663A (zh) * 2018-09-04 2019-03-01 上海交通大学 基于区块链的无人驾驶信息安全保障方法和系统
CN109274768A (zh) * 2018-11-02 2019-01-25 陕西科技大学 一种基于区块链的动力电池状态监测装置与方法
JP2020076877A (ja) * 2018-11-08 2020-05-21 矢崎総業株式会社 セキュアロギングシステム
EP3888046A4 (fr) * 2018-11-27 2022-04-20 Micron Technology, Inc. Infrastructure de stationnement optimisée par une base de données décentralisée et distribuée
CN113168661A (zh) * 2018-11-27 2021-07-23 美光科技公司 由去中心化、分布式数据库供电的停车基础设施
US11449524B2 (en) 2018-11-27 2022-09-20 Micron Technology, Inc. Parking infrastructure powered by a decentralized, distributed database
US10699574B1 (en) 2019-01-29 2020-06-30 Ford Global Technologies, Llc Parking information sharing system using blockchain
EP3764292A4 (fr) * 2019-02-27 2021-12-01 Launch Tech Co., Ltd Procédé d'analyse de données, dispositif électronique et support lisible par ordinateur
US11945457B2 (en) 2019-02-27 2024-04-02 Launch Tech Co., Ltd. Method for data analysis, electronic device, and computer readable medium
DE102019203990A1 (de) * 2019-03-22 2020-09-24 Robert Bosch Gmbh Verfahren zur Kommunikation zwischen Fahrzeugen eines Fahrzeug-Platoons, um Fahrzeuge in einem Fahrzeug-Platoon zu identifizieren, sowie entsprechende Vorrichtung und Verwendung einer Blockchain zum Identifizieren von Fahrzeugen in einem Fahrzeug-Platoon
DE102019205308A1 (de) * 2019-04-12 2020-10-15 Robert Bosch Gmbh Verfahren und Aktualisierungsvorrichtung zum Aktualisieren eines Umfeldmodells für ein Fahrzeug oder eine Infrastruktureinrichtung
JP7173305B2 (ja) 2019-04-18 2022-11-16 三菱電機株式会社 入退管理システム、入退管理システムの認証装置、入退管理システムの管理装置、入退管理システムの携帯端末または移動体、入退管理プログラム、および入退管理システムの構築方法
CN113748421A (zh) * 2019-04-18 2021-12-03 三菱电机株式会社 进出管理系统、进出管理系统的认证装置、进出管理系统的管理装置、进出管理系统的便携终端、进出管理系统的移动体、进出管理数据的数据结构、进出管理程序、以及进出管理系统的构筑方法
WO2020213516A1 (fr) * 2019-04-18 2020-10-22 三菱電機株式会社 Système de gestion d'entrée/sortie, dispositif d'authentification pour système de gestion d'entrée/sortie, dispositif de gestion pour système de gestion d'entrée/sortie, terminal portatif pour système de gestion d'entrée/sortie, unité mobile pour système de gestion d'entrée/sortie, structure de données pour données de gestion d'entrée/sortie, programme de gestion d'entrée/sortie, et procédé de construction pour système de gestion d'entrée/sortie
JPWO2020213516A1 (ja) * 2019-04-18 2021-10-28 三菱電機株式会社 入退管理システム、入退管理システムの認証装置、入退管理システムの管理装置、入退管理システムの携帯端末または移動体、入退管理データのデータ構造、入退管理プログラム、および入退管理システムの構築方法
US11244565B2 (en) 2019-04-26 2022-02-08 Blackberry Limited Method and system for traffic behavior detection and warnings
EP3731206A1 (fr) * 2019-04-26 2020-10-28 BlackBerry Limited Procédé et système de détection de comportement de trafic et d'alarmes
US11402853B2 (en) * 2019-08-20 2022-08-02 Lg Electronics Inc. Method for controlling platooning and autonomous vehicle based on blockchain
CN110533909A (zh) * 2019-09-10 2019-12-03 重庆大学 一种基于交通环境的驾驶行为分析方法及系统
CN110533909B (zh) * 2019-09-10 2020-11-06 重庆大学 一种基于交通环境的驾驶行为分析方法及系统
CN112733197B (zh) * 2019-10-28 2024-05-28 本田技研工业株式会社 信息管理系统
CN112733197A (zh) * 2019-10-28 2021-04-30 本田技研工业株式会社 信息管理系统
US11752930B2 (en) 2020-03-04 2023-09-12 BlueOwl, LLC Systems and methods for displaying contextually-sensitive braking information
US11132899B1 (en) * 2020-03-26 2021-09-28 Toyota Motor North America, Inc. Acquiring vacant parking spot
US11288762B2 (en) 2020-03-26 2022-03-29 Toyota Motor North America, Inc. Vacancy processing
US11801832B2 (en) 2020-03-26 2023-10-31 Toyota Motor North America, Inc. Transport relocation
CN111510496B (zh) * 2020-04-16 2023-04-07 山东交通学院 基于区块链信息共享的交通诱导系统及方法
CN111510496A (zh) * 2020-04-16 2020-08-07 山东交通学院 基于区块链信息共享的交通诱导系统及方法
WO2022024088A1 (fr) * 2020-07-31 2022-02-03 Pado-Community Gmbh Système de stationnement communautaire
CN114648884A (zh) * 2020-12-18 2022-06-21 宝能汽车集团有限公司 车联网区块链系统及基于其的出行方法和存储介质

Also Published As

Publication number Publication date
EP3453005A1 (fr) 2019-03-13

Similar Documents

Publication Publication Date Title
WO2017190794A1 (fr) Système de circulation
US10601836B2 (en) Observation system
US20220398149A1 (en) Minimizing transport fuzzing reactions
US20230315435A1 (en) Software updates based on transport-related actions
US11861950B2 (en) Device modification from transport operation
US20240025293A1 (en) Transport battery health
US20230382406A1 (en) Vehicle action determination based on occupant characteristics
US20230226941A1 (en) Electric transport charging determination
US11987144B2 (en) Transport energy transfer using real-time cost information
US11752889B2 (en) Fractional energy retrieval
US20220222762A1 (en) Transport recharge notification
US20220274593A1 (en) Transport-related object avoidance
US11776397B2 (en) Emergency notifications for transports
US20240167831A1 (en) Electric vehicle routing to alternate charging stations
US20240054563A1 (en) Auto insurance system
US20240109449A1 (en) Determining vehicle charging locations
US11917395B2 (en) Connected vehicle services privacy and protection
US11894136B2 (en) Occupant injury determination
US11608030B2 (en) Vehicle surveillance system and early vehicle warning of potential threat
US20230296388A1 (en) Predictive routes for vehicles
US20220279475A1 (en) Detection of aberration on transport
US20230211782A1 (en) Corrective actions for unsafe transports
US20230074898A1 (en) Transport limitation for data reads
US20240157951A1 (en) Real-time modification from vehicle operations
US20230252801A1 (en) Completing a transaction by a transport

Legal Events

Date Code Title Description
DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16726486

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2016726486

Country of ref document: EP

Effective date: 20181206