Description

The present disclosure relates to a computer program, an apparatus, a user device, a vehicle, a server, and methods for controlling a vehicle. In particular, but not exclusively, embodiments relate to a concept for locking and unlocking a vehicle using a user device.

In view of the development in the field of mobility, concepts of locking/unlocking vehicles using a handheld user device play an increasingly important role. In car sharing or car rental services, e.g., “physical vehicle keys” and personal key fobs may be impractical. So, it may be desired to enable users to access vehicles only using their handheld user device and without using a physical vehicle key.

However, concepts of locking/unlocking vehicles using user devices may bear security risks. In existing concepts, there is a particular risk that users or unauthorized third parties/persons lock and/or unlock a vehicle from afar, i.e., from a greater distance than intended.

Hence, there may be a demand for an improved concept for controlling a vehicle.

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

Embodiments are based on the finding that for controlling a vehicle using a user device, it may be desired that the user device and a respective user is within a certain distance to the vehicle. So, a basic idea of the present disclosure is to use communication technology with a limited range, in particular, with distance dependent signal strength to check or make sure that a user (device) requesting for an action of the vehicle, e.g., locking or unlocking the vehicle, is within the certain distance to the vehicle in order to prevent danger from actions triggered from farther away. Accordingly, the proposed concept provides that a user device and a vehicle at least partly communicate via communication technology having a limited range. Examples of such technology comprise Bluetooth low energy (BLE), ultrawide -band (UWB), and wireless local area network (WLAN) communication technology. In favor of a technically simple implementation, in embodiments, the user device communicates with the vehicle through one or more beacons which may be universally compatible with multiple car/vehicle manufacturers and/or vehicle rental services. For authorization purposes, the beacons may be indicative of a token that the vehicle can use to authenticate the user device. Optionally, it is also determined by a signal strength of the beacons if a distance between the vehicle and the user device is equal to or less than a predefined maximum distance.

Embodiments provide a method for a user device and for controlling a vehicle. The method comprises transmitting, to a server, a request for an action of the vehicle and for triggering the server to provide a token to the user device and receiving the token from the server. Also, the method comprises emitting a beacon indicative of the token to the vehicle using communication technology for direct communication in a limited range. In this way, it can be determined whether the user device (and, thus, a respective user of the user device) is within the range of the used communication technology. So, the method provides a presence check for a higher security. In particular, the proposed concept may prevent danger from the vehicle as well as unwanted interference or attacks by third parties farther away. In practice, an appropriate communication technology having a range greater than or equal to a maximum desired distance can be selected. Further, the method allows the vehicle to authenticate the user device based on the token. For this, the server may provide to the vehicle the same token for comparison with the beacon via a separate channel for a safe two-way token authentication.

Optionally, emitting the beacon comprises emitting the beacon with a predefined output signal strength. In this way, the vehicle is able to reliably determine a distance of the user device to the vehicle based on a signal strength of the received beacon. In particular, this allows to check whether the user device is within a predefined maximum distance. To this end, the signal strength of the received beacon, e.g., is compared to a predefined level of the signal strength which is such that the signal strength is greater than or equal to the predefined level if the vehicle is within the predefined maximum range.

In some embodiments, the communication technology comprises at least one of Bluetooth low energy (BLE), Ultra-wideband (UWB), and technology for communication via a wireless local area network (WLAN).

Further embodiments provide a method for a vehicle and for controlling the vehicle. The method comprises obtaining a token from an external server and receiving an instruction to perform an action of the vehicle. Further, the method comprises checking, if the vehicle receives a beacon indicative of the token using a communication technology for direct communication with a user device in a limited range. Moreover, the method comprises performing the action if the vehicle receives the beacon indicative of the token using the communication technology. Analogously to the method for the user device, the limited range of the used communication technology allows the vehicle to determine whether the user device is at least within the range of the communication technology. In particular, the method allows the vehicle to make sure that the user device is within a distance to the vehicle that is smaller or equal to the range of the communication technology and to only perform the requested action if the user device is within this distance. So, the method provides a higher security, e.g., against danger from actions of a vehicle and unwanted interference or attacks by third parties outside of the range.

In some embodiments, the method further comprises comparing a signal strength of the received beacon with at least one predefined level for the signal strength to check whether the signal strength is greater than or equal to the predefined level. As well, performing the action may comprise performing the action if the signal strength of the received beacon is greater than or equal to the predefined level. In doing so, the predefined level can be such that the signal strength needs to be higher than a minimum signal strength required for communication. In this way, a distance of the user device to the vehicle for triggering the action may be arbitrarily defined. So, in other words, the predefined level for the signal strength allows to precisely define an arbitrary desired distance for the user device to trigger the requested action. In particular, this allows the maximum distance of the user device to be smaller than the range of the used communication technology. The smaller range may make attacks of unauthorized parties or persons even more difficult since an attacker would need to be closer than the range and, thus, provides an even higher security.

Optionally, the predefined level for the signal strength is such that the signal strength is greater than or equal to the level for the signal strength if the user device is closer to the vehicle than a predefined maximum distance. This allows to set a certain distance (the maximum distance), in which the user device needs to be in order to trigger the action of the vehicle.

In some embodiments, multiple levels for different maximum distances may be defined, e.g., in order to check the presence of the user device in different ranges/distances, as laid out in more detail later.

In practice, e.g., in car sharing or car rental services, the action may comprise at least one of locking/unlocking the vehicle, allowing to start an engine of the vehicle, and starting the engine. This may prevent unauthorized third parties or persons from gaining access to the vehicle and/or using the vehicle.

Optionally, the predefined maximum distance depends on the action. In practice, e.g., different maximum distances may be defined for different actions. In this way, e.g., the maximum distance can be adapted to a kind of action. In embodiments, e.g., for actions typically triggered from smaller distances the maximum distance may be smaller than for other actions. In practice, e.g., the user is typically in the vehicle when he or she starts a motor of the vehicle and, thus, closer to the vehicle than when the user unlocks the vehicle while approaching the vehicle. Accordingly, the maximum distance for starting the motor may be set smaller than the maximum distance for unlocking the vehicle. So, in this way, particular peculiarities of different actions, especially different typical distances between the user device and the vehicle for certain actions, can be considered.

Other embodiments provide a method for a server and for controlling a vehicle. The method comprises receiving a request for triggering an action of the vehicle from a user device, obtaining a token, and transmitting the token to the user device for configuring the user device to transmit, using communication technology for direct communication between the user device and the vehicle in a limited range, a beacon indicative of the token. To this end, the token can be configured such that it can be transmitted via the beacon, e.g., a size of the token can be adapted to a maximum size that can be transmitted via the beacon. As well, the method comprises transmitting the token to the vehicle for configuring the vehicle to check whether the beacon is indicative of the (same) token and perform the action if the beacon is indicative of the token. So, the method for the server analogously to the complementary methods for the user device and the vehicle allows to determine whether the user device is within a distance to the vehicle that is equal to the range of the used communication technology and/or within a predefined maximum distance, as described above and, thus, may prevent danger from the vehicle as well as unwanted interference or attacks by third parties farther away.

Optionally, the method further comprises transmitting an instruction indicative of the requested action from the server to the vehicle. In this way, it is possible to refrain from the user device sending the instruction, which allows saving resources of the user device, e.g., computing power, as laid out in more detail later.

Other embodiments provide a computer program (product) having a program code for performing at least one of the methods of the preceding claims, when the computer program is executed on a computer, a processor, or a programmable hardware component.

Still other embodiments provide an apparatus comprising one or more interfaces for communication and a data processing circuit configured to control the one or more interfaces and execute, using the one or more interfaces, one of the methods proposed herein. Further embodiments provide a user device, vehicle, or server comprising the apparatus proposed herein.

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

Fig. 1 shows a flow chart schematically illustrating an embodiment of a method for a user device and for controlling a vehicle;

Fig. 2 shows a flow chart schematically illustrating an embodiment of a method for a vehicle and for controlling the vehicle;

Fig. 3 shows a flow chart schematically illustrating an embodiment of a method for a server and for controlling the vehicle;

Fig. 4 schematically illustrates a use case of the proposed concept; and

Fig. 5 shows a block diagram schematically illustrating an apparatus according to the proposed concept.

Various example embodiments will now be described more fully with reference to the accompanying drawings in which some example embodiments are illustrated. In the figures, the thicknesses of lines, layers or regions may be exaggerated for clarity. Optional components may be illustrated using broken, dashed, or dotted lines.

Accordingly, while example embodiments are capable of various modifications and alternative forms, embodiments thereof are shown by way of example in the figures and will herein be described in detail. It should be understood, however, that there is no intent to limit example embodiments to the particular forms disclosed, but on the contrary, example embodiments are to cover all modifications, equivalents, and alternatives falling within the scope of the invention. Like numbers refer to like or similar elements throughout the description of the figures.

As used herein, the term "or" refers to a non-exclusive or, unless otherwise indicated (e.g., “or else” or “or in the alternative”). Furthermore, as used herein, words used to describe a relationship between elements should be broadly construed to include a direct relationship or the presence of intervening elements unless otherwise indicated. For example, when an element is referred to as being “connected” or “coupled” to another element, the element may be directly connected or coupled to the other element or intervening elements may be present. In contrast, when an element is referred to as being “directly connected” or “directly coupled” to another element, there are no intervening elements present. Similarly, words such as “between”, “adjacent”, and the like should be interpreted in a like fashion.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises”, “comprising”, “includes”, or “including”, when used herein, specify the presence of stated features, integers, steps, operations, elements or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups thereof.

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which example embodiments belong. It will be further understood that terms, e.g., those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

Existing concepts of locking/unlocking vehicles using (only) a user device provide for two-way authentication of a user device to a vehicle through a first bidirectional Bluetooth communication session and a second communication session with a backend connected to the vehicle. However, such concepts have several disadvantages.

For security reasons, the communication session utilizes a secure link established by a predefined pairing mechanism. Such a pairing mechanism requires that a specific software development kit (SDK) of a respective service provider (car manufacturer, car rental service, and/or car sharing service) and/or a respective hardware (particularly interface system) is embedded in a corresponding software for communication with the vehicle on the user device for compatibility of the software with the vehicle of a respective car manufacturer and service provider, respectively. In practice, this makes it technically difficult to develop or provide software which is compatible with various service providers and/or hardware because various SDKs had to be embedded for each of the service providers and/or hardware components, e.g., in so-called “carsharing aggregator applications” which are computer programs that allow a user to rent or book vehicles from different providers. Another disadvantage is that the aforementioned concept is vulnerable to interferences or attacks, e.g., to Bluetooth Impersonation Attacks (BIAS) or man-in-the -middle (MITM) attacks.

Hence, it can be seen as an objective of the concept proposed herein to tackle the above disadvantages.

Fig. 1 shows a flow chart schematically illustrating an embodiment of a method 100 for a user device and for controlling a vehicle. In embodiments, method 100 is executed by the user device.

Method 100 comprises transmitting 110, to a (external) server, a request for an action of the vehicle and for triggering the server to provide a token to the user device. To this end, the user device may communicate with the server via the Internet and may access the Internet via a (wireless) local area network or a cellular network. The request, e.g., includes an inquiry to instruct the vehicle perform a certain action, e.g., to unlock a vehicle, i.e., a door of the vehicle. In practice, the request may also include any personal data, credentials, and/or any user input of a user in order that the request and the respective action can be assigned to the user or his/her user device.

In embodiments, the user device can be any handheld device (e.g., a mobile phone, tablet, notebook, smartwatch, or the like), any stationary terminal device (e.g., a personal computer), or any other programmable hardware device for communication with the server and the vehicle. The server can be understood as any server separate from the vehicle and the user device. In embodiments, the server can be a service backend, e.g., of a car manufacturer (of the vehicle), a car rental service, and/or a carsharing service, or any other server for communication with the user device and the vehicle.

The server may generate the token in response to the request. Optionally, the server creates the token based on personal data or user credentials and/or based on information on the requested action in order that the token can only be used by the (authorized) user/user device and/or specifically for the requested action, e.g., only for unlocking the vehicle (once). In practice, the server may then transmit the token to the user device, e.g., via the Internet.

Accordingly, method 100 further comprises receiving 120 the token from the server, as mentioned, e.g., via the Internet.

In practice, the token can be any data or data structure for authentication of the user or user device. For security reasons, the token may be encrypted for transmission to the user device. The skilled person will appreciate that, for this purpose, several encryption mechanisms/schemes may be used. The user device may then use the token for authentication to the vehicle and proving the presence of the user device within a desired distance to the vehicle.

To this end, method 100 provides for emitting 130 a beacon indicative of the token to the vehicle using communication technology for direct communication in a limited range.

The beacon can be understood as an “unaddressed” signal or data packet, in the sense of a signal or data packet that is not specifically directed to and/or encrypted for a certain recipient. In embodiments, the beacon is emitted without, i.e., “outside” of, any (previously established) connection following a predefined bilateral communication or encryption protocol, e.g., a Bluetooth or WLAN connection of paired entities. Accordingly, the beacon may be universally compatible with various interfaces (e.g., of various vehicle manufacturers and/or vehicle rental services) of a respective communication technology used for emitting the beacon and may not require additional information on interfaces such as SDKs for its generation. For the beacon to be indicative of the token, the token can be included in a payload of the beacon.

The range, e.g., is limited, e.g., by the fact that the beacon only has a certain limited range, i.e., that the beacon can is only “readable” up to a certain maximum distance to the user device. The range, thus, may correspond to the distance up to which the beacon can be utilized (i.e., analyzed or read) by the vehicle.

In practice, on the one hand, the use of the beacon for the authentication may reduce a technical complexity, e.g., in carsharing aggregator applications which, in practice, need to bring together various car manufacturers and/or service providers using different interfaces, software, and/or hardware. In particular, the use of beacons, thus, make the use of multiple SDKs in such aggregator applications superfluous and, so, the aggregator applications technically less complex and more resource-saving than in existing concepts as no SDKs have to be embedded and processed in the aggregator application.

On the other hand, the limited range of the used communication technology enables the vehicle to check the presence of a user or user device within a distance to the vehicle equal to the range of the used communication technology. For BLE, UWB, and WLAN technology or other technologies for direct communication with the vehicle, the range is smaller than for indirect communication technologies, e.g., using cellular networks. For BLE, UWB, and WLAN, the range is a few meters or a few tens of meters. So, as the skilled person having benefit from the present disclosure will appreciate, compared to indirect communication with the vehicle, the communication technology for direct communication with the vehicle allows to determine a position and/or a presence of the user device or the user more accurately than, e.g., cellular networks. The skilled person will appreciate that the used technology may be optionally adapted to other preferred ranges. To this end, e.g., the output signal strength and/or the receiver sensitivity are/is adapted.

The presence check, e.g., allows to determine whether the user is close enough for certain actions of the vehicle in order to avoid danger from the vehicle, e.g., when moving the vehicle from remote using the user device (“remote parking”) or starting the engine of the vehicle, or any other risks, e.g., that an unauthorized person gains access to the vehicle when the vehicle is or can be unlocked from too far way.

In some embodiments, the beacon may be emitted regularly, e.g., every X seconds, such that the action is performed as soon as the user device gets within a distance to the vehicle equal to the range for direct communication or a desired distance.

In embodiments, the beacon is emitted with a predefined output signal strength. The output signal strength can be understood as the transmission power of the user device or the beacon at the output, e.g., the antenna of the user device. On the one hand, the predefined output signal strength may ensure that that the beacon is only received if the vehicle is in range of the user device and, thus, allows the vehicle to determine more reliably whether the user device is within a certain distance to the vehicle than for an indefinite output signal strength of the beacon. On the other hand, the predefined output signal strength may enable the vehicle to determine a concrete/specific distance of the user device by a signal strength of the beacon at the vehicle and based on a model for the pathdependent decrease in signal strength of the beacon.

In practice, the communication technology may comprise BLE, UWB, or technology for communication via a WLAN, “WLAN technology”. Accordingly, the user device and the vehicle may be equipped with appropriate BLE, UWB, and/or WLAN transmitter/s and receivers, respectively. In practice, the user device and/or the vehicle may be equipped with transceivers of a respective communication technology. However, the proposed unidirectional communication through the beacon does not require that the vehicle and the user device each are equipped with both receiving and transmitting means.

In real use cases, the proposed concept, e.g., is applied in carsharing service or car rental services, e.g., for locking or unlocking vehicles by a user only using his or her user device. To this end, a server, e.g., a respective carsharing, car manufacturer, or car rental backend, may instruct or configure the vehicle to check whether a beacon indicative of the token is received and, if so, lock or unlock, respectively, one or more doors of the vehicle, as laid out in more detail later. In doing so, the proposed concept provides that the user can only lock or unlock the vehicle if the user device has the (appropriate/respective) token and, if the vehicle is in range for communication via the communication technology with limited range. Thus, the concept prevents that the user can instruct the vehicle to perform actions if the distance between the user device and the vehicle is larger than the range of the used communication technology, e.g., to prevent that the user can unlock the vehicle from afar (unintentionally) for an unauthorized third person or that the user can move the car from afar, i.e., if the distance between the user device and the vehicle is larger than the range of the used communication technology.

Although the proposed concept may be described with reference to use cases for locking or unlocking vehicles of carsharing and car rental services, the skilled person will understand that the proposed concept may be also applied to private/personal vehicles and or other actions of the vehicle, e.g., for activating theft protection, setting a parking heater, and/or the like.

As the skilled person will also understand, method 100, in practice, may be executed in connection with interrelated complementary methods for a vehicle and a server, as laid out in more detail below with reference to Fig. 2 and 3.

Fig. 2 shows a flow chart schematically illustrating an embodiment of a method 200 for a vehicle and for controlling the vehicle. In embodiments, method 200 is executed by the vehicle.

In accordance with method 100, method 200 comprises obtaining 210 the token from the external server and receiving 220 an instruction to perform an action of the vehicle. As mentioned above, the action, e.g., comprises locking the vehicle, unlocking the vehicle, allowing to start an engine of the vehicle, starting the engine, activating theft protection, setting or adjusting a parking heater, and/or the like.

In embodiments, the vehicle may receive the instruction from the external server, e.g., together (i.e., in the same data packet) with the token. To this end, the vehicle may be communicatively coupled with the external server, e.g., via the Internet using WLAN or a cellular network. In practice, the token, e.g., is associated with the action and/or the user such that the vehicle is able to identify the user and perform the right/desired action, namely the one associated with the token, in response to receiving the same token from the user device (later).

In other embodiments, the vehicle may alternatively or additionally receive the instruction from the user device. However, it may be preferred that not the user device but the external server provides the instruction to the vehicle in order that the communication between the user device and the vehicle is less resource-intensive, in particular that, in applications where the instruction is not suitable for transmission via the beacon, no additional (resource-intensive) connection between the user device and the vehicle, e.g., a Bluetooth connection, is required.

Further, method 200 comprises checking 230 whether a beacon is received from a user device using a communication technology for direct communication with the user device in a limited range. In doing so, the vehicle may check whether an evaluable or analyzable (i.e., “readable”) signal of a beacon is received, i.e., a signal of a beacon exhibiting a sufficient signal strength for readout. Thus, signals or beacons from a distance to the vehicle that is larger than the range of the used communication technology are ignored.

Further, method 200 comprises checking 230, if the vehicle receives a beacon indicative of the token using a communication technology for direct communication with a user device in a limited range and, if so, performing 240 the action.

Analogously to method 100, method 200, in this way, provides that the action is only performed if the vehicle is (at least) within the range of the used communication technology in order to avoid security risks through actions of the vehicle while the user is farther away or through attacks by unauthorized third parties farther away from the vehicle.

For some applications, a desired maximum distance between the user device and the vehicle may be smaller than the range of the used communication technology. For this case, method 200 may provide for comparing a signal strength of the received beacon with at least one predefined level for the signal strength to check whether the signal strength is greater than or equal to the predefined level and performing the action comprises performing the action (only) if the signal strength of the received beacon is greater than or equal to the predefined level. In doing so, the predefined level can be such that the signal level of the beacon is only greater than or equal to the predefined level, if the user device is within a distance (i.e., at the distance or closer) smaller than the range of the used communication technology.

In some applications, it may be also desired that the user can only trigger the action if he or she is within a certain predefined maximum distance. For this case, the predefined level for the signal strength is such that the signal strength is greater than or equal to the level for the signal strength if the user device is closer to the vehicle than a predefined maximum distance. To this end, the predefined level for the signal strength can be set based on a model for the path-dependent decrease in signal strength of the beacon such that, provided that the output signal strength of the beacon is invariant, the user device is within the maximum distance to the vehicle if the signal strength of the received signal is greater than or equal to the predefined level for the signal strength. This allows to set a certain distance for the user to trigger the action. In applications, e.g., it is desired that the user can only unlock the vehicle if he or she is two or six meters away from the vehicle or closer.

In some applications, it may be desired that different actions have different predefined maximum distances, e.g., such that the user device needs to be closer to the vehicle for starting the engine of the vehicle than for unlocking the vehicle. To this end, the predefined maximum distance may depend on the action, e.g., the kind of action. In embodiments, the predefined maximum distance for starting the engine may correspond to two meters and the maximum distance for unlocking the vehicle may correspond to six meters. In this way, the predefined maximum distance may be adapted to various peculiarities and/or regulations regarding different actions. In practice, e.g., starting the engine may be dangerous as long as the user is not in or right next to the vehicle (e.g., closer than two meters to the vehicle) while it may be innocuous that the user unlocks the vehicle from a greater distance (e.g., from six meters). Accordingly, the predefined maximum distance for starting the engine may correspond to two meters and the predefined maximum distance for unlocking the vehicle may correspond to six meters.

Fig. 3 shows a flow chart schematically illustrating an embodiment of a method 300 for a server and for controlling the vehicle. In embodiments, method 300 is executed by the server.

As can be seen from the flow chart of Fig. 3, the method 300 comprises receiving 310 a request for triggering an action of the vehicle from a user device. As mentioned above, the request, e.g., is communicated via the Internet.

Method 300 also comprises obtaining 320 a token. To this end, the server may run an appropriate algorithm for generating the token. In doing so, the server may take care that the generated token is suitable for transmission via the beacon, e.g., that a data size of the generated token is small enough for transmission via the beacon. In order to enable the vehicle to determine the action to be performed (only) based on the token received via the beacon from the user device, the server can associate the token with the action. To this end, the token, e.g., can be such that it is indicative of the action or the token may be added to the same data packet which includes the instruction of the respective action.

In practice, the server may also encrypt the token such that only the vehicle is able to decrypt the token In line with method 100 and 200, method 300 also includes transmitting 330 the token to the user device for configuring the user device to transmit, using communication technology for direct communication between the user device and the vehicle in a limited range, a beacon indicative of the token and transmitting 340 the token to the vehicle for configuring the vehicle to check whether the beacon is indicative of the token and perform the action if the beacon is indicative of the token.

As well, as mentioned above, the server may transmit an instruction indicative of the requested action from the server to the vehicle.

The proposed concept, in particular the methods 100, 200, and 300 and their interaction, will be explained in more detail below with reference an exemplary use case schematically illustrated by Fig. 4.

As can be seen from Fig. 4, in the exemplary use case, a user device 410 (here, e.g., a smartphone) requests to unlock a vehicle 420. To this end, the user device 410 in a first step 1 sends a request for an action of the vehicle 420 to a server 430, here referred to as “ODM (original design manufacturer) backend”. In the present use case, the action, e.g., comprises unlocking the vehicle 420.

The server 430 then, in another step 2, generates a cryptographical (i.e., encrypted) token in response to the request and sends the cryptographical token to the user device 410 in a further step 3.

Similarly, the server 430 sends the cryptographical token and information on the requested action (also understood as instruction to perform the action) in yet another step to an interface for communication with the ODM backend, here a Wireless Access in Vehicular Environments (“WAVE”) interface of the vehicle 420 (see solid arrow numbered “4”), in order that the vehicle is configured to detect beacons being indicative or bearing the same token.

The user device 410 emits a beacon with the cryptographical token in a payload of the beacon (see dashed arrow numbered “4”). In the present use case, the user device 410, e.g., emits the beacon by using BLE. Accordingly, the beacon may be also referred to as “BLE beacon”.

The vehicle 420 is equipped with an interface which is configured to receive the beacon. In order to receive the BLE beacon, the vehicle 420, e.g., is equipped with a BLE interface, herein implemented in a UWB+BLE CAN (controller area network) gateway with FCC (Federal Communications Commission) ID “FBD5”, also referred to as FBD5 gateway. Further, the BLE interface may determine a signal strength of the received beacon. The WAVE forwards the token received from the ODM backend to a data processing circuit of the vehicle 420, herein referred to as “BCP-AP” (see left/upper arrow numbered “5”). As well, if the BLE interface receives a BLE beacon, it forwards information on a token and a signal strength of the received beacon to the data processing circuit (see right/lower arrow numbered “5”).

The data processing circuit, then, can check in a further step (see number “6”) the presence and the authorization of a user device transmitting the received beacon and trigger the requested action based on the presence check and the authorization. In doing so, the data processing circuit may compare the token received from the ODM backend with the token received from the user device, e.g., user device 410 and consider the user device authorized if the tokens match.

If only the presence of the user device within the range of the used communication technology is required or desired, the presence may be proven by the mere fact that the vehicle was able to receive and evaluate the BLE beacon.

If it is desired to check the presence within a certain range smaller than the range of the communication technology, the data processing circuit also compares the signal strength of the received beacon with a level indicative of the desired range, i.e., indicative of a signal strength of signals with a predefined (and invariant) output signal strength received from a distance equal to the desired range. In this case, the data processing circuit may only trigger the action if the tokens match and the signal strength is greater than or equal to said level indicative of the desired range, i.e., if the user device is authorized and present within the desired range. The skilled person will understand that the predefined level for the signal strength may particularly depend on the output signal strength, the receiver sensitivity, and environmental circumstances (e.g., perturbation, reflection, and/or absorption of the beacon in the environment) and, thus, may be adapted to various applications exhibiting different output signal strengths and/or receiver sensitivities. The predefined/predetermined level, e.g., is determined from previous real-world test trials and/or simulations. The output signal strength, e.g., is predefined by a standard.

In practice, several different cases may occur.

In one case, the vehicle 420 is out of range of the used communication technology, here BLE, and, thus, may not be able to receive the BLE beacon from the user device, be it authorized or not. So, in this case, there is no information on any beacon to compare with the token from the ODM backend. Consequently, the data processing circuit will not trigger the vehicle 420 to carry out the action, here to unlock the vehicle 420. In this way, it is avoided that even authorized user devices such as user device 410 can unlock vehicle 420 from a distance greater than the range of the communication technology and, in this way, unauthorized third parties gain access without being noticed (since the authorized user may be too far away to notice if any third party accesses the vehicle).

In another case, the BLE interface receives a BLE beacon but the BLE beacon is not indicative of the token received from the ODM backend, e.g., when the BLE beacon is received from an unauthorized user device (other than user device 410) not having the token from the ODM backend. In this case, the data processing circuit will determine that the compared tokens do not match and, thus, will not cause the vehicle to unlock itself.

In a further case, the BLE beacon indicative of the token is received from user device 410. In this case, the compared tokens will match such that the user device is considered authorized. As mentioned above, the presence of the user device may be proven alone by the fact that the BLE beacon is received. In this case, the data processing circuit may cause the vehicle to unlock itself without any evaluation of the signal strength of the received beacon.

However, in some applications it may be desired that the user device 410 is not only present in the range of the used communication technology but in a smaller range. The user or the user device 410, e.g., may be required to be present within six meters distance to the vehicle 420 for unlocking because it has been determined that the user in this distance has a sufficiently good overview of the vehicle 420 to safely unlock the vehicle, e.g., to make sure that no unauthorized party or person enters the vehicle 420 when unlocking the vehicle 420. To this end, as mentioned before, the data processing circuit compares the signal strength of the received BLE beacon with the predefmed/predetermined level for the signal strength. The level may be such that the signal strength is lower than the level if the user device 410 is more than six meters away from the vehicle 420 or from the BLE interface and greater than or equal to the level if the user device 410 is six meters away from or closer to the vehicle 420 or BLE interface. In order that the vehicle is only unlocked if the user or user device 410 is not more than six meters away from the vehicle 420 or BLE interface, the data processing circuit causes the vehicle 420 to unlock itself if the signal strength of the received beacon is greater than or equal to the predetermined level indicative for the distance of six meters. To this end, the data processing circuit may be communicatively coupled with and/or configured to control a locking/unlocking system of the vehicle 420.

It is noted that the example of Fig. 4 is only one of various possible implementations of the proposed concept. The skilled person will appreciate that the proposed concept, e.g., may be also implemented using other technologies and/or in other use cases (e.g., for other actions of the vehicle). As the skilled person will understand, the proposed methods can be implemented in respective apparatuses, as stated in more detail below with reference to Fig. 5.

Fig. 5 shows a block diagram schematically illustrating an embodiment of an apparatus 500 implementing the proposed concept.

As can be seen from Fig. 5, apparatus 500 comprises one or more interfaces 510 for communication and a data processing circuit 520 configured to control the one or more interfaces 510. The data processing circuit 520 is further configured to control the one or more interfaces and execute, using the one or more interfaces, one of the proposed methods. That is, the apparatus 500 may be configured to execute method 100, 200, or 300 for a user device, for a vehicle, and a server, respectively. Accordingly, the apparatus 500 may be implemented in a user device, a server, or a vehicle, respectively.

In embodiments the one or more interfaces 510 may comprise means for communication with vehicles or another server. For this, the one or more interfaces 510 may comprise or correspond to any means for obtaining, receiving, transmitting, or providing analog or digital signals or information, e.g., any connector, contact, pin, register, input port, output port, conductor, lane, etc. which allows providing or obtaining a signal or information. An interface may be wireless or wireline and it may be configured to communicate, i.e. transmit or receive signals, information with further internal or external components. The one or more interfaces 510 may comprise further components to enable according communication, such components may include transceiver (transmitter and/or receiver) components, such as one or more Low-Noise Amplifiers (LNAs), one or more Power-Amplifiers (PAs), one or more duplexers, one or more diplexers, one or more filters or filter circuitry, one or more converters, one or more mixers, accordingly adapted radio frequency components, and/or the like. The one or more interfaces 510 may be coupled to one or more antennas, which may correspond to any transmit and/or receive antennas, such as horn antennas, dipole antennas, patch antennas, sector antennas, and/or the liked. The antennas may be arranged in a defined geometrical setting, such as a uniform array, a linear array, a circular array, a triangular array, a uniform field antenna, a field array, combinations thereof, and/or the like.

As shown in Fig. 5, the one or more interfaces 510 are coupled to the data processing circuit 520. In embodiments the data processing circuit 520 may comprise any means for processing information according to one of the proposed methods. The data processing circuit 520 may be implemented using one or more processing units, one or more processing devices, any means for processing, such as a processor, a computer or a programmable hardware component being operable with accordingly adapted software. In other words, the described functions of the data processing circuit 520 may as well be implemented in software, which is then executed on one or more programmable hardware components. Such hardware components may comprise a general -purpose processor, a Digital Signal Processor (DSP), a micro-controller, and/or the like.

A person of skill in the art would readily recognize that steps of various above-described methods can be performed by programmed computers. In some embodiments, the apparatus may also comprise program storage devices, e.g., digital data storage media, which are machine or computer readable and encode machine-executable or computer-executable programs of instructions where said instructions perform some or all of the steps of methods described herein. The program storage devices may be, e.g., digital memories, magnetic storage media such as magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media. The embodiments are also intended to cover computers programmed to perform said steps of methods described herein or (field) programmable logic arrays ((F)PLAs) or (field) programmable gate arrays ((F)PGAs), programmed to perform said steps of the above-described methods.

The description and drawings merely illustrate the principles of the invention. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the invention and are included within its spirit and scope. Furthermore, all examples recited herein are principally intended expressly to be only for pedagogical purposes to aid the reader in understanding the principles of the invention and the concepts contributed by the inventor(s) to furthering the art and are to be construed as being without limitation to such specifically recited examples and conditions. Moreover, all statements herein reciting principles, aspects, and embodiments of the invention, as well as specific examples thereof, are intended to encompass equivalents thereof.

When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term “processor” or “controller” should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, Digital Signal Processor (DSP) hardware, network processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), read only memory (ROM) for storing software, random access memory (RAM), and non-volatile storage. Other hardware, conventional or custom, may also be included. Their function may be carried out through the operation of program logic, through dedicated logic, through the interaction of program control and dedicated logic, or even manually, the particular technique being selectable by the implementer as more specifically understood from the context. It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative circuitry embodying the principles of the invention. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

Furthermore, the following claims are hereby incorporated into the detailed description, where each claim may stand on its own as a separate embodiment. While each claim may stand on its own as a separate embodiment, it is to be noted that - although a dependent claim may refer in the claims to a specific combination with one or more other claims - other embodiments may also include a combination of the dependent claim with the subject matter of each other dependent claim. Such combinations are proposed herein unless it is stated that a specific combination is not intended. Furthermore, it is intended to include also features of a claim to any other independent claim even if this claim is not directly made dependent to the independent claim.

It is further to be noted that methods disclosed in the specification or in the claims may be implemented by a device having means for performing each of the respective steps of those.

References

100 method for a user device

110 transmitting a request

120 receiving the token

130 emitting a beacon indicative of the token

200 method for a vehicle

210 obtaining a token

220 receiving and instruction

230 checking, if the vehicle receives a beacon indicative of the token

240 performing the action

300 method for an external server

310 receiving a request

320 obtaining a token

330 transmitting the token to the user device

340 transmitting the token to the vehicle

410 user device

420 vehicle

430 server/ODM backend

500 apparatus

510 one or more interfaces

520 data processing circuit