JP5689858B2 - 情報提供システム、情報提供方法及びプログラム - Google Patents

Description

本発明の実施形態はユーザに情報を提供する情報提供システム、情報提供方法及びプログラムに関する。

近年、インターネットを介してユーザ端末をサーバに接続し、サーバにより種々の情報がユーザ端末に提供される情報提供システムが開発されている。例えば、インターネット上のサイトを閲覧可能なディジタルテレビジョン装置が普及している。ディジタルテレビジョン装置は放送コンテンツを受信・記録・再生することもできるし、インターネット上の各種サイトの情報を出力することもできる。

特開２００２−３２３９６号公報

現在の情報提供システムのサーバは大量の情報をユーザに提供できる反面、ユーザがその中から情報を選ぶことは容易ではなかった。

本発明の目的はユーザが情報を容易に選ぶことができる情報提供システム、情報提供方法及びプログラムを提供することである。

実施形態によれば、コンテンツについての情報であるコンテンツ情報を提供するためのシステムは、記憶手段と、提供手段とを具備する。記憶手段は、第１電子機器に記録されている１以上のコンテンツを特定可能な情報を記憶する。提供手段は、第１電子機器からのコンテンツ情報の要求に応答して、要求に従って選択されるコンテンツ情報のうち、第１電子機器に記録されているコンテンツに対応するコンテンツ情報を第１電子機器に提供する。

実施形態の情報提供システムの一例を示す図である。 図１の情報提供システム内のメタデータサーバのモジュール構成の一例を示す図である。 図１の情報提供システムで処理されるタグリストの構成の一例を示す図である。 図１の情報提供システムで処理されるシーン情報の構成の一例を示す図である。 図１の情報提供システムで処理されるシーン情報の構成の一例を示す図である。 図１の情報提供システムで処理されるシーン情報の構成の一例を示す図である。 人気シーンランキングの作成処理を示すフローチャートである。 シーン視聴率ランキングの作成処理を示すフローチャートである。 ＨＯＴワード取得・更新処理を示すフローチャートである。 既録画判定処理の一例を示すフローチャートである。 既録画判定処理の他の例を示すフローチャートである。 メタデータが作成されていない地域で放送される同一番組検索処理の一例を示すフローチャートである。 検索サーバによるシーン検索処理の一例を示すフローチャートである。 検索サーバによる録画番組一覧の変換の一例を示すフローチャートである。 クライアント端末の画面表示の一例としておすすめシーン表示を画面を示す図である。

以下、実施形態について図面を参照して説明する。

（システム構成）
図１はクラウド対応ＴＶに対してタイムクラウドサービスを提供するクラウドサーバのシステム構成を示す。実施形態に係るシステムは各種サーバとクライアント端末１０により構成される。クライアント端末１０はユーザインターフェース、通信機能、コンテンツ処理機能、コンテンツ出力機能、及びコンテンツ録画機能等を備えたデバイスであればどのようなデバイスであってもよい。クライアント端末１０の一例としては、例えばディジタルテレビジョン装置があるが、光ディスク記録再生装置等の他の映像機器でも良いし、タブレット型パーソナルコンピュータ、スマートフォン等のモバイル端末を利用することもできる。図１は、クライアント端末１０を１台しか示していないが、多数のクライアント端末１０がシステムに接続されている。

クライアント端末１０であるディジタルテレビジョン装置に搭載されるタイムクラウド機能である“ＳｃｅｎｅｆＯＳｃｅｎｅＬｉｓｔ／ＳｃｅｎｅＰｌａｙ”アプリケーションについて説明する。Ｓｃｅｎｅｆｏはシーン情報を意味する。ＳｃｅｎｅＬｉｓｔはシーン情報を集めたシーンリストを意味する。ＳｃｅｎｅＰｌａｙはシーン情報を利用した再生を意味する。

タイムクラウドはメタデータ作成会社、ユーザ、又はｂｏｔなどによって作成されたタグ又はシーン情報と映像コンテンツを結びつけるサービスであり、以下の３つの機能から構成される。タグとはコンテンツの頭出しのための情報であり、シーン情報とはコンテンツのあるシーンの内容を示す情報である。

＜Ｓｃｅｎｅｆｏ＞
Ｓｃｅｎｅｆｏは再生中の気になるシーンのシーン情報を提供する機能である。この機能の応用例には通信販売がある。ここで利用するタグリスト（登録商標）はあるコンテンツに含まれるタグの一覧であり、例えば、メタデータ作成会社が提供する企業作成タグリストや、ユーザが作成したユーザ作成タグリストがある。

Ｓｃｅｎｅｆｏ機能は次のステップからなる。
（１）タグリスト登録、（２）コンテンツ再生、（３）Ｓｃｅｎｅｆｏ起動、（４）タグリストの送受信、（４）商品提示（表示）、（５）商品選択（入力操作）、（６）商品ページの提供（表示）。

＜ＳｃｅｎｅＬｉｓｔ＞
ＳｃｅｎｅＬｉｓｔは再生中に視聴したいシーンだけを選択的に視聴する機能である。ユーザ作成タグリスト、タグｂｏｔタグリスト、メタデータ作成会社が提供する企業作成タグリストなど、様々なタグリストの中から利用したいタグリストから視聴したいシーンを選んで視聴する。

ＳｃｅｎｅＬｉｓｔ機能は次のステップからなる。
（１）タグリスト登録、（２）コンテンツ再生、（３）ＳｃｅｎｅＬｉｓｔ起動、（４）タグリスト一覧の送受信、（５）タグリスト選択（入力操作）、（６）タグリストの送受信、（７）タグジャンプ。

＜ＳｃｅｎｅＰｌａｙ＞
ＳｃｅｎｅＰｌａｙは再生可能な映像コンテンツの多数のシーン情報からユーザが興味のあるシーンを探して視聴する機能である。一例として、おすすめシーンから気になるシーンを発見し、そのまま気になるシーンを選んで視聴することがある。利用できるタグリストはユーザ作成タグリストやタグｂｏｔタグリスト、メタデータ作成会社が提供する企業作成タグリストなど、様々なタグリストが対象となる。

ＳｃｅｎｅＰｌａｙ機能は次のステップからなる。
（１）タグリスト登録、（２）ＳｃｅｎｅＰｌａｙ起動、（３）レコメンド処理、（４）タグ一覧の送受信、（５）タグ選択（入力操作）、（６）タグ位置からコンテンツ再生。

図１に示すように、クライアント端末１０はメタデータサーバ２０、レコメンドサーバ２２、履歴収集サーバ２４に接続される。クライアント端末１０はメタデータサーバ２０から番組情報を取得する。クライアント端末１０はレコメンドサーバ２２にお気に入り情報を送信し、履歴収集サーバ２４に操作履歴を送信する。

ここで、用語・略語の定義・説明を行う。

メタデータは放送番組データについて記述されたデータである。本明細書では、メタデータ作成サーバ３０から提供される番組放送履歴データ、テレビ紹介＜＜商品＞＞データ、テレビ紹介＜＜店舗＞＞データ、ＣＭ放送履歴データ等を指す。
メタデータサーバは上記メタデータを管理するサーバである。

シーン情報は番組内の１シーンの詳細情報を示すもので、上記メタデータから生成したデータである。
シーン情報リストは複数のシーン情報を番組単位でまとめたリストである。

タグはクライアント端末１０のタグ処理アプリケーションで使用される録画番組のシーン頭出し情報である。
タグリストは複数のタグを番組単位でまとめたリストである。タグリストサーバ２８はタグ、タグリストを管理するサーバである。

クライアント端末１０はメタデータサーバ２０に接続し、メタデータサーバ２０に対してメタデータを要求するものである。
履歴収集サーバ２４はクライアント端末１０におけるユーザの視聴履歴、操作履歴を収集するサーバである。
レコメンドサーバ２２はユーザの視聴履歴、操作履歴、嗜好情報（お気に入り情報）をもとにおすすめの番組、シーンを算出するサーバである。

Ｗｅｂアプリはクライアント端末１０上で動作するタイムクラウドアプリである。

番組情報：メタデータ、シーン情報リスト、タグリストの総称である。

メタデータサーバ２０はクライアント端末１０からの要求に応じて特定の番組についての番組情報（ここでは、例えばシーン情報リスト／タグリスト）をクライアント端末１０へ返す。クラウドサーバシステムは膨大な量の番組を記録しているので、全部の番組についてのシーン情報リスト／タグリストをクライアント端末１０へ送っても、ユーザは所望の番組・シーンを選ぶことができない。しかし、メタデータサーバ２０はユーザ毎に特定の番組についてのシーン情報リスト／タグリストをクライアント端末１０へ送るので、ユーザは視聴する番組・シーンを容易に選ぶことができる。

メタデータサーバ２０はレコメンドサーバ２２、検索サーバ２６、タグリストサーバ２８、メタデータ作成サーバ３０に接続される。メタデータサーバ２０はレコメンドサーバ２２からおすすめ／お気に入り情報を取得する。メタデータサーバ２０は検索サーバ２６からシーン／タグリスト検索結果を取得する。メタデータサーバ２０はタグリストサーバ２８にタグリストを登録し、タグリストサーバ２８からタグリストを取得する。メタデータサーバ２０はメタデータ作成サーバ３０からメタデータを取得する。

レコメンドサーバ２２は情報収集サーバ２４、検索サーバ２６に接続される。レコメンドサーバ２２は情報収集サーバ２４から各種ランキング、既録画（録画済み）判定、他地域の同一録画番組検索のための情報を取得し、検索サーバ２６から検索結果を取得する。

情報収集サーバ２４は検索サーバ２６に接続され、検索サーバ２６から既録画判定、他地域の同一録画番組検索のための情報を取得する。

検索サーバ２６はタグリストサーバ２８に接続され、タグリストサーバ２８からタグリストを取得する。各サーバはインターネットを介して接続される。

なお、各サーバは独立したサーバとして示しているが、複数のサーバが見かけ上１つのサーバとして構成されていても良い。

メタデータサーバ２０はタイムクラウドサービスのＳｅｃｅｎｅｆＯＳｃｅｎｅＬｉｓｔ、ＳｃｅｎｅＰｌａｙ機能を実現するために必要な放送番組の内容を示すメタデータを管理するサーバである。サービスで使用するメタデータはデータ提供元であるメタデータ作成サーバ３０から取得する。メタデータは通常の電子番組表（ＥＰＧデータ）に加えて、番組やＣＭをメタデータ作成会社のオペレータが実際に視聴し、手入力した情報も記憶している。この情報の例としては、何時、どの局のどのような番組で、誰が、どのような話題・企業・商品・ショップ等について、どのくらいの時間、どのようにコメントしたかについての情報がある。なお、メタデータは手入力に限らず、メタデータ作成サーバ３０が放送番組を分析して自動的にメタデータを作成してもよい。

メタデータサーバ２０は取得したメタデータを用いて、番組内の１シーンの詳細情報を示すシーン情報を生成し、シーン情報リストをクライアント端末１０に送信する。メタデータサーバ２０は詳細なメタデータから一部を抜粋、あるいは整形して、あるシーンについてのシーン情報を作成し、一番組についてのシーン情報リストを作成する。あるいは、メタデータサーバ２０はタグリストサーバ２８から取得した、ある番組についてのタグリスト(頭出し情報のリスト)をクライアント端末１０に送信する。シーン情報リスト、タグリストに基づいてユーザは番組の内容を知ることができるので、視聴する番組の選択が容易となる。なお、メタデータそのものを番組情報として利用してもよい。あるいは、メタデータ作成サーバ３０の代わりにシーン情報作成サーバを設けてもよい。

メタデータサーバ２０はクライアント端末１０の要求に応じて、要求を満たす番組についての必要なメタデータをシーン情報に変換し、クライアント端末１０に送信する。また、タイムクラウドサービスで使用するユーザ作成のタグリストについても、クライアント端末１０はメタデータサーバ２０を経由してタグリストサーバ２８から取得することも可能である。

ＳｃｅｎｅＰｌａｙにおいては、シーン情報リスト／タグリスト検索処理は検索サーバ２６で実行され、おすすめ／お気に入りシーンの算出処理はレコメンドサーバ２２で実行される。メタデータサーバ２０はクライアント端末１０からのＷｅｂ ＡＰＩ（Application program interface）受信処理とレスポンデータの作成処理のみ実行する。

(メタデータサーバ２０の構成)
図２はメタデータサーバ２０のモジュール構成の一例を示す図である。メタデータサーバ２０は外部のメタデータ作成サーバ２８からメタデータを取得し、メタデータを変換してタグ、シーン情報を生成し、タグリストはタグリストサーバ２８へ送信（登録）するとともに、シーン情報リストをクライアントからの要求に対して回答するために格納しておく。タグリスト、シーン情報はメタデータの抜粋・整形処理により得られ、番組名と時刻の情報を含む。メタデータは主要都市、例えば東京、名古屋、大阪にて放送される番組についてのものしかない。主要都市以外の地域（地方）で放送される番組については、各ユーザが手入力したタグ情報がタグリストサーバ２８へ登録されており、当該情報を使用し得る。ユーザ（クライアント端末のユーザに限らない）はタブレット型パーソナルコンピュータ、スマートフォン等のモバイル端末からタグ情報を入力する。

メタデータからタグ、シーン情報へ変換されるに当って、開始時刻等は絶対時刻から相対時刻へ変換される。タグ、シーン情報にはチャンネルコード（放送地域、チャンネルを示す識別子）が付与される。

メタデータサーバ２０はタグリストをタグリストサーバ２８へ送り、シーン情報をクライアント端末１０からの要求に対して回答するために保管する。シーン情報は多種類の情報を含む。タグはシーン情報よりも少ない情報（時刻と番組名）を含む。

番組情報として、情報量が多いリッチな情報（シーン情報）と、情報量が少ないプアな情報（タグ）のそれぞれを有することで、タグのみに対応する旧世代のクライアント端末が有するアプリケーションも番組情報を使用できる。また、シーン情報はクライアント端末１０からしかアクセスできないが、タグはインターネットからもアクセスできる。

メタデータサーバ２０とタグリストサーバ２８とをそれぞれ別個のサーバとすることでも、同様の効果がある。

メタデータサーバ２０はクライアント端末１０からの要求に対して要求に応じた番組の番組情報（シーン情報リスト、タグリスト）を提供する。要求があると、先ず、メタデータサーバ内で格納するメタデータを要求に応じて検索する。その次に、タグリストサーバ２８へ問い合わせる（タグリストを検索する）。メタデータサーバ２０のメタデータを検索するか、タグリストサーバ２８のタグリストを検索するかは、クライアント端末１０のアプリケーションが判断する。メタデータサーバ２０はクライアント端末１０から要求された番組情報を送信する際に、その番組情報に関連する商品情報等も合わせて送信する。クライアント端末１０から要求するもののメインはシーン情報、タグである。

メタデータサーバ２０は他のサーバ（タグリストサーバ２８、レコメンドサーバ２２、検索サーバ２６、履歴収集サーバ２４）と、クライアント端末１０との通信を仲介するゲートウェイの役割を果たす。基本的は、クライアント端末１０と他のサーバとの通信を仲介（スルー）しているだけである。例えば、クライアント端末１０からコマンドをもらって、検索サーバ２６に渡す。なお、メタデータサーバ２０とは別に、フロントエンドサーバを設けても良い。その場合、フロントエンドサーバが、その他のサーバ（メタデータサーバ２０も含む）とクライアント端末１０との通信を仲介する。

以下、メタデータサーバ２０が提供する機能処理部について詳細に記載する。

（１）コマンド（Ｗｅｂ ＡＰＩ）処理部２０Ａ
メタデータサーバ２０はＷｅｂアプリを実行するためのＷｅｂ ＡＰＩにより各種データを取得し、クライアント端末１０へ提供する。例えば、メタデータサーバ２０は以下のデータを取得し、クライアント端末１０へ提供する。

（ａ）番組一覧の取得
タグリストサーバ２８内のタグリストが登録されている番組の一覧を取得する。

（ｂ）タグリスト一覧の取得
タグリストサーバ２８内に登録されているタグリスト一覧を取得する。

（ｃ）タグリストの取得
タグリストサーバ２８内に登録されているタグリストを取得する。

（ｄ）シーン情報の取得
指定した番組のシーン情報を取得する。

（ｅ）商品情報の取得
商品情報詳細を取得する。

（ｆ）商品情報一覧の取得
シーンに含まれる商品情報の一覧を取得する。

（ｇ）店舗情報の取得
店舗情報詳細を取得する。

（ｈ）店舗情報一覧の取得
シーンに含まれる店舗情報の一覧を取得する。

（ｉ）シーン情報の検索
クライアント端末１０から入力されたキーワードに合致するシーン情報を検索し取得する。指定した検索条件に一致するシーン情報を含むシーン情報リストを取得する。検索条件には、ユーザが入力する任意キーワードを指定可能なものとする。

（ｊ）“おすすめ”のモード／カテゴリの取得
“おすすめ”で対応可能なモード／カテゴリリストを取得する。これは、ユーザが登録したお気に入りシーンの取得も含む。

（ｋ）おすすめシーンの取得
モード、カテゴリで指定した“おすすめ”シーンを取得する。

（ｌ）シーン情報リストの取得
指定した条件に一致する番組のシーン情報リストを取得する。指定条件に一致する番組のシーン情報リストが複数存在する場合は、全て取得する。条件一致するシーン情報リストが存在しない場合は、その旨が通知される。取得するシーン情報リスト中にタグリストサーバ２８に登録されているユーザ作成のタグリストを含めることも可能とする。

（ｍ）シーン情報リストが存在する番組一覧の取得
指定した条件のシーン情報リストが存在する“番組の一覧”を取得する。取得する番組一覧中に、タグリストサーバ２８に登録されているユーザ作成のタグリストが存在する番組を含めることも可能とする。

（ｎ）シーン情報リスト一覧の取得
指定した番組に登録されている“シーン情報リストの一覧”を取得する。取得するリスト一覧中に、タグリストサーバ２８に登録されているユーザ作成のタグリストの一覧を含めることも可能とする。

（ｏ）シーン情報リストの取得（ＩＤ指定）
指定したＩＤの“シーン情報リスト”を取得する。タグリストＩＤを指定した場合は、タグリストサーバ２８に登録されているユーザ作成のタグリストを取得する。

（ｐ）おすすめシーン情報の取得
レコメンドサーバ２２が算出した“おすすめシーン”情報を取得する。

（ｑ）お気に入りシーン情報の取得
サーバが管理するユーザが登録した“お気に入りシーン”情報を取得する。

（２）メタデータ取得処理部２０Ｂ
メタデータ作成サーバ３０が提供するメタデータを取得する。メタデータ作成サーバ３０が提供するメタデータの取得には、メタデータ作成サーバ３０が提供するＷｅｂ ＡＰＩを使用する。

各種メタデータを一定間隔で取得する。取得間隔は、サーバの状態に応じて変更可能なものとする。

（ａ）番組放送履歴データは１時間間隔で、現時刻から過去１時間分の更新データを各地域毎に取得する。

（ｂ）ＣＭ放送履歴データは１時間間隔で、現時刻から過去１時間分の更新データを取得する。取得する地域は東京プラスα。

（ｃ）テレビ紹介商品データは１時間間隔で、現時刻から過去１時間分の更新データを各地域毎に取得する。

（ｄ）テレビ紹介店舗データは１時間間隔で、現時刻から過去１時間分の更新データを各地域毎に取得する。

（ｅ）放送局情報、番組ジャンル情報、番組分類情報、地域情報、ＣＭジャンル情報、商品ジャンル情報、店舗ジャンル情報は１日間隔で、現時刻から過去１日分の更新データを取得する。

番組放送履歴データとＣＭ放送履歴データについては、同時刻に放送されたデータであってもメタデータ作成の所要時間により取得できるタイミングにズレが生じる（番組放送履歴データは放送終了後２〜３時間後、ＣＭ放送履歴データは２〜３日後に取得可能となる）。

初めに番組放送履歴データが取得できたタイミングでその番組データをデータベースに登録し、その後ＣＭ放送履歴データが取得できたタイミングで、そのＣＭデータに紐付く番組放送履歴データを再取得し、ＣＭデータと併せてデータベースに登録する。

そのため、ＣＭデータについては、データベースからの取得タイミングによりデータ内容が異なる場合がある。

Ｗｅｂ ＡＰＩ経由でメタデータ作成サーバ３０から取得したメタデータを、メタデータサーバ２０内のデータベース２０Ｃに登録する。

また、下記データをメタデータサーバ２０内で生成し、データベース２０Ｃに登録する。

（ａ）タグリスト登録時にタグリストサーバ２８から発行されたタグリストＩＤは番組／シーンテーブルに追加される。

（ｂ）サービスＩＤを検索キーとして使用して放送局テーブルから取得したネットワークＩＤは番組／シーンテーブルに追加される。

（ｃ）地域テーブルから取得した地域ＩＤは番組／シーンテーブルに追加される。

（ｄ）エリア名は番組／シーンテーブルに追加される。

（ｅ）サブエリア名は番組／シーンテーブルに追加される。

（ｆ）メタデータ作成サーバ３０から取得したメタデータをもとに生成されるチャンネルコードは番組／シーンテーブルに追加される。

（ｇ）サービスＩＤを検索キーとて使用して放送局情報テーブルから取得したチャンネル名は番組／シーンテーブルに追加される。

（ｈ）各シーンの出稿開始／終了時刻を番組開始時刻からの相対時間（単位はｍｓ）に変換した出稿開始／終了時刻（相対時間）はシーンテーブルに追加される。

（ｉ）番組名＋固定文字からなるタグリスト名はシーンテーブルに追加される。

（ｊ）番組ジャンルＩＤを検索キーとして使用して番組ジャンルテーブルから取得した番組ジャンルは番組／シーンテーブルに追加される。

（ｋ）番組分類ＩＤを検索キーとして使用して番組分類テーブルから取得した番組分類はシーンテーブルに追加される。

（ｌ）ＣＭジャンルＩＤを検索キーとして使用してＣＭジャンルテーブルから取得したＣＭジャンル（大／中／小分類）はＣＭテーブルに追加される。

（ｍ）各ＣＭの出稿開始／終了時刻を番組開始時刻からの相対時間（単位はｍｓ）に変換したＣＭ出稿開始／終了時刻（相対時間）はＣＭテーブルに追加される。

（ｎ）特殊記号を文字列処理したメモはＣＭテーブルに追加される。

（ｏ）商品ジャンルＩＤを検索キーとして使用して商品ジャンルテーブルから取得した商品ジャンル（ジャンル１／２／３／４／５）は商品テーブルに追加される。

（ｐ）店舗ジャンルＩＤを検索キーとして使用して店舗ジャンルテーブルから取得した店舗ジャンル（ジャンル１／２／３／４／５）は店舗テーブルに追加される。

（ｑ）シーン種別（０：シーン情報内のＣＭ件数が−１、０の場合、１：シーン情報内のＣＭ件数が１以上の場合）はシーンテーブルに追加される。

（ｒ）アフィリエイトＩＤを追加する商品検索結果一覧ページＵＲＬはＣＭ／商品テーブルに追加される。

（ｓ）メタデータ作成者を示すタグラー種別、タグラー名はシーンテーブルに追加される。

（３）タグリスト生成／登録処理部２０Ｄ
メタデータ中の番組放送履歴データをタグリストサーバ２８にタグリストとして登録する。登録したメタデータは既存タグリストと互換性を持ち、クライアント端末１０のタグ処理アプリケーションから利用可能である。

図３はタグリストとして登録するメタデータを示す。

削除／登録フラグｍｒｆは固定値：１とする。

タグリスト本体（開始時間、タグ）ｔｌにはシーンテーブル（出稿開始時刻／ヘッドライン）が登録される。出稿開始時刻は番組開始時刻からの相対時間（ｍｓ）である。

タグリストに含まれるタグの数ｔｌｃｔには１番組のシーン数をカウントする。タグリストのタグ数が上限９９件（タグリストサーバ２８の制限）を越える場合は、登録するタグリストを複数に分割する。

番組タイトルｔｌｔｌにはシーンテーブル（番組名）を登録する。番組名は最大９６文字（タグリストサーバ２８の制限）である。

チャンネルコードｔｌｃｈにはシーンテーブル（チャンネルコード）が登録される。

放送開始日時ｔｌｓｔにはシーンテーブル（番組開始日時）が登録される。番組開始日時はＴＩＭＥＳＴＡＭＰ型であり、（ＹＹＹＹ−ＭＭ−ＤＤ ＨＨ：ＭＭ：ＳＳ）をＹＹＹＹＭＭＤＤｈｈｍｍｓｓ形式に変換する。

タグリスト名ｔｌｎｍにはシーンテーブル（番組名）が登録される。なお、番組名末尾に固定文字列を追加する（番組名＋固定文字）。

対象番組のチャンネル名称ｔｌｃｈｎｍにはシーンテーブル（放送局名）が登録される。

放送種別ｂｍｋには固定値：０１（１６進数）（０００００００１ｂ：地上波デジタル）が登録される。

タグリスト対象コンテンツのＩＤｔｌｃｉｄには固定値：０が登録される。

（４）シーン情報生成処理部２０Ｅ
メタデータ作成サーバ３０から取得したメタデータをもとにシーン情報を生成し、クライアント端末１０に送信する。シーン情報生成時に実行する処理を下記に示す。

（４ａ）同一番組情報の検索
クライアント端末１０から受信した、番組放送日時、チャンネルコード（放送地域を示す）、タグリストＩＤ、シーンＩＤをもとに、該当する番組のメタデータをメタデータサーバ２０内のデータベース２０Ｃから取得する。例えば、メタデータが作成されていない地域のユーザに対しては、主要都市で放送される番組のうち当該地域の番組と同じ内容の番組のメタデータを利用する。これにより、メタデータが作成されていない地域のユーザもメタデータを利用することができる。取得したメタデータをＪＳＯＮフォーマットの番組シーン情報に変換し、クライアント端末１０に送信する。該当する番組が複数存在する場合は、全ての候補をクライアント端末に送信する。該当する番組が存在しない場合は、その旨をクライアント端末１０に送信する。

（４ｂ）シーン情報の生成
メタデータサーバ２０内のデータベース２０Ｃに格納された放送履歴データ、商品データ、店舗データ、ＣＭ放送履歴データを関連付け、シーン情報を生成する。

生成するシーン情報に含まれるメタデータを図４、図５、図６に示す。

Ａ．番組放送履歴データ
シーンリストＩＤ：タグリスト登録時にタグリストサーバ２８から発行されたＩＤ（タグリストＩＤ）
チャンネルコード：放送地域、チャンネルを示す識別子
放送局名
番組名
放送開始日時：番組の放送開始時間
放送終了日時：番組の放送終了時刻
曜日
シーンＩＤ：番組内のコーナー（シーン）単位で付与するユニークＩＤ
シーン名：該当シーンの概要（ヘッドライン）
シーン詳細説明：該当シーンの詳細説明（メモ）
シーン開始時間：番組内で細分化されたシーンの開始時刻
シーン終了時間：番組内で細分化されたシーンの終了時刻
シーン種別：番組情報なのかＣＭ情報なのかを示すフラグ
番組ジャンル
Ｂ．商品データ
商品名：番組内で紹介されて商品名
商品情報ＩＤ：商品毎に付与するユニークＩＤ（同一商品でも紹介毎に個別のＩＤを付与）
販売店名：商品の販売店
ジャンル１：商品データであることを示す“商品”が記載。

ジャンル２：大分類
ジャンル３：中分類
ジャンル４：小分類
ジャンル５
ジャンル６
関連人物１：主演／作家
関連人物２：助演
関連人物３：監督
商品概要説明
商品紹介状況
ショッピングＵＲＬ：当該商品のショッピング検索結果一覧ページＵＲＬ
ショッピング画像ＵＲＬ：当該商品のショッピング上の画像リンクＵＲＬ
Ｃ．店舗データ
店舗名：番組内で紹介された店舗名
店舗情報ＩＤ：紹介店舗毎に付与されるユニークＩＤ（同一店舗でも紹介毎に個別のＩＤを付与）
店舗住所：郵便番号含む
店舗電話番号
ジャンル１：店舗データであることを示す“店舗”が記載。

ジャンル２：大分類（飲食店／宿泊施設など）
ジャンル３：中分類（和食／洋食／ホテル／旅館など）
ジャンル４：小分類（てんぷら／イタリア料理／リゾートホテル／ビジネスホテルなど）
ジャンル５
ジャンル６
緯度：世界測地系／日本測地系 両方
経度：世界測地系／日本測地系 両方
紹介メニュー１／２／３／４／５：番組内で紹介されたメニュー
店舗・紹介メニューの概要説明
紹介状況
地図サイトＵＲＬ：施設／店舗の地図リンクＵＲＬ
トラベルＵＲＬ：トラベル国内宿泊施設ページへのリンクＵＲＬ（ジャンル「宿泊施設」のみ）
Ｄ．ＣＭデータ
商品名：ＣＭで紹介された商品名
ＣＭ ＩＤ：ＣＭ毎に付与されるユニークＩＤ
会社名：商品を販売する会社名
ＣＭ開始時間
ＣＭ終了時間
ＣＭジャンル 大分類
ＣＭジャンル 中分類
ＣＭジャンル 小分類
状況設定：ＣＭ放送内容（主に設定）
備考：注意喚起内容（キャンペーン告知、飲酒運転防止テロップ）
タレント
ＢＧＭ：ＣＭ内で演奏されたＢＧＭ
メモ：主なテロップ内容、商品名詳細、キャッチコピー
ショッピングＵＲＬ：当該商品のショッピング検索結果一覧ページＵＲＬ
ショッピング上の画像リンクＵＲＬ：当該商品のショッピング上の画像リンクＵＲＬ
１シーン情報内に商品情報、店舗情報が存在しない場合もある。また１シーン情報内に複数の商品データ、店舗データが関連付けられる場合もある。

（５）タグリスト取得処理部２０Ｆ
メタデータサーバ２０はクライアント端末１０からの要求に対してタグリストサーバ２８に登録されているタグリストから要求に応じた番組のタグリストを取得し、必要な処理を実施した後、クライアント端末１０に送信する。タグリストサーバ２８からのデータ取得は、タグリストサーバ２８が提供するＡＰＩを使用する。メタデータサーバ２０がタグリストサーバ２８から取得するデータはタグ及びタグリストに関するものである。

（６）検索処理部２０Ｇ
クライアント端末１０から受信した検索条件に一致するメタデータをメタデータサーバ２０内のデータベース２０Ｃとタグリストサーバ２８から検索する。メタデータサーバ２０はクライアント端末１０からのＷｅｂ ＡＰＩ受信処理とレスポンスデータの整形処理のみ実行する。

なお、タグリストサーバ２８が管理するタグリストと、メタデータサーバ２０内で生成するシーン情報を、クライアント端末１０の要求に応じてメタデータサーバ２０でマージし、クライアント端末１０に送信してもよい。また、タグリストサーバ２８から取得するタグ情報にはタグ終了時間が記載されていないため、クライアント端末１０からの要求に応じて、注目するタグの次タグの開始時間を現タグの終了時間として設定する処理を、メタデータサーバ２０にて実行してもよい。

（７）おすすめ／お気に入り処理部２０Ｈ
レコメンドサーバ２２からおすすめ／お気に入りシーン情報を取得し、クライアント端末１０に送信する。

レコメンドサーバ２２からは該当するシーンのリスト情報（ＩＤリスト）を受信し、メタデータサーバ２０はリスト情報をもとにメタデータサーバ２０内のデータベース２０Ｃとタグリストサーバ２８からシーン情報リスト／タグリストの詳細情報を取得する。取得した複数のシーン情報リスト／タグリストの詳細情報からクライアント端末１０がコンテンツ再生時に必要なプレイリストを作成する。

（８）シーン情報送信処理部２０Ｉ
シーン情報生成処理部２０Ｅが作成したシーン情報リストをクライアント端末１０に送信する。シーン情報はＪＳＯＮフォーマットで送信し、タグリストサーバ２８から取得したＸＭＬフォーマットのタグリストデータはシーン情報生成処理部２０ＥでＪＳＯＮフォーマットに変換し、クライアント端末１０に送信する。

（レコメンドサーバ２２の構成）
次に、レコメンドサーバ２２について詳細を説明する。レコメンドサーバ２２は履歴収集サーバ２４に蓄積された各ユーザ（クライアント端末１０）の視聴履歴・録画履歴の情報をもとに、各ユーザへのおすすめ／お気に入り情報を算出して、提示する。

他のサーバやクライアント端末からレコメンドサーバ２２へのリクエストはＨＴＴＰのＰＯＳＴメソッドが使用され、レコメンドサーバ２２からのレスポンスはＪＳＯＮ形式で送信されることが想定されるが、他の形式でもよい。

レコメンドサーバ２２の機能は以下である。

（ａ）ユーザへのおすすめ／お気に入りシーン／番組情報の提示：例えば以下ようなものがある。（１）ランキングデータ：ログサーバ等から各種情報を取得、集計する。その各順位に該当する番組、シーンを検索し、ユーザ向けの番組、シーンのランキングを作成する。（２）嗜好学習：ユーザの操作、閲覧からユーザの嗜好にあった番組、シーンを算出する。（３）ＨＯＴワード：外部のサーバから取得したＨＯＴワード(キーワード)のリストを提供する。

（ｂ）既録画判定
既録画判定ユーザが該当番組またはシーンを既に録画しているか否かを判定し、リストを提供する。

（ｃ）同一番組取得：別のユーザから送られたチャンネルと時刻の番組が、視聴可能か否かを判定する。

ユーザへのおすすめ／お気に入り番組の番組情報の提示の仕方としてはランキング形式があり、その例は、イチオシシーン（シーンの視聴率のランキング）、人気シーン、みんなの気になるシーン（シーンの気になるランキング）、ソーシャルネットワーク盛り上がりシーン、友人からの推薦シーン、友人のお気に入りシーン、人気商品・店舗シーン、ＨＯＴワード検索、あなたへのおすすめシーン等がある。

ランキングデータはランキングの種類に応じて、端末ＩＤ（対象となるクライアント端末のＩＤ）、ＵＳＥＲ＿ＩＤ（対象ユーザのＵＳＥＲ ＩＤ）、おすすめシーンカテゴリＩＤ（おすすめシーンのカテゴリ固有のＩＤ）、対象期間開始時刻（集計対象の期間の開始時刻）、対象期間終了時刻（集計対象の期間の終了時刻）、集計時刻（ランキングを作成した時刻）、最大順位数（ランキングの最大順位）、順位（ランキング中の順位）、チャンネルコード、番組開始時刻（シーン／タグが属する番組の放送開始時刻）、番組終了時刻（シーン／タグが属する番組の放送終了時刻）、番組管理コード（番組固有のＩＤ）、番組管理枝番（番組の放送回に固有のＩＤ）、番組ＩＤ（シーン／タグが属する番組データＩＤ／タグリストＩＤ）、シーンＩＤ（シーン／タグ固有のＩＤ）、番組タイトル（シーン／タグが属する番組データ／タグリストのタイトル）、シーンタイトル（シーン／タグのタイトル）、シーン開始時間（シーン／タグの開始時刻）、シーン終了時間（シーン／タグの終了時刻）、商品・店舗ＩＤ（対象商品／店舗のＩＤ）、商品・店舗名（対象商品／店舗の名称）、検索キーワード、視聴数（集計した視聴数）、シーンジャンプ数（集計したシーン／タグジャンプ数）、お気に入り登録数（集計したお気に入りの登録数）、友人からの推薦数（集計した友人からのおすすめ数）、友人お気に入り登録数（集計した友人のお気に入り登録数）、嗜好スコア（シーン／タグの嗜好スコアの値）の中から選択した項目を含む。

イチオシシーンランキングは視聴（ＬＩＶＥ）ログから高視聴数な時間帯を算出し、視聴数でランキングを作成する。

人気シーンランキングはタイムクラウドでのシーンジャンプのログから、シーンジャンプ数を集計しランキングを作成する。

人気シーンランキングの作成処理を図７のフローチャートを参照して説明する。

ブロックＢ７１で、ログ取得を実行する。すなわち、レコメンドサーバ２２は履歴収集サーバ２４へシーンジャンプ数要求を送信する。履歴収集サーバ２４はレコメンドサーバ２２へシーンＩＤリスト、シーンＩＤ、カウント数を送信する。これにより、履歴収集サーバ２４からシーンジャンプ数（過去１週間分）を取得する。

ブロックＢ７２で、シーンＩＤ検索を実行する。すなわち、レコメンドサーバ２２はメタデータサーバ２０へシーン検索要求とシーンＩＤを送信する。メタデータサーバ２０はレコメンドサーバ２２へシーンＩＤ、チャンネル、シーン開始時刻を送信する。これにより、シーンＩＤからチャンネルとシーン開始時刻を取得する。

ブロックＢ７３で、そのシーンが最近１週間の番組のシーンであるかを判定する。否の場合は、ブロックＢ７２に戻る。最近１週間の番組のシーンである場合は、ブロックＢ７４で、番組検索を実行する。すなわち、レコメンドサーバ２２は図示しない外部のＥＰＧサーバに番組検索要求とチャンネル、シーン開始時刻を送信する。ＥＰＧサーバからは番組管理コード、番組管理枝番、番組名が返信される。なおこれらＥＰＧデータは、あらかじめＥＰＧサーバから取得し、レコメンドサーバ２２内のデータベースに格納しておいてもよい。

ブロックＢ７５で、ランキング数の繰返しが必要か否か判定され、必要である場合はブロックＢ７２に戻り、不要な場合はブロックＢ７６で、ランキング表をレコメンドサーバ２２内のデータベースに保存して、処理を終了する。

シーン視聴率ランキングは視聴（ＬＩＶＥ）ログから高視聴数の時間帯を算出し、視聴数でランキングを作成し、対応するメタデータのシーンを高視聴率シーンとする。そのうち過去１日、１週間、１か月分のシーンランキングを提示する。１日１回のバッチ処理を行う。

シーン視聴率ランキングの作成処理を図８のフローチャートを参照して説明する。
ブロックＢ８１で、ログ取得を実行する。すなわち、レコメンドサーバ２２は履歴収集サーバ２４へ視聴数要求を送信する。履歴収集サーバ２４はレコメンドサーバ２２へ視聴数リスト、チャンネル、カウント数、時刻を送信する。これにより、履歴収集サーバ２４から視聴数（過去１日、１週間、あるいは１か月分）を取得する。

ブロックＢ８２で、シーンＩＤ検索を実行する。すなわち、レコメンドサーバ２２はメタデータサーバ２０へシーン検索要求とシーンＩＤを送信する。メタデータサーバ２０はレコメンドサーバ２２へシーンＩＤ、チャンネル、シーン開始時刻を送信する。これにより、シーンＩＤからチャンネルとシーン開始時刻を取得する。

ブロックＢ８３で、番組検索を実行する。すなわち、レコメンドサーバ２２は図示しない外部のＥＰＧサーバに番組検索要求とチャンネル、シーン開始時刻を送信する。ＥＰＧサーバからは番組管理コード、番組管理枝番、番組名が返信される。

ブロックＢ８４で、ランキング数の繰返しが必要か否か判定され、必要である場合はブロックＢ８２に戻り、不要な場合はブロックＢ８５で、ランキング表をレコメンドサーバ２２内のデータベースに保存して、処理を終了する。

人気商品・店舗シーンランキングはメタデータ作成サーバ３０から供給される番組に関する商品・店舗ページの閲覧／ＵＲＬのジャンプ数を集計し、閲覧／ＵＲＬのジャンプ数の多い商品・店舗ページを持つシーンをおすすめする。

ＨＯＴワード検索ランキングは外部のサーバから取得したＨＯＴワード（検索数が多いキーワード）のリストを作成する。

ＨＯＴワード取得・更新処理を図９のフローチャートを参照して説明する。

ブロックＢ９１で、外部サーバにＨＯＴワード取得要求を送信し、外部サーバから結果を取得する。

ブロックＢ９２で、取得した結果からＨＯＴワードを抽出する。

抽出したキーワードに基づいて、ブロックＢ９３で、ＨＯＴワードテーブルを更新する。更新したＨＯＴワードテーブルはレコメンドサーバ２２内のデータベースに保存する。

ＨＯＴワードテーブルは管理用ＩＤ、キーワード（登録キーワード／クエリ）、順位（ＨＯＴワードの順位）、更新時刻（ＨＯＴワードを更新した時刻）を含む。

以上のように、レコメンドサーバ２２は各クライアント（ユーザ）に対しておすすめするシーンを決めるが、そのシーンを含む番組がユーザのクライアント端末１０で録画されていなければ、提示する意味がない。このため、レコメンドサーバ２２はユーザへおすすめするシーンが、そのユーザのクライアント端末１０で録画されているのか（視聴可能なのか）否かを判断する。おすすめシーンは検索サーバ２６等から受信する。各クライアント端末１０で録画されているのか（視聴可能なのか）否かを履歴収集サーバ２４の操作履歴情報（録画履歴を含む）をもとに判断する。ユーザへおすすめするシーンのうち、ユーザの端末で録画されていないものを除外する、あるいはユーザの端末で録画されているものに印をつけてユーザへ提示する。

録画番組の既録画判定処理の一例を図１０のフローチャートを参照して説明する。図１０は録画番組を個々に指定して録画するＰＶＲ録画の場合である。

ブロックＢ１００１で、レコメンドサーバ２２はおすすめシーンを含む番組を特定するための比較データ（Ａ）を、データベースのランキング表等から取得する。あるいは、他のサーバ（図１内、あるいは図示しない外部のサーバ)から、比較データ（Ａ）を取得する。この場合、具体的には、ＵＳＥＲ＿ＩＤ、端末ＩＤ、チャンネル、開始時刻を取得する。

ブロックＢ１００２で、録画番組リスト（Ｂ）を取得する。具体的には、履歴収集サーバ２４で取得し、レコメンドサーバ２２内のデータベースに保存されている録画番組リストを取得する。レコメンドサーバ２２は履歴収集サーバ２４から該当機器の録画番組リストを取得する。録画番組リストは１日１回と録画開始時刻の都度、クライアント端末１０から送信される。レコメンドサーバ２２はデータベース内に録画番組リストを書き込む。録画番組リストは管理用ＩＤ、端末ＩＤ（対象機器のＩＤ）、ＵＳＥＲ＿ＩＤ（対象ユーザのＵＳＥＲ ＩＤ）、チャンネルコード、番組開始時刻（シーン／タグが属する番組の放送開始時刻）、番組終了時刻（シーン／タグが属する番組の放送終了時刻）、録画ＩＤ（機器内に録画されたシーン／タグが属する番組を一意に表すＩＤ）、番組ＩＤ（シーン／タグが属する番組データＩＤ／タグリストＩＤ）、番組タイトル（シーン／タグが属する番組データ／タグリストのタイトル）、更新時刻（録画リストを更新した時刻）を含む。録画番組リストは対応する端末ＩＤ、ＵＳＥＲ＿ＩＤに関連付けて書き込まれる。これにより、レコメンドサーバ２２はデータベースから端末ＩＤ、ＵＳＥＲ＿ＩＤに対応したデータ（チャンネル、開始時刻、終了時刻、番組名、録画ＩＤ）を取得することができる。

ブロックＢ１００３で、比較データ（Ａ）内のチャンネルが録画番組リスト（Ｂ）内に含まれているか否かを判定する。Ｙｅｓの場合は、ブロックＢ１００４で、比較データ（Ａ）と録画番組リスト（Ｂ）とで開始時刻が一致しているか否かを判定する。一致している場合は、ブロックＢ１００５で、両者は同一番組であると判定し、その時の録画ＩＤを記録し、処理を終了する。開始時刻が一致しない場合は、ブロックＢ１０１０で、「該当する録画番組が無い」と判断し、処理を終了する。

ブロックＢ１００３で、比較データ（Ａ）内のチャンネルが録画番組リスト（Ｂ）内に含まれていないと判定されると、比較データ（Ａ）を他サーバから取得した場合はブロックＢ１００６で、比較データ（Ａ）側の番組情報を取得する。具体的には、ＥＰＧサーバあるいはレコメンドサーバ２２内にあるＥＰＧデータベースにチャンネル（Ａ）と開始時刻（Ａ）を送信し、レコメンドサーバ２２内のデータベースから番組管理コード、番組管理枝番、終了時刻（Ａ）を受信する。

ブロックＢ１００７で、録画番組リスト（Ｂ）側の番組情報を取得する。具体的には、ＥＰＧデータベースにチャンネル（Ｂ）と開始時刻（Ｂ）を送信し、レコメンドサーバ２２内のデータベースから番組管理コード、番組管理枝番、終了時刻（Ｂ）を受信する。

ブロックＢ１００８で、番組管理コード、番組管理枝番、開始終了時刻が一致するかを判定する（時刻の秒の位は無視する）。一致する場合は、ブロックＢ１００５へ進み、一致しない場合は、ブロックＢ１００９へ進み、録画番組リストの番組分だけ処理が実行されたか否かを判定する。否の場合は、ブロックＢ１００７に戻り、イエスの場合は、ブロックＢ１０１０へ進む。

これにより、クライアント端末１０で録画されていないおすすめシーンを提示することが防止され、おすすめシーンのうち、クライアント端末１０で既にＰＶＲ録画されている番組のみを提示することができる。

録画番組の既録画判定処理の他の例を図１１のフローチャートを参照して説明する。図１１は時間、複数チャンネル（例えば、６チャンネルまでの任意のチャンネル）を指定して一定期間（例えば過去１５日分）全部の番組を録画する（タイムシフト録画）場合である。

ブロックＢ１１０１で、レコメンドサーバ２２はおすすめシーンを含む番組を特定するための比較データ（Ａ）を、データベースのランキング表等から取得する。あるいは、他のサーバ（図１内、あるいは図示しない外部のサーバ)から、比較データ（Ａ）を取得する。この場合、具体的には、ＵＳＥＲ＿ＩＤ、端末ＩＤ、チャンネル、開始時刻を取得する。

ブロックＢ１１０２で、タイムシフト録画設定情報（Ｂ）を取得する。具体的には、履歴収集サーバ２４で取得し、レコメンドサーバ２２内のデータベースに保存されているタイムシフト録画設定情報を取得する。レコメンドサーバ２２は履歴収集サーバ２４から該当機器のタイムシフト録画設定情報を取得する。タイムシフト録画設定情報は設定変更時と１日１回、クライアント端末１０から送信される。レコメンドサーバ２２はデータベース内にタイムシフト録画設定情報を書き込む。タイムシフト録画設定情報は端末ＩＤ（対象機器のＩＤ）、タイムシフト実行時間リスト（どの時間帯がタイムシフト録画されたか）、更新時刻（録画リストを更新した時刻）、チャンネルコードリスト（タイムシフト録画の対象のチャンネルコードのリスト）、録画済み最古時間（各チャンネルで録画済み最古時間）を含む。タイムシフト設定情報は対応する端末ＩＤに関連付けて書き込まれる。これにより、レコメンドサーバ２２はデータベースから端末ＩＤに対応したデータ（タイムシフト録画設定情報）を取得することができる。

ブロックＢ１１０３で、タイムシフト再生可能時刻を算出する。これは、現在時刻と更新時刻との差から、録画済み最古時間を算出し、各チャンネルの内一番現在に近いものを「再生可能時刻」とする。なお、複数のチャンネル全部で連続して録画されていると仮定し、最古再生時刻は各チャンネル同じとする。

ブロックＢ１１０４で、他サーバからの要求があった場合のみ比較側（Ａ）番組情報を取得する。ＥＰＧサーバあるいはレコメンドサーバ２２内のＥＰＧデータベースにチャンネル（Ａ）と開始時刻（Ａ）を与え、データベースから番組管理コード、番組管理枝番、終了時刻（Ａ）を受け取る。

ブロックＢ１１０５で、「再生可能時刻」とタイムシフト実行時間リスト内に開始、終了時刻が含まれているか否かを判定する。含まれていない場合は、ブロックＢ１１１０で、「おすすめシーンを含む番組に該当する録画番組が無い」（該当フラグ＝０）と判断し、処理を終了する。

ブロックＢ１１０５で、「再生可能時刻」とタイムシフト実行時間リスト内に開始、終了時刻が含まれている場合は、ブロックＢ１１０６で比較データ（Ａ）内のチャンネルがタイムシフト録画設定情報（Ｂ）内に含まれているか否かを判定する。含まれている場合は、ブロックＢ１１０７で、同一番組である（おすすめシーンを含む番組に該当する録画番組がある）と判定し、チャンネル（Ａ）と開始時刻を記録して、処理を終了する。

ブロックＢ１１０６で比較データ（Ａ）内のチャンネルがタイムシフト録画設定情報（Ｂ）内に含まれていない場合は、ブロックＢ１１０８で、比較データ（Ａ）の番組情報に該当する放送局リスト（Ｃ）を取得する。ＥＰＧデータベースに番組管理コードと番組管理枝番（Ａ）を与え、データベースからチャンネル、開始時刻、終了時刻のリストを受け取る。

ブロックＢ１１０９で、チャンネル（Ｂ）がチャンネル（Ｃ）に含まれ、かつ、その時の開始、終了時刻（Ｃ）と開始、終了時刻（Ａ）とが一致するか否かを判定する。一致する場合は、ブロックＢ１１０７で、同一番組であると判定し、その時のチャンネルと開始時刻を記録して、処理を終了する。一致しない場合は、ブロックＢ１１１０で、該当無しと判断し、処理を終了する。

これにより、クライアント端末１０で録画されていないおすすめシーンを提示することが防止され、おすすめシーンのうち、クライアント端末１０で既に録画されている番組のみを提示することができる。

次に、メタデータが作成されている主要都市以外の地域（地方）のユーザに対するおすすめシーンの番組情報の充実化について説明する。地方で放送される番組についてのメタデータは作成されていない。しかし、地方で放送され、録画された番組ＹＹが主要都市で放送された番組ＸＸと同一であると判断できれば、ある地域で放送された番組ＸＸの番組情報（メタデータ）と他の地域で放送された番組ＹＹとを紐付けることができ、その結果、メタデータが作成されていない東京、大阪、名古屋以外の地域で放送された番組の番組情報の充実化を実現できる。第２地域（地方）の番組のリッチなメタデータ以外のプアな番組情報（例えばＥＰＧデータ）と第１地域（主要都市）の番組のリッチな番組情報（メタデータ）について、それらの番組が同一であると判断された場合に、第２地域の番組のプアな番組情報を、第１地域の番組のリッチな番組情報で補完することができる。

同一番組検索処理の例を図１２のフローチャートを参照して説明する。

ブロックＢ１２０１で、レコメンドサーバ２２はおすすめシーンを含む番組（Ａ）が、特定のクライアント端末で利用できるか判定するため、他のサーバあるいはクライアント端末から、比較データ（Ａ）を受信する。具体的には、ＵＳＥＲ＿ＩＤ、端末ＩＤ、番組（Ａ）のチャンネル、番組（Ａ）の開始時刻、クライアント端末(端末ＩＤ)のチャンネルリスト（Ａ）を取得する。

ブロックＢ１２０２で、他サーバからクライアント端末(端末ＩＤ)のチャンネルリストが取得出来たか判定し、取得できた場合は、クライアント端末(端末ＩＤ)のチャンネルリストをチャンネルリスト（Ｂ）とする。取得できなかった場合は、ブロックＢ１２０３で、チャンネルリスト（Ｂ）を取得する。具体的には、履歴収集サーバ２４から取得し、レコメンドサーバ２２内のデータベースに保存している端末ＩＤのチャンネルリスト（チャンネルリスト（Ｂ））を取得する。レコメンドサーバ２２は履歴収集サーバ２４から該当機器のチャンネルリストを取得する。チャンネルリストは１日１回、あるいはチャンネルスキャンが行われた時に、クライアント端末１０から送信される。レコメンドサーバ２２はデータベース内にチャンネルリストを書き込む。チャンネルリストは端末ＩＤ（対象機器のＩＤ）、更新時刻（リストを取得した時刻）、チャンネルコードリストを含む。

ブロックＢ１２０５で、比較側番組（Ａ）の情報を取得する。レコメンドサーバ２２内のデータベースに番組（Ａ）のチャンネル（チャンネル（Ａ））と番組（Ａ）の開始時刻（開始時刻（Ａ））を与え、データベースから番組管理コード、番組管理枝番、終了時刻（Ａ）を受け取る。

ブロックＢ１２０６で比較データ（Ａ）内のチャンネル（Ａ）がチャンネルリスト（Ｂ）内に含まれているか否かを判定する。含まれている場合は、同一番組があることは自明であるため、ブロックＢ１２０９で、その時のチャンネルと開始時刻、終了時刻を記録して、処理を終了する。

ブロックＢ１２０６で比較データ（Ａ）内のチャンネルがチャンネルリスト（Ｂ）内に含まれていない場合は、ブロックＢ１２０７で、該当放送局リスト（Ｃ）を取得する。レコメンドサーバ２２内のデータベースに番組管理コードと番組管理枝番を与え、データベースからチャンネル、開始時刻、終了時刻のリストを受け取る。

ブロックＢ１２０８で、チャンネル（Ｂ）がチャンネル（Ｃ）と一致し、かつ、その時の開始、終了時刻（Ｃ）と開始、終了時刻（Ａ）とが一致するか否かを判定する。一致する場合は、ブロックＢ１２０９で、おすすめシーンを含む番組（Ａ）とチャンネル（Ｃ）の番組（Ｃ）が同一番組であると判定し、その番組（Ｃ）のチャンネルと開始終了時刻を回答して、処理を終了する。一致しない場合は、ブロックＢ１２１０で、該当無しと回答し、処理を終了する。

このように、おすすめシーンを含む番組の番組情報に関して、クライアント端末の所在地の番組情報が存在しない場合でも、同一の内容の他地域の番組情報を利用することで、おすすめシーンの番組情報を提供することができる。

レコメンドサーバで使用するデータベース構造を以下に示す。

おすすめシーン：おすすめシーンのカテゴリを管理するテーブル
ランキングデータ：集計したランキングを格納するテーブル
お気に入りシーン：お気に入りへの登録シーン／タグを格納するテーブル
友人からの推薦シーン：友人の推薦シーンを記録するテーブル
検索キーワード履歴：検索されたキーワードを記録するテーブル
登録キーワード：登録された検索キーワード／クエリを記録するテーブル
ＨＯＴワード：ＨＯＴワードを記録するテーブル
録画番組：録画番組を記録する。

タイムシフト録画設定情報：タイムシフト録画の設定情報を記録する。

チャンネルリスト：機器のチャンネル情報を記録する。

ＥＰＧ情報：所定のＥＰＧデータを記録する。

（検索サーバ２６の構成）
検索サーバ２６のモジュール構成は検索サーバ・フロントエンド、検索サーバ・バックエンド、メタデータ用データベースからなる。検索サーバ・フロントエンドはメタデータサーバ２０からのリクエストに応じて、キーワード検索の検索結果を返す。検索サーバ・バックエンドはメタデータデータベースの番組情報より検索用インデックステーブルを作成する。メタデータ用データベースはメタデータ作成サーバ３０から取得した番組放送履歴データとタグリストサーバ２８へ登録したタグリストの情報が登録される。

メタデータサーバ２０から検索サーバ２６へのリクエストはＨＴＴＰのＰＯＳＴメソッドが使用される。検索サーバ２６からメタデータサーバ２０へのレスポンスはＪＳＯＮ形式で送信される。文字コードはＵＴＦ−８が使用される。

検索サーバ２６がクライアント端末２０に提供するＡＰＩはシーン検索と、シーン検索（検索件数の取得）である。

シーン検索は与えられた単語に対し、インデックステーブルに登録された単語との完全一致、前方一致で検索を行う。例えば、検索の対象となる文章に「直径２メートルの新型風力発電機が公開された。微量の風で回転し発電する。」とあった場合、インデックステーブルには「２メートル、新型風力発電機、発電」という単語が登録されており、これらの語句に対する完全一致、前方一致での検索を行う。

タグ名を検索するキーワードはスペースで区切られ
・＜検索語＞
・＜ａｎｄ 検索語＞
・＜ｎｏｔ 検索語＞
のいずれかに解釈される。ａｎｄ、ｎｏｔのいずれも頭につかない場合はａｎｄとして解釈される。

また、検索後の先頭についてはｎｏｔは指定できない。

検索結果のソート順は番組放送日の新しい順、チャンネル番号（チャンネルコード）の若い順、番組放送時間の新しい順、シーン開始時間の古い順にソートされる。レコメンドサーバ２２による地方局の時差ネット番組の同一判定により、放送日時の違う番組が同じ番組であると判定された場合、ソート順序は録画機器側での時刻順にはならない。また、ソート順序はより多くの検索語にマッチしたものを先に出すようにしてもよい。

タグリストについては、タグリスト名が検索にヒットした場合はタグリスト内のタグがすべて検索結果として返り、タグ名が検索にヒットした場合はそのタグのみが検索結果として返る。

ＣＭが検索結果に含まれる場合は、ｓｉｄ（シーンＩＤ）には一連のＣＭをまとめたもののｓｉｄが入る。

検索に必要なデータベースの構造は以下である。

キーワードテーブルはキーワード、シーンＩＤ、番組ＩＤ、ＣＭＩＤ、タグリストＩＤ、チャンネルコード、放送日時を格納する。

前回アップデート日時保存テーブルは前回アップデート日時を格納する。

タグリストキャッシュテーブルはタグリストＩＤ、タグリストサブＩＤ、タグリスト名、タグ名、放送日時、アップデート日時を格納する。

検索履歴テーブルはキーワード、前回問合せ日時、検索回数を格納する。

メタデータに対して知識処理を行うことにより、メタデータのシーン情報のうちの一部（ヘッドライン、メモ）からキーワードを抽出する。キーワード抽出処理例を以下に示す。

＜メタデータ記述情報＞
［施設］「○○球場」で名物の［商品］「○○カレー」を紹介。製造しているのは大阪府大阪市の食品加工メーカー。様々なご当地カレーを開発・製造し、業績も急成長、売り上げは１０倍になった。千葉県産「△△牛」と無添加のみそを使って開発した［商品］「千葉牛味噌カレー」を紹介。［出演］ｘｘｘｘ［コメント］ｙｙｙｙ（食品加工メーカー・常務）、ｚｚｚｚ（企画会社・社長）
＜キーワード抽出＞
施設、甲子園球場、名物、製造、大阪府大阪市、食品、加工、メーカー、ご当地、開発、 業績、 急成長、 売り上げ、 １０倍、 無添加、 みそ、 千葉牛味噌カレー、 コメント、 常務、 会社、 社長
＜人名抽出＞
千葉県産、ｘｘｘｘ、ｙｙｙｙ、ｚｚｚｚ
検索サーバ２６は人名、商品等のキーワードによる検索要求をクライアント端末１０から受信し、そのキーワードに応じたシーン情報、タグリストをクライアント端末１０に提示する。なお、検索結果はそのまま提示するのではなく、検索要求を送信したユーザが実際に録画しているシーンに絞って、クライアント端末１０に対して回答する。検索要求を送信したクライアント端末１０が実際に録画しているか否かは、レコメンドサーバ２２へ問い合わせを行い、その結果を受信することで知ることができる。レコメントサーバ２２は情報収集サーバ２４から各種ランキング、既録画（録画済み）判定、他地域の同一番組検索のための情報を取得する。そのため、レコメントサーバ２２にも情報収集サーバ２４から取得した録画履歴情報があり、検索サーバ２６はレコメントサーバ２２から録画履歴情報を取得することも出来る。これにより、ユーザが視聴不可能な番組のシーン情報が検索結果に含まれることが防止される。

検索結果の絞り込み法は２つあり、１つ目はキーワードによる検索要求をクライアント端末１０から受信すると、メタデータ、シーン情報、タグリスト全体から、そのキーワードに応じたシーンを検索した上で、検索結果とされたシーンが、検索要求を送信したクライアント端末において視聴可能か否かをレコメンドサーバ２２に問い合わせで、絞り込みを行う方法である。この絞り込み方法のフローチャートを図１３に示す。

ブロックＢ１３０１に示すようにＷｅｂ ＡＰＩからＮ件目からｎ件検索の要求を受けると、処理が開始し、ブロックＢ１３０２で、ある地域（例えば関東）のインデックステーブルへｘ件の問合せを出す。ｘは、録画済み番組の絞り込みをすることにより検索結果のシーン数が減ってしまうために、Ｎ＋ｎ件目までの結果を取得するために予め何件検索しておけばよいかが分からないため、例えばｘ＝５０件等、予め適当に定める。問合せ結果であるシーンが得られると、ブロックＢ１３０３で、レコメンドサーバ２２に対してそのシーンが既録画であるか否かを問い合わせる。ブロックＢ１３０４で、上記地域のインデックステーブルへＭ件以上問い合わせたか否かを判定する。Ｍは、録画済み番組絞込みを行う前の検索結果が膨大にあり、絞り込んで何も残らない場合、問合せのループ回数が膨大になってしまうため、問合せを打ち切るために例えばＭ＝１０００件等、予め適当に定める。ノーの場合は、ブロックＢ１３０５で、Ｎ＋ｎ件の検索結果が得られたか否かを判定する。ノーの場合は、ブロックＢ１３０２に戻る。ブロックＢ１３０４でイエスの場合、あるいはブロックＢ１３０５でイエスの場合、ブロックＢ１３０６で、メタデータテーブル、タグリストテーブルへ問合せる。ブロックＢ１３０７で、検索結果をメタデータサーバ２０へ返し、処理を終了する。

２つ目の検索結果の絞り込み法は、キーワードによる検索要求をクライアント端末１０から受信すると、その検索要求を行ったユーザが視聴可能な番組のみに対応するメタデータ、シーン情報、タグリストから、そのキーワードに応じたシーンを検索する方法である。検索要求を送信したユーザにとって視聴可能な番組はレコメンドサーバからユーザの録画番組一覧の番組情報を貰ってくることによって特定できる。

次に、検索サーバ２６の他の動作例を説明する。上述したように、検索サーバ２６はクライアント端末１０で録画している録画番組の中から検索条件にあったシーン情報を探すが、メタデータが作成されていない地域では検索が不十分となる可能性がある。メタデータが作成されている地域では録画番組の番組情報はメタデータが使われるので、情報量が多いが、メタデータが作成されていない地域では録画番組の番組情報の情報量は無い、あるいはあったとしても非常に少ない。そのため、検索条件に合っているにも関わらず、ヒットしないシーンが存在してしまう。これを防ぐために、検索サーバ２６が検索する録画番組一覧はクライアント端末１０が存在する地域の番組情報ではなく、メタデータが作成されている地域の同じ内容の番組の番組情報に置き換えてから検索を行う。この置き換えは図１２で示したレコメンドサーバ２２の同一番組検索処理と同様である。しかし、ここでは、図１２において既に同一番組の検索が行われているので、この検索結果から作成した変換テーブル（第１地域の番組情報を第２地域の番組情報に変換）を用いることにより番組情報の置き換え(変換)を行っている。これにより、番組情報が無い、あるいは少ない地域であっても、検索条件に合ったシーン情報を見つけることが可能となる。

図１４は検索サーバ２６の他の動作例のフローチャートである。クライアント端末１０からの検索要求はメタデータサーバ２０を介して検索サーバ２６に与えられる。検索サーバ２６は履歴収集サーバ２４に対して録画番組一覧要求を送り、履歴収集サーバ２４から録画番組情報の一覧を受け取る。検索サーバ２６はレコメンドサーバ２２に対して変換テーブルを要求し、レコメンドサーバ２２から変換テーブルを受け取る。この後、検索サーバ２６はクライアント端末１０の録画番組の番組情報を、メタデータが作成されている他の地域で放送され、同一の内容の番組の番組情報へ変換してから、クライアント端末１０からの要求に応じたシーン情報をこの変換後の番組情報から検索する。検索結果（シーン情報リスト）はメタデータサーバ２０を介してクライアント端末１０に送られる。その後、検索サーバ２６は変換後の番組情報を元の番組情報に逆変換する。

番組情報の変換の一例を示す。

＜変換前＞ ＜変換後＞
20120729 G7FE00400 1230 → 20120729 G7FE04000”0” 1230
20120729 G7FC03052 1230 → 20120729 G7FE04000”1” 1230
この例では、番組情報の最初の８桁は年月日、次の９桁は放送地域、チャンネルを示す識別子であるチャンネルコード、次の４桁は開始時刻を示す。なお、変換前の番組情報がメタデータが作成されている地域の情報である場合は、変換後も同じ番組情報である。変換された番組情報であるか否かを識別するために、チャンネルコードの末尾に１桁の変換済みフラグを付け足す。１行目の番組情報はフラグが“０”であるので、未変換を示し、２行目の番組情報は７ＦＣ０から７ＦＥ０に変換されているので、フラグが“１”である。なお、ＣＭの場合、地域が異なれば、その内容もほぼ異なるので、このフラグが“１”のものは検索対象から除く。同様な理由で、一地方の番組と同一の内容の他の地方の番組を検索する際も、ＣＭは検索対象に含めない。また、一地方のＣＭの番組情報を他の地方の番組情報に変換する際も、ＣＭは対象に含めない。

検索サーバ２６は検索用のインデックスを１つ増やすことも考えられる。これにより、ラーメンとかカレーという個々のメニューのキーワードではなく、グルメという上位概念のキーワードで検索を可能となる。シーン情報リスト、タグリスト等で、ラーメン、カレーといったキーワードがあった場合には、さらにグルメといったキーワード（カテゴリー）を追加する。あるいは、キーワードのインデックスを作るときに、カテゴリ名を追加する。

（履歴収集サーバ２４の構成）
履歴収集サーバ２４は各クライアント端末１０の操作履歴、視聴履歴を収集して蓄積し続ける。これにより、各クライアント端末１０のユーザがどの番組を視聴したのか、録画したのかの情報が集積される。操作履歴、視聴履歴を蓄積するためには、クライアント端末１０から履歴収集サーバ２４へ情報をアップロードする必要があるが、ユーザの操作毎に無制限にアップロードすると、アップロードが集中してネットワークに過度の負荷がかかる可能性がある。特に、ＣＭ時にチャンネル切換をする傾向があり、ＣＭ時に操作履歴が集中してアップロードされる。ユーザの操作履歴・視聴履歴のアップロードをイベントドリブン的に行う（操作毎にアップロードする）と、周期は短くなり、リアルタイム性は高まるが、情報の錯誤が起こり得る。逆に、ユーザの操作履歴・視聴履歴のアップロードを一括的に行う（複数の操作を纏めてアップロードする）と、周期は長くなり、リアルタイム性は低いが、情報の錯誤が起こりにくい。このため、履歴の種類に応じてアップロードの周期を設定することにより、ネットワークに過度の負荷がかかることを防止できる。本実施形態では、履歴項目毎にアップロードのタイミングを次のように決めている。

アップロードする履歴項目は予約カテゴリの視聴予約と録画予約と、録画カテゴリの番組録画と、編集カテゴリの録画番組編集と、視聴カテゴリのライブ視聴とＰＶＲ視聴・タイムシフト視聴と、その他カテゴリの設定情報を含む。

予約カテゴリの視聴予約の通信トリガ(アップロードタイミング)は予約追加／変更、予約削除時である。予約一括通知は逐次／１日１回である。予約カテゴリの録画予約の通信トリガは予約追加／変更、予約削除時である。予約一括通知は逐次／１日１回である。
録画カテゴリの番組録画の通信トリガは録画開始からランダム時間後、録画失敗時である。録画リスト一括通知は逐次／１日１回である。
編集カテゴリの録画番組編集の通信トリガはムーブ完了、ダビング完了、番組削除、属性変更時である。
視聴カテゴリのライブ視聴の通信トリガは１時間毎／視聴終了時である。視聴カテゴリのＰＶＲ視聴、タイムシフト視聴の通信トリガはＰＶＲ再生停止時、各番組終了、またはタイムシフト再生停止時である。
設定情報の通信トリガは機器登録／変更については逐次、機器登録解除については逐次、登録済み機器一括通知については１日１回、フォルダ設定通知については逐次／１日１回、タイムシフト設定通知については逐次／１日１回、受信可能チャンネル一括通知については逐次／１日１回である。

履歴収集サーバ２４からクライアント端末１０に対しては以下のＸＭＬレスポンスを返す。

次回サーバアクセス日時（次回のログ送信日時を指定する）
次回アクセス解禁日時（非定期アップロードに対しても、サーバの負荷分散のため、アクセス禁止期間を設定する。クライアント端末はここで指定された日時までアップロードしない。）
予約一括通知のように、短時間間隔（逐次）の履歴と、長時間間隔（１日１回）の履歴がとも存在する場合は、両者の一致を判定する。一致していない場合は、長時間間隔（１日１回）の履歴を優先する。

履歴収集サーバ２４からクライアント端末１０へ情報（例えば、録画番組一覧）を送信する際に、次回のサーバアクセス時刻、アクセス禁止期間等を一緒に通知する。

図１５はクライアント端末１０の画面表示の一例である。図１５はＳｃｅｎｅＰｌａｙの一例のおすすめシーンの今日のイチオシシーンの表示である。図示しないクライアント端末１０の画面にクラウドメニュー画面を表示し、クラウドメニュー画面からおすすめシーンが選択されると、図１５の画面に遷移する。ここでは、同時に５つまでのシーン情報が表示される。シーン情報は上下にスクロールすることにより、他のシーン情報も表示することができる。いずれかのシーン情報にカーソルを位置すると、プレビュー画面に当該シーンが再生されるとともに、プレビュー画面の下に当該シーンの詳細な番組情報が表示される。

以上説明したように、第１の実施形態によれば、外部から供給され、放送番組の詳細な内容を示すメタデータから番組のあるシーンの内容を示すシーン情報を作成し、ユーザにシーン情報を提供することにより、ユーザが番組を容易に選ぶことが出来る。また、メタデータからシーンの頭出し情報であるタグを作成することにより、タグにしか対応しない従前のクライアント装置でも本サーバを利用可能である。

シーン情報には番組放送履歴データ以外に商品データも含まれているので、クライアント端末から要求された番組情報を送信する際に、その番組情報に関連する商品情報等を併せて送信することもできる。

履歴収集サーバが各ユーザの視聴履歴・録画履歴の情報を蓄積しているので、各ユーザへのおすすめ情報を算出して、提示することができる。ユーザへおすすめするシーンが、そのユーザのクライアント端末で録画されているのか（視聴可能なのか）を確認して、録画されていないものを除外する、あるいは録画されているものをユーザへ提示することにより、ユーザの利便性が向上する。

メタデータは主要都市で放送される番組についてのみ作成されており、それ以外の地域で放送される番組についてはない。しかし、メタデータが作成されていない地方で放送された番組と同じ内容の番組がメタデータが作成されている地方で放送されているか否かを判定し、同じ内容の番組があれば、その番組の番組情報をメタデータが作成されていない地方で放送された番組の番組情報として使用することができ、メタデータが作成されていない地方で放送される番組の番組情報の充実化を実現できる。

検索結果のうち、クライアント端末で録画されている番組の情報のみに絞り込むことにより、ユーザの利便性が向上する。

履歴収集サーバは各クライアント端末からのアップロードタイミングを制限しているので、アップロードが集中してネットワークに過度の負荷がかかることが防止される。

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

システムの種々のモジュールはソフトウェアアプリケーションとしても、ハードウェアとしても、ソフトウェアモジュールとしても、一つ以上のコンピュータ上のコンポーネントとしても実現可能である。システムの各種モジュールは別々のモジュールとして示されているが、同一のロジックあるいはコードのいくつか、あるいは全てを共有してもよい。

１０…クライアント端末、２０…メタデータサーバ、２２…レコメンドサーバ、２４…履歴収集サーバ、２６…検索サーバ、２８…タグリストサーバ、３０…メタデータ作成サーバ、２０Ａ…コマンド（ＡＰＩ）処理部、２０Ｂ…メタデータ取得処理部、２０Ｃ…メタデータデータベース、２０Ｄ…タグリスト生成／登録処理部、２０Ｅ…シーン情報生成処理部、２０Ｆ…タグリスト取得処理部、２０Ｇ…検索処理部、２０Ｈ…おすすめ／お気に入り処理部、２０Ｉ…シーン情報送信部。

Claims (21)

1. コンテンツについての情報であるコンテンツ情報を提供するためのシステムであって、
   第１電子機器に記録されている１以上のコンテンツを特定可能な情報を記憶する記憶手段と、
   前記第１電子機器からのコンテンツ情報の要求に応答して、前記要求に従って選択されるコンテンツ情報のうち、前記第１電子機器に記録されているコンテンツに対応するコンテンツ情報を前記第１電子機器に提供する提供手段と、
   を具備する情報提供システム。
2. コンテンツは少なくとも１つのシーンを含み、
   コンテンツ情報は、コンテンツのシーンについての情報であるシーン情報を含み、
   前記第１電子機器からのコンテンツ情報の要求はシーン情報の要求を含み、
   前記記憶手段は、前記第１電子機器におけるコンテンツの録画履歴に基づいて、前記第１電子機器で記録されている少なくとも１つのシーンを特定可能な情報を記憶し、
   前記提供手段は、前記シーン情報の要求に従って選択されるシーン情報のうち、前記第１電子機器で記録されているシーンに対応するシーン情報を前記第１電子機器に提供する請求項１記載の情報提供システム。
3. 前記記憶手段は、前記第１電子機器からコンテンツの視聴履歴と、コンテンツの録画履歴とを受信するものであって、前記第１電子機器からコンテンツの視聴履歴を受信するタイミングと、コンテンツの録画履歴を受信するタイミングとが異なる請求項１記載の情報提供システム。
4. 前記提供手段は、前記第１電子機器からのコンテンツ情報の要求に応答して、該要求に応じたコンテンツ情報を選択した上で、選んだコンテンツ情報の中から前記第１電子機器で記録されているコンテンツに対応するコンテンツ情報を選択し、選択したコンテンツ情報を前記第１電子機器に提供する請求項１記載の情報提供システム。
5. 前記提供手段は、前記第１電子機器からのコンテンツ情報の要求に応答して、前記第１電子機器で記録されているコンテンツに対応するコンテンツ情報を選択した上で、選んだコンテンツ情報の中から該要求に応じたコンテンツ情報を選択し、該選択したコンテンツ情報を前記第１電子機器に提供する請求項１記載の情報提供システム。
6. 前記コンテンツ情報は、コンテンツが放送された地域を示す情報を含み、
   前記第１電子機器が位置する第１の地域で放送される第１のコンテンツと、前記第１の地域とは異なる第２の地域で放送される第２のコンテンツとが同一の内容である場合に、前記提供手段は、前記第１電子機器からのコンテンツ情報の要求に応答して前記第２のコンテンツに対応するコンテンツ情報が選択された場合、前記第１のコンテンツに対応するコンテンツ情報の少なくとも一部を前記第１電子機器に提供する請求項１記載の情報提供システム。
7. コンテンツに含まれる１以上のシーンについての情報であるシーン情報を提供するためのシステムであって、
   第１電子機器に記録されている１以上のシーンを特定可能な情報を記憶する記憶手段と、
   前記第１電子機器におけるコンテンツ又はシーンの視聴履歴又は録画履歴の少なくとも一方に基づいて選択されるシーン情報のうち、前記第１電子機器に記録されているシーンに対応するシーン情報を前記第１電子機器に提供する情報提供システム。
8. コンテンツについての情報であるコンテンツ情報を提供するための方法であって、
   他の電子機器に記録されている１以上のコンテンツを特定可能な情報を記憶することと、
   前記他の電子機器からのコンテンツ情報の要求に応答して、前記要求に従って選択されるコンテンツ情報のうち、前記他の電子機器に記録されているコンテンツに対応するコンテンツ情報を提供することと、
   を具備する情報提供方法。
9. コンテンツは少なくとも１つのシーンを含み、
   コンテンツ情報は、コンテンツのシーンについての情報であるシーン情報を含み、
   前記他の電子機器からのコンテンツ情報の要求はシーン情報の要求を含み、
   前記記憶することは、前記他の電子機器におけるコンテンツの録画履歴に基づいて、前記他の電子機器で記録されている少なくとも１つのシーンを特定可能な情報を記憶することを具備し、
   前記提供することは、前記シーン情報の要求に従って選択されるシーン情報のうち、前記他の電子機器で記録されているシーンに対応するシーン情報を前記他の電子機器に提供することを具備する請求項８記載の情報提供方法。
10. 前記記憶することは、前記他の電子機器からコンテンツの視聴履歴と、コンテンツの録画履歴とを受信することを具備し、前記他の電子機器からコンテンツの視聴履歴を受信するタイミングと、コンテンツの録画履歴を受信するタイミングとが異なる請求項８記載の情報提供方法。
11. 前記提供することは、前記他の電子機器からのコンテンツ情報の要求に応答して、該要求に応じたコンテンツ情報を選択した上で、選んだコンテンツ情報の中から前記他の電子機器で記録されているコンテンツに対応するコンテンツ情報を選択し、選択したコンテンツ情報を前記他の電子機器に提供することを具備する請求項８記載の情報提供方法。
12. 前記提供することは、前記他の電子機器からのコンテンツ情報の要求に応答して、前記他の電子機器で記録されているコンテンツに対応するコンテンツ情報を選択した上で、選んだコンテンツ情報の中から該要求に応じたコンテンツ情報を選択し、該選択したコンテンツ情報を前記他の電子機器に提供することを具備する請求項８記載の情報提供方法。
13. 前記コンテンツ情報は、コンテンツが放送された地域を示す情報を含み、
    前記他の電子機器が位置する第１の地域で放送される第１のコンテンツと、前記第１の地域とは異なる第２の地域で放送される第２のコンテンツとが同一の内容である場合に、前記提供することは、前記他の電子機器からのコンテンツ情報の要求に応答して前記第２のコンテンツに対応するコンテンツ情報が選択された場合、前記第１のコンテンツに対応するコンテンツ情報の少なくとも一部を前記他の電子機器に提供することを具備する請求項８記載の情報提供方法。
14. コンテンツに含まれるシーンについての情報であるシーン情報を提供するための方法であって、
    他の電子機器で記録されている１以上のシーンを特定可能な情報を記憶することと、
    前記他の電子機器におけるコンテンツ又はシーンの視聴履歴又は録画履歴の少なくとも一方に基づいて選択されるシーン情報のうち、前記他の電子機器で記録されているシーンに対応するシーン情報を前記他の電子機器に提供することを具備する情報提供方法。
15. コンピュータにより実行されるプログラムであって、前記プログラムは
    他の電子機器に記録されている１以上のコンテンツを特定可能な情報を記憶することと、
    前記他の電子機器からのコンテンツ情報の要求に応答して、前記要求に従って選択されるコンテンツ情報のうち、前記他の電子機器に記録されているコンテンツに対応するコンテンツ情報を提供することと、
    を具備するプログラム。
16. コンテンツは少なくとも１つのシーンを含み、
    コンテンツ情報は、コンテンツのシーンについての情報であるシーン情報を含み、
    前記他の電子機器からのコンテンツ情報の要求はシーン情報の要求を含み、
    前記記憶することは、前記他の電子機器におけるコンテンツの録画履歴に基づいて、前記他の電子機器で記録されている少なくとも１つのシーンを特定可能な情報を記憶することを具備し、
    前記提供することは、前記シーン情報の要求に従って選択されるシーン情報のうち、前記他の電子機器で記録されているシーンに対応するシーン情報を前記他の電子機器に提供することを具備する請求項１５記載のプログラム。
17. 前記記憶することは、前記他の電子機器からコンテンツの視聴履歴と、コンテンツの録画履歴とを受信することを具備し、前記他の電子機器からコンテンツの視聴履歴を受信するタイミングと、コンテンツの録画履歴を受信するタイミングとが異なる請求項１５記載のプログラム。
18. 前記提供することは、前記他の電子機器からのコンテンツ情報の要求に応答して、該要求に応じたコンテンツ情報を選択した上で、選んだコンテンツ情報の中から前記他の電子機器で記録されているコンテンツに対応するコンテンツ情報を選択し、選択したコンテンツ情報を前記他の電子機器に提供することを具備する請求項１５記載のプログラム。
19. 前記提供することは、前記他の電子機器からのコンテンツ情報の要求に応答して、前記他の電子機器で記録されているコンテンツに対応するコンテンツ情報を選択した上で、選んだコンテンツ情報の中から該要求に応じたコンテンツ情報を選択し、該選択したコンテンツ情報を前記他の電子機器に提供することを具備する請求項１５記載のプログラム。
20. 前記コンテンツ情報は、コンテンツが放送された地域を示す情報を含み、
    前記他の電子機器が位置する第１の地域で放送される第１のコンテンツと、前記第１の地域とは異なる第２の地域で放送される第２のコンテンツとが同一の内容である場合に、前記提供することは、前記他の電子機器からのコンテンツ情報の要求に応答して前記第２のコンテンツに対応するコンテンツ情報が選択された場合、前記第１のコンテンツに対応するコンテンツ情報の少なくとも一部を前記他の電子機器に提供することを具備する請求項１５記載のプログラム。
21. コンピュータにより実行され、コンテンツに含まれるシーンについての情報であるシーン情報を提供するためプログラムであって、前記プログラムは
    他の電子機器で記録されている１以上のシーンを特定可能な情報を記憶することと、
    前記他の電子機器におけるコンテンツ又はシーンの視聴履歴又は録画履歴の少なくとも一方に基づいて選択されるシーン情報のうち、前記他の電子機器で記録されているシーンに対応するシーン情報を前記他の電子機器に提供することを具備するプログラム。

Images