This specification relates to data transfer arrangements; for example, data transfer arrangements including Internet of Things (IoT) sensors or some other device. The specification also relates to security arrangements for such data transfers.

Background

Bluetooth® Low Energy (BLE) is an example of a system for transferring information and data between one location (e.g. a data sensor, such as an IoT device or a control system) and another location (e.g. another IoT device, a mobile phone or a system). The present specification seeks to provide improvements and implementations in systems such as (but not exclusively) BLE systems. Summary

In a first aspect, this specification describes a method comprising: providing a first message advertising the presence of a first device; receiving, at the first device, a first response to the first message, the first response having an address, the address including a first portion including first data and a second portion included an encoded version of the first data; and determining whether the first portion of the first response includes information for the first device.

The method may further comprise extracting the first data in the event that the data portion of the address is determined to include information for the first device.

The first and second portions of the address may be concatenated.

The encoded version of the first data may be encoded using a resolving key. Further, the encoded version of the first data may be generated from the first data and the resolving key using a hash function. The resolving key may be known to both the first device and a device generating the first response.

The first data may encode an instruction for the first device. For example, the instruction may instruct the first device to contact a server.

The first data may encode location information. The first data included in the first portion of the address may be encrypted.

The first message may include information identifying the first device. The first message may be an advertisement of a Bluetooth® low energy module.

In a second aspect, this specification describes a method comprising: generating an encoded version of a first data, wherein the first data is to be send to a first device;

formulating an address having a first portion including the first data and a second portion included the encoded version of the first data; detecting a first message advertising the presence of the first device; and sending a first response to the first message, the first response including said address.

The method may further comprise identifying a source of the first message.

The first and second portions of the address may be concatenated.

The method may further comprise generating the encoded version of the first data using a resolving key. The encoded version of the first data and the resolving key may be generated using a hash function.

The first data may encode an instruction for the first device. For example, the instruction may instruct the first device to contact a server. The first data may encode location information.

The first data included in the first portion of the address may be encrypted.

The first message may include information identifying the first device.

The first message may be an advertisement of a Bluetooth® low energy module.

In a third aspect, this specification describes a method comprising: providing, at a first device, a first message advertising the presence of a first device; detecting the first message at a second device; generating an encoded version of a first data, wherein the first data is to be send to a first device; formulating an address having a first portion including the first data and a second portion included the encoded version of the first data; sending a first response to the first message from the second device to the first device, the first response including said address; receiving the first response at the first device; and determining, at the first device, whether the first portion of the first response includes information for the first device.

The method may further comprise extracting the first data in the event that the data portion of the address is determined to include information for the first device.

The first and second portions of the address may be concatenated.

The method may further comprise generating the encoded version of the first data using a resolving key. The encoded version of the first data may be generated from the first data and the resolving key using a hash function. The resolving key may be known to both the first device and the second device.

The first data may encode an instruction for the first device. For example, the instruction may instruct the first device to contact a server.

The first data may encode location information.

The first data included in the first portion of the address may be encrypted.

The first message may include information identifying the first device. The first message may be an advertisement of a Bluetooth® low energy module.

In a fourth aspect, this specification describes an apparatus configured to perform any method as described with reference to the first, second or third aspects. In a fifth aspect, this specification describes computer-readable instructions which, when executed by computing apparatus, cause the computing apparatus to perform a method as described with reference to the first, second or third aspects.

In a sixth aspect, this specification describes a computer-readable medium having computer-readable code stored thereon, the computer readable code, when executed by at least one processor, causes performance of: providing a first message advertising the presence of a first device; receiving, at the first device, a first response to the first message, the first response having an address, the address including a first portion including first data and a second portion included an encoded version of the first data; and determining whether the first portion of the first response includes information for the first device. In a seventh aspect, this specification describes a computer-readable medium having computer-readable code stored thereon, the computer readable code, when executed by at least one processor, causes performance of: generating an encoded version of a first data, wherein the first data is to be send to a first device; formulating an address having a first portion including the first data and a second portion included the encoded version of the first data; detecting a first message advertising the presence of the first device; and sending a first response to the first message, the first response including said address.

In an eighth aspect, this specification describes a computer-readable medium having computer-readable code stored thereon, the computer readable code, when executed by at least one processor, causes performance of: providing, at a first device, a first message advertising the presence of a first device; detecting the first message at a second device; generating an encoded version of a first data, wherein the first data is to be send to a first device; formulating an address having a first portion including the first data and a second portion included the encoded version of the first data; sending a first response to the first message from the second device to the first device, the first response including said address; receiving the first response at the first device; and determining, at the first device, whether the first portion of the first response includes information for the first device. In a ninth aspect, this specification describes an apparatus comprising: at least one processor; and at least one memoiy including computer program code which, when executed by the at least one processor, causes the apparatus to: provide a first message advertising the presence of a first device; receive, at the first device, a first response to the first message, the first response having an address, the address including a first portion including first data and a second portion included an encoded version of the first data; and determine whether the first portion of the first response includes information for the first device.

In a tenth aspect, this specification describes an apparatus comprising: at least one processor; and at least one memory including computer program code which, when executed by the at least one processor, causes the apparatus to: generate an encoded version of a first data, wherein the first data is to be send to a first device; formulate an address having a first portion including the first data and a second portion included the encoded version of the first data; detect a first message advertising the presence of the first device; and send a first response to the first message, the first response including said address.

In an eleventh aspect, this specification describes an apparatus comprising: at least one processor; and at least one memoiy including computer program code which, when executed by the at least one processor, causes the apparatus to: provide, at a first device, a first message advertising the presence of a first device; detect the first message at a second device; generate an encoded version of a first data, wherein the first data is to be send to a first device; formulate an address having a first portion including the first data and a second portion included the encoded version of the first data; send a first response to the first message from the second device to the first device, the first response including said address; receive the first response at the first device; and determine, at the first device, whether the first portion of the first response includes information for the first device.

In a twelfth aspect, this specification describes an apparatus comprising: means for providing a first message advertising the presence of a first device; means for receiving, at the first device, a first response to the first message, the first response having an address, the address including a first portion including first data and a second portion included an encoded version of the first data; and means for determining whether the first portion of the first response includes information for the first device.

In a thirteenth aspect, this specification describes an apparatus comprising: means for generating an encoded version of a first data, wherein the first data is to be send to a first device; means for formulating an address having a first portion including the first data and a second portion included the encoded version of the first data; means for detecting a first message advertising the presence of the first device; and means for sending a first response to the first message, the first response including said address.

In a fourteenth aspect, this specification describes an apparatus comprising: means for providing, at a first device, a first message advertising the presence of a first device; means for detecting the first message at a second device; means for generating an encoded version of a first data, wherein the first data is to be send to a first device; means for formulating an address having a first portion including the first data and a second portion included the encoded version of the first data; means for sending a first response to the first message from the second device to the first device, the first response including said address; means for receiving the first response at the first device; and means for determining, at the first device, whether the first portion of the first response includes information for the first device. Brief description of the drawings

Figure l shows an example system in which the principles described herein could be applied;

Figure 2 is a message sequence showing an example use of the system of Figure l;

Figure 3 is a message sequence showing an example use of the system of Figure l;

Figure 4 shows a system in accordance with an example embodiment;

Figure 5 is a message sequence in accordance with an example embodiment;

Figure 6 shows an example resolvable address format in accordance with an example embodiment;

Figure 7 shows a message format in accordance with an example embodiment;

Figure 8 shows a non-resolvable address format in accordance with an example embodiment;

Figure 9 is a flow chart showing an algorithm in accordance with an example embodiment; Figure 10 is a flow chart showing an algorithm in accordance with an example

embodiment;

Figures 11a to 11c show different views of a system in accordance with an example embodiment;

Figure 12 shows a message sequence in accordance with an example embodiment;

Figure 13 shows a system that may be used in some embodiments;

Figure 14 shows a system in accordance with an example embodiment;

Figure 15 shows a message sequence in accordance with an example embodiment;

Figure 16 is a flow chart showing an algorithm in accordance with an example

embodiment;

Figure 17 is a block diagram, of components of a processing system in accordance with an example embodiment; and

Figures 18a and 18b show tangible media, respectively a removable memory unit and a compact disc (CD) storing computer-readable code which when run by a computer perform operations according to embodiments.

Detailed description

Figure 1 shows an example system, indicated generally by the reference numeral 1, in which the principles described herein could be applied. The system 1 comprises a first Bluetooth® low energy (BLE) device 2 and a second device 4. Bluetooth® low energy devices are wireless devices that transmit data over short distances. BLE devices, such as the device 2, are typically intended to be low power devices and may be used for a wide variety of applications, such as healthcare and fitness tracker applications. The first device 2 may, for example, be an Internet of Things (IoT) sensor that includes BLE functionality.

Figure 2 shows a message sequence, indicated generally by the reference numeral 10, in an example use of the system 1.

The message sequence 10 begins with the first device 2 issuing an advertising message 12 (such that the first device is sometimes referred to as an advertising device). The advertising message 12 invites any compatible device (such as the second device 4) to respond to the advertising message seeking more information about the advertising device 2. Although only one instance of the message 12 is shown in Figure 2, an advertising message 12 may be sent periodically (as described further below).

When in range of the first device 2, the second device receives the advertising message 12. In some embodiments, the second device 4 performs passive scanning (and is sometimes referred to as a scanning device). Passive scanning involves the second device 4 simply detecting the advertising message 12. This may, for example, be used for tracking that the first device 2 is in range of the second device 4. Alternatively, the second device 4 may perform active scanning; this is scenario shown in the message sequence 10. In the message sequence 10, in response to detecting the advertising message 12, the second device 4 sends a scan request message 14 to the first device 2. The scan request message 14 may request further information from the first device 2. On receipt of the scan request message 14, the first device 2 may send a scan response packet 16 to the second device 4. The scan response packet 16 may, in some embodiments, include additional data not included in the advertising message 12.

The message sequence 10 can be used to enable the first device 2 to send data periodically to one or more other devices, such as the second device 4, over a low power short-range wireless connection. The periodic and short-range nature of the wireless communications results in a relatively low power system. By way of example, the first device 2 may be a wearable device that collected health data concerning a person wearing the device. That health data may then be transmitted periodically to the second device 4. The message sequence 10 enables the first device 2 to send data to the second device 4 in the message 16. Figure 3 is a message sequence, indicated generally by the reference numeral 20, showing another example use of the system 1.

The message sequence 20 begins with the first device 2 issuing an advertising message 22 (similar to the advertising message 12 described above). In response to detecting the advertising message 22, the second device 4 sends a scan request message 23 (similar to the scan request message 14 described above) to the first device 2. On receipt of the scan request message 23, the first device 2 may send a scan response packet 24 (similar to the scan response packet 16) to the second device 4. The scan response packet 24 may, in some embodiments, include additional data not included in the advertising message 22.

In order to enable data to be transmitted from the second device 4 to the first device 2, the first and second devices are paired in a pairing operation 25. After the pairing operation 25, data can be transferred (possibly in either direction) between the first device 2 and the second device 4.

The device pairing arrangement shown in the message sequence 20 enables bi-directional communication between the first device 2 and the second device 4. However, the device pairing arrangement can significantly increase the power consumption at the first device 2, which may be undesirable or impractical in some embodiments. Moreover, a scanning device, such as the second device 4, may need to communicate with many devices similar to the first device 2. Pairing with many such devices may present practical challenges for devices such as the second device 4, such as managing multiple device pairings.

Moreover, in some embodiments, some example first devices 2 may not accept device pairing, such as the pairing operation 25, for example for security reasons. Further, some example devices 2 may not send a scan response packet (such as the scan response packets 16 and 24 described above); again, this may be for security reasons.

Figure 4 shows a system, indicated generally by the reference numeral 30, in accordance with an embodiment. The system 20 comprises a first BLE device 32 (similar to the first device 2 described above) and a second device 34 (similar to the second device 4 described above). Figure 5 shows a message sequence, indicated generally by the reference numeral 40, in accordance with an example embodiment.

The message sequence 40 begins with the first BLE device 32 issuing an advertising message 42 (similar to the advertising messages 12 and 22 described above). In response to detecting the advertising message 42, the second device 34 sends a message 44 (similar to the scan request messages 14 and 23 described above) to the first device 32. As described further below, the message sequence 40 uses the format of the message 44 to send data to the device 32.

Some implementations of BLE systems include a privacy feature that provides a level of privacy that makes it more difficult for an unauthorised party to track a device (such as the device 32) over time. The privacy feature involves changing the address of the device periodically. As described further below, an identity resolving key (IRK) can be shared between a first BLE device (such as the device 32) and a second device (such as the device 34) and used to encode address details.

The advertising message 42 (and also the advertising messages 12 and 22) might typically contain a device name and is used to send periodic advertisements in an advertisement channel of a BLE system that the device 32 (or the device 2) is available for

communications. The advertising message may therefore be short. This, together with the periodic sending of the messages as a low power transmission means that the advertising message can be sent as a low power message. The period between advertising messages may vary in different embodiments. For example, the period between advertising messages may be 10ms or 1 second, or any other time period. The period between advertising messages may also be a settable parameter in a system.

Figure 6 shows a first address format, indicated generally by the reference numeral 50, in accordance with an example embodiment. The first address format 50 may be the format of the message 44 sent from the second device 34 to the first device 32 in the message sequence 40 described above.

The message 50 has a resolvable address format and includes a 24-bit random field 54 (including a two-bit identification portion 52) and a 24-bit hash field 56.

As shown in Figure 6, the two most significant bits of the message 50 (the identification portion 52) are‘o’ and T\ The random field 54 can take any value, but in one embodiment, the random field cannot have all bits equal to‘o’ or all bits equal to T\ The hash field 56 is generated using a random address function (denoted by‘ah’). The hash function has two inputs: the contents on the random field 54 (labelled prand in Figure 6) and the identity resolving key (IRK), such that: hash = ah(IRK, prand).

Thus, the hash function and the random value (prand) are concatenated to generate a random address.

Figure 7 shows a message format, indicated generally by the reference numeral 60, in accordance with an example embodiment. The message format 60 is an exemplaiy implementation of the message format 50 and may be used in generating the message 44 sent from the second device 34 to the first device 32 in the message sequence 40 described above. The address format 60 exploits features of the resolvable message format 50 to send data to the device 32.

As shown in Figure 7, the message format 60 includes a two-bit identification portion 62, a data portion 64 (two separate data portions - data 1 and data 2 - are shown in Figure 7) and a hash field 66. The hash field 66 is generated using a random address function (denoted by‘ah’), based on the data portion and the identity resolving key (IRK), such that: hash = ah(IRK, data). Of course, the provision of two data portions is only an example; many different configurations of data could be provided.

On receipt of the message 44 having the message format 60, the first device 32 can readily extract the unencoded data. The first device 32 can then generate a local hash ( LocalHash = ah(IRK, data)) and check that the content of the hash field 66 matches the local hash. (If so, this confirms that the entity generating the message 44 is in possession of the identity resolving key (IRK). Thus, the IRK is being used as a shared secret between the first device 32 and the second device 34.)

If a local hash does not match the hash in a received message, this means that a different IRK was used and that the message is not intended for the first device 32. In this circumstance, the device 32 should not extract and make use of the message. The data portion 64 of the message format 60 has 22-bits available for sending data from the second device 34 to the first device 32 (24 bits, less the 2-bits of the identification code 62). In one example use of the message format 60, the data portion 64 may include two headers bits and 20 data bits. For example, two 10-bit data words may be sent (as shown in Figure 7). The first data could, for example, include longitude location data for the second device 34, with the second data including latitude location data for the host 34. In this way, the first device 32 can be informed of the geographic location of the second device 34. If the first device 32 is moving, the location data of other nearby devices (such as the second device 34) can be used to track the approximate device location.

Figure 8 shows a second address format, indicated generally by the reference numeral 70, in accordance with an example embodiment. The second address format 70 may be in the format of the message 44 sent from the second device 34 to the first device 32 in the message sequence 40 described above. Again, the address format 70 can be exploited to send data to the first device 32.

The message 70 has a non-resolvable address format and includes a two-bit identification portion 72 and a 46-bit random field 74. As shown in Figure 8, the two most significant bits of the message 70 (the identification portion 72) are‘o’ and‘o’. The random field 74 may include a 2-bit header and a 44-bit payload, which payload may be used for data transfer between the second device 34 and the first device 32.

By way of example, the 44-bit payload may include a data portion and a hash portion. For example, 36-bits of data could be sent, together with a 10-bit hash formed from a message resolving key (MSK) used as a shared secret between the first device 32 and the second device 34, such that hash = ah(MRK, data).

In one example use of the invention, the 36-bits of data could be used as follows. The first 17-bits of data transmit first location data (e.g. longitude), the second 17-bits of data transmit second location data (e.g. latitude) and the remaining 10-bits of data include some other information. (Of course, the transmission of location data is just one of many example uses of the principles described herein.)

Figure 9 is a flow chart showing an algorithm, indicated generally by the reference numeral 90, in accordance with an example embodiment. The algorithm 90 shows an example implementation of the message sequence 40. The algorithm 90 starts at operation 91, where an advertisement message 42 is sent by the first device 32 (the advertising device). At operation 93, it is determined whether or not a receive response (i.e. the message 44) has been received. If not, the algorithm returns to step 91 and a further advertisement is sent (perhaps following a delay period). If the response message 44 has been received, the algorithm 90 moves to operation 95.

In the algorithm 90, the message sequence 50 is used. Thus, at operation 95, a hash function is used to determine that the message has been encoded using the IRK of the first device 32. Assuming, the correct message is identified, then algorithm 90 moves to operation 97 where the data is extracted from the random part 54 of the message (e.g. the data 64 shown in Figure 7).

Finally, at operation 99, the extracted data is used or, if provided in encoded form, the extracted data is decoded.

Figure 10 is a flow chart showing an algorithm, indicated generally by the reference numeral 100, in accordance with an example embodiment. The algorithm 100 is similar to the algorithm 90 described above, differing only because the address format being used is different.

The algorithm 100 starts at operation 101, where an advertisement message 42 is sent by the first device 32. At operation 103, it is determined whether or not a receive response (i.e. the message 44) has been received. If not, the algorithm returns to step 101 and a further advertisement is sent (perhaps following a delay period). If the response message 44 has been received, the algorithm 100 moves to operation 105.

In the algorithm 100, the message sequence 70 is used. Thus, at operation 105, a hash function is applied to determine that the message has been encoded using the MRK of the first device 32. If so, the message is decoded using that MRK. Assuming, the correct message is identified, the algorithm 100 moves to operation 107 where the extracted data is used or, if provided in encoded form, the extracted data is decoded.

The data transmitted using the principles described herein can take many different forms. As described above, data, such as location data, could be sent. Alternatively, the data fields could be used to send coded information and/or set particular flags that will be understood by the first device 32. Accordingly, the embodiments are extremely flexible. Figures 11a to 11c show different views of a system, indicated generally by the reference numeral no, in which the principles described in this specification could be applied. Specifically, Figure 11a shows a system 110a including a first device 112 (such as a

Bluetooth® low energy (BLE) device) and a second device 114. The first device 112 is moving towards the second device 114. Figure 11b shows a system 110b in which the first device 112 has moved closer to the second device. Figure 11c shows a system 110c in which the first device 112 is even closer to the second device 114. (The earlier position of the first device 112 is show in dotted form in Figures 11b and 11c.) In one example use of the system 110, the first device 112 is a tracker device worn by a user, which may be used, for example, to monitor the movement of a user (e.g. as part of a health application). The first device 112 may make contact with a second device (such as the second device 114) in order to obtain location information for use in the health monitoring application. BLE devices are typically low power devices that communicate periodically over short distances.

Figure 12 shows a message sequence, indicated generally by the reference numeral 120, in accordance with an example embodiment. The message sequence 120 begins with the first device 112 issuing an advertising message 122. The advertising message 122 invites any compatible device (such as the second device 114) to respond to the advertising message seeking more information about the first device.

Assume that the message 122 is sent with the first device 112 and the second device 114 in the positions shown in Figure 11a, but that the first device 112 is too remote for the message 122 to be successfully received at the second device 114. As shown in the message sequence 120, the second device 114 takes no action in response to the message 122.

Later, the first device 112 moves to the position shown in Figure 11b and a second advertising message 124 is sent. The first device 112 is still too remote from the second device 114 and again no action is taken in response to the advertising message 124.

Later still, the first device 112 moves to the position shown in Figure 11c and a third advertising message 126 is sent. Now, the first device 112 is within range of the second device 114. As shown in Figure 12, the second device 114 responds to the advertising message 126 by sending a message 128 to the device 112. The message 128 may, for example, include location data. In some embodiments, data included within messages, such as messages using the formats 50, 60 or 70 described above, may be enciypted in order to avoid plain text communication. Alternatively, or in addition, a data whitening process may be applied. Figure 13 shows a system, indicated generally by the reference numeral 130, that may be used in some embodiments for data whitening. Of course, other arrangements are possible.

Figure 14 shows a system, indicated generally by the reference numeral 140, in accordance with an example embodiment. The system 140 comprises a first device 142 (similar to the devices 2, 32 and 112 described above), a second device 144 (similar to the devices 4, 34 and 114 described above), a server 146, a first communication network 148 for

communications between the first device 142 and the server 146 and a second

communication network 149 for communications between the server 146 and the second device 144. The communications networks 148 and 149 could take many different forms, such as IP networks (e.g. the Internet) or a mobile network. Note that the networks 148 and 149 could be the same communications network.

In one exemplary use of the system 140, the first device 142 is a meter (such as a water meter or an electricity meter). The first device 142 sends information, such as meter readings, to the server 146. For example, the first device 142 may send meter reading data to the server 146 once per day.

The server 146 may also send information to the first device 142. For example, in the example above, the server 146 may send tariff information to the first device 142.

However, in some implementations, the server 146 may only be able to send information to the first device 142 when that device is connected to the server. The server 146 may simply wait for the first device 142 to make contact. Alternatively, the server 146 could make use of the second device 144 (which is local to the first device 142) to instruct the first device 142 to make contact with the server, as described further below.

Figure 15 shows a message sequence, indicated generally by the reference numeral 150, in accordance with an example embodiment.

The message sequence 150 begins with the first device 142 issues an advertising message 151. At this stage, the second device 144 has no reason to contact the first device 142 and so no response is made to the advertising message 151. After a delay period (e.g. 1 second), the first device 142 issues a second advertising message 152. Again, the second device 144 has no reason to contact the device 142 and so no response is made to the advertising message 152. Next, the server 146 sends a message 153 to the second device 144 indicating that the server wants to make contact with the first device 142. The message 153 is sent using the network 149.

After a delay period following the second advertising message 152, the first device 142 issues a third advertising message 154. In response to the advertising message 154, the second device 144 sends a response 155 instructing the first device 142 to make contact with the server 146. As shown in Figure 15, the first device 142 responds to the message 155 by contacting the server as indicated by the message 156. The server 146 can then send data to the device (e.g. an updated meter tariff, as described above).

The message 155 sent from the second device 144 to the first device 142 may take one of many forms. The message may make use of the data part of a message (such as the data portions 64 and 74 of the message formats 60 and 70). The data may, for example, take the form of a flag that is set indicating that the first device 142 should contact the server 146. Note that the second device 144 does not need to be given any information about the reason for the server wanting to make contact with the device 142.

Figure 16 is a flow chart, indicated generally by the reference numeral 160, showing an algorithm in accordance with an example embodiment. The algorithm starts at operation 162 where the first device 142 sends an advertising message. The step 162 is repeated until the device receives (at operation 164) a message to contact the server 146. Then, at operation 166, the first device 142 makes contact with the server. It should be noted that the algorithm 160 ensures that the device can be made to make contact with the server quickly (depending on the period between advertising messages), but that the potentially power demanding step of contacting the server only needs to be carried out by the first device 142 when necessaiy.

There are many potential uses for the principles described herein. The following is a short, non-limiting, list of such examples.

Consider an application in which the first device 32, 112 or 142 is an automated floor cleaner. The message protocol described herein may be used to enable the second device 34, 114 or 144 to send instructions to the first device 32, 112 or 142 regarding the cleaning repeat frequency with which cleaning should take place. For example, the frequency may be reduced if the user is going on holiday. Moreover, the second device 144 might instruct the device 142 to contact the server 146 in order for instructions to be sent to the device 142. This might be appropriate, for example, for sending detailed instructions regarding future cleaning times to be sent to the device.

In another example, a refrigeration system might have a mechanism to communicate with objects within the system to extract expiiy date data from those objects. For example, the first device 32, 112 or 142 might be used to collect such expiry date information. This step may be carried out periodically (e.g. once per week in order to generate a weekly shopping list).

The message protocols described herein may be used to enable the second device 34, 114 or 144 to instruct the first device 32, 112 or 142 to generate a list of items that are close to the expiry data in order for an ad-hoc on-line shopping order to be generated (e.g. not as part of a normal weekly sequence). The instructions sent from the second device to the first device might include an instruction to generate the data and a relevant date (e.g. instructions to generate a list of items having an expiry date in the next three days).

Moreover, the second device 144 may instruct the first device 142 to contact the server 146 in order for instructions to be obtained by the device 142 from the server 146.

In yet a further example, the first device 32, 112 or 142 may be a controller for an air exchange system for a room or a property. In the event that a warm day is forecast, a user may decide to use the second device 34, 114 or 144 to instruct the device 32, 112 or 142 to increase the air exchange rate for the room or property. Moreover, the second device 144 may instruct the first device 142 to contact the server 146 in order for instructions to be obtained by the device 142 from the server 146. By way of example, the server may be used to send detailed instructions regarding when to perform the air exchange. Thus, for example, the server 146 may calculate an optimum time for the air exchange to be carried out (e.g. the warmest two hours of the day, based on weather forecast data available to the server) and the first device 142 may be instructed by the second device 144 to contact the server 146 in order to receive those instructions. In a further example, the first device 142 is a mobile phone owned by a child and the second device 144 is a mobile phone owned by a parent of that child. The first device 142 normally operates in a restricted mode in which access to external sites is restricted. The first device 142 may be arranged to periodically contact the server 146 for updating information regarding restricted sites (e.g. an update to a list of prohibited websites). In an alternative arrangement, external access during certain times might be restricted. On occasions, a parent may wish to unlock some or all restrictions for a limited time (e.g. if the child is going to a concert and may wish to make contact with others, including the parent). In order to do so, the parent may change security settings at the server 146 for a limited period. The algorithms described above may then be used to instruct the first device 142 to contact the server 146 in order to obtained updated security settings. For completeness, Figure 17 is a schematic diagram of components of one or more of the modules described previously (e.g. implementing some or all of the operations of the message sequences 40, 120 and 150 and the algorithms 90, 100 and 160 described above), which hereafter are referred to generically as processing systems 300. A processing system 300 may have a processor 302, a memory 304 closely coupled to the processor and comprised of a RAM 314 and ROM 312, and, optionally, user input 310 and a display 318.

The processing system 300 may comprise one or more network interfaces 308 for connection to a network, e.g. a modem which may be wired or wireless.

The processor 302 is connected to each of the other components in order to control operation thereof.

The memory 304 may comprise a non-volatile memory, such as a hard disk drive (HDD) or a solid state drive (SSD). The ROM 312 of the memory 314 stores, amongst other things, an operating system 315 and may store software applications 316. The RAM 314 of the memory 304 is used by the processor 302 for the temporaiy storage of data. The operating system 315 may contain code which, when executed by the processor implements aspects any of the message sequences and algorithms 40, 90, 100, 120, 150 and/or 160 described above. The processor 302 may take any suitable form. For instance, it may be a microcontroller, plural microcontrollers, a processor, or plural processors.

The processing system 300 may be a standalone computer, a server, a console, or a network thereof.

In some embodiments, the processing system 300 may also be associated with external software applications. These may be applications stored on a remote server device and may run partly or exclusively on the remote server device. These applications may be termed cloud-hosted applications (an example of such an application is an application to manage child filters restricting access to use during certain times or access websites from a child’s mobile phone, as described above). The processing system 300 may be in communication with the remote server device in order to utilize the software application stored there.

Figures 18a and 18b show tangible media, respectively a removable memoiy unit 365 and a compact disc (CD) 368, storing computer-readable code which when run by a computer may perform methods according to embodiments described above. The removable memoiy unit 365 may be a memory stick, e.g. a USB memory stick, having internal memory 366 storing the computer-readable code. The memory 366 may be accessed by a computer system via a connector 367. The CD 368 may be a CD-ROM or a DVD or similar. Other forms of tangible storage media may be used.

Embodiments of the present invention may be implemented in software, hardware, application logic or a combination of software, hardware and application logic. The software, application logic and/or hardware may reside on memoiy, or any computer media. In an example embodiment, the application logic, software or an instruction set is maintained on any one of various conventional computer-readable media. In the context of this document, a“memory” or“computer-readable medium” may be any non-transitoiy media or means that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer.

Reference to, where relevant,“computer-readable storage medium”,“computer program product”,“tangibly embodied computer program” etc., or a“processor” or“processing circuitry” etc. should be understood to encompass not only computers having differing architectures such as single/multi-processor architectures and sequencers/parallel architectures, but also specialised circuits such as field programmable gate arrays FPGA, application specify circuits ASIC, signal processing devices and other devices. References to computer program, instructions, code etc. should be understood to express software for a programmable processor firmware such as the programmable content of a hardware device as instructions for a processor or configured or configuration settings for a fixed function device, gate array, programmable logic device, etc. As used in this application, the term“circuitiy” refers to all of the following: (a) hardware- only circuit implementations (such as implementations in only analogue and/or digital circuitry) and (b) to combinations of circuits and software (and/or firmware), such as (as applicable): (i) to a combination of processor(s) or (ii) to portions of processor(s)/software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a server, to perform various functions) and (c) to circuits, such as a microprocessor(s) or a portion of a microprocessor(s), that require software or firmware for operation, even if the software or firmware is not physically present. If desired, the different functions discussed herein may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the above- described functions may be optional or may be combined. Similarly, it will also be appreciated that the flow diagrams of Figures 9, 10 and 16 are examples only and that various operations depicted therein may be omitted, reordered and/or combined.

It will be appreciated that the above described example embodiments are purely illustrative and are not limiting on the scope of the invention. Other variations and modifications will be apparent to persons skilled in the art upon reading the present specification. For example, although the embodiments described above typically refer to Bluetooth® low energy applications, this is not essential. The principles described herein could be applied to other communication and data transfer systems.

Moreover, the disclosure of the present application should be understood to include any novel features or any novel combination of features either explicitly or implicitly disclosed herein or any generalization thereof and during the prosecution of the present application or of any application derived therefrom, new claims may be formulated to cover any such features and/or combination of such features.

Although various aspects of the invention are set out in the independent claims, other aspects of the invention comprise other combinations of features from the described embodiments and/or the dependent claims with the features of the independent claims, and not solely the combinations explicitly set out in the claims.

It is also noted herein that while the above describes various examples, these descriptions should not be viewed in a limiting sense. Rather, there are several variations and modifications which may be made without departing from the scope of the present invention as defined in the appended claims.