Revocation list in a wireless power system

Abstract

This disclosure provides systems, methods and apparatuses for updating a revocation list or other configuration information in a wireless power system. A wireless power apparatus (such as a Power Transmitter or a Power Receiver) implements a revocation list update process with another device. The update process might include various information messages and / or transfer messages. In some aspects, the revocation list update process is performed as part of, or after, an authentication with a peer wireless power apparatus or update apparatus. The apparatus with the most recent version (based on version information) of the revocation list can provide the most recent version to the other apparatus. Thus, the other apparatus can store the newer version of the revocation list for subsequent authentications. Some techniques of this disclosure enable an updated revocation list to propagate in a wireless power system that includes one or more offline devices.

Description

REVOCATION LIST IN A WIRELESS POWER SYSTEMCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority benefit of Indian Provisional Patent Application No.202511004378, filed January 20, 2025, the disclosure of which is incorporated herein.TECHNICAL FIELD

[0002] This disclosure relates generally to wireless power and some aspects relate to authentication with revocation list version control in a wireless power system.BACKGROUND

[0003] A wireless power system includes a Power Transmitter (PTx, sometimes also referred to as a wireless power transmission apparatus) and a Power Receiver (PRx, sometimes also referred to as a wireless power reception apparatus). The Power Transmitter transmits power via an electromagnetic field or resonant frequency. The Power Receiver can receive the wireless power and provide it to a load (such as a motor, a heating element, electronics, or a power storage device, among other examples) of an appliance. An appliance (sometimes also referred to as a device) might include a Power Transmitter, a Power Receiver, or both. For example, a first appliance (such as a kitchen hob, table, or charging station) might include one or more Power Transmitters. A second appliance (such as a kitchen device, computing device, or user device) might include a Power Receiver as well as the load. A wireless power system can include appliances from different manufacturers. The manufacturers might implement a common standard wireless power transfer specification so that their respective Power Transmitter(s) or Power Receiver(s) are compatible with one another. Failure of a wireless power apparatus (such as the Power Transmitter or the Power Receiver in a first appliance) to comply with the common specification can potentially cause damage to the wireless power apparatus, other components, or an environment in which the appliances are operated.

[0004] To mitigate the risk of incompatible wireless power apparatuses, manufacturers might undertake product testing and manufacturer registration to ensure proper implementation of the specification. The specification may define an authentication protocol in which each apparatus can verify that that another apparatus has registered and is compatible with the common specification. An appliance that cannot be authenticated might be produced by a manufacturer that does not fully support the features of the common specification. To enable successful authentication, an appliance from a registered manufacturer can storeauthentication information (such as a private key, registration information, configuration settings, or authentication software, among other examples). A license administrator can distribute the authentication information to registered manufacturers.

[0005] A revocation list may contain revocation data (such as revoked certificates, manufacturer identification, device identification, or other information). For example, a revocation list can indicate than an apparatus no longer complies with the common wireless power specification. There is a desire to support revocation lists in devices.BRIEF SUMMARY

[0006] The systems, methods, and apparatuses of this disclosure each have several innovative aspects, no single one of which is solely responsible for the desirable attributes disclosed herein.

[0007] One innovative aspect of the subject matter described in this disclosure can be implemented as a method performed by a first wireless power apparatus. The method includes the first wireless power apparatus communicating with a second wireless power apparatus, performing a successful authentication of the second wireless power apparatus based, at least in part, on a first revocation list stored in a memory of the first wireless power apparatus, and initiating a revocation list update process between the first wireless power apparatus and the second wireless power apparatus during or after the successful authentication of the second wireless power apparatus.

[0008] Another innovative aspect of the subject matter described in this disclosure can be implemented as a method of a first apparatus. The method includes the first apparatus communicating one or more information messages to enable the first apparatus or a second apparatus to determine whether the first apparatus or the second apparatus has a most recent version of a revocation list compared to the other of the first apparatus and the second apparatus, the revocation list including revocation data to prevent one or more wireless power apparatuses from authenticating with the first apparatus or the second apparatus. The method includes the first apparatus communicating one or more transfer messages to transfer the most recent version of the revocation list to the other of the first apparatus and the second apparatus.

[0009] Another innovative aspect of the subject matter described in this disclosure can be implemented as an apparatus that includes a communication unit and a controller or processor configured to control the communication unit to implement any one of the above-referenced methods.

[0010] Details of one or more implementations of the subject matter described in this disclosure are set forth in the accompanying drawings and the description below. Otherfeatures, aspects, and advantages will become apparent from the description, the drawings, and the claims.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Like reference numbers and designations in the various drawings indicate like elements. Note that the relative dimensions of the figures may not be drawn to scale.

[0012] FIG. 1A illustrates an example wireless power system that includes a Power Transmitter and a Power Receiver.

[0013] FIG. 1B illustrates an example revocation list.

[0014] FIG. 2A illustrates an example state diagram of a wireless power system.

[0015] FIG. 2B illustrates other example phases of a wireless power system.

[0016] FIG. 3 shows a message diagram illustrating public key infrastructure (PKI)-based authentication followed by a revocation list update.

[0017] FIG. 4 shows an example revocation list update process.

[0018] FIG. 5A shows an example scenario in the revocation list update process of FIG. 4 in which the Power Receiver does not support the revocation list update process.

[0019] FIG. 5B shows an example modification to the revocation list update process of FIG.4 in which the wireless power apparatuses obtain version information using bidirectional requests and responses.

[0020] FIG. SC show's an example modification to the revocation list update process of FIG.4 in which either or both of the wireless power apparatuses can determine which apparatus has the newer revocation list version.

[0021] FIG. 5D shows an example modification to the revocation list update process of FIG.4 to omit some messaging overhead.

[0022] FIG. 5E shows an example scenario to the revocation list update process of FIG. 4 in which the Power Receiver declines a revocation list update request.

[0023] FIG. 6 shows another revocation list update process in which an update apparatus can provide an updated revocation list to an offline wireless power apparatus.

[0024] FIG. 7 shows another revocation list update process implemented in different wireless power specification than shown in the example of FIG. 4.

[0025] FIG. 8 shows an example scenario to the revocation list update process of FIG. 7 in which the Power Receiver declines a revocation list update request.

[0026] FIG. 9A illustrates a scenario in which an authentication occurs between two wireless power apparatuses having the same version of the revocation list.

[0027] FIG. 9B illustrates a scenario in which a first wireless power apparatus can receive an updated version of the revocation list from a second wireless power apparatus.

[0028] FIG. 9C illustrates a scenario in which the first wireless power apparatus can provide an updated version of revocation list to a third wireless power apparatus.

[0029] FIG. 10 illustrates examples of updating a revocation list.

[0030] FIG. 11 illustrates a scenario in which an updated version of a revocation list can propagate among multiple wireless power apparatuses.

[0031] FIG. 12 illustrates a flow chart with example operations of a first wireless power apparatus in accordance with some aspects of this disclosure.

[0032] FIG. 13 illustrates a flow chart with example operations of a first apparatus in accordance with some aspects of this disclosure.

[0033] FIG. 14 illustrates another flow chart with example operations of a wireless power apparatus in accordance with some aspects of this disclosure.

[0034] FIG. 15A is a diagram of an example packet to request information about a revocation list.

[0035] FIG. 15B is a diagram of an example packet to indicate information about a revocation list.

[0036] FIG. 15C is a diagram of an example packet to indicate which wireless power apparatus has a newer version of the revocation list.

[0037] FIG. 16A is a diagram of an example packet to request information about a revocation list.

[0038] FIG. 16B is a diagram of an example packet to indicate information about a revocation list.

[0039] FIG. 17 is a diagram of an example packet for providing a revocation list.

[0040] FIG. 18A illustrates an example of communicating a revocation list in a plurality of message frames, such as near field communication (NFC) data exchange format (NDEF) frames.

[0041] FIG. 18B illustrates an aspect of the subject matter in accordance with one embodiment,

[0042] FIG. 19A is a diagram of an example packet to indicate information about the revocation list as part of an authentication message.

[0043] FIG. 19B is a diagram of another example packet to request information about the revocation list.

[0044] FIG. 20 illustrates a block diagram of an example apparatus in a wireless power system.DETAILED DESCRIPTION

[0045] The following description is directed to certain implementations for the purpose of describing innovative aspects of this disclosure. However, a person having ordinary skill in the art will readily recognize that the teachings herein can be applied in a multitude of different ways. The described implementations can be implemented in any means, apparatus, system, or method for transmitting or receiving wireless power.

[0046] A wireless power system includes a Power Transmitter (PTx, sometimes also referred to as a wireless power transmission apparatus) and a Power Receiver (PRx, sometimes also referred to as a wireless power reception apparatus). In some implementations, the Power Transmitter includes a primary coil that produces an electromagnetic field during a power state to induce a voltage in a secondary coil of the Power Receiver when the secondary coil is placed in an electromagnetic field of the primary coil. Alternatively, the Power Transmitter can transmit the power using a resonant frequency that induces a voltage in the resonant coil of the Power Receiver. The Power Receiver uses the induced voltage to generate power for a load.

[0047] Before and / or during the transmission of power, the Power Receiver and the Power Transmitter can perform an authentication procedure to authenticate the other device. Authentication can also be referred to as an authentication protocol, authentication mechanism, authentication procedure, or other similar terms. Authentication is intended as a tamper-resistant procedure to verify and trust that the other device complies with the standard wireless power specification. Additionally, an apparatus can enforce policies on allowable products. For instance, a manufacturer concerned about safety issues from inferior products can set limits on power transferred to or from an unauthenticated device. A successful authentication typically involves messaging, which can be referred to as an authentication message exchange. For example, the authentication message exchange can include the communication of a key, a certificate digest, a challenge, a response, or any combination thereof. Furthermore, in some implementations, each authentication might be a bi-directional authentication such that each wireless power apparatus can authenticate the other wireless power apparatus.

[0048] Each device can store authentication information to enable authentication. Authentication information can include a public or global set of public keys, a private key, among other examples. In accordance with this disclosure, authentication information can include revocation data, such as indicia of public keys, manufacturer identifications, device identifications, certificates, or other information about manufacturers or appliances that should not be permitted to authenticate. The revocation data can limit authentication by unauthorized manufacturers or appliances that no longer comply with the specification or which have had their public / private keys revoked by the trusted authority. In some implementations, the revocation data is formatted as an XML revocation list. XML, or Extensible Markup Language, is a markup language designed to store and transport data in a structured format / schema. Although the examples of this disclosure refer to XML revocation list(s), the techniques can apply to any file, data structure, or message format that conveys revocation data or other information.

[0049] It may be desirable to periodically or occasionally update a revocation list. For example, a trusted authority or manufacturers may update the revocation list. A revocation list may be associated with a version number or date that is updated when the revocation data changes, such as when the trusted authority makes a change to one or more public keys, a private key, revocation data, or permission data. Revocations lists are typically stored in a memory of an appliance and might be updated offline, such as during software or firmware updates or during product manufacturing. Some types of appliances have Internet connectivity that enables the appliance to periodically obtain an updated version of the revocation list from a network server. However, some appliances are manufactured as offline devices to reduce cost. An offline device is an apparatus that does not have a network interface for accessing a network, such as an Internet-connected network. An online device is an apparatus that has network connectivity.

[0050] This disclosure provides systems, methods and apparatuses for updating a revocation list in a wireless power system. While the examples of this detailed description are related to updating the revocation list, the same techniques can be used to update other types of information (such as configuration settings, firmware, or protocols, among other examples) in an offline device. A first wireless power apparatus might have an earlier version of the revocation list. For example, the earlier version may have been current at the original manufacture date of the first wireless power apparatus but a newer version has been developed since the original manufacture date. Meanwhile, a second wireless power apparatus might have been manufactured at a later date and might include the newer versi on of the revocation list. Furthermore, the second wireless power apparatus may have Internet connectivity thatenables the second wireless power apparatus to periodically or occasionally obtain newer versions of the revocation list.

[0051] In accordance with aspects of this disclosure, the first wireless power apparatus can obtain the newer version of the revocation list from the second wireless power apparatus. The first wireless power apparatus can update its local storage to store the newer version of the revocation list. Thus, the first wireless power apparatus can benefit from the updated revocation list data even if the first wireless power apparatus is an offline device without a network interface. In some implementations, a revocation list update process is initiated after a successful authentication between the first wireless power apparatus and the second wireless power apparatus. Alternatively, or additionally, some or all messages for the revocation list update process can occur before or as part of the authentication. For example, a first apparatus can authenticate a second apparatus and then send / receive a revocation list update before the second apparatus completes the authentication protocol to authenticate the first apparatus.

[0052] In some aspects of this disclosure, revocation lists can be updated among several wireless power apparatuses within a location (such as different kitchen appliances used with wireless power systems of a kitchen environment). As one or more wireless power apparatuses interact with other wireless power apparatuses, the most recent version of the revocation list can propagate to the other wireless power apparatuses, and so on. When a wireless power apparatus with an updated revocation list is introduced to the location and as various wireless power apparatuses are used with each other, the various wireless power apparatuses can be updated with the most recent revocation list. A newer wireless power apparatus (or one with network connectivity) can provide the updated revocation list to other wireless power apparatuses.

[0053] Particular implementations of the subject matter described in this disclosure can be implemented to realize one or more of the following potential advantages. Use of certified wireless power apparatuses can reduce the occurrence of damage that otherwise might result from a wireless power apparatus that has not been certified to comply with the wireless power specification. The techniques of this disclosure enable a trusted authority or manufacturer policy to propagate a revocation list of devices found to not comply with a wireless power specification. Some aspects of this disclosure enable wireless power apparatuses to benefit from an updated revocation list that is field-updateable or managed by update apparatus (such as a memory card interface, near field communication device, short-range radio frequency communication device, or smart home controller, among other examples).

[0054] For ease of understanding, several examples in this disclosure refer to operations of a Power Transmitter or a Power Receiver. However, the techniques are not limited to such devices. Furthermore, most of the messages and revocation list update process features can be implemented by either Power Transmitter or the Power Receiver. For example, where it is a described that a Power Transmitter initiates the revocation list update process by communicating a first message, the description of the first message can also apply to a Power Receiver that initiates the revocation list update process. A revocation list update process can also be referred to as a protocol, procedure, technique, or any other word to refer to operations related to coordinating a revocation list between multiple devices.

[0055] FIG. 1A illustrates an example wireless power system 100 that includes a Power Transmitter 102 and a Power Receiver 104. In FIG. 1A, dashed lines represent communications to distinguish from solid lines that represent electrical circuit lines. In some implementations, the Power Transmitter may include a countertop-mounted primary coil or a primary coil that is embedded or manufactured in a surface on which a Power Receiver can be placed. A Power Receiver can be configured to wirelessly receive power from the Power Transmitter. Some examples of this disclosure are based on a kitchen environment. For example, the Power Transmitter might be part of a kitchen equipment such as a hob, a countertop, or range, while the Power Receiver might be part of a cordless appliance such as a cordless blender, kettle, toaster, or cooking vessel, among other examples. Alternatively, the Power Receiver can be a phone and the Power Transmitter can be any device that provides wireless power to the Power Receiver according to a wireless power specification.

[0056] This disclosure includes a brief description of wireless power transfer for context. The Power Transmitter 102 and the Power Receiver 104 are two types of wireless power apparatuses that are used together. The Power Transmitter 102 includes a primary coil 101 and a Power Transmitter (PTx) controller 109, The primary coil 101 may be associated with a Power Transmitter circuit 103 (sometimes also referred to as a power signal generator or a driver circuit). The primary coil 101 may be any type of coil which transmits wireless power (which also may be referred to as wireless energy). The primary coil 101 may transmit wireless energy using an inductive or a resonant magnetic field. The Power Transmitter circuit 103 may include components (not shown) to prepare the wireless power. For example, the Power Transmitter circuit 103 may include one or more switches, drivers, series capacitors, rectifiers, inverters, or other components. In some implementations, the Power Transmitter circuit 103, PTx controller 109 and other components (not shown) may be collectively referred to as a Power Transmitter unit 105. Some or all of the Power Transmitter unit 105 may be embodied as an integrated circuit (IC) that implements features of thisdisclosure for controlling and transmitting wireless power to one or more wireless power reception apparatuses. The PTx controller 109 may be implemented as a microcontroller, dedicated processor, integrated circuit, application specific integrated circuit (ASIC) or any other suitable electronic device.

[0057] A power source 106 provides power to the Power Transmitter unit 105. In some implementations, the power source 106 may convert alternating current (AC) power to direct current (DC) power. For example, the power source 106 may include a converter that receives an AC power from an external power supply and converts the AC power to a DC power used by the Power Transmitter circuit 103. Alternatively, or additionally, a component (such as an inverter) of the Power Transmitter circuit 103 may convert the DC power to the AC power. The power source 106 may be integrated as part of the Power Transmitter 102 or may be external to the Power Transmitter 102.

[0058] In some implementations, the Power Transmitter 102 causes the power source 106 to regulate the DC output voltage of the power source 106. For example, the PTx controller 109 can set DC voltage of the power source 106 based on information (such as a value indicating a requested power) received from the Power Receiver 104. The Power Transmitter 102 can receive power configuration information from the Power Receiver 104 and use the information to set a parameter (such as the DC output voltage of the power source 106). The Power Transmitter 102 can receive the power configuration information during various operating states, such as the discovery state or power state. In some implementations, the Power Transmitter 102 includes a DC-DC converter (not shown) between the power source 106 and the Power Transmitter circuit 103 to control the variable DC output voltage.

[0059] The PTx controller 109 is connected to a first communication interface 107. The first communication interface 107 is connected to the first communication coil 108. In some implementations, the first communication interface 107 and the first communication coil 108 may be collectively referred to as the first communication unit 111. In some implementations, the first communication unit 111 may support short-range radio frequency communication, such as Near-Field Communication (NFC), Bluetooth (BT), Thread, ZigBee, Z-wave, Matter, Wi-Fi, or other forms of local radio frequency network communication. NFC is a technology by which data transfer occurs on a carrier frequency of 13.56 Megahertz (MHz). The first communication unit 111 also may support any suitable communication protocol. The first communication unit 111 may contain modulation and demodulation circuits to wirelessly communicate via the first communication coil 108. Alternatively, or additionally, the PTx controller 109 may use frequency, amplitude, current, or voltage modulation of a wireless power signal to communicate via an in-band communication link (not shown) that includesthe primary coil 101. The first communication interface 107 is different from a network interface in that it is not configured to access a network of devices. Rather, the first communication interface 107 is configured for local communication from the Power Transmitter 102 to a Power Receiver, such as Power Receiver 104. Some wireless power appliances might include both a communication unit (such as first communication interface 107) as well as a network interface (not shown). For example, a “smart appliance” might have a wireless local area network (WLAN) interface for communicating with a Wi-Fi network as part of smart home network or a cellular network interface for communicating with a wireless wide area network (WWAN). As described herein, an offline device might include a communication unit (such as first communication interface 107) for peer communication with another wireless power apparatus but does not include a network interface for communication with a network.

[0060] The Power Receiver 104 may include a secondary coil 110, a rectifier 112, a Power Receiver (PRx) controller 113, a second communication interface 115, a load controller 117, a load 114, and a memory (not shown). In some implementations, the load 114 can include a drive (not shown) for controlling at least one parameter such as charging current, speed, or torque of the load. In some implementations, the rectifier 112 may be omitted such as when the voltage induced in the secondary' coil 110 can directly power the load 114. In some implementations, other components, such as a series switch (not shown) and / or capacitors, may be included in series with the secondary coil 110 or in series between the rectifier 112 and the load 114. Although not shown, a load capacitance can be used after the rectifier 112 to reduce the rate of rise of load voltage that would otherwise occur when the load 114 suddenly reduces power consumption. Although shown as different components, some components may be packaged or implemented in the same hardware. For example, in some implementations, the PRx controller 113 and the load controller 117 may be implemented as a single controller. The PRx controller 113, the load controller 117, or any combination thereof, may be implemented as a microcontroller, dedicated processor, integrated circuit, application specific integrated circuit (ASIC) or any other suitable electronic device.

[0061] The PTx controller 109 may detect the presence or proximity of a Power Receiver 104. This detection may happen during a periodic pinging process of the first communication interface 107. During the pinging process, the first communication interface 107 also may¬ supply power to the second communication interface 115 when the Power Receiver 104 is in proximity to the Power Transmitter 102. The second communication interface 115 may “wake up” and power-up the PRx controller 113 and may send a reply signal back to the first communication interface 107. Prior to power transfer, a handshaking process may take placeduring which the PTx controller 109 may receive identification and configuration data, among other information, from the Power Receiver 104. The PTx controller 109 may control characteristics of wireless power it provides to the Power Receiver 104 based on the configuration data.

[0062] A PRx controller 113 may be operationally coupled to the rectifier 112 and the second communication interface 115. The second communication interface 115 may contain modulation and demodulation circuits to wirelessly communicate via the second communication coil 116. Thus, the PRx controller 113 may wirelessly communicate feedback information to the PTx controller 109 via the second communication interface 115 to the first communication interface 107 using short-range radio frequency communication, such as NFC. Alternatively, or additionally, the PRx controller 113 may use load modulation to communicate via an in-band communication link (not shown) that includes the secondary coil 110. In some implementations, the modulation / demodulation circuits are included in the PRx controller 113.

[0063] A load controller 117 may be operationally coupled to the load 114 and the second communication interface 115. The load controller 117 may detect changes to load states such as change in charging currents in a battery charging application. The load controller 117 also may determine a load voltage reference. The load controller 117 also may send load voltage references, load current, and any other suitable information to the PRx controller 113 or the second communication interface 115 for communication to the Power Transmitter 102. The PRx controller 113 may additionally determine and provide feedback information indicating a measured load voltage available to the load 114. In some feedback messages, the feedback information may include a reference value indicating a required voltage or power for the load 114. In some feedback messages, the feedback information may indicate an error in the output voltage of the load 114. In some feedback messages, the feedback information may include the required power for the load.though the PRx controller 113 and load controller 117 are shown separately, they may be included in the same component of the Power Receiver 104.

[0064] Either the Power Transmitter 102 or the Power Receiver 104, or both, may have other components, the description of which is omitted for brevity. For example, the wireless power apparatuses may have alignment aids. Either or both of the wireless power apparatus may- have magnets to aid with alignment and / or wireless power transfer. Other circuit level details, such as capacitors, resisters, impedance matching circuits, and / or tuning circuits may be present.

[0065] In some implementations, the Power Transmitter 102, the Power Receiver 104, or both, may be configured to authenticate the other of the Power Transmitter 102 or the Power Receiver 104. One type of authentication is referred to as a bi-directional authentication. In bi-directional authentication, the Power Transmitter 102 authenticates the Power Receiver 104 and the Power Receiver 104 authenticates the Power Transmitter 102, In some implementations, each authentication can include an authentication message exchange to verify that the second wireless power apparatus is in possession of a private key issued by a trusted authority. The trusted authority might issue private keys to manufacturers that are certified to comply with a wireless power specification. In some implementations, the trusted authority might include a central node or machine that distributes public and private keys as part of a public key infrastructure (PKI). For example, a trusted authority can issue authentication information (such as a private key) to a certified wireless power apparatus. The private key has a corresponding public key. The public key or a root public key can be provided to any wireless power apparatuses configured to authenticate another wireless power apparatus. Using the authentication message exchange, a wireless power apparatus (such as the Power Transmitter 102 or the Power Receiver 104) can verify that the other wirel ess power apparatus is in possession of a private key issued by the trusted authority. Although this disclosure describes PKI-based authentication as one type of authentication, other types of authentication (and their respective protocol for authentication message exchange) can be used for authentication of a wireless power apparatus.

[0066] In some implementations, each wireless power apparatus has an authentication chip (not shown). For example, the authentication chip may be referred to as a microcontroller. The microcontroller may store authentication data, including information for authentication. The microcontroller also may store the revocation list. Ail or part of a revocation list update process of this discl osure can be implemented by the microcontroller, an apparatus controller, or any combination thereof. All or part of the revocation list update process may be implemented in the PTx controller 109, the PRx controller 113, the first communication interface 107, the second communication interface 115, or any other logic component of the wireless power apparatus.

[0067] In some implementations, the private key and one or more root public keys might be stored in a secure memory that is attached, affixed, or integrated, or otherwise non-removable within a wireless power apparatus. For example, the Power Transmitter 102 might include PTx authentication information 132 stored in a secured manner such that the PTx authentication information 132 cannot be removed or becomes unusable if not used with the PTx controller 109 or other components of the Power Transmitter 102. Similarly, the PowerReceiver 104 can include PRx authentication information 134 that is securely stored, affixed, attached, integrated, or otherwise non-removable within the Power Receiver 104.

[0068] In this disclosure, the Power Transmitter 102 and the Power Receiver 104 can also include a revocation list. The revocation list may be considered part of authentication information since it includes information about devices that should not be authenticated, thereby preventing a successful authentication of those devices. As an example, the revocation list might be referred to as a block list to cause authentication to fail for a particular wireless power apparatus or a plurality of untrusted wireless power apparatuses.

[0069] As shown in FIG. 1A, the Power Transmitter 102 includes a first revocation list 142 and the Power Receiver 104 includes a second revocation list 144. Each revocation list may be associated with a particular version. Absent the techniques of this disclosure, the Power Transmitter 102 and the Power Receiver 104 may be unaware if they have an older version of the revocation list compared to the other apparatus.

[0070] There may be advantages to updating the revocation list occasionally. For example, the revocation list may be changed to include a revised list of untrusted appliances or manufacturers to prevent damage from a wireless power apparatus that does not comply with a specification. If a private key becomes hacked or otherwise published, there is a potential for physical harm if an appliance does not comply with the standard. In such situations, it is desirable to update the revocation list to prevent authentication of devices using a compromised or revoked certificate / credential for authentication. This disclosure describes an example revocation list update process and optional variations to enable the Power Transmitter 102 and the Power Receiver 104 to update either the revocation list 142 or the revocation list 144 to a most recent version (e.g., higher version number) that is available from among the revocation list 142 and the revocation list 144.

[0071] FIG. IB illustrates an example revocation list 143. The example revocation list 143 includes version information 150 and revocation data 170. In some implementations, the example revocation list 143 can include a security signature 180 or other information to verify the authenticity of the example revocation list 143, Version information 150 may include a version number 152, a version date 154, or other version data for determining a version of the example revocation list 143. When a version number 152 is used for version control, a higher number (referring to a higher version) can also refer to a newer or more recent version compared to a lower number (referring to a lower version). When a version date 154 is used for version control, a later date may refer to a newer or more recent version compared to an earlier date, version information 150 is one example of information about the revocation list.Examples of this disclosure describe apparatuses sharing version information as a technique for determining which revocation list has a newer version. However, any type of information, metadata, or portion of the revocation list can be used. The term version information can be replaced with “information about the revocation list” or “metadata.” In some implementations, the information can include information about the revocation list (or file transfer), including the size and / or format of the file. Furthermore, the messages described in this disclosure can be modified to carry any type of information (in addition to or in lieu of the version information).

[0072] The revocation data 170 can include any data that a wireless power apparatus can use to prevent a successful authentication of other apparatuses. For example, the revocation data 170 can include a list of revoked certificates 174, a list of banned identifiers (IDs) 176, or other indicia of devices or manufacturers, among other examples.

[0073] In some implementations, the revocation list 143 is formatted as an “. XML” file. Thus, the revocation list 143 can have an XML format 145 that may be machine-readable by a controller or authentication module of a wireless power apparatus. Although described as an XML file, the information can be formatted in any file type, including a comma-separated values (CSV) file, binary file, or text file.?\s mentioned previously, the examples of this disclosure that refer to a revocation list / file can apply to any file, data structure, or message format. For example, the techniques of this disclosure that describe file transfer could also enable transfer of a proprietary file, a software update, version information, or other type of file or information.

[0074] This disclosure provides a variety of techniques for exchanging version information 150 or the revocation data 170. Typically, when a revocation list is transferred from one apparatus to another apparatus, the full revocation list 143 (in XML format 145) is communicated. However, it is also possible to communicate portions of the revocation list 143, such as the revocation data 170. In accordance with this disclosure, apparatuses can implement a revocation list update process to communicate the information about the revocation list (such as version information). The revocation list update process can also include communicating one or more transfer messages for communicating the revocation list 143.

[0075] FIG. 2A illustrates a state diagram 200 A of an example wireless power system. The state diagram 200A illustrates the operating states in which the wireless power system may operate. When a Power Receiver is placed within an operating volume on the interface surface of a Power Transmitter, the two start to communicate to configure and control thepower transfer. In the example of FIG. 2A, there are four operating states associated with the wireless power system: a standby state 202 (sometimes also referred to as a ping state), a discovery state 204 (sometimes referred to as a configuration state), a connected state 206 (sometimes referred to as a negotiation state), and a power state 208 (sometimes referred to as a power transfer state). While four example states are illustrated, the functionality of power transfer communication can be spread over fewer or more operating states. While FIG. 2A provides example names and operations of the example states, different names or operations may be used.

[0076] A technical specification may define how the Power Transmitter and Power Receiver can transition between the operating states. For example, the wireless power system typically begins in the standby state 202 until the Power Transmitter detects a Power Receiver, moving it to the discovery state 204. In the discovery state 204 the Power Transmitter establishes communication and receives the first identification information of the Power Receiver and its configuration data. In the connected state 206 and the power state 208, the Power Transmitter and Power Receiver exchange information to agree and adjust parameters related to wireless power transfer. The system can move to a reinitialization state (not shown) as needed to reinitialize or return to the standby state when communication, powering, or other activities are no longer taking place. Each of the operating states are briefly described herein for reference.

[0077] In the standby state 202, the Power Transmitter tries to establish communication with a Power Receiver. The Power Receiver may be just placed on the interface surface or may not be present during this operating state. The Power Transmitter may attempt to communicate or detect the presence of the Power Receiver. For example, the Power Transmitter may use an analog ping, out-of-band communication (such as NFC or other protocols), a digital ping, or any combination thereof, to determine that a Power Receiver is present. Once the wireless power system determines that a Power Receiver is present (such as by confirming NFC communication), the wireless power system may transition to the discovery state 204.

[0078] In the discovery state 204, the Power Receiver may establish communication 210 with the Power Transmitter and send static configuration information (such as identification and configuration information 212) to the Power Transmitter. For example, the Power Transmitter may retrieve configuration information from the Power Receiver via the NFC communication. The Power Transmitter and the Power Receiver may use this information to verify that they both use compatible versions of a technical specification or protocol for wireless power transfer. The Power Transmitter and Power Receiver may communicate basicsettings or communicate regarding their respective capabilities. From the discovery state 204, the wireless power system may transition to the connected state 206.

[0079] In the connected state 206, the Power Transmitter and the Power Receiver may exchange further communications to negotiate the parameters that govern the power state. For example, a power negotiation can occur during the connected state 206. After negotiating the parameters, the Power Transmitter may be prepared to transfer wireless power and the Power Receiver may be prepared to receive the wireless power. However, the Power Transmitter may wait for a request or command from the Power Receiver before transitioning to the power state 208. This may be useful, for example, when a cordless appliance (such as a blender, toaster, mixer, or microwave, among other examples) is configured for use pending a user interaction. The user may initiate the power state 208 by a user interface (such as an activation switch) of the Power Receiver, which in turn communicates to the Power Transmitter to transition to the power state 208.

[0080] This disclosure describes a revocation list update process 140. In some implementations, the revocation list update process 140 can occur during the connected state 206 following an authentication 230 (which may occur in various states but is illustrated in the discovery state 204 as an example) or as part of the authentication 230. The revocation list update process 140 can also be initiated in other states, such as the discovery state 204 (after the authentication 230) or during the power state 208. The revocation list update process 140 can include communicating one or more information messages 250 and / or one or more transfer messages 270. In some implementations, the revocation list update process can occur as part of an authentication process. The information messages and transfer messages are further described with reference to other figures of this disclosure.

[0081] FIG. 2B illustrates other example phases 200B of a wireless power system. The ping phase 203, the configuration phase 205, the negotiation phase 207, and the power transfer phase 209 can include similar operations as described with reference to corresponding states in FIG. 2A. In some implementations, the revocation list update process 140 can occur during the power transfer phase 209, following an authentication 230. Alternatively, or additionally, the revocation list update process 140 can occur during the negotiation phase 207 or other phases. In some implementations, the revocation list update process 140 is integrated with the authentication 230 such that one or more authentication messages can include information about the revocation list and / or the revocation list.

[0082] FIG. 3 shows a message diagram 300 illustrating public key infrastructure (PKI)-based authentication followed by a revocation list update. The example Power Receiver 104is certified by a trusted authority 301. The trusted authority 301 might create a public key and a private key associated with the manufacturer or product model of the Power Receiver 104. The public key and the private key might be based on a root public key of the trusted authority 301 such that the public key of the manufacturer or product model can be verified by the root public key 302. The trusted authority 301 can provide the root public key 302 (or the public key associated with the Power Receiver 104) to a manufacturer of the Power Transmitter 102. The manufacturer of the Power Transmitter 102 might store the root public key 302 (or the public keys of one or more Power Receivers) as authentication information 304 in a local storage of the Power Transmitter 102. The trusted authority 301 also provides the private key 303 to the manufacturer of the Power Receiver 104 and the manufacturer can securely store the private key in the Power Receiver 104. Although FIG. 3 illustrates the private key 303 for the Power Receiver 104, in some implementations, the trusted authority 301 also can generate and provide a different public / private key pair associated with the Power Transmitter 102. In some implementations, authentication information 304 might include a private key (not shown) of the Power Transmitter 102 or other information used for the authentication 230. In some implementations, the authentication information 304 can also include or refer to algorithms for verifying a public / private key pair. In some implementations, the authentication information 304 can include revocation data (such as a revocation list of revoked public / private keys) or explicit permission (such as an allowed list or indentation information for trusted wireless power apparatuses that do not require authentication).

[0083] In some implementations, the Power Transmitter 102, the Power Receiver 104, or both are offline devices. An offline device does not have the capability of communicating via a network 309. In contrast, a network-connected device (also sometimes referred to as a smart appliance) might have a capability to communicate with the trusted authority 301 via the network 309. In FIG. 3, the Power Transmitter 102 and the Power Receiver 104 are offline devices such they do not have the capability to obtain updates (e.g., update 305 for the Power Transmitter 102 or update 307 for the Power Receiver 104) via the network 309.

[0084] In some implementations, revocation list might refer to a public or global set of public keys, block list, allowed list, among other examples. The revocation list might change over time as the trusted authority 301 or one or more manufacturers make updates to the revocation list. For pedagogical purposes, authentication information might be referred to as having a version. A version might be based on a version number or date when the authentication information was generated or updated, such as when the trusted authority 301 makes a change to one or more public keys, a private key, revocation data, or permission data.

[0085] In one example scenario of FIG. 3, the Power Transmitter 102 might have a previous version of the revocation list 342. The Power Receiver 104 might have a newer version of the revocation list 344. In accordance with aspects of this disclosure, following a successful authentication 230 (or as part of authentication 230), the Power Transmitter 102 can implement a revocation list update process 140 to obtain the revocation list 344 from the Power Receiver 104. For example, the revocation list update process 140 includes one or more messages 350 to get information about the revocation list and / or to transfer the revocation list 344. Although the scenario of FIG. 3 is based on the Power Receiver 104 having a newer version of the revocation list compared to the Power Transmitter 102, it might also be possible that the Power Transmitter 102 has a newer version of the revocation list compared to the Power Receiver 104. In some implementations, whichever wireless power apparatus has the newest version of the revocation list can provide the newest version to the other wireless power apparatus. For example, the Power Transmitter 102 can provide a revocation list update to the Power Receiver 104 if the Power Transmitter 102 has a newer version of the revocation list.

[0086] FIG. 4 shows an example revocation list update process 440 following a successful authentication 230 between the Power Transmitter 102 and the Power Receiver 104. The revocation list update process includes one or more information messages 250 and one or more transfer messages 270. In the example of FIG. 4, the Power Transmitter 102 may initiate the update process by transmitting a version request message 452. However, in other implementations the Power Receiver 104 can initiate the update process and send the version request message 452 to the Power Transmitter 102.

[0087] The version request message 452 can include a request for information about the revocation list stored at the Power Receiver 104. For example, the version request message 452 can request a version number or version date. An example of the version request message 452 is referred to as a “RQST / MEAS / REVNO” packet (further described with reference to FIG. 15 A) or a ‘‘RQST / REVNO" packet (further described with reference to FIG. 16A). The Power Receiver 104 responds to the version request message 452 by sending a version response message 453 (such as the “MEAS / REVNO” or “REVNO” packets described with reference to FIG. 15B or FIG. 16B, respectively). The version response message 453 indicates the version number, version date, or other version information about the revocation list stored at the Power Receiver 104. At block 455, the Power Transmitter 102 can determine whether the local version information (e.g., version of the revocation list at the Power Transmitter 102) matches or is different from the received version information (e.g., version of the revocation list at the Power Receiver 104). For example, at block 455, the Power Transmitter102 can compare the received version information with its currently stored version of the revocation list at the Power Transmitter 102. Furthermore, based on the version information, the Power Transmitter 102 can determine which apparatus has the most recent version of the revocation list. The Power Transmitter 102 can transmit a version results message 458 to inform the Power Receiver 104 regarding which version is most recent or if both apparatuses have the same version of the revocation list. An example version results message 458 is referred to as a version measurement packet (such as the example “MEAS / AVER” packet described with reference to FIG. I5C).

[0088] If both apparatuses 102 and 104 have the same version of the revocation list, the revocation list update process 440 may end after the one or more information messages 250. If one apparatus has an older version of the revocation list, it may request an update from the other apparatus. Alternatively, or additionally, an apparatus having a newer list may transfer its version of the revocation list either in response to a request or on its own initiative. FIG.4 describes two example scenarios for transferring a revocation list, shown as one or more transfer messages 270. In a first example (shown as revocation list transfer 470a), the Power Transmitter 102 requests an update from the Power Receiver 104. In a second example (shown as revocation list transfer 470b), the Power Receiver 104 requests an update from the Power Transmitter 102. Typically, the revocation list update process 440 would only include at most either one instance of the revocation list transfer 470a or the revocation list transfer 470b.

[0089] In the first example (shown as revocation list transfer 470a), the Power Transmitter 102 transmits a revocation list request message 472a. For example, the revocation list request message 472a may be a “RQST / MEAS / REVLIST” packet or a “RQST / REVLIST” packet. Although not illustrated separately, the “RQST / MEAS / REVLIST” packet or “RQST / REVLIST” packet is similar to the formats for “RQST / MEAS / REVNO” or “RQST / REVNO” packets of FIG. 15 / A and FIG. 16A, except that the Extension field or Message Type field have different values to refer to “REVLIST” instead of “REVNO” type messages. The revocation list request message 472a requests the receiving device to transmit its revocation list. In response to the revocation list request message 472a, the Power Receiver 104 transmits its revocation list in a revocation list response message 474a. An example of the revocation list response message 474a is described as the “REVLIST” packet of FIG. 17. Alternatively, the 474a might be implemented as a “MEAS / REVLIST” packet, where the “REVLIST” message is included in a payload of the “MEAS” packet and the “MEAS” packet has an extension field value to indicate the payload includes the “REVLIST” message.

[0090] / Xfter receiving the revocation list of the Power Receiver 104, the Power Transmitter 102 may transmit an acknowledgment message 476a (such as a “RESP / ACK” packet). It is noted that the names of the one or more transfer messages 270 may be specific to a particular wireless power specification, and other wireless power specifications may have different names for similar messages. For example, the revocation list request message 472a may be referred to as a “GET / rlist” packet described with reference to FIG. 19B, having the same functionality as the “RQST / MEAS / REVLIST” or “RQST / REVLIST” packet.

[0091] The second example (shown as revocation list transfer 470b) is the same as described for the first example (revocation list transfer 470a) except that the directions of the messages are reversed because in revocation list transfer 470b, the Power Receiver 104 requests the revocation list of the Power Transmitter 102. The messages 472b, 474b, and 476b may have the same or similar formats as described for messages 472a, 474a, and 476a, respectively.

[0092] Having described an example revocation list update process 440 in FIG. 4, there are some potential modifications and scenarios that can be briefly described with reference to FIG. 5A through FIG. 5E. Generally speaking, similar events in FIGs 5A-5E are labeled with reference numbers that have the same lower-order digits. For brevity, similar messages or events are not discussed in detail in each instance, but the discussion of a certain messages with reference to one of the figures also applies to similar messages in other figures. For brevity, the descriptions of messages and blocks are abbreviated to focus on the differences among the features while omitting redundant explanation.

[0093] FIG. 5A shows an example scenario 500a in the revocation list update process of FIG. 4 in which the Power Receiver does not support the revocation list update process. After sending the version request message 452, the Power Transmitter 102 may start a tinier waiting for a response. If the Power Receiver 104 does not respond before expiration of the timer, the Power Transmitter 102 may presume that the Power Receiver 104 does not support the revocation list update process features of this disclosure. Alternatively, the Power Receiver 104 may respond to the version request message 452 with a message 557 having a value (e.g., “00”) for the version number indicating that the Power Receiver 104 does not support the revocation list update process or refuses to provide the requested version information. When the there is no response, a timeout, or value indicating the revocation list update process is not supported, the Power Transmitter 102 may end the revocation list update process to reduce communication overhead. In some implementations, the Power Transmitter 102 may reattempt the version request message 452 for a threshold quantity of attempts (e.g., 2, 3, or 4 attempts) before determining that the Power Receiver 104 does not support the revocation list update process.

[0094] FIG. 5B shows an example modification 500b to the revocation list update process of FIG. 4 in which the wireless power apparatuses obtain version information using bidirectional requests and responses. A potential technical advantage of this approach is that the “MEAS / AVER” packet does not need to be defined in the wireless power specification. Instead, the “RQST / MEAS / REVNO” (or “RQST / REVNO”) and the “MEAS / REVNO” (or “REVNO”) packets can be reused for exchanging version information. The Power Transmitter 102 transmits a version request message 452 to the Power Receiver 104 which responds with a version response message 453. Then, the Power Receiver 104 transmits a version request message 552 to the Power Transmitter 102, which responds with a version response message 553. After exchanging version information, either device may initiate the one or more transfer messages 270 (e.g., revocation list transfer 470a or revocation list transfer 470b).

[0095] FIG. 5C shows an example modification 500c to the revocation list update process of FIG. 4 in which either or both of the wireless power apparatuses can determine which apparatus has the newer revocation list version. FIG. 5C provides a modification to reduce at least one of the version communication messages 250 described with reference to FIG. 4. A potential technical advantage of this approach is reducing communication overhead. In the example of FIG. 5C, the Power Transmitter 102 transmits a version report / request message 551 that includes the request for version information from the Power Receiver 104 and also includes version information about the revocation list at the Power Transmitter 102. Thus, the Power Transmitter 102 can concurrently report its version while requesting the version information of the Power Receiver 104. After receiving the version response message 453, the Power Transmitter 102 can compare (block 555a) its own version information with the received version information to determine which apparatus has the most recent version. Similarly, because the Power Transmitter 102 includes its version information in the version report / request message 551, the Power Receiver 104 can also compare (block 555b) its version information with the version information received from the Power Transmitter 102. Either or both apparatus can determine which apparatus has a most recent version and request the revocation list from the apparatus having the most recent version.

[0096] FIG. 5D shows an example modification 500d to the revocation list update process of FIG. 4 to omit some messaging overhead. In some implementations, the one or more information messages 250 can be omitted. Instead, the revocation list update process can proceed with the one or more transfer messages 270. A potential technical advantage of this approach is that version information is not exchanged, reducing some initial steps and communication delay. Furthermore, the Power Receiver 104 may be a device with Internetaccess (such as a phone or smart home appliance) that the Power Receiver 104 can use to occasionally receive obtain the revocation list. The Power Transmitter 102 might be an offline device and might skip the preliminary information messages and assume the Power Receiver 104 has a most recent version. The Power Receiver 104 may choose whether or not to proceed with the revocation list transfer messages.

[0097] The revocation list transfer messages (e.g., in revocation list transfer 470a and 470b) may be omitted if both apparatuses have the same version or recently performed a revocation list transfer. Therefore, the modification 500d may be implemented based on a condition, such as the date of the version stored at the apparatus. For example, if the Power Transmitter 102 is an offline device and has a version of the revocation list that is more than X months old (where X is a quantity of months, such as 0, 6, 12, 18 months), the Power Transmitter 102 may skip the preliminary information messages and immediately send a revocation list request message (e.g., message 472a for revocation list transfer 470a) to initiate a revocation list transfer. If the received revocation list is the same as the version already stored at the Power Transmitter 102, the Power Transmitter 102 may discard the received revocation list or interrupt the revocation list transfer. Alternatively, if the received revocation list is an older version than the version already stored at the Power Transmitter 102, then the Power Transmitter 102 may proactively initiate a revocation list transfer message (e.g., " REVLIST" packet, similar to the revocation list response message 474b), with or without having received a revocation list request message 472b). Alternatively, the Power Transmitter 102 might send a ‘‘MEAS / AVER’’ packet to inform the Power Receiver 104 that the Power Transmitter 102 has a more recent version. In some implementations, when the Power Receiver 104 is informed that the Power Transmitter 102 has a more recent version, the Power Receiver 104 can request the revocation list from the Power Transmitter 102 (such as by sending a revocation list request message 472b of the revocation list transfer 470b)

[0098] FIG. 5E shows an example scenario 500e to the revocation list update process of FIG. 4 in which the Power Receiver declines a revocation list update request. In response to receiving the version request message 452 from the Power Transmitter 102, the Power Receiver 104 may elect to refrain from participating in the revocation list update process. For example, the Power Receiver 104 may wish to avoid providing its revocation list depending on manufacturer, requesting device type, or location (such as a public space where the Power Transmitter 102 may be shared by unauthenticated devices). For any reason, the Power Receiver 104 can transmit a rejection message 558. In some implementations, the rejection message 558 can be formatted to indicate that the Power Receiver 104 declines the versionrequest message 452. Alternatively, the rejection message 558 can be a nonacknowledgement (NAK) message.

[0099] After receiving the rejection message 558, the Power Transmitter 102 may end the revocation list update process (shown at block 559).

[0100] Although FIG. 5A through FIG. 5E includes several example scenarios and modifications, other variations are possible. For example, if a revocation list transfer has stopped before being completed (e.g., due to taken off the device or could be other reasons), an apparatus may retain the previous version of the revocation list it already has. In some implementations, an apparatus can send a non-acknowledgement (NAK) or refrain from sending an acknowledgement (ACK) if the revocation list transfer has not completed. In some implementations, an apparatus may retain an original version of the revocation list (e.g., the version created at time of manufacturing) in addition to or in lieu of any version(s) of the revocation list received from other devices. For example, a wireless power apparatus may store a manufacturing version of the revocation list in a static memory (such as in the authentication chip or a near field communication (NEF) data exchange format (NDEF) message). The NDEF can also store the version date or version number for the revocation list as part of static data.

[0101] In some implementations, because NDEF is static data and cannot be changed, a microcontroller may store a most recent version of the revocation list in a memory (such as a non-volatile memory or local memory). Memory can refer to any storage device capable of storing information, such as those described further with reference to FIG, 20. The microcontroller may check its memory and the NDEF to obtain the most recent version of the revocation list. To overcome a potential data failure or problem with a received revocation list, in some implementations, an apparatus can store a backup copy of the original (or previous) revocation list. When implemented in NDEF, the copy of the revocation list in the NDEF can serve as a backup of a version of the revocation list at time of manufacturing. In some implementations, either apparatus can transmit an error message if it cannot send, receive, process, or store the revocation list. This error message allows either apparatus to signal a communication, storage, or other fault during the revocation list update process. In some implementations, the first wireless power apparatus and the second wireless power apparatus can continue with power transfer following a successful authentication even if the revocation list transfer was unsuccessful or some other fault occurred.

[0102] FIG. 6 shows another revocation list update process 640 in which an update apparatus can provide an updated revocation list to an offline wireless power apparatus. Therevocation list update process 440 of FIG. 4 is described as a procedure between one or more other wireless power apparatuses (e.g., the Power Transmitter 102 and the Power Receiver 104). However, the revocation list update process 440 is not limited to wireless power apparatuses and can be used with other types of devices. For example, as shown in FIG. 6, the revocation list update process 640 can be used between an offline wireless power apparatus 602 and an update apparatus 604. The update apparatus 604 might be another wireless power apparatus, or could be any type of device that can communicate one or more information messages 250 and one or more transfer messages 270. In some implementations, the update apparatus 604 might be an NFC card, Bluetooth signal, smart home controller, memory card, chip, or any other device. In some implementations, the update apparatus 604 is designed for servicing the offline wireless power apparatus 602 by a field technician, property owner, or manufacturer. In some implementations, the update apparatus 604 can be part of a smart home network or local area network.

[0103] In some implementations, the offline wireless power apparatus 602 and the update apparatus 604 perform an authentication 630 (similar to the authentication 230 previously described). Alternatively, or additionally, the authentication 630 can be an abbreviated authentication, such as where the update apparatus 604 provides credentials or other means of authenticating with fewer authentication messages. The one or more information messages 250 (such as the version request message 452 and version response message 453) can be as described with reference to FIG. 4. Alternatively, the one or more information messages 250 may be omitted, as described with reference to FIG. 5D

[0104] In some implementations, the one or more transfer messages 270 may be modified when using an update apparatus 604. For example, the update apparatus 604 may transmit a revocation list transfer initiation message 672 to inform the offline wireless power apparatus 602 that it is ready to transfer the updated revocation list. The offline wireless power apparatus 602 may respond with an ACK message 674. In some implementations, the revocation list transfer initiation message 672 and ACK message 674 can be omitted, such as when the update apparatus 604 has completed an abbreviated or omitted authentication designed for this purpose. The update apparatus 604 transmits the revocation list message 676 (e.g., a “MEAS / REVLIST” or “REVLIST” packet) to provide the revocation list from the update apparatus 604 to the offline wireless power apparatus 602. After receiving the revocation list, the offline wireless power apparatus 602 may respond with an ACK message 678.

[0105] FIG. 7 shows another example revocation list update process 740 implemented in different wireless power specification than shown in the example of FIG. 4. Some examplesof FIG. 4 are based on a Ki wireless power specification for kitchen appliances. FIG. 7 provides an example for Qi wireless power specification for other types of devices. Because the wireless power specifications might have different communication protocols, the various messages might be adapted based on the communication protocol of the wireless power specification. In some implementations, a wireless power specification defines different power profiles, such as a baseline power profile (BPP), an extended power profile (EPP), and a magnetic power profile (MPP). Other power profiles may be developed in the future. Each power profile is associated with a protocol, supported power levels, and design features. For example, the EPP or MPP power profiles support authentication and can be adapted to implement the revocation list update process features of this disclosure. In some implementations, a wireless power apparatus can determine whether to initiate the revocation list update process based on the power profile or capability information of the other device.

[0106] In FIG. 7, Power Transmitter 102 and the 104 may begin an authentication 731. During authentication, several authentication messages 720 are exchanged. For brevity, the detailed protocol for authentication messages 720 is omitted from FIG. 7. One or more of the authentication messages 720 may be adapted to include information about the revocation list. For example, the authentication messages 720 can include a GET DIGEST packet 732 from the Power Receiver 104 to the Power Transmitter 102 and a DIGEST response packet 734 from the Power Transmitter 102 to the Power Receiver 104. In some implementations, the GET DIGEST packet 732 and / or the DIGEST response packet 734 may be modified to include information about the revocation list as described with the one or more information messages 250. For example, FIG. 19A shows an example GET DIGEST packet that includes information about the revocation list. Alternatively, or additionally, new packet types may be specified to request and receive the information about the revocation list (in addition to or in lieu of the GET DIGEST and DIGEST packets). For example, the new packet types may be added as a step in the authentication, such as before or after the GET DIGEST / DIGEST message exchange.

[0107] Although shown as part of the authentication messages 720, it is possible for the Power Transmitter 102 and the Power Receiver 104 to exchange revocation list version information during power transfer phase. In some implementations, the revocation list transfer 770 can occur as part of the authentication or after the authentication is complete (shown at optional event 739). In some implementations, the revocation list transfer 770 (and / or any precursor information messages) can occur during a power transfer phase (not shown).

[0108] According to the communication protocol, the Power Receiver 104 may periodically send an extended control error (XCE) packet 772. Following the XCE packet 772, the Power Transmitter 102 may transmit an attention (ATN) packet 774. The ATN packet 774 informs the Power Receiver 104 that the Power Transmitter 102 requests further communication. The Power Receiver 104 opens a data stream and sends a poll message (shown as DSR / POLL packet 776) to give an opportunity for the Power Transmitter 102 to communicate further packets. Once the data stream is open, the Power Transmitter 102 can transmit a GET / rlist packet 778. The GET / rlist packet 778 is further described with reference to FIG. 19B. The GET / rlist packet 778 is similar to the revocation list request message 472a described with reference to FIG. 4. In response to the GET / rlist packet 778, the Power Receiver 104 transmits an auxiliary' data control (ADC) packet (shown at ADC / rlist packet 780) indicating that it is preparing to transmit the revocation list. The Power Transmitter 102 may respond with an ACK packet 782.

[0109] The Power Receiver 104 can transmit the revocation list in a plurality of auxiliary data transport (ADT) frames (shown as ADT packet(s) 784). In some implementations, the revocation list is larger than can be addressed by a single ADC and its related ADT frames. Therefore, the Power Receiver 104 may need to send one or more further ADC frames (not shown), each followed by ADT frames (not shown) to transfer portions of the revocation list until the revocation list can be fully transferred. For each set of ADT frames, the Power Transmitter 102 can transmit an acknowledgement frames (not shown) to indicate the ADT frames have been received. Once the revocation list has been received, the Power Transmitter 102 can transmit the Power Transmitter 102 can transmit an ACK packet 785 to indicate it has received the revocation list and to conclude the revocation list update process 740. The Power Transmitter 102 can then store the received revocation list, thereby updating its memory with a most recent version of the revocation list.

[0110] FIG. 8 shows an example scenario 800 to the revocation list update process of FIG.7 in which the Power Receiver declines a revocation list update request. The difference between FIG. 8 and FIG. 7 is that the Power Receiver 104 can elect to not provide its revocation list for any reason (similar to FIG. 5E). The Power Receiver 104 can transmit a NAK packet 879 (or any type of rejection / error message) to indicate it will not provide the revocation list in response to the GET / rlist packet 778. At block 559, the Power Transmitter 102 can end the revocation list update process based on receiving the NAK packet 879. In some implementations, a failure to update the revocation list does not prevent the wireless power protocol from continuing with power transfer according to next steps of the authentication or power transfer operations.

[0111] F IGs. 9 A, 9B, and 9C illustrated various scenarios in which revocation list is updated as a result of interactions between a Power Transmitter 902 and one or more Power Receivers 904, 905, and 906. The Power Transmitter 902 can be any Power Transmitter, such as Power Transmitter 102 described with reference to FIG. 1A or other FIGs. of this disclosure. The Power Receiver 904, 905, and 906 can be any Power Receiver, such as Power Receiver 104 described with reference to FIG. 1A or other FIGs. of this disclosure. In FIG. 9A, both the Power Transmitter 902 and the first Power Receiver 904 have the same first version of the authentication information. In FIG. 9B, the Power Transmitter 902 receives an update of the authentication information from the second Power Receiver 905. In FIG. 9C, the Power Transmitter 902 provides an update of the authentication information to a third Power Receiver 906.

[0112] FIG. 9A illustrates a scenario 900a in which an authentication occurs between two wireless power apparatuses having the same version of the revocation list. The Power Transmitter 902 stores a first version of revocation list 942 (at PTx) and the first Power Receiver 904 stores a first version of revocation list 944 (at PRx). The first version of revocation list 942 (at PTx) and the first version of revocation list 944 (at PRx) might be the same revocation list. For example, the revocation lists 942 and 944 might be associated with the same version number or version date.

[0113] FIG. 9B illustrates a scenario 900b in which a first wireless power apparatus can receive an updated version of the revocation list from a second wireless power apparatus. The Power Transmitter 902 stores the first version of revocation list 942 (at PTx). However, different from the scenario of FIG. 9A, in FIG. 9B, the second Power Receiver 905 might have a second version of revocation list 943. The second version of revocation list 943 might be in addition to the PRX's first version of revocation list 944 (as shown in FIG. 9B) or might be in lieu of the first version of revocation list 944 (at PRx). After a successful authentication, the second Power Receiver 905 provides the second version of revocation list 943 to the Power Transmitter 902 using the revocation list update process (shown at arrow 940a).

[0114] FIG. 9C illustrates a scenario 900c in which the first wireless power apparatus can provide an updated version of revocation list to a third wireless power apparatus. Continuing with the example from FIG. 9B, the Power Transmitter 902 might interact with a different Power Receiver (such as a third Power Receiver 906). Following a successful authentication, the Power Transmitter 902 can provide the second version of revocation list 945 to the third Power Receiver 906 using the revocation list update process (shown at arrow 940b) so that the third Power Receiver 906 can store the second version of revocation list 945 (shown as second version of revocation list 946).

[0115] FIG. 10 illustrates examples of updating a revocation list. The examples of FIG. 10 might be implemented by any wireless power apparatus (such as a Power Transmitter or a Power Receiver) that receives a revocation list update from another wireless power apparatus.

[0116] In the first example 1004, a wireless power apparatus might replace (shown as arrow 1003) a first version of revocation list 1001 with a second version of revocation list 1002. For example, the wireless power apparatus might erase the first version of revocation list 1001 from the local storage and cause the second version of revocation list 1002 to be stored in the local storage.

[0117] In the second example 1006, a wireless power apparatus might process a revocation list update 1005 as an update to the first version of revocation list 1001. For example, the revocation list update 1005 might include a subset of the elements stored in the first version of revocation list 1001. An advantage of this technique is that communication overhead and time can be reduced because the revocation list update 1005 might include only those elements that have changed from the first version of revocation list 1001 to the second version of revocation list 1002. The second version of revocation list 1002 can be derived as a combination of the first version of revocation list 1001 with additions or modifications from the revocation list update 1005.

[0118] In the third example 1011, a wireless power apparatus might receive revocation list updates 1008, 1009, and 1010 from different other wireless power apparatuses (following various instances when the other wireless power apparatuses are used with the wireless power apparatus). The wireless power apparatus might maintain the most recent version of revocation list 1007 in a local memory of the wireless power apparatus. For example, the most recent version of revocation list 1007 might be the revocation list that has the highest version number or latest date information from among the first version of revocation list 1001 and the revocation list updates 1008, 1009, and 1010.

[0119] FIG, 11 illustrates a scenario in which an updated version of a revocation list can propagate among multiple wireless power apparatuses. FIG. 11 includes a combination of several updates such as those described with reference to FIG. 9A, FIG. 9B, and FIG. 9C. Consider an example scenario in which a home or business includes a plurality of appliances including a first Power Transmitter 1101, a second Power Transmitter 1102, and several Power Receivers. A new appliance is purchased for use in the home or business. In the example of FIG. 11 the newest appliance (meaning the most recently manufactured) is the second Power Receiver 905. The second Power Receiver 905 might include a most recentversion of the revocation list, while the other Power Receivers and Power Transmitters have an earlier version of the revocation list.

[0120] Using the techniques of this disclosure, when the second Power Receiver 905 interacts with the first Power Transmitter 1101, the first Power Transmitter 1101 can be updated to store the most recent version of revocation list 1122. For example, the second Power Receiver 905 might be included in a kettle appliance and the first Power Transmitter 1101 might be included in a kitchen hob or countertop. As a result of using the kettle appliance with the kitchen hob or countertop, the most recent version of revocation list 1122 can communicate 1104 an updated revocation list to the kitchen hob or countertop. The kitchen hob or countertop might be an offline device.

[0121] Later, a different appliance might be used with the kitchen hob or countertop. For example, the first Power Receiver 904 might be included in a blender. The first Power Receiver 904 might have a version of the revocation list that is not as recent as the most recent version of the revocation list stored at the first Power Transmitter 1101. When the blender is placed on the kitchen hob or countertop, the first Power Receiver 904 can obtain 1105 the updated revocation list from the first Power Transmitter 1101. Similarly, when an appliance (such as a toaster) having the third Power Receiver 906 is used with the kitchen hob or countertop, the third Power Receiver 906 can obtain 1106 the updated revocation list from the first Power Transmitter 1101,

[0122] The revocation list can continue to propagate as wireless power apparatuses are used with each other. Continuing with the foregoing example, when the toaster (containing the third Power Receiver 906) is placed on a different wireless Power Transmitter (such as the second Power Transmitter 1102), the third Power Receiver 906 can communicate 1107 the updated revocation list to the second Power Transmitter 1102. The second Power Transmitter 1102 can communicate 1108 the updated revocation list to a fourth Power Receiver 1112 when an appliance containing the fourth Power Receiver 1112 (such as a food processor) is used with the second Power Transmitter 1102.

[0123] Thus, each time a new appliance is introduced to the location, it can serve as the source of a revocation list update that propagates to other wireless power apparatuses as they are used. Therefore, in some implementations, updates can be accomplished by introducing a new appliance to the location. In some implementations, an inexpensive wireless power apparatus (such as an NFC tag or other device designed for the purpose of transmitting an update) can be used to source a revocation list update. An advantage of this technique is thatregistered users or subscribers can receive updates using material purchased at a store or by mail.

[0124] In some implementations, one of the wireless power apparatuses might be a smart appliance with a network connection. For example, referring to FIG. 11, the second Power Receiver 905 might include a network interface 1110 for accessing a network 1103. The network interface 1110 might be a wireless local area network (WLAN, such as WiFi), a cellular interface for a wide area network, a satellite interface, or other suitable network interface for accessing a host device 1111 via the network 1103. The host device 1111 can be a server, another wireless power appliance, a smart card, a mobile phone, a home server, or any type of device capable of storing a revocation list for the wireless power system and providing an updated revocation list to a Power Receiver or a Power Transmitter. In the example of FIG. 11, the second Power Receiver 905 can obtain 1109 an updated revocation list from the host device 1111 via a periodic query, or on-demand request, or a push update. The second Power Receiver 905 can update its most recent version of revocation list 1122 based on the revocation list update 1109. Then, as described earlier, the revocation list can propagate to the other wireless power apparatuses (such as the first Power Transmitter 1101, the first Power Receiver 904, the third Power Receiver 906, the second Power Transmitter 1102, and the fourth Power Receiver 1112).

[0125] FIG. 12 illustrates a flow chart with example operations 1200 of a first wireless power apparatus in accordance with some aspects of this disclosure. For example, the operations might be performed by the Power Transmitter 102 or the Power Receiver 104 described with reference to other Figures of this disclosure.

[0126] At block 1225, the first wireless power apparatus communicates with a second wireless power apparatus. At block 1230, the first wireless power apparatus performs a successful authentication of the second wireless power apparatus based, at least in part, on a first revocation list stored in a memory of the first wireless power apparatus. At block 1250, the first wireless power apparatus initiates a revocation list update process between itself and the second wireless power apparatus during or after the successful authentication of the second wireless power apparatus.

[0127] FIG. 13 illustrates a flow chart with example operations 1300 of a first apparatus in accordance with some aspects of this disclosure. For example, the operations might be performed by the Power Transmitter 102 or the Power Receiver 104 described with reference to other Figures of this disclosure. Alternatively, the operations may be performed by an offline wireless power apparatus or an update apparatus, among other examples.

[0128] ?\t block 1350, the first apparatus communicates one or more information messages to determine if either the first apparatus or the second apparatus has the most recent version of a revocation list, enabling them to assess compatibility and prevent unauthorized authentication. At block 1370, the first apparatus communicates one or more transfer messages to provide the most recent version of the revocation list to the other apparatus.

[0129] FIG. 14 illustrates another flow chart with example operations 1400 of a wireless power apparatus in accordance with some aspects of this disclosure. For example, the operations might be performed by the Power Transmitter 102 or the Power Receiver 104 described with reference to other Figures of this disclosure.

[0130] At block 1402, the first wireless power apparatus authenticates a peer wireless power apparatus. At decision block 1404, the first wireless power apparatus determines whether the peer wireless power apparatus has a more recent version of the revocation list compared to the first wireless power apparatus. For example, the first wireless power apparatus might provide version information or date information to the peer wireless power apparatus and request a revocation list update if the peer wireless power apparatus has a more recent version of the revocation list. Alternatively, or additionally, the first wireless power apparatus might receive version information or date information from the peer wireless power apparatus and determine whether to request the updated revocation list from the peer wireless power apparatus. If the peer wireless power apparatus has updated revocation list available for the first wireless power apparatus, the flow chart continues to block 1406. Otherwise, the flow chart proceeds to decision block 1410.

[0131] At block 1406, the first wireless power apparatus obtains the updated revocation list from the peer wireless power apparatus. At block 1408, the first wireless power apparatus updates a local storage based on the updated revocation list. At block 1414, the first wireless power apparatus proceeds with a wireless charging protocol.

[0132] Returning to decision block 1410, if the peer wireless power apparatus does not have the updated revocation list to provide to the first wireless power apparatus, then another inquiry is whether the first wireless power apparatus has an updated revocation list compared to the peer wireless power apparatus. At decision block 1410, if the first wireless power apparatus does not have an updated revocation list to provide the peer wireless power apparatus, the flow chart continues to block 1414 to proceed with the wireless charging protocol. Otherwise, if the first wireless power apparatus does have an updated revocation list compared to the peer wireless power apparatus, the flow chart continues to block 1412.At block 1412, the first wireless power apparatus provides the updated revocation list to the peer wireless apparatus. Thereafter, the flow chart continues to block 1414.

[0133] FIG. 15A through FIG. 19B include diagrams of example formats and data in various communication packets. The sizes and placement of the fields are shown for illustrative purposes and any of the described fields can be increased or decreased in size or placed in different byte / bit locations. A technical specification may specify the byte / bit locations and sizes of the fields. Furthermore, the values described for various message types or extension fields can refer to a value in a lookup table. For ease of reference, possible values are shown in the figures and described in the text. However, the example values may be replaced with any numerical value in the lookup table. Furthermore, this disclosure includes possible names for various packets / messages. The described names are intended to provide clarity and can be replaced with any other word or name. For example, a “REVNO” packet or message could be given a different name, such as “REVNUM,” “REVVER,” “RNUM,” “RLVER,” or any other name that refers to a communication for information about the revocation list. Similarly, the name for a “REVLIST” packet can also be changed to any other name that refers to a communication including a revocation list such as " AUTHRL", “AUTHREVL.” or “REVL,” among other examples.

[0134] FIG. 15A is a diagram of an example version request packet 1552 for requesting information about the recipient's revocation list. In some technical specifications, the version request packet 1552 can be referred to as a “RQST / MEAS / REVNO” packet, where “RQST” refers to a message for requesting the recipient send a requested “MEAS / REVNO” packet and “MEAS / REVNO” refers to the requested packet (e.g., a “MEAS” packet containing the “REVNO” message). An example general message structure includes a Message Type field 1512, an Extension field, and a Payload; however, various other fields can be included based on particular protocol implementation. The value populated in the Message Type field 1512 corresponds with an index table of different values for different message types (such as, for example, those in Table 1).Table 1. Message TypesMessageMessageType field Sender DescriptionNamevalue- STAT Any Status of the senderCommunication, provides protocol support 0 COMM Anyinformation1 CTRL PRx Control, control the power2 NEXT Any Next, proceed to the requested state3 NEGO Any Negotiate, exchange negotiation parameters4 MEAS Any Measure, provide measurement data5 RQST Any Request, request a particular message to be sent 6 RESP Any Response, respond to a proposalAny authentication, transport service for 7 AUTH Anyauthentication8-14 Reserved15 PROP Any

[0135] In this example, for a version request packet 1552 (e.g., RQST / MEAS / REVNO"), the Message Type field 1512 is populated with a value (e.g., “5” for " RQST") indicating the message is a request message. The Payload field 1514 includes is populated with another copy of the general message structure. In the Payload field 1514, the Message Type 1516 (for the requested message type) is populated with a value (e.g., “4” for MEAS") indicating the requested message type is a MEAS packet. The Extension field 1574 is populated with a value (e.g., “5”) associated with the “REVNO” message. Table 2 includes possible extension field values for the MEAS packet.Table 2. Extension field of the MEAS messageExtensionMnemonic Sender Descriptionfield value0 P PTx Power. Average transmitted power level1 t PTx Temperature, measured2 cv PRx Carrier voltage3 cap PTx Capability4 ident PTx Identity5 REVNO Any revocation list version number / date6 AVER Any version comparison results7 REVLIST Any revocation list

[0136] Having described the example general message structure, message type, and extension field options, other packet types can be referenced by a mnemonic. For example, a " RQST / MEAS / REVNO" mnemonic refers to an RQST message (message type “5”) that requests a MEAS message (message type "4") having an extension field value ("5") associated with " MEAS / REVNO" packet.

[0137] Although FIG. 15A provides one possible format for the version request packet 1552, other formats are possible. For example, any portion of the message may be populated with an indication or value to indicate the request for version information. Further, the version request packet 1552 can be merged with other packets such as a “MEAS / REVNO” packet or a “AUTH / REVNO” to optimize communication bandwidth.

[0138] FIG. 15A is provided as an example of a “RQST” packet for requesting a “MEAS / REVNO” packet. However, it might also be possible to define a “REVNO” as amessage type in Table 1, and then use a “RQST / REVNO” packet for the version request message. Furthermore, while “REVLIST” is described in Table 2 as a type of MEAS packet (" MEAS / REVLIST") it is also possible to define “REVLIST” in Table 1 as another message type (different from “MEAS”).

[0139] Using the message types and extension field values described in Tables 1 and 2, as well as the general explanation of how these values are used, other messages can be easily understood. For example, “MEAS / AVER,” “RQST / MEAS / REVLIST,” and “ME / XS / REVLIST” would have similar general message structures, but with different values (from Table 1 and 2) in the Message Type field and Extension field. In some implementations, the revocation list update messages of this disclosure can be specified under an authentication (" AUTH") message type (message type 7) to convey the revocation list information, metadata, revocation list, or other update / information file,

[0140] FIG. 15B is a diagram of an example version response message 1553 to indicate information about the sender's revocation list. In some technical specifications, the version response packet 1654 may be referred to as a “MEAS / REVNO” packet, or other name to indicate that the version response packet 1654 includes version information. As descried with reference to FIG. 15 A, the general message structure is the same, except that instead of “RQST” as the message type, the version response message 1553 indicates the “MEAS” message type in the Message Type field 1557. The Extension field 1570 includes a value (e.g., “5”) indicating that the Payload 1555 includes the REVNO message. The REVNO message includes a Version Number field 1520 that can be populated with version information (such as a version number). Alternatively, or additionally, the version response message 1553 can be populated with other types of version information, such as a version date or indicia of the version of the revocation list stored at the sender's memory. In some implementations, the Version Number field 1520 is a byte of binary digits that represent a hexadecimal number indicating the version number of the revocation list.

[0141] Other modifications (not shown) to the version response message 1553 are possible. For example, the version response message 1553 may include an indication whether the recipient should report version comparison results or whether the recipient should proceed with sending its revocation list if the sender’s revocation list is a newer version.

[0142] FIG. 15C is a diagram of an example version results packet 1558 to indicate which wireless power apparatus has a newer version of the revocation list. In some technical specifications, the version results packet 1558 may be referred to as a “MEAS / AVER” packet. A “MEAS” packet is used to exchange measured values or static information indicated in theextension field parameter. The frame header for the “MEAS / AVER” packet would include a message type value (e.g., “4”) followed by an extension field parameter (e.g., “6” from Table 2) indicating that the MEAS packet includes the “AVER” packet in a Payload 1555 of the MEAS packet. The AVER packet includes a Value field 1521. The sender of the MEAS / AVER can populate the Value field 1521 field with various values to indicate the results of a comparison of the version information from the sender and version information from the recipient. For example, a first value 1564 (e.g., “00”) can indicate that both apparatuses have the same version of the revocation list. A second value 1566 (e.g., “11”) can indicate that the Power Transmitter has a newer version of the revocation list. A third value 1568 (e.g., “10”) can indicate that the Power Receiver has a newer version of the revocation list. The example values are provided for understanding, and other values can be ascribed to the meanings.

[0143] In some implementations, the version results packet 1558 can have other fields or parameters, such as in the reserved field. For example, the version results packet 1558 can include an indication whether the sender requests the recipient to transmit the recipient's revocation list. Alternatively, or additionally, the version results packet 1558 can include a parameter related to the revocation list update process, such as which device is expected to initiate a revocation list request message or whether to proceed with revocation list transfer messages immediately or after a delay.

[0144] FIG. 16A is a diagram of another example version request packet 1652 for requesting information about the recipient's revocation list. In some technical specifications, the version request packet 1652 can be referred to as a “RQST / REVNO” packet. In this scenario, Table 1 would be updated to include a “REVNO” message type (e.g., a value of “8”). The version request packet 1652 includes a Message Type field (e.g., “5” for a RQST message type) and an Extension field. The payload of the RQST message includes the requested message type (e.g., “8”) added to Table 1 to represent REVNO message type.

[0145] FIG. 16B is a diagram of another example version response packet 1654 to indicate information about the sender's revocation list. In some technical specifications, the version response packet 1654 may be referred to as a “REVNO” packet, or other name to indicate that the version response packet 1654 includes version information. In FIG. 16B, the version response packet 1654 has a payload that includes a Version Number field 1520 that can be populated with version information (such as a version number), as described in the example of FIG. 15B.

[0146] FIG. 17 is a diagram of an example revocation list packet 1702 for providing a revocation list. In some technical specifications, the version results packet 1558 may be referred to as a “REVLIST” packet. The REVLIST packet can be a new message in the payload of a MEAS packet (e.g., using an extension field of the MEAS packet as described with Table 2). The revocation list packet 1702 can include Abytes of data, depending on the size of the revocation list. For example, an XML revocation list might be 5 kilobytes (kb), 10 kb, 20 kb, or longer. The size of the XML revocation list is vari able based on the amount of revocation data in the XML revocation list. In some implementations, the revocation list packet 1702 can include headers or field (not shown) that indicate the size of the “REVLIST” packet. For example, the revocation list packet 1702 can include information or metadata about the revocation list / XML file, such as the size or format of the list / file.

[0147] In some implementations, the “REVLIST” can be added as a new message type (rather than a message under the MEAS message type). For example, Table 3 shows a potential list of message types where “REVLIST” is a new message type having a new value (e.g., “8”).Table 3. Message TypesMessageMessageType field Sender DescriptionNamevalue- STAT Any Status of the senderCommunication, provides protocol support 0 COMM Anyinformation1 CTRL PRx Control, control the power2 NEXT Any Next, proceed to the requested state3 NEGO Any Negotiate, exchange negotiation parameters4 MEAS Any Measure, provide measurement data5 RQST Any Request, request a particular message to be sent 6 RESP Any Response, respond to a proposalAny authentication, transport service for 7 AUTH Anyauthentication8 REVLIST Any Revocation List9-14 Reserved15 PROP Any

[0148] FIG. 18A illustrates an example of communicating a revocation list in a plurality of message frames, such as NDEF frames. Some wireless power apparatuses use NDEF to store static information. The NDEF device of the Power Receiver 104 typically stores static data populated in the NDEF memory during manufacturing. To obtain the static information, a first device uses its NFC interface to “read” the NDEF data from an NFC device of second device. For example, in a “read” operation, a Power Transmitter retrieves static informationfrom the NDEF record of the Power Receiver. One limitation of NDEF is the size of the buffer in the NDEF device. For example, a ‘’command buffer size” parameter indicates the buffer size in increments of 4 bytes. A maximum value in the command buffer size parameter would refer to a buffer size of 1 kb. However, because an XML revocation list can exceed 1 kb in file size, the transferring device may segment the XML revocation list into chunks of NDEF data. As an example, the revocation list 1802 of the Power Receiver 104 may exceed 1 kb size. To accommodate revocation list transfer, the Power Receiver 104 may provide a first portion of the 1802 in a first communication slot for a first read operation 1804. The Power Receiver 104 may provide a second portion of the revocation list 1802 in a second communication slot for a second read operation 1806, and so on. The Power Transmitter 102 can combine the portions of the revocation list obtained by a series of read operations until it has reconstructed the revocation list 1802 at the Power Transmitter 102.

[0149] The NFC communication units in the Power Receiver 104 and the Power Transmitter 102 may have different buffer sizes. In some implementations, the apparatus exchange information about their respective buffer sizes. The device that is transferring the revocation list will select the lowest buffer size and use that as the portion size to include in each read operation. The NFC communication unit can retrieve the revocation list from the NDEF and segment / chunk the revocation list into portions according to the portion size that can be included in each read operation.

[0150] FIG. 18A illustrates an example of an extension field 1808 for REVLIST message frames that communicate portions of a revocation list with retransmission and sequence control. In some implementations, the extension field of the header for a REVLIST (e.g., either in the general message structure or in the extension field of a MEAS packet header) can include protocol control bits. As an example, the protocol control bits can include a “more information” (MI) bit, a “send sequence number” (NS) bit, and a “receive sequence number” (NR) bit. The protocol control bits can be used to manage which segment / portion of a revocation list has been received or which segment / portion to transmit next. In some implementations, the protocol control bits can be used to manage retransmissions of a previous packet. Because a revocation list may be larger than can be communicated in a single REVLIST message, the revocation list may be sent as a series of REVLIST messages, where the protocol control bits are used to indicate the sequence number in the series. The Ki wireless power specification (version 1,0,1, section 3,5.9.1) includes an example of the protocol control bits and their use in managing sequence transmission and retransmission.

[0151] FIG. 19A is a diagram of an example GET DIGEST packet 1932 to indicate information about the revocation list as part of an authentication message. The GET DIGESTpacket 1932 includes an Authentication Message Header, reserved fields, and a Slot Mask. In some implementations, the GET_DIGEST packet 1932 can be modified to include a request for information about the revocation list of the recipient, such as in one or more bits of the reserved fields. Alternatively, or additionally, the GET DIGEST packet 1932 may include information about the revocation list at the sender.

[0152] In some implementations, when a recipient (such as a Power Transmitter) receives the GET DIGEST packet 1932, the recipient of the GET DIGEST packet responds by sending a DIGEST packet (not shown). The sender of the DIGEST packet (e.g., the Power Transmitter) populates the DIGEST packet with authentication material (such as a certificate chain, public key, challenge / response data, or other authentication data). In some implementations, a DIGEST packet is modified to also include information about the revocation list at the sender of the DIGEST packet.

[0153] FIG. 19B is a diagram of a GET / rlist packet 1978 to request information about the revocation list. The GET / rlist packet 1978 is similar to a RQST / REVLIST packet in that the GET / rlist packet 1978 includes a parameter for requesting that the recipient of the GET / rlist packet 1978 prepare to transmit its revocation list. The Parameter field of the GET / rlist packet 1978 can include various values. In some implementations, a particular value (such as “5”) can indicate that the packet is a ‘" GET / rlist” type of GET packet. In some implementations, the GET / rlist packet 1978 can include other information related to the request for the revocation list.

[0154] FIG. 20 illustrates a block diagram of an example apparatus for use in a wireless power system. In some implementations, the apparatus 2000 may be a wireless power apparatus (such as the Power Transmitter 102 or the Power Receiver 104) described herein. The apparatus 2000 can include a processor 2002 (possibly including multiple processors, multiple cores, multiple nodes, or implementing multi-threading, etc ). The apparatus 900 also can include a memory 2004. The memory 2004 may be system memory or any one or more of the possible realizations of computer-readable media described herein. The apparatus 2000 also can include a bus 2008 (such as PCI, ISA, PCI-Express, HyperTransport®, InfiniBand®, NuBus,® AHB, AXI, etc.).

[0155] The apparatus 2000 may include one or more controllers 2010. In some implementations, the controller 2010 can be distributed within the processor 2002, the memory 2004, and the bus 2008. The controller 2010 may perform some or all of the operations described herein. For example, the controller 2010 may implement the processes described with reference to any one of FIG. 2A through FIG. 14, or any combination thereof.

[0156] The memory 2004 can include computer instructions executable by the processor 2002 to implement the functionality of the implementations described herein. Any one of these functionalities may be partially (or entirely) implemented in hardware or on the processor 2002. For example, the functionality may be implemented with an application specific integrated circuit, in logic implemented in the processor 2002, in a co-processor on a peripheral device or card, etc. Further, realizations may include fewer or additional components not illustrated in FIG. 20. The processor 2002, the memory 2004, and the controller 2010 may be coupled to the bus 2008. Although illustrated as being coupled to the controller 2010, the memory 2004 may be coupled to the processor 2002.

[0157] The apparatus 2000 also includes a revocation list module 2006. The revocation list module 2006 might store a revocation list. The revocation list module 2006 may implement any of the example revocation list update processes described herein, or any combination thereof.

[0158] FIG. 1 through FIG. 20 and the operations described herein are examples meant to aid in understanding example implementations and should not be used to limit the potential implementations or limit the scope of the claims. Some implementations may perform additional operations, fewer operations, operations in parallel or in a different order, and some operations differently.

[0159] This description includes several optional modifications to the revocation list update process and the associated messages. Other modifications are possible. For example, while a revocation list update process is described as potentially occurring after or with an authentication, it may be possible to implement all or part of a revocation list update process before the authentication. Further, in some implementations, the authentication may be omitted based on completion of the revocation list transfer. For explanation purposes, various communication messages are illustrated as individual packet transmission between devices to describe functions and operations; however, one skilled in the art will appreciate that transmission of these individual message packets can be optimized by combining one or more message packets into a single communication packet using various fields indicating corresponding operation and / or functionality. For example, as described above, the revocation list version, date, or other information can be communicated between devices as part of authentication key exchange during the authentication phase, which can immediately lead to revocation list update prior to the beginning of power negotiation / transfer phases.

[0160] The foregoing disclosure provides illustration and description but is not intended to be exhaustive or to limit the aspects to the precise form disclosed. Modifications andvariations may be made in light of the above disclosure or may be acquired from practice of the aspects. While the aspects of the disclosure have been described in terms of various examples, any combination of aspects from any of the examples is also within the scope of the disclosure. The examples in this disclosure are provided for pedagogical purposes. Alternatively, or in addition to the other examples described herein, examples include any combination of the following enumerated example implementation options (referred to as clauses for clarity).

[0161] Clause 1. A method of a first wireless power apparatus, including: communicating with a second wireless power apparatus; performing a successful authentication of the second wireless power apparatus based, at least in part, on a first revocation list stored in a memory of the first wireless power apparatus; and initiating a revocation list update process between the first wireless power apparatus and the second wireless power apparatus during or after the successful authentication of the second wireless power apparatus.

[0162] Clause 2. The method of clause 1, where the initiating the revocation list update process includes at least one of: transmitting first information about the first revocation list; transmitting a request for second information about a second revocation list at the second wireless power apparatus; or transmitting a request for the second revocation list.

[0163] Clause 3. The method of clause 2, further including: receiving, from the second wireless power apparatus, the second information about the second revocation list; determining whether the first revocation list or the second revocation list is newer based on the first information and the second information; and transmitting an indication to the second wireless power apparatus to indicate which apparatus has a newer revocation list.

[0164] Clause 4. The method of clause 2 or 3, further including: transmitting a request to the second wireless power apparatus to obtain the second revocation list; and receiving the second revocation list in response to the request for the second revocation list.

[0165] Clause 5. The method of clause 4, further including: updating the first revocation list at the first wireless power apparatus based on the second revocation list received from the second wireless power apparatus.

[0166] Clause 6. The method of clause 2 or 3, further including: receiving a rejection message from the second wireless power apparatus in response to the request for the second information or the request for the second revocation list; and ending the revocation list update process based on the rejection message.

[0167] Clause 7. The method of any one of clauses 1 to 6, where the first wireless power apparatus is an offline device that does not have access to a network, the method furtherincluding: obtaining information about one or more revocation lists from one or more other wireless power apparatuses after one or more successful authentications of the one or more other wireless power apparatuses; maintaining the first revocation list when a first information about the first revocation list is more recent than the information about the one or more one or more revocation lists; and updating the first revocation list when the first information is less recent than at least one information about the one or more one or more revocation lists.

[0168] Clause 8. The method of any one of clauses 1 to 7, where the revocation list update process includes: one or more communication messages to enable the first wireless power apparatus or the second wireless power apparatus to determine whether the first wireless power apparatus or the second wireless power apparatus has a most recent revocation list compared to the other of the first wireless power apparatus and the second wireless power apparatus; and one or more revocation list transfer messages to provide the most recent revocation list to the other of the first wireless power apparatus and the second wireless power apparatus.

[0169] Clause 9. The method of clause 8, where the one or more communication messages include at least one of: a request for information about the revocation list; a message indicating the information about the revocation list; a message indicating which apparatus has a most recent revocation list based on a version date or version number in the information; or an authentication message indicating a request for information or indicating information about the revocation list.

[0170] Clause 10, The method of clause 8 or 9, where the one or more revocation list transfer messages includes at least one of: a request for the revocation list of the second wireless power apparatus; a revocation list message including the revocation list; a message opening a channel for a revocation list transfer; or one or more messages for the revocation list transfer.

[0171] Clause 11. The method of any one of clauses 7 to 9, where the one or more revocation list transfer messages are transmitted via an individual packet or via a combination of one or more packets.

[0172] Clause 12. The method of any one of clauses 1 to 10, where the first wireless power apparatus is one of a Power Transmitter or a Power Receiver, and where the second wireless power apparatus is the other one of the Power Transmitter or the Power Receiver.

[0173] Clause 13. The method of any one of clauses 1 to 10, where the first wireless power apparatus is an offline wireless power apparatus, and where the second wireless power apparatus is an update apparatus or an online apparatus with which the offline wireless power apparatus can communicate using at least one of: in-band communication via a wireless powersignal, short-range radio frequency communication, near-field communication, a memory card interface, or a smart home network.

[0174] Clause 14. The method of any one of clauses 1-10 or 12-13, further including: initiating the revocation list update process during a power transfer phase between the first wireless power apparatus and the second wireless power apparatus.

[0175] Clause 15. A method of a first apparatus, the method including: communicating one or more communication messages to enable the first apparatus or a second apparatus to determine whether the first apparatus or the second apparatus has a most recent revocation list compared to the other of the first apparatus and the second apparatus, the revocation list including revocation data to prevent one or more wireless power apparatuses from authenticating with the first apparatus or the second apparatus; and communicating one or more revocation list transfer messages to provide the most recent of the revocation list to the other of the first apparatus and the second apparatus.

[0176] Clause 16. A wireless power apparatus, including: a communication unit; and a controller or processor configured to perform a method according to any one of clauses 1 to 15.

[0177] Another innovative aspect of the subject matter described in this disclosure can be implemented as a computer-readable medium having stored therein instructions which, when executed by a processor, causes the processor to perform any one of the above-mentioned functionalities.

[0178] Another innovative aspect of the subject matter described in this disclosure can be implemented as a system having means for implementing any one of the above-mentioned functionalities.

[0179] Another innovative aspect of the subject matter described in this disclosure can be implemented as an apparatus having one or more processors configured to perform one or more operations from any one of the above-mentioned functionalities.

[0180] As used herein, a phrase referring to “at least one of’ or “one or more of’ a list of items refers to any combination of those items, including single members. For example, “at least one of: a, b, or c” is intended to cover the possibilities of: a only, b only, c only, a combination of a and b, a combination of a and c, a combination of b and c, and a combination of a and b and c.

[0181] The various illustrative components, logic, logical blocks, modules, circuits, operations and algorithm processes described in connection with the implementations disclosed herein may be implemented as electronic hardware, firmware, software, orcombinations of hardware, firmware or software, including the structures disclosed in this specification and the structural equivalents thereof. The interchangeability of hardware, firmware and software has been described generally, in terms of functionality, and illustrated in the various illustrative components, blocks, modules, circuits and processes described above. Whether such functionality is implemented in hardware, firmware or software depends upon the particular application and design constraints imposed on the overall system.

[0182] The hardware and data processing apparatus used to implement the various illustrative components, logics, logical blocks, modules and circuits described in connection with the aspects disclosed herein may be implemented or performed with a general purpose single- or multi-chip processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device (PLD), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, or any conventional processor, controller, microcontroller, or state machine. A processor also may be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. In some implementations, particular processes, operations and methods may be performed by circuitry that is specific to a given function.

[0183] As described above, some aspects of the subject matter described in this specification can be implemented as software. For example, various functions of components disclosed herein, or various blocks or steps of a method, operation, process or algorithm disclosed herein can be implemented as one or more modules of one or more computer programs. Such computer programs can include non-transitory processor-executable or computer-executable instructions encoded on one or more tangible processor-readable or computer-readable storage media for execution by, or to control the operation of, a data processing apparatus including the components of the devices described herein. By way of example, and not limitation, such storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store program code in the form of instructions or data structures. Combinations of the above should also be included within the scope of storage media.

[0184] Various modifications to the implementations described in this disclosure may be readily apparent to persons having ordinary skill in the art, and the generic principles defined herein may be applied to other implementations without departing from the scope of thisdisclosure. Thus, the claims are not intended to be limited to the implementations shown herein but are to be accorded with the widest scope consistent with this disclosure, the principles and the novel features disclosed herein.

[0185] Additionally, various features that are described in this specification in the context of separate implementations also can be implemented in combination to form a single implementation. Conversely, various features that are described in the context of a single implementation also can be implemented in multiple implementations separately or in any suitable subcombination. As such, although features may be described above as acting in particular combinations, and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

[0186] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. Further, the drawings may schematically depict one or more example processes in the form of a flowchart or flow diagram. However, other operations that are not depicted can be incorporated in the example processes that are schematically illustrated. For example, one or more additional operations can be performed before, after, simultaneously, or between any of the illustrated operations. In some circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated together into a single software product or packaged into multiple software products.

Claims

CLAIMSWhat is claimed is:

1. A method of a first wireless power apparatus, comprising:communicating with a second wireless power apparatus;performing an authentication protocol to authenticate the second wireless power apparatus based, at least in part, on a first revocation list stored in a memory of the first wireless power apparatus; andinitiating a revocation list update process between the first wireless power apparatus and the second wireless power apparatus during or after an authentication of the second wireless power apparatus.

2. The method of claim 1, wherein the initiating the revocation list update process includes at least one of:transmitting first information about the first revocation list;transmitting a request for second information about a second revocation list at the second wireless power apparatus; ortransmitting a request for the second revocation list.

3. The method of claim 2, further comprising:receiving, from the second wireless power apparatus, the second information about the second revocation list;determining whether the first revocation list or the second revocation list is newer based on the first information and the second information; andtransmitting an indication to the second wireless power apparatus to indicate which apparatus has a newer revocation list.

4. The method of claim 2 or 3, further comprising:transmitting a request to the second wireless power apparatus to obtain the second revocation list; andreceiving the second revocation list in response to the request for the second revocation list.

5. The method of claim 4, further comprising:updating the first revocation list at the first wireless power apparatus based on the second revocation list received from the second wireless power apparatus.

6. The method of claim 2 or 3, further comprising:receiving a rejection message from the second wireless power apparatus in response to the request for the second information or the request for the second revocation list; and ending the revocation list update process based on the rejection message.

7. The method of any one of claims 1 to 6, wherein the first wireless power apparatus is an offline device that does not have access to a network, the method further comprising:obtaining information about one or more revocation lists from one or more other wireless power apparatuses after one or more successful authentications of the one or more other wireless power apparatuses;maintaining the first revocation list when a first information about the first revocation list is more recent than the information about the one or more one or more revocation lists; andupdating the first revocation list when the first information is less recent than at least one information about the one or more one or more revocation lists.

8. The method of any one of claims 1 to 7, wherein the revocation list update process includes:one or more information messages to enable the first wireless power apparatus or the second wireless power apparatus to determine whether the first wireless power apparatus or the second wireless power apparatus has a most recent revocation list compared to the other of the first wireless power apparatus and the second wireless power apparatus.

9. The method of claim 8, wherein the one or more communication messages include at least one of:a request for information about the revocation list;a message indicating the information about the revocation list;a message indicating which apparatus has a most recent revocation list based on a version date or version number; oran authentication message indicating a request for information or indicating information about the revocation list.

10. The method of any one of claims 1 to 9, wherein the revocation list update process includes:one or more transfer messages to transfer the most recent revocation list to the other of the first wireless power apparatus and the second wireless power apparatus.

11. The method of claim 10, wherein the one or more transfer messages includes at least one of:a request for the revocation list of the second wireless power apparatus;a revocation list message including the revocation list;a message opening a channel for a revocation list transfer; orone or more messages for the revocation list transfer.

12. The method of claim 10 or 11, wherein the one or more transfer messages are transmitted via an individual packet or via a combination of one or more packets.

13. The method of any one of claims 1 to 10,wherein the first wireless power apparatus is one of a Power Transmitter or a Power Receiver, andwherein the second wireless power apparatus is the other one of the Power Transmitter or the Power Receiver.

14. The method of any one of claims 1 to 10,wherein the first wireless power apparatus is an offline wireless power apparatus, and wherein the second wireless power apparatus is an update apparatus or an online apparatus with which the offline wireless power apparatus can communicate using at least one of:in-band communication via a wireless power signal,short-range radio frequency communication,near-field communication,a memory card interface, ora smart home network.

15. The method of any one of claims 1 to 14, further comprising:initiating the revocation list update process during a power transfer phase between the first wireless power apparatus and the second wireless power apparatus.

16. A wireless power apparatus, comprising:a communication unit; anda controller or processor configured to perform a method according to any one of claims 1 to 15.

Images