JP2006042353A

JP2006042353A - ライブコンテンツ管理方法、ソース装置及びシンク装置

Info

Publication number: JP2006042353A
Application number: JP2005216020A
Authority: JP
Inventors: Cheol-Hong An; 哲弘安; Jinkan Kin; 仁煥金; Alexandre Magzoumov; アレクサンドレ・マグゾモブ; Ho-Jeong You; 浩昌柳; Jun-Hae Choi; 峻會崔; Ju-Han Lee; 柱漢李
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2004-07-27
Filing date: 2005-07-26
Publication date: 2006-02-09
Also published as: CN1741529A; US20060026654A1; KR20060010173A; KR100611985B1

Abstract

【課題】ライブコンテンツ管理方法、ソース装置及びシンク装置を提供する。
【解決手段】ネットワークを通じてライブコンテンツを管理する方法において、ライブコンテンツを提供するソース装置から、ライブコンテンツを提供されるシンク装置へのライブコンテンツの伝送が一時中止されるとき、ライブコンテンツをソース装置の保存部に保存するステップを含み、また、ライブコンテンツの伝送中止のタイムアウト以前に、シンク装置から保存されたライブコンテンツの再開要請を受信した場合に、保存部に保存されたライブコンテンツを伝送し、新たに受信されるライブコンテンツを、保存部を経てシンク装置へ伝送するステップをさらに含むライブコンテンツ管理方法である。
【選択図】図２

Description

本発明は、ネットワークを通じるライブコンテンツ管理に係り、特に、ライブコンテンツ管理方法、ソース装置及びシンク装置に関する。

デジタル時代の拡散及び発展により、周辺でさらに多くのデジタル製品が提供されている。例えば、ＤＶＤプレーヤ、ケーブルＳＴＢ（ＳｅｔＴｏｐＢｏｘｅｓ）、ＤＶＣＲ（ＤｉｇｉｔａｌＶｉｄｅｏＣａｓｓｅｔｔｅＲｅｃｏｒｄｅｒ）、ＤＴＶ（ＤｉｇｉｔａｌＴＶ）、ＰＣ（ＰｅｒｓｏｎａｌＣｏｍｐｕｔｅｒ）の多くのデジタル製品が一つのネットワークに連結されている。このような多様な機器は、ネットワークで連結され、それを制御するためのホームネットワーク標準がＤＨＷＧ（ＤｉｇｉｔａｌＨｏｍｅＷｏｒｋｉｎｇＧｒｏｕｐ）により定立されている。

最近、ホームネットワーク内のマルチメディア環境は、３つのワールド、すなわちＰＣインターネットワールド、モバイルワールド、ＣＥ（ＣｏｎｓｕｍｅｒＥｌｅｃｔｒｏｎｉｃｓ）ブロードキャストワールドに大別できる。

図１は、従来技術によって、ＤＨＷＧによるホームネットワーク環境を説明するための参考図である。

ＰＣインターネットワールド１００は、ＰＣとＰＣ周辺通信装置とを備える。具体的には、ＰＣ１０１、ゲームコンソール１０２、プリンタ１０３、デジタルイメージング装置１０４、デジタルミュージック装置１０５、及び無線モニタ１０６などを備える。

モバイルワールド１１０は、ラップトップコンピュータ１１１、マルチメディアモバイルフォーン１１２、及びＰＤＡ（ＰｅｒｓｏｎａｌＤｉｇｉｔａｌＡｓｓｉｓｔａｎｔ）１１３などを備え、このようなモバイル装置は、ホームネットワークの内部だけでなく外部の環境でも、ユーザーに移動の自由を提供する。

ＣＥブロードキャストワールド１２０は、ＴＶモニタ１２１、ＰＶＲ（ＰｅｒｓｏｎａｌＶｉｄｅｏＲｅｃｏｒｄｅｒ）、チューナ、ＳＴＢなどの伝統的なＣＥ１２２、及びステレオセット１２３などを備える。

消費者は、このような３つのドメインにあるデバイスを、家庭内で共に連動して動作させることを所望する。このようなデジタルワールド間の相互互換性を実現するためのホームネットワーク研究が要求される。

デジタルホームは、ＣＥ、モバイル、ＰＣデバイスのネットワークから構成され、このようなネットワークは、トランスペアレントであり、かつ簡単であることで、継ぎ目のない相互互換性のために協力せねばならない。そして、このようなネットワークは、ＩＰネットワーキング及びＵＰｎＰ（ＵｎｉｖｅｒｓａｌＰｌｕｇａｎｄＰｌａｙ）技術に基づく。

ＵＰｎＰオーディオ／ビデオ技術によるメディア管理及び制御は、デバイスとアプリケーションとがホームネットワーク上でメディアコンテンツを識別し、管理し、配布することを可能にし、また、それをモバイルデバイスへ伝送することを可能にする。

ＵＰｎＰは、インテリジェントアプリケーション、無線デバイス及びＰＣなどのピアツーピアのネットワーク連結性のためのアーキテクチャーである。それは、家庭や、小規模ビジネスなどの規模が小さいネットワークに使用し易く、融通性があり、標準に基盤した連結性を提供するように設計される。ＵＰｎＰＡＶアーキテクチャーは、ＵＰｎＰコントロールポイントとＵＰｎＰデバイスとの間の一般的なインタラクションを定義する。ＵＰｎＰアーキテクチャーは、いかなる形態のコンテンツ及びいかなる種類の伝送プロトコルも、デバイスが支援可能にする。ＵＰｎＰデバイスは、ＴＶ、ＶＣＲ、ＣＤ／ＤＶＤプレーヤ、ＳＴＢ、ステレオシステム、ＭＰ３プレーヤ、スチールイメージカメラ、カムコーダ、ＰＣなどを含む。そして、ＡＶアーキテクチャーは、デバイスがＭＰＥＧ（ＭｏｔｉｏｎＰｉｃｔｕｒｅＥｘｐｅｒｔｓＧｒｏｕｐ）２、ＭＰＥＧ４、ＪＰＥＧ（ＪｏｉｎｔＰｈｏｔｏｇｒａｐｈｉｃＥｘｐｅｒｔｓＧｒｏｕｐ）、ＭＰ３、ＢＭＰ（ｂｉｔｍａｐ）、ＷＭＡ（ＷｉｎｄｏｗＭｅｄｉａＡｒｃｈｉｔｅｃｔｕｒｅ）など相異なる種類のフォーマットを有したコンテンツ、及びＩＥＥＥ（ＩｎｓｔｉｔｕｔｅｏｆＥｌｅｃｔｒｉｃａｌａｎｄＥｌｅｃｔｒｏｎｉｃｓＥｎｇｉｎｅｅｒｓ）−１３９４、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）ＧＥＴ、ＲＴＰ（ＬｉｖｅＴｒａｎｓｐｏｒｔＰｒｏｔｏｃｏｌ）、ＨＴＴＰＰＵＴ／ＰＯＳＴ、ＴＣＰ（ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ）／ＩＰのような多様な種類の伝送プロトコルを支援可能にする。

ほとんどのＵＰｎＰＡＶのシナリオは、ムービー、音楽、ピクチャのようなコンテンツが一つのデバイスから他のデバイスへ伝送されることを含む。ＡＶコントロールポイントは、ソースとシンクとして役割を行う二つ以上のＵＰｎＰデバイスと相互作用する。

メディアサーバは、ユーザーがレンダリングしようとするコンテンツを有している。メディアサーバは、複数のコンテンツを有しているか、またはアクセスできる。メディアサーバは、そのコンテンツをアクセスして、それを所定の伝送プロトコルを利用して、ネットワークを通じて他のデバイスへ伝送する。メディアサーバの例としては、ＶＣＲ、ＣＤ／ＤＶＤプレーヤ、カメラ、カムコーダ、ＰＣ、ＳＴＢ、衛星受信器、オーディオテーププレーヤなどを含む。

メディアサーバコントロールポイントは、再生などのユーザーが所望の作業を行うために、ユーザーにより指定された通りメディアサーバの動作を調整して管理する。また、メディアサーバコントロールポイントは、ユーザーがデバイスの動作を制御するために、インタラクト可能なユーザーインターフェースを提供する。コントロールポイントの例としては、一般的なリモコンを有したＴＶや無線ＰＤＡデバイスを挙げることができる。また、ユーザーにより要求される場合、コントロールポイントは、Ｓｔｏｐ、Ｐａｕｓｅ、ＦＦ、ＲＥＷ、Ｓｋｉｐのような多様なＡＶ伝送アクションを起動することによって、コンテンツの流れを制御できる。

図１に示したようなホームネットワーク環境で、ネットワークを通じてライブコンテンツが伝送されている途中で一時中止された場合に、そのライブコンテンツを効果的に管理できる方法が要求される。
米国特許第６，１８２，０９４号明細書

本発明の目的は、ネットワークを通じて、Ａ／Ｖコンテンツを管理可能にするライブコンテンツ管理方法、ソース装置及びシンク装置を提供するところにある。

前記の課題を解決するための本発明の一つの特徴は、ネットワークを通じてライブコンテンツを管理する方法において、前記ライブコンテンツを提供するソース装置から、前記ライブコンテンツを提供されるシンク装置への前記ライブコンテンツの伝送が一時中止されるとき、前記ライブコンテンツを前記ソース装置の保存部に保存するステップを含むことである。

前記管理方法は、前記ライブコンテンツの伝送中止のタイムアウト以前に、前記シンク装置から前記保存されたライブコンテンツのｒｅｓｕｍｅ（再開）要請を受信した場合に、前記保存部に保存されたライブコンテンツを伝送し、新たに受信されるライブコンテンツを、前記保存部を経て前記シンク装置へ伝送するステップをさらに含むことが望ましい。

また、前記管理方法は、前記ライブコンテンツの保存により、前記ライブコンテンツの変更された状態情報を前記シンク装置へ伝送するステップをさらに含むことが望ましい。

また、前記管理方法は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記シンク装置から前記ライブコンテンツの伝送要請を受信した場合に、新たに受信されるライブコンテンツを直接前記シンク装置へ伝送するステップをさらに含むことが望ましい。

前記シンク装置からのライブコンテンツの伝送要請は、ＨＴＴＰＧＥＴ命令により伝送されることが望ましい。

また、前記管理方法は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記シンク装置から前記保存部に保存されたライブコンテンツの伝送要請を受信した場合に、前記保存部に保存されたライブコンテンツを伝送し、新たに受信されるライブコンテンツを、前記保存部を通じて前記シンク装置へ伝送するステップをさらに含むことが望ましい。

前記シンク装置からのライブコンテンツの伝送要請は、再生範囲が指定されたＨＴＴＰＧＥＴ命令により伝送されることが望ましい。

また、前記管理方法は、前記指定された再生範囲が前記保存部に保存されたライブコンテンツの範囲を外れる場合、エラーメッセージを前記シンク装置へ伝送するか、または新たに受信されるライブコンテンツを前記シンク装置へ伝送するステップをさらに含むことが望ましい。

また、前記管理方法は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記シンク装置から前記保存されたライブコンテンツの伝送要請を受信した場合に、前記保存されたライブコンテンツを、トリックプレイを通じて前記シンク装置へ伝送するステップをさらに含むことが望ましい。

前記トリックプレイを通じた伝送ステップは、前記シンク装置から再生範囲が指定されたＨＴＴＰＧＥＴ命令を少なくとも１回以上受信することに応答して、前記指定された再生範囲に対応する前記ライブコンテンツを１回以上伝送するステップを含むか、または前記シンク装置からトリックプレイが指定されたＨＴＴＰＧＥＴ命令を受信し、それに応答して前記トリックプレイ情報に対応するように、前記ライブコンテンツを伝送するステップを含むことが望ましい。

本発明の他の特徴は、ネットワークを通じてライブコンテンツを管理する方法において、前記ライブコンテンツを提供するソース装置から前記ライブコンテンツの伝送を一時中止し、前記ライブコンテンツを前記ソース装置で保存可能にするために、前記ソース装置へ前記ライブコンテンツの伝送を一時中止するように要請するステップを含むことである。

前記管理方法は、前記ライブコンテンツの伝送中止のタイムアウト以前に、前記ソース装置に保存されたライブコンテンツのｒｅｓｕｍｅ要請を伝送するステップと、前記要請に応答して、前記ソース装置に保存されたライブコンテンツを受信するステップと、を含むことが望ましい。

また、前記管理方法は、前記ソース装置から前記ライブコンテンツの保存により、前記ライブコンテンツの変更された状態情報を受信するステップをさらに含むことが望ましい。

また、前記管理方法は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記ソース装置へ前記ライブコンテンツの伝送を要請し、それに応答して、前記ソース装置で新たに受信されるライブコンテンツを直接受信するステップをさらに含むことが望ましい。

前記ライブコンテンツの伝送要請は、ＨＴＴＰＧＥＴ命令により伝送されることが望ましい。

また、前記管理方法は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記ソース装置へ前記ソース装置に保存されたライブコンテンツの伝送を要請し、それに応答して、前記ソース装置に保存されたライブコンテンツ及び前記ソース装置で新たに受信されるライブコンテンツを受信するステップをさらに含むことが望ましい。

前記保存されたライブコンテンツの伝送要請は、再生範囲が指定されたＨＴＴＰＧＥＴ命令により伝送されることが望ましい。

また、前記管理方法は、前記指定された再生範囲が前記ソース装置に保存されたライブコンテンツの範囲を外れる場合、前記ソース装置からエラーメッセージを受信するか、または前記ソース装置で新たに受信されるライブコンテンツを前記ソース装置から提供されるステップをさらに含むことが望ましい。

また、前記管理方法は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記ソース装置へ前記保存されたライブコンテンツの伝送を要請し、それに応答して、前記ソース装置に保存されたライブコンテンツを、トリックプレイを通じて前記ソース装置から受信するステップをさらに含むことが望ましい。

前記トリックプレイを通じた受信ステップは、前記ソース装置へ再生範囲が指定されたＨＴＴＰＧＥＴ命令を少なくとも１回以上伝送したことに応答して、前記指定された再生範囲に対応する前記ライブコンテンツを１回以上前記ソース装置から受信するステップを含むか、または前記ソース装置へトリックプレイが指定されたＨＴＴＰＧＥＴ命令を伝送し、それに応答して、前記トリックプレイ情報に対応する前記ライブコンテンツを受信するステップを含むことが望ましい。

本発明のさらに他の特徴は、ネットワークを通じてライブコンテンツを管理するソース装置において、前記ライブコンテンツを提供する前記ソース装置から、前記ライブコンテンツを提供されるシンク装置への前記ライブコンテンツの伝送が一時中止されるとき、ネットワークを通じて受信されるライブコンテンツを保存部に保存するように制御する制御部を備えることである。

本発明のさらに他の特徴は、ネットワークを通じてライブコンテンツを管理するシンク装置において、前記ライブコンテンツを提供するソース装置から前記ライブコンテンツの伝送を一時中止し、前記ライブコンテンツを前記ソース装置で保存可能にするために、前記ソース装置へ前記ライブコンテンツの伝送を一時中止するように要請する制御部を備えることである。

本発明の構成によれば、ホームネットワーク環境で、ネットワークを通じてライブコンテンツが伝送されている途中で一時中止された場合に、そのライブコンテンツを効果的に管理できる方法を提案して、ネットワークを通じた多様なデータ転送のシナリオを提供できる。

以下では、添付された図面を参照して本発明を詳細に説明する。

図２は、本発明によって、ネットワークを通じてライブコンテンツを管理するシステム構成図である。

図２に示すように、システムは、ソース装置３００及びシンク装置４００を備える。ソース装置３００は、シンク装置４００からのライブコンテンツ要請を受信して、ライブコンテンツを要請した装置へコンテンツを伝送し、シンク装置は、ソース装置からライブコンテンツに関する情報を持ってきて、またライブコンテンツを要請して、ソース装置からライブコンテンツを受信して消費する。

ソース装置３００は、チューナ３１０、ストリーミングサーバ＋メディアサーバ３２０、保存部３３０、及びバイトカウンタ３４０を備える。

チューナ３１０は、ネットワークを通じて放送されるライブコンテンツを受信して、ストリーミングサーバ＋メディアサーバ３２０に提供する。

ストリーミングサーバは、コンテンツをシンク装置に提供する役割を行い、メディアサーバは、シンク装置にコンテンツについての情報を提供する役割を行う。

特に、本発明によるストリーミングサーバは、チューナ３１０を通じて受信されたライブコンテンツをシンク装置に提供するか、または保存部３３０に保存されたコンテンツを読み込んでシンク装置に提供する。

保存部３３０は、ライブコンテンツを、ネットワークを通じてシンク装置へ伝送できない場合、このライブコンテンツを保存する。

バイトカウンタ３４０は、シンク装置へ現在まで伝送されたライブコンテンツの数またはコンテンツの時間情報を計算する。

シンク装置４００は、ストリーミングクライアント＋メディアサーバコントロールポイント４１０、再生部４２０、及びバイトカウンタ４３０を備える。シンク装置４００は、Ａ／Ｖコンテンツを消費する役割を行う。例えば、ユーザーから“ｐｌａｙ”という命令を受ければ、シンク装置は、例えばＨＴＴＰプロトコルを利用して該当データを読み込む。

ストリーミングクライアント＋メディアサーバコントロールポイント４１０内のメディアサーバコントロールポイントは、ソース装置３００からコンテンツの情報を取得し、ユーザーから命令による動作を行う。

ストリーミングクライアント＋メディアサーバコントロールポイント４１０内のストリーミングクライアントは、ソース装置３００に制御命令を伝達し、該当コンテンツを受信する役割を行う。

バイトカウンタ４３０は、現在まで受信したデータの数または該当データの時間情報を計算する。

再生部４２０は、ストリーミングクライアントからコンテンツを受信して、それを再生する。

図３は、図２に示したソース装置３００の概略的な構成図である。

ソース装置３００の他の構成は、図２に示したと同一であり、ストリーミングサーバ＋メディアサーバ３２０の細部的な構成が示されている。

ストリーミングサーバ＋メディアサーバ３２０は、ストリーミングサーバ３２１及びメディアサーバ３２４から構成される。

メディアサーバ３２４は、制御命令管理部３２５、コンテンツ管理部３２６、及びコンテンツ状態情報３２７を備える。

制御命令管理部３２５は、制御命令を生成してシンク装置へ伝送し、シンク装置から受信された制御命令を解釈して適切な処理を行う。本発明によって、制御命令管理部３２５は、シンク装置からｂｒｏｗｓｅ／ｓｅａｒｃｈ命令などを受信した場合に、それを解釈し、コンテンツ管理部３２６により自身が管理しているコンテンツについての状態情報をシンク装置へ伝送するように制御する。

コンテンツ管理部３２６は、コンテンツについての状態情報３２７を管理する。すなわち、シンク装置のメディアサーバコントロールポイントからコンテンツについての情報を要請する命令を受信すれば、コンテンツについての情報を検索して、検索されたコンテンツに関する情報をシンク装置へ伝送する。特に、本発明によって、コンテンツ管理部３２６は、チューナ３１０を通じて受信されるライブコンテンツが保存部に保存される場合に、このコンテンツがシーク可能であるか、またはトリックプレイが可能であるか等についての状態情報を変更し、このようにコンテンツについての状態情報が変更されたことを、例えばイベント形式でシンク装置に知らせる。このような制御命令管理部３２５及びコンテンツ管理部３２６は、制御部（図示せず）の制御によりその機能を行う。

ストリーミングサーバ３２１は、制御命令管理部３２２及びコンテンツ伝送部３２３を備える。

制御命令管理部３２２は、シンク装置から受信されたコンテンツに関する制御命令を受信して解釈し、その解釈結果によって、コンテンツ伝送部３２３を適切に制御する。コンテンツについての制御命令としては、ｐｌａｙ、ｐａｕｓｅ、ｒｅｓｕｍｅ、ＦＦ、ＲＷなどの命令を含む。

コンテンツ伝送部３２３は、シンク装置から要請されたライブコンテンツをチューナ３１０から直接受信してシンク装置へ伝送するか、またはコンテンツ保存部３００に保存されたコンテンツを読み込んでシンク装置へ伝送する。コンテンツ保存部３００に保存されたコンテンツを読み込んでシンク装置へ伝送する場合には、バイトカウンタ３４０から提供されたコンテンツの数または時間情報を参照して、保存部３３０から指定されたコンテンツの範囲を探す。

バイトカウンタ３４０は、シンク装置へ現在まで伝送されたライブコンテンツの数またはコンテンツの時間情報を計算して、コンテンツ伝送部３２３に提供する。

このような制御命令管理部３２２、コンテンツ伝送部３２３及びバイトカウンタ３４０は、制御部（図示せず）の制御によりその機能を行う。

図４は、図２に示したシンク装置の概略的な構成図である。

シンク装置４００の他の構成は、図２に示したものと同一であり、ストリーミングクライアント＋メディアサーバコントロールポイント４１０の細部的な構成が示されている。

メディアサーバコントロールポイント４１４は、制御命令管理部４１５及びユーザーインターフェース４１６を備える。

ユーザーインターフェース４１６は、ユーザーからＡ／Ｖコンテンツについての制御動作命令、例えば“ｐｌａｙ”などの動作命令を受信して制御命令管理部４１５に伝達する。

制御命令管理部４１５は、ＢｒｏｗｓｅまたはＳｅａｒｃｈ命令を利用してソース装置にコンテンツについての情報を要請し、ソース装置からコンテンツについての情報を受信すれば、受信されたコンテンツについての情報を解釈する。また、特定のコンテンツについての情報を得るために、コンテンツ情報を要請し、それを受信して解釈し、これによって解釈された情報またはユーザーインターフェースを通じて受信したユーザー命令に関する情報をストリーミングクライアント４１１に伝達する。特に、本発明によって、制御命令管理部４１５は、ソース装置からコンテンツの状態情報が変更されたことを知らせるイベントなどを受信した場合に、その具体的な変更された状態情報を得るために、それをソース装置に要請して受信する。制御命令管理部４１５及びユーザーインターフェース４１６は、制御部（図示せず）の制御によりその機能を行う。

ストリーミングクライアント４１１は、制御命令管理部４１３及びコンテンツ受信部４１２を備える。

制御命令管理部４１３は、メディアサーバコントロールポイント４１４から受信したユーザー命令に関する情報、またはコンテンツ解釈情報を参照してコンテンツについての制御命令を生成し、それを伝送する。特に、本発明によって、制御命令管理部４１３は、所定のコンテンツを持ってくるために、ＨＴＴＰＧｅｔ命令や、ｐａｕｓｅ、ｒｅｓｕｍｅ命令などをソース装置へ伝送し、またトリックプレイなどのために、範囲が指定されたＨＴＴＰＧｅｔ命令やｐｌａｙｓｐｅｅｄが指定されたＨＴＴＰＧｅｔ命令などを伝送する。

コンテンツ受信部４１２は、ソース装置からＡ／Ｖコンテンツを受信して、それを再生部４２０へ伝送する。制御命令管理部４１３、コンテンツ受信部４１２及びバイトカウンタは、制御部（図示せず）の制御によりその機能を行う。

図５は、本発明の第１実施形態によって、シンク装置からソース装置にライブコンテンツについてのｐａｕｓｅ命令を受信する場合、ｐａｕｓｅ命令のタイムアウトが発生しない状況で、ライブコンテンツについてのｒｅｓｕｍｅ動作を行う過程のフローチャートである。

シンク装置は、ソース装置からコンテンツについての情報を得るために、ｂｒｏｗｓｅ／ｓｅａｒｃｈのような命令をソース装置へ送信する（５０１）。

この命令を受けたソース装置は、自身が持っているコンテンツについての情報をシンク装置に伝達する（５０２）。

シンク装置では、ライブコンテンツを見るために、所望のコンテンツについての該当ＵＲＬ１を有したＨＴＴＰＧｅｔ命令を送信し（５０３）、ソース装置は、そのＵＲＬ１に該当するコンテンツをシンク装置へ伝送する（５０４）。この場合、ライブコンテンツは、実際のチューナから直接入るライブデータである。

ＨＴＴＰＧｅｔＵＲＬ１命令の一例が図１０に示されている。図１０に示すように、ＨＴＴＰＧｅｔ命令は、“ＵＲＬ１”で識別される情報を照会せよという要請を含んでおり、“ＨＯＳＴ”は、志願が要請されたインターネットホストを識別する情報をいう。ＨＯＳＴフィールドには、“ｈｏｓｔｏｆｃｏｎｔｒｏｌＵＲＬ１”及び“ｐｏｒｔｏｆｃｏｎｔｒｏｌＵＲＬ１”が入る。そして、Ａｃｔｉｏｎには、ｐｌａｙが指定されている。

もし、シンク装置がライブコンテンツを一時中止するために、ｐａｕｓｅ命令をソース装置へ伝送すれば（５０５）、ソース装置は、ライブコンテンツを自身の保存部に保存する。ｐａｕｓｅ命令は、コンテンツの伝送を一時中止せよという命令であって、このようなｐａｕｓｅ命令の一例が図１１に示されている。もちろん、他のプロトコルによる制御命令を使用することもあるが、図１１には、ＨＴＴＰＰｏｓｔ命令の例を示した。

そして、ソース装置は、ライブコンテンツについての状態情報を、例えばシークが可能である、またはトリックプレイが可能である状態に変更し、該当コンテンツにこのような状態変更があることを、イベントなどを通じてシンク装置に知らせる（５０６）。

これにより、シンク装置は、このような状態変更があることが分かり、ｂｒｏｗｓｅ／ｓｅａｒｃｈ命令をソース装置へ送信し（５０７）、ソース装置からこのコンテンツについての変更された状態情報を得て、コンテンツについての状態情報を更新する（５０８）。

しかし、ｐａｕｓｅタイムアウト以前に、シンク装置が同一なコンテンツについてｒｅｓｕｍｅ命令をソース装置へ伝送すれば（５０９）、ソース装置は、現在のチューナから受信されるデータは保存部に保存し、以前に保存部に保存されたデータ、すなわちタイムシフトされたデータをシンク装置に伝達する（５１０）。ｒｅｓｕｍｅ命令は、一時中止されたコンテンツの伝送を再び始めさせる命令であって、このようなｒｅｓｕｍｅ命令の一例が図１２に示されている。もちろん、他のプロトコルによる制御命令を使用することもできる。ここで、ｐａｕｓｅタイムアウトは、ソース装置またはシンク装置で内部的または外部的要因により発生し、各装置で任意的に発生させることもできる。

図６は、本発明の第２実施形態によって、シンク装置からソース装置にライブコンテンツについてのｐａｕｓｅ命令を受信する場合、ｐａｕｓｅ命令のタイムアウトが発生した状況で、ライブコンテンツを再び伝送する動作を行う過程のフローチャートである。

シンク装置は、ソース装置にｂｒｏｗｓｅ／ｓｅａｒｃｈのような命令を送信し（６０１）、コンテンツについての情報を伝達され（６０２）、シンク装置でライブコンテンツを見るために、所望のコンテンツについての該当ＵＲＬ１を有したＨＴＴＰＧｅｔ命令を送信し（６０３）、そのＵＲＬ１に該当するコンテンツをソース装置から受信し（６０４）、ｐａｕｓｅ命令（６０５）によりライブコンテンツの伝送が中止し、ソース装置がコンテンツについての状態変更があることをシンク装置に知らせ（６０６）、ｂｒｏｗｓｅ／ｓｅａｒｃｈ命令（６０７）により、シンク装置がコンテンツについての状態情報を更新（６０８）する動作は、図５に示した動作と同一である。

このような状態で、シンク装置やソース装置で、ある原因によりｐａｕｓｅタイムアウトが発生した場合（６０９）、シンク装置が保存したデータではなく現在放送されているデータを見ようとする場合に、ＨＴＴＰＧｅｔＵＲＬ１の命令をソース装置に送信する（６１０）。このようなＨＴＴＰＧｅｔＵＲＬ１命令を受信したソース装置は、現在受信されるライブコンテンツを直接シンク装置へ伝送する（６１１）。

図７は、本発明の第３実施形態による、シンク装置からソース装置にライブコンテンツについてのｐａｕｓｅ命令を受信する場合、ｐａｕｓｅ命令のタイムアウトが発生した状況で、ｐａｕｓｅの間に保存されたコンテンツを伝送する動作を行う過程のフローチャートである。

シンク装置は、ソース装置にｂｒｏｗｓｅ／ｓｅａｒｃｈのような命令を送信し（７０１）、コンテンツについての情報を伝達され（７０２）、シンク装置でライブコンテンツを見るために、所望のコンテンツについての該当ＵＲＬ１を有したＨＴＴＰＧｅｔ命令を送信し（７０３）、そのＵＲＬ１に該当するコンテンツをソース装置から受信し（７０４）、ｐａｕｓｅ命令（７０５）によりライブコンテンツの伝送が中止し、ソース装置がコンテンツについての状態変更があることをシンク装置に知らせ（７０６）、ｂｒｏｗｓｅ／ｓｅａｒｃｈ命令（７０７）により、シンク装置がコンテンツについての状態情報を更新（７０８）する動作は、図６に示した動作と同一である。

このような状態で、シンク装置やソース装置で、ある原因によりｐａｕｓｅタイムアウトが発生した場合（７０９）、シンク装置が現在放送されるデータを見たいものではなく、ｐａｕｓｅの間に保存されたデータを受信しようとする場合に、次のような動作が行われる。

すなわち、ｐａｕｓｅタイムアウト以後、シンク装置は、ＨＴＴＰＧｅｔＵＲＬ１命令と共にｒａｎｇｅ位置または時間情報を送信する（７１０）。ｒａｎｇｅ位置や時間情報は、ソース装置に送信するデータの位置を指定する。この情報は、シンク装置のバイトカウンタから得ることができる。ｒａｎｇｅ位置が指定されたＨＴＴＰＧｅｔＵＲＬ１命令の一例が図１３に示されている。

ソース装置は、シンク装置から受信したｒａｎｇｅ情報を参照して、該当位置からデータをシンク装置へ伝送する（７１１）。この位置は、保存されたデータについての範囲内にあり、もし、シンク装置のｒａｎｇｅ情報が正確でない場合には、エラーメッセージをシンク装置に送信できる。そして、該当範囲が保存された位置から終了時点が指定されていない場合には、保存されたデータをいずれも送信した後、該当するライブコンテンツを続けて送信することもある。ソース装置も、ｐａｕｓｅ時点まで送信したデータをソース装置のバイトカウンタから分かる。

図８は、本発明の第４実施形態による、シンク装置からソース装置にライブコンテンツについてのｐａｕｓｅ命令を受信する場合、ｐａｕｓｅ命令のタイムアウトが発生した状況で、シンク装置の要請によりコンテンツを複数回受信する動作を行う過程のフローチャートである。

シンク装置は、ソース装置にｂｒｏｗｓｅ／ｓｅａｒｃｈのような命令を送信し（８０１）、コンテンツについての情報を伝達され（８０２）、シンク装置でライブコンテンツを見るために、所望のコンテンツについての該当ＵＲＬ１を有したＨＴＴＰＧｅｔ命令を送信し（８０３）、そのＵＲＬ１に該当するコンテンツをソース装置から受信し（８０４）、ｐａｕｓｅ命令（８０５）によりライブコンテンツの伝送が中止し、ソース装置がコンテンツについての状態変更があることをシンク装置に知らせ（８０６）、ｂｒｏｗｓｅ／ｓｅａｒｃｈ命令（８０７）により、シンク装置がコンテンツについての状態情報を更新（８０８）する動作は、図６に示した動作と同一である。

このような状態で、シンク装置やソース装置で、ある原因によりｐａｕｓｅタイムアウトが発生した場合（８０９）、シンク装置で複数回のデータを受信するために、複数回のＨＴＴＰＧｅｔＵＲＬ１を相異なるｒａｎｇｅ情報を利用して送信する。

すなわち、シンク装置は、ｒａｎｇｅを指定してＨＴＴＰＧｅｔＵＲＬ１をソース装置に送信し（８１０）、ソース装置からその指定された範囲に対応するコンテンツを受信する（８１１）。そして、再びシンク装置は、ｒａｎｇｅを指定してＨＴＴＰＧｅｔＵＲＬ１をソース装置に送信し（８１２）、ソース装置からその指定された範囲に対応するコンテンツを受信する（８１３）。このような動作は、シンク装置でトリックプレイを行うために使われうる。もし、ｒａｎｇｅ情報が保存されたデータの終端に到達すれば、該当データをシンク装置へ伝送し、それ以上保存されたデータがなくてシークまたはトリックプレイが不能な状態に変更し、このように状態が変更されたことを、イベントを通じてシンク装置に知らせる（８１４）。このイベントを受けたシンク装置は、変更された状態情報を知るために、ソース装置にｂｒｏｗｓｅ／ｓｅａｒｃｈ命令を送信し（８１５）、それによるコンテンツ情報を、シンク装置はソース装置から受信する。次いで、シンク装置は、ＨＴＴＰＧｅｔＵＲＬ１を実行して正常的な再生モードでコンテンツ伝送を要求でき（８１６）、ソース装置は、このような要求に応答して、ライブコンテンツを直接シンク装置へ伝送する（８１７）。

図９は、本発明の第５実施形態による、シンク装置からソース装置にライブコンテンツについてのｐａｕｓｅ命令を受信する場合、ｐａｕｓｅ命令のタイムアウトが発生した状況で、ソース装置の支援によりコンテンツを複数回伝送する動作を行う過程のフローチャートである。

シンク装置は、ソース装置にｂｒｏｗｓｅ／ｓｅａｒｃｈのような命令を送信し（９０１）、コンテンツについての情報を伝達され（９０２）、シンク装置でライブコンテンツを見るために、所望のコンテンツについての該当ＵＲＬ１を有したＨＴＴＰＧｅｔ命令を送信し（９０３）、そのＵＲＬ１に該当するコンテンツをソース装置から受信し（９０４）、ｐａｕｓｅ命令（９０５）によりライブコンテンツの伝送が中止し、ソース装置がコンテンツについての状態変更があることをシンク装置に知らせ（９０６）、ｂｒｏｗｓｅ／ｓｅａｒｃｈ命令（９０７）により、シンク装置がコンテンツについての状態情報を更新（９０８）する動作は、図６に示した動作と同一である。

このような状態で、シンク装置やソース装置で、ある原因によりｐａｕｓｅタイムアウトが発生した場合（９０９）、図８に示した動作と異なり、ソース装置でトリックプレイを支援する。すなわち、タイムアウト以後、シンク装置は、ソース装置にＨＴＴＰＧｅｔＵＲＬ１ｐｌａｙｓｐｅｅｄ＝２のような命令で、ソース装置で２倍の速度でデータを送ることを要求する（９１０）。ｐｌａｙｓｐｅｅｄが指定されたＨＴＴＰＧｅｔＵＲＬ１命令の一例が図１４に示されている。

この際、ソース装置は、２倍速い速度でデータを送信するか、またはそのような効果を得るために、それぞれ部分的なデータを送信できる（９１１）。ソース装置は、もし、保存されたデータをいずれも消尽する場合、それ以上シークまたはトリックプレイが不能な状態に状態情報を変更し、状態情報が変更されたことをイベントを通じてシンク装置に知らせる（９１２）。これにより、このイベントを受けたシンク装置は、状態情報の変更を知るためにｂｒｏｗｓｅ／ｓｅａｒｃｈを実行し（９１３）、その結果をソース装置から得る。

以上、説明したようなシンク装置及びソース装置での管理方法は、また、コンピュータで読み取り可能な記録媒体にコンピュータで読み取り可能なコードとして具現することが可能である。コンピュータで読み取り可能な記録媒体は、コンピュータシステムにより読み取られるデータが保存されるあらゆる種類の記録装置を含む。コンピュータで読み取り可能な記録媒体の例としては、ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）、ＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）、ＣＤ−ＲＯＭ、磁気テープ、フロッピー（登録商標）ディスク、光データ保存装置などがあり、またキャリアウェーブ（例えば、インターネットを通じた伝送）の形態で具現されるものも含む。また、コンピュータで読み取り可能な記録媒体は、ネットワークで連結されたコンピュータシステムに分散され、分散方式でコンピュータで読み取り可能なコードが保存されて実行されうる。そして、前記処理方法を具現するための機能的なプログラム、コード及びコードセグメントは、本発明が属する技術分野のプログラマにより容易に推論されうる。

これまで、本発明について、その望ましい実施形態を中心に述べた。当業者は、本発明が、本発明の本質的な特性から逸脱しない範囲で、変形された形態に具現可能であるということを理解できるであろう。したがって、開示された実施形態は、限定的な観点ではなく、説明的な観点で考慮されねばならない。本発明の範囲は、前述した説明ではなく、特許請求の範囲に表れており、それと同等な範囲内にあるあらゆる差異点は、本発明に含まれていると解釈されねばならない。

本発明は、例えばＤＶＤプレーヤ、ケーブルＳＴＢ、ＤＶＣＲ、ＤＴＶ、ＰＣなどの多様なデジタル機器に利用可能である。

従来技術によって、ＤＨＷＧによるホームネットワーク環境を説明するための参考図である。本発明によって、ネットワークを通じてデジタルコンテンツを共有するシステム構成図である。図２に示したソース装置の概略的な構成図である。図２に示したシンク装置の概略的な構成図である。本発明の第１実施形態によって、シンク装置からソース装置にライブコンテンツについてのｐａｕｓｅ命令を受信する場合、ｐａｕｓｅ命令のタイムアウトが発生しない状況で、ライブコンテンツについてのｒｅｓｕｍｅ動作を行う過程のフローチャートである。本発明の第２実施形態によって、シンク装置からソース装置にライブコンテンツについてのｐａｕｓｅ命令を受信する場合、ｐａｕｓｅ命令のタイムアウトが発生した状況で、ライブコンテンツを再び伝送する動作を行う過程のフローチャートである。本発明の第３実施形態によって、シンク装置からソース装置にライブコンテンツについてのｐａｕｓｅ命令を受信する場合、ｐａｕｓｅ命令のタイムアウトが発生した状況で、ｐａｕｓｅの間に保存されたコンテンツを伝送する動作を行う過程のフローチャートである。本発明の第４実施形態によって、シンク装置からソース装置にライブコンテンツについてのｐａｕｓｅ命令を受信する場合、ｐａｕｓｅ命令のタイムアウトが発生した状況で、シンク装置の要請によりコンテンツを複数回受信する動作を行う過程のフローチャートである。本発明の第５実施形態によって、シンク装置からソース装置にライブコンテンツについてのｐａｕｓｅ命令を受信する場合、ｐａｕｓｅ命令のタイムアウトが発生した状況で、ソース装置の支援によりコンテンツを複数回伝送する動作を行う過程のフローチャートである。本発明に適用されるＨＴＴＰＧＥＴ命令の一例を示す図面である。本発明に適用されるｐａｕｓｅ命令の一例を示す図面である。本発明に適用されるｒｅｓｕｍｅ命令の一例を示す図面である。本発明に適用されるｒａｎｇｅが指定されたＨＴＴＰＧＥＴ命令の一例を示す図面である。本発明に適用されるｐｌａｙｓｐｅｅｄが指定されたＨＴＴＰＧＥＴ命令の一例を示す図面である。

符号の説明

３００ソース装置
３１０チューナ
３２０ストリーミングサーバ＋メディアサーバ
３３０保存部
３４０バイトカウンタ
４００シンク装置
４１０ストリーミングクライアント＋メディアサーバコントロールポイント
４２０再生部
４３０バイトカウンタ

Claims

ネットワークを通じてライブコンテンツを管理する方法において、
前記ライブコンテンツを提供するソース装置から、前記ライブコンテンツを提供されるシンク装置への前記ライブコンテンツの伝送が一時中止されるとき、前記ライブコンテンツを前記ソース装置の保存部に保存するステップを含むことを特徴とするライブコンテンツ管理方法。
前記ライブコンテンツの伝送中止のタイムアウト以前に、前記シンク装置から前記保存されたライブコンテンツの再開要請を受信した場合に、前記保存部に保存されたライブコンテンツを伝送し、新たに受信されるライブコンテンツを、前記保存部を経て前記シンク装置へ伝送するステップをさらに含むことを特徴とする請求項１に記載のライブコンテンツ管理方法。
前記ライブコンテンツの保存により、前記ライブコンテンツの変更された状態情報を前記シンク装置へ伝送するステップをさらに含むことを特徴とする請求項１に記載のライブコンテンツ管理方法。
前記ライブコンテンツの伝送中止のタイムアウト以後に、前記シンク装置から前記ライブコンテンツの伝送要請を受信した場合に、新たに受信されるライブコンテンツを直接前記シンク装置へ伝送するステップをさらに含むことを特徴とする請求項１に記載のライブコンテンツ管理方法。
前記シンク装置からのライブコンテンツの伝送要請は、ＨＴＴＰＧＥＴ命令により伝送されることを特徴とする請求項４に記載のライブコンテンツ管理方法。
前記ライブコンテンツの伝送中止のタイムアウト以後に、前記シンク装置から前記保存部に保存されたライブコンテンツの伝送要請を受信した場合に、前記保存部に保存されたライブコンテンツを伝送し、新たに受信されるライブコンテンツを、前記保存部を通じて前記シンク装置へ伝送するステップをさらに含むことを特徴とする請求項１に記載のライブコンテンツ管理方法。
前記シンク装置からのライブコンテンツの伝送要請は、再生範囲が指定されたＨＴＴＰＧＥＴ命令により伝送されることを特徴とする請求項６に記載のライブコンテンツ管理方法。
前記指定された再生範囲が前記保存部に保存されたライブコンテンツの範囲を外れる場合、エラーメッセージを前記シンク装置へ伝送するか、または新たに受信されるライブコンテンツを前記シンク装置へ伝送するステップをさらに含むことを特徴とする請求項７に記載のライブコンテンツ管理方法。
前記ライブコンテンツの伝送中止のタイムアウト以後に、前記シンク装置から前記保存されたライブコンテンツの伝送要請を受信した場合に、前記保存されたライブコンテンツを、トリックプレイを通じて前記シンク装置へ伝送するステップをさらに含むことを特徴とする請求項１に記載のライブコンテンツ管理方法。
前記トリックプレイを通じた伝送ステップは、前記シンク装置から再生範囲が指定されたＨＴＴＰＧＥＴ命令を少なくとも１回以上受信することに応答して、前記指定された再生範囲に対応する前記ライブコンテンツを１回以上伝送するステップを含むことを特徴とする請求項９に記載のライブコンテンツ管理方法。
前記トリックプレイを通じた伝送ステップは、前記シンク装置からトリックプレイが指定されたＨＴＴＰＧＥＴ命令を受信し、それに応答して前記トリックプレイ情報に対応するように、前記ライブコンテンツを伝送するステップを含むことを特徴とする請求項９に記載のライブコンテンツ管理方法。
ネットワークを通じてライブコンテンツを管理する方法において、
前記ライブコンテンツを提供するソース装置から前記ライブコンテンツの伝送を一時中止し、前記ライブコンテンツを前記ソース装置で保存可能にするために、前記ソース装置へ前記ライブコンテンツの伝送を一時中止するように要請するステップを含むことを特徴とするライブコンテンツ管理方法。
前記ライブコンテンツの伝送中止のタイムアウト以前に、前記ソース装置に保存されたライブコンテンツの再開要請を伝送するステップと、
前記要請に応答して、前記ソース装置に保存されたライブコンテンツを受信するステップとを含むことを特徴とする請求項１２に記載のライブコンテンツ管理方法。
前記ソース装置から前記ライブコンテンツの保存により、前記ライブコンテンツの変更された状態情報を受信するステップをさらに含むことを特徴とする請求項１２に記載のライブコンテンツ管理方法。
前記ライブコンテンツの伝送中止のタイムアウト以後に、前記ソース装置へ前記ライブコンテンツの伝送を要請し、それに応答して、前記ソース装置で新たに受信されるライブコンテンツを直接受信するステップをさらに含むことを特徴とする請求項１２に記載のライブコンテンツ管理方法。
前記ライブコンテンツの伝送要請は、ＨＴＴＰＧＥＴ命令により伝送されることを特徴とする請求項１５に記載のライブコンテンツ管理方法。
前記ライブコンテンツの伝送中止のタイムアウト以後に、前記ソース装置へ前記ソース装置に保存されたライブコンテンツの伝送を要請し、それに応答して、前記ソース装置に保存されたライブコンテンツ及び前記ソース装置で新たに受信されるライブコンテンツを受信するステップをさらに含むことを特徴とする請求項１２に記載のライブコンテンツ管理方法。
前記保存されたライブコンテンツの伝送要請は、再生範囲が指定されたＨＴＴＰＧＥＴ命令により伝送されることを特徴とする請求項１７に記載のライブコンテンツ管理方法。
前記指定された再生範囲が前記ソース装置に保存されたライブコンテンツの範囲を外れる場合、前記ソース装置からエラーメッセージを受信するか、または前記ソース装置で新たに受信されるライブコンテンツを前記ソース装置から提供されるステップをさらに含むことを特徴とする請求項１８に記載のライブコンテンツ管理方法。
前記ライブコンテンツの伝送中止のタイムアウト以後に、前記ソース装置へ前記保存されたライブコンテンツの伝送を要請し、それに応答して、前記ソース装置に保存されたライブコンテンツを、トリックプレイを通じて前記ソース装置から受信するステップをさらに含むことを特徴とする請求項１２に記載のライブコンテンツ管理方法。
前記トリックプレイを通じた受信ステップは、前記ソース装置へ再生範囲が指定されたＨＴＴＰＧＥＴ命令を少なくとも１回以上伝送したことに応答して、前記指定された再生範囲に対応する前記ライブコンテンツを１回以上前記ソース装置から受信するステップを含むことを特徴とする請求項２０に記載のライブコンテンツ管理方法。
前記トリックプレイを通じた受信ステップは、前記ソース装置へトリックプレイが指定されたＨＴＴＰＧＥＴ命令を伝送し、それに応答して、前記トリックプレイ情報に対応する前記ライブコンテンツを受信するステップを含むことを特徴とする請求項２０に記載のライブコンテンツ管理方法。
ネットワークを通じてライブコンテンツを管理するソース装置において、
前記ライブコンテンツを提供する前記ソース装置から、前記ライブコンテンツを提供されるシンク装置への前記ライブコンテンツの伝送が一時中止されるとき、ネットワークを通じて受信されるライブコンテンツを保存部に保存するように制御する制御部を備えることを特徴とするソース装置。
前記制御部は、前記ライブコンテンツの伝送中止のタイムアウト以前に、前記シンク装置から前記保存されたライブコンテンツの再開要請を受信した場合に、前記保存部に保存されたライブコンテンツを伝送し、新たに受信されるライブコンテンツを、前記保存部を経て前記シンク装置へ伝送するようにさらに制御することを特徴とする請求項２３に記載のソース装置。
前記制御部は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記シンク装置から前記ライブコンテンツの伝送要請を受信した場合に、新たに受信されるライブコンテンツを直接前記シンク装置へ伝送するようにさらに制御することを特徴とする請求項２３に記載のソース装置。
前記制御部は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記シンク装置から前記保存部に保存されたライブコンテンツの伝送要請を受信した場合に、前記保存部に保存されたライブコンテンツを伝送し、新たに受信されるライブコンテンツを、前記保存部を通じて前記シンク装置へ伝送するようにさらに制御することを特徴とする請求項２３に記載のソース装置。
前記制御部は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記シンク装置から再生範囲が指定されたＨＴＴＰＧＥＴ命令を少なくとも１回以上受信することに応答して、前記指定された再生範囲に対応する前記ライブコンテンツを１回以上伝送するようにさらに制御することを特徴とする請求項２３に記載のソース装置。
前記制御部は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記シンク装置からトリックプレイが指定されたＨＴＴＰＧＥＴ命令を受信し、それに応答して前記トリックプレイ情報に対応するように、前記ライブコンテンツを伝送するようにさらに制御することを特徴とする請求項２３に記載のソース装置。
ネットワークを通じてライブコンテンツを管理するシンク装置において、
前記ライブコンテンツを提供するソース装置から前記ライブコンテンツの伝送を一時中止し、前記ライブコンテンツを前記ソース装置で保存可能にするために、前記ソース装置へ前記ライブコンテンツの伝送を一時中止するように要請する制御部を備えることを特徴とするシンク装置。
前記制御部は、前記ライブコンテンツの伝送中止のタイムアウト以前に、前記ソース装置へ保存されたライブコンテンツの再開要請を伝送し、前記要請に応答して、前記ソース装置に保存されたライブコンテンツを受信するようにさらに制御することを特徴とする請求項２９に記載のシンク装置。
前記制御部は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記ソース装置へ前記ライブコンテンツの伝送を要請し、それに応答して、前記ソース装置で新たに受信されるライブコンテンツを直接受信するようにさらに制御することを特徴とする請求項２９に記載のシンク装置。
前記制御部は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記ソース装置へ前記ソース装置に保存されたライブコンテンツの伝送を要請し、それに応答して、前記ソース装置に保存されたライブコンテンツ及び前記ソース装置で新たに受信されるライブコンテンツを受信するようにさらに制御することを特徴とする請求項２９に記載のシンク装置。
前記制御部は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記ソース装置へ再生範囲が指定されたＨＴＴＰＧＥＴ命令を少なくとも１回以上伝送したことに応答して、前記指定された再生範囲に対応する前記ライブコンテンツを１回以上前記ソース装置から受信するようにさらに制御することを特徴とする請求項２９に記載のシンク装置。
前記制御部は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記ソース装置へトリックプレイが指定されたＨＴＴＰＧＥＴ命令を伝送し、それに応答して、前記トリックプレイ情報に対応する前記ライブコンテンツを受信するようにさらに制御することを特徴とする請求項２９に記載のシンク装置。