(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023122560
(43)【公開日】2023-09-01
(54)【発明の名称】受信機およびプログラム
(51)【国際特許分類】
H04N 21/443 20110101AFI20230825BHJP
H04N 21/4363 20110101ALI20230825BHJP
H04H 40/18 20080101ALI20230825BHJP
H04H 60/82 20080101ALI20230825BHJP
H04H 20/26 20080101ALI20230825BHJP
【ＦＩ】
H04N21/443
H04N21/4363
H04H40/18
H04H60/82
H04H20/26
【審査請求】未請求
【請求項の数】11
【出願形態】ＯＬ
(21)【出願番号】P 2023023419
(22)【出願日】2023-02-17
(31)【優先権主張番号】P 2022026082
(32)【優先日】2022-02-22
(33)【優先権主張国・地域又は機関】JP
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡＳＣＲＩＰＴ
２．ＷｅｂＯＳ
３．ＮＥＴＦＬＩＸ
４．ＴＶｅｒ
５．ティーバー
(71)【出願人】
【識別番号】000004352
【氏名又は名称】日本放送協会
(74)【代理人】
【識別番号】100141139
【弁理士】
【氏名又は名称】及川 周
(74)【代理人】
【識別番号】100171446
【弁理士】
【氏名又は名称】高田 尚幸
(74)【代理人】
【識別番号】100114937
【弁理士】
【氏名又は名称】松本 裕幸
(74)【代理人】
【識別番号】100171930
【弁理士】
【氏名又は名称】木下 郁一郎
(72)【発明者】
【氏名】瀧口 徹
(72)【発明者】
【氏名】遠藤 大礎
(72)【発明者】
【氏名】松村 欣司
(72)【発明者】
【氏名】藤沢 寛
【テーマコード（参考）】
5C164
【Ｆターム（参考）】
5C164FA11
5C164UB41S
5C164UB51P
5C164UB72P
5C164YA21
(57)【要約】
【課題】より柔軟に放送コンテンツと通信コンテンツとの間の切り替えが行えるようにすることのできる受信機を提供する。
【解決手段】受信機は、コンテンツ提示機能部と、アプリケーション稼働部と、制御部とを備える。コンテンツ提示機能部は、放送信号によるコンテンツあるいは通信によるコンテンツを受信し、前記コンテンツを提示する。アプリケーション稼働部は、アプリケーションを稼働させる環境を含む。制御部は、前記アプリケーション稼働部での前記アプリケーションの稼働を制御する。また、制御部は、受信機搭載オペレーティングシステム用アプリケーションから、ハイブリッドキャストアプリケーションを起動する。
【選択図】図１
【解決手段】受信機は、コンテンツ提示機能部と、アプリケーション稼働部と、制御部とを備える。コンテンツ提示機能部は、放送信号によるコンテンツあるいは通信によるコンテンツを受信し、前記コンテンツを提示する。アプリケーション稼働部は、アプリケーションを稼働させる環境を含む。制御部は、前記アプリケーション稼働部での前記アプリケーションの稼働を制御する。また、制御部は、受信機搭載オペレーティングシステム用アプリケーションから、ハイブリッドキャストアプリケーションを起動する。
【選択図】図１
【特許請求の範囲】
【請求項1】
放送信号によるコンテンツあるいは通信によるコンテンツを受信し、前記コンテンツを提示するコンテンツ提示機能部と、
アプリケーションを稼働させる環境を含むアプリケーション稼働部と、
前記アプリケーション稼働部での前記アプリケーションの稼働を制御する制御部と、
を備え、
前記制御部は、所定のアプリケーションを起動させる要求を受けたとき、自装置の内部からハイコネ機能を呼び出すことによって所定のアプリケーションの起動を行うとともに、当該ハイコネ機能を呼び出す手順のうちの、
（Ａ）ＤＩＡＬ（Discovery-and-Launch）プロトコルを用いて受信機を発見する機能に代えて、（Ａ１）自装置のローカルホストのアドレスを対象として接続処理を行う、または、（Ａ２）受信機の発見を行わない、こととする、
または、
（Ｂ）前記ハイコネ機能によるアプリケーションの起動の際の、要求元と要求先との間の認証の手続を行わない、こととする、
の少なくともいずれか一方とする、
受信機。
アプリケーションを稼働させる環境を含むアプリケーション稼働部と、
前記アプリケーション稼働部での前記アプリケーションの稼働を制御する制御部と、
を備え、
前記制御部は、所定のアプリケーションを起動させる要求を受けたとき、自装置の内部からハイコネ機能を呼び出すことによって所定のアプリケーションの起動を行うとともに、当該ハイコネ機能を呼び出す手順のうちの、
（Ａ）ＤＩＡＬ（Discovery-and-Launch）プロトコルを用いて受信機を発見する機能に代えて、（Ａ１）自装置のローカルホストのアドレスを対象として接続処理を行う、または、（Ａ２）受信機の発見を行わない、こととする、
または、
（Ｂ）前記ハイコネ機能によるアプリケーションの起動の際の、要求元と要求先との間の認証の手続を行わない、こととする、
の少なくともいずれか一方とする、
受信機。
【請求項2】
放送信号によるコンテンツあるいは通信によるコンテンツを受信し、前記コンテンツを提示するコンテンツ提示機能部と、
アプリケーションを稼働させる環境を含むアプリケーション稼働部と、
前記アプリケーション稼働部での前記アプリケーションの稼働を制御する制御部と、
を備え、
前記制御部は、受信機搭載オペレーティングシステム用アプリケーションから、ハイブリッドキャストアプリケーションを起動する、
受信機。
アプリケーションを稼働させる環境を含むアプリケーション稼働部と、
前記アプリケーション稼働部での前記アプリケーションの稼働を制御する制御部と、
を備え、
前記制御部は、受信機搭載オペレーティングシステム用アプリケーションから、ハイブリッドキャストアプリケーションを起動する、
受信機。
【請求項3】
前記制御部は、放送マネージドアプリケーションとして前記他のアプリケーションを起動するよう要求を受けた場合には、受信機の利用可能メディア情報および利用可能チャンネル情報の取得を行い、取得した利用可能メディア情報および利用可能チャンネル情報が前記他のアプリケーションと整合する場合にのみ、前記他のアプリケーションを起動する、
請求項２に記載の受信機。
請求項２に記載の受信機。
【請求項4】
前記制御部は、自装置で稼働するハイブリッドキャストアプリケーションからのＡＰＩを介した要求があった際に、指定された放送サービスを選局し、且つ指定されたハイブリッドキャストアプリケーションを起動する、
請求項１または２に記載の受信機。
請求項１または２に記載の受信機。
【請求項5】
前記制御部は、外部の連携端末装置からのＡＰＩを介した要求として、自装置で稼働するハイブリッドキャストアプリケーションの状況を問い合わせる要求を受けた際に、稼働するハイブリッドキャストアプリケーションの状況を表す情報として、当該ハイブリッドキャストアプリケーションが、放送非依存マネージドアプリケーションであるか放送マネージドアプリケーションであるかを表す情報を、要求元の前記連携端末装置に返す、
請求項１または２に記載の受信機。
請求項１または２に記載の受信機。
【請求項6】
前記制御部は、外部の連携端末装置からのＡＰＩを介した要求として、自装置で稼働するハイブリッドキャストアプリケーションの状況を問い合わせる要求を受けた際に、稼働するハイブリッドキャストアプリケーションの状況を表す情報として、当該ハイブリッドキャストアプリケーションを識別するための情報を、要求元の前記連携端末装置に返す、
請求項１または２に記載の受信機。
請求項１または２に記載の受信機。
【請求項7】
前記ハイブリッドキャストアプリケーションを識別するための情報は、当該ハイブリッドキャストアプリケーションに関連するＵＲＬ（ユニフォームリソースロケーター）である、
請求項６に記載の受信機。
請求項６に記載の受信機。
【請求項8】
放送信号によるコンテンツあるいは通信によるコンテンツを受信し、前記コンテンツを提示するコンテンツ提示機能部と、
アプリケーションを稼働させる環境を含むアプリケーション稼働部と、
前記アプリケーション稼働部での前記アプリケーションの稼働を制御する制御部と、
を備え、
前記制御部は、自装置で稼働するハイブリッドキャストアプリケーションからのＡＰＩを介した要求があった際に、指定された放送サービスを選局し、且つ指定されたハイブリッドキャストアプリケーションを起動する、
受信機。
アプリケーションを稼働させる環境を含むアプリケーション稼働部と、
前記アプリケーション稼働部での前記アプリケーションの稼働を制御する制御部と、
を備え、
前記制御部は、自装置で稼働するハイブリッドキャストアプリケーションからのＡＰＩを介した要求があった際に、指定された放送サービスを選局し、且つ指定されたハイブリッドキャストアプリケーションを起動する、
受信機。
【請求項9】
放送信号によるコンテンツあるいは通信によるコンテンツを受信し、前記コンテンツを提示するコンテンツ提示機能部と、
アプリケーションを稼働させる環境を含むアプリケーション稼働部と、
前記アプリケーション稼働部での前記アプリケーションの稼働を制御する制御部と、
を備え、
前記制御部は、外部の連携端末装置からのＡＰＩを介した要求として、自装置で稼働するハイブリッドキャストアプリケーションの状況を問い合わせる要求を受けた際に、稼働するハイブリッドキャストアプリケーションの状況を表す情報として、当該ハイブリッドキャストアプリケーションが、放送非依存マネージドアプリケーションであるか放送マネージドアプリケーションであるかを表す情報を、要求元の前記連携端末装置に返す、
受信機。
アプリケーションを稼働させる環境を含むアプリケーション稼働部と、
前記アプリケーション稼働部での前記アプリケーションの稼働を制御する制御部と、
を備え、
前記制御部は、外部の連携端末装置からのＡＰＩを介した要求として、自装置で稼働するハイブリッドキャストアプリケーションの状況を問い合わせる要求を受けた際に、稼働するハイブリッドキャストアプリケーションの状況を表す情報として、当該ハイブリッドキャストアプリケーションが、放送非依存マネージドアプリケーションであるか放送マネージドアプリケーションであるかを表す情報を、要求元の前記連携端末装置に返す、
受信機。
【請求項10】
放送信号によるコンテンツあるいは通信によるコンテンツを受信し、前記コンテンツを提示するコンテンツ提示機能部と、
アプリケーションを稼働させる環境を含むアプリケーション稼働部と、
前記アプリケーション稼働部での前記アプリケーションの稼働を制御する制御部と、
を備え、
前記制御部は、外部の連携端末装置からのＡＰＩを介した要求として、自装置で稼働するハイブリッドキャストアプリケーションの状況を問い合わせる要求を受けた際に、稼働するハイブリッドキャストアプリケーションの状況を表す情報として、当該ハイブリッドキャストアプリケーションを識別するための情報を、要求元の前記連携端末装置に返す、
受信機。
アプリケーションを稼働させる環境を含むアプリケーション稼働部と、
前記アプリケーション稼働部での前記アプリケーションの稼働を制御する制御部と、
を備え、
前記制御部は、外部の連携端末装置からのＡＰＩを介した要求として、自装置で稼働するハイブリッドキャストアプリケーションの状況を問い合わせる要求を受けた際に、稼働するハイブリッドキャストアプリケーションの状況を表す情報として、当該ハイブリッドキャストアプリケーションを識別するための情報を、要求元の前記連携端末装置に返す、
受信機。
【請求項11】
放送信号の受信機能を備えるコンピューターを、
請求項１、請求項２、請求項８、請求項９、または請求項１０のいずれか一項に記載の受信機、
として機能させるためのプログラム。
請求項１、請求項２、請求項８、請求項９、または請求項１０のいずれか一項に記載の受信機、
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、受信機およびプログラムに関する。
【背景技術】
【0002】
従来技術によるテレビ（受信機）は、放送信号（例えば、地上デジタル放送の信号など）として配信された番組やインターネットを経由して配信された番組を受信し、ユーザーに対して提示する。ユーザーは、これらの番組を視聴することができる。ユーザーにとっては、番組が伝送経路（放送信号かインターネットか）を意識することなく簡単に番組を選択して視聴できることが好ましい。しかしながら、従来技術によるテレビは、放送のプラットフォームと通信（インターネット）のプラットフォームとが区切られた構成を有している。ユーザーは、それぞれの伝送経路で受信した番組を視聴するために所定の手順を踏む必要があった。放送番組を選択するためには、ユーザーは、例えば、番組表からチャンネルを選局する操作を行っていた。また、インターネットで配信される番組を視聴するためには、ユーザーは、例えば、ホーム画面からアプリを起動させる操作を行っていた。
【0003】
近年では、ハイブリッドキャストの技術が標準化され、実用化されている。ハイブリッドキャストは、放送と通信を連携させたり、放送のサービスと通信のサービスとの間での切り替えを可能とさせたりする技術である。ハイブリッドキャストは、ウェブの仕組みに準拠しているとともに、放送局が提供するコンテンツを安全・セキュアに利用するための仕組みを備えている。また、初期のハイブリッドキャストの利用には基本的に放送を受信していることが前提となっていた（放送マネージドアプリケーション（ＢＭＡ））のに対して、近年では、放送を受信していない状態でも放送局のコンテンツを安全に利用できるための放送非依存マネージドアプリケーション（ＢＩＡ）が提案され、標準化されている。
【0004】
非特許文献１、２、および３には、放送非依存マネージドアプリの標準技術について記載されている。
【0005】
また、非特許文献４には、伝送路を意識しない動画視聴を実現するテレビ向けの動画視聴アプリケーションについて記載されている。
【先行技術文献】
【非特許文献】
【0006】
【非特許文献1】ＩＰＴＶ規定，放送通信連携システム仕様，IPTVFJ STD-0010，2.3版，２０２０年１０月２日，一般社団法人ＩＰＴＶフォーラム．
【非特許文献2】ＩＰＴＶ規定，ＨＴＭＬ５ブラウザ仕様，IPTVFJ STD-0011，2.6版，２０２０年１０月２日，一般社団法人ＩＰＴＶフォーラム．
【非特許文献3】ＩＰＴＶ規定，ハイブリッドキャスト運用規定，IPTVFJ STD-0013，2.9版，２０２０年１０月２日，一般社団法人ＩＰＴＶフォーラム．
【非特許文献4】広中悠樹，藤津智，松村欣司，藤沢寛，伝送路を意識しない動画視聴を実現するテレビ向け動画視聴アプリケーションの試作評価，映像情報メディア学会技術報告，Vol.45，No.10，BCT2021-24，２０２１年３月．
【発明の概要】
【発明が解決しようとする課題】
【0007】
テレビにおける、放送によるサービスと通信によるサービスとの切り替えをより一層スムーズ（ザッピングレベルで）に行えるようにすることが望まれる。
【0008】
従来技術によるテレビ（受信機）が持つ機能は、放送受信領域と放送非受信領域とに分かれている。ユーザーがテレビのリモコン装置を操作することなどにより、放送受信領域と放送非受信領域のいずれの機能をも呼び出すことが可能である。
【0009】
［１．放送受信領域］
放送受信領域では、ウェブ標準技術を用いて、放送局既定のサービスが実行される。
放送受信領域では、ウェブ標準技術を用いて、放送局既定のサービスが実行される。
【0010】
［２．放送非受信領域］
放送非受信領域は、放送局既定のサービスの領域と、テレビ搭載ＯＳに依存する領域とがある。
放送非受信領域は、放送局既定のサービスの領域と、テレビ搭載ＯＳに依存する領域とがある。
【0011】
［２．１ 放送非受信領域の放送局既定のサービスの領域］
放送局既定のサービスの領域では、ウェブ標準技術を用いて、放送局既定のサービスが実行される。この領域は、ウェブ標準技術に依拠しているため、テレビメーカーごとのテレビ搭載ＯＳには依存しないサービスが実現可能である。
放送局既定のサービスの領域では、ウェブ標準技術を用いて、放送局既定のサービスが実行される。この領域は、ウェブ標準技術に依拠しているため、テレビメーカーごとのテレビ搭載ＯＳには依存しないサービスが実現可能である。
【0012】
［２．２ 放送非受信領域のテレビ搭載ＯＳの領域］
従来技術によるテレビは、各メーカーが開発しているテレビ用のＯＳ（オペレーティングシステム）を搭載している。これをテレビ搭載ＯＳと呼ぶ。テレビ搭載ＯＳは、例えば、Android（アンドロイド、登録商標）ＯＳやWebOSなどである。こういったテレビ搭載ＯＳのホーム画面からは、各種のネットコンテンツ（通信コンテンツ）を呼び出すことができる。ネットコンテンツは、例えば、NETFLIXやYouTube（登録商標）などである。また、テレビ搭載ＯＳのホーム画面からは、放送画面（放送受信領域）に遷移することが可能である。この放送受信領域への遷移は、テレビ搭載ＯＳのホーム画面において「テレビ」ボタンを実行することや、テレビ搭載ＯＳのホーム画面に表示されている受信チャンネルの一覧から特定のチャンネルを選択することなどによって行われる。放送非受信領域内のテレビ搭載ＯＳのホーム画面の機能は、テレビ搭載ＯＳごとに固有の機能であり、つまり、テレビメーカーごとに固有の機能である。
従来技術によるテレビは、各メーカーが開発しているテレビ用のＯＳ（オペレーティングシステム）を搭載している。これをテレビ搭載ＯＳと呼ぶ。テレビ搭載ＯＳは、例えば、Android（アンドロイド、登録商標）ＯＳやWebOSなどである。こういったテレビ搭載ＯＳのホーム画面からは、各種のネットコンテンツ（通信コンテンツ）を呼び出すことができる。ネットコンテンツは、例えば、NETFLIXやYouTube（登録商標）などである。また、テレビ搭載ＯＳのホーム画面からは、放送画面（放送受信領域）に遷移することが可能である。この放送受信領域への遷移は、テレビ搭載ＯＳのホーム画面において「テレビ」ボタンを実行することや、テレビ搭載ＯＳのホーム画面に表示されている受信チャンネルの一覧から特定のチャンネルを選択することなどによって行われる。放送非受信領域内のテレビ搭載ＯＳのホーム画面の機能は、テレビ搭載ＯＳごとに固有の機能であり、つまり、テレビメーカーごとに固有の機能である。
【0013】
放送局が提供するアプリをテレビ搭載ＯＳごとに固有の領域において稼働させることは、不可能または困難である。放送局が提供するアプリとは、例えば、ＴＶｅｒ（ティーバー）やＮＨＫプラスなどである。特定のテレビ搭載ＯＳ用のアプリを、他のテレビ搭載ＯＳ上で稼働させることはできない。放送局が提供するアプリをそれぞれのテレビ搭載ＯＳ上で稼働させるためには、それぞれのテレビ搭載ＯＳごとのアプリ開発や保守が必要であり、高コスト化する。また、テレビ搭載ＯＳ上の環境では、アプリは、ネットコンテンツ（通信コンテンツ）を受信して提示することはできても、放送信号のコンテンツを受信できなかったり、テレビ搭載ＯＳに依存する範囲内でしかログの収集を行えなかったりという問題がある。
【0014】
放送局が主体的にサービスを提供できる領域は、上記の１の放送受信領域、または２．１の放送非受信領域内における放送局既定のサービスの領域である。これらの領域では、ＩＰＴＶフォーラムで規定されたハイブリッドキャストの標準技術が利用される。ハイブリッドキャストの標準技術は、テレビ搭載ＯＳの種類に依存せず、またすべての放送局が共通に利用できる技術である。ハイブリッドキャストの技術では、国際標準であるＨＴＭＬブラウザーの機能や、放送サービスを提供する上で必要となる放送サービスの選択（選局）の機能などを、すべてのメーカーのテレビ上で共通に利用することができる。また、ハイブリッドキャストの技術では、放送局が提供するサービスの動作を、テレビ搭載ＯＳ上ではなく、ＨＴＭＬブラウザー上で実行するため、テレビ搭載ＯＳに依存せずにすべてのメーカーのテレビ上で共通のアプリとして提供することができる。また、視聴ログの収集に関しても、テレビ搭載ＯＳの領域では収集できる情報がメーカーに依存するのに対して、ハイブリッドキャストの領域ではテレビ搭載ＯＳに依存せずに放送局がマネージ可能なサービスを実現することができる。
【0015】
従来技術を用いる場合にテレビでハイブリッドキャスト（ＢＭＡあるいはＢＩＡ）を起動するためには、データ放送を経由して起動するか、ハイブリッドキャストを自動起動の設定とするか、端末連携機能を用いてアプリの外部起動（ハイコネ）をするか、といった起点から行うことが必要である。端末連携機能とは、テレビ（受信機）と同一のネットワーク内にある連携端末（例えば、スマホ等）から、テレビ（受信機）の機能を制御する仕組みである。端末連携機能を用いることにより、任意のハイブリッドキャストアプリを起動することができる。なお、ハイコネを用いない場合には、基本的に、初期で起動するハイブリッドキャストアプリは、放送信号に含まれているもののみである。
【0016】
つまり、従来技術では、テレビ（受信機）の、テレビ搭載ＯＳ上のサービス起動メニューにあるアプリケーションから、放送非依存マネージドアプリケーション（ＢＩＡ）を起動することができない。なお、放送非依存マネージドアプリケーション（ＢＩＡ）は、放送局によってマネージされている、放送非依存のアプリケーションである。また、従来技術では、放送非依存マネージドアプリケーション（ＢＩＡ）から放送マネージドアプリケーション（ＢＭＡ）に遷移することができない。
【0017】
本発明は、上記の課題認識に基づいて行なわれたものであり、従来技術では不可能であった放送コンテンツと通信コンテンツとの間の導線を構築でき、より柔軟に放送コンテンツと通信コンテンツとの間の切り替えが行えるようにすることのできる受信機およびプログラムを提供しようとするものである。
【課題を解決するための手段】
【0018】
［１］また、本発明の一態様による受信機は、放送信号によるコンテンツあるいは通信によるコンテンツを受信し、前記コンテンツを提示するコンテンツ提示機能部と、アプリケーションを稼働させる環境を含むアプリケーション稼働部と、前記アプリケーション稼働部での前記アプリケーションの稼働を制御する制御部と、を備え、前記制御部は、所定のアプリケーションを起動させる要求を受けたとき、自装置（当該受信機）の内部からハイコネ機能を呼び出すことによって所定のアプリケーションの起動を行うとともに、当該ハイコネ機能を呼び出す手順のうちの、（Ａ）ＤＩＡＬ（Discovery-and-Launch）プロトコルを用いて受信機を発見する機能に代えて、（Ａ１）自装置（当該受信機）のローカルホストのアドレスを対象として接続処理を行う、または、（Ａ２）受信機の発見を行わない、こととする、または、（Ｂ）前記ハイコネ機能によるアプリケーションの起動の際の、要求元と要求先との間の認証の手続を行わない、こととする、の少なくともいずれか一方とする、ものである。
【0019】
［２］上記の課題を解決するため、本発明の一態様による受信機は、放送信号によるコンテンツあるいは通信によるコンテンツを受信し、前記コンテンツを提示するコンテンツ提示機能部と、アプリケーションを稼働させる環境を含むアプリケーション稼働部と、前記アプリケーション稼働部での前記アプリケーションの稼働を制御する制御部と、を備え、前記制御部は、受信機搭載オペレーティングシステム用アプリケーションから、ハイブリッドキャストアプリケーションを起動する、ものである。
【0020】
［３］また、本発明の一態様は、上記［２］の受信機において、前記制御部は、放送マネージドアプリケーションとして前記他のアプリケーションを起動するよう要求を受けた場合には、受信機の利用可能メディア情報および利用可能チャンネル情報の取得を行い、取得した利用可能メディア情報および利用可能チャンネル情報が前記他のアプリケーションと整合する場合にのみ、前記他のアプリケーションを起動する、というものである。
【0021】
［４］また、本発明の一態様は、上記［１］から［３］までのいずれかの受信機において、前記制御部は、自装置（当該受信機）で稼働するハイブリッドキャストアプリケーションからのＡＰＩを介した要求があった際に、指定された放送サービスを選局し、且つ指定されたハイブリッドキャストアプリケーションを起動する、ものである。
【0022】
［５］また、本発明の一態様は、上記［１］から［４］までのいずれかの受信機において、前記制御部は、外部の連携端末装置からのＡＰＩを介した要求として、自装置（当該受信機）で稼働するハイブリッドキャストアプリケーションの状況を問い合わせる要求を受けた際に、稼働するハイブリッドキャストアプリケーションの状況を表す情報として、当該ハイブリッドキャストアプリケーションが、放送非依存マネージドアプリケーションであるか放送マネージドアプリケーションであるかを表す情報を、要求元の前記連携端末装置に返す、というものである。
【0023】
［６］また、本発明の一態様は、上記［１］から［５］までのいずれかの受信機において、前記制御部は、外部の連携端末装置からのＡＰＩを介した要求として、自装置（当該受信機）で稼働するハイブリッドキャストアプリケーションの状況を問い合わせる要求を受けた際に、稼働するハイブリッドキャストアプリケーションの状況を表す情報として、当該ハイブリッドキャストアプリケーションを識別するための情報を、要求元の前記連携端末装置に返す、というものである。
【0024】
［７］また、本発明の一態様は、上記［６］の受信機において、前記ハイブリッドキャストアプリケーションを識別するための情報は、当該ハイブリッドキャストアプリケーションに関連するＵＲＬ（ユニフォームリソースロケーター）であってよい。
【0025】
［８］また、本発明の一態様による受信機は、放送信号によるコンテンツあるいは通信によるコンテンツを受信し、前記コンテンツを提示するコンテンツ提示機能部と、アプリケーションを稼働させる環境を含むアプリケーション稼働部と、前記アプリケーション稼働部での前記アプリケーションの稼働を制御する制御部と、を備え、前記制御部は、自装置（当該受信機）で稼働するハイブリッドキャストアプリケーションからのＡＰＩを介した要求があった際に、指定された放送サービスを選局し、且つ指定されたハイブリッドキャストアプリケーションを起動する、ものである。
【0026】
［９］また、本発明の一態様による受信機は、放送信号によるコンテンツあるいは通信によるコンテンツを受信し、前記コンテンツを提示するコンテンツ提示機能部と、アプリケーションを稼働させる環境を含むアプリケーション稼働部と、前記アプリケーション稼働部での前記アプリケーションの稼働を制御する制御部と、を備え、前記制御部は、外部の連携端末装置からのＡＰＩを介した要求として、自装置（当該受信機）で稼働するハイブリッドキャストアプリケーションの状況を問い合わせる要求を受けた際に、稼働するハイブリッドキャストアプリケーションの状況を表す情報として、当該ハイブリッドキャストアプリケーションが、放送非依存マネージドアプリケーションであるか放送マネージドアプリケーションであるかを表す情報を、要求元の前記連携端末装置に返す、というものである。
【0027】
［１０］また、本発明の一態様による受信機は、放送信号によるコンテンツあるいは通信によるコンテンツを受信し、前記コンテンツを提示するコンテンツ提示機能部と、アプリケーションを稼働させる環境を含むアプリケーション稼働部と、前記アプリケーション稼働部での前記アプリケーションの稼働を制御する制御部と、を備え、前記制御部は、外部の連携端末装置からのＡＰＩを介した要求として、自装置（当該受信機）で稼働するハイブリッドキャストアプリケーションの状況を問い合わせる要求を受けた際に、稼働するハイブリッドキャストアプリケーションの状況を表す情報として、当該ハイブリッドキャストアプリケーションを識別するための情報を、要求元の前記連携端末装置に返す、というものである。
【0028】
［１１］また、本発明の一態様は、放送信号の受信機能を備えるコンピューターを、上記［１］から［１０］までのいずれかに記載の受信機、として機能させるためのプログラムである。
【発明の効果】
【0029】
本発明によれば、テレビ（受信機）で稼働するハイブリッドキャストアプリケーションの起動方法を多様化することができる。また、アプリケーション間での起動の制約を緩和する。
【図面の簡単な説明】
【0030】
【図1】本発明の実施形態による、テレビ（受信機）において稼働するアプリケーションプログラムを制御するためのシステムの概略機能構成を示すブロック図である。
【図2】同実施形態のシステムにおける、アプリケーションの稼働状態とその状態の遷移の概要を示す概略図である。
【図3】同実施形態による第１処理例の動作手順であって、第７ステップにおいて手法１を用い、且つ第９ステップにおいて手法１を用いる場合の、テレビ（受信機）上での動作手順を示す概略図である。
【図4】同実施形態による第１処理例の動作手順であって、第７ステップにおいて手法２を用い、且つ第９ステップにおいて手法２を用いる場合の、テレビ（受信機）上での動作手順を示す概略図である。
【図5】同実施形態によるテレビ（受信機）において、インテントを用いて放送非依存マネージドアプリケーションを起動するための関数群の例を示す概略図である。
【図7】同実施形態において連携端末装置側からテレビ（受信機）に対する連携動作を開始する場合の処理の流れを示す概略図（従来技術）である。
【図8】同実施形態によるテレビ（受信機）のＡＰＩの１つであるstartApplication()関数の形式の例を示す概略図である。
【図10】同実施形態による第２処理例におけるテレビ（受信機）の動作手順を示す概略図である。
【図11】同実施形態によるテレビ（受信機）側で稼働するハイブリッドキャストアプリケーションを識別する情報を問い合わせるためのリクエストの例を示す概略図である。
【図12】同実施形態によるテレビ（受信機）側のモードの情報を返すレスポンスの例を示す概略図である。
【図13】同実施形態によるテレビ（受信機）側で稼働するハイブリッドキャストアプリケーションを識別する情報を問い合わせるためのリクエストの例を示す概略図である。
【図14】同実施形態によるテレビ（受信機）がハイブリッドキャストアプリケーションを識別する情報を返すレスポンスの例を示す概略図である。
【図15】同実施形態による各装置を構成する要素であるコンピューターの内部構成の例を示すブロック図である。
【発明を実施するための形態】
【0031】
次に、本発明の実施形態について、図面を参照しながら説明する。本実施形態は、テレビ（受信機）におけるハイブリッドキャストアプリケーションプログラムの起動手段を拡張するシステムである。本システムにより、従来よりも柔軟な放送通信連携サービス（放送と通信の切り替え）を実現する。
【0032】
図１は、テレビ（受信機）において稼働するアプリケーションプログラム（単に「アプリケーション」あるいは「アプリ」とも呼ぶ）を制御するための、本実施形態のシステムの概略機能構成を示すブロック図である。図示するように、本実施形態によるシステム１は、テレビ（受信機）２と、連携端末装置５と、リモコン装置６と、ＡＩＴＵＲＩ可否判定サーバー装置７と、ローカルネットワーク８９１と、インターネット８９２と、中継装置８９３とを含んで構成される。システム１を構成する要素は、例えば、電子回路を用いて実現可能である。システム１を構成する要素は、情報を記憶する手段（例えば、半導体メモリーや磁気ディスク装置等）を含む。システム１を構成する要素のうち、特に、テレビ（受信機）２と、連携端末装置５と、ＡＩＴＵＲＩ可否判定サーバー装置７と、中継装置８９３とについては、それら各々の主要な機能を、コンピューターとプログラムとで実現可能である。
【0033】
システム１は、テレビ（受信機）２において稼働するアプリケーションを制御するためのものである。システム１は、主として、テレビ（受信機）２におけるハイブリッドキャストアプリケーションのライフサイクル（起動から終了まで）を柔軟に制御することを可能とするものである。システム１は、以下で説明するテレビ（受信機）２、連携端末装置５、リモコン装置６、ＡＩＴＵＲＩ可否判定サーバー装置７が、相互に情報をやりとりすることにより機能する。
【0034】
テレビ（受信機）２は、放送信号を受信して、放送信号から抽出した映像や音声やテキスト等を、ユーザーに対して提示する装置である。テレビ（受信機）２は、映像やテキストを表示するためのディスプレイ（例えば、液晶ディスプレイ等）や、音声を出力するためのスピーカー等を備える。また、テレビ（受信機）２は、通信ネットワークを介して他の装置との間で通信を行う機能を備える。テレビ（受信機）２は、この通信機能を用いて、コンテンツ配信サーバー装置等から送信される通信コンテンツ（映像や音声等）を受信し、その通信コンテンツをユーザーに対して提示する。テレビ（受信機）２は、また、外部の装置との間で、データ（制御情報を含む）のやりとりを行う。
【0035】
本実施形態のテレビ（受信機）２は、本実施形態に特有の、特徴的機能１から５までを持つ。特徴的機能１は、インテントでハイブリッドキャストアプリケーションを起動することができるようにした機能である。これにより、起動用アプリケーション２１３（後述、図４）が直接、ハイブリッドキャストの起動要求（mode=app）を行うことによって、放送マネージドアプリケーション（ＢＭＡ，Broadcast-oriented Managed Application）を起動することができる。特徴的機能２は、テレビ（受信機）２の内部からハイコネの機能を要求できるようにしたものである。なお、「ハイコネ」は、「ハイブリッドキャストコネクト」（Hybridcast Connect）の略である。ハイコネは、標準化された技術であり、テレビ（受信機）のメーカーに依存せずに、テレビ（受信機）２と連携端末装置５との連携動作を可能とする者である。特徴的機能３は、受信機ＡＰＩを介して、放送サービスの選局とハイブリッドキャストアプリケーションの起動との両方を行えるようにしたものである。特徴的機能４は、受信機ＡＰＩを介して、稼働中のハイブリッドキャストアプリケーションが放送非依存マネージドアプリケーション（ＢＩＡ，Broadcast-Independent managed Application）であるか放送マネージドアプリケーション（ＢＭＡ）であるか、を把握できるようにしたものである。特徴的機能５は、受信機ＡＰＩを介して、稼働中のハイブリッドキャストアプリケーションを識別することのできる情報（例えばＵＲＬ）を把握できるようにしたものである。これら、テレビ（受信機）２の特徴的機能１から５までのそれぞれの詳細、およびその前提条件については、後述する。
【0036】
連携端末装置５は、テレビ（受信機）２と同一のネットワーク内で通信をすることのできる端末装置である。連携端末装置５とテレビ（受信機）２との間では、ネットワークを介した双方向の通信を行うことができる。連携端末装置５は、例えば、スマートフォン（スマホ）、タブレット型端末、ウェアラブル端末等の装置およびプログラムを用いて実現される。連携端末装置５は、標準化された技術であるハイブリッドキャストの端末連携機能（「ハイコネ」と呼ばれる）によって、テレビ（受信機）２を操作するために用いられることがある。連携端末装置５からの通信によって、テレビ（受信機）２における選局の操作や、テレビ（受信機）２の外部からテレビ（受信機）２内で稼働するハイブリッドキャストアプリの起動の操作を行うことが可能である。
【0037】
リモコン装置６は、テレビ（受信機）２の動作を制御するためのリモコン信号を送信する装置である。リモコン装置６は、複数の押し釦を備えており、ユーザーがそれらの押し釦を操作することにより、リモコン信号を発信する。リモコン信号としては、赤外線信号、超音波信号、光信号、無線（電波）信号等を用いることができる。
【0038】
ＡＩＴＵＲＩ可否判定サーバー装置７は、外部からの問い合わせに応じて、該当のチャンネルにおける、特定のアプリケーションの起動可否を判定し、その判定結果を問い合わせ元に対して応答する。ＡＩＴＵＲＩ可否判定サーバー装置７は、テレビ（受信機）２などからの問い合わせに応答する。なお、ＡＩＴＵＲＩ可否判定サーバー装置７は、指定されるＵＲＩによって参照されるＡＩＴに基づいて判断対象のアプリケーションを特定する。なお、ＡＩＴは、アプリケーション情報テーブル（Application Information Table）を表す。また、ＵＲＩは、ユニフォームリソース識別子（Uniform Resource Identifier）である。ＡＩＴＵＲＩ可否判定サーバー装置７は、インターネット８９２等の通信回線を介して、テレビ（受信機）２との間で通信を行う。ＡＩＴＵＲＩ可否判定サーバー装置７を利用することにより、例えば、問い合わせ元のテレビ（受信機）２は、放送サービスの受信状況に基づいてアプリケーションの起動可否を判断することができる。なお、ＡＩＴＵＲＩ可否判定サーバー装置７が持つ機能自体は、従来技術に属するものである。
【0039】
ローカルネットワーク８９１は、例えば宅内あるいは事業所内に設けられるネットワークであり、無線通信によるアクセスも可能となっている。テレビ（受信機）２と連携端末装置５との間の通信を、ローカルネットワーク８９１を行うことができる。また、テレビ（受信機）２や連携端末装置５等が、ローカルネットワーク８９１を経由してインターネット８９２にアクセスすることができる。
【0040】
インターネット８９２は、テレビ（受信機）２や連携端末装置５等が外部の装置（ＡＩＴＵＲＩ可否判定サーバー装置７を含む）と通信を行うことを可能とするネットワークである。
【0041】
中継装置８９３は、ローカルネットワーク８９１とインターネット８９２とを仲介する装置である。例えばテレビ（受信機）２や連携端末装置５は、中継装置８９３を介して、インターネット８９２にアクセスすることができる。
【0042】
図１に示す通り、テレビ（受信機）２は、プログラム駆動部２１と、制御部２４と、その他機能部２５と、を含む。プログラム駆動部２１やその他機能部２５自体は、既存技術を用いて構成可能である。
【0043】
テレビ（受信機）２は、例えば赤外線やブルートゥース（登録商標、Bluetooth）などの信号伝達手段を用いるリモコン装置６などによって、あるいは前述の連携端末装置５によって、操作することが可能となるように構成される。
【0044】
プログラム駆動部２１は、アプリケーションが稼働する環境を有する。プログラム駆動部２１は、「アプリケーション稼働部」と呼ばれる場合もある。プログラム駆動部２１は、プロセッサー資源やメモリー等を使用してアプリケーションを稼働させる。プログラム駆動部２１で稼働するアプリケーションは、例えば、ＨＴＭＬ（ハイパーテキストマークアップ言語）で記述されたコードによって、画面構成を決定したり、手続的な処理を行ったりするものであってよい。この場合、プログラム駆動部２１は、ＨＴＭＬブラウザーの機能を持つ。ＨＴＭＬブラウザーは、スクリプト言語を解釈しながら実行する機能を含む。アプリケーションは、例えば、JavaScript等で記述された実行可能コードを含んだＨＴＭＬファイルとして、テレビ（受信機）２内の記憶手段に記憶され得る。
【0045】
制御部２４は、テレビ（受信機）２において稼働するアプリケーションに関連する制御を行う。制御部２４が持つ機能は、テレビ（受信機）２が持つ前述の特徴的機能１から５までを実現させる機能を含む。つまり、制御部２４は、前述の特徴的機能１によってハイブリッドキャストアプリケーションを起動したり、テレビ（受信機）２内部からのハイコネ機能の要求に応じた処理をしたり（特徴的機能２）、特徴的機能３、４、および５のそれぞれのＡＰＩによって呼び出される機能を実行したりする。つまり、制御部２４は、プログラム駆動部２１でのアプリケーションの稼働を制御する機能を含む。
【0046】
制御部２４は、一態様（特徴的機能１）として、テレビ（受信機）搭載オペレーティングシステム用アプリケーションから、ハイブリッドキャストアプリケーションを起動するものであってよい。具体的には、制御部２４は、プログラム駆動部２１で稼働する一つのアプリケーションからの要求に基づき、インテントで、他のアプリケーションを起動するものであってよい。具体的には、制御部２４は、例えば、起動用アプリケーション（後述）からの要求に基づいて、上記の他のアプリケーションを起動する。また、ここで、制御部２４は、放送マネージドアプリケーションとして前記他のアプリケーションを起動するよう要求を受けた場合には、受信機の利用可能メディア情報および利用可能チャンネル情報の取得を行い、取得した利用可能メディア情報および利用可能チャンネル情報が前記他のアプリケーションと整合する場合にのみ、前記他のアプリケーションを起動するものであってよい。
【0047】
制御部２４は、一態様（特徴的機能２）として、所定のアプリケーションを起動させる要求を受けたとき、自装置（当該受信機）の内部からハイコネ機能を呼び出すことによって所定のアプリケーションの起動を行うとともに、当該ハイコネ機能を呼び出す手順のうちの、
（Ａ）ＤＩＡＬ（Discovery-and-Launch）プロトコルを用いて受信機を発見する機能に代えて、（Ａ１）自装置（当該受信機）のローカルホストのアドレスを対象として接続処理を行う、または、（Ａ２）受信機の発見を行わない、こととする、
または、
（Ｂ）前記ハイコネ機能によるアプリケーションの起動の際の、要求元と要求先との間の認証の手続を行わない、こととする、
の少なくともいずれか一方とするものであってよい。
（Ａ）ＤＩＡＬ（Discovery-and-Launch）プロトコルを用いて受信機を発見する機能に代えて、（Ａ１）自装置（当該受信機）のローカルホストのアドレスを対象として接続処理を行う、または、（Ａ２）受信機の発見を行わない、こととする、
または、
（Ｂ）前記ハイコネ機能によるアプリケーションの起動の際の、要求元と要求先との間の認証の手続を行わない、こととする、
の少なくともいずれか一方とするものであってよい。
【0048】
制御部２４は、一態様（特徴的機能３）として、自装置（テレビ（受信機）２）で稼働するハイブリッドキャストアプリケーションからのＡＰＩを介した要求があった際に、その要求において指定された放送サービスを選局し、且つその要求において指定されたハイブリッドキャストアプリケーションを起動するものであってよい。
【0049】
制御部２４は、一態様（特徴的機能４）として、外部の連携端末装置５からのＡＰＩを介した要求として、自装置（テレビ（受信機）２）で稼働するハイブリッドキャストアプリケーションの状況を問い合わせる要求を受けた際に、稼働するハイブリッドキャストアプリケーションの状況を表す情報として、当該ハイブリッドキャストアプリケーションが、放送非依存マネージドアプリケーションであるか放送マネージドアプリケーションであるかを表す情報を、要求元の連携端末装置５に返すものであってよい。
【0050】
制御部２４は、一態様（特徴的機能５）として、外部の連携端末装置５からのＡＰＩを介した要求として、自装置（テレビ（受信機）２）で稼働するハイブリッドキャストアプリケーションの状況を問い合わせる要求を受けた際に、稼働するハイブリッドキャストアプリケーションの状況を表す情報として、当該ハイブリッドキャストアプリケーションを識別するための情報を、要求元の前記連携端末装置に返すものであってよい。ここで、前記ハイブリッドキャストアプリケーションを識別するための情報は、当該ハイブリッドキャストアプリケーションに関連するＵＲＬ（ユニフォームリソースロケーター）であってよい。
【0051】
上記の特徴的機能１から５までのそれぞれの詳細については、後述する。
【0052】
その他機能部２５は、いわゆるテレビ受像機における、プログラム駆動部２１と制御部２４とが持つ機能以外の機能を持つ。その他機能部２５が持つ機能は、放送信号を受信したり、放送信号を復調したり、復調された放送信号からデータ（映像、音声、テキスト、制御用データ等）を抽出したり、インターネットプロトコルを用いて外部と通信したり、リモコン信号を受信してテレビ（受信機）２の全体の動作を制御したり、テレビ（受信機）２の動作のために必要なデータ（制御情報等を含む）を記憶したり、その他の処理をしたりする機能を含むものである。
【0053】
その他機能部２５が持つ機能のうち、放送信号によるコンテンツあるいは通信によるコンテンツを受信し、それらのコンテンツ（映像や音声やテキスト等）を提示する機能を、特に、コンテンツ提示機能部と呼んでもよい。
【0054】
プログラム駆動部２１は、テレビ搭載ＯＳ向けアプリケーション領域２３と、ハイブリッドキャスト領域２２とを含む。テレビ搭載ＯＳは、Android（登録商標）やLinux（登録商標）などをベースとして構成されるテレビ（受信機）２用のＯＳである。ＯＳは、「オペレーティングシステム」の略であり、機器を制御する基本ソフトウェアである。テレビ搭載ＯＳは、様々なアプリケーションを呼び出すためのホーム画面を表示する機能を持っている。テレビ搭載ＯＳにおいて、起動用アプリケーション２１３が、上記のホーム画面を表示する。ユーザーは、リモコン装置６等を用いて、ホーム画面から、他のアプリケーションを選択して起動させる操作を行うことができる。ハイブリッドキャストの領域は、さらに、放送マネージドアプリケーション（ＢＭＡ）と放送非依存マネージドアプリケーション（ＢＩＡ）に大別される。放送マネージドアプリケーションは、放送受信状態において稼働するアプリケーションである。放送非依存マネージドアプリケーションは、放送非受信状態（放送を受信していない状態）において稼働するアプリケーションである。なお、「ハイブリッドキャストアプリケーション」（「ＨＣアプリ」等とも呼ばれる）は、上記の放送マネージドアプリケーションと放送非依存マネージドアプリケーションとの両方を含む概念である。
【0055】
つまり、ハイブリッドキャスト領域２２では、放送非依存マネージドアプリケーション（ＢＩＡ）２１１や放送マネージドアプリケーション（ＢＭＡ）２１２が稼働する。また、テレビ搭載ＯＳ向けアプリケーション領域２３では、起動用アプリケーション２１３等が稼働する。
【0056】
図２は、主として本実施形態によるテレビ（受信機）２における、アプリケーションの稼働状態とその状態の遷移の概要を示す概略図である。以下、この図を参照しながら説明する。
【0057】
図２において、ＳＴ１は、連携端末装置５において、ハイコネアプリケーションが稼働している状態である。ハイコネアプリケーションは所定の手順を実行することにより、テレビ（受信機）２との間での連携動作を行う。ハイコネアプリケーション（ＳＴ１）からは、遷移Ｔ１により、ＳＴ３の放送非依存マネージドアプリケーション（ＢＩＡ）を起動することができる。ＳＴ３は、この放送非依存マネージドアプリケーション（ＢＩＡ）が、アプリケーションの起動のための選択画面を表示している状態である。ＳＴ２は、テレビ用ＯＳ上でホーム画面が表示されている状態である。即ち、このホーム画面は、サービス起動メニューを表示している。ＳＴ２の画面において、テレビ（受信機）２は、リモコン装置６からのリモコン信号による操作が可能である。本実施形態では、ＳＴ２の画面から、遷移Ｔ２により、ＳＴ３の放送非依存マネージドアプリケーション（ＢＩＡ）を起動することができる。
【0058】
上記の遷移Ｔ１は、既存技術であるハイコネにより実現可能である。言い換えれば、遷移Ｔ１は、ハイコネからのアプリケーション外部起動（外部の連携端末装置５からの起動）である。上記の遷移Ｔ２は、本実施形態に特有のテレビ（受信機）２の動作である。言い換えれば、遷移Ｔ２は、リモコンからのアプリケーション内部起動（テレビ（受信機）２の内部で完結している起動）である。
【0059】
上記ＳＴ３の放送非依存マネージドアプリケーション（ＢＩＡ）のアプリケーションの起動のための選択画面からは、遷移Ｔ３（状態ＳＴ４への遷移）、遷移Ｔ５（状態ＳＴ５への遷移）、遷移Ｔ７（状態ＳＴ６への遷移）のそれぞれが可能である。具体的には、ＳＴ３の状態からは、放送サービスを選局することにより、状態ＳＴ４に遷移する（遷移Ｔ３）。また、ＳＴ３の状態からは、放送マネージドアプリケーション（ＢＭＡ）を起動することにより、状態ＳＴ５に遷移する（遷移Ｔ５）。また、ＳＴ３の状態からは、別の放送非依存マネージドアプリケーション（ＢＩＡ）を起動することにより、状態ＳＴ６に遷移する（遷移Ｔ７）。
【0060】
図２におけるＳＴ４は、テレビ（受信機）２が、放送番組を受信し、提示している状態である。つまり、ユーザーは、放送番組を視聴することができる状態である。この状態ＳＴ４から状態ＳＴ５に遷移可能である（遷移Ｔ４）。遷移Ｔ４は、データ放送から放送マネージドアプリケーション（ＢＭＡ）を起動することにより起こり得る。
【0061】
図２におけるＳＴ５は、放送マネージドアプリケーション（ＢＭＡ）が稼働している状態である。この状態では、ユーザーは、放送マネージドアプリケーション（ＢＭＡ）が出力するコンテンツを視聴したりすることができる。また、この状態では、テレビ（受信機）２が、特定の放送サービスを受信している状態である。この状態ＳＴ５から状態ＳＴ３に遷移可能である（遷移Ｔ６）。遷移Ｔ６は、放送非依存マネージドアプリケーション（ＢＩＡ）を起動することにより起こり得る。この状態ＳＴ５から状態ＳＴ６に遷移可能である（遷移Ｔ９）。遷移Ｔ９も、放送非依存マネージドアプリケーション（ＢＩＡ）を起動することにより起こり得る。
【0062】
図２におけるＳＴ６は、放送非依存マネージドアプリケーション（ＢＩＡ）が稼働している状態である。この状態では、例えば、ユーザーは、放送非依存マネージドアプリケーション（ＢＩＡ）が提示するコンテンツを視聴することができる。この状態ＳＴ６から状態ＳＴ３に遷移可能である（遷移Ｔ８）。遷移Ｔ８は、選択画面を表示する放送非依存マネージドアプリケーション（ＢＩＡ）を起動することにより起こり得る。この状態ＳＴ６から状態ＳＴ５に遷移可能である（遷移Ｔ１０）。遷移Ｔ６は、放送マネージドアプリケーション（ＢＭＡ）を起動することにより起こり得る。
【0063】
以上、図２を参照しながら、テレビ（受信機）２におけるアプリケーションの遷移（起動）の経路について説明した。
【0064】
本実施形態のテレビ（受信機）２の特徴は、第１に、放送非依存マネージドアプリケーション（ＢＩＡ）からの放送マネージドアプリケーション（ＢＭＡ）の起動を可能としている点である（図２における遷移Ｔ５，Ｔ１０）。また、その特徴は、第２に、リモコン装置等の操作により、テレビ（受信機）２の内部でのアプリケーションの起動（内部起動）を可能としている点である（図２における遷移Ｔ２）。これらの特徴を実現するための技術構成については、以下の第１処理例および第２処理例と関連付けながら説明する。
【0065】
［第１処理例］
本実施形態では、連携端末装置５を用いることなくテレビ（受信機）２単体で、ハイブリッドキャストの起動を行うことが可能である。つまり、テレビ（受信機）２内のテレビ搭載ＯＳ下の起動用アプリケーション２１３（アプリホーム画面）から、ハイブリッドキャストアプリケーションが起動される。
本実施形態では、連携端末装置５を用いることなくテレビ（受信機）２単体で、ハイブリッドキャストの起動を行うことが可能である。つまり、テレビ（受信機）２内のテレビ搭載ＯＳ下の起動用アプリケーション２１３（アプリホーム画面）から、ハイブリッドキャストアプリケーションが起動される。
【0066】
第１処理例が想定するシナリオは、次の通りである。ユーザーは、リモコン装置６を操作することにより、テレビ（受信機）２のアプリホーム画面から、放送非依存マネージドアプリケーション（ＢＩＡ）を起動する。起動される放送非依存マネージドアプリケーション（ＢＩＡ）は、インターネットを介して配信されるＶＯＤ（ビデオ・オン・デマンド）のコンテンツを視聴するためのアプリケーションである。ユーザーは、放送非依存マネージドアプリケーション（ＢＩＡ）を用いてＶＯＤのコンテンツを視聴した後、放送コンテンツを視聴し、さらにその後に放送非依存マネージドアプリケーション（ＢＩＡ）に戻る。
【0067】
上記のシナリオを実現するためのテレビ（受信機）２の動作手順は、次の通りである。
【0068】
第１ステップ： ユーザーは、リモコン装置６等を用いて、テレビ（受信機）２のアプリホーム画面を表示させる。そのための手法として、手法１と手法２のいずれかを用いることができる。手法１では、ユーザーがリモコン装置６を操作することにより、テレビ（受信機）２にアプリホーム画面を表示させる。リモコン装置６は、そのための制御信号を例えば赤外線信号としてテレビ（受信機）２に対して送信する。手法２では、ユーザーが連携端末装置５（例えば、スマートフォン）を操作することにより、ローカルネットワーク８９１経由で、テレビ（受信機）２にアプリホーム画面を表示させる。この場合、連携端末装置５は、ローカルネットワーク８９１を用いた通信により、制御信号をテレビ（受信機）２に対して送信する。
【0069】
第２ステップ： ユーザーは、上記のアプリホーム画面に表示されているアプリ一覧の中から、特定のアプリケーションを選択して実行させる。ここでユーザーが選択するアプリケーションは、放送非依存マネージドアプリケーション（ＢＩＡ）を起動するための起動用アプリケーションである。本ステップにおいても、第１ステップと同様に、手法１（リモコン装置６による制御）あるいは手法２（連携端末装置５からの通信による制御）のいずれかを用いることができる。各手法の詳細は、第１ステップにおけるそれらと同様である。
【0070】
第３ステップ： 第２ステップにおいて選択された起動用アプリは、ハイブリッドキャストの放送非依存マネージドアプリケーション（ＢＩＡ）の起動を要求する。ここで、放送非依存マネージドアプリケーション（ＢＩＡ）を起動するための手法として、手法１および手法２のいずれかを用いることができる。
【0071】
第３ステップにおける手法１では、テレビ（受信機）２上でのインテントで、放送非依存マネージドアプリケーション（ＢＩＡ）を起動する。既存技術においては、テレビ（受信機）上でのインテントは規定されていない。そこで、手法１を用いることができるように、本実施形態のテレビ（受信機）２は、特徴的機能１を持つ。
【0072】
第３ステップにおける手法２では、ハイコネのハイブリッドキャストアプリケーション起動要求（mode=bia）を、テレビ（受信機）２内で実行可能とする。ハイコネでのハイブリッドキャストアプリケーションの起動要求については、非特許文献３（IPTVFJ STD-0013，2.9版）の第7.2.3.2.3.3.1節に記載されている。ハイブリッドキャストアプリケーションの起動要求におけるmode=biaは、放送非依存マネージドアプリケーション（ＢＩＡ）の起動要求であることを意味する。従来技術ではテレビ（受信機）２内に閉じてハイコネのハイブリッドキャストアプリケーション起動要求を実行することはできなかった。本実施形態のようにテレビ（受信機）２内に閉じてハイコネのハイブリッドキャストアプリケーション起動要求を実行できるようにすることにより、プロセスを簡易化することができる。この手法２を用いることができるように、本実施形態のテレビ（受信機）２は、特徴的機能２を持つ。
【0073】
第４ステップ： 第３ステップにおける放送非依存マネージドアプリケーション（ＢＩＡ）の起動要求に基づいて、テレビ（受信機）２は、インターネットを介して、ＡＩＴＵＲＩ可否判定サーバー装置７に対して、起動可否を問い合わせるためのリクエストを行う。このＡＩＴＵＲＩ可否判定サーバー装置７は、従来と同様の技術により、起動可否のリクエストを受け取り、可否判定を行い、テレビ（受信機）２に対してレスポンスを返す。
【0074】
第５ステップ： 上記のＡＩＴＵＲＩ可否判定サーバー装置７からの応答が肯定的な応答（例えば、応答の値が２００）である場合、テレビ（受信機）２は、放送非依存マネージドアプリケーション（ＢＩＡ）を起動する。なお、ＡＩＴＵＲＩ可否判定サーバー装置７からのレスポンスに応じてアプリケーションを起動するか否かを決定する処理自体は、従来技術と同様である。
【0075】
第６ステップ： 第５ステップにおいて起動された放送非依存マネージドアプリケーション（ＢＩＡ）が動作する。この放送非依存マネージドアプリケーション（ＢＩＡ）は、ビデオオンデマンド（ＶＯＤ）などの通信コンテンツを受信し、提示する機能を持つ。これにより、ユーザーは任意に選択する通信コンテンツを視聴することができる。
【0076】
第７ステップ： 稼働中の放送非依存マネージドアプリケーション（ＢＩＡ）が、下の手法１から手法４までのいずれかを実行することにより、放送マネージドアプリケーション（ＢＭＡ）を起動する。
【0077】
第７ステップの手法１の場合には、受信機ＡＰＩのtuneTo()関数とデータ放送とで、放送マネージドアプリケーション（ＢＭＡ）を起動する。つまり、まず、放送非依存マネージドアプリケーション（ＢＩＡ）が、tuneTo()関数を実行する。tuneTo()関数は、テレビ（受信機）２に選局させるためのＡＰＩである。そして、選局されたデータ放送のＢＭＬでのオートスタートにより、放送マネージドアプリケーション（ＢＭＡ）を起動する。これにより、自動的にハイブリッドキャストアプリを起動することが可能である。この手法１は、既存技術のみを用いて実現可能であるが、放送局を横断してこの手法１を適用することは困難である。
【0078】
第７ステップの手法２の場合には、放送非依存マネージドアプリケーション（ＢＩＡ）は、次の手順を実行する。まず、放送非依存マネージドアプリケーション（ＢＩＡ）は、受信機ＡＰＩのgetAvailableMedia()関数を実行することにより、テレビ（受信機）２の利用可能メディアの情報を取得する。次に、放送非依存マネージドアプリケーション（ＢＩＡ）は、受信機ＡＰＩのgetChannelInformation()関数を実行することにより、テレビ（受信機）２の利用可能チャンネルの情報を取得する。次に、放送非依存マネージドアプリケーション（ＢＩＡ）は、ハイブリッドキャストの起動要求（mode=app）を行う。このmode=appは、非特許文献３（IPTVFJ STD-0013，2.9版）の第7.2.3.2.3.3.1節に記載されているものであり、放送の選局と、放送マネージドアプリケーション（ＢＭＡ）の起動とを要求することを表す。
【0079】
なお、テレビ（受信機）２の内部からハイブリッドキャストアプリケーションを起動する方法は、従来技術では規定されていない。テレビ（受信機）２で稼働する放送非依存マネージドアプリケーション（ＢＩＡ）からの認証方法がないためである。つまり、従来技術では、放送非依存マネージドアプリケーション（ＢＩＡ）からハイブリッドキャストアプリケーションを起動することはできない。つまり、第７ステップでの手法２を実現するためには、テレビ（受信機）２の内部からハイコネの連携を行えるようにするために、連携する機器同士のペアリングの手続を行わずに済むようにする。このため、テレビ（受信機）２は、後述する特徴的機能２を持つ。次に、テレビ（受信機）２は、ＡＩＴＵＲＩ可否判定サーバー装置７に対して、起動可否を問い合わせる。ＡＩＴＵＲＩ可否判定サーバー装置７は、可否判定を行い、テレビ（受信機）２に対してレスポンスを返す。このレスポンスが「起動可」を表す場合には、テレビ（受信機）２は、放送マネージドアプリケーション（ＢＭＡ）を起動する。
【0080】
第７ステップの手法３の場合には、受信機ＡＰＩとして、指定した放送サービスの選局とハイブリッドキャストアプリの起動を行うためのＡＰＩを準備する。放送非依存マネージドアプリケーション（ＢＩＡ）は、このＡＰＩを呼び出す。この手法３を実施するためには、テレビ（受信機）２は、特徴的機能３を持つ。
【0081】
第７ステップの手法４の場合には、起動用アプリケーション（ＢＩＡ）からの起動の制御を行う。つまり、テレビ搭載ＯＳのアプリケーションが、バックグラウンドで処理を行う。そのため、放送非依存マネージドアプリケーション（ＢＩＡ）は、放送サービスを選局する。その具体的な方法の第１は、テレビ（受信機）２のＡＰＩが持つTuneTo()関数を実行することによって放送サービスの選局を行う方法である。その第２の方法は、リモコンでの選局である。
【0082】
（Ｂ）次に、テレビ（受信機）２で稼働している起動用アプリケーションが、テレビ（受信機）２の選局状態を取得する。その具体的な方法の第１は、ハイコネの機能であるgetContentSource()による受信機状態の取得である。非特許文献３（IPTVFJ STD-0013，2.9版）の第7.2.3.2.3.4.2節には、受信機状態の取得のためのインターフェース（<BaseURL>/status）について記載されている。その方法の第２は、テレビ（受信機）２が、自装置の選局結果の情報を含むイベントを、テレビ搭載ＯＳ上で稼働する起動用アプリケーションに報告する。
【0083】
（Ｃ）上記のいずれの方法でテレビ（受信機）２の選局状態を取得した場合も、起動用アプリケーションは、テレビ（受信機）２の選局状態が変わった段階（目的の放送サービスを受信している状態になった段階）で、ハイブリッドキャスト起動要求のmode=appを実行する。
【0084】
第８ステップ： 第７ステップにおいて起動された放送マネージドアプリケーション（ＢＭＡ）が動作する。これにより、ユーザーは放送局マネージドなコンテンツを視聴することができる。放送局マネージドなコンテンツは、テレビ（受信機）２がリアルタイムに受信する放送信号による放送番組や、放送マネージドのハイブリッドキャストアプリのコンテンツである。
【0085】
第９ステップ： 稼働中の放送マネージドアプリケーション（ＢＭＡ）から、放送非依存マネージドアプリケーション（ＢＩＡ）を起動する。その手法は、下記の手法１または２のいずれかである。
【0086】
第９ステップの手法１の場合には、放送マネージドアプリケーション（ＢＭＡ）は、受信機ＡＰＩのreplaceApplication()関数を実行することによって、アプリケーションを切り替える。
【0087】
第９ステップの手法２の場合には、放送マネージドアプリケーション（ＢＭＡ）から、ハイコネ（mode=bia）による放送非依存マネージドアプリケーション（ＢＩＡ）の起動要求を行う。具体的には、テレビ（受信機）２は、次の手順で放送非依存マネージドアプリケーション（ＢＩＡ）を起動する。まず、放送マネージドアプリケーション（ＢＭＡ）が、mode=biaでのアプリケーションの起動要求を行う。次に、テレビ（受信機）２は、ＡＩＴＵＲＩ可否判定サーバー装置７への問い合わせを行うことにより、アプリケーションの起動可否の確認を行う。この確認の結果として、「起動可」である場合のみ、テレビ（受信機）２は、放送非依存マネージドアプリケーション（ＢＩＡ）を起動する。
【0088】
【0089】
図３は、上記の第１処理例の動作手順であって、第７ステップにおいて手法１を用い、且つ第９ステップにおいて手法１を用いる場合の、テレビ（受信機）２上での動作手順を示す概略図である。同図におけるプログラム駆動部２１は、図１で説明した通り、テレビ（受信機）２内の機能である（後の図においても同様）。また、図３に示すように、プログラム駆動部２１は、データ放送２１６およびアプリ起動可否判定機能２１７の各機能を含む。アプリ起動可否判定機能２１７は、ＡＩＴＵＲＩ可否判定サーバー装置７に対して問い合わせを行うことによって、そのレスポンスに基づき、特定のアプリケーションの起動可否を判定するものである。図３において示す丸数字は、動作手順におけるステップの番号に対応する。
【0090】
図３に示すように、第１ステップにおいて、リモコン装置６からの信号、または連携端末装置５からのハイコネ経由での信号に基づいて、テレビ（受信機）２は、起動用アプリケーション２１３を起動させる。起動用アプリケーション２１３が稼働することにより、テレビ（受信機）２におけるアプリケーション起動用のホーム画面が表示される。第２ステップにおいて、第１ステップと同様にリモコン装置６または連携端末装置５からの信号に基づいて、特定のアプリケーションが選択される。ここで選択されるアプリケーションは、ユーザーが起動させようとするアプリケーションである。
【0091】
図３の第３ステップにおいて、起動用アプリケーション２１３は、アプリ起動可否判定機能２１７に対して、選択されたアプリケーションの起動可否の判定を依頼する。第４ステップにおいて、アプリ起動可否判定機能２１７は、ＡＩＴＵＲＩ可否判定サーバー装置７に対して、起動可否判定のリクエストを送信する。また、ＡＩＴＵＲＩ可否判定サーバー装置７は、その判定結果を示すレスポンスを、アプリ起動可否判定機能２１７に対して送信する。その結果が「起動可」であった場合には、第５ステップにおいて、アプリ起動可否判定機能２１７は、そのアプリケーションを起動する。なお、ここで起動されるアプリケーションは、ハイブリッドキャストの放送非依存マネージドアプリケーション（ＢＩＡ）である。
【0092】
図３の第６ステップにおいて、放送非依存マネージドアプリケーション（ＢＩＡ）２１１が稼働する。放送非依存マネージドアプリケーション（ＢＩＡ）２１１は、通信コンテンツを受信し、ユーザーに対して提示する。ユーザーは、この通信コンテンツを視聴することができる。
【0093】
図３の第７ステップにおいて、本例では、前述の手法１の手順を実行する。つまり、放送非依存マネージドアプリケーション（ＢＩＡ）２１１は、受信機ＡＰＩのtuneTo()関数を実行することによりデータ放送への選局を行う。そして、そのデータ放送のオートスタート（自動起動）機能により、ハイブリッドキャストの放送マネージドアプリケーション（ＢＭＡ）２１２を起動する。
【0094】
図３の第８ステップにおいて、放送マネージドアプリケーション（ＢＭＡ）２１２が稼働する。放送マネージドアプリケーション（ＢＭＡ）２１２は、放送マネージドなコンテンツをユーザーに対して提示する。ユーザーは、このコンテンツを視聴することができる。
【0095】
図３の第９ステップにおいて、本例では、前述の手法１の手順を実行する。つまり、放送マネージドアプリケーション（ＢＭＡ）２１２が、受信機ＡＰＩのreplaceApplication()関数を実行することによって、アプリケーションを切り替える。これにより、ハイブリッドキャストの放送非依存マネージドアプリケーション（ＢＩＡ）２１１が稼働するようになる。
【0096】
図４は、上記の第１処理例の動作手順であって、第７ステップにおいて手法２を用い、且つ第９ステップにおいて手法２を用いる場合の、テレビ（受信機）２上での動作手順を示す概略図である。図４に示すように、本例では、ハイブリッドキャスト領域２２において、アプリ起動可否判定機能２１８が稼働する。アプリ起動可否判定機能２１８は、アプリ起動可否判定機能２１７と同様に、ＡＩＴＵＲＩ可否判定サーバー装置７に対して問い合わせを行うことによって、そのレスポンスに基づき、特定のアプリケーションの起動可否を判定するものである。図４において示す丸数字は、前述の動作手順におけるステップの番号に対応する。
【0097】
図４の第１ステップから第６ステップまでの動作は、上で説明した図３の第１ステップから第６ステップまでの動作と同様である。即ち、リモコン装置６あるいは連携端末装置５からの信号に基づき、テレビ（受信機）２は、起動用アプリケーション２１３を稼働させ、そこで選択されたアプリケーションの起動を試みる。ＡＩＴＵＲＩ可否判定サーバー装置７から受け取る可否判定結果が「起動可」を示す場合には、テレビ（受信機）２は、ハイブリッドキャストの放送非依存マネージドアプリケーション（ＢＩＡ）２１１を起動させる。放送非依存マネージドアプリケーション（ＢＩＡ）２１１は、例えば、放送コンテンツをユーザーに対して提示することができる。
【0098】
図４の第７ステップにおいて、本例では、前述の手法２の手順を実行する。つまり、放送非依存マネージドアプリケーション（ＢＩＡ）２１１は、受信機ＡＰＩのgetAvailableMedia()関数およびgetChannelInformation()関数を実行することにより、それぞれ、利用可能メディアの情報および利用可能チャンネルの情報を取得する。そして、放送非依存マネージドアプリケーション（ＢＩＡ）２１１は、ハイブリッドキャストの起動要求（mode=app）を行う。テレビ（受信機）２が持つアプリ起動可否判定機能２１７は、前述の通り、ＡＩＴＵＲＩ可否判定サーバー装置７に対して起動可否を問い合わせ、そのレスポンスをＡＩＴＵＲＩ可否判定サーバー装置７から受信する。このレスポンスが「起動可」を表す場合には、テレビ（受信機）２は、放送マネージドアプリケーション（ＢＭＡ）２１２を起動する。
【0099】
図４の第８ステップにおいて、放送マネージドアプリケーション（ＢＭＡ）２１２が稼働する。放送マネージドアプリケーション（ＢＭＡ）２１２は、放送によってマネージされたコンテンツをユーザーに対して提示する。
【0100】
図４の第９ステップにおいて、本例では、前述の手法２の手順を実行する。つまり、第９ステップにおいて、放送マネージドアプリケーション（ＢＭＡ）２１２は、ハイコネ（mode=bia）を用いて、放送非依存マネージドアプリケーション（ＢＩＡ）の起動要求を行う。これを受けて、アプリ起動可否判定機能２１７は、ＡＩＴＵＲＩ可否判定サーバー装置７に対して起動可否を問い合わせ、そのレスポンスをＡＩＴＵＲＩ可否判定サーバー装置７から受信する。このレスポンスが「起動可」を表す場合には、テレビ（受信機）２は、ハイブリッドキャストの放送非依存マネージドアプリケーション（ＢＩＡ）２１１を起動する。その結果、放送非依存マネージドアプリケーション（ＢＩＡ）２１１が稼働状態となる。
【0101】
［第１変形例，特徴的機能１の利用］
変形例として、起動用アプリケーション２１３（図４参照）が直接、ハイブリッドキャストの起動要求（mode=app）を行うことによって、放送マネージドアプリケーション（ＢＭＡ）２１２を起動するようにしてもよい。
変形例として、起動用アプリケーション２１３（図４参照）が直接、ハイブリッドキャストの起動要求（mode=app）を行うことによって、放送マネージドアプリケーション（ＢＭＡ）２１２を起動するようにしてもよい。
【0102】
放送非依存マネージドアプリケーション（ＢＩＡ）２１１を経由して放送マネージドアプリケーション（ＢＭＡ）２１２を起動する場合には、図４の第７ステップで説明したように受信機ＡＰＩのgetAvailableMedia()関数およびgetChannelInformation()関数を呼び出して利用可能メディアおよび利用可能チャンネルの情報を取得できる。しかしながら、起動用アプリケーション２１３から直接、放送マネージドアプリケーション（ＢＭＡ）２１２を起動しようとする場合には、テレビ（受信機）２が該当するチャンネルを受信できるかどうかがわからないという問題がある。そこで、起動用アプリケーション２１３から直接の起動を行うためには、端末連携機能によって、利用可能メディアおよび利用可能チャンネルの情報を取得するようにする。
【0103】
そこで、第１処理例の第３ステップの手法１において説明したように、テレビ（受信機）２上におけるインテントで、放送非依存マネージドアプリケーション（ＢＩＡ）を起動する。インテントは、特定のアクティビティが他のアクティビティやアプリケーションなどと情報のやり取りを行うための仕組みである。インテントを用いることによって、例えば端末装置（スマートフォン等）上で、特定のアプリケーション（例えば、ツイッターアプリ）から他のアプリケーション（例えば、ＬＩＮＥアプリ）を起動することなどもできる。同様に、本実施形態では、テレビ（受信機）２上のアプリケーション（例えば、図３における起動用アプリケーション２１３）などから、インテントによって放送非依存マネージドアプリケーション（ＢＩＡ）２１１を起動することができる。
【0104】
図５は、インテントを用いて放送非依存マネージドアプリケーション（ＢＩＡ）を起動するための関数の例を示す概略図である。図示するように、インテント（intent）クラスに属する関数は、putExtra関数である。putExtra関数は、様々なパターンの引数を伴って呼び出される。この関数を呼び出す際の引数のパターンの例は、putExtra（key, value）、putExtra（mode）、putExtra（original_network_id, transport_stream_id, service_id）、およびputExtra（aiturl, orgid, appid）といったものを含む。putExtra（key, value）は、ハイブリッドキャスト起動のリクエストであることを指定するために使用される。putExtra（mode）は、モード（ＢＭＡまたはＢＩＡ）を指定するために使用される。
putExtra（original_network_id, transport_stream_id, service_id）は、放送局の選局情報を指定するために使用される。putExtra（aiturl, orgid, appid）は、ハイブリッドキャストのアプリケーション情報を指定するために使用される。これらの引数については、次に図６を参照しながら説明する。
putExtra（original_network_id, transport_stream_id, service_id）は、放送局の選局情報を指定するために使用される。putExtra（aiturl, orgid, appid）は、ハイブリッドキャストのアプリケーション情報を指定するために使用される。これらの引数については、次に図６を参照しながら説明する。
【0105】
図６は、図５に示したそれぞれの関数呼び出しの際の各パラメーターのデータ型および値を示す概略図である。パラメーターkeyとvalueとはペアで用いられる。パラメーターkeyはstring型であり、パラメーターvalueはBoolean型である。パラメーターkeyの値として"hybridcast_mode"を指定し、valueの値として「TRUE」を指定することにより、ハイブリッドキャスト起動のリクエストであることが指定される。パラメーターmodeはstring型であり、その値が「app」の場合にはモードが放送マネージドアプリケーション（ＢＭＡ）であることを表し、値が「bia」の場合にはモードが放送非依存マネージドアプリケーション（ＢＩＡ）であることを表す。パラメーターoriginal_network_id，transport_stream_id，service_idは、それぞれ、オリジナルネットワークＩＤ、トランスポートストリームＩＤ、サービスＩＤであり、これらの三つ組が、放送局の選局情報を指定するものである。aiturl，orgid，appidは、それぞれ、ＡＩＴ（アプリケーション情報テーブル）のＵＲＬ、組織ＩＤ、アプリケーションＩＤであり、これらの値によってハイブリッドキャストアプリケーションが特定される。なお、上記の関数の名称や仕様等の詳細は機器を制御するＯＳ（オペレーティングシステム）によって異なる場合もあるが、指定されるパラメーターの意味や値はＯＳに依存しない。いずれにしても、テレビ搭載ＯＳ向けアプリケーションから、ハイブリッドキャストアプリケーションを起動する際には、上に挙げたパラメーターを用いることができる。
【0106】
テレビ（受信機）２は、上記の起動要求を受けた場合、ＡＩＴＵＲＩ可否判定サーバー装置７に対してハイブリッドキャストアプリケーションの起動可否を問い合わせる。ＡＩＴＵＲＩ可否判定サーバー装置７からは、起動可否の判定結果がテレビ（受信機）２に対して返される。可否判定結果が「起動可」である場合に限って、テレビ（受信機）２は、ハイブリッドキャストアプリケーションを起動する。
【0107】
なお、ハイブリッドキャストアプリケーションの起動の際にmode=biaが指定された場合には、対象のアプリケーションは放送非依存であるため、放送受信状態や起動可否の状況には依存せずに起動が可能である。一方、mode=appが指定された場合には、選局対象の放送信号が受信できている必要がある。そのため、mode=appが指定された場合には下記のいずれかの処理を実行するようにする。その第１の方法では、テレビ（受信機）２の機能として対象の放送信号が受信可能か否かを判断できるようにする。ただし、この第１の方法は、テレビ（受信機）２の機能に依存する。その第２の方法では、テレビ（受信機）２の制御部２４が外部機能ＡＰＩを経由して、テレビ（受信機）２が持つ端末連携機能による、利用可能メディア情報および利用可能チャンネル情報の取得を行った後に、対象のハイブリッドキャストアプリケーションが起動可能である場合のみに起動するようにする。
【0108】
なお、上記の方法でのハイブリッドキャストアプリケーションの起動の際に、mode=appの指定を使用せず、常にmode=biaとするように運用してもよい。つまり、常に放送非依存マネージドアプリケーション（ＢＩＡ）のモードで起動するようにしてもよい。その場合には、パラメーターmodeの指定を不要としてもよい。
【0109】
［第２変形例，機能的特徴２の利用を含む］
別の変形例を説明する。本変形例においても、起動用アプリケーション２１３（図４参照）が直接、ハイブリッドキャストの起動要求（mode=app）を行うことによって、放送マネージドアプリケーション（ＢＭＡ）２１２を起動できるようにする。本変形例では、第１処理例の第３ステップにおいても説明したハイコネの内部要求と外部要求とを使用する。
別の変形例を説明する。本変形例においても、起動用アプリケーション２１３（図４参照）が直接、ハイブリッドキャストの起動要求（mode=app）を行うことによって、放送マネージドアプリケーション（ＢＭＡ）２１２を起動できるようにする。本変形例では、第１処理例の第３ステップにおいても説明したハイコネの内部要求と外部要求とを使用する。
【0110】
従来技術によるハイコネを用いた放送非依存マネージドアプリケーション（ＢＩＡ）の起動は、外部の連携端末装置５上で稼働するアプリケーションからの要求であるハイブリッドキャストアプリケーション起動要求StartAITControlledAppToHostDevidceを実行する。この起動要求は、非特許文献３（IPTVFJ STD-0013，2.9版）の第7.1.7.2.1節に記載されている。一方で、本変形例では、テレビ（受信機）２の内部でハイブリッドキャストアプリケーションの起動を行う。この場合には、従来技術において連携端末装置５側からの要求を行う場合に必要な手順の一部を省略することが可能である。
【0111】
図７は、従来技術により連携端末装置５側からテレビ（受信機）２に対する連携動作を開始する場合の処理の流れを示す概略図である。この処理の流れは、非特許文献３（IPTVFJ STD-0013，2.9版）の「付録Ｇ コンパニオンアプリケーションの基本動作」にも記載されている。
【0112】
この処理の流れは、次の通りである。ステップＳ１において、連携端末装置５は、コンパニオンアプリケーション（図中の「ＣＡ」）を起動する。ステップＳ２において、連携端末装置５は、機器発見接続を試みる。ステップＳ２１において、テレビ（受信機）２も、機器発見接続を試みる。ここで両者が相互に相手を発見し、連携端末装置５とテレビ（受信機）との接続が確立される。ステップＳ３において、連携端末装置５は、端末認証を行う。ステップＳ２２において、テレビ（受信機）２は、これに応じて連携端末装置５を認証する。これにより、認証が完了する。ステップＳ４において、連携端末装置５は、外部起動ロンチャーを画面に表示する。連携端末装置５のユーザーは、起動するハイブリッドキャストアプリケーションを選択して起動指示を行うことができるようになる。
【0113】
続いて、ステップＳ５において、連携端末装置５は、ハイブリッドキャストアプリケーションの起動命令を送信する。ステップＳ２３において、テレビ（受信機）２は、その起動命令を受信するとともに、指定されたハイブリッドキャストアプリケーションを実行環境にロードする。ステップＳ５の送信後、連携端末装置５は、ステップＳ６において、ｓｅｔＵＲＬを待つ状態に入っている。ステップＳ２４において、テレビ（受信機）２は、ｓｅｔＵＲＬを、連携端末装置５に対して送信する。ステップＳ７において、連携端末装置５は、送られたｓｅｔＵＲＬを受信する。ステップＳ８において、連携端末装置５は、ステップＳ７で受信したｓｅｔＵＲＬの情報に基づいて、ＨＴＭＬアプリケーションにアクセスし、ＨＴＭＬアプリケーションをロードする。これにより、連携端末装置５とテレビ（受信機）２との間で連携状態が確立し、双方向にデータを送信することが可能となる。ステップＳ９において、連携端末装置５は、ｓｅｎｄＴｘｔ（テキストデータの送信）やｒｅｃｖＴｘｔ（テキストデータの受信）を実行できるようになる。これに対応する形でステップＳ２５において、テレビ（受信機）２も、ｓｅｎｄＴｘｔやＲｅｃｖＴｘｔを実行できるようになる。
【0114】
本変形例では、上記（図７）で説明した手順を、テレビ（受信機）２の内部のみで実行する。つまり、図７で説明した連携端末装置５の機能を、テレビ（受信機）２が内部に持つようにする。ただし、テレビ（受信機）２の内部のみでこの手順を実行する場合には、いくつかの処理を変更（あるいは省略）することが可能である。具体的な方法として、次の２種類が考えられる。
【0115】
［第２変形例の第１の方法－外部要求（従来技術に準拠）］
本変形例での第１の方法では、図７で説明した従来技術による連携端末装置５の処理フローに準拠する手法を用いる。つまり、テレビ（受信機）２上で稼働する起動用アプリケーション２１３（図３等）をハイコネアプリケーションと見なして、この起動用アプリケーション２１３からテレビ（受信機）２への接続を行い、ハイブリッドキャストの起動要求を行う。その手順は、図７に記載されている連携端末装置５のステップＳ１からＳ９までの処理手順と同様である。なお、この場合は、ハイブリッドキャストブラウザーで稼働するハイブリッドキャストアプリケーション単体ではハイブリッドアプリケーションの起動要求が実行できないため、バックグラウンドでの起動用アプリケーションを経由するようにする。
本変形例での第１の方法では、図７で説明した従来技術による連携端末装置５の処理フローに準拠する手法を用いる。つまり、テレビ（受信機）２上で稼働する起動用アプリケーション２１３（図３等）をハイコネアプリケーションと見なして、この起動用アプリケーション２１３からテレビ（受信機）２への接続を行い、ハイブリッドキャストの起動要求を行う。その手順は、図７に記載されている連携端末装置５のステップＳ１からＳ９までの処理手順と同様である。なお、この場合は、ハイブリッドキャストブラウザーで稼働するハイブリッドキャストアプリケーション単体ではハイブリッドアプリケーションの起動要求が実行できないため、バックグラウンドでの起動用アプリケーションを経由するようにする。
【0116】
［第２変形例の第２の方法－内部要求，特徴的機能２の利用］
本変形例での第２の方法では、図７で説明した手順の一部を簡略化して実行する。具体的には、この第２の方法では、テレビ（受信機）２上で稼働するアプリケーションをコンパニオンプリケーションとして、機器発見の手順と端末認証の手順とを簡略化する。既存技術では、ステップＳ２における機器発見および接続では、連携端末装置５は、ＤＩＡＬ（Discovery-and-Launch）プロトコルを用いて、同一ネットワーク内にあるハイコネ対応のテレビ（受信機）２を発見する。本変形例（第２変形例の第２の方法）では、代わりに、（１）ローカルホスト（localhost）のＩＰアドレスを対象として接続処理を行う、あるいは（２）テレビ（受信機）２内の相互では機器発見および接続を不要とする、といった方法を用いる。また、ステップＳ３における端末認証についても、同一のテレビ（受信機）２内（同一筐体内）での認証を不要とする。これにより、ハイブリッドキャストアプリケーションから、ハイコネのＡＰＩを介して、受信機状態の取得やアプリケーションの起動要求などを実行できるようになる。
本変形例での第２の方法では、図７で説明した手順の一部を簡略化して実行する。具体的には、この第２の方法では、テレビ（受信機）２上で稼働するアプリケーションをコンパニオンプリケーションとして、機器発見の手順と端末認証の手順とを簡略化する。既存技術では、ステップＳ２における機器発見および接続では、連携端末装置５は、ＤＩＡＬ（Discovery-and-Launch）プロトコルを用いて、同一ネットワーク内にあるハイコネ対応のテレビ（受信機）２を発見する。本変形例（第２変形例の第２の方法）では、代わりに、（１）ローカルホスト（localhost）のＩＰアドレスを対象として接続処理を行う、あるいは（２）テレビ（受信機）２内の相互では機器発見および接続を不要とする、といった方法を用いる。また、ステップＳ３における端末認証についても、同一のテレビ（受信機）２内（同一筐体内）での認証を不要とする。これにより、ハイブリッドキャストアプリケーションから、ハイコネのＡＰＩを介して、受信機状態の取得やアプリケーションの起動要求などを実行できるようになる。
【0117】
［特徴的機能３］（選局およびハイブリッドキャストアプリケーションの実行の両方を行うためのＡＰＩの実装）
既存技術によるテレビ（受信機）のＡＰＩとして、指定したハイブリッドキャストアプリケーションへの遷移を可能とするreplaceApplication()関数がある。この関数は、非特許文献３（IPTVFJ STD-0013，2.9版）の第7.1.6.1.4節に記載されている。この関数では、ハイブリッドキャストアプリケーションを示すＵＲＬと、組織ＩＤ（organization_id）と、アプリケーションＩＤ（application_id）とを引数として指定することができる。
また放送局の選局を行うことのできるtuneto()関数もある。しかしながら、既存技術では、テレビ（受信機）のＡＰＩとして、放送の選局とハイブリッドキャストアプリケーションの起動とを行うためのインターフェースは存在しない。本実施形態では、放送の選局とハイブリッドキャストアプリケーションの起動とを行うためのテレビ（受信機）のＡＰＩを設ける。
既存技術によるテレビ（受信機）のＡＰＩとして、指定したハイブリッドキャストアプリケーションへの遷移を可能とするreplaceApplication()関数がある。この関数は、非特許文献３（IPTVFJ STD-0013，2.9版）の第7.1.6.1.4節に記載されている。この関数では、ハイブリッドキャストアプリケーションを示すＵＲＬと、組織ＩＤ（organization_id）と、アプリケーションＩＤ（application_id）とを引数として指定することができる。
また放送局の選局を行うことのできるtuneto()関数もある。しかしながら、既存技術では、テレビ（受信機）のＡＰＩとして、放送の選局とハイブリッドキャストアプリケーションの起動とを行うためのインターフェースは存在しない。本実施形態では、放送の選局とハイブリッドキャストアプリケーションの起動とを行うためのテレビ（受信機）のＡＰＩを設ける。
【0118】
図８は、本実施形態が備えるテレビ（受信機）のＡＰＩの１つであるstartApplication()関数の形式の例を示す概略図である。図示するように、startApplication()関数は、organization_id，application_id，aiturl，original_network_id，transport_stream_id，service_idというパラメーターを持つものである。
【0119】
図９は、上記のstartApplication()関数が受け入れるパラメーターのそれぞれのデータ型を示す概略図である。パラメーターorganization_idは、number型であり、組織ＩＤを表す。パラメーターapplication_idは、number型であり、アプリケーションを識別するためのアプリケーションＩＤを表す。パラメーターaiturlは、string型であり、ＡＩＴ（アプリケーション情報テーブル）を表す。パラメーターoriginal_network_idは、number型であり、オリジナルネットワークＩＤを表す。パラメーターtransport_stream_idは、number型であり、トランスポートストリームＩＤを表す。パラメーターservice_idは、number型であり、サービスＩＤを表す。なお、original_network_idとtransport_stream_idとservice_idとの組は、放送サービスを特定する情報である。
【0120】
このstartApplication()関数は、放送サービスを選局して且つハイブリッドキャストアプリケーションを起動する機能のインターフェースとして機能する。なお、プログラムの機能として放送サービスを選局するための処理自体、およびハイブリッドキャストアプリケーションを起動するための処理自体は、既存技術を用いて実現可能である。
【0121】
なお、上では、startApplication()関数のＡＰＩを設ける例を説明したが、代わりに既存のＡＰＩの機能を拡張することによって同様のものを実現してもよい。例えば、既存ＡＰＩであるreplaceApplication()関数に、original_network_idとtransport_stream_idとservice_idとのパラメーターを追加して、放送サービスを指定できるようにしてよい。これにより、replaceApplication()関数の呼び出しによって、アプリケーションの遷移とともに、放送の選局を実行するようにしてよい。なお、replaceApplication()関数においてＵＲＬを引数として渡す場合に、そのＵＲＬは、ハイブリッドキャストアプリケーションのＵＲＬである場合と、ＡＩＴのＵＲＬである場合との両方に対応できるようにする。
【0122】
［第２処理例］
第２処理例では、連携端末装置５のハイコネアプリケーションからの起動を行う。第２処理例の前提として、テレビ（受信機）２と連携端末装置５とは同一のネットワークに存在しており、且つこれらの両装置はハイコネの仕組みにおけるペアリングを実施済みである。
第２処理例では、連携端末装置５のハイコネアプリケーションからの起動を行う。第２処理例の前提として、テレビ（受信機）２と連携端末装置５とは同一のネットワークに存在しており、且つこれらの両装置はハイコネの仕組みにおけるペアリングを実施済みである。
【0123】
第２処理例におけるテレビ（受信機）２の動作手順は、次の通りである。
【0124】
第１ステップ： 連携端末装置５上で稼働するハイコネアプリケーションは、テレビ（受信機）２に対して、放送非依存マネージドアプリケーション（ＢＩＡ）の起動要求を行う。
【0125】
第２ステップ： テレビ（受信機）２のアプリ起動可否判定機能２１７は、ＡＩＴＵＲＩ可否判定サーバー装置７に、そのアプリケーションの起動可否を問い合わせる。ＡＩＴＵＲＩ可否判定サーバー装置７は、起動可否を判定し、その判定結果をテレビ（受信機）２に返す。
【0126】
第３ステップ： ＡＩＴＵＲＩ可否判定サーバー装置７から返された応答が「起動ＯＫ」を示している場合には、テレビ（受信機）２は、第１ステップにおいて要求された放送非依存マネージドアプリケーション（ＢＩＡ）を起動する。
【0127】
第４ステップ： 第３ステップにおいて起動された放送非依存マネージドアプリケーション（ＢＩＡ）２１１が動作する。この放送非依存マネージドアプリケーション（ＢＩＡ）２１１の機能は、例えば、通信コンテンツを受信して提示するといったものである。これにより、ユーザーは通信コンテンツを視聴することができる。
【0128】
第５ステップ： テレビ（受信機）２上で稼働する放送非依存マネージドアプリケーション（ＢＩＡ）２１１は、連携端末装置５との間で双方向の通信を行う。例えば、放送非依存マネージドアプリケーション（ＢＩＡ）２１１は、コンテンツの視聴状態に関する情報などを、連携端末装置５との間でやりとりすることができる。
【0129】
第６ステップ： 連携端末装置５上で稼働するハイコネアプリケーションは、テレビ（受信機）２に対して、放送マネージドアプリケーション（ＢＭＡ）の起動要求を行う。
【0130】
第７ステップ： テレビ（受信機）２のアプリ起動可否判定機能２１７は、ＡＩＴＵＲＩ可否判定サーバー装置７に、そのアプリケーションの起動可否を問い合わせる。ＡＩＴＵＲＩ可否判定サーバー装置７は、起動可否を判定し、その判定結果をテレビ（受信機）２に返す。
【0131】
第８ステップ： ＡＩＴＵＲＩ可否判定サーバー装置７から返された応答が「起動ＯＫ」を示している場合には、テレビ（受信機）２は、第６ステップにおいて要求された放送マネージドアプリケーション（ＢＭＡ）を起動する。
【0132】
第９ステップ： 第８ステップにおいて起動された放送マネージドアプリケーション（ＢＭＡ）２１２が動作する。この放送マネージドアプリケーション（ＢＭＡ）２１２の機能は、例えば、放送マネージドなコンテンツを受信して提示するといったものである。これにより、ユーザーはコンテンツを視聴することができる。
【0133】
第１０ステップ： テレビ（受信機）２上で稼働する放送マネージドアプリケーション（ＢＭＡ）２１２は、連携端末装置５との間で双方向の通信を行う。例えば、放送マネージドアプリケーション（ＢＭＡ）２１２は、コンテンツの視聴状態に関する情報などを、連携端末装置５との間でやりとりすることができる。
【0134】
図１０は、第２処理例の手順を示す概略図である。図中の丸数字は、上記の処理手順におけるステップの番号に対応する。即ち、第１ステップから第３ステップまでは、連携端末装置５からの要求に基づいて、テレビ（受信機）２上で放送非依存マネージドアプリケーション（ＢＩＡ）２１１を起動するまでの処理過程である。第４ステップにおいて、放送非依存マネージドアプリケーション（ＢＩＡ）２１１が稼働する。第５ステップにおいて、放送非依存マネージドアプリケーション（ＢＩＡ）２１１と連携端末装置５との間で双方向のデータの送受信を行う。また、第６ステップから第８ステップまでは、連携端末装置５からの要求に基づいて、テレビ（受信機）２上で放送マネージドアプリケーション（ＢＭＡ）２１２を起動するまでの処理過程である。第４ステップにおいて、放送マネージドアプリケーション（ＢＭＡ）２１２が稼働する。第５ステップにおいて、放送マネージドアプリケーション（ＢＭＡ）２１２と連携端末装置５との間で双方向のデータの送受信を行う。
【0135】
ここで説明した第２処理例の場合に、連携端末装置５側で稼働するハイコネアプリケーションは、テレビ（受信機）２側においてその時点で稼働しているアプリケーションが放送非依存マネージドアプリケーション（ＢＩＡ）であるのか放送マネージドアプリケーション（ＢＭＡ）であるのかを知ることができない。
そこで、テレビ（受信機）２の制御部２４が、次に説明する機能的特徴４および機能的特徴５を持つようにする。
そこで、テレビ（受信機）２の制御部２４が、次に説明する機能的特徴４および機能的特徴５を持つようにする。
【0136】
［機能的特徴４］ハイブリッドキャストアプリケーションの状況の把握（状態判定）
従来技術によるハイコネの規定では、連携端末装置５は、テレビ（受信機）２側でのハイブリッドキャストの稼働状態を把握することができる。非特許文献３（IPTVFJ STD-0013，2.9版）の第7.2.3.2.3.4.2節（受信機状態の取得）には、受信機状態を取得するためのＡＰＩが規定されている。しかしながら、従来技術では、連携端末装置５は、テレビ（受信機）２の状態が放送非依存マネージドアプリケーション（ＢＩＡ）であるのか放送マネージドアプリケーション（ＢＭＡ）であるのかを把握することができない。
従来技術によるハイコネの規定では、連携端末装置５は、テレビ（受信機）２側でのハイブリッドキャストの稼働状態を把握することができる。非特許文献３（IPTVFJ STD-0013，2.9版）の第7.2.3.2.3.4.2節（受信機状態の取得）には、受信機状態を取得するためのＡＰＩが規定されている。しかしながら、従来技術では、連携端末装置５は、テレビ（受信機）２の状態が放送非依存マネージドアプリケーション（ＢＩＡ）であるのか放送マネージドアプリケーション（ＢＭＡ）であるのかを把握することができない。
【0137】
そこで、本実施形態では、連携端末装置５がテレビ（受信機）２側におけるモード（ＢＩＡまたはＢＭＡ）を把握することができるようにする。具体的には、下に説明するようなインターフェースを設けるようにする。
【0138】
図１１は、テレビ（受信機）２側で稼働するハイブリッドキャストアプリケーションを識別する情報を問い合わせるためのリクエストの例を示す概略図である。本例では、既存技術においても存在するリクエストである「<BaseURL>/status」を拡張することにより、ハイブリッドキャストアプリケーションを識別する情報を連携端末装置５に対して返せるようにしている。図示する例では、リクエストを発行するためのＵＲＬは「<BaseURL>/status」であり、そのメソッドは「get」である。なお、既存の「status」というリクエストを拡張する代わりに、別のＡＰＩを設けるようにしてもよい。別のＡＰＩとする場合のそのリクエストのＵＲＬは、例えば、「<BaseURL>/modestatus」などとしてよい。
【0139】
図１２は、テレビ（受信機）２側のモードの情報を返すレスポンスの例を示す概略図である。図示するように、レスポンスは、例えばＪＳＯＮ形式のデータとして表わされる。
同図では、便宜的に、ＪＳＯＮ形式のデータに対して行番号を付与している。
同図では、便宜的に、ＪＳＯＮ形式のデータに対して行番号を付与している。
【0140】
図１２に示すデータ（レスポンス）は、ヘッダー部分（"head"、第２行目から第５行目まで）と、ボディー部分（"body"、第６行目から第１９行目まで）を含んでいる。ボディー部分は、状況（"status"）を表すブロック（第７行目から第１８行目まで）を含む。状況は、ハイブリッドキャスト（"hybridcast"、第８行目から第１１行目まで）、連携アプリ（"companion_apps"、第１２行目）、リソース（"resource"、第１３行目から第１７行目まで）という３つのブロックを含む。これらのうち、ハイブリッドキャストのブロックは、状況（"status"、第９行目）およびモード（"mode"、第１０行目）の各項目を含む。
本例において、この状況の値は、「Running」であり、ハイブリッドキャストアプリケーションが稼働中であることを表している。また、このモードの値は「bia」であり、この値はテレビ（受信機）２側のモードが放送非依存マネージドアプリケーション（ＢＩＡ）であることを表す情報である。このようなレスポンスを獲得することにより、本実施形態の連携端末装置５は、ハイブリッドキャストアプリケーションの稼働状態とともに、そのモードの情報を把握することができる。これにより、連携端末装置５側は、例えば重複したアプリケーションの起動を行う必要がなくなる。
本例において、この状況の値は、「Running」であり、ハイブリッドキャストアプリケーションが稼働中であることを表している。また、このモードの値は「bia」であり、この値はテレビ（受信機）２側のモードが放送非依存マネージドアプリケーション（ＢＩＡ）であることを表す情報である。このようなレスポンスを獲得することにより、本実施形態の連携端末装置５は、ハイブリッドキャストアプリケーションの稼働状態とともに、そのモードの情報を把握することができる。これにより、連携端末装置５側は、例えば重複したアプリケーションの起動を行う必要がなくなる。
【0141】
［機能的特徴５］稼働中のハイブリッドキャストアプリケーションのＵＲＬの把握
従来技術によるハイコネの規定では、連携端末装置５は、テレビ（受信機）２側におけるハイブリッドキャストの起動状態を確認することができる。この機能は、非特許文献３（IPTVFJ STD-0013，2.9版）の第7.2.3.2.3.4.2節（受信機状態の取得）に規定されている。しかしながら、従来技術では、連携端末装置５は、テレビ（受信機）２側においてその時点で稼働しているアプリケーションが何であるかを知ることができない。例えば、連携端末装置５側からハイコネを用いてテレビ（受信機）２側で特定のアプリケーションを起動させた場合にも、その後にテレビ（受信機）２がreplaceApplication()関数を実行してアプリケーションの切り替えを行うと、連携端末装置５は、切り替え後のアプリケーションが何であるかを把握できない。
従来技術によるハイコネの規定では、連携端末装置５は、テレビ（受信機）２側におけるハイブリッドキャストの起動状態を確認することができる。この機能は、非特許文献３（IPTVFJ STD-0013，2.9版）の第7.2.3.2.3.4.2節（受信機状態の取得）に規定されている。しかしながら、従来技術では、連携端末装置５は、テレビ（受信機）２側においてその時点で稼働しているアプリケーションが何であるかを知ることができない。例えば、連携端末装置５側からハイコネを用いてテレビ（受信機）２側で特定のアプリケーションを起動させた場合にも、その後にテレビ（受信機）２がreplaceApplication()関数を実行してアプリケーションの切り替えを行うと、連携端末装置５は、切り替え後のアプリケーションが何であるかを把握できない。
【0142】
そこで、本実施形態では、例えば連携端末装置５がテレビ（受信機）２側におけるハイブリッドキャストの起動状態を問い合わせた際に、従来技術と同様の起動状態の情報に加えて、ハイブリッドキャストアプリケーションを識別することのできる情報が、連携端末装置５に返されるようにする。
【0143】
図１３は、テレビ（受信機）２側で稼働するハイブリッドキャストアプリケーションを識別する情報を問い合わせるためのリクエストの例を示す概略図である。本例では、既存技術においても存在するリクエストである「<BaseURL>/status」を拡張することにより、ハイブリッドキャストアプリケーションを識別する情報を連携端末装置５に対して返せるようにしている。図示する例では、リクエストを発行するためのＵＲＬは「<BaseURL>/status」であり、そのメソッドは「get」である。なお、既存技術において存在するリクエストを拡張する代わりに、別のＡＰＩを設けるようにしてもよい。別のＡＰＩとする場合のそのリクエストのＵＲＬは、例えば、「<BaseURL>/urlstatus」などとしてよい。
【0144】
図１４は、ハイブリッドキャストアプリケーションを識別する情報を返すレスポンスの例を示す概略図である。図示するように、レスポンスは、例えばＪＳＯＮ形式のデータとして表わされる。同図では、便宜的に、ＪＳＯＮ形式のデータに対して行番号を付与している。
【0145】
図１４に示すデータ（レスポンス）は、ヘッダー部分（"head"、第２行目から第５行目まで）と、ボディー部分（"body"、第６行目から第１９行目まで）を含んでいる。ボディー部分は、状況（"status"）を表すブロック（第７行目から第１８行目まで）を含む。状況は、ハイブリッドキャスト（"hybridcast"、第８行目から第１１行目まで）、連携アプリ（"companion_apps"、第１２行目）、リソース（"resource"、第１３行目から第１７行目まで）という３つのブロックを含む。これらのうち、ハイブリッドキャストのブロックは、状況（"status"、第９行目）およびＵＲＬ（"url"、第１０行目）の各項目を含む。
本例において、この状況の値は、「Running」であり、ハイブリッドキャストアプリケーションが稼働中であることを表している。また、このＵＲＬの値は「http://sample/index.html」であり、この値は稼働中のハイブリッドキャストアプリケーションを識別する情報である。なお、変形例としては、ハイブリッドキャストアプリケーションを識別する情報として、ＵＲＬの代わりに、その他の識別情報をレスポンス内に持たせるようにしてもよい。このようなレスポンスを獲得することにより、本実施形態の連携端末装置５は、ハイブリッドキャストアプリケーションの稼働状態とともに、そのハイブリッドキャストアプリケーションが何であるか（識別情報）を把握することができる。
本例において、この状況の値は、「Running」であり、ハイブリッドキャストアプリケーションが稼働中であることを表している。また、このＵＲＬの値は「http://sample/index.html」であり、この値は稼働中のハイブリッドキャストアプリケーションを識別する情報である。なお、変形例としては、ハイブリッドキャストアプリケーションを識別する情報として、ＵＲＬの代わりに、その他の識別情報をレスポンス内に持たせるようにしてもよい。このようなレスポンスを獲得することにより、本実施形態の連携端末装置５は、ハイブリッドキャストアプリケーションの稼働状態とともに、そのハイブリッドキャストアプリケーションが何であるか（識別情報）を把握することができる。
【0146】
図１５は、上で説明した実施形態におけるテレビ（受信機）２や、連携端末装置５や、ＡＩＴＵＲＩ可否判定サーバー装置７を構成する要素であるコンピューターの内部構成の例を示すブロック図である。これらの装置の少なくとも一部の機能は、コンピューターを用いて実現され得る。図示するように、そのコンピューターは、中央処理装置９０１と、ＲＡＭ９０２と、入出力ポート９０３と、入出力デバイス９０４や９０５等と、バス９０６と、を含んで構成される。コンピューター自体は、既存技術を用いて実現可能である。
中央処理装置９０１は、ＲＡＭ９０２等から読み込んだプログラムに含まれる命令を実行する。中央処理装置９０１は、各命令にしたがって、ＲＡＭ９０２にデータを書き込んだり、ＲＡＭ９０２からデータを読み出したり、算術演算や論理演算を行ったりする。ＲＡＭ９０２は、データやプログラムを記憶する。ＲＡＭ９０２に含まれる各要素は、アドレスを持ち、アドレスを用いてアクセスされ得るものである。なお、ＲＡＭは、「ランダムアクセスメモリー」の略である。入出力ポート９０３は、中央処理装置９０１が外部の入出力デバイス等とデータのやり取りを行うためのポートである。入出力デバイス９０４や９０５は、入出力デバイスである。入出力デバイス９０４や９０５は、入出力ポート９０３を介して中央処理装置９０１との間でデータをやりとりする。バス９０６は、コンピューター内部で使用される共通の通信路である。例えば、中央処理装置９０１は、バス９０６を介してＲＡＭ９０２のデータを読んだり書いたりする。また、例えば、中央処理装置９０１は、バス９０６を介して入出力ポートにアクセスする。
中央処理装置９０１は、ＲＡＭ９０２等から読み込んだプログラムに含まれる命令を実行する。中央処理装置９０１は、各命令にしたがって、ＲＡＭ９０２にデータを書き込んだり、ＲＡＭ９０２からデータを読み出したり、算術演算や論理演算を行ったりする。ＲＡＭ９０２は、データやプログラムを記憶する。ＲＡＭ９０２に含まれる各要素は、アドレスを持ち、アドレスを用いてアクセスされ得るものである。なお、ＲＡＭは、「ランダムアクセスメモリー」の略である。入出力ポート９０３は、中央処理装置９０１が外部の入出力デバイス等とデータのやり取りを行うためのポートである。入出力デバイス９０４や９０５は、入出力デバイスである。入出力デバイス９０４や９０５は、入出力ポート９０３を介して中央処理装置９０１との間でデータをやりとりする。バス９０６は、コンピューター内部で使用される共通の通信路である。例えば、中央処理装置９０１は、バス９０６を介してＲＡＭ９０２のデータを読んだり書いたりする。また、例えば、中央処理装置９０１は、バス９０６を介して入出力ポートにアクセスする。
【0147】
上記の各装置の機能は、コンピューター上で稼働するプログラムを用いてで実現することができる。その場合、この機能を実現するためのプログラムをコンピューター読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピューターシステムに読み込ませ、実行することによって実現しても良い。なお、ここでいう「コンピューターシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピューター読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、ＵＳＢメモリー等の可搬媒体、コンピューターシステムに内蔵されるハードディスク等の記憶装置のことをいう。つまり、「コンピューター読み取り可能な記録媒体」とは、非一過性の（non-transitory）コンピューター読み取り可能な記録媒体であってよい。さらに「コンピューター読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、一時的に、動的にプログラムを保持するもの、その場合のサーバーやクライアントとなるコンピューターシステム内部の揮発性メモリーのように、一定時間プログラムを保持しているものも含んでも良い。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピューターシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。
【0148】
以上説明した実施形態（変形例を含む）により、テレビ（受信機）２上においてアプリケーションを起動する際の制約を緩和することができる。具体的には、テレビ（受信機）２のそれぞれの状態において、テレビ（受信機）２上で任意のハイブリッドキャストアプリケーションを起動することができるようになる。
【0149】
具体的には、第１に、テレビ搭載ＯＳから任意のハイブリッドキャストアプリケーションを起動することが可能となる。つまり、連携端末装置５を起点とすることなく、テレビ（受信機）２単体で、任意のハイブリッドキャストアプリケーションを利用することができるようになる。つまり、放送局側からは、当該放送局のマネージドな領域において、柔軟なサービス提供を行うことが可能となる。また、放送局側では、テレビ（受信機）２のＯＳの種類に依存することなく（つまりメーカー等に依存することなく）、標準化された技術を用いて、アプリケーションを開発したりメンテナンスしたりすることが可能となる。つまり、開発およびメンテナンスのコストを低減化できる。また、視聴者側では、放送サービスと通信コンテンツとの垣根を感じることなく、様々な形態で配信される番組を容易に視聴することができるようになる。
【0150】
また、第２に、ある放送局が提供するハイブリッドキャストアプリケーションから、別の放送局が提供するハイブリッドキャストアプリケーションを起動することが可能となる。これが可能となるのは、上記実施形態において、テレビ（受信機）２上のブラウザー（アプリケーションの実行環境）からハイコネ機能を実行できるようにしたこと、および受信機ＡＰＩの拡張も行ったことによるものである。これにより、放送局側からは、アプリケーション間の遷移に関する制約がなくなって容易になり、複数の放送局を横断するサービスを実現することもできるようになる。また、視聴者側では、放送サービスと通信コンテンツとの垣根を感じることなく、様々な形態で配信される番組を容易に視聴することができるようになる。
【0151】
また、説明した実施形態（変形例を含む）によれば、連携端末装置５側からのＡＰＩを介した問い合わせに対して、テレビ（受信機）２は、稼働中のハイブリッドキャストアプリケーションが放送非依存マネージドアプリケーション（ＢＩＡ）であるか放送マネージドアプリケーション（ＢＭＡ）であるかを表す情報を、連携端末装置５に返すことができる。また、同様のＡＰＩを介した問い合わせに対して、テレビ（受信機）２は、稼働中のハイブリッドキャストアプリケーションを識別するための識別情報（例えば、ＵＲＬ等）を、連携端末装置５に返すことができる。これらにより、連携端末装置５で稼働するアプリケーションは、それらの情報を把握し、それらの情報に基づいた動作を行うことが可能となる。
【0152】
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【産業上の利用可能性】
【0153】
本発明は、例えば、ユーザーに対するコンテンツを提供するための基盤として利用することができる。但し、本発明の利用範囲はここに例示したものには限られない。
【符号の説明】
【0154】
１ システム
２ テレビ（受信機）
５ 連携端末装置
６ リモコン装置
７ ＡＩＴＵＲＩ可否判定サーバー装置
２１ プログラム駆動部（アプリケーション稼働部）
２２ ハイブリッドキャスト領域
２３ テレビ搭載ＯＳ向けアプリケーション領域
２４ 制御部
２５ その他機能部
２１１ 放送非依存マネージドアプリケーション（ＢＩＡ）
２１２ 放送マネージドアプリケーション（ＢＭＡ）
２１３ 起動用アプリケーション
２１７，２１８ アプリ起動可否判定機能
８９１ ローカルネットワーク
８９２ インターネット
８９３ 中継装置
９０１ 中央処理装置
９０２ ＲＡＭ
９０３ 入出力ポート
９０４，９０５ 入出力デバイス
９０６ バス
２ テレビ（受信機）
５ 連携端末装置
６ リモコン装置
７ ＡＩＴＵＲＩ可否判定サーバー装置
２１ プログラム駆動部（アプリケーション稼働部）
２２ ハイブリッドキャスト領域
２３ テレビ搭載ＯＳ向けアプリケーション領域
２４ 制御部
２５ その他機能部
２１１ 放送非依存マネージドアプリケーション（ＢＩＡ）
２１２ 放送マネージドアプリケーション（ＢＭＡ）
２１３ 起動用アプリケーション
２１７，２１８ アプリ起動可否判定機能
８９１ ローカルネットワーク
８９２ インターネット
８９３ 中継装置
９０１ 中央処理装置
９０２ ＲＡＭ
９０３ 入出力ポート
９０４，９０５ 入出力デバイス
９０６ バス
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】