In the field of wireless communications, for some applications, it is known to provide a so-called Firmware Over-The-Air (FOTA) system. FOTA systems are used for keeping communications-enabled devices in an updating system updated to their most recent firmware version. The over-the-air update approach enables a device with communication capabilities to be updated using a wireless connection with a server, for example a dedicated firmware updating server. Therefore, the devices can remain in-situ without a need to retrieve or recall them for updates or physical connection to another computing device. However, a number of constraints accompany the over-the-air approach. For example, the device needs to be reachable from a communications perspective, an adequate data transfer rate needs to be available, and the power supply to the device needs to adequate, such as in the case of battery-powered beacons.
Consequently, updates sent to the device are typically processed in order to account for limited bandwidth in respect of the connection between the updating server and the device, and the fact that wireless reception by the device consumes a relatively large amount of power compared to normal tasks performed by the device. In this regard, for example, the update can be processed by packaging it using a suitable packaging algorithm for the data type involved. This, however, then leads to a requirement that the device receiving the processed update has to be able to reverse the processing of the data in order to use it.
Furthermore, an update common to all devices using the updating system may not be available. Instead, updates for devices can be required on an individual basis, or groups of more than one device can require respectively different updates to be applied to them. Additionally, in some scenarios, the devices can be accessible for updating purposes by more than one server and so the firmware configuration of a given device is not under the exclusive control of a single updating server. Also, for some devices, it is possible to update the firmware locally, for example by tethering the device to another computing device to apply the update.
Therefore, whilst an updating server, hereinafter referred to as a “content server”, can be programmed to record and thus track the update status and version of the firmware for a given device, such an approach assumes that the content server is the only server to have access to the device for updating purposes and so there is an assumption that the information held by the content server is always up-to-date. Similarly, whilst the content server can maintain a record of processes supported by each device or group of devices for the purposes of communication of updates from the content server to the device(s), since the content server is not necessarily the only entity to have access to the processes stored by a given device, and it is possible that the device or group of devices are controlled by another server or other servers, or they can be accessed locally for updating purposes. This can lead to changes being made to the device(s) outside the scope of detection of the content server and so the record of processes supported by the content server becomes inaccurate.
In order to overcome such difficulties, a known device updating procedure can require the content server to interrogate the device to be updated in order to identify a processing technique, available to the updating server and supported by the device to be updated, which can be used by the content server to communicate, in processed form, the update for the device. However, the known updating procedure assumes that a common processing technique can be found. Additionally, the interrogation of the device requires the device to send data back to the content server in response to a query concerning processing techniques supported by the device, the device thereby consuming power.