(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022183548
(43)【公開日】2022-12-13
(54)【発明の名称】受信装置、クライアント端末装置、およびプログラム
(51)【国際特許分類】
H04N 21/436 20110101AFI20221206BHJP
H04N 21/4402 20110101ALI20221206BHJP
【ＦＩ】
H04N21/436
H04N21/4402
【審査請求】未請求
【請求項の数】21
【出願形態】ＯＬ
(21)【出願番号】P 2021090915
(22)【出願日】2021-05-31
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡＳＣＲＩＰＴ
(71)【出願人】
【識別番号】000004352
【氏名又は名称】日本放送協会
(74)【代理人】
【識別番号】100141139
【弁理士】
【氏名又は名称】及川 周
(74)【代理人】
【識別番号】100171446
【弁理士】
【氏名又は名称】高田 尚幸
(74)【代理人】
【識別番号】100114937
【弁理士】
【氏名又は名称】松本 裕幸
(74)【代理人】
【識別番号】100171930
【弁理士】
【氏名又は名称】木下 郁一郎
(72)【発明者】
【氏名】瀧口 徹
(72)【発明者】
【氏名】藤沢 寛
(72)【発明者】
【氏名】松村 欣司
(72)【発明者】
【氏名】大西 正芳
【テーマコード（参考）】
5C164
【Ｆターム（参考）】
5C164FA04
5C164FA11
5C164PA36
5C164TB31S
5C164UA03S
5C164UA04S
5C164UB02P
5C164UB71P
(57)【要約】
【課題】受信装置からクライアント端末装置に対して放送リソースに基づくウェブリソースを提供するシステムにおいて、相互接続性を高くする。
【解決手段】受信装置において、受信部は、放送信号を受信する。トランスコード部は、受信された前記放送信号から抽出されたリソースのデータを、ウェブプラットフォームで利用可能な形式のデータにトランスコードして、ウェブリソースとして出力する。ウェブリソース提要部は、外部のクライアント端末装置からの視聴要求に応じて、前記トランスコード部が出力する前記ウェブリソースを、通信を介して、前記クライアント端末装置に対して送信する。クライアント端末連携制御部は、ハイブリッドキャストコネクトの機能により前記クライアント端末装置との連携動作を制御するとともに、前記ウェブリソースを利用するために必要な情報を前記クライアント端末装置に送信する。
【選択図】図１
【解決手段】受信装置において、受信部は、放送信号を受信する。トランスコード部は、受信された前記放送信号から抽出されたリソースのデータを、ウェブプラットフォームで利用可能な形式のデータにトランスコードして、ウェブリソースとして出力する。ウェブリソース提要部は、外部のクライアント端末装置からの視聴要求に応じて、前記トランスコード部が出力する前記ウェブリソースを、通信を介して、前記クライアント端末装置に対して送信する。クライアント端末連携制御部は、ハイブリッドキャストコネクトの機能により前記クライアント端末装置との連携動作を制御するとともに、前記ウェブリソースを利用するために必要な情報を前記クライアント端末装置に送信する。
【選択図】図１
【特許請求の範囲】
【請求項1】
放送信号を受信する受信部と、
ハイブリッドキャストの端末連携機能により外部のクライアント端末装置との連携動作を制御するとともに、前記放送信号から抽出されるリソースのデータを、ウェブプラットフォームで利用可能な形式のウェブリソースとして利用するために必要な情報を前記クライアント端末装置に送信するクライアント端末連携制御部と、
を備え、
クライアント端末連携制御部は、少なくとも、前記ウェブリソースを利用するためのロケーションの情報を前記クライアント端末装置に送信する、
受信装置。
ハイブリッドキャストの端末連携機能により外部のクライアント端末装置との連携動作を制御するとともに、前記放送信号から抽出されるリソースのデータを、ウェブプラットフォームで利用可能な形式のウェブリソースとして利用するために必要な情報を前記クライアント端末装置に送信するクライアント端末連携制御部と、
を備え、
クライアント端末連携制御部は、少なくとも、前記ウェブリソースを利用するためのロケーションの情報を前記クライアント端末装置に送信する、
受信装置。
【請求項2】
受信された前記放送信号から抽出された映像および音声のリソースのデータを、ウェブプラットフォームで利用可能な形式のデータにトランスコードして、映像および音声のウェブリソースとして出力するトランスコード部と、
前記クライアント端末装置からの視聴要求に応じて、前記トランスコード部が出力する前記映像および音声のウェブリソースを、通信を介して、前記クライアント端末装置に対して送信するウェブリソース提供部と、
をさらに備え、
前記クライアント端末連携制御部は、前記ウェブリソース提供部が送信する前記映像および音声のウェブリソースを利用するためのロケーションの情報を前記クライアント端末装置に送信する、
請求項１に記載の受信装置。
前記クライアント端末装置からの視聴要求に応じて、前記トランスコード部が出力する前記映像および音声のウェブリソースを、通信を介して、前記クライアント端末装置に対して送信するウェブリソース提供部と、
をさらに備え、
前記クライアント端末連携制御部は、前記ウェブリソース提供部が送信する前記映像および音声のウェブリソースを利用するためのロケーションの情報を前記クライアント端末装置に送信する、
請求項１に記載の受信装置。
【請求項3】
前記クライアント端末連携制御部は、前記クライアント端末装置からの、前記ウェブリソースを提供する機器を発見するためのリクエストに対応して、前記ウェブリソースを利用するためのロケーションの情報を前記クライアント端末装置に送信する、
請求項１または２に記載の受信装置。
請求項１または２に記載の受信装置。
【請求項4】
前記クライアント端末連携制御部は、前記クライアント端末装置からの、前記ウェブリソースの利用可否の情報を取得するためのリクエストに対応して、前記ウェブリソースの利用可否の情報を前記クライアント端末装置に送信する、
請求項１から３までのいずれか一項に記載の受信装置。
請求項１から３までのいずれか一項に記載の受信装置。
【請求項5】
前記クライアント端末連携制御部は、前記ウェブリソースの、少なくとも映像と音声と字幕とＳＩ（サービス情報）とＥＰＧ（電子番組表）とＥＭ（イベントメッセージ）とＡＩＴ（アプリケーション情報テーブルとのいずれかの種別ごとの利用可否の情報を、前記クライアント端末装置に送信する、
請求項４に記載の受信装置。
請求項４に記載の受信装置。
【請求項6】
前記クライアント端末連携制御部は、前記クライアント端末装置からの、ウェブサービス一覧を取得するためのリクエストに対応して、提供可能な前記ウェブリソースの、ウェブサービス一覧の情報を前記クライアント端末装置に送信する、
請求項１から５までのいずれか一項に記載の受信装置。
請求項１から５までのいずれか一項に記載の受信装置。
【請求項7】
前記クライアント端末連携制御部は、外部のウェブ編成情報管理サーバー装置から取得した前記ウェブサービス一覧の情報を前記クライアント端末装置に送信する、
請求項６に記載の受信装置。
請求項６に記載の受信装置。
【請求項8】
前記クライアント端末連携制御部は、前記クライアント端末装置からの、前記トランスコード部による処理の開始または終了、あるいは前記トランスコード部による処理のためのパラメーターの設定、のリクエストに応じて、前記トランスコード部を制御する、
請求項２に記載の受信装置。
請求項２に記載の受信装置。
【請求項9】
前記クライアント端末連携制御部は、前記クライアント端末装置からの、ウェブサービスの起動可否状態の情報を取得するためのリクエストに対応して、前記ウェブサービスの起動可否状態の情報を前記クライアント端末装置に送信する、
請求項１から８までのいずれか一項に記載の受信装置。
請求項１から８までのいずれか一項に記載の受信装置。
【請求項10】
前記クライアント端末連携制御部は、前記クライアント端末装置からの、前記トランスコード部が実行中であるか否かを表すウェブサービス状態の情報、を取得するためのリクエストに対応して、前記ウェブサービス状態の情報を前記クライアント端末装置に送信する、
請求項２に記載の受信装置。
請求項２に記載の受信装置。
【請求項11】
請求項１に記載の受信装置から前記ウェブリソースを受信して利用するウェブアプリケーションを稼働させるアプリケーションエンジンと、
ハイブリッドキャストの端末連携機能により、前記ウェブリソースを利用するために必要な処理を、前記受信装置との連携動作として実行する受信端末連携制御部と、
を備え、
受信端末連携制御部は、少なくとも、前記ウェブリソースを利用するためのロケーションの情報を前記受信装置から受信する、
クライアント端末装置。
ハイブリッドキャストの端末連携機能により、前記ウェブリソースを利用するために必要な処理を、前記受信装置との連携動作として実行する受信端末連携制御部と、
を備え、
受信端末連携制御部は、少なくとも、前記ウェブリソースを利用するためのロケーションの情報を前記受信装置から受信する、
クライアント端末装置。
【請求項12】
前記受信端末連携制御部は、前記受信装置に前記ウェブリソースを提供する機器を発見するためのリクエストを送信し、前記ウェブリソースを提供する機器を発見するためのリクエストに対応して前記受信装置が送信した前記ウェブリソースを利用するためのロケーションの情報を受信する、
請求項１１に記載のクライアント端末装置。
請求項１１に記載のクライアント端末装置。
【請求項13】
前記受信端末連携制御部は、前記受信装置に前記ウェブリソースの利用可否の情報を取得するためのリクエストを送信し、前記受信装置に前記ウェブリソースの利用可否の情報を取得するためのリクエストに対応して前記受信装置が送信する前記ウェブリソースの利用可否の情報を、前記受信装置から受信する、
請求項１１または１２に記載のクライアント端末装置。
請求項１１または１２に記載のクライアント端末装置。
【請求項14】
前記受信端末連携制御部は、前記ウェブリソースの、少なくとも映像と音声と字幕とＳＩ（サービス情報）とＥＰＧ（電子番組表）とＥＭ（イベントメッセージ）とＡＩＴ（アプリケーション情報テーブルとのいずれかの種別ごとの利用可否の情報を、前記受信装置から受信する、
請求項１３に記載のクライアント端末装置。
請求項１３に記載のクライアント端末装置。
【請求項15】
前記受信端末連携制御部は、前記受信装置にウェブサービス一覧を取得するためのリクエストを送信し、ウェブサービス一覧を取得するためのリクエストに対応して前記受信装置が送信する前記ウェブサービス一覧の情報を、前記受信装置から受信する、
請求項１１から１４までのいずれか一項に記載のクライアント端末装置。
請求項１１から１４までのいずれか一項に記載のクライアント端末装置。
【請求項16】
前記受信端末連携制御部は、前記受信装置が外部のウェブ編成情報管理サーバー装置から取得した前記ウェブサービス一覧の情報を、前記受信装置から受信する、
請求項１５に記載のクライアント端末装置。
請求項１５に記載のクライアント端末装置。
【請求項17】
前記受信端末連携制御部は、請求項２に記載の受信装置側における前記トランスコード部による処理の開始または終了、あるいは前記トランスコード部による処理のためのパラメーターの設定、のリクエストを、前記受信装置に送信する、
請求項１１から１６までのいずれか一項に記載のクライアント端末装置。
請求項１１から１６までのいずれか一項に記載のクライアント端末装置。
【請求項18】
前記受信端末連携制御部は、ウェブサービスの起動可否状態の情報を取得するためのリクエストを前記受信装置に対して送信し、ウェブサービスの起動可否状態の情報を取得するためのリクエストに対応して前記受信装置が送信する前記ウェブサービスの起動可否状態の情報を、前記受信装置から受信する、
請求項１１から１７までのいずれか一項に記載のクライアント端末装置。
請求項１１から１７までのいずれか一項に記載のクライアント端末装置。
【請求項19】
前記受信端末連携制御部は、前記受信装置において前記トランスコード部が実行中であるか否かを表すウェブサービス状態の情報、を取得するためのリクエストを前記受信装置に送信し、前記ウェブサービス状態の情報を取得するためのリクエストに対応して前記受信装置が送信する前記ウェブサービス状態の情報を、前記受信装置から受信する、
請求項１１から１８までのいずれか一項に記載のクライアント端末装置。
請求項１１から１８までのいずれか一項に記載のクライアント端末装置。
【請求項20】
放送信号を受信する受信部、を備えるコンピューターを、
請求項１から１０までのいずれか一項に記載の受信装置、
として機能させるためのプログラム。
請求項１から１０までのいずれか一項に記載の受信装置、
として機能させるためのプログラム。
【請求項21】
コンピューターを、
請求項１１から１９までのいずれか一項に記載のクライアント端末装置、
として機能させるためのプログラム。
請求項１１から１９までのいずれか一項に記載のクライアント端末装置、
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、受信装置、クライアント端末装置、およびプログラムに関する。
【背景技術】
【0002】
従来技術において、テレビ受信機は、放送波に含まれる様々なリソース（映像、音声、字幕など）を活用する。このような放送に含まれるリソースの活用は、基本的に放送チューナーを有するテレビ受信機等に限られていたものである。
【0003】
これに対して、放送波に含まれるリソースをウェブプラットフォームで利活用できるようにするための技術の普及が進みつつある。このような技術では、テレビ受信機以外の端末装置（例えば、ウェブクライアント端末）でも放送に含まれるリソースの活用が可能となる。例えば、日本国外の規格であるＡＴＳＣ ３．０規格（ＡＴＳＣは、「Advanced Television Systems Committee」の略）に準拠したテレビ受信機などは、配信サーバーの役割を担うことができる。即ち、そのようなテレビ受信機は、受信した放送映像などを別の端末装置に対して配信することができる。
【0004】
一方、日本の放送規格（ＩＳＤＢ－Ｔなど）では、様々な電機メーカーが提供する録画機などによってリモート視聴のサービスが提供されている。非特許文献１には、リモート視聴について記載されている。
【0005】
標準化された技術としては、テレビ受信機と視聴端末とが連携するための仕組みである、ハイブリッドキャストの端末連携機能が存在する。この機能は、「ハイブリッドキャストコネクト」あるいは「ハイコネ」と呼ばれる。ハイブリッドキャストの端末連携機能の技術標準では、発見・接続・データ送受信プロトコルなどが提供されている。非特許文献２には、ハイブリッドキャストの端末連携機能の規定が含まれる。
【先行技術文献】
【非特許文献】
【0006】
【非特許文献1】「デジタル放送のリモート視聴について」，一般社団法人放送サービス高度化推進協会，［online］，［2021年4月10日ダウンロード］，インターネット＜URL：https://www.apab.or.jp/remote-viewing/pdf/remote-viewing.pdf＞
【非特許文献2】「IPTVフォーラム標準規格,運用規定」，一般社団法人IPTVフォーラム， IPTVFJ-STD0010 2.3版・IPTVFJ-STD0011 2.6版・IPTVFJ-STD0013 2.9版，[2020年10月2日]，インターネット＜URL：https://www.iptvforum.jp/download/input.html＞
【発明の概要】
【発明が解決しようとする課題】
【0007】
しかしながら、従来技術には、次のような解決すべき課題が存在する。
【0008】
非特許文献１に記載されているリモート視聴のしくみでは、テレビ受信機と視聴端末（およびその端末上で動作するアプリケーションプログラム）の組合せが、メーカーごとに固定されている。その理由としては、テレビ受信機と視聴端末との間での発見・接続プロトコルや、コンテンツ保護のための技術として、メーカーごとの独自技術が用いられていることが考えられる。つまり、テレビ受信機と視聴端末との間の相互接続性が向上しないという問題がある。このような事情により、ユーザーの利便性が向上せず、技術の普及が阻害されているという問題がある。
【0009】
非特許文献２に記載されているハイブリッドキャストの端末連携機能のしくみでは、視聴端末において、放送波のリソースを取得して動画再生を行ったり字幕を表示したりすることができないという問題がある。
【0010】
つまり、標準的な技術でテレビ受信機と視聴端末との間の相互接続性を高めるためには、ハイブリッドキャストの端末連携機能の標準技術を拡張して、放送波に含まれる様々なリソースを視聴端末で活用できるようにすることが望まれる。
【0011】
つまり、具体的には、放送波のリソースに含まれる映像や音声や字幕等のデータを、ウェブの標準的なインターフェースで活用できるようにすることが望まれる。また、テレビ受信装置（受信端末装置）が提供するウェブのリソースを、視聴端末（クライアント端末装置）で活用できるようにすることが望まれる。
【0012】
本発明は、上記の課題認識に基づいて行なわれたものであり、受信装置（テレビ受信機）からクライアント端末装置（視聴端末）に対して放送リソースに基づくウェブリソースを提供するシステムにおいて、相互接続性の高い受信装置、クライアント端末装置、およびプログラムを提供しようとするものである。
【課題を解決するための手段】
【0013】
［１］上記の課題を解決するため、本発明の一態様による受信装置は、放送信号を受信する受信部と、ハイブリッドキャストの端末連携機能により外部のクライアント端末装置との連携動作を制御するとともに、前記放送信号から抽出されるリソースのデータを、ウェブプラットフォームで利用可能な形式のウェブリソースとして利用するために必要な情報を前記クライアント端末装置に送信するクライアント端末連携制御部と、を備え、クライアント端末連携制御部は、少なくとも、前記ウェブリソースを利用するためのロケーションの情報を前記クライアント端末装置に送信する、ものである。
【0014】
［２］また、本発明の一態様は、上記の受信装置において、受信された前記放送信号から抽出された映像および音声のリソースのデータを、ウェブプラットフォームで利用可能な形式のデータにトランスコードして、映像および音声のウェブリソースとして出力するトランスコード部と、前記クライアント端末装置からの視聴要求に応じて、前記トランスコード部が出力する前記映像および音声のウェブリソースを、通信を介して、前記クライアント端末装置に対して送信するウェブリソース提供部と、をさらに備え、前記クライアント端末連携制御部は、前記ウェブリソース提供部が送信する前記映像および音声のウェブリソースを利用するためのロケーションの情報を前記クライアント端末装置に送信する、ものである。
【0015】
［３］また、本発明の一態様は、上記の受信装置において、前記クライアント端末連携制御部は、前記クライアント端末装置からの、前記ウェブリソースを提供する機器を発見するためのリクエストに対応して、前記ウェブリソースを利用するためのロケーションの情報を前記クライアント端末装置に送信する、というものである。
【0016】
［４］また、本発明の一態様は、上記の受信装置において、前記クライアント端末連携制御部は、前記クライアント端末装置からの、前記ウェブリソースの利用可否の情報を取得するためのリクエストに対応して、前記ウェブリソースの利用可否の情報を前記クライアント端末装置に送信する、というものである。
【0017】
［５］また、本発明の一態様は、上記の受信装置において、前記クライアント端末連携制御部は、前記ウェブリソースの、少なくとも映像と音声と字幕とＳＩ（サービス情報）とＥＰＧ（電子番組表）とＥＭ（イベントメッセージ）とＡＩＴ（アプリケーション情報テーブルとのいずれかの種別ごとの利用可否の情報を、前記クライアント端末装置に送信する、というものである。
【0018】
［６］また、本発明の一態様は、上記の受信装置において、前記クライアント端末連携制御部は、前記クライアント端末装置からの、ウェブサービス一覧を取得するためのリクエストに対応して、提供可能な前記ウェブリソースの、ウェブサービス一覧の情報を前記クライアント端末装置に送信する、というものである。
【0019】
［７］また、本発明の一態様は、上記の受信装置において、前記クライアント端末連携制御部は、外部のウェブ編成情報管理サーバー装置から取得した前記ウェブサービス一覧の情報を前記クライアント端末装置に送信する、というものである。
【0020】
［８］また、本発明の一態様は、上記の受信装置において、前記クライアント端末連携制御部は、前記クライアント端末装置からの、前記トランスコード部による処理の開始または終了、あるいは前記トランスコード部による処理のためのパラメーターの設定、のリクエストに応じて、前記トランスコード部を制御する、ものである。
【0021】
［９］また、本発明の一態様は、上記の受信装置において、前記クライアント端末連携制御部は、前記クライアント端末装置からの、ウェブサービスの起動可否状態の情報を取得するためのリクエストに対応して、前記ウェブサービスの起動可否状態の情報を前記クライアント端末装置に送信する、というものである。
【0022】
［１０］また、本発明の一態様は、上記の受信装置において、前記クライアント端末連携制御部は、前記クライアント端末装置からの、前記トランスコード部が実行中であるか否かを表すウェブサービス状態の情報、を取得するためのリクエストに対応して、前記ウェブサービス状態の情報を前記クライアント端末装置に送信する、ものである。
【0023】
［１１］また、本発明の一態様によるクライアント端末装置は、上の［１］に記載の受信装置から前記ウェブリソースを受信して利用するウェブアプリケーションを稼働させるアプリケーションエンジンと、ハイブリッドキャストの端末連携機能（ハイブリッドキャストコネクトの機能）により、前記ウェブリソースを利用するために必要な処理を、前記受信装置との連携動作として実行する受信端末連携制御部と、を備え、受信端末連携制御部は、少なくとも、前記ウェブリソースを利用するためのロケーションの情報を前記受信装置から受信する、というものである。
【0024】
［１２］また、本発明の一態様は、上記のクライアント端末装置において、前記受信端末連携制御部は、前記受信装置に前記ウェブリソースを提供する機器を発見するためのリクエストを送信し、前記ウェブリソースを提供する機器を発見するためのリクエストに対応して前記受信装置が送信した前記ウェブリソースを利用するためのロケーションの情報を受信する、というものである。
【0025】
［１３］また、本発明の一態様は、上記のクライアント端末装置において、前記受信端末連携制御部は、前記受信装置に前記ウェブリソースの利用可否の情報を取得するためのリクエストを送信し、前記受信装置に前記ウェブリソースの利用可否の情報を取得するためのリクエストに対応して前記受信装置が送信する前記ウェブリソースの利用可否の情報を、前記受信装置から受信する、というものである。
【0026】
［１４］また、本発明の一態様は、上記のクライアント端末装置において、前記受信端末連携制御部は、前記ウェブリソースの、少なくとも映像と音声と字幕とＳＩ（サービス情報）とＥＰＧ（電子番組表）とＥＭ（イベントメッセージ）とＡＩＴ（アプリケーション情報テーブルとのいずれかの種別ごとの利用可否の情報を、前記受信装置から受信する、というものである。
【0027】
［１５］また、本発明の一態様は、上記のクライアント端末装置において、前記受信端末連携制御部は、前記受信装置にウェブサービス一覧を取得するためのリクエストを送信し、ウェブサービス一覧を取得するためのリクエストに対応して前記受信装置が送信する前記ウェブサービス一覧の情報を、前記受信装置から受信する、というものである。
【0028】
［１６］また、本発明の一態様は、上記のクライアント端末装置において、前記受信端末連携制御部は、前記受信装置が外部のウェブ編成情報管理サーバー装置から取得した前記ウェブサービス一覧の情報を、前記受信装置から受信する。
【0029】
［１７］また、本発明の一態様は、上記のクライアント端末装置において、前記受信端末連携制御部は、上の［２］に記載の受信装置側における前記トランスコード部による処理の開始または終了、あるいは前記トランスコード部による処理のためのパラメーターの設定、のリクエストを、前記受信装置に送信する、というものである。
【0030】
［１８］また、本発明の一態様は、上記のクライアント端末装置において、前記受信端末連携制御部は、ウェブサービスの起動可否状態の情報を取得するためのリクエストを前記受信装置に対して送信し、ウェブサービスの起動可否状態の情報を取得するためのリクエストに対応して前記受信装置が送信する前記ウェブサービスの起動可否状態の情報を、前記受信装置から受信する、というものである。
【0031】
［１９］また、本発明の一態様は、上記のクライアント端末装置において、前記受信端末連携制御部は、前記受信装置において前記トランスコード部が実行中であるか否かを表すウェブサービス状態の情報、を取得するためのリクエストを前記受信装置に送信し、前記ウェブサービス状態の情報を取得するためのリクエストに対応して前記受信装置が送信する前記ウェブサービス状態の情報を、前記受信装置から受信する、というものである。
【0032】
［２０］また、本発明の一態様は、放送信号を受信する受信部、を備えるコンピューターを、上の［１］から［１０］までのいずれか一項に記載の受信装置、として機能させるためのプログラムである。
【0033】
［２１］また、本発明の一態様は、コンピューターを、上の［１１］から［１９］までのいずれか一項に記載のクライアント端末装置、として機能させるためのプログラムである。
【発明の効果】
【0034】
本発明によれば、標準的な技術であるハイブリッドキャストの端末連携機能を用いて、相互接続性が高い状態で、受信装置が受信した放送リソースに基づくウェブリソースを、クライアント端末装置に提供する制御を行うことが可能となる。
【図面の簡単な説明】
【0035】
【図1】本発明の実施形態によるシステムの構成を示すブロック図である。
【図2】同実施形態による受信端末装置の機能構成を示す機能ブロック図である。
【図3】同実施形態において拡張されたハイブリッドキャストの端末連携機能の機能を用いた、受信端末装置とクライアント端末装置との間での、リクエストおよびレスポンスのシーケンスの例を示す概略図（その１）である。
【図5】同実施形態による受信端末装置が送信するメッセージであり、ウェブリソースのエンドポイント情報を含んだメッセージの記述例を示す概略図である。
【図6】同実施形態によるクライアント端末装置による、プロトコルのバージョン番号の情報に基づいた動作の例を示すフローチャートである。
【図7】同実施形態によるクライアント端末装置から受信端末装置に対して送信されるウェブリソース利用可否取得リクエストを示す概略図である。
【図8】同実施形態における、上記のウェブリソース利用可否取得のリクエストに対応するレスポンスのデータを示す概略図である。
【図9】同実施形態によるウェブリソース利用可否取得のレスポンスのデータの別例（変形例）を示す概略図である。
【図10】同実施形態において、ウェブリソース利用可否の受け渡しのために、利用可能メディア取得ＡＰＩを拡張した結果であるレスポンスデータの構成を示す概略図である。
【図11】同実施形態によるクライアント端末装置から受信端末装置に対して送信されるウェブリソース利用可否取得のリクエストを示す概略図である。
【図12】同実施形態における、上記のウェブサービス一覧取得のリクエストに対応するレスポンスのデータを示す概略図である。
【図13】同実施形態によるクライアント端末装置から受信端末装置に対して送信される編成サービス一覧取得のリクエスト（ウェブサービス一覧を取得するよう拡張）を示す概略図である。
【図14】同実施形態によるクライアント端末装置が、外部のサーバー装置から提供されるウェブリソースの編成情報を取得するためのシステムの構成および手順を示すブロック図である。
【図15】同実施形態による編成サービス一覧取得のレスポンスとして、受信端末装置がクライアント端末装置に対して送信するデータ（ウェブリソースを含むよう拡張されたレスポンス）の例を示す概略図である。
【図16】同実施形態によるクライアント端末装置から受信端末装置に対して送信されるウェブサービス起動要求のリクエストを示す概略図である。
【図18】同実施形態において、上記のウェブサービス起動要求のリクエストに対応するレスポンスの例を示す概略図である。
【図19】同実施形態によるクライアント端末装置から受信端末装置に対して送信される選局・ＨＣアプリ起動要求のリクエスト（ウェブサービスの起動要求を行えるように拡張）を示す概略図である。
【図21】同実施形態による上記の選局・ＨＣアプリ起動要求（ウェブサービスの起動要求を含む）のリクエストに対応するレスポンスのデータの例を示す概略図である。
【図22】同実施形態によるクライアント端末装置３から受信端末装置２に対して送信されるウェブサービス起動可否状態取得のリクエストを示す概略図である。
【図24】同実施形態における起動可否状態取得のＡＰＩを拡張（ウェブ起動可否状態を取得できるように拡張）したときのレスポンスのデータ例を示す概略図である。
【図25】同実施形態によるクライアント端末装置から受信端末装置に対して送信されるウェブサービス状態取得のリクエストを示す概略図である。
【図27】同実施形態によるウェブサービス状態取得のリクエストに対応して返されるレスポンスデータ（各サービスの個別の状態を含むように拡張）の例を示す概略図である。
【図28】同実施形態による受信機状態取得のリクエストに対応して返される拡張されたレスポンスデータの例を示す概略図である。
【図29】同実施形態によるクライアント端末装置の内部の概略機能構成を示すブロック図である。
【図30】同実施形態によるシステムを構成する各装置の内部構成の例を示すブロック図である。
【発明を実施するための形態】
【0036】
次に、本発明の一実施形態について、図面を参照しながら説明する。
【0037】
本実施形態では、受信端末装置２は、放送波のリソースをウェブのプラットフォームで利活用できるようにするための機能を持つ。また、クライアント端末装置３は、受信端末装置２によって提供されるウェブのリソースを活用するための機能を持つ。受信端末装置２とクライアント端末装置３とのそれぞれは、ハイブリッドキャストコネクト（ハイコネ、ハイブリッドキャストの端末連携機能）の拡張機能によって上記機能を実現する。
【0038】
図１は、本実施形態によるシステムの構成を示すブロック図である。図示するように、システム１は、受信端末装置２と、クライアント端末装置３と、アンテナ４と、ルーター８とを含んで構成される。受信端末装置２は、「受信装置」とも呼ばれる。システム１においては、受信端末装置２とクライアント端末装置３とが、ハイブリッドキャストの端末連携機能によって連携動作する。これにより、クライアント端末装置３は、受信端末装置２から提供される放送のリソースに基づくコンテンツを、提示することができる。なお、この図では、受信端末装置２、クライアント端末装置３、ルーター８をそれぞれ１台ずつ示しているが、システム１が含むこれらそれぞれの装置の台数は任意である。例えば複数の受信端末装置２あるいはクライアント端末装置３が１つのローカルネットワークに接続されてシステム１を構成していてもよい。システム１を構成するそれぞれの装置の機能については、次に説明する。
【0039】
受信端末装置２は、アンテナ４を介して放送信号（高周波、ＲＦ）を受信する。受信端末装置２は、デジタル方式の放送信号を復調および復号し、放送信号に含まれる映像や音声や字幕等のリソースを抽出する。つまり、受信端末装置２は、いわゆるテレビ受像機である。受信端末装置２は、ローカルエリアネットワークを介して、インターネットプロトコル（ＩＰ）により、クライアント端末装置３との間で通信を行う。つまり、受信端末装置２は、ルーター８経由で、クライアント端末装置３と通信を行うことができる。受信端末装置２は、無線または有線の通信によりルーター８にアクセスすることができる。受信端末装置２上では、アプリケーションプログラム（以下、「アプリ」と呼ぶ場合がある）を稼働させることができる。受信端末装置２は、ハイブリッドキャストの端末連携機能を用いて、クライアント端末装置３と連携動作する。なお、受信端末装置２の詳細な機能構成については、後で別の図を参照しながら説明する。
【0040】
クライアント端末装置３は、受信端末装置２と連携する端末装置である。クライアント端末装置３は、具体的には、ＰＣ（パーソナルコンピューター）や、タブレット端末や、スマートフォンや、スマートスピーカー等の装置であってよい。クライアント端末装置３は、アプリを稼働させることができる。クライアント端末装置３上では、受信端末装置２と連携動作するためのアプリが稼働する。クライアント端末装置３は、ハイブリッドキャストの端末連携機能を用いて、受信端末装置２と連携動作する。クライアント端末装置３は、受信端末装置２に対して、ウェブリソースを視聴するための各種の要求（リクエスト）を送信する。クライアント端末装置３は、リクエストした結果に応じて、ウェブリソースを利用することができる。即ち、クライアント端末装置３は、ウェブリソースをユーザー（視聴者）に提示する。なお、クライアント端末装置３自体は、放送信号を直接受信するためのチューナーの機能を持つ必要がない。
【0041】
アンテナ４は、上記の放送信号を受信するためのものである。アンテナ４は、空中波として捉えた放送信号を、電気信号として受信端末装置２に供給する。
【0042】
ルーター８は、上記のローカルエリアネットワークを構成する機器のひとつである。ルーター８は、ローカルエリアネットワークに接続されている送信元の装置から送信されるＩＰパケットを、宛先の装置側に向けて転送する。図示する構成においては、ルーター８がＩＰパケットを転送することにより、受信端末装置２とクライアント端末装置３とが相互に通信を行うことが可能となる。
【0043】
図２は、受信端末装置２の機能構成を示す機能ブロック図である。受信端末装置２は、放送波（放送信号）が含む映像や音声や字幕などといったリソースを、ウェブのプラットフォームで活用可能とするための機能を持つ。具体的には、図示するように、受信端末装置２は、チューナー部２０１と、デスクランブラー２０２と、デマルチプレクサー２０３と、データ放送処理部２１１と、映像デコーダー部２１２と、音声デコーダー部２１３と、字幕デコーダー部２１４と、データ放送エンジン２２１と、通信部２３１と、ストリーミング受信部２３２と、デマルチプレクサー２３３と、映像デコーダー部２４２と、音声デコーダー部２４３と、字幕デコーダー部２４４と、アプリケーション制御部２５１と、アプリケーションエンジン２５２と、アプリケーションロンチャー２５３と、トランスコード部２６１と、ウェブリソース提供部２６２と、クライアント端末連携制御部２６３と、映像出力部２７１と、音声出力部２７２と、を含んで構成される。
【0044】
受信端末装置２の各機能部は、例えば、電子回路を用いて構成される。また、受信端末装置２が持つ少なくとも一部の機能を、コンピューターと、プログラムとで実現することが可能である。また、各機能部は、必要に応じて、記憶手段を有する。記憶手段は、例えば、プログラム上の変数や、プログラムの実行によりアロケーションされるメモリーである。また、必要に応じて、磁気ハードディスク装置やソリッドステートドライブ（ＳＳＤ）といった不揮発性の記憶手段を用いるようにしてもよい。受信端末装置２が持つ各部の機能は、次に説明する通りである。
【0045】
チューナー部２０１は、放送信号を受信し、受信した放送信号のチューニング（選局）を行い、選局された放送信号をデスクランブラー２０２に渡す。なお、受信される放送信号は、ＩＳＤＢ－Ｔ（地上デジタル放送）やＩＳＤＢ－Ｓ（衛星デジタル放送）などの放送信号である。なお、チューナー部２０１は、「受信部」とも呼ばれる。
【0046】
デスクランブラー２０２（descrambler）は、受信された放送信号をデスクランブルして出力する。デスクランブラー２０２は、デスクランブルした結果の信号を、デマルチプレクサー２０３に渡す。
【0047】
デマルチプレクサー２０３（demultiplexer）は、多重送信された放送信号から、個々のリソースの信号を取り出して出力する。具体的には、デマルチプレクサー２０３は、デスクランブラー２０２から出力された信号から、データ放送の信号や、映像の信号や、音声の信号や、字幕の信号や、必要に応じてその他の信号を、それぞれ抽出して出力する。
【0048】
データ放送処理部２１１は、デマルチプレクサー２０３が抽出したデータ放送の信号を処理する。データ放送の信号は、例えばＢＭＬ（Broadcast Markup Language）で記述されたコンテンツである。
【0049】
映像デコーダー部２１２は、デマルチプレクサー２０３が抽出した映像のリソースを受け取り、映像としてデコード（復号）する。映像デコーダー部２１２は、デコード結果である映像を、映像出力部２７１およびトランスコード部２６１に渡す。
【0050】
音声デコーダー部２１３は、デマルチプレクサー２０３が抽出した音声のリソースを受け取り、音声としてデコードする。音声デコーダー部２１３は、デコード結果である音声を、音声出力部２７２およびトランスコード部２６１に渡す。
【0051】
字幕デコーダー部２１４は、デマルチプレクサー２０３が抽出した字幕のリソースを受け取り、デコードする。字幕デコーダー部２１４は、デコード結果である字幕のデータを、映像出力部２７１に渡す。さらに、字幕デコーダー部２１４は、その字幕のデータを、トランスコード部２６１にも渡してよい。
【0052】
データ放送エンジン２２１は、データ放送処理部２１１から出力されたコンテンツについての処理を行う。データ放送エンジン２２１は、その処理結果を、映像として、映像出力部２７１に渡す。
【0053】
通信部２３１は、外部の装置との通信を行う。通信部２３１は、例えば、インターネットプロトコル（ＩＰ）を用いて、外部と通信する。通信部２３１の機能により、受信端末装置２は、クライアント端末装置３等との間で相互に通信を行うことが可能となる。なお、通信部２３１は、後述する外部（例えば宅外）のサーバー装置（ウェブ編成情報管理サーバー装置９１等）とも通信を行うことができる。
【0054】
ストリーミング受信部２３２は、通信（インターネット等）を介してストリーミング配信されるコンテンツの信号を受信する。ストリーミング受信部２３２は、受信した信号をデマルチプレクサー２３３に渡す。
【0055】
デマルチプレクサー２３３は、ストリーミング受信部２３２が受信したコンテンツの信号から、各リソースのデータをそれぞれ抽出する。抽出されるデータは、映像や、音声や、字幕等のデータである。デマルチプレクサー２３３は、映像のデータを映像デコーダー部２４２に渡し、音声のデータを音声デコーダー部２４３に渡し、字幕のデータを字幕デコーダー部２４４に渡す。デマルチプレクサー２３３が、映像や音声や字幕以外の種類のリソースを抽出してもよい。
【0056】
映像デコーダー部２４２は、デマルチプレクサー２３３から渡される映像のデータをデコードし、デコード後の映像を出力する。
【0057】
音声デコーダー部２４３は、デマルチプレクサー２３３から渡される音声のデータをデコードし、デコード後の音声を出力する。
【0058】
字幕デコーダー部２４４は、デマルチプレクサー２３３から渡される字幕のデータをデコードし、デコード後の字幕（テキスト）を出力する。
【0059】
アプリケーション制御部２５１は、受信端末装置２上で稼働するアプリケーションプログラムを制御する。具体的には、アプリケーション制御部２５１は、特定のアプリケーションプログラムを起動させたり、停止させたり、その他の管理を行ったりする。アプリケーション制御部２５１は、ハイブリッドキャストの技術（規定）に基づく制御を行う。
【0060】
アプリケーションエンジン２５２は、受信端末装置２上で稼働するアプリケーションプログラムを稼働させる環境である。アプリケーションプログラムは、例えば、ＨＴＭＬ５で記述されるコンテンツである。ＨＴＭＬ５で記述されるコンテンツは、画面等に提示するためのページの定義や、実行可能なコードを含む。
【0061】
アプリケーションロンチャー２５３は、特定のアプリケーションプログラムをアプリケーションエンジン２５２上で起動させるための機能を有するものである。
【0062】
トランスコード部２６１は、デコードされた映像や音声のデータを受け取り、通信を介して配信するためのフォーマット（ネット動画配信フォーマット）に変換（トランスコード）する。変換先のネット動画配信フォーマットは、例えば、ＭＰＥＧ－ＤＡＳＨ（ＤＡＳＨは、「Dynamic Adaptive Streaming over HTTP」の略）やＨＬＳ（HTTP Live Streaming）である。つまり、トランスコード部２６１は、受信された放送信号から抽出されたリソースのデータを、ウェブプラットフォームで利用可能な形式のデータにトランスコードして、ウェブリソースとして出力する。トランスコード部２６１が出力するデータは、ウェブリソース提供部２６２に渡され、さらにクライアント端末装置３側に提供され得るものである。なお、トランスコード部２６１がコンテンツをトランスコードする際のパラメーターは、アプリケーション制御部２５１やクライアント端末連携制御部２６３によって制御・設定され得るものである。
【0063】
ウェブリソース提供部２６２は、トランスコード部２６１から出力されるネット動画配信形式のコンテンツを受け取り、外部装置（クライアント端末装置３等）への配信の管理を行う。ウェブリソース提供部２６２は、トランスコード部２６１が出力した動画コンテンツを、少なくとも所定期間、蓄積しておくこともできる。ウェブリソース提供部２６２は、動画コンテンツを、通信部２３１経由で、クライアント端末装置３等に提供することができる。つまり、ウェブリソース提供部２６２は、外部に存在するクライアント端末装置３からの視聴要求に応じて、トランスコード部２６１が出力する前記ウェブリソースを、通信を介して、クライアント端末装置３に対して送信する。
【0064】
また、ウェブリソース提供部２６２は、ウェブクライアント（クライアント端末装置３等）が動画コンテンツを利用するためのエンドポイント情報を生成する。エンドポイント情報は、ウェブクライアント側から見た、動画配信コンテンツのアクセス先を表す情報である。ウェブリソース提供部２６２が生成したエンドポイント情報は、クライアント端末連携制御部２６３を介して、クライアント端末装置３側に渡され得る情報である。このエンドポイント情報によって、クライアント端末装置３は、動画コンテンツを取得するためのアクセス先を知る。
【0065】
クライアント端末連携制御部２６３は、受信端末装置２とクライアント端末装置３との間の連携を制御する。具体的には、クライアント端末連携制御部２６３は、ハイブリッドキャストの端末連携機能によって、受信端末装置２とクライアント端末装置３との間の連携を制御する。ハイブリッドキャストの端末連携機能自体は既存の技術であるが、クライアント端末連携制御部２６３は、本実施形態に特有の機能として、ハイブリッドキャストの端末連携機能を拡張した機能を実現するものである。
【0066】
具体的には、クライアント端末連携制御部２６３は、ハイブリッドキャストの端末連携機能（拡張機能を含む）によりクライアント端末装置３との連携動作を制御するとともに、ウェブリソースを利用するために必要な情報をクライアント端末装置に送信する。クライアント端末連携制御部２６３は、少なくとも、ウェブリソースを利用するためのロケーション（エンドポイント等）の情報をクライアント端末装置３に送信する。
【0067】
クライアント端末連携制御部２６３は、拡張したハイブリッドキャストの端末連携機能において、次のような処理を行う。即ち、クライアント端末連携制御部２６３は、前述のエンドポイント情報を、クライアント端末装置３に対して提供する。また、クライアント端末連携制御部２６３は、放送リソースからトランスコードされたウェブリソースを利用するためのＡＰＩ（アプリケーションプログラムインターフェース）を、クライアント端末装置３に対して提供する。また、クライアント端末連携制御部２６３は、クライアント端末装置３側から渡されるトランスコード部２６１を制御するための情報を取得し、その制御情報（トランスコード処理用のパラメーター等）を、アプリケーション制御部２５１経由で、トランスコード部２６１に渡す。つまり、クライアント端末連携制御部２６３は、クライアント端末装置３からの情報に基づいて、トランスコード部２６１を制御する。なお、受信端末装置２とクライアント端末装置３との間の連携については、後でさらに詳細に説明する。
【0068】
映像出力部２７１は、映像デコーダー部２１２や、字幕デコーダー部２１４や、映像デコーダー部２４２や、字幕デコーダー部２４４や、データ放送エンジン２２１等から渡される映像を統合して、統合された映像を出力する。つまり、映像出力部２７１は、その映像をユーザー（視聴者）に対して提示する。具体的には、映像出力部２７１は、ディスプレイ装置等に対して、提示するための映像の信号を出力する。なお、本実施形態において、受信端末装置２が、映像出力部２７１を持たない構成としてもよい。その場合にも、受信端末装置２は、映像（字幕に相当する情報を含む）をウェブリソースとしてクライアント端末装置３に提供することができる。
【0069】
音声出力部２７２は、音声デコーダー部２１３や音声デコーダー部２４３から渡される音声を、外部に出力する。具体的には、音声出力部２７２は、スピーカーやイヤフォン等に対して、音声の信号を出力する。なお、本実施形態において、受信端末装置２が、音声出力部２７２を持たない構成としてもよい。その場合にも、受信端末装置２は、音声をウェブリソースとしてクライアント端末装置３に提供することができる。
【0070】
上記のような機能構成により、受信端末装置２は、放送信号として受信した映像や音声や字幕等のリソースを、クライアント端末装置３が持つウェブブラウザー（ウェブプラットフォーム）で提示（利用）できるようにする。即ち、受信端末装置２を用いることにより、放送リソースをウェブプラットフォームで利用できるようになる。
【0071】
なお、受信端末装置２が、オプションとして、次のような機能を持つようにしてもよい。受信端末装置２は、クライアント端末装置３に対してはウェブサーバーとして機能するが、そのウェブサーバー内に、トランスコード部２６１が生成した動画データ（ｍｐ４など）を蓄積できるようにしても良い。これにより、例えばクライアント端末装置３からの要求に基づいて、巻き戻し視聴（特定の再生位置までジャンプ）を可能にしたり、ビデオオンデマンド（ＶＯＤ）による視聴を可能にしたりすることができる。また、受信端末装置２が、動画再生プレーヤーの機能や、動画再生可能なＨＴＭＬコンテンツを持つようにしてもよい。これにより、クライアント端末装置３が動画再生プレーヤーの機能を持たない場合にも、動画の再生をすることが可能となる。また、受信端末装置２が、動画配信の際に、チャンク転送エンコーディング（chunked-transfer-encoding）を用いることができるようにしてもよい。これにより、ＣＭＡＦ（Common Media Application Format）での超低遅延配信を実現することも可能となる。
【0072】
図３および図４は、本実施形態において拡張されたハイブリッドキャストの端末連携機能を用いた、受信端末装置２とクライアント端末装置３との間での、リクエストおよびレスポンスのシーケンスの例を示す概略図である。
【0073】
図示するステップＳ１０１からＳ１１５まで、およびステップＳ１２１からＳ１３２までの処理のうち、ステップＳ１０１からＳ１１５までが、従来のハイブリッドキャストの端末連携機能においても存在するＡＰＩ（リクエストおよびレスポンス等）によるものである。ただし、従来のリクエストあるいはレスポンスの少なくとも一部が本実施形態のために拡張される場合もある。つまり、以下に説明するステップＳ１０１からＳ１１５までの処理のすべてが従来技術に属するものであるというわけではない。また、ステップＳ１２１からＳ１３２までの処理が、特に本実施形態に特有の拡張されたハイブリッドキャストの端末連携機能のＡＰＩ（リクエストおよびレスポンス）によるものである。
【0074】
また、受信端末装置２とクライアント端末装置３とが、これらのステップＳ１０１からＳ１１５まで、およびステップＳ１２１からＳ１３２までのすべての手順を順次実行するとは限らない。なお、図示する通り、ステップＳ１１５の処理以外は、リクエストとレスポンスの対としてまとまった処理である。ステップＳ１１５の処理は、双方向通信であり、その中の具体的な手順は、適用する処理内容およびデータ内容に依存する。
【0075】
【0076】
図３のステップＳ１０１において、クライアント端末装置３は、受信端末装置２に対して、機器発見のリクエストを送信する。上記のリクエストに対して、ステップＳ１０２において、受信端末装置２は、クライアント端末装置３に対して、機器発見のレスポンスを送信する。
【0077】
ステップＳ１０３において、クライアント端末装置３は、受信端末装置２に対して、認証のリクエストを送信する。上記のリクエストに対して、ステップＳ１０４において、受信端末装置２は、クライアント端末装置３に対して、認証のレスポンスを送信する。
【0078】
ステップＳ１０５において、クライアント端末装置３は、受信端末装置２に対して、利用可能メディア取得のリクエストを送信する。上記のリクエストに対して、ステップＳ１０６において、受信端末装置２は、クライアント端末装置３に対して、利用可能メディア取得のレスポンスを送信する。
【0079】
ステップＳ１０７において、クライアント端末装置３は、受信端末装置２に対して、編成サービス一覧取得のリクエストを送信する。上記のリクエストに対して、ステップＳ１０８において、受信端末装置２は、クライアント端末装置３に対して、編成サービス一覧取得のレスポンスを送信する。
【0080】
ステップＳ１０９において、クライアント端末装置３は、受信端末装置２に対して、選局・ＨＣアプリ起動要求のリクエストを送信する。上記のリクエストに対して、ステップＳ１１０において、受信端末装置２は、クライアント端末装置３に対して、選局・ＨＣアプリ起動要求のレスポンスを送信する。なお、「ＨＣ」は、ハイブリッドキャストの略である。
【0081】
ステップＳ１１１において、クライアント端末装置３は、受信端末装置２に対して、起動可否状態取得のリクエストを送信する。上記のリクエストに対して、ステップＳ１１２において、受信端末装置２は、クライアント端末装置３に対して、起動可否状態取得のレスポンスを送信する。
【0082】
ステップＳ１１３において、クライアント端末装置３は、受信端末装置２に対して、受信機状態取得のリクエストを送信する。上記のリクエストに対して、ステップＳ１１４において、受信端末装置２は、クライアント端末装置３に対して、受信機状態取得のレスポンスを送信する。なお、ここで「受信機」とは、受信端末装置２を指すものである。
【0083】
ステップＳ１１５において、クライアント端末装置３および受信端末装置２は、双方向に通信を行う。これにより、クライアント端末装置３と受信端末装置２とが連携動作することが可能となる。つまり、クライアント端末装置３と受信端末装置２とは、端末連携通信を行う。
【0084】
図４に移り、ステップＳ１２１において、クライアント端末装置３は、受信端末装置２に対して、ウェブリソース機器発見のリクエストを送信する。上記のリクエストに対して、ステップＳ１２２において、受信端末装置２は、クライアント端末装置３に対して、ウェブリソース機器発見のレスポンスを送信する。この「ウェブリソース機器発見」のリクエストおよびレスポンスは、従来のハイブリッドキャストの端末連携機能の技術では存在しない手順である。
【0085】
ステップＳ１２３において、クライアント端末装置３は、受信端末装置２に対して、ウェブリソース利用可否取得のリクエストを送信する。上記のリクエストに対して、ステップＳ１２４において、受信端末装置２は、クライアント端末装置３に対して、ウェブリソース利用可否取得のレスポンスを送信する。この「ウェブリソース利用可否取得」のリクエストおよびレスポンスは、従来のハイブリッドキャストの端末連携機能の技術では存在しない手順である。
【0086】
ステップＳ１２５において、クライアント端末装置３は、受信端末装置２に対して、ウェブサービス一覧取得のリクエストを送信する。上記のリクエストに対して、ステップＳ１２６において、受信端末装置２は、クライアント端末装置３に対して、ウェブサービス一覧取得のレスポンスを送信する。この「ウェブサービス一覧取得」のリクエストおよびレスポンスは、従来のハイブリッドキャストの端末連携機能の技術では存在しない手順である。
【0087】
ステップＳ１２７において、クライアント端末装置３は、受信端末装置２に対して、ウェブサービス起動要求のリクエストを送信する。上記のリクエストに対して、ステップＳ１２８において、受信端末装置２は、クライアント端末装置３に対して、ウェブサービス起動要求のレスポンスを送信する。この「ウェブサービス起動要求」のリクエストおよびレスポンスは、従来のハイブリッドキャストの端末連携機能の技術では存在しない手順である。
【0088】
ステップＳ１２９において、クライアント端末装置３は、受信端末装置２に対して、ウェブサービス起動可否状態取得のリクエストを送信する。上記のリクエストに対して、ステップＳ１３０において、受信端末装置２は、クライアント端末装置３に対して、ウェブサービス起動可否状態取得のレスポンスを送信する。この「ウェブサービス起動可否状態取得」のリクエストおよびレスポンスは、従来のハイブリッドキャストの端末連携機能の技術では存在しない手順である。
【0089】
ステップＳ１３１において、クライアント端末装置３は、受信端末装置２に対して、ウェブサービス状態取得のリクエストを送信する。上記のリクエストに対して、ステップＳ１３２において、受信端末装置２は、クライアント端末装置３に対して、ウェブサービス状態取得のレスポンスを送信する。この「ウェブサービス状態取得」のリクエストおよびレスポンスは、従来のハイブリッドキャストの端末連携機能の技術では存在しない手順である。
【0090】
次に、システム１における、受信端末装置２とクライアント端末装置３との間のやりとりのさらに詳細について、説明する。これらのやりとりは、本実施形態において拡張されたハイブリッドキャストの端末連携機能による処理である。
【0091】
下で説明する（１）から（３）までは、ウェブリソース機器発見のための手順である。ウェブリソース機器発見のための新たなＡＰＩを設ける例と、その他の例（従来手順の拡張等）との両方を説明する。後で説明するいずれかの手順によるウェブリソース機器発見の処理によって、受信端末装置２のクライアント端末連携制御部２６３は、クライアント端末装置３からの、ウェブリソースを提供する機器を発見するためのリクエストに対応して、ウェブリソースを利用するためのロケーションの情報をクライアント端末装置３に送信する。言い換えれば、クライアント端末装置３の受信端末連携制御部３６３は、受信端末装置２にウェブリソースを提供する機器を発見するためのリクエストを送信し、ウェブリソースを提供する機器を発見するためのリクエストに対応して受信端末装置２が送信したウェブリソースを利用するためのロケーションの情報を受信する。
【0092】
また、（４）から（７）までは、ウェブリソース利用可否取得のための手順である。ウェブリソース利用可否取得のための新たなＡＰＩを設ける例と、その他の例との両方を説明する。後で説明するいずれかの手順によるウェブリソース利用可否取得の処理によって、受信端末装置２のクライアント端末連携制御部２６３は、クライアント端末装置３からの、ウェブリソースの利用可否の情報を取得するためのリクエストに対応して、ウェブリソースの利用可否の情報をクライアント端末装置３に送信する。クライアント端末連携制御部２６３は、特に、ウェブリソースの、少なくとも映像と音声と字幕とＳＩ（サービス情報）とＥＰＧ（電子番組表）とＥＭ（イベントメッセージ）とＡＩＴ（アプリケーション情報テーブルとのいずれかの種別ごとの利用可否の情報を、クライアント端末装置３に送信するようにしてよい。言い換えれば、クライアント端末装置３の受信端末連携制御部３６３は、受信端末装置２にウェブリソースの利用可否の情報を取得するためのリクエストを送信し、受信端末装置２にウェブリソースの利用可否の情報を取得するためのリクエストに対応して受信端末装置２が送信するウェブリソースの利用可否の情報を、受信端末装置２から受信する。受信端末連携制御部３６３は、特に、ウェブリソースの、少なくとも映像と音声と字幕とＳＩ（サービス情報）とＥＰＧ（電子番組表）とＥＭ（イベントメッセージ）とＡＩＴ（アプリケーション情報テーブルとのいずれかの種別ごとの利用可否の情報を、受信端末装置２から受信するようにしてよい。
【0093】
また、（８）から（１０）までは、ウェブサービス一覧取得のための手順である。ウェブサービス一覧取得のための新たなＡＰＩを設ける例と、その他の例との両方を説明する。後で説明するいずれかの手順によるウェブリソース利用可否取得の処理によって、受信端末装置２のクライアント端末連携制御部２６３は、クライアント端末装置３からの、ウェブサービス一覧を取得するためのリクエストに対応して、提供可能なウェブリソースの、ウェブサービス一覧の情報をクライアント端末装置３に送信する。なお、クライアント端末連携制御部２６３は、特に、外部のウェブ編成情報管理サーバー装置９１（後述）から取得したウェブサービス一覧の情報をクライアント端末装置３に送信するようにしてよい。言い換えれば、クライアント端末装置３の受信端末連携制御部３６３は、受信端末装置２にウェブサービス一覧を取得するためのリクエストを送信し、ウェブサービス一覧を取得するためのリクエストに対応して受信端末装置２が送信する前記ウェブサービス一覧の情報を、受信端末装置２から受信する。受信端末連携制御部３６３は、特に、受信端末装置２が外部のウェブ編成情報管理サーバー装置９１から取得した前記ウェブサービス一覧の情報を、受信端末装置２から受信するようにしてよい。
【0094】
また、（１１）から（１３）までは、ウェブサービス起動要求のための手順である。ウェブサービス起動要求のための新たなＡＰＩを設ける例と、その他の例との両方を説明する。後で説明するいずれかの手順によるウェブリソース利用可否取得の処理によって、受信端末装置２のクライアント端末連携制御部２６３は、クライアント端末装置３からの、トランスコード部２６１による処理の開始または終了、あるいはトランスコード部２６１による処理のためのパラメーターの設定、のリクエストに応じて、トランスコード部２６１を制御する。言い換えれば、クライアント端末装置３の受信端末連携制御部３６３は、受信端末装置２側における前記トランスコード部による処理の開始または終了、あるいは前記トランスコード部による処理のためのパラメーターの設定、のリクエストを、受信端末装置２に送信する。
【0095】
また、（１４）から（１６）までは、ウェブサービス起動可否状態取得のための手順である。ウェブリソース機器発見のための新たなＡＰＩを設ける例と、その他の例との両方を説明する。後で説明するいずれかの手順によるウェブリソース利用可否取得の処理によって、受信端末装置２のクライアント端末連携制御部２６３は、クライアント端末装置３からの、ウェブサービスの起動可否状態の情報を取得するためのリクエストに対応して、ウェブサービスの起動可否状態の情報をクライアント端末装置３に送信する。言い換えれば、クライアント端末装置３の受信端末連携制御部３６３は、ウェブサービスの起動可否状態の情報を取得するためのリクエストを受信端末装置２に対して送信し、ウェブサービスの起動可否状態の情報を取得するためのリクエストに対応して受信端末装置２が送信するウェブサービスの起動可否状態の情報を、受信端末装置２から受信する。
【0096】
また、（１７）から（１９）までは、ウェブサービス状態取得のための手順である。ウェブサービス状態取得のための新たなＡＰＩを設ける例と、その他の例との両方を説明する。後で説明するいずれかの手順によるウェブリソース利用可否取得の処理によって、受信端末装置２のクライアント端末連携制御部２６３は、クライアント端末装置３からの、トランスコード部２６１が実行中であるか否かを表すウェブサービス状態の情報、を取得するためのリクエストに対応して、ウェブサービス状態の情報をクライアント端末装置３に送信する。言い換えれば、クライアント端末装置３の受信端末連携制御部３６３は、受信端末装置２においてトランスコード部２６１が実行中であるか否かを表すウェブサービス状態の情報、を取得するためのリクエストを受信端末装置２に送信し、ウェブサービス状態の情報を取得するためのリクエストに対応して受信端末装置２が送信するウェブサービス状態の情報を、受信端末装置２から受信する。
【0097】
また（２０）は、端末連携通信（受信端末装置２とクライアント端末装置３との間の連携通信）のためのＡＰＩを活用した、各種データの交換（制御等）について説明するものである。
【0098】
これらの（１）から（２０）までの処理の内容は、次に順次説明する通りである。
【0099】
（１）ウェブリソース機器発見（図４のステップＳ１２１およびＳ１２２）－その１
受信端末装置２のクライアント端末連携制御部２６３は、クライアント端末装置３からの機器発見のメッセージ（ＤＩＡＬプロトコル：ＵＰｎＰ規格を使用したプロトコル）に対応して、ＡＰＩのエンドポイント情報を提供する。なお、ＤＩＡＬは、「Discovery-and-Launch」の略である。また、ＵＰｎＰは、「Universal Plug and Play（ユニバーサル・プラグ・アンド・プレイ）」の略である。クライアント端末連携制御部２６３は、上記のエンドポイント情報を、ＸＭＬ形式等のデータとして提供する。
受信端末装置２のクライアント端末連携制御部２６３は、クライアント端末装置３からの機器発見のメッセージ（ＤＩＡＬプロトコル：ＵＰｎＰ規格を使用したプロトコル）に対応して、ＡＰＩのエンドポイント情報を提供する。なお、ＤＩＡＬは、「Discovery-and-Launch」の略である。また、ＵＰｎＰは、「Universal Plug and Play（ユニバーサル・プラグ・アンド・プレイ）」の略である。クライアント端末連携制御部２６３は、上記のエンドポイント情報を、ＸＭＬ形式等のデータとして提供する。
【0100】
本実施形態では、受信端末装置２が提供するウェブリソースをクライアント端末装置３が利用する。このように拡張する場合のメッセージ記述の一例は、次の通りである。即ち、プロトコルのバージョン番号により、機器がウェブリソース対応の機器であるか否かを区別することができる。
【0101】
図５は、ウェブリソースのエンドポイント情報を含んだメッセージの記述例を示す概略図である。このメッセージは、受信端末装置２のクライアント端末連携制御部２６３が、クライアント端末装置３に対して送信するメッセージの例である。つまり、図４のステップＳ１２１におけるクライアント端末装置３側からのウェブリソース機器発見のリクエストに対して、クライアント端末連携制御部２６３がステップＳ１２２でクライアント端末装置３に対して送信するレスポンスの例である。なお、この図では、データを参照するための行番号を付している。
【0102】
図５に示すメッセージは、ＸＭＬ形式で記述されている。このメッセージの第８行目から第１０行目までのブロックには、ハイブリッドキャストのプロトコルのバージョン番号が記述されている。本例では、バージョン番号が「３．０」とされている。例えばこのバージョン番号により、従来技術によるハイブリッドキャストの端末連携機能のメッセージであるか、本実施形態で拡張されたハイブリッドキャストの端末連携機能のメッセージであるかを区別するようにできる。例えば、バージョン番号が「３．０」またはそれ以上であれば、拡張されたハイブリッドキャストの端末連携機能を使用可能（つまり、本実施形態によるウェブリソースの活用が可能）である。逆に、バージョン番号が「３．０」未満（例えば、「２．３」等）であれば、ハイブリッドキャストの端末連携機能は、拡張前の、従来技術によるものである。なお、ここで、上記の「３．０」といった値等は単なる例である。
【0103】
図５に示すメッセージの第１７行目から第１９行目までのブロックには、受信端末装置２がウェブリソースを提供するためのエンドポイント情報が記述されている。具体的には、第１７行目の「<iptv:X_Hybridcast_WebresourceURL>」および第１９行目の「</iptv:X_Hybridcast_WebresourceURL>」というタグが、上記のエンドポイント情報を記述するためのタグである。また、第１８行目の「http://192.168.1.11:1236/hybridcast/webresource」という記述が、エンドポイントを示すＵＲＬ（エンドポイント情報）の例である。
【0104】
図６は、上記のプロトコルのバージョン番号の情報に基づいた動作の例を示すフローチャートである。以下、このフローチャートを参照しながら、バージョン番号に基づいて動作を分岐する処理について、説明する。
【0105】
ステップＳ２０１において、クライアント端末装置３は、ＵＰｎＰを用いて、ウェブリソース機器発見のリクエストを、受信端末装置２に送信する（図４のステップＳ１２１に相当）。
【0106】
次に、ステップＳ２０２において、クライアント端末装置３は、上記のリクエストに対応する、受信端末装置２からのレスポンスを取得する。このレスポンスは、図５に例示したように、ＸＭＬで記述されている。
【0107】
次に、ステップＳ２０３において、クライアント端末装置３は、プロトコルのバージョン番号に基づく判定を行う。具体的には、クライアント端末装置３は、バージョン番号が、ウェブリソース機能に対応しているものであるか否かを判定する。
【0108】
受信したレスポンスに記述されたプロトコルのバージョン番号がウェブリソース機能に対応しているものであることを表す（例えば、ｖｅｒ３．０以上）場合（ステップＳ２０３：ウェブリソース対応）には、ステップＳ２０４に移る。即ち、クライアント端末装置３は、ウェブリソースを利用することを前提として処理を行うことができる。
【0109】
そのバージョン番号がウェブリソース機能に対応しているものではないことを表す（例えば、ｖｅｒ３．０未満）場合（ステップＳ２０３：ウェブリソース非対応）には、クライアント端末装置は、従来のハイブリッドキャストの端末連携機能により動作する。即ち、クライアント端末装置３は、ウェブリソースを利用しないことを前提とした処理を行う。
【0110】
ステップＳ２０４に進んだ場合には、同ステップにおいて、クライアント端末装置３は、ステップＳ２０２で受信したレスポンスのメッセージから、ウェブリソースのエンドポイントの情報を取得する。つまり、クライアント端末装置３は、図５の第１７行目から第１９行目までにおいて例示した情報を取得する。このエンドポイントの情報に基づいて、クライアント端末装置３は、受信端末装置２が提供するウェブリソースにアクセスすることが可能となる。
【0111】
そして、次にステップＳ２０５において、クライアント端末装置３は、ウェブコンテンツの視聴を行うための処理を行う。つまり、クライアント端末装置３は、受信端末装置２からウェブリソース（映像や音声等）のデータを受信し、そのデータのコンテンツをユーザー（視聴者）に対して提示する。これ以後も、クライアント端末装置３は、ウェブリソースの利用を前提とした処理を行うことができる。
【0112】
（２）ウェブリソース機器発見（図４のステップＳ１２１およびＳ１２２）－その２（従来エンドポイント情報の拡張）
次に、ウェブリソース機器発見のための代替手法について説明する。従来の（非拡張の）ハイブリッドキャストの端末連携機能では、機器発見のリクエストに対して、端末連携ＡＰＩのエンドポイント情報が「<iptv:X_Hybridcast_TVcontrolURL>」のタグを用いて記述されている（図５の例における第１４行目から第１６行目までのブロック）。この「<iptv:X_Hybridcast_TVcontrolURL>」のタグを利用して、ウェブリソースのエンドポイント情報を記述子、受信端末装置２からクライアント端末装置３に伝えるようにしてもよい。
次に、ウェブリソース機器発見のための代替手法について説明する。従来の（非拡張の）ハイブリッドキャストの端末連携機能では、機器発見のリクエストに対して、端末連携ＡＰＩのエンドポイント情報が「<iptv:X_Hybridcast_TVcontrolURL>」のタグを用いて記述されている（図５の例における第１４行目から第１６行目までのブロック）。この「<iptv:X_Hybridcast_TVcontrolURL>」のタグを利用して、ウェブリソースのエンドポイント情報を記述子、受信端末装置２からクライアント端末装置３に伝えるようにしてもよい。
【0113】
また、受信端末装置２が、さらに別の手法を用いてウェブリソースのエンドポイント情報を提供するようにしても良い。例えば、クライアント端末装置３からの利用可能メディア取得（図３のステップＳ１０５）のリクエストに対応して、ウェブリソースのエンドポイント情報を提供してもよい。この利用可能メディア取得のレスポンスにおいては、従来技術では、ハイブリッドキャストの端末連携機能のＡＰＩのエンドポイントとして「＜base URL＞/media」が提供されている。これに代えて、受信端末装置２が、ハイブリッドキャストの端末連携機能のＡＰＩのエンドポイントとして、ウェブリソースのエンドポイントの情報を提供するようにしてよい。例えば、受信端末装置２が、ウェブリソースのエンドポイントの情報として、「＜base URL＞/webresource」の情報を提供するようにしてよい。なお、ここで、「＜base URL＞」は、サービスを提供するための基底ＵＲＬの文字列によって置き換えられるべきものである。
【0114】
（３）ウェブリソース機器発見（図４のステップＳ１２１およびＳ１２２）－その３（従来エンドポイント情報の内容の変更のみ）
ウェブリソース機器発見のためのさらなる代替手法について説明する。本手法では、既存のハイブリッドキャストの端末連携機能の技術におけるエンドポイント情報の内容のみを変更する。つまり、受信端末装置２は、既存のエンドポイント情報に代えて、ウェブリソースのエンドポイント情報を記述したメッセージを、クライアント端末装置３に対して、レスポンスとして送信するようにする。この手法を用いる場合、従来技術と比べて、エンドポイント情報が追加されるわけではないが、ウェブリソースのエンドポイント情報をクライアント端末装置３側に伝えることが可能となる。これにより、クライアント端末装置３は、受信端末装置２が提供するウェブリソースにアクセスして利用することが可能となる。
ウェブリソース機器発見のためのさらなる代替手法について説明する。本手法では、既存のハイブリッドキャストの端末連携機能の技術におけるエンドポイント情報の内容のみを変更する。つまり、受信端末装置２は、既存のエンドポイント情報に代えて、ウェブリソースのエンドポイント情報を記述したメッセージを、クライアント端末装置３に対して、レスポンスとして送信するようにする。この手法を用いる場合、従来技術と比べて、エンドポイント情報が追加されるわけではないが、ウェブリソースのエンドポイント情報をクライアント端末装置３側に伝えることが可能となる。これにより、クライアント端末装置３は、受信端末装置２が提供するウェブリソースにアクセスして利用することが可能となる。
【0115】
（４）ウェブリソース利用可否取得（図４のステップＳ１２３およびＳ１２４）－その１
次に、クライアント端末装置３が、ウェブリソース利用可否の情報を取得するためのＡＰＩについて説明する。ウェブリソース利用可否とは、クライアント端末装置３が利用することのできるウェブリソースが存在するか否かを表す情報である。ここで説明する手法では、クライアント端末装置３がウェブリソース利用可否の情報を取得するための新たなＡＰＩを導入する。クライアント端末装置３は、ウェブリソース利用可否の情報をリクエストする（図４のステップＳ１２３）。このリクエストに対応して、受信端末装置２は、レスポンスを、クライアント端末装置３に返送する（図４のステップＳ１２４）。
次に、クライアント端末装置３が、ウェブリソース利用可否の情報を取得するためのＡＰＩについて説明する。ウェブリソース利用可否とは、クライアント端末装置３が利用することのできるウェブリソースが存在するか否かを表す情報である。ここで説明する手法では、クライアント端末装置３がウェブリソース利用可否の情報を取得するための新たなＡＰＩを導入する。クライアント端末装置３は、ウェブリソース利用可否の情報をリクエストする（図４のステップＳ１２３）。このリクエストに対応して、受信端末装置２は、レスポンスを、クライアント端末装置３に返送する（図４のステップＳ１２４）。
【0116】
図７は、クライアント端末装置３から受信端末装置２に対して送信されるウェブリソース利用可否取得のＡＰＩ（リクエスト）を示す概略図である。図示するように、このＡＰＩのＵＲＬは「＜BaseURL＞/webmedia」である。「＜BaseURL＞」については、既に説明した通りである。また、このＡＰＩを呼び出すためのメソッドは「get」である。
【0117】
図８は、上記のウェブリソース利用可否取得のリクエストに対応する、レスポンスのデータを示す概略図である。このレスポンスのデータは、受信端末装置２がクライアント端末装置３に対して送信するものである。図示するように、レスポンスのデータは、例えばＪＳＯＮ形式のデータとして記述可能である。ＪＳＯＮは、「JavaScript Object Notation」の略である。図示するようにウェブリソース利用可否取得ＡＰＩのレスポンスは、ヘッダー部（”head”で示されるブロック）と、ボディー部（”body”で示されるブロック）とを含む。ヘッダー部に含まれる「200」というコード（code）および「OK」というメッセージ（message）は、リクエストが成功したことを表す。ボディー部に含まれる生成日時（created_at）は、年月日および時分秒（協定世界時）を表す情報である。また、ボディー部に含まれる、ウェブ（web）が「Available」という文字列データである場合には、ウェブリソースが利用可能であることを表す。ウェブリソースが利用不可である場合には、「Available」ではなく「NotAvailable」という文字列データがレスポンスとして返される。
【0118】
（５）ウェブリソース利用可否取得－その２（図４のステップＳ１２３およびＳ１２４）
次に、ウェブリソース利用可否取得についての代替手法を説明する。上で図８に示したレスポンスデータは、ウェブリソースが全体として利用可能であるか否かを表す情報が、受信端末装置２からクライアント端末装置３に返された。本手法では、ウェブリソースとして利用できるサービスの種別ごとの利用可否の情報が、受信端末装置２からクライアント端末装置３に返される。なお、本手法において、ウェブリソース利用可否取得ＡＰＩのリクエストのデータは、上で図７に示したものと同様である。一方、ウェブリソース利用可否取得ＡＰＩのレスポンスのデータは、次の通りである。
次に、ウェブリソース利用可否取得についての代替手法を説明する。上で図８に示したレスポンスデータは、ウェブリソースが全体として利用可能であるか否かを表す情報が、受信端末装置２からクライアント端末装置３に返された。本手法では、ウェブリソースとして利用できるサービスの種別ごとの利用可否の情報が、受信端末装置２からクライアント端末装置３に返される。なお、本手法において、ウェブリソース利用可否取得ＡＰＩのリクエストのデータは、上で図７に示したものと同様である。一方、ウェブリソース利用可否取得ＡＰＩのレスポンスのデータは、次の通りである。
【0119】
図９は、本手法における、ウェブリソース利用可否取得ＡＰＩのレスポンスのデータを示す概略図である。このレスポンスのデータは、受信端末装置２がクライアント端末装置３に対して送信するものである。レスポンスのデータは、例えばＪＳＯＮ形式のデータとして記述される。このレスポンスのデータは、ヘッダー部とボディー部とを含む。ここで例示するヘッダー部のデータは、図８において説明したものと同様である。また、ボディー部に含まれる生成日時（created_at）は、図８において説明したものと同様である。そして、ボディー部に含まれる”VIDEO”（映像）、”AUDIO”（音声）、”SUBTITLE”（字幕）、”EVENT”（イベントメッセージ）、”BML”（ＢＭＬで記述されたデータ放送のコンテンツ）、”AIT”（ハイブリッドキャスト）、”SI”（サービス情報）のそれぞれは、ウェブリソースの種別ごとの利用可否を表すデータである。なお、ＳＩは、番組編成に関するデータである。「Available」はその種別が利用可能であることを表す。「NotAvailable」はその種別が利用不可であることを表す。
【0120】
クライアント端末装置３が例えばスマートスピーカーである場合には、そのクライアント端末装置３は、音声コンテンツを出力することができるが、映像コンテンツを出力することはできない。つまり、クライアント端末装置３の種類によって、利用可能なウェブリソースと利用できないウェブリソースとがある。このような場合には、クライアント端末装置３は、上記の、ウェブリソースの種別ごとの利用可否の情報に基づいて、その種別を利用するかを判定することができる。
【0121】
（６）ウェブリソース利用可否取得－その３
ウェブリソース利用可否取得についてのさらなる代替手法を説明する。本手法では、既存のハイブリッドキャストの端末連携機能における利用可能メディア取得のＡＰＩ（図３におけるステップＳ１０５およびＳ１０６）を拡張することによって、クライアント端末装置３が、ウェブリソース利用可否の情報を取得するようにする。
ウェブリソース利用可否取得についてのさらなる代替手法を説明する。本手法では、既存のハイブリッドキャストの端末連携機能における利用可能メディア取得のＡＰＩ（図３におけるステップＳ１０５およびＳ１０６）を拡張することによって、クライアント端末装置３が、ウェブリソース利用可否の情報を取得するようにする。
【0122】
図１０は、本手法によって、利用可能メディア取得ＡＰＩを拡張した結果であるレスポンスのデータの構成を示す概略図である。このレスポンスのデータは、受信端末装置２がクライアント端末装置３に対して送信するものである。レスポンスのデータは、例えばＪＳＯＮ形式のデータとして記述される。このレスポンスのデータは、ヘッダー部とボディー部とを含む。ここで例示するヘッダー部のデータについては、既に説明した通りである。また、ボディー部に含まれる生成日時（created_at）もまた、既に説明した通りである。そして、ボディー部に含まれる”TD”（地上デジタル）、”BS”（放送衛星デジタル）、”CS”（ＣＳデジタル）のそれぞれは、従来技術によるハイブリッドキャストの端末連携機能のインターフェースにおけるデータである。つまり、これらの項目のそれぞれは、地上デジタルと、放送衛星デジタルと、ＣＳデジタルの利用可否（「Available」または「NotAvailable」）を表すデータである。
【0123】
図１０に示すデータのボディー部に含まれる”WEB”は、本実施形態において拡張されたハイブリッドキャストの端末連携機能に特有のデータであり、ウェブリソースの利用可否を表すものである。つまり、この”WEB”の値が「Available」の場合には、ウェブリソースが利用可能であることを表す。また、この”WEB”の値が「NotAvailable」の場合には、ウェブリソースが利用不可であることを表す。このようなレスポンスのデータを獲得することにより、クライアント端末装置３は、受信端末装置２がウェブリソースを提供しているか否かを判定することができる。
【0124】
本手法を用いる場合には、図５で示したような機器発見のレスポンスデータにおいて、プロトコルのバージョン情報を含めなくても、その受信端末装置２でウェブリソースが利用可能であるか否かを、クライアント端末装置３は把握することが可能である。したがって、機器発見のレスポンスデータにプロトコルのバージョン情報を含めないようにしてもよい。ただし、機器発見のレスポンスデータにプロトコルのバージョンを含めることによって、クライアント端末装置３が、認証フローを経由せずに、その受信端末装置２のウェブリソースが利用可能か否かを判断することが可能となる。ここでの認証フローとは、図３のステップＳ１０３およびＳ１０４に示した処理手順である。
【0125】
（７）ウェブリソース利用可否取得－その４
本手法では、受信端末装置２は、ウェブリソース利用可否取得のＡＰＩを設けない。代わりに、クライアント端末装置３は、前述のウェブリソース機器発見の処理（図４のステップＳ１２１およびＳ１２２）で得られるレスポンス（図５のデータ）に基づいて、併せて、ウェブリソース利用可否を判断する。つまり、ウェブリソース機器発見のレスポンスとして得たデータが、受信端末装置２はウェブリソースに対応していることを表している場合（図６におけるステップＳ２０３の判定結果が「ウェブリソース対応」）には、クライアント端末装置３は、「ウェブリソース利用可能」であると判断する。逆に、ウェブリソース機器発見のレスポンスとして得たデータが、受信端末装置２はウェブリソースに対応していいないことを表している場合（図６におけるステップＳ２０３の判定結果が「ウェブリソース非対応」）には、クライアント端末装置３は、「ウェブリソース利用不可」であると判断する。言い換えれば、本手法では、受信端末装置２から得たレスポンスのデータ（図５）が、ウェブリソース利用可否の情報をも含んでいると解釈する。本手法では、ウェブリソース利用可否取得のＡＰＩを呼ぶ処理（図４のステップＳ１２３およびＳ１２４）を行わなくても、クライアント端末装置３は、ウェブリソース利用可否を判定できる。
本手法では、受信端末装置２は、ウェブリソース利用可否取得のＡＰＩを設けない。代わりに、クライアント端末装置３は、前述のウェブリソース機器発見の処理（図４のステップＳ１２１およびＳ１２２）で得られるレスポンス（図５のデータ）に基づいて、併せて、ウェブリソース利用可否を判断する。つまり、ウェブリソース機器発見のレスポンスとして得たデータが、受信端末装置２はウェブリソースに対応していることを表している場合（図６におけるステップＳ２０３の判定結果が「ウェブリソース対応」）には、クライアント端末装置３は、「ウェブリソース利用可能」であると判断する。逆に、ウェブリソース機器発見のレスポンスとして得たデータが、受信端末装置２はウェブリソースに対応していいないことを表している場合（図６におけるステップＳ２０３の判定結果が「ウェブリソース非対応」）には、クライアント端末装置３は、「ウェブリソース利用不可」であると判断する。言い換えれば、本手法では、受信端末装置２から得たレスポンスのデータ（図５）が、ウェブリソース利用可否の情報をも含んでいると解釈する。本手法では、ウェブリソース利用可否取得のＡＰＩを呼ぶ処理（図４のステップＳ１２３およびＳ１２４）を行わなくても、クライアント端末装置３は、ウェブリソース利用可否を判定できる。
【0126】
（８）ウェブサービス一覧取得－その１（図４のステップＳ１２５およびＳ１２６）
クライアント端末装置３は、ウェブリソースの利用可否を確認した後、利用可である場合には、利用可能なサービスの一覧のデータを取得する。具体的には、クライアント端末装置３は、ウェブサービス一覧取得のＡＰＩのリクエストを、受信端末装置２に送信する（図４のステップＳ１２５）。このリクエストに対応して、受信端末装置２は、ウェブサービス一覧のレスポンスのデータを、クライアント端末装置３に送信する（図４のステップＳ１２６）。
クライアント端末装置３は、ウェブリソースの利用可否を確認した後、利用可である場合には、利用可能なサービスの一覧のデータを取得する。具体的には、クライアント端末装置３は、ウェブサービス一覧取得のＡＰＩのリクエストを、受信端末装置２に送信する（図４のステップＳ１２５）。このリクエストに対応して、受信端末装置２は、ウェブサービス一覧のレスポンスのデータを、クライアント端末装置３に送信する（図４のステップＳ１２６）。
【0127】
図１１は、クライアント端末装置３から受信端末装置２に対して送信されるウェブリソース利用可否取得のＡＰＩ（リクエスト）を示す概略図である。図示するように、このＡＰＩのＵＲＬは「＜BaseURL＞/webservice」である。「＜BaseURL＞」については、既に説明した通りである。また、このＡＰＩを呼び出すためのメソッドは「get」である。
【0128】
図１２は、上記のウェブサービス一覧取得のリクエストに対応する、レスポンスのデータを示す概略図である。このレスポンスのデータは、受信端末装置２がクライアント端末装置３に対して送信するものである。レスポンスのデータは、例えばＪＳＯＮ形式のデータとして記述される。図示するようにウェブサービス一覧取得ＡＰＩのレスポンスは、ヘッダー部（"head"で示されるブロック）とボディー部（"body"で示されるブロック）とを含む。ヘッダー部については、既に説明した通りである。ボディー部に含まれる生成日時（created_at）については、既に説明した通りである。ボディー部に含まれる、メディア（"media"）のデータがウェブ（"web"）というタイプを含んでいる。
【0129】
また、チャネル（"channels"）というラベルで示されるリスト（図１２の第１１行目から第２９行目まで）は、チャネルの情報のリストを含む。図示する例では、このレスポンスデータは、２つのチャネルのデータを含む。第１のチャネルの記述は、第１２行目から第１９行目までである。第２のチャネルの記述は、第２０行目から第２７行目までである。
【0130】
第１のチャネルに関するデータは、次の通りである。つまり、論理チャネル番号（"logical_channel_number"）は、「011」である（第１３行目）。また、リソース（"resource"）のメディア情報（"base"）は「ＴＤ」（地上デジタル）である（第１５行目）。また、ストリーム（"stream"）を特定する情報は「/stream/32736.mpd」である（第１６行目）。また、放送チャネル名（"broadcast_chennel_name"）は「ＮＨＫ総合・関東広域」である（第１８行目）。
【0131】
第２のチャネルに関するデータは、次の通りである。つまり、論理チャネル番号（"logical_channel_number"）は、「021」である（第２１行目）。また、リソース（"resource"）のメディア情報（"base"）は「ＴＤ」（地上デジタル）である（第２３行目）。また、ストリーム（"stream"）を特定する情報は「/stream/32737.mpd」である（第２４行目）。また、放送チャネル名（"broadcast_chennel_name"）は「ＮＨＫ教育・関東広域」である（第２６行目）。
【0132】
なお、ここに記述されているストリームの情報は、受信端末装置２がウェブ用にトランスコードしたストリームであり、受信端末装置２がリソースを提供するためのＵＲＬである。このＵＲＬは、クライアント端末装置３が、ネット配信される動画コンテンツを取得するためのマニュフェストファイルの場所を表す情報である。
【0133】
図１２に示した例では、ストリーム（"stream"）を特定する情報であるＵＲＬには、ＡＲＩＢで規定されるトランスポートＩＤ（transport_id）が含まれる。即ち、上記第１のチャネルに関しては、トランスポートＩＤは「３２７３６」である。また、上記第１のチャネルに関しては、トランスポートＩＤは「３２７３７」である。
【0134】
ただし、図１２に示した例とは異なる形で、例えばすべてのサービスについてのマニュフェストファイルを共通化してＵＲＬを「/webresouce/stream.mpd」などとすることもできる。
【0135】
上記のようなレスポンスデータにより、クライアント端末装置３は、ウェブリソースとして取得可能なサービスの一覧の情報を得ることができる。
【0136】
（９）ウェブサービス一覧取得－その２
本手法は、上記のウェブサービス一覧取得のＡＰＩの呼び出し（図４のステップＳ１２５およびＳ１２６）を代替するものである。本手法では、代わりに、ハイブリッドキャストの端末連携機能が持つ既存のＡＰＩである編成サービス一覧取得（図３のステップＳ１０７およびＳ１０８）を拡張するものである。
本手法は、上記のウェブサービス一覧取得のＡＰＩの呼び出し（図４のステップＳ１２５およびＳ１２６）を代替するものである。本手法では、代わりに、ハイブリッドキャストの端末連携機能が持つ既存のＡＰＩである編成サービス一覧取得（図３のステップＳ１０７およびＳ１０８）を拡張するものである。
【0137】
図１３は、本手法において、クライアント端末装置３から受信端末装置２に対して送信される編成サービス一覧取得のＡＰＩ（リクエスト）を示す概略図である。図示するように、このＡＰＩのＵＲＬは「＜BaseURL＞/webservice」である。「＜BaseURL＞」については、既に説明した通りである。また、このＡＰＩを呼び出すためのメソッドは「get」である。また、ここでは、ＡＰＩの拡張として、「media＝web」というクエリーが用いられる。このクエリーが付いたＡＰＩ呼び出しにより、受信端末装置２は、ウェブリソースによるサービス一覧取得の要求であることを認識する。
【0138】
本手法におけるレスポンスのデータは、例えば既に説明した、図１２に示すようなデータであってよい。つまり、レスポンスデータは、クライアント端末装置３が受信端末装置２から取得することのできるサービスの一覧のデータを含む。これにより、クライアント端末装置３は、利用可能なすべてのサービスの情報を取得することができる。
【0139】
（１０）ウェブサービス一覧取得－その３（外部のサーバーからサービスのリストを取得）
本手法では、クライアント端末装置３は、外部のサーバー装置が提供する、ウェブリソースのサービスの情報を取得する。
本手法では、クライアント端末装置３は、外部のサーバー装置が提供する、ウェブリソースのサービスの情報を取得する。
【0140】
図１４は、本手法においてクライアント端末装置３がウェブリソースの編成情報を取得するための構成を示すブロック図である。図示するように、本手法では、システム１は、受信端末装置２およびクライアント端末装置３に加えて、ウェブ編成情報管理サーバー装置９１を含む。
【0141】
ウェブ編成情報管理サーバー装置９１は、リクエストに応じて、クライアント端末装置３が利用可能なウェブによるサービスの一覧情報を提供する機能を有する。ウェブ編成情報管理サーバー装置９１は、多数の端末装置からアクセスされ、それらの端末に対してウェブサービスの情報を提供する。図示する例では、クライアント端末装置３は、受信端末装置２を介して、サービスの一覧情報を取得する。具体的な手順の例は、次の通りである。
【0142】
ステップＳ３０１において、クライアント端末装置３は、編成サービス一覧取得のリクエストを、受信端末装置２に対して送信する。このリクエストは、図３のステップＳ１０７で説明したものに相当する。このリクエストにおいて、クライアント端末装置３は、図１３で説明した「media＝web」というクエリーを付加してよい。受信端末装置２は、このリクエストを受信する。
【0143】
ステップＳ３０２において、上記のクライアント端末装置３からのリクエストに基づいて、受信端末装置２は、ウェブ編成情報を取得するためのリクエストを、ウェブ編成情報管理サーバー装置９１に対して送信する。ウェブ編成情報管理サーバー装置９１は、このリクエストを受信する。
【0144】
ステップＳ３０３において、ステップＳ３０２でのリクエストに応じて、ウェブ編成情報管理サーバー装置９１は、レスポンスとして、ウェブリソースのサービス一覧の情報を、受信端末装置２に対して送信する。
【0145】
ステップＳ３０４において、受信端末装置２は、ウェブ編成情報管理サーバー装置９１から受け取ったウェブリソースのサービス一覧の情報を、クライアント端末装置３に送信する。クライアント端末装置３は、このレスポンスのデータを受信する。このレスポンスは、図３のステップＳ１０８で説明したものに相当する。
【0146】
図１５は、編成サービス一覧取得のレスポンスとして、受信端末装置２がクライアント端末装置３に対して送信するデータ（拡張されたレスポンス）の例を示す概略図である。このレスポンスのデータは、図１２を参照しながら説明したデータと同様に、第１のチャネルの情報（第１２行目から第１９行目まで）と、第２のチャネルの情報（第２０行目から第２７行目まで）とを含んでいる。第１のチャネルの情報において、論理チャネル番号は「０１１」である。また、メディアの種別は「ＴＤ」（地上デジタル）である。また、ストリームのＵＲＬは「/stream/32736.mpd」である。一方で、第２のチャネルの情報において、論理チャネル番号は「０２１」である。また、メディアの種別は「ＴＤ」（地上デジタル）である。また、ストリームのＵＲＬは「/stream/32737.mpd」である。このレスポンスのデータは、さらに、論理チャネル番号が「０００」のチャネルを含んでいる（第２９行目から第３６行目まで）。このチャネルは、「ＷＥＢ」（第３２行目）のメディアであり、そのストリームのＵＲＬは、「/stream/Utube.mpd」（第３３行目）である。また、このチャネルの放送チャネル名（broadcast_channel_name）は、「Utubeチャネル」（第３５行目）である。
【0147】
本手法によれば、特定のチャネル（有料チャネルや、トランスコードによる配信を禁止するチャネルや、通信（ネット）のみで配信するサービスなど）を反映したサービス編成を、リストに反映させることができる。
【0148】
本手法では、クライアント端末装置３が外部のサーバー装置（ウェブ編成情報管理サーバー装置９１）からサービスの一覧の情報を取得できるようにした。変形例として、クライアント端末装置３が、チャネルごとに、ウェブリソースとして利用することが可能か否かを表す情報を、外部のサーバー装置から取得するようにしてもよい。
【0149】
また、別の変形例として、受信端末装置２がウェブ編成情報管理サーバー装置９１に対してリクエストを送信する（図１４のステップＳ３０２）際に、番組編成情報（地上波デジタル、放送衛星デジタル、ＣＳデジタル）をリクエスト内に含めるようにしてもよい。これにより、クライアント端末装置３において視聴可能となる動画コンテンツを、その地域に対応したものとすることができる。
【0150】
（１１）ウェブサービス起動要求－その１（図４のステップＳ１２７およびＳ１２８）
このＡＰＩでは、クライアント端末装置３が、収集した情報に基づいて、受信端末装置２に対して、ウェブサービスの起動要求を行う。このウェブサービス起動要求のＡＰＩを通して、クライアント端末装置３は、受信端末装置２内のトランスコード部２６１による処理の開始あるいは終了を制御したり、処理パラメーターの設定（変更）を行ったりすることができる。
このＡＰＩでは、クライアント端末装置３が、収集した情報に基づいて、受信端末装置２に対して、ウェブサービスの起動要求を行う。このウェブサービス起動要求のＡＰＩを通して、クライアント端末装置３は、受信端末装置２内のトランスコード部２６１による処理の開始あるいは終了を制御したり、処理パラメーターの設定（変更）を行ったりすることができる。
【0151】
図１６は、クライアント端末装置３から受信端末装置２に対して送信されるウェブサービス起動要求のＡＰＩ（リクエスト）を示す概略図である。図示するように、このＡＰＩのＵＲＬは「＜BaseURL＞/webstream」である。「＜BaseURL＞」については、既に説明した通りである。また、このＡＰＩを呼び出すためのメソッドは「post」である。
【0152】
図１７は、図１６に示したウェブサービス起動要求のリクエストにパラメーター設定の記述を付加した例を示す概略図である。図示する例では、マニフェストファイルとして「/content/manifest.mpd」を指定している（第３行目）。また、セグメントサイズとして「６」を指定している（第４行目）。また、チャンクサイズとして「１」を指定している（第５行目）。さらに、トランスコード部２６１の処理のための他のパラメーターを指定するようにしてもよい。このように、本手法のＡＰＩを介して、クライアント端末装置３は、トランスコード部２６１の処理を制御することができる。
【0153】
なお、トランスコード部２６１の処理のためのパラメーターを予め設定しておく場合には、ウェブサービス起動要求のリクエストに明示的にパラメーター指定を含めないようにすることもできる。
【0154】
受信端末装置２のトランスコード部２６１は、ウェブサービス起動要求のリクエストに基づいて、エンコーディングの処理を行う。つまり、受信端末装置２が受信した放送信号から抽出された映像や音声を、ＭＰＥＧ－ＤＡＳＨ等の通信用コンテンツ（ネット動画）にエンコーディングする。即ち、トランスコード部２６１は、ＭＰＤ形式やＭＰ４形式のデータを生成する。
【0155】
図１８は、上記のウェブサービス起動要求のリクエストに対応するレスポンスの例を示す概略図である。このレスポンスは、受信端末装置２からクライアント端末装置３に送信される。このレスポンスデータは、ヘッダー部とボディー部とを含む。ヘッダー部の、コード（code）が「２０１」、メッセージ（message）が「Created」というデータは、ウェブサービス起動要求のリクエストが成功してリソースが生成されたことを表す。また、ボディー部のデータは、タスクＩＤが「１５１８０３７５」であることを表す。
【0156】
（１２）ウェブサービス起動要求－その２
本手法は、ウェブサービス起動要求のための代替手法である。本手法では、クライアント端末装置３は、受信端末装置２に対して、ＡＰＩを介したウェブサービス起動要求の明示的なリクエストを送信しない。本手法では、ハイブリッドキャストの端末連携機能におけるクライアント端末装置３からの選局リクエスト（Mode=tune）により、受信端末装置２のトランスコード部２６１が、自動的にトランスコードの処理を開始する。この選局リクエストとは、図３のステップＳ１０９における選局・ＨＣアプリ起動要求のリクエストにあたる。受信端末装置２内では、選局したサービスの映像や音声が、トランスコード部２６１に渡され、トランスコード部２６１がウェブ用のコンテンツとしての動画を生成する。
本手法は、ウェブサービス起動要求のための代替手法である。本手法では、クライアント端末装置３は、受信端末装置２に対して、ＡＰＩを介したウェブサービス起動要求の明示的なリクエストを送信しない。本手法では、ハイブリッドキャストの端末連携機能におけるクライアント端末装置３からの選局リクエスト（Mode=tune）により、受信端末装置２のトランスコード部２６１が、自動的にトランスコードの処理を開始する。この選局リクエストとは、図３のステップＳ１０９における選局・ＨＣアプリ起動要求のリクエストにあたる。受信端末装置２内では、選局したサービスの映像や音声が、トランスコード部２６１に渡され、トランスコード部２６１がウェブ用のコンテンツとしての動画を生成する。
【0157】
本手法においては、受信端末装置２のトランスコード部２６１への制御（開始／終了や、パラメーター設定）を予め決めておくようにしてもよい。あるいは、受信端末装置２とクライアント端末装置３との間の通信（図３のステップＳ１１５の端末連携通信）を用いて、クライアント端末装置３からのトランスコード部２６１の制御を行うようにしてもよい。
【0158】
（１３）ウェブサービス起動要求－その３
本手法は、ウェブサービス起動要求のためのさらなる代替手法である。本手法では、上記の選局リクエスト（図３のステップＳ１０９における選局・ＨＣアプリ起動要求のリクエスト）のパラメーターを拡張する。つまり、クライアント端末装置３が、選局・ＨＣアプリ起動要求のリクエストにおけるパラメーターとして「Mode=web」を追加できるようにする。
本手法は、ウェブサービス起動要求のためのさらなる代替手法である。本手法では、上記の選局リクエスト（図３のステップＳ１０９における選局・ＨＣアプリ起動要求のリクエスト）のパラメーターを拡張する。つまり、クライアント端末装置３が、選局・ＨＣアプリ起動要求のリクエストにおけるパラメーターとして「Mode=web」を追加できるようにする。
【0159】
図１９は、本手法において、クライアント端末装置３から受信端末装置２に対して送信される選局・ＨＣアプリ起動要求のＡＰＩ（リクエスト）を示す概略図である。図示するように、図示するように、このＡＰＩのＵＲＬは「＜BaseURL＞/Hybridcast」である。「＜BaseURL＞」については、既に説明した通りである。また、このＡＰＩを呼び出すためのメソッドは「post」である。また、このリクエストは、拡張クエリーとして「Mode=web」という記述を持つ。この拡張クエリーは、ウェブリソースに対する要求であることを表す。
【0160】
図２０は、図１９に示した選局・ＨＣアプリ起動要求のリクエストに付加したパラメーターの記述例を示す概略図である。図示する例において、第２行目から第１１行目までの記述は、既存のハイブリッドキャストの端末連携機能における記述である。具体的には、第２行目から第６行目までは、選局対象であるサービスのトランスポートストリームＩＤと、オリジナルネットワークＩＤと、サービスＩＤとを指定するための記述である。また、第７行目から第１１行目までは、ハイブリッドキャストのアプリに関する記述である。即ち、第８行目はＡＩＴ（アプリケーション情報テーブル）のＵＲＬを指定し、第９行目はサービス事業者のＩＤ（orgid）を指定し、第１０行目はアプリのＩＤ（appid）を指定するものである。
【0161】
図２０に示すデータの第１２行目から第１６行目までが、本実施形態において拡張された記述の部分である。つまり、この記述は、ウェブリソースを獲得するための、クライアント端末装置３による受信端末装置２のトランスコード部２６１の制御用の記述である。この記述例は、図１７に示したデータに対応する。即ち、第１２行目の「webstream」はウェブリソースに関する記述であることを表す。また、第１３行目は、マニフェストファイルのＵＲＬを指定する記述である。また、第１４行目は、セグメント長を指定する記述である。また、第１５行目は、チャンク長を指定する記述である。これにより、クライアント端末装置３は、トランスコード部２６１を制御することができる。
【0162】
なお、本手法の変形例として、図２０の第１２行目から第１６行目までの記述を行わないようにしてもよい。その場合には、受信端末装置２側のトランスコード部２６１のパラメーターを、予め設定しておくようにする。
【0163】
図２１は、本手法における選局・ＨＣアプリ起動要求（ＡＰＩ）のレスポンスのデータの例を示す概略図である。このレスポンスのデータは、例えば、ＪＳＯＮ形式で記述される。レスポンスのデータは、ヘッダー部とボディー部とを持つ。ヘッダー部に含まれるメッセージのうち、「webstream」についての記述は、本実施形態で拡張された記述である。その値「Created」は、ウェブリソースの生成が正常に完了したことを表す。また、ボディー部は、タスクＩＤの情報を含む。
【0164】
（１４）ウェブサービス起動可否状態取得－その１（図４のステップＳ１２９およびＳ１３０）
このＡＰＩでは、クライアント端末装置３が、受信端末装置２に対して、ウェブサービス起動可否状態の取得をリクエストする。これに対応して、受信端末装置２は、ウェブサービス起動可否状態の情報を、レスポンスとして、クライアント端末装置３に送信する。具体的には、受信端末装置２は、トランスコード部２６１の実行状況を表す情報を、上記レスポンスとしてクライアント端末装置３に送信する機能を持つ。これにより、クライアント端末装置３側で、受信端末装置２におけるトランスコーディングの処理状態を把握することができる。言い換えれば、受信端末装置２におけるサービスの起動が出来ているか否かを把握することができる。
このＡＰＩでは、クライアント端末装置３が、受信端末装置２に対して、ウェブサービス起動可否状態の取得をリクエストする。これに対応して、受信端末装置２は、ウェブサービス起動可否状態の情報を、レスポンスとして、クライアント端末装置３に送信する。具体的には、受信端末装置２は、トランスコード部２６１の実行状況を表す情報を、上記レスポンスとしてクライアント端末装置３に送信する機能を持つ。これにより、クライアント端末装置３側で、受信端末装置２におけるトランスコーディングの処理状態を把握することができる。言い換えれば、受信端末装置２におけるサービスの起動が出来ているか否かを把握することができる。
【0165】
図２２は、クライアント端末装置３から受信端末装置２に対して送信されるウェブサービス起動可否状態取得のＡＰＩ（リクエスト）を示す概略図である。図示するように、このＡＰＩのＵＲＬは「＜BaseURL＞/webstream」である。「＜BaseURL＞」については、既に説明した通りである。また、このＡＰＩを呼び出すためのメソッドは「get」である。
【0166】
図２３は、図２２に示したウェブサービス起動可否状態取得のリクエストに対応するレスポンスのデータの例を示す概略図である。このレスポンスのデータは、受信端末装置２がクライアント端末装置３に対して送信するものである。図示するように、レスポンスのデータは、例えばＪＳＯＮ形式のデータとして記述される。図示するように、ウェブサービス起動可否状態取得ＡＰＩのレスポンスは、ヘッダー部とボディー部とを持つ。ヘッダー部については、既に説明した通りである。また、ボディー部は、タスクＩＤ「１５１８０３７５」の情報を含む。
【0167】
このレスポンスのボディー部が持つ「webresource」のブロック（第８行目から第１４行目まで）は、ウェブサービスの起動可否状態を表すデータである。図示する例では、受信端末装置２からクライアント端末装置３に対して返される結果は、次の通りである。即ち、状況（status）は「Done」（起動成功）である。また、「２００」というコード（code）と、「ＯＫ」というメッセージ（message）も、ウェブサービス起動のリクエストが正常に完了していることを表している。
【0168】
（１５）ウェブサービス起動可否状態取得－その２（図４のステップＳ１２９およびＳ１３０）
本手法は、上記のウェブサービス起動可否状態取得のＡＰＩをさらに拡張したものである。前述の図２３を参照しながら説明したレスポンスデータは、ウェブサービス全体についての状況を受信端末装置２からクライアント端末装置３に通知するものであった。本手法では、レスポンスデータは、ウェブサービス全体についてではなく、映像、音声、字幕等の各々のウェブリソースごとについての、起動可否（起動成功か否かを表す情報）を持つ。これにより、クライアント端末装置３は、各ウェブリソースについての起動状況を把握することができる。
本手法は、上記のウェブサービス起動可否状態取得のＡＰＩをさらに拡張したものである。前述の図２３を参照しながら説明したレスポンスデータは、ウェブサービス全体についての状況を受信端末装置２からクライアント端末装置３に通知するものであった。本手法では、レスポンスデータは、ウェブサービス全体についてではなく、映像、音声、字幕等の各々のウェブリソースごとについての、起動可否（起動成功か否かを表す情報）を持つ。これにより、クライアント端末装置３は、各ウェブリソースについての起動状況を把握することができる。
【0169】
（１６）ウェブサービス起動可否状態取得－その３
本手法では、ウェブサービス起動可否状態取得のＡＰＩを設ける代わりに、起動可否状態取得のＡＰＩ（図３のステップＳ１１１およびＳ１１２）を拡張する。具体的には、起動可否状態取得のレスポンス（図３のステップＳ１１２）を拡張する。
本手法では、ウェブサービス起動可否状態取得のＡＰＩを設ける代わりに、起動可否状態取得のＡＰＩ（図３のステップＳ１１１およびＳ１１２）を拡張する。具体的には、起動可否状態取得のレスポンス（図３のステップＳ１１２）を拡張する。
【0170】
図２４は、起動可否状態取得のＡＰＩを拡張したときのレスポンスのデータ例を示す概略図である。レスポンスのデータは、例えばＪＳＯＮ形式のデータとして記述される。起動可否状態取得ＡＰＩのレスポンスは、ヘッダー部とボディー部とを含む。ヘッダー部については既に説明した通りである。ボディー部は、タスクＩＤ「１５１８０３７５」の情報を含む。また、ボディー部は、ハイブリッドキャスト（"hybridcast"）の状況を表すブロック（第８行目から第１４行目まで）の他に、ウェブリソース（"webresource"）の状況を表すブロック（第１５行目から第２１行目まで）を持つ。本例では、ウェブリソースの状況（status）が「Done」（起動成功、利用可能）であることを表している。なお、状況が「NoProcess」（プロセス無し（つまり、起動失敗））という値もとり得る。
【0171】
上記の通り、本手法によれば、ウェブサービス起動可否状態取得のＡＰＩを設ける代わりに、起動可否状態取得のＡＰＩを拡張する。これにより、クライアント端末装置３は、ウェブサービスの起動可否状態の情報を取得することができる。
【0172】
（１７）ウェブサービス状態取得－その１（図４のステップＳ１３１およびＳ１３２）
このＡＰＩでは、クライアント端末装置３が、受信端末装置２に対して、ウェブサービス状態の取得をリクエストする。これに対応して、受信端末装置２は、ウェブサービス状態の情報を、レスポンスとして、クライアント端末装置３に送信する。これにより、クライアント端末装置３は、トランスコードの状態（実行中であるか否か、など）を取得することができる。
このＡＰＩでは、クライアント端末装置３が、受信端末装置２に対して、ウェブサービス状態の取得をリクエストする。これに対応して、受信端末装置２は、ウェブサービス状態の情報を、レスポンスとして、クライアント端末装置３に送信する。これにより、クライアント端末装置３は、トランスコードの状態（実行中であるか否か、など）を取得することができる。
【0173】
図２５は、クライアント端末装置３から受信端末装置２に対して送信されるウェブサービス状態取得のＡＰＩ（リクエスト）を示す概略図である。図示するように、このＡＰＩのＵＲＬは「＜BaseURL＞/webstatus」である。「＜BaseURL＞」については、既に説明した通りである。また、このＡＰＩを呼び出すためのメソッドは「get」である。
【0174】
図２６は、図２５に示したウェブサービス状態取得のリクエストに対応するレスポンスのデータの例を示す概略図である。このレスポンスのデータは、受信端末装置２がクライアント端末装置３に対して送信するものである。レスポンスのデータは、例えばＪＳＯＮ形式のデータとして記述される。ウェブサービス状態取得ＡＰＩのレスポンスは、ヘッダー部とボディー部とを持つ。ヘッダー部については、既に説明した通りである。
【0175】
ウェブサービス状態取得のレスポンスのボディー部は、状態（status）を表すブロック（第７行目から第１４行目まで）を含む。この状態は、次のデータを含む。即ち、第８行目は、トランスコード（"transcode"）の処理が実行中（"Running"）であることを表すデータである。また、第１０行目から第１３行目までは、リソースの情報として、メディアが地上デジタル（"TD"）であること、およびマニフェストファイルのＵＲＬ（"manifest"）が「/stream/32736.mpd」であることを表すデータである。
【0176】
（１８）ウェブサービス状態取得－その２（図４のステップＳ１３１およびＳ１３２）
本手法では、上で説明したウェブサービス状態取得のＡＰＩをさらに拡張する。上の図２６のレスポンスデータは、ウェブサービスについて全体として１つの状態を表すものであった。本手法では、受信端末装置２は、各々のウェブサービスごとの状態をレスポンスとしてクライアント端末装置３に返す。なお、本手法のＡＰＩにおけるリクエストのデータは、既に説明した図２５のデータと同様である。
本手法では、上で説明したウェブサービス状態取得のＡＰＩをさらに拡張する。上の図２６のレスポンスデータは、ウェブサービスについて全体として１つの状態を表すものであった。本手法では、受信端末装置２は、各々のウェブサービスごとの状態をレスポンスとしてクライアント端末装置３に返す。なお、本手法のＡＰＩにおけるリクエストのデータは、既に説明した図２５のデータと同様である。
【0177】
図２７は、本手法においてウェブサービス状態取得のリクエストに対応して返されるレスポンスデータの例を示す概略図である。このレスポンスのデータは、受信端末装置２がクライアント端末装置３に対して送信するものである。レスポンスのデータは、例えばＪＳＯＮ形式のデータとして記述される。ウェブサービス状態取得ＡＰＩのレスポンスは、ヘッダー部とボディー部とを持つ。ヘッダー部については、既に説明した通りである。
【0178】
図２７に示すレスポンスのボディー部は、状態（status）を表すブロック（第７行目から第２２行目まで）を含む。この状態のデータの内容は、次の通りである。第８行目のデータは、トランスコード処理（"transcode"）の状態を表す。第９行目のデータは、映像（"VIDEO"）の状態を表す。第１０行目のデータは、音声（"AUDIO"）の状態を表す。第１１行目のデータは、字幕（"SUBTITLE"）の状態を表す。第１２行目のデータは、イベントメッセージ（"EVENT"）の状態を表す。第１３行目のデータは、ＢＭＬで記述されたデータ放送コンテンツ（"BML"）の状態を表す。第１４行目のデータは、ハイブリッドキャスト（"AIT"）の状態を表す。第１５行目のデータは、電子番組表（"EPG"）の状態を表す。第１６行目のデータは、サービス情報（"SI"）の状態を表す。上記のそれぞれにおいて、「Running」は、そのサービスが実行中であることを示す。また、「NotRunning」は、そのサービスが実行中ではないことを示す。また、第１８行目から第２１行目までは、リソースの情報として、メディアが地上デジタル（"TD"）であること、およびマニフェストファイルのＵＲＬ（"manifest"）が「/stream/32736.mpd」であることを表すデータである。
【0179】
（１９）ウェブサービス状態取得－その３
本手法では、ウェブサービス状態取得のためのＡＰＩを設けず、受信機状態取得ＡＰＩ（図３のステップＳ１１３およびＳ１１４）を拡張することによって、クライアント端末装置３がウェブサービス状態を取得できるようにする。
本手法では、ウェブサービス状態取得のためのＡＰＩを設けず、受信機状態取得ＡＰＩ（図３のステップＳ１１３およびＳ１１４）を拡張することによって、クライアント端末装置３がウェブサービス状態を取得できるようにする。
【0180】
図２８は、本手法において受信機状態取得のリクエストに対応して返される拡張されたレスポンスデータの例を示す概略図である。このレスポンスのデータは、受信端末装置２がクライアント端末装置３に対して送信するものである。レスポンスのデータは、例えばＪＳＯＮ形式のデータとして記述される。ウェブサービス状態取得ＡＰＩのレスポンスは、ヘッダー部とボディー部とを持つ。ヘッダー部については、既に説明した通りである。
【0181】
図２８に示すレスポンスのボディー部は、状態（status）を表すブロック（第７行目から第１６行目まで）を持つ。この状態データは、拡張されたデータとして、トランスコード処理（"transcode"）の状態を表す情報を含む。本例では、その値は、「Running」（実行中）である。トランスコード処理が実行中ではない場合の値は「NotStarted」である。このレスポンスのデータにより、クライアント端末装置３は、受信端末装置２の状態を把握することができる。
【0182】
（２０）端末連携通信ＡＰＩの活用（図３のステップＳ１１５）
ハイブリッドキャストの端末連携機能による端末連携通信のＡＰＩを活用することによって、本実施形態における様々な処理を実現することができる。具体例としては、クライアント端末装置３が、受信端末装置２のトランスコード部２６１に対して、エンコード処理の開始や、トランスコード処理に関連するパラメーターの設定変更や、トランスコード部２６１が持つキャッシュメモリーの削除などをリクエストすることができる。また、クライアント端末装置３が、この端末連携通信ＡＰＩを経由して、受信端末装置２のトランスコード部２６１に対して、ユーザーによる操作の情報を送信することができる。この操作の情報は、動画再生（ウェブリソース）の開始あるいは停止といった操作を含む。つまり、ハイブリッドキャストの端末連携機能による端末連携通信のＡＰＩを介して、クライアント端末装置３と受信端末装置２とが相互に通信することによって、クライアント端末装置３側でのウェブリソースの活用が可能となる。
ハイブリッドキャストの端末連携機能による端末連携通信のＡＰＩを活用することによって、本実施形態における様々な処理を実現することができる。具体例としては、クライアント端末装置３が、受信端末装置２のトランスコード部２６１に対して、エンコード処理の開始や、トランスコード処理に関連するパラメーターの設定変更や、トランスコード部２６１が持つキャッシュメモリーの削除などをリクエストすることができる。また、クライアント端末装置３が、この端末連携通信ＡＰＩを経由して、受信端末装置２のトランスコード部２６１に対して、ユーザーによる操作の情報を送信することができる。この操作の情報は、動画再生（ウェブリソース）の開始あるいは停止といった操作を含む。つまり、ハイブリッドキャストの端末連携機能による端末連携通信のＡＰＩを介して、クライアント端末装置３と受信端末装置２とが相互に通信することによって、クライアント端末装置３側でのウェブリソースの活用が可能となる。
【0183】
図２９は、クライアント端末装置３の内部の概略機能構成を示すブロック図である。図示するように、クライアント端末装置３は、通信部３３１と、アプリケーションエンジン３５２と、アプリケーションロンチャー３５３と、受信端末連携制御部３６３とを含んで構成される。クライアント端末装置３は、電子回路を用いて実現可能である。クライアント端末装置３が持つ機能の少なくとも一部を、コンピューターとプログラムとで実現してもよい。各部の機能は、次の通りである。
【0184】
なお、クライアント端末装置３を構成する機能は、必ずしもすべて同一のハードウェア上に実現される必要はない。複数の装置（ハードウェア）上に分散する形（疎結合）でクライアント端末装置３を実現してもよい。
【0185】
通信部３３１は、外部の装置との通信を行う。通信部３３１は、例えば、インターネットプロトコル（ＩＰ）を用いて、外部と通信する。通信部３３１の機能により、クライアント端末装置３は、受信端末装置２等との間で相互に通信を行うことが可能となる。
【0186】
アプリケーションエンジン３５２は、アプリケーションプログラムを実行させるものである。図示するように、例えばウェブアプリケーションは、アプリケーションエンジン３５２上で実行されるプログラムの一つである。具体的には、アプリケーションエンジン３５２は、受信端末装置２からウェブリソースを受信して利用するウェブアプリケーションを稼働させる。
【0187】
上記のウェブアプリケーションは、ウェブコンテンツを表示する機能を有するものである。ウェブコンテンツは、ＨＴＭＬ（ハイパーテキストマークアップ言語）で記述されたコンテンツや、ＭＰＥＧ－ＤＡＳＨ動画再生プレーヤーなどを含むものである。
【0188】
アプリケーションロンチャー３５３は、アプリケーションエンジン３５２上で特定のアプリケーションプログラムを起動させるものである。アプリケーションロンチャー３５３は、例えばユーザーの操作等に基づいて、上記のウェブアプリケーションを起動させる。
【0189】
受信端末連携制御部３６３は、受信端末装置２との間で、ハイブリッドキャストの端末連携機能による連携動作を行う。具体的には、受信端末連携制御部３６３は、受信端末装置２が提供するウェブリソースを利用するための情報を、ハイブリッドキャストの端末連携機能のＡＰＩを介して取得する。ハイブリッドキャストの端末連携機能は標準化された技術であるため、受信端末装置２とクライアント端末装置３との間では、装置のメーカー等に依存しない形で、相互に連携することが可能となる。
【0190】
つまり、受信端末連携制御部３６３は、ハイブリッドキャストの端末連携機能により、ウェブリソースを利用するために必要な処理を、受信端末装置２との連携動作として実行する。具体的には、受信端末連携制御部３６３は、少なくとも、ウェブリソースを利用するためのロケーション（エンドポイント等）の情報を受信端末装置２から受信する。
【0191】
図３０は、本実施形態におけるシステム１を構成する各装置（受信端末装置２、クライアント端末装置３、ウェブ編成情報管理サーバー装置９１、あるいはその他の必要なサーバー装置等）の内部構成の例を示すブロック図である。各装置は、コンピューターを用いて実現され得る。図示するように、そのコンピューターは、中央処理装置９０１と、ＲＡＭ９０２と、入出力ポート９０３と、入出力デバイス９０４や９０５等と、バス９０６と、を含んで構成される。コンピューター自体は、既存技術を用いて実現可能である。中央処理装置９０１は、ＲＡＭ９０２等から読み込んだプログラムに含まれる命令を実行する。中央処理装置９０１は、各命令にしたがって、ＲＡＭ９０２にデータを書き込んだり、ＲＡＭ９０２からデータを読み出したり、算術演算や論理演算を行ったりする。ＲＡＭ９０２は、データやプログラムを記憶する。ＲＡＭ９０２に含まれる各要素は、アドレスを持ち、アドレスを用いてアクセスされ得るものである。なお、ＲＡＭは、「ランダムアクセスメモリー」の略である。入出力ポート９０３は、中央処理装置９０１が外部の入出力デバイス等とデータのやり取りを行うためのポートである。入出力デバイス９０４や９０５は、入出力デバイスである。入出力デバイス９０４や９０５は、入出力ポート９０３を介して中央処理装置９０１との間でデータをやりとりする。バス９０６は、コンピューター内部で使用される共通の通信路である。例えば、中央処理装置９０１は、バス９０６を介してＲＡＭ９０２のデータを読んだり書いたりする。また、例えば、中央処理装置９０１は、バス９０６を介して入出力ポートにアクセスする。
【0192】
なお、各装置の少なくとも一部の機能をコンピューターで実現する場合、この機能を実現するためのプログラムをコンピューター読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピューターシステムに読み込ませ、実行する。なお、ここでいう「コンピューターシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピューター読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、ＵＳＢメモリー等の可搬媒体、コンピューターシステムに内蔵されるハードディスク等の記憶装置のことをいう。つまり、「コンピューター読み取り可能な記録媒体」とは、非一過性の（non-transitory）コンピューター読み取り可能な記録媒体であってよい。さらに「コンピューター読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、一時的に、動的にプログラムを保持するもの、その場合のサーバーやクライアントとなるコンピューターシステム内部の揮発性メモリーのように、一定時間プログラムを保持しているものも含んでも良い。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピューターシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。
【0193】
［変形例１］
上の実施形態の説明では、受信端末装置２とクライアント端末装置３との間の連携動作（連携のための各種制御）の機能を、一通り述べた。ただし、必ずしも上で説明した機能のすべてを受信端末装置２とクライアント端末装置３に実装する必要はない。一部の機能を省略した状態で、受信端末装置２やクライアント端末装置３を実施してもよい。その場合にも、クライアント端末装置３は、与えられるロケーション情報に基づいて、受信端末装置２が提供するウェブリソースのデータを取得し、利用することができる。
上の実施形態の説明では、受信端末装置２とクライアント端末装置３との間の連携動作（連携のための各種制御）の機能を、一通り述べた。ただし、必ずしも上で説明した機能のすべてを受信端末装置２とクライアント端末装置３に実装する必要はない。一部の機能を省略した状態で、受信端末装置２やクライアント端末装置３を実施してもよい。その場合にも、クライアント端末装置３は、与えられるロケーション情報に基づいて、受信端末装置２が提供するウェブリソースのデータを取得し、利用することができる。
【0194】
［変形例２］
上の実施形態の説明では、受信端末装置２が受信する放送信号に含まれるリソースのうち、特に、映像および音声をトランスコードして、映像および音声のウェブリソースとして、受信端末装置２からクライアント端末装置３に送信する場合を説明した。ただし、端末連携によってクライアント端末３に送信する放送のリソースは、必ずしも映像や音声に限定されない。放送リソースが含む映像、音声、字幕、ＳＩ（サービス情報）、ＥＰＧ（電子番組表）、ＥＭ（イベントメッセージ）、ＡＩＴ（アプリケーション情報テーブル）のいずれかの情報を、ウェブリソースとして受信端末装置２からクライアント端末装置３に対して送信するようにしてもよい。この場合にも、上で説明した受信端末装置２とクライアント端末装置３との間の連携の制御の手順等を使用することができる。
上の実施形態の説明では、受信端末装置２が受信する放送信号に含まれるリソースのうち、特に、映像および音声をトランスコードして、映像および音声のウェブリソースとして、受信端末装置２からクライアント端末装置３に送信する場合を説明した。ただし、端末連携によってクライアント端末３に送信する放送のリソースは、必ずしも映像や音声に限定されない。放送リソースが含む映像、音声、字幕、ＳＩ（サービス情報）、ＥＰＧ（電子番組表）、ＥＭ（イベントメッセージ）、ＡＩＴ（アプリケーション情報テーブル）のいずれかの情報を、ウェブリソースとして受信端末装置２からクライアント端末装置３に対して送信するようにしてもよい。この場合にも、上で説明した受信端末装置２とクライアント端末装置３との間の連携の制御の手順等を使用することができる。
【0195】
以上、この発明の実施形態（変形例を含む）について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【産業上の利用可能性】
【0196】
本発明は、例えば、映像等のコンテンツを提供する産業、およびそのための機器類を製造あるいは販売等する産業等に利用することができる。但し、本発明の利用範囲はここに例示したものには限られない。
【符号の説明】
【0197】
１ システム
２ 受信端末装置（受信装置）
３ クライアント端末装置
４ アンテナ
８ ルーター
９１ ウェブ編成情報管理サーバー装置
２０１ チューナー部（受信部）
２０２ デスクランブラー
２０３ デマルチプレクサー
２１１ データ放送処理部
２１２ 映像デコーダー部
２１３ 音声デコーダー部
２１４ 字幕デコーダー部
２２１ データ放送エンジン
２３１ 通信部
２３２ ストリーミング受信部
２３３ デマルチプレクサー
２４２ 映像デコーダー部
２４３ 音声デコーダー部
２４４ 字幕デコーダー部
２５１ アプリケーション制御部
２５２ アプリケーションエンジン
２５３ アプリケーションロンチャー
２６１ トランスコード部
２６２ ウェブリソース提供部
２６３ クライアント端末連携制御部
２７１ 映像出力部
２７２ 音声出力部
３３１ 通信部
３５２ アプリケーションエンジン
３５３ アプリケーションロンチャー
３６３ 受信端末連携制御部
９０１ 中央処理装置
９０２ ＲＡＭ
９０３ 入出力ポート
９０４，９０５ 入出力デバイス
９０６ バス
２ 受信端末装置（受信装置）
３ クライアント端末装置
４ アンテナ
８ ルーター
９１ ウェブ編成情報管理サーバー装置
２０１ チューナー部（受信部）
２０２ デスクランブラー
２０３ デマルチプレクサー
２１１ データ放送処理部
２１２ 映像デコーダー部
２１３ 音声デコーダー部
２１４ 字幕デコーダー部
２２１ データ放送エンジン
２３１ 通信部
２３２ ストリーミング受信部
２３３ デマルチプレクサー
２４２ 映像デコーダー部
２４３ 音声デコーダー部
２４４ 字幕デコーダー部
２５１ アプリケーション制御部
２５２ アプリケーションエンジン
２５３ アプリケーションロンチャー
２６１ トランスコード部
２６２ ウェブリソース提供部
２６３ クライアント端末連携制御部
２７１ 映像出力部
２７２ 音声出力部
３３１ 通信部
３５２ アプリケーションエンジン
３５３ アプリケーションロンチャー
３６３ 受信端末連携制御部
９０１ 中央処理装置
９０２ ＲＡＭ
９０３ 入出力ポート
９０４，９０５ 入出力デバイス
９０６ バス
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】