Method for managing access rights for a vehicle

Abstract

The invention relates to a method for managing access rights for a vehicle, in particular for an electric bicycle, by means of a preferably mobile terminal and a backend, the method having the following method steps: sending a request, by means of the mobile terminal, for a vehicle ID to the vehicle; providing the vehicle ID to the mobile terminal; sending a request, by means of the mobile terminal, for a token to the backend on the basis of the vehicle ID; generating the token on the basis of the vehicle ID; providing the token to the mobile terminal; providing the token to the vehicle by means of the mobile terminal; adapting a firewall by means of the vehicle on the basis of the token.

Description

[0001] Description

[0002] title

[0003] Procedure for for a

[0004] State of the art

[0005] DE 10 2022 203 517 A1 describes a control device for an electric bicycle.

[0006] Disclosure of the invention

[0007] The invention relates to a method for access rights management for a vehicle, in particular for an electric bicycle, by a preferably mobile terminal and a backend, comprising the method steps:

[0008] - Request of a vehicle ID by the mobile device to the vehicle;

[0009] - Providing the vehicle ID to the mobile device;

[0010] - Request of a token by the mobile device to the backend based on the vehicle ID;

[0011] - Generation of the token based on the vehicle ID;

[0012] - Providing the token to the mobile device;

[0013] - Provision of the token to the vehicle via the mobile device;

[0014] - Adaptation of a firewall by the vehicle based on the token. This can advantageously enable secure communication between the mobile device and the vehicle.

[0015] The vehicle can be a motor-driven vehicle such as a motorcycle, an electric bicycle or an e-scooter, or a motorless vehicle, for example a motorless bicycle. In the context of this application, an electric bicycle is understood to mean, in particular, a bicycle that has a drive unit for assisting the rider. The electric bicycle is preferably designed as an e-bike, a pedelec, an S-pedelec, a cargo bike, a folding bike or the like. The drive unit has a motor, which can be designed, for example, as a mid-engine or as a hub motor. The motor is preferably designed as an electric motor. The drive unit is connected to a power supply unit for supplying the drive unit with power.The energy supply unit is preferably designed as a battery pack and has a battery housing, which is preferably detachably connected to a frame of the bicycle. The electric bicycle preferably has a control unit, wherein the control unit of the electric bicycle is assigned to an electronic system. The electronic system preferably comprises a sensor unit, wherein the sensor unit can comprise, for example, motion sensors, torque sensors, speed sensors, GNSS receivers, magnetic sensors, or the like. In addition, the electronic system in particular comprises at least one communication interface for wirelessly connecting the electric bicycle to the mobile device and / or a server. The communication interface can be designed, for example, as a short-range communication interface, in particular as a Bluetooth interface or as a WiFi interface, for connecting to the mobile device.

[0016] The mobile device can be embodied, for example, as a smartwatch, a smartphone, or the like. In the context of this application, a non-mobile device is understood to mean a stationary device such as a desktop computer. Alternatively or additionally, the communication interface can comprise a long-range communication interface, for example, a 2G, 3G, 4G, or 5G interface for wirelessly connecting the electric bicycle to the server. The backend can comprise, for example, a server and / or a cloud.

[0017] The vehicle ID is designed in particular as identification information intended for the unique identification of the vehicle. The vehicle ID can, for example, be generated or provided during assembly and / or data input of the vehicle. The vehicle ID can, for example, comprise information relating to a manufacturer, a model, a year of manufacture, specific installed components, etc. The vehicle ID is stored and retrievable in particular in a memory unit of the vehicle's electronics. Alternatively or additionally, it is conceivable that, instead of or in addition to the vehicle ID, certification information is requested by the mobile device, wherein the certificate information is designed to validate a signature. The certificate information can advantageously be used to verify the authenticity of the vehicle ID or other requested vehicle information.

[0018] In the context of this application, a token should be understood in particular as security information that is designed to authenticate and / or authorize the mobile device vis-à-vis the vehicle. Alternatively or additionally, it is also conceivable that the certification information is determined based on the vehicle ID and made available to the vehicle via the mobile device. This is particularly advantageous if the vehicle does not yet have any certification information at this time or if it has already expired. The expiration information can relate to individual or all data points. It is also conceivable that the expiration information includes different points in time and / or validity periods for different data points. The certification information thereby includes expiration information.

[0019] In the context of this application, a firewall is to be understood in particular as a security mechanism designed to prevent unauthorized access to the vehicle. The firewall is designed in particular to monitor data traffic between the vehicle and external devices, such as the mobile terminal. In particular, the firewall is designed to restrict certain ports or services and to control access to them based on the token. The ports or services preferably correspond to the previously described data points via which the respective data can be exchanged, read, or adapted. The firewall is designed in particular such that, when connected to a mobile terminal, at least one port or service is always open via which the vehicle ID and / or the certification information can be provided.The firewall is preferably adjusted by opening additional ports or services.

[0020] Furthermore, it is proposed that the token include an access list. This advantageously allows different access rights to be controlled via the backend. The access list can, for example, be designed as an access list of vehicle data points that can be read and / or modified by the mobile device.

[0021] It is further proposed that the token include expiration information. This advantageously enables access to the vehicle via the mobile device even without a connection to the backend. The expiration information can include, for example, an expiration date or a validity period.

[0022] It is also proposed that the token be provided to the vehicle dynamically. This can advantageously further optimize access rights management. Dynamic token provisioning means that the token, in particular the token's access list, is created at the time the mobile device requests the backend.

[0023] Furthermore, it is proposed that the token be verified by the vehicle before the firewall is adapted. This can advantageously increase the security of the system. In particular, the token is signed with the certificate information, preferably using asymmetric cryptography, which includes a cryptographic key pair consisting of a public key and a private key.

[0024] It is further proposed that the mobile terminal be connected to the vehicle via a first communication interface and to the backend via a second communication interface, wherein the first communication interface and the second communication interface are preferably configured differently. Preferably, the first communication interface is configured as a short-range communication interface, and the second communication interface is configured as a long-range communication interface.

[0025] It is also proposed that the vehicle have a first communication channel and a second communication channel, wherein the first communication channel is always open and the second communication channel enables additional communication. This can advantageously enable a secure connection to be established. The first communication channel and the second communication channel differ in the ports or services. The first communication channel preferably comprises the ports for requesting and / or transmitting the vehicle ID and / or the certification information. In addition, the first communication channel also comprises ports for transmitting the token. The second communication channel preferably comprises the ports for reading operating information of the vehicle, which is detected, for example, by the vehicle's sensors.The operating information can be, for example, a vehicle speed, a vehicle battery charge level, a vehicle geographical position, a vehicle status, a current vehicle setting, or the like. Alternatively or additionally, it is conceivable for the second communication channel to also include ports or services for controlling or configuring the vehicle, for example, for updating the vehicle's firmware, changing a vehicle setting, such as an assistance mode of the vehicle's drive unit, or locking the vehicle to protect against unauthorized access.

[0026] Furthermore, it is proposed that the second communication channel be designed to be openable or adaptable based on a token transmitted via the first communication channel. This advantageously allows the second communication channel to be controlled via the mobile device.

[0027] Furthermore, it is proposed that if the connection between the vehicle and the mobile device is interrupted, the firewall be adjusted, in particular the second communication channel is closed. This can advantageously provide a particularly secure system.

[0028] It is also proposed that the token be stored in the mobile device. This advantageously allows access to the vehicle via the mobile device even without a connection to the backend. Furthermore, it is proposed that the backend generates a further token for the vehicle based on the vehicle ID and the vehicle's certification information, which is intended for a further mobile device. This advantageously enables access to the vehicle for further mobile devices, for example for acquaintances of the user or for use in vehicle sharing. The token and the further token preferably differ from one another, in particular in the respective access list and / or the respective expiration information.

[0029] It is further proposed that the additional token be provided to the additional mobile device via the backend. Provision can occur either spontaneously or upon request from the mobile device.

[0030] It is also suggested that the additional token be requested via the mobile device. Alternatively, it is also conceivable that the additional token be requested via the additional mobile device.

[0031] Furthermore, it is proposed that a pairing between the vehicle and the mobile device be carried out before the vehicle ID is requested by the mobile device.

[0032] Drawings

[0033] Further advantages emerge from the following drawing description. The drawings, the description, and the claims contain numerous features in combination. Those skilled in the art will also expediently consider the features individually and combine them into further meaningful combinations.

[0034] They show:

[0035] Fig. 1 shows a schematic view of a system with a backend, a vehicle, and a mobile device; Fig. 2 shows a flowchart with a method for access rights management;

[0036] Fig. 3 is a flowchart showing a complementary procedure for access rights management.

[0037] Description of the embodiments

[0038] In Fig. 1, a system 10 comprising a backend 12, a vehicle 14 in the form of an electric bicycle 16 and a mobile terminal 100 is shown in a schematic view.

[0039] The electric bicycle 16 has a housing in the form of a frame 20 or a bicycle frame. Two wheels 22 are connected to the frame 20. The electric bicycle 16 also has a power supply unit 24 in the form of a battery pack. The electric bicycle 16 further has a drive unit 26 comprising an electric motor or auxiliary motor. The electric motor is preferably designed as a permanent magnet-excited, brushless DC motor. The electric motor is designed, for example, as a mid-mounted motor, although a hub motor or the like is also conceivable. The electric bicycle 16, in particular the drive unit 26 of the electric bicycle 16, is supplied with power via the power supply unit 24. The power supply unit 24 can be fastened to the frame 20 from the outside, as shown, or can be integrated into the frame 20.

[0040] The electric bicycle 16 comprises an electronic system comprising a control unit (not shown) designed to control or regulate the electric bicycle 16, in particular the electric motor. The electric bicycle 16 has a pedal crank 28. The pedal crank 28 has a pedal crankshaft (not shown).

[0041] The electronics and the drive unit 26 with the electric motor and the pedal crankshaft are at least partially arranged in a drive housing 27 connected to the frame 20. The drive movement of the electric motor is preferably transmitted to the pedal crankshaft via a gear (not shown), wherein the amount of assistance provided by the drive unit 26 is controlled or regulated by means of the electronics. The control unit is designed to actuate the drive unit such that the rider of the electric bicycle 16 is assisted when pedaling. Preferably, the control unit is designed to be operable by the rider so that the rider can adjust the level of assistance. The electric bicycle 16 has, for example, a light assistance mode and a strong assistance mode, wherein the drive unit offers greater assistance to the rider in the strong assistance mode.

[0042] The electronics of the electric bicycle 16 comprise a sensor unit. The sensor unit comprises a plurality of sensor elements, which are arranged, for example, in different components and / or different areas of the electric bicycle 16. By way of example, the sensor unit comprises at least one sensor element in the form of an inertial sensor. The inertial sensor is designed to detect a movement, an acceleration, and / or an orientation of the two-track vehicle 14. The inertial sensor can be designed, for example, as an acceleration sensor and / or as a gyro sensor. In addition, the sensor unit comprises, for example, a position sensor element for detecting position information, in particular for detecting geographical coordinates. In addition, the sensor unit comprises, for example, a torque sensor and a yaw rate sensor. The previously described sensor elements are arranged, for example, in the drive housing 27 of the drive unit 26.In addition, the sensor unit comprises, for example, a brightness sensor for detecting the brightness of the environment, wherein the brightness sensor is arranged in the user interface 50.

[0043] The electric bicycle 16 also comprises a user interface 50, wherein the user interface 50 comprises an operating unit 30 for operating the electric bicycle 16. The operating unit 30 has, for example, an on / off switch (not shown in detail), wherein the electric bicycle 16, in particular the drive unit 26, is designed to be activated by actuating the switch. Furthermore, the electronics are designed to be controllable by the user via the operating unit 30. For example, the assistance mode of the electric bicycle 16 can be selected by operating the operating unit 30. By way of example, the user interface 50 further comprises a display unit (not shown) for displaying operating data or other information provided by the control unit of the electric bicycle 16 or the mobile terminal 100.

[0044] Alternatively or additionally, it is also conceivable for the electric bicycle 16 to have a receptacle for the mobile terminal 100, wherein in the connected state the mobile terminal 100 and the electric bicycle 16 are mechanically and / or electrically connected and the mobile terminal 100 preferably forms the user interface for operating the vehicle 14. An electrical connection is to be understood in particular as a wired connection for exchanging energy, for example for charging the mobile terminal 100 by the electric bicycle 16, and / or for exchanging data and information, for example via a CAN connection.

[0045] The mobile terminal 100 has at least one short-range communication interface that corresponds to the short-range communication interface of the electric bicycle 16. The short-range communication interface is embodied, for example, as a Bluetooth interface. Furthermore, the mobile terminal 100 comprises at least one long-range communication interface for wireless communication with a server. The long-range communication interface is embodied, for example, as an LTE interface. Furthermore, the mobile terminal 100 has a display unit 104 embodied as a touch-sensitive screen, wherein the mobile terminal 100 can be controlled via the touch-sensitive screen.

[0046] The mobile device 100 has an operating system on which various application software (APPs) can be installed. Installation typically occurs via the long-range communication interface of the mobile device 100. The mobile device 100 has a bicycle app 102 designed to display operating information and / or control the vehicle 14.

[0047] To ensure the functionality of the bicycle app 102, the mobile device 100 must have access to the vehicle 14, in particular to the control unit of the electric bicycle 16. By accessing the control unit, the mobile device can read and / or modify data from the vehicle 14. However, the vehicle 14 has a firewall that prevents unauthorized reading and receiving of data and information. The vehicle 14 has a first communication channel and a second communication channel, which differ from one another, for example, in their data points.

[0048] Figure 2 shows a flowchart describing a method for access rights management for the vehicle 14.

[0049] In a step 200, the bicycle app 102 is installed on the mobile device 100.

[0050] In a further and particularly optional step 202, the mobile device 100 is connected to the vehicle 14 via the short-range communication interface. This can be done, for example, via a Bluetooth pairing process. The pairing process pairs and connects the mobile device 100 and the electric bicycle 16. If the mobile device 100 is physically separated from the electric bicycle 16, the wireless communication is also disconnected, although they remain in the paired state.

[0051] If wireless data communication between the vehicle 14 and the mobile device 100 is generally possible, which was made possible, for example, by the pairing process, a request is sent by the mobile device 100 to the vehicle 14 in a further step 204. The request is made via the first communication channel of the vehicle 14, which is preferably always open, so that communication is possible even without access rights. The request from the mobile device 100 includes a request for a vehicle ID and certification information.

[0052] At the request of the mobile terminal 100, the vehicle 14

[0053] Vehicle ID and, if present, certification information of the vehicle 14 are provided to the mobile terminal 100 in a further step 206. For example, no certification information is provided because the vehicle 14 has never been connected to a bicycle app 102, and no certification information was generated and stored in the memory unit of the vehicle 14 during the manufacturing or assembly process.

[0054] In a further step 208, the mobile device 100 then requests a token from the backend 12. The request from the mobile device 100 includes the vehicle ID of the vehicle 14. If certificate information is also provided, this is sent with the vehicle ID to the backend 12. The token request is made via the long-range communication interface of the mobile device 100.

[0055] In a further step 210, the request from the mobile device 100 is checked by the backend 12, and if the check is successful, a token is generated by the backend 12. Preferably, the token is user-specific and intended only for the bicycle app 102 that sent the request to the backend 12. For example, the token can be intended for a specific user ID of the bicycle app 102. The token preferably includes an access list and expiration information.

[0056] In an optional step 212, certification information is additionally generated by the backend 12, since the vehicle 14 does not yet have any.

[0057] In a further step 214, the token and the certification information are sent to the mobile device 100. The token is preferably stored on the mobile device 100.

[0058] In a further step 216, the token and the certification information are sent to the vehicle 14 via the first communication channel.

[0059] In a step 218, the token is verified by the vehicle 14. This can be done, for example, based on the certification information and / or the expiration information. The expiration information can, for example, be a period of 1 year during which the token is valid. In a further step 220, the firewall of the vehicle 14 is adapted based on the token. In particular, the firewall is adapted such that a second communication channel is opened for the mobile device 100, in particular for the bicycle app 102. For the second communication channel, ports and / or services are opened for the mobile device 100, wherein the opening enables access by reading and / or receiving specific data points for the mobile device 100. The adaptation of the firewall, in particular which ports are opened, is carried out based on the access list of the token.Thus, the backend 12 can advantageously determine the scope within which the mobile terminal 100 receives access to vehicle 14.

[0060] For example, the access list is designed such that the vehicle app 102 receives access to various data points, such as information from the sensor unit in the form of a current drive power, a speed signal from the vehicle 14, and / or a charge level of the battery pack 24. Furthermore, the access list is designed such that the bicycle app 102 receives access to further system information of the vehicle 14, which is determined and / or controlled, for example, by the electronics or the control unit. The system information can be, for example, a remaining range of the battery pack 24, a current support mode and / or possible support modes of the vehicle 14, information about the installed components of the vehicle 14, a current position of the vehicle 14, a locking function of the vehicle 14, or other system information known to those skilled in the art.

[0061] If the connection between the mobile terminal 100 and the vehicle 14 is severed, for example by switching off the mobile terminal 100 and / or the vehicle 14, the firewall is adapted in a step 222, preferably the second communication channel is closed.

[0062] In order to enable control of the vehicle 14 by the mobile terminal 100 again, the token stored on the mobile terminal 100 must be provided to the vehicle 14 again in a step 224. The described access rights management is preferably designed such that only the owner of the vehicle 14 receives maximum access to the vehicle 14. A second mobile terminal 300, on which the same bicycle app 102 is installed, can thus initially only connect to the vehicle 14, in particular pair it, and thus gain access to the first communication channel. However, the backend 12 will not generate a token for the second mobile terminal 300 based on the vehicle ID and the certification information of the vehicle 14, which can be provided to the second mobile terminal 300 via the first communication channel. This advantageously protects the vehicle 14 from unauthorized access.

[0063] To still allow the vehicle 14 to be used by other users with a second mobile terminal 300, release information is provided to the backend 12. An exemplary method is shown in a flowchart in Figure 3.

[0064] In a first step 302, the release information is provided to the backend 12. The release information can, for example, be provided by the owner of the vehicle 14 and the mobile device 100. The release information can, for example, include information regarding a user ID of the bicycle app 102 of the second mobile device 300. It is also conceivable that the release information also includes information regarding the duration of the release. For example, it is conceivable that the user of the vehicle app 102 of the mobile device 100 selects from a list which user ID is permitted access to the vehicle 14. It is also conceivable that the user of the vehicle app 102 of the second mobile device 300 submits a request for use, which is provided to the mobile device 100 for approval directly or indirectly via the backend 12.It is also conceivable that the release information includes information about which bicycle components are to be released. For example, it is conceivable that all bicycle components are released so that the vehicle 14 can be used, or that only individual bicycle components, such as the energy storage device 24, are released so that it can also be used in another vehicle. In a second step 304, the backend 12 generates a second token. As described above, the token includes an access list and expiration information. The access list can correspond to the previously described access list for the mobile device 100 or can be restricted such that not all information and functions are made available to the second mobile device 300. The expiration information can be adapted based on the release information, for example, limited to a short period of time of just one day.

[0065] In a third step 306, the second token is provided to the second mobile terminal 300. The second mobile terminal 300, in particular the bicycle app 102 of the second mobile terminal 300, can communicate with the vehicle 14 via a second communication channel using the second token, essentially analogously to the method described above. The second token can be transmitted to the vehicle 14 in a step 308. Thus, the owner of the vehicle 14 and user of the mobile terminal 100 can advantageously allow another user of the vehicle 14 access to its functions.

[0066] The system 10 is preferably designed as a proprietary system in which the vehicle 14 or the in particular electronic vehicle components, preferably the drive unit 26, the energy supply unit 24 and the electronics, the backend 12 and the bicycle app 102 are essentially assigned to the same manufacturer.

Claims

Claims 1 . Method for access rights management for a vehicle (14), in particular for an electric bicycle, by a preferably mobile terminal (100) and a backend (12), comprising the method steps: Request of a vehicle ID by the mobile terminal (100) to the vehicle (14); Providing the vehicle ID to the mobile device (100); Requesting a token by the mobile terminal (100) to the backend (12) based on the vehicle ID; Generation of the token based on the vehicle ID; Providing the token to the mobile device (100); Providing the token to the vehicle (14) by the mobile terminal (100); Adaptation of a firewall by the vehicle (100) based on the token.

2. Method according to claim 1, characterized in that the token comprises an access list 3. Method according to one of the preceding claims, characterized in that the token comprises expiration information 4. Method according to one of the preceding claims, characterized in that the provision of the token to the vehicle (14) is dynamic 5. Method according to one of the preceding claims, characterized in that before adapting the firewall, the token is sent by the vehicle (100) is verified.

6. Method according to one of the preceding claims, characterized in that the mobile terminal (100) is connected to the vehicle (14) via a first communication interface and to the backend (12) via a second communication interface 7. Method according to one of the preceding claims, characterized in that the vehicle (100) has a first communication channel and a second communication channel, wherein the first communication channel is always open and the second communication channel enables additional communication.

8. The method according to claim 7, characterized in that the second communication channel is designed to be openable or adaptable based on a token transmitted via the first communication channel.

9. Method according to one of claims 7 or 8, characterized in that in the event of a connection interruption between the vehicle (14) and the mobile terminal (100), the firewall is adapted, in particular the second communication channel is closed.

10. Method according to one of the preceding claims, characterized in that the token is stored in the mobile terminal (100).

11. Method according to one of the preceding claims, characterized in that the backend (12) generates a further token for the vehicle (14) based on the vehicle ID and the certification information of the vehicle (14), which token is provided for a further mobile terminal (300).

12. The method according to claim 11, characterized in that the further token is provided to the further mobile terminal (300) via the backend (12).

13. Method according to one of claims 11 or 12, characterized in that the further token is requested via the mobile terminal (100).

14. Method according to one of the preceding claims, characterized in that before the request for the vehicle ID by the mobile terminal (100) a pairing is carried out between the vehicle (14) and the mobile terminal (100).

Images