(57)【特許請求の範囲】
【請求項１】
メタファイルの再生目録ファイルを修正し、修正されたメタファイルを生成するスケジューラ、及び
プレーヤーに対してサーバの役割をして、プレーヤーからメタファイル転送要請が受信されれば、前記修正されたメタファイルを転送するサーバソケット
を含み、
前記スケジューラは、前記再生目録ファイルの最後のスライスファイルの一連番号を取得してＮ個減算した一連番号を最初に再生しなければならないファイルの一連番号に指定し、指定された前記一連番号以後のファイル名を含むメタファイルを形成する、
ストリーミング装置。
【請求項２】
前記スケジューラが前記再生目録ファイルにおいて前記最後のスライスファイル名から減算するＮは０または１である、請求項１に記載のストリーミング装置。
【請求項３】
前記スケジューラは、
中継サーバから受信したメタファイルから最後の画像スライスファイル名の一連番号を抽出するファイルパーシング部、
前記ファイルパーシング部により抽出された前記最後の画像スライスファイル名の前記一連番号から一定個数を減算した一連番号を最初に再生しなければならないファイルの一連番号に指定する再生目録ファイル修正部、及び
前記再生目録ファイル修正部で指定された前記一連番号を含み、前記一連番号より順次増加する一定個数のスライスファイル名を含む修正されたメタファイルを生成する再生目録ファイル生成部
を含む、請求項１に記載のストリーミング装置。
【請求項４】
前記スケジューラは、
メタファイルのスライスファイル名に該当するスライスファイルを臨時格納しており、プレーヤーの要請により、臨時格納している前記スライスファイルを転送するファイルキャッシュ部をさらに含む、請求項３に記載のストリーミング装置。
【請求項５】
中継サーバからメタファイルの転送を受けて前記スケジューラに提供するクライアントソケット部をさらに含む、請求項１に記載のストリーミング装置。
【請求項６】
前記クライアントソケット部は、ＨＴＴＰクライアントの役割をし、多数のクライアントソケットを含み、前記中継サーバから前記メタファイルの転送を受けて提供する、請求項５に記載のストリーミング装置。
【請求項７】
メタファイルの再生目録ファイルを修正し、修正されたメタファイルを生成するスケジューラ、及び、
プレーヤーに対してサーバの役割をして、プレーヤーからメタファイル転送要請が受信されれば、前記修正されたメタファイルを転送するサーバソケット
を含み、
前記スケジューラは、前記再生目録ファイルの最後のスライスファイルの一連番号を取得して２〜５の範囲の自然数であるＮ個減算した一連番号を最初に再生しなければならないファイルの一連番号に指定し、指定された前記一連番号以後の３個以上６個以下のスライスファイル名を含むメタファイルを形成する、ストリーミング装置。
【請求項８】
（Ａ）ストリーミング装置がメタファイルを修正し、修正されたメタファイルを生成するステップ、及び
（Ｂ）前記ストリーミング装置がサーバの役割をして、プレーヤーからメタファイルの転送要請を受信すれば、前記修正されたメタファイルを転送するステップ
を含み、
前記（Ａ）ステップは、
（Ａ−１）前記ストリーミング装置が中継サーバから受信したメタファイルから最後の画像スライスファイル名の一連番号を抽出するステップ、
（Ａ−２）前記ストリーミング装置が抽出した前記最後の画像スライスファイル名の一連番号から一定個数を減算した一連番号を最初に再生しなければならないファイルの一連番号に指定するステップ、及び
（Ａ−３）前記ストリーミング装置は、指定された前記一連番号を含み、前記一連番号より順次増加する一定個数のスライスファイル名を含む修正されたメタファイルを生成するステップ
を含む、ストリーミング方法。
【請求項９】
前記（Ｂ）ステップの後に、
（Ｃ）前記プレーヤーからスライスファイルの転送要請を受信すれば、該当するスライスファイルを転送するステップをさらに含む、請求項８に記載のストリーミング方法。
【請求項１０】
前記（Ａ）ステップの前に、
（Ｄ）前記ストリーミング装置が中継サーバからメタファイルの転送を受けるステップをさらに含む、請求項８に記載のストリーミング方法。
【請求項１１】
前記（Ｄ）ステップは、
（Ｄ−１）前記ストリーミング装置がＨＴＴＰクライアントの役割をする多数のクライアントソケットを用いて前記中継サーバにメタファイルの転送を要請するステップ、及び
（Ｄ−２）前記中継サーバから再生ファイル目録情報を含むメタファイルの転送を受けるステップ
を含む、請求項１０に記載のストリーミング方法。
【請求項１２】
前記（Ａ−２）ステップにおいて、前記一定個数は０または１である、請求項８に記載のストリーミング方法。
【請求項１３】
（Ａ）ストリーミング装置がメタファイルを修正し、修正されたメタファイルを生成するステップ、及び
（Ｂ）前記ストリーミング装置がサーバの役割をして、プレーヤーからメタファイルの転送要請を受信すれば、前記修正されたメタファイルを転送するステップ
を含み、
前記（Ａ）ステップは、
（Ａ−１）前記ストリーミング装置が中継サーバから受信したメタファイルから最後の画像スライスファイル名の一連番号を抽出するステップ、
（Ａ−２）前記ストリーミング装置が抽出した前記最後の画像スライスファイル名の一連番号から一定個数を減算した一連番号を最初に再生しなければならないファイルの一連番号に指定するステップ、及び
（Ａ−３）前記ストリーミング装置は、指定された前記一連番号を含み、前記一連番号より順次増加する一定個数のスライスファイル名を含む修正されたメタファイルを生成するステップ
を含み、
前記（Ａ−２）ステップにおいて、前記ストリーミング装置のスケジューラは、前記メタファイルの前記最後のスライスファイルの一連番号を取得して２〜５の範囲の自然数であるＮ個減算した一連番号を最初に再生しなければならないファイルの一連番号に指定し、指定された前記一連番号以後の３個以上６個以下のスライスファイル名を含むメタファイルを形成する、ストリーミング方法。
【請求項１４】
請求項８〜１３のいずれか１項に記載の方法をコンピュータに実行させるためのコンピュータプログラム。
【請求項１５】
請求項８〜１３のいずれか１項に記載の方法をコンピュータに実行させるためのコンピュータプログラムが記録されたコンピュータ読み取り可能な記録媒体。
【請求項１６】
リアルタイムで受信されたマルチメディアデータを多数のスライスファイルに分割し、メタファイルを生成する発行者サーバ、
前記発行者サーバにより生成された前記メタファイルを中継する中継サーバ、及び
プレーヤーに対してサーバの役割をして、前記中継サーバから提供される前記メタファイルの再生目録ファイルを修正し、修正されたメタファイルを前記プレーヤーに提供するストリーミング装置
を含み、
前記ストリーミング装置は、前記再生目録ファイルの最後のスライスファイルの一連番号を取得してＮ個減算した一連番号を最初に再生しなければならないファイルの一連番号に指定し、指定された前記一連番号以後のファイル名を含むメタファイルを形成する、
ストリーミングサービスシステム。
【請求項１７】
前記ストリーミング装置は端末装置に設置される、請求項１６に記載のストリーミングサービスシステム。
【請求項１８】
前記ストリーミング装置は、前記端末装置がスマートフォンである場合には、前記プレーヤーと同一のアプリで駆動される、請求項１７に記載のストリーミングサービスシステム。
【請求項１９】
前記Ｎは０または１である、請求項１６に記載のストリーミングサービスシステム。
【請求項２０】
前記Ｎは２〜５の範囲の自然数であって、前記指定された前記一連番号以後のファイル名は、指定された前記一連番号以後の３個以上６個以下のスライスファイル名を含む、請求項１６に記載のストリーミングサービスシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ストリーミング装置とその方法、これを用いたストリーミングサービスシステム及びコンピュータ読み取り可能な記録媒体に関し、特に、再生目録ファイルを修正して、多数の端末装置のプレーヤーの遅延時間を実質的に同一にするか、バッファリングを最小化するようにした、ストリーミング装置とその方法、これを用いたストリーミングサービスシステム及びコンピュータ読み取り可能な記録媒体に関する。
【背景技術】
【０００２】
インターネットを介してマルチメディアデータをリアルタイムで再生するストリーミング（ｓｔｒｅａｍｉｎｇ）サービスが活性化しており、最近ではＲＴＭＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｍｅｓｓａｇｉｎｇ  Ｐｒｏｔｏｃｏｌ）／ＲＴＳＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ）のような伝統的なサーバ主導型プロトコルでなく、標準ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）プロトコルを用いてストリーミングサービスが提供されている。
【０００３】
標準ＨＴＴＰプロトコルを用いてストリーミングサービスを提供する方式としては、ＨＴＴＰプログレッシブダウンロード（Ｐｒｏｇｒｅｓｓｉｖｅ  Ｄｏｗｎｌｏａｄ）方式と、ＨＴＴＰライブストリーミング（ＨＴＴＰ  Ｌｉｖｅ  Ｓｔｒｅａｍｉｎｇ、以下、ＨＬＳと称する）方式が主に用いられている。
【０００４】
ＨＬＳ方式は、メディアファイルを例えば１０秒（一般に５秒〜１５秒使用）程度の小さな長さを有するファイル（例えば、ＭＰＥＧ−２  Ｔｒａｎｓｐｏｒｔ  Ｓｔｒｅａｍファイル）にスライス化し、ファイルスライスのメタ情報である再生目録ファイルをクライアントに提供する。再生目録ファイルは、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）の一種であるＳＭＩＬ（Ｓｙｎｃｈｒｏｎｉｚｅｄ  Ｍｕｌｔｉｍｅｄｉａ  Ｉｎｔｅｇｒａｔｉｏｎ  Ｌａｎｇｕａｇｅ）文法を使用するＭ３Ｕ８（ＨＬＳ２）ファイルを使う。このため、ファイル名の形態は「．Ｍ３Ｕ８」または「．Ｍ３Ｕ」となる。ここで、「．Ｍ３Ｕ」ファイルはオーディオのみ存在するコンテンツに使われる。
【０００５】
ファイルスライス、すなわち、画像スライスファイルはＭＰＥＧ２−ＴＳフォーマットで構成されており、ファイルの拡張子は「ｔｓ」となっている。
【０００６】
ファイルの名前は順次的な順序を示すため、次のファイル名を類推することができるように生成される。主に十進数形態の数を利用するが、他方式の表記法で表したりもする。再生目録ファイルは、拡張機能として画像スライスファイルの再生順序と様々な再生関連機能に関して設定できるタグを提供することができる。
【０００７】
クライアントは、再生目録ファイルをＨＴＴＰプロトコルを用いてサーバからダウンロードし、再生目録ファイルにおいて指定された画像スライスファイルをサーバからダウンロードして順次に続いて再生する。
【０００８】
ＨＬＳサービスでは、通常３個やそれ以上の画像スライスファイルに対する再生順序を有した再生目録ファイルがクライアントに伝達される。仮に新たに伝達された再生目録ファイルのファイル目録のうち最後から三番目の画像スライスファイル以後から再生を始めるのであれば、クライアントは新たに再生目録ファイルを要請する。その他に、クライアントは、サーバから再生目録ファイルを受けて更新された目録を発見したのであれば、最小再生目録の最後の画像スライスファイルの長さだけ待機した後、更新された再生目録に該当するファイルを要請する。仮に再生目録が更新されなかったのであれば、目標の長さの０．５倍待機した後に再び、再生目録ファイルを要請する。
【０００９】
このようなＨＬＳ方式はＬＩＶＥ／ＶＯＤを全て支援し、ＬＩＶＥの場合、準リアルタイムで動作するプロトコルとして、Ｍ３Ｕ８に含まれたＴＳ個数に応じて端末装置のプレーヤー毎に再生開始時点が異なり、そのためにプレーヤー毎に遅延時間が異なるという問題が発生する。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】韓国特許登録第１０−１３９７１８３号
【特許文献２】韓国特許登録第１０−１４５２３４５号
【特許文献３】韓国特許登録第１０−０８９９６６６号
【特許文献４】韓国特許登録第１０−１２４７１３３号
【特許文献５】韓国公開特許第２０１５−０１２０８８２号
【発明の概要】
【発明が解決しようとする課題】
【００１１】
本発明は、前記のような問題点を解決するために、ＨＬＳ方式において再生目録を修正して、多数のプレーヤーの遅延時間を実質的に同一にするか、バッファリングを最小化するようにした、ストリーミング装置とその方法、これを用いたストリーミングサービスシステム及びコンピュータ読み取り可能な記録媒体を提供することにある。
【課題を解決するための手段】
【００１２】
本発明の一実施形態は、メタファイルの再生目録ファイルを修正し、修正されたメタファイルを生成するスケジューラ、及びプレーヤーに対してサーバの役割をして、プレーヤーからメタファイル転送要請が受信されれば、前記修正されたメタファイルを転送するサーバソケットを含む。
【００１３】
また、本発明の一実施形態の前記スケジューラは、前記メタファイルの再生目録ファイルにおいて最初に再生しなければならないファイルの一連番号を修正し、修正された一連番号以後のファイル名を含むメタファイルを形成してもよい。
【００１４】
なお、本発明の一実施形態の前記スケジューラは、前記再生目録ファイルの最後のスライスファイルの一連番号を取得してＮ個減算した一連番号を、最初に再生しなければならないファイルの一連番号に指定し、指定された一連番号以後のファイル名を含むメタファイルを形成してもよい。
【００１５】
また、本発明の一実施形態の前記スケジューラが前記再生目録ファイルにおいて最後のスライスファイル名から減算するＮは０または１であってもよい。
【００１６】
なお、本発明の一実施形態の前記スケジューラは、メタファイルから最後の画像スライスファイル名の一連番号を抽出するファイルパーシング部、前記ファイルパーシング部により抽出された前記最後の画像スライスファイル名の前記一連番号から一定個数を減算した一連番号を、最初に再生しなければならないファイルの一連番号に指定する再生目録ファイル修正部、及び前記再生目録ファイル修正部で指定された前記一連番号を含み、前記一連番号より順次増加する一定個数のスライスファイル名を含む修正されたメタファイルを生成する再生目録ファイル生成部を含んでもよい。
【００１７】
また、本発明の一実施形態の前記スケジューラは、メタファイルのスライスファイル名に該当するスライスファイルを臨時格納しており、プレーヤーの要請により、臨時格納している前記スライスファイルを転送するファイルキャッシュ部をさらに含んでもよい。
【００１８】
なお、本発明の一実施形態は、中継サーバからメタファイルの転送を受けて前記スケジューラに提供するクライアントソケット部をさらに含んでもよい。
【００１９】
また、本発明の一実施形態は、前記クライアントソケット部は、ＨＴＴＰクライアントの役割をし、多数のクライアントソケットを含み、前記中継サーバから前記メタファイルの転送を受けて提供してもよい。
【００２０】
なお、本発明の一実施形態の前記スケジューラは、前記再生目録ファイルの最後のスライスファイルの一連番号を取得して２〜５の範囲の自然数であるＮ個減算した一連番号を、最初に再生しなければならないファイルの一連番号に指定し、指定された一連番号以後の３個以上６個以下のスライスファイル名を含むメタファイルを形成してもよい。
【００２１】
一方、本発明の他の一実施形態は、（Ａ）ストリーミング装置がメタファイルを修正し、修正されたメタファイルを生成するステップ、及び（Ｂ）前記ストリーミング装置がプレーヤーに対してサーバの役割をして、プレーヤーからメタファイルの転送要請を受信すれば、前記修正されたメタファイルを転送するステップを含んでもよい。
【００２２】
また、本発明の他の一実施形態は、前記（Ｂ）ステップの後に、（Ｃ）前記プレーヤーからスライスファイルの転送要請を受信すれば、該当するスライスファイルを転送するステップをさらに含んでもよい。
【００２３】
なお、本発明の他の一実施形態は、前記（Ａ）ステップの前に、（Ｄ）前記ストリーミング装置が中継サーバからメタファイルの転送を受けるステップをさらに含んでもよい。
【００２４】
また、本発明の他の一実施形態の前記（Ｄ）ステップは、（Ｄ−１）前記ストリーミング装置がＨＴＴＰクライアントの役割をする多数のクライアントソケットを用いて前記中継サーバにメタファイルの転送を要請するステップ、及び（Ｄ−２）前記中継サーバから再生ファイル目録情報を含むメタファイルの転送を受けるステップを含んでもよい。
【００２５】
なお、本発明の他の一実施形態の前記（Ａ）ステップは、（Ａ−１）前記ストリーミング装置が中継サーバから受信したメタファイルから最後の画像スライスファイル名の一連番号を抽出するステップ、（Ａ−２）前記ストリーミング装置が抽出した前記最後の画像スライスファイル名の一連番号から一定個数を減算した一連番号を最初に再生しなければならないファイルの一連番号に指定するステップ、及び（Ａ−３）前記ストリーミング装置は、指定された前記一連番号を含み、前記一連番号より順次増加する一定個数のスライスファイル名を含む修正されたメタファイルを生成するステップを含んでもよい。
【００２６】
また、本発明の他の一実施形態の前記（Ａ−２）ステップにおいて、前記ストリーミング装置は再生目録ファイルの最後のスライスファイルの一連番号を取得してＮ個減算した一連番号を、最初に再生しなければならないファイルの一連番号に指定し、前記Ｎは０または１であってもよい。
【００２７】
本発明の他の一実施形態の前記（Ａ−２）のステップにおいて、前記ストリーミング装置のスケジューラは、前記再生目録ファイルの最後のスライスファイルの一連番号を取得して２〜５の範囲の自然数であるＮ個減算した一連番号を、最初に再生しなければならないファイルの一連番号に指定し、指定された前記一連番号以後の３個以上６個以下のスライスファイル名を含むメタファイルを形成してもよい。
【００２８】
一方、本発明のさらに他の一実施形態は、リアルタイムで受信されたマルチメディアデータを多数のスライスファイルに分割し、メタファイルを生成する発行者サーバ、前記発行者サーバにより生成された前記メタファイルを中継する中継サーバ、及びプレーヤーに対してサーバの役割をして、前記中継サーバから提供されるメタファイルの再生目録ファイルを修正し、修正されたメタファイルをプレーヤーに提供するストリーミング装置を含んでもよい。
【００２９】
また、本発明のさらに他の一実施形態の前記ストリーミング装置は端末装置に設置されてもよい。
【００３０】
なお、本発明のさらに他の一実施形態の前記ストリーミング装置は、前記端末装置がスマートフォンである場合には、前記プレーヤーと同一のアプリで駆動されてもよい。
【発明の効果】
【００３１】
以上に示したような本発明の一実施形態によれば、Ｍ３Ｕ８に含まれたＴＳ個数に応じてプレーヤー毎に再生開始時点が異なるという問題を解決することができる。その結果、プレーヤー毎に遅延時間を実質的に同一にすることができる。
【００３２】
また、本発明の一実施形態によれば、ストリーミング装置がプレーヤーに対してサーバの役割をして、プレーヤーからメタファイル転送要請が受信されれば、前記修正されたメタファイルを転送するようにしている。そのため、上位サーバの変更なしに容易に再生開始時点を変更できるようにして、ユーザの便宜を増大させることができる。
【００３３】
すなわち、本発明の一実施形態によれば、プレーヤーが中継サーバによらずプレーヤーに対してサーバの役割をするストリーミング装置を介して通信を行うため、遅延時間の短縮、及び再生時点が異なるということをストリーミング装置で解決することができるため、その実現と変更等が容易であり、ユーザの便宜性が増大する。
【００３４】
また、本発明の一実施形態によれば、Ｍ３Ｕ８に含まれたＴＳ個数を十分に確保できるようにすることで、プレーヤーのバッファリング（ｂｕｆｆｅｒｉｎｇ）を最小化することができる。
【図面の簡単な説明】
【００３５】
【図１】本発明の一実施形態によるストリーミング装置を用いたストリーミングサービスシステムの構成図である。
【図２】ＨＬＳプロトコルを用いるライブストリーミングサービスにおける一般的なメタファイルを示す例示図である。
【図３】本発明の一実施形態による再生目録ファイルが修正されたメタファイルを示す例示図である。
【図４】本発明の一実施形態による再生目録ファイルが修正されたメタファイルを示す他の例示図である。
【図５】従来技術によるファイル再生順序と本発明によるファイル再生順序を示す図である。
【図６】本発明の一実施形態による遅延時間の短縮を示す一例示図である。
【図７】本発明の一実施形態による遅延時間の短縮を示す他の例示図である。
【図８】本発明の一実施形態によるストリーミング装置の構成図である。
【図９】本発明の好ましい一実施形態によるストリーミング方法のフローチャートである。
【発明を実施するための形態】
【００３６】
本発明の一実施形態は様々な変換を加えたり色々な実施形態を有したりすることができる。以下では、特定の実施形態を、添付された図面に基づいて詳細に説明する。本発明の一実施形態を説明するにあたり、関連の公知技術に関する具体的な説明によって本発明の要旨が不当に解釈される恐れがあると判断される場合には、その詳細な説明は省略する。
【００３７】
第１、第２等の用語は様々な構成要素を説明するのに用いられるが、前記構成要素が前記用語によって限定されるものではなく、前記用語は一つの構成要素を他の構成要素から区別する目的にのみ用いられる。
【００３８】
図１は、本発明の一実施形態によるストリーミング装置を用いたストリーミングサービスシステムの構成図である。図１を参照すれば、本発明の一実施形態によるストリーミング装置を用いたストリーミングサービスシステムは、放送送出者１０、発行者（ＰＰ：Ｐｕｂｌｉｓｈ  Ｐｏｉｎｔ）サーバ２０、中継サーバ３０、ストリーミング装置４０及びプレーヤー５０を含む。
【００３９】
放送送出者１０は、発行者サーバ２０にビデオ信号、またはビデオ信号及びオーディオ信号等のマルチメディアデータを転送する（１：ＰＵＢＬＩＳＨ  ＡＵＤＩＯ、ＶＩＤＥＯ）。この時、放送送出者１０が提供するビデオ信号、またはビデオ信号及びオーディオ信号等のマルチメディア信号は生放送（ＬＩＶＥ）信号であってもよい。
【００４０】
このような放送送出者１０は、カムコーダや、カメラのような一般的な画像取得に用いられる画像取得装置を含むことができる。また、放送送出者１０は、画像取得装置により取得されたビデオ信号、またはビデオ信号及びオーディオ信号等のマルチメディア信号をデジタルに圧縮するエンコーダ等を含むことができる。
【００４１】
このような放送送出者１０は、画像取得装置を介して画像信号を取得し、エンコーダを用いて取得された画像信号を符号化してマルチメディアストリームに変換し、発行者サーバ２０に転送する。
【００４２】
この時、前記符号化されたマルチメディアストリームは、標準画像トランスポートプロトコルであるリアルタイムストリーミングプロトコル（Ｒｅａｌ  Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ；ＲＴＳＰ、ＲＦＣ  ２３２６に規約される）とリアルタイムトランスポートプロトコル（Ｒｅａｌｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ；ＲＴＰ）またはリアルタイムメッセージングプロトコル（Ｒｅａｌ  Ｔｉｍｅ  Ｍｅｓｓａｇｉｎｇ  Ｐｒｏｔｏｃｏｌ；ＲＴＭＰ）等を介して発行者サーバ２０に転送される。これらは、送出プロトコルである。  
【００４３】
一方、前記発行者サーバ２０は、前記放送送出者１０が転送したビデオ信号、またはビデオ信号及びオーディオ信号を符号化する。その後、前記発行者サーバ２０は、スライスファイル（ｃｈｕｎｋ）に分割し、ＨＬＳプロトコルで中継サーバ３０にストリーミングする（２：ＳＴＲＥＡＭＩＮＧ  ＡＵＤＩＯ，ＶＩＤＥＯ）。動画データをスライス化して生成する画像スライスファイルをＴＳ（ｔｒａｎｓｐｏｒｔ  ｓｔｒｅａｍ，ＴＳ）ファイルと称したりもする。
【００４４】
このような発行者サーバ２０はストリームセグメンタ（Ｓｔｒｅａｍ  Ｓｅｇｍｅｎｔｅｒ）を備えている。前記発行者サーバ２０に備えられたストリームセグメンタは、一定時間の間隔毎に入力を受けたビデオ、またはビデオ信号及びオーディオ信号を分割し、分割されたファイルを作り、分割されたファイルに接近できる再生目録ファイルを含むメタファイルを生成する。ストリームセグメンタが生成するメタファイルはＭ３Ｕ８ファイル形式を取ることができる。
【００４５】
Ｍ３Ｕ８フォーマットはＭ３Ｕフォーマットから拡張されたもので、Ｍ３Ｕフォーマットに比べて、ＥＵＣ−ＫＲ文字集合を使用することができ、様々な指示語で再生しようとするファイルに対する追加の情報を提供することができる。Ｍ３Ｕ８フォーマットは一番目の行が「＃ＥＸＴＭ３Ｕ」文字列から始まる。
【００４６】
ストリーミング装置は、メタファイルの一番目の行を確認してＭ３Ｕ８フォーマットが適用されたことを認知することができる。Ｍ３Ｕ８フォーマットは「＃ＥＸＴ」文字列を指示語として活用する。すなわち、ストリーミング装置は、「＃ＥＸＴ」文字列によりＭ３Ｕ８形式のメタファイルの指示語を認識することができる。Ｍ３Ｕ８フォーマットにおいて「＃ＥＸＴ」から始まらなければ、＃以後の全ての文字列は注釈として見なされる。
【００４７】
また、Ｍ３Ｕ８フォーマットは、目録ファイルに羅列される各ファイルの最大再生時間、すなわち、目標長さを示す指示語（＃ＥＸＴ−Ｘ＿ＴＡＲＧＥＴＤＵＲＡＴＩＯＮ）、最初に再生しなければならないファイルの一連番号を示す指示語（＃ＥＸＴ−Ｘ−ＭＥＤＩＡ−ＳＥＱＵＥＮＣＥ）、該当指示語の次に出てくるＴＳファイルの再生時間を示す指示語（＃ＥＸＴＩＮＦ）を含む。生放送の画像をストリーミングする場合には、Ｍ３Ｕ８目録ファイルが「＃ＥＸＴ−Ｘ−ＥＮＤＬＩＳＴ」で終わらない。
【００４８】
一方、中継サーバ３０は、放送送出者１０から送出されたビデオ信号、またはビデオ信号及びオーディオ信号に相応して変換されたストリーミングデータをストリーミング装置４０に転送する（３：ＰＬＡＹ  ＨＴＴＰ  ＬＩＶＥ  ＳＴＲＥＡＭＩＮＧ）。前記中継サーバ３０は、トランスミッタ（ｔｒａｎｓｍｉｔｔｅｒ）とコレクタ（ｃｏｌｌｅｃｔｏｒ）を含み、変換されたストリーミングデータをストリーミング装置４０に転送する。
【００４９】
このような中継サーバ３０のトランスミッタは、発行者サーバ２０から転送されるマルチメディアに相応するストリーミングデータをコレクタに伝達する機能をする。中継サーバ３０に含まれるコレクタは、トランスミッタから伝達されるマルチメディアに相応するストリーミングデータをストリーミング装置４０に提供するために待機させる機能をする。
【００５０】
次に、ストリーミング装置４０は、中継サーバ３０を介して提供される再生目録ファイルを含むメタファイルの転送を受けて、それを格納する。または、それを臨時格納してもよい。前記ストリーミング装置４０は、メタファイルに含まれた再生目録に応じてスライスファイルを中継サーバ３０に要請し転送を受けて、それを格納する。または、それを臨時格納してもよい。
【００５１】
この時、ストリーミング装置４０が中継サーバ３０から転送を受ける、再生しようとする動画に対する情報である再生目録ファイルを含むメタファイル（Ｍ３Ｕ８ファイル）には画像スライスファイル、すなわちＴＳファイルの名前が含まれ、ＴＳファイルの名前は実行順序に応じて順次増加する、負でない整数を含んで構成されることができる。
【００５２】
図２は、ＨＬＳプロトコルを用いるライブストリーミングサービスにおける一般的なメタファイルを示す図であり、図３は、本発明の一実施形態による再生目録ファイルが修正されたメタファイルを示す図である。図４は、本発明の一実施形態による再生目録ファイルが修正されたメタファイルを示す他の図である。
【００５３】
ＨＬＳプロトコルを用いるライブストリーミングサービスにおいて、再生目録ファイルは、一般に、図２に示すように３個以上のスライスファイルを有する。３個以上のスライスファイルは、一例として、１０８５１６．ｔｓ〜１０８５２１．ｔｓが挙げられる。
【００５４】
このような一般的なＨＬＳライブストリーミングサービスにおける再生目録ファイルとは異なり、本発明によるストリーミングサービスにおける再生目録ファイルはさらに少ない画像スライスファイルを持つように修正される。
【００５５】
すなわち、ストリーミング装置４０は、取得されたメタファイルに含まれた再生目録ファイルの画像スライスのファイル名のうち、一番目の画像スライスファイル名と、最後の画像スライスファイル名を取得する。そして、ストリーミング装置４０は、一番目の画像スライスファイル名と、最後の画像スライスファイル名に基づいて再生目録ファイルを修正する。
【００５６】
具体的には、ストリーミング装置４０は、最後の画像スライスファイル名の一連番号を確認し、それよりＮ個を減算した一連番号を最初に再生しなければならないファイルの一連番号を示す指示語（＃ＥＸＴ−Ｘ−ＭＥＤＩＡＳＥＱＵＥＮＣＥ）に指定して修正された一連番号以後のスライスファイル名を含むメタファイルを生成する。
【００５７】
これを、図３を参照して説明すれば、ストリーミング装置４０が中継サーバ３０から転送を受けたメタファイルにおいて最初に再生しなければならないファイルの一連番号は１０８５１６番のファイルとなっており、これを最後のファイル名である１０８５２１から１個を減算した１０８５２０を最初に再生しなければならないファイルの一連番号に修正して転送する。
【００５８】
そして、ストリーミング装置４０は、メタファイルに含まれるスライスファイルも再生しなければならないファイルの一連番号から以後の一連番号からなるスライスファイルを含むようにする。一例として、図３において、１０８５２０と１０８５２１を含むようにする。
【００５９】
ここで、ストリーミング装置４０が減算するＮは各地域や国家の通信政策や通信環境に応じて調整することができる。好ましくは、０または１である。このような通信政策は、ストリーミング装置４０が駆動される時に該当国家の政策サーバ（図示せず）からダウンロードし格納して管理する。
【００６０】
このような状況で、ストリーミング装置４０は、プレーヤー５０に対してサーバとしての役割をして、プレーヤー５０からメタファイル転送要請を受信すれば、受信されたメタファイル転送要請を登録する。そして、ストリーミング装置４０は、修正された再生目録ファイルを含むメタファイルをプレーヤー５０に転送する（４：ＰＬＡＹ  ＨＴＴＰ  ＬＩＶＥ  ＳＴＲＥＡＭＩＮＧ）。
【００６１】
ストリーミング装置４０は、このようなメタファイルの転送に応じ、プレーヤー５０から要請されるスライスファイル転送要請によって該当するスライスファイルを転送する。勿論、ストリーミング装置４０は、メタファイル情報を監視しつつ、継続的に更新して最新のメタファイル情報を維持するようにする。
【００６２】
すなわち、ストリーミング装置４０は、周期的にＭ３Ｕ８目録ファイルに対する変更有無を確認し、変更に応じて新たに追加されるＴＳファイルを中継サーバ３０に要請し提供を受けて格納する。
【００６３】
このように、ＬＩＶＥストリーミングサービスのＭ３Ｕ８目録ファイルは時間流れに従って変更され、例えば、新しいＴＳファイルが生成される時に変更される。
【００６４】
ストリーミング装置４０は、変更されたＭ３Ｕ８目録ファイルに追加されたＴＳファイルを要請して再生することができる。ストリーミング装置４０は、Ｍ３Ｕ８目録ファイルの変更を確認するために、Ｍ３Ｕ８目録ファイルに含まれた最後のスライスファイルに対する指示語（＃ＥＸＴＩＮＦ）に指定された時間の０．５倍〜１．５倍の時間内で、Ｍ３Ｕ８目録ファイルを要請して変更有無を確認することができる。
【００６５】
前記ストリーミング装置４０は、ファイルキャッシュ部を備え、修正されたメタファイルの該当するスライスファイルをファイルキャッシュ部に格納または臨時格納し、プレーヤー５０の要請に対応して迅速に提供するようにすることができる。
【００６６】
勿論、本発明によるストリーミングサービスにおける再生目録ファイルはバッファリングを最小化するために３個以上６個以下のスライスファイルを含み、ストリーミング装置４０が減算するＮは２〜５の範囲を有する自然数であってもよく、好ましくは２が良い。
【００６７】
これを、図４を参照して説明すれば、ストリーミング装置４０が減算するＮは５を持つようにし、それによって再生を始める一連番号は１０８５１６となっており、スライスファイル個数で３個を持つようにして１０８５１６、１０８５１７、１０８５１８の一連番号のスライスファイルを持つようにした。
【００６８】
このように、本発明の一実施形態によるストリーミングサービスにおいて、スライスファイルを最大限持つようにして、バッファリングが最小化されるようにすることができる。図４では、強制的に一番目のスライスファイルから再生をするようにｍ３ｕ８を変調して下ろせば、結果的にスライスファイルの個数が６個だけバッファを持つことができるのでバッファリングを最小化することができる。
【００６９】
一方、プレーヤー５０は、駆動されると、ストリーミング装置４０に生目録ファイルを含むメタファイルの転送を要請し、該当する修正された再生目録ファイルを含むメタファイルの転送を受ける。
【００７０】
この時、転送を受ける修正された再生目録ファイルは図３と図４との右側のような構造からなり、再生しようとする画像スライスファイルの名前、すなわち、画像スライスファイル名からなる再生目録を含む。
【００７１】
このようなプレーヤー５０は、再生目録を含むメタファイルを受信すれば、最初に再生しなければならないファイルの一連番号を確認して該当するファイルから再生する。このために、プレーヤー５０は、再生目録に含まれたスライスファイルをストリーミング装置４０に要請し転送を受けて再生する。
【００７２】
勿論、プレーヤー５０も、ストリーミング装置２０と同様に、メタファイル情報を監視しつつ、継続的に更新して最新のメタファイル情報を維持するようにする。すなわち、プレーヤー５０は、周期的にＭ３Ｕ８目録ファイルに対する変更有無を確認し、変更に応じて新たに追加されるＴＳファイルをストリーミング装置４０に要請し提供を受けて再生する。
【００７３】
プレーヤー５０は、Ｍ３Ｕ８目録ファイルの変更を確認するために、Ｍ３Ｕ８目録ファイルに含まれた最後のスライスファイルに対する指示語（＃ＥＸＴＩＮＦ）に指定された時間の０．５倍〜１．５倍の時間内で、Ｍ３Ｕ８目録ファイルを要請して変更有無を確認することができる。
【００７４】
上記で説明したストリーミング装置４０とプレーヤー５０は同一の端末装置に設置されてもよい。前記端末装置は、ネットワークに接続され、前記ネットワークを介して提供されるコンテンツを利用するためのユーザ装置であって、中継サーバ３０に特定コンテンツを要請し、それに対応して中継サーバ３０から転送されるコンテンツを受信して利用される。
【００７５】
このような端末装置は、例えば、デスクトップＰＣ、ノートブック型パソコン、タブレットＰＣ、スマートフォン、ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔ）、インターネットＴＶ（スマートＴＶ）等、通信機能を含む電子／情報通信機器であれば、いずれであってもよい。
【００７６】
特に、端末装置がスマートフォンである場合、前記ストリーミング装置４０とプレーヤー５０は同一のアプリ（ＡＰＰ）で駆動される。
【００７７】
このようなプレーヤー５０のファイル再生順序が図５に示されており、図５（Ａ）は従来技術によるファイル再生順序を示し、図５（Ｂ）は本発明の一実施形態によるファイル再生順序を示す。
【００７８】
図５（Ａ）に示されたファイル再生順序は１０８５１６．ｔｓから順次ファイル名の番号が増加しつつ再生され、プレーヤー毎に異なる時間遅延が発生し、図５（Ｂ）の場合は、ファイル再生順序が１０８５２０．ｔｓから順次ファイル名の番号が増加しつつ再生され、プレーヤー毎に遅延時間がほぼ同一となる。
【００７９】
このような結果は図６に示されており、図６（Ａ）は本発明による再生テストの結果であり、図６（Ｂ）はＭａｃ  Ｓａｆａｒｉブラウザーにおける再生テストの結果であって、１８秒の遅延時間が短縮できることを示す。
【００８０】
また、他の結果が図７に示されており、図７（Ａ）は本発明による再生テストの結果であり、図７（Ｂ）はＭａｃ  Ｓａｆａｒｉブラウザーにおける再生テストの結果であって、１４秒の遅延時間が短縮できることを示す。
【００８１】
このように、前記のような本発明によれば、Ｍ３Ｕ８に含まれたＴＳ個数に応じてプレーヤー毎に再生開始時点が異なるという問題を解決することができる。その結果、プレーヤー毎に遅延時間を実質的に同一にすることができる。
【００８２】
一方、上記で説明した放送送出者１０と発行者サーバ２０を連結するネットワークと中継サーバ３０とストリーミング装置４０を連結するネットワークとは符号分割多元接続（Ｃｏｄｅ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ、ＣＤＭＡ）、広帯域符号分割多元接続（Ｗｉｄｅｂａｎｄ  ＣＤＭＡ、ＷＣＤＭＡ(登録商標)）、高速パケット接続（Ｈｉｇｈ  Ｓｐｅｅｄ  Ｐａｃｋｅｔ  Ａｃｃｅｓｓ、ＨＳＰＡ）、ロングタームエボリューション（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ、ＬＴＥ(登録商標)）等のような移動通信網、イーサネット（Ｅｔｈｅｒｎｅｔ）(登録商標)、ｘＤＳＬ（ｘ  Ｄｉｇｉｔａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｌｉｎｅ）、ＨＦＣ（Ｈｙｂｒｉｄ  Ｆｉｂｅｒ  Ｃｏａｘ）(登録商標)、ＦＴＴＨ（Ｆｉｂｅｒ  Ｔｏ  Ｔｈｅ  Ｈｏｍｅ）等のような有線通信網、ＷｉＦｉ(登録商標)、Ｗｉｂｒｏ(登録商標)、Ｗｉｍａｘ(登録商標)、ＵＷＢ（Ｕｌｔｒａ  ＷｉｄｅＢａｎｄ）等のような無線通信網、または上述した通信網の組み合わせからなってもよく、特定の通信網に限定されるものではない。
【００８３】
図８は、本発明の好ましい一実施形態によるストリーミング装置の構成図である。図８を参照すれば、本発明の好ましい一実施形態によるストリーミング装置は、サーバソケット１１０、スケジューラ１２０及びクライアントソケット部１３０を含む。
【００８４】
前記サーバソケット１１０は、プレーヤー１００から再生ファイル目録を含むメタファイルの転送要請（ｒｅｑｕｅｓｔ）を受信し、受信された転送要請をスケジューラ１２０に転送して登録する。
【００８５】
そして、サーバソケット１１０は、プレーヤー５０に対してサーバとしての役割をして、スケジューラ１２０から転送される修正された再生ファイル目録を含むメタファイルをプレーヤー１００に転送する。
【００８６】
次に、スケジューラ１２０は、サーバソケット１１０を介してプレーヤー１００から再生ファイル目録を含むメタファイル転送要請を受信すれば、それを格納して管理する。スケジューラ１２０は、中継サーバ１４０から転送を受けた再生ファイル目録を含むメタファイルにおいて再生ファイル目録で最初に再生しなければならないファイル名を修正した後、修正された再生ファイル目録を含むメタファイルをプレーヤー１００に転送する。
【００８７】
このようなスケジューラ１２０は、ファイルパーシング部１２１、再生目録ファイル修正部１２２、再生目録ファイル生成部１２３及びファイルキャッシュ部１２４を含む。
【００８８】
前記ファイルパーシング部１２１は、メタファイルをパーシングして再生目録ファイルに初めて再生する画像スライスファイル名と最後に再生する画像スライスファイル名を抽出し、それを再生目録ファイル修正部１２２に渡す。
【００８９】
すると、再生目録ファイル修正部１２２は、最後の画像スライスファイル名の一連番号を確認し、それより一定個数を減算した一連番号を最初に再生しなければならないファイルの一連番号に指定する。
【００９０】
これにより、再生目録ファイル生成部１２３は、再生目録ファイル修正部１２２により修正された最初に再生しなければならないファイルの一連番号を含んでおり、それより順次増加する一定個数のスライスファイル名を含む修正されたメタファイルを生成する。
【００９１】
このような再生目録ファイル修正部１２２において減算しなければならない一定個数Ｎは、各国の通信政策等に応じて異なっており、該当国家の政策サーバから転送を受けて格納して管理し、好ましくは、０または１である。
【００９２】
政策サーバの政策は国家別（または、ネットワーク別３Ｇ／ＬＴＥ  ｏｒ  ＷＩＦＩ）に区分されており、該当地域におけるテスト及び通信インフラを基準に決定することになる。
【００９３】
勿論、本発明によるストリーミングサービスにおける再生目録ファイル修正部１２２が、再生目録ファイルのバッファリングを最小化するために、３個以上６個以下のスライスファイルを含むようにすることができる。
【００９４】
また、再生目録ファイル修正部１２２が減算するＮは２〜５の範囲を有する自然数であってもよく、好ましくは２が良い。
【００９５】
これを、図４を参照して説明すれば、再生目録ファイル修正部１２２が減算するＮは５を持つようにし、それによって再生を始める一連番号は１０８５１６となっており、スライスファイル個数で３個を持つようにして１０８５１６、１０８５１７、１０８５１８の一連番号のスライスファイルを持つようにした。
【００９６】
このように、本発明によるストリーミングサービスにおいて、スライスファイルを最大限持つようにして、バッファリングが最小化されるようにすることができる。図４では、強制的に一番目のスライスファイルから再生をするようにｍ３ｕ８を変調して下ろせば、結果的にスライスファイルの個数が６個だけバッファを持つことができるのでバッファリングを最小化することができる。このように生成された修正されたメタファイルは、再生目録ファイル生成部１２３が生成し、サーバソケット１１０を介してプレーヤー１００に提供する。
【００９７】
一方、ファイルキャッシュ部１２４は、修正されたメタファイルに応じて再生されなければならないスライスファイルを格納または臨時格納しており、サーバソケット１１０を介してプレーヤー１００から要請がある場合、それをプレーヤー１００に伝達する。
【００９８】
一方、クライアントソケット部１３０は、多数のクライアントソケット（１３０−１〜１３０−ｎ）を備えており、ＨＴＴＰクライアントの役割をして、中継サーバ１４０からメタファイルの転送要請を受け、メタファイルに含まれたスライスファイルの転送を受ける。
【００９９】
前記クライアントソケット部１３０は、どの程度のクライアントソケットを備えるかは状況によって適切に決めることができる。このようなクライアントソケット部１３０は、ＲＥＱ別の優先権（ｐｒｉｏｒｔｙ）を処理し、ＨＴＴＰクライアントの状態（ｃｏｎｎｅｃｔｉｎｇ、ｃｏｎｎｅｃｔｅｄ、ｒｅｃｖ  ｈｅａｄｅｒ、ｒｅｃｖ  ｂｏｄｙ（ｐｅｒｃｅｎｔ））等を管理する。
【０１００】
このように構成されるストリーミング装置は次の通りに動作する。前記サーバソケット１１０は、プレーヤー１００から再生ファイル目録を含むメタファイルの転送要請（ｒｅｑｕｅｓｔ）を受信し、受信された転送要請をスケジューラ１２０に登録する。
【０１０１】
すると、スケジューラ１２０は、サーバソケット１１０を介してプレーヤー１００から再生ファイル目録を含むメタファイル転送要請を受信すれば、それを格納して管理し、中継サーバ１４０から転送を受けた再生ファイル目録を含むメタファイルにおいて再生ファイル目録で最初に再生しなければならないファイル名を修正した後、修正された再生ファイル目録を含むメタファイルをプレーヤー１００に転送する。
【０１０２】
一方、ファイルキャッシュ部１２４は、修正されたメタファイルに応じて再生されなければならないスライスファイルを格納または臨時格納しており、サーバソケット１１０を介してプレーヤー１００から要請がある場合、それをプレーヤー１００に伝達する。
【０１０３】
図９は、本発明の好ましい一実施形態によるストリーミング方法のフローチャートである。本発明の一実施形態に係るストリーミング装置は、取得した再生目録ファイルをプレーヤーに転送して再生目録ファイルに含まれた画像スライスファイルが再生されるようにする。ライブストリーミングサービスの特性上、新しい画像スライスファイルを生成しつつ、新たに再生目録ファイルが生成される。
【０１０４】
本発明の一実施形態では、ライブストリーミングサービスが提供される場合にプレーヤー毎に互いに異なる遅延時間が発生するのを防止するために、中継サーバから受信した再生目録ファイルに含まれたファイル目録のうち一番目の画像スライスファイル名と最後の画像スライスファイル名を利用する。
【０１０５】
そして、中継サーバから新たに生成される画像スライスファイルに応じた再生目録ファイルを修正し、プレーヤーが修正された再生目録ファイルに応じてスライスファイルを受信して再生することができるようにする。
【０１０６】
図９のように、ストリーミング装置は、再生目録ファイルを含むメタファイルを中継サーバに要請し、中継サーバから再生目録ファイルを含むメタファイルを取得する（Ｓ１００、Ｓ１１０）。
【０１０７】
ストリーミング装置は、取得された再生目録ファイルに含まれた画像スライスのファイル名のうち、一番目の画像スライスファイル名と、最後の画像スライスファイル名を取得する（Ｓ１２０）。そして、ストリーミング装置は、一番目の画像スライスファイル名と、最後の画像スライスファイル名に基づいて再生目録ファイルを修正する（Ｓ１２０）。
【０１０８】
具体的には、ストリーミング装置は、最後の画像スライスファイル名の一連番号を確認し、それより一定個数Ｎを減算した画像スライスファイル名を最初に再生しなければならないファイルの一連番号を示す指示語（＃ＥＸＴ−Ｘ−ＭＥＤＩＡＳＥＱＵＥＮＣＥ）に指定して修正された一連番号以後のスライスファイル名を含むメタファイルを生成する。
【０１０９】
ここで、ストリーミング装置が減算する一定個数Ｎは０または１が好ましく、各地域や国家の通信政策や通信環境等に応じて調整することができる。このような通信政策は、ストリーミング装置が駆動される時に該当国家の政策サーバ（図示せず）からダウンロードし格納して管理する。
【０１１０】
勿論、本発明によるストリーミングサービスにおける再生目録ファイルはバッファリングを最小化するために３個以上６個以下のスライスファイルを含み、ストリーミング装置が減算するＮは２〜５の範囲を有する自然数であってもよく、好ましくは２が良い。
【０１１１】
このように、本発明によるストリーミングサービスにおいて、スライスファイルを最大限持つようにして、バッファリングが最小化されるようにすることができる。このような状況で、ストリーミング装置は、プレーヤーからメタファイル転送要請を受信すれば、プレーヤーに対してサーバとして役割をして、受信されたメタファイル転送要請を登録する（Ｓ１３０）。
【０１１２】
そして、ストリーミング装置は、修正された再生目録ファイルを含むメタファイルをプレーヤーに転送する（Ｓ１４０）。
【０１１３】
このようなメタファイルの転送に応じ、プレーヤーから要請されるスライスファイル要請によって該当するスライスファイルを転送する（Ｓ１５０、Ｓ１６０）。
【０１１４】
以上に示したような本発明の一実施形態によれば、Ｍ３Ｕ８に含まれたＴＳ個数に応じてプレーヤー毎に再生開始時点が異なるという問題を解決することができる。その結果、プレーヤー毎に遅延時間を実質的に同一にすることができる。
また、本発明によれば、Ｍ３Ｕ８に含まれたＴＳ個数を十分に確保できるようにすることで、プレーヤーのバッファリングを最小化することができる。
【０１１５】
本発明は、特定の機能及びそれに関係した性能を示す方法ステップを、上記で説明した。このような機能的な構成要素及び方法ステップの境界や順序は説明を簡単にするために、ここでは任意に定義された。
【０１１６】
特定の機能及び関係が適切に実行される限り、代案的な境界及び順序が定義されてもよい。よって、このような代案的な境界及び順序は、本発明において請求された発明の範囲及び思想の範囲内である。さらに、このような機能的な構成要素の境界は説明を簡単にするために任意に定義された。ある重要な機能が適切に実行される限り、代案的な境界が定義されてもよい。同様に、フローチャートブロックもある重要な機能性を示すために、ここで任意に定義されてもよい。拡張された使用のために、前記フローチャートブロック境界及び順序は定義されていてもよく、ある重要な機能を実行する。よって、機能的な構成要素及びフローチャートブロック並びに順序の代案的な定義は、いずれも、本発明において請求された発明の範囲及び思想の範囲内である。
【０１１７】
また、本発明は、一つ以上の実施形態で示された用語で、部分的に説明されていてもよい。本発明の実施形態は、本発明、その側面、その特徴、その概念、及び／又はその例を示すために用いられる。本発明を実現する装置、製造の物、マシーン、及び／又はプロセスの物理的な実施形態は、ここに説明された一つ以上の実施形態を参照して説明された一つ以上の側面、特徴、概念、例等を含むことができる。さらに、全体図面において、実施形態は、同一または相異した参照番号を使用できる同一にまたは類似するように命名された機能、ステップ、モジュール等を統合してもよく、それと共に、前記機能、ステップ、モジュール等は、同一または類似した機能、ステップ、モジュール等または他のものであってもよい。
【０１１８】
以上のように、本発明は具体的な構成要素等のような特定事項と限定された実施形態及び図面によって説明されたが、これは本発明のより全般的な理解を助けるために提供されたものに過ぎず、本発明が本明細書において説明された実施形態に限定されるものではない。本発明が属する分野で通常の知識を有した者であれば、このような記載から様々な修正及び変更が可能である。
【０１１９】
したがって、本発明の思想は、説明された実施形態に限定して定められてはならず、後述する特許請求の範囲だけでなく、この特許請求の範囲と均等または等価的な変更がある全てのものは本発明の思想の範疇に属すると言える。
【符号の説明】
【０１２０】
１０  ・・・放送送出者
２０  ・・・発行者サーバ
３０  ・・・中継サーバ
４０  ・・・ストリーミング装置
５０  ・・・プレーヤー
１００  ・・・プレーヤー
１１０  ・・・サーバソケット
１２０  ・・・スケジューラ
１２１  ・・・ファイルパーシング部
１２２  ・・・再生目録ファイル修正部
１２３  ・・・再生目録ファイル生成部
１２４  ・・・ファイルキャッシュ部
１３０  ・・・クライアントソケット
１３０−１〜１３０−ｎ  ・・・クライアントソケット
１４０・・・  中継サーバ
【図１】
0006338709.tif 000002
【図２】
0006338709.tif 000003
【図３】
0006338709.tif 000004
【図４】
0006338709.tif 000005
【図５】
0006338709.tif 000006
【図６】
0006338709.tif 000007
【図７】
0006338709.tif 000008
【図８】
0006338709.tif 000009
【図９】
0006338709.tif 000010