WO2012004597A2

WO2012004597A2 - Data processing apparatus and system

Info

Publication number: WO2012004597A2
Application number: PCT/GB2011/051269
Authority: WO
Inventors: Charles Graham Palmer
Original assignee: Charles Graham Palmer
Priority date: 2010-07-09
Filing date: 2011-07-06
Publication date: 2012-01-12
Also published as: WO2012004597A3

Abstract

A utility consumption data processing apparatus comprising a data store, a data processor and a first interface, wherein the apparatus is configured to receive utility consumption data, a plurality of different programs are stored in the data store, each of the plurality of different programs being configured to cause the data processor to process the utility consumption data to generate a different output derived from the utility consumption data, whereby at least part of the utility consumption data is not derivable from each of the different outputs, and the first interface is configured to send each of the different outputs to a respective different remote computer.

Description

Data Processing Apparatus and System

Field of the Invention

This invention relates to methods, systems, apparatus and computer code for processing of utility consumption data. Background

Utility meters that are capable of both measuring utility consumption and transmitting utility consumption data for utility consumption monitoring and / or billing purposes are finding increasing use, including in domestic and commercial settings.

These "smart" meters may measure utility consumption at regular intervals, for example at frequencies of once every hour, once every 30 minutes or even at higher frequencies.

The frequency at which utility consumption data is measured by a smart meter can enable utility providers, service providers and other organisations with access to this data to develop detailed information associated with utility consumption at the location receiving the utility.

However, the high frequency at which utility consumption is gathered may mean that the smart meter must also frequently transmit utility consumption data, and the size of data transmitted each time may be large.

Moreover, utility consumption data may contain private information. There is a risk in centralised, remote storage of this data of the security of this private information being compromised, and in some jurisdictions the transmission and / or centralised storage of such data may be illegal or subject to onerous conditions under data protection laws.

WO 2010/026477 discloses secure transmission of utility consumption data between a utility meter and remote servers.

Summary of the Invention

In a first aspect the invention provides utility consumption data processing apparatus comprising a data store, a data processor and a first interface, wherein:

the apparatus is configured to receive consumption data of a utility; a plurality of different programs are stored in the data store, each of the plurality of different programs being configured to cause the data processor to process the utility consumption data to generate a different output derived from the utility consumption data, whereby at least part of the utility consumption data is not derivable from each of the different outputs; and

the first interface is configured to send each of the different outputs to a respective different remote computer.

Optionally, each of the plurality of different programs is configured to cause the data processor to secure the respective different outputs derived from the utility consumption data; and

the first interface is configured to securely send each of the different outputs to a respective different remote computer.

Optionally, each of the plurality of different programs is configured to cause the data processor to secure the utility consumption data.

Optionally, each of the plurality of different programs is configured to cause the data processor to secure the respective different outputs derived from the utility consumption data from the other ones of the plurality of different programs.

Optionally, the first interface is configured to securely send each of the different outputs to a respective different remote computer, whereby each of the different outputs is secured against access by other ones of said different computers.

Optionally, each of the plurality of different programs is configured to cause the data processor to use one or more cryptographic keys of said different program to

cryptographically secure the respective different output. Optionally, the received utility data is secured and each of the plurality of different programs is configured to allow the data processor to access a part of the received utility data required to produce the different output of said program. Optionally, the apparatus is comprised within a utility meter and the utility consumption data is generated by the utility meter.

Optionally, the apparatus is configured to receive consumption data of a utility from a utility meter that is physically separate from the apparatus.

Optionally, the apparatus further comprising a second interface, wherein:

the second interface is configured to receive utility consumption data.

Optionally, the second interface is configured to securely receive utility consumption data.

Optionally, one of said different remote computers is a computer of a utility provider providing the utility to which the received utility consumption data relates. Optionally, the apparatus is configured to receive further data;

at least one further program is stored in the data store, each further program being configured to cause the data processor to process different further data to generate a different further output; and

the first interface is configured to send the or each different further output to a respective different further remote computer.

Optionally, each of the further programs is configured to cause the data processor to secure the respective different further output; and

the first interface is configured to securely send each of the different further outputs to a respective different remote computer. Optionally, each of the different programs and further programs is configured to cause the data processor to secure their respective different output or different further output from the other ones of the plurality of different programs and further programs. Optionally, the first interface is configured to securely send each of the different outputs and different further outputs to a respective different remote computer, whereby each of the different outputs and different further outputs is secured against access by other ones of said different computers. Optionally, each of the plurality of different programs and further programs is configured to cause the data processor to use one or more cryptographic keys of said different program or further program to cryptographically secure the respective different output or different further output. Optionally, said further data comprises further utility consumption data.

Optionally, said further data comprises gas consumption data.

Optionally, said further data comprises telecare data.

Optionally, the utility consumption data is electricity consumption data.

Optionally, one of the different programs is configured to cause the data processor to process the utility consumption data to generate utility consumption billing data.

Optionally, one or more of the different programs are configured to cause the data processor to process the utility consumption data to generate one or more of settlement data; line quality data from electricity consumption data; auditing data; inference of utility-consuming appliances in the household; and data relating to utility consumption patterns. Optionally, at least one of the outputs is sent to a remote computer which is a server.

Optionally, the apparatus is configured to store the utility consumption data in the data store or in another memory.

In a second aspect the invention provides computer program code which when run on a computer causes the computer to act as apparatus according to the first aspect.

In a third aspect the invention provides computer readable code which when run on a computer causes the computer to act as apparatus according to the first aspect.

In a fourth aspect the invention provides computer program product comprising computer readable code according to the third aspect. In a fifth aspect the invention provides an article of manufacture comprising:

a machine-readable storage medium; and

executable program instructions embodied in the machine readable storage medium that when executed by a programmable system causes the system to act as an apparatus according to the first aspect.

In a sixth aspect the invention provides a method of evaluating utility consumption of a plurality of locations wherein each location receives a discrete utility supply, the method comprising the steps of: for each of the plurality of locations, generating a profile of utility consumption over a period of time from measurements of utility consumption at a plurality of intervals of the period; generating a specific average profile of utility consumption from the plurality of profiles of utility consumption over time; and determining a difference between the specific average profile of utility consumption and a general average profile of utility consumption over time.

Optionally according to the sixth aspect, the period of time is a day.

Optionally according to the sixth aspect, the profile of utility consumption for a location is an average of a plurality of profiles of utility consumption for a corresponding plurality of time periods.

Optionally according to the sixth aspect, the method comprises the further step of generating a value representative of the difference between the specific average profile and the general average profile.

Optionally according to the sixth aspect, the method comprises the further step of determining a difference in cost of utility consumed between the specific average profile and the general average profile.

Optionally according to the sixth aspect, the price of electricity per interval is not a constant.

Optionally according to the sixth aspect, the difference between the specific average profile and the general average profile is determined at a location that is local to a utility meter generating the measurements of utility consumption at the plurality of time intervals.

Optionally according to the sixth aspect, the difference between the specific average profile and the general average profile, or a value derived therefrom, is transmitted to a remote computer.

In a seventh aspect the invention provides computer program code which when run on a computer causes the computer to perform the method according to the sixth aspect.

In an eighth aspect the invention provides computer program product comprising computer readable code according to the seventh aspect. In a ninth aspect the invention provides a article of manufacture comprising:

a machine-readable storage medium; and

executable program instructions embodied in the machine readable storage medium that when executed by a programmable system causes the system to perform the method according to the sixth aspect.

In a tenth aspect the invention provides a method of installing a device related program into a data processing apparatus comprising a data store, a data processor and a first interface, comprising the steps of:

transferring an encrypted and signed copy of the program from the related device to the data store of the data processing apparatus through the first interface;

validating the stored copy of the program using the data processor; and enabling the stored copy of the program using the data processor. Optionally according to the tenth aspect the first interface is connected to a local network and the device is configured to automatically transfer the encrypted and signed copy of the program from the device to the data store of the data processing apparatus through the first interface using the local network. Optionally according to the tenth aspect the device is configured to automatically begin the transfer when the device detects the local network.

Optionally according to the tenth aspect the data processor validates the stored copy of the program using data transferred to the data processing apparatus from the device.

Optionally according to the tenth aspect the data processor validates the stored copy of the program using data exchanged between the data processing apparatus and a remote computer. Optionally according to the tenth aspect the apparatus further comprises a second interface; the program being configured to cause the data processor to establish a secure communications channel between the device and the remote computer, the secure communications channel passing through the data processing apparatus. Optionally according to the tenth aspect the data processor validates the stored copy of the program using data exchanged between the data processing apparatus and a remote computer through the second interface.

In an eleventh aspect the invention provides computer program code which when run on a computer causes the computer to perform the method according to the tenth aspect.

In a twelfth aspect the invention provides carrier medium carrying computer readable code which when run on a computer causes the computer to perform the method according to the tenth aspect.

In a thirteenth aspect the invention provides a computer program product comprising computer readable code according to the twelfth aspect.

In a fourteenth aspect the invention provides a computer-implemented apparatus comprising:

a data store;

a data processor; and

a first interface;

wherein the apparatus is configured to:

transfer an encrypted and signed copy of the program from a device to the data store of the data processing apparatus through the first interface;

validate the stored copy of the program using the data processor; and

enable the stored copy of the program using the data processor. In a fifteenth aspect the invention provides an article of manufacture comprising:

a machine-readable storage medium; and executable program instructions embodied in the machine readable storage medium that when executed by a programmable system causes the system to perform the method according to the tenth aspect. Description of the Drawings

The invention will now be described in more detail with reference to the drawings, in which:

Figure 1 illustrates a house receiving an electricity supply having an associated electricity meter, and a plurality of devices within the house capable of communicating with the electricity meter;

Figure 2 illustrates a network environment including a plurality of houses;

Figure 3 is a block diagram of a meter shown in Figures 1 and 2 according to an embodiment of the invention;

Figure 4 is a block diagram of a secure microcontroller shown in Figure 3 according to an embodiment of the invention;

Figure 5 illustrates the contents of the memory shown in Figure 4 according to an embodiment of the invention;

Figure 6 details applets shown in Figure 5 according to an embodiment of the invention;

Figure 7 details an applet shown in Figure 6 according to an embodiment of the invention;

Figure 8 details a security domain applet shown in Figure 6 according to an embodiment of the invention;

Figure 9 details operational steps for the meter shown in Figure 3 according to an embodiment of the invention; Figure 10 illustrates processing of electricity consumption data by a plurality of applets as shown in Figure 6, and transmission of processed data;

Figure 11 is an alternative embodiment of a smart meter embodying the invention;

Figure 12 is a further alternative embodiment of a smart meter embodying the invention; Figure 13 illustrates a mesh network comprising the smart meters shown in Figures 3, 12 and 13;

Figure 14 is a further embodiment of a communications device embodying the invention;

Figure 15 illustrates a block diagram of a telecommunications hub architecture according to a further embodiment of the invention; Figure 16 illustrates a block diagram of a smart meter;

Figure 17 illustrates a block diagram of a secure smart meter according to a further embodiment of the invention;

Figure 18 illustrates a block diagram of a telecoms hub;

Figure 19 illustrates a block diagram of java card applets providing secure communications channels according to a further embodiment of the invention;

Figure 20 illustrates a block diagram of applets processing energy locally for different entities according to a further embodiment of the invention;

Figure 21 illustrates a block diagram of smart card communication;

Figure 22 illustrates a block diagram of a virtual terminal according to a further embodiment of the invention;

Figure 23 illustrates a telecommunications hub according to a further embodiment of the invention; and Figure 24 illustrates an alternative telecommunications hub according to a further embodiment of the invention.

Detailed Description of the Invention

With reference to Figure 1, a house 101 comprises several devices that communicate with meter 102. Electricity is provided to home 101 via mains electricity supply line 103, and premises electricity wiring 104 provides power to devices in the house.

Although Figure 1 illustrates a house, it will be appreciated that the invention applies to any location connected to receive a discrete supply of one or more utility, including indoor and outdoor locations and domestic and commercial locations. Meter 102 monitors the consumption of electricity received from supply line 103 at regular intervals, for example every day, every hour, every 30 minutes, every minute or more than once per minute. The frequency at which measurements are made may depend on the information that is to be derived from utility consumption data, as described in more detail below. Meter 102 may include a wireless communications interface for the purpose of communicating with other devices in the home.

A portable wireless user interface 105 displays electricity usage to the user, and is in this example attached magnetically to a refrigerator 106. Other devices in the home also communicate with meter 102. Gas meter 107 monitors gas usage, panic button 109 is used to raise an alarm if necessary, and solar array 110 and power inverter 111 may provide additional power to the house that can be exported to the national grid. Scales 108 are used to measure the weight of a user, and other data relating to the physical condition of a user, such as blood pressure, may also be transmitted to meter 102.

Each of these devices communicates wirelessly with meter 102, for example using a home area network such as a ZigBee mesh network, although one or more of the devices may communicate through wired means, such as through wiring 104. Figure 2 illustrates transmission of data from meters 102, 102a and 102b associated with respective houses 101, 101a and 101b to remote servers 201, 202, 203, 204 via the internet 205.

Each house 101, 101a and 101b is supplied with electricity through respective supply lines 103, 103a and 103b, each of which are typically are connected to national grid 206 through a substation (not shown).

Meter 102 measures electricity consumption and also receives healthcare data from scales 108 and gas consumption data from gas meter 107.

The invention also applies to locations at which a meter measures consumption of one utility only without receiving data from other devices and / or meters. This is illustrated in Figure 2 where meters 102a and 102b of respective houses 101a and 101b measure electricity consumed from respective supply lines 103a and 103b.

Data stored in meters 102, 102a and 102b is transmitted to remote servers 201, 202, 203 and 204. Server 201 is a server of an electricity retailer that may receive, for example, information on electricity consumed within a billing period. Server 202 is a server of a utility management agent that may provide the utility consumer with advice on reducing utility consumption and utility cost based on analysis of the consumer's utility consumption habits. Server 203 is a server of a gas supplier that may receive, for example, information on gas consumed within a billing period. Server 204 is a server of a healthcare provider that may receive healthcare data. Server 207 is a infrastructure management authority server to manage applets, as described in more detail below.

It will be appreciated that the meters may be in communication with any number of servers, and the companies associated with each of those servers listed above is not exhaustive. Data may be transmitted from each house via a suitable network, for example the internet 205 to each relevant server. Connection to the Internet may be made using any of the means known to the skilled person, such as GPRS, WiMax radio, Ethernet, a telephone modem, or ASDL broadband, or any other suitable method could be used. An electricity substation may contain a concentrator which receives signals from the homes sent down the power supply lines or wirelessly using a wireless mesh network and forwards these signals in a suitable format to Internet 205.

Alternatives to the Internet 205 include a mobile telephone network, a Virtual Private Network, or another network suitable for communication between the meters and the servers.

In operation, meter 102 receives information from various devices associated with house 101 in addition to measuring utility consumption (which is electricity consumption in this case). However, as described in more detail below with reference to Figure 10, the meter 102 may be configured to transmit only some of the data measured or received, and / or to process the measured data to generate processed data suitable for transmission, in order to protect the privacy of that data and / or reduce the volume of data transmitted.

Thus a single device within the home which must of necessity be installed, such as an electricity meter 102, or other utility meter, may be used to enable communication between many household devices and associated servers.

However, it is extremely important that each communication link between the meter and a server is separate and secure, that meter 102 cannot be tampered with by a user, and that data produced by, received by or stored by any of the household devices is not accessible by any third party, including the makers of the other household devices in the home and owners or operators of servers which are connected to the meter 102, but are not associated with the specific communicating household device.

An exemplary meter 102 is detailed in Figure 3. The meter 102 includes a

communications block 301 which may provide a telecommunications hub, a user interface 302, a metrology device 303 and a power supply unit 304. Communications block 301 comprises a Wide Area Network (WAN) interface 305, a secure

microcontroller 306 and a Local Area Network (LAN) interface 307. The LAN may be a Home Area Network (HAN). Secure microcontroller 306 is connected to each of the other elements of the meter. Metrology device 303 connects between the incoming mains electricity supply line 103 and the premises electricity wiring 104, and measures the electricity consumption within house 101. Information regarding electricity usage is displayed to a user on user interface 302. The power supply unit 304 provides a low voltage power supply for the electronics in the smart meter from the incoming power supply line 103. In this embodiment, WAN interface 305 facilitates communication to servers via power supply line 103. LAN interface 307 facilitates communication wirelessly, using a protocol such as ZigBee(R). Thus any communication between one of the local devices and one of the servers is routed through microcontroller 306. In this example the communications block 301 is implemented as a module or sub-system within the meter 102. The communications block 301 could also be implemented as a set of components soldered to a common printed circuit board together with the other components of meter 102.

In this embodiment, the communications block 301 is contained within the housing of meter 102, however it will be appreciated that the communications block may be physically separate from, but in wired or wireless communication with, the metrology device 303. The communications block 301 and the metrology device 303 may have separate housings. If the communications block is physically separate from the metrology device 303 then it may be connected to power supply unit 304 or to a separate power supply.

Although in this example meter 102 is an electricity meter, it could be a meter for any other utility, such as gas, water, heat, and so on. Further, many other embodiments of the meter are possible and examples of these will be discussed below with reference to Figures 11 and 12.

Figure 4 is a block diagram of secure microcontroller 306. This is typically implemented as shown in Figure 4, but it will be understood that there are many variations of microcontroller architectures that differ in some details from Figure 4. A processor, provided in this example by Central Processing Unit 406, connects through an internal bus 408 to RAM memory 402, which may be used to store data which typically changes frequently. The CPU 406 also connects through the internal bus 408 to ROM memory 403, which may be used to store programs and data which typically change infrequently or not at all. An external interface element 401 allows the microcontroller 306 to communicate with other external circuitry through external interface 409. Optionally one or more input-output elements 405 may exist and connect to other components through input-output interfaces 410. Secure microcontroller 306 also includes a cryptography element 404 which is capable of performing calculations necessary for cryptography.

The secure microcontroller 306 also includes a tamper detection and prevention element 407 which is designed to detect and defeat attempts to compromise the operation of the secure microcontroller 306 by determined and skilled assailants. Such assailants might seek to read or modify the program and data stored within the RAM 402 or ROM 403. For example, if assailants were able to read cryptographic keys stored within a

microcontroller they would be able to read or modify encrypted messages which the parties who were exchanging the encrypted messages had assumed were private.

Furthermore, assailants might also be able to modify data or generate false messages such that the recipient of the data or messages incorrectly believed the data or messages to be accurate.

Furthermore, assailants might then be able to manufacture counterfeit products. Attacks on conventional microcontrollers are known to include operating the microcontroller at extremes of temperature or at extremes of power supply voltage or at extremes of clock frequency. Attacks also include exposing the microcontroller to electromagnetic fields and injecting pulses onto its external interface or input-output interfaces. Further attacks include power analysis, which can allow the internal operation of the microcontroller to be determined by monitoring the differences in power consumption that can occur as the microcontroller performs different internal operations. The tamper detection and prevention element 407 present within the secure microcontroller 306 provides protection against such attacks, which might be successful when deployed against a conventional microcontroller, thus preventing assailants from reading or modifying the programs and data contained within the RAM 402 or ROM 403. Secure microcontrollers such as secure microcontroller 306 are used in credit cards and smart cards, and in mobile phone SIM cards. These are often referred to as Universal Integrated Circuit Cards (UICCs). Secure microcontrollers are also used in secure memory sticks and dongles used with personal computers and in trusted platform modules found in some computers. In one implementation secure microcontrollers are used in credit cards and smart cards and in mobile phone SIM cards, where the microcontroller silicon chip is enclosed within a plastic card and where electrical connections are made to the card by exposed metal contacts in the face of the card.

However, secure microcontrollers can also take other forms, including the contactless card format in which the silicon chip is enclosed within a plastic card and where a coil of an electrically conductive material forms one part of a transformer which allows power to be supplied to the secure microcontroller and also allows for the exchange of messages with the secure microcontroller.

In another implementation a secure microcontroller is packaged in a conventional integrated circuit package and is soldered to a printed circuit board. In yet another implementation a secure microcontroller is packaged in a conventional integrated circuit package and is soldered to a printed circuit board which makes up part of a module that plugs into a personal computer; USB memory sticks and dongles are examples of this implementation. Any implementation could be used as part of an embodiment of the invention described herein.

As explained above, implementations of secure microcontrollers are known. Accordingly, the structure and operation of the secure microcontroller does not need to be discussed in detail herein. Figure 5 illustrates the contents of the memory of secure microcontroller 306, embodied by RAM 402 and ROM 403. Programs in the memory control the exchange of messages through the WAN interface 305 with remote servers 201 to 204 and through the LAN interface 307 with local devices. In some implementations these programs merely act to route messages between a remote server and a local device. In other implementations the programs act to store, perform calculations on or otherwise process data received within messages received from the servers and/or the local devices.

Secure operating system 501 manages the hardware resources of secure microcontroller 306. Virtual machine 502 allows software written for the virtual machine to be executed on any secure microcontroller that implements the same virtual machine. A virtual machine is sometimes known as a byte code interpreter.

A number of programs, each comprising instructions and data, are also stored in the memory. In this example, these are applets 505, which are the application programs that run on secure microcontroller 306. Applets 505 can call upon standardised software functions implemented as the Application Programming Interface (API) 504. Run-time environment 503 is responsible for management of resources, communications and security of data and the exchange of data with applets 505.

Operating system 501, virtual machine 502, run-time environment 503 and API 504 are written by or on behalf of the manufacturer of secure microcontroller 306. These software elements do not change during the lifetime of the secure microcontroller 306. However, applets 505 are written by or on behalf of the manufacturer of the product which uses the secure microcontroller 306. Applets 505 define software that is specific to meter 102 and define its functionality.

The memory shown in Figure 5 also includes data 506 used by the operating system 501, virtual machine 502, run-time environment 503 and API 504.

Applets 505 are further detailed in Figure 6. Each of the local devices in house 101 is linked with one of the applets 505. Thus remote user interface 105 communicates with electricity applet 601, as does metrology device 303. The metrology device 303 can be considered as a local device housed within meter 102. Gas meter 107 communicates with gas applet 602. Scales 108 and panic button 109 communicate with telecare applet 603. Power inverter 111 communicates with energy export applet 604. All of this

communication occurs via LAN interface 307. Other applets 605 may also be present. Some applets 505 such as applets 601 to 604 may facilitate communication with a remote server, while other applets may only provide control, data storage or a user interface to a local device. For example, electricity applet 601 records continuous electricity consumption measurements from metrology device 303 and sends electricity

consumption data to electricity retailer server 201. Further, electricity applet 601 may send alarm messages when anomalies are detected. These alarms may, for example, be safety alarms if the data at the electricity applet 601 indicates that there is a problem with the house wiring or a device or appliance using the electricity supply in the house.

Further, the alarms may, for example, be fraud alarms if attempts to access or change the electricity consumption data are detected. The electricity retailer operating server 201 can also use electricity applet 601 to permit easy payment of a bill, or to cut off the electricity if a bill has not been paid. Electricity applet 601 may also send information for display to the remote user interface 105. Power inverter 111 also communicates with electricity retailer server 201, but this

communication is carried out via energy export applet 604. Gas meter 107 communicates with gas supplier server 203 via gas applet 602.

Telecare applet 603 accumulates daily weight measurements from the weighing scales 108 and sends a summary of the weight readings on a weekly schedule to telecare provider server 204. Further, if panic button 109 is depressed, an immediate alarm is sent to telecare provider server 204. Thus many of the applets 505 provide a secure communications channel between a local device and an associated server. This can be a direct channel, in as much as messages are routed directly from a device to a server or vice versa. However, this may also, or alternatively, be an indirect channel, where information or messages from a remote device are stored, changed or accumulated and a different message is then sent to a server. A communications channel can therefore be considered to be simply providing for the routing of information from one point to another point. An important aspect, however, is that messages, data, information and so on are not shared with any other applet, any other local device nor any other server, and thus the communications channel is secure.

Applets 505 may be managed remotely, even after meter 102 is installed, by an infrastructure management authority. Applets may be downloaded, installed, enabled or disabled or uninstalled by a computer program running external to the secure

microcontroller 306. The applet management process is performed by run-time environment 503 and an off-card computer program running remotely on an

infrastructure management authority server 207. By employing appropriate cryptographic protocols the applet management instructions sent by the off-card computer program can be verified by run-time environment 503, ensuring that only an authorised off-card computer program under the control of the infrastructure management authority can manage the deployment of applets 505. The applet management process also provides a secure and reliable method of updating software on secure microcontroller 306 from one version to another version.

Each of the externally communicating applets 601 to 604 is mapped to a corresponding additional applet called a security domain. Thus electricity applet 601 is mapped to security domain 606, gas applet 602 is mapped to security domain 607, telecare applet 603 is mapped to security domain 608, and energy export applet 604 is mapped to security domain 609. Other security domains 610 may also be present. Any other applets 605 which are present may be mapped to the other security domains 610. Each security domain carries out cryptographic operations for its corresponding applet. In the illustrated example each of the applets 601 to 604 is mapped to a different respective security domain applet 606 to 609. In other embodiments more than one of the externally communicating applets may be mapped to a single security domain.

The security provided by the security domain applets is explained further with reference to Figures 7 and 8. Electricity applet 601 contains instructions 701 and data 702, while the corresponding security domain 606 contains instructions 801 and data 802, which includes cryptographic keys 803. When electricity applet 601 needs to communicate securely, either with a local device or with remote server 201, the security domain 606 performs cryptographic operations using cryptographic keys 803 to ensure that the communication is secure and authenticated. Thus, the electricity applet 601 does not itself have access to the cryptographic keys used for its own communications. Further, security domain 606 will not accept instructions from any other applet than the corresponding electricity applet 601. The instructions 701 and data 702 associated with electricity applet 601 are kept secret from all other applets. This security is enforced by the other software elements, such as the secure operating system 501 and run-time environment 503.

Further, since each applet is associated with its own different cryptographic keys, none of the applets are able to decrypt messages sent by electricity applet 601, with the exception of the security domain 606 corresponding to the electricity applet 601. In fact, even the electricity applet 601 itself is not able to decrypt messages sent by electricity applet 601 since, as explained above, the electricity applet 601 does not have access to the cryptographic keys used for its own communications.

Accordingly, the electricity applet 601 and its associated off-card program running on its associated server 201 are able to establish their own logical secure communications channel with the assistance of the corresponding security domain applet 606. The other externally communicating applets 602 to 604 are similarly also able to establish their own logical secure communications channel with the assistance of their corresponding security domain applets 607 to 609.

This approach allows several applets to co-exist on the same secure microcontroller 306, and preserves security for the individual applets even in the event that the different applets are written by different software suppliers. Since secure microcontroller 306 cannot be tampered with, and since each applet cannot access any other applets' instructions, data or communication channels, all communication between local devices, applets and remote servers can be carried out securely. This means that third parties can use meter 102 to facilitate communication between their own household device and remote server without worrying about any other software that may be already installed or installed at a later date. Without this capability to maintain the communications of the different applets secure from one another, all third parties with applets on the meter 102 would have to agree before any new applets, or other software, could be installed, and complete trust between all third parties having applets installed on the meter 102 would be necessary. In practice this is unlikely to be achieved. For example, an electricity supplier would be unlikely to trust a gas supplier not to analyse electricity usage in order to offer the consumer a better deal.

Further, without the capability to maintain the communications of the different applets secure from one another, telecare providers would generally only be able to offer a very restricted range of services and might even be unable to provide any service at all because of the requirement to be sure that the data was kept confidential. In many countries data protection laws place companies are under an obligation to keep certain consumer details secret, which is only possible when one program operating on a computer such as the meter 102 is guaranteed not to be able to access another program running on the same computer. The invention herein described is able to provide such a guarantee.

It will be understood that the functions implemented by the secure microcontroller software described here can also be implemented by alternative approaches that use different software elements. Alternative software stacks could be used that have a plurality of programs, each comprising instructions and data, as long as a processor can, using one of these programs, provide a secure communications channel between a local device and an associated server, while the processor does not accept commands from any other of said programs to access or change the program, and does not route messages over said secure communications channel that are not from or to the local device and the associated server. Figure 9 shows exemplary operational steps for meter 102. At step 901 the meter 102 is installed in home 101, and at step 902 the meter 102 is commissioned by the engineer using a commissioning applet. Once the meter 102 is commissioned, the commissioning applet is deleted by the infrastructure management authority under instructions from the electricity supplier at step 903. At step 904 the electricity metrology applet 601 provides a secure communications channel between electricity supplier server 201, and metrology device 303 and remote user interface 105. This involves receiving consumption data from metrology device 303 and storing it, displaying consumption data on user interface 105, periodically sending consumption data to server 201, periodically receiving tariff data from server 201 and storing the tariff data, and displaying tariff data on remote user interface 105. The applet 601 may also perform other functions if required.

At step 905 the infrastructure management authority server 207 adds or deletes other applets on behalf of third parties. These may be any sort of applet that communicates with any sort of server or local device. Usually these applets are installed remotely via internet 105 and/ or mains power line 201. However, an applet could also be installed locally via a local interface. At step 906, all the installed applets provide secure communications channels between their respective local devices and servers. Following this, steps 905 and 906 are repeated with new applets being added, old applets being deleted and installed applets continuing to provide secure communication channels. Figure 10 illustrates transmission of electricity consumption data from meter 102 to servers of electricity providers and associated service providers. The "raw" electricity consumption data measured by metrology device 303 is provided to a plurality of applets associated with electricity consumption. Each applet is configured to process the utility consumption data to generate output data relevant to the provider that the applet is associated with. Further, each applet is configured to keep the output data secure.

Electricity retail supplier server 201 may communicate securely with metrology device 303, and may also communicate securely with remote user interface 105. A billing applet 1001 within meter 102 communicates securely, via the shared platform provided by the other software within secure microcontroller 306 and LAN interface 307, with metrology device 303, and may also communicate securely with remote user interface 105. Billing applet 1001 similarly communicates securely, via the shared platform provided by the other software within secure microcontroller 306 and WAN interface 305, with electricity retail supplier server 201. Thus a secure communications channel 1007 may be provided between electricity retail supplier server 201 and metrology device 303, and may also be provided between electricity retail supplier server 201 and remote user interface 105, by the applet 1001.

Metrology device 303 may be configured to measure electricity consumption at relatively short intervals, such as once every 30 minutes, or once per second, and provide this electricity consumption measurement to the billing applet 1001. The billing applet 1001 may be configured to calculate the total number of units (e.g. kilowatt hours) of electricity consumed over a longer interval (for example 1 month) from this raw energy consumption data, and transmit only this aggregated value to server 201 of the electricity retailer in order that a bill may be generated. In this way, the amount of sensitive information transmitted to the server 201 of the electricity retailer may be reduced or eliminated. For example, electricity consumption data for 30 minute periods may reveal periods of low electricity consumption within a house due to the house being empty. However, this fine-grained information is not derivable from an aggregated electricity consumption value over a longer period, such as a month. Such an aggregated value of electricity consumption over a long period is not generally regarded as sensitive information.

The billing applet 1001 may generate a measure of consumed electricity in real time as the short interval electricity consumption measurements are produced, store a cumulative total of the total number of units of power consumed in a data store comprised within or associated with the smart meter 102, and send this cumulative total to the server 201 of the electricity retailer at the desired longer interval, such as 1 month for example.

Alternatively, the smart meter 102 may store the "raw" measurements of electricity consumption made at the relatively short intervals, such as once every 30 minutes or once per second, in a data store comprised within or associated with the smart meter 102. The billing applet 1001 can then analyse the stored "raw" measurements of electricity consumption at a longer interval, for example 1 month and calculate the total number of units of electricity consumed over the longer period from the stored measurements. This cumulative total can then be sent by the billing applet 1001 to the server 201 of the electricity retailer.

The cost of a unit of electricity may depend on the day and / or the time of day that the unit of electricity is consumed. For example, the cost of a unit of electricity may be higher during periods when demand for electricity is higher. Accordingly, in one arrangement electricity consumption measured at relatively short intervals may be stored in the data store comprised within or associated with the smart meter 102 and, for each interval within a longer billing period, the billing applet may be configured to multiply the units consumed within a specific interval with the cost of a unit electricity during that specific interval and add up the cost for each interval to produce a billing value for the billing period. In this way, a "time of use" tariff may be used to calculate the cost of the utility consumed without having to export detailed electricity consumption data at each interval.

The utility prices may for example be sent in the form of a weighting curve which can be multiplied by the amount of electricity consumed in each interval to determine the price of the electricity consumed in that interval. The billing applet 1001 may receive a tariff algorithm from electricity retailer 201, and apply that tariff algorithm to the units of electricity consumed in each 30 minutes interval in order to determine the total cost.

Accordingly, the server 201 of the electricity retailer is able to be securely provided with information required to bill a consumer, such as a bill value or a cumulative electricity consumption total, but does not receive the "raw" electricity consumption data or information derivable from the raw data other than information required for billing purposes. Similarly to the measurement of electricity consumption, the calculation of the value of consumed electricity may be carried out in real time as the short interval electricity consumption measurements are produced and stored as a cumulative total value, or the calculation of the value of consumed electricity may be carried out at longer intervals using stored short interval electricity consumption measurements and a stored record of changes in the value of each unit of electricity consumed at different times. The billing applet 1001 may digitally sign the aggregated total transmitted to server 201 to assure the electricity retailer that the aggregated total can be relied upon for billing purposes, having been prepared by a trusted applet according to a known tariff. Communication with server 201 is through a secure communications channel 1007 using an encryption key specific to the secure communications channel between smart meter 102 and server 201. The establishment of this secure communications channel may be facilitated by the security domain applet associated with the billing applet 1001. Applet 1002 is a settlement applet configured to generate "settlement" data from the electricity consumption data. The settlement applet may be used in addition to the billing applet 1001. Typically, energy generators and energy retailers arrange bilateral contracts agreeing the amounts of energy to be provided to the retailers in predetermined periods in the future. These predetermined periods in the future may be half-hour timeslots. The energy to be provided is separately priced in each predetermined period. When the energy actually used by an energy retailer in a particular period differs from the agreed amount exchange payments are made between the energy generators and retailers based upon the actual energy consumed and the "spot price" for energy during the period. This is referred to as the "settlement" process. The settlement process may be administered by a settlement authority.

Currently consumers (in a particular category) may generally be assumed to consume their energy at the same rate over time, according to normalised consumption profile curves representing consumption over a 24-hour period. Settlement payments are made assuming that all customers consume electricity in accordance with this normalised consumption profile. However, if a particular utility supplier has persuaded its customers to reduce consumption at peak periods (by way of a time-of-use tariff, for example) then the application of the normalised consumption profile curves will result in the utility paying more in the settlement process than it would do if settlement was based on the actual consumption profile of the utility's customers. If energy retailers are to be properly rewarded for encouraging their customers to move to time-of-use tariffs then the settlement process needs to be modified take account of the modified consumption profiles of their consumers. The utility's settlement charges could be assessed more fairly if actual use data were available from each customer, in particular data representative of how time of use for each customer differs from the normalised consumption profile curves..

The categories of consumers could be, for example business and domestic customers, and each of these categories may be divided into further sub-categories, for example households with more than or less than a certain number of occupants, and a normalised consumption profile, representing a general average consumption profile for a category, may be generated for each category.

The settlement applet 1002 can analyse consumption data from the customer and provide data to permit an accurate and fair settlement process without divulging the customer's detailed consumption data. The settlement applet 1002 communicates securely, via the shared platform provided by the other software within secure microcontroller 306 and LAN interface 307, with metrology device 303. Settlement applet 1002 similarly communicates securely, via the shared platform provided by the other software within secure microcontroller 306 and WAN interface 305, with settlement authority server 208 The sent data could be encrypted with the cryptographic key of the settlement authority. Thus a secure communications channel 1008 may be provided between settlement authority server 208 and metrology device 303.

Metrology device 303 may be configured to measure electricity consumption at relatively short intervals, such as once every 30 minutes, or once per second, and provide this electricity consumption measurement to the settlement applet 1002. The settlement applet 1002 may be configured to calculate an average energy consumption profile curve, for example an average energy consumption profile curve over a day, from this raw energy consumption data at longer intervals, such as monthly, and transmit only this average energy consumption profile curve to server 208 of the settlement authority in order that settlement may be carried out. In this way, the amount of sensitive information transmitted to the server 208 of the settlement authority may be reduced or eliminated. For example, electricity consumption data for 30 minute periods may reveal periods of low electricity consumption within a house due to the house being empty. However, this fine-grained information may not be derivable from an average energy consumption profile curve over a day based on average consumption values over a longer period, for example a month.

The settlement applet 1002 may store measures of consumed electricity in real time as the short interval electricity consumption measurements are produced, use these stored measures to calculate the average energy consumption profile curve, and send this calculated average energy consumption profile curve to the server 208 of the settlement authority at the desired interval, such as monthly. The average energy consumption profile curve may, for example, be calculated by determining a daily energy consumption profile curve for each day, and then determining an average of the daily energy consumption profiles. However, other methods of determining the average energy consumption profile curve may be used.

Alternatively, the smart meter 102 may store the "raw" measurements of electricity consumption made at the relatively short intervals, such as once every 30 minutes or once per second, in a data store comprised within or associated with the smart meter 102. The settlement applet 1002 can then analyse the stored "raw" measurements of electricity consumption at a longer interval, such as monthly and calculate the energy consumption profile curve. This calculated energy consumption profile curve can then be sent by the settlement applet 1002 to the server 208 of the settlement authority.

Similarly to the billing applet 1001 discussed above, communication with server 208 of the settlement authority is through a secure communications channel 1008 using an encryption key specific to the secure communications channel between smart meter 102 and server 208. The establishment of this secure communications channel may be facilitated by the security domain applet associated with the settlement applet 1002. Alternatively, the separate settlement organization may broadcast an model energy consumption profile curve to all meters (perhaps retrospectively, each month, to reflect actual electricity consumption). The smart meter 102 could receive this model energy consumption profile curve and compare the actual electricity consumption to the model energy consumption profile curve to generate comparison data, such as a figure of merit, indicating the difference between the model energy consumption profile curve and the actual energy consumption. This may be done periodically, for example on a monthly basis. The sent model energy consumption profile curve may be protected by encryption. This generated comparison data such as a figure of merit can then be sent by the settlement applet 1002 to the server 208 of the settlement authority. This comparison data would be a proxy for the actual consumption data, and sufficient to improve the settlement process, and would allow almost no personal data to be derived.

Alternatively, the settlement data calculated by the settlement applet 1002 could be sent to the server 201 of the energy retailer, which would participate in the settlement process.. In this case the sent data could be encrypted with the cryptographic key of the energy retailer.

For example, the electricity retailer could use the settlement data to generate an average consumption profile or average figure of merit for a plurality of households that are customers of that retailer, and transmit the average data to the settlement authority. In this way, the settlement authority is provided with only the average consumption profile or figure of merit for the plurality of customers of the electricity retailer, rather than the data for each individual consumer.As described above, the security domain applet corresponding to the settlement applet 1002 will allow only the server 201 of the electricity retailer to receive the stored energy consumption profile curve. Stored data, which may be either raw electricity consumption data or data derived from the raw data, will be protected by the secure microcontroller to generally prevent unauthorised access to the stored data. Accordingly, the server 208 of the settlement organisation is able to be provided with the required settlement data, but does not receive other parts of the stored data or the real time energy data.

A line quality applet 1003 may monitor how voltage and harmonics vary over a period of time, for example to determine and accumulate minimum, maximum and average voltage values for the period. This information may be encrypted with a cryptographic key belonging to the electricity supply network operator, and transmitted to a server 1005 of the electricity supply network operator. In some examples another component of the meter 102 may generate the measurements of voltage values. Similarly to the billing applet 1001 discussed above, communication with server 1005 of the electricity network operator is through a secure communications channel 1009 using an encryption key specific to the secure channel between smart meter 102 and server 1005. The establishment of this secure communications channel may be facilitated by the security domain applet associated with the line quality applet 1003. Metrology device 303 may be configured to measure voltage values at relatively short intervals, such as once every 30 minutes, or once per second, and provide these measurements to the line quality applet 1003. The line quality applet 1003 may be configured to calculate the minimum, maximum and average voltage values of the electricity supply from these raw measurements, and transmit only these measurements to server 1005 of the electricity network operator in order that line quality of the electricity supply may be assessed. In this way, the amount of sensitive information transmitted to the server 1005 of the electricity network operator may be reduced or eliminated. For example, electricity consumption data for 30 minute periods may reveal periods of low electricity consumption within a house due to the house being empty. However, this fine- grained information is not derivable from minimum, maximum and average voltage values of the electricity supply. Such voltage measurements are not generally regarded as sensitive information.

The line quality applet 1005 may generate a measure of voltage values in real time as the short interval electricity consumption measurements are produced, and send the measured voltage values in real time to the server 1005 of the electricity network operator for analysis. Alternatively, the line quality applet 1005 may store the measured voltage values in a data store comprised within or associated with the smart meter 102, and send this accumulated measured values to the server 1005 of the electricity network operator at a desired longer interval. Alternatively, the smart meter 102 may store the "raw" measurements of electricity consumption made at the relatively short intervals, such as once every 30 minutes or once per second, including voltage measurements, in a data store comprised within or associated with the smart meter 102. The line quality applet 1005 can then analyse the stored "raw" voltage measurements at a longer interval and calculate the minimum, maximum and average voltage values of the electricity supply from the stored measurements. These calculated values can then be sent by the line quality applet 1003 to the server 1005 of the electricity network operator.

Only the server 1005 of the electricity network operator receives the stored calculated voltage values. , but is not able to obtain other parts of the stored data. A detailed usage applet 1004 may provide an energy management agent with information relating to electricity consumption patterns within a domestic, business or other setting that may be analyzed to help the consumer reduce their electricity consumption and/ or electricity bills. This may require transmission of detailed electricity consumption data to show information on how electricity consumption varies over time. Due to the sensitive nature of the data to be transmitted by detailed usage applet 1004, it may be preferred, or even legally required, that installation of this applet 1004 may only be carried out with the consumer's knowledge and consent.

The detailed usage information may be encrypted with a cryptographic key belonging to the energy management agent, and transmitted to a server 1006 of the energy management agent. Similarly to the applets 1001 to 1003 discussed above, a security domain applet associated with the detailed usage applet 1004 may establish a secure communication channel 1010 between the metrology device 303 and the server 1006 of the energy management agent. Metrology device 303 may be configured to measure electricity consumption at relatively short intervals, such as once every 30 minutes, or once per second, and provide this electricity consumption measurement to the detailed usage applet 1004. The detailed usage applet 1004 may be configured to select significant consumption data from this raw energy consumption data, and transmit only this selected significant consumption data to server 1006 of the energy management agent for analysis. Alternatively, the detailed usage applet 1004 may be configured to transmit all of the consumption measurements to the server 1006 of the energy management agent for analysis.

Similarly to the billing applet 1001 discussed above, communication with server 1006 of the energy management agent is through a secure communications channel 1010 using an encryption key specific to the secure communications channel between smart meter 102 and server 1006. The establishment of this secure communications channel may be facilitated by the security domain applet associated with the detailed usage applet 1004.

In the embodiment shown in figure 10 the electricity applet 601 shown in figure 6 has been replaced, or subdivided, into the separate billing applet 1001, settlement applet 1002, line quality applet 1003 and detailed usage applet 1004, which all relate to different matters relating to the electricity supply. The security domain 606 shown in figure 6 will similarly be replaced by, or subdivided into, separate security domains corresponding to each of the billing applet 1001, settlement applet 1002, line quality applet 1003 and detailed usage applet 1004. Although four different applets configured to process electricity consumption data are illustrated in Figure 10, it will be appreciated that two or more different applets may be provided to process the same incoming data. Further applets directed to auditing, research and advice to consumers are described below.

In addition to the electricity supply related applets discussed above, the secure

microcontroller 306 may also support other applets, as shown for example in figures 2 and 6. For example, electricity, or energy, export applet 604 may provide a secure communications channel between an electricity grid server and power inverter 111.

Gas applet 602 may provide a secure communications channel between a gas supplier server 203 and gas meter 107. Telecare applet 603 may provide a secure communications channel between telecare provider server 204, and telecare devices, such as scales 108 and panic button 109.

Many other possible applets may be envisaged. For example, a local device might be an expensive consumer item that communicates wirelessly with a geo- fencing applet on secure microcontroller 306. Regular communication confirms that the item is within communication range of the meter 102. However, if the item fails to communicate with the meter 102 for a predetermined length of time the item may stop working, on the basis that it has been taken out of the home 101, and so may have been stolen. Additionally, items equipped with an audible alert mechanism could be required to identify themselves by an applet.

Further, a TV licence applet could be connected to a TV within the home. If the TV licence is not paid, a TV licence authority server may instruct the TV to stop working, or may fail to supply a code or other data item required in order for the TV to work. Other pay- per-use services could also be managed this way. Various financial services applets could be provided that provide services to users. For example, the meter 102 could communicate with a credit-card reader as a local device. The credit-card reader could be a contact- type reader or a contactless reader using NFC communications. When the user makes a purchase online, the financial services applet could be used to verify the credit or debit card used. The user would insert the card and enter a PIN on the credit-card reader local device, which would display a one-time password for entry into the vendor's website. The applet would verify the PIN and perform the calculation of the password.

The meter 102 could alternatively communicate with a full Chip-and-PIN terminal as a local device, allowing payment to be made by communication with a bank server, under the control of a financial services applet.

Pre-pay items could be topped up using the meter 102, for example a travel card or a mobile telephone. This could be done via user interface 105, or if the meter 102 included a Near- Field Communication (NFC) reader, then an NFC-enabled item could simply be touched to the meter. The NFC reader could alternatively be located in a remote device, such as remote user interface 206. An applet would then communicate with a relevant server to add credit to an account. Payment could be taken as described above, added to the electricity bill, or by some other method. The NFC reader is considered to be a local device whether it is located in the remote user interface 105 or the meter 102.

NFC tags could be supplied with wireless-enabled items, and touched to an NFC-enabled meter or NFC-enabled remote user interface to enable a commissioning applet to commission the item, allowing it to join the wireless network. If kept, the NFC tag could be used to commission the item to a new network when the owner moved house. This would provide an easy way of setting up communication between a meter and local devices.

A local device comprising storage, such as a hard drive, FLASH drive or other suitable means, could be used to allow other local devices to back up data, such as a mobile phone address book. An applet would control the storage of and access to such data. The storage device could be contained within the meter or remote from it.

A local device comprising a barcode reader or an RFID reader could be used to read barcodes or RFID tags on items bought from a supermarket. An applet would

communicate with a server to identify the item and return the information to the user. This would be useful for a partially- sighted person. A similar applet could place an order for the item with the supermarket for home delivery. The reader device could be contained within the meter or remote from it.

Another applet could be used to allow communication between two users. For example, text messages, emails or images could be sent from one meter to another meter.

Other local devices that would usefully be connected to an applet on meter 203 in order to communicate with a remote server are a fire alarm, smoke alarm, movement sensors or burglar alarm. A building management applet could communicate with various sensors and actuators around home 106 in order to provide energy management. If the bandwidth of the LAN interface 307 and WAN interface 305 were sufficient, an applet on meter 203 could be used to provide Internet connectivity to computers and other internet-connected devices in home 106.

As discussed above, the contents of the secure microcontroller 306 may comprise applets corresponding to specific devices in the home and providing a secure communications channel between these devices and respective remote servers. For example, the telecare applet 603 of figure 6 may correspond to scales 108, and together with the corresponding security applet may provide a secure communications channel between the scales 108 and a healthcare provider server 204. As a further example, the gas applet 602 may correspond to a gas meter 107, and together with the corresponding security domain applet may provide a secure communications channel between the gas meter 107 and a gas supplier server 203.

When a new device is introduced into the home it is necessary to install the corresponding applet and security domain applet onto the secure microcontroller 306 in order to support and provide the desired secure communications channel, and other functionality, of the device. This may be a problem because, in general applets may be relatively large and the WAN communications channel might be slow, have long latency, and it might be expensive to transfer data through this channel. Accordingly, it may be inconvenient or expensive to download the applet through the WAN from a server of a service provider associated with the new device.

This problem may be overcome by deploying an applet or applets onto the secure microcontroller 306 of the smart meter 102 from the device itself using the LAN channel between the device and the meter. Generally, the LAN channel will have reasonable speed, low latency and zero cost. In order for a device to transfer its own applet to the smart meter 102,the device can be arranged to cooperate with the secure software framework running on the secure microcontroller 306 to perform the same mutual authentication protocol as if the smart meter 102 were talking across the WAN to a server to download an applet. The same sequence of commands would load the applet from the device, validate it, and enable it for operation.

Alternatively, the device could perform only some of the steps to load, validate and enable the applet. The device may perform only the tasks that require heavy communications traffic, that is the transfer of large amounts of data to the smart meter 102 and the secure microcontroller 306, particularly the task of loading the applet to the smart meter 102. The smart meter 102 and the infrastructure management authority server 207could then execute the protocols that validate the applet and enable it for operation.

In the case that the device performed all the operations it would have to be implemented in a secure microcontroller. This would be necessary to protect the cryptographic secrets in the device, upon which the integrity of the protocols rest. A conventional microcontroller could be used for transferring the applet code, and the validation process may be performed by the smart meter and the server through the WAN channel. Alternatively, all devices that communicate with the smart meter may be implemented in secure microcontrollers, and the device and smart meter telecommunications hub may perform mutual authentication before exchanging data.

The installation method described above may also be used to provide a secure way to commission smart meters during installation and servicing. In this case the device would typically be a hand-held commissioning tool possessed by the energy supplier's operative. The device and the meter would mutually authenticate each other and then the device could provision the meter with the necessary applets, and activate these as appropriate. The commissioning tool would of course need to be implemented with a secure microcontroller.

An alternative embodiment of a smart meter that embodies the invention is shown in Figure 11. Smart meter 1101 is installed in home 101 and has been retrofitted with the capability to implement the invention herein described. It includes a conventional microcontroller 1102 connected to a metrology device 1103, a user interface 1104 and a WAN interface 1105. WAN interface 1105 communicates with the concentrator at a substation via mains power line 1106. Premises electricity wiring 1107 provides electrical power from mains power line 1106 to devices within home 101. Mains power line 1106 provides power to meter

1101 via power supply unit 1111. Conventional microcontroller 1102 stores data from metrology device

1103 and sends it, via WAN interface 1105 and mains power line 1106, to electricity supplier server 201. However, a meter comprising only a conventional microcontroller

1102 cannot be used to embody the present invention because multiple programs cannot be installed on it that will provide secure communications channels between local devices and servers, nor even securely store data received from local devices.

Accordingly, in addition to the conventional microcontroller 1102 the meter 1101 further comprises a communications block 1108 which may provide a telecommunications hub, comprising a secure microcontroller 1109 and a wireless LAN interface 1110. Secure microcontroller 1109 is largely identical to the secure microcontroller 306 discussed above, and runs programs, including applets, in the same way.

In this embodiment, WAN communications using WAN interface 1105 are routed via conventional microcontroller 1102. Since the WAN communications are already encrypted this does not impact on security.

In alternative embodiments the WAN interface 1105 could be another type of interface, as could the LAN interface 1110. Further, communications block 1108 could be implemented as an additional circuit board within the meter 1101, as a smart card that plugs into meter 1101, or as any other type of suitable add-on module internal or external to the meter 1101. Another embodiment of the invention is shown in Figure 12. Meter 1201 is contained within home 101. The meter 1201 includes a metrology block 1202 and a communications block 1203 which may provide a telecommunications hub. Metrology block 1202 comprises a conventional microcontroller 1204 connected to a user interface 1205 and a metrology device 1206. Mains power line 1207 provides power to meter 1201 via power supply unit 1208. Premises electricity wiring 1209 provides power to devices and appliances in home 101. Metrology block 1202 is equivalent to a prior art "non- smart" meter and simply measures power consumption and displays it to a user.

Communications block 1203 comprises a secure microcontroller 1210, a WAN interface 1211 and a LAN interface 1212. In this embodiment, both WAN interface 1211 and LAN interface 1212 are wireless. The LAN is in this example is the ZigBee^(R) network, while the WAN is a wireless mesh network radio suitable for radio communication with a concentrator.

In this embodiment the communications block 1203 and the metrology block 1202 are housed in their own enclosures and communicate through connection 1213 using an Ethernet connection. However, any appropriate technology could be used, such as Universal Serial Bus (USB), an RS232 serial port, one of several wireless local area network technologies, and others. Secure microcontroller 1210 is functionally identical to secure microcontroller 1109 and runs applets to provide secure communications channels to local devices within home 101 and remote servers in a similar manner to secure microcontroller 306 discussed above.

As discussed above, communication between the secure microcontrollers 306, 1109 and 1210 and their local devices is facilitated via a wireless network such as ZigBee(R). Each microcontroller only communicates, via its respective LAN interface, with its own devices. However, each microcontroller is also capable of communicating with other devices and with each other. This allows a Community Area Network (CAN) 1301 to be created. The CAN could have local hubs, or could be a "mesh network" involving peer- to-peer communication, as shown in Figure 13. In a CAN, each meter or other device embodying the invention is considered to be a node, and each has one or more applets that carry out methods described below. It has been discussed above with that local devices could be located or geo-fenced using applets on a meter. This principle also holds for devices within the CAN. A stolen device 1304 might require location, or a young or confused person 1302 could be equipped with a location device 1303 configured to communicate with any nearby node. These communications include received signal strength indication (RSSI) measurements, indicating signal strength and therefore distance from a node, and are stored for later consideration. If the person is missing, then a carer can, at their own node, send out a request for any nodes that have communicated with device 1303 to send details of these communications. Triangulation using the latest communications can then locate person 1302.

For a device to communicate with a node it usually needs associating with that node by commissioning. Local devices are generally only associated with their own meters. However, a request for association, whether successful or unsuccessful, is sufficient for this purpose. This approach has issues for personal privacy. A solution is to ensure that the device does not broadcast its own unique device ID, but rather a random, frequently changing number to avoid tracking. Each association request from device 1303 contains encrypted information, in this case the device's unique ID and RSSI data, but appears to come from one of these random numbers. The node rejects the request and stores it. The request can therefore be considered to be malformed, in that it includes a device ID unknown to the node. Other methods of malforming the request would also work.

Once person 1302 is noted as missing, an applet on the carer's meter sends cryptographic keys to the other nodes. Applets on these nodes attempt to decrypt data within rejected association requests using these keys. If decryption is successful, the information is returned to the carer's node, and device 1303 can be located. This prevents location of person 1302 by anyone who does not have access to the node associated with device 1303. Some nodes in the CAN might be uncooperative, in that they do not have the correct applets installed. In this case, device 1303 can still collect location data since RSSI measurements are obtained from beacon frames transmitted by all nodes. This data could then be included in the next association request to a cooperative node. Alternatively, device 1303 might simply collect RSSI information and not attempt to contact any node at all. When a carer wishes to locate person 1302, an applet on the carer's node sends out messages to nodes that are near to the presumed location of person 1302. These nodes then broadcast an "are you there" message to the ID of the device 1303. If the device 1303 receives it, the device 1303 can request to join the network and be admitted, the device 1303 can then return its RSSI data so that it can be located.

Other methods of estimating distance from nodes may be used, such as ultra- wide band and chirp- spread- spectrum. It would also be useful to allow a local device to associate itself with another node. For example, the user of weighing scales 108 might want to associate it with the node at a friend's house while visiting. In this example, the device 108 can be commissioned onto the LAN at the friend's house, for example by pressing buttons or using NFC tags.

Further, a vulnerable person possessing a telecare device that informs the telecare provider of a fall will want to use it while out of the house as well as in. In this case, the device must join the network immediately, without commissioning. Commissioning applets on another node would be programmed to allow particular sorts of devices to join the network, but care should be taken to avoid devices masquerading as these special devices being allowed to join. Cryptographic operations should be used to ensure the authenticity of the device.

An example of another way of embodying the invention is shown in Figure 14. A communications device 1401 may be located in a supermarket and arranged to communicate with a supermarket chain server. The communications device 1401 comprises a secure microcontroller 1402, functionally similar to secure microcontroller 306 discussed above, which communicates with LAN interface 1403 and GPRS radio module 1404. Local devices, for example devices that monitor refrigerator temperatures, are connected to LAN interface 1403. A SIM card 1405 is connected to GPRS radio module 1404. GPRS radio module 1404 and SIM card 1405 provide the WAN interface in this example, and GPRS radio module 1404 may communicate through a GPRS gateway. The function of SIM card 1405 is to take part in an authentication process with a GPRS radio network to identify the GPRS radio module 1404, to allow the GPRS radio module 1404 and the GPRS network to authenticate each other, and to establish cryptographic keys to secure wireless communications across the GPRS network. SIM card 1405 is itself a form of secure microcontroller. A further embodiment is similar to device 1401, but without the SIM card 1405. In this further embodiment, the function of the SIM card is performed by the secure

microcontroller. Therefore, the WAN interface comprises a GPRS radio and the secure microcontroller itself.

Communications device 1401 allows communication between refrigerator temperature sensors and a server, under control of an applet that has been provided by the

manufacturer of the temperature sensors. However, because the communications device 1401 embodies the present invention it is possible to install other applets and allow communication with other devices within the supermarket. For example, a lighting applet together with sensors that detect failing light bulbs could be installed within secure microcontroller. As another example, a heating, ventilating and air conditioning (HVAC) applet could be installed, and used to communicate with sensors and actuators in the HVAC equipment. Each of these applets could communicate with a single supermarket server, or with several different servers each associated with one applet. It should be understood that communications device 1401 facilitates communications between one or more servers, one or more applets and one or more sets of local devices in such a way that new services can be deployed in the communications device 1401 at any time. These new applets with their associated local devices and servers could be added in order to implement a new function as required. As new applets are added the operation of existing applets will not be disturbed by the new applet, and the data associated with each applet will be kept private.

Other examples of apparatus embodying the invention are an onboard computer in a car where each applet provides another facility such as navigation, insurance and road pricing, or a vending machine selling real or virtual products from multiple vendors. Any apparatus that requires secure communication, whether direct or indirect, between a local device and a remote server, and needs to keep local programs and data secure from each other and outside tampering could be implemented by the present invention..

The invention has been discussed primarily with respect to consumption of electricity, however it will be appreciated that the methods described herein can equally be applied to consumption of water or gas supplied to a household. The invention may also be applied to other fields such as logistics or transport systems.

Consumption of water and gas can be measured using techniques that are well known to the skilled person, for example based on use of water and gas meters. Water and gas consumption, in particular water consumption, may be measured at a lower rate, for example at least once every 300 seconds or at least once every 60 seconds, in order to generate water consumption data that may be used to identify events associated with consumption of water. The rate of flow of water or gas at each time interval may be measured, along with the total volume consumed over time in a manner analogous to power and energy measurements of electricity consumption. Additionally or alternatively, water and gas consumption may be measured at measurement points after intervals of volume consumption rather than intervals of time, for example a measurement of time elapsed for each unit volume (e.g. litre) of water to be consumed. The rapidly aging population is the motivation for exploring the ways that technology can be used in people's home to improve their health care and social care. There are benefits in using the smart meter infrastructure to do this remote monitoring. The network will be ubiquitous (in the UK every house in the country will have a smart meter by 2020), it will be reliable (users cannot switch it off accidentally or deliberately) and the costs of the infrastructure will be borne mainly by the energy suppliers. By extension, other value- added services can also be deployed. If one assumes that each value-added service will generate a revenue stream, then the extension of the smart meter system to support value- added services will improve the economics of the smart meter programme.

The present inventors have found that it is possible to deploy new value-added services onto the smart meters dynamically and securely, while preserving the integrity of existing applications and maintaining a separation of the data between the different applications (such that health data will not be available to the energy supplier, and vice versa). Secure Microcontrollers, GlobalPlatform and Java Card

This section describes exemplary secure microcontroller hardware that may be used to prevent attacks on computer hardware that is accessible to malicious actors. It then describes the GlobalPlatform software platform that is used to manage multiple computer programs that can run on these secure microcontrollers. Finally it discusses the Java Card programming language, which may be used to implement these computer programs.

The secure microcontrollers, and the GlobalPlatform and Java Card software model described here have been designed for credit cards and the like, however the present inventors have recognised that they may also be used for smart meters.

Secure Microcontrollers

Secure microcontrollers are most commonly used in mobile phone SIM cards and in smart cards. They are also used as the cards that control access in subscription television receivers.

In all of these cases they are used to guard access to a valuable resource, where there could be a temptation to defraud the rightful owner of his or her money. The present inventors have found that these microcontrollers may be used in smart meters, including pre-pay meters.

A secure microcontroller is designed to resist attack by malicious individuals who are attempting to read or change data or programs within the microcontroller, typically with the aim of stealing something.

The term "tamper-resistance" is often used in this context, and a list of counter-measures listed by Atmel (a manufacturer of secure microcontrollers) indicates the range of attacks possible:

High and low voltage detectors

High and low frequency detectors Temperature detectors

Illegal access code detection

Illegal opcode detection

Tamper monitor

Non invasive attacks: side channel attacks, fault injection attacks

Invasive attacks: reverse engineering, microprobing, laser attacks

The secure microcontrollers typically include hardware functions to facilitate security operations:

Secure memory management, access protection

True random number generator

CRC engine

Hardware DES/triple DES or AES

Crypto-processor and elliptic curve options

It is worth noting that while secure microcontrollers are usually manufactured in the familiar SIM card or smart card formats, they may also be implemented in conventional microprocessor packaging and soldered to printed circuit boards. In such manifestations they can include the full range of peripherals found on conventional microcontrollers.

Successful attacks on smart meters will be potentially much more serious than those on existing meters, since they are networked, and thus potentially many meters could be attacked remotely. Regular visits to inspect the meters will cease. Since there is a proposal for meters to disconnect electricity and gas supplies under software control, extortion and terrorism also need to be considered. GlobalPlatform

The present inventors have found that the GlobalPlatform standard used for managing applications on secure chips may be used for securely installing, personalising and / or managing the software that runs on the secure microcontrollers. The GlobalPlatform organisation was established by the main players in the smart card industry to establish standards for smart cards. It is derived from earlier work done by Visa for securing credit cards. Most of the rest of this section describes GlobalPlatform in terms of its use with smart cards, but it will be appreciated these features can be used for managing software on smart meters, and specifically that technology described in relation to a smart card may be used in the secure microcontroller of a smart meter as described above, and that a smart meter system owner can utilise the system in a manner analogous to a card issuer.

Amongst the GlobalPlatform standards is the GlobalPlatform Card Specification aimed at managing the life-cycle of smart cards themselves, and the application programs (applets) which run on them. The aim of this standard is to allow multiple applets, from multiple vendors, to be deployed on smart cards. Thus a single smart card could perform several different functions.

The GlobalPlatform Card Specification says:

"The GlobalPlatform architecture is designed to provide Card Issuers with the system management architecture for managing these smart cards. Although GlobalPlatform is based on the paradigm that there is one single Card Issuer for a card, it offers to the Card Issuer the flexibility for managing an ever-changing array of business partners who may want to run applications on the Card Issuer's cards.

GlobalPlatform gives Card Issuers the power to manage their cards with the ultimate flexibility by enabling them to share control over part of their card with business partners. The ultimate control always rests with the Card Issuer, but through GlobalPlatform, the business partners of a Card Issuer can be allowed to manage their own Applications on the Card Issuer's cards as appropriate."

The Application Providers have their own "Security Domains" on the secure microcontroller, which may manage the loading and installation of applications pre- approved by the Card Issuer. The multiplicity of Security Domains allows each Security Domain User's security data (such as cryptographic keys) to be kept separate and private from that of other Security Domain Users and also from the Card Issuer. The Card Issuer has its own Security Domain. Security Domains support security services such as key handling, encryption, decryption, digital signature generation and verification for their providers' applications.

The Card Issuer and the Application Providers have corresponding "off-card entities" and GlobalPlatform allows for logical secure communications channels ("Secure Channels") to be established between each of the on-card entities and their corresponding off-card entities for the secure exchange of messages.

When an Application Provider wants to install a new application (with the approval of the Card Issuer), its Security Domain verifies that the integrity and authenticity of application (using digital signatures).

Applications may call upon the services (listed above) provided by their associated Security Domains. This allows a separation of the application code from the cryptographic tools, meaning that the programmers writing the applications do not also have to be cryptography specialists. It also allows an application to be associated with different Security Domains (and thus different off-card entities) from time to time without the need for changes to the application code or cryptographic functions within the application.

Typically, each application will communicate with its own off-card entity over a Secure Channel which is set up the the Security Domain. GlobalPlatform also provides tools to allow for: Authentication - this makes use public key cryptography, involving private keys possessed by an application on the card and by its off-card entity to allow both parties to be assured that they are communicating with who they think they are.

Message integrity - this makes use of Message Authentication Codes to allow the receiving party to be sure that the message has not been changed since it was sent.

Privacy - this makes use of encryption to assure the transmitting and receiving parties that eavesdroppers cannot understand exchanged messages.

Cards, Security Domains and Applications pass through a number of life-cycle states. For example, an application can be loaded on the card (but not installed), or installed (but not ready for execution), selectable (that is, able to be executed), locked (temporarily disabled) or deleted. Transitions are managed by the Security Domains and the applications themselves, in accordance with privileges when stem, ultimately, from the Card Issuer. Optionally, off-card entities may receive "Receipts" which are digital signatures that show the life-cycle transitions have occurred. This allows off-card entities to synchronise their databases with the actual state of the card.

Java Card

The applications that run on the secure microcontroller may be implemented as Java Card applets as described in detail below, however it will be appreciated that alternative software platforms may be used, for example the Multos operating system.

Java Card uses a sub-set of the Java programming language. It provides a secure environment for applications that run on smart cards and other devices with very limited memory and processing capabilities. Multiple applications can be deployed on a single card, and new ones can be added to it even after it has been issued to the end user. Applications written in the Java programming language can be executed securely on cards from different vendors. The advantages of using Java Card to deploy applications on secure microcontrollers may include the following. It will be appreciated that these advantages may apply equally to both a smart card application and a smart meter:

Java is a standard programming language - anyone who knows how to write a Java program can write a program for Java Card. Standard development environments and tools can be used.

All the benefits of object-oriented programming - programmers have the benefits of code reuse, design patterns, and superior structure.

Standardised development systems (such as Eclipse) provide good software tools, including tools to emulate and test the software before hardware is available.

The secure microcontroller architecture, the security features of Java language and the controls imposed by the Java Card software stack make it possible for multiple applets to reside safely on a Java Card microcontroller. The number of applets is only limited by the amount of space on the microcontroller.

GlobalPlatform provides standardised methods to manage the lifecycle of the applets, and of the card itself. Devices can be deployed in the field and additional functions added and updated over the lifetime of the device.

Secure environment - Java is well known as a secure programming language. The Java Card architecture imposes a firewall between applets, and the GlobalPlatform standards manage the deployment of the applets. This provides automatic separation of the data belonging to each application, and guaranteed privacy of data as further applications are added.

Platform independence - since Java Card applets are portable across different chip architectures, applets cost less to develop and maintain. This means that an application could be relied upon to work the same way on devices (smart cards or smart meters) from all manufacturers.

Support for object persistence and atomic transactions is designed in. This removes from the designer the burden of having to consider what happens if the power fails in the middle of an operation.

Security certification of the hardware/software combination which are typically evaluated according to Common Criteria for Information Technology Security Evaluation and ranked according to an Evaluation Assurance Level. This provides an independent evaluation and certification process of the security characteristics of a system.

Figure 15 shows the Java Card and GlobalPlatform software stack as implemented on a typical smart card (secure microcontroller).

A large proportion of mobile phones also use Java to deploy new functionality. In this case the version of Java is called "Java Platform, Micro Edition (Java ME)" (formerly J2ME), which may provide for high portability; the same application may be written once and downloaded to mobile phones with widely varying levels of capability (screen size, colours, keyboard layout, sound capabilities etc). As more sophisticated phones arrive on the market the old applications can be expected to work without modification. This concept of standardisation is carried through to Java Card, and holds out the prospect of an individual program running on smart meters from any manufacturer.

Basic Telecommunication Hub Architecture

The smart meter system may involve the following elements within the home:

Electricity meter

Gas meter

In-house display

Telecommunications hub

All of these will be connected through a wireless local area network (LAN), which may be a Home Area Network (HAN) and the telecommunications hub will include a wide area network (WAN) link to back-end servers. Examples of the LAN and WAN technologies are ZigBee and GPRS respectively. Figure 16 shows a smart meter system arrangement of this type.

This architecture may be extended by:

Providing LAN links to other in-home devices, such as telehealth equipment.

Using secure microcontrollers, GlobalPlatform and Java Card to add security and privacy, and for dynamic management of software.

This is illustrated in Figure 17, which shows a typical secure smart meter system for value added services.

Figure 18 shows an arrangement in which all utility consumption data is communicated across a WAN to servers of utility suppliers or other third parties. As described above, this data may be intercepted during communication to the respective servers, and / or accessed from the servers (accidentally or maliciously) by unauthorised third parties.

In the architecture shown in Figure 17 the secure microcontroller may run the GlobalPlatform and Java Card software described earlier. Each function that the telecommunications hub performs is performed by a different applet, each with its own cryptographic keys, and with each applet's data protected from the other applets by the firewalls enforced by the Java Card architecture. The applets are:

Electricity meter

Gas meter

Load control

Telecare/telehealth

Applet for other value-added services which could be deployed later.

Figure 19 shows how these applets are arranged within the secure microcontroller, providing separation of programs and data between applications. Figure 19 shows an arrangement having Java Card applets running in a telecoms hub. The GlobalPlatform architecture allows for secure communications channels, through the WAN, to the off-card entities corresponding to each of the applets. Figure 19 shows that, despite sharing the same telecomms infrastructure, in fact the applets and their server-side entities communicate through individual secure communications channels. (This figure shows a "Central Communications Provider" which may be a data communications company (DCC) processing data for the energy applets; this is the model currently proposed for the UK smart meter rollout. In reality, it will be appreciated that the DCC is not required by the architecture described herein. If data is transferred via a DCC then it will be appreciated that both data transfer channels are secure, that is a first channel between the DCC and the telecommunications hub, and a second channel between the DCC and the utility suppliers or service providers.) Figure 19 shows that secure communications channels link applets and server-side entities. Even if a DCC is present, data that is not relevant to the function of the DCC may be transmitted directly to the relevant server without decryption by the DCC. For example, telecare data may be transmitted directly to the telecare service provider.

The secure communications channels could be extended from the telecoms hub through to the devices.

The GlobalPlatform architecture allows for dynamic management of the applets: new applets can be installed and old applets deleted. This is done under the auspices of the body taking the role of the "Card Issuer", which can establish appropriate quality control over the applets. In a practical smart meter deployment this role could be taken by the Central Communications Provider or by another body.

Even leaving aside the benefits of the non-energy value-added services, this approach brings benefits to the smart meter stakeholders: Reuse of the well-tested secure microcontrollers/GlobalPlatform/Java Card technology.

Separation of gas and electricity data.

Secure mechanism for software upgrades. Secure mechanism for altering tariffs.

Mechanism to add support for new energy-realted functionality, such as support for electric vehicles and home-based micro-generation.

Local Processing Smart meter technology is able to collect fine-grained information about the energy use patterns of householders by measuring energy consumption at regular intervals. Rather than a meter reader visiting once a month to obtain a single energy consumption reading, the smart meters can tally energy consumption in 30-minute chunks, or even more frequently. This could be misused, for example to: Establish when the house is empty, or when it is likely to be empty.

Infer information about the social behaviour of the occupants.

Infer what appliances are in use in the house, and the pattern of their use.

Apply pressure to the householder to change their pattern of consumption.

The availability of extra data could have advantages and disadvantages. For example, it might be of use to the householder to receive advice on how to reduce energy bills based on an analysis of usage patterns by the energy supplier. On the other hand, some householders would find this intrusive, and energy suppliers could use the data to the disadvantage of the householder, perhaps by tailoring tariff offers to optimise profit. The threat to privacy could threaten the very viability of a smart meter system, either through a public outcry, or by legal challenge.

The present inventors have found that the same raw energy data could be processed by different applets within the smart meter, and the appropriate analysed data could be forwarded to server- side entities based on their need to know, and on commercial contracts between the householder and service providers. Figure 20 shows four applets processing the same raw energy data on behalf of four different server-side entities. The applets process energy data locally for different stakeholders.

The following use cases illustrate the power of this approach. Prepay Meters

Local processing will be needed for prepay meters. These meters must observe power consumption in the home, be aware of the tariff (perhaps a complex time-of-use tariff), and calculate the amount to deduct from the account balance. The same software will need to take account of emergency credit and friendly credit provisions, and perhaps implement trickle disconnect and time-limited disconnect algorithms. All this computing must be performed locally as it is important that the prepay meter isn't disabled by a customer blocking the WAN or LAN links.

This processing would be performed by a prepay billing applet such as billing applet 1001 in Figure 10. Credit Meters - Billing by Energy Suppliers

The energy supplier needs to bill their credit customers monthly or quarterly. For this to work the supplier does not need the half-hourly raw data. It is sufficient that a software program running on the meter can monitor consumption, apply the tariff and accumulate the bill. This is just what the prepay meter software will be doing. Then once a month the meter system sends the accumulated total to the supplier, which issues the bill. The message can be encrypted with the cryptographic key of the supplier, and can pass through the any intermediate servers without needing to be decrypted, stored or processed. There is no loss of privacy. And WAN data throughput and server-side storage are drastically reduced. For example, the energy supplier only needs to know that a householder has used energy to a certain value, calculated by an agreed tariff. The energy supplier can be assured of this if he receives a single monthly figure, cryptographically signed by an applet that implements a known tariff algorithm. Indeed, the energy supplier might well have written that applet and had it deployed onto the smart meter on its behalf. No fine-grained usage information needs to be sent to the energy supplier. WAN data transfer and storage requirements are also dramatically reduced.

Accurate account balance data can be presented to the customer on the in-house display using local LAN communications alone.

This processing would be performed by a credit billing applet such as billing applet 1001 in Figure 10.

Smart Grid

The electricity network operators might have a use for information on the quality of the electricity supply. Let us say that they are interested in how voltage and harmonics vary over the course of a week. Then an applet running on the smart meter can monitor the raw energy data and accumulate minimum, maximum and average values over time. Perhaps once a week this digested information could be packaged up, encrypted with a cryptographic key belonging to the network operator, and sent on to the operator. Little or no privacy-damaging information is included in such a digest.

This processing would be performed by an applet such as line quality applet 1003 in Figure 10.

Energy Management Services

A consumer could perhaps reduce their bills and energy consumption if they could receive advice from third-party energy management service companies who had access to the consumption data. This data does contain information about the lifestyle of the consumer. Good privacy practice (and European law) dictates that such data belongs to the consumer and should remain under their control. But the customer may choose to share this data, which remains on the smart meter. If the customer chooses, another program running on the meter could encrypt the data with a key belonging to the third- party energy management service company and send this to the company. Indeed, it may be that the customer could get better energy saving advice if the exported data was finer- grained than the half-hourly readings. If so, such a program could deliver the finer- grained consumption data.

On the other hand, the householder might voluntarily ask for his energy consumption patterns to be monitored in further detail. For example, the householder might offer up further data to an "energy management agent" in exchange for advice on how to reduce bills or identify inefficient appliances that could be replaced. In this case another applet would be deployed onto the smart meter. This might send finer-grained energy data to the energy management agent, or perform analysis of appliance behaviour within the smart meter. The energy management agent might be the energy retailer, or some other organization. The point is that this deeper inspection of energy use would be performed with the consent of the householder, under the terms of a contract agreed between the householder and the energy management agent. Data sent from this applet would be separate from the billing data sent to the energy supplier and would be protected by different cryptographic keys. This processing would be performed by an applet such as detailed usage applet 1004 in Figure 10. This applet, or another applet, may be provided to infer the identity of one or more appliances that consume a utility, for example inference of utilities in a household that consume electricity based on power consumption signatures of electrical appliances.

The householder might possibly enter into contracts with more than one energy management agent - one to provide detailed web-based energy consumption data and another to advise on replacing appliances, for example. Each would have separate applets, with the data secured by separate secure communications channels.

Advice to Consumers

The customer might also seek advice from third-party agents on changing energy tariffs or energy suppliers. It is possible that this could be facilitated by sending consumption data to the third-party energy management service company. However, applets could be devised that could run on the smart meter, analyse the data, and provide the advice without having to export the data from the meter at all. For example, the applet could have knowledge of all the tariffs available from all suppliers. It could apply each tariff to the customer's historical consumption data and identify the optimal tariff and supplier for the customer. The applet could make this result available to the customer. Such an applet would enhance the customer's privacy as consumption data would not leave the meter.

Research

Energy suppliers have argued that they need access to half hourly data from all customers to enable them to design and promote time of use tariffs, ensuring that customers are on the best tariff for them.

This research could be done if the energy retailer had access to half-hourly consumption data and could analyse this on their servers. It is also possible that this could be facilitated by sending consumption data to the third-party energy management service company who would conduct the research and provide the results to the energy supplier. However, applets could run on the smart meter, analyse the data, and provide the research results without having to export the raw data from the meter at all. Such an applet could be designed to aggregate and anonymise the consumption data before exporting it from the meter.

Such an applet would enhance the customer's privacy as consumption data would not leave the meter.

Settlement

In the UK energy market, settlement is the process by which energy generators and retailers exchange payments based on actual energy generated and consumed when this differs from amounts previously agreed by bilateral contracts. This energy is priced differently in each half -hour time-slot. Currently all consumers (in a particular category) are assumed to consume their energy in the same way, according to a general average consumption profile curves representing consumption over a 24-hour period. If energy retailers are to be properly rewarded for encouraging their customers to move to time-of-use tariffs then the settlement process needs to take account of the actual consumption profiles of their consumers. An applet running on the apparatus of the invention can be used to take into account a consumer's actual consumption without exporting sensitive half-hourly consumption data. For example, it could build up an energy consumption profile curve for each householder, averaged over a month. This curve could be encrypted with a key associated with a settlement organisation and exported to help in the settlement process. But this may still leak some privacy information, in particular - the average pattern of consumption over a day. Alternative schemes could be devised that exported still less data. For example, the settlement organization could broadcast a weighting curve to all meters (perhaps retrospectively, each month, to reflect actual electricity prices). The meters would multiply the actual consumption by the weighting curve and return a single "figure of merit", on a monthly basis, to the settlement organisation. The figure of merit could represent, for example, a ratio generated by comparing a utility consumption profile of a household to a national or other average. As before this would be encrypted with the key of the settlement organisation. This would be a proxy for the actual consumption data, and sufficient to improve the settlement process, and would leak almost no personal data.

Auditing

Another applet could perform an audit function in the event that a householder queried his bill. Utility consumption data may be stored in the apparatus for a storage period, for example one year, before being deleted or transferred for storage elsewhere. During that period the actual consumption data may be used to verify the accuracy of a bill relating to electricity consumption during the storage period. The source code of each of these applets could be made public. This would assure all parties that the operations being performed on the meter can in fact be trusted to do as they claim, and are not leaking any information above the minimum required, or cheating other stakeholders. Loading Applets from Devices

Consider a scenario in which a patient visits a doctor who decides that she should see daily weight and blood pressure measurements from the patient.

The doctor arranges this for the patient on an on-line booking service. Weighing scales and a blood pressure monitor are dispatched by a delivery service to the patient, and an appropriate applet is downloaded to the smart meter. The patient opens the package, switches on the weighing scales, which establish communications with the smart meter telecommunications hub and exchange messages with the telehealth applet. The telehealth applet returns the data to the doctor over a secure communications channel, and the doctor monitors the patient's weight.

In this scenario the standard GlobalPlatform applet management protocols are used. An encrypted and signed applet is delivered over the WAN to the secure microcontroller, which first authenticates the server, then validates the applet, before installing and activating the applet under control of the GlobalPlatform back-end. In the general case applets might be large and the WAN communications channel might be slow, have long latency, and it might be expensive to transfer data through this channel. If this is the case then applets could be deployed onto the smart meter telecommunications hub by some other channel. Another channel exists, with reasonable speed, low latency and zero cost, and that is the LAN channel between the device and the meter.

That is, it would be possible for the device to transfer its own applet to the meter. The device and the GlobalPlatform framework running on the secure microcontroller would perform the same mutual authentication protocol as if the smart meter were talking across the WAN to its server. The same sequence of commands would load the applet from the device, validate it, and enable it for operation.

Alternatively, the device would perform only some of the steps in the life-cycle of the applet. It would do the tasks that represented the heavy comms traffic - particularly the task of loading the applet to the smart meter. The smart meter and the back-end server could then execute the protocols that validated the applet and enabled it for operation.

Note that the mechanism described here also provides a secure way to commission smart meters during installation and servicing. In this case the device would typically be a hand-held commissioning tool possessed by the energy supplier's operative. The device and the meter would mutually authenticate each other and then the device could provision the meter with the necessary applets, and activate these as appropriate. The commissioning tool would of course need to be implemented with a secure microcontroller.

By extension, the processes described here could be used to any other "machine to machine" application where secure microcontrollers and GlobalPlatform-type software management were implemented.

A Practical Implementation

There is a need to extend the current smart card communications model which is shown in Figure 21. This model is defined by ISO 7816. Current implementations of GlobalPlatform protocols involve a smart card (SIM card or credit card for example) inserted into a terminal (a mobile phone or a chip and PIN terminal in a shop). The terminal sends commands to the smart card which processes these and returns responses. As appropriate messages are exchanged between the terminal and a distant server across a WAN, to validate messages generated by the smart card. The smart card is the secure microcontroller; the terminal is typically not.

The present invention may add local devices which also need to communicate with applets - both energy meter devices and value-added service devices. Message flow is more complex as messages can be initiated by the server or by devices, and a message sequence initiated by one actor (the server for instance) might then require an exchange of messages with another actor (a device for instance).

The present invention may add a "virtual terminal" implemented within the secure microcontroller. This receives messages from local and remote sources and routes these to the appropriate applets using standard commands and responses. This is shown in Figure 22, which shows an arrangement where the virtual terminal has been added.

An exemplary Telecommunication Hub in one implementation is shown in Figure 23.

A secure microcontroller acts as a slave to a conventional microcontroller, which routes messages between the virtual terminal and the appropriate WAN or LAN communications subsystem.

It is worth noting that the SIM card conventionally associated with the GPRS modem shown in this figure can in fact be implemented as yet another applet within the secure microcontroller.

A second implementation is shown in Figure 24. This dispenses with the conventional microcontroller. This pattern of increasing integration could be continued, with the secure micro chip eventually mopping up the WAN and LAN interfaces as well.

Summary

The invention described herein uses secure microcontroller, GlobalPlatform and Java Card technologies in a novel way to provide a high-quality secure computing platform within a smart meter. Furthermore, the use of multiple Java Card applets and secure communications channels offers solutions to the privacy problems: raw energy measurements can be processed by code placed in the public domain for inspection, and the cryptographically signed results returned to authorised parties can be trusted by these parties. Thus, for example, the smart meter needs only release a single monthly billing figure to the energy supplier. Additional data could be released, but only with the permission of the householder, and only to parties that the householder contracts with.

Finally, by enabling the secure deployment and management of new application programs, the invention provides an extensible platform capable of supporting a range of value-added services which will improve the economics of the smart meter programmes, and which will provide valuable services to householders and additional benefits to society as a whole.

The invention has been discussed primarily with respect to consumption of electricity, however it will be appreciated that the methods described herein can equally be applied to consumption of water or gas supplied to a household.

Consumption of water and gas can be measured using techniques that are well known to the skilled person, for example based on use of water and gas meters. Water and gas consumption, in particular water consumption, may be measured at a lower rate, for example at least once every 300 seconds or at least once every 60 seconds, in order to generate water consumption data that may be used to identify events associated with consumption of water. The rate of flow of water or gas at each time interval may be measured, along with the total volume consumed over time in a manner analogous to power and energy measurements of electricity consumption. Additionally or alternatively, water and gas consumption may be measured at measurement points after intervals of volume consumption rather than intervals of time, for example a measurement of time elapsed for each unit volume (e.g. litre) of water to be consumed. The apparatus described above may be implemented at least in part in software. Those skilled in the art will appreciate that the apparatus described above may be implemented using general purpose computer equipment or using bespoke equipment. The hardware elements, operating systems and programming languages of such computers are conventional in nature, and it is presumed that those skilled in the art are adequately familiar therewith. Of course, the server functions may be implemented in a distributed fashion on a number of similar platforms, to distribute the processing load. Here, aspects of the methods and apparatuses described herein can be executed on a computing device. Program aspects of the technology can be thought of as "products" or "articles of manufacture" typically in the form of executable code and/or associated data that is carried on or embodied in a type of machine readable medium. "Storage" type media include any or all of the memory of the apparatus, or associated modules thereof, such as various semiconductor memories, tape drives, disk drives, and the like, which may provide storage at any time for the software programming. All or portions of the software may at times be communicated through the Internet or various other

telecommunications networks. Such communications, for example, may enable loading of the software from a computer or processor into the apparatus. Thus, another type of media that may bear the software elements includes optical, electrical and

electromagnetic waves, such as used across physical interfaces between local devices, through wired and optical landline networks and over various air-links. The physical elements that carry such waves, such as wired or wireless links, optical links or the like, also may be considered as media bearing the software. As used herein, unless restricted to tangible non-transitory "storage" media, terms such as computer or machine "readable medium" refer to any medium that participates in providing instructions to a processor for execution.

Hence, a machine readable medium may take many forms, including but not limited to, a tangible storage carrier, a carrier wave medium or physical transaction medium. Nonvolatile storage media include, for example, optical or magnetic disks, such as any of the storage devices in computer(s) or the like, such as may be used to implement the apparatus shown in the drawings.

Volatile storage media include dynamic memory, such as the main memory of a computer platform. Tangible transmission media include coaxial cables; copper wire and fiber optics, including the wires that comprise the bus within a computer system. Carrier- wave transmission media can take the form of electric or electromagnetic signals, or acoustic or light waves such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media therefore include for example: a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD or DVD-ROM, any other optical medium, punch cards, paper tape, any other physical storage medium with patterns of holes, a RAM, a PROM and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave transporting data or instructions, cables or links transporting such a carrier wave, or any other medium from which a computer can read programming code and/or data. Many of these forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to a processor for execution.

Those skilled in the art will appreciate that while the foregoing has described what are considered to be the best mode and, where appropriate, other modes of performing the invention, the invention should not be limited to specific apparatus configurations or method steps disclosed in this description of the preferred embodiment. It is understood that various modifications may be made therein and that the subject matter disclosed herein may be implemented in various forms and examples, and that the teachings may be applied in numerous applications, only some of which have been described herein. It is intended by the following claims to claim any and all applications, modifications and variations that fall within the true scope of the present teachings. Those skilled in the art will recognize that the invention has a broad range of applications, and that the embodiments may take a wide range of modifications without departing from the inventive concept as defined in the appended claims.

Claims

Claims:

1. Utility consumption data processing apparatus comprising a data store, a data processor and a first interface, wherein:

the apparatus is configured to receive consumption data of a utility;

a plurality of different programs are stored in the data store, each of the plurality of different programs being configured to cause the data processor to process the utility consumption data to generate a different output derived from the utility consumption data, whereby at least part of the utility consumption data is not derivable from each of the different outputs; and

2. Apparatus according to claim 1 wherein each of the plurality of different programs is configured to cause the data processor to secure the respective different outputs derived from the utility consumption data; and

3. Apparatus according to claim 2 wherein each of the plurality of different programs is configured to cause the data processor to secure the utility consumption data.

4. Apparatus according to claim 2 or claim 3 wherein each of the plurality of different programs is configured to cause the data processor to secure the respective different outputs derived from the utility consumption data from the other ones of the plurality of different programs.

5. Apparatus according to any one of claims 2 to 4 wherein the first interface is configured to securely send each of the different outputs to a respective different remote computer, whereby each of the different outputs is secured against access by other ones of said different computers.

6. Apparatus according to any one of claims 2 to 5 wherein each of the plurality of different programs is configured to cause the data processor to use one or more cryptographic keys of said different program to cryptographically secure the respective different output.

7. Apparatus according to any one of claims 2 to 6 wherein the received utility data is secured and each of the plurality of different programs is configured to allow the data processor to access a part of the received utility data required to produce the different output of said program.

8. Apparatus according to any preceding claim wherein the apparatus is comprised within a utility meter and the utility consumption data is generated by the utility meter.

9. Apparatus according to any of claims 1-7 wherein the apparatus is configured to receive consumption data of a utility from a utility meter that is physically separate from the apparatus.

10. Apparatus according to any one of claims 1 to 7 or 9, the apparatus further comprising a second interface, wherein:

the second interface is configured to receive utility consumption data.

11. Apparatus according to claim 10 wherein the second interface is configured to securely receive utility consumption data.

12. Apparatus according to any preceding claim wherein one of said different remote computers is a computer of a utility provider providing the utility to which the received utility consumption data relates.

13. Apparatus according to any preceding claim wherein

the apparatus is configured to receive further data; at least one further program is stored in the data store, each further program being configured to cause the data processor to process different further data to generate a different further output; and

14. Apparatus according to claim 13 wherein each of the further programs is configured to cause the data processor to secure the respective different further output; and

the first interface is configured to securely send each of the different further outputs to a respective different remote computer.

15. Apparatus according to claim 13 or claim 14 wherein each of the different programs and further programs is configured to cause the data processor to secure their respective different output or different further output from the other ones of the plurality of different programs and further programs.

16. Apparatus according to any one of claims 13 to 15 wherein the first interface is configured to securely send each of the different outputs and different further outputs to a respective different remote computer, whereby each of the different outputs and different further outputs is secured against access by other ones of said different computers.

17. Apparatus according to any one of claims 13 to 16 wherein each of the plurality of different programs and further programs is configured to cause the data processor to use one or more cryptographic keys of said different program or further program to cryptographically secure the respective different output or different further output.

18. Apparatus according to any one of claims 13 to 17 wherein said further data comprises further utility consumption data.

19. Apparatus according to claim 18 wherein said further data comprises gas consumption data.

20. Apparatus according to any one of claims 13 to 17 wherein said further data comprises telecare data.

21. Apparatus according to any preceding claim wherein the utility consumption data is electricity consumption data.

22. Apparatus according to any preceding claim wherein one of the different programs is configured to cause the data processor to process the utility consumption data to generate utility consumption billing data.

23. Apparatus according to any preceding claim wherein one or more of the different programs are configured to cause the data processor to process the utility consumption data to generate one or more of settlement data; line quality data from electricity consumption data; auditing data; inference of utility-consuming appliances in the household; and data relating to utility consumption patterns.

24. Apparatus according to any preceding claim wherein at least one of the outputs is sent to a remote computer which is a server.

25. Apparatus according to any preceding claim wherein the apparatus is configured to store the utility consumption data in the data store or in another memory.

26. Computer program code which when run on a computer causes the computer to act as apparatus according to any preceding claim.

27. A carrier medium carrying computer readable code which when run on a computer causes the computer to act as apparatus according to any one of claims 1 to 25.

28. A computer program product comprising computer readable code according to claim 27.

29. An article of manufacture comprising:

a machine-readable storage medium; and

executable program instructions embodied in the machine readable storage medium that when executed by a programmable system causes the system to act as an apparatus according to any one of claims 1 to 25.

30. A method of evaluating utility consumption of a plurality of locations wherein each location receives a discrete utility supply, the method comprising the steps of: for each of the plurality of locations, generating a profile of utility consumption over a period of time from measurements of utility consumption at a plurality of intervals of the period; generating a specific average profile of utility consumption from the plurality of profiles of utility consumption over time; and determining a difference between the specific average profile of utility consumption and a general average profile of utility consumption over time.

31. A method according to claim 30 wherein the period of time is a day.

32. A method according to claim 30 or claim 31 wherein the profile of utility consumption for a location is an average of a plurality of profiles of utility consumption for a corresponding plurality of time periods.

33. A method according to claim 30 comprising the further step of generating a value representative of the difference between the specific average profile and the general average profile.

34. A method according to any of claims 30-33 comprising the further step of determining a difference in cost of utility consumed between the specific average profile and the general average profile.

35. A method according to claim 34 wherein the price of electricity per interval is not a constant.

36. A method according to any of claims 30-35 wherein the difference between the specific average profile and the general average profile is determined at a location that is local to a utility meter generating the measurements of utility consumption at the plurality of time intervals.

37. A method according to claim 36 wherein the difference between the specific average profile and the general average profile, or a value derived therefrom, is transmitted to a remote computer.

38. Computer program code which when run on a computer causes the computer to perform the method according to any one of claims 30 to 37.

39. A computer program product comprising computer readable code according to claim 38.

40. An article of manufacture comprising:

a machine-readable storage medium; and

executable program instructions embodied in the machine readable storage medium that when executed by a programmable system causes the system to perform the method according to any one of claims 30 to 37.

41. A method of installing a device related program into a data processing apparatus comprising a data store, a data processor and a first interface, comprising the steps of: transferring an encrypted and signed copy of the program from the related device to the data store of the data processing apparatus through the first interface;

validating the stored copy of the program using the data processor; and enabling the stored copy of the program using the data processor.

42. The method according to claim 41 wherein the first interface is connected to a local network and the device is configured to automatically transfer the encrypted and signed copy of the program from the device to the data store of the data processing apparatus through the first interface using the local network.

43. The method according to claim 42 wherein the device is configured to

automatically begin the transfer when the device detects the local network.

44. The method according to any one of claims 41 to 43 wherein the data processor validates the stored copy of the program using data transferred to the data processing apparatus from the device.

45. The method according to any one of claims 401 to 43 wherein

the data processor validates the stored copy of the program using data exchanged between the data processing apparatus and a remote computer.

46. The method according to any one of claims 41 to 45 wherein the apparatus further comprises a second interface;

the program being configured to cause the data processor to establish a secure communications channel between the device and the remote computer, the secure communications channel passing through the data processing apparatus.

47. The method according to claim 46 wherein the data processor validates the stored copy of the program using data exchanged between the data processing apparatus and a remote computer through the second interface.

48. Computer program code which when run on a computer causes the computer to perform the method according to any one of claims 41 to 47.

49. A carrier medium carrying computer readable code which when run on a computer causes the computer to perform the method according to any one of claims 41 to 47.

50. A computer program product comprising computer readable code according to claim 49.

51. A computer- implemented apparatus comprising:

a data store;

a data processor; and

a first interface;

wherein the apparatus is configured to:

validate the stored copy of the program using the data processor; and

enable the stored copy of the program using the data processor.

52. An article of manufacture comprising:

a machine-readable storage medium; and

executable program instructions embodied in the machine readable storage medium that when executed by a programmable system causes the system to perform the method according to any one of claims 41 to 47.