連動型放送画面送受信システム
【課題】ワンセグ放送の受信可能な小型端末で、鮮明な画像で画面拡大を可能とする連動型放送画面送受信システムを提供する。
【解決手段】放送受信端末１０１と、放送処理サーバ２０１とが接続されており、放送処理サーバ２０１の拡大指定領域が、放送受信端末１０１の拡大指定領域に貼付される画像である。拡大指定領域は、トリミング位置までトリミングし、領域画像とする。これを放送受信端末１０１の表示部１０４の端末画面サイズに合わせるようにキャプチャー画像として送信し貼付される。放送処理サーバ２０１によってキャプチャーされた映像は、地上波放送であり、１セグ放送よりもビットレートが高い映像に基づいて生成されているため、ユーザーの指定するサイズにスケーリングされたとしても高画質な画像であり、ユーザーは、指定した領域を１セグ放送に比べてより鮮明に視認し確認することが可能となる。
【解決手段】放送受信端末１０１と、放送処理サーバ２０１とが接続されており、放送処理サーバ２０１の拡大指定領域が、放送受信端末１０１の拡大指定領域に貼付される画像である。拡大指定領域は、トリミング位置までトリミングし、領域画像とする。これを放送受信端末１０１の表示部１０４の端末画面サイズに合わせるようにキャプチャー画像として送信し貼付される。放送処理サーバ２０１によってキャプチャーされた映像は、地上波放送であり、１セグ放送よりもビットレートが高い映像に基づいて生成されているため、ユーザーの指定するサイズにスケーリングされたとしても高画質な画像であり、ユーザーは、指定した領域を１セグ放送に比べてより鮮明に視認し確認することが可能となる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、連動型放送画面送受信システムに関し、特に、放送番組を受信・記録・再生できる放送サーバ装置と、放送番組を受信するとともに、放送サーバ装置が生成した画像を表示することができる端末装置とに関する。
【背景技術】
【０００２】
近年、携帯電話機などの携帯端末の普及率が非常に高くなり、だれでもが所持していると言っても過言ではない。さらに、携帯端末に適したデジタル放送であるワンセグデジタル放送を含むモバイル向けデジタル放送が急速に広がりを見せている。このような状況のもとで、ユーザーは、屋外で手軽に番組を視聴できるようになってきた。また、ワンセグデジタル放送では、家庭で視聴できる地上デジタル放送と同じ内容の番組を放送している(サイマル放送）ため、家庭とモバイルユースとで同じ番組を視聴できるというメリットがある。
【０００３】
しかしながら、ワンセグデジタル放送の解像度は、携帯電話のサイズに合わせて規定されており、ワイド放送（16:9比率）の場合、横３２０ドット×縦１８０ドットの解像度しかなく、エラー耐性向上のために、狭い帯域で放送されているため、文字など細かい部分は圧縮ノイズでつぶれてしまうという問題もある。
【０００４】
携帯電話よりも大きい表示画面、例えば８インチ前後の表示画面を持つワンセグ受信機も製造されているが、元の映像（ソース）が鮮明でないため、画面が大きくなっても表示が荒くなるだけであり細部の視認性は向上しない。
【０００５】
このような状況で、スコア表示部分を拡大して表示するという装置が下記特許文献１に、受信状況に応じてワンセグ放送と通信路を用いた映像配信とを切り替えることにより、できるだけ鮮明な映像を見られるようにする装置が特許文献２に開示されている。
【０００６】
【特許文献１】特開２００６−２１１２０７号公報
【特許文献２】特開２００５−３１１４３５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、従来のモバイル端末においては、拡大時に高精細データを取得する仕組みを持ち合わせていないため、モバイル端末側で画像のキャプチャー及び拡大を行った場合に鮮明な画像を得ることが出来ないという問題があった。
【０００８】
本発明は、ワンセグも受信可能な小型端末であっても、鮮明な画像での画面拡大を可能とする連動型放送画面送受信システムを提供することを目的としている。
【課題を解決するための手段】
【０００９】
本発明は、サイマル放送の特性を活かし、サーバ側で受信した高画質な映像を、端末に通信手段を用いて送信することにより、端末側で視聴可能とするものである。
【００１０】
すなわち、本発明に係る連動型放送画面送受信（拡大・縮小）システムは、高解像度の放送を受信できる放送処理サーバと低解像度の放送を受信している放送受信端末を連動させることにより、放送受信端末で高品位なズーム画面を得ることができることを特徴とする。放送受信装置は、ユーザー操作により指定された画面を特定する情報を放送サーバに送り、放送サーバ側で予め記録してある高解像度の画像を取得する。これにより、放送受信端末を用いて、より高画質なイメージを放送受信端末から取得し、高品位が画面拡大を行える連動型放送画面送受信システムが提供される。
【００１１】
すなわち、本発明の一観点によれば、放送受信端末と、該放送受信端末と接続可能な放送処理サーバと、を備えた連動型放送画面送受信システムであって、前記放送受信端末は、第１の解像度の放送を受けることができる第１の放送受信手段と、画像をキャプチャーするタイミングを指定する入力手段と、前記放送処理サーバに対してキャプチャー画面の送信リクエストを行う第１の通信手段と、取得したキャプチャー画面を表示する表示手段と、を有し、前記放送処理サーバは、前記第１の解像度よりも高い解像度の放送を受けることができる第２の放送受信手段と、受信した映像を少なくとも一時的に記憶する記憶手段と、前記放送受信端末から前記送信リクエストに対応する前記第２の解像度の画像データを前記放送受信端末に送信する第２の通信手段と、を有することを特徴とする連動型放送画面送受信システムが提供される。これにより、前記放送受信端末において指定された画像を高解像度で得ることの出来る放送受信端末の画像を拡大したい場合に、放送処理サーバにおいて高画質の画像を得ておき、これを拡大して放送受信端末におくることで、高画質の拡大画像を得ることができる。
【００１２】
前記放送処理サーバが、現在放送されている放送画像のうちから前記放送受信端末から指定された番組指定情報に基づいて特定された放送画像のみを前記記録手段に記録することが好ましく、また、前記放送受信端末において選局操作を行うと、該選局操作を行った放送局のサービス情報が前記放送処理サーバに送られるように放送局に要求することが好ましい。これにより、放送処理サーバが放送受信端末で受信しているサービスのみを記録することが可能になる。
【００１３】
本発明の他の観点によれば、第１の解像度で画像を表示可能な放送受信端末と、該放送受信端末と接続可能な前記第１の解像度よりも高解像度の第２の解像度で画像を表示可能な放送処理サーバと、を備えた連動型放送画面送受信システムにおける放送処理サーバであって、前記放送受信端末から前記放送処理サーバに対して、端末の表示特性と、番組指定情報と時間同期情報と、拡大エリア情報と、拡大率とを含む要求画像情報と、に基づいてキャプチャー画像の要求に応じて、該要求画像情報に基づいて前記第２の解像度の画像をソースとして前記放送処理サーバにおいてキャプチャー画像を生成し、該キャプチャー画像を前記放送受信端末に送信することを特徴とする放送処理サーバが提供される。これにより、拡大画像であっても、放送受信端末において高画質で表示させることができる。
【発明の効果】
【００１４】
以上に説明したように、本発明によれば、例えばモバイル向けの低解像度放送受信端末においても、高画質な画面キャプチャー及び拡大表示が可能となる。
【発明を実施するための最良の形態】
【００１５】
本明細書において、画像という用語は、静止画像と動画像とを含むものとする。以下、本発明の一実施の形態による放送画面拡大技術について図面を参照しながら説明を行う。
【００１６】
まず、放送受信端末(１０１)と放送処理サーバ（２０１）との連動による放送画面拡大技術について説明する。
【００１７】
図１左図は、放送受信端末の一構成例を示す機能ブロック図である。図１左図に示すように、放送受信端末（１０１）は、全体を制御する制御手段（１０２）と、入力手段（１０３）と、表示手段（１０４）と、記憶手段（１０６：インターフェイスを含む）と、一般的な通信手段１０７と、ワンセグなどの放送を受信する放送受信手段（１０５）を備えている。
【００１８】
図１右図は、放送処理サーバの一構成例を示す機能ブロック図である。図１右図に示す放送処理サーバ（２０１）は、全体を制御する制御手段（２０２）と、記憶手段（２０３）と、放送受信手段（２０４）と、通信手段（２０５）とを備えている。
【００１９】
放送受信端末（１０１）においては、放送受信手段（１０５）によって受信された放送データは、制御手段（１０２）に送られる。制御手段（１０２）に送られた放送データに関してデコードなどの信号処理が行われ、ユーザーが視聴可能な形式に変換される。変換された映像データは表示手段（１０４）に送られ、映像が表示される。音声データは図示しない音声出力手段に送られ、音声が出力される。
【００２０】
ユーザーが、放送受信端末（１０１）を利用してワンセグ放送の野球を視聴していたとする。ワンセグ放送は、テレビ放送の電波を受信するため、移動しながらの視聴、もしくは、ビルの谷間などでの視聴であれば、電波状況が悪くなりブロックノイズが発生することがある。また、１セグ放送のコンテンツのビットレートは高くなく、サイズもＱＶＧＡのため映像内のテロップや野球のスコアなどは認識が難しい場合がある。
【００２１】
ユーザーが、映像上に表示されているスコアをより鮮明に確認したいと思った時に、入力手段（１０３）から、そのスコア部分の領域を指定することができるように構成されている。領域の指定方法は、特に限定されるものではないが、例えば入力手段として表示手段（１０４）に対してタッチパネル機能を備えておき、タッチペンなどでその領域を直接なぞるなどして指定することができる。尚、タッチパネルが備えらえていない場合でも、入力手段（１０３）に備えられているボタンなどを押下することを契機として領域指定モードとなるように構成しておくことで、入力手段（１０３）に備わっている上下左右移動キー及び決定ボタンにより、領域を指定することが可能である。また、画面全体を領域として指定するようにしても良い。
【００２２】
ここで、領域情報について、図２、図３を参照しながら説明を行う。図２は、映像領域とズームしたい領域との位置を示す図である。図３は、サーバ側における拡大時の処理の流れを示すフローチャート図である。図５は、事前登録によるキャプチャー映像の授受に関する事前登録の場合のシーケンス図である。
【００２３】
事前に、放送受信端末１０１から放送処理サーバ２０１に対して、端末情報を送る（１４１）。端末情報は、端末ＩＤ、端末画面サイズ、対応フォーマット、表示色数、取得可能最大サイズなどであり、予めこれらの取得した端末情報が、放送処理サーバ２０１に保存される（１４３）。
【００２４】
尚、映像領域とは、ユーザーが放送受信端末（１０１）で視聴している放送映像の全体の領域を示す。仮に、図２の映像領域１中においてユーザーが網模様で示される領域を指定したとする。この際、映像領域１全体の横の長さに対する、映像領域１の左端から、ユーザーが指定した領域の左端までの距離の割合をＸ１％とし、右端までの距離の割合をＸ２％とし、映像領域１全体の縦の長さに対する、映像領域１の上端からユーザーが指定する領域の上端までの距離の割合をＹ１％とし、下端までの距離の割合をＹ２％とする。また、ユーザーが指定した領域のうち、放送受信端末（１０１）の表示画面上の縦横のピクセル数をそれぞれＹ０ピクセル、Ｘ０ピクセルとする。
【００２５】
以上の（Ｘ０、Ｘ１、Ｘ２、Ｙ０、Ｙ１、Ｙ２）の６つの情報群を領域（エリア）情報と称する。例えば、ＱＶＧＡ（縦２４０ピクセル、横３２０ピクセル）のワンセグ放送を、縦４００ピクセル、横２４０ピクセルのＷＱＶＧＡの液晶ディスプレイに表示して視聴しているとする。この時、ＱＶＧＡのワンセグ放送のコンテンツは、横２４０ピクセルの液晶ディスプレイに表示されるため、映像の縦横の比率を変更しないで縮小する場合には、映像の縦横を２５％縮小して、縦１８０ピクセル、横２４０ピクセルの映像をしていることになる。
【００２６】
ここで、ユーザーが、Ｘ１＝２５％、Ｘ２＝７５％、Ｙ１＝２５％、Ｙ２＝７５％となるような領域を指定したとする。現在、ユーザーは縦１８０ピクセル、横２４０ピクセルの映像を見ているため、Ｘ１とＸ２とで挟まれた領域は５０％となり、Ｘ０＝１２０ピクセルとなる。同様にＹ１とＹ２とで挟まれた領域も５０％となるため、Ｙ０＝９０ピクセルとなる。従って、領域情報は（１２０、２５、７５、９０、２５、７５）となる。
【００２７】
ユーザーが領域を指定すると、自動的に、もしくは、入力手段（１０３）に備わっている情報送信のためのボタンを押下することにより、指定された領域情報（エリア情報）を、通信手段（１０７）を介して放送処理サーバ（２０１）に送信することができる。尚、通信手段（１０７）とは、携帯電話などの場合のパケット通信機能や、無線ＬＡＮに対応している端末の場合には無線ＬＡＮユニット、赤外線での通信が可能な場合には赤外線ユニット、有線のＬＡＮやＢｌｕｔｏｏｔｈなどが該当するが、通信手段を具体的に限定するものではない。
【００２８】
放送受信端末（１０１）は、領域情報を放送処理サーバ（２０１）に送信する際に、ユーザーがどのチャンネルを視聴していたかを示すチャンネル情報（番組指定情報）、ユーザーが視聴している１セグ放送映像の縦横のサイズ（ピクセル数）も付加する。送信する情報には、端末ＩＤ、時間同期情報、拡大率などを含んでも良い。以下、放送処理サーバ（２０１）に送信する情報を、まとめてリクエスト情報と記載する。
【００２９】
放送処理サーバ（２０１）は、通信手段（２０５）を用いてリクエスト情報を受信することができる（ステップＳ１：図５の１４１及び１４５）。リクエスト情報を受信した放送処理サーバ（２０１）は、そのリクエスト情報を制御手段（２０２）において解析し、リクエスト情報に含まれているチャンネル情報を取得する。チャンネル情報を取得した放送処理サーバ（２０１）は、放送受信手段（２０４）よりチャンネル情報に基づくチャンネルに対応する内容の地上波放送の受信を開始し、その受信映像をキャプチャーし、例えば記憶手段（２０３）に記録する（ステップＳ２：図５の１４７）。この際、時間同期情報を利用しても良い。
【００３０】
尚、時間同期情報とは、放送処理サーバ（２０１）から放送受信端末（１０１）に送信される放送と、放送受信端末（１０１）が自ら受信する放送と、の間における時間的な同期を行うために必要な情報であり、例えば番組の開始タイミングと番組の終了タイミングとをそれぞれの放送で一致させるための情報を指す。
【００３１】
次に、リクエスト情報に含まれている領域情報のＸ１、Ｘ２、Ｙ１、Ｙ２の値を用いて、キャプチャーした映像から指定された領域のみを切り出す（トリミング：ステップＳ３）。この際に切り出されたキャプチャー映像のサイズは、地上波放送の元の映像の解像度に依存するが、元の映像の解像度がどのようなサイズであっても、後述するように、領域情報のＸ０、Ｙ０の値にスケーリングすることにより（トリミング：ステップＳ５）、ユーザーが放送受信端末で指定した領域と同解像度のキャプチャー映像を生成することができる。尚、放送処理サーバ（２０１）が受信する地上波放送の解像度は、放送受信端末（１０１）が受信する放送の解像度より大きいことが好ましいが、キャプチャー映像をスケーリングする時に拡大も縮小も可能であれば、最終的に求められるキャプチャー映像を生成することは可能である。尚、このシステムでは、放送受信端末（１０１）で受信可能な放送番組と同様の番組を、放送処理サーバ（２０１）でも受信できることが必要である。
【００３２】
放送処理サーバ（２０１）は、切り出したキャプチャー映像を、通信手段（２０５）を用いて放送受信端末（１０１）に送信する（ステップＳ６：図５の１５１）。放送受信端末（１０１）は放送処理サーバ（２０１）から送信されてきた切り出されたキャプチャー映像を、通信手段（１０７）を用いて受信し、受信した映像を、表示手段（１０４）により表示させる。その場合の表示方法は、ユーザーが指定した領域に当てはめるように表示するようにしても良いし、表示手段のディスプレイが複数具備されている場合は、１セグ放送を表示しているディスプレイ以外のディスプレイに表示させても良い。受信画像は表示又は保存される（１５３）。
【００３３】
図４は、トリミング処理の概要を示す図である。放送受信端末１０１と、放送処理サーバ２０１とが電話回線やインターネットのネットワークを通じて情報の送受信が可能な状態であり、放送処理サーバ２０１の拡大指定領域１２１ａが、放送受信端末１０１の拡大指定領域（Ｙ０ｐｉｘ、Ｘ０ｐｉｘ）に貼付されるイメージである。拡大指定領域１２１ａは、縦ａ×Ｙ０ｐｉｘ、横ａ×Ｘ０ｐｉｘの画像を、トリミング位置１２５でトリミングし、縦Ｙ０ｐｉｘ、横Ｘ０ｐｉｘの領域１２７とする。これを放送受信端末１０１の表示部１０４の拡大指定領域１２１に合わせるようにキャプチャー画像として送信し貼付される。
【００３４】
放送処理サーバ（２０１）によってキャプチャーされた映像は、地上波放送であり、１セグ放送よりもビットレートが高い映像に基づいて生成されているため、ユーザーの指定するサイズにスケーリングされたとしても高画質な画像であり、ユーザーは、指定した領域を１セグ放送に比べてより鮮明に視認し確認することが可能となる。
【００３５】
尚、上記の例では、１セグ放送と地上波放送とを対象として例示的に説明したが、放送受信端末と放送処理サーバとで、同じ番組を受信できるシステムであればＢＳ放送やＣＳ放送、ＩＰ放送などの別の放送形態の画像の組み合わせでも良い。
【００３６】
図６は、図５と対応する図であり、事前登録ではなくその都度通知する手法に関するシーケンス図である。まず、放送受信端末１０１が放送処理サーバ２０１に対して、キャプチャー画像をリクエストする（１６１）。放送処理サーバ２０１は、キャプチャーイメージを生成する（１６３）。このキャプチャー画像を放送受信端末１０１に送信し（１６５）、端末１０１において受信画像を表示又は保存する（１６７）。
【００３７】
次に、第１変形例について説明する。上記の説明において、放送受信端末（１０１）を所持するユーザーがキャプチャー領域を指定し、リクエスト情報が放送処理サーバ（２０１）に到達してから地上波放送の受信を開始してキャプチャーを行う手法について説明したが、このような手法によれば、システムの起動や指定された番組のチューニングなどに時間を要してしまい、実際にキャプチャーされた映像が、ユーザーの意図していた映像よりも後の時間にキャプチャーされた映像となってしまう可能性もある（図７参照）。
【００３８】
この問題を回避する方法として、第１変形例では、図８に示すように、放送処理サーバ（２０１）が地上波放送の全チャンネルを録画し続けており、放送受信端末によってリクエスト情報が生成される際に、その時刻を情報としてリクエスト情報に含め、そのリクエスト情報を受信した放送処理サーバ（２０１）は、録画済のコンテンツ中からリクエスト情報に含まれている指定されたチャンネルであり、かつ、指定された時刻に対応する部分のコンピュータを読み出し、その映像に基づいてキャプチャー映像を生成する。
【００３９】
また、上記の第１変形例による説明において、放送処理サーバ（２０１）が複数の放送受信端末（１０１）からのリクエストを受け付けるサーバである場合には、全チャンネルを全て記録しておくと、複数のリクエストにも答えることが可能である。しかしながら、単一の放送受信端末（１０１）に対する専用の放送処理サーバ（２０１）であり、他の放送受信端末（１０１）のリクエストを受信する必要がない構成の場合には、ユーザーが視聴しているチャンネル以外のチャンネルを、放送処理サーバで記録していても無駄となる。
【００４０】
第２変形例では、図９に示すように、この問題を回避するために、ユーザーが視聴するチャンネルもしくは視聴する可能性のあるチャンネルを予め放送処理サーバ（２０１）に設定しておき、その設定されたチャンネルのみ記録しておく構成を有している。
【００４１】
上記放送処理サーバ（２０１）において、ユーザーが放送受信端末（１０１）で視聴を行っていない時間に記録されたコンテンツは、ユーザーからのリクエストが来ることがないため無駄となるものである。この問題を回避するために、図１０に示す第３変形例では、ユーザーが放送受信端末（１０１）で視聴を開始した時点で、自動的にそのチャンネル情報を放送処理サーバ（２０１）に送信し、放送処理サーバ（２０１）は、そのチャンネル情報を受信したときに、チャンネルの記録を開始する方法である。このようにすることで、放送処理サーバ（２０１）は、ユーザーが視聴しているコンテンツのみが記録され、余計なコンテンツの記録を抑制することができる。尚、ユーザーが視聴チャンネルを変更した際も同様にチャンネル情報を放送処理サーバに送信し、その情報を受信した放送処理サーバ（２０１）は、それまでに記録していたコンテンツを自動的に削除するように構成しても良い。また、視聴を終了した時にも、視聴の終了を表す情報を送信することにより、放送処理サーバ（２０１）でのコンテンツ記録を停止し、記録していたコンテンツを自動的に消去するようにすることで、記憶手段（２０３）の容量を効率良く使用することができるという利点がある。
【００４２】
上記チャンネル情報は、ユーザーが視聴チャンネルを変更するたびに送信されるようにすると、ユーザーは単に興味のある番組が放送されていないかなどを確認するためだけにチャンネルを次々送っている場合に、その都度、チャンネル情報が送信されてしまう。すると、放送受信端末（１０１）のチャンネル情報送信処理や、放送処理サーバ（２０１）の記録処理が無駄となってしまうという問題がある。
【００４３】
そこで、図１１に示す第４変形例では、ユーザーが放送を選局してから別のチャンネルに選局されること無くある一定時間経過した場合に、チャンネル情報を送信する。このようにすると、ユーザーがチャンネルを次々と切り替えている間は、放送処理サーバ（２０１）ではコンテンツの記録を行わないため、ユーザーの番組視聴がある一定時間経過し落ち着いた段階でサーバでの記録を開始することが可能となり、余計な処理を行わなくて済む。
【００４４】
上記放送処理サーバ（２０１）のコンテンツ記録機能は、コンテンツの記録を開始したら記録し続けるか、もしくは、記録を終了するのは視聴が終了するまで、というように想定されていた。しかしながら、ユーザーがキャプチャー映像のリクエストのための処理を開始してから何時間も後に、放送処理サーバ（２０１）リクエストが到着するということは考えにくい。ユーザーがリクエスト開始した時と、キャプチャー映像が放送受信端末に到着した時との間に大きな時間のずれがあると、キャプチャー映像自体がユーザーにとって古いものとなってしまい、キャプチャー映像を受信する意味が薄れてしまうことも考えられる。そこで、放送処理サーバ（２０１）は、コンテンツの記録時間を、例えば５分又は１０分などの特定の時間を最大の記録時間とし、その時間前の部分を順次消去していくように構成されていても良い。その最大記録時間の長さについては、放送受信端末がチャンネル情報を送信して放送の記録を開始させる場合には、そのチャンネル情報と共に、最大記録時間を放送処理サーバに送信することで、その時間分だけ常に記録するように動作するようにしても良いし、予め特定の時間が決められているように構成されていても良い。このようにするために、リングバッファなどを利用することが可能であり、放送処理サーバ（２０１）は記憶手段の容量不足を抑制することができる。
【００４５】
尚、放送受信端末（１０１）がキャプチャー映像をリクエストする際に、送信する時刻情報は、放送受信端末（１０１）に内蔵されている時計（図示せず）から取得すれば良い。或いは、放送受信端末（１０１）が、放送受信時に取得可能な放送ＴＳ内のＴＯＴ情報から取得しても良い。もしくは、放送受信端末（１０１）が、放送受信時に取得可能な放送ＴＳ内のＰＣＲ情報から取得しても良い。
【００４６】
尚、ＴＳ内のＴＯＴもしくはＰＣＲ情報から時刻情報を取得する際に、放送の受信状態が悪化し、リクエストをしたい時刻情報が取得できなかった時には、ＴＳから時刻情報を最後に受信できた時間から、リクエストを行う時間までを内蔵時計で計測し、その計測結果として得られる時刻情報を用いる構成でも良い。
【００４７】
また、図１２に示す第５変形例では、ユーザーが、キャプチャー映像をリクエストする際に、リクエストしたいと思った瞬間から、リクエスト操作を開始するまでに多少の時差が発生し、ユーザーが望んでいるキャプチャー映像を逃してしまう可能性が高い。そこで、リクエスト操作を開始した時間より、例えば数秒前の時間の時刻情報が送信されるようにすることで、ユーザーがリクエストしたい瞬間のキャプチャー映像に遡って近づけることが可能となる。但し、ここでいう数秒前とは、ユーザーの設定によるものでも良いし、デフォルトの値でも良いし、どの程度の時間にするかは、ユーザーや映像に応じて適宜変化させるようにしても良い。
【００４８】
ユーザーが、放送受信端末（１０１）を使用して、例えば野球番組を視聴しており、画面右下のスコア情報をキャプチャー画面としてリクエストした場合に、野球の進展によってそのスコア情報は変化することがある。このような場合に、変化が発生するたびに同様のエリアを毎回指定し、キャプチャー映像をリクエストするのはユーザーにとって手間となり煩わしいという問題がある。この問題を解消するために、一度、ユーザーがキャプチャー映像のリクエストを行うと、その後は一定の間隔で同様のエリアのキャプチャー情報を自動的にリクエストするような構成としても良い。この際、一定の間隔とは、ある特定の間隔に限定されるものではなく、ユーザーが最初のリクエスト時に指定するようにしても良いし、視聴しているコンテンツのタイトルや種類や種目、もしくはコンテンツのジャンルによって決められるように構成されていても良い。
【００４９】
次に、ユーザーが指定する「拡大率情報」について、図２を参照しながら説明する。現在、図に示されるように、領域情報として、（Ｘ０、Ｘ１、Ｘ２、Ｙ０、Ｙ１、Ｙ２）が指定されているとする。この時、拡大率を次のように定義する。サーバで録画しているコンテンツにおいて、上記Ｘ１、Ｘ２、Ｙ１、Ｙ２によって指定された領域をＸ０ピクセル、Ｙ０ピクセルに縮小した映像の拡大率を１倍とする。
【００５０】
例えば、拡大率を「ａ倍」と指定した場合に、サーバで録画しているコンテンツにおいて、上記Ｘ１、Ｘ２、Ｙ１、Ｙ２によって指定された領域を、ａ×Ｘ０ピクセル、ａ×Ｙ０ピクセルのサイズに縮小した映像となる。このように、上記「領域情報」Ｘ０、Ｘ１、Ｘ２、Ｙ０、Ｙ１、Ｙ２と、「拡大率情報」ａを含む「リクエスト情報」と、を、放送処理サーバ（２０１）に送信することにより、リクエストする映像の拡大率を指定することができる。
【００５１】
この場合において、取得したいサイズをａ×Ｘ０ピクセル、ａ×Ｙ０ピクセルとするために、拡大率「ａ」として指定したが、拡大率を指定する代わりに、取得したいサイズを直接指定しても良い。この時、ユーザーはリクエスト情報生成時に、取得したい映像のサイズを、入力手段（１０３）を用いて指定し、その指定されたサイズ情報をリクエスト情報に含めて放送処理サーバ（２０１）に送信する。
【００５２】
また、この場合において、拡大率もしくは取得したいサイズを指定することにより、ユーザーが最初に選択する領域情報のサイズよりも大きいキャプチャー映像を受信することになるが、取得された映像を、最初に指定した領域に当てはめて表示する場合に、放送受信端末（１０１）側で、取得された映像のスケーリング処理を行う必要が出てくる。取得された映像は当初の領域より大きいサイズであっても、受信映像から当初の領域のサイズだけを切り出して表示することも考えられる。この時、放送受信端末（１０１）側で映像のトリミングを行うことも可能であるが、リクエスト情報を生成する際に、トリミング位置を予め指定し、トリミングされた映像を放送処理サーバ（２０１）から先に送信してもらい、後に、リクエストした映像を受信するようにすることで、放送受信端末（１０１）側でスケーリング処理を行う必要がなく、受信した映像をすぐに表示させることができる。
【００５３】
トリミング位置をユーザーが指定する方法としては、最初に領域を指定した際に、その領域内のある１点を指定することにより、受信される予定の映像の同じ点から縦横にＸ０ピクセル、Ｙ０ピクセルとなるサイズがトリミングされた映像とするように指定する方法などが挙げられる。放送処理サーバ（２０１）で生成されるキャプチャー映像は、フォーマットによっては、放送受信端末（１０１）で表示できないフォーマットである可能性もある。その問題に対応するために、放送受信端末（１０１）がリクエスト情報を生成する際に、端末が受信したい映像のフォーマットを端末側で指定しておき、リクエスト情報にそのフォーマット情報も含めることによりサーバから送られてくるキャプチャー映像を表示可能とすることができる。
【００５４】
放送受信装置（１０１）に設けられている表示手段（１０４）は、その能力によってはフルカラーの映像表示ができない場合がある。この問題を解決するために、放送受信端末（１０１）がリクエスト情報を生成する際に、表示可能な最大色数情報を端末側で指定し、リクエスト情報にその最大色数情報も含めることにより、サーバから送られてくるキャプチャー映像を表示可能とすることができる。
【００５５】
上記の拡大率において、ユーザーがある特定の拡大率でキャプチャー映像をリクエストした場合、実際に得られたキャプチャー映像が自分が期待していたものと異なっていたという可能性もある。拡大率を数値で指定すると、どのくらいの拡大率でどのくらいの拡大映像が得られるかは、ある程度の経験を踏まないと想定しにくい。この際、一度映像をリクエストした後に、再度、別の拡大率でリクエストをする場合には、前回と拡大率だけ異なるリクエストを再度行うのはユーザーにとって手間でもあり、リクエストの時間を再度指定すること自体も煩わしい。それを回避するために、複数の拡大率を指定するようにしても良い。今、複数の拡大率ａ１、ａ２、ａ３をリクエスト情報に含めてキャプチャー映像をリクエストすると、放送処理サーバ（２０１）は、拡大率ａ１、ａ２、ａ３の３つの映像を生成し、それらの映像を放送受信端末（１０１）に返信する。このようにすることで、ユーザーは得られた映像を切り替えることで、放送受信端末（１０１）側で複数の拡大率の映像を切り替えることが可能となり、所望の拡大率の映像を得やすくなる。
【００５６】
上記では、複数の拡大率を指定することに関して説明を行ったが、実際には一度でも映像をリクエストしてその映像を見てみないと、所望の映像が最初にリクエストした映像よりさらに拡大される映像であるのか、縮小される映像であるのかがわからない場合がある。上記のように、最初に複数の拡大率の映像をリクエストすると、実際には最初のリクエスト映像のみでよかった場合にも複数の映像を受信することとなり、無駄な通信コストをかけてしまうことになる。この問題を解決するために、放送処理サーバ（２０１）は、ある拡大率aの映像のリクエストを受け付けると、自動的に複数の拡大率の映像も同時に生成し、ユーザーから再度、拡大もしくは縮小のリクエストがあった場合に、すぐに対応できるように構成しておく。より具体的には、放送受信端末（１０１）がリクエストした映像を受信すると、ユーザーにその映像を提示すると同時に、その映像の拡大もしくは縮小のリクエストを簡単に行えるように画面上に表示したり、入力手段のある特定のボタンにキャプチャー映像の拡大縮小機能を割り当てるようにしても良い。
【００５７】
ユーザーがキャプチャー映像のリクエストを開始してから、そのリクエスト情報が放送処理サーバ（２０１）に到達し、キャプチャー映像を生成して、再度放送受信端末（１０１）に送り返すまでには、多少の時間を要する。そのリクエストしたキャプチャー映像が到着するまでの間に、放送受信端末（１０１）で受信した映像から、リクエストしたものと同等の拡大率の映像をデジタルズームインやデジタルズームアウトすることにより生成し、生成した映像を代わりに表示していても良い。
【００５８】
また、ユーザーがキャプチャー映像のリクエストを行ってから、そのリクエスト映像が到着するまでの間に、放送受信端末（１０１）で受信する放送はリアルタイムに進んでいく。例えば、野球のスコア部分を一時的に拡大したい場合などは、その拡大映像を知ることができれば特に問題ない可能性もあるが、リクエストした部分の映像と、その周りの映像と、が同期されていない場合には、まわりの映像とリクエスト映像とが繋がらなくなってしまい、視聴が困難な映像となってしまう可能性がある。それを回避するために、ユーザーがキャプチャー映像をリクエストすると、放送受信端末（１０１）は、リクエスト操作が開始されてから受信する放送を記憶手段（１０６）に録画し、リクエストしたキャプチャー映像が受信できた後に、その受信映像と同期をとってタイムシフト再生することも可能である。
【００５９】
放送受信端末（１０１）及び放送処理サーバ（２０１）にそれぞれ具備されている通信手段（１０７）及び通信手段（２０５）の通信方式としては、有線無線を問わずさまざまな通信方式が想定され、例えば有線ＬＡＮ、無線ＬＡＮ、電話回線網、Ｂｌｕｅｔｏｏｔｈ、光通信などがあるが、特にその方式を限定するものではない。放送受信端末（１０１）が携帯電話機である場合には、放送処理サーバ（２０１）とのデータの送受信を行う手段として、電子メールを使用して行うことも可能である。
【００６０】
上記リクエストするキャプチャー映像については、放送映像の一部の領域に対してリクエストする方法を例にして説明したが、この領域は映像全体であっても良い。また、リクエスト映像としては、静止画でのリクエストに限らず、ストリーミング配信などの動画でのリクエストも可能である。動画の場合、前述のように、映像の一部をリクエストする場合にはタイムシフトを行い、映像全体の同期を取ることが望ましい。但し、映像全体がリクエストされている場合には、放送受信端末（１０１）側で録画を行い、タイムシフトをする必要がない。もしくは、音声のみを記録しておき、送信される映像と同期をとってタイムシフトするという方法でも良い。或いは、映像全体がリクエストされる時には、音声情報も含めて放送処理サーバ（２０１）から配信されるようにしても良い。上記例では、主として拡大を例にして説明したが、縮小するものであっても良い。
【００６１】
以上に詳述したように、本実施の形態によれば、モバイル向けの低解像度放送受信端末においても、高画質な画面キャプチャー及び拡大表示が可能となるという利点がある。
【産業上の利用可能性】
【００６２】
本発明は、放送サーバ装置が生成した画像を表示することができる端末装置を含むシステムに利用可能である。
【図面の簡単な説明】
【００６３】
【図１】放送受信端末の一構成例を示す機能ブロック図である。
【図２】放送処理サーバの一構成例を示す機能ブロック図である。
【図３】放送処理サーバにおける処理の流れを示すフローチャート図である。
【図４】トリミング処理の概要を示す図である。
【図５】事前登録によるキャプチャー映像の授受に関する事前登録の場合のシーケンス図である。
【図６】図５と対応する図であり、事前登録ではなくその都度通知する手法に関するシーケンス図である。
【図７】本実施の形態によるキャプチャー例を示すタイミングチャート図である。
【図８】第１変形例によるキャプチャー例を示すタイミングチャート図である。
【図９】第２変形例によるキャプチャー例を示すタイミングチャート図である。
【図１０】第３変形例によるキャプチャー例を示すタイミングチャート図である。
【図１１】第４変形例によるキャプチャー例を示すタイミングチャート図である。
【図１２】第５変形例によるキャプチャー例を示すタイミングチャート図である。
【符号の説明】
【００６４】
１０１…放送受信端末
１０２…制御手段
１０３…入力手段
１０４…表示手段
１０５…放送受信手段
１０６…記憶手段
１０７…通信手段
２０１…放送処理サーバ
２０２…制御手段
２０３…記憶手段
２０４…放送受信手段
２０５…通信手段
【技術分野】
【０００１】
本発明は、連動型放送画面送受信システムに関し、特に、放送番組を受信・記録・再生できる放送サーバ装置と、放送番組を受信するとともに、放送サーバ装置が生成した画像を表示することができる端末装置とに関する。
【背景技術】
【０００２】
近年、携帯電話機などの携帯端末の普及率が非常に高くなり、だれでもが所持していると言っても過言ではない。さらに、携帯端末に適したデジタル放送であるワンセグデジタル放送を含むモバイル向けデジタル放送が急速に広がりを見せている。このような状況のもとで、ユーザーは、屋外で手軽に番組を視聴できるようになってきた。また、ワンセグデジタル放送では、家庭で視聴できる地上デジタル放送と同じ内容の番組を放送している(サイマル放送）ため、家庭とモバイルユースとで同じ番組を視聴できるというメリットがある。
【０００３】
しかしながら、ワンセグデジタル放送の解像度は、携帯電話のサイズに合わせて規定されており、ワイド放送（16:9比率）の場合、横３２０ドット×縦１８０ドットの解像度しかなく、エラー耐性向上のために、狭い帯域で放送されているため、文字など細かい部分は圧縮ノイズでつぶれてしまうという問題もある。
【０００４】
携帯電話よりも大きい表示画面、例えば８インチ前後の表示画面を持つワンセグ受信機も製造されているが、元の映像（ソース）が鮮明でないため、画面が大きくなっても表示が荒くなるだけであり細部の視認性は向上しない。
【０００５】
このような状況で、スコア表示部分を拡大して表示するという装置が下記特許文献１に、受信状況に応じてワンセグ放送と通信路を用いた映像配信とを切り替えることにより、できるだけ鮮明な映像を見られるようにする装置が特許文献２に開示されている。
【０００６】
【特許文献１】特開２００６−２１１２０７号公報
【特許文献２】特開２００５−３１１４３５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、従来のモバイル端末においては、拡大時に高精細データを取得する仕組みを持ち合わせていないため、モバイル端末側で画像のキャプチャー及び拡大を行った場合に鮮明な画像を得ることが出来ないという問題があった。
【０００８】
本発明は、ワンセグも受信可能な小型端末であっても、鮮明な画像での画面拡大を可能とする連動型放送画面送受信システムを提供することを目的としている。
【課題を解決するための手段】
【０００９】
本発明は、サイマル放送の特性を活かし、サーバ側で受信した高画質な映像を、端末に通信手段を用いて送信することにより、端末側で視聴可能とするものである。
【００１０】
すなわち、本発明に係る連動型放送画面送受信（拡大・縮小）システムは、高解像度の放送を受信できる放送処理サーバと低解像度の放送を受信している放送受信端末を連動させることにより、放送受信端末で高品位なズーム画面を得ることができることを特徴とする。放送受信装置は、ユーザー操作により指定された画面を特定する情報を放送サーバに送り、放送サーバ側で予め記録してある高解像度の画像を取得する。これにより、放送受信端末を用いて、より高画質なイメージを放送受信端末から取得し、高品位が画面拡大を行える連動型放送画面送受信システムが提供される。
【００１１】
すなわち、本発明の一観点によれば、放送受信端末と、該放送受信端末と接続可能な放送処理サーバと、を備えた連動型放送画面送受信システムであって、前記放送受信端末は、第１の解像度の放送を受けることができる第１の放送受信手段と、画像をキャプチャーするタイミングを指定する入力手段と、前記放送処理サーバに対してキャプチャー画面の送信リクエストを行う第１の通信手段と、取得したキャプチャー画面を表示する表示手段と、を有し、前記放送処理サーバは、前記第１の解像度よりも高い解像度の放送を受けることができる第２の放送受信手段と、受信した映像を少なくとも一時的に記憶する記憶手段と、前記放送受信端末から前記送信リクエストに対応する前記第２の解像度の画像データを前記放送受信端末に送信する第２の通信手段と、を有することを特徴とする連動型放送画面送受信システムが提供される。これにより、前記放送受信端末において指定された画像を高解像度で得ることの出来る放送受信端末の画像を拡大したい場合に、放送処理サーバにおいて高画質の画像を得ておき、これを拡大して放送受信端末におくることで、高画質の拡大画像を得ることができる。
【００１２】
前記放送処理サーバが、現在放送されている放送画像のうちから前記放送受信端末から指定された番組指定情報に基づいて特定された放送画像のみを前記記録手段に記録することが好ましく、また、前記放送受信端末において選局操作を行うと、該選局操作を行った放送局のサービス情報が前記放送処理サーバに送られるように放送局に要求することが好ましい。これにより、放送処理サーバが放送受信端末で受信しているサービスのみを記録することが可能になる。
【００１３】
本発明の他の観点によれば、第１の解像度で画像を表示可能な放送受信端末と、該放送受信端末と接続可能な前記第１の解像度よりも高解像度の第２の解像度で画像を表示可能な放送処理サーバと、を備えた連動型放送画面送受信システムにおける放送処理サーバであって、前記放送受信端末から前記放送処理サーバに対して、端末の表示特性と、番組指定情報と時間同期情報と、拡大エリア情報と、拡大率とを含む要求画像情報と、に基づいてキャプチャー画像の要求に応じて、該要求画像情報に基づいて前記第２の解像度の画像をソースとして前記放送処理サーバにおいてキャプチャー画像を生成し、該キャプチャー画像を前記放送受信端末に送信することを特徴とする放送処理サーバが提供される。これにより、拡大画像であっても、放送受信端末において高画質で表示させることができる。
【発明の効果】
【００１４】
以上に説明したように、本発明によれば、例えばモバイル向けの低解像度放送受信端末においても、高画質な画面キャプチャー及び拡大表示が可能となる。
【発明を実施するための最良の形態】
【００１５】
本明細書において、画像という用語は、静止画像と動画像とを含むものとする。以下、本発明の一実施の形態による放送画面拡大技術について図面を参照しながら説明を行う。
【００１６】
まず、放送受信端末(１０１)と放送処理サーバ（２０１）との連動による放送画面拡大技術について説明する。
【００１７】
図１左図は、放送受信端末の一構成例を示す機能ブロック図である。図１左図に示すように、放送受信端末（１０１）は、全体を制御する制御手段（１０２）と、入力手段（１０３）と、表示手段（１０４）と、記憶手段（１０６：インターフェイスを含む）と、一般的な通信手段１０７と、ワンセグなどの放送を受信する放送受信手段（１０５）を備えている。
【００１８】
図１右図は、放送処理サーバの一構成例を示す機能ブロック図である。図１右図に示す放送処理サーバ（２０１）は、全体を制御する制御手段（２０２）と、記憶手段（２０３）と、放送受信手段（２０４）と、通信手段（２０５）とを備えている。
【００１９】
放送受信端末（１０１）においては、放送受信手段（１０５）によって受信された放送データは、制御手段（１０２）に送られる。制御手段（１０２）に送られた放送データに関してデコードなどの信号処理が行われ、ユーザーが視聴可能な形式に変換される。変換された映像データは表示手段（１０４）に送られ、映像が表示される。音声データは図示しない音声出力手段に送られ、音声が出力される。
【００２０】
ユーザーが、放送受信端末（１０１）を利用してワンセグ放送の野球を視聴していたとする。ワンセグ放送は、テレビ放送の電波を受信するため、移動しながらの視聴、もしくは、ビルの谷間などでの視聴であれば、電波状況が悪くなりブロックノイズが発生することがある。また、１セグ放送のコンテンツのビットレートは高くなく、サイズもＱＶＧＡのため映像内のテロップや野球のスコアなどは認識が難しい場合がある。
【００２１】
ユーザーが、映像上に表示されているスコアをより鮮明に確認したいと思った時に、入力手段（１０３）から、そのスコア部分の領域を指定することができるように構成されている。領域の指定方法は、特に限定されるものではないが、例えば入力手段として表示手段（１０４）に対してタッチパネル機能を備えておき、タッチペンなどでその領域を直接なぞるなどして指定することができる。尚、タッチパネルが備えらえていない場合でも、入力手段（１０３）に備えられているボタンなどを押下することを契機として領域指定モードとなるように構成しておくことで、入力手段（１０３）に備わっている上下左右移動キー及び決定ボタンにより、領域を指定することが可能である。また、画面全体を領域として指定するようにしても良い。
【００２２】
ここで、領域情報について、図２、図３を参照しながら説明を行う。図２は、映像領域とズームしたい領域との位置を示す図である。図３は、サーバ側における拡大時の処理の流れを示すフローチャート図である。図５は、事前登録によるキャプチャー映像の授受に関する事前登録の場合のシーケンス図である。
【００２３】
事前に、放送受信端末１０１から放送処理サーバ２０１に対して、端末情報を送る（１４１）。端末情報は、端末ＩＤ、端末画面サイズ、対応フォーマット、表示色数、取得可能最大サイズなどであり、予めこれらの取得した端末情報が、放送処理サーバ２０１に保存される（１４３）。
【００２４】
尚、映像領域とは、ユーザーが放送受信端末（１０１）で視聴している放送映像の全体の領域を示す。仮に、図２の映像領域１中においてユーザーが網模様で示される領域を指定したとする。この際、映像領域１全体の横の長さに対する、映像領域１の左端から、ユーザーが指定した領域の左端までの距離の割合をＸ１％とし、右端までの距離の割合をＸ２％とし、映像領域１全体の縦の長さに対する、映像領域１の上端からユーザーが指定する領域の上端までの距離の割合をＹ１％とし、下端までの距離の割合をＹ２％とする。また、ユーザーが指定した領域のうち、放送受信端末（１０１）の表示画面上の縦横のピクセル数をそれぞれＹ０ピクセル、Ｘ０ピクセルとする。
【００２５】
以上の（Ｘ０、Ｘ１、Ｘ２、Ｙ０、Ｙ１、Ｙ２）の６つの情報群を領域（エリア）情報と称する。例えば、ＱＶＧＡ（縦２４０ピクセル、横３２０ピクセル）のワンセグ放送を、縦４００ピクセル、横２４０ピクセルのＷＱＶＧＡの液晶ディスプレイに表示して視聴しているとする。この時、ＱＶＧＡのワンセグ放送のコンテンツは、横２４０ピクセルの液晶ディスプレイに表示されるため、映像の縦横の比率を変更しないで縮小する場合には、映像の縦横を２５％縮小して、縦１８０ピクセル、横２４０ピクセルの映像をしていることになる。
【００２６】
ここで、ユーザーが、Ｘ１＝２５％、Ｘ２＝７５％、Ｙ１＝２５％、Ｙ２＝７５％となるような領域を指定したとする。現在、ユーザーは縦１８０ピクセル、横２４０ピクセルの映像を見ているため、Ｘ１とＸ２とで挟まれた領域は５０％となり、Ｘ０＝１２０ピクセルとなる。同様にＹ１とＹ２とで挟まれた領域も５０％となるため、Ｙ０＝９０ピクセルとなる。従って、領域情報は（１２０、２５、７５、９０、２５、７５）となる。
【００２７】
ユーザーが領域を指定すると、自動的に、もしくは、入力手段（１０３）に備わっている情報送信のためのボタンを押下することにより、指定された領域情報（エリア情報）を、通信手段（１０７）を介して放送処理サーバ（２０１）に送信することができる。尚、通信手段（１０７）とは、携帯電話などの場合のパケット通信機能や、無線ＬＡＮに対応している端末の場合には無線ＬＡＮユニット、赤外線での通信が可能な場合には赤外線ユニット、有線のＬＡＮやＢｌｕｔｏｏｔｈなどが該当するが、通信手段を具体的に限定するものではない。
【００２８】
放送受信端末（１０１）は、領域情報を放送処理サーバ（２０１）に送信する際に、ユーザーがどのチャンネルを視聴していたかを示すチャンネル情報（番組指定情報）、ユーザーが視聴している１セグ放送映像の縦横のサイズ（ピクセル数）も付加する。送信する情報には、端末ＩＤ、時間同期情報、拡大率などを含んでも良い。以下、放送処理サーバ（２０１）に送信する情報を、まとめてリクエスト情報と記載する。
【００２９】
放送処理サーバ（２０１）は、通信手段（２０５）を用いてリクエスト情報を受信することができる（ステップＳ１：図５の１４１及び１４５）。リクエスト情報を受信した放送処理サーバ（２０１）は、そのリクエスト情報を制御手段（２０２）において解析し、リクエスト情報に含まれているチャンネル情報を取得する。チャンネル情報を取得した放送処理サーバ（２０１）は、放送受信手段（２０４）よりチャンネル情報に基づくチャンネルに対応する内容の地上波放送の受信を開始し、その受信映像をキャプチャーし、例えば記憶手段（２０３）に記録する（ステップＳ２：図５の１４７）。この際、時間同期情報を利用しても良い。
【００３０】
尚、時間同期情報とは、放送処理サーバ（２０１）から放送受信端末（１０１）に送信される放送と、放送受信端末（１０１）が自ら受信する放送と、の間における時間的な同期を行うために必要な情報であり、例えば番組の開始タイミングと番組の終了タイミングとをそれぞれの放送で一致させるための情報を指す。
【００３１】
次に、リクエスト情報に含まれている領域情報のＸ１、Ｘ２、Ｙ１、Ｙ２の値を用いて、キャプチャーした映像から指定された領域のみを切り出す（トリミング：ステップＳ３）。この際に切り出されたキャプチャー映像のサイズは、地上波放送の元の映像の解像度に依存するが、元の映像の解像度がどのようなサイズであっても、後述するように、領域情報のＸ０、Ｙ０の値にスケーリングすることにより（トリミング：ステップＳ５）、ユーザーが放送受信端末で指定した領域と同解像度のキャプチャー映像を生成することができる。尚、放送処理サーバ（２０１）が受信する地上波放送の解像度は、放送受信端末（１０１）が受信する放送の解像度より大きいことが好ましいが、キャプチャー映像をスケーリングする時に拡大も縮小も可能であれば、最終的に求められるキャプチャー映像を生成することは可能である。尚、このシステムでは、放送受信端末（１０１）で受信可能な放送番組と同様の番組を、放送処理サーバ（２０１）でも受信できることが必要である。
【００３２】
放送処理サーバ（２０１）は、切り出したキャプチャー映像を、通信手段（２０５）を用いて放送受信端末（１０１）に送信する（ステップＳ６：図５の１５１）。放送受信端末（１０１）は放送処理サーバ（２０１）から送信されてきた切り出されたキャプチャー映像を、通信手段（１０７）を用いて受信し、受信した映像を、表示手段（１０４）により表示させる。その場合の表示方法は、ユーザーが指定した領域に当てはめるように表示するようにしても良いし、表示手段のディスプレイが複数具備されている場合は、１セグ放送を表示しているディスプレイ以外のディスプレイに表示させても良い。受信画像は表示又は保存される（１５３）。
【００３３】
図４は、トリミング処理の概要を示す図である。放送受信端末１０１と、放送処理サーバ２０１とが電話回線やインターネットのネットワークを通じて情報の送受信が可能な状態であり、放送処理サーバ２０１の拡大指定領域１２１ａが、放送受信端末１０１の拡大指定領域（Ｙ０ｐｉｘ、Ｘ０ｐｉｘ）に貼付されるイメージである。拡大指定領域１２１ａは、縦ａ×Ｙ０ｐｉｘ、横ａ×Ｘ０ｐｉｘの画像を、トリミング位置１２５でトリミングし、縦Ｙ０ｐｉｘ、横Ｘ０ｐｉｘの領域１２７とする。これを放送受信端末１０１の表示部１０４の拡大指定領域１２１に合わせるようにキャプチャー画像として送信し貼付される。
【００３４】
放送処理サーバ（２０１）によってキャプチャーされた映像は、地上波放送であり、１セグ放送よりもビットレートが高い映像に基づいて生成されているため、ユーザーの指定するサイズにスケーリングされたとしても高画質な画像であり、ユーザーは、指定した領域を１セグ放送に比べてより鮮明に視認し確認することが可能となる。
【００３５】
尚、上記の例では、１セグ放送と地上波放送とを対象として例示的に説明したが、放送受信端末と放送処理サーバとで、同じ番組を受信できるシステムであればＢＳ放送やＣＳ放送、ＩＰ放送などの別の放送形態の画像の組み合わせでも良い。
【００３６】
図６は、図５と対応する図であり、事前登録ではなくその都度通知する手法に関するシーケンス図である。まず、放送受信端末１０１が放送処理サーバ２０１に対して、キャプチャー画像をリクエストする（１６１）。放送処理サーバ２０１は、キャプチャーイメージを生成する（１６３）。このキャプチャー画像を放送受信端末１０１に送信し（１６５）、端末１０１において受信画像を表示又は保存する（１６７）。
【００３７】
次に、第１変形例について説明する。上記の説明において、放送受信端末（１０１）を所持するユーザーがキャプチャー領域を指定し、リクエスト情報が放送処理サーバ（２０１）に到達してから地上波放送の受信を開始してキャプチャーを行う手法について説明したが、このような手法によれば、システムの起動や指定された番組のチューニングなどに時間を要してしまい、実際にキャプチャーされた映像が、ユーザーの意図していた映像よりも後の時間にキャプチャーされた映像となってしまう可能性もある（図７参照）。
【００３８】
この問題を回避する方法として、第１変形例では、図８に示すように、放送処理サーバ（２０１）が地上波放送の全チャンネルを録画し続けており、放送受信端末によってリクエスト情報が生成される際に、その時刻を情報としてリクエスト情報に含め、そのリクエスト情報を受信した放送処理サーバ（２０１）は、録画済のコンテンツ中からリクエスト情報に含まれている指定されたチャンネルであり、かつ、指定された時刻に対応する部分のコンピュータを読み出し、その映像に基づいてキャプチャー映像を生成する。
【００３９】
また、上記の第１変形例による説明において、放送処理サーバ（２０１）が複数の放送受信端末（１０１）からのリクエストを受け付けるサーバである場合には、全チャンネルを全て記録しておくと、複数のリクエストにも答えることが可能である。しかしながら、単一の放送受信端末（１０１）に対する専用の放送処理サーバ（２０１）であり、他の放送受信端末（１０１）のリクエストを受信する必要がない構成の場合には、ユーザーが視聴しているチャンネル以外のチャンネルを、放送処理サーバで記録していても無駄となる。
【００４０】
第２変形例では、図９に示すように、この問題を回避するために、ユーザーが視聴するチャンネルもしくは視聴する可能性のあるチャンネルを予め放送処理サーバ（２０１）に設定しておき、その設定されたチャンネルのみ記録しておく構成を有している。
【００４１】
上記放送処理サーバ（２０１）において、ユーザーが放送受信端末（１０１）で視聴を行っていない時間に記録されたコンテンツは、ユーザーからのリクエストが来ることがないため無駄となるものである。この問題を回避するために、図１０に示す第３変形例では、ユーザーが放送受信端末（１０１）で視聴を開始した時点で、自動的にそのチャンネル情報を放送処理サーバ（２０１）に送信し、放送処理サーバ（２０１）は、そのチャンネル情報を受信したときに、チャンネルの記録を開始する方法である。このようにすることで、放送処理サーバ（２０１）は、ユーザーが視聴しているコンテンツのみが記録され、余計なコンテンツの記録を抑制することができる。尚、ユーザーが視聴チャンネルを変更した際も同様にチャンネル情報を放送処理サーバに送信し、その情報を受信した放送処理サーバ（２０１）は、それまでに記録していたコンテンツを自動的に削除するように構成しても良い。また、視聴を終了した時にも、視聴の終了を表す情報を送信することにより、放送処理サーバ（２０１）でのコンテンツ記録を停止し、記録していたコンテンツを自動的に消去するようにすることで、記憶手段（２０３）の容量を効率良く使用することができるという利点がある。
【００４２】
上記チャンネル情報は、ユーザーが視聴チャンネルを変更するたびに送信されるようにすると、ユーザーは単に興味のある番組が放送されていないかなどを確認するためだけにチャンネルを次々送っている場合に、その都度、チャンネル情報が送信されてしまう。すると、放送受信端末（１０１）のチャンネル情報送信処理や、放送処理サーバ（２０１）の記録処理が無駄となってしまうという問題がある。
【００４３】
そこで、図１１に示す第４変形例では、ユーザーが放送を選局してから別のチャンネルに選局されること無くある一定時間経過した場合に、チャンネル情報を送信する。このようにすると、ユーザーがチャンネルを次々と切り替えている間は、放送処理サーバ（２０１）ではコンテンツの記録を行わないため、ユーザーの番組視聴がある一定時間経過し落ち着いた段階でサーバでの記録を開始することが可能となり、余計な処理を行わなくて済む。
【００４４】
上記放送処理サーバ（２０１）のコンテンツ記録機能は、コンテンツの記録を開始したら記録し続けるか、もしくは、記録を終了するのは視聴が終了するまで、というように想定されていた。しかしながら、ユーザーがキャプチャー映像のリクエストのための処理を開始してから何時間も後に、放送処理サーバ（２０１）リクエストが到着するということは考えにくい。ユーザーがリクエスト開始した時と、キャプチャー映像が放送受信端末に到着した時との間に大きな時間のずれがあると、キャプチャー映像自体がユーザーにとって古いものとなってしまい、キャプチャー映像を受信する意味が薄れてしまうことも考えられる。そこで、放送処理サーバ（２０１）は、コンテンツの記録時間を、例えば５分又は１０分などの特定の時間を最大の記録時間とし、その時間前の部分を順次消去していくように構成されていても良い。その最大記録時間の長さについては、放送受信端末がチャンネル情報を送信して放送の記録を開始させる場合には、そのチャンネル情報と共に、最大記録時間を放送処理サーバに送信することで、その時間分だけ常に記録するように動作するようにしても良いし、予め特定の時間が決められているように構成されていても良い。このようにするために、リングバッファなどを利用することが可能であり、放送処理サーバ（２０１）は記憶手段の容量不足を抑制することができる。
【００４５】
尚、放送受信端末（１０１）がキャプチャー映像をリクエストする際に、送信する時刻情報は、放送受信端末（１０１）に内蔵されている時計（図示せず）から取得すれば良い。或いは、放送受信端末（１０１）が、放送受信時に取得可能な放送ＴＳ内のＴＯＴ情報から取得しても良い。もしくは、放送受信端末（１０１）が、放送受信時に取得可能な放送ＴＳ内のＰＣＲ情報から取得しても良い。
【００４６】
尚、ＴＳ内のＴＯＴもしくはＰＣＲ情報から時刻情報を取得する際に、放送の受信状態が悪化し、リクエストをしたい時刻情報が取得できなかった時には、ＴＳから時刻情報を最後に受信できた時間から、リクエストを行う時間までを内蔵時計で計測し、その計測結果として得られる時刻情報を用いる構成でも良い。
【００４７】
また、図１２に示す第５変形例では、ユーザーが、キャプチャー映像をリクエストする際に、リクエストしたいと思った瞬間から、リクエスト操作を開始するまでに多少の時差が発生し、ユーザーが望んでいるキャプチャー映像を逃してしまう可能性が高い。そこで、リクエスト操作を開始した時間より、例えば数秒前の時間の時刻情報が送信されるようにすることで、ユーザーがリクエストしたい瞬間のキャプチャー映像に遡って近づけることが可能となる。但し、ここでいう数秒前とは、ユーザーの設定によるものでも良いし、デフォルトの値でも良いし、どの程度の時間にするかは、ユーザーや映像に応じて適宜変化させるようにしても良い。
【００４８】
ユーザーが、放送受信端末（１０１）を使用して、例えば野球番組を視聴しており、画面右下のスコア情報をキャプチャー画面としてリクエストした場合に、野球の進展によってそのスコア情報は変化することがある。このような場合に、変化が発生するたびに同様のエリアを毎回指定し、キャプチャー映像をリクエストするのはユーザーにとって手間となり煩わしいという問題がある。この問題を解消するために、一度、ユーザーがキャプチャー映像のリクエストを行うと、その後は一定の間隔で同様のエリアのキャプチャー情報を自動的にリクエストするような構成としても良い。この際、一定の間隔とは、ある特定の間隔に限定されるものではなく、ユーザーが最初のリクエスト時に指定するようにしても良いし、視聴しているコンテンツのタイトルや種類や種目、もしくはコンテンツのジャンルによって決められるように構成されていても良い。
【００４９】
次に、ユーザーが指定する「拡大率情報」について、図２を参照しながら説明する。現在、図に示されるように、領域情報として、（Ｘ０、Ｘ１、Ｘ２、Ｙ０、Ｙ１、Ｙ２）が指定されているとする。この時、拡大率を次のように定義する。サーバで録画しているコンテンツにおいて、上記Ｘ１、Ｘ２、Ｙ１、Ｙ２によって指定された領域をＸ０ピクセル、Ｙ０ピクセルに縮小した映像の拡大率を１倍とする。
【００５０】
例えば、拡大率を「ａ倍」と指定した場合に、サーバで録画しているコンテンツにおいて、上記Ｘ１、Ｘ２、Ｙ１、Ｙ２によって指定された領域を、ａ×Ｘ０ピクセル、ａ×Ｙ０ピクセルのサイズに縮小した映像となる。このように、上記「領域情報」Ｘ０、Ｘ１、Ｘ２、Ｙ０、Ｙ１、Ｙ２と、「拡大率情報」ａを含む「リクエスト情報」と、を、放送処理サーバ（２０１）に送信することにより、リクエストする映像の拡大率を指定することができる。
【００５１】
この場合において、取得したいサイズをａ×Ｘ０ピクセル、ａ×Ｙ０ピクセルとするために、拡大率「ａ」として指定したが、拡大率を指定する代わりに、取得したいサイズを直接指定しても良い。この時、ユーザーはリクエスト情報生成時に、取得したい映像のサイズを、入力手段（１０３）を用いて指定し、その指定されたサイズ情報をリクエスト情報に含めて放送処理サーバ（２０１）に送信する。
【００５２】
また、この場合において、拡大率もしくは取得したいサイズを指定することにより、ユーザーが最初に選択する領域情報のサイズよりも大きいキャプチャー映像を受信することになるが、取得された映像を、最初に指定した領域に当てはめて表示する場合に、放送受信端末（１０１）側で、取得された映像のスケーリング処理を行う必要が出てくる。取得された映像は当初の領域より大きいサイズであっても、受信映像から当初の領域のサイズだけを切り出して表示することも考えられる。この時、放送受信端末（１０１）側で映像のトリミングを行うことも可能であるが、リクエスト情報を生成する際に、トリミング位置を予め指定し、トリミングされた映像を放送処理サーバ（２０１）から先に送信してもらい、後に、リクエストした映像を受信するようにすることで、放送受信端末（１０１）側でスケーリング処理を行う必要がなく、受信した映像をすぐに表示させることができる。
【００５３】
トリミング位置をユーザーが指定する方法としては、最初に領域を指定した際に、その領域内のある１点を指定することにより、受信される予定の映像の同じ点から縦横にＸ０ピクセル、Ｙ０ピクセルとなるサイズがトリミングされた映像とするように指定する方法などが挙げられる。放送処理サーバ（２０１）で生成されるキャプチャー映像は、フォーマットによっては、放送受信端末（１０１）で表示できないフォーマットである可能性もある。その問題に対応するために、放送受信端末（１０１）がリクエスト情報を生成する際に、端末が受信したい映像のフォーマットを端末側で指定しておき、リクエスト情報にそのフォーマット情報も含めることによりサーバから送られてくるキャプチャー映像を表示可能とすることができる。
【００５４】
放送受信装置（１０１）に設けられている表示手段（１０４）は、その能力によってはフルカラーの映像表示ができない場合がある。この問題を解決するために、放送受信端末（１０１）がリクエスト情報を生成する際に、表示可能な最大色数情報を端末側で指定し、リクエスト情報にその最大色数情報も含めることにより、サーバから送られてくるキャプチャー映像を表示可能とすることができる。
【００５５】
上記の拡大率において、ユーザーがある特定の拡大率でキャプチャー映像をリクエストした場合、実際に得られたキャプチャー映像が自分が期待していたものと異なっていたという可能性もある。拡大率を数値で指定すると、どのくらいの拡大率でどのくらいの拡大映像が得られるかは、ある程度の経験を踏まないと想定しにくい。この際、一度映像をリクエストした後に、再度、別の拡大率でリクエストをする場合には、前回と拡大率だけ異なるリクエストを再度行うのはユーザーにとって手間でもあり、リクエストの時間を再度指定すること自体も煩わしい。それを回避するために、複数の拡大率を指定するようにしても良い。今、複数の拡大率ａ１、ａ２、ａ３をリクエスト情報に含めてキャプチャー映像をリクエストすると、放送処理サーバ（２０１）は、拡大率ａ１、ａ２、ａ３の３つの映像を生成し、それらの映像を放送受信端末（１０１）に返信する。このようにすることで、ユーザーは得られた映像を切り替えることで、放送受信端末（１０１）側で複数の拡大率の映像を切り替えることが可能となり、所望の拡大率の映像を得やすくなる。
【００５６】
上記では、複数の拡大率を指定することに関して説明を行ったが、実際には一度でも映像をリクエストしてその映像を見てみないと、所望の映像が最初にリクエストした映像よりさらに拡大される映像であるのか、縮小される映像であるのかがわからない場合がある。上記のように、最初に複数の拡大率の映像をリクエストすると、実際には最初のリクエスト映像のみでよかった場合にも複数の映像を受信することとなり、無駄な通信コストをかけてしまうことになる。この問題を解決するために、放送処理サーバ（２０１）は、ある拡大率aの映像のリクエストを受け付けると、自動的に複数の拡大率の映像も同時に生成し、ユーザーから再度、拡大もしくは縮小のリクエストがあった場合に、すぐに対応できるように構成しておく。より具体的には、放送受信端末（１０１）がリクエストした映像を受信すると、ユーザーにその映像を提示すると同時に、その映像の拡大もしくは縮小のリクエストを簡単に行えるように画面上に表示したり、入力手段のある特定のボタンにキャプチャー映像の拡大縮小機能を割り当てるようにしても良い。
【００５７】
ユーザーがキャプチャー映像のリクエストを開始してから、そのリクエスト情報が放送処理サーバ（２０１）に到達し、キャプチャー映像を生成して、再度放送受信端末（１０１）に送り返すまでには、多少の時間を要する。そのリクエストしたキャプチャー映像が到着するまでの間に、放送受信端末（１０１）で受信した映像から、リクエストしたものと同等の拡大率の映像をデジタルズームインやデジタルズームアウトすることにより生成し、生成した映像を代わりに表示していても良い。
【００５８】
また、ユーザーがキャプチャー映像のリクエストを行ってから、そのリクエスト映像が到着するまでの間に、放送受信端末（１０１）で受信する放送はリアルタイムに進んでいく。例えば、野球のスコア部分を一時的に拡大したい場合などは、その拡大映像を知ることができれば特に問題ない可能性もあるが、リクエストした部分の映像と、その周りの映像と、が同期されていない場合には、まわりの映像とリクエスト映像とが繋がらなくなってしまい、視聴が困難な映像となってしまう可能性がある。それを回避するために、ユーザーがキャプチャー映像をリクエストすると、放送受信端末（１０１）は、リクエスト操作が開始されてから受信する放送を記憶手段（１０６）に録画し、リクエストしたキャプチャー映像が受信できた後に、その受信映像と同期をとってタイムシフト再生することも可能である。
【００５９】
放送受信端末（１０１）及び放送処理サーバ（２０１）にそれぞれ具備されている通信手段（１０７）及び通信手段（２０５）の通信方式としては、有線無線を問わずさまざまな通信方式が想定され、例えば有線ＬＡＮ、無線ＬＡＮ、電話回線網、Ｂｌｕｅｔｏｏｔｈ、光通信などがあるが、特にその方式を限定するものではない。放送受信端末（１０１）が携帯電話機である場合には、放送処理サーバ（２０１）とのデータの送受信を行う手段として、電子メールを使用して行うことも可能である。
【００６０】
上記リクエストするキャプチャー映像については、放送映像の一部の領域に対してリクエストする方法を例にして説明したが、この領域は映像全体であっても良い。また、リクエスト映像としては、静止画でのリクエストに限らず、ストリーミング配信などの動画でのリクエストも可能である。動画の場合、前述のように、映像の一部をリクエストする場合にはタイムシフトを行い、映像全体の同期を取ることが望ましい。但し、映像全体がリクエストされている場合には、放送受信端末（１０１）側で録画を行い、タイムシフトをする必要がない。もしくは、音声のみを記録しておき、送信される映像と同期をとってタイムシフトするという方法でも良い。或いは、映像全体がリクエストされる時には、音声情報も含めて放送処理サーバ（２０１）から配信されるようにしても良い。上記例では、主として拡大を例にして説明したが、縮小するものであっても良い。
【００６１】
以上に詳述したように、本実施の形態によれば、モバイル向けの低解像度放送受信端末においても、高画質な画面キャプチャー及び拡大表示が可能となるという利点がある。
【産業上の利用可能性】
【００６２】
本発明は、放送サーバ装置が生成した画像を表示することができる端末装置を含むシステムに利用可能である。
【図面の簡単な説明】
【００６３】
【図１】放送受信端末の一構成例を示す機能ブロック図である。
【図２】放送処理サーバの一構成例を示す機能ブロック図である。
【図３】放送処理サーバにおける処理の流れを示すフローチャート図である。
【図４】トリミング処理の概要を示す図である。
【図５】事前登録によるキャプチャー映像の授受に関する事前登録の場合のシーケンス図である。
【図６】図５と対応する図であり、事前登録ではなくその都度通知する手法に関するシーケンス図である。
【図７】本実施の形態によるキャプチャー例を示すタイミングチャート図である。
【図８】第１変形例によるキャプチャー例を示すタイミングチャート図である。
【図９】第２変形例によるキャプチャー例を示すタイミングチャート図である。
【図１０】第３変形例によるキャプチャー例を示すタイミングチャート図である。
【図１１】第４変形例によるキャプチャー例を示すタイミングチャート図である。
【図１２】第５変形例によるキャプチャー例を示すタイミングチャート図である。
【符号の説明】
【００６４】
１０１…放送受信端末
１０２…制御手段
１０３…入力手段
１０４…表示手段
１０５…放送受信手段
１０６…記憶手段
１０７…通信手段
２０１…放送処理サーバ
２０２…制御手段
２０３…記憶手段
２０４…放送受信手段
２０５…通信手段
【特許請求の範囲】
【請求項１】
放送受信端末と、該放送受信端末と接続可能な放送処理サーバと、を備えた連動型放送画面送受信システムであって、
前記放送受信端末は、
第１の解像度の放送を受けることができる第１の放送受信手段と、
画像をキャプチャーするタイミングを指定する入力手段と
前記放送処理サーバに対してキャプチャー画面の送信リクエストを行う第１の通信手段と、
取得したキャプチャー画面を表示する表示手段と、を有し、
前記放送処理サーバは、前記第１の解像度よりも高い解像度の放送を受けることができる第２の放送受信手段と
受信した映像を少なくとも一時的に記憶する記憶手段と
前記放送受信端末から前記送信リクエストに対応する前記第２の解像度の画像データを前記放送受信端末に送信する第２の通信手段と、を有することを特徴とする連動型放送画面送受信システム。
【請求項２】
前記放送処理サーバが、現在放送されている全てのチャンネルの放送画像を前記記憶手段に記録し、前記放送受信端末から指定された番組指定情報に基づいてリクエスト画面を生成するリクエスト画面生成部を有することを特徴とする請求項１に記載の連動型放送画面送受信システム。
【請求項３】
前記放送処理サーバが、現在放送されている放送画像のうち、前記放送受信端末から指定された番組指定情報に基づいて特定された放送画像のみを前記記憶手段に記録することを特徴とする請求項１に記載の連動型放送画面送受信システム。
【請求項４】
前記放送受信端末において選局操作を行うと、該選局操作を行った放送局のサービス情報が前記放送処理サーバに送られるように放送局に要求することを特徴とする請求項３に記載の連動型放送画面送受信システム。
【請求項５】
前記放送受信端末の選局間隔がある間隔以上の場合にのみ、サービス情報が前記放送処理サーバに送られるように要求されることを特徴とする請求項３又は４に記載の連動型放送画面送受信システム。
【請求項６】
前記放送受信端末から最低記憶時間を前記放送処理サーバに送ると、該放送処理サーバが前記最低記憶時間に対応する必要な時間だけ放送を記録することを特徴とする請求項２から５までのいずれか１項に記載の連動型放送画面送受信システム。
【請求項７】
前記放送受信端末がリクエストする画像の時間帯を前記放送受信端末の内蔵タイマから取得することを特徴とする請求項２〜６までのいずれか１項に記載の連動型放送画面送受信システム。
【請求項８】
前記放送受信端末がリクエストする画像の時間帯を放送ＴＳのＴＯＴ情報から取得することを特徴とする請求項２から６までのいずれか１項に記載の連動型放送画面送受信システム。
【請求項９】
前記放送受信端末がリクエストする画像の時間帯を放送ＴＳのＰＣＲ情報から取得することを特徴とする請求項２から６までのいずれか１項に記載の連動型放送画面送受信システム。
【請求項１０】
受信状態が悪くなると、最後にＴＳ情報を取得出来た時間からの経過時間を前記内蔵タイマにより計測することでリクエストする画像の時間帯を算出することを特徴とする請求項８又は９に記載の連動型放送画面送受信システム。
【請求項１１】
放送を少なくとも一時的にバッファリングして記憶する一時記憶部を備え、視聴中にリクエスト操作をした時間よりも（数秒）前の時間を自動的に指定すると、不足分の放送を前記一時記憶部から取り出して補完することを特徴とする請求項２から１０までのいずれか１項に記載の連動型放送画面送受信システム。
【請求項１２】
前記放送受信端末から最初に指定した時間からある間隔で、繰り返しリクエストを繰り返す処理を行うことを特徴とする請求項２〜１１までのいずれか１項に記載の連動型放送画面送受信システム。
【請求項１３】
前記放送受信端末から、拡大率を前記放送処理サーバに送信することにより、該放送処理サーバ側において生成されるリクエスト画像の拡大率を指定することを特徴とする請求項１から１２までのいずれか１項に記載の連動型放送画面送受信システム。
【請求項１４】
前記放送受信端末から、指定された領域情報（エリア情報）を前記放送処理サーバに送信することにより、該放送処理サーバ側において生成されるリクエスト画像のサイズを指定することを特徴とする請求項１から１３までのいずれか１項に記載の連動型放送画面送受信システム。
【請求項１５】
指定された領域情報（エリア情報）に基づいて、キャプチャーした映像から指定された領域のみを切り出す前記リクエスト画像のトリミング位置を指定することを特徴とする請求項１から１４までのいずれか１項に記載の連動型放送画面送受信システム。
【請求項１６】
放送受信端末が放送処理サーバから送信される画像フォーマットを指定することが出来ることを特徴とする請求項１から１５までのいずれか１項に記載の連動型放送画面送受信システム。
【請求項１７】
放送受信端末が放送処理サーバから送信される画像の最大色数を指定することが出来ることを特徴とする請求項１から１６までのいずれか１項に記載の連動型放送画面送受信システム。
【請求項１８】
前記拡大率を複数指定することによって、同時に複数の画像をリクエスト可能とすることを特徴とする請求項１３に記載の連動型放送画面送受信システム。
【請求項１９】
請求項１３及び１８に記載の連動型放送画面送受信システムにおいて用いられ、リクエスト受付時にリクエストされた拡大率以外の拡大率の画像も前もって生成し、保存しておくことを特徴とする放送処理サーバ。
【請求項２０】
請求項１から１９までのいずれか１項に記載の連動型放送画面送受信システムにおいて用いられ、前記放送処理サーバへのリクエスト後に、画像が前記サーバにおいて生成され、前記放送受信端末に送信されるまでの間、リクエストした時間帯の前記放送受信端末で受信する放送受信データの映像をデジタルズームして表示することを特徴とする放送受信端末。
【請求項２１】
請求項１から２０までのいずれか１項に記載の連動型放送画面送受信システムにおいて用いられ、放送をタイムシフトすることにより、前記放送受信サーバから受け取った画像を放送と同期を取って表示する早期手段を有することを特徴とする放送受信端末。
【請求項２２】
請求項１から２１までのいずれか１項に記載の連動型放送画面送受信システムにおいて、サーバへのリクエストあるいはサーバからの画像取得を電子メールにより行うことを特徴とする放送受信端末。
【請求項２３】
第１の解像度で画像を表示可能な放送受信端末と、該放送受信端末と接続可能な前記第１の解像度よりも高解像度の第２の解像度で画像を表示可能な放送処理サーバと、を備えた連動型放送画面送受信システムであって、
前記放送受信端末から前記放送処理サーバに対して、端末の表示特性と、番組指定情報と時間同期情報と、拡大エリア情報と、拡大率とを含む要求画像情報と、に基づいてキャプチャー画像を要求すると、
該要求画像情報に基づいて前記第２の解像度の画像をソースとして前記放送処理サーバにおいてキャプチャー画像を生成し、該キャプチャー画像を前記放送受信端末に送信することを特徴とする連動型放送画面送受信システム。
【請求項２４】
第１の解像度で画像を表示可能な放送受信端末と、該放送受信端末と接続可能な前記第１の解像度よりも高解像度の第２の解像度で画像を表示可能な放送処理サーバと、を備えた連動型放送画面送受信システムにおける放送受信端末であって、
前記放送受信端末から前記放送処理サーバに対して、端末の表示特性と、番組指定情報と時間同期情報と、拡大エリア情報と、拡大率と、を含む要求画像情報と、に基づいてキャプチャー画像を要求し、該要求画像情報に基づいて前記第２の解像度の画像をソースとして前記放送処理サーバにおいてキャプチャー画像を生成し、該キャプチャー画像を受信することを特徴とする放送受信端末。
【請求項２５】
第１の解像度で画像を表示可能な放送受信端末と、該放送受信端末と接続可能な前記第１の解像度よりも高解像度の第２の解像度で画像を表示可能な放送処理サーバと、を備えた連動型放送画面送受信システムにおける放送処理サーバであって、
前記放送受信端末から前記放送処理サーバに対して、端末の表示特性と、番組指定情報と時間同期情報と、拡大エリア情報と、拡大率とを含む要求画像情報と、に基づいたキャプチャー画像の要求に応じて、該要求画像情報に基づいて前記第２の解像度の画像をソースとして前記放送処理サーバ側でキャプチャー画像を生成し、該キャプチャー画像を前記放送受信端末に送信することを特徴とする放送処理サーバ。
【請求項２６】
前記放送受信端末から、指定された領域情報（エリア情報）を前記放送処理サーバに送信することにより、該放送処理サーバ側において生成されるリクエスト画像のサイズを指定することを特徴とし、
前記放送受信端末により視聴している放送映像の全体の領域である映像領域中において、該映像領域全体の横の長さに対する、映像領域の左端から指定された領域の左端までの距離の割合をＸ１％とし、右端までの距離の割合をＸ２％とし、映像領域全体の縦の長さに対する映像領域の上端からユーザーが指定する領域の上端までの距離の割合をＹ１％とし、下端までの距離の割合をＹ２％とし、ユーザーが指定した領域のうち、放送受信端末の表示画面上の縦横のピクセル数をそれぞれＹ０ピクセル、Ｘ０ピクセルとすると、前記放送処理サーバ側において、前記Ｘ１、Ｙ１、Ｘ２，Ｙ２を用いて、取り込み画像の一部をトリミングし、前記Ｘ０、Ｙ０により規定される前記放送受信端末における表示サイズに、指定された拡大率ａを乗算して得られたサイズに前記トリミングした画像を縮小し、前記放送受信端末における表示サイズ（Ｘ０、Ｙ０）で、前記縮小された画像をトリミングすることを特徴とする請求項１から１３までのいずれか１項に記載の連動型放送画面送受信システム。
【請求項２７】
第１の解像度で画像を表示可能な放送受信端末と、該放送受信端末と接続可能な前記第１の解像度よりも高解像度の第２の解像度で画像を表示可能な放送処理サーバと、を備えた連動型放送画面送受信システムを利用した放送視聴方法であって、
前記放送受信端末から前記放送処理サーバに対して、端末の表示特性を送るステップと、
前記放送受信端末から前記放送処理サーバに対して、番組指定情報と時間同期情報と、拡大エリア情報と、拡大率とを含む要求画像情報に基づいてキャプチャー画像を要求するステップと、
該要求画像情報に基づいて前記第２の解像度の画像をソースとして前記放送処理サーバにおいてキャプチャー画像を生成するステップと、
該キャプチャー画像を前記放送受信端末に送信するするステップと
を有することを特徴とする放送視聴方法。
【請求項２８】
請求項２７に記載のステップをコンピュータに実行させるためのプログラム又はそれを記憶する記録媒体。
【請求項１】
放送受信端末と、該放送受信端末と接続可能な放送処理サーバと、を備えた連動型放送画面送受信システムであって、
前記放送受信端末は、
第１の解像度の放送を受けることができる第１の放送受信手段と、
画像をキャプチャーするタイミングを指定する入力手段と
前記放送処理サーバに対してキャプチャー画面の送信リクエストを行う第１の通信手段と、
取得したキャプチャー画面を表示する表示手段と、を有し、
前記放送処理サーバは、前記第１の解像度よりも高い解像度の放送を受けることができる第２の放送受信手段と
受信した映像を少なくとも一時的に記憶する記憶手段と
前記放送受信端末から前記送信リクエストに対応する前記第２の解像度の画像データを前記放送受信端末に送信する第２の通信手段と、を有することを特徴とする連動型放送画面送受信システム。
【請求項２】
前記放送処理サーバが、現在放送されている全てのチャンネルの放送画像を前記記憶手段に記録し、前記放送受信端末から指定された番組指定情報に基づいてリクエスト画面を生成するリクエスト画面生成部を有することを特徴とする請求項１に記載の連動型放送画面送受信システム。
【請求項３】
前記放送処理サーバが、現在放送されている放送画像のうち、前記放送受信端末から指定された番組指定情報に基づいて特定された放送画像のみを前記記憶手段に記録することを特徴とする請求項１に記載の連動型放送画面送受信システム。
【請求項４】
前記放送受信端末において選局操作を行うと、該選局操作を行った放送局のサービス情報が前記放送処理サーバに送られるように放送局に要求することを特徴とする請求項３に記載の連動型放送画面送受信システム。
【請求項５】
前記放送受信端末の選局間隔がある間隔以上の場合にのみ、サービス情報が前記放送処理サーバに送られるように要求されることを特徴とする請求項３又は４に記載の連動型放送画面送受信システム。
【請求項６】
前記放送受信端末から最低記憶時間を前記放送処理サーバに送ると、該放送処理サーバが前記最低記憶時間に対応する必要な時間だけ放送を記録することを特徴とする請求項２から５までのいずれか１項に記載の連動型放送画面送受信システム。
【請求項７】
前記放送受信端末がリクエストする画像の時間帯を前記放送受信端末の内蔵タイマから取得することを特徴とする請求項２〜６までのいずれか１項に記載の連動型放送画面送受信システム。
【請求項８】
前記放送受信端末がリクエストする画像の時間帯を放送ＴＳのＴＯＴ情報から取得することを特徴とする請求項２から６までのいずれか１項に記載の連動型放送画面送受信システム。
【請求項９】
前記放送受信端末がリクエストする画像の時間帯を放送ＴＳのＰＣＲ情報から取得することを特徴とする請求項２から６までのいずれか１項に記載の連動型放送画面送受信システム。
【請求項１０】
受信状態が悪くなると、最後にＴＳ情報を取得出来た時間からの経過時間を前記内蔵タイマにより計測することでリクエストする画像の時間帯を算出することを特徴とする請求項８又は９に記載の連動型放送画面送受信システム。
【請求項１１】
放送を少なくとも一時的にバッファリングして記憶する一時記憶部を備え、視聴中にリクエスト操作をした時間よりも（数秒）前の時間を自動的に指定すると、不足分の放送を前記一時記憶部から取り出して補完することを特徴とする請求項２から１０までのいずれか１項に記載の連動型放送画面送受信システム。
【請求項１２】
前記放送受信端末から最初に指定した時間からある間隔で、繰り返しリクエストを繰り返す処理を行うことを特徴とする請求項２〜１１までのいずれか１項に記載の連動型放送画面送受信システム。
【請求項１３】
前記放送受信端末から、拡大率を前記放送処理サーバに送信することにより、該放送処理サーバ側において生成されるリクエスト画像の拡大率を指定することを特徴とする請求項１から１２までのいずれか１項に記載の連動型放送画面送受信システム。
【請求項１４】
前記放送受信端末から、指定された領域情報（エリア情報）を前記放送処理サーバに送信することにより、該放送処理サーバ側において生成されるリクエスト画像のサイズを指定することを特徴とする請求項１から１３までのいずれか１項に記載の連動型放送画面送受信システム。
【請求項１５】
指定された領域情報（エリア情報）に基づいて、キャプチャーした映像から指定された領域のみを切り出す前記リクエスト画像のトリミング位置を指定することを特徴とする請求項１から１４までのいずれか１項に記載の連動型放送画面送受信システム。
【請求項１６】
放送受信端末が放送処理サーバから送信される画像フォーマットを指定することが出来ることを特徴とする請求項１から１５までのいずれか１項に記載の連動型放送画面送受信システム。
【請求項１７】
放送受信端末が放送処理サーバから送信される画像の最大色数を指定することが出来ることを特徴とする請求項１から１６までのいずれか１項に記載の連動型放送画面送受信システム。
【請求項１８】
前記拡大率を複数指定することによって、同時に複数の画像をリクエスト可能とすることを特徴とする請求項１３に記載の連動型放送画面送受信システム。
【請求項１９】
請求項１３及び１８に記載の連動型放送画面送受信システムにおいて用いられ、リクエスト受付時にリクエストされた拡大率以外の拡大率の画像も前もって生成し、保存しておくことを特徴とする放送処理サーバ。
【請求項２０】
請求項１から１９までのいずれか１項に記載の連動型放送画面送受信システムにおいて用いられ、前記放送処理サーバへのリクエスト後に、画像が前記サーバにおいて生成され、前記放送受信端末に送信されるまでの間、リクエストした時間帯の前記放送受信端末で受信する放送受信データの映像をデジタルズームして表示することを特徴とする放送受信端末。
【請求項２１】
請求項１から２０までのいずれか１項に記載の連動型放送画面送受信システムにおいて用いられ、放送をタイムシフトすることにより、前記放送受信サーバから受け取った画像を放送と同期を取って表示する早期手段を有することを特徴とする放送受信端末。
【請求項２２】
請求項１から２１までのいずれか１項に記載の連動型放送画面送受信システムにおいて、サーバへのリクエストあるいはサーバからの画像取得を電子メールにより行うことを特徴とする放送受信端末。
【請求項２３】
第１の解像度で画像を表示可能な放送受信端末と、該放送受信端末と接続可能な前記第１の解像度よりも高解像度の第２の解像度で画像を表示可能な放送処理サーバと、を備えた連動型放送画面送受信システムであって、
前記放送受信端末から前記放送処理サーバに対して、端末の表示特性と、番組指定情報と時間同期情報と、拡大エリア情報と、拡大率とを含む要求画像情報と、に基づいてキャプチャー画像を要求すると、
該要求画像情報に基づいて前記第２の解像度の画像をソースとして前記放送処理サーバにおいてキャプチャー画像を生成し、該キャプチャー画像を前記放送受信端末に送信することを特徴とする連動型放送画面送受信システム。
【請求項２４】
第１の解像度で画像を表示可能な放送受信端末と、該放送受信端末と接続可能な前記第１の解像度よりも高解像度の第２の解像度で画像を表示可能な放送処理サーバと、を備えた連動型放送画面送受信システムにおける放送受信端末であって、
前記放送受信端末から前記放送処理サーバに対して、端末の表示特性と、番組指定情報と時間同期情報と、拡大エリア情報と、拡大率と、を含む要求画像情報と、に基づいてキャプチャー画像を要求し、該要求画像情報に基づいて前記第２の解像度の画像をソースとして前記放送処理サーバにおいてキャプチャー画像を生成し、該キャプチャー画像を受信することを特徴とする放送受信端末。
【請求項２５】
第１の解像度で画像を表示可能な放送受信端末と、該放送受信端末と接続可能な前記第１の解像度よりも高解像度の第２の解像度で画像を表示可能な放送処理サーバと、を備えた連動型放送画面送受信システムにおける放送処理サーバであって、
前記放送受信端末から前記放送処理サーバに対して、端末の表示特性と、番組指定情報と時間同期情報と、拡大エリア情報と、拡大率とを含む要求画像情報と、に基づいたキャプチャー画像の要求に応じて、該要求画像情報に基づいて前記第２の解像度の画像をソースとして前記放送処理サーバ側でキャプチャー画像を生成し、該キャプチャー画像を前記放送受信端末に送信することを特徴とする放送処理サーバ。
【請求項２６】
前記放送受信端末から、指定された領域情報（エリア情報）を前記放送処理サーバに送信することにより、該放送処理サーバ側において生成されるリクエスト画像のサイズを指定することを特徴とし、
前記放送受信端末により視聴している放送映像の全体の領域である映像領域中において、該映像領域全体の横の長さに対する、映像領域の左端から指定された領域の左端までの距離の割合をＸ１％とし、右端までの距離の割合をＸ２％とし、映像領域全体の縦の長さに対する映像領域の上端からユーザーが指定する領域の上端までの距離の割合をＹ１％とし、下端までの距離の割合をＹ２％とし、ユーザーが指定した領域のうち、放送受信端末の表示画面上の縦横のピクセル数をそれぞれＹ０ピクセル、Ｘ０ピクセルとすると、前記放送処理サーバ側において、前記Ｘ１、Ｙ１、Ｘ２，Ｙ２を用いて、取り込み画像の一部をトリミングし、前記Ｘ０、Ｙ０により規定される前記放送受信端末における表示サイズに、指定された拡大率ａを乗算して得られたサイズに前記トリミングした画像を縮小し、前記放送受信端末における表示サイズ（Ｘ０、Ｙ０）で、前記縮小された画像をトリミングすることを特徴とする請求項１から１３までのいずれか１項に記載の連動型放送画面送受信システム。
【請求項２７】
第１の解像度で画像を表示可能な放送受信端末と、該放送受信端末と接続可能な前記第１の解像度よりも高解像度の第２の解像度で画像を表示可能な放送処理サーバと、を備えた連動型放送画面送受信システムを利用した放送視聴方法であって、
前記放送受信端末から前記放送処理サーバに対して、端末の表示特性を送るステップと、
前記放送受信端末から前記放送処理サーバに対して、番組指定情報と時間同期情報と、拡大エリア情報と、拡大率とを含む要求画像情報に基づいてキャプチャー画像を要求するステップと、
該要求画像情報に基づいて前記第２の解像度の画像をソースとして前記放送処理サーバにおいてキャプチャー画像を生成するステップと、
該キャプチャー画像を前記放送受信端末に送信するするステップと
を有することを特徴とする放送視聴方法。
【請求項２８】
請求項２７に記載のステップをコンピュータに実行させるためのプログラム又はそれを記憶する記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２００８−１８２２９９（Ｐ２００８−１８２２９９Ａ）
【公開日】平成２０年８月７日（２００８．８．７）
【国際特許分類】
【出願番号】特願２００７−１２２７９（Ｐ２００７−１２２７９）
【出願日】平成１９年１月２３日（２００７．１．２３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
【出願人】（０００００５０４９）シャープ株式会社 (33,933)
【Ｆターム（参考）】
【公開日】平成２０年８月７日（２００８．８．７）
【国際特許分類】
【出願日】平成１９年１月２３日（２００７．１．２３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
【出願人】（０００００５０４９）シャープ株式会社 (33,933)
【Ｆターム（参考）】
[ Back to top ]