JP4046846B2 - データ通信システム及びデータ通信装置 - Google Patents
データ通信システム及びデータ通信装置 Download PDFInfo
- Publication number
- JP4046846B2 JP4046846B2 JP11972798A JP11972798A JP4046846B2 JP 4046846 B2 JP4046846 B2 JP 4046846B2 JP 11972798 A JP11972798 A JP 11972798A JP 11972798 A JP11972798 A JP 11972798A JP 4046846 B2 JP4046846 B2 JP 4046846B2
- Authority
- JP
- Japan
- Prior art keywords
- size
- data
- segment
- data communication
- destination
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Small-Scale Networks (AREA)
- Communication Control (AREA)
- Information Transfer Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、データ通信システム及びデータ通信装置に関する。
【０００２】
【従来の技術】
最近、１つの伝送路を介して複数の電子機器を接続し、各機器間における制御信号と情報信号（ビデオ信号、オーディオ信号、グラフィックスデータ、テキストデータ等）との通信を混在させて行うように制御する通信システムが開発されている。
【０００３】
また、このような通信システムにおいて、各種の情報信号を各機器間において非同期に伝送させる通信プロトコルが開発されている。このような通信システムを実現する技術の一つに、高性能シリアルバスに関するＩＥＥＥ１３９４―１９９５規格（以下、１３９４規格）がある。
【０００４】
以下、図１０を用いて１３９４規格に準拠した従来の通信システムの構成について説明する。図１０において、各機器は１３９４規格に準拠したデジタルインタフェース１００５を具備している。
【０００５】
図１０の通信システムは、ＴＶ１００１、デジタルビデオテープレコーダ（以下、ＤＶＴＲ）１００２、プリンタ１００３、デジタルカムコーダ（以下、ＤＶＣＲ）１００４により構成されている。各機器は、１３９４規格に準拠した通信ケーブルを介して接続されている。
【０００６】
ここで、通信ケーブルは、データの転送や調停信号の通信に用いられる２組のシールド付きより対線により構成されている４ピンコネクタケーブルと、２組のより対線と電源供給用のペア線からなる６ピンコネクタケーブルとがある。尚、２組のより対線を用いて伝送されるデータは、ＤＳ−Ｌｉｎｋ方式により符号化されたデータである。
【０００７】
上述の通信システムでは、電源投入時、新たな機器の接続や切り離し等の接続構成の変化に応じてバスリセットを自動的に行う。ここで、バスリセットとは、通信システムを構成する各機器（以下、ノード）が、今までの認識していた通信システムの接続構成と各機器の通信アドレス（以下、ノードＩＤ）とを初期化し、新たな接続構成の再認識と通信アドレスの再設定とを行うため処理である。
【０００８】
以下、バスリセットの処理手順を簡単に説明する。この手順は、通信システムにおける階層的な接続構成の認識と各ノードに対する物理的な通信アドレスの付与からなる。
【０００９】
接続構成の認識は、バスリセットの開始後、各ノードが親子関係を宣言し合うことによって実行される。各ノードは、各ノード間の親子関係を決定することにより、通信システムをツリー構造（階層構造）として認識する。尚、各ノード間の親子関係は、通信システムの接続状態や各ノードの機能に依存するため、バスリセット毎に同じ関係になることはない。
【００１０】
例えば、図３の通信システムでは、まず、プリンタ１００３（以下、ノードＤ）とＤＶＴＲ１００２（以下、ノードＣ）との間で親子関係を設定する。次に、ＤＶＣＲ１００４（以下、ノードＢ）とＴＶ１００１（以下、ノードＡ）との間、及びノードＣとノードＡとの間で親子関係を設定する。
【００１１】
最終的に全てのノードの親（或いは上位）と認識された機器がルート・ノードとなり、この通信システムのバス使用権の調停を管理する。図１０の通信システムでは、ノードＡがルート・ノードとなる。
ルート・ノードの決定後、通信システムを構成する各ノードは、ノードＩＤの設定を自動的に開始する。
【００１２】
ノードＩＤの設定は、基本的に親ノードがポート番号の若い通信ポートに接続された子ノードに対して物理アドレスの設定を許可し、更にその子ノードが自分の子ノードに対して順番に設定の許可を与えることによって実行される。自己のノードＩＤを設定したノードは、セルフＩＤパケットを送出し、自己に付与されたノードＩＤを他のノードに対して通知する。最終的に全ての子ノードのＩＤ設定が終了した後、親ノードは自己のノードＩＤを設定する。
【００１３】
以上の処理を繰り返し実行することによって、ルート・ノードのノードＩＤが一番最後に設定される。尚、各ノードに割り当てられるノードＩＤは、各機器の親子関係に依存するため、バスリセット毎に同じノードＩＤが設定されることはない。
【００１４】
以下、図１０の通信システムを用いてノードＩＤの自動設定処理を説明する。尚、本実施例では、接続構成の認識後、ノードＡがルート・ノードとなった場合について説明する。
【００１５】
図１０において、ルート・ノードであるノードＡはまず、「ポート１」の通信ポートに接続されているノード、即ちノードＢに対してノードＩＤの設定を許可する。
【００１６】
ノードＢは、自己のノードＩＤを「＃０」に設定し、その結果をセルフＩＤパケットとして通信システムを構成する全てのノードに対してブロードキャストする。ここで、ブロードキャストとは、所定の情報を不特定多数のノードを宛先として送出することである。
【００１７】
この結果、全てのノードは、「ノードＩＤ「＃０」は割当済である」と認識し、次にノードＩＤの設定を許可されたノードは「＃１」を設定する。
ノードＢの設定後、ノードＡは、「ポート２」の通信ポートに接続されているノード、即ちノードＣに対してノードＩＤの設定を許可する。
【００１８】
ノードＣは更に、子ノードの接続されている通信ポートの内、最も若いポート番号の通信ポートから順に設定の許可を与える。つまり、ノードＤに対して許可を与え、その許可を受けたノードＤがノードＩＤ「＃１」を設定した後、セルフＩＤパケットをブロードキャストする。
【００１９】
ノードＤの設定後、ノードＣが自己のノードＩＤを「＃３」に設定し、最後にルート・ノードであるノードＡが自己のノードＩＤを「＃４」に設定して接続構成の認識を終了する。
【００２０】
このようなバスリセット処理により、各ノードは通信システムの接続構成の認識と各ノードの通信アドレスの設定とを自動的に行うことができる。そして各ノードは、この上述のノードＩＤを用いることにより各ノード間の通信を行なうことができる。
【００２１】
次に、図１０の通信システムの具備するデータ転送方式について図９を用いて説明する。
図１０の通信システムは、データ転送方式としてIsochronous 転送モードとAsynchronous転送モードとを具備している。Isochronous 転送モードは、１通信サイクル期間（125 μs ）毎に一定量のパケットの送受信を保証するため、ビデオデータや音声データのリアルタイムな転送に有効である。
【００２２】
また、Asynchronous転送モードは、制御コマンドやファイルデータ等を必要に応じて非同期に送受信する転送モードであり、Isochronous 転送モードに比べて優先順位が低く設定されている。
【００２３】
図１１において、各通信サイクルの始めには、サイクル・スタート・パケット１１０１と呼ばれる各ノードの計時するサイクル時間を調整するための通信パケットが送出される。
【００２４】
サイクル・スタート・パケット１１０１の転送後、所定の期間がIsochronous 転送モードに設定されている。Isochronous転送モードでは、Isochronous 転送モードに基づいて転送されるデータの夫々に対してチャネル番号を付すことにより、複数のIsochronous 転送を実行することができる。
【００２５】
例えば、図１１において、ＤＶＣＲ１００４からIsochronous 転送されるデータ１１０２にチャネル番号「ｃｈ０」、ＤＶＴＲ１００２からIsochronous 転送されるデータ１１０３にチャネル番号「ｃｈ１」、ＴＶ１００１からIsochronous転送されるデータ１１０４にチャネル番号「ｃｈ２」が割り当てられている場合、各データは、１通信サイクル期間内において時分割にIsochronous 転送される。
【００２６】
各Isochronous 転送が終了した後、次のサイクル・スタート・パケット１１０１の転送される期間までがAsynchronous転送に使用される。例えば、図１１では、Asynchronous転送に基づくデータ１１０５がＤＶＣＲ１００４からプリンタ１００３に転送される。
【００２７】
図１２は、Asynchronous転送モードに基づく従来の通信プロトコルについて説明するシーケンスチャートである。
図１２において、情報データをAsynchronous転送するノード、即ちソース１２０２をＤＶＣＲ１００４とする。
【００２８】
また、ソース１２０２からAsynchronous転送された情報データを受信するノード、即ちデスティネーション１２０３をプリンタ１００３とする。更に、ソース１２０２とデスティネーション１２０３との間の通信を管理するノード、即ちコントローラ１２０１をＴＶ１００１とする。
【００２９】
従来の通信プロトコルは、３つのフェーズからなっていた。第１のフェーズ１２０４は、コネクションフェーズで、コントローラ１２０１は、デスティネーション１２０３の受信バッファサイズや受信可能か否かを問い合わせ、デスティネーション１２０３を受信待機状態にセットする。
【００３０】
また、コントローラ１２０１は、デスティネーション１２０３に問い合わせた受信バッファサイズをソース１２０２に通知すると共に、ソース１２０２からAsynchronous転送される情報データを選択して、送信バッファからの転送をセットする。
【００３１】
第２のフェーズ１２０５は、伝送フェーズで、コントローラ１２０１は、ソース１２０２とデスティネーション１２０３とを制御し、情報データをAsynchronous転送する。
【００３２】
第３のフェーズ１２０６は、コネクションリリースフェーズで、コントローラ１２０１は、デスティネーション１２０３の受信バッファを自己の管理下から開放し、同様にソース１２０２の送信バッファを自己の管理下から開放する。
【００３３】
図１３は、ソース１２０２からAsynchronous転送される情報データとデスティネーション１２０３の受信バッファとの関係を説明する図である。ソース１２０２からAsynchronous転送される１オブジェクトの情報データ１３０１は、コントローラ１２０１から通知されたデスティネーション１２０３の受信バッファサイズに等しい１つ以上のセグメント１３０２に分割される。ここで、各セグメント１３０２のサイズは固定長であり、１セグメントは、１つ以上のセグメントデータ（固定長）からなる。
【００３４】
各セグメントデータは、Asynchronous転送モードに基づく通信パケット１３０３（以下、Asynchronousパケット１３０３）にパケッタイズされ、ソース１２０２からデスティネーション１２０３に順次転送される。
【００３５】
デスティネーション１２０３は、ソース１２０２からのAsynchronousパケット１３０３を順次受信し、一時的に受信バッファ１３０４に書き込む。１セグメント分の情報データの転送が終了した後、デスティネーション１２０３は、受信バッファ１３０４に格納されたデータを内部メモリ１３０５に順次書き込む。
【００３６】
以下、図１４を用いて上述の第２のフェーズ１２０５の処理について詳細に説明する。
図１４において、コントローラ１２０１は、デスティネーション１２０３に対して、１つ以上の通信パケットによりAsynchronous転送されるセグメントデータを受信するように指示する（１４０１）。
【００３７】
また、コントローラ１２０１は、ソース１２０２に対して、１オブジェクトの情報データを上述のセグメント単位に分割し、更に各セグメントを１つ以上の通信パケットでAsynchronous転送するように指示する（１４０２）。
【００３８】
これらの指示の後、ソース１２０２は、１セグメントデータを１つ以上のAsynchronousパケットにパケッタイズし、それらのAsynchronousパケットをデスティネーション１２０３へ順次転送する（１４０３）。
【００３９】
コントローラ１２０１から指示されたセグメントデータの転送が完了した後、ソース１２０２は、転送の完了をコントローラ１２０１に通知する（１４０４）。また、デスティネーション１２０３は、コントローラ１２０１から指示されたセグメントデータの受信が完了したことをコントローラ１２０１に通知する（１４０５）。以上、図１４の１４０１〜１４０５に示す手順により、１セグメント分の情報データが転送される（１４０６）。
【００４０】
次のセグメントデータの転送を開始する場合、再び１４０１〜１４０５に示す手順を繰り返し、コントローラ１２０１がソース１２０２とデスティネーション１２０３の間の転送を制御する（１４０７）。
【００４１】
【発明が解決しようとする課題】
しかしながら、上述の通信プロトコルには次のような問題があった。
例えば、従来の通信プロトコルにおいて、各セグメントのサイズは固定長であり、デスティネーション１２０３の具備する受信バッファのサイズと等しくなるように制御されていた。
【００４２】
また、デスティネーション１２０３の具備する受信バッファのサイズは、全データの転送が終了するまで一定であり、全データの転送中に各セグメントのサイズを可変的に制御する仕組みがなかった。
【００４３】
例えば、従来の通信プロトコルに従って、複数のセグメントに分割された画像データを順次受信するプリンタにおいて、各セグメント分のデータの受信中に、プリント用に画像処理されているデータの一部を一時的に受信バッファの一部に記憶したい場合がある。
【００４４】
このような場合、従来の通信プロトコルでは、各セグメントのデータ量は一定であるため、通信中に一部のセグメントのデータ量を減らし、受信バッファ内に所望の領域を確保することができなかった。
【００４５】
また、より多くの機器との通信を可能とするために、通信中にソース１２０２からデスティネーション１２０３に転送される１セグメントのデータ量を減らしたり、より早く通信を終了させるために、通信中にデスティネーション１２０３の受信バッファサイズを大きくし、１セグメントのデータ量を増やしたりを適応的に制御することができなかった。
【００４６】
そこで、本発明は、送信すべきデータを複数のセグメントに分割し、当該セグメントを複数のセグメントデータに分割し、当該複数のセグメントデータを受信側データ通信装置に送信する場合において、当該セグメントのデータ量を適切に制御することのできるデータ通信システム及びデータ通信装置を提供することを目的とする。
【００４７】
【課題を解決するための手段】
本発明に係るデータ通信システムは、受信側データ通信装置と、送信すべきデータを複数のセグメントに分割し、前記セグメントを複数のセグメントデータに分割し、前記複数のセグメントデータを前記受信側データ通信装置に送信する送信側データ通信装置とを有するデータ通信システムであって、前記受信側データ通信装置は、前記送信側データ通信装置から送信された前記セグメントデータを格納する第１の受信バッファと、前記第１の受信バッファに格納された前記セグメントデータを格納する第２の受信バッファと、前記送信側データ通信装置が前記セグメントデータのサイズと前記セグメントのサイズとを決定するのに必要な前記第１の受信バッファのサイズを、前記受信側データ通信装置の最大データ転送速度に対応するペイロードサイズを用いて決定し、前記第２の受信バッファのサイズを、前記第１の受信バッファのサイズを用いて決定する第１の決定手段と、前記第１の決定手段により決定された前記第１の受信バッファのサイズを示す情報を前記送信側データ通信装置に送信する送信手段とを有し、前記送信側データ通信装置は、前記受信側データ通信装置から前記第１の受信バッファのサイズを示す情報を受信する受信手段と、前記セグメントデータのサイズと前記セグメントのサイズとを、前記第１の受信バッファのサイズを用いて決定する第２の決定手段とを有することを特徴とする。
【００４８】
本発明に係るデータ通信装置の一つは、送信すべきデータを複数のセグメントに分割し、前記セグメントを複数のセグメントデータに分割し、前記複数のセグメントデータを送信する送信側データ通信装置から送信された前記複数のセグメントデータを受信するデータ通信装置であって、前記送信側データ通信装置から送信された前記セグメントデータを格納する第１の受信バッファと、前記第１の受信バッファに格納された前記セグメントデータを格納する第２の受信バッファと、前記送信側データ通信装置が前記セグメントデータのサイズと前記セグメントのサイズとを決定するのに必要な前記第１の受信バッファのサイズを、前記データ通信装置の最大データ転送速度に対応するペイロードサイズを用いて決定し、前記第２の受信バッファのサイズを、前記第１の受信バッファのサイズを用いて決定する決定手段と、前記決定手段により決定された前記第１の受信バッファのサイズを示す情報を前記送信側データ通信装置に送信する送信手段とを有することを特徴とする。
【００４９】
本発明に係るデータ通信装置の一つは、送信すべきデータを複数のセグメントに分割し、前記セグメントを複数のセグメントデータに分割し、前記複数のセグメントデータを受信側データ通信装置に送信するデータ通信装置であって、前記データ通信装置から送信された前記セグメントデータを格納する第１の受信バッファと、前記第１の受信バッファに格納された前記セグメントデータを格納する第２の受信バッファと、前記データ通信装置が前記セグメントデータのサイズと前記セグメントのサイズとを決定するのに必要な前記第１の受信バッファのサイズを、前記受信側データ通信装置の最大データ転送速度に対応するペイロードサイズを用いて決定し、前記第２の受信バッファのサイズを、前記第１の受信バッファのサイズを用いて決定する第１の決定手段と、前記第１の決定手段により決定された前記第１の受信バッファのサイズを示す情報を前記データ通信装置に送信する送信手段とを有する前記受信側データ通信装置から、前記第１の受信バッファのサイズを示す情報を受信する受信手段と、前記セグメントデータのサイズと前記セグメントのサイズとを、前記第１の受信バッファのサイズを用いて決定する第２の決定手段とを有することを特徴とする。
【００５１】
【発明の実施の形態】
以下、本発明のデータ通信システム、装置及び方法、並びに記録媒体について図面を用いて詳細に説明する。
尚、以下の実施の形態において、上記従来例と同一あるいはそれに相当する部材については同一符号を用いて説明を省略する。
【００５２】
（第１の実施の形態）
以下、第１の実施の形態の通信プロトコルを、図１０に示す通信システムに適用した場合について説明する。ここで、第１の実施の形態におけるコントローラ１０１をＴＶ１００１、ソース１０２をＤＶＣＲ１００４、デスティネーション１０３をプリンタ１００３とする。
【００５３】
第１の実施の形態において、ソース１０２は、１オブジェクトの情報データ（例えば、画像データ、音声データ、グラフィックスデータ、テキストデータ等）を所定のデータ量からなるセグメントに分割した後、そのセグメントを１つ以上のセグメントデータとしてAsynchronous転送する。
【００５４】
また、デスティネーション１０３は、ソース１０２からAsynchronous転送された１つ以上のAsynchronousパケットを受信し、各Asynchronousパケットに含まれるセグメントデータを受信バッファに格納する。
【００５５】
ここで、デスティネーション１０３の受信バッファは、デスティネーション１０３の具備するＣＳＲ（Control and Status Register）空間内に確保されている。セグメントデータは、各Asynchronousパケットに含まれるオフセットアドレスにより指定されるＣＳＲ空間内の所定の領域に対して書き込まれる。デスティネーション１０３は、ＣＳＲ空間に対する１セグメント分のデータの書き込みが完了する毎に、そのデータを内部メモリに格納する。尚、ＣＳＲ空間は、ISO/IEC 13213:1994規格に準拠している。
【００５６】
更に、コントローラ１０１は、デスティネーション１０３のバッファサイズの問合せ、ソース１０２から転送される情報データの選択等、ソース１０２とデスティネーション１０３との間の通信を管理する。
【００５７】
また、第１の実施の形態の通信プロトコルは、従来の通信プロトコルと同様に３つのフェーズ、即ち、コネクションフェーズ、伝送フェーズ、コネクションリリースフェーズから構成されている。ここで、第１の実施の形態におけるコネクションフェーズとコネクションリリースフェーズとは、従来の通信プロトコルにおける第１のフェーズ１２０４、第３のフェーズ１２０６と同様に実行することができる。従って、第1の実施の形態では、伝送フェーズについて詳細に説明する。
【００５８】
以下、図１及び図２を用いて第１の実施の形態の伝送フェーズについて説明する。
図１は、第１の実施の形態の伝送フェーズについて詳細に説明するシーケンスチャートである。また、図２は、第１の実施の形態の伝送フェーズの手順について詳細に説明するフローチャートである。
【００５９】
ステップＳ２０１において、コントローラ１０１は、デスティネーション１０３に対して、いくつかの通信パケットでAsynchronous転送される所定サイズのセグメントを受信するように指示する（１０４）。ここで、デスティネーション１０３は、コントローラ１０１からの指示に対してレスポンスを返す。
【００６０】
ステップＳ２０２において、コントローラ１０１は、ソース１０２に対して、情報データを所定サイズのセグメントに分割し、更にそのセグメントをいくつかの通信パケットでAsynchronous転送するように指示する（１０５）。ここで、ソース１０２は、コントローラ１０１からの指示に対してレスポンスを返す。
【００６１】
ステップＳ２０３において、コントローラ１０１からの指示の後、ソース１０２は、１セグメントデータを１つ以上のAsynchronousパケットにパケッタイズし、それらのAsynchronousパケットをデスティネーション１０３へ順次転送する（１０６）。
【００６２】
ここで、各Asynchronousパケットには、デスティネーション１０３の具備する受信バッファの所定の領域を指定するオフセットアドレスが格納されている。例えば、各セグメントの最初のAsynchronousパケットには、コントローラ１０１により通知された受信バッファの先頭アドレスが格納されている。また、それ以降のAsynchronousパケットには、その受信バッファの所定の領域を順次指定するオフセットアドレスが格納されている。
【００６３】
ステップＳ２０４において、１セグメント分のデータのAsynchronous転送が完了した後、ソース１０２は、１セグメント分のデータの転送の完了をコントローラ１０１に通知する（１０７）。ここで、ソース１０２は、コントローラ１０１からの指示を受信するまで、次のセグメントの転送を待機する。
【００６４】
ステップＳ２０５において、また、デスティネーション１０３も同様に、１セグメント分のデータの受信が完了したことをコントローラ１０１に通知する（１０８）。
【００６５】
ステップＳ２０６において、デスティネーション１０３は更に、次に受信するセグメントのために、新たに確保できる受信バッファのサイズをコントローラ１０１に通知する（１０９）。ここで、コントローラ１０１は、デスティネーション１０３より通知された新たなバッファサイズをＣＳＲ空間の所定の領域に格納して管理する。
【００６６】
以上の手順により、１セグメント分のデータの転送が終了する。
次以降のセグメントの転送を開始する場合、コントローラ１０１、ソース１０２、デスティネーション１０３は、１０４〜１０９に示す手順を繰り返し行えばよい（ステップＳ２０７）。その際、コントローラ１０１は、１セグメントの転送が終了する毎に、デスティネーション１０３より通知された新たなバッファサイズをソース１０２に通知する。
【００６７】
以上のように、第１の実施の形態では、１セグメント分の情報データの転送が完了する毎に、デスティネーション１０３がコントローラ１０１に対して新たなバッファサイズを通知するように制御することによって、各セグメントのデータ量を適応的に設定することができる。
【００６８】
（第２の実施の形態）
上述した第１の実施の形態では、１セグメント分の情報データを受信する毎に、デスティネーション１０３が、次に受信するセグメントのために新たに確保できる受信バッファのサイズをコントローラ１０１に通知するように制御する通信プロトコルについて説明した。
【００６９】
第２の実施の形態では、デスティネーション３０３が、次に受信するセグメントのために新たに確保できる受信バッファのサイズを直接ソース３０２に通知するように制御する通信プロトコルについて説明する。
【００７０】
以下、第２の実施の形態の通信プロトコルを、図１０に示す通信システムに適用した場合について説明する。ここで、第２の実施の形態におけるコントローラ３０１をＴＶ１００１、ソース３０２をＤＶＣＲ１００４、デスティネーション３０３をプリンタ１００３とする。
【００７１】
第２の実施の形態において、ソース３０２は、１オブジェクトの情報データ（例えば、画像データ、音声データ、グラフィックスデータ、テキストデータ等）を所定の大きさのセグメントに分割した後、そのセグメントを１つ以上のセグメントデータとしてAsynchronous転送する。
【００７２】
また、デスティネーション３０３は、ソース３０２からAsynchronous転送された１つ以上のAsynchronousパケットを受信し、各Asynchronousパケットに含まれるセグメントデータを受信バッファに格納する。ここで、デスティネーション３０３の受信バッファは、デスティネーション３０３の具備するＣＳＲ（Control and Status Register ）空間内に確保されている。
【００７３】
セグメントデータは、各Asynchronousパケットに含まれるオフセットアドレスが指定するＣＳＲ空間内の所定の領域に対して書き込まれる。デスティネーション３０３は、ＣＳＲ空間に対する１セグメント分のデータの書き込みが完了する毎に、そのデータを内部メモリに格納する。
【００７４】
更に、コントローラ３０１は、デスティネーション３０３が通信開始時に確保できる受信バッファサイズの問合せ、ソース３０２から転送される情報データの選択等、ソース３０２とデスティネーション３０３との間の通信を管理する。
【００７５】
また、第２の実施の形態の通信プロトコルは、従来の通信プロトコルと同様に３つのフェーズ、即ち、コネクションフェーズ、伝送フェーズ、コネクションリリースフェーズから構成されている。ここで、第２の実施の形態におけるコネクションフェーズとコネクションリリースフェーズとは、従来の通信プロトコルにおける第１のフェーズ１２０４、第３のフェーズ１２０６と同様に実行することができる。従って、第２の実施の形態では、伝送フェーズについて詳細に説明する。
【００７６】
以下、図３及び図４を用いて第２の実施の形態の伝送フェーズについて説明する。
図３は、第２の実施の形態の伝送フェーズについて詳細に説明するシーケンスチャートである。また、図４は、第２の実施の形態の伝送フェーズの手順について詳細に説明するフローチャートである。
【００７７】
ステップＳ４０１において、コントローラ３０１は、デスティネーション２０３に対して、いくつかの通信パケットでAsynchronous転送される所定サイズのセグメントを受信するように指示する（３０４）。ここで、デスティネーション３０３は、コントローラ３０１からの指示に対してレスポンスを返す。
【００７８】
ステップＳ４０２において、コントローラ３０１は、ソース３０２に対して、情報データを所定サイズのセグメントに分割し、更にそのセグメントをいくつかの通信パケットでAsynchronous転送するように指示する（３０５）。ここで、ソース３０２は、コントローラ３０１からの指示に対してレスポンスを返す。
【００７９】
ステップＳ４０３において、コントローラ３０１からの指示の後、ソース３０２は、１セグメントを１つ以上のAsynchronousパケットにパケッタイズし、それらのAsynchronousパケットをデスティネーション３０３へ順次転送する（３０６）。ここで、各Asynchronousパケットには、デスティネーション３０３の具備する受信バッファの所定の領域を指定するオフセットアドレスが格納されている。例えば、各セグメントの最初のAsynchronousパケットには、コントローラ３０１により通知された受信バッファの先頭アドレスが格納されている。また、それ以降のAsynchronousパケットには、その受信バッファの所定の領域を順次指定するオフセットアドレスが格納されている。
【００８０】
ステップＳ４０４において、１セグメント分のデータのAsynchronous転送が完了した後、ソース３０２は、１セグメント分のデータの転送の完了をコントローラ３０１に通知する（３０７）。ここで、ソース３０２は、コントローラ３０１からの指示を受信するまで、次のセグメントの転送を待機する。
【００８１】
ステップＳ４０５において、デスティネーション３０３も同様に、１セグメント分のデータの受信が完了したことをコントローラ３０１に通知する（３０８）。ステップＳ４０６において、デスティネーション３０３は更に、次に受信するセグメントのために、新たに確保できる受信バッファのサイズをソース３０２に通知する（３０９）。
【００８２】
ステップＳ４０７において、ソース３０２は、この受信バッファのサイズをＣＳＲ空間の所定の領域に格納すると共に、この受信バッファのサイズを受信したことをコントローラ３０１に通知する（３１０）。この通知により、コントローラ３０１は、次のセグメントの転送の開始を指示することができる。
【００８３】
以上の手順により、１セグメント分のデータの転送が終了する。次以降のセグメントの転送を開始する場合、コントローラ３０１、ソース３０２、デスティネーション３０３は、３０４〜３１０に示す手順を繰り返し行えばよい（ステップＳ４０８）。
【００８４】
その際、ソース３０２は、１セグメントの転送が終了する毎に、デスティネーション３０３より通知される新たな受信バッファサイズを受信し、そのサイズに応じて次に転送すべきセグメントのサイズを決定する。以上のように、第２の実施の形態では、第１の実施の形態と同様に、１セグメント分の情報データの転送が完了する毎に、デスティネーション３０３がソース３０２に対して新たな受信バッファサイズを通知するように制御することによって、各セグメントのデータ量を適応的に設定することができる。
【００８５】
また、第２の実施の形態では、全データの通信中に変更されたデスティネーション３０３の受信バッファサイズをコントローラ３０１に管理させる必要がなくなり、ソース３０２とデスティネーション３０３との間で管理させることができる。これにより、第１の実施の形態に比べてコントローラに対する負荷をより小さくすることができる。
【００８６】
（第３の実施の形態）
上述した第２の実施の形態では、コントローラ３０１が、ソース３０２とデスティネーション３０３との間のコネクションを設定すると共に、各セグメントの転送の開始をコントローラ３０１により指示させるように制御する通信プロトコルについて説明した。
【００８７】
第３の実施の形態では、コントローラ３０１が、ソース３０２とデスティネーション３０３との間のコネクションを設定した後、各セグメントの転送を、コントローラ３０１を介することなく、ソース３０２とデスティネーション３０３との間で制御する通信プロトコルについて説明する。
【００８８】
以下、第３の実施の形態の通信プロトコルを、図１０に示す通信システムに適用した場合について説明する。ここで、第３の実施の形態におけるコントローラ５０１をＴＶ１００１、ソース５０２をＤＶＣＲ１００４、デスティネーション５０３をプリンタ１００３とする。
【００８９】
第３の実施の形態において、ソース５０２は、１オブジェクトの情報データ（例えば、画像データ、音声データ、グラフィックスデータ、テキストデータ等）を所定の大きさのセグメントに分割した後、そのセグメントを１つ以上のセグメントデータとしてAsynchronous転送する。
【００９０】
また、デスティネーション５０３は、ソース５０２からAsynchronous転送された１つ以上のAsynchronousパケットを受信し、各Asynchronousパケットに含まれるセグメントデータを受信バッファに格納する。ここで、デスティネーション５０３の受信バッファは、デスティネーション５０３の具備するＣＳＲ（Control and Status Register）空間内に確保されている。
【００９１】
セグメントデータは、各Asynchronousパケットに含まれるオフセットアドレスが指定するＣＳＲ空間内の所定の領域に対して書き込まれる。デスティネーション５０３は、ＣＳＲ空間に対する１セグメント分のデータの書き込みが完了する毎に、そのデータを内部メモリに格納する。
【００９２】
更に、コントローラ５０１は、ソース５０２及びデスティネーション５０３に対するバッファ領域の開放の指示、ソース５０２に対するオブジェクトの転送開始の指示等、ソース５０２とデスティネーション５０３との間の通信を管理する。
【００９３】
以下、第３の実施の形態の通信プロトコルについて説明する。
図５は、第３の実施の形態の通信プロトコルについて詳細に説明するシーケンスチャートである。また、図６は、第３の実施の形態の通信プロトコルの手順について詳細に説明するフローチャートである。
【００９４】
第３の実施の形態の通信プロトコルは、従来の通信プロトコルと同様に３つのフェーズ、即ち、コネクションフェーズ、伝送フェーズ、コネクションリリースフェーズから構成されている。
【００９５】
まず、コネクションフェーズについて説明する。
ステップＳ６０１において、コントローラ５０１は、ソース５０２とデスティネーション５０３との間のコネクションを設定し、デスティネーション５０３に対して受信バッファの開放と１オブジェクトの情報データの受信開始を指示する（５０４）。ここで、デスティネーション５０３は、コントローラ５０１からの指示に対してレスポンスを返す。
【００９６】
ステップＳ６０２において、コントローラ５０１は、と共に、ソース５０２に対して送信バッファの開放と１オブジェクトの情報データの送信開始を指示する（５０５）。ここで、ソース５０２は、コントローラ５０１からの指示に対してレスポンスを返す。
【００９７】
次に、伝送フェーズについて説明する。
ステップＳ６０３において、ソース５０２は、デスティネーション５０３に対して１オブジェクトの情報データのデータサイズを通知する（５０６）。デスティネーション５０３は、このデータサイズをＣＳＲ空間の所定の領域に格納する。
【００９８】
ステップＳ６０４において、デスティネーション５０３は、受信バッファのサイズと１Asynchronousパケットにて受信可能なデータサイズ（即ち、ペイロードサイズ）を通信する（５０７）。ソース５０２は、この受信バッファサイズとペイロードサイズとをＣＳＲ空間の所定の領域に格納する。
【００９９】
ステップＳ６０５において、ソース５０２は、受信バッファサイズとペイロードサイズとに応じて１オブジェクトの情報データを所定サイズのセグメントに分割し、そのセグメントを１つ以上のAsynchronousパケットにパケッタイズし、それらを順次デスティネーション５０３へ転送する（５０８）。１セグメントデータの転送完了後、ソース５０２は、デスティネーション５０３からの受信完了の通知があるまで次のセグメントの転送を待機する。
【０１００】
ここで、各Asynchronousパケットには、デスティネーション５０３の具備する受信バッファの所定の領域を指定するオフセットアドレスが格納されている。例えば、各セグメントの最初のAsynchronousパケットには、ソース５０２により通知された受信バッファの先頭アドレスが格納されている。また、それ以降のAsynchronousパケットには、その受信バッファの所定の領域を順次指定するオフセットアドレスが格納されている。
【０１０１】
ステップＳ６０６において、１セグメント分のデータの受信後、デスティネーション５０３は、１セグメント分のデータの転送の完了をソース５０２に通知する（５０９）。
【０１０２】
ステップＳ６０７において、デスティネーション５０３は更に、次に受信するセグメントのために、新たに確保できる受信バッファのサイズをソース５０２に通知する（５１０）。ソース５０２は、この受信バッファサイズをＣＳＲ空間の所定の領域に格納すると共に、この受信バッファサイズとペイロードサイズとに応じて次に転送するセグメントの大きさを設定する。
【０１０３】
以上の手順により、１セグメント分のデータの転送が終了する。
次以降のセグメントの転送を開始する場合、コントローラ５０１、ソース５０２、デスティネーション５０３は、５０４〜５１０に示す手順を繰り返し行えばよい（ステップＳ６０８）。その際、ソース５０２は、１セグメントの転送が終了する毎に、デスティネーション５０３より通知される新たな受信バッファサイズを受信し、そのサイズに応じて次に転送すべきセグメントのサイズを決定する。１オブジェクトの情報データの転送が完了した後、ソース５０２は、転送の完了をコントローラ５０１に通知する（５１１）。
【０１０４】
また、デスティネーション５０３も、１オブジェクトの情報データの受信が完了したことをコントローラ５０１に通知する（５１２）。
以上の手順により伝送フェーズが終了する。
【０１０５】
コネクションリリースフェーズにおいて、コントローラ５０１は、ソース５０２及びデスティネーション５０３から通信完了の通知を受けた後、デスティネーション５０３の受信バッファを自己の管理下から解放する（５１３）し、ソース５０２の送信バッファを自己の管理下から解放する（５１４）。
【０１０６】
以上のように、第３の実施の形態では、１セグメント分の情報データの転送が完了する毎に、デスティネーション５０３がソース５０２に対して新たなバッファサイズを通知するように制御することによって、各セグメントのデータ量を適応的に設定することができる。
【０１０７】
また、第３の実施の形態では、第２の実施の形態と同様に、全データの通信中に変更されたデスティネーション５０３の受信バッファサイズをコントローラ５０１に管理させる必要がなくなり、ソース５０２とデスティネーション５０３との間で管理させることができる。これにより、第１の実施の形態に比べてコントローラに対する負荷をより小さくすることができる。
【０１０８】
更に、第３の実施の形態では、ソース５０２とデスティネーション５０３との間のコネクションの設定後、各セグメントのサイズ設定と各セグメントの転送とをソース５０２とデスティネーション５０３との間で制御し、実行することができる。これにより、第１、第２の実施の形態に比べてコントローラに対する負荷を減らし、通信手順をより簡素化することができる。
【０１０９】
（第４の実施の形態）
この第４の実施の形態では、上述した第３の実施の形態と同様に、コントローラ５０１が、ソース５０２とデスティネーション５０３との間のコネクションを設定した後、各セグメントデータの転送を、コントローラ５０１を介することなく、ソース５０２とデスティネーション５０３との間で制御する通信プロトコルについて説明する。
【０１１０】
以下、第４の実施の形態の通信プロトコルを、図１０に示す通信システムに適用した場合について説明する。ここで、第４の実施の形態におけるコントローラ７０１をＴＶ１００１、ソース７０２をＤＶＣＲ１００４、デスティネーション７０３をプリンタ１００３とする。
【０１１１】
第４の実施の形態において、ソース７０２は、１オブジェクトの情報データ（例えば、画像データ、音声データ、グラフィックスデータ、テキストデータ等）を所定のデータ量からなるセグメントに分割した後、そのセグメントを更に１つ以上のセグメントデータとしてAsynchronous転送する。
【０１１２】
また、デスティネーション７０３は、ソース７０２からAsynchronous転送された１つ以上のAsynchronousパケットを受信し、各Asynchronousパケットに含まれるセグメントデータを受信バッファに格納する。ここで、デスティネーション７０３の受信バッファは、デスティネーション７０３の具備するＣＳＲ（Control and Status Register）空間内に確保されている。
【０１１３】
各セグメントデータは、各Asynchronousパケットに含まれるオフセットアドレスが指定するＣＳＲ空間内の所定の領域に対して書き込まれる。デスティネーション７０３は、ＣＳＲ空間に対する１セグメント分のデータの書き込みが完了する毎に、そのデータを内部メモリに格納する。
【０１１４】
以下、図８、及び図９を用いてソース７０２及びデスティネーション７０３の具備するバッファの構成について詳細に説明する。
図８、図９において、ソース７０２は、１つの受信バッファ、即ち「Source Buffer １」を具備している。ここで、Source Buffer １は、ソース７０２の具備するＣＳＲ空間の所定の領域に確保されている。
【０１１５】
また、図８、図９において、デスティネーション７０３は、２つの受信バッファ、即ち「Destination Buffer１」と「Destination Buffer２」とを具備している。ここで、Destination Buffer１とDestination Buffer２とは、デスティネーション７０３の具備するＣＳＲ空間の所定の領域に確保されている。
【０１１６】
図８、図９に示すSource Buffer １、Destination Buffer１、Destination Buffer２のサイズは以下のように定義される。
まず、第４の実施の形態において、Destination Buffer１及びDestination Buffer２のサイズを以下のように定義する。
【０１１７】
Destination Buffer２＝（max ＿rec ）×Ｎ（Ｎ＝１, ２, ３・・・ ）…（式１）
ここで、Destination Buffer２は、１セグメントの大きさに対応している。また、Ｎは整数で、１セグメントを構成するセグメントデータの数に対応している。
【０１１８】
Destination Buffer１＝max ＿rec …（式２）
ここで、「max ＿rec 」とは、IEEE1394-1995 規格に準拠したAsynchronous Writeトランザクションに基づいて受信されるAsynchronousパケットにおいて、デスティネーション７０３の受信可能なペイロードサイズの最大値を示す。尚、「max ＿rec 」のサイズは、デスティネーション７０３の対応する最大データ転送速度に応じて異なる。「max ＿rec 」は、以下のように定義される。
【０１１９】
max ＿rec ＝４Byte×２L （Ｌ＝0,1,2…） …（式３）
ここで、Ｌは整数である。
【０１２０】
（式１）及び（式２）からDestination Buffer１とDestination Buffer２との関係は、以下のようになる。
【０１２１】
Destination Buffer２＝(Destination Buffer １) ×Ｎ （Ｎ＝1,2,3…） …（式４）
また、第４の実施の形態において、Source Buffer １を以下のように定義する。
【０１２２】
Source Buffer１＝４Byte×２M （Ｍ＝0,1,2…） …（式５）
（式４）において、Source Buffer １とは、ソース７０２の送信可能なAsynchronousパケットのペイロードサイズの最大値を示す。尚、Source Buffer １のサイズは、ソース７０２の対応する最大データ転送速度に応じて異なる。ここで、Ｍは整数である。
【０１２３】
（式３）及び（式５）からmax ＿rec とSource Buffer １との関係は、以下の（式６）のようになる。
Source Buffer １：max ＿rec ＝２M ：２L …（式６）
式により、max ＿rec は、
【０１２４】
となる。
【０１２５】
（式７）及び（式１）からDestination Buffer２は、
Destination Buffer２＝（Source Buffer １）×｛２(L-M) ｝×Ｎ…（式８）
となる。
【０１２６】
（式８）により、ソース７０２は、ペイロードのサイズがSource Buffer １分となるAsynchronousパケットを、[ ｛２(L-M) ｝×Ｎ] 回送信することによってDestination Buffer２を一杯にすることができる。
【０１２７】
このように定義することにより、Destination Buffer２のサイズを、Source Buffer １のサイズとDestination Buffer１のサイズとによって決定することができる。
【０１２８】
例えば、図８において、Source Buffer １＝Destination Buffer１（＝max ＿rec ）の場合、式からＭ＝Ｌとなる。この場合、式により、Destination Buffer２のサイズは、Source Buffer １のサイズのＮ倍となる。従って、Ｎの値を設定することにより、各セグメントの大きさを可変的に制御することができる。
【０１２９】
また、図８において、Source Buffer １＞Destination Buffer１（＝max ＿rec ）の場合、式より、Ｍ＞Ｌとなる。この場合、ソース７０２は、Source Buffer １のサイズをDestination Buffer１のサイズと等しくなるように設定する。これにより、Destination Buffer２のサイズは、Source Buffer １のサイズのＮ倍となる。従って、Ｎの値を設定することにより、各セグメントの大きさを可変的に制御することができる。
【０１３０】
更に、図９において、Source Buffer １＜Destination Buffer１（＝max ＿rec ）の場合、式より、Ｍ＜Ｌとなる。この場合、デスティネーション７０３は、Destination Buffer１のサイズをSource Buffer１のサイズと等しくなるように設定する。これにより、Destination Buffer２のサイズは、Source Buffer １のサイズの[ ｛２(L-M) ｝×Ｎ] 倍となる。従って、Ｍ、Ｎ及びＬの値を設定することにより、各セグメントの大きさを可変的に制御することができる。
【０１３１】
更に、第４の実施の形態において、コントローラ７０１は、ソース７０２及びデスティネーション７０３に対するバッファ領域の開放の指示、ソース７０２の具備するサブユニットに対するオブジェクトの転送準備の指示等、ソース７０２とデスティネーション７０３との間のコネクションを管理する。
【０１３２】
以下、第４の実施の形態の通信プロトコルについて説明する。
図７は、第４の実施の形態の通信プロトコルについて詳細に説明するシーケンスチャートである。
【０１３３】
第４の実施の形態の通信プロトコルは、従来の通信プロトコルと同様に３つのフェーズ、即ち、コネクションフェーズ、伝送フェーズ、コネクションリリースフェーズから構成されている。
まず、コネクションフェーズについて説明する。
【０１３４】
（１）図７に示す手順７０４の説明する。
コントローラ７０１は、デスティネーション７０３に対してアプリケーションＣＴＳ（Command Control Set ）コマンド（図７に示す「SubUnit Appli Cmd 」）を発行し、デスティネーション７０３の具備するサブユニットに対して受信準備を行うように制御する。第４の実施の形態において、デスティネーション７０３はプリンタ１００３である。従って、コントローラ７０１は、プリンタ１００３の具備するプリンタユニットに対して、ＣＴＳコマンド形式のプリントコマンドを発行する。
【０１３５】
デスティネーション７０３は、図８、図９に示すように、Destination Buffer１とDestination Buffer２の２つの受信バッファを具備している。上述のアプリケーションＣＴＳコマンドを受信したデスティネーション７０３は、Destination Buffer１とDestination Buffer２のイニシャライズ、及びサブユニットの具備するアプリケーションメモリのイニシャライズ等を行う。サブユニットが受信可能な状態であれば、コントローラ７０１に対してInterim レスポンス（図７に示す「SubUnit Appli Resp」）をＣＴＳコマンド形式で返す。
【０１３６】
（２）図７に示す手順７０５の説明する。
次に、コントローラ７０１は、ソース７０２に対してアプリケーションＣＴＳコマンド（図７に示す「SubUnit Appli Cmd 」）を発行し、ソース７０２の具備するサブユニットに対して送信準備を行うように制御する。第４の実施の形態において、ソース７０２は、ＤＶＣＲ１００４である。従って、コントローラ７０１は、ＤＶＣＲ１００４の具備するカムコーダユニットに対して、ＣＴＳコマンド形式の再生コマンドを発行する。
【０１３７】
デスティネーション７０３は、図８、図９に示すように、Source Buffer１を具備している。上述のアプリケーションＣＴＳコマンドを受信したソース７０２は、Source Buffer １のイニシャライズを行う。サブユニットが送信可能な状態であれば、コントローラ７０１に対してInterim レスポンス（図７に示す「SubUnit Appli Resp」）をＣＴＳコマンド形式で返す。
【０１３８】
次に伝送フェーズについて説明する。
（３）図７に示す手順７０６の説明。
Interim レスポンスを送信したソース７０２は、サブユニットのアプリケーションメモリに格納されている１オブジェクトの情報データの送信準備を行い、その準備が完了したことをデスティネーション７０３に対して通知する。
【０１３９】
IEEE1394-1995 規格に準拠したAsynchronous Writeトランザクションを用いて、送信準備の完了を通知する場合、ソース７０２は、デスティネーション７０３の具備する所定のレジスタに対して送信準備の完了を示す「Ready to send 」情報を書き込む。尚、「Ready to send 」情報には、上述のＭの値が含まれている。
【０１４０】
ここで、所定のレジスタは、デスティネーション７０３の具備するＣＳＲ空間内の所定のアドレスに設けられている。従って、ソース７０２は、その所定のアドレスを指定したAsynchronous Writeトランザクションを用いて「Ready to send 」情報の書き込みを行う。
【０１４１】
尚、第４の実施の形態では、所定のレジスタに「Ready to send」情報を書き込む処理について説明したが、該レジスタの所定のフィールドに「Ready to send」を示す特定のフラグを設けて、該フラグを書き換えるように処理してもよい。
【０１４２】
（４）図７に示す手順７０７の説明。
Interimレスポンスを送信し、ソース７０２から「Ready to send 」情報を受信したデスティネーション７０３は、ソース７０２の具備する所定のレジスタに対して「Ready to receive」情報とDestination Buffer１、２に関する情報（図７に示す「Buffer Info 」）とを書き込む。
【０１４３】
ここで、Destination Buffer１に関する情報とは、上述のＬの値と上述のＭの値とによって設定されるデスティネーションの受信可能なペイロードサイズの最大値であり、セグメントデータのサイズを示す情報である。また、Destination Buffer２に関する情報とは、上述のＮの値により設定されるセグメントのサイズを示す情報である。ここで、セグメントのサイズは、セグメントデータのサイズのＮ倍になるように設定される。また、デスティネーション７０３は、Ｎの値を各セグメントによって可変的に設定することができる。
【０１４４】
ここで、所定のレジスタは、ソース７０２の具備するＣＳＲ空間内の所定のアドレスに設けられている。従って、デスティネーション７０３は、その所定のアドレスを指定したAsynchronous Writeトランザクションを用いてこれらの情報の書き込みを行う。
【０１４５】
（５）図７に示すData Transfer７０８についての説明。
ソース７０２は、デスティネーション７０３からの「Ready to receive」情報を受信した後、Destination Buffer１、２に関する情報を用いて、１オブジェクトの情報データをＮ個のセグメントデータからなるセグメントに分割する。
【０１４６】
ソース７０２は、各セグメントデータを順次Source Buffer １に格納した後、Asynchronous Writeトランザクションを用いて順次転送する。
ここで、各セグメントデータは、ＣＳＲ空間内に確保されたDestination Buffer１に連続的に書き込まれる。Destination Buffer１に書き込まれたセグメントデータは、次のセグメントデータが受信されるまでに、Destination Buffer２に格納される。各セグメントデータの送信は、デスティネーション７０３により確保されたDestination Buffer２が一杯になるまで実行される。
【０１４７】
（６）図７に示す手順７０９の説明。
ソース７０２は、Ｎ個のセグメントデータを送信した後、図７に示す「End of Segment」情報をデスティネーション７０３に送信する。この「End of Segment」情報は、Asynchronous Writeトランザクションを用いて、「Ready to send」情報を書き込むレジスタに書き込まれる。
【０１４８】
ここで、１オブジェクトの情報データを構成する全てのセグメントデータの送信が完了した場合、ソース７０２は、Destination Buffer２の全てが満たされていなくても、図７に示す「End of Data 」情報をデスティネーション７０３に送信する。この「End of Data 」情報は、Asynchronous Writeトランザクションを用いて、「Ready to send 」情報を書き込むレジスタに書き込まれる。
【０１４９】
（７）図７に示す手順７１０の説明。
デスティネーション７０３及びそのサブユニットは、「End of Segment」情報を受信すると、１セグメント分の情報データ（Ｎ個のセグメントデータからなる）の送信が終了したことを認識する。
【０１５０】
デスティネーション７０３は、Destination Buffer２に格納されたＮ個のセグメントデータを、サブユニット内部のアプリケーションメモリ領域に格納する。その後、デスティネーション７０３は、Asynchronous Writeトランザクションを用いて、「Ready to receive」情報をソース７０２の具備する所定のレジスタに対して書き込む。
【０１５１】
「Ready to receive」情報を受信したソース７０２は、次のセグメントの送信準備が完了した後、再び、図７の７０６〜７１０を実行し、Destination Buffer２分のデータを送信する。
【０１５２】
また、「End of Data 」情報を受信した場合、デスティネーション７０３は、１オブジェクトの情報データを構成する全てのセグメントデータの送信が終了したことを認識する。その後、デスティネーション７０３は、図７に示す「End of Conf 」情報をソース７０２に通知する。
この「End of Data 」情報は、Asynchronous Writeトランザクションを用いて、「Ready to send」情報を書き込むレジスタに書き込まれる。
以上の手順により伝送フェーズが終了する。
また、コネクションリリースフェーズについて説明する。
【０１５３】
（８）図７に示す手順７１１の説明。
「End of Conf 」情報を受信したソース７０２は、コントローラ７０１に対して、１オブジェクトの情報データを構成する全てのセグメントデータの送信が終了したことを通知する。この通知は、ＣＴＳコマンド形式の「Accepted response」を用いて行われる。
【０１５４】
（９）図７に示す手順７１２の説明。
「End of Conf 」情報を送信したデスティネーション７０３は、コントローラ７０１に対して、１オブジェクトの情報データを構成する全てのセグメントデータの受信が終了したことを通知する。この通知は、ＣＴＳコマンド形式の「Accepted response 」を用いて行われる。
【０１５５】
以上のように、第４の実施の形態では、Source Buffer １、Destination Buffer１、Destination Buffer２の関係を定義した。これにより、デスティネーション７０３は、ソース７０２から通知されるＭの値と、Ｎ及びＬの値によって各セグメントのサイズを可変的に設定することができる。また、セグメントのサイズを決定するための演算を容易にすることができる。
【０１５６】
また、第４の実施の形態では、１セグメント分の情報データの転送が完了する毎に、デスティネーション７０３がソース７０２に対して新たなバッファサイズを通知するように制御することによって、各セグメントのデータ量を適応的に設定することができる。
【０１５７】
また、第４の実施の形態では、第３の実施の形態と同様に、全データの通信中に変更されたデスティネーション７０３の受信バッファサイズをコントローラ７０１に管理させる必要がなくなり、ソース７０２とデスティネーション７０３との間で管理させることができる。これにより、第１の実施の形態に比べてコントローラに対する負荷をより小さくすることができる。
【０１５８】
更に、第４の実施の形態では、ソース７０２とデスティネーション７０３との間のコネクションの設定後、各セグメントのサイズ設定と各セグメントの転送とをソース７０２とデスティネーション７０３との間で制御し、実行することができる。これにより、第１、第２の実施の形態に比べてコントローラに対する負荷を減らし、通信手順をより簡素化することができる。
【０１５９】
また、第４の実施の形態によれば、各セグメントの大きさをデスティネーション７０３の受信可能なペイロードサイズの整数倍に設定することができる。これにより、ソースから送出されるパケットの数を管理することによって、各セグメント分のデータの送信を管理でき、ソース側の送信制御が容易になる。
【０１６０】
更に、第４の実施の形態によれば、デスティネーションの受信バッファのサイズを、デスティネーションの受信可能なペイロードサイズの整数倍に設定することができる。これにより、デスティネーションにおいて確保される受信バッファを有効に利用できるとともに、各セグメントデータを書き込むアドレスの制御が容易になる。
【０１６１】
（他の実施の形態）
上述の各実施の形態は、以下のように実現することも可能である。
例えば、上述した実施の形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、本実施の形態のシステム或いは装置の具備する制御部（マイクロコンピュータを含む）に供給するように構成することもできる。
【０１６２】
そして、本実施の形態のシステム或いは装置の具備する制御部が、該記録媒体に格納されたプログラムコードを読み出し、上述した実施の形態の機能を実現するようにシステム或いは装置の動作を制御するように構成しても本発明の実施の形態を実現することができる。
【０１６３】
例えば、第１の実施の形態の図１、第２の実施の形態の図３、第３の実施の形態の図５、第４の実施の形態の図７に示した処理手順及び機能を実現するプログラムコードを格納した記録媒体を図７に示す各ノードの制御部７０６に供給する。そして、各ノードの制御部７０６が、その記録媒体に格納されたプログラムコードを読み出し、各実施の形態の機能を実現するように、図７に示す各ノードの処理回路を動作させるようにしてもよい。
【０１６４】
この場合、記録媒体から読み出されたプログラムコード自体が上述した実施の形態の機能を実現することになり、そのプログラムコードを記憶した記録媒体は、本発明の一部の構成要件になる。
【０１６５】
プログラムコードを供給するための記録媒体としては、例えば、フロッピディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。
【０１６６】
また、制御部上で稼動しているＯＳ（オペレーティングシステム）或いはアプリケーションソフト等が、記録媒体より読み出したプログラムコードの指示に基づき、本実施の形態のシステム或いは装置の動作を制御することにより、上述した実施の形態の機能を実現する場合も本発明に含まれることは言うまでもない。
【０１６７】
更に、記録媒体から読み出されたプログラムコードが、制御部に接続された機能拡張ボード或いは機能拡張ユニットの具備するメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットの具備する制御部が本実施の形態のシステム或いは装置の動作を制御することにより、上述した実施の形態の機能が実現される場合も本発明に含まれることは言うまでもない。尚、本発明はその精神、またはその主要な特徴から逸脱することなく、様々な形で実施することができる。
【０１６８】
例えば、本実施の形態の伝送フェーズでは、IEEE1394-1995 規格に準拠したAsynchronous Writeトランザクションを用いて、１オブジェクトの情報データの転送を実行する場合について説明したが、それに限るものではない。例えば、IEEE1394.a規格に準拠したAsynchronous Streamsパケットを用いたトランザクションにより１オブジェクトの情報データを送信するように構成してもよい。尚、Asynchronous Streamsパケットの構成は、IEEE1394-1995規格に準拠したIsochronousパケットと同じ構成である。
【０１６９】
この場合、各セグメントデータを送信するパケットは、特定の宛先に対して１対１に送信されるものではなく、所定のチャネル番号を指定し、ブロードキャストされるものである。従って、上述の実施の形態はあらゆる点おいて単なる例示に過ぎず、限定的に解釈してはならない。
【０１７０】
【発明の効果】
以上のように、本発明に係るデータ通信システム及びデータ通信装置によれば、送信すべきデータを複数のセグメントに分割し、当該セグメントを複数のセグメントデータに分割し、当該複数のセグメントデータを受信側データ通信装置に送信する場合において、当該セグメントのデータ量を適切に制御することができる。
【図面の簡単な説明】
【図１】本発明に係る第１の実施の形態の伝送フェーズについて詳細に説明するシーケンスチャートである。
【図２】第１の実施の形態の伝送フェーズの手順について詳細に説明するフローチャートである。
【図３】第２の実施の形態の伝送フェーズについて詳細に説明するシーケンスチャートである。
【図４】第２の実施の形態の伝送フェーズの手順について詳細に説明するフローチャートである。
【図５】第３の実施の形態の通信プロトコルについて詳細に説明するシーケンスチャートである。
【図６】第３の実施の形態の通信プロトコルの手順について詳細に説明するフローチャートである。
【図７】第４の実施の形態の通信プロトコルについて詳細に説明するシーケンスチャートである。
【図８】ソース７０２及びデスティネーション７０３の具備するバッファの構成について説明する図である。
【図９】ソース及びデスティネーションの具備するバッファの構成について説明する図である。
【図１０】従来の通信システムの構成を示す図である。
【図１１】従来の通信システムの具備するデータ転送方式について説明する図である。
【図１２】従来の通信プロトコルについて説明するシーケンスチャートである。
【図１３】ソース１２０２からAsynchronous転送される情報データとデスティネーション１２０３の受信バッファとの関係を説明する図である。
【図１４】図１２における第２のフェーズについて詳細に説明するシーケンスチャートである。
【符号の説明】
１０１ コントローラ
１０２ ソース
１０３ デスティネーション
【発明の属する技術分野】
本発明は、データ通信システム及びデータ通信装置に関する。
【０００２】
【従来の技術】
最近、１つの伝送路を介して複数の電子機器を接続し、各機器間における制御信号と情報信号（ビデオ信号、オーディオ信号、グラフィックスデータ、テキストデータ等）との通信を混在させて行うように制御する通信システムが開発されている。
【０００３】
また、このような通信システムにおいて、各種の情報信号を各機器間において非同期に伝送させる通信プロトコルが開発されている。このような通信システムを実現する技術の一つに、高性能シリアルバスに関するＩＥＥＥ１３９４―１９９５規格（以下、１３９４規格）がある。
【０００４】
以下、図１０を用いて１３９４規格に準拠した従来の通信システムの構成について説明する。図１０において、各機器は１３９４規格に準拠したデジタルインタフェース１００５を具備している。
【０００５】
図１０の通信システムは、ＴＶ１００１、デジタルビデオテープレコーダ（以下、ＤＶＴＲ）１００２、プリンタ１００３、デジタルカムコーダ（以下、ＤＶＣＲ）１００４により構成されている。各機器は、１３９４規格に準拠した通信ケーブルを介して接続されている。
【０００６】
ここで、通信ケーブルは、データの転送や調停信号の通信に用いられる２組のシールド付きより対線により構成されている４ピンコネクタケーブルと、２組のより対線と電源供給用のペア線からなる６ピンコネクタケーブルとがある。尚、２組のより対線を用いて伝送されるデータは、ＤＳ−Ｌｉｎｋ方式により符号化されたデータである。
【０００７】
上述の通信システムでは、電源投入時、新たな機器の接続や切り離し等の接続構成の変化に応じてバスリセットを自動的に行う。ここで、バスリセットとは、通信システムを構成する各機器（以下、ノード）が、今までの認識していた通信システムの接続構成と各機器の通信アドレス（以下、ノードＩＤ）とを初期化し、新たな接続構成の再認識と通信アドレスの再設定とを行うため処理である。
【０００８】
以下、バスリセットの処理手順を簡単に説明する。この手順は、通信システムにおける階層的な接続構成の認識と各ノードに対する物理的な通信アドレスの付与からなる。
【０００９】
接続構成の認識は、バスリセットの開始後、各ノードが親子関係を宣言し合うことによって実行される。各ノードは、各ノード間の親子関係を決定することにより、通信システムをツリー構造（階層構造）として認識する。尚、各ノード間の親子関係は、通信システムの接続状態や各ノードの機能に依存するため、バスリセット毎に同じ関係になることはない。
【００１０】
例えば、図３の通信システムでは、まず、プリンタ１００３（以下、ノードＤ）とＤＶＴＲ１００２（以下、ノードＣ）との間で親子関係を設定する。次に、ＤＶＣＲ１００４（以下、ノードＢ）とＴＶ１００１（以下、ノードＡ）との間、及びノードＣとノードＡとの間で親子関係を設定する。
【００１１】
最終的に全てのノードの親（或いは上位）と認識された機器がルート・ノードとなり、この通信システムのバス使用権の調停を管理する。図１０の通信システムでは、ノードＡがルート・ノードとなる。
ルート・ノードの決定後、通信システムを構成する各ノードは、ノードＩＤの設定を自動的に開始する。
【００１２】
ノードＩＤの設定は、基本的に親ノードがポート番号の若い通信ポートに接続された子ノードに対して物理アドレスの設定を許可し、更にその子ノードが自分の子ノードに対して順番に設定の許可を与えることによって実行される。自己のノードＩＤを設定したノードは、セルフＩＤパケットを送出し、自己に付与されたノードＩＤを他のノードに対して通知する。最終的に全ての子ノードのＩＤ設定が終了した後、親ノードは自己のノードＩＤを設定する。
【００１３】
以上の処理を繰り返し実行することによって、ルート・ノードのノードＩＤが一番最後に設定される。尚、各ノードに割り当てられるノードＩＤは、各機器の親子関係に依存するため、バスリセット毎に同じノードＩＤが設定されることはない。
【００１４】
以下、図１０の通信システムを用いてノードＩＤの自動設定処理を説明する。尚、本実施例では、接続構成の認識後、ノードＡがルート・ノードとなった場合について説明する。
【００１５】
図１０において、ルート・ノードであるノードＡはまず、「ポート１」の通信ポートに接続されているノード、即ちノードＢに対してノードＩＤの設定を許可する。
【００１６】
ノードＢは、自己のノードＩＤを「＃０」に設定し、その結果をセルフＩＤパケットとして通信システムを構成する全てのノードに対してブロードキャストする。ここで、ブロードキャストとは、所定の情報を不特定多数のノードを宛先として送出することである。
【００１７】
この結果、全てのノードは、「ノードＩＤ「＃０」は割当済である」と認識し、次にノードＩＤの設定を許可されたノードは「＃１」を設定する。
ノードＢの設定後、ノードＡは、「ポート２」の通信ポートに接続されているノード、即ちノードＣに対してノードＩＤの設定を許可する。
【００１８】
ノードＣは更に、子ノードの接続されている通信ポートの内、最も若いポート番号の通信ポートから順に設定の許可を与える。つまり、ノードＤに対して許可を与え、その許可を受けたノードＤがノードＩＤ「＃１」を設定した後、セルフＩＤパケットをブロードキャストする。
【００１９】
ノードＤの設定後、ノードＣが自己のノードＩＤを「＃３」に設定し、最後にルート・ノードであるノードＡが自己のノードＩＤを「＃４」に設定して接続構成の認識を終了する。
【００２０】
このようなバスリセット処理により、各ノードは通信システムの接続構成の認識と各ノードの通信アドレスの設定とを自動的に行うことができる。そして各ノードは、この上述のノードＩＤを用いることにより各ノード間の通信を行なうことができる。
【００２１】
次に、図１０の通信システムの具備するデータ転送方式について図９を用いて説明する。
図１０の通信システムは、データ転送方式としてIsochronous 転送モードとAsynchronous転送モードとを具備している。Isochronous 転送モードは、１通信サイクル期間（125 μs ）毎に一定量のパケットの送受信を保証するため、ビデオデータや音声データのリアルタイムな転送に有効である。
【００２２】
また、Asynchronous転送モードは、制御コマンドやファイルデータ等を必要に応じて非同期に送受信する転送モードであり、Isochronous 転送モードに比べて優先順位が低く設定されている。
【００２３】
図１１において、各通信サイクルの始めには、サイクル・スタート・パケット１１０１と呼ばれる各ノードの計時するサイクル時間を調整するための通信パケットが送出される。
【００２４】
サイクル・スタート・パケット１１０１の転送後、所定の期間がIsochronous 転送モードに設定されている。Isochronous転送モードでは、Isochronous 転送モードに基づいて転送されるデータの夫々に対してチャネル番号を付すことにより、複数のIsochronous 転送を実行することができる。
【００２５】
例えば、図１１において、ＤＶＣＲ１００４からIsochronous 転送されるデータ１１０２にチャネル番号「ｃｈ０」、ＤＶＴＲ１００２からIsochronous 転送されるデータ１１０３にチャネル番号「ｃｈ１」、ＴＶ１００１からIsochronous転送されるデータ１１０４にチャネル番号「ｃｈ２」が割り当てられている場合、各データは、１通信サイクル期間内において時分割にIsochronous 転送される。
【００２６】
各Isochronous 転送が終了した後、次のサイクル・スタート・パケット１１０１の転送される期間までがAsynchronous転送に使用される。例えば、図１１では、Asynchronous転送に基づくデータ１１０５がＤＶＣＲ１００４からプリンタ１００３に転送される。
【００２７】
図１２は、Asynchronous転送モードに基づく従来の通信プロトコルについて説明するシーケンスチャートである。
図１２において、情報データをAsynchronous転送するノード、即ちソース１２０２をＤＶＣＲ１００４とする。
【００２８】
また、ソース１２０２からAsynchronous転送された情報データを受信するノード、即ちデスティネーション１２０３をプリンタ１００３とする。更に、ソース１２０２とデスティネーション１２０３との間の通信を管理するノード、即ちコントローラ１２０１をＴＶ１００１とする。
【００２９】
従来の通信プロトコルは、３つのフェーズからなっていた。第１のフェーズ１２０４は、コネクションフェーズで、コントローラ１２０１は、デスティネーション１２０３の受信バッファサイズや受信可能か否かを問い合わせ、デスティネーション１２０３を受信待機状態にセットする。
【００３０】
また、コントローラ１２０１は、デスティネーション１２０３に問い合わせた受信バッファサイズをソース１２０２に通知すると共に、ソース１２０２からAsynchronous転送される情報データを選択して、送信バッファからの転送をセットする。
【００３１】
第２のフェーズ１２０５は、伝送フェーズで、コントローラ１２０１は、ソース１２０２とデスティネーション１２０３とを制御し、情報データをAsynchronous転送する。
【００３２】
第３のフェーズ１２０６は、コネクションリリースフェーズで、コントローラ１２０１は、デスティネーション１２０３の受信バッファを自己の管理下から開放し、同様にソース１２０２の送信バッファを自己の管理下から開放する。
【００３３】
図１３は、ソース１２０２からAsynchronous転送される情報データとデスティネーション１２０３の受信バッファとの関係を説明する図である。ソース１２０２からAsynchronous転送される１オブジェクトの情報データ１３０１は、コントローラ１２０１から通知されたデスティネーション１２０３の受信バッファサイズに等しい１つ以上のセグメント１３０２に分割される。ここで、各セグメント１３０２のサイズは固定長であり、１セグメントは、１つ以上のセグメントデータ（固定長）からなる。
【００３４】
各セグメントデータは、Asynchronous転送モードに基づく通信パケット１３０３（以下、Asynchronousパケット１３０３）にパケッタイズされ、ソース１２０２からデスティネーション１２０３に順次転送される。
【００３５】
デスティネーション１２０３は、ソース１２０２からのAsynchronousパケット１３０３を順次受信し、一時的に受信バッファ１３０４に書き込む。１セグメント分の情報データの転送が終了した後、デスティネーション１２０３は、受信バッファ１３０４に格納されたデータを内部メモリ１３０５に順次書き込む。
【００３６】
以下、図１４を用いて上述の第２のフェーズ１２０５の処理について詳細に説明する。
図１４において、コントローラ１２０１は、デスティネーション１２０３に対して、１つ以上の通信パケットによりAsynchronous転送されるセグメントデータを受信するように指示する（１４０１）。
【００３７】
また、コントローラ１２０１は、ソース１２０２に対して、１オブジェクトの情報データを上述のセグメント単位に分割し、更に各セグメントを１つ以上の通信パケットでAsynchronous転送するように指示する（１４０２）。
【００３８】
これらの指示の後、ソース１２０２は、１セグメントデータを１つ以上のAsynchronousパケットにパケッタイズし、それらのAsynchronousパケットをデスティネーション１２０３へ順次転送する（１４０３）。
【００３９】
コントローラ１２０１から指示されたセグメントデータの転送が完了した後、ソース１２０２は、転送の完了をコントローラ１２０１に通知する（１４０４）。また、デスティネーション１２０３は、コントローラ１２０１から指示されたセグメントデータの受信が完了したことをコントローラ１２０１に通知する（１４０５）。以上、図１４の１４０１〜１４０５に示す手順により、１セグメント分の情報データが転送される（１４０６）。
【００４０】
次のセグメントデータの転送を開始する場合、再び１４０１〜１４０５に示す手順を繰り返し、コントローラ１２０１がソース１２０２とデスティネーション１２０３の間の転送を制御する（１４０７）。
【００４１】
【発明が解決しようとする課題】
しかしながら、上述の通信プロトコルには次のような問題があった。
例えば、従来の通信プロトコルにおいて、各セグメントのサイズは固定長であり、デスティネーション１２０３の具備する受信バッファのサイズと等しくなるように制御されていた。
【００４２】
また、デスティネーション１２０３の具備する受信バッファのサイズは、全データの転送が終了するまで一定であり、全データの転送中に各セグメントのサイズを可変的に制御する仕組みがなかった。
【００４３】
例えば、従来の通信プロトコルに従って、複数のセグメントに分割された画像データを順次受信するプリンタにおいて、各セグメント分のデータの受信中に、プリント用に画像処理されているデータの一部を一時的に受信バッファの一部に記憶したい場合がある。
【００４４】
このような場合、従来の通信プロトコルでは、各セグメントのデータ量は一定であるため、通信中に一部のセグメントのデータ量を減らし、受信バッファ内に所望の領域を確保することができなかった。
【００４５】
また、より多くの機器との通信を可能とするために、通信中にソース１２０２からデスティネーション１２０３に転送される１セグメントのデータ量を減らしたり、より早く通信を終了させるために、通信中にデスティネーション１２０３の受信バッファサイズを大きくし、１セグメントのデータ量を増やしたりを適応的に制御することができなかった。
【００４６】
そこで、本発明は、送信すべきデータを複数のセグメントに分割し、当該セグメントを複数のセグメントデータに分割し、当該複数のセグメントデータを受信側データ通信装置に送信する場合において、当該セグメントのデータ量を適切に制御することのできるデータ通信システム及びデータ通信装置を提供することを目的とする。
【００４７】
【課題を解決するための手段】
本発明に係るデータ通信システムは、受信側データ通信装置と、送信すべきデータを複数のセグメントに分割し、前記セグメントを複数のセグメントデータに分割し、前記複数のセグメントデータを前記受信側データ通信装置に送信する送信側データ通信装置とを有するデータ通信システムであって、前記受信側データ通信装置は、前記送信側データ通信装置から送信された前記セグメントデータを格納する第１の受信バッファと、前記第１の受信バッファに格納された前記セグメントデータを格納する第２の受信バッファと、前記送信側データ通信装置が前記セグメントデータのサイズと前記セグメントのサイズとを決定するのに必要な前記第１の受信バッファのサイズを、前記受信側データ通信装置の最大データ転送速度に対応するペイロードサイズを用いて決定し、前記第２の受信バッファのサイズを、前記第１の受信バッファのサイズを用いて決定する第１の決定手段と、前記第１の決定手段により決定された前記第１の受信バッファのサイズを示す情報を前記送信側データ通信装置に送信する送信手段とを有し、前記送信側データ通信装置は、前記受信側データ通信装置から前記第１の受信バッファのサイズを示す情報を受信する受信手段と、前記セグメントデータのサイズと前記セグメントのサイズとを、前記第１の受信バッファのサイズを用いて決定する第２の決定手段とを有することを特徴とする。
【００４８】
本発明に係るデータ通信装置の一つは、送信すべきデータを複数のセグメントに分割し、前記セグメントを複数のセグメントデータに分割し、前記複数のセグメントデータを送信する送信側データ通信装置から送信された前記複数のセグメントデータを受信するデータ通信装置であって、前記送信側データ通信装置から送信された前記セグメントデータを格納する第１の受信バッファと、前記第１の受信バッファに格納された前記セグメントデータを格納する第２の受信バッファと、前記送信側データ通信装置が前記セグメントデータのサイズと前記セグメントのサイズとを決定するのに必要な前記第１の受信バッファのサイズを、前記データ通信装置の最大データ転送速度に対応するペイロードサイズを用いて決定し、前記第２の受信バッファのサイズを、前記第１の受信バッファのサイズを用いて決定する決定手段と、前記決定手段により決定された前記第１の受信バッファのサイズを示す情報を前記送信側データ通信装置に送信する送信手段とを有することを特徴とする。
【００４９】
本発明に係るデータ通信装置の一つは、送信すべきデータを複数のセグメントに分割し、前記セグメントを複数のセグメントデータに分割し、前記複数のセグメントデータを受信側データ通信装置に送信するデータ通信装置であって、前記データ通信装置から送信された前記セグメントデータを格納する第１の受信バッファと、前記第１の受信バッファに格納された前記セグメントデータを格納する第２の受信バッファと、前記データ通信装置が前記セグメントデータのサイズと前記セグメントのサイズとを決定するのに必要な前記第１の受信バッファのサイズを、前記受信側データ通信装置の最大データ転送速度に対応するペイロードサイズを用いて決定し、前記第２の受信バッファのサイズを、前記第１の受信バッファのサイズを用いて決定する第１の決定手段と、前記第１の決定手段により決定された前記第１の受信バッファのサイズを示す情報を前記データ通信装置に送信する送信手段とを有する前記受信側データ通信装置から、前記第１の受信バッファのサイズを示す情報を受信する受信手段と、前記セグメントデータのサイズと前記セグメントのサイズとを、前記第１の受信バッファのサイズを用いて決定する第２の決定手段とを有することを特徴とする。
【００５１】
【発明の実施の形態】
以下、本発明のデータ通信システム、装置及び方法、並びに記録媒体について図面を用いて詳細に説明する。
尚、以下の実施の形態において、上記従来例と同一あるいはそれに相当する部材については同一符号を用いて説明を省略する。
【００５２】
（第１の実施の形態）
以下、第１の実施の形態の通信プロトコルを、図１０に示す通信システムに適用した場合について説明する。ここで、第１の実施の形態におけるコントローラ１０１をＴＶ１００１、ソース１０２をＤＶＣＲ１００４、デスティネーション１０３をプリンタ１００３とする。
【００５３】
第１の実施の形態において、ソース１０２は、１オブジェクトの情報データ（例えば、画像データ、音声データ、グラフィックスデータ、テキストデータ等）を所定のデータ量からなるセグメントに分割した後、そのセグメントを１つ以上のセグメントデータとしてAsynchronous転送する。
【００５４】
また、デスティネーション１０３は、ソース１０２からAsynchronous転送された１つ以上のAsynchronousパケットを受信し、各Asynchronousパケットに含まれるセグメントデータを受信バッファに格納する。
【００５５】
ここで、デスティネーション１０３の受信バッファは、デスティネーション１０３の具備するＣＳＲ（Control and Status Register）空間内に確保されている。セグメントデータは、各Asynchronousパケットに含まれるオフセットアドレスにより指定されるＣＳＲ空間内の所定の領域に対して書き込まれる。デスティネーション１０３は、ＣＳＲ空間に対する１セグメント分のデータの書き込みが完了する毎に、そのデータを内部メモリに格納する。尚、ＣＳＲ空間は、ISO/IEC 13213:1994規格に準拠している。
【００５６】
更に、コントローラ１０１は、デスティネーション１０３のバッファサイズの問合せ、ソース１０２から転送される情報データの選択等、ソース１０２とデスティネーション１０３との間の通信を管理する。
【００５７】
また、第１の実施の形態の通信プロトコルは、従来の通信プロトコルと同様に３つのフェーズ、即ち、コネクションフェーズ、伝送フェーズ、コネクションリリースフェーズから構成されている。ここで、第１の実施の形態におけるコネクションフェーズとコネクションリリースフェーズとは、従来の通信プロトコルにおける第１のフェーズ１２０４、第３のフェーズ１２０６と同様に実行することができる。従って、第1の実施の形態では、伝送フェーズについて詳細に説明する。
【００５８】
以下、図１及び図２を用いて第１の実施の形態の伝送フェーズについて説明する。
図１は、第１の実施の形態の伝送フェーズについて詳細に説明するシーケンスチャートである。また、図２は、第１の実施の形態の伝送フェーズの手順について詳細に説明するフローチャートである。
【００５９】
ステップＳ２０１において、コントローラ１０１は、デスティネーション１０３に対して、いくつかの通信パケットでAsynchronous転送される所定サイズのセグメントを受信するように指示する（１０４）。ここで、デスティネーション１０３は、コントローラ１０１からの指示に対してレスポンスを返す。
【００６０】
ステップＳ２０２において、コントローラ１０１は、ソース１０２に対して、情報データを所定サイズのセグメントに分割し、更にそのセグメントをいくつかの通信パケットでAsynchronous転送するように指示する（１０５）。ここで、ソース１０２は、コントローラ１０１からの指示に対してレスポンスを返す。
【００６１】
ステップＳ２０３において、コントローラ１０１からの指示の後、ソース１０２は、１セグメントデータを１つ以上のAsynchronousパケットにパケッタイズし、それらのAsynchronousパケットをデスティネーション１０３へ順次転送する（１０６）。
【００６２】
ここで、各Asynchronousパケットには、デスティネーション１０３の具備する受信バッファの所定の領域を指定するオフセットアドレスが格納されている。例えば、各セグメントの最初のAsynchronousパケットには、コントローラ１０１により通知された受信バッファの先頭アドレスが格納されている。また、それ以降のAsynchronousパケットには、その受信バッファの所定の領域を順次指定するオフセットアドレスが格納されている。
【００６３】
ステップＳ２０４において、１セグメント分のデータのAsynchronous転送が完了した後、ソース１０２は、１セグメント分のデータの転送の完了をコントローラ１０１に通知する（１０７）。ここで、ソース１０２は、コントローラ１０１からの指示を受信するまで、次のセグメントの転送を待機する。
【００６４】
ステップＳ２０５において、また、デスティネーション１０３も同様に、１セグメント分のデータの受信が完了したことをコントローラ１０１に通知する（１０８）。
【００６５】
ステップＳ２０６において、デスティネーション１０３は更に、次に受信するセグメントのために、新たに確保できる受信バッファのサイズをコントローラ１０１に通知する（１０９）。ここで、コントローラ１０１は、デスティネーション１０３より通知された新たなバッファサイズをＣＳＲ空間の所定の領域に格納して管理する。
【００６６】
以上の手順により、１セグメント分のデータの転送が終了する。
次以降のセグメントの転送を開始する場合、コントローラ１０１、ソース１０２、デスティネーション１０３は、１０４〜１０９に示す手順を繰り返し行えばよい（ステップＳ２０７）。その際、コントローラ１０１は、１セグメントの転送が終了する毎に、デスティネーション１０３より通知された新たなバッファサイズをソース１０２に通知する。
【００６７】
以上のように、第１の実施の形態では、１セグメント分の情報データの転送が完了する毎に、デスティネーション１０３がコントローラ１０１に対して新たなバッファサイズを通知するように制御することによって、各セグメントのデータ量を適応的に設定することができる。
【００６８】
（第２の実施の形態）
上述した第１の実施の形態では、１セグメント分の情報データを受信する毎に、デスティネーション１０３が、次に受信するセグメントのために新たに確保できる受信バッファのサイズをコントローラ１０１に通知するように制御する通信プロトコルについて説明した。
【００６９】
第２の実施の形態では、デスティネーション３０３が、次に受信するセグメントのために新たに確保できる受信バッファのサイズを直接ソース３０２に通知するように制御する通信プロトコルについて説明する。
【００７０】
以下、第２の実施の形態の通信プロトコルを、図１０に示す通信システムに適用した場合について説明する。ここで、第２の実施の形態におけるコントローラ３０１をＴＶ１００１、ソース３０２をＤＶＣＲ１００４、デスティネーション３０３をプリンタ１００３とする。
【００７１】
第２の実施の形態において、ソース３０２は、１オブジェクトの情報データ（例えば、画像データ、音声データ、グラフィックスデータ、テキストデータ等）を所定の大きさのセグメントに分割した後、そのセグメントを１つ以上のセグメントデータとしてAsynchronous転送する。
【００７２】
また、デスティネーション３０３は、ソース３０２からAsynchronous転送された１つ以上のAsynchronousパケットを受信し、各Asynchronousパケットに含まれるセグメントデータを受信バッファに格納する。ここで、デスティネーション３０３の受信バッファは、デスティネーション３０３の具備するＣＳＲ（Control and Status Register ）空間内に確保されている。
【００７３】
セグメントデータは、各Asynchronousパケットに含まれるオフセットアドレスが指定するＣＳＲ空間内の所定の領域に対して書き込まれる。デスティネーション３０３は、ＣＳＲ空間に対する１セグメント分のデータの書き込みが完了する毎に、そのデータを内部メモリに格納する。
【００７４】
更に、コントローラ３０１は、デスティネーション３０３が通信開始時に確保できる受信バッファサイズの問合せ、ソース３０２から転送される情報データの選択等、ソース３０２とデスティネーション３０３との間の通信を管理する。
【００７５】
また、第２の実施の形態の通信プロトコルは、従来の通信プロトコルと同様に３つのフェーズ、即ち、コネクションフェーズ、伝送フェーズ、コネクションリリースフェーズから構成されている。ここで、第２の実施の形態におけるコネクションフェーズとコネクションリリースフェーズとは、従来の通信プロトコルにおける第１のフェーズ１２０４、第３のフェーズ１２０６と同様に実行することができる。従って、第２の実施の形態では、伝送フェーズについて詳細に説明する。
【００７６】
以下、図３及び図４を用いて第２の実施の形態の伝送フェーズについて説明する。
図３は、第２の実施の形態の伝送フェーズについて詳細に説明するシーケンスチャートである。また、図４は、第２の実施の形態の伝送フェーズの手順について詳細に説明するフローチャートである。
【００７７】
ステップＳ４０１において、コントローラ３０１は、デスティネーション２０３に対して、いくつかの通信パケットでAsynchronous転送される所定サイズのセグメントを受信するように指示する（３０４）。ここで、デスティネーション３０３は、コントローラ３０１からの指示に対してレスポンスを返す。
【００７８】
ステップＳ４０２において、コントローラ３０１は、ソース３０２に対して、情報データを所定サイズのセグメントに分割し、更にそのセグメントをいくつかの通信パケットでAsynchronous転送するように指示する（３０５）。ここで、ソース３０２は、コントローラ３０１からの指示に対してレスポンスを返す。
【００７９】
ステップＳ４０３において、コントローラ３０１からの指示の後、ソース３０２は、１セグメントを１つ以上のAsynchronousパケットにパケッタイズし、それらのAsynchronousパケットをデスティネーション３０３へ順次転送する（３０６）。ここで、各Asynchronousパケットには、デスティネーション３０３の具備する受信バッファの所定の領域を指定するオフセットアドレスが格納されている。例えば、各セグメントの最初のAsynchronousパケットには、コントローラ３０１により通知された受信バッファの先頭アドレスが格納されている。また、それ以降のAsynchronousパケットには、その受信バッファの所定の領域を順次指定するオフセットアドレスが格納されている。
【００８０】
ステップＳ４０４において、１セグメント分のデータのAsynchronous転送が完了した後、ソース３０２は、１セグメント分のデータの転送の完了をコントローラ３０１に通知する（３０７）。ここで、ソース３０２は、コントローラ３０１からの指示を受信するまで、次のセグメントの転送を待機する。
【００８１】
ステップＳ４０５において、デスティネーション３０３も同様に、１セグメント分のデータの受信が完了したことをコントローラ３０１に通知する（３０８）。ステップＳ４０６において、デスティネーション３０３は更に、次に受信するセグメントのために、新たに確保できる受信バッファのサイズをソース３０２に通知する（３０９）。
【００８２】
ステップＳ４０７において、ソース３０２は、この受信バッファのサイズをＣＳＲ空間の所定の領域に格納すると共に、この受信バッファのサイズを受信したことをコントローラ３０１に通知する（３１０）。この通知により、コントローラ３０１は、次のセグメントの転送の開始を指示することができる。
【００８３】
以上の手順により、１セグメント分のデータの転送が終了する。次以降のセグメントの転送を開始する場合、コントローラ３０１、ソース３０２、デスティネーション３０３は、３０４〜３１０に示す手順を繰り返し行えばよい（ステップＳ４０８）。
【００８４】
その際、ソース３０２は、１セグメントの転送が終了する毎に、デスティネーション３０３より通知される新たな受信バッファサイズを受信し、そのサイズに応じて次に転送すべきセグメントのサイズを決定する。以上のように、第２の実施の形態では、第１の実施の形態と同様に、１セグメント分の情報データの転送が完了する毎に、デスティネーション３０３がソース３０２に対して新たな受信バッファサイズを通知するように制御することによって、各セグメントのデータ量を適応的に設定することができる。
【００８５】
また、第２の実施の形態では、全データの通信中に変更されたデスティネーション３０３の受信バッファサイズをコントローラ３０１に管理させる必要がなくなり、ソース３０２とデスティネーション３０３との間で管理させることができる。これにより、第１の実施の形態に比べてコントローラに対する負荷をより小さくすることができる。
【００８６】
（第３の実施の形態）
上述した第２の実施の形態では、コントローラ３０１が、ソース３０２とデスティネーション３０３との間のコネクションを設定すると共に、各セグメントの転送の開始をコントローラ３０１により指示させるように制御する通信プロトコルについて説明した。
【００８７】
第３の実施の形態では、コントローラ３０１が、ソース３０２とデスティネーション３０３との間のコネクションを設定した後、各セグメントの転送を、コントローラ３０１を介することなく、ソース３０２とデスティネーション３０３との間で制御する通信プロトコルについて説明する。
【００８８】
以下、第３の実施の形態の通信プロトコルを、図１０に示す通信システムに適用した場合について説明する。ここで、第３の実施の形態におけるコントローラ５０１をＴＶ１００１、ソース５０２をＤＶＣＲ１００４、デスティネーション５０３をプリンタ１００３とする。
【００８９】
第３の実施の形態において、ソース５０２は、１オブジェクトの情報データ（例えば、画像データ、音声データ、グラフィックスデータ、テキストデータ等）を所定の大きさのセグメントに分割した後、そのセグメントを１つ以上のセグメントデータとしてAsynchronous転送する。
【００９０】
また、デスティネーション５０３は、ソース５０２からAsynchronous転送された１つ以上のAsynchronousパケットを受信し、各Asynchronousパケットに含まれるセグメントデータを受信バッファに格納する。ここで、デスティネーション５０３の受信バッファは、デスティネーション５０３の具備するＣＳＲ（Control and Status Register）空間内に確保されている。
【００９１】
セグメントデータは、各Asynchronousパケットに含まれるオフセットアドレスが指定するＣＳＲ空間内の所定の領域に対して書き込まれる。デスティネーション５０３は、ＣＳＲ空間に対する１セグメント分のデータの書き込みが完了する毎に、そのデータを内部メモリに格納する。
【００９２】
更に、コントローラ５０１は、ソース５０２及びデスティネーション５０３に対するバッファ領域の開放の指示、ソース５０２に対するオブジェクトの転送開始の指示等、ソース５０２とデスティネーション５０３との間の通信を管理する。
【００９３】
以下、第３の実施の形態の通信プロトコルについて説明する。
図５は、第３の実施の形態の通信プロトコルについて詳細に説明するシーケンスチャートである。また、図６は、第３の実施の形態の通信プロトコルの手順について詳細に説明するフローチャートである。
【００９４】
第３の実施の形態の通信プロトコルは、従来の通信プロトコルと同様に３つのフェーズ、即ち、コネクションフェーズ、伝送フェーズ、コネクションリリースフェーズから構成されている。
【００９５】
まず、コネクションフェーズについて説明する。
ステップＳ６０１において、コントローラ５０１は、ソース５０２とデスティネーション５０３との間のコネクションを設定し、デスティネーション５０３に対して受信バッファの開放と１オブジェクトの情報データの受信開始を指示する（５０４）。ここで、デスティネーション５０３は、コントローラ５０１からの指示に対してレスポンスを返す。
【００９６】
ステップＳ６０２において、コントローラ５０１は、と共に、ソース５０２に対して送信バッファの開放と１オブジェクトの情報データの送信開始を指示する（５０５）。ここで、ソース５０２は、コントローラ５０１からの指示に対してレスポンスを返す。
【００９７】
次に、伝送フェーズについて説明する。
ステップＳ６０３において、ソース５０２は、デスティネーション５０３に対して１オブジェクトの情報データのデータサイズを通知する（５０６）。デスティネーション５０３は、このデータサイズをＣＳＲ空間の所定の領域に格納する。
【００９８】
ステップＳ６０４において、デスティネーション５０３は、受信バッファのサイズと１Asynchronousパケットにて受信可能なデータサイズ（即ち、ペイロードサイズ）を通信する（５０７）。ソース５０２は、この受信バッファサイズとペイロードサイズとをＣＳＲ空間の所定の領域に格納する。
【００９９】
ステップＳ６０５において、ソース５０２は、受信バッファサイズとペイロードサイズとに応じて１オブジェクトの情報データを所定サイズのセグメントに分割し、そのセグメントを１つ以上のAsynchronousパケットにパケッタイズし、それらを順次デスティネーション５０３へ転送する（５０８）。１セグメントデータの転送完了後、ソース５０２は、デスティネーション５０３からの受信完了の通知があるまで次のセグメントの転送を待機する。
【０１００】
ここで、各Asynchronousパケットには、デスティネーション５０３の具備する受信バッファの所定の領域を指定するオフセットアドレスが格納されている。例えば、各セグメントの最初のAsynchronousパケットには、ソース５０２により通知された受信バッファの先頭アドレスが格納されている。また、それ以降のAsynchronousパケットには、その受信バッファの所定の領域を順次指定するオフセットアドレスが格納されている。
【０１０１】
ステップＳ６０６において、１セグメント分のデータの受信後、デスティネーション５０３は、１セグメント分のデータの転送の完了をソース５０２に通知する（５０９）。
【０１０２】
ステップＳ６０７において、デスティネーション５０３は更に、次に受信するセグメントのために、新たに確保できる受信バッファのサイズをソース５０２に通知する（５１０）。ソース５０２は、この受信バッファサイズをＣＳＲ空間の所定の領域に格納すると共に、この受信バッファサイズとペイロードサイズとに応じて次に転送するセグメントの大きさを設定する。
【０１０３】
以上の手順により、１セグメント分のデータの転送が終了する。
次以降のセグメントの転送を開始する場合、コントローラ５０１、ソース５０２、デスティネーション５０３は、５０４〜５１０に示す手順を繰り返し行えばよい（ステップＳ６０８）。その際、ソース５０２は、１セグメントの転送が終了する毎に、デスティネーション５０３より通知される新たな受信バッファサイズを受信し、そのサイズに応じて次に転送すべきセグメントのサイズを決定する。１オブジェクトの情報データの転送が完了した後、ソース５０２は、転送の完了をコントローラ５０１に通知する（５１１）。
【０１０４】
また、デスティネーション５０３も、１オブジェクトの情報データの受信が完了したことをコントローラ５０１に通知する（５１２）。
以上の手順により伝送フェーズが終了する。
【０１０５】
コネクションリリースフェーズにおいて、コントローラ５０１は、ソース５０２及びデスティネーション５０３から通信完了の通知を受けた後、デスティネーション５０３の受信バッファを自己の管理下から解放する（５１３）し、ソース５０２の送信バッファを自己の管理下から解放する（５１４）。
【０１０６】
以上のように、第３の実施の形態では、１セグメント分の情報データの転送が完了する毎に、デスティネーション５０３がソース５０２に対して新たなバッファサイズを通知するように制御することによって、各セグメントのデータ量を適応的に設定することができる。
【０１０７】
また、第３の実施の形態では、第２の実施の形態と同様に、全データの通信中に変更されたデスティネーション５０３の受信バッファサイズをコントローラ５０１に管理させる必要がなくなり、ソース５０２とデスティネーション５０３との間で管理させることができる。これにより、第１の実施の形態に比べてコントローラに対する負荷をより小さくすることができる。
【０１０８】
更に、第３の実施の形態では、ソース５０２とデスティネーション５０３との間のコネクションの設定後、各セグメントのサイズ設定と各セグメントの転送とをソース５０２とデスティネーション５０３との間で制御し、実行することができる。これにより、第１、第２の実施の形態に比べてコントローラに対する負荷を減らし、通信手順をより簡素化することができる。
【０１０９】
（第４の実施の形態）
この第４の実施の形態では、上述した第３の実施の形態と同様に、コントローラ５０１が、ソース５０２とデスティネーション５０３との間のコネクションを設定した後、各セグメントデータの転送を、コントローラ５０１を介することなく、ソース５０２とデスティネーション５０３との間で制御する通信プロトコルについて説明する。
【０１１０】
以下、第４の実施の形態の通信プロトコルを、図１０に示す通信システムに適用した場合について説明する。ここで、第４の実施の形態におけるコントローラ７０１をＴＶ１００１、ソース７０２をＤＶＣＲ１００４、デスティネーション７０３をプリンタ１００３とする。
【０１１１】
第４の実施の形態において、ソース７０２は、１オブジェクトの情報データ（例えば、画像データ、音声データ、グラフィックスデータ、テキストデータ等）を所定のデータ量からなるセグメントに分割した後、そのセグメントを更に１つ以上のセグメントデータとしてAsynchronous転送する。
【０１１２】
また、デスティネーション７０３は、ソース７０２からAsynchronous転送された１つ以上のAsynchronousパケットを受信し、各Asynchronousパケットに含まれるセグメントデータを受信バッファに格納する。ここで、デスティネーション７０３の受信バッファは、デスティネーション７０３の具備するＣＳＲ（Control and Status Register）空間内に確保されている。
【０１１３】
各セグメントデータは、各Asynchronousパケットに含まれるオフセットアドレスが指定するＣＳＲ空間内の所定の領域に対して書き込まれる。デスティネーション７０３は、ＣＳＲ空間に対する１セグメント分のデータの書き込みが完了する毎に、そのデータを内部メモリに格納する。
【０１１４】
以下、図８、及び図９を用いてソース７０２及びデスティネーション７０３の具備するバッファの構成について詳細に説明する。
図８、図９において、ソース７０２は、１つの受信バッファ、即ち「Source Buffer １」を具備している。ここで、Source Buffer １は、ソース７０２の具備するＣＳＲ空間の所定の領域に確保されている。
【０１１５】
また、図８、図９において、デスティネーション７０３は、２つの受信バッファ、即ち「Destination Buffer１」と「Destination Buffer２」とを具備している。ここで、Destination Buffer１とDestination Buffer２とは、デスティネーション７０３の具備するＣＳＲ空間の所定の領域に確保されている。
【０１１６】
図８、図９に示すSource Buffer １、Destination Buffer１、Destination Buffer２のサイズは以下のように定義される。
まず、第４の実施の形態において、Destination Buffer１及びDestination Buffer２のサイズを以下のように定義する。
【０１１７】
Destination Buffer２＝（max ＿rec ）×Ｎ（Ｎ＝１, ２, ３・・・ ）…（式１）
ここで、Destination Buffer２は、１セグメントの大きさに対応している。また、Ｎは整数で、１セグメントを構成するセグメントデータの数に対応している。
【０１１８】
Destination Buffer１＝max ＿rec …（式２）
ここで、「max ＿rec 」とは、IEEE1394-1995 規格に準拠したAsynchronous Writeトランザクションに基づいて受信されるAsynchronousパケットにおいて、デスティネーション７０３の受信可能なペイロードサイズの最大値を示す。尚、「max ＿rec 」のサイズは、デスティネーション７０３の対応する最大データ転送速度に応じて異なる。「max ＿rec 」は、以下のように定義される。
【０１１９】
max ＿rec ＝４Byte×２L （Ｌ＝0,1,2…） …（式３）
ここで、Ｌは整数である。
【０１２０】
（式１）及び（式２）からDestination Buffer１とDestination Buffer２との関係は、以下のようになる。
【０１２１】
Destination Buffer２＝(Destination Buffer １) ×Ｎ （Ｎ＝1,2,3…） …（式４）
また、第４の実施の形態において、Source Buffer １を以下のように定義する。
【０１２２】
Source Buffer１＝４Byte×２M （Ｍ＝0,1,2…） …（式５）
（式４）において、Source Buffer １とは、ソース７０２の送信可能なAsynchronousパケットのペイロードサイズの最大値を示す。尚、Source Buffer １のサイズは、ソース７０２の対応する最大データ転送速度に応じて異なる。ここで、Ｍは整数である。
【０１２３】
（式３）及び（式５）からmax ＿rec とSource Buffer １との関係は、以下の（式６）のようになる。
Source Buffer １：max ＿rec ＝２M ：２L …（式６）
式により、max ＿rec は、
【０１２４】
【０１２５】
（式７）及び（式１）からDestination Buffer２は、
Destination Buffer２＝（Source Buffer １）×｛２(L-M) ｝×Ｎ…（式８）
となる。
【０１２６】
（式８）により、ソース７０２は、ペイロードのサイズがSource Buffer １分となるAsynchronousパケットを、[ ｛２(L-M) ｝×Ｎ] 回送信することによってDestination Buffer２を一杯にすることができる。
【０１２７】
このように定義することにより、Destination Buffer２のサイズを、Source Buffer １のサイズとDestination Buffer１のサイズとによって決定することができる。
【０１２８】
例えば、図８において、Source Buffer １＝Destination Buffer１（＝max ＿rec ）の場合、式からＭ＝Ｌとなる。この場合、式により、Destination Buffer２のサイズは、Source Buffer １のサイズのＮ倍となる。従って、Ｎの値を設定することにより、各セグメントの大きさを可変的に制御することができる。
【０１２９】
また、図８において、Source Buffer １＞Destination Buffer１（＝max ＿rec ）の場合、式より、Ｍ＞Ｌとなる。この場合、ソース７０２は、Source Buffer １のサイズをDestination Buffer１のサイズと等しくなるように設定する。これにより、Destination Buffer２のサイズは、Source Buffer １のサイズのＮ倍となる。従って、Ｎの値を設定することにより、各セグメントの大きさを可変的に制御することができる。
【０１３０】
更に、図９において、Source Buffer １＜Destination Buffer１（＝max ＿rec ）の場合、式より、Ｍ＜Ｌとなる。この場合、デスティネーション７０３は、Destination Buffer１のサイズをSource Buffer１のサイズと等しくなるように設定する。これにより、Destination Buffer２のサイズは、Source Buffer １のサイズの[ ｛２(L-M) ｝×Ｎ] 倍となる。従って、Ｍ、Ｎ及びＬの値を設定することにより、各セグメントの大きさを可変的に制御することができる。
【０１３１】
更に、第４の実施の形態において、コントローラ７０１は、ソース７０２及びデスティネーション７０３に対するバッファ領域の開放の指示、ソース７０２の具備するサブユニットに対するオブジェクトの転送準備の指示等、ソース７０２とデスティネーション７０３との間のコネクションを管理する。
【０１３２】
以下、第４の実施の形態の通信プロトコルについて説明する。
図７は、第４の実施の形態の通信プロトコルについて詳細に説明するシーケンスチャートである。
【０１３３】
第４の実施の形態の通信プロトコルは、従来の通信プロトコルと同様に３つのフェーズ、即ち、コネクションフェーズ、伝送フェーズ、コネクションリリースフェーズから構成されている。
まず、コネクションフェーズについて説明する。
【０１３４】
（１）図７に示す手順７０４の説明する。
コントローラ７０１は、デスティネーション７０３に対してアプリケーションＣＴＳ（Command Control Set ）コマンド（図７に示す「SubUnit Appli Cmd 」）を発行し、デスティネーション７０３の具備するサブユニットに対して受信準備を行うように制御する。第４の実施の形態において、デスティネーション７０３はプリンタ１００３である。従って、コントローラ７０１は、プリンタ１００３の具備するプリンタユニットに対して、ＣＴＳコマンド形式のプリントコマンドを発行する。
【０１３５】
デスティネーション７０３は、図８、図９に示すように、Destination Buffer１とDestination Buffer２の２つの受信バッファを具備している。上述のアプリケーションＣＴＳコマンドを受信したデスティネーション７０３は、Destination Buffer１とDestination Buffer２のイニシャライズ、及びサブユニットの具備するアプリケーションメモリのイニシャライズ等を行う。サブユニットが受信可能な状態であれば、コントローラ７０１に対してInterim レスポンス（図７に示す「SubUnit Appli Resp」）をＣＴＳコマンド形式で返す。
【０１３６】
（２）図７に示す手順７０５の説明する。
次に、コントローラ７０１は、ソース７０２に対してアプリケーションＣＴＳコマンド（図７に示す「SubUnit Appli Cmd 」）を発行し、ソース７０２の具備するサブユニットに対して送信準備を行うように制御する。第４の実施の形態において、ソース７０２は、ＤＶＣＲ１００４である。従って、コントローラ７０１は、ＤＶＣＲ１００４の具備するカムコーダユニットに対して、ＣＴＳコマンド形式の再生コマンドを発行する。
【０１３７】
デスティネーション７０３は、図８、図９に示すように、Source Buffer１を具備している。上述のアプリケーションＣＴＳコマンドを受信したソース７０２は、Source Buffer １のイニシャライズを行う。サブユニットが送信可能な状態であれば、コントローラ７０１に対してInterim レスポンス（図７に示す「SubUnit Appli Resp」）をＣＴＳコマンド形式で返す。
【０１３８】
次に伝送フェーズについて説明する。
（３）図７に示す手順７０６の説明。
Interim レスポンスを送信したソース７０２は、サブユニットのアプリケーションメモリに格納されている１オブジェクトの情報データの送信準備を行い、その準備が完了したことをデスティネーション７０３に対して通知する。
【０１３９】
IEEE1394-1995 規格に準拠したAsynchronous Writeトランザクションを用いて、送信準備の完了を通知する場合、ソース７０２は、デスティネーション７０３の具備する所定のレジスタに対して送信準備の完了を示す「Ready to send 」情報を書き込む。尚、「Ready to send 」情報には、上述のＭの値が含まれている。
【０１４０】
ここで、所定のレジスタは、デスティネーション７０３の具備するＣＳＲ空間内の所定のアドレスに設けられている。従って、ソース７０２は、その所定のアドレスを指定したAsynchronous Writeトランザクションを用いて「Ready to send 」情報の書き込みを行う。
【０１４１】
尚、第４の実施の形態では、所定のレジスタに「Ready to send」情報を書き込む処理について説明したが、該レジスタの所定のフィールドに「Ready to send」を示す特定のフラグを設けて、該フラグを書き換えるように処理してもよい。
【０１４２】
（４）図７に示す手順７０７の説明。
Interimレスポンスを送信し、ソース７０２から「Ready to send 」情報を受信したデスティネーション７０３は、ソース７０２の具備する所定のレジスタに対して「Ready to receive」情報とDestination Buffer１、２に関する情報（図７に示す「Buffer Info 」）とを書き込む。
【０１４３】
ここで、Destination Buffer１に関する情報とは、上述のＬの値と上述のＭの値とによって設定されるデスティネーションの受信可能なペイロードサイズの最大値であり、セグメントデータのサイズを示す情報である。また、Destination Buffer２に関する情報とは、上述のＮの値により設定されるセグメントのサイズを示す情報である。ここで、セグメントのサイズは、セグメントデータのサイズのＮ倍になるように設定される。また、デスティネーション７０３は、Ｎの値を各セグメントによって可変的に設定することができる。
【０１４４】
ここで、所定のレジスタは、ソース７０２の具備するＣＳＲ空間内の所定のアドレスに設けられている。従って、デスティネーション７０３は、その所定のアドレスを指定したAsynchronous Writeトランザクションを用いてこれらの情報の書き込みを行う。
【０１４５】
（５）図７に示すData Transfer７０８についての説明。
ソース７０２は、デスティネーション７０３からの「Ready to receive」情報を受信した後、Destination Buffer１、２に関する情報を用いて、１オブジェクトの情報データをＮ個のセグメントデータからなるセグメントに分割する。
【０１４６】
ソース７０２は、各セグメントデータを順次Source Buffer １に格納した後、Asynchronous Writeトランザクションを用いて順次転送する。
ここで、各セグメントデータは、ＣＳＲ空間内に確保されたDestination Buffer１に連続的に書き込まれる。Destination Buffer１に書き込まれたセグメントデータは、次のセグメントデータが受信されるまでに、Destination Buffer２に格納される。各セグメントデータの送信は、デスティネーション７０３により確保されたDestination Buffer２が一杯になるまで実行される。
【０１４７】
（６）図７に示す手順７０９の説明。
ソース７０２は、Ｎ個のセグメントデータを送信した後、図７に示す「End of Segment」情報をデスティネーション７０３に送信する。この「End of Segment」情報は、Asynchronous Writeトランザクションを用いて、「Ready to send」情報を書き込むレジスタに書き込まれる。
【０１４８】
ここで、１オブジェクトの情報データを構成する全てのセグメントデータの送信が完了した場合、ソース７０２は、Destination Buffer２の全てが満たされていなくても、図７に示す「End of Data 」情報をデスティネーション７０３に送信する。この「End of Data 」情報は、Asynchronous Writeトランザクションを用いて、「Ready to send 」情報を書き込むレジスタに書き込まれる。
【０１４９】
（７）図７に示す手順７１０の説明。
デスティネーション７０３及びそのサブユニットは、「End of Segment」情報を受信すると、１セグメント分の情報データ（Ｎ個のセグメントデータからなる）の送信が終了したことを認識する。
【０１５０】
デスティネーション７０３は、Destination Buffer２に格納されたＮ個のセグメントデータを、サブユニット内部のアプリケーションメモリ領域に格納する。その後、デスティネーション７０３は、Asynchronous Writeトランザクションを用いて、「Ready to receive」情報をソース７０２の具備する所定のレジスタに対して書き込む。
【０１５１】
「Ready to receive」情報を受信したソース７０２は、次のセグメントの送信準備が完了した後、再び、図７の７０６〜７１０を実行し、Destination Buffer２分のデータを送信する。
【０１５２】
また、「End of Data 」情報を受信した場合、デスティネーション７０３は、１オブジェクトの情報データを構成する全てのセグメントデータの送信が終了したことを認識する。その後、デスティネーション７０３は、図７に示す「End of Conf 」情報をソース７０２に通知する。
この「End of Data 」情報は、Asynchronous Writeトランザクションを用いて、「Ready to send」情報を書き込むレジスタに書き込まれる。
以上の手順により伝送フェーズが終了する。
また、コネクションリリースフェーズについて説明する。
【０１５３】
（８）図７に示す手順７１１の説明。
「End of Conf 」情報を受信したソース７０２は、コントローラ７０１に対して、１オブジェクトの情報データを構成する全てのセグメントデータの送信が終了したことを通知する。この通知は、ＣＴＳコマンド形式の「Accepted response」を用いて行われる。
【０１５４】
（９）図７に示す手順７１２の説明。
「End of Conf 」情報を送信したデスティネーション７０３は、コントローラ７０１に対して、１オブジェクトの情報データを構成する全てのセグメントデータの受信が終了したことを通知する。この通知は、ＣＴＳコマンド形式の「Accepted response 」を用いて行われる。
【０１５５】
以上のように、第４の実施の形態では、Source Buffer １、Destination Buffer１、Destination Buffer２の関係を定義した。これにより、デスティネーション７０３は、ソース７０２から通知されるＭの値と、Ｎ及びＬの値によって各セグメントのサイズを可変的に設定することができる。また、セグメントのサイズを決定するための演算を容易にすることができる。
【０１５６】
また、第４の実施の形態では、１セグメント分の情報データの転送が完了する毎に、デスティネーション７０３がソース７０２に対して新たなバッファサイズを通知するように制御することによって、各セグメントのデータ量を適応的に設定することができる。
【０１５７】
また、第４の実施の形態では、第３の実施の形態と同様に、全データの通信中に変更されたデスティネーション７０３の受信バッファサイズをコントローラ７０１に管理させる必要がなくなり、ソース７０２とデスティネーション７０３との間で管理させることができる。これにより、第１の実施の形態に比べてコントローラに対する負荷をより小さくすることができる。
【０１５８】
更に、第４の実施の形態では、ソース７０２とデスティネーション７０３との間のコネクションの設定後、各セグメントのサイズ設定と各セグメントの転送とをソース７０２とデスティネーション７０３との間で制御し、実行することができる。これにより、第１、第２の実施の形態に比べてコントローラに対する負荷を減らし、通信手順をより簡素化することができる。
【０１５９】
また、第４の実施の形態によれば、各セグメントの大きさをデスティネーション７０３の受信可能なペイロードサイズの整数倍に設定することができる。これにより、ソースから送出されるパケットの数を管理することによって、各セグメント分のデータの送信を管理でき、ソース側の送信制御が容易になる。
【０１６０】
更に、第４の実施の形態によれば、デスティネーションの受信バッファのサイズを、デスティネーションの受信可能なペイロードサイズの整数倍に設定することができる。これにより、デスティネーションにおいて確保される受信バッファを有効に利用できるとともに、各セグメントデータを書き込むアドレスの制御が容易になる。
【０１６１】
（他の実施の形態）
上述の各実施の形態は、以下のように実現することも可能である。
例えば、上述した実施の形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、本実施の形態のシステム或いは装置の具備する制御部（マイクロコンピュータを含む）に供給するように構成することもできる。
【０１６２】
そして、本実施の形態のシステム或いは装置の具備する制御部が、該記録媒体に格納されたプログラムコードを読み出し、上述した実施の形態の機能を実現するようにシステム或いは装置の動作を制御するように構成しても本発明の実施の形態を実現することができる。
【０１６３】
例えば、第１の実施の形態の図１、第２の実施の形態の図３、第３の実施の形態の図５、第４の実施の形態の図７に示した処理手順及び機能を実現するプログラムコードを格納した記録媒体を図７に示す各ノードの制御部７０６に供給する。そして、各ノードの制御部７０６が、その記録媒体に格納されたプログラムコードを読み出し、各実施の形態の機能を実現するように、図７に示す各ノードの処理回路を動作させるようにしてもよい。
【０１６４】
この場合、記録媒体から読み出されたプログラムコード自体が上述した実施の形態の機能を実現することになり、そのプログラムコードを記憶した記録媒体は、本発明の一部の構成要件になる。
【０１６５】
プログラムコードを供給するための記録媒体としては、例えば、フロッピディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。
【０１６６】
また、制御部上で稼動しているＯＳ（オペレーティングシステム）或いはアプリケーションソフト等が、記録媒体より読み出したプログラムコードの指示に基づき、本実施の形態のシステム或いは装置の動作を制御することにより、上述した実施の形態の機能を実現する場合も本発明に含まれることは言うまでもない。
【０１６７】
更に、記録媒体から読み出されたプログラムコードが、制御部に接続された機能拡張ボード或いは機能拡張ユニットの具備するメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットの具備する制御部が本実施の形態のシステム或いは装置の動作を制御することにより、上述した実施の形態の機能が実現される場合も本発明に含まれることは言うまでもない。尚、本発明はその精神、またはその主要な特徴から逸脱することなく、様々な形で実施することができる。
【０１６８】
例えば、本実施の形態の伝送フェーズでは、IEEE1394-1995 規格に準拠したAsynchronous Writeトランザクションを用いて、１オブジェクトの情報データの転送を実行する場合について説明したが、それに限るものではない。例えば、IEEE1394.a規格に準拠したAsynchronous Streamsパケットを用いたトランザクションにより１オブジェクトの情報データを送信するように構成してもよい。尚、Asynchronous Streamsパケットの構成は、IEEE1394-1995規格に準拠したIsochronousパケットと同じ構成である。
【０１６９】
この場合、各セグメントデータを送信するパケットは、特定の宛先に対して１対１に送信されるものではなく、所定のチャネル番号を指定し、ブロードキャストされるものである。従って、上述の実施の形態はあらゆる点おいて単なる例示に過ぎず、限定的に解釈してはならない。
【０１７０】
【発明の効果】
以上のように、本発明に係るデータ通信システム及びデータ通信装置によれば、送信すべきデータを複数のセグメントに分割し、当該セグメントを複数のセグメントデータに分割し、当該複数のセグメントデータを受信側データ通信装置に送信する場合において、当該セグメントのデータ量を適切に制御することができる。
【図面の簡単な説明】
【図１】本発明に係る第１の実施の形態の伝送フェーズについて詳細に説明するシーケンスチャートである。
【図２】第１の実施の形態の伝送フェーズの手順について詳細に説明するフローチャートである。
【図３】第２の実施の形態の伝送フェーズについて詳細に説明するシーケンスチャートである。
【図４】第２の実施の形態の伝送フェーズの手順について詳細に説明するフローチャートである。
【図５】第３の実施の形態の通信プロトコルについて詳細に説明するシーケンスチャートである。
【図６】第３の実施の形態の通信プロトコルの手順について詳細に説明するフローチャートである。
【図７】第４の実施の形態の通信プロトコルについて詳細に説明するシーケンスチャートである。
【図８】ソース７０２及びデスティネーション７０３の具備するバッファの構成について説明する図である。
【図９】ソース及びデスティネーションの具備するバッファの構成について説明する図である。
【図１０】従来の通信システムの構成を示す図である。
【図１１】従来の通信システムの具備するデータ転送方式について説明する図である。
【図１２】従来の通信プロトコルについて説明するシーケンスチャートである。
【図１３】ソース１２０２からAsynchronous転送される情報データとデスティネーション１２０３の受信バッファとの関係を説明する図である。
【図１４】図１２における第２のフェーズについて詳細に説明するシーケンスチャートである。
【符号の説明】
１０１ コントローラ
１０２ ソース
１０３ デスティネーション
Claims (7)
- 受信側データ通信装置と、
送信すべきデータを複数のセグメントに分割し、前記セグメントを複数のセグメントデータに分割し、前記複数のセグメントデータを前記受信側データ通信装置に送信する送信側データ通信装置とを有するデータ通信システムであって、
前記受信側データ通信装置は、
前記送信側データ通信装置から送信された前記セグメントデータを格納する第１の受信バッファと、
前記第１の受信バッファに格納された前記セグメントデータを格納する第２の受信バッファと、
前記送信側データ通信装置が前記セグメントデータのサイズと前記セグメントのサイズとを決定するのに必要な前記第１の受信バッファのサイズを、前記受信側データ通信装置の最大データ転送速度に対応するペイロードサイズを用いて決定し、前記第２の受信バッファのサイズを、前記第１の受信バッファのサイズを用いて決定する第１の決定手段と、
前記第１の決定手段により決定された前記第１の受信バッファのサイズを示す情報を前記送信側データ通信装置に送信する送信手段とを有し、
前記送信側データ通信装置は、
前記受信側データ通信装置から前記第１の受信バッファのサイズを示す情報を受信する受信手段と、
前記セグメントデータのサイズと前記セグメントのサイズとを、前記第１の受信バッファのサイズを用いて決定する第２の決定手段とを有する
ことを特徴とするデータ通信システム。 - 前記第１の決定手段は、前記第２の受信バッファのサイズを、前記第１の受信バッファのサイズだけでなく、前記送信側データ通信装置の最大データ転送速度に対応するペイロードサイズを用いて決定することを特徴とする請求項１に記載のデータ通信システム。
- 前記送信側データ通信装置と、前記受信側データ通信装置との間のコネクションを管理するコントローラをさらに有することを特徴とする請求項１又は２に記載のデータ通信システム。
- 送信すべきデータを複数のセグメントに分割し、前記セグメントを複数のセグメントデータに分割し、前記複数のセグメントデータを送信する送信側データ通信装置から送信された前記複数のセグメントデータを受信するデータ通信装置であって、
前記送信側データ通信装置から送信された前記セグメントデータを格納する第１の受信バッファと、
前記第１の受信バッファに格納された前記セグメントデータを格納する第２の受信バッファと、
前記送信側データ通信装置が前記セグメントデータのサイズと前記セグメントのサイズとを決定するのに必要な前記第１の受信バッファのサイズを、前記データ通信装置の最大データ転送速度に対応するペイロードサイズを用いて決定し、前記第２の受信バッファのサイズを、前記第１の受信バッファのサイズを用いて決定する決定手段と、
前記決定手段により決定された前記第１の受信バッファのサイズを示す情報を前記送信側データ通信装置に送信する送信手段とを有することを特徴とするデータ通信装置。 - 前記決定手段は、前記第２の受信バッファのサイズを、前記前記第１の受信バッファのサイズだけでなく、前記送信側データ通信装置の最大データ転送速度に対応するペイロードサイズを用いて決定することを特徴とする請求項４に記載のデータ通信装置。
- 送信すべきデータを複数のセグメントに分割し、前記セグメントを複数のセグメントデータに分割し、前記複数のセグメントデータを受信側データ通信装置に送信するデータ通信装置であって、
前記データ通信装置から送信された前記セグメントデータを格納する第１の受信バッフ ァと、前記第１の受信バッファに格納された前記セグメントデータを格納する第２の受信バッファと、前記データ通信装置が前記セグメントデータのサイズと前記セグメントのサイズとを決定するのに必要な前記第１の受信バッファのサイズを、前記受信側データ通信装置の最大データ転送速度に対応するペイロードサイズを用いて決定し、前記第２の受信バッファのサイズを、前記第１の受信バッファのサイズを用いて決定する第１の決定手段と、前記第１の決定手段により決定された前記第１の受信バッファのサイズを示す情報を前記データ通信装置に送信する送信手段とを有する前記受信側データ通信装置から、前記第１の受信バッファのサイズを示す情報を受信する受信手段と、
前記セグメントデータのサイズと前記セグメントのサイズとを、前記第１の受信バッファのサイズを用いて決定する第２の決定手段とを有する
ことを特徴とするデータ通信装置。 - 前記第１の決定手段は、前記第２の受信バッファのサイズを、前記第１の受信バッファのサイズだけでなく、前記送信側データ通信装置の最大データ転送速度に対応するペイロードサイズを用いて決定することを特徴とする請求項６に記載のデータ通信装置。
Priority Applications (6)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP11972798A JP4046846B2 (ja) | 1998-04-28 | 1998-04-28 | データ通信システム及びデータ通信装置 |
| US09/253,783 US7590133B2 (en) | 1998-02-24 | 1999-02-22 | Data communication system, data communication method, and data communication apparatus |
| EP99301305A EP0984601A3 (en) | 1998-02-24 | 1999-02-23 | Data communication system and method for connection setup |
| KR1019990006186A KR100294960B1 (ko) | 1998-02-24 | 1999-02-24 | 데이타 통신 시스템, 데이타 통신 방법, 및 데이타 통신 장치 |
| CNB991056108A CN1184787C (zh) | 1998-02-24 | 1999-02-24 | 数据通信系统，数据通信方法和数据通信装置 |
| MYPI99000653A MY135481A (en) | 1998-02-24 | 1999-02-24 | Data communication system, data communication method, and data communication apparatus |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP11972798A JP4046846B2 (ja) | 1998-04-28 | 1998-04-28 | データ通信システム及びデータ通信装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH11313124A JPH11313124A (ja) | 1999-11-09 |
| JP4046846B2 true JP4046846B2 (ja) | 2008-02-13 |
Family
ID=14768639
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP11972798A Expired - Fee Related JP4046846B2 (ja) | 1998-02-24 | 1998-04-28 | データ通信システム及びデータ通信装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4046846B2 (ja) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001320376A (ja) * | 2000-05-02 | 2001-11-16 | Fujitsu Ltd | 電子機器の制御方法および半導体装置 |
| CA2628235A1 (en) * | 2005-11-07 | 2007-05-10 | Lg Electronics Inc. | Near field communication host controller interface |
| TWI767997B (zh) * | 2017-03-23 | 2022-06-21 | 日商索尼半導體解決方案公司 | 通信裝置、通信方法、程式及通信系統 |
| CN112051974B (zh) * | 2019-06-06 | 2023-12-15 | 汉朔科技股份有限公司 | 电子价签信息传输方法及系统、电子价签、服务器 |
-
1998
- 1998-04-28 JP JP11972798A patent/JP4046846B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH11313124A (ja) | 1999-11-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7590133B2 (en) | Data communication system, data communication method, and data communication apparatus | |
| US6717694B1 (en) | Data transmission apparatus, system and method, and recording medium | |
| EP0959590B1 (en) | Data communication system operating at maximum data rate | |
| US7203787B2 (en) | Information processing apparatus and method that utilizes stored information about a mountable device | |
| EP0939529B1 (en) | Destination node, data communication system, method of controlling a destination node and method of operating a data communication system | |
| JP2001306428A (ja) | ネットワーク機器、ネットワークシステム、通信方法及び記録媒体 | |
| JP2000358033A (ja) | データ通信システム及びデータ通信方法 | |
| AU736169B2 (en) | Electronic apparatus, information transmitting method thereof, and storing medium | |
| US7002964B1 (en) | Communication system, method for a communication system and controller for a communication system | |
| JP3630971B2 (ja) | データ通信方法、装置、システム、及び記憶媒体 | |
| KR100311707B1 (ko) | 데이타 통신 시스템, 데이타 통신 방법, 데이타 통신 장치 및 디지탈 인터페이스 | |
| JP4046846B2 (ja) | データ通信システム及びデータ通信装置 | |
| JPH10341247A (ja) | データ送信装置、データ受信装置、データ伝送システム及びデータ伝送方法 | |
| EP1017236A2 (en) | Transmission managing apparatus, information processing apparatus and information transmitting system | |
| JP4428750B2 (ja) | データ通信システム | |
| JP3774540B2 (ja) | データ転送方法及び画像処理システムと装置 | |
| EP1133105A2 (en) | Buffer allocation method for 1394 serial bus | |
| JP3943722B2 (ja) | データ転送装置、データ転送システムおよびその方法、画像処理装置、並びに、記録媒体 | |
| JP2001075756A (ja) | 情報処理装置及び情報処理システム及びそれらの方法 | |
| JP4026979B2 (ja) | データ通信システム | |
| JP3890124B2 (ja) | データ通信システム、データ通信方法、データ通信ノードおよび記録媒体 | |
| JP3647328B2 (ja) | 画像処理装置及びその制御方法並びに画像処理システム | |
| JP3897773B2 (ja) | 通信方法及び通信装置 | |
| JP4058156B2 (ja) | データ処理方法、データ処理装置、プリンタ、及び記憶媒体 | |
| JP3678244B2 (ja) | 電子機器及び通信制御方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050427 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070823 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070828 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071029 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20071113 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20071121 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101130 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101130 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111130 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121130 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131130 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |