特許 7481711 ＵＳＢ Ｔｙｐｅ－Ｃインターフェース回路における状態通知方法、ＵＳＢ Ｔｙｐｅ－Ｃインターフェース回路を有するデバイス、および情報処理システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-05-01

(45)【発行日】2024-05-13

(54)【発明の名称】ＵＳＢ Ｔｙｐｅ－Ｃインターフェース回路における状態通知方法、ＵＳＢ Ｔｙｐｅ－Ｃインターフェース回路を有するデバイス、および情報処理システム

(51)【国際特許分類】

   G06F 13/38 20060101AFI20240502BHJP

   G06F 11/07 20060101ALI20240502BHJP

【ＦＩ】

G06F13/38 320Z

G06F13/38 350

G06F11/07 140T

G06F11/07 184

G06F11/07 190

【請求項の数】 6

(21)【出願番号】P 2022023416

(22)【出願日】2022-02-18

(62)【分割の表示】P 2018184567の分割

【原出願日】2018-09-28

(65)【公開番号】P2022060365

(43)【公開日】2022-04-14

【審査請求日】2022-02-18

【審判番号】

【審判請求日】2023-06-09

(73)【特許権者】

【識別番号】000227205

【氏名又は名称】ＮＥＣプラットフォームズ株式会社

(74)【代理人】

【識別番号】100077838

【弁理士】

【氏名又は名称】池田 憲保

(74)【代理人】

【識別番号】100129023

【弁理士】

【氏名又は名称】佐々木 敬

(72)【発明者】

【氏名】松村 暢也

【合議体】

【審判長】林 毅

【審判官】稲垣 良一

【審判官】吉田 美彦

(56)【参考文献】

【文献】特開２０１８－１１４４２（ＪＰ，Ａ）

【文献】特開２０１８－１０６５５５（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１８／０２４８３５６（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１８／０１８３５４６（ＵＳ，Ａ１）

【文献】Ｍｏｒｔｅｎ Ｃｈｒｉｓｔｉａｎｓｅｎ，ＵＳＢ Ｔｙｐｅ－Ｃの実装に関する３つの課題とその対処［オンライン］，日本シノプシス合同会社，２０１６年１月［検索日：２０２３年１１月２２日］，インターネット＜ＵＲＬ：ｈｔｔｐｓ：／／ｗｗｗ．ｓｙｎｏｐｓｙｓ．ｃｏｍ／ｃｏｎｔｅｎｔ／ｄａｍ／ｓｙｎｏｐｓｙｓ／ｊａｐａｎ／ｄａｔａｓｈｅｅｔｓ／ｕｓｂ＿ｔｙｐｅ－ｃ＿ｃｈａｌｌｅｎｇｅｓ－ｊｐ．ｐｄｆ＞

(58)【調査した分野】(Int.Cl.，ＤＢ名)

IPC G06F 13/38

G06F 11/07

(57)【特許請求の範囲】

【請求項1】

デバイスと上位装置とがUSB (Universal Serial Bus) Type-C規格に準拠したType-Cケーブルを介して接続されたUSB Type-Cインターフェース回路における状態通知方法であって、
前記Type-Cケーブルは、CC（Configuration Channel）ラインを含み、
前記デバイスは、前記Type-Cケーブルに接続されたコネクタと、該コネクタを介して前記CCラインに接続されたType-Cコントローラと、該デバイスを制御するデバイスコントローラとを有し、
前記状態通知方法は、
前記デバイスコントローラが、前記デバイス内で発生した異常状態を検知し、
前記デバイスコントローラが、検知した異常状態を表す検知情報を前記Type-Cコントローラに通知し、
前記Type-Cコントローラが、前記検知情報に基づいて前記デバイスコントローラが検知した異常状態から原因を分析して分析結果を得、
前記Type-Cコントローラが、前記CCラインを利用して、前記上位装置へ前記検知情報と前記分析結果とを通知し、
前記デバイスは、高速信号のスイッチを含み、
該スイッチで異常が発生した場合、前記デバイスコントローラは、前記スイッチでの異常発生に起因して当該デバイスコントローラに信号が届いていないことを前記異常状態として検知して、前記信号が届いていない旨を前記検知情報として前記Type-Cコントローラに通知し、
前記Type-Cコントローラは、通知された前記信号が届いていない旨の前記検知情報を分析して、前記スイッチで異常が発生したと判断した結果を前記分析結果として前記上位装置へ通知する、
USB Type-Cインターフェース回路における状態通知方法。

【請求項2】

前記Type-Cコントローラは、前記CCラインの使用頻度が少ない時間に、前記CCラインを利用して、前記上位装置へ前記検知情報と前記分析結果とを通知する、
請求項１に記載のUSB Type-Cインターフェース回路における状態通知方法。

【請求項3】

デバイスと上位装置とがUSB (Universal Serial Bus) Type-C規格に準拠したType-Cケーブルを介して接続されたUSB Type-Cインターフェース回路における状態通知方法であって、
前記Type-Cケーブルは、CC（Configuration Channel）ラインを含み、
前記デバイスは、前記Type-Cケーブルに接続されたコネクタと、該コネクタを介して前記CCラインに接続されたType-Cコントローラと、該デバイスを制御するデバイスコントローラとを有し、
前記状態通知方法は、
前記デバイスコントローラが、前記デバイス内で発生した異常状態を検知し、検知した異常状態を表す検知情報に基づいて、前記異常状態から原因を分析して分析結果を得、
前記デバイスコントローラが、前記検知情報と前記分析結果とを前記Type-Cコントローラに通知し、
前記Type-Cコントローラが、前記CCラインを利用して、前記上位装置へ前記検知情報と前記分析結果とを通知し、
前記デバイスは、高速信号のスイッチを含み、
該スイッチで異常が発生した場合、前記デバイスコントローラは、前記スイッチでの異常発生に起因して当該デバイスコントローラに信号が届いていないことを前記異常状態として検知し、前記検知情報として前記信号が届いていない旨に基づいて、前記スイッチで異常が発生したと判断した結果を前記分析結果として得る、
USB Type-Cインターフェース回路における状態通知方法。

【請求項4】

前記Type-Cコントローラは、前記CCラインの使用頻度が少ない時間に、前記ＣＣラインを利用して、前記上位装置へ前記検知情報と前記分析結果とを通知する、
請求項３に記載のUSB Type-Cインターフェース回路における状態通知方法。

【請求項5】

USB (Universal Serial Bus) Type-C規格に準拠したType-Cケーブルを介して情報処理装置と接続するUSB Type-Cインターフェース回路を用いるデバイスにおいて、
前記Type-Cケーブルは、CC（Configuration Channel）ラインを含み、
前記デバイスは、前記Type-Cケーブルに接続されたコネクタと、該コネクタを介して前記CCラインに接続されたType-Cコントローラと、該デバイスを制御するデバイスコントローラとを有し、
前記デバイスコントローラは、前記デバイス内で発生した異常状態を検知し、検知した異常状態を表す検知情報を前記Type-Cコントローラに通知し、
前記Type-Cコントローラは、前記検知情報に基づいて前記デバイスコントローラが検知した異常状態から原因を分析して分析結果を得、前記検知情報と前記分析結果とを、前記CCラインを利用５，して、前記情報処理装置へ通知し、
前記デバイスは、高速信号のスイッチを含み、
該スイッチで異常が発生した場合、前記デバイスコントローラは、前記スイッチでの異常発生に起因して当該デバイスコントローラに信号が届いていないことを前記異常状態として検知して、前記信号が届いていない旨を前記検知情報として前記Type-Cコントローラに通知し、
前記Type-Cコントローラは、通知された前記信号が届いていない旨の前記検知情報を分析して、前記スイッチで異常が発生したと判断した結果を前記分析結果として前記情報処理装置へ通知する、
USB Type-Cインターフェース回路を用いるデバイス。

【請求項6】

デバイスと上位装置とがUSB (Universal Serial Bus) Type-C規格に準拠したType-Cケーブルを介して接続されたUSB Type-Cインターフェース回路を有する情報処理システムにおいて、
前記Type-Cケーブルは、CC（Configuration Channel）ラインを含み、
前記デバイスは、前記Type-Cケーブルに接続されたコネクタと、該コネクタを介して前記CCラインに接続されたType-Cコントローラと、該デバイスを制御するデバイスコントローラとを有し、
前記デバイスコントローラは、前記デバイス内で発生した異常状態を検知し、検知した異常状態を表す検知情報を前記Type-Cコントローラに通知し、
前記Type-Cコントローラは、前記検知情報に基づいて前記デバイスコントローラが検知した異常状態から原因を分析して分析結果を得、前記検知情報と前記分析結果とを、前記CCラインを利用して、前記上位装置へ通知し、
前記デバイスは、高速信号のスイッチを含み、
該スイッチで異常が発生した場合、前記デバイスコントローラは、前記スイッチでの異常発生に起因して当該デバイスコントローラに信号が届いていないことを前記異常状態として検知して、前記信号が届いていない旨を前記検知情報として前記Type-Cコントローラに通知し、
前記Type-Cコントローラは、通知された前記信号が届いていない旨の前記検知情報を分析して、前記スイッチで異常が発生したと判断した結果を前記分析結果として前記上位装置へ通知する、
USB Type-Cインターフェース回路を有する情報処理システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、USB (Universal Serial Bus) Type-Cインターフェース回路に関し、特にUSB Type-Cインターフェース回路における状態通知方法に関する。

【背景技術】

【0002】

USB Type-Cインターフェース回路は、ホスト装置とデバイスとの両方をつなぐインターフェース回路である。USB Type-Cインターフェース回路は、これまでのUSBデバイスのインターフェース回路と比べ小型であるにもかかわらず、極数が大幅に増加している。ここで、これまでのUSBデバイスのインターフェース回路とは、USB Type-Aインターフェース回路や、USB Type-Bインターフェース回路のことを指す。また、USB Type-Cインターフェース回路では、電源が投入されている状態での挿抜（ホットプラグ）もこれまでと同様にサポートされている。このことから、USB Type-Cインターフェース回路は、接触不良等による異常が発生しやすい、インターフェース回路である。

【0003】

また、USB Type-Cインターフェース回路においては、正常に動作しない、認識されないといった異常の原因を、次のような作業によって使用者が認識している。ここで、異常の原因の箇所としては、例えば、USBデバイスやUSBケーブルが考えられる。すなわち、作業として、実際にUSB Type-Cインターフェース回路の挿抜を行う、USBデバイスもしくはUSBケーブルを交換する等の切り分け作業を行うことで、初めてその異常の原因を知ることができる。

【0004】

また、本発明に関連する先行技術文献が、種々、知られている。

【0005】

例えば、特許文献１は、接続された外部機器のインターフェースの種別をより確実に判定することが可能な「電子機器」を開示している。この特許文献１は、接続した機器がType-C機器か非Type-C機器かの判定を行うことができる技術的思想を開示している。尚、Type-C機器とは、USB Type-C規格に準拠したインターフェースを有する機器を指し、非Type-C機器とは、USB Type-C規格に準拠したインターフェースを有していない機器を指す。

【0006】

特許文献２は、ＶＢＵＳなどの電力供給用の端子から外部機器の電力が供給されなくなっても、電池やキャパシタなどの蓄積部を使用することなく、外部機器の種別を判定できる「電子機器及びその制御方法」を開示している。特許文献２でも、上記特許文献１と同様に、接続した機器がType-C機器か非Type-C機器かの判定を行うことができる技術思想を開示している。

【0007】

また、特許文献３は、USBデバイスへの給電に際して安全性を高めることが可能な「半導体装置、半導体装置の制御方法および給電システム」を開示している。特許文献３において、給電システムは、ホストと、USBデバイスと、USBケーブルとを有する。USBデバイスは、USBケーブルを介して、ホストとデータ通信を行うことができるとともに、ホストから電力の供給を受けることができる。USBケーブルは、一例としてUSB Type-Cケーブルを利用することが可能である。ホストは、電源部と、電源部を制御するコントローラと、抵抗と、スイッチとを含む。コントローラは、電源制御回路と、異常検出回路と、異常状態通知回路とを含む。電源制御回路は、電源部およびスイッチを制御する。異常検出回路は、電圧の供給経路の状態として正常か異常かを判断する。異常検出回路は、判断結果を異常状態通知回路に出力する。異常状態通知回路は、異常検出回路の判断結果に基づいて異常状態である旨を通知する。具体的には、異常状態通知回路は、アラーム音あるいはＬＥＤで異常状態である旨を外部に報知する。通信回路を用いて外部に報知するようにしても良い。このように、特許文献３では、電源線(VBUS)の異常状態の検出をType-Cコントローラ内で行っている。

【0008】

特許文献４は、コネクタへの異物混入に起因した端子間の短絡を高精度に判定することができる「短絡判定方法及び電子機器」を開示している。特許文献４において、電子機器は、Type-Cコネクタと、充電回路と、スイッチと、抵抗と、接続検出回路と、監視回路と、判定回路と、CC端子制御回路とを有する。監視回路は、Type-Cコネクタに充電機器が接続されたことを契機として、ＲＸ＋端子、ＲＸ２－端子の各々に関して、電圧変化を監視する。判定回路は、監視回路によって監視される電圧変化を用いて、ＵＢＵＳ端子とＲＸ＋端子、ＲＸ－探知との短絡が発生したか否かを判定する。そして、判定回路は、ＲＸ＋電圧及びＲＸ－電圧の立ち上がりタイミングが、ＵＢＵＳ電圧の立ち上がりのタイミングに一致する場合に、Type-Cコネクタへの異物混入に起因して短絡が発生したと判定する。

【0009】

特許文献５は、USB Type-C規格に準拠するＡＣアダプタを使用する場合に、当該ＡＣアダプタが焼損防止機能を備えていない場合であっても、焼損事故を防止できる「電子機器」を開示している。特許文献５において、電子機器は、USB Type-C規格のレセプタクルと、システム回路と、充電池と、プルダウン抵抗と、ＦＦＴ（Field effect transistor）スイッチと、制御回路と、センス抵抗を含む構成である。レセプタクルは、ロックプレートと、シェルと、Ｖ_ＢＵＳピンと、CC（Configuration Channel）ピンとを含む構成である。レセプタクルは、USB Type-C規格に準拠する相手方のコネクタと接続される。相手方のコネクタはケーブルを介してUSB Type-C規格に準拠した充電用アダプタと接続されているものとする。センス抵抗は、レセプタクルのシェルとグラウンド間の短絡電流発生回路に設けられる。もしセンス抵抗において電流が（意味のある値以上の値で）検出された場合、シェルとグラウンドの間に短絡電流が発生していることを意味する。制御回路は、センス抵抗において検出された電流が所定の条件を充たす場合（例えば検出された電流が予め定めた閾値を超過する場合）に、ＦＥＴスイッチを切断に制御する。ＦＥＴスイッチが切断されると、電子機器と充電用アダプタの接続を確認するCCピンに対応する信号経路が遮断されることになるため、充電用アダプタは、電子機器との接続が解除されたと認識し、電力の供給を停止する（充電用アダプタの電源がＯＦＦに制御される）。

【0010】

特許文献６は、受電装置における短絡を安全に検出可能な、給電システムおよび受電装置を開示している。特許文献６において、給電システムは、USB Type-C規格に準拠しており、USBケーブルを介して接続される給電装置と受電装置を備える。給電装置は給電側コントローラを含み、受電装置は受電側コントローラを含む。給電側コントローラおよび受電側コントローラはそれぞれ、USB Type-Cに関するポートコントローラであり、CC（Configuration Channel）ラインを介して互いに接続され、通信機能を提供する。受電装置は短絡検出回路を含む。短絡検出回路は、バススイッチのオフ状態において、バススイッチよりも負荷回路側の第２バスラインにおける短絡を検出する。受電側コントローラは、短絡が検出されたとき、CCラインでの通信を利用して、負荷側の短絡を給電側コントローラに通知してもよい。給電側コントローラは、この通知に応答して、電源回路を停止することができる。

【先行技術文献】

【特許文献】

【0011】

【文献】特開２０１８－０１３９３２号公報

【文献】特開２０１８－０１３９３３号公報

【文献】特開２０１７－１８７９３３号公報

【文献】特開２０１８－０２９４５１号公報

【文献】特開２０１７－２０１８６２号公報

【文献】特開２０１８－０１１４４２号公報

【非特許文献】

【0012】

【文献】Universal Serial Bus Type-C Cable and Connector Specification Revision 1.1, April 3, 2015

【文献】Universal Serial Bus Power Delivery Specification Revision 2.0, V1.1, 7 May 2015

【発明の概要】

【発明が解決しようとする課題】

【0013】

USB Type-Cインターフェース回路には、次に述べるような問題点がある。

【0014】

第１の問題点は、USB Type-Cインターフェース回路が、接触不良等による異常が発生しやすいインターフェース回路であることである。

【0015】

その理由は、次の通りである。インターフェース回路の小型化が進む一方で、信号線（電源・グランド含む）の数は、USB Type-CでないUSBインターフェース回路より増えている（USB2.0 Type-A：4本、USB3.0 Type-A：9本、USB Type-C：20本）。また、USB Type-Cインターフェース回路は、Alternate modeで使用することでUSBのみならずPCI-ExpressやDisplayPort、HDMI（登録商標）（High-Definition Multimedia Interface）等の高速信号（High Speed Signal）を取り扱うことができる。USB Type-Cインターフェース回路は、電源としてもUSB Type-CでないUSBインターフェース回路において使用されていた５Ｖだけでなく、最大２０Ｖ、５Ａまでサポートができる仕様である。そのため、USB Type-Cインターフェース回路は、物理的にも端子間が狭く精密な接続が要求される。しかしながら、USB Type-Cインターフェース回路は、ホットプラグがサポートされる外部インターフェースでもあることから、挿抜頻度が高く、抉りや挿抜による摩耗によって接触不良に陥りやすいからである。

【0016】

第２の問題点は、正常に動作しない、認識されないといった異常の原因（例えば、デバイスなのかケーブルなのか）を使用者が認識するためには、実際に挿抜を行う、デバイスもしくはケーブルを交換する等の切り分け作業を行うことで初めてその原因を知ることができる点である。

【0017】

その理由は、次の通りである。高速信号ラインの異常状態は各デバイスのコントローラによって各高速信号の通信プロトコルにより異常状態を通知することができている。しかしながら、あくまでデバイスコントローラが検知できる範囲の異常状態しか通知することができない。例として、USB Type-Cインターフェース回路を使用する上で欠かすことができない高速信号のスイッチ（Multiplexer：MUX）が故障しているとする。この場合、周知のUSB Type-Cインターフェース回路には、その異常をデバイスコントローラに伝える仕組みはない。なぜなら、デバイスコントローラはUSB Type-Cの規格が策定される以前から使用されている物が多く、USB Type-Cインターフェース回路で使用する前提で設計されたものではないからである。また、MUXによる高速信号の切替えは、USB Type-Cインターフェース回路を使用する上で必要となった機能であることから、デバイスコントローラとMUX間での状態通知をする仕組みがない。

【0018】

一方、特許文献１～６には、それぞれ、次に述べるような問題がある。

【0019】

特許文献１および特許文献２では、単に、接続した機器がType-C機器か非Type-C機器かの判定を行っているに過ぎず、デバイスの異常状態を上位装置へ通知してはいない。

【0020】

特許文献３は、単に、電源線（VBUS）の異常状態の検出をType-Cコントローラ内で行っているに過ぎず、デバイスの異常状態を上位装置へ通知してはいない。

【0021】

特許文献４は、単に、Type-Cコネクタへの異物混入に起因した端子間の短絡を判定しているに過ぎず、デバイスの異常状態を上位装置へ通知していはいない。

【0022】

特許文献５は、単に、焼損事故を防止できる電子機器を開示しているに過ぎず、デバイスの異常状態を上位装置へ通知していはいない。

【0023】

特許文献６は、短絡が検出されたときに、CCラインでの通信を利用して、短絡を通知する技術を開示している。すなわち、特許文献６では、デバイスの異常状態としてバスラインにおける短絡のみを検知しており、それ以外の理由でデバイス内で発生した異常状態を検知してはいない。換言すれば、特許文献６では、予め異常の原因が短絡であることを前提としており、それ以外の原因については検知することができない。

【0024】

本発明の目的は、上述した課題を解決する、USB Type-Cインターフェース回路における状態通知方法を提供することにある。

【課題を解決するための手段】

【0025】

本発明の第１の態様として、USB Type-Cインターフェース回路における状態通知方法は、デバイスと上位装置とがUSB (Universal Serial Bus) Type-C規格に準拠したType-Cケーブルを介して接続されたUSB Type-Cインターフェース回路における状態通知方法であって、前記Type-Cケーブルは、CC（Configuration Channel）ラインを含み、前記デバイスは、前記Type-Cケーブルに接続されたコネクタと、該コネクタを介して前記CCラインに接続されたType-Cコントローラと、該デバイスを制御するデバイスコントローラとを有し、前記状態通知方法は、前記デバイスコントローラが、前記デバイス内で発生した異常状態を検知し、前記デバイスコントローラが、検知した異常状態を表す検知情報を前記Type-Cコントローラに通知し、前記Type-Cコントローラが、前記検知情報に基づいて前記異常状態から原因を分析して分析結果を得、前記Type-Cコントローラが、前記CCラインを利用して、前記上位装置へ前記検知情報と前記分析結果とを通知する。

【0026】

本発明の第２の態様として、USB Type-Cインターフェース回路における状態検知方法は、デバイスと上位装置とがUSB (Universal Serial Bus) Type-C規格に準拠したType-Cケーブルを介して接続されたUSB Type-Cインターフェース回路における状態通知方法であって、前記Type-Cケーブルは、CC（Configuration Channel）ラインを含み、前記デバイスは、前記Type-Cケーブルに接続されたコネクタと、該コネクタを介して前記CCラインに接続されたType-Cコントローラと、該デバイスを制御するデバイスコントローラとを有し、前記状態通知方法は、前記デバイスコントローラが、前記デバイス内で発生した異常状態を検知し、検知した異常状態を表す検知情報に基づいて、前記異常状態から原因を分析して分析結果を得、前記デバイスコントローラが、前記検知情報と前記分析結果とを前記Type-Cコントローラに通知し、前記Type-Cコントローラが、前記CCラインを利用して、前記上位装置へ前記検知情報と前記分析結果とを通知する。

【0027】

本発明の第３の態様として、USB Type-Cインターフェース回路における状態通知方法は、デバイスと上位装置とがUSB (Universal Serial Bus) Type-C規格に準拠したType-Cケーブルを介して接続されたUSB Type-Cインターフェース回路における状態検知方法であって、前記Type-Cケーブルは、CC（Configuration Channel）ラインを含み、前記デバイスは、前記Type-Cケーブルに接続されたコネクタと、該コネクタを介して前記CCラインに接続されたType-Cコントローラと、該デバイスを制御するデバイスコントローラと、異常状態の分析を行う専用コントローラとを有し、前記状態通知方法は、前記デバイスコントローラが、前記デバイス内で発生した異常状態を検知して、検知情報を前記専用コントローラへ通知し、前記専用コントローラが、前記検知情報に基づいて前記異常状態から原因を分析して、分析結果と前記検知情報とをType-Cコントローラに通知し、前記Type-Cコントローラが、前記CCラインを利用して、前記上位装置へ前記検知情報と前記分析結果とを通知する。

【0028】

本発明の第４の態様として、USB Type-Cインターフェース回路における状態通知方法は、デバイスと上位装置とがUSB (Universal Serial Bus) Type-C規格に準拠したType-Cケーブルを介して接続されたUSB Type-Cインターフェース回路における状態通知方法であって、前記Type-Cケーブルは、CC（Configuration Channel）ラインと、該ＣＣラインに接続されたType-Cコントローラと、を含み、前記状態通知方法は、前記Type-Cコントローラが、前記Type-Cケーブル内に異常が発生したことを検知して、検知情報を得、前記Type-Cコントローラが、前記検知情報を分析して、分析結果を得、前記Type-Cコントローラが、前記CCラインを利用して、前記上位装置へ前記検知情報と前記分析結果とを通知する。

【発明の効果】

【0029】

本発明によれば、信頼性を向上し、保守性を向上することができる。

【図面の簡単な説明】

【0030】

【図1】本発明の第１の実施形態に係る、USB Type-Cインターフェース回路を用いたシステムの接続構成を示す図である。

【図2】本発明の第１の実施形態に係るUSB Type-C インターフェース回路における状態通知方法の一例について説明するためのフローチャートである。

【図3】本発明の第１の実施形態に係るUSB Type-C インターフェース回路における状態通知方法の変形例について説明するためのフローチャートである。

【図4】本発明の第２の実施形態に係る、USB Type-Cインターフェース回路を用いたシステムの接続構成を示す図である。

【図5】本発明の第２の実施形態に係るUSB Type-C インターフェース回路における状態通知方法の一例について説明するためのフローチャートである。

【図6】本発明の第３の実施形態に係るUSB Type-C インターフェース回路における状態通知方法の一例について説明するためのフローチャートである。

【図7】図１に図示した第１の実施形態に係るUSB Type-Cインターフェース回路を使用した通信において、デバイスMUXで異常が発生した場合の動作（第１の実施例）を説明するための図である。

【図8】図４に図示した第２の実施形態に係るUSB Type-Cインターフェース回路を使用した通信において、デバイスMUXで異常が発生した場合の動作（第２の実施例）を説明するための図である。

【図9】図４に図示した第２の実施形態に係るUSB Type-Cインターフェース回路を使用した通信において、デバイスMUXにメインコントローラからのUSB信号とDisplayport信号との異なる２つの入力信号が供給される場合の構成を示す図である。

【図10】第２の実施例に係る仕組みを備えたデバイスを示すブロック図である。

【発明を実施するための形態】

【0031】

最初に、本発明の概要について説明する。

【0032】

本発明では、USB Type-Cインターフェース回路を用いるデバイスについて、以下の手順(1)～(4)で課題の解決を図る。
(1)デバイスコントローラがデバイス内で発生した異常状態を検知する。
(2)デバイスコントローラがType-Cコントローラに検知した情報を通知する。
(3)Type-Cコントローラが異常状態から原因を分析する。
(4)Configuration Channel (CC)ラインを利用して上位Type-Cコントローラに異常状態と分析結果とを通知する。

【0033】

この時(3)の役割はデバイスコントローラが行ってもよい。その場合、デバイスコントローラがType-Cコントローラに対して異常状態と分析結果とを通知し、Type-CコントローラはCCラインを用いて上位Type-Cコントローラに通知するだけでもよい。

【0034】

次に、本発明の効果について説明する。

【0035】

第１の効果は、USB Type-Cインターフェース回路のCCラインを用いて異常状態と分析結果とを通知することで、新たにインターフェースを追加する必要がなく、実現できる点にある。

【0036】

その理由は、次の通りである。CCラインはUSB Type-Cインターフェース回路を用いる上で必ず存在する信号線である。CCラインは、通常動作においてはデバイス認識時のネゴシエーションの機能として、USB Type-Cインターフェース回路の特徴でもあるケーブル表裏向き、要求電源（VBUS）電圧、使用する高速信号情報の通知を行う。

【0037】

デバイス接続時のネゴシエーションが完了すると、上位Type-Cコントローラが電圧レベルの監視を行いケーブルの挿抜が行われたかを判断するのみで、この信号ライン（CCライン）を用いての通信等は行われない。

【0038】

通常接続されたデバイスは、使用者が頻繁に抜き差しを行わない限り、接続されたままの状態であり、つまりはCCラインの使用頻度は低い状態であると言える。

【0039】

また、一般的にデバイスコントローラは異常時の通信プロトコルをサポートしている場合が多いが、その通信も正常動作を行っている信号ラインを用いて（異常状態を通知する時間に割いて）行われる。そのため、その間は通常動作の性能に影響する。

【0040】

そこで、本発明では、CCラインの使用頻度の低い時間を利用して、状態異常の通知を行うことで、動作性能に影響を与えることなく異常通知が可能となる。

【0041】

第２の効果は、通常の高速信号の異常通知ではサポートできる異常状態が各通信プロトコルに則ったものに限られるが、本発明ではデバイスコントローラに検知させる異常状態は各通信プロトコルでサポートされていない異常でも通知可能となることである。

【0042】

その理由は、次の通りである。CCラインは、現状各高速信号、デバイスコントローラとは分離されており、あくまで上位装置およびデバイスのType-Cコントローラ間の通信にのみ使用される信号ラインである。そのため、CCラインは、各高速信号、デバイスコントローラのサポートしていない異常状態に関しても、独自のプロトコルで通知する手段として考えることができるためである。

【0043】

CCラインが独自のプロトコルで通知する手段として考えることができるとは、USB Type-Cの規格で使用しているConfiguration Channel (CC)の通信プロトコル(BMC等)と、USB2.0、USB3.0、Displayport等の高速信号で使用される通信プロトコルが全く別物であるということを意味する。また、その通信を行うための信号線も分かれている。

【0044】

CCラインは元々USB Type-Cの規格上定められている信号線であり、既知の技術である。

【0045】

しかしながら、本発明では、各デバイスのエラー状態をCCラインを使って上位装置に通信を行うというものであり、既存の技術として、デバイスのエラー状態までCCラインを用いて通信する技術はない。

【0046】

ここで、独自のプロトコルとあるが、USB Type-Cインターフェース回路としてネゴシエーションを行う場合に使用される通信プロトコルは、その規格(USB Power Delivery)で定義されている。

【0047】

本発明においては、そのプロトコルに沿った通信を行っても、新しい異常通信用のプロトコルを準備してもよい。その場合、その通信のエンコード／デコードを行うのはUSB Type-Cコントローラとなるため、Type-CコントローラのF/W（firmware）をカスタマイズする必要性がある。

【0048】

次に、本発明の実施の形態について図面を参照して詳細に説明する。

【0049】

［実施形態１］
図１は本発明の第１の実施形態に係る、USB Type-Cインターフェース回路１００を用いたシステムの接続構成を示す図である。

【0050】

［構成の説明］
USB Type-Cインターフェース回路１００は、上位装置であるホスト装置２００と、USB Type-Cデバイス３００と、ホスト装置２００とUSB Type-Cデバイス３００とを接続するType-Cケーブル４００とを備える。USB Type-Cデバイス３００は、単に、デバイスとも呼ばれる。Type-Cケーブル４００はUSBケーブルとも呼ばれる。

【0051】

上位装置（ホスト装置）２００は、上位コネクタ２１０と、メインコントローラ２２０と、上位Type-Cコントローラ２３０と、上位MUX２４０と、電源（VBUS）制御回路２５０と、Type-Cケーブル用電源（VCONN）制御回路２６０と、を備える。上位装置（ホスト装置）２００には、電源５００が接続されている。

【0052】

上位コネクタ２１０は、Type-Cケーブル４００に接続されている。メインコントローラ２２０は、CPU（central processing unit）やチップセットのようなシステムの制御部として働く。上位Type-Cコントローラ２３０は、USB Type-Cインターフェース回路１００に係る信号処理を行う。上位MUX２４０は、高速信号の切替えを行うスイッチである。

【0053】

デバイス３００は、デバイスコネクタ３１０と、デバイスコントローラ３２０と、デバイスType-Cコントローラ３３０とを内蔵する。図示のデバイス３００は、デバイスMUX３４０を含む。

【0054】

デバイスコネクタ３１０は、Type-Cケーブル４００に接続されている。デバイスコントローラ３２０は、デバイス３００全体の制御を行う。デバイスType-Cコントローラ３３０は、USB Type-Cインターフェース回路１００に係る信号処理を行う。デバイスMUX３４０は、高速信号の切替えを行うスイッチである。

【0055】

また、デバイス３００は、デバイス３００側から上位装置２００に対し電源（VBUS）を供給するための電源制御回路（図示せず）を持っていてもよい。

【0056】

Type-Cケーブル４００は、CC（Configuration Channel）ライン４１０を含む。図示のType-Cケーブル４００は、ケーブルType-Cコントローラ４２０を含む。

【0057】

上位Type-Cコントローラ２３０は、VBUS制御、VCONN制御、Type-Cデバイス３００（Type-Cケーブル４００を含む）との接続制御、ケーブルの表裏接続状態検出や、接続デバイスの情報から高速信号の切り替えを行うための制御信号を出力したりする。

【0058】

メインコントローラ２２０は、上位Type-Cコントローラ２３０と内部や外部で接続されていてもよく、上位Type-Cコントローラ２３０とは独立していてもよい。

【0059】

［動作の説明］
次に、USB Type-Cインターフェース回路１００の動作について説明を行う。

【0060】

本発明の第１の実施形態においては、その機能においてデバイスType-Cコントローラ３３０が上位装置２００と通信できるように接続された構成となっている。その場合の信号例としては、I2C（Inter-Integrated Circuit）等のシリアル通信がある。

【0061】

ホストType-Cコントローラ２３０とデバイスType-Cコントローラ３３０とは、CCライン４１０にて接続されている。CCライン４１０は、BFSK（Binary Frequency Shift Keying）方式(USB Power Delivery Rev1)もしくはBMC（Biphase Mark Coding）方式(USB Power Delivery Rev2以降)で、パケット通信を行う。このパケット通信において、上位装置２００側の供給可能電源仕様や、デバイス３００側の要求電源、使用する高速信号等の情報をType-Cコントローラ２３０、３３０間でやり取りを行う。この通信を行うタイミングは、Type-Cケーブル４００が上位装置２００およびデバイス３００に接続され、ケーブルの表裏接続状態が検出された後である。

【0062】

第１の実施形態においては、CCライン４１０は、上記通信の完了後、パケット通信には利用されず、Type-Cケーブル４００の接続状態の監視に利用される。

【0063】

この接続状態の監視は、USB通信のようにSOF（Soft of Frame）パケットを用いたポーリングとは異なり、CCライン４１０の電流もしくは電圧値を上位Type-Cコントローラ２３０で監視することで行っている。Type-Cケーブル４００が抜かれたことをCCライン４１０で検出した場合、上位Type-Cコントローラ２３０は速やかにVBUSを落とすために、VBUS制御回路２５０内の放電回路を動作させる。

【0064】

本発明の第１の実施形態においては、デバイス３００の異常状態を通信する手段として、CCライン４１０の接続状態監視中のパケット通信が行われない使用頻度が少ない時間を、異常状態のパケット通信に割り当てている。

【0065】

図２を参照して、本発明の第１の実施形態に係るUSB Type-C インターフェース回路１００における状態通知方法の一例について説明する。

【0066】

先ず、デバイスコントローラ３２０が、デバイス３００内で発生した異常状態を検知する（ステップＳ１０１）。

【0067】

引き続いて、デバイスコントローラ３２０が、検知した異常状態を表す検知情報をデバイスType-Cコントローラ３３０に通知する（ステップＳ１０２）。

【0068】

次に、デバイスType-Cコントローラ３３０が、検知情報に基づいて異常状態から原因を分析して分析結果を得る（ステップＳ１０３）。

【0069】

最後に、デバイスType-Cコントローラ３３０が、CCライン４１０を利用して、上位装置２００の上位Type-Cコントローラ２３０へ検知情報と分析結果とを通知する（ステップＳ１０４）。このとき、デバイスType-Cコントローラ３３０は、前述したように、CCライン４１０の使用頻度が少ない時間に、CCライン４１０を利用して、上位装置２００の上位Type-Cコントローラ２３０へ検知情報と分析結果とを通知する。

【0070】

図３を参照して、本発明の第１の実施形態に係るUSB Type-C インターフェース回路１００における状態通知方法の変形例について説明する。

【0071】

先ず、デバイスコントローラ３２０が、デバイス３００内で発生した異常状態を検知する（ステップＳ０１０１）。

【0072】

引き続いて、デバイスコントローラ３２０が、検知した異常状態を表す検知情報に基づいて、異常状態から原因を分析して分析結果を得る（ステップＳ１０２Ａ）。

【0073】

次に、デバイスコントローラ３２０が、検知情報と分析結果とをデバイスType-Cコントローラ３３０に通知する（ステップＳ１０３Ａ）。

【0074】

最後に、デバイスType-Cコントローラ３３０が、CCライン４１０を利用して、上位装置２００の上位Type-Cコントローラ２３０へ検知情報と分析結果とを通知する（ステップＳ１０４）。このとき、デバイスType-Cコントローラ３３０は、前述したように、CCライン４１０の使用頻度が少ない時間に、CCライン４１０を利用して、上位装置２００の上位Type-Cコントローラ２３０へ検知情報と分析結果とを通知する。

【0075】

次に、第１の実施形態の効果について説明する。

【0076】

第１の効果は、信頼性を向上できることある。その理由は、検知情報と分析情報とを上位装置２００に通知することで、USB Type-C インターフェース回路１００における異常個所の特定ができるからである。

【0077】

第２の効果は、保守性を向上できることである。その理由は、異常個所が特定でき、使用者が解析を行うことなく復旧手段や交換対象が明確になるからである。

【0078】

［実施形態２］
図４は本発明の第２の実施形態に係る、USB Type-Cインターフェース回路１００Ａを用いたシステムの接続構成を示す図である。

【0079】

［構成の説明］
図示のUSB Type-Cインターフェース回路１００Ａは、デバイスの構成が後述するように変更された点を除いて、図１に図示したUSB Type-Cインターフェース回路１００と同様の構成を有し、動作をする。したがって、デバイスに３００Ａの参照符号を付してある。図１のUSB Type-Cインターフェース回路１００と同様の構成要素には同一の参照符号を付し、説明を簡略化するために、それらの説明については省略する。

【0080】

デバイス３００Ａは、異常状態の分析を行うための専用コントローラ３５０を更に備えている点を除いて、図１に図示したデバイス３００と同様の構成を有し、動作をする。

【0081】

［動作の説明］
USB Type-Cインターフェース回路１００Ａの基本的な動作は、先に述べた、USB Type-Cインターフェース回路１００と同様である。

【0082】

図５を参照して、本発明の第２の実施形態に係るUSB Type-C インターフェース回路１００Ａにおける状態通知方法の一例について説明する。

【0083】

先ず、デバイスコントローラ３２０が、デバイス３００Ａ内で発生した異常状態を検知する（ステップＳ１０１）。

【0084】

引き続いて、デバイスコントローラ３２０が、検知情報を専用コントローラ３５０へ通知する（ステップＳ１０２Ｂ）。

【0085】

次に、専用コントローラ３５０が、検知情報に基づいて異常状態から原因を分析して、分析結果と検知情報とをデバイスType-Cコントローラ３３０に通知する（ステップＳ１０３Ｂ）。

【0086】

最後に、デバイスType-Cコントローラ３３０が、CCライン４１０を利用して、上位装置２００の上位Type-Cコントローラ２３０へ検知情報と分析結果とを通知する（ステップＳ１０４）。このとき、デバイスType-Cコントローラ３３０は、前述したように、CCライン４１０の使用頻度が少ない時間に、CCライン４１０を利用して、上位装置２００の上位Type-Cコントローラ２３０へ検知情報と分析結果とを通知する。

【0087】

第２の実施形態の効果は、上述した第１の実施形態の効果と同様である。

【0088】

［実施形態３］
本発明の第３の実施形態に係るUSB Type-Cインターフェース回路１００は、図１に図示したものと同様のシステムの接続構成を有している。

【0089】

図１に示されるように、Type-Cケーブル４００にケーブルType-Cコントローラ４２０が内蔵されている。このケーブルType-Cコントローラ４２０は、上位Type-Cコントローラ２３０とは、デバイスType-Cコントローラ３３０と同様にCCライン４１０にて接続されている。

【0090】

［動作の説明］
図６を参照して、本発明の第３の実施形態に係るUSB Type-C インターフェース回路１００における状態通知方法の一例について説明する。

【0091】

先ず、ケーブルType-Cコントローラ４２０が、Type-Cケーブル４００内に異常が発生したことを検知して、検知情報を得る（ステップＳ２０１）。

【0092】

引き続いて、ケーブルType-Cコントローラ４２０が、検知情報を分析して、分析結果を得る（ステップＳ２０２）。

【0093】

最後に、ケーブルType-Cコントローラ４２０が、CCライン４１０を利用して、上位装置２００の上位Type-Cコントローラ２３０へ検知情報と分析結果とを通知する（ステップＳ２０３）。このとき、ケーブルType-Cコントローラ４２０は、前述したように、CCライン４１０の使用頻度が少ない時間に、CCライン４１０を利用して、上位装置２００の上位Type-Cコントローラ２３０へ検知情報と分析結果とを通知する。

【0094】

これにより、Type-Cケーブル４００が異常状態であることをユーザに知らせることができる。

【0095】

次に、第３の実施形態に関して、より具体的に説明する。

【0096】

デバイスMUX３４０に入力される高速信号はType-Cケーブル４００を通してしかデバイス３００側に共有されない。そのため、Type-Cケーブル４００で考えられる故障としては、断線もしくはショートが挙げられる。

【0097】

また、USB Type-C規格において、Type-Cケーブル４００内にケーブルType-Cコントローラ４２０を持たせたe-Markerと呼ばれるケーブルが定義されている。ケーブルType-Cコントローラ４２０はホスト装置２００側から専用電源（VCONN）が供給されて動作をする。

【0098】

既存のUSB Type-C規格で定義されているケーブルType-Cコントローラ４２０の機能は、Type-Cケーブル４００を通してホスト装置２００側からデバイス３００側に供給されることになる電源(VBUS)のスペックがType-Cケーブル４００に通すことができる電源仕様を満たしているかを監視することにある。すなわち、既存のケーブルType-Cコントローラ４２０の機能は、Type-Cケーブル４００のスペック以上の電流を流すことで焼損等の問題が発生しないように保護するための機能である。

【0099】

上記の監視結果については、Configuration Channel（CCライン）４１０を介して上位Type-Cコントローラ２３０と通信を行う。現状のUSB Type-C規格では、電源以外の高速信号の状態についてケーブルType-Cコントローラ４２０で監視を行う機能はない。

【0100】

そのため、本第３の実施形態においては、ケーブルType-Cコントローラ４２０に、デバイス３００側で行うデバイスMUX３４０、デバイスコントローラ３２０間の高速信号を監視するような仕組みを設けている。これにより、Type-Cケーブル４００の状態について異常を検出することができる。

【0101】

この仕組みは、例えば、ケーブルType-Cコントローラ４２０に、高速信号の波形からデコードできるようなアナライザと呼ばれる計測器の機能を1chip化した専用コントローラを実現し、実装すれば可能となる。

【実施例1】

【0102】

次に、本発明の第１の実施例として、図７を参照して、図１に図示した第１の実施形態に係るUSB Type-Cインターフェース回路１００を使用した通信において、デバイスMUX３４０で異常が発生した場合の動作について説明する。

【0103】

最初に、図７のＡ１の処理について説明する。

【0104】

デバイスMUX３４０で異常が発生した場合、デバイスMUX３４０を通す信号が正常にデバイス３００へ入力されないため、デバイス３００が応答しない。

【0105】

このような状況において、関連技術では、ホスト装置２００は、信号の状況からデバイス３００が認識できていないことを検知し、アプリケーション（AP）等６００へ通知を行うことができる。しかしながら、通知できるのはあくまでも認識できていないという事実のみで、どの部分で異常が発生しているかの詳細な情報を知ることはできない。

【0106】

これに対して、デバイスコントローラ３２０自体は、電源（VBUS）が投入されていれば電源が入っているにもかかわらず、信号が来ていないことを知ることができる。そこで、本第１の実施例においては、デバイスコントローラ３２０は、デバイスType-Cコントローラ３３０に対して、検知情報として、デバイスコントローラ３２０に信号が届いていない旨の通知を行うことができる。

【0107】

この時、図３のステップＳ１０２Ａのように、デバイスコントローラ３２０が考えられる異常状態を分析して、その分析結果をデバイスType-Cコントローラ３３０に通知してもよい。或いは、図２のステップＳ１０３のように、状態異常の通知を受けたデバイスType-Cコントローラ３３０の中で分析してもよい。

【0108】

尚、デバイスコントローラ３２０とデバイスType-Cコントローラ３３０との間の通信は、I2C（Inter-Integrated Circuit）等のシリアル通信や、予め決めておいたエラー内容ごとのbitパターンによるパラレル通信でもよい。

【0109】

次に、図７のＡ２の処理について説明する。

【0110】

先のＡ１の処理の後、図２または図３のステップＳ１０４のように、デバイスType-Cコントローラ３３０が、上位Type-Cコントローラ２３０とCCライン４１０を用いてシリアル通信を行う。

【0111】

この時のシリアル通信は、USB Type-C Power Deliveryで定義されているBMC（Biphase Mark Coding）方式やBFSK（Binary Frequency Shift Keying）方式で、本発明において新たに定義した状態異常通信用のパケット構成で通信を行う。

【0112】

最後に、図７のＡ３の処理について説明する。

【0113】

先のＡ２の処理により、状態異常通信を受け取った上位Type-Cコントローラ２３０は、その情報をメインコントローラ２２０やアプリケーション６００に通知を行い、ユーザに知らせる。

【0114】

これにより、ユーザはデバイス３００の異常の原因として、デバイスコントローラ３２０に信号が届いておらず、デバイスMUX３４０が異常であることを知ることができる。

【実施例2】

【0115】

次に、本発明の第２の実施例として、図８を参照して、図４に図示した第２の実施形態に係るUSB Type-Cインターフェース回路１００Ａを使用した通信において、デバイスMUX３４０で異常が発生した場合の動作について説明する。

【0116】

最初に、図８のＢ１の処理について説明する。

【0117】

デバイスコントローラ３２０は、専用コントローラ３５０に対して、検知情報として、デバイスコントローラ３２０に信号が届いていない旨の通知を行う。

【0118】

次に、図８のＢ２の処理について説明する。

【0119】

この時、図５のステップＳ１０３Ｂのように、専用コントローラ３５０が考えられる異常状態を分析して、その分析結果をデバイスType-Cコントローラ３３０に通知する。

【0120】

次に、図８のＢ３の処理について説明する。

【0121】

先のＢ２の処理の後、図５のステップＳ１０４のように、デバイスType-Cコントローラ３３０が、上位Type-Cコントローラ２３０とCCライン４１０を用いてシリアル通信を行う。

【0122】

最後に、図８のＢ４の処理について説明する。

【0123】

先のＢ３の処理により、状態異常通信を受け取った上位Type-Cコントローラ２３０は、その情報をメインコントローラ２２０やアプリケーション６００に通知を行い、ユーザに知らせる。

【0124】

これにより、ユーザはデバイス３００の異常の原因として、デバイスコントローラ３２０に信号が届いておらず、デバイスMUX３４０が異常であることを知ることができる。

【0125】

次に、本発明の第２の実施例についてより具体的に説明する。

【0126】

Multiplexer (MUX)は、複数の信号を切り替えるスイッチの役割を果たしており、一般的に1チップ化されたIC（integrated circuit）によって実現される。

【0127】

このICは電気的なスイッチであり、複数の入力に対し複数ある出力ポートの出先を切り替えることができる。また、その切り替えを行うための制御信号としては、入出力の組み合わせに応じた数の切り替え信号を入力できるようになっている。しかしながら、デバイスMUX３４０は、あくまで受動的なデバイスであるので、IC自らが異常を上位装置に通知する仕組みが入っていない。ここで、異常とは、例えばIC内部のスイッチを構成する部分の故障で信号が切り替わらない等が考えられる。

【0128】

そこで、本第２の実施例では、後述するように、異常を上位装置に通知できる仕組みを備えている。

【0129】

次にデバイスMUX３４０を通した信号はデバイスコントローラ（後述する）に入力される。デバイスコントローラ自身は自らがサポートしている信号と異なる信号が入力されているか否かをデバイス内部のF/W等により判断することが可能である。このとき、デバイスコントローラは、各高速信号の通信プロトコルに則った状態異常の通知を行う。

【0130】

図９は、デバイスMUX３４０にCPUやチップセット等のメインコントローラ２２０からのUSB信号とDisplayport信号との異なる２つの入力信号が供給される場合の構成を示す図である。

【0131】

図９に示されるように、デバイスMUX３４０には、Displayport信号用のデバイスコントローラ３２２と、USB信号用のデバイスコントローラ３２４とを含む。

【0132】

このような構成において、関連技術では、使用者によって異常と認識される状態としては、以下のような状態が考えられる。
1) Displayportに接続されたモニタが表示されない。
2) USB3.0デバイス(例えばUSBメモリ等)がUSB3.0 Super Speedで認識されない。

【0133】

この内1)は、デバイスコントローラ３２２より先のモニタ自身の状態に関する。この場合、最大４対存在する映像信号のうち２対が来ていなくても、スペックは落ちるもののモニタに表示をすることができる。

【0134】

また、2)についても、デバイス３００Ａが下位互換のUSB 2.0 High Speedをサポートしていれば、USBメモリとしては動作する。

【0135】

そこで、本発明の第２の実施例において、以下に詳細に説明するように、接続先のデバイス３００Ａの異常状態から、デバイスMUX３４０の故障を推測する仕組みを備える。

【0136】

例えば上記1)、2)ともに下位スペックでデバイス３００Ａが動作している場合、デバイス３００Ａの異常状態をデバイスコントローラ３２２、３２４が気づくことができる。この仕組みは既存の技術であり、デバイスコントローラ３２２、３２４が異常状態を上位装置２００に通知することができる。

【0137】

しかしながら、この通知の中では具体的な故障個所(この例ではデバイスMUX３４０)を推測し送ることはできない。その理由は次の通りである。第１に、USB Type-Cインターフェース回路の仕組みが構築されるより前の技術であることから、デバイスMUX３４０の故障を推測し通知するようにはデバイスコントローラ３２２、３２４のファームウェアが対応されていないことである。第２に、故障個所が上位装置２００と接続される信号ラインであることから上位装置２００に送る術がないことである。すなわち、現状の仕組みであると、「USB 3.0 Super Speedで動作していない」という事実のみを上位装置２００で認識することができる。

【0138】

図１０は、第２の実施例に係る仕組みを備えたデバイス３００Ａを示すブロック図である。

【0139】

専用コントローラ３５０とデバイスコントローラ３２０、３２２、３２４との間には、異常状態を通知するためのパスが設けられている。専用コントローラ３５０とデバイスType-Cコントローラ３３０との間には、分析結果を通知するためのパスが設けられている。

【0140】

例えば、図１０に示されるように、デバイスMUX３４０のUSB3.0 Super Speedで故障が発生したと仮定する。

【0141】

この場合、デバイスコントローラ３２２は、Displayportは正常に動作しており、当該デバイスコントローラ３２２内にも異常が見られないことを示す正常状態を、専用コントローラ３５０に通知する。一方、デバイスコントローラ３２４は、USB3.0 Super Speedで動作していないが、当該デバイスコントローラ３２４内には異常が見られないことを示す異常状態を、専用コントローラ３５０に通知する。

【0142】

専用コントローラ３５０は、これら正常状態および異常状態を分析することによって、デバイスMUX３４０の故障が疑わしいとの分析結果を得る。専用コントローラ３５０は、上記異常状態と分析結果とをデバイスType-Cコントローラ３３０に通知する。

【0143】

デバイスType-Cコントローラ３３０は、これら通知された異常状態および分析結果を、Configuration Channel（CCライン）４１０を使用することで上位装置２００に通知する。

【0144】

このように、本第２の実施例では、外部に各デバイスコントローラ３２０、３２２、３２４の異常状態を分析・通知するパスを設け、さらにデバイスType-Cコントローラ３３０がConfiguration Channel（CCライン）４１０を使用することで上位装置２００に異常状態と分析結果とを通知することが可能となる。

【0145】

また、この仕組みには、次のような利点がある。関連技術では、異常状態の通知には各高速信号専用の信号ラインを使用していた。USB Type-Cインターフェース回路の場合は他の信号ラインで異常状態を通知することができる。デバイス３００Ａの一部分が異常状態で、その他の部分は正常に動作できているとする。この場合、対象のデバイスコントローラ内部で異常状態の通信にかかわる動作を正常動作の中に盛り込むのではなく、本第２の実施例のように、専用コントローラ３５０が処理することで、各デバイスコントローラは、正常部の動作にのみ集中することができるようになる。

【0146】

以上、実施形態および実施例を参照して本発明を説明したが、本発明は上記実施形態および実施例に限定されるものではない。本発明の構成や詳細には、本発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

【産業上の利用可能性】

【0147】

本発明の活用例として、USB Type-Cインターフェース回路を用いた端末に利用することができる。

【符号の説明】

【0148】

１００、１００Ａ USB Type-Cインターフェース回路
２００ ホスト装置（上位装置）
２１０ 上位コネクタ
２２０ メインコントローラ
２３０ 上位Type-Cコントローラ
２４０ 上位MUX
２５０ VBUS制御回路
２６０ VCONN制御回路
３００、３００Ａ USB Type-Cデバイス（デバイス）
３１０ デバイスコネクタ
３２０、３２２、３２４ デバイスコントローラ
３３０ デバイスType-Cコントローラ
３４０ デバイスMUX
３５０ 専用コントローラ
４００ Type-Cケーブル（USBケーブル）
４１０ CC（Configuration Channel）ライン
４２０ ケーブルType-Cコントローラ
５００ 電源
６００ アプリケーション（AP）

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】