DEVICES AND METHODS FOR WIRELESS COMMUNICATION

Abstract

The present disclosure relates to a method (210) for establishing a communication session, wherein the method (210) comprises: capturing a user-triggered event (222) at a first communication device (200); generating a first message (232) according to the iBeacon communication protocol by the first communication device (200) in response to the capture of the user-triggered event (222), wherein the first message (232) comprises: identification information (236) representative of the first communication device (200), random information (238), and event-related information (234) representative of the user-triggered event (222); and transmitting the first message (232) by the first communication device (200) according to the iBeacon communication protocol to a second communication device (242).and receiving a request to establish a communication session according to the Bluetooth Low Energy (BLE) protocol between the first communication device (200) and the second communication device (242);

Description

Technical field

[0001] The present disclosure relates generally to a method for establishing a communication session between two communication devices and to communication devices configured to perform the method for establishing the communication session. background

[0002] In general, various technologies and standards have been developed for wireless communication. One protocol widely used for short-range communication is Bluetooth (BT), which relies on the use of radio frequencies for transmission and reception over short distances. With version 4.0 of the Bluetooth standard for wireless networks, Bluetooth Low Energy (BLE) was introduced, a modified communication protocol that offers lower power consumption compared to previous Bluetooth versions. Within the BLE framework, iBeacon technology was developed as an advertising protocol for proximity detection and location-based services. BLE and iBeacon are therefore widely used in modern devices, making improved wireless communication strategies in the BLE and iBeacon context particularly relevant for a variety of services and applications.

[0003] US 2023 / 0217544 A1 describes a rescue system used for search and rescue operations. In search and rescue scenarios, mobile phones can transmit low-power location signals. Rovers detect these signals while exploring hazardous terrain. The mobile phones can use an app that transmits signals intermittently, and the rovers process the received data to support the rescue effort.

[0004] US 9936466 B1 describes methods and systems for managing the data transmission of RF-enabled tags.

[0005] CN 104053155 A describes a data protection procedure and system for an iBeacon base station as well as a control unit and a server for data protection of the iBeacon base station. Brief description of the drawings

[0006] In the drawings, identical reference numerals generally refer to the same parts in the different views. The drawings are not necessarily to scale but primarily serve to illustrate the principles of the invention. The following description details various aspects of the invention with reference to the following drawings, in which Fig. 1 shows a communication circuit in a schematic representation according to various aspects; Fig. 2A and Fig. 2B Show a communication device in a schematic representation according to various aspects; Fig. 3A and Fig. 3B show an exemplary implementation of the communication device in a schematic representation according to various aspects; Fig. 3C shows a switching operation of a switchable element of the communication device in a schematic representation according to various aspects; Fig. 4A Event-related information that is representative of a user-triggered event, shown in a schematic representation according to various aspects; Fig. 4B shows random information in a schematic representation according to different aspects; Fig. 4C Identification information representative of a communication device, shown in a schematic representation according to various aspects; Fig. 5A shows a communication device in a schematic representation according to various aspects; Fig. 5B shows the communication device with an installed application in a schematic representation according to various aspects; Fig. 6A shows a schematic communication flow between a first communication device and a second communication device according to various aspects; and Fig. Figure 6B shows a schematic communication flow between a portable safety button and an application according to various aspects. Description

[0007] The following detailed description refers to the accompanying drawings, which illustrate specific details and aspects in which the invention can be practiced. These aspects are described in sufficient detail to enable those skilled in the art to practice the invention. Other aspects can be used, and structural, logical, and electrical modifications can be made without deviating from the scope of the invention. The various aspects are not necessarily mutually exclusive, as some aspects can be combined with one or more other aspects to form new aspects. Various aspects are described in connection with methods, and various aspects are described in connection with devices (e.g., a first communication device, a second communication device, etc.).However, it is understood that aspects described in connection with processes may similarly apply to the devices and vice versa.

[0008] In general, Bluetooth (BT) is an established technology for short-range communication and small networks. BT enables communication without an internet connection and provides a cost-effective and energy-efficient framework for data exchange between devices located in close proximity. A further development of BT technology is Bluetooth Low Energy (BLE), also known as Bluetooth Smart, which was introduced with version 4.0 of the Bluetooth wireless network standard and further developed in subsequent versions (e.g., 4.1, 4.2, 5.0, 5.1, 5.2, and 5.3).

[0009] The BLE protocol is designed for efficient operation in power-limited environments, typical for modern portable devices, which are usually battery-powered and therefore require low power consumption. BLE has two primary communication modes: broadcasting and links. In broadcasting mode (connectionless), one device (the broadcaster) transmits data to all nearby BLE-enabled devices (observers). Links, on the other hand, involve bidirectional data transmission between two devices, with periodic transmissions in both directions. Both broadcasting and links adhere to the Generic Access Profile (GAP) specification.

[0010] In BLE connections, the participating devices assume different roles. A first BLE-enabled device sends advertising packets to enable discovery and connection with other BLE-enabled devices. A second BLE-enabled device scans the available communication channels to detect the advertising packets and establishes a connection as soon as a suitable packet is found. After the connection is established, either of the two BLE-enabled devices can assume the role of client or server. The client typically accesses resources on the server, and the server provides data to the client. Data exchange between clients and servers usually occurs via a request-response mechanism.

[0011] In the context of BLE (Bluetooth Low Energy), the iBeacon communication protocol was developed as a technology for use in BLE-enabled devices. iBeacon technology is an advertising protocol designed for proximity detection and proximity-based services and applications. In short, an iBeacon device (also simply called a "beacon" or "iBeacon") transmits a unique identifier, known as a Universally Unique Identifier (UUID), along with additional data such as a major ID and a minor ID, to nearby BLE-enabled devices (e.g., a smartphone, a tablet, etc.). A BLE-enabled device receiving the iBeacon advertising packet can use the UUID, major ID, and minor ID to identify specific iBeacon devices. The BLE-enabled device can then determine its proximity to the iBeacon device (based on the strength of the received signal) and perform appropriate actions, such as...Displaying a push notification, alerting a user, launching an application, providing location-based information, and the like.

[0012] Although BLE and iBeacon technologies are widely used in modern applications, they do have limitations. For example, while BLE-enabled devices are efficient in their connectivity, they can consume a lot of battery power and require a continuously running paired application, especially on iOS platforms. This continuous operation can be inconvenient. On the other hand, while iBeacon technology offers effective proximity detection and triggers actions, it lacks feedback mechanisms, meaning that after repeated detections, it can be ignored by the operating system (OS) of the BLE-enabled device, which compromises its reliability.

[0013] The present disclosure relates to a strategy for establishing a communication session between two wireless communication devices that addresses the aforementioned weaknesses by combining the strengths of iBeacon and BLE technologies to create a dynamic and energy-efficient system that ensures reliable communication and feedback mechanisms. In particular, the present disclosure is based on the realization that instead of exclusively using a single technology (i.e., only iBeacon or only BLE), a hybrid approach can be provided in which the initial "discovery" utilizes the iBeacon capabilities, and a communication session is subsequently conducted using the BLE capabilities.

[0014] Hybrid communication thus combines the advantages of the iBeacon protocol, such as background detection, energy efficiency, and simple beacon configuration, with the possibility of a feedback mechanism during the BLE communication session. The approach proposed here therefore introduces a dynamic configuration for a device or application that utilizes both the iBeacon protocol and BLE connectivity. To illustrate, in the iBeacon protocol, communication is typically unidirectional, with the iBeacon transmitting data to the BLE-enabled device but not receiving or collecting data from it. Aspects of this disclosure are therefore based on the understanding that the strengths of the iBeacon protocol regarding connection establishment can be combined with the strengths of the BLE protocol for the communication session itself, enabling bidirectional data exchange.

[0015] In particular, the approach proposed here is provided in the context of iBeacon devices that can respond to a user action and report the occurrence of that action to a BLE-enabled device. For example, the iBeacon device can detect the occurrence of a user-triggered event and report it by including event-related information in the initial iBeacon message (along with the identification information) and then continuing to communicate with the BLE-enabled device during the BLE communication session. The proposed strategy allows the BLE-enabled device to be informed of the user-triggered event quickly and efficiently (using iBeacon technology) while simultaneously enabling a feedback mechanism between the iBeacon device and the BLE-enabled device during the BLE communication session.

[0016] Furthermore, according to the approach proposed here, the iBeacon message reporting the user-triggered event contains random information in addition to the identification and event-related information (for example, a random component that varies randomly between different iBeacon messages). The presence of random information prevents the BLE-enabled device receiving the iBeacon message from simply ignoring it without taking appropriate action. In the context of reporting user-triggered events, it is common for the operating system of a BLE-enabled device to not respond to an iBeacon message because previous messages from that iBeacon device did not contain relevant information and did not report an event (since no event occurred at that time).The random component ensures that the BLE-enabled device processes every iBeacon message from the iBeacon device, thereby improving the reliability of communication and ensuring that the user-triggered event is handled appropriately on the BLE-enabled device.

[0017] The proposed configuration uses the iBeacon protocol with the Major ID as the primary identifier and the Minor ID to incorporate randomness and communicate events (e.g., click counts). This approach ensures continuous notification by the operating system and enables an immediate response from the paired application. After detection, the application can establish a BLE connection for feedback and further interaction.

[0018] From the perspective of the iBeacon device, a procedure for establishing a communication session is provided according to various aspects, the procedure comprising: detection of a user-triggered event at a first communication device; generation of an initial message by the first communication device in accordance with the iBeacon communication protocol in response to the detection of the user-triggered event, wherein the initial message comprises: identification information representative of the first communication device, random information, and event-related information representative of the user-triggered event; transmission of the initial message by the first communication device to a second communication device in accordance with the iBeacon communication protocol;and receiving a request to establish a communication session according to the Bluetooth Low Energy (BLE) protocol between the first communication device and the second communication device on the first communication device.

[0019] A computer program product can be provided which includes instructions which, when the program is executed by a computer, cause the computer to perform the procedure for establishing a communication session as described in the preceding paragraph.

[0020] Depending on various aspects, a suitable communication device can be provided that is configured for wireless communication (e.g.an iBeacon device), wherein the communication device includes a processor configured to: detect a user-triggered event at the communication device; in response to the detection of the user-triggered event, generate an initial message in accordance with the iBeacon communication protocol, the initial message comprising: identification information representative of the communication device, random information, and event-related information representative of the user-triggered event; initiate transmission of the initial message to a second communication device in accordance with the iBeacon communication protocol; and receive a request to establish a communication session between the communication device and the second communication device in accordance with the Bluetooth Low Energy (BLE) protocol.

[0021] From the perspective of the BLE-enabled device, a procedure for establishing a communication session is provided according to various aspects, the procedure comprising: receiving an initial message according to the iBeacon communication protocol from a first communication device to a second communication device, wherein the initial message comprises: identification information representative of the first communication device, random information, and event-related information representative of a user-triggered event on the first communication device; and issuing a request by the second communication device in response to the initial message to the first communication device to establish a communication session according to the Bluetooth Low Energy (BLE) protocol between the first communication device and the second communication device.

[0022] A computer program product can be provided, wherein the computer program product includes instructions which, when the program is executed by a computer, cause the computer to perform the procedure for establishing a communication session described in the preceding paragraph.

[0023] Depending on various aspects, a suitable communication device configured for wireless communication (e.g., a BLE-enabled device) can be provided, wherein the communication device includes a processor configured to: receive an initial message according to the iBeacon communication protocol from a first communication device, wherein the initial message includes: identification information representative of the first communication device, random information, and event-related information representative of a user-triggered event on the first communication device; and, in response to the initial message, issue a request to the first communication device to establish a communication session according to the Bluetooth Low Energy (BLE) protocol between the first communication device and the communication device.

[0024] In some aspects, the procedure from the perspective of the iBeacon device and the procedure from the perspective of the BLE-enabled device together define a procedure for establishing a communication session between the first communication device and the second communication device.

[0025] After the communication session is established, the first and second communication devices can be configured to communicate according to the BLE protocol. In this context, the second communication device can transmit feedback information to the first communication device during the BLE communication session, and the first communication device can receive this feedback information. The proposed approach thus enables a dynamic and adaptive mechanism that allows bidirectional communication and the transmission of information to the first communication device.

[0026] The communication strategy proposed here is particularly relevant in the context of wearable safety buttons. As is generally known, a "wearable safety button" is a small, portable device (e.g., a wearable) configured to allow a user to quickly call for help in an emergency. The user can press the safety button to trigger a response to a security-related situation. Pressing the safety button can, for example, trigger a silent alarm, initiate a call to an emergency service (e.g., the police, a hospital, the fire department, a private security company, etc.), inform predefined emergency contacts, and / or similar actions. A "wearable safety button" may also be referred to as an "alarm button," "action button," "panic button," "emergency button," or "emergency alarm device."

[0027] In the context of the present disclosure, the wearable safety button can be the first communication device to transmit user-related information using the iBeacon message with the random component. In this respect, the user-triggered event can include pressing the safety button, indicating an emergency situation for the user. The approach proposed here can thus ensure that the call for help is not ignored by the BLE-enabled device (e.g., a smartphone containing an application configured to perform the corresponding action) thanks to the random information contained in the iBeacon message. Furthermore, the BLE communication session can allow the BLE-enabled device to inform the user about the actions taken (e.g., "Alarm triggered," "Help is on the way," "Call to the police initiated," etc.) via feedback to the wearable safety button.

[0028] Therefore, the following discussion will focus specifically on the scenario where the communication device transmitting the iBeacon message is a portable security button, and may use terminology specific to the context of portable security buttons. However, it is understood that the communication strategy proposed here is not limited to portable security buttons and that establishing a communication session using the hybrid approach proposed here can be used for any suitable communication device where the combination of iBeacon and BLE features may be advantageous.

[0029] The term "BLE-enabled" is used here in reference to a device that is configured to perform communication according to the BLE communication protocol. For example, a "BLE-enabled" device may include a communication circuit configured to allow the transmission and / or reception of messages according to the BLE communication protocol (see also Fig. 1) and is configured to process messages according to the BLE communication protocol (e.g., configured to extract information from a BLE message and / or prepare a BLE message for transmission via the communication interface). A "BLE-enabled" device can therefore be configured to perform wireless communication according to Bluetooth technology (over radio waves), and it can be configured to perform communication according to the set of rules defined by the BLE protocol.

[0030] In this context, references herein to entities configured according to Bluetooth Low Energy, such as a BLE-enabled device, a BLE communication session, a BLE message, etc., refer to entities configured according to the set of rules and instructions defined by any Bluetooth standard that supports BLE, whether it already exists or has yet to be formulated. Examples of Bluetooth standards that support BLE include Bluetooth 4.0 Low Energy (2010), Bluetooth 4.1 (2013), Bluetooth 4.2 (2014), Bluetooth 5.0 (2016), Bluetooth 5.1 (2019), Bluetooth 5.2 (2020), Bluetooth 5.3 (2021), and Bluetooth 5.4 (2023).

[0031] The term "iBeacon" is used here in reference to a device that is configured to enable communication according to the iBeacon communication protocol. For example, an "iBeacon" device may include a communication circuit configured to enable the transmission and / or reception of messages according to the iBeacon communication protocol, and configured to process messages according to the iBeacon communication protocol (e.g., configured to extract information from an iBeacon message and / or prepare an iBeacon message for transmission via the communication interface). Thus, an "iBeacon" device may be configured to perform wireless communication according to Bluetooth technology (over radio waves), and it may be configured to perform communication according to the set of rules defined by the iBeacon protocol.

[0032] In this context, references herein to iBeacon-configured units, such as an iBeacon device, an iBeacon message, etc., refer to units configured according to the rules and instructions defined by any standard that supports iBeacon, whether that standard already exists or has yet to be formulated. An example of this is the document "Getting Started with iBeacon Version 1.0" dated June 2, 2014, published by Apple Inc.

[0033] In general, iBeacon is an evolution of BLE. Therefore, a communication circuit configured for communication according to the iBeacon communication protocol can also be suitable for communication according to the BLE communication protocol. An iBeacon device can thus generally be considered a BLE-enabled device. Similarly, a communication circuit configured for communication according to the BLE communication protocol can also be configured for communication according to the iBeacon communication protocol. A BLE-enabled device can therefore also be configured for communication according to the iBeacon protocol.

[0034] Before describing the specific features of the adapted approach to setting up a communication session, the general aspects of the communication circuit for use in a communication device will be discussed with reference to Fig. Section 1 discusses the communication circuit 100 in a schematic representation according to various aspects. The representation of the communication circuit 100 is simplified to discuss the general components for enabling wireless communication (e.g., in the BLE context and in the iBeacon context). The aspects discussed with regard to the communication circuit 100 generally apply to circuits for use in a (first) communication device configured to send an iBeacon message (see Fig. 2A), as well as in a (second) communication device configured to receive the iBeacon message (see Fig. 5A).

[0035] The communication circuit 100 can be configured for wireless communication and comprises a communication section 102 (also referred to here as the communication interface or communication circuit) and a signal processing section 104 (also referred to here as the processing section or processing circuit). It is understood that the communication circuit 100 is in Fig. 1 is exemplary and that a general communication circuit for use in a communication device may contain additional, fewer or alternative components in relation to those shown.

[0036] The communication circuit 100 can be configured to transmit and / or receive radio frequency signals (e.g., radio frequency waves) via the communication section 102. In this respect, the communication section 102 can be configured to enable wireless communication and can include one or more antennas 110 and a radio frequency transceiver 112. For example, the communication section 102 can include a single antenna 110 or a plurality of antennas 110 (e.g., an array of antennas 110). The one or more antennas 110 can be, for example, directional or omnidirectional antennas. The one or more antennas 110 can include any suitable antenna type for transmitting / receiving radio frequency signals, such as dipole antennas, loop antennas, microstrip antennas, patch antennas, and the like.As an example, taking into account the BLE / iBeacon context, the one or more antennas 110 can be configured to enable the transmission and reception of high-frequency signals in the 2.4 GHz ISM spectrum band (e.g., from 2400 MHz to 2483.5 MHz), where ISM stands for "Industrial, Scientific and Medical".

[0037] As another example, the one or more antennas 110 can be configured to enable the transmission and reception of high-frequency signals in the frequency range above 2.4 GHz, for example, from 3.1 GHz to 10.6 GHz (ultrawideband), e.g., within a bandwidth of 500 MHz within such a range. As another example, the one or more antennas 110 can be configured to enable the transmission and reception of high-frequency signals in a frequency range below 1 GHz, for example, within a frequency range of 100 MHz to 500 MHz (narrowband), e.g., within a frequency range of 150 MHz to 174 MHz and / or 421 MHz to 470 MHz, e.g., within a bandwidth of 25 kHz within such ranges.As another example, one or more antennas 110 can be configured according to Long Range (LoRa) technology and enable the transmission and reception of high-frequency signals in the sub-gigahertz high-frequency bands EU868 (863 MHz to 870 / 873 MHz), AU915 / AS923-1 (915 MHz to 928 MHz), US915 (902 MHz to 928 MHz), IN865 (865 MHz to 867 MHz) and / or AS923 (915 MHz to 928 MHz).

[0038] In some aspects, the communication circuit may include 100 antennas configured for operation in different frequency ranges; for example, the communication circuit may include a variety of subsets of antennas, each designed for transmitting / receiving high-frequency signals in a corresponding frequency range.

[0039] The high-frequency transceiver 112 can comprise a receiver circuit 114 (for example, a receive path) and a transmitter circuit 116 (for example, a transmit path). In this respect, the high-frequency transceiver 112 can include analog and digital components for processing high-frequency signals, such as amplifiers, filters, boost converters, buck converters, signal modulators, quadrature couplers, analog-to-digital converters (ADCs), digital-to-analog converters (DACs), and the like.

[0040] With respect to receive path 114, the RF transceiver 112 can be configured to receive analog RF signals from one or more antennas 110 and perform analog and digital front-end processing of the analog RF signals to obtain digital baseband signals. In transmit path 116, the RF transceiver 110 can be configured to receive digital baseband signals from the signal processing section 104 and perform analog and digital front-end processing of the digital baseband signals to obtain analog RF signals to be transmitted via the one or more antennas 110. Specifically, the RF transceiver 112 can be a Bluetooth radio, e.g., a BLE radio. For example, the RF transceiver 112 can be a hardware transceiver configured to implement the BLE specification.

[0041] The signal processing section 104 can be configured to perform signal processing for transmission and reception according to one or more communication protocols. For example, the signal processing section 104 can be configured to control the radio frequency transceiver 112 to transmit and receive radio signals according to the set of rules defined by the communication protocol(s), such as the BLE communication protocol and / or the iBeacon communication protocol. The signal processing section 104 can thus be configured to issue instructions to the radio frequency transceiver 112 that are representative of the signal modulation, signal frequency, timing, synchronization, etc., depending on the rules and instructions defined by the communication protocol(s) according to which the communication circuit 100 transmits and / or receives radio frequency signals.

[0042] For example, the signal processing section 104 can include a digital signal processor 122 configured to perform the physical layer (PHY) transmit and receive processing, and a protocol manager 124 configured to perform functions associated with the upper layers in the protocol stack of the communication protocol. The digital signal processor 122 can thus be configured to receive data and information from the protocol manager 124 and to prepare the received data and information for transmission via the transmitter circuit 112. On the receiver side, the digital signal processor 122 can be configured to receive digital signals from the receiver circuit 114 and to prepare the digital signals for processing by the protocol manager 124.

[0043] As exemplary processing functions of the physical layer, the digital signal processor 122 can be configured to perform error detection, error correction, signal encoding, signal decoding, channel modulation, channel demodulation, power control, time synchronization, frequency synchronization and the like.

[0044] The protocol manager 124 can be configured to control the radio communication components of the communication circuit 100 (e.g. the antennas 110, the high-frequency transceiver 112, the digital signal processor 122) according to the communication protocol(s) used for signal transmission and signal reception.

[0045] The signal processing section 104 may further include an application processor 126 configured to perform processing in the layers above the protocol stack. For example, the application processor 126 may be configured to execute programs and applications at the application layer of a communication device comprising the communication circuit 100. For example, the application processor 126 may be configured to implement an operating system (OS), a user interface (UI), or any suitable control function related to interactions with a user.

[0046] The communication circuit 100 can further include a memory 130 coupled to the signal processing section 104. The memory 130 can be configured to store all suitable information relevant to the operation of the communication circuit 100. For example, the memory 130 can be configured to store instructions to be executed by the signal processing section 104, data to be transmitted via the transmitter circuit 112, data to be received via the receiver circuit 114, and the like.

[0047] Let us now turn to the adapted procedure proposed here for establishing a communication session. The aspects relating to the communication device that sends the initial iBeacon message are discussed in relation to… Fig. 2A to Fig. 4C is discussed, and the aspects relating to the communication device receiving the initial iBeacon message are addressed in relation to Fig. 5A and Fig. Section 5B is discussed. Without limiting generality, the communication device that sends the initial iBeacon message can be referred to here as the "first" communication device, and the device that receives the initial iBeacon message can be referred to here as the "second" communication device. However, it is understood that the terms "first" and "second" are used merely to distinguish the two devices and do not imply any particular preference, hierarchy, order, or the like.

[0048] Fig. Figure 2A shows a (first) communication device 200, configured to perform communication according to the hybrid approach proposed here, in a schematic representation according to various aspects. The communication device 200 can generally be configured for wireless communication and include a processor 202 coupled with a memory 204. The memory 204 can be configured to store instructions (e.g., software instructions) that are executed by the processor 202. The instructions can cause the processor 202 to execute a customized procedure 210 for establishing a communication session with another communication device 242, which is described in more detail below. Aspects described with respect to a configuration of the processor 202 can also apply to the procedure 210, and vice versa.

[0049] The wireless communication device 200 may further comprise a communication circuit 206 configured to enable wireless communication. The communication circuit 206 may generally be configured like the one described in Fig. The communication circuit 100 described in Section 1 can be configured as follows: the communication circuit 206 can include a communication section for transmitting / receiving radio frequency waves and a signal processing section for processing the received / to-be-transmitted signals. In this respect, the signal processing section can be a dedicated circuit, or the processor 202 can further be configured to implement signal processing functions for transmission / reception. In particular, the communication circuit 206 can be configured for transmitting and receiving signals according to the BLE communication protocol and the iBeacon communication protocol, as described in Section 1. Fig. 1 explained. The communication device 200 can thus be understood as a BLE-enabled device and an iBeacon device (or iBeacon-enabled device).

[0050] In general, the processor 202 can be configured to receive input from a user (for example, user input) and, in response to the user's input, establish a communication session with another communication device 242 (see also Fig. 6A). In this respect, the processor 202 can be configured to detect a user-triggered event 220 at the (first) communication device 200. For example, the processor 202 can be configured to detect that the user of communication device 200 has performed an action on communication device 200 that triggers communication with the other communication device 242.

[0051] In other words, the processor 202 can be configured to detect the occurrence of an event triggered by user interaction with the communication device 200 and respond accordingly to initiate the establishment of a communication session with the other communication device 242, as further explained below. For example, the processor 202 can be configured to detect a user action (as a "user-triggered event" 222) and, in response to the detection of the action, execute the subsequent steps of the procedure 210. In this respect, the "user-triggered event" 222 can be any suitable type of event (for example, any suitable type of interaction), depending on the overall configuration of the communication device 200 and the intended use case for the hybrid approach proposed here.Aspects related to user-triggered event 222 are discussed in relation to . Fig. 2B explained in more detail.

[0052] The processor 202 can further be configured to generate a (first) message 232 in accordance with the iBeacon communication protocol in response to the detection of a user-triggered event. The first message 232 can thus be a data packet with a format defined by the iBeacon communication protocol. In this respect, the first message 232 can contain a variety of fields according to the structure defined by the iBeacon protocol. According to the approach proposed here, the first message 232 can contain event-related information 234, identification information 236, and random information 238, as explained in more detail below.

[0053] Furthermore, the first message 232 can contain any other suitable field or type of information according to the iBeacon protocol, such as a preamble and power-related information. The preamble can be a 9-byte constant preamble and contain data length, data type, flags, and vendor-specific data (e.g., length, type, company ID, etc.). The power-related information can be representative of the transmit power and represent the average signal power measured at a predefined distance from the communication device 200 (e.g., at a distance of 1 meter). The power-related information can enable the other communication device 242, which receives the first message 232, to determine the distance from the communication device 200 (e.g., near, medium, far) depending on the power of the signal received at the other communication device 242.The first message 232 can therefore be understood as an iBeacon-type message that is further adapted to contain information that enables the hybrid approach proposed here.

[0054] The information contained in the first message 232 relates to Fig. 4A to Fig. 4C explains this in more detail. In general, the identification information 236 is representative of the communication device 200. For example, the identification information 236 is configured so that the other communication device 242, which receives the message 232, can identify the communication device 200 from which the message 232 originated (see also Fig. 4C). The event-related information 234 represents the user-triggered event 222. For example, the event-related information 234 can contain one or more properties of the user-triggered event 222 (see also Fig. 4A), enabling the communication device 242, which receives the message 232, to determine an appropriate response to the event 222. Finally, the random information 238 can include randomly generated information, e.g., information that is not predefined but is randomly generated for inclusion in the message 232 (see also Fig. 4B).

[0055] The processor 202 can further be configured to initiate the transmission of the first message 232 to a second (different) communication device 242. For example, after generating the message 232, the processor 202 can instruct the communication circuit 206 to transmit the first message 232 (e.g., to transmit a radio frequency signal representing the message 232). The processor 202 can thus prepare the message 232 using the information mentioned above and then transmit the message 232 to the second communication device 242. The second communication device 242 is configured with respect to Fig. 5A and Fig. 5B is described in more detail. In general, the second communication device 242 can be another BLE-enabled (and iBeacon-enabled) device within the communication range of the (first) communication device 200.

[0056] The processor 202 can further be configured to receive a request 252 from the other communication device 242 to establish a communication session according to the BLE communication protocol between the communication device 200 and the other communication device 242. As with regard to Fig. As explained in more detail in section 5A, the other communication device 242 can, for example, evaluate the information contained in message 232 and, if necessary, request the establishment of a BLE communication session with the (first) communication device 200. The communication circuit 206 can thus receive a signal (a BLE message) representing request 252 and forward request 252 to processor 202.

[0057] In other words, the processor 202 can receive a connection request 252 from the other communication device 242 in response to the transmission of message 232 and the reception / processing of message 232 by the other communication device 242. The proposed approach thus includes the initial iBeacon message 232 to inform the other communication device 242 about the event 222 and further includes the establishment of a BLE communication session (via the corresponding request 252) for the subsequent exchange of information between the communication device 200 and the other communication device 242.

[0058] Although not shown, processor 202 can also be configured to accept request 252 and establish (and conduct) the BLE communication session with the other communication device 242. During the BLE communication session, communication devices 200 and 242 can communicate with each other according to the BLE protocol, as explained in more detail below, thus enabling an exchange of feedback information that would otherwise not be supported by iBeacon technology. Further aspects related to the communication session and the behavior of communication device 200 during the established communication session are described in relation to Fig. 6A explained.

[0059] In this context, the term "establish" or "manufacture" can encompass all suitable tasks and processes necessary to realize the communication session. The term "establish" or "manufacture" can thus refer to tasks and processes that serve to initiate, start, set up, or generally make the communication relationship between the first communication device and the second communication device "ready for use." Furthermore, any definition of the term "establish" or "manufacture" found in any of the aforementioned specifications or standards may be used for the purposes of this disclosure.

[0060] In this context, the term "communication session" describes a temporary and interactive exchange of information between two units (e.g., between the first and second communication devices). The term "communication session" can, for example, describe a bidirectional flow of messages between the two units over a specific period (e.g., from the beginning to the end of the communication session). Specifically, the term "communication session" here can refer to a communication session according to the BLE communication protocol, in which the units participating in the communication session exchange information according to the rules and formats defined by the BLE protocol. A "communication session" can thus be a structured communicative interaction between the participating units, for example, according to the structure defined by BLE technology.

[0061] From the perspective of Method 210, Method 210 may, in 220, include detecting the occurrence of the user-triggered event 222 at the communication device 200. Method 210 may, in 230, further include generating the first message 232 according to the iBeacon communication protocol in response to detecting the occurrence of the user-triggered event 222. Method 210 may, in 240, further include sending the first message 232 to a second communication device 242 according to the Bluetooth Low Energy (BLE) protocol. Method 210 may, in 250, further include receiving a request 252 to establish a communication session according to the Bluetooth Low Energy (BLE) protocol between the first communication device 200 and the second communication device 242.

[0062] As mentioned previously, the user-triggered event 222 can be any suitable type of interaction that the user performs with the communication device 200 to cause the processor 202 to generate / transmit the first message 232 and to perform the subsequent communication with the other communication device 242. In a preferred configuration, which represents the most relevant use case for the approach proposed here, the user-triggered event 222 can involve switching a switchable element 260 of the communication device 200, as shown in Fig. 2B is shown.

[0063] In various aspects, the communication device 200 can include a switchable element 260 that can be controlled (e.g., switched) by the user of the communication device 200, and the user-triggered event 222 can involve the user actuating the switchable element 260. For example, the switchable element 260 can be switched between a variety of states, e.g., at least a first state and a second state, or more than two states (e.g., a third state, a fourth state, etc.). In this scenario, the user-triggered event 222 can involve the user switching the switchable element 260 from one state to another, e.g., from the first state to the second state (or from the second state to a third state, etc.), or vice versa.

[0064] In other words, the switchable element 260 can be a user-operated element of the communication device 200, and the processor 202 can be configured to detect the occurrence of event 222 by sensing a state change of the switchable element 260. For example, the processor 202 can determine that the user-triggered event 222 has occurred when the switching meets one or more predefined criteria, such as a certain number of consecutive switching operations, a certain duration during which the switchable element 260 remains in a specific state, and the like, and thus execute the rest of the procedure for establishing the communication session only in the case of an intentional action by the user.

[0065] In a preferred configuration, the user-triggered event 222 can encompass a predefined number of switching operations of the switchable element 260, for example, a predefined number of state changes of the switchable element 260. The processor 202 can thus determine that the user-triggered event 222 has occurred when the switchable element 260 has changed its state (e.g., from the first state to the second state) a predefined number of times, e.g., a predefined number of times within a predefined period.In other words, the processor 202 can detect that the user of communication device 200 intentionally requests communication device 200 to initiate the procedure for establishing the communication session with the other communication device 242 when the switchable element 260 is switched from the first state to the second state (or between the first state and the second state, or any other state) a predefined number of times. The predefined number can be any suitable number that strikes a balance between a fast response and avoiding unwanted activations by the user. For example, the predefined number could be one, two, three, four, five, or more than five.

[0066] It is understood, however, that in principle any suitable criterion can be used. As a further example, the user-triggered event 222 can include a predefined duration during which the switchable element 260 is in one of the states (e.g., the second state). For example, one of the states (e.g., the first state) can be a default or unswitched state of the switchable element 260, and another of the states (e.g., the second state) can be a switched state of the switchable element 260. The processor 202 can determine that the user-triggered event 222 has occurred if the switchable element 260 remains in the switched state for a predefined period (e.g., for more than a predefined threshold, e.g., more than 250 milliseconds, more than 1 second, more than 5 seconds, more than 10 seconds, as examples).

[0067] In a preferred configuration, which in terms of Fig. 3A to Fig. As explained in more detail in Section 3C, the switchable element 260 can be a physical button that can be switched between a released state (as the first state, e.g., the default state) and a pressed state (e.g., as the second, switched state). In this configuration, the user-triggered event 222 can include pressing (in other words, actuating) and / or releasing the physical button (by the user of the communication device 200). In this scenario, the processor 202 can determine that the user-triggered event 222 has occurred when the button has been pressed a predefined number of times (e.g., when it has switched from the released state to the pressed state).

[0068] As already mentioned, a physical button is a relevant use case, since the proposed communication strategy is of particular importance in connection with physical safety buttons. However, it is understood that the user-triggered event 222 can, in principle, be any suitable type of action by the user of the communication device and / or that the communication device 200 can comprise any suitable user-operable element, the actuation / activation of which by the user defines the user-triggered event.

[0069] As another example, the user-triggered event 222 can include audio input from the user, such as a specific tone or sequence of tones, which the user inputs into the communication device 200 (e.g., into a microphone of the communication device 200). For example, the user-triggered event 222 can include a predefined word spoken by the user. As another example, the user-controlled event 222 can include visual input from the user; for example, the communication device 200 can be configured to perform face detection or eye tracking, and the user-triggered event 222 can include the detection of the user's face or the detection of the user looking in a specific direction.

[0070] As another example of a user-operated element, the communication device 200 can include a knob that can be rotated between several different positions, and the user-triggered event 222 can involve rotating the knob from a first position to a second position. As another example of a user-operated element, the communication device 200 can include a sliding element that can be moved between several different positions, and the user-triggered event 222 can involve moving the sliding element from a first position to a second position.

[0071] As another example, the user-activated element can be a sensor configured to detect a physical quantity, and the user-triggered event 222 can involve the detected physical quantity meeting a predefined criterion (e.g., the detected physical quantity being greater or less than a predefined threshold). For example, the communication device 200 can include a light sensor, and the user-triggered event 222 can involve the light sensor detecting no light or light below a certain illumination threshold (in this case, activation can consist of the user covering the light sensor with a finger).For example, the communication device 200 may include a gyroscope, and the user-triggered event 222 may include an acceleration of the communication device 200 that is greater than a predefined threshold (in this case, activation may consist of the user rapidly moving or shaking the device).

[0072] As another example, the communication device 200 can include a touchscreen, and the user-operable element can include an element displayed on the screen. In this scenario, the user-triggered event 222 can involve the user touching the touchscreen, for example, a touch that corresponds to a virtual toggle of the operable element. For example, the user-triggered event 222 can involve a predefined pattern drawn by the user on the touchscreen.

[0073] It is also understood that the communication device 200 may include more than one user-operable element, e.g., more than one switchable element 260, and that the user-triggered event 222 may include the user operating several user-operable elements (e.g., switching several switchable elements), for example, in a specific sequence or according to a specific pattern, and the like.

[0074] In general, the communication device 200 can be any suitable type of device. Specifically, the communication device 200 can be a portable device. In this scenario, the communication device 200 can be a battery-powered device, for example, a device with a rechargeable battery or a device designed to accommodate a rechargeable battery. The communication device 200 can thus include a battery compartment configured to hold a battery (or multiple batteries). In some aspects, the communication device 200 can include the battery or batteries that power the various components of the communication device 200.

[0075] In this context, the Fig. 3A to Fig. 3C discloses a portable security button 300, which may be a preferred embodiment of the (first) communication device 200. It is understood that the configuration of the portable security button 300 is exemplary and that the portable security button may include additional, fewer, or alternative components with respect to the components shown. It is also understood that the approach proposed here can be applied to other types of (first) communication devices 200, such as mobile communication devices (e.g., a smartphone, a tablet, a laptop, a netbook, a pager, etc.), wearable devices (e.g., a smartwatch, smart glasses, earphones, etc.), and the like.

[0076] In the exemplary configuration of Fig. 3A to Fig. 3C The portable safety button 300 can comprise a housing 302 that encloses the internal components of the portable safety button 300. For example, the housing 302 can be made of a plastic material. The portable safety button 300 can further comprise a physical button 304 (an exemplary embodiment of the switchable element 260) that the user or owner of the portable safety button 300 can press in an emergency. The portable safety button 300 can further comprise one or more elements that can be actuated to provide feedback to the user. As in Fig. As shown in Figure 3A, the portable safety button 300 can, for example, include a light-emitting element 306, such as a light-emitting diode (LED) ring, configured to emit light. The light-emitting element 306 can, for example, emit light to signal that the button 304 has been pressed or to signal feedback from another device. As further examples of elements that can be activated to provide feedback to a user, the portable safety button 300 can, in addition to or as an alternative to the light-emitting element 306, include a vibration element to provide tactile feedback as vibration of the portable safety button 300, and / or a speaker to provide audible feedback (e.g., a tone).

[0077] The various components of the portable safety button 300 can be mounted on a circuit substrate 308, e.g., a printed circuit board. The portable safety button 300 can also include a mounting opening 310 to facilitate transport of the button 300 by the user, e.g., to allow the button 300 to be attached to a key ring, necklace, bracelet, and the like.

[0078] Fig. Figure 3B shows a view of the interior of button 300, illustrating the interior of the housing 302. As shown, in this exemplary configuration, button 300 can include a power supply 312, e.g., a battery (e.g., a rechargeable battery). Button 300 can further include a processor 314, e.g., a central processing unit (CPU) (e.g., an exemplary implementation of processor 202). The processor 314 can be a system-on-chip configured to control the operation of button 300. Button 300 can also include a BLE radio device and an antenna 316, illustrating a communication interface configured to enable communication according to the BLE (and iBeacon) communication protocol, e.g., an exemplary implementation of the one shown in Figure 3B. Fig. 1 discussed communication section 102.

[0079] Fig. Figure 3C shows an example of user activation of button 300. As shown, the user presses the physical button 304 (e.g., once or a predefined number of times). The firmware 324 responds by waking up the system, initiating radio communication, and transmitting information. According to the proposed approach, the firmware 324 can respond to the button press by generating the message according to the iBeacon protocol, initiating the BLE communication session with the other communication device, and transmitting information during the BLE communication session. The firmware can also receive a command (during the BLE communication session) to play a flashing pattern using the light-emitting element 306, e.g., using the LED ring.

[0080] The content of the (first) message 232 according to the iBeacon protocol is related to Fig. 4A to Fig. 4C explained in more detail. Examples are given. Fig. 4A to Fig. 4C Possible configurations of the event-related information 234, the identification information 236, and the random information 238. The aspects of Fig. 4A to Fig. 4C can be combined with each other, e.g. in such a way that the first message contains 232 event-related information 400, which, as in relation to Fig. 4A is configured as described, and / or random information 410, which is as described in relation to Fig. 4B is configured as described, and / or identification information 420, which is as described in relation to Fig. 4C is configured as described.

[0081] In this respect, it shows Fig. 4A Event-related information 400 in a schematic representation according to various aspects. The event-related information 400 can be an exemplary configuration of the event-related information 234, which is related to Fig. 2A described message 232 is contained, so that aspects described in relation to event-related information 400 may apply to event-related information 234 and vice versa.

[0082] In general, the event-related information 400 can represent any suitable property or parameter associated with the user-triggered event 222 that enables the (second) communication device 242, which receives the information, to determine whether an action should be performed and what type of action should be performed. For example, the event-related information 400 can represent information that causes the (second) communication device 242 to perform an appropriate action in response to the user-triggered event 222 (see also Fig. 5A and Fig. 6A).

[0083] For example, the event-related information 400 can be representative of whether the user-triggered event 222 meets a predefined criterion, so that the (second) communication device 242 can perform a corresponding action if the user-triggered event 222 meets the criterion, and refrain from performing the corresponding action if the user-triggered event 222 does not meet the criterion. The event-related information 400 can thus contain a direct indication of whether the user-triggered event 222 meets the predefined criterion (e.g., a flag representing "yes" or "no"), or it can contain information that enables the (second) communication device 242 to determine whether the user-triggered event 222 meets the predefined criterion.

[0084] In a preferred configuration, which has proven to be a simple yet efficient evaluation of the user-triggered event 222, the event-related information 400 can be representative of a number of occurrences 402 of the user-triggered event 222, for example, within a predefined period. For instance, the event-related information 400 can describe how often the user interacted with the (first) communication device 200 within a specific time period. The predefined period can be freely chosen to ensure that the occurrences 402 of the user-triggered event 222 are related to each other and do not refer to separate and independent events. For example, the duration of the predefined period can be in the range of 10 seconds to 2 minutes, or, for instance, in the range of 30 seconds to 1 minute.

[0085] As another example, the event-related information 400 can be representative of a number of occurrences 402 of the user-triggered event 222, which are separated from each other by a predefined time interval, e.g. by less than 2 seconds or less than 1 second or less than 250 milliseconds, as a numerical example.

[0086] Considering the preferred configuration, where the user-triggered event 222 involves switching a switchable element 260 of the (first) communication device 200 (e.g., pressing / releasing a button, e.g., in a portable safety button), the number of occurrences 402 of the user-triggered event 222 can be a number of switching operations of the switchable element 260, as described in relation to Fig. 2B explains. For example, the number of occurrences 402 of the user-triggered event 222 can be a number of activations of the button (a number of times the button was pressed, e.g., in a predefined period or in predefined time intervals).

[0087] In addition to or as an alternative to the number of occurrences 402 of the user-triggered event 222, the event-related information 400 can be a further parameter, which has proven suitable for a simple but efficient evaluation, and can be representative of a duration 404 of the user-triggered event 222. For example, the event-related information 400 can describe the duration of the event-related user interaction with the (first) communication device 200.

[0088] Considering the preferred configuration, where the user-triggered event 222 involves switching a switchable element 260 of the (first) communication device 200 (e.g., pressing / releasing a button, such as in a portable safety button), the duration 404 of the user-triggered event 222 can be the duration of the switching operation of the switchable element 260. For example, the duration of the switching operation of the switchable element 260 can represent the total time during which the user has activated the switch, e.g., from the start time of an initial switching operation (an initial state change) to the end time of a final switching operation (a final state change). As another example, the duration of the switching operation of the switchable element 260 can represent the time that the switchable element 260 is in the switched state (e.g., in the second state).For a key, the duration 404 of the user-triggered event 222 can be a time during which the key is in the pressed state.

[0089] Fig. Figure 4B shows random information 410 in a schematic representation according to various aspects. The random information 410 can be an exemplary configuration of the random information 238, which is related to Fig. 2A described message 232 are contained, so that aspects described in relation to the random information 410 may apply to the random information 238 and vice versa.

[0090] In general, the random information 410 can be any suitable type of information that varies randomly so that the (first) message 232 is not ignored by the (second) communication device 242. For example, the random information 410 can be any suitable type of randomly generated information that causes the (second) communication device 242 to process the content of the (first) message 232 (and to perform an appropriate action in response to the user-triggered event 222).

[0091] The random information 410 can thus contain random elements 412 that are not predefined and vary between different messages generated / transmitted by the (first) communication device 200 at which the user-related event occurs. For example, each message generated / transmitted by the (first) communication device 200 can contain random information 410 that differs from the random information 410 contained in another message generated / transmitted by the (first) communication device 200, where, for example, at least one random element 412 can be different.

[0092] The random information 410 can be unique for each message generated / transmitted by the (first) communication device 200. For example, considering a random generation process, the probability of the random information 410 being repeated in different messages can be negligible. In this respect, the (first) communication device 200 can generate the random information 410 according to any suitable method, e.g., based on ambient noise, based on a processor state, based on an algorithm with an initial seed value, and the like.

[0093] In a preferred configuration, the random information 410 can consist of a random number, such as a randomly generated number. A random number can be represented compactly for transmission in an iBeacon data packet, as explained in more detail below. In this scenario, the random elements 412 can be digits that take on a random value. The length of the randomly generated number can be freely adjusted to achieve a negligible probability of repetition while maintaining manageable computational overhead. For example, the randomly generated number can have a length of 1 byte. In general, the message 232 can contain a sequence of bits representing the random information 410, and using a random number can facilitate such a representation.

[0094] As another example, the random information 410 could consist of a random string. In this scenario, the random elements could be 412 random characters. As yet another example, the random information 410 could consist of a random alphanumeric code. In this scenario, the random elements could be 412 random characters and random digits, and so on.

[0095] Fig. Figure 4C shows identification information 420 in a schematic representation according to various aspects. Identification information 420 can be an exemplary configuration of identification information 236, which is related to Fig. 2A described message 232 contains, so that aspects described in relation to identification information 420 may apply to identification information 236 and vice versa.

[0096] In general, the identification information can be any suitable type of information that enables the (second) communication device 242, which receives message 232, to identify the (first) communication device 200 from which message 232 originated. In the iBeacon context, the identification information 420 can include a universally unique identifier (UUID), a major ID, and a minor ID. As is generally known, the UUID is a unique identifier, typically 128 bits long, assigned to a group of iBeacon devices. The major ID is an identifier, typically 16 bits long, assigned to a subset of iBeacon devices within the group corresponding to the UUID. The minor ID is another identifier, typically 16 bits long, assigned to an individual iBeacon device within the subset.

[0097] Depending on various aspects, the minor ID can be adapted in relation to a conventional iBeacon configuration to include additional information that enables hybrid communication. For example, the event-related information 234, 400 and the random information 238, 410 can, in principle, be included in any suitable field of the structure of the first message 232. However, in a preferred configuration, the minor ID of the iBeacon message can be adapted to include both the event-related information 234, 400 and the random information 238, 410, thus enabling a resource-efficient implementation of the proposed strategy.

[0098] As in Fig. As shown in Figure 4C, the identification information 422 can (among other things) contain a primary ID 422 and a secondary ID 424. In this context, it is understood that the in Fig. The values ​​and bits shown in Figure 4C are merely examples. The main identifier 422 contains identifier information that is representative of the first communication device 200. The main identifier 422 can be used at the receiving communication device 242 as a primary filter to decide whether the request from the first communication device 200 is "interesting" and should be processed.

[0099] The secondary identifier 424 can consist of a first part 426 and a second part 428. For example, the first part 426 can be a lower byte and the second part a higher byte, but the length of parts 426 and 428 is not limited to this value. For example, one part can be longer than the other. In this configuration, one of the parts (e.g., the first part 426) can contain the event-related information 234, 410, which is representative of the user-triggered event, and the other part (e.g., the second part 428) can contain the random information 238, 410. In some aspects, the secondary identifier 424 can consist of the first part 426 and the second part 428, each with a size of 1 byte.

[0100] Thus, in some aspects, the lower byte of minor ID 424 can be used to transmit the event. As an example configuration, the lower byte of minor ID 424 can contain values ​​below 16 for click counts and long presses, and higher values ​​for generic events. The higher byte of minor ID 424 can be used to add random noise to "trick" the receiver into not recognizing the values ​​as already known (cached) information.

[0101] Let us now turn to the other unit involved in the communication approach proposed here. Fig. Figure 5A shows a (second) communication device 500, configured to perform communication according to the hybrid approach proposed here, in a schematic representation according to various aspects. The communication device 500 can generally be configured for wireless communication and include a processor 502 coupled with a memory 504. The memory 504 can be configured to store instructions (e.g., software instructions) that are executed by the processor 502. The instructions can cause the processor 502 to execute a customized procedure 510 for establishing a communication session with another (first) communication device 532 (for example, the first communication device 200). Aspects described with respect to a configuration of the processor 502 can also apply to the procedure 510, and vice versa.

[0102] The (second) communication device 500 can generally be used like the one described in relation to Fig. The (second) communication device 242 described in Section 2A may be configured such that aspects discussed with regard to the communication device 500 may also apply to the communication device 242, and vice versa. Accordingly, the (first) communication device 532 may generally be configured like the one described in Section 2A. Fig. 2A described (first) communication device 200 should be configured so that aspects discussed in relation to communication device 532 may apply to communication device 200 and vice versa.

[0103] The wireless communication device 500 may further include a communication circuit 506 configured to enable wireless communication. The communication circuit 506 may generally be configured as described in Fig. The communication circuit 100 described in section 1 can be configured as follows: the communication circuit 506 can include a communication section for transmitting / receiving radio frequency waves and a signal processing section for processing the received / to-be-transmitted signals. In this respect, the signal processing section can be a dedicated circuit, or the processor 502 can further be configured to implement signal processing functions for transmission / reception. In particular, the communication circuit 506 can be configured for transmitting and receiving signals according to the BLE communication protocol and the iBeacon communication protocol, as described in section 1. Fig. 1 explained. The communication device 500 can thus be understood as a BLE-enabled device and an iBeacon-enabled device.

[0104] In general, the processor 502 can be configured to receive input relating to a user-triggered event on another communication device 532 and, in response to the input, establish a communication session with that other communication device 532. In this respect, the processor 502 is configured to receive a (first) message 512 from another (first) communication device 532 according to the iBeacon communication protocol. The (first) message 512 can be considered the one relating to Fig. The first message described in 2A is configured as 232 and can contain event-related information 514 (configured as event-related information 234, 400), identification information 516 (configured as identification information 236, 420) and random information 518 (configured as random information 238, 410).

[0105] The processor 502 can further be configured to send a request 534 to the other (first) communication device 532 in response to the first message 512, in order to establish a communication session according to the BLE protocol between the first communication device 532 and the (second) communication device 500. For example, the processor 502 can generate the request 534 and initiate its transmission to the other communication device 532 to request that the other communication device 532 to conduct the BLE communication session. The processor 502 can thus respond to the iBeacon message 512 with a BLE request 534, combining the strengths of the two approaches described above.

[0106] Depending on various aspects, processor 502 can be configured to determine whether to respond to the user-triggered event at the other communication device 532, represented by the first message 512. For example, processor 502 can be configured to determine whether to establish a communication session for the user-triggered event reported by the first message 512, or whether to refrain from establishing a communication session for this user-triggered event. In other words, processor 502 can be configured to determine whether or not to issue request 534 for the user-triggered event at the other communication device 532.

[0107] The evaluation can encompass several aspects. For example, the processor 502 can be configured to determine whether the first message 512 originates from a communication device 532 to which a reply should be sent. For example, the processor 502 can be configured to determine whether the (first) communication device 532 is a known device and, accordingly, whether a communication session with this communication device 532 is appropriate.

[0108] The processor 502 can thus be configured to determine, based on the identification information 516, whether the request 534 should be issued. Specifically, the processor 502 can issue (e.g., generate and transmit) the request 534 if the identification information 516 represents a known communication device 532 (e.g., a communication device 532 that is paired with the communication device 500, for example, with an application 540 of the communication device 500 described below). On the other hand, the processor 502 can refrain from issuing the request 534 if the identification information 516 represents an unknown communication device 532 (e.g., an unpaired device).

[0109] The evaluation can be based, for example, on a major identifier contained in message 512. For instance, the 16-bit major identifier can act as a primary filter to determine whether the request is of interest to the receiving communication device 500 (e.g., the receiving application). In the iBeacon context, the iBeacon ID may not necessarily be unique. Therefore, the evaluation can, in some aspects, be based (additionally or alternatively) on the Bluetooth device address of the (first) communication device 532. The Bluetooth device address can be part of the identification information 516 contained in the first message 512 and can be a unique identifier associated with the (first) communication device 532 (whereas the UUID and major ID of a group or subset of devices can be shared). The Bluetooth device address can also be referred to as the BLE Media Access Control (BLE MAC).

[0110] The processor 502 can thus be configured to issue the request if the BLE MAC address contained in the first message 512 represents a known communication device 532 with which a communication session can be established. In this context, the initial check of the major ID can be a coarser filter to exclude categories or groups of devices, and the check of the BLE MAC address can be a finer filter to evaluate specific individual communication partners.

[0111] In addition to or as an alternative to evaluating the identification information 516, the processor 502 can evaluate the event-related information 514 to determine whether (and how) to respond to the message 512. For example, if the processor 502 performs the evaluation of the identification information 516, it can evaluate the event-related information 514 after determining that the (first) communication device 532 is a known device for which the query 534 can be issued.

[0112] In this respect, the processor 502 can be configured to determine, based on the event-related information 514, whether the user-triggered event at the other communication device 532 meets a predefined criterion. The processor 502 can then issue the request 534 if the user-triggered event meets the criterion, or it can refrain from issuing the request 534 if the user-triggered event does not meet the criterion.

[0113] In this context, the provisions relating to apply. Fig. 4A describes aspects for evaluation. For example, the event-related information 514 can contain a direct indication of whether the user-triggered event was triggered by the user, and the processor 502 can issue the request 534 if the direct indication suggests that the criterion is met. As another example, the event-related information 514 can represent one or more properties or parameters of the user-triggered event, and the processor 502 can determine, based on the properties / parameters, whether the event meets the predefined criterion.

[0114] As previously explained, the 502 processor can, for example, determine that the event meets the predefined criterion if the number of occurrences of the user-triggered event (e.g., within a predefined period) exceeds a threshold (e.g., greater than 1, greater than 2, etc.). In particular, the 502 processor can determine that the event meets the predefined criterion if the number of switching operations of a switchable element of the other communication device 532 (e.g., a number of key presses, such as of a portable safety button) exceeds a threshold.

[0115] As another example, the 502 processor can determine that the event meets the predefined criterion if the duration of the user-triggered event exceeds a threshold (e.g., more than 250 milliseconds, more than 2 seconds, more than 10 seconds, more than 30 seconds, more than 1 minute, etc.). Specifically, the 502 processor can determine that the event meets the predefined criterion if the duration of a switching operation of a switchable element of the other 532 communication device exceeds the threshold. For example, the 502 processor can determine that the event meets the predefined criterion if the duration of the time the switchable element is in the switched state (e.g., the time a button is pressed) exceeds the threshold.

[0116] Although not shown, processor 502 can also be configured to conduct the BLE communication session with the other communication device 532 (after the other device 532 has accepted the request 534). During the BLE communication session, communication devices 500 and 532 can communicate with each other according to the BLE protocol described above.

[0117] From the perspective of procedure 510, procedure 510 in 520 may include receiving an initial message 512 according to the iBeacon communication protocol from an initial communication device 532. Procedure 510 may further include in 530 issuing a request 534 to the initial communication device 532 in response to the initial message 512 in order to establish a BLE communication session.

[0118] In general, the (second) communication device 500 can be any suitable type of communication device. In a preferred configuration, the communication device 500 can be a portable communication device, such as a mobile communication device. Specifically, the communication device 500 can be a smartphone, for example, a smartphone paired with a portable security button (as the first communication device). However, it is understood that the communication device 500 can also be any other device, such as a tablet, laptop, notebook, netbook, computer, WLAN access point, a gateway configured according to Long Term Evolution (LTE) or 5G, a gateway configured according to LoRa or LoRa Wide Area Network (WAN), and the like.

[0119] Furthermore, the (second) communication device 500 can be configured according to various aspects and as described in Fig. Figure 5B shows a software application 540 installed on it. The software application 540 can be configured to perform an appropriate action when it receives information about the occurrence of a user-triggered event (e.g., from a known device and upon fulfillment of a predefined criterion). For example, the software application 540 can be responsible for responding appropriately to user interaction with the first communication device 532.

[0120] In particular, the software application 540 can be paired with one or more predefined other (first) communication devices (e.g., one or more portable security buttons), and the initial evaluation based on the identification information of the first message 512 can determine whether the identification information (e.g., the main ID, BLE MAC) is representative of a (first) communication device paired with the software application 540. The processor 502 can then proceed with issuing the request 534 (and performing a corresponding action) if the identification information indicates that the (first) communication device is paired with the software application 540.

[0121] In this context, the term “coupled” can refer to a previously performed identification and / or authentication procedure involving the first communication device 532 and the second communication device 500, such that the first communication device 532 can be part of a “list” of known (e.g., coupled) devices with which the software application 540 can interact.

[0122] In this scenario, the processor 502 can activate the software application 504 in response to receiving the first message 512 (e.g., based on the identification information) and forward the first message 512 to the software application 504 for further processing. The software application 504 can then evaluate the user-triggered event (e.g., based on the criterion described above) and can be configured to provide an appropriate response. Specifically, in this scenario, the BLE communication session can be understood as a communication session between the first communication device 532 and the software application 540.

[0123] The software application 504 can have any suitable configuration depending on the intended use case, and accordingly, the action implemented by the software application 504 for the event can be of any suitable type depending on the desired implementation.

[0124] In a preferred configuration, the user-triggered event at the first communication device 532 can indicate a safety-relevant situation for the user, such as an emergency. For example, the user's interaction with the first communication device 532 (e.g., pressing a button) can indicate that the user needs help; that is, the user-triggered event can indicate a request for help. In this scenario, the software application 504 can perform a response to the safety-relevant situation, such as responding to the request for help.

[0125] The 504 software application can thus perform a safety-related response to the safety-related situation for the user. The safety-related response can be any appropriate type and may include, for example, sending an alert to an emergency service, initiating a call to the police, initiating a call to the hospital, notifying one or more predefined emergency contacts for the user, emitting a visual or audible signal to attract attention, and the like.

[0126] As mentioned previously, the proposed approach is not limited to the context of portable safety keys. In another exemplary scenario, the software application 540 can also be installed on the first communication device 532, and the communication session can take place between a first instance of the software application 540 on the first communication device 532 and a second instance of the software application 540 on the second communication device 500. For illustrative purposes, a "mesh mode" can be provided in some aspects, in which the software applications installed on different communication devices 500 and 532 interact with each other according to the proposed hybrid approach, without requiring an internet connection.

[0127] Fig. Figure 6A shows a schematic communication flow 600 between a first communication device 604 and a second communication device 606. The first communication device 604 can generally be configured as the (first) communication device 200, 532, which, with respect to Fig. 2A and Fig. 5A is described, so that aspects discussed in relation to the first communication device 604 may apply to the communication device 200, 532 and vice versa. The second communication device 606 may generally be configured as the (second) communication device 242, 500, which in relation to Fig. 2A and Fig. 5A is described such that aspects discussed in relation to the second communication device 606 may apply to communication devices 242 and 500, and vice versa. The aspects discussed for communication flow 600 may apply to procedures 210 and 510, and vice versa.

[0128] As shown, the communication flow 600 can begin when the user 602 triggers the event 610 on the first communication device 604. In response to the user-triggered event 610, the first communication device 604 can generate the iBeacon message 612, which represents the event 610 (along with identification information of the device 604 and random information), and transmit it to the second communication device 606. The second communication device 606 can then, in response to the first message 612 (e.g., based on the fulfillment of certain criteria, as described above), issue the request 614 to establish a BLE communication session 620. For example, in response to message 612, the second communication device 606 (e.g., the application installed on it) can establish a BLE connection with the first communication device 604.

[0129] During the BLE communication session 620, the communication devices 604 and 606 communicate according to the BLE protocol. This enables a feedback mechanism, as mentioned above. Thus, depending on various aspects, the second communication device 606 (e.g., its processor, e.g., the application installed on it) can transmit feedback information 622 to the first communication device 604 during the BLE communication session 620. The second communication device 606 can generate a BLE message containing feedback information 622 (e.g., a data packet according to the BLE structure) and transmit the BLE message to the first communication device 604. The BLE session therefore enables bidirectional information exchange between the devices 604 and 606.

[0130] The feedback information 622 can generally be representative of the action taken by the second communication device 606 in response to the first message 612 (e.g., in response to the user-triggered event 610). Considering the preferred configuration discussed above, the feedback information can be representative of the security-related response implemented by the second communication device 606 in response to the user's request for assistance (602). For example, the feedback information might include a chat message addressed to the user (602). Just as further examples relevant in the "security context," the feedback information could be representative of "Alarm successfully transmitted," "Emergency services have promised assistance with the incident," "Emergency services (e.g., security guards) nearby," "No help found nearby, escalate to 112 (or 911)," etc.

[0131] In some aspects, the feedback information 622 can trigger a user-perceived event at the first communication device 604. For example, the first communication device 604 can generate a user-perceived signal in response to the received feedback information 622. This user-perceived signal can inform the user 602 about the response from the second communication device 606. In this respect, the user-perceived signal can be any suitable type of signal, depending, for example, on the configuration of the first communication device 604.

[0132] For example, the user-perceived signal may include a visual signal (e.g., light emitted from a light source of the first communication device 604, such as an LED ring on a physical safety button). Another example is that the user-perceived signal may include an audible signal or a haptic signal (e.g., a vibration of the first communication device 604). As yet another example, if the first communication device 604 includes a display (e.g., in the case of a smartphone), the user-perceived signal may include a notification displayed on the screen to inform the user 602.

[0133] Communication according to the BLE protocol can also be carried out by the first communication device 604 during the BLE communication session 620. For example, during the established BLE communication session 620, the first communication device 604 can detect a second user-triggered event 624 and, in response to the detection of the second user-triggered event 624, generate a corresponding second message 626 according to the BLE protocol. For example, the first communication device 604 can prepare a BLE message 626 containing event-related information representative of the second user-triggered event 624 (e.g., a number of occurrences, a duration, etc.) and transmit the BLE message 626 to the second communication device 626 according to the BLE protocol. It is understood that, in addition to the event-related information, the BLE message 626 can contain further information provided in the BLE context.

[0134] Although in Fig. Figure 6A shows a single instance of a feedback mechanism and a single instance of further events. It is understood that the second communication device 606 can send more than one BLE message with feedback information to the first communication device 604, and that the first communication device 604 can report more than one user-triggered event during the BLE communication session. For example, the additional user-triggered events can trigger further actions of the second communication device 606, such as further safety-related responses.

[0135] The termination of the BLE communication session 620 can be based on any desired criterion. For example, a user-initiated event on the first communication device 604 can cause the termination of the BLE communication session 620. Alternatively, the second communication device 606 (e.g., the installed application) can cause the termination of the BLE communication session 620 after performing the action associated with event 610 (e.g., the safety-related response).

[0136] In a preferred configuration, the BLE communication session 620 can have a predefined duration 630, and the communication flow 600 (e.g., procedure 210, 510) can include the termination of the BLE communication session 620 after a predefined time has elapsed (since the establishment of the BLE communication session 620). Setting a predefined duration can lead to resource conservation in the context of power-limited devices by avoiding excessively long interactions. In this respect, the predefined duration 630 can be freely chosen to ensure that the information exchange can be carried out in a manner that guarantees an appropriate response while simultaneously avoiding excessive consumption of resources on the communication devices 604, 606. As a numerical example only, the predefined duration 630 can be in the range of 1 minute to 10 minutes, e.g., in the range of 2 minutes to 5 minutes.

[0137] Depending on various aspects, the first communication device 604 can be configured to enter a low-power state after the BLE communication session 620 ends. The first communication device 604 can thus enter a low-power state and wait for the next user-triggered event. Switching to the low-power state conserves the resources (e.g., the battery) of the first communication device 604. A "low-power state" can, for example, describe an operating state in which the first communication device 604 consumes less energy compared to its operation in an active state (e.g., compared to its operation during the communication session 620). For instance, in the low-power state, the first communication device 604 can communicate using the iBeacon protocol rather than the BLE protocol.

[0138] Fig. Figure 6B shows a schematic communication flow 650 between a physical safety button 654 and a software application 656 (e.g., installed in a smartphone). The communication flow 650 can be an exemplary scenario of the communication flow 600, with an exemplary implementation of the first communication device 604 and the second communication device 606.

[0139] Initially, the action button device 654 may be in a power-saving mode. When the user 652 presses the button (e.g., three times), the device 654 activates the iBeacon protocol with a specific primary ID as its identifier. The secondary ID can consist of two bytes. These two bytes contain a top byte, which is set to a random number to introduce variability and ensure that the operating system on the application side does not ignore the beacon due to familiarity. The two bytes also include a bottom byte, and the bottom byte can contain a lower nibble (e.g., 4 bits) representing the number of clicks (e.g., 0x03 for three clicks, with a maximum of 0x07 clicks that can be expressed). The top bit of the lower nibble can be set if the last button press was a long press (e.g., 0x05 for five clicks plus 0x08 for a long press = 0x0D). The remaining bits can be reserved for future use.

[0140] The iBeacon signal prompts the operating system to activate the paired application 656, even if it is not running. Application 656 reads the iBeacon information (Major ID, Minor ID) to determine whether it wants to respond to the event and to ascertain the number of clicks and whether a long press occurred. Application 656 processes the initial event and then establishes a BLE connection with the keypad device 654.

[0141] Once the connection is established via BLE, the 654 keypad can provide visual, haptic, or audible feedback, depending on support. The BLE connection is maintained for a configurable duration (e.g., several minutes) to enable continuous interaction and feedback. While the BLE communication session is active, click events are transmitted directly via BLE instead of iBeacon. The 654 keypad can revert to iBeacon mode after the BLE connection ends to conserve battery power.

[0142] In particular, the 654 key element can function as a physical alarm button that can be detected when pressed by a smartphone, computer, or other devices such as Wi-Fi access points with IoT capabilities. The system can be used in any scenario where a device or application needs to signal an event. The lower byte of the minor ID enables communication of up to 0×FF possible events without requiring a constant BLE connection or other communication means.

[0143] The term "processor" here can be understood as any type of technological unit that enables the processing of data. The data can be processed according to one or more specific functions that the "processing circuit" can perform. Furthermore, a "processing circuit" here can be understood as any type of circuit, e.g., any type of analog or digital circuit. A "processing circuit" can thus be or include an analog circuit, a digital circuit, a mixed-signal circuit, a logic circuit (e.g., a hard-wired logic circuit or a programmable logic circuit), a microprocessor, a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a field-programmable gate array (FPGA), an integrated circuit, an application-specific integrated circuit (ASIC), etc., or any combination thereof.In some aspects, a "processing circuit" can be understood as a software-based implementation of the functions performed by the processing circuit.

[0144] The term "memory" here can be understood as a computer-readable medium (e.g., a non-transient computer-readable medium) in which data or information can be stored for retrieval. References to "memory" in this description can therefore refer to volatile or non-volatile memory, including, but not limited to, random access memory (RAM), read-only memory (ROM), flash memory, solid-state memory, magnetic tape, hard disk drive, optical drive, or any combination thereof. Registers, shift registers, processor registers, data buffers, and others are also grouped together under the term "memory" in this description.

[0145] The term "application" can describe a computer program designed to perform a specific task unrelated to the operation of the computer itself. For example, an "application" can be a complete and ready-to-use package to fulfill a particular function within an operational environment.

[0146] The word "exemplary" is used here in the sense of "serving as an example, case study, or illustration." Each aspect or configuration described here as "exemplary" is not necessarily to be understood as preferable or advantageous compared to other aspects or configurations.

[0147] The expressions "at least one" and "one or more" can be understood to include a number greater than or equal to one (e.g., one, two, three, four, [...], etc.). The expression "at least one of" in relation to a group of elements can be used here to denote at least one element from the group consisting of those elements. Unless otherwise specified, the term "subset" in relation to a group of elements can be understood to include a number greater than or equal to one and less than the total number of implied elements. For example, considering a group of ten elements, a "subset" of the group could include one, two, three, four, five, six, seven, eight, or nine elements.The term “subset” in relation to a group can thus describe a “subset of its own” of the group, such that all elements of the subset belong to the group, but at least one element of the group does not belong to the subset.

[0148] The term "send," as used here, can encompass both direct (point-to-point) and indirect transmission (via one or more intermediate points). Similarly, the term "receive" can include both direct and indirect reception. Furthermore, the terms "send," "receive," "communicate," and other similar terms can encompass both physical transmission (e.g., the transmission of radio signals) and logical transmission (e.g., the transmission of digital data over a logical connection at the software level). In general, the term "communicate" can encompass the exchange of data, such as unidirectional or bidirectional data exchange.

[0149] The implementations of the procedures described here may be demonstrative in nature and implemented in a corresponding device. Similarly, the implementations of the devices or circuits described here may be implemented using a corresponding procedure. It is therefore understood that a device or circuit corresponding to a procedure may comprise one or more components configured to execute every aspect of the associated procedure.

[0150] All acronyms defined in the above description also apply to all claims contained herein.

[0151] Although the invention has been shown and described in particular with reference to certain aspects, it should be understandable to those skilled in the art that various changes in form and detail can be made without deviating from the scope of the invention as defined by the attached claims.

Claims

[1] Method (210) for setting up a communication session, wherein the method (210) comprises: Capturing a user-triggered event (222) at a first communication device (200); Generating an initial message (232) according to the iBeacon communication protocol by the first communication device (200) in response to the detection of the user-triggered event (222), wherein the first message (232) includes: identification information (236) that is representative of the first communication device (200), random information (238) and event-related information (234) that is representative of the user-triggered event (222); Sending the first message (232) by the first communication device (200) according to the iBeacon communication protocol to a second communication device (242); and Receiving a request to establish a communication session according to the Bluetooth Low Energy (BLE) protocol between the first communication device (200) and the second communication device (242) at the first communication device (200); the first message (232, 512) includes: a principal identifier (422) containing the identifier information (236, 516) that is representative of the first communication device (200, 532); and a secondary identifier (424) comprising a first part (426) containing the random information (238, 518) and a second part (428) containing the event-related information (234, 514) that is representative of the user-triggered event (222). [2] Method (510) for setting up a communication session, wherein the method (510) comprises: Receiving an initial message (512) according to the iBeacon communication protocol from a first communication device (532) to a second communication device (500), wherein the first message (512) comprises: identification information (516) that is representative of the first communication device (532), random information (518) and event-related information (514) that is representative of a user-triggered event at the first communication device (532); and Issuing a request by the second communication device (500) in response to the first message (512) to the first communication device (532) to establish a communication session according to the Bluetooth Low Energy (BLE) protocol between the first communication device (532) and the second communication device (500). [3] The method (210, 510) according to claim 1 or 2, further comprising: where the event-related information (234, 514) is representative of a number of occurrences of the user-triggered event (222) and / or where the event-related information (234, 514) is representative of a duration of the user-triggered event (222). [4] The method (210, 510) according to one of claims 1 to 3, wherein the first communication device (200) comprises a switchable element (260) that is switchable between at least a first state and a second state, and where the user-triggered event (222) includes switching the switchable element (260) from the first state to the second state. [5] Method (210, 510) according to claim 4, wherein the user-triggered event (222) comprises a predefined number of switching operations of the switchable element (206) by a user of the first communication device (200). [6] Method (210, 510) according to claim 4 or 5, wherein the switchable element (260) is a physical button that can be switched between a released state and a pressed state, and where the user-triggered event (222) includes pressing and / or releasing the physical button. [7] Method (210, 510) according to any one of claims 1 to 6, further comprising: Establishing the communication session between the first communication device (200, 532) and the second communication device (242, 500), where, during the communication session, the first communication device (200, 532) and the second communication device (242, 500) communicate with each other according to the BLE protocol. [8] Method (210, 510) according to any one of claims 1 to 7, further comprising: Capturing a second user-triggered event (624) on the first communication device (200, 532, 604) during the established communication session (620); Generating a second message (626) according to the BLE communication protocol by the first communication device (200, 532, 604) in response to the detection of the second user-triggered event (624), wherein the second message (626) includes event-related information that is representative of the second user-triggered event (624); and Transmission of the second message (626) by the first communication device (200, 532, 604) to the second communication device (242, 500, 606) according to the BLE communication protocol. [9] Method (210, 510) according to any one of claims 1 to 8, wherein the second communication device (242, 500) comprises a software application (540) coupled with the first communication device (200, 532), and the procedure (210, 510) further includes: Activating the software application (540) in response to receiving the first message (232, 512) at the second communication device (242, 500) and / or Delivering the first message (232, 512) to the software application (540). [10] Method (210, 510) according to any one of claims 1 to 9, comprising issuing the request (252, 534) to the first communication device (200, 532) to establish the communication session: Determine at the second communication device (242, 500) and based on the event-related information (234, 514) whether the user-triggered event (222) meets a predefined criterion, and Sending the request (252, 534) to the first communication device (200, 532) to establish the communication session if the user-triggered event (222) meets the predefined criterion. [11] The method (210, 510) according to any one of claims 1 to 10, which further comprises: During the established communication session (620), the second communication device (242, 500, 606) transmits feedback information (622) to the first communication device (200, 532, 604) according to the BLE communication protocol. [12] Communication device (200) with a processor (202) configured to detects a user-triggered event (222) on the communication device (200); In response to the detection of the user-triggered event (222), an initial message (232) is generated according to the iBeacon communication protocol, wherein the first message (232) includes identification information (236) representative of the communication device (200), random information (238) and event-related information (234) representative of the user-triggered event (222), as well as the following: a principal identifier (422) containing the identifier information (236, 516) that is representative of the first communication device (200, 532); and a secondary identifier (424) comprising a first part (426) containing the random information (238, 518) and a second part (428) containing the event-related information (234, 514) that is representative of the user-triggered event (222); a transmission of the first message (212) to a second communication device (242) in accordance with the iBeacon communication protocol; and a request (252) to establish a communication session according to the Bluetooth Low Energy (BLE) protocol between the communication device (200) and the second communication device (242) is received. [13] The communication device (200) according to claim 12, which is configured as a portable safety button. [14] Communication device (500) with a processor (502) configured to: receives a first message (512) according to the iBeacon communication protocol from a first communication device (532), wherein the first message (512) includes identification information (516) representative of the first communication device (532), random information (518), and event-related information (514) representative of a user-triggered event at the first communication device (532), and comprises: a primary identifier (422) containing the identifier information (236, 516) representative of the first communication device (200, 532); and a secondary identifier (424) comprising a first part (426) containing the random information (238, 518), and a second part (428) containing the event-related information (234, 514) representative of the user-triggered event (222); and In response to the first message (512), a request (534) is sent to the first communication device (532) to establish a communication session according to the Bluetooth Low Energy (BLE) protocol between the first communication device (532) and the communication device (500).

Images