Patent Publication Number: US-2017372600-A1

Title: Method, apparatus, and computer program product for local control through intermediate device

Description:
This international application is a continuation-in-part of U.S. application Ser. No. 14/598,417, filed Jan. 16, 2015, entitled, METHOD, APPARATUS, AND COMPUTER PROGRAM PRODUCT FOR DEVICE CONTROL, the entire contents of which is incorporated herein by reference. 
    
    
     FIELD 
     The technology field relates to wireless control of devices through an intermediate server, using information received from the proximate devices via short range communication. 
     BACKGROUND 
     Modern society has adopted, and is becoming reliant upon, wireless communication devices for various purposes, such as, connecting users of the wireless communication devices with other users. Wireless communication devices can vary from battery powered handheld devices to stationary household and/or commercial devices utilizing electrical network as a power source. Due to rapid development of the wireless communication devices a number of areas capable of enabling entirely new types of communication applications have emerged. 
     An example of a wireless short-range communication technology is Bluetooth™ communication protocol, which operates in the 2.4 GHz ISM band. Bluetooth™ is a short-range radio network, originally intended as a cable replacement. Bluetooth™ Technical Specifications are published by the Bluetooth™ SIG, Inc. The Bluetooth™  Core Specification, Version  4.1, Bluetooth™ SIG, Dec. 3, 2013 (incorporated herein by reference), describes the Bluetooth™ protocol (BT) and the Bluetooth™ Low Energy protocol (BTLE). 
     SUMMARY 
     Method, apparatus, and computer program product example embodiments enhance wireless control of devices through an intermediate server, using information received from the proximate devices via short range communication. 
     An example embodiment of the invention includes a method comprising: 
     receiving, by an apparatus, a message from a proximate device via a short-range communication connection, the message including at least ID information associated with the proximate device; 
     compiling, by the apparatus, a request message including at least the ID information associated with the proximate device and information identifying said apparatus; 
     transmitting, by the apparatus, the compiled request message to a remote server for accessing control to the proximate device; 
     receiving, by the apparatus, information associated with a user interface or control interface for interacting with the proximate device via the remote server, the received information including a set of one or more controls allowing the apparatus to interact with the proximate device through the remote server access control and being based on the information included in the transmitted request message; 
     compiling, by the apparatus, a user interface or control interface for enabling a user of said apparatus to interact with the proximate device based on the received information, the compiled user interface or control interface including access rights for interacting with the proximate device via the server access control depending on the information included in the transmitted request message; and 
     interacting, by the apparatus, with the proximate device via the remote server access control using the compiled user interface or control interface. 
     An example embodiment of the invention includes a method comprising: 
     wherein the message received from the proximate device further includes information for accessing the remote server and an indication of RSSI information ensuring close proximity of the proximate device. 
     An example embodiment of the invention includes a method comprising: 
     wherein the request message further includes authentication information associated with a user of the apparatus, to the server. 
     An example embodiment of the invention includes a method comprising: 
     wherein the information received associated with the user interface or control interface for interacting with the proximate device further includes authentication and authorization level information, to the proximate device. 
     An example embodiment of the invention includes a method comprising: 
     wherein the user interface or control interface compiled by the apparatus further includes information based on the authentication and authorization level information, to the proximate device. 
     An example embodiment of the invention includes a method comprising: 
     increasing, by the apparatus, access rights for the user interface or control interface for interacting with the proximate device by providing additional authentication information associated with the user of the apparatus to the remote server. 
     An example embodiment of the invention includes a method comprising: 
     measuring, by the apparatus, signal strength of the message from the proximate device; and 
     detecting, by the apparatus, whether the apparatus is in close proximity to the proximate device, based on the measured signal strength of the message from the proximate device. 
     An example embodiment of the invention includes a method comprising: 
     transmitting, by an apparatus, to a controllable device, ID information that is to be associated with the controllable device; 
     receiving, by the apparatus, a request message from a wireless device via a communication connection, the request message including at least a request for accessing control to the controllable device and the ID information associated with the controllable device; 
     transmitting, by the apparatus, to the wireless device, information associated with a user interface or control interface for interacting with the controllable device based on remote access control through the apparatus, the transmitted information including a set of one or more controls allowing the wireless device to interact with the controllable device through the apparatus access control and based on the information included in the received request message; and 
     controlling, by the apparatus, interaction of the wireless device with the controllable device based on the information associated with the user interface or control interface. 
     An example embodiment of the invention includes a method comprising: 
     wherein the request message further includes authentication information associated with a user of the wireless device, to the apparatus. 
     An example embodiment of the invention includes a method comprising: 
     wherein the request message further includes authentication information associated with an identifier of the wireless device, to the apparatus. 
     An example embodiment of the invention includes a method comprising: 
     wherein the transmitted information associated with the user interface or control interface further includes information based on authentication and authorization level information associated with the wireless device. 
     An example embodiment of the invention includes a method comprising: 
     wherein the controlling interaction of the wireless device with the controllable device comprises: 
     receiving one or more controls from the wireless device, the one or more controls being based on the information associated with the user interface or control interface; and 
     transmitting commands to the controllable device corresponding to the one or more controls. 
     An example embodiment of the invention includes an apparatus comprising: 
     at least one processor; 
     at least one memory including computer program code; 
     the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to: 
     receive a message from a proximate device via a short-range communication connection, the message including at least ID information associated with the proximate device; 
     compile a request message including at least the ID information associated with the proximate device and information identifying said apparatus; 
     transmit the compiled request message to a remote server for accessing control to the proximate device; 
     receive information associated with a user interface or control interface for interacting with the proximate device via the remote server, the received information including a set of one or more controls allowing the apparatus to interact with the proximate device through the remote server access control and being based on the information included in the transmitted request message; 
     compile a user interface or control interface for enabling a user of said apparatus to interact with the proximate device based on the received information, the compiled user interface or control interface including access rights for interacting with the proximate device via the server access control depending on the information included in the transmitted request message; and 
     interact with the proximate device via the remote server access control using the compiled user interface or control interface. 
     An example embodiment of the invention includes an apparatus comprising: 
     wherein the message received from the proximate device further includes information for accessing the remote server and an indication of RSSI information ensuring close proximity of the proximate device. 
     An example embodiment of the invention includes an apparatus comprising: 
     wherein the request message further includes authentication information associated with a user of the apparatus, to the server. 
     An example embodiment of the invention includes an apparatus comprising: 
     wherein the information received associated with the user interface or control interface for interacting with the proximate device further includes authentication and authorization level information, to the proximate device. 
     An example embodiment of the invention includes an apparatus comprising: 
     wherein the user interface or control interface compiled by the apparatus further includes information based on the authentication and authorization level information, to the proximate device. 
     An example embodiment of the invention includes an apparatus comprising: 
     the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to: 
     increase access rights for the user interface or control interface for interacting with the proximate device by providing additional authentication information associated with the user of the apparatus to the remote server. 
     An example embodiment of the invention includes an apparatus comprising: 
     the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to: 
     measure signal strength of the message from the proximate device; and 
     detect whether the apparatus is in close proximity to the proximate device, based on the measured signal strength of the message from the proximate device. 
     An example embodiment of the invention includes an apparatus comprising: 
     at least one processor; 
     at least one memory including computer program code; 
     the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to: 
     transmit to a controllable device, ID information that is to be associated with the controllable device; 
     receive a request message from a wireless device via a communication connection, the request message including at least a request for accessing control to the controllable device and the ID information associated with the controllable device; 
     transmit to the wireless device, information associated with a user interface or control interface for interacting with the controllable device based on remote access control through the apparatus, the transmitted information including a set of one or more controls allowing the wireless device to interact with the controllable device through the apparatus access control and based on the information included in the received request message; and 
     control interaction of the wireless device with the controllable device, based on the information associated with the user interface or control interface. 
     An example embodiment of the invention includes an apparatus comprising: 
     wherein the request message further includes authentication information associated with a user of the wireless device, to the apparatus. 
     An example embodiment of the invention includes an apparatus comprising: 
     wherein the request message further includes authentication information associated with an identifier of the wireless device, to the apparatus. 
     An example embodiment of the invention includes an apparatus comprising: 
     wherein the transmitted information associated with the user interface or control interface further includes information based on authentication and authorization level information associated with the wireless device. 
     An example embodiment of the invention includes an apparatus comprising: 
     wherein the controlling interaction of the wireless device with the controllable device comprises: 
     the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to: 
     receive one or more controls from the wireless device, the one or more controls being based on the information associated with the user interface or control interface; and 
     transmit commands to the controllable device corresponding to the one or more controls. 
     An example embodiment of the invention includes a computer program product comprising computer executable program code recorded on a computer readable, non-transitory storage medium, the computer executable program code comprising: 
     code for receiving, by an apparatus, a message from a proximate device via a short-range communication connection, the message including at least ID information associated with the proximate device; 
     code for compiling, by the apparatus, a request message including at least the ID information associated with the proximate device and information identifying said apparatus; 
     code for transmitting, by the apparatus, the compiled request message to a remote server for accessing control to the proximate device; 
     code for receiving, by the apparatus, information associated with a user interface or control interface for interacting with the proximate device via the remote server, the received information including a set of one or more controls allowing the apparatus to interact with the proximate device through the remote server access control and being based on the information included in the transmitted request message; 
     code for compiling, by the apparatus, a user interface or control interface for enabling a user of said apparatus to interact with the proximate device based on the received information, the compiled user interface or control interface including access rights for interacting with the proximate device via the server access control depending on the information included in the transmitted request message; and 
     code for interacting, by the apparatus, with the proximate device via the remote server access control using the compiled user interface or control interface. 
     An example embodiment of the invention includes a computer program product comprising computer executable program code recorded on a computer readable, non-transitory storage medium, the computer executable program code comprising: 
     code for transmitting, by an apparatus, to a controllable device, ID information that is to be associated with the controllable device; 
     code for receiving, by the apparatus, a request message from a wireless device via a communication connection, the request message including at least a request for accessing control to the controllable device and the ID information associated with the controllable device; 
     code for transmitting, by the apparatus, to the wireless device, information associated with a user interface or control interface for interacting with the controllable device based on remote access control through the apparatus, the transmitted information including a set of one or more controls allowing the wireless device to interact with the controllable device through the apparatus access control and based on the information included in the received request message; and 
     code for controlling, by the apparatus, interaction of the wireless device with the controllable device, based on the information associated with the user interface or control interface. 
     The resulting example embodiments enhance wireless control of devices through an intermediate server, using information received from the proximate devices via short range communication. 
    
    
     
       DESCRIPTION OF THE FIGURES 
         FIG. 1  is an illustration of an example embodiment of a network with a mobile wireless control device, a wireless medical device, such as a gateway health device, and a remote server, such as a cloud server. The figure shows example steps in wireless remote control of the wireless medical device by the control device through the intermediate remote server, in accordance with at least one embodiment of the present invention. 
         FIG. 2  is an illustration of an example embodiment of the network of  FIG. 1 , wherein in step  1  of  FIG. 1 , the remote server transmits to the wireless medical device, ID information associated with a wireless medical device. The wireless medical device may be, for example, an external pump unit of a patient-implanted infusion pump, in accordance with at least one embodiment of the present invention. 
         FIG. 3A  is an illustration of an example embodiment of the network of  FIG. 2 , wherein the wireless medical device determines that it is in proximity to the control device operated by a medical practitioner. The proximity determination may be based on measurements of signal strength of wireless signals from the control device, in accordance with at least one embodiment of the present invention. 
         FIG. 3B  is an illustration of an example embodiment of the network of  FIG. 3A , wherein, in step  2  of  FIG. 1 , in response to determining that it is proximate to the control device, the wireless medical device transmits a wireless message to the control device via a short-range technology, such as Bluetooth Low Energy (BTLE) advertising message. The message includes at least the ID information associated with the medical device, in accordance with at least one embodiment of the present invention. 
         FIG. 4  is an illustration of an example embodiment of the network of  FIG. 3A , wherein in step  3  of  FIG. 1 , the control device may confirm the proximity of the wireless medical device by means of the signal strength of the received wireless message. The control device then compiles a request message including at least the ID information associated with the proximate medical device and information identifying said apparatus. The request message may further include authentication information associated with the user of the control device, to the server. The control device then transmits the compiled request message to the remote server for accessing control to the proximate medical device, in accordance with at least one embodiment of the present invention. 
         FIG. 5  is an illustration of an example embodiment of the network of  FIG. 3A , wherein in step  4  of  FIG. 1 , the remote server checks the authentication information associated with the user of the control device. The remote server then transmits to the control device, information associated with a user interface for interacting with the wireless device based on remote access control by the control device through the apparatus. The user interface is based on the information included in the received request message. The remote server includes in the transmitted information, authentication and authorization level information, to authenticate it to the proximate device, in accordance with at least one embodiment of the present invention. 
         FIG. 6  is an illustration of an example embodiment of the network of  FIG. 3A , wherein in steps  5  and  6  of  FIG. 1 , the control device compiles the user interface for enabling the user of the apparatus to interact with the proximate medical device based on the received information. The compiled user interface includes access rights for interacting with the proximate medical device via remote server access control. The access rights depend on the authentication information associated with the user included in the transmitted request message from the control device. The access rights may be increased for the user interface for interacting with the proximate medical device, by providing additional authentication information associated with the user of the control device, to the remote server. The control device then transmits control messages to the remote server, for control of the proximate medical device, for interaction of the control device with the proximate medical device via the remote access control, based on the information associated with a user interface, in accordance with at least one embodiment of the present invention. 
         FIG. 7A  is an illustration of an example format for the Bluetooth™ Low Energy protocol (BTLE) advertising messages, in accordance with at least one embodiment of the present invention. 
         FIG. 7B  is an illustration of an example simplified format for a WLAN message sent by the control device to the remote server, its request for the user interface, in accordance with at least one embodiment of the present invention. 
         FIG. 7C  is an illustration of an example simplified format for a WLAN message sent by the remote server to the control device, with the user interface, in accordance with at least one embodiment of the present invention. 
         FIG. 7D  is an illustration of an example simplified format for a WLAN message sent by the control device to the remote server, for control of the medial device, in accordance with at least one embodiment of the present invention. 
         FIG. 7E  is an illustration of an example simplified format for a WLAN message sent by the remote server to the medical device, that has been transmitted from the control device, in accordance with at least one embodiment of the present invention. 
         FIG. 8A  is an illustration of an example flow diagram of an example process in the remote server, carrying out the example operations for providing the user interface to the control device, in accordance with at least one embodiment of the present invention. 
         FIG. 8B  is an illustration of an example flow diagram of an example process in the remote server, carrying out the example operations for control interactions from the control device to the medical device, in accordance with at least one embodiment of the present invention. 
         FIG. 9A  is an illustration of an example flow diagram of an example process in the control device, carrying out the example operations, in accordance with at least one embodiment of the present invention. 
         FIG. 9B  is an illustration of an example flow diagram of an example process in the remote server, carrying out the example operations, in accordance with at least one embodiment of the present invention. 
         FIG. 10  illustrates an example embodiment of the invention, wherein examples of removable storage media are shown, based on magnetic, electronic and/or optical technologies, such as magnetic disks, optical disks, semiconductor memory circuit devices and micro-SD memory cards (SD refers to the Secure Digital standard) for storing data and/or computer program code as an example computer program product, in accordance with at least one embodiment of the present invention. 
       The group of  FIGS. 11A to 11G  illustrates an example case of a server providing a user interface (UI) based on a detected proximity between a mobile wireless device and a controllable device. 
         FIG. 11A  is an illustration of an example embodiment of a network with a mobile wireless device and a controllable device. The mobile wireless device is shown scanning for Bluetooth™ Low Energy protocol (BTLE) advertising messages. The controllable device is shown transmitting BTLE advertising messages containing its identification and, optionally, a description of the controllable device capabilities. When the controllable device in the advertising state, enters the connection state, it will be in the slave role and the mobile wireless device will be in the master role in a BTLE data channel, in accordance with at least one embodiment of the present invention. In an alternate embodiment, the mobile wireless device may receive the device identifier from a remote server and the mobile wireless device may find the device locally. In the alternate embodiment, the mobile wireless device may also receive a user interface and connectivity data from the remote server, as shown in  FIG. 11C , and the mobile wireless device may find the device locally and start communicating with the device based on the received information. 
         FIG. 11B  is an illustration of an example embodiment of the network of  FIG. 11A , wherein the user function to be performed is mechanical service/repair. The mobile wireless device is shown sending to the cloud server, a message for example over a WLAN or cellular connection. The device may send an HTTP request over a WLAN or cellular connection via the Internet to the server. The message may contain information including its ID, user ID, user function: mechanical service/repair, display type: screen&#39;s parameters, location: lat/lon; factory floor; pump room, controllable device id: pump XYZ, and its request for the user interface: mechanical service panel, in accordance with at least one embodiment of the present invention. 
         FIG. 11C  is an illustration of an example embodiment of the network of  FIG. 11B , wherein the cloud server uses the information received from the mobile wireless device, to access from a mapping database, data describing a user interface that characterizes the specified type of controlled device. The cloud server formats the user interface for display on the specified type of display of the mobile wireless device. The cloud server may access a connectivity database to obtain connectivity information. The cloud server sends the user interface and the connectivity data in a message for example over a WLAN or cellular connection via the Internet to the mobile wireless device. The message may contain the formatted user interface: mechanical service panel. 
         FIG. 11D  is an illustration of an example embodiment of the network of  FIG. 11C , wherein the user of the mobile wireless device used the mechanical service panel user interface displayed, to monitor and/or control the controllable device, by sending a BTLE mechanical control message to the controllable device. 
         FIG. 11E  is an illustration of an example embodiment of the network of  FIG. 11B , wherein the user function to be performed is electrical service/repair. The mobile wireless device is shown sending to the cloud server, a message for example over a WLAN or cellular connection, containing information including its ID, user function: electrical service/repair, display type: screen&#39;s parameters, location: lat/lon; factory floor; pump room, controllable device id: pump XYZ, and its request for the user interface: electrical service panel. 
         FIG. 11F  is an illustration of an example embodiment of the network of  FIG. 11E , wherein the cloud server uses the information received from the mobile wireless device, to access from a mapping database, data describing a user interface that characterizes the specified type of controlled device. The cloud server formats the user interface for display on the specified type of display of the mobile wireless device. The cloud server may access a connectivity database to obtain connectivity information, which the cloud server uses to send a message for example over a WLAN or cellular connection, containing the formatted user interface: electrical service panel. 
         FIG. 11G  is an illustration of an example embodiment of the network of  FIG. 11F , wherein the user of the mobile wireless device used the electrical service panel user interface displayed, to monitor and/or control the controllable device, by sending a BTLE electrical control message to the controllable device. 
       The group of  FIGS. 12 to 12D  illustrates an example security enhancement to the example embodiment shown in the group of  FIGS. 11A to 11G , to make the user interface control concept more secure. 
         FIG. 12  is an illustration of an example embodiment of a message flow for a cloud-controlled Bluetooth LE device wakeup of a controllable device. The controlled device initially stays hidden, not advertising its presence, in accordance with at least one embodiment of the present invention. 
         FIG. 12A  is an illustration of an example embodiment of the controllable device of  FIG. 12 , receiving and handling the Bluetooth LE advertisement, in accordance with at least one embodiment of the present invention. 
         FIG. 12B  is an illustration of an example embodiment of the network of  FIG. 11B , wherein the mobile wireless device is shown sending to the cloud server, a message for example over a WLAN or cellular connection, over a secure channel, containing an update of the current location of the mobile wireless device (for example, its latitude and longitude, and environment, such as a factory floor and pump room) and its request for available controllable devices in its area. The figure shows the cloud server, in response, accessing a database to retrieve information about a controllable device in the area of the mobile wireless device, the information including a first public key and a second public key of the controllable device, a sequence number, and a user access profile of the mobile wireless device. The figure shows the cloud server transmitting to the mobile wireless device, a reply message including at least the second public key and an encrypted object that is the first public key encrypting at least the sequence number and user access profile, in accordance with at least one embodiment of the present invention. 
         FIG. 12C  is an illustration of an example embodiment of the network of  FIG. 11A , wherein the mobile wireless device transmits to the controllable device, one or more Bluetooth™ Low Energy protocol (BTLE) advertisement messages containing the encrypted object and the user ID that have been further encrypted with the second public key of the controllable device, wherein the encrypted object is at least the sequence number and user access profile, encrypted with the first public key of the controllable device, in accordance with at least one embodiment of the present invention. 
         FIG. 12D  is an illustration of an example embodiment of the network of  FIG. 12C , wherein the controllable device decrypts the advertisement message and the encrypted object, to assess the validity of the sequence number and the user access profile. If the controllable device determines that the sequence number and the user access profile are valid, then the controllable device reveals its presence by transmitting a BTLE advertisement containing information identifying the controllable device, in accordance with at least one embodiment of the present invention. 
       The group of  FIGS. 13 to 13G  illustrates an example extension of the example embodiment shown in the group of  FIGS. 11A to 11G , wherein a common user interface is constructed from a group of controllable devices that are in proximity to the mobile wireless device. The figures further illustrate an example embodiment where the user interface that is changed based on the proximity of the mobile wireless device to a particular controllable device in the group. 
         FIG. 13  is an illustration of an example embodiment of the network of  FIG. 11A , wherein two controllable devices are located in a pump room: a valve and a pump. The valve is a controllable device located near an entrance of the pump room and the pump is a controllable device located farther from the entrance, in the interior of the pump room. The mobile wireless device is shown located outside of the pump room at a distance X 1  from the nearer valve and at a distance X 2  from the farther pump, in accordance with at least one embodiment of the present invention. 
         FIG. 13A  is an illustration of an example embodiment of the network of  FIG. 13 , wherein a schematic diagram of the pump room is displayed on the mobile wireless device, as a user interface when the mobile device is farther than a proximate distance from either the valve or the pump. A mechanical service panel is displayed as a user interface for the valve when the mobile device is near to a distance X 1  from the valve. An electrical service panel is displayed as a user interface for the pump when the mobile device is near to a distance X 2  from the pump, in accordance with at least one embodiment of the present invention. 
         FIG. 13B  is an illustration of an example embodiment of the network of  FIG. 11B , wherein the mobile device is farther than a proximate distance from either the valve or the pump. The mobile wireless device detects the presence of the BTLE device advertising message, but the detected distance is greater than X 0 . The mobile wireless device is shown sending to the cloud server, a message for example over a WLAN or cellular connection, containing information including its ID, user function: all service/repair, display type: screen&#39;s parameters, location: lat/lon; factory floor; pump room, controllable device valve  102 A, and its request for an appropriate user interface, in accordance with at least one embodiment of the present invention. 
         FIG. 13C  is an illustration of an example embodiment of the network of  FIG. 13B , wherein the cloud server uses the information received from the mobile wireless device, to access from a mapping database, data describing an appropriate user interface corresponding to the specified type of controlled device. Since the mobile wireless device has detected the presence of the valve  102 A, but the detected distance is greater than X 0 , the cloud server accesses a schematic diagram of the pump room where the valve  102 A is located, which is to serve as the user interface. The cloud server formats the user interface for display on the specified type of display of the mobile wireless device. The cloud server may access a connectivity database to obtain connectivity information, which the cloud server uses to send a message for example over a WLAN or cellular connection, containing the formatted user interface: the schematic diagram of the pump room, in accordance with at least one embodiment of the present invention. 
         FIG. 13D  is an illustration of an example embodiment of the network of  FIG. 13C , wherein the mobile wireless device has moved closer to the valve  102 A. The mobile wireless device is shown sending to the cloud server, a message for example over a WLAN or cellular connection, containing information including its ID, user function: all service/repair, display type: screen&#39;s parameters, location: lat/lon; factory floor; pump room, controllable device id: valve  102 A, and its request for the user interface appropriate for the valve  102 A, in accordance with at least one embodiment of the present invention. 
         FIG. 13E  is an illustration of an example embodiment of the network of  FIG. 13D , wherein the cloud server uses the information received from the mobile wireless device, to access from the mapping database, data describing a user interface, a mechanical service panel, which characterizes the specified type of controlled device, the valve  102 A. The cloud server formats the user interface for display on the specified type of display of the mobile wireless device. The cloud server may access a connectivity database to obtain connectivity information, which the cloud server uses to send a message for example over a WLAN or cellular connection, containing the formatted user interface: mechanical service panel, in accordance with at least one embodiment of the present invention. 
         FIG. 13F  is an illustration of an example embodiment of the network of  FIG. 13E , wherein the mobile wireless device has moved closer to the pump  102 B. The mobile wireless device is shown sending to the cloud server, a message for example over a WLAN or cellular connection, containing information including its ID, user function: all service/repair, display type: screen&#39;s parameters, location: lat/lon; factory floor; pump room, controllable device id: pump  102 B, and its request for the user interface appropriate for the pump  102 B, in accordance with at least one embodiment of the present invention. 
         FIG. 13G  is an illustration of an example embodiment of the network of  FIG. 13F , wherein the cloud server uses the information received from the mobile wireless device, to access from a mapping database, data describing a user interface, an electrical service panel, which characterizes the specified type of controlled device, the pump  102 B. The cloud server formats the user interface for display on the specified type of display of the mobile wireless device. The cloud server may access a connectivity database to obtain connectivity information, which the cloud server uses to send a message for example over a WLAN or cellular connection, containing the formatted user interface: electrical service panel, in accordance with at least one embodiment of the present invention. 
       The group of  FIGS. 14A to 14D  illustrates an example extension of the example embodiment shown in the group of  FIGS. 11A to 11G , wherein the user interface is preloaded into a cache of the mobile wireless device from the server, to enable offline use of the user interfaces, which are invoked only when a corresponding controllable device is detected to be in proximity. The offline use may be enabled on a per user, per area, per controllable device, or per time, basis. 
         FIG. 14A  is an illustration of an example embodiment of the network of  FIG. 11B , wherein the mobile wireless device is shown sending to the cloud server, a message for example over a WLAN or cellular connection, requesting preloading of user interfaces characterizing controllable devices in the current area of mobile wireless device, formatted for display on mobile wireless device. The cloud server uses the information received from the mobile wireless device, to access from a mapping database, data describing appropriate user interfaces corresponding to controlled devices in the current area of the mobile wireless device. The figure shows the cloud server responding with a reply message including the requested user interfaces characterizing controllable devices, the pump XYZ, in the area of the mobile wireless device, formatted for display on the mobile wireless device. The requested user interfaces for the pump XYZ are preloaded into a cache in the mobile wireless device, in accordance with at least one embodiment of the present invention. 
         FIG. 14B  is an illustration of an example embodiment of the network of  FIG. 13 , wherein a mechanical service panel is displayed as a user interface for the pump XYZ when the mobile device is near to a distance X 1  from the pump. An electrical service panel is displayed as a user interface for the pump XYZ when the mobile device is near to a distance X 2  from the pump, in accordance with at least one embodiment of the present invention. 
         FIG. 14C  is an illustration of an example embodiment of the network of  FIG. 14B , wherein the mobile wireless device has moved closer at a distance X 1  to the pump. The mobile wireless device is shown accessing the mechanical service panel from its cache for display as a user interface for the pump, when the mobile device is near to a distance X 1  from the pump, in accordance with at least one embodiment of the present invention. 
         FIG. 14D  is an illustration of an example embodiment of the network of  FIG. 14B , wherein the mobile wireless device has moved closer at a distance X 2  to the pump. The mobile wireless device is shown accessing the electrical service panel from its cache for display as a user interface for the pump, when the mobile device is near to a distance X 2  from the pump, in accordance with at least one embodiment of the present invention. 
       The group of  FIGS. 15A to 15D  illustrates an example extension of the example embodiment shown in the group of  FIGS. 11A to 11G . 
         FIG. 15A  is an illustration of an example embodiment of the network of  FIG. 11A , wherein, the mobile wireless device detects whether it is in close proximity to the detected device based on measuring a signal strength value of the one or more received wireless messages. 
         FIG. 15B  is an illustration of an example embodiment of the network of  FIG. 11B , wherein, the mobile wireless device transmits a request message to the remote server, requesting one or more user interfaces corresponding to one or more user functions to be performed, in response to the detecting that the apparatus is in close proximity to the detected device. The figure shows the mobile wireless device receiving from the remote server, a first user interface corresponding to a first close proximity to the detected device based on a first signal strength value of the one or more received wireless messages, a second user interface corresponding to a second close proximity to the detected device based on a second signal strength value of the one or more received wireless messages, and the first and second signal strength values. The figure shows the mobile wireless device preloading into its cache, the first and second user interfaces and the first and second signal strength values received from the remote server. 
         FIG. 15C  is an illustration of an example embodiment of the network of  FIG. 14C , wherein, the mobile wireless device may then invoke the first user interface when it detects it is located at the first close proximity based on measuring the first signal strength value. 
         FIG. 15D  is an illustration of an example embodiment of the network of  FIG. 14D , wherein, the mobile wireless device may then and invoke the second user interface when it detects it is located at the second close proximity based on measuring the second signal strength value. 
         FIG. 16  is an illustration of an example flow diagram of an example process in the cloud server, carrying out the example operations, in accordance with at least one embodiment of the present invention. 
         FIG. 17A  is an illustration of an example flow diagram of an example process in the mobile wireless device, carrying out the example operations, in accordance with at least one embodiment of the present invention. 
         FIG. 17B  is an illustration of an example flow diagram of an example process in the cloud server, carrying out the example operations, in accordance with at least one embodiment of the present invention. 
     
    
    
     DISCUSSION OF EXAMPLE EMBODIMENTS OF THE INVENTION 
     This section is organized into the following topics: 
     A. Wireless Short-Range Communication Networks 
     B. Bluetooth™ Low Energy (BTLE) Technology 
     C. Touch-to-Select in Bluetooth Technology 
     D. Local Control Through Intermediate Device 
     E. Local Device Control for Bluetooth™ Low Energy (BTLE) 
     A. Wireless Short-Range Communication Networks 
     Short-range communication technologies provide communication solutions appropriate for many data applications, without the cost, traffic and legislative concerns of longer-range communication technologies. Popular short-range communication technologies include Bluetooth basic rate/enhanced data rate (BR/EDR), Bluetooth Low Energy (BTLE), IEEE 802.11 wireless local area network (WLAN), IEEE 802.15.4, and near field communication technologies, such as radio frequency identification (RFID) and near field communication (NFC) technology that enable contactless identification and interconnection of wireless devices. Bluetooth Technology provides an example of wireless short-range communication establishment. 
     B. Bluetooth™ Low Energy (BTLE) Technology 
     The Bluetooth™ Core Specification, Version 4.1 includes the Bluetooth™ LE protocol for products that require lower power consumption, lower complexity, and lower cost than would be possible using the Bluetooth™ BR/EDR protocol. Bluetooth LE is designed for applications requiring lower data rates and shorter duty cycles, with a very-low power idle mode, a simple device discovery, and short data packets. Bluetooth LE devices may employ a star topology, where one device serves as a master for a plurality of slave devices, the master dictating connection timing by establishing the start time of the first connection event and the slave devices transmitting packets only to the master upon receiving a packet from the master. According to Bluetooth LE communication protocol all connections are point-to-point connections between two devices (the master and the slave). 
     The Bluetooth LE protocol allows a star network topology in connections, where one device serves as a master for a plurality of slave devices. The master device dictates the connection timing and communication operations of the one or more slave devices. Bluetooth LE communicates over a total of 40 RF channels, separated by 2 MHz. Data communication between Bluetooth LE devices occurs in 37 pre-specified data channels, of the 40 RF channels. All data connection transmissions occur in connection events wherein a point-to-point connection is established between the master device and a slave device. In the Bluetooth LE protocol, a slave device provides data through Bluetooth LE communication to the master device to which it is connected. The remaining 3 channels, of the 40 RF channels, are advertising channels used by devices to advertise their existence and capabilities. The Bluetooth LE protocol defines a unidirectional connectionless broadcast mode on the advertising channels. 
     The Link Layer provides a state machine with the following five states: Standby State, Advertising State, Scanning State, Initiating State, and Connection State. The Link Layer state machine allows only one state to be active at a time. The Link Layer in the Standby State does not transmit or receive any packets and can be entered from any other state. The Link Layer in the Advertising State will be transmitting advertising channel packets and possibly listening to and responding to responses triggered by these advertising channel packets. A device in the Advertising State is known as an advertiser. The Advertising State can be entered from the Standby State. The Link Layer in the Scanning State will be listening for advertising channel packets from devices that are advertising. A device in the Scanning State is known as a scanner. The Scanning State can be entered from the Standby State. The Link Layer in the Initiating State will be listening for advertising channel packets from a specific device and responding to these packets to initiate a connection with that specific device. A device in the Initiating State is known as an initiator. The Initiating State can be entered from the Standby State. The Connection State of the Link Layer may be entered either from the Initiating State or the Advertising State. A device in the Connection State is known as being in a connection over a data channel. Within the Connection State, two roles are defined: the Master Role and the Slave Role. When a device in the Initiating State, enters the Connection State, it is in the Master Role, it exchanges data packets with a slave device in a data channel, and it defines the timings of transmissions. When a device in the Advertising State, enters the Connection State, it is in the Slave Role and exchanges data packets with a master device in a data channel, wherein the master device defines the timings of transmissions. 
     The Bluetooth LE radio operates in the unlicensed 2.4 GHz ISM band, in the same manner as does the Bluetooth Basic Rate/Enhanced Data Rate (BR/EDR) radio. Bluetooth LE supports very short data packets, from 10 octets to a maximum of 47 octets, giving it a low duty cycle. Bluetooth LE employs a frequency hopping transceiver with many frequency hopping spread spectrum (FHSS) carriers, with a bit rate of 1 Megabit per second (Mb/s). 
     Bluetooth LE employs two multiple access schemes: Frequency division multiple access (FDMA) and time division multiple access (TDMA). Forty (40) physical channels, separated by 2 MHz, are used in the FDMA scheme. Three (3) are used as advertising channels and 37 are used as data channels. A TDMA based polling scheme is used in which one device transmits a packet at a predetermined time and a corresponding device responds with a packet after a predetermined interval. 
     The physical channel is sub-divided into time units known as events. Data is transmitted between Bluetooth LE devices in packets that are positioned in these events. There are two types of events: Advertising and Connection events. 
     Devices that transmit advertising packets on the advertising Physical Layer (PHY) channels are referred to as advertisers. Devices that receive advertising on the advertising channels without the intention to connect to the advertising device are referred to as scanners. Devices that form a connection to another device by listening for connectable advertising packets, are referred to as initiators. Transmissions on the advertising PHY channels occur in advertising events. 
     In the Bluetooth™ Core Specification, Version 4.1, there are four advertising event types: connectable undirected advertising (ADV_IND), connectable directed advertising (ADV_DIRECT_IND), scannable undirected advertising (ADV_SCAN_IND), and non-connectable undirected advertising (ADV_NONCONN_IND). At the start of each advertising event, the advertiser sends an advertising packet corresponding to the advertising event type. The header of the advertising channel packet identifies the packet type in a four-bit PDU Type field encoding. There are seven values currently assigned to the four-bit PDU Type field, ranging from 0000 to 0110, with the values 0111 to 1111 being reserved for future use. 
     The scanner device, also referred to as the initiator device, that receives the advertising packet, may make a connect request (CONNECT_REQ) to the advertiser device on the same advertising PHY channel. The CONNECT_REQ request includes fields for access address AA, CRC, WinSize, WinOffset, Interval, Latency, Timeout, ChannelMap, Hop count, and sleep clock accuracy SCA. The four-bit PDU Type field in the header of the CONNECT_REQ advertising channel packet, is 0101. When the advertiser device accepts the CONNECT_REQ request, a point-to-point connection results between the scanner/initiator device that becomes the master device, and the advertiser device that becomes the slave device in a piconet. The master and the slave devices know at what time and in which frequency the connection is in operation. The data channel changes between every connection event and the start of connection events are spaced regularly with the connection interval that is provided in the CONNECT_REQ packet. 
     In the connectable undirected advertising (ADV_IND) channel packet, the ADV_IND PDU has a payload field containing AdvA and AdvData fields. The AdvA field contains the advertiser&#39;s public or random device address and the AdvData field may contain Advertising data from the advertiser&#39;s host. The PDU may be used in connectable undirected advertising events. The four-bit PDU Type field in the header of the ADV_IND advertising channel packet, is 0000. 
     In the connectable directed advertising (ADV_DIRECT_IND) channel packet, the ADV_DIRECT_IND PDU has the payload field containing AdvA and InitA fields. The AdvA field contains the advertiser&#39;s public or random device address. The InitA field is the address of the device to which this PDU is addressed. The InitA field may contain the initiator&#39;s public or random device address. The PDU may be used in connectable directed advertising events. This packet may not contain any host data. The four-bit PDU Type field in the header of the ADV_DIRECT_IND advertising channel packet, is 0001. 
     In a non-connectable undirected event type advertising channel packet, ADV_NONCONN_IND, a scanner device is allowed to receive information in the advertising channel packet, but scanner devices are not allowed to transmit anything in the advertising channels upon receiving the ADV_NONCONN_IND advertising channel packets. When the non-connectable undirected event type is used, non-connectable advertising indications ADV_NONCONN_IND packets are sent by the Link Layer. The non-connectable undirected event type allows a scanner to receive information contained in the ADV_NONCONN_IND from the advertiser. The advertiser may either move to the next used advertising channel index or close the advertising event after each ADV_NONCONN_IND that is sent. The four-bit PDU Type field in the header of the ADV_NONCONN_IND advertising channel packet, is 0010. 
     In the scannable undirected advertising (ADV_SCAN_IND) channel packet, the ADV_SCAN_IND PDU has the payload field containing AdvA and AdvData fields. The AdvA field contains the advertiser&#39;s public or random device address. The PDU may be used in scannable undirected advertising events. The AdvData field may contain Advertising Data from the advertiser&#39;s host. The four-bit PDU Type field in the header of the ADV_SCAN_IND advertising channel packet, is 0110. 
     In the Bluetooth™ Core Specification, Version 4.1, if the advertiser is using a connectable advertising event, an initiator may make a connection request using the same advertising PHY channel on which it received the connectable advertising packet. The advertising event is ended and connection events begin if the advertiser receives and accepts the request for a connection to be initiated. Once a connection is established, the initiator becomes the master device in a piconet and the advertising device becomes the slave device. Within a connection event, the master and slave alternate sending data packets using the same data PHY channel. 
     According to the Bluetooth™ Specification V4.1, Bluetooth LE device discovery involves different operational processes for devices with different roles. In particular:
         Slave Device, being an advertiser, performs an advertising process during which the device repeatedly enters Advertising Events. The interval of each start of Advertising Event, Ta, composes of a fixed-length “advInterval” and a random-length “advDelay”. In Advertising Event, the device sends advertising Packet Data Units (PDUs) in broadcasting channel 37, 38 and 39, respectively.   Master Device, being an initiator/scanner, performs the initiating/scanning process. An initiating/scanning process consists of repeated “scanInterval”, each of which contains a “scanWindow”. In a different “scanWindow”, the device changes the RF module to receive the state and listens to advertising PDUs on different broadcasting channels; while out of the “scanWindow”, it does routine scheduling, or turns off the RF module.       

     If any advertising PDU is received by an initiator/scanner, it means the initiator/scanner successfully discovers the advertising device. For the initiator, it can directly send back a “CONNECT_REQ” to establish a connection with that advertiser. For a scanner, it can send out a “SCAN_REQ” to ask for more information from that advertiser. 
     The CONNECT_REQ PDU has a payload field that consists of InitA, AdvA and LLData fields. The InitA field contains the Initiator&#39;s public or random device address, as indicated by a transmit address flag. The AdvA field contains the advertiser&#39;s public or random device address, as indicated by a receive address flag. The LLData consists of 10 fields, such as the Link Layer connection&#39;s Access Address, a channel map, a hop count increment, and other parameters needed to set up the connection. 
     The SCAN_REQ PDU has a payload field that consists of ScanA and AdvA fields. The ScanA field contains the scanner&#39;s public or random device address, as indicated by a transmit address flag. The AdvA field is the address of the device to which this PDU is addressed and contains the advertiser&#39;s public or random device address, as indicated by a receive address flag. 
     Example non-limited use cases for Bluetooth LE technology include sports and fitness, security and proximity and smart energy. Bluetooth LE technology is designed for devices to have a battery life of up to one year such as those powered by coin-cell batteries. These types of devices include watches that will utilize Bluetooth LE technology to display Caller ID information and sports sensors that will be utilized to monitor the wearer&#39;s heart rate during exercise. The Medical Devices Working Group of the Bluetooth SIG is also creating a medical devices profile and associated protocols to enable Bluetooth applications for Bluetooth LE devices. 
     A Bluetooth LE advertising channel may be shared by any number of Bluetooth LE devices. Any number of Bluetooth LE devices may transmit advertising packets while sharing the same three advertising PHY channels. In high-density environments, however, since there are a large number of nodes to be discovered, the probability of broadcasting conflict will inevitably increase, causing network access time to increase, and also lowering the energy efficiency of the whole network. 
     1. Bluetooth™ LE Discovery: 
     At the start of each advertising event, the advertiser sends an advertising packet corresponding to the advertising event type. Depending on the type of advertising packet, the scanner may make a request to the advertiser on the same advertising PHY channel which may be followed by a response from the advertiser on the same advertising PHY channel. The advertising PHY channel changes on the next advertising packet sent by the advertiser in the same advertising event. The advertiser may end the advertising event at any time during the event. The first advertising PHY channel is used at the start of the next advertising event. 
     Initiator devices that are trying to form a connection to another device listen for connectable advertising packets. If the advertiser is using a connectable advertising event, an initiator may make a connection request using the same advertising PHY channel on which it received the connectable advertising packet. The advertising event is ended and connection events begin if the advertiser receives and accepts the request for a connection be initiated. Once a connection is established, the initiator becomes the master device in a piconet and the advertising device becomes the slave device. Connection events are used to send data packets between the master and slave devices. 
     The format of Advertising data and Scan Response data consists of a significant part and a non-significant part. The significant part contains a sequence of AD structures. Each AD structure shall have a Length field of one octet, which contains the Length value, and a Data field of Length octets. The first octet of the Data field contains the AD type field. The content of the remaining Length−1 octet in the Data field depends on the value of the AD type field and is called the AD data. The non-significant part extends the Advertising and Scan Response data to 31 octets and shall contain all-zero octets. 
     Devices are identified using a device address. Device addresses may be either a public device address or a random device address. A public device address and a random device address are both 48 bits in length. A device shall contain at least one type of device address and may contain both. 
     The public device address shall be created in accordance with section 9.2 (“48-bit universal LAN MAC addresses”) of the IEEE 802-2001 standard (http://standards. ieee.org/getieee802/download/802-2001.pdf) and using a valid Organizationally Unique Identifier (OUI) obtained from the IEEE Registration Authority (http://standardsleee.org/regauth/oui/forms/ and sections 9 and 9.1 of the IEEE 802-2001 specification). 
     The public device address is divided into the following two fields:
         company_assigned field is contained in the 24 least significant bits   company_id field is contained in the 24 most significant bits.       

     For the purposes of this profile, the random device address may be of either of the following two sub-types:
         Static address   Private address       

     The private address may be of either of the following two sub-types:
         Non-resolvable private address   Resolvable private address       

     Static and non-resolvable private address both contains address that is random. The main difference is that the device shall not change its static address value once initialized until the device is power cycled. 
     The random resolvable private device address is divided into the following two fields which can be used to identify the device:
         hash field is contained in the 24 least significant bits, as defined in Bluetooth™ Core Specification, Version 4.1 [Vol. 3] Part C, Section 10.8.2.3.   random field is contained in the 24 most significant bits, as defined in Bluetooth™ Core Specification, Version 4.1 [Vol. 3] Part C, Section 10.8.2.2.       

     2. Bluetooth™ Low Energy (BTLE) Pairing and Bonding 
     Pairing and key distribution over a BTLE physical link is defined by the Security Manager specification (Bluetooth™ Core Specification, Version 4.1 [Vol. 3], Part H Section 2.3). The pairing process may be initiated if either slave or master device request pairing to enable link encryption and possible authentication. 
     The purpose of bonding is to create a relation between two Bluetooth devices based on a stored security and identity information. A transport specific key distribution is performed during pairing process to share the keys which can be used to encrypt a link in future reconnections, verify signed data and random address resolution. 
     LE security uses the following keys and values for encryption, signing, and random addressing: 
     1. Identity Resolving Key (IRK) is a 128-bit key used to generate and resolve random addresses. 
     2. Connection Signature Resolving Key (CSRK) is a 128-bit key used to sign data and verify signatures on the receiving device. 
     3. Long Term Key (LTK) is a 128-bit key used to generate the contributory session key for an encrypted connection. Link Layer encryption is described in Bluetooth™ Core Specification, Version 4.1 [Vol 6] Part B, Section 5.1.3. 
     4. Encrypted Diversifier (EDIV) is a 16-bit stored value used to identify the LTK. A new EDIV is generated each time a unique LTK is distributed. 
     5. Random Number (Rand) is a 64-bit stored valued used to identify the LTK. A new Rand is generated each time a unique LTK is distributed. 
     In order for devices using the privacy feature to reconnect to known devices, the device addresses used when the privacy feature is enabled, private address, must be resolvable to the other devices&#39; identity. The private address is generated using the device&#39;s identity key exchanged during the bonding procedure. 
     The Identity Resolving Key (IRK) is used for resolvable private address construction (see [Part C], Generic Access Profile, Section 10.8.2. A master that has received IRK from a slave can resolve that slave&#39;s random resolvable private device addresses. A slave that has received IRK from a master can resolve that master&#39;s random resolvable private device addresses. The privacy concept only protects against devices that are not part of the set to which the IRK has been given. 
     While a device is in the Peripheral or the Central role the device may support the Bonding procedure. While a device is in the Broadcaster or the Observer role the device shall not support the bonding procedure. The Host of the Central initiates the pairing process as defined in Bluetooth™ Core Specification, Version 4.1 [Vol. 3], Part C Section 2.1 with the Bonding_Flags set to Bonding as defined in [Vol. 3], Part H Section 3.5.1. If the peer device is in the bondable mode, the devices shall exchange and store the bonding information in the security database. 
     If a device has privacy enabled (as defined in Bluetooth™ Core Specification, Version 4.1, Table 10.7), the Host should send it&#39;s IRK to the peer device and request the IRK of the peer device during the pairing procedure. The Host can abort the pairing procedure if the authentication requirements are not sufficient to distribute the IRK. If the pairing procedure fails due to authentication requirements and IRK distribution was requested, the pairing procedure should be retried without requesting IRK distribution. 
     C. Touch-to-Select in Bluetooth Technology 
     The Bluetooth Touch-to-select feature employs Received Signal Strength Indication (RSSI) information, which is used in determining that a device is within “touch range”, i.e. proximate or in close proximity of the inquiring device, and when a threshold for that close proximity is met. This may provide an “intent to share” or “touch to connect” feature. 
     1. Bluetooth™ RSSI 
     The received signal strength indicator (RSSI) is a measurement of the power present in a received radio signal. Bluetooth receiver circuits may include an RSSI detector circuit to measure the strength of an incoming signal and generate an output representing the signal strength. For example, the received RF signal may be amplified and downconverted to an intermediate frequency (IF); then channel selection is performed on the IF signal, and the power of the IF signal in the selected channel is measured as the receiver signal strength indicator (RSSI) value. If the Bluetooth receiver circuit supports RSSI, the accuracy may be +/−6 dBm or better. 
     RSSI Monitoring of Bluetooth LE Packets 
     During Bluetooth discovery in Bluetooth LE, before a connection is created, the RSSI may be measured from advertising packets received in broadcasting channel 37, 38, or 39, when they are received by a scanning device, if enabled by the host. 
     When the controller receives an advertising packet, an HCI LE Advertising Report event is sent by the controller to the host application. The HCI LE Advertising Report event indicates that a Bluetooth device or multiple Bluetooth devices have been detected during an active scan or during a passive scan. The HCI LE Advertising Report event includes a parameter N that indicates the RSSI of the received packet, with N being one octet representing the magnitude of the RSSI, with a range in units of dBm of −127≦N≦+20. This event will be sent from the Controller to the Host as soon as an advertising packet from a remote device is received. The RSSI parameter is measured during the receipt of the advertising packet. This event contains RSSI and advertising packet data for the remote device, among other information. 
     RSSI Monitoring of Data Packets Received Over a Connection 
     After the discovery phase is completed, once a Bluetooth LE device is connected to another Bluetooth device, the received signal strength indication (RSSI) may be used by a receiving device to monitor the received power level of the data communication packets received over the connection. The RSSI value is calculated from received packet in the Bluetooth physical layer, and may be read by the host application for example through the host controller interface (HCI) Read RSSI command, for example once per second. 
     The Read RSSI Command will read the value of the received signal strength indication (RSSI) for data communication packets received over the connection to another Bluetooth LE controller. The RSSI value is referenced with respect to a Connection_Handle that identifies the connection and is assigned when the connection is created. The Connection_Handle is used by the Bluetooth controller to determine which set of buffers to use and the logical link over which the data is to be sent. 
     In Bluetooth LE, the meaning of the RSSI metric is an absolute receiver signal strength value in dBm to ±6 dBm accuracy. If the RSSI cannot be read, the RSSI metric is set to 127. 
     Measuring Pathloss with the RSSI and the TX Power Level 
     The TX Power Level data field in the Bluetooth LE advertising packet indicates the transmitted power level of the advertising packets at the transmitter of the sending device. The TX Power Level is reported to the host in response to the HCI LE Read Advertising Channel Tx Power Command. The TX Power Level data field may be used to calculate path loss of a received packet when the receiving device measures the RSSI of the received advertising packet, using the following equation: 
       pathloss= Tx  Power Level−RSSI of the inquiry response packet
 
     For example, if Tx Power Level=+4 (dBm) and the RSSI on the received packet is −60 (dBm) then the total pathloss is +4−(−60)=+64 dB. If a second packet were received at −40 dBm with a Tx Power Level data=+15 dBm the resulting pathloss would be +55 dB. An application may use these pathloss values to choose which device it thinks might be closer (the one with the lower pathloss value). 
     Unfortunately, due to fading and varying antenna, circuit, and chip characteristics, these resulting pathloss values may have some uncertainty. Some of the uncertainty (for example, due to fading) may be able to be alleviated if multiple packets are received from the same device. 
     2. Bluetooth™ Host Controller Interface 
     The Bluetooth™ radio in a device may include the host controller interface that provides a command interface between the host application in the device and the link layer of the Bluetooth™ radio, also referred to as the controller, to enable access to hardware status and control registers of the Bluetooth™ radio. 
     The host controller interface (HCI) is described in the Bluetooth™ Core 4.0 Specification. The Host will receive asynchronous notifications of HCI events from Host Controller Transport Layer. HCI events are used for notifying the Host when something occurs. When the Host discovers that an event has occurred, it will then parse the received event packet to determine which event occurred. The commands and events are sent between the Host and the Controller. These are grouped into logical groups by function. 
     The HCI provides a command interface between the host application in a device and the Bluetooth™ link layer, provides access to hardware status and control registers of the Bluetooth™ radio, and provides a uniform method of accessing the Bluetooth™ baseband capabilities. 
     Discovery Phase HCI Commands and Events 
     HCI LE Advertising Report Event 
     The Bluetooth LE device discovery group of commands and events allow a device to discover other devices in the surrounding area. The Bluetooth LE host controller interface includes the HCI LE Advertising Report event that indicates that a Bluetooth device or multiple Bluetooth devices have been detected during an active scan or during a passive scan. 
     The scanning device may ask further information of advertising device with scan request packet. Once advertiser has received scan request packet it may answer with scan response packet. 
     Connection Phase HCI Commands and Events 
     HCI LE Read Advertising Channel Tx Power Command 
     The TX Power Level is reported to the host in response to the HCI LE Read Advertising Channel Tx Power Command. The TX Power Level data field may be used to calculate path loss of a received packet when the receiving device measures the RSSI of the received advertising packet. 
     After the discovery phase is completed, once a Bluetooth device is connected to another Bluetooth device, the received signal strength indication (RSSI) may be used by a receiving device to monitor the received power level of the data communication packets received over the connection. The RSSI value is calculated by the Bluetooth physical layer, and may be read by the host application through the host controller interface (HCI) Read RSSI command. 
     The Read RSSI command will read the value of the received signal strength indication (RSSI) for data communication packets received over the connection to another Bluetooth controller. The RSSI value is referenced with respect to a Connection_Handle that identifies the connection and is assigned when the connection is created. The Connection_Handle is used by the Bluetooth controller to determine which set of buffers to use and the logical link over which the data is to be sent. 
     The RSSI parameter in the Read RSSI command is a signed 8-bit value, and is interpreted as an indication of arriving signal strength at the antenna measured in dBm. This command reads the Received Signal Strength Indication (RSSI) value from the Controller. For Bluetooth LE transport, a Connection_Handle is used as the Handle command parameter and return parameter. The meaning of the RSSI metric is an absolute receiver signal strength value in dBm to ±6 dBm accuracy. 
     3. Bluetooth LE Proximity Profile 
     The Proximity Profile defines the behavior when a device moves away from a peer device so that the connection is dropped or the path loss increases above a preset level, causing an immediate alert. This alert may be used to notify the user that the devices have become separated. As a consequence of this alert, a device may take further action, for example to lock one of the devices so that it is no longer usable. 
     The Proximity Profile may also be used to define the behavior when the two devices come closer together such that a connection is made or the path loss decreases below a preset level. 
     The Proximity Profile defines two profile roles to enable devices to detect their proximity: the Proximity Reporter and the Proximity Monitor. The Proximity Reporter is a Generic Attribute Profile (GATT) server on the one device in the connection, which supports a Link Loss Service (mandatory), an Immediate Alert Service (optional), and a transmit (Tx) Power Service (optional). The Proximity Monitor is a GATT client on the peer device in the connection, which monitors the Radio Signal Strength Information (RSSI) of the connection to calculate the signal&#39;s path loss. The Proximity Monitor may use the information received from the Proximity Reporter&#39;s Tx Power Service to normalize the RSSI value, by subtracting the RSSI from the Tx Power Level. In order to trigger an alert on low RSSI, the Proximity Monitor constantly monitors RSSI. 
     The Proximity Monitor on one device may maintain a connection with the Proximity Reporter on the peer device and monitor the RSSI of this connection. The Proximity Monitor may calculate the path loss by subtracting the RSSI from the transmit power level of the device of the Proximity Reporter, as discovered using the Reading Tx Power procedure. If the path loss exceeds a threshold set on the Proximity Monitor, it may write in the Alert Level characteristic of the Immediate Alert service, using the GATT Write Without Response sub-procedure, to cause the Proximity Reporter to generate an alert. The Proximity Monitor may also generate an alert when the path loss exceeds the threshold. The duration of the alert may be implementation specific. 
     The Proximity Monitor specified in the Bluetooth Proximity Profile, may include the following functions:
         Service Discovery from the peer device;   Characteristic Discovery from the peer device;   Configuration of Alert on Link Loss to the peer device;   Alert on Link Loss to the peer device;   Reading Tx Power from the peer device; and   Alert on Path Loss locally and to the peer device based on RSSI supervision.       

     If the path loss falls below a threshold set on the Proximity Monitor it may write in the Alert Level characteristic of the Immediate Alert service, using the GATT Write Without Response sub-procedure, to cause the Proximity Reporter to end the alert. When the path loss is below the threshold the Proximity Monitor should stop alerting. 
     If link loss occurs during this procedure, then the behavior defined in the Alert on Link Loss procedure may be used. 
     D. Local Control Through Intermediate Device 
     Users may monitor the operation of devices, machines, and systems by viewing a visual display of monitoring images, such as icons on a computer display screen, representing signals received from physical sensors connected to or interacting with the devices, machines, and systems, such as ambient light sensors, microphones, location sensors, motion tracking sensors, magnetic sensors, and the like. A user interface program in the user&#39;s computer must be provided with the correct parameters to condition and format the received signals so as to be properly displayed on the computer display screen. 
     Users may control the operation of such devices, machines, and systems thus monitored, by means of selecting an icon or item on a menu displayed on the computer display screen, to cause the computer to transmit signals to physical actuators connected to or interacting with the devices, machines, and systems. Such physical actuators may include relays for electrical switches, solenoids, and electric motors. The user interface program in the user&#39;s computer must be provided with the correct parameters to condition and format the transmitted signals so that the physical actuators are properly activated. 
     Wireless communication protocols, such as Bluetooth, Bluetooth Low Energy, WLAN, and the like, have been used for the communication of signals by a user&#39;s computer to monitor and/or control devices, machines, and systems in a residence, such as room lights, home heating systems, surround-sound systems, washing machines, refrigerators, coffee makers, and the like, belonging to Internet of Things. 
     An area of increasingly critical concern is whether a user attempting to control the operation of a device, machine, or system, is authorized to perform such control. For example, authorized medical practitioners may monitor physical sensors that are part of medical devices, by viewing a visual display of monitoring images, such as icons on a computer display screen. Monitoring the operation of patient-implantable devices, such as heart pacemakers, infusion pumps, and neurostimulators, may be performed by medical practitioners, such as nurses, having a sufficient level of authorization. However, adjusting or controlling the operation of such devices must be limited to those medical practitioners, such as physician specialists, having a higher level of authorization. 
     Another area of concern when wirelessly controlling a medical treatment device, is ensuring that the correct, intended medical treatment device is being controlled. In busy settings, such as in a modern hospital, there may be several instances of wireless remote control being simultaneously conducted within radio range. 
     There is a need to improve the level of security in controls for medical devices to prevent unauthorized use and to insure the correct, intended wireless connections are made. Still further, there is a need to make user interfaces for such controls user friendly, providing help, guidance and language options. 
     In accordance with an example embodiment of the invention, the monitoring and control of medical devices by a control device may be remotely performed through a remote server that checks the level of authorization of the user of the control device and which grants access rights for such interaction. 
     In accordance with an example embodiment of the invention, a remote server transmits to a wireless medical device, secure ID information associated with a wireless medical device. In accordance with another embodiment of the invention, the wireless medical device may generate its own secure ID information. The wireless medical device may be, for example, an external pump unit of a patient-implanted infusion pump. The wireless medical device determines that it is in proximity to a control device, such as a wireless mobile device, operated by a medical practitioner. The proximity determination may be based on measurements of signal strength of wireless signals from the control device. In response to determining that it is proximate to the control device, the wireless medical device transmits a wireless message to the control device via a short-range communication connection, such as Bluetooth Low Energy (BTLE). The message includes at least the secure ID information associated with the medical device. 
     In accordance with an example embodiment of the invention, the control device receives the wireless message from the proximate medical device, the message including the secure ID information. The control device may confirm the proximity of the wireless medical device by means of the signal strength of the received wireless message. The control device then compiles a request message including at least the secure ID information associated with the proximate medical device and information identifying said apparatus. The request message may further include credentials and authentication information associated with the user of the control device, to the server. The control device then transmits the compiled request message to the remote server for accessing control to the proximate medical device. 
     In accordance with an example embodiment of the invention, the remote server receives the request message from the control device via the communication connection, the request message including at least the request for accessing control to the proximate medical device, the credentials of the user of the control device, and the secure ID information associated with the proximate medical device. The remote server checks the credentials and authentication information associated with the user of the control device. The remote server then transmits to the control device, information associated with a user interface or control interface for interacting with the wireless device based on remote access control by the control device through the remote server. The user interface or control interface is based on the information included in the received request message. The remote server may include in the transmitted information, authentication and authorization level information, to be presented to the proximate medical device. 
     In accordance with an example embodiment of the invention, the control device compiles the user interface or control interface for enabling the user of the apparatus to interact with the proximate medical device based on the received information. The compiled user interface or control interface includes access rights for interacting with the proximate medical device via remote server access control. The access rights depend on the authentication information associated with the user included in the transmitted request message from the control device. The access rights may be increased for the user interface or control interface for interacting with the proximate medical device, by providing additional authentication information associated with the user of the control device, to the remote server. 
     In accordance with an example embodiment of the invention, the control device then transmits control messages to the remote server, for accessing control to the proximate medical device, for interaction of the control device with the proximate medical device via the remote access control, based on the information associated with a user interface or control interface. 
       FIG. 1  is an illustration of an example embodiment of a network with a mobile wireless control device  100 , a controllable device, for example a wireless medical device  102 , such as a gateway health device, and a remote server  104 , such as a cloud server. The figure shows example steps  1  through  6  in wireless remote control of the wireless medical device  102  by the control device  100  through the intermediate remote server  104 , in accordance with at least one embodiment of the present invention. 
     The wireless medical device  102  may be, for example, a gateway health device that serves as a wireless control interface between a wireless control device  100  remotely operated by a physician, and a wearable health monitoring device and/or wearable medical treatment device worn by a patient. The figure shows the wireless medical device  102  as a gateway health device that serves as a wireless control interface for a sensor  50 A and control actuator  52 A of a neurostimulator  112  that is worn by the patient. The sensor  50 A and actuator  52 A of the neurostimulator  112  may be controlled via a wireless or wired connection  54 A to the gateway health device. The gateway health device may also serve as a wireless control interface for a sensor  50 B and control actuator  52 B of an external pump unit of a patient-implanted infusion pump  110  that is worn by the patient. The sensor  50 B and actuator  52 B of the infusion pump  110  may be controlled via a wireless or wired connection  54 B to the gateway health device. The gateway health device may be located within radio range of the patient, such as in the patient&#39;s home or at the patient&#39;s bedside, and the connections  54 A and  54 B to the wearable medical treatment devices may be Bluetooth™ Low Energy protocol (BTLE) or a WLAN communications protocol  115 , such as the IEEE 802.11 communications protocol. Alternately, the gateway health device may be worn on the patient&#39;s person, and the connections  54 A and  54 B to the wearable medical treatment devices may be either wireless or wired connections. 
     In example embodiments of the invention, the wireless mobile device  100  and the wireless medical device  102  may include a processor  122  that includes from one to many central processing units (CPUs)  124 , a random access memory (RAM), a read only memory (ROM), a Received Signal Strength Indication (RSSI) to distance conversion module  129 , and interface circuits to interface with one or more radio transceivers  116 , antenna  132 ,  170 , and battery or house power sources. The wireless mobile device  100  also includes cell phone circuits  131  and is connectible to the Internet. The wireless medical device  102  may optionally include cell phone circuits  131  and is connectible to the Internet. The wireless mobile device  100  may include a keypad, display  145 , etc. A wireless medical device  102  may include a display device and/or a speaker. The RAM and ROM can be removable memory devices  126  such as smart cards, SIMs, WIMs, semiconductor memories such as RAM, ROM, PROMS, flash memory devices, etc., as shown in  FIG. 10 . In an example embodiment of the invention, the RAM in the mobile wireless device  100  may store information contained in received advertising messages  150 , for example, a description of the capabilities of the sending wireless medical device  102  in received advertising messages  150 . 
     In an example embodiment of the invention, the mobile wireless device  100  and the wireless medical device  102  include a Bluetooth™ Low Energy protocol (BTLE)  114  module. The mobile wireless device  100  may include a WLAN communications protocol  115  module, such as the IEEE 802.11 communications protocol. The wireless medical device  102  may optionally include a WLAN communications protocol  115  module. 
     In example embodiments of the invention, the remote server  104  may include a processor  122  that includes from one to many central processing units (CPUs)  124 , a random access memory (RAM) and a read only memory (ROM)  126 , and interface circuits to interface with one or more radio transceivers  116 , antenna  172 , and battery or house power sources. The server  104  may also include cell phone circuits  131 . The RAM and ROM can be removable memory devices  126  such as smart cards, SIMs, WIMs, semiconductor memories such as RAM, ROM, PROMS, flash memory devices, etc., as shown in  FIG. 10 . In an example embodiment of the invention, the RAM in the server  104  may store information contained in received messages  160 . In an example embodiment of the invention, the server  104  may include a WLAN communications protocol, such as the IEEE 802.11 communications protocol. In an alternate embodiment, server  104  may be located in the Internet, or other network. In this embodiment, the control device  100  may connect the server  104  by accessing the Internet or other network. The server  104  may have a wired interface to communicate with a local area network or a wide-area wired network that may have been accessed by the mobile wireless device via the Internet, or the like. 
       FIG. 2  is an illustration of an example embodiment of the network of  FIG. 1 , wherein in step  1  of  FIG. 1 , the remote server  104  provides to the wireless medical device  102 , secure ID information that is to be associated with the wireless medical device. In one embodiment, the wireless medical device  102  receives the Secure ID from the cloud server based on a request from the device or another device, or it may be based, for example, on a timer. In another embodiment, the wireless medical device  102  may independently generate the secure ID. The Secure ID may be stored in the device  102  and may be used to identify the device  102  in the later phase. The Secure ID may be, for example, a hash generated from the device information or it may be a string or byte vector. 
       FIG. 3A  is an illustration of an example embodiment of the network of  FIG. 2 , wherein the wireless medical device  102  determines that it is in proximity to the control device  100  operated by a medical practitioner. The proximity determination may be based on measurements of signal strength of wireless signals  148  from the control device  100 , in accordance with at least one embodiment of the present invention. 
       FIG. 3B  is an illustration of an example embodiment of the network of  FIG. 3A , wherein, in step  2  of  FIG. 1 , in response to determining that the wireless medical device  102  is proximate to the control device  100 , the wireless medical device  102  transmits a wireless message  150  to the control device  100  via a short-range communication connection, such as Bluetooth Low Energy (BTLE) advertising message. The message  150  includes at least the secure ID information associated with the medical device  102 , in accordance with at least one embodiment of the present invention. 
     In an alternate embodiment, the wireless medical device  102  may create a connection with the control device  100  to determine if the control device  100  is in close proximity, and if it is, the wireless medical device  102  may deliver the secure ID to control device  100 . 
     In an example embodiment of the invention, the mobile wireless device  100  determines proximity to the wireless medical device  102  by receiving a wireless message  150  from the wireless medical device  102 . The mobile wireless device  100  measures the signal strength of the one or more received BTLE wireless messages  150 . The mobile wireless device  100  determines whether it is in close proximity to the wireless medical device  102 , based on the measured signal strength of the one or more received BTLE wireless messages  150 . 
       FIG. 4  is an illustration of an example embodiment of the network of  FIG. 3A , wherein in step  3  of  FIG. 1 , the control device  100  may confirm the proximity of the wireless medical device  102  by means of the signal strength of the received wireless message  150 . The control device  100  then compiles a request message  160  including at least the secure ID information associated with the proximate medical device  102  and information identifying the control device  100 . The request message  160  may further include authentication information associated with the user of the control device  100 , to authenticate it to the server  104 . The request message  160  may further include authentication information associated with an identifier of the control device  100 , to the server  104 . 
     The control device  100  then transmits the compiled request message  160  to the remote server  104  for accessing control to the proximate medical device  102 , in accordance with at least one embodiment of the present invention. The secure ID information associated with the medical device  102  insures that a physician operating the control device  100 , controls the correct, intended medical device  102 . For example, if a physician operating the control device  100  wishes to make an adjustment to the neurostimulator  112 , via the gateway health device of the wireless medical device  102 , the request message  160  will include the secure ID of the intended wireless medical device  102 . 
       FIG. 5  is an illustration of an example embodiment of the network of  FIG. 3A , wherein in step  4  of  FIG. 1 , the remote server  104  checks the authentication information associated with the user of the control device  100 . The remote server  104  then transmits to the control device  100 , information  162  associated with a user interface or control interface  141  for interacting with the wireless medical device  102  based on remote access control by the control device  100  through the remote server  104 . The information  162  includes a set of one or more controls allowing the control device  100  to interact with the proximate wireless medical device  102  through the remote server  104  access control. The user interface or control interface  141  is based on the information included in the received request message  160 . The transmitted information  162  associated with the user interface or control interface, may further include information based on authentication and authorization level information associated with the control device  100 . 
     For example, if the physician operating the control device  100  wishes to make an adjustment to the control actuator  52 A of the neurostimulator  112 , via the gateway health device of the wireless medical device  102 , information  162  will include a set of one or more controls for the control actuator  52 A of the neurostimulator  112 . The set of one or more controls allow the control device  100  to interact with control actuator  52 A of the neurostimulator  112  via the gateway of the proximate wireless medical device  102 , the interaction being through the remote server  104  access control. The secure ID of the intended wireless medical device  102  may also be included in the information  162 . 
     The remote server  104  includes in the transmitted information  162 , authentication and authorization level information, to authenticate the control device  100  to the proximate medical device  102 , in accordance with at least one embodiment of the present invention. 
     The remote server  104  accesses the mapping database  106  to obtain data describing the requested user interface or control interface corresponding to the user function to be performed. The database  106  contains data describing user interfaces or control interfaces  141  and  142  for a variety of controlled device types and mobile device display types. Two different user interfaces or control interfaces are shown in the database  106 . The first user interface or control interface  141  corresponds to a profile for monitoring, adjusting or controlling an infusion pump  110 . The second user interface or control interface  142  has a profile to monitor, adjust or control a neurostimulator  112 . 
       FIG. 6  is an illustration of an example embodiment of the network of  FIG. 3A , wherein in steps  5  and  6  of  FIG. 1 , the control device  100  compiles the user interface or control interface  141  for enabling the user of the control device to interact with the proximate medical device  102  based on the received information. The compiled user interface or control interface  141  includes access rights for interacting with the proximate medical device  102  via remote server access control. The access rights depend on the authentication information associated with the user included in the transmitted request message  160  from the control device  100 . The access rights may be increased for the user interface or control interface  141  for interacting with the proximate medical device  102 , by providing additional authentication information associated with the user of the control device  100 , to authenticate to the remote server. The control device  100  then transmits control messages  164 ′ to the remote server  104 , for transmission of remote control messages  166  to the proximate medical device  102 , for interaction of the control device  100  with the proximate medical device  102  via the remote access control, based on the information associated with the user interface or control interface  141 , in accordance with at least one embodiment of the present invention. 
     In an alternate embodiment, the control messages  164 ′ may be processed by the cloud server  104  and thereafter translated and/or modified into the messages  166  for actually controlling the wireless medical device  102 . In other words, the user interface or control interface  141  may be just for the purpose of interaction between the control device  100  and the cloud server  104 , and different controls and/or commands may be generated by the cloud server  104 , in response, for the interaction  166  between the cloud server  104  and the wireless medical device  102 . 
     In accordance with an example embodiment of the invention, the controlling interaction of the control device  100  with the controllable medical device  102 , may comprise: 
     the remote server  104  receiving one or more controls  164 ′ from the control device  100 , the one or more controls being based on the information associated with the user interface or control interface  141 ; and 
     the remote server  104  transmitting commands  166  to the controllable medical device  102  corresponding to the one or more controls  164 ′. 
       FIG. 7A  is an illustration of an example format for the Bluetooth™ Low Energy protocol (BTLE) advertising messages  150 , in accordance with at least one embodiment of the present invention. The format of Advertising data and Scan Response data consists of a significant part and a non-significant part. The significant part contains a sequence of AD structures. Each AD structure shall have a Length field of one octet, which contains the Length value, and a Data field of Length octets. The first octet of the Data field contains the AD type field. The content of the remaining Length−1 octet in the Data field depends on the value of the AD type field and is called the AD data. The non-significant part extends the Advertising and Scan Response data to 31 octets and shall contain all-zero octets. 
       FIG. 7B  is an illustration of an example simplified format for a WLAN message  160  sent by the control device  100  to the remote server  104 , its request for the user interface or control interface, in accordance with at least one embodiment of the present invention. The example WLAN message  160  is an IEEE 802.11 data frame carrying an example data payload. In example embodiments of the invention, the request message  160  may be a message for example over a WLAN or cellular connection, or messages over the Internet, such as HTTP request over Transport Layer Security (TLS) connection. 
       FIG. 7C  is an illustration of an example simplified format for a WLAN message  162  sent by the remote server  104  to the control device  100 , with the user interface or control interface  141 , in accordance with at least one embodiment of the present invention. The example WLAN message  1620  is an IEEE 802.11 data frame carrying an example data payload of the user interface or control interface characterizing wireless medical device  102  formatted for display on device  100 . 
     In example embodiments of the invention, the reply message  162  may be a message for example over a WLAN or cellular connection, or messages over the Internet, such as HTTP request over Transport Layer Security (TLS) connection. 
       FIG. 7D  is an illustration of an example simplified format for a WLAN message  164 ′ sent by the control device  100  to the remote server  104 , for control of the wireless medical device  102 , in accordance with at least one embodiment of the present invention. 
       FIG. 7E  is an illustration of an example simplified format for a WLAN message  166  sent by the remote server  104  to the medical device  102 , that has been transmitted from the control device  100 , in accordance with at least one embodiment of the present invention. 
       FIG. 8A  is an illustration of an example flow diagram of an example process  800  in the remote server  104 , carrying out the example operations for providing the user interface or control interface  141  to the control device  100 , in accordance with at least one embodiment of the present invention. The process comprises: 
     Step  802 : Allocate ID and send it to the Gateway health device. The remote server  104  transmits to the wireless medical device  102 , the secure ID information associated with the wireless medical device  102 . The Secure ID may be based on a request from the wireless medical device  102  or another device, or it may be based, for example, on a timer. In another embodiment, the wireless medical device  102  may independently generate the secure ID. The Secure ID may be, for example, a hash generated from the device information or it may be a string or byte vector. The Secure ID may be stored in the device  102  and may be used to identify the device  102  in the later phase. 
     Step  804 : ID from device received. The remote server  104  receives the request message  160  including at least the secure ID information associated with the medical device  102 , credentials of the user of the control device, and information identifying the control device  100 . The request message  160  requests accessing control to the medical device  102 . The remote server  104  checks the credentials of the user. The remote server  104  accesses the mapping database  106  to obtain data describing the user interface or control interface corresponding to the secure ID of the medical device  102  and any specified user function to be performed. The database  106  contains data describing user interfaces or control interfaces  141  and  142  for a variety of controlled device types and control device types. The secure ID information associated with the medical device  102 , insures that the user interface or control interface accessed from the database  106  is for the correct, intended medical device  102 . 
     Step  806 : Provide user interface for control device. The remote server  104  transmits to the control device  100 , information  162  associated with a user interface or control interface  141  for interacting with the wireless medical device  102 , based on remote access control by the control device  100  through the remote server  104 . The user interface or control interface  141  is based on the information included in the received request message  160 . The remote server  104  includes in the transmitted information  162 , authentication and authorization level information, to authenticate the control device  100  to the proximate medical device  102 . 
       FIG. 8B  is an illustration of an example flow diagram of an example process  820  in the remote server  104 , carrying out the example operations for control interactions from the control device  100  to the medical device  104 , in accordance with at least one embodiment of the present invention. The process comprises: 
     Step  822 : Get information of control device and gateway health device. The remote server  104  receives control messages  164 ′ including the user interface or control interface  141  from the control device  100 , which identifies the medical device  102  to be controlled. 
     Step  824 : User Interface action received. The received user interface or control interface  141  specifies the control actions that may be performed on the medical device  102 . The received user interface or control interface  141  includes access rights for interacting with the medical device  102  via remote server access control. The access rights depend on the authentication information associated with the user included in the transmitted request message  160  from the control device  100 . 
     Step  826 : Check permission for user interface action. The remote server  104  checks the authentication information associated with the user of the control device  100  and the access rights for interacting with the medical device  102  via remote server access control. 
     Step  828 : Permission OK. If the authentication information of the user and the access rights check out, then permission is granted for accessing control of the medical device  102 . 
     Step  830 : Authentication needed. If the authentication information of the user or the access rights do not check out, then the remote server  104  may request additional credentials or authentication information from the user. 
     Step  832 : Authentication OK. If the additional authentication information of the user or the access rights are acceptable, then the remote server  104  grants permission for accessing control of the medical device  102 . 
     Step  834 : Perform action. The remote server  104  processes the control messages  164 ′. In one embodiment of the invention, the remote server transmits control messages  166  to the proximate medical device  102 , for interaction of the control device  100  with the proximate medical device  102  via the remote access control, based on the information associated with the user interface or control interface  141 . In an alternate embodiment, the control messages  164 ′ may be processed by the cloud server  104  and thereafter translated and/or modified into the messages  166  for actually controlling the wireless medical device  102 . The user interface or control interface  141  may be for the purpose of interaction between the control device  100  and the cloud server  104 , and different controls and/or commands may be generated by the cloud server  104 , in response, for the interaction  166  between the cloud server  104  and the wireless medical device  102 . 
       FIG. 9A  is an illustration of an example flow diagram of an example process  900  in the control device  100 , carrying out the example operations, in accordance with at least one embodiment of the present invention. The steps of the flow diagram represent computer code instructions stored in the RAM and/or ROM memory of the device, which when executed by the central processing units (CPU)  124 , carry out the functions of the example embodiments of the invention. The steps may be carried out in another order than shown and individual steps may be combined or separated into component steps. The flow diagram has the following steps: 
     Step  902 : receiving, by an apparatus, a message from a proximate device via a short-range communication connection, the message including at least ID information associated with the proximate device; 
     Step  904 : compiling, by the apparatus, a request message including at least the ID information associated with the proximate device and information identifying said apparatus; 
     Step  906 : transmitting, by the apparatus, the compiled request message to a remote server for accessing control to the proximate device; 
     Step  908 : receiving, by the apparatus, information associated with a user interface or control interface for interacting with the proximate device via the remote server, the received information including a set of one or more controls allowing the apparatus to interact with the proximate device through the remote server access control and being based on the information included in the transmitted request message; 
     Step  910 : compiling, by the apparatus, a user interface or control interface for enabling a user of said apparatus to interact with the proximate device based on the received information, the compiled user interface or control interface including access rights for interacting with the proximate device via the server access control depending on the information included in the transmitted request message; and 
     Step  912 : interacting, by the apparatus, with the proximate device via the remote server access control using the compiled user interface or control interface. 
       FIG. 9B  is an illustration of an example flow diagram of an example process  950  in the remote server  104 , carrying out the example operations, in accordance with at least one embodiment of the present invention. The steps of the flow diagram represent computer code instructions stored in the RAM and/or ROM memory of the device, which when executed by the central processing units (CPU)  124 , carry out the functions of the example embodiments of the invention. The steps may be carried out in another order than shown and individual steps may be combined or separated into component steps. The flow diagram has the following steps: 
     Step  952 : transmitting, by an apparatus, to a controllable device, ID information that is to be associated with the controllable device; 
     Step  954 : receiving, by the apparatus, a request message from a wireless device via a communication connection, the request message including at least a request for accessing control to the controllable device and the ID information associated with the controllable device; 
     Step  956 : transmitting, by the apparatus, to the wireless device, information associated with a user interface or control interface for interacting with the controllable device based on remote access control through the apparatus, the transmitted information including a set of one or more controls allowing the wireless device to interact with the controllable device through the apparatus access control and based on the information included in the received request message; and 
     Step  958 : controlling, by the apparatus, interaction of the wireless device with the controllable device, based on the information associated with the user interface or control interface. 
       FIG. 10  illustrates an example embodiment of the invention, wherein examples of removable storage media  126  are shown, based on magnetic, electronic and/or optical technologies, such as magnetic disks, optical disks, semiconductor memory circuit devices and micro-SD memory cards (SD refers to the Secure Digital standard) for storing data and/or computer program code as an example computer program product, in accordance with at least one embodiment of the present invention. 
     E. Local Device Control for Bluetooth™ Low Energy (BTLE) 
     Users may monitor the operation of devices, machines, and systems by viewing a visual display of monitoring images, such as icons on a computer display screen, representing signals received from physical sensors connected to or interacting with the devices, machines, and systems. Such physical sensors may include ambient light sensors, microphones, location sensors, motion tracking sensors, magnetic sensors, and the like. A user interface program in the user&#39;s computer must be provided with the correct parameters to condition and format the received signals so as to be properly displayed on the computer display screen. 
     Users may control the operation of such devices, machines, and systems thus monitored, by means of selecting an icon or item on a menu displayed on the computer display screen, to cause the computer to transmit signals to physical actuators connected to or interacting with the devices, machines, and systems. Such physical actuators may include relays for electrical switches, solenoids, and electric motors. The user interface program in the user&#39;s computer must be provided with the correct parameters to condition and format the transmitted signals so that the physical actuators are properly activated. 
     Wireless communication protocols, such as Bluetooth, Bluetooth Low Energy, WLAN, and the like, have been used for the communication of signals by a user&#39;s computer to monitor and/or control devices, machines, and systems in a residence, such as room lights, home heating systems, surround-sound systems, washing machines, refrigerators, coffee makers, and the like, belonging to Internet of Things. Such wireless communication protocols have been used for the communication of signals by a user&#39;s computer to monitor and/or control devices, machines, and systems in commercial or industrial applications, for heavier machinery such as elevators, AC drives, air conditioners, pumps, valves, escalators, security controls such as movement detectors, heat pumps, engines, street lamps, switches, fuse boards, fire alarms, and the like. 
     There is a need for improved controls for devices, machines, and systems in residential, commercial, and industrial applications, which are reconfigurable to adapt to design changes and which have an increased useful life. Moreover, there is a need to provide a level of security in controls for devices, machines, and systems to prevent unauthorized use. Still further, there is a need to make user interfaces user friendly, providing help, guidance and language options. 
     In accordance with an example embodiment of the invention, a cloud server provides a user interface to a user&#39;s mobile wireless device, based on a detected proximity between the mobile wireless device and a controllable device to be monitored and/or controlled. The user interface may be a display panel including icons and menus, and also including parameters to condition and format the transmitted and received signals. 
     In one example embodiment of the invention, the mobile wireless device detects Bluetooth™ Low Energy protocol (BTLE) advertising messages from the wireless controllable device and is able to transmit to the cloud server, a public or random device address of the detected device or other identification. The cloud server responds with a user interface, based on the detected proximity, enabling monitoring and/or control of the controllable device. 
     In another example embodiment of the invention, the mobile wireless device transmits its current location to the cloud server. The cloud server responds with one or more user interfaces, based on the current location, for one or more controllable devices in the area of the mobile device&#39;s current location, enabling monitoring and/or control of one or more controllable devices. 
     In an example embodiment of the invention, the mobile wireless device may indicate its access level and what control components need be shown to the user. For example, the owner of the controllable device may have more control than a visitor. An elevator maintenance person may need a maintenance view, whereas an ordinary user of the elevator needs only the floor selection buttons. The cloud server composes a user interface corresponding to the access level and control components needed by the user, and provides it to the mobile wireless device, to enable access to the controllable device. 
     In an example embodiment of the invention, the mobile wireless device may be required to submit access authorization credentials to the cloud server. In response, the cloud server composes a user interface including the required access credentials and provides them to the mobile wireless device, to enable access to the controllable device. 
     In an example embodiment of the invention, the cloud server may access a mapping database to obtain the user interface information for the controllable devices. There may be the same or a different database that the cloud server accesses for connectivity information to enable communication between the mobile wireless device and a controllable device. For example, the cloud server may determine that a specific controllable device needs to be accessed over a specific communications protocol Bluetooth, or WLAN, or NFC, or through the Internet. The access method may also be dependent on the user&#39;s access level or time of day or other factor. The cloud server composes a user interface corresponding to the required communications protocol, access method, user&#39;s access level, time of day, or other factor, and provides them to the mobile wireless device, to enable access to the controllable device. 
     In an example embodiment of the invention, the connectivity information may include communications protocol information and/or metadata to enable the mobile wireless device communicate with the controllable device. The metadata may include, for example, service and/or characteristics UUIDs of the Bluetooth LE protocol or other information related to services in the controllable device. 
     In an example embodiment of the invention, the user interface display layout and functionality may be dynamically changed by the cloud server, based on a measured proximity between the devices. At a greater distance, there may be a different user interface provided by the cloud server, than when the devices are in close proximity. As an example, when the user is in an elevator lobby area, only the call buttons for the elevator need to be displayed, whereas when entering the elevator, the user interface may change automatically to show the current floor and the elevator alarm button. 
     In an example embodiment of the invention, the user interface may allow control of a plurality of controllable devices at the same time. This enables use cases where for example, the user interface combines information from several different controllable devices when the user is further away from the devices. If user moves closer to any of the controllable devices, the user interface may be changed by the cloud server, to focus on that particular device. 
     In an example embodiment of the invention, the user interface may be preloaded into a cache of the mobile wireless device from the cloud server, to enable offline use of the user interfaces. Individual ones of the user interfaces in the cache may be invoked when a corresponding controllable device is detected to be in proximity. Offline use may be enabled on a per user, per area, per controllable device, or per time basis. When this is enabled, the mobile device may refresh all offline user interfaces when it is connected to a network, such as the internet. 
     In an example embodiment of the invention, security of the user interface control is enhanced by setting the Bluetooth radios of the controllable devices into a non-discoverable mode, so that the radios only listen for specific advertisements until receiving an advertising message from a mobile wireless device, containing a specific encryption code provided by the cloud server. 
     1. The group of  FIGS. 11A to 11G  illustrates an example of a server providing a user interface (UI) based on a detected proximity between a mobile wireless device and a controllable device. 
       FIG. 11A  is an illustration of an example embodiment of a network with a mobile wireless device  100  and a controllable device  102 , which is shown in the figure as the pump XYZ. Other examples of controllable devices  102  may include, in a residence, room lights, home heating systems, surround-sound systems, washing machines, refrigerators, coffee makers, and the like, belonging to Internet of Things. Other examples of controllable devices  102  may include, in commercial or industrial applications, heavy machinery such as elevators, AC drives, air conditioners, pumps, valves, escalators, security controls such as movement detectors, heat pumps, engines, street lamps, switches, fuse boards, fire alarms, and the like. 
     Other examples of controllable devices  102  may include healthcare and medical equipment in a hospital or similar setting. As an example, a nurse may be provided with diverse user interface display screens corresponding to general treatment or to more specifically prescribed medications. The display screens for a nurse may typically be different from the display screens for an attending physician, with the physician&#39;s screen corresponding to current medication and vital signs, or describing the effectiveness of a prescribed medication and presenting alternate medications. The user interface display screens may be displayed when the nurse or physician approaches the patient&#39;s medical monitoring equipment or the patient&#39;s bed. A further example is where a nurse enters a room occupied by several patients. The nurse may be presented with a combined user interface identifying several of the patients that need medication. The user interface may be invoked by the nurse&#39;s mobile wireless device being proximate to an entrance tag located at the entrance to the room, to display information about several or all of the patients in the room. The same entrance tag may be used by visiting family members to see that their loved ones are staying in the room. In a “closed” environment of a hospital, a “remote server” and the entire infrastructure, including servers, may be within the closed hospital environment, so there may be no communication outside the hospital&#39;s closed intranet network. Accordingly, data may be preloaded from the hospital&#39;s servers, into the nurse&#39;s and physician&#39;s mobile wireless devices when they arrive on duty, since the nurses and physicians typically have certain responsibility areas that are very specific, such as a specific ward where their patients and the medical equipment are located. 
     The mobile wireless device  100  is shown scanning for Bluetooth™ Low Energy protocol (BTLE) advertising messages. The controllable device  102  is shown transmitting BTLE advertising messages  150  containing at least identification of the controllable device. 
     Advertising messages  150  may be the connectable undirected advertising (ADV_IND) channel packet. The ADV_IND PDU has a payload field containing AdvA and AdvData fields. The AdvA field contains the controllable device&#39;s  102  public or random device address and the AdvData field may contain Advertising data shown in  FIG. 7A . When the controllable device  102  in the advertising state, enters the BTLE connection state, it will be in the BTLE slave role and the mobile wireless device  100  initiating the connection state will be in the BTLE master role in a BTLE data channel, in accordance with at least one embodiment of the present invention. 
     In example embodiments of the invention, the controllable device&#39;s identifier may be a periodically changing random device address, as provided by the Bluetooth™ Low Energy protocol (BTLE) communication protocol, to protect privacy and prevent replay attacks. 
     In example embodiments of the invention, instead of an address of a controllable device  102 , another form of identifier for the controllable device  102  may be used, such as Uniform Resource Name, Uniform Resource Identifier, serial number, or the like. 
     The user device may access a cloud server  104  (shown in  FIG. 11B ) with the current location of the mobile wireless device  100 , which is proximate to the controllable device  102 . The cloud server  104  may then query a mapping database  106  in  FIG. 11C , and access the device address or identity of the proximate controllable device  102 . 
     The current location of the mobile wireless device  100  may be determined by: 
     The mobile wireless device  100  provides location (relative/absolute) information to server; 
     The mobile wireless device  100  determines location from (local) positioning system; 
     The mobile wireless device  100  receives positioning data from the controllable device during a touch-to-select event; or 
     The cloud server  104  determines the location of the mobile wireless device from external position sensing sources. 
     In an alternate example embodiment of the invention, the mobile wireless device  100  may receive the device identifier of the controllable device  102  from the remote server  104 . For example, the remote server  104  may know the general location of the mobile wireless device  100  and use this information to access the device identifier of the controllable device  102 . The mobile wireless device  100  may use the received device identifier to find the device  102  locally. In the alternate example embodiment, the mobile wireless device  100  may also receive a user interface  141  and connectivity data from the remote server  104 , as shown in  FIG. 11C . The mobile wireless device  100  may find the device  102  locally and start communicating with the device  102  based on the received information. 
     In example embodiments of the invention, the wireless mobile device  100  and the controllable device  102  may include a processor  122  that includes from one to many central processing units (CPUs)  124 , a random access memory (RAM), a read only memory (ROM), a Received Signal Strength Indication (RSSI) to distance conversion module  129 , and interface circuits to interface with one or more radio transceivers  116 , antenna  132 ,  170 , and battery or house power sources. The wireless mobile device  100  also includes cell phone circuits  131  and is connectible to the Internet. The controllable device  102  may optionally include cell phone circuits  131  and is connectible to the Internet. The wireless mobile device  100  may include a keypad, display  145 , etc. A wireless controllable device may include a display device and/or a speaker. The RAM and ROM can be removable memory devices  126  such as smart cards, SIMs, WIMs, semiconductor memories such as RAM, ROM, PROMS, flash memory devices, etc., as shown in  FIG. 10 . In an example embodiment of the invention, the RAM in the mobile wireless device  100  may store information contained in received advertising messages  150 , for example, a description of the capabilities of the sending controllable device  102  in received advertising messages  150 . 
     In an example embodiment of the invention, the mobile wireless device  100  and the wireless controllable device  102  include a Bluetooth™ Low Energy protocol (BTLE)  114  module. The mobile wireless device  100  may include a WLAN communications protocol  115  module, such as the IEEE 802.11 communications protocol. The controllable device  102  may optionally include a WLAN communications protocol  115  module. The controllable device  102  may optionally include an access authorization module  113 . 
     In an example embodiment of the invention, the mobile wireless device  100  determines proximity to the wireless controllable device  102  by receiving at least an address of the controllable device  102 . The mobile wireless device  100  measures the RSSI signal strength of the one or more received BTLE wireless messages  150 . The mobile wireless device  100  determines whether it is in close proximity to the controllable device  102 , based on the measured RSSI signal strength of the one or more received BTLE wireless messages  150 . 
     In an example embodiment of the invention, the mobile wireless device  100  may be, for example, a miniature device such as a key fob, smart card, jewelry, or the like. In an example embodiment of the invention, the mobile wireless device  100  may be, for example, a relatively larger cell phone, smart phone, flip-phone, PDA, graphic pad. The mobile wireless device  100  may also be in an automobile or other vehicle. In embodiments, the relative sizes of devices  100  and  102  may be arbitrary. 
       FIG. 11B  is an illustration of an example embodiment of the network of  FIG. 11A , wherein the user function to be performed is mechanical service/repair. When the mobile wireless device  100  detects proximity to the pump XYZ, the mobile wireless device transmits to the cloud server, a message  160  requesting a user interface corresponding to a user function to be performed with the mobile wireless device  100 , the request message containing information including at least a user identifier, an indication of characteristics of the mobile wireless device  100  and an indication relating to an address of the controllable device, the pump XYZ  102 . 
     In example embodiments of the invention, the request message  160  may be a WLAN message (shown in  FIG. 7B ), a cell phone message or messages over the Internet, such as HTTP request over Transport Layer Security (TLS) connection. The request message  160  may contain information including some or all of the following: its ID, a user identifier, user function: mechanical service/repair, display type: screen&#39;s parameters, location: lat/lon; factory floor; pump room, controllable device id: pump XYZ, and its request for the user interface: mechanical service panel. The user identifier may be for example, account information (for example a Google account, Apple ID, MS live account, Nokia account, etc.). To maintain security, the mobile wireless device  100  may be required to submit access authorization credentials to the cloud server  104 , showing authorization to securely access the controllable device  102 . 
     In example embodiments of the invention, the cloud server  104  receives the request message  160 . The cloud server  104  may compose information based on the information received by the server  104  in the request message  160 . The information composed by the server  104  may include connectivity information. In an example embodiment of the invention, the connectivity information may include communications protocol information and/or metadata to enable the mobile wireless device  100  communicate with the controllable device  102 . The metadata may include, for example, service and/or characteristics UUIDs of the Bluetooth LE protocol or other information related to services in the controllable device  102 . 
     In example embodiments of the invention, mobile wireless device  100  may compile the user interface  141  including the received parameters enabling at least one of controlling and monitoring of the controllable device  102 . The information for compiling a user interface may be composed of HTML, HTML5, CSS, JavaScript, ECMAScript, Java, or code written in some other language. 
     In other example embodiments of the invention, the server may compose the user interface  141  based on the information received by the server in the request message  160 , the user interface  141  including parameters characterizing the requesting wireless device  100 . 
     In example embodiments of the invention, the mobile wireless device  100  may compose a user interface corresponding to the user function to be performed. The cloud server  104  accesses the mapping database  106  to obtain data describing the requested user interface corresponding to the user function to be performed. The database  106  contains data describing user interfaces  141  and  142  for a variety of controlled device types and mobile device display types. 
     In an example use case, Mechanic Mike is providing service to the pump system. Mike enters the control room and Mike&#39;s mobile wireless device (phone or tablet) is able to detect IDs coming from the pump and valve. The mobile wireless device may know, based on the received ID, which devices are proximate, or the ID may be a random number not providing any insight to the actual device. Mike&#39;s mobile wireless device may also know Mike&#39;s identity and some characteristics of the mobile wireless device, itself, (such as operating system, screen size and resolution). With this information and possible location information, the mobile wireless device may contact the cloud server to provide this collected information to the server. In response, the cloud server may use this information to compose an appropriate user interface, based on the information provided by the mobile wireless device. The user interface may be composed to correspond to the user, the user&#39;s device, the location, or the detected controllable device&#39;s ID. The cloud server will return an appropriate user interface to the user&#39;s device, possibly together with some connectivity information as to how to access the controllable device. 
     Two different user interfaces are shown in the database  106 . The first user interface  141  is provided to mechanic Mike, corresponding to a profile for performing mechanical service/repair. The second user interface  142  is for electrician Einstein, who has a profile to perform electrical service/repair. Mike&#39;s and Einstein&#39;s mobile wireless devices have the same software, only the user interface and possibly the connectivity control messages are different. Einstein can use Mike&#39;s device to perform electrical service work. 
     In example embodiments of the invention, the cloud server  104  may include a processor  122  that includes from one to many central processing units (CPUs)  124 , a random access memory (RAM) and a read only memory (ROM)  126 , and interface circuits to interface with one or more radio transceivers  116 , antenna  172 , and battery or house power sources. The server  104  may also include cell phone circuits  131 . The RAM and ROM can be removable memory devices  126  such as smart cards, SIMs, WIMs, semiconductor memories such as RAM, ROM, PROMS, flash memory devices, etc., as shown in  FIG. 10 . In an example embodiment of the invention, the RAM in the server  104  may store information contained in received messages  160 . In an example embodiment of the invention, the server  104  may include a WLAN communications protocol, such as the IEEE 802.11 communications protocol. 
     In example embodiments of the invention, the cloud server  104  may not necessarily have any radio or any cell phone circuits, as the cloud server may not necessarily have any understanding of cellular networks. The cloud server may simply be in a datacenter connected through wired internet access. Thus, any kind of communication technologies may be used for the cloud server. In example embodiments of the invention, the “cloud server” may be quite local to the mobile device, and hence it may directly have radio access. 
       FIG. 11C  is an illustration of an example embodiment of the network of  FIG. 11B , wherein the cloud server  104  uses the information received in request message  160  from the mobile wireless device  100 , to access from a mapping database  106 , data describing a mechanical service panel user interface  141  that is appropriate for the specified type of controlled device  102 . The cloud server  104  accesses data describing the mechanical service panel  141  corresponding to the user function of mechanical service/repair. The cloud server  104  optionally accesses connectivity information from a connectivity database  108 , to obtain communications protocol information and metadata to enable the mobile wireless device  100  communicate with the controllable device  102 . The cloud server  104  may provide the compiled user interface  141  to the mobile wireless device  100 , to enable a user of the mobile wireless device  100  to perform the user function of at least one of monitoring and controlling the wireless controllable device. 
     In example embodiments of the invention, the cloud server composes the user interface for the mechanical service panel  141 , based on the accessed data, including display parameters for the mobile wireless device  100 , such as a required aspect ratio, resolution, and color palette, and a required communications protocol for the mobile wireless device  100  to communicate with the controllable device  102 . The cloud server  104  formats the accessed user interface  141  for display on the specified type of display  145  of the mobile wireless device  100 . The cloud server  104  may send to the mobile wireless device  100 , a message for example over a WLAN or cellular connection,  162  (shown in  FIG. 7C ) containing the formatted user interface: mechanical service panel  141 . The cloud server sends the user interface and the connectivity data in a message for example over a WLAN or cellular connection via the Internet to the mobile wireless device. 
       FIG. 11D  is an illustration of an example embodiment of the network of  FIG. 11C , wherein the user of the mobile wireless device  100  has used the mechanical service panel user interface  141  displayed, to monitor and/or control the controllable device  102 , by sending a mechanical control message  164  to the controllable device  102 . The message  164  is transmitted by the mobile wireless device  100  to the controllable device  102  using the communications format specified in message  162  by the cloud server  104 , such as BTLE. Example functions displayed on the mechanical service panel user interface  141  may include a display of pump pressure, pump hours, and valve travel. The mechanical service panel user interface  141  may control the pump on and off switch. 
     In example embodiments of the invention, the mobile wireless device  100  may optionally report back to the server  104 , the actions that the user has performed with the controlled device  102 , so that the server  104  may log the actions for further use or analysis. 
       FIG. 11E  is an illustration of an example embodiment of the network of  FIG. 11A , wherein the user function to be performed is electrical service/repair. When the mobile wireless device  100  detects proximity to the pump XYZ, the mobile wireless device sends to the cloud server, a message for example over a WLAN or cellular connection,  160  (shown in  FIG. 7B ). The mobile wireless device  100  is shown sending to the cloud server  104 , a message for example over a WLAN or cellular connection,  160  containing information including some or all of its ID, a user identifier, user function: electrical service/repair, display type: screen&#39;s parameters, location: lat/lon; factory floor; pump room, controllable device ID: pump XYZ, and its request for the user interface: electrical service panel. 
       FIG. 11F  is an illustration of an example embodiment of the network of  FIG. 11E , wherein the cloud server  104  uses the information received from the mobile wireless device  100 , to access from a mapping database  106 , data describing an electrical service panel user interface  142  that characterizes the specified type of controlled device  102 . The cloud server formats the electrical service panel user interface  142  for display on the specified type of display  145  of the mobile wireless device  100 . The cloud server may access the connectivity database  108  to obtain connectivity information, for communication with the controllable device. Connectivity information is used for connection with the controllable device  102 , but it may not necessarily be needed with an existing Internet connection. 
       FIG. 11G  is an illustration of an example embodiment of the network of  FIG. 11F , wherein the user of the mobile wireless device  100  used the electrical service panel user interface  142  displayed on the display  145 , to monitor and/or control the controllable device  102 . Example functions displayed in the electrical service panel user interface  142  may include a display of control voltage and drive voltage. Control functions may include pump on/off, valve on/off, and restart control circuit. The control functions may be performed by sending a BTLE electrical control message  164  to the controllable device  102 . 
     Security of the example embodiment shown in the group of  FIGS. 11A to 11G , may be enhanced by first performing the example embodiment shown in the group of  FIGS. 12 to 12D , to make the user interface control concept more secure. 
     2. The group of  FIGS. 12 to 12D  illustrates an example security enhancement to the example embodiment shown in the group of  FIGS. 11A to 11G  to make the user interface control concept more secure. 
     To improve security, the controllable wireless device may want to stay completely hidden until awakened by an authorized entity. This makes attacking more difficult since the attacker may be unaware of the target being reachable. This saves radio bandwidth by not sending unnecessary advertisements, and makes device selection easier for devices not interested in the hiding device, since they will have fewer choices. 
     In accordance with an example embodiment of the invention, the mobile wireless device with a user account, connects to the cloud server. The cloud server determines the location of the mobile wireless device, for example based on geolocation coordinates received for the mobile wireless device, and what possible controllable devices may be in the vicinity of the mobile wireless device, which it is allowed to access. 
     In accordance with an example embodiment of the invention, based on the available information, the cloud server prepares, for each accessible controllable device, a message object encrypted with the controllable device&#39;s first public key. The message object may contain, for example, a sequence number and access rights for the control device. The cloud server then passes the encrypted object to the mobile wireless device, accompanied by a second public key of the controllable device. The controllable device&#39;s first public key corresponds to a first private key (or secret key) of a first public key/private key pair of the controllable device&#39;s. The controllable device&#39;s second public key corresponds to a second private key (or secret key) of a second public key/private key pair of the controllable device&#39;s. 
     In accordance with an example embodiment of the invention, the mobile wireless device then prepares a message containing the encrypted message object and the mobile wireless device&#39;s identifier, and then encrypts that message with the received second public key. The mobile wireless device then sends the resulting encrypted message, using a Bluetooth LE advertisement packet. The advertisement packet may, at this point, include the public key of the mobile wireless device, or other secret token. The advertisement packet may include one or more encrypted messages targeted to one or more controllable devices. 
     In accordance with an example embodiment of the invention, the controllable device receives the advertisement packet and decrypts the message with its second private key, in order to obtain the encrypted object and the mobile wireless device&#39;s identifier (and possibly other secrets). The controllable device then decrypts the encrypted object with its first secret key. 
     In accordance with an example embodiment of the invention, the controllable device then determines if the mobile wireless device is allowed to access the controllable device (for example, by assessing validity of the included sequence number). If it is allowed, then the controllable device starts sending BTLE advertisements that enable the mobile wireless device to actually make a connection to the controllable device. The determination whether the controllable device starts the advertising, may also include additional steps, such as measuring a Received Signal Strength (RSSI) of the signals received from the mobile wireless device. The controllable device may start advertising its presence only if the RSSI is above some threshold level. If it is not above the threshold, the controllable device sends nothing and stays hidden, for example, by not advertising its presence with BTLE advertisements. In accordance with an example embodiment of the invention, it is also possible that the controllable device is creating a connection to the mobile device, which is allowed to access the controllable device. Hence, the controllable device does not need to start an advertisement, but may directly create a connection with the mobile device. 
       FIG. 12  is an illustration of an example embodiment of a message flow for a cloud-controlled Bluetooth LE device wakeup of a controllable device. The controlled device  102  initially stays hidden, not advertising its presence, in accordance with at least one embodiment of the present invention. 
     For message  200  of the message flow, the mobile wireless device  100  transmits a message for example over a WLAN or cellular connection, over a secure channel, to the cloud server  104 , to inform the cloud server of the current location of the mobile wireless device  100 . Message  200  is also shown in  FIG. 12B . To maintain security, the mobile wireless device  100  may be required to submit access authorization credentials to the cloud server  104 , showing authorization to securely obtain information about any available controllable devices  102  that may be near to the current location of the mobile wireless device  100 . 
     For message  201 A of the message flow, the cloud server  104  issues a query to the mapping database  106 , for the identity of any available controllable devices  102  that may be near to the current location of the mobile wireless device  100 . Message  201 A is also shown in  FIG. 12B . 
     For message  201 B of the message flow, the mapping database  106  replies to the cloud server  104 , with information about at least one available controllable device  102  that is near to the current location of the mobile wireless device  100 . The information provided by the mapping database  106  to the cloud server  104  may include information about the controllable device  102 , a first public key of the controllable device  102 , a second public key of the controllable device  102 , a sequence number, and a user access profile for the mobile wireless device  100 . Message  201 B is also shown in  FIG. 12B . 
     The cloud server computes an encrypted object by using the first public key of the controllable device  102  to encrypt the sequence number and the user access profile for the mobile wireless device  100 . 
     For message  202  of the message flow, the cloud server  104  transmits a message for example over a WLAN or cellular connection, over a secure channel, to the mobile wireless device  100  the encrypted object and the second public key of the controllable device  102 . Message  202  is also shown in  FIG. 12B . 
     The mobile wireless device  100  uses the second public key of the controllable device  102  to encrypt the encrypted object. 
     For message  204  of the message flow, the mobile wireless device  100  transmits one or more Bluetooth LE advertisement messages  204  containing the encrypted object that has been further encrypted with the second public key of the controllable device  102 . Message  204  is also shown in  FIG. 12C . 
     The Bluetooth LE advertisement message  204  is received by the controllable device  102 . The Bluetooth radio of the controllable device  102  is in a non-discoverable mode  180 , so that the radio only listens for specific advertisements until receiving an advertising message  204  containing the specific encryption code. 
     The controllable device  102  processes the received advertisement message  204  as shown in  FIG. 12A . 
     In step  208 , receives the advertisement message  204 . 
     In step  210 , controllable device  102  decrypts the advertisement message  204  using the second private key of the controllable device  102 , recovering the first public key. If this fails, step  211  silently drops the advertisement  204 . 
     In step  212 , controllable device  102  decrypts the encrypted object using the first private key of the controllable device  102 , recovering the sequence number and the user access profile for the mobile wireless device  100 . If this fails, step  213  silently drops the advertisement  204 . 
     In step  214 , controllable device  102  assesses the validity of the sequence number. If this fails, step  215  silently drops the advertisement  204 . 
     In step  216 , controllable device  102  starts sending the Bluetooth LE advertisements  150  containing a description of the controllable device capabilities, as shown in  FIG. 11A . 
       FIG. 12B  is an illustration of an example embodiment of the network of  FIG. 11B , wherein the mobile wireless device  100  is shown sending to the cloud server  104 , a message for example over a WLAN or cellular connection,  200  over a secure channel, containing an update of the current location of the mobile wireless device  100  (for example, its latitude and longitude, and environment, such as a factory floor and pump room) and its request for available controllable devices in its area. 
     The  FIG. 12B  shows the cloud server  104 , in response, accessing the database  106  to retrieve information about a controllable device  102  in the area of the mobile wireless device  100 , the information including a first public key and a second public key of the controllable device  102 , a sequence number, and a user access profile of the mobile wireless device  100 . The figure shows the cloud server  104  transmitting to the mobile wireless device  100 , a reply message  202  including at least the second public key and an encrypted object that is the first public key encrypting at least the sequence number and user access profile, in accordance with at least one embodiment of the present invention. 
     In an example embodiment, the message  200  may be an optional step, wherein the server  104  may be aware of the location of the mobile wireless device  100  via some other means (such as via tracking services or positioning systems). In this example embodiment, the server may push the “reply message” without explicitly being solicited by the mobile wireless device. 
       FIG. 12C  is an illustration of an example embodiment of the network of  FIG. 11A , wherein the mobile wireless device  100  transmits to the controllable device  102 , one or more Bluetooth™ Low Energy protocol (BTLE) advertisement messages  204  containing the encrypted object and the user ID that have been further encrypted with the second public key of the controllable device  102 , wherein the encrypted object is at least the sequence number and user access profile, encrypted with the first public key of the controllable device  102 , in accordance with at least one embodiment of the present invention. 
       FIG. 12D  is an illustration of an example embodiment of the network of  FIG. 12C , wherein the controllable device  102  decrypts the advertisement message  204  and the encrypted object, to assess the validity of the sequence number and the user access profile. If the controllable device  102  determines that the sequence number and the user access profile are valid, then the controllable device  102  reveals its presence by transmitting a BTLE advertisement  150 , such as in  FIG. 11A  and  FIG. 7A , containing information identifying the controllable device, in accordance with at least one embodiment of the present invention. 
     There are further embodiments possible, at least:
         The controllable device may send Bluetooth LE advertisements, when it has accepted wakeup, as directed Bluetooth LE advertisement meant only for the device from whom triggering advertisement was received.   The controllable device may send Bluetooth LE advertisements encrypted with 2nd secret key, and hence decodable only by those in possession of 2nd public key.   The mobile wireless device may include its public key inside the Bluetooth LE advertisement it sends. This would allow controllable device to encrypt Bluetooth LE advertisement it sends in a way that only correct mobile wireless device is able to decrypt it.   In one embodiment the communication between mobile wireless device and controllable device are either based on directed advertisements, or some other form of unicast messaging. For example, the cloud server may in one embodiment tell the device address of the controllable device, and that allows mobile wireless device to directly establish Bluetooth LE connection to the controllable device. In unicast cases the cloud would provide information to mobile wireless device that allows it to form unicast messages that the controllable device can validate and selectively respond only if validation is successful.       

     Although the presence of the controllable device in the example is explained to be advertised over BTLE, it can be any other technology. Also, the presence may be indicated over BTLE but the actual connectivity is done over some other technology. Non-limiting examples includes:
         The controllable device starts a mobile hotspot or Wi-Fi Direct.   The mobile wireless device may for example receive access credential from remote server or via BTLE advertisement.   The controllable device connects to AP.   It may advertise its IP address over BTLE or using for example Bonjour over WLAN network.   The controllable device creates cellular connection and advertise its connectivity information over BTLE.       

     The location update from mobile wireless device to cloud may be periodic, may be triggered by explicit user action such as pressing of “scan for devices” button, or it may be triggered, for example, by positioning beacon message (for example, in a space there can be iBeacon, or any positioning beacon message, which triggers sending of the positioning update to the cloud). It is also possible that mobile wireless device does not send explicit location update to cloud, but cloud obtains position of mobile wireless device by some other means (for example, from an indoor positioning system). A position of the device may be obtained by any means. 
     The database may reside on the same server to where mobile wireless device sends its location update, but it is possible that database is distributed, for example, that different databases are used based on user account or based on device types or based on locations. Database technology may be relational database like SQL, noSQL, text files, key-value stores, object database, or alike. Databases may also have reference to further databases. 
     Log and/or charging data records may be stored on the same database or to different database. 
     While the above description is in terms of asymmetric public-key encryption using public and secret (or private) keys, other encryption means are also possible. In particular, symmetric key cryptography is also a possibility (where the same key is used for decryption and encryption). 
     Furthermore, the cloud server may pass new keys to the controllable device, embedded into the Encrypted Object (or in parallel with the Encrypted Object as a separate part of the message). In many systems, encryption keys may expire and need to be periodically refreshed. 
     During the first time setup, the mobile wireless device may provide keys to the controllable device and update respective keys to the cloud server. This first time setup may be initiated with a certain button press or with certain a RSSI requirement between the mobile wireless device and the controllable device, in a situation where there are no keys existing in the controllable device. 
     Advantages: 
     1. Device is hidden until made visible with properly formatted Bluetooth LE advertisement 
     2. Device can be woken up only with cloud provided Encrypted Object 
     3. Attacker seeing successful wakeup message cannot replay it, because Encrypted Object contains changing sequence number (which may be very short lived) 
     4. Mobile wireless device cannot repeatedly use the controllable device without obtaining fresh Encrypted Object from the cloud 
     5. Cloud is fully in control who talks to controllable device and how many connections are created (this is beneficial e.g. for charging purposes) 
     6. Secure wakeup without requiring changes to existing smartphones and tablets (i.e. the mobile wireless device can be implemented on currently available devices) 
     7. Proprietary software for the controllable device and cloud for handling the Encrypted Object formation and encryption 
     8. Solution can be implemented in application on top of existing mobile wireless devices (Android, iOS, Windows Phone) systems without changes. This allows fast deployment. 
     3, The group of  FIGS. 13 to 13G  illustrates an example extension of the example embodiment shown in the group of  FIGS. 11A to 11G , wherein a common user interface is constructed from multiple controllable devices that are in proximity to the mobile wireless device. The figures further illustrate an example embodiment where the user interface that is changed based on the proximity of the mobile wireless device to a particular controllable device. 
       FIG. 13  is an illustration of an example embodiment of the network of  FIG. 11A , wherein two controllable devices are located in a pump room: a valve and a pump. The valve  102 A is a controllable device located near an entrance of the pump room and the pump  102 B is a controllable device located farther from the entrance, in the interior of the pump room. The mobile wireless device is shown located outside of the pump room at a distance X 1  from the nearer valve and at a distance X 2  from the farther pump. In a manner similar to that described for  FIG. 11A , the mobile wireless device  100  is shown scanning for Bluetooth™ Low Energy protocol (BTLE) advertising messages. The controllable device valve  102 A is shown transmitting BTLE advertising messages  150 A containing a description of the controllable device valve capabilities. The controllable device pump  102 B is shown transmitting BTLE advertising messages  150 B containing a description of the controllable device pump capabilities, in accordance with at least one embodiment of the present invention. 
       FIG. 13A  is an illustration of an example embodiment of the network of  FIG. 13 , wherein a schematic diagram  140  of the pump room will be displayed on the mobile wireless device  100 , as a user interface when the mobile device  100  is farther than a proximate distance from either the valve or the pump. A mechanical service panel  141  will be displayed as a user interface for the valve  102 A when the mobile device  100  is near to a distance X 1  from the valve  102 A. An electrical service panel  142  will be displayed as a user interface for the pump  102 B when the mobile device  100  is near to a distance X 2  from the pump  102 B, in accordance with at least one embodiment of the present invention. 
     There may be a group of more than two controllable devices  102 , and the mobile wireless device  100  detects at least one of those devices  102  in the group, but none of the devices  102  is in close proximity to the mobile wireless device  100 . In response, the mobile wireless device may transmit to the cloud server  104 , information that one or more of the wireless controllable devices in the group is detected, but not in close proximity to the wireless mobile device. The cloud server  104  may include a stored relationship between the more than two controllable devices in the group, such that when any of those devices  102  in the group is detected, a representation is composed of all of the two or more controllable devices in the group. The stored relationship of the group of controllable devices enables the cloud server  104  to transmit a collective user interface  140  to the mobile wireless device  100 , representing the entire group of devices  102 . 
       FIG. 13B  is an illustration of an example embodiment of the network of  FIG. 11B , wherein the mobile device  100  is farther than a proximate distance from either the valve  102 A or the pump  102 B. The mobile wireless device detects the presence of the BTLE device advertising message  105 A, but the detected distance is greater than X 0 . The mobile wireless device is shown sending to the cloud server  104 , a message for example over a WLAN or cellular connection,  160  containing information including some or all of its ID, a user identifier, user function: all service/repair, display type: screen&#39;s parameters, location: lat/lon; factory floor; pump room, controllable device valve  102 A, and its request for an appropriate user interface. To maintain security, the mobile wireless device  100  may be required to submit access authorization credentials to the cloud server  104 , showing authorization to securely access the controllable device  102 A, in accordance with at least one embodiment of the present invention. 
       FIG. 13C  is an illustration of an example embodiment of the network of  FIG. 13B , wherein the cloud server  104  uses the information received from the mobile wireless device, to access from the mapping database  106 , data describing an appropriate user interface corresponding to the specified type of controlled device. Since the mobile wireless device  100  has detected the presence of the valve  102 A, but the detected distance is greater than X 0 , the cloud server  104  composes an alternate user interface by accessing a schematic diagram  140  of the pump room where the valve  102 A is located, which is to serve as the user interface. The cloud server  104  formats the user interface for display on the specified type of display  145  of the mobile wireless device  100 , in accordance with at least one embodiment of the present invention. 
       FIG. 13D  is an illustration of an example embodiment of the network of  FIG. 13C , wherein the mobile wireless device  100  has moved closer to the valve  102 A. The mobile wireless device is shown sending to the cloud server  104 , a message for example over a WLAN or cellular connection,  160  containing information including some or all of its ID, a user identifier, user function: all service/repair, display type: screen&#39;s parameters, location: lat/lon; factory floor; pump room, controllable device ID: valve  102 A, and its request for the user interface appropriate for the valve  102 A, in accordance with at least one embodiment of the present invention. To maintain security, the mobile wireless device  100  may be required to submit access authorization credentials to the cloud server  104 , showing authorization to securely access the controllable device  102 A, in accordance with at least one embodiment of the present invention. 
     The mobile wireless device  100  receives one or more BTLE wireless messages from the wireless controllable device  102 A. The mobile wireless device  100  measures the RSSI signal strength of the one or more received BTLE wireless messages  150 A. The mobile wireless device  100  determines whether it is in close proximity to the physical mechanical service panel of the pump XYZ  102 , based on the measured RSSI signal strength of the one or more received BTLE wireless messages  150 A. The mobile wireless device  100  transmits the request message  160  to the server, in response to the determining that it is in close proximity to the valve  102 A. 
       FIG. 13E  is an illustration of an example embodiment of the network of  FIG. 13D , wherein the cloud server  104  uses the information received from the mobile wireless device  100 , to access from the mapping database  106 , data describing a user interface, a mechanical service panel  141 , which characterizes the specified type of controlled device, the valve  102 A. The cloud server  104  formats the user interface for display on the specified type of display of the mobile wireless device  100 . The cloud server  104  may access the connectivity database  108  to obtain connectivity information, to obtain communications protocol information and metadata to enable the mobile wireless device  100  communicate with the controllable device  102 A. The cloud server composes the user interface for the mechanical service panel  141 , based on the accessed data, including display parameters for the mobile wireless device  100 , such as a required aspect ratio, resolution, and color palette, and a required communications protocol for the mobile wireless device  100  to communicate with the controllable device  102 A. The cloud server  104  may send to the mobile wireless device  100 , a message for example over a WLAN or cellular connection,  162  (shown in  FIG. 7C ) containing the formatted user interface: mechanical service panel  141 , in accordance with at least one embodiment of the present invention. 
       FIG. 13F  is an illustration of an example embodiment of the network of  FIG. 13E , wherein the mobile wireless device has moved closer to the pump  102 B. The mobile wireless device is shown sending to the cloud server  104 , a message for example over a WLAN or cellular connection,  160  containing information including some or all of its ID, a user identifier, user function: all service/repair, display type: screen&#39;s parameters, location: lat/lon; factory floor; pump room, controllable device id: pump  102 B, and its request for the user interface appropriate for the pump  102 B, in accordance with at least one embodiment of the present invention. 
     The mobile wireless device  100  receives one or more BTLE wireless messages from the wireless controllable device  102 B. The mobile wireless device  100  measures the RSSI signal strength of the one or more received BTLE wireless messages. The mobile wireless device  100  determines whether it is in close proximity to the physical electrical service panel of the pump XYZ  102 B, based on the measured RSSI signal strength of the one or more received BTLE wireless messages  150 B. The mobile wireless device  100  transmits the request message  160  to the server  104 , in response to the determining that it is in close proximity to the physical electrical service panel of the pump XYZ  102 B. 
       FIG. 13G  is an illustration of an example embodiment of the network of  FIG. 13F , wherein the cloud server  104  uses the information received from the mobile wireless device  100 , to access from a mapping database  106 , data describing a user interface, an electrical service panel  142 , which characterizes the specified type of controlled device, the pump  102 B. The cloud server  104  formats the user interface for display on the specified type of display  145  of the mobile wireless device  100 . The cloud server  104  may access the connectivity database  108  to obtain connectivity information, to obtain communications protocol information and metadata to enable the mobile wireless device  100  communicate with the controllable device  102 B, in accordance with at least one embodiment of the present invention. The cloud server composes the user interface for the electrical service panel  142 , based on the accessed data, including display parameters for the mobile wireless device  100 , such as a required aspect ratio, resolution, and color palette, and a required communications protocol for the mobile wireless device  100  to communicate with the controllable device  102 B. The cloud server  104  may send to the mobile wireless device  100 , a message for example over a WLAN or cellular connection,  162  (shown in  FIG. 7C ) containing the formatted user interface: electrical service panel  142 . 
     Security of the example embodiment shown in the group of  FIGS. 13 to 13G , may be enhanced by first performing the example embodiment shown in the group of  FIGS. 12 to 12D , to make the user interface control concept more secure. 
     4. The group of  FIGS. 14A to 14D  illustrates an example extension of the example embodiment shown in the group of  FIGS. 11A to 11G , wherein the user interface is preloaded into a cache of the mobile wireless device from the server, to enable offline use of the user interfaces, which are invoked only when a corresponding controllable device is detected to be in proximity. The offline use may be enabled on a per user, per area, per controllable device, or per time, basis. 
       FIG. 14A  is an illustration of an example embodiment of the network of  FIG. 11B , wherein the mobile wireless device  100  is shown sending to the cloud server  102 , a message for example over a WLAN or cellular connection, request message  161  requesting preloading of user interfaces characterizing controllable devices in the current area of mobile wireless device  100 , formatted for display on mobile wireless device  100 . To maintain security, the mobile wireless device  100  may be required to submit access authorization credentials to the cloud server  104 , showing authorization to securely access the controllable devices  102  in its area. 
     The cloud server  104  uses the information received from the mobile wireless device  100 , to access from the mapping database  106 , data describing appropriate user interfaces corresponding to controlled devices in the current area of the mobile wireless device  100 . The cloud server  104  may access the connectivity database  108  to obtain connectivity information, to obtain communications protocol information and metadata to enable the mobile wireless device  100  communicate with the controllable device  102 , in accordance with at least one embodiment of the present invention. The cloud server  104  composes the user interfaces  141  and  142 , based on the accessed data, including display parameters for the mobile wireless device  100 , such as a required aspect ratio, resolution, and color palette, and a required communications protocol for the mobile wireless device  100  to communicate with the controllable device  102 . 
     The figure shows the cloud server  104  responding with a reply message  162  including the requested user interfaces  141  and  142  characterizing a controllable device, the pump XYZ, in the area of the mobile wireless device  100 , formatted for display on the mobile wireless device. The requested user interfaces  141  and  142  for the pump XYZ are preloaded into a cache  155  in the mobile wireless device  100 , in accordance with at least one embodiment of the present invention. 
     Optionally, the cloud server  104  may include in the reply message  162  a first signal strength value of the one or more received wireless messages  150  ( FIG. 14B ) corresponding to a first close proximity X 1  to the detected device  102 , when the first user interface  141  may be invoked by the mobile wireless device ( FIG. 14C ). The first signal strength value may be preloaded into a cache  155  in the mobile wireless device  100 . The mobile wireless device  100  may then invoke the first user interface  141  when it detects it is located at the first close proximity X 1  based on measuring a signal strength greater than the first signal strength value. 
     Optionally, the reply message  162  may include a second signal strength value of the one or more received wireless messages  150  corresponding to a second close proximity X 2  to the detected device  102 , when the second user interface  142  may be invoked by the mobile wireless device  100  ( FIG. 14D ). The second signal strength value may be preloaded into the cache  155  in the mobile wireless device  100 . The mobile wireless device  100  may then and invoke the second user interface  142  when it detects it is located at the second close proximity X 2  based on measuring a signal strength greater than the second signal strength value. 
       FIG. 14B  is an illustration of an example embodiment of the network of  FIG. 13 , wherein the mechanical service panel  141  is displayed as a user interface for the pump XYZ when the mobile device is near to a distance X 1  from the pump. An electrical service panel  142  is displayed as a user interface for the pump XYZ when the mobile device is near to a distance X 2  from the pump, in accordance with at least one embodiment of the present invention. 
       FIG. 14C  is an illustration of an example embodiment of the network of  FIG. 14B , wherein the mobile wireless device  100  has moved closer at a distance X 1  to the pump. The mobile wireless device is shown accessing the mechanical service panel  141  from its cache  155  for display as a user interface for the pump, when the mobile device is near to a distance X 1  from the pump, in accordance with at least one embodiment of the present invention. 
       FIG. 14D  is an illustration of an example embodiment of the network of  FIG. 14B , wherein the mobile wireless device  100  has moved closer at a distance X 2  to the pump. The mobile wireless device is shown accessing the electrical service panel  142  from its cache  155  for display as a user interface for the pump, when the mobile device is near to a distance X 2  from the pump, in accordance with at least one embodiment of the present invention. The preloaded user interfaces in cache  155  of the mobile wireless device, enables offline use of the user interfaces. Individual ones of the user interfaces in the cache may be invoked when a corresponding controllable device is detected to be in proximity. Offline use may be enabled on a per user, per area, per controllable device, or per time basis. When this is enabled, the mobile device may refresh all offline user interfaces when it is connected to a network, such as the internet. 
     In an example embodiment of the invention, the mechanic Mike&#39;s mobile wireless device sends a request message  161  to the server, requesting the necessary user interfaces that are then preloaded or stored in Mike&#39;s mobile wireless device. The request message  161  need only contain Mike&#39;s user identifier. The server may validate the request message and then respond with the corresponding user interfaces that may then be preloaded into the cache in Mike&#39;s mobile wireless device. In addition, the request message may optionally include an indication of characteristics of Mike&#39;s mobile wireless device. 
     Other examples of controllable devices  102  may include healthcare and medical equipment in a hospital or similar setting, as previously discussed. When a nurse or physician arrives on duty and logs in to the hospital&#39;s network, their mobile wireless device sends information to the server that can provide the necessary user interfaces that are then preloaded or stored in the to the mobile wireless device. The login request message  161  need only contain a user identifier of the nurse or physician. The server may validate the login request message  161  and then respond with the corresponding user interfaces that may then be preloaded into the cache in the mobile wireless device. In addition, the login request message may optionally include an indication of characteristics of the mobile wireless device, to provide a distinction between a phone or a tablet, for example. The data provided by the server may be preloaded into the nurse&#39;s and physician&#39;s mobile wireless devices when they arrive on duty, since the nurses and physicians typically have certain responsibility areas, such as a specific ward where their patients and the medical equipment are located. 
     Security of the example embodiment shown in the group of  FIGS. 14A to 14D , may be enhanced by first performing the example embodiment shown in the group of  FIGS. 12 to 12D , to make the user interface control concept more secure. 
     5 The group of  FIGS. 15A to 15D  illustrates an example extension of the example embodiment shown in the group of  FIGS. 11A to 11G . 
       FIG. 15A  is an illustration of an example embodiment of the network of  FIG. 11A , wherein, the mobile wireless device  100  detects whether it is in close proximity to the detected device  102  based on measuring a signal strength greater than a signal strength value (RSSI) of the one or more received wireless messages  150 . The mobile wireless device  100  is shown scanning for Bluetooth™ Low Energy protocol (BTLE) advertising messages. The controllable device  102  is shown transmitting BTLE advertising messages  150  containing at least identification of the controllable device. 
       FIG. 15B  is an illustration of an example embodiment of the network of  FIG. 11B , wherein, the mobile wireless device  100  transmits a request message  160  to the remote server  104 , requesting one or more user interfaces corresponding to one or more user functions to be performed, in response to the detecting that the mobile wireless device  100  is in close proximity to the detected device  102 . 
     The figure shows the mobile wireless device  100  receiving from the remote server  104 , a message  162  including a first user interface  141  corresponding to a first close proximity X 1  to the detected device  102  based on measuring a first signal strength value (RSSI[1]) of the one or more received wireless messages  150 . The message  162  may also include a second user interface  142  corresponding to a second close proximity X 2  to the detected device  102  based on measuring a second signal strength value (RSSI[2]) of the one or more received wireless messages  150 . The message  162  may also include the first signal strength value RSSI[1] and the second signal strength value RSSI[2]. 
     The figure shows the mobile wireless device preloading into its cache  155 , the first and second user interfaces  141  and  142  and the first and second signal strength values RSSI[1] and RSSI[2] received from the remote server. 
       FIG. 15C  is an illustration of an example embodiment of the network of  FIG. 14C , wherein, the mobile wireless device  100  may then invoke the first user interface  141  when it detects it is located at the first close proximity X 1  based on measuring a signal strength greater than the first signal strength value RSSI[1]. 
       FIG. 15D  is an illustration of an example embodiment of the network of  FIG. 14D , wherein, the mobile wireless device  100  may then and invoke the second user interface  142  when it detects it is located at the second close proximity X 2  based on measuring a signal strength greater than the second signal strength value RSSI[2]. 
     In another example extension of the example embodiment shown in the group of  FIGS. 11A to 11G , the mobile wireless device  100  may detect one or more devices  102 A or  102 B in a group of devices in  FIG. 13 , but no device in the group is in close proximity to the mobile wireless device  100 , based on a measured signal strength of the one or more received wireless messages  150 A or  150 B. 
     The mobile wireless device  100  may transmit to the remote server  104 , information that one or more devices is detected in the group of devices, but no device in the group is in close proximity to the mobile wireless device  100 . 
     The mobile wireless device  100  may receive from the remote server  104 , a first user interface, such as the mechanical service panel  141 , corresponding to a first close proximity to a first device in the group, such as the distance X 1  to valve  102 A in  FIG. 13A . The first close proximity is based on measuring a first signal strength value, for example RSSI[1], of the one or more received wireless messages  150 A of  FIG. 13 . The mobile wireless device  100  may also receive from the remote server  104 , the first signal strength value RSSI[1]. 
     The mobile wireless device  100  may receive from the remote server  104 , a second user interface, such as the electrical service panel  142 , corresponding to a second close proximity to a second device in the group, such as the distance X 2  to pump  102 B in  FIG. 13A . The second close proximity is based on measuring a second signal strength value, for example RSSI[2], of the one or more received wireless messages  150 B of  FIG. 13 . The mobile wireless device  100  may also receive from the remote server  104 , the second signal strength value RSSI[2]. 
     The mobile wireless device  100  may preload into a cache in the mobile wireless device  100  shown in  FIG. 15B , the first and second user interfaces  141  and  142  and the first and second signal strength values RSSI[1] and RSSI[2] received from the remote server  104 . 
     The mobile wireless device  100  may invoke the first user interface  141  when the mobile wireless device  100  detects it is located at the first close proximity to the first device in the group, the distance X 1  to valve  102 A in  FIG. 13A , based on measuring a signal strength greater than the first signal strength value RSSI[1] of the one or more received wireless messages  150 A. 
     The mobile wireless device  100  may invoke the second user interface  142  when the mobile wireless device  100  detects it is located at the second close proximity to the second device in the group, the distance X 2  to pump  102 B in  FIG. 13A , based on measuring a signal strength greater than the second signal strength value RSSI[2] of the one or more received wireless messages  150 B. 
       FIG. 7A  is an illustration of an example format for the Bluetooth™ Low Energy protocol (BTLE) advertising messages  150 , in accordance with at least one embodiment of the present invention. The format of Advertising data and Scan Response data consists of a significant part and a non-significant part. The significant part contains a sequence of AD structures. Each AD structure shall have a Length field of one octet, which contains the Length value, and a Data field of Length octets. The first octet of the Data field contains the AD type field. The content of the remaining Length−1 octet in the Data field depends on the value of the AD type field and is called the AD data. The non-significant part extends the Advertising and Scan Response data to 31 octets and shall contain all-zero octets. 
       FIG. 7B  is an illustration of an example simplified format for a WLAN message  160  sent by the mobile wireless device  100  to the cloud server  104 , requesting the user interface: mechanical service panel. The example WLAN message  160  is an IEEE 802.11 data frame carrying an example data payload of some or all of: 
     Mobile device address/ID, a user identifier, 
     USER FUNCTION: mechanical service/repair 
     DISPLAY TYPE: screen&#39;s parameters 
     Location: lat/lon; factory floor; pump room 
     Controllable device id: pump XYZ 
     User interface: MECHANICAL SERVICE panel 
     In example embodiments of the invention, the request message  160  may be a message for example over a WLAN or cellular connection, or messages over the Internet, such as HTTP request over Transport Layer Security (TLS) connection. 
       FIG. 7C  is an illustration of an example simplified format for a WLAN message  162  sent by the cloud server  104  to the mobile wireless device  100 , with the user interface: mechanical service panel. The example WLAN message  1620  is an IEEE 802.11 data frame carrying an example data payload of the user interface characterizing controllable device  102  formatted for display on device  100 . 
     In example embodiments of the invention, the reply message  162  may be a message for example over a WLAN or cellular connection, or messages over the Internet, such as HTTP request over Transport Layer Security (TLS) connection. 
       FIG. 16D  is an illustration of an example flow diagram of an example process in the cloud server  104 , carrying out the example operations, in accordance with at least one embodiment of the present invention. 
     Step  602  detects the device ID of the mobile wireless device  100 , the user ID, the user device ID, and the location of the controllable device  102 . 
     Step  604  selects the user interface by accessing the mapping database  106 . 
     Step  606  access the connectivity information from the connectivity database  108 . 
     Step  608  provides the selected user interface to the requesting mobile wireless device  100 . 
     Server gets detected device ID, user ID, user device ID, location information (or some of those). Server gets U/I from mapping database, which is providing predefined U/I for certain combination of user, device etc. IDs. Next server gets related connectivity information, i.e. how to use connectivity and remote device based on UI. 
       FIG. 17A  is an illustration of an example flow diagram  700  of an example process in the mobile wireless device  100 , carrying out the example operations, in accordance with at least one embodiment of the present invention. The steps of the flow diagram represent computer code instructions stored in the RAM and/or ROM memory of the device, which when executed by the central processing units (CPU)  124 , carry out the functions of the example embodiments of the invention. The steps may be carried out in another order than shown and individual steps may be combined or separated into component steps. The flow diagram has the following steps: 
     Step  702 : receiving, by an apparatus, an identifier associated with a device; 
     Step  704 : transmitting, by the apparatus, a message to a remote server, requesting a user interface corresponding to a user function to be performed with the apparatus, the request message containing information including at least one of a user identifier, an indication of characteristics of the apparatus and an indication relating to the received identifier of the device; 
     Step  706 : receiving, by the apparatus, from the server, information composed by the server based on the information transmitted to the server in the request message, the information received from the server including at least information suitable for compiling a user interface including parameters enabling at least one of controlling and monitoring of the device; and 
     Step  708 : providing, by the apparatus, a user interface compiled based on the received information, to enable a user of the apparatus to perform the user function of at least one of monitoring and controlling the device. 
       FIG. 17B  is an illustration of an example flow diagram  750  of an example process in the cloud server  104 , carrying out the example operations, in accordance with at least one embodiment of the present invention. The steps of the flow diagram represent computer code instructions stored in the RAM and/or ROM memory of the device, which when executed by the central processing units (CPU)  124 , carry out the functions of the example embodiments of the invention. The steps may be carried out in another order than shown and individual steps may be combined or separated into component steps. The flow diagram has the following steps: 
     Step  752 : receiving, by a server, a message from a requesting wireless device, requesting a user interface corresponding to a user function to be performed by the requesting wireless device, the request message containing information including at least one of a user identifier, an indication of characteristics of the requesting wireless device and an indication relating to an address of another device that is to be monitored or controlled by the requesting wireless device using the requested user interface; 
     Step  754 : accessing, by the server, a database to obtain data relating to the requested user interface; 
     Step  756 : composing, by the server, information based on the information received by the server in the request message, the information composed by the server including at least information suitable for compiling a user interface including parameters enabling at least one of controlling and monitoring of the other device; and 
     Step  758 : transmitting, by the server to the requesting wireless device, the information composed by the server. 
     Example embodiments of the invention are easy to use and the customized user interface may be provided for different users of a mobile wireless device. The controlled device&#39;s durability is increased via simpler hardware (no need for fancy displays, no need for so many buttons etc.). Access is allowed for hard to reach devices, such as things inside walls or high, or low, or otherwise difficult places. Security is increased by not making it possible to control device just by getting physical access to device. The user interface may be changed long after device has been deployed (e.g. after more experience on key functions and ways of use of a device, a vendor can make an easier-to-user version, or add missing ways to use a device). The user interface may be adapted and modified all the time to meet the new requirements or to enable more efficient usage for the existing users. 
     Using the description provided herein, the embodiments may be implemented as a machine, process, or article of manufacture by using standard programming and/or engineering techniques to produce programming software, firmware, hardware or any combination thereof. 
     Any resulting program(s), having computer-readable program code, may be embodied on one or more computer-usable non-transitory media such as resident memory devices, smart cards or other removable memory devices, thereby making a computer program product or article of manufacture according to the embodiments. 
     As indicated above, memory/storage devices include, but are not limited to, disks, optical disks, removable memory devices such as smart cards, SIMs, WIMs, semiconductor memories such as RAM, ROM, PROMS, etc. Transmitting mediums include, but are not limited to, transmissions via wireless communication networks, the Internet, intranets, telephone/modem-based network communication, hard-wired/cabled communication network, satellite communication, and other stationary or mobile network systems/communication links. 
     Although specific example embodiments have been disclosed, a person skilled in the art will understand that changes can be made to the specific example embodiments without departing from the spirit and scope of the invention.