JP5014259B2 - 表示制御装置および表示制御方法 - Google Patents

Description

本発明は、動的コンテンツを複数の表示装置に表示させる表示制御装置および表示制御方法に関する。

近年、携帯電話機やＰＤＡ（personal digital assistants）等の持ち運び可能な小型端末（以下「ポータブル端末」という）において、インターネットからウェブ（Web）ページを取得し、取得したウェブページをブラウザで閲覧することが可能である。

ところが、ポータブル端末のディスプレイは、パーソナルコンピュータ等の据置型の端末のディスプレイに比べて、画面の面積が小さく、解像度も低い。一方、多くのウェブページが、１０インチ以上の画面およびＸＧＡ（extended graphics array, １０２４画素×７６８画素）の解像度が主流であるパーソナルコンピュータでの閲覧を想定して作成されている。したがって、ポータブル端末では、表示されるウェブページが閲覧し難いという問題がある。ポータブル端末は、通常、２インチから４インチ程度の小さい画面である。解像度をＸＧＡとすると、画像や文字は非常に小さくなり、見難くなる。一方で、解像度を低くすると、一度に表示される文字の数が少なくなり、改行の数が増加してスクロール操作が多く必要になるだけでなく、画面のレイアウトが崩れる。特に、ウェブページに、写真、地図、動画等のマルチメディア情報といった動的コンテンツが含まれる場合、動画の表示サイズはポータブル端末の画面サイズよりも更に小さくなる。

そこで、ポータブル端末が取得したウェブページを、自宅、学校、オフィス、喫茶店等の店舗に設置されたテレビジョン等、比較的大きなモニタに表示させることが考えられる。ポータブル端末以外の装置のディスプレイにウェブページを表示させるためには、ポータブル端末のディスプレイだけでなく、モニタのディスプレイにもウェブページを表示させる機能を、ポータブル端末に持たせる必要がある。複数のディスプレイにウェブページを表示させる技術は、例えば特許文献１に記載されている。

特許文献１記載の技術は、フレームバッファに格納されたウェブページの表示データを、ディスプレイごとに用意された複数のＶＲＡＭ（video random access memory）のそれぞれに書き込むことにより、複数のディスプレイに同じ画面を表示する。この技術を用いることにより、ポータブル端末が取得したウェブページを、外部モニタにも表示させることが可能となる。

ところが、特許文献１記載の技術では、外部モニタにおいて、ウェブページの画面レイアウトが崩れるという問題がある。これは、上述のように、ポータブル端末のディスプレイの解像度が、据置型の端末のディスプレイの解像度よりも低いためである。

そこで、特許文献２および非特許文献１に、ディスプレイごとに個別の表示データを作成することに関する技術が記載されている。

図１９は、特許文献２および非特許文献１記載の技術を適用した場合の、表示制御装置の構成を示すブロック図である。

図１９に示すように、表示制御装置１０は、本体表示部１１に対応する本体用動画デコーダ１２および本体用ブラウザ１３と、外部モニタ２０に対応するモニタ用動画デコーダ１４およびモニタ用ブラウザ１５とを有する。本体用動画デコーダ１２とモニタ用動画デコーダ１４は、ブラウザ用プラグイン(例えば、非特許文献１参照)として実装されている。また、表示制御装置１０は、これらの本体系統および外部モニタ系統と、ウェブサーバ３０との間に、データの中継を行うプロキシ部１６を配置している。更に、表示制御装置１０は、入力装置１７およびブラウザ制御部１８を配置している。プロキシ部１６は、本体表示部１１および外部モニタ２０の情報を保持している。プロキシ部１６は、ウェブサーバ３０からＩＰ（internet protocol）網４０を介してウェブページのデータを取得し、各ディスプレイの情報に合わせて、それぞれのディスプレイの担当エリアのコンテンツデータに変換する。そして、プロキシ部１６は、本体用ブラウザ１３およびモニタ用ブラウザ１５に、変換したコンテンツデータを渡す。コンテンツデータに動画データが含まれている場合には、プロキシ部１６は、動画データを、本体用動画デコーダ１２およびモニタ用動画デコーダ１４を介して、本体用ブラウザ１３およびモニタ用ブラウザ１５に渡す。本体用ブラウザ１３およびモニタ用ブラウザ１５は、プロキシ部１６から渡されるコンテンツデータに基づいて、担当エリアの表示を行う。

このように、特許文献２記載の技術を用いることにより、外部モニタにおいても、ウェブページの画面の適切なレイアウトで表示することが可能となる。
特表平１０−５０４１１９号公報 特開２００５−８５０５７号公報 Ｍｏｚｉｌｌａ Ｐｒｏｊｅｃｔ，"Ｍｏｚｉｌｌａ Ｄｅｖｅｌｏｐｅｒ Ｃｅｎｔｅｒ − Ｐｌｕｇｉｎｓ"、［online］、［平成２０年５月２６日検索］、〈URL：http://developer.mozilla.org/ja/docs/Plugins〉

ところで、動画コンテンツを表示させるためには、図１９に示すように、動画コンテンツのデータの取得およびデコードを行う動画デコーダが必要となる。動画コンテンツを含むウェブページの場合、その基となるＨＴＭＬ（hypertext markup language）データには、動画コンテンツのデコード（復号）を行う主体を指定する情報（以下「指定情報」という）が含まれている。ブラウザは、この指定情報に基づいて、動画デコーダを起動し、動画デコーダでデコードされた動画コンテンツをウェブページに嵌め込む。

したがって、図１９に示す表示制御装置は、複数のブラウザに対応する複数のデコーダを配置し、同一の動画コンテンツに対して複数のデコード処理を行わなければならない。

ところが、同一の処理を行う複数の機能部を重複して設け、同一の処理を重複して実行することは、コスト、サイズ、および処理負荷の面で好ましくない。

本発明は、かかる点に鑑みてなされたものであり、機能部の重複および処理の重複を回避して、複数の表示装置で動画コンテンツを表示することができる、表示制御装置および表示制御方法を提供することを目的とする。

本発明の表示制御装置は、動的コンテンツの復号を行い、復号した動的コンテンツを第１のバッファに格納するコンテンツ取得部と、前記第１のバッファに格納された前記動的コンテンツを、第２のバッファに転送するバッファ転送部と、前記第１のバッファに格納された前記動的コンテンツを第１の表示装置に表示させる第１の表示制御部と、前記第２のバッファに格納された前記動的コンテンツを第２の表示装置に表示させる第２の表示制御部とを備え、前記コンテンツ取得部は、動的コンテンツの復号を行う復号主体を指定する指定情報を入力する情報入力部と、動的コンテンツの復号を行う動的コンテンツ復号部と、前記指定情報が前記動的コンテンツ復号部を指定するとき、前記指定情報を、前記バッファ転送部を指定する内容に書き換える情報書換部とを有する構成を採る。

本発明の表示制御方法は、動的コンテンツの復号を行う復号主体を指定する指定情報を取得するステップと、前記指定情報が動的コンテンツ復号部を指定するとき、前記動的コンテンツ復号部を用いて動的コンテンツを復号し、復号された動的コンテンツを、第１の表示装置で表示を行うための第１のバッファに格納するステップと、前記第１のバッファに格納された前記動的コンテンツを、第２の表示装置で表示を行うための第２のバッファに転送するステップとを有するようにした。

本発明によれば、第１の表示装置で表示を行うための第１のバッファから、第２の表示装置で表示を行うための第２のバッファへと、復号された動的コンテンツを転送することができる。これにより、動的コンテンツのデコーダを、第２の表示装置のために別個に設けなくて済み、機能部の重複および処理の重複を回避して、複数の表示装置で動画コンテンツを表示することができる。

以下、本発明の各実施の形態について、図面を参照して詳細に説明する。

（実施の形態１）
図１は、本発明の実施の形態１に係る表示制御装置を含む画像表示システムの構成を示すシステム構成図である。

図１において、画像表示システム１００は、ウェブサーバ２００、ＩＰ網３００、ポータブル端末４００、および外部モニタ５００を有する。ポータブル端末４００は、本発明に係る表示制御装置を含む端末であり、例えば、携帯電話機である。外部モニタ５００は、ポータブル端末４００の本体ディスプレイ４００ａよりも大きい、つまり解像度がより高いディスプレイ５００ａを有する表示装置であり、例えば、家庭用テレビジョンである。

ウェブサーバ２００は、ウェブページを記述したデータ（以下「コンテンツデータ」という）を格納しており、ポータブル端末４００からの要求に応じて、コンテンツデータを返信する。すなわち、ウェブサーバ２００は、ポータブル端末４００がアクセスを行う対象となるサーバである。ウェブサーバ２００は、静的なウェブページのみならず、動画、スクリプト、およびアニメーション等の動的なコンテンツを含む動的なウェブページをも格納している。本実施の形態では、動的なコンテンツが、動画コンテンツ（以下、適宜「動画」という）であるものとして以下の説明を行う。

ＩＰ網３００は、ＩＰを使用した通信ネットワークである。ＩＰ網３００は、例えば、インターネット等の広域無線網、無線ＬＡＮ（local area network）、またはＩＥＥＥ８０２.１６／１６ｅ等で策定された無線ＭＡＮ（metropolitan area network）である。

ポータブル端末４００は、ウェブサーバ２００から、ＩＰ網３００を介して、ウェブページのコンテンツデータ（以下、適宜「ウェブページ」という）を取得する機能を有する。また、ポータブル端末４００は、取得したコンテンツデータに基づいて、ウェブページを自端末のディスプレイ（以下「本体ディスプレイ」という）４００ａに表示する機能を有する。ポータブル端末４００は、静的なウェブページのみならず、動画を含む動的なウェブページをも取得・表示可能である。また、ポータブル端末４００は、取得した１つのコンテンツデータから、ウェブページを表示するためのデータ（以下「表示データ」という）を複数生成する機能を有する。具体的には、ポータブル端末４００は、本体ディスプレイ４００ａ用の表示データだけでなく、外部モニタ５００のディスプレイ（以下「モニタディスプレイ」という）５００ａ用の表示データをも生成する。ポータブル端末４００は、生成した外部モニタ５００用の表示データを、所定の画像圧縮方式を用いてエンコードし、近距離無線通信による無線通信回線６００を使用して、外部モニタ５００に送信する。所定の画像圧縮方式は、例えば、Ｍｏｔｉｏｎ−ＪＰＥＧ／ＪＰＥＧ２０００、ＭＰＥＧ２、またはＨ.２６４である。

また、ポータブル端末４００は、動画を含むウェブページを取得したとき、本体ディスプレイ４００ａ用にデコードされた動画のデータ（以下「動画データ」という）を、本体ディスプレイ４００ａでの動画表示だけでなく、外部モニタ５００での動画表示にも用いる。

外部モニタ５００は、ポータブル端末４００から表示データを受信し、受信した表示データに基づいて、モニタディスプレイ５００ａにウェブページを表示する機能を有する。外部モニタ５００は、ポータブル端末４００と共通の近距離通信方式および表示データ形式に対応している。

無線通信回線６００は、ポータブル端末４００と外部モニタ５００を接続する近距離無線の通信回線である。無線通信回線６００の無線通信方式として、例えば、ＵＷＢ（ultra wide band）や、ＩＥＥＥ８０２．１１を採用することができる。

ここで、図１を用いて、画像表示システム１００の利用形態の一例について説明する。

まず、ユーザにより、動画を含むウェブページが指定されると、ポータブル端末４００は、指定されたウェブページをウェブサーバ２００から取得し、本体ディスプレイ４００ａに表示する。そして、表示されたウェブページ４００ｂにおいて、動画４００ｃの再生が開始される。

そして、ユーザにより、表示中のウェブページ４００ｂを外部モニタ５００で表示することが指示されると、ポータブル端末４００は、外部モニタ５００用の表示データを作成し、無線通信回線６００を介して外部モニタ５００に出力する。この結果、外部モニタ５００のモニタディスプレイ５００ａには、ウェブページ５００ｂが表示され、ウェブページ５００ｂ上で動画５００ｃが再生される。本体ディスプレイ４００ａ用にデコードされた動画データが、外部モニタ５００のウェブページでも利用されるので、外部モニタ５００の動画５００ｃは、ポータブル端末４００で再生されている動画４００ｃとほぼ同期して再生される。実際には、動画５００ｃには、無線通信における表示データの伝送および画像圧縮・伸長処理によって、動画４００ｃよりも多少の遅延が発生するが、視聴に支障をきたさない程度である。

このような画像表示システム１００によれば、ポータブル端末４００でウェブサーバ２００からウェブページを取得し、外部モニタ５００の大きなディスプレイで、ウェブページを本来のレイアウトを保持した状態で表示させることができる。

次に、ポータブル端末４００の構成について説明する。図２は、ポータブル端末４００の構成を示すブロック図である。

図２において、ポータブル端末４００は、入力装置４０１、ＩＰ接続インタフェース４０２、共通パーザ４０３、ブラウザ制御部４０４、本体用レンダラー４０５、本体用フレームバッファ４０６、本体表示部４０７、バッファ転送部４０８、共通動画デコーダ４０９、外部モニタ用レンダラー４１０、外部モニタ用フレームバッファ４１１、および外部モニタインタフェース４１２を有する。共通パーザ４０３、ブラウザ制御部４０４、本体用レンダラー４０５、および外部モニタ用レンダラー４１０は、ウェブページのブラウザを構成する。

入力装置４０１は、ユーザからの入力を受け付ける入力装置である。本実施の形態では、入力装置４０１は、タッチスクリーンであるものとする。本実施の形態では、入力装置４０１は、便宜上、入力を行うハードウェアと出力を行うソフトウェアとを含む概念とする。ソフトウェアは、例えば、ハードウェア割り込みを受信し、ＯＳ（operating system）上で動作するアプリケーション上のイベントとして入力情報を出力する、デバイスドライバやユーザモードプロセス等である。入力装置４０１は、ユーザの入力操作を受けて、他のプロセス、つまり共通パーザ４０３やブラウザ制御部４０４に、イベントやメッセージを送る。

ＩＰ接続インタフェース４０２は、ＩＰ網３００と接続するためのインタフェースである。ＩＰ接続インタフェース４０２も、本実施の形態では、便宜上、ハードウェアとソフトウェアとを含む概念とする。ハードウェアは、無線通信用のパワーアンプ、ＲＦ（radio frequency）やベースバンドチップ等である。ソフトウェアは、ハードウェアを制御するためのデバイスドライバやユーザモードプロセス等である。ＩＰ接続インタフェース４０２は、ＩＰ網３００側からのパケットの受信を受けて、他のプロセス、つまり共通パーザ４０３や共通動画デコーダ４０９にイベントやメッセージを送る。また、ＩＰ接続インタフェース４０２は、ソケットインタフェース等を使い、他のプロセス、つまり共通パーザ４０３や共通動画デコーダ４０９から入力されたデータを、ＩＰ網３００に送出する。

共通パーザ４０３は、入力装置４０１からのイベントの入力を受けて、ＩＰ接続インタフェース４０２を制御してウェブサーバ２００からウェブページを取得する機能を有する。また、共通パーザ４０３は、取得したウェブページの内容を解析し、解析結果をブラウザ制御部４０４に渡す機能を有する。ウェブページのコンテンツデータは、ＨＴＭＬやＸＭＬ（extensible markup language）等のマークアップ言語で、ウェブページの表示内容を記述したものである。共通パーザ４０３は、例えば、Ｗ３Ｃ（World Wide Web Consortium）で標準化されたＤＯＭ（Document Object Model）の適用を想定した場合、ＤＯＭを実装したライブラリのうち、主に、ＤＯＭ Ｃｏｒｅ、ＤＯＭ ＨＴＭＬ、およびＤＯＭ Ｌｅｖｅｌ ２ Ｅｖｅｎｔｓの部分に当たる。共通パーザ４０３には、一般にブラウザエンジンと呼ばれるコンポーネントを用いることができる。具体的には、例えば、マイクロソフト（Microsoft（登録商標））社のインターネットエクスプローラ（Internet Explorer、登録商標）のコンポーネントであるＴｒｉｄｅｎｔ（登録商標）、Ｇｅｃｋｏ、ＫＨＴＭＬ、ＷｅｂＫｉｔ、Ｐｒｅｓｔｏ等である。以下、ウェブページのコンテンツデータがＨＴＭＬデータであるものとして、説明を行う。

ブラウザ制御部４０４は、共通パーザ４０３を使用してブラウザの挙動を決める、ブラウザの中心部となる機能部である。ブラウザ制御部４０４は、必要に応じて、本体用レンダラー４０５および外部モニタ用レンダラー４１０に対して共通の動画のデコード処理を行わせるための指示を行う。この指示は、取得されたウェブページを書き換えることによって実現される。具体的には、ブラウザ制御部４０４は、ＨＴＭＬデータに対し、動画を表示させるために指定されている外部プログラム（プラグイン）を、後述のバッファ転送部４０８に書き換える。

本体用レンダラー４０５は、本体表示部４０７でのブラウザ表示を行う際に、ブラウザ制御部４０４から呼び出されて動作する機能部である。本体用レンダラー４０５は、ＨＴＭＬデータを、後述の本体表示部４０７用の表示データに変換して本体用フレームバッファ４０６に格納すると共に、後述の動画バッファ４０６ａの領域を決定し、必要に応じてプラグインを起動する機能を有する。一般には、本体用レンダラー４０５は、ＨＴＭＬデータにＯＢＪＥＣＴタグやＥＭＢＥＤタグによるコンテンツ指定が存在するときに、対応するプラグインを起動する。本体用レンダラー４０５は、プラグインを起動する際に、必要に応じて動画バッファ４０６ａの領域に関する情報を起動対象のプラグインに渡す。本体用レンダラー４０５は、ＤＯＭの適用を想定した場合、ＤＯＭを実装したライブラリのうち、描画を行う部分に当たる。また、本体用レンダラー４０５には、ブラウザエンジンを用いることができる。

本体用フレームバッファ４０６には、ウェブページを本体表示部４０７に表示するための表示データが格納される。本体用フレームバッファ４０６のうち、後述の本体表示部４０７に表示される動画データが格納される領域を、動画バッファ４０６ａとする。本体用フレームバッファ４０６は、ブラウザ制御部４０４がＯＳよりも上位のアプリケーションレイヤのソフトウェアとして実装されている場合には、このアプリケーションからアクセス可能である必要がある。本体用フレームバッファ４０６は、本実施の形態では、説明の簡単のため、単一のバッファとしているが、描画動作による遅延を吸収するために、複数のバッファを備えた構成としても良い。

本体表示部４０７は、ポータブル端末４００の本体に付属するディスプレイを含み、本体用フレームバッファ４０６に格納された表示データに基づいて、ウェブページを表示する機能を有する。本体表示部４０７は、液晶または有機ＥＬ（electroluminescence）等を用いたディスプレイデバイスおよびドライバモジュール等のハードウェアと、デバイスドライバなどのソフトウェアとを含む。

バッファ転送部４０８は、後述の共通動画デコーダ４０９を起動し、動画データのデコードおよび動画バッファ４０６ａへの書き込みを指示する機能を有する。またバッファ転送部４０８は、本体用フレームバッファ４０６に格納される表示データのうち動画バッファ４０６ａに格納される部分、つまりデコードされた動画データを、後述の外部モニタ用フレームバッファ４１１に転送する機能を有する。バッファ転送部４０８は、従来では本体用レンダラー４０５によって共通動画デコーダ４０９が起動されるべきところを、共通動画デコーダ４０９の代わりに起動され、本体用レンダラー４０５に代わって共通動画デコーダ４０９の起動を制御するプロセスである。バッファ転送部４０８の起動、およびバッファ転送部４０８による共通動画デコーダ４０９の起動は、上述のブラウザ制御部４０４でのＨＴＭＬの書き換えによって実現される。ＨＴＭＬの書き換えの詳細については、後述する。

共通動画デコーダ４０９は、動画の基となるデータ（以下「動画データ」という）をデコードして、フレームバッファに格納可能な動画データを作成する機能を有する。共通動画デコーダ４０９は、ＩＰ接続インタフェース４０２およびＩＰ網３００を介して、図１のウェブサーバ２００から動画データを取得し、取得した動画データに対して順次デコードを行う。そして、共通動画デコーダ４０９は、デコードした動画データを、バッファ転送部４０８によって指定された場所に書き込む。共通動画デコーダ４０９は、従来ではレンダラーによって起動されて制御されるべきところを、バッファ転送部４０８によって起動されて制御されるプロセスである。バッファ転送部４０８による共通動画デコーダ４０９の起動および制御は、上述のブラウザ制御部４０４でのＨＴＭＬの書き換えによって実現される。

外部モニタ用レンダラー４１０は、ＨＴＭＬデータを、外部モニタ５００用の表示データに変換して外部モニタ用フレームバッファ４１１に格納すると共に、本体用レンダラー４０５と同様に、必要に応じてプラグインを起動する機能を有する。外部モニタ用レンダラー４１０が本体用レンダラー４０５と異なる点は、外部モニタ５００における描画領域の大きさに関する知識を持っている点である。これにより、外部モニタ用レンダラー４１０は、本体表示部４０７とは解像度が異なる外部モニタ５００において、ウェブページが適切なレイアウトで表示されるような表示データを、生成することができる。

外部モニタ用フレームバッファ４１１には、ウェブページを外部モニタ５００に表示するための表示データが格納される。外部モニタ用フレームバッファ４１１のうち、外部モニタ５００に表示される動画データが格納される領域を、動画バッファ４１１ａとする。外部モニタ用フレームバッファ４１１は、ブラウザ制御部４０４がＯＳよりも上位のアプリケーションレイヤのソフトウェアとして実装されている場合には、このアプリケーションからアクセス可能である必要がある。外部モニタ用フレームバッファ４１１は、本実施の形態では、説明の簡単のため、単一のバッファとしているが、描画動作による遅延を吸収するために、複数のバッファを備えた構成としても良い。

外部モニタインタフェース４１２は、外部モニタ５００に接続し、外部モニタ５００に対して表示データを送信するためのインタフェースである。本実施の形態では、外部モニタインタフェース４１２は、便宜上、ソフトウェアとハードウェアとを含む概念とする。ソフトウェアは、外部モニタ５００に適合した表示データを作成するプロセス、外部モニタ５００との通信回線を制御するデバイスドライバ、および表示データを一時的に保存するバッファ等である。ハードウェアは、通信回線に表示データを送出するためのインタフェースである。

ポータブル端末４００は、図示しないが、ＣＰＵ（central processing unit）や、制御プログラムが格納されたＲＯＭ（read only memory）などの記憶媒体、ＲＡＭ（random access memory）などの作業用メモリなどを有する。例えば、ＣＰＵが制御プログラムを実行することで、上記した各部の機能は実現される。

このようなポータブル端末４００によれば、本体用フレームバッファ４０６から外部モニタ用フレームバッファ４１１へと、デコードされた動的コンテンツを転送することができる。これにより、ウェブサーバ２００から動画を取得するための機能部を、外部モニタ５００のために別個に設けなくて済み、機能部の重複および処理の重複を回避することができる。また、ウェブサーバ２００から取得したウェブページを、ウェブページを本来のレイアウトを保持した状態で、外部モニタ５００のディスプレイで表示させることができる。更に、ポータブル端末４００と外部モニタ５００との間で、動画再生の同期を取ることができる。

ここで、ポータブル端末４００が取得するＨＴＭＬデータの構成について説明する。

図３は、ＯＢＪＥＣＴタグとＥＭＢＥＤタグを用いて動画を表示するウェブページのＨＴＭＬデータの一例の抜粋を示す図である。

図３に示すように、ウェブサーバ２００から取得されるＨＴＭＬデータ７１０には、ＯＢＪＥＣＴタグ７１１、ＰＡＲＡＭタグ７１２〜７１４、およびＥＭＢＥＤタグ７１５が記述されている。

ＯＢＪＥＣＴタグ７１１は、ＣＬＡＳＳＩＤ属性としてコンテンツのクラスＩＤ（identifier）を指定し、ＷＩＤＴＨ属性としてコンテンツの表示領域の横の長さを指定し、ＨＥＩＧＨＴ属性としてコンテンツの表示領域の縦の長さを指定する。

ＰＡＲＡＭタグ７１２は、コンテンツとして出力する動画ファイルのアドレスを指定する。ＰＡＲＡＭタグ７１３、７１４は、再生方法に関するパラメータを指定する。ＰＡＲＡＭタグでは、ＮＡＭＥ属性を使ってパラメータの名称の指定を行い、ＶＡＬＵＥ属性を使ってパラメータの値の指定を行う。ＥＭＢＥＤタグ７１５は、ＳＲＣ属性によって出力動画ファイルの名称を指定し、ＷＩＤＴＨ属性によって動的コンテンツ（ここでは動画）の表示領域の横の長さを指定し、ＨＥＩＧＨＴ属性によって動的コンテンツの表示領域の縦の長さを指定する。また、ＥＭＢＥＤタグ７１５は、ＬＯＯＰ属性およびＱＵＡＬＩＴＹ属性によって動的コンテンツの再生方法を指定し、ＴＹＰＥ属性によってＭＩＭＥ（multipurpose internet mail extension）タイプを指定する。ＴＹＰＥ属性以外は、ＯＢＪＥＣＴタグ７１１およびＰＡＲＡＭタグ７１２〜７１４において指定された内容と等価である。ここでは、動的コンテンツがＭＰＥＧ形式の場合を示しているが、これに限定されるものではない。

ＨＴＭＬデータ７１０に動画が含まれるか否かは、動画再生のための外部プログラム（プラグイン）に対応するクラスＩＤまたはＭＩＭＥタイプが、ＯＢＪＥＣＴタグのＣＬＡＳＳＩＤ属性またはＥＭＢＥＤタグのｔｙｐｅ属性として指定されているか否かによって、判断することができる。また、ＨＴＭＬデータ７１０に含まれる動画は、ＯＢＪＥＣＴタグのＣＬＡＳＳＩＤ属性またはＥＭＢＥＤタグのｔｙｐｅ属性に基づいて、対応するプラグインを起動させることによって、再生することができる。

以下、上記構成を有するポータブル端末４００の動作について説明する。

図４は、ポータブル端末４００の全体動作を示すフローチャートである。

まず、ステップＳ１１００で、ポータブル端末４００は、ウェブページのリンクの指定があったか否かを判断する。具体的には、ポータブル端末４００は、ウェブブラウザで表示すべきウェブページのリンクのＵＲＬ（uniform resource locator）またはＵＲＩ（uniform resource identifier）が指定されたか否かを判断する。リンクの指定は、例えば、ウェブブラウザが動作しているときは、ウェブブラウザに表示されているリンク部分をユーザがタッチすることに行われる。また、リンクの指定は、例えば、ウェブブラウザが起動していないときは、画面上に表示されているＵＲＬが表すアイコンをタッチすることにより行われる。リンク指定の有無の判断は、例えば、入力装置４０１から共通パーザ４０３へと、リンクが指定されたことを示すイベント検出のメッセージが入力されたか否かを判断することにより行われる。

リンク指定が行われた場合には（Ｓ１１００：ＹＥＳ）、ステップＳ１３００で、ポータブル端末４００は、指定されたウェブページを本体表示部４０７で表示するための処理である本体表示処理を実行する。本体表示処理の詳細については後述する。

そして、ステップＳ１４００で、ポータブル端末４００は、外部モニタ５００でのウェブページの表示、つまり表示データの外部出力の指定があったか否かを判断する。具体的には、ポータブル端末４００は、例えば、入力装置４０１のユーザ操作によって、本体表示部４０７で表示されているウェブページと同一のウェブページを外部モニタ５００に表示させることが指示されたか否かを判断する。外部出力の指定は、例えば、ユーザが、タッチパネルに表示された外部モニタ５００を示すアイコンをタッチしたり、本体表示部４０７に表示されたウェブブラウザのウィンドウを、外部モニタ５００を示すアイコンにドラッグ・アンド・ドロップすることにより行われる。また、外部出力指定用のボタンがポータブル端末４００に設けられている場合には、外部出力の指定は、ユーザによりこのボタンが押下されることにより行われても良い。また、外部出力指定の有無の判断は、例えば、入力装置４０１からブラウザ制御部４０４へと、外部出力が指定されたことを示すイベント検出のメッセージが入力されたか否かを判断することにより行われる。外部出力の指定の検出は、ウェブページとは別の場所で行われるため、共通パーザ４０３ではなく、ブラウザ制御部４０４が行う。

外部出力の指定がされた場合には（Ｓ１４００：ＹＥＳ）、ステップＳ１５００で、ポータブル端末４００は、本体表示部４０７で表示されているウェブページと同一のウェブページを外部モニタ５００に表示するための処理である外部出力処理を実行する。外部出力処理の詳細については後述する。

一方、リンク指定が行われていない場合、または外部出力の指定がされていない場合には（Ｓ１１００：ＮＯ、Ｓ１４００：ＮＯ）、ステップＳ１２００で、ポータブル端末４００は、入力装置４０１のユーザ操作等によって動作終了を指示されたか否かを判断する。ポータブル端末４００は、動作終了を指示されていない場合には（Ｓ１２００：ＮＯ）、ステップＳ１１００に戻って動作を継続し、動作終了を指示された場合には（Ｓ１２００：ＹＥＳ）、一連の動作を終了する。

このような処理により、ポータブル端末４００は、リンク指定を受けて本体表示処理を実行し、外部出力指定を受けて外部出力処理を実行する。

図５は、本体表示処理を示すフローチャートである。

まず、ステップＳ１３０１で、共通パーザ４０３は、リンク指定を検出する。

そして、ステップＳ１３０２で、共通パーザ４０３は、ＩＰ接続インタフェース４０２およびＩＰ網３００を介して、指定されたリンク先のウェブページのＨＴＭＬデータを、ウェブサーバ２００から取得する。

そして、ステップＳ１３０３で、共通パーザ４０３は、取得したＨＴＭＬデータを解析して、構文解析データを作成し、ブラウザ制御部４０４に渡す。構文解析データは、ＨＴＭＬデータの構造を示すデータ構造であり、例えば、Ｗ３ＣのＤＯＭ ｃｏｒｅ仕様のＤＯＭ Ｓｔｒｕｃｔｕｒｅ Ｍｏｄｅｌとして表現される。

そして、ステップＳ１３０４で、ブラウザ制御部４０４は、ＨＴＭＬデータに動画が含まれるか否かを判断する。本実施の形態では、図３で説明したＯＢＪＥＣＴタグまたはＥＭＢＥＤタグの解析により、動画の有無の判断を行う。

ＨＴＭＬデータに動画が含まれる場合には（Ｓ１３０４：ＮＯ）、ステップＳ１３０５で、ブラウザ制御部４０４は、ＨＴＭＬデータに対し、動画再生のための起動プラグインの変更を行う。起動プラグインの変更の目的は、上述の通り、ＨＴＭＬデータに基づいて動作するレンダラーに対して、共通動画デコーダ４０９ではなくバッファ転送部４０８を起動させることである。また、これにより、外部モニタ５００でのウェブページ表示が開始される際に、共通動画デコーダ４０９が起動するのを抑制することである。

ここで、ブラウザ制御部４０４によるＨＴＭＬデータに対する起動プラグインの変更の処理について説明する。

図６は、図３に示すＨＴＭＬデータに対し、起動プラグインの変更が行われた後の、ＨＴＭＬデータの一例の抜粋を示す図である。図３と対応する部分には同一符号を付し、これについての説明を省略する。また、図３と異なる部分、つまり変更部分に、下線を付している。

ここで、共通動画デコーダ４０９は、クラスＩＤ“ｃｌｓｉｄ：ＡＡ−ＢＢＢＢ−ＣＣＣＣ−ＤＤＤＤ−ＥＥＥＥＥＥＥＥ００００”に対応しているものとする。また、バッファ転送部４０８のクラスＩＤは、“ｃｌｓｉｄ：２２ＡＡ−２Ａ−２Ａ−２Ａ−２２ＡＡ００００”に設定されているものとする。

この場合、ブラウザ制御部４０４は、図３のＯＢＪＥＣＴタグ７１１のＣＬＡＳＳＩＤ属性が、共通動画デコーダ４０９のクラスＩＤに一致していることから、ＯＢＪＥＣＴタグ７１１のＣＬＡＳＳＩＤ属性を書き換えて、ＨＴＭＬデータ７２０を生成する。

具体的には、ブラウザ制御部４０４は、図６に示すように、ＯＢＪＥＣＴタグ７１１のＣＬＡＳＳＩＤ属性を、バッファ転送部４０８のクラスＩＤ“ｃｌｓｉｄ：２２ＡＡ−２Ａ−２Ａ−２Ａ−２２ＡＡ００００”に書き換える。そして、ブラウザ制御部４０４は、図６に示すように、元のクラスＩＤをＯＲＩＧＩＮＡＬＣＬＡＳＳＩＤ属性として記述したＰＡＲＡＭタグ７２１を追加する。これにより、起動プラグインの変更が行われた後のＨＴＭＬデータ７２０は、動画再生のためのプラグインとして、共通動画デコーダ４０９ではなく、バッファ転送部４０８を指定するとともに、変更前のプラグインを示す情報を含むデータとなる。

なお、起動プラグインの変更は、他の手法によっても実現することができる。

図７〜図９は、起動プラグイン変更後のＨＴＭＬデータの他の例の抜粋を示す図である。図３と同一部分には同一符号を付し、これについての説明を省略する。また、図３と異なる部分に、下線を付している。

図７は、元のクラスＩＤを、ＯＢＪＥＣＴタグのＯＲＩＧＩＮＡＬＣＬＡＳＳＩＤ属性として埋め込む手法を採用した場合の、起動プラグイン変更後のＯＢＪＥＣＴタグ７１１を示す。図８は、ＥＭＢＥＤタグのＴＹＰＥ属性として、バッファ転送部４０８のＭＩＭＥタイプ“ａｐｐｌｉｃａｔｉｏｎ/ｘ−ｂｕｆｆｅｒｔｒａｎｓｆｅｒ”を記述し、元のＭＩＭＥタイプを、ＯＲＩＧＩＮＡＬＴＹＰＥ属性として埋め込む手法を採用した場合の、起動プラグイン変更後のＥＭＢＥＤタグ７１５を示す。図９は、図８で説明した手法に加えて、ＯＢＪＥＣＴタグで指定されていた元のクラスＩＤをＯＲＩＧＩＮＡＬＣＬＡＳＳＩＤ属性として埋め込む手法を採用した場合の、起動プラグイン変更後のＥＭＢＥＤタグ７１５を示す。これらの手法によっても、起動プラグインの変更が行われた後のＨＴＭＬデータ７２０を、動画再生のためのプラグインとして、共通動画デコーダ４０９ではなく、バッファ転送部４０８を指定するとともに、変更前のプラグインを示す情報を含むデータとすることができる。

一方、図５において、ＨＴＭＬデータに動画が含まれない場合には（Ｓ１３０４：ＹＥＳ）、ステップＳ１３０６で、ブラウザ制御部４０４は、本体用レンダラー４０５を呼び出し、ＨＴＭＬデータを渡して、ウェブページのレンダリングを開始するように指示する。この指示を受けて、本体用レンダラー４０５は、本体表示部４０７のウェブページ表示部分のサイズ（解像度）を取得する。

そして、ステップＳ１３０７で、本体用レンダラー４０５は、本体表示部４０７にウェブページを表示するためのレンダリングを行う。このレンダリングは、取得した本体表示部４０７のウェブページ表示部分のサイズに基づき、渡されたＨＴＭＬデータからレンダリングを行って表示データを生成し、本体用フレームバッファ４０６に書き込むことにより行われる。本体用フレームバッファ４０６に書き込まれた表示データは、本体表示部４０７に表示される。

そして、ステップＳ１３０８で、本体用レンダラー４０５は、ステップＳ１３０４と同様の手法により、ウェブページに動画が含まれるかどうかを判断する。

ウェブページに動画が含まれる場合には（Ｓ１３０８：ＮＯ）、ステップＳ１３０９で、本体用レンダラー４０５は、バッファ転送部４０８を起動するとともに、バッファ転送部４０８の動作に必要な各種設定を行う。

具体的には、以下の通りである。まず、本体用レンダラー４０５は、本体表示部４０７のウェブページの表示領域における動画の表示領域の位置と、動画バッファ４０６ａのアドレスとを計算する。ブラウザがＭｉｃｒｏｓｏｆｔ（登録商標）社のＷｉｎｄｏｗｓ（登録商標）である場合には、本体用レンダラー４０５は、アドレスの代わりに、Ｗｉｎｄｏｗｓ（登録商標）のデバイスコンテキストを使用して、動画バッファ４０６ａを設定することが可能である。そして、本体用レンダラー４０５は、ＨＴＭＬデータのＯＢＪＥＣＴタグを解析し、ＯＢＪＥＣＴタグのＣＬＡＳＳＩＤ属性に記述されているクラスＩＤに対応するプラグインを起動する。本実施の形態では、図６で説明したように、バッファ転送部４０８のクラスＩＤが記述されているので、本体用レンダラー４０５は、このクラスＩＤに対応するプラグインであるバッファ転送部４０８を起動する。本体用レンダラー４０５は、バッファ転送部４０８を起動する際に、「元のクラスＩＤ（または元のＭＩＭＥタイプ）」、「動画の表示領域の位置およびサイズ」、「本体用フレームバッファ内の動画データのアドレス（動画バッファのアドレス）」、「動画ファイルのアドレス」、ＰＡＲＡＭタグおよびＯＢＪＥＣＴタグの属性、ＥＭＢＥＤタグの属性を、バッファ転送部４０８にパラメータとして指定する。

そして、ステップＳ１３１０で、バッファ転送部４０８は、本体用レンダラー４０５により指定された「動画バッファのアドレス」を内部に保持する。

そして、ステップＳ１３１１で、バッファ転送部４０８は、本体用レンダラー４０５により指定された「元のクラスＩＤ」または「元のＭＩＭＥタイプ」から、起動すべきプラグインを判断し、起動する。本実施の形態では、共通動画デコーダ４０９のクラスＩＤが「元のクラスＩＤ」として指定されているため、バッファ転送部４０８は、共通動画デコーダ４０９を起動する。このとき、バッファ転送部４０８は、本体用レンダラー４０５により指定された、バッファ転送部４０８の「クラスＩＤ」、および「ＭＩＭＥタイプ」以外のパラメータを指定する。共通動画デコーダ４０９には、既存の動画デコーダに用いられているパラメータと同一のパラメータを設定することができるので、バッファ転送部４０８が共通動画デコーダ４０９を起動する際に、元のクラスＩＤ（または元のＭＩＭＥタイプ）を指定することも可能である。この場合には、既存のプラグインをそのまま流用することができる。

そして、ステップＳ１３１２で、共通動画デコーダ４０９は、バッファ転送部４０８により指定された「動画の表示領域の位置およびサイズ」を元にして、「動画ファイルのアドレス」として指定された動画ファイルに対し、動画デコードを行う。具体的には、共通動画デコーダ４０９は、指定された動画ファイルの動画データを、ＩＰ接続インタフェース４０２およびＩＰ網３００を介してウェブサーバ２００から取得し、デコードした動画データを、「動画バッファのアドレス」として指定された動画バッファ４０６ａに書き込む。

これにより、本体表示部４０７では、動画の表示が開始され、ポータブル端末４００は、本体表示処理を終了して図４の処理に戻る。また、ウェブページに動画が含まれない場合は（Ｓ１３０８：ＹＥＳ）、ポータブル端末４００は、ステップＳ１３０９〜Ｓ１３１２の処理を行うことなく、本体表示処理を終了して図４の処理に戻る。

このようにして、ポータブル端末４００は、ウェブページに動画が含まれるときに、バッファ転送部４０８を起動し、バッファ転送部４０８の制御のもと、共通動画デコーダ４０９による動画デコードを開始することができる。

図１０は、外部出力処理を示すフローチャートである。

まず、ステップＳ１４０１で、ブラウザ制御部４０４は、外部出力指定を検出する。

そして、ステップＳ１４０２で、ブラウザ制御部４０４は、図５のステップＳ１３０５で起動プラグインを変更されたＨＴＭＬデータ（図６参照）に基づいて、外部モニタ用レンダラー４１０を呼び出す。そして、ブラウザ制御部４０４は、外部モニタ用レンダラー４１０に対し、ＨＴＭＬデータを渡して、ウェブページのレンダリングを開始するように指示する。この指示を受けて外部モニタ用レンダラー４１０には、外部モニタ５００のウェブページ表示部分のサイズ（解像度）を取得する。

そして、ステップＳ１４０３で、外部モニタ用レンダラー４１０は、外部モニタ５００にウェブページを表示するためのレンダリングを行う。このレンダリングは、取得した外部モニタ５００のウェブページ表示部分のサイズに基づき、渡されたＨＴＭＬデータからレンダリングを行って表示データを生成し、外部モニタ用フレームバッファ４１１に書き込むことにより行われる。外部モニタ用フレームバッファ４１１に書き込まれた表示データは、外部モニタインタフェース４１２および無線通信回線６００を介して外部モニタ５００に出力され、外部モニタ５００に表示される。

そして、ステップＳ１４０４で、外部モニタ用レンダラー４１０は、図５のステップＳ１３０４と同様の手法により、ウェブページに動画が含まれるか否かを判断する。

ウェブページに動画が含まれる場合には（Ｓ１４０４：ＮＯ）、ステップＳ１４０５で、外部モニタ用レンダラー４１０は、図５のステップＳ１３０９における本体用レンダラー４０５の動作と同様に、バッファ転送部４０８の起動を試みるとともに、バッファ転送部４０８の動作に必要な各種設定を試みる。

具体的には、以下の通りである。まず、外部モニタ用レンダラー４１０は、外部モニタ５００のウェブページの表示領域における動画の表示領域の位置と、動画バッファ４１１ａのアドレスとを計算する。そして、外部モニタ用レンダラー４１０は、ＨＴＭＬデータのＯＢＪＥＣＴタグを解析し、ＯＢＪＥＣＴタグのＣＬＡＳＳＩＤ属性に記述されているクラスＩＤに対応するプラグインを起動する。本実施の形態では、図６で説明したように、バッファ転送部４０８のクラスＩＤが記述されているので、外部モニタ用レンダラー４１０は、このクラスＩＤに対応するプラグインであるバッファ転送部４０８の起動を試みる。外部モニタ用レンダラー４１０は、バッファ転送部４０８を起動する際に、「元のクラスＩＤ（または元のＭＩＭＥタイプ）」、「動画の表示領域の位置およびサイズ」、「外部モニタ用フレームバッファ内の動画データのアドレス（動画バッファのアドレス）」、「動画ファイルのアドレス」、ＰＡＲＡＭタグおよびＯＢＪＥＣＴタグの属性、ＥＭＢＥＤタグの属性を、バッファ転送部４０８にパラメータとして指定することを試みる。

バッファ転送部４０８は、図５のステップＳ１３０９で既に起動しているため、ステップＳ１４０５では起動動作は行わない。また、バッファ転送部４０８は、共通動画デコーダ４０９でデコード処理が行われている動画を指定して、共通動画デコーダ４０９の起動が指示された場合には、その指示に対しては、共通動画デコーダ４０９の起動を行わないように設定されている。したがって、ステップＳ１４０５では、実際には、バッファ転送部４０８の起動および共通動画デコーダの起動は行われず、本体表示部４０７での動画再生は、そのまま継続されることになる。

そして、ステップＳ１４０６で、バッファ転送部４０８は、外部モニタ用レンダラー４１０により指定された「動画バッファのアドレス」を内部に保持する。

そして、ステップＳ１４０７で、バッファ転送部４０８は、本体用フレームバッファ４０６の動画バッファ４０６ａから、外部モニタ用フレームバッファ４１１の動画バッファ４１１ａへと、デコードされた動画データを転送する処理を開始する。具体的には、バッファ転送部４０８は、図５のステップＳ１３１０で記憶した動画バッファ４０６ａのアドレスから、ステップＳ１４０６で記憶した動画バッファ４１１ａのアドレスへと、動画データを転送する。この結果、外部モニタ用フレームバッファ４１１の動画バッファ４１１ａには、本体用フレームバッファ４０６の動画バッファ４０６ａと同一の動画データが格納される。

これにより、ステップＳ１４０８で、外部モニタ５００における動画の表示が開始され、ポータブル端末４００は、外部出力処理を終了して図４の処理に戻る。また、ウェブページに動画が含まれない場合は（Ｓ１４０４：ＹＥＳ）、ポータブル端末４００は、ステップＳ１４０５〜Ｓ１４０８の処理を行うことなく、外部出力処理を終了して図４の処理に戻る。

このようにして、ポータブル端末４００は、動画が含まれるウェブページを外部モニタ５００で表示する際に、本体用フレームバッファ４０６に格納された動画データを、外部モニタ用フレームバッファ４１１に転送し、外部モニタ５００での動画再生に用いることができる。

以下、画像表示システム１００の全体動作の一例について説明する。ここでは、動画を含むウェブページを、本体表示部４０７と外部モニタ５００とで表示する場合について説明する。

図１１は、動画を含むウェブページが、本体表示部４０７で表示されるまでの画像表示システム１００の全体動作を示すシーケンス図である。また、図１２は、本体表示部４０７で表示されているウェブページが、外部モニタ５００で表示されるまでの画像表示システム１００の全体動作を示すシーケンス図である。図１１および図１２において、長方形で囲われた処理は、装置部が実行する処理を示し、細線は、装置部から出力される関数の呼び出し信号を示し、太線は、パケットが発生する通信信号を示す。

図１１において、処理２０１０および信号２０２０は、図５のステップＳ１３０１に対応している。処理２０１０は、ユーザがリンクを指定する処理であり、信号２０２０は、共通パーザ４０３を起動するメッセージである。

信号２０３０〜２０７０は、図５のステップＳ１３０２に対応している。信号２０３０は、共通パーザ４０３が、ＩＰ接続インタフェース４０２に対してウェブページ要求を行わせるために、ＩＰ接続インタフェース４０２を呼び出す信号である。信号２０３０は、具体的には、共通パーザ４０３がウェブページを取得するための、ｈｔｔｐ（hypertext transfer protocol）要求が格納されたパケットデータである。信号２０４０は、ＩＰ接続インタフェース４０２が、ウェブサーバ２００に対してウェブページを要求する信号である。信号２０４０は、具体的には、例えば、ＨＴＴＰのＧＥＴメッセージやＰＯＳＴメッセージである。信号２０５０は、信号２０４０のウェブページ要求に対するウェブサーバ２００のウェブページ応答であり、ウェブページのＨＴＭＬデータが含まれる。信号２０６０は、ウェブページ応答を検出したＩＰ接続インタフェース４０２が、共通パーザ４０３に対して、ウェブページ応答を検出した旨を通知するメッセージまたはイベントである。そして、信号２０７０は、共通パーザ４０３がブラウザ制御部４０４を起動するための呼び出し信号である。

信号２０８０〜２１００は、図５のステップＳ１３０７に対応する。信号２０８０は、ブラウザ制御部４０４が本体用レンダラー４０５を起動するための呼び出し信号である。信号２０９０は、本体用レンダラー４０５が、レンダリングの結果として生成した表示データを、本体用フレームバッファ４０６に書き込むための信号である。信号２１００は、本体用フレームバッファ４０６に書き込まれた表示データを、本体表示部４０７に表示するために出力される信号である。

信号２１１０は、図５のステップＳ１３０９に対応する。信号２１１０は、本体用レンダラー４０５がバッファ転送部４０８を起動するためのメッセージである。

信号２１２０は、図５のステップＳ１３１０に対応する。信号２１２０は、バッファ転送部４０８が共通動画デコーダ４０９を起動するメッセージである。

信号２１３０〜２１５０は、図５のステップＳ１３１１に対応する。信号２１３０は、共通動画デコーダ４０９が動画ファイルのアドレスに基づいてウェブサーバ２００に対して出力する、動画データの取得要求である。信号２１４０は、信号２１３０（動画データの取得要求）に対する応答として、ウェブサーバ２００が出力する動画データである。信号２１５０は、動画データをデコードした共通動画デコーダ４０９が、本体用フレームバッファ４０６の動画バッファ４０６ａに表示データを書き込むための信号である。

信号２１６０は、図５のステップＳ１３１２に対応する。信号２１６０は、本体表示部４０７で動画再生を行うために、本体用フレームバッファ４０６の動画バッファ４０６ａに格納された動画データを本体表示部４０７に出力する信号である。

ここまでの動作により、本体表示部４０７において、動画を含むウェブページの表示が開始される。

図１２において、処理３０１０および信号３０２０は、図１０のステップＳ１４０１に対応する。処理３０１０は、ユーザが外部出力を指定する処理であり、信号３０２０は、ブラウザ制御部４０４を起動するためのメッセージである。

信号３０３０〜３０６０は、図１０のステップＳ１４０３に対応する。信号３０３０は、ブラウザ制御部４０４が外部モニタ用レンダラー４１０を起動するメッセージである。信号３０４０は、外部モニタ用レンダラー４１０がレンダリングの結果として生成した表示データを、外部モニタ用フレームバッファ４１１に書き込む信号である。信号３０５０は、外部モニタ用フレームバッファ４１１に書き込まれた表示データを外部モニタ５００に表示するために、外部モニタインタフェース４１２に出力される信号である。信号３０６０は、表示データを外部モニタ５００で表示するために、更に無線通信回線６００上に出力される信号である。

信号３０７０は、図１０のステップＳ１４０５に対応する。信号３０７０は、外部モニタ用レンダラー４１０が、バッファ転送部４０８を起動するためのメッセージである。

信号３０８０は、図１０のステップＳ１４０７に対応する。信号３０８０は、バッファ転送部４０８が、本体用フレームバッファ４０６の動画バッファ４０６ａに格納された動画データを取得し、外部モニタ用フレームバッファ４１１の動画バッファ４１１ａに書き込みを行うための信号である。

信号３０９０、３１００は、図１０のステップＳ１４１０に対応する。信号３０９０は、外部モニタ用フレームバッファ４１１の表示データを、外部モニタインタフェース４１２に出力するための信号である。信号３１００は、表示データを外部モニタ５００で表示するために、更に無線通信回線６００上に出力される信号である。

このような動作により、外部モニタ５００においても、動画を含むウェブページの表示が開始される。

以上説明したように、本実施の形態によれば、バッファ転送部４０８が、本体用フレームバッファ４０６から外部モニタ用フレームバッファ４１１へと、デコード済みの動画データを転送する。これにより、外部モニタ５００用の表示データを生成するために動画デコーダを別個に設けなくて済み、機能部の重複および処理の重複を回避して、本体表示部４０７と外部モニタ５００とで動画コンテンツを表示することができる。また、本体表示部４０７の動画と外部モニタ５００の動画とを同期させて再生することができる。すなわち、負荷の増大を抑えた状態で、外部モニタ５００の表示を追加し、かつ外部モニタ５００の動画の表示タイミングを、本体表示部４０７において再生されている時点とほぼ一致させることができる。

また、本体用フレームバッファ４０６から外部モニタ用フレームバッファ４１１への動画データの転送を、バッファ転送部４０８の追加と、ブラウザ制御部４０４におけるＨＴＭＬデータの書き換えとによって、実現することができる。これにより、既存の共通パーザ、レンダラー、フレームバッファ、および動画デコーダには特別な変更を加えることなく、上記効果を得ることができる。

（実施の形態２）
本発明の実施の形態２では、ポータブル端末は、複数のディスプレイで動画の表示領域（以下「動画表示領域」という）の大きさが異なるときに、最も大きい動画表示領域を持つディスプレイのための動画デコードをまず行い、デコードされた動画データを他のディスプレイで使用する。

図１３は、本発明の実施の形態２に係る表示制御装置を含む画像表示システムの構成を示すシステム図であり、実施の形態１の図１に対応するものである。図１と同一部分には同一符号を付し、これについての説明を省略する。

図１３に示すように、画像表示システム８００は、図１のポータブル端末４００に代えて、ポータブル端末４００とは異なる構成のポータブル端末９００を有する。外部モニタ５００の解像度は、ポータブル端末９００の本体表示部４０７の解像度よりも高いものとする。

ポータブル端末９００は、動画を含むウェブページを取得したとき、解像度のより高い外部モニタ５００用にデコードされた動画データを、縮小処理を施した上で、本体ディスプレイ４００ａでの動画表示に用いる。すなわち、ポータブル端末９００は、モニタディスプレイ５００ｂで表示するための、サイズの大きな動画５００ｃを先に生成し、その後、本体ディスプレイ４００ａで表示されるサイズの小さな動画４００ｃを生成する。

図１４は、ポータブル端末９００の構成を示すブロック図であり、実施の形態１の図２に対応するものである。図２と同一部分には同一符号を付し、これについての説明を省略する。

図１４に示すように、ポータブル端末９００は、図２のブラウザ制御部４０４およびバッファ転送部４０８とは異なる動作を行うブラウザ制御部９０４およびバッファ転送部９０８を有する。また、共通動画デコーダ４０９は、外部モニタ用フレームバッファ４１１に接続されている。

ブラウザ制御部９０４は、実施の形態１のブラウザ制御部４０４の機能に加えて、最も大きい動画表示領域を有するディスプレイのフレームバッファを動画データの転送元に指定し、他のフレームバッファを転送先に指定する情報を、ＨＴＭＬデータに追加する機能を有する。また、ブラウザ制御部９０４は、転送の際に動画データに施すべき画像編集処理を指定する情報を、ＨＴＭＬデータに追加する機能を有する。

バッファ転送部９０８は、実施の形態１のバッファ転送部４０８と同様の機能を有しているが、ＨＴＭＬデータに含まれるＰＡＲＡＭタグのＤｉｒｅｃｔｉｏｎパラメータに基づいて、共通動画デコーダ４０９の起動を行う。Ｄｉｒｅｃｔｉｏｎパラメータについては、後述する。

このようなポータブル端末９００によれば、動画を含むウェブページを取得したときに、外部モニタ５００用にデコードされた動画データを、縮小処理を施した上で、本体ディスプレイ４００ａでの動画表示に用いることができる。

次に、上記構成を有するポータブル端末９００の全体動作について説明する。

図１５は、ポータブル端末９００の全体動作を示すフローチャートであり、実施の形態１の図４、図５、および図１０に対応するものである。図４、図５、および図１０と同一部分には同一ステップ番号を付し、これについての説明を省略する。

ステップＳ１３０４で、ＨＴＭＬデータに動画が含まれるかＨＴＭＬデータに動画が含まれると判断されると（Ｓ１３０４：ＮＯ）、ステップＳ２３０５で、ブラウザ制御部９０４は、ＨＴＭＬデータに対し、動画再生のための起動プラグインの変更を行う。ここでのＨＴＭＬ書き換えの目的は、実施の形態１の転送方法の指定に加えて、動画データの転送元と転送先とを指定することである。ディスプレイのサイズが異なると、ディスプレイ上のウェブブラウザのウィンドウのサイズは異なるため、ディスプレイの解像度のみに基づいて動画表示領域の大小をバッファ転送部９０８の側で判断することは難しい。すなわち、バッファ転送部９０８の側で、動画デコード処理を行う側のディスプレイと、動画データの転送を受ける側のディスプレイを決定することは難しい。

そこで、ブラウザ制御部９０４は、動画データの転送元および転送先を決め、決定結果をバッファ転送部９０８に通知するような内容に、ＨＴＭＬデータを書き換える。具体的には、ブラウザ制御部９０４は、複数のディスプレイのウィンドウサイズを保持し、各ディスプレイのウィンドウサイズを比較して、最も大きなウィンドウサイズのディスプレイのフレームバッファを、転送元に決定する。ここでは、ブラウザ制御部９０４は、外部モニタ５００で表示する際のブラウザのウィンドウサイズを保持し、本体表示部４０７で表示する際のブラウザのウィンドウサイズと比較する。本実施の形態では、上述の通り、外部モニタ５００のブラウザの動画表示領域のほうが、本体表示部４０７の動画表示領域よりも大きい場合を想定している。したがって、ここでは、ブラウザ制御部９０４は、外部モニタ用フレームバッファ４１１の動画バッファ４１１ａを転送元に決定し、本体用フレームバッファ４０６の動画バッファ４０６ａを転送先に決定する。

また、ブラウザ制御部９０４は、転送の際の動画データの縮小比を決定し、決定結果をバッファ転送部９０８に通知するような内容に、ＨＴＭＬデータを書き換える。具体的には、ブラウザ制御部９０４は、転送元に対応するウィンドウサイズと転送先に対応するウィンドウサイズとの比を、ＷＩＤＴＨ属性およびＨＥＩＧＨＴ属性に設定する。

このウィンドウサイズの比の決定は、例えば、外部ディスプレイの垂直方向の画素数に対する本体画面の垂直方向の画素数を計算する手法や、外部ディスプレイの水平方向の画素数に対する本体画面の水平方向の画素数を計算する手法により行われる。ここでは、ブラウザ制御部９０４は、動画の表示領域のサイズ（解像度）を、縦横共に４０％に縮小する処理を指定することを決定するものとする。

図１６は、図３に示すＨＴＭＬデータに対し、起動プラグインの変更が行われた後の、本体表示部４０７用のＨＴＭＬデータの一例の抜粋を示す図であり、図６に対応するものである。図６と対応する部分には同一符号を付し、これについての説明を省略する。また、図３と異なる部分、つまり変更部分に、下線を付している。

ブラウザ制御部９０４は、ＰＡＲＡＭタグ７３４を追加するとともに、ＯＢＪＥＣＴタグ７１１を書き換えて、本体表示部４０７用のＨＴＭＬデータ７３０を生成する。

具体的には、ブラウザ制御部９０４は、図１６に示すように、Ｄｉｒｅｃｔｉｏｎパラメータに、ｄｅｓｔｉｎａｔｉｏｎという値を指定するＰＡＲＡＭタグ７３４を追加する。また、ブラウザ制御部９０４は、ＯＢＪＥＣＴタグ７１１のＣＬＡＳＳＩＤ属性を図６と同様に書き換えるとともに、ＷＩＤＴＨ属性およびＨＥＩＧＨＴ属性を、４０％に書き換える。ｄｅｓｔｉｎａｔｉｏｎを指定するのは、本体用フレームバッファ４０６側が転送先に決定されたためである。また、ＷＩＤＴＨ属性およびＨＥＩＧＨＴ属性が４０％なのは、動画データを転送する際に、動画データのサイズを４０％にする縮小処理を行うためである。

図１７は、図３に示すＨＴＭＬデータに対し、起動プラグインの変更が行われた後の、外部モニタ５００用のＨＴＭＬデータの一例の抜粋を示す図であり、図６に対応するものである。図６と対応する部分には同一符号を付し、これについての説明を省略する。また、図３と異なる部分、つまり変更部分に、下線を付している。

ブラウザ制御部９０４は、本体表示部４０７用のＨＴＭＬデータ７３０と同様にＯＢＪＥＣＴタグ７１１を書き換える。一方で、ブラウザ制御部９０４は、本体表示部４０７用のＨＴＭＬデータ７３０とは異なり、Ｄｉｒｅｃｔｉｏｎパラメータにｓｏｕｒｃｅを指定するＰＡＲＡＭタグ７４４を追加して、外部モニタ５００用のＨＴＭＬデータ７４０を生成する。ｓｏｕｒｃｅを指定するのは、外部モニタ５００側が転送先に決定されたためである。

このようなＨＴＭＬデータの書き換えを行った後、ブラウザ制御部９０４は、ステップＳ１３０６で、本体表示部４０７用のＨＴＭＬデータ（図１６参照）に基づいて、本体用レンダラー４０５に対してウェブページのレンダリングを行うことを指示する。そして、ステップＳ１３０６〜Ｓ１３０８の処理により、表示データが本体用フレームバッファ４０６に格納される。

ウェブページに動画が含まれる場合には（Ｓ１３０８：ＮＯ）、ステップＳ２３０９で、本体用レンダラー４０５は、図５のステップＳ１３０９と同様に、パラメータを指定してバッファ転送部９０８を起動する。このとき、本体用レンダラー４０５は、バッファ転送部９０８に対するパラメータ指定に、ＨＴＭＬデータに記述されたＤｉｒｅｃｔｉｏｎパラメータの指定を含める。

バッファ転送部９０８は、Ｄｉｒｅｃｔｉｏｎパラメータがｓｏｕｒｃｅのときには、共通動画デコーダ４０９を起動させるが、Ｄｉｒｅｃｔｉｏｎパラメータがｄｅｓｔｉｎａｔｉｏｎのときには、共通動画デコーダ４０９を起動させないようになっている。本体表示部４０７用のＨＴＭＬデータ（図１６参照）では、Ｄｉｒｅｃｔｉｏｎパラメータはｄｅｓｔｉｎａｔｉｏｎとなっている。したがって、ステップＳ２３０９では、バッファ転送部９０８は、共通動画デコーダ４０９を起動させずに、ステップＳ１３１０で、本体用レンダラー４０５により指定された「動画バッファのアドレス」を内部に保持する。

そして、ステップＳ２４０５で、ブラウザ制御部９０４は、外部モニタ５００用のＨＴＭＬデータ（図１７参照）に基づいて、外部モニタ用レンダラー４１０に対してウェブページのレンダリングを行うことを指示する。ただし、外部モニタ５００でのウェブページの表示が指定されていない場合には、ブラウザ制御部９０４は、外部モニタ用レンダラー４１０に対して、内部的にのみレンダリングを行い、レンダリングした結果を表示しないように指定する。この結果、外部モニタ用レンダラー４１０は、図５のステップＳ１４０５と同様に、パラメータを指定してバッファ転送部９０８を起動する。このとき、外部モニタ用レンダラー４１０は、バッファ転送部９０８に対するパラメータ指定に、ＨＴＭＬデータに記述されたＤｉｒｅｃｔｉｏｎパラメータの指定を含める。そして、バッファ転送部９０８は、ステップＳ１４０６で、外部モニタ用レンダラー４１０により指定された「動画バッファのアドレス」を内部に保持する。また、ブラウザ制御部９０４によって、レンダリングした結果を表示しないように指定されているため、外部モニタ用フレームバッファ４１１のデータは、外部モニタインタフェース４１２に対して出力されない。

そして、ステップＳ２３１１で、バッファ転送部９０８は、外部モニタ５００用のＨＴＭＬデータ（図１７参照）のＤｉｒｅｃｔｉｏｎパラメータはｓｏｕｒｃｅとなっていることから、図５のステップＳ１３１１と同様に、共通動画デコーダ４０９を起動させる。具体的には、バッファ転送部９０８は、本体用レンダラー４０５により指定された「元のクラスＩＤ」または「元のＭＩＭＥタイプ」から、起動すべきプラグインを判断する。また、バッファ転送部９０８は、他のパラメータについては、外部モニタ用レンダラー４１０により指定されたパラメータを用いる。これにより、外部モニタ５００の大きい動画表示領域に合わせた動画デコードが行われ、デコードされた動画データが、外部モニタ用フレームバッファ４１１の動画バッファ４１１ａに格納される。

そして、ステップＳ２４０７で、バッファ転送部９０８は、Ｄｉｒｅｃｔｉｏｎパラメータの指定に従い、動画データの転送を開始する。すなわち、バッファ転送部９０８は、外部モニタ用フレームバッファ４１１の動画バッファ４１１ａから、本体用フレームバッファ４０６の動画バッファ４０６ａへと、デコードされた動画データを転送する処理を開始する。また、この転送処理において、バッファ転送部９０８は、ＷＩＤＴＨ属性およびＨＥＩＧＨＴ属性の指定に従い、動画データの縮小処理を行う。具体的には、バッファ転送部９０８は、一旦、外部モニタ用フレームバッファ４１１の動画バッファ４１１ａから動画データを取得した後、その動画データに対する縮小処理を行い、縮小処理の結果得られた動画データを、本体用フレームバッファ４０６の動画バッファ４０６ａに出力する。縮小処理に必要な動画領域のパラメータは、バッファ転送部９０８の起動の際に取得した値が用いられる。

そして、ステップＳ１３１２で、動画デコードが行われる。外部モニタ５００でのウェブページの表示が指定されていない場合には、上述の通り、外部モニタ５００には表示データを表示しないように指定されるため、本体表示部４０７にのみウェブページが表示される。

このようにして、ポータブル端末９００は、動画表示領域の大きい外部モニタ５００に合わせて動画データをデコードし、デコードされた動画データを、動画表示領域の小さい本体表示部４０７での動画表示に用いることができる。

以下、画像表示システム８００の全体動作の一例について説明する。ここでは、動画を含むウェブページを、本体表示部４０７と外部モニタ５００とで表示する場合について説明する。

図１８は、動画を含むウェブページが、本体表示部４０７および本体表示部４０７で表示されるまでの画像表示システム８００の全体動作を示すシーケンス図であり、実施の形態１の図１１および図１２に対応するものである。図１８では、図１１の信号２０７０以前の部分は図１１と同様なので、ここではその図示および説明を省略する。

図１８において、信号４０１０〜４０３０は、図１５のステップＳ１３０７に対応する。信号４０１０は、ブラウザ制御部９０４が本体用レンダラー４０５を起動するための呼び出し信号である。信号４０２０は、本体用レンダラー４０５がレンダリングの結果として生成した表示データを、本体用フレームバッファ４０６に書き込むための信号である。信号４０３０は、本体用フレームバッファ４０６に書き込まれた表示データを、本体表示部４０７に表示するために出力される信号である。

信号４０４０は、図１５のステップＳ２３０９に対応する。信号４０４０は、これは本体用レンダラー４０５がバッファ転送部９０８を起動するためのメッセージである。

信号４０５０、４０６０は、図１５のステップＳ２４０５に対応する。信号４０５０は、ブラウザ制御部９０４が外部モニタ用レンダラー４１０を起動するメッセージである。信号４０６０は、外部モニタ用レンダラー４１０がバッファ転送部９０８を起動するメッセージである。

信号４０７０〜４１００は、図１５のステップＳ２３１１に対応する。信号４０７０は、バッファ転送部９０８が共通動画デコーダ４０９を起動するためのメッセージである。信号４０８０は、共通動画デコーダ４０９が、動画ファイルのアドレスに基づいて、ウェブサーバ２００に対して出力する、動画データの取得を要求する信号である。信号４０９０は、信号４０８０に対してウェブサーバ２００が出力する動画データである。信号４１００は、共通動画デコーダ４０９が、デコードした動画データを、外部モニタ用フレームバッファ４１１の動画バッファ４１１ａに書き込むための信号である。

信号４１１０は、ステップＳ２４０７に対応する。信号４１１０は、バッファ転送部９０８が、外部モニタ用フレームバッファ４１１の動画バッファ４１１ａから、本体用フレームバッファ４０６の動画バッファ４０６ａへと、動画データを転送するための信号である。

信号４１２０は、ステップＳ１３１２に対応する。信号４１２０は、表示データを本体表示部４０７に表示するための信号である。

このような動作により、外部モニタ５００に合わせてデコードされた動画データが、本体表示部４０７での動画表示に用いられる。

このように、本実施の形態によれば、ブラウザ制御部９０４は、複数のディスプレイで表示されるブラウザの動画領域の大きさを比較し、最大の動画領域を持つディスプレイに対応したフレームバッファを、動画データの転送元に決定する。そして、バッファ転送部９０８は、転送元のフレームバッファに格納されたデコード後の動画データを、転送先のフレームバッファに転送する。これにより、複数の異なる大きさのブラウザに動画を表示する場合に、複数のデコード処理を行うことなく、どのディスプレイにおいても画質の低下を防ぐことができる。

なお、以上説明した各実施の形態では、ウェブページを表示する２つのディスプレイが、ポータブル端末のディスプレイと外部モニタのディスプレイである場合について説明したが、これに限定されるものではない。ポータブル端末に備えられた２つのディスプレイや、２つの外部モニタに、ウェブページを表示させるようにしても良い。また、３つ以上のディスプレイにウェブページを表示させるようにしても良い。この場合には、動画データの転送元となるフレームバッファと、動画データの転送先となるフレームバッファとの間に、バッファ転送部を配置するようにすれば良い。

ポータブル端末として、無線通信によって外部モニタおよびＩＰ網に接続する無線通信端末を想定したが、据置型で有線ネットワークを使って外部モニタおよびＩＰ網と接続する端末としても良い。また、外部モニタ５００との接続を有線通信とする場合には、一般のディスプレイに用いられるＶＧＡ（video graphics array）信号、ＤＶＩ（digital visual interface）、ＨＤＭＩ（high-definition multimedia interface）信号を適用することができる。また、ポータブル端末から外部モニタへの通信回線の帯域に余裕があれば、非圧縮の表示データを伝送するようにしてもよい。

また、ブラウザ制御部で、動画コンテンツごとにウェブページ内で一意な識別子を割り当て、バッファ転送部で、識別子ごとに、プラグインの起動およびデータ転送を行うようにしてもよい。具体的には、バッファ転送部は、動画バッファのアドレスや表示領域等の、バッファ転送に必要なデータを記憶し、外部モニタ用にバッファ転送部が起動されたときに、識別子に対応する本体の動画バッファから、動画データを転送するようにする。これにより、ウェブページに複数の動画コンテンツが含まれる場合でも、外部モニタでデコードを行うための負荷を増加させずに、適切に表示することができる。

また、ウェブページの動画の有無を判断する手法は、実施の形態で説明した手法に限定されない。例えば、ａタグで指定されたリンクが示すファイルの拡張子が、動画ファイルの拡張子に該当するか否かを判断することにより、ウェブページの動画の有無を判断するようにしても良い。

また、動画を再生するプログラムがブラウザとは別に起動される場合には、起動されたプロセスで使用されるフレームバッファにおける動画データの位置を取得し、外部モニタにおける表示プロセスにおいて動画データを取り出して送出する構成としても良い。この場合でも、上記実施の形態と同様に、動画デコードの負荷を削減することができる。

また、アニメーションや、スクリプトを使ったインタラクティブなコンテンツ等、動画以外の動的コンテンツのデータについても、フレームバッファ間での転送を行うようにしても良い。例えば、動画以外のＯＢＪＥＣＴタグまたはＥＭＢＥＤタグを使用したアクティブコンテンツの場合、実施の形態で説明した手法により、動的コンテンツの有無の判断を行い、動的コンテンツの領域の表示データを転送することができる。また、スクリプトによって動作する部分の転送を行う場合には、ＯＢＪＥＣＴタグの代わりに、ＳＣＲＩＰＴタグに基づいて、動的コンテンツの有無を判断し、動的コンテンツの領域の表示データを転送することができる。

また、ウェブページと動画とが、同一のウェブサーバに格納されている場合について説明したが、別々のウェブサーバに格納されていても良い。また、ＨＴＭＬデータの取得は、ＩＰ網以外にも、ＨＴＭＬデータの格納場所からＨＴＭＬデータを取得するプロトコルの各種ネットワークを介して行うことができる

また、ポータブル端末の入力装置は、タッチスクリーンに限定されるものではなく、マウス、タッチパネル、タッチパッド、トラックポイント、およびトラックボール等のポインティングデバイス、キーボード、キースイッチ等、他の入力デバイスを用いることができる。

本発明に係る表示制御装置および表示制御方法は、機能部の重複および処理の重複を回避して、複数のディスプレイで動画コンテンツを表示することができる、表示制御装置および表示制御方法として有用である。

本発明の実施の形態１に係る表示制御装置を含む画像表示システムの構成を示すシステム構成図 実施の形態１に係るポータブル端末の構成を示すブロック図 実施の形態１におけるＨＴＭＬデータの一例の抜粋を示す図 実施の形態１に係るポータブル端末の全体動作を示すフローチャート 実施の形態１における本体表示処理を示すフローチャート 実施の形態１における起動プラグイン変更後のＨＴＭＬデータの一例の抜粋を示す図 実施の形態１における起動プラグイン変更後のＨＴＭＬデータの他の例の抜粋を示す図 実施の形態１における起動プラグイン変更後のＨＴＭＬデータの他の例の抜粋を示す図 実施の形態１における起動プラグイン変更後のＨＴＭＬデータの他の例の抜粋を示す図 実施の形態１における外部出力処理を示すフローチャート 実施の形態１に係る画像表示システムの全体動作を示す第１のシーケンス図 実施の形態１に係る画像表示システムの全体動作を示す第２のシーケンス図 本発明の実施の形態２に係る表示制御装置を含む画像表示システムの構成を示すシステム図 実施の形態２に係るポータブル端末の構成を示すブロック図 実施の形態２に係るポータブル端末の全体動作を示すフローチャート 実施の形態２における本体表示部用のＨＴＭＬデータの一例の抜粋を示す図 実施の形態２における外部モニタ用のＨＴＭＬデータの一例の抜粋を示す図 実施の形態２に係る画像表示システムの全体動作を示すシーケンス図 従来の装置の構成を示すブロック図

符号の説明

１００、８００ 画像表示システム
２００ ウェブサーバ
３００ ＩＰ網
４００、９００ ポータブル端末
４０１ 入力装置
４０２ ＩＰ接続インタフェース
４０３ 共通パーザ
４０４、９０４ ブラウザ制御部
４０５ 本体用レンダラー
４０６ 本体用フレームバッファ
４０７ 本体表示部
４０８、９０８ バッファ転送部
４０９ 共通動画デコーダ
４１０ 外部モニタ用レンダラー
４１１ 外部モニタ用フレームバッファ
４１２ 外部モニタインタフェース
５００ 外部モニタ
６００ 無線通信回線

Claims (9)

1. 動的コンテンツの復号を行い、復号した動的コンテンツを第１のバッファに格納するコンテンツ取得部と、
   前記第１のバッファに格納された前記動的コンテンツを、第２のバッファに転送するバッファ転送部と、
   前記第１のバッファに格納された前記動的コンテンツを第１の表示装置に表示させる第１の表示制御部と、
   前記第２のバッファに格納された前記動的コンテンツを第２の表示装置に表示させる第２の表示制御部と、を備え、
   前記コンテンツ取得部は、
   動的コンテンツの復号を行う復号主体を指定する指定情報を入力する情報入力部と、
   動的コンテンツの復号を行う動的コンテンツ復号部と、
   前記指定情報が前記動的コンテンツ復号部を指定するとき、前記指定情報を、前記バッファ転送部を指定する内容に書き換える情報書換部と、を有する、
   表示制御装置。
2. 前記バッファ転送部は、
   前記コンテンツ取得部に対して、前記動的コンテンツ復号部によって復号された動的コンテンツを、前記第１のバッファに格納させる、
   請求項１記載の表示制御装置。
3. 前記コンテンツ取得部は、
   前記指定情報により指定される前記復号主体に対して、動的コンテンツを復号して復号された動的コンテンツを前記第１のバッファに格納する第１の処理、を実行させる第１のレンダリング部と、
   前記指定情報により指定される前記復号主体に対して、動的コンテンツを復号して復号された動的コンテンツを前記第２のバッファに格納する第２の処理、を実行させる第２のレンダリング部と、を更に有し、
   前記バッファ転送部は、
   第１のレンダリング部から前記第１の処理の実行を指示されたとき、前記動的コンテンツ復号部に対して、前記第１の処理を実行させる、
   請求項２記載の表示制御装置。
4. 前記指定情報は、前記動的コンテンツを表示するためのウェブページを記述するコンテンツデータに含まれる、
   請求項３記載の表示制御装置。
5. 前記情報書換部は、
   前記コンテンツデータが複数の動的コンテンツを同時表示することを記述するとき、動的コンテンツごとに識別情報を割り当て、
   前記バッファ転送部は、
   前記識別情報に対応付けて、前記動的コンテンツの転送を行う、
   請求項４記載の表示制御装置。
6. 前記バッファ転送部は、
   転送する前記動的コンテンツに対して、縮小処理を行う、
   請求項１記載の表示制御装置。
7. 前記縮小処理が行われていない動的コンテンツの前記第１の表示装置における表示領域は、前記縮小処理が行われていない動的コンテンツの前記第２の表示装置における表示領域よりも大きい、
   請求項６記載の表示制御装置。
8. 複数の表示装置に接続する表示装置接続部、を更に有し、
   前記情報書換部は、
   前記表示装置接続部により接続された複数の表示装置のうち、前記縮小処理が行われていない動的コンテンツの表示領域が最も大きい表示装置を、前記第１の表示装置とし、他の表示装置を、前記第２の表示装置とする、
   請求項７記載の表示制御装置。
9. 動的コンテンツ復号部を用いて動的コンテンツを復号し、復号された動的コンテンツを、第１の表示装置で表示を行うための第１のバッファに格納するステップと、
   バッファ転送部を用いて前記第１のバッファに格納された前記動的コンテンツを、第２の表示装置で表示を行うための第２のバッファに転送するステップと、
   動的コンテンツの復号を行う復号主体を指定する指定情報を取得するステップと、
   前記指定情報が前記動的コンテンツ復号部を指定するとき、前記指定情報を、前記バッファ転送部を指定する内容に書き換えるステップと、
   を有する表示制御方法。

Images