JP5338594B2 - データ受信方法、データ送受信システム、およびデータ受信機 - Google Patents

Description

本発明は、データ送受信技術に関し、特に、ネットワークを介して送信機から受信機にデータを送信するデータ送受信するデータ送受信技術に関する。

従来のネットワーク型受信処理装置では、たとえば、ネットワークを介してホスト装置から供給される受信データを印字するプリンタ装置においては、受信データ、または通信プロトコルによって受信データの終端を検知できない場合、この受信データの出力が未完了のまま、停止してしまうという問題があった。そこで、送信元であるホスト装置からの受信データが一定時間（受信タイムアウト時間）を越えて受信されないと、プリンタ装置の専有状態を解除する技術が知られている。また、受信先の処理装置において、パケット受信中にプログラムによる割込みが発生した場合、命令処理部は受信割込み要因を起こしたパケットのヘッダ部を主記憶部内に保持し続けるため、割込み処理が終了するまで処理装置は新たなパケットを受信することができず、タイムアウトせざるをえないという状況があった。

このような状況はＡＶ（Audio Visual）機器においての一時停止（ポーズ）、再復活再生（レジューム）機能には非常に不都合なものであり、一旦ネットワークからのＡＶデータを伝送されている以上、受信バッファやデータの復号用バッファにあるデータがフラッシュしてしまうと、次にレジュームした場合に正確な位置からのレジュームができない。即ち、送信側サーバーが何処までを送ったかの情報を持っているとしても、受信側クライアントのほうにある受信バッファやデータの復号用バッファにはどこまでのバッファが溜まっていたか（消費されていたか）の情報がフラッシュしてしまっていると、ＡＶデータがＭＰＥＧなどのように圧縮符号化されているアプリケーションなどでは余計に再生位置の誤差が大きくなってしまう。しかし、ポーズしたタスク全てを完全に保持していることを行っていると、複数のポーズなどの事象が多く発生してくると、バッファなどのリソースを多く保持しなければならなくなり、システムに破綻をきたしてしまうという問題があった。

また、一時停止（ポーズ）、再復活再生（レジューム）に対応した技術として、特許文献１の発明がある。特許文献１の発明は、送信側サーバが動画の配信中にユーザが一時中断を選択したときは配信を停止するが、その後ユーザが配信の再開を選択したときは中断個所から引き続き配信を再開することを特徴とするものである。

特開２００１−３５９０７３号公報

しかし、特許文献１の発明は、タイムアウトの概念がないので、例えば、一時停止（ポーズ）中に、他の原因において、受信側クライアントでのデータ受信のための通信プロセスが消滅し、再復活再生（レジューム）に支障をきたす場合となっても、他の受信側クライアントからの要求に、送信側サーバは一切応答できないという問題が発生する。

本発明は上述した課題を解決するためになされたものであり、その目的は、ネットワークを介してのデータ受信のプロセスを停止した後において、データ復号が再開されたときでも、大きな誤差を発生することなく正確な位置からデータ再生することにある。

上記課題を解決するために、本発明のある態様のデータ受信方法は、ネットワークを介して送信機からデータを受信するデータ受信方法において、あるデータを受信するプロセスを停止した場合に、停止したプロセスとは別のプロセスにて、送信機へ確認要求コマンドを送信するステップと、送信した確認要求コマンドに対して送信機から応答があったか否かを判定するステップと、応答がない場合に、停止したプロセスをタイムアウトさせ、応答があった場合に、停止したプロセスが一時停止状態にあるとして当該プロセスのタイムアウトを回避するステップと、一時停止状態にあるとされたプロセスが所定数に達した場合、一時停止状態にあるとされたプロセスのうち停止した時刻が古いプロセスから順にタイムアウトさせるステップと、を備える。

本発明の別の態様は、データ送受信システムである。このデータ送受信システムは、データを受信する受信機と、ネットワークを介して受信機にデータを送信する送信機と、を備える。受信機は、あるデータを受信するプロセスを停止した場合に、停止したプロセスとは別のプロセスにて送信機へ確認要求コマンドを送信し、送信した確認要求コマンドに対して送信機から応答があったか否かを判定し、応答がない場合に、停止したプロセスをタイムアウトさせ、応答があった場合に、停止したプロセスが一時停止状態にあるとしてタイムアウトを回避し、一時停止状態にあるとされたプロセスが所定数に達した場合、一時停止状態にあるとされたプロセスのうち停止した時刻が古いプロセスから順にタイムアウトさせる。

本発明のさらに別の態様は、データ受信機である。このデータ受信機は、ネットワークを介して送信機と応答コマンドを送受信する応答コマンド送受信手段と、データを受信するプロセスのタイムアウトを制御するタイムアウト保持手段と、を備える。応答コマンド送受信手段は、あるデータを受信するプロセスを停止した場合に、停止したプロセスとは別のプロセスにて、送信機へ確認要求コマンドを送信し、タイムアウト保持手段は、送信した確認要求コマンドに対して送信機から応答がない場合に、停止したプロセスをタイムアウトさせ、応答があった場合に、停止したプロセスが一時停止状態にあるとして当該プロセスのタイムアウトを回避し、一時停止状態にあるとされたプロセスが所定数に達した場合、一時停止状態にあるとされたプロセスのうち停止した時刻が古いプロセスから順にタイムアウトさせる。

本発明によれば、ネットワークを介してのデータ受信のプロセスを停止した後において、データ復号が再開されたときでも、大きな誤差を発生することなく正確な位置からデータ再生することができる。

本実施例に係るデータ送受信システムの構成を示すブロック図である。 ネットワークを介してＡＶ送信機からＡＶ受信機にＡＶデータを送信する送信手順を示すフローチャートである。 本実施例に係る、ＡＶ情報要求コマンド、ＡＶリストコマンド、ＡＶ受信要求コマンド、ＡＶ受信許可コマンドなどの構成例を示す図である。 本実施例に係るデコーダーバッファの具体的な例を模式的に示す図である。 本実施例に係るタイムアウト検出シーケンスの説明図である。 本実施例に係るネットワークバッファ状態管理テーブルを示す図である。 タイムアウトを行う場合と行わない場合におけるプロセスを示すフローチャートである。

本発明の実施例として、データ送受信システムについて以下説明する。このデータ送受信システムは、データを受信する受信機と、ネットワークを介して受信機にデータを送信する送信機と、を備える。受信機は、あるデータを受信するプロセスを停止した場合に、そのプロセスとは別のプロセスにて送信機へ確認要求コマンドを送信する。受信機は、送信した確認要求コマンドに対して送信機から応答があったか否かを判定し、応答がない場合に、停止したプロセスをタイムアウトさせ、応答があった場合に、停止したプロセスが一時停止状態にあるとしてタイムアウトを回避する。受信機は、一時停止状態にあるとされたプロセスが所定数に達した場合、一時停止状態にあるとされたプロセスのうち停止した時刻が古いプロセスから順にタイムアウトさせる。

これにより、受信機でデータが受信できない状態になった場合にタイムアウトをしないで、一時停止を保持するようにする。その結果、保持されたプロセスは、受信機に蓄積されているバッファもそのまま一時停止されるので、ネットワークを介してのデータ受信のプロセスを停止した後において、データ復号再開（レジューム）がされたときでも大きな誤差を発生することなく、正確な位置からデータ再生ができることになる。さらには、本発明によれば、保持されるプロセスに個数上限値を設定して、所定個数以上の一時停止プロセスが発生した場合には、時間的に古い一時停止プロセスからタイムアウトを行うようにしたので、バッファなどのリソースが適度な状態で開放されるためにシステムの破綻が無くなる。

さらに、受信機でデータが受信できない状態になった場合に、データ送受信とは別のプロセスにて、受信機から送信機へ応答要求コマンドを送るようにしたので、本当にデータ送受信プロセスが消滅したのか、一時停止なのかが判定できる。その結果消滅している場合には応答が無いことになるのでタイムアウトを行い、応答がある場合には一時停止状態と判定できるので、タイムアウトをしないで、一時停止を保持するようにする。その結果、保持されたプロセスは、受信機に蓄積されているバッファもそのまま一時停止されるので、データ復号再開（レジューム）がされたときでも大きな誤差を発生することなく、正確な位置からデータ再生ができることになる。さらには、本発明によれば、保持されるプロセスに個数上限値を設定して、所定個数以上の一時停止プロセスが発生した場合には、時間的に古い一時停止プロセスからタイムアウトを行うようにしたので、バッファなどのリソースが適度な状態で開放されるためにシステムの破綻が無くなる。以下、図面を参照して本発明の実施例について詳細に説明する。

図１は、本実施例に係るデータ送受信システムの構成を示すブロック図である。データ送受信システムは、左のオーディオビデオデータのサーバー（以下、「ＡＶ送信機」という）と、右のオーディオビデオデータのレシーバー（以下、「ＡＶ受信機」という）とがネットワークを経由して接続され構成される。ＡＶ送信機は、ＵＳＢ（Universal Serial Bus）１、チューナー２、ＨＤＤ（Hard disk drive）３、ＣＰＵ４、ネットワークバッファ５、ポーズ手段６、および応答コマンド送受信手段７を有する。ＡＶ受信機は、ＣＰＵ８、デコードバッファ９、復号化手段１０、ＡＶモニター１１、応答コマンド送受信手段１２、プロセス管理手段１３、タイムアウト保持手段１４、およびネットワークバッファ１５を有する。

ＨＤＤ３には、送信するＡＶデータが保存されている。このＡＶデータは、チューナー２からの受信データであっても、カムコーダーによって自分で撮影したＡＶデータをＵＳＢ１経由でＨＤＤ３に記録されたものであってもよい。ＨＤＤ３からＡＶデータを送信するとき、ＣＰＵ４は、ネットワークへ送信するためのコマンドを送信する。

図２は、ネットワークを介してＡＶ送信機からＡＶ受信機にＡＶデータを送信する送信手順を示すフローチャートである。図２においてコントローラは、ＡＶ送信機およびＡＶ受信機の双方を操作すべくユーザが操作入力可能に設けられている。本実施例では、コントローラは、ネットワークを介してＡＶ送信機およびＡＶ受信機の各々にデータを送受信可能に設けられている。

まず、コントローラに設けられたＡＶ情報要求ボタンなどがユーザに押されると、コントローラは、ネットワークを介してＡＶ送信機にＡＶ情報要求コマンドを送信する。ＡＶ送信機のＣＰＵ４は、ＡＶ情報要求コマンドを受信すると、ＨＤＤ３に格納されたデータを参照してＡＶリストコマンドを構成し、ネットワークを介してコントローラに返送する。

コントローラには、ＡＶコンテンツを選択する選択ボタンが設けられている。ユーザは、受信したＡＶリストコマンドが示すＡＶコンテンツの中から、この選択ボタンを押すことにより、ＡＶ受信機に送信したいＡＶコンテンツを選択することができる。ユーザによってＡＶコンテンツが選択されると、コントローラは、ネットワークを介してＡＶ受信機にＡＶ受信要求コマンドを送信する。ＡＶ受信機のＣＰＵ８は、ＡＶ受信要求コマンドを受信すると、ＡＶコンテンツを受信するポート情報を指定してＡＶ受信許可コマンドをコントローラに返送する。

ＡＶ受信許可コマンドを受信すると、コントローラは、ＡＶ受信機から指定された受信ポート番号、ＡＶ受信機のＩＰアドレス、ＡＶコンテンツ識別情報をパラメータとして、ネットワークを介してＡＶ送信機にＡＶ送信要求コマンドを送信する。

ＡＶ送信機のＣＰＵ４は、ＡＶ送信要求コマンドを受信すると、ＨＤＤ３に格納されたデータを参照し、ＡＶコンテンツ識別情報で示されるＡＶコンテンツの有無を判定する。そのＡＶコンテンツが存在する場合、同時送信チャネル数や、既に別のＡＶ受信機に送信中か否か、などの状況を確認し、再生可能か否かを判定する。

ここで、要求されたＡＶコンテンツが再生不可能な状態であれば、ＣＰＵ４はネットワークを介して、コントローラに理由と共にＮＡＣＫを返送する。再生可能であればＣＰＵ４はコントローラに再生識別子をパラメータとしてＡＣＫを返送すると共に、ＨＤＤ３に対して、ネットワークバッファ５の未使用のチャネルｘにＡＶ受信機から要求されたＡＶコンテンツのデータの読み出しを指示する。再生識別子は以降、このチャネルｘを使用してＡＶコンテンツの伝送を識別するための情報である。

さらに、ＣＰＵ４はネットワークバッファ５の監視を開始する。所定時間毎（例えば１００ミリ秒毎とし、以下、１００ミリ秒毎に送信すると仮定する）に、チャネルｘからＡＶデータを１００ミリ秒分、ＡＶ受信機のＩＰアドレス、ポート番号に対して送信する。この時、送信するＡＶデータの送信サイズ、ＡＶコンテンツ全体中のオフセット等の情報も一緒に送信する。また、ジッタ、アンダーラン等を考慮し、３００ミリ秒分のＡＶデータがネットワークバッファ５に読み出された時点で、送信を開始する（場合によっては考慮せず、読み出しと同時に送信しても良い）。ＣＰＵ４は１００ミリ秒毎に、１００ミリ秒分の指定されたコンテンツのデータをから読み出し、指定されたチャネルｘにセットするようにＨＤＤ３に指示する。

ＡＶ受信機のＣＰＵ８は、ＡＶ送信機からＡＶデータを受信すると、ＡＶ送信機にＡＣＫを返送すると共に、受信したＡＶデータをネットワークバッファ１５に一旦蓄積する。そして、ネットワーク上のジッタやアンダーラン等を考慮し、ある程度ネットワークバッファ１３に蓄積されると、デコードバッファ９に転送され、復号化手段１０を介してＡＶモニター１１に再生される。

次に、ポーズについて説明する。コントローラには、ポーズボタン（一時停止ボタン）が設けられている。このポーズボタンがユーザによって押されることによりポーズ要求を取得すると、コントローラは、再生識別子をパラメータとして、ポーズコマンドをＡＶ送信機にネットワークを介して送信する。ＡＶ送信機のＣＰＵ４は、ネットワークを介してポーズコマンドを受信すると、ＨＤＤ３にポーズコマンドにより指定された識別子から、ＡＶコンテンツデータの読み出し停止を指示し、ネットワークバッファ５のチャネルｘの監視も停止する。そして、ポーズ手段６に指示して、再開時にＨＤＤ３から読み出す予定のオフセットを記憶する。

ＡＶ送信機のＣＰＵ４は、ネットワークを介してコントローラからレジュームコマンドを受信すると、その再生識別子を用いてポーズ手段６に次に読み出すべきオフセットを問い合わせ、ＨＤＤ３に続きからＡＶデータを読み出してチャネルｘにセットするように指示する。同時に、ネットワークバッファ５の監視を開始し、通常再生時と同様の処理を再開する。

図２において、ＡＶデータそれぞれにＡＣＫを返送しているが、ストリーム系のデータの場合はデータが欠落しても再送しない場合が多いため、そのような場合はＡＣＫの返送を省いても構わない。

図３は、本実施例に係る、ＡＶ情報要求コマンド、ＡＶリストコマンド、ＡＶ受信要求コマンド、ＡＶ受信許可コマンドなどの構成例を示す図である。ＡＶリストコマンドは、ＡＶリストであることを示すデータと、ＡＶ送信機が有する各ＡＶコンテンツの名称を示すＡＶコンテンツ情報識別子と、各ＡＶコンテンツのフォーマットを示すフォーマット識別情報、各ＡＶコンテンツのデータサイズを示すコンテンツサイズ等の属性情報を含む。

ＡＶ受信要求コマンドには、ＡＶ受信要求であることを示すデータと、ＡＶコンテンツ情報識別子と、フォーマット識別情報と、コンテンツサイズとを含む。図３に示す例では、ユーザに「誕生日」という名称のＡＶコンテンツが選択された例が示されている。

図２のフローの後に、ＡＶデータはネットワークバッファ５に一度、蓄えられ、ネットワークを経由して、図１の右側のＡＶ受信機へ送信される。なお、ポーズをかける場合にはＣＰＵ４からポーズ手段６にポーズをかける信号が伝送され、ポーズ手段はネットワークバッファ５に対し、データをネットワークへ送信することをポーズするように指示信号がだされて、ネットワークバッファ５はネットワークへの伝送をポーズする。ＡＶ受信機ではネットワークバッファ１５に一度蓄えられ、ＣＰＵ８で受信の管理がなされる。即ち、所定のサイズのパケット化されたデータで送られてくるので、どれだけの量のデータを受けたか、ある程度ネットワークバッファ１５に蓄積したものはデコードバッファ９へ伝送したりする制御を行う。デコードバッファに送られたデータは、ある程度蓄積され、所定の時刻になるとＡＶデータは復号化手段１０によって復号されるため、データがデコードバッファ９から抜き取られる。

図４は、本実施例に係るデコーダーバッファの具体的な例を模式的に示す図である。図４のＡの位置からデータがデコードバッファに蓄積開始される。右上の傾きはバッファに入る転送レートである。縦軸はバッファに溜まっているデータの占有量、横軸は時間を示す。Ｂの位置になると第１の単位のデータが復号される。これは具体的には、ＡＶデータの主にビデオデータの１ピクチャー分に相当する。例えば地上波デジタルデータなどはＭＰＥＧ２によって可変レートで圧縮符号化されている。従って画面の複雑さや、各ピクチャーのテクスチャーの動き量などの状況により、各フレームに与えられる画像の符号量は異なる。そこでＢからＣへのバッファからデコーダーへ引き抜かれる量が、各ピクチャー単位で異なってくる。次のピクチャーはＤからＥ、その次はＦからＧであって、それぞれ異なっているのが分かる。

ただし、バッファには上限があって、そこまではバッファしても良いが、それ以上は溜めることはできない。溜めた場合には情報ビットが欠落し、ＭＰＥＧではそのピクチャー、あるいは予測符号化されているリファレンスピクチャーである場合には、数ピクチャーのグループ単位で復号が出来なくなってしまうこともある。その上限ギリギリにまでバッファ占有したときにポーズがかかると、例えば図４のＹのようなところまで占有しているときに、タイムアウトが発生し、受信バッファやデータの復号用バッファにあるデータがフラッシュしてしまうと、次にレジュームした場合に正確な位置からのレジュームができなくなる。

即ち、送信側サーバーが何処までを送ったかの情報を持っているとしても、受信側クライアントのほうにある受信バッファやデータの復号用バッファにはどこまでのバッファが溜まっていたか（消費されていたか）の情報がフラッシュしてしまっているので、図４のＸからＹまでの時刻、即ち時間Ｓの期間が、誤差として発生する。ＡＶデータがＭＰＥＧなどのように圧縮符号化されているアプリケーションなどでは符号化しているピクチャーの符号量が変動するので、その期間が小さい符号量などであれば、バッファの値が上限に近い場合に、数多くのピクチャーのデータがバッファされていることになる。このためその分、バッファに溜まっているデータの再生時間が長い状態で溜まってしまうことになる。したがって、本来のポーズとポーズ解除における再生のタイミングと、ポーズしてからバッファをフラッシュして初めからバッファに溜めてからスタートということになると、前者と後者では再生位置が大きく違ってしまい、誤差が大きくなってしまう。

そこで本実施例ではＣＰＵ８がネットワークバッファを経由して、ＡＶ送信機のネットワークバッファと、ＡＶ受信機のネットワークバッファを繋ぐ、ネットワークのプロセスに対して、ポーズ手段６でポーズをかけた場合、所定の時間が掛かってもタイムアウトをしないようにＣＰＵ８からタイムアウト保持手段１４で、タイムアウトしてネットワークバッファがフラッシュしないように制御をかける。

ところで、ネットワークには本当にポーズをかけたか、あるいはＡＶ送信機がなんらかの条件で伝送が中断されてしまうことがある。例えばＡＶ送信機の電源が押された場合や、ネットワークケーブルが切断されてしまう場合などである。そのような場合と本当のポーズの状態を識別するために、ＣＰＵ８は応答コマンド送受信手段１２にＡＶ送信機へのデータ送受信とは別のプロセスにて、応答を要求する応答コマンドを送信するよう指示信号を送信する。

応答コマンド送受信手段はその指示信号をうけたらネットワーク経由にてＡＶ送信機の応答コマンド送受信手段７へ、応答コマンドを送信する。応答コマンドは例えばＰＩＮＧや状態問い合わせ、死活確認、ＮＯＰへの応答、ヘルスチェックなどのように、相手のプロセスが存在しているか消滅しているか否かを判定するために、応答するだけのシンプルなもので良い。

図５は、本実施例に係るタイムアウト検出シーケンスの説明図である。図５では、応答コマンドによってポーズかプロセスが消滅しているかを確認するフローを示している。図５において、ポーズが発生した時点でＡＶ送信機からＡＶデータの送信が停止される。そこでＡＶ受信機のＣＰＵ８は所定の時間経過してもデータを受信しなければ、ＡＶ送信機のＩＰアドレス、通信ポート番号を通知し、応答コマンド送受信手段１２に確認を指示する。

応答コマンド送受信手段１２はネットワークを介して、ＡＶ送信機に確認要求コマンドを送信しＡＣＫの返送を待つ。応答コマンド送受信手段１２は所定時間経過してもＡＣＫを受信できなければ、異常発生と判定し、ＣＰＵ８に対してタイムアウト発生を通知する。所定時間以内にＡＣＫを受信できれば、定期的に確認要求をＡＶ送信機に送信し、確認を継続する。この時、ＡＣＫを受信する毎に図６に示すプロセス状態管理テーブルの受信時刻を更新する。

ＡＶ送信機の応答コマンド送受信手段７は、確認要求コマンドを受信すると、ＡＣＫを返送する。このように、応答が無い場合にはタイムアウトを行い、応答がある場合には一時停止状態にあるとしてタイムアウトを回避し、一時停止状態を保持する。一時停止状態の保持は、ＣＰＵ８を経由してタイムアウト保持手段１４が行う。

その際、複数のＡＶ受信機でＡＶデータを送受信するプロセスが複数発生する場合がある。その場合にはプロセスが生成されるたびにネットワークバッファを分割して割り当て、各プロセスの付随する情報として、ネットワークバッファ状態管理テーブルにプロセスの状態、最後に受信した時刻を記憶しておく。

図６は、本実施例に係るネットワークバッファ状態管理テーブルを示す図である。この例では、ネットワークバッファを４分割しているので、４チャンネル分（プロセス４個分）同時に受信できる。プロセスの状態は何も再生してなければアイドル、再生中、一時停止中の３つの状態で管理する。プロセスの状態が再生中で、応答コマンド送受信手段１２からタイムアウト発生の通知を受けた場合は、タイムアウト発生と見なすが、まずは、プロセス状態を一時停止中に更新し、即座にはタイムアウト処理を行わない。ここで、全てのバッファを使用中に、新たな受信プロセスが生成されるとする。タイムアウトの判定として、プロセス状態が一時停止中であるプロセスの中で、受信時刻の古い順にタイムアウト判定を行うことにより、所定の個数のプロセスを待たせておいたなら、その古い順番にタイムアウトをする。

例えば、１０個のプロセスまでとＣＰＵ８に設定した場合には、１１番目のポーズのプロセスが指定された場合、１番目のプロセスは自動的にタイムアウトする。タイムアウトの時間は自由に設定する。なお、プロセスにはネットワークバッファ状態管理テーブルという仕組みを使うことにより、そのポーズプロセスが発生したときの時刻が記録されているので、その時刻情報を見ることにより、古いもの、新しいものかの判定をＣＰＵ８ですることができる。タイムアウト保持手段１４は、ＣＰＵ８からの指示信号によりプロセス管理手段１３を経由してプロセスの個数、タイムアウトをするタイミングを管理制御する。ここでは、ＡＶデータを受信しなくなってから確認要求の送信を開始したが、ＡＶデータの受信の有無にかかわらず定期的に確認要求を送信しても構わない。

一方、デコードバッファに溜まったデータは、前記のようにデコードのタイミングによって（ＭＰＥＧにはＤＴＳ＝でコーディングタイムスタンプがある）そのピクチャーの復号が、復号化手段１０によってなされる。またオーディオも同様に復号化手段１０によってなされる。その後、復号されたＡＶデータはＡＶモニター１１にて再生され、ユーザに視聴可能とされる。

図７は、タイムアウトを行う場合と行わない場合におけるプロセスを示すフローチャートである。スタートから第１のステップでＣＰＵ４からＨＤＤ３にデータ送信指示を出す。次にステップ２でＣＰＵ８からＡＶ情報要求コマンドを送信する。次にステップ３でＣＰＵ４がＡＶ情報要求コマンドを受けて各パラメータを返す。このパラメータとはＡＶ受信機から指定された受信ポート番号、ＡＶ受信機のＩＰアドレス、ＡＶコンテンツ識別情報などである。

次にステップ４でＡＶデータをネットワークバッファ５に読み出して送信を開始する。次にステップ５にてＣＰＵからＨＤＤ３にポーズをかける。次にステップ６にてタイムアウト保持手段１４でプロセスを保持し、且つ、デコーダーバッファなどを一時停止するように保持する。次にステップ７においてＣＰＵ８はＣＰＵ４へ応答コマンド指示を送信する。次にステップ８にて応答コマンドに対して応答があったか否かを判定する。

応答コマンドが無かった（ＮＯ）の場合、ステップ１２に飛び、プロセス管理手段１３にタイムアウトをするように指示させる。次にステップ１３にてタイムアウトを行う。一報ステップ８にて応答コマンドに対して応答があったか否かを判定し、応答コマンドがあった（ＹＥＳ）の場合には、ステップ９にてプロセス管理手段１３にタイムアウトをしない（保持）させるように指示させる。

次にステップ１０にてタイムアウト保持手段１４によってタイムアウトしないように保持をする。次にステップ１１にてプロセス管理手段１３にて、プロセス数が所定の数以上になったか否かを判定する。所定の数になっていない（ＮＯ）の場合は、ステップ９へ飛ぶ。所定の数になっている（ＹＥＳ）の場合には、ステップ１２に飛び、プロセス管理手段１３にタイムアウトをするように指示させる。次にステップ１３にてタイムアウトを行い終了する。

なお、ここでは、ポーズの解除（タイムアウトすること）をプロセス個数で判定したが、ＡＶ受信機においてのリソース（ポーズするたびに一時停止しておくバッファの量や、ＣＰＵの負荷の量など）によって、その値が所定以上になった場合に、古いものからタイムアウトをするようにしてもよい。また、ＵＳＢ１はＳＤメモリーであってもなんでも良く、チューナーは、外からのデータの受信が可能であれば、デジタルでもアナログでも、通信経路からであるシステムであっても良い。また、ネットワークは、ＩＰ接続でも特別なプロトコル接続であってもよく、パケットフォーマットも特に規制するものではない。

本発明は上述の各実施形態に限定されるものではなく、各実施形態の各要素を適宜組み合わせたものも、本発明の実施形態として有効である。また、当業者の知識に基づいて各種の設計変更等の変形を各実施形態に対して加えることも可能であり、そのような変形が加えられた実施形態も本発明の範囲に含まれうる。

１ ＵＳＢ、 ２ チューナー、 ３ ＨＤＤ、 ４ ＣＰＵ、 ５ ネットワークバッファ、 ６ ポーズ手段、 ７ 応答コマンド送受信手段、 ８ ＣＰＵ、 ９ デコードバッファ、 １０ 復号化手段、 １１ ＡＶモニター、 １２ 応答コマンド送受信手段、 １３ プロセス管理手段、 １４ タイムアウト保持手段、 １５ ネットワークバッファ。

Claims (3)

1. ネットワークを介して送信機からデータを受信するデータ受信方法において、
   あるデータを受信するプロセスを停止した場合に、前記停止したプロセスとは別のプロセスにて、前記送信機へ確認要求コマンドを送信するステップと、
   送信した確認要求コマンドに対して前記送信機から応答があったか否かを判定するステップと、
   応答がない場合に、前記停止したプロセスをタイムアウトさせ、応答があった場合に、前記停止したプロセスが一時停止状態にあるとして当該プロセスのタイムアウトを回避するステップと、
   一時停止状態にあるとされたプロセスが所定数に達した場合、一時停止状態にあるとされたプロセスのうち停止した時刻が古いプロセスから順にタイムアウトさせるステップと、
   を備えることを特徴とするデータ受信方法。
2. データを受信する受信機と、
   ネットワークを介して前記受信機にデータを送信する送信機と、を備え、
   前記受信機は、
   あるデータを受信するプロセスを停止した場合に、前記停止したプロセスとは別のプロセスにて前記送信機へ確認要求コマンドを送信し、
   送信した確認要求コマンドに対して前記送信機から応答があったか否かを判定し、
   応答がない場合に、前記停止したプロセスをタイムアウトさせ、応答があった場合に、前記停止したプロセスが一時停止状態にあるとしてタイムアウトを回避し、
   一時停止状態にあるとされたプロセスが所定数に達した場合、一時停止状態にあるとされたプロセスのうち停止した時刻が古いプロセスから順にタイムアウトさせることを特徴とするデータ送受信システム。
3. ネットワークを介して送信機と応答コマンドを送受信する応答コマンド送受信手段と、
   データを受信するプロセスのタイムアウトを制御するタイムアウト保持手段と、
   を備え、
   前記応答コマンド送受信手段は、あるデータを受信するプロセスを停止した場合に、前記停止したプロセスとは別のプロセスにて、前記送信機へ確認要求コマンドを送信し、
   前記タイムアウト保持手段は、
   送信した確認要求コマンドに対して前記送信機から応答がない場合に、前記停止したプロセスをタイムアウトさせ、応答があった場合に、前記停止したプロセスが一時停止状態にあるとして当該プロセスのタイムアウトを回避し、
   一時停止状態にあるとされたプロセスが所定数に達した場合、一時停止状態にあるとされたプロセスのうち停止した時刻が古いプロセスから順にタイムアウトさせることを特徴とするデータ受信機。

Images