WO2021043398A1

WO2021043398A1 - Improving privacy in wireless personal area networks using customized universally unique identifier values

Info

Publication number: WO2021043398A1
Application number: PCT/EP2019/073609
Authority: WO
Inventors: Steven Arnold; Jack Murfett; Uwe HOLLATZ; Ewen Christopher
Original assignee: Robert Bosch Gmbh
Priority date: 2019-09-04
Filing date: 2019-09-04
Publication date: 2021-03-11

Abstract

Method of operating a first device, wherein said first device is configured to wirelessly transmit data to a second device, preferably using a wireless personal area network, WPAN, communications technology, wherein said method comprises: constructing a message comprising a data field suitable for receiving a universally unique identifier, UUID, providing device data in said data field, transmitting said message to said second device.

Description

IMPROVING PRIVACY IN WIRELESS PERSONAL AREA NETWORKS USING CUSTOMIZED UNIVERSALLY UNIQUE IDENTIFIER VALUES

Field of the Invention

Exemplary embodiments relate to a method of operating a first device, wherein said first device is configured to wirelessly transmit data to a second device.

Further exemplary embodiments relate to a first device, wherein said first device is configured to wirelessly transmit data to a second device.

Further exemplary embodiments relate to a method of operating a second device, wherein said second device is configured to wirelessly receive data from a first device.

Further exemplary embodiments relate to a second device, wherein said second device is configured to wirelessly receive data from a first device.

Summary

Exemplary preferred embodiments relate to a method of operating a first device, wherein said first device is configured to wirelessly transmit data to a second device, preferably using a wireless personal area network, WPAN, communications technology, wherein said method comprises: constructing a message comprising a data field suitable for receiving a universally unique identifier, UUID, providing device data in said data field, transmitting said message to said second device. This enables to send customized messages to said second device, wherein e.g. instead of a regular UUID value, said device data may be transmitted. In other words, according to further preferred embodiments, the data field for receiving one or more UUID values of conventional devices may, according to further preferred embodiments, be used to transmit said device data instead, which increases operational flexibility. According to further preferred embodiments, said device data is different from at least one, preferably all, UUID values associated with said first device and/or said second device. As an example, the first device according to the embodiments may well be associated with and/or use one or more UUID values as known from convenetional systems. However, according to further preferred embodiments, it does not transmit such (conventional) UUID values in said data field, but it rather uses said data field for transmitting said device data and/or portions thereof.

According to further preferred embodiments, said device data is determined dynamically, i.e. during a runtime of the first device, preferably depending on data processed by said first device and/or on data entered by a user of said first device to said first device and/or to a target system for said first device.

According to further preferred embodiments, said device data comprises and/or characterizes first data, wherein said first data is associated with at least one of: said first device, said second device, a target system for said first device, a target system for said second device, wherein preferably said target system for said first device is a mobile device such as e.g. a mobile phone, particularly smartphone, or a tablet computer, wherein preferably said target system for said second device is a control unit for a vehicle, preferably a control unit for a car, wherein preferably said first data characterizes or is a vehicle identification number, VIN.

As an example, according to further preferred embodiments, a user of a smartphone comprising the first device may enter user data such as a VIN of a vehicle the user wants to access, and said first device may use said VIN and/or data derived therefrom to determine and/or provide said device data. This way, according to further preferred embodiments, said VIN and/or data derived therefrom may be transmitted in said message to the second device, i.e. instead of a regular, conventional UUID value.

This way, efficient WPAN-based customized data exchange between the first and second devices may be provided, wherein it is especially advantageous that user data such as a VIN may be transmitted to the second device at a rather early stage of said WPAN communications, e.g. in the form of one or more advertising messages. By contrast, in conventional systems, at the stage of sending such advertising message(s), at best a conventional UUID value may be transmitted from the first device to the second device, whereas according to preferred embodiments, at the same stage, customized user data may be conveyed to the second device in form of the device data, which may replace one or more regular UUID values from the UUID data field of the message(s).

As an example, according to further preferred embodiments, a mobile phone or smartphone may comprise the first device and/or may implement a functionality of said first device, and a control unit of a vehicle such as a car may comprise said second device and/or may implement a functionality of said second device. This way, efficient wireless data exchange between the mobile phone (or its first device, respectively) and the car (or its second device, respectively) may be enabled, particularly WPAN-based communication, e.g. within a distance range of 0 meters (m) and 30 m, preferably between 0 m and 5m between said first and second device.

According to further preferred embodiments, said method further comprises: determining a random number, determining a hash value depending on said random number and on said first data, wherein optionally at least a part of said device data comprises at least a portion of said hash value and/or of said random number. In other words, at least a portion of said hash value and/or of said random number may be used as said device data which may transmitted to the second device using the data field for the UUID. According to further preferred embodiments, both at least one portion of said hash value and said random number may be transmitted to the second device using the data field for the UUID. This way, an efficient and secure data transmission of customized data (as compared to conventional UUID value(s)) is enabled. Further advantageously, when using the hash value, the data transmissions from the first device comprising said message(s) or its user cannot be tracked.

According to further preferred embodiments, said method further comprises: using at least one of the following hash functions for determining said hash value: S HA-224, S HA-256, SHA-384, SHA-512, SHA-512/224 und SHA-512/256. Further details regarding these hash functions may be found at https://doi.orq/10.6028/NIST.FIPS.180-4. According to further preferred embodiments, other types of hash functions may also be used. According to further preferred embodiments, said step of determining said hash value further comprises: combining said random number with said first data to obtain a combination, applying a or said hash function (e.g., SHA-256) to said combination to obtain a hash function output, using at least a portion of said hash function output as said hash value.

According to further preferred embodiments, said portion of said hash function output used as said hash value comprises twelve bytes, preferably the twelve most significant bytes of said hash function output.

According to further preferred embodiments, said random number comprises four bytes. According to further preferred embodiments, hence, the hash value together with the random number may comprise a length of 12+4=16 bytes, corresponding to 128 bit, which 128 bit may be provided as said device data to the data field originally receiving a UUID value.

According to further preferred embodiments, combining said random number with said first data to obtain a combination may comprise at least one of: a) adding said random number to said first data (wherein said first data may e.g. also be considered to characterize a number), b) logically combining said random number with said first data, e.g. by using an AND or an XOR function or the like, c) concatenating said random number and said first data. According to further preferred embodiments, said concatenating may be performed by appending said random number to said first data.

According to further preferred embodiments, said WPAN communications technology is based on a) the Bluetooth Low Energy, BLE, specification version 4.2 or above and/or on b) a specification at least partly compatible with the BLE specification version 4.2, particularly the Bluetooth Core Specification version 5.1 or higher. As an example, said BLE specifications are available at https://www.bluetooth.com/specifications/archived-specifications/.

According to further preferred embodiments, said message is an advertising message, preferably a Bluetooth advertising message according to the Bluetooth Low Energy, BLE, specification version 4.2 and/or above, wherein preferably said data field suitable for receiving a universally unique identifier, UUID, comprises a length of 128 bit, wherein preferably said device data comprises 128 bit.

Further preferred embodiments relate to a first device, wherein said first device is configured to wirelessly transmit data to a second device, preferably using a wireless personal area network, WPAN, communications technology, wherein said first device is configured to perform the method according to the embodiments.

Further preferred embodiments relate to a method of operating a second device, wherein said second device is configured to wirelessly receive data from a first device, particularly from a first device according to the embodiments, preferably using a wireless personal area network, WPAN, communications technology, wherein said method of operating the second device comprises: receiving a message comprising device data from said first device, extracting at least a portion of said device data from a data field of said message which is suitable for receiving a universally unique identifier, UUID, and evaluating said extracted device data.

According to further preferred embodiments, said method of operating said second device comprises: receiving a hash value and a random number from said first device as said device data in said data field, evaluating said received hash value depending on said random number and reference data, wherein preferably said evaluating comprises determining a second hash value depending on said received random number and on said reference data and comparing said second hash value with said received hash value.

As an example, according to further preferred embodiments, said determining of said second hash value may be similar or identical to said determining of said hash value at the first device. As an example, according to further preferred embodiments, if said second hash value (as obtained by the second device) is identical with said received hash value from said first device, it may be concluded that said first device possesses and/or has used first data for building said hash value which is identical to said reference data of said second device. As an example, if said first device uses a specific VI N together with a specific random number (e.g. determined by said first device) to determine the hash value to be transmitted to the second device (e.g., as said device data in said data field conventionally provided to receive a UUID value), and if said second device also uses said same specific VIN (e.g., provided locally at the second device in form of its reference data) together with the specific random number as received from the first device, said second hash value is identical with said hash value as determined by and received from said first device.

According to further preferred embodiments, said reference data may be local data of said second device and/or a shared information, especially shared secret, known to both the first device and the second device, which enables the second device to efficiently evaluate the hash value received from said first device. Particularly, said reference data may be identical to said first data.

According to further preferred embodiments, said reference data is associated with at least one of: said first device, said second device, a target system for said first device, a target system for said second device, wherein preferably, as mentioned above, said target system for said first device is a mobile device such as e.g. a mobile phone, particularly smart phone, or a tablet computer, wherein preferably said target system for said second device is a control unit for a vehicle, preferably a control unit for a car, wherein preferably said reference data characterizes or is a vehicle identification number, VIN. This way, efficient WPAN-based data exchange between the first and second devices may be provided, while tracking by an attacker may be prevented, as explained above.

Further preferred embodiments relate to a second device configured to perform the method according to the embodiments. According to further preferred embodiments, the second device or its functionality may e.g. be integrated into a control unit for and/or of the vehicle.

Further preferred embodiments relate to a computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method according to according to the embodiments. Further preferred embodiments relate to a computer-readable storage medium comprising instructions which, when executed by a computer, cause the computer to carry out the method according to the embodiments.

Further preferred embodiments relate to a data carrier signal carrying the computer program according to the embodiments.

Further preferred embodiments relate to a system comprising at least one first device according to the embodiments and at least one second device according to the embodiments.

Further preferred embodiments relate to a method of operating a system comprising at least one first device according to the embodiments and at least one second device according to the embodiments.

Further preferred embodiments relate to a use of the method according to the embodiments and/or of the first device according to the embodiments and/or of the second device according to the embodiments and/or of the computer program according to the embodiments and/or of the system according to the embodiments for at least one of: a) transmitting one or more messages, particularly advertising messages, preferably Bluetooth advertising messages according to the Bluetooth Low Energy, BLE, specification version 4.2 and/or above and/or a compatible specification, wherein preferably a data field of said advertising message for receiving a universally unique identifier, UUID, according to the BLE specification 4.2 is used for transporting said device data, prefererably other than a UUID value, from said first device to said second device, b) preventing tracking of said first device, c) improving privacy protection of said first device, d) establishing vehicle ownership, particularly when using said second device in said vehicle as a target system, e) gaining access to a vehicle, particularly when using said second device in said vehicle as a target system, preferably for automatic passive entry, APE, to said vehicle and/or for triggered passive entry, TPE, to said vehicle, and/or for remote keyless entry, RKE, to said vehicle, f) unlocking a vehicle, particularly when using said second device in said vehicle as a target system, g) sending data, particularly user data associated with said first device and/or with a user of said first device, particularly to said second device, h) establishing connection to an unknown device, i) authenticating a connection to a device, j) replacing a UUID value in a data field of an advertising message with other data, preferably said device data, k) transmitting customized advertising messages to the second device, I) transmitting data received from a user of said first device and/or from a user of a target system of said first device to the second device, particularly instead of transmitting a UUID value to said second device.

As an example, according to further preferred embodiments, the principle according to the embodiments may be used for providing an operating system independent solution to send customized advertising messages. Therefore, it does not matter if the message is sent from a device/machine, e.g. smartphone with a specific operating system. Rather, different smartphones and/or tablet computers and the like may e.g. be used as a target system for receiving the first device according to the embodiments and/or for implementing the function of said first device according to the embodiments. Further advantageously, existing smartphones may e.g. be used and may, according to further preferred embodiments, be extended by a computer program ("application", "phone app") implementing the method according to the embodiments. As further preferred embodiments propose to use a conventional UUID data field for transmitting said (e.g., customized) device data, conventional smartphone hardware may be used to implement the approach according to the embodiments. Particularly, according to further preferred embodiments, no changes to conventional smartphone hardware, e.g. regarding a BLE transceiver, are required.

According to further preferred embodiments, one or more customized advertising message may be transmitted to the second device, e.g. to efficiently and/or automatically (without any (further) user interaction) connect to a peripheral device/machine, preferably without any user interaction.

According to further preferred embodiments, to send a customized advertising message, the 128-Bit Service Universally Unique ID (data field for receiving said UUID) is not used in its conventional and/or standard(ized) way, e.g. such as an advertiser of a certain service, particularly with a conventional UUID value. Instead, according to further preferred embodiments, it is holding the (customized) information that e.g. a user and/or phone app wants to transfer by itself, e.g. in the form of the device data. The second device, which may e.g. be a central device/machine, can, according to further preferred embodiments, then automatically choose a right advertising message by their Service UUID and connect.

According to further preferred embodiments, the contents of said device data may change dynamically, e.g. upon every connection of a the first device with the second device.

According to further preferred embodiments, neither the first device nor the second device is required to hold a fixed list of UUID values ("UUIDs").

As another example, according to further preferred embodiments, the principle according to the embodiments may be used for setting up an initial WPAN, for example Bluetooth Low Energy (BLE), connection between two devices, i.e. the first device and the second device, e.g. based on a name and/or identifier ("id"), e.g. a VIN, preferably to identify, particularly uniquely identify, each other. This identifier, e.g. the VIN, may be part of an (e.g., BLE) advertising message ("VIN advertising message"), wherein said first device may e.g. be configured to transmit such (BLE) advertising message upon a first connection with said second device.

As an example, according to further preferred embodiments, instead of sending the identifier (e.g., VIN) in plain text, said hash value can be created by the first device out of the identifier and a random number, as explained above. Upon this, the hash value and the random number may be sent within the advertising message, in form of said device data, (e.g., instead of a plain text, conventional UUID) from the first device to the second device. Advantageously, an attacker is therefore not able to resolve out of the hash value and the random number the identifier, e.g. VIN. Hence, according to further preferred embodiments, the identifier is kept secret to the public. According to further preferred embodiments, only the second device can verify such an advertising message as provided by said first device, e.g. by creating out of the received random number within the advertising message and the known identifier (e.g., reference data) the second hash value for comparison with the received hash value of the advertising message. Brief description of the figures

Some exemplary embodiments will now be described with reference to the accompanying drawings, in which:

Fig. 1 schematically depicts a simplified block diagram of devices according to preferred embodiments,

Fig. 2A schematically depicts a simplified flow chart of a method according to further preferred embodiments,

Fig. 2B schematically depicts a simplified flow chart of a method according to further preferred embodiments,

Fig. 2C schematically depicts a simplified flow chart of a method according to further preferred embodiments,

Fig. 3 schematically depicts a simplified block diagram of an operational scenario according to further preferred embodiments,

Fig. 4A,

4B each schematically depict a simplified block diagram of data according to further preferred embodiments,

Fig. 5 schematically depicts a simplified block diagram of a first device according to further preferred embodiments,

Fig. 6 schematically depicts a simplified flow chart of a method according to further preferred embodiments,

Fig. 7 schematically depicts a simplified flow chart of a method of operating a second device according to further preferred embodiments,

Fig. 8 schematically depicts a simplified flow chart of a method of operating a second device according to further preferred embodiments, Fig. 9 schematically depicts a simplified flow chart of a method of operating a system according to further preferred embodiments,

Fig. 10 schematically depicts a simplified block diagram according to further preferred embodiments,

Fig. 11 Aschematically depicts a simplified block diagram of a data format according to further preferred embodiments,

Fig. 11 Bschematically depicts a simplified block diagram of a data format according to further preferred embodiments, and

Fig. 12 to 24 each schematically depicts a simplified flow chart and/or state diagram according to further preferred embodiments.

Figure 1 schematically depicts a simplified block diagram of devices according to preferred embodiments. A first device 100 is provided which is configured to wirelessly transmit data to a second device 200, cf. the arrow AM of Fig. 1. Generally, both devices 100, 200 may be configured to wirelessly exchange data with each other. In other words, according to further preferred embodiments, said first device 100 may be configured to wirelessly transmit data to the second device and/or to wirelessly receive data from said second device 200. Similarly, according to further preferred embodiments, said second device 200 may be configured to wirelessly receive data from said first device 100 and/or to wirelessly transmit data to the first device 100.

According to further preferred embodiments, for said wireless data transmission, a wireless personal area network, WPAN, communications technology may be used. Preferably, said WPAN communications technology is based on radio frequency signals that may be exchanged between said devices 100, 200 as known in the art. As such, according to further preferred embodiments, said devices 100, 200 may form a system 1000, particularly communications system, preferably a WPAN communications system. Further preferred embodiments relate to a method of operating the first device 100, cf. Figure 2A, wherein said method comprises: constructing 300 a message AM (Fig. 1 ) comprising a data field suitable for receiving a universally unique identifier, UUID, providing 302 (Fig. 2A) device data DD in said data field, transmitting 304 said message AM to said second device 200 (Fig. 1). This enables to send customized messages AM, also cf. the schematic block diagram of Fig. 4A, to said second device 200, wherein e.g. instead of a regular UUID value, said device data DD may be transmitted. In other words, according to further preferred embodiments, the data field DF (Fig. 4A) for receiving one or more UUID values of conventional devices may, according to further preferred embodiments, be used to transmit said device data DD instead, which increases operational flexibility.

According to further preferred embodiments, said message AM as exemplarily depicted by Fig. 4A may, in addition to the data field DF used for transmitting said device data DD, also comprise further data fields collectively denoted by "..." (three dots), as is well known in the field of BLE 4.2 and/or as is explained in further detail further below e.g. with reference to Fig. 11 A, 11 B.

According to further preferred embodiments, said device data DD (Fig. 2A, 4A) is different from at least one, preferably all, UUID values associated with said first device 100 (Fig. 1) and/or said second device 200. As an example, the first device 100 according to the embodiments may well be associated with and/or use one or more UUID values as known from convenetional systems. However, according to further preferred embodiments, it does not transmit such (conventional) UUID values in said data field DF (Fig. 4A) when using said message AM according to preferred embodiments, but it rather uses said data field DF (Fig. 4A) for transmitting said device data DD and/or portions thereof.

According to further preferred embodiments, said device data DD is determined dynamically, i.e. during a runtime of the first device 100, preferably depending on data processed by said first device 100 and/or on data entered by a user of said first device 100 to said first device 100 and/or to a target system for said first device. According to further preferred embodiments, said device data DD comprises and/or characterizes first data D1 , wherein said first data D1 is associated with at least one of: said first device 100, said second device 200, a target system for said first device 100, a target system for said second device 200, wherein preferably said target system for said first device 100 is a mobile device 10, cf. Fig. 3, such as e.g. a mobile phone, particularly smartphone 10 (also cf. element 10a, cf. Fig. 12 et seq. further below), or a tablet computer, wherein preferably said target system 20 for said second device 200 is a control unit for a vehicle, preferably a control unit for a car 20 (Fig. 3), or a car 20, wherein preferably said first data D1 (Fig. 4A) characterizes or is a vehicle identification number, VIN, preferably of said vehicle 20. This way, efficient WPAN-based customized data exchange between the first and second devices 100, 200 and their target systems 10, 20 may be provided, while, according to further preferred embodiments explained in detail further below, tracking by an attacker may be prevented.

According to further preferred embodiments, it is especially advantageous that user data such as a VIN may be transmitted to the second device 200 at a rather early stage of said WPAN communications, e.g. in the form of one or more advertising messages AM. By contrast, in conventional systems, at the stage of sending such advertising message(s), at best a conventional UUID value may be transmitted from the first device to the second device, whereas according to preferred embodiments, at the same stage, customized user data may be conveyed to the second device 200 in form of the device data DD, which may e.g. replace one or more regular UUID values from the UUID data field of the message(s).

As an example, according to further preferred embodiments, a user of a smartphone comprising the first device 100 may enter user data such as a VIN of a vehicle 20 (Fig. 3) the user wants to access, and said first device 100 may use said VIN and/or data derived therefrom to determine and/or provide said device data DD (Fig. 4A). This way, according to further preferred embodiments, said VIN and/or data derived therefrom may be transmitted in said message AM (Fig.

1 ) to the second device 200, i.e. instead of a regular, conventional UUID value. As an example, according to further preferred embodiments, a mobile phone or smartphone 10 (Fig. 3) may comprise the first device 100 and/or may implement a functionality of said first device 100, and a control unit of a vehicle such as a car or the car 20 (together with such control unit, not shown in Fig. 3) may comprise said second device 200 and/or may implement a functionality of said second device 200. This way, efficient wireless data exchange DE between the mobile phone 10 (or its first device 100, respectively) and the car 20 (or its second device 200, respectively) may be enabled, particularly WPAN-based communication, e.g. within a distance range of 0 meters (m) and 30 m, preferably between 0 m and 5 m between said first and second device, said distance symbolically being indicated by double arrow D of Fig. 3.

According to further preferred embodiments, cf. Fig. 2B, said method further comprises: determining 310 a random number RN, determining 312 a hash value HV depending on said random number RN and on said first data D1, wherein optionally at least a part of said device data DD (Fig. 4A) comprises at least a portion of said hash value HV and/or of said random number RN. In other words, at least a portion of said hash value HV (Fig. 2B) and/or of said random number RN may be used as said device data DD (Fig. 4A) which may transmitted to the second device 200 using the data field DF for the UUID. According to further preferred embodiments, both at least one portion of said hash value HV and said random number RN may be transmitted to the second device 200 using the data field DF for the UUID. This way, an efficient and secure data transmission of customized data (as compared to conventional UUID value(s)) is enabled.

Further advantageously, when using the hash value HV, the data transmissions from the first device 100 comprising said message(s) or its user cannot be tracked. Particularly, a specific VIN and/or other data that may form part of said device data may not be tracked due to the use of the hash value HV.

According to further preferred embodiments, said method further comprises using at least one of the following hash functions for determining said hash value HV: SHA (secure hash algorithm)-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256. Further details regarding these hash functions can be found at https://doi.orq/10.6028/NIST.FIPS.180-4. According to further preferred embodiments, other types of hash functions may also be used. According to further preferred embodiments, said step 312 (Fig. 2B) of determining said hash value HV further comprises, cf. Fig. 2C: combining 312a said random number RN with said first data D1 to obtain a combination comb, applying 312b a or said hash function, e.g., SHA-256, to said combination comb to obtain a hash function output HO, using 312c at least a portion of said hash function output HO as said hash value HV.

In this respect, Figure 4B schematically depicts a simplified block diagram of data according to further preferred embodiments, wherein the block comb represents said combination of said first data D1 and said random number RN as mentioned above, wherein said block arrow HF of Fig. 4 represents an application of said hash function (also cf. step 312b of Fig. 2C), and wherein said block HO of Figure 4B represents said hash function output HO as obtained by step 312b. Reference sign HO' of Fig. 4B indicates said portion of said hash function output HO which is preferably used as said hash value HV (Fig. 2C).

According to further preferred embodiments, said portion HO' of said hash function output HO used as said hash value HV comprises twelve bytes, preferably the twelve most significant bytes of said hash function output HO.

According to further preferred embodiments, said random number RN comprises four bytes. According to further preferred embodiments, hence, the hash value HV together with the random number RN may comprise a length of 12+4=16 bytes, corresponding to 128 bit, which 128 bit may be provided as said device data DD (Fig. 4A) to the data field DF originally receiving a UUID value in conventional systems.

According to further preferred embodiments, said step 312a (Fig. 2C) of combining said random number RN with said first data D1 to obtain said combination comb may comprise at least one of: a) adding said random number RN to said first data D1 (wherein said first data D1 may e.g. also be considered to characterize a number), b) logically combining said random number RN with said first data D1 , e.g. by using an AND or an XOR function or the like, c) concatenating said random number RN and said first data D1. According to further preferred embodiments, said concatenating may be performed by appending said random number RN to said first data D1 , whereby the most significant bytes of said combination comb comprise said first data D1 and the least significant bytes of said combination comb comprise said random number.

According to further preferred embodiments, said WPAN communications technology that may be used by said first device 100 (Fig. 1) and/or said second device 200 is based on a) the Bluetooth Low Energy, BLE, specification version 4.2 or higher and/or on b) a specification at least partly compatible with the BLE specification version 4.2, particularly the Bluetooth Core Specification version 5.1 or higher. As an example, said BLE specifications are available at https://www.bluetooth.com/specifications/archived-specifications/.

According to further preferred embodiments, said message AM (Fig. 1, 4A) is an advertising message, preferably a Bluetooth advertising message according to the Bluetooth Low Energy, BLE, specification version 4.2 and/or above, wherein preferably said data field DF (Fig. 4A) suitable for receiving a universally unique identifier, UUID, comprises a length of 128 bit, wherein preferably said device data DD (also) comprises 128 bit.

Further preferred embodiments relate to a/said first device 100, wherein said first device 100 is configured to wirelessly transmit data to said second device 200, preferably using a wireless personal area network, WPAN, communications technology, wherein said first device 100 is configured to perform the method according to the embodiments.

Figure 5 schematically depicts a simplified block diagram of a first device 100a according to further preferred embodiments. As an example, the first device 100 of Fig. 1 may comprise a configuration and/or structure at least similar or identical to the configuration 100a of Fig. 5. Device 100a comprises at least one calculating unit 102 and at least one memory unit 104 associated with (i.e., usable by) said at least one calculating unit 102 for at least temporarily storing a computer program PRG and/or data DAT (e.g., said device data DD, and/or a VIN, and/or the random number RN, and the like), wherein said computer program PRG is e.g. configured to at least temporarily control an operation of said device 100, 100a, e.g. the execution of a method according to the embodiments. According to further preferred embodiments, the at least one calculating unit 102 may comprise at least one of the following elements: a microprocessor, a microcontroller, a digital signal processor (DSP), a programmable logic element (e.g., FPGA, field programmable gate array), an ASIC (application specific integrated circuit), hardware circuitry, a core. According to further preferred embodiments, any combination of two or more of these elements is also possible.

According to further preferred embodiments, the memory unit 104 comprises at least one of the following elements: a volatile memory 104a, particularly a random-access memory (RAM), a non-volatile memory 104b, particularly a Flash-EEPROM. Preferably, said computer program PRG is at least temporarily stored in said non-volatile memory 104b. Data DAT, which may e.g. be used for executing the method according to the embodiments, may at least temporarily be stored in said RAM 104a.

According to further preferred embodiments, an optional computer-readable storage medium SM comprising instructions, e.g. in the form of a further computer program PRG’, may be provided, wherein said further computer program PRG’, when executed by a computer, i.e. by the calculating unit 102, may cause the computer 102 to carry out the method according to the embodiments. As an example, said storage medium SM may comprise or represent a digital storage medium such as a semiconductor memory device (e.g., solid state drive, SSD) and/or a magnetic storage medium such as a disk or harddisk drive (HDD) and/or an optical storage medium such as a compact disc (CD) or DVD (digital versatile disc) or the like.

According to further preferred embodiments, the first device 100a may comprise a data interface 106, preferably for wireless bidirectional data exchange with an external device (not shown in Fig. 5), such as e.g. the second device 200 (Fig. 1), e.g. according to at least one of said WPAN communication technologies as already mentioned above. As an example, said data interface 106 may comprise a transmitter/receiver ("transceiver"), e.g. a BLE-compatible transceiver 106'.

As an example, by means of said data interface 106, an optional data carrier signal DCS may be received, e.g. from an external device (not shown). According to further preferred embodiments, the data carrier signal DCS may represent or carry the computer program PRG, PRG' according to the embodiments, or at least a part thereof. Preferably, transceiver 106' may also be used to transmit one or more messages AM (Fig. 1) from the first device 100a (Fig. 5) to the second device 200 (Fig. 1).

According to further preferred embodiments, the first device 100a may be integrated into a mobile device 10, i.e. smartphone 10 (Fig. 3). According to further preferred embodiments, the functionality of said first device 100a may at least partly be implemented by using existing components (hardware and/or software) of said mobile device 10. As an example, according to further preferred embodiments, said mobile device 10 may be a smartphone with a processor, a memory unit, and a transceiver, preferably a BLE-capable transceiver. In these embodiments, the processor of said smartphone 10 may perform at least some aspects of the method according to the embodiments, and/or the memory unit of said smartphone 10 may be used to stored at least portions of said data DAT (Fig. 5) and/or said computer program PRG, PRG', and/or the transceiver of said smartphone 10 may be used to transmit and/or receive data to/from said further device 200.

According to further preferred embodiments, cf. Figure 6, said method of operating the first device 100, 100a further comprises: constructing 314a an advertising message AM (also cf. Fig. 1) comprising a data field DF (Fig. 4A),

P26 (cf. Fig, 11 B explained further below), said data field DF, P26 being suitable for receiving a universally unique identifier, UUID, according to BLE specification version 4.2 (or a specification at least partly compatible with the BLE specification version 4.2, particularly the Bluetooth Core Specification version 5.1 or higher), and providing 314b (Fig. 6) said hash value HV (Fig. 2A, 2B) and said random number RN, preferably as said device data DD (Fig. 4A) in said data field DF, p26 (Fig. 11 B). In other words, according to further preferred embodiments, instead of using a plain text UUID value, said first device 100, 100a may provide said hash value HV and said random number RN in the data field DF, P26 originally provided for receiving a plain text UUID according to the abovementioned BLE specification(s). I.e., according to further preferred embodiments, said first device 100, 100a "replaces" a plain text UUID value with said device data DD, e.g. the hash value HV and said random number RN. Optionally, in step 314c (Fig. 6), said advertising message AM is transmitted by said first device 100, 100a via its transceiver 106' (Fig. 5) to the second device 200 (also cf. Fig. 1).

Further preferred embodiments relate to a method of operating a/the second device 200 (Fig. 1), also cf. Fig. 7, wherein said second device 200 is configured to wirelessly receive data from a first device, particularly from a first device 100 according to the embodiments, preferably using a wireless personal area network, WPAN, communications technology, wherein said method of operating the second device 200 comprises: receiving 400 a message AM comprising device data DD from said first device 100 (e.g, said hash value HV and said random number RN), extracting at least a portion of said device data DD from a/said data field DF (Fig. 4A) of said message AM which is suitable for receiving a universally unique identifier, UUID, and evaluating 402 (Fig. 7) said extracted device data.

According to further preferred embodiments, said method of operating the second device 200 may comprise: receiving 400 a hash value HV and a random number RN from said first device 100, 100a as said device data DD in said data field DF, evaluating 402 said received hash value HV depending on said received random number RN and depending on reference data RD, wherein preferably said evaluating 402 comprises, cf. Fig. 8, determining 402a a second hash value HV2 depending on said received random number RN and on said reference data RD and comparing 402b said second hash value HV2 with said received hash value HV.

As an example, according to further preferred embodiments, said determining 402a of said second hash value HV2 at the second device 200 may be similar or identical to said determining of said hash value HV at the first device 100, 100a. As an example, according to further preferred embodiments, if said second hash value HV2 (as obtained by the second device 200) is identical with said received hash value HV from said first device 100, 100a, it may be concluded that said first device 100, 100a possesses and/or has used said first data D1 (Fig. 2A) for building 312 (Fig. 2A) said hash value HV which is identical to said reference data RD (Fig. 7) of said second device 200. As an example, if said first device 100, 100a uses a specific VI N as said first data D1 together with a specific random number RN (e.g., also determined by said first device 100, 100a) to determine 312 the hash value HV to be transmitted to the second device 200 (e.g., as said device data DD in said data field DF conventionally provided to receive a UUID value), and if said second device 200 also uses said same specific VIN (e.g., provided locally at the second device 200 in form of its reference data RD) together with the specific random number RN as received (step 400 of Fig. 7) from the first device 100, 100a, said second hash value HV2 (Fig. 7) is identical with said hash value HV (Fig. 2A) as determined by and received from said first device 100.

According to further preferred embodiments, said reference data RD may be local data of said second device 200 and/or a shared information, especially shared secret, known to both the first device 100, 100a and the second device 200, which enables the second device 200 to efficiently evaluate the hash value HV received from said first device 100, 100a. Particularly, said reference data RD may be identical to said first data D1.

According to further preferred embodiments, said reference data RD is associated with at least one of: said first device 100, 100a, said second device 200, a target system 10 (Fig. 3) for said first device 100, 100a, a target system 20 for said second device 200, wherein preferably, as mentioned above, said target system 10 for said first device 100, 100a is a mobile device 10 such as e.g. a mobile phone 10, particularly smartphone 10, or a tablet computer, wherein preferably said target system 20 for said second device 200 is a control unit (or a part of a control unit) for a vehicle, preferably a control unit for a car 20 (or the car 20 with such control unit), wherein preferably said reference data RD characterizes or is a vehicle identification number, VIN, especially the VIN of said vehicle 20. This way, efficient customized WPAN-based data exchange between the first and second devices 100, 100a, 200 may be provided, while tracking by an attacker may be prevented, as explained above.

Further preferred embodiments relate to a second device 200 configured to perform the method according to the embodiments. According to further preferred embodiments, the second device 200 or its functionality may e.g. be integrated into a control unit for and/or of the vehicle 20. According to further preferred embodiments, the second device 200 and/or a control unit for receiving said second device 200 may comprise a structure similar or identical with the configuration of Fig. 5, wherein the computer program PRG, PRG' is configured to control at least an operation of the second device 200.

According to further preferred embodiments, either device 100, 100a, 200 may be configured to at least temporarily perform the method according to at least one of Fig. 2A, 2B, 2C, 6 and/or according to at least one of Fig. 7, Fig. 8. In other words, according to further preferred embodiments, a device 100a (Fig. 5) may also be configured to at least temporarily perform the method of operating the first device 100, 100a as explained above and to at least temporarily perform the method of operating the second device 200 as explained above.

According to further preferred embodiments, said first device 100, 100a may be configured to at least temporarily assume a "peripheral" role according to BLE 4.2, wherein said second device 200 may be configured to at least temporarily assume a "central" role according to BLE 4.2, cf. e.g. the BLE specification version 4.2, Vol 1, Part A: Architecture, Section 6.2 "Generic Access Profile" (GAP).

Further preferred embodiments relate to a computer program PRG, PRG' (Fig. 5) comprising instructions which, when the program is executed by a computer 102, cause the computer 102 to carry out the method according to according to the embodiments.

Further preferred embodiments relate to a system 1000 (Fig. 1) comprising at least one first device 100, 100a according to the embodiments and at least one second device 200 according to the embodiments. As an example, such system 1000 may be used to enable, preferably WPAN-type, communications between a control unit of a car 20 and a smartphone 10, cf. Fig. 3.

Further preferred embodiments relate to a method of operating a system 1000 (Fig. 1 ) comprising at least one first device 100, 100a according to the embodiments and at least one second device 200 according to the embodiments. Figure 9 schematically depicts a simplified flow chart of such a method according to further preferred embodiments. In step s1 , the first device 100 determines a random or pseudorandom number RN. In step s2, the first device 100 determines a hash value HV, e.g. as explained in detail above with respect to Fig. 2B, 2C, and constructs said message AM (also cf. Fig. 4A), in which message AM e.g. the device data DD represents a concatenation of the hash value HV and the random number RN, said device data DD being placed in said data field DF of said message AM, said data field DF conventionally being filled with a UUID.

After that, the first device 100 transmits said message AM with the hash value HV and said random number RN comprised within said data field DF as said device data DD to said second device 200, e.g. in the form of a BLE 4.2 compatible advertisement message AM (Fig. 1). Upon receipt of said advertisement message AM, in step s3, the second device 200 extracts at least a portion of said device data DD from said advertisement message AM and, optionally, determines a second hash value HV2 depending on the received random number RN and, preferably local, reference data RD contained in said extracted device data DD. In step s4, the second device 200 compares the received hash value HV and the locally determined second hash value HV2. In a further, optional, step s5, the second device 200 controls an operation of the second device 200 and/or at least one further device (e.g., a control unit of said vehicle 20 (Fig. 3)) depending on said comparison of step s4.

As an example, according to further embodiments, if said comparison of step s4 yields that said second hash value HV2 is equal to or identical with said received hash value HV from said first device, 100, said second device 200 may continue to exchange data with said first device 100, e.g. for initiating a BLE connection with said first device 100. As an example, according to further embodiments, if said comparison of step s4 yields that said second hash value HV2 is not equal to or identical with said received hash value HV from said first device, 100, said second device 200 may refrain from further data exchange with said first device 100, e.g. "ignoring" said advertisement message AM.

Further preferred embodiments, cf. Figure 10, relate to a use 2000 of the method according to the embodiments and/or of the first device 100, 100a according to the embodiments and/or of the second device 200 according to the embodiments and/or of the computer program PRG, PRG' (Fig. 5) according to the embodiments and/or of the system 1000 (Fig. 1 ) according to the embodiments for at least one of: a) transmitting 2001 one or more messages AM, particularly advertising messages, preferably Bluetooth advertising messages AM according to the Bluetooth Low Energy, BLE, specification version 4.2 and/or above and/or a compatible specification, wherein preferably a data field DF of said advertising message AM for receiving a universally unique identifier, UUID, according to the BLE specification 4.2 is used for transporting said device data DD, prefererably other than a UUID value, from said first device 100, 100a to said second device 200, b) preventing 2002 tracking of said first device 100, 100a, c) improving 2003 privacy protection of said first device 100, 100a, d) establishing 2004vehicle ownership, particularly when using said second device 200 (Fig. 3) in said vehicle 20 as a target system, e) gaining 2005 access to a vehicle 20, particularly when using said second device 200 in said vehicle 20 as a target system, preferably for automatic passive entry, APE, 2005a to said vehicle 20 and/or for triggered passive entry, TPE, 2005b to said vehicle 20, and/or for remote keyless entry, RKE, 2005c to said vehicle 20, f) unlocking 2006 a vehicle 20 or a component (e.g., trunk) thereof, particularly when using said second device 200 in said vehicle 20 as a target system, g) sending 2007 data, particularly user data associated with said first device 100, 100a and/or with a user of said first device 100, 100a, particularly to said second device 200, h) establishing 2008 connection to an unknown device, i) authenticating 2009 a connection to a device, j) replacing 2010 a UUID value in a data field DF (Fig. 4A) of an advertising message AM with other data DD, preferably said device data DD, k) transmitting 2011 (also cf. step 304 of Fig. 2A) customized advertising messages AM to the second device 200, 1) transmitting 2012 (Fig. 10) data received from a user of said first device 100, 100a and/or from a user of a target system 10 (Fig. 3) of said first device 100 to the second device 200, particularly instead of transmitting a UUID value to said second device 200.

As an example, according to further preferred embodiments, the principle according to the embodiments may be used for providing an operating system independent solution to send customized advertising messages AM. Therefore, it does not matter if the message AM is sent from a device/machine, e.g. smartphone 10 with a specific operating system. Rather, different smartphones 10 and/or tablet computers and the like may e.g. be used as a target system for receiving the first device 100, 100a according to the embodiments and/or for implementing the function of said first device 100, 100a according to the embodiments. Further advantageously, existing smartphones may e.g. be used and may, according to further preferred embodiments, be extended by a computer program PRG (Fig. 5) ("application", "phone app") implementing the method according to the embodiments. As further preferred embodiments propose to use a conventional UUID data field DF (Fig. 4A) for transmitting said (e.g., customized) device data DD, conventional smartphone hardware may be used to implement the approach according to the embodiments. Particularly, according to further preferred embodiments, no changes to conventional smartphone hardware, e.g. regarding a BLE transceiver, are required.

According to further preferred embodiments, one or more customized advertising message(s) AM may be transmitted to the second device 200, e.g. to efficiently and/or automatically (without any (further) user interaction) connect to a peripheral device/machine, preferably without any user interaction.

According to further preferred embodiments, to send a customized advertising message AM, the 128-Bit Service Universally Unique ID (data field for receiving said UUID) is not used in its conventional and/or standard(ized) way, e.g. such as a conventional advertiser of a certain service, particularly with a conventional UUID value. Instead, according to further preferred embodiments, it is holding the (customized) information DD that e.g. a user and/or phone app wants to transfer by itself, e.g. in the form of the device data DD. According to further preferred embodiments, the second device 200, which may e.g. be a central device/machine, can then automatically choose a right advertising message AM by their Service UUID and connect.

According to further preferred embodiments, the contents of said device data DD may change dynamically, e.g. upon every connection of a the first device 100, 100a with the second device 200. Also, according to further preferred embodiments, the first device 100, 100a may dynamically generate said device data DD to be placed in the data field DF.

According to further preferred embodiments, neither the first device 100, 100a nor the second device 200 is required to hold a fixed list of UUID values ("UUIDs"). As another example, according to further preferred embodiments, the principle according to the embodiments may be used for setting up an initial WPAN, for example Bluetooth Low Energy (BLE), connection between two devices 100,

200, i.e. the first device 100 and the second device 200, e.g. based on a name and/or identifier ("id"), e.g. a VIN, preferably to identify, particularly uniquely identify, each other. This identifier, e.g. the VIN, may be part of an (e.g., BLE) advertising message AM (Fig. 9), wherein said first device 100 may e.g. be configured to transmit such (BLE) advertising message upon a first connection with said second device 200.

As an example, according to further preferred embodiments, instead of sending the identifier (e.g., VIN) in plain text, said hash value HV can be created by the first device 100 out of the identifier VIN (first data D1) and a random number RN, as explained above. Upon this, the hash value HV and the random number RN may be sent within the advertising message AM, in form of said device data DD, (e.g., instead of a plain text, conventional UUID) from the first device 100 to the second device 200. Advantageously, an attacker (not shown) is therefore not able to resolve out of the hash value HV and the random number RN the identifier, e.g. VIN. Hence, according to further preferred embodiments, the identifier is kept secret to the public. According to further preferred embodiments, only the second device 200 can verify such an advertising message AM as provided by said first device 100, e.g. by creating out of the received random number RN within the advertising message AM and the known identifier (e.g., reference data RD) the second hash value HV2 for comparison with the received hash value HV of the advertising message AM.

In the following, further preferred aspects and embodiments are explained with reference to Fig. 11 A to Fig. 32, wherein any of the following aspects and embodiments may be combined with one or more of the abovementioned aspects and embodiments.

Figure 11A schematically depicts a data packet format DF according to further preferred embodiments, which may be used for transmitting messages AM, especially from the first device 100 to the second device 200 and/or vice versa. Particularly, according to further preferred embodiments, said data packet format DF may be used to transmit said device data DD (Fig. 4A), e.g. comprising said hash value HV and said random number RN (Fig. 2A), from said first device 100 (Fig. 1 ) to said second device 200, e.g. in form of an (BLE) advertisement message, wherein said device data DD is provided in said data field DF (Fig. 4A) conventionally used for transmitting a UUID. According to further preferred embodiments, said data packet format DF may be used to transmit more than one set of device data, i.e. more than one 2-tuple (HV, RN) of a hash value HV and an associated random number RN, from said first device 100 (Fig. 1) to said second device 200, e.g. in form of an (BLE) advertisement message.

The most significant byte of said data packet format DF is denoted with reference sign MSB and the least significant byte of said data packet format DF is denoted with reference sign LSB in Fig. 11A. According to further preferred embodiments, said data packet format DF may comprise at least one of: a) a preamble P1 of e.g. 1 byte, b) an access address field P2 of e.g. 4 bytes, c) a protocol data unit, PDU, field P3 of preferably variable length (preferably ranging between 2 and 257 bytes), d) a redundancy information field P4, e.g. for a checksum, preferably crc-checksum, of e.g. 3 bytes.

According to further preferred embodiments, BLE advertisement messages AM (Fig. 1), e.g. for broadcasting data, may conform to GAP (Generic Access Profile) according to the BLE specification 4.2 or above. According to further preferred embodiments, at least some, preferably all, BLE advertisement messages AM shall fit into a single PDU P3 (Fig. 11A). According to further preferred embodiments, especially point-to-point connections (e.g., for sending commands), may conform to GATT (Generic Attribute Profile) according to the BLE specification 4.2 or above.

Figure 11 B schematically depicts a data packet format DF' according to further preferred embodiments, which may also be used for transmitting messages, especially from the first device 100 to the second device 200 and/or vice versa. The data packet format DF' may comprise at least one of: a) a preamble P5 of e.g. 1 byte (e.g. having a value of "OxAA"), b) an access address field P6 of e.g.

4 bytes, c) a protocol data unit, PDU, field P7 of preferably variable length (preferably ranging between 8 and 39 bytes), d) a redundancy information field P8, e.g. for a checksum, preferably CRC (cyclic redundancy check)-checksum, of e.g. 3 bytes. According to further preferred embodiments, the PDU field P7 may comprise a PDU header P9 of e.g. 2 bytes and a PDU payload field P10 of variable length, e.g. ranging between 6 and 37 bytes.

According to further preferred embodiments, the PDU header P9 may comprise at least one of: a) a PDU type field P11 of e.g. 4 bits, b) a transmit ("Tx") address field P12 of e.g. 1 bit, c) a receive ("Rx") address field P13 of e.g. 1 bit, d) a first reserved and/or unused field P14 of e.g. 2 bits, e) a length field P15 of e.g. 6 bits, e.g. to indicate said (variable) length of said PDU payload field P10, f) a second reserved and/or unused field P16 of e.g. 2 bits, g) an advertiser address field P17, e.g. of 6 bytes, e.g. for a BLE media access control (MAC) address, h) an advertising data field P18 of preferably variable length (preferably ranging between 0 and 31 bytes).

According to further preferred embodiments, the advertising data field P18 may comprise at least one of: a) a flag field P19 of e.g. 3 bytes, b) a field P20 for holding one or more (e.g., a list of) UUIDs, preferably 128-bit UUIDs.

According to further preferred embodiments, the flag field P19 may comprise at least one of: a) a length field P21 of preferably 1 byte, b) a type field P22 of preferably 1 byte, c) a data field P23 of preferably 1 byte.

According to further preferred embodiments, the field P20 may comprise at least one of: a) a length field P24 of preferably 1 byte, b) an advertisement type field P25 of preferably 1 byte, c) at least one data field DF, P26 for conventionally receiving a UUID value ("UUID field") of preferably 16 bytes. As an example, the device data DD of said first device 100, 100a, e.g. in the form of and/or comprising the hash value HV and the random number RN according to preferred embodiments (cf. e.g. Fig. 2A, 9), may be provided in said UUID field P26 of Fig.

11 B, cf. the rectangle DD within the data field DF, P26.

According to further preferred embodiments, the data packet formats DF, DF' explained above with reference to Fig. 11 A, 11 B may e.g. be used by the first device 100, 100a and/or target systems 10 for said first device 100, 100a such as e.g. smartphones for transmitting BLE advertising messages. This way, a unified advertising message structure may be provided which may e.g. be used for transmitting device data DD, e.g. comprising the hash value HV and said random number RN.

According to further preferred embodiments, messages, particularly advertisement messages AM (Fig. 1), may comprise an advertising data field P18 (Fig. 11 B) according to the following examples related to tables T1 to T10. According to further preferred embodiments, where a fixed value is indicated, e.g. in the tables T1 to T10, said fixed value may be set in this way for a plurality of, preferably for all, advertising messages. According to further preferred embodiments, variable value fields in the tables T1 to T10 may e.g. be, preferably dynamically (during runtime, e.g. of said first device), defined for each message.

As can be seen from table T1 , as an example, according to further preferred embodiments, a first advertising data block ("Adv Data Block") "AD 0" may comprise the data as defined in rows 2, 3, 4, while an N-th advertising data block may comprise the data as defined in rows 5, 6, 7 of table T 1.

According to further preferred embodiments, an advertising data block structure as exemplarily depicted by table T2 below may be used, preferably for advertisements, e.g. VIN advertisements, with a complete list of service UUIDs.

As an example, an advertising event type may be "Connectable Undirected

(event)", also cf. e.g. Table 4.1 of BLUETOOTH SPECIFICATION Version 4.2 [Vol 6,

Part B]

Table T2

As an example, according to further preferred embodiments, the data according to row 4 of Table T2 above may comprise said hash value HV as explained above, e.g. with respect to Fig. 2A, 9, and, according to further preferred embodiments, the data according to row 5 of Table T2 may comprise said random number RN as explained above, e.g. with respect to Fig. 2A, 9. In other words, rows 4, 5 of table T2 above may correspond with and/or form part of the device data DD as explained above with reference to Fig. 1 to 11B. According to further preferred embodiments, a new random number RN may be determined and/or used each time a user of the first device 100, 100a opens an activity, e.g. requiring access to an unknown vehicle 20 (Fig. 3). Such determination may e.g. be made in step 300 explained above with respect to Fig. 2A.

According to further preferred embodiments, a new random number RN may be generated repeatedly, particularly periodically, especially during a connection (e.g., between said first device 100, 100a and said second device 200). This may further contribute to preventing a traceability of the user of the device 100, 100a.

According to further preferred embodiments, an advertising data block structure as exemplarily depicted by table T3 below may be used, preferably for advertisements, e.g. VI N advertisements, with an incomplete list of service UUIDs. As an example, an advertising event type may be "Connectable Undirected (event)", also cf. e.g. Table 4.1 of BLUETOOTH SPECIFICATION Version 4.2 [Vol 6, Part B]

According to further preferred embodiments, also for "incomplete list of service UUIDs" cases, a new random number RN may be determined and/or used each time a user of the first device 100, 100a opens an activity, e.g. requiring access to an unknown vehicle 20 (Fig. 3). Such determination may e.g. be made in step 300 explained above with respect to Fig. 2A. According to further preferred embodiments, a new random number RN may be generated repeatedly, particularly periodically, especially during a connection (e.g., between said first device 100, 100a and said second device 200). This may further contribute to preventing a traceability of the user of the device 100, 100a.

According to further preferred embodiments, when the vehicle 20 (Fig. 3) or its second device 200, respectively, receives an advertisement message AM (Fig.

1 ), particularly VI N advertisement message AM, with incomplete list of service UUID, the vehicle 20 (or its second device 200, respectively) may send a scan request, particularly if at least one of the following conditions C1 , C2, C3 is not met:

UUIDs received in the Advertisement

According to further preferred embodiments, a data block structure as exemplarily depicted by table T4 below may be used, especially for scan response.

According to further preferred embodiments, a data block structure as exemplarily depicted by table T5 below may be used, especially for Localisation Advertisement with Complete List of Service UUID. As an example, an advertising event type = Connectable Undirected.

According to further preferred embodiments, a data block structure as exemplarily depicted by table T6 below may be used, especially for Localisation Advertisement with Incomplete List of Service UUID. As an example, an advertising event type = Connectable Undirected.

In the following, further aspects and preferred embodiments related to GATT (Generic Attribute Profile) Services Definition and GATT Profile Definition are disclosed with respect to tables T7, T8, T9, T10.

According to further preferred embodiments, GATT services and associated characteristics in the System 1000 (Fig. 1) may/shall take the following format.

According to further preferred embodiments, a service denoted as "PkTagSvc" may be provided and/or defined, wherein said service PkTagSvc may be used to exchange data between a tag and the master. According to further preferred embodiments, a tag may act as the server, and the master may act as the client. As an example, according to further preferred embodiments, a tag may be a (preferably mobile) device, e.g. the first device 100, 100a and/or a key fob. according to further preferred embodiments, said first device 100, 100a may also act as a key fob. According to further preferred embodiments, the service "PkTagSvc" shall have ServiceJJUID = 54b8cc5e-7157-4b1f-858f-e92c0fb92d7f, which may be a hexadecimal number.

According to further preferred embodiments, at least one or more of the below listed characteristics may be provided by and/or shall be available in the service PkTagSvc.

According to further preferred embodiments, as can be seen from the row "AuthText" of Table T8 above, the service "PkTagSvc" may be used to transmit secure data from a tag 100 (Fig. 3) to the vehicle 20 (or its second device 200, respectively) and/or vice versa.

According to further preferred embodiments, related to characteristic values (Functional Messages), e.g. for the purpose of stereotyping a GATT Value Attribute as a transmitted message, the message may be written in the form: Service. Characteristic(Command, Parameters), e.g. PkT agSvc.AuthT ext(RKE, RKE_Function).

According to further preferred embodiments, e.g. related to plain text, the functional commands and corresponding parameters as exemplarily listed in table T9 below may be transmitted as a value field of the Characteristic Value Attribute of PkTagSvc.PlainTextQ, also cf. the row "PlainText" of table T8 above.

According to further preferred embodiments, e.g. related to AuthText, the functional commands and corresponding parameters as exemplarily listed in table T 10 below may be transmitted as the value field of the Characteristic Value Attribute of PkTagSvc.AuthTextQ, also cf. the row "AuthText" of table T8 above.

According to further preferred embodiments, e.g. related to CAText, PkTagSvc.CAText() may be used to transmit messages, e.g. messages generated by and or provided by means of a (cryptographic) security library, preferably all such messages generated by and or provided by means of such/said (cryptographic) security library. According to further preferred embodiments, such messages may be transmitted as the value field of the Characteristic Value Attribute of PkTagSvc.CAText(), also cf. the row "AuthText" of table T8 above. According to further preferred embodiments, details of the content of each such message may be contained in a documentation of the security library.

In the following, further details of aspects and further preferred embodiments are provided with reference to Fig. 12 to 24, which schematically depict simplified flow charts related to said further aspects and/or preferred embodiments which may be, either alone or in combination with each other, combined with at least one of the aspects and preferred embodiments explained above.

Figure 12 schematically depicts a flow-chart which may, according to at least some further preferred embodiments, relate to a use case "establishing vehicle ownership", wherein e.g. the first device 100, 100a according to the embodiments may be involved, which may e.g. be integrated into a smartphone, cf. block 10a of Fig. 12. Block 11 of Fig. 12 may represent a user of the smartphone 10a, and block 20a may represent a second device 200 (also cf. Fig. 3) according to the embodiments or a target system 20a for said second device 200, which target system 20a is preferably arranged in a vehicle 20. In the following description, the target system 20a is also named as "master", in accordance with its communication role with respect to the first device or smartphone 10a.

According to further preferred embodiments, said smartphone 10a may be configured to provide a user interface 10a' (preferably graphical user interface, GUI) for the user 11 , e.g. to enable the user 11 to enter data such as e.g. the vehicle's unique VIN, and/or an (optional) ownership code. As an example, at least one of these steps may be performed during an Ownership Setup process. According to further preferred embodiments, using said user interface 10a', said user 11 may chose and/or execute a function F1 (which may e.g. also be referred to as "AddNewVehicleO") to initiate a procedure at the smartphone 10a which enables to add a new vehicle. According to further preferred embodiments, in response to said function F1, said smartphone 10a may execute a function F2 (which may e.g. also be referred to as "RequestVehicleDetails()"), for requesting vehicle details, especially of said vehicle which should be added as indicated by function F1.

According to further preferred embodiments, using said user interface 10a', said user 11 may chose and/or execute a function F3 (which may e.g. also be referred to as "VehicleDetailsO") to provide detail data related to said new vehicle 20 (Fig. 3) to the smartphone 10a. According to further preferred embodiments, such detail data related to said new vehicle 20 may e.g. comprise at least one of: the vehicle's unique VIN, and/or an (optional) ownership code.

According to further preferred embodiments, the process of Fig. 12, which may also be referred to as "Ownership process", may, preferably after receiving the detail data of said new vehicle (function F3), utilize a block B1 (which may also be referred to as "Block_UnknownDeviceConnect"), preferably for connecting to an unknown device (e.g., the second device 20a of the new vehicle), details of which are explained further below with respect to Fig. 21.

According to further preferred embodiments, an optional block B2 may be provided, which comprises a first section B2_1 and a second section B2_2. According to further preferred embodiments, at least one of said sections B1_1 , B2_2 is executed conditionally. As an example, according to further preferred embodiments, if a PlainText attribute (also cf. table T8 above) exists, the Ownership process may proceed with execution of the first section B2_1 of block B1 , and, in other cases, i.e. if said PlainText attribute does not exist, the master 20a shall disconnect from the smartphone 10a, cf. dashed arrow a1 of the second section B2_2.

According to further preferred embodiments, in the first section B2_1 of block B2 an optional block B2_1_1 (which may also be referred to as "Block_AuthConnection") may be utilized/executed, details of which are explained further below with respect to Fig. 22.

According to further preferred embodiments, in the first section B2_1 of block B2 a further optional block B2_1_2 (which may also be referred to as " CAjDwnerRegistration") may be utilized/executed, details of which are provided in the Bluetooth specification. The CAjDwnerRegistration procedure B2_1_2 may e.g. comprise a protocol that uses a current established Bluetooth connection is not detailed in this application. Preferably, said CAjDwnerRegistration procedure B2_1_2 is performed after the block B2_1_1.

According to further preferred embodiments, following a successful new ownership in CAjDwnerRegistration B2_1_2, which may be signaled to the user 11 by means of message M1 , the master 20a may register the new owner ID as its owner, cf. dashed arrow a2, and may optionally clear all previous authentication data from previous owners and/or shared users, cf. dashed arrow a3.

According to further preferred embodiments, the exemplary ownership process according to Fig. 12 may utilize a bonding procedure within optional block B2_1_3 (which may also be referred to as "Block_Bonding"), details of which are explained further below with respect to Fig. 22.

According to further preferred embodiments, after the optional bonding procedure ("Block_Bonding") of block B2_1_3 is completed, the master 20a may send a message M2 to the smartphone 10a, wherein said message M2 e.g. signals a vehicle status to the smartphone 10, e.g. "PkTagSvc_AuthText(VehicleStatus)", which may e.g. signal the end of the Ownership process.

According to further preferred embodiments, the system 1000 (Fig. 1), which may also be referred to as "PK System", is configured to support a user 11 (Fig. 12) taking ownership of the vehicle 20 (Fig. 3), preferably using GUID: 6cd086d4- 8880-44a3-9d02-4bdecbdbb303.

Figure 13 schematically depicts a flow-chart which may, according to at least some further preferred embodiments, relate to a use case "known (smart)phone moves into range", wherein e.g. the smartphone 10a (and its first device 100, 100a) may be involved, as well as the vehicle 20 and its second device 20a.

According to further preferred embodiments, the process of Fig. 13 may comprise a block B3 (which may also be referred to as "Block_KnownDeviceConnect"), details of which are explained further below with respect to Fig. 24.

According to further preferred embodiments, an optional block B4 may be provided, which comprises a first section B4_1 and a second section B4_2. According to further preferred embodiments, at least one of said sections B4_1, B4_2 is executed conditionally. As an example, according to further preferred embodiments, if a PlainText attribute (also cf. table T8 above) exists (preferably on the smartphone 10a), the process may proceed with execution of the first section B4_1 of block B4, and, in other cases, i.e. if said PlainText attribute does not exist, the master 20a shall disconnect from the smartphone 10a, cf. dashed arrow a4 of the second section B4_2.

In the first section B4_1, the known device or smartphone 10a, respectively, may use/execute the block B4_1_1 (which may also be referred to as "Block_AuthConnection"), details of which are explained further below with respect to Fig. 22. After the block B4_1_1 ("Block_AuthConnection") is completed, the master 20a may send a message M3, preferably PkTagSvc_AuthText(VehicleStatus), to the smartphone 10a, i.e. similar to message M2 of Fig. 12. Preferably, this will signal the end of the Ownership process.

According to further preferred embodiments, the system 1000 (Fig. 1), which may also be referred to as "PK System", as mentioned above, is configured to support a known device connection and authentication, e.g. according to Fig. 13, wherein preferably a GUID may be: 525aac52-9fa2-408b-869e-88bcd909b553.

Figure 14 schematically depicts a flow-chart which may, according to at least some further preferred embodiments, relate to a use case " first use by a friend (i.e., a user with a shared key)", wherein e.g. the smartphone 10a (and its first device 100, 100a, and the user 11 ) may be involved, as well as the vehicle 20 and its second device 20a. According to further preferred embodiments, the user 11 may initiate a first connection and authentication via a function F4, e.g. by opening an RKE (remote keyless entry) page or section of the user interface 10a', wherein said user interface 10a' may e.g. be provided by an application (e.g., computer program, "phone application") running on the smartphone 10a. Function F4 is preferably executed whilst the smartphone 10a is in a BLE communications range of the vehicle 20.

According to further preferred embodiments, the smartphone 10a may enable the function F4 only after the master 20a sends vehicle status information (not shown in Fig. 14), e.g. similar to message M3 of Fig. 13. Temporarily disabling the function F4 may e.g. comprise visually indicating to the user 11 by means of the smartphone GUI 10a' that a GUI element (e.g., virtual "button") is currently not selectable and/or active, respectively, i.e. by "greying out" said GUI element. According to further preferred embodiments, once the smartphone 10a has received said vehicle status information from the master 20a, the smartphone 10a may activate its GUI element(s) for initiating the function F4.

According to further preferred embodiments, the process of Fig. 14 may comprise a block B1 (which may also be referred to as "BlockJJnknownDeviceConnect", also cf. Fig. 12), preferably for connecting to an unknown device, details of which are explained further below with respect to Fig. 21.

According to further preferred embodiments, an optional block B5 may be provided, which comprises a first section B5_1 and a second section B5_2. According to further preferred embodiments, at least one of said sections B5_1, B5_2 is executed conditionally. As an example, according to further preferred embodiments, if a PlainText attribute (also cf. table T8 above) exists, the process may proceed with execution of the first section B5_1 of block B5, and, in other cases, i.e. if said PlainText attribute does not exist, the master 20a shall disconnect from the smartphone 10a, cf. dashed arrow a5 of the second section B5_2.

According to further preferred embodiments, in the first section B5_1 of block B5 an optional block B5_1_1 (which may also be referred to as "Block_AuthConnection") may be utilized/executed, details of which are explained further below with respect to Fig. 22.

According to further preferred embodiments, in the first section B5_1 of block B5 a further optional block B5_1_2 (which may also be referred to as "Block_Bonding") may be utilized/executed, details of which are provided in Fig. 23. Preferably, said Block_Bonding procedure B5_1_2 is performed after the block B5_1_1.

According to further preferred embodiments, after the Block_Bonding block B5_1_2 is completed, the master 20a shall send a message M4 (e.g., as "PkTagSvc_AuthText(VehicleStatus)") to the smartphone 10a signaling that it (i.e., the smartphone 10a) may now activate the GUI element(s) (e.g., RKE buttons) on the GUI provided by said phone application. In turn, the smartphone 10a may active said GUI element(s), cf. "message" M5.

According to further preferred embodiments, the master 20a is configured to wait, cf. block B6 of Fig. 14, for the user 11 to select the GUI element, e.g., press the "Unlock button", on the phone application ("RKE event"). According to further preferred embodiments, once the RKE event is completed, cf. block B6a, the master may enable the functionality of Passive Entry (APE and/or TPE) and/or Passive Start, cf. the dashed arrow a6.

According to further preferred embodiments, the system 1000 (Fig. 1) ("PK System") is configured to support friend unknown device connection and/or authentication, cf. Fig. 14, e.g., using GUID: 70bafc90-d7eb-41d0-9b8f- a1fb31ed2806.

Figure 15 schematically depicts a flow-chart which may, according to at least some further preferred embodiments, relate to a use case "active connection", wherein e.g. the smartphone 10a (and its first device 100, 100a, and the user 11 ) may be involved, as well as the vehicle 20 and its second device 20a, and an optional anchor 12.

According to further preferred embodiments, the anchor 12 may support the master (e.g., second device 20a), e.g. to compute a current position of the mobile device 10a, e.g. using trilateration. According to further preferred embodiments, a vehicle 20 may have two or more anchor nodes 12 distributed all over the vehicle's body, which may e.g. communicate with the master 20a using vehicle's CAN bus and/or proprietary connection. According to further preferred embodiments, the anchor nodes 12 may be listening for Localisation_Advertisement() message of already connected devices to calculate distance using trilateration, such as e.g. message M6 of block B8 explained below.

According to further preferred embodiments, the anchor 12 may be omitted, and a corresponding functionality may at least partly be implemented by the second device 20a.

An optional first block B7 of Fig. 15 represents a procedure similar to that explained above with respect to Figure 13, which may e.g. relate to a use case "known (smart)phone moves into range".

According to a further optional block B8, the smartphone 10a sends at least one message M6, e.g. a Localisation_Advertisement() message M6 to the master 20a. According to further preferred embodiments, the smartphone 10a repeatedly, preferably periodically, e.g. corresponding to an advertising interval PMFastLocAdvlnterval, sends said advertisement message M6 to the master 20a. According to further preferred embodiments, the message(s) M6 of Fig. 15 may correspond with the advertisement message AM (Fig. 1 , 9) according to the embodiments explained above and may as such e.g. comprise the hash value HV and the random number RN as explained above, cf. e.g. Fig. 2A.

According to further preferred embodiments, said smartphone 20a is configured to receive a specific message (not shown in Fig, 15) from the master 20a, and to send at least one of said messages M6 as explained in the preceding paragraph once the specific massage from the master 20a is received.

According to further preferred embodiments, said smartphone 20a is configured to receive a PkTagSvc_AuthText(VehicleStatus) message M3 (cf. Fig. 13) as said specific message from the master 20a, and to send at least one of said messages M6 (Fig. 15) as explained in the preceding paragraph to the master 20a once the specific massage M3 from the master 20a is received. According to further preferred embodiments, once an M3 message from the master 20a is received at the smartphone 10a, the smartphone 10a may commence (or continue) to send Localisation_Advertisement() messages M6, preferably at the advertising interval PMFastLocAdvlnterval.

According to further preferred embodiments, optionally, as also depicted in block B8 of Fig. 15, the anchor 12 may, e.g. upon receipt of a/said advertisement message M6 from said smartphone 10a, perform a BLE address decoding operation, which may also be referred to "DecodeBLEAddress()", cf. dashed arrow a7.

According to further preferred embodiments, optionally, the anchor 12 may transmit output data obtained by said BLE address decoding a7 and/or data derived from said output data to said master 20a, cf. the message M7.

According to further preferred embodiments, optionally, and preferably upon receipt of message M7, the master 20a may perform a localization procedure, cf. dashed arrow a8 of block B8 of Fig. 15.

According to further preferred embodiments, and preferably after block B8, an optional block B9 is provided which relates to vehicle status changes. Details of this optional block B9 are explained further below with reference to Fig. 16.

According to further preferred embodiments, and preferably after block B9, an optional block B10 is provided which relates to cases of lost connection.

According to further preferred embodiments, the smartphone 10a may send a message M8 to the master, said message M8 e.g. indicating that an exit, by the smartphone 10a, of the BLE communication range with the master 20a is planned and/or has occurred. According to further preferred embodiments, and preferably upon receipt of said message M8, the master 20a may update its whitelist, e.g. by executing an "UpdateWhitelist()" function, cf. dashed arrow a9.

According to further preferred embodiments, and preferably upon execution of said "UpdateWhitelistQ" function a9, the master 20a may send a message M9 to the anchor 12 to signal to the anchor 12 that it should remove a certain tag, preferably associated with and/or represented by said smartphone 10a (or its first device 100, 100a, respectively). Upon receipt of said message M9, according to further preferred embodiments, the anchor 12 may remove said tag as signaled via said message M9, e.g. by updating its whitelist, cf. dashed arrow a10. For this purpose, according to further preferred embodiments, the anchor 12 may also use an "UpdateWhitelist()" function a10, which may e.g. be similar or identical to the "UpdateWhitelistO" function a9 of the master 20a.

According to further preferred embodiments, and similar to e.g. the second device 200, the anchor 12 of Fig. 15 may comprise a structure similar or identical with the configuration 100a of Fig. 5, wherein the computer program PRG, PRG' is configured to control at least an operation of the anchor 12, e.g. according to at least some aspects of the process exemplarily depicted by Fig. 15.

According to further preferred embodiments, the system 1000 (Fig. 1) ("PK System"), is configured to support vehicle status updates, e.g. in form of message M3 of Fig. 13, wherein e.g. GUID: b9194229-66c9-4d9f-96a5- c53ee7892f24.

Figure 16 schematically depicts a flow-chart which may, according to at least some further preferred embodiments, relate to a use case "vehicle status changes", wherein e.g. the smartphone 10a (and its first device 100, 100a) and the user 11 may be involved, as well as an entity 21 of the vehicle 20 (i.e., representing the vehicle) and its second device 20a. As an example, according to further preferred embodiments, the entity 21 of the vehicle 20 may represent one or more electronic control units (ECUs) of said vehicle, similar to the master 20a, which may also represent an ECU of said vehicle 20, comprising the second device 200 or the functionality of the second device 200).

According to further preferred embodiments, as an example, a status change of the vehicle 20 (Fig. 3) may occur, for example when a door of the vehicle is opened or closed or the like. In these cases, according to further preferred embodiments, the vehicle 20, or rather the respective ECU 21 of the vehicle 20, may send a message M10 (e.g. referred to as "StatusUpdate()"), to the master 20a. According to further preferred embodiments, and preferably upon receipt of said message M10, the master 20a may send a further message M11 to said smartphone 10a, preferably via the WPAN communications, i.e. BLE data connection between the devices 20a, 10a, wherein said message M11 may e.g. be referred to as "PkTagSvc_AuthText(VehicleStatus)". Message M11 may e.g. be transmitted in a secure manner to smartphone 10a, cf. e.g. the row "AuthText" of table T8 above.

According to further preferred embodiments, in an optional block B11 , and preferably upon receipt of said message M11 , the smartphone 10a may update its GUI, cf. the arrow a11 , i.e. to notify the user 11 of the vehicle status change characterized by the message M11. According to further preferred embodiments, the update a11 of the GUI may e.g. be performed if the application of the smartphone 10a is currently running and/or in the foreground, i.e. visible to the user 11. In other cases, e.g. if the application is in the background, according to further preferred embodiments, the vehicle status change may be signaled to the user 11 by means of a notification M12. According to further preferred embodiments, for implementing said notification M12, existing notification mechanisms of e.g. an operating system of the smartphone 10a may be used, e.g. indicating said notification in a status bar and/or notification bar of the smartphone's display, and/or performing an acoustic notification.

Figure 17 schematically depicts a flow-chart which may, according to at least some further preferred embodiments, relate to a use case "automatic passive entry" (APE), wherein the following entities may be involved: user 11, smartphone 10a, master 20a, an entity 21 ' of the vehicle 20, wherein said entity 21' may e.g. be similar to entity 21 (Fig. 16), e.g. another ECU of the vehicle 20, e.g. a body computer module (BCM), which represents a domain control unit e.g. for body electronic functions of said vehicle 20. As an example, according to further preferred embodiments, the system 1000 ("PK system") may be configured to support APE as explained in detail further below.

According to further preferred embodiments, Automatic Passive Entry (APE) is one available method for gaining vehicle access, which may e.g. be supported by the PK System 1000 (Fig. 1). According to further preferred embodiments, APE may also be referred to as "Approach Unlock" or "Auto Unlock.". According to further preferred embodiments, a methodology related to APE, e.g. in common language, may comprise one or more of the following aspects: - If any tag (e.g., smartphone 10a) with "UNLOCK" permission becomes localized within (a) defined UNLOCK zone/s of the vehicle 20, the vehicle 20 shall automatically unlock the door/s, - If no tags with UNLOCK permission remain localized within the defined STAY-UNLOCKED zone/s, the vehicle 20 shall automatically lock the door/s, - In order to prevent rapid unlocking/locking when the tag is on the border of the access zone, there shall be a configurable timer (e.g., APE_Timer = APE_Delay_Cfg), for which period after any unlock/lock event, APE is disabled.

According to further preferred embodiments, RKE and Triggered PE (passive entry) operations may override Automatic PE operations.

According to further preferred embodiments, automatic PE operations are only resumed after a PE zone transition into the same state as set by the RKE or triggered operation.

According to further preferred embodiments, in the case of a Triggered Lock, all tags should and/or must transition out of the UNLOCKED zone/s before APE Unlocking will resume. According to further preferred embodiments, in the case of a Triggered Unlock, at least 1 tag must transition into the UNLOCK zone/s before APE Locking will resume. According to further preferred embodiments, if a VehicleLockStatus changes, the APE_Timer may be reset, preferably with a value of APE_Delay_Cfg.

According to further preferred embodiments, a methodology related to APE unlock, may comprise one or more of the following aspects: a) If the current state of APE_Arbitration is Auto_Locked (e.g., corresponding to state S_1_2 of Fig. 18, see below), and APE_Unlock_Preconditions becomes TRUE, then a corresponding APE Unlock event may or shall be requested, b) An APE Unlock request shall take the form of req_Access(AccessType, AccessFunction, TagID), where AccessType = APE, AccessFunction = Unlock, c) If all of the following conditions are TRUE, APE_Unlock_Preconditions shall be set to TRUE: d) - APE_Timer has expired (e.g., there has been sufficient time since the vehicle was locked), c2) - AnyDoorAjar == FALSE (e.g., All doors are shut), c3) - TagslnUnlockZone == ANY (e.g., there is at least 1 tag inside the UNLOCK zone), c4) - APE_Unlock_Cfg == ENABLED (e.g., APE Unlocking is enabled on the vehicle), c5) - APE_Allowed == TRUE (according to rbd_pk_pf_sys_arch StateChart APE_Arbitration), d) else (e.g., if preceding aspect c) is not satisfied, APE_Unlock_Preconditions may/shall be set to FALSE.

According to further preferred embodiments, if any authenticated and connected tag with UNLOCK permission is localised in any given UNLOCK zone, then TagslnUnlockZone may or shall be set to ANY. According to further preferred embodiments, else, TagslnUnlockZone shall be set to NONE.

According to further preferred embodiments, if there are tags located in more than one AccessZone when APE_Unlock_Preconditions becomes TRUE, then APE Unlock shall/may proceed, preferably simultaneously, for all zones which contain tags with UNLOCK permission.

According to further preferred embodiments, a methodology related to APE lock, may comprise one or more of the following aspects: If the current state of rbd_pk_pf_sys_arch StateChart APE_Arbitration is AutoJJn locked, and APE_Lock_Preconditions becomes TRUE, then a corresponding APE Unlock event shall be requested. According to further preferred embodiments, an APE Lock request may take the form of req_Access(AccessType, AccessFunction, TagID); where AccessType = APE, AccessFunction = Lock.

According to further preferred embodiments, if all of the following conditions C1), C2), C3), C4), C5) are TRUE, APE_Lock_Preconditions shall be set to TRUE: C1) - APE_Timer has expired (e.g., There has been sufficient time since the vehicle was unlocked), C2) - AnyDoorAjar == FALSE (e.g., all doors are shut), C3) - TagslnUnlockZone == NONE (e.g., there are not any tags inside the unlocking zone), C4) - APE_Lock_Cfg == ENABLED (e.g., APE Locking is enabled on the vehicle), C5) - APE_Allowed == TRUE (e.g., according to rbd_pk_pf_sys_arch StateChart APE_Arbitration). Else, i.e. if at least one of said conditions C1) to C5) is not TRUE, APE_Lock_Preconditions may be set to FALSE.

According to further preferred embodiments, an APE Request may comprise at least one of the following aspects: According to further preferred embodiments, a message format related to an APE Request may be comparatively generic, where e.g. a specific vehicle implementation of the request and/or a response, e.g. via LIN (local interconnect network) or CAN (controller area network) may/shall be defined in a specification for that vehicle implementation.

According to further preferred embodiments, an APE Unlock request may or shall take the form of req_Access(AccessType, AccessFunction, TagID); where e.g. AccessType = APE, AccessFunction = Unlock. According to further preferred embodiments, an APE Lock request may or shall take the form of req_Access(AccessType, AccessFunction, TagID); where e.g. AccessType = APE, AccessFunction = Lock.

According to further preferred embodiments, an execution of a successful APE Lock/Unlock event may be or shall be realised according to e.g. Fig. 17. The PK System 1000 may or shall support Automatic Passive Entry behaviour according to rbd_pk_pf_sys_arch SequenceDiagram UseCase_AutomaticPE (GUID: 05cbcca4-c803-4b36-8f5d-03ee2e2e8e18).

Returning to the flowchart of Fig. 17, the optional block B12 represents an exemplary use case according to which a known device comes into range, also cf. Figure 13.

According to further preferred embodiments, the smartphone 10a sends a message M13 to the master 20a, wherein preferably the message M13 may be referred to as "CrossAccessZoneBoundaryQ".

According to further preferred embodiments, and preferably upon receipt of said message M13, the master 20a executes a function which may be referred to as "LocalizeTagO", also cf. the dashed arrow a12. According to further preferred embodiments, a boundary may be defined as an edge of a zone in which locking and unlocking passively is permitted (edge of UNLOCK ZONE).

According to further preferred embodiments, the process of Fig. 17 may comprise, preferably after execution of said optional function a12, a further optional block B13, wherein said block B13 may comprise a waiting process. According to further preferred embodiments, said block B13 may comprise waiting until the abovementioned APE preconditions (e.g., CrossAccessZoneBoundaryO), are satisfied.

According to further preferred embodiments, and preferably in the optional block B13, at least one optional APE request message M14 may be sent from the master 20a to the BCM 21'. According to further preferred embodiments, after receipt of said at least one optional APE request message M14, said BCM 21' may process said at least one received optional APE request message M14, cf. dashed arrow a13. According to further preferred embodiments, said processing a13 may also be referred to as "Process_Access_Request()".

According to further preferred embodiments, after said processing a13, said BCM 21' may send at least one APE response message M15 to the master 20a. As an example, according to further preferred embodiments, said APE response message M15 may e.g. be used to signal a vehicle lock status to the master 20a.

According to further preferred embodiments, after receipt of said at least one APE response message M15 at the master 20a, the master 20a may signal information related to said at least one APE response message M15 to the smartphone 10, cf. the message M16.

According to further preferred embodiments, at least one of said messages M14, M15 may be transmitted using at least one, preferably at least partly vehicle- internal, communication system such as e.g. a vehicle data bus, e.g. of the LIN- or CAN type or the like. In other words, said messages M14, M15 are preferably transmitted via a vehicle-internal, preferably wired, data communication, as compared to e.g. the WPAN-type wireless (preferably BLE 4.2 compatible) data transmission M16 between the devices 10a, 20a.

According to further preferred embodiments, and preferably after block B13, a further block B14 may be provided, which may e.g. comprise signaling the vehicle status to the user 11. According to further preferred embodiments, said block B14 of the exemplary process according to Fig. 17 may e.g. be identical or at least similar to block B11 of Fig. 16. Figure 18 exemplarily depicts a simplified state diagram according to further preferred embodiments.

According to further preferred embodiments, the PK System 1000 (Fig. 1) may or shall manage a Vehicle Lock Status with respect to APE, e.g. according to Fig.

18, e.g. with GUID: abd75c54-2a2b-4613-9736-a35a118e57c4.

State S_1 of Fig. 18 exemplarily depicts a locked state ("VehicleLockStatus == LOCKED") and an unlocked state S_2 ("VehicleLockStatus == UNLOCKED"). Either state may be assumed starting from an initial state S_0 via a respective state transition ST_0_1 , ST_0_2.

According to further preferred embodiments, the locked state S_1 may comprise at least one of the following states: a) S _ 1 _ 1 , corresponding to "T rigger_Locked", b) S_1_2, corresponding to "Auto_Locked". According to further preferred embodiments, when initially entering the locked state S_1 , the state S _ 1 _ 1 may be assumed, particularly if a condition "APE_Allowed==False" is satisfied.

According to further preferred embodiments, a state transition from the state

S _ 1 _ 1 to the state S_1_2 may be performed, cf. state transition ST_1_12, particularly if at least one, preferably both, of the following conditions is/are satisfied: d) TagslnUnlockZone == NONE, c2) APE_Allowed == True.

According to further preferred embodiments, the unlocked state S_2 may comprise at least one of the following states: a) S_2_1 , corresponding to "TriggerJJnlocked", b) S_2_2, corresponding to "Auto_Unlocked". According to further preferred embodiments, when initially entering the unlocked state S_2, the state S_2_1 may be assumed, particularly if a condition "APE_Allowed==False" is satisfied.

According to further preferred embodiments, a state transition from the state S_2_1 to the state S_2_2 may be performed, cf. state transition ST_2_12, particularly if at least one, preferably both, of the following conditions is/are satisfied: d1) TagslnUnlockZone == ANY, d2) APE_Allowed == True. According to further preferred embodiments, when determining whether at least one of the conditions d), d1) of the three preceding paragraphs is given, a predetermined time interval such as e.g. the last 1000 milliseconds (ms) may be considered. This facilitates considering case where e.g. the tag (e.g. in form of the smartphone 10a) moves to a new zone, particularly before the VehicleLockStatus changes.

Figure 19 schematically depicts a flow-chart which may, according to at least some further preferred embodiments, relate to a use case "triggered passive entry" (TPE), wherein the following entities may be involved: user 11, smartphone 10a, master 20a, and vehicle 20 or an entity 21 ' such as BCM 21 ' of Fig. 17, respectively.

According to further preferred embodiments, the PK System 1000 (Fig. 1) may or shall support TPE according to a least one of the following aspects.

According to further preferred embodiments, Triggered Passive Entry (TPE) is one available method for gaining vehicle access, which may be supported by the PK System 1000 (Fig. 1). According to further preferred embodiments, TPE may also be referred to as "PEPS" or "Cap Sensor Unlock" or "Button Press Unlock".

According to further preferred embodiments, a methodology related to TPE, e.g. in common language, may comprise one or more of the following aspects: a) - If the user activates the defined unlock trigger, and any authenticated tag with UNLOCK permission is localized within the UNLOCK zone, the vehicle 20 (Fig. 3) shall unlock the door/s. b) - If the user activates the defined lock trigger, and any authenticated tag with UNLOCK permission is localized within the UNLOCK zone, the vehicle 20 shall lock the door/s. c) Execution of a successful Triggered Passive Entry Lock/Unlock event according to rbd_pk_pf_sys_arch SequenceDiagram Triggered PE s a\\ result in a transition of rbd_pk_pf_sys_arch StateChart AccessArbitration.

According to further preferred embodiments, if an authenticated and connected tag with UNLOCK permission is localized as within the UNLOCK zone, a Triggered Passive Entry command from the user may (preferably shall always) result in a corresponding request from the master 20a to the vehicle interface 2T, regardless of any recent Automatic Passive Entry, Triggered Passive Entry, or Remote Keyless Entry event.

According to further preferred embodiments, If the PK System 1000 receives a request for access to a Rear Access Entry Zone (e.g., "Trunk") (e.g., "TPE Rear (Cargo) Access"), and any authenticated and connected tag with TRUNK permission is localized in the TRUNK zone; then the PK System shall or may send a TRUNK OPEN request, regardless of the current VehicleLockStatus. According to further preferred embodiments, a TPE Trunk request may take the form of req_Access(AccessType, AccessFunction, TagID); where AccessType = TPE, AccessFunction = Trunk.

According to further preferred embodiments, if the PK System 1000 receives a request for access to the Rear Access Entry Zone ("Trunk"), and there are not any authenticated and connected tags with TRUNK permission localised in the TRUNK zone; then the PK System 1000 shall take no further action.

According to further preferred embodiments, a TPE Request may comprise at least one of the following aspects: According to further preferred embodiments, a message format related to a TPE Request may be comparatively generic, where e.g. a specific vehicle implementation of the request and/or a response, e.g. via LIN (local interconnect network) or CAN (controller area network) may/shall be defined in a specification for that vehicle implementation.

According to further preferred embodiments, a TPE Unlock request may take the form of req_Access(AccessType, AccessFunction, TagID); where AccessType = TPE, AccessFunction = Unlock.

According to further preferred embodiments, a TPE Lock request may take the form of req_Access(AccessType, AccessFunction, TagID); where AccessType = TPE, AccessFunction = Lock.

According to further preferred embodiments, a TPE Trunk request may take the form of req_Access(AccessType, AccessFunction, TagID); where AccessType = TPE, AccessFunction = Trunk. According to further preferred embodiments, if the TriggeredPE_Cfg =

ENABLED, the master 20a may or shall support Triggered Passive Entry behaviour according to Fig. 19, e.g. with GUID: 01ca0945-143a-4dc4-9d9c- 93ec893f6778.

Returning to the flowchart of Fig. 19, the optional block B7' represents an exemplary use case according to which a known device comes into range, similar to block B7 of Figure 15, also cf. Fig. 13. Arrow a14 of Fig. 19 indicates a signal, particularly a trigger signal (which according to further preferred embodiments may also be referred to as "PE_Trigger(AccessZone)"), e.g. from user 11 (or smartphone 10a, respectively) to the vehicle 20 and/or its BCM 2T, respectively.

According to further preferred embodiments, particularly after receipt of said signal a14, the BCM 2T may send a message M17 to the master 20a, which may perform an optional process a15, e.g. of checking a tag location, preferably depending on access zone information which may have been comprised e.g. within said message M17.

According to further preferred embodiments, it the tag (e.g., in form of the smartphone 10a) is in the access zone (as e.g. determined in the process a15), the further optional block B15 is executed. According to further preferred embodiments, e.g. in block B15, the master 20a may request access to the vehicle, e.g. by using the message M18 which is sent from the master 20a to the BCM 2T. According to further preferred embodiments, the BCM 2T may process such access request, cf. dashed arrow a16. According to further preferred embodiments, the BCM 2T may send an access response message M19 to the master 20a, preferably after said step of processing a16.

According to further preferred embodiments, preferably after receipt of the access response message M19 at the master 20a, the master 20a may send a message M20 to the smartphone 10a, particularly a message M20 of the PkTagSvc_AuthText(VehicleStatus)-type. This way, e.g. the vehicle status may be signaled from the master 20a to the smartphone 10a in a secure manner.

According to further preferred embodiments, and preferably after block B15, a further block B16 may be provided, which may e.g. comprise signaling the vehicle status from the smartphone 10a to the user 11. According to further preferred embodiments, said block B16 of the exemplary process according to Fig. 19 may e.g. be identical or at least similar to block B11 of Fig. 16.

Figure 20 schematically depicts a flow-chart which may, according to at least some further preferred embodiments, relate to a use case "remote keyless entry" (RKE), wherein the following entities may be involved: user 11, smartphone 10a, master 20a, and vehicle or an entity 21 ' such as BCM 21 ', respectively.

According to further preferred embodiments, the PK System 1000 (Fig. 1) may or shall support RKE according to a least one of the following aspects.

According to further preferred embodiments, Remote Keyless Entry (RKE) is one available method for gaining vehicle access, which may be supported by the PK System 1000 (Fig. 1).

According to further preferred embodiments, a methodology related to RKE, e.g. in common language, may comprise one or more of the following aspects: a) - If the user presses a button on a connected and authenticated remote device (e.g., KEYFOB or Mobile Phone App on the smartphone 10a), the vehicle 20 may execute a command associated with that button press, b) buttons available to the user (e.g., on the GUI of the smartphone 10a) may include (but are not limited to): b1) Unlock, b2) Lock, b3) Trunk Open, b4) Global Window Open, b5) Global Window Close, b6) Panic Alarm.

According to further preferred embodiments, RKE may be supported by the PK System 1000 (Fig. 1); where RKE is defined as a deliberate user action, resulting in a request for vehicle access functionality.

According to further preferred embodiments RKE shall/may be supported by the (smart)Phone 10a, e.g. acting as a Tag.

According to further preferred embodiments RKE shall/may be supported by the keyfob as Tag. According to further preferred embodiments, a valid and authenticated Remote Keyless Entry command from the User 11 (Fig. 20) shall (preferably always) result in a corresponding request from the Master 20a to the BCM 21', e.g. preferably taking priority over any recent Automatic Passive Entry, Triggered Passive Entry, or Remote Keyless Entry event.

Range: According to further preferred embodiments, RKE functions may be initiated with preferably 100% reliability from a single user activation request with a line of sight radius from 0 to 30 meters (m) measured from a center of the vehicle 20.

System Response Time: According to further preferred embodiments, if the master 20a has an active connection to the Tag 10a, the master 20a may or shall send an RKE request to the vehicle communication interface 2T, preferably within 500 milliseconds (ms) of user activation of the request.

Communication Method: According to further preferred embodiments, (preferably all) RKE commands may or shall be transmitted from the Tag 10a (smartphone 10a and/or keyfob) to the master 20a in the form of a connected message "PkT agSvc.AuthT ext(RKE)".

According to further preferred embodiments, the PK System 1000 (Fig. 1) shall support Remote Keyless Entry, e.g. according to Fig. 20, wherein e.g. GUID: 5ebb5304-7746-430a-9f32-9202a166edb5.

Payload: According to further preferred embodiments, in connected message PkTagSvc.AuthText(RKE), only the RKE_Function shall be transmitted.

RKE_Function: According to further preferred embodiments, there shall be a 1- byte identifier, RKE_Function, packaged in the RKE command from the Tag 10a to the Master 20a , which identifies the type of vehicle access functionality being requested by the user 11.

According to further preferred embodiments, the RKE_Function shall have the following enumerations: 0x00 - No Action, 0x01 - Unlock, 0x02 - Lock, 0x03 - Trunk Release, 0x04 - Global Open Windows, 0x05 - Global Close Windows, 0x06 - Panic Alarm (e.g., flash lights and sound horn), 0x07 to OxFF - Reserved (No Action).

Security: According to further preferred embodiments, the Tag 10a may or shall generate a random, Tag-Vehicle Unique, preferably 16-byte AES (advanced encryption standard) key e.g. usable for a RKE_MAC calculation, which may e.g. be shared with the master 20a, preferably during every authentication event, e.g. as RKE_AESKey. According to further preferred embodiments, SHA-256 (Secure Hash Algorithm 2) may be used to generate a preferably 32-byte output from e.g. 27-byte input ( TID + VI D + RKE_RC + RKE_Function).

RKE Command Acceptance: According to further preferred embodiments, the master 20a shall accept an RKE command from a Tag 10a (preferably only) if all fields in the RKE_String match the expected values. According to further preferred embodiments, the master 20a may accept an RKE command from a Tag only if the RKE_RC is in the acceptable range of: (RKE_RC_prev : RKE_RC_prev + RKE_RC_window). According to further preferred embodiments, the RKE_RC may be incremented modulo OxFFFFFFFF (unit32) on each button press (user RKE request, i.e. function activation by user on the GUI 10a'), where according to further preferred embodiments, the command is preferably only sent after the RKE_RC has been incremented.

According to further preferred embodiments, an RKE Request may comprise at least one of the following aspects: According to further preferred embodiments, a message format related to an RKE Request may be comparatively generic, where e.g. a specific vehicle implementation of the request and/or a response, e.g. via LIN (local interconnect network) or CAN (controller area network) may/shall be defined in a specification for that vehicle implementation.

An RKE request shall take the form of req_Access(AccessType, AccessFunction, TagID); where AccessType = RKE, AccessFunction = RKE_Function.

Returning to the flowchart of Fig. 20, the user may select a function, i.e. by pressing a (virtual) button on the GUI 10a' of the smartphone 10a, cf. arrow a17, which may, according to further preferred embodiments, be considered as an external trigger. According to further preferred embodiments, particularly after receipt of said trigger a17, the smartphone 10a may send a message M21 via wireless WPAN connection, e.g. BLE 4.2, to the master 20a, e.g. using a "PkT agSvc_AuthT ext(RKE)" function.

According to further preferred embodiments, particularly after receipt of said message M21, the master 20a may process the message M21, particularly to verify an RKE validity, cf. the arrow a18 which process a18 may also be referred to as "VerifyRKEValidityO" according to further preferred embodiments.

After that, an optional block B17 may be executed, particularly if said process a18 yields that said RKE request of message M21 is valid.

According to further preferred embodiments, the master 20a may send an access request for RKE, e.g. in form of the message M22, e.g. over LIN and/or CAN and/or another, preferably at least partly vehicle-internal, communication bus, to the BCM 21'. According to further preferred embodiments, said RKE access request M22 may comprise at least one of: information related to RKE, information related to an access function, information related to an ID of the tag 10a.

According to further preferred embodiments, the BCM 21' may process said RKE access request M22, cf. the dashed arrow a19, and may, preferably after said processing a19, send an RKE access response message M23 to the master 20a, preferably again over LIN and/or CAN or the like. According to further preferred embodiments, said RKE access response message M23 may comprise information on a vehicle lock status.

According to further preferred embodiments, preferably after receipt of the response message M23 at the master 20a, the master 20a may send a message M24 (i.e., via BLE 4.2) to the smartphone 10a, particularly a message M24 of the PkTagSvc_AuthText(VehicleStatus)-type. This way, e.g. the vehicle status may be signaled from the master 20a to the smartphone 10a in a secure manner.

According to further preferred embodiments, and preferably after block B17, a further block B18 may be provided, which may e.g. comprise signaling the vehicle status from the smartphone 10a to the user 11. According to further preferred embodiments, said block B18 of the exemplary process according to Fig. 20 may e.g. be identical or at least similar to block B11 of Fig. 16.

Figure 21 schematically depicts a flow chart according to further preferred embodiments, wherein said block B1 (cf. e.g. the "Block_UnknownDeviceConnect" block B1 of Fig. 12) is detailed.

According to further preferred embodiments, in order to connect to a new vehicle 20 for the first time, the smartphone 10a shall send a VINAdvertisement(), cf. the message M25 of Fig. 21 , and also cf. the advertisement message AM of Fig. 1.

According to further preferred embodiments, in the event that a calculated Proximity UUID for a VI N Advertisement iBeacon conflicts with a BluetoothBaseUUID (XXXXXXXX-0000-1000-8000-00805F9B34FB), the LSB of the calculated Proximity UUID may be incremented by 1, making the BaseUUID of the Proximity UUID equal to XXXXXXXX-0000-1000-8000-00805F9B34FC.

According to further preferred embodiments, the smartphone 10a may advertise the VINAdvertisementQ M25 (i.e., send repeatedly (e.g., every 100 ms) the advertisement message M25 related to a VI N) until either the master 20a initiates a connection, cf. message M26 of Fig. 21 , or after a timeout of VINAdvPeriod (ms) expires, cf. arrow a20, in which case the smartphone 10a may provide a failure notification to the user 11 via the smartphone's user interface (e.g., GUI 10a'), cf. the arrow a21 in the second section B19_2 of the block B19.

Once the master 20a initiates a connection, cf. message M26 of the first section B19_1 of block B19, e.g. after an optional preparation of an initial BLE connection, cf. the dashed arrow a22, block B20 may be executed, which represents a simplified BLE service discovery process. For this service discovery process B20, several BLE service discovery messages M27a, M27b may be exchanged, wherein more specifically, message M27a represents a service discovery, and message M27b represents a service information.

After block B20, an optional check for plain text attributes may be performed by the master 20a, cf. arrow a23. According to further preferred embodiments, the PK System 1000 (Fig. 1) shall support the Connection to an unknown device according to e.g., Fig. 21. e.g. with GUID: ccf9fa9a-ad50-468d-ab17-bd00e60c58c7.

Figure 22 schematically depicts a flow chart according to further preferred embodiments, wherein e.g. said block B2_1_1 (cf. e.g. the " Block_AuthConnection" block B1 of Fig. 12) is detailed.

According to further preferred embodiments, to begin an authentication, the master 20a may send a message M28, which may e.g. be referred to as "PkTagSvc_PlainText(AUTH_START)" to the smartphone 10a.

After this, an optional block B21 may follow, which represents a protocol for a connection setup, e.g. as defined in a security library, that e.g. uses a current established Bluetooth connection between the devices 10a, 20a and which is not further detailed. As an example, block B21 may be used to perform and/or complete, cf. arrow a24 an authentication of the smartphone 10a with respect to the master 20a.

According to further preferred embodiments, if the connection setup process (as an example also referred to as "CA_ConnectionSetup process"), e.g. using block B21 , is completed, the smartphone 10a may send a message M29, which may e.g. also be referred to as "PkTagSvc_PlainText(TAG_DONE)" to the master 20a.

According to further preferred embodiments, if the CA_ConnectionSetup process (block B21) is completed successfully, the master 20a may mark the Authentication as OK, cf. the dashed arrow a25 of section B22_1 of block B22.

According to further preferred embodiments, if the CA_ConnectionSetup process B21 has an authentication failure (e.g., for the first time, detected by the master 20a, cf. section B22_2 of block B22), the Block_AuthConnection (i.e., the complete process according to Fig. 22) may restart from the top, cf. block B22_2a. According to further preferred embodiments, after a second failure, the master 20a shall disconnect from the phone, cf. the dashed arrow a26. According to further preferred embodiments, if the CA_ConnectionSetup process has an authentication failure (first time, detected by the smartphone 10a, cf. section B22_3), the smartphone 10a may send a message M30 to the master 20a, e.g. a message M30 of the type "PkTagSvc_PlainText(AUTH_FAIL)", indicating the authentication fail to the master 20a, and the Block_AuthConnection (i.e., Fig. 22) may restart from the top, cf. block B22_3a. After a second failure, cf. arrow a27, the smartphone 10a may disconnect from the master 20a.

According to further preferred embodiments, the PK System 1000 (Fig. 1) shall support the Authentication of the Connection to the phone 10a according to e.g. Fig. 22, wherein e.g. GUID: 147144d5-d68f-423c-afe0-e5a987d0e78a.

Figure 23 schematically depicts a flow chart according to further preferred embodiments, wherein e.g. said block B_2_1_3 of Fig. 12 is detailed.

According to further preferred embodiments, the PK System 1000 (Fig. 1) shall support Bonding of the smartphone 10a connection according to e.g. Fig. 23, wherein e.g. GUID: 77a8871e-acdd-4aa9-bbd8-75b926e54044.

According to further preferred embodiments, the exemplary bonding process of Fig. 23 comprises at least one of the following elements and/or actions: a) master 20a sends a BLE_Bonding() message M31 to smartphone 10a, b) smartphone 10a signals to user 11 Bonding Request M32, e.g. via a phone app, via a GUI 10a', c) user 11 approves of bonding, i.e. "sending" a bonding approval input M33 to smartphone 10a, i.e. via GUI 10a' and/or the phone app, d) smartphone sends a BLE_Bonding() message M34 to master 20a, e) smartphone may send a BondingComplete() message M35 to user 11 , i.e. via GUI 10a' and/or the phone app, to indicate completion of the bonding process.

Figure 24 schematically depicts a flow chart according to further preferred embodiments, wherein e.g. said block B3 ("Connection to a known device") of Fig. 13 is detailed.

According to further preferred embodiments, if the phone app is in a background mode, and e.g. not connected to a master 20a, cf. section B23_1 of block B23 of Fig. 24, the smartphone 10a may send one or more Localisation() advertisements M36, preferably repeatedly with period PMSIowLocAdvlnternal.

According to further preferred embodiments, a Proximity UUID field for LocalisationAdvertisement() may be equal to the CharacteristicJJUID of PlainText.

According to further preferred embodiments, there shall be no Advertising Payload field in the LocalisationAdvertisement() message M36.

According to further preferred embodiments, if the phone app is in a foreground mode, cf. section B23_2 of Block B23, the smartphone 10a may send VINAdvertisement() messages M37 (also cf. the advertisement message AM of Fig. 1 , 9), preferably repeatedly with a period PMSFastLocAdvlnternal.

According to further preferred embodiments, the master 20a may scan for advertisements M36, M37 as outlined below.

According to further preferred embodiments, if the master 20a hears a LocalisationQ advertisement M36 from a smartphone 10a with a Private Device Address, it shall attempt to resolve that address, cf. arrow a28, using the locally stored IRK's, according to the Bluetooth specification version 4.2, [Vol 3, Part C] §1.3.2.3, "Private Device Address Resolution", and request a connection, cf. message M36a.

According to further preferred embodiments, if the master 20a hears a VINAdvertisement(VIN) M37, i.e. containing the (preferably unique) VIN of that vehicle 20 (e.g., in form of the hash value HV which may form part of the device data DD according to further preferred embodiments), it may request a connection, cf. message M37a. Optionally, preparation of an initial BLE connection may be performed at the master 20a, cf. arrow a29.

According to further preferred embodiments, any other advertisements heard by the master 20a, and not meeting the above criteria may be filtered out and ignored. According to further preferred embodiments, once a connection is established, i.e. after receipt of message M37a at the smartphone 10a, the master 20a may perform a service discovery, cf. block B24, on the smartphone 10a, and e.g. check, cf. the dashed arrow a23, for the "PlainText" attribute, also cf. the row "PlainText" of table T8 above. Insofar, the elements B24 and a23 of Fig. 24 correspond with the elements B20 and a23 of Fig. 21.

According to further preferred embodiments, the connection shall be established with a shortest possible connection interval supported by the smartphone 10a, in order to facilitate maximum throughput of data (and hence, speed), especially in the authentication phase.

According to further preferred embodiments, the PK System 1000 (Fig. 1) shall support the Connection to a known device according to e.g. Fig. 24, wherein e.g. GUID: 10b0d375-adf0-4b90-95b1-a05aaab3e729.

The principle according to the embodiments at least sometimes enables one or more of the following aspects and/or advantages: a) well-defined method for a digital key enabled smart device 10a to communicate with vehicles 20 and other BLE enabled devices 200, 20a,

21 , 2T, e.g. that it has the key to unlock, b) efficient prevention of tracking c) Security and encryption of the connection are maintained, d) Low latency of setup of connection e) Ease of vehicle check if a certain device 10a is permitted to unlock it f) Unable to track users 11 or vehicles 20 from their BLE transmissions g) Low current consumption of the vehicle side devices 200, 20a, 21 , 2T h) enables various use cases, e.g.: o Unlocking/locking and starting the vehicle 20 passively only with smart device 10a o Unlocking, locking, opening trunk, windows, remote start using only smart device 10a with app for user interface (e.g., GUI 10a'), "offline" (i.e., no other data connection, particularly no Internet connection) over BLE o Sharing vehicle details to smartphone 10a "offline" using BLE

Claims

1. Method of operating a first device (100; 100a), wherein said first device (100; 100a) is configured to wirelessly transmit data to a second device (200), preferably using a wireless personal area network, WPAN, communications technology, wherein said method comprises: constructing (300) a message (AM) comprising a data field (DF) suitable for receiving a universally unique identifier, UUID, , providing (302) device data (DD) in said data field (DF), transmitting (304) said message (AM) to said second device (200).

2. Method according to claim 1 , wherein said device data (DD) is different from at least one, preferably all, UUID values associated with said first device (100; 100a) and/or said second device (200).

3. Method according to claim 1 or 2, wherein said device data (DD) is determined dynamically, i.e. during a runtime of the first device (100; 100a), preferably depending on data processed by said first device (100; 100a) and/or on data entered by a user (11 ) of said first device (100; 100a) to said first device (100; 100a) and/or to a target system (10a) for said first device (100; 100a).

4. Method according to at least one of the preceding claims, wherein said device data (DD) comprises and/or characterizes first data (D1), wherein said first data (D1) is associated with at least one of: said first device (100), said second device (200), a target system (10) for said first device (100), a target system (20) for said second device (200), wherein preferably said target system (10) for said first device (100) is a mobile device such as e.g. a mobile phone, particularly smart phone, or a tablet computer, wherein preferably said target system (20) for said second device (200) is a control unit for a vehicle, preferably a control unit for a car, wherein preferably said first data (D1) characterizes or is a vehicle identification number, VIN.

5. Method according to at least one of the preceding claims, further comprising: determining (300) a random number (RN), determining (302) a hash value (HV) depending on said random number (RN) and on first data (D1 ) or on said first data (D1 ), wherein optionally at least a part of said device data (DD) comprises at least a portion of said hash value (HV) and/or of said random number (RN), wherein preferably said method further comprises: using at least one of the following hash functions (HF) for determining (302) said hash value (HV): SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224,

S HA-512/256.

6. Method according to claim 5, said step of determining (302) said hash value (HV) further comprising: combining (302a) said random number (RN) with said first data (D1) to obtain a combination (comb), applying (302b) a or said hash function (HF) to said combination (comb) to obtain a hash function output (HO), using (302c) at least a portion (HO') of said hash function output (HO) as said hash value (HV), wherein preferably said portion (HO') comprises twelve bytes, preferably the twelve most significant bytes of said hash function output (HO).

7. Method according to at least one of the claims 5 to 6, wherein said random number (RN) comprises four bytes.

8. Method according to at least one of the preceding claims, wherein said WPAN communications technology is based on a) the Bluetooth Low Energy, BLE, specification version 4.2 and/or on b) a specification at least partly compatible with the BLE specification version 4.2, particularly the Bluetooth Core Specification version 5.1.

9. Method according to at least one of the preceding claims, wherein said message (AM) is an advertising message (AM), preferably a Bluetooth advertising message (AM) according to the Bluetooth Low Energy, BLE, specification version 4.2 and/or above, wherein preferably said data field (DF) suitable for receiving a universally unique identifier, UUID, comprises a length of 128 bit, wherein preferably said device data (DD) comprises 128 bit.

10. First device (100; 100a), wherein said first device (100; 100a) is configured to wirelessly transmit data to a second device (200), preferably using a wireless personal area network, WPAN, communications technology, wherein said first device (100; 100a) is configured to perform the method according to at least one of the claims 1 to 9.

11. Method of operating a second device (200), wherein said second device (200) is configured to wirelessly receive data from a first device (100; 100a), particularly from a first device (100; 100a) according to claim 10, preferably using a wireless personal area network, WPAN, communications technology, wherein said method comprises: receiving (400) a message (AM) comprising device data (DD) from said first device (100; 100a), extracting (402) at least a portion of said device data (DD) from a data field (DF) of said message (AM) which is suitable for receiving a universally unique identifier, UUID, and evaluating (404) said extracted device data (DD).

12. Second device (200) configured to perform the method according to claim 11.

13. A computer program (PRG) comprising instructions which, when the program (PRG) is executed by a computer (102), cause the computer (102) to carry out the method according to at least one of the claims 1 to 9 and/or 11.

14. A computer-readable storage medium (SM) comprising instructions (PRG’) which, when executed by a computer (102), cause the computer (102) to carry out the method according to at least one of the claims 1 to 9 and/or 11.

15. A data carrier signal (DCS) carrying and/or characterizing the computer program (PRG) of claim 13.

16. System (1000) comprising at least one first device (100; 100a) according to claim 10 and at least one second device (200) according to claim 12.

17. Use (2000) of the method according to at least one of the claims 1 to 9 and/or 11 and/or of the first device (100) according to claim 10 and/or of the second device (200) according to claim 12 and/or of the computer program (PRG) according to claim 14 and/or of the system (1000) according to claim 16 for at least one of: a) transmitting (2001) one or more messages (AM), particularly advertising messages (AM), preferably Bluetooth advertising messages (AM) according to the Bluetooth Low Energy, BLE, specification version 4.2 and/or above, wherein preferably a data field (DF) of said advertising message (AM) for receiving a universally unique identifier, UUID, according to the BLE specification 4.2 is used for transporting device data (DD), prefererably other than a UUID value, from said first device (100;

100a) to said second device (200), b) preventing (2002) tracking of said first device (100), c) improving (2003) privacy protection of said first device (100), d) establishing (2004) vehicle ownership, particularly when using said second device (200) in said vehicle (20) as a target system, e) gaining (2005) access to a vehicle (20), particularly when using said second device (200) in said vehicle (20) as a target system, preferably for automatic passive entry, APE, (2005a) to said vehicle (20) and/or for triggered passive entry, TPE, (2005b) to said vehicle (20), and/or for remote keyless entry, RKE, (2005c) to said vehicle (20), f) unlocking (2006) a vehicle (20), particularly when using said second device (200) in said vehicle (20) as a target system, g) sending (2007) data, particularly user data associated with said first device (100) and/or with a user of said first device (100), particularly to said second device (200), h) establishing (2008) connection to an unknown device, i) authenticating (2009) a connection to a device (200), j) replacing (2010) a UUID value in a data field (DF) of an advertising message (AM) with other data, preferably device data (DD), k) transmitting (2011) customized advertising messages (AM) to the second device (200), I) transmitting (2012) data (DD) received from a user (11 ) of said first device (100; 100a) and/or from a user (11 ) of a target system (10a) of said first device (100; 100a) to the second device (200), particularly instead of transmitting a UUID value to said second device (200).