JP3341758B2 - データ転送方法 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、映像信号や音声信
号等のリアルタイム処理が必要なデータを複数の機器間
で転送する際に用いるデータ転送方法に関するものであ
る。

【０００２】

【従来の技術】ディジタル伝送技術の進歩と共に、映像
信号や音声信号（以下ＡＶデータと称する）を共通のデ
ィジタル伝送路（以下バスと称する）を介して伝送する
機器（以下ノードと称する）が開発されつつある。ＡＶ
データは処理されるべき速度に同期して送受信される必
要があるため、リアルタイム通信が可能なバスが必要と
なる。バス接続の特徴は、１つのノードが送信したＡＶ
データをバスで接続されている複数のノードで同時に受
信できるということである。

【０００３】一方、次世代の高速バスとして IEEE P139
4 シリアルバスが提案されている。IEEE P1394 では、1
25μsec（１サイクル）毎に同期パケットを送受信する
ことによってリアルタイム通信を可能にしている。また
ノードが接続または分離された場合やノードのＡＣコン
セントが抜かれた場合等には、即座にバスリセットを実
行して活線挿抜に対応している。したがって IEEE P139
4 バスを用いることによって、家庭用ＡＶ機器に適した
リアルタイムデータの通信（以下同期通信と称する）を
行うことができる。

【０００４】

【発明が解決しようとする課題】しかしながら家庭用Ａ
Ｖ機器間で同期通信を行うに際して IEEE P1394 シリア
ルバスを用いる場合に上記従来の同期パケットの構成で
は、前記同期パケットを受信したノードにとって、どの
ノードが前記同期パケットを送信したのかを判別するこ
とができないという問題を有していた。

【０００５】また上記に示した問題点があるために、ユ
ーザの不用意な操作による同期通信の中断を防ぐ必要が
あるときに、同期パケットを受信している受信ノード
が、同期パケットを送信している送信ノードに対して同
期パケットの送信継続を要求して、送信ノードをプロテ
クト状態にすることができないという問題を有してい
た。

【０００６】例えば、Ａ、Ｂ、Ｃの３つのノードが接続
されたシステムにおいて、Ａのノードが送信した同期パ
ケットをＢのノードが受信して記録している場合に、ユ
ーザが誤ってＣのノードに対して同期パケットの送信を
伴う操作を行ったとする。このとき、ＣのノードがＡの
ノードに対して同期パケットの送信を停止するよう要請
し、Ａのノードがこの要請に応えれば、Ｂのノードの記
録動作が妨げられることになる。すなわち、従来のデー
タ転送方法では、送受信に直接関わりのないノードの誤
操作によって、別のノード間の同期パケットの転送が中
断される可能性があるという問題を有していた。

【０００７】本発明は上記従来の問題点を解決するもの
で、同期通信を行うに際し、同期パケットを受信したノ
ードが、どのノードがその同期パケットを送信したのか
を瞬時に判別できるようにすることによって、ユーザの
不用意な操作による同期通信の中断を防ぐことができる
ようにすることを目的とする。

【０００８】

【課題を解決するための手段】この目的を達成するため
に本発明のデータ転送方法では、同期パケット内に、同
期パケットを送信する送信ノードのノード識別子を付加
した構成とし、複数の受信ノードからの送信継続の要求
に対応するために、送信ノードは、受信ノードから１回
以上の継続要求を受信した段階でプロテクト状態に移行
し、継続要求を受信した回数以上の停止許可を受信した
段階でプロテクト解除状態に移行するという構成を有し
ている。

【０００９】

【発明の実施の形態】本発明の第１の発明は、バスを介
して、リアルタイムデータを同期パケットにより転送す
る方法であって、前記同期パケットは、送信ノードを判
別するための識別子として、バスリセット毎に割り当て
られたノード識別子を含み、前記送信ノードは、他のノ
ードからの前記同期パケットの送信継続を依頼する継続
要求を、１回以上受信した段階でプロテクト状態にな
る。

【００１０】また、第２の発明は、上記第１の発明に加
え、送信ノードは、他のノードからの継続要求の解除を
依頼する停止許可を、継続要求を受信した回数、受信し
た段階でプロテクト解除状態になる。

【００１１】また、第３の発明は、上記第１の発明に加
え、プロテクト状態にある送信ノードは、他のノードか
らの送信停止要求を受信しても、同期パケットの送信を
継続する。

【００１２】また、第４の発明は、上記第１の発明に加
え、プロテクト状態にある送信ノードは、バスリセット
が発生したときにはプロテクト解除状態になる。

【００１３】また、第５の発明は、上記第４の発明に加
え、送信ノードは、バスリセットからの復旧後直ちに同
期パケットの出力を再開する。

【００１４】また、第６の発明は、上記第５の発明に加
え、継続要求を送信したノードは、バスリセットが発生
したときには送信ノードに対して継続要求を送信する。

【００１５】また、第７の発明は、上記第２の発明に加
え、プロテクト解除状態にある送信ノードは、他のノー
ドからの送信停止要求を受信した場合には同期パケット
の送信を停止する。

【００１６】また、第８の発明は、上記第１の発明に加
え、送信ノードは、通信を介さずに直接データの送信停
止を指示された場合には、プロテクト状態であっても、
その時点でデータの送信を停止する。

【００１７】また、第９の発明は、上記第１の発明に加
え、送信ノードは、通信を介さずに直接データの送信継
続を指示された場合には、プロテクト状態に移行する。

【００１８】上記のような方法（または構成）により本
発明のデータ転送方法において、受信ノードは、受信し
た同期パケットに含まれる送信ノードのノード識別子を
見るだけで瞬時に同期パケットを送信した送信ノードを
判別することができるので、この送信ノードを判別する
ことによって、受信ノードは、必要に応じて送信ノード
に対して継続要求を送信し、また必要がなくなった時点
で停止許可を送信することができる。送信ノードは、継
続要求を受信する毎にプロテクトカウンタをインクリメ
ントし、停止許可を受信する毎にプロテクトカウンタを
デクリメントする。送信ノードが、プロテクトカウンタ
の値が零でないときには他のノードからの送信停止要求
を拒絶することによって、ユーザの不用意な操作による
同期通信の中断を防ぐことができる。

【００１９】以下、本発明の実施の形態について、図面
を用いて説明する。

【００２０】本実施の形態では、複数台のビデオテープ
レコーダー（以下ＶＴＲと略記する）を IEEE P1394 バ
スで接続してＡＶデータのダビングを行う場合を例に挙
げて説明する。

【００２１】図１は、本実施の形態において同期通信を
行う際に転送される同期パケットのフォーマットであ
る。

【００２２】図１において、パケットヘッダ１はIEEE P
1394 で規定されているヘッダであり、チャンネル番号
やパケットに含まれる転送ブロック２のデータ量等の情
報が配置される。転送ブロック２はユーザが任意に転送
したいデータを設定できる領域であり、その同期パケッ
トによって転送されているデータがどのようなデータで
あるのか等を示すデータヘッダ３、および実際に転送さ
れているデータ４から成っている。データヘッダ３は、
その同期パケットを送信した送信ノードを示すノード識
別子５、およびその他のヘッダデータから成っている。
ＣＲＣ６は転送ブロック２の転送エラー判別用データで
ある。

【００２３】IEEE P1394 では、バスリセットが発生す
る毎に、その時点で接続されているノードに対して、自
動的にノード識別子が割り当てられる。このため、同期
パケットを送信する送信ノードは、図１に示したフォー
マットに従って、その時点で割り当てられているノード
識別子をデータヘッダ２に書き込んで、同期パケットの
送信を行う。

【００２４】図２に、４台のＶＴＲをバスで接続してＡ
Ｖデータのダビングを行う際の接続図を示す。

【００２５】図２において７〜１０はそれぞれＶＴＲで
あり、ＶＴＲ７〜１０はそれぞれ内蔵しているマイコン
（図示せず）によって動作を管理されている。１１〜１
３はＶＴＲ７〜１０を接続しているケーブルである。こ
のケーブル１１〜１３の接続を行う毎にバスリセットが
発生して、ＶＴＲ７〜１０にノード識別子が割り当てら
れる。ここでは、ＶＴＲ７〜１０にはそれぞれ０〜３の
ノード識別子が割り当てられているものとする。

【００２６】さて、IEEE P1394では125μsec（１サイク
ル）毎にパケットの送受信が行われ、各サイクルの前半
部を同期通信用の優先時間帯に割り当てることができ
る。このため同期通信を行うに際し、有限である優先時
間帯について帯域確保を行う。すなわちどの通信チャン
ネルを利用してどれくらいの時間同期パケットを送信す
るのかを予め決定する必要がある。また、この優先時間
帯の帯域の管理は、バスで接続されているノードの内の
コンフィグレーションマネージャ（以下ＣＦＭと称す
る）と呼ばれる特定のノードが行う。

【００２７】いま、ＶＴＲ７で再生したＡＶデータをＶ
ＴＲ８とＶＴＲ９とで記録するダビングを行うものと
し、ＶＴＲ１０が優先時間帯の帯域の管理を行うものと
する。

【００２８】以下、本実施の形態のＶＴＲの処理内容
を、そのＶＴＲの役割ごとに説明する。

【００２９】ここで、以下の説明に用いるＡＶデータ以
外のデータ、例えば、受信ノードから送信ノードに対し
て送信する継続要求および停止許可等は、非同期パケッ
トを利用して通信している。

【００３０】図３は、本実施の形態においてＶＴＲ７が
ＡＶデータを再生し、ＶＴＲ１０に対して同期通信を行
うための帯域の確保を要求して許可を得た後に、実際に
同期パケットを送信している際のＶＴＲ７のマイコン処
理内容を示すフローチャートである。

【００３１】このとき送信ノードであるＶＴＲ７は、図
１に示した同期パケットのフォーマットに従って、割り
当てられているノード識別子「０」をデータヘッダ２に
書き込んで、同期パケットを送信する。

【００３２】まずステップ３０１において、他のノード
から継続要求を受信したかどうかを判断する。継続要求
を受信していればメモリ上に設定した６ビットのカウン
タであるプロテクトカウンタをインクリメントし（ステ
ップ３０２）、継続要求を受信していなければそのま
ま、ステップ３０３へ進む。

【００３３】ここで、プロテクトカウンタは、同期パケ
ットの送信を開始する直前に「０」にリセットされるカ
ウンタである。このため、例えば本実施の形態において
ＶＴＲ７が同期パケットの送信を開始した後、ＶＴＲ８
およびＶＴＲ９の２台のＶＴＲから継続要求を受信した
場合には、ＶＴＲ７のプロテクトカウンタの値は「２」
となる。

【００３４】ステップ３０３では、他のノードから停止
許可を受信したかどうかを判断し、許可されていればプ
ロテクトカウンタをデクリメントし（ステップ３０
４）、許可されていなければそのまま、ステップ３０５
へ進む。

【００３５】例えば、本実施の形態においてＶＴＲ８お
よびＶＴＲ９の２台のＶＴＲからプロテクトを要求され
てＶＴＲ７のプロテクトカウンタの値が「２」となって
いる場合には、ＶＴＲ８およびＶＴＲ９の２台ともから
停止許可が送信されるまでは、プロテクトカウンタの値
が「０」にならないことになる。

【００３６】ステップ３０４では、他のノードから停止
許可を受信しても、既にプロテクトカウンタの値が
「０」であれば、プロテクトカウンタのデクリメントは
行わない。

【００３７】ステップ３０５では、バスリセットが発生
したかどうかを判断し、発生した場合にはプロテクトカ
ウンタの値を「０」にリセットして（ステップ３０６）
ステップ３０１に戻る。発生していなければステップ３
０７に進む。

【００３８】バスリセットが発生すると、一時的に同期
パケットの送信は中断するが、ＶＴＲ７はバスリセット
からの復旧後直ちに同期パケットの出力を再開する。

【００３９】バスリセットはケーブルが抜き差しされた
場合や、機器のコンセントが抜けた場合等に発生する。
したがって、バスリセットが発生すると、バスリセット
発生以前に継続要求を送信したノードが停止許可を送信
できなくなっている。この場合、ＶＴＲ７はプロテクト
状態から復帰できなくなる。このようなことを防ぐため
にバスリセット発生時にはプロテクトカウンタをリセッ
トする。

【００４０】ステップ３０７では、他のノード、例えば
ＶＴＲ１０から同期パケットの送信停止要求を受信した
かどうかを判断し、受信した場合にはプロテクトカウン
タの値が「０」であるかどうかを判断する（ステップ３
０８）。

【００４１】ここでプロテクトカウンタの値が「０」以
外であればプロテクト状態であると判断して停止要求を
受理せず、送信停止を要求したノードであるＶＴＲ１０
に対して停止要求拒否を送信し（ステップ３０９）、ス
テップ３０１に戻る。

【００４２】プロテクトカウンタの値が「０」であれば
プロテクト解除状態であると判断して停止要求を受理
し、同期パケットの送信を停止して（ステップ３１
０）、処理を終了する。

【００４３】ステップ３０７で送信停止が要求されてい
ない場合には、通信を介さずに外部から直接送信停止が
要求されたかどうかを判断する（ステップ３１１）。通
信を介さずに外部から直接送信停止が要求される例とし
ては、ＶＴＲ７本体の送信停止キーが操作された場合
や、電源スイッチキーが押された場合等が挙げられる。

【００４４】さて、ステップ３０７で通信を介さずに外
部から直接送信停止が要求された場合には、その時点の
プロテクトカウンタの値に関係なく、プロテクトカウン
タを「０」にリセットし（ステップ３１２）、同期パケ
ットの送信を停止する（ステップ３１０）。すなわち、
その機器に対してユーザが直接操作した場合には、その
操作を優先させる。

【００４５】外部から直接送信停止が要求される例とし
ては、バスに対するデータ出力の可・不可を制御するデ
ジタル出力キーが設けられているＶＴＲにおいて、同期
パケットの送信中にユーザがデジタル出力キーを操作し
て、データ出力を不可にされた場合が挙げられる。

【００４６】また、他の例としては、ＴＶチューナーが
付いていないために停止時にはデジタル出力も停止する
仕様となっている再生専用ＶＴＲにおいて、停止キーが
押されたことによってＶＴＲが再生状態からが停止状態
になった場合が挙げられる。

【００４７】ステップ３０７において、通信を介さずに
外部から直接送信停止が要求されていない場合には、ス
テップ３０１に戻って、上記した一連の処理を継続す
る。

【００４８】図４は、本実施例においてＶＴＲ８および
ＶＴＲ９が、ＶＴＲ７から送信されるＡＶデータの同期
パケットを実際に受信して記録を開始した後のＶＴＲ８
およびＶＴＲ９のマイコンの処理内容を示すフローチャ
ートである。

【００４９】いま、本実施の形態において、例えばＶＴ
Ｒ７が再生するＡＶデータをＶＴＲ８およびＶＴＲ９で
記録しているダビングの最中にユーザが操作を誤ってＶ
ＴＲ１０を再生状態にしてしまったとする。このような
場合、ＶＴＲ１０は同期パケットの出力ができなけれ
ば、ＶＴＲ７に対して同期パケットの出力を停止してく
れるように送信停止を要求する。

【００５０】本実施の形態では、上記の例のような場合
にも、ＡＶデータを記録しているＶＴＲ８とＶＴＲ９へ
のＶＴＲ７からの同期パケットの送信が停止することな
く、ダビングが正しく行われるようにする。すなわち、
ＶＴＲ８およびＶＴＲ９は、ＶＴＲ７からの同期パケッ
トを受信した時点で、ＶＴＲ７に対して継続要求を送信
する。

【００５１】また、本実施の形態においては、ＶＴＲ８
とＶＴＲ９とは同じ処理をするため、以下ではＶＴＲ８
の処理内容についてのみ述べる。

【００５２】まずステップ４０１において、受信した同
期パケットのデータヘッダ２に書かれている、送信ノー
ドであるＶＴＲ７のノード識別子「０」を読み込んで、
このノード識別子「０」を持つ送信ノードであるＶＴＲ
７に対して継続要求を送信してステップ４０２に進む。

【００５３】ステップ４０２では、バスリセットが発生
したかどうかを判断し、発生した場合には再度プロテク
トを要求するためにステップ４０１に戻る。

【００５４】バスリセットが発生していない場合にはス
テップ４０３に進んで、同期パケットの受信が正常に行
われているかどうか、例えばＶＴＲ７が送信停止状態に
なっているために同期パケットの受信が中断していない
か等を判断する。

【００５５】同期パケットの受信が正常に行われている
場合にはステップ４０４に進み、正常に行われていない
場合には、その時点で処理を終了する。

【００５６】ステップ４０４では記録終了が指示された
かどうかを判断し、記録終了が指示されていない場合に
は、ステップ４０２に戻って、記録終了が指示されるま
でバスリセットの監視を行う。

【００５７】記録終了が指示された場合には、再度、受
信した同期パケット内のデータヘッダ２に書かれてい
る、送信ノードのノード識別子５を読み込んで、このノ
ード識別子５を持つ送信ノードに対して送信停止許可を
送信して（ステップ４０５）、処理を終了する。

【００５８】以上のように本実施の形態によれば、送信
ノードであるＶＴＲ７が割り当てられているノード識別
子を、送信する同期パケットのデータヘッダ２に書き込
んで送信することにより、この同期パケットを受信した
ＶＴＲ８およびＶＴＲ９は、瞬時にＶＴＲ７が送信ノー
ドであることを判別できる。

【００５９】また、送信ノードであるＶＴＲ７は、他の
ノード、例えばＶＴＲ８とＶＴＲ９から継続要求を受信
した段階でプロテクトカウンタをインクリメントし、停
止許可を受信した段階でプロテクトカウンタをデクリメ
ントし、このプロテクトカウンタの値が「０」以外のと
きにはプロテクト状態であると判断する。送信ノードで
あるＶＴＲ７は、プロテクト状態のときに他のノード、
例えばＶＴＲ１０から送信停止が要求された場合には、
その送信停止要求を拒否して送信を継続する。このよう
にすることによって、例えばＶＴＲ７が再生するＡＶデ
ータをＶＴＲ８およびＶＴＲ９で記録しているダビング
の最中にユーザが操作を誤ってＶＴＲ１０を再生状態に
してしまった場合にも、ＡＶデータを記録しているＶＴ
Ｒ８とＶＴＲ９へのＶＴＲ７からの同期パケットの送信
が停止することなく、ダビングが正しく行われるように
できる。

【００６０】また、バスリセット発生時にプロテクトカ
ウンタをリセットすることによって、バスリセットが発
生した場合にも、バスリセット発生以前に継続要求を送
信したノードが停止許可を送信できなくなってしまった
ために送信ノードであるＶＴＲ７がプロテクト状態から
復帰できなくなることを防ぐことができる。

【００６１】なお、上記実施の形態においては、送信ノ
ードに対して継続要求を送出する受信ノードは、送信ノ
ードからの同期パケットを記録するノードでなくても良
い。例えば、いま、テレビモニター（以下、ＴＶと略記
する）とＶＴＲとレーザーディスク（登録商標）プレー
ヤー（以下、ＬＤプレーヤーと略記する）が接続されて
いて、ＴＶにＬＤプレーヤーの再生画面を映し出してい
るとする。このような場合に、誤ってＶＴＲの再生画面
をＴＶに映しださないようにするために、ユーザ自身が
受信ノードであるＴＶをキー操作することによって、送
信ノードであるＬＤプレーヤーに対して継続要求を送信
しても良い。

【００６２】また、上記実施の形態においては、受信ノ
ードからの継続要求を受信したときに、送信ノードがプ
ロテクト状態に移行していたが、通信を介さずに外部か
ら送信継続を指示されることによってプロテクト状態に
移行しても良い。例えば、上述のＴＶとＬＤプレーヤー
の例において、送信ノードであるＬＤプレーヤーにプロ
テクトキーを設けて、このプロテクトキーを操作される
ことによってプロテクト状態に移行しても良い。

【００６３】また、上記実施の形態においては、送信ノ
ードがプロテクト状態かプロテクト解除状態であるのか
を判別する手段としてメモリ上に設定したカウンタを用
いていたが、プロテクト状態かプロテクト解除状態であ
るのかを判別できればどのような手段を用いても良い。
例えば、接続できるノードの数だけのビットを持つレジ
スタを用いても判別をすることができる。

【００６４】

【発明の効果】以上のように本発明のデータ転送方法
は、バスリセット毎にバスに接続された各ノードに対し
て自動的にノード識別子が割り当てられるバスシステム
を用いてリアルタイム処理が必要なデータを同期パケッ
トに内包して送信するに際し、同期パケット内に、送信
ノードを判別するためのノード識別子を付加して送信す
ることによって、同期パケットを受信した受信ノード
が、受信した同期パケットに含まれる送信ノードのノー
ド識別子を見るだけで瞬時に送信ノードを判別すること
ができるので、受信ノードは、必要に応じて送信ノード
に対して同期パケットの送信継続を依頼する継続要求を
送信し、かつ継続の必要がなくなった時点で継続要求の
解除を依頼する停止許可を送信し、同期パケットの送信
ノードは１回以上の継続要求を受信した段階でプロテク
ト状態となり、継続要求を受信した回数以上の停止許可
を受信した段階でプロテクト解除状態となる。送信ノー
ドは、プロテクト状態では他のノードからの送信停止要
求を拒絶し、同期パケットの送信を停止しない。これに
よって、ユーザの不用意な操作による同期通信の中断を
防ぐことができる。

【００６５】すなわち、送受信に直接関わりのないノー
ドの誤操作によって、別のノード間の同期パケットの転
送が中断されることを防ぐことができるという効果が得
られる。特にＶＴＲのダビング等、継続時間が比較的長
い同期通信を行う際に非常に有効である。

【００６６】また、プロテクト状態にある送信ノード
が、バスリセット発生時にプロテクト解除状態となるこ
とによって、バスリセット発生以前に継続要求を送信し
たノードが停止許可を送信できなくなってしまったため
に送信ノードがプロテクト状態から復帰できなくなるこ
とを防ぐことができる。

【図面の簡単な説明】

【図１】本発明の実施の形態における同期パケットのフ
ォーマットを示す模式図

【図２】同実施の形態におけるＶＴＲの接続図

【図３】同実施の形態における再生ＶＴＲの処理内容を
示すフローチャート

【図４】同実施の形態における記録ＶＴＲの処理内容を
示すフローチャート

【符号の説明】

２ 転送ブロック ３ データヘッダ ４ 転送データ ５ ノード識別子

───────────────────────────────────────────────────── フロントページの続き (72)発明者 西村 拓也 大阪府門真市大字門真1006番地 松下電 器産業株式会社内 (56)参考文献 特開 平７−162968（ＪＰ，Ａ) 特開 平７−250072（ＪＰ，Ａ) 特開 平６−29992（ＪＰ，Ａ) 特開 平７−193616（ＪＰ，Ａ) Ｍｉｃｈａｅｌ Ｔｅｅｎｅｒ，Ａ ＢＵＳ ＯＮ Ａ ＤＩＥＴ−ＴＨＥ ＳＥＲＩＡＬ ＢＵＳ ＡＬＴＥＲＮＡ ＴＩＶＥ，ＩＥＥＥ ＣＯＭＰＣＯＮ ＳＰＲＩＮＧ，米国，ＩＥＥＥ ＣＯＭ ＰＵＴＥＲ ＳＯＣＩＥＴＹ ＩＮＴＥ ＲＮＡＴＩＯＮＡＬ ＣＯＮＦＥＲＥＮ ＣＥ，1992年２月，ＰＡＧＥ316−321 Ａｄａｍ Ｊ．Ｋｕｎｚｍａｎ，Ａｌ ａｎ Ｔ．Ｗｅｔｚｅｌ，1394 ＨＩＧ Ｈ ＰＥＲＦＯＲＭＡＮＣＥ ＳＥＲＩ ＡＬ ＢＵＳ：ＴＨＥ ＤＩＧＩＴＡＬ ＩＮＴＥＲＦＡＣＥ ＦＯＲ ＡＴ Ｖ，ＩＥＥＥ ＴＲＡＮＳＡＣＴＩＯＮ Ｓ ＯＮ ＣＯＮＳＵＭＥＲ ＥＬＥＣ ＴＲＯＮＩＣＳ，米国，1995年８月，Ｖ ＯＬ．41 ＮＯ．３，ＰＡＧＥＳ．893 −900 (58)調査した分野(Int.Cl.⁷，ＤＢ名) H04L 12/28 G06F 13/00 357

Claims (18)

(57)【特許請求の範囲】
1. 【請求項１】 バスを介して、リアルタイムデータを同
   期パケットにより転送する方法であって、 前記同期パケットは、送信ノードを判別するための識別
   子として、バスリセット毎に割り当てられたノード識別
   子を含み、 前記送信ノードは、他のノードからの前記同期パケット
   の送信継続を依頼する継続要求を、１回以上受信した段
   階でプロテクト状態になることを特徴とするデータ転送
   方法。
2. 【請求項２】 送信ノードは、他のノードからの継続要
   求の解除を依頼する停止許可を、継続要求を受信した回
   数、受信した段階でプロテクト解除状態になることを特
   徴とする請求項１記載のデータ転送方法。
3. 【請求項３】 プロテクト状態にある送信ノードは、他
   のノードからの送信停止要求を受信しても、同期パケッ
   トの送信を継続することを特徴とする請求項１記載のデ
   ータ転送方法。
4. 【請求項４】 プロテクト状態にある送信ノードは、バ
   スリセットが発生したときにはプロテクト解除状態にな
   ることを特徴とする請求項１記載のデータ転送方法。
5. 【請求項５】 送信ノードは、バスリセットからの復旧
   後直ちに同期パケットの出力を再開することを特徴とす
   る請求項４に記載のデータ転送方法。
6. 【請求項６】 継続要求を送信したノードは、バスリセ
   ットが発生したときには送信ノードに対して継続要求を
   送信することを特徴とする請求項４記載のデータ転送方
   法。
7. 【請求項７】 プロテクト解除状態にある送信ノード
   は、他のノードからの送信停止要求を受信した場合には
   同期パケットの送信を停止することを特徴とする請求項
   ２記載のデータ転送方法。
8. 【請求項８】 送信ノードは、通信を介さずに直接デー
   タの送信停止を指示された場合には、プロテクト状態で
   あっても、その時点でデータの送信を停止することを特
   徴とする請求項１記載のデータ転送方法。
9. 【請求項９】 送信ノードは、通信を介さずに直接デー
   タの送信継続を指示された場合には、プロテクト状態に
   移行することを特徴とする請求項１記載のデータ送信方
   法。
10. 【請求項１０】 バスを介して、リアルタイムデータを
    同期パケットにより転送するシステムであって、 前記同期パケットは、送信ノードを判別するための識別
    子として、バスリセット毎に割り当てられたノード識別
    子を含み、 前記送信ノードは、他のノードからの前記同期パケット
    の送信継続を依頼する継続要求を、１回以上受信した段
    階でプロテクト状態になることを特徴とするバスシステ
    ム。
11. 【請求項１１】 送信ノードは、他のノードからの継続
    要求の解除を依頼する停止許可を、継続要求を受信した
    回数、受信した段階でプロテクト解除状態になることを
    特徴とする請求項１０記載のバスシステム。
12. 【請求項１２】 プロテクト状態にある送信ノードは、
    他のノードからの送信停止要求を受信しても、同期パケ
    ットの送信を継続することを特徴とする請求項１０記載
    のバスシステム。
13. 【請求項１３】 プロテクト状態にある送信ノードは、
    バスリセットが発生したときにはプロテクト解除状態に
    なることを特徴とする請求項１０記載のバスシステム。
14. 【請求項１４】 送信ノードは、バスリセットからの復
    旧後直ちに同期パケットの出力を再開することを特徴と
    する請求項１３に記載のバスシステム。
15. 【請求項１５】 継続要求を送信したノードは、バスリ
    セットが発生したときには送信ノードに対して継続要求
    を送信することを特徴とする請求項１３記載のバスシス
    テム。
16. 【請求項１６】 プロテクト解除状態にある送信ノード
    は、他のノードからの送信停止要求を受信した場合には
    同期パケットの送信を停止することを特徴とする請求項
    １１記載のバスシステム。
17. 【請求項１７】 送信ノードは、通信を介さずに直接デ
    ータの送信停止を指示された場合には、プロテクト状態
    であっても、その時点でデータの送信を停止することを
    特徴とする請求項１０記載のバスシステム。
18. 【請求項１８】 送信ノードは、通信を介さずに直接デ
    ータの送信継続を指示された場合には、プロテクト状態
    に移行することを特徴とする請求項１０記載のバスシス
    テム。