JP7348721B2

JP7348721B2 - コントローラ、制御方法、制御プログラム

Info

Publication number: JP7348721B2
Application number: JP2018223029A
Authority: JP
Inventors: 暖青木
Original assignee: Renesas Electronics Corp
Current assignee: Renesas Electronics Corp
Priority date: 2018-11-29
Filing date: 2018-11-29
Publication date: 2023-09-21
Anticipated expiration: 2038-11-29
Also published as: JP2020087149A; CN111240453B; US11281271B2; CN111240453A; US20200174538A1

Description

本開示は、コントローラに関し、例えば、ＵＳＢ（Universal Serial Bus）規格に従うシーケンスを実行して接続先との間で受給電動作を実行するために用いられる。

ＵＳＢ規格として、ＵＳＢＴｙｐｅ－Ｃ規格が規定され、ＵＳＢＴｙｐｅ－Ｃ規格に従うＵＳＢＴｙｐｅ－Ｃ型インターフェースが普及しつつある（例えば、非特許文献１など参照）。ＵＳＢＴｙｐｅ－Ｃ型インターフェースでは、給電および受電は同一形状のポートが用いられることになる。そのため、単一のポートで給電および受電の両方に対応することになる。

ＵＳＢＴｙｐｅ－Ｃ規格においては、電力を供給するデバイス（給電側）を「Ｓｏｕｒｃｅ」あるいは「ＳＲＣ」と称し、電力を受電するデバイス（受電側）を「Ｓｉｎｋ」あるいは「ＳＮＫ」と称する。さらに、給電および受電の両方に対応するデバイスを「ＤＲＰ（Dual Role Power）」と称する。ＤＲＰを採用することで、従来では別々に２つ必要だったポートが一つで済み、コストおよびスペースを削減できる。

このような利点により、モバイルバッテリなどのＰｏｗｅｒＢａｎｋをはじめとして、スマートフォン、タブレット、ラップトップパソコンなどのモバイルデバイスにおいて、ＵＳＢＴｙｐｅ－Ｃ型インターフェースが採用される場合には、１つのポートで給電および受電の両方に対応できるように、ＰｏｒｔＰｏｗｅｒＲｏｌｅとしてＤＲＰが採用されることが予想される。

"Universal Serial Bus Type-C Cable and Connector Specification", Release 1.3, July 14, 2017 "Universal Serial Bus Type-C (USB Type-C) Functional Test Specification", Revision:0.79, May 28, 2018 "Universal Serial Bus Power Delivery Specification", Revision:3.0, Version:1.2, June 21 2018

ＰｏｒｔＰｏｗｅｒＲｏｌｅとしてＤＲＰを有するデバイス同士を接続した場合、ＰｏｗｅｒＲｏｌｅ（すなわち、どちらのデバイスがＳＲＣ／ＳＮＫになるか）は一意には決まらない。そこで、非特許文献１に示されるＵＳＢＴｙｐｅ－Ｃ規格においては、ＰｏｒｔＰｏｗｅｒＲｏｌｅとして、「Ｔｒｙ．ＳＲＣ」（ＳＲＣを志向するＤＲＰ）および「Ｔｒｙ．ＳＮＫ」（ＳＮＫを志向するＤＲＰ）が規定されている。

例えば、Ｔｒｙ．ＳＲＣ（ＳＲＣを志向するＤＲＰ）とＤＲＰ（純粋なＤＲＰ）と接続した場合、Ｔｒｙ．ＳＲＣ側のデバイスがＳＲＣとなる。同様に、Ｔｒｙ．ＳＮＫ（ＳＮＫを志向するＤＲＰ）とＤＲＰ（純粋なＤＲＰ）とを接続した場合、Ｔｒｙ．ＳＮＫ側のデバイスがＳＮＫとなる。

本願発明者は、このようなＴｒｙ．ＳＲＣまたはＴｒｙ．ＳＮＫを採用した場合に、新たな課題が生じる得ることを見出した。

その他の課題と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

ある実施の形態に従うコントローラは、ＵＳＢＴｙｐｅ－Ｃ規格に従う、給電側および受電側のいずれにもなり得るＤＲＰに対応したデバイスを実現するために用いられる。コントローラは、接続先のデバイスである対向デバイスとのシーケンスに従って、自デバイスのＰｏｗｅｒＲｏｌｅが受電側を意味するＳｉｎｋに決定されると、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣであるか否かを判断する第１の処理と、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣであれば、自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅをＳＲＣｏｎｌｙに切り替えて、対向デバイスとのシーケンスを継続する第２の処理とを実行可能に構成される。

ある実施の形態によれば、Ｔｒｙ．ＳＲＣまたはＴｒｙ．ＳＮＫを採用した場合に生じ得る新たな課題を解決できる。

ＵＳＢＴｙｐｅ－Ｃ規格に従うＰｏｗｅｒＲｏｌｅを決定する一例を説明するための図である。ＵＳＢＴｙｐｅ－Ｃ規格に従うデバイス接続に係るＰｏｗｅｒＲｏｌｅの決定例を示す図である。本発明の各実施の形態に従うＰｏｗｅｒＢａｎｋのハードウェア構成例を示す模式図である。図３に示すコントローラ１１０の回路構成の一例を示す模式図である。実施の形態１に従うデバイスにおけるＰｏｗｅｒＲｏｌｅの決定例を示す図である。実施の形態１に従うデバイスのステートマシンの一例を示す図である。実施の形態１に従うデバイスがＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣである対向デバイスと接続された場合のシーケンス（ＰｏｒｔＰｏｗｅｒＲｏｌｅの切り替えなし）の一例を示す図である。実施の形態１に従うデバイスがＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣである対向デバイスと接続された場合のシーケンス（ＰｏｒｔＰｏｗｅｒＲｏｌｅの切り替えあり）の一例を示す図である。実施の形態１に従うデバイスがＰｏｒｔＰｏｗｅｒＲｏｌｅがＳＲＣｏｎｌｙである対向デバイスと接続された場合のシーケンスの一例を示す図である。図７～図９に示す各シーケンスに対応するステートマシンを示す図である。実施の形態１に従うデバイス同士が接続された場合のシーケンスの一例を示す図である。実施の形態２に従うデバイスのステートマシンの一例を示す図である。実施の形態２に従うデバイスと実施の形態１に従うデバイスとが接続された場合のシーケンスの一例を示す図である。実施の形態３に従うデバイスにおいて採用される切替条件ＳＲを説明するための図である。実施の形態４に従うデバイスにおいて採用される切替条件ＳＲを説明するための図である。実施の形態４の変形例に従うデバイスにおいて採用される切替条件ＳＲを説明するための図である。実施の形態５に従うデバイスにおけるＰｏｗｅｒＲｏｌｅの決定例を示す図である。実施の形態５に従うデバイスのステートマシンの一例を示す図である。実施の形態５に従うデバイスのステートマシンの要部を示す図である。実施の形態５に従うデバイスにおいて採用される切替条件ＳＮを説明するための図である。

いくつかの実施の形態について、図面を参照しながら詳細に説明する。なお、図中の同一または相当部分については、同一の参照符号を付してその説明は繰り返さない。

［Ａ．背景技術］
まず、ＵＳＢＴｙｐｅ－Ｃ規格におけるＰｏｗｅｒＲｏｌｅについて説明する。

ＵＳＢＴｙｐｅ－Ｃ規格においては、電力を供給するデバイス（給電側）である「Ｓｏｕｒｃｅ」あるいは「ＳＲＣ」、ならびに、電力を受電するデバイス（受電側）である「Ｓｉｎｋ」あるいは「ＳＮＫ」に加えて、給電および受電の両方に対応するデバイスである「ＤＲＰ」が規定されている。

ＤＲＰとして構成されたデバイス同士を接続した場合、ＰｏｗｅｒＲｏｌｅ（すなわち、どちらのデバイスがＳＲＣ／ＳＮＫになるか）は一意には決まらない。そこで、ＵＳＢＴｙｐｅ－Ｃ規格においては、「Ｔｒｙ．ＳＲＣ」（ＳＲＣを志向するＤＲＰ）および「Ｔｒｙ．ＳＮＫ」（ＳＮＫを志向するＤＲＰ）が規定されている。

図１は、ＵＳＢＴｙｐｅ－Ｃ規格に従うＰｏｗｅｒＲｏｌｅを決定する一例を説明するための図である。図１には、ＰｏｗｅｒＢａｎｋ１００と、スマートフォン２００と、ラップトップパソコン３００とを示す。これらのデバイスは、いずれもＤＲＰとして構成されているとする。

図１（ａ）に示すように、ＰｏｗｅｒＢａｎｋ１００とスマートフォン２００とを接続した場合には、通常、ＰｏｗｅｒＢａｎｋ１００からスマートフォン２００へ電力が供給されることが予定される。すなわち、ＰｏｗｅｒＢａｎｋ１００がＳＲＣとなり、スマートフォン２００がＳＮＫとなることが好ましい。

また、図１（ｂ）に示すように、ラップトップパソコン３００とスマートフォン２００とを接続した場合には、ラップトップパソコン３００がより大きなバッテリを搭載していることを考えると、ラップトップパソコン３００スマートフォン２００へ電力が供給されることが予定される。すなわち、ラップトップパソコン３００がＳＲＣとなり、スマートフォン２００がＳＮＫとなることが好ましい。

図１（ａ）および図１（ｂ）に示すような使用形態を想定すると、ＰｏｗｅｒＢａｎｋ１００およびラップトップパソコン３００は、いずれもＴｒｙ．ＳＲＣとして構成し、スマートフォン２００は、Ｔｒｙ．ＳＮＫとして構成することが好ましい。

ここで、図１（ｃ）に示すように、ＰｏｗｅｒＢａｎｋ１００とラップトップパソコン３００とを接続した場合を想定する。この場合、通常、ＰｏｗｅｒＢａｎｋ１００からラップトップパソコン３００へ電力が供給されることが期待される。そのため、ＰｏｗｅｒＢａｎｋ１００はＳＲＣとなり、ラップトップパソコン３００はＳＮＫとなることが好ましい。

しかしながら、図１（ａ）および図１（ｂ）に示されるような使用形態を想定して、ＰｏｗｅｒＢａｎｋ１００およびラップトップパソコン３００をＴｒｙ．ＳＲＣとして構成した場合には、ＰｏｗｅｒＢａｎｋ１００およびラップトップパソコン３００の間のＰｏｗｅｒＲｏｌｅは一意には決まらない、という新たな課題を見出した。

すなわち、Ｔｒｙ．ＳＲＣ同士を接続した場合には、ＰｏｗｅｒＲｏｌｅ（すなわち、どちらのデバイスがＳＲＣ／ＳＮＫになるか）は一意には決まらない。同様に、Ｔｒｙ．ＳＮＫ同士を接続した場合にも、ＰｏｗｅｒＲｏｌｅ（すなわち、どちらのデバイスがＳＲＣ／ＳＮＫになるか）は一意には決まらない。

図２は、ＵＳＢＴｙｐｅ－Ｃ規格に従うデバイス接続に係るＰｏｗｅｒＲｏｌｅの決定例を示す図である。図２に示すように、デバイスに設定される役割を示すＰｏｒｔＰｏｗｅｒＲｏｌｅとしては、「ＳＲＣｏｎｌｙ」、「Ｔｒｙ．ＳＲＣ」、「ＤＲＰ」、「Ｔｒｙ．ＳＮＫ」、「ＳＮＫｏｎｌｙ」の５種類が存在する。また、接続状態におけるデバイスの各ポートの役割を示すＰｏｗｅｒＲｏｌｅとしては、「ＳＮＫ」および「ＳＲＣ」の２種類が存在する。

なお、ＰｏｒｔＰｏｗｅｒＲｏｌｅおよびＰｏｗｅｒＲｏｌｅは、デバイスが有しているポート毎にそれぞれ独立して設定されることになる。説明の便宜上、以下では、各デバイスの単一のポートに注目して説明する。

図２を参照して、自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣである場合には、接続先のデバイスである対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣであるときには、接続後の自デバイスのＰｏｗｅｒＲｏｌｅは一意には決まらない。

同様に、自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＮＫである場合には、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＮＫであるときには、接続後の自デバイスのＰｏｗｅｒＲｏｌｅは一意には決まらない。

本発明の各実施の形態によれば、このようなＰｏｗｅｒＲｏｌｅが一意には決まらないという新たな課題に対して解決手段が提供される。

［Ｂ．ハードウェア構成例］
まず、本発明の各実施の形態に従うコントローラのハードウェア構成例について説明する。後述する各実施の形態は、以下に示すようなコントローラを用いて実現できる。説明の便宜上、ＰｏｗｅｒＢａｎｋ１００のハードウェア構成例について説明するが、他のデバイスについても同様のハードウェア構成を採用できる。

図３は、本発明の各実施の形態に従うＰｏｗｅｒＢａｎｋ１００のハードウェア構成例を示す模式図である。図３を参照して、ＰｏｗｅｒＢａｎｋ１００は、主たる構成要素として、コネクタ１０２と、電源管理部（ＰｏｗｅｒＭａｎａｇｅｒ）１０４と、バッテリ１０６と、コントローラ（Ｃｏｎｔｒｏｌｌｅｒ）１１０とを含む。コネクタ１０２は、ＵＳＢＴｙｐｅ－Ｃ型インターフェースのポートを含む。

電源管理部１０４は、コントローラ１１０からの指示に従って、バッテリ１０６の充放電を制御する。具体的には、電源管理部１０４は、外部電源から供給される電力をバッテリ１０６に蓄える第１充電動作、外部デバイスから供給される電力をバッテリ１０６に蓄える第２充電動作、および、バッテリ１０６に蓄えられた電力を外部デバイスへ供給する放電動作を選択的に実行可能になっている。

バッテリ１０６は、充放電可能に構成された蓄電池であり、例えば、リチウムイオン二次電池、リチウムイオンポリマー二次電池、ニッケル・水素充電池などが用いられる。

コントローラ１１０は、ＵＳＢＴｙｐｅ－Ｃ規格に従う、給電側（ＳＲＣ）および受電側（ＳＮＫ）のいずれにもなり得るＤＲＰに対応したデバイスを実現する。コントローラ１１０は、ＤＲＰとして機能するポートを提供し、後述するような制御方法を実行することで、ＵＳＢケーブル２を介した対向デバイスとの通信および受給電動作を管理する。より具体的には、コントローラ１１０は、プロセッサ１１２と、ＣＣ１／ＣＣ２制御・接続検出モジュール（ＰＨＹ＆ＬＧＣ）１１６とを含む。プロセッサ１１２は、ＣＣ１／ＣＣ２制御・接続検出モジュール１１６および電源管理部１０４に接続されている。

プロセッサ１１２は、ＵＳＢＴｙｐｅ－Ｃ規格に従うシーケンスを実行する。プロセッサ１１２は、制御プログラムの一例であるファームウェア１１４を実行することで、以下に示すような制御方法の実行および機能の提供を実現する。すなわち、ＵＳＢＴｙｐｅ－Ｃ規格に従うステート管理に係るシーケンス（制御手順）は、プロセッサ１１２が制御プログラムの一例であるファームウェア１１４を実行することで実現されてもよい。プロセッサ１１２およびファームウェア１１４を用いて実装することで、シーケンスの修正やバージョンアップなどをより容易に実現できる。なお、プロセッサ１１２を用いたソフトウェア実装ではなく、後述するようなハードウェア実装を採用してもよい。

ＣＣ１／ＣＣ２制御・接続検出モジュール１１６は、プロセッサ１１２からの指示に従って、ＵＳＢケーブル２内の通信ライン（第１通信ライン（ＣＣ１）２１および第２通信ライン（ＣＣ２）２２）を制御して、対向デバイスと接続を検出する。なお、第１通信ライン２１および第２通信ライン２２を、まとめて「通信ライン」と総称することもある。ＣＣ１／ＣＣ２制御・接続検出モジュール１１６の詳細な構成については、後述する。

プロセッサ１１２は、バッテリ１０６の充放電を制御するための電源管理部１０４に結合されている。プロセッサ１１２と電源管理部１０４との間には、任意の制御インターフェースを設けてもよい。このような制御インターフェースは、プロセッサ１１２から指示に従って、電源管理部１０４による充放電を制御するための制御指令の送信を仲介する。例えば、プロセッサ１１２と電源管理部１０４との間では、Ｉ２Ｃインターフェースに従って制御信号を遣り取りするようにしてもよい。

バッテリ１０６と外部デバイスとの間の電力の遣り取りは、ＵＳＢケーブル２内の電力ライン（ＶＢＵＳ）２３を介して行われる。なお、ＵＳＢケーブル２は、図示していないシールド線を含んでいてもよい。

図４は、図３に示すコントローラ１１０の回路構成の一例を示す模式図である。図４を参照して、コントローラ１１０のＣＣ１／ＣＣ２制御・接続検出モジュール１１６は、第１通信ライン２１（ＣＣ１）および第２通信ライン２２（ＣＣ２）を制御して、対向デバイスとの接続を検出する。

より具体的には、ＣＣ１／ＣＣ２制御・接続検出モジュール１１６は、第１接続検出ブロック１１６１および第２接続検出ブロック１１６２を有している。

第１接続検出ブロック１１６１は、第１通信ライン２１の電位によって対向デバイスの接続状態を検出し、その検出結果をプロセッサ１１２へ出力する。同様に、第２接続検出ブロック１１６２は、第２通信ライン２２の電位によって対向デバイスの接続状態を検出し、その検出結果をプロセッサ１１２へ出力する。

ＣＣ１／ＣＣ２制御・接続検出モジュール１１６は、対向デバイスの接続を検出するために、通信ライン（第１通信ライン２１および第２通信ライン２２）と電源電位Ｖｓおよびグランド電位ＧＮＤとの間にそれぞれ接続された抵抗を有している。

具体的には、第１通信ライン２１には、電源電位Ｖｓとの間に抵抗値Ｒｐをもつプルアップ抵抗１１６５が接続されており、また、グランド電位ＧＮＤとの間に抵抗値Ｒｄをもつプルダウン抵抗１１６６が接続されている。同様に、第２通信ライン２２には、電源電位Ｖｓとの間に抵抗値Ｒｐをもつプルアップ抵抗１１６７が接続されており、また、グランド電位ＧＮＤとの間に抵抗値Ｒｄをもつプルダウン抵抗１１６８が接続されている。

スイッチ１１６３，１１６４は、通信ライン（第１通信ライン２１および第２通信ライン２２）から電源電位Ｖｓおよびグランド電位ＧＮＤへ繋がる経路を電気的に接続／遮断する。より具体的には、スイッチ１１６３は、プロセッサ１１２からの制御信号に従って、プルアップ抵抗１１６５またはプルダウン抵抗１１６６と第１通信ライン２１とを電気的に接続／遮断する。同様に、スイッチ１１６４は、プロセッサ１１２からの制御信号に従って、プルアップ抵抗１１６７またはプルダウン抵抗１１６８と第２通信ライン２２とを電気的に接続／遮断する。

第１通信ライン２１および第２通信ライン２２に生じる抵抗値Ｒｐ，Ｒｄに応じた電圧をそれぞれ検出することで、ＰｏｗｅｒＢａｎｋ１００と対向デバイスとの接続が確立される。

［Ｃ．実施の形態１］
次に、実施の形態１として、図１（ｃ）に示すような状況において、ＰｏｗｅｒＢａｎｋ１００のＰｏｗｅｒＲｏｌｅを一意にＳＲＣと決めることができるシーケンスを例示する。

より具体的には、実施の形態１に従うデバイスは、初期状態のＰｏｒｔＰｏｗｅｒＲｏｌｅとしてＴｒｙ．ＳＲＣが設定されており、接続後のＰｏｗｅｒＲｏｌｅをＳＲＣに固定しなければならない状況である場合（所定の切替条件ＳＲが成立した場合）になると、ＰｏｒｔＰｏｗｅｒＲｏｌｅを動的にＳＲＣｏｎｌｙに切り替える。このようなＰｏｒｔＰｏｗｅｒＲｏｌｅの動的な切り替えによって、ＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣであるデバイス同士を接続した場合であっても、予め定められたデバイスをＳＲＣに固定できる。

（ｃ１：ＰｏｗｅｒＲｏｌｅの決定例）
図５は、実施の形態１に従うデバイスにおけるＰｏｗｅｒＲｏｌｅの決定例を示す図である。図５を参照して、初期状態において、自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅはＴｒｙ．ＳＲＣであるとする。対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣである場合には、自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅをＴｒｙ．ＳＲＣからＳＲＣｏｎｌｙに切り替える。これによって、自デバイスのＰｏｗｅｒＲｏｌｅはＳＲＣに一意に定まる。

上述したような、ＰｏｒｔＰｏｗｅｒＲｏｌｅをＴｒｙ．ＳＲＣからＳＲＣｏｎｌｙに切り替えるための切替条件ＳＲとして、実施の形態１においては、対向デバイスと接続する際のステート遷移パスを利用する。より具体的には、自デバイスがＰｏｗｅｒＲｏｌｅをＳＮＫとして接続した場合に、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣであると判断されると、自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅをＳＲＣｏｎｌｙに切り替えて再接続する。なお、対向デバイスとの接続が切断されたことを検出すると、ＰｏｒｔＰｏｗｅｒＲｏｌｅを再度Ｔｒｙ．ＳＲＣに戻す。

このように、実施の形態１に従うデバイスは、接続先のデバイスである対向デバイスとのシーケンスに従って、自デバイスのＰｏｗｅｒＲｏｌｅが受電側を意味するＳＮＫに決定されると、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣであるか否かを判断する処理を実行する。そして、実施の形態１に従うデバイスは、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣであれば、自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅをＳＲＣｏｎｌｙに切り替えて、対向デバイスとのシーケンスを継続する処理を実行する。

ＰｏｒｔＰｏｗｅｒＲｏｌｅを動的に切り替えることで、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣであったとしても、接続後の自デバイスのＰｏｗｅｒＲｏｌｅをＳＲＣに固定できる。

（ｃ２：ステートマシン）
図６は、実施の形態１に従うデバイスのステートマシンの一例を示す図である。図６を参照して、実施の形態１に従うデバイスは、Ｔｒｙ．ＳＲＣおよびＳＲＣｏｎｌｙの両方のステートマシンを有することになる。

初期状態において、ＰｏｒｔＰｏｗｅｒＲｏｌｅはＴｒｙ．ＳＲＣであるので、Ｔｒｙ．ＳＲＣのステートマシンで動作を開始する。ステートマシンの遷移によって、切替条件ＳＲが成立すると、ＳＲＣｏｎｌｙのステートマシンでの動作に遷移する。

そして、ＳＲＣｏｎｌｙでの動作において、対向デバイスとの接続が切断されたことを検出すると（ＳｉｎｋＲｅｍｏｖｅｄ）、Ｕｎａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ３１）へ遷移するのではなく、Ｔｒｙ．ＳＲＣのステートマシンに戻る。すなわち、デバイスは、ＰｏｒｔＰｏｗｅｒＲｏｌｅをＴｒｙ．ＳＲＣに戻して、初期状態に復帰する。

なお、図６に示すステートマシンにおいては、ＳＲＣｏｎｌｙからＴｒｙ．ＳＲＣに復帰するにあたって、Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ３３）からＵｎａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１１）へ直接遷移する例を示すが、Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ３３）からＵｎａｔｔａｃｈｅｄＷａｉｔ．ＳＲＣステート（ＳＴ３４）を経てＵｎａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１１）へ遷移するようにしてもよい。

（ｃ３：切替条件ＳＲ）
次に、ＰｏｒｔＰｏｗｅｒＲｏｌｅをＴｒｙ．ＳＲＣからＳＲＣｏｎｌｙに切り替えるための切替条件ＳＲについて説明する。切替条件ＳＲとしては、Ａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）に至るステート遷移パスを用いる。すなわち、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅを判断する処理は、自デバイスのＰｏｗｅｒＲｏｌｅがＳｉｎｋに決定されるまでのステート遷移パスに基づいて、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣであるか否かを判断する処理を含む。

Ａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）は、デバイスのＰｏｗｅｒＲｏｌｅがＳＮＫとなった状態に相当するが、ここで、対向デバイスがＳＲＣｏｎｌｙであれば図５の規定に沿った動作となるが、対向デバイスがＳＲＣｏｎｌｙではなくＴｒｙ．ＳＲＣであれば、図５の規定に沿った動作ではなく、デバイスのＰｏｗｅｒＲｏｌｅをＳＲＣに切り替える必要がある。

すなわち、実施の形態１に従うデバイスのコントローラ１１０は、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＳＲＣｏｎｌｙではない場合に、ＰｏｒｔＰｏｗｅｒＲｏｌｅをＳＲＣｏｎｌｙに切り替える。

より具体的には、自デバイスがＡｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）へ遷移した場合には、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅは、ＳＲＣｏｎｌｙまたはＴｒｙ．ＳＲＣである。そこで、自デバイスがＡｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）へ遷移した後に、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＳＲＣｏｎｌｙおよびＴｒｙ．ＳＲＣのいずれであるかを判断する。

図６に示すように、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＳＲＣｏｎｌｙである場合には、Ｔｒｙ．ＳＲＣステート（ＳＴ１４）、ＴｒｙＷａｉｔ．ＳＮＫステート（ＳＴ１５）およびＡｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）というステート遷移パスをとる。一方、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣである場合には、Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ２３）、ＴｒｙＷａｉｔ．ＳＮＫステート（ＳＴ１５）およびＡｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）というステート遷移パスをとる。

このようなＡｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）に至るステート遷移パスの相違に基づいて、自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅをＳＲＣｏｎｌｙに切り替えるべきか否かを示す切替条件ＳＲを定めることができる。すなわち、Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ２３）、ＴｒｙＷａｉｔ．ＳＮＫステート（ＳＴ１５）およびＡｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）というステート遷移パスが生じた場合に、ＰｏｒｔＰｏｗｅｒＲｏｌｅをＴｒｙ．ＳＲＣからＳＲＣｏｎｌｙへ切り替える。

つまり、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣであるか否かを判断する処理は、自デバイスのＰｏｗｅｒＲｏｌｅがＳｉｎｋに決定されるまでのステート遷移パスが、Ａｔｔａｃｈｅｄ．ＳＲＣステート、ＴｒｙＷａｉｔ．ＳＮＫステートおよびＡｔｔａｃｈｅｄ．ＳＮＫステートの順序であるか否かを判断する処理を含む。

（ｃ４：シーケンス）
次に、実施の形態１に従うデバイスのシーケンスの一例について説明する。

図７は、実施の形態１に従うデバイスがＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣである対向デバイスと接続された場合のシーケンス（ＰｏｒｔＰｏｗｅｒＲｏｌｅの切り替えなし）の一例を示す図である。図８は、実施の形態１に従うデバイスがＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣである対向デバイスと接続された場合のシーケンス（ＰｏｒｔＰｏｗｅｒＲｏｌｅの切り替えあり）の一例を示す図である。

図９は、実施の形態１に従うデバイスがＰｏｒｔＰｏｗｅｒＲｏｌｅがＳＲＣｏｎｌｙである対向デバイスと接続された場合のシーケンスの一例を示す図である。

図１０は、図７～図９に示す各シーケンスに対応するステートマシンを示す図である。
図７～図９に示すシーケンスにおいて、自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅはＴｒｙ．ＳＲＣである。また、図７～図９に示す「ＣＣ制御」は、第１通信ライン２１（ＣＣ１）および第２通信ライン２２（ＣＣ２）（図３および図４参照）に現れる抵抗値を示す。

まず、図７に示すシーケンスの例は、ＰｏｒｔＰｏｗｅｒＲｏｌｅを動的にＳＲＣｏｎｌｙに切り替えることなく、ＰｏｗｅｒＲｏｌｅがＳＲＣに設定される例を示す。図７を参照して、初期状態において、自デバイスは、Ｕｎａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１１）であり、対向デバイスは、Ｕｎａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ２１）であるとする。なお、自デバイスおよび対向デバイスとも、未接続状態においては、Ｕｎａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１１）とＵｎａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ２１）との間を交互に遷移するトグル動作を行う。

自デバイスは、シーケンスに従って、ＡｔｔａｃｈＷａｉｔ．ＳＮＫステート（ＳＴ１２）へ遷移する（シーケンスＳＱ１１）。一方、対向デバイスは、シーケンスに従って、ＡｔｔａｃｈＷａｉｔ．ＳＲＣステート（ＳＴ２２）へ遷移し（シーケンスＳＱ２１）、さらに、対向デバイスは、Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ２３）へ遷移する（シーケンスＳＱ２２）。Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ２３）への遷移に伴って、対向デバイスは、電力ライン（ＶＢＵＳ）２３に所定電圧を印加する（ＶＢＵＳＯＮ）。

対向デバイスによるＶＢＵＳＯＮを検出することで、自デバイスは、Ｔｒｙ．ＳＲＣステート（ＳＴ１４）へ遷移し（シーケンスＳＱ１２）、さらに、Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ２３）へ遷移する（シーケンスＳＱ１３）。そして、自デバイスは、電力ライン（ＶＢＵＳ）２３に所定電圧を印加する（ＶＢＵＳＯＮ）。

一方、対向デバイスは、ＶＢＵＳＯＮに対してＳＮＫを検出できないので、ＴｒｙＷａｉｔ．ＳＮＫステート（ＳＴ１５）へ遷移し（シーケンスＳＱ２３）、ここで、自デバイスによるＶＢＵＳＯＮを検出することで、対向デバイスは、Ａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）へ遷移する（シーケンスＳＱ２４）。

以上のシーケンスによって、自デバイスと対向デバイスとの接続後においては、自デバイスのＰｏｗｅｒＲｏｌｅはＳＲＣとなり、対向デバイスのＰｏｗｅｒＲｏｌｅはＳＮＫとなる。

次に、図８に示すシーケンスの例は、ＰｏｒｔＰｏｗｅｒＲｏｌｅを動的にＳＲＣｏｎｌｙに切り替えることで、ＰｏｗｅｒＲｏｌｅがＳＲＣに設定される例を示す。図８を参照して、初期状態において、自デバイスは、Ｕｎａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ２１）であり、対向デバイスは、Ｕｎａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１１）であるとする。

自デバイスは、シーケンスに従って、ＡｔｔａｃｈＷａｉｔ．ＳＲＣステート（ＳＴ２２）へ遷移する（シーケンスＳＱ２１）。さらに、自デバイスは、Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ２３）へ遷移する（シーケンスＳＱ２２）。Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ２３）への遷移に伴って、自デバイスは、電力ライン（ＶＢＵＳ）２３に所定電圧を印加する（ＶＢＵＳＯＮ）。自デバイスは、ＶＢＵＳＯＮに対してＳＮＫを検出できないので、ＴｒｙＷａｉｔ．ＳＮＫステート（ＳＴ１５）へ遷移し（シーケンスＳＱ２３）、ここで、対向デバイスによるＶＢＵＳＯＮを検出することで、自デバイスは、Ａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）へ遷移する（シーケンスＳＱ２４）。

一方、対向デバイスは、シーケンスに従って、ＡｔｔａｃｈＷａｉｔ．ＳＮＫステート（ＳＴ１２）へ遷移する（シーケンスＳＱ１１）。ここで、自デバイスによるＶＢＵＳＯＮを検出することで、対向デバイスは、Ｔｒｙ．ＳＲＣステート（ＳＴ１４）へ遷移し（シーケンスＳＱ１２）、さらに、Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ２３）へ遷移する（シーケンスＳＱ１３）。そして、対向デバイスは、電力ライン（ＶＢＵＳ）２３に所定電圧を印加する（ＶＢＵＳＯＮ）。

自デバイスは、Ａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）において、切替条件ＳＲが成立したか否かを判断する。上述したように、切替条件ＳＲは、Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ２３）、ＴｒｙＷａｉｔ．ＳＮＫステート（ＳＴ１５）およびＡｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）というステート遷移パスが生じたか否かである。図８に示す例では、切替条件ＳＲが成立したと判断されて、自デバイスは、ＰｏｒｔＰｏｗｅｒＲｏｌｅをＴｒｙ．ＳＲＣからＳＲＣｏｎｌｙへ切り替える。そして、自デバイスは、Ｕｎａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ３１）へ遷移する（シーケンスＳＱ２５）。ここで、対向デバイスは、ＶＢＵＳＯＮに対してＳＮＫを検出できなくなるので、ＴｒｙＷａｉｔ．ＳＮＫステート（ＳＴ１５）へ遷移する（シーケンスＳＱ１４）。

また、自デバイスは、シーケンスに従って、ＡｔｔａｃｈＷａｉｔ．ＳＲＣステート（ＳＴ３２）へ遷移し（シーケンスＳＱ２６）、さらに、Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ３３）へ遷移する（シーケンスＳＱ２７）。

Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ３３）への遷移に伴って、自デバイスは、電力ライン（ＶＢＵＳ）２３に所定電圧を印加する（ＶＢＵＳＯＮ）。すると、対向デバイスは、自デバイスによるＶＢＵＳＯＮを検出することで、ＴｒｙＷａｉｔ．ＳＮＫステート（ＳＴ１５）からＡｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）へ遷移する（シーケンスＳＱ１５）。

次に、図９に示すシーケンスの例は、実施の形態１に従うデバイスがＰｏｒｔＰｏｗｅｒＲｏｌｅがＳＲＣｏｎｌｙのデバイスと接続された場合であっても、ＵＳＢＴｙｐｅ－Ｃ規格に沿ったシーケンスが実行される例を示す。

図９を参照して、初期状態において、自デバイスは、Ｕｎａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１１）であり、対向デバイスは、Ｕｎａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ３１）（ＳＲＣｏｎｌｙステートマシン）であるとする。

自デバイスは、シーケンスに従って、ＡｔｔａｃｈＷａｉｔ．ＳＮＫステート（ＳＴ１２）へ遷移する（シーケンスＳＱ１１）。そして、対向デバイスによるＶＢＵＳＯＮを検出することで、自デバイスは、Ｔｒｙ．ＳＲＣステート（ＳＴ１４）へ遷移し（シーケンスＳＱ１２）、さらに、自デバイスは、ＴｒｙＷａｉｔ．ＳＮＫステート（ＳＴ１５）へ遷移する（シーケンスＳＱ１６）。ここで、対向デバイスによるＶＢＵＳＯＮを検出することで、自デバイスは、Ａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）へ遷移する（シーケンスＳＱ１５）。

自デバイスは、Ａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）において、切替条件ＳＲが成立したか否かを判断する。上述したように、切替条件ＳＲは、Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ２３）、ＴｒｙＷａｉｔ．ＳＮＫステート（ＳＴ１５）およびＡｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）というステート遷移パスが生じたか否かである。図９に示す例では、切替条件ＳＲが成立していないと判断されて、Ａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）が維持される。

一方、対向デバイスは、シーケンスに従って、ＡｔｔａｃｈＷａｉｔ．ＳＲＣステート（ＳＴ３２）へ遷移し（シーケンスＳＱ２６）、さらに、Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ３３）へ遷移する（シーケンスＳＱ２７）。

Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ３３）への遷移に伴って、対向デバイスは、電力ライン（ＶＢＵＳ）２３に所定電圧を印加する（ＶＢＵＳＯＮ）。この時点において、対向デバイスは、ＶＢＵＳＯＮに対してＳＮＫを検出できないので、Ｕｎａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ３１）へ戻る（シーケンスＳＱ２９）。

そして、対向デバイスは、先に実行したシーケンスと同様に、ＡｔｔａｃｈＷａｉｔ．ＳＲＣステート（ＳＴ３２）へ遷移し（シーケンスＳＱ２６）、さらに、Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ３３）へ遷移する（シーケンスＳＱ２７）。Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ３３）への遷移に伴って、対向デバイスは、電力ライン（ＶＢＵＳ）２３に所定電圧を印加する（ＶＢＵＳＯＮ）。この時点において、自デバイスのＰｏｗｅｒＲｏｌｅはＳＮＫに決定されているので、対向デバイスが接続先のＳＮＫを検出することで、最終的に、自デバイスと対向デバイスとの接続後においては、自デバイスのＰｏｗｅｒＲｏｌｅはＳＮＫとなり、対向デバイスのＰｏｗｅｒＲｏｌｅはＳＲＣとなる。

（ｃ５：小括）
実施の形態１に従うデバイスによれば、自デバイスおよび接続先の対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがいずれもＤＲＰの一種であるＴｒｙ．ＳＲＣであっても、自デバイスのＰｏｗｅｒＲｏｌｅをＳＲＣに確実に決定できる。これによって、ＰｏｗｅｒＲｏｌｅに関連付けて実行される各種処理についても確実な実行を保証できる。

［Ｄ．実施の形態２］
上述の実施の形態１においては、実施の形態１に従うデバイスとＵＳＢＴｙｐｅ－Ｃ規格に従うデバイスとを接続した場合の処理について説明した。実施の形態２においては、実施の形態１に従うデバイス同士を接続した場合の改良について説明する。

図１１は、実施の形態１に従うデバイス同士が接続された場合のシーケンスの一例を示す図である。図１１には、実施の形態１に従うデバイス同士を接続して所定のシーケンスが実行された後の状態を示す。

図１１を参照して、例えば、対向デバイスは、Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ２３）であるとする。一方、自デバイスは、シーケンスに従って、Ａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）遷移したとする。すると、自デバイスは、Ａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）において、切替条件ＳＲが成立したか否かを判断する。

図１１に示す例では、切替条件ＳＲが成立したと判断されて、自デバイスは、ＰｏｒｔＰｏｗｅｒＲｏｌｅをＴｒｙ．ＳＲＣからＳＲＣｏｎｌｙへ切り替える。そして、自デバイスは、Ｕｎａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ３１）へ遷移する。そして、自デバイスは、シーケンスに従って、ＡｔｔａｃｈＷａｉｔ．ＳＲＣステート（ＳＴ３２）へ遷移し、さらに、Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ３３）へ遷移する。

Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ３３）への遷移に伴って、自デバイスは、電力ライン（ＶＢＵＳ）２３に所定電圧を印加する（ＶＢＵＳＯＮ）。

一方、対向デバイスは、ＶＢＵＳＯＮに対してＳＮＫを検出できないので、ＴｒｙＷａｉｔ．ＳＮＫステート（ＳＴ１５）へ遷移し、さらに、Ａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）へ遷移する。すると、対向デバイスは、Ａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）において、切替条件ＳＲが成立したか否かを判断する。

図１１に示す例では、切替条件ＳＲが成立したと判断されて、対向デバイスは、ＰｏｒｔＰｏｗｅｒＲｏｌｅをＴｒｙ．ＳＲＣからＳＲＣｏｎｌｙへ切り替える。そして、対向デバイスは、Ｕｎａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ３１）へ遷移する。すると、自デバイスは、ＶＢＵＳＯＮに対してＳＮＫを検出できなくなるので、対向デバイスとの接続が切断されたと検出し（ＳｉｎｋＲｅｍｏｖｅｄ）、ＰｏｒｔＰｏｗｅｒＲｏｌｅをＳＲＣｏｎｌｙからＴｒｙ．ＳＲＣへ切り替え、Ｕｎａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ２１）へ遷移する。

このように、実施の形態１に従うデバイス同士を接続した場合には、両デバイスにおいて、切替条件ＳＲが成立したと判断されるので、ＰｏｒｔＰｏｗｅｒＲｏｌｅの切り替えが両デバイスでそれぞれ生じることになり、特定のステートに落ち着くことがない。すなわち、実施の形態１に従うデバイス同士を接続した場合には、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣであると互いのデバイスがそれぞれ判断し、自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅをＳＲＣｏｎｌｙに切り替える。すると、デバイス同士がいずれもＳＲＣとなり、各デバイスは対向デバイスとの接続が切断されたと検出し（ＳｉｎｋＲｅｍｏｖｅｄ）、ＰｏｒｔＰｏｗｅｒＲｏｌｅをＴｒｙ．ＳＲＣに戻して、再接続のシーケンスを実行するという処理のループに陥る可能性もある。

実施の形態２においては、上述したような課題が生じないデバイスについて説明する。
図１２は、実施の形態２に従うデバイスのステートマシンの一例を示す図である。図１２を参照して、実施の形態２に従うデバイスのステートマシンは、図１０に示す実施の形態１に従うデバイスのステートマシンと比較して、新たに、ＣＣ．Ｏｐｅｎステート（ＳＴ３５）が追加されている。

ＣＣ．Ｏｐｅｎステート（ＳＴ３５）は、第１通信ライン（ＣＣ１）２１および第２通信ライン（ＣＣ２）２２をオープンにするステートを意味する。すなわち、デバイスがＣＣ．Ｏｐｅｎステート（ＳＴ３５）へ遷移すると、第１通信ライン（ＣＣ１）２１および第２通信ライン（ＣＣ２）２２に接続され得る抵抗値Ｒｐおよび抵抗値Ｒｄの両方を電気的に切断する。これによって、対向デバイスからは、対象のデバイスとの接続が切断されたように見える。

このように、自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅをＳＲＣｏｎｌｙに切り替える際に、ＣＣ．Ｏｐｅｎステート（ＳＴ３５）を経由することで、対向デバイスは、自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＳＲＣｏｎｌｙであると判断する。すなわち、ＰｏｒｔＰｏｗｅｒＲｏｌｅをＴｒｙ．ＳＲＣからＳＲＣｏｎｌｙへ切り替える処理は、対向デバイスと電気的に接続された通信ライン（第１通信ライン（ＣＣ１）２１および第２通信ライン（ＣＣ２）２２）をオープンする処理を含む。

これによって、互いのデバイスが対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅをＴｒｙ．ＳＲＣであるとそれぞれ判断することを回避できる。すなわち、実施の形態１に従うデバイス同士がＰｏｒｔＰｏｗｅｒＲｏｌｅの切り替えを繰り返すことを防止できる。

図１３は、実施の形態２に従うデバイスと実施の形態１に従うデバイスとが接続された場合のシーケンスの一例を示す図である。

図１２および図１３を参照して、例えば、実施の形態１に従うデバイスである対向デバイスは、Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ２３）であるとする。一方、実施の形態２に従うデバイスである自デバイスは、シーケンスに従って、Ａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）遷移したとする。すると、自デバイスは、Ａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）において、切替条件ＳＲが成立したか否かを判断する。

図１３に示す例では、切替条件ＳＲが成立したと判断されて、自デバイスは、ＰｏｒｔＰｏｗｅｒＲｏｌｅをＴｒｙ．ＳＲＣからＳＲＣｏｎｌｙへ切り替える。そして、自デバイスは、ＣＣ．Ｏｐｅｎステート（ＳＴ３５）へ遷移する（シーケンスＳＱ２５Ａ）。その後、エラー復帰時間ｔＥｒｒｏｒＲｅｃｏｖｅｒｙの経過後に、自デバイスは、Ｕｎａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ３１）へ遷移する（シーケンスＳＱ２５Ｂ）。

そして、自デバイスは、シーケンスに従って、ＡｔｔａｃｈＷａｉｔ．ＳＲＣステート（ＳＴ３２）へ遷移し、さらに、Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ３３）へ遷移する。

一方、対向デバイスは、ＶＢＵＳＯＮに対してＳＮＫを検出できないので、ＴｒｙＷａｉｔ．ＳＮＫステート（ＳＴ１５）へ遷移する（シーケンスＳＱ２３）。ＴｒｙＷａｉｔ．ＳＮＫステート（ＳＴ１５）において、対向デバイスは、ＳＲＣを検出できない（ＳｏｕｒｃｅｎｏｔＤｅｔｅｃｔｅｄ）ので、Ｕｎａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１１）へ遷移する（シーケンスＳＱ１７）。

そして、対向デバイスは、シーケンスに従って、Ｕｎａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１１）からＡｔｔａｃｈＷａｉｔ．ＳＮＫステート（ＳＴ１２）へ遷移する（シーケンスＳＱ１１）。続いて、自デバイスによるＶＢＵＳＯＮを検出することで、対向デバイスは、Ｔｒｙ．ＳＲＣステート（ＳＴ１４）へ遷移し（シーケンスＳＱ１２）、さらに、ＴｒｙＷａｉｔ．ＳＮＫステート（ＳＴ１５）およびＡｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）へ順次遷移する（シーケンスＳＱ１６およびＳＱ１５）。

対向デバイスは、Ａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）において、切替条件ＳＲが成立したか否かを判断する。上述したように、切替条件ＳＲは、Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ２３）、ＴｒｙＷａｉｔ．ＳＮＫステート（ＳＴ１５）およびＡｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）というステート遷移パスが生じたか否かである。図１３に示す例では、切替条件ＳＲが成立していないと判断されて、Ａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）が維持される。

最終的に、自デバイスと対向デバイスとの接続後においては、自デバイスのＰｏｗｅｒＲｏｌｅはＳＲＣとなり、対向デバイスのＰｏｗｅｒＲｏｌｅはＳＮＫとなる。

上述した処理および構成を除いた点は、いずれも上述の実施の形態１と同様であるので、詳細な説明は繰り返さない。

実施の形態２によれば、実施の形態１に従うデバイス同士が接続された場合であっても、ＰｏｗｅｒＲｏｌｅを決定できず処理が繰り返されるといった事態を回避できる。

［Ｅ．実施の形態３］
上述の実施の形態１および２においては、切替条件ＳＲとして、Ａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）に至るステート遷移パスが予め定められたステート遷移パスと一致するか否かという条件を用いた。

ところで、上述の非特許文献２などに規定されるＵＳＢＴｙｐｅ－Ｃ規格に適合するか否かのテスト（Ｔｙｐｅ－ＣＣｏｍｐｌｉａｎｃｅＴｅｓｔ）においては、テスト対象機器（自デバイスのポート）がＵＳＢＴｙｐｅ－Ｃ規格で定義されたステートに正しく遷移するか否かが判断される。

実施の形態１および２に従うデバイスは、Ａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）において切替条件ＳＲが成立したと判断されると、ＰｏｒｔＰｏｗｅｒＲｏｌｅを動的にＳＲＣｏｎｌｙに切り替えるため、Ａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）に留まらず、別のステートへ遷移することになる。その結果、「ＴｅｓｔＦａｉｌ」と判定される可能性がある。

上述の実施の形態１および２に従うデバイスがＴｙｐｅ－ＣＣｏｍｐｌｉａｎｃｅＴｅｓｔにおいて「ＴｅｓｔＰａｓｓ」との判定結果を得るために、切替条件ＳＲに「予め定められた時間だけ待機する」という条件を追加してもよい。

図１４は、実施の形態３に従うデバイスにおいて採用される切替条件ＳＲを説明するための図である。図１４を参照して、切替条件ＳＲとしては、まず、予め定められたステート遷移パスでＡｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）へ到達したか否かが判断される（ステップＳ２）。ここで、予め定められたステート遷移パスは、Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ２３）、ＴｒｙＷａｉｔ．ＳＮＫステート（ＳＴ１５）およびＡｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）の順でのステート遷移である。

予め定められたステート遷移パスでＡｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）へ到達していなければ（ステップＳ２においてＮＯ）、切替条件ＳＲは不成立と決定される。

これに対して、予め定められたステート遷移パスでＡｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）へ到達していれば（ステップＳ２においてＹＥＳ）、予め定められた時間だけ待機（ステップＳ４）した後に、切替条件ＳＲは成立と決定される。

このように、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣであるか否かを判断する処理は、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣであると判断された後、予め定められた時間だけ待機する処理を含む。

実施の形態３に従うデバイスによれば、図１４に示すような切替条件ＳＲを採用することで、実施の形態１および２に示すような機能を実装したデバイスであっても、Ｔｙｐｅ－ＣＣｏｍｐｌｉａｎｃｅＴｅｓｔにおいて「ＴｅｓｔＰａｓｓ」との判定結果を得ることができる。

なお、非特許文献３などに規定されるＵＳＢＰｏｗｅｒＤｅｌｉｖｅｒｙ（以下、単に「ＰＤ」とも称す。）を対象のデバイスがサポートするか否かによらず、上述の実施の形態３に従う切替条件ＳＲを適用できる。

［Ｆ．実施の形態４］
非特許文献３などに規定されるＵＳＢＰｏｗｅｒＤｅｌｉｖｅｒｙ（ＰＤ）においては、デバイス間のＰｏｗｅｒＲｏｌｅを切り替えるために、ＰｏｗｅｒＲｏｌｅＳｗａｐ命令が用意されている。接続される両デバイスがいずれもＰＤをサポートしている場合には、通常動作として、ＰｏｗｅｒＲｏｌｅＳｗａｐ命令を用いたＰｏｗｅｒＲｏｌｅの決定あるいは切り替え処理が実行される。

すなわち、ＰＤをサポートしているデバイス間では、上述の実施の形態１および２に従うＵＳＢＴｙｐｅ－Ｃ規格のレベルで実行されるＰｏｗｅｒＲｏｌｅの決定処理ではなく、ＰＤのレベルで実行されるＰｏｗｅｒＲｏｌｅＳｗａｐ命令を用いたＰｏｗｅｒＲｏｌｅの決定処理が優先されることが好ましい。

このようなＰＤをサポートするデバイス間でのＰｏｗｅｒＲｏｌｅＳｗａｐ命令の遣り取りを阻害しないようにするために、Ａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）において判断される切替条件ＳＲに「対向デバイスがＰＤをサポートしていない」という条件を追加してもよい。

図１５は、実施の形態４に従うデバイスにおいて採用される切替条件ＳＲを説明するための図である。図１５を参照して、切替条件ＳＲとしては、まず、予め定められたステート遷移パスでＡｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）へ到達したか否かが判断される（ステップＳ２）。ここで、予め定められたステート遷移パスは、Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ２３）、ＴｒｙＷａｉｔ．ＳＮＫステート（ＳＴ１５）およびＡｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）の順でのステート遷移である。

これに対して、予め定められたステート遷移パスでＡｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ１３）へ到達していれば（ステップＳ２においてＹＥＳ）、自デバイスがＰＤをサポートしているか否かが判断される（ステップＳ６）。自デバイスがＰＤをサポートしていなければ（ステップＳ６においてＮＯ）、切替条件ＳＲは成立と決定される。すなわち、自デバイスはＰｏｗｅｒＲｏｌｅＳｗａｐ命令の遣り取りができないので、実施の形態１および２に示すようなＰｏｒｔＰｏｗｅｒＲｏｌｅの動的な切り替えを実行しても問題は生じないと判断できる。

自デバイスがＰＤをサポートしていれば（ステップＳ６においてＹＥＳ）、自デバイスは、対向デバイスに対してＰＤメッセージを送信する（ステップＳ８）。送信されるＰＤメッセージは、ＰＤ規格において規定されるＰｏｌｉｃｙＥｎｇｉｎｅのステートの問い合わせメッセージを用いることができる。そして、自デバイスは、送信したＰＤメッセージに対する応答を対向デバイスから受信したか否かを判断する（ステップＳ１０）。

ＰＤメッセージに対する応答を受信しなければ（ステップＳ１０においてＮＯ）、切替条件ＳＲは成立と決定される。すなわち、対向デバイスがＰＤをサポートしていないと判断できるので、実施の形態１および２に示すようなＰｏｒｔＰｏｗｅｒＲｏｌｅの動的な切り替えを実行しても問題は生じないと判断できる。

これに対して、ＰＤメッセージに対する応答を受信すれば（ステップＳ１０においてＹＥＳ）、切替条件ＳＲは不成立と決定される。すなわち、対向デバイスもＰＤをサポートしていると判断できるので、実施の形態１および２に示すようなＰｏｒｔＰｏｗｅｒＲｏｌｅの動的な切り替えは実行されない。

このように、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣであるか否かを判断する処理は、対向デバイスがＵＳＢＰｏｗｅｒＤｅｌｉｖｅｒｙをサポートしているか否かを判断する処理を含む。そして、実施の形態４に従うデバイスのコントローラ１１０は、対向デバイスがＵＳＢＰｏｗｅｒＤｅｌｉｖｅｒｙをサポートしていない場合に、自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅをＳＲＣｏｎｌｙに切り替える処理を実行する。

実施の形態４に従うデバイスによれば、図１５に示すような切替条件ＳＲを採用することで、実施の形態１および２に示すような機能を実装したデバイスがＰＤをサポートする場合であっても、Ｔｙｐｅ－ＣＣｏｍｐｌｉａｎｃｅＴｅｓｔにおいて「ＴｅｓｔＰａｓｓ」との判定結果を得ることができる。

［Ｇ．実施の形態４の変形例］
上述の実施の形態４においては、ＰＤにおいて規定されているＰｏｗｅｒＲｏｌｅＳｗａｐ命令を用いるＰｏｒｔＰｏｗｅｒＲｏｌｅの動的な切り替えについて説明した。しかしながら、対向デバイスのＰｏｗｅｒＲｏｌｅＳｗａｐポリシーに依存して、ＰｏｗｅｒＲｏｌｅＳｗａｐ命令を用いることができない場合がある。

すなわち、ＰｏｗｅｒＲｏｌｅの動的な切り替えを指示する、ＰｏｗｅｒＲｏｌｅＳｗａｐＲｅｑｕｅｓｔに対して、対向デバイスがＡｃｃｅｐｔを応答する場合には、ＰｏｗｅｒＲｏｌｅを切り替えることができるので、動作に問題は生じない。これに対して、ＰｏｗｅｒＲｏｌｅＳｗａｐＲｅｑｕｅｓｔに対して、対向デバイスがＲｅｊｅｃｔを応答する場合には、自デバイスは、ＰｏｗｅｒＲｏｌｅＳｗａｐ命令によるＰｏｗｅｒＲｏｌｅの切り替えができない。

なお、ＰＤにおいては、ＰｏｗｅｒＲｏｌｅＳｗａｐＲｅｑｕｅｓｔ（ＰＲ＿ＳｗａｐＭｅｓｓａｇｅ）を受信したデバイスは、当該デバイスのポリシーに従って、ＡｃｃｅｐｔまたはＲｅｊｅｃｔを応答する。例えば、現在のＰｏｗｅｒＲｏｌｅが所望するＲｏｌｅではない場合にＰＲ＿ＳｗａｐＭｅｓｓａｇｅを受信すると、当該デバイスはＡｃｃｅｐｔを応答する。これに対して、現在のＰｏｗｅｒＲｏｌｅが所望するＲｏｌｅである場合にＰＲ＿ＳｗａｐＭｅｓｓａｇｅを受信すると、当該デバイスはＲｅｊｅｃｔを応答する。

このような対向デバイスのＰｏｗｅｒＲｏｌｅＳｗａｐポリシーに依存せず、予定されたＰｏｗｅｒＲｏｌｅを一意に決定できるように、対向デバイスからの応答に基づいて、切替条件ＳＲの成立または不成立を判断するようにしてもよい。より具体的には、ＰｏｗｅｒＲｏｌｅＳｗａｐＲｅｑｕｅｓｔに対して、対向デバイスからＲｅｊｅｃｔが応答された場合には、切替条件ＳＲが成立したと判断し、実施の形態１および２に従って、ＵＳＢＴｙｐｅ－Ｃ規格レベルで、ＰｏｒｔＰｏｗｅｒＲｏｌｅをＳＲＣｏｎｌｙに切り替えるようにしてもよい。

図１６は、実施の形態４の変形例に従うデバイスにおいて採用される切替条件ＳＲを説明するための図である。図１６に示す切替条件ＳＲは、図１５に示す切替条件ＳＲに対してさらに処理を追加したものである。そのため、図１５に示す切替条件ＳＲと同一のステップについては詳細な説明は繰り返さない。

図１６を参照して、ＰＤメッセージに対する応答を受信すれば（ステップＳ１０においてＹＥＳ）、自デバイスは、対向デバイスに対して、ＰｏｗｅｒＲｏｌｅをＳＮＫに切り替えることを指示するＰｏｗｅｒＲｏｌｅＳｗａｐＲｅｑｕｅｓｔを送信する（ステップＳ１２）。

そして、自デバイスは、送信したＰｏｗｅｒＲｏｌｅＳｗａｐＲｅｑｕｅｓｔに対して、対向デバイスがＲｅｊｅｃｔを応答したか否かを判断する（ステップＳ１４）。対向デバイスがＡｃｃｅｐｔを応答すれば（ステップＳ１４においてＮＯ）、切替条件ＳＲは不成立と決定される。

これに対して、対向デバイスがＲｅｊｅｃｔを応答すれば（ステップＳ１４においてＹＥＳ）、切替条件ＳＲは成立と決定される。すなわち、ＰｏｗｅｒＲｏｌｅＳｗａｐ命令ではなく、ＵＳＢＴｙｐｅ－Ｃ規格レベルでのＰｏｒｔＰｏｗｅｒＲｏｌｅの切り替え処理が実行されることになる。

このように、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣであるか否かを判断する処理は、対向デバイスに対してＰｏｗｅｒＲｏｌｅＳｗａｐＲｅｑｕｅｓｔを送信する処理と、対向デバイスからＲｅｊｅｃｔを受信するか否かを判断する処理とを含む。そして、実施の形態４の変形例に従うデバイスのコントローラ１１０は、対向デバイスからＲｅｊｅｃｔを受信すると、自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅをＳＲＣｏｎｌｙに切り替える処理を実行する。

上述したように、接続される両デバイスがいずれもＰＤをサポートしている場合には、ＰｏｗｅｒＲｏｌｅＳｗａｐ命令を用いてＰｏｗｅｒＲｏｌｅを切り替えることができる。しかしながら、対向デバイスのポリシーに依存して、ＰｏｗｅｒＲｏｌｅＳｗａｐＲｅｑｕｅｓｔに対して、対向デバイスがＲｅｊｅｃｔを応答することがあり、このような場合には所望のＰｏｗｅｒＲｏｌｅを設定できないことになる。実施の形態４の変形例においては、このような場合でも、ＵＳＢＴｙｐｅ－Ｃ規格レベルで、ＰｏｒｔＰｏｗｅｒＲｏｌｅを切り替えることで、強制的に所望のＰｏｗｅｒＲｏｌｅに設定できる。

上述した処理および構成を除いた点は、いずれも上述の実施の形態１および４と同様であるので、詳細な説明は繰り返さない。

［Ｈ．実施の形態５］
次に、実施の形態５として、ＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＮＫであるデバイスのＰｏｗｅｒＲｏｌｅを一意にＳＮＫと決めることができるシーケンスを例示する。

より具体的には、実施の形態５に従うデバイスは、初期状態のＰｏｒｔＰｏｗｅｒＲｏｌｅとしてＴｒｙ．ＳＮＫが設定されており、接続後のＰｏｗｅｒＲｏｌｅをＳＮＫに固定しなければならない状況である場合（所定の切替条件ＳＮが成立した場合）になると、ＰｏｒｔＰｏｗｅｒＲｏｌｅを動的にＳＮＫｏｎｌｙに切り替える。このようなＰｏｒｔＰｏｗｅｒＲｏｌｅの動的な切り替えによって、ＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＮＫであるデバイス同士を接続した場合であっても、予め定められたデバイスをＳＮＫに固定できる。

（ｈ１：ＰｏｗｅｒＲｏｌｅの決定例）
図１７は、実施の形態５に従うデバイスにおけるＰｏｗｅｒＲｏｌｅの決定例を示す図である。図１７を参照して、初期状態において、自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅはＴｒｙ．ＳＮＫであるとする。対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＮＫである場合には、自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅをＴｒｙ．ＳＮＫからＳＮＫｏｎｌｙに切り替える。これによって、自デバイスのＰｏｗｅｒＲｏｌｅはＳＮＫに一意に定まる。

上述したような、ＰｏｒｔＰｏｗｅｒＲｏｌｅをＴｒｙ．ＳＮＫからＳＮＫｏｎｌｙに切り替えるための切替条件ＳＮとして、実施の形態５においては、対向デバイスと接続する際のステート遷移パスを利用する。より具体的には、自デバイスがＰｏｗｅｒＲｏｌｅをＳＲＣとして接続した場合に、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＮＫであると判断されると、自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅをＳＮＫｏｎｌｙに切り替えて再接続する。なお、対向デバイスとの接続が切断されたことを検出すると、ＰｏｒｔＰｏｗｅｒＲｏｌｅを再度Ｔｒｙ．ＳＮＫに戻す。

このように、実施の形態５に従うデバイスは、接続先のデバイスである対向デバイスとのシーケンスに従って、自デバイスのＰｏｗｅｒＲｏｌｅが給電側を意味するＳＲＣに決定されると、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＮＫであるか否かを判断する処理を実行する。そして、実施の形態５に従うデバイスは、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＮＫであれば、自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅをＳＮＫｏｎｌｙに切り替えて、対向デバイスとのシーケンスを継続する処理を実行する。

このようなＰｏｒｔＰｏｗｅｒＲｏｌｅを動的に切り替えることで、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＮＫであったとしても、接続後の自デバイスのＰｏｗｅｒＲｏｌｅをＳＮＫに固定できる。

（ｈ２：ステートマシン）
図１８は、実施の形態５に従うデバイスのステートマシンの一例を示す図である。図１８を参照して、実施の形態５に従うデバイスは、Ｔｒｙ．ＳＮＫおよびＳＮＫｏｎｌｙの両方のステートマシンを有することになる。

初期状態において、ＰｏｒｔＰｏｗｅｒＲｏｌｅはＴｒｙ．ＳＲＣであるので、Ｔｒｙ．ＳＲＣのステートマシンで動作を開始する。ステートマシンの遷移によって、切替条件ＳＮが成立すると、ＳＮＫｏｎｌｙのステートマシンでの動作に遷移する。

そして、ＳＮＫｏｎｌｙでの動作において、対向デバイスとの接続が切断されたことを検出すると（ＶＢＵＳＲｅｍｏｖｅｄ）、Ｕｎａｔｔａｃｈｅｄ．ＳＮＫステート（ＳＴ５１）へ遷移するのではなく、Ｔｒｙ．ＳＮＫのステートマシンに戻る。すなわち、デバイスは、ＰｏｒｔＰｏｗｅｒＲｏｌｅをＴｒｙ．ＳＮＫに戻して、初期状態に復帰する。

（ｈ３：切替条件ＳＮ）
次に、ＰｏｒｔＰｏｗｅｒＲｏｌｅをＴｒｙ．ＳＮＫからＳＮＫｏｎｌｙに切り替えるための切替条件ＳＮについて説明する。切替条件ＳＮとしては、Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ４８）に至るステート遷移パスを用いる。

Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ４８）は、デバイスのＰｏｗｅｒＲｏｌｅがＳＲＣとなった状態に相当するが、ここで、対向デバイスがＳＮＫｏｎｌｙであれば図１７の規定に沿った動作となるが、対向デバイスがＳＮＫｏｎｌｙではなくＴｒｙ．ＳＮＫであれば、図１７の規定に沿った動作ではなく、デバイスのＰｏｗｅｒＲｏｌｅをＳＮＫに切り替える必要がある。

すなわち、自デバイスがＡｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ４８）へ遷移した場合には、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅは、ＳＮＫｏｎｌｙまたはＴｒｙ．ＳＮＫである。そこで、自デバイスがＡｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ４８）へ遷移した後に、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＳＮＫｏｎｌｙおよびＴｒｙ．ＳＮＫのいずれであるかを判断する。

図１７に示すステートマシンにおいては、自デバイスがＡｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ４８）へのステート遷移パスは、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＳＮＫｏｎｌｙおよびＴｒｙ．ＳＮＫのいずれであっても同一である。より具体的には、Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ４８）へのステート遷移パスは、いずれも、ＡｔｔａｃｈＷａｉｔ．ＳＲＣステート（ＳＴ４７）、Ｔｒｙ．ＳＮＫステート（ＳＴ４４）、ＴｒｙＷａｉｔＳＲＣステート（ＳＴ４５）およびＡｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ４８）となる。

そのため、ＵＳＢＴｙｐｅ－Ｃ規格に従うＴｒｙ．ＳＮＫのステートマシンでは、対向デバイスをＳＮＫｏｎｌｙおよびＴｒｙ．ＳＮＫのいずれであるかを判断することはできない。そこで、実施の形態５に従うデバイスは、ＵＳＢＴｙｐｅ－Ｃ規格に従うＴｒｙ．ＳＮＫのステートマシンを少し変更したＴｒｙ．ＳＮＫのステートマシンを採用する。

図１９は、実施の形態５に従うデバイスのステートマシンの要部を示す図である。図１９を参照して、実施の形態５において採用されるＴｒｙ．ＳＮＫのステートマシンは、ＵＳＢＴｙｐｅ－Ｃ規格に従うＴｒｙ．ＳＮＫのステートマシンにおけるＴｒｙ．ＳＮＫステート（ＳＴ４４）に代えて、２つのステート（Ｔｒｙ．ＳＮＫ．１ステート（ＳＴ４４Ａ）およびＴｒｙ．ＳＮＫ．２ステート（ＳＴ４４Ｂ））を有している。

Ｔｒｙ．ＳＮＫ．１ステート（ＳＴ４４Ａ）は、対向デバイスのＰｏｗｅｒＲｏｌｅがＳＲＣになることを待つ（Ｓｏｕｒｃｅ検出待ち）ステートである。一方、Ｔｒｙ．ＳＮＫ．２ステート（ＳＴ４４Ｂ）は、対向デバイスによるＶＢＵＳＯＮを待つ（ＶＢＵＳ検出待ち）ステートである。

このように、ＵＳＢＴｙｐｅ－Ｃ規格に従うＴｒｙ．ＳＮＫのステートマシンにおけるＴｒｙ．ＳＮＫステート（ＳＴ４４）を２つのステートに分解することで、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＳＮＫｏｎｌｙおよびＴｒｙ．ＳＮＫのいずれかに応じて、ステート遷移パスが異なることになる。切替条件ＳＮとしては、このようなステート遷移パスの相違に基づいて、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅを判断する。

図１９を参照して、より具体的には、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＳＮＫｏｎｌｙである場合には、ＡｔｔａｃｈＷａｉｔ．ＳＲＣステート（ＳＴ４７）からＴｒｙ．ＳＮＫ．１ステート（ＳＴ４４Ａ）へ遷移（シーケンスＳＱ４１）した後、ＴｒｙＷａｉｔＳＲＣステート（ＳＴ４５）へ直接遷移し（シーケンスＳＱ４２）、最終的にＡｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ４８）へ到達する（シーケンスＳＱ４３）。

これに対して、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＮＫである場合には、ＡｔｔａｃｈＷａｉｔ．ＳＲＣステート（ＳＴ４７）からＴｒｙ．ＳＮＫ．１ステート（ＳＴ４４Ａ）へ遷移（シーケンスＳＱ４１）した後、Ｓｏｕｒｃｅを検出できるので、Ｔｒｙ．ＳＮＫ．２ステート（ＳＴ４４Ｂ）へ遷移する（シーケンスＳＱ４４）。そして、ＴｒｙＷａｉｔＳＲＣステート（ＳＴ４５）へ直接遷移し（シーケンスＳＱ４５）、最終的にＡｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ４８）へ到達する（シーケンスＳＱ４６）。

このように、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＳＮＫｏｎｌｙである場合には、ＡｔｔａｃｈＷａｉｔ．ＳＲＣステート（ＳＴ４７）、Ｔｒｙ．ＳＮＫ．１ステート（ＳＴ４４Ａ）、ＴｒｙＷａｉｔＳＲＣステート（ＳＴ４５）、およびＡｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ４８）というステート遷移パスをとる。一方、対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＮＫである場合には、ＡｔｔａｃｈＷａｉｔ．ＳＲＣステート（ＳＴ４７）、Ｔｒｙ．ＳＮＫ．１ステート（ＳＴ４４Ａ）、Ｔｒｙ．ＳＮＫ．２ステート（ＳＴ４４Ｂ）、ＴｒｙＷａｉｔＳＲＣステート（ＳＴ４５）、およびＡｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ４８）というステート遷移パスをとる。

このようなＡｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ４８）に至るステート遷移パスの相違に基づいて、自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅをＳＮＫｏｎｌｙに切り替えるべきか否かを示す切替条件ＳＮを定めることができる。

図２０は、実施の形態５に従うデバイスにおいて採用される切替条件ＳＮを説明するための図である。図２０を参照して、切替条件ＳＮとしては、まず、予め定められたステート遷移パスでＡｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ４８）へ到達したか否かが判断される。予め定められたステート遷移パスは、Ｔｒｙ．ＳＮＫ．１ステート（ＳＴ４４Ａ）、Ｔｒｙ．ＳＮＫ．２ステート（ＳＴ４４Ｂ）、ＴｒｙＷａｉｔＳＲＣステート（ＳＴ４５）、およびＡｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ４８）というステート遷移パスである。

予め定められたステート遷移パスでＡｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ４８）へ到達していれば、切替条件ＳＮは成立と決定される。切替条件ＳＮが成立と決定されると、自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅはＳＮＫｏｎｌｙへ切り替えられる。

（ｈ４：小括）
実施の形態５に従うデバイスによれば、自デバイスおよび接続先の対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがいずれもＤＲＰの一種であるＴｒｙ．ＳＲＣであっても、自デバイスのＰｏｗｅｒＲｏｌｅをＳＲＣに確実に決定できる。これによって、ＰｏｗｅｒＲｏｌｅに関連付けて実行される各種処理についても確実な実行を保証できる。

［Ｉ．実施の形態６］
上述の実施の形態２において説明したような構成を実施の形態５に対しても適用可能である。すなわち、実施の形態５に従うデバイス同士を接続した場合に、最終的なＰｏｗｅｒＲｏｌｅが決定しない可能性があり、この場合には、ＰｏｒｔＰｏｗｅｒＲｏｌｅをＳＮＫｏｎｌｙへ切り替える際に、ＣＣ．Ｏｐｅｎステートを経由するようにしてもよい。これにより、対向デバイスは、自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＳＮＫｏｎｌｙであると判断する。これによって、互いのデバイスが対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅをＴｒｙ．ＳＮＫであるとそれぞれ判断することを回避できる。すなわち、実施の形態５に従うデバイス同士がＰｏｒｔＰｏｗｅｒＲｏｌｅの切り替えを繰り返すことを防止できる。

上述した処理および構成を除いた点は、いずれも上述の実施の形態１および５と同様であるので、詳細な説明は繰り返さない。

［Ｊ．実施の形態７］
上述の実施の形態３において説明したような構成を実施の形態５に対しても適用可能である。すなわち、上述の非特許文献２などに規定されるＵＳＢＴｙｐｅ－Ｃ規格に適合するか否かのテスト（Ｔｙｐｅ－ＣＣｏｍｐｌｉａｎｃｅＴｅｓｔ）において「ＴｅｓｔＰａｓｓ」との判定結果を確実に得ることができるように、切替条件ＳＮに「予め定められた時間だけ待機する」という条件を追加してもよい。

より具体的には、図２０に示すように、予め定められたステート遷移パスでＡｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ４８）へ到達していれば、予め定められた時間だけ待機した後に、切替条件ＳＮは成立と決定されるようにしてもよい。

［Ｋ．実施の形態８］
上述の実施の形態４において説明したような構成を実施の形態５に対しても適用可能である。すなわち、上述の非特許文献３などに規定されるＵＳＢＰｏｗｅｒＤｅｌｉｖｅｒｙ（ＰＤ）において用意されているＰｏｗｅｒＲｏｌｅＳｗａｐ命令の決定処理が優先するために、Ａｔｔａｃｈｅｄ．ＳＲＣステート（ＳＴ４８）において判断される切替条件ＳＮに「対向デバイスがＰＤをサポートしていない」という条件を追加してもよい。切替条件ＳＮの具体的な処理手順は、図１５に示す切替条件ＳＲと同様であるので、詳細な説明は繰り返さない。

実施の形態８に従う切替条件ＳＲを採用することで、実施の形態５および６に示すような機能を実装したデバイスがＰＤをサポートする場合であっても、Ｔｙｐｅ－ＣＣｏｍｐｌｉａｎｃｅＴｅｓｔにおいて「ＴｅｓｔＰａｓｓ」との判定結果を得ることができる。

［Ｌ．実施の形態８の変形例］
上述した実施の形態８に従うデバイスにおいて、対向デバイスのＰｏｗｅｒＲｏｌｅＳｗａｐポリシーに依存せず、予定されたＰｏｗｅｒＲｏｌｅを一意に決定できるように、対向デバイスからの応答に基づいて、切替条件ＳＮの成立または不成立を判断するようにしてもよい。切替条件ＳＮの具体的な処理手順は、図１６に示す切替条件ＳＮと同様であるので、詳細な説明は繰り返さない。

実施の形態８の変形例に従う切替条件ＳＲを採用することで、実施の形態５および６に示すような機能を実装したデバイスがＰＤをサポートする場合において、対向デバイスのＰｏｗｅｒＲｏｌｅＳｗａｐポリシーに依存せず、予定されたＰｏｗｅｒＲｏｌｅを一意に決定できる。

［Ｍ．実施の形態９］
上述の実施の形態１～４および変形例については、互いに適宜組合せることもできるし、任意の変形を加えることもできる。同様に、上述の実施の形態５～８および変形例については、互いに適宜組合せることもできるし、任意の変形を加えることもできる。

［Ｎ．実施の形態１０］
上述の実施の形態１～８および変形例においては、プロセッサ１１２がファームウェア１１４を実行することで、上述したようなコントローラ１１０に係る処理の実行および機能の提供を実現する。

プロセッサ１１２が実行するファームウェア１１４は、制御プログラムであり、外部からインストールまたは更新が可能になっている。ファームウェア１１４は、例えば、非一時的（non-transitory）な記録媒体に格納された状態で流通し、コントローラ１１０内の記憶領域にインストールまたは更新（アップデート）されてもよい。非一時的な記録媒体としては、光学ディスクなどの光学記録媒体、フラッシュメモリなどの半導体記録媒体、ハードディスクまたはストレージテープなどの磁気記録媒体、ＭＯ（Magneto-Optical disk）などの光磁気記録媒体を用いてもよい。すなわち、本実施の形態は、上述したような処理および機能を実現するためのコンピュータ読取可能な制御プログラム、および、当該制御プログラムを格納した記録媒体も含み得る。

別の形態として、インターネットまたはイントラネットを介してサーバ装置からファームウェア１１４をダウンロードするようにしてもよい。

当業者であれば、本実施の形態が実装される時代に応じた技術を適宜用いて、本実施の形態に従うコントローラおよびコントローラを含むデバイスを設計するであろう。

［Ｏ．実施の形態１１］
上述の実施の形態１～８および変形例においては、プロセッサ１１２がファームウェア１１４を実行することで、上述したようなコントローラ１１０に係る処理の実行および機能の提供を実現する。但し、このようなソフトウェア実装ではなく、一部または全部をハードウェア実装としてもよい。ハードウェア実装とする場合には、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field-Programmable Gate Array）といったハードワイヤードなデバイスを採用してもよい。

［Ｐ．まとめ］
本実施の形態によれば、ＵＳＢＴｙｐｅ－Ｃ規格に従うＴｒｙ．ＳＲＣであるデバイスまたはＵＳＢＴｙｐｅ－Ｃ規格に従うＴｒｙ．ＳＮＫであるデバイス同士を接続した場合に、ＳＲＣまたはＳＮＫのいずれか一方にＰｏｗｅｒＲｏｌｅが決定しないという新たな課題を解決できる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。

２ＵＳＢケーブル、２１第１通信ライン、２２第２通信ライン、１００ＰｏｗｅｒＢａｎｋ、１０２コネクタ、１０４電源管理部、１０６バッテリ、１１０コントローラ、１１２プロセッサ、１１４ファームウェア、１１６ＣＣ１／ＣＣ２制御・接続検出モジュール、２００スマートフォン、３００ラップトップパソコン、１１６１第１接続検出ブロック、１１６２第２接続検出ブロック、１１６３，１１６４スイッチ、１１６５，１１６７プルアップ抵抗、１１６６，１１６８プルダウン抵抗、ＧＮＤグランド電位、Ｒｄ，Ｒｐ抵抗値、Ｖｓ電源電位、ｔＥｒｒｏｒＲｅｃｏｖｅｒｙエラー復帰時間。

Claims

ＵＳＢ（Universal Serial Bus）Ｔｙｐｅ－Ｃ規格に従う、給電側および受電側のいずれにもなり得るＤＲＰ（Dual Role Power）に対応したデバイスを実現するためのコントローラであって、
接続先のデバイスである対向デバイスとのシーケンスに従って、自デバイスのＰｏｗｅｒＲｏｌｅが受電側を意味するＳｉｎｋに決定されると、自デバイスのＰｏｗｅｒＲｏｌｅがＳｉｎｋに決定されるまでの自デバイスのステート遷移パスに基づいて、前記対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣであるか否かを判断する第１の処理と、
前記対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣであれば、自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅをＳＲＣｏｎｌｙに切り替えて、前記対向デバイスとのシーケンスを継続する第２の処理とを実行可能に構成される、コントローラ。
前記第２の処理は、前記対向デバイスと電気的に接続された通信ラインをオープンする処理を含み、
前記通信ラインをオープンする処理は、前記自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅが初期状態のＴｒｙ．ＳｒｃをＳＲＣｏｎｌｙに切り替えると判断されると、Ａｔｔａｃｈｅｄ．ＳＮＫステートからＵｎａｔｔａｃｈｅｄ．ＳＲＣステートへ遷移する間に行われる、請求項１に記載のコントローラ。
前記自デバイスのステート遷移パスに基づいて判断する処理は、自デバイスのＰｏｗｅｒＲｏｌｅがＳｉｎｋに決定されるまでのステート遷移パスが、Ａｔｔａｃｈｅｄ．ＳＲＣステート、ＴｒｙＷａｉｔ．ＳＮＫステートおよびＡｔｔａｃｈｅｄ．ＳＮＫステートの順序であるか否かを判断する処理を含む、請求項１に記載のコントローラ。
前記第１の処理は、前記対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣであると判断された後、予め定められた時間だけ待機する処理を含む、請求項１に記載のコントローラ。
前記第１の処理は、前記対向デバイスがＵＳＢＰｏｗｅｒＤｅｌｉｖｅｒｙをサポートしているか否かを判断する処理を含み、
前記コントローラは、前記対向デバイスがＵＳＢＰｏｗｅｒＤｅｌｉｖｅｒｙをサポートしていない場合に、前記第２の処理を実行する、請求項１に記載のコントローラ。
前記第１の処理は、
前記対向デバイスに対してＰｏｗｅｒＲｏｌｅＳｗａｐＲｅｑｕｅｓｔを送信する処理と、
前記対向デバイスからＲｅｊｅｃｔを受信するか否かを判断する処理とを含み、
前記コントローラは、前記対向デバイスからＲｅｊｅｃｔを受信すると、前記第２の処理を実行する、請求項５に記載のコントローラ。
ＵＳＢ（Universal Serial Bus）Ｔｙｐｅ－Ｃ規格に従う、給電側および受電側のいずれにもなり得るＤＲＰ（Dual Role Power）に対応したデバイスを実現するためのコントローラであって、
接続先のデバイスである対向デバイスとのシーケンスに従って、自デバイスのＰｏｗｅｒＲｏｌｅが給電側を意味するＳｏｕｒｃｅに決定されると、自デバイスのＰｏｗｅｒＲｏｌｅがＳｏｕｒｃｅに決定されるまでの自デバイスのステート遷移パスに基づいて、前記対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＮＫであるか否かを判断する第１の処理と、
前記対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＮＫであれば、自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅをＳＮＫｏｎｌｙに切り替えて、前記対向デバイスとのシーケンスを継続する第２の処理とを実行可能に構成される、コントローラ。
ＵＳＢ（Universal Serial Bus）Ｔｙｐｅ－Ｃ規格に従う、給電側および受電側のいずれにもなり得るＤＲＰ（Dual Role Power）に対応したデバイスで実行される制御方法であって、
接続先のデバイスである対向デバイスとのシーケンスに従って、自デバイスのＰｏｗｅｒＲｏｌｅが受電側を意味するＳｉｎｋに決定されると、自デバイスのＰｏｗｅｒＲｏｌｅがＳｉｎｋに決定されるまでの自デバイスのステート遷移パスに基づいて、前記対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣであるか否かを判断するステップと、
前記対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣであれば、自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅをＳＲＣｏｎｌｙに切り替えて、前記対向デバイスとのシーケンスを継続するステップとを備える、制御方法。
ＵＳＢ（Universal Serial Bus）Ｔｙｐｅ－Ｃ規格に従う、給電側および受電側のいずれにもなり得るＤＲＰ（Dual Role Power）に対応したデバイスで実行される制御方法であって、
接続先のデバイスである対向デバイスとのシーケンスに従って、自デバイスのＰｏｗｅｒＲｏｌｅが給電側を意味するＳｏｕｒｃｅに決定されると、自デバイスのＰｏｗｅｒＲｏｌｅがＳｏｕｒｃｅに決定されるまでの自デバイスのステート遷移パスに基づいて、前記対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＮＫであるか否かを判断するステップと、
前記対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＮＫであれば、自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅをＳＮＫｏｎｌｙに切り替えて、前記対向デバイスとのシーケンスを継続するステップとを備える、制御方法。
ＵＳＢ（Universal Serial Bus）Ｔｙｐｅ－Ｃ規格に従う、給電側および受電側のいずれにもなり得るＤＲＰ（Dual Role Power）に対応したデバイスを実現するためのコントローラのプロセッサで実行される制御プログラムであって、前記制御プログラムは、前記プロセッサに、
接続先のデバイスである対向デバイスとのシーケンスに従って、自デバイスのＰｏｗｅｒＲｏｌｅが受電側を意味するＳｉｎｋに決定されると、自デバイスのＰｏｗｅｒＲｏｌｅがＳｉｎｋに決定されるまでの自デバイスのステート遷移パスに基づいて、前記対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣであるか否かを判断するステップと、
前記対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＲＣであれば、自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅをＳＲＣｏｎｌｙに切り替えて、前記対向デバイスとのシーケンスを継続するステップとを実行させる、制御プログラム。
ＵＳＢ（Universal Serial Bus）Ｔｙｐｅ－Ｃ規格に従う、給電側および受電側のいずれにもなり得るＤＲＰ（Dual Role Power）に対応したデバイスを実現するためのコントローラのプロセッサで実行される制御プログラムであって、前記制御プログラムは、前記プロセッサに、
接続先のデバイスである対向デバイスとのシーケンスに従って、自デバイスのＰｏｗｅｒＲｏｌｅが給電側を意味するＳｏｕｒｃｅに決定されると、自デバイスのＰｏｗｅｒＲｏｌｅがＳｏｕｒｃｅに決定されるまでの自デバイスのステート遷移パスに基づいて、前記対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＮＫであるか否かを判断するステップと、
前記対向デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅがＴｒｙ．ＳＮＫであれば、自デバイスのＰｏｒｔＰｏｗｅｒＲｏｌｅをＳＮＫｏｎｌｙに切り替えて、前記対向デバイスとのシーケンスを継続するステップとを実行させる、制御プログラム。