FIELD OF THE INVENTION

The present invention relates to control of a utility. In particular, the invention relates to a utility supply controller, to a utility supply system and to a method of controlling supply of a utility.

BACKGROUND OF THE INVENTION

The inventors are aware of remote controlled electrical switches that are used in domestic and other electrical power supply installations. However, the inventors identified a need for an intelligent utility supply controller that can be applied to any utility, but also specifically to electricity.

In this specification, the term "utility" is used to refer to a resource such as electricity, gas, water, or the like, which is distributed from a central supplier to a remote user. Although the invention is specifically aimed at electricity supply at remote charging stations, the invention is not limited to this application.

The present invention aims to address this need.

SUMMARY OF THE INVENTION

According to a first aspect of the invention, there is provided a utility supply controller, which includes

a local wireless interface, operable to communicate with a user identity device; a network interface, operable to communicate to a remote server on which a user's information is hosted;

a processor connected to the local wireless interface and the network interface, operable to read a user's identity from a user identity device, to forward transaction details to a remote utility server, to receive instructions from the remote utility server, to dispense a utility and to control dispensing of a utility to the user; and a utility interface, operable to control a utility electricity supply under instruction from the processor.

The local wireless interface may be in the form of a near field communication (NFC) interface, a Bluetooth Low Emission (BLE) interface, a radio- frequency identification (RFID) interface, an 802.1 1x interface, a WiFi interface, a mobile telephone network data interface or the like.

The processor of the utility supply controller may be operable in three modes, including:

- a reader/writer mode, in which the processor is operable to read a user identity device in the form of a NFC type tag, or through data transfer via a device or such like;

- a peer-to-peer mode, in which the processor is operable to exchange data with a matched NFC device, or pairing through WiFi or Bluetooth interface; and

- a card emulation mode, in which the processor is operable to exchange data with a user identity device which emulates a contactless smart card.

According to a further aspect of the invention, there is provided a utility supply system, which includes

at least one utility supply controller, as described above;

at least one user identity device, associated with a particular user and operable to communicate with the at least one utility supply controller;

a utility server on which at least one user's information is stored and from which a transaction can be approved, the server operable to communicate with the at least one utility supply controller to authenticate a user and to charge a user account with electricity supplied via the at least one electricity supply controller.

The user identity device could be in the form of any one of a mobile telephone, a radio frequency identification device, of the like, operable to store a user's identity details, such as a username of a user and a hash value of a user password. The user's identity details may be pre-registered or may be registered at a later stage.

In the embodiment where the user identity device is in the form of a mobile telephone, the user identity device may include an application which may be downloaded from a third party application library. The application may be operable to access the Internet through a TCP/IP protocol, to access a global positioning receiver of the mobile telephone, and a network interface of the mobile telephone, thereby to communicate with a utility supply controller, via a matched interface.

Each user identity device may be associated with a particular user by any one of: a biometric scan (e.g. fingerprint scan, facial scan, retina scan etc.), a unique subscriber identity or the like.

It is to be appreciated that the utility supply controller is not a source of the utility, but merely controls dispensing of the utility to a user.

The invention extends to a method of controlling supply of a utility to a user, the method including the steps of:

reading a user identity device on a utility supply controller located at a point of utility supply to retrieve a user's identity from the user identity device;

confirming transaction details of a user transaction on a remote utility server; upon successful confirmation of the transaction details instructing the utility supply controller from the remote utility server to dispense a utility in accordance with the transaction details; and

enabling the utility supply controller to dispense the utility to a user associated with the user identity device at a point of utility supply.

In one embodiment of the method, in which a utility supply controller is connected to a remote utility server, the step of reading a user identity device may include receiving user identity credentials from a user identity device onto a utility supply controller. The step of confirming transaction details may then include reading details of a utility supplier and transmitting these details together with the user identity credentials via a network interface to a remote utility server for confirmation. The step of confirming the transaction details may then include receiving confirmation from the remote utility server of a financial transaction confirmation. The method may then include dispensing the utility according to the transaction details that were confirmed. In another embodiment of the method, in which a utility supply controller is not connected to a remote utility server, but the user identity device is connectable to a remote utility server via the Internet, the step of reading a user identity device may include loading details of a utility supplier onto a user identity device. The step of confirming transaction details may then include transmitting details of a utility supplier together with the user identity credentials to a remote utility server via a user identity device. This step may include transmitting the details via a mobile telephone network, a satellite network, or the like, to which the user identity device has access. The step of confirming the transaction details may then include receiving confirmation from the remote utility server of a financial transaction confirmation via the user identity device and passing confirmation from the user identity device to the utility supply controller via the local wireless interface. The method may then include dispensing the utility according to the transaction details that were confirmed.

The invention is now described, by way of non-limiting example, with reference to the accompanying figure(s).

FIGURE(S)

In the figure(s):

Figures 1 shows a utility supply system in accordance with one aspect of the invention;

Figure 2 shows a method of controlling a supply of a utility in accordance with another aspect of the invention;

Figure 3 shows one embodiment of the method of Figure 2 in which Internet is available on the utility supply controller of the utility supply system in Figure 1 ; and

Figure 4 shows one embodiment of the method of Figure 2 in which no Internet is available on the utility supply controller of the utility supply system in Figure 1.

EMBODIMENT OF THE INVENTION

In Figure 1 , a utility supply system (10) is shown. The utility supply system (10) includes a utility supply controller (12), at least one user identity device (14), which is associated with a particular user (16), and a remote utility server (18). The user identity device (14) is operable to communicate with the at least one utility supply controller (12). At least one user's information is stored on the utility server (18) and the utility server (18) is operable to authenticate a user (16), to approve a transaction, to charge a user account and once approved/charged, to communicate with the at least one utility supply controller (12) to supply a utility via the utility supply controller (12).

The user supply controller (12) includes a local wireless interface (12.1 ) operable to communicate with the user identity device (14). The local wireless interface

(12.1 ) can in the form of any one of a Near Field Communication (NFC) device, a WiFi 802.x interface, or Bluetooth Low Emission (BLE) transceiver that communicates with the user identity device (14). The user supply controller (12) further includes a network interface (12.2), operable to communicate to a remote server on which a user's information is hosted. The network interface (12.2) is in the form of an Ethernet interface or a Global Packet Radio Service (GPRS) interface operable to communicate on a public network such as the Internet. The user supply controller (12) also includes a processor (12.3) which is connected to the local wireless interface (12.1 ) and the network interface

(12.2). The processor (12.3) is operable to read a user's identity from a user identity device (14) via the local wireless interface (12.1 ), to forward transaction details to the remote utility server (18), via the network interface (12.2), to receive instructions from the remote utility server (18), via the network interface (12.2), to dispense a utility and to control dispensing of a utility to the user (16). The user supply controller (12) further includes a utility interface (12.4), operable to control a utility supply (20) under instruction from the processor (12.3). In this example, the utility to be dispensed is a supply of electricity. The user supply controller (12) further includes memory (12.5), a battery (12.6), a power supply unit (12.7) and a relay (12.8) by means of which the electricity supply (20) is switched to a user's electrical device (22).

As can be seen in Figure 2, in operation, the utility supply system (10) provides a method of controlling supply of a utility, which in this instance is a supply of electricity, to a user. The method includes reading a user identity device at 100 on a utility supply controller (12) located at a point of utility supply (20) to retrieve a user (16) identity from the user identity device (14). At 102, the utility supply controller (12) confirms transaction details of a user transaction on a remote utility server (18). At 104, the transaction details are confirmed and the utility supply controller (12) is instructed by the remote utility server (18) to dispense a utility in accordance with the transaction details. At 106, the utility supply controller (12) activates the relay (12.8) to dispense electricity from the electricity supply (20) to a user device (22) associated with the user identity device (14) at a point of utility supply.

In one embodiment of the method, in which the utility supply controller (12) is connected to a remote utility server (18), the step of reading a user identity device (14) may include receiving user (16) identity credentials from a user identity device (14) onto a utility supply controller (12). The step of confirming transaction details may then include reading details of a utility supplier (20) and transmitting these details at 102 together with the user identity credentials via a network interface (not shown) to a remote utility server (18) for confirmation. The step of confirming the transaction details may then include receiving confirmation at 104 from the remote utility server of a financial transaction. The method may then include dispensing the utility according to the transaction details that were confirmed.

In another embodiment of the method, in which the utility supply controller (12) is not connected to a remote utility server (18), but the user identity device (14) is connectable to a remote utility server (18) via the Internet (not shown), the step of reading a user identity device (14) may include loading details of a utility supplier (20) onto a user identity device (14). The step of confirming transaction details may then include transmitting details of a utility supplier (20) together with the user (16) identity credentials to a remote utility server (18) via a user identity device (14). This step may include transmitting the details via a mobile telephone network, a satellite network, or the like (not shown), to which the user identity device (14) has access. The step of confirming the transaction details may then include receiving confirmation from the remote utility server (18) of a financial transaction via the user identity device (14) and passing confirmation from the user identity device (14) to the utility supply controller (18) via the local wireless interface (12.1 ). The method may then include dispensing the utility according to the transaction details that were confirmed. In Figure 3, the method of Figure 2 is illustrated in more detail, where Internet connectivity is available on the utility supply controller (12) of the utility supply system (10).

In this example, the user identity device (14) is in the form of a mobile telephone, which includes a mobile application downloaded from a third party application library. The application is operable to access the Internet (not shown) through a TCP/IP protocol, to access a global positioning receiver of the mobile telephone, and a network interface of the mobile telephone, thereby to communicate with the utility supply controller (12), via a matched interface. It is to be appreciated that the application can also be downloaded onto other machines.

Each user identity device is associated with a particular user by either a biometric scan in the form of fingerprint scan or facial scan and a unique subscriber identity module (SIM). All user identity devices have a unique identity (or "Device Name") which is published and is displayed on the device to be visible externally.

In Figure 3, 100.1 refers to steps on the mobile application of the mobile telephone (14), 100.2 refer to steps on the utility supply controller (12) device and 100.3 refers to steps on the remote utility server (18).

At 1 10 ("Open_App") and 112 ("App_Device_Pair"), the user identity device (14) pairs with the utility supply controller (12) via a Bluetooth connection. This pairing is automatic, as the mobile application is set to "hand off automatically".

At 114 ("BearerRequest"), it is established which device will do the transaction. At 114, the user identity device (14) requests the utility supply controller (12) for a status on its internet connectivity by sending a connectivity request to the BearerReq Device at 116. If the Internet connectivity is active on the utility supply controller (12) execution is directed to 118, alternatively, if Internet connectivity is not available, execution is directed to 120 on Figure 4. The BearerReq Device responds with a Success or a Failure, indicating the status of the Internet connectivity. Referring to Figure 4, method steps 110, 112, 1 14 and 116 are exactly the same as for the method in Figure 3.

At 118 ("Give_Account"), the user identity device (14) pass the user's identity details to the utility supply controller (12), which receives it at 122. In particular, the user's username and unique subscriber number (or "Trans ID") is sent to the utility supply controller (12) device for encryption. This is sent to the utility supply controller (12) device along with the user's password hash and length of time ("LoT"), both the user password hash and TransID are encrypted with the server's public key. The user's username and LoT is sent in the clear. Decryption and returning a valid TransID will be used as authentication message in this step.

At 122 ("PassDevID"), a session ID is generated. Then, the session ID, the device ID and the information received is encrypted by the server public key. As the device ID is unique, this is used as the return identity.

At 124 ("AuthoriseTrans"), all data is encapsulated together with the public server key for transmission to the remote utility server (18, or "authentication server"). A bearer method code is added as a suffix to the encapsulated data to alert the remote utility server (18) which endpoint will conduct the first layer of de-encryption.

At 124, the utility supply controller (12) sends the user identity in the form of a hash value to the remote utility server (18).

At 126, the remote utility server (18) decrypts both messages using a private key for both the device and the user account. The account username and password hash is authenticated and a request is made using the account payment details.

At 126, the remote utility server (10) further combines the two components in order to create an association between the transaction and the user account. The device message (which includes the session ID and the LoT from the account) is encapsulated with an account public key. At 126 ("ServerAuth"), the remote utility server (18) validates the user identity details and requests payment authorization for the transaction, at 128, from a remote payment gateway (not shown). If the payment was unsuccessful the transaction is rejected with an appropriate error code. If the payment was successful, a confirmation message is sent to the utility supply controller (12) at 128 to activate the relay (128). Both the success and failure responses are re-encrypted.

At 128 ("StartRelay"), the encrypted data packet is decrypted using the private device key and the session ID is compared to the original. If these are identical, then this is used as an authentication message, and the LoT is used as the clock comparator. A clock is started and the relay is activated. If there is an interruption, the Usage Clock is recorded and the remote utility server (18) is notified If the Usage Clock equals the LoT booked, then the Usage Clock is sent to the remote utility server (18)

At 130 ("App_Notify"), the utility supply controller (12) notifies the user identity device (14) that the transaction was successful once decrypted. The user is visually notified of success or failure. The failure (or "reject") message will have a message code to notify the user of a suitable response.

At 132 ("NotifyServ"), a message is sent from the utility supply controller (12) to the remote utility server (18). In particular, the session ID and the Recorded Usage is encrypted using the server's public key and sent in the message. If the bearer is available, then it is used to send the message. If the bearer is not available, then the message sent via Bluetooth to the application at 156 in Figure 4. If no application is present, then the LoT default time will be used.

At 134 ("ServerUpdate"), the transaction details are recorded on the remote utility server (18). From the session ID, the user can now be charged against the usage or charged back.

In Figure 4, another embodiment of the method is shown. In this embodiment, no Internet is available on the utility supply controller (12) of the utility supply system (10). Accordingly, reference numerals 110 ("Open_App"), 1 12 ("App_Device_Pair"), 114 ("BearerRequest") and 116 ("BearerReqDevice") remain the same as in Figure 3. In Figure 4, 200.1 refers to steps on the mobile application, 200.2 refer to steps on the utility supply controller (12) device, 200.3 refers to steps on the remote utility server (18) and 200.4 refers to the steps on the payment end.

In Figure 4, if Internet connectivity was not available on the utility supply controller (12), execution is directed to 120 ("RequestDevID"). At 120, the device ID and the session ID are required in order to pass the acknowledgment back. Both IDs are encrypted to prevent authorisation of another device. The Trans ID will later allow the application to know it is for the same transaction and to map the authorisation/initialisation to.

At 140 ("PassDevID"), a unique session identity (or "SessionID") is then requested from the utility supply controller (12). The unique session identity generated, together with the device identity (or "DevicelD") are encrypted by the server public key.

At 142 ("AuthoriseTrans"), the user identity device (14) sends its user identity details directly to the remote utility server (18) in the form of a hash value. Notably, both the data for the device (trans ID) seeking authority to start and the user's username and password hash are required to authorise the payment. A bearer method code is added as a suffix to these to notify the remote utility server (18) at which endpoint to conduct the first layer of de-encryption.

At 144 ("ServerAuth"), the remote utility server (18) requests payment authorization for the transaction at 146 from a remote payment gateway (148, "Payment Service"). The remote utility server (18) decrypts both messages using its private key for both the device and the account. The account username and password hash is authenticated and a request is made using the account payment details. The server (18) must combine the two components in order create an association between the transaction and the user account. The device message (which is the session ID and the LoT from the acct) is encapsulated with the account public key. If the payment was unsuccessful the transaction is rejected with an appropriate error code. If the payment was successful, a confirmation message is sent to the user identity device (14) at 150.

At 150 ("PassThrough"), the confirmation message is received on the user identity device (14) which then passes the confirmation message to the utility supply controller at 152, which then activates the relay (12.8). This confirms that the request sent is the same as the request received before passing the encrypted authentication message onto the device. The user is notified on the application for both accept and reject.

At 152 ("StartRelay"), the packet is decrypted using the private dev key and the session ID is compared to the original. If the same, then this is taken as an authentication message. The LoT is used as the clock comparator. A clock is started and the relay is activated. If there is an interruption, the usage clock is recorded and the remote utility server (18) is notified. If the usage clock equals the LoT booked, then the usage clock is sent to the server.

At 154 ("NotifyServ"), the utility supply controller (12) notifies the user identity device (14) that the transaction was successful, which receives the message at 156 ("PassServer") and sends it on to the remote utility server (18) at 158 to confirm that the transaction was successful.

At 154, the notification sent includes the session ID and the recorded usage encrypted using the remote utility server's public key. If Internet (e.g. Wifi) is available then this step uses the Internet. If not, then the notification is sent via Bluetooth to the application. If no application is present on the mobile telephone, then the LoT default time will be used.

At 158 ("ServerUpdate"), from the session ID, the user can now be charged against the usage or charged back.

The inventors are of the view that the invention described herein provides a new utility supply controller, a new utility supply system and a new method of controlling supply of a utility. In particular, the inventors are of the opinion that the invention can be applied to electricity as a utility being provided by a third party.