(57)【要約】【課題】  ライブコンテンツ管理方法、ソース装置及びシンク装置を提供する。【解決手段】  ネットワークを通じてライブコンテンツを管理する方法において、ライブコンテンツを提供するソース装置から、ライブコンテンツを提供されるシンク装置へのライブコンテンツの伝送が一時中止されるとき、ライブコンテンツをソース装置の保存部に保存するステップを含み、また、ライブコンテンツの伝送中止のタイムアウト以前に、シンク装置から保存されたライブコンテンツの再開要請を受信した場合に、保存部に保存されたライブコンテンツを伝送し、新たに受信されるライブコンテンツを、保存部を経てシンク装置へ伝送するステップをさらに含むライブコンテンツ管理方法である。【選択図】  図２
2006042353.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを通じてライブコンテンツを管理する方法において、
前記ライブコンテンツを提供するソース装置から、前記ライブコンテンツを提供されるシンク装置への前記ライブコンテンツの伝送が一時中止されるとき、前記ライブコンテンツを前記ソース装置の保存部に保存するステップを含むことを特徴とするライブコンテンツ管理方法。
【請求項２】
前記ライブコンテンツの伝送中止のタイムアウト以前に、前記シンク装置から前記保存されたライブコンテンツの再開要請を受信した場合に、前記保存部に保存されたライブコンテンツを伝送し、新たに受信されるライブコンテンツを、前記保存部を経て前記シンク装置へ伝送するステップをさらに含むことを特徴とする請求項１に記載のライブコンテンツ管理方法。
【請求項３】
前記ライブコンテンツの保存により、前記ライブコンテンツの変更された状態情報を前記シンク装置へ伝送するステップをさらに含むことを特徴とする請求項１に記載のライブコンテンツ管理方法。
【請求項４】
前記ライブコンテンツの伝送中止のタイムアウト以後に、前記シンク装置から前記ライブコンテンツの伝送要請を受信した場合に、新たに受信されるライブコンテンツを直接前記シンク装置へ伝送するステップをさらに含むことを特徴とする請求項１に記載のライブコンテンツ管理方法。
【請求項５】
前記シンク装置からのライブコンテンツの伝送要請は、ＨＴＴＰ ＧＥＴ命令により伝送されることを特徴とする請求項４に記載のライブコンテンツ管理方法。
【請求項６】
前記ライブコンテンツの伝送中止のタイムアウト以後に、前記シンク装置から前記保存部に保存されたライブコンテンツの伝送要請を受信した場合に、前記保存部に保存されたライブコンテンツを伝送し、新たに受信されるライブコンテンツを、前記保存部を通じて前記シンク装置へ伝送するステップをさらに含むことを特徴とする請求項１に記載のライブコンテンツ管理方法。
【請求項７】
前記シンク装置からのライブコンテンツの伝送要請は、再生範囲が指定されたＨＴＴＰ ＧＥＴ命令により伝送されることを特徴とする請求項６に記載のライブコンテンツ管理方法。
【請求項８】
前記指定された再生範囲が前記保存部に保存されたライブコンテンツの範囲を外れる場合、エラーメッセージを前記シンク装置へ伝送するか、または新たに受信されるライブコンテンツを前記シンク装置へ伝送するステップをさらに含むことを特徴とする請求項７に記載のライブコンテンツ管理方法。
【請求項９】
前記ライブコンテンツの伝送中止のタイムアウト以後に、前記シンク装置から前記保存されたライブコンテンツの伝送要請を受信した場合に、前記保存されたライブコンテンツを、トリックプレイを通じて前記シンク装置へ伝送するステップをさらに含むことを特徴とする請求項１に記載のライブコンテンツ管理方法。
【請求項１０】
前記トリックプレイを通じた伝送ステップは、前記シンク装置から再生範囲が指定されたＨＴＴＰ ＧＥＴ命令を少なくとも１回以上受信することに応答して、前記指定された再生範囲に対応する前記ライブコンテンツを１回以上伝送するステップを含むことを特徴とする請求項９に記載のライブコンテンツ管理方法。
【請求項１１】
前記トリックプレイを通じた伝送ステップは、前記シンク装置からトリックプレイが指定されたＨＴＴＰ ＧＥＴ命令を受信し、それに応答して前記トリックプレイ情報に対応するように、前記ライブコンテンツを伝送するステップを含むことを特徴とする請求項９に記載のライブコンテンツ管理方法。
【請求項１２】
ネットワークを通じてライブコンテンツを管理する方法において、
前記ライブコンテンツを提供するソース装置から前記ライブコンテンツの伝送を一時中止し、前記ライブコンテンツを前記ソース装置で保存可能にするために、前記ソース装置へ前記ライブコンテンツの伝送を一時中止するように要請するステップを含むことを特徴とするライブコンテンツ管理方法。
【請求項１３】
前記ライブコンテンツの伝送中止のタイムアウト以前に、前記ソース装置に保存されたライブコンテンツの再開要請を伝送するステップと、
前記要請に応答して、前記ソース装置に保存されたライブコンテンツを受信するステップとを含むことを特徴とする請求項１２に記載のライブコンテンツ管理方法。
【請求項１４】
前記ソース装置から前記ライブコンテンツの保存により、前記ライブコンテンツの変更された状態情報を受信するステップをさらに含むことを特徴とする請求項１２に記載のライブコンテンツ管理方法。
【請求項１５】
前記ライブコンテンツの伝送中止のタイムアウト以後に、前記ソース装置へ前記ライブコンテンツの伝送を要請し、それに応答して、前記ソース装置で新たに受信されるライブコンテンツを直接受信するステップをさらに含むことを特徴とする請求項１２に記載のライブコンテンツ管理方法。
【請求項１６】
前記ライブコンテンツの伝送要請は、ＨＴＴＰ ＧＥＴ命令により伝送されることを特徴とする請求項１５に記載のライブコンテンツ管理方法。
【請求項１７】
前記ライブコンテンツの伝送中止のタイムアウト以後に、前記ソース装置へ前記ソース装置に保存されたライブコンテンツの伝送を要請し、それに応答して、前記ソース装置に保存されたライブコンテンツ及び前記ソース装置で新たに受信されるライブコンテンツを受信するステップをさらに含むことを特徴とする請求項１２に記載のライブコンテンツ管理方法。
【請求項１８】
前記保存されたライブコンテンツの伝送要請は、再生範囲が指定されたＨＴＴＰ ＧＥＴ命令により伝送されることを特徴とする請求項１７に記載のライブコンテンツ管理方法。
【請求項１９】
前記指定された再生範囲が前記ソース装置に保存されたライブコンテンツの範囲を外れる場合、前記ソース装置からエラーメッセージを受信するか、または前記ソース装置で新たに受信されるライブコンテンツを前記ソース装置から提供されるステップをさらに含むことを特徴とする請求項１８に記載のライブコンテンツ管理方法。
【請求項２０】
前記ライブコンテンツの伝送中止のタイムアウト以後に、前記ソース装置へ前記保存されたライブコンテンツの伝送を要請し、それに応答して、前記ソース装置に保存されたライブコンテンツを、トリックプレイを通じて前記ソース装置から受信するステップをさらに含むことを特徴とする請求項１２に記載のライブコンテンツ管理方法。
【請求項２１】
前記トリックプレイを通じた受信ステップは、前記ソース装置へ再生範囲が指定されたＨＴＴＰ ＧＥＴ命令を少なくとも１回以上伝送したことに応答して、前記指定された再生範囲に対応する前記ライブコンテンツを１回以上前記ソース装置から受信するステップを含むことを特徴とする請求項２０に記載のライブコンテンツ管理方法。
【請求項２２】
前記トリックプレイを通じた受信ステップは、前記ソース装置へトリックプレイが指定されたＨＴＴＰ ＧＥＴ命令を伝送し、それに応答して、前記トリックプレイ情報に対応する前記ライブコンテンツを受信するステップを含むことを特徴とする請求項２０に記載のライブコンテンツ管理方法。
【請求項２３】
ネットワークを通じてライブコンテンツを管理するソース装置において、
前記ライブコンテンツを提供する前記ソース装置から、前記ライブコンテンツを提供されるシンク装置への前記ライブコンテンツの伝送が一時中止されるとき、ネットワークを通じて受信されるライブコンテンツを保存部に保存するように制御する制御部を備えることを特徴とするソース装置。
【請求項２４】
前記制御部は、前記ライブコンテンツの伝送中止のタイムアウト以前に、前記シンク装置から前記保存されたライブコンテンツの再開要請を受信した場合に、前記保存部に保存されたライブコンテンツを伝送し、新たに受信されるライブコンテンツを、前記保存部を経て前記シンク装置へ伝送するようにさらに制御することを特徴とする請求項２３に記載のソース装置。
【請求項２５】
前記制御部は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記シンク装置から前記ライブコンテンツの伝送要請を受信した場合に、新たに受信されるライブコンテンツを直接前記シンク装置へ伝送するようにさらに制御することを特徴とする請求項２３に記載のソース装置。
【請求項２６】
前記制御部は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記シンク装置から前記保存部に保存されたライブコンテンツの伝送要請を受信した場合に、前記保存部に保存されたライブコンテンツを伝送し、新たに受信されるライブコンテンツを、前記保存部を通じて前記シンク装置へ伝送するようにさらに制御することを特徴とする請求項２３に記載のソース装置。
【請求項２７】
前記制御部は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記シンク装置から再生範囲が指定されたＨＴＴＰ ＧＥＴ命令を少なくとも１回以上受信することに応答して、前記指定された再生範囲に対応する前記ライブコンテンツを１回以上伝送するようにさらに制御することを特徴とする請求項２３に記載のソース装置。
【請求項２８】
前記制御部は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記シンク装置からトリックプレイが指定されたＨＴＴＰ ＧＥＴ命令を受信し、それに応答して前記トリックプレイ情報に対応するように、前記ライブコンテンツを伝送するようにさらに制御することを特徴とする請求項２３に記載のソース装置。
【請求項２９】
ネットワークを通じてライブコンテンツを管理するシンク装置において、
前記ライブコンテンツを提供するソース装置から前記ライブコンテンツの伝送を一時中止し、前記ライブコンテンツを前記ソース装置で保存可能にするために、前記ソース装置へ前記ライブコンテンツの伝送を一時中止するように要請する制御部を備えることを特徴とするシンク装置。
【請求項３０】
前記制御部は、前記ライブコンテンツの伝送中止のタイムアウト以前に、前記ソース装置へ保存されたライブコンテンツの再開要請を伝送し、前記要請に応答して、前記ソース装置に保存されたライブコンテンツを受信するようにさらに制御することを特徴とする請求項２９に記載のシンク装置。
【請求項３１】
前記制御部は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記ソース装置へ前記ライブコンテンツの伝送を要請し、それに応答して、前記ソース装置で新たに受信されるライブコンテンツを直接受信するようにさらに制御することを特徴とする請求項２９に記載のシンク装置。
【請求項３２】
前記制御部は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記ソース装置へ前記ソース装置に保存されたライブコンテンツの伝送を要請し、それに応答して、前記ソース装置に保存されたライブコンテンツ及び前記ソース装置で新たに受信されるライブコンテンツを受信するようにさらに制御することを特徴とする請求項２９に記載のシンク装置。
【請求項３３】
前記制御部は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記ソース装置へ再生範囲が指定されたＨＴＴＰ ＧＥＴ命令を少なくとも１回以上伝送したことに応答して、前記指定された再生範囲に対応する前記ライブコンテンツを１回以上前記ソース装置から受信するようにさらに制御することを特徴とする請求項２９に記載のシンク装置。
【請求項３４】
前記制御部は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記ソース装置へトリックプレイが指定されたＨＴＴＰ ＧＥＴ命令を伝送し、それに応答して、前記トリックプレイ情報に対応する前記ライブコンテンツを受信するようにさらに制御することを特徴とする請求項２９に記載のシンク装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを通じるライブコンテンツ管理に係り、特に、ライブコンテンツ管理方法、ソース装置及びシンク装置に関する。
【背景技術】
【０００２】
デジタル時代の拡散及び発展により、周辺でさらに多くのデジタル製品が提供されている。例えば、ＤＶＤプレーヤ、ケーブルＳＴＢ（Ｓｅｔ Ｔｏｐ Ｂｏｘｅｓ）、ＤＶＣＲ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｃａｓｓｅｔｔｅ Ｒｅｃｏｒｄｅｒ）、ＤＴＶ（Ｄｉｇｉｔａｌ ＴＶ）、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）の多くのデジタル製品が一つのネットワークに連結されている。このような多様な機器は、ネットワークで連結され、それを制御するためのホームネットワーク標準がＤＨＷＧ（Ｄｉｇｉｔａｌ Ｈｏｍｅ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ）により定立されている。
【０００３】
最近、ホームネットワーク内のマルチメディア環境は、３つのワールド、すなわちＰＣインターネットワールド、モバイルワールド、ＣＥ（Ｃｏｎｓｕｍｅｒ Ｅｌｅｃｔｒｏｎｉｃｓ）ブロードキャストワールドに大別できる。
【０００４】
図１は、従来技術によって、ＤＨＷＧによるホームネットワーク環境を説明するための参考図である。
【０００５】
ＰＣインターネットワールド１００は、ＰＣとＰＣ周辺通信装置とを備える。具体的には、ＰＣ １０１、ゲームコンソール１０２、プリンタ１０３、デジタルイメージング装置１０４、デジタルミュージック装置１０５、及び無線モニタ１０６などを備える。
【０００６】
モバイルワールド１１０は、ラップトップコンピュータ１１１、マルチメディアモバイルフォーン１１２、及びＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）１１３などを備え、このようなモバイル装置は、ホームネットワークの内部だけでなく外部の環境でも、ユーザーに移動の自由を提供する。
【０００７】
ＣＥブロードキャストワールド１２０は、ＴＶモニタ１２１、ＰＶＲ（Ｐｅｒｓｏｎａｌ Ｖｉｄｅｏ Ｒｅｃｏｒｄｅｒ）、チューナ、ＳＴＢなどの伝統的なＣＥ １２２、及びステレオセット１２３などを備える。
【０００８】
消費者は、このような３つのドメインにあるデバイスを、家庭内で共に連動して動作させることを所望する。このようなデジタルワールド間の相互互換性を実現するためのホームネットワーク研究が要求される。
【０００９】
デジタルホームは、ＣＥ、モバイル、ＰＣデバイスのネットワークから構成され、このようなネットワークは、トランスペアレントであり、かつ簡単であることで、継ぎ目のない相互互換性のために協力せねばならない。そして、このようなネットワークは、ＩＰネットワーキング及びＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ）技術に基づく。
【００１０】
ＵＰｎＰオーディオ／ビデオ技術によるメディア管理及び制御は、デバイスとアプリケーションとがホームネットワーク上でメディアコンテンツを識別し、管理し、配布することを可能にし、また、それをモバイルデバイスへ伝送することを可能にする。
【００１１】
ＵＰｎＰは、インテリジェントアプリケーション、無線デバイス及びＰＣなどのピアツーピアのネットワーク連結性のためのアーキテクチャーである。それは、家庭や、小規模ビジネスなどの規模が小さいネットワークに使用し易く、融通性があり、標準に基盤した連結性を提供するように設計される。ＵＰｎＰ ＡＶアーキテクチャーは、ＵＰｎＰコントロールポイントとＵＰｎＰデバイスとの間の一般的なインタラクションを定義する。ＵＰｎＰアーキテクチャーは、いかなる形態のコンテンツ及びいかなる種類の伝送プロトコルも、デバイスが支援可能にする。ＵＰｎＰデバイスは、ＴＶ、ＶＣＲ、ＣＤ／ＤＶＤプレーヤ、ＳＴＢ、ステレオシステム、ＭＰ３プレーヤ、スチールイメージカメラ、カムコーダ、ＰＣなどを含む。そして、ＡＶアーキテクチャーは、デバイスがＭＰＥＧ（Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）２、ＭＰＥＧ４、ＪＰＥＧ（Ｊｏｉｎｔ Ｐｈｏｔｏｇｒａｐｈｉｃ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）、ＭＰ３、ＢＭＰ（ｂｉｔｍａｐ）、ＷＭＡ（Ｗｉｎｄｏｗ Ｍｅｄｉａ Ａｒｃｈｉｔｅｃｔｕｒｅ）など相異なる種類のフォーマットを有したコンテンツ、及びＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ）−１３９４、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）ＧＥＴ、ＲＴＰ（Ｌｉｖｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）、ＨＴＴＰ ＰＵＴ／ＰＯＳＴ、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）／ＩＰのような多様な種類の伝送プロトコルを支援可能にする。
【００１２】
ほとんどのＵＰｎＰ ＡＶのシナリオは、ムービー、音楽、ピクチャのようなコンテンツが一つのデバイスから他のデバイスへ伝送されることを含む。ＡＶコントロールポイントは、ソースとシンクとして役割を行う二つ以上のＵＰｎＰデバイスと相互作用する。
【００１３】
メディアサーバは、ユーザーがレンダリングしようとするコンテンツを有している。メディアサーバは、複数のコンテンツを有しているか、またはアクセスできる。メディアサーバは、そのコンテンツをアクセスして、それを所定の伝送プロトコルを利用して、ネットワークを通じて他のデバイスへ伝送する。メディアサーバの例としては、ＶＣＲ、ＣＤ／ＤＶＤプレーヤ、カメラ、カムコーダ、ＰＣ、ＳＴＢ、衛星受信器、オーディオテーププレーヤなどを含む。
【００１４】
メディアサーバコントロールポイントは、再生などのユーザーが所望の作業を行うために、ユーザーにより指定された通りメディアサーバの動作を調整して管理する。また、メディアサーバコントロールポイントは、ユーザーがデバイスの動作を制御するために、インタラクト可能なユーザーインターフェースを提供する。コントロールポイントの例としては、一般的なリモコンを有したＴＶや無線ＰＤＡデバイスを挙げることができる。また、ユーザーにより要求される場合、コントロールポイントは、Ｓｔｏｐ、Ｐａｕｓｅ、ＦＦ、ＲＥＷ、Ｓｋｉｐのような多様なＡＶ伝送アクションを起動することによって、コンテンツの流れを制御できる。
【００１５】
図１に示したようなホームネットワーク環境で、ネットワークを通じてライブコンテンツが伝送されている途中で一時中止された場合に、そのライブコンテンツを効果的に管理できる方法が要求される。
【特許文献１】米国特許第６，１８２，０９４号明細書
【発明の開示】
【発明が解決しようとする課題】
【００１６】
本発明の目的は、ネットワークを通じて、Ａ／Ｖコンテンツを管理可能にするライブコンテンツ管理方法、ソース装置及びシンク装置を提供するところにある。
【課題を解決するための手段】
【００１７】
前記の課題を解決するための本発明の一つの特徴は、ネットワークを通じてライブコンテンツを管理する方法において、前記ライブコンテンツを提供するソース装置から、前記ライブコンテンツを提供されるシンク装置への前記ライブコンテンツの伝送が一時中止されるとき、前記ライブコンテンツを前記ソース装置の保存部に保存するステップを含むことである。
【００１８】
前記管理方法は、前記ライブコンテンツの伝送中止のタイムアウト以前に、前記シンク装置から前記保存されたライブコンテンツのｒｅｓｕｍｅ（再開）要請を受信した場合に、前記保存部に保存されたライブコンテンツを伝送し、新たに受信されるライブコンテンツを、前記保存部を経て前記シンク装置へ伝送するステップをさらに含むことが望ましい。
【００１９】
また、前記管理方法は、前記ライブコンテンツの保存により、前記ライブコンテンツの変更された状態情報を前記シンク装置へ伝送するステップをさらに含むことが望ましい。
【００２０】
また、前記管理方法は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記シンク装置から前記ライブコンテンツの伝送要請を受信した場合に、新たに受信されるライブコンテンツを直接前記シンク装置へ伝送するステップをさらに含むことが望ましい。
【００２１】
前記シンク装置からのライブコンテンツの伝送要請は、ＨＴＴＰ ＧＥＴ命令により伝送されることが望ましい。
【００２２】
また、前記管理方法は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記シンク装置から前記保存部に保存されたライブコンテンツの伝送要請を受信した場合に、前記保存部に保存されたライブコンテンツを伝送し、新たに受信されるライブコンテンツを、前記保存部を通じて前記シンク装置へ伝送するステップをさらに含むことが望ましい。
【００２３】
前記シンク装置からのライブコンテンツの伝送要請は、再生範囲が指定されたＨＴＴＰ ＧＥＴ命令により伝送されることが望ましい。
【００２４】
また、前記管理方法は、前記指定された再生範囲が前記保存部に保存されたライブコンテンツの範囲を外れる場合、エラーメッセージを前記シンク装置へ伝送するか、または新たに受信されるライブコンテンツを前記シンク装置へ伝送するステップをさらに含むことが望ましい。
【００２５】
また、前記管理方法は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記シンク装置から前記保存されたライブコンテンツの伝送要請を受信した場合に、前記保存されたライブコンテンツを、トリックプレイを通じて前記シンク装置へ伝送するステップをさらに含むことが望ましい。
【００２６】
前記トリックプレイを通じた伝送ステップは、前記シンク装置から再生範囲が指定されたＨＴＴＰ ＧＥＴ命令を少なくとも１回以上受信することに応答して、前記指定された再生範囲に対応する前記ライブコンテンツを１回以上伝送するステップを含むか、または前記シンク装置からトリックプレイが指定されたＨＴＴＰ ＧＥＴ命令を受信し、それに応答して前記トリックプレイ情報に対応するように、前記ライブコンテンツを伝送するステップを含むことが望ましい。
【００２７】
本発明の他の特徴は、ネットワークを通じてライブコンテンツを管理する方法において、前記ライブコンテンツを提供するソース装置から前記ライブコンテンツの伝送を一時中止し、前記ライブコンテンツを前記ソース装置で保存可能にするために、前記ソース装置へ前記ライブコンテンツの伝送を一時中止するように要請するステップを含むことである。
【００２８】
前記管理方法は、前記ライブコンテンツの伝送中止のタイムアウト以前に、前記ソース装置に保存されたライブコンテンツのｒｅｓｕｍｅ要請を伝送するステップと、前記要請に応答して、前記ソース装置に保存されたライブコンテンツを受信するステップと、を含むことが望ましい。
【００２９】
また、前記管理方法は、前記ソース装置から前記ライブコンテンツの保存により、前記ライブコンテンツの変更された状態情報を受信するステップをさらに含むことが望ましい。
【００３０】
また、前記管理方法は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記ソース装置へ前記ライブコンテンツの伝送を要請し、それに応答して、前記ソース装置で新たに受信されるライブコンテンツを直接受信するステップをさらに含むことが望ましい。
【００３１】
前記ライブコンテンツの伝送要請は、ＨＴＴＰ ＧＥＴ命令により伝送されることが望ましい。
【００３２】
また、前記管理方法は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記ソース装置へ前記ソース装置に保存されたライブコンテンツの伝送を要請し、それに応答して、前記ソース装置に保存されたライブコンテンツ及び前記ソース装置で新たに受信されるライブコンテンツを受信するステップをさらに含むことが望ましい。
【００３３】
前記保存されたライブコンテンツの伝送要請は、再生範囲が指定されたＨＴＴＰ ＧＥＴ命令により伝送されることが望ましい。
【００３４】
また、前記管理方法は、前記指定された再生範囲が前記ソース装置に保存されたライブコンテンツの範囲を外れる場合、前記ソース装置からエラーメッセージを受信するか、または前記ソース装置で新たに受信されるライブコンテンツを前記ソース装置から提供されるステップをさらに含むことが望ましい。
【００３５】
また、前記管理方法は、前記ライブコンテンツの伝送中止のタイムアウト以後に、前記ソース装置へ前記保存されたライブコンテンツの伝送を要請し、それに応答して、前記ソース装置に保存されたライブコンテンツを、トリックプレイを通じて前記ソース装置から受信するステップをさらに含むことが望ましい。
【００３６】
前記トリックプレイを通じた受信ステップは、前記ソース装置へ再生範囲が指定されたＨＴＴＰ ＧＥＴ命令を少なくとも１回以上伝送したことに応答して、前記指定された再生範囲に対応する前記ライブコンテンツを１回以上前記ソース装置から受信するステップを含むか、または前記ソース装置へトリックプレイが指定されたＨＴＴＰ ＧＥＴ命令を伝送し、それに応答して、前記トリックプレイ情報に対応する前記ライブコンテンツを受信するステップを含むことが望ましい。
【００３７】
本発明のさらに他の特徴は、ネットワークを通じてライブコンテンツを管理するソース装置において、前記ライブコンテンツを提供する前記ソース装置から、前記ライブコンテンツを提供されるシンク装置への前記ライブコンテンツの伝送が一時中止されるとき、ネットワークを通じて受信されるライブコンテンツを保存部に保存するように制御する制御部を備えることである。
【００３８】
本発明のさらに他の特徴は、ネットワークを通じてライブコンテンツを管理するシンク装置において、前記ライブコンテンツを提供するソース装置から前記ライブコンテンツの伝送を一時中止し、前記ライブコンテンツを前記ソース装置で保存可能にするために、前記ソース装置へ前記ライブコンテンツの伝送を一時中止するように要請する制御部を備えることである。
【発明の効果】
【００３９】
本発明の構成によれば、ホームネットワーク環境で、ネットワークを通じてライブコンテンツが伝送されている途中で一時中止された場合に、そのライブコンテンツを効果的に管理できる方法を提案して、ネットワークを通じた多様なデータ転送のシナリオを提供できる。
【発明を実施するための最良の形態】
【００４０】
以下では、添付された図面を参照して本発明を詳細に説明する。
【００４１】
図２は、本発明によって、ネットワークを通じてライブコンテンツを管理するシステム構成図である。
【００４２】
図２に示すように、システムは、ソース装置３００及びシンク装置４００を備える。ソース装置３００は、シンク装置４００からのライブコンテンツ要請を受信して、ライブコンテンツを要請した装置へコンテンツを伝送し、シンク装置は、ソース装置からライブコンテンツに関する情報を持ってきて、またライブコンテンツを要請して、ソース装置からライブコンテンツを受信して消費する。
【００４３】
ソース装置３００は、チューナ３１０、ストリーミングサーバ＋メディアサーバ３２０、保存部３３０、及びバイトカウンタ３４０を備える。
【００４４】
チューナ３１０は、ネットワークを通じて放送されるライブコンテンツを受信して、ストリーミングサーバ＋メディアサーバ３２０に提供する。
【００４５】
ストリーミングサーバは、コンテンツをシンク装置に提供する役割を行い、メディアサーバは、シンク装置にコンテンツについての情報を提供する役割を行う。
【００４６】
特に、本発明によるストリーミングサーバは、チューナ３１０を通じて受信されたライブコンテンツをシンク装置に提供するか、または保存部３３０に保存されたコンテンツを読み込んでシンク装置に提供する。
【００４７】
保存部３３０は、ライブコンテンツを、ネットワークを通じてシンク装置へ伝送できない場合、このライブコンテンツを保存する。
【００４８】
バイトカウンタ３４０は、シンク装置へ現在まで伝送されたライブコンテンツの数またはコンテンツの時間情報を計算する。
【００４９】
シンク装置４００は、ストリーミングクライアント＋メディアサーバコントロールポイント４１０、再生部４２０、及びバイトカウンタ４３０を備える。シンク装置４００は、Ａ／Ｖコンテンツを消費する役割を行う。例えば、ユーザーから“ｐｌａｙ”という命令を受ければ、シンク装置は、例えばＨＴＴＰプロトコルを利用して該当データを読み込む。
【００５０】
ストリーミングクライアント＋メディアサーバコントロールポイント４１０内のメディアサーバコントロールポイントは、ソース装置３００からコンテンツの情報を取得し、ユーザーから命令による動作を行う。
【００５１】
ストリーミングクライアント＋メディアサーバコントロールポイント４１０内のストリーミングクライアントは、ソース装置３００に制御命令を伝達し、該当コンテンツを受信する役割を行う。
【００５２】
バイトカウンタ４３０は、現在まで受信したデータの数または該当データの時間情報を計算する。
【００５３】
再生部４２０は、ストリーミングクライアントからコンテンツを受信して、それを再生する。
【００５４】
図３は、図２に示したソース装置３００の概略的な構成図である。
【００５５】
ソース装置３００の他の構成は、図２に示したと同一であり、ストリーミングサーバ＋メディアサーバ３２０の細部的な構成が示されている。
【００５６】
ストリーミングサーバ＋メディアサーバ３２０は、ストリーミングサーバ３２１及びメディアサーバ３２４から構成される。
【００５７】
メディアサーバ３２４は、制御命令管理部３２５、コンテンツ管理部３２６、及びコンテンツ状態情報３２７を備える。
【００５８】
制御命令管理部３２５は、制御命令を生成してシンク装置へ伝送し、シンク装置から受信された制御命令を解釈して適切な処理を行う。本発明によって、制御命令管理部３２５は、シンク装置からｂｒｏｗｓｅ／ｓｅａｒｃｈ命令などを受信した場合に、それを解釈し、コンテンツ管理部３２６により自身が管理しているコンテンツについての状態情報をシンク装置へ伝送するように制御する。
【００５９】
コンテンツ管理部３２６は、コンテンツについての状態情報３２７を管理する。すなわち、シンク装置のメディアサーバコントロールポイントからコンテンツについての情報を要請する命令を受信すれば、コンテンツについての情報を検索して、検索されたコンテンツに関する情報をシンク装置へ伝送する。特に、本発明によって、コンテンツ管理部３２６は、チューナ３１０を通じて受信されるライブコンテンツが保存部に保存される場合に、このコンテンツがシーク可能であるか、またはトリックプレイが可能であるか等についての状態情報を変更し、このようにコンテンツについての状態情報が変更されたことを、例えばイベント形式でシンク装置に知らせる。このような制御命令管理部３２５及びコンテンツ管理部３２６は、制御部（図示せず）の制御によりその機能を行う。
【００６０】
ストリーミングサーバ３２１は、制御命令管理部３２２及びコンテンツ伝送部３２３を備える。
【００６１】
制御命令管理部３２２は、シンク装置から受信されたコンテンツに関する制御命令を受信して解釈し、その解釈結果によって、コンテンツ伝送部３２３を適切に制御する。コンテンツについての制御命令としては、ｐｌａｙ、ｐａｕｓｅ、ｒｅｓｕｍｅ、ＦＦ、ＲＷなどの命令を含む。
【００６２】
コンテンツ伝送部３２３は、シンク装置から要請されたライブコンテンツをチューナ３１０から直接受信してシンク装置へ伝送するか、またはコンテンツ保存部３００に保存されたコンテンツを読み込んでシンク装置へ伝送する。コンテンツ保存部３００に保存されたコンテンツを読み込んでシンク装置へ伝送する場合には、バイトカウンタ３４０から提供されたコンテンツの数または時間情報を参照して、保存部３３０から指定されたコンテンツの範囲を探す。
【００６３】
バイトカウンタ３４０は、シンク装置へ現在まで伝送されたライブコンテンツの数またはコンテンツの時間情報を計算して、コンテンツ伝送部３２３に提供する。
【００６４】
このような制御命令管理部３２２、コンテンツ伝送部３２３及びバイトカウンタ３４０は、制御部（図示せず）の制御によりその機能を行う。
【００６５】
図４は、図２に示したシンク装置の概略的な構成図である。
【００６６】
シンク装置４００の他の構成は、図２に示したものと同一であり、ストリーミングクライアント＋メディアサーバコントロールポイント４１０の細部的な構成が示されている。
【００６７】
メディアサーバコントロールポイント４１４は、制御命令管理部４１５及びユーザーインターフェース４１６を備える。
【００６８】
ユーザーインターフェース４１６は、ユーザーからＡ／Ｖコンテンツについての制御動作命令、例えば“ｐｌａｙ”などの動作命令を受信して制御命令管理部４１５に伝達する。
【００６９】
制御命令管理部４１５は、ＢｒｏｗｓｅまたはＳｅａｒｃｈ命令を利用してソース装置にコンテンツについての情報を要請し、ソース装置からコンテンツについての情報を受信すれば、受信されたコンテンツについての情報を解釈する。また、特定のコンテンツについての情報を得るために、コンテンツ情報を要請し、それを受信して解釈し、これによって解釈された情報またはユーザーインターフェースを通じて受信したユーザー命令に関する情報をストリーミングクライアント４１１に伝達する。特に、本発明によって、制御命令管理部４１５は、ソース装置からコンテンツの状態情報が変更されたことを知らせるイベントなどを受信した場合に、その具体的な変更された状態情報を得るために、それをソース装置に要請して受信する。制御命令管理部４１５及びユーザーインターフェース４１６は、制御部（図示せず）の制御によりその機能を行う。
【００７０】
ストリーミングクライアント４１１は、制御命令管理部４１３及びコンテンツ受信部４１２を備える。
【００７１】
制御命令管理部４１３は、メディアサーバコントロールポイント４１４から受信したユーザー命令に関する情報、またはコンテンツ解釈情報を参照してコンテンツについての制御命令を生成し、それを伝送する。特に、本発明によって、制御命令管理部４１３は、所定のコンテンツを持ってくるために、ＨＴＴＰ Ｇｅｔ命令や、ｐａｕｓｅ、ｒｅｓｕｍｅ命令などをソース装置へ伝送し、またトリックプレイなどのために、範囲が指定されたＨＴＴＰ Ｇｅｔ命令やｐｌａｙｓｐｅｅｄが指定されたＨＴＴＰ Ｇｅｔ命令などを伝送する。
【００７２】
コンテンツ受信部４１２は、ソース装置からＡ／Ｖコンテンツを受信して、それを再生部４２０へ伝送する。制御命令管理部４１３、コンテンツ受信部４１２及びバイトカウンタは、制御部（図示せず）の制御によりその機能を行う。
【００７３】
図５は、本発明の第１実施形態によって、シンク装置からソース装置にライブコンテンツについてのｐａｕｓｅ命令を受信する場合、ｐａｕｓｅ命令のタイムアウトが発生しない状況で、ライブコンテンツについてのｒｅｓｕｍｅ動作を行う過程のフローチャートである。
【００７４】
シンク装置は、ソース装置からコンテンツについての情報を得るために、ｂｒｏｗｓｅ／ｓｅａｒｃｈのような命令をソース装置へ送信する（５０１）。
【００７５】
この命令を受けたソース装置は、自身が持っているコンテンツについての情報をシンク装置に伝達する（５０２）。
【００７６】
シンク装置では、ライブコンテンツを見るために、所望のコンテンツについての該当ＵＲＬ１を有したＨＴＴＰ Ｇｅｔ命令を送信し（５０３）、ソース装置は、そのＵＲＬ１に該当するコンテンツをシンク装置へ伝送する（５０４）。この場合、ライブコンテンツは、実際のチューナから直接入るライブデータである。
【００７７】
ＨＴＴＰ Ｇｅｔ ＵＲＬ１命令の一例が図１０に示されている。図１０に示すように、ＨＴＴＰ Ｇｅｔ命令は、“ＵＲＬ１”で識別される情報を照会せよという要請を含んでおり、“ＨＯＳＴ”は、志願が要請されたインターネットホストを識別する情報をいう。ＨＯＳＴフィールドには、“ｈｏｓｔ ｏｆ ｃｏｎｔｒｏｌ ＵＲＬ１”及び“ｐｏｒｔ ｏｆ ｃｏｎｔｒｏｌ ＵＲＬ１”が入る。そして、Ａｃｔｉｏｎには、ｐｌａｙが指定されている。
【００７８】
もし、シンク装置がライブコンテンツを一時中止するために、ｐａｕｓｅ命令をソース装置へ伝送すれば（５０５）、ソース装置は、ライブコンテンツを自身の保存部に保存する。ｐａｕｓｅ命令は、コンテンツの伝送を一時中止せよという命令であって、このようなｐａｕｓｅ命令の一例が図１１に示されている。もちろん、他のプロトコルによる制御命令を使用することもあるが、図１１には、ＨＴＴＰ Ｐｏｓｔ命令の例を示した。
【００７９】
そして、ソース装置は、ライブコンテンツについての状態情報を、例えばシークが可能である、またはトリックプレイが可能である状態に変更し、該当コンテンツにこのような状態変更があることを、イベントなどを通じてシンク装置に知らせる（５０６）。
【００８０】
これにより、シンク装置は、このような状態変更があることが分かり、ｂｒｏｗｓｅ／ｓｅａｒｃｈ命令をソース装置へ送信し（５０７）、ソース装置からこのコンテンツについての変更された状態情報を得て、コンテンツについての状態情報を更新する（５０８）。
【００８１】
しかし、ｐａｕｓｅタイムアウト以前に、シンク装置が同一なコンテンツについてｒｅｓｕｍｅ命令をソース装置へ伝送すれば（５０９）、ソース装置は、現在のチューナから受信されるデータは保存部に保存し、以前に保存部に保存されたデータ、すなわちタイムシフトされたデータをシンク装置に伝達する（５１０）。ｒｅｓｕｍｅ命令は、一時中止されたコンテンツの伝送を再び始めさせる命令であって、このようなｒｅｓｕｍｅ命令の一例が図１２に示されている。もちろん、他のプロトコルによる制御命令を使用することもできる。ここで、ｐａｕｓｅタイムアウトは、ソース装置またはシンク装置で内部的または外部的要因により発生し、各装置で任意的に発生させることもできる。
【００８２】
図６は、本発明の第２実施形態によって、シンク装置からソース装置にライブコンテンツについてのｐａｕｓｅ命令を受信する場合、ｐａｕｓｅ命令のタイムアウトが発生した状況で、ライブコンテンツを再び伝送する動作を行う過程のフローチャートである。
【００８３】
シンク装置は、ソース装置にｂｒｏｗｓｅ／ｓｅａｒｃｈのような命令を送信し（６０１）、コンテンツについての情報を伝達され（６０２）、シンク装置でライブコンテンツを見るために、所望のコンテンツについての該当ＵＲＬ１を有したＨＴＴＰ Ｇｅｔ命令を送信し（６０３）、そのＵＲＬ１に該当するコンテンツをソース装置から受信し（６０４）、ｐａｕｓｅ命令（６０５）によりライブコンテンツの伝送が中止し、ソース装置がコンテンツについての状態変更があることをシンク装置に知らせ（６０６）、ｂｒｏｗｓｅ／ｓｅａｒｃｈ命令（６０７）により、シンク装置がコンテンツについての状態情報を更新（６０８）する動作は、図５に示した動作と同一である。
【００８４】
このような状態で、シンク装置やソース装置で、ある原因によりｐａｕｓｅタイムアウトが発生した場合（６０９）、シンク装置が保存したデータではなく現在放送されているデータを見ようとする場合に、ＨＴＴＰ Ｇｅｔ ＵＲＬ１の命令をソース装置に送信する（６１０）。このようなＨＴＴＰ Ｇｅｔ ＵＲＬ１命令を受信したソース装置は、現在受信されるライブコンテンツを直接シンク装置へ伝送する（６１１）。
【００８５】
図７は、本発明の第３実施形態による、シンク装置からソース装置にライブコンテンツについてのｐａｕｓｅ命令を受信する場合、ｐａｕｓｅ命令のタイムアウトが発生した状況で、ｐａｕｓｅの間に保存されたコンテンツを伝送する動作を行う過程のフローチャートである。
【００８６】
シンク装置は、ソース装置にｂｒｏｗｓｅ／ｓｅａｒｃｈのような命令を送信し（７０１）、コンテンツについての情報を伝達され（７０２）、シンク装置でライブコンテンツを見るために、所望のコンテンツについての該当ＵＲＬ１を有したＨＴＴＰ Ｇｅｔ命令を送信し（７０３）、そのＵＲＬ１に該当するコンテンツをソース装置から受信し（７０４）、ｐａｕｓｅ命令（７０５）によりライブコンテンツの伝送が中止し、ソース装置がコンテンツについての状態変更があることをシンク装置に知らせ（７０６）、ｂｒｏｗｓｅ／ｓｅａｒｃｈ命令（７０７）により、シンク装置がコンテンツについての状態情報を更新（７０８）する動作は、図６に示した動作と同一である。
【００８７】
このような状態で、シンク装置やソース装置で、ある原因によりｐａｕｓｅタイムアウトが発生した場合（７０９）、シンク装置が現在放送されるデータを見たいものではなく、ｐａｕｓｅの間に保存されたデータを受信しようとする場合に、次のような動作が行われる。
【００８８】
すなわち、ｐａｕｓｅタイムアウト以後、シンク装置は、ＨＴＴＰ Ｇｅｔ ＵＲＬ１命令と共にｒａｎｇｅ位置または時間情報を送信する（７１０）。ｒａｎｇｅ位置や時間情報は、ソース装置に送信するデータの位置を指定する。この情報は、シンク装置のバイトカウンタから得ることができる。ｒａｎｇｅ位置が指定されたＨＴＴＰ Ｇｅｔ ＵＲＬ１命令の一例が図１３に示されている。
【００８９】
ソース装置は、シンク装置から受信したｒａｎｇｅ情報を参照して、該当位置からデータをシンク装置へ伝送する（７１１）。この位置は、保存されたデータについての範囲内にあり、もし、シンク装置のｒａｎｇｅ情報が正確でない場合には、エラーメッセージをシンク装置に送信できる。そして、該当範囲が保存された位置から終了時点が指定されていない場合には、保存されたデータをいずれも送信した後、該当するライブコンテンツを続けて送信することもある。ソース装置も、ｐａｕｓｅ時点まで送信したデータをソース装置のバイトカウンタから分かる。
【００９０】
図８は、本発明の第４実施形態による、シンク装置からソース装置にライブコンテンツについてのｐａｕｓｅ命令を受信する場合、ｐａｕｓｅ命令のタイムアウトが発生した状況で、シンク装置の要請によりコンテンツを複数回受信する動作を行う過程のフローチャートである。
【００９１】
シンク装置は、ソース装置にｂｒｏｗｓｅ／ｓｅａｒｃｈのような命令を送信し（８０１）、コンテンツについての情報を伝達され（８０２）、シンク装置でライブコンテンツを見るために、所望のコンテンツについての該当ＵＲＬ１を有したＨＴＴＰ Ｇｅｔ命令を送信し（８０３）、そのＵＲＬ１に該当するコンテンツをソース装置から受信し（８０４）、ｐａｕｓｅ命令（８０５）によりライブコンテンツの伝送が中止し、ソース装置がコンテンツについての状態変更があることをシンク装置に知らせ（８０６）、ｂｒｏｗｓｅ／ｓｅａｒｃｈ命令（８０７）により、シンク装置がコンテンツについての状態情報を更新（８０８）する動作は、図６に示した動作と同一である。
【００９２】
このような状態で、シンク装置やソース装置で、ある原因によりｐａｕｓｅタイムアウトが発生した場合（８０９）、シンク装置で複数回のデータを受信するために、複数回のＨＴＴＰ Ｇｅｔ ＵＲＬ１を相異なるｒａｎｇｅ情報を利用して送信する。
【００９３】
すなわち、シンク装置は、ｒａｎｇｅを指定してＨＴＴＰ Ｇｅｔ ＵＲＬ１をソース装置に送信し（８１０）、ソース装置からその指定された範囲に対応するコンテンツを受信する（８１１）。そして、再びシンク装置は、ｒａｎｇｅを指定してＨＴＴＰ Ｇｅｔ ＵＲＬ１をソース装置に送信し（８１２）、ソース装置からその指定された範囲に対応するコンテンツを受信する（８１３）。このような動作は、シンク装置でトリックプレイを行うために使われうる。もし、ｒａｎｇｅ情報が保存されたデータの終端に到達すれば、該当データをシンク装置へ伝送し、それ以上保存されたデータがなくてシークまたはトリックプレイが不能な状態に変更し、このように状態が変更されたことを、イベントを通じてシンク装置に知らせる（８１４）。このイベントを受けたシンク装置は、変更された状態情報を知るために、ソース装置にｂｒｏｗｓｅ／ｓｅａｒｃｈ命令を送信し（８１５）、それによるコンテンツ情報を、シンク装置はソース装置から受信する。次いで、シンク装置は、ＨＴＴＰ Ｇｅｔ ＵＲＬ１を実行して正常的な再生モードでコンテンツ伝送を要求でき（８１６）、ソース装置は、このような要求に応答して、ライブコンテンツを直接シンク装置へ伝送する（８１７）。
【００９４】
図９は、本発明の第５実施形態による、シンク装置からソース装置にライブコンテンツについてのｐａｕｓｅ命令を受信する場合、ｐａｕｓｅ命令のタイムアウトが発生した状況で、ソース装置の支援によりコンテンツを複数回伝送する動作を行う過程のフローチャートである。
【００９５】
シンク装置は、ソース装置にｂｒｏｗｓｅ／ｓｅａｒｃｈのような命令を送信し（９０１）、コンテンツについての情報を伝達され（９０２）、シンク装置でライブコンテンツを見るために、所望のコンテンツについての該当ＵＲＬ１を有したＨＴＴＰ Ｇｅｔ命令を送信し（９０３）、そのＵＲＬ１に該当するコンテンツをソース装置から受信し（９０４）、ｐａｕｓｅ命令（９０５）によりライブコンテンツの伝送が中止し、ソース装置がコンテンツについての状態変更があることをシンク装置に知らせ（９０６）、ｂｒｏｗｓｅ／ｓｅａｒｃｈ命令（９０７）により、シンク装置がコンテンツについての状態情報を更新（９０８）する動作は、図６に示した動作と同一である。
【００９６】
このような状態で、シンク装置やソース装置で、ある原因によりｐａｕｓｅタイムアウトが発生した場合（９０９）、図８に示した動作と異なり、ソース装置でトリックプレイを支援する。すなわち、タイムアウト以後、シンク装置は、ソース装置にＨＴＴＰ Ｇｅｔ ＵＲＬ１ ｐｌａｙｓｐｅｅｄ＝２のような命令で、ソース装置で２倍の速度でデータを送ることを要求する（９１０）。ｐｌａｙｓｐｅｅｄが指定されたＨＴＴＰ Ｇｅｔ ＵＲＬ１命令の一例が図１４に示されている。
【００９７】
この際、ソース装置は、２倍速い速度でデータを送信するか、またはそのような効果を得るために、それぞれ部分的なデータを送信できる（９１１）。ソース装置は、もし、保存されたデータをいずれも消尽する場合、それ以上シークまたはトリックプレイが不能な状態に状態情報を変更し、状態情報が変更されたことをイベントを通じてシンク装置に知らせる（９１２）。これにより、このイベントを受けたシンク装置は、状態情報の変更を知るためにｂｒｏｗｓｅ／ｓｅａｒｃｈを実行し（９１３）、その結果をソース装置から得る。
【００９８】
以上、説明したようなシンク装置及びソース装置での管理方法は、また、コンピュータで読み取り可能な記録媒体にコンピュータで読み取り可能なコードとして具現することが可能である。コンピュータで読み取り可能な記録媒体は、コンピュータシステムにより読み取られるデータが保存されるあらゆる種類の記録装置を含む。コンピュータで読み取り可能な記録媒体の例としては、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＣＤ−ＲＯＭ、磁気テープ、フロッピー（登録商標）ディスク、光データ保存装置などがあり、またキャリアウェーブ（例えば、インターネットを通じた伝送）の形態で具現されるものも含む。また、コンピュータで読み取り可能な記録媒体は、ネットワークで連結されたコンピュータシステムに分散され、分散方式でコンピュータで読み取り可能なコードが保存されて実行されうる。そして、前記処理方法を具現するための機能的なプログラム、コード及びコードセグメントは、本発明が属する技術分野のプログラマにより容易に推論されうる。
【００９９】
これまで、本発明について、その望ましい実施形態を中心に述べた。当業者は、本発明が、本発明の本質的な特性から逸脱しない範囲で、変形された形態に具現可能であるということを理解できるであろう。したがって、開示された実施形態は、限定的な観点ではなく、説明的な観点で考慮されねばならない。本発明の範囲は、前述した説明ではなく、特許請求の範囲に表れており、それと同等な範囲内にあるあらゆる差異点は、本発明に含まれていると解釈されねばならない。
【産業上の利用可能性】
【０１００】
本発明は、例えばＤＶＤプレーヤ、ケーブルＳＴＢ、ＤＶＣＲ、ＤＴＶ、ＰＣなどの多様なデジタル機器に利用可能である。
【図面の簡単な説明】
【０１０１】
【図１】従来技術によって、ＤＨＷＧによるホームネットワーク環境を説明するための参考図である。
【図２】本発明によって、ネットワークを通じてデジタルコンテンツを共有するシステム構成図である。
【図３】図２に示したソース装置の概略的な構成図である。
【図４】図２に示したシンク装置の概略的な構成図である。
【図５】本発明の第１実施形態によって、シンク装置からソース装置にライブコンテンツについてのｐａｕｓｅ命令を受信する場合、ｐａｕｓｅ命令のタイムアウトが発生しない状況で、ライブコンテンツについてのｒｅｓｕｍｅ動作を行う過程のフローチャートである。
【図６】本発明の第２実施形態によって、シンク装置からソース装置にライブコンテンツについてのｐａｕｓｅ命令を受信する場合、ｐａｕｓｅ命令のタイムアウトが発生した状況で、ライブコンテンツを再び伝送する動作を行う過程のフローチャートである。
【図７】本発明の第３実施形態によって、シンク装置からソース装置にライブコンテンツについてのｐａｕｓｅ命令を受信する場合、ｐａｕｓｅ命令のタイムアウトが発生した状況で、ｐａｕｓｅの間に保存されたコンテンツを伝送する動作を行う過程のフローチャートである。
【図８】本発明の第４実施形態によって、シンク装置からソース装置にライブコンテンツについてのｐａｕｓｅ命令を受信する場合、ｐａｕｓｅ命令のタイムアウトが発生した状況で、シンク装置の要請によりコンテンツを複数回受信する動作を行う過程のフローチャートである。
【図９】本発明の第５実施形態によって、シンク装置からソース装置にライブコンテンツについてのｐａｕｓｅ命令を受信する場合、ｐａｕｓｅ命令のタイムアウトが発生した状況で、ソース装置の支援によりコンテンツを複数回伝送する動作を行う過程のフローチャートである。
【図１０】本発明に適用されるＨＴＴＰ ＧＥＴ命令の一例を示す図面である。
【図１１】本発明に適用されるｐａｕｓｅ命令の一例を示す図面である。
【図１２】本発明に適用されるｒｅｓｕｍｅ命令の一例を示す図面である。
【図１３】本発明に適用されるｒａｎｇｅが指定されたＨＴＴＰ ＧＥＴ命令の一例を示す図面である。
【図１４】本発明に適用されるｐｌａｙｓｐｅｅｄが指定されたＨＴＴＰ ＧＥＴ命令の一例を示す図面である。
【符号の説明】
【０１０２】
３００  ソース装置
３１０  チューナ
３２０  ストリーミングサーバ＋メディアサーバ
３３０  保存部
３４０  バイトカウンタ
４００  シンク装置
４１０  ストリーミングクライアント＋メディアサーバコントロールポイント
４２０  再生部
４３０  バイトカウンタ
【図１】
2006042353.tif 000003
【図２】
2006042353.tif 000004
【図３】
2006042353.tif 000005
【図４】
2006042353.tif 000006
【図５】
2006042353.tif 000007
【図６】
2006042353.tif 000008
【図７】
2006042353.tif 000009
【図８】
2006042353.tif 000010
【図９】
2006042353.tif 000011
【図１０】
2006042353.tif 000012
【図１１】
2006042353.tif 000013
【図１２】
2006042353.tif 000014
【図１３】
2006042353.tif 000015
【図１４】
2006042353.tif 000016