Method for managing a digital key, computer program, device and vehicle

Abstract

Embodiments of the present invention provide a method for managing a digital key. The method comprises receiving request data indicative of a request to generate a digital key for a vehicle and obtaining information about a generated digital key. The information about the generated digital key is obtained based on the request data. It also comprises storing usage information about the generated digital key. By storing the usage information about the generated digital key, the key can be managed. That is, storing can enable management of the generated digital key. For example, by storing the usage information, a period of occupancy of the vehicle can be stored.This avoids the need to generate another digital key for the vehicle, which could lead to overcrowding of the vehicle.

Description

[0001] Exemplary embodiments of the present invention relate to a method for managing a digital key, a computer program, a device and a vehicle, in particular but not exclusively to a concept for storing usage information via a generated digital key.

[0002] When managing a vehicle fleet, access to individual vehicles is only possible with a physical key. For private vehicles, access via a digital key is already possible. This digital key is defined in more detail, for example, in the CCC (Car Connectivity Consortium) Digital Key Release 3 v1.1. However, the use of the digital key is primarily reserved for private vehicles. In the future, a reduction in physical keys and a corresponding increase in the use of digital keys could also be of interest for vehicle fleets. However, the end-customer use case described in the CCC cannot be directly implemented for fleet-managed vehicles.

[0003] Therefore, there is a need to improve the management of a digital key. The procedure, the device, the computer program, and the vehicle address this need according to the independent claims.

[0004] Examples of implementations are based on the core idea that a method for managing a digital key can be provided. This can improve the use of a vehicle by multiple users. In particular, it can prevent vehicle overcrowding.

[0005] Exemplary embodiments relate to a method for managing a digital key. The method includes receiving request data indicative of a request to generate a digital key for a vehicle and triggering the generation of a digital key based on the request data. Furthermore, the method includes obtaining information about the generated digital key. The method also includes storing usage information about the generated digital key. Storing this usage information enables the management of the generated digital key. That is, storing the generated digital key allows for its management.

[0006] For example, storing usage information allows for the recording of vehicle occupancy periods. This avoids the need to generate an additional digital key for the vehicle, which could lead to over-occupancy.

[0007] In one embodiment, the method can further include obtaining additional query data indicative of a request to generate another digital key for the vehicle and comparing the usage information about the generated key with the additional query data. If no conflict exists between the query data and the usage information, the method can further include triggering, based on the additional query data, the generation of another digital key, obtaining information about the additional generated digital key, and storing additional usage information about the additional generated digital key. By comparing the usage information with the additional query data, a conflict between multiple generated digital keys can be avoided.For example, it can prevent multiple digital keys from being issued for the same vehicle for the same period. This avoids over-utilization of the vehicle. Furthermore, the matching process can allow for the creation of multiple digital keys for the same vehicle. In this case, the digital keys for the same vehicle can be for different usage periods. For example, a user can receive a digital key in advance, eliminating the need for a communication connection when the vehicle is handed over. This can also improve vehicle utilization.

[0008] In one embodiment, if a conflict exists between the request data and the usage information, the procedure can further include sending a rejection message indicating that generating a further digital key is not possible. Sending this rejection message informs the user that the vehicle is unavailable. Accordingly, the user can request a different vehicle for use and / or adjust the request period.

[0009] In one embodiment, obtaining the digital key can involve sending a key request to an external server to receive the digital key and receiving the digital key from that external server. That is, the key generation can be performed by an external device. Accordingly, the method can be carried out on a device configured as an intermediary service. This allows a security aspect of the method to be considered independently of a security aspect of generating a digital key.

[0010] In one embodiment, the method can further include receiving a reservation request for a vehicle and checking the vehicle's availability based on the stored usage information. The method can also include sending availability information about the vehicle's availability. Sending this availability information allows a user to be notified of the vehicle's availability, enabling them, for example, to book the vehicle more conveniently.

[0011] In one embodiment, the method can further include sending usage information to notify the user that the vehicle is in use. By sending this usage information, another device, such as a user terminal, can be directly informed of vehicle use without having to send a further request. This can improve the user experience when booking the vehicle.

[0012] In one embodiment, the method can further include receiving information about the termination of use of the transmitted digital key and updating the usage information based on this information. For example, usage can be terminated by the expiration of a booking period, the return of the vehicle, or the cancellation of the booking. Optionally or alternatively, usage can also be terminated by the revocation of the digital key user's authorization. Receiving this information allows outdated usage information to be updated, thus preventing the generation of a new digital key for the vehicle from being affected by outdated usage information.

[0013] Exemplary embodiments also include a computer program for carrying out one of the methods described herein, if the computer program runs on a computer, a processor, or a programmable hardware component.

[0014] Another embodiment is a device for managing a digital key. The device comprises an interface for communication with a communication device (for example, a user terminal and / or a server for generating a digital key) and a data processing circuit configured to perform at least one of the methods described herein. Further embodiments include a vehicle equipped with a device as described herein.

[0015] Examples of implementation are explained in more detail below with reference to the accompanying figures. These show: Fig. Figure 1 shows a schematic representation of a procedure for managing a digital key; Fig. 2 shows an architecture for implementing a method according to the invention; Fig. Figures 3a-3c show a flow diagram of another method according to the invention; and Fig. Figure 4 shows a block diagram of an embodiment of a device for managing a digital key.

[0016] Several embodiments are now described in more detail with reference to the accompanying drawings, in which some of these embodiments are illustrated. For the sake of clarity, the thickness dimensions of lines, layers, and / or regions may be exaggerated in the figures.

[0017] Fig. Figure 1 shows a schematic representation of a procedure 100 for managing a digital key. The procedure 100 involves receiving 110 request data indicative of a request to generate a digital key for a vehicle. The request data can be received, for example, from a user's terminal device or an administration server (for managing vehicle bookings). The request data can be indicative of a period of vehicle use and / or a desired vehicle for use. That is, the request data can include information necessary to determine vehicle use. In particular, the request data can be used to determine the need to generate a digital key for a specific vehicle and / or a specific period.

[0018] Procedure 100 further includes triggering step 120, based on the request data, the generation of a digital key. For example, a request to generate the digital key can be sent to a device configured for Connected Fleet Access (CFA). This means the digital key is generated entirely externally to Procedure 100.

[0019] Procedure 100 further includes obtaining, based on the request data, information about the generated digital key. For example, the information can be obtained by generating a digital key. That is, Procedure 100 can include generating the digital key. Alternatively, the information can be obtained by receiving information about a generated digital key. For example, information about a generated digital key can be received from a device configured for connected fleet access. Procedure 100 can then be used solely for storing usage information. The generation and / or transmission of the digital key or key information can be performed by at least one external device.

[0020] Furthermore, the process includes storing 140 units of usage information about the generated digital key. This usage information is indicative of a vehicle for which a digital key has been created. This means that the usage information prevents the generation of another digital key that could conflict with the already generated digital key. This prevents a vehicle from being assigned a key. Storing 140 units of usage information thus enables the management of a generated digital key. In particular, for fleet-managed vehicles, this allows for monitoring and management of fleet vehicle availability. This enables the use of one digital key for a fleet vehicle while simultaneously allowing for the management of the digital key for that fleet vehicle.Procedure 100 can therefore enable the use of a CCC-compliant digital key for fleet vehicles. For example, procedure 100 can be executed by a database server. Usage information 140 can be stored on the database server. In particular, usage information, i.e., whether a digital key has already been issued, can be stored for a plurality of fleet vehicles, advantageously for each one. Optionally, information can also be stored as to whether a new digital key can be issued for a fleet vehicle because no (valid) digital key has currently been issued for that fleet vehicle. That is, information can be stored on the database server for a plurality of fleet vehicles, in particular for each fleet vehicle, as to whether a digital key has been issued for the fleet vehicle or not, and / or can be issued.

[0021] Optionally, the procedure can include sending key information indicative of the digital key. In this case, receiving the information about a generated digital key can be considered receiving the key information. The key information can be sent to the same device from which the request data was received. For example, the digital key can be sent to a user terminal or an administration server. Alternatively, the key information can be sent to a different device than the one from which the request data was received. For example, the request data may have been received by an administration server, and the key information can be sent to a user terminal. In this case, the request data can include information about the user terminal to which the digital key is to be sent.The key information can include a URL that allows retrieval of the digital key. Alternatively, the key information can include the digital key itself.

[0022] Procedure 100 enables vehicle management through the administration of the vehicle's digital keys. This prevents, for example, double bookings of the vehicle. Furthermore, it allows for the unambiguous determination of who was authorized to access the vehicle at any time (e.g., in the event of a hit-and-run accident, traffic violation proceedings, etc.). This improves vehicle monitoring.

[0023] In one embodiment, the method 100 can further comprise obtaining additional query data indicative of a request to generate another digital key for the vehicle and comparing the usage information about the generated key with the additional query data. If no conflict exists between the query data and the usage information, the method 100 can further comprise triggering, based on the additional query data, the generation of another digital key, obtaining information about the additional generated digital key, and storing additional usage information about the additional generated digital key. The comparison of the usage information with the additional query data can be performed to determine the availability of the vehicle.Accordingly, based on usage information, a determination can be made as to whether an additional digital key can be generated for the vehicle. The digital key and the additional digital key cannot, in particular, allow simultaneous use of the vehicle. This prevents over-occupancy of the vehicle. That is, the additional digital key can only be valid for a period during which the digital key is not valid. Obtaining the additional digital key can be done in the same way as obtaining the initial digital key.

[0024] Optionally, the request data can be indicative of multiple vehicle usage periods. This means the request data can encompass several desired usage periods for the vehicle. Accordingly, by comparing the usage information, a suitable usage period for generating the next digital key can be determined. This can improve vehicle utilization.

[0025] In one embodiment, if a conflict exists between the request data and the usage information, the procedure can further include sending a rejection message indicating that generating a further digital key is not possible. Sending this rejection message informs the user that the vehicle is unavailable. Consequently, the user can generate a request for a different vehicle. This can improve the user experience.

[0026] In one embodiment, obtaining the digital key (130) can involve sending a key request to an external server to receive the digital key and receiving the digital key from the external server. In this case, the digital key can be generated independently of the process (100). For example, the process (100) can be executed by a database server, and the generation of the digital key can be performed by a certification authority. The database server and the certification authority can be two different devices. This allows a security aspect for a device to execute the process (100) to be independent of a security aspect for generating a digital key. In particular, the required security of the device for performing the process (100) can be lower than that required for generating a digital key.This simplifies the execution of procedure 100.

[0027] Alternatively, as described above, procedure 100 can also include the generation of the digital key. In this case, the device, for example the database server, can generate the digital key. That is, the device can include the database server and simultaneously act as a certification authority. This eliminates the need for an interface between different devices.

[0028] In one embodiment, Method 100 may further include receiving a reservation request for a vehicle and checking the vehicle's availability based on the stored usage information. Method 100 may also include sending availability information about the vehicle's availability. This availability information can be sent to the same device that received the request data. Sending the availability information can inform a user about the vehicle's availability, allowing the user to modify their vehicle booking request based on the vehicle's availability. This can improve the user experience.

[0029] In one embodiment, method 100 can further include sending usage information to indicate vehicle usage. Sending this usage information can inform another device about the vehicle's availability. For example, the usage information can be sent to a fleet booking system. In this case, the fleet booking system can be independent of the device for carrying out method 100. That is, the device for carrying out method 100 can simply serve as a database server for storing the usage information.

[0030] Alternatively, the device for carrying out method 100 can also be configured to provide a booking system. That is, the booking system can be executed by the same device as method 100. In this case, method 100 can further include receiving the reservation request. The reservation request can be determined, for example, based on user input. For instance, a user can provide a parameter, such as a vehicle type, for booking a vehicle. Based on this parameter, a suitable vehicle can be identified from the fleet. A comparison with the usage information can then be performed for the selected vehicle. If a digital key cannot be generated for the selected vehicle, another suitable vehicle from the fleet can be identified. Accordingly, multiple suitable vehicles from the fleet can be checked.By combining the booking system with procedure 100, a more suitable vehicle can be identified. This allows for better processing of user requests, thereby improving the user experience.

[0031] In one embodiment, the method 100 can further include receiving information about the termination of use of the transmitted digital key and updating the usage information based on this information. For example, usage can be terminated by the expiration of a booking period, the return of the vehicle, or the cancellation of the booking. Optionally or alternatively, usage can also be terminated by the revocation of the user's authorization for the digital key. Receiving this information allows the stored usage information to be updated. This can, in particular, improve vehicle utilization.

[0032] A user terminal device (UT) can generally be any device capable of wireless communication. Specifically, the UT can be a mobile device, such as one designed to be carried by a user. The UT can be, for example, a user terminal or user equipment (UE) as defined by the respective communication standards used for mobile communication. The UT could be, for instance, a mobile phone like a smartphone, or another type of mobile communication device such as a smartwatch, laptop, tablet computer, or autonomous augmented reality glasses. Alternatively, the UT could also be a near-field communication (NFC) card.

[0033] A device can generally be any device capable of wireless communication. The device can communicate within a mobile communication system. For example, the device can communicate in / via a mobile communication system. The mobile communication system can include a variety of transmitting points and / or base stations capable of transmitting radio signals to the device.

[0034] Further details and aspects are mentioned in connection with the exemplary embodiments described below. The in Fig. The embodiment shown in 1 may include one or more optional additional features corresponding to one or more aspects related to the proposed concept or one or more embodiments described below (e.g. Fig. 2 - 4) were mentioned.

[0035] Fig. Figure 2 shows an architecture for implementing a method 200 according to the invention. The method 200 can be restricted to the database server 220. In this case, the method 200 can be implemented as described in Figure 2. Fig. As described in section 1, the process includes receiving request data, obtaining information about the generated digital key, and storing usage information. That is, the process 200 can be solely for managing information about the use of a digital key. The generation and exchange of the digital key can take place externally to the database server 220. Accordingly, the database server 220 can be a device that is separate from a device for connected fleet access 230, a device for a booking system 240, and a device for generating a digital key 250.

[0036] Optionally, as described above, the procedure 200 can include further processes. For example, the procedure 200 can be performed by the database server 220 and the connected fleet access device 230. In this case, the database server 220 and the connected fleet access device 230 can be configured as a single device 222. Receiving information about a generated digital key is then a receiving of key information, and the procedure 200 further includes sending the key information.

[0037] Optionally, as described above, generating the digital key can also be part of procedure 200. In this case, procedure 200 can be performed by a device 252. The device 252 can include device 222 and device 250. In this case, procedure 200 can also include sending the generated digital key.

[0038] Optionally, as described above, procedure 200 can also include receiving a reservation request. In this case, procedure 200 can be performed by a device 242. The device 242 can include the device for a booking system 240.

[0039] In process 208, database server 220 receives query data. In process 218, database server 220 can send information to device 230 to generate the digital key based on the query data. That is, database server 220 can trigger the generation of the digital key. In process 248, database server 220 can receive information about the generated digital key from device 230. Therefore, processes 218 and 248 are necessary to store the usage information.

[0040] In 228, device 230 can send a request to device 250 to generate the digital key. Device 250 can, for example, be a certification authority trained to generate a digital key. Device 250 can therefore be specifically trained to provide Smart Access (SMACC). The Smart Access can be server-based, particularly as specified in the CCC.

[0041] In 238, device 230 can receive key information. This key information could be, for example, a URL that allows user device 260 to receive a digital key from device 250. The key information can thus enable external transmission of the digital key in 268. Based on the received key information, device 230 can generate the information about the generated digital key and send it to database server 220 in 248. Furthermore, device 230 can send the key information to device 240 in 248. Device 240 can then send the key information to user device 260 in 258. Based on the received key information, user device 260 can receive the digital key from device 250 in 268.

[0042] The device for connected fleet access 230 can enable connected fleet access. In particular, the device 230 can be configured to perform authentication for a fleet or a fleet vehicle (Fleet Authentication Service, FAS).

[0043] Accordingly, in its simplest embodiment, the database server 220 can be configured as a digital key box 220. The digital key box 220 can be independent of the booking system device 240, the digital key issuance device 250, and the connected fleet access device 230.

[0044] The Digital Key Box 220 can be connected to the booking system 240 by a user. When booking a vehicle, it will no longer be necessary to borrow a physical key to open / start the vehicle; instead, the loan can be processed digitally by issuing a digital key, which can be stored on the user's terminal device 260, thus enabling vehicle access and engine start. The Digital Key Box 220 manages this digital key system.

[0045] The procedure 200 can be used, for example, wherever vehicle key boxes with physical keys are currently used, such as at companies, dealers, etc.

[0046] A booking request can be generated by a user using booking software 270.

[0047] Further details and aspects are mentioned in connection with the exemplary embodiments described below and / or above. The in Fig. The embodiment shown in Figure 2 may include one or more optional additional features corresponding to one or more aspects related to the proposed concept or one or more of the above (e.g., Fig. 1) and / or the embodiments described below (e.g. Fig. 3 (comprehensive) Fig. 3a-3c) - 4) were mentioned.

[0048] Fig. Figures 3a-3c show a flowchart of another method 300 according to the invention. Fig. Figure 3a shows the process of requesting a digital key and generating the digital key.

[0049] In section 302, a user can make a booking for a fleet vehicle. For example, the booking can be made using a device for a booking system (see reference 240 in [reference number]). Fig. 2) can be carried out. In 304, the device for a booking system can send the booking or information about the booking to a database server. That is, through 304, the database server can receive query data. The query data can be indicative of a billing period, a usage period, a vehicle identification, and / or a booking identification.

[0050] In step 306, the database server can check whether the vehicle for which a booking was requested is a fleet vehicle. If the requested vehicle is not a fleet vehicle, the procedure can be terminated in step 300. If the requested vehicle is a fleet vehicle, a key request can be sent in step 308. The key request can be sent to a device for connected fleet access (see reference 230 in [reference number]). Fig. 2).

[0051] In section 310, the connected fleet access device can perform a key request verification. If the verification is successful, the connected fleet access device can forward the key request to a digital key generation device (see reference 250 in [reference number]). Fig. 2) be forwarded.

[0052] In 312, the device for generating a digital key can generate a digital key and a URL associated with that digital key. In 314, the URL can be forwarded to the device for connected fleet access. In 316, the URL can be forwarded to the database server. That is, in contrast to the procedure in Fig. 2. The database server can receive the URL from the device for a connected fleet access.

[0053] In section 318, the database server generates a link for accessing the digital key. Optionally, the link can also include booking information. The link can then be sent to the booking system device. The booking system device can forward the link in section 320 to the user, for example, a user device. For instance, the booking system device can send the link via email.

[0054] In step 322, a user can select a link. Selecting this link allows a login to the database server in step 324. In step 326, the database server can verify the booking. For example, the database server can check if the booking is valid, such as whether it has not been canceled, whether the user of the user's device is authorized, and / or whether the booking time has expired. If the booking time has not yet expired, the process can be terminated in step 300.

[0055] When the booking time is reached, a check can be performed in step 328 to see if the digital key for the vehicle is available. If the digital key is not available, for example, because another digital key has already been issued for the vehicle for the usage period, the procedure can be terminated in step 300. If the digital key is available, it can be made available to the user's device in step 332. Usage information about the provided digital key can also be stored in step 330.

[0056] Fig. Figure 3b shows the deletion of a digital key at the end of fleet vehicle use. In Figure 350, the user can end vehicle use. To do this, the digital key can be deleted from the user's device. In Figure 352, the digital key generation device can delete the digital key. Information about the deletion of the digital key can be forwarded to the database server by the connected fleet access device in Figure 354. In Figure 356, the database server can update the usage information for the digital key. Specifically, the database server can save the vehicle for which the digital key was issued as available. Accordingly, the database server can enable the generation of another digital key for the vehicle upon a subsequent request.In 358, the device for a booking system can send a notification to the user terminal that the booking has ended.

[0057] Fig. Figure 3c shows the cancellation of a fleet vehicle booking. In Figure 370, a user can cancel the fleet vehicle booking. In Figure 372, the booking system device can review and cancel the booking. Information about the canceled booking, such as the vehicle identification number, can be sent to the database server. In Figure 374, the database server can store information about the canceled booking. This prevents the misuse of a digital key by a user device for a canceled booking.

[0058] Further details and aspects are mentioned in connection with the exemplary embodiments described below and / or above. The in Fig. The embodiment shown in Figure 3 may include one or more optional additional features corresponding to one or more aspects related to the proposed concept or one or more of the above (e.g., Fig. 1 - 2) and / or the embodiments described below (e.g. Fig. 4) were mentioned.

[0059] Fig. Figure 4 shows a block diagram of an embodiment of a device 30 for managing a digital key. The device 30 comprises an interface 32 for communication with, for example, a device for a booking system or a device for generating a digital key. The device 30 further comprises a data processing circuit 34 configured to carry out at least one of the methods described herein, for example, the method which relates to one of the Fig. 1-3 is described. Further embodiments include a vehicle 40 with a device 30. Alternatively, the device 30 can also be part of a server, for example a database server.

[0060] The in Fig. The interface 32 shown in Figure 4 can, for example, correspond to one or more inputs and / or one or more outputs for receiving and / or transmitting information, such as digital bit values ​​based on a code, within a module, between modules, or between modules of different entities. The interface 32 can, for example, be configured to communicate with other network components via a (radio) network or a local area network.

[0061] In exemplary embodiments, the data processing circuit 34 can correspond to any controller or processor, or to a programmable hardware component. For example, the data processing circuit 34 can also be implemented as software programmed for a corresponding hardware component. In this respect, the data processing circuit 34 can be implemented as programmable hardware with appropriately adapted software. Any processor, such as digital signal processors (DSPs), can be used. These exemplary embodiments are not limited to a specific type of processor. Any processor, or even multiple processors, are conceivable for implementing the data processing circuit 34.

[0062] As in Fig. As shown in Figure 4, the interface 32 can be coupled to the respective data processing circuit 34 of the device 30. In examples, the device 30 can be implemented by one or more processing units, one or more processing devices, or any means of processing, such as a processor, a computer, or a programmable hardware component that can be operated with appropriately adapted software. Likewise, the described functions of the data processing circuit 34 can also be implemented in software, which is then executed on one or more programmable hardware components. Such hardware components can be a general-purpose processor, a digital signal processor (DSP), a microcontroller, etc.The data processing circuit 34 can be able to control the interface 32, so that any data transmission that takes place via the interface 32 and / or any interaction in which the interface 32 may be involved can be controlled by the data processing circuit 34.

[0063] In one embodiment, the device 30 can comprise a memory and at least one data processing circuit 34 which is functionally coupled to the memory and is configured to perform one of the methods described above.

[0064] In examples, interface 32 can correspond to any means of receiving, receiving, transmitting, or providing analog or digital signals or information, such as any connector, contact, pin, register, input terminal, output terminal, conductor, track, etc., that enables the provision or receipt of a signal or information. Interface 32 can be wireless or wired and can be configured to communicate with other internal or external components, such as sending or receiving signals or information.

[0065] In at least some embodiments, the vehicle 40 can correspond, for example, to a land vehicle, a watercraft, an aircraft, a rail vehicle, a road vehicle, a car, a bus, a motorcycle, an all-terrain vehicle, a motor vehicle, or a truck. The device 30 can, for example, be a part of or a control unit of the vehicle 40.

[0066] Further details and aspects will be mentioned in connection with the exemplary embodiments described above. The in Fig. The embodiment shown in section 4 may include one or more optional additional features corresponding to one or more aspects related to the proposed concept or one or more of the above (e.g. Fig. The exemplary embodiments described in sections 1-3 were mentioned.

[0067] Further embodiments include computer programs for carrying out one of the methods described herein, when the computer program runs on a computer, a processor, or a programmable hardware component. Depending on specific implementation requirements, embodiments of the invention can be implemented in hardware or in software. The implementation can be carried out using a digital storage medium, for example, a floppy disk, a DVD, a Blu-ray disc, a CD, a ROM, a PROM, an EPROM, an EEPROM, a FLASH memory, a hard disk, or other magnetic or optical storage media on which electronically readable control signals are stored. These control signals can interact with, or interact with, a programmable hardware component in such a way that the respective method is carried out.

[0068] A programmable hardware component can be a processor, a computer processor (CPU = Central Processing Unit), a graphics processor (GPU = Graphics Processing Unit), a computer, a computer system, an application-specific integrated circuit (ASIC = Application-Specific Integrated Circuit), an integrated circuit (IC = Integrated Circuit), a system-on-a-chip (SOC = System on Chip), a programmable logic element, or a field-programmable gate array with a microprocessor (FPGA = Field Programmable Gate Array).

[0069] The digital storage medium can therefore be machine-readable or computer-readable. Some embodiments thus include a data carrier containing electronically readable control signals capable of interacting with a programmable computer system or programmable hardware component to execute one of the methods described herein. An embodiment is therefore a data carrier (or a digital storage medium or a computer-readable medium) on which the program for performing one of the methods described herein is recorded.

[0070] In general, embodiments of the present invention can be implemented as a program, firmware, computer program, or computer program product with program code or as data, wherein the program code or data is / are effective in carrying out one of the methods when the program runs on a processor or a programmable hardware component. The program code or data can, for example, also be stored on a machine-readable medium or data carrier. The program code or data can be in the form of, among other things, source code, machine code, bytecode, or other intermediate code. Reference symbol list 30 Device 32 interface 34 Data processing circuit 40 vehicles 100 procedures 110 Received request data 120 Triggering the generation of a digital key 130 Receiving information about the generated digital key 140 spokes of a usage information 150 Sending a key piece of information 200 procedures 208 Receiving request data 218 Sending information to generate the digital key 220 database servers 222 Device comprising database server and connected fleet access 228 Sending a request to generate the digital key 230 Device for a connected fleet access 238 Receiving key information 240 Device for a booking system 242 Device comprising database server, connected fleet access and booking system 248 Receiving information about a generated digital key 250 Device for generating a digital key 252 Device comprising database server, connected fleet access and booking system, generation of a digital key 260 user terminals 268 Send digital key 270 booking software 300 procedures 302 Booking a fleet vehicle 304 Sending request data 306 Check for fleet vehicle 308 Sending a key request 310 Checking the key request 312 Generating a digital key 314 Redirecting a URL 316 Redirecting a URL 318 Generating a link 320 Forwarding the link 322 Selecting the link 324 Login to the database server 326 Checking the booking 328 Check if a digital key is available 330 Saving usage information 332 providing the digital key 350 Termination of fleet vehicle use 352 Deleting a digital key 354 forwarding information about the deleted digital key 356 Updating usage information 358 Sending a notification of termination of use 370 Cancellation of a booking 372 Checking and canceling the booking 374 Saving information about the downloaded booking

Claims

[1] A method (100) for managing a digital key, comprising receiving (110) request data indicative of a request to generate a digital key for a vehicle; triggering, based on the request data, a generation of a digital key; obtaining information about the generated digital key; and storing (140) usage information about the generated digital key. [2] The method (100) according to claim 1, further comprising Receipt of further request data is indicative of a request to generate another digital key for the vehicle; Matching the usage information via the generated key with the other request data; and If there is no conflict between the request data and the usage information, trigger the generation of another digital key based on the additional request data; Receiving information about the additional generated digital key; and storing further usage information about the additional generated digital key. [3] The method (100) according to claim 2, further comprising, if a conflict exists between the request data and the usage information, sending a rejection information about a non-possible generation of the further digital key. [4] The method (100) according to any of the preceding claims, comprising obtaining the digital key: Sending a key request to an external server to receive the digital key; and Received from the external server, the digital key. [5] The method (100) according to any of the preceding claims, further comprising receiving a reservation request for a vehicle; Checking vehicle availability based on stored usage information; and Sending availability information about the availability of the vehicle. [6] The method (100) according to any of the preceding claims, further comprising sending the usage information to provide information about the use of the vehicle. [7] The method (100) according to any of the preceding claims, further comprising receiving information about the termination of use of the transmitted digital Key; and updating usage information based on the information received about the Termination of use. [8] A computer program for carrying out one of the methods (100) according to any of the preceding claims, wherein the computer program runs on a computer, a processor, or a programmable hardware component. [9] A device (30) for managing a digital key, comprising: an interface (32) for communication with a communication device; and a data processing circuit (34) for carrying out at least one of the procedures (100) is designed according to one of claims 1-7. [10] A vehicle (40) with a device (30) according to claim 9.

Images