(57)【要約】【課題】ユーザにより録画予約された番組の録画に失敗した場合でも、装置自体に負荷をかけることなく、当初録画予約された番組を録画可能な録画制御装置を提供する。【解決手段】録画制御装置（100）は、通信回線を介してデータの送受信が可能な通信部（140）、録画予約された番組の録画予約情報を格納する予約情報記憶部(121)、予約情報記憶部(121)に格納された録画予約情報に基づいて録画される番組を格納する番組記憶部（122）、番組記憶部(122)に録画予約された番組が正常に格納されなかった場合に、通信部(140)を介して該番組をリクエストし、当該リクエストに対する応答情報に基づいて、リクエストした番組を番組記憶部(122)に格納するように制御する制御部（110）を備える。【選択図】図２
2010130169.tif 000002
【特許請求の範囲】
【請求項１】
通信回線を介してデータの送受信が可能な通信部と、
録画予約された番組の録画予約情報を格納する予約情報記憶部と、
当該予約情報記憶部に格納された前記録画予約情報に基づいて録画される番組を格納する番組記憶部と、
当該番組記憶部に前記録画予約された番組が正常に格納されなかった場合に、前記通信部を介して該番組をリクエストし、当該リクエストに対する応答情報に基づいて、前記リクエストした番組を前記番組記憶部に格納するように制御する制御部と、
を備える録画制御装置。
【請求項２】
請求項１に記載の録画制御装置において、
前記制御部は、
前記応答情報が、前記リクエストした番組が前記通信回線を介してダウンロード可能であることを示す場合には、前記通信部を制御して前記リクエストした番組をダウンロードし、当該ダウンロードした番組を前記番組記憶部に格納するように制御する、
ことを特徴とする録画制御装置。
【請求項３】
請求項１または２に記載の録画制御装置において、
前記制御部は、
前記応答情報が、前記リクエストした番組が再放送されることを示す場合には、当該再放送される番組の録画予約情報を前記番組記憶部に格納するように制御する、
ことを特徴とする録画制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、録画制御装置に関し、特に、録画予約された番組の録画に失敗した場合に、その番組を自動的に番組送信側にリクエストし、リクエストに応じて再放送又はダウンロード可能となった当初録画予約されていた番組を、録画することができる録画制御装置に関する。
【背景技術】
【０００２】
地上デジタルテレビ放送は、２００３年の国内主要三大広域圏での放送開始後、順次全国展開されている。これに伴い、従来のアナログテレビ放送は、２０１１年に廃止されることが決定している。この地上デジタル放送において実現されたゴーストの低減及びハイビジョン放送等により、ユーザは、番組を高品質の映像や音で楽しむことが可能となった。さらに、地上デジタル放送では、データ放送、双方向通信、ＥＰＧ（Electronic Program Guide：電子番組表）の配信が行われるなど、放送における新たな仕組みが実施されている。デジタル放送の視聴に際し、ユーザは、地上デジタルテレビ放送の受信機又はセットトップボックスを自宅に設置して放送波を受信している。近年では、ハードディスクレコーダやＤＶＤレコーダ、ＶＴＲ等の録画機に、地上デジタルテレビ放送の受信機が標準で搭載されており、ユーザは、ＥＰＧを参照して簡単に地上デジタルテレビ放送の番組を録画予約する事が可能となっている。さらに、設置型に限らず、携帯端末向け地上テジタルテレビ放送（例えばワンセグ放送）を受信可能な携帯電話、携帯音楽再生装置（ポータブルプレーヤー）、車載機器（カーナビゲーションシステム）、ポータブルＤＶＤプレーヤー、及び携帯型のナビゲーションシステムであるＰＮＤ（Personal Navigation Device）等の携帯端末においても、デジタルテレビ放送番組の録画予約による録画（すなわち、予約録画）が可能となっている。
【０００３】
また、近年、アナログテレビ放送の停止により生じる空き周波数帯を利用した携帯端末向けの新たな放送サービスとして、ＩＳＤＢ−Ｔ系、ＤＶＢ−Ｈ、Ｔ−ＤＭＢ及びＭｅｄｉａＦＬＯ等を技術方式とするマルチメディア放送の開発が進められている。「マルチメディア放送」とは、コンテンツとして映像・音響・データのいずれも可能であり、それらコンテンツを、ストリーム型（リアルタイム型）及び／又はファイル型（蓄積型）で送信するような放送形態である。こういったマルチメディア放送の番組も、携帯端末で録画（予約録画も含む。）可能となることが想定される。
【０００４】
なお、携帯端末でデジタルテレビ放送やマルチメディア放送の番組を録画する場合には、以下のような問題がある。例えば、携帯端末は、そのモビリティから、録画予約した番組の放送開始から終了までの全ての期間で充分な受信電界強度を維持できないおそれがある。すなわち、ユーザの移動に伴うフェージングやマルチパスにより、デジタルテレビ放送やマルチメディア放送の受信が途切れてしまう状況が多発する。従って、ユーザが録画予約した番組の放送中にこのような状況が発生した場合は、録画が途切れる箇所が発生したり、番組が全く録画できなかったりして、録画予約した番組を正常に録画することができない。また、携帯端末の電源は有限であるため、充電が切れた場合にも録画予約した番組を録画できない。さらに、携帯端末に搭載されているメモリ量も、家庭に設置される録画装置のメモリ量と比較して少なく、録画できる量に制約があり、録画予約した番組を完全に録画できない状況が起こり得る。
【０００５】
上述の問題に対し、従来技術に、ユーザにより録画予約されたにもかかわらず録画に失敗した番組を、その番組の放送局に対して再放送するようにリクエストし、自動的に再録画予約を行う録画制御装置が開示されている（例えば、特許文献１を参照。）。
【０００６】
【特許文献１】特開２０００−４１２１１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、従来技術では、リクエストした番組の再録画予約を行うために、例えば放送局から放送される番組情報（放送スケジュール、ＥＰＧ等）をチェックしながら、リクエストした番組が再放送される日時等を検出しなければならない。従って、ＥＰＧのチェック処理に対する負荷がかかる。また、放送局から放送される番組情報の受信に失敗すれば、番組情報に基づいた再予約を行うことができず、再放送された番組を録画することができないというおそれもある。なお、マルチメディア放送では、サービス事業者（放送事業者及び／又は通信事業者等の番組送信側）がコンテンツサーバに番組を蓄積しておき、ユーザがそのコンテンツサーバにアクセスして蓄積されている番組をダウンロード可能な、蓄積型の番組配信が検討されている。従って、このサービスにより、マルチメディア放送の事業者が、リクエストされた番組をコンテンツサーバに蓄積することも考えられる。その場合には、ユーザに対して、自身がリクエストした番組がどのような形態で配信されるのか（コンテンツサーバに蓄積されるのかまたは再放送されるのか）を知らせる仕組みが必要となってくるが、そのような仕組みは開示されていない。すなわち、従来技術には、ユーザによって録画予約された番組を、装置自体に負荷をかけることなく確実に録画できる技法は開示されていない。
【０００８】
従って、本発明の目的は、ユーザにより録画予約された番組の録画に失敗した場合でも、装置自体に負荷をかけることなく、当初録画予約された番組を録画可能な録画制御装置を提供することを目的とする。
【課題を解決するための手段】
【０００９】
上述した課題を解決すべく、本発明による録画制御装置は、
通信回線を介してデータの送受信が可能な通信部と、
（番組（マルチメディア放送及び／又はデジタルテレビ放送の番組）を受信する受信部と、）
録画予約された番組の録画予約情報（録画予約された番組を特定するための識別子等）を格納する予約情報記憶部と、
当該予約情報記憶部に格納された前記録画予約情報に基づいて録画される番組を格納する番組記憶部と、
当該番組記憶部に前記録画予約された番組が正常に格納（録画）されなかった場合に、前記通信部を介して該番組を（番組送信側へ）リクエストし、当該リクエストに対する（番組送信側からの）応答情報に基づいて、前記リクエストした番組（前記録画予約された番組）を前記番組記憶部に格納するように制御する制御部とを備えることを特徴とする。
【００１０】
また、本発明の一実施形態による録画制御装置は、
前記制御部は、
前記応答情報が、前記リクエストした番組が（前記通信回線に接続され当該リクエストした番組を格納するサーバから）前記通信回線を介してダウンロード可能であることを示す場合には、前記通信部を制御して（前記サーバから）前記リクエストした番組をダウンロードし、当該ダウンロードした番組を前記番組記憶部に格納するように制御することを特徴とする。
【００１１】
さらに、本発明の別の実施形態による録画制御装置は、
前記制御部は、
前記応答情報が、前記リクエストした番組が再放送されることを示す場合には、当該再放送される番組の録画予約情報を前記番組記憶部に格納するように制御することを特徴とする。
【００１２】
上述したように本発明の解決手段を装置として説明してきたが、本発明はこれらに実質的に相当する方法、プログラム、プログラムを記録した記憶媒体としても実現し得るものであり、本発明の範囲にはこれらも包含されるものと理解されたい。なお、下記の方法やプログラムの各ステップは、データの処理においては必要に応じて、CPU、DSPなどの演算処理装置を使用するものであり、入力したデータや加工・生成したデータなどをHDD、メモリなどの記憶装置に格納するものである。
【発明の効果】
【００１３】
本発明によれば、ユーザにより録画予約された番組のリアルタイムでの録画に失敗した場合でも、装置自体に負荷をかけることなく、当初録画予約された番組を録画可能な録画制御装置を提供することが可能となる。
【発明を実施するための最良の形態】
【００１４】
以降、諸図面を参照しながら、本発明の実施態様を詳細に説明する。なお、これ以降では、放送システムとしてＭｅｄｉａＦＬＯ（メディアフロー）を想定し、本発明の録画制御装置としては、携帯端末を想定して説明する。しかしながら、本発明はこれらに限られるものではないことに留意されたい。なお携帯端末としては、例えば、ＰＤＡ（パーソナルデジタルアシスタンス）、携帯ゲーム機、携帯オーディオプレーヤー、携帯ビデオプレイヤー、携帯電子辞書、携帯電子書籍ビューワーなどの、デジタル放送を受信可能な携帯機器に幅広く本発明を適用することが可能である。
【００１５】
図１は、本発明の録画制御装置を使用可能な放送システム（ＭｅｄｉａＦＬＯ）の一例の概略図である。図に示すように、ＭｅｄｉａＦＬＯでは、携帯端末１００、放送局２００、基地局（移動体通信基地局）３００、移動体通信事業者４００、オペレーションセンター５００及びコンテンツ（番組）製作会社６００を含むシステムにおいてマルチメディア放送サービスが提供される。マルチメディア放送の番組は、マルチメディア放送サービスを提供する事業者（放送事業者や通信事業者を含むものであり、これ以降、「番組送信側」とする。）のオペレーションセンター５００にて編成・処理され、放送局２００から携帯端末１００に向けて送信される。
【００１６】
オペレーションセンター５００は、コンテンツ製作会社６００が製作した番組を受信し、リアルタイムに番組を放送するリアルタイムエンコーダ５３０と、番組データを蓄積するデータキャスティングコンテンツサーバ５２０とを備える。オペレーションセンター５００は、さらに、リアルタイムエンコーダ５３０でエンコードされた番組データと、データキャスティングコンテンツサーバ５２０に蓄積されている番組データとを、番組の放送スケジュールに従って多重化する多重化器５１０をさらに備える。多重化器５１０によって多重化された番組データは、放送局２００へ有線または無線で送出される。放送局２００は、番組データに変調等の所要な処理を行った後、携帯端末１００へと番組を送信する。なお、マルチメディア放送の番組情報を含むＥＰＧは、放送局２００から携帯端末１００へ提供されるか、または、通信回線を介して基地局３００から携帯端末１００へ提供される。或いは、ＥＰＧは、ユーザが携帯端末１００から所定のサーバへアクセスしてダウンロードすることにより取得するものであっても良い。
【００１７】
なお、上述のマルチメディア放送のサービスが有料で提供される場合は、オペレーションセンター５００でユーザ認証や課金認証、番組コンテンツを復号するための復号鍵等の管理が行なわれる。そして、ユーザ認証のための携帯端末１００の端末ＩＤ等のユーザ情報や、番組送信側から提供される番組コンテンツの復号鍵等は、携帯端末１００と基地局３００との間で通信回線を介して送受信される。すなわち、携帯端末１００と番組送信側との間のユーザ情報や復号鍵のやり取りは、移動体通信事業者４００を介して行われる。
【００１８】
詳細は後述するが、本発明によれば、携帯端末１００は、録画予約した番組の録画（予約録画）に失敗した場合に、当初録画予約した番組を何らかの形で配信するように又は取得出来るように番組送信側にリクエストする。そして、携帯端末１００は、そのリクエストに対する番組送信側からの応答情報に応じて、リクエストした番組の再放送を録画予約するか、またはリクエストした番組を通信回線を介してダウンロードする。番組送信側への番組のリクエストは、通信回線を介して基地局３００へと送信され、移動体通信事業者４００からオペレーションセンター５００へと送信される。オペレーションセンター５００では、携帯端末１００からのリクエストが解析され、リクエストされた番組を再放送するか、またはリクエストされた番組を携帯端末１００がダウンロードできるようにするかを示す応答情報が、リクエストに対する応答として携帯端末１００へ送信される。
【００１９】
図２は、本発明の一実施例による携帯端末（録画制御装置）のブロック図である。図２に示すように、携帯端末１００は、制御部１１０、記憶部１２０、受信部１３０、通信部１４０及び電池電圧測定部１５０を備える。携帯端末１００は、さらに、音声処理部１６０、記録媒体Ｉ／Ｆ１７０、表示部ＤＩＳ、操作部ＫＥＹ、スピーカＳＰ、マイクロホンＭＩＣ、切替回路ＳＷ及びアンテナＡＮＴ１，ＡＮＴ２を備える。また、制御部１１０は、携帯端末１００全体の制御を司り、判定部１１１、リクエスト作成部１１２、応答情報解析部１１３、録画予約再設定部１１４及び取得部１１５を備える。記憶部１２０は、予約情報記憶部１２１、番組記憶部１２２及び閾値記憶部１２３を備える。
【００２０】
図２のブロック図における各ブロックの機能とともに、本発明の一実施例による携帯端末１００について説明する。受信部１３０は、アンテナＡＮＴ１を介して、放送局２００から放送される放送番組を受信する。通信部１４０は、基地局３００との間で、通信回線（電話回線、ブロードバンド回線等）を介したデータの送受信を行う。前述した、基地局３００を介した、ユーザ認証のためのユーザ情報や番組コンテンツの復号鍵等の送受信も、通信部１４０によって行われる。さらに、番組のリクエストも、通信部１４０によって基地局３００へ送信される。
【００２１】
電池電圧測定部１５０は、携帯端末１００に供給可能な電力残量を求めるために、電池の端子電圧を測定する。音声処理部１６０は、マイクロホンＭＩＣから入力された音声、受信部１３０で受信された番組の音声及び通信部１４０で送受信される通話音声に対する所定の処理を行う。切替回路ＳＷは、音声処理部１６０によって処理された音声の出力先を、スピーカＳＰとイヤホンスピーカとで切り替える。また、記録媒体Ｉ／Ｆ１７０には、メモリカード、ＵＳＢメモリ等の記録媒体１８０が装着される。表示部ＤＩＳは、ＬＣＤ（液晶ディスプレイ）や有機ＥＬ等の表示デバイスであり、受信部１３０で受信した番組の映像、字幕、データ放送データ等を表示する。操作部ＫＥＹは、例えば、キーパッド、キーボタン、または、タッチパネル等で構成され、ユーザからの、電話番号入力、文字入力、テレビの視聴や録画操作等の操作入力を受け付ける。
【００２２】
予約情報記憶部１２１は、ユーザによる番組の録画予約情報を格納する。なお、ユーザは、例えばＥＰＧを参照して、録画したい番組の録画予約を行うことができる。録画予約情報は、例えば、録画予約された番組に対応する放送波の周波数や、録画予約された番組を特定可能な識別子から成る。番組記憶部１２２は、携帯端末１００によって録画された番組を格納する。閾値記憶部１２３は、受信部１３０で受信する放送波の電界強度、電池電圧測定部１５０で測定される電池電圧、番組を録画可能なメモリ残量に対する閾値を格納する。
【００２３】
判定部１１１は、録画予約された番組が正常に録画されたか否か、すなわち、予約情報記憶部１２１に格納された録画予約情報に基づいて、録画予約された番組が番組記憶部１２２に正常に格納されたか否かを判定する。上述したように、携帯端末１００は、フェージングや充電不足、メモリ不足等で、番組の内容が理解できない程に録画が途切れてしまったり、番組の一部のみを録画したりといった、録画予約された番組を完全に録画できない状況が起こりうる。従って、この場合の「正常に格納された」とは、録画予約された番組が、ユーザがその内容を把握できる程度に録画できたことをいうものとする。また、判定部１１１は、後述する各種の判定動作も行う。
【００２４】
リクエスト作成部１１２は、録画予約された番組が番組記憶部１２２に正常に格納されなかった場合に、番組送信側にその番組をリクエストするためのリクエストを作成する。応答情報解析部１１３は、リクエストに応答して番組送信側から送信された応答情報を解析する。録画予約再設定部１１４は、応答情報が、リクエストした番組が再放送されることを示す場合に、その再放送される番組の録画予約を設定する。すなわち、再放送される番組の録画予約情報を格納するように、予約情報記憶部１２１を制御する。取得部１１５は、応答情報が、リクエストした番組が通信回線を介してダウンロード可能であることを示す場合には、通信部１４０を制御してリクエストした番組をダウンロードし、さらに、ダウンロードした番組を格納するように番組記憶部１２２を制御する。
【００２５】
次に、携帯端末１００が予約録画に失敗したことを検出し、当初録画予約していた番組を番組送信側へリクエストする処理について、フローチャートを用いて説明する。予約録画に失敗する原因としては、番組の放送波の受信レベル（電界強度）の低下、記憶容量（メモリ容量）不足及び充電不足が考えられる。図３〜５に、それぞれの原因に対する携帯端末１００の処理を示すフローチャートの一例を示し、説明する。なお、予めユーザによって１つまたは複数の番組の録画予約が設定されており、それらの番組の録画予約情報は、予約情報記憶部１２１に格納されているものとする。なお、図３〜５において、制御部１１０は、予約情報記憶部１２１に格納されている録画予約情報に基づき、録画予約された番組の放送が開始されると、受信部１３０によってその番組の放送波を受信し、番組の録画を開始する。録画された番組は、番組記憶部１２２に格納される。録画予約された番組の放送が開始されたか否かは、例えば、受信済みの最新のＥＰＧを参照して判定することができる。また、録画中であることを示すアイコン、録画が開始されてからの時間等を表示部ＤＩＳへ表示して、ユーザに録画中であることを示すようにしてもよい。
【００２６】
図３は、携帯端末１００による、放送波の受信レベルが低下した場合の処理のフローチャートである。予約に基づく録画が開始されると、判定部１１１は、受信部１３０で受信する放送波の受信レベルが、所定時間（第１の所定時間）以上、基準値以下となったか否かを判定する（ステップＳ１１）。なお、これら所定時間や受信レベルの基準値等は、閾値記憶部１２３に格納されている。受信レベルの基準値は、その基準値以下では受信する番組コンテンツが途切れてしまうような値とし、所定時間とともに、ユーザによって予め設定することが可能である。この所定時間は、録画に失敗した時間、すなわち番組を再生できない時間に相当するため、ユーザが、番組内容に応じて設定することが好適である。ステップＳ１１で、正常な録画が可能な状態であると判定された場合は、ステップＳ１６へ進み、判定部１１１は、録画中の番組が終了したか否かを判定し、番組が終了していない場合はステップＳ１１へ戻る。従って、録画中の番組が終了するまで、放送波の受信レベルの監視が継続される。
【００２７】
ステップＳ１１で、受信レベルが所定時間以上、基準値以下となったと判定された場合は、制御部１１０は、基準値以下となった時刻を記憶部１２０に記録し、録画に失敗したことを示す録画失敗フラグを立てる（ステップＳ１２）。その後、判定部１１１は、録画中の番組が終了する前に、番組の放送波の受信レベルが、所定時間（第２の所定時間）以上、基準値以上となったか（受信レベルが復帰したか）否かを判定する（ステップＳ１３）。すなわち、放送波の受信レベルが安定し、正常な録画が可能となったか否かが判定される。ステップＳ１３にて、受信レベルが復帰したと判定された場合は、制御部１１０は、受信レベルが基準値以上となった時刻を記憶部１２０に記録する（ステップＳ１４）。次に、制御部１１０は、放送波の受信レベルが基準値以下であった期間を録画失敗期間として、録画失敗番組リストに記録する。この録画失敗番組リストは記憶部１２０に格納されており、録画に失敗した期間、番組名、番組識別子等が記録される。
【００２８】
その後、判定部１１１は、録画中の番組が終了したか否かを判定する（ステップＳ１６）。録画中の番組が終了したと判定された場合は、制御部１１０は、録画を終了するように自端末を制御する（ステップＳ１７）。すなわち、受信部１３０による放送波の受信及び／又は番組記憶部１２２への番組の格納を停止する。また、ステップＳ１３にて録画中の番組が終了したと判定された場合も、制御部１１０は、ステップＳ１７へ進み、録画を終了するように自端末を制御する。その後、判定部１１１は、記憶部１２０に録画失敗フラグがあるか否かを判定する（ステップＳ１８）。録画失敗フラグがあると判定された場合は、ステップＳ２０へ進み、制御部１１０は、番組送信側への番組のリクエストを行うように自端末を制御する。なお、リクエスト処理については後述する。ステップＳ１８にて、録画失敗フラグがないと判定された場合は、予約録画が完了したとして、記憶部１２０に格納されている録画リストに、録画済の番組に関する情報を記録する（ステップＳ１９）。
【００２９】
次に、記憶容量（メモリ容量）不足により予約録画が失敗した場合について説明する。図４は、携帯端末１００による、記憶容量（メモリ容量）が不足した場合の処理のフローチャートである。まず、予約録画が開始されると、判定部１１１は、番組記憶部１２２の残量（メモリ残量）が、閾値（メモリ残量閾値）を超えたか否かを判定する（ステップＳ３１）。なお、制御部１１０は、録画が開始されると、録画中の番組の1秒当たりのメモリ消費量を計算し、メモリ残量を参照してどの程度録画可能であるかを算出する。録画中の番組の画質レートが分かる場合には、レートを取得してメモリ残量を計算することもできる。放送波の画質レートが可変する事も考えられるため、制御部１１０は、上述の演算処理を行いつつ、メモリ残量が閾値を越えたか否かの判定を行う。このメモリ残量閾値は、ユーザにより設定され、記憶部１２０に格納されている。ステップＳ３１にてメモリ残量が閾値を超えたと判定されると、判定部１１１は、低画像レートでの録画が可能であるように自端末が設定されているか否かを判定し、低画像レートでの録画が可能である場合には、低画像レートで録画を継続する。すなわち、ステップＳ３１〜Ｓ３３にて、ユーザが、画質よりも番組の録画時間を優先させているか否かが判定される。従って、ユーザが画質を優先する場合には、メモリ残量の閾値を設定せず、ステップＳ３１〜Ｓ３３の処理は行わなくてもよい。なお、番組記憶部１２２は、取り外し可能な記録媒体１８０に設けることもできる。従って、メモリ残量とは、番組を格納可能な全メモリに対する残量を指すものとする。
【００３０】
ステップＳ３４にて、判定部１１１は、予約に基づく録画中の番組が終了する前に、全メモリが使用されたか、すなわち、番組を格納可能なメモリ容量が確保できない状況となったか否かを判定する。全メモリが使用されたと判定された場合には、制御部１１０は、録画中の番組の録画を終了するように自端末を制御する（ステップＳ３７）。そして、制御部１１０は、録画を終了した時刻（録画終了時刻）及び録画失敗フラグを格納するように記憶部１２０を制御する（ステップＳ３８）。制御部１１０は、録画に失敗した番組の録画終了時刻、番組名等を、録画失敗番組リストに記録する（ステップＳ３９）。
【００３１】
ステップＳ３４にて、録画中の番組の終了前に全メモリが使用されていないと判定された場合には、判定部１１１は、録画中の番組が終了したか否かを判定する（ステップＳ３５）。録画中の番組が終了したと判定された場合は、制御部１１０は、録画を終了するように自端末を制御する（ステップＳ３６）。すなわち、受信部１３０による放送波の受信及び／又は番組記憶部１２２への番組の格納を停止する。ステップＳ３６の後、または、ステップＳ３９の後、判定部１１１は、記憶部１２０に録画失敗フラグがあるか否かを判定する（ステップＳ４０）。録画失敗フラグがあると判定された場合は、ステップＳ４２へ進み、制御部１１０は、番組送信側への番組のリクエストを行うように自端末を制御する。なお、リクエスト処理については後述する。ステップＳ４０にて、録画失敗フラグがないと判定された場合は、予約録画が完了したとして、記憶部１２０に格納されている録画リストに、録画済の番組に関する情報を記録する（ステップＳ４１）。
【００３２】
次に、充電不足により予約録画が失敗した場合について説明する。図５は、携帯端末１００による、充電不足の場合の処理のフローチャートである。予約録画が開始されると、電池電圧測定部１５０は、電池電圧を一定周期で測定・監視する（ステップＳ５１）。電池電圧測定部１５０の測定結果を受け、判定部１１１は、バッテリ残量（電池残量）が、閾値（バッテリ残量閾値）以下となったか否かを判定する（ステップＳ５２）。このバッテリ残量閾値は、バッテリ残量閾値以下となっても再放送リクエスト処理が行われる程度に設定することが好ましい。ステップＳ５２にてバッテリ残量が閾値以下となったと判定されると、制御部１１０は、予約に基づく録画中の番組の録画を終了するように自端末を制御する（ステップＳ５５）。そして、制御部１１０は、録画を終了した時刻（録画終了時刻）及び録画失敗フラグを格納するように記憶部１２０を制御する（ステップＳ５６）。制御部１１０は、録画に失敗した番組の録画終了時刻、番組名等を、録画失敗番組リストに記録する（ステップＳ５７）。
【００３３】
ステップＳ５２にて、バッテリ残量が閾値以下でないと判定された場合には、判定部１１１は、録画中の番組が終了したか否かを判定する（ステップＳ５３）。録画中の番組が終了したと判定された場合は、制御部１１０は、録画を終了するように自端末を制御する（ステップＳ５４）。すなわち、受信部１３０による放送波の受信と、番組記憶部１２２への番組の格納を停止する。ステップＳ５４の後、または、ステップＳ５７の後、判定部１１１は、記憶部１２０に録画失敗フラグがあるか否かを判定する（ステップＳ５８）。録画失敗フラグがあると判定された場合は、ステップＳ６０へ進み、制御部１１０は、番組送信側への番組のリクエストを行うように自端末を制御する。なお、リクエスト処理については後述する。ステップＳ５８にて、録画失敗フラグがないと判定された場合は、予約録画が完了したとして、記憶部１２０に格納されている録画リストに、録画済の番組に関する情報を記録する（ステップＳ５９）。
【００３４】
上述の処理により、予約録画が正常に行われなかった場合には、録画失敗番組リストが作成される。図６に、表示部ＤＩＳに表示された録画失敗番組リストの一例を示す。図６のように、ユーザビリティの観点から、録画失敗番組リストをユーザに対して提示することが好適である。録画失敗番組リストには、予約録画に失敗した番組の番組名、放送日時、放送局名等が含まれる。また、ユーザは、図６に示すように、フォーカス（またはカーソル）を移動させてリストの項目を選択し、失敗内容の詳細を確認できるようにしてもよい。例えば、リストの項目を選択すると、録画に失敗した期間や録画率（全番組に対する録画された分の割合）等が、表示部ＤＩＳに表示されるようにすることができる。なお、本発明による録画制御装置によれば、録画失敗番組リストに基づいて、予約録画に失敗した番組が自動的に番組送信側へリクエストされるため、ユーザへの録画失敗番組リストの提示は必ずしも必要ではない。
【００３５】
次に、図３〜５の再放送リクエスト処理、及びリクエストに対する番組送信側からの応答情報に応じた、携帯端末１００による処理について説明する。本発明の録画制御装置によれば、番組送信側からの応答情報に応じて、予約録画に失敗した番組を、その番組の再放送時に録画するように再録画予約を設定するか、或いは、通信回線を介してダウンロードする。リクエストに対して番組送信側から送信された、そのリクエストした番組の放送スケジュールに基づき、再録画予約を行う実施例について説明する。
【００３６】
図７及び８は、それぞれ、携帯端末１００のリクエストに対して番組送信側からリクエストした番組の放送スケジュールが送信される場合の、携帯端末１００による処理のフローチャート及びシーケンス図である。携帯端末のサービスエリアと、放送のサービスエリアが一致するとは限らないため、まず、判定部１１１は、通信部１４０で受信する受信電界が、所定の基準レベル以上であるか否かを判定する（ステップＳ６１）。このステップは、リクエストが確実に送信されるためのものであり、通信部１４０で受信する受信電界が所定の基準レベル以上でない場合は、所定の基準レベル以上となるまで待機する。次に、ステップＳ６２へ進み、リクエスト作成部１１２は、記憶部１２０に格納されている録画失敗番組リストに基づき、番組送信側へ送信する再放送リクエストメッセージを作成する。再放送リクエストメッセージには、番組送信側でリクエストされた番組及びリクエストした端末を識別できる情報、例えば、放送日時、番組名、番組ＩＤ、番組提供者（コンテンツ製作社）名等と、自端末の情報（電話番号、端末ＩＤ等）とが含まれる。作成した再放送リクエストメッセージは、通信部１４０によって、通信回線を介して基地局３００へ送信される（ステップＳ６３）。制御部１１０は、リクエストした番組をリクエストリストに保存し格納するように記憶部１２０を制御する（ステップＳ６４）。その後、判定部１１１は、放送局２００又は基地局３００から、放送スケジュールを受信したか否かを判定する（ステップＳ６５）。この放送スケジュールには、携帯端末１００がリクエストした番組が再放送される日時や、番組ＩＤ等、携帯端末１００が録画予約するのに十分な情報が含まれる。録画予約再設定部１１４は、受信した放送スケジュールに基づき、リクエストした番組の録画予約を再設定する（ステップＳ６６）。すなわち、予約情報記憶部１２１に、リクエストした番組の識別情報等（録画予約情報）を格納する。その後、リクエストされた番組に関する情報は、リクエストリストから削除される（ステップＳ６７）。
【００３７】
この処理を、図８のシーケンス図に基づき説明する。まず、携帯端末１００は、再放送リクエストを、通信回線を介して基地局３００へ送信する（ステップＴ１１）。オペレーションセンター５００は、携帯端末１００の再放送リクエストを、基地局３００から移動体通信事業者４００を経て受信する。再放送リクエストを受信したオペレーションセンター５００は、リクエストを受け付けたことを示す応答（レスポンス）を、基地局３００を介して携帯端末１００へ送信する（ステップＴ２１）。携帯端末１００は、応答を受信すると、リクエストした番組の再放送に関する情報を受信するのを待機する（ステップＴ１２）。オペレーションセンター５００は、複数のユーザからの再放送リクエストや視聴率を集計し、番組放送スケジュールを編成する（ステップＴ２２）。放送スケジュールの中にリクエストされた番組が含まれる場合には、オペレーションセンター５００は、リクエストを送信した全携帯端末に対し、再放送されることを通知するメッセージ（応答情報）を報知する。このメッセージは放送波に重畳されて放送局２００から送信されるか、或いは、基地局３００から通信回線を介して送信される。メッセージ（応答情報）を受信した携帯端末１００は、再録画予約が設定される（ステップＴ１３）。その後、オペレーションセンター５００から放送局２００を介してリクエストされた番組が再放送されると（ステップＴ２３）、携帯端末１００は、その番組の録画を行う（ステップＴ１４）。
【００３８】
このように、本発明によれば、リクエストした番組の再放送スケジュールが携帯端末１００に送信されるため、従来技術と異なり、録画予約を行うためにＥＰＧをチェックする負荷が軽減される。
【００３９】
次に、ダウンロードタイプの実施例について説明する。本実施例では、ユーザがダウンロード可能なように、ユーザによりリクエストされた番組が番組送信側によってコンテンツサーバに蓄積される場合を想定している。図９及び１０は、それぞれ、携帯端末１００のリクエストに対して番組送信側がリクエストした番組を再放送するか、或いはコンテンツサーバに蓄積する場合の、携帯端末１００による処理のフローチャート及びシーケンス図である。図９のステップＳ７１〜Ｓ７４の処理は、図７のステップＳ６１〜Ｓ６４の処理と同様であるため説明を省略する。その後、判定部１１１は、番組送信側からの応答を受信したか否かを判定する（ステップＳ７５）。応答を受信した場合には、判定部１１１は、番組送信側からのメッセージ（応答情報）を受信したか否かを判定する（ステップＳ７６）。すなわち、ステップＳ７５及びＳ７６によって、リクエストに対する番組送信側からの何らかの応答があるまでは、携帯端末１００では、再録画予約等の処理が行われない。
【００４０】
メッセージ（応答情報）を受信すると、応答情報解析部１１３は、メッセージ（応答情報）の内容を解析する（ステップＳ７７）。メッセージ（応答情報）が、リクエストした番組が再放送されることを示すものである場合には、ステップＳ８５へ進み、録画予約再設定部１１４は、再放送される番組の録画予約情報を格納するように予約情報記憶部１２１を制御する。その後、再録画予約が設定された番組は、リクエストリストから削除される（ステップＳ８６）。ステップＳ７７にて、メッセージ（応答情報）が、リクエストした番組がコンテンツサーバに蓄積されており、通信回線を介してダウンロード可能であることを示すものである場合には、判定部１１１は、番組をダウンロードするか否かを判定する（ステップＳ７８）。これは、ダウンロードが有料である場合には、ユーザがダウンロードを希望しないことが想定されるためである。ユーザによって、ダウンロード不可と設定されていた場合は、ステップＳ８６へ進み、リクエストした番組はリクエストリストから削除される。ステップＳ７８にて、ダウンロードすると判定された場合には、判定部１１１は、録画率の高低を判定する（ステップＳ７９）。ここで、録画率とは、番組の全コンテンツに対する録画されたコンテンツの割合を示し、この割合の高低の判定基準については、予めユーザが設定可能である。ステップＳ７９にて録画率が低い、すなわち、ほとんど録画されていないと判定された場合には、取得部１１５は、通信部１４０を制御して、番組の全データ（全コンテンツ）をダウンロードする（ステップＳ８０）。さらに、取得部１１５は、ダウンロードした番組を格納するように番組記憶部１２２を制御する。ステップＳ７９にて、録画率が高いと判定された場合には、取得部１１５は、録画失敗番組リストに基づいて、録画されていない期間（未録画時刻）をチェックし、録画に失敗した一部のデータをダウンロードするように通信部１４０を制御する（ステップＳ８１，Ｓ８２）。なお、録画に失敗した部分の前後に所定の時間（例えば、５分など）を付加した期間のデータをダウンロードすることもできる。このようにすれば、当初の録画予約で録画された部分の番組の内容を、ユーザがスムーズに思い出すことができる。
【００４１】
番組コンテンツのダウンロードが終了した後は、制御部１１０は、ダウンロードし番組記憶部１２２に格納されている番組コンテンツをチェックする（ステップＳ８３）。このとき、当初の録画予約で録画されていた番組コンテンツがまだ番組記憶部１２２に格納されている場合は、再生時に番組コンテンツが途切れなく再生されるように、当初の録画予約により録画された番組コンテンツと、予約録画の失敗後にあらためてダウンロードしたコンテンツとに対して所定の処理を行ってもよい。その後、リクエストされた番組に関する情報は、リクエストリストから削除される（ステップＳ８４）。
【００４２】
この処理を、図１０のシーケンス図に基づき説明する。図１０のシーケンス図では、携帯端末１００によってリクエストされた番組が、コンテンツサーバに蓄積される場合について示す。まず、携帯端末１００は、再放送リクエストを、通信回線を介して基地局３００へ送信する（ステップＴ３１）。オペレーションセンター５００は、携帯端末１００の再放送リクエストを、基地局３００から移動体通信事業者４００を経て受信する。再放送リクエストを受信したオペレーションセンター５００は、リクエストを受け付けたことを示す応答（レスポンス）を、基地局３００から携帯端末１００へ送信し（ステップＴ４１）、携帯端末１００は、応答を受信する（ステップＴ３２）。オペレーションセンター５００は、リクエストされた番組をダウンロード可能なアドレス（番組アドレス）を含んだメッセージ（応答情報）を、基地局３００を介して携帯端末１００に送信する（ステップＴ４２）。携帯端末１００は、受信した番組アドレスに通信部１４０を介してアクセスし、番組のダウンロードを指示する（ステップＴ３３）。ダウンロード指示（データ送信要求）は、基地局３００を介してオペレーションセンター５００に送信され、オペレーションセンター５００は、ユーザ認証を行うためのシーケンスを開始し、認証キーの提示を端末に求める（ステップＴ４３）。認証要求を受信した携帯端末１００は、自端末のユーザ情報（電話番号、端末ＩＤ等）や、予め与えられた認証キーを、基地局３００を介してオペレーションセンター５００へ送信する。オペレーションセンター５００は、携帯端末１００から受信した認証キーの正誤を判定し、認証キーが正しい場合は、コンテンツデータのダウンロードを許可する（ステップＴ４４）。その後、携帯端末１００は、通信回線を介して番組コンテンツをダウンロードする（ステップＴ３５）。
【００４３】
このように、本発明によれば、リクエストした番組がどのような形態で配信されるか又は取得出来るかを示す応答情報が携帯端末１００に送信されるため、従来技術と異なり、ＥＰＧのチェックや取りこぼしが発生することなく、録画に失敗した番組を、再録画またはダウンロードにより確実に取得することができる。なお、これらの処理はユーザを煩わせることなく自動的に行われるため、ユーザビリティに優れているという利点もある。さらに、応答情報として、番組の再放送やサーバへの蓄積を行わない、という情報を送信することもできる。このようにすれば、従来技術と異なり、ユーザがＥＰＧのチェックをし続ける負荷を無くすことができる。
【００４４】
本発明を諸図面や実施例に基づき説明してきたが、当業者であれば本開示に基づき種々の変形や修正を行うことが容易であることに注意されたい。したがって、これらの変形や修正は本発明の範囲に含まれることに留意されたい。例えば、各構成部、各ステップなどに含まれる機能などは論理的に矛盾しないように再配置可能であり、複数の構成部やステップなどを１つに組み合わせたり、あるいは分割したりすることが可能である。例えば、上述の実施例では、放送システムとしてＭｅｄｉａＦＬＯを想定して説明したが、本発明はこれに限られるものではなく、例えば、ワンセグ放送や、ＩＳＤＢ−Ｔ系、ＤＭＢ等の方式による放送システムにも適用することができ、各方式に則る方法で、リクエストの送信が行われる。また、上述の実施例では、オペレーションセンターが放送局から番組を放送する態様で説明したが、通信回線を介して番組が送信されるシステムにおいても、本発明の録画制御装置を適用することができる。
【００４５】
また、上述の実施例では、予約録画の開始後にメモリ残量や電池残量の判定を行う態様を説明したが、予約録画の開始前にそれら残量を判定し、それらの不足により予約録画が失敗することが判明した時点で、録画失敗フラグをたてることもできる。さらに、上述の実施例では、録画率の高低によりダウンロードする番組の量を判定したが、この判定は、当初の録画予約の日時からコンテンツサーバに蓄積されるまでの経過時間に応じて行ってもよい。例えば、録画に失敗してからすぐにダウンロード可能となった場合には、録画された部分のみを視聴したユーザはその番組内容を覚えている可能性が高い。従って、録画に失敗した部分のみをダウンロードすれば良い。また、時間が経過している場合には、録画された部分のみを視聴したとしても、全番組コンテンツを視聴しなければユーザが番組内容を思い出せない可能性が高いため、全番組データのダウンロードを行う。
【図面の簡単な説明】
【００４６】
【図１】本発明の録画制御装置が用いられる放送システムの一例の概略図である。
【図２】本発明の一実施例による携帯端末（録画制御装置）のブロック図である。
【図３】放送波の受信レベルが低下した場合の携帯端末１００の処理のフローチャートである。
【図４】記憶容量（メモリ容量）が不足した場合の携帯端末１００の処理のフローチャートである。
【図５】充電不足による場合の携帯端末１００の処理のフローチャートである。
【図６】表示部ＤＩＳに表示された録画失敗番組リストの一例を示す図である。
【図７】番組送信側からリクエストした番組の放送スケジュールが送信される場合の、携帯端末１００の処理のフローチャートである。
【図８】番組送信側からリクエストした番組の放送スケジュールが送信される場合のシーケンス図である。
【図９】番組送信側がリクエストした番組を再放送するか、或いはコンテンツサーバに蓄積する場合の、携帯端末１００の処理のフローチャートである。
【図１０】番組送信側がリクエストした番組をコンテンツサーバに蓄積する場合のシーケンス図である。
【符号の説明】
【００４７】
１００  携帯端末（録画制御装置）
１１０  制御部
１１１  判定部
１１２  リクエスト作成部
１１４  応答情報解析部
１１４  録画予約再設定部
１１５  取得部
１２０  記憶部
１２１  予約情報記憶部
１２２  番組記憶部
１２３  閾値記憶部
１３０  受信部
１４０  通信部
１５０  電池電圧測定部
１６０  音声処理部
１７０  記録媒体Ｉ／Ｆ
１８０  記録媒体
２００  放送局
３００  基地局
４００  移動体通信事業者
５００  オペレーションセンター
５１０  多重化器
５２０  データキャスティングコンテンツサーバ
５３０  リアルタイムエンコーダ
６００  コンテンツ製作会社
【図１】
2010130169.tif 000003
【図２】
2010130169.tif 000004
【図３】
2010130169.tif 000005
【図４】
2010130169.tif 000006
【図５】
2010130169.tif 000007
【図６】
2010130169.tif 000008
【図７】
2010130169.tif 000009
【図８】
2010130169.tif 000010
【図９】
2010130169.tif 000011
【図１０】
2010130169.tif 000012