JP7121521B2 - 受電装置、送電装置、無線電力伝送システムおよびそれらの制御方法 - Google Patents

Description

本発明は、無線電力伝送技術に関する。

近年、無線電力伝送システムの技術開発が広く行われている。特許文献１には、非接触充電規格の標準化団体Ｗｉｒｅｌｅｓｓ Ｐｏｗｅｒ Ｃｏｎｓｏｒｔｉｕｍ（ＷＰＣ）が策定する規格（以下、「ＷＰＣ規格」と呼ぶ。）に準拠した送電装置および受電装置が記載されている。また、特許文献２には、非接触充電の送電装置と受電装置との間の機器認証方法が記載されている。特許文献２によれば、送電装置は、送電コイルを介してチャレンジデ－タを受電装置へ送信し、受電装置は、そのチャレンジデ－タに対して認証用演算を施すことで作成されたレスポンスデ－タを、受電コイルを介して送電装置へ送信する。そして、送電装置が受電装置から受信したレスポンスデ－タを照合することによって、機器認証プロトコルが実行される。

特開２０１６－００７１１６号公報 特開２０１０－１０４０９７号公報

しかしながら、送電装置と受電装置との間で無線電力伝送を行うシステムにおいて、従来の機器認証方法では利便性が十分でない場合があった。例えば、特許文献２の通信方法を用いる場合、送電装置と受電装置は双方が機器認証機能を有していることを前提とした通信を行う。そのため、機器認証機能を有する送電装置は、従来のＷＰＣ規格に準拠しており機器認証機能を有さない受電装置と適切に通信することができなかった。また例えば、送電装置において、受電装置に無線で電力伝送を行うための電力を、外部の電源装置（例えばＡＣアダプタ）からケーブル（例えばＵＳＢケーブル）を介して受け取る構成が知られている。この構成において、送電装置は、ケーブルやＡＣアダプタについて機器認証を行うことができる。送電装置が電源との機器認証プロトコルに対応し、送電装置と受電装置が送電コイルおよび受電コイルを介した上述の機器認証プロトコルに対応している場合、無線電力伝送システムはこれらの複数種類の機器認証プロトコルを実行することができる。しかしながら、このような複数種類の機器認証プロトコルを実行可能な無線電力伝送システムにおける適切な制御方法の検討は進んでいない。

本発明は上記の課題に鑑みてなされたものであり、送電装置と受電装置との間で無線電力伝送を行うためのシステムの利便性を向上させることを目的とする。

本発明の一態様による受電装置は、電源装置から供給された電力を用いた送電装置から無線で受電する受電装置であって、第一の通信プロトコルを使用した前記電源装置と前記送電装置との間での第一の機器認証の結果を前記送電装置から取得する取得手段と、前記第一の通信プロトコルと異なる媒体を使用する第二の通信プロトコルを使用して前記送電装置と第二の機器認証を行う認証手段と、前記第一の機器認証の結果と前記第二の機器認証の結果とに基づいて、前記送電装置と送電電力に関する交渉を行う交渉手段と、を有する。

本発明によれば、送電装置と受電装置との間で無線電力伝送を行うためのシステムの利便性が向上する。

送電装置の構成例を示すブロック図である。 受電装置の構成例を示すブロック図である。 非接触充電システムの構成例を示すブロック図である。 ＵＳＢ認証とＷＰＴ認証を含む、非接触充電システムの動作シーケンス図である。 送電装置の制御部による、ＧＰの設定処理を示すフローチャートである。 機器認証の結果とＧＰの設定値の関係を示す図である。 送電装置の制御部による電力伝送までの状態遷移を示すフローチャートである。 送電装置と受電装置の間の通信に関するシーケンス図である。 送電装置と受電装置の間の通信に関するシーケンス図である。 受電装置の制御部による電力伝送までの状態遷移を示すフローチャートである。 受電装置の制御部による電力伝送までの状態遷移を示すフローチャートである。 受電装置の制御部による電力伝送までの状態遷移を示すフローチャートである。 （ａ）はＣｏｎｆｉｇｕｒａｔｉｏｎ Ｐａｃｋｅｔの構成を示す図であり、（ｂ）はＰｏｗｅｒ Ｔｒａｎｓｍｉｔｔｅｒ Ｃａｐａｂｉｌｉｔｙ Ｐａｃｋｅｔの構成を示す図である。 受電装置の制御部による、ＧＰの設定処理を示すフローチャートである。

以下、添付の図面を参照して、本発明の実施形態について説明する。

（システム構成）
図３は、本実施形態に係る無線電力伝送システム（非接触充電システム）の構成例を示している。図３において、送電装置（以下、「ＴＸ１００」と呼ぶ。）は、ＡＣアダプタ３０１及びＵＳＢケーブル３００等を用いて有線で供給される電力を、無線により、受電装置（以下、「ＲＸ２００」と呼ぶ。）へ伝送する。ＲＸ２００は、ＴＸ１００から無線により伝送された電力を受け取り、例えばＲＸ２００の内部に備えられたバッテリを充電する。ＡＣアダプタ３０１は、電源プラグ３０２を介して供給される商用電源の電力をＴＸ１００に適した電圧に変換して、ＴＸ１００に供給する。なお、図３の構成は一例であり、これら以外の構成が用いられてもよい。例えば、有線による電力供給は、機器認証を行うことができる限りにおいてＵＳＢ以外の規格に従って行われてもよい。このため、以下では、有線による電力供給がＵＳＢ Ｐｏｗｅｒ－Ｄｅｌｉｖｅｒｙ規格に従って行われ、ＵＳＢ Ｐｏｗｅｒ－Ｄｅｌｉｖｅｒｙ規格がサポートするＡｕｔｈｅｎｔｉｃａｔｉｏｎ規格に基づいて機器認証が行われるものとする。ただし、これら以外の規格が用いられてもよい。また、図３にはそれぞれ１つのＴＸ１００及びＲＸ２００が示されているが、複数のＴＸ１００が有線による電力の供給を受けて共通の１つのＲＸ２００又はそれぞれ別個のＲＸ２００に送電してもよいし、１つのＴＸ１００が複数のＲＸ２００に送電してもよい。なお、以下では、ＴＸ１００とＲＸ２００との間で、ＷＰＣ（Ｗｉｒｅｌｅｓｓ Ｐｏｗｅｒ Ｃｏｎｓｏｒｔｉｕｍ）規格に準拠した非接触充電が行われる場合について説明するが、これに限定されず、他の規格に基づいて非接触充電が行われてもよい。

（装置構成）
続いて、図３に示す非接触充電システムにおいて利用可能な送電装置（ＴＸ１００）及び受電装置（ＲＸ２００）の構成例について説明する。

図１は、ＴＸ１００の構成例を示すブロック図である。ＴＸ１００は、ＷＰＣ規格に準拠しており、さらにＷＰＣ規格のバージョン１．２．２（以下、ＷＰＣ規格ｖ１．２．２と呼ぶ。）で規定される機能を有する。ここで、ＴＸ１００は、ＴＸ１００と同様にＷＰＣ規格に対応したＲＸ２００の充電部に、最大１５ワットの電力を出力する電力供給能力を有するものとする。ＴＸ１００は、一例において、制御部１０１、電源部１０２、送電部１０３、通信部１０４、送電コイル１０５、表示部１０６、メモリ１０７、第一認証部１０８、及び第二認証部１０９を有しうる。

制御部１０１は、例えばＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）やＭＰＵ（Ｍｉｃｒｏ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）等の１つ以上のプロセッサを含んで構成され、ＴＸ１００の全体を制御する。なお、制御部１０１は、例えば特定用途向け集積回路（ＡＳＩＣ）やＦＰＧＡ（フィールドプログラマブルゲートアレイ）等を含んで構成されてもよい。

電源部１０２は、ＡＣアダプタ３０１からＵＳＢケーブル３００を介してＴＸ１００の動作のための電力供給を受け、少なくとも制御部１０１および送電部１０３が動作する電源を供給する。電源部１０２は、有線による電力供給機器の機器認証と電力の供給に対応可能に構成される。電源部１０２は、例えば図３のようにＵＳＢケーブル３００を介した電力の供給を受けるために、ＵＳＢ Ｐｏｗｅｒ－Ｄｅｌｉｖｅｒｙ規格と、接続されたＵＳＢ機器同士の機器認証を行うＡｕｔｈｅｎｔｉｃａｔｉｏｎ規格に対応しうる。なお、ＴＸ１００は、ＵＳＢ Ｐｏｗｅｒ－Ｄｅｌｉｖｅｒｙ規格以外の規格に準拠して電力の供給を受けてもよいし、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ規格以外の規格に従って機器認証を行ってもよい。このため、電源部１０２は、これらの規格以外の規格に対応可能に構成されうる。また、電源部１０２（又は後述の第一認証部１０８）は、複数の規格に対応可能に構成されてもよく、例えば電力供給元との接続形態に基づいて（例えばＴＸ１００のどの端子が用いられたかに基づいて）、使用すべき規格を判定してもよい。

送電部１０３は、送電コイル１０５を介して、ＲＸ２００へ伝送される交流電圧および交流電流を発生させる。送電部１０３は、例えば、電源部１０２が供給する直流電圧を、ＦＥＴを使用したハーフブリッジまたはフルブリッジ構成のスイッチング回路を用いて交流電圧に変換しうる。この場合、送電部１０３は、ＦＥＴのＯＮ／ＯＦＦを制御するゲ－トドライバを含みうる。

通信部１０４は、ＲＸ２００（図２の通信部２０４）との間で、ＷＰＣ規格に基づいた非接触充電の制御に関する制御通信を行う。通信部１０４は、送電部１０３が発生する交流電圧または電流を変調し、無線電力に情報を重畳するいわゆるインバンド通信によってＲＸ２００との間での通信を行いうる。ただし、これに限られず、通信部１０４は、通信用の周波数帯の少なくとも一部が電力伝送用の周波数帯に含まれないアウトバンド通信によって、ＲＸ２００との間での通信を行ってもよい。アウトバンド通信は、例えば、ＮＦＣ、ＲＦＩＤ、Ｗｉ－Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ等によって行われうる。

表示部１０６は、ＴＸ１００の状態や、図３に示すようなＴＸ１００、ＲＸ２００、ＵＳＢケーブル３００、ＡＣアダプタ３０１などの機器を含む非接触充電システムの状態の情報を、ユーザが確認可能なように表示する。表示部１０６は、例えば、ＬＥＤ（Ｌｉｇｈｔ Ｅｍｉｔｔｅｄ Ｄｉｏｄｅ）によって構成されうるが、これに限られず、例えばＬＥＤに代えて又はこれに追加して、スピーカ、振動発生回路、ディスプレイ等を含んで構成されてもよい。メモリ１０７は、ＴＸ１００および図３の非接触充電システムの各要素および全体の状態を記憶する。

第一認証部１０８は、電源部１０２と、それに接続されるＵＳＢケーブル３００およびＡＣアダプタ３０１についての機器認証を行う。本実施形態では、第一認証部１０８は、ＵＳＢ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ規格に準拠した機器認証を行うものとする。ただしこれに限られず、Ｑｕａｌｃｏｍｍ社のＱｕｉｃｋ Ｃｈａｒｇｅ規格等の、機器認証に対応している他の規格が用いられてもよい。第二認証部１０９は、通信部１０４を介した通信によってＴＸ１００とＲＸ２００との間の機器認証を行う。本実施形態では、第二認証部１０９が行う機器認証をＷｉｒｅｌｅｓｓ Ｐｏｗｅｒ Ｔｒａｎｓｆｅｒ認証又はＷＰＴ認証と呼ぶ。

なお、図１では、制御部１０１、電源部１０２、送電部１０３、通信部１０４、メモリ１０７、第一認証部１０８、第二認証部１０９が別個のブロックとして図解されているが、これらの内の複数の任意のブロックが同一チップ内に実装されてもよい。例えば、ＵＳＢ Ｐｏｗｅｒ－Ｄｅｌｉｖｅｒｙに対応した電源部１０２とＵＳＢ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ規格に対応した第一認証部１０８とが、ＵＳＢ関連チップとして同一チップ内に実装されてもよい。この場合、ＴＸ１００は、制御部１０１とＵＳＢ関連チップとの間を、例えばＧＰＩＯ（Ｇｅｎｅｒａｌ Ｐｕｒｐｏｓｅ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）やシリアル通信で接続するように構成されうる。また、例えば、第二認証部１０９、制御部１０１、メモリ１０７、送電部１０３、通信部１０４の内の複数の任意のブロックが同一チップ内に実装されてもよい。また、図１における１つのブロックが、複数のブロックに分割されてもよく、場合によっては複数のチップによって実装されてもよい。

図２は、ＲＸ２００の構成例を示すブロック図である。ＲＸ２００も、ＴＸ１００と同様に、ＷＰＣ規格に準拠しており、さらにＷＰＣ規格ｖ１．２．２で規定される機能を有する。ＲＸ２００は、一例において、制御部２０１、表示部２０２、受電部２０３、通信部２０４、受電コイル２０５、充電部２０６、バッテリ２０７、認証部２０８、及びメモリ２０９を有しうる。

制御部２０１は、例えばＣＰＵやＭＰＵ等の１つ以上のプロセッサやＡＳＩＣ又はＦＰＧＡ等を含んで構成され、ＲＸ２００の全体を制御する。表示部２０２は、電力の供給状態や、ＲＸ２００の充電状態などの情報をユーザが確認可能となるように表示する。表示部２０２は、本実施形態ではＬＥＤであるものとするが、これに加えて又はこれに代えて、例えば、スピーカ、振動発生回路、ディスプレイを含んでもよい。

受電部２０３は、受電コイル２０５を介して、送電コイル１０５から放射された電磁波を受電し、受電によって得られる交流電圧および交流電流を、制御部２０１や充電部２０６等が動作する際に用いられる直流電圧および直流電流に変換する。なお、本実施形態では、受電部２０３は、充電部２０６に最大１５ワットの電力を出力する能力を有するものとする。

通信部２０４は、ＴＸ１００の通信部１０４との間で、ＷＰＣ規格に基づいた非接触充電の制御に関する制御通信を行う。この制御通信は、ＲＸ２００側の負荷を変動させることによってＴＸ１００とＲＸ２００との間の電力伝送の状態を変化させて、送電コイル１０５を流れる電流を変動させることにより情報を伝送する、負荷変調によって行われうる。なお、通信部２０４は、この負荷変調等のインバンド通信によって制御通信を行ってもよいし、通信用の周波数帯の少なくとも一部が電力伝送用の周波数帯に含まれないアウトバンド通信により制御通信を行ってもよい。しかしながら、これに限られるものではなく、送電部１０３の周波数と異なる周波数を使用するアウトバンド通信でもよい。アウトバンド通信は、上述のように、例えば、ＮＦＣ、ＲＦＩＤ、Ｗｉ－Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ等によって行われうる。

充電部２０６は、受電部２０３から供給される直流電圧と直流電流とを利用して、バッテリ２０７を充電する。認証部２０８は、通信部２０４を介した通信によって、ＴＸ１００の第二認証部１０９との間のＷＰＴ認証を行う。メモリ２０９は、ＲＸ２００および図３の非接触充電システムの各要素および全体の状態の情報を記憶する。なお、ＴＸ１００またはＲＸ２００がＷＰＴ認証を含むＷＰＣ規格に対応していることを、以下では「ＷＰＣ規格バージョンＡに対応している」と表現する。ここで、ＷＰＣ規格バージョンＡは、ＷＰＣ規格ｖ１．２．２の後継の規格であり、少なくともＷＰＴ認証機能が追加されているものとする。

なお、図２では、受電部２０３、認証部２０８、制御部２０１、メモリ２０９、通信部２０４、充電部２０６が別個のブロックとして図解されているが、これらの内の複数の任意のブロックが同一チップ内に実装されてもよい。また、図２における１つのブロックが、複数のブロックに分割されてもよく、場合によっては複数のチップによって実装されてもよい。

本実施形態に係る非接触充電システムでは、ＴＸ１００の第一認証部１０８が、ＡＣアダプタ３０１およびＵＳＢケーブル３００と、第一の通信プロトコルを使用した機器認証（例えば、ＵＳＢケーブルを介したＵＳＢ認証）を行う。また、ＴＸ１００の第二認証部１０９は、第一の通信プロトコルと異なる媒体（例えば、送電コイル１０５および受電コイル２０５）を使用する第二の通信プロトコルを使用してＲＸ２００と機器認証を行う。本実施形態において、ＡＣアダプタ３０１、ＵＳＢケーブル３００、ＴＸ１００（電源部１０２）はＵＳＢ機器である。ＵＳＢ機器がＵＳＢ認証に対応すると共にＵＳＢ認証に成功することによって、それらの機器にＵＳＢ認証で定められた電力を印加したとしても過度の発熱等の問題が生じないことを確認することができる。すなわち、ＵＳＢ認証に成功した場合、ＡＣアダプタ３０１からＵＳＢケーブル３００を介して、定められた電力をＴＸ１００の電源部１０２に供給した際に、ＴＸ１００の電源部１０２、ＵＳＢケーブル３００、ＡＣアダプタ３０１が過度に発熱しないと言える。

一方、電源部１０２、ＵＳＢケーブル３００、ＡＣアダプタ３０１のいずれかがＵＳＢ認証に対応しない場合は、ＵＳＢ認証に成功することはない。この場合、ＵＳＢ認証に定められた電力を印加した場合に、それらの機器やケーブルのいずれかが過度に発熱する等の問題が生じうる。ここでＵＳＢ認証に非対応の機器は、ＵＳＢ認証規格が策定される以前の複数のバージョンのＵＳＢ規格のいずれかに対応している機器を含む。本実施形態では、ＵＳＢ認証規格が策定される以前の複数のバージョンのＵＳＢ規格のいずれかに対応したＵＳＢ機器をレガシーのＵＳＢ機器と呼ぶ。また、電源部１０２、ＵＳＢケーブル３００、ＡＣアダプタ３０１のいずれかがＵＳＢ認証に失敗した場合は、ＵＳＢ認証で定められた電力を印加した場合に発熱等の問題が生じうる。ここで、ＵＳＢ認証に失敗するとは、ＵＳＢケーブル３００とＡＣアダプタ３０１の少なくともいずれかが、名目的にはＵＳＢ認証に対応しているが、実際は対応していないＵＳＢ機器である可能性がある場合を含む。

また、ＲＸ２００とＴＸ１００とがＷＰＣ規格バージョンＡに対応しており、かつ、ＷＰＴ認証に成功した場合は、ＲＸ２００とＴＸ１００とが規格で定められた所定の電力のやり取りをしたとしても、それらが過度に発熱する等の問題が生じない。一方、ＲＸ２００とＴＸ１００との少なくとも一方がＷＰＣ規格バージョンＡに対応しない場合は、上述の定められた電力が印加された場合に、ＷＰＣ規格バージョンＡに対応しない装置が過度に発熱する等の問題が生じうる。ここでＷＰＣ規格バージョンＡに非対応の機器には、ＷＰＣ規格バージョンＡより前の複数のバージョンのＷＰＣ規格のいずれかに対応している機器が含まれる。本実施形態ではＷＰＣ規格バージョンＡより前の複数のバージョンのＷＰＣ規格のいずれかに対応したＴＸまたはＲＸをレガシーのＴＸまたはＲＸと呼ぶ。

また、ＴＸ１００とＲＸ２００との間でのＷＰＴ認証に失敗するのは、これらの機器が名目上ＷＰＴ認証に対応しているが実際は対応していない場合が含まれる。なお、ＷＰＴ認証に対応している機器間でのＷＰＴ認証は必ず成功する。この場合も、ＷＰＴ認証に成功しないため、上述の定められた電力を印加した場合に、過度の発熱等の問題が生じうる。

本実施形態では、ＵＳＢケーブル３００およびＡＣアダプタ３０１がＵＳＢ認証に成功し、かつＲＸ２００およびＴＸ１００がＷＰＴ認証に成功した場合に、規格で定められる所定の電力を供給することが可能であると判断される。すなわち、過度の発熱などの問題が生じない状態で、ＲＸ２００の受電部２０３が負荷（本実施形態では充電部２０６）に所定の電力（１５ワット）を供給することができる。他方、ＴＸ１００（電源部１０２）、ＵＳＢケーブル３００、ＡＣアダプタ３０１のいずれかがＵＳＢ認証に成功しない、またはＲＸ２００とＴＸ１００のいずれかがＷＰＴ認証に成功しない場合は、所定の電力の供給に問題が生じる可能性がある。すなわち、ＲＸ２００の受電部２０３が負荷に１５ワットの所定の電力を供給した場合に、過度の発熱等の問題が生じうる。以下では、そのようなリスクを回避するために、認証に成功しない場合に、受電部２０３が供給する電力を所定の電力（１５ワット）より小さい電力（例えば５ワット以下）に制限する。

（処理の流れ）
続いて、非接触無線通信システムで実行される処理の流れの例について説明する。図４は、本実施形態において実行される、ＵＳＢ認証とＷＰＴ認証とを含む処理の流れの例を示すシーケンス図である。また、図５は、本実施形態におけるＧｕａｒａｎｔｅｅｄ Ｐｏｗｅｒ（以下、ＧＰ）の設定に関して、送電装置（ＴＸ１００）の制御部１０１によって実行される処理の流れの例を示すフローチャートである。また、図１１は、ＧＰの設定に関して、受電装置（ＲＸ２００）の制御部２０１によって実行される処理の流れの例を示すフローチャートである。ここで、ＧＰとは、ＴＸ１００とＲＸ２００との位置関係がずれて、送電コイル１０５と受電コイル２０５との間の送電効率が低下しても、受電部２０３の負荷への出力電力に関してＴＸ１００が保証する電力値である。受電部２０３の負荷は、受電部２０３が電源を供給する対象であり、少なくとも充電部２０６を含む。例えば、ＧＰが５ワットの場合、送受電コイルの位置関係がずれて、コイル間の送電効率が低下したとしても、受電部２０３が５ワットの電力を出力することができるように、ＴＸ１００は送電部１０３を制御する。本実施形態では、認証の結果に応じて、ＧＰが制限される。これにより、例えば認証に成功しない場合や認証に非対応の場合に、規格で規定された電力が伝送されることによる過度の発熱等の問題が生じるのを防ぐことができる。まず、ＵＳＢ認証およびＷＰＴ認証の結果によって、後述するＮｅｇｏｔｉａｔｉｏｎにおいて用いられるＧＰの制限値の例について、図６を用いて説明する。

列６００の「ＵＳＢ認証非対応」とは、ＴＸ１００の電源部１０２、ＵＳＢケーブル３００、ＡＣアダプタ３０１の少なくともいずれかがＵＳＢ認証に対応していない（ただし、ＵＳＢ認証に対応している機器は認証に成功している）ことを示す。列６０１の「ＵＳＢ認証失敗」とは、ＴＸ１００の電源部１０２、ＵＳＢケーブル３００、ＡＣアダプタ３０１の少なくともいずれかが、（少なくとも名目上は）ＵＳＢ認証に対応しているが、ＵＳＢ認証に失敗したことを示す。列６０２の「ＵＳＢ認証成功」とは、ＴＸ１００の電源部１０２、ＵＳＢケーブル３００、ＡＣアダプタ３０１のすべてがＵＳＢ認証に成功したことを示す。また、行６０３は、ＲＸ２００がＷＰＴ認証に対応していないことを、行６０４は、ＲＸ２００がＷＰＴ認証に対応しているがＷＰＴ認証に失敗したことを、行６０５は、ＲＸ２００がＷＰＴ認証に対応しておりＷＰＴ認証に成功したことを示す。なお、テーブル中の「０，２．５，５」の３種類のＧＰの電力値が記載されている欄については、予めそれらのうちの１つを採用するような設定が行われる。

図６によれば、ＵＳＢ認証に非対応（列６００）である場合は、ＷＰＴ認証の結果によらず、ＧＰを５ワットに制限することで、過度の発熱等を回避するようにする。また、列６００のうち、ＷＰＴ認証に失敗した場合（行６０４）は、０ワット（送電しない）や（５ワットより小さい）２．５ワットなど、ＷＰＴ認証に非対応の場合（行６０３）と比較して、ＧＰを小さい値に制限してもよい。ＷＰＴ認証に失敗したということは、ＲＸが、例えば、名目上はＷＰＴ認証を実装しているが正規に実装していない、ＷＰＣ規格を満たしていない偽物などである可能性があるからである。過度の発熱等の観点では、ＧＰを５ワットに制限すればよい。一方で、ＷＰＴ認証非対応であるが正規に規格を実装しているレガシーのＲＸよりも低いＧＰ（０ワットまたは２．５ワット）に制限することで、ＷＰＴ認証に対応していると見せかけた偽物への送電を抑制又は回避することができる。

同様に、ＵＳＢ認証に失敗した場合（列６０１）は、ＷＰＴ認証の結果にかかわらず０ワット（送電しない）や（５ワットより小さい）２．５ワットなど、ＵＳＢ認証に非対応の場合（列６００）と比較して、ＧＰを小さい値に制限してもよい。これは、ＵＳＢ認証に失敗したということは、認証対象のＵＳＢ機器が、例えば、名目上はＵＳＢ認証を実装してはいるが正規に実装していない偽物である可能性があるからである。このため、ＵＳＢ認証非対応であるが正規に規格を実装しているレガシーのＵＳＢ機器と比較して、より低い０ワットまたは２．５ワットに制限することで、ＵＳＢ認証に対応していると見せかけた偽物からの電力の供給を抑制または回避することができる。

ＵＳＢ認証に成功した場合（列６０２）は、ＴＸ１００の電源部１０２、ＵＳＢケーブル３００、ＡＣアダプタ３０１に関して、ＲＸ２００が負荷へ１５ワット（ＴＸ１００がＲＸ２００へ供給できるＧＰの最大値）を供給しても過度の発熱等が生じない。このため、ＴＸ１００は、ＷＰＣ認証の結果に基づいてＧＰの設定を行う。例えば、ＴＸ１００は、ＷＰＴ認証非対応の場合（行６０３）は上述の理由によりＧＰを５ワットに制限し、ＷＰＴ認証に失敗した場合（行６０４）はＧＰをより低い値（０ワットまたは２．５ワット）に制限する。ＵＳＢ認証に成功し（列６０２）、ＷＰＴ認証にも成功（行６０５）した場合は、過度の発熱等の問題が生じないと判断し、ＴＸ１００は、ＧＰの制限値としてＴＸ１００の送電能力及びＲＸ２００の受電能力の最大値である１５ワットを設定する。また、ＲＸ２００が、ＴＸ１００の送電能力およびＲＸ２００の受電能力の最大値である１５ワットを、ＧＰとしてＴＸ１００に要求してもよい。

このように、ＴＸ１００は、ＵＳＢ認証結果とＷＰＴ認証結果、及び、図６に示されるような設定値に基づいて、後述のＮｅｇｏｔｉａｔｉｏｎフェーズ（以下、「交渉フェーズ」と呼ぶ。）の交渉において許容できるＧＰの最大値を決定しうる。また、ＲＸ２００は、ＵＳＢ認証結果とＷＰＴ認証結果、及び、図６に示されるような設定値に基づいて、交渉フェーズの交渉において、ＴＸ１００に要求するＧＰの最大値を決定しうる。なお、ＵＳＢ認証とＷＴＰ認証との両方が成功した場合は、交渉フェーズの交渉において、ＴＸ１００とＲＸ２００の最大能力に応じた送電電力が決定されうる。

続いて、図３の非接触充電システムの起動から送電までの処理の流れの例について、図４、図５及び図１１を用いて説明する。ＲＸ２００は、ＵＳＢ認証およびＷＰＴ認証において認証の対象となる機器のうち認証に非対応または認証に失敗した機器が１つでもあれば、ＴＸ１００に対して、ＧＰの値として大きな電力を要求しないように動作する。

まず、ＴＸ１００の電源部１０２にＵＳＢケーブル３００とＡＣアダプタ３０１が接続されると（４００）、ＴＸ１００の制御部１０１はＵＳＢ認証を行う（４０１、Ｓ５０１）。ＵＳＢ認証において、制御部１０１は、第一認証部１０８を動作させ、認証対象であるすべてのＵＳＢ機器（実施形態ではＵＳＢケーブル３００とＡＣアダプタ３０１の両方）がＵＳＢ認証に対応しているかを判断する。第一認証部１０８は、すべてのＵＳＢ機器についてＵＳＢ認証を実行し、実行したすべてのＵＳＢ認証に成功した場合に、「ＵＳＢ認証成功」と判定する。また、本実施形態では、いずれかのＵＳＢ認証に成功しなかった場合の認証結果として「ＵＳＢ認証非対応」と「ＵＳＢ認証失敗」を設けている。第一認証部１０８は、ＵＳＢ認証に対応しているが認証に失敗した機器が１つでも存在する場合は「ＵＳＢ認証失敗」とする。また、第一認証部１０８は、認証に失敗した機器の属性に基づいて「ＵＳＢ認証失敗」または「ＵＳＢ認証非対応」のいずれかと判断するようにしてもよい。例えば、第一認証部１０８は、認証に失敗した機器が存在する場合に、その機器の属性を特定して、その属性に応じた判断を実行しうる。また、第一認証部１０８は、ＵＳＢ認証に成功しなかった機器がすべてＵＳＢ認証に対応していない機器である場合に「ＵＳＢ認証非対応」と判断する。

例えば、ＡＣアダプタ３０１のＵＳＢ認証に成功したが、ＵＳＢケーブル３００がＵＳＢ認証に対応していない場合、「ＵＳＢ認証非対応」と判定される。また、例えば、ＡＣアダプタ３０１のＵＳＢ認証に成功し、ＵＳＢケーブル３００はＵＳＢ認証に対応しているものの認証に失敗した場合、「ＵＳＢ認証失敗」と判定される。また、例えば、ＡＣアダプタ３０１とＵＳＢケーブル３００の両方がＵＳＢ認証に成功した場合、「ＵＳＢ認証成功」と判定される。制御部１０１は、このようなＵＳＢ認証結果をメモリ１０７に保持しておく（Ｓ５０２）。

次に、制御部１０１は、ＵＳＢ ＰＤ（ＵＳＢ－Ｐｏｗｅｒ Ｄｅｌｉｖｅｒｙ規格）のシーケンスに基づいてＡＣアダプタ３０１との間でＡＣアダプタ３０１から供給される電圧および電流に関する電源仕様を決定する（４０２）。電源電圧はＴＸ１００の内部構成により決まっているため、この場合は電流値が決定される。本実施形態では、電源部１０２の電圧は１５Ｖであるとし、電源部１０２の出力電流は最大で３Ａであるとする。ここで、ＴＸ１００の制御部１０１は、電流値を下げる際に、図６に示されるような設定に基づいて、電流値の下げ幅を判断する。例えば、ＵＳＢ認証非対応の場合、図６の列６００に基づいて、ＷＰＣ規格の交渉フェーズ（後述）での交渉において許容されるＧＰの最大値は５ワットと決定される。そして、制御部１０１は、ＴＸ１００の内部のロスを考慮して電流値を決定する。たとえば送受電コイルの位置が変化し、コイル間効率が一番低くなった時にＧＰである５ワットをＲＸ２００が出力するときのシステム効率を５０％であるとする。この場合、電源部１０２が送電部１０３や制御部１０１に供給する電力は１０ワット（５Ｗ×２）である。このため、電源電圧が１５Ｖであるため、出力電流は１０Ｗ／１５Ｖ＝０．６７Ａとなる。本実施形態では、ＵＳＢ機器がＵＳＢ認証に非対応であった場合、ＧＰを５ワットに制限するとした。このため、電源部１０２がＵＳＢ ＰＤのシーケンスに基づいてＡＣアダプタ３０１と交渉して決定すべき電流値は、０．６７Ａ程度であればよい。この決定すべき電流値に基づいて、ＴＸ１００の制御部１０１は、ＡＣアダプタ３０１との間で電源仕様を決定する。他方、ＵＳＢ認証に成功した場合は、１５ワットのＧＰ値に対応できるように、電源仕様が２．０Ａ（１５Ｗ×２／１５Ｖ）に決定される。

そして、ＴＸ１００の制御部１０１は、送電部１０３を起動する（４０３）。送電部１０３の起動は、例えば、電源部１０２から制御部１０１と送電部１０３と通信部１０４との少なくともいずれかに電源を投入する、いわゆるパワーオンリセットでありうる。または、第一認証部１０８がＴＸ１００の制御部１０１と送電部１０３と通信部１０４との少なくともいずれかに不図示のリセット信号（ＬＯ：約０Ｖ）を入力することにより、これらの機能部の少なくともいずれかにリセットをかけてもよい。この場合、第一認証部１０８は、電源仕様が決まってＧＰの値が決定された後に、リセット信号をＨＩ（例えば３．３Ｖ）にすることによって、リセットを解除する。

送電部１０３が起動すると、ＴＸ１００はＷＰＣ規格に準拠した動作を開始する。本実施形態では、ＷＰＣ規格に準拠したフェーズに加え、ＷＰＴ認証を行うフェーズとしてＡｕｔｈｅｎｔｉｃａｔｉｏｎフェーズ（以下、「認証フェーズ」と呼ぶ。）を定義する。認証フェーズでは、ＴＸとＲＸが、ＷＰＴ認証に基づいた機器認証を実行する。ＴＸおよびＲＸの両方が認証フェーズに対応している場合、ＴＸとＲＸは、まず、Ｓｅｌｅｃｔｉｏｎフェーズ（以下、「選択フェーズ」と呼ぶ。）の処理を実行する。そして、Ｐｉｎｇフェーズ、及びＩｄｅｎｔｉｆｉｃａｔｉｏｎ ＆ Ｃｏｎｆｉｇｕｒａｔｉｏｎフェーズ（以下、「Ｉ＆Ｃフェーズ」と呼ぶ。）に遷移し、その後に認証フェーズが実行される。さらに、認証フェーズの後に、交渉フェーズ、Ｃａｌｉｂｒａｔｉｏｎフェーズ、Ｐｏｗｅｒ Ｔｒａｎｓｆｅｒフェーズ（以下、「ＰＴフェーズ」と呼ぶ。）の順で処理が実行される。

選択フェーズでは、送電部１０３が、送電コイル１０５を介してＡｎａｌｏｇ Ｐｉｎｇを送電する（４０４）。Ａｎａｌｏｇ Ｐｉｎｇは、送電コイル１０５の近傍に存在する物体を検出するための微小な電力の信号である。ＴＸ１００は、Ａｎａｌｏｇ Ｐｉｎｇを送電した時の送電コイルの電圧値または電流値を検出し、電圧がある閾値を下回る場合又は電流値がある閾値を超える場合に物体が存在すると判断し、Ｐｉｎｇフェーズに遷移する。

Ｐｉｎｇフェーズでは、ＴＸ１００は、Ａｎａｌｏｇ Ｐｉｎｇより大きいＤｉｇｉｔａｌ Ｐｉｎｇを送電する（４０５）。Ｄｉｇｉｔａｌ Ｐｉｎｇの大きさは、送電コイル１０５の近傍に存在するＲＸ２００の制御部２０１が起動するのに十分な電力である。ＲＸ２００の制御部２０１は、受電コイル２０５を介して受電したＤｉｇｉｔａｌ Ｐｉｎｇによって起動すると、受電電圧の大きさをＴＸ１００へ通知し（４０６）、Ｉ＆Ｃフェーズへ遷移する。また、ＴＸ１００は、受電電圧値の通知を受けると、Ｉ＆Ｃフェーズに遷移する。

Ｉ＆Ｃフェーズでは、ＲＸ２００はＩＤ ＰａｃｋｅｔおよびＣｏｎｆｉｇｕｒａｔｉｏｎ ＰａｃｋｅｔをＴＸ１００へ送信する（４０７、４０８）。ＲＸ２００が送信したＣｏｎｆｉｇｕｒａｔｉｏｎ Ｐａｃｋｅｔに対して、ＴＸ１００は、アクノリッジ（ＡＣＫ）で応答する。そしてＴＸ１００およびＲＸ２００はＩ＆Ｃフェーズを終了し、認証フェーズに遷移する。Ｉ＆Ｃフェーズが終了すると、ＴＸ１００とＲＸ２００は、互いにデータを送信できるようになる。ここで、ＲＸ２００は、ＴＸ１００に対してＵＳＢ認証結果要求を送信し（４０９、Ｓ１１０１）、ＴＸ１００は、ＲＸ２００に対してＵＳＢ認証結果を送信する（４１０、Ｓ５０３、Ｓ１１０２）。なお、ここでのＵＳＢ認証結果の通知は、ＵＳＢ認証される機器ごと（この場合、ＵＳＢケーブル３００およびＡＣアダプタ３０１）の結果を含んでもよいし、ＵＳＢケーブル３００およびＡＣアダプタ３０１の認証結果を総合した情報を含んでもよい。例えば、ＵＳＢケーブル３００およびＡＣアダプタ３０１の両方がＵＳＢ認証に成功した場合は「ＵＳＢ認証成功」と通知され、いずれかがＵＳＢ認証に失敗した場合は「ＵＳＢ認証失敗」と通知されうる。

続いて、認証部２０８は、認証フェーズにおいて、ＴＸ１００との間で、ＷＰＴ認証処理を実行する（４１１、Ｓ１１０３）。この認証処理の認証対象は、無線電力伝送システムにおける送電装置としてのＴＸ１００である。なお、認証フェーズの詳細については後述する。制御部２０１は、このＷＰＴ認証の結果をメモリ２０９に保持する。そして、制御部２０１は、このＷＰＴ認証結果をＴＸ１００に通知する（４１２、Ｓ１１０４）。制御部２０１は、受信したＵＳＢ認証結果と、メモリ２０９に保持したＷＰＴ認証結果と、図６のような設定に基づいて、交渉フェーズで要求するＧＰの最大値を決定する（４１３、Ｓ１１０５）。

同様に、ＴＸ１００の第二認証部１０９は、認証フェーズでＷＰＴ認証処理を実行する（４１１、Ｓ５０４）。ここでは、ＴＸ１００は、ＲＸ２００から自身の正当性の認証を受ける。制御部１０１は、ＷＰＴ認証結果をＲＸ２００から受信し（４１２、Ｓ５０５）、このＷＰＴ認証結果を、メモリ１０７に保持する（Ｓ５０６）。そして、制御部１０１は、Ｓ５０２で保持したＵＳＢ認証の結果と、Ｓ５０６で保持したＷＰＴ認証の結果と、図６の設定に基づいて、交渉フェーズで許容できるＧＰの最大値を決定する（４１４、Ｓ５０７）。

その後、ＴＸ１００の制御部１０１は、交渉フェーズでＲＸ２００との交渉によりＧＰを決定する（４１５）。ここでは、第一認証部１０８（ＵＳＢ認証）と第二認証部１０９（ＷＰＴ認証）による機器認証の結果に基づいて送電電力の交渉が行われる。例えば、ＵＳＢ認証の結果が「ＵＳＢ認証成功」かつＷＰＴ認証の結果が「ＷＰＴ認証成功」の場合は、図６に示されるようにＧＰの設定が１５ワットまで許容される。一方、ＵＳＢ認証の結果が「ＵＳＢ認証非対応」であれば、ＧＰは５ワットまたはそれ未満に制限される。この場合、交渉フェーズにおいて、ＲＸ２００の制御部２０１から５ワットを超えるＧＰを要求された場合は、ＴＸ１００の制御部１０１は、その要求に対してＮＡＫを送信する。一方、制限値以下のＧＰが要求されれば、制御部１０１は、アクノリッジ（ＡＣＫ）を送信する。

以上のように、ＴＸ１００の制御部１０１は、ＵＳＢ認証およびＷＰＴ認証の両方の結果と図６の設定に基づいて許容できるＧＰの最大値を決定する。このため、複数の認証のうちのいずれかの認証が失敗した際はＧＰの大きさが制限され、過度の発熱等が予防することができる。また、制御部１０１は、全ての認証が成功した場合には、ＧＰを、送電部１０３の能力の最大値に設定することができる。また、ＲＸ２００は、Ｎｅｇｏｔｉａｔｉｏｎに先立ってＴＸ１００に対してＵＳＢ認証結果を要求し、ＴＸ１００からＵＳＢ認証結果を受信する。これにより、ＲＸ２００は、ＴＸ１００とＵＳＢケーブル３００およびＡＣアダプタとのＵＳＢ認証結果を考慮して、ＧＰの最大値を決定することが可能になる。

その後、ＴＸ１００の制御部１０１およびＲＸ２００の制御部２０１はＣａｌｉｂｒａｔｉｏｎフェーズの処理を実行し（４１６）、ＰＴフェーズへ遷移する。ＰＴフェーズでは、ＴＸ１００からＲＸ２００へ電力が伝送され（４１７）、ＲＸ２００は受信した電力に基づいて負荷へ電力を供給する。このとき、ＲＸ２００の制御部２０１は、受電電力が制限されているか否か等を示す受電状態に関する情報を表示部２０２に表示させてもよい（４１８）。制御部２０１は、例えば、ＵＳＢ認証およびＷＰＴ認証すべてが成功した場合に「高速充電中」という表示を行い、ＵＳＢ認証またはＷＰＴ認証のいずれかが失敗した場合に「低速充電中」や「充電中」との表示を行うように、表示部２０２を制御しうる。また、制御部２０１は、ＵＳＢ認証およびＷＰＴ認証が成功した場合の表示と、ＵＳＢ認証又はＷＰＴ認証の少なくともいずれかが失敗した場合の表示とを区別可能な別の表示を行うように表示部２０２を制御してもよい。これにより、ＴＸ１００又はＲＸ２００のユーザがＵＳＢ認証およびＷＰＴ認証の結果が充電電力（充電速度）にどのように反映されたかを知ることができる等、利便性を向上させることができる。

また、制御部２０１は、４１０で受信したＵＳＢ認証結果およびＷＰＴ認証処理４１０と図６のような設定に基づいて決定したＧＰを要求するため、受電電力が制限された場合にその理由を予め認識することができる。このため、制御部２０１は、受電電力が制限されている場合には、受電電力が制限されていることを理由と共に表示部２０２に表示させてもよい。制御部２０１は、例えば、「送電器に接続しているＵＳＢ機器の問題で、低速充電中」「充電器（ＴＸ１００）の問題で、低速充電中」等の表示を行うように、表示部２０２を制御してもよい。これにより、ＴＸ１００又はＲＸ２００のユーザは、ＵＳＢ認証およびＷＰＴ認証の結果が充電電力（充電速度）にどのように反映されたか、及び、充電電力が制限される場合にその原因を知ることができる。そして、ユーザが、例えば、充電器が原因で充電電力が制限されていることが表示されている場合に充電器を交換することによって、充電電力の制限を解除させることができる等、さらに利便性を向上させることができる。また、ユーザに対して制限を解除するための対策を提案するような表示が行われてもよい。例えば、制御部２０１は、「高速充電するには充電器のＵＳＢケーブルを取り換えてください」や「高速充電するには充電器（ＴＸ１００）を取り換えてください」等の表示を行うように、表示部２０２を制御してもよい。また、制御部２０１は、ＵＳＢ認証結果とＷＰＴ認証結果を表示部２０２に表示させてもよい。例えば、「充電器（ＴＸ１００）に接続されたＵＳＢケーブルとの認証に失敗しました」や「充電器（ＴＸ１００）との認証に失敗しました」等の表示が行われてもよい。

また、後述のようにＵＳＢ認証およびＷＰＴ認証が電子証明書に基づく認証処理である場合は「充電器の証明書の取得にできませんでした」や「ＵＳＢケーブルの証明書は不正です」等の表示が行われてもよい。これらの表示によれば、ＴＸ１００又はＲＸ２００のユーザは、ＵＳＢ認証およびＷＰＴ認証の結果を知ることができ、それによって充電電力（充電速度）が制限されているか否かを判定することができる。また、ユーザがＵＳＢケーブル等を交換することによって充電電力の制限を解除させることができる等、さらに利便性を向上させることができる。

また、（ＵＳＢ機器ごとの）ＵＳＢ認証結果、ＷＰＴ認証結果、充電電力、及び、充電電力を上げるための対応の４つのうちのいずれか又は複数の組み合わせが表示されてもよい。ユーザは、この表示によって電力が制限されていることを認識することで、電力が制限されない場合よりも充電に長い時間がかかることを認識し、ＵＳＢケーブルやＵＳＢアダプタをＵＳＢ認証に対応した製品に交換する等の対応をとることができる。また、この表示は、電力が制限されない場合と制限される場合とでＬＥＤの色や点灯パタ－ンを異ならしめることによって行われてもよい。また、電力が制限されない場合と制限される場合とで、異なる音や振動を発生させることにより、ユーザに情報を提示してもよい。

また、本実施形態では、ＵＳＢ認証において送電電力を制限するか否かを判断した後に、ＷＰＣの送電装置を起動すると説明したが、これに限定されない。例えば、ＵＳＢ認証が完了する前にＷＰＣの送電装置が起動されてもよい。例えば、ＷＰＴ認証によってＴＸ１００がＰＴフェーズにおいて送電を開始した後に、ＵＳＢ認証が完了する場合に対応してもよい。この場合、例えば、ＷＰＴ認証によってＴＸ１００がＰＴフェーズにおいて送電を開始した後に、ＵＳＢ認証によって送電電力を制限すべきことが判明した場合、再度Ｎｅｇｏｔｉａｔｉｏｎを実行することにより、送電電力が制限されてもよい。例えば、ＵＳＢ認証が終了した時点で、ＴＸ１００がＲＸ２００に対して再度Ｎｅｇｏｔｉａｔｉｏｎを要求しうる。なお、ＴＸ１００は、この時に、ＵＳＢ認証の結果と図６のような設定に基づいて許容できるＧＰの最大値を決定する。また、ＲＸ２００が後述のＡｕｔｈ ｃｏｍｐｌｅｔｅ ｂｉｔを定期的にＴＸ１００から取得して、Ｎｅｇｏｔｉａｔｉｏｎの実行を要求してもよい。この場合、ＲＸ２００は、Ａｕｔｈ ｃｏｍｐｌｅｔｅ ｂｉｔがＵＳＢ認証の終了を示す「１」となった時点で、ＴＸ１００に対して再度Ｎｅｇｏｔｉａｔｉｏｎを要求する。この構成によれば、システムの起動後、すぐに充電を開始することができる。

一方、上述のようにＵＳＢ認証において送電電力を制限するか否かを判断した後に、ＷＰＣの送電装置を起動する（ＷＰＴ認証を実行する）ことによれば、Ｎｅｇｏｔｉａｔｉｏｎの回数が１回で済む。すなわち、この場合、ＴＸ１００が交渉フェーズ（４１５）でＧＰを決定する際に、すでにＵＳＢ認証によって送電電力を制限すべきか否かが決定されているため、その後にＮｅｇｏｔｉａｔｉｏｎを実行する必要がなくなる。

ここで、図４の４１０においてＴＸ１００からＲＸ２００へ送信されるＵＳＢ認証結果の詳細について説明する。ＵＳＢ認証結果は、ＴＸ１００がＵＳＢ認証（４０１）の結果を示すデータであり、一例において図１０（ｂ）のようなＷＰＣ規格ｖ１．２．２のＰｏｗｅｒ Ｔｒａｎｓｍｉｔｔｅｒ Ｃａｐａｂｉｌｉｔｙ Ｐａｃｋｅｔによって送信される。例えば、図１０（ｂ）のパケット構成のうち、「Ｒｅｓｅｒｖｅｄ」となっているＢａｎｋ１のｂｉｔ７やｂｉｔ６（１０１０）、またはＢａｎｋ２のｂｉｔ７からｂｉｔ２（１０１１）の少なくともいずれかが、ＵＳＢ認証結果の送信に用いられうる。ＴＸ１００は、「ＵＳＢ認証結果を通知する機能があるか」、「ＵＳＢ認証が完了したか」、及び「ＵＳＢ認証の結果」のうちの少なくともいずれかを、これらのｂｉｔに格納して送信する。

ここでは、各情報を以下のように定義する：
ＵＳＢ Ａｕｔｈ ｂｉｔ：「ＵＳＢ認証結果を通知する機能があるか」または「ＴＸ１００がＵＳＢ認証に対応しているか」を示すｂｉｔ。ＵＳＢ Ａｕｔｈ ｂｉｔが「１」の場合はＴＸ１００の第一認証部１０８がＵＳＢ認証機能を有することを示し、「０」の場合はＴＸ１００の第一認証部１０８がＵＳＢ認証機能を有しないことを示す。
Ａｕｔｈ ｃｏｍｐｌｅｔｉｏｎ ｂｉｔ：ＵＳＢケーブル３００及びＡＣアダプタ３０１とのＵＳＢ認証が終了したかを示すｂｉｔ。ＵＳＢ ｃｏｍｐｌｅｔｅ ｂｉｔが「１」の場合はＴＸ１００の第一認証部１０８がＵＳＢケーブル３００及びＡＣアダプタ３０１とのＵＳＢ認証処理を実行して終了したことを示し、「０」の場合はそのＵＳＢ認証処理が終了していないことを示す。
ＵＳＢ Ａｕｔｈ Ｒｅｓｕｌｔ ｂｉｔ：ＵＳＢケーブル３００及びＡＣアダプタ３０１とのＵＳＢ認証結果を示すｂｉｔ。ＵＳＢ Ａｕｔｈ Ｒｅｓｕｌｔ ｂｉｔが「１」の場合はＴＸ１００の第一認証部１０８がＵＳＢケーブル３００及びＡＣアダプタ３０１とのＵＳＢ認証処理を実行して成功し、ＵＳＢケーブル３００及びＡＣアダプタ３０１の正当性が確認されたことを示す。また、ＵＳＢ Ａｕｔｈ Ｒｅｓｕｌｔ ｂｉｔが「０」の場合は、ＵＳＢ認証処理に成功しなかったことを示す。

なお、ＲＸ２００は、ＵＳＢ認証結果が格納されているＰｏｗｅｒ Ｔｒａｎｓｍｉｔｔｅｒ Ｃａｐａｂｉｌｉｔｙ Ｐａｃｋｅｔを受信するために、図４の４０９においてＵＳＢ認証結果を要求するパケットを送信する。このパケットは、一例において、ＷＰＣ規格ｖ１．２．２で規定されているＧｅｎｅｒａｌ Ｒｅｑｕｅｓｔパケットである。ＲＸ２００は、例えば、Ｇｅｎｅｒａｌ Ｒｅｑｕｅｓｔのうち、Ｐｏｗｅｒ Ｔｒａｎｓｍｉｔｔｅｒ Ｃａｐａｂｉｌｉｔｙ Ｐａｃｋｅｔを要求するメッセ－ジを送信する。また、ＴＸ１００は、ＷＰＣ規格ｖ１．２．２のＰｏｗｅｒ Ｔｒａｎｓｍｉｔｔｅｒ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｐａｃｋｅｔを拡張して、ＵＳＢ認証結果を送信してもよい。この場合、ＲＸ２００は、Ｇｅｎｅｒａｌ Ｒｅｑｕｅｓｔのうち、Ｐｏｗｅｒ Ｔｒａｎｓｍｉｔｔｅｒ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｐａｃｋｅｔを要求するメッセ－ジを送信する。また、ＷＰＣ規格ｖ１．２．２で定義されているＧｅｎｅｒａｌ Ｒｅｑｕｅｓｔのうち、Ｐａｃｋｅｔ ｔｙｐｅが未定義のＲｅｓｅｒｖｅｄ ＰａｃｋｅｔやＰｒｏｐｒｉｅｔａｒｙ Ｐａｃｋｅｔを、ＵＳＢ認証結果要求パケットとして定義してもよい。

ＴＸ１００は、ＵＳＢ認証結果要求に応答することができる場合は、ＵＳＢ Ａｕｔｈ ｂｉｔ、ＵＳＢ Ａｕｔｈ ｃｏｍｐｌｅｔｉｏｎ ｂｉｔ、ＵＳＢ Ａｕｔｈ Ｒｅｓｕｌｔ ｂｉｔの少なくともいずれかを含んだパケットをＲＸ２００へ送信する。また、ＴＸ１００は、ＵＳＢ認証結果要求に対応できない場合は、要求に対応できないことを示すＰｏｗｅｒ Ｔｒａｎｓｍｉｔｔｅｒ Ｄａｔａ Ｎｏｔ Ａｖａｉｌａｂｌｅ ＰａｃｋｅｔをＲＸ２００へ送信する。ＲＸ２００は、Ｐｏｗｅｒ Ｔｒａｎｓｍｉｔｔｅｒ Ｄａｔａ Ｎｏｔ Ａｖａｉｌａｂｌｅ Ｐａｃｋｅｔを受信すると、ＴＸ１００がＵＳＢ認証結果をＲＸ２００に通知する機能がないものとみなす。そして、ＲＸ２００は、ＴＸ１００又はＵＳＢケーブル３００若しくはＡＣアダプタ３０１がＵＳＢ認証に対応していないと判断する。

また、ＷＰＣ規格ｖ１．２．２で定義されているＳｐｅｃｉｆｉｃ Ｒｅｑｕｅｓｔのうち、Ｐａｃｋｅｔ ｔｙｐｅが未定義のＲｅｓｅｒｖｅｄ ＰａｃｋｅｔやＰｒｏｐｒｉｅｔａｒｙ Ｐａｃｋｅｔが、ＵＳＢ認証結果要求として定義されてもよい。このとき、ＴＸ１００は、ＵＳＢ認証結果要求に応答可能な場合は、ＵＳＢ Ａｕｔｈ ｂｉｔ、ＵＳＢ Ａｕｔｈ ｃｏｍｐｌｅｔｉｏｎ ｂｉｔ、ＵＳＢ Ａｕｔｈ Ｒｅｓｕｌｔ ｂｉｔの少なくともいずれかを含んだパケットをＲＸ２００へ送信する。一方、ＴＸ１００は、ＵＳＢ認証結果要求に対応できない場合は、要求に対応できないことを示すＮｏｔ－Ｄｉｆｉｎｅｄ Ｒｅｓｐｏｎｓｅ（ＮＤ Ｒｅｓｐ） ＰａｃｋｅｔをＲＸ２００へ送信する。ＲＸ２００は、ＮＤ Ｒｅｓｐ Ｐａｃｋｅｔを受信すると、ＴＸ１００がＵＳＢ認証結果をＲＸ２００に通知する機能がないものとみなす。そして、ＲＸ２００は、ＴＸ１００又はＵＳＢケーブル３００若しくはＡＣアダプタ３０１がＵＳＢ認証に対応していないと判断する。

また、ＷＰＣ規格ｖ１．２．２のパケットのうち、Ｓｐｅｃｉｆｉｃ ＲｅｑｕｅｓｔやＧｅｎｅｒａｌ Ｒｅｑｕｅｓｔ以外のパケットがＵＳＢ認証要求に用いられてもよい。例えば、Ｓｐｅｃｉｆｉｃ ＲｅｑｕｅｓｔやＧｅｎｅｒａｌ Ｒｅｑｕｅｓｔと異なり、Ｐａｃｋｅｔ ｔｙｐｅが未定義のＲｅｓｅｒｖｅｄ ＰａｃｋｅｔやＰｒｏｐｒｉｅｔａｒｙ ＰａｃｋｅｔがＵＳＢ認証要求として定義されうる。この時、ＴＸ１００は、ＵＳＢ認証結果要求に対応できない場合は、要求に対応できないことを示すＮｏｔ－Ｄｉｆｉｎｅｄ Ｒｅｓｐｏｎｓｅ（ＮＤ Ｒｅｓｐ） Ｐａｃｋｅｔを送信する。ＲＸ２００は、ＮＤ Ｒｅｓｐ Ｐａｃｋｅｔを受信すると、ＴＸ１００がＵＳＢ認証結果をＲＸ２００に通知する機能がないものとみなす。そして、ＲＸ２００は、ＴＸ１００又はＵＳＢケーブル３００若しくはＡＣアダプタ３０１がＵＳＢ認証に対応していないと判断する。

また、ＵＳＢ認証結果は、ＵＳＢ認証を行う機器の識別情報とその結果をそれぞれ含んでもよい。例えば、ＵＳＢケーブル３００がＵＳＢ認証に対応しているかを示すｂｉｔを「ＵＳＢ Ａｕｔｈ ｂｉｔ１」と定義しうる。同様に、ＵＳＢケーブル３００とのＵＳＢ認証が終了したか及びＵＳＢケーブル３００とのＵＳＢ認証結果を示すｂｉｔを、それぞれ「ＵＳＢ Ａｕｔｈ ｃｏｍｐｌｅｔｉｏｎ ｂｉｔ１」、「ＵＳＢ Ａｕｔｈ Ｒｅｓｕｌｔ ｂｉｔ１」と定義しうる。また、ＡＣアダプタ３０１がＵＳＢ認証に対応しているかを示すｂｉｔを「ＵＳＢ Ａｕｔｈ ｂｉｔ２」と定義しうる。同様に、ＡＣアダプタ３０１とのＵＳＢ認証が終了したか及びＡＣアダプタ３０１とのＵＳＢ認証結果を示すｂｉｔを、それぞれ、「ＵＳＢ Ａｕｔｈ ｃｏｍｐｌｅｔｉｏｎ ｂｉｔ２」、「ＵＳＢ Ａｕｔｈ Ｒｅｓｕｌｔ ｂｉｔ２」と定義しうる。このように、ＵＳＢケーブル３００とＡＣアダプタ３０１とのそれぞれについて、ＵＳＢ認証に対応しているか、ＵＳＢ認証が終了したか、及び、ＵＳＢ認証の結果の少なくともいずれかを、ＴＸ１００がＲＸ２００に通知してもよい。これにより、ＲＸ２００は、ＧＰを制限する原因がＵＳＢケーブル３００にあるか、ＡＣアダプタ３０１にあるかを判断することができ、上述のようにユーザへの対策を提案する表示を表示部２０２に行わせることができる。

また、ＲＸ２００は、ＵＳＢ認証結果要求を送信するか否かの判断を、ＴＸ１００の属性によって決定してもよい。例えば、ＴＸ１００がＵＳＢ認証結果をＲＸ２００に送信する能力を有するかどうかを判断するために、ＲＸ２００は、上述のＰｏｗｅｒ Ｔｒａｎｓｍｉｔｔｅｒ Ｃａｐａｂｉｌｉｔｙ Ｐａｃｋｅｔを要求してＴＸ１００から受信する。そして、ＲＸ２００は、ＵＳＢ Ａｕｔｈ ｂｉｔが「１」である場合に、上述のＲｅｓｅｒｖｅｄ ＰａｃｋｅｔやＰｒｏｐｒｉｅｔａｒｙ Ｐａｃｋｅｔを利用してＵＳＢ認証要求を送信しうる。また、ＲＸ２００は、ＵＳＢ Ａｕｔｈ ｂｉｔが「０」の場合は、ＵＳＢ認証要求を行わず、ＵＳＢ認証非対応と判断しうる。

また、ＲＸ２００は、ＵＳＢ認証結果要求を送信するか否かをＰｏｗｅｒ Ｔｒａｎｓｍｉｔｔｅｒ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｐａｃｋｅｔによって決定してもよい。例えば、ＲＸ２００は、ＴＸ１００がＵＳＢ認証結果をＲＸ２００に送信する能力を有するか否かを判断するために、Ｐｏｗｅｒ Ｔｒａｎｓｍｉｔｔｅｒ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｐａｃｋｅｔを要求してＴＸ１００から受信する。ＲＸ２００は、Ｐｏｗｅｒ Ｔｒａｎｓｍｉｔｔｅｒ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｐａｃｋｅｔに含まれる規格バージョン情報又はＴＸ１００の製造メーカを示すＭａｎｕｆａｃｔｕｒｅ ｃｏｄｅに基づき、ＵＳＢ認証結果要求を送信するかを判断しうる。例えば、ＲＸ２００は、自装置とＴＸ１００の規格バージョンが共に特定のバージョン以上の場合、ＴＸ１００がＵＳＢ認証結果要求に応答できると判断してＵＳＢ認証結果要求を送信すると決定し、そうでない場合はＵＳＢ認証結果要求を送信しないと決定する。また、ＲＸ２００は、自装置とＴＸ１００の規格バージョンが共に特定のバージョン以上であり、さらにＴＸ１００のＭａｎｕｆａｃｔｕｒｅ ｃｏｄｅが自装置の値と同一の場合に、ＴＸ１００がＵＳＢ認証結果要求に応答できると判断しうる。そして、ＲＸ２００は、この場合に、ＴＸ１００へＵＳＢ認証結果要求を送信すると決定し、それ以外の場合にはＴＸ１００がＵＳＢ認証結果要求に応答できないと判断し、ＵＳＢ認証結果要求を送信しないと決定しうる。

＜ＷＰＴ認証の動作と後方互換性＞
ＷＰＣ規格に従ってより大きな電力を送電する場合、上述のように過度の発熱等の問題が生じることを回避するためのＷＰＴ認証機能の規定が従来のＷＰＣ規格に追加される必要がある。ここで、ＷＰＴ認証機能を有するＴＸは、同様のＷＰＴ認証機能を有するＲＸに対応可能であるのみならず、レガシーのＲＸとの後方互換性を確保できることが重要である。同様に、ＷＰＴ認証機能を有するＲＸは、レガシーのＴＸとの後方互換性を確保することが重要である。しかしながら、レガシーのＷＰＣ規格に準拠しながらＷＰＴ認証機能を加えて後方互換性を考慮した手法は知られていない。

図７に、本実施形態のＴＸ１００の制御部１０１の処理の流れの例を示す。図８Ａ～図８Ｂは、バージョンＡのＴＸ１００またはＲＸ２００による後方互換性を説明するシーケンス図である。なお、以下では、ＷＰＴ認証が、ＵＳＢ認証と同様に電子証明書を用いたチャレンジ・レスポンス型の機器認証であるものとして説明するが、これに限定されない。ここでは、ＲＸ２００がＴＸ１００に対してチャレンジテキストを送信するイニシエータとして動作し、ＴＸ１００はチャレンジテキストを暗号化してＲＸ２００に送信するレスポンダとして動作する。図９Ａ～図９ＣはＲＸ２００の制御部２０１の処理の流れを示すフローチャートである。図１０（ａ）は、ＷＰＣ規格によるＣｏｎｆｉｇｕｒａｔｉｏｎ Ｐａｃｋｅｔのビット構成例を示す図である。図１０（ｂ）は、上述のように、ＷＰＣ規格によるＰｏｗｅｒ Ｔｒａｎｓｍｉｔｔｅｒ Ｃａｐａｂｉｌｉｔｙ Ｐａｃｋｅｔのビット構成例を示す図である。なお各図において、同一の処理に対しては、同一の符号を付与している。

まず、各処理の流れの説明に先立って、ＷＰＣ規格ｖ１．２．２に基づいたＴＸおよびＲＸのカテゴリについて説明する。ＧＰが５ワットのＴＸおよびＲＸは、Ｂａｓｉｃ Ｐｏｗｅｒ Ｐｒｏｆｉｌｅ（ＢＰＰ）にカテゴライズされる。また、ＧＰが５ワットより大きく１５ワット以下のＴＸおよびＲＸは、Ｅｘｔｅｎｄｅｄ Ｐｏｗｅｒ Ｐｒｏｆｉｌｅ（ＥＰＰ）にカテゴライズされる。さらに、ＷＰＣ規格ｖ１．２．２ではＧＰに関してＴＸとＲＸ間で交渉（Ｎｅｇｏｔｉａｔｉｏｎ）する機能が追加されており、ＥＰＰにカテゴライズされたＴＸ及びＲＸは、Ｎｅｇｏｔｉａｔｉｏｎ機能を有する。ＢＰＰにカテゴライズされたＴＸおよびＲＸは、Ｎｅｇｏｔｉａｔｉｏｎ機能に対応するもの及び対応しないものに、さらにカテゴライズされる。ＴＸは、ＲＸがＮｅｇｏｔｉａｔｉｏｎ機能を有するか否かを、ＲＸの設定情報が記載されているＣｏｎｆｉｇｕｒａｔｉｏｎ Ｐａｃｋｅｔ（図１０（ａ））のＮｅｇ ｂｉｔ（Ｂａｎｋ４、ｂｉｔ７）の値によって判断することができる。Ｎｅｇ ｂｉｔが「１」の場合はＮｅｇｏｔｉａｔｉｏｎ機能を有することが示され、Ｎｅｇ ｂｉｔが「０」の場合はＮｅｇｏｔｉａｔｉｏｎ機能を有しないことが示される。本実施形態では、特に指定がない限り、レガシーのＴＸおよびＲＸはＮｅｇｏｔｉａｔｉｏｎ機能を有しており、Ｎｅｇｏｔｉａｔｉｏｎは交渉フェーズで実行されるものとする。

ＷＰＴ認証に対応したＷＰＣ規格バージョンＡのＴＸおよびＲＸは、ＷＰＣ規格ｖ１．２．２に対応したレガシーのＲＸおよびＴＸと、それぞれ後方互換性を確保することが重要である。すなわち、ＷＰＣ規格バージョンＡに対応するＴＸは、バージョンＡより前のＷＰＣ規格に対応するＲＸに対しても矛盾なく動作し、バージョンＡに対応するＲＸは、バージョンＡより前のＷＰＣ規格に対応するＴＸに対しても矛盾なく動作することが重要である。

そこで、本実施形態に係るバージョンＡに対応するＴＸ１００およびＲＸ２００がＷＰＣ規格ｖ１．２．２との後方互換性を有することについて、図７、図８Ａ～８Ｂ、図９Ａ～９Ｃを参照して説明する。ＷＰＣ規格ｖ１．２．２のレガシーのＥＰＰに対応したＴＸおよびＲＸは、選択フェーズ、Ｐｉｎｇフェーズ、Ｉ＆Ｃフェーズ、交渉フェーズ、Ｃａｌｉｂｒａｔｉｏｎフェーズ、ＰＴフェーズの順で状態遷移する。また、レガシーのＴＸおよびＲＸのうち少なくともいずれかがＮｅｇｏｔｉａｔｉｏｎ機能を有しないＢＰＰの機器である場合は、ＴＸ及びＲＸは、選択フェーズ、Ｐｉｎｇフェーズ、Ｉ＆Ｃフェーズと遷移した後に、ＰＴフェーズに状態遷移する。また、上述のように、ＴＸおよびＲＸの両方が認証フェーズに対応している場合、ＴＸとＲＸは、選択フェーズ、Ｐｉｎｇフェーズ、Ｉ＆Ｃフェーズの後に、認証フェーズに遷移する。そして、このＴＸとＲＸは、認証フェーズの後に、交渉フェーズ、Ｃａｌｉｂｒａｔｉｏｎフェーズ、ＰＴフェーズの順に遷移する。

認証フェーズは、例えば、交渉フェーズより先に実行される。これは、図６を用いて説明したように、ＷＰＴ認証の結果によってＧＰの値が変わるからである。交渉フェーズにおいてＴＸとＲＸが交渉によりＧＰを決定した後で認証フェーズに遷移した場合、認証フェーズの結果に応じて、既に決定されたＧＰが再設定されうる。すなわち、ＧＰが決定された後に、ＷＰＴ認証の結果によっては、過度の発熱等の回避のためにＧＰを下げるための変更が行われる必要が生じうる。このようなＧＰの再変更が行われると、ＰＴフェーズに遷移するまでの手順が煩雑になることや、手順に要する時間が長くなることがありうる。これに対して、交渉フェーズに先立って認証フェーズが実行されることで、認証フェーズで制限されたＧＰを前提に交渉フェーズでＧＰを決定することができる。このように、交渉フェーズに先立って認証フェーズでＧＰに制限を付することにより、ＰＴフェーズに遷移するまでのＧＰの再設定が発生せず、速やかにＰＴフェーズに遷移することができる。

［ＴＸ１００とＲＸ２００が共にレガシーの場合の処理］
まず、ＴＸ１００及びＲＸ２００が共にレガシーのＥＰＰに対応している場合のＷＰＣ規格ｖ１．２．２における処理例について、図８Ａの（ａ）を用いて説明する。なお、以下では、ＴＸ１００によるＵＳＢケーブル３００およびＡＣアダプタ３０１とのＵＳＢ認証は成功したものとする。本処理例では、図７、図９ＡのフローチャートについてはレガシーのＥＰＰに関する部分のみが用いられる。すなわち、レガシーのＴＸでは、図７のＳ７０３～Ｓ７０８の処理が実行されず、レガシーのＲＸでは図９ＡのＳ９０３～Ｓ９０５及びＳ９０８の処理が実行されない。なお、図８Ａの（ａ）では、後方互換性に関係するＩ＆Ｃフェーズ以降のシーケンスのみを示している。

Ｉ＆Ｃフェーズへは、ＴＸ１００とＲＸ２００との間で選択フェーズとＰｉｎｇフェーズの処理の後に遷移する（Ｓ９０１）。Ｉ＆Ｃフェーズでは、ＲＸ２００はＴＸ１００に対してＩｄｅｎｔｉｆｉｃａｔｉｏｎ Ｐａｃｋｅｔ（ＩＤ Ｐａｃｋｅｔ）を送信し（Ｓ７０２）、ＴＸ１００は、これを受信する（８００、Ｓ７０２）。ＩＤ ｐａｃｋｅｔには、送信元装置（ＲＸ２００）の個体識別情報のほかに、対応しているＷＰＣ規格のバージョン（この場合は「１．２．２」）を特定する情報要素が格納される。続いて、ＲＸ２００は、Ｃｏｎｆｉｇｕｒａｔｉｏｎ ＰａｃｋｅｔをＴＸ１００へ送信し（Ｓ９０１）、ＴＸ１００はこれを受信する（８０１、Ｓ７０２）。ＷＰＣ規格ｖ１．２．２のＣｏｎｆｉｇｕｒａｔｉｏｎ Ｐａｃｋｅｔは、ＲＸ２００が負荷に供給可能な最大電力を特定するＭａｘｉｍｕｍ Ｐｏｗｅｒ Ｖａｌｕｅ、及び、Ｎｅｇｏｔｉａｔｉｏｎ機能を有するか否かを示すＮｅｇ ｂｉｔを含む。ここでは、ＲＸ２００は、Ｎｅｇ ｂｉｔを、Ｎｅｇｏｔｉａｔｉｏｎ機能を有することを示す「１」に設定したＣｏｎｆｉｇｕｒａｔｉｏｎ Ｐａｃｋｅｔを送信する。

ＴＸ１００は、ＲＸ２００からＩＤ ＰａｃｋｅｔおよびＣｏｎｆｉｇｕｒａｔｉｏｎ Ｐａｃｋｅｔを受信すると、ＲＸ２００がＮｅｇｏｔｉａｔｉｏｎ機能を有するかを判断する（Ｓ７０４）。なお、上述のように、レガシーのＴＸ１００は、Ｓ７０３の処理を実行しない。ここでは、ＴＸ１００は、ＲＸ２００がＮｅｇｏｔｉａｔｉｏｎ機能を有するため（Ｓ７０４でＹＥＳ）、Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐａｃｋｅｔに対してＡＣＫを送信し（Ｓ７１３、８０２）、交渉フェーズに遷移する（Ｓ７０９）。なお、ＲＸ２００がＮｅｇｏｔｉａｔｉｏｎに対応していないＢＰＰ（Ｎｅｇ ｂｉｔが０）の場合（Ｓ７０４でＮＯ）、ＴＸ１００は、ＡＣＫを送信せずにＰＴフェーズに遷移する（Ｓ７１２）。また、ＴＸ１００は、自装置がＢＰＰであり、かつ、Ｎｅｇｏｔｉａｔｉｏｎに対応してない場合も、ＡＣＫを送信せずにＰＴフェーズに遷移する。なお、この場合、ＧＰは５ワットに制限される。

ＲＸ２００は、Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐａｃｋｅｔに対するＡＣＫの受信を待機する（Ｓ９０２）。ＲＸ２００は、ＡＣＫを受信すると（Ｓ９０２でＹＥＳ）、ＴＸ１００がＮｅｇｏｔｉａｔｉｏｎ機能に対応していると判断し、交渉フェーズへ遷移する（Ｓ９０６）。なお、ここでは、上述のようにＳ９０８の処理は実行されない。そして、ＲＸ２００は、自装置が必要な電力（例えば１５ワット）を要求するＳｐｅｃｉｆｉｃ Ｒｅｑｕｅｓｔパケットを送信する。この場合、ＲＸ２００は、ＧＰとして１５ワットを要求することを示す情報要素を含んだＳｐｅｃｉｆｉｃ Ｒｅｑｕｅｓｔパケット（Ｓｐｅｃｉｆｉｃ Ｒｅｑｕｅｓｔ（１５Ｗ））をＴＸ１００へ送信する（８０３）。ここで、ＷＰＣ規格ｖ１．２．２のＲＸ２００は、Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐａｃｋｅｔ送信から１５ｍｓ以内にＡＣＫを受信しなかった場合（Ｓ９０２でＮＯ）、ＴＸ１００がＮｅｇｏｔｉａｔｉｏｎ機能を有しないＢＰＰであると判断する（Ｓ９０９）。そして、ＲＸ２００はＰＴフェーズへ状態遷移する（Ｓ９１０）。

ＴＸ１００は、Ｓｐｅｃｉｆｉｃ Ｒｅｑｕｅｓｔ（１５Ｗ）を受信すると、自装置の送電能力と要求された電力量（１５ワット）とを比較し、要求された電力量を送電可能であれば肯定応答（ＡＣＫ）をＲＸ２００へ送信する。一方、ＴＸ１００は、要求された電力量の送電を行うことができない場合は否定応答（ＮＡＫ）をＲＸ２００へ送信する。ここでは、ＴＸ１００は、１５ワットを送電可能と判断して、ＧＰを１５ワットと決定し（Ｓ７１０）、ＡＣＫを送信する（８０４）。そして、ＴＸ１００はＣａｌｉｂｒａｔｉｏｎフェーズに遷移する（Ｓ７１１）。ＲＸ２００は、８０３で送信したＳｐｅｃｉｆｉｃ Ｒｅｑｕｅｓｔに対して、ＴＸ１００からＡＣＫを受信すると、Ｃａｌｉｂｒａｔｉｏｎフェーズへ状態遷移する（Ｓ９０７）。Ｃａｌｉｂｒａｔｉｏｎフェーズでは、ＴＸ１００がＲＸ２００に送電した電力について、ＴＸ１００の内部で測定した値と、ＲＸ２００の内部で測定した受電電力の値との相関に基づいて、ＴＸ１００が調整を行う。Ｃａｌｉｂｒａｔｉｏｎフェーズが終了すると、ＴＸ１００とＲＸ２００はＰＴフェーズへ状態遷移し、無線電力伝送を開始する（Ｓ７１２、Ｓ９１０）。

以上のように、ＷＰＣ規格ｖ１．２．２のＴＸ１００は、Ｎｅｇ ｂｉｔによってＲＸ２００がＮｅｇｏｔｉａｔｉｏｎ機能を有するＥＰＰ若しくはＢＰＰ、又はＮｅｇｏｔｉａｔｉｏｎ機能を有しないＢＰＰのいずれであるかを判断する。そして、ＴＸ１００は、ＲＸ２００がＮｅｇｏｔｉａｔｉｏｎ機能を有するＥＰＰまたはＢＰＰである場合に交渉フェーズへ状態遷移して、送電電力に関する交渉を実行した後に送電を開始する。一方、ＴＸ１００は、ＲＸ２００がＮｅｇｏｔｉａｔｉｏｎ機能を有しないＢＰＰである場合、交渉フェーズに遷移せずにＰＴフェーズへ遷移して、相対的に低い電力の送電を実行する。また、ＷＰＣ規格ｖ１．２．２のＲＸ２００は、Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐａｃｋｅｔの送信から１５ｍｓ以内にＡＣＫを受信した場合には交渉フェーズに遷移し、ＡＣＫを受信しなかった場合にはＰＴフェーズへ遷移する。以上の動作により、ＷＰＣ規格ｖ１．２．２において、Ｎｅｇｏｔｉａｔｉｏｎ機能を有するＴＸ１００およびＲＸ２００とその機能を有しないＴＸ１００およびＲＸ２００の互換性が確保される。

［ＴＸ１００がバージョンＡ、ＲＸ２００がレガシーの場合の処理］
続いて、ＴＸ１００がバージョンＡに対応し、ＲＸ２００がレガシーの場合の処理例について、図８Ａの（ｂ）、図６、図７、図９Ａを用いて説明する。なお、以下では、ＴＸ１００によるＵＳＢケーブル３００およびＡＣアダプタ３０１とのＵＳＢ認証は成功したものとする。なお、以下の説明の全てがＷＰＣ規格の後方互換性に関する説明であるため、ＴＸ１００が第一認証部１０８を有しない構成であっても、以下の議論を適用することができる。

まず、処理の流れの説明に先立ち、Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐａｃｋｅｔ内のＡｕｔｈ ｂｉｔについての定義を行う。図１０（ａ）は、ＷＰＣ規格ｖ１．２．２のＣｏｎｆｉｇｕｒａｔｉｏｎ Ｐａｃｋｅｔの構成を示す図である。なお、本実施形態での説明と関連しない部分については、説明を省略する。Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐａｃｋｅｔには複数のＲｅｓｅｒｖｅｄ領域がある。例えば、Ｂａｎｋ２のｂｉｔ４からｂｉｔ６のＲｅｓｅｒｖｅｄ領域１００１、Ｂａｎｋ１のｂｉｔ０からｂｉｔ７のＲｅｓｅｒｖｅｄ領域１０００、Ｂａｎｋ４のｂｉｔ２からｂｉｔ０のＲｅｓｅｒｖｅｄ領域１００２である。本実施形態では、Ａｕｔｈ ｂｉｔをＢａｎｋ２のｂｉｔ６に配置する。ただし、Ａｕｔｈ ｂｉｔの配置はこれに限られず、他のＲｅｓｅｒｖｅｄ領域にＡｕｔｈ ｂｉｔが配置されてもよい。なお、ＷＰＣ規格ｖ１．２．２では、Ｒｅｓｅｒｖｅｄ領域のビットはいずれも０である。ＲＸ２００は、自装置がＷＰＴ認証に対応している場合にＡｕｔｈ ｂｉｔに「１」を格納し、ＷＰＴ認証に対応していない場合はＡｕｔｈ ｂｉｔに「０」を格納する。なお、Ａｕｔｈ ｂｉｔが格納される位置はＲｅｓｅｒｖｅｄ ｂｉｔであるため、この位置にＡｕｔｈ ｂｉｔが格納されることを認識しない旧世代の規格に対応するＲＸであっても、この位置の値として「０」を格納することができる。

ＴＸ１００は、Ｃｏｎｆｉｇｕｒａｔｉｏｎ ＰａｃｋｅｔのＡｕｔｈ ｂｉｔにより、ＲＸ２００がＷＰＴ認証に対応しているか否かを判断する（Ｓ７０３）。本処理例では、ＲＸ２００はレガシーであるため、Ａｕｔｈ ｂｉｔは「０」である。ＴＸ１００は、ＲＸ２００がＷＰＴ認証に対応していないと判断し（Ｓ７０３でＮＯ）、交渉フェーズに遷移する。ここで、ＴＸ１００は、ＲＸ２００からＧＰとして１５ワットの要求を受信した場合、要求を拒否するＮＡＫをＲＸ２００に送信する（８０５）。これは、ＲＸ２００がＷＰＴ認証非対応であることから、ＲＸ２００における過度の発熱等の問題が生じることを回避するために、１５ワットを送信するべきでないとＴＸ１００が判断するからである。

ＲＸ２００は、ＮＡＫにより要求が拒否されたため、ＴＸ１００が設定可能なＧＰの値を知るために、ＷＰＣ規格ｖ１．２．２で定められたＧｅｎｅｒａｌ Ｒｅｑｕｅｓｔを送信する。本実施形態では、Ｇｅｎｅｒａｌ Ｒｅｑｕｅｓｔのうち、Ｔｒａｎｓｍｉｔｔｅｒ Ｃａｐａｂｉｌｉｔｙ Ｐａｃｋｅｔを要求するメッセ－ジを、Ｇｅｎｅｒａｌ Ｒｅｑｕｅｓｔ（ｃａｐａｂｉｌｉｔｙ）と表す。ＴＸ１００は、このＧｅｎｅｒａｌ Ｒｅｑｕｅｓｔ（ｃａｐａｂｉｌｉｔｙ）を受信すると（８０６）、図６の設定に基づいて、ＷＰＴ認証非対応（行６０３）でＵＳＢ認証成功（列６０２）に対応する５ワットを許容できるＧＰの最大値として決定する。そして、ＴＸ１００は、Ｐｏｗｅｒ Ｔｒａｎｓｍｉｔｔｅｒ Ｃａｐａｂｉｌｉｔｙ ＰａｃｋｅｔのＧｕａｒａｎｔｅｅｄ Ｐｏｗｅｒ Ｖａｌｕｅに５ワットを示す情報を格納して、これをＲＸ２００に送信する（８０７）。なお、Ｔｒａｎｓｍｉｔｔｅｒ Ｃａｐａｂｉｌｉｔｙ Ｐａｃｋｅｔは、Ｎｅｇｏｔｉａｔｉｏｎで許容できるＧＰの最大値の情報を含み、ＷＰＣ規格ｖ１．２．２で定義されたパケットである。

以上のように、本実施形態で定義したＡｕｔｈ ｂｉｔによって、ＷＰＣ規格バージョンＡに対応したＴＸ１００は、バージョンＡより前のＷＰＣ規格に対応したレガシーＲＸに対しても矛盾なく動作することができる。

［ＴＸ１００、ＲＸ２００ともにバージョンＡの場合の処理］
次に、ＴＸ１００とＲＸ２００とが共にＷＰＴ認証処理に対応している場合について、図６、図７、図８Ｂの（ｅ）、図９Ａを用いて説明する。なお、以下では、ＴＸ１００によるＵＳＢケーブル３００およびＡＣアダプタ３０１とのＵＳＢ認証は成功したものとする。処理の流れの説明に先立って、ＷＰＴ認証に対応したバージョンＡのＴＸ１００とＲＸ２００の動作について説明する。

バージョンＡのＲＸ２００は、Ａｕｔｈ Ｂｉｔに「１」を格納したＣｏｎｆｉｇｕｒａｔｉｏｎ ＰａｃｋｅｔをＴＸ１００に送信する。バージョンＡのＴＸ１００は、Ｃｏｎｆｉｇｕｒａｔｉｏｎ ＰａｃｋｅｔのＡｕｔｈ Ｂｉｔによって、ＲＸ２００がＷＰＴ認証に対応していると判断すると（Ｓ７０３でＹＥＳ）、ＡＣＫ（ａｕｔｈ）をＲＸ２００に送信する（Ｓ７０５、８０２）。ＡＣＫ（ａｕｔｈ）は、ＡＣＫとは区別可能かつ異なるビットパタ－ンで構成されるＣｏｎｆｉｇｕｒａｔｉｏｎ Ｐａｃｋｅｔに対するアクノリッジであり、ＴＸ１００がＷＰＴ認証に対応していることを示すパケットである。ＴＸ１００は、ＲＸ２００がＷＰＴ認証に対応していることを特定すると、ＡＣＫ（ａｕｔｈ）を送信して認証フェーズへ遷移する（Ｓ７０６）。一方、ＲＸ２００は、ＡＣＫではなくＡＣＫ（ａｕｔｈ）を受信すると（Ｓ９０２でＮＯ、Ｓ９０３でＹＥＳ）、ＴＸ１００がＷＰＴ認証に対応していると判断する（Ｓ９０４）。そして、ＴＸ１００は、認証フェーズへ遷移する（Ｓ９０５）。

図８Ｂの（ｅ）の８１４から８２０は、本処理例に係るＷＰＴ認証の例である。ＲＸ２００は、まず、ＧＥＴ＿ＤＩＧＥＳＴメッセ－ジを送信し、ＴＸ１００はこれを受信する（８１４、Ｓ７０７）。ＧＥＴ＿ＤＩＧＥＳＴ Ｐａｃｋｅｔは、ＴＸ１００が持つ電子証明書に関する情報を要求するＰａｃｋｅｔである。ＴＸ１００は、ＧＥＴ＿ＤＩＧＥＳＴ Ｐａｃｋｅｔに応答してＤＩＧＥＳＴを送信する（８１５）。ＤＩＧＥＳＴは、ＴＸ１００が所有する電子証明書に関する情報である。続いて、ＲＸ２００は、電子証明書に関する詳細な情報を要求するＧＥＴ＿ＣＥＴＴＩＦＩＣＡＴＥ ＰａｃｋｅｔをＴＸ１００に送信する（８１６）。ＴＸ１００はＧＥＴ＿ＣＥＲＴＩＦＩＣＡＴＥ Ｐａｃｋｅｔに応答してＣＥＲＴＩＦＩＣＡＴＥをＲＸ２００へ送信する（８１７）。続いて、ＲＸ２００は、チャレンジテキストを含むＣＨＡＬＬＥＮＧＥメッセ－ジをＴＸ１００に送信し（８１８）、ＴＸ１００は、チャレンジテキストを暗号化したＲＥＳＰＯＮＳＥをＲＸ２００に送信する（８１９）。ＲＸ２００はＲＥＳＰＯＮＳＥの正当性が確認された場合に、ＲＥＳＵＬＴ（ｓｕｃｃｅｓｓ）をＴＸ１００に送信し、ＴＸ１００はこれを受信する（８２０、Ｓ７０８）、そして、交渉フェーズに遷移する（Ｓ７０９）。ＲＥＳＵＬＴ（ｓｕｃｃｅｓｓ）パケットは、ＲＥＳＰＯＮＳＥの結果により、ＷＰＴ認証が成功したことを意味する。また、ＲＥＳＰＯＮＳＥの結果、ＷＰＴ認証が失敗した場合は、ＲＸ２００は、ＲＥＳＵＬＴ（ｆａｉｌ）をＴＸ１００に送信する。なお、ＲＥＳＵＬＴ（ｓｕｃｃｅｓｓまたはｆａｉｌ）は、図４の４１２に関して説明したＷＰＴ認証結果と同義である。

ＴＸ１００は、ＲＥＳＵＬＴ（ｓｕｃｃｅｓｓ）を受信すると、交渉フェーズに遷移する。また、ＴＸ１００は、ＲＥＳＵＬＴ（ｓｕｃｃｅｓｓ）に対する不図示のＡＣＫを送信した後に交渉フェーズに遷移するようにしてもよい。また、ＲＸ２００はＲＥＳＵＬＴ（ｓｕｃｃｅｓｓ）を送信した後に、交渉フェーズに遷移する（Ｓ９０６）。ここで、ＲＸ２００はＲＥＳＵＬＴ（ｓｕｃｃｅｓｓ）に対する不図示のＡＣＫを受信した後に交渉フェーズに遷移するようにしてもよい。交渉フェーズでは、ＴＸ１００は、図６のような設定に基づいて、ＷＰＴ認証成功（行６０５）でＵＳＢ認証成功（列６０２）に対応する１５ワットを、許容するＧＰの最大値とすると決定して、Ｎｅｇｏｔｉａｔｉｏｎを行う。ここで、本処理例では、ＴＸ１００は、ＧＰとして１５ワットをＲＸ２００から要求されたとする（８０３）。このとき、ＴＸ１００は、上述のように許容できるＧＰの最大値を１５ワットとしているため、要求を認めるＡＣＫをＲＸ２００に送信する（８０４）。

なお、ＲＸ２００は、受信したＲＥＳＰＯＮＳＥに基づく認証に失敗した場合には、認証に失敗したことを示すＲＥＳＵＬＴ（ｆａｉｌ）をＴＸ１００へ送信する。この場合、ＴＸ１００は、図６のような設定に基づいて、交渉フェーズにおいてＧＰの値を決定する。また、ＴＸ１００は、ＲＥＳＵＬＴ（ｆａｉｌ）を受信した場合に送電部１０３を停止して、送電を行わないようにしてもよい。

以上のように、本実施形態のＲＸ２００は、バージョンＡより前のＷＰＣ規格に対応したＴＸに対してのみならず、バージョンＡに対応したＴＸに対しても矛盾なく動作することができる。

ここで、８１４のＧＥＴ＿ＤＩＧＥＳＴＳから８２０のＲＥＳＵＬＴ（ｓｕｃｃｅｓｓ）までのパケット間の時間間隔について説明する。ＴＸ１００のパケットに対するＲＸ２００の応答は、例えばＷＰＣ規格ｖ１．２．２の交渉フェーズでは、ＴＸ１００のパケットの後端から次にＲＸ２００が送信するパケットの先端まで１０ｍｓ以内と規定されている。しかし認証フェーズのイニシエータ（ＲＸ２００）は、ＴＸ１００が送信する電子証明書に関連するパケット（ＤＩＧＥＳＴ、ＣＥＲＴＩＦＩＣＡＴＥ、ＲＥＳＰＯＮＳＥ）の正当性を確認する処理を実行する必要がある。このため、認証フェーズでは、ＲＸ２００はＴＸ１００の応答に対して正当性を確認する処理に時間がかかる。そこで認証フェーズでは、他のフェーズにおいて規定されているＴＸ１００のパケットを受信してからＲＸ２００が次のパケットを送信するまでの時間と比較して長い時間が設けられる。本実施形態では、この時間を５０ｍｓとする。図８Ｂの（ｅ）では、ＤＩＧＥＳＴからＧＥＴ＿ＣＥＲＴＩＦＩＣＡＴＥ、ＣＥＲＴＩＦＩＣＡＴＥからＣＨＡＬＬＥＮＧＥ、ＲＥＳＰＯＮＳＥからＲＥＳＵＬＴ（ｓｕｃｃｅｓｓ）までの時間として、この時間が設定される。この時間を長くすることで、ＲＸ２００の制御部２０１が高速に動作する必要性が低下し、制御部２０１の消費電力の低減や低速なＣＰＵの使用による低コスト化を実現できる。

また、認証フェーズのレスポンダ（ＴＸ１００）もＲＸ２００が送信する電子証明書に関連するパケット（ＧＥＴ＿ＤＩＧＥＳＴ、ＧＥＴ＿ＣＥＲＴＩＦＩＣＡＴＥ、ＣＨＡＬＬＥＮＧＥ）に応答するための処理を実行する必要がある。このため、認証フェーズでは応答に時間がかかる。そこで、認証フェーズでは、他のフェーズにおける応答時間（Ｒｅｓｐｏｎｓｅ ｔｉｍｅ）と比較して長い応答時間が設けられてもよい。応答時間を長くすることで、ＴＸ１００の制御部１０１が高速に動作する必要性が低下し、制御部１０１の消費電力の低減や低速なＣＰＵの使用による低コスト化を実現できる。

なお、上述の説明では、Ｃｏｎｆｉｇｕｒａｔｉｏｎ ＰａｃｋｅｔのＡｕｔｈ ｂｉｔによってＲＸ２００がＷＰＴ認証に対応するか否かをＴＸ１００が判断するとしたが、ＩＤ Ｐａｃｋｅｔのバージョン情報に基づいてこの判断が行われてもよい。例えば、ＴＸ１００は、ＲＸ２００のバージョン情報がバージョンＡ（又はそれ以降のバージョン）の場合はＲＸ２００がＷＰＴ認証に対応していると判断し、バージョン情報がバージョンＡより前の場合はＲＸ２００がＷＰＴ認証に対応していないと判断する。

なお、ＷＰＣ規格ｖ１．２．２のＳｐｅｃｉｆｉｃ Ｒｅｑｕｅｓｔのうち、Ｐａｃｋｅｔ ｔｙｐｅが未定義のＲｅｓｅｒｖｅｄ ＰａｃｋｅｔやＰｒｏｐｒｉｅｔａｒｙ Ｐａｃｋｅｔが、電子証明書に関連するパケットとして定義されてもよい。またＷＰＣ規格ｖ１．２．２のＧｅｎｅｒａｌ Ｒｅｑｕｅｓｔのうち、Ｐａｃｋｅｔ ｔｙｐｅが未定義のＲｅｓｅｒｖｅｄ ＰａｃｋｅｔやＰｒｏｐｒｉｅｔａｒｙ Ｐａｃｋｅｔが、電子証明書に関連するパケットとして定義されてもよい。また、ＷＰＣ規格ｖ１．２．２のパケットのうち、Ｓｐｅｃｉｆｉｃ ＲｅｑｕｅｓｔやＧｅｎｅｒａｌ Ｒｅｑｕｅｓｔ以外のパケットが電子証明書に関連するパケットとして定義されてもよい。例えば、Ｓｐｅｃｉｆｉｃ ＲｅｑｕｅｓｔやＧｅｎｅｒａｌ Ｒｅｑｕｅｓｔと異なり、Ｐａｃｋｅｔ ｔｙｐｅが未定義のＲｅｓｅｒｖｅｄ ＰａｃｋｅｔやＰｒｏｐｒｉｅｔａｒｙ Ｐａｃｋｅｔが、電子証明書に関連するパケットとして定義されうる。電子証明書に関連するパケットは、上述のように、ＧＥＴ＿ＤＩＧＥＳＴ、ＧＥＴ＿ＣＥＲＴＩＦＩＣＡＴＥ、ＣＨＡＬＬＥＮＧＥパケットを含む。

［ＴＸがレガシー、ＲＸがバージョンＡの場合の処理］
続いて、ＴＸ１００がレガシーであり、ＲＸ２００がバージョンＡに対応している場合の処理例について、図８Ａの（ｃ）、図６、及び図９Ａを用いて説明する。なお、以下では、ＴＸ１００によるＵＳＢケーブル３００およびＡＣアダプタ３０１とのＵＳＢ認証は成功したものとする。

まず、バージョンＡに対応したＲＸ２００の動作について説明する。ＲＸ２００は、Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐａｃｋｅｔにより、自装置がＷＰＴ認証に対応していることをＴＸ１００に通知する（８００、８０１、Ｓ９０１）。しかしながら、この場合は、ＴＸ１００がレガシーであるため、Ａｕｔｈ ｂｉｔを無視する。そして、ＴＸ１００は、ＲＸ２００がＮｅｇｏｔｉａｔｉｏｎ機能に対応しているため、ＡＣＫを送信して、自身は交渉フェーズへ遷移する（Ｓ７０４でＹＥＳ、Ｓ７１３、Ｓ７０９）。

ＲＸ２００は、ＡＣＫを受信すると（８０２、Ｓ９０２でＹＥＳ）、ＴＸ１００がＷＰＴ認証に対応していない、レガシーのＴＸであると判断する（Ｓ９０８）。これは、ＲＸ２００がＷＰＴ認証に対応しているため、ＴＸ１００がＷＰＴ認証に対応している場合は、ＡＣＫではなくＡＣＫ（ａｕｔｈ）を受信するはずだからである。なお、ＲＸ２００は、Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐａｃｋｅｔを送信してから１５ｍｓ以内にＡＣＫを受信せず（Ｓ９０２でＮＯ）、かつＡＣＫ（ａｕｔｈ）も受信しない場合は（Ｓ９０３でＮＯ）、処理はＳ９０９へ進む。この場合、ＲＸ２００は、ＴＸ１００がＢＰＰであり、かつ、Ｎｅｇｏｔｉａｔｉｏｎ機能に対応してないと判断して（Ｓ９０９）、ＰＴフェーズへ遷移する（Ｓ９１０）。

ＲＸ２００は、交渉フェーズにおいてＧＰの交渉を行うが、図６を用いて説明したように、過度な発熱等が生じることを回避するために、１５ワットでの受電を回避すべきと判断する。このため、ＲＸ２００は、ＷＰＴ認証非対応（行６０３）でＵＳＢ認証成功（列６０２）に対応する５ワットをＧＰとして交渉すると判断し、Ｓｐｅｃｉｆｉｃ Ｒｅｑｕｅｓｔ（５Ｗ）を送信する（８０９）。そして、ＲＸ２００は、ＴＸ１００からＡＣＫを受信し（８１０）、交渉フェーズを終了する。そして、ＲＸ２００はＣａｌｉｂｒａｔｉｏｎフェーズへ遷移し（Ｓ９０７）、所定の処理を実行した後、ＰＴフェーズへ遷移する（Ｓ９１０）。

以上のように、ＷＰＣ規格バージョンＡに対応したＲＸ２００は、バージョンＡより前のＷＰＣ規格に対応したＴＸ１００に対しても矛盾なく動作することができる。さらに、図８Ｂの（ｅ）で説明したように、ＲＸ２００はＴＸ１００がＷＰＴ認証に対応している場合でも矛盾なく動作できる。

［ＴＸがレガシー、ＲＸがバージョンＡの場合の別の処理］
上述の説明では、バージョンＡに対応しているＲＸ２００は、Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐａｃｋｅｔに対するＴＸ１００からの応答に基づいてＴＸ１００がＷＰＴ認証やＮｅｇｏｔｉａｔｉｏｎ機能に対応しているか否かを判断した。すなわち、ＲＸ２００は、Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐａｃｋｅｔの送信から１５ｍｓ以内にＡＣＫとＡＣＫ（ａｕｔｈ）のどちらを受信したか、または、いずれも受信していないか、に応じて、上述の判断をする場合について説明した。ここでは、ＴＸ１００がバージョンＡに対応しているか否かの判断を行う別の例について、図８Ｂの（ｄ）及び図９Ｃを用いて説明する。なお、以下では、ＴＸ１００によるＵＳＢケーブル３００およびＡＣアダプタ３０１とのＵＳＢ認証は成功したものとする。

ＲＸ２００は、Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐａｃｋｅｔに対してＡＣＫを受信すると（Ｓ９０２でＹＥＳ）、ＷＰＴ認証の実行を要求するためにＡｕｔｈ Ｒｅｑを送信する（Ｓ９１３、８１０）。Ａｕｔｈ Ｒｅｑは、認証フェーズへ遷移し、ＷＰＴ認証処理４１０を開始することをＴＸ１００に要求するパケットであり、例えばＷＰＣ規格ｖ１．２．２でパケットタイプが規定されていないＲｅｓｅｒｖｅｄ Ｐａｃｋｅｔである。本実施形態では、Ｒｅｓｅｒｖｅｄ Ｐａｃｋｅｔのうち、パケットヘッダが０ｘ４０のパケットをＡｕｔｈ Ｒｅｑパケットとして定義する。バージョンＡに対応したＴＸは、Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐａｃｋｅｔに対してＡＣＫを返した後、Ａｕｔｈ Ｒｅｑパケットの受信に応じて認証フェーズへ遷移し、ＷＰＴ認証を開始する。

一方、バージョンＡに対応していないＴＸは、以下のように動作する。ＷＰＣ規格ｖ１．２．２は、交渉フェーズにおいて、ＴＸ１００が非対応のパケットタイプのＰａｃｋｅｔの受信に応じてＮｏｔ－Ｄｅｆｉｎｅｄ Ｒｅｓｐｏｎｓｅ（ＮＤ Ｒｅｓｐ）パケットを送信することを規定している。なお、Ｉ＆Ｃフェーズでは、ＴＸ１００は、対応していないＰａｃｋｅｔを受信しても何も応答しないように規定されている。ＴＸ１００は、８０２においてＣｏｎｆｉｇｕｒａｔｉｏｎ Ｐａｃｋｅｔに対するＡＣＫを送信しているため、交渉フェーズに遷移している。したがって、レガシーであるＴＸ１００はＡｕｔｈ Ｒｅｑのパケットに応答してＮＤ ＲｅｓｐをＲＸ２００へ送信する（８１１）。ＲＸ２００は、ＮＤ Ｒｅｓｐを受信すると（Ｓ９１４でＹＥＳ）、ＴＸ１００がＷＰＴ認証に対応していないと判断し（Ｓ９０８）、ＷＰＴ認証を行わずに、交渉フェーズへ遷移する（Ｓ９０６）。

ここで、ＲＸ２００が、送信したＡｕｔｈ Ｒｅｑに対するＮＤ Ｒｅｓｐを受信せず（Ｓ９１３でＮＯ）、ＡＣＫを受信した場合（Ｓ９１４でＹＥＳ）は、処理はＳ９０４へ進む。この場合、ＲＸ２００は、ＴＸ１００がＷＰＴ認証に対応していると判断し（Ｓ９０４）、認証フェーズへ遷移する（Ｓ９０５）。なお、Ａｕｔｈ Ｒｅｑに対して、ＲＸ２００がＮＤ ＲｅｓｐもＡＣＫも受信しない場合（Ｓ９１４でＮＯ）は、ＲＸ２００は、ＴＸ１００に対して送電の停止を要求し（Ｓ９１６）、選択フェーズに戻る。送電の停止の要求は、例えばＥｎｄ ｏｆ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐａｃｋｅｔ（ＥＴＰ）を送信することにより行われる。例えばＴＸ１００の故障やＴＸ１００とＲＸ２００との間の通信品質の劣化によってＷＰＣシーケンスを継続できない場合に、ＴＸ１００に対して送電の停止を要求することによって、システムを元の状態に戻すことができる。

また、ＲＸ２００は、ＮＤ ＲｅｓｐもＡＣＫも受信しなかった場合に、Ａｕｔｈ Ｒｅｑを再送してもよい。これは、ＴＸ１００がＡｕｔｈ Ｒｅｑを正しく受信できなかった可能性があるからである。ＷＰＣ規格ｖ１．２．２では、ＴＸ１００が交渉フェーズにおいてパケットを正しく受信できない場合には交渉フェーズに留まることが規定されている。このため、ＲＸ２００は、Ａｕｔｈ Ｒｅｑを再送して、ＴＸ１００が正しくパケットを受信できるのを待ってもよい。ＴＸ１００が正しくパケットを受信できた場合、ＲＸ２００は、ＡＣＫまたはＮＤ Ｒｅｓｐを受信して、シーケンスを継続することができる。なお、ＲＸ２００は、Ａｕｔｈ Ｒｅｑを数回（３回など）連続で送信しても、ＡＣＫもＮＤ Ｒｅｓｐも受信しない場合に、ＥＰＴを送信するようにしてもよい。

以上のように、ＴＸ１００が非対応のパケットに対して応答（ＮＤ Ｒｅｓｐ）を返す状態にある交渉フェーズの時に、ＲＸ２００は、ＴＸ１００がＷＰＴ認証に対応するか否かがわかるパケットを送信する。これにより、ＲＸ２００は、Ａｕｔｈ Ｒｅｑに対する応答に基づいてＴＸ１００がＷＰＴ認証に対応しているか否かを判断し、ＷＰＴ認証に対応していないＴＸに対しても矛盾なく動作することができる。

また、Ａｕｔｈ Ｒｅｑは、レガシーのＴＸ１００からの応答が期待される他のパケットと置き換えられてもよい。例えば、ＷＰＣ規格ｖ１．２．２で応答が期待されるパケットのうち、Ｐａｃｋｅｔ ｔｙｐｅが未定義のＲｅｓｅｒｖｅｄ Ｐａｃｋｅｔや、Ｐａｃｋｅｔ ｔｙｐｅを独自に定義できるＰｒｏｐｒｉｅｔａｒｙ Ｐａｃｋｅｔが用いられうる。応答が期待されるパケットは、例えばＧｅｎｅｒａｌ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔ、Ｓｐｅｃｉｆｉｃ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔを含む。例えば、Ｓｐｅｃｉｆｉｃ Ｒｅｑｕｅｓｔ ＰａｃｋｅｔのＲｅｑｕｅｓｔフィールドがＲｅｓｅｒｖｅｄ（０ｘ０５から０ｘＥＦ）のパケットが用いられてもよい。この場合は、ＴＸ１００は、ＷＰＴ認証に対応していない場合はＮＤ Ｒｅｓｐを送信し、ＲＸ２００はこれを受信する。また、Ｇｅｎｅｒａｌ Ｒｅｑｕｅｓｔ ＰａｃｋｅｔのＲｅｑｕｅｓｔフィールドがＲｅｓｅｒｖｅｄであるパケットが用いられてもよい。この場合、ＴＸ１００は、ＷＰＴ認証に対応していない場合は、Ｒｅｑｕｅｓｔに応答して対応できないことを示すＰｏｗｅｒ Ｔｒａｎｓｍｉｔｔｅｒ Ｄａｔａ Ｎｏｔ Ａｖａｉｌａｂｌｅ Ｐａｃｋｅｔを送信し、ＲＸ２００はこれを受信する。

また、Ａｕｔｈ Ｒｅｑを送信する前に、ＷＰＴ認証に対応しているかどうかを知るためのパケットが送受信されてもよい。例えば、ＲＸ２００は、Ｇｅｎａｒａｌ Ｒｅｑｕｅｓｔ ＰａｃｋｅｔでＴＸ１００の個体識別情報や規格バージョンが格納されるＰｏｗｅｒ Ｔｒａｎｓｍｉｔｔｅｒ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｐａｃｋｅｔを要求しうる。この場合、ＲＸ２００は、Ａｕｔｈ Ｒｅｑに先立って、Ｇｅｎｅｒａｌ Ｒｅｑｕｅｓｔ ＰａｃｋｅｔによりＴＸ１００の規格バージョンを取得する。そして、ＲＸ２００は、取得したバージョンがバージョンＡ以降の場合に、ＴＸ１００がＷＰＴ認証に対応すると判断してＡｕｔｈ Ｒｅｑを送信することができる。一方、ＲＸ２００は、取得したバージョンがバージョンＡより前の場合に、ＴＸ１００がＷＰＴ認証に対応していないと判断することができる。

また、ＲＸ２００は、Ｐｏｗｅｒ Ｔｒａｎｓｍｉｔｔｅｒ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｐａｃｋｅｔに代えて、ＴＸ１００の能力情報が格納されるＰｏｗｅｒ Ｔｒａｎｓｍｉｔｔｅｒ Ｃａｐａｂｉｌｉｔｙ Ｐａｃｋｅｔを要求してもよい。この要求は、Ｇｅｎｅｒａｌ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔで行われうる。Ｐｏｗｅｒ Ｔｒａｎｓｍｉｔｔｅｒ Ｃａｐａｂｉｌｉｔｙ Ｐａｃｋｅｔは、ＴＸ１００が送電能力を通知するためのパケットであり、これにＷＰＴ認証を実行可能であることを示す情報を含めることができる。この場合、ＷＰＣ規格ｖ１．２．２のＰｏｗｅｒ Ｔｒａｎｓｍｉｔｔｅｒ Ｃａｐａｂｉｌｉｔｙ Ｐａｃｋｅｔ（図１０（ｂ））でＲｅｓｅｒｖｅｄとなっているビット１０１０又は１０１１をＡｕｔｈ ｂｉｔとしてバージョンＡで定義する。Ａｕｔｈ ｂｉｔには、ＷＰＴ認証に対応する場合に「１」が書き込まれ、ＷＰＴ認証に対応しない場合に「０」が書き込まれる。バージョンＡに対応したＴＸ１００は、Ｐｏｗｅｒ Ｔｒａｎｓｍｉｔｔｅｒ Ｃａｐａｂｉｌｉｔｙ ＰａｃｋｅｔのＡｕｔｈ ｂｉｔに「１」を書き込む。なお、レガシーのＴＸは、Ａｕｔｈ ｂｉｔに対応しないため、このビットをＲｅｓｅｒｖｅｄとして取り扱い、「０」を格納する。

本処理例では、ＲＸ２００は、Ｒｅｓｅｒｖｅｄ Ｐａｃｋｅｔに対する応答を受信するために、ＴＸ１００が交渉フェーズに滞在している間に、Ｒｅｓｅｒｖｅｄ Ｐａｃｋｅｔを送信するようにした。これによれば、ＲＸ２００は、応答がＮＤ－ＲｅｓｐとＡＣＫのいずれであるかによりＴＸ１００がレガシーなのかＷＰＴ認証に対応しているのかを判断することができる。なお、レガシーのＴＸは、Ｉ＆Ｃフェーズに滞在中にこのようなパケットを受信したとしても、ＷＰＣ規格ｖ１．２．２の規定上応答しないことになっているため、上述の判断を行うことはできないことに留意されたい。

［ＴＸがレガシー、ＲＸがバージョンＡの場合のさらに別の処理］
ＴＸ１００がＷＰＴ認証に対応しているか否かをＡＣＫ（ａｕｔｈ）またはＡｕｔｈ Ｒｅｑに対する応答によってＲＸ２００が判断する例について説明した。以下では、他の例について図９Ｂを用いて説明する。なお、以下では、ＴＸ１００によるＵＳＢケーブル３００およびＡＣアダプタ３０１とのＵＳＢ認証は成功したものとする。

説明に先立ち、ＷＰＴ認証に対応したＴＸ１００の動作について説明する。ＴＸ１００は、Ｃｏｎｆｉｇｕｒａｔｉｏｎ ＰａｃｋｅｔによってＲＸ２００がＷＰＴ認証に対応していると判断すると、認証フェーズに遷移する。そして、ＴＸ１００は、Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐａｃｋｅｔに対するＡＣＫの後端から一定時間以内にＧＥＴ＿ＤＩＧＥＳＴパケットの先頭をＲＸ２００から受信する。ここで、本実施形態では、ＷＰＣ規格ｖ１．２．２のＳｐｅｃｉｆｉｃ Ｒｅｑｕｅｓｔのうち、Ｐａｃｋｅｔ ｔｙｐｅが定義されていないヘッダ番号のパケットの１つを、ＧＥＴ＿ＤＩＧＥＳＴパケットと定義する。

ＲＸ２００は、Ｉ＆Ｃフェーズの後にＧＥＴ＿ＤＩＧＥＳＴを送信する（Ｓ９１１）。その後、ＲＸ２００は、ＴＸ１００がレガシーの場合にはＮＤ ＲＥＳＰを受信するため（Ｓ９１２でＹＥＳ）、ＴＸ１００がＷＰＴ認証に対応していないと判断し（Ｓ９０８）、交渉フェーズに遷移する。このように、ＲＸ２００はレガシーのＴＸ１００に対して矛盾なく動作する。また、ＴＸ１００がＷＰＴ認証に対応している場合、ＲＸ２００はＮＤ Ｒｅｓｐを受信せず（Ｓ９１２でＮＯ）、ＤＩＧＥＳＴメッセージを受信する。このため、ＲＸ２００はＴＸ１００がＷＰＴ認証対応であると判断し（Ｓ９０４）、認証フェーズに遷移する（Ｓ９０５）。

また、上述の説明では、ＧＥＴ＿ＤＩＴＥＳＴパケットをＳｐｅｃｉｆｉｃ Ｒｅｑｕｅｓｔの１つと定義したが、これをＧｅｎｅｒａｌ Ｒｅｑｕｅｓｔの１つと定義してもよい。例えば、Ｇｅｎｅｒａｌ Ｒｅｑｕｅｓｔのうち、Ｐａｃｋｅｔ ｔｙｐｅが定義されていないヘッダ番号のパケットの１つを、ＧＥＴ＿ＤＩＧＥＳＴパケットと定義しうる。そして、ＴＸ１００がレガシーの場合は、ＲＸ２００は、ＧＥＴ＿ＤＩＧＥＳＴを送信した後に（Ｓ９１１）、Ｐｏｗｅｒ Ｔｒａｎｓｍｉｔｔｅｒ Ｄａｔａ Ｎｏｔ Ａｖａｉｌａｂｌｅ Ｐａｃｋｅｔを受信する（Ｓ９１２でＹＥＳ）。

また、ＧＥＴ＿ＤＩＴＥＳＴパケットは、ＷＰＣ規格ｖ１．２．２のパケットのうち、Ｓｐｅｃｉｆｉｃ ＲｅｑｕｅｓｔやＧｅｎｅｒａｌ Ｒｅｑｕｅｓｔ以外のパケットがＧＥＴ＿ＤＩＧＥＳＴパケットとして用いられてもよい。例えば、Ｓｐｅｃｉｆｉｃ ＲｅｑｕｅｓｔやＧｅｎｅｒａｌ Ｒｅｑｕｅｓｔと異なり、Ｐａｃｋｅｔ ｔｙｐｅが未定義のＲｅｓｅｒｖｅｄ ＰａｃｋｅｔやＰｒｏｐｒｉｅｔａｒｙ Ｐａｃｋｅｔの１つとしてＧＥＴ＿ＤＩＧＥＳＴパケットが定義される。そして、ＴＸ１００がレガシーの場合は、ＲＸ２００は、ＧＥＴ＿ＤＩＧＥＳＴを送信した後に（Ｓ９１１）、ＮＤ＿ＲＥＳＰを受信する（Ｓ９１２でＹＥＳ）。

以上のように、本実施形態のＲＸ２００は、ＴＸ１００がレガシーである場合およびＷＰＴ認証に対応している場合に、矛盾なく動作することができる。

また、認証フェーズにおいて、ＴＸ１００が所定のパケット以外のパケットをＲＸ２００から受信した場合は、送電部１０３の送電を停止し、選択フェーズに遷移してもよい。ここで、所定のパケットは８１４から８２０のパケットであり、ＧＥＴ＿ＤＩＧＥＳＴ、ＤＩＧＥＳＴ、ＧＥＴ－ＣＥＲＴＩＣＡＲＴＥ、ＣＥＲＴＩＦＩＣＡＴＥ、ＣＨＡＬＬＥＮＧＥ、ＲＥＳＰＯＮＳＥ、ＲＥＳＵＬＴである。認証フェーズにおいて、Ｓｉｇｎａｌ Ｓｔｒｅｎｇｔｈ Ｐａｃｋｅｔ、Ｃｏｎｔｒｏｌ Ｅｒｒｏｒ Ｐａｃｋｅｔ、ＩＤ Ｐａｃｋｅｔ、Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐａｃｋｅｔ等を受信すると、ＴＸ１００は送電を停止する。ここで、Ｓｉｇｎａｌ Ｓｔｒｅｎｇｔｈ Ｐａｃｋｅｔは受電した電圧の電圧値を示すパケットであり、Ｃｏｎｔｒｏｌ Ｅｒｒｏｒ Ｐａｃｋｅｔ、ＩＤ Ｐａｃｋｅｔは電圧値の増減を要求するパケットである。そして、ＴＸ１００は、選択フェーズに戻る。このように、ＴＸ１００は、認証フェーズにおいて、ＲＸ２００の故障等により所定のパケット以外のパケットを受信した場合に送電を停止して、システムが予期せぬ動作をすることを防ぐことができる。

以上のように、本実施形態の非接触充電システムでは、電力供給源である電源装置（ＡＣアダプタ３０１）と送電装置との間でＵＳＢプロトコルを用いた機器認証が行われ、送電装置と受電装置との間でＷＰＣプロトコルを用いた機器認証が行われる。そして、受電装置は、ＵＳＢの機器認証結果とＷＰＣの機器認証結果とに基づいて、ＷＰＣの送電装置が送電電力を制御する。これにより、複数種類の機器認証プロトコルを実行可能な無線電力伝送において、それらの認証結果を有効に利用することができる。その結果、例えば、電源供給の経路に存在する機器において過度の発熱等の問題が生じない適切な送電制御を実現できる。

また、ＷＰＣの送電装置が受電装置に送電を開始するのに先立って、ＵＳＢの認証結果に基づいてＷＰＣの送電装置の送電電力を制限する。これにより、ＷＰＣによる送電開始後に、ＵＳＢ認証の結果に基づく送電電力の制限による送電電力の再交渉などが発生せず、高速な制御を実現できる。

＜その他の実施形態＞
本実施形態に係る無線電力伝送システムの電力伝送方式は特に限定されない。例えば、ＴＸの共振器（共鳴素子）と、ＲＸの共振器（共鳴素子）との間の磁場の共鳴（共振）による結合によって電力を伝送する磁界共鳴方式が用いられうる。また、電磁誘導方式、電界共鳴方式、マイクロ波方式、レ－ザ－等を利用した電力伝送方式が用いられてもよい。

また、ＴＸおよびＲＸは、例えば、撮像装置（カメラやビデオカメラ等）やスキャナ等の画像入力装置や、プリンタ、コピー機、プロジェクタ等の画像出力装置であってもよい。また、ＴＸ及びＲＸは、ハードディスク装置やメモリ装置などの記憶装置であってもよいし、パーソナルコンピュータ（ＰＣ）やスマートフォンなどの情報処理装置であってもよい。

また、図５、図７、図９Ａ～９Ｃ及び図１１に示すフローチャ－トは、例えば、制御部１０１又は制御部２０１に電源が投入された場合に開始される。例えば、図５及び図７に示される処理はＴＸ１００のメモリ１０７に記憶されたプログラムを制御部１０１が実行することにより実現されうる。また、図９Ａ～９Ｃ及び図１１に示すフローチャ－トは、ＲＸ２００のメモリ２０９に記憶されたプログラムを制御部２０１が実行することによって実現されうる。なお、図５、図７、図９Ａ～９Ｃ及び図１１のフローチャ－トで示される処理の少なくとも一部がハードウェアによって実現されてもよい。例えば、所定のコンパイラを用いて、各ステップを実現するためのプログラムからＦＰＧＡ上に自動的に生成された専用回路により処理が実現されうる。また、ＦＰＧＡと同様にしてＧａｔｅ Ａｒｒａｙ回路を形成し、ハードウェアとして実現するようにしてもよい。

本発明は上述の実施形態の１以上の機能を実現するプログラムを、ネットワ－ク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュ－タにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１００：ＴＸ、１０１：制御部、１０２：電源部、１０３：送電部、１０４：通信部、１０５：送電コイル、１０６：表示部、１０７：メモリ、１０８：第一認証部、１０９：第二認証部、２００：ＲＸ、２０１：制御部、２０２：表示部、２０３：受電部、２０４：通信部、２０５：受電コイル、２０６：充電部、２０７：バッテリ、２０８：認証部、２０９：メモリ

Claims (25)

1. 電源装置から供給された電力を用いた送電装置から無線で受電する受電装置であって、
   第一の通信プロトコルを使用した前記電源装置と前記送電装置との間での第一の機器認証の結果を前記送電装置から取得する取得手段と、
   前記第一の通信プロトコルと異なる媒体を使用する第二の通信プロトコルを使用して前記送電装置と第二の機器認証を行う認証手段と、
   前記第一の機器認証の結果と前記第二の機器認証の結果とに基づいて、前記送電装置と送電電力に関する交渉を行う交渉手段と、
   を有することを特徴とする受電装置。
2. 前記送電装置が前記第一の機器認証に対応していることを確認する第一の確認手段をさらに有することを特徴とする請求項１に記載の受電装置。
3. 前記第一の確認手段は、前記第二の通信プロトコルにより前記送電装置から受信した第一の所定のパケットに基づいて前記確認を行うことを特徴とする請求項２に記載の受電装置。
4. 前記第一の所定のパケットは、ＷＰＣ規格のＰｏｗｅｒ Ｔｒａｎｓｍｉｔｔｅｒ Ｃａｐａｂｉｌｉｔｙ Ｐａｃｋｅｔであることを特徴とする請求項３に記載の受電装置。
5. 前記認証手段は、前記第一の所定のパケットを受信した後に、前記第二の通信プロトコルを用いた前記第二の機器認証を開始することを特徴とする請求項３または４に記載の受電装置。
6. 前記送電装置が前記第二の機器認証に対応していることを確認する第二の確認手段をさらに有することを特徴とする請求項１から５のいずれか１項に記載の受電装置。
7. 前記第二の確認手段は、前記第二の通信プロトコルにより前記送電装置へ第二の所定のパケットを送信した際の応答に基づいて前記送電装置が前記第二の機器認証に対応していることの確認を行うことを特徴とする請求項６に記載の受電装置。
8. 前記応答は、前記第二の機器認証が可能であることを示す、前記第二の所定のパケットに対するアクノリッジであることを特徴とする請求項７に記載の受電装置。
9. 前記第二の所定のパケットは、ＷＰＣ規格のＣｏｎｆｉｇｕｒａｔｉｏｎ Ｐａｃｋｅｔであることを特徴とする請求項７又は８に記載の受電装置。
10. 前記送電装置から受信する当該送電装置の能力を通知するためのパケットに前記第二の機器認証を行う能力があることを示す情報が含まれる場合に、前記第二の通信プロトコルを用いた前記第二の機器認証を実行することを特徴とする請求項１から５のいずれか１項に記載の受電装置。
11. 前記第一の機器認証が成功しない場合は、前記交渉手段において前記第一の機器認証が成功した場合と比較して小さい電力値を要求することを特徴とする請求項１から１０のいずれか１項に記載の受電装置。
12. 前記第一の機器認証と前記第二の機器認証が共に成功した場合に、前記交渉手段は前記送電装置の送電能力または前記受電装置の受電能力のいずれかの最大値に基づいて前記交渉を実行することを特徴とする請求項１から１１のいずれか１項に記載の受電装置。
13. 認証対象の機器が前記第一の機器認証または前記第二の機器認証に対応していない場合に、前記交渉手段において前記送電装置に要求する送電電力は、前記第一の機器認証と前記第二の機器認証が成功した場合と比較して小さいことを特徴とする請求項１から１２のいずれか１項に記載の受電装置。
14. 前記取得手段は、さらに、前記第一の機器認証が終了したことを示す情報を取得し、
    前記交渉手段は、前記第一の機器認証が終了したと判断した場合に、前記交渉を実行することを特徴とする請求項１から１３のいずれか１項に記載の受電装置。
15. 前記第二の機器認証の結果を前記送電装置へ送信する送信手段をさらに有することを特徴とする請求項１から１４のいずれか１項に記載の受電装置。
16. 前記交渉手段による交渉の結果と、前記交渉の結果に関する前記第一の機器認証または前記第二の機器認証の結果との少なくともいずれかをユーザに提示する提示手段をさらに有することを特徴とする請求項１から１５のいずれか１項に記載の受電装置。
17. 前記認証手段は、前記受電装置が前記送電装置から無線で電力を受電するためのコイルを用いて通信を行うことにより前記第二の機器認証を行うことを特徴とする請求項１から１６のいずれか１項に記載の受電装置。
18. 前記交渉手段は、前記第一の機器認証の結果と前記第二の機器認証の結果とに基づいて許容される送電電力を決定し、前記受電装置への送電電力が前記決定された送電電力を越えないように交渉を行うことを特徴とする請求項１から１７のいずれか１項に記載の受電装置。
19. 前記電源装置はケーブルを介して電力を供給し、
    前記第一の機器認証では、前記電源装置と前記ケーブルについて機器認証が行われることを特徴とする請求項１から１８のいずれか１項に記載の受電装置。
20. 受電装置に無線で送電する送電装置であって、
    所定の通信プロトコルを使用して前記受電装置と機器認証を行う認証手段と、
    前記受電装置へ、ＷＰＣ規格のＰｏｗｅｒ Ｔｒａｎｓｍｉｔｔｅｒ Ｃａｐａｂｉｌｉｔｙ Ｐａｃｋｅｔに前記機器認証を行う能力があることを示す情報を含めて送信することにより、前記機器認証を行う能力があることを通知する通知手段と、
    前記通知手段による通知に対する前記受電装置の応答に基づいて、前記受電装置が前記機器認証に対応しているか否かを判定する判定手段と、
    前記判定手段により前記受電装置が前記機器認証に対応していると判定された場合に、前記認証手段による前記機器認証を実行する実行手段と、
    を有することを特徴とする送電装置。
21. 電源装置から供給された電力を用いて無線で送電する送電装置と、前記送電装置から無線で受電する受電装置と、を含んだ無線電力伝送システムであって、
    前記送電装置は、
    第一の通信プロトコルを使用して前記電源装置と送電装置との間で第一の機器認証を行う第一の認証手段と、
    前記第一の機器認証の結果を前記受電装置に通知する通知手段と、
    を有し、
    前記受電装置は、
    前記第一の機器認証の結果を取得する取得手段と、
    前記第一の通信プロトコルと異なる媒体を使用する第二の通信プロトコルを使用して前記送電装置と第二の機器認証を行う第二の認証手段と、
    前記第一の機器認証の結果と前記第二の機器認証の結果とに基づいて、前記送電装置と送電電力に関する交渉を行う交渉手段と、
    を有することを特徴とする無線電力伝送システム。
22. 電源装置から供給された電力を用いた送電装置から無線で受電する受電装置の制御方法であって、
    第一の通信プロトコルを使用した前記電源装置と前記送電装置との間での第一の機器認証の結果を前記送電装置から取得する取得工程と、
    前記第一の通信プロトコルと異なる媒体を使用する第二の通信プロトコルを使用して前記送電装置と第二の機器認証を行う第二の認証工程と、
    前記第一の機器認証の結果と前記第二の機器認証の結果とに基づいて、前記送電装置と送電電力に関する交渉を行う交渉工程と、
    を有することを特徴とする制御方法。
23. 所定の通信プロトコルを使用して受電装置と機器認証を行う認証手段を有し、前記受電装置に無線で送電する送電装置の制御方法であって、
    前記受電装置へ、ＷＰＣ規格のＰｏｗｅｒ Ｔｒａｎｓｍｉｔｔｅｒ Ｃａｐａｂｉｌｉｔｙ Ｐａｃｋｅｔに前記機器認証を行う能力があることを示す情報を含めて送信することにより、前記機器認証を行う能力があることを通知する通知工程と、
    前記通知工程における通知に対する前記受電装置の応答に基づいて、前記受電装置が前記機器認証に対応しているか否かを判定する判定工程と、
    前記判定工程により前記受電装置が前記機器認証に対応していると判定された場合に、前記認証手段による前記機器認証を実行する実行工程と、
    を有することを特徴とする制御方法。
24. コンピュータを、請求項１から１９のいずれか１項に記載された受電装置の各手段として機能させるためのプログラム。
25. コンピュータを、請求項２０に記載された送電装置の各手段として機能させるためのプログラム。

Images