JP5282745B2 - 移動端末 - Google Patents

Description

本件は、移動端末に関する。

近年、ワンセグ放送などの放送を受信する機能を有する携帯端末装置として、テレビ放送受信機能付携帯電話装置（ＴＶ付携帯電話）が広く提供されつつある。さらに、テレビ放送の受信機能を有する携帯端末装置としては、携帯電話のみならず、例えば、ＰＤＡ（Personal Digital Assistance）やノート型パーソナルコンピュータ（ノートパソコン）、携帯型ゲーム器など、種々のものが出現してきている。

ところで、最近では、ワンセグ放送を利用した新たな放送サービスの１つとして、路上等に設置された基地局から半径数ｍ〜数十ｍ程度の狭いエリア限定で、その地域の情報を提供するローカル放送サービスが出現してきている。このサービスは、電波出力の上限を設定することにより、誰もが無免許で放送局を設置できるものである。これを利用することで、例えば商店街ごとあるいは店舗ごとに独自の放送（例えば、コマーシャル放送など）を行うことができるので、今後、広く利用されることが想定される。

このようなローカル放送サービスでは、基地局から一定範囲内でしか放送波を受信できないという制約があること、及び新規の放送局が多数出現しうることから、ユーザは場所ごとにローカル放送波をサーチする必要がある。これに対し、最近では、特許文献１のように、ローカル放送波のサーチを自動的に行う技術が提案されている。

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

しかしながら、ローカル放送波のサーチが頻繁に行われる場合、電力を無駄に消費するおそれがある。

そこで本件は上記の課題に鑑みてなされたものであり、省電力化を図ることが可能な移動端末を提供することを目的とする。

本明細書に記載の移動端末は、放送番組に関する番組データを取得する取得手段と、前記取得手段により取得した番組データに基づく報知を行う報知手段と、現在位置の情報を取得する位置情報取得手段と、前記取得手段により番組データの取得を行う領域の情報を保持する保持部と、前記位置情報取得手段が取得した現在位置の情報と、前記保持部に保持された領域の情報とに基づいて、前記現在位置が前記領域の情報で示される領域内にあるか否かを判定する判定手段と、前記判定手段により前記現在位置が前記領域内にあると判定された場合に、前記取得手段による前記番組データの取得頻度を、前記現在位置が前記領域内にないと判定されたときの取得頻度よりも高く設定する設定手段と、を有する移動端末である。

本明細書に記載の移動端末は、省電力化を図ることができるという効果を奏する。

第１の実施形態に係るワンセグ放送システムの構成を模式的に示す図である。 ワンセグ受信機の構成を示すブロック図である。 ニーズ設定処理を示すフローチャートである。 ニーズ登録画面を示す図である。 図５（ａ）は、カテゴリテーブルを示す図であり、図５（ｂ）は、エリアテーブルを示す図であり、図５（ｃ）は、ニーズテーブルを示す図である。 エリアを規定する２地点を示す図である。 番組データの取得及び放送受信に関する処理を示すフローチャートである。 番組表作成処理を示すフローチャートである。 図９（ａ）、図９（ｂ）は、第１の実施形態のワンセグ受信機で受信するデータのデータ構造を示す図である。 第１の実施形態の番組表テーブルを示す図である。 放送受信処理を示すフローチャートである。 第２の実施形態に係るワンセグ放送システムの構成を模式的に示す図である。 第２の実施形態のワンセグ受信機の構成を示すブロック図である。 図１４（ａ）、図１４（ｂ）は、第２の実施形態のワンセグ受信機で受信するデータのデータ構造を示す図である。 第２の実施形態の番組表テーブルを示す図である。 第３の実施形態に係るワンセグ放送システムの構成を模式的に示す図である。 第３の実施形態のワンセグ受信機の構成を示すブロック図である。 第３の実施形態におけるニーズ設定処理を示すフローチャートである。 第３の実施形態における放送受信に関する処理（Ｐｕｓｈ配信サーバ側）を示すフローチャートである。 第３の実施形態における放送受信に関する処理（ワンセグ受信機側）を示すフローチャートである。

≪第１の実施形態≫
以下、移動端末の第１の実施形態について、図１〜図１１に基づいて詳細に説明する。図１には、移動端末としてのワンセグ受信機１０を含むワンセグ放送システム１００の構成が模式的に示されている。

この図１に示すように、ワンセグ放送システム１００は、ローカル放送局としてのワンセグコンテンツ配信サーバ５０と、街中に配置された多数の送信機３０と、送信機３０からワンセグ放送を受信することが可能なワンセグ受信機１０と、を有する。

ワンセグコンテンツ配信サーバ５０は、ローカルワンセグ放送（一地域で放送される、商店街や店舗に関するコマーシャル（ＣＭ）など）の放送データ（番組コンテンツ）を送信機３０に対して送信する。また、これとともに、番組データ（番組の放送開始時間、終了時間等に関する情報）を送信機３０に対して送信する。

送信機３０は、数ｍ〜数十ｍの範囲にローカルワンセグ放送データ（番組コンテンツ）や番組データを配信する。この送信機３０は、図１のＡ地域、Ｂ地域、Ｃ地域などに分散して配置されており、各地域で、放送データや番組データが異なっているものとする。

ワンセグ受信機１０は、例えば、ワンセグ放送及びローカルワンセグ放送を受信することが可能な携帯電話、ＰＨＳ、ＰＤＡ、あるいはワンセグ放送及びローカルワンセグ放送受信専用のポータブル受像機などの移動端末である。このワンセグ受信機１０は、図２に示すように、表示画面２４と、入力部２６と、制御部２８と、を有している。

表示画面２４は、液晶ディスプレイや有機ＥＬディスプレイを含み、ローカルワンセグ放送や当該ローカルワンセグ放送の番組表などを表示する。入力部２６は、タッチパネルやキーボードを含み、ユーザの入力を受け付ける機能を有している。ユーザは、入力部２６から、自己のニーズを登録する操作を行ったり、ワンセグ放送のチャンネルを切り替えたりすることができる。制御部２８は、ＣＰＵやＲＯＭ、ＲＡＭ等を含んでおり、ＲＡＭに格納されたプログラムにより、図２に示す各部の機能が実現される。具体的には、図２に示すように、ワンセグ受信機１０では、受信部１２と、表示制御部１３と、取得部１４と、報知部１６と、位置情報取得部１８と、登録部２０と、判定手段及び設定手段としての取得頻度設定部２２と、の機能が実現されている。

受信部１２は、送信機３０を介して、ワンセグコンテンツ配信サーバ５０から送信されるローカルワンセグ放送データや番組データを受信する。表示制御部１３は、入力部２６から入力されるチャンネル情報と、受信部１２で受信した放送データに基づいて、表示画面２４上に番組コンテンツを表示する。なお、受信部１２と表示制御部１３により、チューナとしての機能が実現されている。

取得部１４は、受信部１２において受信された番組データを取得して、番組表を作成する。報知部１６は、取得部１４による番組データの取得結果（又は番組表の作成結果）に基づいて、ユーザのニーズに応じた番組の情報をユーザに報知するものである。報知の方法としては、ユーザのニーズに応じた番組の情報を表示画面２４上に表示するほか、音や振動により表示画面２４上に番組の情報を表示したことをユーザに報知することもできる。

位置情報取得部１８は、現在位置を取得する。この位置情報取得部１８の現在位置取得方法については、後述する。

登録部２０は、ユーザの操作を受け付けて、ユーザが入力したエリア（情報を得たいエリア）を登録したり、ユーザが入力したカテゴリ（嗜好に合っていて、情報を得たいと考えるカテゴリ）の登録を行う。なお、本実施形態では、登録部２０は、登録したエリアの情報及びカテゴリの情報を保持（記憶）する保持部を有している。

取得頻度設定部２２は、位置情報取得部１８が取得した現在位置と、登録部２０で登録された登録エリアとの関係に基づいて、取得部１４による番組データの取得頻度（番組表の作成頻度）を設定する。

次に、本実施形態のワンセグ受信機１０における処理について、図３〜図１１に基づいて、詳細に説明する。まず、ユーザの入力に基づいて、ワンセグ受信機１０において実行される設定処理について説明する。

図３に示すように、ワンセグ受信機１０の登録部２０では、まず、ステップＳ１０において、入力部２６を介してユーザからの初期設定指示、又は設定変更指示が出されたか否かを判断する。ここでは、例えば、ワンセグ受信機１０のメニュー画面から、「設定」のメニューが選択され、更に、「ニーズ登録初期設定又は設定変更」のメニューが選択された場合に、ステップＳ１０の判断が肯定される。ここでの判断が肯定されると、ステップＳ１２に移行する。なお、ステップＳ１０が否定された場合には、肯定されるまでステップＳ１０が繰り返される。

ステップＳ１２に移行すると、登録部２０は、表示画面２４上に、図４に示すようなニーズ登録画面を表示する。このニーズ登録画面は、図４に示すように、エリア選択とカテゴリ選択ができるようになっている。このうち、エリア選択では、エリアを地域から選択したり、路線（最寄駅など）から選択したりすることができる。一方、カテゴリ選択では、グルメ、ショッピング、映画、イベント、スポーツなどのカテゴリを選択するとともに、それらカテゴリの中でも更にカテゴリを絞り込んで選択することができる。例えば、グルメの項目を選択すると、更に、和食、洋食などのカテゴリが選択できるようになり、更に和食であれば、ソバやうどんなどの更なる絞り込み選択もできる。

図３に戻り、ステップＳ１４に移行すると、登録部２０は、ニーズが全て設定済みか否かを判断する。ここでの判断が否定された場合には、ステップＳ１６に移行し、登録部２０は、ユーザによりニーズが選択されたか否かを判断する。ここでの判断が肯定された場合には、ステップＳ１８に移行して、カテゴリテーブル（図５（ａ））又はエリアテーブル（図５（ｂ））に基づいて、ニーズテーブル（図５（ｃ））を作成する。

ここで、図５（ａ）に示すカテゴリテーブルは、レベル１、レベル２というように段階的にカテゴリが定められており、レベル１では、グルメ、ショッピング、エンターテイメントなどに対してカテゴリコードが定義されている。また、レベル２では、例えば、グルメ（Ｇ１０００）に関連するカテゴリ（下位概念のカテゴリ）である、和食、中華、フレンチなどに対して、カテゴリコードが定義されている。なお、図５（ａ）においては、グルメの下位概念のカテゴリ（和食、中華、フレンチ等）のカテゴリコードのアルファベット部分「Ｇ」と、その次の数字「１」が共通するようになっている。また、図５（ａ）には図示されていないが、和食の下位概念のカテゴリ（うどん、そば等）では、カテゴリコードのアルファベット部分「Ｇ」と、その次の２桁の数字「１１」が共通するようになっている。

一方、図５（ｂ）に示すエリアテーブルでは、渋谷、新宿、銀座などの地名が、２つの地点（地点（１）（経度（１）、緯度（１））と、地点（２）（経度（２）、緯度（２）））で定義されている。ここで、エリアを定義する２つの地点としては、図６に示すように、渋谷や新宿、銀座などの地名で表される領域の全て（又は一部）が入る矩形領域の対角の頂点を採用することができる。

また、図５（ｃ）に示すニーズテーブルでは、ユーザのニーズとして、カテゴリと地名とを紐付けして登録する。例えば、図５（ｃ）のニーズ１には、「渋谷」の「和食」というニーズが登録され、ニーズ２には、「新宿」の「フレンチ」というニーズが登録されている。このニーズテーブルでは、ユーザの設定した数だけ、ニーズが登録されるものとする。なお、設定できる数には上限を設けても良い。

その後、ステップＳ１４に戻り、ステップＳ１４の判断が否定された場合には、ステップＳ１６、Ｓ１８を上記と同様に実行するが、ステップＳ１４の判断が肯定された場合には、ステップＳ２０に移行する。ステップＳ２０では、登録部２０が、ニーズ登録画面を非表示にして、ステップＳ１０に戻る。

以上のようにして、図３の処理を実行することで、登録部２０では、ユーザのニーズが、１つ又は複数登録されるようになっている。

次に、図７に基づいて、ローカルワンセグ放送の番組データ及び番組表の取得及び放送受信に関する処理について説明する。図７は、ローカルワンセグ放送の番組データ及び番組表の取得及び放送受信に関する処理を示すフローチャートである。

図７のステップＳ３０では、取得部１４が、設定時間が経過したか否かを判断する。ここで、設定時間とは、予め設定された初期時間であり、例えば、３分に設定されているものとする。ここでの判断が否定された場合には、ステップＳ３０を繰り返すが、判断が肯定された場合には、ステップＳ３２に移行する。

ステップＳ３２では、取得部１４が、番組表作成処理のサブルーチンを実行する。このサブルーチンでは、図８の処理を実行する。図８では、取得部１４が、ステップＳ５０において、パケット分割されているデータを受信する。ここで、パケット分割されているデータとは、図９（ａ）に示すようなデータである。このうち、番組情報識別子が付加されているパケットのデータ領域には、図９（ｂ）に示すように、番組の名称、放送開始日時、終了日時、放送緯度、経度、カテゴリコード及び内容が含まれているものとする。

図８に戻り、次のステップＳ５２では、取得部１４が、最終パケットの処理が済んだか否かを判断する。ここでの判断が肯定された場合には、図７のステップＳ３４に移行するが、判断が否定された場合には、ステップＳ５４に移行する。ステップＳ５４では、取得部１４が、パケット識別子が番組情報識別子であるか否かを判断する。ここでの判断が否定された場合には、ステップＳ５２に戻るが、肯定されると、ステップＳ５６において、取得部１４が、番組に関する情報（番組データ）を取り出し、番組表テーブルに追加する。番組表テーブルは、図１０に示すようなテーブルである。この図１０の番組表テーブルは、番組情報データを「放送開始日時」の早い順に並べたものである。

上記処理を行い、ステップＳ５２の判断が肯定されると、図８の番組表作成処理の全処理を終了して、図７のステップＳ３３に移行する。

図７のステップＳ３３では、位置情報取得部１８が、ユーザの現在位置を取得する。ここで、位置情報取得部１８では、ステップＳ３２の番組表作成処理において作成された番組表から、放送緯度、放送経度を取得することで、ユーザが存在しているエリア（現在位置）を取得する。

次いで、ステップＳ３４では、取得頻度設定部２２が、ユーザが現在位置しているエリアが、ニーズテーブルに登録されているエリア内であるか否かを判定する。図１の例では、ユーザが現在位置しているエリア（Ａ地域）がニーズテーブルに登録されているか否かを判定する。ここでの判断が肯定された場合には、取得頻度設定部２２は、ステップＳ３６において設定時間をａ分（ａ分は例えば３分とする）に設定する。一方、ステップＳ３４の判断が否定された場合には、取得頻度設定部２２は、ステップＳ３８において、設定時間をｂ分（ａ分よりも長い時間、例えば３０分とする）に設定する。

次いで、ステップＳ４０では、表示制御部１３が、番組表データの中に、ニーズにあった放送があるか否かを判断する。ここで、ニーズに合った放送とは、カテゴリのニーズのほか、エリアのニーズも合致している放送であるものとする。ステップＳ４０では、例えば、登録されているカテゴリが図５（ａ）のグルメ（Ｇ１０００）である場合には、その下位概念である、和食（Ｇ１１００）や中華（Ｇ１２００）などの放送も、ニーズに合致する放送であるものとして扱う。この場合、グルメのカテゴリコードの前半部「Ｇ１」と、和食（Ｇ１１００）や中華（Ｇ１２００）などのカテゴリコードとの比較により、ニーズに合致するか否かを判定する。一方、和食（Ｇ１１００）の下位概念であるそば（例えば、Ｇ１１０８）がニーズとして登録されている場合に、うどん（例えば、Ｇ１１０５）のＣＭが番組表に存在している場合には、ニーズは合致しないものとして取り扱う。ただし、これに限られるものではなく、そばと、うどんは類似する（カテゴリコードが類似する）ものとして、ニーズが合致すると判定しても良い。

ここでの判断が否定された場合には、ステップＳ３０に移行し、ステップＳ３６又はステップＳ３８で設定された設定時間間隔で、ステップＳ３２以降の処理が実行されるようになっている。すなわち、ユーザが登録したエリア内に位置している場合には、頻繁に（ａ分ごとに）番組データを取得して、番組表を作成（更新）し、登録したエリア内に位置していない場合には、比較的長い時間間隔（ｂ分ごと）で、番組表を作成（更新）するようにしている。

これに対し、ステップＳ４０の判断が肯定された場合には、ステップＳ４２の放送受信処理のサブルーチンを実行する。

ステップＳ４２のサブルーチンでは、図１１のフローチャートに沿った処理を実行する。図１１のステップＳ６０では、表示制御部１３が、放送開始までの時間を算出する。この場合、ユーザのニーズに合った放送の放送開始日時（時刻）を、図１０の番組表テーブルから取得し、その放送開始日時（時刻）から現在日時（時刻）を差し引くことで、放送開始までの時間を算出する。

次いで、ステップＳ６２では、表示制御部１３が、放送開始までの時間がｍ秒以下であるか否かを判断する。ここで、ｍ秒は、ユーザなどが設定することができ、例えばｍ＝５（秒）などとすることができる。なお、このステップＳ６２の判断が否定された場合には、ステップＳ６０に戻るが、ステップＳ６２の判断が肯定された場合には、ステップＳ６４に移行する。

ステップＳ６４では、表示制御部１３が、報知部１６を介して、ユーザに、ニーズに合った放送（ＣＭ放送）があることを通知する。この場合、報知部１６は、表示画面２４における表示で報知を行っても良いし、不図示のスピーカからの音の出力や、不図示の振動機構（バイブレータ）による振動の発生により、報知を行っても良い。また、例えば、自動的にワンセグ放送を視聴するためのソフトを立ち上げても良い。

次いで、ステップＳ６６では、受信部１２が、ローカルワンセグ放送（ＣＭ放送）の受信を開始し、表示制御部１３が、表示画面２４上にローカルワンセグ放送の表示を開始する。すなわち、受信部１２と表示制御部１３により実現されるチューナを起動する。このようにすることで、ユーザは、自己のニーズ（エリア、カテゴリ）に合った放送を、放送開始まで別の放送を視聴しながら待つことなく、視聴することが可能となる。なお、受信部１２に対する電力供給は、常時行っていても良いが、これに限らず、番組データを受信するとき、及び番組を視聴するときにのみ行うこととしても良い。

以上、詳細に説明したように、本実施形態によると、ワンセグ受信機１０が、放送番組に関する番組データを取得する取得部１４と、取得部１４が取得した番組データに基づく報知を行う報知部１６と、現在位置を取得する位置情報取得部１８と、ユーザが登録したエリア（番組データの取得を行う領域）の情報を保持する登録部２０と、位置情報取得部１８が取得した現在位置が、登録されているエリア内にあると判定したときに、取得部１４による番組データの取得頻度を高く設定する取得頻度設定部２２と、を備えている。したがって、ユーザの現在位置と、登録されたエリア（ユーザのニーズに合ったエリア）との関係に基づいて、番組データの取得頻度（作成・更新頻度）を設定するので、番組データを頻繁に取得（作成・更新）する必要が無いような場合に、当該取得（作成・更新）頻度を減らすことができる。これにより、放送波の頻繁なサーチも不要となるため、省電力化を図ることができる。また、本実施形態では、ユーザは、ローカルワンセグ放送を用いたＣＭを視聴することから、インターネットのサイトなどで、店の情報等を閲覧する場合と比べて、通信料（パケット料金）の負担を低減することができる。また、ローカルワンセグ放送では、動画を視聴することができるので、インターネットの文字情報や静止画像などで店の情報等を収集するよりも、店の雰囲気などを的確に把握することができる。

また、本実施形態によると、取得頻度設定部２２は、現在位置が登録されたエリア内にあるときの取得頻度を、エリア内にないときの取得頻度よりも高くすることとしている。このため、ユーザのニーズに応じて、適切に番組データの取得頻度（作成・更新頻度）を設定することができるので、適切に省電力化を図ることができるようになる。

また、本実施形態によると、ユーザは、嗜好に合ったカテゴリを登録しておき、取得部１４で作成した番組表にユーザの現在位置及び嗜好と合致する番組が存在する場合に番組を自動的に表示する（図７のステップＳ３４〜Ｓ４２）。このように、ユーザが見たい番組のみを自動で表示することで、ユーザの使い勝手を向上させることができる。この点、従来の携帯電話におけるＰｕｓｈ配信サービス（嗜好に応じた情報提供）やカーナビゲーションシステム（現在位置に応じた情報提供）、インターネット検索（自己の意志で検索して情報提供を受ける）と比較しても、十分にユーザの使い勝手が向上していることになる。

また、本実施形態では、番組に関する情報（番組データ）を、放送波から取得するので、ワンセグ放送を受信する受信部以外の通信部（インターネット機能や無線ＬＡＮ機能など）をワンセグ受信機１０に持たせる必要が無い。これにより、ワンセグ受信機１０の簡素化を図ることができ、ひいては、小型・軽量化及びコストダウンを計ることが可能となる。

また、本実施形態では、位置情報取得部１８が、番組に関する情報（番組データ）から、ユーザの現在位置を取得するようにしているので、位置情報を取得するための特別な機器をワンセグ受信機１０に持たせる必要が無い。この点からも、ワンセグ受信機１０の簡素化を図ることができ、ひいては、小型・軽量化及びコストダウンを計ることが可能となる。

なお、上記実施形態では、制御部２８は、位置情報取得部１８が取得した現在位置の情報と、登録部２０が保持するエリアの情報とに基づいて、現在位置がエリア内にあると判断されるときだけ受信部１２と取得部１４への電力供給を行い、エリア外にあるときには電力供給を停止する電力供給部を更に備えていても良い。これにより、更なる省電力化を図ることができる。

なお、上記実施形態では、ユーザの現在位置及び嗜好と合致する番組が開始される前にユーザに当該番組があることを報知し、放送開始前から（又は放送開始と同時に）、受信部１２が放送を自動で受信して、表示制御部１３が番組を自動で表示する場合について説明したが、これに限られるものではない。例えば、放送が既に開始されている場合でも、放送を自動で受信し表示することとしても良い。ただし、このような場合でも、表示制御部１３は、番組終了までの残り時間が所定の閾値（例えば、５秒）以下の場合には、番組を自動的に表示しないようにすることができる。このように、放送の残り時間がわずかな場合には番組を表示しないようにすることで、ユーザの使い勝手を向上させることができる。なお、番組終了までの残り時間が所定の閾値以下の場合には、次に、同じ番組が放送される時間に合わせて、放送を自動で受信し表示するようにすれば良い。同じ番組が放送される時間は、番組名称など番組を識別する情報に基いて番組表テーブルを参照することにより特定することができる。このようにすることで、ユーザの使い勝手を更に向上させることができる。

≪第２の実施形態≫
次に、移動端末の第２の実施形態について、図１２〜図１５に基づいて詳細に説明する。本第２の実施形態では、ワンセグ受信機１０’の位置（ユーザの位置）を取得する方法が、上記第１の実施形態と異なっている。以下、この点を中心に説明する。

図１２には、本第２の実施形態に係るワンセグ受信機１０’を含むワンセグ放送システム１００’の構成が模式的に示されている。図１２に示すように、本第２実施形態のワンセグ放送システム１００’では、第１の実施形態のワンセグ放送システム１００（図１参照）に加えて、ＧＰＳ（Global Positioning System）衛星４０を備えている。

図１３には、図１２のワンセグ受信機１０’の構成がブロック図にて示されている。この図１３に示すように、ワンセグ受信機１０’には、図２の位置情報取得部１８に代えて、ＧＰＳ位置取得部１８’が設けられている。このＧＰＳ位置取得部１８’は、ＧＰＳ衛星４０からの信号（電波）を受信して、当該受信結果から、ワンセグ受信機１０’の位置を取得する。

図１４（ａ）には、本第２の実施形態において、ワンセグコンテンツ配信サーバ５０から送信されてくるパケット分割されているデータが示されている。また、図１４（ｂ）には、番組情報識別子が付加されているパケットのデータ領域の具体的内容が示されている。これらの図に示すように、本第２の実施形態では、前述した第１の実施形態（図９（ｂ））と異なり、ワンセグコンテンツ配信サーバ５０から送信されてくるデータには、放送緯度、及び放送経度が含まれていない。また、本第２の実施形態の番組表テーブル（図１５）には、第１の実施形態（図１０参照）と異なり、放送緯度、及び放送経度の項目は含まれていない。

本第２の実施形態では、基本的には、前述した第１の実施形態と同様の処理を行うことができる。ただし、図７のステップＳ３３（位置情報を取得するステップ）においては、ＧＰＳ位置取得部１８’が、ワンセグ受信機１０’（すなわちユーザ）の位置を取得するようにする。

以上のように、本第２の実施形態では、第１の実施形態と同様の処理を行うことができるので、番組データの取得頻度が適切となり、第１の実施形態と同様、省電力化を図ることができる。また、本第２の実施形態では、ＧＰＳ位置取得部１８’を用いて、ワンセグ受信機１０’の位置を取得するので、高精度な位置取得が可能である。また、本第２の実施形態では、ワンセグコンテンツ配信サーバ５０から送信されてくるデータには、放送緯度、及び放送経度が含まれていないため、ワンセグ受信機１０’で受信するデータ量を少なくすることができる。更に、番組表テーブルには、放送緯度及び放送経度が含まれていないことから、番組表テーブルのデータ量を少なくすることができ、ひいては、ワンセグ受信機１０’に用意すべきメモリ量を少なくすることができる。

なお、上記実施形態では、ＧＰＳ衛星４０から送信される信号を用いてワンセグ受信機１０’の位置を取得する場合について説明したが、これに限られるものではない。例えば、ＲＦＩＤ（Radio Frequency IDentification）システムなどに含まれる送信機を街中に配置しておき、当該送信機からの信号を受信することで、ワンセグ受信機１０’の位置を取得するようにしても良い。

≪第３の実施形態≫
次に、第３の実施形態について、図１６〜図２０に基づいて説明する。図１６には、本第３の実施形態に係るワンセグ受信機１０”を含むワンセグ放送システム１００”の構成が模式的に示されている。この第３の実施形態では、ワンセグ受信機１０”は、携帯電話やスマートフォンなど、携帯電話基地局６０との通信が可能な機器であるものとする。

図１６に示すように、本第３の実施形態のワンセグ放送システム１００”は、第１の実施形態のワンセグ放送システム１００に加えて、携帯電話基地局６０、ユーザ位置情報検知サーバ６２、ニーズ登録サーバ６４、及び、移動端末基地局としてのＰｕｓｈ配信サーバ６６、を有している。これら、携帯電話基地局６０、ユーザ位置情報検知サーバ６２、ニーズ登録サーバ６４、及びＰｕｓｈ配信サーバ６６を含んで、番組情報通知装置としての機能が実現されている。

携帯電話基地局６０は、ワンセグ受信機１０”との間で無線通信を行うとともに、サーバ６２，６４，６６との間で通信を行う。なお、携帯電話基地局６０は、街中に数多く配置されているものである。ユーザ位置情報検知サーバ６２は、街中に数多く配置されている携帯電話基地局６０とワンセグ受信機１０”との間の通信状態から、ワンセグ受信機１０”の位置情報を検知するものである。ユーザ位置情報検知サーバ６２は、必要に応じて、位置情報の検知結果をＰｕｓｈ配信サーバ６６に送信する。ニーズ登録サーバ６４は、ワンセグ受信機１０”上での操作に基づいて、ユーザのニーズを登録して、記憶するサーバである。ニーズ登録サーバ６４は、必要に応じて、登録されているニーズを、Ｐｕｓｈ配信サーバ６６に送信する。Ｐｕｓｈ配信サーバ６６は、番組の情報を含む電子メールをワンセグ受信機１０”に対してＰｕｓｈ配信するサーバである。

ワンセグ受信機１０”は、図１７に示すように、図１のワンセグ受信機１０の取得頻度設定部２２と位置情報取得部１８に代えて、通信部７０を有している。通信部７０は、登録部２０において登録されたユーザのニーズ（エリア、カテゴリ）を、携帯電話基地局６０を介して、ニーズ登録サーバ６４に送信する。ニーズ登録サーバ６４では、図５（ｃ）と同様のニーズテーブルで、ユーザのニーズを管理する。以下、図１８に基づいて、ニーズ設定処理の具体的な手順について、説明する。

図１８には、ニーズ設定処理の手順がフローチャートにて示されている。この図１８に示すように、ニーズ設定処理では、ユーザから初期設定又は設定変更指示があったことを、登録部２０が確認すると（ステップＳ１１０の判断が肯定）、ステップＳ１１２において、登録部２０が、通信部７０を介して通信キャリアの用意するニーズ登録サーバにアクセスする。このアクセスにより、ニーズ登録サーバ６４は、ニーズ登録画面を通信部７０に送信し、登録部２０では、当該ニーズ登録画面を表示画面２４上に表示する。次のステップＳ１１４では、登録部２０が、ニーズが全て設定済みかを判断し、ここでの判断が否定されると、ステップＳ１１６に移行する。そして、ステップＳ１１６では、登録部２０は、ニーズが選択されるまで待機し、選択された段階で、ステップＳ１１８に移行する。ステップＳ１１８では、登録部２０は、カテゴリテーブル（図５（ａ））又はエリアテーブル（図５（ｂ））に基づいて、ニーズテーブルに格納するデータを、通信部７０を介してニーズ登録サーバ６４に対して送信する。その後は、ステップＳ１１４の判断が肯定されるまで、ステップＳ１１４〜Ｓ１１８を繰り返し、ステップＳ１１４の判断が肯定されると、ステップＳ１２０に移行する。ステップＳ１２０では、登録部２０は、表示画面２４上で、放送通知先のメールアドレスの設定又は確認を行う。具体的には、登録部２０は、表示画面２４上に、「メールアドレスを入力してください」や「メールアドレスは、XXX@XX.XXXXでよろしいですか？」などの表示を行う。そして、登録部２０は、当該表示に対するユーザの入力を受け付けることで、ステップＳ１２０の設定又は確認を行う。その後は、ステップＳ１１０に戻る。

次に、図１９，図２０に基づいて、放送受信に関する処理について説明する。まず、Ｐｕｓｈ配信サーバ６６における処理について図１９に基づいて説明する。

図１９のステップＳ２００では、Ｐｕｓｈ配信サーバ６６は、設定時間が経過したか否かを判断する。ここで、設定時間とは、予め設定された初期時間であり、例えば、３分に設定されているものとする。ここでの判断が否定された場合には、ステップＳ３０を繰り返すが、判断が否定された場合には、ステップＳ２０２に移行する。

次いで、ステップＳ２０２では、Ｐｕｓｈ配信サーバ６６は、ユーザ位置情報検知サーバ６２からユーザの位置（ワンセグ受信機１０”の位置）を取得する。次いで、ステップＳ２０４では、Ｐｕｓｈ配信サーバ６６は、ニーズ登録サーバ６４からユーザのエリアに関するニーズを取得する。例えば、ニーズテーブルに「渋谷」、「銀座」が登録されているのであれば、それらのエリアを取得する。

次いで、ステップＳ２０６では、Ｐｕｓｈ配信サーバ６６は、ユーザの現在位置がニーズとして登録されているエリアと合致しているか否かを判断する。ここでの判断が肯定された場合には、ステップＳ２０８に移行して、Ｐｕｓｈ配信サーバ６６は、設定時間をａ分（ａ分は例えば３分とする）に設定した後、ステップＳ２１２に移行する。一方、ステップＳ２０６の判断が否定された場合には、Ｐｕｓｈ配信サーバ６６は、ステップＳ２１０において、設定時間をｂ分（ａ分よりも長い時間、例えば３０分とする）に設定して、ステップＳ２００に戻る。

ステップＳ２０８を経て、ステップＳ２１２に移行すると、Ｐｕｓｈ配信サーバ６６は、ステップＳ２１２において、ユーザの位置（又は登録されているエリア）に応じた番組表（番組データ）を取得する。この場合、Ｐｕｓｈ配信サーバ６６は、例えば、インターネットなどの通信網を介して、番組表を取得するものとする。

次いで、ステップＳ２１４では、Ｐｕｓｈ配信サーバ６６は、ニーズ登録サーバ６４からユーザが登録した、カテゴリに関するニーズを取得する。この場合、例えば、ニーズテーブルに和食が登録されていれば、カテゴリコード「Ｇ１１００」（図５（ａ）参照）を取得する。

次いで、ステップＳ２１６では、Ｐｕｓｈ配信サーバ６６は、番組表中に取得したカテゴリと合致する番組があるか否かを判断する。なお、ここでの判断は、前述したステップＳ４０と同様の判断を行うものとする。ここでの判断が否定された場合には、ステップＳ２００に戻るが、肯定された場合には、ステップＳ２１８に移行する。

ステップＳ２１８では、Ｐｕｓｈ配信サーバ６６は、番組に関する放送通知をメールにて送信する。なお、番組に関する放送通知とは、番組の内容と開始時間などを含む通知である。この場合、Ｐｕｓｈ配信サーバ６６は、図１８のステップＳ１２０で設定又は確認されたメールアドレスに対してメール送信を行う。そして、ステップＳ２２０では、Ｐｕｓｈ配信サーバ６６は、所定時間（例えば、１時間）経過するまで待機し、所定時間経過した段階で、ステップＳ２００に戻る。なお、ステップＳ２２０で、所定時間経過するまで待機するのは、番組表が更新されていないにもかかわらず、何度も同一の放送通知のメールがユーザに届いてしまうのを回避するためである。

ステップＳ２００に戻ると、ステップＳ２０８、Ｓ２１０のいずれかにおいて設定された時間が経過するまで待機し、以下、同様の処理を実行する。すなわち、図１９では、ユーザが登録したエリア内に存在しているときには、ユーザの位置の取得処理が比較的頻繁に行われ、ユーザが登録したエリア外に存在しているときには、ユーザの位置の取得処理は比較的間欠的に行われるようになっている。

次に、ワンセグ受信機１０”側における処理について、図２０に基づいて説明する。

図２０のステップＳ２３０では、表示制御部１３が、通信部に、キャリアから放送通知のメールが送信されてきたか否かを判断する。ここでの判断が肯定されると、ステップＳ２３２に移行し、ユーザから放送受信要求があるまで待機する。なお、ユーザは、入力部２６から、放送受信要求を入力することができる。

ステップＳ２３２の判断が肯定されると、ステップＳ２３４に移行し、放送受信処理のサブルーチンを実行する。なお、このステップＳ２３４の処理は、前述した第１の実施形態における処理（図１１）と同様であるので、説明を省略するものとする。

以上のように、本第３の実施形態では、ユーザは、現在位置している場所で放送しているローカルワンセグ放送のうち、自己のニーズに合った番組の情報をメールで受け取ることができる（ステップＳ２１８、Ｓ２３０）。また、ユーザは、当該メールに基づいて放送受信要求を入力すれば（ステップＳ２３２）、番組放送開始から、番組を視聴することができる（ステップＳ２３４）ようになっている。

なお、上記においては、ワンセグ受信機１０”に対して放送通知がメールにて送信される場合について説明したが、これに限られるものではない。例えば、通信キャリアの用意する災害時緊急通知機能を用いて、放送通知を行うこととしても良い。

以上、詳細に説明したように、本第３の実施形態によると、ローカルワンセグ放送を受信するワンセグ受信機１０”の現在位置を取得する携帯電話基地局６０及びユーザ位置情報検知サーバ６２と、ワンセグ受信機１０”から登録されるエリアを取得するニーズ登録サーバ６４と、ワンセグ受信機１０”の現在位置に応じた番組表（番組データ）を取得し、当該番組表の少なくとも一部の情報をワンセグ受信機１０”に通知するＰｕｓｈ配信サーバ６６とを備えており、ユーザ位置情報検知サーバ６２によるワンセグ受信機１０”の現在位置取得頻度は、ワンセグ受信機１０”の現在位置と、ワンセグ受信機１０”において登録されたエリアとの関係に基づいて設定される。これにより、本第３の実施形態では、ユーザ位置情報検知サーバ６２におけるワンセグ受信機１０”の位置検出の頻度を低減することができるので、ユーザ位置情報検知サーバ６２の省電力化を図ることができる。また、ワンセグ受信機１０”においても通信回数が減るので、ワンセグ受信機１０”の電力消費を低減することもできる。

なお、上記第３の実施形態では、ユーザ位置情報検知サーバ６２、ニーズ登録サーバ６４、Ｐｕｓｈ配信サーバ６６のそれぞれが別の装置である場合について、説明したが、これに限られるものではない。例えば、上記３つのサーバの少なくとも２つの機能を同一の装置で実現することとしても良い。

なお、上記第３の実施形態では、ユーザ位置情報検知サーバ６２が、ワンセグ受信機１０”の位置を携帯電話基地局６０における通信状態に基づいて、取得する場合について説明したが、これに限られるものではない。例えば、第２実施形態のようにＧＰＳを用いてワンセグ受信機１０”で検出される位置を、ユーザ位置情報検知サーバ６２が取得するようにしても良い。

なお、上記各実施形態では、ローカルワンセグ放送を街中で視聴するような場合について説明したが、これに限られるものではない。例えば、デパートの各階ごとに異なる放送があるような場合には、その番組情報をワンセグ受信機で取得して、これに応じた放送の受信（視聴）を行うようにすれば良い。また、博物館などで、展示物近傍でのみ視聴可能な番組を放送するようにすることもできる。

なお、上記各実施形態における処理機能は、前述したように、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

上述した各実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。

１０ ワンセグ受信機（移動端末）
１３ 表示制御部（表示手段の一部）
１４ 取得部（取得手段）
１６ 報知部（報知手段）
１８ 位置情報取得部（位置情報取得手段）
２０ 登録部（保持部）
２２ 取得頻度設定部（判定手段、設定手段、電力制御部）
２４ 表示画面（表示手段の一部）
５０ ワンセグコンテンツ配信サーバ（放送局）
６６ Ｐｕｓｈ配信サーバ（移動端末基地局）

Claims (7)

1. 放送番組に関する番組データを取得する取得手段と、
   前記取得手段により取得した番組データに基づく報知を行う報知手段と、
   現在位置の情報を取得する位置情報取得手段と、
   前記取得手段により番組データの取得を行う領域の情報を保持する保持部と、
   前記位置情報取得手段が取得した現在位置の情報と、前記保持部に保持された領域の情報とに基づいて、前記現在位置が前記領域の情報で示される領域内にあるか否かを判定する判定手段と、
   前記判定手段により前記現在位置が前記領域内にあると判定された場合に、前記取得手段による前記番組データの取得頻度を、前記現在位置が前記領域内にないと判定されたときの取得頻度よりも高く設定する設定手段と、
   を有することを特徴とする移動端末。
2. 前記判定手段により、前記現在位置が前記領域内にないと判定された場合に、前記取得手段への電力供給を停止する電力制御部をさらに有することを特徴とする請求項１に記載の移動端末。
3. 前記番組データには、放送番組のカテゴリ情報と放送時刻情報が含まれ、
   前記保持部には、放送番組のカテゴリ情報が保持され、
   前記取得手段で取得した番組データに含まれるカテゴリ情報と前記保持部に保持されたカテゴリ情報とが合致すると判断された場合に、前記放送時刻情報で示される時刻に前記放送番組を表示する表示手段を更に有することを特徴とする請求項１又は２のいずれか一項に記載の移動端末。
4. 前記表示手段は、前記取得手段で取得した番組データに含まれるカテゴリ情報と前記保持部に保持されたカテゴリ情報とが合致すると判断された場合であっても、前記放送時刻情報で示される放送番組終了までの残り時間が閾値以下であると判断された場合には、前記放送番組を表示しないことを特徴とする請求項３に記載の移動端末。
5. 前記番組データには、放送番組の識別情報が含まれ、
   前記表示手段は、前記残り時間が閾値以下の場合には、前記番組データに基いて、同一の識別情報で示される放送番組が次に放送される時刻を特定し、特定された時刻に前記放送番組を表示することを特徴とする請求項４に記載の移動端末。
6. 前記取得手段は、前記番組データを、放送局又は移動端末基地局から送信される情報から取得することを特徴とする請求項１〜５のいずれか一項に記載の移動端末。
7. 前記番組データには、放送番組を放送する放送局の位置情報が含まれ、
   前記位置情報取得手段は、前記現在位置を、前記番組データから取得することを特徴とする請求項１〜６のいずれか一項に記載の移動端末。

Images