(57)【特許請求の範囲】
【請求項１】
ネットワークを介してクライアント装置から特定の番組の配信を要求する配信要求を受信する受信部と、
受信された前記配信要求に係る前記特定の番組に対応する番組シナリオを取得する番組シナリオ取得部と、
前記番組シナリオに従って、複数の情報コンテンツを取得するコンテンツ取得部と、
前記番組シナリオに従って、取得された複数の前記情報コンテンツをもとに、映像シーンを生成する映像変換部と、
生成された前記映像シーンをストリーミング配信用にエンコーディングして、ストリームを生成するエンコード部と、
生成された前記ストリームを、前記ネットワークを介して前記クライアント装置へ配信するストリーミング配信部とを備えたことを特徴とする映像化配信装置。
【請求項２】
前記番組シナリオ取得部は、前記番組シナリオを、ネットワーク上から取得することを特徴とする請求項１に記載の映像化配信装置。
【請求項３】
複数の番組にそれぞれ対応する複数の番組シナリオを記憶する番組シナリオ記憶部を更に備え、
前記番組シナリオ取得部は、前記番組シナリオを、前記番組シナリオ記憶部から取得することを特徴とする請求項１に記載の映像化配信装置。
【請求項４】
前記コンテンツ取得部は、前記情報コンテンツを、ネットワーク上から取得することを特徴とする請求項１に記載の映像化配信装置。
【請求項５】
複数の情報コンテンツを記憶するコンテンツ記憶部を更に備え、
前記コンテンツ取得部は、前記情報コンテンツを、前記コンテンツ記憶部から取得することを特徴とする請求項１に記載の映像化配信装置。
【請求項６】
前記番組シナリオ取得部が取得した前記番組シナリオをキャッシュするためのキャッシュ部を更に備えたことを特徴とする請求項１ないし５のいずれか1項に記載の映像化配信装置。
【請求項７】
前記コンテンツ取得部が取得した前記情報コンテンツをキャッシュするためのキャッシュ部を更に備えたことを特徴とする請求項１ないし６のいずれか1項に記載の映像化配信装置。
【請求項８】
前記映像変換部が生成した前記映像シーンをキャッシュするためのキャッシュ部を更に備えたことを特徴とする請求項１ないし７のいずれか1項に記載の映像化配信装置。
【請求項９】
前記エンコード部が生成した前記ストリームをキャッシュするためのキャッシュ部を更に備えたことを特徴とする請求項１ないし８のいずれか1項に記載の映像化配信装置。
【請求項１０】
個々の番組を識別する番組識別情報と、当該番組に係る配信要求を次に受信したときに、前記番組シナリオ取得部、前記コンテンツ取得部、前記映像変換部、前記エンコード部又は前記ストリーミング配信部のうちのいずれから処理を開始するかを示す開始位置情報とを対応付けたエントリーを複数登録可能なテーブルを記憶するテーブル記憶部と、
前記受信部が前記配信要求を受信した場合に、該配信要求に係る前記特定の番組の番組識別情報をもとに、前記テーブル記憶部を参照し、該番組識別情報に対応するエントリーが存在するときは、該エントリーに含まれる前記開始位置情報に基づき、前記番組シナリオ取得部、前記コンテンツ取得部、前記映像変換部、前記エンコード部又は前記ストリーミング配信部のうちのいずれから処理を開始するかを決定し、該番組識別情報に対応するエントリーが存在しないときは、前記番組シナリオ取得部から処理を開始すると決定する制御部とを更に備えたことを特徴とする特徴とする請求項６ないし９のいずれか1項に記載の映像化配信装置。
【請求項１１】
前記番組シナリオの更新を検知するシナリオ更新検知部を更に備え、
前記番組シナリオの更新が検知された場合には、前記テーブル記憶部から、更新が検知された前記番組シナリオに係る番組の番組識別情報に対応するエントリーを削除するとともに、前記キャッシュ部から、更新が検知された前記番組シナリオに係るキャッシュデータをすべて削除することを特徴とする請求項１０に記載の映像化配信装置。
【請求項１２】
前記テーブル記憶部の各々の前記エントリーは、更に、当該番組識別情報の番組について、各キャッシュ部にキャッシュされているデータを識別するデータ識別情報を含み、
前記映像化配信装置は、前記キャッシュ部へのデータの保存、前記キャッシュ部からデータの取得及び前記テーブル記憶部の前記エントリーへの前記データ識別情報の登録を行うキャッシュ制御部を更に備えたことを特徴とする請求項１０または１１に記載の映像化配信装置。
【請求項１３】
前記情報コンテンツの更新を検知するコンテンツ更新検知部を更に備え、
前記情報コンテンツの更新が検知された場合には、前記テーブル記憶部に記憶されている前記エントリーから、更新が検知された前記情報コンテンツに対応するデータ識別情報を削除するとともに、前記キャッシュ部から、更新が検知された前記情報コンテンツに係るキャッシュデータ及び該情報コンテンツをもとに生成されたキャッシュデータをすべて削除することを特徴とする請求項１２に記載の映像化配信装置。
【請求項１４】
前記ストリーミング配信部により前記クライアント装置へ配信可能な前記ストリームを保存するためのアーカイブ部を更に備え、
特定の番組に係るストリームの内容に変更が発生する場合に、該特定の番組に係る変更前のストリームを、前記アーカイブ部に保存することを特徴とする請求項１ないし１３のいずれか1項に記載の映像化配信装置。
【請求項１５】
前記受信部が、前記特定の番組に係る変更前の内容の配信を要求する配信要求を受信した場合には、前記ストリーミング配信部が、前記アーカイブ部に保存されている前記特定の番組に係る変更前のストリームを配信することを特徴とする請求項１４に記載の映像化配信装置。
【請求項１６】
映像化配信装置の映像化配信方法であって、
前記映像化配信装置の備える受信部が、ネットワークを介してクライアント装置から特定の番組の配信を要求する配信要求を受信するステップと、
前記映像化配信装置の備える番組シナリオ取得部が、受信された前記配信要求に係る前記特定の番組に対応する番組シナリオを取得するステップと、
前記映像化配信装置の備えるコンテンツ取得部が、前記番組シナリオに従って、複数の情報コンテンツを取得するステップと、
前記映像化配信装置の備える映像変換部が、前記番組シナリオに従って、取得された複数の前記情報コンテンツをもとに、映像シーンを生成するステップと、
前記映像化配信装置の備えるエンコード部が、生成された前記映像シーンをストリーミング配信用にエンコーディングして、ストリームを生成するステップと、
前記映像化配信装置の備えるストリーミング配信部が、生成された前記ストリームを、前記ネットワークを介して前記クライアント装置へ配信するステップとを有することを特徴とする映像化配信方法。
【請求項１７】
映像化配信装置としてコンピュータを機能させるためのプログラムであって、
ネットワークを介してクライアント装置から特定の番組の配信を要求する配信要求を受信する受信部と、
受信された前記配信要求に係る前記特定の番組に対応する番組シナリオを取得する番組シナリオ取得部と、
前記番組シナリオに従って、複数の情報コンテンツを取得するコンテンツ取得部と、
前記番組シナリオに従って、取得された複数の前記情報コンテンツをもとに、映像シーンを生成する映像変換部と、
生成された前記映像シーンをストリーミング配信用にエンコーディングして、ストリームを生成するエンコード部と、
生成された前記ストリームを、前記ネットワークを介して前記クライアント装置へ配信するストリーミング配信部とをコンピュータに機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報を映像化してネットワーク配信する情報映像化配信装置、情報映像化配信方法及びプログラムに関する。
【背景技術】
【０００２】
テレビを鑑賞（或いは利用）する形態として、特定の番組を視聴する（或いは、凝視する）間だけテレビを付ける形態や、その際に何か他の作業を行いながらテレビを視聴する形態の他に、テレビを常時付けておいて、必要に応じて音声のみ聞いたり一瞥したり注視したりすることを繰り返したり、或いは、積極的に鑑賞していなくても環境映像／音楽として利用するような形態がある。テレビが常時付いている状態にする利用形態は、家庭、店舗、公共施設など種々の場所において良く行われている。
【０００３】
しかしながら、テレビ放送には、放送局が放送する情報しか受信・再生できないという限界がある。よって、テレビ放送を常時受信・再生するといっても、その内容については、高々、放送局の数だけしか選択肢がない。
【０００４】
これに対して、昨今、放送局が放送する情報以外に、多くの情報が取得できるようになっている。特に、一般の人が広範囲の情報に触れる機会がなかった従来の状況を、インターネットが大きく変え、現在では、全世界から普通の人が情報を発信できる世界が構築されようとしている。そこでは、政治経済などに始まり、趣味の世界、「先週行ったおいしい店」に至るまで、多種多様の情報が扱われ、加えて、一般の利用者自身が自らそれら多種多様な情報を整理し、まとめ、意見を述べ、その意見に対して別の人がさらに意見を述べる、といったことも可能になっている。プロでない一般の人が主役の情報流通の仕組みがインターネットという大きな情報基盤の上にできあがりつつあると言っても良い。
【０００５】
このようにインターネットにはテレビとは比較にならないほど多くの情報が流通しているが、その反面、テレビの場合のような受動的な情報取得形態（例えば、ソファーに寝そべってテレビを見るには、高々、スイッチを入れて、チャンネルを選択するだけで良い。）を取ることはできず、インターネットから情報を取得するためには、通常、例えば机に座ってキーボードから検索ワードを入力したりマウスでクリックしたりするといったように、ユーザが能動的に何らかの操作をしなければならない。「インターネットは情報を得るものであり、テレビは視聴するものである。」という言葉が、それらの差を端的に表していると言える。
【０００６】
しかし、インターネットにおいて所望の情報を取得して閲覧するためには、ユーザ自身が、まず、どのような情報を取得して閲覧したいかという考えを持ち、そして、その考えに基づいて入力操作等を行ったり、提示される多くの情報から所望するものを取捨選択したりするなどの、能動的な操作等が要求される。
【特許文献１】特開２００４−３４３６８３号公報
【特許文献２】特開２００７−０７４１５８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
従来、インターネットのブラウザ画面等の表示内容を変化させるためには、ユーザの能動的な操作が必要であり（インターネットのブラウザ画面等を単に動作させ続けても、高々、同一の情報が表示され続けるだけであり）、ユーザの能動的な操作なしに画面変化をさせることは困難であった。
【０００８】
本発明は、上記事情を考慮してなされたもので、ユーザによる能動的な操作なしに、情報を映像化（番組化）し、ネットワークを介して配信することを可能にする情報映像化配信装置、情報映像化配信方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明に係る映像化配信装置は、ネットワークを介してクライアント装置から特定の番組の配信を要求する配信要求を受信する受信部と、受信された前記配信要求に係る前記特定の番組に対応する番組シナリオを取得する番組シナリオ取得部と、前記番組シナリオに従って、複数の情報コンテンツを取得するコンテンツ取得部と、前記番組シナリオに従って、取得された複数の前記情報コンテンツをもとに、映像シーンを生成する映像変換部と、生成された前記映像シーンをストリーミング配信用にエンコーディングして、ストリームを生成するエンコード部と、生成された前記ストリームを、前記ネットワークを介して前記クライアント装置へ配信するストリーミング配信部とを備えたことを特徴とする。
【発明の効果】
【００１０】
本発明によれば、ユーザによる能動的な操作なしに、情報を映像化（番組化）し、ネットワークを介して配信することが可能になる。
【発明を実施するための最良の形態】
【００１１】
以下、図面を参照しながら本発明の実施形態について説明する。
【００１２】
（第１の実施形態）
図１に、本発明の一実施形態に係る番組配信システムの全体構成の一例を示す。図中、１は映像化配信装置、２はＡＶクライアント装置、３はネットワーク、４は番組一覧配信サーバである。
【００１３】
映像化配信装置１は、ＡＶクライアント装置２と、ネットワーク３により接続される。ネットワーク３は、例えばインターネットであるが、これに制限されるものではなく、他のネットワークでも良い。
【００１４】
映像化配信装置１は、詳しくは後述するが、ＡＶクライアント装置２からの配信要求に応じて情報の映像化や配信などの処理を行うメイン処理部１００が、ネットワーク３と接続されており、さらに、番組の識別情報である番組ＩＤに対応付けて当該番組のシナリオ１０００とを登録した番組ＩＤ・シナリオ対応データベース（ＤＢ）１０や、各種コンテンツ（図１では、テキストコンテンツ１００１，画像・動画コンテンツ１００２，ＢＧＭコンテンツ１００３，背景コンテンツ１００４）とストレッジ接続されている。
【００１５】
図１では、番組ＩＤ・シナリオ対応ＤＢ１０は、映像化配信装置１に含まれるとしているが、各番組シナリオは、外部から読み込まれたものであっても良いし、映像化配信装置１上で作成されたものであっても良い。また、番組ＩＤ・シナリオ対応ＤＢ１０は、映像化配信装置１に含まれるのに加えて、又、その代わりに、ネットワーク３上及び又はＬＡＮ（図示せず）上に（分散）配置されていても良い。例えば、シナリオ１０００を提供する１又は複数のシナリオサーバが存在しても良い。
【００１６】
また、図１では、各種コンテンツは、映像化配信装置１の記憶部に記憶されているとしているが、それらコンテンツは、外部から読み込まれたものであっても良いし、映像化配信装置１上で作成されたものであっても良い。また、各種コンテンツは、映像化配信装置１の記憶部に記憶されているのに加えて、又は、その代わりに、ネットワーク３上及び又はＬＡＮ（図示せず）上のサーバやホスト等に（分散）配置されていて、映像化配信装置１が、それらを取得しても良い。例えば、テキストコンテンツ１００１、画像・動画コンテンツ１００２、ＢＧＭコンテンツ１００３、背景コンテンツ１００４を提供する１又は複数のコンテンツサーバが存在しても良い。
【００１７】
番組一覧情報２０００を保持する番組一覧配信サーバ４は、ＡＶクライアント装置２と、ネットワーク３により接続される。また、番組一覧配信サーバ４は、映像配信装置１と、ネットワーク８により接続される。ネットワーク８は、ネットワーク３と同一のネットワークであっても良いし、ネットワーク３とは異なるネットワークであっても良い。その代わりに、番組一覧配信サーバ４は、映像化配信装置１と専用線で接続されても良いし、映像化配信装置１内に配置されていても良い。また、他のサーバと一体化されていても良い。
【００１８】
図２に、一例として、映像化配信装置１、ＡＶクライアント装置２、番組一覧配信サーバ４、シナリオ１０００を提供するシナリオサーバ５、各種コンテンツを提供するコンテンツサーバ６がすべてネットワーク３上に存在する場合の番組配信システムの構成例を示す。
【００１９】
なお、図１や図２では、各装置や各サーバは、１台ずつ示しているが、それぞれ、複数台存在して構わない。
【００２０】
また、映像化配信装置１、番組一覧配信サーバ４、シナリオサーバ５、コンテンツサーバ６の全部又は一部が一体化していても良い。
【００２１】
次に、図３を参照しながら、本実施形態の番組配信システムの基本的な処理手順について説明する。なお、図３は、映像化配信装置１の処理手順の一例である。
【００２２】
ＡＶクライアント装置２は、番組一覧配信サーバ４若しくは映像化配信装置１又は他のサーバより提供される番組一覧情報２０００を、ネットワーク３経由で取得し、該番組一覧情報２０００から、ユーザ所望の番組（例えば、ユーザにより指示された番組）を選択した後、該選択された番組に対応する番組ＩＤを含む配信要求を、映像化配信装置１に送信する。なお、番組ＩＤは、固有ＩＤ又はＵＲＩなどによる番組識別情報であり、番組一覧情報２０００より入手される。
【００２３】
映像化配信装置１のメイン処理部１００は、ＡＶクライアント装置２から、番組ＩＤを含む配信要求を受信すると、配信要求を解釈し（ステップＳ１）、該配信要求に含まれる番組ＩＤを抽出する。
【００２４】
次に、抽出された番組ＩＤをキーとして、当該映像化配信装置１内の番組ＩＤ・シナリオ対応ＤＢ１０を検索し、番組ＩＤ・シナリオ対応ＤＢ１０から、番組ＩＤに対応する番組シナリオ１０００を取得する（ステップＳ２）。なお、番組シナリオ１０００がネットワーク３上及び又はＬＡＮ（図示せず）上の１又は複数のシナリオサーバから映像化配信装置１に対して提供可能な形態（映像化配信装置１から検索・取得が可能な形態）で実現されている場合には、映像化配信装置１は、番組シナリオ１０００をシナリオサーバ３から検索・取得する。
【００２５】
次に、映像化配信装置１のメイン処理部１００は、取得した番組シナリオ１０００を解釈しながら、映像化に必要なコンテンツ要素（テキストコンテンツ１００１，画像・動画コンテンツ１００２，ＢＧＭコンテンツ１００３，背景コンテンツ１００４）を順次取り込んでいく（ステップＳ３）。前述のように、コンテンツ要素は、映像化配信装置１内にあらかじめ保持されていても良いが、ネットワーク３上及び又はＬＡＮ（図示せず）上の１又は複数のコンテンツサーバに配置され、ここから映像化配信装置１に対して提供可能な形態（映像化配信装置１から検索・取得が可能な形態）で実現されても良い。
【００２６】
各コンテンツ要素は、シーン毎に、番組シナリオ１０００によって記述される合成手順（例えば、画面レイアウト、表示タイミング、エフェクト等）に基づき映像変換され（ステップＳ４）、最終的にはストリーミング配信向けにエンコーディングされ（ステップＳ５）、その映像ストリームがＨＴＴＰやＲＴＰなどの配信用プロトコルを用いてＡＶクライアント装置２に配信される（ステップＳ６）。
【００２７】
一つの番組シナリオから生成される映像（又は、ストリーム）は、ＴＶ放送における「番組」と同義の概念を表すことになるが、複数の番組を時系列で組み合わせ、これを「チャンネル」と呼ぶ単位で扱うこともできる。番組一覧配信サーバ４にて扱う情報にチャンネル一覧情報を加え、ＡＶクライアント装置２において、このチャンネル一覧情報を取得した後に、自動的に放送番組を選択できる枠組みが提供されても良い。
【００２８】
次に、図４に、本実施形態の映像化配信装置１の全体構成の一例を示す。図４は、図１のメイン処理部１００の内部構成を示したものに相当する。なお、番組ＩＤ・シナリオ対応ＤＢ１０と各種コンテンツについては前述した通りである。
【００２９】
図４に示されるように、この映像化配信装置１（のメイン処理部１００）は、配信要求受信・解釈部４０、配信番組検索部３０、番組シナリオ取得部１０１、番組シナリオ解釈・コントロール部１０２、コンテンツ取得部１０３、映像変換部１０４、ストリーム生成部（エンコード部）１０５、ストリーミング配信部１０６、番組ＩＤ・キャッシュ対応テーブル２０、キャッシュ条件設定ファイル２００、番組シナリオに関するキャッシュ制御部１１／キャッシュ１１１、各種コンテンツに関するキャッシュ制御部１２／キャッシュ１１２、映像シーンに関するキャッシュ制御部１３／キャッシュ１１３、ストリーミング用動に関するキャッシュ制御部１４／キャッシュ１１４を備えている。
【００３０】
ここで、キャッシュについて説明する。
【００３１】
本実施形態の映像化配信装置１は、番組シナリオ１０００、各コンテンツ要素、映像化配信装置１内で映像化した動画のデータ、動画をエンコーディングした結果（ストリーム）のデータを選択的にキャッシュ可能なアーキテクチャを採用しており、これによって、自身の処理負荷を軽減することができる。
【００３２】
すなわち、各処理部は、キャッシュ制御部／キャッシュを搭載可能であり、キャッシュ条件設定ファイル２００に記述された指示に基づき自動的にキャッシュ処理が行われ、次回以降の配信要求処理時には、取得・映像化・エンコーディングの全部又は一部を省略した負荷低減型の映像化および配信処理を行うことができる。
【００３３】
キャッシュ適用条件は、管理者によって設定可能であり、例えば、下記に例示するような種々の内容を記述することができる。それぞれの実現手法については、後述する。  
（ａ）あらかじめ指定した番組に対して、初回再生（配信）時にサーバ上で生成ストリームをキャッシュし、次回再生時に再利用する。  
（ｂ）一定数以上の視聴者をカウントした番組は、優先してストリームを生成・キャッシュする。  
（ｃ）番組更新時期設定（毎日・毎週などの一定期間、番組シナリオ制作者やコンテンツ提供者が行う内容更新時期）に基づき、キャッシュをアーカイブ保存し、最新番組と過去番組を自動編成する。
【００３４】
なお、番組シナリオ用のキャッシュ制御部１１／キャッシュ１１１、コンテンツ用のキャッシュ制御部１２／キャッシュ１１２、映像データ用のキャッシュ制御部１３／キャッシュ１１３、ストリームデータ用のキャッシュ制御部１４／キャッシュ１１４は、全てが同時に搭載されている必要はなく、映像化配信装置１の処理負荷、利用効率を考慮して、いずれか一つ以上のキャッシュ制御部とキャッシュが搭載されていれば良い（４種類のキャッシュについて、それぞれ、任意に搭載するか否かを決めることが出来る）。
【００３５】
なお、すべてのキャッシュ制御部とキャッシュを搭載しない構成も可能であり、この場合には、番組ＩＤ・キャッシュ対応テーブル２０とキャッシュ条件設定ファイル２００は、不要となる。なお、この場合の映像化配信装置１の動作は、図３のようになる。
【００３６】
次に、上記４種類のキャッシュをすべて搭載する場合（すなわち、図４の構成の場合）を中心に本実施形態の映像化配信装置１の動作について説明する。
【００３７】
図５に、この場合の映像化配信装置１の処理手順の一例を示す。なお、ここでは、説明を簡単にするために、番組ＩＤ・シナリオ対応ＤＢ１０や各種コンテンツは、映像化配信装置１内に存在するものとして説明する。
【００３８】
映像化配信装置１の配信要求受信・解釈部４０は、ＡＶクライアント装置２からの配信要求パケットを受信すると、その内容を解釈し（ステップＳ１１）、番組ＩＤを抽出する。番組ＩＤは、番組シナリオを特定する識別子であり、固有ＩＤ又はＵＲＩなどによる識別情報となる。なお、配信要求パケット内に、番組ＩＤが複数のリストとなって構成されていても構わない。
【００３９】
次に、配信番組検索部３０は、配信要求受信・解釈部４０から呼び出され、抽出された上記番組ＩＤに対応する番組シナリオの検索を行う（ステップＳ１２）。ここで、キャッシュ１１１〜１１４のどれかに以前の配信時にキャッシュした該当データが存在すれば、それを利用することができるので、番組ＩＤ・シナリオＤＢ１０への問い合わせに先立ち、番組ＩＤ・キャッシュ対応テーブル２０への問い合わせを行う。
【００４０】
番組ＩＤ・キャッシュ対応テーブル２０に、上記番組ＩＤに対応するエントリーが存在しない場合は（ステップＳ１３）、番組シナリオ取得部１０１へ処理を移行する。
【００４１】
これに対して、番組ＩＤ・キャッシュ対応テーブル２０に、上記番組ＩＤに対応するエントリーが得られた場合は（ステップＳ１３）、そのエントリーに記載されている再開位置に応じて（ステップＳ１４，Ｓ１５）、ある特定の処理部（番組シナリオ取得部１０１、コンテンツ取得部１０３、映像変換部１０４、ストリーム生成部１０５、ストリーミング配信部１０６のいずれか）に制御を移行する。
【００４２】
図６に、番組ＩＤ・キャッシュ対応テーブル２０の構成例を示す。図６の例では、個々のエントリーは、番組ＩＤをキーとして、再開位置と、各キャッシュ１１１〜１１４ごとにそれぞれキャッシュされているデータを示す情報（例えば、ファイル名）とを含む。
【００４３】
番組シナリオ取得部１０１は、ステップＳ１３で番組ＩＤ・キャッシュ対応テーブル２０のエントリーが得られなかった場合、又は、ステップＳ１３でエントリーが得られ、ステップＳ１４でそのエントリーの再開位置に「番組シナリオ取得部１０１」が記載されていた場合に、配信番組検索部３０から呼び出され、番組ＩＤ・シナリオ対応ＤＢ１０に対して、必要な番組ＩＤに対応する番組シナリオを問い合わせ、取得する（ステップＳ１６）。
【００４４】
ここで、番組ＩＤ・シナリオ対応ＤＢ１０は、複数の番組シナリオを保持するデータベースである。番組ＩＤをキーとする問い合わせに対して、対応する番組シナリオを返却する。なお、ここでは、データベースの形態で記載しているが、通常のファイルシステム上にハッシュなどのインデックス表を用いた実装形態や、Ｗｅｂサーバでの実装形態であっても構わない。
【００４５】
ここで、本実施形態では、一つの番組につき、メイン用の番組シナリオ（図７参照）と、動作指示用の番組シナリオ（サブシナリオ）（図９参照）の二つのシナリオを用いる場合を例にとっているが、これに制限されるものではない。また、本実施形態では、番組シナリオを、ＸＭＬを使用して記述する場合を例にとっているが、これに制限されるものではない。
【００４６】
キャッシュ制御部１１、キャッシュ１１１が搭載された映像化配信装置１の場合は、上記の番組シナリオの番組ＩＤ・シナリオＤＢ１０への問い合わせに先立ち、番組シナリオ取得部１０１が番組ＩＤ・キャッシュ対応テーブル２０に以前の配信時にキャッシュした該当データが存在しないか問い合わせを行い、存在した場合には、番組ＩＤ・シナリオ対応ＤＢ１０への問い合わせ・取得処理を行わず、キャッシュ１１１に含まれる該当データを取得する。
【００４７】
例えば、ステップＳ１３で番組ＩＤ・キャッシュ対応テーブル２０のエントリーが得られなかった場合には、それら二種類の番組シナリオはいずれもキャッシュされていないことになるので（番組ＩＤ・キャッシュ対応テーブル２０に問い合わせを行っても、該当するデータが得られないので）、番組シナリオ取得部１０１は、それら二種類の番組シナリオを番組ＩＤ・シナリオＤＢ１０から取得する（ステップＳ１６）。
【００４８】
また、例えば、ステップＳ１３でエントリーが得られ、ステップＳ１４でそのエントリーの再開位置に「番組シナリオ取得部１０１」が記載されていた場合には、キャッシュ１１１には、二種類の番組シナリオのうちの一方がキャッシュされていないことになるので、番組シナリオ取得部１０１は、番組ＩＤ・シナリオＤＢ１０への問い合わせに先立ち、番組ＩＤ・キャッシュ対応テーブル２０に問い合わせを行って、それら二種類の番組シナリオのうちでキャッシュされているものをキャッシュ１１１から取得するとともに、キャッシュされていないものを番組ＩＤ・シナリオＤＢ１０に問い合わせて取得する（ステップＳ１６）。
【００４９】
他方、例えば、ステップＳ１３でエントリーが得られ、ステップＳ１４でそのエントリーの再開位置に「コンテンツ取得部１０３」が記載されていた場合には、キャッシュ１１１には、二種類の番組シナリオがいずれもキャッシュされていることになるので、番組シナリオ取得部１０１による番組シナリオの取得処理は省かれ、キャッシュ１１１にキャッシュされている二種類の番組シナリオが利用される。
【００５０】
なお、キャッシュ制御部１１／キャッシュ１１１が搭載されない映像化配信装置１の場合は、番組シナリオが不要なとき（例えば再開位置に「ストリーミング配信部１０６」が記載されているとき）でない限り、常に、番組シナリオ取得部１０１が番組シナリオの取得処理を行うことになる。
【００５１】
さて、番組シナリオ取得部１０１が番組シナリオを取得した場合には、番組シナリオ取得部１０１は、キャッシュ条件設定ファイル２００の内容に基づき、取得した番組シナリオのキャッシュが必要な場合は、取得した番組シナリオを、キャッシュ制御部１１に渡し、キャッシュ１１１に保存するよう指示する（ステップＳ１６）。
【００５２】
ここで、キャッシュ条件設定ファイル２００は、管理者により各番組ごとに設定されるキャッシュの適用条件を記したものである。例えば、あらかじめ選定した番組シナリオのみ一定期間（一日、一週間、一か月など）キャッシュしたり、一定の配信カウントが一定の期間内（一日以内など）に確認された場合にキャッシュしたり、といった記述が、各番組ごとに記載されているものとする。更に、例えば、キャッシュ１１１〜キャッシュ１１４のいずれを使用するか、使用する各キャッシュに、どのデータをキャッシュするかしないか、「再開位置」を番組シナリオ取得部１０１、コンテンツ取得部１０３、映像変換部１０４、ストリーム生成部１０５、ストリーミング配信部１０６のいずれにするかについて、具体的な指示又は具体的な指示を特定可能なルールなどが、各番組ごとに記載されているものとする。
【００５３】
キャッシュ制御部１１は、番組シナリオ取得部１０１から指示があった場合には、キャッシュ１１１に番組シナリオを保存する（ステップＳ１６）。
【００５４】
このとき、キャッシュ１１１に当該番組に対する二種類の番組シナリオが全てキャッシュされた状態になる場合には、番組ＩＤ・キャッシュ対応テーブル２０に、番組ＩＤとして当該番組の「番組ＩＤ」を、次回の同一番組シナリオに対する映像化配信装置１の再開位置として「コンテンツ取得部１０３」を、キャッシュ１１１にキャッシュされているデータを示す情報として例えば各番組シナリオの「ファイル名」をそれぞれ記載したエントリーを登録する。
【００５５】
また、キャッシュ１１１に当該番組に対する二種類の番組シナリオの一方がキャッシュされない状態になる場合には、番組ＩＤ・キャッシュ対応テーブル２０に、番組ＩＤとして当該番組の「番組ＩＤ」を、次回の同一番組シナリオに対する映像化配信装置１の再開位置として「番組シナリオ取得部１０１」を、キャッシュ１１１にキャッシュされているデータを示す情報として例えば番組シナリオの「ファイル名」をそれぞれ記載したエントリーを登録する。
【００５６】
キャッシュされる形式は、番組シナリオそのものの形式の他に、ＤＯＭ形式などの内部処理形式に一度展開されたものであっても良い。
【００５７】
図６の番組ＩＤ・キャッシュ対応テーブル２０の例では、番組ＩＤが“１００１３”の場合、映像化処理の再開位置を「コンテンツ取得部１０３」から行うことが明示されている。この場合、番組シナリオはすでにキャッシュされているので、２回目以降のＡＶクライアント装置２からの配信要求に対しては、番組シナリオ取得部１０１の処理は省略でき、コンテンツ取得部１０３から処理を再開できる。なお、この場合の処理の再開手順は、次の通りとなる。まず、配信番組検索部３０から番組ＩＤ・キャッシュ対応テーブル２０への問い合わせを行った後、対応するエントリーが得られた場合は、配信番組検索部３０が再開位置として「コンテンツ取得部１０３」を番組シナリオ解釈・コントロール部１０２に伝達し、以降の処理を継続する。
【００５８】
なお、ステップＳ１６で番組シナリオが取得できなかった場合には、例えば、適切なエラーメッセージを作成し、ＡＶクライアント装置２へ返却すると好ましい。
【００５９】
さて、ステップＳ１６で番組シナリオ取得部１０１が番組ＩＤに対応する番組シナリオを取得した場合、又は、ステップＳ１３でエントリーが得られ、ステップＳ１４，Ｓ１５でそのエントリーの再開位置に、「コンテンツ取得部１０３」「映像変換部１０４」「ストリーム生成部１０５」「ストリーミング配信部１０６」のいずれかが記載されていた場合には、番組シナリオ解釈・コントロール部１０２に処理を移行する。
【００６０】
番組シナリオの解釈・コントロールは、以下のように行われる。
【００６１】
上記の場合のうち、エントリーの再開位置に「ストリーミング配信部１０６」が記載されていた場合以外の場合には、番組シナリオ解釈・コントロール部１０２は、対応する番組シナリオに基づき、内容の解釈を行い、番組ストリーム生成・配信に必要な各処理（コンテンツ取得部１０３、映像変換部１０４、ストリーム生成部１０５、ストリーム配信部１０６の全部又は一部）への指示、制御を行う（ステップＳ１７〜Ｓ２０）。各処理部への指示、制御は、キャッシュ条件設定ファイル２００の内容を考慮して行われる。
【００６２】
これに対して、エントリーの再開位置に「ストリーミング配信部１０６」が記載されていた場合には、ストリーム配信部１０６への指示、制御のみ行われる（ステップＳ２０）。
【００６３】
コンテンツ取得部１０３は、番組シナリオ解釈・コントロール部１０２から番組シナリオの内容に応じて順次呼び出され、映像シーンの合成に必要な各コンテンツ要素を取得する（ステップＳ１７）。
【００６４】
テキストコンテンツ１００１、画像・動画コンテンツ１００２、ＢＧＭコンテンツ１００３、背景コンテンツ１００４は、映像シーンの合成に使用される素材となる。なお、各コンテンツ要素がＷｅｂサーバ上に配置している場合は、これらコンテンツ要素の取得は、ＨＴＴＰ通信により取得するが、各コンテンツは、ＲＳＳなど、一般的なWeb APIが提供されている場合は、これを利用できる。Web APIが提供されていない場合は、スクレイピングと呼ばれる技法により、任意のＨＴＭＬ記述から必要な要素を自動的に抽出することで実現することができる。
【００６５】
ここで、図７に、メイン用の番組シナリオの記述例（news_main.xml）を示す。
【００６６】
図７の例では、まず、program要素があり、「番組シナリオ（メイン用）」のタイトルを「ニュース」とし、規格のバージョンを「０．１」と宣言している。program要素の中には、plugins要素があり、その中にplugin要素が羅列してある。このplugin要素が、変換を示す。この例では、一つ目の変換が「Subscription RSS」、二つ目の変換が「Filter_removeTag」、三つ目の変換が「Filter_ToSpeak」、四つ目の変換が「Presentation_Array_Scene」であることが分かる。plugin要素は、様々な設定を、子のoption要素と、そのid属性およびvalue属性で指定する。
【００６７】
上記内容に基づき、番組シナリオ解釈・コントロール部１０２は、コンテンツ取得部１０３に以下のような処理を行うよう、指示を行う。
【００６８】
最初の変換では、option要素のｉｄ＝“url”がvalue属性で示す値（ＵＲＬ先）から情報を取得し、ＲＳＳとして構造を読み取り、取得したＲＳＳの各要素をexample_arrayという配列に格納することを示している。
【００６９】
ここで、図８に、コンテンツ取得部１０３が、テキストコンテンツ１００１をＲＳＳによって取得し、配列変数example_arrayに格納するための変換処理について示す。この例では、コンテンツ取得部１０３が取得したＲＳＳから、title：「金融市場への資金供給」、description：「官房長官は１０日の閣議後…」を一つの組として抽出し、title：「概算要求基準を閣議了解」、description：「政府は１０日の閣議で、一般…」を別の組として抽出している。
【００７０】
なお、ここでは、取得したコンテンツを保持するデータ構造としてハッシュテーブルを用いるものと想定しているが、構成要素の識別子とその内容が関連付けられ、かつ、そのまとまりを、順序関係を考慮して保持するデータ構造であれば、他の実装でも構わない。
【００７１】
図７の例では、Subscription RSSの変換を行った後に、Filter removeTagの変換を行う。この変換は、ＨＴＭＬタグなど余計な要素を取り除く変換である。入力値は上記のexample_array配列変数であり、出力もexample_array配列変数に格納する。入力として変数を参照する場合は、“＄”を先頭に追記する記法としている。
【００７２】
不要タグを取り除いた後は、Filter_ToSpeakの変換を行う。この変換は、タグが取り除かれた後の情報を音声合成する変換である。ｗａｖファイル形式にて変換後、example_arrayの追加要素（cache1.wav,cache2.wav）として保存される。
【００７３】
最後のpluginにてPresentation_Array_Sceneの変換を行う。この変換は、上記３つの変換により生成されたexample_array配列要素を入力として、動作指示用の番組シナリオ（図９参照）に基づく処理への接続を行う。
【００７４】
ここで、各pluginは、映像化配信装置１内のコンテンツ取得部１０３および映像変換部１０４に組み込まれているモジュールとしているが、必要に応じて機能拡張することができ、新たなpluginを導入しても良い。
【００７５】
次に、図９に、動作指示用の番組シナリオ（サブシナリオ）の記述例（news_gmg.xml）を示す。
【００７６】
図９の例では、まず、ｇｍｇ要素があり、「番組シナリオ（動作指示用）」のタイトルを「ニュース」とし、規格のバージョンを「０．１」と宣言している。gmg要素の中には、動作指示用の各種要素がある。Image要素は、画像のＵＲＬから指定の画像を取得し、指定した座標位置、サイズにて描写することを規定している。ｉｄがbgimageの画像では、ＵＲＬを相対アドレス表記としているが、ｉｄがphotoの画像のように、絶対アドレス表記とすることも可能である。コンテンツ取得部１０３は、ＵＲＬ先より画像ファイルを、ＨＴＴＰなど通信プロトコルを用いて入手する。次のｉｄがtitleのText要素では、テキストの内容として、上記のexample_array配列要素から得られるtitle変数の値を指定の座標・サイズにて描写することを規定している。同様に、ｉｄがdescのText要素では、上記のexample_array配列要素から得られるdescription変数の値を指定の座標・サイズにて描写することを規定している。次に、Ｂｏｘ要素では、座標位置、サイズに基づく四角形の図形を描写することを規定している。Ｂｏｘ要素を除く取得すべきすべての要素を番組シナリオ解釈・コントロール部１０２がコンテンツ取得部１０３に適切に取得するよう指示する。
【００７７】
コンテンツ取得部１０３は、指示された内容に基づき、テキストコンテンツ１００１、画像・動画コンテンツ１００２、ＢＧＭコンテンツ１００３、背景コンテンツ１００４から必要なコンテンツを取得するが、キャッシュ制御部１２／キャッシュ１１２が搭載された映像化配信装置１の場合は、コンテンツ取得部１０３は、上記各種コンテンツを取得することに先立ち、番組ＩＤ・キャッシュ対応テーブル２０に以前の配信時にキャッシュした該当データが存在しないか問い合わせを行い、存在した場合には、キャッシュ１１２に含まれる該当データを取得する（ステップＳ１７）。
【００７８】
次に、図６の番組ＩＤ・キャッシュ対応テーブル２０の例では、番組ＩＤが“１００１４”の場合、映像化処理の再開位置を「コンテンツ取得部１０３」から行うことが明示されている。
【００７９】
この場合、映像化に必要な各種コンテンツのいくつかはすでにキャッシュされているので（番組シナリオもキャッシュされていてもかまわない）、２回目以降のＡＶクライアント装置２からの配信要求に対しては、キャッシュされているコンテンツに関しては、コンテンツ取得部１０１の処理を省略できる。ただし、番組シナリオにてテキストコンテンツを必要とする場合、このエントリーではキャッシュされていない。キャッシュされていないコンテンツについては、コンテンツ取得部１０３が番組シナリオの内容に基づき取得処理を行う。
【００８０】
キャッシュが存在しない場合、コンテンツ取得部１０３は、キャッシュ条件設定ファイル２００の内容に基づき、取得したコンテンツのキャッシュが必要な場合は、取得した各種コンテンツを、キャッシュ制御部１２に渡し、キャッシュ１１２に保存するよう指示する（ステップＳ１７）。
【００８１】
図６の例において、番組ＩＤが“１００１４”の場合、キャッシュ条件設定ファイル２００の内容に基づき、ＢＧＭコンテンツ、背景コンテンツがキャッシュされるよう明記されている。
【００８２】
各シーンに相当するコンテンツファイルの生成単位、名前の生成規則は任意に規定することができる。例えば、ｉｄがつけられるコンテンツ要素単位に、順次下記のようなファイル名にて生成していけば良い。  
（番組ＩＤ）＋（シーンＩＤ）＋（コンテンツ要素毎のｉｄ）．拡張子
拡張子は、Image要素やMovie要素（動画要素）、Music要素（BGM要素）に対しては、ｕｒｌで記載されるファイル名の拡張子を、Text要素に対してはｔｘｔとすることができる。シーンＩＤについては、後述する。
【００８３】
具体的な処理の再開手順は、前述の番組シナリオのキャッシュ動作とほぼ同様となる。
【００８４】
コンテンツの取得が完了すると、これらを組み合わせた映像化処理（映像シーンへの合成・変換処理）を映像変換部１０４にて行う（ステップＳ１８）。
【００８５】
番組シナリオ解釈・コントロール部１０２は、映像変換部１０４に対して、例えば図９に記載されたような番組シナリオに基づき各コンテンツの合成を行うよう、指示を行う。背景イメージ（ｉｄ＝“bgimage”）と写真イメージ（ｉｄ＝“photo”）は、指定された座標・サイズにて表示を開始し、タイトルテキスト（ｉｄ＝“title”）と記事内容（ｉｄ＝“desc”）は、それぞれ左方向からのスライドイン効果を０．５秒間、画面上部からのフェードイン効果を０．５秒間行い、表示を開始し、四角形を指定座標・サイズにて同一画面上に配置・描画していく。Sleep指定により上記表示・描画を５秒間まで継続する。これらをシーンごとに生成していく。この例では、example_array配列要素にふたつ以上のtitle, descriptionの組が格納されており、ひとつの組に対してひとつのシーンが生成されるとしている。すなわち、最初の5秒表示されるシーンの後、example_array配列要素の次の組が次のシーンとなって5秒間表示され、example_array配列要素内の組が消費されるまで新たなシーンの生成を継続するものとしている。個々のシーンの単位（区切り）および生成方法は、任意のタイミング指定のもと任意のシーン記述形式によりシステム内で規定しても良い。
【００８６】
キャッシュ制御部１３／キャッシュ１１３が搭載された映像化配信装置１の場合は、映像変換部１０４は、上記のシーン生成処理に先立ち、番組ＩＤ・キャッシュ対応テーブル２０に以前の配信時にキャッシュした該当データが存在しないか問い合わせを行い、存在した場合には、キャッシュ１１３に含まれる該当データを取得する（ステップＳ１８）。
【００８７】
図６の番組ＩＤ・キャッシュ対応テーブル２０の例では、番組ＩＤが“１００１４”の場合、映像化処理の再開位置を「コンテンツ取得部１０３」から行うことが明示されている。前述の説明にて、２回目以降のＡＶクライアント装置２からの配信要求に対しては、キャッシュされているコンテンツ（10014s2bgm.mp3,10014s2bgimg.jpg）に関しては、コンテンツ取得部１０１の処理を省略し、キャッシュ１１２から取得するとし、キャッシュされていないコンテンツ（テキストコンテンツなど）を取得し、映像変換部１０４へ渡される。キャッシュ１１３では、シーン１、シーン３に相当する映像ファイル（10014s1.avi,10014s3.avi）が既にキャッシュされている。映像変換部１０４は、キャッシュされている映像ファイルはそのまま使用し、キャッシュされていないシーン２に相当する映像ファイルは、コンテンツ取得部１０３から渡される各種コンテンツを番組シナリオ（動画指示用）に基づき合成することで生成される。
【００８８】
次に、図１０に、生成される映像シーンの一例を示す。
【００８９】
各シーンに相当する映像ファイルの生成単位（長さ）、生成タイミング、名前の生成規則は任意に規定することができる。例えば、Sleep要素が出現するまでの単位とし、Sleep要素のdur期間が経過したタイミングでひとつのシーンを順次下記のようなファイル名にて生成していけば良い。  
（番組ＩＤ）＋（シーンＩＤ）．ａｖｉ
キャッシュが存在しない場合、映像変換部１０４は、キャッシュ条件設定ファイル２００の内容に基づき、生成した映像シーンのキャッシュが必要な場合は、生成した各種映像シーンを、キャッシュ制御部１３に渡し、キャッシュ１１３に保存するよう指示する（ステップＳ１８）。図６の例において、番組ＩＤが“１００１４”の場合、キャッシュ条件設定ファイル２００の内容に基づき、シーン１、シーン３に相当する映像ファイル（10014s1.avi,10014s3.avi）がキャッシュされるよう明記されている。
【００９０】
映像変換部１０４による映像シーンの生成が完了すると、これらを順次ストリーム配信用にエンコーディングする処理を、ストリーム生成部１０５にて行う（ステップＳ１９）。番組シナリオ解釈・コントロール部１０２からの指示に基づき、ストリーム生成部１０５は、映像シーンを順次エンコーディング処理を行い、ストリーム配信部１０６へ渡していく。エンコーディング処理は、H.264/MPEG-4 AVCやFlashムービー、Windows（登録商標）Mediaなどのストリーミングのフォーマットに変換することで行う。
【００９１】
キャッシュ制御部１４／キャッシュ１１４が搭載された映像化配信装置１の場合は、ストリーム生成部１０５は、上記のストリーム生成処理に先立ち、番組ＩＤ・キャッシュ対応テーブル２０に以前の配信時にキャッシュした該当データが存在しないか問い合わせを行い、存在した場合には、キャッシュ１１４に含まれる該当データを取得する。
【００９２】
ストリームファイル名の生成規則は、任意に規定することができる。例えば、番組ＩＤを用いて、順次下記のようなファイル名にて生成していけば良い。  
（番組ＩＤ）．ｍｐ４
キャッシュが存在しない場合、ストリーム生成部１０５は、キャッシュ条件設定ファイル２００の内容に基づき、エンコードした後、ストリームのキャッシュが必要な場合は、これをキャッシュ制御部１３に対して、キャッシュ１１３に保存するよう指示する（ステップＳ１９）。図６において番組ＩＤが“１００１０”の場合、キャッシュ条件設定ファイル２００の内容に基づき、ストリームファイル（10010.mp4）がキャッシュされるよう明記されている。
【００９３】
変換されたストリーミングは、ストリーミング配信部１０６により、ＨＴＴＰやＲＴＰなどのトランスポートプロトコルを使用して、配信要求の送信元であるＡＶクライアント装置２へストリーミング配信される（ステップＳ２０）。
【００９４】
なお、ステップＳ１３でエントリーが得られ、ステップＳ１４，Ｓ１５でそのエントリーの再開位置に「ストリーミング配信部１０６」が記載されていた場合には、ストリーム配信部１０６は、キャッシュ１１４に含まれる該当データを取得して、これをストリーミング配信する（ステップＳ２０）。
【００９５】
図６の番組ＩＤ・キャッシュ対応テーブル２０の例では、番組ＩＤが“１００１０”の場合、映像化処理の再開位置を「ストリーム配信部１０６」から行うことが明示されている。２回目以降のＡＶクライアント装置２からの配信要求に対しては、番組ＩＤ・キャッシュ対応テーブル２０の街頭エントリーを照会した後、ストリーム配信部１０６へ処理が移行するよう、番組シナリオ解釈・コントロール部１０２に伝達し、既にキャッシュされたストリームファイル（10010.mp4）をストリーミング配信部１０６へ渡して、ユーザ所望のストリーミングを配信することになる。
【００９６】
なお、上記説明では、映像変換部１０４にてシーンごとの映像を作成し、その後、ストリーム生成部１０５にてストリーミング用フォーマットにてエンコーディングするとしているが、ストリーム生成部１０５のエンコーディング処理を、映像変換部１０４内部で映像作成をしながら、行っても良い。
【００９７】
また、キャッシュ制御部とキャッシュは、番組シナリオ取得部１０１、コンテンツ取得部１０３、映像変換部１０４、ストリーム生成部１０５、の各々に独立して接続される形態としているが、すべての処理部（１０１，１０３，１０４，１０５）に共通した同一のキャッシュ制御部とキャッシュを接続する形態で実現しても良い。
【００９８】
ストリーム生成部１０５／キャッシュ制御部１４／キャッシュ１１４は、エンコーダ専用チップを搭載したハードウェアにて独立して動作しても良い。この場合、キャッシュ制御部１３、キャッシュ１１３も前記ハードウェア上に搭載して稼働させることも考えられる。
【００９９】
以上説明したように、本実施形態によれば、インターネット等のネットワーク上のサーバ若しくはホスト又は自装置内から取得可能なコンテンツ情報（テキスト、ＢＧＭ、背景、画像・動画）を組み合わせ、映像化（番組化）し、ＡＶクライアント装置へストリーミング配信することが可能になる。その際、扱う番組数やクライアント数の増大に伴う処理負荷を動的に軽減可能な形態で実現することができる。
【０１００】
また、例えば、サーバ・クライアントモデルにおいて、クライアント数が増大し、また、扱う番組数が大量となった場合でも、情報の映像化処理・配信処理を動的に負荷軽減可能な形態で実現することができる。
【０１０１】
また、例えば、映像化された情報は、ＩＰＴＶやＶｏＤのようなストリーミング配信やダウンロード配信の形態にて配信され、ＰＣ、ＳＴＢ、ＴＶ、各種ビデオレコーダなどのＡＶクライアント装置での受信処理と同様の手順で行われることで、受信器開発のコスト削減が期待できる。
【０１０２】
（第２の実施形態）
第１の実施形態では、映像化配信装置において、キャッシュ条件設定ファイル２００の設定内容に基づき、各処理段階にてキャッシュ制御が行われるが、キャッシュされた内容が常に保持されたままであると、番組シナリオや各種コンテンツの更新が行われた場合、キャッシュの更新が出来ず、コンテンツ映像の刷新ができない。第２の実施形態は、番組シナリオ、各種コンテンツの更新を速やかに検知し、これをキャッシュ制御にフィードバックする仕組みを提供するものである。
【０１０３】
以下、本実施形態について、第１の実施形態と相違する点を中心に説明する。
【０１０４】
図１１に、本実施形態の映像化配信装置１の全体構成の一例を示す。本実施形態の映像化配信装置１は、図４の映像化配信装置１の構成（ただし、少なくとも一組のキャッシュ制御部／キャッシュが搭載されているもの）に、シナリオ更新検知・通知部２００１と、各種コンテンツ更新検知・通知部２００２とを追加したものである。なお、図１１は、映像化配信装置１の構成のうち、シナリオ更新検知・通知部２００１と各種コンテンツ更新検知・通知部２００２の動作に関わる部分のみを示している。
【０１０５】
シナリオ更新検知・通知部２００１は、番組シナリオの内容が更新されたかどうかを検知する機能と、更新を検知した場合にこれを番組ＩＤ・キャッシュ対応テーブル２０へ通知する機能を有する。各種コンテンツ更新検知・通知部２００２は、各種コンテンツの内容が更新されたかどうかを検知する機能と、更新を検知した場合にこれを番組ＩＤ・キャッシュ対応テーブル２０へ通知する機能を有する。
【０１０６】
更新の検知は、例えば、登録・保存済みの番組シナリオや各種コンテンツに対する削除や、更新した内容にて再度登録・保存を行うＡＰＩを呼び出して処理を完了した際に自動的に検知されるようＡＰＩにフックを入れておく方法や、更新時に明示的にシナリオ更新検知・通知部２００１へ通知する方法の他に、定期的に番組シナリオや各種コンテンツとなるファイルを順次スキャンし、以前保存しておいたタイムスタンプ情報との差異がないか確認することで更新の有無を調査する方法など、種々の方法がある。
【０１０７】
図１２に、本実施形態の更新処理の手順例を示す。
【０１０８】
シナリオ更新検知・通知部２００１が番組シナリオの更新を検知した場合は（ステップＳ４１）、番組ＩＤ・キャッシュ対応テーブル２０に対して、該当番組ＩＤに関するエントリー（番組ＩＤ、再開位置、キャッシュ１１１、キャッシュ１１２、キャッシュ１１３、キャッシュ１１４）を削除するよう要請する（ステップＳ４２）。
【０１０９】
番組ＩＤ・キャッシュ対応テーブル２０は、該当エントリーを削除する際、対応するキャッシュ（番組シナリオに関するキャッシュ、各種コンテンツに関するキャッシュ、映像シーンに関するキャッシュ、ストリーミング用動画に関するキャッシュ）を保持する可能性のあるキャッシュ１１１，１１２，１１３，１１４を管理するキャッシュ制御部１１，１２，１３，１４に対して、該当キャッシュファイルの削除を要請する。各キャッシュ制御部がこの削除要求に基づき、対応するキャッシュファイルを削除することで、処理を完了する。
【０１１０】
各種コンテンツ更新検知・通知部２００２がコンテンツの更新を検知した場合は（ステップＳ４３）、番組ＩＤ・キャッシュ対応テーブル２０に対して、該当コンテンツに関するキャッシュ情報（キャッシュ１１２内の該当アイテム）を削除するよう要請する（ステップＳ４４）。
【０１１１】
番組ＩＤ・キャッシュ対応テーブル２０は、該当キャッシュ情報を削除する際、キャッシュ１１２を管理するキャッシュ制御部１２に対して、該当キャッシュファイルの削除を要請する。同エントリーにて、キャッシュ１１３内にキャッシュファイルが存在している場合には、更新コンテンツを使用する映像シーンのキャッシュファイルのみ削除するよう、キャッシュ制御部１３に対して、該当キャッシュファイルの削除を要請する。キャッシュ１１４内にてキャッシュファイルが存在する場合には、このファイルを削除するよう、キャッシュ制御部１４に対して、該当キャッシュファイルの削除を要請する。
【０１１２】
各キャッシュ制御部がこれらの削除要求に基づき、対応するキャッシュファイルを削除した後、再開位置が「映像変換部１０４」又は「ストリーム生成部１０５」の場合には、これを「コンテンツ取得部１０３」に変更することで、処理を完了する（更新されたコンテンツを用いて新たにキャッシュが作成し直された後に、再開位置を「映像変換部１０４」又は「ストリーム生成部１０５」に戻して構わない）。なお、再開位置が「番組シナリオ取得部１０１」又は「コンテンツ取得部１０３」の場合には、再開位置を変更しなくて構わない。
【０１１３】
なお、再開位置が「ストリーミング配信部１０６」の場合において、番組シナリオがキャッシュされるときは、再開位置を「コンテンツ取得部１０３」に変更し、番組シナリオがキャッシュされないときは、再開位置を「番組シナリオ取得部１０１」に変更しても良い（更新されたコンテンツを用いて新たにキャッシュが作成し直された後に、再開位置を「ストリーミング配信部１０６」に戻して構わない）。また、再開位置が「ストリーミング配信部１０６」の場合においては、番組シナリオの更新が検知された場合と同様に、該当するエントリーとキャッシュファイルを削除する方法も可能である。
【０１１４】
（第３の実施形態）
これまでの実施形態では、映像化配信装置において、番組シナリオや各種コンテンツの更新に伴い、同一ＩＤの番組シナリオであっても、番組内容の異なる映像を作成することができるようになっている。常に最新のコンテンツ映像を視聴することが可能となっているが、過去のコンテンツ映像も視聴したいという要求にはこのままでは対応できない。第３の実施形態は、アーカイブの概念を導入し、履歴管理をすることで、過去の番組視聴を可能にする装置を提供するものである。
【０１１５】
以下、本実施形態について、第１の実施形態と相違する点を中心に説明する。
【０１１６】
図１３に、本実施形態の映像化配信装置１の全体構成の一例を示す。本実施形態の映像化配信装置１は、図４の映像化配信装置１の構成（ただし、少なくともキャッシュ制御部１４／キャッシュ１１４が搭載されているもの）に、アーカイブ３００１を追加したものである。なお、図１３は、映像化配信装置１の構成のうち、アーカイブ３００１の動作に関わる部分のみを示している。
【０１１７】
図１４に、本実施形態の番組ＩＤ・キャッシュ対応テーブル２０の構成例を示す。本実施形態の番組ＩＤ・キャッシュ対応テーブル２０は、図６の番組ＩＤ・キャッシュ対応テーブル２０に対して、アーカイブ３００１属性を追加したものである。
【０１１８】
ここでは、番組シナリオ又はコンテンツの更新のタイミングで、ストリーミング配信用にアーカイブを作成するようキャッシュ条件設定ファイル２００に設定する。他に、一日に一度、一週間に一度など、定期的なアーカイブ作成のタイミングを設定しても良い。
【０１１９】
キャッシュ条件設定ファイル２００の指示に基づき、番組シナリオ解釈・コントロール部１０２から制御されるストリーム生成部１０５は、キャッシュ制御部１４に対して、上記更新タイミングにてストリームファイルのキャッシュを作成するよう指示する。アーカイブ３００１は、キャッシュ１１４に以前作成していた同一番組ＩＤのストリームファイルが存在する場合には、これを別の番組ＩＤのストリームファイル名に変更し、自身のファイルシステム内に保管する。
【０１２０】
例えば、番組ＩＤが“１００１０”の番組シナリオや各種コンテンツの更新タイミングにしたがって、キャッシュ制御部１４が、以前キャッシュしていたストリームファイル“10010.mp4”を“10020.mp4”とリネームし、アーカイブ３００１の管理下に移動させる。キャッシュ制御部１４は、番組ＩＤ・キャッシュ対応テーブル２０に対して、以前キャッシュしていたストリームファイルが番組ＩＤを“１００２０”と変更してアーカイブに保管されたことを通知し、図１４のようなエントリーを作成することを依頼する。
【０１２１】
ＡＶクライアント装置２から番組ＩＤが“１００２０”の配信を要求された場合、配信番組検索部３０は、番組ＩＤ・キャッシュ対応テーブル２０の該当エントリーを参照した後、アーカイブ３００１に保存されている“10020.mp4”を引数としてストリーミング配信部１０６に処理を移行するよう、番組シナリオ解釈・コントロール部１０２に伝達し、以降の処理を継続する。
【０１２２】
なお、第1の実施形態に、第２の実施形態の更新検知と第３の実施形態のアーカイブとを両方適用した実施形態も可能である。
【０１２３】
また、本実施形態では、映像配信装置１をインターネット上のサーバや任意のホストとしたが、家庭内にあるＰＣやＡＶ機器を任意のホストとしても良い。ＡＶクライアント装置２に対するサーバとして機能し得る装置すべてが対象となるため、将来的には携帯電話や携帯ゲーム機、携帯ＡＶ機器などの携帯端末機であっても、同様にサーバとして機能し得る場合には映像配信装置１の実施対象となる。
【０１２４】
なお、以上の各機能は、ソフトウェアとして記述し適当な機構をもったコンピュータに処理させても実現可能である。  
また、本実施形態は、コンピュータに所定の手順を実行させるための、あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるためのプログラムとして実施することもできる。加えて該プログラムを記録したコンピュータ読取り可能な記録媒体として実施することもできる。
【０１２５】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【図面の簡単な説明】
【０１２６】
【図１】本発明の一実施形態に係る番組配信システムの全体構成の一例を示す図
【図２】同実施形態に係る番組配信システムの構成例を示す図
【図３】キャッシュを搭載しない場合の映像化配信装置の処理手順の一例を示すフローチャート
【図４】同実施形態に係る映像化配信装置の全体構成の一例を示す図
【図５】キャッシュを搭載した場合の映像化配信装置の処理手順の一例を示すフローチャート
【図６】番組ＩＤ・キャッシュ対応テーブルの構成例を示す図
【図７】メイン用の番組シナリオの記述例を示す図
【図８】コンテンツ取得部の変換処理の一例について説明するための図
【図９】動作指示用の番組シナリオの記述例を示す図
【図１０】生成される映像シーンの一例を示す図
【図１１】同実施形態に係る映像化配信装置の全体構成の他の例を示す図
【図１２】更新処理の手順例を示すフローチャート
【図１３】同実施形態に係る映像化配信装置の全体構成の更に他の例を示す図
【図１４】番組ＩＤ・キャッシュ対応テーブルの他の構成例を示す図
【符号の説明】
【０１２７】
１…映像化配信装置、２…ＡＶクライアント装置、３…ネットワーク、４…番組一覧配信サーバ、５…シナリオサーバ、６…コンテンツサーバ、１００…メイン処理部、１０…番組ＩＤ・シナリオ対応データベース、１１，１２，１３，１４…キャッシュ制御部、２０…番組ＩＤ・キャッシュ対応テーブル、３０…配信番組検索部、４０…配信要求受信・解釈部、１０１…番組シナリオ取得部、１０２…番組シナリオ解釈・コントロール部、１０３…コンテンツ取得部、１０４…映像変換部、１０５…ストリーム生成部、１０６…ストリーミング配信部、１１１，１１２，１１３，１１４…キャッシュ、２００…キャッシュ条件設定ファイル、１０００…番組シナリオ、１００１…テキストコンテンツ、１００２…画像・動画コンテンツ、１００３…ＢＧＭコンテンツ、１００４…背景コンテンツ、２０００…番組一覧情報
【図１】
0005208560.tif 000002
【図２】
0005208560.tif 000003
【図３】
0005208560.tif 000004
【図４】
0005208560.tif 000005
【図５】
0005208560.tif 000006
【図６】
0005208560.tif 000007
【図７】
0005208560.tif 000008
【図８】
0005208560.tif 000009
【図９】
0005208560.tif 000010
【図１０】
0005208560.tif 000011
【図１１】
0005208560.tif 000012
【図１２】
0005208560.tif 000013
【図１３】
0005208560.tif 000014
【図１４】
0005208560.tif 000015