(57)【要約】【課題】作成中のコンテンツが放送用か通信用かを意識することなく、規格、優先度を考慮して配信形式の違いによる振り分けをする。【解決手段】本発明は、制作段階Ｓ１で、コンテンツに対して放送用または通信用のみ可能な設定をユーザーが指定可能なステップＳ１２と、コンテンツが放送または通信専用の機能を使用しているかを判断するステップＳ１３とを備え、自動振り分け段階Ｓ２で、コンテンツに対して放送用または通信用のみ可能な設定の優先度をユーザーが指定可能なステップＳ１４と、コンテンツの各シーンのリンク数に応じた優先度を計算するステップＳ１４と、コンテンツの各シーンの自動振り分けによる放送用または通信用の容量の制限を判断するステップＳ１４とを備えた。【選択図】      図１１
2004304262.tif 000002
【特許請求の範囲】
【請求項１】
放送局におけるデータ放送サービスのためのデータ放送コンテンツを制作するデータ放送コンテンツ制作装置において、
上記データ放送コンテンツの制作段階におけるものであって、
上記データ放送コンテンツに対して放送用のみ可能な設定または通信用のみ可能な設定をユーザーが指定可能なユーザー指定手段と、
上記データ放送コンテンツが放送専用の機能または通信専用の機能を使用しているかを判断する専用機能判断手段と、
を備え、上記ユーザー指定手段により指定された設定または上記専用機能判断手段により判断された専用の機能に応じて、自動的に上記データ放送コンテンツの各シーンを時間的に遷移可能に放送用か通信用かに振り分けるようにしたことを特徴とするデータ放送コンテンツ制作装置。
【請求項２】
請求項１記載のデータ放送コンテンツ制作装置において、
放送用か通信用かのどちらかに振り分けられた上記データ放送コンテンツの各シーンに対する設定は放送用か通信用かの各モードで設定可能なものだけに制限され誤った設定が行えないようにし、それぞれのモード検証により誤った設定に対して警告を発することを特徴とするデータ放送コンテンツ制作装置。
【請求項３】
放送局におけるデータ放送サービスのためのデータ放送コンテンツを制作するデータ放送コンテンツ制作装置において、
上記データ放送コンテンツの制作段階の後の放送用または通信用の自動振り分け段階におけるものであって、
上記データ放送コンテンツに対して放送用のみ可能な設定の優先度または通信用のみ可能な設定の優先度をユーザーが指定可能な優先度指定手段と、
上記データ放送コンテンツの各シーンのリンク数に応じた優先度を計算する優先度計算手段と、
上記データ放送コンテンツの各シーンの自動振り分けによる放送用または通信用の容量の制限を判断する容量制限判断手段と、
を備え、上記優先度指定手段により指定された優先度、上記優先度計算手段により計算された優先度または容量制限判断手段により判断された容量制限に応じて、自動的に上記データ放送コンテンツの各シーンを時間的に遷移可能に放送用か通信用かに振り分けるようにしたことを特徴とするデータ放送コンテンツ制作装置。
【請求項４】
請求項３記載のデータ放送コンテンツ制作装置において、
放送用か通信用かのどちらかに振り分けられた上記データ放送コンテンツの各シーンに対する優先度は各シーンの遷移情報または参照情報に基づいて求められることを特徴とするデータ放送コンテンツ制作装置。
【請求項５】
請求項３記載のデータ放送コンテンツ制作装置において、
放送用か通信用かのどちらかに振り分けられた上記データ放送コンテンツの各シーンに対する設定は放送用容量制限を超えた後に通信用容量制限を判断することを特徴とするデータ放送コンテンツ制作装置。
【請求項６】
請求項３記載のデータ放送コンテンツ制作装置において、
放送用か通信用かのどちらかに振り分けられた上記データ放送コンテンツの各シーンの遷移情報または参照情報に対して変換処理をすることを特徴とするデータ放送コンテンツ制作装置。
【請求項７】
放送局におけるデータ放送サービスのためのデータ放送コンテンツを制作するデータ放送コンテンツ制作方法において、
上記データ放送コンテンツの制作段階におけるものであって、
上記データ放送コンテンツに対して放送用のみ可能な設定または通信用のみ可能な設定をユーザーが指定可能なユーザー指定ステップと、
上記データ放送コンテンツが放送専用の機能または通信専用の機能を使用しているかを判断する専用機能判断ステップと、
を備え、上記ユーザー指定ステップにより指定された設定または上記専用機能判断ステップにより判断された専用の機能に応じて、自動的に上記データ放送コンテンツの各シーンを時間的に遷移可能に放送用か通信用かに振り分けるようにしたことを特徴とするデータ放送コンテンツ制作方法。
【請求項８】
請求項７記載のデータ放送コンテンツ制作方法において、
放送用か通信用かのどちらかに振り分けられた上記データ放送コンテンツの各シーンに対する設定は放送用か通信用かの各モードで設定可能なものだけに制限され誤った設定が行えないようにし、それぞれのモード検証により誤った設定に対して警告を発することを特徴とするデータ放送コンテンツ制作方法。
【請求項９】
放送局におけるデータ放送サービスのためのデータ放送コンテンツを制作するデータ放送コンテンツ制作方法において、
上記データ放送コンテンツの制作段階の後の放送用または通信用の自動振り分け段階におけるものであって、
上記データ放送コンテンツに対して放送用のみ可能な設定の優先度または通信用のみ可能な設定の優先度をユーザーが指定可能な優先度指定ステップと、
上記データ放送コンテンツの各シーンのリンク数に応じた優先度を計算する優先度計算ステップと、
上記データ放送コンテンツの各シーンの自動振り分けによる放送用または通信用の容量の制限を判断する容量制限判断ステップと、
を備え、上記優先度指定ステップにより指定された優先度、上記優先度計算ステップにより計算された優先度または容量制限判断ステップにより判断された容量制限に応じて、自動的に上記データ放送コンテンツの各シーンを時間的に遷移可能に放送用か通信用かに振り分けるようにしたことを特徴とするデータ放送コンテンツ制作方法。
【請求項１０】
請求項９記載のデータ放送コンテンツ制作方法において、
放送用か通信用かのどちらかに振り分けられた上記データ放送コンテンツの各シーンに対する優先度は各シーンの遷移情報または参照情報に基づいて求められることを特徴とするデータ放送コンテンツ制作方法。
【請求項１１】
請求項９記載のデータ放送コンテンツ制作方法において、
放送用か通信用かのどちらかに振り分けられた上記データ放送コンテンツの各シーンに対する設定は放送用容量制限を超えた後に通信用容量制限を判断することを特徴とするデータ放送コンテンツ制作方法。
【請求項１２】
請求項９記載のデータ放送コンテンツ制作方法において、
放送用か通信用かのどちらかに振り分けられた上記データ放送コンテンツの各シーンの遷移情報または参照情報に対して上記振り分けに応じた変換処理をすることを特徴とするデータ放送コンテンツ制作方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、例えば、データ放送サービスのためのデータ放送コンテンツ制作装置およびデータ放送コンテンツ制作方法に関するものである。
【０００２】
【従来の技術】
地上波デジタル放送の開始により、データ放送コンテンツをこれまでの放送用電波のみでなくインターネット上のＨＴＴＰサーバから家庭のテレビに直接取得・受信することが可能になる。
【０００３】
特許文献１では、配信側で放送用データコンテンツの出力属性に応じた表現形式を規定するスタイルシートを決めて振り分け、受信側で出力属性に合致したスタイルシートを選択する技術が開示されている。
【０００４】
また、特許文献２では、放送用データコンテンツの参照情報となるモノメディアを適合規格に変換し、色情報の最適化処理を行う技術が開示されている。
【０００５】
【特許文献１】
特開２００１−８６０７８号公報
【特許文献２】
特開２００３−１８５３１号公報
【０００６】
【発明が解決しようとする課題】
しかし、上述した従来の放送用データコンテンツも通信用データコンテンツも記述言語としてはＢＭＬ（Ｂｒｏａｄｃａｓｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）を使用するが規格上許された記述が一部異なる場合、例えば、放送コンテンツでは可能だが通信コンテンツでは不可能な記述、またはその逆などがある。そのためコンテンツ制作者は作成中のコンテンツが放送用か通信用かという点を常に意識していなければならないという不都合があった。
【０００７】
また、どちらか一方への利用を想定して制作されたコンテンツをもう一方に利用しようとした場合、例えば、放送用から通信用への変更、あるいはその逆など、規格上の制限を考慮し手作業でコンテンツの修正を行う必要が生じるという不都合があった。
【０００８】
また、ＢＳ（Ｂｒｏａｄｃａｓｔｉｎｇ  Ｓａｔｅｌｌｉｔｅ）／ＣＳ（Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｓａｔｅｌｌｉｔｅ）／地上波デジタルを含めた各モードについての規格運用が異なり習得が難解であるため、制作段階での設定が規格違反になる可能性が高く、また、あるモードで作成されたコンテンツの別モードにおける再利用が容易ではないという不都合があった。
【０００９】
また、カルーセル方式で送出されるコンテンツのアクセス頻度などを考慮して、シーンによって構成されるモジュールの優先度を手動で設定する必要があるという不都合があった。
【００１０】
さらに、ＢＳ／ＣＳなどに比べ、地上波デジタル放送におけるデータ放送割り当て帯域は狭いため、通信コンテンツとの共存／住み分けがより重要な課題となる。
【００１１】
また、放送用コンテンツと通信用コンテンツを併用する場合には、その配信形式の違いによる問題が生じる。例えば放送用コンテンツは放送時間が過ぎれば送出されなくなるため時間外には見ることができなくなるが、通信側ではサーバに残っている限りいつでもアクセスすることが可能となってしまう。そのため放送時間に連動して通信用コンテンツも差し替えや削除という手段によってアクセスを制御する手段が必要となるという不都合があった。
【００１２】
そこで、本発明は、かかる点に鑑みてなされたものであり、作成中のコンテンツが放送用か通信用かを意識することなく、規格および優先度を考慮して配信形式の違いによる振り分けをすることができるデータ放送コンテンツ制作装置およびデータ放送コンテンツ制作方法を提供することを課題とする。
【００１３】
【課題を解決するための手段】
本発明のデータ放送コンテンツ制作装置は、データ放送コンテンツの制作段階におけるものであって、データ放送コンテンツに対して放送用のみ可能な設定または通信用のみ可能な設定をユーザーが指定可能なユーザー指定手段と、データ放送コンテンツが放送専用の機能または通信専用の機能を使用しているかを判断する専用機能判断手段とを備えたものである。
【００１４】
これにより、ユーザー指定手段により指定された設定または専用機能判断手段により判断された専用の機能に応じて、自動的にデータ放送コンテンツの各シーンを時間的に遷移可能に放送用か通信用かに振り分けるようにした。
【００１５】
従って本発明によれば、以下の作用をする。
データ放送コンテンツ制作装置は、データ放送サービスのコンテンツ制作において、放送向けのみでなく通信向けのコンテンツの制作を可能とするように、放送用と通信用の双方に送出／配信されることを前提としたコンテンツをユーザー指定手段により指定された設定または専用機能判断手段により判断された専用の機能に応じて、自動的に放送用として使用するコンテンツと通信用として使用するコンテンツに振り分けることができる。
【００１６】
ここで、地上波デジタル放送の開始により、データ放送コンテンツをこれまでの放送用電波のみでなくインターネット上のｈｔｔｐ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）サーバから家庭のテレビ受像機で直接取得・受信することが可能になる。
特に、ＢＳデジタル放送用コンテンツやＣＳ１１０度用コンテンツだけではなく地上波デジタル放送用コンテンツを一つの制作装置で制作可能であり、さらに地上波デジタルとしては放送用と通信用のコンテンツ両方を制作できる。
【００１７】
また、地上波デジタルコンテンツ制作において、放送用と通信用の自動振り分け機能により、制作初期段階では各シーンが放送用か通信用かを意識しないで制作することができる。
【００１８】
この際、放送用と通信用の区別なく同一のＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）を使用してコンテンツの制作ができる。また、放送用と通信用の区別なく同一のＧＵＩを使用して時間に連動するコンテンツの制作ができる。
【００１９】
また、本発明のデータ放送コンテンツ制作装置は、データ放送コンテンツの制作段階の後の放送用または通信用の自動振り分け段階におけるものであって、データ放送コンテンツに対して放送用のみ可能な設定の優先度または通信用のみ可能な設定の優先度をユーザーが指定可能な優先度指定手段と、データ放送コンテンツの各シーンのリンク数に応じた優先度を計算する優先度計算手段と、データ放送コンテンツの各シーンの自動振り分けによる放送用または通信用の容量の制限を判断する容量制限判断手段とを備えたものである。
【００２０】
これにより、優先度指定手段により指定された優先度、優先度計算手段により計算された優先度または容量制限判断手段により判断された容量制限に応じて、自動的にデータ放送コンテンツの各シーンを時間的に遷移可能に放送用か通信用かに振り分けるようにした。
【００２１】
従って本発明によれば、以下の作用をする。
データ放送コンテンツ制作装置は、データ放送サービスのコンテンツ制作において、放送向けのみでなく通信向けのコンテンツの制作を可能とするように、放送用と通信用の双方に送出／配信されることを前提としたコンテンツを優先度指定手段により指定された優先度、優先度計算手段により計算された優先度または容量制限判断手段により判断された容量制限に応じて、自動的に放送用として使用するコンテンツと通信用として使用するコンテンツに振り分けることができる。
【００２２】
また、本発明のデータ放送コンテンツ制作方法は、データ放送コンテンツの制作段階におけるものであって、データ放送コンテンツに対して放送用のみ可能な設定または通信用のみ可能な設定をユーザーが指定可能なユーザー指定ステップと、データ放送コンテンツが放送専用の機能または通信専用の機能を使用しているかを判断する専用機能判断ステップとを備えたものである。
【００２３】
これにより、ユーザー指定ステップにより指定された設定または専用機能判断ステップにより判断された専用の機能に応じて、自動的にデータ放送コンテンツの各シーンを時間的に遷移可能に放送用か通信用かに振り分けるようにした。
【００２４】
従って本発明によれば、以下の作用をする。
データ放送コンテンツ制作方法は、データ放送サービスのコンテンツ制作において、放送向けのみでなく通信向けのコンテンツの制作を可能とするように、放送用と通信用の双方に送出／配信されることを前提としたコンテンツをユーザー指定ステップにより指定された設定または専用機能判断ステップにより判断された専用の機能に応じて、自動的に放送用として使用するコンテンツと通信用として使用するコンテンツに振り分けることができる。
【００２５】
また、本発明のデータ放送コンテンツ制作方法は、データ放送コンテンツの制作段階の後の放送用または通信用の自動振り分け段階におけるものであって、データ放送コンテンツに対して放送用のみ可能な設定の優先度または通信用のみ可能な設定の優先度をユーザーが指定可能な優先度指定ステップと、データ放送コンテンツの各シーンのリンク数に応じた優先度を計算する優先度計算ステップと、データ放送コンテンツの各シーンの自動振り分けによる放送用または通信用の容量の制限を判断する容量制限判断ステップとを備えたものである。
【００２６】
これにより、優先度指定ステップにより指定された優先度、優先度計算ステップにより計算された優先度または容量制限判断ステップにより判断された容量制限に応じて、自動的にデータ放送コンテンツの各シーンを時間的に遷移可能に放送用か通信用かに振り分けるようにした。
【００２７】
従って本発明によれば、以下の作用をする。
データ放送コンテンツ制作装置は、データ放送サービスのコンテンツ制作において、放送向けのみでなく通信向けのコンテンツの制作を可能とするように、放送用と通信用の双方に送出／配信されることを前提としたコンテンツを優先度指定ステップにより指定された優先度、優先度計算ステップにより計算された優先度または容量制限判断ステップにより判断された容量制限に応じて、自動的に放送用として使用するコンテンツと通信用として使用するコンテンツに振り分けることができる。
【００２８】
【発明の実施の形態】
以下に、本発明の実施の形態について適宜図面を参照しながら説明する。
【００２９】
地上波デジタル放送の開始により、データ放送コンテンツをこれまでの放送用電波のみでなくインターネット上のＨＴＴＰサーバから家庭のテレビに直接取得・受信することが可能になる。
【００３０】
図１は、放送波またはインターネットによるデータ放送コンテンツの放送システムを示す図である。
図１のように放送局１からは放送用コンテンツ４−１，４−２を放送波３を介してデータカルーセル４方式で送出する。視聴者５は受信機５−１やそれに相当する機能を持つパーソナルコンピュータ、携帯電話などで放送波３を受信することで放送用コンテンツ４−１，４−２にアクセスすることができ、同時にインターネット６を通じてサーバ２上に用意された通信用コンテンツ２−１，２−２，２−３にアクセスすることができる。
【００３１】
図２は、放送コンテンツと通信コンテンツの閲覧を示す図である。
図２において、放送用コンテンツ２１−１，２１−５と通信用コンテンツ２１−２，２１−３，２１−４はお互いにシーンの行き来が可能であるなど、視聴者から見た場合には区別なく混在することができる。
【００３２】
しかし放送コンテンツと通信コンテンツでは出来ることが異なり、放送側で送出可能な帯域がＢＳ／ＣＳなどの衛星データ放送と比較して狭いという問題がある。
【００３３】
ＢＳ／ＣＳ／地上波という区別は制作段階ではっきりしているが、地上波コンテンツを制作するという段階では放送用か通信用かは明確でない可能性がある。また、区別が明確であったとしても制作者はそれがどちらに対するコンテンツであるかを常に意識している必要がある。
【００３４】
本発明の実施の形態では放送用コンテンツと通信用コンテンツを意識せずに同一のＧＵＩなどを用いて制作する環境を提供し、さらに双方の検証／変換や、コンテンツを自動的に放送側と通信側へと振り分ける最適化機能により、コンテンツ制作者の負担を減らすことを目的とする。
【００３５】
図３は、デジタル衛星放送、地上波デジタル放送またはインターネットによるデータ放送コンテンツの放送システムを示す図である。
図３において示すように、データ放送コンテンツをこれまでの放送局３１からの放送用電波のみでなくインターネット３７上の情報提供システム（ｗｅｂサーバ）３８または情報提供システム（スタイルシート・サーバ）３９から受信局３５である一般家庭のテレビ受像機で直接取得・受信することが可能になる。
【００３６】
特に、放送衛星３３を用いたＢＳデジタル放送用コンテンツやＣＳ１１０度用コンテンツだけではなく地上波デジタル放送用コンテンツ３６を一つの制作装置で制作可能であり、さらに地上波デジタルとしては放送用と通信用のコンテンツ両方を制作できる。
【００３７】
次に、制作対象となるコンテンツの構成の概要を説明する。
放送の場合、データ放送コンテンツは表示装置の一つの画面に表示される単位をシーンとして、通常複数のシーンによって構成され、例えば、リモートコマンダーのアップキ−またはダウンキーの操作などにより時間的に連続するシーン間を行き来するように表示装置の画面上で表示することができる。表示されるシーンは時間により他のシーンに切り替わるようにされることもある。
【００３８】
また複数のシーンはひとつのモジュールという単位でまとめられ、さらに複数のモジュールをカルーセルとしてデータエレメンタリーストリーム（データＥＳ）の形で送出する。
【００３９】
コンテンツが通信コンテンツとして提供される場合はモジュールやカルーセルといった放送特有の概念はなく、通常のインターネット環境で見られるＨＴＭＬ（ｈｙｐｅｒｔｅｘｔ  ｍａｒｋｕｐ  ｌａｎｇｕａｇｅ）コンテンツのようにＨＴＴＰサーバ上のフォルダ構成の中に配置される。
【００４０】
放送側でシーンなどのコンテンツ全体を管理する情報としては番組交換フォーマットを示すＢＣＭＬ（Ｂｒｏａｄｃａｓｔ  Ｃｏｎｔｅｎｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）という記述言語を用いる。ただしその他の管理フォーマットを用いる場合においても同様の構成を利用可能である。
【００４１】
放送用のみ、あるいは通信用のみのコンテンツ制作も可能だが、それらを併用するコンテンツの制作時に特に効果があると考えられる。
【００４２】
コンテンツの配信環境として特に放送波と通信を併用する場合を想定する。
放送のデータコンテンツ配信手法であるカルーセル方式にはある時間帯で送出可能なデータに容量制限がある。同時に送出されているデータが多いほどユーザーが目的のシーンを表示するためにかかる時間は長くなる可能性がある。アクセス頻度が高いシーン、例えば、ほとんどのユーザーがアクセスすることが予想されるインデックス画面など、のみをカルーセル方式で送出しておき、アクセス頻度が低いシーンを通信側のサーバに置いておくという運用が想定される。
【００４３】
制作初期段階で放送用／通信用と用途を分けて制作する必要がないようにする。初期段階では用途を意識せずに制作し、最終段階で優先度などを元に放送用と通信用に自動で分ける。
【００４４】
共通の素材をベースとして利用し、用途に応じて放送用／通信用に変換して出力する。
地上波デジタル（放送用）／地上波デジタル（通信用）／ＣＳ用／ＢＳデジタル用への変換／出力も可能である。
【００４５】
モードによりＧＵＩの設定制限などがかかり間違えた設定ができないようになっている。ただし制作初期段階で放送用または通信用という明確な指定をユーザーが行っていない場合には放送専用機能と通信専用機能の両方の設定を可能とする。後述するタイミングでどちらかのモードに固定された場合にＧＵＩの設定可否は対応するモードにロックされる。
【００４６】
編集中のモードで設定対象外の項目は画面上でも設定不可になる。
編集中のモードで固定値運用される項目は自動的に値が設定され変更不可状態になる。
検証メニューを実行した場合、編集中のモードに従い運用規格検査などの検証が行われる。
【００４７】
制作途中でモードを変更することが出来る。自動的に規格への適合検査を行い、変換先の規格に適合するように各種値を変更する。変更する際には画面上でユーザーに対し変更項目と内容を報告し了解を取る。これによりある放送形態で利用したコンテンツを別の放送形態で再利用することができる。同時に各ＧＵＩの有効／無効や規格チェック用の検証／変換モードも自動的に変更される。
【００４８】
図４にモード変更時の表示例を示す。
図４において、例えば、データ放送コンテンツを、ＢＳ用からＣＳ用へ変更したとき、ＣＳ用設定４１で示すように、「ｄａｔａ  ｅｓ要素のｅｓ  ｒｅｆｅｒｒｅｄ属性値を０Ｘ５０に設定しました。」という表示に対応する変換処理がされ、ＢＳからＣＳ変更用設定４２で示すように、「ｍｏｄｕｌ要素のｆｏｒｍａｔ  ｖｅｒｓｉｏｎ属性値を１．０から２．０に変更しました。」という表示に対応する変換処理がされる。
【００４９】
図５に時間編成ＧＵＩのイメージを示す。
図５において、通信コンテンツ管理用のＨＴＴＰサーバに該当する機能があるという前提のもとで、各シーン５１で示すように、通信側のＢＭＬコンテンツに対しても放送側のＢＭＬコンテンツと共に時間編成を可能とする。
【００５０】
制作段階では放送側／通信側を意識せずに同一ＧＵＩを用いてＢＭＬコンテンツに対する各シーン５１の制作を行い、コンテンツの最終出力時に振り分けを行うようにする。
【００５１】
ＢＣＭＬファイルをインターフェースとするＨＴＴＰサーバ用の管理アプリケーションを使用することが前提となる。
サーバ側がその他ＢＣＭＬファイル以外のインターフェースを利用して通信コンテンツの時間制御を可能としている場合は、そのインターフェースにあわせて出力する機能を実装することで対応可能となる。
【００５２】
ここで、本発明の実施の形態で制御対象とする「データ放送コンテンツ」について説明する。
本発明の実施の形態で制御対象とするデータ放送コンテンツとはデジタルデータ放送におけるデータ部を記述するＢＭＬ（Ｂｒｏａｄｃａｓｔ  ＭａｒｋｕｐＬａｎｇｕａｇｅ）コンテンツのことであり、通常テレビで流れているような映像音声コンテンツを含まない。
【００５３】
ＢＭＬコンテンツ内で「シーン」とは一つの画面のことであり、インターネット上のＨＴＭＬコンテンツの一つのページにあたる単位を表す。通常複数のシーンをページを切り替えるように行き来することで一つのＢＭＬコンテンツが構成される。
【００５４】
通常一つのシーンは一つのＢＭＬファイルとそこから参照される画像などのモノメディアファイルによって構成される。
【００５５】
次に、番組交換基準およびＢＣＭＬ（Ｂｒｏａｄｃａｓｔ  Ｃｏｎｔｅｎｔ    Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）ファイルについて説明する。
放送局への納品時には各シーンやそこに使用されるモノメディアファイルだけでなく、それらを束ね、またシーンの提示時間や納品情報など各種情報を含むファイルが必要となる。地上波デジタル放送ではそのための番組交換基準としてＢＣＭＬファイルの規格が定められた（規格書：ＡＲＩＢ（Ａｓｓｏｃｉａｔｉｏｎ  ｏｆ  Ｒａｄｉｏ  Ｉｎｄｕｓｔｒｉｅｓ  ａｎｄ  Ｂｕｓｉｎｅｓｓｅｓ）  ＳＴＤ−Ｂ３５）。
ＢＣＭＬファイルはＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）形式で複数のタグにより構成される。
【００５６】
以下にＢＣＭＬファイルを用いたコンテンツ管理の概要を示す（規格書より抜粋）。
データ放送伝送方式とＢＣＭＬコンテンツの構成について以下に説明する。
【００５７】
まず、伝送イメージに基づいたファイルシステム構成を説明する。
図６は、カルーセル伝送されるデータ放送コンテンツの構造を示す図である。ＤＳＭ−ＣＣ（Ｄｉｇｉｔａｌ  Ｓｔｏｒａｇｅ  Ｍｅｄｉｕｍ  ａｎｄ  Ｃｏｎｔｒｏｌ）データカルーセル方式送出データとして、データ放送コンテンツは送信装置（放送局）から送出される。データカルーセル方式送出データは、例えば、Ｓ社ファイル、Ｍ社ファイル、Ｐ社ファイル、Ｙ社ファイルの順で回転式に送出される方式のデータである。
ＤＳＭ−ＣＣデータカルーセル伝送方式に基づいて放送波経由で伝送されるデータ放送コンテンツは、１つ以上のエレメンタリーストリームＥＳで構成される。各データエレメンタリーストリームＥＳは、データイベント（１）６１、（２）６２・・・によって時間的に区切られた１つ以上のローカルコンテンツ（データイベント）１，２で構成される。各ローカルコンテンツ１，２は、データ放送コンテンツの送出単位である１つ以上のカルーセル（１１）６３−１、（１２）６３−２・・・（１Ｎ）６３−Ｎ、カルーセル（２１）６４−１・・・で構成される。各カルーセル（１１）６３−１、（１２）６３−２は０個以上のモジュール（１１）６５−１、（１２）６５−２・・・（１Ｍ）６５−Ｍ、モジュール（２１）６６−１、（２２）６６−２・・・（２Ｍ）６５−Ｍ｀で構成されている。ここで、モジュールが０個である場合には、当該カルーセルが空カルーセルであることを意味する。
【００５８】
ＤＳＭ−ＣＣデータカルーセル伝送方式では、ローカルコンテンツ１，２・・・の切り替え点、図６におけるデータイベント１からデータイベント２に変わる点がカルーセルの切り替え点、図６におけるカルーセル（１Ｎ）６３−Ｎからカルーセル（２１）６４−１に変わる点と一致する。すなわち、データイベント（１）６１、（２）６２・・・の更新はカルーセル（１Ｎ）６３−Ｎからカルーセル（２１）６４−１・・・の切り替えを伴うため、ローカルコンテンツはカルーセル列として取り扱うことが可能である。
【００５９】
次に、ＢＣＭＬコンテンツのファイルシステム構成を説明する。
図７に交換方式において交換されるＢＣＭＬコンテンツのフォルダ構成モデルを示す。
図７において、ルートフォルダ（コンテンツフォルダ）７１の下位にはＢＣＭＬファイル７２−１とデータＥＳフォルダ７２−２が設けられている。データＥＳフォルダ７２−２の下位にはカルーセルフォルダ７３が設けられている。カルーセルフォルダ７３の下位にはモジュールファイル７４−１とモジュールフォルダ７４−２が設けられている。モジュールフォルダ７４−２の下位にはリソースファイル７５−１と再編集用フォルダ７５−２が設けられている。再編集用フォルダ７５−２の下位には再編集用ファイル７６が設けられている。
【００６０】
ここで、ＢＣＭＬファイル７２−１について説明する。
本交換方式において交換されるＢＣＭＬコンテンツに含まれる管理ファイルを「ＢＣＭＬファイル」と呼ぶ。ＢＣＭＬファイルは、規格書第４章にて規定される「ＢＣＭＬ」と呼ばれる記述言語を用いて記述される。ＢＣＭＬファイル７２−１は、ＢＣＭＬコンテンツのルートフォルダ（コンテンツフォルダ）７１に配置する。１個または必要に応じて複数のＢＣＭＬファイル７２−１を配置することが可能である。ただし、ＢＣＭＬファイル７２−１を単独で交換する場合はこの限りではない。
【００６１】
モジュールフォルダ７４−２の下位のリソースファイル７５−１は、コンテンツのシーン７７が格納されていて、例えば、ｂｍｌ７７−１、ＪＰＥＧ（Ｊｏｉｎｔ  Ｐｈｏｔｏｇｕｒａｐｈ  Ｅｘｐｅｒｔ  Ｇｒｏｕｐ）７７−２、・・・ｂｍｌ７７−ｎが設けられる。
【００６２】
図８は、地上波デジタル放送のデータコンテンツの状態を示す図である。
地上波デジタル放送で扱うＢＭＬコンテンツは視聴者の受信状態によって以下の３種の状態に分けることができる。第１の状態は、状態名８１がデータ放送受信状態８４で、状態８２がデータ放送と映像・音声をともに受信、再生している状態であり、このときデータコンテンツ（ＢＭＬ）の形式８３は放送用である。
【００６３】
第２の状態は、状態名８１がリンク状態８５で、状態８２が通信コンテンツと映像・音声をともに受信、再生している状態であり、このときデータコンテンツ（ＢＭＬ）の形式８３は通信（リンク状態）用である。
【００６４】
第３の状態は、状態名８１が非リンク状態８６で、状態８２が通信コンテンツのみを受信、再生している状態であり、このときデータコンテンツ（ＢＭＬ）の形式８３は通信（非リンク状態）用である。
【００６５】
放送用と通信用（リンク、非リンク）コンテンツの主な違いを以下に説明する。
放送用、通信用（リンク状態、非リンク状態）のコンテンツの制約のうち代表的なものを以下に示す。
【００６６】
放送用のみで使用可のものとして、割り込みイベント（Ｂｅｖｅｎｔ、Ｂｅｉｔｅｍ）の使用およびｅｖｅｎｔ ｍｅｓｓａｇｅ Ｇｒｏｕｐ ｉｄ属性の値が０のイベントメッセージの受信がある。ここで、通信（リンク状態）では値が１のもののみ受信できる。また、通信（非リンク状態）ではイベントメッセージの受信ができない。
【００６７】
次に、状態による放送用拡張関数（規格書ＡＲＩＢ  ＴＲ−Ｂ１４より抜粋）の動作例を説明する。
図９は、通信コンテンツのＢａｓｉｃ手順双方向機能の動作を示す図である。図９において、放送用拡張関数９１がｃｏｎｎｅｃｔ（）のとき、データ放送受信状態９２は○：動作する、リンク状態９３は×：動作失敗する、非リンク状態９４は×：動作失敗する、である。
【００６８】
放送用拡張関数９１がｄｉｓｃｏｎｎｅｃｔ（）のとき、データ放送受信状態９２は○：動作する、リンク状態９３は×：動作失敗する、非リンク状態９４は×：動作失敗する、である。
【００６９】
放送用拡張関数９１がｓｅｎｄＴｅｘｔＤａｔａ（）のとき、データ放送受信状態９２は○：動作する、リンク状態９３は×：動作失敗する、非リンク状態９４は×：動作失敗する、である。
【００７０】
放送用拡張関数９１がｒｅｃｅｉｖｅＴｅｘｔＤａｔａ（）のとき、データ放送受信状態９２は○：動作する、リンク状態９３は×：動作失敗する、非リンク状態９４は×：動作失敗する、である。
【００７１】
図１０は、通信コンテンツのＴＣＰ／ＩＰ（ｔｒａｎｓｍｉｓｓｉｏｎ  ｃｏｎｔｒｏｌ  ｐｒｏｔｏｃｏｌ／ｉｎｔｅｒｎｅｔ  ｐｒｏｔｏｃｏｌ）双方向機能の動作を示す図である。
図１０において、放送用拡張関数１０１がｇｅｔＣｏｎｎｅｃｔｉｏｎＴｙｐｅ（  ）のとき、データ放送受信状態１０２は○：動作する、リンク状態１０３は：動作する、非リンク状態１０４は○：動作する、である。
【００７２】
放送用拡張関数１０１がｉｓＩＰＣｏｎｎｅｃｔｅｄ（  ）  のとき、データ放送受信状態１０２は○：動作する、リンク状態１０３は○：動作する、非リンク状態１０４は○：動作する、である。
【００７３】
放送用拡張関数１０１がｃｏｎｎｅｃｔＰＰＰ（  ）のとき、データ放送受信状態１０２は○：動作する、リンク状態１０３は×：動作失敗する、非リンク状態１０４は×：動作失敗する、である。
【００７４】
放送用拡張関数１０１がｃｏｎｎｅｃｔＰＰＰＷｉｔｈＩＳＰＰａｒａｍｓ  （  ）  のとき、データ放送受信状態１０２は○：動作する、リンク状態１０３は○：動作する、非リンク状態１０４は×：動作失敗する、である。
【００７５】
放送用拡張関数１０１がｄｉｓｃｏｎｎｅｃｔＰＰＰ（  ）のとき、データ放送受信状態１０２は○：動作する、リンク状態１０３は○：動作する、非リンク状態１０４は×：動作失敗する、である。
【００７６】
放送用拡張関数１０１がｓｅｔＩＳＰＰａｒａｍｓ（  ）のとき、データ放送受信状態１０２は○：動作する、リンク状態１０３は×：動作失敗する、非リンク状態１０４は×：動作失敗する、である。
【００７７】
放送用拡張関数１０１がｇｅｔＩＳＰＰａｒａｍｓ（  ）  のとき、データ放送受信状態１０２は○：動作する、リンク状態１０３は×：動作失敗する、非リンク状態１０４は×：動作失敗する、である。
【００７８】
放送用拡張関数１０１がｓｅｎｄＴｅｘｔＭａｉｌ（  ）のとき、データ放送受信状態１０２はオプション、リンク状態１０３はオプション、非リンク状態１０４は×：動作失敗する、である。
【００７９】
放送用拡張関数１０１がｓｅｎｄＭＩＭＥＭａｉｌ（  ）のとき、データ放送受信状態１０２はオプション、リンク状態１０３はオプション、非リンク状態１０４は×：動作失敗する、である。
【００８０】
放送用拡張関数１０１がｔｒａｎｓｍｉｔＴｅｘｔＤａｔａＯｖｅｒＩＰ（  ）のとき、データ放送受信状態１０２は○：動作する、リンク状態１０３は：動作する、非リンク状態１０４は○：動作する、である。
【００８１】
なお、上記の図９、図１０は放送用拡張関数の一例である。このようにある状態でしか使用できない（正しく動作しない）関数の使用状況により振り分け先が制限されることになる。
【００８２】
さらに、放送用、通信用（リンク状態、非リンク状態）のコンテンツのシーン遷移時のＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）の記述が異なる。
【００８３】
例えば、通信コンテンツへの遷移時：“ｈｔｔｐ：”、”ｈｔｔｐｓ：”に対して、通信（リンク状態）から放送コンテンツへの遷移時：”ａｒｉｂ−ｄｃ：”となる。ただし、非リンク状態の通信コンテンツから放送コンテンツへ遷移することはできない。
【００８４】
また、放送用、通信用（リンク状態、非リンク状態）のコンテンツの規格により推奨されているＢＭＬファイルの拡張子が異なる。
【００８５】
例えば、放送コンテンツ：＊．ｂｍｌ、通信コンテンツ（リンク状態）：＊．ｌｂｍｌ、通信コンテンツ（非リンク状態）：＊．ｉｂｍｌとなる。
【００８６】
また、放送コンテンツとして配信されることが望まれるコンテンツとして、例えば、映像・音声との同期など、動作タイミングが重要なＢＭＬコンテンツ、全ての要素を正しく提示することが重要なＢＭＬコンテンツ、画像などのモノメディアを多用したＢＭＬコンテンツがある。
【００８７】
上述したように構成される本実施の形態の動作を以下に説明する。
図１１は、放送用コンテンツと通信用コンテンツの自動振り分け（最適化）を示すフローチャートである。
ステップＳ１の制作段階の後にステップＳ２の最適化（自動振り分け）が行われる。
【００８８】
ステップＳ１の制作段階におけるステップＳ１１では、コンテンツの制作が行われる。具体的には、ユーザーが各シーンの制作を行う。
【００８９】
ステップＳ１の制作段階におけるステップＳ１２では、ユーザーによって指定されているか否かを判断する。具体的には、ステップＳ１１でユーザーが制作した各シーンに対して放送用か通信用かを明確に指定することにより、ユーザー指定を判断する。
【００９０】
ステップＳ１２でユーザーによって指定されていないときは、ステップＳ１の制作段階におけるステップＳ１３へ進み、ステップＳ１３で、専用の機能を使用しているか否かを判断する。具体的には、放送用でしか使用できない放送用拡張関数やイベントメッセージなど放送の割り込みイベントを使用しているシーンや関連シーンを優先して放送側に渡す。また、通信用でしか使用できない機能を使用しているシーンや関連シーンを優先して通信側に渡す。さらに、イベントメッセージなど放送用でしか使用できない項目などを自動再設定する。また通信用でしか使用できない項目を自動再設定する。自動で変更できない項目については警告を表示しユーザーによる変更を促す。
【００９１】
ステップＳ１２およびステップＳ１３で、放送用のときはステップＳ１５の放送用コンテンツに振り分け、通信用のときはステップＳ１６の通信用コンテンツに振り分ける。
【００９２】
ステップＳ１３で専用の機能を使用していないときは、ステップＳ２の最適化（自動振り分け）段階へ進み、ステップＳ２の最適化（自動振り分け）段階のステップＳ１４で、放送用として送出するコンテンツと通信用としてＨＴＴＰサーバ上に公開するコンテンツを自動で振り分け最適化する。最適化（振り分け）の判断基準となる項目としては以下を想定する。これらを総合的に判断して、優先度を決定する。
【００９３】
具体的には、第１に、ユーザーの指定した優先度による。ユーザーが制作した各シーンに対して優先度を設定することができる。優先度はユーザーがアクセスする頻度が高いと思われるもの、例えば、インデックス画面などについては高く設定しておく。すべてのシーンに優先度を設定した後に最適化メニューを実行すると、設定された優先度を元に放送用と通信用に振り分けられる。ＢＣＭＬ内の属性ｐｒｉｏｒｉｔｙの値をベースにするほか、ツール独自の優先度属性を使用することも可能とする。
【００９４】
第２に、リンクされている数やリンクしている数により優先度を自動計算する。あるシーンからのリンク、例えば、シーン遷移用の関数が使われている数や、あるシーンへのリンク、例えば、その他のシーンから遷移先として指定されている数をコンテンツ全体から算出し、遷移先として多く設定されているシーンをアクセス頻度の高いシーンとみなし優先度を高く設定する。
【００９５】
第３に、容量による自動計算をする。容量制限のあるカルーセル（放送側）におさまるように自動的に振り分ける。インデックスページはファイル名で判別できるため優先して放送側に振り分け、その他は特に優先順位をつけない。制限容量を超えるシーンは通信側に振り分ける。
【００９６】
ステップＳ２の最適化（自動振り分け）段階のステップＳ１４で、放送用のときはステップＳ１５の放送用コンテンツに振り分け、通信用のときはステップＳ１６の通信用コンテンツに振り分ける。
【００９７】
上記のように自動で放送側／通信側に割り当てるほかに、ユーザー自身がシーンごとに明示的に割り当てを行うことも可能である。その場合は最終段階での検証時に容量制限を違反していないかどうか、使用している機能項目に矛盾は無いか、などをチェックし誤りがあった場合は内容とともに警告し、ユーザーにより修正するか、アプリケーションが自動で修正するかを選択させる。
【００９８】
データエレメンタリーストリームＥＳ名やカルーセル名など放送側でしか指定できない部分を通信用コンテンツに変換する場合は該当する部分を通信側のフォルダ構成にあうように書き換える。通信コンテンツ用サーバのフォルダ構成をデータエレメンタリーストリームＥＳやカルーセル名にあわせることで解決可能である。
【００９９】
シーン制作中に放送側専用（または通信側専用）の関数などを使用した機能を設定した場合、そのシーンに放送側（または通信側）への優先度が設定される。
【０１００】
その後、同じシーン内で他方専用の機能を設定しようとした場合は警告を表示し、混在しないようにする。
【０１０１】
または一方専用の機能を使用した時点でモードを固定し他方専用機能の設定ができないようにＧＵＩ上でロックしてしまう、ということも可能とする。
【０１０２】
コンテンツ管理情報の出力は番組交換フォーマットであるＢＣＭＬファイル形式を主とする。コンテンツを構成するシーンを記述するためのＢＭＬとコンテンツ全体を管理するためのＢＣＭＬファイル共にモードごとにバージョンや運用制約が異なるため出力時に変換を行う。
【０１０３】
あるモードにしたがって作成されたコンテンツを別のモードに変換することができる。これによりコンテンツの再利用性が向上する。
【０１０４】
また上記のように各シーンが放送用、通信用のどちらに属するかを意識しない状態で制作することが可能であるが、初期段階でシーンを放送用または通信用としてユーザーが宣言し区別を意識した制作を行うことも可能とする。その場合は対応するモードで使用可能な設定機能のみ有効となり、誤設定を防ぐようにする。
【０１０５】
本発明の実施の形態の基本的な考え方は放送と通信の双方で連携したコンテンツを制作する場合に応用可能である。
【０１０６】
以下に、上述した制作段階、最適化（自動振り分け）段階およびこれに続く変換処理段階の動作を詳細に説明する。
図１２は、制作段階を示すフローチャートである。
ステップＳ１の制作段階におけるステップＳ２１の制作開始の後にステップＳ２２のシーンの制作を行う。具体的には、制作段階の制作初期段階で、放送用と通信用の区別なくシーンの制作を開始する。ＧＵＩでは放送用と通信用（リンク、非リンク）の双方の機能を使用可とする。
【０１０７】
ステップＳ２２のシーンの制作におけるステップＳ２３で、専用の機能設定を使用したか否かを判断する。ステップＳ２３で専用の機能設定を使用したときは、ステップＳ２４で対応する振り分けを行う。具体的には、制作中では、放送用専用の機能を使用しているシーンを放送コンテンツとして振り分ける。例えば、割り込みイベント（ｂｅｖｅｎｔ，ｂｉｔｅｍ）や放送コンテンツでしか動作しない放送用拡張関数を使用した時点でそのシーンを放送用に設定する。この時点からそのシーンについて、ＧＵＩ上では放送用で使用できない機能や設定ができないようになる。振り分けのタイミングは制作中に専用の機能（関数）を使用したり、設定を使用した時点とする。
【０１０８】
ステップＳ２３で専用の機能設定を使用しないときは、ステップＳ２５で、制作者が振り分け先を指定したか否かを判断する。ステップＳ２５で制作者が振り分け先を指定したときは、ステップＳ２６で振り分け先のコンテンツとして正しいか否かを判断する。ステップＳ２６で振り分け先のコンテンツとして正しいときは、ステップＳ２７で、指定に従い振り分けを行う。ステップＳ２６で振り分け先のコンテンツとして正しくないときは、ステップＳ２８で、指定通りの振り分けができない旨の警告をして、ステップＳ２３に戻って、ステップＳ２３〜ステップＳ２６までの処理および判断を繰り返す。
【０１０９】
具体的には、ユーザー自身がシーンごとに明示的に割り当てを行う。その場合は最終段階での検証時に容量制限を違反していないかどうか、使用している機能項目に矛盾は無いか、などをチェックし誤りがあった場合は内容とともに警告し、ユーザーにより修正するか、アプリケーションが自動で修正するかを選択させる。
【０１１０】
ステップＳ２５で制作者が振り分け先を指定しないときは、ステップＳ２９で、全シーンの制作が完了したか否かを判断する。ステップＳ２９で全シーンの制作が完了したときは、ステップＳ３０で、各シーンに必要に応じて優先度を設定する。ステップＳ２９で全シーンの制作が完了しないときは、ステップＳ２３へ戻って、ステップＳ２３〜ステップＳ２９までの処理および判断を繰り返す。
【０１１１】
具体的には、制作最終段階で、一通りのシーンの制作が終了した時点である。この時点では専用機能を使用したシーンのみ放送または通信（リンク、非リンク）に振り分けられている。その他のシーンの振り分け先は未定である。制作者は主観的な判断により各シーンを放送用、通信用（リンク、非リンク）のいずれかを明示的に指定することが出来る。設定は制作開始から制作最終段階までの任意のタイミングで可能である。
【０１１２】
ここで指定されたコンテンツは直ちに指定されたモードでの検証を行い、それぞれのモード用に変換される。すでに放送用／通信用（リンク、非リンク）のいずれかに振り分けられていたものに対し、別のモードの指定をする場合は検証を行い、その結果として自動変換可能である場合をのぞき、手動での変更を伴わなければモードの変更は不可である旨を制作者に通知する。
【０１１３】
制作者は主観的な判断により各シーンに優先度を数値で設定することができる。設定は制作開始から制作最終段階までの任意のタイミングで可能である。放送優先にすべきと考えるコンテンツに高い優先度をつける。優先度は自動振り分け時の判断材料となるが、特に必要でない場合は設定しなくてもよい。
【０１１４】
図１３は、最適化（自動振り分け）段階を示すフローチャートである。
ステップＳ２の最適化（自動振り分け）段階におけるステップＳ３１の自動振り分け段階について説明する。ステップＳ３１の自動振り分け段階におけるステップＳ３２で、自動振り分け命令を実行する。具体的には、「送出形式で保存」や「シーンの振り分け」というようなメニューを実行し、制作者は明示的に自動振り分けのタイミングを指示する。下記の第１〜第５の判定基準により各シーンに自動で優先度を設定し放送側／通信側に分配する。
【０１１５】
優先度判定基準として、第１に、放送専用の機能の使用を判断する。「放送のみ」、または「放送または通信（リンク状態）のみ」でしか使用できない機能や設定を使用しているかどうかを判断する。第２に、制作者が主観により設定した優先度を判断する。設定された優先度の数値による判定をする。放送優先にすべきコンテンツとして、例えば、映像・音声との同期など、動作タイミングが重要なＢＭＬコンテンツ、全ての要素を正しく提示することが重要なＢＭＬコンテンツ、画像などのモノメディアを多用したＢＭＬコンテンツがある。
【０１１６】
ステップＳ３３で、各シーンの遷移情報をチェックし、優先度を自動設定する。具体的には、第３の判定基準として、リンクの遷移元、遷移先情報を判断する。そのシーンへ遷移するためのリンクまたはそのシーンから遷移するためのリンクの数を判断する。例えば、あるシーンＡに遷移するためのリンクを持つシーンが多い場合、シーンＡをアクセス頻度の高いシーンと判断し優先度を上げる。また、リンク元とリンク先がいずれも放送側または通信側のどちらかに偏っている場合、同じ方にまとめる。例えば、あるシーンへの遷移元のシーンとそこからの遷移先のシーンの大部分が放送側であった場合、そのシーンが放送専用の機能などを使用していなくても放送側への優先度を高くする。
【０１１７】
シーン遷移のためのリンクの判定情報として、例えば、＜ｓｃｒｉｐｔ＞領域内に記述されたシーン遷移用関数ｌａｕｎｃｈＤｏｃｕｍｅｎｔ（”遷移先シーンのＵＲＩ“）による判定をする。また、＜ａ＞（アンカー）要素内の属性として、ｈｒｅｆ＝”遷移先シーンのＵＲＩ”による判定をする。
【０１１８】
ステップＳ３４で、各シーンのモノメディアファイル使用数をチェックし、優先度を自動設定する。具体的には、第４の判定基準として、モノメディアの使用数を判断する。例えば、シーンで使用されている（参照されている）モノメディア（画像ファイルなど）の数が多いほど放送側への優先度を高くする。
【０１１９】
ステップＳ３５で、優先度の高いものから順に放送側へ振り分ける。ステップＳ３６で、放送側の容量制限を超えているか否かを判断する。具体的には、第５の判定基準として、放送側に送出可能なシーンの容量制限を判断する。例えば、放送コンテンツとしてカルーセル送出することのできる容量制限を考慮する。また、優先度を設定されたシーンを優先度の高い順に放送コンテンツとして割り当てる。
【０１２０】
ステップＳ３６で放送側の容量制限を超えているときは、ステップＳ３７で、残りのシーンは全て通信用として使用可能か否かを判断する。ステップＳ３７で残りのシーンは全て通信用として使用可能のときは、ステップＳ３８で、残りのシーンを通信用として振り分ける。ステップＳ３７で残りのシーンは全て通信用として使用可能でないときは、ステップＳ３９で、放送側の容量オーバーを制作者に警告し、構成の変更を促す。具体的には、放送コンテンツの容量制限を超える場合はシーンを通信コンテンツとして設定する。さらに、放送コンテンツ専用の機能を使用しているコンテンツだけで放送側の容量制限を超えてしまう場合は警告を表示し構成の変更を促す。
【０１２１】
図１５は、優先度に応じたコンテンツの振り分けを示す図である。
図１５において、コンテンツ１５１は、シーン（ページ）１５２から構成され、各シーン１５２−１、１５２−２、１５２−３、１５２−４，１５２−５，１５２−６に対して、リンク数や参照ファイル１５６の有無などにより、優先度１５３が設定される。
【０１２２】
例えば、シーン１５２−１は参照ファイル１５６が設定されているので放送コンテンツ１５４に振り分けられる。シーン１５２−２はリンクもなく参照ファイルもないので通信コンテンツ１５５に振り分けられる。シーン１５２−３はシーン１５２−４からリンクを張られているので放送コンテンツ１５４に振り分けられる。シーン１５２−４はシーン１５２−３およびシーン１５２−６に対してリンクを張ると共にシーン１５２−６からリンクを張られているので優先度１５３は高い優先度１５３−１に設定されて放送コンテンツ１５４に振り分けられる。シーン１５２−５はシーン１５２−４からリンクを張られているので放送コンテンツ１５４に振り分けられる。シーン１５２−６はシーン１５２−４に対してリンクを張っているが、放送コンテンツ１５４の容量を超えているので通信コンテンツ１５５に振り分けられる。
【０１２３】
図１６は、ＸＭＬ形式のＢＣＭＬファイルを示す図である。
図１６において、ＢＣＭＬファイル１６１は、例えば、＜ｂｏｄｙ＞の項の＜ｏｂｊｅｃｔ・・・−ｊｐｅｇ＞欄に記述された“ａａａ（）；”のリンク１６２をクリックすると、リンク先の＜ｈｅａｄ＞の項の＜ｓｃｒｉｐｔ＞欄に記述された〜ｌａｕｎｃｈＤｏｃｕｍｅｎｔ（“遷移先シーンのＵＲＬ”）；で指定されたシーンへ遷移する。
【０１２４】
なお、非リンク状態の通信コンテンツから放送コンテンツへ遷移することはできない。通信コンテンツ（非リンク状態）と確定されたコンテンツから遷移するシーンは放送コンテンツにはしないこととする。
【０１２５】
図１４は、変換処理段階を示すフローチャートである。
ステップＳ３の変換処理段階におけるステップＳ４１の変換処理について説明する。ステップＳ４１の変換処理におけるステップＳ４２で、ファイルの拡張子を対応するものに変更する。具体的には、振り分け後の変換処理段階で、ソフトウェアの振り分け処理により各シーンが放送用か通信用かが決定した後に、以下のような処理を行う。振り分けによってファイルの拡張子を変更する。例えば、放送：＊．ｂｍｌ、通信（リンク状態）：＊．ｌｂｍｌ、通信（非リンク状態）：＊．ｉｂｍｌ、とする。
【０１２６】
ステップＳ４３で、シーンから参照するファイルへのＵＲＬを修正する（スキームおよびファイル拡張子を含む）。具体的には、シーン遷移のＵＲＩの記述を変更する（ファイルの拡張子も含む）。また、モノメディア参照用のＵＲＩの記述を変更する。例えば、放送から通信コンテンツへの遷移時のスキーム：“ｈｔｔｐ：”、”ｈｔｔｐｓ：”、通信（リンク状態）から放送コンテンツへの遷移時のスキーム：”ａｒｉｂ−ｄｃ：”となる。
【０１２７】
ステップＳ４４で、放送用、通信用それぞれの管理ファイルを自動生成する。具体的には、それぞれのＢＭＬファイルおよび番組交換用の管理ファイル（放送側ではＡＲＩＢ準拠のＢＣＭＬファイル、通信側ではサーバの使用にあった管理ファイル）を出力する。
【０１２８】
上述した本発明の実施の形態によれば、ＢＳデジタル／ＣＳ／地上波（放送用、通信用）それぞれに向けたコンテンツを同一ＧＵＩの別モードとして制作することが可能になる。
【０１２９】
同一ＧＵＩの別動作モードを使用して複数モードのコンテンツの制作を可能とすることでモードの区別を意識せずに制作することが出来る。
【０１３０】
放送用コンテンツ特有の概念である時間によるアクセス可否の設定を通信用コンテンツに対しても同様のＧＵＩを用いて設定することが出来る。
【０１３１】
自動的またはユーザーの指示によりあるひとつのモードに指定されたシーンに対する制作を行う時にはＧＵＩ上では該当するモードで設定可能な項目のみ有効となり間違った入力をすることが防止される。規格におけるモードごとの運用規定を完全に習得することは難しいが、これらの機能により正当なコンテンツを制作することを補助する効果がある。
【０１３２】
あるモード向けに制作されたコンテンツをモード変換機能により変換し、変換先のモードの規格にあうように値を変更することで、他のモードにまたがったコンテンツの再利用性が向上する。
【０１３３】
地上波デジタルの放送用と通信用を併用するコンテンツを制作する際に、コンテンツ制作の最終段階で複数の判断基準を用いて各シーンを放送用とするか通信用とするかを自動的に判定する機能により制作途中段階では振り分けを意識する必要がない。
【０１３４】
以上のような効果によりコンテンツ制作者の負担を軽減し制作効率を向上することができる。
【０１３５】
上述した本発明の実施の形態に限らず、本発明の特許請求の範囲を逸脱しない限り、適宜他の構成をとりうることは言うまでもない。
【０１３６】
【発明の効果】
この発明によれば、衛星放送／地上波（放送用、通信用）それぞれに向けたコンテンツを同一のコンテンツ制作装置の別モードとして制作することを可能にすることができるという効果を奏する。
【０１３７】
また、この発明によれば、同一のコンテンツ制作装置の別動作モードを使用して複数モードのコンテンツの制作を可能とすることでモードの区別を意識せずに制作することができる。
【０１３８】
また、この発明によれば、放送用コンテンツ特有の概念である時間によるアクセス可否の設定を通信用コンテンツに対しても同様のコンテンツ制作装置を用いて設定することができる。
【０１３９】
また、この発明によれば、自動的またはユーザーの指示によりあるひとつのモードに指定されたシーンに対する制作を行う時にはコンテンツ制作装置上では該当するモードで設定可能な項目のみ有効となり間違った入力をすることが防止される。放送規格におけるモードごとの運用規定を完全に習得することは難しいが、これらの機能により正当なコンテンツを制作することを補助する効果がある。
【０１４０】
また、この発明によれば、あるモード向けに制作されたコンテンツをモード変換機能により変換し、変換先のモードの規格にあうように値を変更することで、他のモードにまたがったコンテンツの再利用性が向上する。
【０１４１】
また、この発明によれば、地上波デジタルの放送用と通信用を併用するコンテンツを制作する際に、コンテンツ制作の最終段階で複数の判断基準を用いて各シーンを放送用とするか通信用とするかを自動的に判定する機能により制作途中段階では振り分けを意識する必要がない。
以上のような効果によりコンテンツ制作者の負担を軽減し制作効率を向上することができる。
【図面の簡単な説明】
【図１】放送波またはインターネットによるデータ放送コンテンツの放送システムを示す図である。
【図２】放送コンテンツと通信コンテンツの閲覧を示す図である。
【図３】デジタル衛星放送、地上波デジタル放送またはインターネットによるデータ放送コンテンツの放送システムを示す図である。
【図４】モード変更時の表示例を示す図である。
【図５】時間編成ＧＵＩのイメージを示す図である。
【図６】カルーセル伝送されるデータ放送コンテンツの構造を示す図である。
【図７】交換方式において交換されるＢＣＭＬコンテンツのフォルダ構成モデルを示す図である。
【図８】地上波デジタル放送のデータコンテンツの状態を示す図である。
【図９】通信コンテンツのＢａｓｉｃ手順双方向機能の動作を示す図である。
【図１０】通信コンテンツのＴＣＰ／ＩＰ双方向機能の動作を示す図である。
【図１１】放送用コンテンツと通信用コンテンツの自動振り分け（最適化）を示すフローチャートである。
【図１２】制作段階を示すフローチャートである。
【図１３】最適化（自動振り分け）段階を示すフローチャートである。
【図１４】変換処理段階を示すフローチャートである。
【図１５】優先度に応じたコンテンツの振り分けを示す図である。
【図１６】ＸＭＬ形式のＢＣＭＬファイルを示す図である。
【符号の説明】
１……放送局、２……サーバ、２−１，２−２，２−３……通信用コンテンツ、３……放送波、４……データカルーセル、４−１，４−２……放送用コンテンツ、５……視聴者、６……インターネット、２１……ユーザーの閲覧イメージ、２１−１，２１−５……放送用コンテンツ、２１−２，２１−３，２１−４……通信用コンテンツ、３１……放送局、３２……データ放送コンテンツのアップロード、３３……放送衛星、３４……データ放送コンテンツのダウンロード、３５……受信局（一般家庭）、３６……データ放送コンテンツの地上波デジタル放送、３７……インターネット、３８……情報提供システム（ｗｅｂサーバ）、３９……情報提供システム（スタイルシート・サーバ）、４１……ＣＳ用設定、４２……ＢＳ→ＣＳ変更用設定、５１……各シーン、６１，６２……データイベント１（ローカルコンテンツ１），データイベント２（ローカルコンテンツ１）、６３−１￣６３−Ｎ……カルーセル、６５−１￣６５−Ｍ……モジュール、７１……ルートフォルダ、７２−１……ＢＣＭＬファイル、７２−２……データＥＳフォルダ、７３……カルーセルフォルダ、７４−１……モジュールファイル、７４−２……モジュールフォルダ、７５−１……リソースファイル、７５−２……再編集用フォルダ、７６……再編集用フォルダ、７７……シーン、８１……状態名、８２……状態、８３……データコンテンツ（ＢＭＬ）の形式、８４……データ放送受信状態、８５……リンク状態、８６……非リンク状態、９１……放送用拡張関数、９２……データ放送受信状態、９３……リンク状態、９４……非リンク状態、１０１……放送用拡張関数、１０２……データ放送受信状態、１０３……リンク状態、１０４……非リンク状態、１５１……コンテンツ、１５２……シーン（ページ）、１５３……優先度、１５４……放送コンテンツ、１５５……通信コンテンツ、１６１……ＢＣＭＬファイル、１６２……リンク
【図１】
2004304262.tif 000003
【図２】
2004304262.tif 000004
【図３】
2004304262.tif 000005
【図４】
2004304262.tif 000006
【図５】
2004304262.tif 000007
【図６】
2004304262.tif 000008
【図７】
2004304262.tif 000009
【図８】
2004304262.tif 000010
【図９】
2004304262.tif 000011
【図１０】
2004304262.tif 000012
【図１１】
2004304262.tif 000013
【図１２】
2004304262.tif 000014
【図１３】
2004304262.tif 000015
【図１４】
2004304262.tif 000016
【図１５】
2004304262.tif 000017
【図１６】
2004304262.tif 000018