(57)【要約】【課題】ＣＥＣ機器と互換性を確保しながらＣＥＣ機器が混在した状況でも高速な通信が可能で、デバイス間で高度な連携が可能となる通信システム、電子機器、および通信方法を提供する。【解決手段】送受信するＣＥＣの１フレームデータにはスタートビット、ヘッダブロック、および少なくとも一つのデータブロック３３を含み、電子機器は、イニシエータの機能およびフォロワーの機能のうち少なくとも一方の機能を持つことが可能で、データブロック期間中にパルスによる高速通信を行う機能を有する。【選択図】図５
2009159061.tif 000002
【特許請求の範囲】
【請求項１】
映像と音声のデータ伝送と接続機器情報の交換、機器制御データの通信を可能とする通信ケーブルを接続可能でＣＥＣデバイスを含む電子機器間の通信システムであって、
送受信するＣＥＣの１フレームデータにはスタートビット、ヘッダブロック、および少なくとも一つのデータブロックを含み、
上記電子機器は、
イニシエータの機能およびフォロワーの機能のうち少なくとも一方の機能を持つことが可能で、
上記データブロック期間中にパルスによる高速通信を行う機能を有する
通信システム。
【請求項２】
上記電子機器は、
所定のセーフサンプルピオリド期間に高速通信を行う
請求項１記載の通信システム。
【請求項３】
上記電子機器は、
高速通信において、補助情報により早期エンドオブメッセージ処理が可能である
請求項１記載の通信システム。
【請求項４】
上記電子機器は、
高速通信において、補助情報により通信中に機器間でイニシエータとフォロワーの役割がフレーム中で交代する送受信チェンジを実現可能である
請求項１記載の通信システム。
【請求項５】
上記電子機器は、
高速転送フレームデータに高速転送モードデータの付加、未付加による高速転送モードと通常転送モードとのネゴシエーションを行う機能を有する
請求項１記載の通信システム。
【請求項６】
映像と音声のデータ伝送と接続機器情報の交換、機器制御データの通信を可能とする通信ケーブルを接続可能でＣＥＣデバイスを含み、イニシエータの機能およびフォロワーの機能のうち少なくとも一方の機能を持つことが可能な電子機器であって、
送受信するＣＥＣの１フレームデータにはスタートビット、ヘッダブロック、および少なくとも一つのデータブロックを含み、
上記データブロック期間中にパルスによる高速通信を行う機能を有する
電子機器。
【請求項７】
所定のセーフサンプルピオリド期間に高速通信を行う
請求項６記載の電子機器。
【請求項８】
高速通信において、補助情報により早期エンドオブメッセージ処理が可能である
請求項６記載の電子機器。
【請求項９】
高速通信において、補助情報により通信中に機器間でイニシエータとフォロワーの役割がフレーム中で交代する送受信チェンジを実現可能である
請求項６記載の電子機器。
【請求項１０】
高速転送フレームデータに高速転送モードデータの付加、未付加による高速転送モードと通常転送モードとのネゴシエーションを行う機能を有する
請求項６記載の電子機器。
【請求項１１】
映像と音声のデータ伝送と接続機器情報の交換、機器制御データの通信を可能とする通信ケーブルを接続可能でＣＥＣデバイスを含む電子機器間の通信方法であって、
送受信するＣＥＣの１フレームデータにはスタートビット、ヘッダブロック、および少なくとも一つのデータブロックを含み、
上記電子機器は、
イニシエータの機能およびフォロワーの機能のうち少なくとも一方の機能を持つことが可能で、
上記データブロック期間中にパルスによる高速通信を行う
通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、非圧縮の画像の画素データを一方向に高速伝送することができる、たとえばＨＤＭＩ（High Definition Multimedia Interface）などの通信インタフェースを有する通信システム、電子機器、および通信方法に関するものである。
【背景技術】
【０００２】
ＣＥＣ(Consumer Electronic Control)は欧州で普及しているP50を参考にして制定されたＨＤＭＩのオプション規格で、ＨＤＭＩケーブル内の１本の信号線を使った双方向シリアル通信の手段を規定したプロトコルである。
【０００３】
転送レートは416bps(理論値)と低速である。またその特徴として、ＨＤＭＩケーブルで接続された機器間をバス接続で結ぶことが可能であり、各々がイニシエータ（Initiator；マスタ）とフォロワー（Follower；スレーブ）となり得るマルチマスタ通信形態を持つ。
【０００４】
ＣＥＣの使用方法として、たとえばビデオ（Video）再生機器（Source）とテレビジョン受像機（以下、TV；（Sink）をＨＤＭＩで接続した状態を想定すると、ＴＶのリモートコントローラ（以下、リモコンという場合もある）で電源をオフにすると、その情報がＴＶからＣＥＣを経由してVideoに送信され、ＴＶとVideoの電源を同時にオフにすることが可能となる。
【０００５】
またVideoの再生ボタンを押すと同時にＴＶの入力切り替えが発生して、Videoのチャネルが選択されるような使い方がある。
これらの機能によりユーザーはリモコンを持ち替えることなく、ＴＶとVideoの機器操作をすることが可能となる。
【０００６】
ＣＥＣの特長としてソース（Source）からシンク（Sink）へ一方向でデータが転送されるＨＤＭＩシステム内で、唯一シンク（Sink）からソース（Source）へデータを主体的に送ることが可能であり、ＴＶを主体とした送信形態をとることができる通信ラインであることが上げられる。
【０００７】
特許文献１には、システム内にホスト制御ユニットからの高レベル命令をＣＥＣ標準の低レベル電気信号に変換する装置の提案やＣＥＣの利便性を利用した実装方法が提示されている。
【０００８】
また、特許文献２には、ＨＤＭＩ接続システム間の信号伝送の補助としてＣＥＣの利用が適用できる例も提示されており、ＨＤＭＩ接続のシステム内で情報を送受信できるＣＥＣの利用は今後拡大されていくと思われる。
【特許文献１】特開２００６−１３５９５９号公報
【特許文献２】特開２００７−００６２９８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
ＣＥＣが現状想定している使用範囲はユーザーの機器操作の利便性向上が主であり、リモコン通信程度の帯域で動作をカバーできたが、特許文献２の技術のように圧縮映像のパケット再送要求をＣＥＣで送る場合は高度なタイムスケジュールが要求されると思われ、現状の低速なＣＥＣ通信では再送要求が間に合わない可能性がある。
【００１０】
従来のＣＥＣに求められている以上の機能を実装する必要が生じた場合、たとえばＴＶの電源投入と同時にＴＶの構成情報をレコーダやアンプに送りレコーダやアンプを最適な状態に再構成するシステムを考えた場合、その情報が１Ｋバイトあるとすると２０秒近い転送時間を経る必要がある。
これは、たとえ特許文献１の技術のように高レベル命令を低レベル電気信号に変換する装置を用いて実装したとしても、根本的なＣＥＣの標準プロトコルである416bpsがネックとなり、かわらない。
電源投入後に２０秒の待ち時間が発生することで解決される問題が大きい場合はそのシステムは実用できるが、ＴＶから送らなければならない情報が１Ｍバイトの場合は５時間の転送時間が必要となり、決して実用的とはいえない。
【００１１】
このように、ＨＤＭＩケーブルでつながったそれぞれの機器がＣＥＣで相互通信できる状態にあるにも関わらず、何らかの高機能を実装しようとする場合、必ず転送レートが遅いことにより実用性が低くなってしまう。
【００１２】
このように、ＨＤＭＩの普及が拡大する中で、ＨＤＭＩシステムの更なる利便性や高機能の付加を考えた場合、ＣＥＣの標準転送である416bpsを上回る転送レートを実現できるＣＥＣに適した通信装置が必要である。
【００１３】
転送速度を上げるためには、既存のプロトコルに規定されていない手法により、電気信号で0と1を表現する必要がある。
既存の高速化のための手法として、たとえば１bitの信号を表す期間を単純に短くすることで高転送レートを実現できた。
【００１４】
ＣＥＣプロトコルでも、マスターとスレーブの１対１の場合を考えると、そのように1bitの期間を短くして転送レートを上げることは可能である。
しかし、ＣＥＣのプロトコルの特長として、複数のＣＥＣデバイスがバス接続することが上げられる。
たとえばＴＶとレコーダとＡＶアンプはＨＤＭＩケーブルでＴＶ/ＡＶアンプ間、ＴＶ/レコーダ間において１対１で接続されるが、回路構造上はＴＶ-ＡＶアンプ-レコーダのＣＥＣデバイスがバス接続している。
このような接続を許可しているため、バス内にどのようなＣＥＣデバイスが接続されるかがわからないため、限定された機器間の転送であっても転送方式を変えることができない。
【００１５】
具体的に起きる症状として、送信者と受信者の２点間でＣＥＣの標準プロトコルを無視した高速転送をしている状況で、高速転送に対応していない第３のＣＥＣデバイスが接続されていると、第３のＣＥＣデバイスは高速転送をモニタすることができない。
このため、誰もＣＥＣバスを占拠していないものと勘違いしてＣＥＣバス上にデータを流し、高速通信を阻害することが考えられる。
【００１６】
本発明は、ＣＥＣ機器と互換性を確保しながらＣＥＣ機器が混在した状況でも高速な通信が可能で、デバイス間で高度な連携が可能となる通信システム、電子機器、および通信方法を提供することにある。
【課題を解決するための手段】
【００１７】
本発明の第１の観点は、映像と音声のデータ伝送と接続機器情報の交換、機器制御データの通信を可能とする通信ケーブルを接続可能でＣＥＣデバイスを含む電子機器間の通信システムであって、送受信するＣＥＣの１フレームデータにはスタートビット、ヘッダブロック、および少なくとも一つのデータブロックを含み、上記電子機器は、イニシエータの機能およびフォロワーの機能のうち少なくとも一方の機能を持つことが可能で、上記データブロック期間中にパルスによる高速通信を行う機能を有する。
【００１８】
好適には、上記電子機器は、所定のセーフサンプルピオリド期間に高速通信を行う。
【００１９】
好適には、上記電子機器は、高速通信において、補助情報により早期エンドオブメッセージ処理が可能である。
【００２０】
好適には、上記電子機器は、高速通信において、補助情報により通信中に機器間でイニシエータとフォロワーの役割がフレーム中で交代する送受信チェンジを実現可能である。
【００２１】
好適には、上記電子機器は、高速転送フレームデータに高速転送モードデータの付加、未付加による高速転送モードと通常転送モードとのネゴシエーションを行う機能を有する。
【００２２】
本発明の第２の観点は、映像と音声のデータ伝送と接続機器情報の交換、機器制御データの通信を可能とする通信ケーブルを接続可能でＣＥＣデバイスを含み、イニシエータの機能およびフォロワーの機能のうち少なくとも一方の機能を持つことが可能な電子機器であって、送受信するＣＥＣの１フレームデータにはスタートビット、ヘッダブロック、および少なくとも一つのデータブロックを含み、上記データブロック期間中にパルスによる高速通信を行う機能を有する。
【００２３】
本発明の第３の観点は、映像と音声のデータ伝送と接続機器情報の交換、機器制御データの通信を可能とする通信ケーブルを接続可能でＣＥＣデバイスを含む電子機器間の通信方法であって、送受信するＣＥＣの１フレームデータにはスタートビット、ヘッダブロック、および少なくとも一つのデータブロックを含み、上記電子機器は、イニシエータの機能およびフォロワーの機能のうち少なくとも一方の機能を持つことが可能で、上記データブロック期間中にパルスによる高速通信を行う。
【００２４】
本発明によれば、電子機器は、データブロックの所定のセーフサンプルピオリド期間にパルスによる高速通信を行う。
【発明の効果】
【００２５】
本発明によれば、ＣＥＣ機器と互換性を確保しながらＣＥＣ機器が混在した状況でも高速な通信が可能で、デバイス間で高度な連携が可能となる。
【発明を実施するための最良の形態】
【００２６】
以下、本発明の実施の形態を図面に関連付けて説明する。
【００２７】
本実施形態においては、まず通信システム例について説明した後、通常の通信プロトコル、高速転送プロトコル、および通常のＣＥＣとの相互接続について説明する。
【００２８】
図１は、本発明の実施形態に係る通信方法を適用した通信システムの構成例を示す図である。
【００２９】
図１の通信システム１００は、既存のＣＥＣ機器と互換性を確保しながら高速通信を実現することによりＣＥＣ接続のデバイス間で高度な連携が可能となるように構成されている。ここでは、一例としてＴＶ１１０に、二つのＨＤＤレコーダ１３０，１４０がＨＤＭＩを介して接続した例を示す。
【００３０】
ＴＶ１１０は、表示部１１１、表示切替回路１１２、システム制御部１１３、リモートコントロール（リモコン）信号受信部１１４、ユーザーインタフェース（Ｉ／Ｆ）１１５、メモリ１１６、ＣＥＣデバイス１１７、ＨＤＭＩレシーバ（Rx）１１８，１１９、チューナ１２０を有する。
【００３１】
ＨＤＤレコーダ１３０は、ＣＥＣデバイス１３１、ＨＤＭＩトランスミッタ（Tx）１３２、システム制御部１３３、メモリ１３４、ＨＤＤ１３５、およびリモコン信号受信部１３６を有する。
【００３２】
ＨＤＤレコーダ１４０は、ＣＥＣデバイス１４１、ＨＤＭＩトランスミッタ（Tx）１４２、システム制御部１４３、メモリ１４４、ＨＤＤ１４５、およびリモコン信号受信部１４６を有する。
【００３３】
本実施形態において、ソース（Source）機器はそれぞれＨＤＤレコーダ１３０，１４０であり、それぞれ異なるコンテンツＣＮＴ０，ＣＮＴ１をＨＤＤ１３５，１４５内に保持している。
ＨＤＤ１３５，１４５内に保持されているコンテンツＣＮＴ０、ＣＮＴ１のリストＬＳＴ１，ＬＳＴ２はそれぞれのメモリ１３４，１４４に保管されており、ユーザーＵＳＲは、そのリストを見ることでＨＤＤ１３５，１４５内の情報を知ることができる。
このような通信システム１００で通常（既存）のＣＥＣを使用した場合では、ユーザーはリモコンを使用してＴＶ１１０のリモコン信号受信部１１４より明示的にＨＤＤレコーダ１３０のコンテンツ情報を見たい旨を送信する。
するとＴＶ１１０のシステム制御部１１３は表示切替回路１１２を設定して、ＨＤＤレコーダ１３０の映像を受信しているＨＤＭＩレシーバ１１８を有効にし、リモコン信号受信部１１４から入力される命令をＣＥＣデバイス１１７−ＣＥＣデバイス１３１間を通してＨＤＤレコーダ１３０のシステム制御部１３３に送信する。
【００３４】
また、ユーザーＵＳＲがＨＤＤレコーダ１４０のコンテンツ情報ＣＮＴ１を見たい場合は、ユーザーＵＳＲが明示的にＨＤＤレコーダ１４０のコンテンツＣＮＴ１を見たい旨を送信する。
ＴＶ１１０のシステム制御部１１３は、表示切替回路１１２の設定をＨＤＭＩ レシーバ１１９を有効にするように設定して、ユーザーＵＳＲからの命令をＣＥＣデバイス１１７−ＣＥＣデバイス１４１間を通してシステム制御部１４３に送る。
このようにユーザーＵＳＲは明示的にＨＤＤレコーダ１３０とＨＤＤレコーダ１４０のコンテンツＣＮＴ０，ＣＮＴ１を把握する必要があり、ＣＥＣを利用して機器操作する効果として、システム制御部１１３が表示切替回路１１２を自動で設定するだけにとどまる。
【００３５】
この場合、ユーザーがＴＶ１１０の表示切替回路１１２を自分で設定して、リモコン信号受信部１３６，１４６より命令を送るようなＣＥＣ利用以前の操作から格段の利便性の向上があったとはいえない。
これはＴＶのシステムがＣＥＣによってＨＤＤレコーダ１３０のメモリ１３４に格納されているリストＬＳＴ１とＨＤＤレコーダ１４０のメモリ１４４に格納されているリストＬＳＴ２を収集して、メモリ１１６内に一元管理することができれば解決できる。
これにより、ユーザーＵＳＲはメモリ１１６内のリストを選択するだけで、ＴＶのシステム制御部１１３が表示切替回路１１２を自動設定し、ユーザーＵＳＲはＨＤＤレコーダ１３０とＨＤＤレコーダ１４０を意識せず、一つのＨＤＤレコーダとして使用することができる。
【００３６】
しかしこのようなシステムは通常のＣＥＣでは難しい。まず、ＣＥＣが低速であることが原因で、リストの更新が即座にできない。
そのためメモリ１１６には不揮発性メモリを用いて管理するような対策が必要である。  その理由は、低速なＣＥＣを使用した場合ＴＶは時間をかけてＨＤＤレコーダ１３０と１４０内のコンテンツ情報を吸い上げる必要があるため、電源投入後に毎回コンテンツ情報を吸い上げるのは望ましくないからである。
またそのような理由から、ＨＤＤレコーダ１３０とＨＤＤレコーダ１４０の内容の更新に対して、メモリ１１６内の更新タイムラグが発生することが考えられ、返ってユーザーに不便をかける結果にもなりえる。
そこで、本実施形態においては、後で詳述する高速転送プロトコルを採用している。
【００３７】
本発明によりＣＥＣを高速にすることができた場合、図１のような事例でもＴＶ１１０はＨＤＤレコーダ１３０と１４０２のリストＬＳＴ１、リストＬＳＴ２を即座に取り出し、管理ができる。
また、ユーザーインタフェース（Ｉ／Ｆ）１１５にＵＳＢなどのインタフェースを実装することを考えると、Ｉ／Ｆ１１５に接続されたキーボードなどの入力情報を高速ＣＥＣを用いることでＨＤＤレコーダ１３０，１４０にストレスなく送ることができ、一つのＩ／ＦをＨＤＭＩで接続された機器間で共有することができるようになる。
また、ＣＥＣはシンク（Sink）からソース（Source）機器に主体的に情報を発信できる手段であるため、高速ＣＥＣを実現することにより、出力装置であるＴＶを入力装置にすることがＨＤＭＩケーブル一本で可能となる。
たとえば、現状のタッチパネルモニタには、ＡＶ入力のほかにタッチパネル情報を出力するＲＳ２３２ＣケーブルやＵＳＢインタフェースが付属している。これがＨＤＭＩケーブルだけで実現できる。
このように本実施形態により、ＴＶの高付加価値化と、ＴＶを中心とした機器間の連携動作の幅を格段に広げることができる。
【００３８】
以下、本実施形態における通常の通信プロトコル、高速転送プロトコル、および通常のＣＥＣとの相互接続について説明する。
【００３９】
［通常のＣＥＣプロトコル］
図２（Ａ），（Ｂ）は、通常のＣＥＣのプロトコルを示す図である。
【００４０】
この場合、通信単位は１フレーム（1Frame）単位で行われる。Frame（１）はスタートビット（Start Bit）（２）とヘッダブロック（Header Block）（３）といくつかのデータブロック（Data Block）（４）で構成される。
Data Blockは最大16 Blockで、最小 1 Blockとなる。Data Blockの構成（５）は8bitデータ（６）と1bitのEOM（７）とACK（８）の計10bitで構成されており、ACK のみフォロワー（Follower；スレーブ）が送信する。
Start Bitを除いた、すべてのbitは、図２（Ｂ）に示すように、同じタイミングダイアグラム（９）をとり、立下りから始まって、スタートタイム（Sample Time）（１０）の極性で論理（Logical） 1（１１）、Logical 0（１２）を判断する。
1bitを構成するスタートイベント（Start event）（１３）やサンプルタイムリターントーハイ（Sample Time、Return to High）（１４,１５）はマージンを持つが、すべて規格で規定されており、1bitは標準で2.4msecの長さを持ち、これにより転送レートの理論値416bpsが導き出される。
ＥＯＭはエンドオブメッセージ（End Of Message）の略で、Data Blockの終了を表し、現在のData Blockで通信が終了することを意味する。フォロワー（Follower）はこのEOMを検出してFrameの終了を検出することができる。
【００４１】
図３は、通常のＣＥＣプロトコルのHeader Block構成（１６）を示す図である。
【００４２】
Header Blockは4bitのイニシエータ論理（ロジカル）（Initiator Logical）アドレス（１７）と フォロワー論理（ロジカル）（Follower Logical）アドレス（１８）、1bitのEOM（７）とACK（８）の計10bitで構成されており、このHeader Blockによって送信者と受信者の特定、およびバスアービトレーションを行い、通信を確実なものとする。
論理（Logical）アドレスはそれぞれ機器カテゴリー別に決まったアドレスで、プライオリティを有する。
送信を開始するイニシエータ（Initiator）は、送信した情報を常に監視しており、Header BlockのInitiator 論理アドレスが送信した自アドレスでない場合は、優先度の高いイニシエータ（Initiator）にバス権をとられたと判断して、次の通信タイミングを待つ。
自アドレスが検出できた場合は引き続きData Blockの送信を行う。その他、通信中であっても出力した信号とＣＥＣバスの状態が異なった場合はエラーハンドリング（Error Handling）と判断する。エラーハンドリングについては後述する。
【００４３】
フォロワー（Follower）としての機能は全てのデバイス（Device）が対応しなければならず、デバイスはStart Bitを検出したならば、まずヘッダ（Header）の中に自デバイスのアドレスが含まれていないかを解析する。
自デバイスのアドレスをHeader内に検出すると、ACKビットを操作して、イニシエータ（Initiator）に通信の確立を報告する。
その後はData BlockごとにACKビットを操作するが、ACKとは別に受信中にbitタイミングダイアグラムに違反したbitが存在すると、イニシエータ（Initiator）にその旨を報告する必要がある。報告する手段としてエラーハンドリング（Error Handling）という手法がある。
フォロワー（Follower）は違反bitを検出すると（たとえば1bitの構成が規定より短い）ＣＥＣバスをフォロワー（Follower）が3.36msec〜3.84msecの間ロー（Low）に固定する。
イニシエータ（Initiator）は前述の通り送信中の信号を常に監視しているので、あるはずのハイ（High）インピーダンス状態がない場合、フォロワー（Follower）からのエラーハンドリング（Error Handling）と判断して送信の中断を行う。
【００４４】
また、図４は、ＣＥＣのアービトレーション方法とシグナルフリータイム（Signal Free Time）について示す図である。
【００４５】
ＣＥＣの規格ではSignal Free Time（２６）という送信禁止期間が規定されている。全てのデバイスはＣＥＣバスが不活性な状態がSignal Free Timeの期間続いたことを確認してからイニシエータ（Initiator）となることを許可する。
これにより、他のイニシエータ（Initiator）の送信を阻害することがないようにできる。
また、各デバイスの状態によりこの送信禁止期間を変え、各デバイスの送信開始タイミングをずらすことで、アービトレーションロストの低減を行うことができる。
【００４６】
Signal Free Timeは3つの種類があり、前回のFrameで転送を行ったイニシエータ（Initiator）のそれは19.2msecである。前回のFrameでイニシエータ（Initiator）でない場合は14.4msecである。再送信の場合は9.6msecとなっている。
これにより、再送信時は優先的に次のイニシエータ（Initiator）となることができ、一つのイニシエータ（Initiator）が連続して帯域を支配することを防げる。
【００４７】
図４において、Frame1（１９）ではDeviceA（２３）がイニシエータ（Initiator）、DeviceB（２４）がフォロワー（Follower）となり通信を行っている。
その間、DeviceC（２５）はＣＥＣ ライン（Line）が不活性になる（Frame1の通信が終わる）状態を待っている。
Frame1終了後、各DeviceA,B,CによるSignal Free Timeのカウントが始まるが、DeviceAはFrame1でイニシエータ（Initiator）であったため、19.2msecのSignal Free Timeが設定される。
DeviceB,CはFrame1ではイニシエータ（Initiator）でなかったため、14.4msecのSignal Free Timeとなる。
Frame1終了後、DeviceAとDeviceCに送信要求が発生した場合、DeviceCのSignal Free TimeがDeviceAより先に終わるため、Frame2（２０）ではDeviceCがイニシエータ（Initiator）となり、通信を開始する。
イニシエータ（Initiator）になりたかったDeviceAはCEC Lineが活性化したので、Signal Free Timeのカウントを止め、フォロワー（Follower）として動作をはじめる。
【００４８】
次にFrame2の転送が何らかの原因で失敗し、再送信となるとする。
この場合、DeviceCに設定されるSignal Free Timeは9.6msecである。Frame2でイニシエータ（Initiator）ではなかったDeviceA,Bは14.4msecのSignal Free Timeとなる。
このときDeviceA,Bに送信要求があっても、Signal Free Timeが一番早く終わるのはDeviceCとなるため、再送信が優先されてFrame3（２１）ではDeviceCがリトライイニシエータ（Re-try Initiator）（２７）となる。
Frame3が終了後は、DeviceA,Bが14.4msecで、DeviceCが19.2msecのSignal Free Timeとなる。
Frame3終了時点でDeviceAとDeviceBに送信要求が発生しているとすると、互いのSignal Free Timeは同じであるために、Frame4（２２）ではコンフリクト（２９）が発生して、バスアービトレーションが行われる。
この例では、DeviceBがバス権を取得して、DeviceAがアービトレーションロスト（２８）となった場合を示している。
Frame4の終了時はDeviceAとDeviceCが14.4msecで、DeviceBが19.2msecのSignal Free Timeとなる。
【００４９】
以上、通常のＣＥＣプロトコルについて説明した。
次に、本実施形態における高速転送プロトコルについて説明する。
【００５０】
［高速転送プロトコル］
図５は、本実施形態の高速通信のＣＥＣプロトコルを示す図である。
【００５１】
Start Bit（３０）、Header Block（３１）は、どのようなフォロワー（Follower）でも等しく理解できる必要があるため、通常のプロトコルと同じ構成とするが、Data Block（３２,３３）において高速通信することで転送レートを向上させる。
ただし待機DeviceはＣＥＣバスアクティブを監視しているため、Data Block期間中、常にパルスの短い高速通信を行うと、待機DeviceがＣＥＣバスを不活性と判定してしまうこともある。
その問題を回避するため、図５に示すように、高速Bitタイミングダイアグラム（３４）を採用する。
このように、セーフサンプルピオリド（Safe sample period）（３５）期間に高速転送を行うことで、通常プロトコルの待機Deviceを誤動作させることなく高速転送が可能となる。
【００５２】
高速bitタイミングダイアグラムでは、Start eventとReturn to Highのタイミングは、図２に示したように、通常のbitタイミングダイアグラムのLogical 1と同等の数値を取るものとする。
Safe sample period内で1bit、10μsec程度のシリアル通信を行い合計40bitの情報を送信する。Safe sample period終了後の残りの期間は通常のLogical 1と同様にハイレベル（High）を保つものとする。
【００５３】
Safe sample period内の高速通信プロトコルには調歩同期式通信を採用する。
図６は、調歩同期式通信のプロトコルの例を示す図である。
【００５４】
40bitの情報は、4Byteのデータ（３７）、1bitのStart Bit（３６）と奇数パリティビット（３８）2bitのAuxiliaryデータ（３９）、4bitのACK（４０）で構成されている。
図６のデータ例1では4ByteのデータはByte0=0x8d,Byte1=0x46,Byte2=0xa0,Byte3=0xd2となり、データ例2ではByte0=0x01,Byte1=0x13,Byte2=0x85,Byte3=0xffとなり、電気信号でハイ（High）となっているbitがLogical １を表し、ロー（Low）となっているbitがLogical 0を表す。
ACKは通常のプロトコル同様にもData Blockの最後にも出力されるが高速転送時はData Blockの最後のACKビットは無視して、Data Block内の4bitのACKを利用する。Auxiliaryデータは補助情報として早期ＥＯＭや送受信チェンジを実現する。
【００５５】
早期ＥＯＭと送受信チェンジは転送効率を向上させるために必要な手段である。ＣＥＣのプロトコルに準拠して1Frameの通信を完了させるためには、最小で1つのData Blockが必要であり、2.4msec×10bit＝24msecの帯域占有が発生する。
これに対して、高速通信でData Block中の1bitの期間で情報の伝送が終わってしまった場合、残り7bitの期間、空転送が発生しFrameが終了するのでは効率がよくない。そのために早期ＥＯＭを使用して、Data Blockの1bit目でもACKを即座に取得するようにする。  ただし、転送が終わってもＣＥＣバス上の帯域占有自体は発生しているため、次のFrameを送信する場合は待たされることに注意が必要であり、一度通信が途切れると、次の転送まではSignal Free Timeによる送信禁止帯が付加される。
これでは短いメッセージの交換においては、Frameの長さが変わらないのでトータルの占有帯域は通常のプロトコルと変わらない。
そのため、送受信チェンジの手段も併せ持つことでその問題を回避する。送受信チェンジは、通信中のデバイス間でイニシエータ（Initiator）とフォロワー（Follower）の役割がFrame中に交代することで、最大16 Data Block分の帯域を占有したままデバイス間の通信を続けることができる。
【００５６】
図７は、早期ＥＯＭと送受信チェンジのAuxiliaryビットを使用した通信例を示す図である。
【００５７】
Data Block構成（４１）のフレームワークは変化がないがBit7（４２）からBit2（４３）までがDeviceAがInitiatorでDeviceBがフォロワー（Follower）となり、Bit2に早期EOMと送受信チェンジ=1（４４）が表示されると、Bit1（４５）とBit0（４６）はDeviceBがイニシエータ（Initiator）となり、DeviceAがフォロワー（Follower）となる送受信チェンジを起こす。
【００５８】
また、図８は、早期ＥＯＭだけを使用した場合の通信例を示す図である。
【００５９】
この場合、Data Block構成（４７）のBit2（４８）までで送信するデータが終わった場合、Bit2において、早期ＥＯＭを発行する。
フォロワー（Follower）は早期ＥＯＭを検出すると、Frameの終了と判断して、メッセージオペコードの解析やデータ処理を開始することができる。
イニシエータ（Initiator）は早期ＥＯＭ以降のBit1(４９)Bit0(５０)にSafe sample bitが全てハイ（High）となる無効Bitを送る。
また、この無効Bitを使用して、システムのスループットが転送レートより低い場合のバッファオーバーラン、アンダーランを防ぐことができる。
イニシエータ（Initiator）のシステムが次のBitまでにデータの準備が間に合わないと無効Bitが発生し、受信側はSample TimingまでにStart Bitが発生しない通信を無効Bitであると判断し、このBitを無視して次のBitでの受信を待つ。
受信バッファのオーバーランはACKビットを使用する再送要求で回避する。これにより、ＣＥＣのスループットをシステムスループットにあわせることが可能となる。
【００６０】
また、図４で示したように、ＣＥＣはSignal Free Timeを規定することでDevice間の送信開始タイミングをずらし、アービトレーションロストの低減や一つのDeviceがバス帯域を占有してしまうことを防いでいる。しかしこれらの制限はＣＥＣが１対１で接続している状態では必要がなく、そのような形態でのSignal Free Timeは転送レートを下げる大きな要因となる。
通常のプロトコルでは、Signal Free Timeの制約により前回イニシエータ（Initiator）であったDeviceが次にデータを送信できるのは通信が終わってから19.2msec後になる。
それに対して、フォロワー（Follower）であったDeviceのSignal Free Timeは14.4msecである。Deviceが2つしかない状態とした場合、フォロワー（Follower）はイニシエータ（Initiator）がデータを送りきっていないことをＥＯＭビットやその他の手段で知ることができ、フォロワー（Follower）であったDeviceは次もフォロワー（Follower）になることをコントロールできるので、一つのDeviceが帯域を占有することを防ぐためのSignal Free Timeである19.2msecは確保する必要はない。
【００６１】
図９に、規格上で規定されているSignal Free Timeを遵守しつつ転送効率を上げるための方法を示す。
【００６２】
DeviceA（５１）がDeviceB（５２）に対してデータを送信する場合、DeviceAがイニシエータ（Initiator）（５３）、DeviceBがフォロワー（Follower）（５４）となり、通信を開始する。
START BitやHeader BlockなどはDeciceAからDeviceBへ送られる（５８）。
規格で定められている最大のData Block数16を超えるデータを送信する必要があった場合、イニシエータ（Initiator）(５３)の通信では終わらない。このとき、Data Block16の最後の高速通信で送受信チェンジ=1、早期EOM=0の状態（５９）にしておくと、次の通信はDeviceBがイニシエータ（Initiator）（５７）となり通信が開始する。
この場合は、START BitやHeader BlockはDeviceBからDeviceAへ送られ（６０）、Data Block1からDeviceAからDeviceBへの送信となる（６１）。
こうすることで2回目のDeviceAからDeviceBへの送信はSignal Free Timeは19.2msec（５５）ではなく、14.4msec（５６）を使用することができ、効率よく通信できることが可能となる。
また、ロジカルアドレスのプライオリティと合わせて利用することで、複数のDeviceが接続されている状態で、ある2つのDevice間でバスを占有したい場合にも利用できる。
【００６３】
以上、高速通信プロトコルについて説明した。
次に、通常のＣＥＣとの相互接続について説明する。
【００６４】
［通常のＣＥＣとの相互接続］
また、通常のＣＥＣプロトコルとの互換性を維持するためには、高速転送モードと通常転送モードを切り替えて通信する必要がある。
高速転送が可能なDeviceA、DeviceBの二つのDeviceによるＣＥＣトポロジーであれば、互いのDeviceは常に高速転送状態でもかまわないが、そのトポロジーに通常転送のみ対応のDeviceCが組み込まれた場合、DeviceA-B間の通信は高速通信を行って、DeviceA-C、B-C間では通常の転送を行う必要がある。かつ、マルチマスターシステムであるため、DeviceCからいつ通常転送のメッセージが送られてくるかを知ることができない。
そのため、DeviceA-B間で高速転送を行った後、DeviceCからDeviceAにメッセージが来ても、DeviceAはそのメッセージを高速転送モードのまま取り込むという問題がでてくる。
その問題を回避するために、高速転送Frameのはじめに高速転送モードBitによるネゴシエーションを取る。
【００６５】
図１０は、高速転送モードBitのタイミングダイアグラムを示す図である。
【００６６】
高速転送モードBitは、Data Block構成（６２）の一番初めのBitであるBit7（６３）に埋め込まれて送信される。
高速転送モードBitタイミングダイアグラム（６４）は通常のタイミングダイアグラムとは異なる。
Start event（６５）から0.5msecの期間ロー（Low）を維持し、ファーストリターントーハイ（First Return to High）（６６）から0.5msecの期間ハイ（High）を維持する。
さらにReturn to Low（６７）から0.5msecの期間ロー（Low）を維持し、Second Return to High（６８）でハイ（High）に戻り、2.4msecまでハイ（High）を維持する。
通常転送のDeviceはこのようなデータは送信しない。また、高速転送プロトコルの調歩同期式通信時もAll-0の場合はパリティが１になるように奇数パリティを使用するので、このようなデータは送信しない。
この高速転送モードBitがない転送は通常転送であると判断して、DeviceAは通常転送モードに切り替わって受信をシームレスに行うことができる。
【００６７】
また、この高速転送モードBitを設けることで、万が一通常転送のDeiveCに対して高速転送を試みてしまった場合、DeviceCはハンドシェイクBitを間隔の短すぎる立下りエッジと判定して、確実にエラーハンドリング（Error Handling）を発生させることができ、誤動作させずに通信を中断させることができる。
これは、ＣＥＣのコンプライアンステストにおいて、フォロワー（Follower）はＣＥＣラインの立下りエッジの期間が規定されたタイミング以下の場合であれば、エラーハンドリング（Error Handling）を発生させなければならないと規定されていることに由来する。
そのため、高速モードを持たないどのようなＣＥＣデバイスも短すぎる立下りエッジ間隔の検出によりエラーハンドリング（Error Handling）を確実に発生させることが可能となる。
また、通常のLogical 1のタイミングダイアグラムと比べてReturn to Highの発生箇所が若干違う。これは、立下り検出を確実にするために、ＣＥＣが持たなければならない最低のサンプリング間隔である0.4msec以上の間、ＣＥＣラインをハイ（High）/ロー（Low）に保つためである。
【００６８】
このように高速転送モードBitを設けることで、高速転送Deviceと通常転送Device間での不整合をお互い検出できるようなるが、転送モードを切り替えてリトライするような状態は効率が悪い。
そのため、高速転送Deviceリストをシステム内に確保して、どのDeviceが高速通信可能であるかをあらかじめ登録しておく方法が転送効率の向上に有効である。
そのために、ブロードキャスト（Broadcast）通信を行う方法がある。ブロードキャスト（Broadcast）通信は接続時に自分のアドレスをトポロジー中の全Deviceに一斉に連絡してトポロジーを形成する際などに使用するので、同様に自分が高速通信可能であることもトポロジー内のDeviceに通知可能である。
【００６９】
この発明によって、通常のＣＥＣ機器と互換性を確保しながら高速通信を実現することによりCEC接続のデバイス間で高度な連携が可能となる。
また、ＣＥＣはシンク（Sink）からソース（Source）機器に主体的に情報を発信できる手段であるため、高速ＣＥＣを実現することにより、たとえば図１に示すように、出力装置であるＴＶを入力装置にすることがＨＤＭＩケーブル一本で可能となる。
たとえば、現状のタッチパネルモニタには、ＡＶ入力のほかにタッチパネル情報を出力するＲＳ２３２ＣケーブルやＵＳＢインタフェースが付属している。これがHDMIケーブルだけで実現できる。
このように本実施形態により、ＴＶの高付加価値化と、ＴＶを中心とした機器間の連携動作の幅を格段に広げることができる。
【図面の簡単な説明】
【００７０】
【図１】本発明の実施形態に係る通信方法を適用した通信システムの構成例を示す図である。
【図２】通常のＣＥＣのプロトコルを示す図である。
【図３】通常のＣＥＣプロトコルのHeader Block構成を示す図である。
【図４】ＣＥＣのアービトレーション方法とシグナルフリータイム（Signal Free Time）について示す図である。
【図５】高速通信のＣＥＣプロトコルを示す図である。
【図６】調歩同期式通信のプロトコルの例を示す図である。
【図７】早期ＥＯＭと送受信チェンジのAuxiliaryビットを使用した通信例を示す図である。
【図８】早期ＥＯＭだけを使用した場合の通信例を示す図である。
【図９】規格上で規定されているSignal Free Timeを遵守しつつ転送効率を上げるための方法を示す図である。
【図１０】高速転送モードBitのタイミングダイアグラムを示す図である。
【符号の説明】
【００７１】
１００・・・通信システム、１１０・・・ＴＶ、１１１・・・表示部、１１２・・・表示切替回路、１１３・・・システム制御部、１１４・・・リモートコントロール（リモコン）信号受信部、１１５・・・ユーザーインタフェース（Ｉ／Ｆ）、１１６・・・メモリ、１１７・・・ＣＥＣデバイス、１１８，１１９・・・ＨＤＭＩレシーバ、１２０・・・チューナ、１３０・・・ＨＤＤレコーダ、１３１・・・ＣＥＣデバイス、１３２・・・ＨＤＭＩトランスミッタ（Tx）、１３３・・・システム制御部、１３４・・・メモリ、１３５・・・ＨＤＤ、１３６・・・リモコン信号受信部、１４０・・・ＨＤＤレコーダ、１４１・・・ＣＥＣデバイス、１４２・・・ＨＤＭＩトランスミッタ（Tx）、１４３・・・システム制御部、１４４・・・メモリ、１４５・・・ＨＤＤ、１４６・・・リモコン信号受信部。
【図１】
2009159061.tif 000003
【図２】
2009159061.tif 000004
【図３】
2009159061.tif 000005
【図４】
2009159061.tif 000006
【図５】
2009159061.tif 000007
【図６】
2009159061.tif 000008
【図７】
2009159061.tif 000009
【図８】
2009159061.tif 000010
【図９】
2009159061.tif 000011
【図１０】
2009159061.tif 000012