JP2014138223A - 番組情報通知装置、番組情報通知方法およびプログラム - Google Patents

Abstract

【課題】 話題性が大きな放送番組についての情報をユーザに通知することができる番組情報通知装置、番組情報通知方法およびプログラムを提供する。
【解決手段】 アプリケーションサーバ１は、話題性情報として番宣情報サーバ５から、放送番組の宣伝内容を示す番組宣伝情報を取得し、取得した番組宣伝情報に基づいて、放送番組の宣伝内容が、初回放送番組であること、または特別放送番組であることのいずれかの放送番組を、話題性を有する放送番組として決定する。決定した放送番組について、番組名、放送開始・終了時刻など番組に関する情報を、端末管理サーバ４を介してユーザ端末装置３に通知する。
【選択図】 図１

Description

本発明は、ユーザに対して放送番組に関する情報を通知する番組情報通知装置、番組情報通知方法およびプログラムに関する。

インターネット上では、特定のウェブサイトに対してユーザがコメントを投稿し、その投稿されたコメントを他のユーザが見ることができる。投稿されるコメントの中には、多種多様な内容があるが、その中でもテレビジョン放送番組（以下、単に「テレビ番組」ともいう）に対してコメントが投稿されることも多く、ユーザは、自分が視聴しているテレビ番組と同じ番組を視聴している他のユーザのコメントを見て楽しんだり、自分が視聴していないテレビ番組に対するコメントを見て、その番組に興味を持って後から視聴したりするという、新たなテレビ番組の視聴の仕方が、多くのユーザによって創り出されている。

テレビ番組は、録画している場合やオンデマンド放送、タイムシフト放送に対応している場合を除いて、放送時に見逃してしまうと、見ることができなくなる可能性が高い。ユーザは、自分が知らないところで他の多くの視聴者の間で盛り上がっているテレビ番組が放送されていたことを放送後に知った場合に、そのテレビ番組を視聴することはできないので、現在盛り上がっている番組があればユーザに通知する技術が提案されている。

特許文献１記載の放送受信装置は、視聴率を予め設定された値と比較して盛り上がりを検出し、盛り上がり番組が未視聴であれば、盛り上がり番組の存在について通知を行う。

特許文献２記載のテレビジョン装置は、視聴を中断した放送番組について、音量レベルや瞬間視聴率などを利用して盛り上がり度を検出し、検出した盛り上がり度が基準値よりも大きい場合には、視聴中断後に盛り上がったことをユーザに通知する。

特開２０１０−２６３５２７号公報 特開２０１０−１６１４８９号公報

特許文献１，２記載の技術は、盛り上がっている番組をユーザが見逃さないように通知するものであるが、通知を行う判断基準が固定値であるので、適切な通知ができない。たとえば、視聴率はテレビ番組の内容や放送時間帯によって平均的に高い番組、平均的に低い番組がある。ニュース番組やゴールデンタイムの放送番組は総じて視聴率が高く、深夜放送の番組は総じて視聴率が低い。盛り上がっている番組であるかどうかを判断する場合に、固定値で判断すると、視聴率が平均的に高い番組は、常に固定値を超えて盛り上がっていると判断されることになり、深夜放送の番組は、実際には盛り上がっているようなものであっても、固定値を超えることがないので、盛り上がっていると判断される可能性が極めて低い。

ユーザが通知を望む番組は、番組中でハプニングが生じたり、特別な出演者が出演したり、放送内容が通常とは異なる特別な放送内容であったり、話題性の大きな番組であり、話題性の有無および大小は、固定値などの絶対的な基準値によって判断することはできない。

また、話題性が大きなテレビ番組を予測することができれば、放送開始前にユーザに通知することもできるが、話題性が大きな番組を予測して通知する技術はない。

本発明の目的は、話題性が大きな放送番組についての情報をユーザに通知することができる番組情報通知装置、番組情報通知方法およびプログラムを提供することである。

本発明は、ユーザが所持するユーザ端末装置とデータ通信可能に構成される番組情報通知装置であって、
放送番組の話題性に関する話題性情報を外部装置から取得し、取得した話題性情報に基づいて話題性を有する放送番組を決定する決定部と、
前記決定部が決定した放送番組を特定するための特定情報を生成する情報生成部と、
前記情報生成部が生成した特定情報をユーザ端末装置に通知する通知部と、を有することを特徴とする番組情報通知装置である。

また本発明は、前記話題性情報は、放送番組の宣伝内容を示す番組宣伝情報であり、
前記決定部は、番組宣伝情報に基づいて、放送番組の宣伝内容が、初回放送番組であること、または特別放送番組であることのいずれかであれば、該放送番組を、話題性を有する放送番組として決定することを特徴とする。

また本発明は、前記情報生成部は、前記検出部が検出した初回放送番組または特別放送番組について、外部データベースを検索し、放送局名、放送日および放送時間帯の少なくともいずれか１つを取得し、取得した放送局名、放送日および放送時間帯の少なくともいずれか１つと放送番組名とを含む特定情報を生成することを特徴とする。

また本発明は、前記話題性情報は、予め定める投稿サーバ装置に投稿された、放送番組に関するコメント情報の投稿数であり、
前記投稿数の経時変化を記録した投稿数履歴を少なくとも１週分以上記憶し、記憶した投稿数履歴に基づいて、基準となる投稿数の経時変化を算出する基準算出部をさらに有し、
前記決定部は、現在時刻における投稿数と、前記基準算出部が算出した、現在時刻と同じ時刻における基準となる投稿数とを比較し、現在時刻における投稿数が基準となる投稿数よりも予め定める割合以上多いときは、現在時刻に放送している放送番組を、話題性を有する放送番組として決定することを特徴とする。

また本発明は、前記情報生成部は、前記決定部が決定した放送番組について、放送局名および放送番組名の少なくともいずれか１つを含む特定情報を生成することを特徴とする。

また本発明は、ユーザが所持するユーザ端末装置に番組情報を通知する番組情報通知方法であって、
番組情報通知装置が、放送番組の話題性に関する話題性情報を外部装置から取得し、取得した話題性情報に基づいて話題性を有する放送番組を決定する決定工程と、
番組情報通知装置が、前記決定工程で決定した放送番組を特定するための特定情報を生成する情報生成工程と、
番組情報通知装置が、前記情報生成工程で生成した特定情報をユーザ端末装置に通知する通知工程と、を有することを特徴とする番組情報通知方法である。

また本発明は、コンピュータを、上記の番組情報通知装置として機能させるためのプログラムである。

本発明によれば、決定部が、放送番組の話題性に関する話題性情報を外部装置から取得し、取得した話題性情報に基づいて話題性を有する放送番組を決定すると、情報生成部が、前記決定部が決定した放送番組を特定するための特定情報を生成し、通知部が、前記生成部が生成した特定情報をユーザ端末装置に通知する。

これにより、単にコメント投稿数や視聴率などの指標に基づいてユーザへの通知を行うのではなく、話題性を有する放送番組を決定して、ユーザに対して番組情報を通知することができる。

また本発明によれば、前記話題性情報は、放送番組の宣伝内容を示す番組宣伝情報であり、前記決定部は、番組宣伝情報に基づいて、放送番組の宣伝内容が、初回放送番組であること、または特別放送番組であることのいずれかであれば、該放送番組を、話題性を有する放送番組として決定する。

これにより、初回放送番組または特別放送番組など話題性が大きいと推測される放送番組について、番組宣伝情報から判断することにより、予めユーザに番組情報を通知することができる。

また本発明によれば、前記情報生成部は、前記検出部が検出した初回放送番組または特別放送番組について、外部データベースを検索し、放送局名、放送日および放送時間帯の少なくともいずれか１つを取得し、取得した放送局名、放送日および放送時間帯の少なくともいずれか１つと放送番組名とを含む特定情報を生成する。

ユーザは、通知された特定情報を見ることにより、話題性が大きいと推測される放送番組を簡単に知ることができる。

また本発明によれば、前記話題性情報は、予め定める投稿サーバ装置に投稿された、放送番組に関するコメント情報の投稿数であり、基準算出部が、前記投稿数の経時変化を記録した投稿数履歴を少なくとも１週分以上記憶し、記憶した投稿数履歴に基づいて、基準となる投稿数の経時変化を算出し、前記決定部は、現在時刻における投稿数と、前記基準算出部が算出した、現在時刻と同じ時刻における基準となる投稿数とを比較し、現在時刻における投稿数が基準となる投稿数よりも予め定める割合以上多いときは、現在時刻に放送している放送番組を、話題性を有する放送番組として決定する。

これにより、過去のコメント情報の投稿数よりも予め定める割合以上多いコメント情報が投稿された放送番組について、現在盛り上がりが大きく話題になっている放送番組としてユーザに通知することができる。

また本発明によれば、前記情報生成部は、前記決定部が決定した放送番組について、放送局名および放送番組名の少なくともいずれか１つを含む特定情報を生成する。

ユーザは、通知された特定情報を見ることにより、現在話題になっている放送番組を簡単に知ることができる。

また本発明によれば、決定工程で、放送番組の話題性に関する話題性情報を外部装置から取得し、取得した話題性情報に基づいて話題性を有する放送番組を決定すると、情報生成工程で、決定された放送番組を特定するための特定情報を生成し、通知工程で、生成された特定情報をユーザ端末装置に通知する。

これにより、単にコメント投稿数や視聴率などの指標に基づいてユーザへの通知を行うのではなく、話題性を有する放送番組を決定して、ユーザに対して番組情報を通知することができる。

本発明によれば、コンピュータを、上記の番組情報通知装置として機能させるためのプログラムとして提供することができる。

番組情報通知システムＳ１の構成を示す概略図である。 番宣情報テーブル１００の構成を示す図である。 管理者端末装置２に送信される報告用電子メールの文面２０の一例を示す図である。 管理者端末装置２に表示される登録用画面３０の例を示す図である。 初回放送および特番の通知を受け取ったユーザ端末装置３の動作を説明する図である。 番組情報通知システムＳ２の構成を示す概略図である。 コメント投稿数の変動記録処理を示すフローチャートである。 ユーザ端末装置３への通知の要否の判断について説明するための図である。 ユーザ端末装置３への通知処理を示すフローチャートである。 コメント投稿数が特に多い放送番組の通知を受け取ったユーザ端末装置３の動作を説明する図である。 過去に盛り上がった番組の通知を受け取ったユーザ端末装置３の動作を説明する図である。

本発明は、ユーザが所持するユーザ端末装置に対して、話題性のある放送番組について通知するサービスを提供するための番組情報通知装置である。ユーザ端末装置には、サービスを受けるためのアプリケーションソフトウェア（以下、「アプリ」）が予めインストールされており、番組情報通知装置は通知の対象となるユーザ端末装置を認識することができる。

本発明において、話題性のある放送番組とは、たとえば、mixi（登録商標）、Facebook（登録商標）、Twitter（登録商標）などの、各ユーザがそれぞれコメントを投稿できるＳＮＳ（Social Networking Service）において、番組に関する投稿数が一時的に多くなる番組であり、ユーザにとっては他のユーザと話題を共有したいので、見逃したくないと思うような放送番組である。

このような放送番組は、単に視聴者数が多いとか、視聴率が高いといった指標では推し量ることが難しい。どのような放送番組が、話題性が大きくなる番組であるかを分析し、話題性が大きくなる放送番組についてユーザ端末装置に通知する必要がある。

本願発明者は、話題性が大きくなる放送番組について、以下の２種類に大別できるものと考えている。

（Ａ）単発的に放送される特別放送番組、いわゆる特番、および定期的に放送されるレギュラー放送番組のうちの第１回目の放送である初回放送番組
（Ｂ）放送中にハプニングが発生するなどして、コメントの投稿数が同じ曜日の前週または前々週などの投稿数と比較して特に多い放送番組

＜第１実施形態＞
まずは、（Ａ）の初回放送および特番について、ユーザに通知する場合について説明する。

図１は、番組情報通知システムＳ１の構成を示す概略図である。番組情報通知システムＳ１は、本発明の番組情報通知装置であるアプリケーションサーバ１、管理者端末装置２、ユーザ端末装置３、端末管理サーバ４および番宣情報サーバ５を含み、番組情報通知サービスを実施するためのシステムである。なお、これらアプリケーションサーバ１、管理者端末装置２、ユーザ端末装置３、端末管理サーバ４および番宣情報サーバ５は、サーバ機、パーソナルコンピュータ、携帯端末装置など汎用のハードウェアによって容易に実現可能であるので、詳細なハードウェア構成については省略する。

ユーザ端末装置３には、番組情報通知を受け取るためのアプリがインストールされており、アプリをインストールしたユーザ端末装置３は、それぞれが端末ＩＤなどにより端末管理サーバ４に登録される。本発明において、ユーザ端末装置３への通知は、アプリケーションサーバ１から端末管理サーバ４へと通知要求を送信し、要求を受けた端末管理サーバ４が、各ユーザ端末装置３に対して、通知要求の要求内容に応じた通知を行う。

番宣情報サーバ５は、番組宣伝情報を提供するサーバであり、アプリケーションサーバ１は、放送番組名および放送局名を含む番組宣伝情報を番宣情報サーバ５から定期的に受信する。受信した番組宣伝情報は、アプリケーションサーバ１の記憶部１ａに蓄積される。

管理者端末装置２は、アプリケーションサーバ１と直接通信可能な端末装置であり、本発明の番組情報通知サービスを提供するサービス提供者によって操作される。

アプリケーションサーバ１は、情報通知／登録アプリ１ｂを実行し、番組検出プログラム１ｃの実行、管理者端末装置２との通信、端末管理サーバ４への通信要求、番宣情報サーバ５からの番組宣伝情報の受信などを総合的に管理する。

アプリケーションサーバ１は、番宣情報サーバ５から番組宣伝情報を受信すると、放送番組名および放送局名とを含む番宣情報テーブルを更新する。番宣情報テーブルは、アプリケーションサーバ１の記憶部１ａに記憶される。

図２は、番宣情報テーブル１００の構成を示す図である。番宣情報テーブル１００は、番組名１０１、報告設定１０２、開始時刻１０３、終了時刻１０４、局１０５およびカウント１０６を含む。番組名１０１は、番組宣伝情報に含まれる放送番組名であり、局１０５は、番組宣伝情報に含まれる放送局名である。この例では、放送局名は、各放送局に割り当てられたチャンネル番号によって示される。

番組宣伝情報を受信すると、番宣情報テーブル１００の番組名１０１に登録された放送番組に、受信した番組宣伝情報に含まれる放送番組名と同じ番組名があるかどうかを判断し、同じ番組名があれば、カウント１０６の値を１増加させる。同じ番組名が無ければ、番組名１０１に受信した放送番組名を新たに登録してカウント１０６の値を１とする。つまり、カウント１０６の値は、アプリケーションサーバ１が、番組名１０１に登録された放送番組名を含む番組宣伝情報を受信した回数を表している。カウント１０６の値が多ければ、それだけ番組宣伝情報に同じ放送番組名が含まれていることになり、放送局がその放送番組をどれだけ宣伝しようとしているかの指標となる。本発明では、特に宣伝に力が注がれている放送番組であって、初回放送番組または特別放送番組について、放送前に予めユーザに対して通知しようとするものである。

カウント１０６に登録されたカウント値が、予め定める閾値を超えると、ユーザに通知すべき放送番組であるとして、管理者端末装置２に対して報告する。報告はたとえば、放送番組名、放送局名などの情報を含む報告用電子メールを管理者端末装置２宛に送信する。

サービス提供者は、アプリケーションサーバ１から報告用電子メールを受信すると、放送番組名などから放送番組に関する情報として、放送開始時刻、放送終了時刻を調査し、放送開始時刻、放送終了時刻をアプリケーションサーバ１に登録する。さらに、ユーザ端末装置３に対して通知をするかどうか、通知する場合にはいつ通知するか、管理者端末装置２に対して通知するかどうか、通知する場合にはいつ通知するかなどの通知に関する情報も、管理者端末装置２を介してアプリケーションサーバ１に登録する。

管理者端末装置２を介してアプリケーションサーバ１に登録された各種情報は、必要に応じて番宣情報テーブル１００に登録される。放送開始時刻、放送終了時刻は、それぞれ開始時刻１０３および終了時刻１０４に登録される。

カウント値が大きい放送番組は、それだけ番組宣伝情報によって宣伝される頻度が高いことから、初回放送番組や特別放送番組などの話題性を有する放送番組である可能性が高いが、必ずしもカウント値が閾値を超えた番組の全てがユーザに通知すべき放送番組であるとは限らない。その場合は、サービス提供者が、管理者端末装置２からユーザへの通知が不要な番組であることを入力可能とすることが好ましい。

図３は、管理者端末装置２に送信される報告用電子メールの文面２０の一例を示す図である。報告用電子メールの文面２０には、報告用電子メールを管理者端末装置２に送信した日時を示す報告日２１、同じ放送番組について過去に報告用電子メールを送信していた場合に、初回の送信日時を示す初回報告日２２、放送番組の放送局名を示す放送局２３、放送番組名を示す番組名２４、放送番組を識別するための番組ＩＤ２５、カウント値を示す検出回数２６、放送開始時刻などを登録するための登録ページのＵＲＬを示す登録用ＵＲＬ２７および放送番組について検索するための検索ページのＵＲＬを示す検索エンジンＵＲＬ２８が記載されている。

管理者端末装置２を操作するサービス提供者のオペレータは、放送番組についての情報を外部の検索エンジンなどを利用して検索する。報告用電子メールの検索エンジンＵＲＬ２８には、予め検索キーとなる放送番組名と放送局名とがクエリパラメータとして指定され、リンクが設定されているので、オペレータは、検索エンジンＵＲＬ２８を選択するだけで簡単に放送番組に関する情報の検索を実行できる。

検索により、たとえば、放送局の公式サイトなどに、該当する番組の説明ページや、該当する番組の特設サイトなどが見つかれば、そのページまたはサイトに記載されている番組内容を確認することができる。

ページまたはサイトに記載された番組内容から放送開始時刻および放送終了時刻を確認すると、オペレータは、登録用ＵＲＬ２７を選択して登録用画面を管理者端末装置２に表示させる。登録用ＵＲＬ２７には、放送番組の番組ＩＤ２５と管理者端末装置２を操作するオペレータのＩＤ（管理者ＩＤ）とがクエリパラメータに含まれている。

図４は、管理者端末装置２に表示される登録用画面３０の例を示す図である。登録用画面３０には、番組ＩＤを入力するＩＤ入力領域３１、該当する番組の番組名を入力する番組名入力領域３２、放送開始時刻を入力する開始時刻入力領域３３、放送終了時刻を入力する終了時刻入力領域３４、該当する番組の公式サイトのＵＲＬを入力するＵＲＬ入力領域３５、該当する番組の出演者を入力する出演者入力領域３６、ユーザに知らせるべき内容があればメモとして入力するメモ入力領域３７、ユーザ端末装置３への通知タイミングを選択する通知タイミング選択領域３８および管理者端末装置２への通知を抑制する期間を選択する抑制期間選択領域３９が含まれる。

番組ＩＤ、放送局名、番組名は、登録用画面３０を表示した時点ですでに入力されているので、他の入力項目についてオペレータが各入力領域に必要事項を入力する。放送開始時刻および放送終了時刻ならびに公式サイトＵＲＬ、出演者およびメモなどの情報は、前述の検索によって確認した内容を入力すればよい。なお、入力済みの項目についてもオペレータの判断により、内容を変更することができる。

ユーザ端末装置３への通知タイミングは、放送開始時刻を基準として、放送前日の夜（１９時ごろ）、放送当日の朝（９時ごろ）、放送開始１時間前、放送開始１０分前など予め定められたタイミングの中から選択すればよい。また、放送開始時刻よりも前の任意の時刻を通知のタイミングとして入力可能としてもよい。

上記のようにカウント値が閾値を超えるとアプリケーションサーバ１から管理者端末装置２へ報告用電子メールが送信されるが、一度カウント値を超えたあとは、番組宣伝情報を受信し、カウント値が１増えるたびに毎回報告用電子メールを送信することになる。このような繰り返しの報告用電子メールの送信を避けるために管理者端末装置２への通知を抑制する期間を設定可能とすることが好ましい。また、抑制期間終了後に抑制期間終了時点のカウント値に初期の閾値を加算し、これを新たな閾値として利用する構成であってもよい。この構成によれば、抑制期間終了後に初期の閾値分のカウント値の増加があって初めて報告用電子メールが送信される。

抑制期間は、最初に報告用電子メールを送信した日を基準として、１カ月抑制、３カ月抑制、６カ月抑制、１年抑制、永久抑制など予め定められた期間の中から選択すればよい。また、任意の期間を抑制期間として入力可能としてもよい。

入力および選択した内容を確定すると、確定した内容に応じて、番宣情報テーブル１００の報告設定１０２、開始時刻１０３、終了時刻１０４の各項目が登録される。さらに確定後に入力確認電子メールを各管理者端末装置２に送信する構成とすることが好ましい。管理者が複数いる場合、各管理者端末装置２に対して入力確認電子メールを送信することで、ある番組についての入力が完了したことを他の管理者に伝えることができ、同じ番組について他の管理者が入力しようとする無駄を省く、もしくは入力済みの情報を他の管理者が確認するのに役立つ。

図２に示した例であれば、番組名「サンウォーズ」は、初回放送番組であり、開始時刻が２０１２年１１月１５日１３時００分、放送終了時刻が２０１２年１１月１５日１５時００分であり、すでに各項目が登録されているので管理者端末装置２への報告は３カ月抑制されている。番組名「ＢＢＢニュース」は、通年放送されるニュース番組であり、ユーザ端末装置３に対して通知する必要がない番組であるので、開始時刻、終了時刻が設定されておらず、管理者端末装置２への報告も不要（永久抑制）となっている。番組名「大海ドラマ」は、カウント値が閾値を超えていないので、管理者端末装置２に対して未報告である。番組名「Ｄスペシャル」は、特別放送番組であり、開始時刻が２０１２年１０月１３日２０時００分、放送終了時刻が２０１２年１０月１３日２２時００分であり、すでに各項目が登録されているので管理者端末装置２への報告は３カ月抑制されている。

以上のようにして、管理者端末装置２からサービス提供者が放送番組についての必要事項を登録すると、アプリケーションサーバ１は、端末管理サーバ４に対して、ユーザ端末装置３への通知要求を送信する。通知要求には、放送番組名、放送局名、放送開始時刻、放送終了時刻など、ユーザが放送番組を特定するための特定情報およびユーザ端末装置３へ通知を行う日時を示す通知時刻情報を含む。通知要求を受けた端末管理サーバ４は、通知時刻情報で示される日時になると、特定情報を各ユーザ端末装置３へと通知する。

なお、通知時刻に合わせて特定情報をユーザに通知するための制御は必ずしも端末管理サーバ４で行う必要はなく、通知時刻に合わせてアプリケーションサーバ１から端末管理サーバ４に、特定情報を含み通知時刻情報を含まない通知要求を送信し、通知要求を受信した端末管理サーバ４は、直ちに特定情報を各ユーザ端末装置３へ通知する構成であってもよい。さらには、管理者による登録が完了すると、直ちにアプリケーションサーバ１は端末管理サーバ４に、特定情報および通知時刻情報を含む通知要求を送信し、端末管理サーバ４は直ちにユーザ端末装置３に通知時刻情報および特定情報を通知する構成であってもよい。この場合、ユーザ端末装置３は受け取った通知時刻情報に応じてタイマー機構を設定し、通知時刻情報で示される日時になると、ユーザへの通知を行う。

図５は、初回放送および特番の通知を受け取ったユーザ端末装置３の動作を説明する図である。図５（ａ）は、ユーザ端末装置３の待機画面８を示し、待機画面８はユーザ端末装置３の状態を示すステータス領域８１を含む。通知を受けたユーザ端末装置３は通知に関連するアプリケーションのアイコン８２をステータス領域８１に表示する。アイコン８２を視認することにより通知があることを認識したユーザがステータス領域８１を画面下方向にドラッグすると図５（ｂ）に示す通知表示領域８３があらわれる。この通知表示領域８３には通知のより詳細な情報が表示され、さらに、ユーザが通知表示領域８３をタップするとアプリケーションが起動し、図５（ｃ）に示すアプリケーション画面８４が表示される。アプリケーション画面８４は、図４で入力された情報を元に構築され、通知に関する各種情報、情報を各種ＳＮＳに投稿するためのボタン８５、公式ページや視聴予約を行うためのリンク８６などを含む。

なお、視聴予約を選択すると、番組の放送開始時刻直前（たとえば１分前）に電子メールにて番組の放送開始を通知するための画面が表示される。さらに放送開始時刻直前に、アプリケーションの機能としてアラームが鳴る、あらかじめユーザ端末装置３と連携設定しているテレビジョン受像機の電源をオンにする、あらかじめユーザ端末装置３と連携設定している放送番組録画装置に録画予約をするなどの動作が可能な構成としてもよい。

ユーザは、ユーザ端末装置３に通知された特定情報を見ることで、初回放送や特別番組が放送されること、その放送日時などを予め知ることができる。

図１では、アプリケーションサーバ１、端末管理サーバ４および番宣情報サーバ５がそれぞれ１台のサーバ装置からなる３台のサーバ装置を含む番組情報通知システムの構成を示したが、処理能力の拡充や冗長性の確保のため、各サーバの機能をそれぞれ複数のサーバ装置で実現するような構成としてもよく、あるいは複数のサーバの機能を１台のサーバ装置で実現するような構成としてもよい。

＜第２実施形態＞
第１実施形態では、放送開始時刻などユーザ端末装置３に通知すべき放送番組に関する情報を管理者端末装置２から登録する構成としているが、本実施形態では、アプリケーションサーバ１が全ての情報について、自ら取得して登録する。

放送開始時刻および放送終了時刻の取得は、管理者端末装置２が行うのと同様に、アプリケーションサーバ１が、番組の公式サイトを検索し、公式サイトにアクセスして特定の文字列を検出して放送開始時刻、放送終了時刻を取得する。取得した放送開始時刻および放送終了時刻と、放送番組名および放送局名とを関連付けて記憶部１ａに記憶しておく。ユーザへの通知タイミングは、予めサービス提供者が、アプリケーションサーバ１に登録しておけばよい。第１実施形態と同様に、放送開始時刻を基準として、予め定められたタイミングの中から選択すればよく、放送開始時刻よりも前の任意の時刻を通知のタイミングとして入力可能としてもよい。

これにより、第２実施形態では、管理者端末装置２が不要となり、サービス提供者による情報の検索、検索した各種情報の入力操作なども全て不要となる。

＜第３実施形態＞
次に、（Ｂ）のコメント投稿数が特に多い放送番組について、ユーザに通知する場合について説明する。前述のように、コメント投稿数が、同じ時間帯の過去の投稿数に比べて一定の割合以上に多い番組は、放送中に何らかのハプニングが起こったり、特別なゲストが出演したりするなど、話題性の大きな放送番組である可能性が高い。しかしながら、このような番組は、放送前に予め特定することは難しいので、放送中に番組を検出し、速やかにユーザに対して通知することが望ましい。

ツイッターなどにおけるツイート（コメント）の投稿数は、たとえば１分ごとに計数することが可能であるので、現在放送中の番組に対する投稿数を、番組のいわゆる“盛り上がり度”として話題性の指標としてユーザに知らせるアプリなどは存在する。これまでのアプリが実行しているのは、リアルタイムで投稿数の変動を表示する、投稿数が一定数を超えると通知するなどでしかなく、視聴者が多く、常に多くのコメントが投稿されるような放送番組の場合は、常に盛り上がっている状態となり、ハプニングが起こった場合など通常の盛り上がりとは異なる大きな盛り上がりが生じていることまでは検出できず、ユーザに通知することはできない。また、常に多くのコメントが投稿される同じ番組について繰り返しユーザに通知すると、ユーザは通知に慣れてしまい、話題性のある番組を通知するという本来の通知の役目を果たせない。

本実施形態では、このようなコメント投稿数が突出して多く、通常よりも大きな盛り上がりが生じている放送番組について検出し、速やかにユーザに通知しようとするものである。

図６は、番組情報通知システムＳ２の構成を示す概略図である。番組情報通知システムＳ２は、本発明の番組情報通知装置であるアプリケーションサーバ１、ユーザ端末装置３、端末管理サーバ４および番組情報サーバ６を含み、番組情報通知サービスを実施するためのシステムである。なお、これらアプリケーションサーバ１、ユーザ端末装置３、端末管理サーバ４および番組情報サーバ６は、サーバ機、パーソナルコンピュータ、携帯端末装置など汎用のハードウェアによって容易に実現可能であるので、詳細なハードウェア構成については省略する。

ツイッターサービスへの投稿は他のＳＮＳに比べてハプニングに対する応答性が高く、本発明の目的に適した性質を持っているため、本システムでは、盛り上がりを示す指標としてツイッターサービスにおけるツイートの投稿数を利用する構成について説明するが、ツイート数に限らず他のＳＮＳにおける投稿数（電子掲示板への書き込み数なども含む）を利用したり、複数のＳＮＳにおける投稿数を総合したりしてもよい。

アプリケーションサーバ１が実行するツイート監視プログラム１ｄは、ツイッターサーバ７から連続的に送られてくるツイートから放送局名など放送局に応じた特定の単語を含むツイートの数を計数し、たとえば１分ごとに、記憶部１ａに記憶する。

ツイッターサーバ７に蓄積されるコメントは、コメント内容および放送局を示す放送局情報を示す文字列からなるコメント本文と、コメント情報を投稿した投稿者を識別可能なユーザＩＤとコメント本文が投稿された時刻を示す投稿時刻情報とからなる。

コメント本文に含まれる文字列は、投稿するユーザが入力した文字、単語および文章を示すものであって、たとえば、放送番組に体する感想などを示すコメント内容がコメント本文には表されている。放送局情報は、漢字やアルファベットの組み合わせなどからなり放送局名を示す文字列や、記号「＃」とこれに続く複数のアルファベットからなる特定の文字列である、いわゆるハッシュタグなどであって、コメント本文に、コメント内容とともに含まれる。ある放送局情報を含んでいる場合には、そのコメント情報は、該当する放送局の放送番組に関連するコメント情報であると判断することができる。放送局情報は、全国の各放送局に対して個別に設定される。

各放送局のコメント投稿数を１分ごとに投稿数蓄積部１ｅに記憶しておき、その後一定期間における各放送局のコメント投稿数の変動として記録する。本実施形態では、一定期間を一週間としてコメント投稿数の変動を記録する。さらに、前週、前々週および３週間前のコメント投稿数の変動についても蓄積する。

図７は、コメント投稿数の変動記録処理を示すフローチャートである。変動記録処理では、単に各放送局を対象に記録されていた１分ごとのコメント投稿数から、一週間分の投稿数の変動として記録するものである。また、変動記録処理は１週間に１回実施することとし、本例では毎週月曜日に前週分のコメント投稿数の変動を記録する。

ステップＡ１では、放送局を示す放送チャンネル番号の１つを変数「CHANNEL」に設定し、ステップＡ２で変数「TIME」に記録開始時刻として、フロー実施前週の月曜日の午前０時００分を設定する。ステップＡ３では、記憶されたコメント投稿数を参照し、「CHANNEL」で示される放送局について、「TIME」に設定された時刻とその前後２分間（（TIME-2分）〜（TIME+2分）すなわち５個の投稿数データ）におけるコメント投稿数の最大値を求め、変数「MAX」に設定する。ステップＡ４では、コメント投稿数の変動を示す変動テーブルに、「CHANNEL」の「TIME」における最大値「MAX」を格納する。

ステップＡ５では、変数「TIME」を１分増加させ、ステップＡ６で「TIME」に設定された時刻が、記録終了時刻であるフロー実施前週の日曜日の午後１１時５９分を超えるかどうかを判断する。記録終了時刻を超える場合には、ステップＡ７に進み、記録終了時刻を超えない場合には、ステップＡ３に戻って、１分進めた時刻の最大値を求める。

ステップＡ７では、全ての放送局について、記録処理が完了したかどうかを判断し、全ての放送局について完了していればフローを終了し、記録処理が完了していない放送局があればステップＡ１に戻って、次の放送局に対する記録処理を行う。

本実施形態の例では、図７に示す記録変動処理を毎週実行し、既に記録されたコメント投稿数の変動について、最新の３週間分を変動テーブルに残しておく。つまり、新しく１週間分の変動が記録されると４週間前の変動記録を削除する。なお、記録して残しておく投稿数の変動は、３週間分に限らず４週間分以上であっても１，２週間分であってもよい。

図８は、ユーザ端末装置３への通知の要否の判断について説明するための図である。図８は、過去のコメント投稿数の変動と、現在のコメント投稿数の変動と、通知を判断するための基準値および下限値を示している。

実際には、現在時刻において、１分ごとに現在のコメント投稿数と、基準値および下限値とを比較し、１分ごとにユーザ端末装置３への通知を行うかどうかを判断するものであるが、図８では、通知の判断について理解し易いように、現在時刻の投稿数の変動を示し、通知する場合、通知しない場合について説明する。

先週分のコメント投稿数の変動を示すＰ１、先々週のコメント投稿数の変動を示すＰ２および３週間前のコメント投稿数の変動を示すＰ３によって、基準となる投稿数の最大値の変動を示すＢが求められる。一方で、通知を判断する際の下限値Ｕを予め設定しておく。下限値は、適宜決定することができるが、たとえば１分あたりのコメント投稿数を１００とする。基準となる最大値Ｂが少ない時間帯には、放送番組が通知すべき状態ではない、盛り上がりとは異なる他の理由によって簡単に最大値を超えてしまう可能性が高くなり、そのような場合に通知する意義が薄れてしまう。一定の投稿数を超えて、かつ過去のコメント投稿数よりも大きくコメント投稿数が増えている場合には、そのコメントの対象となる放送番組において、ユーザに通知すべきほどの盛り上がりが生じている可能性が高くなるので、一定の投稿数として下限値を設定している。

さらに、現在のコメント投稿数が基準となる最大値Ｂを、単に超えたというだけでは、ユーザに通知すべきほどの盛り上がりが生じている可能性はあまり高くないと考えられるので、基準となる最大値のｘ倍（ｘはたとえば３〜５）を、現在のコメント投稿数が超えた場合にユーザへの通知を行うものとする。

これらの条件を元に、図８に示す例について説明すると、現在時刻の投稿数の変動Ｃが、下限値Ｕおよび基準最大値のｘ倍ＴＨを超えた時刻Ｃ１において、ユーザに対して通知すべきと判断する。また、時刻Ｃ２においても、下限値Ｕおよび基準最大値のｘ倍ＴＨを超えてはいるが、既に通知した時刻Ｃ１からの経過時間が一定時間以内であるので、同じ番組で同じ理由で盛り上がりが継続しているものと考え時刻Ｃ２では通知しないものとする。ユーザへの通知を実行してから連続して通知しない一定時間としては、通知の頻度を１つの番組において１回とすると、たとえば３０分間、１時間、２時間などとすればよい。なお、一定時間経過後も、変動Ｃが最初の通知から連続して下限値Ｕと基準最大値のｘ倍ＴＨを超え続けている場合は、ユーザへの通知をしない構成としてもよい。

また、時刻Ｃ３において、現在のコメント投稿数が基準最大値のｘ倍ＴＨを超えているが、下限値Ｕを超えていないので、ユーザへの通知は行わない。

図９は、ユーザ端末装置３への通知処理を示すフローチャートである。本フローは、番組検出プログラム１ｃの一例であり、コメント投稿数を記憶部１ａに記憶する時間間隔ごと、たとえば１分ごとにアプリケーションサーバ１において実行される。

ステップＢ１では、放送局を示す放送チャンネル番号の１つを変数「CHANNEL」に設定し、ステップＢ２で変数「TIME」に現在時刻を設定する。

ステップＢ３では、変動テーブルを参照し、「TIME-７日前」すなわち先週の同じ曜日の「CHANNEL」におけるコメント投稿数を変数「MAX1」に設定する。ステップＢ４では、変動テーブルを参照し、「TIME-１４日前」すなわち先々週の同じ曜日の「CHANNEL」におけるコメント投稿数を変数「MAX2」に設定する。ステップＢ５では、変動テーブルを参照し、「TIME-２１日前」すなわち３週間前の同じ曜日の「CHANNEL」におけるコメント投稿数を変数「MAX3」に設定する。

ステップＢ６では、「MAX1」のｘ倍、「MAX2」のｘ倍、「MAX3」のｘ倍および下限値から最大値を求め、「MAX」に設定する。ステップＢ７では、現在時刻におけるコメント投稿数が「MAX」を超えたかどうかを判断し、超えていればステップＢ８に進み、超えていなければステップＢ９に進む。

ステップＢ８では、「CHANNEL」に設定された放送局チャンネル番号に応じた放送局名と現在時刻において、「CHANNEL」に設定された放送局チャンネル番号の放送局で放送されている番組名をユーザ端末装置３に対して通知する。

ステップＢ９では、全ての放送局について、通知処理が完了したかどうかを判断し、全ての放送局について完了していればフローを終了し、通知処理が完了していない放送局があればステップＢ１に戻って、次の放送局に対する通知処理を行う。

ユーザ端末装置３への通知については、図６に示すように、予め番組情報サーバ６から、放送局名、放送番組名、放送開始・終了時刻などを含む、たとえば電子番組ガイド（ＥＰＧ）などの番組情報を取得して記憶部１ａに記憶しておき、「CHANNEL」に設定された放送局と現在時刻とに基づいて、番組情報から放送番組名を取得して端末管理サーバ４に対して通知要求を送信する。通知要求には、放送番組名、放送局名など、ユーザが現在盛り上がっている放送番組を特定するための特定情報を含む。通知要求を受けた端末管理サーバ４は、速やかに特定情報を各ユーザ端末装置３へと通知する。

なお、本発明の本質は週単位で繰り返される投稿数の変動から突出して多い投稿数を検出してユーザに通知することにあり、本実施形態で示した図７の記録変動処理を週に一度実行し、図９の通知処理を毎分実行する構成に限定されず、たとえば先週、先々週、３週間前の前後２分間の最大値を求める処理を毎分実行して現在時刻での投稿数と比較する構成であっても良い。

図１０は、コメント投稿数が特に多い放送番組の通知を受け取ったユーザ端末装置３の動作を説明する図である。図５に示したのと同様に、通知アイコンが表示された状態で待機画面におけるステータス領域を下方向にドラッグすると、図１０（ａ）に示す通知表示領域８７があらわれる。この通知表示領域８７には通知のより詳細な情報が表示され、さらに、ユーザが通知表示領域８７をタップするとアプリケーションが起動し、図１０（ｂ）に示すアプリケーション画面８８が表示される。アプリケーション画面８８は、盛り上がっている番組に関するＳＮＳへの投稿がリアルタイムに表示される画面であり、この画面を見ることでユーザはその盛り上がりを体感することができる。また、この画面からＳＮＳへのコメントを投稿することもできる。このような動作は第１実施形態と似ているが、放送番組の種類に応じてアプリケーション画面を適切に切り替えることにより、ユーザが速やかに知りたい情報にアクセスできるようになっている。

さらに、アプリケーションサーバ１に記憶されているＳＮＳへのコメント投稿数を利用して、過去に盛り上がった番組、たとえば先週の同じ曜日に盛り上がった番組を通知してもよい。図１１は、過去に盛り上がった番組の通知を受け取ったユーザ端末装置３の動作を説明する図である。図５に示したのと同様に、通知アイコンが表示された状態で待機画面におけるステータス領域を下方向にドラッグすると、図１１（ａ）に示す通知表示領域８９があらわれる。この通知表示領域８９には通知のより詳細な情報が表示され、さらに、ユーザが通知表示領域８７をタップするとアプリケーションが起動し、図１１（ｂ）に示すアプリケーション画面９０が表示される。アプリケーション画面９０は、先週の同じ曜日に放送された放送番組の番組名が、ＳＮＳ投稿数に応じた順位に沿って表示される、いわゆるランキングページの表示画面である。

なお、コメント投稿数が突出して多い番組の通知は、速やかにユーザに伝える必要があるため、ユーザ端末装置３の機能を用いて通知音やバイブレーションを使って通知することが好ましく、過去に盛り上がった番組の通知は、通知後にユーザが速やかに気づかなかったとしても影響が少ないため、通知音やバイブレーション無しに、図１１に示すような画面表示だけで通知するようにしてもよい。

＜第４実施形態＞
また本発明は、第４実施形態として、コンピュータを上記のアプリケーションサーバ１として機能させるためのサーバプログラムを提供することができる。

なお、本実施形態のサーバプログラムを記録する記録媒体として、マイクロコンピュータで処理が行われるために図示していないメモリ、たとえばＲＯＭ（Read Only Memory）のようなものそのものがプログラム記録媒体であっても良いし、また、図示していないが外部記憶装置としてプログラム読み取り装置が設けられ、そこに挿入することで読み取り可能なプログラム記録媒体であっても良い。

いずれの場合においても、格納されているプログラムはマイクロプロセッサがアクセスして実行させる構成であっても良いし、あるいは、いずれの場合もプログラムコードを読み出し、読み出されたプログラムコードは、マイクロコンピュータの図示されていないプログラム記憶エリアにダウンロードされて、そのプログラムが実行される方式であってもよい。このダウンロード用のプログラムは予め本体装置に格納されているものとする。

ここで、上記プログラム記録媒体は、コンピュータ本体と分離可能に構成される記録媒体であり、磁気テープやカセットテープなどのテープ系、フレキシブルディスクやハードディスク等の磁気ディスクやＣＤ−ＲＯＭ／ＭＯ／ＭＤ／ＤＶＤなどの光ディスクのディスク系、ＩＣカード（メモリカードを含む）／光カードなどのカード系、あるいはマスクＲＯＭ、ＥＰＲＯＭ（Erasable Programmable Read Only Memory）、ＥＥＰＲＯＭ（（登録商標）Electrically Erasable Programmable Read Only Memory）、フラッシュＲＯＭなどによる半導体メモリを含めた固定的にプログラムコードを担持する媒体であっても良い。

また、コンピュータがインターネットを含む通信ネットワークを接続可能なシステム構成であることから、通信ネットワークからプログラムコードをダウンロードするように流動的にプログラムコードを担持する媒体であっても良い。なお、このように通信ネットワークからプログラムをダウンロードする場合には、そのダウンロード用のプログラムは予めコンピュータ本体に格納しておくか、あるいは別な記録媒体からインストールされるものであっても良い。なお、本実施形態は、上記プログラムコードが電子的な伝送で具現化された、搬送波に埋め込まれたコンピュータデータ信号の形態でも実現され得る。

１ アプリケーションサーバ
１ａ 記憶部
１ｂ 情報通知／登録アプリ
１ｃ 番組検出プログラム
１ｄ ツイート監視プログラム
１ｅ 投稿数蓄積部
２ 管理者端末装置
３ ユーザ端末装置
４ 端末管理サーバ
５ 番宣情報サーバ
６ 番組情報サーバ
７ ツイッターサーバ
１００ 番宣情報テーブル
１０１ 番組名
１０２ 通知設定
１０３ 開始時刻
１０４ 終了時刻
１０５ 局
１０６ カウント

Claims (7)

1. ユーザが所持するユーザ端末装置とデータ通信可能に構成される番組情報通知装置であって、
   放送番組の話題性に関する話題性情報を外部装置から取得し、取得した話題性情報に基づいて話題性を有する放送番組を決定する決定部と、
   前記決定部が決定した放送番組を特定するための特定情報を生成する情報生成部と、
   前記情報生成部が生成した特定情報をユーザ端末装置に通知する通知部と、を有することを特徴とする番組情報通知装置。
2. 前記話題性情報は、放送番組の宣伝内容を示す番組宣伝情報であり、
   前記決定部は、番組宣伝情報に基づいて、放送番組の宣伝内容が、初回放送番組であること、または特別放送番組であることのいずれかであれば、該放送番組を、話題性を有する放送番組として決定することを特徴とする請求項１記載の番組情報通知装置。
3. 前記情報生成部は、前記検出部が検出した初回放送番組または特別放送番組について、外部データベースを検索し、放送局名、放送日および放送時間帯の少なくともいずれか１つを取得し、取得した放送局名、放送日および放送時間帯の少なくともいずれか１つと放送番組名とを含む特定情報を生成することを特徴とする請求項２記載の番組情報通知装置。
4. 前記話題性情報は、予め定める投稿サーバ装置に投稿された、放送番組に関するコメント情報の投稿数であり、
   前記投稿数の経時変化を記録した投稿数履歴を少なくとも１週分以上記憶し、記憶した投稿数履歴に基づいて、基準となる投稿数の経時変化を算出する基準算出部をさらに有し、
   前記決定部は、現在時刻における投稿数と、前記基準算出部が算出した、現在時刻と同じ時刻における基準となる投稿数とを比較し、現在時刻における投稿数が基準となる投稿数よりも予め定める割合以上多いときは、現在時刻に放送している放送番組を、話題性を有する放送番組として決定することを特徴とする請求項１記載の番組情報通知装置。
5. 前記情報生成部は、前記決定部が決定した放送番組について、放送局名および放送番組名の少なくともいずれか１つを含む特定情報を生成することを特徴とする請求項４記載の番組情報通知装置。
6. ユーザが所持するユーザ端末装置に番組情報を通知する番組情報通知方法であって、
   番組情報通知装置が、放送番組の話題性に関する話題性情報を外部装置から取得し、取得した話題性情報に基づいて話題性を有する放送番組を決定する決定工程と、
   番組情報通知装置が、前記決定工程で決定した放送番組を特定するための特定情報を生成する情報生成工程と、
   番組情報通知装置が、前記情報生成工程で生成した特定情報をユーザ端末装置に通知する通知工程と、を有することを特徴とする番組情報通知方法。
7. コンピュータを、請求項１〜５のいずれか１つに記載の番組情報通知装置として機能させるためのプログラム。

Images