(57)【要約】ストリーミング技術等によるインターネット等を媒体としてライブ及びコンテンツを配信するストリーム・サーバに関し、不特定多数ユーザ端末に対して、それぞれ与えられた環境、すなわち、ネットワーク負荷、ユーザ端末の処理能力、又はストリーム・サーバの混雑度等にリアルタイムに対応したコンテンツ配信又はライブ配信を行う。
2004040908.tif 000002
【特許請求の範囲】
【請求項１】
１つ以上のトランスコーダと、
データを格納するキャッシュ型データベースと、
コンテンツ又はライブ、符号化方式、及び符号化レートに関して要求されたデータが該キャッシュ型データベースに格納されていないとき、該キャッシュ型データベースに該要求されたデータが格納されるように該トランスコーダ及び該キャッシュ型データベースを連携して制御するヒット／ミス判定部と、
を備えたことを特徴とするストリーム・サーバ。
【請求項２】
請求の範囲１において、
該トランスコーダがエンコーダ又はＣＯＤＥＣであることを特徴したストリーム・サーバ。
【請求項３】
請求の範囲１において、
該キャッシュ型データベースが、同一のコンテンツ又はライブ及び符号化方式に対して異なる符号化レートの該データをそれぞれ格納する複数のラインを有することを特徴としたストリーム・サーバ。
【請求項４】
請求の範囲１において、
ユーザ端末との間で、呼制御、又は該データの配信の開始制御、一時停止制御、若しくは巻戻し制御に関するネゴシエーションを行い、その結果を該ヒット／ミス判定部に通知する呼制御／ネゴシエーション処理部をさらに有し、
該ヒット／ミス判定部が、該結果に基づき該トランスコーダ及び該キャッシュ型データベースに対する連携制御を行うことを特徴とするストリーム・サーバ。
【請求項５】
請求の範囲１において、
さらに、ユーザ端末との間のネットワーク負荷、コンテンツサーバの混雑度、又はユーザ端末の処理能力の少なくともいずれか１つを監視し、監視結果を該ヒット／ミス判定部に与えるネットワーク監視部を有し、
該ヒット／ミス判定部が該監視結果に基づき最適符号化レートを決定することを特徴としたストリーム・サーバ。
【請求項６】
請求の範囲１において、
所定のプロトコルを実装し、該所定プロトコルに基づきユーザ端末との間の通信処理を行うプロトコル実装処理部をさらに有することを特徴としたストリーム・サーバ。
【請求項７】
請求の範囲６において、
該プロトコル実装処理部が、少なくともＩＰヘッダ処理部、ＵＤＰヘッダ処理部、ＲＴＰヘッダ処理部、ＲＴＣＰヘッダ処理部、及びＲＴＳＰヘッダ処理部の中のいずれか１つを備えていることを特徴とするストリーム・サーバ。
【請求項８】
請求の範囲６において、
該プロトコル実装処理部が、ＭＰＥＧシーケンスヘッダ処理部を備えていることを特徴としたストリーム・サーバ。
【請求項９】
請求の範囲１において、
該トランスコーダが、入力した少なくとも素材データ、トランスコードデータ、及びライブデータの内のいずれか１つを該要求された符号化方式の指定された符号化レートのデータに変換することを特徴とするストリーム・サーバ。
【請求項１０】
請求の範囲１において、
該ヒット／ミス判定部が、要求されたコンテンツ又はライブの検索、その符号化方式の検索、符号化レートの検索、及びデータが有効であるか否かの検索の順序を所定の順序で行い要求データのヒット／ミス判定を行うことを特徴としたストリーム・サーバ。
【請求項１１】
請求の範囲１において、
該ヒット／ミス判定部が、該要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータが該キャッシュ型データベースに格納されているか否かの判定に、該符号化レートが許容範囲に入っている否かを判定することを特徴としたストリーム・サーバ。
【請求項１２】
請求の範囲１において、
該ヒット／ミス判定部が、該要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータが該キャッシュ型データベースに格納されていないとき、該要求されたコンテンツ又はライブ、要求された符号化方式であり、該要求された符号化レートに近い符号化レートのデータを破棄し、該データが格納されていた位置に、該要求されたデータを格納するように該トランスコーダ及び該キャッシュ型データベースを連携して制御することを特徴としたストリーム・サーバ。
【請求項１３】
請求の範囲１において、
該ヒット／ミス判定部が、低視聴率のコンテンツデータ又はライブデータ、又は低視聴率の符号化レートのデータを破棄することを特徴とするストリーム・サーバ。
【請求項１４】
請求の範囲５において、
該キャッシュ型データベースは、該ネットワーク監視部から与えられた、該要求されたデータについて、その視聴開始時刻情報、停止時刻情報、及び変更時刻情報を格納し、
該ヒット／ミス判定部が、該情報に基づきヒット／ミス判定を行うことを特徴としたストリーム・サーバ。
【請求項１５】
請求の範囲１において、
該ヒット／ミス判定部が、低視聴率のコンテンツデータ又はライブデータ、低視聴率の符号化方式、又は低視聴率の符号化レートのデータの内の少なくとも１つを破棄して、該破棄されたデータが格納されていた場所に、要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータを格納するように該トランスコーダ及びキャッシュ型データベースに指示することを特徴とするストリーム・サーバ。
【請求項１６】
請求の範囲１において、
該ヒット／ミス判定部は、未使用トランスコーダがあるとき、このトランスコーダ及び該キャッシュ型データベースを制御して、新規コンテンツ又は新規ライブを所定符号化レートの所定符号化方式のデータに変換し、該キャッシュ型データベースに格納することを特徴としたストリーム・サーバ。
【請求項１７】
請求の範囲１において、
該トランスコーダが、空間スケーラビリティ、時間スケーラビリティ、又はＳＮＲスケーラビリティによる階層符号化において、符号化レート変更対象階層及びその１つ上位の階層の符号化データのみ新規に作成し、該新規上位階層より伸長された復号データと現上位階層より伸長された復号データの差分絶対値の和が所定の閾値以下であるとき該新規作成された変更対象階層及び上位階層を現階層とすることを特徴とするストリーム・サーバ。
【発明の詳細な説明】
【技術分野】  本発明はストリーム・サーバに関し、特にストリーミング技術等によるインターネット等を媒体としてライブ及びコンテンツを配信するストリーム・サーバに関するものである。
近年、ＡＤＳＬ及び無線ＬＡＮ等の普及によるインターネット等のネットワークのブロードバンド化が進んでいる。これに伴い、データ、音声、映像等を送受信するマルチメディア・多チャネルの通信環境が急速に整備されている。さらに、常時接続が一般化され、情報家電とネットワークの融合化が促進され、映像・音楽等のコンテンツ配信及びライブ配信等の需要が拡大している。
このようなネットワークにおいては、マルチメディアを多重化して１つのディジタル情報の流れとして扱うストリーミング技術によるライブ及びコンテンツを配信は重要である。
【背景技術】  図１０は、従来のライブ配信及びコンテンツ配信例を示している。ユーザ端末（ＰＤＡ）１７０＿２がライブ７２０を配信要求したときに、キャッシュサーバ１５０＿２がライブ７２０を保持していない場合、映像入力装置１２０で撮影されたライブ７２０は、リアルタイムエンコーダ１３０に与えられる。
エンコーダ１３０は、ライブ７２０を、要求された符号化方式・符号化レートのデータに変換して、ＩＰネットワーク１４０及びキャッシュサーバ１５０＿２を経由したライブ配信７２０ａで、ユーザ端末１７０＿２に送信する。このとき、キャッシュサーバ１５０＿２は、ライブ７２０を一時的に記憶する。
ユーザ端末（携帯電話）１７０＿３が、同じ符号化方式・符号化レートのライブ７２０を配信要求したとき、キャッシュサーバ１５０＿２は、記憶したライブ７２０を、ライブ配信７２０ｂでユーザ端末１７０＿３に送信する。
コンテンツ７１０は、コンテンツサーバ１１０のソースデータベース７００に格納されている。ユーザ端末（デスクトップＰＣ）１７０＿１がコンテンツ７１０を配信要求したときに、キャッシュサーバ１５０＿１がコンテンツ７１０を記憶していない場合、コンテンツ７１０は、コンテンツサーバ１１０からＩＰネットワーク１４０及びターミナルアダプタ（ＴＡ）１６０を経由して、ユーザ端末１７０＿１にコンテンツ配信７１０ａが行われる。
このとき、キャッシュサーバ１５０＿１は、コンテンツ７１０を一時記憶する。この後、例えば、ユーザ端末１７０＿２からコンテンツ７１０の配信要求があったときのキャッシュサーバ１５０＿１の動作は、キャッシュサーバ１５０＿２と同様である。
ライブ配信７２０ａ，７２０ｂ及びコンテンツ配信７１０ａは、例えば、リファレンスデータ参照による伸長処理を行うＭＰＥＧストリーム等で行われる。
ＩＰネットワーク１４０は、基本的にはベストエフォート型であり、ＭＰＥＧストリームを長時間途切れずに配信には適応していない。
この課題を解決する従来技術として、例えば、リアルタイム転送プロトコル（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ、以下、ＲＴＰと称する。）、リアルタイム転送制御プロトコル（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ、以下、ＲＴＣＰと称する。）、及びリアルタイム・ストリーム制御プロトコル（Ｒｅａｌ  Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ、以下ＲＴＳＰと称する。）等のストリーミング技術がある。
ＲＴＰは、メディア同期が受信側で可能となるように、音声データや映像データを伝送する際のパケット形式を定めた伝送プロトコルである。ＲＴＳＰは、コンテンツの配信開始や一時停止等のようなストリーム制御を行うプロトコルである。ＲＴＣＰは、音声や映像のストリームに対するフロー制御に必要な情報やメディア同期のための基準時間情報を伝達する手順を定めているプロトコルである。
これらのプロトコルによって、ユーザ端末と配信元とのネゴシエーション、データ配信時におけるネットワーク負荷、及びユーザ端末の処理能力等の与えられた環境を考慮したより快適なＲＴＰストリーム（コンテンツ配信又はライブ配信）がリアルタイムで制御される。
しかしながら、従来のストリーミング環境においては、ライブ配信は、ストリーム・サーバ（配信側）から、固定化された複数の符号化レートのデータを不特定多数のユーザ端末（受信側）に対して配信している。
ユーザ端末は、自身の処理能力に応じて、配信元から固定化された複数の符号化レートのデータの内から選択して受信している。従って、不特定多数のユーザ端末に対して、それぞれ、ネットワーク負荷及びユーザ端末の処理能力等をリアルタイムに考慮した、快適なマルチキャスト型のコンテンツ配信及びライブ配信を実現していない。
すなわち、従来のストリーミング環境は、コンテンツ配信において、或る１つのコンテンツ（ワンソース）を、符号化方式のみならず、リアルタイムな最適符号化レートも各ユーザ端末に対応したデータ（マルチユース）を配信することは困難である。
これを解決するためには、ユーザ端末数分のリアルタイムエンコーダ、若しくは全符号化レートのデータのデータベースといった、莫大なハードウェアが必要であり現実的ではない。
すなわち、コンテンツ、符号化方式のみならず符号化レートまでを範疇としたワンソース・マルチユース化ができない。
また、ライブ配信において、リアルタイムエンコーダ１３０がリアルタイムエンコードデータを、そのままネットワークに配信するため、ユーザ端末は、コンテンツ・サーバに対して、巻き戻し、一時停止等のコミュニケーション（選択性）の拡張が困難である。
したがって、ユーザ端末は、コンテンツ配信とライブ配信が異なることを考慮したサービスを受けなければならない。また、配信サーバは、コンテンツ・サーバとライブ・サーバが独立装置であり、それぞれ独立に制御する必要があり、コンテンツ配信とライブ配信の融合が困難である。
コンテンツ配信において、コンテンツに対応する複数の符号化データを予めデータベース化しているため、多数のユーザが視聴する映画コンテンツ、或る個人ユーザのみが視聴するパーソナルビデオコンテンツに関係なく、全コンテンツデータをデータベース化する必要があり、莫大なデータベース容量が必要となる。
このため、最近のトレンドである個人ユーザがオリジナルに制作したディジタルコンテンツ等を格納するパーソナルデータベースの構築にも限界が生じる。
また、コンテンツ配信において、データベースは、圧縮された符号化データを格納しており、ＭＰＥＧストリームにおけるシーケンスヘッダの任意位置への挿入／削除が困難なため、ユーザ端末（受信側）任意の映像の頭出し機能、アクセス回線種別、ネットワークの混雑度、ユーザ端末処理能力等を考慮した最適符号化レート／解像度変更等が困難である。
また、従来のコンテンツ配信又はライブ配信は、配信サーバとキャッシュサーバ（エッジサーバ）が独立配備かつ独立動作しており、キャッシュサーバでは、ユーザ端末（受信側）から要求されたコンテンツ又はライブ、符号化方式を考慮したヒット／ミス判定は可能である。
しかし、ネゴシエーション又はユーザ端末からのＲＲ（Ｒｅｃｅｉｖｅｒ  Ｒｅｐｏｒｔ）タイプのＲＴＣＰパケットのフィードバックをトリガとして決定した符号化レートまでを考慮した要求データの視聴開始／停止／変更を管理できない。したがって、視聴率を考慮したヒット／ミス判定を実施することが困難である。
従来のコンテンツ配信又はライブ配信は、ネゴシエーション動作時又はストリーミングにおけるＲＲタイプのＲＴＣＰパケットフィードバック時のような、ユーザ端末からのアクションに対応して、ストリーム・サーバが動作している。
したがって、ある映画コンテンツの配信開始となった日時に不特定多数ユーザからの視聴要求が重なった場合に、トランスコーダ（ｔｒａｎｓｃｏｄｅｒ）へのアクセス競合が多数発生し、ユーザ端末に対する配信サービスの即応性が困難になる。
また、従来のコンテンツ配信又はライブ配信におけるキャッシュサーバ（エッジサーバ）は、様々なコンテンツ又はライブデータ、符号化方式、符号化レート等のデータが格納されており、ユーザ端末が要求するデータの有無の確認を全格納データに対して行うため、そのヒット／ミス判定回路は莫大なハードウェア規模が必要になる。
また、従来のコンテンツ配信又はライブ配信は、配信サーバとキャッシュサーバ（エッジサーバ）が独立配備かつ独立動作しており、ユーザ端末からのキャッシュサーバ（エッジサーバ）内に格納されていない新コンテンツ又はライブ、新符号化方式、新符号化レートが要求された場合、ミス判定になる。
これにより、配信サーバは上記コンテンツ、符号化方式に対応したデータをキャッシュサーバに配信するため、キャッシュサーバは、必ず既に格納されているデータを破棄しなければならない。
また、キャッシュサーバ（エッジサーバ）のヒット／ミス判定において、配信サーバ側の混雑度等を考慮しないため、配信サーバの即応性が悪い場合には、配信データのスループットの低下、揺らぎ等が発生する。
また、従来の階層符号化において、ある階層データの符号化レート又は解像度等を変更する場合には、上記階層をリファレンスデータとして参照し、符号化処理を実施する。
以後、全上位階層データも再生成する必要があるため、莫大なハードウェアが必要となり、かつトランスコーダ等の資源の使用回数の増大（資源の有効活用が困難）を招く。
そこで本発明は、ストリーミング技術等によるインターネット等を媒体としてライブ及びコンテンツを配信するストリーム・サーバにおいて、以下の項目（１）〜（９）を目的とする。
（１）不特定多数ユーザ端末に対して、それぞれ与えられた環境、すなわち、ネットワーク負荷、ユーザ端末の処理能力、又はストリーム・サーバの混雑度等にリアルタイムに対応したコンテンツ配信又はライブ配信を行う。
（２）コンテンツ配信とライブ配信とを融合することを、少ないハードウエアで実現する。
（３）必要なデータベースの容量を削減する。
（４）要求されたコンテンツ及び符号化方式のみならず、要求された符号化レートに対応したワンソース・マルチユースを実現する。
（５）ユーザ端末が、アクセス回線種別、ネットワークの混雑度、及びユーザ端末処理能力に対応した、任意の映像の頭出し、最適符号化レート変更、及び解像度変更を行うことを可能とする。
（６）視聴率に対応したコンテンツ又はライブ配信サービスを行う。
（７）ユーザが要求したデータの有無の判定を高速化する。
（８）ユーザから要求された新コンテンツ又は新ライブ、新符号化方式、及び新符号化レートのデータのヒットミスを少なくする。
（９）階層符号化において、符号化レート及び解像度の変更の効率化を図る。
〈先行技術文献〉
・特開２０００−２２８６６９号
・特開２００１−５４０９５号
・特開２００１−５４０９４号
・特開平１０−１０８１６０号
・特開２０００−２９９７０２号
【発明の開示】
上記の課題を解決するため、本発明のストリーム・サーバは、１つ以上のトランスコーダと、データを格納するキャッシュ型データベースと、コンテンツ又はライブ、符号化方式、及び符号化レートに関して要求されたデータが該キャッシュ型データベースに格納されていないとき、該キャッシュ型データベースに該要求されたデータが格納されるように該トランスコーダ及び該キャッシュ型データベースを連携して制御するヒット／ミス判定部と、を備えたことを特徴としているストリーム・サーバ。
すなわち、トランスコーダは、通常の如く、指定されたコンテンツ又はライブを、指定された符号化方式の指定された符号化レートのデータに変換する。このデータをキャッシュ型データベースは格納する。
ヒット／ミス判定部は、符号化方式、及び符号化レートに関して要求されたデータが該キャッシュ型データベースに格納されていないとき、要求されたデータをキャッシュ型データベースに格納することを、トランスコーダ及びキャッシュ型データベースが連携して制御する。
これにより、キャッシュ型データベースは、例えばユーザ端末から要求されたコンテンツ又はライブを、要求された符号化方式の要求された符号化レートのデータとして格納することになり、各ユーザ端末は、要求した符号化方式の符号化レートのコンテンツ配信又はライブ配信を実現することが可能になる。
なお、ここで言うキャッシュ型データベース及びトランスコーダは、後述するそれぞれ制御／調停部が含んでいるものとするが、以下において、キャッシュ型データベースをキャッシュ型データベース本体とその制御／調停部に分け、トランスコーダをトランスコーダとその制御／調停部に分けて表示することがある。
また、本発明は、該トランスコーダがエンコーダ又はＣＯＤＥＣであることが可能である。
すなわち、本発明においてトランスコーダには、ＣＯＤＥＣ、及びエンコーダを含むものとする。例えば、ライブ配信の場合、トランスコーダの代わりにエンコーダを用いることが可能である。
また、本発明は、該キャッシュ型データベースが、同一のコンテンツ又はライブ及び符号化方式に対して異なる符号化レートの該データをそれぞれ格納する複数のラインを有することができる。
すなわち、キャッシュ型データベースは、複数のラインを有し、これらのラインには、それぞれ、例えば、同一のコンテンツ及び符号化方式に対して異なる符号化レートに変換したデータが格納される。
これにより、不特定多数のユーザ端末に対してマルチキャスト型コンテンツ配信又はライブ配信を実現する。すなわち、コンテンツ又はライブ、符号化方式、さらには符号化レートを各ユーザ端末に対応して配信するワンソース・マルチユースを実現することが可能になる。
また、本発明は、ユーザ端末との間で、呼制御、又は該データの配信の開始制御、一時停止制御、若しくは巻戻し制御に関するネゴシエーションを行い、その結果を該ヒット／ミス判定部に通知する呼制御／ネゴシエーション処理部をさらに有し、該ヒット／ミス判定部が、該結果に基づき該トランスコーダ及び該キャッシュ型データベースに対する連携制御を行うことが可能である。
すなわち、呼制御／ネゴシエーション処理部はユーザ端末との間で、呼制御、又は該データの配信の開始制御、一時停止制御、若しくは巻戻しのネゴシエーションを行う。
この結果に基づき、ヒット／ミス判定部は、キャッシュ型データベースに格納されたデータの配信の開始、一時停止、又は巻戻し制御を行う。
これにより、コンテンツ配信に対する開始、一時停止、巻戻制御が可能になるとともにライブ配信をデータをキャッシュ型データベースに格納後、行うことにより、ライブ配信に対する開始、一時停止、巻戻制御も可能になる。
また、本発明は、さらに、ユーザ端末との間のネットワーク負荷、コンテンツサーバの混雑度、又はユーザ端末の処理能力の少なくともいずれか１つを監視し、監視結果を該ヒット／ミス判定部に与えるネットワーク監視部を有し、該ヒット／ミス判定部が該監視結果に基づき最適符号化レートを決定することができる。
すなわち、ネットワーク監視部は、ユーザ端末との間のネットワーク負荷、コンテンツサーバの混雑度、又はユーザ端末の処理能力を監視する。この監視結果に基づきヒット／ミス判定部は、各ユーザ端末に対する最適な符号化レートを決定する。
これにより、例えば、ネットワーク負荷、コンテンツサーバの混雑度、ユーザ端末の現在の処理能力等をリアルタイムで考慮した符号化レートのコンテンツ配信又はライブ配信が可能になる。
すなわち、与えられた環境の中で、ユーザに対して、より快適なコンテンツ配信又はライブ配信をリアルタイムに制御することが可能になる。
また、本発明では、所定のプロトコルを実装し、該所定プロトコルに基づきユーザ端末との間の通信処理を行うプロトコル実装処理部をさらに有することができる。
すなわち、プロトコル実装処理部は、本ストリーム・サーバとユーザ端末との間の通信処理を行うプロトコルを実装している。この実装されたプロトコルに基づき、コンテンツ配信又はライブ配信の及びそれらの制御を実行することができる。
また、本発明では、該プロトコル実装処理部が、少なくともＩＰヘッダ処理部、ＵＤＰヘッダ処理部、ＲＴＰヘッダ処理部、ＲＴＣＰヘッダ処理部、及びＲＴＳＰヘッダ処理部の中のいずれか１つを備えることができる。
これにより、ＩＰ、ＵＤＰ、ＲＴＰ、ＲＴＣＰ、ＲＴＳＰ等のプロトコルに基づきコンテンツ配信又はライブ配信及びそれらの制御することが可能になる。
また、本発明では、該プロトコル実装処理部が、ＭＰＥＧシーケンスヘッダ処理部を備えていることができる。
これにより、アクセス回線種別、ネットワークの混雑度、又はユーザ端末能力を考慮した、ＭＰＥＧ符号化方式の最適符号化レートの変更及び解像度変更、並びに任意の映像の頭出し機能等が容易になる。
また、本発明では、該トランスコーダが、入力した少なくとも素材データ、トランスコードデータ、及びライブデータの内のいずれか１つを該指定された符号化方式の指定された符号化レートのデータに変換することができる。
すなわち、トランスコーダは、例えば、ソースデータベース装置から素材データ又はトランスコードデータを入力し、映像入力装置からライブデータを入力して該データに変換することができる。
なお、ストリーム・サーバとソースデータベース装置及び映像入力装置との接続は、直接接続及びネットワークを介した接続のいずれでもよい。
また、本発明では、該ヒット／ミス判定部が、要求されたコンテンツ又はライブの検索、その符号化方式の検索、符号化レートの検索、及びデータが有効であるか否かの検索の順序を所定の順序で行い要求データのヒット／ミス判定を行うことができる。
すなわち、ヒット／ミス判定部は、例えば、要求されたコンテンツ又はライブ及びその符号化方式の検索、符号化レートの検索、及びデータが有効であるか否かの検索の順序で要求データのヒット／ミス判定を行う。
これにより、ヒット／ミス判定が容易になると共に、ハードウェアの大幅な削減が可能になる。
また、本発明では、該ヒット／ミス判定部が、該要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータが該キャッシュ型データベースに格納されているか否かの判定に、該符号化レートが許容範囲に入っている否かを判定することができる。
すなわち、該ヒット／ミス判定部が、該要求されたコンテンツ又はライブ、符号化方式、及び符号化レートに変換されたのデータが該キャッシュ型データベースに格納されているか否かの判定するとき、例えば、要求された符号化レートと同一符号化レートでなく、要求された符号化レートから許容範囲にある符号化レートのデータもヒットしたものとみなす。
これにより、要求された符号化レートの代わりに、許容範囲内の符号化レートのデータを配信することが可能になり、要求された全ての符号化レートのデータを格納する必要がなくなり、効率的にキャッシュ型データベースを運用することが可能になるとともに、安定したコンテンツ配信及びライブ配信が実現する。
また、本発明では、該ヒット／ミス判定部が、該要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータが該キャッシュ型データベースに格納されていないとき、該要求されたコンテンツ又はライブ、要求された符号化方式であり、該要求された符号化レートに近い符号化レートのデータを破棄し、該データが格納されていた位置に、該要求されたデータを格納するように該トランスコーダ及び該キャッシュ型データベースを連携して制御することができる。
すなわち、ヒット／ミス判定部は、該要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータが該キャッシュ型データベースに格納されていなとき、該要求されたコンテンツ又はライブであって要求された符号化方式であるが、該要求された符号化レートに近い符号化レートのデータを検索して破棄する。
そして、ヒット／ミス判定部は、該データが格納されていた位置に、該要求されたデータを格納するように該トランスコーダ及び該キャッシュ型データベースを連携して制御する。
これにより、要求されたデータをユーザ端末に配信することが可能になる。
また、本発明では、該ヒット／ミス判定部が、低視聴率のコンテンツデータ又はライブデータ、又は低視聴率の符号化レートのデータを破棄することができる。
これにより、該キャッシュ型データベースのサイズを削減することが可能になるとともに、高視聴率のコンテンツ又はライブのデータを保持され続けるため、キャッシュ型データベースのヒット率も高くなる。
また、本発明では、該キャッシュ型データベースは、該ネットワーク監視部から与えられた、該要求されたデータについて、その視聴開始時刻情報、停止時刻情報、及び変更時刻情報を格納し、該ヒット／ミス判定部が、該情報に基づきヒット／ミス判定を行うことができる。
すなわち、該キャッシュ型データベースは、該ネットワーク監視部から与えられた、該要求されたデータについて、その視聴開始時刻情報、停止時刻情報、及び変更時刻情報を格納する。該ヒット／ミス判定部が、該情報に基づき、例えば、リアルタイムな視聴率を計算し、この視聴率に基づきヒット／ミス判定を行う。
これにより、ヒット／ミス判定部は、例えば、リアルタイムな視聴率を考慮したヒット／ミス判定を行うことが可能になる。
また、本発明では、該ヒット／ミス判定部が、低視聴率のコンテンツデータ又はライブデータ、低視聴率の符号化方式、又は低視聴率の符号化レートのデータの内の少なくとも１つを破棄して、該破棄されたデータが格納されていた場所に、要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータを格納するように該トランスコーダ及びキャッシュ型データベースに指示することができる。
すなわち、ヒット／ミス判定部は、例えば、要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータを格納する場所がキャッシュ型データベース内に無いとき、低視聴率のコンテンツデータ又はライブデータ、低視聴率の符号化方式、又は低視聴率の符号化レートのデータを破棄する。
そして、破棄したデータが格納されていた場所に、要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータを格納する。
これにより、要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータを格納する場所を確保することが可能になる。
また、該キャッシュ型データベースのサイズを削減することが可能になるとともに、高視聴率のコンテンツ又はライブのデータが保持され続ける。
これにより、キャッシュ型データベースのヒット率も高くなり、効率的なキャッシュ型データベースの運用を実現することができる。
また、本発明では、該ヒット／ミス判定部は、未使用トランスコーダがあるとき、このトランスコーダ及び該キャッシュ型データベースを制御して、新規コンテンツ又は新規ライブを所定符号化レートの所定符号化方式のデータに変換し、該キャッシュ型データベースに格納することができる。
すなわち、ヒット／ミス判定部は、新規コンテンツ又は新規ライブがあるときで、且つ使用していないトランスコーダがあるとき、新規コンテンツ又は新規ライブを所定符号化レートの所定符号化方式のデータに変換し、該キャッシュ型データベースに格納するように該トランスコーダ及び該キャッシュ型データベースを制御する。
これにより、トランスコーダは、例えば、要求されたコンテンツの変換を行っていないときで且つキャッシュ型データベースに空きがあるとき、事前に新規コンテンツを所定符号化方式の所定符号化レートのデータに変換することが可能になる。この結果、トランスコーダ及びキャッシュ型データベースのアクセス競合を回避することが可能になるとともに、資源の有効活用が実現できる
さらに、本発明では、該トランスコーダが、空間スケーラビリティ、時間スケーラビリティ、又はＳＮＲスケーラビリティによる階層符号化において、符号化レート変更対象階層及びその１つ上位の階層の符号化データのみ新規に作成し、該新規上位階層より伸長された復号データと現上位階層より伸長された復号データの差分絶対値の和が所定の閾値以下であるとき該新規作成された変更対象階層及び上位階層を現階層とすることが可能である。
これにより、他に使用されている符号化レートデータに対して影響を与えることなく、ターゲットとなる符号化レートを変更することができる。
また、符号化レート変更対象階層及びその１つ上位の階層を新規作成するのみで、全上位階層のデータを新規に作成する必要がなくなり、莫大なハードウエアが必要でなくなるとともに、トランスコーダ等の資源の使用回数を少なくすることが可能になる。
【図面の簡単な説明】  図１は、本発明に係るストリーム・サーバの一実施例を示したブロック図である。
図２は、本発明に係るストリーム・サーバにおけるキャッシュ型データベースの一構成例を示したブロック図である。
図３は、本発明に係るストリーム・サーバにおける３段階検索手順例を示した図である。
図４は、本発明に係るストリーム・サーバのネゴシエーション時における動作手順を示したフローチャート図である。
図５は、本発明に係るストリーム・サーバのネットワーク監視時における動作手順を示したフローチャート図である。
図６は、本発明に係るストリーム・サーバにおける要求コンテンツ（又はライブ）及び符号化方式等のヒット／ミス判定及びその後の処理を示した図である。
図７は、本発明に係るストリーム・サーバにおける要求符号化レート等のヒット／ミス判定及びその後の処理を示した図である。
図８は、本発明に係るストリーム・サーバにおける階層符号化における符号化レート変更例（低符号化レート→高符号化レート）を示した図である。
図９は、本発明に係るストリーム・サーバにおける階層符号化における符号化レート変更法（高符号化レート→低符号化レート）を示した図である。
図１０は、従来のコンテンツ配信及びライブ配信を示したブロック図である。
【符号の説明】
2004040908.tif 000003
2004040908.tif 000004
【発明を実施するための最良の形態】  図１は、本発明に係るストリーム・サーバ１００の一実施例を示している。このサーバ１００は、トランスコーダ制御／調停部１０、トランスコーダ２０＿１〜２０＿Ｌ（以下、符号２０で総称することがある。）、データベース制御／調停部３０、キャッシュ型データベース４０、ヒット／ミス判定部５０、ネットワーク監視部６０、呼制御／ネゴシエーション処理部７０、及びプロトコル実装処理部８０で構成されている。
キャッシュ型データベース４０は、コンテンツデータ又はライブデータ（以下、コンテンツデータ及びライブデータをコンテンツデータで総称することがある。）を格納するライン４３＿１〜４３＿Ｎ（以下、符号４３で総称することがある。）で構成されている。
プロトコル実装処理部８０は、ＩＰヘッダ処理部８１、ＵＤＰヘッダ処理部８２、ＲＴＰヘッダ処理部８３、ＭＰＥＧシーケンスヘッダ処理部８４、ＲＴＣＰヘッダ処理部８５、ＲＴＳＰヘッダ処理部８６で構成されている。
ヒット／ミス判定部５０は、キャッシュ型データベース４０に要求データが格納されているか否かの確認を行い、ネットワーク監視部６０はＲＴＣＰプロトコルでネットワークを監視し、呼制御／ネゴシエーション処理部７０は、ＲＴＳＰプロトコルで呼制御及びネゴシエーションを行う。
図２（５）は、図１に示した、キャッシュ型データベース４０のより詳細な構成例を示している。このデータベース４０は、タグラム（ＴＡＧ  ＲＡＭ）４１、タグラム４２、及びキャッシュ４３で構成されている。
タグラム４１は、“ＭＲＵ（Ｍｏｓｔ  Ｒｅｃｅｎｔｌｙ  Ｕｓｅｄ）”、“コンテンヅ”、“符号化方式”、及び“タグラム４２のアドレス”のフィールドから成るタグラム４１＿１〜４１＿Ｍで構成されている。
タグラム４１は、“コンテンツ”及び“符号化方式”単位に管理され、“コンテンツ”及び“符号化方式”には、それぞれ、例えば、コンテンツ情報及びその符号化方式情報が格納される。
タグラム４１の“ＭＲＵ”には、ネゴシエーション時又はネットワーク監視（（ＲＲタイプのＲＴＣＰパケットフィードバック）時の符号化レート変更時における、視聴開始／停止／変更時刻情報等の視聴履歴情報（例えば、視聴率情報）が格納される。
タグラム４１の“タグラム４２のアドレス”には、“コンテンツ”及び“符号化方式”に対応するタグラム４２の先頭アドレスが格納される。
タグラム４２は、“ＭＲＵ”、“符号化レート”、及び“階層”のフィールドから成るタグラム４２＿１〜４２＿Ｎ（以下、符号４２で総称することがある。）で構成され、“符号化レート”単位に管理される。
タグラム４２の“ＭＲＵ”には、符号化レート変更時における、視聴開始／停止／変更時刻情報等の視聴履歴情報（視聴率情報）が格納される。
“符号化レート”、及び“階層”には、それぞれ、符号化レート情報及びその階層が格納される。
キャッシュ４３は、それぞれ、データ１〜データＸ１、…、データ１〜データＸＮから成るライン４３＿１〜４３＿Ｎ（以下、符号４３で総称することがある。）で構成されている。各ライン４３は、各データの有効／無効を示す有効フィールドをさらに含んでいる。各データ１〜Ｘ１等に格納される、コンテンツデータの管理単位はＭＰＥＧデータの場合は、ＧＯＰ（Ｇｒｏｕｐ  Ｏｆ  Ｐｉｃｔｕｒｅ）である。
このライン４３＿１〜４３＿Ｎは、それぞれ、タグラム４２＿１〜４２＿Ｎに対応しており、この対応関係は、例えば、タグラム４２にライン４３の先頭アドレスを示すフィールド（図示せず）を設けて示す。
同図（２）は、同図（５）に示したタグラム４１＿１をより詳細に示しており、このタグラム４１＿１には、管理単位のコンテンツ及び符号化方式が、それぞれ「コンテンツ７１０＿１」及び「ＭＰＥＧ２」であり、そのＭＲＵが視聴履歴０１〜視聴履歴０ｘであることを示している。
さらに、タグラム４１＿１には、「コンテンツ７１０＿１」及び「ＭＰＥＧ２」に対応するタグラム４２（符号化レート）の先頭アドレスが、「０ｘ０」，「０ｘ１」，…，「０ｘｙ」であることが示されている。
同図（３）は、同図（５）に示したタグラム４２＿１，４２＿２，…のより詳細例を示している。この例では、タグラム４１＿１のタグラム４２アドレス＝“０ｘ０”で指定されたタグラム４２＿１が示されている。
このタグラム４２＿１は、符号化レート＝“１Ｍｂｐｓ”の階層が“１”であり、そのＭＲＵが視聴履歴１１〜１Ｘであることを示している。
ストリーム・サーバ１００の基本的動作として、ヒット／ミス判定部５０が、ユーザ端末からの契機〔１〕ネゴシエーション時、又は契機〔２〕ＲＲタイプのＲＴＣＰパケットフィードバック時（ネットワーク監視時）に、それぞれキャッシュ型データベース４０のヒット／ミス判定を行う。
また、ヒット／ミス判定部５０は、契機〔１〕又は〔２〕以外の契機〔３〕未使用のトランスコーダが存在し、且つ人気コンテンツがソースデータベースに新規格納され、キャッシュ型データベース４０には未格納の場合、自律的な連携動作でキャッシュ型データベース４０のヒット／ミス判定を行い、人気コンテンツの符号化データをキャッシュ型データベース４０に格納する。
これにより、例えば、人気コンテンツ配信開始時における不特定多数ユーザからの配信要求が競合した際においても、通常はキャッシュ型データベースより読み出すことができる。このように、有限数のトランスコーダ資源の有効活用ができるとともに、ユーザ端末（受信側）に対する配信サービスの即応性が実現できる。
図３は、ストリーム・サーバ１００のヒット／ミス判定部の基本的な動作手順を示している。ストリーミング技術においては、図２に示したように、例えば、コンテンツ（又はライブ）７１０＿１及び符号化方式（ＭＰＥＧ２）に対して複数の符号化レート（１Ｍｂｐｓ，５Ｍｂｐｓ，…，２０Ｍｂｐｓ）がサポートされる。
そこで、ヒット／ミス判定部５０は、キャッシュ型データベース４０のヒット／ミス判定を下記の（Ｔ１）〜（Ｔ３）の３段階で行う。
（Ｔ１）タグラム４１を検索して、要求コンテンツ又はライブ及び符号化方式が格納されているか否かを判定する（図２（１）の判定Ｔ１参照）。
（Ｔ２）次に、タグラム４２の検索を検索して、要求符号化レートが格納されているか否かを判定する（図２（１）の判定Ｔ２参照）。
（Ｔ３）最後に、キャッシュ４３の「有効（Ｖａｌｉｄ）フィールド」を検索して、要求データが格納されているか否かを判定する（図２（１）の判定Ｔ３参照）。
［１］ネゴシエーション時
図４は、本発明のストリーム・サーバ１００のネゴシエーション時（契機〔１〕）における動作手順例を示している。同図及び図１、図２を参照してネゴシエーション時における動作手順を以下に説明する。
なお、この説明においては、図１に示したソースデータベース７００に格納されているコンテンツ７１０をユーザ端末１７０が要求した場合について説明する。
ユーザ端末がライブ７２０を要求した場合も同様であるが、ライブ配信の場合、トランスコーダ２０としてエンコーダを用いることもでき、同図に示したトランスコーダ制御／調停部１０はエンコーダ制御／調停部１０になる。
図４において、破線で囲まれたステップＳ１００はヒット／ミス判定部５０のキャッシュ型データベース検索手順を示し、破線で囲まれたステップＳ２００はトランスコーダ制御／調停部１０、データベース制御／調停部３０、及びヒット／ミス判定部５０におけるトランスコーダエントリ手順を示し、破線で囲まれたステップＳ３００はプロトコル実装処理部８０のプロトコル実装処理手順を示している。
図１において、呼制御／ネゴシエーション処理部７０は、ユーザ端末１７０から呼制御／ネゴシエーション動作によりストリーム・サーバ１００とユーザ端末１７０との間のコネクションを確立する。
ステップＳ１１０〜Ｓ１３０：ヒット／ミス判定部５０は、ユーザ端末１７０が要求したコンテンツデータ、符号化方式、及び符号化レート、例えば、コンテンツ７１０＿１、ＭＰＥＧ２、及び５Ｍｂｐｓと一致するデータがキャッシュ型データベース４０に格納されているか否かを確認する。
すなわち、図２において、ヒット／ミス判定部５０は、ユーザ端末１７０から同図（１）に示した（Ｔ０）例えば、コンテンツ名＝コンテンツ７１０＿１、符号化方式＝“ＭＰＥＧ２”、及び符号化レート＝“５Ｍｂｐｓ”の要求を受ける。
なお、ネゴシエーション時には、同図（１）に示したＧＯＰ番号の要求はない。
そこで、ヒット／ミス判定部５０は、同図（２）において、タグラム４１から、コンテンツ７１０＿１及び符号化方式＝“ＭＰＥＧ２”を検索する同図（１）に示したヒット／ミス判定Ｔ１を行い、タグラム４１＿１にヒットする。
さらに、ヒット／ミス判定部５０は、タグラム４１＿１のタグラム４２アドレスフィールドに示された先頭アドレス＝０ｘ０，０ｘ１，…，０ｘｙにそれぞれ対応するタグラム４２＿１〜４２＿ｙの中から符号化レート＝“５Ｍｂｐｓ”を検索する同図（１）に示したヒット／ミス判定Ｔ２を行い、タグラム４２＿２にヒットする。
ステップＳ１８０：さらに、ヒット／ミス判定部５０は、ヒットしたタグラム４２＿２に対応するライン４３＿２のデータが有効であるか否かを判定するヒット／ミス判定Ｔ３（図２（４）参照）を行う。
符号化されたデータが有効である場合、ヒット／ミス判定部５０は、有効なデータ“１”をデータ８０２として読み出しプロトコル実装処理部８０に与える。この動作を繰り返すことにより、ライン４３＿２のデータ１〜データＸ２は、順次、プロトコル実装処理部８０に与えられることになる。
データが無効である場合、ヒット／ミス判定部５０は、トランスコーダエントリのステップＳ２１０に進む。
ステップＳ３１０〜Ｓ３４０：プロトコル実装処理部８０は、ＭＰＥＧシーケンスヘッダ、ＲＴＰヘッダ、ＵＤＰヘッダ、及びＩＰヘッダをデータ８０１に挿入した後、ＩＰネットワーク１４０を経由して、ユーザ端末１７０にライン４３＿２に格納されたコンテンツの配信を開始する（図２（１）のデータ配信Ｔ４）。
ステップＳ１４０〜Ｓ１７０：ステップＳ１１０、Ｓ１２０でミスした（データが存在しない）場合、ヒット／ミス判定部５０は、キャッシュ型データベース４０の内から、データ未格納ライン４３の検索、又は、予め設定された閾値ａより低い視聴率のコンテンツの検索、低視聴率の符号化方式の検索、低視聴率の符号化レートの検索を行う。
すなわち、ヒット／ミス判定部５０は、図２（５）において、データ未格納ライン４３を検索し、無い（ミス）場合、タグラム４１のＭＲＵの内で閾値ａより低い視聴率を示したコンテンツ／符号化方式を検索し、無い（ミス）場合、タグラム４２のＭＲＵの内で閾値ａより低い視聴率を示した符号化レートを検索する。
ステップＳ２１０：上記の検索の１つにヒットした（ヒットラインがある）場合、ヒット／ミス判定部５０は、トランスコーダ制御／調停部１０及びデータベース制御／調停部３０に対して、それぞれトランスコーダエントリ要求信号８００及び信号８０１与える。
トランスコーダ制御／調停部１０は、例えば、トランスコーダ２０＿２が未使用である場合、トランスコーダエントリ要求信号８００が示す、ユーザが要求したコンテンツ（素材又はトランスコード）７１０をソースデータベース７００からトランスコーダ２０＿２に与える。
未使用のトランスコーダが無い場合、ステップＳ２９０に進む。
ステップＳ２２０：トランスコーダ２０＿２は、コンテンツ７１０に対してリアルタイムエンコード処理したデータをデータベース制御／調停部３０に与える。データベース制御／調停部３０は、キャッシュ型データベース４０内の例えば未格納ライン（又は低視聴率ライン）４３＿１にエンコードされたデータを格納する（キャッシュフィル）。
ステップＳ２３０：ヒット／ミス判定部５０は、キャッシュフィルされたライン４３＿２からデータ８０２を読み出しプロトコル実装処理部８０に与える。
ステップＳ３１０〜Ｓ３４０：プロトコル実装処理部８０は、上記のステップＳ３１０〜Ｓ３４０と同様に、ＩＰネットワーク１４０を経由して、順次、ユーザ端末１７０に要求されたコンテンツ配信又はライブ配信を開始する。
ステップＳ２９０：上記のステップＳ１４０〜Ｓ１７０において、未格納ラインの検索、低視聴率のコンテンツの検索、低視聴率の符号化方式の検索、及び低視聴率の符号化レートの検索が全てミスの場合、又はステップＳ２１０において、未使用トランスコーダ２０が無い（トランスコーダエントリ要求に失敗した）場合、ユーザ端末１７０からのエントリ要求は失敗となる。
［２］ネットワーク監視時
図５は、ストリーム・サーバ１００が、ユーザ端末１７０に対してコンテンツ配信又はライブ配信を行っている時、ユーザ端末１７０（図１参照）からＲＲタイプＲＴＣＰパケットを受信した時の動作手順を示している。
この動作手順を、図２を参照して以下に説明する。図５においてステップＳ４００はネットワーク監視手順を示し、ステップＳ５００はキャッシュ型データベースの検索手順を示し、ステップＳ６００はトランスコーダへのエントリ手順を示し、ステップＳ８００は、プロトコル実装処理手順を示している。
ステップＳ４１０：呼制御／ネゴシエーション処理部７０は、ユーザ端末１７０から送信されたＲＲタイプのＲＴＣＰパケットを受信し、このパケットに含まれるフィードバック情報をヒット／ミス判定部５０に与える。
ＲＲタイプＲＴＣＰパケットは、ストリームを受信したユーザ端末がストリームの受信状態（パケットの廃棄率（Ｆｒａｃｔｉｏｎ  Ｌｏｓｔ）、累積パケット廃棄率（Ｃｕｍｕｌａｔｉｖｅ  Ｎｕｍｂｅｒ  ｏｆ  Ｐａｃｋｅｔ  Ｌｏｓｔ）、パケット到着間のゆらぎ（Ｉｎｔｅｒａｒｒｉｖａｌ  Ｊｉｔｔｅｒ））に関する情報をストリーム送信側にフィードバックするパケットである。
この情報に基づき、ヒット／ミス判定部５０は、視聴者数、視聴履歴、パケット廃棄率、累積パケット廃棄率、パケット到着間隔の揺らぎ等より、現在のネットワークの混雑度、ユーザ端末１７０の能力等を考慮した最適符号化レートを算出する。
すなわち、ヒット／ミス判定部５０は、図２（１）のＴ０、すなわち、ユーザ端末１７０に対して配信しているコンテンツ名、符号化方式、符号化レート、及びＧＯＰ番号を決定する。
ステップＳ５１０：ヒット／ミス判定部５０は、算出した最適符号化レートと一致するデータがキャッシュ型データベース４０に格納されているか否かの確認を行う。
すなわち、ヒット／ミス判定部５０は、図２（２）及び（３）において、要求されたコンテンツ及び符号化方式に対する最適な符号化レートがあるか否かのヒット／ミス判定Ｔ１，Ｔ２を行う。
ステップＳ５９０，Ｓ７１０：最適な符号化レートが存在する（ヒット）場合、ヒット／ミス判定部５０は、符号化レートに対応するラインのデータが有効か否かのヒット／ミス判定Ｔ３を行う（同図（１）参照）。
データがヒットした（有効の）場合、ヒット／ミス判定部５０は、ヒットしたライン４３から読み出したデータ８０２をプロトコル実装処理部８０に与える。
ステップＳ８１０〜Ｓ８４０：プロトコル実装処理部８０は、ＭＰＥＧシーケンスヘッダ、ＲＴＰヘッダ、ＵＤＰヘッダ、ＩＰヘッダを挿入した最適符号化レートデータ８０２をユーザ端末１７０に、ＩＰネットワーク１４０を経由して順次配信する。これにより、前の符号化レートデータに継続して最適符号化レートデータ８０２が、ユーザ端末１７０に配信されることになる。
ステップＳ５９０，Ｓ７７０：データがミスした（無効の）場合は、キャッシュには要求する符号化レートは存在するが、対象となるデータ自体が存在しない状態を示す。
そこで、ヒット／ミス判定部５０は、信号８００及び信号８０１をそれぞれトランスコーダ制御／調停部１０及びデータベース制御／調停部３０に与える。
これらの信号８００及び信号８０１に基づき、現在使用中のトランスコーダは、要求されたコンテンツを、要求された符号化方式で要求された符号化レートのデータにエンコードし、このデータは、ステップＳ５１０でヒットしたライン４３に格納される（キャッシュフィル）。
ステップＳ７８０：ヒット／ミス判定部５０は、ヒットライン４３のデータを読み出して、プロトコル実装処理部８０に与える。
ステップＳ８１０〜Ｓ８４０：プロトコル実装処理部８０は、ＭＰＥＧシーケンスヘッダ、ＲＴＰヘッダ、ＵＤＰヘッダ、ＩＰヘッダを挿入したデータ８０２をユーザ端末１７０に、ＩＰネットワーク１４０を経由して順次配信する。
これにより、最適符号化レートのデータが、ユーザ端末１７０に配信されることになる。
ステップＳ５１０，Ｓ５２０：最適符号化レートのデータが存在しない（ミス）場合、ヒット／ミス判定部５０は、最適符号化レートに最も近い符号化データをキャッシュ型データベース４０から検索する。
すなわち、ヒット／ミス判定部５０は、図２（２）、（３）において、要求されたコンテンツ及び符号化方式に対応するタグラム４１に対応するタグラム４２の符号化レートの内で最適符号化ルートに最も近い符号化レート（比較対照符号化レート）を検索する。
ステップＳ５３０：差分絶対値ｘ＝｜最適符号化レート−比較対象符号化レート｜が予め設定された閾値ｂ以下の場合、ヒット／ミス判定部５０は、要求データが存在する（ヒット）とみなす。
ステップＳ５９０：そして、ヒット／ミス判定部５０は、ヒットとみなしたラインのデータが有効か否かのヒット／ミス判定Ｔ３を行い、有効である場合、データを読み出し、プロトコル実装処理部８０に与える。
すなわち、ヒット／ミス判定部５０は、図２（３）、（４）において、ヒットした符号化レートのタグラム４２に対応するライン４３から読み出した有効なデータ８０２をプロトコル実装処理部８０に与える。以後の動作は、上記のステップＳ８１０〜Ｓ８４０と同様である。
これにより、最適符号化レートのデータではないが、許容範囲内の符号化レートのデータ８０２が、ユーザ端末１７０に配信されることになる。
ステップＳ５４０：差分絶対値ｘが、設定された閾値ｂより大きく閾値ｃ以下である場合、ヒット／ミス判定部５０は、要求データが存在せず（図２（１）のヒット／ミス判定Ｔ１，Ｔ２におけるミス判定）且つキャッシュ型データベース４０に格納されている比較対象符号化レートのデータが不要である（ＲＲタイプのＲＴＣＰパケットによる符号化レートの変更要求がある）ため、トランスコーダ制御／調停部１０に対してトランスコーダエントリ要求信号８００を与える。
ステップＳ６１０，Ｓ６２０：トランスコーダ制御／調停部１０は、トランスコーダエントリ要求に対して、トランスコーダ２０の内に未使用トランスコーダ２０が存在する場合、素材データ又はトランスコードデータをソースとして、リアルタイムエンコード処理を行い、処理したデータをキャッシュ型データベース４０内の比較対象符号化レートライン（ミスライン）に格納する（キャッシュフィル）。
ステップＳ７２０：ヒット／ミス判定部５０は、このキャッシュフィルされたラインから読み出したデータ８０２をプロトコル実装処理部８０に与える。
ステップＳ８１０〜Ｓ８４０：プロトコル実装処理部８０は、データ８０１をＩＰネットワーク１４０を経由してユーザ端末１７０に順次配信する。
これにより、最適符号化レートとの差分絶対値が閾値ｂより大きく閾値ｃ以下の比較対象符号化レートのラインに最適符号化レートのデータをフィルすることが可能になる。このデータフィルによっても、比較対象符号化レートのラインのデータを使用するユーザ端末に対する映像及び音声への影響が少ない。
差分絶対値が設定された閾値ｃより大きい場合、比較対象データから要求データへの符号化レート変更を行うと、比較対象符号化レートのデータを使用するユーザに対する映像及び音声への影響が大きい。
そこで、ヒット／ミス判定部５０は以下の判定を行う。
ステップＳ５５０，Ｓ６３０：ヒット／ミス判定部５０は、比較対象符号化レートの差分絶対値が大きいため、キャッシュ型データベース４０の未格納ライン４３を検索し、対象となるラインが存在する（ヒット）場合、トランスコーダ制御／調停部１０に対してトランスコーダエントリ要求信号８００を与える。
ステップＳ６４０，Ｓ７３０：トランスコーダ制御／調停部１０は、トランスコーダエントリ要求に対して、未使用のトランスコーダ２０が存在する場合、素材データもしくはトランスコードデータを未使用トランスコーダ２０に与える。
このトランスコーダ２０は、与えられたデータに対してリアルタイムエンコード処理を行い、データベース制御／調停部３０を経由して未格納ライン４３に格納（キャッシュフィル）する。このフィルラインからデータ８０２が読み出されてユーザ端末に送信される。
ステップＳ５６０〜Ｓ５８０：ヒット／ミス判定部５０は、未格納ラインが無いため、キャッシュ型データベース４０から予め設定された閾値ａより低い視聴率のコンテンツ、符号化方式、又は符号化レートのライン４３を検索し、対象となるデータが存在する（ヒット）場合、トランスコーダ制御／調停部１０に対してトランスコーダエントリを要求する。
ステップＳ６５０，Ｓ６６０：トランスコーダ制御／調停部１０は、トランスコーダエントリ要求に対して、未使用のトランスコーダ２０が存在する場合、素材データもしくはトランスコードデータを未使用トランスコーダ２０に与える。
このトランスコーダ２０は、与えられたデータに対してリアルタイムエンコード処理を行いデータベース制御／調停部３０を経由してキャッシュ型データベース４０内の低視聴率ライン４３に格納する（キャッシュフィル）。
ステップＳ７４０：ヒット／ミス判定部５０は、キャッシュフィルされたライン４３からデータ８０２を読み出し、プロトコル実装処理部に与える。
ステップＳ８１０〜Ｓ８４０：プロトコル実装処理部８０は、上記のヘッダを挿入したデータをユーザ端末に順次配信を継続する。
ステップＳ５８０，Ｓ６７０，Ｓ６８０，Ｓ７６０：上記キャッシュ型データベースに格納されている、未格納ライン及び閾値ａより低い視聴履歴ライン検索において、対象となるデータが存在しない場合、ヒット／ミス判定部５０はトランスコーダ制御／調停部１０に対してトランスコーダエントリ要求信号８００を与える。
未使用トランスコーダが存在する場合、素材データもしくはトランスコードデータに対してはリアルタイムエンコード処理が行われ、キャッシュ型データベース４０内の比較対象符号化レートライン４３に格納する（キャッシュフィル）。このキャッシュフィルされたライン４３から読み出されたデータがプロトコル実装処理部８０に与えられる。
ステップＳ８１０〜Ｓ８４０：プロトコル実装処理部８０は、ユーザ端末１７０に順次データ配信を継続する。
ステップＳ６１０，Ｓ６３０，Ｓ６５０，Ｓ６７０，Ｓ７５０：未使用トランスコーダ２０が存在しない場合、ＲＲタイプのＲＴＣＰパケットに基づく符号化レート変更要求は失敗となる。
ヒット／ミス判定部５０は、現在の符号化レートのデータの送信を継続し、次回符号化レート変更要求を待つ。
このようなトランスコーダ制御／調停部１０、トランスコーダ２０、データベース制御／調停部３０、キャッシュ型データベース４０、及びヒット／ミス判定部５０の連携動作により、ストリーム・サーバ１００は、ライブ配信のみならず、コンテンツ配信においても、リアルタイムにネットワーク負荷、ユーザ端末の処理能力等を考慮した、リアルタイムエンコード処理を行うことが可能になる。
また、ストリーム・サーバ１００は、低視聴率の符号化レートの符号化方式のコンテンツデータ及びライブデータを破棄することにより、高視聴率の符号化レートの符号化方式のコンテンツデータ及びライブデータのみが、キャッシュ型データベース４０に格納され続けることになる。
この結果、通常は、キャッシュ型データベース４０に格納されている高視聴率データを多くのユーザ端末に配信することができる。
すなわち、ストリーム・サーバ１００は、不特定多数ユーザに対して、それぞれ、リアルタイムのネットワーク負荷、ユーザ端末１７０の処理能力、ストリーム・サーバ１００の混雑度等を考慮した、快適なマルチキャスト型コンテンツ配信及びライブ配信が実現でき、コンテンツ及び符号化方式のみならず、符号化レートまでを範疇とした、“ワンソース・マルチユース化”を実現できる。
また、ストリーム・サーバ１００は、不特定多数ユーザに対するコンテンツ配信データ及びライブ配信データは、通常、高視聴率の符号化レートの符号化方式のコンテンツデータ及びライブデータを格納するキャッシュ型データベースより読み出すことができる（ヒットする）ため、ユーザ数分のトランスコーダを備える必要はなく、トランスコーダ数の大幅な削減が可能になる。
また、ストリーム・サーバ１００のキャッシュ型データベース４０は、常に、個人ユーザのみが視聴する低視聴率のコンテンツ及びライブは破棄され、多数のユーザが視聴する映画コンテンツ等の高視聴率コンテンツ及び高視聴率ライブのみが保存され続けるため、データベースサイズの大幅な削減が実現でき、且つストリーム・サーバ１００でのパーソナルデータベースの配信サービスも容易となる。
また、ストリーム・サーバ１００は、トランスコーダ２０の後段にキャッシュ型データベース４０を配置し、コンテンツデータ及びライブデータを一旦キャッシュ型データベース４０に格納後、ユーザに配信されるため、ライブ配信においても、ユーザ端末（受信側）からストリーム・サーバ（配信側）に対する巻戻し、一時停止要求といったコミュニケーション機能（選択性）の拡張が可能である。
すなわち、ユーザ端末（受信側）１７０は、ライブ配信とコンテンツ配信の区別することなく、サービスを享受することができ、ライブ配信とコンテンツ配信の融合が可能となる。
また、ストリーム・サーバ１００は、キャッシュ型データベース４０の後段に、ＭＰＥＧシーケンスヘッダ処理部８４を挿入することにより、シーケンスヘッダに実装されている、フレームレート及び解像度等を変更することが容易となり、ユーザ端末（受信側）任意の映像の頭出し機能、アクセス回線種別、ネットワークの混雑度、ユーザ端末の処理能力等を考慮した、最適符号化レート／解像度変更等が容易に実現できる。
このように、本発明のストリーム・サーバ１００は、トランスコーダ２０とキャッシュ型データベース４０との連携動作により、不特定多数ユーザ端末１７０に対する快適なマルチキャスト型通信によるワンソース・マルチユース化、ユーザ端末１７０とストリーム・サーバ１００間のコミュニティ環境の構築によるライブ配信とコンテンツ配信の融合、与えられた環境の中で、ストリーム・サーバ（配信側）は、リアルタイムかつ最適な制御を実現でき、ユーザ（受信側）は、より快適な配信サービスを享受できると共に、さらに大幅なハードウェア削減が可能になる。
図６は、本発明のストリーム・サーバ１００のヒット／ミス判定部５０における要求コンテンツ（又はライブ）及び符号化方式等のヒット／ミス判定法をより詳細に示している。なお、同図に示されているステップ符号は、図４のステップ符号に対応している。
〔１〕ネゴシエーション時におけるキャッシュ型データベース４０の３段階検索フローに基づくヒット／ミス判定（１）〜（５）を以下に説明する。
（１）ヒット／ミス判定部５０は、タグラム４１を検索して、要求コンテンツ（又はライブ）及び符号化方式のヒット／ミス判定Ｔ１を行う。要求データが存在する（ヒット）場合には、後述する図７の要求符号化レートのヒット／ミス判定Ｔ２へ遷移する（図４のステップＳ１１０〜Ｓ１３０参照）。
（２）要求データがタグラム４１に存在しない（ミス）場合、ヒット／ミス判定部５０は、タグラム４２の未格納ライン４３を検索し、要求データを未格納ライン４３に格納する（同ステップＳ１４０，Ｓ２１０，Ｓ２２０参照）。
（３）タグラム４２の検索において、未格納ラインが存在しない（ミス）場合、ヒット／ミス判定部５０は、低視聴率のコンテンツラインを検索し、対象となるデータが存在する（ヒット）場合、低視聴率のコンテンツラインのデータを破棄して、このラインに要求データを格納する（同ステップＳ１５０，Ｓ１６０，Ｓ２１０，Ｓ２２０参照）。
（４）タグラム４１の検索において、低視聴率のコンテンツラインが存在しない（ミス）場合、ヒット／ミス判定部５０は、タグラム４２のＭＲＵより低視聴率の符号化レートラインを検索し、対象となるデータが存在する（ヒット）場合、低視聴率の符号化レートラインのデータを破棄し、このラインに要求データを格納する（同ステップＳ１７０，Ｓ２１０，Ｓ２２０参照）。
（５）タグラム４１，４２の検索において、低視聴率のコンテンツ、及び低視聴率の符号化レートが存在しない場合、ヒット／ミス判定部５０は対象データ読み出し失敗となる（同ステップＳ１８０参照）。
〔３〕未使用トランスコーダが有る時のキャッシュ型データベース４０の自律動作によるヒット／ミス判定（６）〜（１０）を以下に説明する。この自律動作により、ソースデータベースに新規に格納された人気コンテンツが自動的にキャッシュ型データベースに格納される。（６）〜（１０）の動作は、それぞれ、上述した（１）〜（５）と同様ある。
（６）ヒット／ミス判定部５０は、要求（新規）符号化方式のコンテンツ（又はライブ）がある（ヒットした）場合、後述する図７の符号化レートのヒット／ミス判定Ｔ２に遷移する。
（７）要求符号化方式のコンテンツ（又はライブ）が無く（ミスし）、且つ未格納ラインが有る場合、要求符号化方式のコンテンツ（又はライブ）を未格納ラインに追加する。
（８）要求符号化方式のコンテンツ（又はライブ）が無く（ミスし）、未格納ラインが無く、且つ低視聴率のコンテンツが有る場合、低視聴率のコンテンツを破棄して、要求符号化方式のコンテンツ（又はライブ）を破棄した低視聴率のコンテンツラインに追加する。
（９）要求符号化方式のコンテンツ（又はライブ）が無く（ミスし）、未格納ラインが無く、低視聴率のコンテンツが無く、且つ低視聴率の符号化レートが有る場合、低視聴率の符号化レートを破棄して、要求符号化方式のコンテンツ（又はライブ）を破棄した低視聴率の符号化レートラインに追加する。
（１０）要求符号化方式のコンテンツ（又はライブ）が無く（ミスし）、未格納ラインが無く、低視聴率のコンテンツが無く、且つ低視聴率の符号化レートが無い場合、新規コンテンツのエントリは失敗となる。
（７）〜（９）により、新規コンテンツが自律的にキャッシュ型データベースに格納されたことになる。
図７は、本発明のにおける要求符号化レートのヒット／ミス判定Ｔ２の例を示している。
この判定は冗長性をもたせている。すなわち、差分絶対値ｘ（現在配信しているキャッシュ型データベース４０に格納されている比較対象の符号化データの符号化レートと、要求データの符号化レートとの差分の絶対値ｘ）と、所定の閾値ｂ，ｃとの大小関係によって判定が異なる。
また、ネゴシエーション時とネットワーク監視（ＲＲタイプのＲＴＣＰパケットフィードバック）時とでは、判定動作が異なる。なお、同図に示されているステップ符号は、図４、図５のステップ符号に対応している。
〔１〕ネゴシエーション時における要求符号化レート等のヒット／ミス判定（１）〜（５）を以下に説明する。
（１）ヒット／ミス判定部５０は、差分絶対値ｘ≦閾値ｂである場合、要求符号化レートが存在する（ヒット）と判定し、要求符号化データに冗長を持ったヒット／ミス判定Ｔ３に遷移する。
（２）ヒット／ミス判定部５０は、閾値ｂ＜差分絶対値ｘである場合、要求符号化レートが存在しない（ミス）と判定し、タグラム４２のＭＲＵより未格納ラインを検索し未格納ラインが有る場合、要求データを未格納ラインに格納する。
（３）ヒット／ミス判定部５０は、上記の未格納ライン検索において、未格納ラインが存在しない（ミス）場合、要求符号化レートのヒット／ミス判定を強制ヒット判定し、次の要求符号化データのヒット／ミス判定Ｔ３へ遷移する。
〔３〕ネットワーク監視（ＲＲタイプのＲＴＣＰパケットフィードバック）時における要求符号化レートのヒット／ミス判定Ｔ２（４）〜（８）を以下に説明する。
（４）ヒット／ミス判定部５０は、差分絶対値ｘ≦閾値ｂである場合、要求符号化レートが存在する（みなしヒット）と判定し、要求符号化データのヒット／ミス判定Ｔ３に遷移する。
（５）ヒット／ミス判定部５０は、閾値ｂ＜差分絶対値ｘ≦閾値ｃである場合、要求符号化レートが存在しない（ミス）と判定し、比較対象符号化レートラインのデータを破棄した後、このラインに要求データを格納する。
（６）ヒット／ミス判定部５０は、閾値ｃ＜差分絶対値ｘである場合、要求符号化レートが存在しない（ミス）と判定し、タグラム４２のＭＲＵより未格納ラインを検索し未格納ラインが有り、且つ対象となるデータが存在する（ヒット）場合、要求データを未格納ラインに格納する。
（７）ヒット／ミス判定部５０は、上記の未格納ライン検索で未格納ラインが存在しない（ミス）場合、タグラム４２において、低視聴率の符号化レートラインが存在する（ヒット）場合、要求データを低視聴率の符号化レートラインに格納する。
（８）ヒット／ミス判定部５０は、上記の未格納ライン及び低視聴率の符号化レートラインが存在しない（ミス）場合、比較対象符号化レートのラインを破棄し、このラインに要求データを格納する。
なお、上記の（５）〜（８）は、使用するトランスコーダが有る場合の処理である。
また、符号化ＲＴＣＰパケット（ＲＲタイプ）フィードバックによるリアルタイムな符号化レート制御を行っているため、未使用トランスコーダ存在時における自律的な符号化レート制御（要求符号化レートのヒット／ミス判定Ｔ２）は基本的には不要である。
上記の要求符号化データのヒット／ミス判定Ｔ３に遷移した場合、ヒット／ミス判定部５０は、キャッシュ４３の検索においてヒット／ミス判定Ｔ３行い、要求データが存在する（ヒット）場合、ヒット判定し、要求データが存在しない（ミス）場合、要求データを対象インデックスに格納する。
上記のようにキャッシュ型データベース４０において、図２に示すようにタグラム４１のＭＲＵ及びタグラム４２のＭＲＵに、それぞれ、コンテンツ及び符号化方式単位並びに符号化レート単位の各ユーザの視聴開始／停止／変更時刻情報をキューイングすることにより、キャッシュ型データベースに格納されているデータに対する各ユーザの視聴開始／停止時刻、リアルタイムな視聴率を考慮したヒット／ミス判定を行うことができる。
また、上記のキャッシュ型データベース４０のヒット／ミス判定は、通常の判定契機［１］：或るユーザ端末（受信側）からの配信要求によるネゴシエーション時、通常の判定契機［２］：ＲＲタイプのＲＴＣＰパケットフィードバック時がある。さらに、ヒット／ミス判定は、判定契機［１］及び［２］以外に、未使用トランスコーダが存在する時を動作契機［３］とすることにより、ソースデータベースに新規格納され、かつキャッシュ型データベースに未格納である、人気コンテンツを事前に格納（キャッシュフィル）することができる。
また、ストリーミング技術においては、或る一つのコンテンツまたは、ライブ、符号化方式に対する、複数の符号化レートをサポートしている。
したがって、キャッシュ型データベース４０のヒット／ミス判定は、ユーザから配信要求に対して、要求コンテンツ又はライブ、符号化方式が対応するデータの検索（ヒット／ミス判定Ｔ１）を行い、次に要求符号化レートが対応するデータの検索（ヒット／ミス判定Ｔ２）を行い、最後に要求データの検索（ヒット／ミス判定Ｔ３）を行うといった３段階的な検索を行うことにより、判定の容易化／高速化が実現できるとともに、ヒット／ミス判定回路のハードウェア規模の大幅な削減が実現できる。
また、キャッシュ型データベース４０のヒット／ミス判定は、ユーザ（受信側）からの要求コンテンツ又はライブ、符号化方式、符号化レート、及び符号化データが存在しない（ミス）場合は、タグラム４１のＭＲＵ、タグラム４２のＭＲＵに格納されている視聴履歴を参照して、低視聴率のコンテンツ、符号化レートラインを破棄するため、不特定多数ユーザが要求する高視聴率のコンテンツ及び高視聴率の符号化レートのデータのみが格納され、効率的なキャッシュ運用を実現する。
また、キャッシュ型データベースのヒット／ミス判定は、ＲＲタイプのＲＴＣＰパケットによるフィードバック情報を基にしたネットワークの混雑度、ユーザ端末処理能力を考慮した最適な要求符号化レートに対する、現在使用されている符号化レートとの差分絶対値が、所定の閾値以下の場合は、冗長性をもたせたヒット／ミス判定を行うことにより、リアルタイムなネットワークの混雑度、ユーザ端末処理能力の急激な変化に追従しない。
また、所定の閾値以上の場合においても、キャッシュ型データベースに格納されているデータが、例えば全て高視聴率データの場合は、強制ヒット判定を行うことにより、他ユーザへの配信データに対して、影響を与えない。
上記の動作により、本発明のストリーム・サーバは、自律動作による自身の配信要求データ、及び他のユーザ端末へ配信データが実現できる。
図８、９は、本発明のストリーム・サーバ１００における階層化符号化方式例を示している。この階層符号化は、空間スケーラビリティ、時間スケーラビリティ、及びＳＮＲ（Ｓｉｇｎａｌ  ｔｏ  Ｎｏｉｓｅ  Ｒａｔｉｏ）スケーラビリティ等により階層化され、或る階層の符号化レートを変更する際に、符号化レート変更対象の階層及びこの階層の１つ上位の階層の符号化データのみ、新規符号化データを作成する。
図８は、低符号化レートを高符号化レートに変更する場合を示している。同図（１）において、各階層１，２，３，及び４の階層の符号化レートは、それぞれ、１Ｍｂｐｓ，５Ｍｂｐｓ、１０Ｍｂｐｓ、及び２０Ｍｂｐｓである。
同図（４）は、同図（１）に示した各階層１〜４の符号化レートが格納されているバンク９０を示しており、バンク９０＿１〜９０＿４には、それぞれ、符号化レート１Ｍｂｐｓ，５Ｍｂｐｓ，１０Ｍｂｐｓ，２０Ｍｂｐｓのデータが格納されている。
同図（２）、（５）において、階層２の符号化レートを５Ｍｂｐｓ（低符号化レート）から７Ｍｂｐｓ（高符号化レート）に変更する場合、新階層２新規符号化データ、及びこの新階層２をリファレンスとして伸長動作を行う新階層３（１０Ｍｂｐｓ）の新規符号化データを、それぞれバンク９０＿５，９０＿６に格納する。
同図（３）、（６）において、新階層３より伸長された復号フレームデータと現階層３により伸長された復号フレームデータの差分絶対値和が、或る閾値以下になった場合に、現階層２、３（バンク９０＿２，９０＿３）を破棄し、新階層２，３（バンク９０＿５，９０＿６）を現階層２，３とし、新しい階層構成に切り替える。
図９は、高符号化レートを低符号化レートに変更する場合を示している。同図（１）及び（４）は、それぞれ、図８（１）及び（４）と同様である。
図９（２）、（５）において、階層３の符号化レートを１０Ｍｂｐｓ（高符号化レート）から７Ｍｂｐｓ（低符号化レート）に変更する場合、新階層３（７Ｍｂｐｓ）、及びこの新階層３をリファレンスとして伸長動作を行う新階層４（２０Ｍｂｐｓ）の新規符号化データをバンク９０＿５，９０＿６に格納する。
同図（３）、（６）において、新階層４より伸長された復号フレームデータと現階層４により伸長された復号フレームデータの差分絶対値和が、或る閾値以下になった場合に、現階層３、４（バンク９０＿３，９０＿４）を破棄し、新階層３，４（バンク９０＿５，９０＿６）を現階層２，３とし、新しい階層構成に切り替える。
すなわち、上記階層符号化における、或る一つの階層の符号化レートを変更する場合に、この階層データをリファレンスデータとして使用する、以降の上位階層すべてのデータ変更を行うことなく、一つ上位の階層データのみの変更を行うことで、符号化レートを変更して新しい階層構成を構築することができる。
この符号化レート変更において、必要となるバンク数は、階層数＋２のみで実現でき、ハードウェア規模の削減が可能である。
以上説明したように、本発明のストリーム・サーバによれば、コンテンツ又はライブ、符号化方式、及び符号化レートに関して要求されたデータが該キャッシュ型データベースに格納されていないとき、ヒット／ミス判定部が、該キャッシュ型データベースに該要求されたデータが格納されるように該トランスコーダ及び該キャッシュ型データベースを連携して制御するように構成したので、不特定多数ユーザ端末に対して、それぞれ与えられた環境、すなわち、ネットワーク負荷、ユーザ端末の処理能力、又はストリーム・サーバの混雑度にリアルタイムに対応したコンテンツ配信を行うこと、また、コンテンツ配信とライブ配信の融合することを、少ないハードウエアで実現することが可能になる。
【図１】
2004040908.tif 000005
【図２】
2004040908.tif 000006
【図３】
2004040908.tif 000007
【図４】
2004040908.tif 000008
【図５】
2004040908.tif 000009
【図６】
2004040908.tif 000010
【図７】
2004040908.tif 000011
【図８】
2004040908.tif 000012
【図９】
2004040908.tif 000013
【図１０】
2004040908.tif 000014
【手続補正書】
【提出日】平成16年12月7日(2004.12.7)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】特許請求の範囲
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】１つ以上のトランスコーダと、
データを格納するキャッシュ型データベースと、
コンテンツ又はライブ、符号化方式、及び符号化レートに関して要求されたデータが該キャッシュ型データベースに格納されていないとき、該キャッシュ型データベースに該要求されたデータが格納されるように該トランスコーダ及び該キャッシュ型データベースを連携して制御するヒット/ミス判定部と、
を備えたことを特徴とするストリーム・サーバ。
【請求項２】請求項１において、
ユーザ端末との間で、呼制御、又は該データの配信の開始制御、一時停止制御、若しくは巻戻し制御に関するネゴシエーションを行い、その結果を該ヒット/ミス判定部に通知する呼制御/ネゴシエーション処理部をさらに有し、
該ヒット/ミス判定部が、該結果に基づき該トランスコーダ及び該キャッシュ型データベースに対する連携制御を行うことを特徴とするストリーム・サーバ。
【請求項３】請求項１において、
さらに、ユーザ端末との間のネットワーク負荷、コンテンツサーバの混雑度、又はユーザ端末の処理能力の少なくともいずれか１つを監視し、監視結果を該ヒット/ミス判定部に与えるネットワーク監視部を有し、
該ヒット/ミス判定部が該監視結果に基づき最適符号化レートを決定することを特徴としたストリーム・サーバ。
【請求項４】請求項１において、
該ヒット/ミス判定部が、該要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータが該キャッシュ型データベースに格納されているか否かの判定に、該符号化レートが許容範囲に入っている否かを判定することを特徴としたストリーム・サーバ。
【請求項５】請求項３において、
該キャッシュ型データベースは、該ネットワーク監視部から与えられた、該要求されたデータについて、その視聴開始時刻情報、停止時刻情報、及び変更時刻情報を格納し、
該ヒット/ミス判定部が、該情報に基づきヒット/ミス判定を行うことを特徴としたストリーム・サーバ。
【請求項６】請求項１において、
該トランスコーダが、空間スケーラビリティ、時間スケーラビリティ、又はSNRスケーラビリティによる階層符号化において、符号化レート変更対象階層及びその１つ上位の階層の符号化データのみ新規に作成し、該新規上位階層より伸長された復号データと現上位階層より伸長された復号データの差分絶対値の和が所定の閾値以下であるとき該新規作成された変更対象階層及び上位階層を現階層とすることを特徴とするストリーム・サーバ。
【国際調査報告】
2004040908.tif 000015
2004040908.tif 000016
2004040908.tif 000017
2004040908.tif 000018