SYSTEM FOR DYNAMIC CONTROL AND REGULATION OF VEHICLE FUNCTIONS

Description

[0001] The present invention relates to a system and a method for dynamically controlling and regulating vehicle functions of a plurality of vehicles.

[0002] Systems that enable users to share a variety of vehicles with their drivers in real time, so-called ridesharing, real-time ridesharing, or on-demand ridesharing, are well known. Such concepts can be implemented using modern technological advances, in particular using navigation satellite systems for positioning, e.g., Global Positioning System (GPS), Global Navigation Satellite System (GLONASS), Galileo, Beidou, etc., in the corresponding vehicle fleet and / or in corresponding mobile devices, especially smartphones. The disadvantage of this is that users of ridesharing services are more likely to be viewed as users of a rideshare in a vehicle assigned to the driver, so that the use of the technology is limited to booking rideshares in real time, and no further technical interaction is possible.

[0003] US 2015 / 339928 A1 describes operating a fleet of autonomous vehicles. A request for a taxi service may be received from a mobile device. The request may include a current location of the mobile device. An autonomous vehicle may be selected from the fleet of autonomous vehicles to provide the taxi service based in part on the availability of the autonomous vehicle and the proximity between the autonomous vehicle and the current location of the mobile device.

[0004] US 2015 / 185034 A1 describes a shared vehicle service. A verified user can specify details of their desired ride. In particular, the verified user can specify a desired vehicle type and a driver category.

[0005] DE 10 2015 219 463 A1 concerns the use of an intelligent valet parking system for a vehicle. An automatic valet mode can allow a user to leave their automobile parked and, when the vehicle is needed again, be picked up from the user's location. Furthermore, other features can be activated, including climate control, engine control, window / sunroof control, vehicle data extraction (e.g., parking position, fuel information, etc.).

[0006] Windshield wiper control. US 2015 / 0339928 A1, US 2016 / 364823 A1, and US 2014 / 172727 A1 demonstrate taxi services and configure vehicle functions according to given user profiles before the user is picked up. US 2012 / 0164989 A1 allows the driver to create user profiles on their smartphone.

[0007] The object of the invention is to avoid the disadvantages mentioned above and to create a solution that offers users of real-time ride-sharing services the possibility of influencing the vehicle functions of the vehicle before each journey in order to achieve the highest possible driving comfort.

[0008] This object is achieved according to the invention by the features of the independent claims. Preferred embodiments are the subject of the dependent claims.

[0009] According to a first aspect of the invention, a system for dynamically controlling and / or regulating vehicle functions of a plurality of vehicles is provided, each vehicle having a central communication unit comprising: at least one backend server; at least one terminal device configured to send a driving request to the backend server, wherein the driving request comprises at least one starting position, a selection of a vehicle type from the plurality of vehicles, and at least one request for controlling and / or regulating at least one vehicle function according to a user input into an input interface on the terminal device; wherein the backend server is configured, after receiving the driving request, to select a vehicle according to the vehicle type and to send a driving request comprising the request for controlling and / or regulating at least one vehicle function to the central communication unit of the selected vehicle; and wherein the at least one vehicle function of the selected vehicle is controlled and / or regulated according to the request for controlling and regulating in the vehicle request, Where, in the event that a corresponding vehicle function cannot be controlled or regulated, the central communication unit can generate a corresponding message and output it to the terminal device via the backend server, whereby a user of the terminal device is then provided with the option of confirming the use of the ridesharing service via the backend server despite the non-existent vehicle function or of selecting another vehicle that can provide the corresponding vehicle function to use the ridesharing service.

[0010] The vehicles can, in particular, be motor vehicles with any type of drive (e.g., combustion engine, plug-in hybrid, electric drive, etc.). At least some of the motor vehicles can have at least a partially autonomous, but also a fully autonomous driving mode. The backend server can display vehicle types from the multitude of vehicles based on predetermined criteria, e.g., 7-seater, sports activity vehicle, convertible, coupe, sports car, etc.

[0011] Each of the plurality of vehicles has a central communications unit. The central communications unit comprises at least one subscriber identity module or SIM card, which serves to establish a communications connection via a mobile radio system. The subscriber identity module uniquely identifies the communications unit in the mobile radio network.

[0012] The communication connection can be established wirelessly, for example, via Global System for Mobile Communication (GSM), General Package Radio Service (GPRS), Enhanced Data Rates for Global Evolution (EDGE), Universal Mobile Telecommunications System (UMTS), High Speed ​​Downlink / Uplink Packet Access (HSDPA, HSUPA), Long-Term Evolution (LTE), World Wide Interoperability for Microwave Access (WIMAX) and / or 5G mobile radio systems. In addition or alternatively, the communication module is designed to establish or establish a communication connection via all common and future communication technologies, e.g. WiFi, Bluetooth, NFC, WiMAX. The communication connection can be a data connection (e.g. packet switching) and / or a wired communication connection (e.g. circuit switching).

[0013] Each central communication unit can be configured to permit only one communication connection with the backend server or servers. Before a communication connection can be established, it may also be necessary for the vehicle or the corresponding communication module to be registered once with the backend server, for example via a corresponding registration process by an authorized user of the vehicle (e.g. owner of the vehicle). In other words, a prior one-time registration of each vehicle from the multitude of vehicles on the backend server is required. This advantageously ensures that only drive requests received via the backend server, comprising at least one request to control and / or regulate at least one vehicle function, can carry out the control and / or regulation of the corresponding vehicle function in the vehicle.This advantageously prevents unauthorized manipulation of the corresponding vehicle functions. During the one-time registration process, technical parameters of the vehicle and optionally other data required depending on the context (e.g. data relating to an owner and / or driver of the vehicle in question or a passenger in vehicles with at least one at least partially autonomous driving mode) can be recorded on the backend server and stored in a storage unit, e.g. a database. The technical parameters can, in particular, be technical parameters relating to the vehicle functions. Advantageously, this means that the backend server can already record and store for each vehicle which vehicle functions the vehicle provides.

[0014] Each vehicle can send its current position to the backend server, e.g., via the central communication unit, which may have a corresponding positioning module, e.g., a GPS module, at predefined or predetermined intervals (e.g., every minute, every 5 minutes, etc.) and / or at predefined or predetermined events (e.g., vehicle start, vehicle stop, start of a trip, end of a trip, etc.). Advantageously, this allows the backend server to constantly determine the current position of all registered vehicles.

[0015] The communication between the end device, the backend server and the vehicle can be realized, for example, in the sense of the client-server paradigm (request / request-response / answer principle).

[0016] The backend server may be a car sharing service provider, but in particular a ride sharing service provider that provides ride sharing services to a large number of registered vehicles via a suitable communication system (e.g. mobile network and / or Internet).

[0017] In order to use a ridesharing service of the backend server, it may be mandatory for each user of the ridesharing service to register once with the backend server via a device, whereby the corresponding user data (e.g. user credentials, payment data, etc.) is recorded and stored in a corresponding storage unit, e.g. a database.

[0018] The end device can be a stationary device, e.g., a laptop, PC, etc., or a mobile device. The mobile device can include, in particular, smartphones, but also other mobile devices such as cell phones, personal digital assistants (PDAs), tablet PCs, and all current and future electronic devices equipped with technology for loading and running apps and / or for loading and running internet browsers.

[0019] In addition or alternatively, the end device can also be augmented reality (AR), virtual reality (VR), mixed reality (MR) glasses or AR, VR or MR contact lenses, via which the user of the corresponding end device can send the driving request to the backend server.

[0020] After successfully completing a one-time registration process on the part of the vehicle and each user of the ridesharing service, each user can log in using any device (user credentials) and send a ride request to the backend server via the device. The ride request includes at least one starting position and at least one request to control and / or regulate at least one vehicle function. For example, appropriately registered and drivable vehicles can be displayed via a suitable output unit of the device in a predetermined or predeterminable geographical vicinity of a starting position (e.g., a radius of 5 kilometers), for example on a digital map.

[0021] The user of the terminal device can enter the starting position, for example, using a corresponding human-machine interface in the terminal device (e.g., because no positioning module, e.g., GPS, is present in the terminal device and / or if the starting position deviates from a current position of the terminal device). In another example, the starting position can be the current geographical position of the user of the terminal device, which is determined by a positioning module (e.g., GPS module) included on or in the terminal device and transmitted accordingly. In a further step, the user of the terminal device can select a vehicle type from the multitude of vehicles.

[0022] In a further step, vehicle functions that correspond, for example, to the stored technical parameters and that can be manipulated (controllable and / or regulated) can be displayed to the user of the terminal device. The user of the terminal device can now at least manipulate the corresponding vehicle functions. This process corresponds to a request to control and / or regulate at least one vehicle function. Based on the request to control and / or regulate at least one vehicle function, the terminal device then creates a drive request comprising the starting position and the request to control and / or regulate at least one vehicle function and sends or transmits this to the backend server.The backend server will now select a vehicle according to the vehicle type and create a driving request comprising at least the request to control and / or regulate the at least one vehicle function and send it to the central communication unit of the vehicle selected by the backend server of the ridesharing service. The central communication unit will process the driving request accordingly and control and / or regulate the at least one vehicle function according to the request for control and / or regulation. The central communication unit can, for example, be implemented on a control unit or a control device that is capable of controlling or regulating the corresponding vehicle functions. In another example, the central communication unit cana control unit which is communicatively connected to one or more further control units and / or control devices in the vehicle which are designed to control or regulate the vehicle function.

[0023] Advantageously, every user of a (registered) device can control or regulate vehicle functions of a large number of vehicles securely and dynamically via the backend server.

[0024] Preferably, the at least one vehicle function of the vehicle comprises: at least one air conditioning or temperature control; a radio control; a multimedia content control; at least one seat heating system; at least one seat ventilation system; at least one seat cooling system; at least one seat position; at least one driving mode; and / or a vehicle navigation system.

[0025] Multimedia content includes, for example, streaming services for music and / or video content, but also all other current and future multimedia content.

[0026] For example, a list of vehicle functions that can be manipulated (i.e., controlled and / or regulated) in the selected vehicle can be displayed to the user of the ridesharing service via an output unit on the terminal device. The user of the ridesharing service can then make suitable settings accordingly. For example, the user can enter a desired vehicle interior temperature via a corresponding input interface on the terminal device. The heating and / or air conditioning in the vehicle are then controlled such that the desired vehicle interior temperature is reached and maintained. In addition or alternatively, the user of the terminal device can enter a desired radio station and, optionally, a desired volume. A radio module in the selected vehicle is then controlled such that the desired radio station and, optionally, the corresponding volume are set.In addition or alternatively, the user of the terminal device can select additional multimedia content. The corresponding multimedia unit in the vehicle is then controlled to start and / or adjust the multimedia content. In addition or alternatively, the user of the terminal device can specify that they require seat heating and / or seat ventilation and / or seat cooling and / or a specific seat setting. The corresponding units in the vehicle that provide the functionality (e.g., control units or software modules, which can be part of a central control unit or implemented as separate control units in the vehicle) are then controlled to adjust the vehicle function accordingly. In addition or alternatively, the user of the terminal device can specify a specific driving mode, e.g., "comfortable driving," "dynamic driving," etc.The corresponding control module in the vehicle, which provides the functionality, is then controlled to set the vehicle's driving mode. In addition, or alternatively, the device user can enter a destination position. The destination position can then be automatically adopted by the vehicle's navigation system.

[0027] These are merely exemplary vehicle functions; all suitable, common and future vehicle functions can be added to the above list.

[0028] Each of the vehicle functions can be recorded via the vehicle's technical parameters during a one-time registration process on the backend server and displayed to the end device users via an output unit.

[0029] Preferably, the drive request of the backend server also includes the starting position so that the selected vehicle can be moved to the starting position.

[0030] The vehicles that are registered once with the backend server can be vehicles that require a driver to move the vehicle. In addition, or alternatively, the vehicles can be vehicles that have at least a partially autonomous, but also a fully autonomous driving mode. By transmitting the starting position with the drive request from the backend server, the driver of the corresponding vehicle can move or drive the vehicle to the starting position in order to make it available to the user of the ridesharing service. Vehicles with a fully autonomous driving mode can move fully autonomously to the starting position after transmitting the starting position in order to make it available to the user of the ridesharing service. As already explained above, the starting position can be a geographical location, e.g.GPS position, which was either entered manually by the user of the ridesharing service and / or automatically adopted by a positioning module (e.g. GPS module of the terminal device).

[0031] Preferably, the driving request and the driving requirement also include a start time so that the selected vehicle can be moved to the start position at the start time.

[0032] If the user of the ridesharing service does not want to use the service immediately, but rather at a later time (either themselves or through another person), the user can also enter a start time (e.g., by entering the corresponding date and time on the device). This advantageously allows ridesharing trips to be planned well in advance.

[0033] Preferably, the large number of vehicles belong to a ridesharing vehicle fleet.

[0034] As mentioned above, the vehicles can belong to a ridesharing fleet. In this case, it may be mandatory for the vehicle to register once with the backend server.

[0035] According to the embodiments of the present invention, the user of the terminal device is thus enabled to control or regulate manipulable (i.e., controllable) vehicle functions according to their personal preferences or requirements. This also increases the convenience of users of ridesharing services.

[0036] According to a second aspect of the present invention, the underlying object is achieved by a method for dynamic control and / or regulation of vehicle functions, wherein each vehicle has a central communication unit, comprising: Receiving, at a backend server, a driving request from a terminal device, wherein the driving request comprises at least one starting position, a selection of a vehicle type from the plurality of vehicles, and at least one request for controlling and / or regulating at least one vehicle function according to a user input into an input interface on the terminal device; selecting, by the backend server, a vehicle that corresponds to the vehicle type; creating and sending a driving request comprising the request for controlling and / or regulating the at least one vehicle function to the central communication unit of the selected vehicle; and automatically controlling and / or regulating the at least one vehicle function in the selected vehicle according to the received request, In the event that a corresponding vehicle function cannot be controlled or regulated, the central communication unit can generate a corresponding message and output it to the terminal device via the backend server, whereby a user of the terminal device is then provided with the option of confirming the use of the ridesharing service via the backend server despite the non-existent vehicle function or of selecting another vehicle that can provide the corresponding vehicle function to use the ridesharing service.

[0037] Preferably, the at least one vehicle function of the vehicle comprises: at least one air conditioning or temperature control; a radio control; a multimedia content control; at least one seat heating system; at least one seat ventilation system; at least one seat cooling system; at least one seat position; at least one driving mode; and / or a vehicle navigation system.

[0038] Preferably, the drive request of the backend server also includes the starting position so that the selected vehicle can be moved to the starting position.

[0039] Preferably, the driving request and the driving requirement also include a start time so that the selected vehicle can be moved to the start position at the start time.

[0040] Preferably, the large number of vehicles belong to a ridesharing vehicle fleet.

[0041] These and other objects, features, and advantages of the present invention will become more apparent upon review of the following detailed description of preferred embodiments and the accompanying drawings. It will be appreciated that, although embodiments are described separately, individual features thereof may be combined to form additional embodiments. Fig. 1shows an exemplary method for dynamically controlling and regulating vehicle functions of a large number of vehicles; Fig. 2 shows an exemplary system for dynamically controlling and / or regulating vehicle functions of a plurality of vehicles; Fig. 3 shows an exemplary arrangement of vehicle modules, in particular with reference to the central communication unit in the vehicle; Fig. 4 shows an example terminal device and example input fields for controlling vehicle functions of a variety of vehicles.

[0042] Figure 1 shows an exemplary method 100 for dynamically controlling and / or regulating vehicle functions of a plurality of vehicles 210. The method 100 may be executed on a system 200 as described below with reference to Figure 2 explained in more detail.

[0043] The communication between the terminal device 230, the backend server 240, and the vehicle 210 can be implemented, for example, according to the client-server paradigm (request-response principle). The terminal device can be a stationary device or a mobile device. The backend server 240 can be a car-sharing service provider, but in particular a ride-sharing service provider that provides ride-sharing services to a plurality of registered vehicles 210 via a suitable communication system (e.g., a mobile network and / or the Internet).

[0044] In order to use a ridesharing service, it may be mandatory for each user of the ridesharing service to first register once with the backend server 240 via any (mobile) terminal device 230, whereby corresponding user data (e.g., user credentials, payment data, etc.) is recorded and stored in a corresponding storage unit, e.g., a database 250 and / or 260.

[0045] Each vehicle 210 comprises a central communication unit 310. The central communication unit 310 can be configured to permit only one communication connection with the backend server 240 or server 240. This advantageously ensures that only driving requests received via the backend server 240, comprising at least one request to control and / or regulate at least one vehicle function 330, 340, 350, 360, 370, 380, can initiate the control and / or regulation of the corresponding vehicle function 330, 340, 350, 360, 370, 380. This prevents any other unauthorized attempts to manipulate the vehicle functions 330, 340, 350, 360, 370, 380.

[0046] In advance, it may also be mandatory that each vehicle 210 or the corresponding communication module 310 is registered once with the backend server 240, for example via a corresponding registration process by an authorized user of the vehicle 210. In other words, a prior one-time registration of each vehicle 210 of the plurality of vehicles 210 on the backend server 240 may be required. This prevents unauthorized use of vehicles 210. During the one-time registration process, technical parameters of the vehicle 210 and optionally further data required depending on the context (e.g., data relating to an owner and / or driver of the corresponding vehicle or a passenger in vehicles with at least one at least partially autonomous driving mode) can be recorded and stored in a storage unit, e.g., a database 250 and / or 260.The technical parameters can, in particular, be technical parameters relating to the manipulable, i.e., controllable or regulatable vehicle functions 330, 340, 350, 360, 370, 380. Advantageously, this makes it possible to record and store for each vehicle on the backend server 240 which vehicle functions 330, 340, 350, 360, 370, 380 can be dynamically manipulated by the vehicle 210 via the mobile terminal 230. The registration of the users (via the backend devices 230) and the vehicles 210, as well as the storage of the corresponding data in at least one database 250 and / or 260, to which the backend server 240 has access, can be implemented by one and the same server 240. Alternatively, the registration processes and the storage of the corresponding data can be implemented by different servers (not shown) and stored in different databases 250 or 260 (for example, for data protection reasons).

[0047] Each vehicle 210 can send its current position to the backend server 240, e.g., via the central communication unit 310, which may have a corresponding positioning module, e.g., a GPS module (not shown), at predeterminable or predetermined time intervals (e.g., every minute, every 5 minutes, etc.) and / or at predeterminable or predetermined events (e.g., vehicle start, vehicle stop, start of a trip, end of a trip, etc.), which can be stored or updated there accordingly. Advantageously, the backend server 240 always knows the current position of all registered vehicles 210.

[0048] After successfully completing the one-time registration process for each vehicle 210 and for the users of the ridesharing service, the following procedure can now be carried out, possibly after prior login (user credentials): Step 110: Each (registered) user can create a ride request for using the ridesharing service via the mobile terminal 230 and send it to the backend server 240. The ride request comprises at least one starting position, at least one selection of a vehicle type from the plurality of vehicles 210, and at least one request for controlling and / or regulating at least one vehicle function 330, 340, 350, 360, 370. For example, correspondingly registered and drivable vehicles 210 can be displayed via a suitable output unit of the terminal 230 in a predetermined or predeterminable geographical area around the starting position (e.g., a radius of 5 kilometers), for example, on a digital map. For example, the user of the ridesharing service can enter the starting position using a corresponding human-machine interface in the terminal 230 (e.g., since there is no positioning module, e.g.,GPS, is present in the terminal 230 and / or if the starting position deviates from a current position of the terminal 230). In another example, the starting position can be the current geographical position of the user of the ridesharing service, which is determined by a positioning module included on or in the terminal 230 (e.g. GPS module, not shown) and adopted accordingly. The user of the terminal 230 can select a vehicle type in a further step. In a further step, vehicle functions 330, 340, 350, 360, 370, 380, which correspond, for example, to the technical parameters stored during the registration process and which the user of the terminal can manipulate (i.e. control and / or regulate) according to his personal preferences, can be displayed to the user of the terminal 230 via the terminal 230 (see also below, . Figure 4). The user of the terminal device 230 can now at least perform one manipulation of the corresponding vehicle functions 330, 340, 350, 360, 370, 380 via the terminal device 230. This process corresponds to a request to control and / or regulate the at least one vehicle function 330, 340, 350, 360, 370, 380. Based on the selected vehicle 210 and the request to control and / or regulate the at least one vehicle function 330, 340, 350, 360, 370, 380, the terminal device 240 now creates a drive request comprising the starting position and the request to control and / or regulate the at least one vehicle function 330, 340, 350, 360, 370, 380. The drive request is transmitted from the terminal device 230 to the backend server 240. Step 120: The backend server 240 can process the drive request accordingly after receiving it.In particular, the backend server 240 will select a vehicle that corresponds to the vehicle type selected by the user via the terminal 230 and optionally meets further predetermined criteria (e.g., fill level of the vehicle's energy storage device (fuel level and / or battery charge level), geographical distance, etc.) and, in step 122, create a drive request for the selected vehicle 210 and send it to the central communication unit 310 of the vehicle 210. The drive request comprises at least the request contained in the drive request for the control and / or regulation of at least one vehicle function 330, 340, 350, 360, 370, 380. Step 130: The drive request is received at the selected vehicle 130, in particular at the central communication unit 310 of the vehicle 130, and processed accordingly.Step 132: The selected vehicle 210 can create a ride response 132, which includes a confirmation or rejection of the ride request, and send it to the backend server 230.

[0049] In a further step 134, the selected vehicle 210 will carry out the control and / or regulation of the at least one vehicle function 330, 340, 350, 360, 370, 380. The central communication unit 310 can process the driving request accordingly and control and / or regulate the at least one vehicle function 330, 340, 350, 360, 370, 380 in accordance with the request for control and / or regulation. The central communication unit 310 can be implemented, for example, on a control unit or a control device 320 that is capable of controlling or regulating the corresponding vehicle functions 330, 340, 350, 360, 370, 380. In another example, the central communication unit 310 can be implemented on a control unit ora control unit which is communicatively connected to one or more further control units and / or control units 320 in the vehicle 210, which are designed to control or regulate the vehicle function 330, 340, 350, 360, 370, 380.

[0050] Advantageously, each user of the ridesharing service of the backend server 240 can control or regulate vehicle functions 330, 340, 350, 360, 370, 380 of a plurality of vehicles 210 dynamically and securely via the backend server 240 during or immediately before using the ridesharing service.

[0051] In the event that one or more vehicle functions 330, 340, 350, 360, 370, 380 cannot be controlled or regulated - for example due to a lack of this vehicle function 330, 340, 350, 360, 370, 380 in the selected vehicle 210 and / or a malfunction of one or more of the components providing the vehicle function - the central communication unit 310 can send a corresponding message to the terminal 230 via the backend server 240. The user of the terminal 230 is then provided with the option of confirming the use of the ridesharing service via the backend server 240 despite the missing vehicle function(s) 330, 340, 350, 360, 370, 380 or of selecting another vehicle 210 which has the corresponding vehicle function(s). 330, 340, 350, 360, 370, 380 to use the ridesharing service (not shown).

[0052] Step 140: The backend server 240 can receive the driving response and forward it to the terminal device.

[0053] Step 150: The terminal 230 can receive the driving response, process it, and display it via an output unit in the terminal 230.

[0054] Figure 2shows an exemplary system 200 for dynamically controlling and / or regulating vehicle functions of a plurality of vehicles 210. As already mentioned above, the vehicles 210 can belong to a ridesharing vehicle fleet. In this case, it may be mandatory for each vehicle 210 to register once with the backend server 240. This advantageously enables users of ridesharing services to control and / or regulate enabled vehicle functions 330, 340, 350, 360, 370, 380 (i.e., manipulable via the terminal 230, i.e., controllable and / or regulated) according to their personal preferences or requirements. This also increases the convenience of the users of the ridesharing services.

[0055] Each vehicle 210 of the plurality of vehicles 210 has a central communication unit 310. The central communication unit comprises at least one subscriber identity module or a SIM card, which serves to establish a communication connection via a mobile radio system. The subscriber identity module uniquely identifies the communication unit 310 in the mobile radio network. Each central communication unit 310 can be configured to be able to establish or permit only one communication connection with the backend server 240 or server 240.Advantageously, it can thus be ensured that only driving requests received via the backend server 240, comprising at least one request for controlling and / or regulating at least one vehicle function 330, 340, 350, 360, 370, 380, can control and / or regulate the control and / or regulating of the corresponding vehicle function 330, 340, 350, 360, 370, 380 in the selected vehicle 210.

[0056] A prior, one-time registration of each vehicle 210 of the plurality of vehicles 210 on the backend server 240 may be required. This increases security because unauthorized manipulation of the corresponding vehicle functions 330, 340, 350, 360, 370, 380 is prevented. During the one-time registration process, technical parameters of the vehicle 210 and optionally further data required depending on the context (e.g., data regarding an owner and / or driver of the corresponding vehicle) can be recorded and stored in a storage unit, e.g., a database 250 and / or 260. The technical parameters can, in particular, be technical parameters relating to the vehicle functions 330, 340, 350, 360, 370, 380. Advantageously, this makes it possible to record and store for each vehicle 210 on the backend server 240 which manipulable (i.e.,controllable and / or adjustable) vehicle functions 330, 340, 350, 360 provided by the vehicle 210.

[0057] Each vehicle 210 can send or transmit its current position to the backend server 240, e.g., via the central communication unit 310, which may have a corresponding positioning module, e.g., a GPS module (not shown), at predeterminable or predetermined time intervals (e.g., every minute, every 5 minutes, etc.) and / or at predeterminable or predetermined events (e.g., vehicle start, vehicle stop, start of a trip, end of a trip, etc.). Advantageously, the backend server 240 thus always knows the current position of all registered vehicles 210.

[0058] The backend server 240 may be a car-sharing service provider, but in particular a ride-sharing service provider that provides ride-sharing services to a plurality of registered vehicles 210 via a suitable communication system (e.g., mobile network and / or Internet). In order to use a ride-sharing service, it may be mandatory for each user of the ride-sharing service to initially register once with the backend server 240 via a terminal device 230, whereby corresponding user data (e.g., user credentials, payment data, etc.) can be recorded and stored in a corresponding storage unit, e.g., a database 250 and / or 260.

[0059] The terminal 230 may be a stationary terminal 230, a mobile terminal 230, AR, VR, or MR glasses, or AR, VR, or MR contact lenses (not shown).

[0060] After successfully completing the one-time registration process of the plurality of vehicles 210 and at least one user of the ridesharing service on the backend server 240, each user can log in via any terminal device 230 (user credentials) and send a ride request to the backend server 240 via the terminal device 230.

[0061] The ride request comprises at least one starting position and at least one request for controlling and / or regulating at least one vehicle function. For example, the plurality of (correspondingly registered and drivable vehicles 210) can be displayed via a suitable output unit of the terminal device 230 in a predetermined or predeterminable geographical vicinity of a starting position (e.g., a radius of 5 kilometers), for example on a digital map. For example, the user of the ridesharing service can enter the starting position using a corresponding human-machine interface in the terminal device 230 (e.g., because no positioning module, e.g., GPS, is present in the terminal device and / or if the starting position deviates from a current position of the terminal device). In another example, the starting position can be the current geographical position of the user of the ridesharing service, which can be determined from a location on orin the terminal 230 by the positioning module (e.g., GPS module, not shown) and adopted accordingly. The user of the ridesharing service can also select a vehicle type via the terminal 230.

[0062] In a further step, vehicle functions 330, 340, 350, 360, 370, 380, which correspond, for example, to the technical parameters of the selected vehicle type stored in the database 250, 260 and which the user of the terminal can manipulate according to their personal preferences, can be displayed to the user of the ride-sharing service via the terminal 230. Preferably, the vehicle functions 330, 340, 350, 360, 370, 380 of the vehicle 210 include: at least one air conditioning or temperature control 330; a radio control 340; a multimedia content control 340; at least one seat heating 360; at least one seat ventilation 360; at least one seat cooling 360; at least one seat position 350; at least one driving mode 370; and / or a vehicle navigation system 380.

[0063] For example, a list of vehicle functions 330, 340, 350, 360, 370, 380 that can be manipulated (ie, controlled and / or regulated) for the selected vehicle type can be displayed on the terminal 230 via an output unit. The user of the terminal can make corresponding settings as described below with reference to Figure 4 described and explained in more detail.

[0064] For example, the user can enter a desired vehicle interior temperature 330 via a corresponding input interface on the terminal device 230. In the vehicle 210 selected by the backend server 240, which corresponds to the vehicle type selected by a user via the terminal device 230, the heating and / or air conditioning system are subsequently regulated (as explained in more detail below) such that the desired vehicle interior temperature is reached and maintained. In addition or alternatively, the user of the terminal device can enter a desired radio station 240 and optionally a desired volume. A radio module in the selected vehicle 210 is then controlled such that the desired radio station and optionally the corresponding volume are set. In addition or alternatively, the user of the terminal device 230 can select further multimedia content 340.The corresponding multimedia unit(s) in the vehicle is (are) then controlled such that the corresponding multimedia content is started and / or set. In addition or alternatively, the user of the terminal device 230 can input that they desire seat heating 230 and / or seat ventilation 260 and / or seat cooling 260 and / or a specific seat setting 250. The corresponding units providing the functionality (e.g., control units or software modules that are part of a central control unit) in the vehicle 210 are then controlled such that the vehicle function is set accordingly. In addition or alternatively, the user of the terminal device 230 can input a specific driving mode 370, e.g., "comfortable driving," "dynamic driving," etc. The corresponding control module providing the functionality in the vehicle 210 can then control the setting of the corresponding driving mode in the vehicle 210.In addition or alternatively, the user of the ridesharing service can enter a destination position 380. The destination position can then be automatically adopted by the navigation system of the vehicle 210 via a corresponding control unit in the vehicle 210. These are merely exemplary vehicle functions 330, 340, 350, 360, 370, 380; all suitable, common, and future vehicle functions can be added to the above list. Each of the vehicle functions 330, 340, 350, 360, 370, 380 can be recorded during the one-time registration process on the backend server 240 using the technical parameters of the vehicle 210 and output via the terminal 230.

[0065] Thus, users can now at least manipulate the corresponding vehicle functions 330, 340, 350, 360, 370, 380 of a plurality of vehicles 210 via the terminal 230. This process corresponds to a request to control and / or regulate at least one vehicle function 330, 340, 350, 360, 370, 380.

[0066] Based on the selected vehicle type and the request to control and / or regulate the at least one vehicle function 330, 340, 350, 360, 370, 380, the terminal device 230 then creates a driving request comprising the starting position and the request to control and / or regulate the at least one vehicle function 330, 340, 350, 360, 370, 380, and sends this to the backend server 240. The backend server 240 will then select a vehicle 210 from the plurality of vehicles 210 according to the vehicle type (selected by the user via the terminal device 230), create a driving request comprising at least the request to control and / or regulate the at least one vehicle function 330, 340, 350, 360, 370, 380, and send it to the central communication unit 310 of the selected vehicle 210.The central communication unit 310 will process the driving request accordingly and control and / or regulate the at least one vehicle function 330, 340, 350, 360, 370, 380 according to the request for controlling and / or regulating the at least one vehicle function 330, 340, 350, 360, 370, 380. The central communication unit 310 can be implemented, for example, on a control unit or a control device that is capable of controlling or regulating the corresponding vehicle functions 330, 340, 350, 360, 370, 380. In another example, the central communication unit 310 may be implemented on a control unit or control device that is communicatively connected to one or more further control units 320 and / or control devices 320 in the vehicle 210, which are configured to control or regulate the vehicle functions 330, 340, 350, 360, 370, 380.

[0067] The driving request from the backend server 240 can also include the starting position so that the selected vehicle 210 can be moved to the starting position. The vehicles 210 that are registered once with the backend server 240 can be vehicles 210 that require a driver to move the vehicle 210. Furthermore or alternatively, the vehicles 210 can be vehicles 210 that have at least one partially autonomous driving mode. By transmitting the starting position with the driving request from the backend server 240, the driver of the corresponding vehicle 210 can move or drive the vehicle to the starting position in order to make it available to the user of the ridesharing service. Vehicles 210 with a fully autonomous driving mode can move or drive to the starting position fully autonomously after transmitting the starting position in order to make it available to the user of the ridesharing service.As already explained above, the starting position can be a geographical position, e.g. GPS position, which the user of the ridesharing service either entered manually and / or was automatically adopted by a positioning module (e.g. GPS module of the end device).

[0068] In addition, the driving request and the driving requirement may also include a start time so that the selected vehicle 210 can be moved to the start position at the start time.

[0069] If the user of terminal device 230 does not want to use the ridesharing service immediately, but only at a later time (either themselves or through another person), the user can also enter a start time (e.g., by entering the corresponding date and time via terminal device 230). This advantageously allows trips with the ridesharing service to be planned well in advance.

[0070] Advantageously, the user of the terminal 230 can thus securely control or regulate vehicle functions 330, 340, 350, 360, 370, 380 of a plurality of vehicles 210 via the backend server 240 during or immediately before using the ridesharing service via the terminal 230.

[0071] In the event that a corresponding vehicle function 330, 340, 350, 360, 370, 380 cannot be controlled or regulated - for example due to a malfunction of one or more of the components providing the vehicle function 330, 340, 350, 360, 370, 380 - the central communication unit 310 can generate a corresponding message and transmit or send it to the terminal 230 via the backend server 240. The user of the terminal device 230 can then be provided with the option of confirming the use of the ridesharing service via the backend server 240 despite the lack of the vehicle function 330, 340, 350, 360, 370, 380 or another vehicle 210 that can provide the corresponding vehicle function 330, 340, 350, 360, 370, 380, which can be manipulated via the terminal device 230.

[0072] The above-mentioned method 100 and system 200 are particularly advantageous for a vehicle fleet consisting of fully autonomous vehicles, since personalization can be realized completely independently of the driver.

[0073] Figure 3 shows an exemplary arrangement of vehicle modules on which the vehicle functions 330, 340, 350, 360, 370, 380, on which the vehicle functions are implemented in hardware and / or software, with reference to the central communication unit 310.

[0074] As already mentioned with reference to Figure 1 and 2As mentioned above, each vehicle 210 includes a central communication unit 310. The central communication unit 310 can be implemented as a control unit, as a software module of a control unit, or on a dedicated control unit. It can be configured to control and / or regulate the modules on which the vehicle functions 330, 340, 350, 360, 370, 380 are implemented. In another example, the central communication unit 310 can be communicatively connected to one or more control units 320 configured to control or regulate corresponding vehicle functions 330, 340, 350, 360, 370, 380, and forward the corresponding control and / or regulation commands to the one or more control units 320.

[0075] Figure 4 shows an exemplary terminal 230 and exemplary input fields 422, 424, 426 for controlling vehicle functions 330, 340, 350, 360, 370, 380 of a plurality of vehicles 210 as described above with reference to the Figure 1 , 2 and 3 described. Available vehicles 210 and / or vehicle types are displayed on a digital map 215 on the terminal 230. For a selected vehicle type, some of the vehicle functions selectable via the terminal 230 are displayed in a drop-down list 420. In particular, a "Do Not Disturb" vehicle function 422 can be selected. In addition, an available radio station can be selected as vehicle function 424. In a next field 426, the interior temperature can be selected as vehicle function 330, 340, 350, 360, 370, 380.

Claims

1. System (200) for dynamically controlling and / or regulating vehicle functions (330, 340, 350, 360, 370, 380) of a multiplicity of vehicles (210) of a ride-sharing service, each vehicle (210) having a central communication unit (310), comprising: at least one backend server (240); at least one terminal (230) which is configured to send a driving request to the backend server (240), wherein the driving request comprises at least one starting position, a selection of a vehicle type from the multiplicity of vehicles (210) and at least one requirement to control and / or regulate at least one vehicle function (330, 340, 350, 360, 370, 380) according to a user input into an input interface on the terminal (230); wherein the backend server (240) is configured, after receiving the driving request, to select a vehicle (210) corresponding to the vehicle type and to send a drive requirement comprising the requirement to control and / or regulate the at least one vehicle function (330, 340, 350, 360, 370, 380) to the central communication unit (310) of the selected vehicle (210); and wherein the at least one vehicle function (330, 340, 350, 360, 370, 380) of the selected vehicle (210) is controlled and / or regulated according to the control and regulation requirement in the vehicle request, wherein, if a corresponding vehicle function (330, 340, 350, 360, 370, 380) cannot be controlled and / or regulated, the central communication unit (310) generates a corresponding message and outputs it via the backend server (240) to the terminal (230), wherein a user of the terminal (230) is then provided with the possibility of confirming the use of the ride-sharing service despite the unavailable vehicle function (330, 340, 350, 360, 370, 380) via the backend server (240), or selecting another vehicle (210), which can provide the corresponding vehicle function (330, 340, 350, 360, 370, 380), for the use of the ride-sharing service.

2. System (200) according to Claim 1, wherein the at least one vehicle function (330, 340, 350, 360, 370, 380) of the vehicle (210) comprises: - at least one air conditioning or temperature regulation means (330); - control of the radio (340); - control of multimedia content (340); - at least one seat heating means (360); - at least one seat ventilation means (360); - at least one seat cooling means (360); - at least one seat position (350); - at least one driving mode (370); and / or - a navigation system (380).

3. System (200) according to Claim 1 or 2, wherein the drive requirement from the backend server (240) also comprises the starting position, so that the selected vehicle (210) can be moved to the starting position.

4. System (200) according to Claim 3, wherein the driving request and the drive requirement also comprise a starting time, so that the selected vehicle (210) can be moved to the starting position at the starting time.

5. System (200) according to one of the preceding claims, wherein the multiplicity of vehicles (210) belong to a ride-sharing vehicle fleet.

6. Method (100) for dynamically controlling and / or regulating vehicle functions (330, 340, 350, 360, 370, 380) of a multiplicity of vehicles (210) of a ride-sharing service, each vehicle (210) having a central communication unit (310), comprising: receiving (110), in a backend server (240), a driving request from a terminal (230), wherein the driving request comprises at least one starting position, a selection of a vehicle type from the multiplicity of vehicles (210) and at least one requirement to control and / or regulate at least one vehicle function (330) according to a user input into an input interface on the terminal (230); selecting, by means of the backend server (240), a vehicle (210) corresponding to the vehicle type; creating (122) and sending a drive requirement comprising the requirement to control and / or regulate the at least one vehicle function (330, 340, 350, 360, 370, 380) to the central communication unit (310) of the selected vehicle (210); and automatically controlling and / or regulating (134) the at least one vehicle function (330, 340, 350, 360, 370, 380) in the selected vehicle (210) according to the requirement received in the selected vehicle (210), wherein, if a corresponding vehicle function (330, 340, 350, 360, 370, 380) cannot be controlled and / or regulated, the central communication unit (310) generates a corresponding message and outputs it via the backend server (240) to the terminal (230), wherein a user of the terminal (230) is then provided with the possibility of confirming the use of the ride-sharing service despite the unavailable vehicle function (330, 340, 350, 360, 370, 380) via the backend server (240), or selecting another vehicle (210), which can provide the corresponding vehicle function (330, 340, 350, 360, 370, 380), for the use of the ride-sharing service.

7. Method (100) according to Claim 6, wherein the at least one vehicle function (330, 340, 350, 360, 370, 380) comprises: - at least one air conditioning or temperature regulation means (330); - control of the radio (340); - control of multimedia content (340); - at least one seat heating means (360); - at least one seat ventilation means (360); - at least one seat cooling means (360); - at least one seat position (350); - at least one driving mode (370); and / or - a navigation system (380).

8. Method (100) according to either of Claims 6 and 7, wherein the drive requirement from the backend server (240) also comprises the starting position, so that the selected vehicle (210) can be moved to the starting position.

9. Method (100) according to Claim 8, wherein the driving request and the drive requirement also comprise a starting time, so that the selected vehicle (210) can be moved to the starting position at the starting time.

10. Method (100) according to one of Claims 6 to 9, wherein the multiplicity of vehicles (210) belong to a ride-sharing vehicle fleet.