特許 7286040 端末装置およびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-05-25

(45)【発行日】2023-06-02

(54)【発明の名称】端末装置およびプログラム

(51)【国際特許分類】

   H04N 21/435 20110101AFI20230526BHJP

   H04N 21/436 20110101ALI20230526BHJP

   G06F 9/445 20180101ALI20230526BHJP

   H04H 20/28 20080101ALI20230526BHJP

   H04H 60/13 20080101ALI20230526BHJP

【ＦＩ】

H04N21/435

H04N21/436

G06F9/445

H04H20/28

H04H60/13

【請求項の数】 2

(21)【出願番号】P 2023018415

(22)【出願日】2023-02-09

(62)【分割の表示】P 2021002036の分割

【原出願日】2021-01-08

(65)【公開番号】P2023059902

(43)【公開日】2023-04-27

【審査請求日】2023-02-09

(31)【優先権主張番号】P 2020002438

(32)【優先日】2020-01-09

(33)【優先権主張国・地域又は機関】JP

【早期審査対象出願】

(73)【特許権者】

【識別番号】000004352

【氏名又は名称】日本放送協会

(74)【代理人】

【識別番号】100141139

【弁理士】

【氏名又は名称】及川 周

(74)【代理人】

【識別番号】100171446

【弁理士】

【氏名又は名称】高田 尚幸

(74)【代理人】

【識別番号】100114937

【弁理士】

【氏名又は名称】松本 裕幸

(74)【代理人】

【識別番号】100171930

【弁理士】

【氏名又は名称】木下 郁一郎

(72)【発明者】

【氏名】大亦 寿之

【審査官】富樫 明

(56)【参考文献】

【文献】特開２０２１－７２６１３（ＪＰ，Ａ）

【文献】特開２０１９－６８４１０（ＪＰ，Ａ）

【文献】特開２０１５－１４６４７８（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｎ ２１／００－２１／８５８

Ｇ０６Ｆ ９／４４５

Ｈ０４Ｈ ２０／２８

Ｈ０４Ｈ ６０／１３

(57)【特許請求の範囲】

【請求項1】

放送を受信する受信機から、前記受信機が受信可能な編成チャンネルの名称である編成サービス名を含む編成チャンネル情報を取得する編成チャンネル情報取得部と、
予め特定の編成サービス名を記憶する記憶部と、
前記特定の編成サービス名に関連付けられるプログラムの起動要求を前記受信機に対して行う機能を持つ起動要求部と、
前記記憶部が記憶する前記特定の編成サービス名が、前記編成チャンネル情報取得部が前記受信機から取得した前記編成チャンネル情報に含まれるか否かを判定するとともに、この判定結果に基づいて前記起動要求部が前記プログラムの起動要求を行うか否かを制御する判定部と、
を備え、
前記編成チャンネル情報取得部は、ハイブリッドキャスト対応受信機の「channels」のアプリケーションプログラムインターフェースを呼び出すことにより、前記編成チャンネル情報を取得する、
端末装置。

【請求項2】

コンピューターを、
請求項１に記載の端末装置、
として機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、端末装置およびプログラムに関する。

【背景技術】

【0002】

従来技術では、放送受信機と連携する端末装置から放送受信機上で稼働するプログラムの起動を要求する場合、放送受信機が受信する放送の資源を特定する情報と、起動対象のプログラムを特定する情報との整合性を確認していた。

【0003】

非特許文献1の７．２．３．２．３．３．１節「起動要求」には、受信機上のハイブリッドキャストアプリの起動について記載されている。従来の技術では、放送通信連携システムであるハイブリッドキャストでは、端末装置から、即ちスマートフォンのアプリ等から、受信機上のハイブリッドキャストアプリを起動できる。具体的には、端末装置から、受信機に対して、選局すべき放送の編成チャンネルの情報と、起動すべきハイブリッドキャストアプリのＡＩＴのＵＲＬとを送信することで、受信機上のハイブリッドキャストアプリの起動が可能である。なお、ＡＩＴは、アプリケーション情報テーブル（Application Information Table）を表す。

【0004】

なお、端末装置から、放送の編成チャンネルの情報と、起動すべきハイブリッドキャストアプリのＡＩＴのＵＲＬとを受信した受信機は、端末装置から受信した起動命令を、受信機外の可否判定サーバー装置に送信する。可否判定サーバー装置は、選局すべき放送の編成チャンネルの情報と、起動すべきハイブリッドキャストアプリのＡＩＴのＵＲＬとの組み合わせの妥当性を確認する。可否判定サーバー装置は、その判定結果を受信機に返却する。受信機は、可否判定サーバー装置から、妥当という判定結果を受信した場合に限り、端末装置側から要求された、選局およびハイブリッドキャストアプリの起動を実行する。

【0005】

なお、上記の放送の編成チャンネルの情報は、オリジナルネットワークＩＤ（original_network_id）と、トランスポートストリームＩＤ（transport_stream_id）と、サービスＩＤ（service_id）との組み合わせとして指定される。

【0006】

非特許文献１によれば、ハイブリッドキャストが対象とする放送サービスは、地上波放送、ＢＳ放送（放送衛星による放送）、および広帯域ＣＳデジタル放送である。
非特許文献２の「第七編 地上デジタルテレビジョン放送送出運用規定」には、地上波放送について、上記の、オリジナルネットワークＩＤと、トランスポートストリームＩＤと、サービスＩＤとの割り当てが規定されている。なお、これらの値は都道府県などの地域ごとに割り当てられた地域識別の値と、地域事業者識別の値をもとに算出される。地域事業者識別の値は、地域ごとに「０」から「１５」までの値を利用することができる。
非特許文献３の「第一部 第七編 ＢＳデジタル放送送出運用規定」には、ＢＳ放送について、上記の、オリジナルネットワークＩＤと、トランスポートストリームＩＤと、サービスＩＤとの割り当てが規定されている。
非特許文献３の「第二部 第七編 広帯域ＣＳデジタル放送送出運用規定」には、広帯域ＣＳデジタル放送について、上記の、オリジナルネットワークＩＤと、トランスポートストリームＩＤと、サービスＩＤとの割り当てが規定されている。

【0007】

なお、オリジナルネットワークＩＤ、トランスポートストリームＩＤ、およびサービスＩＤは、日本全国において各編成チャンネルに対して重複することなくＩＤの値が割り振られている。したがって、上記の可否判定サーバー装置は、各編成チャンネルに、起動を許可するハイブリッドキャストアプリのＡＩＴのＵＲＬを対応付けて管理することによって、放送事業者の独立性を担保しながらアプリの起動の妥当性を保証することができる。

【0008】

一方、非特許文献４の「第２部地上デジタル放送ネットワークにおけるケーブルテレビ事業者の自主放送運用仕様」では、ケーブルテレビの地上デジタル放送ネットワークを用いた自主放送（いわゆるコミュニティチャンネル）についても、放送の編成チャンネルごとに、オリジナルネットワークＩＤ、トランスポートストリームＩＤ、およびサービスＩＤの値の割当が規定されている。

【先行技術文献】

【非特許文献】

【0009】

【文献】「ＩＰＴＶ規定 ハイブリッドキャスト運用規定 ＩＰＴＶＦＪ ＳＴＤ－００１３ ２．７版」，２０１８年９月２１日改定，一般社団法人ＩＰＴＶフォーラム

【文献】「地上デジタルテレビジョン放送運用規定 技術資料 ＡＲＩＢ ＴＲ－Ｂ１４ ６．５版」，２０１９年１月２１日改定，一般社団法人電波産業会

【文献】「ＢＳ／広帯域ＣＳデジタル放送運用規定 技術資料 ＡＲＩＢ ＴＲ－Ｂ１５ ７．７版」，平成３０年（２０１８年）１０月１１日改定，一般社団法人電波産業会

【文献】「ＪＬａｂｓ ＳＰＥＣ－００６ ２．１版 地上デジタルテレビジョン放送 パススルーならびに自主放送運用仕様」, ２０１４年３月３１日，一般社団法人日本ケーブルラボ

【発明の概要】

【発明が解決しようとする課題】

【0010】

しかしながら、ケーブルテレビの地上デジタル放送ネットワークを用いた自主放送に関しては、都道府県等の地域ごとに地域事業者識別の値が「１３」と「１５」と２つまでに制限されている。このため、各地域において最大２つのケーブルテレビ放送事業者の編成チャンネルしか識別することができない。したがって、３つ以上のケーブルテレビ放送事業者が存在する地域においては、複数のケーブルテレビ放送事業者が、同一の、オリジナルネットワークＩＤ、トランスポートストリームＩＤ、およびサービスＩＤの値の組み合わせを使用することとなる。つまり、複数のケーブルテレビ放送事業者が、同一の識別情報を使用する状況があり得る。したがって、ハイブリッドキャストアプリの外部起動を用いたサービスを運用しようとする場合、前記の可否判定サーバー装置は、放送事業者の独立性を担保しながらアプリの起動の妥当性を管理・保証することができないという問題が起こる。例えば、同一のオリジナルネットワークＩＤ、トランスポートストリームＩＤ、およびサービスＩＤの値の組み合わせを用いて自主放送サービスを提供しているケーブルテレビ放送事業者ＡとＢが存在した場合、視聴者が、例えばケーブルテレビ放送事業者Ａのハイブリッドキャストアプリを起動可能なアプリをインストールしたスマートフォンを持って、ケーブルテレビ放送事業者Ｂの放送エリアに移動してアプリの外部起動を実行した場合に、事業者Ｂの放送サービスに事業者Ａのハイブリッドキャストアプリが起動されてしまうことが起こり得る。つまり、放送サービスとハイブリッドキャストアプリの整合性が担保されないという問題が生じる。

【0011】

本発明は、上記の課題認識に基づいて行なわれたものであり、同一のオリジナルネットワークＩＤ、トランスポートストリームＩＤ、およびサービスＩＤの値の組み合わせを用いる複数の放送事業者が存在する場合にも、ハイブリッドキャストアプリの外部起動の際に、放送サービスとハイブリッドキャストアプリとの間の整合性を保証することのできる端末装置およびプログラムを提供しようとするものである。

【課題を解決するための手段】

【0012】

［１］上記の課題を解決するため、本発明の一態様による端末装置は、放送を受信する受信機から、前記受信機が受信可能な編成チャンネルの名称である編成サービス名を含む編成チャンネル情報を取得する編成チャンネル情報取得部と、予め特定の編成サービス名を記憶する記憶部と、前記特定の編成サービス名に関連付けられるプログラムの起動要求を前記受信機に対して行う機能を持つ起動要求部と、前記記憶部が記憶する前記特定の編成サービス名が、前記編成チャンネル情報取得部が前記受信機から取得した前記編成チャンネル情報に含まれるか否かを判定するとともに、この判定結果に基づいて前記起動要求部が前記プログラムの起動要求を行うか否かを制御する判定部とを備える端末装置である。

【0013】

［２］また、本発明の一態様は、上記の端末装置において、前記判定部は、前記特定の編成サービス名が前記受信機から取得された前記編成チャンネル情報に含まれる場合には前記プログラムの起動要求を行うよう前記起動要求部を制御し、前記特定の編成サービス名が前記受信機から取得された前記編成チャンネル情報に含まれない場合には前記プログラムの起動要求を行わないよう前記起動要求部を制御するものである。

【0014】

［３］また、本発明の一態様は、上記の端末装置において、編成チャンネル情報取得部は、ハイブリッドキャスト対応受信機の「channels」のアプリケーションプログラムインターフェースを呼び出すことにより、前記編成チャンネル情報を取得するものである。

【0015】

［４］また、本発明の一態様は、コンピューターを、上記の［１］から［３］までのいずれかに記載の端末装置、として機能させるためのプログラムである。

【発明の効果】

【0016】

本発明によれば、同一のオリジナルネットワークＩＤ、トランスポートストリームＩＤ、およびサービスＩＤの値の組み合わせを用いる複数の放送事業者が存在する場合にも、ハイブリッドキャストアプリの外部起動の際に、放送サービスとハイブリッドキャストアプリとの間の整合性を保証することができる。

【0017】

また、そのような整合性を確保するために、既存のハイブリッドキャストアプリの起動手順における、起動の可否判定の運用を変更する必要がない。したがって、放送事業者の独立性を担保しながらシステムを運用することが可能となる。

【図面の簡単な説明】

【0018】

【図1】本発明の実施形態による端末装置の概略機能構成を示すブロック図である。

【図2】同実施形態による端末装置および受信機を含むシステムの構成を示すブロック図である。

【図3】同実施形態における、端末装置と受信機との間のやりとりの手順を示すシーケンス図である。

【図4】同実施形態による端末装置がハイブリッドキャストアプリの起動を要求するための処理の手順を示すフローチャートである。

【図5】同実施形態による端末装置の編成チャンネル情報取得部が、受信機側から取得するデータ（編成チャンネル情報）の構成例を示す概略図である。

【発明を実施するための形態】

【0019】

次に、本発明の一実施形態について、図面を参照しながら説明する。本実施形態では、端末装置１は、受信機２に対してハイブリッドキャストアプリの起動を要求する前に、受信機２から編成チャンネルに関する情報を取得する。端末装置１が取得する情報は、受信機２が受信可能なすべての編成チャンネルに関する編成サービス名（文字列）のリストの情報を含む。端末装置１は、受信機２から取得した編成サービス名のリスト内に、予め記憶しておいた目的の編成サービス名が含まれるか否かを判定する。端末装置１が予め記憶しておいた編成サービス名とは、起動しようとするハイブリッドキャストアプリに対応付けられる編成チャンネルの編成サービス名である。目的の編成サービス名が取得したリスト内に含まれていれば、端末装置１は、そのまま、当該ハイブリッドキャストアプリの起動を、受信機２に対して要求する。目的の編成サービス名が取得したリスト内に含まれていなければ、端末装置１は、当該ハイブリッドキャストアプリの起動の要求を行わない（中止する）。これにより、たまたま放送資源の特定情報（オリジナルネットワーク識別子、トランスポートストリーム識別子、サービス識別子）が一致していても、整合しないハイブリッドキャストアプリを起動してしまうことを防ぐことができる。

【0020】

本実施形態で使用する用語について、ここで説明する。「アプリ」とは、アプリケーションプログラムを意味する。「アプリ」を単に「プログラム」と呼んでもよい。端末装置上で稼働し、受信機と連携するための処理を行うアプリケーションプログラムは、「コンパニオンアプリケーション」あるいは「コンパニオンアプリ」と呼ばれる場合もある。「ハイブリッドキャスト」（Hybridcast）とは、放送と通信とを連携させる方式、システムの呼び名である。「ＡＩＴ」は、ハイブリッドキャストにおいて用いられるアプリケーション情報テーブル（Application Information Table）を意味する。「ＰＣ」は、パーソナルコンピューターの略である。「ＬＡＮ」は、ローカルエリアネットワーク（Local Area Network）の略である。「ＵＲＬ」は、ユニフォームリソースロケーター（Uniform Resource Locator）の略である。「ＨＴＴＰ」は、ハイパーテキスト転送プロトコル（Hyper-text Transfer Protocol）の略である。「ＤＢＭＳ」は、データベース管理システム（Database Management System）を意味する。「ＪＳＯＮ」(JavaScript Object Notation)は、テキストを用いたデータ（オブジェクト）の記法である（なお、「JavaScript」は登録商標）。

【0021】

図１は、本実施形態による端末装置の機能構成を示すブロック図である。図示するように、端末装置１は、通信部１１と、認証部１２と、記憶部１４と、編成チャンネル情報取得部１５と、判定部１６と、起動要求部１８とを含んで構成される。これらの各機能部は、例えば、コンピューターと、プログラムとで実現することが可能である。また、各機能部は、必要に応じて、記憶手段を有する。記憶手段は、例えば、プログラム上の変数や、プログラムの実行によりアロケーションされるメモリーである。また、必要に応じて、磁気ハードディスク装置やソリッドステートドライブ（ＳＳＤ）といった不揮発性の記憶手段を用いるようにしてもよい。また、各機能部の少なくとも一部の機能を、プログラムではなく専用の電子回路として実現してもよい。

【0022】

端末装置１は、端末装置１と連携する受信機（テレビ放送を受信するテレビ受像機）上で、特定の編成チャンネルに関連付けられたハイブリッドキャストアプリを起動する機能を持つ。端末装置１は、この受信機上でハイブリッドキャストアプリを起動する機能を、例えば、アプリの機能として実現する。このアプリは、端末装置１上のプログラム実行環境（プロセッサーおよびメモリー等）において稼働する。図１に示す各部の機能は、次の通りである。

【0023】

通信部１１は、外部との通信を行う機能を有する。通信部１１は、例えば、インターネットプロトコル（ＩＰ）による通信を実現する。通信部１１は、有線または無線の通信手段を用いて、インターネットを介した、外部の装置との通信を可能にする。また、通信部１１は、無線ＬＡＮ等の近距離通信手段を用いて、後述するように、受信機２と相互に通信し、連携動作を可能とする。通信部１１は、上位の機能である、認証部１２や、編成チャンネル情報取得部１５や、起動要求部１８からの要求に応じて、通信を行う。

【0024】

認証部１２は、受信機２との間の通信により、端末装置１と受信機２との間の認証を行う。認証部１２が、無線ＬＡＮ等の通信手段を用いて発見される受信機２との間の認証を行うことにより、端末装置１と受信機２とはペアリングされる。

【0025】

記憶部１４は、データを記憶する。記憶部１４は、特に、受信機上で起動するハイブリッドキャストアプリが関連付けられる編成チャンネルの編成サービス名を記憶する。つまり、記憶部１４は、予め、特定の編成サービス名を記憶するものである。記憶部１４内において、上記の編成サービス名が記憶される場所は、具体的には、例えば、半導体メモリー上であってもよいし、磁気ディスク装置上であってもよい。また、上記の編成サービス名が記憶される場所は、プログラムから直接アクセス可能なメモリー空間上であってもよいし、ファイルシステム上のファイル内であってもよいし、データベース管理システム（ＤＢＭＳ）等によって管理されるデータベース内であってもよい。また、上記の編成サービス名が記憶される場所は、例えば、プログラム内の変数に割り当てられるデータ領域であってもよいし、プログラム内の定数の領域であってもよいし、プログラムコードそのものの中の所定の領域であってもよい。

【0026】

編成チャンネル情報取得部１５は、放送を受信する受信機２から、前記受信機２が受信可能な編成チャンネルの名称である編成サービス名を含む編成チャンネル情報を取得する。編成チャンネル情報取得部１５は、通信を介して、受信機２から、編成チャンネル情報を取得する。編成チャンネル情報取得部１５は、後述する所定のＡＰＩ（アプリケーションプログラムインターフェース）を呼び出すことにより、上記の編成チャンネル情報を取得する。編成チャンネル情報は、受信機２が受信可能な編成チャンネルに関する情報である。編成チャンネル情報は、受信機２が受信可能な編成チャンネルの編成サービス名のデータを含むものである。編成チャンネル情報取得部１５が受信機２から取得する編成チャンネル情報の構成例については、後で、図５を参照しながら説明する。

【0027】

判定部１６は、記憶部１４が記憶する特定の編成サービス名が、編成チャンネル情報取得部１５が受信機２から取得した編成チャンネル情報に含まれるか否かを判定するとともに、この判定結果に基づいて起動要求部１８がプログラムの起動要求を行うか否かを制御する。より具体的には、判定部１６は、前記特定の編成サービス名が受信機２から取得された編成チャンネル情報に含まれる場合にはプログラムの起動要求を行うよう起動要求部１８を制御する。また、判定部１６は、前記特定の編成サービス名が受信機２から取得された編成チャンネル情報に含まれない場合にはプログラムの起動要求を行わないよう起動要求部１８を制御する。

【0028】

言い換えれば、判定部１６は、予め記憶部１４が記憶していた編成サービス名が、受信機２から取得された編成チャンネル情報内に含まれているか否かを判定する。判定部１６は、判定結果に基づき、受信機２に対してハイブリッドキャストアプリの起動を要求するか否かを制御する。記憶部１４が記憶していた編成サービス名が、受信機２から取得された編成チャンネル情報内に含まれていた場合には、当該編成サービス名に関連付けられるハイブリッドキャストの起動要求を実行するように、判定部１６は制御する。記憶部１４が記憶していた編成サービス名が、受信機２から取得された編成チャンネル情報内に含まれていなかった場合には、当該編成サービス名に関連付けられるハイブリッドキャストの起動要求を行わない（中止する）ように、判定部１６は制御する。

【0029】

起動要求部１８は、特定の編成サービス名に関連付けられるプログラムの起動要求を受信機２に対して行う機能を持つ。具体的には、起動要求部１８は、特定のハイブリッドキャストアプリの起動を、受信機２に対して要求する。ただし、上記の判定部１６の判定結果に応じて、起動要求部１８が受信機２に対するハイブリッドキャストアプリの起動要求を中止する場合もある。つまり、起動要求部１８がハイブリッドキャストアプリの起動要求を実行するか否かは、判定部１６による判定結果およびその判定結果に基づく制御に依存する。

【0030】

図２は、本実施形態によるシステムの構成を示すブロック図である。図示するように、システム１００は、端末装置１と、受信機２と、放送送出装置３と、可否判定サーバー装置４と、サービスサーバー装置５とを含んで構成される。システム１００内において、端末装置１と受信機２とは、例えば、無線ＬＡＮ等の近距離通信手段によって相互に通信可能である。端末装置１と受信機２とは、相互に通信しながら連携動作することができる。
また、端末装置１と、受信機２と、可否判定サーバー装置４と、サービスサーバー装置５とは、それぞれ、インターネット９等の通信ネットワークに接続される。端末装置１と、受信機２と、可否判定サーバー装置４と、サービスサーバー装置５とは、この通信ネットワークを介して、相互に通信を行うことができる。また、放送送出装置３は、放送信号を送出する。放送信号は、空中（空間）や、金属ケーブルや、光ケーブル等の伝送媒体によって伝送され得る。受信機２は、放送送出装置３から送出される放送信号を、受信し、復調し、復号することができる。

【0031】

図２に示す装置のうち、放送送出装置３と、可否判定サーバー装置４と、サービスサーバー装置５とは、放送事業者等によって運営される装置である。また、端末装置１と、受信機２とは、一般ユーザー（放送視聴者等）が保持し、使用する装置である。

【0032】

端末装置１は、無線ＬＡＮ等の通信手段を介して、受信機２との間で通信を行う。端末装置１は、受信機２と連携動作することができる。端末装置１は、アプリを稼働させるための稼働環境を備える。端末装置１は、例えばアプリの機能により、受信機２上で稼働するハイブリッドキャストアプリの起動を、受信機２に対して要求することができる。端末装置１は、必要に応じて、アプリのコードや、アプリが利用するデータ（コンテンツ等）等を、サービスサーバー装置５から受け取ることができる。なお、端末装置１は、具体的には例えば、スマートフォンや、タブレット型端末装置や、ウェアラブル端末装置や、ＰＣ等を用いて実現される。

【0033】

受信機２は、テレビ放送を受信する装置である。受信機２は、放送送出装置３から送出される放送信号を受信し、放送信号から映像や音声等のコンテンツを抽出してユーザーに提示する。受信機２は、ハイブリッドキャストに対応する機能を有する。つまり、受信機２は、ハイブリッドキャストアプリを稼働させるためのアプリ稼働環境を持つ。また、受信機２は、インターネット９を介して、可否判定サーバー装置４やサービスサーバー装置５との間で通信を行う。また、受信機２は、無線ＬＡＮ等の通信手段を介して、端末装置１との間で通信を行い、連携動作することができる。

【0034】

放送送出装置３は、放送信号を送出する装置である。

【0035】

可否判定サーバー装置４は、インターネット９を介して、受信機２からの問い合わせを受信し、その問い合わせに対する判定結果を受信機２に送信する。具体的には次の通りである。可否判定サーバー装置４が受信する問い合わせは、放送の編成サービスを識別するための識別情報と、受信機２上で稼働するハイブリッドキャストアプリのＡＩＴの所在を表すＵＲＬとを含む。可否判定サーバー装置４は、編成サービスを識別する識別情報と、ＡＩＴの所在を示すＵＲＬとが整合しているか否かを判定する。即ち、可否判定サーバー装置４は、指定されたハイブリッドキャストアプリを受信機２上で起動することができるか否かを判定する。可否判定サーバー装置４は、判定結果である起動可否の情報を、応答として、受信機２に送信する。

【0036】

サービスサーバー装置５は、インターネット９を介して、ハイブリッドキャストのＡＩＴや、アプリ本体（アプリの実行コード等）や、アプリが利用するコンテンツ等のデータを、端末装置１や受信機２に対して配信する。

【0037】

インターネット９は、通信ネットワークである。インターネット９上では、例えば、インターネットプロトコルを用いた通信が行われる。端末装置１と、サービスサーバー装置５との間では、インターネット９を介した通信を行うことができる。また、受信機２と、可否判定サーバー装置４およびサービスサーバー装置５との間では、インターネット９を介した通信を行うことができる。

【0038】

図３は、端末装置１と受信機２との間のやりとりの手順を示すシーケンス図である。ここに示す手順では、端末装置１から、受信機２上でのハイブリッドキャストアプリの起動を要求する。以下、このシーケンスに沿ってステップごとに説明する。

【0039】

まず、ステップＳ１において、端末装置１と受信機２との間でのペアリングを行う。本ステップにおけるペアリングは、規格「ＩＰＴＶ規定 ハイブリッドキャスト運用規定
ＩＰＴＶＦＪ ＳＴＤ－００１３ ２．７版」の７．２．２節に規定された端末認証の方法によるものである。

【0040】

次に、ステップＳ２において、端末装置１は、受信機２から、編成チャンネル情報を取得する。本ステップの処理は、端末装置１が、規格「ＩＰＴＶ規定 ハイブリッドキャスト運用規定 ＩＰＴＶＦＪ ＳＴＤ－００１３ ２．７版」の７．２．３．２．３．２．２節「編成チャンネル情報の取得」に規定されたＡＰＩ「channels」を呼び出すことによって行われる。なお、ＡＰＩ「channels」を呼び出すためのＵＲＬは、「<BaseURL>/channels」である。ここで、「<BaseURL>」は、基底となるＵＲＬである。上記ＡＰＩを呼び出すことにより、端末装置１は、ＪＳＯＮデータ構造を取得する。端末装置１が取得するＪＳＯＮデータ構造は、その受信機２が受信することのできるすべての編成サービスの情報を含む。編成サービスの情報は、各編成サービスの、オリジナルネットワーク識別子（original_network_id）と、トランスポートストリーム識別子（transport_stream_id）と、サービス識別子（service_id）と、編成サービス名（broadcast_channel_name）とを含む。編成サービス名は、編成サービス（チャンネル）の名称を表す文字列である。この編成サービス名により、端末装置１は、事業者（ケーブルテレビ事業者等）を把握することができる。なお受信機２が端末装置１に対して返却するbroadcast_channel_nameの値は、規格「ＡＲＩＢＴＲ－Ｂ１４ 第四編 地上デジタルテレビジョン放送 ＰＳＩ／ＳＩ運用規定」３０．４.２．１節に規定されているnetwork_name_descriptorに記述する放送局名に相当する文字列に対応するものである。地上デジタル放送ネットワークにおけるケーブルテレビ事業者の自主放送の場合には、編成サービス名を、ＮＩＴのＴＳ情報記述子内のts_name_char（ＴＳ名）とＳＤＴのロゴ伝送記述子内のlogo_id値としてよい。

【0041】

次に、ステップＳ３において、端末装置１は、編成サービス名に関する判定処理を行う。具体的には、端末装置１は、予め記憶しておいた特定の編成サービス名が、ステップＳ２で取得したＪＳＯＮデータ構造内に含まれる編成サービス名であるか否かを判定する。
予め記憶しておいた特定の編成サービス名がステップＳ２で取得したデータ内に含まれる場合には、端末装置１は、当該編成サービスに関連付けられたハイブリッドキャストアプリの起動要求を行う。その他の場合（予め記憶しておいた特定の編成サービス名がステップＳ２で取得したデータ内に含まれない場合）には、端末装置１は、ハイブリッドキャストアプリの起動要求を行わない。

【0042】

ステップＳ３での判定の結果、ハイブリッドキャストアプリの起動要求を行う場合にのみ、端末装置１は、次のステップＳ４の処理を行う。即ち、ステップＳ４において、端末装置１は、受信機２に対して、ハイブリッドキャストアプリの起動要求を行う。この起動要求は、規格「ＩＰＴＶ規定 ハイブリッドキャスト運用規定 ＩＰＴＶＦＪ ＳＴＤ－００１３ ２．７版」の７．２．３．２．３．３．１節「起動要求」に規定されたＡＰＩ「hybridcast」を呼び出すことにより行われるものである。なお、ＡＰＩ「hybridcast」を呼び出すためのＵＲＬは、「<BaseURL>/ hybridcast」である。ここで、「<BaseURL>」は、基底となるＵＲＬである。このＡＰＩを呼び出す際に、端末装置１は、規定されたＪＳＯＮデータ構造を渡す。そのＪＳＯＮデータ構造は、編成サービスの、オリジナルネットワーク識別子（original_network_id）と、トランスポートストリーム識別子（transport_stream_id）と、サービス識別子（service_id）とを含む。また、そのＪＳＯＮデータ構造は、実行対象となるハイブリッドキャストアプリのＸＭＬ－ＡＰＩのＵＲＬと、事業者ＩＤと、アプリＩＤとを含む。このＪＳＯＮデータ構造の情報を受信した受信機２は、可否判定サーバー装置４への問い合わせを行うことにより、編成サービスを識別する情報と、ハイブリッドキャストアプリを特定する情報（具体的には、例えば、上記のＸＭＬ－ＡＰＩのＵＲＬ）との整合性を確認する。つまり、編成サービスとアプリとが整合していれば受信機２は当該ハイブリッドキャストアプリを起動する。逆に、編成サービスとアプリとが整合していなければ受信機２は当該ハイブリッドキャストアプリを起動しない。なお、このステップＳ４の処理自体は、既存技術を用いて行い得るものである。

【0043】

図４は、端末装置１による処理の手順を示すフローチャートである。以下、このフローチャートに沿って説明する。なお、端末装置１の記憶部１４は、予め、自装置（自アプリ）が選局すべき放送の編成サービス名を記憶している。記憶部１４が記憶している編成サービス名は、編成チャンネル情報取得のＡＰＩ「channels」で取得される編成サービス名（broadcast_channel_name）に対応するものである。このＡＰＩ「channels」については、規格「ＩＰＴＶ規定 ハイブリッドキャスト運用規定 ＩＰＴＶＦＪ ＳＴＤ－００１３ ２．７版」の７．２．３．２．３．２．２節「編成チャンネル情報の取得」に規定されている。

【0044】

ステップＳ２１において、端末装置１の認証部１２は、受信機２との間での端末認証を行う。これにより、端末装置１と受信機２とがペアリングされる。

【0045】

次に、ステップＳ２２において、端末装置１の編成チャンネル情報取得部１５は、編成チャンネル情報を取得するためのＡＰＩを呼び出すことにより、ステップＳ２１でペアリングした相手の受信機２から、編成チャンネル情報を取得する。

【0046】

次に、ステップＳ２３において、端末装置１の編成チャンネル情報取得部１５は、ステップＳ２２において取得した編成チャンネル情報から、編成サービス名のリストを抽出する。ここで抽出された編成サービス名のリストは、受信機２が受信することのできるすべての編成チャンネルの編成サービス名を含む。

【0047】

次に、ステップＳ２４において、端末装置１の判定部１６は、ステップＳ２３で抽出された編成サービス名（つまり、受信機２側から取得した編成サービス名）のリスト内に、予め記憶部１４が記憶していた編成サービス名と等しいものが含まれるか否かを判定する。含まれていた場合（ステップＳ２４：ＹＥＳ）には、次のステップＳ２５の処理に移る。含まれていなかった場合（ステップＳ２４：ＮＯ）には、次のステップＳ２５の処理をスキップし、本フローチャート全体の処理を終了する。

【0048】

受信機２から取得した編成サービス名のリスト内に、記憶部１４が記憶する編成サービス名と等しいものが含まれている場合（ステップＳ２４：ＹＥＳ）は、目的とするハイブリッドキャストアプリをその受信機２で起動してもよいことを意味する。受信機２から取得した編成サービス名のリスト内に、記憶部１４が記憶する編成サービス名と等しいものが含まれていない場合（ステップＳ２４：ＮＯ）は、目的とするハイブリッドキャストアプリをその受信機２で起動することは不適切であることを意味する。しかしながら、この「ステップＳ２４：ＮＯ」の場合にも、端末装置１の起動要求部１８が当該ハイブリッドキャストアプリの起動要求のＡＰＩを呼び出してしまうと、放送のリソースを特定する情報（オリジナルネットワーク識別子、トランスポートストリーム識別子、サービス識別子）がたまたま一致していると、ハイブリッドキャストアプリが起動されてしまうことが起こり得る。即ち、放送の編成チャンネルと、ハイブリッドキャストアプリの内容とが整合しない状況が生じてしまう可能性がある。ステップＳ２４での判定に基づく分岐は、そのような不整合を防止する。

【0049】

次に、ステップＳ２５に進んだ場合、端末装置１の起動要求部１８は、ハイブリッドキャストアプリの起動要求のＡＰＩ「hybridcast」を呼び出す。これに応じて、受信機２側では、可否判定サーバー装置４に対して可否判定の問い合わせを行う。可否判定の問い合わせは、放送リソースを識別する情報（オリジナルネットワーク識別子、トランスポートストリーム識別子、サービス識別子）と、ハイブリッドキャストアプリのＡＩＴのＵＲＬとの組み合わせが、合っているか否かを確認するものである。可否判定サーバー装置４が受信機２に肯定的な応答を返した場合には、受信機２は、指定されたハイブリッドキャストを起動する。また、受信機２は、その編成サービスを選局する。可否判定サーバー装置４が受信機２に否定的な応答を返した場合には、受信機２は、ハイブリッドキャストアプリの起動を中止する。

【0050】

図５は、編成チャンネル情報取得のＡＰＩ「channels」を呼び出すことにより端末装置１の編成チャンネル情報取得部１５が取得するデータの構成例を示す概略図である。図３のステップＳ２、図４のステップＳ２２の手順により、編成チャンネル情報取得部１５は、この図５に示すデータを取得する。

【0051】

図５に示すデータは、ＪＳＯＮ形式で記述されたデータである。このデータは、ブロック構造を有するテキストで表現される。このデータにおいて、左および右の中括弧（カーリーブレース）が、それぞれ、ブロックの始まりおよび終わりを表す。なお、左および右の大括弧（ブラケット、角括弧）は、配列要素の列挙の始まりおよび終わりを表す。なお、同図では、参照のための行番号を付している。

【0052】

第１行目の左の中括弧は、本データ全体の始まりを示す。第１行目の左の中括弧は、第３４行目の右の中括弧に対応する。

【0053】

第２行目から第５行目までは、要素「ｈｅａｄ」である。要素「ｈｅａｄ」は、ＨＴＴＰステータスラインの情報を含むオブジェクトである。要素「ｈｅａｄ」は、要素「ｃｏｄｅ」と要素「ｍｅｓｓａｇｅ」とを含む。要素「ｃｏｄｅ」は、ＨＴＴＰステータスコードである。要素「ｃｏｄｅ」の値「２００」は、ＡＰＩ呼び出しが正常に終了したことを示す。要素「ｍｅｓｓａｇｅ」の値「ＯＫ」は、上記ＨＴＴＰステータスコードの説明句である。

【0054】

第６行目から第３３行目までは、要素「ｂｏｄｙ」である。要素「ｂｏｄｙ」は、ＡＰＩ呼び出しに応じて返されるデータを持つオブジェクトである。要素「ｂｏｄｙ」は、要素「ｃｒｅａｔｅｄ＿ａｔ」と、要素「ｍｅｄｉａ」とを含む。

【0055】

第７行目は、要素「ｃｒｅａｔｅｄ＿ａｔ」を表す。要素「ｃｒｅａｔｅｄ＿ａｔ」は、当該情報を受信機２が応答した日時を表す。要素「ｃｒｅａｔｅｄ＿ａｔ」の値は、協定世界時（ＵＴＣ）の「ＹＹＹＹ－ＭＭ－ＤＤＴｈｈ：ｍｍ：ｓｓＺ」（年・月・日、時・分・秒）の形式で表わされる。この要素「ｃｒｅａｔｅｄ＿ａｔ」の値は、「２０２０－０１－０１Ｔ０９：００：００Ｚ」であり、「２０２０年１月１日９時０分０秒（協定世界時）」を表す。

【0056】

第８行目から第３２行目までは、要素「ｍｅｄｉａ」をあらわす。要素「ｍｅｄｉａ」は配列である。本図に示す例では、この配列の要素は１つだけである。第９行目から第３１行目までが、その配列要素である。この要素は、要素「ｔｙｐｅ」と、要素「ｃｈａｎｎｅｌｓ」とを含む。要素「ｔｙｐｅ」は、メディアの種別を表す。言い換えれば、要素「ｔｙｐｅ」は、当該データがどの種別のメディアのチャンネル情報であるかを表す文字列である。要素「ｔｙｐｅ」は、「ＴＤ」（地上デジタルを表す）、「ＢＳ」（ＢＳ（放送衛星）を表す）、「ＣＳ」（ＣＳ（通信衛星）を表す）といった値を取り得る。第１０行目における「ｔｙｐｅ」の値は「ＴＤ」である。第１１行目から第３０行目までは要素「ｃｈａｎｎｅｌｓ」である。この第１１行目から第３０行目までの要素「ｃｈａｎｎｅｌｓ」は、第１０行目の要素「ｔｙｐｅ」に対応する。つまり、第１１行目から第３０行目までの要素「ｃｈａｎｎｅｌｓ」は、「ＴＤ」（地上デジタル）に属する複数の編成チャンネルの情報を表す配列である。

【0057】

第１１行目から第３０行目までの配列は、２つの要素を持つ。第１２行目から第２０行目までの第１要素と、第２１行目から第２９行目までの第２要素である。これらの各要素が、編成チャンネルに対応する。ここでは、便宜的に、符号を用いて表し、第１要素の内容をブロック９０１として、第２要素の内容をブロック９０２としている。ブロック９０１および９０２のそれぞれは、要素「ｌｏｇｉｃａｌ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ」と、要素「ｒｅｓｏｕｒｃｅ」と、要素「ｂｒｏａｄｃａｓｔ＿ｃｈａｎｎｅｌ＿ｎａｍｅ」とを持つ。このうち、要素「ｒｅｓｏｕｒｃｅ」は、さらに、要素「ｏｒｉｇｉｎａｌ＿ｎｅｔｗｏｒｋ＿ｉｄ」と、要素「ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄ」と、要素「ｓｅｒｖｉｃｅ＿ｉｄ」とを持つオブジェクトである。

【0058】

要素「ｌｏｇｉｃａｌ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ」は、編成チャンネルに割り当てられる論理チャンネル番号を表す文字列である。
要素「ｏｒｉｇｉｎａｌ＿ｎｅｔｗｏｒｋ＿ｉｄ」は、オリジナルネットワーク識別子を表す整数値（０以上且つ６５５３５以下）である。
要素「ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄ」は、トランスポートストリーム識別子を表す整数値（０以上且つ６５５３５以下）である。
要素「ｓｅｒｖｉｃｅ＿ｉｄ」は、サービス識別子を表す整数値（０以上且つ６５５３５以下）である。
要素「ｂｒｏａｄｃａｓｔ＿ｃｈａｎｎｅｌ＿ｎａｍｅ」は、編成サービス名を表す文字列である。

【0059】

ブロック９０１に関しては、各要素の値は、次の通りである。
要素「ｌｏｇｉｃａｌ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ」の値は、「０１１」である。
要素「ｏｒｉｇｉｎａｌ＿ｎｅｔｗｏｒｋ＿ｉｄ」の値は、３２７３６である。
要素「ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄ」の値は、３２７３６である。
要素「ｓｅｒｖｉｃｅ＿ｉｄ」の値は、１０２４である。
要素「ｂｒｏａｄｃａｓｔ＿ｃｈａｎｎｅｌ＿ｎａｍｅ」の値は、「総合ＴＶ東京」である。

【0060】

ブロック９０２に関しては、各要素の値は、次の通りである。
要素「ｌｏｇｉｃａｌ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒ」の値は、「１０１」である。
要素「ｏｒｉｇｉｎａｌ＿ｎｅｔｗｏｒｋ＿ｉｄ」の値は、３２３９９である。
要素「ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄ」の値は、３２３９９である。
要素「ｓｅｒｖｉｃｅ＿ｉｄ」の値は、２３６７２である。
要素「ｂｒｏａｄｃａｓｔ＿ｃｈａｎｎｅｌ＿ｎａｍｅ」の値は、「渋谷ケーブルＴＶ」である。

【0061】

なお、図５に例示したデータは、要素「ｔｙｐｅ」が「ＴＤ」である複数のチャンネルの情報のみを持つものであった。端末装置１が編成チャンネル情報として取得するデータが、他のメディア種別（「ＢＳ」や「ＣＳ」）の情報を持つものであってもよい。

【0062】

本実施形態における端末装置１の判定部１６が判定のために用いる情報は、図５に示したデータの中の、各チャンネルの編成サービス名（ｂｒｏａｄｃａｓｔ＿ｃｈａｎｎｅｌ＿ｎａｍｅ）の情報である。図４のステップＳ２３で説明したように、編成チャンネル情報取得部１５は、取得された編成チャンネル情報から、編成サービス名のリストを抽出する。つまり、編成チャンネル情報取得部１５が例えば図５のデータを編成チャンネル情報として取得した場合、編成チャンネル情報取得部１５は、その第１９行目および第２８行目の、それぞれ要素「ｂｒｏａｄｃａｓｔ＿ｃｈａｎｎｅｌ＿ｎａｍｅ」を抽出する。そして、編成チャンネル情報取得部１５は、この場合、２つの編成サービス名から成る「（“総合ＴＶ東京”，“渋谷ケーブルＴＶ”）」というリストを作成する。このように作成されたリストは、図４のステップＳ２４で説明した判定処理に用いられる。例えば、記憶部１４が記憶する編成サービス名が「渋谷ケーブルＴＶ」である場合、作成されたリスト「（“総合ＴＶ東京”，“渋谷ケーブルＴＶ”）」内に「渋谷ケーブルＴＶ」が含まれるため、端末装置１は、判定結果に基づき、ハイブリッドキャストアプリの起動を要求するＡＰＩ呼び出しを実行することとなる。あるいは、例えば、記憶部１４が記憶する編成サービス名が「江戸川コミュニティチャンネル」である場合、作成されたリスト「（“総合ＴＶ東京”，“渋谷ケーブルＴＶ”）」内に「江戸川コミュニティチャンネル」が含まれないため、端末装置１は、判定結果に基づき、ハイブリッドキャストアプリの起動の要求を行わない（抑止する）。

【0063】

以上説明したように、本実施形態によると、放送資源を特定する情報（例えば、オリジナルネットワーク識別子、トランスポートストリーム識別子、サービス識別子の組み合わせ）がたまたま一致してしまう状況においても、編成サービスと整合しない不適切なアプリの起動を抑止できる。つまり、本実施形態によると、放送事業者の独立性を確保することができる。また、本実施形態によると、上記のような不適切なアプリの起動を抑止するために、既存の手順（可否判定サーバー装置への問い合わせの手順）を変更する必要がない。つまり、可否判定サービスに関する既存の規格を変更する必要がない。

【0064】

なお、上述した実施形態における端末装置や、受信機や、可否判定サーバー装置等の少なくとも一部の機能をコンピューターで実現することができる。その場合、この機能を実現するためのプログラムをコンピューター読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピューターシステムに読み込ませ、実行することによって実現しても良い。なお、ここでいう「コンピューターシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピューター読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、ＵＳＢメモリー等の可搬媒体、コンピューターシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピューター読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、一時的に、動的にプログラムを保持するもの、その場合のサーバーやクライアントとなるコンピューターシステム内部の揮発性メモリーのように、一定時間プログラムを保持しているものも含んでも良い。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピューターシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。

【0065】

以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

【産業上の利用可能性】

【0066】

本発明は、例えば、放送受信機と連携動作する端末装置等の機器に関する産業や、端末装置上で稼働するアプリを製造、販売、あるいは配信する産業や、ハイブリッドキャストのシステムを利用したコンテンツを配信するコンテンツ提供産業等（放送事業を含む）に利用することができる。但し、本発明の利用範囲はここに例示したものには限られない。

【符号の説明】

【0067】

１ 端末装置
２ 受信機
３ 放送送出装置
４ 可否判定サーバー装置
５ サービスサーバー装置
９ インターネット
１１ 通信部
１２ 認証部
１４ 記憶部
１５ 編成チャンネル情報取得部
１６ 判定部
１８ 起動要求部
１００ システム

【図1】

【図2】

【図3】

【図4】

【図5】