(57)【特許請求の範囲】
【請求項１】
複数の機器が接続されたバスシステムにおいて、前記バスシステムにデータを送信しようとする送信機が前記バスシステムに接続された他の機器に、前記機器内の一つまたは複数の各入力プラグに対するデータ受信の可否の状態を問い合わせ、前記問い合わせを受けた機器は、前記各入力プラグのデータ受信可否の状態に応じて前記送信機に受信状態情報を送出し、
前記送信機は前記受信状態情報に応じて前記機器内の前記各入力プラグのうちのいずれかとの間に伝送路を確立する事を特徴とする伝送管理方法。
【請求項２】
受信状態情報は前記機器内の前記各入力プラグに対するデータ受信の可否状態や可否状態の状態変化を示すことを特徴とする請求項１記載の伝送管理方法。
【請求項３】
送信機が、受信状態情報を受けると、自分自身がデータの送信が可能な状態か否かを調べ、送信できる状態であるならば、前記受信状態情報を送信してきた機器の前記各入力プラグのうちのいずれかとの間にデータ伝送路を確立する事を特徴とする請求項１または２記載の伝送管理方法。
【請求項４】
受信状態情報を送出した機器は、送信機がデータを送出しているかを確認し、データを送出しているなら前記送信機との間にデータ伝送路を確立することを特徴とする請求項１または２記載の伝送管理方法。
【請求項５】
送信機が特定の形式のデータに対する受信の可否の状態を問い合わせることを特徴とする請求項１または２記載の伝送管理方法。
【請求項６】
複数の機器が接続されたバスシステムにおいて、前記バスシステムからデータを受信しようとする受信機が前記バスシステムに接続された他の機器に、前記機器内の一つまたは複数の各出力プラグに対するデータ送信の可否の状態を問い合わせ、
前記問い合わせを受けた機器は、前記各出力プラグのデータ送信可否の状態に応じて前記受信機に送信状態情報を送出し、
前記受信機は前記送信状態情報に応じて前記各出力プラグのうちのいずれかとの間に伝送路を確立する事を特徴とする伝送管理方法。
【請求項７】
送信状態情報は前記各出力プラグのデータ送信の可否状態や可否状態の状態変化を示すことを特徴とする請求項６記載の伝送管理方法。
【請求項８】
受信機が、送信状態情報を受けると、自分自身が受信可能な状態か否かを調べ、受信できる状態であるならば、前記送信状態情報を送信してきた機器の前記各出力プラグのいずれかとの間にデータ伝送路を確立する事を特徴とする請求項６または７記載の伝送管理方法。
【請求項９】
受信機は特定の形式のデータに対する前記各出力プラグの送信の可否の状態を問い合わせることを特徴とする請求項６または７記載の伝送管理方法。
【請求項１０】
複数の機器が接続されたバスシステムにおいて、第３の機器が前記バスシステムに接続された第１の機器に、前記第1の機器内の一つまたは複数の各出力プラグに対するデータ送信の可否の状態を問い合わせ、また第2の機器に、前記第２の機器内の一つまたは複数の各入力プラグに対するデータ受信の可否の状態を問い合わせ、
前記問い合わせを受けた前記第１の機器は、前記第１の機器内の各出力プラグに対するデータ送信の可否の状態に応じて前記第３の機器に送信状態情報を送出し、また前記第２の機器は、前記第２の機器内の各入力プラグに対する受信の可否の状態に応じて前記第３の機器に受信状態情報を送出し、
前記第３の機器は前記送信状態情報および前記受信状態情報に応じて、前記第1の機器と前記第２の機器の間にデータ伝送路の切断または確立を行う事を特徴とする伝送管理方法。
【請求項１１】
受信状態情報は前記第２の機器内の各入力プラグに対するデータ受信の可否状態や可否状態の状態変化を示し、送信状態情報は前記第１の機器内の各出力プラグに対するデータ送信の可否状態や可否状態の状態変化を示すことを特徴とする請求項１０記載の伝送管理方法。
【請求項１２】
第３の機器は特定の形式のデータに対する送信および受信の可否の状態を問い合わせることを特徴とする請求項１０もしくは１１記載の伝送管理方法。
【請求項１３】
第３の機器が、送信準備済みである旨を示す送信状態情報を受信準備済みである旨を示す受信状態情報より先に受け取った場合、前記送信状態情報を送信した機器がまだ送信準備済みの状態であることを、通信路を確立する前に確認する事を特徴とする請求項１０記載の伝送管理方法。
【請求項１４】
第３の機器が受信準備済みである旨を示す受信状態情報を送信準備済みである旨を示す送信状態情報より先に受け取った場合、前記受信状態情報を送信した機器がまだ受信準備済みの状態であることを、通信路を確立する前に確認する事を特徴とする請求項１０記載の伝送管理方法。
【請求項１５】
バスシステムがＩＥＥＥ１３９４であることを特徴とする請求項１から１４のいずれかに記載の伝送管理方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、複数の機器が接続されたバスシステムにおける伝送管理方法に関するものである。
【０００２】
【従来の技術】
ＭＰＥＧ２のトランスポートパケット（ＴＳパケット）やＤＶデータのような映像・音声データのリアルタイム伝送に適したネットワークとしてＩＥＥＥ１３９４と呼ばれるディジタルインターフェースが提案されている。ＩＥＥＥ１３９４はシリアルの高速バスシステムで、データをアイソクロノス（Ｉｓｏｃｈｒｏｎｏｕｓ）伝送と呼ばれる形式で同期伝送できるため、リアルタイム伝送が可能である。さらに、アイソクロノス伝送と並行して非同期のアシンクロナス（Ａｓｙｎｃｈｒｏｎｏｕｓ）伝送を行う事ができる。
【０００３】
ＩＥＥＥ１３９４では、１つのローカルバスに最大６３台までの機器が接続できる。各機器は電源が入ったままの状態でケーブルの抜き差しを行う事が可能であり、機器が追加または削除された時点で自動的に接続された機器を認識してネットワークの再構成を行う事ができる。
【０００４】
ＩＥＥＥ１３９４は、多くのディジタル映像・音声機器に外部用インタフェースとして搭載することができる。ＩＥＥＥ１３９４およびその上でのＡＶデータ伝送規格であるＡＶプロトコル（ＩＥＣ６１８８３規格：Ｓｐｅｃｉｆｉｃａｔｉｏｎｓ  ｏｆ  Ｄｉｇｉｔａｌ  Ｉｎｔｅｒｆａｃｅ  ｆｏｒ  ｃｏｎｓｕｍｅｒ  Ｅｌｅｃｔｒｏｎｉｃ  Ｅｑｕｉｐｍｅｎｔ）を用いることにより、例えば２台のＤＶ間でのデータ伝送、ディジタルダビングを行うことができる。またＡＶプロトコル以外の規定として、Ａｓｙｎｃｈｒｏｎｏｕｓ伝送を用いて、ＡＶ機器にＰｌａｙ，Ｓｔｏｐといった機器の制御コマンドを送るためのＡＶ／ＣＤｉｇｉｔａｌ  Ｉｎｔｅｒｆａｃｅｃｏｍｍａｎｄ  Ｓｅｔや、Ａｓｙｎｃｈｒｏｎｏｕｓ  接続と呼ばれるデータ伝送方法も規定されている。
【０００５】
１３９４では１つのコネクタを介して複数チャンネルのＡＶ信号の入出力が可能である。また、１つのコネクタで信号の入力と出力が可能である。ＡＶプロトコルでは１チャンネルの入力あるいは出力が可能な仮想的なコネクタとしてプラグが定めてある。プラグは入力用と出力用が有り、１つの入力プラグが１つのチャンネルの入力を行うことができ、１つの出力プラグが１つのチャンネルの出力を行うことができる。従って、同時にｎチャンネルのＩｓｏｃｈｒｏｎｏｕｓパケットを入力出来る機器はｎ個の入力プラグを持ち、同時にｎチャンネルのＩｓｏｃｈｒｏｎｏｕｓパケットを出力出来る機器はｎ個の出力プラグを持つことになる。
【０００６】
これらのプラグに対して、扱うチャンネルナンバーを指定したり動作のＯＮ／ＯＦＦを指定するためのレジスタ（ＰＣＲ：Ｐｌｕｇ  ｃｏｎｔｒｏｌ  ｒｅｇｉｓｔｅｒ）が定義してある。ＰＣＲには入力用のｉＰＣＲと出力用のｏＰＣＲの２種類が存在する。ＰＣＲは１３９４のアドレス空間に位置するので、Ａｓｙｎｃｈｒｏｎｏｕｓパケットを用いて直接読み出したりあるいは値を変更したりすることが出来る。即ち、信号の入出力制御を行うのに特別な制御コマンドは必要なく、ＰＣＲをハードウェアで実現することも可能である。
【０００７】
このＰＣＲを利用して、機器間の信号接続を行うのがＡＶプロトコルにおけるＣｏｎｎｅｃｔｉｏｎ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｃｅｄｕｒｅ（ＣＭＰ）である。ＣＭＰでは  １）ｂｒｏａｄｃａｓｔ  ｏｕｔ接続、  ２）ｂｒｏａｄｃａｓｔ  ｉｎ接続、  ３）Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ（ｐ−ｔｏ−ｐ）接続の３種類の信号接続手法を提供している。これらの概念を図４に示す。図４は、図１０のようにＩＥＥＥ１３９４バスにより接続されたカムコーダ０、ＶＴＲ１、ＶＴＲ２、ＳＴＢ（Ｓｅｔ  Ｔｏｐ  Ｂｏｘ：衛星放送受信機）３、モニタ４、コントローラ５から構成されたバスシステムにおけるプラグの例を記述したものである。
【０００８】
ｂｒｏａｄｃａｓｔ  ｏｕｔ接続は出力プラグと１つのチャンネルとの間の接続である。図４（１）ではカムコーダ０が６３チャンネルにｂｒｏａｄｃａｓｔｏｕｔ接続を張っている。６３チャンネルとモニタ４の間にはｂｒｏａｄｃａｓｔ  ｉｎ接続が張られている。即ち、チャンネルという媒体を介して、カムコーダ０が出力したデータはモニタ４に入力されている。
【０００９】
ｂｒｏａｄｃａｓｔ  ｏｕｔ接続は他の機器によって切断することが可能である。例えば、ユーザーがＶＴＲ２のＰＬＡＹボタンを押した場合、ＶＴＲ２はカムコーダ０が行っているｂｒｏａｄｃａｓｔ  ｏｕｔ接続を切断し、自分自身がｂｒｏａｄｃａｓｔ  ｏｕｔ接続をチャンネル６３の間に張るといったアプリケーションを実現することが出来る。この場合、モニタ４はチャンネル６３のｂｒｏａｄｃａｓｔ  ｉｎ接続を継続している為、表示される画面は自動的にＶＴＲ２からの映像に切り替わる。
【００１０】
ＶＴＲ２は自分が出力しようとしている６３チャンネルに他の機器（カムコーダ０）が出力している事を検出し、出力機器のｏＰＣＲを読み出す。さらに、６３チャンネルがｂｒｏａｄｃａｓｔ  ｏｕｔ接続のみに使用されていることを知り、この接続をｏＰＣＲの値を書き換えることによって切断する。
【００１１】
この結果カムコーダ０は６３チャンネル上へのＩｓｏｃｈｒｏｎｏｕｓパケットの出力を停止するので、ＶＴＲ２は６３チャンネルと自身の間にｂｒｏａｄｃａｓｔ  ｏｕｔ接続を張る事が出来る。
【００１２】
特定の２つの機器間で保護された信号接続を行いたい場合には、ｐ−ｔｏ−ｐ接続を使用する。図４ではチャンネル６１を使用してＳＴＢ３からＶＴＲ１へのｐ−ｔｏ−ｐ接続が張られている。ｐ−ｔｏ−ｐ接続はそれを張った機器しか切断させることが出来ない１対１の接続である。ｐ−ｔｏ−ｐ接続は、出力機器、入力機器だけでなく、第３者の機器が張る事も可能である。例えば、コントローラ５が再生側のＶＴＲと記録側のＶＴＲ間にｐ−ｔｏ−ｐ接続を張る事も可能である。また、ｐ−ｔｏ−ｐ接続は１つの出力プラグに対して複数存在することもできる（オーバレイ）。同じ入力プラグとの間で２つ以上張ることもできるし、２つ以上の入力プラグとの間で同時に張ることもできる。
【００１３】
【発明が解決しようとする課題】
しかしながら、上述したＣＭＰによる接続管理方法では、以下に示す課題がある。
【００１４】
第一に、ｐ−ｔｏ−ｐは無駄なＩｓｏｃｈｒｏｎｏｕｓ伝送が行われるという可能性がある。具体的には、
１）第３者がｐ−ｔｏ−ｐを張ったとき、送信データがない、すなわちｅｍｐｔｙパケットだけしか送信していない場合にもｐ−ｔｏ−ｐを張りつづけている可能性がある。また、第３者もしくは送信機がｐ−ｔｏ−ｐを張った場合、受信側で受信しているデータを使っていない場合もｐ−ｔｏ−ｐを張りつづけデータを受けつづける可能性がある。Ｉｓｏｃｈｒｏｎｏｕｓ伝送では送信開始の前に帯域を確保し送信が終了すれば帯域を返却する。従って、他の機器が帯域を確保していることにより、Ｉｓｏｃｈｒｏｎｏｕｓ伝送ができない場合が存在する。上記のようにｐ−ｔｏ−ｐ接続では不要な伝送を行っている可能性があり、このために有効な伝送が妨げられることがあるという課題を有していた。
【００１５】
２）送信機もしくは第３者がｐ−ｔｏ−ｐを張っても受信機がそのデータを有効利用してくれるかどうかはわからない。
【００１６】
３）受信機もしくは第３者がｐ−ｔｏ−ｐを張ると、送信機が有効なデータを出してくれるかどうかわからなく結果として無駄な伝送が発生する。
【００１７】
第二に、ｂｒｏａｄｃａｓｔ  ｏｕｔ接続は受信機器を特定しない出力であるため、どの機器も受信していない可能性があり、無駄な出力により他の伝送に使用可能な伝送容量が減るといった課題がある。
【００１８】
第三に、ｂｒｏａｄｃａｓｔ  ｉｎ接続をしたくなった機器がｂｒｏａｄｃａｓｔ  ｏｕｔ接続の準備ができている機器を探し出すことができないという課題がある。
【００１９】
例えば、受信前にデータを送信可能な機器がどれだか分からないため、従来受信機は受けたいデータが流れているか各チャンネルを探す必要があった。
【００２０】
本発明は、上述した従来の伝送管理方法の課題を考慮し、ｐ−ｔｏ−ｐ接続で無駄な伝送をなくすことを第一の目的とするものである。また、受信可能な機器の存在を確認してからｂｒｏａｄｃａｓｔ  ｏｕｔ接続を開始することにより無駄な伝送をなくすことを第二の目的とするものである。さらに、ｂｒｏａｄｃａｓｔ  ｉｎ接続の準備ができた段階でｂｒｏａｄｃａｓｔ  ｏｕｔ接続を開始させることにより、無意味な伝送をなくすことを第三の目的とするものである。
【００２４】
【課題を解決するための手段】
請求項１の本発明は、複数の機器が接続されたバスシステムにおいて、前記バスシステムにデータを送信しようとする送信機が前記バスシステムに接続された他の機器に、前記機器内の一つまたは複数の各入力プラグに対するデータ受信の可否の状態を問い合わせ、前記問い合わせを受けた機器は、前記各入力プラグのデータ受信可否の状態に応じて前記送信機に受信状態情報を送出し、前記送信機は前記受信状態情報に応じて前記機器内の前記各入力プラグのうちのいずれかとの間に伝送路を確立する事を特徴とする伝送管理方法である。
【００２５】
また、請求項６の本発明は、複数の機器が接続されたバスシステムにおいて、前記バスシステムからデータを受信しようとする受信機が前記バスシステムに接続された他の機器に、前記機器内の一つまたは複数の各出力プラグに対するデータ送信の可否の状態を問い合わせ、前記問い合わせを受けた機器は、前記各出力プラグのデータ送信可否の状態に応じて前記受信機に送信状態情報を送出し、前記受信機は前記送信状態情報に応じて前記各出力プラグのうちのいずれかとの間に伝送路を確立する事を特徴とする伝送管理方法である。
【００２６】
また、請求項１０の本発明は、複数の機器が接続されたバスシステムにおいて、第３の機器が前記バスシステムに接続された第１の機器に、前記第1の機器内の一つまたは複数の各出力プラグに対するデータ送信の可否の状態を問い合わせ、また第2の機器に、前記第２の機器内の一つまたは複数の各入力プラグに対するデータ受信の可否の状態を問い合わせ、前記問い合わせを受けた前記第１の機器は、前記第１の機器内の各出力プラグに対するデータ送信の可否の状態に応じて前記第３の機器に送信状態情報を送出し、また前記第２の機器は、前記第２の機器内の各入力プラグに対する受信の可否の状態に応じて前記第３の機器に受信状態情報を送出し、前記第３の機器は前記送信状態情報および前記受信状態情報に応じて、前記第1の機器と前記第２の機器の間にデータ伝送路の切断または確立を行う事を特徴とする伝送管理方法である。
【００２７】
【発明の実施の形態】
以下に、本発明の実施の形態を図面を参照して説明する。本発明の実施の形態では、従来例と同様に、図４に示されたＩＥＥＥ１３９４バスにより接続されたバスシステムに適用した場合を考える。
【００２８】
（第１の実施の形態）
以下に、本発明の第１の実施の形態における、ＡＶデータを送信しようとする送信機、ここではカムコーダ０がそのデータを受信する機器を探す際の流れを図１のフローチャートを用いて説明する。
【００２９】
まずステップ１として、送信機は、各機器に対してＰＬＵＧ＿ＩＮＦＯ  ｓｔａｔｕｓコマンドを用いて相手の機器の入力プラグ数を問い合わせる。ＰＬＵＧ＿ＩＮＦＯ  ｓｔａｔｕｓコマンドは１３９４ＴｒａｄｅＡｓｓｏｃｉａｔｉｏｎの「ＡＶ／Ｃ  Ｄｉｇｉｔａｌ  Ｉｎｔｅｒｆａｃｅ  Ｃｏｍｍａｎｄ  Ｓｅｔ  Ｇｅｎｅｒａｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｖｅｒ．３．０  Ａｐｒｉｌ  １５，１９９８」で規定されているコマンドの一つで、相手の機器の入出力プラグ数を問い合わせるものである。図５にコマンドの内容を示す。送信機がシリアルバス出力プラグから送信しようとしている場合には、図５（１）のコマンドを送信して相手のシリアルバス入力プラグ数を調べる。
【００３０】
図５（１）のコマンドを受け取った相手の機器は、図５（２）に示される形式でレスポンスを返す。図５（２）のレスポンスにおいてＳｅｒｉａｌ＿ｂｕｓ＿ｉｎｐｕｔ＿ｐｌｕｇｓフィールドはＩｓｏｃｈｒｏｎｏｕｓ入力プラグの数を、Ｓｅｒｉａｌ＿ｂｕｓ＿ｏｕｔｐｕｔ＿ｐｌｕｇｓフィールドはＩｓｏｃｈｒｏｎｏｕｓ出力プラグの数を、Ｅｘｔｅｒｎａｌ＿ｉｎｐｕｔ＿ｐｌｕｇｓフィールドは外部（アナログ）入力プラグの数を、Ｅｘｔｅｒｎａｌ＿ｏｕｔｐｕｔ＿ｐｌｕｇｓフィールドは外部（アナログ）出力プラグの数をそれぞれ示す。
【００３１】
相手の機器に入力プラグがある場合にはステップ２に進み、次にＩＮＰＵＴ＿ＰＬＵＧ＿ＳＩＧＮＡＬ＿ＦＯＲＭＡＴ  ｉｎｑｕｉｒｙコマンドを用いて各入力プラグが自分の出したい信号を受信する能力があるかどうかを問い合わせる。ＩＮＰＵＴ＿ＰＬＵＧ＿ＳＩＧＮＡＬ＿ＦＯＲＭＡＴ  ｉｎｑｕｉｒｙコマンドもＡＶ／Ｃコマンドセットにすでに規定されているものである。この形式を図６（１）に示す。相手の機器においてｐｌｕｇフィールドに記述された番号のプラグに対し、ｆｍｔ、ｆｄｆの２つのフィールドによって規定された信号形式、例えばカムコーダ０がデータを出力しようとする際に、「ＮＴＳＣ（５２５／６０）対応のＤＶデータ」を入力する能力を持つか否かを問い合わせる。機器中のどのプラグも送信機が出そうとしているデータを入力する能力がなければ（レスポンスが”ＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤ”であれば）、その機器は受信不可能なので次の機器にステップ１から再度問い合わせていく。
【００３２】
出そうとしているデータを入力する能力を持つ入力プラグが存在する場合にはステップ３に進み、そのプラグが現在入力を要求しているかを問い合わせる。問い合わせる方法の具体例として、図７にＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨ  Ｓｔａｔｕｓ／Ｉｎｑｕｉｒｙコマンドの案を示す。ＡＶ／Ｃコマンドの形式に合わせ、かつ汎用的に使用するために、図に示すような階層構造とした。
【００３３】
図７（１）に示すように、ＡＶ／ＣコマンドにＦＬＯＷ＿ＭＡＮＡＧＥＭＥＮＴというコマンドを新たに定義する。ＦＬＯＷ＿ＭＡＮＡＧＥＭＥＮＴコマンドはｃａｔｅｇｏｒｙフィールドの値に応じて複数の内容を持てるようにする。ｃａｔｅｇｏｒｙ＿ｄｅｐｅｎｄｅｎｔフィールドはｃａｔｅｇｏｒｙフィールドの値に応じて大きさや具体的定義を設定できるようにする。
【００３４】
図７（２）に示すようにｃａｔｅｇｏｒｙフィールドが００であるとき、ＦＬＯＷ＿ＭＡＮＡＧＥＭＥＮＴコマンドはＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨコマンドという内容を持つ。問い合わせに対する答えが相手によって書きこまれるべきフィールド、すなわち後述するｉｐＮ、ｏｐＮ、ｉ＿ｓｉｇ、ｏ＿ｓｉｇの各フィールドには１を入れてコマンドを送る。
【００３５】
本実施の形態においてＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨコマンドはＮｏｔｉｆｙコマンドの形式とＳｔａｔｕｓコマンドの形式の両方で使うことが可能である。Ｓｔａｔｕｓコマンドの形式であればコマンドを受け取った機器はその時点の状態を返すだけである。Ｎｏｔｉｆｙコマンドの形式であれば、コマンドを受けた機器は、このコマンドを受信したときに現在の状態をレスポンスとして返し、かつ、その後状態の変化が発生したときに再度レスポンスを返す。ＳｔａｔｕｓコマンドとＮｏｔｉｆｙコマンドはＡＶ／Ｃコマンドの先頭５ｂｉｔ目から８ｂｉｔ目までのｃｔｙｐｅと呼ばれる４ｂｉｔの値により区別されその他の値は同一である。
【００３６】
図７（３）のレスポンスにおいて、ｉｐＮ（Ｎ＝００，０１，．．．．３０）の各ビットを接続要求ビットと呼び、この値が０のとき「番号Ｎのプラグは入力を要求していない」ことを示し、１のとき「番号Ｎのプラグは入力を要求している」ことを示すものとする。上記ビットは、実際に入出力を行っているかどうかとは無関係である。例えば入力の要求があっても実際に入力している場合としていない場合がある。また、ｉ＿ｓｉｇは０のとき「どの入力プラグも扱う信号形式が以前と変わっていない」ことを示し、１のとき「どれかの入力プラグで扱う信号形式が以前から変わったか」を示す。ここで扱う信号形式とはｆｍｔ、ｆｄｆの２つのフィールドなどによって規定されたＤＶ、ＭＰＥＧ２−ＴＳ、Ａｕｄｉｏデータなどの信号形式を示す。このビットはＳｔａｔｕｓコマンドのレスポンスと、Ｎｏｔｉｆｙコマンドの最初のレスポンスでは常に０である。
【００３７】
このレスポンスの値から、どのプラグが入力要求しているかがわかる。またＮｏｔｉｆｙコマンドとして送信する事により、各プラグの入力要求状況もしくは各プラグが入力できる信号形式が変更された場合にレスポンスとして返される。カムコーダを例にとると、カメラ撮影モードではiｐ００＝０に、テープ再生モードのうちPLAY/CUE/Review中はｉｐ００＝０となる。一方Ｓｔｏｐ、ＦＦ、ＲＥＷ中はＩｓｏｃｈｒｏｎｏｕｓパケットの受信が可能なのでｉｐ００＝１になる。ＲＥＣ Pauseの場合にもｉｐ００＝１になる。ＶＴＲでは、テープ再生モードのうちPLAY/CUE/Review中はｉｐ００＝０となる。一方Ｓｔｏｐ、ＦＦ、ＲＥＷ中はＩｓｏｃｈｒｏｎｏｕｓパケットの受信が可能なのでｉｐ００＝１になる。ＲＥＣ Pauseの場合にもｉｐ００＝１になる。すでに他のデータをテープ録画中の時はｉｐ０１＝０になる。ＳＴＢでは、番組データ出力中はｉｐ０３＝０に、外部からのデータをデコード出力しようとしている時はｉｐ０３＝１となる。モニタの場合、内部チューナからの番組表示中の時はｉｐ０４＝０に、他機器からの番組データをすでに入力表示中の時はｉｐ０４＝０になる。外部からのデータをデコード出力しようとしている時はｉｐ０４＝１となる。
【００３８】
また、モニタの内部デコーダをＤＶからＭＰＥＧデコード用に切り替えた場合などでは、Ｎｏｔｉｆｙコマンドを受けていたモニタはｉ＿ｓｉｇフラグを１にしてレスポンスを返す。
【００３９】
入力要求している入力プラグが存在する場合にはステップ４に進み、入力要求しているプラグが別機器からの信号を入力中か否かをそのプラグのｉＰＣＲを読み取る事により判定する。他の機器から入力している場合には、次の入力要求しているプラグをステップ２から調べる。それ以上入力要求しているプラグが無い場合には、次の機器をステップ１から順次調べる。
【００４０】
入力プラグが入力要求しておりかつ他の機器から入力していない場合にはステップ５に進み、送信機はＩＮＰＵＴ＿ＰＬＵＧ＿ＳＩＧＮＡＬ＿ＦＯＲＭＡＴ  ｃｏｎｔｒｏｌコマンドを相手の機器に送り、入力プラグの扱う信号形式を自分が出そうとしている信号形式に変えさせる。
【００４１】
コマンドを受けて入力プラグの信号形式が変わった場合には他の機器から入力していない場合には、入力準備ができたとしてステップ６に進む。上記入力プラグの信号形式を変えようとする等の手続きは、受信側の状況によっては期待通りに変わってくれない場合もありえる。その場合にはＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨｎｏｔｉｆｙコマンドを送って扱う信号形式が変わるのを待つか、あるいは次のプラグに対してステップ２から、または次の機器に対してステップ１から処理を再開する。
【００４２】
例えば、カムコーダがＤＶ形式のデータを出力しようとしているが、モニタがＭＰＥＧ信号を受信要求中であった場合、このままではデータを有効に受け付けてくれないので出せない。ＤＶからモニタにＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨ  ｎｏｔｉｆｙコマンドを送信すると、まず、ｉｐ００−３０が各プラグの状態を示しｉ−ｓｉｇフラグが０のレスポンスが返される。その後、内部デコーダの接続状況が変わるなどしてＤＶ入力待ちになった場合、ｉ−ｓｉｇフラグを１にしたレスポンスを返す。このレスポンスを受けたカムコーダはモニタの各プラグの信号形式を確認して接続を確立し、データを送信する。
【００４３】
ステップ６として、送信機は入力準備ができた機器のプラグと送信機の送信しようとするプラグの間にｐ−ｔｏ−ｐ接続を張ることにより伝送路を確立するとともにデータを出力し始める。なお、ＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨコマンドは「接続を確立したら有効なデータを出力できる」ことや、「入力したデータは無駄にしないで使う」ことを知らせるコマンドであるから、内部接続を変更してやる必要は無い。
【００４４】
全ての機器における全ての入力プラグが、信号形式に対応していない、入力を要求していない、他の機器からの信号を入力中であるなどの理由で受信ができないようなら、データの送信を行っても受信する機器がおらず無駄な送信となるため、送信機はデータの送信を行わない。必要に応じＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨＮｏｔｉｆｙコマンドを送ることにより、他の機器からの信号を受け取っている機器や入力要求していないプラグの状態を見守るなどの処理を引き続き行う。
【００４５】
次にデータ送信または受信の必要が無くなった際に、上記手順により確立した伝送路を切りデータ出力を停止する場合の手順について述べる。本実施の形態では送信機がｐ−ｔｏ−ｐ接続を張ったので、ｐ−ｔｏ−ｐ接続を切断することができるのは送信機だけである。このため、送信機がデータ送信の必要がなくなった場合には、単に送信機がｐ−ｔｏ−ｐ接続を切断すればよい。受信機はデータが来なくなったことを検出して停止するなどの処理を行う事になる。
【００４６】
一方、受信機がデータ受信を止めたい場合、送信機により張られたｐ−ｔｏ−ｐ接続を直接切断する事はできないので、送信機にデータ受信の必要が無くなったことを知らせて送信機にｐ−ｔｏ−ｐ接続を切断させる必要がある。このために、先に説明したＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨ  Ｎｏｔｉｆｙコマンドを用いる。すなわち、データ伝送が開始すると、送信機は再度受信機に対してＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨ  Ｎｏｔｉｆｙコマンドを送る。これにより、受信機は受信しているプラグの入力要求が無くなった時点で、そのプラグに対応したｉｐＮのビットを０にして最終レスポンスを返す。あるいは入力要求は継続しているが受信機が受信している信号形式を変更する時点で、そのプラグに対応したｉ＿ｓｉｇビットを１にして最終レスポンスを返す。送信機は、ｉｐＮビットが０になったレスポンスを受け取ると受信しているプラグが現在のデータ伝送に使われ無くなった事がわかるので、そのプラグとのｐ−ｔｏ−ｐ接続を切断する。送信機は、ｐ−ｔｏ−ｐ接続を張って受信している機器が全て無くなると送信を止めるなどの処理を行う事になる。
【００４７】
ｉ＿ｓｉｇビットが１になった場合、送信機は自分が張ったｐ−ｔｏ−ｐのプラグの信号フォーマットが変わったかどうかをＩＮＰＵＴ＿ＰＬＵＧ＿ＳＩＧＮＡＬ＿ＦＯＲＭＡＴ  ｓｔａｔｕｓコマンドを送ってチェックし、変わっていればそのプラグとのｐ−ｔｏ−ｐ接続を切断する。変わっていなければｐ−ｔｏ−ｐ接続を継続する。
【００４８】
（第２の実施の形態）
次に、本発明の第２の実施の形態を説明する。第１の実施の形態と異なる点は、ｐ−ｔｏ−ｐ接続でなくｂｒｏａｄｃａｓｔ接続により伝送路を確立する点である。ステップ１からステップ５までの動作は第１の実施の形態と同様であるのでその説明は省略する。
【００４９】
ｐ−ｔｏ−ｐ接続は、ｐ−ｔｏ−ｐ接続を確立しようとする機器が、チャンネルや帯域などのリソースを確保し、図９（１）（２）に示すｉＰＣＲフォーマット、ｏＰＣＲフォーマットにおいて、ｃｈａｎｎｅｌやｄａｔａ  ｒａｔｅ、ｏｖｅｒｈｅａｄ−ＩＤをセットし、ｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔ  ｃｏｎｎｅｃｔｉｏｎ  ｃｏｕｎｔｅｒを０から１に変化させる事により確立する事ができる。ｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔ  ｃｏｎｎｅｃｔｉｏｎ  ｃｏｕｎｔｅｒはさらに同じ機器または別の機器が１ずつ増加させる事によりオーバーレイさせる事もできる。
【００５０】
一方、ｂｒｏａｄｃａｓｔ接続は、チャンネルや帯域などのリソースを確保し、図９（１）（２）に示すｉＰＣＲフォーマット、ｏＰＣＲフォーマットにおいて、ｃｈａｎｎｅｌやｄａｔａ  ｒａｔｅ、ｏｖｅｒｈｅａｄ−ＩＤをセットし、ｂｒｏａｄｃａｓｔ  ｃｏｎｎｅｃｔｉｏｎ  ｃｏｕｎｔｅｒに１を立てる事により確立する事ができる。
【００５１】
ｐ−ｔｏ−ｐは送信機、受信機、第３のノードの誰でもｉＰＣＲ，ｏＰＣＲをルールに従って書きかえることにより確立することができる。これに対してｉＰＣＲ，ｏＰＣＲのｂｒｏａｄｃａｓｔ  ｃｏｎｎｅｃｔｉｏｎ  ｃｏｕｎｔｅｒを１にセットできるのはそのプラグを所有している機器のみである。例えば送信機や第３の機器が受信機のｉＰＣＲのｂｒｏａｄｃａｓｔ  ｃｏｎｎｅｃｔｉｏｎ  ｃｏｕｎｔｅｒに１を書きこむことは禁止されている。即ち、broadcast  in/out接続の確立を外部の機器が行うことはできない。外部の機器がbroadcast  in/out接続の確立を受信機／送信機に依頼するためのＡＶ／Ｃコマンドが既に規定してある。
【００５２】
具体的には、図８に示したＤＩＧＩＴＡＬ＿ＯＵＴＰＵＴ  コマンドにおいてｃｏｎｎｅｃｔｉｏｎ＿ｓｔａｔｅに７０（ｅｓｔａｂｌｉｓｈ）を設定して機器に送ることにより、機器がリソースの確保などのｂｒｏａｄｃａｓｔ  ｏｕｔ接続に必要な操作を行い、ｂｒｏａｄｃａｓｔ  ｏｕｔ接続を確立する。またｂｒｏａｄｃａｓｔ  ｉｎ接続も同様に、図８に示したＤＩＧＩＴＡＬ＿ＩＮＰＵＴ  コマンドにおいてｃｏｎｎｅｃｔｉｏｎ＿ｓｔａｔｅに７０（ｅｓｔａｂｌｉｓｈ）を設定して機器に送ることにより、機器が接続を確立する。
【００５３】
本実施の形態では、図１のステップ６で送信機が自分でリソースの確保を行いｂｒｏａｄｃａｓｔ  ｏｕｔ接続を確立して、チャンネル番号を確認して、そのチャンネル番号を受信ＲＥＡＤＹ状態（データを受信可能であるがまだ実際の受信を行っていない状態をＲＥＡＤＹ状態という）のｉＰＣＲに書きこむ。さらに受信機に対しｃｏｎｎｅｃｔｉｏｎ＿ｓｔａｔｅに７０（ｅｓｔａｂｌｉｓｈ）を設定したＤＩＧＩＴＡＬ＿ＩＮＰＵＴ  コマンドを送りｂｒｏａｄｃａｓｔ  ｉｎ接続を行わせる。このように、ｂｒｏａｄｃａｓｔ  ｉｎ接続とｂｒｏａｄｃａｓｔ  ｏｕｔ接続を同じチャンネルに対して行うことにより、結果として送信機と受信機の間で伝送路が確立される。
【００５４】
次にデータ送信または受信の必要が無くなった際に、上記手順により確立した伝送路を切りデータ入力を停止する場合の手順について述べる。本実施の形態では、ｂｒｏａｄｃａｓｔ接続を行っているので、送信機がデータ送信の必要がなくなった場合には、単に送信機がｂｒｏａｄｃａｓｔ  ｏｕｔ接続を切断しデータ送信を止めればよい。受信機はデータが来なくなったことを検出して停止するなどの処理を行う事になる。
【００５５】
また受信機がデータ受信の必要がなくなった場合にも、単に受信機がｂｒｏａｄｃａｓｔ  ｉｎ接続を切断すればよい。さらに受信機がデータ受信不要になった時点で無駄な送信を止めようとするならば、送信機は受信している機器の有無が検出できないので、例えば送信機に対しｃｏｎｎｅｃｔｉｏｎ＿ｓｔａｔｅに６０（ｂｒｅａｋ）を設定したＤＩＧＩＴＡＬ＿ＯＵＴＰＵＴ  コマンドを送りｂｒｏａｄｃａｓｔ  ｏｕｔ接続を切断させることができる。もちろんｏＰＣＲのｂｒｏａｄｃａｓｔ  ｃｏｎｎｅｃｔｉｏｎ  ｃｏｕｎｔｅｒビットを受信機が０クリアすることによりｂｒｏａｄｃａｓｔ  ｏｕｔ接続を切断しても構わない。また先に説明したＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨ  Ｎｏｔｉｆｙコマンドを送信機が受信機に発行しておき、受信機は送信機にデータ受信の必要が無くなったことを知らせて送信機にデータ送信を止めさせることもできる。ここで、他の機器がｂｒｏａｄｃａｓｔされているチャンネルを受信している可能性があるので、送信機にｂｒｏａｄｃａｓｔ  ｏｕｔ接続を張らせた受信機がデータ送信を止めさせる前に、それぞれの機器のｉＰＣＲを読み、そのチャンネルに対してｂｒｏａｄｃａｓｔ  ｉｎ接続していないかを確認することが望ましい。
【００５６】
以上第１の実施の形態及び第２の実施の形態で説明した手順にしたがって送信機が判定を行い、データ伝送路の確立と切断を行えば、送信前に無駄な送信とならないかを判定する事ができ、必要性がなくなったデータ伝送を停止することができるため、無駄な伝送を回避することが可能となる。
【００５７】
なお、図１に示したフローチャートの各ステップにおいて、入力プラグ数の問い合わせ、信号フォーマットをサポートしているかの問い合わせ、データ入力準備できているかの問い合わせ、別信号入力中かの問い合わせのコマンドは本実施の形態で示したものに限定されるもので無く、同等の内容を問い合わされるものであれば良い。また、図７に示したＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨ  Ｎｏｔｉｆｙコマンドを送るとしたが、これはＳｔａｔｕｓコマンドを繰り返し送ることでも良く、さらに信号形式の指定や問い合わせなども同じコマンド中に含めて一度に送っても良い。例えば、ＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨ  Ｎｏｔｉｆｙコマンドにｆｍｔ、ｆｄｆフィールドを追加定義し、このコマンドを受信した機器はｆｍｔ、ｆｄｆフィールドで指定された信号形式のデータに関する送受信要求を回答するようにすれば良い。この際には要求は継続しても信号形式が変われば、各ポートに対応するビットは０クリアされるのでｉ＿ｓｉｇ、ｏ＿ｓｉｇのビットは規定しなくてもよい。
【００５８】
また、各問い合わせの順序は本発明の実施の形態だけに限定されるものではなく、入れ替わっても良い。
【００５９】
また、第１の実施の形態および第２の実施の形態において、送信機は伝送路を確立するとともにデータを出力し始めるとしたが、この例だけに限定されるものではなく、受信側が伝送路を確立するとしてもよい。
【００６０】
例えば、送信機が受信可能なプラグを見つけると、データを出せるならｂｒｏａｄｃａｓｔ  ｏｕｔでデータを送信し、データ入力要求があると応答した機器が各チャンネルのデータをチェックして、データが送信されればｐ−ｔｏ−ｐ接続を確立して受信し、送信されなければ伝送路を切断するなどの形態を取っても良い。
【００６１】
（第３の実施の形態）
次に、本発明の第３の実施の形態として、ＡＶデータを受信しようとする受信機がそのデータを送信する機器を探す時の流れを図２を用いて説明する。
【００６２】
まずステップ１として、受信機は、各機器に対して、図５（１）のＰＬＵＧ＿ＩＮＦＯ  ｓｔａｔｕｓコマンドを送信し相手の出力プラグ数を問い合わせる。相手の機器に対応する出力プラグが無い場合には次の機器に同様の問い合わせを行う。
【００６３】
相手の機器に対応する出力プラグがある場合にはステップ２に進み、次にＯＵＴＰＵＴ  ＰＬＵＧ＿ＳＩＧＮＡＬ＿ＦＯＲＭＡＴ  ｉｎｑｕｉｒｙコマンドを用いて各出力プラグが自分の受信したい信号フォーマットをサポートしているかを問い合わせる。ＯＵＴＰＵＴ＿ＰＬＵＧ＿ＳＩＧＮＡＬ＿ＦＯＲＭＡＴ  ｉｎｑｕｉｒｙコマンドもＡＶ／Ｃコマンドセットにすでに規定されているものである。この形式を図６（２）に示す。ｆｍｔ、ｆｄｆの２つのフィールドによって規定された信号形式、例えばカムコーダ０がデータを入力しようとする際に、「ＮＴＳＣ（５２５／６０）対応のＤＶデータ」を出力する能力を持つか否かを各プラグに順次問い合わせる。機器中のどのプラグも受信機が受信しようとしているデータを出力する能力がなければ（レスポンスが”ＮＯＴ  ＩＭＰＬＥＭＥＮＴＥＤ”であれば）、その機器は送信不可能なので次の機器にステップ１から再度問い合わせていく。
【００６４】
受信しようとしているデータを出力する能力を持つ出力プラグが存在する場合にはステップ３に進み、次にそのプラグが現在出力可能な状態になっているかを問い合わせる。問い合わせには新設したＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨコマンドを用いる。図７（３）のレスポンスにおいて、接続要求ビットｏｐＮ（Ｎ＝００，０１，．．．３０）の各ビットはこの値が０のとき「第Ｎ番目の出力プラグは出力を要求していない」ことを示し、１のとき「第Ｎ番目の出力プラグは出力を要求している」ことを示すものとする。この値と対応する出力プラグが実際にＩｓｏｃｈｒｏｎｏｕｓパケットの送信を行っているかどうかは無関係である。例えばｏｐ００が１であっても出力プラグ０からデータの出力を行っている場合と行っていない場合がある。
【００６５】
カムコーダを例にとると、カメラ撮影モードではｏｐ００＝１に、テープ再生モードのうちPLAY/CUE/Review中はｏｐ００＝１となる。一方Ｓｔｏｐ、ＦＦ、ＲＥＷ中はＩｓｏｃｈｒｏｎｏｕｓパケットの送信の有無に関わらず有用なデータを出力しないのでｏｐ００＝０になる。テープが入っていない場合にもｏｐ００＝０になる。ＶＴＲでは、テープ再生モードのうちPLAY/CUE/Review中はｏｐ０１＝１となる。一方Ｓｔｏｐ、ＦＦ、ＲＥＷ中はＩｓｏｃｈｒｏｎｏｕｓパケットの送信の有無に関わらず有用なデータを出力しないのでｏｐ０１＝０になる。テープ録画中で出力不可能な時はｏｐ０１＝０になる。ＳＴＢでは、番組データ出力中はｏｐ０３＝１に、番組ガイドなどのメニュー表示中はｏｐ０３＝０となる。モニタの場合、内部チューナからの番組表示中で、その番組データを外部に出力できる場合にはｏｐ０４＝１に、他機器からの番組データ入力表示中で、出力不可能な時はｏｐ０３＝０になる。
【００６６】
また、ｏ＿ｓｉｇの値が０のとき「どの出力プラグも扱う信号形式が以前と変わっていない」ことを示し、１のとき「どれかの出力プラグで扱う信号形式が以前から変わったか」を示す。このビットはＳｔａｔｕｓコマンドのレスポンスと、Ｎｏｔｉｆｙコマンドの最初のレスポンスでは常に０である。
【００６７】
ＭＰＥＧ２−ＴＳ信号とＤＶ信号の両方を扱えるＶＴＲを例に考えると、再生しているテープが途中でＤＶ信号記録部分からＭＰＥＧ２−ＴＳ信号記録部分に変わったときに出力しているデータの信号形式はＤＶからＭＰＥＧ２−ＴＳに変化する。このときＮｏｔｉｆｙコマンドを受け取っていたＶＴＲはｏ＿ｓｉｇを１にしてレスポンスを返す。また同じＤＶ信号でも、ＮＴＳＣ信号からＰＡＬ信号などに信号形式が変わった場合にも同様にｏ＿ｓｉｇを１にしてレスポンスを返す。
【００６８】
以上のレスポンスの値から、どのプラグが出力要求しているかがわかる。またＮｏｔｉｆｙコマンドとして送信する事により、入出力準備状況の変化および各プラグが出力できる信号形式が変更された場合にレスポンスとして返される。出力プラグが所望の信号形式の送信能力を持つにも関わらず出力要求していない場合には、現在の内部のプラグ接続状況などにより送信できる状態に無いと考えられる。例えばチューナーを持たないＶＴＲにテープが装てんされていない場合には能力はあってもデータを送信できる状況には無い。このため、次の出力プラグに対しステップ３から確認する。
【００６９】
出力要求している出力プラグが存在する場合にはステップ４に進み、出力要求しているプラグがすでに信号を出力中か否かをそのプラグのｏＰＣＲを読み取る事により判定する。
【００７０】
すでにデータを出力中である場合には、そのデータが受け取りたい信号形式であるかを判定する。受け取りたい信号形式である場合には出力準備ができたとしてステップ６に進む。受け取りたくない信号形式である場合には受信動作をあきらめる。
【００７１】
出力中で無い場合には、ＯＵＴＰＵＴ＿ＰＬＵＧ＿ＳＩＧＮＡＬ＿ＦＯＲＭＡＴ  ｃｏｎｔｒｏｌコマンドで出力形式を自身が受信可能な形式に変更する。コマンドにより送信機の出力プラグの信号形式が変われば、出力準備ができたとしてステップ６に進む。
【００７２】
上記入力プラグの信号形式を変えようとする等の手続きは、受信側の状況によっては期待通りに変わってくれない場合もありえる。その場合には再度ＯＵＴＰＵＴ＿ＰＬＵＧ＿ＳＩＧＮＡＬ＿ＦＯＲＭＡＴ  ｎｏｔｉｆｙコマンドを送って扱う信号形式が変わるのを待つ、あるいはステップ４から、または次の機器に対してステップ１から処理を再開する。
【００７３】
ステップ６として、受信機はその機器との伝送路をｐ−ｔｏ−ｐ接続により確立し、信号出力しているプラグからデータを入力し始める。なお、ＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨコマンドは「接続を確立したら有効なデータを出力できる」ことや、「入力したデータは無駄にしないで使う」ことを知らせるコマンドであるから、内部接続を変更してやる必要は無い。
【００７４】
全ての機器における全ての出力プラグが、信号形式に対応していない、出力を要求していないなどの理由で受信ができないようなら、データの受信を行おうにも送信する機器がいないため、受信機はデータの受信を行わない。必要に応じＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨ  Ｎｏｔｉｆｙコマンドを継続して送ることにより、他の機器からの信号を受け取っている機器や出力要求していないプラグの状態を見守るなどの処理を引き続き行う。
【００７５】
次にデータ送信または受信の必要が無くなった際に、上記手順により確立した伝送路を切断しデータ入力を停止する場合の手順について述べる。本実施の形態では受信機がｐ−ｔｏ−ｐ接続を張ったので、ｐ−ｔｏ−ｐ接続を切断することができるのは受信機だけである。
【００７６】
このため、受信機がデータ受信の必要がなくなった場合には、単に受信機がｐ−ｔｏ−ｐ接続を切断すればよい。送信機はｐ−ｔｏ−ｐ接続が全て無くなったことを検出して停止するなどの処理を行う事になる。
【００７７】
一方、送信機がデータ受信を止めたい場合、受信機により張られたｐ−ｔｏ−ｐ接続を直接切断する事はできないので、受信機にデータ送信の必要が無くなったことを知らせて受信機にｐ−ｔｏ−ｐ接続を切断させる必要がある。このために、先に説明したＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨ  Ｎｏｔｉｆｙコマンドを用いる。すなわち、データ伝送が開始すると、受信機は再度送信機に対してＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨ  Ｎｏｔｉｆｙコマンドを送る。これにより、送信機は送信しているプラグの出力要求が無くなった時点で、そのプラグに対応したｏｐＮのビットを０にして最終レスポンスを返す。または送信機は送信している信号形式を変更する時点で、ｏ＿ｓｉｇビットを１にして最終レスポンスを返す。
【００７８】
受信機は、レスポンスを受け取ると送信しているプラグが現在のデータ伝送に使われ無くなった事がわかるので、そのプラグとのｐ−ｔｏ−ｐ接続を切断する。送信機は、ｐ−ｔｏ−ｐ接続して受信している機器が全て無くなると送信を止めるなどの処理を行う事になる。ｏ＿ｓｉｇビットが１になった場合、受信機は自分が張ったｐ−ｔｏ−ｐのプラグの信号フォーマットが変わったかどうかをＯＵＴＰＵＴ＿ＰＬＵＧ＿ＳＩＧＮＡＬ＿ＦＯＲＭＡＴ  ｓｔａｔｕｓコマンドを送ってチェックし、変わっていればそのプラグとのｐ−ｔｏ−ｐ接続を切断する。変わっていなければｐ−ｔｏ−ｐ接続を継続する。
【００７９】
（第４の実施の形態）
次に、本発明の第４の実施の形態を説明する。第３の実施の形態と異なる点は、ｐ−ｔｏ−ｐ接続でなくｂｒｏａｄｃａｓｔ接続により伝送路を確立する点である。ステップ１からステップ５までの動作は第３の実施の形態と同様であるのでその説明は省略する。
【００８０】
本実施の形態では、図２のステップ６で受信機が送信機に対しｃｏｎｎｅｃｔｉｏｎ＿ｓｔａｔｅに７０（ｅｓｔａｂｌｉｓｈ）を設定したＤＩＧＩＴＡＬ＿ＯＵＴＰＵＴ  コマンドを送りｂｒｏａｄｃａｓｔ  ｏｕｔ接続を行わせる。この際、チャンネル番号を指定したければｏＭＰＲのＢｒｏａｄｃａｓｔ＿ｃｈａｎｎｅｌ＿Ｂａｓｅフィールドを設定しておく。受信機はデータが送出されているチャンネルを確認してｂｒｏａｄｃａｓｔ  ｉｎ接続を張りデータ受信を開始する。このように、ｂｒｏａｄｃａｓｔ  ｉｎ接続とｂｒｏａｄｃａｓｔ  ｏｕｔ接続を同じチャンネルに対して行うことにより、結果として送信機と受信機の間で伝送路が確立される。
【００８１】
次にデータ送信または受信の必要が無くなった際に、上記手順により確立した伝送路を切りデータ入力を停止する場合の手順について述べる。本実施の形態では、ｂｒｏａｄｃａｓｔ接続を行っているので、送信機がデータ送信の必要がなくなった場合には、単に送信機がｂｒｏａｄｃａｓｔ  ｏｕｔ接続を切断しデータ送信を止めればよい。受信機はデータが来なくなったことを検出して停止するなどの処理を行う事になる。
【００８２】
また受信機がデータ受信の必要がなくなった場合にも、単に受信機がｂｒｏａｄｃａｓｔ  ｉｎ接続を切断すればよい。さらに受信機がデータ受信不要になった時点で無駄な送信を止めようとするならば、送信機は受信している機器の有無が検出できないので、例えば送信機に対しｃｏｎｎｅｃｔｉｏｎ＿ｓｔａｔｅに６０（ｂｒｅａｋ）を設定したＤＩＧＩＴＡＬ＿ＯＵＴＰＵＴ  コマンドを送りｂｒｏａｄｃａｓｔ  ｏｕｔ接続を切断させることができる。もちろんｏＰＣＲのｂｒｏａｄｃａｓｔ  ｃｏｎｎｅｃｔｉｏｎ  ｃｏｕｎｔｅｒビットを受信機が０クリアすることによりｂｒｏａｄｃａｓｔ  ｏｕｔ接続しても構わない。また先に説明したＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨ  Ｎｏｔｉｆｙコマンドを用いて送信機にデータ受信の必要が無くなったことを知らせて送信機にデータ送信を止めさせることもできる。ここで、他の機器がｂｒｏａｄｃａｓｔされているチャンネルを受信している可能性があるので、送信機にｂｒｏａｄｃａｓｔ  ｏｕｔ接続を張らせた受信機がデータ送信を止めさせる前に、それぞれの機器のｉＰＣＲを読み、そのチャンネルに対してｂｒｏａｄｃａｓｔ  ｉｎ接続していないかを確認することが望ましい。
【００８３】
以上第３の実施の形態及び第４の実施の形態で説明した手順にしたがって受信機が判定を行い、データ伝送路の確立と切断を行えば、受信前に無駄な受信とならないかを判定する事ができ、必要性がなくなったデータ伝送を停止することができるため、無駄な伝送を回避することが可能となる。
【００８４】
なお、図２に示したフローチャートにおいて、出力プラグ数の問い合わせ、信号フォーマットをサポートしているかの問い合わせ、データ出力準備できているかの問い合わせ、別信号出力中かの問い合わせのコマンドは本実施の形態で示したものに限定されるもので無く、同等の内容を問い合わされるものであれば良い。また、図７に示したＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨ  Ｎｏｔｉｆｙコマンドを送るとしたが、これはＳｔａｔｕｓコマンドを繰り返し送ることでも良く、さらに信号形式の指定や問い合わせなども同じコマンド中に含めて一度に送っても良い。例えば、ＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨ  Ｎｏｔｉｆｙコマンドにｆｍｔ、ｆｄｆフィールドを追加定義し、このコマンドを受信した機器はｆｍｔ、ｆｄｆフィールドで指定された信号形式のデータに関する送受信要求を回答するようにすれば良い。
【００８５】
この際には要求は継続しても信号形式が変われば、各ポートに対応するビットは０クリアされるのでｉ＿ｓｉｇ、ｏ＿ｓｉｇのビットは規定しなくてもよい。また、各問い合わせの順序は本発明の実施の形態だけに限定されるものではなく、入れ替わっても良い。
【００８６】
なお、第３の実施の形態および第４の実施の形態において、受信機は伝送路を確立するとともにデータを入力し始めるとしたが、この例だけに限定されるものではなく、送信側が伝送路を確立するとしてもよい。
【００８７】
例えば、受信機が送信可能なプラグを見つけると、送信可能な機器にデータ送信を要求し、送信可能な機器が要求に応じて伝送路を確立してデータを送信するなどの形態を取っても良い。
【００８８】
（第５の実施の形態）
次に、本発明の第５の実施の形態として、ＡＶデータの送受信を直接行わない第３の機器がデータを送信できる機器、受信できる機器の存在を確認し、伝送を確認する時の流れを図３を用いて説明する。
【００８９】
まずステップ１として、第３の機器は、各機器に対して、ＰＬＵＧ＿ＩＮＦＯｓｔａｔｕｓコマンドを用いて相手の機器の入力プラグおよび出力プラグ数を問い合わせる。第３の機器がＩｓｏｃｈｒｏｎｏｕｓ伝送を管理しようとしている場合には、図５（１）のコマンドを送信し、相手のシリアルバス入力プラグ数を調べる。対応する入力プラグおよび出力プラグ数が無い場合には次の機器に同様の問い合わせを行う。
【００９０】
対応する入力プラグおよび出力プラグ数がある場合には、ステップ２に進み次にＩＮＰＵＴ＿ＰＬＵＧ＿ＳＩＧＮＡＬ＿ＦＯＲＭＡＴ  ｉｎｑｕｉｒｙコマンドおよびＯＵＴＰＵＴ＿ＰＬＵＧ＿ＳＩＧＮＡＬ＿ＦＯＲＭＡＴ  ｉｎｑｕｉｒｙコマンドを用いて各入力プラグが対象としている信号フォーマットをサポートしているかを問い合わせる。例えば「ＮＴＳＣ（５２５／６０）対応のＤＶデータ」を入力する能力および出力する能力を持つか否かを各機器の各プラグに順次問い合わせる。機器中どのプラグも対象としているデータを入力する能力および出力する能力がなければ（レスポンスが”ＮＯＴ  ＩＭＰＬＥＭＥＮＴＥＤ”であれば）、その機器は送受信不可能なので次の機器にステップ１から再度問い合わせていく。
【００９１】
対象としているデータを入力する能力を持つ入力プラグまたは出力する能力を持つ出力プラグが存在する場合には、ステップ３としてその信号形式の出力と入力可能な機器とプラグの一覧表を作成する。プラグの数に応じて機器内の各プラグに対し同じ操作を繰り返し追加していく。
【００９２】
一覧表が完成すればステップ４に進み、次にそのプラグが現在出力可能な状態になっているかをＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨコマンドを用いて問い合わせる。このレスポンスの値から、どのプラグが出力要求しているかがわかる。またＮｏｔｉｆｙコマンドとして送信する事により、各プラグの出力要求状況および各プラグが出力できる信号形式が変更された場合にレスポンスとして返される。
【００９３】
このレスポンスの値から、どのプラグが出力要求しているかがわかる。またＮｏｔｉｆｙ型のコマンドとして送信する事により、各プラグの出力準備状況および各プラグが出力できる信号形式が変更された場合にレスポンスとして返される。
【００９４】
出力要求している出力プラグが存在する場合にはステップ５に進み、出力要求しているプラグがすでに信号を出力中か否かをそのプラグのｏＰＣＲを読み取る事により判定する。
【００９５】
すでにデータを出力中である場合には、そのデータが受け取りたい信号形式であるかを判定する。受け取りたい信号形式である場合には出力準備ができたとしてステップ１０に進む。そのデータが対象とする信号形式で無い場合、受信機はＯＵＴＰＵＴ＿ＰＬＵＧ＿ＳＩＧＮＡＬ＿ＦＯＲＭＡＴ  ｃｏｎｔｒｏｌコマンドを用いて出力プラグの信号形式を変えようとする。この時、他の機器とｐ−ｔｏ−ｐ接続またはｂｒｏａｄｃａｓｔ接続されていないことを確認するべきである。
【００９６】
コマンドにより送信機の出力プラグの信号形式が変われば出力準備ができたとしてステップ１０に進む。
【００９７】
上記出力プラグの信号形式を変えようとする等の手続きは、受信側の状況によっては期待通りに変わってくれない場合もありえる。その場合には再度ＯＵＴＰＵＴ＿ＰＬＵＧ＿ＳＩＧＮＡＬ＿ＦＯＲＭＡＴ  ｎｏｔｉｆｙコマンドを送って扱う信号形式が変わるのを待つ、あるいは次の機器に対してステップ１から処理を再開する。
【００９８】
出力準備できたプラグが見つかれば次にステップ７に進み、次にそのプラグが現在入力可能な状態になっているかをＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨコマンドを用いて問い合わせる。このレスポンスの値から、どのプラグが入力要求しているかがわかる。またＮｏｔｉｆｙコマンドとして送信する事により、各プラグの入力要求状況および各プラグが入力できる信号形式が変更された場合にレスポンスとして返される。
【００９９】
このレスポンスの値から、どのプラグが入力要求しているかがわかる。またＮｏｔｉｆｙ型のコマンドとして送信する事により、各プラグの入力準備状況および各プラグが入力できる信号形式が変更された場合にレスポンスとして返される。
【０１００】
入力要求している入力プラグが存在する場合にはステップ８に進み、入力要求しているプラグが別機器からの信号を入力中か否かをそのプラグのｉＰＣＲを読み取る事により判定する。他の機器から入力していない場合には、入力準備ができたとしてステップ１０に進む。他の機器から入力している場合には、次の入力要求しているプラグを調べる。それ以上入力要求しているプラグが無い場合には、次の機器をステップ１から順次調べる。
【０１０１】
ステップ１０として、第３の機器は、全部の（または目的に合う）プラグに関する情報を確認し、出力準備できたプラグ、および入力準備できたプラグの間にｐ−ｔｏ−ｐ接続を張ることにより伝送路を確立する。なお、ＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨコマンドは「接続を確立したら有効なデータを出力できる」ことや、「入力したデータは無駄にしないで使う」ことを知らせるコマンドであるから、内部接続を変更してやる必要は無い。
【０１０２】
全ての機器における全ての入力プラグおよび出力プラグが、信号形式に対応していない、入出力を要求していない、他の信号を入出力中であるなどの理由で送受信ができないようなら、第３の機器は伝送路の設定を行わない。必要に応じＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨ  Ｎｏｔｉｆｙコマンドを継続して送ることにより、他の機器からの信号をすでに入出力している機器や入出力要求していないプラグの状態を見守るなどの処理を引き続き行う。
【０１０３】
次にデータ送信または受信の必要が無くなった際に、上記手順により確立した伝送路を切りデータ出力を停止する場合の手順について述べる。本実施の形態では第３の機器がｐ−ｔｏ−ｐ接続を張ったので、ｐ−ｔｏ−ｐ接続を切断することができるのは第３の機器だけである。
【０１０４】
このため、第３の機器がデータ送受信の必要がなくなったと判断した場合には、単に第３の機器がｐ−ｔｏ−ｐを切断すればよい。送信機、受信機はｏＰＣＲ、ｉＰＣＲに書きこまれた値に従って送受信動作を停止するなどの処理を行う事になる。
【０１０５】
一方、受信機がデータ受信を止めたい場合、第３の機器により張られたｐ−ｔｏ−ｐ接続を直接切断する事はできないので、第３の機器にデータ受信の必要が無くなったことを知らせて第３の機器にｐ−ｔｏ−ｐを切断させる必要がある。データ伝送が開始すると、第３の機器は再度受信機に対してＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨ  Ｎｏｔｉｆｙコマンドを送る。これにより、受信機は受信しているプラグがデータを利用しなくなった時点で、そのプラグに対応したｉｐ００−ｉｐ３０のいずれかのビットを０にしてレスポンスを返す。または受信機は受信している信号形式を変更する場合にもｉ＿ｓｉｇビットを１にしてレスポンスを返す。第３の機器は、レスポンスを受け取ると受信しているプラグが現在のデータ伝送に使われ無くなった事がわかるので、そのプラグとのｐ−ｔｏ−ｐ接続を解除する。
【０１０６】
また、送信機がデータ受信を止めたい場合、第３の機器により張られたｐ−ｔｏ−ｐ接続を直接切断する事はできないので、第３の機器にデータ送信の必要が無くなったことを知らせて第３の機器にｐ−ｔｏ−ｐ接続を切断させる必要がある。データ伝送が開始すると、第３の機器は再度送信機に対してＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨ  Ｎｏｔｉｆｙコマンドを送る。これにより、送信機は送信要求が無くなった時点で、そのプラグに対応したｏｐ００−ｏｐ３０のいずれかのビットを０にしてレスポンスを返す。または送信機は送信している信号形式を変更する時点で、ｏ＿ｓｉｇビットを１にしてレスポンスを返す。第３の機器は、レスポンスを受け取ると送信しているプラグが現在のデータ伝送に使われ無くなった事がわかるので、そのプラグとのｐ−ｔｏ−ｐ接続を切断する。さらに無駄な送信を止めようとするならば、ｐ−ｔｏ−ｐ接続して受信している機器が全て無くなると、送信機に送信を止めるなどの処理を行う事になる。ｉ＿ｓｉｇビットやｏ＿ｓｉｇビットが１になった場合には、相手の機器に対してそのデータの送信モード／受信モードになるようにコントロールコマンドを送り、相手の機器に拒絶された場合にはｐ−ｔｏ−ｐ接続を切る操作を行っても良い。
【０１０７】
なお、本実施の形態では信号形式を指定し、出力準備できている（もしくは出力準備できた）機器があれば入力機器を探すとしたが、これは入力準備できている（もしくは入力準備できた）機器があれば出力機器としてもよい。また、入出力準備を合わせて行い、準備ができているプラグの一覧表を作成する方法でも構わない。また、信号形式を指定し、一覧表を作成した後にｐ−ｔｏ−ｐを張るとしたが、これは、信号形式を指定せずに、ｐ−ｔｏ−ｐを張る前に信号形式をあわせるようにしてもよい。
【０１０８】
（第６の実施の形態）
次に、本発明の第６の実施の形態を説明する。第５の実施の形態と異なる点は、ｐ−ｔｏ−ｐ接続でなくｂｒｏａｄｃａｓｔ接続により伝送路を確立する点である。ステップ１からステップ５までの動作は第５の実施の形態と同様であるのでその説明は省略する。
【０１０９】
本実施の形態では、図３のステップ６で第３の機器が送信機に対しｃｏｎｎｅｃｔｉｏｎ＿ｓｔａｔｅに７０（ｅｓｔａｂｌｉｓｈ）を設定したＤＩＧＩＴＡＬ＿ＯＵＴＰＵＴコマンドを送りｂｒｏａｄｃａｓｔ  ｏｕｔ接続を行わせる。また同時に受信機に対しｃｏｎｎｅｃｔｉｏｎ＿ｓｔａｔｅに７０（ｅｓｔａｂｌｉｓｈ）を設定したＤＩＧＩＴＡＬ＿ＩＮＰＵＴコマンドを送りｂｒｏａｄｃａｓｔ  ｉｎ接続を行わせる。このように、ｂｒｏａｄｃａｓｔ  ｉｎ接続とｂｒｏａｄｃａｓｔ  ｏｕｔ接続を同じチャンネルに対して行うことにより、結果として送信機と受信機の間で伝送路が確立される。ｂｒｏａｄｃａｓｔ  ｉｎ／ｏｕｔの張り方の詳細は、第２、第４の実施の形態と同じであるので省略する。
【０１１０】
次にデータ送信または受信の必要が無くなった際に、上記手順により確立した伝送路を切断しデータ入力を停止する場合の手順について述べる。本実施の形態では、ｂｒｏａｄｃａｓｔ接続を行っているので、送信機がデータ送信の必要がなくなった場合には、単に送信機がｂｒｏａｄｃａｓｔ  ｏｕｔ接続を切断しデータ送信を止めればよい。受信機はデータが来なくなったことを検出して停止するなどの処理を行う事になる。
【０１１１】
また受信機がデータ受信の必要がなくなった場合にも、単に受信機がｂｒｏａｄｃａｓｔ  ｉｎ接続を切断すればよい。さらに受信機がデータ受信不要になった時点で無駄な送信を止めようとするならば、送信機は受信している機器の有無が検出できないので、例えば送信機に対しｃｏｎｎｅｃｔｉｏｎ＿ｓｔａｔｅに６０（ｂｒｅａｋ）を設定したＤＩＧＩＴＡＬ＿ＯＵＴＰＵＴコマンドを送りｂｒｏａｄｃａｓｔ  ｏｕｔ接続を切断させることができる。もちろん送信機のｏＰＣＲのＢｒｏａｄｃａｓｔ＿ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｕｎｔｅｒを受信機が直接０クリアしても構わない。また先に説明したＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨＮｏｔｉｆｙコマンドを送信機が受信機に発行しておき、受信機は送信機にデータ受信の必要が無くなったことを知らせて送信機にデータ送信を止めさせることもできる。ここで、他の機器がｂｒｏａｄｃａｓｔされているチャンネルを受信している可能性があるので、第３の機器がデータ送信を止めさせる前に、それぞれの機器のｉＰＣＲを読み、そのチャンネルに対してｂｒｏａｄｃａｓｔ  ｉｎ接続していないかを確認することが望ましい。
【０１１２】
また第３の機器がデータ伝送路を切断したい場合にも、送信機に対しｃｏｎｎｅｃｔｉｏｎ＿ｓｔａｔｅに６０（ｂｒｅａｋ）を設定したＤＩＧＩＴＡＬ＿ＯＵＴＰＵＴコマンドを送りｂｒｏａｄｃａｓｔ  ｏｕｔ接続を切断させることができる。もちろんｏＰＣＲのｂｒｏａｄｃａｓｔ  ｃｏｎｎｅｃｔｉｏｎ  ｃｏｕｎｔｅｒビットを受信機が０クリアすることによりｂｒｏａｄｃａｓｔ  ｏｕｔ接続を切断しても構わない。
【０１１３】
以上第５の実施の形態および第６の実施の形態で説明した手順にしたがって第３の機器が判定を行い、データ伝送路の確立と切断を行えば、無駄な受信とならないかを判定する事ができ、必要性がなくなったデータ伝送を停止することができるため、無駄な伝送を回避することが可能となる。
【０１１４】
なお、図３に示したフローチャートにおいて、入力プラグ数および出力プラグ数の問い合わせ、信号フォーマットをサポートしているかの問い合わせ、データ入出力準備できているかの問い合わせ、別信号入力中か出力中かの問い合わせのコマンドは本実施の形態で示したものに限定されるもので無く、同等の内容を問い合わされるものであれば良い。
【０１１５】
また、図７に示したＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨ  Ｎｏｔｉｆｙコマンドを送るとしたが、これはＳｔａｔｕｓコマンドを繰り返し送ることでも良く、さらに信号形式の指定や問い合わせなども同じコマンド中に含めて一度に送っても良い。例えば、ＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨ  Ｎｏｔｉｆｙコマンドにｆｍｔ、ｆｄｆフィールドを追加定義し、このコマンドを受信した機器はｆｍｔ、ｆｄｆフィールドで指定された信号形式のデータに関する送受信要求を回答するようにすれば良い。この際には要求は継続しても信号形式が変われば，各ポートに対応するビットは０クリアされるのでｉ＿ｓｉｇ、ｏ＿ｓｉｇのビットは規定しなくてもよい。
【０１１６】
また、各問い合わせの順序は本発明の実施の形態だけに限定されるものではなく、入れ替わっても良い。
【０１１７】
なお、以上第１から６の実施の形態で述べた伝送管理方法は、コマンドで問い合わせる形式を取ったが、接続状態に関する属性情報を規定し、これが変化するたびに管理しようとする機器に送るような形式にしても良い。例えば図１０のように接続されたバスシステムにおいて、各機器から接続状態が変化するたびに、コントローラ５に対し接続状態に関する属性情報を送信する。コントローラ５は各機器の接続状態やデータの入出力状態を視覚的に表示する。図１１は接続状態を視覚的に表示するイメージ図である。
【０１１８】
【発明の効果】
以上説明したところから明らかなように、本発明では、ｐ−ｔｏ−ｐ接続において、送信データがない場合にもｐ−ｔｏ−ｐを張りつづける、受信側で必要でないデータを送信する、送信前に送信機が有効なデータを出してくれるかどうかわからない、などにより生じるデータの無駄な伝送をなくすことができる。
【０１１９】
また、受信可能な機器の存在を確認してからｂｒｏａｄｃａｓｔ  ｏｕｔ接続を開始することにより無駄な伝送をなくすことができる。
【０１２０】
さらに、ｂｒｏａｄｃａｓｔ  ｉｎ接続の準備ができた段階でｂｒｏａｄｃａｓｔ  ｏｕｔ接続を開始させることにより、無意味な伝送をなくすことができる。
【図面の簡単な説明】
【図１】本発明の第１の実施の形態において送信機がデータを受信する機器を探す際の流れを示すフローチャート
【図２】本発明の第３の実施の形態において受信機がデータを送信する機器を探す際の流れを示すフローチャート
【図３】本発明の第５の実施の形態において第３の機器がデータを送受信する機器を探す際の流れを示すフローチャート
【図４】ＣＭＰにおけるプラグの概念を説明するための図
【図５】ＰＬＵＧ  ＩＮＦＯ  コマンドを説明するための図
【図６】ＩＮＰＵＴ  ＰＬＵＧ  ＳＩＧＮＡＬ  ＦＯＲＭＡＴおよびＯＵＴＰＵＴ  ＰＬＵＧ  ＳＩＧＮＡＬ  ＦＯＲＭＡＴコマンドを説明するための図
【図７】ＩＳＯＣＨ＿ＩＯ＿ＷＩＳＨコマンドを説明するための図
【図８】ＤＩＧＩＴＡＬ  ＩＮＰＵＴコマンドおよびＤＩＧＩＴＡＬ  ＯＵＴＰＵＴコマンドを説明するための図
【図９】ｉＰＣＲ  フォーマットおよびｏＰＣＲ  フォーマットを説明するための図
【図１０】バスシステムの構成を示す構成図
【図１１】接続状態を視覚的に表示するイメージ図
【符号の説明】
０  カムコーダ
１  ＶＴＲ
２  ＶＴＲ
３  ＳＴＢ（Ｓｅｔ  Ｔｏｐ  Ｂｏｘ：衛星放送受信機）
４  モニタ
５  コントローラ
【図１】
0003671738.tif 000002
【図２】
0003671738.tif 000003
【図３】
0003671738.tif 000004
【図４】
0003671738.tif 000005
【図５】
0003671738.tif 000006
【図６】
0003671738.tif 000007
【図７】
0003671738.tif 000008
【図８】
0003671738.tif 000009
【図９】
0003671738.tif 000010
【図１０】
0003671738.tif 000011
【図１１】
0003671738.tif 000012