JP4271211B2 - 放送番組のメタデータを提供する装置及びプログラム - Google Patents

Description

本発明は、ネットワークを通じて放送番組情報のメタデータを提供する装置及びプログラムに関する。

各テレビ局では新番組やスペシャル番組の視聴を促すために、頻繁に番組宣伝の広告（ＣＭ）を放送している。その放送自体の視聴率は既存の調査システムで測定できるが、実際の視聴に繋がった効果については測定ができない。だからといって、アンケートのような手法によって都度、広告効果を測定するのは非常に高いコストがかかる。そこで、番組予告情報を本放送のメタデータとして表現し、インターネットや放送波などを使って配信し、放送受信装置と配信サーバの間で活用するといった新しいサービスの実現が今後盛んになると考えられている。

近年、ますます高度で多様化しているサービス利用者からのニーズを満たすためには、前述のような番組情報等に関するメタデータをうまく利用した利便性の高いサービス機能を実現することが望まれている。このためには、質の高いメタデータを制作するべきであるが、当然、それに応じて時間的、費用的なコストが高くなる。しかし、メタデータ提供サービスの現状としては、「メタデータは当然に無償で提供されるもの」という考え方が支配的であり、その提供コストの回収が考慮されているようなシステムは存在しない。

メタデータ提供関連の技術については、視聴中の番組に対するユーザからの操作を検知し、これを契機にＥＰＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｐｒｏｇｒａｍ Ｇｕｉｄｅ）を配信するサーバとは別のサーバ（番組情報ＤＢ）から関連情報（メタデータ）を取得する技術が例えば下記特許文献１に記載されている。番組情報ＤＢは、番組内の任意の部分に関連する情報として、番組に関連する情報コンテンツ本体を蓄積する他、インターネットなど所定の情報空間上で関連情報を探索するためのＵＲＬやＵＲＩなどのリファレンス、資源識別情報、キーワードなどが蓄積されている。

視聴情報を外部に送信する機能を備えたＴＶ受信装置も知られている（例えば下記特許文献２参照）。この装置では、視聴情報のみならず番組録画予約の際の操作情報をも送信できることから、録画予約率などを外部から分析することができる。同文献には、分析データを定期的にサーバに対して送信することが記載されている。
特開２００５−１７５８５０号公報 特開２００５−１５１１４８号公報

放送受信装置におけるＥＰＧを利用した番組録画予約機能等の進化に伴い、番組情報に関するメタデータをより迅速に提供するサービスの実現が望まれている。例えば、放送における番組宣伝（いわゆる「番宣」）番組の視聴時に、宣伝対象である本放送番組のＥＰＧ情報がまだ配信されていない早期の段階においてユーザがクリック操作１つで本放送番組を録画予約できる機能はこれまで実現されていないが、メタデータ・サーバによる迅速なサービス応答により、かかる機能を実現可能となる。

したがって、本発明は、放送番組のメタデータ要求に迅速に応答し、該要求に対して非同期的にメタデータを提供することのできる装置及びプログラムを提供することを目的とする。

本発明の一観点に係るメタデータ提供装置は、宣伝対象の番組の放送予定を表すメタデータを要求する第１のリクエストを受信する第１の受信部と、前記第１のリクエストに対してリクエストＩＤを発行する発行部と、前記第１のリクエストと前記リクエストＩＤとを関連付けて記憶する第１の記憶部と、前記第１のリクエストに対し、前記リクエストＩＤを含むリクエスト応答を送信する第１の送信部と、メタデータを記憶する第２の記憶部と、前記リクエストＩＤを含み、該リクエストＩＤに対応するメタデータの取得を要求する第２のリクエストを受信する第２の受信部と、前記第２のリクエストに含まれるリクエストＩＤに該当するメタデータを前記第２の記憶部から検索し、該第２のリクエストに対して該メタデータを送信する第２の送信部と、を具備する。

本発明によれば、放送番組のメタデータ要求に迅速に応答し、該要求に対して非同期的にメタデータを提供することのできる装置及びプログラムを提供できる。

（第１の実施形態）
図１に示すように、メタデータ提供システムは、インターネットのようなネットワーク３００に接続された複数の放送受信装置１００に対し、メタデータ・サーバ２００が同ネットワーク３００を介してメタデータを提供するというものである。

（放送受信装置１００）
図２に示すように、放送受信装置１００は、各部の制御と演算を行うＣＰＵ１０１と、プログラムやデータの一時記憶のためのＲＡＭ１０３と、プログラム記憶のためのＲＯＭ１０５と、現在時刻取得のための内部時計１０７と、インターネットのような外部のネットワーク３００と通信するための通信デバイス１０９と、リモコンや本体ボタンからの利用者入力を受け付けるためのアクション受付部１１５と、受信した放送の表示や各種利用者向け情報を表示する画面表示処理部１１７と、アンテナ、ＣＡＴＶ、ＩＰネットワークなどからのアナログ放送波やデジタル放送波を受信するチューナ１１９とを備える。

放送受信装置１００は、チューナ１１９により受信した情報をテレビ等への出力のための表示処理する基本的なＴＶ受信機能に加え、放送予定番組をＥＰＧにより予約録画する機能や、録画した番組を再生する機能、ＤＶＤ等の外部メディアを再生する機能等を備える。このため、放送受信装置１００はＨＤＤ（ハードディスク装置）１１１、外部メディアリーダ１１３、ＥＰＧ処理部１２１、録画再生処理部１２７を備える。

さらに放送受信装置１００は、視聴中の番組のあるシーンに対する利用者からのアクションを受け付け、その利用者アクションの情報をメタデータ要求としてインターネット３００を通じてメタデータ提供サーバ２００に送信し、メタデータを受信する機能と、受け取ったメタデータを解釈して利用する機能とを備える。例えば、上記アクションは、番組宣伝番組を視聴中の利用者が、その宣伝対象の番組の予約録画を指示する操作入力である（後述する「予告録画」）。これに応じてメタデータ提供サーバ２００から受け取るメタデータは、番組宣伝番組の終了後に提供される当該番組をＥＰＧ処理部１２１において予約処理するために用いられるＥＰＧ情報（例えばＥＰＧ識別子）である。ＥＰＧ録画機能を備えない構成例の場合には、メタデータ提供サーバ２００から受け取るメタデータは、別の予約録画処理部において当該番組の予約録画処理に用いられる情報であり、例えば予約対象のチャネル及び録画日時、録画時間を表す情報である。

（メタデータ・サーバ２００）
図３に示すように、メタデータ・サーバ２００は、各部の制御と演算を行うＣＰＵ２０１と、プログラムやデータの一時記憶のためのＲＡＭ２０３と、プログラム記憶のためのＲＯＭ２０５と、現在時刻取得のための内部時計２０７と、外部ネットワークと通信するための通信デバイス２１１と、各種データベースやアプリケーション・プログラムの記憶のためのＨＤＤ２０９と、を備える。

図４に示すように、メタデータ・サーバ２００上に配置されるアプリケーション・ソフトウェアは、番組放送枠に対するメタデータの提供状況を記憶しているメタデータ提供状況ＤＢ５１３と、放送受信装置１００からのメタデータ・リクエストを受信する処理を行うメタデータ・リクエスト受付部５０１と、受け付けたメタデータ・リクエストを記憶するメタデータ・リクエストＤＢ５０７と、メタデータ・リクエストのリクエストＩＤ発行を受けた放送受信装置１００からのメタデータ取得要求を受信し、実際のメタデータの提供を行うメタデータ提供部５０３と、提供すべきメタデータを記憶するメタデータＤＢ５０９と、これら一連の処理内容を処理時刻とともに記録するログ記録部５０とを有する。

以下、第１の実施形態における放送受信装置１００と、メタデータ要求を受け付けるメタデータ・サーバ２００との間で送受される情報について説明する。

（メタデータＤＢとメタデータ提供状況ＤＢ）
図５に示すように、番組編成表はチャンネル毎に、時間軸に沿って構成される。ライブ放送の場合は放送後にしか番組編成は確定しないが、ライブ放送でなければ放送前に番組編成を確定させることもできる。図５の番組編成表では、１６：０５：００〜１６：１２：００の間に「注目ドラマ」という番組宣伝コーナーがあったことがわかるが、この番組宣伝に対して、図６に示すようなメタデータＤＢ５０９中のレコード（ここでは、メタデータIDがID_XXX01であるレコード）と、図７に示すようなメタデータ提供ＤＢにおいて記憶される、前述のメタデータと番組放送枠との関係情報（ここでは、提供状況IDがID_YYY020であるレコード）と、を記憶することによって、番組編成表中の特定の放送枠に対するメタデータを特定できる。

メタデータＤＢ５０９で保持されるデータを「番組編成情報のメタデータ」と呼ぶことにする。例えば、メタデータが番組編成情報に対する被番宣番組情報の場合、メタデータＤＢ５０９の各レコードは、メタデータＩＤ、被番宣番組チャンネル情報、被番宣番組開始日時、被番宣番組終了日時を必須カラムとした構成とする。番組編成情報とメタデータの対応関係は、メタデータ提供状況ＤＢ５１３で保持される。

このようなメタデータがメタデータ作成業者から提供され、メタデータ・サーバ２００のメタデータＤＢ５０９に蓄積される。

メタデータの提供状況は、図７のような番組宣伝放送枠に対するメタデータの提供有無の情報をまとめたメタデータ提供状況ＤＢ５１３に記憶される。このメタデータ提供状況ＤＢ５１３は、メタデータが提供されることが確定した時間帯と、メタデータが提供されないことが確定された時間帯の二種類の情報が登録される。具体的には、番組宣伝番組の各シーンに対してメタデータを生成する際に、単純にメタデータとシーンとの関連づけをするだけでなく、メタデータとの関連づけのないシーンを確定させることで、番組宣伝の編成全体を通して、メタデータがあるかないかを明確にするような方法でメタデータを作成することで実現できる。

なお、図７に示すメタデータ提供状況ＤＢ５１３には、まだメタデータが提供の可否が確定していない時間帯は記憶されない。そのような時間帯に対しては、メタデータ提供部５０３において、あらかじめ提供期間のポリシーを定めておき、例えば「３日後に提供する予定」といった情報を放送受信装置１００に返す。

（通常視聴状態）
画面表示処理部１１７は、リモコンや本体スイッチなどからの利用者の操作をアクション受付部１１５で受付け、その操作を処理するＣＰＵ１０１の制御によりチューナ１１９の受信画像を表示する。ここで、チューナ１１９は特にＴＶ放送に限定するものではなく、ラジオ放送やデータ放送などの放送波経由の放送であったり、インターネット・ストリーミングなどのネットワーク経由の放送であったりする。ここではＴＶ放送を例にあげて説明する。

（ユーザアクションの受付と応答）
チャンネル切り替えや音量変更などの通常のＴＶ操作に加え、利用者はＴＶ視聴中の予告シーン視聴の際に、リモコンに専用に用意された「予告録画」ボタンを押すことで、その予告先番組の録画予約を希望する旨の指示を、アクション受付部１１５を介して放送受信装置１００に指示することができる。この指示により、放送受信装置１００は、アクション操作時の日時を内部時計１０７より取得し、視聴中のチャンネル情報をチューナ１１９より取得し、メタデータ・リクエストの構成要素として記憶する。

アクションの種類としては、予告先番組の録画予約実行の他に、予告先番組を録画予約候補としてブックマーク、録画機能を持たない放送受信装置１００での予告先番組の視聴予約、全チャンネル録画機能を持つ放送受信装置１００における予告先番組の視聴候補ブックマークや予告先番組の視聴拒否ブックマーク、などの視聴中のシーンと将来放送される番組との間の関連づけに関するものがあり得る。

もちろん、ここでいう予告先番組はＥＰＧなどで管理される単位であるところの「番組」のみならず、１つの番組の中の１つの「コーナー」や「シーン」であっても良い。さらに、視聴中の番組やシーンについての更に詳細な解説情報の希望など、ＴＶ画面に表示可能な情報であれば、応用可能であることは言うまでもない。リモコンボタンの構成は、これらコーナーやシーンのそれぞれに専用のボタンを設けても良いし、ボタンは１つにして画面でのダイアログ表示でアクション種別を問うようにしてもよい。

また、予告シーンの種類としては、シリーズ番組の終了間際の次回予告だけではなく、番組宣伝自体をコンテンツとする番組中のワンシーンや、番組の視聴率や主題歌のランキングをコンテンツとする番組での引用シーンや紹介シーンなどがある。

ターゲットとなるメタデータの種類は、アクションの種類によって大枠が決まるが、例えば、ユーザアクションが「今のシーンに関係のある番組すべて」といった抽象的な指示であっても良く、その場合、メタデータ・サーバ２００側でその抽象的な指示に従った形でのメタデータ検索を行う。また、番組宣伝番組において他の番組の予告シーンが放映されている際に、放送受信装置１００よりアクションとして「次回放送のメタデータ」という指示を出した場合、メタデータ・サーバ２００は該当するシーンの予告先番組ではなく、該当するシーンの含まれる番組宣伝番組の次回放送のメタデータの検索を試みる。このようにしてユーザアクションの種別をメタデータ・サーバ２００はうまく利用する。

ユーザアクションの受付に際し、本体ＬＥＤや視聴画面中にアクションを受け付けた旨のメッセージや、アクション処理の可否を問うメッセージを表示することで、ユーザの操作性や視認性を高めるなどの工夫をしてもよい。

また、メタデータ・リクエスト処理とメタデータ取得処理の間のタイムラグを考慮して、いったんユーザの希望を受け取った旨を画面に表示し、事後にＬＥＤや視聴画面中に処理の結果を通知する方法や、ユーザアクション履歴のリストを管理しユーザ操作によりいつでも閲覧可能にしておくなどの機能を放送受信装置１００側に持たせることが望ましい。また、以上で述べた一連のユーザアクションの処理を、適当な自動処理プログラムの判断により代行させることも可能である。

（メタデータ・リクエスト登録）
図９に沿って、放送受信装置１００からのメタデータ・リクエストをメタデータ・サーバ２００において受け付ける手順を説明する。

アクション受付部１１５の処理の後、ＣＰＵ１０１の制御により、通信デバイス１０９を用いて、インターネット経由で、メタデータ・サーバ２００と通信を行う。メタデータ・サーバ２００とのメタデータ・リクエスト送受信に用いるメッセージ転送プロトコルは、あらかじめ決められたものを用いる。例えば、ＨＴＴＰやＳＭＴＰなどがある。

放送受信装置１００は、アクション受付部１１５で記憶したアクション操作時の放送受信装置１００の日時と視聴チャンネルとの組み合わせ（検索キーに相当する）を含むメタデータ・リクエストを生成し、メタデータ・サーバ２００に送信する。

図１０に示すメタデータ・リクエストにおける日時の表記は、放送受信装置１００とメタデータ・サーバ２００の地理的な違いがある場合を考慮して、タイムゾーン付きで表現することが望ましい。形式としては、例えば、ＩＳＯ８６０１で定められるものなどが考えられる。

メタデータ・リクエストにおける視聴チャンネル８０の表記については、各ローカル局での編成の違いを考慮するため、郵便番号や市外局番と受信チャンネルコードとを組み合わせたもの、あるいはＤＥＰＧコードのような地域識別可能な統一コードなどの中から、放送受信装置１００側とサーバ側の間であらかじめ形式を定めたものを利用して表現する。

アクション操作時の日時情報８１については、アクション操作時点からメタデータ・リクエスト送出までの「処理遅延」を計測し、その時間をメタデータ・サーバ２００に伝え、メタデータ・サーバ２００側で「受信時刻」から「処理遅延」を減じた時刻を以てアクション操作時の日時とする。さらに、処理遅延が無視できる程度であれば、単純にメタデータ・サーバ２００側での「受信時刻」を以てアクション操作日時とすることもできる。この方式では放送受信装置１００の現在時刻は必ずしも正確でなくてもよい。

もちろん、放送受信装置１００の内部時計１０７の時刻が、あらかじめＮＴＰや時報サービスなどを用いて正しい時刻にあわせることが可能な場合は、放送受信装置１００の内部時計から得られた操作時の日時情報を用いることも可能である。いずれにせよ、あらかじめメタデータ・サーバ２００側で決めた形式でやりとりする。

次に、メタデータ・サーバ２００は、メタデータ・リクエストを受け取ると、まずメタデータ・リクエストの正規性をチェックする。ここでいう「正規性」とは、メタデータ・リクエストの表記フォーマットや、値の範囲などのことを言う。メタデータ・リクエストが正規性を満たさない場合は、メタデータ・サーバ２００はリクエストの正規性に問題がある旨のエラーメッセージを放送受信装置１００に送信し、接続を完了する。

メタデータ・リクエストが正規性を満たす場合は、メタデータ・リクエスト毎にユニークなリクエストＩＤを発行する。このＩＤの形式は、例えば、ＳＭＴＰのＭｅｓｓａｇｅ−ＩＤや、現在時刻＋放送受信装置１００の識別番号などが考えられる。

次に、メタデータ・サーバ２００はこのリクエストＩＤとともにメタデータ・リクエストをメタデータ・リクエストＤＢ５０７に記憶する。放送受信装置１００から送られたメタデータ・リクエストは、例えば図１１のようなテーブルに保存される。

メタデータ・サーバ２００は一連のメタデータ・リクエスト受付処理を終えると、図１２に示すようなメタデータ・リクエスト・レスポンスを生成し、放送受信装置１００に送信する。

メタデータ・リクエスト・レスポンスには、メタデータ・リクエストの正否を表す結果コード「<RequestReult>」１２０と、前述のメタデータ・サーバ２００内で生成されたメタデータ・リクエストＩＤ「<RequestID>」１２１が含まれる。

また、メタデータの提供期間「<MetadataAvailableTimeRange>」１２２については、メタデータ提供状況ＤＢ５１３内の情報に従って返答する。例えば、提供されるメタデータがすでに準備されている場合は、提供期間を「ＮＯＷ」などとして、即時メタデータの取得が可能であることを示す。なお、ここでいうメタデータの提供期間が後日変更になり、当該期間内においてメタデータが提供されない場合があってもよい。この場合、メタデータ取得時にメタデータが得られないことがあり得るが、その処理手順については後述する。

また、メタデータ提供状況ＤＢ５１３からメタデータ提供期間がわからない場合は、例えば、メタデータ・サーバ２００側であらかじめデフォルト値として「３日後から１週間」などの値を決めておき、それに基づき機械的に返す。

この間メタデータ・サーバ２００において何らかの処理のエラーがあった場合は、そのエラーの内容を示すメッセージを放送受信装置１００に送信し、接続を完了する。

放送受信装置１００はメタデータ・リクエスト・レスポンスを受け取ると、その正規性をチェックし、問題なければ図示しない不揮発記憶装置に記憶する。

上記一連の処理が完了すると、放送受信装置１００及びメタデータ・サーバ２００はあらかじめ決められた手順に従って接続を完了する。

放送受信装置１００は、記憶しているメタデータ・リクエスト・レスポンスにおいて指定されているメタデータ提供期間と現在時刻とを比較し、その差に応じたメッセージで利用者にリクエスト結果を伝えておくことが望ましい。例えば、このメッセージは、すぐにメタデータ取得が可能な場合は「メタデータの取得を始めます」であったり、１週間後にメタデータの取得が可能となる場合は「リクエストを記憶します」「１週間後にリクエストが確定します」であったりする。

（メタデータ取得）
図１３に放送受信装置１００がメタデータ・サーバ２００からメタデータを受け取る手順を示す。

放送受信装置１００は、既に得たメタデータ・リクエスト・レスポンスにおいて指定されている情報に基づき、メタデータ提供期間をねらって、メタデータの取得を試みる。

メタデータ提供期間内のいつメタデータを取得を実行するかについては、負荷分散の観点では、メタデータ・サーバ２００側であらかじめ返答すべき提供期間にばらつきを持たせることが望ましく、そのようにすれば放送受信装置１００は提供開始時間が到来した以後、すみやかにメタデータの取得を試みることができる。

メタデータの取得に際し、まず、メタデータ・リクエスト・レスポンスで指示されたメタデータ・サーバ２００のＵＲＩに対して、あらかじめ決められた手順にしたがって、接続を開始する。放送受信装置１００は、メタデータ・サーバ２００に対して、リクエストＩＤに対応するメタデータの提供を依頼する旨のメッセージを送信する。

メタデータ・サーバ２００は、図１４に示すようなメタデータ提供希望メッセージを受信すると、その正規性をチェックする。メタデータ提供希望メッセージの正規性が確認できたら、メッセージに含まれるリクエストＩＤ１４０を検索キーとして用いてメタデータＤＢ５０９の検索を行う。該当するメタデータがヒットした場合は、メタデータ・サーバ２００は、検索に成功した旨を表すコードと、そのメタデータを、放送受信装置１００に返答する。

放送受信装置１００は、メタデータ・サーバ２００から図１５に示すような返答メッセージを受け取ると、その正規性をチェックする。正規性が確認できた場合、放送受信装置１００はそのメッセージに含まれるメタデータ１５０を記憶する。この一連の処理が完了すると、放送受信装置１００とメタデータ・サーバ２００は接続を完了する。

メタデータＤＢ５０９の検索に失敗した場合に返答されるメッセージの例を図１６に示す。

該当するメタデータがヒットしなかった場合で、かつメタデータ提供状況ＤＢ５１３から、例えば、後日再取得可能となる、あるいは、違うメタデータ・サーバにアクセスすれば可能になる、など他の方法を用いればメタデータ提供が可能になることがわかっている場合には、検索に失敗したが代案がある旨を表すコード１６０と、リクエストＩＤ１６１と、次に試みるべきメタデータ・サーバのＵＲＩ１６２と、次に試みるべきメタデータ提供期間１６３とを含むレスポンスを生成し、放送受信装置１００に返答する。

放送受信装置１００は、メタデータ・サーバ２００から訂正の返答を受け取ると、その返答の正規性をチェックし、メタデータ・リクエスト・レスポンスの処理と同様にして、再度、メタデータ取得のスケジューリングを行う。この一連の処理が完了すると、放送受信装置１００とメタデータ・サーバ２００は接続を完了する。

該当するメタデータがヒットしなかった場合で、かつメタデータ提供ＤＢ５１３によるとメタデータの提供が不可能であることが判明している場合は、「検索に失敗し、代案もない」旨を表すコードと、リクエストＩＤとを含むレスポンスを生成し、放送受信装置１００に返答する。このレスポンスの例を図１７に示す。

放送受信装置１００は、メタデータ・サーバ２００から検索不可の返答を受け取ると、その返答の正規性をチェックする。その結果、当該メタデータ・リクエストについては、該当するメタデータの取得ができなかったものとし、例外処理を行う。この一連の処理が完了すると、放送受信装置１００とメタデータ・サーバ２００は接続を完了する。

以上のように、メタデータ・リクエストの受付時点とメタデータの提供時点との間に時間差を与えることができ、すなわち、当初のメタデータ・リクエストに対して非同期的にメタデータを提供することができる。したがって、メタデータ提供業者は事前にメタデータを用意しない方法でのメタデータの提供も可能となる。もちろん、本装置において、メタデータ・リクエスト受付時点でメタデータの提供が可能な場合は、メタデータ提供期間を「即時」「ＮＯＷ」などとすることで、即時にメタデータの提供が可能である。

（第２の実施形態）
第２の実施形態は、録画済み番組宣伝視聴時の予約に関する。録画番組視聴中のシーンに対して、第１の実施形態と同様の効果を得る方法を述べる。

画面表示処理部１１７は、リモコンや本体スイッチなどからの利用者の操作をアクション受付部１１５で受付け、その操作を処理するＣＰＵ１０１の制御により録画再生処理部１２７の再生画像を表示する。

（ユーザアクションの受付と応答）
利用者は再生番組視聴中の予告シーン視聴の際にリモコンに専用に用意された「予告録画」ボタンを押すことで、その予告先番組の録画予約を希望する旨の指示を、アクション受付部１１５を介して放送受信装置１００に指示することができる。

この指示により、放送受信装置１００は、視聴中のシーンの放送日時とチャンネル情報を録画再生処理部１２７より取得し、メタデータ・リクエスト送信の際の検索キーとして記憶する。

視聴中のシーンの放送日時の算出は、例えば、「再生番組の放送開始時刻」＋「視聴シーンの先頭からの時間」から求める。

このようにして当該シーンの実際に放送された日時を求めることで、メタデータ・リクエスト登録手順やメタデータ取得手順については、第１の実施形態と同様の手順を実行することで、同様の効果を得ることが可能である。

（第３の実施形態）
第３の実施形態は、メタデータ・リクエストの受付とメタデータ提供とを別々のサーバにより実現する構成に関する。

図１８に示すように、データセンターはリクエストＤＢ５０７と、メタデータ提供状況ＤＢ５１３と、メタデータＤＢ５０９を備え、これらＤＢにアクセス可能な、メタデータ・リクエストサーバ２０１及びメタデータ提供サーバ２０３を備える。この構成により、各プロセスの処理の負荷を複数のハードウェアで分散処理することが可能になる。また、メタデータＤＢ５０９を放送地域毎、利用者グループ毎、放送局毎などのグループ毎に構成することもでき、メタデータ管理をより効率的に行える。

このような構成においては、各放送受信装置１００からのメタデータ・リクエストがメタデータ・リクエストサーバ２０１に送信されるが、その際のレスポンスにおいて、各放送受信装置１００が利用すべきメタデータ提供サーバ２０３の情報として利用可能なメタデータ提供サーバ群の中からラウンドロビンなどの方法で選択し通知することで、各放送受信装置１００が適当に分散されたタイミングでメタデータ提供サーバ２０３にアクセスするようにできるため、メタデータ検索処理の負荷分散が可能となる。

また、メタデータ・リクエストサーバ２０１を地域毎に構築し、各放送受信装置１００でリクエストを送信すべきメタデータ・リクエストサーバ２０１のＵＲＬを放送地域毎にに使い分けることで、放送受信装置１００側からは地域限定で有効な視聴チャンネル情報を利用して、メタデータ・リクエストを行う可能とする方法もある。この場合、メタデータ・リクエストサーバ群において地域性を考慮したチャンネルコードの把握を行うことで、メタデータ提供サーバ２０３を１つにまとめることもできる。あるいは、メタデータ検索サーバも地域ごとに用意しても良い。

このようにリクエストサーバと検索サーバが分離された構成においても、第１の実施形態と同様の効果を得ることが可能である。

（第４の実施形態）
第４の実施形態はＥＰＧサーバとの連動に関する。図１９にメタデータ・サーバ２００とＥＰＧサーバ７００とが連携した構成を示す。ＥＰＧとは電子番組表のことで、現在から１週間先までなど、ある期間の放送予定の番組編成表を電子的に提供するものである。放送受信装置１００は、放送波やインターネットにより、このＥＰＧ情報を画面に表示し利用することができる。このＥＰＧ情報は番組単位でスケジュールの管理がなされており、ある番組がいつ放送されるかを知ることができ、メタデータ・サーバ２００の各部の処理をカスタマイズしたり、拡張することができる。

まず、メタデータ・リクエスト登録のフェーズにおいて、放送受信装置１００とメタデータ・サーバ２００が同一のＥＰＧを参照できるようにすることで、視聴シーンの特定を「番組識別子」＋「視聴時間位置」で特定することが可能となる。これにより、番組の開始時間をＥＰＧの管理に任せることができるので、シーンの特定を番組中の視聴時間位置という相対的な指定が可能となる。たとえば、ある地域と別の地域で番組開始時刻が違っても、同じ視聴時間位置で同じ視聴シーンを特定できる。結果、メタデータＤＢ５０９やメタデータ提供状況ＤＢ５１３のデータ管理の手間を減らせる。また、ＥＰＧの情報更新機能と連動することが可能となり、スポーツ延長などの臨時の編成変更に対応できる。

また、録画された番組宣伝番組に対しても、その番組宣伝番組の「番組識別子」を記憶しておくことで、「番組識別子」＋「視聴時間位置」で視聴シーンの特定を行うことができる。

さらに、メタデータ提供時に、予告先番組のメタデータとして当該ＥＰＧの番組識別子を用いることで、放送受信装置１００はそのままその番組識別子でＥＰＧ番組連動予約を行うことが可能となる。

メタデータの管理においては、各メタデータのインスタンスにおいて、ＥＰＧと連携した形で、例えば、番組識別子をもって予告先番組を表現するなど、メタデータ作成の効率化が図れる。

また、メタデータ提供状況ＤＢ５１３において、ＥＰＧの番組編成情報を元に提供スケジュール構築することで、例えば、メタデータは作成されないことが確定している番組に対してはリクエスト受付時点でエラーを返したり、編成の確定した録画放送の番組に対してメタデータ提供情報をあらかじめ確定させるなど、より状況に応じた対応を放送受信装置１００に対して行うことが可能となる。

このようにＥＰＧサーバと連携することで、第１の実施形態と同様の効果を得ることができる。

（第５の実施形態）
第５の実施形態はメタデータの利用状況を分析するための分析サーバに関する。

図２０に示すように、メタデータ利用状況分析サーバ９００は、メタデータ・サーバ２００に接続されている。メタデータ利用状況分析サーバ９００は、放送受信装置１００からメタデータ・サーバ２００のメタデータ・リクエスト受付部５０１へのアクセスの記録、同放送受信装置１００からメタデータ提供部５０３へのアクセスの記録である通信ログを分析する。

通信ログは、利用者情報（ＩＰアドレス、ユーザ名、機器名など）、受信日時、アクションチャンネル、アクション時間、アクション種別、利用しているＥＰＧプロバイダなどの情報を含む。この通信ログ情報をもとに、例えば、各番組宣伝の効果の度合いをメタデータ・リクエスト数をもとに分析したり、メタデータ提供に際し利用者からの希望の多いメタデータの情報は特に粒度を詳細化したりなど、より柔軟な運用が可能となる。

以上説明した実施形態によれば、メタデータ提供者は、メタデータが未だ準備されていない番組の予告放送前や、予告放送後のいずれのタイミングにおいてもメタデータを生成し提供することができ、メタデータの提供形態の自由度は高く保たれる。また、提供者には番組宣伝のマーケティングデータを入手でき、そのデータを活用したメタデータ提供コストの回収や最適化を考えることができる。例えば、ある予告シーンに対して一定数のメタデータ取得希望を受けた時点でメタデータを準備して配布する、多くの利用者に取得されたメタデータは放送波経由でも配信する、などが考えられる。一方、利用者にはメタデータに基づくサービスをいつでも利用できるというメリットがある。番組宣伝視聴情報のキーとして、例えば「視聴チャンネル」＋「視聴日時」を用いて、ユーザアクションの時点でメタデータがなくても、後からメタデータを提供すれば利用者は所望の結果を得ることができる。

なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

第１の実施形態に係るメタデータ提供システムを示す図 放送受信装置のハードウェア構成を示す図 メタデータ・サーバのハードウェア構成を示す図で メタデータ・サーバ上で動作するソフトウェア構成を示す図 メタデータの記述内容と番組編成表との関係を示す図 メタデータＤＢ中のレコードを示す図 メタデータと番組放送枠との関係情報を示す図 メタデータ提供状況ＤＢを示す図 メタデータ・リクエストをメタデータ・サーバにおいて受け付ける手順を示す図 メタデータ・リクエストの形式を示す図 メタデータ・リクエストを保存するテーブルを示す図 メタデータ・リクエスト・レスポンスを示す図 放送受信装置がメタデータ・サーバからメタデータを受け取る手順を示す図 メタデータ提供希望メッセージを示す図 メタデータ・サーバからの返答メッセージ（レスポンス）を示す図 別のレスポンスを示す図 さらに別のレスポンスを示す図 第３の実施形態に係るデータセンターを示す図 第４の実施形態に係るＥＰＧサーバとの連携を示す図 第５の実施形態に係るメタデータ利用状況分析サーバを示す図

符号の説明

１００…放送受信装置、２００…メタデータ・サーバ、３００…ネットワーク

Claims (15)

1. 宣伝対象の番組の放送予定を表すメタデータを要求する第１のリクエストを受信する第１の受信部と、
   前記第１のリクエストに対してリクエストＩＤを発行する発行部と、
   前記第１のリクエストと前記リクエストＩＤとを関連付けて記憶する第１の記憶部と、
   前記第１のリクエストに対し、前記リクエストＩＤ、及びメタデータが提供される期間を含むリクエスト応答を送信する第１の送信部と、
   メタデータを記憶する第２の記憶部と、
   前記リクエストＩＤを含み、該リクエストＩＤに対応するメタデータを要求する第２のリクエストを前記メタデータが提供される期間に限って受け付けて受信する第２の受信部と、
   前記第２のリクエストに含まれるリクエストＩＤに該当するメタデータを前記第２の記憶部から検索し、該第２のリクエストに対して該メタデータを送信する第２の送信部と、を具備するメタデータ提供装置。
2. 前記第１のリクエストは、番組宣伝番組の視聴チャネル情報及び視聴時刻情報を含む請求項１記載のメタデータ提供装置。
3. 前記第１の受信部又は前記第２の受信部へのアクセスのログを記録する記録部と、
   前記ログを分析することにより、前記番組宣伝番組による番組宣伝の効果の度合いを算出する分析部とをさらに具備する請求項２記載のメタデータ提供装置。
4. 前記リクエスト応答は、メタデータ提供サーバの情報を含んでおり、
   前記第１の記憶部は前記メタデータ提供サーバの情報により指定される第１のサーバ装置に設けられ、前記第２の記憶部は前記メタデータ提供サーバの情報により指定される第２のサーバ装置に設けられる請求項２記載のメタデータ提供装置。
5. 前記第１のリクエストは、番組宣伝番組の視聴チャネル情報、又は番組宣伝番組の視聴チャネル情報及び前記番組宣伝番組の視聴中になされたアクションから前記第１のリクエストが送出されるまでの処理遅延時間を含み、前記視聴チャネル情報に対応する前記番組宣伝番組の視聴時刻情報を、前記第１のリクエストを受信した時刻、又は前記第１のリクエストを受信した時刻から前記処理遅延時間を減じた時刻とする請求項１記載のメタデータ提供装置。
6. 前記第１の受信部又は前記第２の受信部へのアクセスのログを記録する記録部と、
   前記ログを分析することにより、前記番組宣伝番組による番組宣伝の効果の度合いを算出する分析部とをさらに具備する請求項５記載のメタデータ提供装置。
7. 前記リクエスト応答は、メタデータ提供サーバの情報を含んでおり、
   前記第１の記憶部は前記メタデータ提供サーバの情報により指定される第１のサーバ装置に設けられ、前記第２の記憶部は前記メタデータ提供サーバの情報により指定される第２のサーバ装置に設けられる請求項５記載のメタデータ提供装置。
8. 前記第１のリクエストは、番組宣伝番組の番組識別子及び前記番組宣伝番組の視聴位置情報を含む請求項１記載のメタデータ提供装置。
9. 前記第１の受信部又は前記第２の受信部へのアクセスのログを記録する記録部と、
   前記ログを分析することにより、前記番組宣伝番組による番組宣伝の効果の度合いを算出する分析部とをさらに具備する請求項８記載のメタデータ提供装置。
10. 前記リクエスト応答は、メタデータ提供サーバの情報を含んでおり、
    前記第１の記憶部は前記メタデータ提供サーバの情報により指定される第１のサーバ装置に設けられ、前記第２の記憶部は前記メタデータ提供サーバの情報により指定される第２のサーバ装置に設けられる請求項８記載のメタデータ提供装置。
11. 宣伝対象の番組の放送予定を表すメタデータを要求する第１のリクエストを生成する第１の生成部と、
    前記第１のリクエストに対して発行されたリクエストＩＤ、及びメタデータが提供される期間を含むリクエスト応答を受信する第１の受信部と、
    前記リクエストＩＤを含み、該リクエストＩＤに対応するメタデータを要求する第２のリクエストを生成する第２の生成部と、
    前記第２のリクエストに含まれるリクエストＩＤに該当する前記メタデータの取得を前記メタデータが提供される期間をねらって試みることにより、前記メタデータを受信する第２の受信部と、を具備する放送受信装置。
12. 前記第２の受信部が受信したメタデータを用いて前記宣伝対象の番組を予約録画する予約録画部をさらに具備する請求項１１記載の放送受信装置。
13. 宣伝対象の番組を予約録画する放送受信装置と、前記放送受信装置に対してメタデータを提供するメタデータ提供装置とを有するメタデータ提供システムにおいて、
    前記放送受信装置は、
    前記宣伝対象の番組の放送予定を表すメタデータを要求する第１のリクエストを生成する第１の生成部と、
    前記第１のリクエストを前記メタデータ提供装置に送信する第１の送信部と、
    前記第１のリクエストに対して発行されたリクエストＩＤ、及びメタデータが提供される期間を含むリクエスト応答を前記メタデータ提供装置から受信する第１の受信部と、
    前記リクエストＩＤを含み、該リクエストＩＤに対応するメタデータを要求する第２のリクエストを生成する第２の生成部と、
    前記メタデータが提供される期間をねらって前記第２のリクエストを前記メタデータ提供装置に送信する第２の送信部と、
    前記第２のリクエストに含まれるリクエストＩＤに該当する前記メタデータを前記メタデータ提供装置から受信する第２の受信部と、を具備し、
    前記メタデータ提供装置は、
    前記第１のリクエストを前記放送受信装置から受信する第１の受信部と、
    前記第１のリクエストに対してリクエストＩＤを発行する発行部と、
    前記第１のリクエストと前記リクエストＩＤとを関連付けて記憶する第１の記憶部と、
    前記放送受信装置からの前記第１のリクエストに対し、前記リクエストＩＤ、及びメタデータが提供される期間を含むリクエスト応答を送信する第１の送信部と、
    メタデータを記憶する第２の記憶部と、
    前記リクエストＩＤを含み、該リクエストＩＤに対応するメタデータを要求する第２のリクエストを前記メタデータが提供される期間に限って受け付けて前記放送受信装置から受信する第２の受信部と、
    前記放送受信装置からの第２のリクエストに含まれるリクエストＩＤに該当するメタデータを前記第２の記憶部から検索し、該第２のリクエストに対して該メタデータを送信する第２の送信部と、を具備するメタデータ提供システム。
14. 宣伝対象の番組を予約録画する放送受信装置に対してメタデータ提供装置がメタデータを提供するメタデータ提供方法において、
    前記放送受信装置は、
    前記宣伝対象の番組の放送予定を表すメタデータを要求する第１のリクエストを生成し、
    前記第１のリクエストを前記メタデータ提供装置に送信し、
    前記第１のリクエストに対して発行されたリクエストＩＤ、及びメタデータが提供される期間を含むリクエスト応答を前記メタデータ提供装置から受信し、
    前記リクエストＩＤを含み、該リクエストＩＤに対応するメタデータを要求する第２のリクエストを生成し、
    前記メタデータが提供される期間をねらって前記第２のリクエストを前記メタデータ提供装置に送信し、
    前記第２のリクエストに含まれるリクエストＩＤに該当する前記メタデータを前記メタデータ提供装置から受信し、
    前記メタデータ提供装置は、
    前記第１のリクエストを前記放送受信装置から受信し、
    前記第１のリクエストに対してリクエストＩＤを発行し、
    前記第１のリクエストと前記リクエストＩＤとを関連付けて記憶し、
    前記放送受信装置からの前記第１のリクエストに対し、前記リクエストＩＤ、及びメタデータが提供される期間を含むリクエスト応答を送信し、
    メタデータを第２の記憶部に記憶し、
    前記リクエストＩＤを含み、該リクエストＩＤに対応するメタデータを要求する第２のリクエストを前記メタデータが提供される期間に限って受け付けて前記放送受信装置から受信し、
    前記放送受信装置からの第２のリクエストに含まれるリクエストＩＤに該当するメタデータを前記第２の記憶部から検索し、該第２のリクエストに対して該メタデータを送信するメタデータ提供方法。
15. 宣伝対象の番組の放送予定を表すメタデータを要求する第１のリクエストを受信する第１の受信手順と、
    前記第１のリクエストに対してリクエストＩＤを発行する発行手順と、
    前記第１のリクエストと前記リクエストＩＤとを関連付けて第１の記憶部に記憶する手順と、
    前記第１のリクエストに対し、前記リクエストＩＤ、及びメタデータが提供される期間を含むリクエスト応答を送信する送信手順と、
    メタデータを第２の記憶部に記憶する手順と、
    前記リクエストＩＤを含み、該リクエストＩＤに対応するメタデータを要求する第２のリクエストを前記メタデータが提供される期間に限って受け付けて受信する第２の受信手順と、
    前記第２のリクエストに含まれるリクエストＩＤに該当するメタデータを前記第２の記憶部から検索し、該第２のリクエストに対して該メタデータを送信する第２の送信手順と、をコンピュータに実行させるためのプログラム。

Images