JP2010130401A - 携帯端末装置及びそれを用いた番組情報取得システム - Google Patents

Abstract

【課題】携帯端末装置の特性を生かして、どの場所であっても、その場所で視聴するテレビ番組に適した電子番組表を取得することを目的とする。
【解決手段】携帯端末装置１００は、情報を受信する情報受信部１８と、各部を制御するＣＰＵ（リクエスト処理部）１６と、処理プログラムを記憶するメモリ１０と、番組情報を記憶する番組情報蓄積部１５と、番組情報蓄積部１５にアクセスするための番組情報アクセス部１４と、エリア情報を記憶するエリア情報蓄積部１９と、バッテリ２０と、チューナ１２１を備えた放送受信部１２と、出力部である表示部１３及びスピーカ２１と、情報送信部１７と、放送受信用のアンテナ１１と、を備えている、ＣＰＵ１６は、相手方の情報提供端末のバッテリの残量を取得するとともに、相手方から番組情報を取得するためのデータ送信を依頼するデータ送信依頼部１６ｂと、バッテリ残量に基づいて、番組情報を実際に取得できる程度の容量を残している端末で有るか否かを判断するバッテリ残量判断部１６ａと、を備えている。
【選択図】図２

Description

本発明は、携帯端末装置に関し、特に、テレビジョン受信機能を備えた携帯端末装置及びそれを用いた番組情報取得システムに関する。

近年、携帯電話機などの携帯端末装置においては、デジタルテレビジョン受信機能、特にワンセグ放送の受信機能を備えた機種が多くなっている。デジタルテレビジョン受信装置を視聴する際に役立つように、電子番組表（ＥＰＧ）を取得し表示させる機能が設けられている。

ＥＰＧのような番組情報を外部から取得する技術として、下記特許文献１には、据え置き型のテレビジョン受信装置に番組表を作成させ、それを携帯型のテレビジョン受信装置に、ネットワークを介して送信する技術として開示されている。
下記特許文献１の図６には、携帯型地上デジタル放送受信機１から番組情報送信の依頼を通信インタフェースを介して図３の据え置き型地上デジタル放送受信機２ａへ送り、番組情報のリクエストを受けた据え置き方地上デジタル放送受信機２ａは各局の放送波を受信、番組表を作成し、携帯型地上デジタル放送受信機１へ電子番組表を送信する技術が記載されている。

特開２００４−２０７８０６号公報

上記特許文献１に記載の技術は、例えば自宅に固定されて設置されている据え置き型地上デジタル放送受信機から電子番組表を取得することを前提としている。しかしながら、実際には、携帯電話機でワンセグ放送を受信する場合には、自宅とは離れた場所（出張先など）で視聴したい場合もあり、必ずしも自宅の据え置きテレビからの電子番組表を取得するのが適していない場合もある。

本発明は、携帯端末装置の特性を生かして、どの場所であっても、その場所で視聴するテレビ番組に適した電子番組表を取得することを目的とする。

本発明は、情報提供可能な周辺端末相手のバッテリ残量を予め取得しておき、また取得したバッテリ残量を評価し、評価に応じて番組情報を提供してもらう相手を決定し、この相手にスキャン受信を行わせるようにする。そして、スキャン受信の結果として得られた番組情報を得るようにすることを特徴とする。ここで、バッテリ残量に関しては、あるしきい値以上の端末に依頼するか、最もバッテリ残量（駆動時間）に余裕のある端末に依頼するようにしても良い。

本発明の一観点によれば、テレビジョン放送の受信機能を備えた携帯端末装置であって、前記携帯端末装置とは異なる少なくとも１以上の、テレビジョン受信機能を備えた情報提供端末装置からのバッテリ情報を取得するバッテリ情報取得部と、取得したバッテリ情報に基づいて情報提供端末装置のバッテリ残量を判断するバッテリ残量判断部と、自己が保持していない欠損している番組情報を、前記バッテリ残量判断部により取得されたバッテリ残量がある基準値又は他の端末に比べて高い前記情報提供端末装置に対してリクエストするデータ送信依頼部と、リクエストした前記番組情報を受信するリクエスト情報受信部と、を備えた携帯端末装置が提供される。バッテリ残量を考慮することで、情報提供側端末のバッテリ切れなどを抑制することができる。前記データ送信依頼部は、テレビジョン放送の選局処理を現在行っていないチューナ部の残数のある前記情報提供側携帯端末装置を優先的に選択してリクエストを行うことが好ましい。現在使われているチューナ部を利用してしまうと、相手の視聴を妨げることになるからである。前記データ送信依頼部は、選択した前記情報提供側携帯端末装置における現在動作していないチューナ部において、前記欠損している番組情報に対応するチャネルに選局させて番組情報の取得を依頼するようにするのが好ましい。これにより、相手方の端末の視聴等を妨げることなく情報を取得させることができる。バッテリから流れ出す電流値により電力消費量を推定し、前記バッテリ残量に加えて、前記電力消費量が小さい方の前記情報提供側携帯端末装置を優先的に選択してリクエストを行うことようにしても良い。電流値は、現在の端末の使用状況の目安となり、現在のバッテリ残量だけでなくその後のバッテリ残量の減少傾向も推定することができる。表示部に表示されるリソースの使用表示に基づいて電力消費量を推定し、前記電力消費量が小さい方の前記情報提供側携帯端末装置を優先的に選択してリクエストを行うようにしても良い。例えば表示部に表示されるアプリケーション使用表示に基づいて、どの程度のリソースが使用されているかを推定することができる。前記リクエストを行う前に、周辺の前記情報提供側携帯端末装置が現在有している番組情報を予め取得しておくようにすることが好ましい。これにより、相手方のチューナを起動させなくても取得可能な分は事前に取得しておくことで、効率的な情報取得が可能となる。

また、本発明は、テレビジョン受信機能を備えた情報提供側の携帯端末装置であって、前記情報提供側携帯端末装置とは異なるテレビジョン受信機能を備えた情報提供側携帯端末装置からの番組情報提供に応じて、自己のバッテリ情報を提供するバッテリ情報送信部を有し、バッテリ情報を送信した後に、チャネルを指定した番組情報の提供依頼を受信すると、前記チャネルに選局することにより依頼された番組情報を取得し、テレビジョン放送の受信機能を備えた携帯端末装置に送信することを特徴とする携帯端末装置が提供される。前記チャネルに選局する際に、放送の映像を出力する映像表示部と放送の音声を出力する音声出力部とはオフのままにしておくことが好ましい。これにより、番組情報の取得に必要な機能部のみを起動させ、番組情報提供に関する電力消費を抑制することができる。

また上記情報取得側の携帯端末装置と、上記情報提供側の携帯端末装置と、を有することを特徴とする番組情報取得システムであっても良い。

本発明は、通信システム、携帯端末装置における処理方法、この方法をコンピュータにより実行させるためのプログラム、該プログラムを記憶するコンピュータ読み取り可能な記録媒体であっても良い。プログラムは、インターネットなどの伝送媒体によって取得するものであっても良い。

本発明によれば、情報提供側の携帯端末装置のバッテリ切れを防止しつつ、情報取得側の端末側において欠損している番組情報を簡単に取得することができる。

発明者は、上記特許文献１のような自宅の据え置き型のテレビジョン受信装置の代わりに、例えば、契約などによりグループ化された仲間の端末装置のうちテレビ視聴機能（チューナを含む）を備えた情報提供端末装置から番組表を提供してもらう技術を考えた。この場合に、情報提供端末装置が、携帯端末装置、特に携帯電話機などである場合においては、バッテリが切れてしまうと待受などもできなくなるため、バッテリ（電池）残量が０になることを避ける必要がある。番組情報の提供依頼相手のバッテリ残量についてはまったく考慮しない場合には、バッテリ残量が残り少ない相手に対して番組情報の提供依頼を行うことになり、相手方装置のバッテリを消耗させ使い切らせてしまう可能性がある。例えば、ワンセグの番組情報を取得するには、取得したいチャンネルを選局する必要がある。また一度に取得できる番組情報の数も少ない。そのためワンセグの視聴開始時には有効な番組情報が端末内に存在しないことが多く、本来であれば番組選局時の参考となる番組情報を選局前に閲覧することができない。

以下、本発明の一実施の形態による携帯端末装置及び情報提供端末装置について、図面を参照しながら説明を行う。尚、このシステムに参加する情報提供端末装置のユーザは、何らかの契約、登録により以下に説明するような処理を行うことができるようになっていることが前提となる。

図１は、本実施の形態による携帯端末装置及び情報提供端末装置を含む電子番組表取得システムの一構成例を示す図である。図１に示す番組情報取得システムには、番組情報取得側の携帯端末装置１００と、番組情報提供側の情報提供端末１０１、１０２、１０３、…の２種類の端末が存在しており、これらの端末は、放送アンテナ１１からの放送、たとえばワンセグ放送を受信することができるように構成されている。携帯端末装置１００と、情報提供端末１０１〜１０３と、の間の通信手段については、特に限定されるものではないが、例えば、ワイヤレスＬＡＮ、Ｂｌｕｅｔｏｏｔｈ、ＵＷＢ（ウルトラワイドバンド）、家電向けの短距離無線通信規格の一つであるＺｉｇＢｅｅなど（登録商標）を用いることができる。以下に、このシステムの動作の概要について簡単に説明する。
１）携帯端末装置１００においてテレビの視聴を開始すると、番組情報が不足している場合は近くに存在する情報提供端末１０１〜１０３にブロードキャストでの番組情報のリクエストを行う。
２）情報提供端末１０１〜１０３のうちのいずれかは、番組情報提供のリクエストを受けると、それぞれが保持している番組情報と、自己のバッテリ残量に関する情報と、現在利用可能なチューナ残数と、を携帯端末装置１００へ返信する。
４）上記３）の処理によっても不足している場合は、情報提供端末１０１〜１０３のバッテリ情報、チューナ残数を元に、スキャン受信の依頼先を決定、リクエストを行う。
５）リクエストを受けた情報提供端末は依頼されたチャンネルについて番組情報の受信を順次行う。
６）リクエストされたチャンネル分の情報が準備できると、その情報を携帯端末装置１００へ送信する。
７）携帯端末装置１００では、不足分の番組情報をさらに埋めていく。

以上の処理により、携帯端末装置１００は、必要な番組情報、すなわち裏番組に関する情報をすべて持つことになる。

尚、番組に関する情報としては以下の項目があるが、それぞれの項目により重要性が異なる。
ａ）必須項目：番組名、チャネル番号、放送開始時刻、放送終了時刻。
ｂ）情報保持時間は、各端末から集まった番組情報間に食い違いが生じた際、取得した時間が新しい方を採用するために、取得しておくことが望ましい。
ｃ）任意の項目：番組ジャンル大項目、番組ジャンル中項目、番組説明、番組付属情報など。

図２は、本実施の形態による携帯端末装置１００の一構成例を示す機能ブロック図である。図２に示すように、携帯端末装置１００は、情報を受信する情報受信部１８と、各部を制御するＣＰＵ（リクエスト処理部）１６と、処理プログラムを記憶するメモリ１０と、番組情報を記憶する番組情報蓄積部１５と、番組情報蓄積部１５にアクセスするための番組情報アクセス部１４と、エリア情報を記憶するエリア情報蓄積部１９と、チューナ１２１を備えた放送受信部１２と、出力部である表示部１３及びスピーカ２１と、情報送信部１７と、放送受信用のアンテナ１１と、を備えている、ＣＰＵ１６は、相手方の情報提供端末のバッテリの残量を取得するとともに、相手方から番組情報を取得するためのデータ送信を依頼するデータ送信依頼部１６ｂと、バッテリ残量に基づいて、番組情報を実際に取得できる程度の容量を残している端末で有るか否かを判断するバッテリ残量判断部１６ａと、を備えている。

図３は、本実施の形態による情報提供端末１０１の一構成例を示す機能ブロック図である。図３に示すように、情報提供端末１０１（〜１０３）は、情報を受信する情報受信部１８と、各部を制御するＣＰＵ（リクエスト処理部）１６と、処理プログラムを記憶するメモリ１０と、番組情報を記憶する番組情報蓄積部１５と、番組情報蓄積部１５にアクセスするための番組情報アクセス部１４と、エリア情報を記憶するエリア情報蓄積部１９と、端末を駆動するためのバッテリ２０と、バッテリ２０に関する情報（主としてバッテリ残量とバッテリから流れる電流値）を取得するバッテリ情報取得部２０ａと、端末をユニークに識別するための個体識別番号を記憶する個体識別番号記憶部２２と、チューナ１２１を備えた放送受信部１２と、外部への映像及び音声のぞれぞれの出力部である表示部１３及びスピーカ２１と、携帯端末装置から依頼された情報の送信を行う情報送信部１７と、放送受信用のアンテナ１１と、を備えている。ＣＰＵ１６は、情報送信部１７を介してバッテリ残量を送信するバッテリ残量送信部１６ｃと、情報送信部１７に番組情報のデータ送信を依頼するデータ送信受付部１６ｄと、アイコン表示を行うための情報に基づいてアイコン表示を行うアイコン表示制御部１６ｅと、後述するように、アイコン表示を行うための情報に基づいてリソースの使用状況を取得するリソース使用状況取得部１６ｇと、送信データを一時的に格納する送信バッファ１６ｆと、を備えている。チューナ１２１からの情報が番組情報蓄積部１５に送られる。尚、バッテリ残量送信部１６ｃは、自己の機器の現時点でのバッテリ残量などの情報を相手方に送る。データ送信受付部１６ｄは、要求された番組情報などのデータを受け付けて相手方に送る。

アイコン表示判定部１６ｅは、現時点でのリソースの使用状況をアイコン表示に利用している情報を利用しこれに基づいて判定する。リソース使用状況取得部１６ｇにおいて、アイコン表示に利用している情報によりリソースの使用状況を推定できるものとしては、例えば、電池残量表示（３段階の電池残量＋充電中表示）、インターネット接続モードの状態（通常ブラウザ状態又はフルブラウザ起動も推定可能である）、アプリケーションの使用状態（アプリケーションが起動中かどうかを推定できる。）、ＧＰＳの状態（ＧＰＳにより位置を測位中であるか否かを推定することができる。）、ワンセグ録画中表示、赤外線等の無線通信によるデータ通信中表示、マルチタスク表示などである。

尚、マルチタスク表示とは、例えば、多数のアプリケーションが起動中である旨の表示、データ通信中表示、フルブラウザ表示、ワンセグ表示などである。

図４は、本実施の形態による携帯端末装置１００における放送受信部１２の詳細な構成例を示す機能ブロック図である。図４に示すように、放送受信部１２は、放送信号を受信するアンテナ１１と、アンテナ１１から受信した信号に基づいて番組を選局するチューナーモジュール１２１と、トランスポートストリーム（ＴＳ）をＤＥＭＵＸするＴＳＤＥＭＡＸ１２２と、ＴＳＤＥＭＡＸ１２２で処理された信号を受ける、Ｈ．２６４デコーダなどの映像信号のデコーダ１２３、ＡＡＣデコーダなどの音声信号のデコーダ１２４、番組情報取得部１２５と、各部を制御する制御部１２６と、を備えている。このうち、符号ａで示した破線範囲内が、番組情報取得依頼時に起動する。

図５は、図４に示す放送受信部における動作の流れを示すフローチャート図である。まず処理を開始すると（ステップＳ１）、ステップＳ２においてチューナ動作が開始する。次いで、ユーザ操作により処理の開始が指示されると（ＹＥＳ）、ステップＳ４においてチャネル変更操作がなされたかどうかを判定する。チャネル変更操作が行われると（ＹＥＳ）、ステップＳ５に進み、指定チャネルに選局を変更する。チャネル変更操作が行われないと（ＮＯ）、ステップＳ５をスキップし、ＹＥＳの場合と同様にステップＳ６に進み、ＴＳのＤＥＭＵＸが開始される。次いで、ステップＳ７においてＨ．２６４デコーダによるデコードが開始され、ステップＳ８においてＡＡＣデコーダによるデコードが開始される。次いで、ステップＳ９において、番組情報を取得し、ステップＳ１０でテレビ機能をオフするかどうかを判定し、ＹＥＳであれば処理を終了し（エンド：ステップＳ１１）、ＮＯであればステップＳ４に戻る。

ここで、ステップＳ３において、ＮＯの場合にはステップＳ１５に進み、リクエストされたチャネルに選局を変更する。次いで、ステップＳ１６において、ＴＳのＤＥＭＵＸを開始し、ステップＳ１７において番組情報を取得し、ステップＳ１８において、要求されたチャネル全てについて処理が終了しているか否かを判定し、ＹＥＳであれば処理を終了し（ステップＳ１１）、ＮＯであればステップＳ１５で次のチャネルについて処理を行う。このようにして、要求されたチャネルの情報を情報提供端末において順次取得していくことができる。

図６Ａは、バッテリ情報取得部２０ａの一構成例を示す機能ブロック図である。バッテリ情報取得部２０ａは、電圧値取得部１９２と、残駆動時間計算部１９１と、電圧値−残り時間対応テーブル１９３と、を備えている。要するに、図６Ｂに示すように、処理が開始され（スタート：ステップＳ２１）、ステップＳ２２においてリクエスト又はタイマ割り込みが行われると、ステップＳ２３において、電圧値取得部１９２が電圧値を取得し、ステップＳ２４において、取得した電圧値からバッテリの残駆動時間を取得し、ステップＳ２５でバッテリの残駆動時間をバッテリ情報として携帯端末装置に送信し、ステップＳ２６において処理を情報提供端末側における終了する。すなわち、電圧値情報が電圧値取得部１９２に入力されると、例えば電圧値が残駆動時間計算部１９１に出力され、電圧値−残り時間対応テーブル１９３を参照して残り時間を算出し、残り時間を出力する。

また、ブロードキャストされる端末がすべて同じ機種とは限らないため、電圧値をもってバッテリ情報とはできない場合がある（すなわち、機種によってバッテリの電圧値が異なることがある）。また、バッテリの電圧が同じ機種であっても、その消費電力に差がある場合には、残り駆動時間に差が生じる。そこで、この例のように、残駆動時間などの値で機種による差異を補償することが好ましい（残り％で補償しもよい）。

尚、ＡＣ電源が供給されている状態の装置はバッテリ切れの恐れがないため、番組情報の提供を依頼する情報提供端末として最優先させるようにしてもよい。このように、据え置きテレビなどの固定端末も情報提供端末として適用可能である。この場合は、ＡＣ電源から電力が供給されている旨の情報をバッテリ情報と同様に送受することで対応できる。

以下には、バッテリ残量以外の情報も考慮に含める場合について説明する。図７Ａは、装置の使用状態も考慮した例を示す図である。図７Ａに示すバッテリ情報取得部２０ａは、電圧値取得部１９２と、電流値取得部１９４と、残駆動時間計算部１９１と、電圧値、電流値−残り時間対応テーブル１９３と、を備えている。ここで、バッテリから各機能部に流れる例えばバッテリ端における電流値を電流値取得部１９４により取得する。取得した電流値は、情報提供端末のその時の利用状態（現在のバッテリの消費速度など、電流値が大きい程、バッテリの消費速度が早いと推定できる。）を表す値として用いるのに適している。図７Ｂに示すように、携帯端末装置からの番組情報取得リクエストがあると処理を開始し（スタート：ステップＳ３１）、ステップＳ３２において、バッテリ情報のリクエスト又はタイマ割り込みがあると、ステップＳ３３において、例えば、電圧値と電流値とを取得し、ステップＳ３４において、電圧値・電流値から、残駆動時間を推定する。次いで、ステップＳ３５において、推定されたバッテリの残駆動時間などのバッテリ情報を、リクエストしてきた携帯端末装置に対して送信し、この処理を終了する（ステップＳ３６、エンド）。この処理では、情報提供端末の利用状態を電流値により推定し、利用状態を考慮して残駆動時間を算出することにより、より精度の高いバッテリ情報を携帯端末装置に対して提供することができる。すなわち、電力消費がより少ない情報提供端末を選択することが可能となる。

次に、携帯端末装置と情報提供端末におけるテレビ視聴に関する全体処理と、要部処理とについて説明する。図８は、携帯端末装置における処理の流れを示すフローチャート図である。まず、テレビ視聴処理を開始すると（スタートからステップＳ４１）、ステップＳ４２において、番組情報に欠損があるかどうかを判定する。

欠損があれば（ＹＥＳ）ステップＳ４３に進み、情報取得処理を行う。番組情報に欠損がなければ（ＮＯ）、ステップＳ４３をスキップしてステップＳ４４に進み、番組情報を表示部に表示する要求があれば（ＹＥＳ）、ステップＳ４５において表示部に番組情報を表示させる。ステップＳ４４で表示要求がなければ（ＮＯ）、ステップＳ４５をスキップする。いずれの場合でも、ステップＳ４６においてテレビアプリを終了するかどうかの指示に沿って、終了する場合には（ＹＥＳ）処理を終了し（エンド）、終了しない場合には（ＮＯ）、ステップＳ４２に戻る。

次に、図９を参照しながら、情報提供端末における蓄積情報の確認方法についてフローチャート図を参照しながら説明する。まず処理を開始すると（Ｓ６２：スタート）、自身のテレビチューナーに設定されているエリア情報を読み込み（ステップＳ７１）、情報要求側の携帯端末装置から送信されてきた地域設定情報と同じエリアであるかどうかを判定する。同一エリアでなければ（ＮＯ）、その地域設定情報は利用できないため処理を終了する（エンド）。

ステップＳ７２において同一エリアであれば（ＹＥＳ）、ステップＳ７３に進み番組情報を１つ読み込み、ステップＳ７４において現在時刻を取得する。次いで、ステップＳ７５において、既に番組が終了しているか否かを現在時刻と放送時間帯とを比較して判定し、既に終了していれば（ＹＥＳ）、ステップＳ７６をスキップしてステップＳ７７に進み、全データの読み込みを完了したかどうかを判定し、完了していれば（ＹＥＳ）処理を終了し（エンド）、完了していなければ、ステップＳ７３に戻り処理を継続する。ステップＳ７５において番組が終了していなければ（ＮＯ）、ステップＳ７６において、時間帯と番組情報との対応関係を例えばテーブル形式で送信バッファに保持しておく。

図１０は、図８のステップＳ４３の情報取得処理の詳細と、情報提供の処理と、を示すフローチャート図である。図１０に示すように、ステップＳ４３において情報取得処理を開始すると、ステップＳ５１において、エリア情報とともに番組情報を情報提供端末に送信する（リクエスト）。情報提供端末では、処理が開始され、ステップＳ６１において、リクエストを受け付ける（この場合に、例えば、通信手段としてＢｌｕｅｔｏｏｔｈを例にすると、通信機能は常時オンになっている場合を例にして説明する）。次いで、図９に示す蓄積情報の確認処理を行い（ステップＳ６２）、ステップＳ６３において、番組情報とバッテリ残量と、機器ＩＤと、チューナ残数と、を携帯端末装置に対して送信する。チューナ残数については後述する。

これらの情報、すなわち、番組情報と、バッテリ残量と、チューナ残数と、を携帯端末装置に対して送信し（ステップＳ５２において受信し）、携帯端末装置側において、取得した番組情報を統合する処理が行われる。統合処理の例についても図面を参照して後述する。次いで、統合した番組情報に欠損が有るか否かをステップＳ５４において判定する。欠損がなければ（ＮＯ）情報取得処理を終了する（エンド）。欠損があれば（ＹＥＳ）、ステップＳ５５に進み、バッテリ残量と、チューナ残数と、を参照しながらリクエスト先の情報提供端末を選択し決定する処理を行う。この処理の内容についても、統合処理と合わせて後に説明する。

次いで、ステップＳ５６において、リクエスト先の情報提供端末に対して番組情報の返信を依頼する。この際、特定のＩＤを有する情報提供端末宛てにリクエストと必要なチャネル（単数又は複数、時間帯を含む。）と、を送信する（情報提供端末側では、ステップＳ６４でリクエストを受信することになる）。このリクエストに基づいて、自己のテレビ機能を起動し（但し、テレビ機能起動の目的がテレビの視聴ではないため、映像の表示および、音声の出力などは必要ないことから、チューナなど図４ａに示す機能のみを起動すればよい。当然バックライトなどを点灯する必要もないため、リクエストに対しての消費電力を最小限におさえることができる。）、リクエストされた番組情報を取得する（ステップＳ６５）。次いで、ステップＳ６６において、取得した番組情報（リクエストされた番組情報）をリクエスト元の携帯端末装置に対して送信する（ステップＳ５７において、送信された番組情報を取得する。次いで、ステップＳ５８において、取得した番組情報を元からある番組情報と統合し、情報取得処理を終了する。

図１１は、上記の処理により取得した番組情報の統合処理の一例を示すフローチャート図である。すなわち、情報提供端末から取得した情報を携帯端末装置がもつ情報とマージするための処理に相当する。まず、処理を開始し（スタート）、ステップＳ８１において、取得データ（群）から１つ取り出し、ステップＳ８２において、番組情報蓄積部から、上記チャネル、時刻の情報を取り出す。ステップＳ８３において、チャネル、時刻の該当箇所に情報があるか否かを判定し、ｙｅｓであればステップＳ８７に進み、取得データをチャネルの時刻の該当箇所に記録し、ステップＳ８６に進む。ステップＳ８３で該当箇所の情報がある場合には（ＮＯ）、ステップＳ８４に進み、チャネル、時刻の該当箇所と異なる情報であるか否かを判定する。ＮＯの場合、すなわち同じ情報であれば、ステップＳ８６に進む（何もしない）。ＹＥＳであれば、ステップＳ８５に進み、タイムスタンプの新しい方を採用し、新しい情報を記録する。すなわち、情報が異なっている場合は、情報を取得した時刻がより新しい方を最新の情報として番組情報蓄積部に保存する（例えば、番組編成が変更になった場合などにこれで対応することができる）。ステップＳ８６においては、全データの処理が終了したか否かを判定し、ＮＯの場合にはステップＳ８１に戻り、新たな情報の記録を行う。ＹＥＳの場合には、処理を終了する（エンド）。
次に、リクエスト先の決定方法の一例について説明する。

表２は、端末ＩＤと、残駆動時間と、チューナ残数との対応関係を示すテーブルである。一方、図１２は、リクエスト先の決定処理の流れを示すフローチャート図である。図１２に示すように、処理を開始し（スタート）、ステップＳ９１においてチューナ残数が０の端末を除外する。次いで、ステップ９２において、残った端末の中でバッテリ残量等残駆動時間が最も長い端末を探し、処理を終了する（エンド）。表２の場合では、チューナ残数が０のＩＤ１０２が除外され、その後、ＩＤ１０１、ＩＤ１０３のうちから、よりバッテリに余裕があるＩＤ１０３が自動的に選択される。

上記の実施例では、チューナ残数を携帯端末装置側で評価する例について説明したが、この評価を情報提供端末側で行うようにすることもできる。図１３に示すように、処理を開始すると（スタート）、ステップＳ１０１において、残駆動時間順に端末リストをソートする（Ｓｏｒｔ（Ｌｉｓｔ［Ｎ］）。次いで、ステップＳ１０２においてｉ＝１とし、ステップＳ１０３ａにおいてリストｉ番目の端末にチューナ残数確認処理又はリストｉ番目の端末にハードウェアリソースの確認を行わせる。次いで、ステップＳ１０４において、チューナ残数がＯＫであるか否かを判定し、ＹＥＳであればステップＳ１０５において、リクエスト先として決定し、処理を終了する（エンド）。また、ステップＳ１０４において、ＮＯであれば、ステップＳ１０６に進み、ｉ＜Ｎであるか否かを判定する。ここでＮＯであれば、ステップＳ１０７でリクエスト先が無いとし、ＹＥＳであればステップＳ１０８で１＋１としてステップＳ１０３に戻る。これにより、チューナ残数以外のハードウェアリソースの使用状況などを反映することができる。

図１４は、リソース情報を取得した情報取得側の携帯端末装置がリソースに関して判断する処理の流れを示すフローチャート図である。まず処理を開始し（スタート）、ステップＳ１１１において、残駆動時間順に端末リストをソートする（Ｓｏｒｔ（Ｌｉｓｔ［Ｎ］）。１回目の通信により、複数の情報提供端末があればそれぞれのバッテリ残量（残駆動時間）がわかるため、残り駆動時間が長い順に並べ替える。ステップＳ１１２において、ｉ＝１とする。そして、ｉ＝１〜Ｎ（Ｎは１回目でレスポンスを返した情報提供端末の数）の順でリクエスト先の候補となりえるか否かを確認していく。ステップＳ１１１において並び替え処理が既に行われているため、バッテリ残量に余裕のある順番で確認が行われる。

ステップ１１３において、リストｉ番目端末にチューナ残数を確認する（List[i]）。ここで、ループの中ではその情報提供端末に利用可能なチューナが存在しているかを確認する。このチューナに関する情報も１回目の情報提供処理で取得しているものとする。次いで、ステップＳ１１４において、チューナ残数の応答の結果がＯＫであるかどうかを判定する。ＹＥＳの場合には、ステップＳ１１５ｂに進み、リクエスト先を決定し（Ｌｉｓｔ［ｉ］）、処理を終了する（エンド）ステップＳ１１４でＮＯの場合には、ステップＳ１１６に進み、ｉ＜Ｎであるか否かを判定する。判定結果がＮＯであれば、ステップＳ１１７に進みリクエスト先無しとなり処理を終了する（エンド）。ステップＳ１１６でＹＥＳの場合には、ステップＳ１１８に進み、ｉ＋１を行い、ステップＳ１１３に戻る。このようにして、チューナが利用可能であればその端末をリクエスト先に決定する。チューナが利用不可であれば、次の候補を確認する（ステップＳ１１５）。リストの最後までチューナを利用できる端末が存在しない場合はステップＳ１１７となり、リクエスト無しとして処理が終了する。

図１５は、情報提供端末がリソースに関して判断する例を示すフローチャート図である。処理の概要について、表２を参照して説明すると、まず、チューナ残数が０の端末には依頼できないためそれを除外し、次いで、除外されずに残った端末の中で最も残駆動時間が長い端末を探して、番組情報の提供を依頼する。この処理のより具体的な内容が図１５に示すように、まず、処理を開始し（スタート）、ステップＳ１２１において、残駆動時間順に、端末リストをソートする（Ｓｏｒｔ（ＬＩｓｔ［Ｎ］）。

ステップＳ１２２において、ｉ＝１とする。次いで、ステップＳ１２３において、リストｉ番目の検索にハードウェアリソースの確認を行う。ステップＳ１２４において、チューナ残数がＯＫであるかどうかを判定する。ＹＥＳであれば、ステップＳ１２５に進み、リクエスト先を決定し（Ｌｉｓｔ［ｉ］）、処理を終了する（エンド）。ステップＳ１２４でＮＯの場合には、ステップＳ１２６に進み、ｉ＜Ｎであるか否かを判定する。ＮＯであればステップＳ１２７でリクエスト先なしとして処理を終了する（エンド）。ステップＳ１２６でＹＥＳであれば、ステップＳ１２８に進み、ｉ＋＋を行ってステップＳ１２３に戻る。

この処理は、図１４に示す処理の変形例であり、図１４に示す処理が１回目の通信で取得した情報を利用しているのに対して、リスト中のi番目の情報提供端末にハードウェアリソースの空きを問い合わせるように変更された処理である。図１４の処理では、周辺端末からチューナの利用可否情報を取得した携帯端末装置においてリクエスト先を決定している。図１５に示す処理では、その部分を情報提供端末に委ねたものである。

チューナ残数など単純な情報だけで判断するのであれば、情報取得側で判断させることも可能であるが、ここにＣＰＵの稼働率やメモリの利用率など様々な指標を考慮していくと、そのような判断のための情報を全て送信する必要がある。従って、ある程度以上複雑な判断が必要になってきた場合には、その判断自体を相手側（情報提供端末側）に任せてしまった方がよい。

図１６以降は、上述の番組表データ取得の様子を示す図である。図１６（ａ）は、テレビの視聴を開始した端末（携帯端末装置）１００の表示部に番組表を表示させた様子を示す図である。図に示すように、端末Ａの表示部には、バッテリ情報表示欄２０１と、視聴開始表示欄２０３と、番組欄チャネル軸２０７と、時間帯軸（現在番組２１１、次の番組２１３、その次の番組２１５）との２次元的なマトリックス構造を有している表示２０５を有している。

一方、図１６（ｂ）に示す携帯端末装置の例えば周辺（特に周辺に限定されるものではないが近くの端末の方が番組情報を共有しやすいので好ましい。）に存在するテレビ機能付き情報提供端末に示すように、視聴を開始した端末１０１ａでは、バッテリ残量表示欄３０１と、テレビ視聴・未視聴表示欄３０３と、番組表表示欄３０５（チャネル軸３０７、時間軸３１１・３１３・３１５）とを有しており、符号１０１ａの端末では、バッテリ残量３０１が５０％、視聴・未視聴（状況）３０３が未視聴であり、チャネル２の現在・次番組と、チャネル３の現在番組情報を保持している。符号１０１ｂの端末では、バッテリ残量３０１が９５％、視聴中であり、チャネル１・２の現在番組と、チャネル３の現在番組３１１からその次の番組３１５番組までの全ての情報を保持している。符号１０１ｃの端末では、バッテリ残量３０１が９０％、未視聴であり、チャネル１の現在番組と、チャネル３の現在番組情報を保持している（この様子は例示である）。

図１７（ａ）に示すように、視聴中のチャネル（この場合にはチャネル１）ｄ１については、自己の端末で番組情報を取得することができる。すなわち、視聴していないチャネルｄ２・ｄ３については、視聴を中断しない限り番組情報を取得することはできない。そこで、図１７（ｂ）に示すように、まず、周辺に存在するテレビ付きの提供側の端末の中で、テレビ視聴中の端末１０１ｂから、番組情報を取得することを考える。ここでは、端末Ｃ１０１ｂが視聴中であり、チャネル３の列（ｆ３）が取得可能であるから、この番組情報を取得することができる。

そこで、図１８に示すように、番組情報を端末Ｂ〜Ｄ１０１ａ〜ｃにより取得することができる番組情報を符号１０１ｔ１で示されている。符号ｈ１ではチャネル１の現在番組が、ｈ２ではチャネル２の現在・次番組が、ｈ３ではチャネル３の全ての時間帯の番組が取得可能であることがわかる。

図１９は、このようにして取得した番組情報により端末Ａ１００の番組情報を補充していった例を示す図であり、ほぼ全ての番組情報を得ることができている。しかしながら、周辺の端末が少ない場合、チャネル数が少ない場合には、全てのチャネル・時間帯の番組情報を得ることは保証されない。ここでは、符号１０１ｔｚで示す表示のように、チャネル２のその次の番組の情報を欠損している。

そこで、図２０に示すように、テレビ機能が使われていない周辺の端末の中で、バッテリ残量に最も余裕のある端末(図に示す例では端末Ｄ１０１ｃ）に必要なチャネル（この例ではｃｈ２）の選局とデータ取得とを依頼する（依頼はチャネル単位で行うことができる）。

尚、バッテリ残量が高い、又は、余裕がある端末との記載は、１）端末Ａ１００が保持している基準値よりも高い端末であることを意味する。或いは、２）複数の端末Ｂ〜Ｄにおいて相対的にバッテリ残量が高いこと端末を選択するようにしても良い。上記１）、２）の両方の基準に基づいて判断するようにしても良い。

尚、本実施の形態における情報提供端末は、固定型のテレビジョン受信装置であっても良く、その場合には、バッテリ消耗の問題のない固定型のテレビが優先的に選ばれる対象とすることが可能である。

図２１は、未視聴であった端末Ｄ１０１ｃに対して、端末Ａ１００で番組情報が欠損しているチャネルであるチャネル２に選局して符号ｋ１−ｋ１’で示すようにチャネル２の次の次の番組情報を代理で取得してもらい、それを、端末Ａ１００に送信してもらうことで、欠損している番組情報を補完している様子を示す図である。

尚、上述したように、情報提供端末にチューナが１つしかない場合には、その端末が視聴中の場合もあるため、利用可能チューナ残数も考慮に入れて依頼を行う必要がある。さらに、チューナ残数以外の要因によっても受信できない場合がある。例えば、ハードウェアリソースに余裕がなく、これ以上、他のアプリを起動できないときなどが該当する。

以上に説明したように、本実施の形態によるシステムにおいては、周辺の端末のうち、バッテリ残量などに余裕のある端末に、自己の番組情報の欠損分を補填してもらうために、欠損しているチャネルのチューナを起動させ、番組情報を代理で取得して送ってもらうように構成したことにより、自己が視聴中であってもその視聴を中断させずに、多くの番組情報を得ることができる。この際、提供側端末のバッテリ残量を考慮するため、提供側端末のバッテリ切れなどを防止することができる。従って、システム全体として、特に不利益になることはなく、所望の番組情報を補完することができる。

次に、本発明の実施の形態の第１変形例によるテレビ機能付き携帯端末システムについて説明する。図２２は、情報提供側端末の処理の流れを示すフローチャート図である。図２２に示すように、まず処理を開始し、ステップＳ２０１においてバッテリ残量＞α（αは所定の値）であるか否かを判定し、ＹＥＳであればステップＳ２０２において待受を開始し、ＮＯであればステップＳ２０３において待ち受けを停止する。いずれの場合も処理を終了させる。この実施例の考え方は、全ての端末がリクエストの待ち受け状態にあるというのは現実的ではない点を考慮したものである。例えば、残りバッテリ残量がわずかな端末の場合には、たとえわずかな時間であっても通信させたくない。また、いつ依頼が来るかかわらない通信に関する待機を継続的に行わせることも好ましくない。そこで、図２２の処理に示すように待受を行うか、行わないかを自身のバッテリ残量に応じて決定する。尚、この場合に、バッテリ残量は前述の残駆動時間や残量を％で表した数値により評価を行うようにしても良い。この手法を用いることで、携帯端末におけるバッテリ残量の低下を抑制し省エネルギー化に寄与することができる。

次に、本発明の実施の形態の第２変形例によるテレビ機能付き携帯端末システムについて説明する。図２３は、本変形例による処理の流れを示すフローチャート図である。まず前提として、周辺の情報提供端末は、１回目の通信時に自身の個体識別番号のハッシュ値を作成、機器ＩＤとして情報要求側端末に送信しておく。次に、携帯端末装置は、番組情報の送信のリクエストを行う情報提供端末を決定すると、リクエスト先に指定したい端末から取得したハッシュ値を周辺端末に向けて送信する。

情報提供端末は、送信されたリクエストを受信すると、図２３に示すように、ステップＳ２１１において、リクエストからハッシュ値を取り出し（→Ａとする）、ステップＳ２１２において、自己の個体識別番号を読み出し（→Ｂとする）、ステップＳ２１３において、Ｃ＝ＨＡＳＨ（Ｂ）によりＣを求める。次いで、ステップＳ２１４において、Ａ＝Ｃであるか否かを判定する。この判定結果がＹＥＳであれば、自身に対するリクエストと判定しリクエストに対する応答処理を開始する（ステップＳ２１５）。ＮＯであれば自身へのリクエストではないと判定されるため、そのまま処理を終了する（エンド）。
これにより、チューナ起動の依頼が自己の端末宛てであるかどうかを判断することができる。その際、個体識別番号を外部にさらすことがない。すなわち、特定の端末に依頼する場合に、個体識別番号が不要となる。

また、上記の実施の形態において、添付図面に図示されている構成等については、これらに限定されるものではなく、本発明の効果を発揮する範囲内で適宜変更することが可能である。その他、本発明の目的の範囲を逸脱しない限りにおいて適宜変更して実施することが可能である。また、上記の実施の形態では、テレビジョンの放送波を受信してコンテンツを視聴する例について説明したが、放送波がテレビジョン放送であることは必須でなく、ラジオ放送やインターネット放送であっても良い。また、いわゆる「放送（ブロードキャスト）」ではなく特定多数に配信するマルチキャスト「通信」にも本発明を適用することができる。

本実施の形態で説明した機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより各部の処理を行ってもよい。尚、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。

また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。

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

本発明は、テレビ付き携帯端末装置に利用可能である。

本発明の一実施の形態による携帯端末装置を含む電子番組表取得システムの一構成例を示す図である。 本実施の形態による携帯端末装置の一構成例を示す機能ブロック図である。 本実施の形態による情報提供端末の一構成例を示す機能ブロック図である。 本実施の形態による携帯端末装置における放送受信部の詳細な構成例を示す機能ブロック図である。 図４に示す放送受信部における動作の流れを示すフローチャート図である。 バッテリ情報取得部の一構成例を示す機能ブロック図である。 図６Ａに示す構成の処理の流れを示すフローチャート図である。 装置の使用状態も考慮した例を示す図である。 図７Ａに示す構成の処理の流れを示すフローチャート図である。 携帯端末装置における処理の流れを示すフローチャート図である。 情報提供端末における蓄積情報の確認処理の流れを示すフローチャート図である。 図８のステップＳ４３の情報取得処理の詳細と、情報提供の処理と、を示すフローチャート図である。 取得した番組情報の統合処理の一例を示すフローチャート図である。 リクエスト先の決定処理の流れを示すフローチャート図である。 チューナ残数を情報提供端末側で評価する処理の流れを示すフローチャート図である。 リソース情報を取得した情報取得側が判断する処理の流れを示すフローチャート図である。 情報提供側が判断する例を示すフローチャート図である。 番組表データ取得の様子を示す一連の図である。 番組表データ取得の様子を示す一連の図である。 番組表データ取得の様子を示す一連の図である。 番組表データ取得の様子を示す一連の図である。 番組表データ取得の様子を示す一連の図である。 未視聴であった端末Ｄ１０１ｃに対して、端末Ａ１１で番組情報が欠損しているチャネルであるチャネル２に選局して符号ｋ１−ｋ１’で示すようにチャネル２の次の次の番組情報を代理で取得してもらい、それを、端末Ａ１１に送信してもらうことで、欠損している番組情報を補完している様子を示す図である。 本発明の実施の形態の第１変形例によるテレビ機能付き携帯端末システムにおける、情報提供端末における処理の流れを示すフローチャート図である。 本発明の実施の形態の第２変形例によるテレビ機能付き番組情報提供システムによる処理の流れを示すフローチャート図である。

符号の説明

１０…メモリ、１１…アンテナ、１２…放送受信部、１３…表示部、１４…番組情報アクセス部、１５…番組情報蓄積部、１６…ＣＰＵ（リクエスト処理部）、１６ａ…相手方バッテリ残量判断部、１６ｂ…データ送信依頼部、１７…情報送信部、１８…情報受信部、１９…エリア情報蓄積部、２０…バッテリ、２０ａ…バッテリ情報取得部、２１…スピーカ、１００…携帯端末装置、１２１…チューナ。

Claims (9)

1. テレビジョン放送の受信機能を備えた携帯端末装置であって、
   前記携帯端末装置とは異なる少なくとも１以上の、テレビジョン受信機能を備えた情報提供端末装置からのバッテリ情報を取得するバッテリ情報取得部と、
   取得したバッテリ情報に基づいて情報提供端末装置のバッテリ残量を判断するバッテリ残量判断部と、
   自己が保持していない欠損している番組情報を、前記バッテリ残量判断部により取得されたバッテリ残量がある基準値又は他の端末に比べて高い前記情報提供端末装置に対してリクエストするデータ送信依頼部と、
   リクエストした前記番組情報を受信するリクエスト情報受信部と
   を備えた携帯端末装置。
2. 前記データ送信依頼部は、テレビジョン放送の選局処理を現在行っていないチューナ部の残数のある前記情報提供端末装置を優先的に選択してリクエストを行うことを特徴とする請求項１に記載の携帯端末装置。
3. 前記データ送信依頼部は、選択した前記情報提供端末装置における現在動作していないチューナ部において、前記欠損している番組情報に対応するチャネルに選局させて番組情報の取得を依頼することを特徴とする請求項１又は２に記載の携帯端末装置。
4. 前記バッテリから流れ出す電流値を取得することにより前記情報提供端末装置の電力消費量を推定し、前記バッテリ残量に加えて、前記電力消費量が小さい方の前記情報提供端末装置を優先的に選択してリクエストを行うことを特徴とする請求項１から３までのいずれか１項に記載の携帯端末装置。
5. 表示部に表示させるリソースの使用状況に基づいて電力消費量を推定し、前記電力消費量が小さい方の前記情報提供端末装置を優先的に選択してリクエストを行うことを特徴とする請求項１から３までのいずれか１項に記載の携帯端末装置。
6. 前記リクエストを行う前に、前記情報提供端末装置が現在有している番組情報を予め取得しておくことを特徴とする請求項１から５までのいずれか１項に記載の携帯端末装置。
7. テレビジョン受信機能を備えた情報提供端末装置であって、
   前記情報提供端末装置とは異なる、テレビジョン受信機能を備えた携帯端末装置からの番組情報提供に応じて、自己のバッテリ情報を提供するバッテリ情報送信部と、
   前記バッテリ情報を送信した後に、チャネルを指定した番組情報の提供依頼を受信する受信部と、
   前記チャネルに選局することにより提供を依頼された番組情報を取得する番組情報取得部と、を有し、
   取得した前記番組情報をテレビジョン放送の受信機能を備えた携帯端末装置に送信することを特徴とする情報提供端末装置。
8. 前記チャネルに選局する際に、放送の映像を出力する映像表示部と放送の音声を出力する音声出力部との少なくともいずれか一方はオフのままにしておくことを特徴とする請求項７に記載の情報提供端末装置。
9. 請求項１から６までのいずれか１項に記載の携帯端末装置と、請求項７又は８に記載の情報提供端末装置と、を有することを特徴とする番組情報取得システム。

Images