GB2472769A - Contactless charging system with priority consideration - Google Patents

Abstract

A charging system comprising: a charger 121 capable of generating a field, for example using an inductive coil 120; two or more discrete devices 1, 30, 40, each comprising a rechargeable energy store 10, 31, 41 capable of powering the device, a pickup 12, 32, 42 for harnessing energy from the field, a switching device 14, 34, 44 having a first state in which it couples the pickup to the energy store for charging and a second in which it isolates the pickup; a data store storing an operating priority for each of the devices; and a controller having access to the data store and configured to control the switching device of one or more of the devices depending on the operating priority for that device. The system may estimate device power requirements and priority data may be transferred to other systems. The devices may be a datalogger and sensors.

Description

I

CRITICALITY-BASED CHARGING

This invention relates to charging equipment that includes multiple components which each have their own energy store. For example, the equipment could comprise a datalogger and ancillary sensors.

Dataloggers are devices that record sensed data and allow the data to be processed on the logging device, or uploaded to another device for secondary analysis. The data could be collected from sensors on the datalogger or from external sensors that communicate with the datalogger through wired or wireless protocols.

One use of dataloggers is for gathering physiological conditional data about a person. A person can carry a datalogger and any associated sensors whilst they are in motion. The data recorded by the datalogger can then be uploaded to a third party system for analysis. Dataloggers that record physiological information have a variety of uses. For example, they can be used for medical purposes to monitor a patient's response to a course of treatment, or to monitor background factors about a person's lifestyle that may allow a doctor to advise on healthy living (see US 5,778,882, for instance); and for sports purposes, to monitor an athlete's performance.

Energy consumption is a significant issue in the design of dataloggers. It is desirable for a datalogger to be small and light, with a self-contained energy source such as a battery, but also to operate for as long as possible.

The data that is collected by dataloggers may be collected at discrete times or continuously. The period between data sampling may be application specific. An example of data that may be logged at discrete times is a patient's weight, which may be taken once a day, or more frequently if required. Data that varies more rapidly could be collected continuously. Examples include heart rate (or ECG curve), blood pressure, and Sp02. Whilst these are referred to as being collected continuously, they may in fact be sampled at discrete times: typically several times per second in the case of an ECG curve.

Collecting data continuously generates large amounts of data. If the sensor in question communicates wirelessly with the datalogger then significant amounts of energy can be required to transmit the data from the sensor to the datalogger. This, together with the amount of memory needed to store the data, limits the amount of time for which the devices can gather continuous data such as ECG curves.

Current devices of this type are limited to gathering short bursts of ECG data. It would be desirable to be able to collect an increased amount of EGG (or other) data without increasing the size of the device. One motivation for this is to increase the amount of data available to clinicians for diagnostic purposes. Another motivation is to increase the integrity of the data to the level that is needed for monitoring drugs trials and the like.

Two routes are available for uploading the logged data. Some devices upload the logged data when they are physically attached to a docking station. The docking station has a communications facility. (Ethernet connection, modem port, or another form of network connection) by means of which it can pass the data to a remote computer. Other devices, which can be integrated into mobile phone systems as attached devices, may use mobile phone networks to upload the data. Uploading data wirelessly in this way has the advantage that the data can be uploaded when the user of the datalogger is away from his home, but has the disadvantage that it can use large amounts of energy.

Where a user is able to cope with complex functions, it may be desirable for a medical datalogger to offer those functions. However, medical dataloggers are likely to be used by people who, for reasons of infirmity, might be unable to operate a complex user interface or pay full attention to the data that is available from a datalogger. It is therefore desirable to simplify as much as possible the way in which the device can be used, and to allow other individuals to assist the user in benefitting from the data that is logged: either by analysing it on the user's behalf, or by providing assistance to the user if the data indicates that that is appropriate.

The datalogging system might comprise multiple discrete devices, such as a datalogger and a number of sensors that can sense data and communicate the sensed data wirelessly to the datalogger. In this type of system the datalogger and each of the sensors will be expected to have their own local energy store. As the system is used the energy stores will be depleted, and will need to be replaced or more preferably recharged. However, recharging a number of devices is inconvenient for a user. Using a conventional charging mechanism, where each device is plugged into a respective mains-powered charger might require many chargers and might occupy some time to plug and later unplug each device. More recently, proximity charging mechanisms have been developed. In these systems devices that are to be charged do not need to be plugged into a charger. Instead they are positioned near a charging unit that can transfer energy contactlessly to the devices. The charging unit could, for example, be a mat or plate that contains a coil which is energised from the electrical mains and cooperates inductively with a respective coil in each device in order to transfer charge to it. Such a system is described, for example, in EP 1 868 275 A. However, such systems are typically able to charge the devices less quickly than a plug-in charger, which may result in the user having to wait longer before they can use a device. This is a particular problem for medical devices since the health of the user might depend on the device being available for use.

There is a need for a datalogger and/or a charging system that is improved in one or more of the areas identified above.

According to one aspect of the present invention there is provided: a charging system comprising: a charger capable of generating a field; two or more discrete devices, each discrete device comprising a rechargeable energy store capable of powering the operation of the device, a pickup for harnessing energy from the field generated by the charger, a switching device having a first state in which it couples the pickup to the energy store whereby the energy store can be charged from the pickup and a second state in which it isolates the pickup; a data store storing an operating priority for each of the discrete devices; and a controller having access to the data store and configured to control the switching device of one or more of the discrete devices in dependence on the operating priority for that device.

The charger may be an inductive charger and each pickup is an inductive pickup.

The controller may be comprised in one of the devices.

The controller may be configured to control the switching device of each of the discrete devices in dependence on the operating priority for that device.

Each discrete device may comprise a respective controller that is configured to control the switching device of the respective discrete device in dependence on the operating priority for that device.

The controller may be comprised in the charger.

The or each controller may be configured to control the switching device of one or more of the discrete devices in dependence on the operating priorities for that device and the other discrete devices.

The or each controfler may be configured to control the switching device of one or more of the discrete devices in dependence on the operating priority for that device and on the level of the energy store of that device.

The or each controller may be configured to control the switching device of one or more of the discrete devices in dependence on the operating priority for that device and on the levels of the energy store of that device and the other discrete devices.

The controller may have access to information indicating the energy requirement of at least one of the devices over time, be configured to estimate whether the charger will deliver sufficient energy to that device to meet that energy requirement over time, and in response to that determination being negative, to signal the user to intervene to charge that device.

The data store may be is held in the controller.

The controller may be capable of exporting data from and/or importing data to the data store.

The controller may be capable of exporting the operating priorities to a similar controller.

The controller may be capable of automatically exporting the operating priorities to the similar controller if the controller detects that its stored energy is below a pre-stored threshold.

On exporting the operating priorities the controller may be capable of handing over the devices from interaction with itself to interaction with the similar controller.

The present invention will now be described by way of example, with reference to the accompanying drawings, in which: Figure 1 is a schematic drawing of a datalogger and associated data collection, storage and analysis equipment.

Figure 2 is a schematic drawing of the adaptive and dynamic device criticality and bandwidth control mechanisms.

Figure 3 illustrates a charging system.

Figure 1 shows a datalogger 1. The datalogger is a portable device having a housing 2 which encloses the other components. The datalogger comprises a processor 3, a non-volatile memory 4, a touch-screen display 5, a set of wireless interface modules 6, 7, 8, 9 and a rechargeable battery 10 which powers the other components. The processor runs program code that is stored as firmware 11 in memory 4. That code defines the functioning of the processor, and hence of the device. The display 5 is controlled by the processor to display images under the control of the program code. When a user touches the display, the display signals that pressure to the processor, which can use it as input. Instead of a touchscreen display, the device could have a simpler means of providing a user interface: for example a separate display and keypad, or a series of individual signalling LEDs (light emitting diodes).

Each wireless interface module operates for a respective wireless protocol, and is coupled to the processor for passing to the processor data received over a wireless channel and for receiving from the processor data to be transmitted over the wireless channel. In this example, modules 6 and 7 operate for short-range wireless protocols that can be used for communicating with sensors, and modules 8 and 9 operate for longer-range protocols that can be used for communicating with a data server. The same protocol could be used for both purposes. The device could alternatively be connected by a wired link for either purpose.

Conveniently each wireless module handles the lower layers, e.g. up to and including the session layer, for communication using its protocol. Examples of protocols suitable for communication with sensors include ANT, Bluetooth, IRDA, Zigbee, Wibree, UWB, and 802.1IA/B/G/N, as well as proprietary means of data communications using ISM or registered frequency band communications, including the usage of such multiplexing algorithms as GSFK, OFDM, FHSS, DSSS, CSDM etc. Examples of protocols suitable for uplink communication include wireless LAN protocols such as 802.11 NB/GIN and protocols suitable for carrying data over a mobile phone network such as such as GSM, GPRS, UMTS (3G) EDGE, and BGAN.

A series of sensor modules are available for operation with the datalogger 1. The sensors illustrated in figure 1 are as follows: ECG sensor module 20, Sp02 sensor module 30, blood pressure sensor module 40, accelerometer module 50, weighing module 60, blood glucose sensor module 70. Sensor modules 20, 30, 40 and 50 are capable of continuous operation (including substantially continuous operation) with the datalogger. These modules are preferably wearable or attachable to the user's body. For example, they could be embedded in or attached to belts, cuffs, implants or adhesive pads. Sensor modules 60 and 70 are capable of periodic operation with the data logger.

The datalogger itself, and potentially some of the sensors, are fully portable, in so far as they may be readily carried by a person.

The sensors provide data to the data logger through their own proprietary means, or choice in established protocol, presenting their respective data to the datalogger through an established or proprietary data format. The majority of wireless sensors that are independent of mains power supply have performance limitations that are governed through an established balance between on board memory capacity, battery life, and sampling frequency.

A base unit 80 (see figure 1) operates with the datalogger and the sensor modules.

The base unit is connected to the mains electrical supply via a suitable power conversion and limiting device and has a cradle 84 in which are terminals that provide a low-voltage output. This can be used to charge the rechargeable batteries of the datalogger and potentially some of the sensor modules, when they are in contact with it. Conveniently, the datalogger and the sensor modules have common charging connectors so that they can attach to the same charging point 81, or similar charging points, on the base unit. Alternatively, they could be charged by an inductive charging arrangement on the base unit, or via an electromagnetic near field behaviour concept potentially based on coupled resonance, such as Resonant Inductive Coupling. The base unit also has a wireless interface module 82 which operates according to a protocol that can communicate with the datalogger for uploading logged data from the datalogger. Examples of suitable protocols include wireless LAN protocols (e.g. 802.1 1NB/G/N), Bluetooth and UWB. The base unit 80 also has a mechanism by which it can connect to a wider network such as the internet in order to pass the logged data to a remote server. For that purpose, the base unit may have a wired network connection (e.g. an Ethernet connection) 83.

A server infrastructure shown generally at 90 is capable of storing and processing data that has been logged by the datalogger. The server infrastructure may receive data from the datalogger over a publicly accessible network such as the internet 91, or over a private network such as a mobile phone network 93. The private network may be connected to the server infrastructure by an APN connection 92. An interface 94 interfaces between a communication server 96 and the connections 92, by which data can be received from the datalogger. The communication server 96 manages communications with the datalogger 1. When data is to be uploaded from the datalogger, either the communication server may request that data or the data may be pushed by the datalogger. When the data is received by the communication server it formats the data as appropriate, and stores the data in a log database 97. That data may then be accessed by a reporting server 98, which can run automated reporting and analysis processes on the data, and by a client interface 99 by means of which the data can be accessed by users of the system, such as doctors. Information extracted via the client interface 99 can be presented via any suitable interface, for example a website 100, or via an API 101 to an external database 110. Credentials for authenticating users of the client interface are stored in a security database 102.

A configuration database 103 stores data defining the configuration of each datalogger that is used with the system. The configuration may include the firmware version installed on the datalogger, the type and identity of each sensor module that is paired with the datalogger and the firmware version installed on each sensor. The communication server can use that configuration information to control the datalogger, as will be described in more detail below.

The principal functions of the system are: (a) collection of data, (b) transfer of data from sensor to datalogger, (C) datalogger upload of data, (d) analysis or review of data, (e) configuration of the datalogger and (f) control of charging.

Collection of Data When data is to be collected, the user of the datalogger can carry the datalogger on his person, for example in a pocket, attached to his belt or attached to an armband.

The user may do this 24 hours a day, or just during times when they require to collect data. The sensors that are to be used are deployed as required for taking measurements: Wireless sensors may utilise either an established wireless data communication protocol, or a proprietary wireless or cabled means for communicating with the datalogger. When a communications path is present the sensory device may opt to route the data to its end point. When a communications path is not available the sensory device may seek to store the data locally upon its inbuilt memory, optionally using a cyclic purge system, such that only the latest data is kept in memory.

In one embodiment the sensory module may store a threshold power level that is accessible to its wireless module. If the wire'ess module can communicate with the datalogger using less than the pie-stored threshold transmit power level, then the sensing module promptly transmits the sampled data to the datalogger by means of the wireless module. If the wireless module of the sensing module cannot communicate with the datalogger at below the threshold transmit power level then the sensing module caches the sensed data in its local memory. When communication with the datalogger at below the threshold transmit power level is re-established, then the data from the memory is sent to the datalogger and then cyclically deleted from the memory. This allows significant power savings at both the sensor module and the datalogger since data can be kept at the sensor module until they can be transmitted to the datalogger with sufficiently low power.

Power usage by the sensor devices may also be managed by the datalogger. The datalogger may use the criticality factor of the device (see below) to determine a round robin polling order of the devices. Instead of each sensor device being allocated a communication slot in turn, devices that have a higher criticality factor could have relatively more slots allocated to them. Should the criticality factor of a sensor device warrant constant monitoring of said device, then the datalogger can maintain continuous communications with that highest criticality factor device until a threshold (e.g. a time-out) is met such that the remaining attached device's data must be uploaded. At this point the collecting device will ensure that the highest criticality factor device keeps its data in memory whilst the round robin polling scheme is applied to the lesser criticality factored devices.

In order to allow the datalogger to make use of data that is received in either an untimely manner or an out of sequence manner, the sensed data should be stored in such a manner that the time at which the data was acquired by the sensory device can be established by the datalogger. To achieve this, the sensory device may maintain a local clock with which to timestamp the data. Subsequently the sample value and the time value are sent, for example as a tuple pair, to the datalogger. In such a manner, the datalogger can determine the time at which each sample was taken. In some cases it may be possible for the datalogger to maintain a synchronous heartbeat with the sensory devices, which may establish the offset between the datalogger's internal clock and the internal clocks of the sensory devices attached to it. Thus, the sensory device can send sensed data to the datalogger continuously, as it is sensed, or in bursts having been cached for some time at the sensor.

For sensors that utilise wireless communications, be it infra red, radio frequency, electromagnetic near field or other means, power is a key issue, bearing in mind that if the sensor is to store energy it would most conveniently be battery powered. The levels of transmit power available to the sensory devices may also be controlled by legislation that differs from region to region. If it is assumed that a sensory device starts by utilising the maximum transmitted power available (Pmax) to the transmitter, taking into account any gain by antennas or loss through wiring, such that the EIRP (equivalent isotropically radiated power) is within the legal limit, then if communications between the sensory device and the datalogger can be established then the sensory units' data may be uploaded in near real time, utilising the time stamped principle to ensure ordered data delivery. If the transmit power of the sensory device can be scaled down to a lower power (Pmax-x), such that the maximum permitted EIRP for that region is not exceeded at any point, then if it is to conserve battery life the sensory unit should scale down the transmit power. If communications between the data logger and the sensory device are lost or become weak, then the sensory device can store the data to local memory. The sensory device can subsequently re-establish communications using, if necessary, the maximum amount of power available to the sensory device (Pmax).

If the datalogger and sensory devices are configured to be able to send an acknowledgement of the time stamped data that has been sent and received, as would be the case in TCP communications. The sensory device should be able to decipher from the acknowledgements sent by the data logger that the data it sent had been sent in a timely and robust manner, and thus should be able to reduce the transmit power level until the acknowledgements are no longer received in such a manner, at which stage the sensory device can increase the transmission power to a threshold level suitable ((Pmax-x)+y) to allow effective communications from the sensory device to the data logger, whilst also allowing a suitable buffer level of available power.

The sampling rate of the data should also be selected by the sensory device in a dynamic fashion. The data that the sensory device produces can be acquired at a range of varying rates, determined by the user of the device, pre-programmed into the sensory device or configured remotely. If the sensory device collects sensory data at a sampling interval (Is) of O.ls, the sensory device has the option of routing the sampled data to the datalogger at the same rate, assuming the connection exists and the bandwidth (Bd) downstream of the data logger is sufficient, or, the sensory device may buffer the data for a period of time (Tb) and then send the buffered data in one stream.

The criticality of the data from the sensory devices attached to the datalogger may be determined by the system administrator. In reality in a human physiological monitoring exercise, the data coming from a wirelessly attached ECO may be the most important type of data, followed by data from an Sp02 monitor, followed by data from a blood glucose monitor. The criticality of the attached sensory devices can therefore be indicated by their criticality factor (Cf). The criticality factor may be expresses as an integer value, with the criticality factor starting at 1 (Cfl) for essential devices, then decreasing to Cf2 for the next most critical devices etc. Assuming the Bandwidth Bd is a finite value at any point in time, it is therefore possible to route sensory device data according to its criticality and sampling rate.

Thus the bandwidth Bd may be proportioned with the correct scaling factor to allow the most critical sensory devices the ability to route their data at the desired sampling rate Ts, with the minimal amount of sampled data being routed to the sensory devices storage buffer Tb. Thus when the bandwidth Bd is high enough to support a high sampling rate Ts, there will be a low usage of the buffer store Tb; thus Bd supports Ts, with Ts being inversely proportional to Tb.

If the bandwidth Bd is high enough to support two equally high critical factor CF1 Sensory devices (Devi and Dev2) then equal bandwidth Bd/2 will be applied to either device Devi or Dev2, however if the bandwidth B is insufficient to support both Devi and Dev2 when transmitting all their available data in the most energy-efficient way then a number of techniques can be used to allow both devices to upload their data to the datalogger. First, the data can be processed in one or more of a number of ways to reduce the bandwidth required for its transmission. For example: (i) the data can be compressed losslessly before transmission despite the fact that this would be expected to increase power consumption; (ii) the data could be culled so that its resolution is reduced or some samples are lost; (iii) the data could be encrypted using a simpler algorithm, or not encrypted at all, if that reduces the amount of bandwidth required to transmit the data or saves power to compensate for an increaseimpower used for compression; (iv) a hashing function could be used to simplify the data. Second, the data from the devices can be buffered at each device so that transmissions from the devices can be interleaved. The transmissions from the devices can then take place when bandwidth becomes available or under the control of the datalogger.

Encryption may be performed using any suitable encryption algorithm. The mechanism by which encryption at the datalogger is performed can be dependent on factors including the level of energy stored by the datalogger. For example, the datalogger may store an energy threshold. When the energy stored by the datalogger (e.g. the level of charge remaining in its battery) exceeds the threshold data received by the datalogger from the sensor devices is encrypted by the datalogger by means of a first algorithm and then transmitted to the server. When the energy stored by the datalogger is less than the threshold data received by the datalogger from the sensor devices is encrypted by the datalogger by means of a second algorithm and then transmitted to the server. The second algorithm is an algorithm which the datalogger can implement using less energy than it takes to implement the first algorithm. For example, the first algorithm could use a longer encryption key than the second algorithm. Alternatively, when stored energy is below the threshold the datalogger could omit to encrypt data before sending it to the server. These mechanisms have the advantage of prolonging the operational time of the datalogger whilst maintaining full operational performance when energy is readily available. In this way, the device can avoid the loss or delay of critical data when energy would otherwise run out.

This switching between devices may be performed in any suitable manner. One example is to use the round robin principles of data switching between devices, analogous to a Bluetooth piconet.

If the datalogger is equipped with multiple wireless interface modules that support the same protocol, then it is possible to create different sub-groups of devices that use similar protocols, according to the criticality factor of the attached devices, thus allowing the processing of the datalogger to be configured to place the most cycles and processing threads to assign and manage the high Cf devices, whilst still allowing some threads and processing cycles for the low Cf devices, with a scaling proportionality appointed as to the number of high and low criticality devices.

In cases where the sensory devices attached to the datalogger are of different criticalities and protocols, the data logger can appoint resources proportionally. If Devi is an ANT protocol device and of Cf I and Dev2 a Bluetooth device of Cf2, these devices will utilise different amounts of transmit power and appear with different strengths in the same frequency bands. The datalogger may advantageously be dynamic enough to be able to calculate and manage the criticality of the devices in the context of the protocols which are routing the sensory devices' information. In some cases it may be necessary to limit or truncate one protocol's efficacy, in order to route or receive packets of a higher criticality from another protocol. In such cases the device which has its transmission protocol interrupted can advantageously revert to capturing their sensory data to local memory when it is not transmitting.

The datalogger can advantageously be able to receive near-live time series data from a range of wired and wireless attached sensory devices. Owing to wireless data transmission constraints the datalogger can advantageously be able to control and apportion the available bandwidth located to facilitate a proportion of the available bandwidth such that live information may be sent across the wireless link, as well as historical data that has been buffered and stored by the sensory device in its memory.

This balance between live and post-live data bandwidth is known as the Bandwidth Timeliness Function (Bd-tf). This scenario allows for interruptions to the sensory devices' available uplink bandwidth. The Bandwidth Bd can be sub-divided into bandwidth for near-live data (Bd-nl) and bandwidth for post-live data (Bd-pl), with the sub-division being dynamically controlled by the data logger. In such a manner the datalogger can control the availability of both the live and post-live data. It is preferable that for sensory devices with high criticalities the Bandwidth Timeliness Function will favour 100% near-live data (Bnl) until there is a break in the reception of the time series data from the sensory device such that the near-live proportion of the Bandwidth Timeliness Function will far exceed that of the post-live proportion.

When a break in the reception of the data is identified then the datalogger will adjust the Bandwidth time function (Bd-tf) to allow part of the available bandwidth to be proportioned to received the post-live data (Bd-pI) when communications are re-established or adjust the available bandwidth (Bd) accordingly.

Upload of data The data logger can advantageously also control and allocate dynamically sufficient processing and transmission resources to handle the various protocols, bearing in mind that the transmission protocols to pass the data upstream utiising Bandwidth (Bu) to a server may well interrupt the transmission of the data from the sensory devices into the datalogger and vice versa thus reducing bandwidth both upstream (Bu) and downstream (Bd).

As such there will be a trade off between processing the received data from the sensory devices, and sending the received data upstream. The datalogger can advantageously maintain the optimum balance of receive and forwarded processing power, this optimum balance being known as the Marshalling function (M) The datalogger adopts a strategy that is programmed into its firmware for uploading the logged data to the server infrastructure. That strategy preferably favours methods of communication that use less power, for example communication over a wireless LAN connection rather than over a mobile phone connection. The interval between transmissions may depend on the availability of a low-power connection.

However, the interval is preferably also capable of being altered in two ways under command from the server infrastructure.

The server infrastructure can instruct the datalogger to transmit data more promptly (preferably immediately if bandwidth Bu/Bd permit and this does not effect the criticality of the other sensory devices) when the datalogger detects that the sensory device data meets a certain value-based threshold. In such a manner the datalogger can be programmed to monitor and react to the physiological changes of the sensory device network attached to the subject.

This allows the datalogger to alert a system administrator of the server infrastructure (e.g. a medical professional) immediately if the subject of the datalogger meets a certain physiological condition. That condition could, for example, be that the subject's blood pressure is greater than a set value or that the subject's pulse rate is below a set value.

Alternately, an administrator of the server infrastructure can instruct the datalogger to transmit data more or less frequently irrespective of the content of the sensed data if the datalogger's subject is to be monitored more or less intensively. The intensity of monitoring may depend on clinical decisions made by the user of the server, or this process may be automated through reporting server 98.

The server transmits to the datalogger acknowledgements for data that it receives.

When the datalogger has successfully uploaded data to the server infrastructure it deletes that data from its memory. In the same manner as the Bandwidth Timeliness Function (Bd-tf) operates for the bandwidth between the sensory devices and the datalogger, a similar Bandwidth Timeliness Function (Bu-tf) operates for the upstream bandwidth. It is envisaged that this scenario would allow for interruptions to the datalogger's available uplink bandwidth. The Bandwidth Bu can be sub-divided into bandwidth for near-live data (Bu-ni) and bandwidth for post-live data (Bu-pl), with the sub-division being dynamically controlled by server. For instances where the processing power is limited on the datalogger, and so as not to overload the datalogger's processor, a further scalable downhink bandwidth is defined for communications from the server back downstream to the datalogger. This bandwidth is defined as (Bu-dl) and is defined to allow the server to control the processor's upstream sending function, such that new firmware, software, memory images, or instructions may be sent to the device in the timeliest manner.

In such a manner the datalogger can control the availability of both the live and post-live data. It is presumed that until there is a break in the reception of the time series data from the datalogger such that the near-live proportion of the Bandwidth timeliness function will far exceed that of the post-live proportion. When a break in the reception of the data is identified then the datalogger will adjust the Bandwidth time function (Bu-tf) to allow part of the available bandwidth to be proportioned to received the post-live data (Bu-pI) when communications are re-established or adjust the available bandwidth (Bu) accordingly.

If the datalogger detects that the sensory devices data is out of pre-defined limits, the processor acting within the datalogger can dynamically increase or decrease the criticality level (CO of the sensory device accordingly, whilst simultaneously increasing or decreasing both the time sampling rate (Ts) or buffering (Tb) accordingly. This would be done such that the datalogger might have enough autonomy to adapt to human physiological condition changes as detected by the attached sensory devices.

In a similar manner, the datalogger has the ability to adapt the Bandwidth timeliness functions Bu-tf and Bd-ff upon analysis such that the emphasis should be placed on live data coming through at any cost. This scenario can account for a specific physiological action or reaction being caught by the datalogger, and the system's pre-determined action is to enable as much live data to be sent, with post-live data being discarded. The latest live data coming through being more important than the bandwidth being throttled by post-live data trying to fill in the gaps.

Likewise if the server detects that the sensory devices' data is out of pie-defined limits, the server can dynamically increase or decrease the criticality level (CO of the sensory device accordingly by relaying this to the datalogger, whilst simultaneously increasing or decreasing both the time sampling rate (Ts) or buffering (Tb) accordingly. This would be done such that the server might have enough autonomy to adapt to human physiological condition changes as detected by the attached sensory devices.

Once again, the server has the ability to adapt the Bandwidth timeliness functions Bu-tf and Bd-ff in dependence upon analysis such that the emphasis should be placed on live data coming through at any cost. This scenario can account for a specific physiological action or reaction being caught by the server, and the system's pie-determined action is to enable as much live data to be sent, with post-live data being discarded. The latest live data coming through being more important than the bandwidth being throttled by post-live data trying to fill in the gaps Analysis or review of data The server infrastructure holds the logged data for each subject whose data has been collated via a datalogger. Data stored at the server infrastructure can then be accessed by third parties. The third parties are then able to analyse each subject's data. Consequently, the third parties can advise each subject on the correct course of action. The data remaining on the server for aggregated research purposes.

The reporting server 98 is pre-programmed with analysis routines which it runs on the data from selected subjects that are stored within database 97. The analysis routines may be designed to detect features of the subjects' data, and on the detection of such features, raise certain flags. As an example, the analysis routines may analyse some or all of the subjects' ECG data to detect features indicative of problematic cardiac function. If such a feature is detected in a subject's data then an alert may be triggered automatically. The alert may be made in a number of ways. It could be sent as a message to a person who is designated as working with that subject. Alternately a message could be passed to the subjects' datalogger in a manner that might trigger the datalogger to display a massage to the user.

Alternatively it could be sent to the datalogger or other communication terminal (e.g. a mobile phone) of another individual who is designated as working with the subject.

Alerts to network connected staff can be made through the interfaces 100 or 101.

Alerts to the subject or to another individual may be made through the networks 91 or 93.

When aggregated data is processed, each subject's data is treated as anonymous within the system. The system merely needs to know a subject reference number to attach the data coming from the datalogger into the system. In such a manner the system is able to perform automated comparative analysis between a subject and the whole system, based on parameters identified as interesting by a user of the system. The system may present its stored human physiological data to other such systems to provide extended search and comparison analysis, these could include searching against other systems that hold previous data acquired from a specific subject such as a patient record etc. Configuration of the Datalogqr The datalogger stores firmware 11 in non-volatile memory 4. The firmware may be made up of program code that is executable by the processor 3 and meta-code, such as configuration files or image files that store parameters, images or layout definitions that can be used by the processor during execution. The firmware of the sensor modules is composed in a similar way.

The configuration database 103 stores data indicating the configuration of each of the dataloggers in the system and their currently associated sensory devices. That includes, for example, the software version and the configuration files that are meant to be on each datalogger.

The firmware of each datalogger can be updated from the server infrastructure. This is done by the server infrastructure sending replacement firmware to the datalogger together with an instruction for the datalogger to install and use the new firmware.

The datalogger may need to reboot itself after installing the new firmware. In a similar way, the server infrastructure can also send the datalogger new firmware that it is to transmit to the sensor modules for installation on them. This mechanism of updating the firmware requires no intervention from the user of the datalogger, making it easier for the datalogger to be used by people with less technical skills.

The firmware may configure functions such as the criticality factor (Cf) of each associated sensory device, coupled with the sampling interval (Ts) of each sensory device, the starting Bandwidth Timeliness Function (Bd-tf) for the sensory device to datalogger relationship, as well as the starting Bandwidth Timeliness Function (Bu-tf) for the datalogger to server relationship. From a higher level perspective the firmware may identify the type of the sensory device as well as any unique identifier of the device such as to form a logical association with the specific sensory device and the specific datalogger. The firmware will also control the user interface of the datalogger and human inputted data gathering functions of the datalogger. In such a manner the server algorithms may decide how the sensory device data may be changed dynamically and in real time to reflect the physiological data coming into the server.

An operative of the system may decide that the user needs to be issued with a new type of sensor module. The sensor module can be sent to the user, and meanwhile firmware code that allows the datalogger to communicate with and make use of the data from such a sensor module can be downloaded to the datalogger. The datalogger might be locked so that it will only communicate with sensory devices having a certain identity, a certain type, or a certain unique identifier, such as a MAC address. In such a scenario the identity of the new sensor module is also downloaded to the datalogger. If the datalogger is reported as being lost, then the server infrastructure could send a signal of a predetermined format in response to which the datalogger will erase all sensory devices association with that datalogger.

The datalogger has a display that can provide information to the user. The display may be configured by firmware. If the display is touch-sensitive then one significant aspect of the configurability of the display is that the size and layout of elements of the user interface presented by the display can be customised for particular users.

In the case of a touch-sensitive display the buttons are represented by displayed areas of a distinctive appearance. The processor is configured to respond to pressure on the display anywhere in one of those areas to perform a function related to the information displayed in that area. The user interface can be reconfigured through firmware to alter the size of the regions that are responsive to pressure in that way, and the corresponding displayed zones, effectively changing the size of the buttons on the touch screen. The user interface could be customisable in other ways. For example, the language of any text on the display could be configured by firmware.

The datalogger could display alerts that are received from the server infrastructure.

In response to receiving the message the datalogger automatically displays the alert contained in the message. That alert could, for example, be a reminder to take certain medication or to make a certain measurement. The alert could be a reminder to a third party in a similar manner to ensure the subject has undertaken said action.

The server may be configurable to send such alerts automatically.

Charging Figure 3 illustrates charging of the batteries of the datalogger and the sensors. For simplicity figure 3 shows the datalogger 1 and sensors 30 and 40, but there could be additional sensors. In operation, the datalogger is powered by its battery 10 and the sensors 30 and 40 are powered by their batteries 31, 41. The datalogger and the sensors include coils 12, 32, 42 in which an EMF can be induced by a coil 120 in an inductive charging mat 121. The coil 120 could be powered by mains electricity.

The general operation of the contactless charging system may, for example, be as described in EP 1 868 275 A. Thus, when the devices are places on, or are otherwise in range of, the mat their batteries can be charged by means of the EMF induced in the coils 12, 32, 42 by the coil 120. Other contactless charging mechanisms could be used.

As indicated above, each sensor may be designated with a respective criticality or priority value that indicates its importance for the current operation of the system.

The criticality values could be set by the user entering them into the datalogger by means of its user interface. More preferably they could be uploaded to the datalogger from the server over a network such as the internet and/or a mobile phone network or another network of the types discussed above by means of which the datalogger can communicate with the server. In the latter case, the criticality values could be set by a healthcare worker who has analysed the user's state of health, or by an automated routine that has analysed data received by the server from the user's datalogger. The criticality values are stored at the datalogger, although they could alternatively or additionally be stored on the respective sensor.

Broadly, the criticality value for any sensor or other device reflects the importance of gathering data by means of that sensor, or having that device available for use. For example, if the sensors include an ECG sensor and a blood pressure sensor then those devices' criticality values could be I and 2 respectively if the user is a patient with a heart problem, or 2 and 1 respectively if the user is a patient with high blood pressure; where a lower value indicates greater importance.

Each device includes a processor 3, 33, 43 and a switching device 14, 34, 44 which is controlled by the processor. When the switch is opened it isolates the respective coil 12, 32, 42 from the respective battery 10, 41, 41. In this state the coil will not draw significant energy from the field generated by the coil 120 of the mat 121.

When the switch is closed it connects the respective coil across the battery so that it can be used to charge the battery.

As described above, each of the sensors includes a wireless module (35, 45 in figure 3) which can communicate with one of the wireless modules 6-9 of the datalogger.

The criticality values are used to control the charging of the devices' batteries, as will now be described. The datalogger senses that charging is in progress either because it senses that it its own battery is being charged, or more preferably because each sensor signals the datalogger to indicate that that respective sensor is being charged. For that purpose, the processors of the sensors may be configured to detect that charging is in progress and signal the datalogger accordingly by means of their wireless modules. When the datalogger knows that charging is in progress it activates a routine that causes the sensors to be charged in accordance with their current criticality values. The algorithm that the datalogger uses for this may be determined by various operational constraints, but broadly it is preferable for the datalogger to cause sensors that have greater criticality to be charged preferentially.

The algorithm may also take account of other factors such as the level of charge remaining in each of the sensors, which could be signalled to the datalogger by the sensors. Devices could be charged preferentially in dependence upon them having a relatively high criticality and/or a relatively low level of charge.

In one embodiment the datalogger stores a table which indicates one or more criticality values for each of the devices that are connected to it. The table may, for example, store a list of identities for each of those devices, and in conjunction with each of those identities may indicate a criticality as a numeric value. The criticality reflects the importance of collecting data from the respective device. That importance may be influenced by (a) the medical significance of any data gathered by the device in question and/or (b) an expected power consumption of he device and/or (C) the preferred sampling rate of the device in question (which could, for example, vary from many times per second to once per day). The sampling rate is significant because devices with a higher sampling rate might be expected to have a higher power consumption. In such a manner the datalogger may be able to distinguish between a sensory device that requires an essentially continuous stream of measurements to be taken, and a sensory device that requires a point reading to be taken, say, every five minutes. As the power requirements for most sensory devices depend on the frequency of sampling, this is of paramount importance.

A criticality look up table, held by the datalogger, therefore might list the sensory devices by their overall criticality, i.e. a cardiac reading is more important than a weight scale reading, when both devices are to be read on a once per hour scheme.

The look up table held by the data logger may also detail the criticality of the sensory device in terms of the frequency with which the device must be read, either in point reading or continuous reading form. The data in the criticality table could be arranged in various ways, but preferably it indicates for a variety of states of energy storage the devices that should take sensor readings and the frequency of those readings. In one example, the criticality table could be as follows, where the criticality values indicate sensing frequencies for each device for each of a range of charge states: Charge state Sp02 Heart sensor High 1 Hz 1000 Hz Medium 0.01 Hz 1000 Hz Low Device off 250 Hz Criticality 2 1 The table could be populated differently if different sensors have different priorities, in accordance with the clinical needs of the user.

If the sensory devices that are to be connected to the data logger are wireless then the criticality look up table can be dynamic such that devices may appear and disappear from the table according to the current state of the wireless sensory device network. Alternatively, the table may store data for all devices, irrespective of whether they are currently connected, and the datalogger can optimise charging or data collection by sharing resources -whether bandwidth or charging energy -between the devices that are currently connected in dependence on their criticalities as indicated by the table. If the table is altered as devices attach or detach from the datalogger then the datalogger can similarly optimise energy usage among those that are actually present. Thus, as a device attaches or detaches (whether via a wired or a wireless connection) to or from the datalogger, the data logger may assess the importance and preferred frequency of gathering data from the now-connected devices and may update the table accordingly. Alternatively, the datalogger could transmit the list of connected devices to a remote server, where criticality information could be assigned using information about the medical priorities for the user of the datalogger and then sent back to the datalogger to update the table. Thus the datalogger can make use of a dynamic charging strategy that allows for all devices in all circumstances.

The table may include a criticality value for the datalogger itself, since the datalogger may be powered form a local energy source such as a battery. Since the datalogger is central to the data gathering system it would be expected to have a high criticality status and thus be favoured for receiving charging energy.

As described above, the dynamic charging strategy for any device is determined in dependence on the criticality factor assigned to the device. The criticality factor may be expressed as a single value (e.g. an integer value) for each device. That value may be derived from a formula that takes into consideration one or more of the following factors: 1. Master/slave device: details whether the sensory device is a datalogger or an attached device.

2. Point reading or essentially continuous reading device 3. Frequency of reading required 4. Medical Criteria -e.g. how important data from the device is to the treatment or monitoring of the user in question In a simple example the criticality factor (CF) may be calculated by summing values representing each of the above four factors. Such a score represents the aggregate of the attributes gives the datalogger the ability to prioritise which sensory and data logging devices are more critical than which other sensory and data logging devices, such that a charging strategy may be developed and applied by the datalogger.

The datalogger, or any other device that is controlling the charging process, may detect that there is insufficient charging capability to meet the devices' requirements.

Two devices may have a high charging criticality value and the datalogger may be aware that the charging energy available is insufficient to allow them both to continue to operate as required. For example, the datalogger may be aware that two of the sensors are required to operate to take data samples in two hours' time, but that the charging device 121 will be incapable of delivering sufficient energy to allow them both to do so by then. The datalogger may determine the available charging energy or rate from the rate of increase in the sensor devices' charge level as they are charged, or by signalling from the charging device. In response to this determination the controlling device may signal the user to prompt the user to charge one of the devices by another method. To prompt the user, a display light, e.g. an LED, could be flashed on the device that is to be charged separately. The other charging method could, for example, be by attaching the device to a wired mains-powered charger, or by placing it on another inductive charging device. Thus, the datalogger may store information indicating the anticipated energy consumption of any of the devices over time. When that device is in a location where it can be charged, the datalogger can determine whether the device is receiving sufficient energy to meet the anticipated usage requirements of the device. If it is not, perhaps because charging of that device has been disabled in favour of another device, then the datalogger can signal the user to intervene to charge that device. To achieve this, it could, for example, display a message on a display of the datalogger.

The criticality table and/or lists of connected devices stored by the datalogger can be exported to another datalogger. This may be useful if the first datalogger is damaged, or its battery is run down, so that the user can switch to using another datalogger under the same logging and charging criteria. To allow a smooth handover from one datalogger to its replacement the datalogger preferably supports exporting and importing of stored values such as the criticality table and lists of paired devices. If the first datalogger detects that it is close to running out of energy then it could attempt to wirelessly detect another nearby datalogger, and if it does detect one it could pass off monitoring to that other datalogger as indicated above.

The transfer of these values may take place wirelessly over a direct channel from the old datalogger to the new. Alternatively, the old datalogger could upload the values to the server, and the new datalogger could download them from the server.

When the datalogger identifies that devices (potentially including itself) are configured such that they can be charged -for example by being placed on an inductive charging mat -the datalogger controls which devices accept charging.

The datalogger thus identifies that one device (e.g. device 30) is to be charged in preference to another (e.g. device 40). Having done that the datalogger signals one or both of the devices accordingly. Preferably the devices accept charge by default, when it is available, so the datalogger signals the less preferred device with a message indicating that it should disable charging of its battery. The processor of that device (e.g. device 40) opens its switching device (e.g. 44) to isolate its battery from the respective coil, whilst the other device is charge by the coil 120. In this state the energy available from coil 120 is substantially undepleted by the coil (e.g. 42) of the device for which charging is disabled. Hence, the preferred device (e.g. 30) can be charged more quickly.

Whilst charging continues the datalogger continues to run the routine that controls which of the sensors can be charged. Once the energy stored in one sensor is increased, the algorithm may cause the datalogger to reassign which devices are being charged, again in accordance with data including the respective sensors' criticality values.

The datalogger may also control whether its own coil absorbs energy from the charging field, in order to favour charging of one or more of the sensors.

This charging arrangement has a number of advantages. Compared to a plug-in charging system it is easier for the user to charge multiple devices, since they only need to be placed in proximity to the mat in order for charging to take place.

Nevertheless, compared to a conventional inductive charging system the presence of multiple devices in the charging zone does not significantly impact the effectiveness of the datalogging system because charging energy is concentrated on the devices that most require it, for example because of their high criticality and/or because their level of stored energy is low. For example, device 30, which measures Sp02, might have greater importance for the user's health than device 40, which measures blood pressure. In that case, device 30 will have a higher criticality or priority. Since device 30 will be charged preferentially to device 40, device 30 can be maintained in operation even if only a brief time period is available for charging, since device 40 will not adversely affect the charging of device 30. The user does not need to manage this: for example by keeping device 40 away from the inductive charger whilst device 30 is charging. To the user the charging process simply involves putting all the devices in proximity with the charger. The devices then collectively implement a suitable charging scheme.

The mechanism described above may be used with sets of devices other than datalogging systems. One example is an intelligent desktop space, where collaborative people may drop mobile phones, PDAs etc. The desktop space would charge devices preferentially depending on their importance. The desktop space could be a surface unit, where collaborative data exchange takes place. Another example is a workshop area where a number of rechargeable tools are to be used.

The charging apparatus could prioritise charging of (for instance) a cordless drill over a cordless saw.

Instead of a battery the devices could use another energy storage device such as a capacitor.

The control of the devices' charging need not be in the datalogger. The devices could mutually cooperate to decide on a charging strategy. To achieve this they could at the start of charging and periodically thereafter communicate their criticalities and/or their battery states to each other. Using that information each device could establish locally whether it has sufficient priority to start charging, and control its switching device accordingly. Alternatively, a processor associated with the mat could determine the charging priority. The mat could signal to the devices which of them is to start or stop charging by modulating data on the field emitted by the coil 120.

Where the datalogger or other controlling device is capable of communicating wirelessly using a number of protocols with a destination then it could select which of those protocols to use in dependence on its current state of charge. For example, it may be capable of uploading data to a server by a WiFi link to a wired internet connection or by a cellular radio link. If its stored energy is below a pre-stored threshold then it could restrict itself to using the WiFi link, since that would be expected to use less power. If the WiFi link is incapable of communicating with the server then it could switch to using the cellular radio link, or could only do so if it has important data to transmit or if it has failed to establish a link with the server by means of the WiFi link for a pre-stored period of time.

Each device may have a unique identifier whereby it can be identified for control purposes and for identifying signals that it has transmitted.

Instead of a mat, the charger 121 could take other forms.

The applicant hereby discloses in isolation each individual feature described herein and any combination of two or more such features, to the extent that such features or combinations are capable of being carried out based on the present specification as a whole in the light of the common general knowledge of a person skilled in the art, irrespective of whether such features or combinations of features solve any problems disclosed herein, and without limitation to the scope of the claims. The applicant indicates that aspects of the present invention may consist of any such individual feature or combination of features. In view of the foregoing description it will be evident to a person skilled in the art that various modifications may be made within the scope of the invention.

Claims (15)

1. CLAIMS1. A charging system comprising:a charger capable of generating a field;two or more discrete devices, each discrete device comprising a rechargeable energy store capable of powering the operation of the device, a pickup for harnessing energy from the field generated by the charger, a switching device having a first state in which it couples the pickup to the energy store whereby the energy store can be charged from the pickup and a second state in which it isolates the pickup; a data store storing an operating priority for each of the discrete devices; and a controller having access to the data store and configured to control the switching device of one or more of the discrete devices in dependence on the operating priority for that device.
2. 2. A charging system as claimed in claim 1, wherein the charger is an inductive charger and each pickup is an inductive pickup.
3. 3. A charging system as claimed in claim 1 or 2, wherein the controller is comprised in one of the devices.
4. 4. A charging system as claimed in any preceding claim, wherein the controller is configured to control the switching device of each of the discrete devices in dependence on the operating priority for that device.
5. 5. A charging system as claimed in any of claims I to 3, wherein each discrete device comprises a respective controller that is configured to control the switching device of the respective discrete device in dependence on the operating priority for that device.
6. 6. A charging system as claimed in any preceding claim, wherein the controller is comprised in the charger.
7. 7. A charging system as claimed in any preceding claim, wherein the or each controller is configured to control the switching device of one or more of the discrete devices in dependence on the operating priorities for that device and the other discrete devices.
8. 8. A charging system as claimed in any preceding claim, wherein the or each controller is configured to control the switching device of one or more of the discrete devices in dependence on the operating priority for that device and on the level of the energy store of that device.
9. 9. A charging system as claimed in any preceding claim, wherein the or each controller is configured to control the switching device of one or more of the discrete devices in dependence on the operating priority for that device and on the levels of the energy store of that device and the other discrete devices.
10. 10. A charging system as claimed in any preceding claim, wherein the controller has access to information indicating the energy requirement of at least one of the devices over time, is configured to estimate whether the charger will deliver sufficient energy to that device to meet that energy requirement over time, and in response to that determination being negative, to signal the user to intervene to charge that device.
11. 11. A charging system as claimed in any preceding claim, wherein the data store is held in the controller.
12. 12. A charging system as claimed in claim 11, wherein the controller is capable of exporting data from and/or importing data to the data store.
13. 13. A charging system as claimed in any preceding claim, wherein the controller is capable of exporting the operating priorities to a similar controller.
14. 14. A charging system as claimed in claim 13, wherein the controller is capable of automatically exporting the operating priorities to the similar controller if the controller detects that its stored energy is below a pre-stored threshold.
15. 15. A charging system as claimed in claim 13 or 14, wherein on exporting the operating priorities the controller is capable of handing over the devices from interaction with itself to interaction with the similar controller.