放送通信連携システム、サーバ及びプログラム
【課題】受信機において所望のコンテンツを入手することができること。
【解決手段】受信機４は、サービス毎のサーバ３２１に対してコンテンツをリクエストし、サービス毎のサーバ３２１は、受信機４からのリクエストを受けて、コンテンツ管理・配信サーバ３１１に対して、Ｗｅｂ ＡＰＩで、コンテンツを加工して自機に送信することをリクエストし、コンテンツ管理・配信サーバ３１１は、Ｗｅｂ ＡＰＩでのリクエストに従って、コンテンツを加工して、加工後のコンテンツをサービス毎のサーバ３２１に送信し、サービス毎のサーバ３２１は、コンテンツ管理・配信サーバ３１１から送信されたコンテンツを受信して、受信機４に送信し、受信機４は、サービス毎のサーバ３２１から送信されたコンテンツを受信する。
【解決手段】受信機４は、サービス毎のサーバ３２１に対してコンテンツをリクエストし、サービス毎のサーバ３２１は、受信機４からのリクエストを受けて、コンテンツ管理・配信サーバ３１１に対して、Ｗｅｂ ＡＰＩで、コンテンツを加工して自機に送信することをリクエストし、コンテンツ管理・配信サーバ３１１は、Ｗｅｂ ＡＰＩでのリクエストに従って、コンテンツを加工して、加工後のコンテンツをサービス毎のサーバ３２１に送信し、サービス毎のサーバ３２１は、コンテンツ管理・配信サーバ３１１から送信されたコンテンツを受信して、受信機４に送信し、受信機４は、サービス毎のサーバ３２１から送信されたコンテンツを受信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、放送と通信の連携を図る機能を有する放送通信連携システム、サーバ及びプログラムに関する。
【背景技術】
【０００２】
近年、放送のデジタル化と通信のブロードバンド化の進展に伴い、放送通信連携サービスの実現に向けた研究開発が行われている。
【０００３】
また、この放送通信連携サービスにおいては、放送と通信という異なる伝送路を用いて複数のコンテンツを配信し、デジタルテレビ等の受信機において、配信された複数のコンテンツを統合して提示する形態が想定される。
【０００４】
ところで、現在、データ放送では、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）をベースとした、マルチメディア符号化用に開発されたＢＭＬ（Ｂｒｏａｄｃａｓｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）という放送サービスに必要な機能を拡張した言語を用いて、様々なコンテンツが提供されている（特許文献１を参照）。
【０００５】
例えば、特許文献２によれば、ビデオオンデマンド（Ｖｉｄｅｏ Ｏｎ Ｄｅｍａｎｄ：以下、ＶＯＤという）による、過去に放送されたコンテンツが提供可能になっている。この場合のコンテンツの伝送方法は、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）に準拠した方法が用いられている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００３−６０９３１号公報
【特許文献２】特開２００９−２４６８１５号公報
【非特許文献】
【０００７】
【非特許文献１】「デジタル放送におけるアプリケーション実行環境 標準規格 ＡＲＩＢ ＳＴＤ−Ｂ２３ １．２版」 第二部１０．１６，平成２１年７月２９日策定，社団法人 電波産業会
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ところで、データ放送では、全ての情報を放送波に多重化させる必要があるため、放送波で送信可能なデータ容量に一定の制限がある。
【０００９】
このような状況の下、送信可能なデータの容量に制限のない通信を、放送と連携させるシステムの実現が要求されている。
【００１０】
このようなシステムでは、受信機等の受信側が、保存元のコンテンツそのものではなく、何らかの加工が施されたコンテンツを要求する場合が想定される。しかしながら、上述のＦＴＰを採用しても、保存元のコンテンツそのものが単に伝送されるだけであり、このような要求に応えることができない。
【００１１】
本発明は、このような状況に鑑みてなされたものであり、放送と通信の連携を図るシステムにおいて、受信側で要求される形態でのコンテンツの伝送を実現することを一つの目的とする。
【課題を解決するための手段】
【００１２】
本発明に係る放送通信連携システムは、放送局と、前記放送局により管理される第１サーバと、前記第１サーバと通信する第２サーバと、前記第２サーバと通信すると共に前記放送局から放送された放送信号を受信する受信機と、を備える放送通信連携システムであって、前記受信機は、前記第２サーバに対してコンテンツをリクエストし、前記第２サーバは、前記受信機からの前記リクエストを受けて、前記第１サーバに対して、Ｗｅｂ ＡＰＩで、前記コンテンツを加工して自機に送信することをリクエストし、前記第１サーバは、Ｗｅｂ ＡＰＩでの前記リクエストに従って、前記コンテンツを加工して、加工後の前記コンテンツを前記第２サーバに送信し、前記第２サーバは、前記第１サーバから送信された前記コンテンツを受信して、前記受信機に送信し、前記受信機は、前記第２サーバ群から送信された前記コンテンツを受信する構成とした。
【００１３】
かかる構成によれば、第２サーバでは、第１サーバからのＷｅｂ ＡＰＩでのリクエストに従って、コンテンツが加工されて、加工後のコンテンツが第１サーバに送信されるので、受信側で要求される形態でのコンテンツの伝送を実現することができる。
【００１４】
また、放送通信連携システムでは、前記第２サーバは、前記第１サーバから受信した前記コンテンツをさらに加工して、加工後の前記コンテンツを前記受信機に送信するようにしてもよい。
【００１５】
かかる構成によれば、第１のサーバに加えて、第２のサーバでもコンテンツをさらに加工するので、受信側でのより高度な要求にも容易に応えることができる。
【００１６】
また、本発明に係る第１のサーバは、放送局と、サーバ群と、前記サーバ群と通信すると共に前記放送局から放送された放送信号を受信する受信機と、を備える放送通信連携システムにおけるサーバであって、前記受信機からのコンテンツのリクエストを受信する第１通信手段と、前記第１通信手段に受信された前記リクエストに従って、前記放送局により管理される別サーバに対するリクエストであって、前記コンテンツを加工して自機に送信させるリクエストをＷｅｂ ＡＰＩで生成する生成手段と、前記生成手段により前記Ｗｅｂ ＡＰＩで生成された前記リクエストを前記別サーバに送信する第２通信手段と、を備え、前記別サーバにおいて、前記Ｗｅｂ ＡＰＩによるリクエストに従って、前記コンテンツが加工されて送信されてきた場合、前記第２通信手段は前記コンテンツを受信し、前記第１通信手段は前記コンテンツを前記受信機に送信する構成とした。
【００１７】
かかる構成によれば、第１のサーバが別サーバに対してＷｅｂ ＡＰＩでのリクエストをすると、別サーバでは、第１のサーバからのＷｅｂ ＡＰＩでのリクエストに従って、コンテンツが加工されて、加工後のコンテンツが第１のサーバに送信されるので、受信機側で要求される形態でのコンテンツの伝送を実現することができる。
【００１８】
また、上記第１のサーバは、前記別サーバから受信した前記コンテンツを加工する加工手段をさらに備え、前記第１通信手段は、前記加工手段による加工後の前記コンテンツを、前記受信機に送信することが好ましい。
【００１９】
かかる構成によれば、別サーバに加えて、第１のサーバでもコンテンツをさらに加工するので、受信側でのより高度な要求にも容易に応えることができる。
【００２０】
また、本発明に係る第１のプログラムは、放送局と、サーバ群と、前記サーバ群と通信すると共に前記放送局から放送された放送信号を受信する受信機と、を備える放送通信連携システムにおけるサーバを制御するコンピュータを、前記受信機からのコンテンツのリクエストを前記サーバに受信させる制御を実行する第１通信制御手段、前記第１通信制御手段の制御により前記サーバに受信された前記リクエストに従って、前記放送局により管理される別サーバに対するリクエストであって、前記コンテンツを加工して自機に送信させるリクエストをＷｅｂ ＡＰＩで生成する生成手段、前記生成手段により前記Ｗｅｂ ＡＰＩで生成された前記リクエストを前記サーバから前記別サーバに送信させる制御を実行する第２通信制御手段、として機能させ、前記別サーバにおいて、前記Ｗｅｂ ＡＰＩによるリクエストに従って、前記コンテンツが加工されて送信されてきた場合、前記第２通信制御手段として機能するコンピュータは、前記コンテンツを前記サーバに受信させる制御を実行し、前記第１通信制御手段として機能するコンピュータは、前記コンテンツを前記サーバから前記受信機に送信させる制御を実行するように構成した。
【００２１】
かかる構成によれば、かかる構成によれば、サーバが別サーバに対してＷｅｂ ＡＰＩでのリクエストをすると、別サーバでは、サーバからのＷｅｂ ＡＰＩでのリクエストに従って、コンテンツが加工されて、加工後のコンテンツがサーバに送信されるので、受信機側で要求される形態でのコンテンの伝送を実現することができる。
【００２２】
また、本発明に係る第２のサーバは、放送局と、サーバ群と、前記サーバ群と通信すると共に前記放送局から放送された放送信号を受信する受信機と、を備える放送通信連携システムにおけるサーバであって、別サーバにおいて、前記受信機からのコンテンツのリクエストに従って、自機に対するリクエストであって、前記コンテンツを加工して前記別サーバに送信させるリクエストがＷｅｂ ＡＰＩで生成されて、送信されてきた場合、前記リクエストを解析して処理するＡＰＩと、前記ＡＰＩにより解析された前記リクエストに従って、前記コンテンツを加工する加工手段と、前記ＡＰＩにより解析された前記リクエストに従って、前記加工手段により加工された前記コンテンツを、前記ＡＰＩを介して前記別サーバに配信する配信管理手段と、を備えるように構成した。
【００２３】
かかる構成によれば、第２のサーバでは、別サーバからのＷｅｂ ＡＰＩでのリクエストに従って、コンテンツが加工されて、加工後のコンテンツが別サーバに送信されるので、受信側で要求される形態でのコンテンの伝送を実現することができる。
【００２４】
また、第２の本発明に係るプログラムは、放送局と、サーバ群と、前記サーバ群と通信すると共に前記放送局から放送された放送信号を受信する受信機と、を備える放送通信連携システムにおけるサーバを制御するコンピュータを、別サーバにおいて、前記受信機からのコンテンツのリクエストに従って、自機に対するリクエストであって、前記コンテンツを加工して前記別サーバに送信させるリクエストがＷｅｂ ＡＰＩで生成されて、送信されてきた場合、前記リクエストを解析して処理させる制御を実行するＡＰＩ手段、前記ＡＰＩにより解析された前記リクエストに従って、前記コンテンツを加工する加工手段、前記ＡＰＩにより解析された前記リクエストに従って、前記加工手段により加工された前記コンテンツを、前記ＡＰＩを介して前記別サーバに配信させる制御を実行する配信管理手段、として機能させるように構成した。
【００２５】
かかる構成によれば、サーバでは、別サーバからのＷｅｂ ＡＰＩでのリクエストに従って、コンテンツが加工されて、加工後のコンテンツが別サーバに送信されるので、受信側で要求される形態でのコンテンの伝送を実現することができる。
【発明の効果】
【００２６】
本発明によれば、受信機において所望のコンテンツを入手することができる。
【図面の簡単な説明】
【００２７】
【図１】放送通信連携システムの全体構成図である。
【図２】デジタル放送に係る放送信号の伝送プロトコルのスタックを示す図である。
【図３】受信機の機能構成を示すブロック図である。
【図４】ＸＭＬ形式で記述されたＡＩＴの一例を示す図である。
【図５】サーバ群を放送局サーバ群とサービス事業者サーバ群とに区別した場合における、放送通信連携システムの機能構成を示すブロック図である。
【図６】コンテンツ配信処理を実行するためのサーバ群の機能的構成を示す機能ブロック図である。
【図７】コンテンツ配信処理の流れを示すアローチャートである。
【発明を実施するための形態】
【００２８】
以下、本発明の実施の形態について図面を参照して説明する。
図１は、本発明の一実施形態に係る放送通信連携システム１００の全体構成図である。放送通信連携システム１００は、放送局１と、放送用アンテナ２と、サーバ群３と、受信機４とを含んで構成される。
この放送通信連携システム１００では、受信機４において、ＩＳＤＢ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｂｒｏａｄｃａｓｔｉｎｇ：統合デジタル放送サービス）方式によって放送局１から提供される放送サービスと、インターネット等により構成される通信ネットワークＮを介してサーバ３から提供される通信サービスとが連携される。これにより、放送通信連携サービスが、受信機４のユーザに提供される。
本実施形態では、放送通信連携システム１００は、Ｈｙｂｒｉｄｃａｓｔ（登録商標）システムであるものとする。Ｈｙｂｒｉｄｃａｓｔとは、同報性、高品質、高信頼という放送の特徴と、視聴者の個別の要求に応えることができるという通信の特徴とを生かしたシステムを構築するための仕組みである。Ｈｙｂｒｉｄｃａｓｔシステムは、放送サービスを中心に置きながら、通信の活用によってサービスを強化するという観点で、放送と通信のハイブリッドサービスを実現することができる。
【００２９】
放送局１は、番組編成設備と、番組送出設備と、送信設備とを含んで構成される一般的なデジタル放送用の放送設備（図示省略）を備える。
放送局１は、放送設備によって、コンテンツや、イベント情報（Ｅｖｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ：ＥＩＴ）や、ＡＩＴ（以下、アプリケーション管理情報とも適宜呼ぶ）等を制作する。そして、放送局１は、放送設備によって、これらコンテンツ、イベント情報及びＡＩＴ等を多重化した放送信号を生成し、当該放送信号を放送波に変調して放送用アンテナ２から送信する。
【００３０】
このような放送波に含まれるコンテンツとしては、放送スケジュールに従って放送される番組を構成する映像や音声の各データを含むコンテンツ（以下、番組コンテンツと呼ぶ）の他、番組コンテンツとは非同期に発生するコンテンツ、例えば緊急地震速報等を含むコンテンツ（以下、緊急コンテンツと呼ぶ）も存在する。
【００３１】
イベント情報は、番組コンテンツの名称、番組コンテンツの放送日時、番組コンテンツの説明等、コンテンツに関するメタ情報を含む。以下、テーブル形式のイベント情報をＥＩＴと呼ぶ。
ＡＩＴ（アプリケーション管理情報）は、受信機４で実行可能な１以上のアプリケーションを管理するための情報である。ＡＩＴには、１以上のアプリケーションのそれぞれに対応し、当該１以上のアプリケーションのそれぞれを管理するための個別管理情報が含まれる。個別管理情報には、管理対象のアプリケーションを識別するアプリケーションＩＤ、当該アプリケーションのライフサイクルを制御するライフサイクル制御情報、当該アプリケーションの所在を示すロケーション情報等が含まれている（後述の図４参照）。
【００３２】
アプリケーションにより受信機４に提供されるコンテンツには、番組コンテンツに連動するコンテンツ及び番組コンテンツに連動しないコンテンツが含まれる。以下、アプリケーションにより提供されるコンテンツをアプリ用コンテンツという。
【００３３】
放送信号は、従来のデジタル放送の放送信号と同一であり、ＡＲＩＢ（登録商標）（Ａｓｓｏｃｉａｔｉｏｎ ｏｆ Ｒａｄｉｏ Ｉｎｄｕｓｔｒｉｅｓ ａｎｄ Ｂｒｏａｄｃａｓｔ：社団法人電波産業会）標準規格で規定される。
【００３４】
図２は、デジタル放送に係る放送信号の伝送プロトコルのスタックを示す図である。図２に示すように、デジタル放送によって提供される映像、音声等の各種データは、国際標準規格ＭＰＥＧ−２ Ｓｙｓｔｅｍｓで規定されるＴＳパケット（トランスポートストリームパケット）に格納されて、時分割で多重伝送される。
【００３５】
ＴＳパケットには、図２に示すように、セクション（Ｓｅｃｔｉｏｎ）に対してＰＳＩ（Ｐｒｏｇｒａｍ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎ）／ＳＩ（Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ）が規定されている。ＰＳＩ／ＳＩには、ＴＳパケットに格納されているデータの種別を示す情報や、コンテンツの種別を示す情報が含まれている。上述のＥＩＴは、ＳＩに含まれている。
【００３６】
ＴＳパケットによるデータ伝送は、セクションを用いてデータを伝送する方式とＰＥＳ（Ｐａｃｋｅｔｉｚｅｄ Ｅｌｅｍｅｎｔａｒｙ Ｓｔｒｅａｍ）パケットを用いてデータを伝送する方式（データストリーム伝送方式）とに分類される。
【００３７】
セクションを用いてデータを伝送する方式には、データカルーセル伝送方式と、イベントメッセージ伝送方式がある。
【００３８】
データカルーセル伝送方式は、１以上のデータを一定周期で繰り返し伝送する伝送方式である。データカルーセル伝送方式によって伝送される個々のデータ（モジュール）には、それらを一意に識別するための識別情報が付されている。データカルーセル伝送方式は、受信機４側に個々のデータを任意のタイミングで取得させるために用いられる。
【００３９】
イベントメッセージ伝送方式は、放送局１から受信機４に対して、トリガ信号を送るための方式である。イベントメッセージ伝送方式は、データ量が少ないメッセージを放送局１から受信機４に伝送する場合に用いられる。
【００４０】
データストリーム伝送方式は、伝送するデータをＰＥＳパケットに収容してストリームとして伝送する伝送方式である。データストリーム伝送方式は、映像、音声、字幕データ等のリアルタイム型のデータや、他のストリームとの同期を要するデータの伝送に用いられる。
【００４１】
ここで、ＡＩＴは、ＴＳパケットを用いて様々な方法によって伝送可能である。
すなわち、ＡＩＴは、ＴＳパケットのＳＩに含まれるＥＩＴに対して記述することによって伝送可能である。
【００４２】
また、ＡＩＴは、セクションを用いてデータカルーセル伝送方式により伝送可能である。ＡＩＴをデータカルーセル伝送方式により伝送する場合、受信機４側でＡＩＴであることを認識できるようにモジュールに対して識別情報が付される。
【００４３】
また、ＡＩＴは、ＰＥＳとしてコンテンツの映像や音声に多重させて伝送可能である。
【００４４】
また、ＡＩＴは、バイナリ表現又はＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）によるテキスト表現で記述して、ＴＳパケットに格納することができる。
本実施形態では、ＡＩＴの伝送方法は、上記の伝送方法の少なくともいずれかに予め規定されているものとする。
【００４５】
なお、ＸＭＬをベースとした、マルチメディア符号化用に開発されたＢＭＬは、Ｗ３Ｃ（登録商標）（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ）が定義したｘＨＴＭＬを基礎とし、手続き型言語にはＪａｖａＳｃｒｉｐｔ（登録商標）を基礎としたＥＣＭＡＳｃｒｉｐｔを用いて国際標準との整合性を考慮して定義された規格である。
【００４６】
サーバ群３は、インターネット等のネットワークを介する通信により、他のサーバや受信機４等と各種情報を送受信することができる。サーバ群の詳細については、図５を参照して後述する。
【００４７】
受信機４は、放送局１からの放送又はサーバ群３との通信を介して受信する番組コンテンツに対して所定の処理を行うことにより、番組コンテンツを構成する映像や音声を同期して出力する。また、受信機４は、ＡＩＴに基づいて、アプリケーションを適宜取得し、取得したアプリケーションを起動して実行する。また例えば、受信機４は、実行されているアプリケーションによってサーバ群３からアプリ用コンテンツを取得し、番組コンテンツに連携させて出力することも可能である。なお、アプリ用コンテンツの出力は、必ずしも番組コンテンツに連携させる必要はない。
以下、このような受信機４の機能について詳述する。
【００４８】
図３は、受信機４の機能構成を示すブロック図である。
受信機４は、放送波受信部１１と、第１分離部１２と、放送ＡＩＴ取得部１３と、通信部１４と、第２分離部１５と、通信ＡＩＴ取得部１６と、アプリケーション実行制御部１７と、音声制御部１８と、表示制御部１９と、スピーカ２０と、ディスプレイ２１と、メモリ２２と、ＡＩＴ記憶部２３とを備える。
【００４９】
放送波受信部１１は、放送用アンテナ２を介して放送局１から送信されてくる放送波を受信する。
【００５０】
第１分離部１２は、放送波受信部１１に受信された放送波を復調することによって、放送信号、すなわちＴＳパケットを抽出する。そして、第１分離部１２は、ＴＳパケットのＰＳＩ／ＳＩを参照して、ＴＳパケットに含まれているデータの種別を判別し、映像、音声、ＥＩＴ等の各種データを分離して抽出する。また、第１分離部１２は、予め規定されているＡＩＴの伝送方法に応じて、セクションやＰＥＳを参照してＡＩＴを分離して抽出する。
【００５１】
続いて、第１分離部１２は、ＴＳパケットのＰＥＳに含まれているデータが音声データである場合、この音声データを音声制御部１８に出力する。また、第１分離部１２は、ＴＳパケットのＰＥＳに含まれているデータが映像データである場合、この映像データを表示制御部１９に出力する。
【００５２】
また、第１分離部１２は、抽出したＥＩＴやその他の各種データをメモリ２２に記憶させる。また、第１分離部１２は、ＡＩＴを抽出した場合、抽出したＡＩＴを放送ＡＩＴ取得部１３に出力する。
【００５３】
放送ＡＩＴ取得部１３は、第１分離部１２から出力されたＡＩＴを取得し、ＡＩＴ記憶部２３に記憶させる。
【００５４】
通信部１４は、通信ネットワークＮを介するサーバ群３との間で各種情報を送受信したり、リモートコントローラＲ（以下、リモコンＲと略記する）からの操作信号を受信する。
【００５５】
第２分離部１５は、サーバ群３から通信ネットワークＮを介して送信されてきて通信部１４に受信されたデータの種別を判別し、その判別結果に基づいてデータの出力先を分離する。例えば、第２分離部１５は、受信したデータがＡＩＴであると判別した場合、このＡＩＴを通信ＡＩＴ取得部１６に出力する。また、第２分離部１５は、受信したデータがアプリケーションであると判別した場合、このアプリケーションをアプリケーション実行制御部１７に出力する。
【００５６】
また、第２分離部１５は、受信したデータがＴＳパケットであると判別した場合、映像、音声、ＡＩＴ等の各種データをＴＳパケットから分離して抽出する。そして、第２分離部１５は、ＡＩＴを抽出した場合、このＡＩＴを通信ＡＩＴ取得部１６に出力し、ＡＩＴ以外のデータを抽出した場合、このデータをアプリケーション実行制御部１７に出力する。
【００５７】
通信ＡＩＴ取得部１６は、第２分離部１５から出力されたＡＩＴを取得し、ＡＩＴ記憶部２３に記憶させる。
【００５８】
アプリケーション実行制御部１７は、ＡＩＴに基づいてアプリケーションを取得し、取得したアプリケーションの起動及び実行を制御する。
【００５９】
ここで、アプリケーション実行制御部１７により実行が制御されるアプリケーションの管理用のＡＩＴの構造の例を詳細に説明する。
図４は、ＸＭＬ形式で記述されたＡＩＴの構造の一例を示す図である。
上述したように、ＡＩＴには、１以上のアプリケーションそれぞれに対応し、１以上のアプリケーションそれぞれを管理するための個別管理情報がそれぞれ含まれる。
具体的には、図４に示される＜ｍｈｐ：Ａｐｐｌｉｃａｔｉｏｎ＞タグから＜／ｍｈｐ：Ａｐｐｌｉｃａｔｉｏｎ＞タグまでに記述されているコードは、一のアプリケーションを管理するための個別管理情報に対応している。ＡＩＴには、＜／ｍｈｐ：Ａｐｐｌｉｃａｔｉｏｎ＞タグの後に、他のアプリケーションの個別管理情報を新たに記述することによって、複数の個別管理情報を記述することができる。
【００６０】
また、個別管理情報に対応するコードのうち、例えば、＜ｍｈｐ：ａｐｐＩｄ＞タグに対応するコードは、アプリケーションのＩＤ（識別情報）を示している。また、＜ｍｈｐ：ｃｏｎｔｒｏｌＣｏｄｅ ｍｈｐ：ｔｙｐｅ＝“ＡＲＩＢ−Ｊ”＞タグに対応するコードは、このアプリケーションのライフサイクル制御情報を示しており、図４に示す「ＡＵＴＯＳＴＡＲＴ」は、受信機４によってアプリケーションを自動実行させるライフサイクル制御情報である。また、＜ｍｈｐ：ｌｏｃａｔｉｏｎ＞タグに対応するコードは、このアプリケーションの所在を示すロケーション情報を示している。図４の例では、ロケーション情報には、アプリケーションの所在として、サービスサーバ３のアドレスが記述されている。
なお、ロケーション情報には、アプリケーションの所在として、受信機４を指定することもできる。
【００６１】
アプリケーション実行制御部１７は、ＡＩＴ記憶部２３を監視し、新たにＡＩＴが記憶された場合に、このＡＩＴに記述されているライフサイクルに係る制御情報を参照する。そして、アプリケーション実行制御部１７は、ライフサイクルに係る制御情報が「自動実行」を示すものである場合、ＡＩＴに記述されているロケーション情報をアプリケーションの取得先として認識する。例えば取得先がサーバ群３であった場合には、アプリケーション実行制御部１７は、通信部１４及び第２分離部１５を介してサーバ群３からアプリケーションを取得し、取得したアプリケーションを起動して実行する。この場合、アプリケーションは、受信機４のユーザから明示的な操作指示を受けることなく自動的に実行される。
【００６２】
また、アプリケーション実行制御部１７は、受信機４のユーザからリモコンＲを介してアプリケーションの実行指示を受け付ける。例えば、リモコンＲには、Ｈｙｂｒｉｄｃａｓｔ（登録商標）ボタンが設けられており、アプリケーション実行制御部１７は、受信機４のユーザによってＨｙｂｒｉｄｃａｓｔボタンが押下されたことに応じて、実行するアプリケーションの選択を受け付けるためのメニュー画面の実行指示を受け付ける。アプリケーション実行制御部１７は、メニュー画面の実行指示を受け付けたことに応じて、ＡＩＴ記憶部２３を参照し、実行可能なアプリケーションのＡＩＴを特定する。そして、アプリケーション実行制御部１７は、特定したＡＩＴに対応するアプリケーションを選択可能なメニューの画像データを生成して、当該画像データを表示制御部１９に出力することで、このメニューをディスプレイ２１に表示させる。受信機４のユーザからリモコンＲを介してアプリケーションの選択操作を受け付けた場合、アプリケーション実行制御部１７は、ＡＩＴに記述された当該アプリケーションのロケーション情報を参照してアプリケーションを取得し、アプリケーションを起動して実行する。
【００６３】
アプリケーション実行制御部１７は、必要に応じて、実行中のアプリケーションに関するアプリ用コンテンツをサービスサーバ３から取得する。そして、アプリケーション実行制御部１７は、アプリ用コンテンツのうち、音声のデータを音声制御部１８に、映像のデータを表示制御部１９に、それぞれ出力する。ここで、実行中のアプリケーションが、番組コンテンツに連動するアプリ用コンテンツを提供するアプリケーションである場合には、アプリ用コンテンツの映像データ及び音声データが番組コンテンツの映像データ及び音声データに連動して出力される。
【００６４】
また、アプリケーション実行制御部１７は、ＡＩＴ記憶部２３に記憶されたＡＩＴに基づいて、具体的には当該ＡＩＴのうち個別管理情報に含まれるライフサイクル制御情報に基づいて、実行中のアプリケーションのライフサイクルを制御する。例えば、アプリケーション実行制御部１７は、アプリケーションのライフサイクル制御情報が「終了」を示すものであるとき、アプリケーションを終了させる。
【００６５】
音声制御部１８は、第１分離部１２から出力された音声のデータを、表示制御部１９により表示が制御される映像のデータと同期をとりながらスピーカ２０に出力する。また、音声制御部１８は、アプリケーション実行制御部１７から出力された音声のデータが表示制御部１９により表示が制御される映像のデータと同期可能である場合、この映像のデータと同期をとりながら音声のデータをスピーカ２０に出力する。
【００６６】
表示制御部１９は、第１分離部１２から出力されたデータに対応する映像を、音声制御部１８により出力制御される音声のデータと同期をとりながらディスプレイ２１に表示させる。また、表示制御部１９は、アプリケーション実行制御部１７から出力された映像のデータが音声制御部１８により出力制御される音声のデータと同期可能である場合、この音声のデータと同期をとりながら当該映像をディスプレイ２１に表示させる。
【００６７】
スピーカ２０は、音声制御部１８から出力されたデータに基づいて、当該データに対応する音声を出力する。ディスプレイ２１は、表示制御部１９から出力されたデータに基づいて、当該データに対応する映像を表示する。
【００６８】
メモリ２２は、ＥＩＴ等の番組コンテンツのメタ情報や、緊急コンテンツに含まれる緊急地震速報等、その他各種情報を記憶する。
ＡＩＴ記憶部２３は、放送ＡＩＴ取得部１３又は通信ＡＩＴ取得部１６によって取得された各種ＡＩＴを記憶する。
【００６９】
さらに以下、サーバ群３の詳細も含め、放送通信連携システム１００の機能構成について説明する。
図５は、サーバ群３を放送局サーバ群３１とサービス事業者サーバ群３２とに区別した場合における、放送通信連携システム１００の機能構成を示すブロック図である。
【００７０】
図１のサーバ群３は、図５に示すように、放送局により管理される放送局サーバ群３１と、各種サービスを提供するサービス事業者により管理されるサービス事業者サーバ群３２とに大別される。
【００７１】
放送局サーバ群３１は、コンテンツ管理・配信サーバ３１１と、放送局サービスサーバ３１２と、ＡＰＩ３１３とを備える。
【００７２】
コンテンツ管理・配信サーバ３１１は、各種番組コンテンツや、これらの番組コンテンツに関するメタデータを管理し、必要に応じて、サービス事業者サーバ群３２に配信する。ここで、メタデータには、番組タイトル、番組ＩＤ、番組概要、番組出演者、放送日時、台本、字幕、解説等の各種情報が含まれる。
【００７３】
放送局サービスサーバ３１２は、サービス事業者に対して各種のサービス、例えば、放送局１が運営するソーシャルネットサービス、放送局１が運営する放送番組毎のブログサービス等を提供するサーバである。
【００７４】
ＡＰＩ３１３は、サービス事業者サーバ群３２からの要求に応じて、放送局サーバ群３１からデータを提供するためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）である。ＡＰＩのデータフォーマットは、放送局とサービス事業者間（Ｂ to Ｂ）の合意により決められる。本実施形態では、ＡＰＩのデータフォーマットは、後述するＷｅｂ ＡＰＩを用いる。
【００７５】
サービス事業者サーバ群３２は、サービス毎のサーバ３２１と、管理・配信サーバ３２２とを備える。
【００７６】
サービス毎のサーバ３２１は、その名の如くサービス事業者が受信機４（そのユーザ）に対して各種サービスを提供するために１つずつ設けられるサーバである。サービス毎のサーバ３２１は、サービスに必要なコンテンツ（受信機４側でいうアプリ用コンテンツ）を、通信により受信機４に提供する。
【００７７】
管理・配信サーバ３２２は、サービスに必要な各種アプリケーションを管理し、通信による受信機４からのリクエストに応じて、アプリケーションを通信により受信機４に提供する。
【００７８】
受信機４は、ＡＰＩを備える。ＡＰＩは、受信機に依存することなく、アプリの動作が同様になるようにするために規定される。なお、アプリケーションは、ＡＰＩを介さずに受信機４の固有機能にアクセスすることができない仕様となっている。
また、受信機４は、Ｈｙｂｒｉｄｃａｓｔ機能と、基本機能とを有している。
Ｈｙｂｒｉｄｃａｓｔ機能とは、Ｈｙｂｒｉｄｃａｓｔのサービスを実現するために必要な機能である。Ｈｙｂｒｉｄｃａｓｔ機能には、ＡＩＴ等によるアプリケーションの制御、描画制御、同期制御、セキュリティ等の各種機能が含まれる。
基本機能には、現行方式の放送（地上デジタル放送、ＢＳデジタル放送、データ放送）が受信でき表示できる機能と、インターネットに接続することができる機能とが含まれる。
【００７９】
以上のように構成される放送通信連携システム１００では、サービス毎のサーバ３２１は、コンテンツの配信のリクエストが受信機４からなされると、そのリクエストに従ってコンテンツを受信機４に配信する。ここで、リクエストされたコンテンツが放送局サーバ群３１に存在する場合、サービス毎のサーバ３２１は、放送局サーバ群３１に対してコンテンツの配信のリクエストをする。この場合、放送局サーバ群３１は、そのリクエストに従ってコンテンツをサービス毎のサーバ３２１に配信する。サービス毎のサーバ３２１は、このような放送局サーバ群３１から配信されたコンテンツを受信すると、当該コンテンツを受信機４に配信する。
このように、受信機４、サービス毎のサーバ３２１、及び放送局サーバ群３１において、受信機４のリクエストに応じて、コンテンツが受信機４に配信されるまでの一連の処理が実行される。このような一連の処理を、以下、コンテンツ配信処理と呼ぶ。
【００８０】
図６は、このようなコンテンツ配信処理を実行するためのサーバ群の機能的構成を示す機能ブロック図である。
【００８１】
放送通信連携システム１００においては、コンテンツ配信処理が実行される場合、受信機４と、サービス毎のサーバ群３２１と、放送局サーバ群３１におけるコンテンツ管理・配信サーバ３１１及びＡＰＩ３１３とが機能する。
【００８２】
受信機４は、サービス毎のサーバ３２１に対して、所定のコンテンツの配信のリクエスト（以下、コンテンツリクエストと呼ぶ）をし、その後、サービス毎のサーバ３２１から送信されてくるコンテンツを受信する。
【００８３】
サービス毎のサーバ３２１においては、コンテンツ配信処理が実行される場合、第１通信部３２１１と、コンテンツ記憶部３２１２と、コンテンツ配信管理部３２１３と、コンテンツ要求生成部３２１４と、第２通信部３２１５と、加工部３２１６とが機能する。
【００８４】
第１通信部３２１１は、受信機４と通信により各種情報を送受信する。例えば、第１通信部３２１１は、受信機４からのコンテンツリクエストを受信する。
【００８５】
コンテンツ記憶部３２１２は、サービス事業者側で生成されたコンテンツを、第２コンテンツとして記憶する。
【００８６】
コンテンツ配信管理部３２１３は、第１通信部３２１１に受信されたコンテンツリクエストに基づいて、受信機４にコンテンツを配信するまでの処理を管理する。
【００８７】
例えば、コンテンツリクエストで求められているコンテンツの全てが、自機内のコンテンツ記憶部３２１２に記憶されている場合、コンテンツ配信管理部３２１３は、当該コンテンツ記憶部３２１２からコンテンツを取得して、当該コンテンツを第１通信部３２１１を介して受信機４に配信する。
【００８８】
これに対して、例えば、コンテンツリクエストで求められているコンテンツの少なくとも一部が、放送局サーバ群３１に記憶されている場合、コンテンツ配信管理部３２１３は、放送局サーバ群３１に対するコンテンツリクエストの生成指示を、後述のコンテンツ要求生成部３２１４に対して行う。
この指示を受けてコンテンツ要求生成部３２１４によりコンテンツリクエストが生成されて、後述の第２通信部３２１５から放送局サーバ群３１に送信される。そのコンテンツリクエストを受けて、放送局サーバ群３１からコンテンツが送信されてくると、コンテンツ配信管理部３２１３は、当該コンテンツを第２通信部３２１５を介して受信する。
そして、コンテンツ配信管理部３２１３は、当該コンテンツを第１通信部３２１１を介して受信機４に配信する。
【００８９】
なお、以下、放送局サーバ群３１に記憶されているコンテンツを、第１コンテンツと呼び、サーバ毎のサーバ３２のコンテンツ記憶部３２１２に記憶されているコンテンツを、第２コンテンツと呼ぶ。
ここで、受信機４からのコンテンツリクエストによって、第１コンテンツと第２コンテンツとの合成（単なる加算や合体も合成に含む）が求められる場合がある。
このような場合には、コンテンツ配信管理部３２１３は、第１コンテンツと第２コンテンツとの各々を個別に取得した後、これらの第１コンテンツと第２コンテンツとを合成する。合成後のコンテンツを、以下、合成コンテンツと呼ぶ。
そして、コンテンツ配信管理部３２１３は、当該合成コンテンツを第１通信部３２１１を介して受信機４に配信する。
【００９０】
コンテンツ要求生成部３２１４は、コンテンツ配信管理部３２１３の指示を受けると、受信機４からのコンテンツリクエストに基づいて、Ｗｅｂ ＡＰＩに準拠したコンテンツリクエストを生成する。
【００９１】
ここで、Ｗｅｂ ＡＰＩとは、ＨＴＴＰを利用してネットワーク越しに処理を実行して結果を受け取る仕組みである。本実施形態においては、Ｗｅｂ ＡＰＩのうち、ＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）のソフトウェアアーキテクチャのスタイルが採用されている。
ＲＥＳＴでは、以下のコマンドフォーマットがＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）形式で提供される。
http://○○○．org/｛サーバ名｝/｛パラメータ１｝/｛パラメータ２｝/・・・
このような形式のＲＥＳＴは、先頭のＵＲＬでサーバ等のコンテンツの場所が特定可能であるという特徴に加えて、パラメータ１，２・・・によって各種各様のパラメータを指定することができるという特徴を有する。
このパラメータ１，２・・・には、任意のパラメータを指定することが可能であり、単純にコンテンツの取得を示すパラメータのみならず、コンテンツの加工を指示したり、その加工方法を指定するパラメータを指定することができる。
例えば、とあるドラマ番組に対する多数のユーザのレビューを含むオリジナルコンテンツが放送局サーバ群３に記憶されている場合には、当該オリジナルコンテンツから、ドラマ番組の出演者の１人である役者に対して、好意的なレビューだけを抽出したものを第１コンテンツとして配信してもらうといった指示内容を、各種パラメータで指定することが可能になる。
即ち、コンテンツ要求生成部３２１４は、第１通信部３２１１に受信されたコンテンツリクエストに従って、例えば、放送局サーバ群３１に対するコンテンツリクエストであって、第１コンテンツを加工して自機に送信させるコンテンツリクエストをＷｅｂ ＡＰＩで生成することができる。
【００９２】
第２通信部３２１５は、コンテンツ要求生成部３２１４により生成されたコンテンツリクエストを放送局サーバ群３１（詳細には、後述するＡＰＩ３１３）に送信する。このコンテンツリクエストを受けて放送局サーバ群３１から第１コンテンツが送信されてくると、第２通信部３２１５は、当該第１コンテンツを受信して、コンテンツ配信管理部３２１３に供給する。
【００９３】
加工部３２１６は、コンテンツ配信管理部３２１３の指示に基づいて、第２コンテンツをコンテンツ記憶部３２１２から取得して加工する。ここで、加工とは、単なる加算や合体の他、減算や抽出、編集、フォーマットやデータ形式の変更、圧縮／復号、符号化／復号、その他、元のデータと少なくとも一部が同一ではないデータを生成することを意味する。
【００９４】
このような機能的構成のサービス毎のサーバ３２１に対して、コンテンツ配信処理が実行される場合、サービスサーバ群３では、コンテンツ管理・配信サーバ３１１と、ＡＰＩ３１３とが機能する。詳細には、コンテンツ管理・配信サーバ３１１においては、コンテンツ配信管理部３１１１と、コンテンツ記憶部３１１２と、加工部３１１３とが機能する。
【００９５】
ＡＰＩ３１３は、サービス毎のサーバ３２１からコンテンツリクエストを受信すると、当該コンテンツリクエストを解析する。
ＡＰＩ３１３は、解析したコンテンツリクエストに従って、コンテンツ管理・配信サーバ３１１に対して各種要求をし、それらの各種要求に対する返答としてコンテンツ管理・配信サーバ３１１から送信されてくる第１コンテンツを受信し、サービス毎のサーバ３２１に送信する。
例えば、ＡＰＩ３１３は、コンテンツリクエストにコンテンツの加工の要求が含まれていると解析した場合、コンテンツ加工要求を生成して、コンテンツ管理・配信サーバ３１１に送信する。コンテンツ管理・配信サーバ３１１によって、元の第１コンテンツが加工されたものが送信されてくると、ＡＰＩ３１３は、当該第１コンテンツを受信してサービス毎のサーバ３２１に送信する。
【００９６】
コンテンツ管理・配信サーバ３１１のコンテンツ配信管理部３１１１は、ＡＰＩ３１３からの要求に基づいて、ＡＰＩ３１３を介してサービス毎のサーバ３２１に第１コンテンツを配信するまでの処理を管理する。
【００９７】
例えば、ＡＰＩ３１３からの要求が、コンテンツ記憶部３１１２に記憶されている第１コンテンツを加工せずに送信するというものである場合、コンテンツ配信管理部３１１１は、当該コンテンツ記憶部３１１２から第１コンテンツを取得して、ＡＰＩ３１３を介してサービス毎のサーバ３２１に配信する。
【００９８】
これに対して、例えば、ＡＰＩ３１３からの要求が、コンテンツ記憶部３１１２に記憶されている第１コンテンツを加工して送信するというものである場合、コンテンツ配信管理部３１１１は、その旨及び加工方法等を後述の加工部３１１３に通知する。その後、加工後の第１コンテンツが加工部３１１３から供給されてきた場合、コンテンツ配信管理部３１１１は、当該加工後の第１コンテンツを取得して、ＡＰＩ３１３を介してサービス毎のサーバ３２１に配信する。
【００９９】
コンテンツ記憶部３１１２は、放送局１により用意されたコンテンツ等を第１コンテンツとして記憶する。コンテンツ記憶部３１１２には、例えば、放送局が提供する放送局提供情報や、視聴者から吸い上げた視聴者情報が第１コンテンツとして記憶されている。
ここで、放送局提供情報とは、例えば、放送番組毎のブログサービスで提供される番組出演者やスタッフのブログ等の情報である。視聴者情報は、例えば、放送局が運営するソーシャルネットワークサービスで提供される掲示板の書き込みやブログのコメント欄の書き込み等の情報である。
【０１００】
加工部３１１３は、コンテンツ配信管理部３１１１の指示に基づいて、第１コンテンツをコンテンツ記憶部３１１２から取得して加工する。ここで、加工の解釈は、加工部３２１６に対するものと同様であり説明済みであるため、ここではその説明は省略する。
【０１０１】
図７は、このような図６の機能的構成を有する、受信機４、サーバ毎のサーバ３、並びに放送局サーバ群３１のコンテンツ管理・配信サーバ３１１及びＡＰＩ３１３により実行されるコンテンツ配信処理の流れの一例を示すアローチャートである。
即ち、図７には、受信機４から、特定の役者に関する好意的な情報をコンテンツとして取得したというコンテンツリクエストが送信された場合における、コンテンツ配信処理の流れが示されている。
【０１０２】
ステップＳ１において、受信機４は、コンテンツリクエストを送信する。
ステップＳ２において、サービス毎のサーバ３２１の第１通信部３２１１は、コンテンツリクエストを受信する。
ステップＳ３において、サービス毎のサーバ３２１のコンテンツ要求生成部３２１４は、コンテンツリクエストに基づいて、Ｗｅｂ ＡＰＩのＲＥＳＴフォーマットに準拠したコンテンツリクエストを生成する。本例では、送信先となる放送局サーバ群３１の所在を示すＵＲＬを先頭にして、その後、｛役者名｝、｛好意的な情報｝といった各種パラメータが設定されたコンテンツリクエストが生成される。
そして、第２通信部３２１５は、このようなコンテンツリクエストをＡＰＩ３１３に送信する。
【０１０３】
ステップＳ４において、ＡＰＩ３１３は、コンテンツリクエストを受信する。
ステップＳ５において、ＡＰＩ３１３は、コンテンツリクエストを解析する。具体的には、ＡＰＩ３１３は、コンテンツリクエストに含まれる｛役者名｝、｛好意的な情報｝というパラメータから、その役者名の役者の情報を少なくとも含む第１コンテンツに対して、当該役者の好意的な情報のみを抽出する（抽出という加工をする）処理を施す必要があると解析する。
ステップＳ６において、ＡＰＩ３１３は、ステップＳ５において解析されたコンテンツリクエストに基づいて、第１コンテンツを加工した上で配信する旨の要求（以下、コンテンツ加工要求と呼ぶ）を、コンテンツ管理・配信サーバ３１１に対して行う。具体的には本例では、第１コンテンツに対して、当該役者の好意的な情報のみを抽出し（抽出という加工をし）、抽出後の第１コンテンツを配信するというコンテンツ加工要求がなされる。
【０１０４】
ステップＳ７において、コンテンツ管理・配信サーバ３１１のコンテンツ配信管理部３１１１は、コンテンツ加工要求に基づいて、コンテンツ記憶部３１１２から第１コンテンツを取得する。ただし、本例では、取得された第１コンテンツは、加工部３１１３に供給される。
ステップＳ８において、加工部３１１３は、ステップＳ７の処理で取得された第１コンテンツを加工する。具体的には、加工部３１１３は、第１コンテンツに含まれる役者の情報の中からさらに、当該役者に好意的な情報を抽出（加工）する。
ステップＳ９において、コンテンツ配信管理部３１１１は、加工後の第１コンテンツを送信する。
これにより、コンテンツ管理・配信サーバ３１１におけるコンテンツ配信処理は終了する。
【０１０５】
ステップＳ１０において、ＡＰＩ３１３は、第１コンテンツの送信の中継を制御する。即ち、ステップＳ９の処理でコンテンツ管理・配信サーバ３１１から送信された、加工後の第１コンテンツは、ステップＳ１０の処理でＡＰＩ３１３を経由してサービス毎のサーバ３２１に送信される。
【０１０６】
ステップＳ１１において、サービス毎のサーバ３２１の第２通信部３２１５は、第１コンテンツを受信する。
ステップＳ１２において、サービス毎のサーバ３２１のコンテンツ配信管理部３２１３は、コンテンツ記憶部３２１２から第２コンテンツを取得する。本例では、コンテンツ配信管理部３２１３は、サービス事業者が独自に収集した役者に関する情報のコンテンツを第２コンテンツとして取得する。ただし、本例では、取得された第２コンテンツは、加工部３２１６に供給される。
ステップＳ１３において、加工部３２１６は、ステップＳ１２の処理で取得された第２コンテンツを加工する。具体的には、加工部３２１６は、第２コンテンツに含まれる役者の情報の中からさらに、当該役者に好意的な情報を抽出（加工）する。
ステップＳ１４において、コンテンツ配信管理部３２１３は、加工後の第１コンテンツと加工後の第２コンテンツとを合成することによって、合成コンテンツを生成する。具体的には、放送局が保有する役者に好意的な情報（加工後の第１コンテンツ）と、サービス事業者が独自に収集した役者に好意的な情報（加工後の第２コンテンツ）とが合算されたものが、合成コンテンツとして生成される。
ステップＳ１５において、第１通信部３２１１は、合成コンテンツを受信機４に送信する。
これにより、サービス毎のサーバ３２１におけるコンテンツ配信処理が終了する。
【０１０７】
ステップＳ１６において、受信機４は、合成コンテンツを受信する。
これにより、受信機４におけるコンテンツ配信処理は終了する。
その後、受信機４においては、所定のアプリケーションによって、取得された合成コンテンツが表示されたり、当該合成コンテンツを用いた処理が実行される。
【０１０８】
本実施形態によれば、以下のような効果がある。
（１）放送通信連携システム１００では、リクエストに従って、コンテンツを加工して、加工後のコンテンツをコンテンツ管理・配信サーバ３１１から受信するので、受信機４において所望のコンテンツを入手することができる。
【０１０９】
（２）放送通信連携システム１００では、コンテンツ管理・配信サーバ３１１に加えて、サービス毎のサーバ３２１でもコンテンツをさらに加工するので、より高度なリクエストにも対応したコンテンツを提供することができる。
【０１１０】
上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。
換言すると、図６の機能的構成は例示に過ぎず、特に限定されない。すなわち、上述した一連の処理を全体として実行できる機能が受信機４やコンテンツ管理・配信サーバ３１１やサービス毎のサーバ３２１等に備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは特に図６の例に限定されない。
また、一つの機能ブロックは、ハードウェア単体で構成してもよいし、ソフトウェア単体で構成してもよいし、それらの組み合わせで構成してもよい。
【０１１１】
一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、コンピュータ等にネットワークや記録媒体からインストールされる。
コンピュータは、専用のハードウェアに組み込まれているコンピュータであってもよい。また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えば汎用のパーソナルコンピュータであってもよい。
【０１１２】
なお、本発明は上記実施形態に限定されるものではなく、本発明の目的を達成できる範囲での変形、改良等は本発明に含まれるものである。
【０１１３】
また、上記実施形態では、コンテンツの加工は、第１コンテンツを加工部３１１３が加工し、第２コンテンツを加工部３２１６が加工するように構成したがこれに限られない、例えば、第１コンテンツ、又は第２コンテンツのいずれかを加工しても、第１コンテンツを加工部３１１３が加工した後にさらに加工部３２１６が加工したり、加工部３２１６のみが加工したりするように構成してもよい。
【０１１４】
また、上記実施形態では、受信機４はリクエスト対象を、放送局提供情報や視聴者情報をコンテンツとしたがこれに限られない。例えば、メタデータをリクエスト対象としてもよい。また、コンテンツは、掲示板の書き込み、映像、字幕、音声を含む。また、メタデータは、番組タイトル、番組ＩＤ、番組概要、出演者、放送日時、台本、字幕、解説等のコンテンツに付随する情報を含む。
【０１１５】
また、上記実施形態では、サービス事業者サーバ群と放送局サーバ群とのやり取りをＷｅｂ ＡＰＩのうち、ＲＥＳＴのフォーマットにおいて行ったがこれに限られない。サービス事業者サーバ群、放送局サーバ群、受信機のやり取りは、リクエストに応じて、所望のデータを取得できるような方法であれば種々の方法を採用することができる。
【符号の説明】
【０１１６】
１ 放送局
４ 受信機
１００ 放送通信連携システム
３１１ コンテンツ管理・配信サーバ
３１３ ＡＰＩ
３２１ サービス毎のサーバ
３１１３ 加工部
【技術分野】
【０００１】
本発明は、放送と通信の連携を図る機能を有する放送通信連携システム、サーバ及びプログラムに関する。
【背景技術】
【０００２】
近年、放送のデジタル化と通信のブロードバンド化の進展に伴い、放送通信連携サービスの実現に向けた研究開発が行われている。
【０００３】
また、この放送通信連携サービスにおいては、放送と通信という異なる伝送路を用いて複数のコンテンツを配信し、デジタルテレビ等の受信機において、配信された複数のコンテンツを統合して提示する形態が想定される。
【０００４】
ところで、現在、データ放送では、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）をベースとした、マルチメディア符号化用に開発されたＢＭＬ（Ｂｒｏａｄｃａｓｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）という放送サービスに必要な機能を拡張した言語を用いて、様々なコンテンツが提供されている（特許文献１を参照）。
【０００５】
例えば、特許文献２によれば、ビデオオンデマンド（Ｖｉｄｅｏ Ｏｎ Ｄｅｍａｎｄ：以下、ＶＯＤという）による、過去に放送されたコンテンツが提供可能になっている。この場合のコンテンツの伝送方法は、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）に準拠した方法が用いられている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００３−６０９３１号公報
【特許文献２】特開２００９−２４６８１５号公報
【非特許文献】
【０００７】
【非特許文献１】「デジタル放送におけるアプリケーション実行環境 標準規格 ＡＲＩＢ ＳＴＤ−Ｂ２３ １．２版」 第二部１０．１６，平成２１年７月２９日策定，社団法人 電波産業会
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ところで、データ放送では、全ての情報を放送波に多重化させる必要があるため、放送波で送信可能なデータ容量に一定の制限がある。
【０００９】
このような状況の下、送信可能なデータの容量に制限のない通信を、放送と連携させるシステムの実現が要求されている。
【００１０】
このようなシステムでは、受信機等の受信側が、保存元のコンテンツそのものではなく、何らかの加工が施されたコンテンツを要求する場合が想定される。しかしながら、上述のＦＴＰを採用しても、保存元のコンテンツそのものが単に伝送されるだけであり、このような要求に応えることができない。
【００１１】
本発明は、このような状況に鑑みてなされたものであり、放送と通信の連携を図るシステムにおいて、受信側で要求される形態でのコンテンツの伝送を実現することを一つの目的とする。
【課題を解決するための手段】
【００１２】
本発明に係る放送通信連携システムは、放送局と、前記放送局により管理される第１サーバと、前記第１サーバと通信する第２サーバと、前記第２サーバと通信すると共に前記放送局から放送された放送信号を受信する受信機と、を備える放送通信連携システムであって、前記受信機は、前記第２サーバに対してコンテンツをリクエストし、前記第２サーバは、前記受信機からの前記リクエストを受けて、前記第１サーバに対して、Ｗｅｂ ＡＰＩで、前記コンテンツを加工して自機に送信することをリクエストし、前記第１サーバは、Ｗｅｂ ＡＰＩでの前記リクエストに従って、前記コンテンツを加工して、加工後の前記コンテンツを前記第２サーバに送信し、前記第２サーバは、前記第１サーバから送信された前記コンテンツを受信して、前記受信機に送信し、前記受信機は、前記第２サーバ群から送信された前記コンテンツを受信する構成とした。
【００１３】
かかる構成によれば、第２サーバでは、第１サーバからのＷｅｂ ＡＰＩでのリクエストに従って、コンテンツが加工されて、加工後のコンテンツが第１サーバに送信されるので、受信側で要求される形態でのコンテンツの伝送を実現することができる。
【００１４】
また、放送通信連携システムでは、前記第２サーバは、前記第１サーバから受信した前記コンテンツをさらに加工して、加工後の前記コンテンツを前記受信機に送信するようにしてもよい。
【００１５】
かかる構成によれば、第１のサーバに加えて、第２のサーバでもコンテンツをさらに加工するので、受信側でのより高度な要求にも容易に応えることができる。
【００１６】
また、本発明に係る第１のサーバは、放送局と、サーバ群と、前記サーバ群と通信すると共に前記放送局から放送された放送信号を受信する受信機と、を備える放送通信連携システムにおけるサーバであって、前記受信機からのコンテンツのリクエストを受信する第１通信手段と、前記第１通信手段に受信された前記リクエストに従って、前記放送局により管理される別サーバに対するリクエストであって、前記コンテンツを加工して自機に送信させるリクエストをＷｅｂ ＡＰＩで生成する生成手段と、前記生成手段により前記Ｗｅｂ ＡＰＩで生成された前記リクエストを前記別サーバに送信する第２通信手段と、を備え、前記別サーバにおいて、前記Ｗｅｂ ＡＰＩによるリクエストに従って、前記コンテンツが加工されて送信されてきた場合、前記第２通信手段は前記コンテンツを受信し、前記第１通信手段は前記コンテンツを前記受信機に送信する構成とした。
【００１７】
かかる構成によれば、第１のサーバが別サーバに対してＷｅｂ ＡＰＩでのリクエストをすると、別サーバでは、第１のサーバからのＷｅｂ ＡＰＩでのリクエストに従って、コンテンツが加工されて、加工後のコンテンツが第１のサーバに送信されるので、受信機側で要求される形態でのコンテンツの伝送を実現することができる。
【００１８】
また、上記第１のサーバは、前記別サーバから受信した前記コンテンツを加工する加工手段をさらに備え、前記第１通信手段は、前記加工手段による加工後の前記コンテンツを、前記受信機に送信することが好ましい。
【００１９】
かかる構成によれば、別サーバに加えて、第１のサーバでもコンテンツをさらに加工するので、受信側でのより高度な要求にも容易に応えることができる。
【００２０】
また、本発明に係る第１のプログラムは、放送局と、サーバ群と、前記サーバ群と通信すると共に前記放送局から放送された放送信号を受信する受信機と、を備える放送通信連携システムにおけるサーバを制御するコンピュータを、前記受信機からのコンテンツのリクエストを前記サーバに受信させる制御を実行する第１通信制御手段、前記第１通信制御手段の制御により前記サーバに受信された前記リクエストに従って、前記放送局により管理される別サーバに対するリクエストであって、前記コンテンツを加工して自機に送信させるリクエストをＷｅｂ ＡＰＩで生成する生成手段、前記生成手段により前記Ｗｅｂ ＡＰＩで生成された前記リクエストを前記サーバから前記別サーバに送信させる制御を実行する第２通信制御手段、として機能させ、前記別サーバにおいて、前記Ｗｅｂ ＡＰＩによるリクエストに従って、前記コンテンツが加工されて送信されてきた場合、前記第２通信制御手段として機能するコンピュータは、前記コンテンツを前記サーバに受信させる制御を実行し、前記第１通信制御手段として機能するコンピュータは、前記コンテンツを前記サーバから前記受信機に送信させる制御を実行するように構成した。
【００２１】
かかる構成によれば、かかる構成によれば、サーバが別サーバに対してＷｅｂ ＡＰＩでのリクエストをすると、別サーバでは、サーバからのＷｅｂ ＡＰＩでのリクエストに従って、コンテンツが加工されて、加工後のコンテンツがサーバに送信されるので、受信機側で要求される形態でのコンテンの伝送を実現することができる。
【００２２】
また、本発明に係る第２のサーバは、放送局と、サーバ群と、前記サーバ群と通信すると共に前記放送局から放送された放送信号を受信する受信機と、を備える放送通信連携システムにおけるサーバであって、別サーバにおいて、前記受信機からのコンテンツのリクエストに従って、自機に対するリクエストであって、前記コンテンツを加工して前記別サーバに送信させるリクエストがＷｅｂ ＡＰＩで生成されて、送信されてきた場合、前記リクエストを解析して処理するＡＰＩと、前記ＡＰＩにより解析された前記リクエストに従って、前記コンテンツを加工する加工手段と、前記ＡＰＩにより解析された前記リクエストに従って、前記加工手段により加工された前記コンテンツを、前記ＡＰＩを介して前記別サーバに配信する配信管理手段と、を備えるように構成した。
【００２３】
かかる構成によれば、第２のサーバでは、別サーバからのＷｅｂ ＡＰＩでのリクエストに従って、コンテンツが加工されて、加工後のコンテンツが別サーバに送信されるので、受信側で要求される形態でのコンテンの伝送を実現することができる。
【００２４】
また、第２の本発明に係るプログラムは、放送局と、サーバ群と、前記サーバ群と通信すると共に前記放送局から放送された放送信号を受信する受信機と、を備える放送通信連携システムにおけるサーバを制御するコンピュータを、別サーバにおいて、前記受信機からのコンテンツのリクエストに従って、自機に対するリクエストであって、前記コンテンツを加工して前記別サーバに送信させるリクエストがＷｅｂ ＡＰＩで生成されて、送信されてきた場合、前記リクエストを解析して処理させる制御を実行するＡＰＩ手段、前記ＡＰＩにより解析された前記リクエストに従って、前記コンテンツを加工する加工手段、前記ＡＰＩにより解析された前記リクエストに従って、前記加工手段により加工された前記コンテンツを、前記ＡＰＩを介して前記別サーバに配信させる制御を実行する配信管理手段、として機能させるように構成した。
【００２５】
かかる構成によれば、サーバでは、別サーバからのＷｅｂ ＡＰＩでのリクエストに従って、コンテンツが加工されて、加工後のコンテンツが別サーバに送信されるので、受信側で要求される形態でのコンテンの伝送を実現することができる。
【発明の効果】
【００２６】
本発明によれば、受信機において所望のコンテンツを入手することができる。
【図面の簡単な説明】
【００２７】
【図１】放送通信連携システムの全体構成図である。
【図２】デジタル放送に係る放送信号の伝送プロトコルのスタックを示す図である。
【図３】受信機の機能構成を示すブロック図である。
【図４】ＸＭＬ形式で記述されたＡＩＴの一例を示す図である。
【図５】サーバ群を放送局サーバ群とサービス事業者サーバ群とに区別した場合における、放送通信連携システムの機能構成を示すブロック図である。
【図６】コンテンツ配信処理を実行するためのサーバ群の機能的構成を示す機能ブロック図である。
【図７】コンテンツ配信処理の流れを示すアローチャートである。
【発明を実施するための形態】
【００２８】
以下、本発明の実施の形態について図面を参照して説明する。
図１は、本発明の一実施形態に係る放送通信連携システム１００の全体構成図である。放送通信連携システム１００は、放送局１と、放送用アンテナ２と、サーバ群３と、受信機４とを含んで構成される。
この放送通信連携システム１００では、受信機４において、ＩＳＤＢ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｂｒｏａｄｃａｓｔｉｎｇ：統合デジタル放送サービス）方式によって放送局１から提供される放送サービスと、インターネット等により構成される通信ネットワークＮを介してサーバ３から提供される通信サービスとが連携される。これにより、放送通信連携サービスが、受信機４のユーザに提供される。
本実施形態では、放送通信連携システム１００は、Ｈｙｂｒｉｄｃａｓｔ（登録商標）システムであるものとする。Ｈｙｂｒｉｄｃａｓｔとは、同報性、高品質、高信頼という放送の特徴と、視聴者の個別の要求に応えることができるという通信の特徴とを生かしたシステムを構築するための仕組みである。Ｈｙｂｒｉｄｃａｓｔシステムは、放送サービスを中心に置きながら、通信の活用によってサービスを強化するという観点で、放送と通信のハイブリッドサービスを実現することができる。
【００２９】
放送局１は、番組編成設備と、番組送出設備と、送信設備とを含んで構成される一般的なデジタル放送用の放送設備（図示省略）を備える。
放送局１は、放送設備によって、コンテンツや、イベント情報（Ｅｖｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ：ＥＩＴ）や、ＡＩＴ（以下、アプリケーション管理情報とも適宜呼ぶ）等を制作する。そして、放送局１は、放送設備によって、これらコンテンツ、イベント情報及びＡＩＴ等を多重化した放送信号を生成し、当該放送信号を放送波に変調して放送用アンテナ２から送信する。
【００３０】
このような放送波に含まれるコンテンツとしては、放送スケジュールに従って放送される番組を構成する映像や音声の各データを含むコンテンツ（以下、番組コンテンツと呼ぶ）の他、番組コンテンツとは非同期に発生するコンテンツ、例えば緊急地震速報等を含むコンテンツ（以下、緊急コンテンツと呼ぶ）も存在する。
【００３１】
イベント情報は、番組コンテンツの名称、番組コンテンツの放送日時、番組コンテンツの説明等、コンテンツに関するメタ情報を含む。以下、テーブル形式のイベント情報をＥＩＴと呼ぶ。
ＡＩＴ（アプリケーション管理情報）は、受信機４で実行可能な１以上のアプリケーションを管理するための情報である。ＡＩＴには、１以上のアプリケーションのそれぞれに対応し、当該１以上のアプリケーションのそれぞれを管理するための個別管理情報が含まれる。個別管理情報には、管理対象のアプリケーションを識別するアプリケーションＩＤ、当該アプリケーションのライフサイクルを制御するライフサイクル制御情報、当該アプリケーションの所在を示すロケーション情報等が含まれている（後述の図４参照）。
【００３２】
アプリケーションにより受信機４に提供されるコンテンツには、番組コンテンツに連動するコンテンツ及び番組コンテンツに連動しないコンテンツが含まれる。以下、アプリケーションにより提供されるコンテンツをアプリ用コンテンツという。
【００３３】
放送信号は、従来のデジタル放送の放送信号と同一であり、ＡＲＩＢ（登録商標）（Ａｓｓｏｃｉａｔｉｏｎ ｏｆ Ｒａｄｉｏ Ｉｎｄｕｓｔｒｉｅｓ ａｎｄ Ｂｒｏａｄｃａｓｔ：社団法人電波産業会）標準規格で規定される。
【００３４】
図２は、デジタル放送に係る放送信号の伝送プロトコルのスタックを示す図である。図２に示すように、デジタル放送によって提供される映像、音声等の各種データは、国際標準規格ＭＰＥＧ−２ Ｓｙｓｔｅｍｓで規定されるＴＳパケット（トランスポートストリームパケット）に格納されて、時分割で多重伝送される。
【００３５】
ＴＳパケットには、図２に示すように、セクション（Ｓｅｃｔｉｏｎ）に対してＰＳＩ（Ｐｒｏｇｒａｍ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎ）／ＳＩ（Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ）が規定されている。ＰＳＩ／ＳＩには、ＴＳパケットに格納されているデータの種別を示す情報や、コンテンツの種別を示す情報が含まれている。上述のＥＩＴは、ＳＩに含まれている。
【００３６】
ＴＳパケットによるデータ伝送は、セクションを用いてデータを伝送する方式とＰＥＳ（Ｐａｃｋｅｔｉｚｅｄ Ｅｌｅｍｅｎｔａｒｙ Ｓｔｒｅａｍ）パケットを用いてデータを伝送する方式（データストリーム伝送方式）とに分類される。
【００３７】
セクションを用いてデータを伝送する方式には、データカルーセル伝送方式と、イベントメッセージ伝送方式がある。
【００３８】
データカルーセル伝送方式は、１以上のデータを一定周期で繰り返し伝送する伝送方式である。データカルーセル伝送方式によって伝送される個々のデータ（モジュール）には、それらを一意に識別するための識別情報が付されている。データカルーセル伝送方式は、受信機４側に個々のデータを任意のタイミングで取得させるために用いられる。
【００３９】
イベントメッセージ伝送方式は、放送局１から受信機４に対して、トリガ信号を送るための方式である。イベントメッセージ伝送方式は、データ量が少ないメッセージを放送局１から受信機４に伝送する場合に用いられる。
【００４０】
データストリーム伝送方式は、伝送するデータをＰＥＳパケットに収容してストリームとして伝送する伝送方式である。データストリーム伝送方式は、映像、音声、字幕データ等のリアルタイム型のデータや、他のストリームとの同期を要するデータの伝送に用いられる。
【００４１】
ここで、ＡＩＴは、ＴＳパケットを用いて様々な方法によって伝送可能である。
すなわち、ＡＩＴは、ＴＳパケットのＳＩに含まれるＥＩＴに対して記述することによって伝送可能である。
【００４２】
また、ＡＩＴは、セクションを用いてデータカルーセル伝送方式により伝送可能である。ＡＩＴをデータカルーセル伝送方式により伝送する場合、受信機４側でＡＩＴであることを認識できるようにモジュールに対して識別情報が付される。
【００４３】
また、ＡＩＴは、ＰＥＳとしてコンテンツの映像や音声に多重させて伝送可能である。
【００４４】
また、ＡＩＴは、バイナリ表現又はＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）によるテキスト表現で記述して、ＴＳパケットに格納することができる。
本実施形態では、ＡＩＴの伝送方法は、上記の伝送方法の少なくともいずれかに予め規定されているものとする。
【００４５】
なお、ＸＭＬをベースとした、マルチメディア符号化用に開発されたＢＭＬは、Ｗ３Ｃ（登録商標）（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ）が定義したｘＨＴＭＬを基礎とし、手続き型言語にはＪａｖａＳｃｒｉｐｔ（登録商標）を基礎としたＥＣＭＡＳｃｒｉｐｔを用いて国際標準との整合性を考慮して定義された規格である。
【００４６】
サーバ群３は、インターネット等のネットワークを介する通信により、他のサーバや受信機４等と各種情報を送受信することができる。サーバ群の詳細については、図５を参照して後述する。
【００４７】
受信機４は、放送局１からの放送又はサーバ群３との通信を介して受信する番組コンテンツに対して所定の処理を行うことにより、番組コンテンツを構成する映像や音声を同期して出力する。また、受信機４は、ＡＩＴに基づいて、アプリケーションを適宜取得し、取得したアプリケーションを起動して実行する。また例えば、受信機４は、実行されているアプリケーションによってサーバ群３からアプリ用コンテンツを取得し、番組コンテンツに連携させて出力することも可能である。なお、アプリ用コンテンツの出力は、必ずしも番組コンテンツに連携させる必要はない。
以下、このような受信機４の機能について詳述する。
【００４８】
図３は、受信機４の機能構成を示すブロック図である。
受信機４は、放送波受信部１１と、第１分離部１２と、放送ＡＩＴ取得部１３と、通信部１４と、第２分離部１５と、通信ＡＩＴ取得部１６と、アプリケーション実行制御部１７と、音声制御部１８と、表示制御部１９と、スピーカ２０と、ディスプレイ２１と、メモリ２２と、ＡＩＴ記憶部２３とを備える。
【００４９】
放送波受信部１１は、放送用アンテナ２を介して放送局１から送信されてくる放送波を受信する。
【００５０】
第１分離部１２は、放送波受信部１１に受信された放送波を復調することによって、放送信号、すなわちＴＳパケットを抽出する。そして、第１分離部１２は、ＴＳパケットのＰＳＩ／ＳＩを参照して、ＴＳパケットに含まれているデータの種別を判別し、映像、音声、ＥＩＴ等の各種データを分離して抽出する。また、第１分離部１２は、予め規定されているＡＩＴの伝送方法に応じて、セクションやＰＥＳを参照してＡＩＴを分離して抽出する。
【００５１】
続いて、第１分離部１２は、ＴＳパケットのＰＥＳに含まれているデータが音声データである場合、この音声データを音声制御部１８に出力する。また、第１分離部１２は、ＴＳパケットのＰＥＳに含まれているデータが映像データである場合、この映像データを表示制御部１９に出力する。
【００５２】
また、第１分離部１２は、抽出したＥＩＴやその他の各種データをメモリ２２に記憶させる。また、第１分離部１２は、ＡＩＴを抽出した場合、抽出したＡＩＴを放送ＡＩＴ取得部１３に出力する。
【００５３】
放送ＡＩＴ取得部１３は、第１分離部１２から出力されたＡＩＴを取得し、ＡＩＴ記憶部２３に記憶させる。
【００５４】
通信部１４は、通信ネットワークＮを介するサーバ群３との間で各種情報を送受信したり、リモートコントローラＲ（以下、リモコンＲと略記する）からの操作信号を受信する。
【００５５】
第２分離部１５は、サーバ群３から通信ネットワークＮを介して送信されてきて通信部１４に受信されたデータの種別を判別し、その判別結果に基づいてデータの出力先を分離する。例えば、第２分離部１５は、受信したデータがＡＩＴであると判別した場合、このＡＩＴを通信ＡＩＴ取得部１６に出力する。また、第２分離部１５は、受信したデータがアプリケーションであると判別した場合、このアプリケーションをアプリケーション実行制御部１７に出力する。
【００５６】
また、第２分離部１５は、受信したデータがＴＳパケットであると判別した場合、映像、音声、ＡＩＴ等の各種データをＴＳパケットから分離して抽出する。そして、第２分離部１５は、ＡＩＴを抽出した場合、このＡＩＴを通信ＡＩＴ取得部１６に出力し、ＡＩＴ以外のデータを抽出した場合、このデータをアプリケーション実行制御部１７に出力する。
【００５７】
通信ＡＩＴ取得部１６は、第２分離部１５から出力されたＡＩＴを取得し、ＡＩＴ記憶部２３に記憶させる。
【００５８】
アプリケーション実行制御部１７は、ＡＩＴに基づいてアプリケーションを取得し、取得したアプリケーションの起動及び実行を制御する。
【００５９】
ここで、アプリケーション実行制御部１７により実行が制御されるアプリケーションの管理用のＡＩＴの構造の例を詳細に説明する。
図４は、ＸＭＬ形式で記述されたＡＩＴの構造の一例を示す図である。
上述したように、ＡＩＴには、１以上のアプリケーションそれぞれに対応し、１以上のアプリケーションそれぞれを管理するための個別管理情報がそれぞれ含まれる。
具体的には、図４に示される＜ｍｈｐ：Ａｐｐｌｉｃａｔｉｏｎ＞タグから＜／ｍｈｐ：Ａｐｐｌｉｃａｔｉｏｎ＞タグまでに記述されているコードは、一のアプリケーションを管理するための個別管理情報に対応している。ＡＩＴには、＜／ｍｈｐ：Ａｐｐｌｉｃａｔｉｏｎ＞タグの後に、他のアプリケーションの個別管理情報を新たに記述することによって、複数の個別管理情報を記述することができる。
【００６０】
また、個別管理情報に対応するコードのうち、例えば、＜ｍｈｐ：ａｐｐＩｄ＞タグに対応するコードは、アプリケーションのＩＤ（識別情報）を示している。また、＜ｍｈｐ：ｃｏｎｔｒｏｌＣｏｄｅ ｍｈｐ：ｔｙｐｅ＝“ＡＲＩＢ−Ｊ”＞タグに対応するコードは、このアプリケーションのライフサイクル制御情報を示しており、図４に示す「ＡＵＴＯＳＴＡＲＴ」は、受信機４によってアプリケーションを自動実行させるライフサイクル制御情報である。また、＜ｍｈｐ：ｌｏｃａｔｉｏｎ＞タグに対応するコードは、このアプリケーションの所在を示すロケーション情報を示している。図４の例では、ロケーション情報には、アプリケーションの所在として、サービスサーバ３のアドレスが記述されている。
なお、ロケーション情報には、アプリケーションの所在として、受信機４を指定することもできる。
【００６１】
アプリケーション実行制御部１７は、ＡＩＴ記憶部２３を監視し、新たにＡＩＴが記憶された場合に、このＡＩＴに記述されているライフサイクルに係る制御情報を参照する。そして、アプリケーション実行制御部１７は、ライフサイクルに係る制御情報が「自動実行」を示すものである場合、ＡＩＴに記述されているロケーション情報をアプリケーションの取得先として認識する。例えば取得先がサーバ群３であった場合には、アプリケーション実行制御部１７は、通信部１４及び第２分離部１５を介してサーバ群３からアプリケーションを取得し、取得したアプリケーションを起動して実行する。この場合、アプリケーションは、受信機４のユーザから明示的な操作指示を受けることなく自動的に実行される。
【００６２】
また、アプリケーション実行制御部１７は、受信機４のユーザからリモコンＲを介してアプリケーションの実行指示を受け付ける。例えば、リモコンＲには、Ｈｙｂｒｉｄｃａｓｔ（登録商標）ボタンが設けられており、アプリケーション実行制御部１７は、受信機４のユーザによってＨｙｂｒｉｄｃａｓｔボタンが押下されたことに応じて、実行するアプリケーションの選択を受け付けるためのメニュー画面の実行指示を受け付ける。アプリケーション実行制御部１７は、メニュー画面の実行指示を受け付けたことに応じて、ＡＩＴ記憶部２３を参照し、実行可能なアプリケーションのＡＩＴを特定する。そして、アプリケーション実行制御部１７は、特定したＡＩＴに対応するアプリケーションを選択可能なメニューの画像データを生成して、当該画像データを表示制御部１９に出力することで、このメニューをディスプレイ２１に表示させる。受信機４のユーザからリモコンＲを介してアプリケーションの選択操作を受け付けた場合、アプリケーション実行制御部１７は、ＡＩＴに記述された当該アプリケーションのロケーション情報を参照してアプリケーションを取得し、アプリケーションを起動して実行する。
【００６３】
アプリケーション実行制御部１７は、必要に応じて、実行中のアプリケーションに関するアプリ用コンテンツをサービスサーバ３から取得する。そして、アプリケーション実行制御部１７は、アプリ用コンテンツのうち、音声のデータを音声制御部１８に、映像のデータを表示制御部１９に、それぞれ出力する。ここで、実行中のアプリケーションが、番組コンテンツに連動するアプリ用コンテンツを提供するアプリケーションである場合には、アプリ用コンテンツの映像データ及び音声データが番組コンテンツの映像データ及び音声データに連動して出力される。
【００６４】
また、アプリケーション実行制御部１７は、ＡＩＴ記憶部２３に記憶されたＡＩＴに基づいて、具体的には当該ＡＩＴのうち個別管理情報に含まれるライフサイクル制御情報に基づいて、実行中のアプリケーションのライフサイクルを制御する。例えば、アプリケーション実行制御部１７は、アプリケーションのライフサイクル制御情報が「終了」を示すものであるとき、アプリケーションを終了させる。
【００６５】
音声制御部１８は、第１分離部１２から出力された音声のデータを、表示制御部１９により表示が制御される映像のデータと同期をとりながらスピーカ２０に出力する。また、音声制御部１８は、アプリケーション実行制御部１７から出力された音声のデータが表示制御部１９により表示が制御される映像のデータと同期可能である場合、この映像のデータと同期をとりながら音声のデータをスピーカ２０に出力する。
【００６６】
表示制御部１９は、第１分離部１２から出力されたデータに対応する映像を、音声制御部１８により出力制御される音声のデータと同期をとりながらディスプレイ２１に表示させる。また、表示制御部１９は、アプリケーション実行制御部１７から出力された映像のデータが音声制御部１８により出力制御される音声のデータと同期可能である場合、この音声のデータと同期をとりながら当該映像をディスプレイ２１に表示させる。
【００６７】
スピーカ２０は、音声制御部１８から出力されたデータに基づいて、当該データに対応する音声を出力する。ディスプレイ２１は、表示制御部１９から出力されたデータに基づいて、当該データに対応する映像を表示する。
【００６８】
メモリ２２は、ＥＩＴ等の番組コンテンツのメタ情報や、緊急コンテンツに含まれる緊急地震速報等、その他各種情報を記憶する。
ＡＩＴ記憶部２３は、放送ＡＩＴ取得部１３又は通信ＡＩＴ取得部１６によって取得された各種ＡＩＴを記憶する。
【００６９】
さらに以下、サーバ群３の詳細も含め、放送通信連携システム１００の機能構成について説明する。
図５は、サーバ群３を放送局サーバ群３１とサービス事業者サーバ群３２とに区別した場合における、放送通信連携システム１００の機能構成を示すブロック図である。
【００７０】
図１のサーバ群３は、図５に示すように、放送局により管理される放送局サーバ群３１と、各種サービスを提供するサービス事業者により管理されるサービス事業者サーバ群３２とに大別される。
【００７１】
放送局サーバ群３１は、コンテンツ管理・配信サーバ３１１と、放送局サービスサーバ３１２と、ＡＰＩ３１３とを備える。
【００７２】
コンテンツ管理・配信サーバ３１１は、各種番組コンテンツや、これらの番組コンテンツに関するメタデータを管理し、必要に応じて、サービス事業者サーバ群３２に配信する。ここで、メタデータには、番組タイトル、番組ＩＤ、番組概要、番組出演者、放送日時、台本、字幕、解説等の各種情報が含まれる。
【００７３】
放送局サービスサーバ３１２は、サービス事業者に対して各種のサービス、例えば、放送局１が運営するソーシャルネットサービス、放送局１が運営する放送番組毎のブログサービス等を提供するサーバである。
【００７４】
ＡＰＩ３１３は、サービス事業者サーバ群３２からの要求に応じて、放送局サーバ群３１からデータを提供するためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）である。ＡＰＩのデータフォーマットは、放送局とサービス事業者間（Ｂ to Ｂ）の合意により決められる。本実施形態では、ＡＰＩのデータフォーマットは、後述するＷｅｂ ＡＰＩを用いる。
【００７５】
サービス事業者サーバ群３２は、サービス毎のサーバ３２１と、管理・配信サーバ３２２とを備える。
【００７６】
サービス毎のサーバ３２１は、その名の如くサービス事業者が受信機４（そのユーザ）に対して各種サービスを提供するために１つずつ設けられるサーバである。サービス毎のサーバ３２１は、サービスに必要なコンテンツ（受信機４側でいうアプリ用コンテンツ）を、通信により受信機４に提供する。
【００７７】
管理・配信サーバ３２２は、サービスに必要な各種アプリケーションを管理し、通信による受信機４からのリクエストに応じて、アプリケーションを通信により受信機４に提供する。
【００７８】
受信機４は、ＡＰＩを備える。ＡＰＩは、受信機に依存することなく、アプリの動作が同様になるようにするために規定される。なお、アプリケーションは、ＡＰＩを介さずに受信機４の固有機能にアクセスすることができない仕様となっている。
また、受信機４は、Ｈｙｂｒｉｄｃａｓｔ機能と、基本機能とを有している。
Ｈｙｂｒｉｄｃａｓｔ機能とは、Ｈｙｂｒｉｄｃａｓｔのサービスを実現するために必要な機能である。Ｈｙｂｒｉｄｃａｓｔ機能には、ＡＩＴ等によるアプリケーションの制御、描画制御、同期制御、セキュリティ等の各種機能が含まれる。
基本機能には、現行方式の放送（地上デジタル放送、ＢＳデジタル放送、データ放送）が受信でき表示できる機能と、インターネットに接続することができる機能とが含まれる。
【００７９】
以上のように構成される放送通信連携システム１００では、サービス毎のサーバ３２１は、コンテンツの配信のリクエストが受信機４からなされると、そのリクエストに従ってコンテンツを受信機４に配信する。ここで、リクエストされたコンテンツが放送局サーバ群３１に存在する場合、サービス毎のサーバ３２１は、放送局サーバ群３１に対してコンテンツの配信のリクエストをする。この場合、放送局サーバ群３１は、そのリクエストに従ってコンテンツをサービス毎のサーバ３２１に配信する。サービス毎のサーバ３２１は、このような放送局サーバ群３１から配信されたコンテンツを受信すると、当該コンテンツを受信機４に配信する。
このように、受信機４、サービス毎のサーバ３２１、及び放送局サーバ群３１において、受信機４のリクエストに応じて、コンテンツが受信機４に配信されるまでの一連の処理が実行される。このような一連の処理を、以下、コンテンツ配信処理と呼ぶ。
【００８０】
図６は、このようなコンテンツ配信処理を実行するためのサーバ群の機能的構成を示す機能ブロック図である。
【００８１】
放送通信連携システム１００においては、コンテンツ配信処理が実行される場合、受信機４と、サービス毎のサーバ群３２１と、放送局サーバ群３１におけるコンテンツ管理・配信サーバ３１１及びＡＰＩ３１３とが機能する。
【００８２】
受信機４は、サービス毎のサーバ３２１に対して、所定のコンテンツの配信のリクエスト（以下、コンテンツリクエストと呼ぶ）をし、その後、サービス毎のサーバ３２１から送信されてくるコンテンツを受信する。
【００８３】
サービス毎のサーバ３２１においては、コンテンツ配信処理が実行される場合、第１通信部３２１１と、コンテンツ記憶部３２１２と、コンテンツ配信管理部３２１３と、コンテンツ要求生成部３２１４と、第２通信部３２１５と、加工部３２１６とが機能する。
【００８４】
第１通信部３２１１は、受信機４と通信により各種情報を送受信する。例えば、第１通信部３２１１は、受信機４からのコンテンツリクエストを受信する。
【００８５】
コンテンツ記憶部３２１２は、サービス事業者側で生成されたコンテンツを、第２コンテンツとして記憶する。
【００８６】
コンテンツ配信管理部３２１３は、第１通信部３２１１に受信されたコンテンツリクエストに基づいて、受信機４にコンテンツを配信するまでの処理を管理する。
【００８７】
例えば、コンテンツリクエストで求められているコンテンツの全てが、自機内のコンテンツ記憶部３２１２に記憶されている場合、コンテンツ配信管理部３２１３は、当該コンテンツ記憶部３２１２からコンテンツを取得して、当該コンテンツを第１通信部３２１１を介して受信機４に配信する。
【００８８】
これに対して、例えば、コンテンツリクエストで求められているコンテンツの少なくとも一部が、放送局サーバ群３１に記憶されている場合、コンテンツ配信管理部３２１３は、放送局サーバ群３１に対するコンテンツリクエストの生成指示を、後述のコンテンツ要求生成部３２１４に対して行う。
この指示を受けてコンテンツ要求生成部３２１４によりコンテンツリクエストが生成されて、後述の第２通信部３２１５から放送局サーバ群３１に送信される。そのコンテンツリクエストを受けて、放送局サーバ群３１からコンテンツが送信されてくると、コンテンツ配信管理部３２１３は、当該コンテンツを第２通信部３２１５を介して受信する。
そして、コンテンツ配信管理部３２１３は、当該コンテンツを第１通信部３２１１を介して受信機４に配信する。
【００８９】
なお、以下、放送局サーバ群３１に記憶されているコンテンツを、第１コンテンツと呼び、サーバ毎のサーバ３２のコンテンツ記憶部３２１２に記憶されているコンテンツを、第２コンテンツと呼ぶ。
ここで、受信機４からのコンテンツリクエストによって、第１コンテンツと第２コンテンツとの合成（単なる加算や合体も合成に含む）が求められる場合がある。
このような場合には、コンテンツ配信管理部３２１３は、第１コンテンツと第２コンテンツとの各々を個別に取得した後、これらの第１コンテンツと第２コンテンツとを合成する。合成後のコンテンツを、以下、合成コンテンツと呼ぶ。
そして、コンテンツ配信管理部３２１３は、当該合成コンテンツを第１通信部３２１１を介して受信機４に配信する。
【００９０】
コンテンツ要求生成部３２１４は、コンテンツ配信管理部３２１３の指示を受けると、受信機４からのコンテンツリクエストに基づいて、Ｗｅｂ ＡＰＩに準拠したコンテンツリクエストを生成する。
【００９１】
ここで、Ｗｅｂ ＡＰＩとは、ＨＴＴＰを利用してネットワーク越しに処理を実行して結果を受け取る仕組みである。本実施形態においては、Ｗｅｂ ＡＰＩのうち、ＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）のソフトウェアアーキテクチャのスタイルが採用されている。
ＲＥＳＴでは、以下のコマンドフォーマットがＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）形式で提供される。
http://○○○．org/｛サーバ名｝/｛パラメータ１｝/｛パラメータ２｝/・・・
このような形式のＲＥＳＴは、先頭のＵＲＬでサーバ等のコンテンツの場所が特定可能であるという特徴に加えて、パラメータ１，２・・・によって各種各様のパラメータを指定することができるという特徴を有する。
このパラメータ１，２・・・には、任意のパラメータを指定することが可能であり、単純にコンテンツの取得を示すパラメータのみならず、コンテンツの加工を指示したり、その加工方法を指定するパラメータを指定することができる。
例えば、とあるドラマ番組に対する多数のユーザのレビューを含むオリジナルコンテンツが放送局サーバ群３に記憶されている場合には、当該オリジナルコンテンツから、ドラマ番組の出演者の１人である役者に対して、好意的なレビューだけを抽出したものを第１コンテンツとして配信してもらうといった指示内容を、各種パラメータで指定することが可能になる。
即ち、コンテンツ要求生成部３２１４は、第１通信部３２１１に受信されたコンテンツリクエストに従って、例えば、放送局サーバ群３１に対するコンテンツリクエストであって、第１コンテンツを加工して自機に送信させるコンテンツリクエストをＷｅｂ ＡＰＩで生成することができる。
【００９２】
第２通信部３２１５は、コンテンツ要求生成部３２１４により生成されたコンテンツリクエストを放送局サーバ群３１（詳細には、後述するＡＰＩ３１３）に送信する。このコンテンツリクエストを受けて放送局サーバ群３１から第１コンテンツが送信されてくると、第２通信部３２１５は、当該第１コンテンツを受信して、コンテンツ配信管理部３２１３に供給する。
【００９３】
加工部３２１６は、コンテンツ配信管理部３２１３の指示に基づいて、第２コンテンツをコンテンツ記憶部３２１２から取得して加工する。ここで、加工とは、単なる加算や合体の他、減算や抽出、編集、フォーマットやデータ形式の変更、圧縮／復号、符号化／復号、その他、元のデータと少なくとも一部が同一ではないデータを生成することを意味する。
【００９４】
このような機能的構成のサービス毎のサーバ３２１に対して、コンテンツ配信処理が実行される場合、サービスサーバ群３では、コンテンツ管理・配信サーバ３１１と、ＡＰＩ３１３とが機能する。詳細には、コンテンツ管理・配信サーバ３１１においては、コンテンツ配信管理部３１１１と、コンテンツ記憶部３１１２と、加工部３１１３とが機能する。
【００９５】
ＡＰＩ３１３は、サービス毎のサーバ３２１からコンテンツリクエストを受信すると、当該コンテンツリクエストを解析する。
ＡＰＩ３１３は、解析したコンテンツリクエストに従って、コンテンツ管理・配信サーバ３１１に対して各種要求をし、それらの各種要求に対する返答としてコンテンツ管理・配信サーバ３１１から送信されてくる第１コンテンツを受信し、サービス毎のサーバ３２１に送信する。
例えば、ＡＰＩ３１３は、コンテンツリクエストにコンテンツの加工の要求が含まれていると解析した場合、コンテンツ加工要求を生成して、コンテンツ管理・配信サーバ３１１に送信する。コンテンツ管理・配信サーバ３１１によって、元の第１コンテンツが加工されたものが送信されてくると、ＡＰＩ３１３は、当該第１コンテンツを受信してサービス毎のサーバ３２１に送信する。
【００９６】
コンテンツ管理・配信サーバ３１１のコンテンツ配信管理部３１１１は、ＡＰＩ３１３からの要求に基づいて、ＡＰＩ３１３を介してサービス毎のサーバ３２１に第１コンテンツを配信するまでの処理を管理する。
【００９７】
例えば、ＡＰＩ３１３からの要求が、コンテンツ記憶部３１１２に記憶されている第１コンテンツを加工せずに送信するというものである場合、コンテンツ配信管理部３１１１は、当該コンテンツ記憶部３１１２から第１コンテンツを取得して、ＡＰＩ３１３を介してサービス毎のサーバ３２１に配信する。
【００９８】
これに対して、例えば、ＡＰＩ３１３からの要求が、コンテンツ記憶部３１１２に記憶されている第１コンテンツを加工して送信するというものである場合、コンテンツ配信管理部３１１１は、その旨及び加工方法等を後述の加工部３１１３に通知する。その後、加工後の第１コンテンツが加工部３１１３から供給されてきた場合、コンテンツ配信管理部３１１１は、当該加工後の第１コンテンツを取得して、ＡＰＩ３１３を介してサービス毎のサーバ３２１に配信する。
【００９９】
コンテンツ記憶部３１１２は、放送局１により用意されたコンテンツ等を第１コンテンツとして記憶する。コンテンツ記憶部３１１２には、例えば、放送局が提供する放送局提供情報や、視聴者から吸い上げた視聴者情報が第１コンテンツとして記憶されている。
ここで、放送局提供情報とは、例えば、放送番組毎のブログサービスで提供される番組出演者やスタッフのブログ等の情報である。視聴者情報は、例えば、放送局が運営するソーシャルネットワークサービスで提供される掲示板の書き込みやブログのコメント欄の書き込み等の情報である。
【０１００】
加工部３１１３は、コンテンツ配信管理部３１１１の指示に基づいて、第１コンテンツをコンテンツ記憶部３１１２から取得して加工する。ここで、加工の解釈は、加工部３２１６に対するものと同様であり説明済みであるため、ここではその説明は省略する。
【０１０１】
図７は、このような図６の機能的構成を有する、受信機４、サーバ毎のサーバ３、並びに放送局サーバ群３１のコンテンツ管理・配信サーバ３１１及びＡＰＩ３１３により実行されるコンテンツ配信処理の流れの一例を示すアローチャートである。
即ち、図７には、受信機４から、特定の役者に関する好意的な情報をコンテンツとして取得したというコンテンツリクエストが送信された場合における、コンテンツ配信処理の流れが示されている。
【０１０２】
ステップＳ１において、受信機４は、コンテンツリクエストを送信する。
ステップＳ２において、サービス毎のサーバ３２１の第１通信部３２１１は、コンテンツリクエストを受信する。
ステップＳ３において、サービス毎のサーバ３２１のコンテンツ要求生成部３２１４は、コンテンツリクエストに基づいて、Ｗｅｂ ＡＰＩのＲＥＳＴフォーマットに準拠したコンテンツリクエストを生成する。本例では、送信先となる放送局サーバ群３１の所在を示すＵＲＬを先頭にして、その後、｛役者名｝、｛好意的な情報｝といった各種パラメータが設定されたコンテンツリクエストが生成される。
そして、第２通信部３２１５は、このようなコンテンツリクエストをＡＰＩ３１３に送信する。
【０１０３】
ステップＳ４において、ＡＰＩ３１３は、コンテンツリクエストを受信する。
ステップＳ５において、ＡＰＩ３１３は、コンテンツリクエストを解析する。具体的には、ＡＰＩ３１３は、コンテンツリクエストに含まれる｛役者名｝、｛好意的な情報｝というパラメータから、その役者名の役者の情報を少なくとも含む第１コンテンツに対して、当該役者の好意的な情報のみを抽出する（抽出という加工をする）処理を施す必要があると解析する。
ステップＳ６において、ＡＰＩ３１３は、ステップＳ５において解析されたコンテンツリクエストに基づいて、第１コンテンツを加工した上で配信する旨の要求（以下、コンテンツ加工要求と呼ぶ）を、コンテンツ管理・配信サーバ３１１に対して行う。具体的には本例では、第１コンテンツに対して、当該役者の好意的な情報のみを抽出し（抽出という加工をし）、抽出後の第１コンテンツを配信するというコンテンツ加工要求がなされる。
【０１０４】
ステップＳ７において、コンテンツ管理・配信サーバ３１１のコンテンツ配信管理部３１１１は、コンテンツ加工要求に基づいて、コンテンツ記憶部３１１２から第１コンテンツを取得する。ただし、本例では、取得された第１コンテンツは、加工部３１１３に供給される。
ステップＳ８において、加工部３１１３は、ステップＳ７の処理で取得された第１コンテンツを加工する。具体的には、加工部３１１３は、第１コンテンツに含まれる役者の情報の中からさらに、当該役者に好意的な情報を抽出（加工）する。
ステップＳ９において、コンテンツ配信管理部３１１１は、加工後の第１コンテンツを送信する。
これにより、コンテンツ管理・配信サーバ３１１におけるコンテンツ配信処理は終了する。
【０１０５】
ステップＳ１０において、ＡＰＩ３１３は、第１コンテンツの送信の中継を制御する。即ち、ステップＳ９の処理でコンテンツ管理・配信サーバ３１１から送信された、加工後の第１コンテンツは、ステップＳ１０の処理でＡＰＩ３１３を経由してサービス毎のサーバ３２１に送信される。
【０１０６】
ステップＳ１１において、サービス毎のサーバ３２１の第２通信部３２１５は、第１コンテンツを受信する。
ステップＳ１２において、サービス毎のサーバ３２１のコンテンツ配信管理部３２１３は、コンテンツ記憶部３２１２から第２コンテンツを取得する。本例では、コンテンツ配信管理部３２１３は、サービス事業者が独自に収集した役者に関する情報のコンテンツを第２コンテンツとして取得する。ただし、本例では、取得された第２コンテンツは、加工部３２１６に供給される。
ステップＳ１３において、加工部３２１６は、ステップＳ１２の処理で取得された第２コンテンツを加工する。具体的には、加工部３２１６は、第２コンテンツに含まれる役者の情報の中からさらに、当該役者に好意的な情報を抽出（加工）する。
ステップＳ１４において、コンテンツ配信管理部３２１３は、加工後の第１コンテンツと加工後の第２コンテンツとを合成することによって、合成コンテンツを生成する。具体的には、放送局が保有する役者に好意的な情報（加工後の第１コンテンツ）と、サービス事業者が独自に収集した役者に好意的な情報（加工後の第２コンテンツ）とが合算されたものが、合成コンテンツとして生成される。
ステップＳ１５において、第１通信部３２１１は、合成コンテンツを受信機４に送信する。
これにより、サービス毎のサーバ３２１におけるコンテンツ配信処理が終了する。
【０１０７】
ステップＳ１６において、受信機４は、合成コンテンツを受信する。
これにより、受信機４におけるコンテンツ配信処理は終了する。
その後、受信機４においては、所定のアプリケーションによって、取得された合成コンテンツが表示されたり、当該合成コンテンツを用いた処理が実行される。
【０１０８】
本実施形態によれば、以下のような効果がある。
（１）放送通信連携システム１００では、リクエストに従って、コンテンツを加工して、加工後のコンテンツをコンテンツ管理・配信サーバ３１１から受信するので、受信機４において所望のコンテンツを入手することができる。
【０１０９】
（２）放送通信連携システム１００では、コンテンツ管理・配信サーバ３１１に加えて、サービス毎のサーバ３２１でもコンテンツをさらに加工するので、より高度なリクエストにも対応したコンテンツを提供することができる。
【０１１０】
上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。
換言すると、図６の機能的構成は例示に過ぎず、特に限定されない。すなわち、上述した一連の処理を全体として実行できる機能が受信機４やコンテンツ管理・配信サーバ３１１やサービス毎のサーバ３２１等に備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは特に図６の例に限定されない。
また、一つの機能ブロックは、ハードウェア単体で構成してもよいし、ソフトウェア単体で構成してもよいし、それらの組み合わせで構成してもよい。
【０１１１】
一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、コンピュータ等にネットワークや記録媒体からインストールされる。
コンピュータは、専用のハードウェアに組み込まれているコンピュータであってもよい。また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えば汎用のパーソナルコンピュータであってもよい。
【０１１２】
なお、本発明は上記実施形態に限定されるものではなく、本発明の目的を達成できる範囲での変形、改良等は本発明に含まれるものである。
【０１１３】
また、上記実施形態では、コンテンツの加工は、第１コンテンツを加工部３１１３が加工し、第２コンテンツを加工部３２１６が加工するように構成したがこれに限られない、例えば、第１コンテンツ、又は第２コンテンツのいずれかを加工しても、第１コンテンツを加工部３１１３が加工した後にさらに加工部３２１６が加工したり、加工部３２１６のみが加工したりするように構成してもよい。
【０１１４】
また、上記実施形態では、受信機４はリクエスト対象を、放送局提供情報や視聴者情報をコンテンツとしたがこれに限られない。例えば、メタデータをリクエスト対象としてもよい。また、コンテンツは、掲示板の書き込み、映像、字幕、音声を含む。また、メタデータは、番組タイトル、番組ＩＤ、番組概要、出演者、放送日時、台本、字幕、解説等のコンテンツに付随する情報を含む。
【０１１５】
また、上記実施形態では、サービス事業者サーバ群と放送局サーバ群とのやり取りをＷｅｂ ＡＰＩのうち、ＲＥＳＴのフォーマットにおいて行ったがこれに限られない。サービス事業者サーバ群、放送局サーバ群、受信機のやり取りは、リクエストに応じて、所望のデータを取得できるような方法であれば種々の方法を採用することができる。
【符号の説明】
【０１１６】
１ 放送局
４ 受信機
１００ 放送通信連携システム
３１１ コンテンツ管理・配信サーバ
３１３ ＡＰＩ
３２１ サービス毎のサーバ
３１１３ 加工部
【特許請求の範囲】
【請求項１】
放送局と、前記放送局により管理される第１サーバと、前記第１サーバと通信する第２サーバと、前記第２サーバと通信すると共に前記放送局から放送された放送信号を受信する受信機と、を備える放送通信連携システムであって、
前記受信機は、前記第２サーバに対してコンテンツをリクエストし、
前記第２サーバは、前記受信機からの前記リクエストを受けて、前記第１サーバに対して、Ｗｅｂ ＡＰＩで、前記コンテンツを加工して自機に送信することをリクエストし、
前記第１サーバは、Ｗｅｂ ＡＰＩでの前記リクエストに従って、前記コンテンツを加工して、加工後の前記コンテンツを前記第２サーバに送信し、
前記第２サーバは、前記第１サーバから送信された前記コンテンツを受信して、前記受信機に送信し、
前記受信機は、前記第２サーバから送信された前記コンテンツを受信する、
放送通信連携システム。
【請求項２】
前記第２サーバは、前記第１サーバから受信した前記コンテンツをさらに加工して、加工後の前記コンテンツを前記受信機に送信する、
請求項１に記載の放送通信連携システム。
【請求項３】
放送局と、サーバ群と、前記サーバ群と通信すると共に前記放送局から放送された放送信号を受信する受信機と、を備える放送通信連携システムにおけるサーバであって、
前記受信機からのコンテンツのリクエストを受信する第１通信手段と、
前記第１通信手段に受信された前記リクエストに従って、前記放送局により管理される別サーバに対するリクエストであって、前記コンテンツを加工して自機に送信させるリクエストをＷｅｂ ＡＰＩで生成する生成手段と、
前記生成手段により前記Ｗｅｂ ＡＰＩで生成された前記リクエストを前記別サーバに送信する第２通信手段と、
を備え、
前記別サーバにおいて、前記Ｗｅｂ ＡＰＩによるリクエストに従って、前記コンテンツが加工されて送信されてきた場合、前記第２通信手段は前記コンテンツを受信し、前記第１通信手段は前記コンテンツを前記受信機に送信する、
サーバ。
【請求項４】
前記別サーバから受信した前記コンテンツを加工する加工手段をさらに備え、前記第１通信手段は、前記加工手段による加工後の前記コンテンツを、前記受信機に送信する、
請求項３に記載のサーバ。
【請求項５】
放送局と、サーバ群と、前記サーバ群と通信すると共に前記放送局から放送された放送信号を受信する受信機と、を備える放送通信連携システムにおけるサーバを制御するコンピュータを、
前記受信機からのコンテンツのリクエストを前記サーバに受信させる制御を実行する第１通信制御手段、
前記第１通信制御手段の制御により前記サーバに受信された前記リクエストに従って、前記放送局により管理される別サーバに対するリクエストであって、前記コンテンツを加工して自機に送信させるリクエストをＷｅｂ ＡＰＩで生成する生成手段、
前記生成手段により前記Ｗｅｂ ＡＰＩで生成された前記リクエストを前記サーバから前記別サーバに送信させる制御を実行する第２通信制御手段、
として機能させ、
前記別サーバにおいて、前記Ｗｅｂ ＡＰＩによるリクエストに従って、前記コンテンツが加工されて送信されてきた場合、前記第２通信制御手段として機能するコンピュータは、前記コンテンツを前記サーバに受信させる制御を実行し、前記第１通信制御手段として機能するコンピュータは、前記コンテンツを前記サーバから前記受信機に送信させる制御を実行する、
プログラム。
【請求項６】
放送局と、サーバ群と、前記サーバ群と通信すると共に前記放送局から放送された放送信号を受信する受信機と、を備える放送通信連携システムにおけるサーバであって、
別サーバにおいて、前記受信機からのコンテンツのリクエストに従って、自機に対するリクエストであって、前記コンテンツを加工して前記別サーバに送信させるリクエストがＷｅｂ ＡＰＩで生成されて、送信されてきた場合、前記リクエストを解析して処理するＡＰＩと、
前記ＡＰＩにより解析された前記リクエストに従って、前記コンテンツを加工する加工手段と、
前記ＡＰＩにより解析された前記リクエストに従って、前記加工手段により加工された前記コンテンツを、前記ＡＰＩを介して前記別サーバに配信する配信管理手段と、
を備えるサーバ。
【請求項７】
放送局と、サーバ群と、前記サーバ群と通信すると共に前記放送局から放送された放送信号を受信する受信機と、を備える放送通信連携システムにおけるサーバを制御するコンピュータを、
別サーバにおいて、前記受信機からのコンテンツのリクエストに従って、自機に対するリクエストであって、前記コンテンツを加工して前記別サーバに送信させるリクエストがＷｅｂ ＡＰＩで生成されて、送信されてきた場合、前記リクエストを解析して処理させる制御を実行するＡＰＩ手段、
前記ＡＰＩにより解析された前記リクエストに従って、前記コンテンツを加工する加工手段、
前記ＡＰＩにより解析された前記リクエストに従って、前記加工手段により加工された前記コンテンツを、前記ＡＰＩを介して前記別サーバに配信させる制御を実行する配信管理手段、
として機能させるプログラム。
【請求項１】
放送局と、前記放送局により管理される第１サーバと、前記第１サーバと通信する第２サーバと、前記第２サーバと通信すると共に前記放送局から放送された放送信号を受信する受信機と、を備える放送通信連携システムであって、
前記受信機は、前記第２サーバに対してコンテンツをリクエストし、
前記第２サーバは、前記受信機からの前記リクエストを受けて、前記第１サーバに対して、Ｗｅｂ ＡＰＩで、前記コンテンツを加工して自機に送信することをリクエストし、
前記第１サーバは、Ｗｅｂ ＡＰＩでの前記リクエストに従って、前記コンテンツを加工して、加工後の前記コンテンツを前記第２サーバに送信し、
前記第２サーバは、前記第１サーバから送信された前記コンテンツを受信して、前記受信機に送信し、
前記受信機は、前記第２サーバから送信された前記コンテンツを受信する、
放送通信連携システム。
【請求項２】
前記第２サーバは、前記第１サーバから受信した前記コンテンツをさらに加工して、加工後の前記コンテンツを前記受信機に送信する、
請求項１に記載の放送通信連携システム。
【請求項３】
放送局と、サーバ群と、前記サーバ群と通信すると共に前記放送局から放送された放送信号を受信する受信機と、を備える放送通信連携システムにおけるサーバであって、
前記受信機からのコンテンツのリクエストを受信する第１通信手段と、
前記第１通信手段に受信された前記リクエストに従って、前記放送局により管理される別サーバに対するリクエストであって、前記コンテンツを加工して自機に送信させるリクエストをＷｅｂ ＡＰＩで生成する生成手段と、
前記生成手段により前記Ｗｅｂ ＡＰＩで生成された前記リクエストを前記別サーバに送信する第２通信手段と、
を備え、
前記別サーバにおいて、前記Ｗｅｂ ＡＰＩによるリクエストに従って、前記コンテンツが加工されて送信されてきた場合、前記第２通信手段は前記コンテンツを受信し、前記第１通信手段は前記コンテンツを前記受信機に送信する、
サーバ。
【請求項４】
前記別サーバから受信した前記コンテンツを加工する加工手段をさらに備え、前記第１通信手段は、前記加工手段による加工後の前記コンテンツを、前記受信機に送信する、
請求項３に記載のサーバ。
【請求項５】
放送局と、サーバ群と、前記サーバ群と通信すると共に前記放送局から放送された放送信号を受信する受信機と、を備える放送通信連携システムにおけるサーバを制御するコンピュータを、
前記受信機からのコンテンツのリクエストを前記サーバに受信させる制御を実行する第１通信制御手段、
前記第１通信制御手段の制御により前記サーバに受信された前記リクエストに従って、前記放送局により管理される別サーバに対するリクエストであって、前記コンテンツを加工して自機に送信させるリクエストをＷｅｂ ＡＰＩで生成する生成手段、
前記生成手段により前記Ｗｅｂ ＡＰＩで生成された前記リクエストを前記サーバから前記別サーバに送信させる制御を実行する第２通信制御手段、
として機能させ、
前記別サーバにおいて、前記Ｗｅｂ ＡＰＩによるリクエストに従って、前記コンテンツが加工されて送信されてきた場合、前記第２通信制御手段として機能するコンピュータは、前記コンテンツを前記サーバに受信させる制御を実行し、前記第１通信制御手段として機能するコンピュータは、前記コンテンツを前記サーバから前記受信機に送信させる制御を実行する、
プログラム。
【請求項６】
放送局と、サーバ群と、前記サーバ群と通信すると共に前記放送局から放送された放送信号を受信する受信機と、を備える放送通信連携システムにおけるサーバであって、
別サーバにおいて、前記受信機からのコンテンツのリクエストに従って、自機に対するリクエストであって、前記コンテンツを加工して前記別サーバに送信させるリクエストがＷｅｂ ＡＰＩで生成されて、送信されてきた場合、前記リクエストを解析して処理するＡＰＩと、
前記ＡＰＩにより解析された前記リクエストに従って、前記コンテンツを加工する加工手段と、
前記ＡＰＩにより解析された前記リクエストに従って、前記加工手段により加工された前記コンテンツを、前記ＡＰＩを介して前記別サーバに配信する配信管理手段と、
を備えるサーバ。
【請求項７】
放送局と、サーバ群と、前記サーバ群と通信すると共に前記放送局から放送された放送信号を受信する受信機と、を備える放送通信連携システムにおけるサーバを制御するコンピュータを、
別サーバにおいて、前記受信機からのコンテンツのリクエストに従って、自機に対するリクエストであって、前記コンテンツを加工して前記別サーバに送信させるリクエストがＷｅｂ ＡＰＩで生成されて、送信されてきた場合、前記リクエストを解析して処理させる制御を実行するＡＰＩ手段、
前記ＡＰＩにより解析された前記リクエストに従って、前記コンテンツを加工する加工手段、
前記ＡＰＩにより解析された前記リクエストに従って、前記加工手段により加工された前記コンテンツを、前記ＡＰＩを介して前記別サーバに配信させる制御を実行する配信管理手段、
として機能させるプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２０１２−２４４４０８（Ｐ２０１２−２４４４０８Ａ）
【公開日】平成２４年１２月１０日（２０１２．１２．１０）
【国際特許分類】
【出願番号】特願２０１１−１１２５３６（Ｐ２０１１−１１２５３６）
【出願日】平成２３年５月１９日（２０１１．５．１９）
【出願人】（０００００４３５２）日本放送協会 (2,206)
【Ｆターム（参考）】
【公開日】平成２４年１２月１０日（２０１２．１２．１０）
【国際特許分類】
【出願日】平成２３年５月１９日（２０１１．５．１９）
【出願人】（０００００４３５２）日本放送協会 (2,206)
【Ｆターム（参考）】
[ Back to top ]