特開 2023-172942 受信装置およびプログラム

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023172942

(43)【公開日】2023-12-06

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

(51)【国際特許分類】

   H04N 21/435 20110101AFI20231129BHJP

   H04N 21/442 20110101ALI20231129BHJP

【ＦＩ】

H04N21/435

H04N21/442

【審査請求】未請求

【請求項の数】4

【出願形態】ＯＬ

(21)【出願番号】P 2023084136

(22)【出願日】2023-05-22

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

(32)【優先日】2022-05-23

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

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

(32)【優先日】2022-10-04

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

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＪＡＶＡＳＣＲＩＰＴ

(71)【出願人】

【識別番号】000004352

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

(74)【代理人】

【識別番号】100141139

【弁理士】

【氏名又は名称】及川 周

(74)【代理人】

【識別番号】100171446

【弁理士】

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

(74)【代理人】

【識別番号】100114937

【弁理士】

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

(74)【代理人】

【識別番号】100171930

【弁理士】

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

(72)【発明者】

【氏名】遠藤 大礎

(72)【発明者】

【氏名】松村 欣司

(72)【発明者】

【氏名】藤沢 寛

(72)【発明者】

【氏名】大亦 寿之

【テーマコード（参考）】

5C164

【Ｆターム（参考）】

5C164FA11

5C164TA14S

5C164UB10P

5C164UB41P

5C164YA21

5C164YA24

(57)【要約】

【課題】放送サービスあるいはインターネット等でのネット配信サービスに関するサービス情報を取得して自装置の抽象サービスの設定を行える受信装置を提供する。
【解決手段】受信装置が、放送信号が受信可能であるか否かを判定する放送受信可否判定部と、通信ネットワークを介した通信が可能であるか否かを判定する通信可否判定部と、受信した放送信号から放送サービスについてのサービス情報を取得する放送サービス情報取得部と、ネット配信サービスについてのサービス情報を外部のサーバー装置から前記通信ネットワークを介して取得するネット配信サービス情報取得部と、所定の関係を有する複数の具体サービスのそれぞれのサービス情報を統合して抽象サービスについてのサービス情報を生成する統合部と、を備え、前記具体サービスは、前記放送サービスまたは前記ネット配信サービスのいずれかである。
【選択図】図４

【特許請求の範囲】

【請求項1】

放送信号が受信可能であるか否かを判定する放送受信可否判定部と、
通信ネットワークを介した通信が可能であるか否かを判定する通信可否判定部と、
前記放送受信可否判定部が放送信号は受信可能であると判定した場合に、受信した放送信号から放送サービスについてのサービス情報を取得する放送サービス情報取得部と、
通信可否判定部が通信は可能であると判定した場合に、ネット配信サービスについてのサービス情報を外部のサーバー装置から前記通信ネットワークを介して取得するネット配信サービス情報取得部と、
を備え、
前記ネット配信サービス情報取得部は、取得済みの前記ネット配信サービスについてのサービス情報に関する更新タイミング情報に基づいて、外部のサーバー装置から更新用のネット配信サービスについてのサービス情報を取得し、自装置で保持する前記ネット配信サービスについてのサービス情報の更新を行う、
受信装置。

【請求項2】

前記更新タイミング情報は、取得済みの前記ネット配信サービスについてのサービス情報の有効期限の情報、または前記外部のサーバー装置が更新用のネット配信サービスについてのサービス情報の提供を開始する日時である更新日時情報、の少なくともいずれかである、
請求項１に記載の受信装置。

【請求項3】

前記ネット配信サービス情報取得部は、定められた運用ルールに基づき、複数のサービスに関するサービス情報の相互間でのデータの衝突を解決しながら、前記自装置で保持する前記ネット配信サービスについてのサービス情報の更新を行う、
請求項１に記載の受信装置。

【請求項4】

放送信号が受信可能であるか否かを判定する放送受信可否判定部と、
通信ネットワークを介した通信が可能であるか否かを判定する通信可否判定部と、
前記放送受信可否判定部が放送信号は受信可能であると判定した場合に、受信した放送信号から放送サービスについてのサービス情報を取得する放送サービス情報取得部と、
通信可否判定部が通信は可能であると判定した場合に、ネット配信サービスについてのサービス情報を外部のサーバー装置から前記通信ネットワークを介して取得するネット配信サービス情報取得部と、
を備え、
前記ネット配信サービス情報取得部は、取得済みの前記ネット配信サービスについてのサービス情報に関する更新タイミング情報に基づいて、外部のサーバー装置から更新用のネット配信サービスについてのサービス情報を取得し、自装置で保持する前記ネット配信サービスについてのサービス情報の更新を行う、
受信装置、としてコンピューターを機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

通信ネットワーク（インターネット等）を介して放送コンテンツと同一の内容を同時に配信するサービス（ネット配信）が提供され始めている。また、受信装置（テレビ受像機）として、放送信号を受信する機能とネット通信機能との両方を備え、それらのコンテンツそれぞれをユーザーに提示する機能が実装され始めている。

【0003】

特許文献１には、放送信号を受信する情報処理装置において、放送信号を利用するアプリケーションの動作を制御する情報と、そのアプリケーションの画面制御方法のタイプを示す情報とを取得し、取得したこれらの情報を基に、前記タイプごとにアプリケーションの動作を制御する技術が記載されている。この技術を用いることにより、放送外マネージドアプリケーションの画面提示制御が容易になる。また、この技術により、放送事業者（放送局）によるアプリケーションの認可が容易になる。

【0004】

特許文献２には、放送信号を受信する受信装置と連携する端末装置の技術が記載されている。端末装置は、受信装置上のアプリケーションが発行したメッセージを受信し、このメッセージに基づいてサービスアプリケーションを実行させる。また、端末装置は、ポリシーデータに基づき、受信装置側からのメッセージの送信の可否を制御する。つまり、送信可と判定されたメッセージだけが、判定された送信先に応じたアプリケーションのサービス実行部に出力される。この技術により、受信装置側のアプリケーションが連携する端末装置側のアプリケーションを制限することができる。

【0005】

非特許文献１には、放送通信連携システムの仕様が記載されている。

【0006】

非特許文献２には、放送信号を受信する受信装置上でアプリケーションを実行するための基盤となるＨＴＭＬ５ブラウザの仕様が記載されている。

【0007】

また、従来技術によるテレビ受像機は、放送サービスおよび通信サービスのそれぞれを提供するための情報を提示する機能を備えている。放送サービスに関しては、「ＩＰＴＶＦＪ ＳＴＤ－Ｂ１０ デジタル放送に仕様する番組配列情報」、「ＡＲＩＢ ＴＲ－Ｂ１４ 第七編 地上デジタルテレビジョン放送 送出運用規定」、「ＡＲＩＢ ＴＲ－Ｂ１５ 第一部 第七編 ＢＳデジタル放送 送出運用規定」、「ＡＲＩＢ ＴＲ－Ｂ１５ 第二部 第七編 広帯域ＣＳデジタル放送 送出運用規定」といった各種の技術標準あるいは規定によって、放送サービスにおける配信情報に関するメタデータが定義されている。テレビ受像機は、これらのメタデータを受信して利用することができる。一方で、通信（ネット配信）のためのアプリケーションプログラムは、独自に配信されるメタデータを受信し、ユーザーへの提示を行っている。

【0008】

従来技術において、放送事業者が放送と同じサービスを通信でも提供する場合（「ＮＨＫプラス」等のネット同時配信）には、テレビ受像機は、放送信号から取得するメタデータと、通信（インターネット等）から受信するメタデータとを、全く別の体系のデータとして扱っている。

【0009】

特許文献３、４、および５のそれぞれには、サービスのロケーション情報を解決することによって、放送とネットから提供されるコンテンツを動的に解決するための技術が記載されている。

【先行技術文献】

【特許文献】

【0010】

【特許文献1】特許第６４３２５２５号公報

【特許文献2】特開２０１８－０７８３８３号公報

【特許文献3】特開２０１６－１４９６２４号公報

【特許文献4】特開２０１６－２１２７４０号公報

【特許文献5】特許第６６９８４１５号公報

【非特許文献】

【0011】

【非特許文献1】ＩＰＴＶ規定 放送通信連携システム仕様 IPTVFJ STD-0010，２．４版，２０２２年１月２１日改定，一般社団法人ＩＰＴＶフォーラム（IPTV Forum Japan）

【非特許文献2】ＩＰＴＶ規定 ＨＴＭＬ５ブラウザ仕様 IPTVFJ STD-0011，２．７版，２０２２年１月２１日改定，一般社団法人ＩＰＴＶフォーラム（IPTV Forum Japan）

【発明の概要】

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

【0012】

しかしながら、従来技術には、次に説明するような課題がある。

【0013】

［第１の課題］
現状において、放送事業者（放送局）もコンテンツのネット配信サービスを提供し始めているが、放送信号として提供されるコンテンツとインターネット等を用いて配信されるコンテンツとを相互に関連付けるシステムは存在していない。つまり、ユーザーは、コンテンツを受信し視聴するためのデバイスやアプリケーションプログラムを、放送用とネット配信用とで切り替えて使用する必要がある。

【0014】

また、一方で、放送信号は、超短波帯以上の電波や、地域ごとのケーブルテレビのサービスを用いて配信される。つまり、放送信号を受信できる地域は限定される。これに対して、インターネットでの通信には基本的には地域に関する限定がない。言い換えれば、ネット配信では、放送信号の到達範囲（サービスエリア)と関連付けた通信制御は行われていなかった。つまり、放送信号の受信状況をネット配信のサービスに反映させるためのしくみがなかった。

【0015】

［第２の課題］
従来の技術においては、放送とネット配信との両方で同一（同等）のコンテンツが提供されている場合においても、テレビ受像機はそれら両者のサービス情報を関連付けて管理していない。したがって、テレビ受像機における通信（インターネット等のネットワークを介した通信）が不可能になった状況（通信断など）においては、ユーザーは、視聴していたネット配信サービスから同等のコンテンツを配信している放送サービスにスムーズに移行することができない。また、逆も同様であり、テレビ受像機が放送信号の受信をすることができなくなった状況（放送信号が届かない場所に移動した場合など）においては、ユーザーは、視聴していた放送サービスから同等のコンテンツを配信しているネット配信サービスにスムーズにお移行することができない。つまり、ユーザーが継続視聴できない場合がある。

【0016】

つまり、従来の技術では、例えばテレビ受像機における放送信号の受信品質が低下した場合などに、ユーザーは、他方（ネット配信サービス）のサービス情報を改めて取得して、そのサービスに対応可能なアプリケーションなどを起動する必要がある。
また、放送サービスとネット配信サービスとの間での不正後によって、サービス情報を統一的に扱うことができないため、テレビ受像機は、両方のサービスを共通のフローで処理することができない。

【0017】

［第３の課題］
放送の流動編成などを想定した場合には、放送サービスにおけるサービス情報の更新タイミングと、ネット配信サービスにおけるサービス情報の更新タイミングとが、ずれるケースが生じる可能性がある。そのようなずれが生じると、受信装置内で保持する両方のサービスのサービス情報において不整合が発生し得る。つまり、受信装置が取得するサービスについての情報の誤りや欠落が生じてしまうことが考えられる。つまり、ネット配信サービスの側でのサービス情報の更新があるときに、受信装置がその更新を反映できず、古い情報を基に受信装置が動作してしまう。

【0018】

本発明は、上記の課題認識に基づいて行なわれたものであり、（１）放送サービスあるいはインターネット等でのネット配信サービスに関するサービス情報を取得して自装置のセットアップを行えること、（２）相互に関連し合う放送サービスに関するサービス情報とネット配信サービスの関するサービス情報とを適切に統合することによって、両者を統合して抽象化したサービスである抽象サービス（抽象チャンネルとも呼ぶ）を生成すること、（３）取得済みのサービス情報を更新すべき状況においては更新用の情報を取得して管理するサービス情報の更新を行えること、の少なくともいずれかを行うことのできる受信装置およびプログラムを提供しようとするものである。

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

【0019】

前記の第１の課題を解決するために、受信装置（ユーザークライアント）は、放送チャンネル（編成チャンネル）によるサービスとネット配信のサービスとの間での連携に関する情報を外部から取得する。受信装置は、放送信号の受信状況やユーザーによる設定情報などを基に、ネット配信サービス（インターネットを用いた動画配信のサービス）に関するサービス情報（サービスリスト）を取得したり、取得したサービス情報をユーザーに対して提示したりする。

【0020】

また、前述の第２の課題を解決するために、受信装置は、放送の編成サービス（編成チャンネル）に関するサービス情報と、インターネット等を用いたネット配信サービスに関するサービス情報とを取得する。また、受信装置は、取得した放送サービスのサービス情報およびネット配信サービスのサービス情報を統合する形で、抽象サービスのサービス情報を生成する。これにより、受信装置は、放送と通信ネットワーク（インターネット等）という異なる伝送路で伝送される配信サービスのサービス情報を、共通の枠組みで捉え処理することが可能となる。つまり、受信装置は、それぞれのサービス情報（放送に関するサービス情報、およびネット配信サービスに関するサービス情報）における関連性（一例としては、パラメーターの一致など）に応じて、これら複数のサービスを統合する。つまり、異なる伝送路（放送、および通信ネットワーク）から提供される同一のサービスについて、一方の伝送路によるサービスを受信することができなくなったときに、受信装置は、統合されたペアの相手方である他の伝送路によるサービスを受信するように切り替えることが可能になる。また、それらのサービスの各々の運用規定や各種ルールに基づき、更新の優先度や、サービス間の関連性の定義を反映する。複数のサービスを統合する際には、受信装置は、例えばサービスＩＤや系列ＩＤなどを参照することにより、どのサービスとどのサービスとを統合すべきであるかを把握する。

【0021】

また、前述の第３の課題を解決するために、受信装置は、放送の編成サービス情報とインターネット等におけるネット配信サービス情報とを取得し、それらのサービス情報などを基に、それらのサービス情報の有効期限や更新すべきタイミングを把握する。受信装置は、上記のタイミングにしたがって、サービス情報の更新情報を取得し、自装置内で保持するサービス情報を更新する。つまり、受信装置は、サービス情報の更新処理に追従する。また、受信装置は、複数のサービスが関連付けられている場合には、それらのサービスのいずれかのサービス情報が更新されたとき、当該サービスに関連付けられる他のサービスについてもサービス情報の更新を行うようにしてよい。

【0022】

［１－１］前記の課題を解決するため、本発明の一態様による受信装置は、放送信号が受信可能であるか否かを判定する放送受信可否判定部と、通信ネットワークを介した通信が可能であるか否かを判定する通信可否判定部と、前記放送受信可否判定部が放送信号は受信可能であると判定した場合に、受信した放送信号から放送サービスについてのサービス情報を取得する放送サービス情報取得部と、通信可否判定部が通信は可能であると判定した場合に、ネット配信サービスについてのサービス情報を外部のサーバー装置から前記通信ネットワークを介して取得するネット配信サービス情報取得部と、を備える。

【0023】

［１－２］また、本発明の一態様は、上記［１－１］の受信装置において、前記ネット配信サービス情報取得部が前記ネット配信サービスについてのサービス情報を取得するための取得条件を決定する取得条件決定部、をさらに備え、前記ネット配信サービス情報取得部は、前記取得条件決定部が決定した前記取得条件にしたがって前記ネット配信サービスについてのサービス情報を取得する、というものである。

【0024】

［１－３］また、本発明の一態様は、上記［１－２］の受信装置において、前記ネット配信サービスについてのサービス情報の所在情報を管理するサービス情報所在情報管理部、をさらに備え、前記取得条件決定部は、サービス情報所在情報管理部が管理する前記ネット配信サービスについてのサービス情報の所在情報に基づいて前記ネット配信サービス情報取得部が前記ネット配信サービスについてのサービス情報を取得するという条件を決定する、というものである。

【0025】

［１－４］また、本発明の一態様は、上記［１－３］の受信装置において、前記サービス情報所在情報管理部は、元々保持していた前記所在情報に加えて、外部から追加で入力される所在情報である拡張所在情報も、前記所在情報の一部として管理する、というものである。

【0026】

［１－５］また、本発明の一態様は、上記［１－２］から［１－４］までのいずれかの受信装置において、前記取得条件決定部は、外部の装置から前記通信ネットワークを介して受信した取得条件を、前記ネット配信サービスについてのサービス情報を取得するための前記取得条件として決定するものである。

【0027】

［１－６］また、本発明の一態様は、上記［１－２］から［１－５］までのいずれかの受信装置において、前記放送サービス情報取得部が取得した前記放送サービスについてのサービス情報に基づいて地域情報を推定する地域推定部、をさらに備え、前記取得条件決定部は、前記地域推定部が推定した結果である前記地域情報に基づいて決定される前記ネット配信サービスについてのサービス情報を取得するという前記取得条件を決定するものである。

【0028】

［１－７］また、本発明の一態様は、放送信号が受信可能であるか否かを判定する放送受信可否判定部と、通信ネットワークを介した通信が可能であるか否かを判定する通信可否判定部と、前記放送受信可否判定部が放送信号は受信可能であると判定した場合に、受信した放送信号から放送サービスについてのサービス情報を取得する放送サービス情報取得部と、通信可否判定部が通信は可能であると判定した場合に、ネット配信サービスについてのサービス情報を外部のサーバー装置から前記通信ネットワークを介して取得するネット配信サービス情報取得部と、を備える受信装置、としてコンピューターを機能させるためのプログラムである。

【0029】

［２－１］また、本発明の一態様による受信装置は、放送信号が受信可能であるか否かを判定する放送受信可否判定部と、通信ネットワークを介した通信が可能であるか否かを判定する通信可否判定部と、前記放送受信可否判定部が放送信号は受信可能であると判定した場合に、受信した放送信号から放送サービスについてのサービス情報を取得する放送サービス情報取得部と、通信可否判定部が通信は可能であると判定した場合に、ネット配信サービスについてのサービス情報を外部のサーバー装置から前記通信ネットワークを介して取得するネット配信サービス情報取得部と、所定の関係を有する複数の具体サービスのそれぞれのサービス情報を統合して抽象サービスについてのサービス情報を生成する統合部と、を備え、前記具体サービスは、前記放送サービスまたは前記ネット配信サービスのいずれかである、というものである。

【0030】

［２－２］また、本発明の一態様は、上記［２－１］の受信装置において、前記統合部は、前記具体サービスのそれぞれに対応するサービス情報に基づいて、相互に関連すると判定される具体サービス同士である前記複数の具体サービスのサービス情報を統合して抽象サービスについてのサービス情報を生成するものである。

【0031】

［２－３］また、本発明の一態様は、上記［２－１］または［２－２］の受信装置において、前記統合部は、前記具体サービスのそれぞれに対応するサービス情報に基づいて、同一の系列に属する前記複数の具体サービスのサービス情報を統合して抽象サービスについてのサービス情報を生成するものである。

【0032】

［２－４］また、本発明の一態様は、上記［２－１］の受信装置において、前記統合部は、前記具体サービスのそれぞれに対応するサービス情報に基づいて、同一のコンテンツを同時にまたはほぼ同時に配信する前記複数の具体サービスのサービス情報を統合して抽象サービスについてのサービス情報を生成するものである。

【0033】

［２－５］また、本発明の一態様は、上記［２－１］から［２－４］までのいずれかの受信装置において、前記サービス情報を画面に提示する提示部、を備え、前記提示部は、前記抽象サービスについては、前記統合部が統合した結果である前記抽象サービスについてのサービス情報を提示するものである。

【0034】

［２－６］また、本発明の一態様は、上記［２－１］から［２－５］までのいずれかの受信装置において、前記放送サービスまたは前記ネット配信サービスで配信されるコンテンツを受信するコンテンツ受信部、を備え、前記コンテンツ受信部は、前記抽象サービスを受信するように指示された場合には、指示された前記抽象サービスを構成する複数の前記具体サービスのうちのいずれかの具体サービスを受信するものである。

【0035】

［２－７］また、本発明の一態様は、上記［２－６］の受信装置において、前記コンテンツ受信部は、前記抽象サービスを受信するように指示されていた状況において、受信中であった当該抽象サービスに属する具体サービスを受信できない場合には、指示されていた当該抽象サービスに属する具体サービスであって、受信できない状況になった前記具体サービスとは異なる他の具体サービスを受信するように切り替えるものである。

【0036】

［２－８］また、本発明の一態様は、放送信号が受信可能であるか否かを判定する放送受信可否判定部と、通信ネットワークを介した通信が可能であるか否かを判定する通信可否判定部と、前記放送受信可否判定部が放送信号は受信可能であると判定した場合に、受信した放送信号から放送サービスについてのサービス情報を取得する放送サービス情報取得部と、通信可否判定部が通信は可能であると判定した場合に、ネット配信サービスについてのサービス情報を外部のサーバー装置から前記通信ネットワークを介して取得するネット配信サービス情報取得部と、所定の関係を有する複数の具体サービスのそれぞれのサービス情報を統合して抽象サービスについてのサービス情報を生成する統合部と、を備え、前記具体サービスは、前記放送サービスまたは前記ネット配信サービスのいずれかである、受信装置、としてコンピューターを機能させるためのプログラムである。

【0037】

［３－１］また、本発明の一態様による受信装置は、放送信号が受信可能であるか否かを判定する放送受信可否判定部と、通信ネットワークを介した通信が可能であるか否かを判定する通信可否判定部と、前記放送受信可否判定部が放送信号は受信可能であると判定した場合に、受信した放送信号から放送サービスについてのサービス情報を取得する放送サービス情報取得部と、通信可否判定部が通信は可能であると判定した場合に、ネット配信サービスについてのサービス情報を外部のサーバー装置から前記通信ネットワークを介して取得するネット配信サービス情報取得部と、を備え、前記ネット配信サービス情報取得部は、取得済みの前記ネット配信サービスについてのサービス情報に関する更新タイミング情報に基づいて、外部のサーバー装置から更新用のネット配信サービスについてのサービス情報を取得し、自装置で保持する前記ネット配信サービスについてのサービス情報の更新を行う。

【0038】

［３－２］また、本発明の一態様は、上記［３－１］の受信装置において、前記更新タイミング情報は、取得済みの前記ネット配信サービスについてのサービス情報の有効期限の情報、または前記外部のサーバー装置が更新用のネット配信サービスについてのサービス情報の提供を開始する日時である更新日時情報、の少なくともいずれかである、というものである。

【0039】

［３－３］また、本発明の一態様は、上記［３－１］または［３－２］の受信装置において、前記ネット配信サービス情報取得部は、定められた運用ルールに基づき、複数のサービスに関するサービス情報の相互間でのデータの衝突を解決しながら、前記自装置で保持する前記ネット配信サービスについてのサービス情報の更新を行うものである。

【0040】

［３－４］また、本発明の一態様は、放送信号が受信可能であるか否かを判定する放送受信可否判定部と、通信ネットワークを介した通信が可能であるか否かを判定する通信可否判定部と、前記放送受信可否判定部が放送信号は受信可能であると判定した場合に、受信した放送信号から放送サービスについてのサービス情報を取得する放送サービス情報取得部と、通信可否判定部が通信は可能であると判定した場合に、ネット配信サービスについてのサービス情報を外部のサーバー装置から前記通信ネットワークを介して取得するネット配信サービス情報取得部と、を備え、前記ネット配信サービス情報取得部は、取得済みの前記ネット配信サービスについてのサービス情報に関する更新タイミング情報に基づいて、外部のサーバー装置から更新用のネット配信サービスについてのサービス情報を取得し、自装置で保持する前記ネット配信サービスについてのサービス情報の更新を行う、受信装置、としてコンピューターを機能させるためのプログラムである。

【発明の効果】

【0041】

本発明によれば、受信装置は、サービス情報を適切に取得し、放送サービスとネット配信サービス（通信サービス）を統合した抽象サービスを生成し、然るべきタイミングにおいて上記のサービス情報の更新を適切に行う、といったことの少なくともいずれかを行える。

【図面の簡単な説明】

【0042】

【図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】同実施形態によるおいてコンテンツ情報に関連して、エンティティ「サービス」と関連する他のエンティティとの関係を示す概略図（ＥＲ図）である。

【図31】同実施形態におけるコンテンツリスト（コンテンツ情報）の論理的な構成を示す概略図である。

【図32】同実施形態におけるコンテンツリスト（コンテンツ情報）の論理的な構成の別態様を示す概略図である。

【図33】同実施形態による受信装置が、複数のコンテンツに関するコンテンツ情報を取得してそれらのコンテンツ情報を統合し、統合されたコンテンツ情報に基づいてコンテンツを提示する処理の手順の例を示す概略図である。

【図34】同実施形態におけるコンテンツ情報の統合の処理での情報の流れを示す概略図である。

【図35】同実施形態による情報統合部がコンテンツ情報を統合する処理を行うための条件の例を示す概略図であり、「identifier」の完全一致によるコンテンツの統合を示す。

【図36】同実施形態による情報統合部がコンテンツ情報を統合する処理を行うための条件の例を示す概略図であり、「associatedMedia」に従属する要素が一致することによるコンテンツの統合を示す。

【図37】同実施形態による情報統合部がコンテンツ情報を統合する処理を行うための条件の例を示す概略図であり、「associatedMedia」の要素の中のコンテンツ同定に関わる要素が一致することによるコンテンツの統合の一例を示す。

【図38】同実施形態による情報統合部がコンテンツ情報を統合する処理を行うための条件の例を示す概略図であり、「associatedMedia」の要素の中のコンテンツ同定に関わる要素が一致することによるコンテンツの統合の別の例を示す。

【図39】同実施形態におけるコンテンツ情報（コンテンツリスト）の具体例を示す概略図（１／６）である。

【図40】同実施形態におけるコンテンツ情報（コンテンツリスト）の具体例を示す概略図（２／６）である。

【図41】同実施形態におけるコンテンツ情報（コンテンツリスト）の具体例を示す概略図（３／６）である。

【図42】同実施形態におけるコンテンツ情報（コンテンツリスト）の具体例を示す概略図（４／６）である。

【図43】同実施形態におけるコンテンツ情報（コンテンツリスト）の具体例を示す概略図（５／６）である。

【図44】同実施形態におけるコンテンツ情報（コンテンツリスト）の具体例を示す概略図（６／６）である。

【図45】同実施形態における受信装置内の取得方法決定部のさらに詳細な機能構成を示すブロック図である。

【図46】同実施形態における取得方法決定部がコンテンツの取得方法を決定する手順を説明するためのシーケンス図である。

【図47】同実施形態における情報管理部２３０が、ユーザーからの情報入力に基づいて、管理する情報を更新する処理の手順を示すシーケンス図である。

【図48】同実施形態における情報管理部２３０が、ユーザーからの情報入力以外の方法（情報管理部２３０自身による状況変化の把握等）に基づいて、管理する情報を更新する処理の手順を示すシーケンス図である。

【図49】同実施形態における情報統合部のさらに詳細な機能構成を示すブロック図である。

【図50】同実施形態の情報統合部がコンテンツ情報を統合するための処理のさらに詳細な手順を示す概略図である。

【図51】同実施形態におけるサービス情報（サービスリスト）の具体例を示す概略図（１／２）である。

【図52】同実施形態におけるサービス情報（サービスリスト）の具体例を示す概略図（２／２）である。

【図53】実施形態に係るシステムの概要構成の一例を示すブロック図である。

【図54】実施形態に係る受信装置の機能構成の一例を示すブロック図である。

【図55】実施形態に係る情報提供システム及び情報登録装置の機能構成の一例を示すブロック図である。

【図56】実施形態に係るシステムの一連の動作の一例を示す状態遷移図である。

【図57】実施形態に係るコンテンツプロバイダーがコンテンツリスト（コンテンツ情報）を提供する場合における一連の動作の一例を示す状態遷移図である。

【図58】実施形態におけるコンテンツリスト（コンテンツ情報）が有する階層構造について説明するための模式図である。

【図59】実施形態に係る受信装置により行われるサービスリスト及びコンテンツリストの更新動作の一例を示すフローチャートである。

【図60】実施形態に係る緊急イベントに関する情報の第１の受信方法について説明するための受信装置のブロック図である。

【図61】実施形態に係る緊急イベントに関する情報の第２の受信方法について説明するための情報提供システムのブロック図である。

【図62】実施形態に係る緊急イベントの提示の一例について説明するための図である。

【図63】実施形態に係るイベントリストの具体例を示す概略図である。

【図64】コンピューターを用いて実施形態における各装置を実現する場合の内部構成の一例を示すブロック図である。

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

【0043】

次に、本発明の実施形態について、図面を参照しながら説明する。図１は、本実施形態によるシステムの概略構成を示すブロック図である。

【0044】

本実施形態のシステム１において、受信装置２は、受信した情報に基づいてコンテンツを発見する。受信装置２は、放送信号（放送波）によるサービス（放送サービス）と、インターネット等の通信ネットワークを介して配信されるサービス（ネット配信サービス）とを受信する。放送サービスは、放送事業者側の配信スケジュールにしたがって配信される。ネット配信サービスは、配信事業者側の配信スケジュールにしたがって配信されるスタイル（ライブ）と、受信装置２（クライアント）側からの要求に基づいて配信されるスタイル（ビデオ・オン・デマンド）とがある。

【0045】

本実施形態においては、抽象チャンネルによるサービスが配信される。抽象チャンネルとは、放送のサービスと、放送と同時に配信されるネット配信のサービスと、の両方を括ったまとまりとしての抽象的なチャンネル（abstract channel）である。一例として、「ＮＨＫ総合テレビ・東京」という放送サービスと「ＮＨＫ総合」のネット配信サービスとを括ったサービスが、抽象チャンネルである。

【0046】

抽象チャンネルの構成要素である放送サービスは、サービス名（例えば、「ＮＨＫ総合・東京」）や、放送チャンネル（オリジナルネットワークＩＤ、トランスポートストリームＩＤ、サービスＩＤの三つ組によって規定される資源）などの管理情報と関連付けられる。抽象チャンネルの他の構成要素であるネット配信サービスは、サービスにアクセスするための所在情報（ＵＲＬ、ユニフォーム・リソース・ロケーター）や、配信パラメーターなどの管理情報と関連付けられる。放送サービスやネット配信サービスは、動画、音声、テキストなどといった資源を、配信事業者側からユーザー（視聴者）の受信装置２側に伝送することによって実現される。

【0047】

また、上記のようなサービスの中で提要される一つ一つの番組（コンテンツ）の情報は、別途、コンテンツリスト等として管理される。

【0048】

本実施形態において、受信装置２は、サービスリストを取得する。サービスリストはサービスについての情報（サービス情報）である。サービスリストは、複数のサービスについての情報を括った情報である。サービスリストは、例えば、特定の地域（例えば、関東）の地上デジタル（地デジ）放送に関連する情報をまとめたリストであってよい。また、サービスリストは、例えば、国（日本）全体をカバーする衛星放送（ＢＳ放送）に関連する情報をまとめたリストであってもよい。サービスリストの括り方は、ここで例示したものには限定されず、様々な括り方があってよい。

【0049】

サービスリストは、サービス情報提供サーバー装置３によって提供される。受信装置２は、サービス情報提供サーバー装置３からサービスリストを取得することができる。サービス情報提供サーバー装置３自体も、様々な形態で存在してよい。受信装置２が少なくとも最低限のサービスリストを取得できるようにするために、ミニマムなサービス情報提供サーバー装置３や、デフォルト扱いの（例えば工場出荷時の状態での受信装置２がアクセス可能な）サービス情報提供サーバー装置３を運用するようにしてよい。

【0050】

サービス情報提供サーバー装置３は、インターネット等の通信ネットワークを介して、サービスリストを受信装置２に提供する。ただし、サービス情報提供サーバー装置３は、他の方法でサービスリストを提供してもよい。例えば、サービス情報提供サーバー装置３は、ＩＳＤＢ（Integrated Services Digital Broadcasting、統合デジタル放送サービス）の放送信号中のＳＩ（Service Information、サービス情報）内においてサービスリストを提供するようにしてもよい。

【0051】

受信装置２は、インターネット等から受信するサービスリストと放送信号から受信するサービスリストとを、マージしたり、ルール等に基づいて一方が他方を上書きしたりするなどしてよい。つまり、受信装置２は、複数の手段ないしは経路で受信したサービスリストを統合することによって、自装置用のサービスリストを生成してよい。また、複数の受信装置２間でサービスリストを共有するようにしてもよい。例えば、宅内、同一ユーザー内、あるいは同一ユーザーグループ内などに複数の受信装置２が存在するとき、第１の受信装置が受信して生成したサービスリストを、他の装置である第２の受信装置が参照して利用するようにしてもよい。また、例えば、第１の受信装置が取得したサービスリストと、他の装置である第２の受信装置がサービスリストと、相互に交換してマージした形態で共有するようにしてもよい。

【0052】

コンテンツリストは、コンテンツ情報提供サーバー装置６によって提供される。

【0053】

コンテンツリストは、コンテンツに関する情報（コンテンツ情報）の集合である。サービス情報提供サーバー装置３は、上記のサービスリストとは別にコンテンツリストを受信装置２に提供してよい。一つのコンテンツリストにどのコンテンツの情報を含めるようにするかは、様々であって良い。一つのミニマムな仕様の例として、一つのコンテンツリストは、ある放送サービス（チャンネル）を想定して、現在配信されているコンテンツ（番組）の情報や、次に配信されるコンテンツ（番組）の情報のリストという形態であってよい。現在のコンテンツの情報と次のコンテンツの情報とは、「ｐ／ｆ」と呼ばれるものである。ここで、「ｐ」はpresent（現在）を表し、「ｆ」はfollowing（次の、後続する）を表す。また、従来技術における放送の場合と同様に、現在から１週間先の日付までのＥＩＴスケジュール相当のコンテンツリストを、サービス情報提供サーバー装置３が提供するようにしてもよい。また、コンテンツリストが、過去のコンテンツに関する情報を含んでいてもよい。過去のコンテンツの情報は、いわゆる「見逃し配信」のサービスを実現する際に有用な情報である。

【0054】

コンテンツリストは、特定の一つのサービス（チャンネル）において配信されるコンテンツの情報の集合であってもよいし、複数のサービス（チャンネル）にまたがるコンテンツの情報の集合であってもよい。一例として、コンテンツリストは特定の地域（例えば、東京）を対象とする地上デジタル（地デジ）放送のサービス群に含まれるコンテンツの情報の集合であってもよい。

【0055】

コンテンツリストに含まれるコンテンツ情報は、典型的には、コンテンツ名（番組名）、制作者名、出演者名などといった情報を含む。また、コンテンツ情報は、配信媒体に特有の情報（例えば、放送サービスに関してはチャンネルを特定する情報、ネット配信サービスに関しては配信用のＵＲＬや配信プロトコルの種別を表す情報など）を含んでもよい。また、コンテンツ情報には、複数のコンテンツ間の関係を記述することができる。例えば、コンテンツＡとコンテンツＢとが同一シリーズの異なる配信回のコンテンツである場合には、コンテンツ情報は、上記のコンテンツＡとコンテンツＢとに関する情報として、両者に共通するシリーズ名（あるいは、シリーズＩＤ等）と、配信回を表す情報とを含むことができる。配信回は、例えば、第×シリーズ、第×シーズン、第×エピソード、第×回などといった表現（それらの組合せでもよい）で表わされる場合がある。コンテンツＡとコンテンツＢとが、共通のテーマ（例えば、ニホンカワウソ）を扱う場合や、共通の制作者によるものである場合や、共通の出演者が出演するものである場合などにも、コンテンツ情報がこれら両者の関連性を示すようにしてもよい。

【0056】

受信装置２は、サービスリストの場合と同様に、複数のコンテンツリストを取得してそれらをマージして自装置用のコンテンツリスト（コンテンツデータベース）を生成してもよい。それら複数のコンテンツリストのそれぞれは、放送信号から取得されるコンテンツリストであってもよいし、ネット配信としてインターネット等を介して取得されるコンテンツリストであってもよい。

【0057】

サービスリストが比較的静的な情報であるのに対して、コンテンツリストは動的な情報であってよい。つまり、受信装置２は、より頻繁にコンテンツリストを取得して、自装置内の情報（コンテンツデータベース等）を更新することができる。地上放送の信号に関する規定（ＩＳＤＢ－Ｔ，Integrated Services Digital Broadcasting - Terrestrial，統合デジタル放送サービス － 地上用）では、受信装置２は、放送信号に含まれるコンテンツリストを所定頻度で受信することとなる。ネット配信サービスにおけるコンテンツリストの更新頻度は、適宜設定され得る。ネット配信サービスにおけるコンテンツリストは、プル（pull）型ＡＰＩ、プッシュ（push）型ＡＰＩなどを介して受信装置２によって取得される。受信装置２は、それらのＡＰＩを介して更新通知だけを受け取るスタイルとしてもよい（この場合には受信装置２が必要に応じて更新された情報を要求して取得する）し、それらのＡＰＩを介してコンテンツリストのデータ実体を受け取るスタイルとしてもよい。また、ＭＴＥ（Media Timed Event、メディア・タイムド・イベント）のしくみを用いて、配信される動画ストリームに付随する形で、受信装置２がコンテンツリストの情報（コンテンツリストの更新情報、またはコンテンツリストのデータ実体）を受信できるようにしてもよい。

【0058】

また、コンテンツリスト内に、サービスリストの更新通知を含めて受信装置２側で取得できるようにしてもよい。この場合には、受信装置２は、コンテンツリスト内にサービスリストの更新通知が含まれていることを検出したことをトリガーとして、サービスリストの更新情報を、サービス情報提供サーバー装置３に対して要求することができる。

【0059】

サービスリストあるいはコンテンツリストの少なくともいずれかが、有効期限の情報、あるいは再取得日時の情報を持つようにしてもよい。これらの情報は、受信装置２がサービスリストあるいはコンテンツリストを再取得することを促す情報である。受信装置２は、例えば有効期限が切れたことをトリガーとして、適宜、リスト（サービスリストあるいはコンテンツリスト）を再取得する。あるいは、受信装置２は、例えば再取得日時が到来したことをトリガーとして、適宜、リスト（サービスリストあるいはコンテンツリスト）を再取得する。

【0060】

受信装置２は、サービスリストを、放送信号のみから、あるいは通信（インターネット等）のみからしか取得できない場合にも、適切にサービスリストを取得、維持、および更新する。また、コンテンツリストについても同様である。即ち、受信装置２は、コンテンツリストを、放送信号のみから、あるいは通信（インターネット等）のみからしか取得できない場合にも、適切にコンテンツリストを取得、維持、および更新する。

【0061】

図１に示すように、システム１は、受信装置２と、サービス情報提供サーバー装置３と、サービス配信サーバー装置４と、放送送出装置５と、コンテンツ情報提供サーバー装置６と、コンテンツ提供装置７と、インターネット８とを含んで構成される。この図においては、受信装置２、サービス情報提供サーバー装置３、サービス配信サーバー装置４、放送送出装置５、コンテンツ情報提供サーバー装置６、およびコンテンツ提供装置７のそれぞれを１台ずつ示しているが、これらの装置の台数は任意である。受信装置２、サービス情報提供サーバー装置３、サービス配信サーバー装置４、放送送出装置５、コンテンツ情報提供サーバー装置６、およびコンテンツ提供装置７のそれぞれは、例えば、コンピューターを用いて実現される。システム１を構成する各要素の機能は、次の通りである。

【0062】

受信装置２は、コンテンツを受信してユーザーに提示する装置である。受信装置２は、放送送出装置５からの放送信号によって伝送されるコンテンツを受信することもでき、インターネット８等の通信ネットワークを介してサービス配信サーバー装置４から伝送されるコンテンツを受信することもできる。受信装置２は、受信したコンテンツのデータを、適宜、復調、復号して、映像や音声やテキスト等を含むコンテンツをユーザーに対して提示する。受信装置２は、映像やテキストについては、画面に表示する。受信装置２は、音声についてはスピーカー等（イヤフォン等を含む）から出力する。受信装置２はその他の形態のコンテンツを提示してもよい。

【0063】

受信装置２は、放送サービスに関するサービス情報や、ネット配信サービスに関するサービス情報を取得し、自装置内などに保持する。受信装置２は、サービス情報に基づいて、放送やネット配信のサービスを受信することができる。受信装置２は、サービス情報提供サーバー装置３から、インターネット８経由で、サービス情報（サービスリスト）を受信することができる。また、受信装置２は、放送送出装置５から送出される放送信号内に含まれるサービス情報（サービスリスト）を受信することができる。また、受信装置２は、複数のサービス情報（放送に関するサービス情報とネット配信に関するサービス情報）を統合して、それらのサービスを束ねる概念である抽象サービス（抽象チャンネル）を生成することができる。抽象チャンネルに属する放送サービスとネット配信サービスとは、例えば、同一のコンテンツを同時（ほぼ同時）に配信するものであってよい。受信装置２は、例えばあるサービスを受信中に、何らかの理由でそのサービスの受信が途絶えてしまった場合（伝送信号の不達等）には、抽象サービスに関するサービス情報を参照することによって、当該サービスと同一の抽象サービスに属する他のサービスにアクセスして、当該抽象サービスのコンテンツを継続して受信することができる。つまり、受信装置２は、伝送路を適宜切り替えることができる。なお、受信装置２は、信号不達等の場合の伝送路の切り替えに限らず、他の形態で抽象サービスを受信してもよい。つまり、受信装置２は、様々な形態で、相互に関連付けられる複数のサービスを受信し、提示することができる。

【0064】

受信装置２は、また、サービス情報が更新されるときには、新たなサービス情報を取得して、自装置が管理（設定）するサービス情報を更新する。受信装置２は、関連し合う複数のサービス間においてサービス情報の不整合が生じないように、サービス情報の更新を制御する。

【0065】

受信装置２は、例えば、インターネットによる通信の機能を有するテレビ受像機として実現され得る。また、受信装置２は、他の例として、放送信号を受信する機能およびインターネットによる通信の機能を有するコンピューター（ＰＣ（パーソナルコンピューター）、タブレット端末装置、スマートフォン、腕時計型端末装置、ウェアラブル端末装置等）としても実現され得る。

【0066】

サービス情報提供サーバー装置３は、インターネット８を介して、サービス情報を受信装置２に対して提供する。サービス情報提供サーバー装置３は、プッシュ形式でサービス情報を受信装置２に送信するものであってもよいし、受信装置２からの要求に応じる形でサービス情報を受信装置２に送信するものであってもよい。また、サービス情報提供サーバー装置３は、サービス情報を更新すべき状況においては、その更新用の情報を受信装置２に対して送信する。なお、サービス情報提供サーバー装置３は、サービス情報に関する更新通知を、例えばプッシュ形式等で受信装置２に対して送るようにしてもよい。なお、サービス情報提供サーバー装置３は、コンテンツ提供装置７から、サービス情報あるいはその基となる情報を受け取る。

【0067】

サービス配信サーバー装置４は、ネット配信によるサービスを、インターネット８を介して受信装置２に提供する。具体的には、サービス配信サーバー装置４は、コンテンツを構成する動画や音声のデータを、例えばストリーミング等の手段を用いて、受信装置２に提供する。サービス配信サーバー装置４が配信するサービスについての情報は、サービス情報提供サーバー装置３が受信装置２に対して提供する情報である。なお、サービス配信サーバー装置は配信対象となるコンテンツのデータを、コンテンツ提供装置７から受け取る。

【0068】

放送送出装置５は、放送信号を送出する。放送信号は、空中波として、あるいはケーブルテレビ用のケーブルを媒体とする電気信号として、放送送出装置５によって送出され、伝送される。放送送出装置５が送出する放送信号は、動画や音声やテキスト等の信号に加えて、制御信号を含んでいる。制御信号には各種の制御情報が含まれる。放送信号に載せて送出され制御信号は、放送サービスの編成チャンネルについてのサービス情報を含む。

【0069】

コンテンツ情報提供サーバー装置６は、コンテンツに関する情報を、インターネット８を介して、受信装置２に送信する。コンテンツ（番組）は、内容的にまとまりのある単位であり、映像や音声等を含んで構成されるものである。コンテンツに関する情報は、コンテンツの識別情報、タイトル（題名）、概略（あらすじなど）、出演者情報、制作者情報などを含んでいてよい。

【0070】

コンテンツ提供装置７は、コンテンツのデータおよび関連するデータを、サービス情報提供サーバー装置３、サービス配信サーバー装置４、放送送出装置５、およびコンテンツ情報提供サーバー装置６に提供する。コンテンツのデータは、動画や音声やテキスト等のデータである。コンテンツに関連するデータは、前述のサービス情報やコンテンツ情報を含む。

【0071】

インターネット８は、回線を用いて構成される通信ネットワークである。インターネット８はオープンなネットワークであり、インターネット８に接続した装置同士は所定のプロトコルを用いて相互に通信する。インターネット８のインターネット層においては、インターネットプロトコル（ＩＰ）等を用いた通信が行われる。

【0072】

システム１においてコンテンツ提供装置７から提供するコンテンツは、ＩＳＤＢ－Ｔ（統合デジタル放送サービス － 地上用）、ＩＳＤＢ－Ｓ（統合デジタル放送サービス － 衛星用）、ＩＳＤＢ－Ｓ３（高度広帯域衛星デジタル放送方式）などといった放送システムで提供される。また、コンテンツは、ネット配信サービスでも提供される。ネット配信サービスでは、ＣＭＡＦ（Common Media Application Format）、ＭＰＥＧ－ＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）、ＨＬＳ（HTTP Live Streaming）などの方法が用いられる。ネット配信サービスでは、ライブ配信（live）とオンデマンド配信（VOD，Video on Demand）のいずれもが想定される。

【0073】

放送番組は、ネット配信サービスでも同時に配信されている（例えば、ＮＨＫプラス、ＴＶｅｒ等）。本実施形態では、同内容（同一の番組等）が提供される放送編成チャンネルと同時ネット配信とを束ねる抽象的なグループとして、「サービス」を定義する。サービスは、「抽象チャンネル」とも呼ばれる。

【0074】

上記のサービスとしては、種々のタイプのものが存在する。例えば、放送チャンネルによるコンテンツの配信を軸としたサービス、ネット配信によるコンテンツの配信を軸としたサービス、ＶＯＤにおけるポータル提供によるサービス、カテゴリーやジャンル等で定義されるコンテンツ配信のグループとしてのサービスなどである。

【0075】

放送チャンネルを軸としたサービスは、放送事業者が編成するスケジュールにしたがって放送によって配信される番組の連続である。このような番組の配列は、例えば、ＡＲＩＢ ＳＴＤ－Ｂ１０「デジタル放送に使用する番組配列情報」標準規格において規定される。

【0076】

ネット配信を軸としたサービスは、１）放送と同様にコンテンツプロバイダー（放送事業者がコンテンツプロバイダーである場合を含む）が編成するネット番組の連続として成るタイプのサービスと、２）ＶＯＤ配信などのサービスとの２種類がある。

【0077】

前述の通り、サービス情報提供サーバー装置３は、サービスリストを提供する。前述の通り、放送信号でサービスリストが提供される場合もある。

【0078】

サービスリストは、各サービスについて、サービス名称、配信者情報、サービス識別子（サービスを特定するためのユニークなＩＤ）、提供方法（放送チャンネルの場合には、チャンネルの識別子情報であるところのオリジナルネットワークＩＤ（nid）、トランスポートストリームＩＤ（tsid）、サービスＩＤ（sid）の組。ネット配信サービスの場合には、ＵＲＬや配信プロトコルや配信パラメーターの情報）、サービス自体の付加情報を提供するためのＡＰＩの情報、そのサービスのコンテンツの情報を取得するためのＡＰＩ（コンテンツリストＡＰＩ）の情報などを含む。なお、サービスリストの例については、後で図面を参照しながら説明する。

【0079】

図２は、本実施形態が扱う対象であるコンテンツ配信のための抽象サービス（抽象チャンネル）の構成を概念的に示す概略図である。本実施形態における抽象サービス（抽象チャンネル）は、例えば複数個のサービス（放送サービスあるいは通信（ネット配信）サービス）を束ねることによって構成されるサービスである。抽象サービス（抽象チャンネル）を上位層と捉えた場合には、その下位層は、放送サービスや通信（ネット配信）サービスである。放送サービスや通信（ネット配信）サービスのそれぞれは、コンテンツを配信するための手段である。図示するように、１つの抽象サービス（抽象チャンネル）は、０個以上の放送サービスと０個以上の通信（ネット配信）サービスとを含むようにして構成される。ただし、１つの抽象サービス（抽象チャンネル）は、通常は１個以上のサービス（放送サービスあるいは通信（ネット配信）サービス）を含む。

【0080】

図３は、抽象サービス（抽象チャンネル）を管理するための情報（抽象サービス管理情報と呼ぶ）と、抽象サービスに属する実体のサービス（放送サービスおよび通信（ネット配信）サービス）を管理するための情報（それぞれ、放送サービス管理情報および通信サービス管理情報と呼ぶ）との関係を表す概略図である。図示するように、抽象サービス管理情報は、その抽象サービスを具体的に構成する放送サービスや通信（ネット配信サービス）サービスを管理するための放送サービス管理情報や通信サービス管理情報と関連付けられる。つまり、それぞれの放送サービスを管理するための放送サービス管理情報は、その放送サービスが属する抽象サービス（抽象チャンネル）を管理するための抽象サービス管理情報と関連付けられている。また、それぞれの通信（ネット配信）サービスを管理するための通信サービス管理情報は、その通信サービスが属する抽象サービス（抽象チャンネル）を管理するための抽象サービス管理情報と関連付けられている。なお、この図３は、抽象サービス管理情報と、放送サービス管理情報と、通信サービス管理情報との相互の関係を概念的に説明するためのものである。これらの管理情報を具体的にどういったデータ構造で表現するかについては、別途検討されてよい。

【0081】

図４は、本実施形態による受信装置２の内部の概略機能構成を示すブロック図である。図示するように、受信装置２は、ユーザー制御入力部２０１と、放送メディア利用可否情報取得部２０２と、選局可能チャンネル情報取得部２０３と、放送受信可否判定部２０４と、選局可能チャンネル情報記憶部２０５と、地域推定部２０６と、通信可否判定部２１１と、サービスリスト取得条件決定部２１２と、サービスリスト所在情報管理部２１３と、サービスリスト取得部２１４と、サービスリスト記憶部２１５と、情報統合部２２１と、コンテンツ受信部２３１と、提示部２３２とを含んで構成される。これらの各機能部は、例えば、電子回路を用いて実現される。また、各機能部は、必要に応じて、半導体メモリーや磁気ハードディスク装置などといった記憶手段を内部に備えてよい。また、各機能を、コンピューターおよびソフトウェアによって実現するようにしてもよい。

【0082】

ユーザー制御入力部２０１は、ユーザー等からの制御信号を外部から受け取り、受信装置２内の必要な機能に対して制御信号を伝達する。ユーザー制御入力部２０１は、例えばユーザーが操作するリモコンの信号を上記の制御信号として受信する。制御信号の内容は、受信装置２の起動や停止、サービスリスト取得に関する設定（サービスリストの所在情報に関する設定を含む）、受信すべきコンテンツの選択（選局）、音量等の調整、受信装置２上で稼働するアプリの起動や停止、サービスリストの提示の指示、提示されたサービスリストからのサービスの選択などを含むようにできる。

【0083】

放送メディア利用可否情報取得部２０２は、放送メディアの利用可否についての情報を取得する。放送メディアとは、ＣＳデジタル放送、ＢＳデジタル放送、１１０度ＣＳデジタル放送、地上デジタル放送等である。放送メディア利用可否情報取得部２０２は、これらそれぞれの放送メディアの信号の受信を試みて、所定の信号が得られるか否かを判定することにより、各放送メディアの利用可否の情報を得る。

【0084】

選局可能チャンネル情報取得部２０３は、放送の、選局可能なチャンネルに関する情報を取得する。選局可能チャンネル情報取得部２０３は、「放送サービス情報取得部」とも呼ばれる。選局可能チャンネル情報取得部２０３は、下記の放送受信可否判定部２０４が放送信号は受信可能であると判定した場合に、受信した放送信号から放送サービスについてのサービス情報を取得するものである。具体的には、選局可能チャンネル情報取得部２０３は、受信装置２が受信する放送信号から、選局可能編成チャンネル情報を取得する。選局可能編成チャンネル情報は、選局可能なチャンネルの、論理チャンネル番号、オリジナルネットワークＩＤ、トランスポートストリームＩＤ、サービスＩＤなどの情報を含んでいる。選局可能チャンネル情報取得部２０３は、取得した選局可能編成チャンネル情報を、選局可能チャンネル情報記憶部２０５に書き込む。放送信号は、超短波帯以上の周波数帯域の電波等を用いて、サービス対象の地域に向けて送信される。つまり、選局可能なチャンネルに関する情報は、受信装置２が設置されている地域を推定するための基となり得る情報である。選局可能チャンネル情報取得部２０３は、例えば、受信装置２が起動される都度、所定の時間間隔ごと、あるいは受信装置２が移動したことを検知した都度、選局可能チャンネル情報を取得しなおすようにしてもよい。

【0085】

放送受信可否判定部２０４は、放送信号を受信できるか否かを判定する。放送受信可否判定部２０４は、例えば、所定の放送チャンネル（単数または複数）の周波数の信号の受信を試みて、期待される信号が受信できるか否かによって放送信号の受信可否を判定する。

【0086】

選局可能チャンネル情報記憶部２０５は、選局可能チャンネル情報取得部２０３が取得した選局可能チャンネル情報を記憶する。選局可能チャンネル情報は、選局可能チャンネル情報取得部２０３によって書き込まれる。選局可能チャンネル情報記憶部２０５が記憶している選局可能チャンネル情報は、例えば地域推定部２０６によって読み出され、地域情報の推定のために利用される場合がある。また、選局可能チャンネル情報は、例えば情報統合部２２１によって読み出され、ネット配信サービスのサービスリストとの統合の処理の対象となる場合がある。

【0087】

地域推定部２０６は、受信装置２が存在している（設置されている）地域を推定する。ここで推定される地域とは、例えば東京エリア、あるいは関東エリアなどといった粒度のものである。つまり、地域推定部２０６によって推定される地域は、概ね、放送のサービスエリアに対応する。地域推定部２０６は、様々な手法を用いて地域を推定することができる。例えば、地域推定部２０６は、ＧＰＳ（グローバル・ポジショニング・システム）信号を受信することによって緯度および経度を算出し、その情報から地域を求めてもよい。また、例えば、地域推定部２０６は、選局可能チャンネル情報記憶部２０５から選局可能チャンネル情報を読み出し、不図示の地域検索テーブル等と照合することによって、地域を推定してもよい。言い換えれば、地域推定部２０６は、選局可能チャンネル情報取得部２０３が取得した放送サービスについてのサービス情報（選局可能チャンネル情報）に基づいて地域情報を推定してもよい。また、例えば、地域推定部２０６は、有線の通信ネットワークのアクセスポイントを識別する情報や、無線通信ネットワークの基地局を識別する情報などに基づいて、地域を推定するようにしてもよい。地域推定部２０６は、推定結果である地域情報を、サービスリスト取得条件決定部２１２やサービスリスト取得部２１４に渡す。

【0088】

通信可否判定部２１１は、通信ネットワーク（インターネット８）を介した通信が可能であるか否かを判定する。通信可否判定部２１１は、判定結果である通信可否の情報を、少なくともサービスリスト取得部２１４に伝える。これにより、サービスリスト取得部２１４は、通信ネットワークを介してサービスリストを取得することが可能であるか否かを把握することができる。

【0089】

サービスリスト取得条件決定部２１２は、サービスリスト取得部２１４がネット配信サービスについてのサービスリストを取得するための取得条件を決定する。サービスリスト取得条件決定部２１２は、単に「取得条件決定部」とも呼ばれる。サービスリスト取得条件決定部２１２は、その決定に基づいて、サービスリストの取得条件をサービスリスト取得部２１４に渡す。

【0090】

サービスリスト取得条件決定部２１２は、後述するサービスリスト所在情報管理部２１３が管理するネット配信サービスについてのサービス情報のＵＲＬ（所在情報）に基づいてネット配信サービスについてのサービス情報を取得するという条件を決定するようにしてよい。これは、下記の第１の条件および第２の条件に該当する。

【0091】

サービスリスト取得条件決定部２１２は、具体的には、次に列挙するような条件を決定する。第１に、サービスリストを取得するためのＵＲＬが予め（例えば工場出荷時から）受信装置２内に登録されている（登録ＵＲＬと呼ぶ）。サービスリスト取得条件決定部２１２は、この登録ＵＲＬを読み出すとともに、その登録ＵＲＬをサービスリストの取得のために用いるか否かを決定する。ユーザー制御入力部２０１から渡されるユーザーからの指示によっては、その登録ＵＲＬを用いないようにすることもできる。第２に、サービスリスト取得条件決定部２１２は、サービスリストを取得するための追加のＵＲＬ（拡張ＵＲＬと呼ぶ）を取得し、その拡張ＵＲＬをサービスリストの取得のために用いるか否かを決定する。拡張ＵＲＬの情報は、例えば、ユーザー制御入力部２０１を介してユーザーから入力される。第３に、サービスリスト取得条件決定部２１２は、地域推定部２０６から推定結果である地域情報を受け取り、その地域情報に応じてサービスリスト取得条件を決定する。つまり、サービスリスト取得条件決定部２１２は、地域推定部２０６が推定した結果である地域情報に基づいて決定されるネット配信サービスについてのサービスリストを取得するという取得条件を決定する。例えば、サービスリスト取得条件決定部２１２は、渡された地域情報に対応するコンテンツ配信事業者（放送事業者である場合を含む）のみについてのサービスリストを取得するように、サービスリスト取得条件を決定してもよい。第４に、サービスリスト取得条件決定部２１２は、例えば外部のサーバー装置（サービス情報提供サーバー装置３等）からインターネット８を介して受信した取得条件に基づいてネット配信サービスについてのサービスリスト（サービス情報）を取得するように、サービスリスト取得条件を決定してもよい。また、サービスリスト取得条件決定部２１２は、上に例示した第１から第４までの方法以外の方法でサービスリスト取得条件を設定してもよい。

【0092】

サービスリスト所在情報管理部２１３は、ネット配信サービスについてのサービスリストを取得するための所在情報（ＵＲＬ）を保持し、管理する。サービスリスト所在情報管理部２１３は、「サービス情報所在情報管理部」とも呼ばれる。サービスリスト所在情報管理部２１３は、具体的には、上記の登録ＵＲＬや拡張ＵＲＬを記憶する。つまり、サービスリスト所在情報管理部２１３は、元々保持していた所在情報（登録ＵＲＬ）に加えて、外部から追加で入力される所在情報である拡張所在情報（拡張ＵＲＬ）も、管理対象とする。サービスリスト所在情報管理部２１３が管理するＵＲＬの情報は、サービスリスト取得部２１４に渡される。サービスリスト取得部２１４は、上記の登録ＵＲＬや拡張ＵＲＬにアクセスすることによって、サービスリストを取得する。言い換えれば、サービスリスト取得部２１４は、上記の登録ＵＲＬや拡張ＵＲＬにアクセスすることによってサービス情報提供サーバー装置３に対してサービス情報（サービスリスト）を要求する。

【0093】

サービスリスト取得部２１４は、サービスリスト取得条件決定部２１２が決定した取得条件にしたがって、サービス情報提供サーバー装置３からサービスリスト（サービス情報）を取得する。サービスリスト取得部２１４は、「ネット配信サービス情報取得部」とも呼ばれる。サービスリスト取得部２１４は、通信可否判定部２１１が通信は可能であると判定した場合に、ネット配信サービスについてのサービス情報を外部のサーバー装置からインターネット８を介して取得する。サービスリスト取得部２１４が取得するサービスリストは、ネット配信サービスに関するサービス情報である。サービスリスト取得条件については、既に説明した通りである。サービスリスト取得部２１４は、サービスリスト取得条件にしたがって、サービスリスト所在情報管理部２１３から渡されるＵＲＬ（上記の登録ＵＲＬや拡張ＵＲＬ）に基づいて、サービスリストの取得を行う。なお、サービスリスト取得部２１４は、通信可否判定部２１１が通信可能であると判定した場合にのみ、通信ネットワークを介して、サービスリストを取得する。通信可否判定部２１１が通信不可であると判定した場合には、サービスリスト取得部２１４は、通信ネットワーク経由でのサービスリストの取得を行わない。

【0094】

サービスリスト取得部２１４がサービスリストを取得した場合には、サービスリスト取得部２１４は、そのサービスリストをサービスリスト記憶部２１５に書き込む。

【0095】

サービスリスト取得部２１４は、サービスリストの更新を行うタイミングにおいては、更新用のサービスリストの情報を取得する。サービスリスト取得部２１４は、取得済みのネット配信サービスについてのサービス情報に関する更新タイミング情報に基づいて、サービス情報提供サーバー装置３から更新用のネット配信サービスについてのサービス情報を取得し、自装置（サービスリスト記憶部２１５）で保持するネット配信サービスについてのサービス情報の更新を行う。上記の更新タイミング情報は、取得済みのネット配信サービスについてのサービス情報の有効期限の情報、またはサービス情報提供サーバー装置３が更新用のネット配信サービスについてのサービス情報の提供を開始する日時である更新日時情報、の少なくともいずれかであってよい。また、他の更新タイミング情報に基づいてサービス情報の更新を行うようにしてもよい。

【0096】

また、サービスリスト取得部２１４は、定められた運用ルールに基づき、複数のサービスに関するサービス情報の相互間でのデータの衝突を解決しながら、自装置（サービスリスト記憶部２１５）で保持する前記ネット配信サービスについてのサービス情報の更新を行うようにしてよい。

【0097】

ここで、複数のサービスが互いに関連付けられている場合、更新されたサービス情報を、関連するサービス情報に反映させることによって、更新が遅延したり提供できなかったりする状況にあるサービスについても、更新情報をもとに受信機が動作できるようになる。また、放送でイベントリレー送出情報や流動編成関連付属情報を抽出した場合、ネットからサービス情報を取得するまでは、放送の最新情報の優先度を高めることができる。更に、場合によってはネットからの情報を無効化することもできる。一方、サービス情報サーバーからのプッシュ通知に新情報が格納されている場合、最新情報の優先度を高め放送からの情報の無効化や優先度の低下を図ることができる。そして、放送サービスやネットサービスにおいて、同一サービスとして統合される、又は同系列サービスとして統合される、又は抽象サービスの要素同士について互いに関連付けされているとみなして、更新判定時刻の比較が行われる。

【0098】

サービスリスト取得部２１４は、例えば、関連性と、更新情報内容に応じて、他のサービス情報を上書きするかどうかの判定を行う。関連性の具体例としては、サービスＩＤが同一であるとき、親サービスのＩＤ（ＰＡＲＥＮＴサービスＩＤ）が同一であるとき、系列サービスＩＤが同一であるときを例示することができる。更新情報内容の具体例としては、複数のサービスに関するサービス情報の相互間でのデータの衝突とは、緊急情報関係（災害情報や緊急ニュース等）、又は一般情報関係（スポーツの延長番組や流動編成等）を例示することができる。より具体的には、緊急情報については、すべての関連性について更新が行われてもよい。また、一般情報関係については、サービスＩＤが同一の関係は即時反映を行い、親サービスのＩＤの関係性については、３０秒反映を行ってもよい。また、系列サービスＩＤについては、判定が行われなくてもよい。

【0099】

サービスリスト記憶部２１５は、サービスリスト取得部２１４が取得したサービスリストを記憶する。

【0100】

情報統合部２２１は、放送サービスに関するサービス情報（編成チャンネル情報）とネット配信サービスに関するサービス情報とを統合し、一つの情報としてまとめる。情報統合部２２１は、単に「統合部」とも呼ばれる。情報統合部２２１は、所定の関係を有する複数の具体サービスのそれぞれのサービス情報を統合して、抽象サービスについてのサービス情報を生成する。ここで、「具体サービス」とは、放送サービスまたはネット配信サービスのいずれかである。つまり、情報統合部２２１は、統合されたサービスについてのサービス情報を生成する。言い換えれば、情報統合部２２１は、放送サービスとネット配信サービスとを統合した抽象サービスを生成する。情報統合部２２１が統合したサービス情報は、提示部２３２によってユーザーに提示される。

【0101】

なお、情報統合部２２１は、具体サービスのそれぞれに対応するサービス情報に基づいて、相互に関連すると判定される具体サービス同士である複数の具体サービスのサービス情報を統合して抽象サービスについてのサービス情報を生成するものである。

【0102】

具体サービス間の相互の関連の一例として、情報統合部２２１は、同一の系列（affiliation）に属する複数の具体サービスのサービス情報を統合して、抽象サービスについてのサービス情報を生成してよい。ここで、系列とは、典型的には放送事業における系列である。例えば、「ＮＨＫ総合・東京」という放送サービスと、「ＮＨＫ総合・名古屋」という放送サービスとは、いずれも、「ＮＨＫ総合」という系列に属する。また、例えば、関東地域をサービスエリアとする放送事業者と、近畿（関西）地域をサービスエリアとする放送事業者とが、別法人であっても、同一の系列に属するものであてもよい。

【0103】

具体サービス間の相互の関連の一例として、別の観点では、次の通りである。即ち、情報統合部２２１は、具体サービスのそれぞれに対応するサービス情報に基づいて、同一のコンテンツを同時にまたはほぼ同時に配信する複数の具体サービスのサービス情報を統合して抽象サービスについてのサービス情報を生成してよい。

【0104】

情報統合部２２１は、統合したサービス情報を、提示部２３２に渡す。統合したサービス情報は、抽象サービス（抽象サービス）の情報と、具体サービスの情報との両方を含んでいてもよい。情報統合部２２１は、抽象サービスに属さない具体サービスに関しての情報は、具体サービスのサービス情報として、提示部２３２に渡す。

【0105】

コンテンツ受信部２３１は、コンテンツを受信する。具体的には、コンテンツ受信部２３１は、放送サービスで配信されるコンテンツや、ネット配信サービスで配信されるコンテンツを受信する。コンテンツ受信部２３１が受信するコンテンツのデータは、動画や、音声や、テキスト等の情報を含んでいる。コンテンツ受信部２３１は、受信したコンテンツの信号を、適宜復調し、また復号し、動画や音声やテキストを提示するために提示部２３２に渡す。

【0106】

なお、コンテンツ受信部２３１は、例えばユーザー制御入力部２０１等から、抽象サービスを受信するように指示された場合には、指示された抽象サービスを構成する複数の具体サービスのうちのいずれかの具体サービスを受信する。また、コンテンツ受信部２３１は、抽象サービスを受信するように指示されていた状況において、受信中であった当該抽象サービスに属する具体サービスを受信できない場合には、指示されていた当該抽象サービスに属する具体サービスであって、受信できない状況になった具体サービスとは異なる他の具体サービスを受信するように切り替える。このように、コンテンツ受信部２３１は、抽象サービス（抽象チャンネル）で配信されるコンテンツを受信し、ユーザーに対して提示できるようにする。

【0107】

提示部２３２は、ユーザーに対する提示を行う。提示部２３２は、視覚情報（動画、静止画、テキスト等）をディスプレイ画面に表示する。提示部２３２は、また、音声情報をスピーカー等から出力する。提示部２３２が、視覚情報や音声情報以外の情報をユーザーに対して提示する手段を持っていてもよい。

【0108】

提示部２３２は、情報統合部から渡されるサービス情報をユーザーに対して提示することができる。サービス情報の提示は、画面への表示などの方法で行われる。提示部２３２は、抽象サービスのサービス情報を提示する場合には、情報統合部２２１が統合した結果であるところの抽象サービスについてのサービス情報を提示する。
また、提示部２３２は、コンテンツ受信部２３１が受信したコンテンツをユーザーに対して提示することができる。

【0109】

図５は、本実施形態によるサービス情報提供サーバー装置３の概略機能構成を示すブロック図である。図示するように、サービス情報提供サーバー装置３は、サービスリスト取得部３０１と、サービスリスト提供部３０２とを含んで構成される。サービス情報提供サーバー装置３についても、各機能は、例えば、電子回路を用いて実現される。また、各機能部は、必要に応じて、半導体メモリーや磁気ハードディスク装置などといった記憶手段を内部に備えてよい。また、各機能を、コンピューターおよびソフトウェアによって実現するようにしてもよい。

【0110】

サービスリスト取得部３０１は、コンテンツ提供装置７から、サービスリストの情報を取得し、サービスリスト提供部３０２に渡す。

【0111】

サービスリスト提供部３０２は、上記のサービスリスト取得部３０１から受け取ったサービスリストの情報を、所定の形式（一例としては、後述するＪＳＯＮ形式）で、受信装置２に対して送信する。また、サービスリスト提供部３０２は、サービスリストの情報が更新されるべきタイミングにおいては、更新通知を受信装置2に対して送信するようにしてもよい。

【0112】

[★１]受信装置によるサービス情報の取得
次に、受信装置２が外部からサービス情報を取得するために、システム１内の各装置が持つ機能について説明する。

【0113】

図６は、受信装置２が、放送信号の受信の可否および通信によるデータの送受信の可否に応じて、各状況でサービス情報を受信するための動作の概要を示す概略図である。図示するように、受信装置２にとっては、放送受信が可能且つ通信（インターネット等のネットワークによる通信）が不可能な状況、放送受信が可能且つ通信が可能な状況、そして、放送受信が不可能且つ通信が可能な状況の３通りが考えられる。放送受信も通信も不可能な状況においてはそもそも受信装置２が外部から情報を取得することができないため、考慮しない。

【0114】

第１に、放送受信が可能且つ通信が不可能な状況において受信装置２が起動された場合、受信装置２は、放送編成情報をまず取得する。次に、受信装置２は、自装置が設けられている地域（場所）の推定を行う。地域の推定のためには、取得済みの放送編成情報を利用することも考えられる。そして、受信装置２は、取得済みの放送編成情報に基づいて、放送コンテンツ（放送サービス）を受信することが可能となる。なお、受信装置２による処理の順序は必ずしもここに記載した通りでなくてもよい（以下のケースでも同様）。

【0115】

第２に、放送受信が可能且つ通信が可能な状況において受信装置２が起動された場合、受信装置２は、放送編成情報をまず取得する。次に、受信装置２は、自装置が設けられている地域（場所）の推定を行う。地域の推定のためには、取得済みの放送編成情報を利用することも考えられる。次に、受信装置２は、ユーザー設定や地域情報（放送受信エリア）を考慮したサービスリスト（ネット配信に関するサービスリスト）を取得する。そして、受信装置２は、取得済みの放送編成情報やサービスリストに基づいて、放送コンテンツ（放送サービス）やネット配信コンテンツ（ネット配信サービス）を受信することが可能となる。

【0116】

そして、第３に、放送受信が不可能且つ通信が可能な状況において受信装置２が起動された場合、受信装置２は、ユーザー設定を考慮したサービスリスト（ネット配信に関するサービスリスト）を取得する。そして、受信装置２は、取得済みのサービスリストに基づいて、ネット配信コンテンツ（ネット配信サービス）を受信することが可能となる。

【0117】

図７は、所定の稼働環境において起動されたときに受信装置２が必要な情報を取得して自装置のセットアップを行う処理の手順を示すフローチャートである。このフローチャートで示す処理は、典型的には、受信装置２が初めて起動される時に自装置のセットアップを行うために必要な手順である。ただし、初めての起動以外の状況においても、受信装置２は、適宜、取得した情報に基づいて自装置のセットアップを行うことができる。以下、このフローチャートに沿って説明する。

【0118】

このフローチャートが実行されるのは、受信装置２が起動したときである。例えば、ユーザーが受信装置２の電源をオンすることによって受信装置が起動する。

【0119】

ステップＳ１１において、受信装置２の放送受信可否判定部２０４は、放送信号を受信可能であるか否かを判定する。放送受信可否判定部２０４は、例えば所定の放送チャンネル（単数または複数）の周波数の信号の受信を試みて、期待される信号が受信できるか否かによって放送信号の受信可否を判定する。放送受信可能である場合（ステップＳ１１：ＹＥＳ）には、次のステップＳ１２に進む。放送受信不可である場合（ステップＳ１１：ＮＯ）には、ステップＳ１５に飛ぶ。

【0120】

ステップＳ１２において、受信装置２の放送メディア利用可否情報取得部２０２は、
受信した放送信号から、放送メディア利用可否情報を取得する。放送メディア利用可否情報は、地上デジタル、ＢＳ（放送衛星）、高度ＢＳ、広帯域ＣＳ（ＣＳは、通信衛星）、高度広帯域ＣＳ、狭帯域ＣＳ、および高度狭帯域ＣＳなどといった放送メディアごとの、利用可否を表す情報である。具体的には、放送メディア利用可否情報取得部２０２は、放送信号からイベント情報テーブル（ＥＩＴ，Event Information Table）を抽出する。そして、放送メディア利用可否情報取得部２０２は、このイベント情報テーブルからコンテンツ情報を取得するためのＡＰＩを取得する。

【0121】

次にステップＳ１３において、受信装置２の選局可能チャンネル情報取得部２０３は、受信した放送信号から、選局可能編成チャンネル情報を取得する。選局可能編成チャンネル情報は、選局可能なチャンネルの、論理チャンネル番号、オリジナルネットワークＩＤ、トランスポートストリームＩＤ、サービスＩＤなどの情報である。選局可能チャンネル情報取得部２０３は、取得した選局可能編成チャンネル情報を、選局可能チャンネル情報記憶部２０５に書き込む。

【0122】

次にステップＳ１４において、受信装置２の地域推定部２０６は、受信装置２が現在稼働している地域を推定する。地域推定部２０６は、推定結果である地域の情報をサービスリスト取得部２１４に渡す。なお、本ステップにおいて、地域推定部２０６は、複数の方法のうちのいくつかを使用して地域を推定してよい。第１の方法として、地域推定部２０６は、選局可能チャンネル情報記憶部２０５を参照し、ステップＳ１３で獲得された選局可能編成チャンネル情報に基づいて地域を推定してよい。例えば、選局可能編成チャンネル情報が関東地方のチャンネルの情報を示している場合には、地域推定部２０６は現在地域が関東地方であると推定することができる。第２の方法として、地域推定部２０６は、受信装置２が備えるＧＰＳ機能（不図示）を用いて緯度および経度の情報を取得し、その緯度および経度の情報から参照テーブル等を検索することによって地域情報を推定してよい。なお、ＧＰＳは、グローバル・ポジショニング・システム（Global Positioning System）の略であり、衛星信号を用いて地上での緯度および経度等を算出する手法である。第３の方法として、地域推定部２０６は、位置情報ＡＰＩ（Geolocation API）で提供される機能を呼び出すことによって地域情報を推定してよい。位置情報ＡＰＩは、コンピューター稼働環境がウェブアプリケーションに対して位置情報を提供するための手段である。なお、地域推定部２０６は、上に記した方法のうちの複数を併用することによって地域情報を推定してもよい。

【0123】

ステップＳ１５において、受信装置２の通信可否判定部２１１は、通信ネットワークを介した通信が可能であるか否かを判定する。通信可否判定部２１１は、例えば、ＤＮＳ（Domain Name System）サーバーにアクセスしたり、既知のＵＲＬを有するサーバー装置にアクセスしたりすることによって、通信の可否を判定する。通信が可能である場合（ステップＳ１５：ＹＥＳ）には、次のステップＳ１５に進む。通信が不可である場合（ステップＳ１５：ＮＯ）には、次のステップＳ２１に飛ぶ。

【0124】

ステップＳ１６において、受信装置２のサービスリスト所在情報管理部２１３は、サービスリストのＵＲＬの初期値を参照する。この初期値のＵＲＬは、予め受信装置２内において登録（記憶）されているものである。サービスリストＵＲＬの規定値としては、例えば、「https://<main-url>/」、「https://<sub-url>/」などといった形のＵＲＬが受信装置２内に登録されている。ここで、<main-url>および<sub-url>は、それぞれ変数である。

【0125】

次にステップＳ１７において、受信装置２のサービスリスト所在情報管理部２１３は、サービスリストのＵＲＬの追加値を参照する。サービスリストの追加値は、例えば、ユーザー制御入力部２０１が取得してサービスリスト所在情報管理部２１３に渡すものである。つまり、サービスリスト所在情報管理部２１３は、ユーザーから入力される追加のＵＲＬを取得することができる。サービスリストＵＲＬの追加値としては、例えば「https://<user-url>/」などといった形のＵＲＬを取得可能である。ここで、<user-url>は変数である。なお、本ステップにおいて、ユーザーが既存のサービスリストあるいはサービスリストＵＲＬに関して、編集（サービスあるいはＵＲＬの追加や削除など）を行えるようにしてもよい。

【0126】

次にステップＳ１８において、受信装置２のサービスリスト所在情報管理部２１３は、ステップＳ１６およびＳ１７で取得したサービスリストのＵＲＬを用いて、ＡＰＩの情報を取得する。ＡＰＩは、サービス情報提供サーバー装置３によって提供されるものである。具体的には、受信装置２のサービスリスト所在情報管理部２１３は、上記の「https://<main-url>/」や「https://<sub-url>/」や「https://<user-url>/」などのＵＲＬを用いる。

【0127】

サービス情報提供サーバー装置３は、予め定められているパラメーターや語彙の他に、schema.org、iotschema.orgなどといった外部の語彙定義を使用したり、独自のＡＰＩおよびパラメーターを拡張したりすることができる。サービスリスト所在情報管理部２１３は、上記のステップＳ１８の処理によって、拡張ＡＰＩ等の情報を取得することができる。

【0128】

次にステップＳ１９において、受信装置２のサービスリスト取得条件決定部２１２は、サービスリスト取得条件の設定および決定を行う。具体的には、ユーザー制御入力部２０１が、ユーザーから入力されるサービスリスト取得条件の情報を、サービスリスト取得条件決定部２１２に渡す。サービスリスト取得条件決定部２１２は、ユーザーから入力（設定）された取得条件や、上で述べた登録ＵＲＬあるいは拡張ＵＲＬや、地域推定部２０６によって推定された地域情報（推定が行われた場合）などを基に、サービスリスト取得条件を設定する。つまり、サービスリストを取得するための条件としては、予め受信装置２に登録されていたＵＲＬの他に、ユーザーからの設定や、地域推定の結果を用いることができる。

【0129】

次にステップＳ２０において、受信装置２のサービスリスト取得部２１４は、サービスリスト取得リクエストを実行する。つまり、サービスリスト取得部２１４は、ステップＳ１９において決定した取得条件にしたがって、例えばＡＰＩを呼び出すことによって、サービス情報提供サーバー装置３からサービスリストを取得する。サービスリストは、例えばＪＳＯＮ形式のデータとしてサービス情報提供サーバー装置３から受信装置２に送られる。ＪＳＯＮは、「JavaScript Object Notation」（JavaScriptのオブジェクト記法を用いたデータ交換フォーマット）の略である。ただし、サービスリストのデータの形式はＪＳＯＮ形式には限定されず、他の形式であってもよい。サービスリスト取得部２１４は、取得したサービスリストのデータを、サービスリスト記憶部２１５に書き込む。サービスリストのデータの構成については、後で別の図面を参照しながら説明する。ステップＳ２０におの処理の実行後には、ステップＳ２１に移る。

【0130】

なお、受信装置２がサービス情報提供サーバー装置３からサービスリストを取得した際に、サービス情報提供サーバー装置３がコンテンツ提供装置７（コンテンツ提供事業者の装置）側に対して、サービスリストの提供があった事実を表す情報を渡すようにしてもよい。

【0131】

ステップＳ２１において、受信装置２は、上で取得した編成チャンネルの情報と、上で取得したサービスリストの情報とを、統合的に提示する。つまり、情報統合部２２１は、選局可能チャンネル情報記憶部２０５から読み出した選局可能な編成チャンネルの情報と、サービスリスト記憶部２１５から読み出したサービスリストの情報とを統合する。なお、放送の編成チャンネルの情報は、放送信号内に含まれるＥＩＴ（イベント情報テーブル）の情報などである。情報統合部２２１は、統合した情報を提示部２３２に渡す。提示部２３２は、渡された統合情報を、ユーザーに提示する。具体的には、提示部２３２は、その統合情報を画面に表示する。また、提示部２３２は、その統合情報を音声の形で出力するようにしてもよい。これらにより、受信装置２は、上記の統合された情報を出力する。ユーザーは、選局可能チャンネルの情報とサービスリストの情報とを、統合的に把握することが可能になる。つまり、ユーザーは、放送の編成チャンネルの情報と、サービスリストの情報とを、例えば相互に関連付けて統合した形態の視覚情報等として把握することが可能になる。ユーザーは、提示部２３２が提示した情報に基づき、各サービスの内容を把握し、視聴したいサービスを選択することができるようになる。提示部２３２による提示のしかたの例については、後で別の図を参照しながら説明する。

【0132】

なお、情報統合部２２１は、予め定められた順序（優先順位）にしたがって、あるいは取得したサービスリスト内において定義された順序（優先順位）にしたがって、ユーザーに提示するためのサービスの情報を生成する。また、情報統合部２２１は、ユーザーによる設定に基づいて、サービスの順序（優先順位）を変更することができるようにしてもよい。

【0133】

次にステップＳ２２において、受信装置２は、ユーザーからのサービスのリクエストを受け付ける。つまり、ステップＳ２１において提示したサービスリストに基づき、ユーザーは特定のサービスをリクエストすることができる。ユーザー制御入力部２０１は、ユーザーがリクエストしたサービスを特定するための情報を受け付ける。ユーザー制御入力部２０１は、指定されたサービスをコンテンツ受信部２３１に伝える。

【0134】

次にステップＳ２３において、コンテンツ受信部２３１は、サービスのリクエストを実行する。具体的には、放送チャンネル（サービス）を受信する場合には、コンテンツ受信部２３１は、ユーザーによって指定されたチャンネル（サービス）を選局する動作を行う。また、ネット配信サービスを受信する場合には、コンテンツ受信部２３１は、ユーザーによって指定されたサービスに対応するサービス配信サーバー装置４に対して、リクエストを送信する。これらにより、コンテンツ受信部２３１は、ユーザーがリクエストしたサービスを受信することができるようになる。

【0135】

次にステップＳ２４において、受信装置２は、サービスを受信し、ユーザーに提示する。具体的には、次の通りである。コンテンツ受信部２３１は、ステップＳ２３においてリクエストしたサービスのコンテンツを受信する。つまり、放送によってコンテンツが配信される場合には、コンテンツ受信部２３１は、放送信号を受信し、信号の復調および復号を行い、そのコンテンツの映像や音声を得て、それらの映像や音声を提示部２３２に渡す。通信（ネット配信）によってコンテンツが配信される場合には、コンテンツ受信部は、通信でコンテンツのデータを受信し、復号を行うことによってそのコンテンツの映像や音声を得て、それらの映像や音声を提示部２３２に渡す。提示部２３２は、コンテンツ受信部２３１から渡された映像や音声をユーザーに提示する。即ち、提示部２３２は、映像等を画面に表示し、音声をスピーカー等から出力する。

【0136】

次にステップＳ２５において、受信装置２は、編成チャンネル情報とサービスリストとを更新するか否かを判定する。具体的には、受信装置２が編成チャンネル情報とサービスリストを更新するのは、例えば、受信装置２自体の位置が変わった（ユーザーが受信装置２とともに移動した）ことによって地域情報が変わるときや、通信によるネット配信サービスの受信状況が変動したときや、ユーザーの操作によって明示的に更新処理を行うことが指示されたときなどである。編成チャンネル情報とサービスリストとを更新する場合（ステップＳ２５：ＹＥＳ）には、ステップＳ１１に戻る。編成チャンネル情報とサービスリストとを更新しない場合（ステップＳ２５：ＮＯ）には、本フローチャート全体の処理（編成チャンネル情報とサービスリストの取得）を終了する。本フローチャートの処理の終了後にも、受信装置２は、サービスを受信して提示する処理を継続することができる。なお、本フローチャートの処理が終了した場合にも、必要が生じたときなどに随時、受信装置２が本フローチャートの処理を再実行するようにしてよい。

【0137】

以上説明した処理により、受信装置２は、受信可能なサービスに関する情報のセットアップを行うことができる。つまり、受信装置２は、初期セットアップ時（設置されて初めて稼働する時）や、クライ移設された後の時に、サービス情報を取得することができる。
また、受信装置２は、放送サービスやネット配信サービスの配信状況の更新に動的に対応することができる。また、受信装置２は、取得条件に基づいて限定された情報を取得するようにできるため、サービス情報の取得時間の短縮化や、サービス情報提供サーバー装置３側への負荷軽減を図ることができる。

【0138】

[★２]受信装置におけるサービス情報の統合
次に、受信装置２が、取得したサービス情報（放送の編成サービス情報とネット配信サービスのサービス情報）とを統合して抽象サービスを生成する処理について説明する。

【0139】

図８は、本実施形態の受信装置２が、放送の編成サービス情報とインターネット等の通信でのネット配信サービスの情報と取得して、これら両方の情報を統合することによって抽象サービスを生成するまでの、一連の流れを示すシーケンス図である。以下、この図の流れに沿って説明する。

【0140】

ステップＳ５１において、受信装置２は、サービス情報提供サーバー装置３から、サービス情報を取得する。既に説明したように、サービスに関する情報は、サービスリストという形でサービス情報提供サーバー装置３から提供される。なお、本ステップにおいて、受信装置２は、通信ネットワーク（インターネット等）を介して、サービス情報を取得する。

【0141】

次に、ステップＳ５２において、受信装置２は、放送送出装置５から、編成チャンネル情報を取得する。編成チャンネル情報は、放送における編成チャンネル（サービス）に関する情報を含むものである。なお、本ステップにおいて、受信装置２は、放送信号を受信し、その放送信号内から編成チャンネル情報を抽出する。具体的には、受信装置２は、放送信号内のＳＩ（Service Information、サービス情報）に含まれる編成チャンネル情報を取得する。

【0142】

次にステップＳ５３において、受信装置２の情報統合部２２１は、情報統合処理を行う。これにより、情報統合部２２１は、ステップＳ５１で取得したサービス情報と、ステップＳ５２で取得した編成チャンネル情報とを統合し、新たなサービス情報を生成する。

【0143】

次にステップＳ５４において、受信装置２は、ステップＳ５３において統合されたサービスの情報に基づいて、抽象サービスを生成する処理を行う。つまり、受信装置２は、ネット配信によるサービスと放送によるサービスとを共通に扱うための抽象サービスを生成する。

【0144】

なお、図８に示すシーケンスでは、受信装置２は、まず通信ネットワーク経由でサービスリストを取得した後で、放送信号によって編成チャンネル情報を取得している。これら両者の順序（前後関係）は任意である。例えば、逆に、受信装置２が、まず放送信号によって編成チャンネル情報を取得した後で、通信ネットワーク経由でサービスリストを取得するようにしてもよい。

【0145】

図９は、受信装置２の情報統合部２２１がネット配信サービスに関するサービス情報と放送の編成チャンネル情報（サービス情報）とを統合するための処理の手順を示すフローチャートである。以下、このフローチャートに沿って、処理手順を説明する。

【0146】

まずステップＳ７１において、受信装置２は、インターネット等の通信ネットワークを介して、サービス情報提供サーバー装置３から、ネット配信サービスに関するサービス情報（サービスリスト）を取得する。本ステップのサービス情報取得の処理については、図７のフローチャートにおいても説明した通りである。

【0147】

次にステップＳ７２において、受信装置２は、受信した放送信号から、放送の編成チャンネル情報を取得する。本ステップの編成チャンネル情報の取得の処理については、図７のフローチャートにおいても説明した通りである。

【0148】

なお、上記のステップＳ７１の処理とステップＳ７２の処理の順序を逆にしてもよい。

【0149】

次にステップＳ７３において、受信装置２の情報統合部２２１は、ステップＳ７１で取得したネット配信のサービス情報の中に含まれるサービスに関して、照合のためのキーとなるＩＤ（識別情報）を抽出する。具体的には、情報統合部２２１は、各サービスのサービスＩＤ（service ID）および系列ＩＤ（affiliation ID）を抽出する。なお、ステップＳ７１で取得したサービス情報の中に複数のサービスが含まれる場合には、情報統合部２２１は、各々のサービスについて上記のサービスＩＤおよび系列ＩＤを抽出する。系列ＩＤを持たないサービスが存在していてもよい。そのようなサービスについては、系列ＩＤが「nil」であるものとして以後の処理を行ってよい。

【0150】

次にステップＳ７４において、受信装置２の情報統合部２２１は、ステップＳ７２で取得した放送のサービス情報（ＳＩ、編成チャンネル情報）に含まれるサービスに関して、照合のためのキーとなるＩＤを抽出する。具体的には、情報統合部２２１は、各放送サービスのサービスＩＤ（service ID）および系列ＩＤ（affiliation ID）を抽出する。なお、ステップＳ７２で取得したサービス情報の中に複数のサービスが含まれる場合には、情報統合部２２１は、各々のサービスについて上記のサービスＩＤおよび系列ＩＤを抽出する。系列ＩＤを持たないサービスが存在していてもよい。そのようなサービスについては、系列ＩＤが「nil」であるものとして以後の処理を行ってよい。

【0151】

次にステップＳ７５において、受信装置２の情報統合部２２１は、ネット配信サービスのサービス情報から取り出したサービスＩＤ（ネットサービスＩＤとも呼ぶ）と、放送サービスのサービス情報から取り出したサービスＩＤとの間で、等しいものがあるか否かを判定する。両方のサービスＩＤが等しい組み合わせがある場合（ステップＳ７５：ＹＥＳ）には、それらのサービスの組について、ステップＳ７６の処理に移る。両方のサービスＩＤが異なる組合せについて（ステップＳ７５：ＮＯ）は、それらのサービスの組については、ステップＳ７６の処理をスキップしてステップＳ７７に移る。

【0152】

ステップＳ７６に進んだ場合、同ステップにおいて、受信装置２の情報統合部２２１は、サービスＩＤの等しいネット配信サービスと放送サービスとの組について、それら両方のサービスを同一のサービスとして統合する。言い換えれば、情報統合部２２１は、サービスＩＤの等しいネット配信サービスと放送サービスとを、同一の抽象サービス（抽象チャンネル）に属するサービスとして扱う。

【0153】

次にステップＳ７７において、受信装置２の情報統合部２２１は、ネット配信サービスのサービス情報から取り出した系列ＩＤ（ネット系列ＩＤとも呼ぶ）と、放送サービスのサービス情報から取り出した系列ＩＤとの間で、等しいものがあるか否かを判定する。両方の系列ＩＤが等しい組み合わせがある場合（ステップＳ７７：ＹＥＳ）には、それらのサービスの組について、ステップＳ７８の処理に移る。両方の系列ＩＤが異なるサービスの組合せについて（ステップＳ７７：ＮＯ）は、それらのサービスの組については、ステップＳ７８の処理をスキップしてステップＳ７９に移る。

【0154】

ステップＳ７８に進んだ場合、同ステップにおいて、受信装置２の情報統合部２２１は、系列ＩＤの等しいネット配信サービスと放送サービスとの組について、それら両方のサービスを同一のサービスとして統合する。言い換えれば、情報統合部２２１は、系列ＩＤの等しいネット配信サービスと放送サービスとを、同一の抽象サービス（抽象チャンネル）に属するサービスとして扱う。

【0155】

次にステップＳ７９において、受信装置２の情報統合部２２１は、ステップＳ７６およびＳ７８のそれぞれにおいて、同一の抽象サービスに属するサービスとすることになったサービス（ネット配信サービス、放送サービス）を束ねて、抽象サービスを生成する。情報統合部２２１は、生成する抽象サービスには、新たなサービスＩＤ（識別情報）を付与する。情報統合部２２１は、生成する抽象サービスのサービス情報内において、統合される前の元のサービスに関する情報も維持する。

【0156】

このフローチャートの処理においては、情報統合部２２１は、サービスＩＤや系列ＩＤをキーとして、複数のサービスを一つの抽象サービス（抽象チャンネル）として統合した。情報統合部２２１は、その他の情報を用いてサービスの統合を行ってもよい。また、このフローチャートの処理においては、サービスＩＤあるいは系列ＩＤが一致する（等しい）場合に、情報統合部２２１が該当するサービスを統合して抽象サービス（抽象チャンネル）を生成するようにした。その代わりに、あるＩＤ（識別情報）が共通の集合に属する場合や、ＩＤ間の包含関係がある場合など、様々な条件に応じて複数のサービス（ネット配信サービス、および放送サービス）を束ねて抽象サービス（抽象チャンネル）を生成するようにしてもよい。

【0157】

以上の処理により、受信装置２において、情報統合部２２１は、サービスに関する情報の統合を行う。受信装置２は、統合後の情報（サービス情報、サービスリスト）を、記憶手段（半導体メモリーや、磁気ハードディスク装置など）に記憶させるようにする。

【0158】

次に、受信装置２がユーザーに対してサービスを提示する方法について説明する。

【0159】

図１０、図１１、および図１２のそれぞれは、サービスを提示する際の形態の例を示す概略図である。図１０は、受信装置２がネット配信サービスのみを受信可能な場合（放送サービスの受信は不可）における、サービスの提示例を示している。図１１は、受信装置２が放送サービスのみを受信可能な場合（ネット配信サービスの受信は不可）における、サービスの提示例を示している。そして、図１２は、受信装置２が、ネット配信サービスと放送サービスの両方を受信可能である場合の、統合されたサービスの提示例を示している。以下では、図１０、図１１、図１２のそれぞれについて順次説明する。

【0160】

図１０は、受信装置２の画面に提示されたサービスの一覧表の例を示している。ここでは、ネット配信サービスのみが提示されており、放送サービスは提示されていない。言い換えれば、ネット配信サービスのみを受信可能で放送サービスの受信ができない場合には、受信装置２の提示部２３２は、この図の例のように、ネット配信サービスのみの一覧表を提示する。この一覧表の画面では、情報が縦・横のマトリクス状に提示されている。図内における、行方向の０，１，２，３の数字は、行を参照するために便宜的に記載しているものである。また、列方向のＸ，Ａ，Ｂ，Ｃ，Ｄの英字は、列を参照するために便宜的に記載しているものである。

【0161】

列方向は、概ね、サービス提供事業者（コンテンツ配信事業者）またはその系列に対応している。ただし、列Ｘは、サービスによって配信される番組（コンテンツ）のステータスを表す情報である。列Ａは、「ＮＨＫ－Ｇ」という名称のネット配信サービスの情報を示す。列Ｂは、「〇〇テレ」という名称のネット配信サービスの情報を示す。列Ｃは、本例では、空いている列である。列Ｄは、「△△放送」という名称のネット配信サービスの情報を示す。ここに表示されるそれぞれのサービスには、ネット配信用のサービスＩＤ（net.sid）が付与されている。列ＡのサービスのサービスＩＤは、１０２４である。列ＢのサービスのサービスＩＤは、１０３６である。列ＤのサービスのサービスＩＤは、１０６０である。

【0162】

なお、どの列（Ａ，Ｂ，Ｃ，Ｄ等）にどのサービスを配置するかは、受信装置２の設定情報や、所定の配置ルールに基づいて決められる。

【0163】

行方向は、概ね、サービス内における番組（コンテンツ）のステータスに対応している。想定している事項として、この図で示しているサービスは、ＶＯＤではなく、決められたスケジュールにしたがって番組（コンテンツ）が配信されるスタイルのものである。行０は、各サービスの名称を表示するための行である。行１は、配信済みの番組（コンテンツ）の情報を表示するための行である。配信済みの番組（コンテンツ）は、いわゆる見逃し配信が可能であるため、行１の列Ｘには「見逃し」と表示されている。行２は、現在配信中の番組（コンテンツ）の情報を表示するための行である。行３は、その次に配信される予定の番組（コンテンツ）の情報を表示するための行である。

【0164】

図示する例では、マトリクス内に、ネット配信サービスによる９個の番組情報（コンテンツ情報）が表示されている。便宜的に、Ａ列に表示されている番組情報を、Ａ１ｎ、Ａ２ｎ、およびＡ３ｎとしている。また、Ｂ列に表示されている番組情報を、Ｂ１ｎ、Ｂ２ｎ、およびＢ３ｎとしている。また、Ｄ列に表示されている番組情報を、Ｄ１ｎ、Ｄ２ｎ、およびＤ３ｎとしている。個々の番組情報（コンテンツ情報）は、番組名称、配信開始時刻、配信終了時刻、番組の概略を表すテキスト、番組出演者情報、番組制作者情報、サムネール画像等を含んでいてもよい。

【0165】

図１１は、受信装置２の画面に提示されたサービスの一覧表の例を示している。図１１では、放送サービスのみが提示されており、ネット配信は提示されていない。言い換えれば、放送サービスのみを受信可能で、ネット配信サービスの受信ができない場合には、受信装置２の提示部２３２は、この図の例のように、放送サービスのみ一覧表を提示する。一覧表の画面がマトリクス状の提示であることは、図１０の場合と同様である。

【0166】

図１１では、列Ａは、「ＮＨＫ－Ｇ」という名称の放送サービスの情報を示す。列Ｂは、「〇〇テレ」という名称の放送サービスの情報を示す。列Ｃは、「ＴＶ□□」という名称の放送サービスの情報を示す。列Ｄは、本例では、空いている列である。ここに表示されるそれぞれのサービスには、放送用のサービスＩＤ（b.sid）が付与されている。列ＡのサービスのサービスＩＤは、１０２４である。列ＢのサービスのサービスＩＤは、１０３６である。列ＣのサービスのサービスＩＤは、１０５０である。

【0167】

行方向に、見逃し（行１）、現在（行２）、次番組（行３）といった順で番組情報（コンテンツ情報）が配置される点は、図１０の場合と同様である。

【0168】

図示する例では、マトリクス内に、ネット配信サービスによる９個の番組情報（コンテンツ情報）が表示されている。便宜的に、Ａ列に表示されている番組情報を、Ａ１ｂ、Ａ２ｂ、およびＡ３ｂとしている。また、Ｂ列に表示されている番組情報を、Ｂ１ｂ、Ｂ２ｂ、およびＢ３ｂとしている。また、Ｃ列に表示されている番組情報を、Ｃ１ｂ、Ｃ２ｂ、およびＣ３ｂとしている。

【0169】

図１２は、受信装置２の画面に提示されたサービスの一覧表の例を示しているものであり、ここでは、ネット配信サービスのサービス情報と放送サービスのサービス情報とを統合して、抽象サービス（抽象チャンネル）のサービス情報として提示しているものである。言い換えれば、ネット配信サービスと放送サービスの両方を受信することができる状況において、受信装置２は、図１０に示したネット配信サービスの情報と図１１に示した放送サービスの情報とを統合し、抽象サービスのサービス情報（図１２）を提示している。一覧表の画面がマトリクス状の提示であることは、図１０や図１１の場合と同様である。

【0170】

図１２では、列Ａは、「ＮＨＫ－Ｇ」という名称の抽象サービスの情報を示す。この抽象サービスは、図１０の列Ａに示したネット配信サービス（Net.sid＝1024）と、図１１の列Ａに示した放送サービス（b.sid＝1024）とを統合して成るサービスである。つまり、情報統合部２２１は、これら両者のサービスＩＤが「１０２４」で同一であることから、これら両者を統合している。言い換えれば、受信装置２が、取得したサービス情報に基づいてこの抽象サービス（抽象チャンネル）を生成している。列Ｂは、「〇〇テレ」という名称の抽象サービスの情報を示す。列Ａの場合と同様に、この抽象サービスは、図１０の列Ｂに示したネット配信サービス（Net.sid＝1036）と、図１１の列Ｂに示した放送サービス（b.sid＝1036）とを統合して成るサービスである。列Ｃは、「ＴＶ□□」という名称の抽象サービスの情報を示す。ただし、列Ｃの抽象サービス（抽象チャンネル）は、放送サービス（図１１の列Ｃ（b.sid=1050））のみを構成要素とするサービスであって、これに対応するネット配信サービスは存在しない。列Ｄは、「△△放送」という名称の抽象サービスの情報を示す。ただし、列Ｄの抽象サービス（抽象チャンネル）は、ネット配信サービス（図１０の列Ｄ（Net.sid=1060））のみを構成要素とするサービスであって、これに対応する放送サービスは存在しない。

【0171】

図１２に示す例では、マトリクス内に、抽象サービス（抽象チャンネル）による１２個の番組情報（コンテンツ情報）が表示されている。便宜的に、Ａ列に表示されている番組情報を、Ａ１ａ、Ａ２ａ、およびＡ３ａとしている。また、Ｂ列に表示されている番組情報を、Ｂ１ａ、Ｂ２ａ、およびＢ３ａとしている。また、Ｃ列に表示されている番組情報を、Ｃ１ａ、Ｃ２ａ、およびＣ３ａとしている。また、Ｄ列に表示されている番組情報を、Ｄ１ａ、Ｄ２ａ、およびＤ３ａとしている。

【0172】

以上説明したように、受信装置２の情報統合部２２１は、ネット配信のサービス情報と放送のサービス情報とを統合し、抽象サービス（抽象チャンネル）を生成する。また、提示部２３２は、抽象サービスのサービス情報をユーザー等に対して提示する。なお、図１０、図１１、図１２で示した提示の形態は、単なる一例であり、異なる形態でそれぞれのサービス情報を提示するようにしてもよい。

【0173】

[★３]受信装置におけるサービス情報の更新
図１３は、本実施形態の受信装置２が、取得済みのサービス情報を更新するための一連の処理の流れを示すシーケンス図である。以下、この図の流れに沿って説明する。

【0174】

ステップＳ１０１において、受信装置２は、サービス情報提供サーバー装置３から、ネット配信サービスに関するサービス情報を取得する。本ステップの処理は、図８におけるステップＳ５１の処理と同様の処理である。

【0175】

次に、ステップＳ１０２において、受信装置２は、放送送出装置５から、編成チャンネル情報を取得する。本ステップの処理は、図８におけるステップＳ５２の処理と同様の処理である。

【0176】

なお、ステップＳ１０１の処理とステップＳ１０２の処理の順序は、逆でもよい。つまり、ネット配信サービスに関するサービス情報と放送の編成チャンネル情報とを受信装置２が取得する順序は、任意である。

【0177】

ステップＳ１０３は、オプショナルな処理（図内に「opt」と表記）である。即ち、サービス情報提供サーバー装置３からサービス情報の更新通知が送信された場合には、ステップＳ１０３において、受信装置２は、その更新通知を受信する。

【0178】

ステップＳ１０４もまた、オプショナルな処理（図内に「opt」と表記）である。即ち、放送送出装置５から流動編成関連付属情報が送信された場合には、ステップＳ１０４において、受信装置２は、その流動編成関連付属情報を受信する。受信装置２は、放送信号内から、その流動編成関連付属情報を抽出する。

【0179】

ステップＳ１０５において、受信装置２は、サービス情報に関する更新判定の処理を行う。更新判定処理の詳細については、後で説明する。

【0180】

ステップＳ１０５における判定結果に応じて、判定結果が真（true）のときには、受信装置２は、ステップＳ１０６において、サービス情報の更新を行う。即ち、受信装置２は、サービス情報提供サーバー装置３から、更新情報を取得し、内部に保持しているサービス情報を更新する。

【0181】

なお、ここで説明したステップＳ１０３、Ｓ１０４、Ｓ１０５、Ｓ１０６の処理を適宜繰り返して行うようにしてもよい。つまり、受信装置２は、例えば所定の時間間隔でサービス情報の更新判定の処理を行い、その判定結果が「真」のときには随時サービス情報の更新を行うようにしてよい。

【0182】

受信装置２は、既に取得しているサービス情報に記述している有効期限が満了したときや、サービス情報提供サーバー装置３からサービス情報の更新通知を受信したときや、放送信号に含まれる流動編成関連付属情報を種痘したときや、放送信号に含まれるイベントリレー記述子をしゅとうしたときなどに、下に説明するサービス情報更新判定処理を行う。即ち、受信装置２は、その更新判定の結果にしたがって、サービス情報を更新すべきとき（更新条件が真のとき）には、サービス情報提供サーバー装置３から更新情報を受け取って、サービス情報の更新を行う。なお、サービス情報内において不整合がある場合（例えば、更新タイミングの競合等が行ったことにより複数のサービス間においてサービス情報の不整合が生じる場合）には、所定の優先順位に基づいて、優先して解釈すべきサービス情報を設定する。言い換えれば、受信装置２は、サービス情報を更新する際の、サービス間での優先順位を予め設定しておくようにしてよい。

【0183】

図１４は、受信装置２が持つサービス情報を更新するための処理の手順の例を示すフローチャートである。以下、このフローチャートに沿って説明する。

【0184】

まずステップＳ１２１において、受信装置２は、インターネット等の通信ネットワークを介して、サービス情報提供サーバー装置３から、ネット配信サービスに関するサービス情報（サービスリスト）を取得する。本ステップのサービス情報取得の処理については、図７のフローチャートにおいても説明した通りである。

【0185】

次にステップＳ１２２において、受信装置２は、受信した放送信号から、放送の編成チャンネル情報を取得する。本ステップの編成チャンネル情報の取得の処理については、図７のフローチャートにおいても説明した通りである。

【0186】

なお、上記のステップＳ１２１の処理とステップＳ１２２の処理の順序を逆にしてもよい。

【0187】

次にステップＳ１２３において、受信装置２は、受信した放送信号から、イベントグループ記述子（event_group_descriptor）を抽出する。イベントグループ記述子は、ＥＩＴ（イベント情報テーブル）内に存在する記述子であり、ＡＲＩＢ ＴＲ－Ｂ１４において規定されるものである。

【0188】

次にステップＳ１２４において、受信装置２は、受信した放送信号から、流動編成関連付属情報（user_nibble）を抽出する（図１３のステップＳ１０４）。具体的には、受信装置２は、content_nibble=「0xE0」が指定された際に、流動編成関連付属情報（user_nibble）を抽出する。流動編成関連付属情報（user_nibble）については、ＡＲＩＢ ＳＴＤ－Ｂ１０およびＡＲＩＢ ＴＲ－Ｂ１４に規定される。

【0189】

次にステップＳ１２５において、受信装置２は、サービス情報更新通知を抽出する（図１３のステップＳ１０３）。

【0190】

ステップＳ１２６において、取得した情報を基に、更新条件が真であるか否かを判定する。更新条件については、下で説明する。更新条件が真である場合（Ｓ１２６：ＹＥＳ）には、次のステップＳ１２７に進む。更新条件が偽（false）である場合（Ｓ１２６：ＮＯ）には、再度情報を取得して更新条件の判定を行うために、次のステップＳ１２３に戻る。

【0191】

ステップＳ１２６における更新条件は、例えば、次の通りである。
更新条件：
１）イベントグループ記述子（event_group_descriptor）が「null」ではないこと、
または、２）流動編成関連付属情報（user_nibble）の値が、１６進数表記における０ｘ００から０ｘ０Ｆまで、あるいは０ｘ１０から０ｘ１Ｆであること、
または、３）更新サーバー情報（update_server_info）が「true」であること。

【0192】

なお、上記の更新サーバー情報（update_server_info）については次の通りである。即ち、サービス情報提供サーバー装置３からサービス情報の更新通知（プッシュ通知等）を受信したり、既に受信装置２側で保持していたサービス情報の有効期限が到来したりしたときに、受信装置２自身が更新サーバー情報（update_server_info）の値を「true」に設定しておく。

【0193】

ステップＳ１２７に進んだ場合には、同ステップにおいて受信装置２は、サービス情報提供サーバー装置３から更新用のサービス情報を受信し、自装置において保持するサービス情報を更新する。

【0194】

次にステップＳ１２８において、受信装置は、更新判定時刻（上記のステップＳ１２６における判定を行った時刻）と、ステップＳ１２７で取得したサービス情報の更新時刻との、前後関係の比較を行う。即ち、本ステップにおいて、受信装置２は、取得したサービス情報の更新時刻が更新判定の時刻よりも遅い（大きい、新しい）か否かを判定する。取得したサービス情報の更新時刻が更新判定の時刻よりも遅い場合（ステップＳ１２８：ＹＥＳ）には、本フローチャート全体の処理を終了する。取得したサービス情報の更新時刻が更新判定の時刻よりも早い（小さい、古い）場合または同時刻である場合（ステップＳ１２８：ＮＯ）には、ステップＳ１２７に戻る。即ち、サービス情報の更新が反映されていなかった場合には、ステップＳ１２７における更新版のサービス情報の取得をリトライすることとなる。なお、ここで取得リトライ回数に上限を設けてもよい。その場合には、取得リトライ回数を超えてリトライしても更新が反映されていない場合には、受信装置２は、その場での更新を少なくとも一旦はあきらめて、サービス情報の取得を中断する。

【0195】

なお、ステップＳ１２８では時刻に基づいて更新済みの情報であるか否かを判定することとしたが、代わりに、他の方法で更新が反映されているか否かの判定を行うようにしてもよい。一例としては、サービス情報の内容に基づいて、更新が反映されているか否かの判定を行ってもよい。

【0196】

なお、受信装置２は、サービス情報の更新に関して、次のようにしてもよい。例えば、受信装置２が放送信号からイベントリレー送出情報（イベントグループ記述子）や流動編成関連付属情報を抽出した場合において、通信ネットワーク経由でサービス情報の更新版を取得するまでの間は、放送信号から得られるサービス情報を優先的に扱うようにしたり、通信ネットワークから得られたサービス情報を無効にしたりしてもよい。また、サービス情報提供サーバー装置３からプッシュ通知される更新情報に更新後のサービス情報が含まれている場合には、そのサービス情報提供サーバー装置３からの最新のサービス情報を放送からの情報よりも優先的に扱ったり、放送から得られたサービス情報を無効にしたりしてもよい。

【0197】

以上説明したように、受信装置２は、サービス情報の更新を適切に行うことができる。

【0198】

次に、サービスリストの構成について、例を参照しながら説明する。以下で説明する例は、受信装置２の情報統合部２２１によって統合された結果のサービス情報（サービスリスト）である。

【0199】

図１５は、サービスリストの構成の例（第１例）を示す概略図である。サービスリストのデータは、例えば、図示するように、入れ子構造のブロックのデータとして構成することができる。図示する例では、ブロック８０１は、本サービスリストの全体に対応するブロックである。ブロック８０１は、ブロック８０２、８０３、および８０４を内部に含む。

【0200】

ブロック８０２は、更新日時の情報を含むブロックである。更新日時の情報を参照することにより、新たなサービスリストがリリースされたときに、受信装置２は、内部に保持するサービスリストの情報を更新すべきかどうかの判断の基準とすることができる。ブロック８０３は、地域情報を含むブロックである。地域情報は、当該サービスリストが対象とする地域（例えば、日本全国）を表す情報である。ブロック８０４は、アイテムリストのブロックである。アイテムリストのブロックは、さらに内部に個々のアイテムの情報を持つ。個々のアイテムは、１つの抽象的なサービスに対応するものである。本図の例では、アイテムリストのブロック８０４は、ブロック８１１および８１２を持つ。ブロック８１１および８１２は、それぞれ、アイテムのブロックである。ブロック８１１は、「ＮＨＫ ＢＳプレミアム」というサービスのブロックである。このブロック８１１は、さらに内部に、ブロック８１２および８１３を含む。ブロック８１２および８１３のそれぞれは、ブロック８１１が表す「ＮＨＫ ＢＳプレミアム」というサービスを構成する、より具体的なサービスに対応するものである。即ち、ブロック８１２は、ＩＳＤＢ―Ｔによる放送サービス（放送チャンネル）に関する情報を持つものである。また、ブロック８１３は、ＭＰＥＧ－ＤＡＳＨ Ｄｙｎａｍｉｃの方式によるネット配信のサービスに関する情報を持つものである。

【0201】

なお、図１５に示したサービスリストの構成は単なる例であり、ここに例示したもの以外の情報をサービスリストが持つようにしてもよい。例えば、サービスごとの提示優先順位の情報をサービスリスト内に持つようにしてもよい。つまり、ブロック８１１で表わされる「ＮＨＫ ＢＳプレミアム」について、ブロック８１２のＩＳＤＢ―Ｔと、ブロック８１２のＭＰＥＧ－ＤＡＳＨ Ｄｙｎａｍｉｃとのうちで、どちらの手段による提示を優先するかを表す順位の情報を持つようにしてもよい。また、さらに他の情報をサービスリスト内に持つようにしてもよい。

【0202】

図１６，図１７，図１８，図１９は、サービスリストのデータの記述例（第１例）を示す概略図である。図１６から図１９までで、１件のサービスリストのデータを示す。便宜的に、データの各行に行番号を付して示している。図示するように、本例のサービスリストは、ＪＳＯＮ形式で記述されている。ここに示すサービスリストのデータは、図１５で説明した構成例に対応するものである。

【0203】

以下においても説明するように、このサービスリストの記述例（第１例）では、１つの抽象サービスに対応して、放送サービス（ＩＳＤＢ－Ｔ）とネット配信サービス（ＭＰＥＧ－ＤＡＳＨ Ｄｙｎａｍｉｃ）の２つのサービスが定義されている。つまり、このサービスリストの記述例（第１例）は、放送サービスに関するサービス情報と、ネット配信サービスに関するサービス情報とを統合した結果を表している。

【0204】

図１６の第１行目は、当該データ（サービスリスト）全体のブロックの始まりを示す。当該ブロックの終わりは、第１０６行目（図１９）である。
第３行目は、当該データのタイプがアイテムリスト（ItemList）であることを示す。
第４行目は、当該データの名称がサービスリスト（Service List）であることを示す。

【0205】

第５行目は、当該サービスリストの更新日時（dateModified）を示すデータである。日時の表現形式は「ＹＹＹＹ－ＭＭ－ＤＤＴｈｈ：ｍｍ：ｓｓ」である。本例では、更新日時は、「２０１８年４月２６日０８時００分００秒」である。「＋０９：００」はタイムゾーンが協定世界時よりも９時間進んでいること（日本標準時）を示している。この更新日時のデータは、図１５におけるブロック８０２に該当する。

【0206】

第６行目から第１５行目までは、「area」と示されたデータであり、地域情報である。本例では、この地域情報は、ＩＤ＝１の「関東広域」と、ＩＤ＝２３の「東京」とを含んでいる。この地域情報は、図１５におけるブロック８０３に該当する。

【0207】

第１６行目は、アイテムリストのブロックの始まりを示す。当該アイテムリストの終わりは、第１０５行目（図１９）である。当該アイテムリストは、図１５におけるブロック８０４に該当する。このアイテムリストの内部には、２つのリストアイテムを含む。その第１のリストアイテムは、「ＮＨＫ ＢＳプレミアム」という名称を持つサービスに対応するものである。その第２のリストアイテムは、「ＮＨＫ ＢＳ１」という名称を持つサービスに対応するものである。

【0208】

第１７行目は、上記第１のリストアイテムのブロックの始まりを示す。当該リストアイテムの終わりは、第６３行目（図１７）である。当該ブロックは、図１５におけるブロック８１１に該当する。
第１８行目は、当該ブロックのタイプがリストアイテム（ListItem）であることを示す。
第２１行目は、当該リストアイテムを識別するためのＩＤが「bsp.nhk.or.jp」であることを示す。
第２２行目は、当該リストアイテムの名称（name）が「ＮＨＫ ＢＳプレミアム」であることを示す。
第２３行目は、当該リストアイテム（サービス）に関するサムネール（画像）のＵＲＬを記述するものである。
第２５行目から第２８行目までは、当該リストアイテム（サービス）についてのコンテンツリスト（ContentList）の情報を持つブロックである。

【0209】

図１７に移って、第２９行目から第６１行目までは、当該サービス（抽象サービス）に含まれる２つのサービスを定義する情報である。

【0210】

ここでの２つのサービスの第１は、「ＩＳＤＢ－Ｔ」という名称を持つサービスである。第３０行目から第５３行目までのブロックは、この「ＩＳＤＢ－Ｔ」のサービスに関する情報を示している。当該ブロックは、図１５におけるブロック８１２に該当する。当該ブロックにおいては、放送資源にアクセスするための情報が定義されている。具体的には、ネットワークＩＤ（network_id）が４であり、トランスポートストリームＩＤ（ts_id）が１６４００であり、サービスＩＤ（service_id）が１５１であることが定義されている。また、当該サービスの優先度（priority）が１００であることが定義されている。

【0211】

上記２つのサービスの第２は、「ＭＰＥＧ－ＤＡＳＨ Ｄｙｎａｍｉｃ」という名称を持つサービスである。第５４行目から第６０行目までのブロックは、この「ＭＰＥＧ－ＤＡＳＨ Ｄｙｎａｍｉｃ」のサービスに関する情報を示している。当該ブロックは、図１５におけるブロック８１３に該当する。当該ブロックにおいては、ネット配信の資源にアクセスするための情報が定義されている。具体的には、ストリーム配信のＵＲＬ（streamUrl）が「example.net/bsp.mpd」であることが定義されている。また、当該サービスの優先度（priority）が２０であることが定義されている。

【0212】

図１８に移って、第６４行目は、上記第２のリストアイテムのブロックの始まりを示す。当該リストアイテムの終わりは、第１０４行目（図１９）である。当該ブロックは、図１５におけるブロック８２１に該当する。
第６５行目は、当該ブロックのタイプがリストアイテム（ListItem）であることを示す。
第６８行目は、当該リストアイテムを識別するためのＩＤが「bsp.nhk.or.jp」であることを示す。
第６９行目は、当該リストアイテムの名称（name）が「ＮＨＫ ＢＳ１」であることを示す。
第７０行目は、当該リストアイテム（サービス）に関するサムネール（画像）のＵＲＬを記述するものである。

【0213】

第７１行目から第１０２行目（図１９）までは、当該サービス（抽象サービス）に含まれる２つのサービスを定義する情報である。

【0214】

ここでの２つのサービスの第１は、「ＩＳＤＢ－Ｔ」という名称を持つサービスである。第７２行目から第９４行目までのブロックは、この「ＩＳＤＢ－Ｔ」のサービスに関する情報を示している。当該ブロックは、図１５におけるブロック８２２に該当する。当該ブロックにおいては、放送資源にアクセスするための情報が定義されている。具体的には、ネットワークＩＤ（network_id）が４であり、トランスポートストリームＩＤ（ts_id）が１６４００であり、サービスＩＤ（service_id）が１５１であることが定義されている。また、当該サービスの優先度（priority）が１００であることが定義されている。

【0215】

図１９に移る。上記２つのサービスの第２は、「ＭＰＥＧ－ＤＡＳＨ Ｄｙｎａｍｉｃ」という名称を持つサービスである。第９５行目から第１０１行目までのブロックは、この「ＭＰＥＧ－ＤＡＳＨ Ｄｙｎａｍｉｃ」のサービスに関する情報を示している。当該ブロックは、図１５におけるブロック８２３に該当する。当該ブロックにおいては、ネット配信の資源にアクセスするための情報が定義されている。具体的には、ストリーム配信のＵＲＬ（streamUrl）が「example.net/bsp.mpd」であることが定義されている。また、当該サービスの優先度（priority）が２０であることが定義されている。

【0216】

図２０は、サービスリストの構成の記述例（第２例）を示す概略図である。図１５の場合と同様に、サービスリストのデータは、入れ子構造のブロックのデータとして構成される。この第２例では、ブロック８３１は、本サービスリストの全体に対応するブロックである。ブロック８３１は、ブロック８３２、８３３、および８３４を内部に含む。

【0217】

ブロック８３２は、更新日時の情報を含むブロックである。ブロック８３３は、地域情報を含むブロックである。ブロック８３４は、アイテムリストのブロックである。アイテムリストのブロックは、さらに内部に単数または複数のアイテムの情報を持つことができる。個々のアイテムは、１つの抽象的なサービスに対応するものである。本例では、アイテムリストのブロック８３４は、１個のアイテムに対応するブロック８４１を持つ。ブロック８４１は、「ＮＨＫ総合・東京」というサービスに関する情報を持つブロックである。このブロック８４１は、さらに内部に、ブロック８４２、８４３、および８４４を含む。ブロック８４２は、図１５におけるブロック８１２等と同様に、ＩＳＤＢ―Ｔによる放送サービス（放送チャンネル）に関する情報を持つものである。ブロック８４４は、図１５におけるブロック８１３等と同様に、ＭＰＥＧ－ＤＡＳＨ Ｄｙｎａｍｉｃの方式によるネット配信のサービスに関する情報を持つものである。

【0218】

また、ブロック８４３は、図２０のサービスリストに特有のものであり、上記の放送サービスに関して、「系列ＩＤおよび系列名」についての情報を持つものである。本例では、ブロック８４３は、「ＮＨＫ総合」という名称の系列に関する情報（系列ＩＤ等）を持つ。つまり、ブロック８４１によって定義される「ＮＨＫ総合・東京」という放送サービスが、「ＮＨＫ総合」という系列に属するものであることを、ブロック８４３の情報は表している。本例の「ＮＨＫ総合」という系列は、各地の放送局における「ＮＨＫ総合・××」（ここで「××」は放送局（地域）を表す名称）を関連付けるものである。なお、放送サービスの系列は、同一の事業者（法人）が持つ複数の放送局（放送サービス）の系列であってもよいし、複数の異なる事業者（法人）がそれぞれ持つ放送局（放送サービス）を束ねるための系列であってもよい。

【0219】

図２１，図２２，図２３は、サービスリストのデータの記述例（第２例）を示す概略図である。図２１から図２３までで、１件のサービスリストのデータを示す。便宜的に、データの各行に行番号を付して示している。本例のサービスリストも、ＪＳＯＮ形式で記述されている。ここに示すサービスリストのデータは、図２０で説明した構成例に対応するものである。

【0220】

図２１の第１行目は、当該データ（サービスリスト）全体のブロックの始まりを示す。当該ブロックの終わりは、第８０行目（図２３）である。当該ブロックは、図２０におけるブロック８３１に該当する。
第３行目は、当該データのタイプがアイテムリスト（ItemList）であることを示す。
第４行目は、当該データの名称がサービスリスト（Service List）であることを示す。

【0221】

第５行目は、当該サービスリストの当初公開日時（datePublished）を示す。
第６行目は、当該サービスリストの更新日時（dateModified）を示す。
第５行目および第６行目における日時の表現形式は「ＹＹＹＹ－ＭＭ－ＤＤＴｈｈ：ｍｍ：ｓｓ」である。本例では、当初公開日時および更新日時はともに、「２０２２年４月２０日１４時４０分３１秒」である。「＋０９：００」はタイムゾーンが協定世界時よりも９時間進んでいること（日本標準時）を示している。この更新日時のデータは、図２０におけるブロック８３２に該当する。

【0222】

第７行目から第１６行目までは、「area」と示されたデータであり、地域情報である。本例では、この地域情報は、ＩＤ＝１の「関東広域」と、ＩＤ＝２３の「東京」とを含んでいる。この地域情報は、図２０におけるブロック８３３に該当する。

【0223】

第１７行目は、アイテムリストのブロックの始まりを示す。当該アイテムリストは、図２０におけるブロック８３４に該当する。このアイテムリストの内部には、１つのリストアイテムを含む。そのリストアイテムは、「ＮＨＫ総合・東京」という名称を持つサービスに対応するものである。

【0224】

第１８行目は、上記のリストアイテムのブロックの始まりを示す。当該ブロックは、図１５におけるブロック８４１に該当する。
第１９行目は、当該ブロックのタイプがリストアイテム（ListItem）であることを示す。
第２２行目は、当該リストアイテムを識別するためのＩＤが「tokyo.gtv.nhk.or.jp」であることを示す。
第２３行目は、当該リストアイテムの名称（name）が「ＮＨＫ・総合 東京」であることを示す。
第２４行目は、当該リストアイテム（サービス）に関するサムネール（画像）のＵＲＬを記述するものである。
第２８行目から第３１行目までは、当該リストアイテム（サービス）についてのコンテンツリスト（ContentList）の情報を持つブロックである。

【0225】

図２２に移って、第３２行目から始まるブロックは、当該サービス（抽象サービス）に含まれる２つのサービスと、１つの拡張記述（系列ＩＤの情報の記述）を定義するものである。

【0226】

ここでの２つのサービスの第１は、「ＩＳＤＢ－Ｔ」という名称を持つサービスである。第３３行目から第５３行目までのブロックは、この「ＩＳＤＢ－Ｔ」のサービスに関する情報を示している。当該ブロックは、図２０におけるブロック８４２に該当する。当該ブロックにおいては、放送資源にアクセスするための情報が定義されている。具体的には、オリジナルネットワークＩＤ（original_network_id）が３２７３６であり、トランスポートストリームＩＤ（transport_stream_id）が３２７３６であり、サービスＩＤ（service_id）が１０２４であることが定義されている。また、当該サービスの優先度（priority）が１００であることが定義されている。

【0227】

第５４行目から第６５行目までのブロックは、前記の拡張記述（extendedBroadcasterDescription、拡張放送事業者記述）である。当該ブロックは、図２０におけるブロック８４３に該当する。当該ブロックにおいては、この抽象サービスに関する系列情報が定義されている。具体的には、第５５行目から第５９行目までのブロックは、系列ＩＤ（affiliation_id）が０であることを定義している。また、第６０行目から第６４行目までのブロックは、系列名称（affiliation_name）が「ＮＨＫ総合」であることを定義している。

【0228】

図２３に移る。上記２つのサービスの第２は、「ＭＰＥＧ－ＤＡＳＨ Ｄｙｎａｍｉｃ」という名称を持つサービスである。第６９行目から第７５行目までのブロックは、この「ＭＰＥＧ－ＤＡＳＨ Ｄｙｎａｍｉｃ」のサービスに関する情報を示している。当該ブロックは、図２０におけるブロック８４４に該当する。当該ブロックにおいては、ネット配信の資源にアクセスするための情報が定義されている。具体的には、ストリーム配信のＵＲＬ（streamUrl）が「https://example.net/test/manifest.mpd」であることが定義されている。また、当該サービスの優先度（priority）が２０であることが定義されている。

【0229】

以上説明したように、サービスリストのデータの記述例（第２例）は、系列情報を含むものである。

【0230】

図２４は、上記の実施形態における受信装置２や、サービス情報提供サーバー装置３や、サービス配信サーバー装置４や、放送送出装置５や、コンテンツ情報提供サーバー装置６や、コンテンツ提供装置７などといた装置の内部構成の例を示すブロック図である。これらのそれぞれの装置の少なくとも一部の機能は、コンピューターを用いて実現され得る。なお、放送信号の受信に関しては、受信装置２が受信した高周波の信号に関して、例えば復号処理以後の処理についてコンピューターでの実現が可能である。図示するように、そのコンピューターは、中央処理装置９０１と、ＲＡＭ９０２と、入出力ポート９０３と、入出力デバイス９０４や９０５等と、バス９０６と、を含んで構成される。コンピューター自体は、既存技術を用いて実現可能である。中央処理装置９０１は、ＲＡＭ９０２等から読み込んだプログラムに含まれる命令を実行する。中央処理装置９０１は、各命令にしたがって、ＲＡＭ９０２にデータを書き込んだり、ＲＡＭ９０２からデータを読み出したり、算術演算や論理演算を行ったりする。ＲＡＭ９０２は、データやプログラムを記憶する。ＲＡＭ９０２に含まれる各要素は、アドレスを持ち、アドレスを用いてアクセスされ得るものである。なお、ＲＡＭは、「ランダムアクセスメモリー」の略である。入出力ポート９０３は、中央処理装置９０１が外部の入出力デバイス等とデータのやり取りを行うためのポートである。入出力デバイス９０４や９０５は、入出力デバイスである。入出力デバイス９０４や９０５は、入出力ポート９０３を介して中央処理装置９０１との間でデータをやりとりする。バス９０６は、コンピューター内部で使用される共通の通信路である。例えば、中央処理装置９０１は、バス９０６を介してＲＡＭ９０２のデータを読んだり書いたりする。また、例えば、中央処理装置９０１は、バス９０６を介して入出力ポートにアクセスする。

【0231】

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

【0232】

上の実施形態の説明において、ＡＰＩとは、Application Program Interface（アプリケーション・プログラム・インターフェース）の略である。つまり、各装置の機能をプログラムで実現する場合に、プログラムから所定のサービスを呼び出すために規定されているインターフェースが、ＡＰＩである。

【0233】

以上、実施形態を説明したが、本発明はさらに変形例で実施するようにしてもよい。また、本発明の具体的な構成は、ここまでに説明した実施形態に限られるものではなく、その技術的要旨を逸脱しない範囲の設計等を含んでもよい。

【0234】

以下、図２５から図６４を参照しながら、他の実施形態について説明する。図１から図２４を参照しながら説明した構成と、図２５から図６４を参照しながら説明する構成とは、異なる構成に対して同一の符号を付す場合がある。すなわち、同一の符号が異なる構成に付されている場合があるが、これらは互いに異なるものである。

【0235】

まず、本発明の一実施形態の背景技術について説明する。従来、放送規格に則ってコンテンツの情報を放送信号として配信する技術、およびオープンな通信技術を用いてコンテンツの情報をインターネット等の通信ネットワークを介して配信する技術（ネット配信技術と呼ぶ）が、それぞれ利用されている。ここで、コンテンツとは、主として映像および音声の情報として構成されるものである。上記の放送技術およびネット配信技術をそれぞれ用いて、同一のコンテンツあるいは関連性の深いコンテンツを、放送信号およびネット配信の両方で配信することは、従来技術においても可能である。また、従来の放送では、コンテンツ（番組）そのものが配信されるとともに、番組配列情報が配信されている。

【0236】

しかしながら従来技術では、放送とネット配信の両方で同一のコンテンツあるいは内容が関連するコンテンツが配信されていても、受信装置の側ではそれら両者を関連付けた制御を行うことができないという問題があった。例えば、放送とネット配信の両方でコンテンツが配信されている場合であっても、受信装置がそれらのコンテンツのうちネット配信のコンテンツを受信している状況において、放送で配信されるコンテンツだけしか受信できなくなった（通信状況の問題等）場合には、継続してコンテンツを受信し続けることができない。逆に、受信装置がそれらのコンテンツのうち放送のコンテンツを受信している状況において、ネット配信のコンテンツだけしか受信できなくなった（放送信号の受信品質の低下の問題等）場合には、継続してコンテンツを受信し続けることができない。

【0237】

受信装置が例えば放送でのコンテンツの受信からネット配信での同一コンテンツの受信に切り替えるためには、受信装置は、そのネット配信にアクセスするための情報（ＵＲＬ等）を取得したり、そのネット配信に適合するアプリケーションプログラム（以下において単に「アプリ」と呼ぶ場合がある）を起動したりする必要がある。

【0238】

また、従来技術では、受信装置は、どの放送コンテンツとどのネット配信コンテンツが関連するものであるかを表す情報を把握することもできない。これらにより、受信装置は、放送コンテンツとネット配信コンテンツとを統一された処理フローでハンドリングすることもできない。

【0239】

言い換えれば、受信装置は、あるコンテンツを代替し得る代替コンテンツを受信して再生するための仕組みを持たない。従来技術における放送信号のＳＩ（service information）には、代替コンテンツに関する情報が含まれない。代替コンテンツを受信して再生する仕組みの一つは、複数のコンテンツを統合して成る統合コンテンツに関する情報（統合コンテンツ情報）を保持して利用することである。この場合には、統合コンテンツに関連付けられる複数の具体コンテンツのそれぞれを取得するための情報を、統合コンテンツ情報として保持し、参照することができる。

【0240】

また、統合コンテンツに複数の（多数の）具体コンテンツが関連付けられている場合には、それらの複数の具体コンテンツのうちの特定の具体コンテンツを取得する方法を妥当な方法で決定する必要がある。

【0241】

本発明の一実施形態は、上記の課題認識に基づいて行なわれたものであり、複数のコンテンツを統合的に管理するために各コンテンツに関するコンテンツ情報を統合して利用できる手段を提供しようとするものである。特に、本発明は、統合されたコンテンツ情報に含まれる複数の具体コンテンツのうちのいずれかを取得する方法を適切に決定するためのコンテンツ取得方法決定装置することのできるコンテンツ情報統合装置およびプログラムを提供しようとするものである。

【0242】

次に、本発明の一実施形態について、図面を参照しながら説明する。なお、実施形態を説明する際に、略語を用いる場合がある。代表的な略語の意味は、次の通りである。即ち、ＥＰＧは、Electronic Programming Guide（電子番組表）の略である。また、ＥＲ図は、Entity Relationship Diagramを表す。また、ＪＳＯＮ（ジェイソン）は、JavaScript Object Notation（ジャバスクリプトオブジェクト記述方法）の略である。また、ＯＴＴは、Over the Topの略であり、インターネットを用いたコンテンツの配信の形態を表す語である。また、ＳＩは、Service Informationの略である。また、ＵＲＬは、Uniform Resource Locator（ユニフォームリソースロケーター）の略である。また、ＶＯＤは、Video on Demand（ビデオオンデマンド）の略である。

【0243】

まず、課題を解決するための技術構成の概略を説明する。あるコンテンツ（ここでは便宜的に「主コンテンツ」と呼ぶ）とそのコンテンツを代替し得る代替コンテンツとの関係の例は、次に挙げる通りである。主コンテンツが放送コンテンツであるとき、その代替コンテンツの一例は、別の放送コンテンツ（別の放送事業者によって、あるいは別のチャンネルで、あるいは別の放送日時に放送されるコンテンツ）である。また、主コンテンツが放送コンテンツであるとき、その代替コンテンツの一例は、ネットでの同時配信（ライブ配信）のコンテンツである。また、主コンテンツが放送コンテンツであるとき、その代替コンテンツの一例は、ネットでのビデオオンデマンド（ＶＯＤ）で配信されるコンテンツである。また、主コンテンツがネット配信（ＶＯＤ）であるとき、その代替コンテンツの一例は、放送コンテンツである。また、主コンテンツがネット配信（ＶＯＤ）であるとき、その代替コンテンツの一例は、別のネット配信（ＶＯＤ）である。また、主コンテンツが放送コンテンツであるとき、その代替コンテンツの一例は、ウェブページ（例えば、その放送コンテンツに対応する番組ホームページ）である。また、主コンテンツが放送コンテンツであるとき、その代替コンテンツの一例は、ソーシャルネットワーキングサービス（ＳＮＳ；例えば、その放送コンテンツに対応する番組ＳＮＳ）である。

【0244】

受信装置（コンテンツ情報統合装置）は、主コンテンツを代替し得る他のコンテンツが何であるかを知っている必要がある。そのために、複数のコンテンツのコンテンツ情報を統合して成る統合コンテンツ情報を、受信装置は参照する。

【0245】

受信装置（コンテンツ情報統合装置）は、受信装置は、受信している放送コンテンツについて、放送信号に含まれるＥＰＧ情報と、その放送コンテンツ（番組）に対応する他のコンテンツのコンテンツ情報とを取得する。受信装置は、コンテンツ情報提供サーバー装置から通信によってコンテンツ情報を取得することができる。受信装置は、これらの情報を基に、抽象コンテンツを生成する。抽象コンテンツは、複数の具体的コンテンツを含むように定義される。言い換えれば、抽象コンテンツは、複数の提供方法のいずれかによって提供され得る。それぞれの具体的コンテンツに関しては、配信方法およびルート情報が定義される。配信方法は、放送による配信であるかネット配信（通信）による配信であるかを区別する。また、配信方法がネット配信である場合には、配信方法はさらに、ライブ配信であるかビデオオンデマンド（ＶＯＤ）であるかを区別する。また、配信方法がネット配信である場合には、配信方法は必要に応じてさらに配信のために使用される通信プロトコルを区別する。放送による配信である場合には、ルート情報は、例えば、オリジナルネットワークＩＤ、トランスポートストリームＩＤ、およびサービスＩＤの３つ組の情報である。ネット配信である場合には、ルート情報は、例えば、ＵＲＬとして表わされる。

【0246】

なお、抽象コンテンツは、複数の具体コンテンツを統合して成るものであり、「統合コンテンツ」とも呼ばれる。統合コンテンツに関する情報は、統合コンテンツ情報と呼ばれる。

【0247】

受信装置は、放送信号の受信状況や通信状況等の理由によってある具体的コンテンツを取得できないときに、その具体的コンテンツが属する抽象コンテンツの定義に基づいて代替コンテンツの情報を取得し、その代替コンテンツを取得し、再生することができる。

【0248】

あるコンテンツに対応して複数の代替コンテンツが存在する場合には、受信装置は、それら複数の代替コンテンツの中から最も適切かつ取得可能な代替コンテンツを選択して取得する。即ち、受信装置は、コンテンツを発見することができる。

【0249】

図２５は、本実施形態によるコンテンツ発見システムの概略機能構成を示すブロック図である。図示するように、コンテンツ発見システム１は、受信装置２と、コンテンツ情報提供サーバー装置３と、サービス情報提供サーバー装置４と、コンテンツプロバイダー装置５Ａと、コンテンツ配信装置７と、放送送出装置８とを含んで構成される。コンテンツ発見システム１を構成する各装置の機能は、例えば、コンピューターと、プログラムとで実現することが可能である。また、各機能部は、必要に応じて、記憶手段を有する。記憶手段は、例えば、プログラム上の変数や、プログラムの実行によりアロケーションされるメモリーである。また、必要に応じて、磁気ハードディスク装置やソリッドステートドライブ（ＳＳＤ）といった不揮発性の記憶手段を用いるようにしてもよい。また、各装置の少なくとも一部の機能を、プログラムではなく専用の電子回路として実現してもよい。

【0250】

受信装置２は、コンテンツ取得するとともに、取得したコンテンツをユーザーに提示する。具体的には、受信装置２は、インターネット等の通信回線を介して、コンテンツ配信装置７から配信されるコンテンツを受信することができる。また、受信装置２は、放送信号によって、放送送出装置８から配信されるコンテンツを受信することができる。受信装置２は、インターネット等の通信回線を介して、コンテンツ情報提供サーバー装置３からコンテンツ情報を取得したり、サービス情報提供サーバー装置４からサービス情報を取得したりすることができる。受信装置２は、コンテンツ情報提供サーバー装置３から渡されるコンテンツ情報や、放送送出装置から放送信号で渡されるコンテンツ情報や、あるいは自装置が既に保持するコンテンツ情報に基づいて、統合コンテンツ情報を生成し、保持する。統合コンテンツ情報自身も、一種のコンテンツ情報である。受信装置２は、ユーザーから指定された統合コンテンツについて、統合コンテンツ情報に基づいて、適切なコンテンツ取得方法を決定して、その方法によってコンテンツを取得し、ユーザーに提示することができる。

【0251】

なお、受信装置２は、上記の通りコンテンツ情報を統合する機能を持つものであり、「コンテンツ情報統合装置」とも呼ばれる。また、受信装置２は、統合されたコンテンツ情報（統合コンテンツ情報）に含まれる具体コンテンツのうちのいずれかを選択することによって具体コンテンツを取得するための方法を決定する機能を持つものであり、「コンテンツ取得方法決定装置」とも呼ばれる。

【0252】

コンテンツ情報提供サーバー装置３（「コンテンツ情報提供装置」と呼んでもよい。）は、インターネット等の通信回線を介して、コンテンツ情報を受信装置２に対して提供する。コンテンツ情報は、コンテンツの名称や、概要や、ジャンルや、取得方法（アクセス方法）などといった情報を含むものである。コンテンツ情報の詳細については後で説明する。

【0253】

サービス情報提供サーバー装置４は、インターネット等の通信回線を介して、サービス情報を受信装置２に対して提供する。サービス情報は、放送のサービスに関する情報である。サービス情報は、コンテンツ情報の一種である。

【0254】

コンテンツプロバイダー装置５Ａは、コンテンツを供給する事業者等が運営する装置である。コンテンツプロバイダー装置５Ａは、コンテンツ情報提供サーバー装置３やサービス情報提供サーバー装置４に対して、コンテンツの情報を供給する。コンテンツプロバイダー装置５Ａは、例えば予め規定された所定のインターフェースを介して、情報をコンテンツ情報提供サーバー装置３やサービス情報提供サーバー装置４に提供する。また、コンテンツプロバイダー装置５Ａは、コンテンツそのものを、コンテンツ配信装置７や放送送出装置８に供給する。コンテンツは、映像や音声やテキストや画像などから成るものであり、デジタルデータとして供給され得る。

【0255】

コンテンツ配信装置７は、インターネット等の通信回線を用いて、コンテンツを受信装置２に対して配信する装置である。コンテンツ配信装置７は、ブロードキャスティング方式あるいはオンデマンド方式のいずれかでコンテンツを配信することができる。コンテンツ配信装置７による配信自体は、既存の技術を用いて行われ得る。

【0256】

放送送出装置８は、放送信号によってコンテンツを受信装置２に対して配信する。放送送出装置８によるコンテンツの配信（放送）自体は、既存の技術を用いて行われ得る。

【0257】

図２６は、本実施形態による受信装置の概略機能構成を示すブロック図である。図示するように、受信装置２は、情報取得部２１Ａと、情報統合部２２Ａと、取得方法決定部２３と、コンテンツ取得部２６と、コンテンツ提示部２７と、ユーザー入力部２９とを含んで構成される。

【0258】

情報取得部２１Ａは、コンテンツに関する情報であるコンテンツ情報を取得する。具体的には、情報取得部２１Ａは、放送信号に含まれるコンテンツ情報を取得したり、外部の装置（コンテンツ情報提供サーバー装置３等）からインターネット経由で提供されるコンテンツ情報を取得したりすることができる。また、情報取得部２１Ａは、下で説明する情報統合部２２Ａが生成した統合コンテンツ情報の少なくとも一部の情報を、コンテンツ情報として取得するものであってもよい。

【0259】

つまり、情報取得部２１Ａは、放送信号（ＳＩ）によって配信されるコンテンツ情報と、通信によってコンテンツ情報提供サーバー装置３等から配信されるコンテンツ情報と、下で説明する情報統合部２２Ａが生成した統合コンテンツ情報であるところのコンテンツ情報との、少なくともいずれかを取得するものであってよい。なお、情報取得部２１Ａが放送信号によって配信されるコンテンツ情報（ＥＰＧ等）を受信する機能自体は、既存技術である。

【0260】

情報統合部２２Ａは、上記の情報取得部２１Ａが取得したコンテンツ情報に基づいて、複数（２つまたはそれ以上）のコンテンツを同定し、同定されたそれら複数のコンテンツのそれぞれに関するコンテンツ情報を統合する。これによって、情報統合部２２Ａは、統合コンテンツのコンテンツ情報である統合コンテンツ情報を生成する。情報統合部２２Ａは、生成した統合コンテンツ情報を保持する。情報統合部２２Ａは、必要に応じて、生成した統合コンテンツ情報を受信装置２内の各部に渡すことができる。つまり、情報統合部２２Ａは、生成した統合コンテンツ情報を記憶手段に記憶させるとともに、その記憶手段から読み取った統合コンテンツ情報を、受信装置２内の各部（取得方法決定部２３等）に渡すことができる。情報統合部２２Ａを、「統合情報取得部」と呼んでもよい。即ち、情報統合部２２Ａ（統合情報取得部）は、同定された複数のコンテンツのそれぞれに関するコンテンツ情報を統合して成る、統合コンテンツのコンテンツ情報である統合コンテンツ情報を、記憶手段等から取得し、取得方法決定部２３等の各部に渡すことができる。

【0261】

情報統合部２２Ａが複数のコンテンツ情報を同定する方法としては、様々な方法が考えられる。その同定方法の一つは、それぞれのコンテンツに関するコンテンツ情報が持つコンテンツ識別情報が完全に一致する場合に、それら複数のコンテンツを同定する方法である。コンテンツ識別情報は、コンテンツを一意に識別する情報である。

【0262】

放送されるコンテンツの場合に、コンテンツ識別情報は、例えば、日付（放送日付）とイベントＩＤ（イベント識別情報）とサービス（チャンネル）を特定する情報との組である。サービスを特定する情報は、例えば、オリジナルネットワークＩＤとトランスポートストリームＩＤとサービスＩＤとの３つ組として表現され得る。通信で配信されるコンテンツの場合に、コンテンツ識別情報は、一例として、日付（または日時）とＵＲＬとの組である。あるいは、通信で配信されるコンテンツのコンテンツ識別情報が、上記の放送コンテンツの識別情報と同一の形式のものであってもよい。なお、放送コンテンツの場合も通信コンテンツの場合も、ここに例示した形式以外のコンテンツ識別情報を用いるようにしてもよい。コンテンツ識別情報の具体例については、後で別の図を参照しながら説明する。

【0263】

情報統合部２２Ａは、さらに別の方法で複数のコンテンツを同定するようにしてもよい。例えば、情報統合部２２Ａは、複数のコンテンツのそれぞれについてのコンテンツ情報に基づいて、コンテンツ情報の中におけるコンテンツ同定に関する要素であって且つコンテンツを一意に識別する情報であるコンテンツ識別情報以外の要素、が少なくとも部分的に一致することによって同定可能である場合に、それら複数のコンテンツを同定して、それら複数のコンテンツのコンテンツ情報を統合して、統合コンテンツ情報を生成してよい。つまり、情報統合部２２Ａは、上記のコンテンツ識別情報に依らずに、複数のコンテンツを同定することができる場合がある。

【0264】

そのような同定方法の具体例を、列挙する。第１例として、複数のコンテンツのそれぞれにおける物理的な配信に関する情報（それぞれのコンテンツに関するコンテンツ情報内に含まれる情報）が一致する場合に、情報統合部２２Ａは、それら複数のコンテンツを同定することが可能である。第２例として、複数のコンテンツのそれぞれにおける配信日時とコンテンツ名称とに関する情報が一致する場合に、情報統合部２２Ａは、それら複数のコンテンツを同定することが可能である。第３例として、複数のコンテンツのそれぞれの配信のための所在情報が一致する場合に、情報統合部２２Ａは、それら複数のコンテンツを同定することが可能である。ここで、所在情報とは、例えば、インターネット等を用いた通信の場合におけるＵＲＬである。また、所在情報は、放送の場合には放送サービスを特定する情報であってもよい。放送サービスは、オリジナルネットワークＩＤとトランスポートストリームＩＤとサービスＩＤの３つ組の情報によって特定可能である。なお、上記の「コンテンツ情報の中におけるコンテンツ同定に関する要素であって且つコンテンツを一意に識別する情報であるコンテンツ識別情報以外の要素、が少なくとも部分的に一致することによって同定可能である場合」として、これらの第１例から第３例までの他に、さらに他の場合があってもよい。

【0265】

情報統合部２２Ａは、統合コンテンツ情報を生成する際には、その統合コンテンツを構成するそれぞれの具体コンテンツの取得方法に関する情報を、生成する統合コンテンツ情報内に含めるようにする。つまり、情報統合部２２Ａは、同定された複数のコンテンツのそれぞれが持っていたコンテンツの取得方法の情報を、統合コンテンツ情報内に含めるようにする。つまり、情報統合部２２Ａによって生成される統合コンテンツ情報は、その統合コンテンツに関連付けられるそれぞれのコンテンツ（具体コンテンツ）の取得方法に関する情報を含むものである。

【0266】

取得方法決定部２３は、情報統合部２２Ａが生成した統合コンテンツ情報を受け取る。また、取得方法決定部２３は、その統合コンテンツ情報を参照することによって、特定の統合コンテンツに関連付けられるコンテンツ（具体的なコンテンツ）のうちのいずれかを、取得対象のコンテンツとして決定する。

【0267】

つまり、取得方法決定部２３は、特定の統合コンテンツについての統合コンテンツ情報を参照することによって、当該統合コンテンツに関連付けられる複数の前記コンテンツのうちのいずれかを取得対象のコンテンツとして決定する。統合コンテンツ情報は、統合コンテンツに関連付けられるそれぞれのコンテンツの取得方法に関する情報を含むものである。即ち、取得方法決定部２３は、１つのコンテンツの取得方法を決定することができる。ここで、取得方法とは、取得手段が放送であるか通信であるかの区別や、放送の場合には取得対象の放送サービスや日時等を特定することや、通信の場合には取得対象のコンテンツの所在情報（ＵＲＬ）や日時等を特定することである。

【0268】

取得方法決定部２３は、例えば、具体コンテンツごとに定められている優先度にしたがって、複数の具体コンテンツの中から取得対象のコンテンツを決定してよい。また、取得方法決定部２３は、複数の具体コンテンツの中から、最も豊かな表現を含む具体コンテンツを取得対象のコンテンツとして決定してよい。例えば、映像と音声とから成る具体コンテンツと、音声のみから成る具体コンテンツと、テキストのみから成る具体コンテンツとの中からは、最も豊かな表現を含むものである映像と音声とから成る具体コンテンツが取得対象のコンテンツとして決定される。取得方法決定部２３が特定の具体コンテンツを決定すると、その具体コンテンツの取得方法（ＵＲＬ等）は、当該具体コンテンツに関するコンテンツ情報の中から取得することができる。

【0269】

コンテンツ取得部２６は、コンテンツ配信装置７や放送送出装置８から配信されるコンテンツを取得する。具体的には、コンテンツ取得部２６は、放送信号で配信されるコンテンツや、インターネット等の通信回線を介した通信で配信されるコンテンツを取得する。なお、コンテンツ取得部２６は、取得方法決定部２３が決定した方法（統合コンテンツ情報の中で規定されている、通信の場合における取得元の特定のサービスの情報、あるいは通信の場合における取得元の特定のＵＲＬ等の情報など）によってコンテンツを取得する。即ち、コンテンツ取得部２６は、取得方法決定部２３によって決定された取得対象のコンテンツを取得する。即ち、コンテンツ取得部２６は、取得方法決定部２３によって決定された取得対象のコンテンツを、統合コンテンツ情報に基づいて取得するものである。

【0270】

コンテンツ提示部２７は、コンテンツ取得部２６が取得したコンテンツをユーザーが視聴できる形態で提示する。具体的には、コンテンツ提示部２７は、映像をディスプレイ装置に表示したり、音声をスピーカー等から出力したり、文字あるいは画像をディスプレイ装置に表示したりする。

【0271】

ユーザー入力部２９は、ユーザーが操作するリモコン装置等からの入力信号を受け付ける。つまり、ユーザー入力部２９は、ユーザーからの受信装置２に対する操作の信号を受け付ける。例えば、統合コンテンツのリストが表示されている状態において、ユーザーはリモコン装置等を操作することによって特定の統合コンテンツを選択することができる。ユーザー入力部２９は、その信号の意味を解釈することによって、ユーザーが選択した統合コンテンツ（ユーザーが視聴したい統合コンテンツ）を特定するための情報を得る。あるいはユーザー入力部２９は、受信装置２のオン／オフに関する信号を受け付けることもできる。あるいはユーザー入力部２９は、受信装置２がコンテンツ情報等を外部から取得する動作を行うための指示を受け付けることもできる。

【0272】

図２７は、本実施形態によるコンテンツ情報提供サーバー装置の概略機能構成を示すブロック図である。図示するように、コンテンツ情報提供サーバー装置３は、コンテンツ情報登録受付部３１と、コンテンツ情報データベース３２と、コンテンツ情報提供部３３とを含んで構成される。

【0273】

コンテンツ情報登録受付部３１は、コンテンツプロバイダー装置５Ａ側から渡されるコンテンツ情報の登録を受け付ける。コンテンツ情報登録受付部３１は、受け付けたコンテンツ情報をコンテンツ情報データベース３２に格納することができる。

【0274】

コンテンツ情報データベース３２は、コンテンツ情報を保持して管理するデータベースである。コンテンツ情報データベース３２は、コンテンツ情報登録受付部３１から渡されるコンテンツ情報や、その他の方法で取得するコンテンツ情報を、保持することができる。また、コンテンツ情報提供部３３からの要求に応じて、コンテンツ情報データベース３２は、保持しているコンテンツ情報をコンテンツ情報提供部３３に渡すことができる。

【0275】

コンテンツ情報提供部３３は、コンテンツ情報データベース３２から読み出したコンテンツ情報を適切なタイミングで受信装置２に対して提供する。コンテンツ情報提供部３３は、例えば、受信装置２側からの要求に応じて、コンテンツ情報を受信装置２に提供する。

【0276】

図２８は、本実施形態によるサービス情報提供サーバー装置の概略機能構成を示すブロック図である。図示するように、サービス情報提供サーバー装置４は、コンテンツ情報登録受付部３１と、コンテンツ情報データベース３２と、コンテンツ情報提供部３３とを含んで構成される。

【0277】

サービス情報登録受付部４１は、コンテンツプロバイダー装置５Ａ側から渡されるサービス情報の登録を受け付ける。サービス情報登録受付部４１は、受け付けたサービス情報をサービス情報データベース４２に格納することができる。

【0278】

サービス情報データベース４２は、サービス情報を保持して管理するデータベースである。サービス情報データベース４２は、サービス情報登録受付部４１から渡されるサービス情報や、その他の方法で取得するサービス情報を、保持することができる。また、サービス情報提供部４３からの要求に応じて、サービス情報データベース４２は、保持しているサービス情報をサービス情報提供部４３に渡すことができる。

【0279】

サービス情報提供部４３は、サービス情報データベース４２から読み出したサービス情報を適切なタイミングで受信装置２に対して提供する。サービス情報提供部４３は、例えば、受信装置２側からの要求に応じて、サービス情報を受信装置２に提供する。

【0280】

図２９は、コンテンツ情報に関わるエンティティとエンティティ間の関係とを表す概略図（ＥＲ図）である。このＥＲ図で表わされるデータ（コンテンツ情報）は、具体的には例えばリレーショナルデータあるいはオブジェクト指向データ等として、受信装置２から参照され得る形で記憶される。図示するように、コンテンツ情報において主要な意味を持つエンティティの一つはエンティティ「コンテンツ」である。以下で、このＥＲ図について説明する。

【0281】

エンティティ「コンテンツ」（content）は、コンテンツ名、コンテンツ概要、サムネール、ジャンル、視聴年齢制限などといった属性を持つ。コンテンツ名は、コンテンツの名称であり、例えば映像作品のタイトル（題名）等である。コンテンツ概要は、そのコンテンツの概略を表す文章を含むテキストである。サムネールは、そのコンテンツを表すサムネール画像である。ジャンルは、そのコンテンツが属するジャンル（例えば、ドラマ、スポーツ、報道、音楽等）を表すテキストあるいは記号等である。視聴年齢制限は、そのコンテンツに関する年齢制限を表す情報（例えば、制限なし、１５歳以上視聴可能、１８歳以上視聴可能等）である。エンティティ「コンテンツ」が、さらに他の属性を持ってもよい。また、エンティティ「コンテンツ」が、個々のコンテンツを一意に識別するためのコンテンツＩＤを持つようにしてもよい。１つの「コンテンツ」は、「関連コンテンツ」という関係によって、他の「コンテンツ」と関連付けられてもよい。また、１つの「コンテンツ」は、１つまたは複数の「アソシエイテッドメディア（リニア）」と関連付けられていてよい。また、１つの「コンテンツ」は、１つまたは複数の「アソシエイテッドメディア（ＶＯＤ）」と関連付けられていてよい。また、１つの「コンテンツ」は、１つまたは複数の「シリーズ」と関連付けられていてよい。

【0282】

エンティティ「シリーズ」は、コンテンツのシリーズ（例えば、ドラマのシリーズや、ドキュメンタリーコンテンツのシリーズ等）に対応するものである。エンティティ「シリーズ」は、シリーズ名、シリーズ概要、サムネールなどといった属性を持つ。シリーズ名は、シリーズの名称を表すテキストである。シリーズ概要は、そのシリーズの概略を表す文章を含むテキストである。サムネールは、そのシリーズを表すサムネール画像である。エンティティ「シリーズ」が、さらに他の属性を持ってもよい。また、エンティティ「シリーズ」が、個々のシリーズを一意に識別するためのシリーズＩＤを持つようにしてもよい。１つの「シリーズ」は、そのシリーズに属する複数の「コンテンツ」に関連付けられる。

【0283】

エンティティ「アソシエイテッドメディア（リニア）」は、コンテンツを配信するためのメディアに対応するエンティティである。「アソシエイテッドメディア（リニア）」は、コンテンツ配信サービス事業者（放送事業者やネット配信事業者等）による編成にしたがってコンテンツを配信するメディアである。エンティティ「アソシエイテッドメディア（リニア）」は、公開方式（放送編成）、公開方式（ＯＴＴ編成）などといった属性を持つ。公開方式（放送編成）は、放送での配信に使用されるメディアの資源（例えば、放送のオリジナルネットワークＩＤ、トランスポートストリームＩＤ、サービスＩＤの３つ組）を特定する情報である。公開方式（ＯＴＴ編成）は、インターネットでの配信に使用されるメディアの資源（例えば、ＵＲＬや使用プロトコル等）を特定する情報である。なお、エンティティ「アソシエイテッドメディア（リニア）」は、属性「公開方式（放送編成）」と属性「公開方式（ＯＴＴ編成）」のいずれか一方のみの属性値を持つ者であってよい。受信装置２は、コンテンツ情報内に含まれるこれらの公開方式の情報を参照することにより、実際の配信メディアにアクセスして、コンテンツを取得することが可能となる。エンティティ「アソシエイテッドメディア（リニア）」が、さらに他の属性を持ってもよい。また、エンティティ「アソシエイテッドメディア（リニア）」が、個々のシリーズを一意に識別するためのシリーズＩＤを持つようにしてもよい。

【0284】

エンティティ「アソシエイテッドメディア（ＶＯＤ）」は、コンテンツを配信するためのメディアに対応するエンティティである。「アソシエイテッドメディア（ＶＯＤ）」は、ユーザー（視聴者）が選択して要求したコンテンツを配信するメディアである。エンティティ「アソシエイテッドメディア（ＶＯＤ）」は、公開方式（ＯｎＤｅｍａｎｄ）などといった属性を持つ。公開方式（ＯｎＤｅｍａｎｄ）は、オンデマンドでのネット配信のために使用されるメディアの資源（例えば、ＵＲＬや使用プロトコル等）を特定する情報である。受信装置２は、コンテンツ情報内に含まれるこの公開方式の情報を参照することにより、実際の配信メディアにアクセスして、コンテンツを取得することが可能となる。エンティティ「アソシエイテッドメディア（ＶＯＤ）」が、さらに他の属性を持ってもよい。また、エンティティ「アソシエイテッドメディア（ＶＯＤ）」が、個々のシリーズを一意に識別するためのシリーズＩＤを持つようにしてもよい。

【0285】

エンティティ「コンテンツ」は、１つまたは複数の「アソシエイテッドメディア（リニア）」、および／または、１つまたは複数の「アソシエイテッドメディア（ＶＯＤ）」と関連付けられ得る。つまり、受信装置２は、コンテンツ情報を参照することにより、特定のコンテンツを取得するための１つまたは複数のメディアへのアクセス情報（前記の各エンティティが持つ「公開方式」の属性）を得られる。

【0286】

図３０は、コンテンツ情報に関連して、エンティティ「サービス」と関連する他のエンティティとの関係を示す概略図（ＥＲ図）である。このＥＲ図で表わされるデータ（コンテンツ情報、サービス情報）は、具体的には例えばリレーショナルデータあるいはオブジェクト指向データ等として、受信装置２から参照され得る形で記憶される。以下で、このＥＲ図について説明する。

【0287】

エンティティ「サービス」（service）は、コンテンツ配信サービスに対応するエンティティである。「サービス」は、時間順にリニアに配置された複数のコンテンツを含むものであってよい。エンティティ「サービス」は、サービス名、サムネール、サイト、コンテンツリストＵＲＬ（ｐ／ｆ）、コンテンツリストＵＲＬ（scheduled）などといった属性を持つ。サービス名は、サービスの名称（具体例としては、「ＮＨＫ Ｇ」、「ＮＨＫ Ｅ」、「ＮＨＫ ＢＳ１」等）を表すテキストである。サムネールは、そのサービスを表すサムネール画像である。コンテンツリストＵＲＫは、「ｐ／ｆ」形式のコンテンツ情報リストのネットワーク上での所在を表す情報である。「ｐ／ｆ」形式とは、リニアな配信サービス編成として、現在（present）配信中のコンテンツの情報と次（following）に配信されるコンテンツの情報とで構成される形式である。「ｐ／ｆ」形式のコンテンツリストは、コンテンツ配信の進行と同期して更新される。コンテンツリストＵＲＬ（scheduled）は、「scheduled」形式のコンテンツ情報リストのネットワーク上での所在を表す情報である。「scheduled」形式とは、現時点を起点としてＮ日分（Ｎは正整数）に配信される予定のコンテンツの情報を持つ形式である。これらのコンテンツリストは、コンテンツタイトル、コンテンツの配信日時、コンテンツの内容を表すテキスト情報等を含む。

【0288】

エンティティ「プロバイダー」（provider）は、配信事業者（放送事業者やネット配信事業者）に対応するエンティティである。エンティティ「プロバイダー」は、ｏｒｇＩＤ、系列ＩＤなどといった属性を持つ。ｏｒｇＩＤ（組織ＩＤ）は、組織（配信事業を行う事業者等の法人）をユニークに識別するための識別情報である。系列ＩＤは、事業者の系列をユニークに識別するための識別情報である。当該プロバイダー（配信事業者）は、この系列ＩＤによって表される系列に属する。系列の典型例は、テレビ放送の地域間ネットワークである。一例として、関東地域のＡ局（放送事業者）と、中京地域のＢ局（放送事業者）と、関西地域のＣ局（放送事業者）とが、１つの系列を形成する場合があり得る。あるいは別の例として、一つの放送事業者が地域ごとに複数の放送局を持ち、それらが１つの系列を形成する場合（一例として、ＮＨＫ東京放送局と、ＮＨＫ名古屋放送局と、ＮＨＫ大阪放送局など）があり得る。１つの「プロバイダー」は、１つまたは複数の「サービス」を配信する。つまり、「プロバイダー」は、１つまたは複数の「サービス」に関連付けられる。

【0289】

エンティティ「地域」（area）は、上記の「サービス」が対象とする地域に対応するエンティティである。例えば、「関東地方」あるいは「関西地方」などといった地域が、これに該当する。サービスは、特定の地域に閉じて配信される場合がある。例えば地上デジタル放送によるサービスは、特定の地域に閉じて配信される。エンティティ「地域」は、地域ＩＤ、地域名などといった属性を持つ。地域ＩＤは、地域をユニークに識別するための識別情報である。地域名は、その地域を表す名称である。地域名の例は、「関東地方」あるいは「関西地方」などといった名称である。

【0290】

エンティティ「アソシエイテッドメディア（リニア）」は、図２９において説明したエンティティ「アソシエイテッドメディア（リニア）」と同じものである。つまり、エンティティ「アソシエイテッドメディア（リニア）」は、放送編成チャンネルや、ＯＴＴリニアチャンネルに対応する。

【0291】

上記のエンティティ間の関係は、次の通りである。１つの「地域」は、１つまたは複数の「サービス」と関連付けられる。つまり１つの地域においては、１つまたは複数のサービスが配信され得る。１つの「プロバイダー」は、１つまたは複数の「サービス」と関連付けられる。１つの「サービス」は、１つまたは複数の「アソシエイテッドメディア（リニア）」と関連付けられる。

【0292】

図３１は、コンテンツリスト（コンテンツ情報）の論理的な構成を示す概略図である。コンテンツ情報提供サーバー装置３が保持するコンテンツリストや、コンテンツ情報提供サーバー装置３から受信装置２に渡されるコンテンツリストや、受信装置２が保持するコンテンツリストは、この図に示す論理的構成に基づく情報である。

【0293】

図示するように、コンテンツリストは、「CreativeWork」（クリエイティブワーク、コンテンツ、作品）、「PropertyValue」（ＩＤ値）、「VideoObject」（ビデオオブジェクト）、「AudioObject」（オーディオオブジェクト）、「MediaObject」（メディアオブジェクト）、「BroadcastEvent」（ブロードキャストイベント、放送イベント）、「OnDemandEvent」（オンデマンドイベント）などといったオブジェクト（エンティティ）に関する情報を表すデータである。

【0294】

オブジェクト「CreativeWork」は、「Identifier」（アイデンティファイアー）、「associatedMedia」（アソシエイテッドメディア）などといった属性を持つ。この「Identifier」は、前述のコンテンツＩＤに相当する。また、この「associatedMedia」については、図２９や図３０においても説明した通りである。

【0295】

オブジェクト「PropertyValue」は、クリエイティブワーク（コンテンツ）を識別するためのＩＤの値である。

【0296】

オブジェクト「VideoObject」、「AudioObject」、および「MediaObject」のそれぞれは、上記の「associatedMedia」のタイプ（種類）の例である。例えば、オブジェクト「VideoObject」は、図２９や図３０において説明したエンティティ「アソシエイテッドメディア（リニア）」に相当するものであってよい。また、オブジェクト「VideoObject」は、図２９において説明したエンティティ「アソシエイテッドメディア（ＶＯＤ）」に相当するものであってよい。オブジェクト「VideoObject」、「AudioObject」、および「MediaObject」のそれぞれは、「Publication」などといった属性を持つ。この属性「Publication」は、物理的な配信手段に関する情報である。属性「Publication」は、例えば、放送チャンネルＩＤやネット配信におけるＵＲＬなどに関する情報を、属性値として取る。

【0297】

オブジェクト「BroadcastEvent」および「OnDemandEvent」のそれぞれは、上記の属性「Publication」の値となり得るオブジェクトである。オブジェクト「BroadcastEvent」は、放送あるいはリニアなネット配信によって配信されるイベントに関するものであり、例えば、放送チャンネルＩＤ（放送の場合）や、ＵＲＬ（ネット配信の場合）や、配信日時等の情報を持つものである。オブジェクト「OnDemandEvent」は、オンデマンドなネット配信によって配信されるイベントに関するものであり、例えば、ＵＲＬ等の情報を持つものである。

【0298】

図３１においては、コンテンツリスト（コンテンツ情報）の論理的な構成を示したが、このコンテンツリストのデータは、装置内等において保持される場合には、例えば、リレーショナルデータベースあるいはオブジェクト指向データベースなどといった手段を用いて、管理・保持される。これらの情報は、磁気ハードディスク装置や半島対メモリーなどといった記憶手段によって記憶され得る。また、コンテンツリストのデータは、ある装置から他の装置に渡される際には、適宜伝送に適した形態のデータとして受け渡しが行われる。これらの情報は、有線あるいは無線のデジタル通信によって伝送され得る。伝送に適した形態のデータの一例は、ＪＳＯＮ形式のデータであるが、他の形式のデータを用いてもよい。

【0299】

図３２は、コンテンツリスト（コンテンツ情報）の論理的な構成の別態様を示す概略図である。図３１においても説明したように、コンテンツ情報提供サーバー装置３が保持するコンテンツリストや、コンテンツ情報提供サーバー装置３から受信装置２に渡されるコンテンツリストや、受信装置２が保持するコンテンツリストは、この図に示す論理的構成に基づく情報である。

【0300】

図３２に示す通り、コンテンツリストは、「CreativeWork」、「identifier」（識別情報、コンテンツＩＤ）、「associatedMedia」（配信方法情報）、「publication」（物理的な配信情報）、「isRelatedTo」（関連コンテンツ）などといったオブジェクトに関する情報を表すデータである。

【0301】

オブジェクト「CreativeWork」は、「TV Episode」（テレビのエピソード（映像番組））、「Radio Episode」（ラジオのエピソード（音声のみの番組））、あるいは「Web Page」（ウェブページ）などといった種類（タイプ）のいずれかであり得る。オブジェクト「CreativeWork」は、番組名やジャンルなどといった属性を持つ。また、オブジェクト「CreativeWork」は、属性として、上記の「identifier」、「associatedMedia」、「publication」、「isRelatedTo」などのオブジェクトに関連付けられる。

【0302】

オブジェクト「identifier」は、図３１において説明したオブジェクト「PropertyValue」に相当するものである。オブジェクト「identifier」は、「datePublished」（公開日）、「eventId」（イベント識別情報、イベントＩＤ）、「triplet」（３つ組、放送サービスを特定するための３つ組情報であるところのネットワークＩＤとトランスポートストリームＩＤとサービスＩＤの情報）、「url」（ＵＲＬ、ネット配信にアクセスするための所在情報）、「accessTime」（アクセス時刻（あるいは日時））といった情報を持ち得るものである。

【0303】

オブジェクト「associatedMedia」は、「VideoObject」（映像によるコンテンツのオブジェクト）あるいは「AudioObject」（音声のみによるコンテンツのオブジェクト）などといった種類（タイプ）のいずれかであり得る。

【0304】

オブジェクト「associatedMedia」は、「放送チャンネルＩＤ」や「ネット配信ＵＲＬ」などといった情報を持ち得るものである。

【0305】

オブジェクト「isRelatedTo」は、当該CreativeWorkから見たときに関連する他のCreativeWorkである。あるオブジェクト「CreativeWork」（インスタンス）の属性「isRelatedTo」の値は、単数または複数の他のオブジェクト「CreativeWork」（インスタンス）であってよい。一例として、ある映像ドラマ作品の「第１８話」のCreativeWork（コンテンツ）は、その次回の話のCreativeWork（コンテンツ）として当該映像ドラマ作品の「第１９話」に関連するものである。ただし、コンテンツ間の「関連」の態様は、ここで例示したものに限られず、様々な種類の「関連」であってよい。

【0306】

図３１における場合と同様に、図３２においても、コンテンツリスト（コンテンツ情報）の論理的な構成を示した。このコンテンツリストのデータは、例えば、リレーショナルデータベースあるいはオブジェクト指向データベースなどといった手段を用いて、保持され得るものである。また、このコンテンツリストのデータは、適宜伝送に適した形態のデータとして、装置間での受け渡しが行われ得るものである。

【0307】

図３３は、受信装置２が、複数のコンテンツに関するコンテンツ情報を取得してそれらのコンテンツ情報を統合し、統合されたコンテンツ情報に基づいてコンテンツを提示する処理の手順の例を示す概略図である。以下ではこの図に沿って処理手順を説明する。

【0308】

ステップＳ１において、受信装置２のユーザー入力部２９は、ユーザーからの起動要求を受け付ける。この起動要求は、例えば、リモコン装置の信号（赤外線信号等）によって伝達される。受信装置２は、起動要求に基づいて起動する。

【0309】

ステップＳ２において、起動後の受信装置２は、放送信号を受信し、サービスインフォメーション（ＳＩ）を取得する。サービスインフォメーションは、ＥＰＧ（電子番組表）のデータを含む。つまり、受信装置２は、ＥＰＧのデータを取得する。

【0310】

次にステップＳ３において、受信装置２の情報取得部２１Ａは、サービス情報提供サーバー装置４に対してサービス情報を要求する。受信装置２とサービス情報提供サーバー装置４との間の通信は、インターネットを経由して行われる。サービス情報提供サーバー装置４は、この要求を受信し、受信装置２に対して送信するためのサービス情報を準備する。

【0311】

ステップＳ４において、サービス情報提供サーバー装置４は、要求元の受信装置２に対してサービス情報を送信する。受信装置２の情報取得部２１Ａは、そのサービス情報を受信する。

【0312】

ステップＳ５において、受信装置２の情報統合部２２Ａは、サービス情報を統合する処理を行う。具体的には、同ステップにおいて、受信装置２は、複数のサービスを統合した統合サービス（統合チャンネル、抽象チャンネル、抽象サービス等とも呼ばれる）の情報を生成する。受信装置２は、任意の数の統合サービスの情報を生成してもよい。個々の統合サービスは、任意の数の具体サービスを含むものであってよい。なお、受信装置２は、ステップＳ２において放送信号から取得したサービスインフォメーションと、ステップＳ４においてサービス情報提供サーバー装置４から取得したサービス情報とを基に、複数のサービスを統合して成る統合サービスのサービス情報を生成する。

【0313】

ステップＳ６において、受信装置２の情報取得部２１Ａは、コンテンツ情報提供サーバー装置３に対して、に対してコンテンツ情報（コンテンツリスト）を要求する。受信装置２とコンテンツ情報提供サーバー装置３との間の通信は、インターネットを経由して行われる。コンテンツ情報提供サーバー装置３は、この要求を受信し、受信装置２に対して送信するためのコンテンツ情報を準備する。なお、このコンテンツ情報は、図２９、図３０、図３１、および図３２を参照しながら説明した論理構成を有するデータである。

【0314】

ステップＳ７において、コンテンツ情報提供サーバー装置３は、要求元の受信装置２に対してコンテンツ情報を送信する。受信装置２の情報取得部２１Ａは、そのコンテンツ情報を受信する。

【0315】

ステップＳ８において、受信装置２の情報統合部２２Ａは、コンテンツ情報を統合することによって統合コンテンツ（抽象コンテンツなどとも呼ばれる）についてのコンテンツ情報を生成する。具体的には、受信装置２は、複数の具体コンテンツに関するコンテンツ情報を統合することによって、それらの複数の具体コンテンツを含んだ統合コンテンツの情報を生成する。なお、受信装置２は、ステップＳ２において取得したＥＰＧのデータ内に含まれる番組（コンテンツ）の情報と、ステップＳ７においてコンテンツ情報提供サーバー装置３から取得したコンテンツ情報とに基づいて、上記の統合コンテンツのコンテンツ情報を生成する。受信装置２は、任意の数の統合コンテンツに関するコンテンツ情報を生成することができる。また、個々の統合コンテンツは、任意の数の具体コンテンツを含むものであってよい。

【0316】

ステップＳ９において、受信装置２は、ステップＳ８で生成した統合コンテンツのコンテンツ情報に基づいて、統合コンテンツのリストをユーザーに対して提示する。具体的には、受信装置２は、統合コンテンツのリストを画面等に表示する。ユーザーは画面等を見ることによって統合コンテンツのリストを視認することができる。ユーザーは、リモコン装置等を用いることによって、統合コンテンツリストの中から、視聴したい統合コンテンツを選択することができる。

【0317】

ステップＳ１０において、受信装置２のユーザー入力部２９は、ユーザーからコンテンツ再生要求を受信する。具体的には、コンテンツ再生要求は、リモコン装置等の信号として受信装置２に伝えられる。このコンテンツ再生要求は、統合コンテンツを識別する情報を含む。これにより、受信装置２は、要求された統合コンテンツを特定する。ユーザーから要求された統合コンテンツの識別情報は、取得方法決定部２３に伝えられる。

【0318】

ステップＳ１１において、受信装置２の取得方法決定部２３は、ステップＳ１０において要求された統合コンテンツの取得方法を決定する。つまり、受信装置２は、要求された統合コンテンツに含まれる複数の具体コンテンツのうち、どの具体コンテンツを取得するかを決定する。本ステップにおいて具体コンテンツが決定されると、その具体コンテンツにアクセスするための情報（放送におけるサービスを特定する情報やネット配信における所在情報（ＵＲＬ）など）が明らかになる。

【0319】

ステップＳ１２において、受信装置２のコンテンツ取得部２６は、ステップＳ１１において決定した取得方法を用いて、実際にコンテンツ（具体コンテンツ）を取得するとともに、取得したコンテンツをユーザーに対して提示する。具体コンテンツは、映像コンテンツ（映像と音声とから成るコンテンツ）であってもよいし、音声のみのコンテンツであってもよいし、ウェブページ等であってもよいし、その他の任意の形態のコンテンツであってもよい。受信装置２は、映像を画面に表示し、音声をスピーカー等（イヤフォン等を含む）から出力し、ウェブページ等の情報を画面に表示することができる。

【0320】

以上のステップＳ１からＳ１２までの処理により、受信装置２は、コンテンツ情報を統合することができ、また統合コンテンツの取得方法を決定して提示することができる。なお、受信装置２は、既に統合済みのコンテンツ情報を記憶装置等に保持しておいて、そのコンテンツ情報を利用して統合コンテンツの取得および提示を行ってもよい。

【0321】

図３４は、コンテンツ情報の統合の処理（図３３のステップＳ８）における情報の流れを示す概略図である。図示するように、受信装置２内の情報統合部２２Ａは、複数のコンテンツのそれぞれについてのコンテンツ情報を統合することにより、統合コンテンツの情報を生成する。

【0322】

次に、図３５から図３８までを参照しながら、情報統合部２２Ａがコンテンツ情報を統合する処理をさらに詳細に説明する。図３５は、「identifier」（アイデンティファイアー）の完全一致によるコンテンツの統合を示すものである。図３６は、「associatedMedia」（アソシエイテッドメディア）に従属する要素が一致することによるコンテンツの統合を示すものである。図３７や図３８は、コンテンツのassociatedMediaの要素の中のコンテンツ同定に関わる要素が一致することによるコンテンツの統合を示すものである。

【0323】

図３５は、コンテンツのidentifierの一致に基づくコンテンツの統合を説明するための概略図である。同図において、（Ａ）および（Ｂ）のそれぞれは、いずれもオブジェクト「CreativeWork」（クリエイティブワーク）のインスタンスである。ここに示すそれぞれのオブジェクトは、「identifier」（アイデンティファイアー）および「associatedMedia」（アソシエイテッドメディア）という属性を含む。図３５に示す例の場合には、情報統合部２２Ａは、両オブジェクトの属性「identifier」が完全に一致する場合に、それら両者を統合して統合コンテンツのオブジェクトを生成する。即ち、図３５に示すＡ１１の属性値とＢ１１の属性値とが完全に一致する場合に、（Ａ）および（Ｂ）のオブジェクト（コンテンツ情報）は、情報統合部２２Ａによって統合される。

【0324】

前述の通り、「identifier」（アイデンティファイアー）は、そのコンテンツを一意に識別するための情報である。「identifier」の値は、単純な数値あるいは文字列であってもよいし、何らかの構造体（オブジェクト等）であってもよい。本実施形態では、例として、放送に関するコンテンツの識別情報は、日付と、イベントＩＤと、サービスを特定する情報（オリジナルネットワークＩＤとトランスポートストリームＩＤとサービスＩＤとで構成される３つ組）との複合データである。また、例として、ネット配信のコンテンツの識別情報は、上記の放送の識別情報と同一の形式であってもよいし、ＵＲＬと日付（日時）との複合データ等であってもよい。

【0325】

図３６は、コンテンツのassociatedMediaの要素の少なくとも一部が一致することに基づくコンテンツの統合を説明するための概略図である。同図において、（Ｃ）および（Ｄ）のそれぞれは、いずれもオブジェクト「CreativeWork」（クリエイティブワーク）のインスタンスである。ここに示すそれぞれのオブジェクトは、「identifier」（アイデンティファイアー）および「associatedMedia」（アソシエイテッドメディア）という属性を含む。「identifier」（アイデンティファイアー）の値は上で説明した通りである。図示するように、「identifier」（アイデンティファイアー）の値は、例えば、「PropertyName」（属性名）と「PropertyValue」（属性値）との組の集合であってよい。これにより、複数のデータ項目からなる複合データを「identifier」（アイデンティファイアー）の値として表現できる。

【0326】

図３６の例において、（Ｃ）のオブジェクトは、「associatedMedia」（アソシエイテッドメディア）として、２つのオブジェクト「VideoObject」に関連付けられている。それらのオブジェクトのうちの１つのオブジェクト（符号Ｃ３０２）は、図に示すＣ１２に含まれるものである。また、このＣ１２に含まれるオブジェクト「VideoObject」は、属性「publication」の値として、オブジェクト「OnDemandEvent」に関連付けられている。このオブジェクト「OnDemandEvent」もまたＣ１２の範囲内に含まれる。一方で、（Ｄ）のオブジェクトは、「associatedMedia」（アソシエイテッドメディア）として、２つのオブジェクト「VideoObject」に関連付けられている。それらのオブジェクトのうちの１つのオブジェクト（符号Ｄ３０１）は、図に示すＤ１２に含まれるものである。また、このＤ１２に含まれるオブジェクト「VideoObject」は、属性「publication」の値として、オブジェクト「OnDemandEvent」に関連付けられている。このオブジェクト「OnDemandEvent」もまたＤ１２の範囲内に含まれる。情報統合部２２Ａは、（Ｃ）のオブジェクトの属性「associatedMedia」（アソシエイテッドメディア）の値の一つであるＣ１２と、（Ｄ）のオブジェクトの属性「associatedMedia」（アソシエイテッドメディア）の値の一つであるＤ１２とが一致する場合に、（Ｃ）のコンテンツ情報と（Ｄ）のコンテンツ情報とを統合して統合コンテンツのオブジェクトを生成する。つまり、図３６の例は、「associatedMedia」（アソシエイテッドメディア）の要素の少なくとも一つが、両オブジェクト間で一致する場合を示す。即ち、即ち、図３６に示す（Ｃ）のオブジェクトに関するＣ１２と（Ｄ）のオブジェクトに関するＤ１２とが完全に一致する場合に、（Ｃ）および（Ｄ）のオブジェクト（コンテンツ情報）は、情報統合部２２Ａによって統合される。

【0327】

図３７は、コンテンツのassociatedMediaの要素の中のコンテンツ同定に関わる要素が一致することに基づくコンテンツの統合の一例を説明するための概略図である。図示する（Ｅ）および（Ｆ）のそれぞれは、いずれもオブジェクト「CreativeWork」（クリエイティブワーク）のインスタンスである。ここに示すそれぞれのオブジェクトは、「identifier」（アイデンティファイアー）および「associatedMedia」（アソシエイテッドメディア）という属性を含む。図３７に示す例では、（Ｅ）のオブジェクトの「associatedMedia」（アソシエイテッドメディア）の値の一つであるオブジェクト「VideoObject」（符号Ｅ３０２）が、属性として、配信日時、組織（コンテンツ提供事業者等）、およびコンテンツ名を含んでいる（Ｅ１３）。また、（Ｆ）のオブジェクトの「associatedMedia」（アソシエイテッドメディア）の値の一つであるオブジェクト「VideoObject」（符号Ｆ３０１）が、属性として、配信日時、組織（コンテンツ提供事業者等）、およびコンテンツ名を含んでいる（Ｆ１３）。本例では、このオブジェクト「VideoObject」における配信日時と組織とコンテンツ名とのすべてが一致する場合に、両者のコンテンツ同定に関わる要素が一致すると判断される。つまり、図３７に示す例におけるＥ１３の値とＦ１３の値とが完全に一致する場合に、情報統合部２２Ａは、両者のコンテンツ同定に関わる要素が一致すると判断し、（Ｅ）のオブジェクトと（Ｆ）のオブジェクトとを統合して、統合コンテンツのオブジェクト（コンテンツ情報）を生成する。

【0328】

なお、上記の図３７の例においては、Ｅ１３側のオブジェクト「VideoObject」（符号Ｅ３０２）に関連付けられる属性「publication」は、２つの「BroadcastEvent」である。また、Ｆ１３側のオブジェクト「VideoObject」（符号Ｆ３０１）に関連付けられる属性「publication」は、１つの「OnDemandEvent」である。このように、両者間においてたとえ属性「publication」のタイプが異なって（「BroadcastEvent」と「OnDemandEvent」）いる場合でも、上記のコンテンツ同定に関わる要素が一致する場合には、情報統合部２２Ａは、統合すべき条件が満たされていると判断し、これらの（Ｅ）のオブジェクトと（Ｆ）のオブジェクトとを統合する。

【0329】

図３８は、コンテンツのassociatedMediaの要素の中のコンテンツ同定に関わる要素が一致することに基づくコンテンツの統合の別の例を説明するための概略図である。図示する（Ｇ）および（Ｈ）のそれぞれは、いずれもオブジェクト「CreativeWork」（クリエイティブワーク）のインスタンスである。ここに示すそれぞれのオブジェクトは、「identifier」（アイデンティファイアー）および「associatedMedia」（アソシエイテッドメディア）という属性を含む。図３８に示す例においては、コンテンツ同定に関わる要素は、ネット配信において受信装置２からのアクセス先となる所在情報（ＵＲＬ）である。コンテキストに依存する場合を除いて、ＵＲＬの一致に基づいてコンテンツを同定することは妥当である。

【0330】

情報統合部２２Ａがコンテンツ識別情報以外の情報に基づいて複数のコンテンツの同定を行うための条件の例を図３６から図３８までで説明したが、その他の方法によって、情報統合部２２Ａがコンテンツ識別情報以外の情報を用いてコンテンツの同定を行ってもよい。その方法は、（１）コンテンツ情報内の所定の全要素が一致することによってコンテンツの同定を行う、（２）コンテンツ情報内の要素の少なくとも一つが一致することによってコンテンツの同定を行う、（３）コンテンツ情報内の要素のうちのコンテンツ同定に関わる条件を満たす（そのために例えば所定の関数を定義してもよい）ことによってコンテンツの同定を行う、（４）「associatedMedia」（アソシエイテッドメディア）以下の情報が一致することによってコンテンツの同定を行う、といった方法を含むがこれらには限定されない。

【0331】

図３９、図４０、図４１、図４２、図４３、および図４４は、コンテンツ情報（コンテンツリスト）の具体例を示す概略図である。ここで例示するコンテンツ情報は、ＪＳＯＮ形式で記述されたデータである。ＪＳＯＮ形式は、入れ子型のブロック構造を有するテキストのデータである。ここに示す図３９から図４４までの全体が、１個のブロックとして成る１件のコンテンツ情報の例である。図３９から図４４までに示すデータの各行には、便宜的に行番号を付している。以下では、このコンテンツ情報の例について順を追って説明する。

【0332】

図３９は、コンテンツリストの第１行目から第６行目までを示す。第１行目は、コンテンツリスト全体のブロックの始まりを示す。第２行目から第６行目までは、コンテンツリストのヘッダー情報である。ヘッダー情報は、データの公開日時の情報（第５行目）や、データの変更日時の情報（第６行目）などを含む。

【0333】

図４０は、コンテンツリストの第７行目から第４５行目までを示す。第７行目は、要素「itemListElement」（アイテムリストエレメント）の始まりを示す。この要素「itemListElement」は、第７行目から第１８４行目（図４４）まで続く。上記の要素「itemListElement」の内側には、複数の要素が存在し得る。本例では、それらの要素のうちの一つは、第８行目から第１８０行目（図４４）まで続く要素である。第９行目は、当該要素のタイプ（@type）が「ListItem」であることを表している。第１０行目から第１７９行目（図４４）までは、要素「item」である。第１１行目は、当該要素「item」のコンテキスト（@context）を表す。第１２行目は、当該要素「item」のタイプ（@type）が、「TVEpisode」（テレビエピソード）であることを表す。第１３行目から第４５行目までは、当該要素「item」の属性「identifier」（アイデンティファイアー、識別情報）である。この「identifier」は、３つの要素を含む。「identifier」における１つ目の要素は、第１４行目から第１８行目までの「PropertyValue」型の要素であり、その属性名は「date」（日付）でありその属性値は「20220420」（YYYYYMMDD（年月日）の形式）である。「identifier」における２つ目の要素は、第１９行目から第２３行目までの「PropertyValue」型の要素であり、その属性名は「eventId」（イベントＩＤ、イベント識別情報）でありその属性値は「26235」である。「identifier」における３つ目の要素は、第２４行目から第４４行目までの要素「triplet」（３つ組）である。この要素「triplet」は、属性名「network_id」（オリジナルネットワークＩＤ）と属性値「32736」との対と、属性名「ts_id」（トランスポートストリームＩＤ）と属性値「32736」との対と、属性名「service_id」（サービスＩＤ）と属性値「1024」との対とを含む３つ組である。つまり、第１０行目から始まる要素「item」は、「identifier」として、日付と、イベントＩＤと、放送資源を表わす３つ組の情報とを含むものである。

【0334】

図４１は、コンテンツリストの第４６行目から第８０行目までを示す。第４６行目は、第１０行目から始まっている要素「item」の属性「name」（コンテンツ名称）を表す。本例では、このコンテンツ名称は「テレビ体操［字］」である。第４７行目は、当該要素「item」の属性「description」（コンテンツ記述、コンテンツ概略）を表す。本例では、「description」としてコンテンツ出演者らの指名の情報が記述されている。第４８行目は、データの公開日時の情報を表す。第４９行目は、データの変更日時の情報を表す。第５０行目は、当該要素「item」の「thumbnailUrl」（サムネール画像の所在（ＵＲＬ））を表す。第５２行目から第５８行目までは、要素「actor」（演者、出演者）である。この要素「actor」は、演者の氏名等の文字列のリストの情報である。第５９行目から第６３行目までは、要素「genre」（ジャンル）である。この要素「genre」は、ジャンルを表す文字列のリストの情報である。第６４行目から第７５行目までは、要素「rating」（レーティング）である。この要素「rating」は、さらに２つの要素（いずれも、タイプ（@type）は「ratingValue」）を含む。その第１は、第６５行目から第６９行目までであり、「name」（レーティング名称）の「標準化機関規定」と「value」（レーティング値）の「4」との対である。その第２は、第７０行目から第７４行目までであり、「name」（レーティング名称）の「事業者規定」と「value」（レーティング値）の「4」との対である。第７５行目は、要素「isAccessibleForFree」（無料アクセス可否の情報）であり、本例ではその値は「true」（真）である。第７７行目から第８０行目までは、要素「conditionalAccess」（条件付きアクセス）であり、この要素はさらに、その下位の要素「identifierDescriptor」（識別情報記述子）と要素「systemId」（システムＩＤ）とを含む。

【0335】

図４２は、コンテンツリストの第８１行目から第１２３行目までを示す。第８１行目から第１３６行目（図４３）までは、当該コンテンツ（第１０行目（図４０）から始まっている「item」）の「publication」（パブリケーション）の情報である。当該「publication」（パブリケーション）は、複数の要素を含む。第８２行目から第１１１行目までは、その「publication」（パブリケーション）の第１の要素であって、「BroadcastEvent」のタイプ（@type）のものである。この要素は、さらに下位において、「name」（名称、「ISDB-T」は、放送によるものであることを表す）、「startDate」（開始日時）、「endDate」（終了日時）、「priority」（優先度、当該「publication」内における当該要素の優先度）、「logoURL」（ロゴの所在情報（ＵＲＬ））、「audioMode」（音声モード、ステレオあるいはモノラル等）、「accessMode」（アクセスモード）、「serviceDescription」（サービス記述）などといった要素を持つ。なお、「serviceDescription」（サービス記述）は、「network_id」（オリジナルネットワークＩＤ）の値と、「ts_id」（トランスポートストリームＩＤ）の値と、「service_id」（サービスＩＤ）の値との情報を持つ。第１１２行目から第１２３行目までは、その「publication」（パブリケーション）の第２の要素であって、「BroadcastService」のタイプ（@type）のものである。この要素は、さらに下位において、「name」（名称、「MPEG-DASH Dynamic」は、ＭＰＥＧ－ＤＡＳＨダイナミックによるネット配信であることを表す）、「streamUrl」（コンテンツ配信ストリームの所在情報（ＵＲＬ））、「logoURL」（ロゴの所在情報（ＵＲＬ））、「audioMode」（音声モード、ステレオあるいはモノラル等）、「accessMode」（アクセスモード）、「priority」（優先度）などといった要素を持つ。

【0336】

続いて図４３に移る。図４３は、コンテンツリストの第１２４行目から第１５１行目までを示す。

【0337】

図４３の第１２４行目から第１３５行目までは、上記の「publication」（パブリケーション）の第３の要素であって、「OnDemandEvent」のタイプ（@type）のものである。この要素は、さらに下位において、「name」（名称、「MPEG-DASH static」は、ＭＰＥＧ－ＤＡＳＨスタティックによるネット配信であることを表す）、「streamUrl」（コンテンツ配信ストリームの所在情報（ＵＲＬ））、「logoURL」（ロゴの所在情報（ＵＲＬ））、「audioMode」（音声モード、ステレオあるいはモノラル等）、「accessMode」（アクセスモード）、「priority」（優先度）などといった要素を持つ。第１３７行目から第１７８行目（図４４）までは、要素「isRelatedTo」（関連コンテンツ）である。この要素「isRelatedTo」（関連コンテンツ）は、下位において複数の要素を持ち得るものであるが、第１３８行目から第１７４行目（図４４）までは、それらの複数の要素のうちの代表（第１の要素）である。当該要素は、第１４１行目から第１７３行目（図４４）までの「identifier」（アイデンティファイアー）を含む。要素「identifier」（アイデンティファイアー）については、既に説明したものと同様である。

【0338】

続いて図４４に移る。図４４は、コンテンツリストの第１５２行目から第１８５行目までを示す。

【0339】

図４４において、第１７５行目や、第１７６行目や、第１７７行目は、「isRelatedTo」（関連コンテンツ）のさらなる要素を表すものであるが、この図においては詳細を省略している。第１８０行目は、第７行目（図３９）から始まる「itemListElement」に含まれる、第８行目（図３９）から始まる第１の要素、の終わりの部分である。第１８１行目や、第１８２行目や、第１８３行目は、上記の「itemListElement」に含まれる、それぞれ、第２の要素や、第３の要素や、第４の要素であるが、この図においては詳細を省略している。第１８５行目は、当該コンテンツリスト全体の終わりの部分である。

【0340】

以上，ＪＳＯＮ形式を用いたコンテンツ情報の例を説明した。このような記述方法を用いる場合には、受信装置２の情報統合部２２Ａは、第１のコンテンツのコンテンツ情報と第２のコンテンツのコンテンツ情報とを統合して、統合コンテンツのコンテンツ情報（その内部の要素が複数存在する場合には、それらを列挙できる）を生成することが可能である。

【0341】

次に、取得方法決定部２３がコンテンツの取得方法を決定するための具体的な機能構成および処理手順について説明する。

【0342】

図４５は、取得方法決定部２３のさらに詳細な機能構成を示すブロック図である。図示するように、取得方法決定部２３は、情報管理部２３０と、可否判定部２３１と、スコア算出部２３２と、決定部２３３とを含んで構成される。既に説明したように、取得方法決定部２３は、ユーザー等から指定された統合コンテンツについて、統合コンテンツ情報を参照することによってその取得方法を決定する。なお、取得方法決定部２３が取得方法を決定する前提として、取得方法決定部２３は、情報統合部２２Ａによって生成された統合コンテンツ情報を受け取って利用する。取得方法決定部２３を構成する各部の機能は次の通りである。

【0343】

情報管理部２３０は、受信装置２の機能に関する（「機能情報」と呼ぶ）情報、およびユーザーに関する情報（「ユーザー情報」と呼ぶ）を保持し、管理する。情報管理部２３０が管理する機能情報やユーザー情報の少なくとも一部は、スコア算出部２３２によって個々の具体コンテンツのスコアが算出される際に利用される。

【0344】

情報管理部２３０は、機能情報とユーザー情報の少なくともいずれかを保持するものであってよい。機能情報とは、コンテンツ取得部２６がコンテンツを取得するための機能あるいはコンテンツ提示部２７がコンテンツを提示するための機能（コンテンツの提示機能）の少なくともいずれかの機能に関する情報である。ユーザー情報とは、コンテンツ提示部２７が提示するコンテンツを視聴するユーザーに関する情報である。

【0345】

情報管理部２３０によって管理される機能情報は、例えば、受信装置２が、放送によるコンテンツを受信することができるか否か、通信によるコンテンツを受信することができるか否か、映像コンテンツを提示することができるか否か、音声（映像コンテンツに含まれる音声や、音声のみのコンテンツに含まれる音声等）を出力することができるか否か、といった受信装置２の機能に関する情報を含む。機能情報は、さらに、受信装置２が、特定のサービス（例えば、地上デジタル放送のサービスや、ＢＳ（放送衛星）によるサービスや、ＢＳ４ＫあるいはＢＳ８Ｋによるサービス）を受信することができるか否かを表す情報を含んでもよい。機能情報は、さらに、受信装置２が備えるディスプレイ（液晶ディスプレイ等）の表示解像度に関する情報や、ディスプレイのサイズ（インチ数）についての情報を含んでもよい。機能情報は、さらに、受信装置２が持つ通信機能の通信可能速度（単位時間あたりビット数）についての情報を含んでもよい。機能情報は、さらに、受信装置２が接続されている通信ネットワークにおけるその時点での通信可能速度（単位時間あたりビット数）の情報（あるいはその推定値の情報）を含んでもよい。機能情報は、さらに、その他の、受信装置２がコンテンツを受信して提示するにあたっての機能やその能力数値等に関する情報を含んでもよい。情報管理部２３０は、受信装置２の起動時等に、機能情報を設定したり更新したりすることができる。また、情報管理部２３０は、受信装置２の能力に関して動的に変化し得る情報（例えば、接続されているネットワークの通信速度等の情報）を、適切なタイミングで取得しなおして更新することができる。

【0346】

情報管理部２３０によって管理されるユーザー情報は、その受信装置２のユーザーの、コンテンツの視聴等に関連する情報を含む。ユーザー情報は、例えば、その受信装置２のユーザーの、コンテンツを視聴する時間帯の傾向に関する情報を含んでもよい。また、ユーザー情報は、その受信装置２のユーザーが好んで視聴するコンテンツのジャンル（報道、スポーツ、芸術、ドラマ、娯楽など）等の情報を含んでもよい。また、ユーザー情報は、その受信装置２のユーザーの、ジャンル以外の好みに関する情報（例えば、好きな演者、好きな監督、好きなスポーツチームなど）を含んでもよい。また、ユーザー情報は、その受信装置２のユーザーにとって好ましいコンテンツの視聴時間の長さに関する情報を含んでもよい。また、ユーザー情報は、その受信装置２のユーザーがコンテンツを視聴する際の視聴のしかた（例えば、コンテンツを最初から視聴（追っかけ再生等を含む）するか、コンテンツをライブで途中から視聴するか、など）の傾向についての情報を含んでもよい。また、ユーザー情報は、その受信装置２のユーザーのコンテンツの視聴のしかた（高解像度の映像で視聴するか、低解像度の映像で視聴するか、放送を好んで視聴するか、ネット配信を好んで視聴するか、音声のみによる聴取を好むか、などといった区別）についての情報を含んでもよい。また、ユーザー情報は、その受信装置２のユーザーの、その他の、コンテンツの受信および視聴に関する好みや傾向についての情報を含んでいてもよい。

【0347】

情報管理部２３０は、上記のような機能情報やユーザー情報を、必要に応じて、可否判定部２３１やスコア算出部２３２に対して提供することができる。

【0348】

可否判定部２３１は、当該受信装置２が、ある特定の具体コンテンツを受信（取得）してユーザーに対して提示可能であるか否かを判定する。可否判定部２３１は、情報管理部２３０から提供される機能情報に基づいて、当該受信装置２の機能（通信等の帯域幅や、コンテンツの信号の処理能力や、表示画素数や、コンテンツの符号化方式等を含む）を把握する。また、可否判定部２３１は、個々の具体コンテンツに関する情報を、情報統合部２２Ａから渡される統合コンテンツ情報によって把握する。統合コンテンツ情報は、統合コンテンツに関連付けられている具体コンテンツのそれぞれについての情報を含んでいる。ここで、具体コンテンツについての情報は、コンテンツの種別（映像を含むか否か、音声を含むか否か、テキストを含むか否か、その他の特定の情報を含むか否か）や、コンテンツが配信される経路（放送によるものか通信（ネット配信によるものかの区別）や、放送の場合におけるサービスの種類（例えば、地上デジタル、放送衛星（ＢＳ）、ＢＳ４ＫあるいはＢＳ８Ｋ等の区別）や、コンテンツの符号化方式や、映像の解像度あるいはビットレート（映像の場合）や、音声の符号化レート（音声の場合）や、その他、受信装置２がその具体コンテンツを受信して提示することができるか否かを判定するために必要な情報などを含む。つまり、可否判定部２３１は、情報管理部２３０から提供される機能情報と、統合コンテンツ情報に含まれる個々の具体コンテンツの情報とを対応付けて把握することにより、当該受信装置２がその具体コンテンツに対応することができるか否かを判定する。可否判定部２３１による判定結果は、スコア算出部２３２や決定部２３３に伝えられる。これにより、スコア算出部２３２は、当該受信装置２が対応可能な具体コンテンツのみについて、スコアを算出することができる。また、これにより、決定部２３３は、実際のコンテンツ取得対象として決定する可能性のあるコンテンツを絞り込む（対応不可能な具体コンテンツを除外する）ことができる。

【0349】

つまり、可否判定部２３１は、情報管理部２３０が保持する機能情報と、統合コンテンツ情報に含まれるそれぞれのコンテンツの取得方法に関する情報あるいは提示方法に関する情報の少なくともいずれかと、に基づいて、それぞれのコンテンツの取得あるいは提示の可否を判定する即ち、可否判定部２３１は、受信装置２が持つ機能が、それぞれのコンテンツに対応可能であるか否かを判定する。

【0350】

スコア算出部２３２は、ある統合コンテンツに関して、当該統合コンテンツに関連付けられている複数の具体コンテンツのそれぞれについて、スコアを算出する。具体的には、スコア算出部２３２は、情報管理部２３０から提供されるユーザー情報に基づいて、当該受信装置２のユーザーの好み等（例えばジャンルや視聴時間帯など、ユーザー情報から把握可能なもの）を把握する。また、スコア算出部２３２は、情報管理部２３０から提供される機能情報に基づいて、当該受信装置２の機能に関する情報を把握する。また、スコア算出部２３２は、統合コンテンツ情報に基づいて、統合コンテンツに関連付けられた複数の具体コンテンツのそれぞれについてのコンテンツ情報を把握する。ここで、コンテンツ情報は、そのコンテンツのジャンルや、コンテンツの種別（映像を含むか否か、音声を含むか否か、テキストを含むか否か、その他の特定の情報を含むか否か）や、コンテンツが配信される経路（放送によるものか通信（ネット配信によるものかの区別）や、放送の場合におけるサービスの種類（例えば、地上デジタル、放送衛星（ＢＳ）、ＢＳ４ＫあるいはＢＳ８Ｋ等の区別）などといった情報を含む。スコア算出部２３２は、上記のようなユーザー情報や機能情報やコンテンツ情報（具体コンテンツの情報）に基づいて、具体コンテンツのそれぞれについてのスコアを算出する。このスコアは、個々の具体コンテンツが、当該受信装置２や、当該受信装置２のユーザーに適合する度合いを表す数値である。例えば、スコアの数値が大きい程、その具体コンテンツを取得して提示することが受信装置２およびユーザーに適合している度合いが高くなるように、スコアの算出方法を定義してよい。スコア算出部２３２は、算出結果である具体コンテンツごとのスコアを、決定部２３３に通知する。

【0351】

つまり、スコア算出部２３２は、統合コンテンツ情報に含まれるそれぞれのコンテンツの情報と、情報管理部２３０が保持する機能情報とユーザー情報との少なくともいずれかと、に基づいてそれぞれの前記コンテンツの適合度合いを表すスコアを算出するものであってよい。

【0352】

なお、スコア算出部２３２は、可否判定部２３１によって対応可能と判定された具体コンテンツのみについて、スコアを算出するようにしてよい。言い換えれば、スコア算出部２３２は、可否判定部２３１によって、取得することができないコンテンツあるいは提示することができないコンテンツと判定されたコンテンツに関しては、前記スコアの算出を行わないようにしてよい。

【0353】

決定部２３３は、可否判定部２３１やスコア算出部２３２から渡される情報に基づいて、ある統合コンテンツの視聴が要求されたときに、具体コンテンツの取得方法を決定する。具体的には、当該受信装置２の機能として対応可能な具体コンテンツのうち、最もスコアの高い具体コンテンツを、取得対象の具体コンテンツとして決定する。また、決定部２３３は、決定した具体コンテンツに関してコンテンツ情報を参照することにより、その取得方法を決定する。取得方法を表す情報は、放送による配信であるか通信による配信であるかを区別する情報を含む。また、取得方法を表す情報は、放送による配信の場合には、コンテンツを取得するためのサービスを特定する情報や、配信日時に関する情報を含む。放送サービスを特定する情報は、例えば、オリジナルネットワークＩＤとトランスポートストリームＩＤとサービスＩＤとの組によって表される。また、取得方法を表す情報は、通信による配信の場合には、コンテンツを取得するための所在情報（ＵＲＬ）や配信パラメーターの情報を含んでよい。また、取得方法を表す情報は、通信による配信が、オンデマンド方式での配信であるかブロードキャスティング方式での配信であるかを区別する情報を含んでよい。

【0354】

つまり、決定部２３３（取得方法決定部）は、統合コンテンツ情報に含まれるそれぞれのコンテンツの情報と、情報管理部２３０が保持する機能情報とユーザー情報との少なくともいずれかと、に基づいて取得対象のコンテンツを決定する。決定部２３３（取得方法決定部）は、スコア算出部２３２が算出したそれぞれのコンテンツについてのスコアに基づいて、取得対象のコンテンツを決定するものであってよい。

【0355】

以上説明した構成を有する取得方法決定部２３は、個々のコンテンツの属性と、受信装置２の機能（能力）と、ユーザーの好み等とに応じて、可能な複数の具体コンテンツの中から最適なコンテンツを取得する方法を決定することができる。

【0356】

なお、取得方法決定部２３が、複数の取得方法を決定してもよい。例えば、放送信号の受信状況が悪化した場合や、通信状況が悪化（通信レートの低下等）した場合などには、それらの決定された複数の取得方法の中から、代替の取得方法を用いて、コンテンツ取得部２６がコンテンツを取得することができる。

【0357】

図４６は、取得方法決定部２３がコンテンツの取得方法を決定する手順を説明するためのシーケンス図である。同図におけるステップＳ１０およびステップＳ１１のそれぞれの処理は、図３３における同じ番号のステップの処理に対応している。ステップＳ１０において、取得方法決定部２３は、ユーザーによって要求された統合コンテンツを特定することができる。あるいは、ユーザーからの再生要求の代わりに、何らかの他の方法によって特定の統合コンテンツの再生が要求されてもよい。ステップＳ１１の中に含まれる各ステップにおいて、取得方法決定部２３は、次のような処理を行う。

【0358】

ステップＳ１１１において、取得方法決定部２３は、情報統合部２２Ａから渡されるコンテンツ情報（統合コンテンツ情報）を参照する。これにより、取得方法決定部２３は、要求された統合コンテンツに含まれるすべての具体コンテンツについてのコンテンツ情報を利用することができる。

【0359】

ステップＳ１１２において、可否判定部２３１は、各々の具体コンテンツについてのコンテンツ情報と、情報管理部２３０から渡される機能情報とに基づいて、その受信装置２がそれぞれの具体コンテンツに対応可能であるか否かを判定する。可否判定部２３１は、各具体コンテンツについての可否判定の結果の情報を、スコア算出部２３２および決定部２３３に渡す。

【0360】

ステップＳ１１３において、スコア算出部２３２は、各々の具体コンテンツについてのスコアを算出する。前述の通り、スコア算出部２３２は、具体コンテンツごとに、当該受信装置２が持つ機能や、当該受信装置２のユーザーの好みに適合する度合いを示すスコアを算出する。この具体コンテンツは、既に説明したコンテンツリストの中における「associatedMedia」（アソシエイテッドメディア）要素に対応するものである。つまり、スコア算出部２３２は、それぞれの「associatedMedia」（アソシエイテッドメディア）要素に含まれる情報を具体コンテンツの情報として利用する。ここでは、例として、スコアの数値が高い程、その具体コンテンツが受信装置２の機能やユーザーの好みに適合する度合いが高いものとする。ここでスコア算出部２３２が算出するスコアは、少なくとも下に列挙する要素に基づいて算出される。

【0361】

（１）受信装置２が能力を備える限りにおいて、より豊富な情報をユーザーに提示できる具体コンテンツのほうが、そうではない具体コンテンツよりも、スコアの値が高い。ここで、より豊富な情報を提示するということは、映像を提示可能である場合には映像を含むものであることや、品質（解像度、フレームレート等）が異なる複数の映像の具体コンテンツの間ではより品質の高い映像を含むものであることである。
（２）受信装置２が能力を備える限りにおいて、より高品質な音声をユーザーに提示できる具体コンテンツのほうが、そうではない具体コンテンツよりも、スコアの値が高い。
（３）受信装置２が映像を提示する際のディスプレイ装置の物理的なサイズ（インチ数）が、より適している具体コンテンツの方が、層ではない具体コンテンツよりも、スコアの値が高い。
（４）ユーザーの好みのジャンルにより合致する具体コンテンツの方が、そうではない具体コンテンツよりもスコアの値が高い。
（５）ユーザーが好む視聴時間帯（曜日や日付等を含んでもよい）により合致する具体コンテンツの方が、そうではない視聴時間帯の具体コンテンツよりもスコアの値が高い。
（６）再生時間（視聴時間）の長さの異なる複数の具体コンテンツ間での比較において、ユーザーの好みのコンテンツの長さ（時間の長さ）により近い具体コンテンツの方が、その他の具体コンテンツよりもスコアの値が高い。
（７）ブロードキャスト型の具体コンテンツと、オンデマンド型の具体コンテンツとの比較において、ユーザーの好みに近いタイプの具体コンテンツの方が他方よりもスコアの値が高い。
（８）ここで（１）から（７）までにおいて例示した要素以外の要素に基づいて、より受信装置２の機能等や、視聴環境や、ユーザーの好みにより一層合致する具体コンテンツの方が、そうではない具体コンテンツよりもスコアの値が高い。

【0362】

ステップＳ１１４において、決定部２３３は、可否判定部２３１によって行われた判定結果や、スコア算出部２３２によって算出されたスコアの値などに基づいて、複数の具体コンテンツのうちの一つの（例えば、最もスコアの値が高い）具体コンテンツの取得を決定する。具体的には、決定部２３３は、統合コンテンツ情報の中の、選択された具体コンテンツに対応する「associatedMedia」（アソシエイテッドメディア）要素を参照することにより、そのコンテンツの取得方法を決定する。取得方法の情報は、例えば、放送による取得であるか通信（ネット配信）による取得であるかを区別する情報を含む。また、取得方法の情報は、配信日時に関する情報を含む。また、取得方法の情報は、取得先の資源の情報（放送の場合にはサービスを特定する情報であり、通信（ネット配信）の場合には取得先の所在情報（ＵＲＬ等）である。決定部２３３は、決定した取得方法の情報を、コンテンツ取得部２６に渡すことができる。

【0363】

図４７は、情報管理部２３０が、ユーザーからの情報入力に基づいて、管理する情報を更新する処理の手順を示すシーケンス図である。この図に示す手順では、まずステップＳ８１において、ユーザー側からの操作によって受信装置２に情報が入力される。ここでの情報の入力手段は、例えばユーザーがテレビのリモコン装置を操作することによるものや、ユーザーがスマートフォン（携帯電話）の画面を操作することによるものや、その他の入力方法を用いるものであってよい。ここで入力される情報は、典型的にはユーザー情報（ユーザー属性等）を変更するための情報であるが、その他の情報であってもよい。次にステップＳ８２において、情報管理部２３０は、ステップＳ８１で入力された情報を用いて、自己が管理している情報（機能情報あるいはユーザー情報）を更新する。

【0364】

図４８は、情報管理部２３０が、ユーザーからの情報入力以外の方法に基づいて、管理する情報を更新する処理の手順を示すシーケンス図である。この図に示す手順では、まずステップＳ９１において、情報管理部２３０が、情報を更新すべき状況を把握する。例えば、受信装置２が接続されている通信ネットワークの通信状況（ビットレート等）が変わったり、受信装置２が受信している放送信号の強度が変わったりした場合に、情報管理部２３０はその状況を把握する。あるいは、受信装置２がユーザーの好みの変化を検知した場合に、情報管理部２３０はその状況を把握する。次にステップＳ９２において、情報管理部２３０は、ステップＳ９１で把握した状況に基づいて、自己が管理する情報（機能情報あるいはユーザー情報）を更新する。

【0365】

図４７や図４８は、を参照しながら説明した方法により、情報管理部２３０は、必要に応じて管理している情報を更新することができる。つまり、受信装置２は、状況の変化にも対応して、適した具体コンテンツを選択して提示することができる。

【0366】

以上、実施形態を説明したが、本発明はさらに次のような変形例でも実施することが可能である。

【0367】

［変形例１］
上記実施形態では、受信装置２がコンテンツ情報の統合を行うコンテンツ情報都合装置として機能する形態とした。しかしながら、必ずしもコンテンツを受信する機能を有する装置と、コンテンツ情報を統合する機能を有するコンテンツ情報統合装置とが、同一の装置ではなくてもよい。例えば、コンテンツ情報統合装置が、受信装置２の外部に存在して、複数のコンテンツに関するコンテンツ情報に基づいてそれらのコンテンツ情報を統合し、統合コンテンツ情報を生成するようにしてもよい。この場合には、コンテンツ情報統合装置が生成した統合コンテンツ情報は、所定のタイミングで、受信装置２に対して提供される。受信装置２は、その統合コンテンツ情報を参照することによって、コンテンツの取得方法を決定し、コンテンツを取得することができる。

【0368】

［変形例２］
上記実施形態では、オブジェクト指向のデータとしてコンテンツ情報を説明した。また、コンテンツ情報の具体例としてＪＳＯＮ形式のデータ例を説明した。ただし、コンテンツ情報やサービス情報を含め、等価な情報を有する別形態のデータを用いて装置を実現するようにしてもよい。

【0369】

次に、本発明の一実施形態が解決しようとする課題について説明する。

【0370】

ところで、同じコンテンツが別個の具体コンテンツとして提供されていても、両者が同一のコンテンツであるという情報が一般には提供されていないという課題がある。一例として、放送と通信（ネット配信）とで同一の番組が提供されていても、両者が同一のコンテンツであるという情報が提供されていないという課題がある。それら複数のコンテンツが同一のコンテンツであることを受信装置等が認識するためには、例えば、コンテンツ情報としてそれら複数のコンテンツに同一の識別情報が提供されている必要がある。あるいは、識別情報以外の情報（コンテンツのタイトル等）が同一であるか、何らかの方法でそれらのコンテンツが同一のコンテンツであることを識別するための情報が提供されている必要がある。このように複数のコンテンツが同一のコンテンツであることを表す情報がない場合には、受信装置等は、あるコンテンツの代替コンテンツとして他のコンテンツを取得することができない。つまり、ユーザーは、代替コンテンツを視聴することができない。

【0371】

統合コンテンツ情報を生成するためには、複数の具体コンテンツが与えられたときに、それらの具体コンテンツ間の関連性を発見することが必要である。一般にそれら複数の具体コンテンツは識別情報等によって予め関連付けられているわけではなく、何らかの方法を用いて複数の具体コンテンツ間の関連性を発見することによって、それらを統合して抽象コンテンツとすることができる。

【0372】

次に、情報統合部２２Ａが、複数のコンテンツを統合する際にコンテンツ間の関連性を発見するための具体的な機能構成および処理手順について説明する。

【0373】

図４９は、情報統合部２２Ａのさらに詳細な機能構成を示すブロック図である。図示するように、情報統合部２２Ａは、一致検出部２２１Ａと、関連性発見部２２２Ａとを含んで構成される。なお、情報統合部２２Ａは、一致検出部２２１Ａと関連性発見部２２２Ａのいずれか一方のみを備えるものであってもよい。そのような場合には、情報統合部２２Ａは、一致検出あるいは関連性発見のいずれかの機能だけを用いてコンテンツ情報を投合する処理を行う。
また、関連性発見部２２２Ａを実現するためのさらに詳細な構成の一例として、関連性発見部２２２Ａは、スコア算出部２２６と、関連性判定部２２７とを含むものであってもよい。これらのそれぞれの機能は、次の通りである。

【0374】

一致検出部２２１Ａは、前記コンテンツ情報が含む前記識別情報に基づいて、複数の前記コンテンツの間での一致を検出する。

【0375】

関連性発見部２２２Ａは、情報取得部２１Ａが取得したコンテンツ情報に基づいて、複数のコンテンツの間での関連性を発見する。なお、前記コンテンツ情報は、前記コンテンツを識別するための識別情報と、前記コンテンツについての前記識別情報を含まない属性情報と、を含むものである。関連性発見部２２２Ａは、そのようなコンテンツ情報のうち、コンテンツについての属性情報のみに基づいて（つまり識別情報に基づかずに）、複数のコンテンツ間での関連性を発見する。

【0376】

スコア算出部２２６は、複数のコンテンツ間での関連性の度合いを表すスコアを算出する。スコア算出部２２６は、前記複数のコンテンツに関して、例として次に列挙する事項の少なくともいずれかに基づいて、前記スコアを算出するものであってよい。
（１）当該複数のコンテンツ間において、ジャンル情報の全部または一部が共通するか否か。
（２）当該複数のコンテンツ間において、コンテンツ名称の全体または一部が一致するか否か。
（３）当該複数のコンテンツ間において、コンテンツ概要の記述の全体または部分が一致するか否か。
（４）当該複数のコンテンツ間において、コンテンツの出演者情報の全部または一部が共通するか否か。
（５）当該複数のコンテンツ間において、コンテンツ情報内に含まれるパブリケーション（publication）要素が一致するか否かまたはその類似性。
（６）当該複数のコンテンツ間において、コンテンツ情報内に含まれるコンテンツへのアクセスのための所在情報が一致するか否かまたはその類似性。
または、
（７）当該複数のコンテンツ間において、コンテンツ情報が持つ配信日あるいは配信開始日の情報が一致するか否かまたはその近似性。

【0377】

なお、スコア算出部２２６がスコアを算出する方法については、さらに後でも説明する。

【0378】

関連性判定部２２７は、スコア算出部２２６が算出した前記スコアに基づいて当該複数のコンテンツ間での関連性の有無を判定する。関連性判定部２２７は、一例として、スコア算出部２２６が算出した前記スコアが所定の閾値以上（あるいは閾値以下）であるか否かに基づいて当該複数のコンテンツ間での関連性の有無を判定する。なお、関連性判定部２２７は、スコアを基に他の方法で関連性の有無を判定してもよい。なお、関連性発見部２２２Ａが発見した複数のコンテンツの間での関連性に基づいて、情報統合部２２Ａは、それら複数のコンテンツに関するコンテンツ情報を統合することによって、統合コンテンツのコンテンツ情報である統合コンテンツ情報を生成することができる。

【0379】

図５０は、情報統合部２２Ａがコンテンツ情報を統合するための処理のさらに詳細な手順を示す概略図である。図５０に示すステップＳ８は、図３３を参照しながら説明したステップＳ８にあたる。図５０に示すように、ステップＳ８は、さらに詳細な手順としてステップＳ８１からＳ８４までを含む。以下ではこの手順に沿って説明する。

【0380】

ステップＳ８１において、情報統合部２２Ａの一致検出部２２１Ａは、複数のコンテンツ間での一致を検出する。具体的には、一致検出部２２１Ａは、コンテンツを一意に識別するための識別情報の一致を検出する。この識別情報の例は、図３１で示したオブジェクト「CreativeWork」内における「identifier」（アイデンティファイアー）である。ただし、一致検出部２２１Ａは、その他のデータによってコンテンツの一致を検出してもよい。例えば、図３１で示したオブジェクト「CreativeWork」内における「associatedMedia」（アソシエイテッドメディア）の内容が完全に一致する場合に、一致検出部２２１Ａは、それらのコンテンツが一致していることを検出する。このように、一致検出部２２１Ａが複数のコンテンツにおける識別情報の一致を検出すると、それらのコンテンツは同一のコンテンツであると判断され、コンテンツ情報の統合の対象となる。なお、ステップＳ８１において一致検出部２２１Ａは、例えば、与えられるコンテンツ情報に含まれるすべてのコンテンツのペアについて、それらのコンテンツが一致するか否かの検出を行うようにしてよい。

【0381】

次のステップＳ８２からＳ８３までにおいては、ステップＳ８１で一致が検出されなかったコンテンツのペアについて、情報統合部２２Ａの関連性発見部２２２Ａがコンテンツ間の関連性の発見を試みる。具体的な手順としては次の通りである。

【0382】

ステップＳ８２において、関連性発見部２２２Ａ内のスコア算出部２２６が、各ペアについて、コンテンツ間の類似度に関するスコアを算出する。なお、スコアの具体的な算出方法の例については、さらに後でも説明する。

【0383】

ステップＳ８３において、ステップにおいて算出されたスコアが所定の条件を満たす場合に、関連性発見部２２２Ａ内の関連性判定部２２７が、そのペアに属する両コンテンツを関連付ける。つまり、関連性判定部２２７は、両コンテンツ間に関連性があるか否かを判定する。ここで、関連性判定部２２７が用いる条件は、例えば、スコア算出部２２６によって算出されたスコアが所定の閾値を超えるか否かという条件（ただし、これに限定されない）である。

【0384】

ステップＳ８４において、情報統合部２２Ａは、複数のコンテンツについてのコンテンツ情報を統合することによって、統合コンテンツ情報を生成する。ここで、統合の対象となり得るコンテンツは、上のステップＳ８１において一致が検出された複数のコンテンツ、あるいは上のステップＳ８３において関連していると判定された複数のコンテンツ、あるいはそれら両方である。

【0385】

スコア算出部２２６がスコアを算出する際の処理を列挙すると、次の通りである。
（１）特定の２つのコンテンツ間のスコアは、所定の基準点（例えば、０点）をベースとして、様々な要素に基づいて加点あるいは減点される。
（２）コンテンツ間においてジャンル情報の全部または一部が共通する場合、その一致度合いに応じてそれらのコンテンツ間のスコアは加点されてよい。
（３）コンテンツ名称（文字列）の全体または一部が一致する場合、その一致度合いに応じてコンテンツ間のスコアは加点されてよい。
（４）コンテンツ概要の記述（文字列等）の全体または部分が一致する場合、その一致度合いに応じてコンテンツ間のスコアは加点されてよい。
（５）コンテンツの出演者情報（文字列）の全部または一部が共通する場合、その一致度合いに応じてそれらのコンテンツ間のスコアは加点されてよい。
（６）上記の様々な文字列の一致度合いに基づいてスコアを算出する際に、括弧、即ち（）や［］などといったコンテンツ名等に含まれがちな文字を除外して一致度合いを判定するようにしてもよい。
（７）コンテンツ情報内に含まれるpublication要素の一致あるいは類似性に基づいて、コンテンツ間のスコアは加算されてよい。なお、publication要素が、放送局（放送事業者）を特定する情報を含む場合がある。
（８）コンテンツ情報内に含まれるurl要素（コンテンツの所在情報）の一致あるいは類似性に基づいて、コンテンツ間のスコアは加算されてよい。ＵＲＬに含まれるドメイン名などは、コンテンツ提供会社（publisher, organization）の情報を表す場合がある。
（９）さらに上記のコンテンツ提供会社間の関連性を予めテーブル等に記憶しておいて、そのテーブル等を参照することによって会社間の関連性がある場合には、コンテンツ間のスコアを加算するようにしてよい。
（１０）コンテンツ情報が持つ配信日あるいは配信開始日（datePublished要素）の情報が一致する場合あるいは近い場合には、その近さに応じてコンテンツ間のスコアを加算するようにしてよい。
（１１）２つのコンテンツについてのコンテンツ情報に含まれる他の要素に基づいて、当該ペアのスコアを加算あるいは減算するようにしてよい。

【0386】

スコア算出部２２６は、上で説明したそれぞれの要素における一致／不一致、あるいは類似性、近さ／遠さなどを判断する際に、機械学習を用いてもよい。このとき、ペアのコンテンツのそれぞれのコンテンツ情報に含まれる要素の値を入力として、それらペアにおけるスコアの加算値あるいは減算値を出力とするモデルを予め学習しておくようにする。学習の際には、実データ等に基づく教師データを用いる。

【0387】

コンテンツ情報に含まれるコンテンツのペアの数は、そのコンテンツ情報に含まれるコンテンツ数の２乗に比例する。スコア算出部２２６がコンテンツのペアについてのスコア値を算出するための演算量を減らすためには、例えば、関連性のある見込みの低いペアについては、適宜枝刈りをすることによってスコアの算出を省略してもよい。また、スコア算出部２２６が特定のペアについて上記の枝刈りを行うか否かの判断のために、機械学習を用いてもよい。

【0388】

また、スコア算出部２２６によるスコアの算出を省略して、コンテンツのペアについてのコンテンツ情報に含まれる要素の値と、それらのコンテンツのペアにおける関連性の有無との関係を、機械学習を利用して求めるようにしてもよい。この場合には、関連性判定部２２７が内部に機械学習モデルを持つ。そして、要素の値を入力として、関連性の有無を出力とする教師データを用いて、予め機械学習モデルの学習を行っておくようにする。コンテンツ情報が持つデータの値と関連性有無との関係に関して、ユーザーとのインタラクション情報やユーザーによる判定結果を、関連性判定部２２７がアノテーションデータとして保持し、学習のための教師データに反映させるようにしてもよい。

【0389】

以上説明したように、本実施形態では、受信装置２は、コンテンツ情報に基づいて、複数のコンテンツ間の関連性を発見する。具体的には、受信装置２は、放送信号に含まれるＥＰＧ情報やコンテンツ情報提供サーバー装置３から提供されるコンテンツ情報（これらを総称して「コンテンツ情報」と呼ぶことができる）に基づいて、複数のコンテンツ間の関連性を発見する。これにより、受信装置２は、コンテンツの識別情報(identifier)に基づく一致の検出や、コンテンツの配信に関する情報（associatedMedia要素）に基づく一致の検出が行われない場合にも、コンテンツ情報のその他の要素の類似性に基づいて、複数のコンテンツ間の関連性を発見する。このような関連性に基づいて、受信装置２は、コンテンツを同定することができる。言い換えれば、受信装置２は、同等であると見なすことのできるコンテンツのペア（あるいは集合）を特定できる。一致検出部２２１Ａによって一致が検出されたコンテンツの集合も、関連性発見部２２２Ａによって関連性があると判定されたコンテンツの集合も、統合コンテンツとして統合することができる。つまり、受信装置２は、関連する複数のコンテンツを統合して統合コンテンツ（抽象コンテンツ）とすることができる。受信装置２は、抽象コンテンツに関する情報（統合コンテンツ情報）を持つことにより、特定の具体コンテンツを取得できない状況（放送信号の強度が得られない場合や、通信帯域が十分に得られない場合など）において、その抽象コンテンツに属する他の具体コンテンツを代替コンテンツとして取得することができる。

【0390】

次に、サービスリストの具体例について説明する。

【0391】

図５１および図５２は、サービスリスト（ServiceList）の例を示す概略図である。本例のサービスリストはＪＳＯＮ（JavaScript Object Notation）形式のデータとして記述されている。なお、これらの図においては便宜的に参照用の行番号を示している。

【0392】

図５１の第１行目は、１つのサービスリストの開始を表す。このサービスリストの終了は、第７９行目（図４８）である。第２行目から第４行目までは、このサービスリストのヘッダーに当たる部分である。第５行目は、アイテムリストエレメント（itemListElement）の開始を表す。このアイテムリストエレメントの終了は、第７８行目（図４８）である。第６行目から第６８行目（図４８）までは、このアイテムリストエレメントが持つ第１の要素についての記述である。第６９行目から第７７行目までは、このアイテムリストエレメントが持つ第２の要素以後の要素についての記述である。これらの要素の各々は、１つのサービスに対応している。

【0393】

次に第６行目から始まる要素（第１のサービスについての記述）に関して説明する。

【0394】

第７行目は、当該要素のタイプ（@type）がブロードキャストサービス（BroadcastService）であることを表す。第８行目は、当該サービスの名称が「ＮＨＫ総合・東京」であることを表わす。第９行目は、ブロードキャスト表示名（broadcastDisplayName）が「ＮＨＫ総合・東京」であることを表す。第１０行目から第１３行目までは、放送事業者（broadcaster）についての定義である。その中で第１１行目と第１２行目とは、タイプ（@type）が組織（Organization）であり、その名称が「ＮＨＫ」であることを表している。

【0395】

第１４行目から第３０行目までは、この第１のサービスの識別情報（identifier）を規定している。放送サービスは、オリジナルネットワークＩＤと、トランスポートストリームＩＤと、サービスＩＤとの３つ組の情報によってユニークに識別される。第１５行目から第１９行目までは、オリジナルネットワークＩＤ（original_network_id）の値が３２７３６であることを表している。また、第２０行目から第２４行目までは、トランスポートストリームＩＤ（ts_id）の値が３２７３６であることを表している。また、第２５行目から第２９行目までは、サービスＩＤ（service_id）の値が１０２４であることを表している。

【0396】

第３１行目は、当該サービスに関連付けられる画像（image）の所在を規定する情報である。第３２行目は、当該サービスと同一のサービス（sameAs）の所在を表す情報である。第３３行目は、当該サービスについてのウェブサイト（あるいは、当該サービスを提供する事業者のウェブサイト）のＵＲＬを規定する。

【0397】

第３４行目から第４３行目まで（hasOfferCatalog）は、当該サービスによって配信されるコンテンツに関するコンテンツリストの所在を表す情報である。本例では、プレゼントリスト（presentList）の所在情報と、スケジュールリスト（scheduleList）の所在情報とが定義されている。第３５行目から第３８行目までは、前者のプレゼントリストについての定義である。第３９行目から第４２行目までは、後者のスケジュールリストについての定義である。第３７行目には、前者のプレゼントリストのＵＲＬが記述されている。第４１行目には、後者のスケジュールリストのＵＲＬが記述されている。

【0398】

図５２に移って、第４４行目は、放送チャンネルに関する情報を持つ要素（hasBroadcastChannel）であるが、本例ではそのデータは空である。第４５行目から第５４行目までは、放送のサービスエリア（areaServed）に関する情報を表す。本例では、２つの行政区域（administrativeArea）が規定されており、第４６行目から第４９行目までにおいて表わされる行政区域の名称は「関東」（Kanto）であり、第５０行目から第５３行目までにおいて表わされる行政区域の名称は「東京」（Tokyo）である。

【0399】

第５５行目から第６７行目までは、親サービス（parentService）を規定している。第５６行目は、その親サービスの名称が「ＮＨＫ総合」であることを示す。つまり、１つのエリアのサービスである「ＮＨＫ総合・東京」の親サービスが、各地のエリアのサービスを統合的にとらえた「ＮＨＫ総合」である。第５７行目は、当該サービスの種別（@type）が放送サービス（BroadcastService）であることを表している。第５８行目は、当該サービスと同一のサービス（sameAs）の所在を表す情報である。第５９行目から第６６行目までは、当該親サービスの識別情報（identifier）である。この識別情報においては、属性ＩＤ（第６４行目）として０、属性名（第６１行目）として「系列」（affiliation）、属性値（第６３行目）として「ＮＨＫ総合」が記述されている。

【0400】

第６９行目から第７７行目までは、第２のサービスに関する記述である。この第２のサービスの記述項目も、第６行目から第６８行目までにおいて示した第１のサービスにおける記述項目と同様である。この図においては、その記述の一部を省略している。なお、第７１行目は、このサービスの名称が「ＮＨＫＥテレ東京」であることを表している。第７２行目は、このサービスの表示名が「ＮＨＫＥテレ東京」であることを表している。第７３行目から第７６行目までは、第１のサービスにおける第１０行目から第１３行目までと同様に、このサービスを提供する放送事業者を定義している。

【0401】

なお、ここで図面を参照しながら説明したサービスリストは、２つのサービスの情報を含むものであるが、一般にサービスリストは任意の数のサービスを含むものであってよい。

【0402】

以下、本発明の実施形態について、図面を参照しながら他の方法により説明する。

【0403】

図５３は、実施形態に係るシステムの概要構成の一例を示すブロック図である。同図を参照しながら、システム１の概要について説明する。同図に示すように、システム１は、受信装置２と、コンテンツプロバイダコンテンツプロバイダーＣＰと、情報提供システム６とを含んで構成される。コンテンツプロバイダーＣＰの具体的態様としては、情報登録装置５と、コンテンツ配信装置７と、放送送出装置８とが含まれる。本実施形態において、受信装置２、情報登録装置５、情報提供システム６、コンテンツ配信装置７及び放送送出装置８（以下、これらの各装置及びシステムをまとめて「システム１に含まれる構成要素」と記載する場合がある。）の数はそれぞれ１以上であればよい。同図には、一例として、システム１が、複数の受信装置２と、それぞれ１台ずつの情報登録装置５、情報提供システム６、コンテンツ配信装置７及び放送送出装置８を含む場合について図示している。システム１に含まれる構成要素のそれぞれは、例えば、コンピューターを用いて実現されてもよい。

【0404】

本実施形態の前提となる事項について説明する。本実施形態に係るシステム１は、ユーザーに対しコンテンツを配信する。当該コンテンツは、コンテンツプロバイダーＣＰにより提供される。本実施形態に係るシステムが配信するコンテンツには、様々な態様の情報が含まれる。例えばコンテンツには、動画、音声、テキスト及びこれらの組み合わせ等の視覚的又は聴覚的に認知可能な様々な情報が含まれていてもよい。また、コンテンツとは、動画、音声及びテキストの少なくともいずれかを含むものであってもよい。以下の説明では、一例として本実施形態に係るシステムが、動画及び音声を含む映像コンテンツを配信する場合の一例について説明する。なお、以下の説明において、本実施形態に係るシステムをコンテンツ配信システムとも記載する場合がある。

【0405】

コンテンツプロバイダーＣＰから提供されるコンテンツは、ＩＳＤＢ－Ｔ（統合デジタル放送サービス － 地上用）、ＩＳＤＢ－Ｓ（統合デジタル放送サービス － 衛星用）、ＩＳＤＢ－Ｓ３（高度広帯域衛星デジタル放送方式）等の放送システムで提供されるものであってもよい。また、これらのコンテンツは、ネット配信サービスでも提供される。ネット配信サービスでは、ＣＭＡＦ（Common Media Application Format）、ＭＰＥＧ－ＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）、ＨＬＳ（HTTP Live Streaming）等の方法が用いられてもよい。ネット配信サービスでは、ライブ配信（live）とオンデマンド配信（VOD，Video on Demand）のいずれもが想定される。放送番組は、ネット配信サービスでも同時に配信されている（例えば、ＮＨＫプラス、ＴＶｅｒ等）。

【0406】

本実施形態に係るサービスとしては、種々のタイプのものが存在する。例えば、本実施形態に係るサービスの一例としては、放送チャンネルによるコンテンツの配信を軸としたサービス、ネット配信によるコンテンツの配信を軸としたサービス、ＶＯＤにおけるポータル提供によるサービス、カテゴリーやジャンル等で定義されるコンテンツ配信のグループとしてのサービス等を例示することができる。

【0407】

放送チャンネルを軸としたサービスは、放送事業者が編成するスケジュールにしたがって放送によって配信される番組の連続である。このような番組の配列は、例えば、ＡＲＩＢ ＳＴＤ－Ｂ１０「デジタル放送に使用する番組配列情報」標準規格において規定される。

【0408】

ネット配信を軸としたサービスは、放送と同様にコンテンツプロバイダーＣＰが編成するネット番組の連続として成るタイプのサービスと、ＶＯＤ配信等のサービスとの２種類がある。なお、本実施形態に係るコンテンツプロバイダーＣＰには、放送事業者がコンテンツプロバイダーである場合が含まれる。

【0409】

受信装置２は、コンテンツプロバイダーＣＰにより提供されるサービスを受信する。具体的には、受信装置２は、放送信号（放送波）によるサービス（放送サービス）と、インターネット等の所定の通信ネットワークＮＷを介して配信されるサービス（ネット配信サービス）とを受信する。放送サービスは、放送事業者側の配信スケジュールにしたがって配信される。放送サービスは、放送送出装置８により配信される。ネット配信サービスは、配信事業者側の配信スケジュールにしたがって配信されるスタイル（ライブ）と、受信装置２（クライアント）側からの要求に基づいて配信されるスタイル（ビデオ・オン・デマンド）とがある。ネット配信サービスは、情報登録装置５及びコンテンツ配信装置７により配信される。

【0410】

所定の通信ネットワークＮＷとは、回線を用いて構成される通信ネットワークである。所定の通信ネットワークＮＷの一例としては、インターネットを例示することができる。所定の通信ネットワークＮＷはオープンなネットワークであり、通信ネットワークＮＷに接続された装置同士は所定のプロトコルを用いて相互に通信することができる。通信ネットワークＮＷのインターネット層においては、インターネットプロトコル（ＩＰ）等を用いた通信が行われる。

【0411】

システム１に含まれる複数の受信装置２は、コンテンツプロバイダーＣＰにより提供されるサービス又はコンテンツを、放送サービス又はネット配信サービスのいずれかの態様において受信できていればよい。放送サービスにより提供されるサービス又はコンテンツを放送コンテンツＢＣと記載し、ネット配信サービスにより提供されるサービス又はコンテンツをネットコンテンツＮＣと記載する場合がある。図示する一例では、システム１に受信装置２として受信装置２－１と、受信装置２－２と、…、受信装置２－ｎ（ｎは１以上の自然数）とが含まれる。受信装置２－１はネットコンテンツＮＣのみを取得し、受信装置２－２はネットコンテンツＮＣ及び放送コンテンツＢＣの両方を受信し、受信装置２－ｎは放送コンテンツＢＣのみを受信する。受信装置２が受信可能なサービスは、受信装置２が置かれる場所の変化や、受信装置２が置かれる環境の変化に応じて変化してもよい。

【0412】

本実施形態において、受信装置２は、サービスリストＳＬを取得する。サービスリストＳＬには、サービスについての情報（サービス情報）が含まれる。サービスリストＳＬは、複数のサービスについての情報を括った情報である。サービスリストＳＬは、例えば、特定の地域（例えば、関東）の地上デジタル（地デジ）放送に関連する情報をまとめたリストであってよい。また、サービスリストＳＬは、例えば、国（日本）全体をカバーする衛星放送（ＢＳ放送）に関連する情報をまとめたリストであってもよい。サービスリストＳＬの括り方は、ここで例示したものには限定されず、様々な括り方があってよい。なお、サービスリストＳＬとは、放送信号に含まれるサービス記述テーブル（ＳＤＴ；Service Described Table、以下の説明においては、単にＳＤＴと記載する場合がある。）相当の情報であるということもできる。

【0413】

サービスリストＳＬは、情報登録装置５によって提供される。情報登録装置５によって提供されたサービスリストＳＬは、情報提供システム６が備える不図示の記憶部に記憶され、受信装置２に提供される。受信装置２は、情報提供システム６が備える不図示の記憶部に記憶されたサービスリストＳＬの全部又はサービスリストＳＬの一部を、所定のタイミングで取得することができる。情報登録装置５及び情報提供システム６は、様々な形態で存在してもよい。例えば情報登録装置５及び情報提供システム６は、異なる事業者により運用されていてもよい。情報登録装置５及び情報提供システム６が異なる事業者により運用される場合、情報登録装置５及び情報提供システム６はそれぞれ異なるサーバーに構成されていてもよい。図示する一例では情報登録装置５及び情報提供システム６が互いに１対１で接続されているが、情報登録装置５及び情報提供システム６は互いにインターネット等の所定の通信ネットワークＮＷを介して接続されていてもよい。

【0414】

情報提供システム６は、インターネット等の所定の通信ネットワークＮＷを介して、サービスリストＳＬを受信装置２に提供する。なお、情報提供システム６がサービスリストＳＬを提供する方法はこの一例に限定されず、他の方法であってもよい。例えば、情報提供システム６は、ＩＳＤＢ（Integrated Services Digital Broadcasting、統合デジタル放送サービス）の放送信号中のＳＩ（Service Information、サービス情報）内においてサービスリストＳＬを提供するようにしてもよい。

【0415】

受信装置２は、インターネット等から受信するサービスリストＳＬと放送信号から受信するＳＤＴとに基づいて、サービスに関する情報をマージしたり、所定のルール等に基づいて一方が他方を上書きしたりすることができる。つまり、受信装置２は、複数の手段又は経路で受信したサービスに関する情報を統合することによって、自装置用のリストを生成してよい。

【0416】

また、生成したリストを複数の受信装置２の間で互いに共有するようにしてもよい。例えば、宅内、同一ユーザー内又は同一ユーザーグループ内等に複数の受信装置２が存在する場合、第１の受信装置２が受信して生成したサービスに関するリストを、他の装置である第２の受信装置２が参照して利用するようにしてもよい。また、例えば、第１の受信装置２が生成したサービスに関するリストと、他の装置である第２の受信装置２が生成したサービスに関するリストとを、相互に交換してマージした形態で共有するようにしてもよい。

【0417】

サービスリストＳＬは、具体的には、各サービスについてのサービス名称、配信者情報、サービス識別子（サービスを特定するためのユニークなＩＤ）、提供方法（放送チャンネルの場合には、チャンネルの識別子情報であるところのオリジナルネットワークＩＤ（nid）、トランスポートストリームＩＤ（tsid）、サービスＩＤ（sid）の組。ネット配信サービスの場合には、ＵＲＬや配信プロトコルや配信パラメーターの情報）、サービス自体の付加情報を提供するためのＡＰＩの情報、そのサービスのコンテンツの情報を取得するためのＡＰＩ（コンテンツリストＡＰＩ）の情報等を含んでいてもよい。

【0418】

また、上記のようなサービスの中で提供される一つ一つのコンテンツ（例えば番組）の情報は、別途、コンテンツリストＣＬ等として管理される。コンテンツリストＣＬは、サービスリストＳＬと同様に、情報提供システム６によって提供される。

【0419】

コンテンツリストＣＬは、コンテンツに関する情報（コンテンツ情報）の集合である。情報提供システム６は、上述したサービスリストＳＬとは異なる情報として、コンテンツリストＣＬを受信装置２に提供してもよい。受信装置２は、情報提供システム６に記憶されたコンテンツリストＣＬの全部又はコンテンツリストＣＬの一部を、所定のタイミングで取得することができる。一つのコンテンツリストＣＬにどのコンテンツの情報を含めるようにするかは、様々な態様が存在してもよい。第１の態様として、一つのコンテンツリストＣＬは、ある放送サービス（チャンネル）を想定して、現在配信されているコンテンツ（番組）の情報や、次に配信されるコンテンツ（番組）の情報のリストという態様であってよい。現在のコンテンツの情報と次のコンテンツの情報とは、「ｐ／ｆ」と呼ばれるものである。ここで、「ｐ」はpresent（現在）を表し、「ｆ」はfollowing（次の、後続する）を表す。また、第２の態様として、一つのコンテンツリストＣＬは、現在から１週間先の日付までのＥＩＴ（Event Information Table）スケジュール相当のリストという態様であってよい。ＥＩＴスケジュール相当のコンテンツリストＣＬに基づいて、番組表が生成されてもよい。また、第３の態様として、一つのコンテンツリストＣＬは、過去に放送（又は配信）されたコンテンツに関する情報を含んでいてもよい。過去に放送（又は配信）されたコンテンツに関する情報は、いわゆる「見逃し配信」のサービスを実現する際に有用な情報である。

【0420】

コンテンツリストＣＬは、特定の一つのサービス（チャンネル）において配信されるコンテンツの情報の集合であってもよいし、複数のサービス（チャンネル）にまたがるコンテンツの情報の集合であってもよい。一例として、コンテンツリストＣＬは、特定の地域（例えば、東京等の都道府県単位）を対象とする地上デジタル（地デジ）放送のサービス群に含まれるコンテンツの情報の集合であってもよい。

【0421】

コンテンツリストＣＬに含まれるコンテンツ情報には、典型的には、コンテンツ名（番組名）、制作者名、出演者名等といった情報が含まれる。また、コンテンツ情報は、配信媒体に特有の情報（例えば、放送サービスに関してはチャンネルを特定する情報、ネット配信サービスに関しては配信用のＵＲＬや配信プロトコルの種別を表す情報等）を含んでいてもよい。また、コンテンツ情報には、複数のコンテンツ間の関係を記述することができる。例えば、コンテンツＡとコンテンツＢとが同一シリーズの異なる配信回のコンテンツである場合には、コンテンツ情報は、上記のコンテンツＡとコンテンツＢとに関する情報として、両者に共通するシリーズ名（あるいは、シリーズＩＤ等）と、配信回を表す情報とを含むことができる。配信回は、例えば、第×シリーズ、第×シーズン、第×エピソード、第×回などといった表現（又はそれらの組合せでもよい）で表わされる場合がある。コンテンツＡとコンテンツＢとが、共通のテーマ（例えば、ニホンカワウソ）を扱う場合や、共通の制作者によるものである場合や、共通の出演者が出演するものである場合などにも、コンテンツ情報がこれら両者の関連性を示すようにしてもよい。

【0422】

受信装置２は、サービスリストＳＬの場合と同様に、複数のコンテンツリストＣＬを取得してそれらをマージしたり、所定のルール等に基づいて一方が他方を上書きしたりして自装置用のコンテンツに関するリストを生成してもよい。自装置用のコンテンツに関するリストを生成するための情報は、放送信号から取得されてもよいし、ネット配信としてインターネット等の所定の通信ネットワークＮＷを介して取得されてもよい。

【0423】

受信装置２は、サービスリストＳＬと比較して、コンテンツリストＣＬをより頻繁に取得して、自装置内の情報（コンテンツデータベース等）を更新してもよい。すなわちサービスリストＳＬが比較的静的な情報であるのに対して、コンテンツリストＣＬは動的な情報であるということができる。地上放送の信号に関する規定（ＩＳＤＢ－Ｔ，Integrated Services Digital Broadcasting - Terrestrial，統合デジタル放送サービス － 地上用）では、受信装置２は、放送信号に含まれるコンテンツリストＣＬを所定頻度で受信することとなる。ネット配信サービスにおけるコンテンツリストＣＬの更新頻度は、適宜設定され得る。ネット配信サービスにおけるコンテンツリストＣＬは、プル（pull）型ＡＰＩ、プッシュ（push）型ＡＰＩなどを介して受信装置２によって取得される。受信装置２は、それらのＡＰＩを介して更新通知だけを受け取るスタイルとしてもよい（この場合には受信装置２が必要に応じて更新された情報を要求して取得する）し、それらのＡＰＩを介してコンテンツリストのデータ実体を受け取るスタイルとしてもよい。また、ＭＴＥ（Media Timed Event、メディア・タイムド・イベント）のしくみを用いて、配信される動画ストリームに付随する形で、受信装置２がコンテンツリストＣＬの情報（コンテンツリストの更新情報、またはコンテンツリストのデータ実体）を受信できるようにしてもよい。

【0424】

サービスリストＳＬ及びコンテンツリストＣＬの更新のためのトリガーとしては、以下の３通りの方法を例示することができる。すなわち、第１のタイミングとしては、受信装置２により設定される任意のタイミングである。任意のタイミングとは、具体的には受信装置２によりカウントされるタイマに基づくタイミングであってもよい。より具体的には、受信装置２は、２秒周期や１０秒周期でサービスリストＳＬ及びコンテンツリストＣＬを更新してもよい。サービスリストＳＬ及びコンテンツリストＣＬの更新頻度は、互いに異なっていてもよい。上述した通り、サービスリストＳＬは静的な性質を有しコンテンツリストＣＬは動的な性質を有するため、サービスリストＳＬの更新頻度は、コンテンツリストＣＬの更新頻度より低く設定されていてもよい。また、第２のタイミングとしては、受信装置２が更新通知を受信したタイミングである。当該更新通知は、情報提供システム６により提供される。更新通知には、サービスリストＳＬ及びコンテンツリストＣＬの少なくともいずれかが更新された事実及びサービスリストＳＬ及びコンテンツリストＣＬのうち更新された部分を特定するための情報が含まれる。情報提供システム６は、情報登録装置５からサービスリストＳＬ又はコンテンツリストＣＬが更新された場合、更新通知を受信装置２に提供する。受信装置２は、情報提供システム６から更新通知を取得し、取得した更新通知により特定された部分についての情報を情報提供システム６から取得してもよい。また、第３のタイミングとしては、ユーザーの操作に基づくタイミングである。ユーザーは、受信装置２を直接的又は間接的に操作することにより、自身が望むコンテンツ（すなわち自身が視聴を望む番組）を特定する。受信装置２は、ユーザーにより特定された情報に基づき、サービスリストＳＬ又はコンテンツリストＣＬの更新情報を、情報提供システム６に対して要求することができる。

【0425】

また、コンテンツリストＣＬ内にサービスリストＳＬの更新通知を含めることにより、受信装置２側でサービスリストＳＬの更新情報を取得できるようにしてもよい。この場合、受信装置２は、コンテンツリストＣＬ内にサービスリストＳＬの更新通知が含まれていることを検出したことをトリガーとして、サービスリストＳＬの更新情報を、情報提供システム６に対して要求することができる。

【0426】

サービスリストＳＬ又はコンテンツリストＣＬの少なくともいずれかが、有効期限の情報、あるいは再取得日時の情報を持つようにしてもよい。これらの情報は、受信装置２がサービスリストＳＬ又はコンテンツリストＣＬを再取得することを促す情報である。受信装置２は、例えば有効期限が切れたことをトリガーとして、適宜、サービスリストＳＬ又はコンテンツリストＣＬの全部を再取得する。受信装置２は、例えば再取得日時が到来したことをトリガーとして、適宜、サービスリストＳＬ又はコンテンツリストＣＬの全部を再取得してもよい。

【0427】

受信装置２は、サービスに関するリストを、放送信号のみから、又は所定の通信ネットワークＮＷを介してのみからしか取得できない場合にも、適切にサービスに関するリストを取得、維持、および更新する。また、コンテンツに関するリストについても同様である。即ち、受信装置２は、コンテンツに関するリストを、放送信号のみから、又は所定の通信ネットワークＮＷを介してのみからしか取得できない場合にも、適切にコンテンツに関するリストを取得、維持、および更新する。

【0428】

次に、本実施形態に係るシステム１を構成する各構成要素の機能の概要について説明する。

【0429】

受信装置２は、コンテンツを受信してユーザーに提示する装置である。受信装置２は、放送送出装置８からの放送信号によって伝送されるコンテンツを受信することができる。また、受信装置２は、インターネット等の所定の通信ネットワークＮＷを介してコンテンツ配信装置７から伝送されるコンテンツを受信することもできる。受信装置２は、受信したコンテンツのデータを、適宜、復調及び復号等して、映像や音声やテキスト等を含むコンテンツをユーザーに対して提示する。受信装置２は、映像やテキストについては、画面に表示する。受信装置２は、音声についてはスピーカー等（イヤフォン等を含む）から出力する。受信装置２が提示するコンテンツの一例は映像、音声又はテキストの一例に限定されず、その他の形態のコンテンツを提示してもよい。

【0430】

受信装置２は、放送サービスに関するサービス情報や、ネット配信サービスに関するサービス情報、及びこれらのサービスを通じて提供されるコンテンツに関するコンテンツ情報を取得し、保持する。具体的な態様の一例として、受信装置２は、情報提供システム６からサービス情報が含まれるサービスリストＳＬと、コンテンツ情報が含まれるコンテンツリストＣＬとを取得し、取得した情報を自装置内等に保持する。受信装置２は、自装置内に保持されたサービス情報とコンテンツ情報とに基づいて、放送やネット配信のサービスを受信することができる。受信装置２は、情報提供システム６から、インターネット等の所定の通信ネットワークＮＷを経由して、サービスリストＳＬとコンテンツリストＣＬとを受信することができる。また、受信装置２は、放送送出装置８から送出される放送信号内に含まれるサービスやコンテンツに関する情報を受信することができる。具体的な態様の一例としては、サービスに関する情報はＳＤＴ等に含まれていてもよいし、コンテンツに関する情報はＥＴＩ等に含まれていてもよい。

【0431】

また、受信装置２は、複数の情報（放送に関する情報とネット配信に関する情報）を統合することができる。統合された情報には、例えば、同一のコンテンツを同時（ほぼ同時）に配信するものが対応付けられていてもよい。受信装置２は、例えば一方のサービス（例えば放送サービス）を受信中に、何らかの理由でそのサービスの受信が途絶えてしまうような場合がある（例えば、伝送信号の不達等）。このような場合、受信装置２は、他方のサービス（ネット配信サービス）に関する情報を参照することによって、他方のサービス（ネット配信サービス）を経由することに切り替えて、継続して同等内容のコンテンツを受信することができる。つまり、受信装置２は、コンテンツを受信するための伝送路を適宜切り替えることができる。なお、受信装置２は、信号不達等の場合の伝送路の切り替えに限らず、他の理由による伝送路の切り替えを行ってもよい。つまり、受信装置２は、様々な理由により、相互に関連付けられる複数のサービスを受信し、いずれかのサービスを提示することができる。

【0432】

受信装置２は、具体的な一例として、インターネット等の所定の通信ネットワークＮＷによる通信機能を有するテレビ受像機として実現され得る。また、受信装置２は、他の一例として、放送信号を受信する機能およびインターネットによる通信の機能を有するコンピューターとしても実現され得る。当該コンピューターの具体的態様としては、ＰＣ（パーソナルコンピューター）、タブレット端末装置、スマートフォン、腕時計型端末装置やスマートグラス等のウェアラブル端末装置等を例示することができる。

【0433】

情報登録装置５は、情報提供システム６にサービスリストＳＬ及びコンテンツリストＣＬを提供する。また、情報登録装置５は、情報提供システム６が記憶するサービスリストＳＬ及びコンテンツリストＣＬを更新する。サービスリストＳＬ及びコンテンツリストＣＬは、情報登録装置５により任意のタイミングで更新され得る。サービスリストＳＬ及びコンテンツリストＣＬが更新される任意のタイミングとは、サービスリストＳＬ又はコンテンツリストＣＬのいずれかの一部に変更があった時点であってもよい。情報登録装置５によるサービスリストＳＬ及びコンテンツリストＣＬの更新は、サービスリストＳＬ及びコンテンツリストＣＬの一部の情報のみが情報提供システム６に提供されることであってもよい。

【0434】

情報提供システム６は、情報登録装置５からサービスリストＳＬ及びコンテンツリストＣＬを取得する。情報提供システム６は、取得したサービスリストＳＬ及びコンテンツリストＣＬを記憶し、インターネット等の所定の通信ネットワークＮＷを介して、記憶した情報を受信装置２に対して提供する。情報提供システム６は、プッシュ形式で情報を受信装置２に送信するものであってもよいし、受信装置２からの要求に応じる形で情報を受信装置２に送信するものであってもよい。また、情報提供システム６は、情報を更新すべき状況においては、更新のために用いる情報を受信装置２に対して送信する。なお、情報提供システム６は、更新通知を、例えばプッシュ形式等で受信装置２に対して送るようにしてもよい。

【0435】

コンテンツ配信装置７は、ネット配信によるコンテンツに関する情報を、インターネット等の所定の通信ネットワークＮＷを介して受信装置２に提供する。コンテンツは、内容的にまとまりのある単位であり、映像や音声等を含んで構成されるものである。コンテンツに関する情報は、コンテンツ（例えば番組）の識別情報、タイトル（題名）、概略（あらすじ等）、出演者情報、制作者情報等を含んでいてもよい。より具体的には、コンテンツ配信装置７は、コンテンツを構成する動画や音声のデータをネットコンテンツＮＣとして受信装置２に提供する。ネットコンテンツＮＣは、例えばストリーミング等の手段を用いて提供されてもよい。コンテンツ配信装置７が配信するサービスについての情報は、情報提供システム６から受信装置２に対して提供される。

【0436】

放送送出装置８は、放送信号を送出する。放送信号は、空中波として、あるいはケーブルテレビ用のケーブルを媒体とする電気信号として、放送送出装置８によって送出され、伝送される。放送送出装置８が送出する放送信号は、動画や音声やテキスト等の信号に加えて、制御信号を含んでいてもよい。制御信号には各種の制御情報が含まれる。放送信号に載せて送出され制御信号は、放送サービスの編成チャンネルについてのサービス情報を含む。また、放送信号には放送を通じて提供されるコンテンツに関する情報である放送コンテンツＢＣが含まれる。

【0437】

図５４は、実施形態に係る受信装置の機能構成の一例を示すブロック図である。同図を参照しながら、受信装置２の機能構成の一例について説明する。受信装置２は、統合機能部２１と、既存機能部２２とを備える。既存機能部２２とは、従来のテレビ受像機が有する機能部である。受信装置２は、既存機能部２２に加え、更に統合機能部２１を備えることにより、従来のテレビ受像機が受信可能な放送信号に加えネット配信サービスを受信可能な装置として実現され得る。統合機能部２１と既存機能部２２とは、所定の通信方式を用いることにより互いに情報通信を行う。なお、本実施形態においては、説明のため統合機能部２１と既存機能部２２とを区別して説明するが、統合機能部２１及び既存機能部２２は、１つの機能部として実現されていてもよい。

【0438】

まず、既存機能部２２について説明する。既存機能部２２は、操作取得部２２１と、コンテンツ提示部２２２と、放送コンテンツ取得部２２３とを含んで構成される。既存機能部２２は、これらの各機能部を含んで構成されることにより、従来のテレビ受像機と同等の機能を実現する。従来のテレビ受像機と同等の機能とは、すなわち、ユーザーＵの操作を受け付け、受け付けた操作に基づいてコンテンツを提示することを含む。

【0439】

操作取得部２２１は、ユーザーＵの操作を取得する。ユーザーＵの操作には、例えばリモコン装置（不図示）による操作や、テレビ受像機が備える様々なユーザーインタフェース（不図示）による操作等が含まれる。操作取得部２２１は、リモコン装置による操作を受け付ける場合、リモコン装置から出力された制御信号（例えば赤外線信号）を受信する。また、操作取得部２２１は、テレビ受像機が備える各ユーザーインタフェースによる操作を受け付ける場合、例えばスイッチの押下操作等を検知する。操作取得部２２１は、取得した操作に関する情報を操作情報ＯＩとして統合機能部２１及び既存機能部２２がそれぞれ備える所定の機能部に出力する。

【0440】

放送コンテンツ取得部２２３は、放送サービスで配信されるコンテンツを受信する。放送コンテンツ取得部２２３が放送送出装置８から取得する情報を放送情報ＢＩと記載する。放送情報ＢＩには、放送サービスで配信されるコンテンツが含まれる。放送コンテンツ取得部２２３が受信する放送情報ＢＩに含まれるコンテンツの内容としては、動画、音声、テキスト及びこれらの結合等の情報を例示することができる。放送コンテンツ取得部２２３は、受信した放送情報ＢＩを、適宜復調し、また復号し、動画や音声やテキストを提示するための情報として放送コンテンツ情報ＢＣＩを生成する。放送情報ＢＩには、サービスに関する情報（ＳＤＴ）やコンテンツに関する情報（ＥＩＴ）等が含まれていてもよい。生成された放送コンテンツ情報ＢＣＩは、コンテンツ提示部２２２に提供される。また、放送情報ＢＩに含まれるサービスに関する情報やコンテンツに関する情報は、統合機能部２１に提供される。放送コンテンツ取得部２２３は、例えば操作取得部２２１等から、特定のコンテンツを受信するように指示された場合には、指示されたコンテンツを受信する。

【0441】

コンテンツ提示部２２２は、ユーザーＵに対し提示情報ＰＩを出力する。提示情報ＰＩとは、例えば動画や音声やテキストのコンテンツに関する情報を、表示部（不図示）や音声出力部（不図示）等を介してユーザーＵに対して提示するための情報である。コンテンツに関する情報とは、コンテンツ自体（例えば番組）であってもよいし、コンテンツの配信スケジュールに関する情報（例えば番組表）であってもよい。表示部とは、例えば液晶ディスプレイ、有機ＥＬ（Electroluminescence）ディスプレイ等であってもよい。また、音声出力部とは、例えばスピーカーであってもよい。コンテンツ提示部２２２は、放送送出装置８から提供された情報に基づくコンテンツである放送コンテンツ情報ＢＣＩ、又は所定の通信ネットワークを介してコンテンツ配信装置７から提供された情報に基づくコンテンツであるネットコンテンツ情報ＮＣＩのいずれかに基づいて、提示情報ＰＩを出力する。放送コンテンツ情報ＢＣＩは放送コンテンツ取得部２２３により提供され、ネットコンテンツ情報ＮＣＩは統合機能部２１により提供される。すなわちコンテンツ提示部２２２は、放送コンテンツ取得部２２３により提供された情報又は統合機能部２１により提供された情報のいずれかを提示する。なお、ネットコンテンツ情報ＮＣＩは、後述する統合機能部２１により提供される。なお、以下の説明において、コンテンツ提示部を単に提示部と記載する場合がある。また、以下の説明において、コンテンツに関する情報を提示するステップ又は工程を、提示ステップ又は提示工程と記載する場合がある。

【0442】

次に、統合機能部２１について説明する。統合機能部２１は、情報取得部２１１と、情報統合部２１２と、提示方法決定部２１３と、ネットコンテンツ取得部２１４と、事前情報設定部２１５とを含んで構成される。統合機能部２１は、これらの各機能部を含んで構成されることにより、放送信号に基づくコンテンツに代えて、通信ネットワークを介して取得したコンテンツをユーザーＵに対して提示することができる。換言すれば、受信装置２が放送信号を取得できないような環境に置かれている場合であっても、受信装置２が通信ネットワークＮＷに接続されていれば、ユーザーＵは放送信号により提供されているコンテンツを視聴等することができる。

【0443】

情報取得部２１１は、ネット情報取得部２１１１と、ネット情報要求部２１１２と、放送情報取得部２１１３とを構成要素として備える。ネット情報取得部２１１１は、サービスリストＳＬとコンテンツリストＣＬとを、通信ネットワークを介して取得する。サービスリストＳＬには、放送に関するサービスについての情報が含まれる。換言すれば、サービスリストＳＬには、従来放送信号から取得していたＳＤＴ相当の情報が含まれている。サービスリストＳＬにはＳＤＴ相当の情報が含まれているため、受信装置２は、放送信号を受信することができない環境においても、ＳＤＴ相当の情報を取得することができる。ネット情報取得部２１１１によりサービスリストＳＬ及びコンテンツリストＣＬを取得するステップ又は工程を、ネット情報取得ステップ又はネット情報取得工程と記載する場合がある。ネット情報要求部２１１２は、取得したサービスリストＳＬに基づいて、特定のサービスやコンテンツに関する情報の提供を要求する。サービスに関する情報の提供を要求するための信号をサービス情報要求ＳＬＲＥＱと記載し、コンテンツに関する情報の提供を要求するための信号をコンテンツ情報要求ＣＬＲＥＱと記載する場合がある。ネット情報要求部２１１２により情報提供システム６に対する要求が出力された後、ネット情報取得部２１１１は、サービス情報要求ＳＬＲＥＱに基づいてサービスリストＳＬを取得し、コンテンツ情報要求ＣＬＲＥＱに基づいてコンテンツリストＣＬを取得する。ネット情報要求部２１１２により特定のコンテンツに関する情報の提供を要求するステップ又は工程を、ネット情報要求ステップ又はネット情報要求工程と記載する場合がある。放送情報取得部２１１３は、放送コンテンツ取得部２２３により取得された放送信号に含まれるサービスに関する情報（ＳＤＴ）やコンテンツに関する情報（ＥＩＴ）を取得する。

【0444】

情報統合部２１２は、ネット情報取得部２１１１からサービスリストＳＬとコンテンツリストＣＬとを取得する。また、情報統合部２１２は、放送情報取得部２１１３からＳＤＴとＥＩＴとを取得する。情報統合部２１２は、ネットから取得したサービスに関する情報（サービスリストＳＬ）と、放送から取得したサービスに関する情報（ＳＤＴ）とを統合し一つの情報としてまとめる。また、情報統合部２１２は、ネットから取得したコンテンツに関する情報（コンテンツリストＣＬ）と、放送から取得したコンテンツに関する情報（ＥＩＴ）とを統合し一つの情報としてまとめる。情報統合部２１２は、例えば、同一の系列（affiliation）に属する複数のサービスに関する情報を統合し、統合サービスリストＩＳＬを生成する。ここで、系列とは、典型的には放送事業における系列である。例えば、「ＮＨＫ総合・東京」という放送サービスと、「ＮＨＫ総合・名古屋」という放送サービスとは、いずれも、「ＮＨＫ総合」という系列に属する。また、例えば、関東地域をサービスエリアとする放送事業者と、近畿（関西）地域をサービスエリアとする放送事業者とが、別法人であっても、同一の系列に属するものであってもよい。また、情報統合部２１２は、同一のコンテンツを同時に又は略同時に配信する複数のサービスに関する情報を統合して統合サービスリストＩＳＬを生成してよい。情報統合部２１２は、統合したサービスに関する情報を統合サービスリストＩＳＬとして、統合したコンテンツに関する情報を統合コンテンツリストＩＣＬとして提示方法決定部２１３に出力する。

【0445】

提示方法決定部２１３は、情報統合部２１２から統合サービスリストＩＳＬと統合コンテンツリストＩＣＬとを取得する。提示方法決定部２１３は、取得した統合サービスリストＩＳＬ及び統合コンテンツリストＩＣＬに基づき、コンテンツの提示方法を決定する。コンテンツの提示方法とは、すなわち、放送により提供されるサービス及びネットワークを介して提供される複数のサービスのうち、いずれのサービスにより提供されるコンテンツを提示するかであってもよい。提示方法決定部２１３は、いずれのサービスにより提供されるコンテンツを提示するかを特定し、ネットコンテンツ取得部２１４に対しネットコンテンツ要求ＮＣＲＥＱを出力する。ネットコンテンツ要求ＮＣＲＥＱには、コンテンツが提供されるサービスに関する情報が少なくとも含まれる。また、ネットコンテンツ要求ＮＣＲＥＱには、コンテンツを識別する情報が含まれていてもよい。

【0446】

なお、提示方法決定部２１３は、ネットワークを介して提供される複数のサービスのうち、いずれのサービスにより提供されるコンテンツを提示するかであってもよい。提示方法決定部２１３は、ネットコンテンツ取得部２１４により取得された情報及び放送コンテンツ取得部２２３により取得された情報のいずれも提示可能な場合、放送コンテンツ取得部により取得された情報を提示してもよい。すなわち、コンテンツ提示部２２２は、ネットワークを介して提供されるコンテンツより放送信号から取得されるコンテンツを優先して提示してもよい。

【0447】

ネットコンテンツ取得部２１４は、提示方法決定部２１３からネットコンテンツ要求ＮＣＲＥＱを取得する。ネットコンテンツ取得部２１４は、取得したネットコンテンツ要求ＮＣＲＥＱに基づき、コンテンツ配信装置７から所定の通信ネットワークＮＷを介してコンテンツを取得する。ネットコンテンツ要求ＮＣＲＥＱとは、サービスリストＳＬに基づく要求である。すなわち、ネットコンテンツ取得部２１４は、ネット情報取得部２１１１により取得されたサービスリストＳＬに基づく要求に応じて提供された情報を、通信ネットワークＮＷを介して取得する。ネットコンテンツ取得部２１４がコンテンツ配信装置７から取得する情報をネット配信情報ＮＤＩと記載する。ネットコンテンツ取得部２１４は、取得したネット配信情報ＮＤＩに基づき、動画や音声やテキストを提示するための情報としてネットコンテンツ情報ＮＣＩを生成する。ネットコンテンツ取得部２１４は、生成したネットコンテンツ情報ＮＣＩをコンテンツ提示部２２２に提供する。

【0448】

事前情報設定部２１５は、ユーザーＵの操作に基づき、事前情報を設定する。ユーザーＵにより設定される事前情報の種類には、取得するコンテンツの優先度に関するもの等が含まれる。事前情報設定部２１５は操作取得部２２１により取得されたユーザーＵの操作に関する情報が含まれる操作情報ＯＩを取得し、操作情報ＯＩに基づき設定された情報を記憶する。事前情報設定部２１５は、ネット情報要求部２１１２からの要求に基づき、記憶した情報を事前設定情報ＰＳＩとして提供する。ネット情報要求部２１１２は、事前情報設定部２１５から事前設定情報ＰＳＩを取得し、取得した事前設定情報ＰＳＩに基づきサービスリストＳＬやコンテンツリストＣＬを要求する。

【0449】

図５５は、実施形態に係る情報提供システム及び情報登録装置の機能構成の一例を示すブロック図である。同図を参照しながら、情報提供システム６及び情報登録装置５の機能構成の一例について説明する。情報提供システム６及び情報登録装置５は、所定の通信ネットワークＮＷを介して受信装置２にサービスリストＳＬ及びコンテンツリストＣＬを出力する。

【0450】

なお、図示する一例では、サービスリストＳＬを提供するサーバー装置と、コンテンツリストＣＬを提供するサーバー装置が異なるサーバー装置である場合の一例について説明するが、本実施形態の態様はこの一例に限定されない。例えば、他の実施形態の態様として、単一のサーバー装置がサービスリストＳＬ及びコンテンツリストＣＬを提供する構成としてもよい。また、図示する一例では、更に、サービスリストＳＬ及びコンテンツリストＣＬの少なくともいずれかに更新があった場合に受信装置２に更新通知を行うためのサーバー装置を備える。しかしながら更新通知を行う機能は、サービスリストＳＬを提供するサーバー装置及びコンテンツリストＣＬを提供するサーバー装置のそれぞれに備えらえられていてもよい。すなわち、図示する構成の一例は、本実施形態の概要を説明するための具体的な一例であり、本実施形態の態様を限定するものではない。

【0451】

まず、情報登録装置５の機能構成の一例について説明する。情報登録装置５は、コンテンツプロバイダーＣＰにより運用される。情報登録装置５は、サービス情報登録部５１と、コンテンツ情報登録部５２とを含んで構成される。サービス情報登録部５１は、サービスリストＳＬを情報提供システム６に提供する。コンテンツ情報登録部５２は、コンテンツリストＣＬを情報提供システム６に提供する。情報登録装置５から情報提供システム６に提供されるサービスリストＳＬ及びコンテンツリストＣＬは、リストが新たに登録される場合においてはリストの全部であってもよいし、リストの一部が更新される場合においてはリストの一部であってもよい。情報登録装置５がリストの一部を更新する場合には、更新する部分についての情報と併せて、リストのうち更新する部分を特定するための情報が提供される。すなわち、サービスリストＳＬ及びコンテンツリストＣＬは、複数の構成要素から構成される構造を有している。複数の構成要素は、例えば階層構造を有していてもよく、リストの一部が更新される場合には、任意の階層を特定して更新してもよい。なお、図示する一例では、サービス情報登録部５１とコンテンツ情報登録部５２とを異なる構成としているが、サービス情報登録部５１及びコンテンツ情報登録部５２は、単一の機能部として構成されていてもよい。また、複数の構成要素は、「ネットワーク型構造」「リレーショナルデータ型構造」「ＲＤＦ(Resource Description Framework)型の構造」等のデータ構造を有していてもよい。

【0452】

次に、情報提供システム６の機能構成の一例について説明する。情報提供システム６は、サービス情報提供サーバー装置６１と、コンテンツ情報提供サーバー装置６２と、イベント情報提供サーバー装置６３とを含んで構成される。

【0453】

サービス情報提供サーバー装置６１は、サービス情報登録受付部６１１と、サービス情報データベース６１２と、サービス情報提供部６１３と、サービス情報更新要求取得部６１４とを含んで構成される。サービス情報登録受付部６１１は、サービス情報登録部５１からサービスリストＳＬを取得する。サービス情報登録受付部６１１は、取得したサービスリストＳＬをサービス情報データベース６１２に登録する。サービス情報登録部５１から取得したサービスリストＳＬが新たに登録されるものである場合（リストの全部を含むものである場合）、サービス情報登録受付部６１１は、新たにサービスリストＳＬをサービス情報データベース６１２に記憶させる。また、サービス情報登録部５１から取得したサービスリストＳＬが既に登録されているサービスリストＳＬの一部を更新するものである場合（リストの一部を含むものである場合）、サービス情報登録受付部６１１は、既に登録されたサービスリストＳＬの一部を更新する。すなわち、サービス情報登録受付部６１１は、サービス情報データベース６１２に記憶された情報を管理する記憶管理部であるということもできる。サービス情報データベース６１２は、サービスリストＳＬを記憶する。サービス情報データベース６１２に記憶されるサービスリストＳＬは、サービス情報登録受付部６１１により提供され、更新される。サービス情報提供部６１３は、所定の通信ネットワークを介してサービスリストＳＬを受信装置２に提供する。なお、サービス情報提供部６１３は、受信装置２から取得したサービス情報要求ＳＬＲＥＱに基づいてサービスリストＳＬを提供してもよい。サービス情報要求ＳＬＲＥＱは、サービス情報更新要求取得部６１４により取得され、サービス情報提供部６１３に通知される。

【0454】

コンテンツ情報提供サーバー装置６２は、管理の対象がサービスリストＳＬに代えてコンテンツリストＣＬである点においてサービス情報提供サーバー装置６１とは異なるものの、サービス情報提供サーバー装置６１と略同一の構成を採用し得る。コンテンツ情報提供サーバー装置６２は、コンテンツ情報登録受付部６２１と、コンテンツ情報データベース６２２と、コンテンツ情報提供部６２３と、コンテンツ情報更新要求取得部６２４とを含んで構成される。コンテンツ情報登録受付部６２１は、コンテンツ情報登録部５２からコンテンツリストＣＬを取得する。コンテンツ情報登録受付部６２１は、取得したコンテンツリストＣＬをコンテンツ情報データベース６２２に登録する。コンテンツ情報登録部５２から取得したコンテンツリストＣＬが新たに登録されるものである場合（リストの全部を含むものである場合）、コンテンツ情報登録受付部６２１は、新たにコンテンツリストＣＬをコンテンツ情報データベース６２２に記憶させる。また、コンテンツ情報登録部５２から取得したコンテンツリストＣＬが既に登録されているコンテンツリストＣＬの一部を更新するものである場合（リストの一部を含むものである場合）、コンテンツ情報登録受付部６２１は、既に登録されたコンテンツリストＣＬの一部を更新する。すなわち、コンテンツ情報登録受付部６２１は、コンテンツ情報データベース６２２に記憶された情報を管理する記憶管理部であるということもできる。コンテンツ情報データベース６２２は、コンテンツリストＣＬを記憶する。コンテンツ情報データベース６２２に記憶されるコンテンツリストＣＬは、コンテンツ情報登録受付部６２１により提供され、更新される。コンテンツ情報提供部６２３は、所定の通信ネットワークを介してコンテンツリストＣＬを受信装置２に提供する。なお、コンテンツ情報提供部６２３は、受信装置２から取得したコンテンツ情報要求ＣＬＲＥＱに基づいてコンテンツリストＣＬを提供してもよい。コンテンツ情報要求ＣＲＥＱは、コンテンツ情報更新要求取得部６２４により取得され、コンテンツ情報提供部６２３に通知される。

【0455】

イベント情報提供サーバー装置６３は、更新情報取得部６３１と、記憶情報取得部６３２と、差分判定部６３３と、更新通知部６３４とを含んで構成される。更新情報取得部６３１は、情報登録装置５からサービスリストＳＬ又はコンテンツリストＣＬの更新が行われると、サービス情報提供サーバー装置６１からサービスリストＳＬを取得し、コンテンツ情報提供サーバー装置６２からコンテンツリストＣＬを取得する。更新情報取得部６３１は、取得した更新に関する情報を更新情報ＵＩとして差分判定部６３３に出力する。記憶情報取得部６３２は、サービス情報データベース６１２に記憶されたサービスリストＳＬを取得し、コンテンツ情報データベース６２２に記憶されたコンテンツリストＣＬを取得する。記憶情報取得部６３２は、データベースに記憶された情報を記憶情報ＳＩとして差分判定部６３３に出力する。差分判定部６３３は、更新情報取得部６３１から更新情報ＵＩを取得し、記憶情報取得部６３２から記憶情報ＳＩを取得する。差分判定部６３３は、記憶された情報と更新に係る情報とを比較し、差分を判定する。差分判定部６３３は、差分が判定された場合、当該差分に関する情報を差分情報ＤＩとして更新通知部６３４に提供する。更新通知部６３４は、差分判定部６３３から差分情報ＤＩを取得する。更新通知部６３４は、取得した差分情報ＤＩに基づき、受信装置２に更新通知ＵＮを出力する。更新通知ＵＮには、サービスリストＳＬ又はコンテンツリストＣＬの少なくとも一方に更新が行われた事実と、更新箇所に関する情報が含まれている。受信装置２は、更新通知ＵＮを取得すると、更新通知ＵＮに含まれる更新箇所について、サービス情報要求ＳＬＲＥＱ又はコンテンツ情報要求ＣＬＲＥＱを出力し、サービスリストＳＬ又はコンテンツリストＣＬの更新を行う。

【0456】

図５６は、実施形態に係るシステムの一連の動作の一例を示す状態遷移図である。同図を参照しながら、システム１の一連の動作の一例について説明する。同図には、受信装置２が起動され、ユーザーＵの操作に応じたコンテンツを再生するまでの一連の動作が示されている。以下、同図に沿って処理手順を説明する。

【0457】

ステップＳ１１１において、受信装置２は、ユーザーＵからの起動要求を受け付ける。この起動要求は、例えば、リモコン装置の信号（赤外線信号等）によって伝達される。受信装置２は、起動要求に基づいて起動する。

【0458】

ステップＳ１２１において、起動後の受信装置２の放送コンテンツ取得部２２３は、放送送出装置８により送出された放送信号を受信し、サービスインフォメーション（ＳＩ）及びＥＰＧ（電子番組表）を取得する。ＳＩは、ＥＰＧのデータを含んでいてもよい。放送コンテンツ取得部２２３により取得されたＳＩ及びＥＰＧは、放送情報取得部２１１３に提供される。

【0459】

ステップＳ１３１において、受信装置２のネット情報要求部２１１２は、所定の通信ネットワークＮＷを介してサービス情報提供サーバー装置６１に対しサービス情報要求ＳＬＲＥＱを出力し、サービスリストＳＬの提供を要求する。サービス情報提供サーバー装置６１のサービス情報更新要求取得部６１４によりサービス情報要求ＳＬＲＥＱが受信されると、サービス情報提供サーバー装置６１は受信装置２に対して送信するためのサービスリストＳＬを準備する。

【0460】

ステップＳ１３３において、サービス情報提供サーバー装置６１のサービス情報提供部６１３は、要求元の受信装置２に対してサービスリストＳＬを出力する。サービス情報要求ＳＬＲＥＱには、システム１に含まれる複数の受信装置２のうち、各装置を識別するための識別情報が含まれていてもよい。受信装置２のネット情報取得部２１１１は、サービス情報提供サーバー装置６１のサービス情報提供部６１３から出力されたサービスリストＳＬを受信する。

【0461】

ステップＳ１３５において、受信装置２の情報統合部２１２は、放送信号から取得したサービスに関する情報と通信ネットワークＮＷを介して取得したサービスに関する情報とを統合する処理を行う。統合処理の結果として、統合サービスリストＩＳＬが生成される。なお、統合サービスリストＩＳＬは、通信ネットワークＮＷを介して取得した情報のみに基づいて生成されてもよい。すなわち情報統合部２１２は、放送信号を取得できない環境においても統合サービスリストＩＳＬを生成することができる。また、統合サービスリストＩＳＬは、放送信号のみに基づいて生成されてもよい。すなわち情報統合部２１２は、通信ネットワークＮＷを介して情報を取得できない環境においても統合サービスリストＩＳＬを生成することができる。

【0462】

ステップＳ１４１において、受信装置２のネット情報要求部２１１２は、所定の通信ネットワークＮＷを介してコンテンツ情報提供サーバー装置６２に対しコンテンツ情報要求ＣＬＲＥＱを出力し、コンテンツリストＣＬの提供を要求する。コンテンツ情報提供サーバー装置６２のコンテンツ情報更新要求取得部６２４によりコンテンツ情報要求ＣＬＲＥＱが受信されると、コンテンツ情報提供サーバー装置６２は受信装置２に対して送信するためのコンテンツリストＣＬを準備する。

【0463】

ステップＳ１４３において、コンテンツ情報提供サーバー装置６２のコンテンツ情報提供部６２３は、要求元の受信装置２に対してコンテンツリストＣＬを出力する。コンテンツ情報要求ＣＬＲＥＱには、システム１に含まれる複数の受信装置２のうち、各装置を識別するための識別情報が含まれていてもよい。受信装置２のネット情報取得部２１１１は、コンテンツ情報提供サーバー装置６２のコンテンツ情報提供部６２３から出力されたコンテンツリストＣＬを受信する。

【0464】

ステップＳ１４５において、受信装置２の情報統合部２１２は、放送信号から取得したコンテンツに関する情報と通信ネットワークＮＷを介して取得したコンテンツに関する情報とを統合する処理を行う。統合処理の結果として統合コンテンツリストＩＣＬが生成される。なお、統合コンテンツリストＩＣＬは、通信ネットワークＮＷを介して取得した情報のみに基づいて生成されてもよい。すなわち情報統合部２１２は、放送信号を取得できない環境においても統合コンテンツリストＩＣＬを生成することができる。また、統合コンテンツリストＩＣＬは、放送信号のみに基づいて生成されてもよい。すなわち情報統合部２１２は、通信ネットワークＮＷを介して情報を取得できない環境においても統合コンテンツリストＩＣＬを生成することができる。

【0465】

ステップＳ１４７において、受信装置２のコンテンツ提示部２２２は、情報統合部２１２により統合された統合コンテンツリストＩＣＬに基づいて、統合コンテンツのリストをユーザーＵに対して提示する。具体的には、受信装置２は、統合コンテンツのリストを不図示の表示部等に表示する。統合コンテンツのリストとは、例えば番組表であってもよい。ユーザーは統合コンテンツのリストが表示された表示部等を見ることによって、取得可能な統合コンテンツのリストを認識することができる。ユーザーＵは、リモコン装置等を用いることによって、統合コンテンツリストの中から、取得を所望するコンテンツを選択することができる。

【0466】

すなわち、受信装置２のネット情報取得部２１１１は、後述する監視プロセスが立ち上がる前に、自装置が起動したことに応じて、所定の通信ネットワークを介してサービスリストＳＬ及びコンテンツリストＣＬを取得する。自装置が起動したタイミングで所定の通信ネットワークを介してサービスリストＳＬ及びコンテンツリストＣＬを取得することにより、受信装置２は、自装置が取得可能なサービス及びコンテンツを認識することができる。

【0467】

ステップＳ１５１において、受信装置２は、監視プロセスを立ち上げる。監視プロセスとは、サービスリストＳＬ及びコンテンツリストＣＬに更新があったか否かを監視するためのプロセスである。ここで、サービスリストＳＬ及びコンテンツリストＣＬを更新するための条件としては、複数設定されていてもよい。具体的には、以下の３つの条件を例示することができる。すなわち、第１の条件とは、情報提供システム６から更新通知ＵＮを取得したか否かである。第２の条件とは、所定の時間が経過したか否か、すなわち定期的な監視である。第３の所定の時間が経過とは、ユーザーＵからの操作に基づくものである。監視プロセスは、更新のための条件が満たされたか否かを判定し、更新のための条件が満たされた場合には、サービスリストＳＬ及びコンテンツリストＣＬの少なくとも一部を更新する。

【0468】

ステップＳ１６１において、受信装置２の操作取得部２２１は、ユーザーＵから操作を取得することにより、コンテンツの再生要求を取得する。具体的には、当該再生要求は、リモコン装置等の信号として受信装置２に伝えられる。当該再生要求は、コンテンツを識別する識別情報を含む。受信装置２は、ユーザーＵから当該再生要求を取得するにより、ユーザーＵが取得を所望するコンテンツを特定する。

【0469】

ステップＳ１６３において、受信装置２の提示方法決定部２１３は、ユーザーＵから要求されたコンテンツの提示方法を決定する。つまり、受信装置２は、ユーザーＵから要求されたコンテンツについて、複数の選択肢が存在する場合（例えば、放送コンテンツＢＣ及びネットコンテンツＮＣのいずれも取得可能な場合）、いずれのコンテンツをユーザーＵに対して提示するかを決定する。受信装置２は、コンテンツの提示方法を決定すると、当該コンテンツにアクセスするための情報（放送におけるサービスを特定する情報やネット配信における所在情報（ＵＲＬ）等）が明らかになる。

【0470】

ステップＳ１６５において、受信装置２の放送コンテンツ取得部２２３又はネットコンテンツ取得部２１４は、提示方法決定部２１３により決定された提示方法に基づき、コンテンツを取得する。また、受信装置２のコンテンツ提示部２２２は、取得されたコンテンツをユーザーＵに対して提示する。コンテンツ提示部２２２により提示されるコンテンツは、映像コンテンツ（映像と音声とを構成要素として含むコンテンツ）であってもよいし、音声のみを構成要素として含むコンテンツであってもよいし、ウェブページ等であってもよいし、その他の任意の形態のコンテンツであってもよい。受信装置２は、映像を画面に表示し、音声をスピーカー等（イヤフォン等を含む）から出力し、ウェブページ等の情報を画面に表示することができる。

【0471】

以上説明した処理により、受信装置２は、コンテンツ情報を統合することができ、また統合コンテンツの提示方法を決定して提示することができる。なお、受信装置２は、既に統合済みのサービスに関する情報やコンテンツに関する情報を記憶装置等に保持しておき、記憶された情報を利用してコンテンツの取得および提示を行ってもよい。

【0472】

図５７は、実施形態に係るコンテンツプロバイダーがコンテンツリスト（コンテンツ情報）を提供する場合における一連の動作の一例を示す状態遷移図である。同図には、コンテンツプロバイダーＣＰとしての情報登録装置５がコンテンツリストＣＬを提供し、受信装置２が受信するまでの一連の動作が示されている。以下、同図を参照しながら、情報登録装置５が新たにコンテンツリストＣＬを登録する場合と、既に登録されているコンテンツリストＣＬの一部を更新する場合の処理手順について、それぞれ説明する。情報提供システム６が備える機能は、上述したようにサービス情報提供サーバー装置６１、コンテンツ情報提供サーバー装置６２及びイベント情報提供サーバー装置６３に分散されていてもよいし、単一のサーバーに備えられていてもよいし、他の集約方法により複数のサーバー装置に備えられていてもよい。また、情報提供システム６自体をサーバー装置と記載し、情報提供システム６に含まれるいずれのサーバー装置が備える機能かを区別しない場合がある。なお、サービスリストＳＬの登録手順については説明を省略するが、サービスリストＳＬの登録手順についても、同図を用いて説明するコンテンツリストＣＬの登録手順と同様であってもよい。

【0473】

まず、情報登録装置５が新たにコンテンツリストＣＬを登録する場合について説明する。新たにコンテンツリストＣＬを登録する場合とは、すなわち、情報登録装置５が情報提供システム６に対して未だ情報を提供したことがないコンテンツについての情報を登録する場合である。

【0474】

ステップＳ２１１において、情報登録装置５のコンテンツ情報登録部５２は、コンテンツ情報提供サーバー装置６２のコンテンツ情報登録受付部６２１に対してコンテンツリストＣＬを提供する。

【0475】

ステップＳ２１３において、コンテンツ情報提供サーバー装置６２のコンテンツ情報登録受付部６２１は、情報登録装置５からコンテンツリストＣＬを取得する。

【0476】

ステップＳ２１５において、コンテンツ情報提供サーバー装置６２のコンテンツ情報登録受付部６２１は、取得したコンテンツリストＣＬをコンテンツ情報データベース６２２に記憶させる。ここで、本実施形態に係るコンテンツリストＣＬは、複数の情報を互いに分離可能な構成要素として有している。コンテンツリストＣＬが有する複数の情報には、コンテンツを識別する情報と当該コンテンツの属性に関する情報とが含まれる。また、当該構成要素は、階層構造を有していてもよい。構成要素の階層構造については後述する。コンテンツ情報登録受付部６２１は、取得したコンテンツリストＣＬを、各構成要素に分離可能な分離構造として記憶する。コンテンツ情報登録受付部６２１を、単に登録受付部と記載する場合がある。また、コンテンツ情報データベース６２２を、単に記憶部と記載する場合がある。

【0477】

ステップＳ２３１において、受信装置２が情報提供システム６に対しコンテンツ情報要求ＣＬＲＥＱを出力し、コンテンツリストＣＬの提供を要求する。受信装置２がコンテンツリストＣＬの提供を要求するタイミングとは、所定の条件を満たした場合であってもよい。所定の条件とは、例えば、装置の起動に基づくものであったり、所定の周期に基づくものであったり、ユーザーＵの操作に基づくものであってもよい。

【0478】

ステップＳ２３３において、コンテンツ情報提供サーバー装置６２のコンテンツ情報更新要求取得部６２４が受信装置２からコンテンツ情報要求ＣＬＲＥＱを取得すると、コンテンツ情報提供部６２３は、要求があった受信装置２に対して、コンテンツ情報データベース６２２に記憶されたコンテンツリストＣＬを出力する。受信装置２は、コンテンツ情報提供部６２３から出力されたコンテンツリストＣＬを取得する。

【0479】

次に、情報登録装置５が、既に登録されているコンテンツリストＣＬの一部を更新する場合について説明する。

【0480】

ステップＳ３１１において、情報登録装置５のコンテンツ情報登録部５２は、コンテンツ情報提供サーバー装置６２のコンテンツ情報登録受付部６２１に対してコンテンツリストＣＬを提供する。既に登録されているコンテンツリストＣＬの一部を更新する場合において、情報登録装置５は、コンテンツリストＣＬの全てを情報提供システム６に対して出力してもよいし、コンテンツリストＣＬのうち更新する部分だけを出力してもよい。更新する部分は、コンテンツリストＣＬを構成する構成要素ごとであってもよい。

【0481】

ステップＳ３１３において、コンテンツ情報提供サーバー装置６２のコンテンツ情報登録受付部６２１は、情報登録装置５からコンテンツリストＣＬを取得する。コンテンツ情報登録受付部６２１は、取得したコンテンツリストＣＬをサービス情報データベース６１２に記憶させる。コンテンツリストＣＬの一部が提供された場合、コンテンツ情報登録受付部６２１は、コンテンツ情報データベース６２２に記憶されたコンテンツリストＣＬの一部を更新する。また、コンテンツリストＣＬの全部が提供された場合、コンテンツ情報登録受付部６２１は、コンテンツ情報データベース６２２に記憶されたコンテンツリストＣＬの全部を更新する。

【0482】

ステップＳ３１５において、更新情報取得部６３１は、コンテンツ情報登録受付部６２１により取得されたコンテンツリストＣＬを更新情報ＵＩとして差分判定部６３３に出力する。また、記憶情報取得部６３２は、サービス情報データベース６１２に記憶された情報を記憶情報ＳＩとして差分判定部６３３に出力する。差分判定部６３３は、コンテンツ情報登録受付部６２１によりコンテンツリストＣＬが取得された場合に、コンテンツ情報登録受付部６２１により取得されたコンテンツリストＣＬと、コンテンツ情報データベース６２２に記憶されたコンテンツリストＣＬとを比較し、差分を有する構成要素の有無を判定する。差分判定部６３３は、判定した差分に関する情報を差分情報ＤＩとして更新通知部６３４に提供する。更新通知部６３４は、差分を有する構成要素の有無に基づいて、差分を有する構成要素が存在する場合に更新通知ＵＮを提供する。更新通知ＵＮは、所定の通信ネットワークＮＷを介して受信装置２に提供される。更新通知ＵＮには、差分を有する構成要素を特定する情報が含まれる。更新通知部６３４を、単に通知部と記載する場合がある。

【0483】

ステップＳ３３１において、受信装置２のネット情報取得部２１１１は、情報提供システム６の更新通知部６３４から更新通知ＵＮを取得する。コンテンツリストＣＬには、特定の構成要素を特定する情報が含まれる。更新通知ＵＮを取得するステップ又は工程を、ネット情報取得ステップ又はネット情報取得工程と記載する場合がある。受信装置２のネット情報要求部２１１２は、事前情報設定部２１５により設定された事前情報に基づき、取得した更新通知ＵＮにより特定される構成要素の更新をするか否かの判定を行う。例えば、ユーザーＵが興味を有さないコンテンツについては、更新された場合であってもコンテンツリストＣＬを更新しなくてもよい。なお、ネット情報要求部２１１２による更新要否の判定は任意であり、更新要否の判定を行わず、更新があった構成要素についての提供を要求する構成を採用してもよい。

【0484】

ステップＳ３４１において、受信装置２のネット情報要求部２１１２は、ネット情報取得部２１１１により取得された更新通知ＵＮに基づき、特定された構成要素を含む情報の提供を要求する。当該要求はコンテンツ情報要求ＣＬＲＥＱ又は更新要求としてコンテンツ情報提供サーバー装置６２に出力される。ネット情報要求部２１１２は、更新要否の判定を行った結果、更新すると判定された場合に、特定された構成要素を含む情報の提供を要求してもよい。特定された構成要素を含む情報の提供を要求するステップ又は工程を、ネット情報要求ステップ又はネット情報要求工程と記載する場合がある。

【0485】

ステップＳ３４３において、コンテンツ情報提供サーバー装置６２のコンテンツ情報更新要求取得部６２４は、コンテンツ情報要求ＣＬＲＥＱ又は更新要求を、受信装置２から取得する。更新要求とは、すなわち更新通知ＵＮに基づき出力された要求であって、コンテンツリストＣＬのうち更新を要求する構成要素を特定する情報を含む要求である。コンテンツ情報提供部６２３は、コンテンツ情報更新要求取得部６２４により取得された更新要求に基づき、コンテンツ情報データベース６２２に記憶されたコンテンツリストＣＬのうち特定された構成要素を含む情報を、更新要求を出力した受信装置２に対して提供する。コンテンツ情報提供部６２３は、特定された構成要素のみを出力してもよいし、コンテンツリストＣＬの全部を出力してもよい。

【0486】

図５８は、実施形態におけるコンテンツリスト（コンテンツ情報）が有する階層構造について説明するための模式図である。同図を参照しながら、コンテンツリストＣＬが有する階層構造について説明する。図示する一例では、コンテンツリストＣＬが第１階層Ｌ１か乃至第４階層Ｌ４の４階層を有する場合について示す。なお、コンテンツリストＣＬの階層は４階層である場合の一例に限定されず、コンテンツリストＣＬは１以上の階層を有していればよい。

【0487】

第１階層Ｌ１には、構成要素ＥＬ１－１が含まれる。構成要素ＥＬ１－１は、例えＩｔｅｍＬｉｓｔ（アイテムリスト）を特定する。

【0488】

第２階層Ｌ２には、構成要素ＥＬ２－１、構成要素ＥＬ２－２、構成要素ＥＬ２－３及び構成要素ＥＬ２－４が含まれる。第２階層Ｌ２に含まれる各構成要素は、例えば各コンテンツに対応する。図示する一例では、構成要素ＥＬ２－１により特定されるコンテンツの一例について示し、構成要素ＥＬ２－２、構成要素ＥＬ２－３及び構成要素ＥＬ２－４に含まれる第３階層Ｌ３以降の階層については説明を省略する。第２階層Ｌ２には、例えば、ＴＶ Ｅｐｉｓｏｄｅ（テレビエピソード）、Ｒａｄｉｏ Ｅｐｉｓｏｄｅ（ラジオエピソード）、及びＷｅｂ Ｐａｇｅ（ウェブページ）等の情報が含まれる。

【0489】

第３階層Ｌ３には、構成要素ＥＬ３－１、構成要素ＥＬ３－２及び構成要素ＥＬ３－３が含まれる。構成要素ＥＬ３－１は、例えばＩｄｅｎｔｉｆｉｅｒ（識別情報）が含まれる。Ｉｄｅｎｔｉｆｉｅｒとは、コンテンツを識別するための識別情報である。構成要素ＥＬ３－２は、例えばａｓｓｏｃｉａｔｅｄＭｅｄｉａ（アソシエイテッドメディア）が含まれる。ａｓｓｏｃｉａｔｅｄＭｅｄｉａは、コンテンツを配信するためのメディアに対応し、コンテンツプロバイダーＣＰによる編成にしたがってコンテンツを配信するメディアである。構成要素ＥＬ３－３は、例えばｉｓＲｅｌａｔｅｄＴｏ（関連コンテンツ）が含まれる。ｉｓＲｅｌａｔｅｄＴｏは、当該コンテンツに関連するコンテンツ（例えば複数のエピソードからなるシリーズもののコンテンツの他のエピソード）を特定する。

【0490】

第４階層Ｌ４には、ａｓｓｏｃｉａｔｅｄＭｅｄｉａである構成要素ＥＬ３－２の下位構成として、構成要素ＥＬ４－１１と構成要素ＥＬ４－１２とが含まれる。構成要素ＥＬ４－１１及び構成要素ＥＬ４－１２には、ｐｕｂｌｉｃａｔｉｏｎ（物理的な配信情報）が含まれる。ａｓｓｏｃｉａｔｅｄＭｅｄｉａとは、コンテンツの配信方法に関する情報を特定するものであるため、ａｓｓｏｃｉａｔｅｄＭｅｄｉａの下位階層には、当該コンテンツの物理的な配信方法に関する情報が含まれるということができる。ｐｕｂｌｉｃａｔｉｏｎの一例としては、ＢｒｏａｄｃａｓｔＥｖｅｎｔや、ＯｎＤｅｍａｎｄＥｖｅｎｔを例示することができる。また、第４階層Ｌ４にはｉｓＲｅｌａｔｅｄＴｏである構成要素ＥＬ３－３の下位構成として、構成要素ＥＬ４－２１と構成要素ＥＬ４－２２と構成要素ＥＬ４－２３とが含まれる。構成要素ＥＬ３－３の下位構成として含まれる各構成要素は、コンテンツを特定する。すなわち、当該構成要素の下位構成としては、対象のコンテンツにおける第２階層Ｌ２以下の構成が複製されていてもよい。

【0491】

なお、情報提供システム６から受信装置２に提供される更新通知ＵＮには、図示した構成要素を特定する情報が含まれる。受信装置２は、当該構成要素単位でコンテンツリストＣＬの更新を要求し、コンテンツリストＣＬを更新する。

【0492】

次に、サービスリスト及びコンテンツリストの更新に係る実施形態について説明する。従来技術によれば、コンテンツを視聴するための受信端末は、コンテンツの再生要求に応じて配信方法リストを取得し、取得した配信方法リストに基づいてコンテンツを取得する。このような技術によれば、受信端末は放送により提供されるコンテンツと通信ネットワークを介して提供されるコンテンツとを受信することができるかもしれない。ここで、放送番組に関する情報は、放送信号の中にＥＰＧ（電子番組表）として多重化されており、常時プッシュ型の更新が行われている。したがって、従来技術による受信端末は、放送信号を取得することができなければ放送番組に関する情報を取得することができず、その結果として放送番組と同等のコンテンツを、通信ネットワークを介して取得することができなかった。そこで本実施形態は、複数の方式により提供されるコンテンツを好適に受信し、ユーザーに提示することが可能な受信装置及びプログラムを提供しようとするものである。

【0493】

図５９は、実施形態に係る受信装置により行われるサービスリスト及びコンテンツリストの更新動作の一例を示すフローチャートである。同図を参照しながら、監視プロセスの動作の一例について説明する。

【0494】

ステップＳ２１において、監視プロセスは、更新のための条件を満たしたか否かを判定する。更新のための条件には、例えば以下の３つの条件のうち少なくともいずれかが含まれていてもよい。第１の条件とは、情報提供システム６から更新通知ＵＮを取得したか否かである。第２の条件とは、所定の時間が経過したか否か、すなわち定期的な監視である。第３の条件とは、ユーザーＵからの操作に基づくものである。監視プロセスは、更新のための条件を満たした場合（すなわち、ステップＳ２１；ＹＥＳ）、処理をステップＳ２３に進める。また、監視プロセスは、更新のための条件を満たすまで、ステップＳ２１の処理を繰り返す（すなわち、ステップＳ２１；ＮＯ）。

【0495】

ステップＳ２３において、監視プロセスは、放送送出装置８により送出された放送信号を受信し、サービスインフォメーション（ＳＩ）及びＥＰＧ（電子番組表）を取得する。すなわちＳＩ及びＥＰＧの取得は、サービスリストＳＬ及びコンテンツリストＣＬの更新時においても行われる。

【0496】

ステップＳ２５において、監視プロセスは、所定の通信ネットワークＮＷを介してサービス情報提供サーバー装置６１に対しサービス情報要求ＳＬＲＥＱ及びコンテンツ情報要求ＣＬＲＥＱを出力し、サービスリストＳＬ及びコンテンツリストＣＬの提供を要求する。なお、その他の実施形態として、更新の条件に応じて、監視プロセスはサービスリストＳＬ又はコンテンツリストＣＬのいずれかの提供を要求してもよい。

【0497】

ステップＳ２７において、監視プロセスは、情報提供システム６からサービスリストＳＬ及びコンテンツリストＣＬを取得する。監視プロセスが取得するサービスリストＳＬ及びコンテンツリストＣＬは、リストの全部を含んでいてもよいし、更新された部分を含むリストの一部であってもよい。なお、監視プロセスは、ネット情報取得部２１１１にサービスリストＳＬ及びコンテンツリストＣＬを取得させる。

【0498】

ここで、上述した第２の条件（定期的な監視）では、例えば複数の異なる時間間隔（又は周期）で更新の有無を監視してもよい。監視プロセスは、例えば２秒間隔で更新の有無を監視することによりｐ／ｆ相当の情報を取得し、１０秒間隔で更新の有無を監視することによりＥＩＴ相当の監視を行ってもよい。すなわちネット情報取得部２１１１は、第１の周期（例えば２秒）でサービスリストＳＬ及びコンテンツリストＣＬを取得し、更に第２の周期（例えば１０秒）でサービスリストＳＬ及びコンテンツリストＣＬを取得する。

【0499】

また、上述した第３の条件（ユーザーの操作）では、操作取得部２２１により取得されたユーザーＵの操作が特定の操作であるか否かを判定し、特定の操作であると判定された場合に更新を行う。特定の操作とは、例えば、表示された番組表からユーザーＵが特定の番組を選択することであってもよい。この場合、ネット情報取得部２１１１は、ユーザーＵの操作に基づきサービスリストＳＬ及びコンテンツリストＣＬを取得する。

【0500】

ステップＳ２９において、監視プロセスは、放送送出装置８により送出された放送信号に基づくＳＩ及びＥＰＧと、所定の通信ネットワークを介して取得されたサービスリストＳＬ及びコンテンツリストＣＬとに基づき、統合サービスリストＩＳＬ及び統合コンテンツリストＩＣＬを更新する。

【0501】

以上説明した実施形態によれば、受信装置２は、ネット情報取得部２１１１を備えることにより、放送に関するサービスについての情報が含まれるサービスリストＳＬを、通信ネットワークを介して取得する。サービスリストＳＬには、従来放送信号を通じて取得していたＳＤＴ相当の情報が含まれる。受信装置２は、ネット情報要求部２１１２を備えることにより、取得したサービスリストＳＬに基づいて特定のコンテンツに関する情報の提供を要求する。また、受信装置２は、コンテンツ提示部２２２を備えることにより、要求に応じて取得されたコンテンツに関する情報を提示する。受信装置２によれば、通信ネットワークを介してサービスリストＳＬを取得することによって、放送信号を取得できない環境においても、放送信号により可能なサービスと同等のサービスを、通信ネットワークＮＷを介して取得することができる。また、受信装置２は、提示するコンテンツの提供元を放送又はネットに任意に切り替えることができる。また、当該切り替えについて、ユーザーＵは意識しなくてもよい。したがって、本実施形態によれば、受信装置２は、ユーザーＵの操作によらず、自動的にコンテンツの提供元を放送又はネットに切り替えることができる。よって本実施形態によれば、複数の方式により提供されるコンテンツを好適に受信し、ユーザーに提示することができる。

【0502】

また、以上説明した実施形態によれば、受信装置２はネットコンテンツ取得部２１４を備えることにより、取得されたサービスリストＳＬに基づく要求に応じて提供された情報を、通信ネットワークＮＷを介して取得する。また、受信装置２は放送コンテンツ取得部２２３を備えることにより、コンテンツが含まれる放送信号を取得する。また、コンテンツ提示部２２２は、ネットコンテンツ取得部２１４により取得された情報又は放送コンテンツ取得部２２３により取得された情報のいずれかを提示する。受信装置２は、ユーザーＵの操作によらず、提示するコンテンツを自動的に切り替えることができる。よって本実施形態によれば、複数の方式により提供されるコンテンツを好適に受信し、ユーザーに提示することができる。

【0503】

また、以上説明した実施形態によれば、受信装置２のコンテンツ提示部２２２は、ネットコンテンツ取得部２１４により取得された情報及び放送コンテンツ取得部２２３により取得された情報のいずれも提示可能な場合、放送コンテンツ取得部２２３により取得された情報を提示する。すなわち、受信装置２は、通信ネットワークＮＷを介して取得されたコンテンツよりも放送信号から取得されたコンテンツを優先的に提示する。したがって、本実施形態によれば、通信ネットワークＮＷの使用量を抑止することができる。また、放送信号には、緊急地震速報等の緊急情報が含まれる場合がある。したがって、本実施形態によれば、放送信号から取得されたコンテンツを優先的に提示するため、緊急地震速報等の緊急情報をユーザーＵに提示することができる。

【0504】

また、以上説明した実施形態によれば、受信装置２のネット情報取得部２１１１は、自装置が起動したことに応じてサービスリストＳＬを取得する。受信装置２が起動したタイミングでは、放送信号を受信できる環境に置かれているか否かが不明である。したがって受信装置２は、自装置が起動したことに応じてサービスリストＳＬを取得することにより、放送信号が受信できない環境であっても、通信ネットワークＮＷを介してコンテンツを取得可能な状態にする。よって、本実施形態によれば、放送信号を受信できない状態であっても、通信ネットワークＮＷを介してコンテンツを好適に受信し、ユーザーに提示することができる。

【0505】

また、以上説明した実施形態によれば、ネット情報取得部２１１１は、第１の周期でサービスリストＳＬを取得し、第１の周期とは異なる第２の周期で更にサービスリストＳＬを取得する。第１の周期とは例えば２秒であり、第２の周期とは１０秒である。すなわち、受信装置２は、２秒周期でｐ／ｆ相当の更新を行うことができ、１０秒周期でＥＩＴスケジュール相当の更新をすることができる。よって、本実施形態によれば、放送信号を受信できない状態であっても、通信ネットワークＮＷを介してサービスに関する情報やコンテンツに関する情報を更新することにより、コンテンツを好適に受信し、ユーザーに提示することができる。

【0506】

また、以上説明した実施形態によれば、ネット情報取得部２１１１は、ユーザーＵの操作に基づきサービスリストＳＬを取得する。ここで、ユーザーＵは、受信装置２が保持しないサービスやコンテンツについて取得を望む場合がある。このような場合、ネット情報取得部２１１１は、ユーザーＵの操作に基づきサービスリストＳＬを取得することにより、ユーザーＵが望むサービスやコンテンツの提供を行うことができる。

【0507】

次に、システム１が緊急警報放送を行う場合の実施形態について説明する。放送信号を用いたサービスとして、従来、緊急警報放送（又はＥＷＳ：Emergency Warning System）のサービスが提供されている。緊急警報放送等の緊急イベントに関する情報を取得するためには、放送信号を受信することを要する。したがって、通信ネットワークには接続されているが、放送信号を受信することができないような受信端末は、緊急警報放送等の緊急イベントに関する情報を取得することができないといった問題があった。システム１は、このような問題を解決しようとするものである。

【0508】

システム１が緊急警報放送を行う場合、受信装置２は、自装置の起動後、緊急イベントに関する情報の受信方法に応じたプロセスを立ち上げる。緊急イベントに関する情報とは、例えば地震等の大規模災害の発生や、津波警報の発表等に関する情報である。緊急イベントに関する情報とは、具体的には緊急警報放送（又はＥＷＳ：Emergency Warning System）に用いられる緊急警報信号等であってもよい。また、本実施形態において緊急イベントに関する情報とは、ニュース速報に関する情報等を広く含む。以下の説明においては、緊急イベントに関する情報が緊急警報放送に用いられる緊急警報信号である場合の一例について説明する。受信装置２は、例えば受信方法取得部（不図示）を備えることにより、緊急イベントに関する情報の受信方法に関する情報を取得する。緊急イベントに関する情報の受信方法に関する情報には、複数の受信方法のうちいずれの受信方法であるかが示されていてもよい。緊急イベントに関する情報の受信方法に関する情報は、例えば情報提供システム６等から出力されてもよい。また、緊急イベントに関する情報の受信方法に関する情報は、ユーザーＵの操作等により設定されてもよい。

【0509】

緊急イベントに関する情報の受信方法の一例としては、映像ストリームの配信データの中に緊急イベントに関する情報を記述する方法（以下、第１の受信方法と記載する。）を例示することができる。また、緊急イベントに関する情報の受信方法のその他の一例としては、メタ情報として記述する方法（以下、第２の受信方法と記載する。）を例示することができる。緊急イベントに関する情報の受信方法に関する情報には、例えば、第１の受信方法又は第２の受信方法のいずれかを特定する情報が含まれていてもよい。この場合、受信装置２に備えられた受信方法取得部（不図示）は、第１の受信方法又は第２の受信方法のいずれであるかを示す情報を取得する。緊急イベントに関する情報の受信方法に関する情報は、例えば情報提供システム６から所定の通信ネットワークＮＷを介して提供されてもよいし、ユーザーＵの操作に基づいて提供されてもよい。緊急イベントに関する情報の受信方法に応じたプロセスとは、第１の受信方法に応じた第１のプロセス又は第２の受信方法に応じた第２のプロセスであってもよい。第１の受信方法と第２の受信方法の詳細については後述する。なお、本実施形態では例示しないが、その他の受信方法（例えば第３又は第４の受信方法等）が存在していてもよい。

【0510】

緊急イベントに関する情報は、例えばコンテンツプロバイダーＣＰから提供される。具体的には、コンテンツプロバイダーＣＰにより公開済みＡＰＩに登録されることにより、緊急イベントに関する情報が提供される。

【0511】

緊急イベントに関する情報は、例えば緊急イベントに関する条件が設定された緊急情報記述子としてＰＭＴ（Program Map Table）により送出されてもよい。緊急イベントに関する条件（ＥＷＳの条件）には、start_end_flag、第１種／第２種種別及び地域符号等が含まれていてもよい。

【0512】

緊急警報放送（ＥＷＳ）の開始時において、放送事業者は、ＴＭＣＣ（Transmission and Multiplexing Configuration Control）の緊急警報放送用起動フラグを１として送出する。送出側では、送出階層によらず、ＴＳ（network）内のいずれかのサービスで緊急警報放送が行われている期間は、ＴＭＣＣの緊急警報放送用起動フラグが常時１とされる。自動起動に対応した受信装置２は、ＴＭＣＣの緊急警報放送用起動フラグを常時監視する。監視方法は複数存在していてもよく、それぞれの方法については後述する。

【0513】

緊急情報記述子は、例えば当該緊急警報放送を行うサービスのＰＭＴの記述子領域に記憶される。受信装置２に対して緊急警報放送を実施中であることを明示するため、緊急警報放送サービスそのもののＰＭＴには当該記述子が記載される。その他のサービスのＰＭＴに緊急情報記述子を記載するか否かは、各放送事業者によって定められてもよい。ただし異なる階層のサービスを記載した場合は、受信装置２によって無視されてしまう場合がある。

【0514】

緊急警報放送の終了時において、放送事業者は、ＴＭＣＣの緊急警報放送用起動フラグを０として送出する。また、緊急放送の終了時において、ＰＭＴから緊急情報記述子が削除される。

【0515】

図６０は、実施形態に係る緊急イベントに関する情報の第１の受信方法について説明するための受信装置のブロック図である。同図を参照しながら、緊急イベントに関する情報の第１の受信方法（以下、単に第１の受信方法と記載する。）について説明する。第１の受信方法においては、緊急イベントに関する情報を、コンテンツ配信装置７が配信するネットコンテンツの中にＭＴＥ(Media Timed Events)として記述する。ＭＴＥとは、ＭＰＥＧ―ＤＡＳＨ動画に含めることのできるトリガー信号である。ＭＴＥは、通常Ｗｅｂコンテンツの同期や情報提示等に用いられるものである。

【0516】

第１の受信方法においては、受信装置２が緊急イベント処理部２１６を更に備えることにより緊急イベントに関する情報を取得する。緊急イベント処理部２１６は、ネットコンテンツ取得部２１４とコンテンツ提示部２２２との間に備えられる。

【0517】

第１の受信方法においては、緊急イベントに関する情報は、ネット配信情報ＮＤＩに含まれる。すなわち、第１の受信方法において緊急イベントに関する情報は、ネットコンテンツ取得部２１４により取得される。したがって、ネットコンテンツ取得部２１４を、緊急イベント通知取得部ということもできる。緊急イベント通知取得部は、緊急イベントに関する情報が含まれる緊急イベント情報ＥＩを、通信ネットワークを介して取得する。緊急イベント情報ＥＩの一例としては、緊急警報信号を例示することができる。緊急イベント通知取得部により緊急イベント情報ＥＩを取得するステップ又は工程を、緊急イベント通知取得ステップ又は緊急イベント通知取得工程と記載する場合がある。

【0518】

緊急イベント処理部２１６は、ネットコンテンツ取得部２１４から緊急イベント情報ＥＩを取得した場合、取得した緊急イベント情報ＥＩに基づき、緊急イベントに関する情報をコンテンツ提示部２２２に提示する。緊急イベント処理部２１６により緊急イベントに関する情報をコンテンツ提示部２２２に提示するステップ又は工程を、緊急イベント処理ステップ又は緊急イベント処理工程と記載する場合がある。なお、緊急イベント処理部２１６は、コンテンツ提示部２２２が現在何らかのコンテンツを提示しているか否かに関わらず（すなわちコンテンツ提示部２２２の駆動状態に関わらず）、強制的に緊急イベントに関する情報を提示してもよい。換言すれば、緊急イベント処理部２１６は、コンテンツ提示部２２２に電源が供給されていない場合であっても、緊急イベント情報ＥＩに基づき強制的に電源を供給し、緊急イベントに関する情報を提示してもよい。この場合、ネットコンテンツ取得部２１４及び緊急イベント処理部２１６は、受信装置２に電源が供給されているか否かに関わらず常に待機状態とされていてもよい。また、緊急イベント処理部２１６は、コンテンツ提示部２２２が現在何らかのコンテンツを提示している場合、コンテンツの提示を停止し、緊急イベントに関する情報を提示してもよい。また、緊急イベント処理部２１６は、コンテンツ提示部２２２が現在何らかのコンテンツを提示している場合、提示しているコンテンツに重ねて、緊急イベントに関する情報を提示してもよい。

【0519】

なお、第１の受信方法によれば、コンテンツ配信装置７から配信されるネットコンテンツ（例えば映像ストリームの配信データ等の番組に関する情報）の中に緊急イベントに関する情報が記述されるため、情報提供システム６等に新たな機能を用意する必要がない点において利点があるということができる。

【0520】

図６１は、実施形態に係る緊急イベントに関する情報の第２の受信方法について説明するための情報提供システムのブロック図である。同図を参照しながら、緊急イベントに関する情報の第２の受信方法（以下、単に第２の受信方法と記載する。）について説明する。第２の受信方法においては、緊急イベントに関する情報を、メタ情報の中に記載する。第２の受信方法において緊急イベントに関する情報は、ＬＤＮ（Linked Data Notifications）等の手法を用いて情報提供システム６から受信装置２に送信されてもよい。より具体的には、緊急イベントに関する情報は、サービスリストＳＬ又はコンテンツリストＣＬ等の中に記述されていてもよい。

【0521】

第２の受信方法においては、情報提供システム６が緊急イベント情報提供部６３５を更に備えることにより緊急イベントに関する情報を受信装置２に出力する。緊急イベント情報提供部６３５は、情報提供システム６のうち、サービス情報提供サーバー装置６１、コンテンツ情報提供サーバー装置６２又はイベント情報提供サーバー装置６３のいずれかに備えられていてもよいが、図示する一例ではイベント情報提供サーバー装置６３に備えられる場合の一例について説明する。なお、緊急イベント情報提供部６３５は、サービス情報提供サーバー装置６１、コンテンツ情報提供サーバー装置６２及びイベント情報提供サーバー装置６３のうち複数に備えられていてもよい。

【0522】

緊急イベント情報提供部６３５は、緊急イベント情報ＥＩを所定の通信ネットワークＮＷを介して受信装置２に出力する。緊急イベント情報提供部６３５は、例えば放送送出装置８から送出される緊急イベント情報ＥＩを取得し、取得した緊急イベント情報ＥＩを所定のデータ形式に変換し、受信装置２に出力してもよい。緊急イベント情報ＥＩは、受信装置２のネット情報取得部２１１１により取得される。この場合、ネット情報取得部２１１１を、緊急イベント通知取得部ということもできる。緊急イベント通知取得部は、緊急イベントに関する情報が含まれる緊急イベント情報ＥＩを、通信ネットワークを介して取得する。第２の受信方法においても、受信装置２は緊急イベント処理部２１６を備える。第２の受信方法においては、ネット情報取得部２１１１とコンテンツ提示部２２２との間に緊急イベント処理部２１６が備えられる点において第１の受信方法とは異なる。緊急イベント処理部２１６は、ネット情報取得部２１１１から緊急イベント情報ＥＩを取得した場合、取得した緊急イベント情報ＥＩに基づき、緊急イベントに関する情報をコンテンツ提示部２２２に提示する。

【0523】

なお、第２の受信方法によれば、緊急イベントに関する情報は、情報提供システム６から配信されるメタデータ（例えばサービスリストＳＬ又はコンテンツリストＣＬ）の中に記述される。すなわち第２の受信方法によれば、緊急イベントに関する情報は、コンテンツ配信装置７から配信されるネットコンテンツとは異なる情報として配信される。したがって、第２の受信方法によれば、ネットコンテンツを配信するコンテンツプロバイダーＣＰによる運用を必要としない点に利点がある。

【0524】

また、受信装置２が受信方法取得部（不図示）を備えることにより、緊急イベントに関する情報の受信方法を選択する場合、第１の受信方法又は第２の受信方法のいずれを選択するかに応じて、ネットコンテンツ取得部２１４又はネット情報取得部２１１１のいずれかが緊急イベント通知取得部となり得る。この場合、受信方法の選択により特定された緊急イベント通知取得部は、受信方法取得部により取得された受信方法に応じて緊急イベント情報ＥＩを取得する。

【0525】

また、受信装置２が受信方法取得部（不図示）を備えることにより、緊急イベントに関する情報の受信方法を選択する場合、受信方法に応じて緊急イベントに関する情報を送信する装置が異なる。具体的には、第１の受信方法によればコンテンツ配信装置７が緊急イベントに関する情報を送信し、第２の受信方法によれば情報提供システム６が緊急イベントに関する情報を送信する。すなわち、受信方法の選択により特定された緊急イベント通知取得部は、受信方法に応じて異なる装置から配信される緊急イベント情報ＥＩを取得するということもできる。

【0526】

なお、受信装置２は、上述したような通信ネットワークを介して緊急イベントに関する情報を受信することに加えて、放送波のＥＷＳ関連情報を受信する。すなわち、受信装置２は、放送波のＥＷＳ関連情報（ＰＭＴの緊急情報記述子や、ＴＭＣＣの緊急警報放送起動フラグ）や、データ放送で配信されるバイナリテーブルオブジェクトやイベントメッセージを受信することができる。緊急イベント処理部２１６は、これらの取得した情報に基づき、緊急イベントに関する情報を表示させる。緊急イベント処理部２１６は、取得した緊急イベントに関する情報のうち内容が重なる情報について統合したり、又はイベントの発行時刻が遅いデータについて破棄したりしてもよい。

【0527】

また、緊急イベント処理部２１６は、通信ネットワークを介して取得したＥＷＳ関連情報に相当する情報と、通信ネットワークを介して取得するイベント情報との間でマッチングをとれるように、該当するパラメーターをあらかじめ定義してもよい。また、データ放送で配信されるバイナリテーブルオブジェクトやイベントメッセージについて、ａｒｉｂで規定されたリソース識別子を用いてマッチングできるように、通信ネットワークを介して取得するイベント情報に該当情報を付与してもよい。ａｒｉｂで規定されたリソース識別子とは、例えば以下のＵＲＩによるリソースの識別（名前空間）を例示することができる。

【0528】

Arib-dc://<orig_network_id>.<transport_stream_id>.<service_id>[.<event_id>]/<component_tag>/<moduleName>/<resourceName>

【0529】

また、受信装置２は、通信ネットワークを介して取得された緊急イベントに関する情報を、既存機能部２２に提供してもよい。他の実施例として、受信装置２は、放送から取得された情報と通信ネットワークを介して取得された情報とを処理した結果について、既存機能部２２に提供してもよい。

【0530】

次に、図６２を参照しながら、緊急イベントに関する情報の表示の具体例について説明する。

【0531】

図６２は、実施形態に係る緊急イベントの提示の一例について説明するための図である。図６２（Ａ）には、所定のコンテンツ（ネットコンテンツ又は放送コンテンツのいずれか）が表示された表示画面Ｄ１を示す。図６２（Ｂ）には、緊急イベント情報ＥＩが取得された後に提示される表示画面Ｄ２を示す。図６２（Ａ）に図示するように、表示画面Ｄ１にはニュースキャスターがニュースを読み上げる画面が表示されている。当該画面は、通常のテレビプログラムで予定された番組を示している。ここで、受信装置２が所定の方法で緊急イベント情報ＥＩを取得すると、緊急イベント処理部２１６は、番組のコンテンツの提示を停止し、緊急イベントＥＩに関する情報を提示する。緊急イベント処理部２１６は、番組のコンテンツの提示から緊急イベントＥＩに関する情報の提示へ、表示画面を切り替えるということもできる。図６２（Ｂ）に図示するように、表示画面Ｄ２には緊急イベント情報ＥＩを示すテキストＴが表示されている。テキストＴには、具体的には、“〇〇地方にて震度〇の地震が発生いたしました。”と表示されている。このようにテキストＴには、緊急イベントに関する情報が表示される。

【0532】

なお、上述した通り、緊急イベント情報ＥＩは、提示部がコンテンツを提示していない状態（図６２（Ａ）とは異なり表示画面がオフの状態）であっても、緊急イベント情報ＥＩを提示することができる。

【0533】

図６３は、実施形態に係るイベントリストの具体例を示す概略図である。同図を参照しながら、イベントリストの具体例について説明する。イベントリストとは、緊急イベント情報ＥＩの具体例である。ここで例示するイベントリストは、ＪＳＯＮ形式で記述されたデータである。ＪＳＯＮ形式は、入れ子型のブロック構造を有するテキストのデータである。図６３に示すデータの各行には、便宜的に行番号を付している。以下、イベントリストの例について順を追って説明する。

【0534】

第１行目は、イベントリストのブロックの始まりを示す。第３行目は、当該要素のタイプ（@type）が「ListItem」であることを表している。第４行目は、当該要素の名前（name）が「Event List」であることを表している。第５行目は、要素「itemListElement」（アイテムリストエレメント）の始まりを示す。この要素「itemListElement」は、第５行目から第５０行目まで続く。上記の要素「itemListElement」の内側には、複数の要素が存在し得る。図示する一例では、６行目から２７行目までにおける第１の要素と、２８行目から４９行目までにおける第２の要素とが含まれる。

【0535】

まず、６行目から２７行目までにおける第１の要素について説明する。第７行目は、コンテキスト（@context）を表す。第８行目は、タイプ（@type）が、「SpecialAnnouncement」（スペシャルアナウンスメント）であることを表す。第９行目から第１４行目までは、属性「identifier」（アイデンティファイアー、識別情報）である。「identifier」における要素には、「PropertyValue」型の要素が含まれる。当該要素の「PropertyID」は「emergencyId」であり、その属性値は「1」である。第１５行目は、「dateModified」であり、データの変更日時の情報を表す。第１６行目は、「dateCreated」であり、データが作成された日時の情報を表す。第１７行目は、「datePosted」であり、データがポストされた日時の情報を表す。図示する一例では、データの変更日時、データが作成された日時及びデータがポストされた日時は、「2022-09-01T13:13:10」であり、同一である。第１８行目は、「category」であり、カテゴリーについての情報を示す。第１９行目は、「name」であり、イベントの名前を表す。図示する一例では、「緊急地震速報」であることを表している。第２０行目は、イベントに含まれるテキストを表している。図示する一例では、「緊急地震速報」として、「緊急地震速報 およそ__秒後に震度__程度の地震がきます」のテキストが含まれている。第２１行目から第２６行目までは、属性「spatialCoverage」（スペシャルカバレッジ）である。第２３行目は、タイプ（@type）が、「AdministrativeArea」であることを表す。２４行目は、名前（name）が「Tokyo」であることを表す。

【0536】

次に、２８行目から４９行目までにおける第２の要素について説明する。第２の要素の説明において、第１の要素と重複する部分については説明を省略する。２９行目から３１行目までは、７行目から９行目までと同様である。３３行目から３５行目までは、１１行目から１３行目までと略同様である。第２の要素については、属性値が「２」であるてんにおいて第１の要素とは異なる。３７行目から４２行目までは、１５行目から２０行目と略同様である。第２の構成要素においては、データの変更日時、データが作成された日時及びデータがポストされた日時が、いずれも「2022-09-01T13:30:20」である点において、第１の構成要素と異なる。すなわち、第１の構成要素と第２の構成要素とは、異なるタイミングにおける、同一内容の情報である。第４３行目から第４８行目までは、第２１行目から第２６行目までと同様である。

【0537】

以上説明した実施形態によれば、受信装置２は、緊急イベント通知取得部（ネットコンテンツ取得部２１４又はネット情報取得部２１１１のいずれか）を備えることにより、緊急イベントに関する情報が含まれる緊急イベント情報ＥＩを、通信ネットワークＮＷを介して取得する。また、受信装置２は、緊急イベント処理部２１６を備えることにより、取得した緊急イベント情報ＥＩに基づき、緊急イベントに関する情報をコンテンツ提示部２２２に提示する。すなわち、受信装置２によれば、放送信号を受信することができない場合であっても、通信ネットワークＮＷを介して緊急イベント情報ＥＩを取得し、取得した緊急イベント情報ＥＩに基づいて緊急イベントに関する情報を提示することができるため、緊急イベントに関する情報を好適に受信し、ユーザーＵに提示することができる。

【0538】

また、以上説明した実施形態によれば、受信装置２は、受信方法取得部を更に備えることにより、緊急イベントに関する情報の受信方法に関する情報を取得する。また、緊急イベント通知取得部（ネットコンテンツ取得部２１４又はネット情報取得部２１１１のいずれか）は、取得した受信方法に応じて緊急イベント情報を取得する。すなわち、本実施形態によれば、緊急イベントに関する情報の受信方法が複数存在する。したがって、本実施形態によれば、受信装置２は、複数の受信方法の中から選択された好適な受信方法により緊急イベントに関する情報を受信することができる。

【0539】

また、以上説明した実施形態によれば、緊急イベント通知取得部は、取得した受信方法に応じて異なる装置から配信される緊急イベント情報を取得する。換言すれば、緊急イベントに関する情報の受信方法に応じて、緊急イベントに関する情報を配信する装置が異なる。したがって、本実施形態によれば、受信装置２は、好適な装置から配信された緊急イベントに関する情報を受信することができる。

【0540】

また、以上説明した実施形態の第１の受信方法によれば、緊急イベント情報ＥＩは、通信ネットワークＮＷを介して取得されるコンテンツを含む情報（すなわちコンテンツ情報）に含まれる。したがって、本実施形態によれば、情報提供システム６は緊急イベントに関する情報の送信を行わなくてもよい。したがって、本実施形態によれば、容易に緊急イベントに関する情報を送信することができる。

【0541】

また、以上説明した実施形態の第２の受信方法によれば、緊急イベント情報ＥＩは、通信ネットワークＮＷを介して取得される情報であって、コンテンツを含む情報とは異なる情報（すなわちコンテンツ情報以外の情報）に含まれる。具体的には、緊急イベント情報ＥＩは、メタ情報に含まれていてもよい。したがって、本実施形態によれば、ネットコンテンツの配信を通常通り行い、ネットコンテンツとは異なる情報として緊急イベントに関する情報を送信することができる。

【0542】

また、以上説明した実施形態によれば、受信装置２の受信方法取得部は、第１の受信方法又は第２の受信方法のいずれであるかを示す情報を取得する。第１の受信方法において、緊急イベント情報ＥＩは、通信ネットワークＮＷを介して取得される番組に関する情報（例えばネットコンテンツ）に含まれる。第２の受信方法において、緊急イベント情報ＥＩは、通信ネットワークＮＷを介して取得される情報であって、番組に関する情報とは異なる情報（例えばメタ情報）に含まれる。したがって、本実施形態によれば、緊急イベント情報ＥＩをネットコンテンツに含むのか、メタ情報に含むのかを選択することができる。よって、本実施形態によれば、受信装置２は、緊急イベント情報ＥＩを好適な態様で受信することができる。

【0543】

また、以上説明した実施形態によれば、緊急イベント処理部２１６は、緊急イベント情報ＥＩを取得した場合、番組のコンテンツの提示を停止し、緊急イベントに関する情報を提示する。すなわち、緊急イベント処理部２１６は、番組のコンテンツの提示に代えて、緊急イベントに関する情報を提示する。したがって、本実施形態によれば、緊急性の高いイベントを、確実にユーザーＵに対して提示することができる。

【0544】

図６４は、コンピューターを用いて実施形態における各装置を実現する場合の内部構成の一例を示すブロック図である。本実施形態に係る各装置（受信装置２、情報登録装置５、情報提供システム６、コンテンツ配信装置７及び放送送出装置８のそれぞれ）は、コンピューターを用いて実現され得る。図示するように、そのコンピューターは、中央処理装置９０１と、ＲＡＭ９０２と、入出力ポート９０３と、入出力デバイス９０４や９０５等と、バス９０６と、を含んで構成される。コンピューター自体は、既存技術を用いて実現可能である。中央処理装置９０１は、ＲＡＭ９０２等から読み込んだプログラムに含まれる命令を実行する。中央処理装置９０１は、各命令にしたがって、ＲＡＭ９０２にデータを書き込んだり、ＲＡＭ９０２からデータを読み出したり、算術演算や論理演算を行ったりする。ＲＡＭ９０２は、データやプログラムを記憶する。ＲＡＭ９０２に含まれる各要素は、アドレスを持ち、アドレスを用いてアクセスされ得るものである。なお、ＲＡＭは、「ランダムアクセスメモリー」の略である。入出力ポート９０３は、中央処理装置９０１が外部の入出力デバイス等とデータのやり取りを行うためのポートである。入出力デバイス９０４や９０５は、入出力デバイスである。入出力デバイス９０４や９０５は、入出力ポート９０３を介して中央処理装置９０１との間でデータをやりとりする。バス９０６は、コンピューター内部で使用される共通の通信路である。例えば、中央処理装置９０１は、バス９０６を介してＲＡＭ９０２のデータを読んだり書いたりする。また、例えば、中央処理装置９０１は、バス９０６を介して入出力ポートにアクセスする。

【0545】

［実施形態のまとめ］
以上説明した実施形態によれば、情報提供システム６は、コンテンツ情報登録受付部６２１を備えることにより、コンテンツリストＣＬを取得する。コンテンツリストＣＬは、コンテンツを識別する情報と当該コンテンツの属性に関する情報とを含む複数の情報を互いに分離可能な構成要素として有する。また、コンテンツ情報提供サーバー装置６２は、コンテンツ情報データベース６２２を備えることにより、取得されたコンテンツリストＣＬを記憶する、また、情報提供システム６は、差分判定部６３３を備えることにより、コンテンツ情報登録受付部６２１によりコンテンツリストＣＬが取得された場合に、取得されたコンテンツリストＣＬの全部又は一部と、コンテンツ情報データベース６２２に記憶されたコンテンツリストＣＬの全部又は一部とを比較し、差分を有する構成要素の有無を判定する。また、情報提供システム６は、更新通知部６３４を備えることにより更新通知ＵＮを受信装置２に対して提供する。更新通知ＵＮには、差分を有する構成要素を特定する情報が含まれる。また、情報提供システム６は、コンテンツ情報更新要求取得部６２４を備えることにより、更新要求を取得する。更新要求とは、情報提供システム６により提供された更新通知ＵＮに基づき出力された要求であって、コンテンツリストＣＬのうち更新を要求する構成要素を特定する情報を含む要求である。また、情報提供システム６は、コンテンツ情報提供部６２３を備えることにより、取得された更新要求に基づきコンテンツ情報データベース６２２に記憶されたコンテンツリストＣＬのうち特定された構成要素を少なくとも含む情報を提供する。本実施形態によれば、情報提供システム６は、コンテンツリストＣＬのうち更新があった部分を特定する情報を受信装置２に提供し、受信装置２は、当該部分についての更新を要求する。すなわち、本実施形態によれば、コンテンツリストＣＬのうち更新があった部分を含む構成要素のみを更新することができる。よって、情報提供システム６によれば、受信装置２に記憶されるコンテンツに関する情報を好適に更新することができる。

【0546】

また、以上説明した実施形態によれば、コンテンツリストＣＬの構成要素は、階層構造を有する。したがって、本実施形態によれば、階層ごとに区別された構成要素のそれぞれを、必要に応じて更新することができる。

【0547】

また、以上説明した実施形態によれば、コンテンツリストＣＬの構成要素には、コンテンツの配信方法に関する情報が少なくとも含まれる。コンテンツの配信方法に関する情報は、例えばａｓｓｏｃｉａｔｅｄＭｅｄｉａに含まれる。更に、コンテンツの配信方法に関する情報の下位階層としては、物理的なコンテンツの配信方法に関する情報が少なくとも含まれる。物理的なコンテンツの配信方法に関する情報は、例えばｐｕｂｌｉｃａｔｉｏｎに含まれる。したがって、情報提供システム６によれば、コンテンツリストＣＬにより特定されるコンテンツを、コンテンツリストＣＬにより特定された配信方法を用いて取得することができる。

【0548】

また、以上説明した実施形態によれば、受信装置２は、ネット情報取得部２１１１を備えることにより、情報提供システム６から提供された更新通知ＵＮを取得する。更新通知ＵＮには、コンテンツリストＣＬのうち、特定の構成要素を特定する情報が含まれる。また、受信装置２は、ネット情報要求部２１１２を備えることにより、取得した更新通知ＵＮに基づき、特定された構成要素を含む情報の提供を要求する。したがって、受信装置２は、コンテンツリストＣＬの更新があった場合に、更新後のコンテンツリストＣＬの提供を情報提供システム６に対してすることができる。また、更新通知ＵＮには更新が行われた場所が特定されているため、受信装置２は、更新があった部分についてコンテンツリストＣＬの提供を要求することができる。よって、受信装置２によれば、コンテンツに関する情報を好適に更新することができる。

【0549】

また、以上説明した実施形態によれば、受信装置２は、事前情報設定部２１５を備えることにより、ユーザーＵの操作に基づき事前情報が設定される。また、受信装置２のネット情報要求部２１１２は、事前情報設定部２１５により設定された事前情報に基づき、取得した更新通知ＵＮにより特定される構成要素の更新をするか否かの判定を行い、更新をすると判定した場合に、更新通知ＵＮにより特定される構成要素を含む情報の提供を要求する。したがって、受信装置２は、コンテンツリストＣＬの新規登録又は更新が行われた場合、更新の要否を判定し、判定した結果に基づいて更新を行うことができる。したがって、受信装置２によれば、不要な更新を抑止し、ネット通信量を少なくすることができる。

【0550】

なお、上述した実施形態におけるシステム１が備える各部の機能全体あるいはその一部は、これらの機能を実現するためのプログラムをコンピューター読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現しても良い。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。

【0551】

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

【0552】

また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示に係る技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者には明らかな他の効果を奏しうる。また、本発明はこうした実施形態に何ら限定されるものではなく、本発明の趣旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。

【産業上の利用可能性】

【0553】

本発明は、例えば、コンテンツを配信するためのシステムに利用することができる。但し、本発明の利用範囲はここに例示したものには限られない。

【符号の説明】

【0554】

１ システム
２ 受信装置
３ サービス情報提供サーバー装置
４ サービス配信サーバー装置
５ 放送送出装置
７ コンテンツ提供装置
８ インターネット
２０１ ユーザー制御入力部
２０２ 放送メディア利用可否情報取得部
２０３ 選局可能チャンネル情報取得部（放送サービス情報取得部）
２０４ 放送受信可否判定部
２０５ 選局可能チャンネル情報記憶部（放送サービス情報記憶部）
２０６ 地域推定部
２１１ 通信可否判定部
２１２ サービスリスト取得条件決定部（取得条件決定部）
２１３ サービスリスト所在情報管理部
２１４ サービスリスト取得部（ネット配信サービス情報取得部）
２１５ サービスリスト記憶部（ネット配信サービス情報記憶部）
２２１ 情報統合部（統合部）
２３１ コンテンツ受信部
２３２ 提示部
３０１ サービスリスト取得部
３０２ サービスリスト提供部
９０１ 中央処理装置
９０２ ＲＡＭ
９０３ 入出力ポート
９０４，９０５ 入出力デバイス
９０６ バス
１ システム
２ 受信装置
５ 情報登録装置
６ 情報提供システム
７ コンテンツ配信装置
８ 放送送出装置
２１ 統合機能部
２２ 既存機能部
２１１ 情報取得部
２１２ 情報統合部
２１３ 提示方法決定部
２１４ ネットコンテンツ取得部
２１５ 事前情報設定部
２１１１ ネット情報取得部
２１１２ ネット情報要求部
２１１３ 放送情報取得部
２２１ 操作取得部
２２２ コンテンツ提示部
２２３ 放送コンテンツ取得部
５１ サービス情報登録部
５２ コンテンツ情報登録部
６１ サービス情報提供サーバー装置
６２ コンテンツ情報提供サーバー装置
６３ イベント情報提供サーバー装置
６１１ サービス情報登録受付部
６１２ サービス情報データベース
６１３ サービス情報提供部
６１４ サービス情報更新要求取得部
６２１ コンテンツ情報登録受付部
６２２ コンテンツ情報データベース
６２３ コンテンツ情報提供部
６２４ コンテンツ情報更新要求取得部
６３１ 更新情報取得部
６３２ 記憶情報取得部
６３３ 差分判定部
６３４ 更新通知部

【図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】

【図31】

【図32】

【図33】

【図34】

【図35】

【図36】

【図37】

【図38】

【図39】

【図40】

【図41】

【図42】

【図43】

【図44】

【図45】

【図46】

【図47】

【図48】

【図49】

【図50】

【図51】

【図52】

【図53】

【図54】

【図55】

【図56】

【図57】

【図58】

【図59】

【図60】

【図61】

【図62】

【図63】

【図64】