Control of fleet-related access to motor vehicle

Abstract

The invention relates to a method (200) for controlling a fleet-related access to a motor vehicle (102), comprising: reading fleet-related carrier information (124) from a first physical carrier (110); and forwarding (128) the read carrier information (124) to a fleet management device (104) related to the assignment of the motor vehicle (102) to the vehicle fleet.

Description

Technical Field

[0001] This invention relates to a technique for controlling fleet-related access to motor vehicles. Furthermore, the technique includes a fleet management device for allocating motor vehicles to a vehicle fleet. Background Technology

[0002] Motor vehicles can be secured using a solution designated as a "digital key" by the Connected Car Alliance (CCC). For example, a complete technical description can be found in the technical specification "Digital Key Release 4." This solution specifies that security functions of the motor vehicle (such as central locking and / or immobilizer) are controlled based on asymmetric encryption methods. A digital vehicle key using an encrypted data structure can be assigned to the user. Authentication based on this key utilizes a wireless connection between the mobile device and the motor vehicle.

[0003] For example, a digital vehicle key may include a private portion and a public portion. The private portion can be stored in the secure environment of a mobile device. Conversely, a digital key is also assigned to the vehicle, and the private portion of this digital key can be stored in the on-board control unit. The public portion is known to the user. To control security or access functions, bilateral authentication is performed based on the corresponding private and public key portions. If authentication is successful, the requested security function on the vehicle is controlled, allowing access to or use of the vehicle, etc.

[0004] The vehicle owner (“Owner” as defined by CCC) may share their key; this shared, assigned, or derived key allows a user (“Friend”) to use (and share) the vehicle if necessary. Digital vehicle keys can be transmitted or forwarded between smartphones (i.e., between users, for example in private applications), but can also be assigned to users by a server (based on the owner’s device, or SBOD).

[0005] In all cases, a digital vehicle key must be present or stored in the vehicle. In private applications, this storage is achieved through a process called "owner pairing," in which the vehicle owner requests a password from the vehicle's backend. To have the authority to make this request, the owner must provide proof of ownership, which is verified by the vehicle. For example, two remote keys (Key-Fob) can be assigned to a vehicle. During owner pairing, both remote keys must be located inside the vehicle or in the car, and this serves as proof of ownership.

[0006] Unlike private applications, vehicles designated for fleet use are first assigned to the fleet and then managed by the backend (including SBOD - key allocation). Assigning vehicles to the fleet may include, for example, assigning fleet configurations. These configurations may affect vehicle functionality, HMI (Human-Machine Interface) output, etc. Fleet vehicle management, or control, and vehicle infleeting may involve managing lists involving VINs, FIDs (Vehicle Identification Numbers), or VINs, and the use of remote keys and tokens.

[0007] For cost reasons, a preferred solution for classifying vehicles into a fleet is one where classification can be done on-site or by staff in the vehicle. However, vehicles are typically configured for private applications at the factory. In other words, vehicles may be specially configured from the vehicle manufacturer and / or the relevant fleet operator, for example, in the form of embedded modules, software / firmware, etc. But such solutions are very complex.

[0008] There is a need for a simple and quick way to classify vehicles into a vehicle fleet through direct interaction on-site or on the vehicle itself. Summary of the Invention

[0009] The objective of this invention is to provide an improved technical solution for controlling fleet-related access to motor vehicles. This invention addresses this objective through the technical solution outlined in the independent claims. The dependent claims define preferred embodiments.

[0010] A first aspect of the invention relates to a method for controlling fleet-related access (Zugriff) to motor vehicles. The method can be implemented on the vehicle side or in an application (“App”), for example, in an application for use on a mobile device for fleet management. The method includes: reading fleet-related carrier information from a first physical carrier; and sending or forwarding the read carrier information to a fleet management device relating to the allocation of motor vehicles to a vehicle fleet.

[0011] A second aspect of the invention also relates to a method for controlling fleet-related access to motor vehicles. This method can be implemented in a backend for vehicle and / or fleet operators, typically a backend for fleet management. The method includes: receiving forwarded fleet-related carrier information; assigning a motor vehicle to a vehicle fleet based on the received carrier information; and sending a description relating to the configuration of the vehicle fleet to which the vehicle is assigned.

[0012] The embodiments of the present invention enable operators (e.g., operators located in vehicles) to quickly, easily, and safely assign vehicles to a vehicle fleet without requiring special preparation of the vehicles, such as by adding built-in modules, manually downloading or loading fleet configurations, etc.

[0013] The physical carrier can be a memory card, smart card, or other hardware token. Its card-like form could be, for example, a USB token, or a remote key. Alternatively, the physical carrier could exist as a smart device, such as a smartphone or a comparable mobile device, on which applications or mini-applications with corresponding functions are hosted.

[0014] Typically, the physical carrier may have a carrier structure, such as a card or stick, which carries, contains, or accommodates data storage devices, chips, etc. For example, if the carrier is constructed as a memory card, it may be, for example, a plastic card, chip card, smart card, etc., with integrated circuits (chips), hardware logic devices, memory, and / or a microprocessor.

[0015] The memory of the physical carrier contains at least one carrier information that can be readablely stored. This carrier information may be an identification number (ID), which, for example, uniquely identifies the carrier (unique worldwide, or unique relative to a carrier provider, vehicle manufacturer, chip manufacturer, etc.). In addition to the carrier ID, other information may be stored, which may be part of the ID or in the form of additional data, data structures, etc.

[0016] In one particular implementation, the carrier may, for example, include an NFC (Near Field Communication) chip with a readable UID (“Unique Identifier”). Accordingly, reading of the physical carrier may be based on NFC technology. However, generally, any known or future-developed wireless, contactless, and / or short-range technologies can be used to read the carrier, such as Bluetooth, Bluetooth Low Energy, UWB (Ultra-Wideband), Firebird, WLAN (Wireless Local Area Network), RFID (Radio Frequency Identification), iBeacon, etc. Implementations in which the carrier carries a (one-dimensional) barcode or (two-dimensional) QR code, which is then read by active or passive sensors, such as those based on optical, ultraviolet, and / or infrared sensors.

[0017] Users, operators, etc. can read the carrier, for example by holding the carrier (i.e., card, token, etc.) at the reading device, such as at the NFC reading device of a vehicle or mobile device, or at a reading device based on other technologies, such as at the camera of a vehicle or mobile device.

[0018] In some exemplary embodiments of the first aspect of the present invention, the first physical carrier includes a fleet management card or fleet card that does not contain any vehicle-related information, i.e., does not contain information related to the motor vehicle or each currently assigned motor vehicle.

[0019] In some embodiments of the first aspect of the invention, the method further includes the steps of: reading information related to a motor vehicle from a second physical carrier; and sending an instruction related to the read motor vehicle-related information to a fleet management device. Some embodiments include: verifying the read motor vehicle-related information; and sending an instruction related to the verification to the fleet management device.

[0020] The second physical carrier can be, for example, a remote key (Fob) associated with a single vehicle, or a smart card, setup card, etc., associated with a single vehicle. Reading can be performed, for example, in situations where an operator provides proof of ownership. This is used in a simple manner to authorize fleet-related access.

[0021] In some embodiments, the first physical carrier and the second physical carrier may have the same form and may exist, for example, in the form of smart cards, wherein vehicle cards are configured to be associated with vehicles and fleet cards are configured to be associated with fleet operators and vehicle fleets. The associated design may include, for example, a visual design on the front and / or back of the card that is easily noticeable to an operator.

[0022] In one implementation, fleet information is first read from the fleet card, and then vehicle information is read from the remote key or vehicle card. From the operator's perspective, this process is intuitively easy to understand, given the known key distribution methods on vehicles, and therefore can be performed simply, quickly, and without errors.

[0023] Some embodiments of the first aspect of the invention further include: requesting a signature from a first carrier, for example, in relation to a motor vehicle; and forwarding the requested signature to a fleet management device. Corresponding embodiments of the second aspect of the invention include: receiving a signature from a physical carrier; and verifying the received signature. Such signatures provide a fleet-related access design that protects against abuse and can be used, for example, as a second element in two-factor authentication to ensure that the first carrier is indeed located inside the vehicle.

[0024] Some embodiments of the first aspect of the invention include: forwarding message interactions (handshakes) between a first carrier and a fleet management device, wherein the message interactions are related to the verification of the first carrier. Corresponding embodiments of the second aspect of the invention correspondingly include: a carrier with fleet-related carrier information performing message interactions related to the verification of that carrier.

[0025] Through the aforementioned message exchange, the fleet management device can verify eligibility for fleet-related access (i.e., for adding or removing vehicles from a fleet). Encryption techniques can be employed to ensure the security of the message exchange. The above implementation provides a higher level of security for fleet-related access.

[0026] Some embodiments of the first aspect of the invention further include: receiving a fleet configuration; and applying the fleet configuration to prepare key distribution based on a digital vehicle key in the backend. The preparation may, in particular, include: a vehicle accepting an SBOD (Side-by-Side Activation Device) for key transfer. According to the invention, the downloading or provision of the fleet configuration can be achieved by presenting a fleet card and (if necessary) a vehicle card, thereby eliminating the need for complex manual operations via a human-machine interface (HMI).

[0027] A specific embodiment of the first aspect of the invention further includes: receiving parameters related to a motor vehicle; requesting a signature related to the motor vehicle-related parameters from a first carrier; and forwarding the requested signature to a fleet management device. The parameters can be received from a backend, and the first carrier can be read by a mobile device. Thus, for example, on-site fleet management (including proof of ownership) can be achieved, but the fleet management does not rely on direct interaction with vehicles (e.g., on the vehicles). This simplifies and speeds up fleet-related access to vehicles.

[0028] Some implementations also include pre-receiving selections related to the vehicle. For example, vehicles can be displayed and selected within the application, while fleet management is performed via a website. This increases the flexibility in applying the invention.

[0029] Another aspect of the invention relates to a control device configured to perform the method for controlling fleet-related access to motor vehicles according to the first aspect of the invention.

[0030] Another aspect of the invention relates to a motor vehicle having a reading device for reading at least one physical carrier (e.g., an NFC reader on the motor vehicle) and a control device for text description. For example, the control device may be implemented as part of the motor vehicle's electronic control unit (ECU).

[0031] Another aspect of the present invention relates to a computer program product comprising a program code segment that, when executed on a computer, performs the method described in the first aspect of the present invention through the program code segment.

[0032] Another aspect of the invention relates to a mobile device comprising a reading device (e.g., an NFC reading device) for reading at least one physical carrier and a computer program product (e.g., in the form of a fleet management application) with a text description.

[0033] The term "mobile device" as used in this article should be understood as tablet computers, smartphones, smartwatches, etc., and generally refers to any mobile or portable device with, for example, an integrated NFC reader or a camera for reading QR codes.

[0034] The mobile device can also be configured to store a digital vehicle key that can be used to access a motor vehicle. For example, an application from a motor vehicle manufacturer can be implemented on the mobile device. The functionality according to the invention can also be implemented in such an application.

[0035] Another aspect of the invention relates to a backend server configured to perform the method for controlling fleet-related access to motor vehicles according to the second aspect of the invention.

[0036] Another aspect of the invention relates to the use of a physical carrier (e.g., a smart card, an NFC chip card, etc.) for controlling fleet-related access to motor vehicles, comprising: reading fleet-related carrier information from the carrier to send or forward it to a fleet management device, the fleet management device being involved in allocating motor vehicles to a vehicle fleet.

[0037] Another aspect of the invention relates to a vehicle fleet comprising at least one motor vehicle as described herein and a physical carrier configured to read fleet-related carrier information from the physical carrier for forwarding to a fleet management device relating to the allocation of motor vehicles to the vehicle fleet. Attached Figure Description

[0038] The invention will now be described in detail with reference to the accompanying drawings, in which:

[0039] - Figure 1 As a system;

[0040] - Figure 2A This is a flowchart of the first method;

[0041] - Figure 2B This is a flowchart of the second method;

[0042] - Figure 3The flowchart for the third method;

[0043] - Figure 4 This is a flowchart of the fourth method. Detailed Implementation

[0044] Figure 1 A system 100 is illustrated in schematic form, which includes a vehicle 102, a back-end server 104, a mobile device 106, a smart card (“vehicle card”) 108, a smart card (“fleet card”) 110, and a user 112.

[0045] Vehicle 102 has a control device 114, which may be implemented as part of an ECU (Electronic Control Unit), Head-Unit, etc., or as a separate unit. Additionally, vehicle 102 has a near-field communication (NFC) reader 116, for example, located within the interior space of vehicle 102.

[0046] In the following description, the reference numeral "104" is used both to refer generally to one or more back-end units 104 (particularly for the back-end of vehicle 102) and specifically to server 104, which may also be multiple interconnected servers. It should be noted that at least some of the functions of the control device 114 described herein may also operate wholly or partially in the back-end unit 104; however, for clarity, this will not be elaborated upon further.

[0047] A fleet management application 118 is installed on mobile device 106, for example, for fleet management related to vehicle 102 as described below. Fleet management application 118 can be implemented as a standalone application, or it can be implemented as part of another application, such as a vehicle-related application from the vehicle 102 manufacturer, for example, for storing digital vehicle keys for vehicle 102. If fleet management application 118 is implemented as a standalone application, a vehicle-related application can be implemented independently on mobile device 106, but this is not necessary. Furthermore, mobile device 106 has an NFC reader 120, which can be integrated, but for visual illustration purposes, it is not shown here. Figure 1 It is shown in a separate form.

[0048] Smart card 108 (also known as "vehicle card" 108) serves as a carrier for readable vehicle-related information, which can provide proof of ownership of vehicle 102, such as vehicle identification involving vehicle licenses, vehicle registration, contract numbers, etc. This vehicle identification may, for example, be pre-defined by the manufacturer of vehicle 102. Reading vehicle card 108, or vehicle identification 122, can be achieved, for example, via NFC technology, i.e., via NFC reader 116 of vehicle 102 or NFC reader 120 of mobile device 106.

[0049] The smart card 110 (also known as the "fleet card" 110) serves as a carrier for readable fleet-related information, such as a fleet identifier 124, which can be used in the backend 104 to identify vehicle fleets, fleet operators, etc. The fleet identifier can be reserved by the operator of the backend 104 (i.e., the manufacturer and / or fleet operator of vehicle 102).

[0050] The vehicle truck 110 may also contain an encryption element 126, such as an encryption key, which can be used to perform secure message interactions with the backend 104 for purposes such as signing.

[0051] Reading the fleet card 110, or fleet identifier 124, or encryption element 126, can be achieved, for example, through NFC technology, i.e., through the NFC reader 116 of vehicle 102 or the NFC reader 120 of mobile device 106.

[0052] In addition to using the smart card as the "Fleet Card" 110, a general management token (i.e., a hardware token, HW-Token) can also be used, such as a management token in the form of a USB token, or any device with the corresponding function ("smart device").

[0053] In some embodiments, vehicle 102 may be in a standard configuration, i.e., not specifically assigned, for example, in a brand-new factory state, in which it is adopted as a standard private scenario, i.e., a private user purchases vehicle 102 and, for example, attempts to operate it through a user interface such as a host unit or a human-machine interface. However, vehicle 102 should be, for example, assigned to a fleet.

[0054] Fleet card 110 may be associated with a company (or a department of a company), such as a fleet operator, car-sharing service provider, rental vehicle, etc. In embodiments of the invention, in order to access vehicle 102 in a fleet-related manner, i.e., to add vehicle 102 to a fleet, fleet card 110 (or a more general fleet management token, or a smart device running a dedicated app; the latter will not be discussed in detail here) can be used on or independently of vehicle 102, for example, in conjunction with mobile device 106.

[0055] The fleet card 110 has readable logical elements (carrier information or fleet identification 124) and can interact with vehicle 102, for example, via NFC technology, to place vehicle 102 in a context consistent with the purpose of the fleet-related carrier information 122. For example, vehicle 102 can then provide functions that would not be provided in other contexts (i.e., in a context for private users), or conversely, if the fleet-related context is unknown to vehicle 102, vehicle 102 will use a private context according to standards.

[0056] In some embodiments, the fleet card 110, together with the encryption management element 126, can interact with the mobile device 106 via NFC technology, for example, to confirm specific management operations; that is, for example, to provide a signature to confirm a specific action as a second element under a two-factor (or multi-factor) verification framework, or to perform a specific protocol with the backend 104, such as a handshake, session, etc.

[0057] In an alternative implementation, the fleet identifier 124 and the encryption element 126 may be located on separate cards, or the card 110 may only have the fleet identifier 124 without the encryption element 126.

[0058] For direct (“on-site”, e.g., “in the vehicle”) interaction with vehicle 102, smart card or fleet card 110 may be placed on NFC reader 116, kept nearby, etc. inside vehicle 102 (the term “contactless” interaction should also include situations in which card 110 is in contact with reader 116, user 112’s hand not only holds card 110 but also touches reader 116, etc., such situations are known to those skilled in the art).

[0059] In general, the scope of application or effective scope of the vehicle identification card 110, or the identification scenario and configuration scope (such as "fleet", "fleet management", etc.), and accordingly provide corresponding functions to the user 112, such as assigning vehicle 102 to a fleet or classifying vehicle 102 into that fleet.

[0060] In some embodiments, specific preconditions must be met before a function or action can be performed, and vehicle 102 requests and verifies the received data accordingly. For example, in order to classify vehicle 102 into a fleet based on the presentation of fleet card 110 on vehicle 102, a precondition might be the provision of proof of ownership of vehicle 102. This proof may require two elements to prevent misuse.

[0061] In one embodiment, proof of ownership may require the presentation of two remote keys (Key-Fob). In another embodiment, one remote key needs to be verified by vehicle 102 and located within the vehicle's interior space, and instead of presenting a second remote key, other tokens are presented, such as a setup card, vehicle card, or other smart card, chip card, etc., which are presented at NFC reader 116 and used in combination with the remote key as proof of ownership (for clarity, Figure 1 The presentation of the remote key was omitted.

[0062] Vehicle 102 verifies the aforementioned elements (setting card or vehicle card 108 and remote key, or two remote keys, etc.) and forwards the ownership verification result to backend 104. Only then does backend 104 examine the requested action 128 and execute it.

[0063] During the process of assigning vehicle 102, the fleet card 110 data forwarded from vehicle 102 128 determines the fleet to which vehicle 102 should be assigned, and vehicle 102 is assigned to the determined fleet. The fleet management device and / or the vehicle-side backend 104 can generate and save a list of VINs (Vehicle Identification Numbers) listing all the VINs of vehicles 102 operated by the fleet management device.

[0064] Fleet card 110 does not necessarily need to have encryption element 126. For vehicle 102 to be added to or removed from the fleet, the key is that vehicle 102 can determine the fleet-related scenario for the action / access. Therefore, encryption functionality and / or interaction with backend 104 are not necessarily required.

[0065] However, fleet card 110 can use encryption element 126 for a secure handshake 132 with backend 104, or for providing a signature that can be used, for example, to verify a specific interaction. When using encryption element 126 (or other encryption techniques), an application on mobile device 106, such as fleet management application 118, can request a signature from fleet management card 110, such as data associated with functions, actions, or fleet-related access to vehicle 102 134, such as parameters, or a one-time nonce provided by backend 104 to ensure the validity of the signature.

[0066] One embodiment of direct interaction between fleet card 110 and vehicle 102 may involve classifying vehicle 102 into a vehicle fleet, i.e., assigning vehicle 102 to a fleet managed in backend 104. No specific allocation for a fleet or special configuration is stored in vehicle 102. For example, vehicle 102 may be newly manufactured, meaning its standard use or operating scenario may be geared towards private buyers or users.

[0067] Based on the presentation of the fleet card 110 (or equivalent hardware token) at the NFC reader 116 inside the vehicle 102, the vehicle 102 is placed in the 128 fleet entry mode, that is, the vehicle 102 identifies the fleet scene based on the carrier information read from the card 110 and provides the option to enter the fleet.

[0068] In process 130 (which may include one or more steps, a message interaction, etc.), vehicle 102 requests eligibility for inclusion, i.e., requests proof of ownership of vehicle 102 and verifies that proof of ownership (which may be provided, for example, using a factory remote key and / or vehicle card 108). Vehicle 102 forwards relevant information, such as the identifier or ID of fleet management card 110, the status of the provided proof of ownership, etc., to backend 104.

[0069] In process 132, the backend 104 checks the allocation inquiry, determines the target fleet based on the carrier information read from the fleet card 110, and assigns vehicle 102 to the fleet, that is, assigns vehicle 102 to the fleet.

[0070] In process 134, vehicle 102 acquires the fleet configuration and, based on this configuration, receives further fleet-related queries or request messages from backend 104, such as accepting an assigned key (“key sharing”) into the key table in vehicle 102. In this case, vehicle 102 verifies the credentials of the assigned key according to the introduced or existing fleet configuration.

[0071] Another embodiment relates to a scenario where vehicle 102 should be removed from the fleet or vehicle depot. This can also be done without direct interaction with vehicle 102, for example, by controlling, managing, or administering it within the fleet management application 118.

[0072] The removal of vehicle 102 is initiated by personnel 112, such as a fleet administrator, in process 136, selecting vehicle 102 to be removed from the vehicle database in the fleet management application 118. The fleet management application 118 then sends corresponding instructions to the backend 104, such as removal parameters and VIN.

[0073] Backend 104 verifies the received parameters, creates a session, and returns a session identifier (e.g., one-time information) for signing. Fleet management application 118 issues a request on the user interface of mobile device 106 to confirm the swipe by presenting fleet card 110. Fleet card 110 signs the parameters and session identifier. Fleet management application 118 forwards the signature to backend 104. Backend 104 verifies the query and signature and executes the requested operation.

[0074] In another embodiment (not in) Figure 1 As shown in the diagram, vehicles can be controlled or managed through a website, such as adding or removing vehicles. In this case, action parameters, session identifiers, etc., are forwarded to an application, such as the vehicle manufacturer's application (not a fleet management application for mobile devices, such as those for...). Figure 1 (Application 118 described in the embodiment). Subsequently, the application issues a request on the user interface of the mobile device: to confirm the departure by presenting a fleet card. The fleet card generates a signature for confirmation, which is returned to the backend, for example.

[0075] The following will combine Figure 2A and Figure 2B The schematic diagram illustrates another specific embodiment in which a fleet card (or "fleet management card") 110 on vehicle 102 collaborates with a backend (e.g., a fleet management device) 104 for fleet-related access to vehicle 102. Figure 2A The process of method 200 in motor vehicle 102 is shown. Figure 2B The flow of the corresponding method 250 in backend 104 is shown.

[0076] exist Figure 2A In method 200, the process begins at step 202, where a fleet card 110 is presented at the NFC reader 116 of vehicle 102, and fleet-related carrier information is read. In subsequent step 204, a message exchange (“handshake”) related to the verification of the fleet card 110 occurs between the fleet card 110 and the backend 104, and this message exchange is forwarded by vehicle 102 in both directions. This message exchange may include forwarding the read carrier information for use by fleet management devices related to the allocation of vehicle 102 to the vehicle fleet.

[0077] Correspondingly, in Figure 2B In step 252 of method 250, a message interaction is performed with fleet card 110 for verification of fleet card 110. Step 252 may include receiving fleet-related carrier information of card 110 forwarded by vehicle 102 (in other embodiments, the carrier information may be provided before or after the message interaction for verifying card 110).

[0078] A session identifier may also be assigned in step 252. However, in one embodiment, the other steps in backend 104 are executed only after the ownership proof method in vehicle 102 has been successfully executed.

[0079] Therefore, in Figure 2A In step 206 of method 200, the vehicle card 108 is presented at the NFC reader 116 of the vehicle 102, and vehicle-related carrier information is read. In subsequent step 208, the read vehicle-related carrier information is verified, and an instruction related to the verification is sent to the backend 104 or a fleet management device. In the corresponding step 254, an instruction related to the ownership certificate is received in the backend 104.

[0080] In step 256, backend 104—more precisely, based on the carrier information received from card 110—assigns vehicle 102 to a vehicle fleet. In step 258, backend 104 sends a description to vehicle 102 relating to the configuration of the assigned vehicle fleet.

[0081] In the corresponding step 210, vehicle 102 receives the instruction, which may relate to a fleet configuration for key sharing or distribution based on a server-based digital vehicle key (SBOD, server-based owner device) for access to vehicle 102. In step 212, vehicle 102 applies this configuration or is placed in a corresponding scenario or state. Thus, vehicle 102 is, for example, ready to receive a distributed key according to the SBOD method, which vehicle 102 would discard or reject in other scenarios or modes, such as those for private users.

[0082] The method in backend 104 ends in step 260, where vehicle 102 is assigned to the corresponding fleet. The vehicle-side backend can inform the fleet operator's backend of the status of vehicle 102, the status of the corresponding fleet, etc.

[0083] Figure 3 A method 300 for controlling fleet-related access to vehicle 302, such as for classifying vehicle 302 into a vehicle fleet, is illustrated in the form of a schematic sequence diagram. Method 300 can be a specific embodiment of a process that generally corresponds to... Figure 1 Procedures 128 to 134 in the document; and for this purpose, for an explanation of, for example, the details of the definitions and terminology used, see [reference]. Figure 1 Explanation.

[0084] In method 300, the back-end or fleet management device 304 for vehicle 302 collaborates with user 312, who holds a fleet card. This fleet card is specifically held by person 312 at the NFC reader of vehicle 302. Additionally, a vehicle-related card with identification and / or a remote key for vehicle 302 are used.

[0085] Method 300 may be operated by the manufacturer of vehicle 302, with backend 304, for example, in collaboration with a fleet operator or as a service for fleet operators (e.g., fleets with a small number of vehicles). In another embodiment, method 300 may be operated by a fleet operator of a large fleet (e.g., a car rental company, taxi company, car-sharing service provider, etc.). This is collectively referred to as fleet management device 304. Personnel / users 312 may, for example, be employees of the fleet operator.

[0086] The prerequisite for the method flow 300 described below is that the fleet operator / fleet management device 304 has a fleet management token (e.g., in the form of a smart card) that is assigned to one of the fleets or the fleet operated by the fleet management device 304. Vehicle 302 is also assigned a hardware token, such as a smart card (“Setup-Card”). Both smart cards are configured for interaction with vehicle 302.

[0087] Overall process (also refer to here) Figure 1 This may include presenting the fleet card near, at, or on the NFC reader of vehicle 302 to place vehicle 302 into fleet management mode, allocation mode, etc. The vehicle card is then presented to the NFC reader. For this purpose, privilege verification can be performed relative to the vehicle-side backend 304, for example, based on carrier information (e.g., identifier) ​​read from the fleet card. Backend 304 assigns vehicle 302 to the fleet associated with the fleet card owner, as explained by the read carrier information. Subsequently, server-based key allocation can be performed according to the corresponding vehicle fleet configuration.

[0088] It needs to be clarified again that the fleet card is not associated with a specific vehicle (e.g., vehicle 302). When the fleet card is presented to the reader of vehicle 302, the fleet card (or other hardware token) allows vehicle 302 to distinguish between a "use or operating mode for fleet inclusion" and an "operating mode for private use." The fleet card can be used outside of vehicle 302 to generate signatures, for example, via a smartphone application. The fleet card can be assigned to a specific fleet operator, which can be a business, such as a small or medium-sized enterprise, where fleet management is only a part of business activities.

[0089] The fleet card can also exist as a hardware token, such as a USB hardware token. In other embodiments, the fleet card can also generally exist as a smart device with corresponding functions, such as for... Figure 1 The fleet card 110 is as described herein. In one embodiment, the fleet card may be configured for use with a small application for setting up the card.

[0090] It should be noted that the following steps are simplified based on the process according to the present invention.

[0091] Adding vehicle 302 to the fleet begins in step S01, whereby personnel 312, inside vehicle 302, present a fleet card to an NFC reader. In one embodiment, where an explicit trigger signal is given to backend 304, a handshake or message exchange is performed between the fleet card and backend 304 in step S02. In step S03, backend 304 verifies or validates the legitimacy and generates an addition session. Backend 304 specifically verifies the fleet card and identifies the fleet operator.

[0092] In an alternative embodiment, where the fleet card interacts only with vehicle 302, a signature is generated by the fleet card and verified by the vehicle in step S04.

[0093] In step S05, vehicle 302 is placed in swipe mode. In step S06, vehicle 302 outputs a corresponding pop-up window, for example: "To swipe the vehicle..."<FLOTTEN_NAME> The fleet must place the setup card on the NFC reader. The remote key must be in the vehicle.

[0094] In step S07, operator 312 presents the setup card to the NFC reader. Then, it is verified whether the remote key is located in vehicle 302. This verification is performed in step S08, for example by a security environment or security element within vehicle 302, in which, for example, a key-related digital pair for the remote key is stored electronically. In an alternative embodiment, in step S09, if the vehicle 302 does not have a remote key, a pop-up window related to swipe-in ​​is displayed: "To swipe the vehicle..."<FLOTTEN_NAME> "The remote key must be in the vehicle." In step S10, the remote key is checked again to see if it can be found. If the remote key is not found, a loop containing steps S09 and S10 can be executed.

[0095] In step S11, a pop-up window related to the vehicle transfer is displayed: "You have transferred a vehicle here. Continue?". In step S12, operator 312 confirms the execution of the transfer process. In step S13, vehicle 302 is placed in "Transfer Confirmed" mode.

[0096] In one embodiment, where an explicit fleet-related trigger has previously been given to the backend 304, in step S14, the setting card trigger (e.g., read carrier information) and the status related to the remote key are transmitted to the backend 304. In step S15, the backend 304 verifies the query and checks the session initiation. In an alternative embodiment, where only the fleet card and vehicle 302 have previously interacted, in step S16, the setting card trigger, fleet card signature, and the status related to the remote key are transmitted to the backend 304. In step S17, the backend 304 verifies the query and checks the fleet card signature.

[0097] In step S18, backend 304 integrates the configuration settings. In step S19, vehicle 302 is temporarily added to the fleet operator's fleet. Backend 304, operated by the vehicle 302 manufacturer, informs the fleet operator's backend of this status.

[0098] In step S20, the fleet configuration settings are pushed to vehicle 302. In step S21, vehicle 302 checks whether it is in "Fleet Confirmed" mode. If it is not clearly in this state, fleet configuration and server-based key sharing are rejected.

[0099] In step S22, vehicle 302 applies the configuration and its status changes to "fleet" or a similar state. In step S23, vehicle 302 outputs a pop-up window: "Vehicle has been assigned to..."<FLOTTEN_NAME> "Fleet". In step S24, vehicle 302 sends a confirmation to backend 304. In step S25, based on the confirmation, backend 304 finally adds vehicle 302 to the fleet. Backend 304, operated by the manufacturer of vehicle 302, informs the fleet operator's backend of this status.

[0100] Figure 4 Another embodiment of a method 400 for controlling fleet-related access to vehicle 402 is illustrated in the form of a schematic sequence diagram, for example, for classifying vehicle 402 into a vehicle fleet. Method 400 may be a specific embodiment of a process that generally corresponds to... Figure 1 Procedures 128 to 134 in the document; and for this purpose, for an explanation of, for example, the details of the definitions and terminology used, see [reference]. Figure 1 Explanation.

[0101] In method 400, the back-end of vehicle 402, or fleet management device 404, collaborates with user 412, who holds a fleet card. A simple (unmarked) fleet card is held by person 412, specifically on vehicle 402, at the NFC reader of vehicle 402. Additionally, a vehicle-associated card (setting card) and / or a remote key for vehicle 402 are used.

[0102] The following method flow 400 is predicated on the following: the fleet operator / fleet management device 404 possesses a fleet management token (e.g., in the form of a smart card or fleet card), which is associated with a vehicle or fleet operated by the fleet management device 404. The vehicle 402 is also associated with a hardware token, such as a smart card (“setup card”). Both smart cards are configured to interact with the vehicle 402.

[0103] The overall process may include: presenting the fleet card near, at, or on the NFC reader of vehicle 402 to place vehicle 402 into fleet management mode, allocation mode, etc. The vehicle card is then presented to the NFC reader. Privilege verification can be performed relative to the vehicle-side backend 304 for this purpose. Backend 404 assigns vehicle 402 to the fleet associated with the fleet card owner. Server-based key allocation can then be used according to the corresponding vehicle fleet configuration.

[0104] It needs to be clarified again that the fleet card is not associated with a specific vehicle (e.g., vehicle 402). When the fleet card is presented to the reader of vehicle 402, the fleet card (or other hardware token) allows vehicle 402 to distinguish between a "use or operation mode for joining a fleet" and an "operation mode for private use." The fleet card can also function as a hardware token, for example, in the form of a USB hardware token. In other embodiments, the fleet card can also exist as a smart device with corresponding functions, for example, for... Figure 1 The vehicle in vehicle 110 is as described in this article.

[0105] It should be noted that the following steps are simplified based on the process according to the present invention.

[0106] Adding vehicle 402 to the convoy begins in step S01, whereby personnel 412, inside vehicle 402, present a convoy card to the NFC reader. In step S02, vehicle 402 is placed in convoy mode. In step S03, vehicle 402 displays a corresponding pop-up window, such as: "To add vehicle 402 to the convoy..."<FLOTTEN_NAME> The fleet must place the setup card on the NFC reader. The remote key must be in the vehicle.

[0107] In step S04, operator 412 presents the setup card to the NFC reader. The remote key is then checked to ensure it is present in vehicle 402. This check is performed in step S05, for example by a security environment or security element within vehicle 402, in which, for example, a key-related digital pairing for the remote key is stored electronically. In an alternative embodiment, in step S06, if the vehicle 402 does not have a remote key, a pop-up window related to swipe-in ​​is displayed: "To swipe the vehicle..."<FLOTTEN_NAME> "The remote key must be in the vehicle." In step S07, the remote key is checked again to see if it can be found. If the remote key is not found, a loop containing steps S06 and S07 can be executed.

[0108] In step S08, a pop-up window related to the vehicle transfer operation is displayed: "You have transferred a vehicle here. Continue?". In step S09, operator 412 confirms the execution of the transfer process. In step S10, vehicle 402 is placed in "Transfer Confirmed" mode.

[0109] In step S11, logically, information related to the fleet card is transmitted, and in terms of ownership verification, the status related to the setting card trigger (e.g., read carrier information) and the remote key is transmitted to the backend 304. In step S12, the backend 304 determines the desired fleet based on the fleet card information. In step S13, the backend 304 integrates the fleet configuration settings. In step S14, vehicle 402 is temporarily added to the fleet operator's fleet. The backend 404, operated by the vehicle 402 manufacturer, notifies the fleet operator's backend of this status.

[0110] In step S15, the fleet configuration settings are sent to vehicle 402. In step S16, vehicle 402 checks whether it is in "fleet confirmed" mode. If it is not explicitly in this state, the fleet configuration and server-based key sharing will be rejected.

[0111] In step S17, vehicle 402 applies the configuration, and the vehicle status changes to "Fleet" or a similar status. In step S18, vehicle 402 outputs a pop-up window: "Vehicle has been assigned to..."<FLOTTEN_NAME> "Fleet". In step S19, vehicle 402 sends a confirmation to backend 404. In step S20, based on the confirmation, backend 404 finally adds vehicle 402 to the fleet operator's fleet. Backend 404, operated by the manufacturer of vehicle 402, informs the fleet operator's backend of this status.

[0112] Embodiments of the present invention enable fleet-related access to vehicles, such as adding or removing vehicles from a fleet. In embodiments, this access is controlled by personnel on-site at or inside the vehicle. For this purpose, the vehicle requires no special equipment or configuration, and can be in its new factory condition (i.e., delivery condition for a private buyer).

[0113] In embodiments of the invention, the proof of ownership within the vehicle (which is known, for example, through key sharing) is modified or supplemented in an intuitive manner. In addition to a vehicle-related card (e.g., a setup card for proof of ownership), it is recommended to use an additional fleet-related card. Presenting this fleet card within the vehicle complements and is performed in the same manner as presenting the vehicle-related tokens (remote keys and / or smart cards, setup cards). In this way, no additional equipment or configuration is required within the vehicle, and the on-site operator (e.g., a fleet operator's employee) only needs to hold the fleet card to perform sign-in interactions with the backend quickly and easily.

[0114] If, for example, an encryption element is set on the fleet card, the above access can also be performed securely, through which secure interaction with the vehicle or directly with the backend can be performed, for example, while presenting the fleet card.

[0115] Other embodiments of the invention enable fleet-related access control via a fleet management application (e.g., installed on a smartphone or tablet); thus, fleet-related cards and vehicle-related cards can be presented at an NFC reader on a smartphone or other mobile device. This allows for, for example, rapid fleet-related access to multiple vehicles within a company parking lot. Furthermore, other embodiments also enable flexible control according to the invention via a website and using a vehicle-related application, which is known in itself as an application for digital vehicle keys on mobile devices.

[0116] List of reference numerals in the attached diagram:

[0117] 100 System

[0118] 102 Vehicles and motor vehicles

[0119] 104 Backend Server, Backend

[0120] 106 Mobile Devices

[0121] 108 Smart Card, Vehicle Card, Setting Card

[0122] 110 Smart Card, Fleet Card, Fleet Management Card

[0123] 112 users

[0124] 114 Control device for vehicle 102

[0125] NFC reader for vehicle 102 (116)

[0126] 118 Fleet management applications on mobile devices 106

[0127] 120 NFC reader for mobile device 106

[0128] 122 Vehicle card 108 Carrier information and vehicle identification

[0129] Information on the vehicle and vehicle identification on vehicle 124 vehicle 110

[0130] 126 Encryption Elements

[0131] 128 Set vehicle 102 as a convoy scenario

[0132] 130 Provide proof of ownership

[0133] 132 is allocated in backend 104.

[0134] 134 Download Team Configuration

[0135] 136 Select vehicle 102 in fleet management application 118.

[0136] 138 Return Session ID

[0137] 140 Show convoy card 110

[0138] 142 Execute the demarcation

[0139] 200 methods

[0140] 202 Show the fleet card

[0141] 204 Message interaction used for verifying fleet cards

[0142] 206 Certificate of Ownership

[0143] 208 Send ownership certificate result

[0144] 210 Receiving fleet configuration

[0145] 212 Application Fleet Configuration

[0146] 250 methods

[0147] 252 Message interaction used for verifying fleet cards

[0148] 254 Receive ownership certificate results

[0149] 256. Assign vehicles to the fleet.

[0150] 258 Send fleet configuration

[0151] 260 added the vehicle to the fleet

[0152] 300 methods

[0153] 302 Motor Vehicles

[0154] 304 Fleet Management Device

[0155] 312 users

[0156] S01-S25 Method Steps

[0157] 400 methods

[0158] 402 Motor Vehicles

[0159] 404 Fleet Management

[0160] 412 users

[0161] S01-S20 Method Steps

Claims

1. A method (200) for controlling fleet-related access to motor vehicles (102), comprising the following steps: - Read (202) vehicle information (124) related to the fleet from the first physical carrier (110); as well as - The read carrier information (124) is forwarded (128, 204) to the fleet management device (104) related to the allocation of the motor vehicle (102) to the vehicle fleet.

2. The method (200) according to claim 1, further comprising the following steps: - Read (206) vehicle-related information (122) from the second physical carrier (108); - Send (208) instructions related to the read vehicle-related information (122) to the fleet management device (104).

3. The method (200) according to claim 1 or 2, further comprising the following steps: - Request a signature from the first carrier (110); and - Forward the requested signature to the fleet management device (104).

4. The method (200) according to any one of the preceding claims, comprising the following further steps: - Forwarding (204) is a message exchange between the first carrier (110) and the fleet management device (104) related to the verification of the first carrier (110).

5. The method (200) according to any one of the preceding claims, comprising the following further steps: - Receive fleet configuration (134, 210); and - Apply the fleet configuration described in (212) to prepare key distribution based on the digital vehicle key in the backend (104).

6. The method (200) according to any one of the preceding claims, comprising the following further steps: - Receive vehicle-related parameters; - Request a signature from the first carrier (110) regarding the vehicle-related parameters; and - Forward the requested signature to the fleet management device (104).

7. The method (200) according to claim 6 further includes the following pre-processing steps: - Receive selections related to the motor vehicle.

8. A method (250) for controlling fleet-related access to a motor vehicle (102), comprising the following steps: - Receive (128, 254) forwarded vehicle-related information (124); - Based on the received carrier information (124), the motor vehicle (102) is allocated (256) to the vehicle fleet; and - Send (134, 258) instructions related to the configuration of the vehicle fleet.

9. The method (250) according to claim 8, further comprising the following steps: - The carrier (110) of the carrier information (124) related to the fleet performs (254) message interaction related to the verification of the carrier (110).

10. A motor vehicle (102), comprising: - Reading device (116) is configured to read at least one physical carrier (108, 110). as well as - The control device (114) is configured to perform a method (200) for controlling fleet-related access to the motor vehicle (102) according to any one of claims 1 to 7.

11. A computer program product comprising a program code segment, wherein when the computer program product is executed on a computer (106), the program code segment is configured to perform the method (200) according to any one of claims 1 to 6.

12. A mobile device (106), comprising: - Reading device (120) for reading at least one physical carrier (108, 110); as well as - The computer program product according to claim 11.

13. A backend server (104) configured to perform a method (250) for fleet-related access to a motor vehicle (102) according to any one of claims 8 or 9.

14. An application of using a physical carrier (110) for controlling fleet-related access to motor vehicles (102), comprising: The carrier information (124) related to the vehicle fleet is read from the carrier (110) for forwarding to the fleet management device (104) related to the allocation of the vehicle (102) to the vehicle fleet.

15. A vehicle fleet, comprising: - At least one motor vehicle (102) according to claim 10; as well as - A physical carrier (110) is configured to read carrier information (124) related to the vehicle fleet from the carrier (110) for forwarding to a fleet management device (104) related to the allocation of the motor vehicle (102) to the vehicle fleet.

Images