動画像・音声再生携帯端末、及び、動画像・音声配信端末、及び、システム
【課題】通信回線の帯域に制限があり、配信側のコンピュータで動画像のトランスコーディングが必要な場合に、携帯端末の形態や向きの変化に適応させてトランスコーディングの処理を行う。
【解決手段】携帯端末１は、サーバ３に対して、コンテンツを指示するデータと変換パラメータセットを指示するデータとを送る。携帯端末１の形態が画面横向き形態であると、符号化パラメータセット指示データは、画質優先パラメータセット指示データとなる。逆に、画面縦向き形態であったときは、動き優先パラメータセット指示データとなる。サーバ３は、要求されたコンテンツを、コンテンツ保存部から取り出し、指示された変換パラメータセットを用いて、トランスコーディング処理を行い、コンテンツを携帯端末１へ送信する。コンテンツを受信中に携帯端末１の形態の変化が検出されると、携帯端末１は、サーバ３に対して、符号化パラメータセットを指示するデータを送る。
【解決手段】携帯端末１は、サーバ３に対して、コンテンツを指示するデータと変換パラメータセットを指示するデータとを送る。携帯端末１の形態が画面横向き形態であると、符号化パラメータセット指示データは、画質優先パラメータセット指示データとなる。逆に、画面縦向き形態であったときは、動き優先パラメータセット指示データとなる。サーバ３は、要求されたコンテンツを、コンテンツ保存部から取り出し、指示された変換パラメータセットを用いて、トランスコーディング処理を行い、コンテンツを携帯端末１へ送信する。コンテンツを受信中に携帯端末１の形態の変化が検出されると、携帯端末１は、サーバ３に対して、符号化パラメータセットを指示するデータを送る。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツ送受信技術に関し、特に、動画像や音声データを受信し再生する携帯端末、及び、動画像や音声データを携帯端末に向けて配信する配信端末、及びそれらを含むシステムに関する。
【背景技術】
【０００２】
近年、ドラマやニュースなどの動画像や音声データを配信する配信サービスが普及しつつある。このような配信サービスに用いられるシステムは、データ配信用のサーバと、必要であればデータを中継する中継サーバと、データを受信して再生する再生端末と、各端末間を接続する通信回線と、を含んで構成される。
【０００３】
通信回線には一般的に帯域制限があり、一つの通信回線を複数の人や端末で共用する場合や、通信回線が無線通信である場合などは、特に帯域の制限が厳しくなる傾向にある。
【０００４】
したがって、通信回線の帯域を超えるビットレートの動画像を配信する場合に、一般的に、フレームを間引いたり、解像度を落としたりして再符号化するトランスコーディングという処理が必要となる。このトランスコーディングの処理では、フレームレートと解像度（又は、画質）は、通常、トレードオフの関係にある。また、トランスコーディング処理は、リアルタイムで処理する方法と、事前に処理したデータを用意しておく方法との２つに大別される。
【０００５】
携帯型コンテンツ再生機やそのような機能を包含する携帯電話機などの再生端末は、トランスコーディングされた動画像データを受信し、復号して再生する。
【０００６】
コンテンツの解像度を変化させるトランスコーディングに関しては、再生端末が再生できる解像度に応じで、コンテンツの解像度を変化させることを可能とする技術が提案されている（特許文献１参照）。この技術では、同一の解像度への変換のみを行っている。
【０００７】
また、同様にコンテンツを適応的にトランスコーディングして、通信回線の品質や端末の電池レベルなどに応じて、プロキシサーバを用いて、トランスコーディングを行う提案がなされている（特許文献２参照）。
【０００８】
【特許文献１】特開２００５−３４１０９３号公報、「コンテンツ適応化装置、コンテンツ適応化システム、コンテンツ適応化方法」
【特許文献２】特開２００６−７４７２８号公報、「無線端末動的プログラマブルプロキシ」
【発明の開示】
【発明が解決しようとする課題】
【０００９】
配信側のコンピュータがリアルタイムにトランスコーディングする場合に、動き優先、画質優先などと言われることがあるトランスコーディングのフレームレートと画質との関係を与える変数は、配信を開始したときの初期変数から、通信回線の帯域の状況に応じて変化することは、従来から可能であった。
【００１０】
しかしながら、動画データなどの配信中に、端末の形態を変更する場合があり、また、表示画面の向きなども変化する場合がある。
ところが、このような変化に関しては、対応できていなかった。
【００１１】
本発明は、コンテンツの配信を受ける携帯端末を含む無線回線を用いたコンテンツ配信システムのように、通信回線の帯域に制限があり、配信側のコンピュータで動画像のトランスコーディングが必要な場合に、携帯端末などの再生端末の形態や向きの変化に適応させてトランスコーディングの処理を行うことを目的とする。
【課題を解決するための手段】
【００１２】
本発明の一観点によれば、可動部を備えることにより形態が変化し、ネットワークを介してコンテンツ配信サーバからコンテンツの配信を受けることができるコンテンツ受信端末であって、前記形態を検出する形態検出部を有し、前記コンテンツ配信サーバに対するコンテンツの配信要求の際に前記形態検出部によって検出された形態に適したコンテンツの変換方法を指定する変換方法指定データを送信することを特徴とするコンテンツ受信端末が提供される。上記のサーバは、前記変換方法の指定にもとづいて、必要に応じてトランスコーディング処理を行ったコンテンツをコンテンツ受信端末に配信する。
【００１３】
前記コンテンツを受信中に前記形態検出部によって形態の変化を検出すると、前記サーバに対してコンテンツの変換方法を指定するデータを送信することが好ましい。また、前記携帯端末による前記サーバへのコンテンツの要求において、分割された符号化データを複数回にわたり配信するように要求することが好ましい。前記携帯端末による前記サーバへのコンテンツの要求において、分割されたコンテンツのうちのいずれの要素を要求するかを指定することが好ましい。
【００１４】
前記携帯端末による前記サーバへのコンテンツの要求において、動き優先パラメータセット又は画質優先パラメータセットのいずれかを指定することも可能である。前記形態検出部により直近に検出された形態を記憶する形態記憶部を有しており、該形態記憶部に記憶された形態と形態の変化の検出とに基づいて、検出後の形態を推定して記憶することを特徴とする。例えば、２通りの形態がある場合には、変化を検出すると、前の形態からそれ以外の１通りの形態に変化したことがわかる。
【００１５】
また、コンテンツ受信端末の形態が画面横向き形態に変化していると推定されると、画質を優先するパラメータセットを前記コンテンツ配信装置への配信指示データとすることを特徴とする。さらに、コンテンツ受信端末の形態が画面縦向き形態に変化していると推定されると、動きを優先するパラメータセットを前記コンテンツ配信装置への配信指示データとするようにしても良い。
【００１６】
また、ネットワークを介してコンテンツ配信サーバからコンテンツの配信を受けることができるコンテンツ受信端末であって、端末の向く方向を検出する方向検出部を有し、前記コンテンツ配信サーバに対するコンテンツの配信要求の際に前記方向検出部によって検出された向きに適したコンテンツの変換方法を指定する変換方法指定データを送信することを特徴とするコンテンツ受信端末が提供される。
【００１７】
上記に記載のコンテンツ受信端末に対してコンテンツを配信するコンテンツ配信装置であって、コンテンツを保存するコンテンツ保存部と、コンテンツを復号する復号部と、復号されたコンテンツデータを変換処理する変換制御部と、変換処理された前記コンテンツデータを符号化する符号化部と、符号化された符号化データを前記コンテンツ受信端末に送信する通信部と、を有することが好ましい。前記変換制御部は、前記変換方法指定データに基づいて変換を行うことが好ましい。前記変換制御部による復号されたデータの処理は、データ量を減らす方向の処理又はフレーム数を減らす方向である。
【００１８】
また、上記のコンテンツ配信装置は、事前に自ら復号、変換処理、符号化された符号化データをコンテンツ保存部、又は上記コンテンツ配信装置の他の記憶部に保持し、前記変換方法指定データに基づいて、前記保持した符号化データを読み出し、前記コンテンツ受信端末に対して配信しても良い。このとき、上記コンテンツ配信装置は、自ら復号、変換処理、符号化しない場合、復号部と変換制御部と符号化部を有しない構成をとっても良い。
【００１９】
前記コンテンツ保存部が、通信回線により前記コンテンツ配信装置と接続可能な別の端末装置に設けられていても良い。
【００２０】
本発明の他の観点によれば、コンテンツ受信端末の形態を検出するステップと、該形態に基づいて、コンテンツを配信するコンテンツ配信装置に対してコンテンツの変換方法を指定するデータを送信するステップと、を有することを特徴とする配信コンテンツ要求方法が提供される。前記コンテンツ配信装置からの符号化データの受信中に前記コンテンツ受信端末の形態の変化を検出すると、前記コンテンツ配信装置に対して変換方法を指定するデータを送信するステップを有することが好ましい。前記コンテンツ受信端末から送られた変換方法を指定するデータを受信し、該データの要求に基づいて復号されたデータに対して変換処理及び符号化を行うステップと、前記符号化データを前記コンテンツ受信端末へ送信するステップと、を有することが好ましい。また、前記コンテンツ受信端末から送られた変換方法を指定するデータを受信し、該データの要求に基づいて符号化データを読み出すステップと、前記符号化データを前記コンテンツ受信端末へ送信するステップと、を有することが好ましい。また、前記コンテンツ受信端末への符号化データの送信中に、前記コンテンツ受信端末から変換方法を指定するデータを受信するステップと、前記変換方法の指定に基づいて復号されたデータに対して変換処理及び符号化を行うステップと、前記符号化データを前記コンテンツ受信端末へ送信するステップと、を有していても良い。また、前記コンテンツ受信端末への符号化データの送信中に、前記コンテンツ受信端末から変換方法を指定するデータを受信するステップと、前記変換方法の指定に基づいて符号化データを読み出すステップと、前記符号化データを前記コンテンツ受信端末へ送信するステップと、を有していても良い。上記ステップをコンピュータに実行させるためのプログラムも本発明に含まれるものである。
【発明の効果】
【００２１】
本発明によれば、サーバから配信された動画や音声などのデータを受信する携帯端末において、携帯端末の形態や向きの変化に応じて受信するデータを適切に変化させることができる。従って、通信回線の帯域を効率的に利用することができる。また、コンテンツを見やすく表示させることができるという利点がある。
【発明を実施するための最良の形態】
【００２２】
以下、本発明の実施の形態によるコンテンツ送受信技術について図面を参照しながら説明を行う。図１は本発明の一実施の形態による第１の携帯端末１の外観例を示す正面図である。図２は、携帯端末１を側面から見た側面図である。図３は携帯端末１を背面から見た背面図である。図４、図５は、携帯端末１の動作例を示す正面図である。
【００２３】
本実施の形態による携帯端末１は、複数の入力ボタン１６を備える操作部を含む本体部（第１の筐体）１３と、表示画面１５が設けられた画面部（第２の筐体）１１と、を有している。画面受け部１２は、本体部１３と画面部１１とを２つの可動部を介して連結している。第１の可動部は、画面受け部１２と本体部１３とをクラムシェルのように開閉する方向への動作を可能とする。第２の可動部は、画面受け部１２と画面部１１とが平行な状態を保持したままで面内において回転移動を可能とする。
【００２４】
すなわち、画面受け部１２に対して、図４に示すように、画面部１１が回動部１８を基準として回転し（矢印ＡＲ１参照）、図５に示すように、表示画面１５が図１に示す状態から例えば９０度回転し、縦向きから横向きになるように動作させることができる。ここで、図１のような携帯端末１の形態を画面縦向き形態と称し、図５のような形態を画面横向き形態と称する。以上に説明した機構を有する携帯端末１は、既に商品として販売されておりさらに詳細な機構についての説明は省略する。
【００２５】
さらに、上記とは異なる動作をする第２の携帯端末の例について図１１〜１３までに示す。図１１は、第２の携帯端末１０１の構成例を示す斜視図である。図１１に示す携帯端末１０１は、本体部１１３と画面部１１１とが２軸（ＡＲ２およびＡＲ３）の可動部１２５をもつヒンジ１２７によって連結され、クラムシェルのように開閉する方向ＡＲ３への可動と、さらに、画面部１１１が回転する機構（ＡＲ２）をもつ。このような携帯端末１０１についても、表示画面１１５が縦向きになるような開いた形態のときを画面縦向き形態と称し、表示画面１１５が回転して折りたたんだ形態（デジカメのような形態）を画面横向き形態と称する。すなわち、図１１に示す形態が、画面縦向き形態であり、図１３に示す形態が、画面横向き形態である。つまり、携帯端末１０１の表示画面１１５の向きが縦方向に見やすい向きであれば画面縦向き形態と称し、画面の向きが横方向に見やすい向きであれば画面横向き形態と称することにする。このような機構をもつ携帯端末に関しても販売されているものであるため、その機構の詳細な説明は省略する。
【００２６】
図６は、上記のような携帯端末１・１０１の内部構成例を示す機能ブロック図である。携帯端末１・１０１は、画面縦向き形態と画面横向き形態のいずれの形態であるかを検出する形態検出部６１と、サーバなどの他の端末と通信してデータを送受信する通信部６２と、符号化された動画データや音声データを復号する復号部６３と、携帯端末１・１０１の各部を制御及び監視するＣＰＵ６４と、復号された動画データなどを表示画面１５へ表示する表示部６５と、入力ボタン１６からの入力を受ける入力部６６と、制御プログラムや固定データを格納するＲＯＭ１７と、実行中のプログラムやデータを一時的に保存するＲＡＭ１８と、を含んで構成される。ここで、形態検出部６１が、加速度センサ機能を備えているときは、重力の方向を検出して形態又は画面の向きを検出することも可能である。一般的に、形態検出部６１は電気的、又は光学的なセンサやスイッチによって携帯端末１・１０１の形態を検出する。
【００２７】
図７は携帯端末１を含むコンテンツ配信ネットワークの構成例を示す図である。図７に示すように、携帯端末１（以下、１０１を省略する）は、無線回線（通信可能であれば良いので有線でも可能である）によってネットワークＮＴにつながっている。ここで、ネットワークＮＴは、単一のネットワークでも複数のネットワークの連結であっても良い。コンテンツ配信装置（サーバ３）も、有線又は無線回線によってネットワークＮＴにつながっており、携帯端末１と相互にデータの送受信が可能である。
【００２８】
図８は、サーバ３の内部構成例を示す図である。サーバ３は、復号されたデータの処理及び符号化のパラメータを制御する変換制御部８１と、携帯端末などの他の端末と通信してデータを送受信する通信部８２と、符号化された動画や音声データを復号する復号部８３と、サーバ３の各部を制御及び監視を行うＣＰＵ８４と、動画データや音声データを送信用に符号化する符号化部８５と、動画データや音声データを保存するコンテンツ保存部８６と、制御プログラムや固定データを格納する記録部８７と、実行中のプログラムやデータを一時的に保存するＲＡＭ８８と、を含んで構成される。ここで、コンテンツ保存部８６は、記録部８７の一部とした構成をとっても良い。また、コンテンツ保存部８６は、ネットワークを介して他の端末に存在し、通信部８２を介して読み出すか、或いは、受け取るように構成することも可能である。
【００２９】
尚、携帯端末１は、直接にサーバ３と通信しても良いが、携帯端末１と、サーバ３と、の間に中継サーバを設け、この中継サーバを介して、制御データ、動画や音声データの送受信を行う構成であっても良い。また、制御データ、動画データや音声データそれぞれのネットワーク内の通信経路は、異なっていても良い。
【００３０】
図９は、本実施の形態によるコンテンツ配信に関する１つの携帯端末１がサーバ３からコンテンツを取得する際のシーケンス図である。まず、ステップＳ９１において、携帯端末１は、サーバ３に対して、動画データや音声データであるコンテンツのリストを要求する。例えば、コンテンツのリストを要求するためのＵＲＬを予め携帯端末１が知っていて、このＵＲＬに対して、ＨＴＴＰプロトコルのＧＥＴメソッドを実行する。ステップＳ９２において、サーバ３は、コンテンツ保存部８６に保存されたコンテンツのうち、要求に合ったコンテンツのリストを携帯端末１へ送信する。例えば、動画データが欲しいという要求があった場合に、サーバ３は、コンテンツ保存部８６に保存されたコンテンツのうち動画データであるコンテンツのリストを携帯端末１へ送信する。例えば、拡張子“.3gp”である動画データを探し、リスト化し送信することが可能である。
【００３１】
ステップＳ９３において、上記コンテンツのリストを受信した携帯端末１は、このコンテンツのリストの中から、受信し再生したいコンテンツを、ユーザによる入力部６６からの指令などによって選択し、サーバ３に対して、選択されたコンテンツを指示するデータを送信する。携帯端末１は、コンテンツ指示データとともに、変換パラメータセットを指示するデータをサーバ３に対して送信する。この変換パラメータセットについては、後述する。尚、変換パラメータセット指示データとコンテンツ指示データは、同じリクエストとして送っても良いし、別々のリクエストとして送っても良い。
【００３２】
ステップＳ９４において、サーバ３は、コンテンツ指示データによって指示されたコンテンツを、コンテンツ保存部８６から取り出す。そして、このコンテンツを復号部８３によって復号し、変換制御部８１は、携帯端末１とサーバ３との間の通信回線の帯域に見合ったビットレートへ、符号化部８５を使ってトランスコーディングを行った後、又は、行いながらリアルタイムに、携帯端末１に対して上記トランスコーディング後のコンテンツを送信する。
【００３３】
トランスコーディングに関する一例について説明する。例えば、指示されたコンテンツが動画データであり、解像度（サイズ）が７２０×４８０、フレームレートが３０ｆｐｓ、ビットレートが２Ｍｂｐｓの動画データであるコンテンツＡがコンテンツ保存部８６に保存されていたとする。このとき、通信回線の帯域の制限によって、上記コンテンツＡをビットレートが３８４ｋｂｐｓ程度のコンテンツとしてであれば送ることができる場合には、トランスコーディング処理が必要となる。
【００３４】
サーバ３は、復号部８３によってコンテンツＡを復号し、変換制御部８１によって解像度を減らしたり、フレームを間引いてフレームレートを落としたりした動画データを抽出する。そして、符号化部８５にパラメータを与えて符号化を行い、コンテンツＡ’を作成する。解像度を減らしたりフレームレートを落としたりするとデータ量が減るため、符号化された上記コンテンツＡ’のビットレートを下げることができる。符号化の例として、ＭＰＥＧ−４、Ｈ．２６４など公知の圧縮方式を用いることができる。符号化時の圧縮率を上げることにより、ビットレートを下げることが可能であるが、圧縮率を上げていくと、当然、画質は劣化していく。
【００３５】
ここで、フレームレートを犠牲にして各フレームの画質を優先するようにトランスコーディング処理する変換パラメータの組み合わせを画質優先パラメータセットと称し、反対に、各フレームの画質を犠牲にしてフレームレートを優先するようにトランスコーディング処理する変換パラメータの組み合わせを動き優先パラメータセットと称することにする。すなわち、画質優先パラメータセットは、フレーム数を減らす処理、例えば、３０ｆｐｓのフレームレートを１０ｆｐｓへ落とすような処理を優先して行うパラメータの組み合わせである。動き優先パラメータセットは、フレームレートをできるだけ維持し、１フレームの解像度（サイズ）を縮小することを優先して行うパラメータの組み合わせである。
【００３６】
また、上記パラメータセットに、符号化時のパラメータも含めることもできる。例えば、ＭＰＥＧ−４などの圧縮方式で使われる量子化係数（ＱＰ値）の最大値、最小値や、イントラフレームの挿入する間隔などである。一般的に、量子化係数（ＱＰ値）の最大値を制限することによって、１フレームの画質を維持することが可能であるが、その分、符号量が増えるため、フレーム数を減らすなどの処理が必要となる。また、フレームレートの違いによってイントラフレームを挿入する間隔（フレーム数）も違ってくる。尚、変換制御部８１が行うトランスコーディング処理のパラメータの組み合わせは、上述のパラメータセットに限定されるものではなく、任意にパラメータを選択することができる。
【００３７】
図９のシーケンス図では、サーバ３は、コンテンツＡ’を分割して携帯端末１に送っている。携帯端末１は、コンテンツの要求を繰り返すことによって、次々にコンテンツＡ’の一部分を受信し、最終的には、コンテンツＡ’全体を受信するに至る。例えば、携帯端末１は、ＨＴＴＰプロトコルのＧＥＴメソッドをサーバ３に対して繰り返し送ることにより、上記シーケンスを実現することができる。
【００３８】
ステップＳ９３について、詳細に説明する。ステップＳ９３において、携帯端末１の形態検出部６１よって検出された最新の形態が画面縦向き形態であった場合に、携帯端末１がサーバ３に対して送る変換パラメータセット指示データは、動き優先パラメータセット指示データとなる。表示画面１５が縦向きであると、一般的に動画データの解像度は横に長いアスペクト比をもつため、表示画面１５に表示される動画データの解像度（サイズ）は画面横向き形状のときに比べて小さくなる。例えば、表示画面の解像度が２４０×３２０であった場合、横方向のサイズを小さい方の２４０に収めなければならず、これは、表示画面が横向きであった場合の３２０より小さい。したがって、画質優先パラメータセットより、動画データの解像度の横のサイズを２４０に合わせて小さくして、その分、フレーム数を維持した動き優先パラメータセットを指示する方が、表示画面１５の向きの表示に合っている。動き優先パラメータセットを指示することで、より通信回線の帯域を効率よく使うことが可能である。動き優先パラメータセットが使われてトランスコーディングされた結果のコンテンツをコンテンツＡ（Ｍ）と呼ぶことにする。
【００３９】
変換パラメータセットを指示するデータの送信は、例えば、ＨＴＴＰプロトコルのＧＥＴ、又はＰＯＳＴメソッドを使うことで実現できる。例えば、ＨＴＴＰプロトコルのＵＲＬの後ろに次のようにパラメータを指定する。
“http://www.xxxxxxx.com/contents.3gp?i=10&c=1”
【００４０】
ここで、“i=10”は分割されたコンテンツのどの要素が欲しいかを指定している。また、“c=1”は、動き優先パラメータセットであるか、或いは、画質優先パラメータセットであるかを指定する。
【００４１】
携帯端末１が、サーバ３からコンテンツＡ（Ｍ）の要素を受信中に、携帯端末１の形態検出部６１によって、携帯端末１の形態の変化を検出したとする。例えば、直近に検出された形態を記憶する記憶部を設けておく。この記憶部に記憶されたデータによれば、以前に検出された形態が画面縦向き形態であったとすると、ここでの変化は、画面縦向き形態ではない形態への変化、つまり、画面縦向き形態から画面横向き形態への変化と推定される。もちろん、以前の形態が異なると逆の変化も起こりうる。
【００４２】
ステップＳ９５において、携帯端末１は、サーバ３に対して、コンテンツの要求とともに、変換パラメータセット指示データを送る。このときの変換パラメータセット指示データは、携帯端末１の形態が画面横向き形態に変化しているから、画質優先パラメータセット指示データとなる。画面が横向きであると、画面が縦向きであるときと比べて、横に長いアスペクト比をもつ動画データを表示するときに、表示画面１５に表示できる動画データの解像度（サイズ）は大きくなる。例えば、表示画面の解像度が２４０×３２０であった場合、画面が横向きになっているから横方向のサイズは３２０まで使うことができ、これは、表示画面が縦向きであった場合の２４０より大きい。したがって、画質優先パラメータセットを指示する方が、動画データの１フレームの画像はより細かく見える。従って、表示画面１５の向きの表示により合っている。画質優先パラメータセットを指示することで、より通信回線の帯域を効率よく使うことが可能である。画質優先パラメータセットが使われてトランスコーディング処理された結果のコンテンツをコンテンツＡ（Ｒ）と称する。
【００４３】
ステップＳ９６において、サーバ３は、携帯端末１から画質優先パラメータセット指示データを受け取り、トランスコーディングのパラメータを変化させて、コンテンツＡのトランスコーディングを行う。サーバ３は、作られたコンテンツＡ（Ｒ）を携帯端末１へ送信する。
【００４４】
図１０は、図９と異なり、サーバ３が携帯端末１へ、コンテンツを分割しないで送る場合のシーケンス図である。
【００４５】
ステップＳ１０１、ステップＳ１０２は、図９のステップＳ９１、ステップＳ９２と同じであるため説明を省略する。
【００４６】
ステップＳ１０３において、携帯端末１は、サーバ３に対して、コンテンツを指示するデータと変換パラメータセットを指示するデータとを送る。この際、携帯端末１の形態検出部６１によって検出された最新の形態が画面横向き形態であったとすると、上記符号化パラメータセット指示データは、前述の説明のように画質優先パラメータセット指示データとなる。逆に、携帯端末１の形態が、画面縦向き形態であったときは、動き優先パラメータセット指示データとなる。
【００４７】
変換パラメータセット指示データの送信は、例えば、ＲＴＳＰプロトコルのＳＥＴ＿ＰＡＲＡＭＥＴＥＲメソッドや前述したＨＴＴＰのＧＥＴメソッドによって行うことができる。ＨＴＴＰプロトコルを使う場合、ダウンロードしながら再生を開始するので、これを疑似ストリーミングと呼ぶことがある。なお、コンテンツ指示データと変換パラメータセット指示データは、別々のリクエストとして送っても良いものとする。
【００４８】
ＲＴＳＰプロトコルによってセッションをはり、ＲＴＰ／ＲＴＣＰプロトコルを使う場合、一般的に、コンテンツデータはＲＴＰパケットによって送られる。ＲＴＣＰパケットはＲＴＰパケットの送受信中に、送信者と受信者間で通信品質などの情報をやりとりするプロトコルである。ＲＴＣＰプロトコルのＲＲ（Ｒｅｃｅｉｖｅｒ Ｒｅｐｏｒｔ）パケットはＲＴＰパケットの受信者から送信者に送られるパケットであり、拡張領域ｐｒｏｆｉｌｅ−ｓｐｅｃｉｆｉｃ ｅｘｔｅｎｓｉｏｎｓをもつことができる。この拡張領域に、変換パラメータセット指示データを入れることも可能である。
【００４９】
ステップＳ１０４において、サーバ３は、要求された上記コンテンツ、すなわちコンテンツＢ（Ｍ）を、コンテンツ保存部８６から取り出す。そして、変換制御部８１は、指示された変換パラメータセットを用いて、復号部８３、符号化部８５を用い、トランスコーディング処理を行う。今回の変換パラメータセットは画質優先パラメータセットであるから、動画データの１フレームの解像度を優先したパラメータの組み合わせを用いてトランスコーディング処理を行う。例えば、フレームレートを下げ、ＭＰＥＧ−４などの圧縮方式で使われるＱＰ値があまり大きくならないように制御を行う。サーバ３は、トランスコーディングされたコンテンツ、コンテンツＢ（Ｒ）を携帯端末１へ送信する。
【００５０】
携帯端末１がサーバ３からコンテンツＢ（Ｒ）を受信中に、携帯端末１の形態検出部６１によって、携帯端末１の形態の変化が検出されたとする。以前に検出された形態が画面横向き形状であったので、ここでの変化は、画面横向き形状ではない形状への変形態、つまり、画面横向き形態から画面縦向き形態への変化となる。もちろん、以前の形態が異なると逆の変化も起こりうる。
【００５１】
ステップＳ１０５において、携帯端末１は、サーバ３に対して、符号化パラメータセットを指示するデータを送る。このときの符号化パラメータセット指示データは、携帯端末１の形態が画面縦向き形態に変化しているから、動き優先パラメータセット指示データとなる。例えば、前述したＲＴＣＰプロトコルのＲＲパケットタイプの拡張領域によって実現することが可能である。
【００５２】
上記コンテンツＡ（Ｍ）とコンテンツＡ（Ｒ）、又はコンテンツＢ（Ｍ）とコンテンツＢ（Ｒ）は、リアルタイムにトランスコーディングを行ったが、事前にサーバ３、又はトランスコーディング用の装置が、上記コンテンツＡ、又はコンテンツＢを動き優先パラメータセット、及び、画質優先パラメータセットを用いてトランスコーディングし、コンテンツ保存部８６、又は他の記憶部に保存しておき、携帯端末１から変換パラメーターセット指示データを受け取ると、事前にトランスコーディングされたコンテンツを読み出して送る構成とすることも可能である。この際、コンテンツ配信中のサーバ３の負荷はトランスコーディング処理が削減されるため軽くなるという利点がある。
【００５３】
もし、サーバ３が事前に他の装置でトランスコーディングされたコンテンツを保持しており、リアルタイムにトランスコーディングを行わない場合には、図８の構成図から、変換制御部８１、復号部８３、符号化部８５を省略することも可能である。
【００５４】
上記の技術において、端末の形態・向きに応じて、適切な処理を行うことについて説明したが、端末の形態と向きとの両方を検出して、それに応じた処理を行うようにしてもよい。
【００５５】
尚、以上の実施例において、再生初期時の形態によって変換パラメータセットを指示した後、コンテンツの受信中に携帯端末１の形態に変化があっても変換パラメータセット指示データを送信せず、再生を続けることも可能である。
【００５６】
また、以上の実施例のステップは基本的なステップのみを挙げたものであって、他のデータの送受信など、任意にステップを追加しても良く、携帯端末１とサーバ３とのシーケンスが破綻しない範囲で順番の変更が行われても良い。プロトコルは他のプロトコルによっても実現可能であり、例としてとりあげたものに限定しない。
【００５７】
以上、本発明の例を説明したが、本発明は上述の例に限定されるものではなく、特許請求の範囲に記載された発明の範囲にて様々な変更が可能であることは当業者に理解されよう。
【産業上の利用可能性】
【００５８】
本発明は、コンテンツ送受信技術に利用可能である。
【図面の簡単な説明】
【００５９】
【図１】本発明の一実施の形態に係る携帯端末であって、その形態が表示画面縦向きとなっている場合の外観図である。
【図２】本発明の一実施の形態に係る携帯端末であって、形態が表示画面縦向きとなっている場合の側面から見た外観図である。
【図３】本発明の一実施の形態に係る携帯端末で形態が表示画面縦向きとなっている場合の背面から見た外観図である。
【図４】本発明の一実施の形態に係る携帯端末で表示画面を回転させている途中段階を示した外観図である。
【図５】本発明の一実施の形態に係る携帯端末であって、その形態が表示画面横向きとなっている場合の外観図である。
【図６】本発明の一実施の形態に係る携帯端末の内部構成例を示す機能ブロック図である。
【図７】本発明の一実施の形態に係る携帯端末とサーバを含んだネットワークシステムの構成例を示す図である。
【図８】本発明の一実施の形態に係るサーバの内部構成例を示す図である。
【図９】本発明の一実施の形態に係る携帯端末とサーバとのデータ送受信のシーケンスを示した図である。
【図１０】本発明の一実施の形態に係る携帯端末とサーバのデータ送受信のシーケンスを示した図である。
【図１１】本発明の一実施の形態に係る携帯端末で形態が表示画面縦向きとなっている場合の外観図である。
【図１２】本発明の実施の形態に係る携帯端末で表示画面が背面を向いた形態で表示画面縦向きとなっている場合の外観図である。
【図１３】本発明の実施の形態に係る携帯端末で筐体を重ねて折りたたんだ形態を示す外観図である。
【符号の説明】
【００６０】
１…携帯端末、１１…画面部、１２…画面受け部、１３…本体部、１５…表示画面、１６…入力ボタン、３…コンテンツ配信装置（サーバ）
【技術分野】
【０００１】
本発明は、コンテンツ送受信技術に関し、特に、動画像や音声データを受信し再生する携帯端末、及び、動画像や音声データを携帯端末に向けて配信する配信端末、及びそれらを含むシステムに関する。
【背景技術】
【０００２】
近年、ドラマやニュースなどの動画像や音声データを配信する配信サービスが普及しつつある。このような配信サービスに用いられるシステムは、データ配信用のサーバと、必要であればデータを中継する中継サーバと、データを受信して再生する再生端末と、各端末間を接続する通信回線と、を含んで構成される。
【０００３】
通信回線には一般的に帯域制限があり、一つの通信回線を複数の人や端末で共用する場合や、通信回線が無線通信である場合などは、特に帯域の制限が厳しくなる傾向にある。
【０００４】
したがって、通信回線の帯域を超えるビットレートの動画像を配信する場合に、一般的に、フレームを間引いたり、解像度を落としたりして再符号化するトランスコーディングという処理が必要となる。このトランスコーディングの処理では、フレームレートと解像度（又は、画質）は、通常、トレードオフの関係にある。また、トランスコーディング処理は、リアルタイムで処理する方法と、事前に処理したデータを用意しておく方法との２つに大別される。
【０００５】
携帯型コンテンツ再生機やそのような機能を包含する携帯電話機などの再生端末は、トランスコーディングされた動画像データを受信し、復号して再生する。
【０００６】
コンテンツの解像度を変化させるトランスコーディングに関しては、再生端末が再生できる解像度に応じで、コンテンツの解像度を変化させることを可能とする技術が提案されている（特許文献１参照）。この技術では、同一の解像度への変換のみを行っている。
【０００７】
また、同様にコンテンツを適応的にトランスコーディングして、通信回線の品質や端末の電池レベルなどに応じて、プロキシサーバを用いて、トランスコーディングを行う提案がなされている（特許文献２参照）。
【０００８】
【特許文献１】特開２００５−３４１０９３号公報、「コンテンツ適応化装置、コンテンツ適応化システム、コンテンツ適応化方法」
【特許文献２】特開２００６−７４７２８号公報、「無線端末動的プログラマブルプロキシ」
【発明の開示】
【発明が解決しようとする課題】
【０００９】
配信側のコンピュータがリアルタイムにトランスコーディングする場合に、動き優先、画質優先などと言われることがあるトランスコーディングのフレームレートと画質との関係を与える変数は、配信を開始したときの初期変数から、通信回線の帯域の状況に応じて変化することは、従来から可能であった。
【００１０】
しかしながら、動画データなどの配信中に、端末の形態を変更する場合があり、また、表示画面の向きなども変化する場合がある。
ところが、このような変化に関しては、対応できていなかった。
【００１１】
本発明は、コンテンツの配信を受ける携帯端末を含む無線回線を用いたコンテンツ配信システムのように、通信回線の帯域に制限があり、配信側のコンピュータで動画像のトランスコーディングが必要な場合に、携帯端末などの再生端末の形態や向きの変化に適応させてトランスコーディングの処理を行うことを目的とする。
【課題を解決するための手段】
【００１２】
本発明の一観点によれば、可動部を備えることにより形態が変化し、ネットワークを介してコンテンツ配信サーバからコンテンツの配信を受けることができるコンテンツ受信端末であって、前記形態を検出する形態検出部を有し、前記コンテンツ配信サーバに対するコンテンツの配信要求の際に前記形態検出部によって検出された形態に適したコンテンツの変換方法を指定する変換方法指定データを送信することを特徴とするコンテンツ受信端末が提供される。上記のサーバは、前記変換方法の指定にもとづいて、必要に応じてトランスコーディング処理を行ったコンテンツをコンテンツ受信端末に配信する。
【００１３】
前記コンテンツを受信中に前記形態検出部によって形態の変化を検出すると、前記サーバに対してコンテンツの変換方法を指定するデータを送信することが好ましい。また、前記携帯端末による前記サーバへのコンテンツの要求において、分割された符号化データを複数回にわたり配信するように要求することが好ましい。前記携帯端末による前記サーバへのコンテンツの要求において、分割されたコンテンツのうちのいずれの要素を要求するかを指定することが好ましい。
【００１４】
前記携帯端末による前記サーバへのコンテンツの要求において、動き優先パラメータセット又は画質優先パラメータセットのいずれかを指定することも可能である。前記形態検出部により直近に検出された形態を記憶する形態記憶部を有しており、該形態記憶部に記憶された形態と形態の変化の検出とに基づいて、検出後の形態を推定して記憶することを特徴とする。例えば、２通りの形態がある場合には、変化を検出すると、前の形態からそれ以外の１通りの形態に変化したことがわかる。
【００１５】
また、コンテンツ受信端末の形態が画面横向き形態に変化していると推定されると、画質を優先するパラメータセットを前記コンテンツ配信装置への配信指示データとすることを特徴とする。さらに、コンテンツ受信端末の形態が画面縦向き形態に変化していると推定されると、動きを優先するパラメータセットを前記コンテンツ配信装置への配信指示データとするようにしても良い。
【００１６】
また、ネットワークを介してコンテンツ配信サーバからコンテンツの配信を受けることができるコンテンツ受信端末であって、端末の向く方向を検出する方向検出部を有し、前記コンテンツ配信サーバに対するコンテンツの配信要求の際に前記方向検出部によって検出された向きに適したコンテンツの変換方法を指定する変換方法指定データを送信することを特徴とするコンテンツ受信端末が提供される。
【００１７】
上記に記載のコンテンツ受信端末に対してコンテンツを配信するコンテンツ配信装置であって、コンテンツを保存するコンテンツ保存部と、コンテンツを復号する復号部と、復号されたコンテンツデータを変換処理する変換制御部と、変換処理された前記コンテンツデータを符号化する符号化部と、符号化された符号化データを前記コンテンツ受信端末に送信する通信部と、を有することが好ましい。前記変換制御部は、前記変換方法指定データに基づいて変換を行うことが好ましい。前記変換制御部による復号されたデータの処理は、データ量を減らす方向の処理又はフレーム数を減らす方向である。
【００１８】
また、上記のコンテンツ配信装置は、事前に自ら復号、変換処理、符号化された符号化データをコンテンツ保存部、又は上記コンテンツ配信装置の他の記憶部に保持し、前記変換方法指定データに基づいて、前記保持した符号化データを読み出し、前記コンテンツ受信端末に対して配信しても良い。このとき、上記コンテンツ配信装置は、自ら復号、変換処理、符号化しない場合、復号部と変換制御部と符号化部を有しない構成をとっても良い。
【００１９】
前記コンテンツ保存部が、通信回線により前記コンテンツ配信装置と接続可能な別の端末装置に設けられていても良い。
【００２０】
本発明の他の観点によれば、コンテンツ受信端末の形態を検出するステップと、該形態に基づいて、コンテンツを配信するコンテンツ配信装置に対してコンテンツの変換方法を指定するデータを送信するステップと、を有することを特徴とする配信コンテンツ要求方法が提供される。前記コンテンツ配信装置からの符号化データの受信中に前記コンテンツ受信端末の形態の変化を検出すると、前記コンテンツ配信装置に対して変換方法を指定するデータを送信するステップを有することが好ましい。前記コンテンツ受信端末から送られた変換方法を指定するデータを受信し、該データの要求に基づいて復号されたデータに対して変換処理及び符号化を行うステップと、前記符号化データを前記コンテンツ受信端末へ送信するステップと、を有することが好ましい。また、前記コンテンツ受信端末から送られた変換方法を指定するデータを受信し、該データの要求に基づいて符号化データを読み出すステップと、前記符号化データを前記コンテンツ受信端末へ送信するステップと、を有することが好ましい。また、前記コンテンツ受信端末への符号化データの送信中に、前記コンテンツ受信端末から変換方法を指定するデータを受信するステップと、前記変換方法の指定に基づいて復号されたデータに対して変換処理及び符号化を行うステップと、前記符号化データを前記コンテンツ受信端末へ送信するステップと、を有していても良い。また、前記コンテンツ受信端末への符号化データの送信中に、前記コンテンツ受信端末から変換方法を指定するデータを受信するステップと、前記変換方法の指定に基づいて符号化データを読み出すステップと、前記符号化データを前記コンテンツ受信端末へ送信するステップと、を有していても良い。上記ステップをコンピュータに実行させるためのプログラムも本発明に含まれるものである。
【発明の効果】
【００２１】
本発明によれば、サーバから配信された動画や音声などのデータを受信する携帯端末において、携帯端末の形態や向きの変化に応じて受信するデータを適切に変化させることができる。従って、通信回線の帯域を効率的に利用することができる。また、コンテンツを見やすく表示させることができるという利点がある。
【発明を実施するための最良の形態】
【００２２】
以下、本発明の実施の形態によるコンテンツ送受信技術について図面を参照しながら説明を行う。図１は本発明の一実施の形態による第１の携帯端末１の外観例を示す正面図である。図２は、携帯端末１を側面から見た側面図である。図３は携帯端末１を背面から見た背面図である。図４、図５は、携帯端末１の動作例を示す正面図である。
【００２３】
本実施の形態による携帯端末１は、複数の入力ボタン１６を備える操作部を含む本体部（第１の筐体）１３と、表示画面１５が設けられた画面部（第２の筐体）１１と、を有している。画面受け部１２は、本体部１３と画面部１１とを２つの可動部を介して連結している。第１の可動部は、画面受け部１２と本体部１３とをクラムシェルのように開閉する方向への動作を可能とする。第２の可動部は、画面受け部１２と画面部１１とが平行な状態を保持したままで面内において回転移動を可能とする。
【００２４】
すなわち、画面受け部１２に対して、図４に示すように、画面部１１が回動部１８を基準として回転し（矢印ＡＲ１参照）、図５に示すように、表示画面１５が図１に示す状態から例えば９０度回転し、縦向きから横向きになるように動作させることができる。ここで、図１のような携帯端末１の形態を画面縦向き形態と称し、図５のような形態を画面横向き形態と称する。以上に説明した機構を有する携帯端末１は、既に商品として販売されておりさらに詳細な機構についての説明は省略する。
【００２５】
さらに、上記とは異なる動作をする第２の携帯端末の例について図１１〜１３までに示す。図１１は、第２の携帯端末１０１の構成例を示す斜視図である。図１１に示す携帯端末１０１は、本体部１１３と画面部１１１とが２軸（ＡＲ２およびＡＲ３）の可動部１２５をもつヒンジ１２７によって連結され、クラムシェルのように開閉する方向ＡＲ３への可動と、さらに、画面部１１１が回転する機構（ＡＲ２）をもつ。このような携帯端末１０１についても、表示画面１１５が縦向きになるような開いた形態のときを画面縦向き形態と称し、表示画面１１５が回転して折りたたんだ形態（デジカメのような形態）を画面横向き形態と称する。すなわち、図１１に示す形態が、画面縦向き形態であり、図１３に示す形態が、画面横向き形態である。つまり、携帯端末１０１の表示画面１１５の向きが縦方向に見やすい向きであれば画面縦向き形態と称し、画面の向きが横方向に見やすい向きであれば画面横向き形態と称することにする。このような機構をもつ携帯端末に関しても販売されているものであるため、その機構の詳細な説明は省略する。
【００２６】
図６は、上記のような携帯端末１・１０１の内部構成例を示す機能ブロック図である。携帯端末１・１０１は、画面縦向き形態と画面横向き形態のいずれの形態であるかを検出する形態検出部６１と、サーバなどの他の端末と通信してデータを送受信する通信部６２と、符号化された動画データや音声データを復号する復号部６３と、携帯端末１・１０１の各部を制御及び監視するＣＰＵ６４と、復号された動画データなどを表示画面１５へ表示する表示部６５と、入力ボタン１６からの入力を受ける入力部６６と、制御プログラムや固定データを格納するＲＯＭ１７と、実行中のプログラムやデータを一時的に保存するＲＡＭ１８と、を含んで構成される。ここで、形態検出部６１が、加速度センサ機能を備えているときは、重力の方向を検出して形態又は画面の向きを検出することも可能である。一般的に、形態検出部６１は電気的、又は光学的なセンサやスイッチによって携帯端末１・１０１の形態を検出する。
【００２７】
図７は携帯端末１を含むコンテンツ配信ネットワークの構成例を示す図である。図７に示すように、携帯端末１（以下、１０１を省略する）は、無線回線（通信可能であれば良いので有線でも可能である）によってネットワークＮＴにつながっている。ここで、ネットワークＮＴは、単一のネットワークでも複数のネットワークの連結であっても良い。コンテンツ配信装置（サーバ３）も、有線又は無線回線によってネットワークＮＴにつながっており、携帯端末１と相互にデータの送受信が可能である。
【００２８】
図８は、サーバ３の内部構成例を示す図である。サーバ３は、復号されたデータの処理及び符号化のパラメータを制御する変換制御部８１と、携帯端末などの他の端末と通信してデータを送受信する通信部８２と、符号化された動画や音声データを復号する復号部８３と、サーバ３の各部を制御及び監視を行うＣＰＵ８４と、動画データや音声データを送信用に符号化する符号化部８５と、動画データや音声データを保存するコンテンツ保存部８６と、制御プログラムや固定データを格納する記録部８７と、実行中のプログラムやデータを一時的に保存するＲＡＭ８８と、を含んで構成される。ここで、コンテンツ保存部８６は、記録部８７の一部とした構成をとっても良い。また、コンテンツ保存部８６は、ネットワークを介して他の端末に存在し、通信部８２を介して読み出すか、或いは、受け取るように構成することも可能である。
【００２９】
尚、携帯端末１は、直接にサーバ３と通信しても良いが、携帯端末１と、サーバ３と、の間に中継サーバを設け、この中継サーバを介して、制御データ、動画や音声データの送受信を行う構成であっても良い。また、制御データ、動画データや音声データそれぞれのネットワーク内の通信経路は、異なっていても良い。
【００３０】
図９は、本実施の形態によるコンテンツ配信に関する１つの携帯端末１がサーバ３からコンテンツを取得する際のシーケンス図である。まず、ステップＳ９１において、携帯端末１は、サーバ３に対して、動画データや音声データであるコンテンツのリストを要求する。例えば、コンテンツのリストを要求するためのＵＲＬを予め携帯端末１が知っていて、このＵＲＬに対して、ＨＴＴＰプロトコルのＧＥＴメソッドを実行する。ステップＳ９２において、サーバ３は、コンテンツ保存部８６に保存されたコンテンツのうち、要求に合ったコンテンツのリストを携帯端末１へ送信する。例えば、動画データが欲しいという要求があった場合に、サーバ３は、コンテンツ保存部８６に保存されたコンテンツのうち動画データであるコンテンツのリストを携帯端末１へ送信する。例えば、拡張子“.3gp”である動画データを探し、リスト化し送信することが可能である。
【００３１】
ステップＳ９３において、上記コンテンツのリストを受信した携帯端末１は、このコンテンツのリストの中から、受信し再生したいコンテンツを、ユーザによる入力部６６からの指令などによって選択し、サーバ３に対して、選択されたコンテンツを指示するデータを送信する。携帯端末１は、コンテンツ指示データとともに、変換パラメータセットを指示するデータをサーバ３に対して送信する。この変換パラメータセットについては、後述する。尚、変換パラメータセット指示データとコンテンツ指示データは、同じリクエストとして送っても良いし、別々のリクエストとして送っても良い。
【００３２】
ステップＳ９４において、サーバ３は、コンテンツ指示データによって指示されたコンテンツを、コンテンツ保存部８６から取り出す。そして、このコンテンツを復号部８３によって復号し、変換制御部８１は、携帯端末１とサーバ３との間の通信回線の帯域に見合ったビットレートへ、符号化部８５を使ってトランスコーディングを行った後、又は、行いながらリアルタイムに、携帯端末１に対して上記トランスコーディング後のコンテンツを送信する。
【００３３】
トランスコーディングに関する一例について説明する。例えば、指示されたコンテンツが動画データであり、解像度（サイズ）が７２０×４８０、フレームレートが３０ｆｐｓ、ビットレートが２Ｍｂｐｓの動画データであるコンテンツＡがコンテンツ保存部８６に保存されていたとする。このとき、通信回線の帯域の制限によって、上記コンテンツＡをビットレートが３８４ｋｂｐｓ程度のコンテンツとしてであれば送ることができる場合には、トランスコーディング処理が必要となる。
【００３４】
サーバ３は、復号部８３によってコンテンツＡを復号し、変換制御部８１によって解像度を減らしたり、フレームを間引いてフレームレートを落としたりした動画データを抽出する。そして、符号化部８５にパラメータを与えて符号化を行い、コンテンツＡ’を作成する。解像度を減らしたりフレームレートを落としたりするとデータ量が減るため、符号化された上記コンテンツＡ’のビットレートを下げることができる。符号化の例として、ＭＰＥＧ−４、Ｈ．２６４など公知の圧縮方式を用いることができる。符号化時の圧縮率を上げることにより、ビットレートを下げることが可能であるが、圧縮率を上げていくと、当然、画質は劣化していく。
【００３５】
ここで、フレームレートを犠牲にして各フレームの画質を優先するようにトランスコーディング処理する変換パラメータの組み合わせを画質優先パラメータセットと称し、反対に、各フレームの画質を犠牲にしてフレームレートを優先するようにトランスコーディング処理する変換パラメータの組み合わせを動き優先パラメータセットと称することにする。すなわち、画質優先パラメータセットは、フレーム数を減らす処理、例えば、３０ｆｐｓのフレームレートを１０ｆｐｓへ落とすような処理を優先して行うパラメータの組み合わせである。動き優先パラメータセットは、フレームレートをできるだけ維持し、１フレームの解像度（サイズ）を縮小することを優先して行うパラメータの組み合わせである。
【００３６】
また、上記パラメータセットに、符号化時のパラメータも含めることもできる。例えば、ＭＰＥＧ−４などの圧縮方式で使われる量子化係数（ＱＰ値）の最大値、最小値や、イントラフレームの挿入する間隔などである。一般的に、量子化係数（ＱＰ値）の最大値を制限することによって、１フレームの画質を維持することが可能であるが、その分、符号量が増えるため、フレーム数を減らすなどの処理が必要となる。また、フレームレートの違いによってイントラフレームを挿入する間隔（フレーム数）も違ってくる。尚、変換制御部８１が行うトランスコーディング処理のパラメータの組み合わせは、上述のパラメータセットに限定されるものではなく、任意にパラメータを選択することができる。
【００３７】
図９のシーケンス図では、サーバ３は、コンテンツＡ’を分割して携帯端末１に送っている。携帯端末１は、コンテンツの要求を繰り返すことによって、次々にコンテンツＡ’の一部分を受信し、最終的には、コンテンツＡ’全体を受信するに至る。例えば、携帯端末１は、ＨＴＴＰプロトコルのＧＥＴメソッドをサーバ３に対して繰り返し送ることにより、上記シーケンスを実現することができる。
【００３８】
ステップＳ９３について、詳細に説明する。ステップＳ９３において、携帯端末１の形態検出部６１よって検出された最新の形態が画面縦向き形態であった場合に、携帯端末１がサーバ３に対して送る変換パラメータセット指示データは、動き優先パラメータセット指示データとなる。表示画面１５が縦向きであると、一般的に動画データの解像度は横に長いアスペクト比をもつため、表示画面１５に表示される動画データの解像度（サイズ）は画面横向き形状のときに比べて小さくなる。例えば、表示画面の解像度が２４０×３２０であった場合、横方向のサイズを小さい方の２４０に収めなければならず、これは、表示画面が横向きであった場合の３２０より小さい。したがって、画質優先パラメータセットより、動画データの解像度の横のサイズを２４０に合わせて小さくして、その分、フレーム数を維持した動き優先パラメータセットを指示する方が、表示画面１５の向きの表示に合っている。動き優先パラメータセットを指示することで、より通信回線の帯域を効率よく使うことが可能である。動き優先パラメータセットが使われてトランスコーディングされた結果のコンテンツをコンテンツＡ（Ｍ）と呼ぶことにする。
【００３９】
変換パラメータセットを指示するデータの送信は、例えば、ＨＴＴＰプロトコルのＧＥＴ、又はＰＯＳＴメソッドを使うことで実現できる。例えば、ＨＴＴＰプロトコルのＵＲＬの後ろに次のようにパラメータを指定する。
“http://www.xxxxxxx.com/contents.3gp?i=10&c=1”
【００４０】
ここで、“i=10”は分割されたコンテンツのどの要素が欲しいかを指定している。また、“c=1”は、動き優先パラメータセットであるか、或いは、画質優先パラメータセットであるかを指定する。
【００４１】
携帯端末１が、サーバ３からコンテンツＡ（Ｍ）の要素を受信中に、携帯端末１の形態検出部６１によって、携帯端末１の形態の変化を検出したとする。例えば、直近に検出された形態を記憶する記憶部を設けておく。この記憶部に記憶されたデータによれば、以前に検出された形態が画面縦向き形態であったとすると、ここでの変化は、画面縦向き形態ではない形態への変化、つまり、画面縦向き形態から画面横向き形態への変化と推定される。もちろん、以前の形態が異なると逆の変化も起こりうる。
【００４２】
ステップＳ９５において、携帯端末１は、サーバ３に対して、コンテンツの要求とともに、変換パラメータセット指示データを送る。このときの変換パラメータセット指示データは、携帯端末１の形態が画面横向き形態に変化しているから、画質優先パラメータセット指示データとなる。画面が横向きであると、画面が縦向きであるときと比べて、横に長いアスペクト比をもつ動画データを表示するときに、表示画面１５に表示できる動画データの解像度（サイズ）は大きくなる。例えば、表示画面の解像度が２４０×３２０であった場合、画面が横向きになっているから横方向のサイズは３２０まで使うことができ、これは、表示画面が縦向きであった場合の２４０より大きい。したがって、画質優先パラメータセットを指示する方が、動画データの１フレームの画像はより細かく見える。従って、表示画面１５の向きの表示により合っている。画質優先パラメータセットを指示することで、より通信回線の帯域を効率よく使うことが可能である。画質優先パラメータセットが使われてトランスコーディング処理された結果のコンテンツをコンテンツＡ（Ｒ）と称する。
【００４３】
ステップＳ９６において、サーバ３は、携帯端末１から画質優先パラメータセット指示データを受け取り、トランスコーディングのパラメータを変化させて、コンテンツＡのトランスコーディングを行う。サーバ３は、作られたコンテンツＡ（Ｒ）を携帯端末１へ送信する。
【００４４】
図１０は、図９と異なり、サーバ３が携帯端末１へ、コンテンツを分割しないで送る場合のシーケンス図である。
【００４５】
ステップＳ１０１、ステップＳ１０２は、図９のステップＳ９１、ステップＳ９２と同じであるため説明を省略する。
【００４６】
ステップＳ１０３において、携帯端末１は、サーバ３に対して、コンテンツを指示するデータと変換パラメータセットを指示するデータとを送る。この際、携帯端末１の形態検出部６１によって検出された最新の形態が画面横向き形態であったとすると、上記符号化パラメータセット指示データは、前述の説明のように画質優先パラメータセット指示データとなる。逆に、携帯端末１の形態が、画面縦向き形態であったときは、動き優先パラメータセット指示データとなる。
【００４７】
変換パラメータセット指示データの送信は、例えば、ＲＴＳＰプロトコルのＳＥＴ＿ＰＡＲＡＭＥＴＥＲメソッドや前述したＨＴＴＰのＧＥＴメソッドによって行うことができる。ＨＴＴＰプロトコルを使う場合、ダウンロードしながら再生を開始するので、これを疑似ストリーミングと呼ぶことがある。なお、コンテンツ指示データと変換パラメータセット指示データは、別々のリクエストとして送っても良いものとする。
【００４８】
ＲＴＳＰプロトコルによってセッションをはり、ＲＴＰ／ＲＴＣＰプロトコルを使う場合、一般的に、コンテンツデータはＲＴＰパケットによって送られる。ＲＴＣＰパケットはＲＴＰパケットの送受信中に、送信者と受信者間で通信品質などの情報をやりとりするプロトコルである。ＲＴＣＰプロトコルのＲＲ（Ｒｅｃｅｉｖｅｒ Ｒｅｐｏｒｔ）パケットはＲＴＰパケットの受信者から送信者に送られるパケットであり、拡張領域ｐｒｏｆｉｌｅ−ｓｐｅｃｉｆｉｃ ｅｘｔｅｎｓｉｏｎｓをもつことができる。この拡張領域に、変換パラメータセット指示データを入れることも可能である。
【００４９】
ステップＳ１０４において、サーバ３は、要求された上記コンテンツ、すなわちコンテンツＢ（Ｍ）を、コンテンツ保存部８６から取り出す。そして、変換制御部８１は、指示された変換パラメータセットを用いて、復号部８３、符号化部８５を用い、トランスコーディング処理を行う。今回の変換パラメータセットは画質優先パラメータセットであるから、動画データの１フレームの解像度を優先したパラメータの組み合わせを用いてトランスコーディング処理を行う。例えば、フレームレートを下げ、ＭＰＥＧ−４などの圧縮方式で使われるＱＰ値があまり大きくならないように制御を行う。サーバ３は、トランスコーディングされたコンテンツ、コンテンツＢ（Ｒ）を携帯端末１へ送信する。
【００５０】
携帯端末１がサーバ３からコンテンツＢ（Ｒ）を受信中に、携帯端末１の形態検出部６１によって、携帯端末１の形態の変化が検出されたとする。以前に検出された形態が画面横向き形状であったので、ここでの変化は、画面横向き形状ではない形状への変形態、つまり、画面横向き形態から画面縦向き形態への変化となる。もちろん、以前の形態が異なると逆の変化も起こりうる。
【００５１】
ステップＳ１０５において、携帯端末１は、サーバ３に対して、符号化パラメータセットを指示するデータを送る。このときの符号化パラメータセット指示データは、携帯端末１の形態が画面縦向き形態に変化しているから、動き優先パラメータセット指示データとなる。例えば、前述したＲＴＣＰプロトコルのＲＲパケットタイプの拡張領域によって実現することが可能である。
【００５２】
上記コンテンツＡ（Ｍ）とコンテンツＡ（Ｒ）、又はコンテンツＢ（Ｍ）とコンテンツＢ（Ｒ）は、リアルタイムにトランスコーディングを行ったが、事前にサーバ３、又はトランスコーディング用の装置が、上記コンテンツＡ、又はコンテンツＢを動き優先パラメータセット、及び、画質優先パラメータセットを用いてトランスコーディングし、コンテンツ保存部８６、又は他の記憶部に保存しておき、携帯端末１から変換パラメーターセット指示データを受け取ると、事前にトランスコーディングされたコンテンツを読み出して送る構成とすることも可能である。この際、コンテンツ配信中のサーバ３の負荷はトランスコーディング処理が削減されるため軽くなるという利点がある。
【００５３】
もし、サーバ３が事前に他の装置でトランスコーディングされたコンテンツを保持しており、リアルタイムにトランスコーディングを行わない場合には、図８の構成図から、変換制御部８１、復号部８３、符号化部８５を省略することも可能である。
【００５４】
上記の技術において、端末の形態・向きに応じて、適切な処理を行うことについて説明したが、端末の形態と向きとの両方を検出して、それに応じた処理を行うようにしてもよい。
【００５５】
尚、以上の実施例において、再生初期時の形態によって変換パラメータセットを指示した後、コンテンツの受信中に携帯端末１の形態に変化があっても変換パラメータセット指示データを送信せず、再生を続けることも可能である。
【００５６】
また、以上の実施例のステップは基本的なステップのみを挙げたものであって、他のデータの送受信など、任意にステップを追加しても良く、携帯端末１とサーバ３とのシーケンスが破綻しない範囲で順番の変更が行われても良い。プロトコルは他のプロトコルによっても実現可能であり、例としてとりあげたものに限定しない。
【００５７】
以上、本発明の例を説明したが、本発明は上述の例に限定されるものではなく、特許請求の範囲に記載された発明の範囲にて様々な変更が可能であることは当業者に理解されよう。
【産業上の利用可能性】
【００５８】
本発明は、コンテンツ送受信技術に利用可能である。
【図面の簡単な説明】
【００５９】
【図１】本発明の一実施の形態に係る携帯端末であって、その形態が表示画面縦向きとなっている場合の外観図である。
【図２】本発明の一実施の形態に係る携帯端末であって、形態が表示画面縦向きとなっている場合の側面から見た外観図である。
【図３】本発明の一実施の形態に係る携帯端末で形態が表示画面縦向きとなっている場合の背面から見た外観図である。
【図４】本発明の一実施の形態に係る携帯端末で表示画面を回転させている途中段階を示した外観図である。
【図５】本発明の一実施の形態に係る携帯端末であって、その形態が表示画面横向きとなっている場合の外観図である。
【図６】本発明の一実施の形態に係る携帯端末の内部構成例を示す機能ブロック図である。
【図７】本発明の一実施の形態に係る携帯端末とサーバを含んだネットワークシステムの構成例を示す図である。
【図８】本発明の一実施の形態に係るサーバの内部構成例を示す図である。
【図９】本発明の一実施の形態に係る携帯端末とサーバとのデータ送受信のシーケンスを示した図である。
【図１０】本発明の一実施の形態に係る携帯端末とサーバのデータ送受信のシーケンスを示した図である。
【図１１】本発明の一実施の形態に係る携帯端末で形態が表示画面縦向きとなっている場合の外観図である。
【図１２】本発明の実施の形態に係る携帯端末で表示画面が背面を向いた形態で表示画面縦向きとなっている場合の外観図である。
【図１３】本発明の実施の形態に係る携帯端末で筐体を重ねて折りたたんだ形態を示す外観図である。
【符号の説明】
【００６０】
１…携帯端末、１１…画面部、１２…画面受け部、１３…本体部、１５…表示画面、１６…入力ボタン、３…コンテンツ配信装置（サーバ）
【特許請求の範囲】
【請求項１】
可動部を備えることにより形態が変化し、ネットワークを介してコンテンツ配信装置からコンテンツの配信を受けることができるコンテンツ受信端末であって、
前記形態を検出する形態検出部を有し、
前記コンテンツ配信サーバに対するコンテンツの配信要求の際に前記形態検出部によって検出された形態に適したコンテンツの変換方法を指定する変換方法指定データを送信することを特徴とするコンテンツ受信端末。
【請求項２】
前記コンテンツを受信中に前記形態検出部によって形態の変化を検出すると、前記サーバに対してコンテンツの変換方法を指定するデータを送信することを特徴とする請求項１に記載のコンテンツ受信端末。
【請求項３】
前記携帯端末による前記サーバへのコンテンツの要求において、分割された符号化データを複数回にわたり配信するように要求することを特徴とする請求項１又は２に記載のコンテンツ受信端末。
【請求項４】
前記携帯端末による前記サーバへのコンテンツの要求において、分割されたコンテンツのうちのいずれの要素を要求するかを指定することを特徴とする請求項３に記載のコンテンツ受信端末。
【請求項５】
前記携帯端末による前記サーバへのコンテンツの要求において、動き優先パラメータセット又は画質優先パラメータセットのいずれかを指定することを特徴とする請求項１から４までのいずれか１項に記載のコンテンツ受信端末。
【請求項６】
前記形態検出部により直近に検出された形態を記憶する形態記憶部を有しており、
該形態記憶部に記憶された形態と形態の変化の検出とに基づいて、検出後の形態を推定して記憶することを特徴とする請求項１から５までのいずれか１項に記載のコンテンツ受信端末。
【請求項７】
コンテンツ受信端末の形態が画面横向き形態に変化していると推定されると、画質を優先するパラメータセットを前記コンテンツ配信装置への配信指示データとすることを特徴とする請求項１から６までのいずれか１項に記載のコンテンツ受信端末。
【請求項８】
コンテンツ受信端末の形態が画面縦向き形態に変化していると推定されると、動きを優先するパラメータセットを前記コンテンツ配信装置への配信指示データとすることを特徴とする請求項１から７までのいずれか１項に記載のコンテンツ受信端末。
【請求項９】
ネットワークを介してコンテンツ配信サーバからコンテンツの配信を受けることができるコンテンツ受信端末であって、
端末の向く方向を検出する方向検出部を有し、
前記コンテンツ配信サーバに対するコンテンツの配信要求の際に前記方向検出部によって検出された向きに適したコンテンツの変換方法を指定する変換方法指定データを送信することを特徴とするコンテンツ受信端末。
【請求項１０】
請求項１から９までのいずれか１項に記載のコンテンツ受信端末に対してコンテンツを配信するコンテンツ配信装置であって、
符号化された符号化データを前記コンテンツ受信端末に送信する通信部を有することを特徴とするコンテンツ配信装置。
【請求項１１】
前記符号化データが、他の装置で事前に符号化された符号化済みデータであることを特徴とする請求項１０に記載のコンテンツ配信装置。
【請求項１２】
前記符号化済みデータが、他の装置で事前に復号、変換処理されたデータであることを特徴とする請求項１１に記載のコンテンツ配信装置。
【請求項１３】
前記変換方法指定データに基づいて前記保持した符号化データを読み出し、前記コンテンツ受信端末に送信することを特徴とする請求項１０から１２までのいずれか１項に記載のコンテンツ配信装置。
【請求項１４】
前記符号化済みデータを保存する符号化済みデータ保存部が、コンテンツ配信端末内又はコンテンツ配信端末外に設けられていることを特徴とする請求項１１から１３までのいずれか１項に記載のコンテンツ配信端末。
【請求項１５】
コンテンツを保存するコンテンツ保存部と、
コンテンツを復号する復号部と、
復号されたコンテンツデータを変換処理する変換制御部と
を有することを特徴とする請求項１０に記載のコンテンツ配信装置。
【請求項１６】
前記変換制御部は、前記変換方法指定データに基づいて変換を行うことを特徴とする請求項１５に記載のコンテンツ配信装置。
【請求項１７】
前記変換処理は、データ量を減らす方向又はフレーム数を減らす方向の処理であることを特徴とする請求項１２、又は請求項１６に記載のコンテンツ配信装置。
【請求項１８】
前記コンテンツ保存部が、通信回線により前記コンテンツ配信装置と接続可能な別の端末装置に設けられていることを特徴とする請求項１２から１７までのいずれか１項に記載のコンテンツ配信装置。
【請求項１９】
コンテンツ受信端末の形態を検出するステップと、
該形態に基づいて、コンテンツを配信するコンテンツ配信装置に対してコンテンツの変換方法を指定するデータを送信するステップと
を有することを特徴とする配信コンテンツ要求方法。
【請求項２０】
前記コンテンツ配信装置からの符号化データの受信中に前記コンテンツ受信端末の形態の変化が検出すると、前記コンテンツ配信装置に対して変換方法を指定するデータを送信するステップを有することを特徴とする請求項１９に記載の配信コンテンツ要求方法。
【請求項２１】
前記コンテンツ受信端末から送られた変換方法を指定するデータを受信し、該データの要求に基づいて復号されたデータに対して変換処理及び符号化を行うステップと、
前記符号化データを前記コンテンツ受信端末へ送信するステップと
を有することを特徴とする請求項１９、又は請求項２０に記載の配信コンテンツ要求方法。
【請求項２２】
前記コンテンツ受信端末から送られた変換方法を指定するデータを受信し、該データの要求に基づいて事前に保持する符号化データを読み出すステップと、前記符号化データを前記コンテンツ受信端末へ送信するステップとを有することを特徴とする請求項１９、又は請求項２０に記載の配信コンテンツ要求方法。
【請求項２３】
前記コンテンツ受信端末への符号化データの送信中に、前記コンテンツ受信端末から変換方法を指定するデータを受信するステップと、
前記変換方法の指定に基づいて復号されたデータに対して変換処理及び符号化を行うステップと、
前記符号化データを前記コンテンツ受信端末へ送信するステップと
を有することを特徴とする請求項２１に記載の配信コンテンツ要求方法。
【請求項２４】
前記コンテンツ受信端末への符号化データの送信中に、前記コンテンツ受信端末から変換方法を指定するデータを受信するステップと、
前記変換方法の指定に基づいて事前に保持する符号化データを読み出すステップと、前記符号化データを前記コンテンツ受信端末へ送信するステップと
を有することを特徴とする請求項２２に記載の配信コンテンツ要求方法。
【請求項２５】
請求項１９から２４までのいずれか１項に記載のステップをコンピュータに実行させるためのプログラム。
【請求項１】
可動部を備えることにより形態が変化し、ネットワークを介してコンテンツ配信装置からコンテンツの配信を受けることができるコンテンツ受信端末であって、
前記形態を検出する形態検出部を有し、
前記コンテンツ配信サーバに対するコンテンツの配信要求の際に前記形態検出部によって検出された形態に適したコンテンツの変換方法を指定する変換方法指定データを送信することを特徴とするコンテンツ受信端末。
【請求項２】
前記コンテンツを受信中に前記形態検出部によって形態の変化を検出すると、前記サーバに対してコンテンツの変換方法を指定するデータを送信することを特徴とする請求項１に記載のコンテンツ受信端末。
【請求項３】
前記携帯端末による前記サーバへのコンテンツの要求において、分割された符号化データを複数回にわたり配信するように要求することを特徴とする請求項１又は２に記載のコンテンツ受信端末。
【請求項４】
前記携帯端末による前記サーバへのコンテンツの要求において、分割されたコンテンツのうちのいずれの要素を要求するかを指定することを特徴とする請求項３に記載のコンテンツ受信端末。
【請求項５】
前記携帯端末による前記サーバへのコンテンツの要求において、動き優先パラメータセット又は画質優先パラメータセットのいずれかを指定することを特徴とする請求項１から４までのいずれか１項に記載のコンテンツ受信端末。
【請求項６】
前記形態検出部により直近に検出された形態を記憶する形態記憶部を有しており、
該形態記憶部に記憶された形態と形態の変化の検出とに基づいて、検出後の形態を推定して記憶することを特徴とする請求項１から５までのいずれか１項に記載のコンテンツ受信端末。
【請求項７】
コンテンツ受信端末の形態が画面横向き形態に変化していると推定されると、画質を優先するパラメータセットを前記コンテンツ配信装置への配信指示データとすることを特徴とする請求項１から６までのいずれか１項に記載のコンテンツ受信端末。
【請求項８】
コンテンツ受信端末の形態が画面縦向き形態に変化していると推定されると、動きを優先するパラメータセットを前記コンテンツ配信装置への配信指示データとすることを特徴とする請求項１から７までのいずれか１項に記載のコンテンツ受信端末。
【請求項９】
ネットワークを介してコンテンツ配信サーバからコンテンツの配信を受けることができるコンテンツ受信端末であって、
端末の向く方向を検出する方向検出部を有し、
前記コンテンツ配信サーバに対するコンテンツの配信要求の際に前記方向検出部によって検出された向きに適したコンテンツの変換方法を指定する変換方法指定データを送信することを特徴とするコンテンツ受信端末。
【請求項１０】
請求項１から９までのいずれか１項に記載のコンテンツ受信端末に対してコンテンツを配信するコンテンツ配信装置であって、
符号化された符号化データを前記コンテンツ受信端末に送信する通信部を有することを特徴とするコンテンツ配信装置。
【請求項１１】
前記符号化データが、他の装置で事前に符号化された符号化済みデータであることを特徴とする請求項１０に記載のコンテンツ配信装置。
【請求項１２】
前記符号化済みデータが、他の装置で事前に復号、変換処理されたデータであることを特徴とする請求項１１に記載のコンテンツ配信装置。
【請求項１３】
前記変換方法指定データに基づいて前記保持した符号化データを読み出し、前記コンテンツ受信端末に送信することを特徴とする請求項１０から１２までのいずれか１項に記載のコンテンツ配信装置。
【請求項１４】
前記符号化済みデータを保存する符号化済みデータ保存部が、コンテンツ配信端末内又はコンテンツ配信端末外に設けられていることを特徴とする請求項１１から１３までのいずれか１項に記載のコンテンツ配信端末。
【請求項１５】
コンテンツを保存するコンテンツ保存部と、
コンテンツを復号する復号部と、
復号されたコンテンツデータを変換処理する変換制御部と
を有することを特徴とする請求項１０に記載のコンテンツ配信装置。
【請求項１６】
前記変換制御部は、前記変換方法指定データに基づいて変換を行うことを特徴とする請求項１５に記載のコンテンツ配信装置。
【請求項１７】
前記変換処理は、データ量を減らす方向又はフレーム数を減らす方向の処理であることを特徴とする請求項１２、又は請求項１６に記載のコンテンツ配信装置。
【請求項１８】
前記コンテンツ保存部が、通信回線により前記コンテンツ配信装置と接続可能な別の端末装置に設けられていることを特徴とする請求項１２から１７までのいずれか１項に記載のコンテンツ配信装置。
【請求項１９】
コンテンツ受信端末の形態を検出するステップと、
該形態に基づいて、コンテンツを配信するコンテンツ配信装置に対してコンテンツの変換方法を指定するデータを送信するステップと
を有することを特徴とする配信コンテンツ要求方法。
【請求項２０】
前記コンテンツ配信装置からの符号化データの受信中に前記コンテンツ受信端末の形態の変化が検出すると、前記コンテンツ配信装置に対して変換方法を指定するデータを送信するステップを有することを特徴とする請求項１９に記載の配信コンテンツ要求方法。
【請求項２１】
前記コンテンツ受信端末から送られた変換方法を指定するデータを受信し、該データの要求に基づいて復号されたデータに対して変換処理及び符号化を行うステップと、
前記符号化データを前記コンテンツ受信端末へ送信するステップと
を有することを特徴とする請求項１９、又は請求項２０に記載の配信コンテンツ要求方法。
【請求項２２】
前記コンテンツ受信端末から送られた変換方法を指定するデータを受信し、該データの要求に基づいて事前に保持する符号化データを読み出すステップと、前記符号化データを前記コンテンツ受信端末へ送信するステップとを有することを特徴とする請求項１９、又は請求項２０に記載の配信コンテンツ要求方法。
【請求項２３】
前記コンテンツ受信端末への符号化データの送信中に、前記コンテンツ受信端末から変換方法を指定するデータを受信するステップと、
前記変換方法の指定に基づいて復号されたデータに対して変換処理及び符号化を行うステップと、
前記符号化データを前記コンテンツ受信端末へ送信するステップと
を有することを特徴とする請求項２１に記載の配信コンテンツ要求方法。
【請求項２４】
前記コンテンツ受信端末への符号化データの送信中に、前記コンテンツ受信端末から変換方法を指定するデータを受信するステップと、
前記変換方法の指定に基づいて事前に保持する符号化データを読み出すステップと、前記符号化データを前記コンテンツ受信端末へ送信するステップと
を有することを特徴とする請求項２２に記載の配信コンテンツ要求方法。
【請求項２５】
請求項１９から２４までのいずれか１項に記載のステップをコンピュータに実行させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２００８−７９２２８（Ｐ２００８−７９２２８Ａ）
【公開日】平成２０年４月３日（２００８．４．３）
【国際特許分類】
【出願番号】特願２００６−２５８９７６（Ｐ２００６−２５８９７６）
【出願日】平成１８年９月２５日（２００６．９．２５）
【出願人】（０００００５０４９）シャープ株式会社 (33,933)
【Ｆターム（参考）】
【公開日】平成２０年４月３日（２００８．４．３）
【国際特許分類】
【出願日】平成１８年９月２５日（２００６．９．２５）
【出願人】（０００００５０４９）シャープ株式会社 (33,933)
【Ｆターム（参考）】
[ Back to top ]