GB2528911A

GB2528911A - Power system, apparatus and method

Info

Publication number: GB2528911A
Application number: GB1413791.3A
Authority: GB
Inventors: Dan Bladen
Original assignee: CHARGIFI Ltd
Current assignee: CHARGIFI Ltd
Priority date: 2014-08-04
Filing date: 2014-08-04
Publication date: 2016-02-10
Anticipated expiration: 2034-08-04
Also published as: WO2016020645A1; GB201413791D0; GB2528911B

Abstract

A power system 5 comprises a transmitter 13 to transmit an identifier of the transmitter; a charger 17 to wirelessly charge the battery of a mobile object 23; a controller 9 to activate the charger, and a server 3 to communicate with the controller. The mobile object receives the identifier of the transmitter and send a request comprising the identifier of the transmitter and a user identifier to the server. The server receives the request, determines whether an access condition is satisfied based upon the user identifier, and provides an access condition result to the controller. The mobile object may be a portable electronic device (mobile phone, tablet or laptop computer), or an electric vehicle (bicycle, scooter, car). A second identifier may be transmitted, indicating a venue or facility. The transmitter may be a beacon. The user of the mobile device may be provided with a geographical indication of one or more charging facilities.

Description

Intellectual Property Office Application No. GB1413791.3 RTN4 Date:28 May 20t5 The following terms are registered trade marks and should be read as such wherever they occur in this document: Bluetooth Wifi iBeacon Qualcomm Halo Rezence Zigbee Z-wave Intellectual Property Office is an operating name of the Patent Office www.gov.uk/ipo POWER SYSTEM, APPARATUS AND METHOD

INTRODUCTION

The present application relates to power systems, apparatus and methods and in particular but not exclusively to a systems, apparatus and method for delivery of wireless charging to mobile devices.

The wireless provision of power transfer by induction has been used in variety of devices over a number of years. For example, Nikola Tesla demonstrated wireless energy transmission by means of electrostatic induction using a high-tension induction coil in 1891, although it is only in more recent years that industrially applicable applications of this technology have been made.

Included in such recent implementations are devices that can provide for inductive, resonance, radio frequency and ultrasound charging of mobile battery-powered devices such as cellular telephones.

SUMMARY

Particular aspects and embodiments are set forth in the appended claims.

Viewed from one perspective, the present teachings can provide a power system comprising: a transmitter operable to transmit an identifier of the transmitter; a charger operable to wirelessly charge the battery of a mobile object; a controller operable to activate the charger; a server operable to communicate with the controller; a mobile object having a battery operable to be charged wirelessly, the mobile object operable to receive the identifier of the transmitter and send a request comprising the identifier of the transmitter and a user identifier to the server; wherein the server is operable to: receive the request; determine whether an access condition is satisfied based upon the user identifier; and provide an access condition result to the controller.

Thereby, wireless charging can be provided on demand to an authorised device or user in a manner consistent with principles of good energy management. Such provision may optionally be provided as an ancillary service to some other form of venue service provision.

Viewed from another perspective, the present teachings can provide a battery-powered movable device having a wireless charging capability, the device comprising: a receiver operable to receive a wireless signal comprising a transmitter identifier; a processor operable to generate a request to an authorisation server for provision of wireless charging, the request comprising the transmitter identifier and an account identifier; a transmitter operable to wirelessly transmit to the authorisation server a signal comprising the request; and a wireless charging receptor operable to receive wireless provision of power to recharge the battery of the movable device. Thereby an authorised device may be provided that can request and receive wireless charging in a flexible manner.

Viewed from another perspective, the present teachings can provide a power controller comprising: a server interface operable to receive from a remote server a message instructing activation of a wireless charging station associated with a beacon identifier; and a power control interface operable to activate a wireless charging station associated with the beacon identifier responsive to receipt of the message. Thereby a wireless charging infrastructure can provide activated charging stations upon demand for authorised users or devices while providing for effective and responsible power management within the infrastructure.

Viewed from another perspective, the present teachings can provide a charging control server, comprising: a communication interface operable to receive a request for wireless charging from a wirelessly-chargeable device located in proximity to a wireless charging station under the control of a local power controller, the request including a beacon identifier and an authorisation identifier; a processor operable to determine an authorisation result for the authorisation identifier; the communication interface further operable to transmit, in dependence upon the authorisation result, a message to the local power controller instructing activation of a wireless charging station associated with the beacon identifier. Thereby a wireless charging infrastructure can be efficiently managed to provide distributed wireless charging on demand to authorised users and devices while providing for effective and responsible power management within the infrastructure.

Viewed from another perspective, the present teachings can provide a method of providing wireless charging to a movable device having a wireless charging capability, the method comprising: providing to a user of a movable device having a wireless charging capability a geographical indication of one or niore wireless charging facilities; providing, using a first wireless communication beacon of a wireless charging facility, to a user of the movable device having a wireless charging capability a notification when approaching the wireless charging facility; providing, using a second wireless communication beacon of the wireless charging facility, an indication of availability of conditional access to wireless charging; providing, from a manager device of the wireless charging facility, confirmation of the availability of the conditional access to wireless charging; and activating, by the manager device a wireless charging source for use by the movable device having a wireless charging capability. Thereby a wireless charging infrastructure can be efficiently operated to provide distributed wireless charging on demand to authorised users and devices while providing for effective and responsible power management within the infrastructure.

Viewed from another perspective there can be provided a method of providing wireless charging to a movable device having a wireless charging capability, the method comprising: receiving, from a wireless communication transmitter of a wireless charging facility, an indication of availability of conditional access to wireless charging; sending a request for access to wireless charging at the wireless charging facility; receiving, from a wireless charging source activated by a manager device of the wireless charging facility, wireless charging to a movable device having a wireless charging capability. Thereby an authorised device may be request and receive wireless charging in a flexible manner from a distributed wireless charging architecture.

Further implementations and approaches will become apparent from the following detailed description which provides implementational examples of the present teachings.

BRIEF DESCRIPTION OF THE FIGURES

Detailed description of various implementations demonstrating the present teachings will be set out, making reference to the accompanying drawings, in which: Figure 1 illustrates schematically a power provision environment; Figure 2 illustrates steps in a process for activating a wireless charging facility; Figure 3 illustrates steps in an alternative process for activating a wireless charging facility; Figure 4a illustrates steps in a first process for deactivating a wireless charging facility; Figure 4b illustrates steps in a first process for deactivating a wireless charging facility based upon an altered infrastructure arrangement; Figure 5a illustrates steps in a second process for deactivating a wireless charging facility; Figure Sb illustrates steps in a second process for deactivating a wireless charging facility based upon an altered infrastructure arrangement; Figure 6a illustrates steps in a third process for deactivating a wireless charging facility; and Figure 6b illustrates steps in a third process for deactivating a wireless charging facility based upon an altered infrastructure arrangement.

While the present teachings are susceptible to various modifications and alternative forms, specific embodiments are shown by way of example in the drawings and are herein described in detail. It should be understood, however, that drawings and detailed description thereto are not intended to limit the scope of protection to the particular form disclosed, but on the contrary, the scope is to include all modifications, equivalents and alternatives falling within the spirit and scope of the appended claims.

DETAILED DESCRIPTION

An example infrastructure for provision of wireless charging is illustrated in Figure 1. In this example structure, a charging infrastructure 1 has a remote service 3, which in the present examples may take the form of a remote authentication, authorisation and account management service. The remote service 3 may be provided by a dedicated server arrangement running software or having configured hardware and/or firmware to provide the service or may be provided as a hosted service from a general purpose cloud provider facility.

The remote service 3 communicates to one or more charging venues or facilities 5 via associated communications channels 7. The communications channel may be a standard internet or other WAN communications channel and may be formed as an encrypted or tunnelled channel to provide security for the transfer of authentication and/or account management information to and from the remote service 3.

Communication to and from the remote service 3 over the communications channel 7 is handled at the charging facility or venue 5 by a controller 9. In the present examples, when a controller 9 sends a message to the remote service 3, it establishes or utilises an existing virtual private network (VPN) tunnel for the communications channel 7. The controller 9 may also use this communication channel to provide status and/or operational information relating to the remote service 3. For example, the controller 9 may provide to the remote service 3 information relating to the power supply to the controller (including remaining battery life if the controller is battery powered, or regularity of mains or charging supply if the controller is mains powered), the operating temperature and/or ambient temperature of the controller, and/or the current total power draw from all chargers under control of the charger. The communications channel 7 may be any suitable data connection between the controller 9 and the remote service 3. Examples of suitable data connections include a wired or wireless data link that may include a connection from the controller 9 to the Internet or other WAN and a connection from the Internet or other WAN to the remote service 3. Data services such as a WFi network of a building or zone into which the controller is installed, a cellular data service such as a GPRS, 2G, 3G, 4G etc may be used.

The controller 9 of the charging facility or venue 5 interfaces with a number of charging nodes 11. Each charging node has a wireless beacon 13 and a charger 17. In some examples, the wireless beacon 13 may have no communication channel to or from the controller 9. In other examples, the wireless beacon 13 may be controlled as to adopting an active or inactive state by the controller 9 using a channel 15. In some examples, the wireless beacon 13 may be alternatively or additionally operable to provide status information for the beacon 13, such as an indication of fault-free operation and/or a fault indication to the controller 9 via a channel 15. If a channel between the controller 9 and wireless beacon 13 is used, the channel may be a wired or wireless channel, and if a wireless channel is used it may utilise a wireless technology such as Bluetooth or Wfi (IEESO2.1 1). The charger 17 is triggered to be active or inactive by a control signal 19 from the controller 9. The control signal may be issued directly to the charger 17 or may be issued by way of controlling a power source that supplies power to the charger 17 that the charger is then able to pass on to a device being charged.

In the present examples, the charger 17 may be able to communicate with the controller 9 via a two-way communication over channel 15. For example, if a wirelessly chargeable device is at or reaches through provision of charging a fully charged state, then the wireless charger may be configured to detect this and could power down into a lower voltage mode. In an example where the charger is able to communicate to the controller, the charger can communicate this powered-down status of the charger and control a cessation of charging to that device and/or enter a low power state if no other charging sessions are active or no other active sessions require controller input.

The charger 17 of the present examples is a wireless charger that uses any suitable wireless energy transfer technology to pass energy from the charger to a wirelessly chargeable device positioned close to the charger. Such wireless energy transfer methods may include inductive coupling, resonance, radio frequency and ultrasound technologies. The charger 17 will be selected for a given implementation based upon the nature of the wirelessly chargeable devices to be charged by the charger. As discussed below, a variety of different wirelessly chargeable devices may be serviced using the approach of the present teachings and it is envisaged that a different charger would be deployed for charging mobile telephones to that deployed for charging electric vehicles. Where relevant standards exist for wireless charging devices and chargers, the chargers deployed in the wireless charging infrastructure may be compliant with one or more relevant standards. One example of a charging standard that may be relevant to a charger deployed for charging portable electronic devices such as mobile telephone, tablets or the like includes the Qi standard. Further examples of charging standards that may be suitable for devices such as, for example, mobile phones, tablets, phablets and laptops include the Rezence (Alliance for Wireless Power -A4WP) and PMA (Power Matters Alliance) standards. An illustrative example of a charging standard that may be suitable for electronic vehicles is Qualcomm Halo.

Each wireless beacon 13 broadcasts an identifier code within its communication range 21. In the present examples, each wireless beacon 13 is able to transmit first and second identifier codes and uses Bluetooth to transmit the codes. In some implementations, the beacons may be a so-called iBeacon utilising Bluetooth Low Energy (also known as Bluetooth Smart, BluetoothLE or BLE) technology. In the case of an iBeacon, the first beacon identifier code may be transmitted as the iBeacon major value and the second beacon identifier code may be transmitted as the iBeacon minor value. The transmission range 21 may be the same for the first and second codes or may be different for the two codes. In some examples, the transmission technology may be different as between the two codes, with the first code transmitted using, for example, Bluetooth and the second code transmitted via near field communication (NFC). Any suitable alternative to Bluetooth may also be used, such as alternative microlocation/triangulation or wireless personal area network (WPAN) technologies such as Z-Wave or ZigBee. In some examples, each beacon may transmit only a single identifier code, with some beacons transmitting only a first beacon identifier code and some beacons transmitting only a second beacon identifier code. In some examples, the beacon may be a two-way transmitter operable to receive data as well as transmit an identifier code. In such examples the beacon could be part of a communication channel between the controller and an object receiving the beacon identifier code. Some beacons may also transmit a third beacon identifier code such as a UUID (universally unique identifier). Whereas the first and second beacon identifier codes discussed above would be configurable to transmit codes required of the system as implemented for a particular charging infrastructure or venue/facility, the UUID would typically be set by the manufacturer of the beacon. This UUID could be used for example by the controller to detect for each beacon that the controller has recorded as being a pad of the system at the facility/venue whether that beacon is functioning, monitor and detect its battery life and/or detect the distance of the beacon from the controller.

The wireless charging facility or venue 5 may also have one or more beacons 13 not associated with a charging node 11. Such an additional beacon 13 may be configured to transmit only the first identifier code. In such an example, one or more of the wireless beacons 13 belonging to a charging node 11 may be configured to transmit only the second identifier code.

Thus a technology structure for the provision of wireless charging has been provided with respect to Figure 1. With continued reference to Figure 1, an overview of the interaction of a wirelessly chargeable device with the charging technology infrastructure will now be provided.

As shown in Figure 1, a wirelessly chargeable portable device 23 may be moved into proximity with a charger 17 so as to receive wireless transfer 27 of energy from the charger to the device 23.

The wirelessly chargeable device 23 may be any form of movable device having a rechargeable battery and a capability for that battery to be charged wirelessly. Examples of devices that may be moved around and charged in this way include mobile telephones, tablets, phablets, netbooks, laptops computers, navigation devices, headphones and microphones, portable music and/or video players, and battery powered vehicles such as electric bicycles, mobility scooters or electric vehicles. The wireless charging capability may be inherent to the device or may be provided by an accessory for the device. In the example of a mobile telephone, phablet or tablet, the device may not inherently have a wireless charging capability but such a capability may be added by placing the device into a suitably enabled case or holder or providing a suitably enabled attachment. Likewise, in the example of a netbook or laptop computer, a device lacking inherent wireless charging capability may be provided with this capability through use of a suitable case or wired accessory such as a dongle.

The wirelessly chargeable device may be configured with software, hardware and/or firmware to illustrate on a map or by other location indication on a display of the mobile device the relative position of the device to a charging facility or venue 5. For example the wireless device may be able to determine its current position based upon a satellite navigation receiver and/or cellular network positioning information. The position so determined can then be used to indicate location relative to one or more charging facilities or venues 5 based upon having available information describing the locations of such charging facilities or venues. The location information for the charging facilities or venues may be stored by the mobile device or may be accessible to the mobile device via a data connectivity connection (such as a cellular data technology such as GPRS, 3G, 4G etc) to a data store that holds such information. Such a data store may be provided by the remote service 3, which may be accessible to the device 23 via such a data connectivity connection. The functionality to display the relative position information may be provided by a dedicated application for the device, such as an app for a mobile telephone, phablet or tablet.

The wireless device 23 may be configured with software, hardware and/or firmware to enable the wireless device to receive signals 25 broadcast by the wireless beacons 13. For reception of the signals, this will be a receiver matching the transmission technology of the beacon, i.e. if the beacon utilises Bluetooth then the device will use a Bluetooth receiver to receive the beacon signal. The wireless technology of the beacon does not match the wireless technology of the wirelessly chargeable device, a wireless technology accessory may be used with the mobile device. For example if the beacons utilise Bluetooth and a wirelessly chargeable device does not have a Bluetooth capability, a Bluetooth accessory may be used with the device to provide that capability.

Once the wirelessly chargeable device 23 arrives within range of one of the beacons 13 of the wireless charging facility or venue 5, the wirelessly chargeable device receives the beacon identifier code. The beacon transmitting the code received by wirelessly chargeable device 23 may be one or more of a beacon 13 associated with a charging node 11 or a separate beacon 13, for example a beacon 13 provided in proximity to an entry portal for the wireless charging facility or venue 5. In the present examples, the first beacon identifier code is an identifier associated with the wireless charging facility or venue 5 or with the controller 9. Thus a wirelessly chargeable device 23 receiving the first beacon identifier code receives an identifier for the overall charging facility. In the example where a facility is large and is subdivided between a number of separate controllers, the identifier may be an identifier for the controller controlling the part of the facility that has the beacon providing the signal which the wirelessly chargeable device has received. In other examples of large multiple controller facilities, the controllers may operate as a cluster such that a single facility identifier code applies to the whole facility.

In some examples, it is envisaged that the wireless charging facility or venue would be a facility or venue which a user of the wirelessly chargeable device may visit for reasons in addition or alternative to charging. For example, where charging of a mobile communication or computing device such as a mobile telephone, phablet, tablet, netbook or laptop is offered, the facility or venue may be a commercial premises that has other products or services for the user of the device. One example is for the venue or facility to be a café, coffee shop, bar or restaurant, such that the user of the device may be able to charge their device while consuming food or drink and/or while meeting with other people. Other examples of suitable facilities or venues might include cinemas or theatres (such that the mobile device can charge while the user watches a film or play), business centres (such that the mobile device can charge while the user conducts business activities), and airports (such that the mobile device can charge while the user waits for an airline departure or arrival). In the example where the wirelessly chargeable device is a vehicle, the facilities or venues might include a vehicle parking area associated with a commercial premises (such as a bicycle rack outside a café or coffee shop), a general parking area, such as a bicycle rack, shed or storage facility such located for example at a residential parking area, block of flats, park, office building or shopping mall, a car park for electric vehicles, a taxi rank, a petrol station, parts or sections of public or private highways such as at traffic lighted junctions or the approach to toll booths, vehicle storage or maintenance garages, or similar.

Once the wirelessly chargeable device 23 receives the first beacon identifier, the wirelessly chargeable device 23 can present on a display of the device an indication that the device has entered a wireless charging facility or venue 5 such that a user of the device may be made aware that wireless charging will be available in that facility or venue. In the present example, the communication between the wirelessly chargeable device and the beacon 13 is one-way (i.e. transmission by the beacon 13 and reception by the wirelessly chargeable device 23). The wirelessly chargeable device may be operable to transmit to the remote service 23 via a communications channel 29 information describing the reception by the wirelessly mobile device of the first beacon identifier. The communications channel 29 may be any suitable data connection between the wirelessly chargeable device 23 and the remote service 3. Examples of suitable data connections include a wired or wireless data link that may include a connection from the device 23 to the Internet or other WAN and a connection from the Internet or other WAN to the remote service 3. Data services such as a WiFi network of the wireless charging facility or venue 5, a cellular data service such as a GPRS, 2G, 3G, 4G etc may be used. Such a communications channel 29 may be secured by any suitable approach such as a VPN tunnel, an https or SSL connection or the like. In some examples, the communication between wirelessly chargeable device 23 and beacon 13 may be two-way communication such that the beacon may be able to provide to the controller 9, or provide to the remote service 3 via the controller 9 details of the wirelessly chargeable device that has entered the facility or venue 5.

In the present examples, the second beacon identifier code is an identifier for a particular charging node 11. Thus, once the wirelessly chargeable device 23 moves within range to receive the second beacon identifier code, the wirelessly chargeable device 23 is now sufficiently proximal to a charger for wireless charging to be offered to the device. In the present examples, the wirelessly chargeable device 23 provides an interface to offer the possibility of wireless charging to a user of the device. When the user selects that wireless charging should be used, the wirelessly chargeable device 23 communicates wirelessly 25 with the remote service 3 to send a wireless charging request. In the present examples this charging request is sent via the communications channel 29 from the wirelessly chargeable device 23 to the remote service 3. In alternative examples, it may be provided that the beacons are able to receive as well as transmit via bluetooth or such that the controller 9 may be able to communicate directly with the wireless chargeable device 23 and in such examples the request may be passed by the controller 9 to the remote service 3.

Upon receipt of the request by the remote service 3, the remote service 3 establishes whether the wirelessly chargeable device 23 is entitled to receive access to wireless charging at the charging venue or facility 5. In the present examples, the determination of eligibility is based upon eligibility of the device and/or eligibility of a user account associated with the device. That is, an account or authorisation pass for receiving wireless charging may be associated with a particular device, or may be associated with a user. To make the determination, an appropriate identifier is included in the request sent from the wirelessly chargeable device 23 to the remote service 3. This identifier may be a device identifier, a user identifier or both, depending on the authorisation approach in use. It is envisaged that some users may be authorised on a per device basis and other users be authorised on a per account basis within a single implementation of the present teachings.

In the present examples, the request sent from the wirelessly chargeable device 23 to the remote service 3 also includes the first beacon identifier code or some other data representative of the information conveyed by the first beacon identifier code. The inclusion of this code provides a number of functions to the system. By including the first beacon identifier code, the remote system 3 knows to which charging facility or venue 5 and hence which controller 9 the authorisation response should be sent. By inclusion of the first beacon identifier, the remote system 3 can also optionally include the particular charging facility or venue 5 in establishing the authorisation determination. For example, a device or user account may have entitlement to access wireless charging on a geographic basis, for example some devices or users may subscribe for access to wireless charging in just one region (such as a country, state or city), whereas other devices or users may subscribe for access to wireless charging in multiple regions. Inclusion of the first beacon identifier in the request allows this optional geographical element of a charging entitlement to be tested. In other examples, the request may include some other identifier of the charging facility or venue 5 in addition to or instead of the first beacon identifier code. An example of other data representative of the information conveyed by the first beacon identifier code could be that the wirelessly chargeable device 23 by itself or by communication with an external database (which may be hosted by or accessible via the remote service 3) is operable to use the first beacon identifier code to obtain a value describing the wireless charging facility or venue 5. Such a value could be a code, for example an alphanumeric code, for the facility or venue, or could be a facility or venue name or combined name and identifier number, for example "Named Coffee Shop London" or "Restaurant Chain branch 243".

In the present examples, the request sent from the wirelessly chargeable device 23 to the remote service 3 also includes the second beacon identifier code oi some other data representative of the information conveyed by the second beacon identifier code. The inclusion of this code provides a number of functions to the system. By inclusion of the second beacon identifier code, the remote system can include in an authorisation response to the controller 9 an indication of which charging node 11 the device has requested use of such that the controller may control the correct charger 17 to supply wireless charging to the device. Also and optionally, by inclusion of the second beacon identifier, the remote service 3 can be enabled to check whether the device from which the request was sent is compatible with the charger 17 at the associated charging node 11. For example, if a second beacon identifier code included in the request is associated with a charger 17 compatible only with mobile telephones, phablets and tablets and it is determined that the request was sent from a laptop computer, the authorisation result can be adjusted to take account of the technological mismatch. An example of other data representative of the information conveyed by the second beacon identifier code could be that the wirelessly chargeable device 23 by itself or by communication with an external database (which may be hosted by or accessible via the remote service 3) is operable to use the second beacon identifier code to obtain a value describing the charging node 11. Such a value could be a code, for example an alphanumeric code, for the charging node or charger, or could be a node name or number, for example "table 42" or "tablet station".

In some examples, where the request includes data representative of the information conveyed by each of the first and second beacon identifier codes, this data could be combined into a data value. Such a data value could be a code, for example an alphanumeric code, for the facility or venue and charging node or charger, or could be a facility or venue name or combined with a charging station identifier, for example Named Coffee Shop London table 42" or "Restaurant Chain branch 243 tablet station".

In examples where the request is passed via the controller 9 between being issued by the wirelessly chargeable device 23 and the remote service 3, the controller 9 may reformulate or alter the request as it passes through the controller 9 on its way to the remote service 3. In such an example, the remote service would receive in the request data identifying the device or user against which to perform authorisation and data indicating the correct controller to receive the authorisation response, but other functions such as the identifying which charging node is requested may be performed by the controller 9.

Once the controller 9 receives a positive authorisation result from the remote service 3, the controller 9 can then activate the charger 17 associated with the beacon 13 whose second beacon identifier code was included or represented in the request. At this time, wireless delivery of power to recharge the wirelessly chargeable device is provided.

In that it is envisaged that the wireless charging venue or facility 5 may have another purpose beyond provision of charging, it is also envisaged that the venue or facility may communicate to the wirelessly chargeable device while the wirelessly chargeable device is in the venue or facility. For example, a food and/or drink outlet hosting a wireless charging facility may communicate information associated with the outlet to the device. Examples may include provision of information relating to special offers or discounts available to the user of the device, which special offers or discounts may be applicable only to users of the wireless charging service. For example, it is envisaged that the controller 9, may have internet connectivity provided by connection to a public or visitor W-Fi service of the hosting outlet. The controller can use this internet connectivity for establishing communication with the remote service 3, but may also utilise the Wi-Fi service for communicating with a server of the hosting outlet to exchange information relating to number of active charging stations at any given time, user information about users with activated charging or the like. Such information may include ordering and/or payment information relating to the purchase of goods or services from or via the wireless charging venue or facility 5, for example by utilising a charging interface application of the wirelessly chargeable device 23. Such provision of information may be performed by sending the information via the remote service 3 to be delivered to the handset via the connection 29, or via the controller 9 to be delivered to the wirelessly chargeable handset via the controller 9 or remote service 3, or may be delivered over the W-Fi service at the hosting outlet.

The sharing of user information can be controlled according to prevailing laws and standards for exchange of customer information, and it is envisaged that the transferred information may be profile rather than or in addition to identity information. For example, a customer profile for a currently activated charging user may be used to target information provided by the hosting outlet or a third party such as a sponsor or advertiser to the user. Such information my include membership information of a venue loyalty program, advertising, coupons, vouchers, special offer details or the like. Other information might include details of a maximum charging node occupancy time per commercial transaction with the venue. Such an approach would facilitate a venue from preventing its primary commercial function being undermined by users utilising the charging facility and blocking space in the venue that might be desired by other persons wishing to conduct a financial transaction with the venue.

To terminate the provision of wireless charging to the wirelessly chargeable device 23, one of a number of options may be used. One approach is to establish when the wirelessly chargeable device moves too far from the charging node 11, such as when the wirelessly chargeable device is not in contact with any beacon of the venue or facility. In this example the device may communicate, upon detection that it is no longer receiving a signal from any beacon of the charging venue or facility 5, to the remote service 3 via communications channel 29 a message that indicates the charging should be ceased. Upon receipt of such a message, the remote service 3 may communicate to the relevant controller 9 an instruction for ceasing delivery of power to the charger 17 that had been activated for the wirelessly chargeable device 23. In an example where the communications channel 29 includes the controller 9, a message may be provided directly to the controller 9 from the wirelessly chargeable device that the charging is to be ceased. Another example would be based upon a maximum time or energy delivery restriction. Another example might relate to ceasing charging when an energy delivery source for the wireless charging is becoming depleted, for example if the charger is itself being fed from a chargeable battery (which could be the case in a café for example, to avoid a table needing to have a wired connection to a power source so as to provide wireless charging to a device on that table). A further example might be that the user of the device or the device itself requests that charging cease. For example, through software, hardware and/or firmware of the wirelessly chargeable device the device may be able to present to a user an option to cease charging and/or the device itself may request cessation of charging once a given battery level is reached (for example full battery or some other threshold set by, for example, power management software of the device).

Thus there has now been described an example of an infrastructure and approach for delivering wireless charging to a movable wirelessly chargeable device. By use of such an infrastructure and approach, a user of a wirelessly chargeable device may conveniently receive charging for their device without needing to bring with them a mains electricity power adapter and cable and without needing to find a location with publicly accessible or usable power outlets in which to plug the power adapter. Use of such an approach also facilitates the provision of value added services in the form of venue information, offers, advertising, ordering and payment.

Now, with reference to Figures 2 to 6, a number of examples of approaches for activating and deactivating charging will be discussed. In these examples, the wirelessly chargeable device is a handset such as a mobile telephone, phablet or tablet. Also in this example, the remote service 3 is provided as a cloud service.

Figure 2 shows an example flow for establishing charging for a wirelessly-chargeable device 23 according to a first example implementation.

The method of the present example starts at step S2-1 with a relevant charging functionality software application being activated on the handset. If necessary, this step may also include checking and prompting activation or, or performing activation of, a handset wireless communication technology compatible with transmissions from the beacons 13. The software application may be a so-called "app" for a mobile device or may be a so-called "applet" to operate within a functionality framework such as the JavaTM runtime environment.

The process then continues at step 32-3 at which the handset detects the first beacon identifier code as transmitted by one or more beacons 13 of a charging venue or facility 5. In this example, the beacon identifier code is not known to the handset, such that processing continues at step 32-5 where the handset sends a lookup query to the cloud service to request descriptive information based upon the received first beacon identifier code. As discussed above, this may include one or more of a name and a code representative of the charging venue or facility 5 in respect of which the beacon 13 is operating. This beacon-derived information is piovided by the cloud at step 32-7.

Next, at step S2-9 the beacon-derived information can optionally be presented on a display of the handset. This may include, for example, presenting in a display of the handset by means of which the charging functionality software application is enabled to present information a description of the charging venue or facility 5. For example, such a display could include a name, address, location, code or any other beacon-derived information provided by the cloud at step 32-7.

The process now continues at step S2-1 1 where the handset detects the second beacon identifier code as transmitted by one of the beacons 13 of the charging venue or facility 5. In this example, the second beacon identifier code is not known to the handset, such that processing continues at step S2-13 where the handset sends a lookup query to the cloud service to request descriptive information based upon the received first beacon identifier code.

In some optional examples, this beacon-derived information may be used to enable display by the handset of information describing to the user some property or description relating to the specific charging node, such as a device capability of the node and/or a specific charging geometry that may apply to the charger of that node. As discussed above, this may include one or more of a name and a code representative of the charging node 11 of the charging venue or facility 5 in respect of which the beacon 13 is operating. This beacon-derived information is provided by the cloud at step S2-15.

Next, at step S2-17, the handset facilitates the provision of a charging request input from a user. This may take the form of, for example presenting or enabling an input button of the handset to be configured to receive input as being the making of such a request. Where the handset has a touchscreen input device, the button may be a so-called soft button presented on the touchscreen display of the handset. Once a user input indicative of a charging request has been received by the handset as step S2-19, the handset the generates a charge authorisation query (step S2-21) for sending from the handset to request activation of wireless charging. The query includes information identifying the handset or a user, and information on the first and second beacon identifier codes. The information on the beacon identifier codes can be either or both of the beacon identifier codes themselves and the beacon-derived information provided to the handset by the cloud service at steps S2-7 and S2-15. At step S2-23 this query is sent by the handset to the cloud service.

Following receipt of the charge authorisation query by the cloud service at step S2-25, the cloud performs an authorisation process at step S2-27 to validate (or deny) the request for charging from the handset. The validation may depend on one or more of a number of parameters relating to the handset, a handset user and/or the charging venue or facility. As discussed above, it is possible that an account for providing access to wireless charging is associated with the handset itself or with a user of the handset. Thus the authorisation may operate in dependence upon a device identifier and/or a user identifier included in the charge authorisation query. Where provision of charging is a paid-for service, this may include determining that the handset/user has either sufficient credit balance to cover the cost of the charging requested in the charge authorisation query or has an active subscription of provision of charging in accordance with the charge authorisation query. Other factors that may influence the authorisation step may include a check that the particular facility or venue in respect of which charging has been requested is included in a service subscription or account settings of the handset/user. The authorisation may also take into account a compatibility check between the handset and a charging node for which charging has been requested in the charge authorisation query. The authorisation may also take into account whether another device already has an active charging session associated with the particular combination of first and second beacon identifiers.

As a result of the authorisation at step S2-27, an authorisation response is issued and, assuming that the authorisation result is positive (i.e. charging permitted), is provided by the cloud service to the controller 9 for the charging facility or venue in respect of which charging has been requested by the handset (step S2-29). This authorisation response is directed to the controller 9 based upon the first beacon code as received by the handset and included (either explicitly or in the form of beacon-derived information) in the charge authorisation query. The authorisation response includes the second beacon identifier or beacon-derived information therefor.

Upon receipt of the authorisation response by the controller at step S2-31, the controller activates the charger 17 of the charger node 11 associated with or identified by the second beacon identifier code. At this time, the handset receives charging if it is placed in sufficient proximity to the charger 17. Also, at this time, the controller may optionally inform a venue computer of the charging facility or venue about the handset or user that is receiving charging from the wireless charging service. This may facilitate direct communication from the venue computer to the handset for provision of secondary or value-added services as discussed above.

In addition to the cloud providing the authorisation response to the controller, the cloud also informs the handset of the authorisation response at step S2-37. Assuming that the authorisation response is positive, the handset can then indicate (step S2-31) that charging has been permifted, for example using a display of the handset. This may act as a prompt to a user to place the handset in sufficient proximity to the charger 17 for the wireless charging to occur, this may be particularly relevant if the range of the beacon 13 to transmit the second beacon identifier code is larger than or non-coincident with the range over which the charger 17 can perform wireless charging.

If the authorisation response was negative, it is possible to send the authorisation response to the handset only (i.e. not to the controller), which may result in the handset providing a notification to a user thereof that charging has been denied. Responsive thereto, a communication exchange between the handset and cloud may take place to establish a cause of failed authorisation and/or to make arrangements for a further request from the same handset to be authorised.

Although it has been discussed with respect to Figure 2 that the handset receives the first beacon identifier code before receiving the second beacon identifier code, it is possible that both of these may be received at the same time. It is also possible that the handset may wait until it has received both beacon identifier codes in order to send a single request to the cloud service for beacon-derived information relating to both the first and second beacon identifier codes together. It is also possible that the handset may request beacon derived information in respect of only one of the first and second beacon identifier codes, for example just the first beacon identifier code.

Although it has been discussed with respect to Figure 2 that a notification to a venue computer may be made from the controller, it is also envisaged that such a notification may be additionally or alternatively made by the cloud service such that 52-35 would occur based on the cloud service rather than the controller.

It has been discussed with respect to Figure 2 that the handset may communicate with the remote service to request beacon derived information associated with first and/or second beacon identifier codes detected by the handset. In some optional examples, the remote service may be configured to record or log information indicating when such requests are made and details of the handset/user making the request. Such records or logs may be stored in or stored in associated with a handset/user account such that a user may be provided with a record of when and where the handset entered charging facilities/venues, even if no charging request was made. Such information could be useful, for example in the event of a user's handset being stolen as a history of visits by the stolen device to charging facilities and venues could help both with recovery of the stolen item and tracing of a person in possession of the stolen item.

Thus there has now been described a first example of a process for requesting and providing wireless charging to a wirelessly-chargeable device. By use of such a process, a user of a portable device having a wireless charging capability can, after arriving at a wireless charging facility or venue, become aware that wireless charging is available, request wireless charging, receive wireless charging and be notified that the charging has been provided.

Figure 3 shows an example flow for establishing charging for a wirelessly-chargeable device 23 according to a second example implementation.

In the example of Figure 3, there are two main optional differences with respect to the example of Figure 2: there is no request made for beacon-derived information and the charge authorisation query is directed via the controller. Each of these differences may be independent of the other such that it is also envisaged to provide a system which applies only one of these optional differences with respect to the example of Figure 2.

The process of this example starts at step S3-1 with the activation of a software application as in step S2-1. Then a first beacon identifier code is received at step S3-3, which corresponds to step S2-3 discussed above.

Next, and optionally, the handset can look up the beacon identifier code at step S3-5 to retrieve-derived information for presenting on a display of the handset at step S3-7. This beacon derived information may correspond to beacon derived information such as that discussed with reference to steps S2-5 to S2-9 above. This lookup is in the present example performed with reference to a record or database of first beacon identifiers stored at the handset or in the handset's directly connected storage. This step is optional as it is envisaged that the present teachings may be implemented such that the software application may simply notify a user that the user is at a wireless charging facility or venue without indicating which wireless charging facility or venue.

In addition, at step S3-9, the handset detects the second beacon identifier code. As discussed above with respect to Figure 2, the handset may receive the second beacon identifier code at the same time (or even before) receiving the first beacon identifier code. Even in a situation where the beacons 13 transmit the first beacon identifier code to have a longer range of transmission than the second identifier code, it is possible that a user of the handset may chose not to activate the relevant software application or a hardware feature necessary for reception of the identifier codes until the handset is in range of both beacon identifier code transmissions. In this case, it could also be considered that the beacon-derived information is the fact of the handset being within range of a beacon rather than any information derived from the beacon identifier code itself.

Following reception of both beacon identifier codes by the handset, the handset facilitates the input of a charging request at step 33-11. Upon receipt of such an input at step 33-13, the handset generates a charge authorisation query at step 33-15. These steps correspond to steps 32-17 to 32-21 discussed above.

Once the charge authorisation query has been generated, the handset sends this to the controller at step 33-17. In this example, the controller takes an active role in managing the charge authorisation request but relies upon the cloud service to provide authorisation services.

Thus the controller passes the charge authorisation query on to the cloud service via a vpn link between the controller and the cloud service.

The controller may modify the authorisation request query before forwarding as in some implementations it may not be necessary for the cloud service to receive information on the second beacon identifier code. Thus the controller may forward the query without the second beacon identifier code and instead keep a record of the handset/user and second beacon identifier (or charger 17 or charging node 11 associated therewith) so that the controller can later apply an authorisation result for that handset/user to the specified second beacon identifier.

Upon receipt of the charge authorisation query at step 33-29, the cloud service at step S3-23 performs authorisation of the query. These steps correspond to steps S2-25 and S2-27 discussed with reference to Figure 2 above, lithe query as forwarded from the controller does not include the second beacon identifier or beacon derived information therefor, then the authorisation will not take second beacon identifier code information into account in the authorisation or provide this in any authorisation response.

Next, the cloud service may optionally inform the handset of the authorisation response at step 33-25. Assuming that the authorisation response is positive, the handset can then provide on a display of the handset an indication that charging has been authorised, which may provide a prompt to a user of the handset to ensure that the handset is sufficiently close to the charger 17 for wireless charging to take place.

The cloud service then sends the authorisation response to the controller at step 33-29.

After receiving the authorisation response at step 33-31, the controller then activates the charger 17 of the charger node 11 associated with or identified by the second beacon identifier code. If the controller forwarded the charge authorisation query without including the second beacon identifier code, then at this time the controller retrieves from its records the relationship between the handset/user identified in the authorisation response and the second beacon identifier code so as to be able to activate the correct charger. If the second beacon identifier code was retained in the query as forwarded by the controller at step 33-19, then the authorisation response may include the second beacon identifier code or beacon derived information therefor. At this time, the handset receives charging if it is placed in sufficient proximity to the charger 17.

At step 33-35, the controller may optionally notify the handset that charging has been activated at the charger 17, such that at step 33-37 the handset may inform a user thereof that charging is in progress.

Another optional step occurs at step 33-37 where the controller notifies the cloud service that charging has been commenced in accordance with the authorisation response. Thus the cloud service may at step 33-39 update a log or record indicating that the handset/user has received charging.

Also, at this time, the controller may optionally inform a venue computer of the charging facility or venue about the handset or user that is receiving charging from the wireless charging service (33-39). This may facilitate direct communication from the venue computer to the handset for provision of secondary or value-added services as discussed above.

If the authorisation response was negative, it is possible to send the authorisation response to the handset only (i.e. not to the controller), which may result in the handset providing a notification to a user thereof that charging has been denied. Responsive thereto, a communication exchange between the handset and cloud may take place to establish a cause of failed authorisation and/or to make arrangements for a further request from the same handset to be authorised. If a negative authorisation response is sent to the controller, this may be used for communicating the response to the handset and for removing from the records of the controller any stored relationship between the requesting handset/user and a particular second beacon identifier code.

Although it has been described with respect to Figure 3 that the handset presents information and facilitates and waits for input before the handset makes a charge authorisation query, in some examples some or all of these steps may be omitted. For example, the software application may be configured to automatically make and send a charge authorisation query whenever the software is active and the handset is receiving both a first beacon identifier code and a second beacon identifier code. In this example, the process would carry out steps 33-1, 33-3, 33-9 and 33-13 but would miss out steps 33-5, 33-7, 33-11 and 33-13. In another example, the software may display some form of notification of being at a wireless charging facility or venue (for example by providing a display responsive to having detected a first beacon identifier code) but may make the request automatically without seeking or waiting for user input.

Thus there has now been described another example of a process for requesting and providing wireless charging to a wirelessly-chargeable device. By use of such a process, a user of a portable device having a wireless charging capability can, after arriving at a wireless charging facility or venue, become aware that wireless charging is available, request wireless charging, receive wireless charging and be notified that the charging has been provided.

Figure 4a shows an example flow for ceasing provision of charging to a wirelessly-chargeable device 23 according to a first example implementation. It will be appreciated that ceasing the supply of power to a charger at an appropriate time, such as when a handset is no longer present to receive wireless power transfer, may provide for appropriate use of energy and responsible power management for a charging venue.

The process of the present example is triggered by a request from a user to cease charging, the request being input to the handset by the user. Thus the process commences at step S4-1 with a request to stop charging being received by the handset. From this input, the handset generates at step 34-3 a stop charging request. The stop charging request identifies the handset (or user account associated with the handset) and first and second beacon identifier codes (and/or beacon-derived information therefor) as previously used by the handset to initiate charging in a charge authorisation query. This stop charging request is then sent at step 34-5 from the handset to the cloud service, which receives the stop charging request at step 34-7.

After receiving the stop charging request, the cloud service may optionally carry out a check to determine whether it has a record of the handset/user having an active charging provision associated with the supplied first and second beacon identifier codes. If no such active charging provision is indicated, then an error message may be returned. Alternatively, if no such active charging provision is recorded, then a record of an active charging provision associated with the supplied first and second identifier codes may be made by the cloud service to record that such a provision had in fact been made available and received.

The cloud service then, at step 34-9, sends a stop charging command to the controller associated with the first beacon identifier code. The cloud service can record that the command to stop charging has been sent with or in respect of a handset/user account record. The cloud service can also record that the command to stop charging has been sent with or in respect of a record of active charging nodes. The stop charging command is directed to the controller based upon the first beacon code identifier. In response to receipt of the stop charging command at step 34-11, the controller then de-activates the charger 17 associated with the second beacon identifier code included in the stop charging command at step 34-13.

In addition to sending the stop charging command to the controller, the cloud service can also send a notification to the handset (step 34-15) to inform the handset that the request to stop charging has been actioned. Upon receipt of such a notification, the handset can present information on a display of the handset indicating that charging is ceased.

Thus there has now been described an example of a process for requesting the cessation of wireless charging to a wirelessly-chargeable device. By use of such a process, a user of a portable device having a wireless charging capability can, after receiving wireless charging to their device, request that the charging cease and receive notification that the charging has been stopped accordingly.

Figure 4b shows an example flow for ceasing provision of charging to a wirelessly-chargeable device 23 according to a second example implementation.

The process of the present example is again triggered by a request from a user to cease charging, the request being input to the handset by the user. Thus the process commences at step 34-21 with a request to stop charging being received by the handset. From this input, the handset generates at step 34-23 a stop charging request. The stop charging request identifies the handset (or user account associated with the handset) and first and second beacon identifier codes (and/or beacon-derived information therefor) as previously used by the handset to initiate charging in a charge authorisation query. This stop charging request is then sent at step 34-25 from the handset to the controller, which receives the stop charging request at step S4-27.

The controller then, at step 34-29, de-activates the charger 17 associated with the second beacon identifier code included in the stop charging command at step. The controller sends notifications of the ceasing of charging by the charger 17 at step 34-31.

One notification is sent by the controller to the handset, which receives the notification at step 34-33 that the request to stop charging has been actioned. Upon receipt of such a notification, the handset can present information on a display of the handset indicating that charging is ceased (step 34-35).

Notification of stopping the charging is also sent by the controller to the cloud service.

After receiving the notice of stopping the charging at step 34-37, the cloud service can record that the command to stop charging has been sent with or in respect of a handset/user account record, and/or with or in respect of a record of active charging nodes (step 34-39).

The cloud service may optionally carry out a check to determine whether it has a record of the handset/user having an active charging provision associated with the notification of stopping charging. If no such active charging provision is indicated, then an error message may be returned. Alternatively, if no such active charging provision is recorded, then a record of an active charging provision may be made by the cloud service to record that such a provision had in fact been made available and received.

Thus there has now been described another example of a process for requesting the cessation of wireless charging to a wirelessly-chargeable device. By use of such a process, a user of a portable device having a wireless charging capability can, after receiving wireless charging to their device, request that the charging cease and receive notification that the charging has been stopped accordingly.

Figure 5a shows an example flow for ceasing provision of charging to a wirelessly-chargeable device 23 according to a third example implementation.

The process of the present example is triggered by a detection that the handset is no longer able to detect a beacon identifier code associated with a previously made charge authorisation query for an active wireless charging provision. Such cessation of detecting the codes may be caused, for example, by the handset moving away from the charging venue or facility, or by the handset having a beacon reception technology turned off, or by a failure of one or more beacons of a charging venue or facility.

Thus the process commences at step 35-1 with the software application of the handset detecting that the handset that it is no longer receiving a first or second beacon identifier code.

By making the detection dependent upon receiving of the first beacon identifier code, this facilitates the handset being moved within the venue or facility, for example if a user has to move the handset away from the charger and hence the associated beacon that transmits the second beacon identifier code to, attend a sales desk of the charging venue or facility, to answer a telephone call or to visit a restroom. The determination may also be time-dependent, such that the determination may in some examples only be made if reception of the beacon identifier code is lost for more than a threshold time interval.

Upon making the determination at step Sb-i, the handset generates and sends at step Sb-S a stop charging request. The stop charging request identifies the handset (or user account associated with the handset) and first and second beacon identifier codes (and/or beacon-derived information therefor) as previously used by the handset to initiate charging in a charge authorisation query. This stop charging request sent from the handset to the cloud service, which receives the stop charging request at step 55-5.

The cloud service then, at step 55-7, sends a stop charging command to the controller associated with the first beacon identifier code. The cloud service can record that the command to stop charging has been sent with or in respect of a handset/user account record. The cloud service can also record that the command to stop charging has been sent with or in respect of a record of active charging nodes. The stop charging command is directed to the controller based upon the first beacon code identifier. In response to receipt of the stop charging command at step 55-9, the controller then de-activates the charger 17 associated with the second beacon identifier code included in the stop charging command at step 55-11.

In addition to sending the stop charging command to the controller, the cloud service can also send a notification to the handset (not shown) to inform the handset that the request to stop charging has been actioned. Upon receipt of such a notification, the handset can present information on a display of the handset indicating that charging is ceased. On the other hand, as the handset may be considered to already know that charging has ceased due to loss of the beacon identifier code reception, this step may be omitted and the handset can indicate a cessation of charging once the detection is made at step S5-1.

Thus there has now been described an example of a process for requesting the cessation of wireless charging to a wirelessly-chargeable device. By use of such a process, a portable device having a wireless charging capability can, after detecting that it is no longer receiving identifiers associated with a wireless charging venue or facility notify the charging infrastructure to provide that the charging provision that the handset was previously using is turned off.

The approach shown in and described with respect to Figure 5a, can be altered to operate in an infrastructure system where the controller takes a more active role in managing the system. In one such example, the modifications necessary to achieve this would correspond to the modifications made to arrive at the process of Figure 4b from the process of Figure 4a.

Figure 5b shows an example flow for ceasing provision of charging to a wirelessly-chargeable device 23 according to a fourth example implementation.

In this example, the infrastructure is such that the handset has some form of two-way communication beacons or has some form of direct communication with the controller, such as an intermitted handshake or some form of more substantial communication. Thus the process of the present example is triggered by a detection that there has been a cessation in the reception of handset signals by either or both of the controller and the beacons. Such cessation may be caused, for example, by the handset moving away from the charging venue or facility, or by the handset having a beacon or controller signal communication technology turned off, or by a failure of one or more beacons of the charging venue or facility.

Thus the process commences at step 55-21 with the controller detecting that it is no longer in communication with the handset, either directly or via one or more beacons. The determination may be time-dependent, such that the determination may in some examples only be made if such a cessation of communication occurs for more than a threshold time interval.

Upon making the determination at step S5-21, the controller de-activates the charger 17 associated with the second beacon identifier code included in the stop charging command at step 35-23. The controller sends notification of the ceasing of charging by the charger 17 at step 35-25.

The notification of stopping the charging is sent by the controller to the cloud service.

After receiving the notice of stopping the charging at step S5-27, the cloud service can record that the command to stop charging has been sent with or in respect of a handset/user account record, and/or with or in respect of a record of active charging nodes (step 55-29). The cloud service may optionally carry out a check to determine whether it has a record of the handset/user having an active charging provision associated with the supplied first and second beacon identifier codes. If no such active charging provision is indicated, then an error message may be returned. Alternatively, if no such active charging provision is recorded, then a record of an active charging provision associated with the supplied first and second identifier codes may be made by the cloud service to record that such a provision had in fact been made available and received.

Optionally, a notification may be sent by the cloud server to the handset to inform he handset that charging has been ceased. (not shown). Upon receipt of such a notification, the handset can present information on a display of the handset indicating that charging is ceased.

Thus there has now been described another example of a process for terminating the provision of wireless charging to a wirelessly-chargeable device. By use of such a process, a charging facility that has been providing wireless charging to a portable device having a wireless charging capability can, after detecting that the portable device is no longer in communication with the facility, update the wireless charging infrastructure to provide that the charging service that the handset was previously using is turned off.

The approach set out in Figure 5b can also be used for stopping of charging in the situation where a maximum charge session threshold is reached. Such a threshold may include, for example, a maximum charge session duration or a maximum charge session power delivery amount. To achieve such a system, the step 55-21 instead of making a determination that communication with the handset has been lost may make a determination that the relevant threshold has been reached or exceeded. In another example, the process can be used where the charger is powered by a rechargeable battery under the control of the controller and the battery has reached a threshold run-down level.

Figure Ga shows an example flow for ceasing provision of charging to a wirelessly-chargeable device 23 according to a fifth example implementation.

The process of the present example is triggered by a request from a venue hosting a charging facility to cease charging, the request being provided by the venue to the cloud service. Thus the process commences at step S6-1 with a request to stop charging being received by the cloud service from the venue. The request identifies at least the venue and the charging node for which charging is to be ceased. The cloud service may apply a suitable level of authenticity and authority confirmation before auctioning the request from the venue. From this input, the cloud service generates and sends at step S6-3 a stop charging command. The stop charging command identifies the handset (or user account associated with the handset), which may be determined by the cloud service from records of the cloud service linking the charging node identified by the venue to the handset based upon a previous charge authorisation query that resulted in an active charging session. The stop charging command also includes the second beacon identifier codes (and/or beacon-derived information therefor) as provided by the request from the venue or associated with a charging node identified in the request from the venue. This stop charging command is sent to the controller associated with the venue which made the stop charging request.

In response to receipt of the stop charging command at step 36-5, the controller then de-activates the charger 17 associated with the second beacon identifier code included or represented in the stop charging command at step 54-7.

In addition to sending the stop charging command to the controller, the cloud service can also send a notification to the handset (step 36-9) to inform the handset that a request to stop charging has been actioned. The notification may also communicate that the stop charging request came from the venue. Upon receipt of such a notification, the handset can present information on a display of the handset indicating that charging is ceased (36-11).

A venue may make a request to stop charging in a number of circumstances, for example in a situation where the venue is a commercial outlet and is closing to customers due to the end of trading hours being reached. A venue may also make such a request if the venue is responsible for maintaining a power supply to the charging stations and reaches a threshold power delivery level for a given time period or if the chargers are powered by rechargeable batteries under the control of the venue and the relevant charger battery has reached a threshold run-down level. A venue may also make such a request where the venue is a commercial outlet and the user of the handset has not made sufficient purchases from the commercial outlet to be permitted to retain their place in the outlet. Such an approach would facilitate a commercial outlet hosting a wireless charging facility from having a user occupy a table or other space with a charging node without that user also conducting sufficient commercial transactions with the commercial outlet itself.

Thus there has now been described an example of a process for requesting the cessation of wireless charging to a wirelessly-chargeable device. By use of such a process, a venue hosting a wireless charging facility can request that charging be ceased to one or more charging stations.

Figure 6b shows an example flow for ceasing provision of charging to a wirelessly-chargeable device 23 according to a sixth example implementation.

The process of the present example is triggered by a request from a venue hosting a charging facility to cease charging, the request being provided in this example by the venue to the controller. Thus the process commences at step S26-1 with a request to stop charging being received by the controller from the venue. The request identifies at least the charging node for which charging is to be ceased. The controller may apply a suitable level of authenticity and authority confirmation before auctioning the request from the venue, which may include sending an authorisation request to the cloud server (not shown). From this input, the controller then de-activates at step S6-23 the charger 17 associated with the second beacon identifier code included or represented in the stop charging request. The controller sends notifications of the ceasing of charging by the charger 17 at step S6-25.

One notification is sent by the controller to the handset, which receives the notification at step S6-27 that a request to stop charging has been actioned. The notification may also communicate a reason why the charging has been stopped. Upon receipt of such a notification, the handset can present information on a display of the handset indicating that charging is ceased (step S6-29).

After receiving the notice of stopping the charging at step S6-31, the cloud service can record that the command to stop charging has been sent with or in respect of a handset/user account record, and/or with or in respect of a record of active charging nodes (step S6-33).

With any of the described approaches for both providing and stopping charging, it is also possible for the cloud service or controller to send one or more messages or notifications to the handset to provide information relating to current and historical charging sessions, including any or all of usage information, venues/facilities utilised, duration of charging, amount of power delivered overall or per charging session, venue offers or vouchers received or utilised, account status such as credit balance or subscription duration, and communications from visited venues or facilities. Thus not only can a handset receive information that may be of interest to a user in managing their account, the handset can also facilitate a continued communication between the user and a facility or venue hosting the wireless charging nodes even after charging has been terminated for that venue.

It will therefore be understood that a wireless charging infrastructure as described herein may be operating in one or more of a number of ways to achieve both commencement and cessation of charging to a wirelessly-chargeable device. The implementation of such an infrastructure and approach provides for efficient and controlled delivery of wireless charging to authorised wirelessly-chargeable devices at a variety of venues and facilities.

While it has been described above that the wirelessly chargeable device may display one or more notifications or other information to a user thereof on a display apparatus of the device, it is also possible to provide notifications in a manner other than or additionally to by visual means. For example, notifications and other information could be provided via audio signals such as a suitable beep, tone or generated speech method. Also, notifications could be provided via haptic feedback technology such as by making the wirelessly chargeable device or a part thereof vibrate.

While it has been described above that a controller is provided to control a number of wireless chargers at a wireless charging facility or venue, it is also possible to use other configurations. For example, one or more wireless chargers could have a controller built in such that a combined controller/charger could control itself and a number of simple chargers, or each charger could have its own integral charger with each communicating with the remote service in respect of its own charger only. In examples where multiple ones of the charges have integral controllers it would also be possible to arrange the controllers into some form of mesh network to provide redundancy of communication to the remote service and/or provide for resilient connection to a wired data path from the facility/venue to the remote service. It is also additionally or alternatively possible for a beacon to be integrated into a charger and/or the controller, such that a charging node could be a single device providing both charger and beacon functionality.

While it has been described above that the wireless charging is applied to the same device that both navigates to the charging facility or venue and then communicates with the beacons, it is also possible to use separate devices for navigation and/or communication to that which receives charging. For example, a user may utilise a mobile device with a navigation capability to arrive at the facility or venue, and then use another device to communicate with the beacons and then use another device to receive charging. For example, a user may use a mobile telephone to navigate to the facility and to communicate with the beacons, but then receive charging to a tablet or laptop that is of a size or form inconvenient for navigation purposes. In such a situation, if the venue or facility or if the user/device account is linked to the particular device or device nature to receive charging, then the request may include details of the device to receive charging as well as the device from which a charging request is made.

While it has been described above that a remote service S provides functions such as provision of information based upon beacon identifier codes, authorisation of charging requests, account maintenance and payment updates, it is also considered that these functions could be split between different remote services or different subsections of a remote service. For example an information service could respond to queries relating to beacon identifier codes and an account management service could provide authorisation of charging request and provide management of account usage and payment records. Other configurations, including distributed services and load balanced clusters can also be used.

This disclosure shows by way of illustration various embodiments in which the present teachings may be practiced and provide for a wireless charging infrastructure, service, controller, application, device and method. The advantages and features of the disclosure are of a representative sample of embodiments only, and are not exhaustive and/or exclusive. They are presented only to assist in understanding and teach the claimed features. It is to be understood that advantages, embodiments, examples, functions, features, structures, and/or other aspects of the disclosure are not to be considered limitations on the disclosure as defined by the claims or limitations on equivalents to the claims, and that other embodiments may be utilised and modifications may be made without departing from the scope and/or spirit of the disclosure. Various embodiments may suitably comprise, consist of, or consist in essence of, various combinations of the disclosed elements, components, features, parts, steps, means, etc. In addition, the disclosure includes other teachings not presently claimed, but which may be claimed in future.

Claims

CLAIMS1. A power system comprising: a transmitter operable to transmit an identifier of the transmitter; a charger operable to wirelessly charge the battery of a mobile object; a controller operable to activate the charger; a server operable to communicate with the controller; a mobile object having a battery operable to be charged wirelessly, the mobile object operable to receive the identifier of the transmitter and send a request comprising the identifier of the transmitter and a user identifier to the server; wherein the server is operable to: receive the request; determine whether an access condition is satisfied based upon the user identifier; and provide an access condition result to the controller.
2. The power system of claim 1, wherein, if the access condition is satisfied, the access condition result provided to the controller causes the controller to activate the charger to wirelessly charge the battery of the mobile object.
3. The power system of claim 1 or 2, wherein the mobile object is operable to send the request via wireless communication to the controller and wherein the controller is operable to forward the request via a secure communications channel to the server.
4. The power system of claim 1, 2 or 3, wherein the transmitter identifier is indicative of the charger.
5. The power system of any preceding claim, wherein the transmitter is operable to transmit a second identifier, the second identifier indicative of a venue or facility.
6. The power system of any preceding claim, comprising a plurality of transmitters and a plurality of chargers, each transmitter operable to transmit an identifier associated with a respective charger.
7. The power system of claim 6 as dependent from claim 5, wherein at least one transmitter is operable to transmit only the second identifier.
8. The power system of claim 5 or 7, wherein the request further comprises the second identifier.
9. The power system of claim 5, 7 or 8, wherein the mobile object is operable to receive the second identifier and to display an indication of a venue or facility associated with the second identifier.
10. The power system of any preceding claim, wherein the mobile object is a general purpose device programmed using a wireless charging functionality application.
11. The power system of any preceding claim, wherein the charger is powered by a rechargeable power source and wherein the controller is operable to activate the charger wirelessly.
12. The power system of claim 11, wherein the controller is operable to deactivate the charger in dependence upon a remaining charge of the rechargeable power source.
13. The power system of any preceding claim, wherein the controller is operable to deactivate the charger responsive to one or more selected from the group comprising: a request to stop charging from the movable device, a loss of communication with the movable device, a control from an administrator, a charge time exceeding a time threshold, and a transferred power exceeding a power threshold.
14. The power system of any preceding claim, wherein the controller or the server is operable to provide data describing the movable object or a user of the movable object to a computer of a venue or facility hosting the controller and the charger.
15. The power system of claim 14, wherein the computer is operable to transmit a message to the movable object while the charger is activated.
16. The power system of any preceding claim 14 or 15, wherein the computer is operable to receive a message from the movable object while the charge is activated.
17. The power system of claim 16, wherein the message comprises information relating to an order or payment from the movable object to the computer for goods or services available at or via the venue or facility hosting the controller and the charger.
18. A battery-powered movable device having a wireless charging capability, the device comprising: a receiver operable to receive a wireless signal comprising a transmitter identifier; a processor operable to generate a request to an authorisation server for provision of wireless charging, the request comprising the transmitter identifier and an account identifier; a transmitter operable to wirelessly transmit to the authorisation server a signal comprising the request; a wireless charging receptor operable to receive wireless provision of power to recharge the battery of the movable device.
19. The device of claim 18, wherein the receiver is further operable to receive a second wireless signal comprising a venue identifier, and wherein the processor is operable to generate the request further comprising the venue identifier.
20. The device of claim 18 or 19, further comprising a display operable to display an invitation to request charging responsive to reception of the wireless signal, and an input device operable to receive an input responsive to the invitation, the processor operable to generate the request responsive to the input.
21. The device of claim 20, wherein the display is further operable to display an invitation to request cessation of charging, the input device is operable to receive an input responsive to the invitation, the processor is operable to generate a request to cease charging, and the transmitter is operable to wirelessly transmit the request to cease charging to the power controller.
22. A power controller comprising: a server interface operable to receive from a remote server a message instructing activation of a wireless charging station associated with a beacon identifier; and a power control interface operable to activate a wireless charging station associated with the beacon identifier responsive to receipt of the message.
23. The controller of claim 22, wherein the request comprises first and second identifiers of a beacon, and wherein the controller is associated with one of the identifiers and a wireless charging station is associated with the other of the identifiers.
24. The controller of any of claims 22 or 23, comprising a beacon interface operable to activate and deactivate one or more beacons.
25. The controller of claim 22, 23 or 24, operable to detect that a battery-powered device is no longer in data communication with a beacon associated with the controller, the power control interface operable to deactivate the wireless charging station responsive to the detection.
26. The controller of claim 25, operable to detect that a battery-powered device is no longer in data communication with a beacon associated with the controller by receiving a message via the server interface.
27. The controller of any of claims 22 to 26, wherein the power control interface is operable to deactivate the wireless charging station responsive to one or more selected from the group comprising: a request to stop charging from the battery-powered device, a loss of communication with the movable device, a control from an administrator, a charge time exceeding a time threshold, a transferred power exceeding a power threshold, and a remaining power resource of a charging power supply.
28. The controller of any of claims 22 to 27, wherein the server interface is operable to communicate to a remote server status and/or configuration information of the controller.
29. A charging control server, comprising: a communication interface operable to receive a request for wireless charging from a wirelessly-chargeable device located in proximity to a wireless charging station under the control of a local power controller, the request including a beacon identifier and an authorisation identifier; a processor operable to determine an authorisation result for the authorisation identifier; the communication interface further operable to transmit, in dependence upon the authorisation result, a message to the local power controller instructing activation of a wireless charging station associated with the beacon identifier.
30. The charging control server of claim 29, the communication interface further operable to receive from a wirelessly-chargeable device a message indicating that charging from the wireless charging station associated with the beacon identifier should be ceased, and to transmit a message to the local power controller instructing deactivation of the wireless charging station associated with the beacon identifier.
31. The charging control server of claim 29 or 30, the communication interface further operable to receive a message from the local power controller providing status and/or configuration information of the controller.
32. The charging control server of claim 29, 30 or 31, the processor further operable to update a value indicator associated with the wirelessly-chargeable device or an account code provided by the wirelessly-chargeable device in dependence upon the authorisation result, and the communication interface further operable to transmit a message describing the updated value indicator to the wireless-chargeable device.
33. A method of providing wireless charging to a movable device having a wireless charging capability, the method comprising: providing to a user of a movable device having a wireless charging capability a geographical indication of one or more wireless charging facilities providing, using a first wireless communication beacon of a wireless charging facility, to a user of the movable device having a wireless charging capability a notification when approaching the wireless charging facility providing, using a second wireless communication beacon of the wireless charging facility, an indication of availability of conditional access to wireless charging providing, from a manager device of the wireless charging facility, confirmation of the availability of the conditional access to wireless charging and activating, by the manager device a wireless charging source for use by the movable device having a wireless charging capability
34. A method of providing wireless charging to a movable device having a wireless charging capability, the method comprising: receiving, from a wireless communication transmitter of a wireless charging facility, an indication of availability of conditional access to wireless charging; sending a request for access to wireless charging at the wireless charging facility; receiving, from a wireless charging source activated by a manager device of the wireless charging facility, wireless charging to a movable device having a wireless charging capability.
35. The method of claim 26, further comprising receiving, from a wireless communication beacon of a wileless charging facility, a proximity indication relating to the wireless charging facility.
36. The method of claim 26 or 27, further comprising receiving, at the movable device having a wireless charging capability, a geographical indication of one or more wireless charging facilities.
37. The method of claim 26, 27 or2B, further comprising receiving confirmation of access to wireless charging.
38. The method of any of claims 26 to 29, wherein the receiving confirmation of the availability of access to wireless charging comprises receiving confirmation from one or more of the manager device and an authorisation service.AMENDMENTS TO CLAIMS HAVE BEEN FILED AS FOLLOWSC LA MS1 A power system comprising: a transmitter operable to transmit an identifier of the transmitter; a charger operahe to wirelessly charge the battery of a mobile object: a controfler operable to activate the charger; a server operabe to communicate with the controfler; a mobile object having a battery operable to be charged wirelessy, the mobile object operable to receive the identifier of the transmitter and send a request comprising the identifier of the transmitter and a user identifier to the server; wherein the eerier is operable to: receive the request; determine whether an access condition is satisfied based upon the user identifier; and provide an access condition result to the controller.2. The power system of claim 1, wherein, if the access condition is satisfied, the access condition result provided to the controfler causes the controHer to activate the charger to LI) wir&essly charge the battery of the mobile object.3 The power system of claim I or 2, wherein the mobile object is operable to send the request via wireless communication to the controller and wherein the controller is operable to forward the request via a secure communications channel to the server.4. The power system of daim 1, 2 or 3, wherein the transmitter dentifier is indcative of the charger.5, The power system of any preceding daim, wheren the transmitter is operabe to transmit a second identifier, the second idenfifier indicative of a venue or facility.6. The power system of any preceding claim, comprising a plurality of transmitters and a purality of chargers, each transmitter operable to transmit an identifier assocated with a respective charger.7. The power system of claim 6 as dependent from claim 5, wherein at least one transmitter is operable to transmit ony the second identifier.8. The power system of claim 5 or 7, wherein the request further comprises the second identifier.9. The power system of claim 5, 7 or 8, wherein the mobe object is operable to receive the second identifier and to display an indication of a venue or facility associated with [he second identifier.10. The power system of any preceding daim, wherein the mobfle object is a general purpose device programmed using a wireless charging functionality application 11. The power system of any preceding claim, wherein the charger is powered by a rechargeable power source and wherein the controHer is operable to activate the charger wirelessly.12. The power system of claim 11, wherein the controller is operable to deactivate the charger in dependence upon a remaining charge of the rechargeable power source.13. The power system of any preceding claim, wherein the controfler is operable to LI) deactivate the charger responsive to one or more selected from the group comprising: a request to stop charging from the mobUe object, a loss of communication with the mobile object, a control from an administrator, a charge time exceeding a time threshold, arid a transferred power exceeding a power threshold.0 14. The power system of any preceding claim, wherein the controller or the server is operable to provide data describing the mobile object or a user of [he mobile object to a computer of a venue or facility hosting the controller and the charger.15. The power system of claim 14, wherein the computer is operable to transmit a message to the mobile object while the charger is activated.16. The power system of any preceding claim 14 or 15, wherein, the computer is operable to receive a message from the mobile object while the charge is activated.17. The power system of claim 16, wherein the message comprises information relating to an order or payment from the mobile object to the computer for goods or services available at or via the venue or facility hosting the controller and the charger.18. A battery-powered mobile object having a Mreless charging capability, the device comprising: a receiver operable to receive a wireless signal comprising a transmitter identifier; a processor operable to generate a request to an authorisation server for provision of wireless charging, the request comprising the transmitter identifier and an account identifier, a transmitter operable to wirelessly transmit to the authonsaflon server a signal comprising the request; a wireless charging receptor operable to receive wireless provision of power to recharge the battery of the mobile object.19. The object of claim 18, wherein the receiver is further operable to receive a second wireless signal comprising a venue identifier, and wherein the processor is operable to generate the request further comprising the venue identifier.20. The object of claim 18 or 19, further comprising a display operable to display an invitation to request charging responsive to reception of the wireless signal, and an input object operable to receive an input responsive to the invitation, the processor operable to generate the request responsive to the input. IC)21. The object of claim 20, wherein the display is further operable to display an invitation to request cessation of charging. the input object is operable to receive an input responsive to the invitation, the processor is operable to generate a request to cease charging, and the 0 transmitter is operable to wirelessly transmit the request to cease charging to the power 0 controller.22. A power controller comprising: a server interface operable to receive from a remote server a message instructing activation of a wireless charging station associated with a transmitter identifier; and a power control interface operable to activate a wireless charging station associated with the transmitter identifier responsive to receipt of the message.23. The controller of claim 22, wherein the request comprises first and second identifiers of a transmitter, and wherein the controller is associated with one of the identifiers and a wireless charging station is associated with the other of the identifiers.24. The controller of any of claims 22 or 23, comprIsing a transmitter interface operable to activate and deactivate one or more transmitters.25. The controller of claim 22, 23 or 24, operable to detect that a battery-powered mobile object is no longer in data communication with a transmitter associated with the controller, the power control interface operable to deactivate the wireless charging station responsive to the detection.26. The controHer of claim 25, operable to detect that a battery-powered rnobe object is no longer in data communication with a beacon associated with the controfler by receiving a message via the server interface.27. The controfler of any of claims 22 to 26, wherein the power control interface is operable to deactivate the wireless charging station responsive to one or more selected from the group comprising: a request to stop charging from the battery-powered mobile object. a loss of communication with the mobile object, a control from an administrator, a charge time exceeding a time threshold, a transferred power exceeding a power threshold, and a remaining power resource of a charging power supply.28. The controller of any of claims 22 to 27, wherein the server interface is operable to communicate to a remote server status and/or configuration information of the controfler. IC)29. A charging control server, comprising: a communication interface operable to receive a request for wireless charging from a wirelessly-chargeable mobile object located in proximity to a wireless charging station under the control of a local power controller, the request including a beacon identifier and an authorisation O identifier; a processor operable to determine an authorisation result br the authorisation identiñer; the communication interface further operable to transmit, in dependence upon the authorisation result, a message to the local power controller instructing activation of a wireless charging station associated with the transmitter identifier.30. The charging control server of claim 29, the communication interface further operable to receive from a wirelessly-chargeable mobile object a message indicating that charging from the wireless charging station associated with the transmitter identifier should be ceased, and to transmit a message to the local power controller instructing deacLEvation of the wireless charging station associated with the transmitter identifier.31. The charging control server of claim 29 or 30, the communication interface further operable to receive a message from the local power controller providing status and/or configuration information of the controller.32. The charging control server of claim 29, 30 or 31, the processor further operable to update a value indicator associated with the wirelessly-chargeable mobfle object or an account code provided by the wirelesslychargeabie mobile object in dependence upon the aul.hohsatlon result, and the communication nterface further operable to transmit a message describing the updated value indicator to the wireless-chargeable device.33. A method of providing wireless charging to a mobile object having a wireless charging capabihty, the method comprising: providing to a user of a mobile object having a wireless charging capabihty a geographical indication of one or more wireless charging faciUties: providing, using a first wireless communication transmitter of a wireless charging facility, to a user of the mobile object having a wireless charging capability a notification when approaching the wireless charging facility; providing, using a second wireless communication transmitter of the wireless charging facihty, an indication of availability of conditional access to wireless charging: providing, from a manager device of the wireless charging facility, confirmation of the LI) availability of the conditional access to wireless charging; and activating, by the manager device a wireless charging source for use by the mobile object having a wireless charging capability 34. A method of providing wireless charging to a mobile object having a wireless charging O capability, the method comprising: receiving, from a wireless communication transmitter of a wireless charging facility, an indication of availability of conditional access to wireless charging; receiving by the mobile object from the wireless communication transmitter an identifier of the wireless communication transmitter; sending a request for access to wireless charging at the wireless charging facility; and receiving, from a wireless charging source activated by a manager device of the wireless charging facility, wireless charging to the mobile object having a wireless charging capability.35. The method of claim 34. further comprising receiving, from a wireless communication transmitter of a wireless charging facility, a proximity indication relating to the wireless charging facility.36. The method of claim 34 or 35. further comprising receiving] at the mobile ot4ect having a wireless charging capability, a geographical indication of one or more wireless charging facilities.37. The method of claim 34, 35 or 36, further comprising receiving confirmation of access to wireless charging.38. The method of any of claims 34 to 37, wherein the receiving confirmation of the availability of access to wireless charging comprises receiving confirmation from one or more of the manager device and an authorisation service. LI) cv) C)