JP2019208280A - テレビ受信機、表示装置、並びに装置 - Google Patents

Abstract

【課題】サービス毎の個別実装やメンテナンスのコストを低減する。【解決手段】異なる複数のサービス・プロバイダーから提供されるＩＰＴＶサービス・クライアントの機能を、ナビゲーション（コンテンツを選択させる機能）と、再生制御（通常再生並びに停止や、巻き戻し再生、早送り再生、ポーズといったトリックプレイなどのコマンドを送る機能）と、ストリーミング（ＡＶストリームを転送・再生する機能）に分離し、前者２つをブラウザー・アプリケーションとして実現し、後者１つをＩＰＴＶサービス・プロトコルと透過なプレイヤーとして実装する。【選択図】 図１

Description

本明細書で開示する技術は、ストリーミング・サーバーから送出されるコンテンツのストリームを転送するコンテンツ転送装置及びコンテンツ転送方法、コンテンツの選択やコンテンツの再生を行なうコンテンツ再生装置及びコンテンツ再生方法、コンテンツ配信システム、並びにコンピューター・プログラムに係り、例えばＩＰＴＶ放送サービスにより配信されるコンテンツのストリームをＩＰＴＶサービス・クライアントに転送するコンテンツ転送装置及びコンテンツ転送方法、ＩＰＴＶサービスにおけるクライアントとしてコンテンツ若しくはチャンネルの選択やコンテンツの再生を行なうコンテンツ再生装置及びコンテンツ再生方法、コンテンツ配信システム、並びにコンピューター・プログラムに関する。

地上波や衛星波を使って放送していたビデオ・コンテンツをＩＰ（ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ブロードバンド・ネットワーク経由で伝送するＩＰＴＶサービスやＶＯＤ（Ｖｉｄｅｏ Ｏｎ Ｄｅｍａｎｄ）サービスの商用化が進んでいる。

従来のＩＰＴＶ配信システムでは、ＡＶストリームの取得と制御にＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）プロトコルを利用している。すなわち、品質の保証されていないネットワークを介したインターネットＴＶ配信システムでは、一般にコンテンツの取得制御メッセージもコンテンツのＡＶストリームも同じＨＴＴＰ並びにＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）プロトコルを使って転送する方式が採用されている（例えば、特許文献１を参照のこと）。

一方、各国のキャリア主導で導入が始まっているＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）のようなＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）の保証されたネットワークにおいては、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）やＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）などのプロトコルを用いてストリーミング・セッションを確立して、ＲＴＰ（Ｒｅａｌ ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）などのプロトコルを用いてＡＶストリームを転送している（例えば、特許文献２を参照のこと）。

一般に、ＳＩＰ／ＲＴＳＰとＲＴＰによるＩＰＴＶプロトコルのクライアントはキャリア毎に実装プロファイル（プロトコル・パラメーターのセット）が異なる。このため、ＩＰＴＶを受信するＳＴＢ（Ｓｅｔ Ｔｏｐ Ｂｏｘ）などのデバイスを開発・製造するデバイス・ベンダーは、各キャリア独自のＩＰＴＶクライアント（キャリア毎のＩＰＴＶクライアント・アプリケーション）を実装しなければならない。

図１０には、ＳＩＰ／ＲＴＳＰプロトコルを用いてストリーミング・セッションの確立を行なうとともにＲＴＰプロトコルを用いてＡＶストリームを転送する映像配信システムを模式的に示している。図示の例では、２つのキャリアからそれぞれＩＰＴＶサービスＡとＩＰＴＶサービスＢという独自のサービスが提供され、各サービス用のサーバーが設置されている。ここで、ＩＰＴＶサービスＡサーバーから配信サービスを受けるには独自のサービスＡ向けＩＰＴＶクライアント・アプリケーションが必要であり、ＩＰＴＶサービスＢサーバーから配信サービスを受けるには独自のサービスＢ向けＩＰＴＶクライアント・アプリケーションが必要である。これらサービス毎のクライアント・アプリケーションは、具体的には、各キャリアから配布されるＳＴＢ内の組み込みソフトである。このような場合、キャリアは、サービスを変えるときには、デバイス（すなわち、ＳＴＢ）を置き換える必要がある。また、クライアント・アプリケーションのベンダーは、キャリア毎（すなわちサービス毎）の独自のプロトコルに合わせてクライアント・アプリケーションを開発し、メンテナンスする必要がある。また、エンド・ユーザーは、あるキャリアのＩＰＴＶサービスに加入した後、さらに別のキャリアのＩＰＴＶサービスも利用したいときには、ＳＴＢを買い増しする必要がある。

デバイス・ベンダーは、とあるキャリアのＩＰＴＶサービス向けに開発したＩＰＴＶクライアント実装を、他の複数のキャリアのＩＰＴＶサービス向けに流用したいという願望がある。そのためには、１つのＩＰＴＶクライアントに、キャリア毎の異なる独自のＩＰＴＶサービス・プロトコルを複数実装するか、又は、キャリア毎に異なる独自のＩＰＴＶクライアントそのものを複数実装しなければならない。デバイス・ベンダーにとっては、そのプロトコル実装にコストがかかる。また、デバイス・ベンダーは、サービス・プロバイダーからの要求に応じた機能追加などにまつわるメンテナンスにコストがかかるという問題が起こる。

また、サービス・プロバイダーは、複数の異なるクライアント・ベンダーによる異なる実装のクライアントのいずれを介しても、エンド・ユーザーに対して、各クライアント間の実装上の相違に依らない均一なサービスを提供しなければならない。このため、サービス・プロバイダーは、テストやサービス品質の管理など、サービス開発並びにメンテナンスに時間とコストを費やすという問題がある。

特開２００７−２７２８６８号公報 ＷＯ２００８／０９１００９

本明細書で開示する技術の目的は、ＩＰＴＶ放送サービスにより配信されるコンテンツのストリームをＩＰＴＶサービス・クライアントに好適に転送することができる優れたコンテンツ転送装置及びコンテンツ転送方法、並びにコンピューター・プログラムを提供することにある。

また、本明細書で開示する技術の目的は、ＩＰＴＶサービスにおけるクライアントとしてコンテンツ若しくはチャンネルの選択やコンテンツの再生を好適に行なうことができる優れたコンテンツ再生装置及びコンテンツ再生方法、並びにコンピューター・プログラムを提供することにある。

また、本明細書で開示する技術の目的は、ＩＰＴＶクライアントの実装並びにメンテナンスのコストを低減でき、各クライアントに対するサービス品質を均一にすることができる、優れたコンテンツ配信システムを提供することにある。

本願は、上記課題を参酌してなされたものであり、請求項１に記載の技術は、
コンテンツのストリームを再生するコンテンツ再生装置との間でチャンネルをネットワーク上で確立するチャンネル確立部と、
前記コンテンツ再生装置からコンテンツのストリームの再生を制御する再生制御コマンドを前記ネットワーク経由で受信する再生制御コマンド受信部と、
受信した前記再生制御コマンドに従って、前記チャンネルを用いてコンテンツのストリームを前記コンテンツ再生装置に送出するストリーミング部と、
を具備するコンテンツ転送装置である。

本願の請求項２に記載の技術によれば、請求項１に記載のコンテンツ転送装置の前記チャンネル確立部は、前記コンテンツ再生装置上でコンテンツのストリームを再生するプレイヤーからの要求に応じて前記チャンネルを確立するように構成されている。

本願の請求項３に記載の技術によれば、請求項１に記載のコンテンツ転送装置の前記チャンネル確立部は、前記コンテンツ再生装置との間で常時ＨＴＴＰリクエストの送信及びＨＴＴＰレスポンスの返信が可能な帯域保証型のパスからなるチャンネルを、前記ネットワーク上で確立するように構成されている。

本願の請求項４に記載の技術によれば、請求項１に記載のコンテンツ転送装置の前記再生制御コマンド受信部は、前記コンテンツ再生装置のブラウザー実行環境で動作するブラウザー・アプリケーションがユーザーの指示に応じて発行した再生制御コマンドを、ＨＴＴＰリクエストとして受信するように構成されている。

本願の請求項５に記載の技術によれば、請求項１に記載のコンテンツ転送装置の前記ストリーミング部は、前記コンテンツ再生装置上で動作するサービス・プロトコル透過なプレイヤーに対してコンテンツのストリームを送出するように構成されている。

本願の請求項６に記載の技術によれば、請求項１に記載のコンテンツ転送装置の前記ストリーミング部は、前記コンテンツ再生装置のブラウザー実行環境で動作するブラウザー・アプリケーションがユーザーの選択に応じてＨＴＴＰリクエストにより要求するコンテンツのストリームをストリーミング・サーバーから取得して、前記コンテンツ再生装置に送出するように構成されている。

本願の請求項７に記載の技術によれば、請求項１に記載のコンテンツ転送装置の前記ストリーミング部は、前記コンテンツ再生装置からの要求に応じてストリーミング・サーバーから送出されるストリーム・フォーマットを、前記コンテンツ再生装置側でストリーミング再生するプレイヤーが処理できるフォーマットに変換して、前記コンテンツ再生装置に送出するように構成されている。

本願の請求項８に記載の技術によれば、請求項１に記載のコンテンツ転送装置の前記再生制御コマンド受信部は、受信した前記再生制御コマンドを、前記コンテンツ再生装置からのストリーミング要求に応じてコンテンツを送出するストリーミング・サーバーが解釈できる再生制御プロトコルに変換して、前記ストリーミング・サーバーとやり取りするように構成されている。

本願の請求項９に記載の技術によれば、請求項８に記載のコンテンツ転送装置の前記再生制御コマンド受信部は、ＲＴＳＰを解釈できるストリーミング・サーバーに対して、ストリームの変速再生に関する再生制御コマンドをＲＴＳＰの変速転送指示に変換してやり取りするように構成されている。

本願の請求項１０に記載の技術によれば、請求項８に記載のコンテンツ転送装置の前記再生制御コマンド受信部は、ＨＴＴＰしか解釈できないＨＴＴＰ擬似ストリーミング・サーバーに対して、ストリームの再生速度に関する再生制御コマンドをＨＴＴＰストリーミングにおけるコンテンツ・リクエストに変換し、前記再生制御コマンドが指示する速度に応じた速さで前記ＨＴＴＰ擬似ストリーミング・サーバーに対するＨＴＴＰリクエストを発行するように構成されている。

本願の請求項１１に記載の技術によれば、請求項１に記載のコンテンツ転送装置は、ストリーミング・サーバーから受信したコンテンツのストリームを蓄積するストレージをさらに備えている。そして、前記ストリーミング部は、前記再生制御コマンド受信部でストリームの変速再生に関する再生制御コマンドを受信したときに、前記コンテンツ再生装置上で動作するプレイヤーが通常再生と同様な処理で変速再生できるようにストリームを処理してから送出するように構成されている。

本願の請求項１２に記載の技術によれば、請求項１に記載のコンテンツ転送装置の前記チャンネル確立部、前記再生制御コマンド受信部、及び、前記ストリーミング部は、所定のポータル・サーバーからダウンロードし起動するトランスレーション・サーバーの機能として実現される。

本願の請求項１３に記載の技術によれば、請求項１に記載のコンテンツ転送装置は、コンテンツのストリームを送出するストリーミング・サーバーとコンテンツ再生装置との間に介在するエッジ・サーバーとして動作する。

また、本願の請求項１４に記載の技術は、
コンテンツのストリームを要求するコンテンツ再生装置との間でチャンネルをネットワーク上で確立するチャンネル確立ステップと、
前記コンテンツ再生装置からコンテンツのストリームの再生を制御する再生制御コマンドを前記ネットワーク経由で受信する再生制御コマンド受信ステップと、
受信した前記再生制御コマンドに従って、前記チャンネルを用いてコンテンツのストリームを前記コンテンツ再生装置に送出するストリーミング・ステップと、
を有するコンテンツ転送方法である。

また、本願の請求項１５に記載の技術は、
ユーザーの指示に応じて選択したコンテンツのストリーミングをＨＴＴＰリクエストにより要求するナビゲーション部と、
ユーザーの指示に応じてコンテンツのストリーミングの再生制御をＨＴＴＰリクエストにより行なう再生制御部と、
所定のサーバーとの間で確立されたチャンネルを介して受信するコンテンツのストリームを再生するプレイヤーと、
を具備するコンテンツ再生装置である。

また、本願の請求項１６に記載の技術は、
ユーザーの指示に応じて選択したコンテンツのストリーミングをＨＴＴＰリクエストにより要求するナビゲーション・ステップと、
ユーザーの指示に応じてコンテンツのストリーミングの再生制御をＨＴＴＰリクエストにより行なう再生制御ステップと、
所定のサーバーとの間で確立されたチャンネルを介して受信するコンテンツのストリームを再生する再生ステップと、
を有するコンテンツ再生方法である。

また、本願の請求項１７に記載の技術は、
コンテンツの選択とコンテンツの再生制御の指示をＨＴＴＰリクエストで行なうとともに、サービス・プロトコル透過なプレイヤーでコンテンツのストリーム再生を行なうコンテンツ再生装置と、
前記コンテンツ再生装置が選択したコンテンツのストリームを送出するストリーミング・サーバーと、
前記コンテンツ再生装置が発行する再生制御コマンドを前記ストリーミング・サーバーが解釈できるプロトコルに変換して前記ストリーミング・サーバーとやり取りするとともに、ストリーミング・サーバーから送出されたコンテンツのストリームを前記プレイヤーが処理できるフォーマットに変換し、前記コンテンツ再生装置との間で確立したチャンネルを用いてコンテンツのストリームを転送するエッジ・サーバーと、
を具備するコンテンツ配信システムである。

但し、ここで言う「システム」とは、複数の装置（又は特定の機能を実現する機能モジュール）が論理的に集合した物のことを言い、各装置や機能モジュールが単一の筐体内にあるか否かは特に問わない。

本願の請求項１８に記載の技術によれば、請求項１７に記載のコンテンツ配信システムは、前記チャンネルのための配信リソースを確保するリソース・マネジメント・サーバーをさらに備えている。

また、本願の請求項１９に記載の技術は、
コンテンツのストリームを再生するコンテンツ再生装置との間でチャンネルをネットワーク上で確立するチャンネル確立部、
前記コンテンツ再生装置からコンテンツのストリームの再生を制御する再生制御コマンドを前記ネットワーク経由で受信する再生制御コマンド受信部、
受信した前記再生制御コマンドに従って、前記チャンネルを用いてコンテンツのストリームを前記コンテンツ再生装置に送出するストリーミング部、
としてコンピューターを機能させるようコンピューター可読形式で記述されたコンピューター・プログラムである。

また、本願の請求項２０に記載の技術は、
ユーザーの指示に応じて選択したコンテンツのストリーミングをＨＴＴＰリクエストにより要求するナビゲーション部、
ユーザーの指示に応じてコンテンツのストリーミングの再生制御をＨＴＴＰリクエストにより行なう再生制御部、
所定のサーバーとの間で確立されたチャンネルを介して受信するコンテンツのストリームを再生するプレイヤー、
としてコンピューターを機能させるようコンピューター可読形式で記述されたコンピューター・プログラムである。

本願の請求項１９、２０に係る各コンピューター・プログラムは、コンピューター上で所定の処理を実現するようにコンピューター可読形式で記述されたコンピューター・プログラムを定義したものである。換言すれば、本願の請求項１９、２０に係るコンピューター・プログラムをコンピューターにインストールすることによって、コンピューター上では協働的作用が発揮され、本願の請求項１に係るコンテンツ装置、請求項１５に係るコンテンツ再生装置と同様の作用効果をそれぞれ得ることができる。

本明細書で開示する技術によれば、ＩＰＴＶ放送サービスにより配信されるコンテンツのストリームをＩＰＴＶサービス・クライアントに好適に転送することができる優れたコンテンツ転送装置及びコンテンツ転送方法、並びにコンピューター・プログラムを提供することができる。

また、本明細書で開示する技術によれば、ＩＰＴＶサービスにおけるクライアントとしてコンテンツ若しくはチャンネルの選択やコンテンツの再生を好適に行なうことができる優れたコンテンツ再生装置及びコンテンツ再生方法、並びにコンピューター・プログラムを提供することができる。

また、本明細書で開示する技術によれば、ＩＰＴＶクライアントの実装並びにメンテナンスのコストを低減でき、各クライアントに対するサービス品質を均一にすることができる優れたコンテンツ配信システムを提供することができる。

本明細書で開示する技術を適用したＩＰＴＶ配信システムでは、異なる複数のサービス・プロバイダーから提供されるＩＰＴＶサービス・クライアントの機能を、ナビゲーション（コンテンツを選択させる機能）と、再生制御（通常再生（プレイ）、停止（ストップ）、巻き戻し再生（リワインド）、早送り再生（フォワード）、ポーズといったトリックプレイなどのコマンドを送る機能）と、ストリーミング（ＡＶストリームを転送・再生する機能）に分離し、前者２つをブラウザー・アプリケーションとして実現し、後者１つをＩＰＴＶサービス・プロトコルと透過な（ＩＰＴＶサービス・プロトコルの相違に依存しない共通の）プレイヤーとして実装するようにしている。したがって、デバイス・ベンダーは、サービス毎のブラウザー・アプリケーションを開発するだけでよく、複数の異なるサービス向けにクライアントを個別に実装したりメンテナンスしたりするコストを低減することができる。また、サービス・プロバイダーにとっては、エンド・ユーザーがブラウザーを介して選択したコンテンツを、ブラウザー上で指示した再生制御コマンドに従って、品質が保証されたネットワークを通してＲＴＰプロトコルにてストリーミングするので、サービス品質の均質化を図ることができる。また、ＨＴＴＰストリーミグ・クライアントを利用するにもかかわらず、ＩＰ放送配信におけるチャンネル・チェンジの際のパフォーマンスを各段に向上させることができる。

本明細書で開示する技術のさらに他の目的、特徴や利点は、後述する実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。

図１は、本明細書で開示する技術を適用して実現されるＩＰＴＶ配信システムの構成を模式的に示した図である。 図２は、ＩＰＴＶ配信システム１００において常設ストリーミング・セッションを利用してコンテンツの配信サービスを行なう具体的構成例を示した図である。 図３は、ＩＰＴＶ配信システム１００において常設ストリーミング・セッションを利用してコンテンツ・ストリームの配信サービスを行なうシーケンス例を示した図である。 図４は、ＩＰＴＶ配信システム１００においてクライアント・デバイス２３１上でコンテンツをストリーミング再生並びに再生制御するシーケンス例をより詳細に示した図である。 図５は、ＩＰＴＶ配信システム１００で高速チャンネル・チェンジを実現する仕組みを説明するための図である。 図６は、ＩＰＴＶ配信システム１００において常設ストリーミング・セッションを利用してチャンネル・ストリームの配信サービスを行なうシーケンス例を示した図である。 図７は、ＩＰＴＶ配信システム１００において常設ストリーミング・セッションを利用してチャンネル・ストリームの配信サービスを行なうシーケンス例（チャンネル・ストリームの変速再生に対応する場合）を示した図である。 図８は、ＩＰＴＶサービス・トランスレーション・サーバーの機能的構成を模式的に示した図である。 図９は、ＩＰＴＶサービスにおけるクライアント・デバイス２３１側のエンティティーを示した図である。 図１０は、ＳＩＰ／ＲＴＳＰプロトコルを用いてストリーミング・セッションの確立を行なうとともにＲＴＰプロトコルを用いてＡＶストリームを転送する映像配信システム（従来例）を模式的に示した図である。

以下、図面を参照しながら本明細書で開示する技術の実施形態について詳細に説明する。

図１には、本明細書で開示する技術を適用して実現されるＩＰＴＶ配信システム１００の構成を模式的に示している。図示の例では、２つのキャリアからそれぞれＩＰＴＶサービスＡとＩＰＴＶサービスＢという独自のサービスが提供され、各サービス用のサーバーが設置されている。

本明細書で開示する技術では、異なる複数のサービス・プロバイダーから提供されるＩＰＴＶサービス・クライアントの機能を、ナビゲーション（コンテンツを選択させる機能）と、再生制御（通常再生（プレイ）、停止（ストップ）、巻き戻し再生（リワインド）、早送り再生（フォワード）、ポーズといったトリックプレイなどのコマンドを送る機能）と、ストリーミング（ＡＶストリームを転送・再生する機能）に分離し、前者２つをブラウザー・アプリケーションとして実現し、後者１つをＩＰＴＶサービス・プロトコルと透過な（ＩＰＴＶサービス・プロトコルの相違に依存しない共通の）プレイヤーとして実装するようにしている。ナビゲーション及び再生制御機能を備えたブラウザー・アプリケーションは、キャリアのポータル・サイトから、ポータル・アプリケーションとして提供される。

図１に示す例では、サービスＡサーバー１１０からは、サービスＡ独自のナビゲーション及び再生制御プロトコルが、サービスＡ向けブラウザー・アプリケーション１３１として提供されている。エンド・ユーザー側では、サービスＡサーバー１１０からサービスＡ向けブラウザー・アプリケーション１３１をＴＶ受像機などのクライアント・デバイス１３０にダウンロードして、ブラウザー実行環境１３３でこのアプリケーションを起動することで、ナビゲーションすなわちサービスＡが配信サービスするコンテンツの選択並びにコンテンツの再生制御をブラウザー上で行なうことができる。

同様に、サービスＢサーバー１２０からは、サービスＢ独自のナビゲーション及び再生制御プロトコルが、サービスＢ向けブラウザー・アプリケーション１３２として提供されている。エンド・ユーザー側では、サービスＢサーバーからサービスＢ向けブラウザー・アプリケーション１３２をクライアント・デバイス１３０にダウンロードして、ブラウザー実行環境１３３でこのアプリケーションを起動することで、ナビゲーション並びにコンテンツの再生制御をブラウザー上で行なうことができる。

そして、クライアント・デバイス１３０上で、サービスＡサーバー１１０からストリーミング配信されるコンテンツを、エッジ・サーバー１４０経由で受信して、クライアント・デバイス上で動作するプレイヤー１３４を用いて再生する。

エッジ・サーバー１４０は、サービスＡサーバー１１０から、サービスＡ独自ストリーミング・プロトコル・トランスレーション・サーバー・アプリケーションをダウンロードし、同サーバーを起動している。後述するように、エッジ・サーバー１４０上で動作するサービスＡ独自のＩＰＴＶサービス・トランスレーション・サーバーを経由したクライアント・デバイス１１０へのストリーミング・セッションは常設される。

ここで、サービスＡのストリーミング・サーバーとエッジ・サーバー１４０間はＳＩＰ、ＲＴＳＰ、ＲＰ／ＲＴＣＰなどプロバイダー独自のストリーミング・セッションが張られている（後述）。サービスＡ独自のＩＰＴＶサービス・トランスレーション・サーバーとしてのエッジ・サーバー１４０は、ストリーミング・サーバーから送出される独自のストリーム・フォーマットを、クライアント・デバイス２３１側のプレイヤー１３４が処理できるストリーム・フォーマットに変換して送出する。したがって、クライアント・デバイス１３０上では、ウィンドウズ（登録商標）のメディア・プレイヤーなどの、ＩＰＴＶサービス・プロトコルと透過な（ＩＰＴＶサービス・プロトコルの相違に依存しない共通の）プレイヤーを用いて、サービスＡから提供されるコンテンツを再生することができる。また、サービスＡ独自ストリーミング・プロトコル・トランスレーション・サーバーとしてのエッジ・サーバー１４０は、クライアント・デバイス１２０からの再生制御コマンドを、ストリーミング・サーバーが解釈できる独自ＩＰＴＶサービス再生制御プロトコルに変換してやり取りする。

プレイヤー１３４上でストリーム配信されるコンテンツを再生している間、エンド・ユーザーは、ブラウザーを介して再生制御を行なう。エッジ・サーバー１４０は、ブラウザーからＨＴＴＰリクエストとして送信される再生制御コマンドに従って、プレイヤー１３４へのストリーミング動作を制御する。

同様に、エンド・ユーザーは、サービスＢサーバー１２０からストリーミング配信されるコンテンツを、エッジ・サーバー１５０経由で受信して、クライアント・デバイス１３０上で動作するプレイヤー１３４を用いて再生する。

エッジ・サーバー１５０は、サービスＢサーバー１２０からダウンロードしたサービスＢ独自のＩＰＴＶサービス・トランスレーション・サーバー・アプリケーションを起動している。後述するように、エッジ・サーバー１５０上で動作するサービスＢ独自のＩＰＴＶサービス・トランスレーション・サーバーを経由したクライアント・デバイス１１０へのストリーミング・セッションは常設される。

ここで、サービスＢ独自のＩＰＴＶサービス・トランスレーション・サーバーとしてのエッジ・サーバー１５０は、サービスＢのストリーミング・サーバーから送出される独自のストリーム・フォーマットを、クライアント・デバイス２３１側のプレイヤー１３４が処理できるストリーム・フォーマットに変換して送出する。したがって、クライアント・デバイス１３０上では、ＩＰＴＶサービス・プロトコルと透過なプレイヤー１３４を用いて、サービスＢから提供されるコンテンツを再生することができる。また、サービスＢ独自のＩＰＴＶサービス・トランスレーション・サーバーとしてのエッジ・サーバー１５０は、クライアント・デバイス１２０からの再生制御コマンドを、ストリーミング・サーバーが解釈できる独自ＩＰＴＶサービス再生制御プロトコルに変換してやり取りする。

プレイヤー１３４上でストリーム配信されるコンテンツを再生している間、エンド・ユーザーは、ブラウザーを介して再生制御を行なう。エッジ・サーバー１５０は、ブラウザーからＨＴＴＰリクエストとして送信される再生制御コマンドに従って、プレイヤーへのストリーミング動作を制御する。

図１に示したＩＰＴＶ配信システム１００では、サービスＡ、サービスＢなどを提供するサービス・オペレーターは、クライアント・デバイス１３０にポータル・アプリケーションとしてダウンロードするサービス毎のブラウザー・アプリケーションを開発しメンテナンスを行なうだけで、エンド・ユーザーに対して、各クライアント間の実装上の相違に依らない均一なサービスを提供することができ、時間とコストの負担はかなり軽減される。

また、デバイス・ベンダーは、クライアント・デバイス１３０上で動作する標準のブラウザー実行環境のみを開発しメンテナンスを行なうだけでよく、キャリア毎の異なる独自のＩＰＴＶサービス・プロトコルを複数したり、キャリア毎に異なる独自のＩＰＴＶクライアントそのものを複数実装したりする場合に比べ、コストの負担はかなり軽減される。

図２には、ＩＰＴＶ配信システム１００において常設ストリーミング・セッションを利用してコンテンツの配信サービスを行なう具体的構成例を示している。同図では、説明の簡素化のため、１つの映像配信サービスに着目してＩＰＴＶ配信システム１００を描いている。

コア・ネットワーク２０１並びにアクセス・ネットワーク２０２は、ＩＰＴＶ配信サービスを提供するキャリア（サービス・プロバイダー）が所有するネットワークである。コア・ネットワーク２０１はいわゆる基幹ネットワークに相当し、アクセス・ネットワーク２０２は光ファイバー網などで構成される高速ネットワークである。図示の例では、キャリアは、コア・ネットワーク２０１上に、サービス・ディスカバリー・サーバー２１１、ポータル・サーバー２１２、ストリーミング・サーバー２１３、ＳＩＰ、ＲＴＳＰ、ＲＴＰ／ＲＴＣＰなどのプロバイダー独自のストリーミング・サーバー２１３、リソース・マネジメント・サーバー２１５などのＩＰＴＶサービスにおけるサーバー側のエンティティーが設置されている。また、プロバイダー・ネットワーク内の地域毎に、コア・ネットワーク２０１とアクセス・ネットワーク２０２を接続するエッジ・サーバー２１６が設置されている。エッジ・サーバー２１６は、ストリーミング・サーバー２１３からクライアント・デバイス２３１へのストリーミングを中継する。

サービス・ディスカバリー・サーバー２１１は、クライアント・デバイス２３１のＩＰＴＶクライアント・マネージャー２３３がアクセスして、そのクライアントがアクセスできるＩＰＴＶサービスを発見するためのサーバーである。サービス・ディスカバリー・サーバー２１１は、サービス提供可能なＩＰＴＶサービスの属性を管理する。ＩＰＴＶサービス・プロバイダーは、サービス・ディスカバリー・サーバー２１１に対して、そのサービス・アクセスに必要となる情報を登録しておく。サービス・ディスカバリー・サーバー２１１がクライアント側に提供する情報要素として、ＩＰＴＶサービスの名前、ＩＰＴＶサービスの概要、ＩＰＴＶサービス・ポータル（ポータル・サーバー）のＵＲＬを挙げることができる。

ポータル・サーバー２１２は、クライアント・デバイス２３１のブラウザー２３４上で実行されるポータル・アプリケーション（コンテンツ・ナビゲーションと再生制御を担うアプリケーション）に対して、ＩＰＴＶポータル・ページ（ＶｏＤコンテンツや、ＩＰ放送チャンネルのショップ・フロント（購入コンテンツ選択と購入処理を行なうサイト））、並びに、ポータル・ページから導入される各々のコンテンツやチャンネルの再生制御画面を提供するサーバーである。

エッジ・サーバー２１６は、地域毎のアクセス・ネットワーク集線装置（局舎）などの近辺に設置されるサーバーである（クライアント側からアクセス可能なところであれば、ホーム・ネットワーク２０３以外のどこでもよく、特にロケーションは問わない）。

本実施形態では、エッジ・サーバー２１６は、例えばポータル・サーバー２１２からダウンロードした所定のサーバー・アプリケーションを実行して、ＩＰＴＶサービス・トランスレーション・サーバーとして機能する。図８には、ＩＰＴＶサービス・トランスレーション・サーバーの機能的構成を模式的に示している。ＩＰＴＶサービス・トランスレーション・サーバー（ストリーミング部８０３）は、そのエッジ・サーバー２１３が担当するクライアントからの、コンテンツ又はチャンネルのストリーミング・リクエストを受けて、当該ストリームを送出する。また、ＩＰＴＶサービス・トランスレーション・サーバー（専用チャンネル確立部８０１）は、クライアント・デバイス２３１上のプレイヤー２３５との間で、専用チャンネルとして、帯域の保証された１つのＨＴＴＰ擬似ストリーミング・チャンネル（セッション）を確立する。また、ストリーミング・サーバー２１３とトランスレーション・サーバー間では、ＳＩＰ、ＲＴＳＰ、ＲＴＰ／ＲＴＣＰなどのプロバイダー独自のストリーミング・セッションが確立される。ストリーミング部８０３は、常にこのチャンネル上ですべてのストリーミングをプレイヤー２３５側に転送する。なお、必要であれば、ＨＴＴＰ擬似ストリーミングのセッションのセキュリティーは、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）などで保護される。エッジ・サーバー２１６上のＩＰＴＶサービス・トランスレーション・サーバーは、クライアント・デバイス２３１上のプレイヤー２３５からは常に１つのＵＲＬでアクセスされる。また、ＩＰＴＶサービス・トランスレーション・サーバー（再生制御コマンド受信部８０２）は、クライアント・デバイス２３１上で動作するポータル・アプリケーションから、ストリーム再生に関する再生制御コマンドを受信すると、プレイヤー上では通常再生と同様な処理で済むようにストリームの処理を行なう。

リソース・マネジメント・サーバー２１５は、エッジ・サーバー２１６上のＩＰＴＶサービス・トランスレーション・サーバー（専用チャンネル確立部８０１）からの要求に従って、ストリーミング・サーバー２１３との間、及び、クライアント・デバイス２３１上のプレイヤーとの間の配信リソースの確保を行なう。配信リソースの確保には、ＮＧＮなどのキャリア専用網で利用されているＩＭＳ／ＳＩＰプロトコルや、今後標準化されているＯｐｅｎＦｌｏｗ−ＡＰＩ、あるいはキャリア・ネットワーク機器独自のプロトコルなどを利用する（後述）。

ストリーミング・サーバー２１３は、ＩＰＴＶサービス・トランスレーション・サーバーからのコンテンツのストリーミング・リクエスト又はチャンネルのストリーミング・リクエストを受けて、該当するコンテンツのストリームを送出する。

一方、エンド・ユーザーの宅内には、ホーム・ネットワーク２０３が付設されている。ホーム・ネットワーク２０３は、モデム若しくはルーター２３２を介して、アクセス・ネットワーク２０２などのキャリアのネットワークと相互接続している。ホーム・ネットワーク２０３は、例えばＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）などの技術仕様に従うが、本明細書で開示する技術の要旨には直接関連しないので、この種の技術仕様の詳細な説明は省略する。

ホーム・ネットワーク２０３には、クライアント・デバイス２３１が接続されている。クライアント・デバイス２３１上では、ＩＰＴＶクライアント・マネージャー２３３、ブラウザー２３４、プレイヤー２３５などのエンティティーが動作する。そして、ブラウザー２３５が実行するポータル・アプリケーションによりナビゲーション（コンテンツを選択させる機能）、再生制御（通常再生（プレイ）、停止（ストップ）、巻き戻し再生（リワインド）、早送り再生（フォワード）、ポーズといったトリックプレイなどのコマンドを送る機能）を実現するとともに、プレイヤー２３５によりストリーミング（ＡＶストリームを転送・再生する機能）の機能を実現する。

ＩＰＴＶクライアント・マネージャー２３３、ブラウザー２３４、プレイヤー２３５の各々は、ＩＰＴＶサービスにおけるクライアント・デバイス２３１側のエンティティーである（図９を参照のこと）。

ＩＰＴＶクライアント・マネージャー２３３は、起動時に、サービス・ディスカバリー・サーバー２１１から、ＩＰＴＶサービス・ディスカバリー・インフォメーションを取得し、そこで提供されるポータルＵＲＬを基にブラウザー２３４を起動する。

ブラウザー２３４は、ＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｙ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ブラウザー２３４に相当し、ＪａｖａＳｃｒｉｐｔ（登録商標）アプリケーションの実行環境も含む。ブラウザー２３４は、ポータルＵＲＬ（ポータル・サーバー２１２）からダウンロードされるポータル・ブラウザ・ページ（ポータル・アプリケーション）が実行されるモジュールである。ブラウザー２３４は、エンド・ユーザーとＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）処理系を介してのコンテンツの提示、対話管理などを行なう。ポータル・アプリケーションでは、ブラウザー２３４は、コンテンツやチャンネルの選択の他、選択されたコンテンツ・チャンネルの再生制御の画面も処理する。

プレイヤー２３５は、ストリームを再生・提示するモジュールであり、ブラウザー外部に実装される場合の他に、プレイヤー２３５がブラウザー２３４に組み込まれる場合がある。本実施形態では、プレイヤー２３５は、エッジ・サーバー２１６上のＩＰＴＶサービス・トランスレーション・サーバーとの間に、専用チャンネルとして、帯域の保証された１つのＨＴＴＰ擬似ストリーミング・チャンネル（セッション）を確立し、常にこの上ですべてのストリーミングを受ける。必要であれば、ＨＴＴＰ擬似ストリーミングのセッションのセキュリティーは、ＳＳＬなどで保護される。

図３には、ＩＰＴＶ配信システム１００において常設ストリーミング・セッションを利用してコンテンツ・ストリームの配信サービスを行なうシーケンス例（但し、専用チャンネルを確立するまで）を示している。図示のシーケンスでは、クライアント側からのコンテンツのストリーミング・リクエストに応じてストリーミングが行なわれる。以下、図３を参照しながら、図２に示したＩＰＴＶ配信システム１００の仕組みについて説明する。

クライアント・デバイス２３１上のＩＰＴＶクライアント・マネージャー２３３は、サービス・ディスカバリー・サーバー２１１から、ＩＰＴＶサービスを提供するサービス・プロバイダーを検索するためのリスト、すなわちサービス・ディスカバリー・インフォメーションを取得する（ＳＥＱ３０１）。サービス・ディスカバリー・インフォメーションには、ＩＰＴＶサービスの属性として、サービスの名称やＩＰＴＶサービスのポータルＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）が記述されている。ＩＰＴＶクライアント・マネージャー２３３は、そのポータルＵＲＬを基に、ブラウザー２３４を起動する（ＳＥＱ３０２）。

ブラウザー２３４は、ポータルＵＲＬを基に、ＩＰＴＶポータル・サーバー２１２からポータル・ページをダウンロード（ＤＬ）して、エンド・ユーザーに提示する（ＳＥＱ３０３）。ここで、ポータル・ページそのものはＩＰＴＶサービス・プロバイダーが開発するため、クライアント・ベンダーは、ブラウザー実行環境だけを実装すればよく、図１０に示した従来システムのようにプロバイダー毎の固有のＩＰＴＶクライアントを実装する必要はない。さらに、コンテンツの選択処理にまつわるコンテンツ・ナビゲーションのシーケンスはすべてサービス・プロバイダーが設計することができ、且つ、変更なども容易である。したがって、サービス・プロバイダーは、エンド・ユーザーに提供するサービス品質の均一化、メンテナンス・コストの低減化を図ることができる。

ここで、ポータル・ページには、例えばＪａｖａＳｃｒｉｐｔ（登録商標）で記述されたポータル・アプリケーションが含まれている。エンド・ユーザーがブラウザー２３４上に表示されたポータル・ページを介して所望のＩＰＴＶコンテンツや放送チャンネルを選択したことに応答して、ポータル・アプリケーションが実行される（ＳＥＱ３０４）。あるいは、ポータル・ページを開いた時点でポータル・アプリケーションが実行される。

サービスＡ向けブラウザー・アプリケーションやサービスＢ向けブラウザー・アプリケーションなどのポータル・アプリケーションは、トランスレーション・サーバー起動要求として、プロバイダー・ネットワーク内で自地域に設置されているエッジ・サーバー２１６に対して、当該ＩＰＴＶサービス・トランスレーション・サーバー・アプリケーションをダウンロード（ＤＬ）して起動するよう依頼する（ＳＥＱ３０５）。若しくは、事前に利用される可能性のある複数のＩＰＴＶサービス・トランスレーション・サーバー・アプリケーションを、事前にポータル・サーバー２１２からエッジ・サーバー２１６にダウンロードしておいてもよい。但し、ダウンロードしてから実行するオーバーヘッドが十分小さければ、メンテナンス・バージョン管理などの便宜を図るため、この種のアプリケーションを逐次ダウンロードするのが好ましい。エッジ・サーバー２１６は、ポータル・サーバー２１２からダウンロードしたＩＰＴＶサービス・トランスレーション・サーバーを起動すると（ＳＥＱ３０６）、要求元のポータル・アプリケーションにトランスレーション・サーバー起動要求に対する応答を返す。

また、ポータル・アプリケーションは、クライアント・デバイス２３１上のプレイヤー（ＡＶストリーミング・プロトコルを処理してストリームを再生する実装）２３５に対して、エッジ・サーバー２１６上で動作するＩＰＴＶサービス・トランスレーション・サーバーとの間にＩＰＴＶ専用チャンネルを確立するよう依頼する（ＳＥＱ３０７）。そして、プレイヤー２３５は、エッジ・サーバー２１６にＩＰＴＶ専用チャンネルの確立要求を発行する（ＳＥＱ３０８）。このＩＰＴＶ専用チャンネルは、各クライアントに対して個別に割り当てられる専用のＨＴＴＰストリーミング・セッションである（個々のＨＴＴＰ要求／取得トランザクションで完結するＴＣＰセッションではなく、より持続時間の長いセッションの意味）。

エッジ・サーバー２１６上のＩＰＴＶサービス・トランスレーション・サーバーは、プレイヤー２３５からのＩＰＴＶ専用チャネル確立要求に応答して、リソース・マネジメント・サーバー２１５に対して、当該トランスレーション・サーバーとプレイヤー２３５間のＩＰＴＶ専用チャンネルを通してのストリーミングのために必要なＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、記憶領域、ネットワーク・インターフェースなどの配信リソースの確保を要求する（ＳＥＱ３０９）。リソース・・マネジメント・サーバー２１５は、この要求に応答して、ストリーミング・セッションが確立してから解放するまで、上記の通信リソースを常に確保するものとする（ＳＥＱ３１０）。

なお、配信リソースの確保には、ＮＧＮなどのキャリア専用網で利用されているＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）／ＳＩＰプロトコルや、ＯｐｅｎＦｌｏｗ−ＡＰＩ、あるいはキャリア・ネットワーク独自のプロコルなどを利用することができる。ここで、ＩＭＳは、固定電話網や移動体通信網など、回路スイッチやパケット・スイッチが異なる公衆通信サービスをＳＩＰで統合し、マルチメディア・サービスを実現させる次世代の公衆通信網向けの通信方式である。また、ＯｐｅｎＦｌｏｗは、ＯｐｅｎＦｌｏｗスイッチング・コンソーシアムが提唱しているネットワーク制御技術であり、ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスやＩＰアドレス、ポート番号などの組み合わせによって決定される一連の通信を「フロー」として定義し、フロー単位で経路制御を行なって、品質の確保やネットワークの利用率を向上させる通信方式である。本実施形態では、当該エンド・ユーザーが契約しているＳＬＡ（Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ）にて定義されている配信リソース／品質レベルを提供するのに必要な配信リソースが確保される。ＳＬＡは、通信サービスの事業者が、利用者にサービスの品質を保証する制度であり、回線の最低通信速度やネットワーク内の平均遅延時間、利用不能時間の上限など、サービス品質の補償項目や、それらを実現できなかった場合の利用料金の減額に関する規定などをサービス契約に含めることを指す。

配信リソースが確保されると、ＩＰＴＶ専用チャンネルＩＰＴＶ配信サービスにおけるＱｏＳが保証される。そこで、エッジ・サーバー２１６上のＩＰＴＶサービス・トランスレーション・サーバーとプレイヤー２３５間では、配信リソースが確保された、ＩＰＴＶ専用チャンネルとして、帯域の保証された１つのＨＴＴＰ擬似ストリーミング・チャンネル（セッション）を確立する（ＳＥＱ３１１、３１２）。ＩＰＴＶ専用チャンネルは、常設であり、プレイヤー２３５からのＨＴＴＰリクエスト送信とエッジ・サーバー２１６上のトランスレーション・サーバーからのＨＴＴＰレスポンス返信が常時可能な帯域保証型のパスである。エッジ・サーバー２１６上のＩＰＴＶサービス・トランスレーション・サーバーは、常にこのチャンネル上ですべてのストリーミングをプレイヤー２３５側に転送する。必要であれば、ＨＴＴＰ擬似ストリーミングのセッションのセキュリティーは、ＳＳＬ）などで保護される。

その後、エンド・ユーザーは、ブラウザー２３４が実行するポータル・アプリケーションのコンテンツ・ナビゲーション機能により、コンテンツの選択を行なう。コンテンツ・ナビゲーションの過程で、ブラウザー上のポータル・アプリケーションがポータル・サーバーとやり取りし、エンド・ユーザーは、コンテンツの属性情報（タイトル、概要、価格など）を照会しながら、所望のコンテンツを選択することができる。

ポータル・アプリケーションは、エッジ・サーバー２１６上のＩＰＴＶサービス・トランスレーション・サーバーに対して、エンド・ユーザーが選択したコンテンツのＵＲＬとともにストリーミング要求を発行して、コンテンツのストリーム送出を指示する。これに対し、ＩＰＴＶサービス・トランスレーション・サーバーは、常設ストリーミング・セッションを利用してＵＲＬで指示されたコンテンツのストリームを送出する。そして、クライアント・デバイス２３１上では、プレイヤーがコンテンツのストリーミング再生を行なう。

図４には、ＩＰＴＶ配信システム１００において、上記のように常設ストリーミング・セッションを利用したコンテンツ・ストリームをクライアント・デバイス２３１上で再生制御するシーケンス例（専用チャンネルを確立した以降の処理）をより詳細に示している。

エッジ・サーバー２１６上のトランスレーション・サーバーとプレイヤー２３５の間で専用チャンネルが確立すると、エンド・ユーザーは、ブラウザー２３４が実行するポータル・アプリケーションのコンテンツ・ナビゲーション機能により、コンテンツの選択を行なう（ＳＥＱ４０１）。コンテンツ・ナビゲーションの過程で、ブラウザー２３４上のポータル・アプリケーションがポータル・サーバーとやり取りし、エンド・ユーザーは、コンテンツの属性情報（タイトル、概要、価格など）を照会しながら、所望のコンテンツを選択することができる。

エンド・ユーザーは、ブラウザー２３４が実行するポータル・アプリケーションの再生制御機能を利用して、通常再生（プレイ）、停止（ストップ）、巻き戻し再生（リワインド）、早送り再生（フォワード）、ポーズといったトリックプレイなどの再生制御を行なうことができる。

まず、コンテンツのストリームを通常速度で再生する場合について説明する。

エンド・ユーザーは、上記のようにしてストリーミング再生するコンテンツを選択した後、ポータル・アプリケーションを実行するブラウザー画面上で、ストリーミング中のコンテンツの通常再生を指示する（ＳＥＱ４０２）。

すると、ブラウザー２３４上のポータル・アプリケーションは、エッジ・サーバー２１６上のトランスレーション・サーバーに対して、エンド・ユーザーが選択したコンテンツのＵＲＬとともに、通常再生を指示する再生制御コマンドを発行し、コンテンツ・ストリームの送出を指示する（ＳＥＱ４０３）。

エンド・ユーザーからの再生指示のインタラクションは、すべてポータル・アプリケーションが検知して、再生制御コマンドとしてエッジ・サーバー２１６上のトランスレーション・サーバーに通知する。

ここで、ポータル・アプリケーションは、ＡＪＡＸ（Ａｓｙｎｃｈｒｏｎｕｏｓ ＪａｖａＳｃｒｉｐｔ（登録商標） ＋ ＸＭＬ）などのＨＴＴＰリクエストで再生指示を行なう。エッジ・サーバー２１６上のトランスレーション・サーバーは、クライアント・デバイス２３１上でポータル・アプリケーションとして実行されるブラウザー・スクリプトからの再生制御コマンドを、ストリーミング・サーバー２１３が解釈できる独自ＩＰＴＶサービス再生制御プロトコルに変換してやり取りする。すなわち、トランスレーション・サーバーがストリーミング・サーバー２１３に対し再生指示を行なう（ＳＥＱ４０４）。

例えば、ストリーミング・サーバー２１３がＲＴＳＰを解釈できるならば、トランスレーション・サーバーは、ポータル・アプリケーションからの再生制御コマンドを、ＲＴＳＰの転送指示に変換して転送する。又は、ストリーミング・サーバー２１３がＨＴＴＰしか解釈できないＨＴＴＰ擬似ストリーミング・サーバーの場合には、トランスレーション・サーバーは、ポータル・アプリケーションからの再生制御コマンドを、ＨＴＴＰ擬似ストリーミングにおけるコンテンツ・リクエストに変換して転送する。

これに対し、ストリーミング・サーバー２１３は、再生制御コマンドで指示された通常速度で、選択されたコンテンツのストリームを送出する（ＳＥＱ４０５）。ストリーミング・サーバー２１３は、ＲＴＰなどでストリーミングを行なうか、又は、ＨＴＴＰ擬似ストリーミングのレスポンスを返す。

エッジ・サーバー２１６上のトランスレーション・サーバーは、ストリーミング・サーバー２１３から送出されるプロバイダー独自のストリーム・フォーマット（トランスポート・プロトコル（ＲＴＳＰ／ＲＴＰ／ＲＴＣＰなど）／コーデック／コンテナ）を、クライアント・デバイス２３１上で動作するプレイヤーが処理できるフォーマット（ＨＴＴＰストリーミング／クライアント・プレイヤーに処理可能なコーデック／コンテナ）に変換して送出（ＨＴＴＰ擬似ストリーミング）する（ＳＥＱ４０６）。そして、クライアント・デバイス２３１上では、プレイヤーが受信したストリームの再生を行なう（ＳＥＱ４０７）。

続いて、エンド・ユーザーは、コンテンツのストリームを変速再生する場合について説明する。

エンド・ユーザーは、例えば通常速度でストリーム再生中に、ポータル・アプリケーションを実行するブラウザー２３４画面上で、ストリーミング中のコンテンツの変速再生を指示する（ＳＥＱ４１１）。

すると、ポータル・アプリケーションは、エッジ・サーバー２１６上のトランスレーション・サーバーに対して、変速再生を指示する再生制御コマンドを発行し、コンテンツ・ストリームの送出を指示する（ＳＥＱ４１２）。エンド・ユーザーからのトリックプレイ指示のインタラクションは、すべてポータル・アプリケーションが検知して、再生制御コマンドとしてエッジ・サーバー２１６上のトランスレーション・サーバーに通知する。

ポータル・アプリケーションはＡＪＡＸなどのＨＴＴＰリクエストで再生指示を行なっている。そこで、エッジ・サーバー２１６上のトランスレーション・サーバーは、クライアント・デバイス２３１上でポータル・アプリケーションとして実行されるブラウザー・スクリプトから変速再生を指示する再生制御コマンドを受信すると、ストリーミング・サーバー２１３が解釈できる独自ＩＰＴＶサービス再生制御プロトコルに変換して再生指示を行なう（ＳＥＱ４１３）。これに対し、ストリーミング・サーバー２１３は、再生制御コマンドで指示された速度で、選択されたコンテンツのストリームを変速転送する（ＳＥＱ４１４）。ストリーミング・サーバー２１３は、ＲＴＰなどでストリーミングを行なうか、又は、ＨＴＴＰ擬似ストリーミングのレスポンスを返す。

例えば、ストリーミング・サーバー２１３がＲＴＳＰを解釈できるならば、トランスレーション・サーバーは、ポータル・アプリケーションからの再生制御コマンドを、ＲＴＳＰの変速転送指示に変換して転送する。変速再生指示が２倍速であるならば、ストリーミング・サーバー２１３からは２倍速でコンテンツのストリームが送出される。又は、ストリーミング・サーバー２１３がＨＴＴＰしか解釈できないＨＴＴＰ擬似ストリーミング・サーバーの場合には、トランスレーション・サーバーは、通常の２倍の速さでＨＴＴＰリクエストを発行して、ストリーミング・サーバー２１６から２倍の速度でコンテンツのストリームを取得する。

エッジ・サーバー２１６上のトランスレーション・サーバーは、上記のいずれかの方法により変速のコンテンツを受信すると、クライアント・デバイス２３１側のプレイヤー２３５が通常再生と同様な処理で済むように、ストリームを処理して転送する（ＳＥＱ４１５）。このとき、トランスレーション・サーバーは、ストリーミング・サーバー２１３から送出されるプロバイダー独自のストリーム・フォーマット（トランスポート・プロトコル（ＲＴＳＰ／ＲＴＰ／ＲＴＳＰなど）／コーデック／コンテナ）を、クライアント・デバイス２３１上で動作するプレイヤーが処理できるフォーマット（ＨＴＴＰストリーミング／クライアント・プレイヤー２３５に処理可能なコーデック／コンテナ）に変換して送出（ＨＴＴＰ擬似ストリーミング）する（ＳＥＱ４１５）。そして、クライアント・デバイス２３１上では、プレイヤー２３５が受信したストリームの再生を行なう（ＳＥＱ４１６）。

上記のようにトランスレーション・サーバーが介在するというＩＰＴＶ配信システム１００の構成をとることにより、クライアント・ベンダーにとっては、サービス毎の独自なサービス・プロトコルをクライアントのアプリケーションとして実装する必要がなくなり、異なるサービス（ネットワーク・サービス、インターネット・サービス）のプロバイダーのサービスに対応させたクライアントの開発コストを大幅に低減することができるようになる。

続いて、ＩＰＴＶ配信システム１００で高速チャンネル・チェンジを実現する仕組みについて、図５を参照しながら説明する。

図５に示すように、コア・ネットワーク２０１においては、ストリーミング・サーバー２１３からエッジ・サーバー２１６までは、そのエッジ・サーバー２１６上のＩＰＴＶサービス・トランスレーション・サーバーに対応するＩＰＴＶサービスで提供される、ＩＰ放送チャンネル（ライブ中継ストリームなどを含む）がすべて送信されているものとする。すなわち、エッジ・サーバー２１６にＩＰＴＶサービス・トランスレーション・サーバーがダウンロードされ起動されると同時に、そのＩＰＴＶサービス・トランスレーション・サーバーがアクセス（サービス提供）可能なすべてのＩＰ放送に対して、ストリームの送付要求が行なわれる。

具体的には、コア・ネットワーク２０１におけるＩＰ放送チャンネルのトランスポート・プロトコルにマルチキャストが利用される場合には、トランスレーション・サーバーがエッジ・サーバー２１６にダウンロードされて起動された直後に、コア・ネットワーク２０１内のマルチキャスト・ルーターを介して、ストリーミング・サーバー２１３にてサービス提供可能なすべてのマルチキャスト・チャンネルに対して参加（取得）要求が行なわれる。ストリーミング・サーバー２１３からトランスレーション・サーバーへのチャンネル・ストリームの送信には、ＲＴＰ／マルチキャストが利用される。また、マルチキャスト・チャンネルへの参加には、ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）やＭＬＤ（Ｍｕｌｔｉｃａｓｔ Ｌｉｓｔｅｎｅｒ Ｄｉｓｃｏｖｅｒｙ）が利用される。

クライアント・デバイス２３１のブラウザー上で動作するポータル・アプリケーションでチャンネルが選択された場合、ポータル・アプリケーションは、ＡＪＡＸ／ＨＴＴＰリクエストとして、エッジ・サーバー２１６上のＩＰＴＶサービス・トランスレーション・サーバーに対してチャンネル選択／切り替えを要求する。そして、トランスレーション・サーバーは、所望のチャンネル・ストリームに直ちにチャンネル・スイッチする。エンド・ユーザーがとあるチャンネルを選択したときには、ストリーミング・サーバー２１３から既にマルチキャスト送信されているので、エッジ・サーバー２１６上のＩＰＴＶサービス・トランスレーション・サーバーは、即座に対応するマルチキャスト・ストリーミングを、クライアント・デバイス２３１上のプレイヤーに送信（すなわち、ＨＴＴＰストリーミング）することができる。

エンド・ユーザーがチャンネル・ザッピングなどにより異なるチャンネルを選択すると、新しく選択されるチャンネルのストリームも既にストリーミング・サーバー２１３からマルチキャストされているので、瞬時に所望のチャンネルにチャンネル・スイッチすることが可能となる。したがって、チャンネル・ザッピングのパフォーマンスが格段に向上する。なお、チャンネル切り替えの前後でも、クライアントは一貫して（トランスレーション・サーバーを指す）同一のＵＲＬからＨＴＴＰストリーミングを受信する。

但し、コア・ネットワーク２０１のリソース上の制限で、該当するＩＰＴＶサービス・トランスレーション・サーバーがアクセス可能なすべてのマルチキャスト・チャンネル・ストリーミングに参加（登録）できない場合には、ネットワーク・リソースの負荷軽減策を講じることも可能である。例えば、エンド・ユーザーがとあるチャンネルを選択した際に、そのチャンネルの前後（チャンネル・リスト上の前後の場合もあれば、そのエンド・ユーザーの嗜好を考慮に入れたアクセス頻度の高いチャンネルのみを並べたチャンネル・リスト上の前後など）のチャンネルを選択的にマルチキャスト参加するなどして、参加するマルチキャスト数を制限するようにする。

図６には、ＩＰＴＶ配信システム１００において常設ストリーミング・セッションを利用してチャンネル・ストリームの配信サービスを行なうシーケンス例を示している。図示のシーケンスでは、クライアント側からのコンテンツのチャンネル・リクエストに応じてストリーミングが行なわれる。以下、図６を参照しながら、図５に示したＩＰＴＶ配信システム１００の仕組みについて説明する。

エッジ・サーバー２１６上にＩＰＴＶサービス・トランスレーション・サーバーがダウンロードされ起動された直後に、このトランスレーション・サーバーは、プレイヤーへのチャンネル・ストリーミングを行なうＩＰＴＶ専用チャンネルに必要なＣＰＵ、記憶領域、ネットワーク・インターフェースなどの配信リソースの確保をリソース・マネジメント・サーバー２１５に要求する（ＳＥＱ６０１）。

リソース・・マネジメント・サーバー２１５は、この要求に応答して、ストリーミング・セッションが確立してから解放するまで、上記の通信リソースを常に確保する（ＳＥＱ６０２）。配信リソースの確保には、ＮＧＮなどのキャリア専用網で利用されているＩＭＳ／ＳＩＰプロトコルや、ＯｐｅｎＦｌｏｗ−ＡＰＩ、あるいはキャリア・ネットワーク独自のプロコルなどを利用することができる（同上）。

そして、エッジ・サーバー２１６上のＩＰＴＶサービス・トランスレーション・サーバーとプレイヤー２３５間では、配信リソースが確保された、ＩＰＴＶ専用チャンネルとして、帯域の保証された１つのＨＴＴＰ擬似ストリーミング・チャンネル（セッション）を確立する（ＳＥＱ６０３、６０４）。このＩＰＴＶ専用チャンネルは、常設であり、プレイヤーからのＨＴＴＰリクエスト送信とエッジ・サーバー２１６上のトランスレーション・サーバーからのＨＴＴＰレスポンス返信が常時可能な帯域保証型のパスである。エッジ・サーバー２１６上のＩＰＴＶサービス・トランスレーション・サーバーは、常にこのチャンネル上ですべてのストリーミングをプレイヤー側に転送する。必要であれば、ＨＴＴＰ擬似ストリーミングのセッションのセキュリティーは、ＳＳＬなどで保護される。

次いで、エッジ・サーバー２１６上のＩＰＴＶサービス・トランスレーション・サーバーは、ストリーミング・サーバー２１３に対して、選択される可能性のあるすべてのマルチキャスト・チャンネルに対して参加（取得）要求を行なう（ＳＥＱ６０５）。これに対し、ストリーミング・サーバー２１３は、ＲＴＰなどを利用して、要求されたすべてのチャンネルについて、エッジ・サーバー２１６上のトランスレーション・サーバーへ、ストリーミングを通常速度転送により行なう（ＳＥＱ６０６）。

エンド・ユーザーは、ブラウザー２３４が実行するポータル・アプリケーションのチャンネル・ナビゲーション機能により、チャンネルの選択を行なう（ＳＥＱ６０７）。チャンネル・ナビゲーションの過程で、ブラウザー２３４上のポータル・アプリケーションは、ポータル・サーバー２１２とやり取りし、エンド・ユーザーは、選択するチャンネルに関する属性情報（タイトル、概要、価格など）を照会しながら、所望のチャンネルを選択することができる。

そして、エンド・ユーザーは、ブラウザー２３４上のポータル・アプリケーションに対して、選択したチャンネルの再生を指示する（ＳＥＱ６０８）。

すると、ブラウザー２３４上のポータル・アプリケーションは、エッジ・サーバー２１６上のトランスレーション・サーバーに対して、ＡＪＡＸなどのＨＴＴＰリクエストにより、選択されたチャンネルの再生指示を行なう（ＳＥＱ６０９）。ＩＧＭＰ Ｊｏｉｎなどによる対象のマルチキャスト・ストリームへの参加は事前に行なわれている。したがって、このタイミングでは、エッジ・サーバー２１６上のＩＰＴＶサービス・トランスレーション・サーバーは、単なるマルチキャスト・ストリーム入力ポートの切り替えにより、選択されたチャンネル・ストリーミングを直ちに開始することができる。そして、エッジ・サーバー２１６上のＩＰＴＶサービス・トランスレーション・サーバーは、ＨＴＴＰ擬似ストリーミングにより選択されたチャンネルのコンテンツ・ストリームを送出する（ＳＥＱ６１０）。そして、クライアント・デバイス２３１上では、プレイヤーが受信したコンテンツ・ストリームの再生を行なう（ＳＥＱ６１１）。

続いて、エンド・ユーザーがブラウザー上のポータル・アプリケーションのチャンネル・ナビゲーション機能により、チャンネルの選択を行なう（ＳＥＱ６１２）。チャンネル・ナビゲーションの過程で、ブラウザー２３４上のポータル・アプリケーションはポータル・サーバー２１２とやり取りし、エンド・ユーザーは選択するチャンネルに関する属性情報を照会しながら、所望のチャンネルを選択する（同上）。

そして、エンド・ユーザーは、ブラウザー２３４上のポータル・アプリケーションに対して、上記とは異なるチャンネルの再生を指示する（ＳＥＱ６１３）。ブラウザー上のポータル・アプリケーションは、エッジ・サーバー２１６上のトランスレーション・サーバーに対して、ＡＪＡＸなどのＨＴＴＰリクエストにより、選択されたチャンネルの再生指示を行なう（ＳＥＱ６１４）。ＩＧＭＰ Ｊｏｉｎなどによる対象のマルチキャスト・ストリームへの参加は事前に行なわれているので、このタイミングでは、単なるマルチキャスト・ストリーム入力ポートの切り替えにより、選択されたチャンネル・ストリーミングが直ちに開始される。そして、エッジ・サーバー２１６上のＩＰＴＶサービス・トランスレーション・サーバーは、ＨＴＴＰ擬似ストリーミングにより選択されたチャンネルのコンテンツ・ストリームを送出する（ＳＥＱ６１５）。クライアント・デバイス２３１上では、プレイヤー２３５が受信したコンテンツ・ストリームの再生を行なう（ＳＥＱ６１６）。

図６に示したシーケンス例では、エッジ・サーバー２１６上のＩＰＴＶサービス・トランスレーション・サーバーは、ストリーミング・サーバー２１３からマルチキャスト送信されているチャンネルのうち対応するチャンネル・ストリームをクライアント・デバイス２３１上のプレイヤー２３５にＨＴＴＰ擬似ストリーミングしている。これに対し、エッジ・サーバー２３１上に十分なメモリー若しくはハード・ディスクなどの蓄積記憶域（ストレージ）がある場合には、ストリーミング・サーバー２１３から送出されるチャンネル・ストリームをこの蓄積記憶域に蓄積することで、マルチキャスト・チャンネル再生時のトリックプレイ・モード（主には巻き戻し再生）のパフォーマンスを向上させることが可能である。

エッジ・サーバー２１６にＩＰサービス・トランスレーション・サーバーがダウンロードされ起動されると同時に、このトランスレーション・サーバーはアクセス（サービス提供）可能なすべてのＩＰ放送チャンネルに対して送付要求を行なう。具体的には、コア・ネットワーク２０１におけるＩＰ放送チャンネルのトランスポート・プロトコルにマルチキャストが利用される場合には、ＩＰＴＶサービス・トランスレーション・サーバーがエッジ・サーバー２１６にダウンロードされ起動された直後に、コア・ネットワーク２０１内のマルチキャスト・ルーター（図示しない）を介して、ストリーミング・サーバー２１３にてサービス提供可能なすべてのマルチキャスト・チャンネルに対して参加（取得）要求が行なわれる。ここで、エッジ・サーバー２１６に対して送信されるすべてのマルチキャスト・ストリームは、エッジ・サーバー２１６に受信されると同時に上記の記憶領域に蓄積される。その後、エンド・ユーザーがとあるチャンネルを選択すると、ＩＰＴＶサービス・トランスレーション・サーバーは、所望のチャンネルにスイッチする。そして、エンド・ユーザーが巻き戻し再生を指示する場合には、既にエッジ・サーバー２１６の蓄積記憶領域に蓄積されているストリームから再生を行なうことにより、ＩＰ放送チャンネルの巻き戻し再生のパフォーマンスを各段に向上させることが可能である。

但し、コア・ネットワーク２０１のリソース上の制限、若しくは、エッジ・サーバー２１６の蓄積記憶領域の制限で、該当するＩＰＴＶサービス・トランスレーション・サーバーがアクセス可能なすべてのマルチキャスト・チャンネル・ストリーミングの既に配信された分を蓄積できない場合には、ネットワーク・リソース並びにストレージ・リソースの負荷軽減策を講じることも可能である。例えば、エンド・ユーザーがとあるチャンネルを選択した際に、そのチャンネルの前後（チャンネル・リスト上の前後の場合もあれば、そのエンド・ユーザーの嗜好を考慮に入れたアクセス頻度の高いチャンネルのみを並べたチャンネル・リスト上の前後など）のチャンネルを選択的にマルチキャスト参加するなどして、それらのマルチキャスト・ストリームのみエッジ・サーバー２１６に蓄積しておくようにして、ネットワーク・リソース並びにストレージ・リソースの負荷を軽減する。

図７には、ＩＰＴＶ配信システム１００において常設ストリーミング・セッションを利用してチャンネル・ストリームの配信サービスを行なうシーケンス例を示している。図示のシーケンスでは、エッジ・サーバー２１６がストリームを蓄積するストレージを備え、チャンネル・ストリームの変速再生にも対応することができる。

エッジ・サーバー２１６上にＩＰＴＶサービス・トランスレーション・サーバーがダウンロードされ起動された直後に、このトランスレーション・サーバーは、プレイヤーへのチャンネル・ストリーミングを行なうＩＰＴＶ専用チャンネルに必要なＣＰＵ、記憶領域、ネットワーク・インターフェースなどの配信リソースの確保をリソース・マネジメント・サーバー２１５に要求する（ＳＥＱ７０１）。

リソース・・マネジメント・サーバー２１５は、この要求に応答して、ストリーミング・セッションが確立してから解放するまで、上記の通信リソースを常に確保する（ＳＥＱ７０２）。配信リソースの確保には、ＮＧＮなどのキャリア専用網で利用されているＩＭＳ／ＳＩＰプロトコルや、ＯｐｅｎＦｌｏｗ−ＡＰＩ、あるいはキャリア・ネットワーク独自のプロコルなどを利用することができる（同上）。

そして、エッジ・サーバー２１６上のＩＰＴＶサービス・トランスレーション・サーバーとプレイヤー２３５間では、配信リソースが確保された、ＩＰＴＶ専用チャンネルとして、帯域の保証された１つのＨＴＴＰ擬似ストリーミング・チャンネル（セッション）を確立する（ＳＥＱ７０３、７０４）。このＩＰＴＶ専用チャンネルは、常設であり、プレイヤー２３５からのＨＴＴＰリクエスト送信とエッジ・サーバー２１６上のトランスレーション・サーバーからのＨＴＴＰレスポンス返信が常時可能な帯域保証型のパスである。エッジ・サーバー２１６上のＩＰＴＶサービス・トランスレーション・サーバーは、常にこのチャンネル上ですべてのストリーミングをプレイヤー２３５側に転送する。必要であれば、ＨＴＴＰ擬似ストリーミングのセッションのセキュリティーは、ＳＳＬなどで保護される。

次いで、エッジ・サーバー２１６上のＩＰＴＶサービス・トランスレーション・サーバーは、ストリーミング・サーバー２１３に対して、選択される可能性のあるすべてのマルチキャスト・チャンネルに対して参加（取得）要求を行なう（ＳＥＱ７０５）。これに対し、ストリーミング・サーバー２１３は、ＲＴＰなどを利用して、要求されたすべてのチャンネルについて、エッジ・サーバー２１６上のトランスレーション・サーバーへ、ストリーミングを通常速度転送により行なう（ＳＥＱ７０６）。

エンド・ユーザーは、ブラウザー２３４が実行するポータル・アプリケーションのチャンネル・ナビゲーション機能により、チャンネルの選択を行なう（ＳＥＱ７０７）。チャンネル・ナビゲーションの過程で、ブラウザー２３４上のポータル・アプリケーションは、ポータル・サーバー２１２とやり取りし、エンド・ユーザーは、選択するチャンネルに関する属性情報（タイトル、概要、価格など）を照会しながら、所望のチャンネルを選択することができる。

そして、エンド・ユーザーは、ブラウザー２３４上のポータル・アプリケーションに対して、選択したチャンネルの再生を指示する（ＳＥＱ７０８）。

すると、ブラウザー上のポータル・アプリケーションは、エッジ・サーバー２１６上のトランスレーション・サーバーに対して、ＡＪＡＸなどのＨＴＴＰリクエストにより、選択されたチャンネルの再生指示を行なう（ＳＥＱ７０９）。ＩＧＭＰ Ｊｏｉｎなどによる対象のマルチキャスト・ストリームへの参加は事前に行なわれている。したがって、このタイミングでは、エッジ・サーバー２１６上のＩＰＴＶサービス・トランスレーション・サーバーは、単なるマルチキャスト・ストリーム入力ポートの切り替えにより、選択されたチャンネル・ストリーミングを直ちに開始することができる。そして、エッジ・サーバー２１６上のＩＰＴＶサービス・トランスレーション・サーバーは、選択されたチャンネルのコンテンツ・ストリームをエッジ・サーバー２１６内のストレージに蓄積しながら（ＳＥＱ７１０）、ＨＴＴＰ擬似ストリーミングにより送出する（ＳＥＱ７１１）。そして、クライアント・デバイス２３１上では、プレイヤー２３５が受信したコンテンツ・ストリームの再生を行なう（ＳＥＱ７１２）。

続いて、エンド・ユーザーがブラウザー上のポータル・アプリケーションのチャンネル・ナビゲーション機能により、再生中のコンテンツ・ストリームの変速再生の指示を行なう（ＳＥＱ７１３）。すると、ブラウザー２３４上のポータル・アプリケーションは、エッジ・サーバー２１６上のトランスレーション・サーバーに対して、ＡＪＡＸなどのＨＴＴＰリクエストにより、コンテンツの変速再生指示を行なう（ＳＥＱ７１４）。

エッジ・サーバー２１６上のトランスレーション・サーバーは、クライアント・デバイス２３１上でポータル・アプリケーションとして実行されるブラウザー・スクリプトから変速再生を指示する再生制御コマンドを受信すると、その対象チャンネルの過去放送分が既に自身のストレージに蓄積済みであるかどうかを確認にする（ＳＥＱ７１５）。

このとき、その対象チャンネルの過去放送分が既に自身のストレージに蓄積済みであれば、変速再生可能と判断する。トランスレーション・サーバーは、自身のストレージに蓄積済みのものから該当するチャンネル・ストリームを取り出すと（ＳＥＱ７１６）、クライアント・デバイス２３１上のプレイヤーが通常再生と同様な処理で済む（変速再生できる）ように、ストリームを処理する（ＳＥＱ７１７）。

そして、トランスレーション・サーバーは、上記の処理した後のチャンネル・ストリームをＨＴＴＰ擬似ストリーミングにより送出する（ＳＥＱ７１８）。クライアント・デバイス２３１上では、プレイヤーが受信したコンテンツ・ストリームの通常再生を行なうことにより、エンド・ユーザーには変速再生したストリームを提示することかできる（ＳＥＱ７１９）。

以上説明してきたように、本実施形態に係るＩＰＴＶ配信システム１００では、異なる複数のサービス・プロバイダーから提供されるＩＰＴＶサービス・クライアントの機能を、ナビゲーション（コンテンツ若しくはチャンネルを選択させる機能）と、再生制御（通常再生（プレイ）、停止（ストップ）、巻き戻し再生（リワインド）、早送り再生（フォワード）、ポーズといったトリックプレイなどのコマンドを送る機能）と、ストリーミング（ＡＶストリームを転送・再生する機能）に分離し、前者２つをブラウザー・アプリケーションとして実現し、後者１つをＩＰＴＶサービス・プロトコルと透過な（ＩＰＴＶサービス・プロトコルの相違に依存しない共通の）プレイヤーとして実装するようにしている。

したがって、デバイス・ベンダーは、サービス毎のブラウザー・アプリケーションを開発するだけでよく、複数の異なるサービス向けにクライアントを個別に実装したりメンテナンスしたりするコストを低減することができる。また、サービス・プロバイダーにとっては、エンド・ユーザーがブラウザーを介して選択したコンテンツを、ブラウザー上で指示した再生制御コマンドに従って、品質が保証されたネットワークを通してＲＴＰプロトコルにてストリーミングするので、サービス品質の均質化を図ることができる。また、ＨＴＴＰストリーミグ・クライアントを利用するにもかかわらず、ＩＰ放送配信におけるチャンネル・チェンジの際のパフォーマンスを各段に向上させることができる。

なお、本明細書の開示の技術は、以下のような構成をとることも可能である。
（１）コンテンツのストリームを再生するコンテンツ再生装置との間でチャンネルをネットワーク上で確立するチャンネル確立部と、前記コンテンツ再生装置からコンテンツのストリームの再生を制御する再生制御コマンドを前記ネットワーク経由で受信する再生制御コマンド受信部と、受信した前記再生制御コマンドに従って、前記チャンネルを用いてコンテンツのストリームを前記コンテンツ再生装置に送出するストリーミング部と、を具備するコンテンツ転送装置。
（２）前記チャンネル確立部は、前記コンテンツ再生装置上でコンテンツのストリームを再生するプレイヤーからの要求に応じて前記チャンネルを確立する、上記（１）に記載のコンテンツ転送装置。
（３）前記チャンネル確立部は、前記コンテンツ再生装置との間で常時ＨＴＴＰリクエストの送信及びＨＴＴＰレスポンスの返信が可能な帯域保証型のパスからなるチャンネルを、前記ネットワーク上で確立する、上記（１）に記載のコンテンツ転送装置。
（４）前記再生制御コマンド受信部は、前記コンテンツ再生装置のブラウザー実行環境で動作するブラウザー・アプリケーションがユーザーの指示に応じて発行した再生制御コマンドを、ＨＴＴＰリクエストとして受信する、上記（１）に記載のコンテンツ転送装置。
（５）前記ストリーミング部は、前記コンテンツ再生装置上で動作するサービス・プロトコル透過なプレイヤーに対してコンテンツのストリームを送出する、上記（１）に記載のコンテンツ転送装置。
（６）前記ストリーミング部は、前記コンテンツ再生装置のブラウザー実行環境で動作するブラウザー・アプリケーションがユーザーの選択に応じてＨＴＴＰリクエストにより要求するコンテンツのストリームをストリーミング・サーバーから取得して、前記コンテンツ再生装置に送出する、上記（１）に記載のコンテンツ転送装置。
（７）前記ストリーミング部は、前記コンテンツ再生装置からの要求に応じてストリーミング・サーバーから送出されるストリーム・フォーマットを、前記コンテンツ再生装置側でストリーミング再生するプレイヤーが処理できるフォーマットに変換して、前記コンテンツ再生装置に送出する、上記（１）に記載のコンテンツ転送装置。
（８）前記再生制御コマンド受信部は、受信した前記再生制御コマンドを、前記コンテンツ再生装置からのストリーミング要求に応じてコンテンツを送出するストリーミング・サーバーが解釈できる再生制御プロトコルに変換して、前記ストリーミング・サーバーとやり取りする、上記（１）に記載のコンテンツ転送装置。
（９）前記再生制御コマンド受信部は、ＲＴＳＰを解釈できるストリーミング・サーバーに対して、ストリームの変速再生に関する再生制御コマンドをＲＴＳＰの変速転送指示に変換してやり取りする、上記（８）に記載のコンテンツ転送装置。
（１０）前記再生制御コマンド受信部は、ＨＴＴＰしか解釈できないＨＴＴＰ擬似ストリーミング・サーバーに対して、ストリームの再生速度に関する再生制御コマンドをＨＴＴＰストリーミングにおけるコンテンツ・リクエストに変換し、前記再生制御コマンドが指示する速度に応じた速さで前記ＨＴＴＰ擬似ストリーミング・サーバーに対するＨＴＴＰリクエストを発行する、上記（８）に記載のコンテンツ転送装置。
（１１）ストリーミング・サーバーから受信したコンテンツのストリームを蓄積するストレージをさらに備え、前記ストリーミング部は、前記再生制御コマンド受信部でストリームの変速再生に関する再生制御コマンドを受信したときに、前記コンテンツ再生装置上で動作するプレイヤーが通常再生と同様な処理で変速再生できるようにストリームを処理してから送出する、上記（１）に記載のコンテンツ転送装置。
（１２）前記チャンネル確立部、前記再生制御コマンド受信部、及び、前記ストリーミング部は、所定のポータル・サーバーからダウンロードし起動するトランスレーション・サーバーの機能として実現される、上記（１）に記載のコンテンツ転送装置。
（１３）コンテンツのストリームを送出するストリーミング・サーバーとコンテンツ再生装置との間に介在するエッジ・サーバーとして動作する、上記（１）に記載のコンテンツ転送装置。
（１４）コンテンツのストリームを要求するコンテンツ再生装置との間でチャンネルをネットワーク上で確立するチャンネル確立ステップと、前記コンテンツ再生装置からコンテンツのストリームの再生を制御する再生制御コマンドを前記ネットワーク経由で受信する再生制御コマンド受信ステップと、受信した前記再生制御コマンドに従って、前記チャンネルを用いてコンテンツのストリームを前記コンテンツ再生装置に送出するストリーミング・ステップと、を有するコンテンツ転送方法。
（１５）ユーザーの指示に応じて選択したコンテンツのストリーミングをＨＴＴＰリクエストにより要求するナビゲーション部と、ユーザーの指示に応じてコンテンツのストリーミングの再生制御をＨＴＴＰリクエストにより行なう再生制御部と、所定のサーバーとの間で確立されたチャンネルを介して受信するコンテンツのストリームを再生するプレイヤーと、を具備するコンテンツ再生装置。
（１６）ブラウザー実行環境を備え、前記ナビゲーション部及び前記再生制御部は、前記ブラウザー実行環境下で実行するブラウザー・アプリケーションとして実現され、前記プレイヤーは、サービス・プロトコル透過である、上記（１５）に記載のコンテンツ再生装置。
（１７）前記プレイヤーは、前記ブラウザー・アプリケーションからの要求に応じて、前記サーバーに対して前記チャンネルの確立を要求する、上記（１５）に記載のコンテンツ再生装置。
（１８）前記チャンネルは、コンテンツのストリームを転送するエッジ・サーバーとの間で常時ＨＴＴＰリクエストの送信及びＨＴＴＰレスポンスの返信が可能な帯域保証型のパスからなる、上記（１５）に記載のコンテンツ再生装置。
（１９）ユーザーの指示に応じて選択したコンテンツのストリーミングをＨＴＴＰリクエストにより要求するナビゲーション・ステップと、ユーザーの指示に応じてコンテンツのストリーミングの再生制御をＨＴＴＰリクエストにより行なう再生制御ステップと、所定のサーバーとの間で確立されたチャンネルを介して受信するコンテンツのストリームを再生する再生ステップと、を有するコンテンツ再生方法。
（２０）コンテンツの選択とコンテンツの再生制御の指示をＨＴＴＰリクエストで行なうとともに、サービス・プロトコル透過なプレイヤーでコンテンツのストリーム再生を行なうコンテンツ再生装置と、前記コンテンツ再生装置が選択したコンテンツのストリームを送出するストリーミング・サーバーと、前記コンテンツ再生装置が発行する再生制御コマンドを前記ストリーミング・サーバーが解釈できるプロトコルに変換して前記ストリーミング・サーバーとやり取りするとともに、ストリーミング・サーバーから送出されたコンテンツのストリームを前記プレイヤーが処理できるフォーマットに変換し、前記コンテンツ再生装置との間で確立したチャンネルを用いてコンテンツのストリームを転送するエッジ・サーバーと、を具備するコンテンツ配信システム。
（２１）前記チャンネルのための配信リソースを確保するリソース・マネジメント・サーバーをさらに備える、上記（２０）に記載のコンテンツ配信システム。
（２２）コンテンツのストリームを再生するコンテンツ再生装置との間でチャンネルをネットワーク上で確立するチャンネル確立部、前記コンテンツ再生装置からコンテンツのストリームの再生を制御する再生制御コマンドを前記ネットワーク経由で受信する再生制御コマンド受信部、受信した前記再生制御コマンドに従って、前記チャンネルを用いてコンテンツのストリームを前記コンテンツ再生装置に送出するストリーミング部、としてコンピューターを機能させるようコンピューター可読形式で記述されたコンピューター・プログラム。
（２３）ユーザーの指示に応じて選択したコンテンツのストリーミングをＨＴＴＰリクエストにより要求するナビゲーション部、ユーザーの指示に応じてコンテンツのストリーミングの再生制御をＨＴＴＰリクエストにより行なう再生制御部、所定のサーバーとの間で確立されたチャンネルを介して受信するコンテンツのストリームを再生するプレイヤー、としてコンピューターを機能させるようコンピューター可読形式で記述されたコンピューター・プログラム。

以上、特定の実施形態を参照しながら、本明細書で開示する技術について詳細に説明してきた。しかしながら、本明細書で開示する技術の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。

本明細書では、ＩＰＴＶ配信サービスに適用した実施形態について説明してきたが、本明細書で開示する技術は、その他のさまざまなタイプのコンテンツ・ストリーム配信システムに同様に適用することができる。

また、本明細書では、エッジ・サーバー上のトランスレーション・サーバーからクライアント・デバイスへストリームを転送するための専用チャネルのための配信リソースを確保するために、ＩＭＳ／ＳＩＰプロトコルやＯｐｅｎＦｌｏｗ−ＡＰＩを利用できることを言及したが、本明細書で開示する技術の要旨は配信リソースを確保する特定の方法に限定される訳ではない。

要するに、例示という形態により本明細書で開示する技術について説明してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本明細書で開示する技術の要旨を判断するためには、特許請求の範囲を参酌すべきである。

１００…ＩＰＴＶ配信システム
１１０…サービスＡサーバー
１３０…クライアント・デバイス
１３１…サービスＡ向けブラウザー・アプリケーション
１３２…サービスＢ向けブラウザー・アプリケーション
１３３…ブラウザー実行環境
１３４…プレイヤー
１４０…エッジ・サーバー
１５０…エッジ・サーバー
２０１…コア・ネットワーク
２０２…アクセス・ネットワーク
２０３…ホーム・ネットワーク
２１１…サービス・ディスカバリー・サーバー
２１２…ポータル・サーバー
２１３…ストリーミング・サーバー
２１５…リソース・マネジメント・サーバー
２１６…エッジ・サーバー
２３１…クライアント・デバイス
２３２…モデム／ルーター
２３３…ＩＰＴＶクライアント・マネージャー
２３４…ブラウザー
２３５…プレイヤー
８０１…専用チャンネル確立部
８０２…再生制御コマンド受信部
８０３…ストリーミング部

Claims (31)

1. アプリケーションの実行によってコンテンツの選択と再生制御を命令するブラウザーと、
   ブラウザーが実行するアプリケーションが発行した再生制御コマンド送信要求を受信する受信部と、
   （１）コンテンツ・ストリーミング・サーバーが再生制御コマンドを解釈できるように、アプリケーションからの再生制御コマンドの送信要求に対してプロトコル変換を実行し、（２）変換した再生制御コマンドをコンテンツ・ストリーミング・サーバーに供給し、（３）変換された再生制御コマンドをコンテンツ・ストリーミング・サーバーが受信したことに応答して、第１のフォーマットの選択されたコンテンツ・ストリームをコンテンツ・ストリーミング・サーバーから受信し、（４）受信した選択されたコンテンツ・ストリームを第１のフォーマットから第２のフォーマットに変換して、変換されたビデオ・ストリームを取得する、制御部と、
   プライベート・チャネルの確立を要求するように構成され、第２のフォーマットのビデオ・ストリームを再生するプレイヤーと、
   を具備するテレビ受信機。
2. 再生制御コマンドの送信要求は、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）リクエストである、
   請求項１に記載のテレビ受信機。
3. 第２のフォーマットは、ＨＴＴＰプロトコルと互換性があるプロトコルである、
   請求項１又は２のいずれかに記載のテレビ受信機。
4. アプリケーションからの再生制御コマンドは、ＨＴＴＰリクエストによって行なわれる、
   請求項１乃至３のいずれかに記載のテレビ受信機。
5. ブラウザーと、
   ブラウザーから実行してコンテンツの選択と再生制御を行なうことができる、異なるＩＰＴＶ毎の、複数のブラウザー・アプリケーションと、
   少なくとも１つのＩＰＴＶサービスから少なくとも１つのエッジ・サーバーを経由して受信したコンテンツ・ストリームを再生するように構成され、プライベート・チャネルの確立を要求するように構成されたプレイヤーと、
   ブラウザー上でのコンテンツの選択に応答してプレイヤーにストリーム配信されるコンテンツの再生をブラウザーからの再生制御指示に従って制御するように構成された再生制御部と、
   を具備するテレビ受信機。
6. 再生制御部は、ブラウザーからのＨＴＴＰリクエストとして送信される再生制御コマンドに従って、プレイヤーへのストリーミング動作を制御する、
   請求項５に記載のテレビ受信機。
7. ブラウザー・アプリケーションは、ＩＰＴＶシリーズの少なくとも１つのサーバーからダウンロード可能である、
   請求項５又は６のいずれかに記載のテレビ受信機。
8. プレイヤーは、ストリーミング・サーバーとエッジ・サーバーの間の個別のストリーミング・セッションを供給するプロバイダーのサービスの１つによって提供されるストリーミング・フォーマットを処理するように構成される、
   請求項５乃至７のいずれかに記載のテレビ受信機。
9. ストリーミング・セッションは、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｌ Ｐｒｏｔｏｃｏｌ）、ＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）、ＲＴＰ（Ｒｅａｌ ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）のうち少なくとも１つからなる、
   請求項８に記載のテレビ受信機。
10. プレイヤーは、第２のサービスからダウンロードされる第２のサービス用の個別のストリーミング・プロトコル・トランスレーション・サーバー・アプリケーションを起動する第２のエッジ・サーバーを持つ第２のサービスによって提供される第２のストリーミング・フォーマットを処理するように構成される、
    請求項５乃至８のいずれかに記載のテレビ受信機。
11. プレイヤーは第２のサービスからのコンテンツを再生するように構成され、第２のエッジ・サーバーは第２のサービス用の個別のＩＰＴＶサービスのトランスレーション・サーバーであり、トランスレーション・サーバーは第２のサービスから送出された個別のストリーミング・フォーマットをプレイヤーが処理することができるストリーミング・フォーマットに変換してプレイヤーに送出する、
    請求項１０に記載のテレビ受信機。
12. ブラウザーはチャンネル選択用のポータル・アプリケーションを有し、ポータル・アプリケーションは、少なくとも１つのサービスのＩＰＴＶサービスのトランスレーション・サーバーに関連するチャンネルの選択又は変更を要求する、
    請求項５乃至１１のいずれかに記載のテレビ受信機。
13. ブラウザーは、チャンネル選択用のポータル・アプリケーションを含み、
    ポータル・アプリケーションは、少なくとも１つのサービスのＩＰＴＶサービスのトランスレーション・サーバーに関連するチャンネルの選択又は変更を要求し、
    ユーザーがストリーミング・サーバーから既にマルチキャストされているチャンネルを選択したときに、ＩＰＴＶサービスのトランスレーション・サーバーは、マルチキャスト・ストリーミングに対応するＨＴＴＰストリーミングを即座にプレイヤーに送信する、
    請求項５乃至１１のいずれかに記載のテレビ受信機。
14. ブラウザーは、選択されたチャンネルの再生指示を、ＨＴＴＰリクエストを使って実行し、
    プレイヤーは、マルチキャスト・ストリームの入力ポートを変更するだけで、選択されたチャンネルのストリーミングを即座に受信する、
    請求項５乃至１１のいずれかに記載のテレビ受信機。
15. プレイヤーは、ＩＰＴＶサービスのトランスレーション・サーバー上で選択されたチャンネルにおいてＩＰＴＶサービスのトランスレーション・サーバーがＨＴＴＰストリーミングを用いて送出するコンテンツ・ストリームを受信して再生を実行する、
    請求項１４に記載のテレビ受信機。
16. ブラウザーと、
    ブラウザーから実行してコンテンツの選択と再生制御を行なうことができる、異なるＩＰＴＶサービス毎の、複数のブラウザー・アプリケーションと、
    少なくとも１つのＩＰＴＶサービスからのコンテンツ・ストリーミングを、少なくとも１つのエッジ・サーバーを経由して受信して、再生するように構成されたプレイヤーと、
    を具備し、ホーム・ネットワークに接続するように構成されたテレビ受信機。
17. ＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）に則ってホーム・ネットワークに接続されるように構成された、請求項１６に記載のテレビ受信機。
18. ブラウザーはポータル・アプリケーションを実行するように構成され、プレイヤーはポータル・アプリケーションの機能に応答してＡＶストリームの転送及び再生を実行するように構成される、
    請求項１６又は１７のいずれかに記載のテレビ受信機。
19. ブラウザーはＨＴＭＬブラウザーである、
    請求項１６乃至１８のいずれかに記載のテレビ受信機。
20. ブラウザーは、ＪａｖａＳｃｒｉｐｔアプリケーションの実行環境を含む、
    請求項１９に記載のテレビ受信機。
21. ポータル・サイトからポータル・アプリケーションとして提供されたブラウザー・アプリケーションを実行して、ナビゲーション及びコンテンツの再生制御を実行するブラウザーと、
    ナビゲーション及び再生制御から実行可能な、異なるＩＰＴＶサービス毎の複数のアプリケーションと、
    少なくとも１つのサービスのＩＰＴＶサービスから少なくとも１つのエッジ・サーバーを経由して受信したコンテンツ・ストリーミングを再生するように構成され、プライベート・チャネルの確立を要求するように構成されたプレイヤーと、
    ブラウザーのナビゲーション及び再生制御を経由して、プレイヤーに配信されるストリームからなるコンテンツを制御するように構成された再生制御部と、
    を具備する表示装置。
22. 再生制御部は、ナビゲーション及び再生制御からＨＴＴＰリクエストとして伝送される再生制御コマンドに従って、プレイヤーへのストリーミング動作を制御する、
    請求項２１に記載の表示装置。
23. アプリケーションは、少なくとも１つのＩＰＴＶサービスのサーバーからダウンロード可能である、
    請求項２１又は２２のいずれかに記載の表示装置。
24. プレイヤーは、ストリーミング・サーバーとエッジ・サーバーの間の個別のストリーミング・セッションを提供するプロバイダーのサービスの１つによって提供されるストリーミング・フォーマットを処理するように構成される、
    請求項２１乃至２３のいずれかに記載の表示装置。
25. ストリーミング・セッションは、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｌ Ｐｒｏｔｏｃｏｌ）、ＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）、ＲＴＰ（Ｒｅａｌ ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）のうち少なくとも１つからなる、
    請求項２４に記載の表示装置。
26. プレイヤーは、第２のサービスからダウンロードされる第２のサービス用の個別のストリーミング・プロトコル・トランスレーション・サーバー・アプリケーションを起動する第２のエッジ・サーバーを持つ第２のサービスによって提供される第２のストリーミング・フォーマットを処理するように構成される、
    請求項２４に記載の表示装置。
27. プレイヤーは第２のサービスからのコンテンツを再生するように構成され、第２のエッジ・サーバーは第２のサービス用の個別のＩＰＴＶサービスのトランスレーション・サーバーであり、トランスレーション・サーバーは第２のサービスから送出された個別のストリーミング・フォーマットをプレイヤーが処理することができるストリーミング・フォーマットに変換してプレイヤーに送出する、
    請求項２６に記載の表示装置。
28. コンテンツを選択してビデオ・ストリームのＨＴＴＰリクエストとして再生制御コマンドを実行して、クライアント装置を検出して対話する受信部に再生制御コマンドを送信するブラウザーであって、ブラウザーの再生制御コマンドは、ネットワーク経由で実行されて、制御部に変換されたビデオ・ストリームのネットワーク経由の伝送の制御を行なわせ、選択されたコンテンツ・ストリームが再生制御コマンドに従って速度調整して転送され、選択されたコンテンツ・ストリームがサーバーから送出された第１のフォーマットを有し、選択されたコンテンツ・ストリームが第１のフォーマットから第２のフォーマットに変換されて、変換されたビデオ・ストリームの伝送が実施される、ブラウザーと、
    選択されたコンテンツ・ストリームがサーバーから送出されるときと変動しない速度で転送されるコンテンツのフォーマットからなり、制御部による変換から取得される変換後のビデオ・ストリームの再生を実行するときと同じ再生処理を実行することによって、第２のフォーマットを持つ変換後のビデオ・ストリームを再生し、プライベート・チャネルの確立を要求するように構成されたプレイヤーと、
    を具備し、
    第１のフォーマットに対応する第１のプロトコルは、第２のフォーマットに対応する第２のプロトコルとは相違し、且つ、第１のプロトコルはＨｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌとは相違し、
    Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌから制御部に送信される再生制御コマンドは、再生制御コマンドのプロトコルをＨｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌから第１のプロトコルに変換して、第１のフォーマットを持つ再生制御コマンドがサーバーに送信される、
    装置。
29. コンテンツを選択し、ビデオ・ストリームを要求するＨＴＴＰリクエストとして再生制御コマンドを実行するブラウザーと、
    ブラウザーから再生制御コマンドを受信して、装置を検知して対話する受信部に再生制御コマンドを送信する再生制御コマンド受信部であって、再生制御コマンドはネットワーク経由で実行されて制御部に変換後のビデオ・ストリームのネットワーク経由での転送を制御させる、再生制御コマンド受信部と、
    変換後のビデオ・ストリームを再生し、プライベート・チャネルの確立を要求するように構成されたプレイヤーと、
    チャネル上でのすべてのビデオ・ストリームをプレイヤーに転送するストリーミング部と、
    を具備する装置。
30. 選択されたコンテンツ・ストリームがサーバーから送出された第１のフォーマットを有し、選択されたコンテンツ・ストリームが第１のフォーマットから第２のフォーマットに変換されて変換後のビデオ・ストリームの送信が行われる際に、選択されたコンテンツ・ストリームが再生制御コマンドに従って速度可変転送されるとき、第１のフォーマットに対応する第１のプロトコルは、第２のフォーマットに対応する第２のプロトコルとは相違し、且つ、第１のプロトコルはＨｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌとは相違する、
    請求項２９に記載の装置。
31. Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌから制御部に送信される再生制御コマンドは、再生制御コマンドのプロトコルをＨｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌから第１のプロトコルに変換して、第１のフォーマットを持つ再生制御コマンドがサーバーに送信される、
    請求項３０に記載の装置。