METHOD AND DEVICE FOR INDIVIDUALLY ASSIGNING AT LEAST ONE VEHICLE FUNCTIONAL SCHEME TO AT LEAST ONE VEHICLE

Description

[0001] The invention relates to a method for individually assigning at least one vehicle function scheme to at least one vehicle according to the preamble of claim 1. Furthermore, the invention relates to a device for carrying out such a method according to the preamble of claim 10.

[0002] Document US 2012 / 0317161 A1 describes an in-vehicle computer system with instructions that cause a processor to store a media profile of a first user indicating their media preferences. The processor further determines when the vehicle encounters a second vehicle and receives a media profile of a second user. The processor further evaluates the profiles to determine a similarity between them. If a similarity is determined, recommended media is identified based on the characteristics of the profiles, and the provision of recommended media to one of the users of the first vehicle and the user of the second vehicle is triggered.

[0003] Document US 2013 / 0124009 A1 describes a device and method for managing vehicle configurations. A database with multiple configuration templates is provided. A configuration template includes parameters of configurable features and settings of an associated vehicle. A user is enabled to retrieve and customize a configuration template using a configuration application. Customized configuration data is transmitted to a control module of the vehicle to customize features and settings in accordance with the user's configuration data.

[0004] Document US 2017 / 0369052 A1 describes an apparatus and method for controlling an autonomous vehicle. The method includes receiving a profile selection by an electronic processor of the autonomous vehicle. The method further includes receiving a driver profile with a plurality of settings based on the profile selection. The method further includes, in an autonomous driving mode, controlling with the electronic processor based on at least one of the plurality of settings.

[0005] Document US 2022 / 0366061 A1 describes a method for verifying the authenticity of an association of a non-fungible token (NFT) with a physical object. In one embodiment, the method is suitable for verifying the connection between an NFT and an authenticated physical object. In another embodiment, the method comprises retrieving authentication metadata for a security feature associated with a physical object. It can be verified whether the authentication metadata for the security feature contains an identifier of the NFT.

[0006] Document US 2022 / 0075845 A1 describes a computer-aided design (CAD) system using an image analysis device to identify objects in video images. Adjustment rules and object identifiers determined by the image analysis device determine whether a video image is approved for use in customizing a product. It determines which video images should be used for customization. A first video image that has not yet been selected for customizing the product is selected and printed on the product. The first video image is excluded from further use for customizing the product.

[0007] The document Dietrlich, Fabian et al., "Concept for a Token-based Blockchain Architecture for Mapping Manufacturing Processes of Products with Changeable Configurations," A.-L. Andersen et al. (Eds.): CARV 2021 / MCPC 2021, LNME, pp. 508-515, 2022, https: / / doi.org / 10.1007 / 978-3-030-90700-6_57, describes a method in which logically decoupled tokens are embedded in a flexible smart contract structure. A concept for a token-based architecture is described that can be used to map manufacturing processes of products with changeable configurations.

[0008] Document US 2013 / 0124009 A1 describes a device and method for managing vehicle configurations. A database comprising a plurality of configuration templates is provided. The configuration templates include parameters of configurable features and settings of an associated vehicle. A user is provided with a software application with which configuration templates can be retrieved and personalized. The personalized configuration data is transmitted to a control unit of the vehicle to adapt features and settings according to the user's configuration data.

[0009] The invention is based on the object of providing an improved method for individually assigning at least one vehicle function scheme to at least one vehicle. This object is achieved according to the invention by a method having the features of claim 1.

[0010] Furthermore, the invention is based on the object of providing a device for carrying out this method. This object is achieved by a device having the features of claim 10.

[0011] Advantageous embodiments of the invention are the subject of the subclaims.

[0012] The user experience—that is, the perception of multimedia content, but also the perception of vehicle operation by a passenger—in modern vehicles is influenced by a multitude of freely selectable parameters. Optimizing such a user experience is complex and offers added value over standardized settings. Therefore, there is a need for a process that can control the sharing of such customized settings and, in particular, prevent arbitrary duplication by assigning customized settings to an individual (i.e., identifiable) vehicle.

[0013] In a method for individually assigning at least one vehicle functional diagram to at least one vehicle, according to a first aspect of the invention, a vehicle functional diagram is digitally recorded, for example as a set of integer values, floating-point values, characters, character strings, binary data, and / or control instructions. A vehicle functional diagram digitally recorded in this way, for example encoded in a markup language such as XML (extensible markup language) or JavaScript Object Notation (JSON), is minted according to the invention as a non-fungible token (NFT) in a predetermined number in a distributed ledger technology (DLT) system.

[0014] "Minting" refers to the individualization and registration of digital data records. In other words, the DLT system manages individualized vehicle function schemas (e.g., via assigned numbers or character strings unique within the DLT system) and can assign them to other entities, such as users, organizations, vehicles, or other systems, in a traceable and tamper-proof manner. DLT systems are known from the state of the art, for example, DLT systems based on the blockchain process.

[0015] According to the invention, a DLT system is used to mint and manage NFTs corresponding to vehicle functional diagrams, which is configured to assign a maximum of one vehicle to an NFT at a specific point in time. Of course, however, multiple NFTs can also be assigned to a vehicle functional diagram, which are thus essentially functionally identical (i.e., configure a vehicle in the same way) and can be assigned to different vehicles. Thus, depending on the number of NFTs minted for a vehicle functional diagram, only a single vehicle or any other limited number of vehicles can be assigned to this specific vehicle functional diagram.

[0016] From the set of NFTs registered in the DLT system, at least one NFT is selected and / or acquired for a vehicle. The vehicle functional scheme associated with this selected and / or acquired NFT is applied to the vehicle.

[0017] The method according to the invention makes it possible to control the distribution of vehicle function diagrams and create a digital marketplace for trading them. In particular, unauthorized distribution of vehicle function diagrams is prevented by the forgery-proof assignment to a maximum of one vehicle in the DLT system. This promotes the development and further development of such vehicle function diagrams, achieves exclusive access to certain vehicle functions, and generates additional added value from trading in vehicle function diagrams.

[0018] A vehicle functional diagram is understood here and in the following as a configuration, i.e. a set of parameters and / or functional settings of a vehicle function.

[0019] In one embodiment, a vehicle functional diagram captures parameters of a visually perceptible presentation of a vehicle interior. Such parameters can, for example, relate to vehicle interior lighting and can be adjusted in such a way that a specific color, brightness, and / or brightness distribution is or will be generated, triggering a particular user experience. Alternatively or additionally, such parameters can also configure background images or background patterns displayed on one or more displays in the vehicle interior. Visually perceptible presentations are particularly easy to personalize and offer a high level of recognition.

[0020] In a similar way, a vehicle functional diagram can parameterize audio playback in the vehicle interior, for example, with regard to absolute and / or frequency-dependent relative volume or with regard to specific sound effects. For example, preferred audio playback settings can be parameterized in a vehicle functional diagram depending on an audio source (e.g., radio or external media) or depending on an audio characteristic (e.g., speech, classical music, or rock music). Sound effects generated for perception in the immediate vehicle environment, such as an artificial engine sound for an electrically powered vehicle, can also be parameterized.

[0021] According to the invention, an NFT comprises requirement data and parameter data, wherein the parameter data describe the settings of the vehicle functional scheme and wherein the requirement data describe those equipment features of the vehicle that are required for implementing a vehicle functional scheme according to the parameter data.

[0022] Typically, an NFT has a transaction-variable cryptographic hash value that incorporates both characteristics of the protected digital asset (in this case, parameters of a vehicle functional diagram) and characteristics of one or more transactions involving this digital asset, such as timestamps of a transfer of ownership or usage rights. Such hash values, determined across the entire digital asset, are therefore unsuitable for searches, even if they relate to one and the same setting of a vehicle functional diagram, because they are subject to unpredictable changes over the course of transactions.

[0023] In the present embodiment, such a transaction-variable hash value of an NFT is formed solely based on the parameter data and supplemented by a transaction-invariant part containing the request data. Advantageously, the transaction-invariant part can be used to search for those NFTs that can be implemented on a vehicle with given specific equipment features. At the same time, the cryptographic security of the settings of the vehicle functional scheme to be protected is not compromised.

[0024] In a particularly advantageous embodiment, the request data includes a special equipment code (SA code) and / or a hardware version and / or a software version of an equipment feature. This enables a particularly simple and specific search for NFTs suitable for a specific vehicle.

[0025] In one embodiment of the method, the compatibility of at least one NFT registered in the DLT system with a specific vehicle is determined based on the identity of that vehicle. The identity of a vehicle can be determined, for example, by a number or character string known as the Vehicle Identification Number (VIN), which is unique at least for the fleet of vehicles of a vehicle manufacturer.

[0026] Using this embodiment, only those vehicle function schemes are offered and / or provided for a vehicle that are compatible with the vehicle's features, i.e., that can be used and implemented with the vehicle's hardware and software components. This enables easier operation when configuring the vehicle.

[0027] In one embodiment, a selection list is generated and stored in at least one head unit of a vehicle, which includes the NFTs registered in the DLT system and compatible with that vehicle. A head unit is understood here and below to be a central control unit that has a user interface and can be used to control vehicle functions, in particular settings in the vehicle interior and / or infotainment functions.

[0028] With this embodiment, a selection of NFTs can be executed particularly quickly and autonomously, i.e. without repeated access to the DLT system.

[0029] In another embodiment, equipment features are assigned to a vehicle in a configuration management system and stored there. Such equipment features may, for example, but not exclusively, relate to compatibility with vehicle functional schemes of NFTs. For example, a hardware configuration installed in the vehicle for a vehicle interior lighting system and a software version installed on it may be recorded.

[0030] According to this embodiment of the method, a list of all NFTs registered in the DLT system is created, and at least one NFT is selected from this list. For the at least one selected NFT, its compatibility with the vehicle is determined using the configuration management system.

[0031] This embodiment ensures that only those NFTs are selected for a vehicle whose associated vehicle functional schemes can be implemented in the vehicle. This enables particularly good usability and prevents the acquisition of unsuitable NFTs.

[0032] In another embodiment, a selection list of NFTs registered in the DLT system that are compatible with the respective vehicle (i.e., with its features) is generated for a vehicle. Such a selection list, also referred to as a whitelist, is offered for the selection of one or more compatible NFTs. This makes it easier for the user to select NFTs.

[0033] Preferably, such a selection list is stored locally in the vehicle in one or more head units and reused for subsequent NFT selection. By generating such a selection list only at longer intervals, rather than for each selection process, the selection process is accelerated and usability is improved.

[0034] In a further embodiment, a first hash value is generated for each NFT, which is based on the request data describing the equipment features required to implement the settings of the vehicle functional scheme assigned to this NFT, for example, as a set of SA codes. Furthermore, a second hash value is generated, which is based on the settings of the vehicle functional scheme. A first list comprising the first hash values ​​is created and stored locally in a vehicle. Furthermore, a second list comprising the second hash values ​​is created and stored in a distributed system independent of a vehicle, preferably in a cloud.

[0035] When retrieving an NFT for a specific vehicle, the first list, stored locally in the vehicle, is used to select those NFTs that can be implemented on the vehicle, and their first hash values ​​are extracted. Then, using the second list, stored distributed and preferably in the cloud, the associated second hash values ​​are searched for and extracted, which describe the associated settings of the vehicle's functional scheme.

[0036] The first and the associated second hash values ​​are combined and checked for correct assignment using a verification algorithm. If the assignment is correct, the NFT is retrieved from the DLT system using the combined value of the first and second hash values.

[0037] According to a second aspect of the invention, a device for carrying out the method according to the first aspect of the invention comprises at least one DLT system which is configured for access via an over-the-air network, preferably via a mobile radio network.

[0038] This allows the method to be implemented virtually independently of the vehicle's location. Further advantages of the device correspond to the advantages of the method according to the first aspect of the invention.

[0039] Embodiments of the invention are explained in more detail below with reference to drawings.

[0040] Showing: Fig. 1 schematically shows the structure of a non-fungible token (NFT), Fig. 2 schematically shows a process flow for transferring an NFT between a distributed ledger technology (DLT) system and a vehicle, Fig. 3 schematically shows access to a DLT system from vehicles, Fig. 4 schematically shows the process for restricting access to vehicle settings that are protected by NFT, Fig. 5 schematically shows the process flow for selecting an NFT for a vehicle, Fig. 6 schematically shows the process flow for selecting an NFT for a vehicle based on NFT hash values ​​and Fig. 7 schematically shows the process flow of a transaction for transferring an NFT between two vehicles.

[0041] Corresponding parts are provided with the same reference numerals in all figures.

[0042] Figure 1shows a schematic diagram of the structure of a non-fungible token (NFT) 1 for configuring vehicle functions, for example, for configuring a color scheme for vehicle interior lighting or for configuring a sound or audio scheme for an audio system. The NFT 1 comprises data, preferably characters arranged in a character string, control instructions, and / or numbers.

[0043] In a first section, the NFT 1 comprises requirement data 1.1, which can be used to check the technical feasibility of a configuration specified by the NFT 1 (i.e., a vehicle functional diagram related to a specific function). Requirement data 1.1 can, for example, include one or more special equipment codes (SA codes). An SA code is used to specify certain optional, for example, country- or region-specific, equipment features of a vehicle specified in Figure 1vehicle not shown in detail. Alternatively or additionally, the requirement data 1.1 can identify development stages of subsystems of the vehicle, for example a hardware version and / or a software version.

[0044] In a second section, the NFT 1 comprises parameter data 1.2 that defines settings for specific functions available in a vehicle that meets the requirement data 1.1. Using such parameter data 1.2, for example, the lighting of a vehicle interior can be configured to display specific colors or sequences of colors. Furthermore, the lighting can be changed depending on the vehicle's operating states (e.g., speed, acceleration, or deceleration) or other vehicle or multimedia functions that can be adjusted by a user of the vehicle. For example, a lighting scheme can be set depending on the music selected by the user from an infotainment system.

[0045] In a similar way, the vehicle's audio or sound functions can be configured. Furthermore, vehicle seats can be adjusted to suit a user's specific preferences.

[0046] Furthermore, parameter data 1.2 can be used to specify specific graphics or images to be displayed on one or more display devices available in the vehicle. A backlight for such display devices can also be specified using parameter data 1.2.

[0047] In addition, lighting effects, such as a light show when opening a vehicle door or the illumination of a type or brand plate, and / or sound effects, such as the engine noise of an electrically powered vehicle, can be configured using parameter data 1.2.

[0048] An NFT 1 is assigned an NFT hash value 2, which can be represented as a character string and / or integer, using a cryptographic hash function. A hash function that is collision-resistant and a one-way function is particularly cryptographic (or cryptological). Thus, with realistically available computing power, no further NFT 1 can be determined that results in the same NFT hash value 2 as a different first NFT 1. Likewise, with realistically available computing power, no NFT 1 can be determined that, when applied to this cryptographic hash function, results in a given NFT hash value 2.

[0049] Subsequently, the NFT hash value 2 can be transmitted and / or stored instead of the NFT 1. Preferably, the cryptographic hash function is selected such that certain particularly significant features of the request data 1.1 and / or the parameter data 1.2 can be derived from the NFT hash value 2, for example, restrictions regarding the technical applicability of the NFT 1 (for example, a minimum hardware and / or software version).

[0050] In one embodiment, it is possible to split the character string of the NFT hash value 2 into sub-character strings in order to use them at different locations, for example in a vehicle and on a Figure 1 central software system not shown in detail.

[0051] Figure 2illustrates the method of transferring an NFT 1 between a Distributed Ledger Technology (DLT) system 20 and a vehicle 10. The vehicle 10 has at least one infotainment device referred to as a head unit 11, which is used for data exchange, in particular via a Figure 2 wirelessly available Over-The-Air (OTA) network (not shown in detail) with which DLT System 20 is set up and which can be operated by a vehicle occupant via a user interface.

[0052] The head unit 11 controls functions of the vehicle 10, for example lighting functions of a vehicle interior lighting, the audio playback of an audio system in the vehicle interior, a sound generator for generating an artificial engine noise for a vehicle with electric drive or actuators for adjusting vehicle seats in the vehicle 10, typically with the inclusion of further Figure 2control units not shown in detail.

[0053] The DLT system 20 can, for example, be implemented as a blockchain and is configured to manage a plurality of NFTs 1. In particular, the DLT system 20 is configured to individualize the NFTs 1 managed therein in a manner that is tamper-proof and forgery-proof, i.e., to assign them to a specific user. The functionality of the DLT system 20 is explained in more detail below.

[0054] By means of a preferably graphical user interface of the head unit 11, a user (i.e. a driver or other vehicle occupant of the vehicle 10) can be shown a list of NFTs 1 whose assigned configurations can be implemented on the vehicle 10.

[0055] For this purpose, a vehicle identification number (VIN) can be transmitted from the head unit 11 to the DLT system 20. Using a Figure 2Using a further vehicle configuration information system (not shown in detail), such NFTs 1 can be selected based on such a VIN and sent to the vehicle 10, which are technically executable on the vehicle 10 (with the available hardware and software configuration). Alternatively, information and parameters relevant for the selection of NFTs 1 can also be transmitted directly to the DLT system 20.

[0056] In one embodiment, an NFT hash value 2 can be used as an index, via which a set of parameters and / or a specific algorithm, e.g., encoded as a program, for evaluating these parameters can be uniquely determined, for example, downloaded from a cloud server. The parameters and / or the algorithm are loaded into the local memory of the head unit 11. The head unit 11 uses this to determine a setting for vehicle functions, for example, the control of lamps of different colors to illuminate the vehicle interior to convey a predetermined, perceptible color impression.

[0057] In one embodiment, a list of technically suitable NFTs 1 for the respective vehicle 10 is displayed on the user interface for selection and / or stored on a data storage device. By selecting from this list, a user can activate a corresponding NFT 1 for their vehicle 10 (i.e., adjust vehicle functions of the vehicle 10 according to the parameters specified in the selected NFT 1). Typically, this will require acquiring a selected NFT 1 prior to use, for example, through an e-commerce transaction mediated via a wireless network.

[0058] The invention is based on the idea that configurations parameterized via NFTs 1 are not applied to an arbitrary number of vehicles 10, but are unique (i.e., to a single vehicle 10) or limited (i.e., to a maximum of a predetermined number of vehicles 10), regardless of the number of vehicles 10 that would be technically equipped and prepared for the use of such an NFT 1. For such a limitation, an individualization of NFTs 1 is first required, which is carried out using Figure 3 is explained in more detail.

[0059] Figure 3schematically shows three different vehicles 10A to 10C, each with at least one head unit 11, which independently access the DLT system 20. The DLT system 20 manages four NFTs 1A to 1D, which similarly encode a specific configuration or parameterization for a vehicle 10. For example, identical settings for a vehicle interior lighting can be defined via each of the four NFTs 1A to 1D shown.

[0060] Furthermore, these four NFTs 1A to 1D encode the technical requirements necessary to implement the configuration specified therein, for example, a specific type and at least one development stage of a vehicle interior lighting as a hardware version and at least one software version of a head unit 11. It is possible that the configuration encoded in the NFTs 1A to 1D can be implemented with vehicles 10A to 10C of different types or different development stages.

[0061] The illustrated NFTs 1A to 1D are thus functionally identical. In other words, each of the four NFTs 1A to 1D, when installed on a vehicle 10A to 10C suitable for this purpose due to its type and level of development, leads to the same user perception, for example, to a certain, typical interior lighting. Of course, the configuration encoded by an NFT 1A to 1D is not limited to visual user perception; settings of an audio system or settings on one or more vehicle seats, or combinations of such settings, can also be encoded. The user perception that can be associated with an NFT 1A to 1D is limited only by the technical parameters on the vehicle 10A to 10C that can be influenced by the head unit 11 or downstream control units.However, the functionally identical NFTs 1A to 1D have distinguishable identities, which can be determined, for example, by different assigned integer values ​​or character strings in the form of globally unique identifiers (GUI).

[0062] Using the DLT system 20, each of the functionally identical NFTs 1A to 1D is either individualized, i.e., assigned to a vehicle 10A to 10C, or registered as still available. For example, a first NFT 1A can be assigned to a first vehicle 10A, a second NFT 1B to a second vehicle 10B, and a third NFT 1C to a third vehicle 10C based on the respective VIN. A fourth NFT 1D can be registered as still freely available and offered for purchase to other users.

[0063] Both the transfer of an already issued NFT 1A to 1C (i.e., the assignment of a different VIN) and the acquisition of an as yet unissued NFT 1D (i.e., the initial assignment of a new VIN) are registered and managed by the DLT system 20. In this way, a limited edition of functionally identical NFTs 1A to 1D can be implemented, as in the present case, for example, with four functionally identical NFTs 1A to 1D. The amount (scope) of a limited edition can be arbitrarily determined by the operator of the DLT system 20, which issues the NFTs 1A to 1D, and can, for example, be one.

[0064] In this case, only a single NFT 1 of a certain configuration (associated with a certain user experience) can be assigned to a vehicle 10A to 10C.

[0065] To enforce a limited requirement for a certain parameterization of vehicle functions, in addition to the individualization of the NFTs 1A to 1D assigned to this parameterization, access to this parameterization must be restricted. In other words, only those vehicles 1A to 1C for which one of these NFTs 1A to 1D is registered in the DLT system 20 (based on, for example, their VINs) should be able to make settings (e.g., to change the color of the vehicle interior lighting and / or to influence audio playback) according to this parameterization. Figure 4 illustrates how such a restriction works.

[0066] Vehicles 10 on which certain settings (for example, the vehicle interior lighting) are to be made request authorization for this from a central configuration management system 30, preferably by specifying the respective VIN. The vehicles 10 are connected to the configuration management system 30 via a wireless over-the-air (OTA) network 31.

[0067] The configuration management system 30 determines whether the requested parameterization (i.e., the totality of all settings required to generate the specific user experience) is assigned to an NFT 1 that has been registered in the DLT system 20 for a vehicle 10 or for multiple vehicles 10A to 10C. If such an assignment is not registered, any vehicle can make and use the requested settings.

[0068] If, however, one or more NFTs 1 are assigned to the requested parameterization, the configuration management system 30 checks whether the identity of the requesting vehicle 10 matches the identity of one owner or the identities of the multiple owners of the NFTs 1 issued for the requested settings. For example, it can be checked whether one of the eligible NFTs 1 was issued to the VIN of the requesting vehicle 10.

[0069] If a match is found, the parameters and / or the algorithm for the requested parameterization are passed to the Figure 4 Head Unit 11 (not shown in detail) of the requesting vehicle 10, which uses this information to determine the specific instructions and parameters required to set the vehicle functions and implements them in the vehicle 10.

[0070] If none of the NFTs 1 created for the requested parameterization has been issued to the requesting vehicle 10, the transmission of the parameters or algorithm is refused. In this case, the requesting vehicle 10 cannot perform the parameterization. This ensures that parameterization remains exclusively reserved for those vehicles 10 to which a corresponding NFT 1 has been assigned.

[0071] As already explained, the technical feasibility of the vehicle settings encoded in an NFT 1 may be tied to technical requirements that are not present in every vehicle 10 of a vehicle type, for example, a specific hardware configuration and / or a firmware version for an interior lighting system or for an audio system. Figure 5explains in more detail how an NFT 1 is selected that is suitable for a specific vehicle 10 (i.e. whose coded settings can be implemented on the vehicle 10).

[0072] A vehicle 10 (comprising a Figure 5 In a first step S1, the head unit 11 (not shown in detail) communicates its VIN via an OTA network 31 to a configuration management system 30 in which the equipment features of the vehicle 10 are recorded. In a second step S2, the configuration management system 30 determines the totality of equipment features (for example, hardware and software configurations of an interior lighting system and / or an audio system) that are assigned to the communicated VIN.

[0073] In a third step S3, the configuration management system 30 determines, by querying the DLT system 20, those NFTs 1 registered there that are compatible with the equipment features of the vehicle 10. Alternatively or additionally, it is also possible to transmit the NFT hash values ​​2 assigned to the selected NFTs 1 to the vehicle 10. This embodiment is described below with reference to Figure 6 be explained in more detail.

[0074] In a fourth step S4, this vehicle-specific selection of NFTs 1 is transmitted via the OTA network 31 to the vehicle 10 and displayed there on a display 12 (which can be assigned to the head unit 11, for example).

[0075] For display on the display 12, it is necessary to determine the essential characteristics of each NFT 1 of this vehicle-specific selection. This can be done by decoding the respective NFT 1 or using the associated NFT hash value 2.

[0076] Figure 6 explains in more detail an embodiment of a method in which a selection of suitable NFTs 1 is made in a vehicle 10 based on their NFT hash values ​​2.

[0077] In a first step S1, settings for vehicle functions, preferably settings related to the vehicle interior, are developed that, for example, provide a particularly pleasant or original user experience. These settings can be developed by the manufacturer of the vehicle 10, but also by a service provider, a supplier, or a third party uninvolved in the production of the vehicle 10.

[0078] In a second step S2, an NFT 1 or a predetermined, limited number of NFTs 1 is minted from the developed vehicle settings (i.e., the parameters or configuration of vehicle functions) on a DLT system 20 using a cryptographic process.

[0079] In a third step S3, the at least one NFT 1 that has been assigned to the developed vehicle settings is transmitted to the configuration management system 30, on which the equipment features of the vehicles 10 of a fleet and / or a manufacturer are registered based on their respective VINs.

[0080] In a fourth step S4, the configuration management system 30 determines the VINs of those vehicles 10 whose equipment features are compatible with the developed vehicle settings (which were assigned to the at least one NFT 1 during its minting). If at least one compatible vehicle 10 is determined, the at least one NFT 1 is transmitted to an NFT hash value converter 40.

[0081] In a fifth step S5, the NFT hash value converter 40 assigns an NFT hash value 2 to each NFT 1 such that the NFT hash value 2 contains a character string describing the function or triggered user experience of the respective NFT 1. For example, for an NFT 1 with a specific vehicle light setting, an NFT hash value 2 could be generated as the character string "XXXXLIGHTINGXXX284UR".

[0082] In a sixth step S6, the generated NFT hash value 2 is sent via an OTA network 31 to a vehicle 10 whose equipment features are compatible with the settings of the associated NFT 1. In the vehicle 10, the NFT hash value 2 can be added to a selection list (whitelist) that includes all settings available on the DLT system 20 for this vehicle 10 and protected via NFTs 1.

[0083] In one embodiment, instead of the complete NFT hash value 2, only a part of it can be stored locally in the vehicle 10, with which the function and optionally further parameters, for example the required equipment features or the amount of a limited edition, are described.

[0084] From such a selection list, a user can select settings of interest to them and purchase an associated NFT 1 from the DLT system 20. Upon purchase of an NFT 1, the VIN of the vehicle 10 is assigned in a seventh step S7 in the DLT system 20. This assigns the configuration associated with the NFT 1 (for example, the setting of the vehicle interior lighting) to this individual vehicle 10.

[0085] Subsequently, in an eighth step S8, the user can activate the settings of this NFT 1. As can be seen from Figure 4 As already explained, upon activation it is checked whether the identity (i.e. the VIN) of the vehicle 10 matches that of the vehicle 10 or one of the vehicles 10 for which a corresponding NFT 1 was registered in the DLT system 20.

[0086] In an alternative or additional embodiment, instead of a selection list (whitelist), a negative list (blacklist) of those NFTs 1 can be created and stored on the vehicle 10 for which this vehicle 10 is not compatible (i.e., does not have the required features).

[0087] Figure 7 shows a schematic of the process of a transaction in which an NFT 1 is transferred from a first vehicle 10A to a second vehicle 10B. Each of the vehicles 10A, 10B is assigned a user account 13A, 13B in the DLT system 20.

[0088] Before the transaction is executed, an NFT 1 is registered in the DLT system 20 for the first vehicle 10A. Thus, the settings assigned to this NFT 1 can be activated and implemented on the first vehicle 10A.

[0089] For simplicity, we will first consider the case where only a single and thus exclusive NFT 1 was minted for the assigned settings. In this case, any other vehicle, including the second vehicle 10B, cannot use these settings.

[0090] During the transaction, the NFT 1 is transferred to the second vehicle 10B in exchange for payment of an agreed purchase price. The transaction (i.e., the reassignment of a vehicle identity, typically a VIN, to the NFT 1) is registered in the DLT system 20. After the transaction, the assigned settings are deactivated on the first vehicle 10A and can be activated on the second vehicle 10B.

[0091] The user accounts 13A, 13B serve to assign one or more vehicles 10, 10A to 10C to a user, i.e., to a natural or legal person with ownership rights to the respective vehicle 10, 10A to 10C. Furthermore, business transactions such as the described sale and purchase of NFTs 1 can be processed via the user accounts 13A, 13B. The operator of an NFT marketplace through which these transactions are processed and to which the user accounts 13A, 13B provide access can charge fees for transactions with or for the management of NFTs 1. Such an NFT marketplace will preferably be accessible for smartphones or web browsers from computer workstations.

[0092] Such a sales transaction can also be executed in the event that not just a single (exclusive) NFT 1, but a limited number of NFTs 1 related to certain vehicle settings, such as a color scheme for the vehicle interior lighting, have been minted. In this case, a buyer can choose from potentially several providers of NFTs 1 that are identical in terms of vehicle settings, yet individually distinguishable and potentially offered under different conditions.

[0093] It is also possible for NFTs 1 to be acquired by legal or natural persons with a user account 13A, 13B without being simultaneously assigned to a vehicle 10, 10A to 10C. For example, a vehicle manufacturer can acquire or reacquire NFTs 1 to offer them again.

Claims

1. Method for individually allocating at least one vehicle function schema, describing the configuration of at least one vehicle function, to at least one vehicle (10, 10A to 10C), the method comprising: - a vehicle function schema is digitally recorded and minted as a non-fungible token (NFT) (1, 1A to 1D) in a predetermined number in a distributed ledger technology (DLT) system (20), which is configured to assign a maximum of one vehicle (10, 10A to 10C) to an NFT (1, 1A to 1D), - at least one NFT (1, 1A to 1D) is selected and / or acquired for a vehicle (10, 10A to 10C) and - the relevant assigned vehicle function schema is applied to the vehicle (10, 10A to 10C), - wherein an NFT (1, 1A to 1D) encodes the technical requirements required to implement a configuration of the at least one vehicle function, which configuration is described by the assigned vehicle function schema and - wherein an NFT (1, 1A to 1D) comprises requirement data (1.1) and parameter data (1.2), wherein the parameter data (1.2) describe the settings of the vehicle function schema and wherein the requirement data (1.1) describe the equipment features of the vehicle (10, 10A to 10C) required for implementing the vehicle function schema according to the parameter data (1.2).

2. Method according to claim 1, characterized in that the requirement data (1.1) include a special equipment code (SA code) and / or a hardware version and / or a software version of an equipment feature.

3. Method according to either of the preceding claims, characterized in that the vehicle function schema records parameters of a visually perceptible representation of the vehicle interior of the vehicle (10, 10A to 10C).

4. Method according to any of the preceding claims, characterized in that the vehicle function schema records parameters of an audio and / or sound playback in the interior or in the surroundings of the vehicle (10, 10A to 10C).

5. Method according to any of the preceding claims, characterized in that for at least one NFT (1, 1A to 1D) registered in the DLT system (20), the compatibility of which with a vehicle (10, 10A to 10C) is determined on the basis of the identity of the vehicle (10, 10A to 10C).

6. Method according to any of the preceding claims, characterized in that for a vehicle (10, 10A to 10C), a selection list of NFTs (1, 1A to 1D) compatible with this vehicle (10, 10A to 10C) is determined and at least one NFT (1, 1A to 1D) is offered for selection.

7. Method according to either claim 5 or claim 6, characterized in that the selection list of NFTs (1, 1A to 1D) compatible with a vehicle (10, 10A to 10C) is stored in at least one head unit (11) of this vehicle (10, 10A to 10C).

8. Method according to any of claims 5 to 7, characterized in that - in a configuration management system (30), equipment features are assigned to a vehicle (10, 10A to 10C) and the assignment is stored, - a list of all NFTs (1, 1A to 1D) minted in the DLT system (20) is created, - at least one NFT (1, 1A to 1D) is selected from the list and - for the at least one selected NFT (1, 1A to 1D) the compatibility with the vehicle (10, 10A to 10C) is determined using the configuration management system (30).

9. Method according to claim 8, characterized in that each NFT (1, 1A to 1D) is assigned a first hash value on the basis of requirement data (1.1) and a second hash value on the basis of parameter data (1.2) and a first list comprising the first hash values is created and stored locally in a vehicle, and a second list comprising the second hash values is created and stored in a cloud in a distributed manner, the parameter data (1.2) describing the settings of the vehicle function schema and the requirement data (1.1) describing the equipment features of the vehicle (10, 10A to 10C) required for implementing the vehicle function schema according to the parameter data (1.2).

10. Device for carrying out a method according to any of the preceding claims, wherein the device comprises at least one DLT system (20) which is configured for access via an over-the-air (OTA) network (31).