(57)【要約】      （修正有）【課題】  本発明は、ＨＴＴＰ−ＧＥＴ方法に基づいたトランスポートメカニズムを、データストリームの伝送にいわゆるトリックモードを導入することが可能であるよう拡張することを目的とする。【解決手段】  データストリームが、分散局のネットワークにおいて伝送されるとき、このネットワークでは、加入者局は、インターネットプロトコルに基づいて制御されるが、リソース（例えばファイル）は、しばしば、ＨＴＴＰ−ＧＥＴ方法を用いて伝送される。本発明は、周知のＨＴＴＰ−ＧＥＴ方法の拡張を、このＨＴＴＰ−ＧＥＴ方法というアプリケーションも同様に可能であるよう記載する。このために、要求される検索に関連する追加のパラメータが、ＨＴＴＰ−ＧＥＴ要求においてソース電化製品に伝送される。次に、ソース電化製品は、検索のための各データセクションを送信する。【選択図】  図５
2005204278.tif 000002
【特許請求の範囲】
【請求項１】
分散局のネットワークにおける、第１のネットワーク加入者局（１０）と第２のネットワーク加入者局（２０）間でのデータのセクションでの不連続伝送方法であって、
ファイル名、ファイルタイプ、経路、再生速度、再生方向、及び開始位置といった所要のパラメータを記載するＨＴＴＰ−ＧＥＴ要求を作成する段階と、
前記ソース電化製品（１０）に、前記ＨＴＴＰ−ＧＥＴ要求を伝送する段階と、
ＨＴＴＰ応答において、前記ソース電化製品（１０）から前記宛先電化製品（２０）に前記データをセクションで不連続伝送する段階と、
を含む方法。
【請求項２】
前記データは、ＨＴＴＰチャンク転送エンコードモードを用いて伝送される請求項１記載の方法。
【請求項３】
特定のステータスコードが、前記要求されたデータの伝送に対する前記応答において戻されて、前記ＨＴＴＰ−ＧＥＴ要求における前記所要のパラメータを正しく解釈することが可能であったことを伝える請求項１又は２記載の方法。
【請求項４】
前記ＨＴＴＰ−ＧＥＴ要求における１つ以上の前記所要のパラメータを正しく解釈することが可能であったことを示す認知として、前記要求されたデータの伝送に対する前記応答において、前記ＨＴＴＰ−ＧＥＴ要求からの１つ以上の前記所要のパラメータが繰り返される請求項１乃至３のうちいずれか一項記載の方法。
【請求項５】
前記データのセクションでの不連続伝送は、高速検索の要求の場合に用いられる請求項１乃至４のうちいずれか一項記載の方法。
【請求項６】
前記データは、マルチメディアデータ、特に、オーディオ又はビデオデータに関連する請求項１乃至５のうちいずれか一項記載の方法。
【請求項７】
前記ビデオデータのセクション、特にビデオフレームのデータは、前記ＨＴＴＰチャンク転送エンコードモードを用いてセクションでの不連続伝送のためのブロックとして、前記データの長さの指示と共にそれぞれ伝送される請求項２乃至６のうちいずれか一項記載の方法。
【請求項８】
フレーム内符号化ビデオフレーム又は順方向予測符号化ビデオフレームのデータは、ＭＰＥＧ２符号化ビデオフィルムのデータセクションとしてそれぞれ伝送される請求項７記載の方法。
【請求項９】
前記分散局のネットワークは、インターネットプロトコルに基づいて制御されるネットワークである請求項１乃至８のうちいずれか一項記載の方法。
【請求項１０】
前記ネットワーク加入者局は、ユニバーサル・プラグ・アンド・プレイを表すＵＰｎＰ規格に従う制御のために設計される請求項９記載の方法。
【請求項１１】
請求項１乃至１０のうちいずれか一項記載の方法を実行する要求電化製品としてのネットワーク加入者局であって、
要求に応じて、データのセクションでの不連続伝送のために、ファイル名、ファイルタイプ、経路、再生速度、再生方向、及び開始位置といった所要のパラメータの詳細を有するＨＴＴＰ−ＧＥＴ要求を作成するプログラム手段を含むネットワーク加入者局。
【請求項１２】
高速検索処理を実行するコマンドを受信する手段と、
前記コマンドの受信に応答して前記ＨＴＴＰ−ＧＥＴ要求を作成するよう前記プログラム手段を作動させる手段と、
を有する請求項１１記載のネットワーク加入者局。
【請求項１３】
請求項１乃至１０のうちいずれか一項記載の方法を実行するソース電化製品としてのネットワーク加入者局であって、
ファイル名、ファイルタイプ、経路、再生速度、再生方向、及び開始位置といった所要のパラメータの詳細を有するデータのセクションでの不連続伝送のために、宛先電化製品（２０）からの受信ＨＴＴＰ−ＧＥＴ要求を評価するプログラム手段と、
前記要求されたデータを、前記宛先電化製品に伝送する伝送手段と、
を含むネットワーク加入者局。
【請求項１４】
前記伝送手段は、前記要求されたデータを、ＨＴＴＰチャンク転送エンコードモードを用いて転送する請求項１３記載のネットワーク加入者局。
【請求項１５】
ＭＰＥＧビデオデータを伝送する手段が設けられ、
前記ＭＰＥＧビデオデータを伝送する手段は、前記ＨＴＴＰチャンク転送エンコードの際に、前記ＭＰＥＧビデオデータストリーム内のフレーム内符号化ビデオフレーム及び／又は順方向予測符号化ビデオフレームのデータを別個のデータセクションとして伝送する請求項１４記載のネットワーク加入者局。
【請求項１６】
前記データをセクションで不連続伝送する手段は、前記データストリーム中の前記データセクションの位置を示す位置詳細もそれぞれ追加する請求項１４又は１５記載のネットワーク加入者局。
【請求項１７】
前記要求されたデータの伝送に対する前記応答において特定のステータスコードを戻し、前記ＨＴＴＰ−ＧＥＴ要求における前記所要のパラメータを正しく解釈することが可能であったことを伝えるフォーマッティング手段が設けられる請求項１３乃至１６のうちいずれか一項記載のネットワーク加入者局。
【請求項１８】
前記ＨＴＴＰ−ＧＥＴ要求における１つ以上の前記所要のパラメータを正しく解釈することが可能であったことを示す認知として、前記要求されたデータの伝送に対する前記応答において、前記ＨＴＴＰ−ＧＥＴ要求からの１つ以上の前記所要のパラメータを繰り返すフォーマッティング手段が設けられる請求項１３乃至１７のうちいずれか一項記載のネットワーク加入者局。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散局のネットワーク、特に、いわゆる家庭用ネットワークにおけるデータ伝送の技術分野に関する。この場合、データは、セクションで不連続的に伝送される。
【背景技術】
【０００２】
最近では、家庭領域における電化製品をネットワーク化するための様々な家庭用ネットワーク規格が、利用可能となっている。
【０００３】
マイクロソフト社によって率いられる、特にコンピュータ産業における企業といった企業のコンソーシアムは、既存のインターネットプロトコル（ＩＰ）に基づいたネットワーク制御ソフトウェアの規格のためのイニシアティブを取っている。このネットワークシステムは、ＵＰｎＰ（ユニバーサル・プラグ・アンド・プレイ）という省略形で知られるようになっている。このシステムでは、規格は、娯楽電子機器に主に関連するのではなく、実際には、特に、パーソナルコンピュータや、冷蔵庫、電子レンジ、洗濯機といった大型家庭用電化製品や、温度制御器、照明制御器、警報システム等の様々な電化製品もネットワーク内に組込まれることが可能である。
【０００４】
ＵＰｎＰフォーラムの作業委員会は、ＵＰｎＰ−ＡＶ規格を実現させており、これは、一般ＵＰｎＰ規格に基づき、ＵＰｎＰ方法の適用をＡＶ機器にまで拡張する。このような家庭用ネットワークにおいてＡＶデータ（オーディオ／ビデオデータ）を、いわゆるサーバ（ソース電化製品）と、いわゆるレンダラ電化製品（宛先電化製品）との間で転送させるには、ＵＰｎＰ−ＡＶ規格は、データの運搬に既知の伝送プロトコルが用いられるべきであることを規定する。この規格には、いわゆるＨＴＴＰ−ＧＥＴ方法（ＨＴＴＰは、ハイパー・テキスト・トランスファ・プロトコルの略語である）、及び、更に、いわゆるＲＴＰ方法（ＲＴＰは、リアル・タイム・トランスポート・プロトコルの略語である）が、既知のプロトコルとして述べられている。これらの２つのトランスポートメカニズムは、ネットワーク加入者局が、イーサネット（登録商標）バス接続を介して互いにリンクされるときに利用可能である。
【０００５】
ＨＴＴＰ−ＧＥＴ方法は、基本的な接続指向のトランスポートプロトコルであるＴＣＰ（伝送制御プロトコル）方法に基づいており、この方法では、保護されたデータ伝送（誤り補正を有する）が行われる。ＴＣＰ方法は、インターネットプロトコル（ＩＰ）に基づいている。ＨＴＴＰ−ＧＥＴ方法は、特に、ウェブサーバからウェブブラウザへのファイル（例えば、ＨＴＭＬウェブページ）の伝送のために開発された。従って、例えば、オーディオ又はビデオデータストリームの伝送の際に行われるセクションでのリアルタイムデータ伝送には適応されていない。その一方、ＨＴＴＰ−ＧＥＴ方法は、広く使用されており、アプリケーションプログラマにとって非常に単純であるよう設計されている。従って、この方法は、広く普及している。
【０００６】
ＲＴＰ方法によるトランスポートメカニズムは、同様にインターネットプロトコルに基づいているＵＤＰ（ユーザ・データグラム・プロトコル）方法に基づいており、任意の接続なしで動作し、また、誤り補正を用いないので、この方法を用いてデータが伝送されるときは、妨害が発生する場合がある。その一方、ＲＴＰ方法は、リアルタイムデータ伝送にはより良好に適しており、というのは、ＲＴＰ方法は、中間バッファ、追加時間スタンプ、及び連続番号を用いるからである。この点について、従って、多数のボトルネックによって特徴付けられるＲＴＰ方法は、特に、インターネット上でのオーディオ又はビデオ情報の伝送により適している。
【０００７】
ＨＴＴＰ−ＧＥＴ方法に基づいたトランスポートメカニズムは、ＵＰｎＰ規格において、ＡＶデータストリームの伝送のために推奨されている。ＨＴＴＰ−ＧＥＴ方法は、多くの場合において既存のファイルであるネットワーク内で利用可能なリソースを要求し、これを、宛先電化製品に完全な１つのピースとして伝送することを主に意図している。更に、いわゆるチャンク転送エンコード方法が、ＨＴＴＰバージョン１．１にも導入され、これは、伝送の開始時にその全体の長さが依然として知られていないリソースが伝送されるときに常に使用されることを意図する。この場合、リソースは、セクションでだが、連続的に（即ち、任意の隙間なく）伝送されるべきである。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
記載した従来の技術の背景に対して、本発明は、ＨＴＴＰ−ＧＥＴ方法に基づいたトランスポートメカニズムを、データストリームの伝送にいわゆるトリックモードを導入することが可能であるよう拡張することを目的とする。
【課題を解決するための手段】
【０００９】
このトリックモードは、例えば、ＡＶデータストリームの場合、早送り（順方向での検索）及び高速巻戻し（逆方向での検索）を含む。本発明は、例えば、再生速度及び再生方向、並びに再生処理の開始位置に関するＨＴＴＰ−ＧＥＴ方法の追加パラメータを定義することによってこの問題を解決する。
【００１０】
通常は、例えば、ビデオフィルムを早送り検索する間に個別のビデオフレームのみが再生され、再生されたフレーム間の他のビデオフレームは削除されるように、このようなトリックモードでは、個別のデータブロックのみが再生処理のために必要となる。事実上、従って、このことは、１つのビデオフレームＮからビデオフレームＮ＋Ｘ（順方向）又はＮ−Ｘ（逆方向）への繰り返されるジャンプをもたらす。このデータの不連続伝送をセクションで実行するには、再生速度及び再生方向、並びに再生処理の開始位置といった追加のパラメータを有する新しいタイプのＨＴＴＰ−ＧＥＴ要求を送出することが可能である。ソース装置は、ＨＴＴＰＧｅｔ応答と共に要求されたトリックモードについての要求されたデータセクションを送り返す。
【００１１】
本発明は、特に、ＡＶデータ用に、リアルタイムデータ伝送のトリックモードの実施のための単純なトランスポートメカニズムＨＴＴＰ−ＧＥＴを用いることを可能にする。本発明は更に、例えば、現在の再生時刻から１５分後といったように特定の時刻又は後において発生するデータストリームにおける位置への意図的なジャンプを許可するいわゆるナビゲーションコマンドを実施することを可能にする。
【００１２】
従属項に記載する手段方法は、本発明の方法の有利な開発及び改善を可能にする。
【００１３】
本発明の１つの有利な実施例は、ＨＴＴＰ−ＧＥＴ方法においてチャンク転送エンコードモードを用いる。具体的には、再生されるべきデータセクションは、常にチャンクとして伝送される。更に、この場合、データは、連続的に伝送されない。つまり、隙間無しに伝送されない。その代わりに、個々の伝送されるデータセクション間には省略される他の領域がある。つまり、このことは、セクションでの不連続データ伝送を表す。各チャンクの時間位置も、コメンタリライン内に指示されることが可能である。このことは、現在のトリックモードが停止されるか、又は、新しいタイプのトリックモード要求によって中断されるときにより正確な時間を有するという利点がある。
【００１４】
本発明のＨＴＴＰ−ＧＥＴ要求におけるパラメータを正しく解釈できたことを示す認知として、合意されている特別なステータスコードを戻すか、又は、パラメータを応答において繰り返すことが可能である。本発明に従って設計されていない電化製品の場合、応答は異なり得る。従って、要求電化製品は、アドレス指定された電化製品がそのようなトリックモード再現をサポートしない場合、操作者に適切な情報を送ることができる。
【００１５】
上述に対応するように、本発明の方法を実行するための要求電化製品としてのネットワーク加入者局の有利な手段を、請求項１１及び１２に列挙する。
【００１６】
更に、上述に対応するように、本発明の方法を実行するためのソース電化製品としてのネットワーク加入者局の有利な手段を、請求項１３乃至１８に列挙する。
【発明を実施するための最良の形態】
【００１７】
本発明の例示的な実施例は、以下の説明において詳細に説明し、且つ、図面に示す。
【００１８】
図１は、分散局ネットワークにおけるソース電化製品１０と宛先電化製品２０を示す。図示するように、個々のネットワーク加入者局は、イーサネット（登録商標）バス接続１５によって互いに接続されることを意図する。個々のネットワーク加入者局は、ＵＰｎＰ規格に合うよう設計されていることを想定している。ＵＰｎＰ規格は、マイクロソフト社から入手可能である。
【００１９】
更なる情報は、ＵＰｎＰシステムのオフィシャルインターネットサイトにて入手可能である。更なる情報を得るためには、インターネットサイトｗｗｗ．ＵＰｎＰ．ｏｒｇを参照されたい。
【００２０】
ソース電化製品という用語は、ＵＰｎＰシステムについてのソース電化製品の用語に対応し、サーバである。ＵＰｎＰシステムにおける宛先電化製品２０という用語は、レンダラ電化製品の用語に対応し、これは、宛先電化製品に対応する。図１に示す例では、ソース電化製品１０の２つの主な構成要素は、メモリ装置１２とＨＴＴＰサーバ１１であり、これらは、別個に強調してある。オーディオ／ビデオデータのための一般的なソース電化製品は、例えば、ＤＶＤプレイヤ、ＤＶＤレコーダ、ハードディスクレコーダ、ＤＶＨＳレコーダ、ＣＤプレイヤ、ＭＰ３プレイヤ、ビデオカメラ、或いは、パーソナルコンピュータである。再生可能なＡＶデータは、ソース電化製品１０内のメモリ装置１３内に格納される。ＨＴＴＰサーバ構成要素１１は、ＵＰｎＰ規格に基づいたこのようなＵＰｎＰ電化製品には絶対不可欠であり、また、ソフトウェアの形態であり得る。対応するプログラム方法は、従来技術から既知であり、これらの構成要素の開示に関してＵＰｎＰ規格を特に参照すべきである。
【００２１】
宛先電化製品２０内の主な構成要素は、ＨＴＴＰ送信器／受信器２２、ＨＴＴＰサーバ２１、バッファ記憶装置２３、及び復号化ロジック２４である。宛先電化製品２０は、例えば、セットトップボックスの形態でもあり得るデジタルテレビジョン、ＤＶＤプレイヤ、及び、ＭＰ３プレイヤ、或いはパーソナルコンピュータであり得る。復号化ユニット２４は、ＭＰＥＧ２符号化ビデオ情報の伝送のためのＭＰＥＧ２デコーダとして設計されなければならない。バッファ記憶装置２３は、ＲＡＭメモリユニットの形態であることが好適である。
【００２２】
以下の文章は、ＡＶデータのデータ伝送のための接続がソース電化製品と宛先電化製品間で設定されているという前提に基づいている。更に、ソース電化製品１０は、標準速度でビデオフィルムを再生しており、関連付けられるＡＶデータストリームは、設定された接続を介して、宛先電化製品２０に連続的に伝送されているものと仮定する。このとき、ユーザが、宛先電化製品２０上で順方向での高速検索を要求する。図３に示すように、このことは、遠隔制御器３０を用いて行われ得る。例示的に、図３は、タッチスクリーンディスプレイ３１が具備される汎用遠隔制御器３０を示し、そのタッチスクリーンディスプレイ３１上には、デジタルビデオレコーダ用の制御機能が表示される。このような汎用遠隔制御器は、従来技術から周知である。１つの例として、欧州特許出願ＥＰ−Ａ−０  ７８０  ９９０の従来技術を参照されたい。ディスプレイ３１上に表示されるボタンは、停止ボタン３２、再生ボタン３３、一時休止ボタン３４、記録ボタン３５、高速巻戻しボタン３６、早送りボタン３７、順方向タイトルジャンプボタン３８、及び、逆方向タイトルジャンプボタン３９である。操作者が、早送り検索を要求するために、宛先電化製品２０上のボタン３７を押す。このコマンドは次に、宛先電化製品２０によって、適切なＨＴＴＰ−ＧＥＴ要求に変換され、この要求は、ネットワークケーブル１５を介してソース電化製品に伝送される。図２は、ＨＴＴＰ−ＧＥＴ要求の構造体の詳細を示す。図示する例では、要求されたファイル名が、キーワードＧＥＴの後に続く。これは、パラメータ名ＩＴＥＭによって示される。例えば、ファイル名は、ＭｅｎＩｎＢｌａｃｋ．ＭＰＧであり、これは、ビデオフィルムの一般的な名前である。同じライン上のＨＴＴＰバージョンの詳細の後に、次のラインにおいて当該のファイルを見つけることのできる電化製品の詳細が続く。このパラメータを識別するために、第２のラインにおいてサーバ名が、表現ＨＯＳＴが前に置かれる。この例に示すサーバ名は、ｗｗｗ．ｍｙ．ｓｅｒｖｅｒである。この後のライン上の次のパラメータは、再生速度の詳細である。パラメータ名は、従って、ＡＶ＿ＳＰＥＥＤである。しかし、同時に、このパラメータは更に、再生方向も有する。図示する例では、このパラメータ詳細は、３倍速で早送り検索を実行することを示す表現Ｆｏｒｗａｒｄ＿３を有する。しかし、別個のパラメータを、再生方向のために追加的に用いることも可能である。ＨＴＴＰ−ＧＥＴ要求の第４のラインは更に、要求された検索の開始位置についてのパラメータの詳細を含む。このためのパラメータ名は、ＡＶ＿ＳＴＡＲＴＴＩＭＥである。このパラメータ名の後に、位置詳細０１．０２．０３．０２が続き、これは、現在の再生時間位置、具体的には、１時間と２分と３秒とフレーム０２を示す。ＨＴＴＰ−ＧＥＴ要求を作成するために適切なプログラムが宛先電化製品２０内に設けられ、これは、ボタン３７を押すことによって、検索処理を要求することにより開始される。このことは、以下の文章においてより詳細に説明する。
【００２３】
図４は、順方向における３倍の再生速度での要求された検索処理をより詳細に示す図である。この図は、デジタル符号化ビデオフレームの表示シーケンスを示すが、このデジタルビデオフレームは、ＭＰＥＧ２規格に基づいて符号化されている。この規格は、フレーム内符号化フレーム（Ｉフレーム）と、双方向予測符号化フレーム（Ｂフレーム）、及び、順方向予測符号化フレーム（Ｐフレーム）を区別する。最も高いデータ圧縮率は、Ｂフレームについて用いられ、次に、Ｐフレームが続く。フレーム内符号化フレームは、圧縮率が最も低いが、サポートフレームとして用いられることが可能である、つまり、これらのフレームコンテンツは、前の又は後のフレームの任意の知識なく再構成されることが可能である。ＭＰＥＧ２規格のフレームシーケンスは、ＩＢＢＰＢＢＰＢＢＰＢＢの形であるいわゆるグループ・オブ・ピクチャＧＯＰとして推薦される。図４は、３つの連続するこのようなグループ・オブ・ピクチャを示す。順方向に三倍速検索を行う手順を以下に説明する。グループ・オブ・ピクチャのＩフレーム及びＰフレームのみが再生される。従って、４つの異なるフレームが、１２フレームを有するグループ・オブ・ピクチャから表示されることが可能であり、従って、全体で、順方向における三倍速検索が結果としてもたらされる。従って、データストリーム中のＩフレームからＰフレーム、ＰフレームからＰフレーム、及び、ＰフレームからＩフレームへの検索処理の間に、ジャンプが行われる。
【００２４】
ＭＰＥＧ２符号化ビデオフレームにトリックモードを実施する技法に関する更なる詳細は、
【００２５】
【数１】
2005204278.tif 000003
及びDirk  Adolphによる論文
【００２６】
【数２】
2005204278.tif 000004
［Development  of  the  DVD  player:  problems  and  solutions］（ＦＫＴ  Ｎｏ．１１／１９９９、６６４頁以降）を参照されたい。
【００２７】
図５は、高速検索が要求された後に、ソース電化製品１０から発信されるＨＴＴＰ応答のフォーマットを示す。受信成功したＨＴＴＰ−ＧＥＴ要求に対するステータスメッセージが第１のラインに生成される。第１のラインは更に、ＨＴＴＰ方法に関連するバージョン詳細も含む。日付とクロック時刻が、応答の第２のラインに記載される。
【００２８】
第３のラインには、キーワードＣＯＮＴＥＮＴ−ＴＹＰＥを用いて、次に伝送されるデータのタイプを示す。引用する例では、データのタイプは、ＭＰＥＧ２フォーマットを用いて符号化されたビデオデータである。第４のラインは、後続の伝送は、チャンク転送エンコードモードを用いることを示すよう用いられる。次に、第１のデータセクションが伝送される。この前に、１６進数字を用いて、関連のデータセクションの長さの詳細が置かれる。図４と共に既に説明したように、ＩフレームとＰフレームのデータのみが、検索のために伝送されるので、Ｉフレームのビデオデータは、毎回、ここでは、データセクションとして続く。標準的なビデオフレームの１つのそのようなＩフレームのデータ量は、約１２０キロバイトである。当然ながら、データ量は、フレームコンテンツによって変化する。伝送されたビデオフレームにおける各時間の詳細は、同じライン上に、セミコロンによって長さの詳細から切離されて、続く。図２を参照するに、検索は、開始時刻０１：０２：０３：０２において要求された。この時刻から始まって、ソース電化製品１０は、次のＩフレームを検索する。次のＩフレームは、時刻０１：０２：０３：０４において見つけられた。従って、ＨＴＴＰ−ＧＥＴ応答における第５のラインにおける時刻は、この値に正確に対応する。通知されたＩフレームに対するビデオデータが、次のラインに続く。このビデオフレームが伝送されると、伝送されるべき次のビデオフレームの長さ詳細が、このフレームがビデオフィルム中に位置付けられていた適切な適切な時間及び位置と共に、次のラインに続く。この後に、関連付けられるビデオデータが続く。図５は更に、そこにジャンプされ、その後伝送される第３のＰフレームについての対応する詳細を示す。この処理は、ユーザ制御器によって検索が終了される、又は、ビデオフィルムの終わりに到達するまで続けられる。チャンク転送エンコードモードにおけるデータ伝送の終わりは、値として値０のみを伝送するラインによって示される。このことは図４にも示す。
【００２９】
上述したように、これは、本発明のビデオデータの不連続ではあるが、セクションでの伝送を含む。これは、ここではＩ及びＰフレームである別個のフレームに対するビデオデータのみが伝送され、一方、それらの間のフレームに対するビデオデータは伝送されないので、不連続である。
【００３０】
本発明のＨＴＴＰ要求が、上述したようなタイプのトリックモードをサポートしない電化製品に送信されることは全く可能であるので、トリックモードをサポートしない電化製品からの応答は、要求は理解され、データストリームは、その要求内のパラメータに従うことを明らかにすべきである。このことは、図５に示すように、応答における特定ＨＴＴＰステータスコード（例えば、「２１０」、「Trick  mode  OK」）によって達成されることが可能である。
【００３１】
或いは、トリックモードパラメータは、このことを示すために、応答において繰り返され得る。その場合、応答は、以下のように形成されるであろう。
ＨＴＴＰ／１．１  ２００  ＯＫ
Ｄａｔｅ：Ｆｒｉ，３１  Ｄｅｃ  ２００３  １７：５９：５０  ＧＭＴ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ｖｉｄｅｏ／ｍｐｅｇ
Ｔｒａｎｓｆｅｒ−Ｅｎｃｏｄｉｎｇ：Ｃｈｕｎｋｅｄ
ＡＶ＿ＳＰＥＥＤ：ｆｏｒｗａｒｄ＿３
ＡＶ＿ＳＴＡＲＴＴＩＭＥ：０１．０２．０３．０４
１ＥＡＥ０；  ｔｉｍｅ＝０１：０２：０３：０４
・
・
・
周知のステータスコード２００  ＯＫは、この応答において単純に用いられる。しかし、トリックモードパラメータは、実際には、このために繰り返される。このことは、トリックモードパラメータを解釈することができなければ、標準電化製品によって行われない。パラメータＡＶ＿ＳＴＡＲＴＴＩＭＥの詳細には、時刻は、第１の伝送されたビデオフレームに関連付けられる値と適合するようにされる。このことは、任意選択的である。要求の時刻のみを単純に繰り返すことも可能である。
【００３２】
図６は、ユーザによって高速検索処理が要求されると、宛先電化製品２０において処理されるプログラムのフローチャートの一例を示す。プログラムは、操作者が、順方向検索ボタン３７を動作させると、プログラム段階４０において開始する。ビデオフィルムは既に、標準速度で再生されているので、検索処理のための要求されたパラメータは、次のプログラム段階４１において、再生されているビデオフィルムからも抽出可能である。これらは、まず、現在の再生時間の時刻、映されているフィルムのファイル名、ビデオフィルムが格納されるサーバ名である。新しい動作モードのためのパラメータも記録される。単純な場合において、このパラメータは、検索ボタン３７の動作に永久的に関連付けられ得る。このボタンは、その場合、順方向検索（三倍速）パラメータに永久的に関連付けられる。
【００３３】
観られているビデオフィルムの標準の再生は、次のプログラム段階４２において停止される。更なるビデオフレームのデータを依然として含み得るバッファ記憶装置２３は、次のプログラム段階４３において消去される。この措置は、標準の再生から検索再現に専用の移行、より正確には、妨害と恐らく思われ得る如何なる主な遅れ時間なしで、専用の移行が行われることを意味する。
【００３４】
次のプログラム段階４４において、プログラムは、高速検索処理のための所要のＨＴＴＰ−ＧＥＴ要求を作成する。図２は、作成されるべき要求についてのフォーマットを示す。このＨＴＴＰ−ＧＥＴ要求は、プログラム段階４５においてソース電化製品１０に送信される。このプログラムセクションは、次に、プログラム段階４６において終了する。
【００３５】
図７は、上述したＨＴＴＰ−ＧＥＴ要求の受信後に、ソース電化製品内で処理されるプログラムのフローチャートを示す一例を示す。このプログラムの開始は、プログラム段階５０にて認められる。これは、上述したＨＴＴＰ−ＧＥＴ要求の受信によって開始される。受信されたＨＴＴＰ−ＧＥＴ要求は、プログラム段階５１において評価される。この要求内で伝送されるパラメータ、特に、新しい再生処理のための開始位置、ファイル名、サーバ名、及び動作モード、つまり、順方向又は逆方向においてどの速度で検索するかが、ＨＴＴＰ−ＧＥＴ要求から抽出される。現在観られていた再生は、段階４２において、既存のＴＣＰ／ＩＰ接続によってＨＴＴＰ−ＧＥＴ要求の伝送後に自動的に終了されている。伝送された開始位置から始めて、この後に続くＩフレームが、次のプログラム段階５２において検索される。新しい再生処理は、この場合、このようにして見つけられたＩフレームから始められる。このために読出しされるビデオデータは、ＨＴＴＰ応答メッセージ内に含まれる。ＨＴＴＰ応答メッセージのフォーマットは図５に示すようなものである。従って、ＨＴＴＰチャンク転送エンコードモードが用いられる。この段階は、図７のプログラムにおいて参照番号５３によって識別される。選択されたＩフレームに対するビデオデータが伝送されると、ソース電化製品１０の駆動装置は、ビデオデータファイルにおける次のＩフレームの場所にジャンプする。このために、別個のポインタ情報アイテムが、ＭＰＥＧ２規格に従って、ビデオデータストリーム内に含まれる。次のＩフレームのデータは、次に、宛先電化製品２０に次のアイテムとして伝送される。この処理は、宛先電化製品からの接続が中断されるか、又は、ビデオフィルムの終わりとなるまで連続的に繰り返される。その場合に、図７に示すエンドレスループが終了する。
【００３６】
本発明によるＨＴＴＰ−ＧＥＴ要求のもう１つの実施例を、図８に示す。本発明では、図８に示す経路名は、ファイル名のみならず、これから開始されるべき検索についての全ての他の要求されるパラメータも含む。この例は、疑問符の後に経路に要求される全てのパラメータを列挙するよう設計される。図示するパラメータは、ファイル名、再生速度並びに方向、及び開始位置である。疑問符記号は、専用の定義されたパラメータが、ＵＲＬ（ユニフォーム・リソース・ロケータ）における＆記号によってサーバに別個に伝送されることを可能にする。この方法は、インターネット技術  ＲＦＣ  １７３８（ＲＦＣは、リクエスト・フォ・コメントを意味する）により詳細に説明される。
【００３７】
本発明は、ＡＶデータの伝送のためのトリックモード（検索）の実施だけに用いることができるのではない。これらの検索は、他のマルチメディアでも可能である。本のコンテンツが格納されたファイルを、一例として挙げる。
【００３８】
更に、本発明は、トリックモード（検索）の実行の適用だけに制限されるものではない。例えば、ドキュメント中の指示された位置（例えば、データストリーム中の１５分後の位置）にジャンプする一般的なナビゲーション処理も、従って、実行することが可能である。この場合、ＨＴＴＰ−ＧＥＴ要求の返信に対する速度の詳細は、標準再生を示し得るが、新しい開始位置は、データストリーム中の１５分後の位置に対応し得る。
【００３９】
更に、必要とされるパラメータの数及び性質は、実施例に依存して異なり得る。例えば、特定の開始位置が、永久的にプリセットされる場合には、開始位置をパラメータとして常に伝送する必要はない。短いアイテムの場合、順方向検索に対して、絶対開始位置からの開始を常に与えることが可能である。
【図面の簡単な説明】
【００４０】
【図１】分散局ネットワークにおけるソース電化製品と宛先電化製品を示す粗いブロック図である。
【図２】宛先電化製品からソース電化製品に送信される本発明のＨＴＴＰ−ＧＥＴ要求のフォーマットを示す図である。
【図３】汎用遠隔制御器の一例を示す図である。
【図４】ＭＰＥＧ２符号化ビデオデータに対する順方向における三倍速検索を一例として示す図である。
【図５】本発明のＨＴＴＰ−ＧＥＴ応答のフォーマットを示す図である。
【図６】ＨＴＴＰ−ＧＥＴ要求を作成し、且つ、ソース電化製品に送信するために用いられるプログラムのフローチャートを示す図である。
【図７】チャンク転送エンコードモードを用いたＨＴＴＰ−ＧＥＴ応答の作成及び伝送のために、ソース電化製品において処理されるプログラムのフローチャートを示す図である。
【図８】疑問符によって切離される絶対ＵＲＬの詳細を有し、同様に、要求された再生処理のための所要のパラメータも含むＨＴＴＰ−ＧＥＴ要求の宛先電化製品からソース電化製品への伝送を示す図である。
【符号の説明】
【００４１】
１０  ソース電化製品
１１  ＨＴＴＰサーバ
１２  メモリ装置
１５  バス接続
２０  宛先電化製品
２１  ＨＴＴＰサーバ
２２  ＨＴＴＰ送信器／受信器
２３  バッファ記憶装置
２４  復号化ロジック
３０  汎用遠隔制御器
３１  タッチスクリーンディスプレイ
３２  停止ボタン
３３  再生ボタン
３４  一時休止ボタン
３５  記録ボタン
３６  高速巻戻しボタン
３７  早送りボタン
３８  順方向タイトルジャンプボタン
３９  逆方向タイトルジャンプボタン
【図１】
2005204278.tif 000005
【図２】
2005204278.tif 000006
【図３】
2005204278.tif 000007
【図４】
2005204278.tif 000008
【図５】
2005204278.tif 000009
【図６】
2005204278.tif 000010
【図７】
2005204278.tif 000011
【図８】
2005204278.tif 000012