(57)【特許請求の範囲】
【請求項１】
電子機器を実現するコンピュータにタイムマシン機能提供方法を実行させるためのコンピュータプログラムであって、
前記タイムマシン機能提供方法は、
ライブストリーミングサービスを提供するために前記電子機器にインストールされたストリーミングクライアントで、前記電子機器にインストールされたプレイヤとのストリーミングセッションを設定する段階、
前記ストリーミングクライアントで、ネットワークを介して受信したライブストリームデータを、前記ストリーミングセッションを通じて順に前記プレイヤに送信する段階、
前記ストリーミングクライアントで、前記ストリーミングセッションとは異なる、前記プレイヤとのタイムマシン制御セッションを設定する段階、
前記ストリーミングクライアントで、前記タイムマシン制御セッションを通じて前記プレイヤからタイムマシン制御要求を受信する段階、および
前記ストリーミングクライアントで、前記タイムマシン制御要求中に再生位置情報を含むタイムマシン制御要求に対応するチャンネルのライブストリームデータを、前記再生位置情報によって特定される再生位置から順に前記ストリーミングセッションを通じて前記プレイヤに送信する段階
を含み、
前記ストリーミングセッションを通じた前記ストリーミングクライアントと前記プレイヤとの間のデータ送信と、前記タイムマシン制御セッションを通じた前記ストリーミングクライアントと前記プレイヤとの間のデータ送信は、互いに異なる別のプロトコルによってそれぞれ行われ、
前記タイムマシン機能提供方法は、
前記ストリーミングクライアントで、チャンネル識別情報、前記チャンネル識別情報によって識別されるチャンネルのライブストリームデータのうち、特定の放送プログラムのライブストリームデータを識別するための放送キーを含む再生要求を、前記タイムマシン制御セッションを通じて受信する段階、および
前記ストリーミングクライアントで、前記チャンネル識別情報によって識別されるチャンネルのライブストリームデータのうち、前記放送キーによって識別されるライブストリームデータを順に前記ストリーミングセッションを通じて前記プレイヤに送信する段階
をさらに含む、コンピュータプログラム。
【請求項２】
前記タイムマシン機能提供方法は、
前記ストリーミングクライアントで、前記プレイヤから前記タイムマシン制御セッションを通じて認証要求を受信する段階であって、前記認証要求は、ライブストリームデータまたはチャンネルを特定するための情報および認証キーを含む、段階、および
前記認証キーを利用して前記プレイヤを認証し、前記プレイヤの認証が成功した場合、前記タイムマシン制御セッションに対して付与された固有値をセッションキーとして前記認証要求に対する応答に含めて前記プレイヤに送信する段階
をさらに含む、請求項１に記載のコンピュータプログラム。
【請求項３】
前記タイムマシン機能提供方法は、
前記ストリーミングクライアントで、前記タイムマシン制御要求が前記セッションキーを含むか否かを確認して前記タイムマシン制御要求を認証する段階
をさらに含む、請求項２に記載のコンピュータプログラム。
【請求項４】
前記タイムマシン機能提供方法は、
前記ストリーミングクライアントで、前記電子機器にインストールされた他のプレイヤからの認証要求に応じて前記他のプレイヤが認証された場合、前記他のプレイヤと設定されたタイムマシン制御セッションに対して付与された固有値を含むセッションキーを前記他のプレイヤに送信し、既存のプレイヤのセッションキーを無効にする段階
をさらに含む、請求項２に記載のコンピュータプログラム。
【請求項５】
前記タイムマシン機能提供方法は、
前記ストリーミングクライアントで、前記プレイヤから前記タイムマシン制御セッションを通じて情報取得およびセッション維持要求を受信する段階、および
前記ストリーミングクライアントで、前記ストリーミングセッションを通じて前記プレイヤで提供中のライブストリームデータに対するタイムマシン時間情報を前記情報取得およびセッション維持要求に対する応答に含めて、前記タイムマシン制御セッションを通じて前記プレイヤに送信する段階
を含む、請求項１に記載のコンピュータプログラム。
【請求項６】
前記タイムマシン時間情報は、前記ライブストリームデータの最新データを基準として過去データを探索可能な程度を示す指標として前記ライブストリームデータ別に予め設定された最大シフト可能時間、前記最新データを基準として現時点で過去データを探索可能な程度を示す指標である現在シフト可能時間、および前記最新データを基準としてタイムマシン機能によって現在再生中の過去データを特定する指標である現在シフト時間を含む、請求項５に記載のコンピュータプログラム。
【請求項７】
前記ライブストリームデータは、デリバリサーバからネットワークを介して前記電子機器に送信され、
前記デリバリサーバが含むタイムマシンバッファで、前記ライブストリームデータが前記チャンネル識別情報および前記放送キーを利用してチャンネル別そして放送プログラム別にマッチングされて格納される、請求項１に記載のコンピュータプログラム。
【請求項８】
前記再生要求は、タイムマシン機能の使用可否、識別されたライブストリームデータの初めの再生開始位置、チャンネルを一時停止状態によって開始するか否かのうち少なくとも１つに関する情報をさらに含む、請求項１に記載のコンピュータプログラム。
【請求項９】
前記タイムマシン機能提供方法は、
前記ストリーミングクライアントで、一時停止要求を、前記タイムマシン制御セッションを通じて受信することによって、前記ライブストリームデータから現在まで再生された位置を格納し、前記ライブストリームデータの送信を停止する段階、および
前記ストリーミングクライアントで、再開要求を、前記タイムマシン制御セッションを通じて受信することによって、前記の格納された位置から前記ライブストリームデータを順に前記プレイヤに送信する段階
をさらに含む、請求項１に記載のコンピュータプログラム。
【請求項１０】
前記一時停止要求に応じて前記チャンネルの接続が終了し、前記再開要求に応じて前記チャンネルの接続が再び生成される、請求項９に記載のコンピュータプログラム。
【請求項１１】
前記タイムマシン機能提供方法は、
前記ストリーミングクライアントで、前記タイムマシン制御要求に対する応答として、前記ライブストリームデータが現在放送中であるか否かに関するオンエア情報、および前記ライブストリームデータの最新データを基準としてタイムマシン機能によって現在再生中の過去データを特定する指標である現在シフト時間を、前記タイムマシン制御セッションを通じて前記プレイヤに送信する段階
をさらに含み、
前記プレイヤで前記オンエア情報および前記現在シフト時間を組み合わせることによって放送終了時点を決める、請求項１に記載のコンピュータプログラム。
【請求項１２】
コンピュータによって実現された電子機器のタイムマシン機能提供方法であって、
ライブストリーミングサービスを提供するために前記電子機器にインストールされたストリーミングクライアントで、前記電子機器にインストールされたプレイヤとのストリーミングセッションを設定する段階、
前記ストリーミングクライアントで、ネットワークを介して受信したライブストリームデータを、前記ストリーミングセッションを通じて順に前記プレイヤに送信する段階、
前記ストリーミングクライアントで、前記ストリーミングセッションとは異なる、前記プレイヤとのタイムマシン制御セッションを設定する段階、
前記ストリーミングクライアントで、前記タイムマシン制御セッションを通じて前記プレイヤからタイムマシン制御要求を受信する段階、および
前記ストリーミングクライアントで、前記タイムマシン制御要求中に再生位置情報を含むタイムマシン制御要求に対応するチャンネルのライブストリームデータを、前記再生位置情報によって特定される再生位置から順に前記ストリーミングセッションを通じて前記プレイヤに送信する段階
を含み、
前記ストリーミングセッションを通じた前記ストリーミングクライアントと前記プレイヤとの間のデータ送信と、前記タイムマシン制御セッションを通じた前記ストリーミングクライアントと前記プレイヤとの間のデータ送信は、互いに異なる別のプロトコルによってそれぞれ行われ、
前記タイムマシン機能提供方法は、
前記ストリーミングクライアントで、チャンネル識別情報、前記チャンネル識別情報によって識別されるチャンネルのライブストリームデータのうち、特定の放送プログラムのライブストリームデータを識別するための放送キーを含む再生要求を、前記タイムマシン制御セッションを通じて受信する段階、および
前記ストリーミングクライアントで、前記チャンネル識別情報によって識別されるチャンネルのライブストリームデータのうち、前記放送キーによって識別されるライブストリームデータを順に前記ストリーミングセッションを通じて前記プレイヤに送信する段階
をさらに含む、タイムマシン機能提供方法。
【請求項１３】
前記ストリーミングクライアントで、前記プレイヤから前記タイムマシン制御セッションを通じて認証要求を受信する段階であって、前記認証要求は、ライブストリームデータまたはチャンネルを特定するための情報および認証キーを含む、段階、および
前記認証キーを利用して前記プレイヤを認証し、前記プレイヤの認証が成功した場合、前記タイムマシン制御セッションに対して付与された固有値をセッションキーとして前記認証要求に対する応答に含めて前記プレイヤに送信する段階
をさらに含む、請求項１２に記載のタイムマシン機能提供方法。
【請求項１４】
前記ストリーミングクライアントで、前記プレイヤから前記タイムマシン制御セッションを通じて情報取得およびセッション維持要求を受信する段階、および
前記ストリーミングクライアントで、前記ストリーミングセッションを通じて前記プレイヤで提供中のライブストリームデータに対するタイムマシン時間情報を前記情報取得およびセッション維持要求に対する応答に含めて、前記タイムマシン制御セッションを通じて前記プレイヤに送信する段階
を含む、請求項１２に記載のタイムマシン機能提供方法。
【請求項１５】
前記ストリーミングクライアントで、一時停止要求を、前記タイムマシン制御セッションを通じて受信することによって、前記ライブストリームデータから現在まで再生された位置を格納し、前記ライブストリームデータの送信を停止する段階、および
前記ストリーミングクライアントで、再開要求を、前記タイムマシン制御セッションを通じて受信することによって、前記の格納された位置から前記ライブストリームデータを順に前記プレイヤに送信する段階
をさらに含む、請求項１２に記載のタイムマシン機能提供方法。
【請求項１６】
前記ストリーミングクライアントで、前記タイムマシン制御要求に対する応答として、前記ライブストリームデータが現在放送中であるか否かに関するオンエア情報、および前記ライブストリームデータの最新データを基準としてタイムマシン機能によって現在再生中である過去データを特定する指標である現在シフト時間を、前記タイムマシン制御セッションを通じて前記プレイヤに送信する段階
をさらに含み、
前記プレイヤで、前記オンエア情報および前記現在シフト時間を組み合わせることによって放送終了時点を決める、請求項１２に記載のタイムマシン機能提供方法。
【発明の詳細な説明】
【技術分野】
【０００１】
下記の説明は、生放送でタイムマシン機能を提供する方法およびシステムに関する。
【背景技術】
【０００２】
ライブで提供される映像コンテンツ（一例として、放送プログラム）に対するタイムマシン機能とは、ライブ映像の少なくとも一部を一定時間が経過した後にユーザが任意で視聴できるようにする機能であって、ライブ映像を格納しておき、格納されたライブ映像を再生する方式によって提供される。例えば、特許文献１は、タイムマシン機能を備えた映像表示機器およびその制御方法を開示している。
【０００３】
従来技術において、ストリーミングサービスにおけるタイムマシン機能は、映像コンテンツを再生する電子機器のプレイヤがＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ：ＯＳ）やプラットフォームによって互いに異なるストリーミング規格を使用している。例えば、ＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）のフラッシュプレイヤは、ストリーミングプロトコルとしてＲＴＭＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｍｅｓｓａｇｉｎｇ  Ｐｒｏｔｏｃｏｌ）を使用するし、ｉＯＳ（登録商標）やアンドロイド（登録商標）のプレイヤは、ストリーミングプロトコルとしてＨＬＳ（ＨＴＴＰ  Ｌｉｖｅ  Ｓｔｒｅａｍｉｎｇ）プロトコルを使用する。ここで、従来技術では、タイムマシン機能のための制御セッションを各ストリーミングプロトコル別に実現しなければならないという問題がある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】韓国登録特許第１０−１３００８８２号公報
【特許文献２】国際公開第２０１５／０６５００１号
【特許文献３】米国特許出願公開第２０１４／００１９５４０号明細書
【特許文献４】米国特許出願公開第２０１３／０３３２５４３号明細書
【特許文献５】米国特許出願公開第２０１３／０２６０８９３号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００５】
タイムマシン制御プロトコルがタイムマシン機能を制御する役割だけを担い、ストリーミングクライアントとプレイヤとの間のストリーミングプロトコルは、プレイヤがサポートするストリーミング規格をそのまま利用できるように実現することができる方法およびシステムを提供する。
【０００６】
また、ＯＳやプレイヤに関係なく、同じ規格を利用してタイムマシン機能を制御することができるため、ストリーミングクライアントのプレイヤに対する依存性を除去することができる方法およびシステムを提供する。
【課題を解決するための手段】
【０００７】
電子機器を実現するコンピュータにタイムマシン機能提供方法を実行させるためのコンピュータプログラムであって、前記タイムマシン機能提供方法は、ライブストリーミングサービスを提供するために前記電子機器にインストールされたストリーミングクライアントで、前記電子機器にインストールされたプレイヤとのストリーミングセッションを設定する段階、前記ストリーミングクライアントで、ネットワークを介して受信したライブストリームデータを、前記ストリーミングセッションを通じて順に前記プレイヤに送信する段階、前記ストリーミングクライアントで、前記プレイヤとのタイムマシン制御セッションを設定する段階、前記ストリーミングクライアントで、前記タイムマシン制御セッションを通じて前記プレイヤからタイムマシン制御要求を受信する段階、および前記ストリーミングクライアントで、前記タイムマシン制御要求中に再生位置情報を含むタイムマシン制御要求に対応するチャンネルのライブストリームデータを、前記再生位置情報によって特定される再生位置から順に前記ストリーミングセッションを通じて前記プレイヤに送信する段階を含む、コンピュータプログラムを提供する。
【０００８】
コンピュータによって実現された電子機器のタイムマシン機能提供方法であって、ライブストリーミングサービスを提供するために前記電子機器にインストールされたストリーミングクライアントで、前記電子機器にインストールされたプレイヤとのストリーミングセッションを設定する段階、前記ストリーミングクライアントで、ネットワークを介して受信したライブストリームデータを、前記ストリーミングセッションを通じて順に前記プレイヤに送信する段階、前記ストリーミングクライアントで、前記プレイヤとのタイムマシン制御セッションを設定する段階、前記ストリーミングクライアントで、前記タイムマシン制御セッションを通じて前記プレイヤからタイムマシン制御要求を受信する段階、および前記ストリーミングクライアントで、前記タイムマシン制御要求中に再生位置情報を含むタイムマシン制御要求に対応するチャンネルのライブストリームデータを、前記再生位置情報によって特定される再生位置から順に前記ストリーミングセッションを通じて前記プレイヤに送信する段階を含む、タイムマシン機能提供方法を提供する。
【発明の効果】
【０００９】
タイムマシン制御プロトコルがタイムマシン機能を制御する役割だけを担い、ストリーミングクライアントとプレイヤとの間のストリーミングプロトコルは、プレイヤがサポートするストリーミング規格をそのまま利用できるように実現することができる。
【００１０】
また、ＯＳやプレイヤに関係なく、同じ規格を利用してタイムマシン機能を制御することができるため、ストリーミングクライアントのプレイヤに対する依存性を除去することができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の一実施形態における、ネットワーク環境の例を示した図である。
【図２】本発明の一実施形態における、電子機器およびサーバの内部構成を説明するためのブロック図である。
【図３】本発明の一実施形態における、ライブストリーミングサービスのための全体システム環境の例を示した図である。
【図４】本発明の一実施形態における、制御セッションの認証過程の例を示した図である。
【図５】本発明の一実施形態における、シフト値を説明するための例を示した図である。
【図６】本発明の一実施形態における、初回再生要求および再生終了要求を処理する過程の例を示したフローチャートである。
【図７】本発明の一実施形態における、再生中に探索要求を処理する過程の例を示したフローチャートである。
【図８】本発明の一実施形態における、一時停止要求および再開要求を処理する過程の例を示したフローチャートである。
【図９】本発明の一実施形態における、デリバリサーバの内部構成を説明するための図である。
【図１０】本発明の一実施形態における、タイムマシンバッファの活用例を示した図である。
【図１１】本発明の一実施形態における、タイムマシン機能を利用して探索を行う場合にプレビュー機能を提供する画面の例を示した図である。
【図１２】本発明の一実施形態における、電子機器のプロセッサが含むことのできる構成要素の例を示した図である。
【図１３】本発明の一実施形態における、電子機器が実行することのできるタイムマシン機能提供方法の例を示したフローチャートである。
【発明を実施するための形態】
【００１２】
以下、実施形態について、添付の図面を参照しながら詳しく説明する。
【００１３】
図１は、本発明の一実施形態における、ネットワーク環境の例を示した図である。図１のネットワーク環境は、複数の電子機器１１０、１２０、１３０、１４０、複数のサーバ１５０、１６０、およびネットワーク１７０を含む例を示している。このような図１は、発明の説明のための一例に過ぎず、電子機器の数やサーバの数が図１のように限定されることはない。
【００１４】
複数の電子機器１１０、１２０、１３０、１４０は、コンピュータ装置によって実現される固定端末や移動端末であってよい。複数の電子機器１１０、１２０、１３０、１４０の例としては、スマートフォン、携帯電話、ナビゲーション、コンピュータ、ノート型パンコン、デジタル放送用端末、ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔ）、ＰＭＰ（Ｐｏｒｔａｂｌｅ  Ｍｕｌｔｉｍｅｄｉａ  Ｐｌａｙｅｒ）、タブレットＰＣなどがある。一例として、電子機器１（１１０）は、無線または有線通信方式を利用し、ネットワーク１７０を介して他の電子機器１２０、１３０、１４０および／またはサーバ１５０、１６０と通信してよい。
【００１５】
通信方式が限定されることはなく、ネットワーク１７０が含むことのできる通信網（一例として、移動通信網、有線インターネット、無線インターネット、放送網）を活用する通信方式だけではなく、機器間の近距離無線通信が含まれてもよい。例えば、ネットワーク１７０は、ＰＡＮ（ｐｅｒｓｏｎａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ）、ＬＡＮ（ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ）、ＣＡＮ（ｃａｍｐｕｓ  ａｒｅａ  ｎｅｔｗｏｒｋ）、ＭＡＮ（ｍｅｔｒｏｐｏｌｉｔａｎ  ａｒｅａ  ｎｅｔｗｏｒｋ）、ＷＡＮ（ｗｉｄｅ  ａｒｅａ  ｎｅｔｗｏｒｋ）、ＢＢＮ（ｂｒｏａｄｂａｎｄ  ｎｅｔｗｏｒｋ）、インターネットなどのネットワークのうちの１つ以上の任意のネットワークを含んでもよい。さらに、ネットワーク１７０は、バスネットワーク、スターネットワーク、リングネットワーク、メッシュネットワーク、スター−バスネットワーク、ツリーまたは階層的（ｈｉｅｒａｒｃｈｉｃａｌ）ネットワークなどを含むネットワークトポロジのうちの任意の１つ以上を含んでもよいが、これに限定されることはない。
【００１６】
サーバ１５０、１６０それぞれは、電子機器１１０、１２０、１３０、１４０とネットワーク１７０を介して通信して命令、コード、ファイル、コンテンツ、サービスなどを提供する１つ以上のコンピュータ装置によって実現されてよい。
【００１７】
一例として、サーバ１６０は、ネットワーク１７０を介して接続した電子機器１（１１０）にアプリケーションのインストールのためのファイルを提供してよい。この場合、電子機器１（１１０）は、サーバ１６０から提供されたファイルを利用してアプリケーションをインストールしてよい。また、電子機器１（１１０）が含むオペレーティングシステム（ＯＳ）および少なくとも１つのプログラム（一例として、ブラウザやインストールされたアプリケーション）の制御にしたがってサーバ１５０に接続し、サーバ１５０が提供するサービスやコンテンツの提供を受けてよい。例えば、電子機器１（１１０）が、アプリケーションの制御にしたがってネットワーク１７０を介してサービス要求メッセージをサーバ１５０に送信すると、サーバ１５０は、サービス要求メッセージに対応するコードを電子機器１（１１０）に送信してよく、電子機器１（１１０）は、アプリケーションの制御にしたがってコードに基づく画面を構成して表示することにより、ユーザにコンテンツを提供してよい。他の例として、サーバ１５０は、メッセージングサービスのための通信セッションを設定し、設定された通信セッションを通じて複数の電子機器１１０、１２０、１３０、１４０間のメッセージ送受信をルーティングしてもよい。さらに他の例として、サーバ１５０は、電子機器１１０、１２０、１３０、１４０にソーシャルネットワークサービスを提供してもよい。さらに他の例として、サーバ１５０、１６０は、複数の電子機器１１０、１２０、１３０、１４０にライブストリーミングサービスを提供してもよい。
【００１８】
図２は、本発明の一実施形態における、電子機器およびサーバの内部構成を説明するためのブロック図である。図２では、１つの電子機器に対する例として電子機器１（１１０）の内部構成を、１つのサーバに対する例としてサーバ１５０の内部構成を説明する。他の電子機器１２０、１３０、１４０やサーバ１６０だけでなく、図１を参照しながら説明したネットワーク環境に含まれ得るさらに他の電子機器やさらに他のサーバにも、同一または類似の内部構成要素が適用されてもよい。
【００１９】
電子機器１（１１０）とサーバ１５０は、メモリ２１１、２２１、プロセッサ２１２、２２２、通信モジュール２１３、２２３、および入力／出力インタフェース２１４、２２４を含んでよい。メモリ２１１、２２１は、コンピュータで読み取り可能な記録媒体であって、ＲＡＭ（ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ）、ＲＯＭ（ｒｅａｄ  ｏｎｌｙ  ｍｅｍｏｒｙ）、およびディスクドライブのような永久大容量記憶装置（ｐｅｒｍａｎｅｎｔ  ｍａｓｓ  ｓｔｏｒａｇｅ  ｄｅｖｉｃｅ）を含んでよい。また、メモリ２１１、２２１には、オペレーティングシステムと、少なくとも１つのプログラムコード（一例として、電気機器１（１１０）にインストールされ駆動するブラウザや上述したアプリケーションなどのためのコード）が格納されてよい。このようなソフトウェア構成要素は、ドライブメカニズム（ｄｒｉｖｅ  ｍｅｃｈａｎｉｓｍ）を利用してメモリ２１１、２２１とは別のコンピュータで読み取り可能な記録媒体からロードされてもよい。このような別のコンピュータで読み取り可能な記録媒体は、フロッピー（登録商標）ドライブ、ディスク、テープ、ＤＶＤ／ＣＤ−ＲＯＭドライブ、メモリカードなどのコンピュータで読み取り可能な記録媒体を含んでよい。他の実施形態において、ソフトウェア構成要素は、コンピュータで読み取り可能な記録媒体ではない通信モジュール２１３、２２３を利用してメモリ２１１、２２１にロードされてもよい。例えば、少なくとも１つのプログラムは、開発者またはアプリケーションのインストールファイルを配布するファイル配布システム（一例として、上述したサーバ１６０）がネットワーク１７０を介して提供するファイルによってインストールされるプログラム（一例として、上述したアプリケーション）に基づいてメモリ２１１、２２１にロードされてもよい。
【００２０】
プロセッサ２１２、２２２は、基本的な算術、ロジック、および入出力演算を実行することにより、コンピュータプログラムの命令を処理するように構成されてよい。命令は、メモリ２１１、２２１または通信モジュール２１３、２２３によって、プロセッサ２１２、２２２に提供されてよい。プロセッサ２１２、２２２は、メモリ２１１、２２１のような記録装置に格納されたプログラムコードにしたがって受信される命令を実行するように構成されてよい。
【００２１】
通信モジュール２１３、２２３は、ネットワーク１７０を介して電子機器１（１１０）とサーバ１５０とが互いに通信するための機能を提供してもよいし、他の電子機器（一例として、電子機器２（１２０））または他のサーバ（一例として、サーバ１６０）と通信するための機能を提供してもよい。一例として、電子機器１（１１０）のプロセッサ２１２がメモリ２１１のような記録装置に格納されたプログラムコードにしたがって生成した要求（一例として、コンテンツに対するストリーミングサービス要求）が、通信モジュール２１３の制御にしたがってネットワーク１７０を介してサーバ１５０に伝達されてもよい。これとは逆に、サーバ１５０のプロセッサ２２２の制御にしたがって提供される制御信号や命令、コンテンツ、ファイルなどが、通信モジュール２２３とネットワーク１７０を経て電子機器１（１１０）の通信モジュール２１３を通じて電子機器１（１１０）に受信されてもよい。例えば、通信モジュール２１３を通じて受信されたサーバ１５０の制御信号や命令などは、プロセッサ２１２やメモリ２１１に伝達されてもよく、コンテンツやファイルなどは、電子機器１（１１０）がさらに含むことのできる格納媒体に格納されてもよい。
【００２２】
入力／出力インタフェース２１４、２２４は、入力／出力装置２１５とのインタフェースのための手段であってよい。例えば、入力装置は、キーボードまたはマウスなどの装置を、また出力装置は、アプリケーションの通信セッションを表示するためのディスプレイのような装置を含んでよい。他の例として、入力／出力インタフェース２１４は、タッチスクリーンのように入力と出力のための機能が１つに統合された装置とのインタフェースのための手段であってもよい。より具体的な例として、電子機器１（１１０）のプロセッサ２１２は、メモリ２１１にロードされたコンピュータプログラムの命令を処理するにあたり、サーバ１５０や電子機器２（１２０）が提供するデータを利用して構成されるサービス画面２１５やコンテンツが、入力／出力インタフェース２１４を通じてディスプレイに表示されてもよい。
【００２３】
また、他の実施形態において、電子機器１（１１０）とサーバ１５０は、図２の構成要素よりも多くの構成要素を含んでもよい。しかし、大部分の従来技術的構成要素を明確に図に示す必要はない。例えば、電子機器１（１１０）は、上述した入力／出力装置２１５のうち少なくとも一部を含むように実現されてもよいし、トランシーバ、ＧＰＳ（Ｇｌｏｂａｌ  Ｐｏｓｉｔｉｏｎｉｎｇ  Ｓｙｓｔｅｍ）モジュール、カメラ、各種センサ、データベースなどのような他の構成要素をさらに含んでもよい。
【００２４】
図３は、本発明の一実施形態における、ライブストリーミングサービスのための全体システム環境の例を示した図である。図３は、メディアストリーミングサーバ３１０、パケット化サーバ３２０、デリバリサーバ３３０、インデックスサーバ３４０、電子機器３５０、および複数のピア３６０を示している。
【００２５】
メディアストリーミングサーバ３１０、パケット化サーバ３２０、デリバリサーバ３３０、およびインデックスサーバ３４０それぞれは、図１および図２を参照しながら説明したサーバ１５０と同一または類似の内部構成要素を備える装置であってよい。また、複数のピア３６０それぞれと電子機器３５０は、図１および図２を参照しながら説明した電子機器１（１１０）と同一または類似の内部構成要素を備える装置であってよい。図３では、メディアストリーミングサーバ３１０、パケット化サーバ３２０、デリバリサーバ３３０、およびインデックスサーバ３４０をそれぞれ１つずつ示しているが、それぞれ複数のサーバグループの形態で実現されてもよい。例えば、プロ野球の試合を生放送するにあたり４つの試合が行われる場合、４つの試合に対して４つのメディアソースのための４つのメディアストリーミングサーバのグループが存在してもよく、それぞれのメディアソースのために４つのパケット化サーバのグループが存在してもよい。これと同様に、デリバリサーバ３３０およびインデックスサーバ３４０も、必要に応じて複数のサーバグループで実現されてもよい。例えば、デリバリサーバ３３０およびインデックスサーバ３４０は、同時接続者数のような性能イシューによって求められるサーバの数が決められてもよい。
【００２６】
メディアストリーミングサーバ３１０は、ライブストリームデータを提供するエンコーダ（図示せず）を含むメディアソース装置であってよい。パケット化サーバ３２０は、このようなメディアストリーミングサーバ３１０からライブストリームデータを受信してよく、受信したライブストリームデータをＰ２Ｐサービスで提供するために、受信したライブストリームデータをピース（ｐｉｅｃｅ）にパケット化（またはインデクシング）してよい。ストリームデータをピースにパケット化（またはインデクシング）する方法は、周知の多様な方法のうちの１つを利用してよい。
【００２７】
デリバリサーバ３３０は、パケット化サーバ３２０からパケット化された（またはインデクシングされた）ピースを受信し、これをバッファリングしてよく、Ｐ２Ｐサービスのピア（ｐｅｅｒ）からの要求に応じ、要求されたライブストリームデータに対するピースを該当のピアに送信してよい。ここで、ピアとは、Ｐ２Ｐサービスを利用するライブストリーミングサービスのクライアントを意味してよく、それぞれ１つの電子機器で実現されてよい。ピアを実現する電子機器は、図３に示す電子機器３５０を含み、上述したように図１および図２を参照しながら説明した電子機器１（１１０）と同一または類似の内部構成要素を備える装置であってよい。
【００２８】
インデックスサーバ３４０は、ピアのリストを保持し、ピアの要求に応じた検索結果を提供してよい。
【００２９】
ピアを実現する電子機器３５０では、ストリーミングクライアント３５１のようなアプリケーションがインストールおよび駆動されてよい。ここで、電子機器３５０は、駆動するストリーミングクライアント３５１の制御にしたがい、デリバリサーバ３３０からピースを受信してもよいし、他のピア（図３の複数のピア３６０）を実現する他の電子機器からピースを受信してもよい。
【００３０】
また、電子機器３５０で駆動するストリーミングクライアント３５１は、電子機器３５０でインストールおよび駆動される他のアプリケーションであるプレイヤ３５２と電子機器３５０で内部的に通信し、プレイヤ３５２にライブストリームデータを送信してよい。ここで、ストリーミングクライアント３５１がプレイヤ３５２に提供するライブストリームデータは、デリバリサーバ３３０または複数のピア３６０の少なくとも一部から受信したピースに基づいて組み合わされたデータであってよい。
【００３１】
この場合、プレイヤ３５２は、ストリーミングクライアント３５１が提供するライブストリームデータを再生してよく、これにより、メディアストリーミングサーバ３１０が提供するライブストリームデータが電子機器３５０で再生され、電子機器３５０のユーザに提供されてよい。
【００３２】
１．タイムマシン機能の概要
ピアを実現する電子機器（一例として、図３の電子機器３５０）でインストールおよび駆動されるストリーミングクライアント（一例として、図３のストリーミングクライアント３５１）は、電子機器のユーザにライブストリームデータに対するタイムマシン機能を提供してよい。上述したように、従来技術では、各ストリーミングプロトコル別にタイムマシン機能のための制御セッションを実現しなければならなかったのに対し、本発明の実施形態では、タイムマシン制御プロトコルがタイムマシン機能を制御する役割だけを担い、ストリーミングクライアントとプレイヤとの間のストリーミングプロトコルは、プレイヤがサポートするストリーミング規格をそのまま利用できるように実現することができる。このような実施形態により、ＯＳやプレイヤに関係なく、同じ規格を利用してタイムマシン機能を制御することができるため、ストリーミングクライアントのプレイヤに対する依存性を除去することができる。プレイヤでタイムマシン制御プロトコルがサポートされない場合、ユーザは、プレイヤを利用しながら、既存のプレイヤが使用しているストリーミングプロトコルを利用してライブ映像だけを視聴することができる。
【００３３】
２．用語の整理
ストリーミングクライアントは、ライブストリーミングサービスで利用されるアプリケーションであって、図３では、電子機器３５０に含まれるストリーミングクライアント３５１を例示しているが、上述したように、実際には、本発明の実施形態に係るライブストリーミングサービスの提供を受けようとするピアそれぞれでインストールおよび駆動されてよい。
【００３４】
タイムマシン機能のための制御セッションとは、ライブストリームデータを提供するためのストリーミングセッションとは別に、プレイヤ３５２とストリーミングクライアント３５１との間に結ばれる論理的な接続を意味してよい。プレイヤ３５２とストリーミングクライアント３５１との間のＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）接続とは関係がなく、ＴＣＰ接続が切れたとしても制御セッション接続が切れることはなく、これとは逆に、ＴＣＰ接続が続いている間でも、以下で詳細に説明されるチャンネルに対する要求がない場合には、制御セッション接続が切れるように実現されてもよい。
【００３５】
シフト（以下、「ｓｈｉｆｔ」）は、タイムマシン機能を利用するにあたり、過去のデータをどのくらい再生するかに対する相対的な指標として使用される。ｓｈｉｆｔの値は、最新ライブ映像を０とし、０よりも大きければ過去に移動したことを示してよく、ｓｈｉｆｔの値が大きいほど相対的にさらに過去の映像を再生していることを意味してよい。ｓｈｉｆｔの値の単位は、一例としてミリ秒（ｍｓｅｃ）を利用してもよい。
【００３６】
最大シフト可能時間（ｍａｘ  ｓｈｉｆｔ、以下「ｍｓｈｉｆｔ」）は、放送に対して設定されたタイムマシンが可能な最大時間を示す指標として使用される。最大シフト可能時間のｍｓｈｉｆｔの値が大きい放送であるほど、相対的に長いタイムマシン映像データを提供できることを意味してよい。
【００３７】
現在シフト可能時間（ａｖａｉｌａｂｌｅ  ｓｈｉｆｔ、以下、「ａｓｈｉｆｔ」）とは、ユーザが過去の映像を巻き戻して見ることのできる最大時間を意味する指標であってよい。
【００３８】
現在シフト時間（ｃｕｒｒｅｎｔ  ｓｈｉｆｔ、以下、「ｃｓｈｉｆｔ」）とは、現時点でユーザが過去の映像をどのくらい再生しているかを示す指標であってよい。
【００３９】
このようなｓｈｉｆｔ、ｍｓｈｉｆｔ、ａｓｈｉｆｔ、およびｃｓｈｉｆｔについては、以下でさらに詳しく説明する。
【００４０】
３．タイムマシン制御セッションの基本情報
３．１．メッセージ認証
メッセージを交換するための制御セッションを使用するためには認証が求められる。プレイヤは制御セッションを開始するために認証要求（「／ａｕｔｈ」）をストリーミングクライアントに送信し、ストリーミングクライアントで認証が成功すれば、ストリーミングクライアントは認証要求に対する応答として該当のプレイヤで使用するキー（ｋｅｙ）情報を送信する。ここで、キー情報は、「／ａｕｔｈ」要求の応答にだけ含まれてもよい。このキーは、プレイヤがストリーミングクライアントに送信する次のタイムマシン制御要求にパラメータの形態で含まれてもよい。例えば、キーは、「ｋ＝」ｑｕｅｒｙのような文字列の形態で含まれてストリーミングされてもよい。ここで、「ｋ＝」ｑｕｅｒｙ文字列が間違っていたり、このｑｕｅｒｙ文字列がなかったりする場合、ストリーミングクライアントは、認証されなかったことを知らせるための応答（一例として、ＨＴＴＰにおける４０１応答コード）をプレイヤに送信する。このキーは、該当のプレイヤで映像が再生され続ける間だけ有効となり、他のプレイヤで同じチャンネルに対して接続要求が発生したときには無効となってもよい。ここで、無効となったセッションから受け取った要求に対し、ストリーミングクライアントは、認証されなかったことを知らせるための応答（一例として、ＨＴＴＰにおける４０１応答コード）を送信してもよい。この条件は、互いに異なるブラウザから同じチャンネルに接続したり、同じブラウザ内の他のウィンドウから同じチャンネルに接続したりしても、同じチャンネルに対する要求に対して同じように適用されてもよい。ここで、各プレイヤが他のチャンネルに接続する場合には適用されなくてもよい。ｑｕｅｒｙ文字列の順序が変わっても問題はない。
【００４１】
図４は、本発明の一実施形態における、制御セッションの認証過程の例を示した図である。図４は、ストリーミングクライアント４１０、プレイヤ１（４２０）、およびプレイヤ２（４３０）を示している。一例として、ストリーミングクライアント４１０、プレイヤ１（４２０）、およびプレイヤ２（４３０）は、１つの電子機器でインストールおよび駆動されるそれぞれのアプリケーションであってよい。
【００４２】
第１点線ボックス４４１は、プレイヤ１（４２０）がストリーミングクライアント４１０に認証要求（／ａｕｔｈ）をし、ストリーミングクライアント４１０がプレイヤ１（４２０）を認証することにより、応答（ＨＴＴＰにおける２００  ＯＫ応答コード）と共にキー＜ｋｅｙ１＞をプレイヤ１（４２０）に送信する過程を示している。認証要求（／ａｕｔｈ）については、以下でさらに詳しく説明する。キー情報として示された｛“ｋｅｙ”：＜ｋｅｙ１＞｝は、キーとして＜ｋｅｙ１＞が提供されることを意味してよい。
【００４３】
第２点線ボックス４４２は、プレイヤ１（４２０）が取得したキー（＜ｋｅｙ１＞）を利用してストリーミングクライアント４１０に再生要求（／ｐｌａｙ）をし、ストリーミングクライアント４１０がプレイヤ１（４２０）に応答（ＨＴＴＰにおける２００  ＯＫ応答コード）を送信する過程を示している。このように、プレイヤ１（４２０）は、認証要求（／ａｕｔｈ）によって取得したキー（＜ｋｅｙ１＞）を利用してタイムマシン機能のための制御要求をストリーミングクライアント４１０に送信してよく、ストリーミングクライアント４１０は、ストリーミングクライアント４１０が発給したキー（＜ｋｅｙ１＞）を利用してプレイヤ１（４２０）の制御要求を認証してよい。
【００４４】
第３点線ボックス４４３は、プレイヤ２（４３０）がストリーミングクライアント４１０に認証要求（／ａｕｔｈ）をし、ストリーミングクライアント４１０がプレイヤ２（４３０）を認証することにより、応答（ＨＴＴＰにおける２００  ＯＫ応答コード）と共にキー＜ｋｅｙ２＞をプレイヤ２（４３０）に送信する過程を示している。上述したように、他のプレイヤから同じチャンネルに対して接続要求が発生したため、先に発給されたキー＜ｋｅｙ１＞は無効となってよい。
【００４５】
第４点線ボックス４４４は、プレイヤ１（４２０）がキー＜ｋｅｙ１＞を利用して探索要求（／ｓｅｅｋ）をストリーミングクライアント４１０に送信する例を示している。ここで、キー＜ｋｅｙ１＞は、プレイヤ２（４３０）のキー＜ｋｅｙ２＞の発給によって無効となったため、ストリーミングクライアント４１０は、探索要求（／ｓｅｅｋ）に対して認証されなかったことを示す応答（ＨＴＴＰにおける４０１応答コード）をプレイヤ１（４２０）に送信してよい。探索要求（／ｓｅｅｋ）については、以下でさらに詳しく説明する。
【００４６】
第５点線ボックス４４５は、プレイヤ２（４３０）がキー＜ｋｅｙ２＞を利用して探索要求（／ｓｅｅｋ）をストリーミングクライアント４１０に送信する例を示している。キー＜ｋｅｙ２＞はまだ有効であるため、ストリーミングクライアント４１０は、プレイヤ２（４３０）の探索要求（／ｓｅｅｋ）を処理することによる応答（ＨＴＴＰにおける２００  ＯＫ応答コード）をプレイヤ２（４３０）に送信してよい。
【００４７】
第６点線ボックス４４６は、プレイヤ１（４２０）が再びキー＜ｋｅｙ１＞を利用して情報取得およびセッション維持要求（／ｍａｘｓｈｉｆｔ）をストリーミングクライアント４１０に送信する例を示している。キー＜ｋｅｙ１＞はプレイヤ２（４３０）のキー＜ｋｅｙ２＞の発給によって無効となったため、ストリーミングクライアント４１０は、情報取得およびセッション維持要求（／ｍａｘｓｈｉｆｔ）に対して認証されなかったことを示す応答（ＨＴＴＰにおける４０１応答コード）をプレイヤ１（４２０）に送信してよい。情報取得およびセッション維持要求（／ｍａｘｓｈｉｆｔ）については、以下でさらに詳しく説明する。
【００４８】
３．２．セッション維持
ブラウザ（またはプレイヤ）とストリーミングクライアントとの間のＴＣＰ接続は、いつでも終了されてよい（例えば、ＨＴＴＰ  １．０）。言い換えれば、ＴＣＰ接続は継続して維持されるものではないため、ユーザが該当のチャンネルを継続して使用しているか否かをストリーミングクライアントが把握できるように、プレイヤは一定時間内にユーザが見ているチャンネルに対するタイムマシン制御要求をストリーミングクライアントに送信しなければならない。このようなセッション維持（およびタイムマシン制御セッションの情報取得）のために情報取得およびセッション維持要求（／ｍａｘｓｈｉｆｔ）が利用されてよい。／ｍａｘｓｈｉｆｔは、認証が成功した後、ユーザがチャンネルを介してストリームデータを視聴している間、タイムマシン制御セッションの情報を取得するためにいつでも呼び出されてよい。ここで、／ｍａｘｓｈｉｆｔもタイムマシン制御要求の１つであり、／ｍａｘｓｈｉｆｔの送信により、ストリーミングクライアントは該当のプレイヤとのセッションを維持してよい。タイムマシンの制御セッションは、予め設定された最大有効時間を有してよい。したがって、ストリーミングクライアントは、予め設定された最大有効時間中に該当のプレイヤからタイムマシン制御要求が何も受信されない場合には、タイムマシン制御セッションを終了してよい。したがって、プレイヤは、タイムマシン制御セッションの維持のために、最大有効時間よりも短い呼び出し間隔で／ｍａｘｓｈｉｆｔをストリーミングクライアントに送信してよい。
【００４９】
３．３．ＨＴＴＰ  ｑｕｅｒｙ文字列
タイムマシン制御要求それぞれは、タイムマシン制御セッションの認証のために、要求と共にｑｕｅｒｙ文字列が追加されてもよい。ｑｕｅｒｙ文字列は、下記の表１のように定義されてよい。
【００５０】
【表１】
0006490654.tif 000002
【００５１】
すべてのタイムマシン制御要求はｒｅｆ  ｑｕｅｒｙ文字列を含んでよく、ｒｅｆ  ｑｕｅｒｙ文字列が含まれない要求はすべて、認証されない要求として見なされてよい。また、認証要求（／ａｕｔｈ）を除いたすべてのタイムマシン制御要求はｋ  ｑｕｅｒｙ文字列を含んでよく、ｋ  ｑｕｅｒｙ文字列が含まれない要求はすべて、認証されない要求として見なされてよい。ｋ  ｑｕｅｒｙ文字列の値は、認証要求（／ａｕｔｈ）に対する成功応答に含まれ、プレイヤに送信されるキー値を含んでよく、他のキー値（有効ではないキー値）が含まれるタイムマシン制御要求も認証されない要求として見なされてよい。
【００５２】
４．制御のためのメッセージ
上述したタイムマシン制御要求としてプレイヤからストリーミングクライアントに送信されるメッセージは、ＨＴＴＰを利用してよい。すべてのメッセージは、上述したように、現在再生しているＵＲＬ情報を明示したｒｅｆ  ｑｕｅｒｙ文字列を含んでよい。また、認証要求（／ａｕｔｈ）メッセージ以外のすべてのメッセージは、認証要求（／ａｕｔｈ）に対する成功応答に含まれ、送信されるキー値を明示したｋ  ｑｕｅｒｙ文字列をさらに含んでもよい。ｑｕｅｒｙ文字列が含まれない要求メッセージは、不適切な要求（認証されない要求）として見なされてよい。再生と関連のある応答は、２００  ＯＫメッセージの内容にＪＳＯＮフォーマットを利用してストリーミングクライアントからプレイヤに送信されてよい。再生終了要求（／ｓｔｏｐ）を除いた他の要求に対する結果確認は、ストリーミングクライアントが送信する応答の内容を確認しなければならない。
【００５３】
４．１．メッセージの概括
タイムマシン制御要求のためにプレイヤからストリーミングクライアントに送信されるメッセージ（要求）は、下記の表２のように定義されてよい。
【００５４】
【表２】
0006490654.tif 000003
【００５５】
４．２．接続認証（／ａｕｔｈ）
認証要求（／ａｕｔｈ）は、上述したように、タイムマシン機能を使用するために初めて接続を結ぶときにプレイヤが送信する要求であって、ストリーミングクライアントは、認証要求（／ａｕｔｈ）を送信するプレイヤが適切なプレイヤであるかを確認するために、認証要求（／ａｕｔｈ）に追加されたパラメータを利用してよい。認証要求（／ａｕｔｈ）は、プレイヤからストリーミングクライアントに接続を結ぶ１つのタイムマシン制御セッションに対して初回に１度だけ送信されてよい。
【００５６】
認証要求は、下記の表３のように定義されてよい。
【００５７】
【表３】
0006490654.tif 000004
【００５８】
認証キー（ａｕｔｈＫｅｙ）生成方式の例示：ｒｅｆ  ｑｕｅｒｙ文字列に明示した「代表ＵＲＬ」のＳＨＡ−１（Ｓｅｃｕｒｅ  Ｈａｓｈ  Ａｌｇｏｒｉｔｈｍ  １）返り値をベース６４（ｂａｓｅ  ６４）のエンコード方法によってエンコードした値を認証キーとして生成。ここで、ベース６４で使用する「：」、「＝」、「／」は、ＵＲＬ  ｑｕｅｒｙで使用する「：」、「＝」、「／」と区別するために、それぞれＵＲＬエンコードした「％３Ａ」、「％３Ｄ」、「％２Ｆ」に変更して使用する。
【００５９】
より具体的な例として、プレイヤで「ＵＲＬ：／／１２７．０．０．１：７０８５／ｌｉｖｅ？ｃｉｄ＝４９」に接続しようとする場合、認証キー（ａｕｔｈＫｅｙ）は、次のような過程によって生成されてよい。
【００６０】
１．ＳＨＡ−１（Ｓｅｃｕｒｅ  Ｈａｓｈ  Ａｌｇｏｒｉｔｈｍ  １）を利用してＵＲＬのハッシュ値を生成（１６進数）：ＥＡ  Ｂ０  ＡＣ  ＡＤ  ３４  Ｆ２  ８６  Ｂ２  ０Ｆ  Ｂ１  ５８  ５４  ３３  ＡＡ  Ｄ９  ６９  ４Ｅ  ７Ｆ  ５Ｃ  ２４
（この値は参照値であり、該当の文字列をエンコードするのではなく、バイナリ値をベース６４のエンコード方法によってエンコード。）
２．ベース６４のエンコード方法によってエンコード：６ｒＣｓｒＴＴｙｈｒＩＰｓＶｈＵＭ６ｒＺａＵ５／ＸＣＱ＝
３．認証キー（ａｕｔｈＫｅｙ）：６ｒＣｓｒＴＴｙｈｒＩＰｓＶｈＵＭ６ｒＺａＵ５％２ＦＸＣＱ％３Ｄ
（「／」、「＝」をそれぞれ「％２Ｆ」、「％３Ｄ」に変更。）
【００６１】
このように、認証要求（／ａｕｔｈ）のための認証キー（ａｕｔｈＫｅｙ）は「６ｒＣｓｒＴＴｙｈｒＩＰｓＶｈＵＭ６ｒＺａＵ５％２ＦＸＣＱ％３Ｄ」となり、実際の要求は下記の表４のように生成されてよい。
【００６２】
【表４】
0006490654.tif 000005
【００６３】
認証要求（／ａｕｔｈ）が成功した場合、ストリーミングクライアントの応答は、下記の表５のように示されてよい。
【００６４】
【表５】
0006490654.tif 000006
【００６５】
表５のキー（ｋｅｙ）は、ストリーミングクライアントが該当のタイムマシン制御セッションに対して付与した固有値であり、クライアント（プレイヤ）で認証のためにストリーミングクライアントに送信する認証キー（ａｕｔｈＫｅｙ）とは異なるキー（他の値）である。
【００６６】
認証要求（／ａｕｔｈ）が失敗した場合、ストリーミングクライアントは、別途のメッセージ内容なく、「４０１  Ｕｎａｕｔｈｏｒｉｚｅｄ」応答コードをプレイヤに送信してよい。
【００６７】
認証要求（／ａｕｔｈ）が成功した場合、ストリーミングクライアントの応答メッセージには｛“ｋｅｙ”：“１２３４５６７８”｝のようにキーの値が含まれてよい。“１２３４５６７８”は文字列であってもよい。キーを受信したプレイヤのその後の要求は、一例として下記の表６のような形態であってもよい。
【００６８】
【表６】
0006490654.tif 000007
【００６９】
４．３．提供可能な最大タイムマシン時間情報要求およびＨＴＴＰセッション維持
プレイヤは、情報取得およびセッション維持要求（／ｍａｘｓｈｉｆｔ）に応じ、ストリーミングクライアントで提供することのできるタイムマシン最大時間情報を読み込んでよい。ストリーミングクライアントは現在状態だけに応答してもよく、ストリーミングクライアントの状態変化（タイムマシン機能オン（ｏｎ）状態／タイムマシン機能オフ（ｏｆｆ）状態）はない。上述したように、／ｍａｘｓｈｉｆｔは、再生要求（／ｐｌａｙ）に対する成功応答を受け取った後、制御セッションを維持するためにいつでも呼び出されてよい。
【００７０】
情報取得およびセッション維持要求（／ｍａｘｓｈｉｆｔ）は、下記の表７のように定義されてよい。
【００７１】
【表７】
0006490654.tif 000008
【００７２】
情報取得およびセッション維持要求（／ｍａｘｓｈｉｆｔ）の成功時にストリーミングクライアントが送信する応答が含むことのできる情報は、下記の表８のように定義されてよい。
【００７３】
【表８】
0006490654.tif 000009
【００７４】
例えば、最大シフト可能時間が５分であり、ストリーミングクライアントで３分シフトされたデータを送信している場合、情報取得およびセッション維持要求（／ｍａｘｓｈｉｆｔ）の成功によるストリーミングクライアントの応答は、下記の内容を含んでよい。
【００７５】
｛“ｒｅｓｕｌｔ”：“ｓｕｃｃｅｓｓ”、“ｍｓｈｉｆｔ”：３０００００、“ａｓｈｉｆｔ”：２０００００、“ｃｓｈｉｆｔ”：１８００００｝
【００７６】
また、情報取得およびセッション維持要求（／ｍａｘｓｈｉｆｔ）の失敗時にストリーミングクライアントが送信する応答が含むことのできる情報は、下記の表９のように定義されてよい。
【００７７】
【表９】
0006490654.tif 000010
【００７８】
例えば、情報取得およびセッション維持要求（／ｍａｘｓｈｉｆｔ）が失敗し、エラーコードが３である場合、ストリーミングクライアントの応答は下記の内容を含んでよい。
【００７９】
｛“ｒｅｓｕｌｔ”：“ｆａｉｌ”、“ｅｒｒｏｒ”：３｝
【００８０】
４．４．タイムマシンアクティブ化状態の変更
ユーザが任意にタイムマシン機能の使用状態を変更してもよい。例えば、タイムマシン機能の使用が可能なリアルタイム生放送を見ている途中にディスクの容量問題が発生したとき、ユーザは任意にタイムマシン機能を非アクティブ化させ、これ以上のタイムマシン情報を記録しないようにしてもよい。タイムマシン機能が非アクティブ化した場合、ユーザは、タイムマシン機能をこれ以上使用することができない。しかし、プレイヤでは、情報取得およびセッション維持要求（／ｍａｘｓｈｉｆｔ）を呼び出し続けてもよい。
【００８１】
タイムマシン機能に対する状態変更要求（／ｃｈａｎｇｅ）は、下記の表１０のように定義されてよい。
【００８２】
【表１０】
0006490654.tif 000011
【００８３】
状態変更要求（／ｃｈａｎｇｅ）が成功した場合、ストリーミングクライアントは、別途のメッセージ内容なく、２００  ＯＫのような応答コードをプレイヤに送信してよい。また、状態変更要求（／ｃｈａｎｇｅ）が失敗した場合、ストリーミングクライアントは、別途のメッセージ内容なく、５００  Ｉｎｔｅｒｎａｌ  Ｓｅｒｖｅｒ  Ｅｒｒｏｒのような応答コードをプレイヤに送信してよい。
【００８４】
４．５．再生要求
再生要求（／ｐｌａｙ）は、プレイヤがストリーミングクライアントにライブストリームデータの再生開始を要求するときに送信されてよい。ストリーミングクライアントで再生要求（／ｐｌａｙ）を受信すると、ストリーミングクライアントは、該当の放送（再生要求（／ｐｌａｙ）に含まれるＵＲＬに対応する放送）の最新ライブストリームデータをプレイヤに送信して該当の放送が再生されるようにしてよい。ユーザがチャンネルを変えた場合にも、再生要求（／ｐｌａｙ）は、チャンネルが変わったことをストリーミングクライアントに知らせるために使用されてよく、ストリーミングクライアントは、変えられたチャンネルの放送（新たな再生要求（／ｐｌａｙ）のＵＲＬに対応する放送）の最新ライブストリームデータをプレイヤに送信し、該当の放送が再生されるようにしてよい。放送キーは、ライブストリーミングサービスのプラットフォームで発給した放送キーであってよい。タイムマシン機能を使用した再生のためにも、再生要求（／ｐｌａｙ）がストリーミングクライアントに送信されてもよい。
【００８５】
再生要求（／ｐｌａｙ）は、下記の表１１のように定義されてよい。
【００８６】
【表１１】
0006490654.tif 000012
【００８７】
再生要求（／ｐｌａｙ）に対する成功時に応答が含むことのできる情報は、下記の表１２のように定義されてよい。
【００８８】
【表１２】
0006490654.tif 000013
【００８９】
再生要求（／ｐｌａｙ）に対する失敗時に応答が含むことのできる情報は、下記の表１３のように定義されてよい。
【００９０】
【表１３】
0006490654.tif 000014
【００９１】
初めてライブストリーミングを開始するときにプレイヤが再生要求（／ｐｌａｙ）を送信する場合、最大シフト可能時間に関する情報を得るための動作により応答が少し遅れることがある。再生要求（／ｐｌａｙ）を送信せず、ストリーミングプロトコルを利用して再生要求を送信する場合、ストリーミングクライアントは、タイムマシン機能を使用しない放送として見なされ、常に最新ライブ放送を再生してよく、その後に入ってくるタイムマシン制御要求はすべて無視してよい。
【００９２】
４．６．以前に停止した位置から再生
ストリーミングクライアントは、一時停止要求（／ｐａｕｓｅ）が受信されると、現在まで再生した位置（または、現在までプレイヤに送信した位置）を記憶（格納および管理）してよい。この位置情報は、ストリーミングクライアントが終了するか、タイムマシン制御セッションが切れない限り継続して維持されてよい。再開要求（／ｒｅｓｕｍｅ）は、ストリーミングクライアントが記憶している位置から再生を開始するように要求するために、プレイヤからストリーミングクライアントに送信されてよい。
【００９３】
再開要求（／ｒｅｓｕｍｅ）は、下記の表１４のように定義されてよい。
【００９４】
【表１４】
0006490654.tif 000015
【００９５】
再開要求（／ｒｅｓｕｍｅ）に対する成功時に応答が含むことのできる情報は、下記の表１５のように定義されてよい。
【００９６】
【表１５】
0006490654.tif 000016
【００９７】
再開要求（／ｒｅｓｕｍｅ）に対する失敗時に応答が含むことのできる情報は、下記の表１６のように定義されてよい。
【００９８】
【表１６】
0006490654.tif 000017
【００９９】
４．７．再生位置の移動
タイムマシン機能を使用するために、ストリーミングクライアントに現在再生位置を移動するように要求するために探索要求（／ｓｅｅｋ）が使用されてよい。探索要求メッセージは、再生や一時停止状態に関係なく送信可能であり、探索要求（／ｓｅｅｋ）の受信後にも再生や一時停止状態は同じように維持されてよい。言い換えれば、ストリーミングクライアントは、再生途中に探索要求（／ｓｅｅｋ）を受信した場合、再生位置を移動した後に移動した位置から継続して再生してよい。また、ストリーミングクライアントは、一時停止状態で探索要求（／ｓｅｅｋ）を受信した場合、再生位置を移動した後に一時停止状態を継続して維持してよい。タイムマシン機能を利用した再生を開始した後の再生位置変更は、探索要求（／ｓｅｅｋ）によって行われてよい。
【０１００】
探索要求（／ｓｅｅｋ）は、下記の表１７のように定義されてよい。
【０１０１】
【表１７】
0006490654.tif 000018
【０１０２】
探索要求（／ｓｅｅｋ）に対する成功時に応答が含むことのできる情報は、下記の表１８のように定義されてよい。
【０１０３】
【表１８】
0006490654.tif 000019
【０１０４】
探索要求（／ｓｅｅｋ）に対する失敗時に応答が含むことのできる情報は、下記の表１９のように定義されてよい。
【０１０５】
【表１９】
0006490654.tif 000020
【０１０６】
４．８．一時停止
一時停止要求（／ｐａｕｓｅ）は、現在ストリーミングクライアントが送信している位置で再生を一時的に停止するために利用されてよい。ストリーミングクライアントは、タイムマシン機能のための制御セッションが終わらない限りこの位置を記憶し、再開要求（／ｒｅｓｕｍｅ）に応じて記憶された位置からまた再生を開始してよい。
【０１０７】
一時停止要求（／ｐａｕｓｅ）は、下記の表２０のように定義されてよい。
【０１０８】
【表２０】
0006490654.tif 000021
【０１０９】
一時停止要求（／ｐａｕｓｅ）に対する成功時に応答が含むことのできる情報は、下記の表２１のように定義されてよい。
【０１１０】
【表２１】
0006490654.tif 000022
【０１１１】
一時停止要求（／ｐａｕｓｅ）に対する失敗時に応答が含むことのできる情報は、下記の表２２のように定義されてよい。
【０１１２】
【表２２】
0006490654.tif 000023
【０１１３】
４．９．セッション終了
プレイヤを終了する場合、ストリーミングクライアントですべての情報を削除するように再生終了要求（／ｓｔｏｐ）が利用されてよい。
【０１１４】
再生終了要求（／ｓｔｏｐ）は、下記の表２３のように定義されてよい。
【０１１５】
【表２３】
0006490654.tif 000024
【０１１６】
ストリーミングクライアントは、再生終了要求（／ｓｔｏｐ）による成功／失敗とは関係なく、内容なしで２００  ＯＫ応答コードをプレイヤに送信してよい。
【０１１７】
図５は、本発明の一実施形態における、シフト値を説明するための例を示した図である。図５は、放送のタイムマシン時間であって、最大シフト可能時間が５分に設定され、放送が始まってから４分が経過した状態でユーザが１分前映像を見ている場合に、タイムマシン制御要求の結果値によって伝達される最大シフト可能時間（ｍｓｈｉｆｔ）、現在シフト可能時間（ａｓｈｉｆｔ）、および現在シフト時間（ｃｓｈｉｆｔ）の関係を示している。
【０１１８】
最大シフト可能時間（ｍｓｈｉｆｔ）は、放送に対して設定されたタイムマシン可能時間であって、本例示では５分に固定されている。ここで、最大シフト可能時間（ｍｓｈｉｆｔ）は５分であるが、放送開始後の経過時間が４分であり、５分よりも短いことから、４分以上のタイムマシン機能は提供され得ない。このように、最大シフト可能時間とは別に、現時点でのシフト可能時間を知らせるために現在シフト可能時間（ａｓｈｉｆｔ）が利用されてよい。言い換えれば、現在シフト可能時間（ａｓｈｉｆｔ）とは、ストリーミングクライアントが現在提供することのできるタイムマシン可能時間の最大時間を示してよく、現在シフト可能時間（ａｓｈｉｆｔ）よりもさらに過去の放送を提供することはできない。放送開始後の経過時間がタイムマシン可能時間よりも長い場合、最大シフト可能時間（ｍｓｈｉｆｔ）と現在シフト可能時間（ａｓｈｉｆｔ）の値は等しくなる。また、現在シフト時間（ｃｓｈｉｆｔ）が１分であるというのは、ユーザが最新ライブに比べて１分前の映像を見ていることを示してよい。現在シフト時間（ｃｓｈｉｆｔ）は、最新ライブ放送が進行中であり、ユーザが再生位置を移動しない限り変わらない。言い換えれば、図５においてユーザは、実際の放送時点とは継続して１分の時間差を置いて映像を見るようになる。
【０１１９】
６．放送終了処理
生放送中の放送が終了したとき、ユーザがタイムマシンを利用して過去の映像を見ている状態でプレイヤが即時に放送終了処理をする場合、ユーザは、最後の中継映像を見ることができなくなる。例えば、ユーザが、図５において、実際の放送時点と１分の時間差を置いて映像を見ている状態で、生放送中の放送が終了することにより、プレイヤが即時に放送終了処理をすると、ユーザは最後の１分間の映像を見ることができなくなる。したがって、実際の放送が終了した後でも放送終了処理を一定時間遅らせる必要がある。
【０１２０】
タイムマシン制御セッションでは、タイムマシン制御要求に対する応答に「ｏｎａｉｒ」を含み、「ｏｎａｉｒ」の値と「ｃｓｈｉｆｔ」とを組み合わせることによって放送終了時点に関する情報を提供してよい。
【０１２１】
−放送進行中のタイムマシン情報
放送進行中の「ｏｎａｉｒ」値は１であり、ユーザがタイムマシンを利用してシフトされた映像を見ている場合、「ｃｓｈｉｆｔ」値はユーザが過去に移動した時間を示し、０よりも大きい値を返すようになる。また、放送中「ｃｓｈｉｆｔ」値は、ユーザが過去に移動した時間を固定値によって返す。
【０１２２】
−放送終了時のタイムマシン情報
放送が終了した場合、「ｏｎａｉｒ」値は０であり、再生が進むほど「ｃｓｈｉｆｔ」値は次第に０に減るようになる。この値が０になれば、放送が終了した時点の映像までの送信が完了したことを意味する。したがって、「ｏｎａｉｒ」値と「ｃｓｈｉｆｔ」値が同時に０となれば、プレイヤでこれ以上再生する映像がないということを意味するため、再生を中断してもよい。
【０１２３】
例えば、ユーザが最新ライブ映像を見ていたとすると、「ｃｓｈｉｆｔ」値は０が返されるため、「ｏｎａｉｒ」値が０に変わる時点に放送を即時に終了してもよい。一方、ユーザが１分シフト（ｃｓｈｉｆｔ値が６００００ミリ秒）になった映像を見ていたとすると、「ｏｎａｉｒ」が０に変わる時点から、「ｃｓｈｉｆｔ」値は６００００からリアルタイムで減少するようになる。このとき、１分が経過すれば「ｃｓｈｉｆｔ」は０となり、プレイヤは放送を終了してもよい。
【０１２４】
図６は、本発明の一実施形態における、初回再生要求および再生終了要求を処理する過程の例を示したフローチャートである。図６は、プレイヤ６１０とストリーミングクライアント６２０との間のメッセージの流れを示している。ここで、ストリーミングクライアント６２０は、図６に示すように、制御セッション６２１、ＲＴＭＰセッション６２２、およびエンジン６２３を含んでよい。制御セッション６２１は、タイムマシン機能を提供するためのタイムマシン制御プロトコルを利用してプレイヤ６１０とストリーミングクライアント６２０との間で通信するために設定されたセッションであってよく、ＲＴＭＰセッション６２２は、実際のストリーミングサービスのためのストリーミングプロトコルを利用してプレイヤ６１０とストリーミングクライアント６２０との間で通信するために設定されたセッションであってよい。実際に、制御セッション６２１は、制御セッション６２１を通じてタイムマシン機能を提供するためのストリーミングクライアント６２０のソフトウェア的機能（ｆｕｎｃｔｉｏｎ）であってよく、ＲＴＭＰセッション６２２は、ストリーミングサービスを提供するためのストリーミングクライアント６２０のソフトウェア的機能であってよい。
【０１２５】
１．／ａｕｔｈ？ａｕｔｈＫｅｙ＝＜認証キー＞過程は、プレイヤ６１０が制御セッション６２１を通じてストリーミングクライアント６２０に認証要求（／ａｕｔｈ）を送信する過程であってよい。ここで、認証要求（／ａｕｔｈ）は、認証キー（ａｕｔｈＫｅｙ）を含んでよい。
【０１２６】
２．２００  ＯＫ過程は、ストリーミングクライアント６２０が制御セッション６２１を通じてプレイヤ６１０に認証要求（／ａｕｔｈ）に対する応答を送信する過程であってよい。ストリーミングクライアント６２０は、認証要求（／ａｕｔｈ）に含まれる認証キー（ａｕｔｈＫｅｙ）を利用してプレイヤ６１０を認証してよい。プレイヤ６１０の認証に成功した場合、ストリーミングクライアント６２０は、成功応答（２００  ＯＫ応答コード）をプレイヤ６１０に送信してよい。プレイヤ６１０の認証に失敗した場合、ストリーミングクライアント６２０は、失敗応答（４０１  Ｕｎａｕｔｈｏｒｉｚｅｄ応答コード）をプレイヤ６１０に送信してよい。
【０１２７】
３．／ｐｌａｙ？ｐｒｏｇｒａｍＫｅｙ＝＜放送キー＞過程は、プレイヤ６１０が制御セッション６２１を通じてストリーミングクライアント６２０に再生要求（／ｐｌａｙ）を送信する過程であってよい。放送キー（ｐｒｏｇｒａｍＫｅｙ）については上述したとおりである。再生要求（／ｐｌａｙ）に含まれるＵＲＬは省略した。
【０１２８】
４．Ｐｌａｙ＜ｕｒｌ、ｐｒｏｇＩＤ＞過程は、制御セッション６２１を通じて受信した再生要求（／ｐｌａｙ）の処理のために、ストリーミングクライアント６２０の内部的にエンジン６２３に再生を要求する過程であってよい。「ｕｒｌ」は再生要求（／ｐｌａｙ）に含まれるＵＲＬに対応してよく、「ｐｒｏｇＩＤ」は再生要求（／ｐｌａｙ）に含まれる放送キー（ｐｒｏｇｒａｍＫｅｙ）に対応してよい。
【０１２９】
５．Ｃｒｅａｔｅ  Ｃｈａｎｎｅｌ過程は、エンジン６２３で要求された放送のためのチャンネルを生成する過程であってよい。例えば、エンジン６２３は、要求された「ｕｒｌ」にアクセスして「ｐｒｏｇＩＤ」に対応するライブストリームデータを要求するようにプレイヤ６１０とストリーミングクライアント６２０を含む電子機器を制御してよく、ライブストリームデータのためのチャンネルを生成してよい。
【０１３０】
６．ｒｅｔ：＜ｃａｐａｃｉｔｙ＿ｔｉｍｅ、ｓｅｅｋａｂｌｅ＿ｔｉｍｅ＞過程は、エンジン６２３が制御セッション６２１に該当のライブストリームデータに対する最大シフト可能時間（ｃａｐａｃｉｔｙ＿ｔｉｍｅ）と現在シフト可能時間（ｓｅｅｋａｂｌｅ＿ｔｉｍｅ）を伝達する過程であってよい。「ｃａｐａｃｉｔｙ＿ｔｉｍｅ」および「ｓｅｅｋａｂｌｅ＿ｔｉｍｅ」は、制御セッション６２１でそれぞれ「ｍｓｈｉｆｔ」および「ａｓｈｉｆｔ」として処理されてよい。図６では省略したが、「ｃｓｈｉｆｔ」に関する情報が共に伝達されてもよい。
【０１３１】
７．２００  ＯＫ過程は、ストリーミングクライアント６２０が制御セッション６２１を通じて再生要求（／ｐｌａｙ）に対する成功応答を送信する過程であってよい。ここで、成功応答には、「ｍｓｈｉｆｔ」と「ａｓｈｉｆｔ」（さらに「ｃｓｈｉｆｔ」）が含まれて送信されてもよい。
【０１３２】
８．Ｐｌａｙ＜ｕｒｌ＞過程は、プレイヤ６１０がストリーミングプロトコルを利用し、ＲＴＭＰセッション６２２を通じてストリーミングクライアント６２０に放送の再生を要求する過程であってよい。
【０１３３】
９．Ｐｌａｙ＜ｕｒｌ＞過程は、ＲＴＭＰセッション６２２を通じて放送の再生に対する要求がエンジン６２３に伝達される過程であってよい。
【０１３４】
１０．Ｓｅｎｄ  Ｍｅｄｉａ  Ｄａｔａ過程および１１．Ｓｅｎｄ  Ｍｅｄｉａ  Ｄａｔａ過程は、エンジン６２３がＲＴＭＰセッション６２２を通じて実際のストリーミングのためのデータをプレイヤ６２０に送信する過程であってよい。プレイヤ６２０は、受信したデータを利用して放送を再生してよく、再生された放送が電子機器のディスプレイに表示されるように電子機器を制御してよい。
【０１３５】
１２．／ｓｔｏｐ過程は、プレイヤ６１０が制御セッション６２１を通じてストリーミングクライアント６２０に再生終了要求（／ｓｔｏｐ）を送信する過程であってよい。
【０１３６】
１３．Ｃｌｅａｎｕｐ  Ｃｏｎｔｅｘｔ過程は、ストリーミングクライアント６２０が該当のセッションのためのタイムマシン情報をすべて削除する過程であってよい。
【０１３７】
１４．２００  ＯＫ過程は、ストリーミングクライアント６２０が制御セッション６２１を通じてプレイヤ６１０に再生終了要求（／ｓｔｏｐ）に対する成功応答を送信する過程であってよい。
【０１３８】
１５．ＳＴＯＰ過程は、エンジン６２３に再生終了を要求する過程であってよい。
【０１３９】
１６．Ｃｌｏｓｅ  Ｓｅｓｓｉｏｎ過程は、プレイヤ６１０がＲＴＭＰセッション６２２を通じてストリーミングクライアント６２０に実質的なセッションの終了を要求する過程であってよい。
【０１４０】
１７．Ｃｌｏｓｅ過程は、ストリーミングクライアント６２０がストリーミングプロトコルにしたがってエンジン６２３に終了を指示する過程であってよい。
【０１４１】
１８．Ｃｌｏｓｅ  Ｃｈａｎｎｅｌ過程は、エンジン６２３がチャンネルを終了する過程であってよい。
【０１４２】
このように、タイムマシン制御プロトコルとストリーミングプロトコルとを完全に分離して処理が行われるため、ストリーミングクライアントは、プレイヤ６１０がサポートするストリーミングプロトコルとは関係なく、タイムマシン制御プロトコルを利用してタイムマシン機能を提供することが可能となる。
【０１４３】
図７は、本発明の一実施形態における、再生中に探索要求を処理する過程の例を示したフローチャートである。
【０１４４】
１．／ｓｅｅｋ？ｓｈｉｆｔ＝＜移動する時間＞過程は、プレイヤ６１０がストリーミングクライアント６２０に探索要求（／ｓｅｅｋ）を送信する過程であってよい。
【０１４５】
２．Ｓｅｅｋ：＜ｕｒｌ、ｔｉｍｅ＞過程は、ストリーミングクライアント６２０が制御セッション６２１を通じてエンジン６２３に実質的な探索を要求する過程であってよい。
【０１４６】
３．ｒｅｔ：＜ｓｅｅｋ＿ｔｉｍｅ＞過程は、エンジン６２３が探索結果を提供する過程であってよい。ここで、「ｓｅｅｋ＿ｔｉｍｅ」は「ｃｓｈｉｆｔ」に対応してよい。
【０１４７】
４．２００  ＯＫ過程は、ストリーミングクライアント６２０が制御セッション６２１を通じて探索要求（／ｓｅｅｋ）に対する成功応答をプレイヤ６１０に送信する過程であってよい。ここで、「ｓｅｅｋ＿ｔｉｍｅ」に対応する「ｃｓｈｉｆｔ」が成功応答に含まれてプレイヤ６１０に送信されてよい。
【０１４８】
５．Ｒｅｓｅｔ  Ｍｅｄｉａ  Ｄａｔａ過程は、エンジン６２３がＲＴＭＰセッション６２２を通じて再生位置が移動された部分から再生するためにストリームデータを再設定する過程であってよい。
【０１４９】
６．Ｓｅｎｄ  Ｍｅｄｉａ  Ｄａｔａ過程および７．Ｓｅｎｄ  Ｍｅｄｉａ  Ｄａｔａ過程は、エンジン６２３が再設定された再生位置からデータをプレイヤ６１０に送信する過程であってよい。
【０１５０】
このような図７の実施形態でも、このようにタイムマシン制御プロトコルとストリーミングプロトコルとを完全に分離して処理が行わることを理解することができる。
【０１５１】
図８は、本発明の一実施形態における、一時停止要求および再開要求を処理する過程の例を示したフローチャートである。
【０１５２】
１．／ｐａｕｓｅ過程は、プレイヤ６１０が再生中の放送に対する一時停止要求（／ｐａｕｓｅ）を、制御セッション６２１を通じてストリーミングクライアント６２０に送信する過程であってよい。
【０１５３】
２．Ｐａｕｓｅ過程は、ストリーミングクライアント６２０がエンジン６２３に一時停止を指示する過程であってよい。
【０１５４】
３．ｒｅｔ：＜ｃｕｒ＿ｔｉｍｅ＞過程は、エンジン６２３が一時停止要求（／ｐａｕｓｅ）に対する処理結果を提供する過程であってよい。ここで、「ｃｕｒ＿ｔｉｍｅ」は、現在一時停止されている再生位置を時間で示した値であってよい。制御セッションは、「ｃｕｒ＿ｔｉｍｅ」を格納および管理してよい。
【０１５５】
４．２００  ＯＫは、ストリーミングクライアント６２０が一時停止要求（／ｐａｕｓｅ）に対する成功応答を、制御セッション６２１を通じてプレイヤ６１０に送信する過程であってよい。
【０１５６】
５．Ｃｌｏｓｅ  Ｃｈａｎｎｅｌ過程は、エンジン６２３がチャンネルを終了する過程であってよい。チャンネルが接続されている場合、一時停止状態でもデータが持続して受信されてもよいが、これはモバイルでネットワークデータ使用量に影響を及ぼすことがある。したがって、本実施形態では、チャンネルを終了してデータの受信を防いでよい。
【０１５７】
６．Ｐａｕｓｅ過程は、プレイヤ６１０がＲＴＭＰセッション６２２を通じてストリーミングプロトコルにしたがってストリーミングクライアントに一時停止を要求する過程であってよい。
【０１５８】
７．／ｒｅｓｕｍｅ過程は、プレイヤ６１０が一時停止中の放送に対して再開要求（／ｒｅｓｕｍｅ）を、制御セッション６２１を通じてストリーミングクライアント６２０に送信する過程であってよい。
【０１５９】
８．Ｒｅｓｕｍｅ：＜ｕｒｌ，ｔｉｍｅ＞過程は、制御セッション６２１でエンジン６２３に「ｃｕｒ＿ｔｉｍｅ」から再生を再開することを要求する過程であってよい。「ｕｒｌ」は一時停止が要求された放送のＵＲＬに対応してよく、「ｔｉｍｅ」は制御セッション６２１が格納および管理する「ｃｕｒ＿ｔｉｍｅ」に対応してよい。
【０１６０】
９．Ｃｒｅａｔｅ  Ｃｈａｎｎｅｌ過程は、エンジン６２３が放送をまた再開するためにチャンネルを生成する過程であってよい。
【０１６１】
１０．ｒｅｔ：＜ｒｅｓｕｍｅ＿ｔｉｍｅ＞過程は、エンジン６２３が再開要求（／ｒｅｓｕｍｅ）に対する処理結果を提供する過程であってよい。ここで、「ｒｅｓｕｍｅ＿ｔｉｍｅ」は、放送が再開される再生位置に対する値を示してよい。
【０１６２】
１１．２００  ＯＫ過程は、ストリーミングクライアント６２０が制御セッション６２１を通じて再開要求（／ｒｅｓｕｍｅ）に対する成功応答をプレイヤ６１０に送信する過程であってよい。「ｒｅｓｕｍｅ＿ｔｉｍｅ」は「ｃｓｈｉｆｔ」に対応してよい。
【０１６３】
１２．Ｐｌａｙ＜ｕｒｌ＞過程は、プレイヤ６１０がストリーミングプロトコルを利用し、ＲＴＭＰセッション６２２を通じてストリーミングクライアント６２０に放送の再生を要求する過程であってよい。また、１３．Ｃｒｅａｔｅ  Ｃｈａｎｎｅｌ過程は、ＲＴＭＰセッション６２２がエンジン６２３にチャンネルを生成することを要求する過程であってよい。
【０１６４】
図９は、本発明の一実施形態における、デリバリサーバの内部構成を説明するための図である。デリバリサーバ３３０は、上述したように、パケット化サーバ３２０からピースを受信してピア（ストリーミングクライアント３５１を含む電子機器）に伝達してよい。また、デリバリサーバ３３０は、プログラム管理サーバ９５０からプログラムスケジュールを受信し、受信したプログラムスケジュールにしたがって動作してよい。このために、デリバリサーバ３３０は、プログラムモニタ９１０、プログラムマネージャ９２０、およびストリームマネージャ９３０を含んでよい。
【０１６５】
プログラムモニタ９１０は、プログラム管理サーバ９５０から放送プログラムに関するスケジュール情報としてプログラムスケジュールを収集してよい。
【０１６６】
プログラムマネージャ９２０は、プログラムスケジュールを分析し、特定のチャンネルまたは特定の放送プログラムに対してタイムマシンバッファの動作の可否を決めてよい。
【０１６７】
ストリームマネージャ９３０は、プログラムマネージャ９２０の分析結果に基づき、特定のチャンネルまたは特定の放送プログラムに対するタイムマシンバッファを管理してよい。
【０１６８】
例えば、プログラムマネージャ９２０は、現在生放送中の放送プログラムＡに対するタイムマシンバッファＢを管理することをストリームマネージャ９３０に要求してよい。ここで、ストリームマネージャ９３０は、パケット化サーバ３２０が送信するピースのうち、放送プログラムＡに対するピースをタイムマシンバッファＢで格納して管理してよい。
【０１６９】
したがって、このようなタイムマシンバッファＢに格納されたピースを利用することで、ストリーミングクライアント３５１は、放送プログラムＡに対するタイムマシン機能を安定的に提供することが可能となる。また、デリバリサーバ３３０の観点では、すべての放送プログラムやすべてのチャンネルに対するタイムマシンバッファを管理する必要がなく、現在生放送中であるか、タイムマシン機能を提供しようとする放送プログラムに対してのみタイムマシンバッファを活用することにより、効率的にライブストリームデータを管理することが可能となる。
【０１７０】
また、プログラムマネージャ９２０で放送プログラムに対するタイムマシンバッファの動作の可否を決め、タイムマシンバッファを使用する放送プログラムに関する情報をストリーミングクライアント３５１に送信してもよい。例えば、プログラムマネージャ９２０は、上述した放送キー（ｐｒｏｇｒａｍＫｅｙ）をストリーミングクライアント３５１に送信することで、タイムマシンバッファを活用中である放送プログラムに関する情報をユーザに提供することができるようになる。
【０１７１】
図１０は、本発明の一実施形態における、タイムマシンバッファの活用例を示した図である。図１０のタイムマシンバッファ（１０１０および１０２０）は、１つのタイムマシンバッファで複数のプログラム（プログラム１、２、３）に対するストリームデータを格納および管理する例を示している。ここで、デリバリサーバ３３０は、１つのタイムマシンバッファのためのストリームデータ（ピース）を、上述したプログラムスケジュールに基づいて放送プログラム別そしてストリーム別に区分して格納および管理してよい。例えば、特定の放送プログラムのストリームデータを該当の放送プログラムの放送キー（ｐｒｏｇｒａｍＫｅｙ）とマッチングさせて格納してよい。
【０１７２】
例えば、一般的な場合のタイムマシンバッファ１０１０は、プログラムスケジュールに基づいて（一例として、放送時間など）プログラム１のためのストリームデータとプログラム２のためのストリームデータとを区分してよい。したがって、一般的な場合のタイムマシンバッファ１０１０内のストリームデータのうちどのストリームデータがプログラム２に対するストリームデータであるかを区分することができ、したがって、タイムマシン機能を利用してプログラム２に対して過去のどの時点まで再生位置を移動することができるかを明確に把握することができるようになる。
【０１７３】
また、ネットワーク状況に応じてストリーム接続が切れたりする場合、例外的な場合のタイムマシンバッファ１０２０のように、１つの放送プログラムに対するストリームデータが複数のストリームによって提供される場合が存在するようになる。例えば、例外的な場合のタイムマシンバッファ１０２０において、プログラム２は、再生位置に応じてそれぞれ互いに異なるストリームであるストリーム１、ストリーム２、およびストリーム３によって提供されることがある。ここで、互いに異なるストリームは、互いに異なるチャンネルに対応してよい。したがって、プログラム２に対するタイムマシン機能に基づいてストリームデータを提供するとき、再生位置に応じて互いに異なるストリームでストリームデータを提供しなければならない。本実施形態に係るタイムマシンバッファ（１０１０および１０２０）は、ストリームデータ（ピース）を上述したプログラムスケジュールに基づき、放送プログラム別そしてストリーム別に区分して格納および管理することができるため、放送プログラム別そしてストリーム別にストリームデータを正確に特定することができるようになる。
【０１７４】
ストリーミングクライアント３５１の観点では、デリバリサーバ３３０に要求しようとする特定の放送プログラムのデータストリームまたは特定のチャンネルのプログラムに対するデータストリームを、１つのタイムマシンバッファから正確に受信することができるようになる。
【０１７５】
図１１は、本発明の一実施形態における、タイムマシン機能を利用して探索を行う場合にプレビュー機能を提供する画面の例を示した図である。図１１は、ライブストリーミングサービスのためのディスプレイ画面１１００の例を示している。ディスプレイ画面１１００には、ストリーミングされる放送プログラムに対する映像画面１１１０が提供されてよい。ディスプレイ画面１１００のバー１１２０は、タイムマシン機能で再生位置を指定するためのユーザインタフェースであってよい。ユーザがバー１１２０から特定の位置を選択（一例として、ＰＣ環境でバーの特定の位置にマウスオーバー）した場合、選択された位置と関連するプレビュー映像１１３０が提供されてよい。プレビュー映像１１３０は、選択されたフレームのスナップショット形態で提供されてよい。
【０１７６】
ここで、バー１１２０の領域は、複数の区間に予め分類されてもよく、プレビュー映像１１３０は、特定の位置を含む区間のフレームのうち一番目のフレームに対応してよい。例えば、ストリーミングクライアントは、ユーザによって選択された位置が、バー１１２０に予め設定された複数の区間のうちの特定の区間１１４０に含まれる場合、該当の位置に正確にマッチングするフレームを見つけるのではなく、特定の区間１１４０に該当するフレームの一番目のフレームであるフレーム１をプレビュー映像１１３０として提供してよい。したがって、生放送される放送プログラムでタイムマシン機能を提供するにあたり、過去の特定のフレームを正確に見つける必要なく、相対的に見つけやすい区間の一番目のフレームを見つけて提供することにより、演算量を減らすことができるようになる。
【０１７７】
図１２は、本発明の一実施形態における、電子機器のプロセッサが含むことのできる構成要素の例を示した図であり、図１３は、本発明の一実施形態における、電子機器が実行することのできるタイムマシン機能提供方法の例を示したフローチャートである。
【０１７８】
図１２に示すように、電子機器１（１１０）のプロセッサ２１２は、構成要素として、ストリーミングセッション設定部１２１０、ライブストリームデータ送信部１２２０、タイムマシン制御セッション設定部１２３０、およびタイムマシン制御要求受信部１２４０を備えてよい。このようなプロセッサ２１２およびプロセッサ２１２の構成要素は、図１３のタイムマシン機能提供方法に含まれる段階１３１０〜１３６０を実行するように電子機器１（１１０）を制御してよい。ここで、プロセッサ２１２およびプロセッサ２１２の構成要素は、メモリ２１１に含まれるオペレーティングシステムのコードと少なくとも１つのプログラムのコードとによる命令を実行するように実現されてよい。ここで、プロセッサ２１２の構成要素は、プロセッサ２１２によって実行される互いに異なる機能（ｄｉｆｆｅｒｅｎｔ  ｆｕｎｃｔｉｏｎｓ）の表現であってよい。例えば、プロセッサ２１２が上述した命令にしたがってストリーミングセッションを設定するように電子機器１（１１０）を制御する動作の機能的表現として、ストリーミングセッション設定部１２１０が使用されてよい。
【０１７９】
段階１３１０で、プロセッサ２１２は、タイムマシン機能提供方法のためのプログラムのファイルに格納されたプログラムコードをメモリ２１１にロードしてよい。例えば、電子機器１（１１０）にインストールされたプログラムが駆動される場合、プロセッサ２１２は、プログラムのファイルからプログラムコードをメモリ２１１にロードするように電子機器１（１１０）を制御してよい。
【０１８０】
ここで、プロセッサ２１２およびプロセッサ２１２が備えるストリーミングセッション設定部１２１０、ライブストリームデータ送信部１２２０、タイムマシン制御セッション設定部１２３０、およびタイムマシン制御要求受信部１２４０それぞれは、メモリ２１１にロードされたプログラムコードのうち対応する部分（対応する命令）を実行し、以後に段階１３２０〜１３６０を実行してよい。段階１３２０〜１３６０の実行のために、プロセッサ２１２およびプロセッサ２１２の構成要素は、電子機器１（１１０）を制御してよい。例えば、プロセッサ２１２は、電子機器１（１１０）が含む通信モジュール２１３を制御して電子機器１（１１０）が他の電子機器や他のサーバと通信するように電子機器１（１１０）を制御してよい。
【０１８１】
段階１３２０で、ストリーミングセッション設定部１２１０は、ライブストリーミングサービスを提供するために、電子機器１（１１０）にインストールされたストリーミングクライアントと電子機器１（１１０）にインストールされたプレイヤとのストリーミングセッションを設定してよい。ストリーミングクライアントとプレイヤはそれぞれアプリケーションであり、電子機器１（１１０）でインストールおよび駆動されてよい。
【０１８２】
段階１３３０で、ライブストリームデータ送信部１２２０は、ストリーミングクライアントの制御にしたがってネットワークを介して受信したライブストリームデータを、ストリーミングセッションを通じて順にプレイヤに送信してよい。
【０１８３】
段階１３４０で、タイムマシン制御セッション設定部１２３０は、ストリーミングクライアントとプレイヤとの間のタイムマシン制御セッションを設定してよい。
【０１８４】
段階１３５０で、タイムマシン制御要求受信部１２４０は、ストリーミングクライアントの制御にしたがってタイムマシン制御セッションを通じてプレイヤからタイムマシン制御要求を受信してよい。
【０１８５】
段階１３６０で、ライブストリームデータ送信部１２２０は、ストリーミングクライアントの制御にしたがって、タイムマシン制御要求のうち再生位置情報を含むタイムマシン制御要求に対応するチャンネルのライブストリームデータを、再生位置情報によって特定される再生位置から順にストリーミングセッションを通じてプレイヤに送信してよい。
【０１８６】
ストリーミングセッションを通じた前記ストリーミングクライアントとプレイヤとの間のデータ送信と、タイムマシン制御セッションを通じたストリーミングクライアントとプレイヤとの間のデータ送信は、互いに異なる別のプロトコルによってそれぞれ行われてもよい。
【０１８７】
他の実施形態において、タイムマシン機能提供方法は、ストリーミングクライアントで、プレイヤからタイムマシン制御セッションを通じて認証要求を受信してもよい。ここで、認証要求は、ライブストリームデータまたはチャンネルを特定するための情報および認証キーを含んでよい。この場合、タイムマシン機能提供方法は、認証キーを利用してプレイヤを認証し、プレイヤの認証が成功した場合、タイムマシン制御セッションに対して付与された固有値をセッションキーとして認証要求に対する応答に含めてプレイヤに送信してよい。また、タイムマシン機能提供方法は、ストリーミングクライアントで、タイムマシン制御要求がセッションキーを含んでいるかを確認してタイムマシン制御要求を認証してもよい。さらに、タイムマシン機能提供方法は、ストリーミングクライアントで、電子機器にインストールされた他のプレイヤからの認証要求によって他のプレイヤが認証された場合、他のプレイヤと設定されたタイムマシン制御セッションに対して付与された固有値を含むセッションキーを前記他のプレイヤに送信し、既存のプレイヤのセッションキーを無効にしてもよい。
【０１８８】
さらに他の実施形態において、タイムマシン機能提供方法は、ストリーミングクライアントで、プレイヤからタイムマシン制御セッションを通じて情報取得およびセッション維持要求を受信し、ストリーミングクライアントで、ストリーミングセッションを通じてプレイヤに提供中のライブストリームデータに対するタイムマシン時間情報を前記情報取得およびセッション維持要求に対する応答に含めてタイムマシン制御セッションを通じてプレイヤに送信してもよい。ここで、タイムマシン時間情報は、ライブストリームデータの最新データを基準として過去データを探索可能な程度を示す指標としてライブストリームデータ別に予め設定された最大シフト可能時間、最新データを基準として現時点で過去データを探索可能な程度を示す指標である現在シフト可能時間、および最新データを基準としてタイムマシン機能によって現在再生中の過去データを特定する指標である現在シフト時間を含んでよい。
【０１８９】
さらに他の実施形態において、タイムマシン機能提供方法は、ストリーミングクライアントで、チャンネル識別情報、チャンネル識別情報によって識別されるチャンネルのライブストリームデータのうち、特定の放送のライブストリームデータを識別するための放送キーを含む再生要求を、タイムマシン制御セッションを通じて受信してもよく、ストリーミングクライアントで、チャンネル識別情報によって識別されるチャンネルのライブストリームデータのうち、放送キーによって識別されるライブストリームデータを順にストリーミングセッションを通じてプレイヤに送信してもよい。ここで、ライブストリームデータは、デリバリサーバからネットワークを介して電子機器に送信されてよく、デリバリサーバが含むタイムマシンバッファで、ライブストリームデータがチャンネル識別情報および放送キーを利用してチャンネル別そして放送別にマッチングされて格納されてよい。また、再生要求は、タイムマシン機能の使用可否、識別されたライブストリームデータの初めの再生開始位置、チャンネルを一時停止（ｐａｕｓｅ）状態によって開始するか否かのうち少なくとも１つに関する情報をさらに含んでもよい。
【０１９０】
さらに他の実施形態において、タイムマシン機能提供方法は、ストリーミングクライアントで、一時停止要求を、タイムマシン制御セッションを通じて受信することによって、ライブストリームデータで現在まで再生された位置を格納し、ライブストリームデータの送信を停止してもよく、ストリーミングクライアントで、再開要求を、タイムマシン制御セッションを通じて受信することによって、格納された位置からライブストリームデータを順にプレイヤに送信してもよい。ここで、一時停止要求に応じて前記チャンネルの接続が終了し、再開要求に応じて前記チャンネルの接続が再び生成されてよい。
【０１９１】
さらに他の実施形態において、タイムマシン機能提供方法は、ストリーミングクライアントで、前記タイムマシン制御要求に対する応答として、ライブストリームデータが現在放送中であるか否かに関するオンエア情報およびライブストリームデータの最新データを基準としてタイムマシン機能によって現在再生中の過去データを特定する指標である現在シフト時間を、タイムマシン制御要求に対する応答としてタイムマシン制御セッションを通じて前記プレイヤに送信してもよい。ここで、プレイヤでオンエア情報および現在シフト時間を組み合わせることによって、放送終了時点を決めてよい。
【０１９２】
図１２および図１３で省略した内容は、図１〜図１１を参照してよい。
【０１９３】
このように、本発明の実施形態によると、タイムマシン制御プロトコルがタイムマシン機能を制御する役割だけを担い、ストリーミングクライアントとプレイヤとの間のストリーミングプロトコルは、プレイヤがサポートするストリーミング規格をそのまま利用できるように実現することができる。また、ＯＳやプレイヤに関係なく、同じ規格を利用してタイムマシン機能を制御することができるため、ストリーミングクライアントのプレイヤに対する依存性を除去することができる。
【０１９４】
上述したシステムまたは装置は、ハードウェア構成要素、ソフトウェア構成要素、またはハードウェア構成要素とソフトウェア構成要素との組み合わせによって実現されてよい。例えば、実施形態で説明された装置および構成要素は、例えば、プロセッサ、コントローラ、ＡＬＵ（ａｒｉｔｈｍｅｔｉｃ  ｌｏｇｉｃ  ｕｎｉｔ）、デジタル信号プロセッサ、マイクロコンピュータ、ＦＰＧＡ（ｆｉｅｌｄ  ｐｒｏｇｒａｍｍａｂｌｅ  ｇａｔｅ  ａｒｒａｙ）、ＰＬＵ（ｐｒｏｇｒａｍｍａｂｌｅ  ｌｏｇｉｃ  ｕｎｉｔ）、マイクロプロセッサ、または命令を実行して応答することができる様々な装置のように、１つ以上の汎用コンピュータまたは特殊目的コンピュータを利用して実現されてよい。処理装置は、オペレーティングシステム（ＯＳ）および前記ＯＳ上で実行される１つ以上のソフトウェアアプリケーションを実行してよい。また、処理装置は、ソフトウェアの実行に応答し、データにアクセスし、データを格納、操作、処理、および生成してよい。理解の便宜のために、１つの処理装置が使用されるとして説明される場合もあるが、当業者は、処理装置が複数個の処理要素（ｐｒｏｃｅｓｓｉｎｇ  ｅｌｅｍｅｎｔ）および／または複数種類の処理要素を含んでもよいことが理解できるであろう。例えば、処理装置は、複数個のプロセッサまたは１つのプロセッサおよび１つのコントローラを含んでもよい。また、並列プロセッサ（ｐａｒａｌｌｅｌ  ｐｒｏｃｅｓｓｏｒ）のような、他の処理構成（ｐｒｏｃｅｓｓｉｎｇ  ｃｏｎｆｉｇｕｒａｔｉｏｎ）も可能である。
【０１９５】
ソフトウェアは、コンピュータプログラム、コード、命令、またはこれらのうちの１つ以上の組み合わせを含んでもよく、思うままに動作するように処理装置を構成したり、独立的または集合的に（ｃｏｌｌｅｃｔｉｖｅｌｙ）処理装置に命令したりしてよい。ソフトウェアおよび／またはデータは、処理装置に基づいて解釈されたり、処理装置に命令またはデータを提供したりするために、いかなる種類の機械、コンポーネント、物理装置、仮想装置（ｖｉｒｔｕａｌ  ｅｑｕｉｐｍｅｎｔ）、コンピュータ格納媒体または装置、または伝送される信号波（ｓｉｇｎａｌ  ｗａｖｅ）に永久的または一時的に具現化（ｅｍｂｏｄｙ）されてもよい。ソフトウェアは、ネットワークによって接続されたコンピュータシステム上に分散され、分散された状態で格納されても実行されてもよい。ソフトウェアおよびデータは、１つ以上のコンピュータで読み取り可能な記録媒体に格納されてもよい。
【０１９６】
実施形態に係る方法は、多様なコンピュータ手段によって実行可能なプログラム命令の形態で実現されてコンピュータで読み取り可能な媒体に記録されてもよい。前記コンピュータで読み取り可能な媒体は、プログラム命令、データファイル、データ構造などを単独でまたは組み合わせて含んでもよい。前記媒体に記録されるプログラム命令は、実施形態のために特別に設計されて構成されたものであってもよいし、コンピュータソフトウェア当業者に公知な使用可能なものであってもよい。コンピュータで読み取り可能な記録媒体の例としては、ハードディスク、フロッピー（登録商標）ディスク、および磁気テープのような磁気媒体、ＣＤ−ＲＯＭ、ＤＶＤのような光媒体、フロプティカルディスク（ｆｌｏｐｔｉｃａｌ  ｄｉｓｋ）のような光磁気媒体、およびＲＯＭ、ＲＡＭ、フラッシュメモリなどのようなプログラム命令を格納して実行するように特別に構成されたハードウェア装置が含まれる。プログラム命令の例は、コンパイラによって生成されるもののような機械語コードだけではなく、インタプリタなどを使用してコンピュータによって実行される高級言語コードを含む。上述したハードウェア装置は、実施形態の動作を実行するために１つ以上のソフトウェアモジュールとして動作するように構成されてもよく、その逆も同じである。
【０１９７】
以上のように、実施形態を、限定された実施形態と図面に基づいて説明したが、当業者であれば、上述した記載から多様な修正および変形が可能である。例えば、説明された技術が、説明された方法とは異なる順序で実行されたり、かつ／あるいは、説明されたシステム、構造、装置、回路などの構成要素が、説明された方法とは異なる形態で結合されたりまたは組み合わされたり、他の構成要素または均等物によって対置されたり置換されたとしても、適切な結果を達成することができる。
【０１９８】
したがって、異なる実施形態であっても、特許請求の範囲と均等なものであれば、添付される特許請求の範囲に属する。
【符号の説明】
【０１９９】
１１０、１２０、１３０、１４０：電子機器
１５０、１６０：サーバ
１７０：ネットワーク
【図１】
0006490654.tif 000025
【図２】
0006490654.tif 000026
【図３】
0006490654.tif 000027
【図４】
0006490654.tif 000028
【図５】
0006490654.tif 000029
【図６】
0006490654.tif 000030
【図７】
0006490654.tif 000031
【図８】
0006490654.tif 000032
【図９】
0006490654.tif 000033
【図１０】
0006490654.tif 000034
【図１１】
0006490654.tif 000035
【図１２】
0006490654.tif 000036
【図１３】
0006490654.tif 000037