Patent Description:
Digital vehicle keys are the digital equivalents of classical hardware vehicle keys and allow to perform various vehicle functions such as locking and unlocking or starting of the vehicle. However, the functionalities provided for digital vehicle keys are still limited. Further, users conventionally have to provide several identifiers for accessing vehicles remotely.

Document <CIT> relates to a method and system to utilize a key fob in a car-sharing vehicle access system. The method involves verifying the fob for use with a specific vehicle, receiving an activation command, obtaining authorization to control certain functions of the vehicle, enabling transmission of vehicle commands via the fob, allowing the user to request commands, sending the requested command to the vehicle, and then disabling the fob from further controlling the vehicle functions.

Document <CIT> relates to a system for enabling access to and use of a vehicle via electronic keys using a cloud-based server. The vehicle is equipped with electronics and subsystems that allow for unlocking and starting of the vehicle. The vehicle's communication circuitry can communicate with the cloud system and a mobile device, and receive requests for vehicle access from the mobile device. These requests must include a unique access code that is associated with certain access privileges. The vehicle is programmed to authenticate the request from the mobile device, and provide an electronic key if the request is authentic and the access privileges of the unique access code are met. The electronic key enables unlocking and starting of the vehicle consistent with the defined privileges of the unique access code.

Document <CIT> relates to a technique to personalize a vehicle for one or more users. The process entails identifying the user accessing the vehicle, gathering first customization settings linked to this user identifier from a remote server, and configuring the vehicle's systems based on the received customization settings.

Document <CIT> relates to verifying a user's identity when they're on a transportation vehicle. The transportation vehicle is linked to an external device that stores a secret code for authentication and to a token that stores another secret code. The method involves transmitting the token secret code to the transportation vehicle when a user interacts with the token. A new secret code is generated from the token secret code and compared to the authentication secret code. If they match, the user is authorized to ride the transportation vehicle. An equipment for this type of user authentication is also provided.

There may be a demand for improved utilization of digital vehicle keys.

This demand may be satisfied by the subject-matter of the appended independent and dependent claims.

An example relates to a server communicatively coupled to a vehicle via a network. The server comprises circuitry configured to receive request data. The request data indicate a request to provide dynamic status information about the vehicle and/or to execute a vehicle function at the vehicle. The request data further indicate an identifier of a digital vehicle key for the vehicle. Further, the apparatus comprises circuitry configured to determine, based on the identifier of the digital vehicle key, whether the request is in compliance with vehicle access and/or control rights assigned to the digital vehicle key. In addition, the apparatus comprises circuitry configured to process the request, if it is determined that the request is in compliance with the vehicle access and/or control rights assigned to the digital vehicle key. For processing the request, the circuitry is configured to request the dynamic status information from the vehicle via the network and forward the dynamic status information upon receipt from the vehicle to a sender of the request data, if the request data indicate the request to provide the dynamic status information. If the request data indicate the request to execute the vehicle function at the vehicle, the circuitry is configured to control the vehicle via the network to execute the vehicle function, if the request data indicate the request to execute the vehicle function at the vehicle.

Another example relates to a system comprising a server as described herein and a user equipment (UE). The UE comprises a data storage configured to store the digital vehicle key. Further, the UE comprises processing circuitry configured to generate the request data In addition, the UE comprises wireless communication circuitry configured to transmit the request data to the server or another server communicatively coupled to the server.

A further example relates to a method for a server communicatively coupled to a vehicle via a network. The method comprises receiving request data. The request data indicate a request to provide dynamic status information about the vehicle and/or to execute a vehicle function at the vehicle. The request data further indicate an identifier of a digital vehicle key for the vehicle.

Additionally, the method comprises determining, based on the identifier of the digital vehicle key, whether the request is in compliance with vehicle access and/or control rights assigned to the digital vehicle key. The method further comprises processing the request, if it is determined that the request is in compliance with the vehicle access and/or control rights assigned to the digital vehicle key. Processing the request comprises requesting the dynamic status information from the vehicle via the network and forwarding the dynamic status information upon receipt from the vehicle to a sender of the request data, if the request data indicate the request to provide the dynamic status information. If the request data indicate the request to execute the vehicle function at the vehicle, processing the request comprises controlling the vehicle via the network to execute the vehicle function.

Examples of the present disclosure may allow to use the digital vehicle key as identifier for accessing dynamic status information about the vehicle and/or executing a vehicle function at the vehicle. No other (e.g. third-party) identifiers are needed.

Some examples of apparatuses, methods and/or computer programs will be described in the following by way of example only, and with reference to the accompanying figures, in which.

Optional components may be illustrated using broken, dashed, or dotted lines.

<FIG> illustrates a system <NUM> comprising an apparatus <NUM> and a UE <NUM>.

The UE <NUM> is any device used or usable directly by a (end-)user. In the example of <FIG>, the UE <NUM> is illustrated as a mobile phone (smartphone). However, the UE <NUM> is not limited thereto. In other examples, the UE <NUM> may be any other type of mobile device such as a tablet-computer, a laptop-computer or a wearable device like a smart watch, smart glasses, etc. In still other examples, the UE <NUM> may be a stationary device such as personal computer.

The UE <NUM> comprises a data storage <NUM> configured to store a digital vehicle key for a vehicle. For example, the data storage <NUM> may be Non-Volatile Memory (NVM) including high-speed electrically erasable memory (commonly referred to as Flash memory), Phase change Random Access Memory (PRAM), Magnetoresistive Random Access Memory (MRAM) and/or a three-dimensional crosspoint (3D XPoint) memory. The memory may be implemented as one or more of solder down packaged integrated circuits, socketed memory modules and plug-in memory cards. The digital vehicle key is a data structure representing a digital copy of the vehicle's physical key. Like the vehicle's physical key, the digital vehicle key may be used to, e.g., unlock or start the vehicle. The vehicle may be any apparatus that comprises one or more wheel driven by an engine (and optionally a powertrain system). For example, the vehicle may be a private vehicle or a commercial vehicle. In particular, the vehicle may be an automobile, a truck, a motorcycle or a tractor.

The UE <NUM> additionally comprises processing circuitry <NUM> coupled to the data storage <NUM>. For example, the processing circuitry <NUM> may be a single dedicated processor, a single shared processor, or a plurality of individual processors, some of which or all of which may be shared, an application processor, a Digital Signal Processor (DSP) hardware, an Application Specific Integrated Circuit (ASIC), a neuromorphic processor or a Field Programmable Gate Array (FPGA). In addition to the data storage <NUM>, the processing circuitry <NUM> may optionally be coupled to, e.g., Read Only Memory (ROM) for storing software and/or Random Access Memory (RAM).

The processing circuitry <NUM> is configured to generate request data <NUM> indicating a request to provide dynamic status information about the vehicle and/or to execute a vehicle function at the vehicle. The dynamic status information about the vehicle is any piece of information that describes a state or condition of the vehicle that can change or vary over time. For example, the dynamic status information may be (indicate) one or more of a geolocation of the vehicle, a lock status of the vehicle (i.e. whether the vehicle is locked or unlocked), a range of the vehicle (i.e. a distance that can still be driven or travelled with the vehicle), a state of charge of an electric battery of the vehicle and a fill level of a fuel tank of the vehicle. However, it is to be noted that the present disclosure is not limited to the foregoing exemplary pieces of dynamic status information. The vehicle function may be any action offered by the vehicle to a user. For example the vehicle function may be one or more of locking or unlocking of the vehicle, opening or closing of a window of the vehicle, starting or stopping of the vehicle, adjusting a setting of an air-conditioning system of the vehicle and adjusting a setting of an entertainment system of the vehicle. However, it is to be noted that the present disclosure is not limited to the foregoing exemplary vehicle functions.

The request data <NUM> further indicate at least one of an identifier of the digital vehicle key and a token derived from the digital vehicle key. In other words, the request data <NUM> may either indicate only one of the identifier of the digital vehicle key and the token derived from the digital vehicle key, or the request data <NUM> may indicate both the identifier of the digital vehicle key and the token derived from the digital vehicle key. The identifier of the digital vehicle key is one or more word, letter, number and/or symbol that identifies (i.e. labels the identity of) the digital vehicle key. The identifier may in some examples be a unique identifier, i.e., an identifier that refers to only one particular digital vehicle key. The token is a sequence of one or more letter, number and/or symbol (e.g. a string) derived according to a predefined rule or set of rules (e.g. defined in an algorithm) from the digital vehicle key. The identifier of the digital vehicle key and/or the token derived from the digital vehicle key may be generated by the processing circuitry <NUM>. In other examples, the identifier of the digital vehicle key and/or the token derived from the digital vehicle key may be read by the processing circuitry <NUM> from a memory of the UE <NUM> such as the data storage <NUM>.

For example, the UE <NUM> may comprise a user interface such as a touch-sensitive display (touch screen) <NUM> or a button <NUM> configured to receive a user input (i.e. an input of a user). Accordingly, the processing circuitry <NUM> may be configured to generate the request data <NUM> in response to the user input. In other examples, the processing circuitry <NUM> may be configured to generate the request in response to another request received from an application executed by the processing circuitry <NUM> or any other circuitry of the UE <NUM>.

Additionally, the UE <NUM> comprises wireless communication circuitry <NUM> configured to transmit the request data <NUM> (e.g. by causing one or more antenna <NUM> of the UE <NUM> to radiate radio waves modulated with the request data <NUM>). The wireless communication circuitry <NUM> may, e.g., be configured to operate according to one of the 3rd Generation Partnership Project (3GPP)-standardized mobile/wireless communication networks or systems such as a <NUM>th Generation New Radio (<NUM> NR) network, a Long-Term Evolution (LTE) network or an LTE-Advanced (LTE-A) network. Alternatively or additionally, the wireless communication circuitry <NUM> may be configured to operate according to mobile/wireless communication networks with different standards, for example, a Worldwide Inter-operability for Microwave Access (WIMAX) network according to the standard IEEE <NUM> of the Institute of Electrical and Electronics Engineers (IEEE), a Wireless Local Area Network (WLAN) according to the standard IEEE <NUM> of the IEEE, a Near-Field Communication (NFC) network or an Ultra-WideBand (UWB) network, generally an Orthogonal Frequency Division Multiple Access (OFDMA) network, a Time Division Multiple Access (TDMA) network, a Code Division Multiple Access (CDMA) network, a Wideband-CDMA (WCDMA) network, a Frequency Division Multiple Access (FDMA) network, a Spatial Division Multiple Access (SDMA) network, etc..

The UE <NUM> may comprise further elements such as, e.g., a baseband processor, an audio driver, a camera driver, a display driver, sensors, removable memory, a power management integrated circuit or a smart battery.

In particular, the wireless communication circuitry <NUM> is configured to transmit the request data <NUM> to the apparatus <NUM> for processing the request data <NUM>, or to an entity comprising the apparatus <NUM>.

The apparatus <NUM> may, e.g., be part of the vehicle, be a server communicatively coupled to the vehicle, or be part of a server communicatively coupled to the vehicle. As claimed, the apparatus <NUM> is a server.

For example, if the apparatus <NUM> is part of the vehicle, the wireless communication circuitry <NUM> of the UE <NUM> may be configured to transmit the request data <NUM> to the vehicle via a cellular network or a local wireless network (e.g. a WLAN network or a UWB network). In other examples, if the apparatus <NUM> is a server or part of a server communicatively coupled to the vehicle via a network (such as the Internet and/or a cellular network), the wireless communication circuitry <NUM> of the UE <NUM> may be configured to transmit the request data <NUM> directly to the apparatus <NUM> or another (intermediate) server communicatively coupled to the apparatus <NUM>, wherein the other (intermediate) server forwards the request data <NUM> to the apparatus <NUM>.

The apparatus <NUM> comprises various circuitry such as interface circuitry, processing circuitry and memory circuitry. The circuitry of the apparatus <NUM> is configured to receive the request data <NUM> - either directly from the UE <NUM> or from one or more intermediate devices such as one or more server.

Additionally, the circuitry of the apparatus <NUM> is configured to determine, based on the identifier of the digital vehicle key and/or the token, whether the request is in compliance with vehicle access rights and/or control rights assigned to the digital vehicle key. The vehicle access rights define permissions to access the vehicle and/or selected (predefined) pieces of information about the vehicle (e.g. selected pieces of dynamic status information about the vehicle) granted to one or more digital vehicle key and/or one or more user. The control rights define permissions to control selected (predefined) vehicle functions of the vehicle granted to one or more digital vehicle key and/or one or more user. For determining whether the request is in compliance with the vehicle access rights and/or control rights assigned to the digital vehicle key, the circuitry of the apparatus <NUM> may, e.g., compare whether access to the requested dynamic status information is granted to the digital vehicle key and/or whether control of the requested vehicle function is granted to the digital vehicle key. If access to the requested dynamic status information is granted to the digital vehicle key, it may be determined that the request is in compliance with the vehicle access and/or control rights assigned to the digital vehicle key. Similarly, it may be determined that the request is in compliance with the vehicle access and/or control rights assigned to the digital vehicle key if control of the requested vehicle function is granted to the digital vehicle key.

For example, the identifier of the digital vehicle key and/or the token may comprise information about the vehicle access and/or control rights assigned to the digital vehicle key. Accordingly, the circuitry of the apparatus <NUM> may determine whether the request is in compliance with vehicle access rights and/or control rights assigned to the digital vehicle key by comparing the request to the vehicle access and/or control rights indicated by the identifier of the digital vehicle key and/or the token. In this example, there is no need for retrieving information about the vehicle access and/or control rights assigned to the digital vehicle key from another source such as a server of a manufacturer of the vehicle.

In other examples, the circuitry of the apparatus <NUM> may alternatively be configured to retrieve information about the vehicle access and/or control rights assigned to the digital vehicle key from rights management circuitry based on the identifier of the digital vehicle key and/or the token. The rights management circuitry is configured to manage the vehicle access and/or control rights for the vehicle and optionally further vehicle. For example, the rights management circuitry may be supervised and/or operated by a manufacturer of the vehicle or a service provider (e.g. a vehicle rental company). By retrieving the information about the vehicle access and/or control rights assigned to the digital vehicle key from the rights management circuitry, an integrity of the information about the vehicle access and/or control rights assigned to the digital vehicle key may be ensured.

If it is determined that the request is in compliance with the vehicle access and/or control rights assigned to the digital vehicle key, the circuitry of the apparatus <NUM> is configured to process the request. On the other hand, if it is determined that the request is not in compliance with the vehicle access and/or control rights assigned to the digital vehicle key, the circuitry of the apparatus <NUM> is configured to discard (reject, dismiss) the request.

The system <NUM> may allow to use the digital vehicle key as identifier for accessing dynamic status information about the vehicle and/or executing a vehicle function at the vehicle. No other (e.g. third-party) identifiers are needed.

For example, in case the apparatus <NUM> is a server or part of a server communicatively coupled to the vehicle via a network, the circuitry of the apparatus <NUM> may be configured to request the dynamic status information from the vehicle via the network and forward the dynamic status information upon receipt from the vehicle to a sender of the request data (e.g. by sending response data indicating the requested dynamic status information to the sender of the request data), if the request data <NUM> indicate the request to provide the dynamic status information. The sender of the request data <NUM> may, e.g., be the UE <NUM>, or an intermediate device coupled between the apparatus <NUM> and the UE <NUM> such that the UE <NUM> receives the dynamic status information either directly from the apparatus <NUM>, or from the intermediate device. Similarly, the circuitry of the apparatus <NUM> may be configured to control the vehicle via the network to execute the vehicle function, if the request data <NUM> indicate the request to execute the vehicle function at the vehicle. For example, the circuitry of the apparatus <NUM> may send one or more control command to the vehicle via the network for controlling the vehicle to execute the vehicle function.

In case the apparatus <NUM> is part of the vehicle, the circuitry of the apparatus <NUM> may be configured to request the dynamic status information from further vehicle circuitry (e.g. a controller or a sensor of the vehicle) communicatively coupled to the apparatus, if the request data indicate the request to provide the dynamic status information. Analogously to what is described above, the circuitry of the apparatus <NUM> may further be configured to forward the dynamic status information upon receipt from the further vehicle circuitry to a sender of the request data <NUM> (e.g. by sending response data indicating the requested dynamic status information to the sender of the request data). The sender of the request data <NUM> may, e.g., be the UE <NUM>, or an intermediate device coupled between the apparatus <NUM> and the UE <NUM> such that the UE <NUM> receives the dynamic status information either directly from the apparatus <NUM>, or from the intermediate device. Similarly, the circuitry of the apparatus <NUM> may be configured to control one or more controller of the vehicle, which is communicatively coupled to the apparatus, to execute the vehicle function, if the request data indicate the request to execute the vehicle function at the vehicle. For example, the circuitry of the apparatus <NUM> may send one or more control command to the controller via an internal data network of the vehicle (e.g. a bus system such as a Controller Area Network, CAN, bus) for controlling the vehicle to execute the vehicle function.

In case the circuitry of the apparatus <NUM> forwards the dynamic status information to the sender of the request data <NUM>, the circuitry of the apparatus <NUM> may be configured to forward the dynamic status information to the sender of the request data together with an identifier of the vehicle. The identifier of the vehicle is one or more word, letter, number and/or symbol that identifies (i.e. labels the identity) the vehicle. The identifier may in some examples be a unique identifier, i.e., a unifier that refers to only one particular vehicle. For example, the identifier of the vehicle may be mappable to a Vehicle Identification Number (VIN) of the vehicle. Forwarding the dynamic status information together with the identifier of the vehicle may allow to simplify processing of the dynamic status information for the recipient of the dynamic status information.

Accordingly, the wireless communication circuitry <NUM> may in some examples be configured to receive, in response to transmitting the request data <NUM>, response data <NUM> indicating the requested dynamic status information. The processing circuitry <NUM> may accordingly be configured to process the response data <NUM>. For example, the processing circuitry <NUM> may be configured to control the display <NUM> of the UE <NUM> to display a graphical representation of the dynamic status information or at least pieces of the dynamic status information. Exemplary graphical representations of the dynamic status information are described below with reference to <FIG>.

As described above, the apparatus <NUM> may be employed at various locations. Some exemplary data flows, in which the apparatus <NUM> is employed at various locations, are described below with reference to <FIG>.

<FIG> illustrates a first exemplary data flow <NUM>. A digital vehicle key <NUM> of the vehicle <NUM> is initially created and transferred (with its secure elements) to a UE <NUM> as indicated by arrow <NUM>. The creation and the transfer of the digital vehicle key <NUM> is done according to conventional techniques. The UE <NUM> is configured as described above with reference to <FIG> and stores the digital vehicle key <NUM> in a data storage.

An application running on the UE <NUM> requests dynamic status information about the vehicle <NUM> (e.g. geolocation, range or state of charge) and/or execution of a vehicle function at the vehicle <NUM> (e.g. locking or unlocking of the vehicle). Alternatively, the request for the dynamic status information or the execution of the vehicle function may be triggered by a user input at the UE <NUM>. The UE <NUM> generates according request data indicating the request to provide dynamic status information about the vehicle <NUM> and/or to execute a vehicle function at the vehicle <NUM>. The request data further indicate an identifier of the digital vehicle key <NUM> and/or a token derived from the digital vehicle key <NUM>. The request data are sent to a server <NUM> by the UE <NUM> as indicated by arrow <NUM>. The server <NUM> is a third-party server such as a server operated by/for a manufacturer of the UE <NUM>, a manufacturer of an operating system running on the UE <NUM> or any other service provider such as a vehicle rental company.

The server <NUM> forwards the request data to another server <NUM>. The server <NUM> is a server operated by/for a manufacturer of the vehicle <NUM>. The server <NUM> is configured as above with reference to <FIG> for the apparatus <NUM>. That is, the server <NUM> determines, based on the identifier of the digital vehicle key and/or the token, whether the request is in compliance with vehicle access and/or control rights assigned to the digital vehicle key. As described above, the identifier of the digital vehicle key and/or the token may comprise information about the vehicle access and/or control rights assigned to the digital vehicle key. Alternatively, the server <NUM> may retrieve the information about the vehicle access and/or control rights assigned to the digital vehicle key from rights management circuitry (e.g. implemented in the server <NUM> or provided by another server operated by/for the manufacturer of the vehicle <NUM>) based on the identifier of the digital vehicle key and/or the token.

In case the server <NUM> determines that the request is not in compliance with the vehicle access and/or control rights assigned to the digital vehicle key, the server <NUM> discards the request. If it is determined by the server <NUM> that the request is in compliance with the vehicle access and/or control rights assigned to the digital vehicle key, the server <NUM> processes the request.

For example, if the request data indicate the request to execute the vehicle function at the vehicle <NUM>, the server controls the vehicle via a network to execute the vehicle function (e.g. by sending corresponding control data) as indicated by arrow <NUM>. The vehicle <NUM> accordingly executes the requested vehicle function.

If the request data indicate the request to provide the dynamic status information, the server <NUM> requests the dynamic status information from the vehicle as indicated by arrow <NUM>. The vehicle <NUM> gathers the requested dynamic status information and sends it to the server <NUM> as indicated by arrow <NUM>. According to examples, the vehicle <NUM> may provide the dynamic status information together with an identifier of the vehicle <NUM>. For example, the identifier of the vehicle <NUM> may be mappable to a VIN of the vehicle <NUM>.

The server <NUM> forwards the dynamic status information upon receipt from the vehicle <NUM> to the server <NUM> as indicated by the arrow <NUM>. According to examples, the server <NUM> may forward the dynamic status information together with the identifier of the vehicle.

The server <NUM> forwards the dynamic status information upon receipt from the server <NUM> to the UE <NUM> as indicated by arrow <NUM> such that the UE <NUM> is able to process the dynamic status information. For example, the UE <NUM> may display a graphical representation of the dynamic status information or at least pieces of the dynamic status information. Exemplary graphical representations of the dynamic status information are described below with reference to <FIG>.

<FIG> illustrates a second exemplary data flow <NUM>. The data flow <NUM> is identical to the above described data flow <NUM> except that the third-party server <NUM> is omitted. In other words, the UE <NUM> directly communicates with the server <NUM> in the example of <FIG>. Accordingly, the UE <NUM> sends the request data to the server <NUM> operated by/for a manufacturer of the vehicle <NUM> as indicated by arrow <NUM>. The server <NUM> performs the above described processing of the request data.

As the server <NUM> is omitted in the example of <FIG>, the server <NUM> forwards the dynamic status information upon receipt from the vehicle <NUM> to the UE <NUM> as indicated by the arrow <NUM>. Analogously to what is described above, the server <NUM> may forward the dynamic status information together with the identifier of the vehicle.

<FIG> illustrates a third exemplary data flow <NUM>. In contrast to the examples of <FIG> and <FIG>, the vehicle <NUM> and the UE <NUM> communicate directly with each other in the example <FIG> (e.g. via a cellular network or a local wireless network). Analogously to what is described above, a digital vehicle key <NUM> of the vehicle <NUM> is initially created and transferred (with its secure elements) to the UE <NUM> as indicated by arrow <NUM>. The UE <NUM> is configured as described above with reference to <FIG> and stores the digital vehicle key <NUM> in a data storage.

In the example of <FIG>, the UE <NUM> sends the request data to the vehicle <NUM>. The vehicle <NUM> is configured as described above with reference to <FIG> for the apparatus <NUM>. In other words, the vehicle <NUM> comprises the apparatus <NUM> described above with reference to <FIG>.

Accordingly, if the apparatus/vehicle <NUM> determines that the request is not in compliance with the vehicle access and/or control rights assigned to the digital vehicle key, the apparatus/vehicle <NUM> discards the request. On the other hand, if the apparatus/vehicle <NUM> determines that the request is in compliance with the vehicle access and/or control rights assigned to the digital vehicle key, the apparatus/vehicle <NUM> processes the request.

For example, if the request data indicate the request to execute the vehicle function at the vehicle, the apparatus/vehicle <NUM> controls one or more controller of the vehicle <NUM> to execute the requested vehicle function.

If the request data indicate the request to provide the dynamic status information, apparatus/vehicle <NUM> requests the dynamic status information from further vehicle circuitry of the vehicle <NUM> and forward the dynamic status information upon receipt to the UE <NUM> as indicated by arrow <NUM>.

The UE <NUM> is able to process the dynamic status information. For example, the UE <NUM> may display a graphical representation of the dynamic status information or at least pieces of the dynamic status information similarly to what is described below with reference to <FIG>.

<FIG> illustrates a first exemplary graphical representation of dynamic status information. In the example of <FIG>, the display <NUM> of the UE <NUM> is controlled to display three pieces of received dynamic status information in a digital wallet application of a user. The digital wallet is used to store the digital vehicle key in the data storage of the UE <NUM>. The digital vehicle key is visualized by a corresponding card-like graphical element <NUM> in the graphical representation. A first graphical icon <NUM> in the graphical representation displays the lock status of the vehicle (i.e. whether the vehicle is locked or unlocked). A second graphical icon <NUM> in the graphical representation displays the geolocation of the vehicle. A third graphical icon <NUM> in the graphical representation displays the range of the vehicle and the state of charge of the vehicle's electric battery. By pressing the touch-sensitive display <NUM> at the display position of the first graphical icon <NUM>, the user may provide a user input that causes generation and transmission of request data for requesting execution of a locking/unlocking function at the vehicle according to the above described principles.

<FIG> illustrates a second exemplary graphical representation of dynamic status information. In the example of <FIG>, the display <NUM> of the UE <NUM> is controlled to display the geolocation of the vehicle as an exemplary piece of received dynamic status information in a web mapping application. A first graphical icon <NUM> in the graphical representation displays the geolocation of the vehicle in textual form. A second graphical icon <NUM> in the graphical representation displays the geolocation of the vehicle in a map.

For further illustrating the proposed digital vehicle key utilization, <FIG> illustrates a flowchart of a method <NUM>. The method <NUM> comprises receiving <NUM> request data. The request data indicate a request to provide dynamic status information about a vehicle and/or to execute a vehicle function at the vehicle. Further, the request data indicate an identifier of a digital vehicle key for the vehicle and/or a token derived from the digital vehicle key. The method <NUM> additionally comprises determining <NUM>, based on the identifier of the digital vehicle key and/or the token, whether the request is in compliance with vehicle access and/or control rights assigned to the digital vehicle key. If it is determined that the request is in compliance with the vehicle access and/or control rights assigned to the digital vehicle key, the method <NUM> comprises processing <NUM> the request. On the other hand, if it is determined that the request is not in compliance with the vehicle access and/or control rights assigned to the digital vehicle key, the method <NUM> comprises discarding <NUM> the request.

The method <NUM> may allow to use the digital vehicle key as identifier for accessing dynamic status information about the vehicle and/or executing a vehicle function at the vehicle. No other (e.g. third-party) identifiers are needed.

Claim 1:
A server (<NUM>) communicatively coupled to a vehicle via a network, the server (<NUM>) comprising circuitry configured to:
receive request data (<NUM>), the request data (<NUM>) indicating a request to provide dynamic status information about a vehicle and/or to execute a vehicle function at the vehicle, the request data (<NUM>) further indicating an identifier of a digital vehicle key for the vehicle;
determine, based on the identifier of the digital vehicle key, whether the request is in compliance with vehicle access and/or control rights assigned to the digital vehicle key; and
process the request, if it is determined that the request is in compliance with the vehicle access and/or control rights assigned to the digital vehicle key, wherein, for processing the request, the circuitry is configured to:
request the dynamic status information from the vehicle via the network and forward the dynamic status information upon receipt from the vehicle to a sender of the request data (<NUM>), if the request data (<NUM>) indicate the request to provide the dynamic status information; and
control the vehicle via the network to execute the vehicle function, if the request data (<NUM>) indicate the request to execute the vehicle function at the vehicle.