JP2012043140A - Ｗｅｂページ閲覧システム及び中継サーバ - Google Patents

Abstract

【課題】携帯端末がＰＣ向けＷｅｂページの閲覧機能を有していなくても、Ｗｅｂページのデザインを崩すことなくＷｅｂページを閲覧することができ、特にリッチコンテンツが組み込まれたＷｅｂページであっても閲覧及び操作を可能にする。
【解決手段】中継サーバによりＷｅｂページを閲覧用画像データに変換して（画像化して）携帯端末に提供する。中継サーバは、Ｗｅｂページにリッチコンテンツが組み込まれている場合、そのリッチコンテンツ領域を抽出し（ステップＳ９０）、リッチコンテンツ領域の画像の変化を検出する（ステップＳ９１〜Ｓ９４）。そして、画像変化が検出されると、現在のＷｅｂページを閲覧用画像データに変換して携帯端末に送信し、画面更新させる（ステップＳ９５、Ｓ９６）。
【選択図】 図１１

Description

本発明はＷｅｂページ閲覧システム及び中継サーバに係り、特に携帯電話等の画面サイズやダウンロード可能なファイルサイズが制限される携帯端末においてＰＣ向けＷｅｂページを閲覧するための技術に関する。

近年、携帯電話でＷｅｂページを閲覧する機会が多く見受けられる。しかしながら、パーソナルコンピュータ（ＰＣ）向けＷｅｂページに加え、携帯電話向けＷｅｂページも作るのは大きな手間でコストがかかることから、Ｗｅｂページ制作側は携帯電話向けＷｅｂページの制作を避ける傾向にあり、ユーザが閲覧したいＷｅｂページに携帯電話向けのＷｅｂページが用意されていないことが少なくない。

画面サイズやダウンロード可能なファイルサイズがＰＣと比べて劣る携帯電話においてＰＣ向けＷｅｂページを閲覧する場合に、コンテンツファイルを分割して受信させ、複数のページにわたって表示させることが考えられるが、ＰＣでＷｅｂページを閲覧した場合と携帯電話でＷｅｂページを閲覧した場合とで、見た目の差異が生じてしまう。

また、携帯電話向けのマークアップ言語に変換することも考えられるが、デザイン崩れの問題が起こりやすい。

このような課題に対し、ＰＣ向けＷｅｂページを画像化してクライアント端末に表示する方法が提案されている。例えば、特許文献１では、画像配信サーバにおいて取得したＷｅｂページのＨＴＭＬ(Hyper Text Markup Language）文書等の構成要素からＷｅｂページを作成し、作成したＷｅｂページをビットマップ等の画像データに変換し、クライアント端末に送信する。この画像データを表示したクライアント端末は、ユーザがポインティングデバイスを用いて表示された文字列等をクリックすると、そのクリック位置座標データと表示されているＷｅｂページのＵＲＬ(Uniform Resource Locator)とを画像配信サーバに送信する。画像配信サーバは、そのＷｅｂページの構成要素から、送られてきたクリック位置座標に対応するリンクポインタが存在しているかどうかを検査し、リンクポインタが存在している場合に、そのリンクポインタが示すＵＲＬが指定するＷｅｂサーバにアクセスする。

特許文献１の技術によれば、Ｗｅｂブラウザを実装していないクライアント端末であっても、Ｗｅｂページの閲覧が可能となる。

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

近年、動画（ビデオ映像、アニメーション等）を含む表現力豊かなコンテンツ（リッチコンテンツ）が組み込まれたＷｅｂページが多く見られるようになった。リッチコンテンツの代表的なものとしては、アドビシステムズ社のアドビ・フラッシュ (Adobe Flash)がある。

特許文献１に記載の発明は、リッチコンテンツを含むＷｅｂページには対応していない。即ち、リッチコンテンツは、クライアントからのＷｅｂページの閲覧要求の有無にかかわらず映像が変化するため、Ｗｅｂページの閲覧要求時に取得したＷｅｂページを画像化して（静止画にして）クライアントに提供してもＷｅｂブラウザでのＷｅｂページのリッチコンテンツとユーザがクライアント端末で見ているリッチコンテンツとは異なるものとなる。尚、ユーザがクライアント端末で見ているリッチコンテンツは、実際には静止画であるため、ユーザはリッチコンテンツとは認識できず、リッチコンテンツの特徴が減殺される。

また、リッチコンテンツの画像とＵＲＬとがリンクされている場合に、クライアント端末に表示されているリッチコンテンツの画像をクリックすると、表示されているリッチコンテンツの画像とは無関係なＵＲＬによりＷｅｂサーバがアクセスされるおそれがあり、ユーザが意図しているＷｅｂページを閲覧することができないという問題もある。

本発明はこのような事情に鑑みてなされたもので、携帯端末がＰＣ向けＷｅｂページの閲覧機能を有していなくても、Ｗｅｂページのデザインを崩すことなくＷｅｂページを閲覧することができ、特にリッチコンテンツが組み込まれたＷｅｂページであってもＰＣと同様にＷｅｂページの閲覧及び操作が可能なＷｅｂページ閲覧システム及び中継サーバを提供することを目的とする。

前記目的を達成するために請求項１に係る発明は、画像の表示が可能な携帯端末と、Ｗｅｂサーバが提供するＷｅｂページを画像化して前記携帯端末に提供する中継サーバとからなり、前記携帯端末によりＷｅｂページを閲覧させるＷｅｂページ閲覧システムであって、前記中継サーバは、前記携帯端末からＷｅｂページの閲覧要求があると、前記閲覧要求されたＷｅｂページにリッチコンテンツが含まれているか否かを判別し、リッチコンテンツが含まれている場合には、そのリッチコンテンツが表示されるリッチコンテンツ領域を抽出する抽出手段と、前記抽出したリッチコンテンツ領域におけるリッチコンテンツの変化を検出する検出手段と、前記閲覧要求に応じてＷｅｂページを前記携帯端末での閲覧用画像データに変換する画像変換手段であって、前記検出手段により前記リッチコンテンツ領域におけるリッチコンテンツの変化が検出されると、画面更新のためにＷｅｂページを前記閲覧用画像データに変換する画像変換手段と、前記画像変換手段により変換した閲覧用画像データを前記携帯端末に送信する画像データ送信手段と、を備えたことを特徴としている。

請求項１に係る発明によれば、前記中継サーバによりＷｅｂページを画像化して携帯端末に提供するため、Ｗｅｂページのデザインが崩れることなく、そのまま携帯端末で閲覧することができる。この場合、前記携帯端末は画像の表示機能があればよく、ＰＣ向けＷｅｂページの閲覧機能がなくてもよい。また、Ｗｅｂページにリッチコンテンツが組み込まれている場合には、そのリッチコンテンツの変化を検出し、その変化に対応してＷｅｂページを閲覧用画像データに変換するようにしたため、リッチコンテンツの変化に対応した画面更新を行うことができる。これにより、ＰＣと同様にＷｅｂページの閲覧及び操作が可能になる。

請求項２に示すように請求項１に記載のＷｅｂページ閲覧システムにおいて、前記検出手段は、前記リッチコンテンツ領域の画像を所定の間隔で取得する画像取得手段と、前記画像取得手段により今回取得した画像と前回取得した画像とを比較し、両画像間の変化量を検出する変化量検出手段と、前記検出された変化量に基づいてリッチコンテンツの変化を判断する判断手段と、からなることを特徴としている。

請求項３に示すように請求項２に記載のＷｅｂページ閲覧システムにおいて、前記判断手段は、前記変化量検出手段により検出された変化量が所定の閾値を越えると、リッチコンテンツが変化したと判断することを特徴としている。例えば、リッチコンテンツが動画の場合、シーンの切り替わり等を判断して画面更新を行うことができる。また、リッチコンテンツが静止画をスライドショー表示している場合、静止画の切り替わりを判断して画面更新を行うことができる。

請求項４に示すように請求項２に記載のＷｅｂページ閲覧システムにおいて、前記判断手段は、前記変化量検出手段により検出された変化量が検出された後、所定時間変化が検出されなくなると、リッチコンテンツが変化したと判断することを特徴としている。リッチコンテンツが動画の場合、動画の停止時に画面更新を行うことができる。

請求項５に示すように請求項２から４のいずれかに記載のＷｅｂページ閲覧システムにおいて、前記変化量検出手段は、前記画像取得手段により今回取得した画像と前回取得した画像とをそれぞれ縮小させる縮小手段と、前記縮小された画像間の相関値を、前記画像間の変化量を示す評価値として算出する算出手段と、を有することを特徴としている。画像を縮小することにより、前記算出手段による評価値の算出時間を短縮することができる。

請求項６に示すように請求項１に記載のＷｅｂページ閲覧システムにおいて、前記検出手段は、前記リッチコンテンツ領域の画像を所定の間隔で取得する画像取得手段と、前記リッチコンテンツ領域におけるリッチコンテンツの変化後の画像を記憶する記憶手段と、前記画像取得手段により取得された画像と前記記憶手段に記憶された画像とを比較し、両画像の一致度を検出する一致度検出手段と、前記検出された一致度に基づいて前記リッチコンテンツ領域の画像が前記記憶手段に記憶された画像と一致したことが検出されると、リッチコンテンツが変化したと判断する判断手段と、からなることを特徴としている。これによれば、前記記憶手段に記憶させる画像を事前に設定することにより画面更新を行うタイミングを設定することができる。

請求項７に係る発明は、画像の表示が可能な携帯端末と通信し、Ｗｅｂサーバが提供するＷｅｂページを画像化して前記携帯端末に提供する中継サーバであって、前記携帯端末からＷｅｂページの閲覧要求があると、前記閲覧要求されたＷｅｂページにリッチコンテンツが含まれているか否かを判別し、リッチコンテンツが含まれている場合には、そのリッチコンテンツが表示されるリッチコンテンツ領域を抽出する抽出手段と、前記抽出したリッチコンテンツ領域におけるリッチコンテンツの変化を検出する検出手段と、前記閲覧要求に応じてＷｅｂページを前記携帯端末での閲覧用画像データに変換する画像変換手段であって、前記検出手段により前記リッチコンテンツ領域におけるリッチコンテンツの変化が検出されると、画面更新のためにＷｅｂページを前記閲覧用画像データに変換する画像変換手段と、前記画像変換手段により変換した閲覧用画像データを前記携帯端末に送信する画像データ送信手段と、を備えたことを特徴としている。

請求項８に示すように請求項７に記載の中継サーバにおいて、前記検出手段は、前記リッチコンテンツ領域の画像を所定の間隔で取得する画像取得手段と、前記画像取得手段により今回取得した画像と前回取得した画像とを比較し、両画像間の変化量を検出する変化量検出手段と、前記検出された変化量に基づいてリッチコンテンツが変化したと判断する判断手段と、からなることを特徴としている。

請求項９に示すように請求項８に記載の中継サーバにおいて、前記判断手段は、前記変化量検出手段により検出された変化量が所定の閾値を越えると、リッチコンテンツが変化したと判断することを特徴としている。

請求項１０に示すように請求項８に記載の中継サーバにおいて、前記判断手段は、前記変化量検出手段により検出された変化量が検出された後、所定時間変化が検出されなくなると、リッチコンテンツが変化したと判断することを特徴としている。

請求項１１に示すように請求項８から１０のいずれかに記載の中継サーバにおいて、前記変化量検出手段は、前記画像取得手段により今回取得した画像と前回取得した画像とをそれぞれ縮小させる画像縮小手段と、前記縮小された画像間の相関値を、前記画像間の変化量を示す評価値として算出する算出手段と、を有することを特徴としている。

請求項１２に示すように請求項８に記載の中継サーバにおいて、前記検出手段は、前記リッチコンテンツ領域の画像を所定の間隔で取得する画像取得手段と、前記リッチコンテンツ領域におけるリッチコンテンツの変化後の画像を記憶する記憶手段と、前記画像取得手段により取得された画像と前記記憶手段に記憶された画像とを比較し、両画像の一致度を検出する一致度検出手段と、前記検出された一致度に基づいて前記リッチコンテンツ領域の画像が前記記憶手段に記憶された画像と一致したことが検出されると、リッチコンテンツが変化したと判断する判断手段と、からなることを特徴としている。

本発明によれば、携帯端末がＰＣ向けＷｅｂページの閲覧機能を有していなくても、Ｗｅｂページのデザインを崩すことなくＷｅｂページを閲覧することができ、特にリッチコンテンツが組み込まれたＷｅｂページであってもＰＣと同様にＷｅｂページの閲覧及び操作を行うことができる。

ＰＣ向けＷｅｂページをＰＣ１の表示部２と携帯端末１０の表示部１４とで閲覧した様子を示す図 Ｗｅｂページ閲覧システム１００の全体構成の一例を示す図 携帯端末１０の表示部１４に所望のＷｅｂページの表示を行うまでの動作を示すフローチャート ＵＩメタデータの生成について説明するための図 ＣＳＶファイルとして保存されるメタデータを示す図 携帯端末１０の内部処理について示すフローチャート 操作に応じてカーソルが移動する場合を示す図 ＵＩメタデータの書き換えについて説明するための画面遷移図 ＵＩメタデータの書き換えについて説明するための図表 携帯端末１０においてＵＩ操作された場合の動作を示すフローチャート 中継サーバ２０におけるリッチコンテンツ対応の処理内容を示すフローチャート リッチコンテンツの画面遷移の一例を示す図

図１はＰＣ１の表示部２を用いてＷｅｂページを閲覧した場合と同様に、携帯端末１０の表示部１４を用いてＷｅｂページの閲覧しているイメージを示す図である。同図に示すように携帯端末（携帯電話）１０は、ＰＣと同様にＷｅｂページの閲覧が可能である。

以下、添付図面に従って本発明を実施するための形態について説明する。

〔実施形態〕
図２は本実施形態におけるＷｅｂページ閲覧システム１００の全体構成の一例を示す図である。同図に示すように、Ｗｅｂページ閲覧システム１００は、ユーザが使用する携帯端末１０と、外部Ｗｅｂサーバ３０、及び携帯端末１０と外部Ｗｅｂサーバ３０との通信を中継する中継サーバ２０とから構成されている。尚、このシステムは、携帯端末１０でのフルブラウザを実現するものであるが、その処理の殆どは中継サーバ２０が担うシンクライアント型である。

携帯端末１０は、通信部１１、処理部１２、入力装置１３、及び表示部１４を備えており、通常の携帯電話等で構成されている。

通信部１１は、所定のプロトコルによる中継サーバ２０との通信を制御する。

携帯端末１０と中継サーバ２０とは、いわゆるインターネットを介して接続されており、通信部１１と後述する通信部２１とは、ＴＣＰ／ＩＰ等の標準的なインターネットプロトコルに従ってそれぞれ通信を行う。尚、専用通信回線やＶＰＮを介して接続されてもよい。

処理部１２は、通信部１１を介して中継サーバ２０から取得した画像を表示部１４に表示させ、また、ユーザの入力装置１３による入力操作に基づいた処理を行う。

入力装置１３は、図示しない電源ボタン、番号キー、十字キー、決定キー等を含み、ユーザは、入力装置１３を操作することにより、携帯端末１０を操作することができる。また、表示部１４の前面にタッチパネルを配置し、入力装置１３として用いてもよい。

表示部１４は、カラー表示が可能な液晶ディスプレイであり、処理部１２から入力された画像信号に基づいて、表示を行う。尚、液晶ディスプレイに代えて、有機ＥＬなど他の方式の表示装置を用いてもよい。

中継サーバ２０は、通信部２１と、画像変換部２２と、リッチコンテンツ領域を抽出する抽出部２３、リッチコンテンツの変化を検出する検出部２４、及びユーザインターフェース（ＵＩ）情報解析部２５を有する処理部２６とを備えて構成されている。

通信部２１は、携帯端末１０との通信を制御すると共に、外部Ｗｅｂサーバ３０との通信を制御する。中継サーバ２０と外部Ｗｅｂサーバ３０とは、インターネットを介して接続され、通信部２１と後述する通信部３１とは、標準的なインターネットプロトコルに従ってそれぞれ通信を行う。

画像変換部２２は、通信部２１を介して外部Ｗｅｂサーバ３０から取得したＷｅｂページに基づいて、当該Ｗｅｂページをブラウズした状態と同様の画像ファイルを生成する。ここでは、予め決められた解像度で画像ファイルを生成するが、Ｗｅｂページの内容や携帯端末１０の解像度に応じた解像度の画像ファイルを生成してもよい。

抽出部２３は、Ｗｅｂページにリッチコンテンツが組み込まれている場合に、そのリッチコンテンツのＷｅｂページ上の領域（リッチコンテンツ領域）を抽出するものである。ＷｅｂページのＨＴＭＬファイルには、リッチコンテンツのタグ（例えば、リッチコンテンツがフラッシュの場合には、フラッシュタグ）が書き込まれており、そのフラッシュタグから表示場所や表示サイズを読み取ることによりリッチコンテンツ領域を抽出する。

検出部２４は、リッチコンテンツ領域の画像を一定の時間間隔で取得し、その取得した前後の画像に基づいてリッチコンテンツの変化を検出する部分である。

ＵＩ情報解析部２５は、取得したＷｅｂページのコンテンツファイルからＵＩ情報を抽出し、その種類や位置を解析し、ＵＩメタデータを生成する。

外部Ｗｅｂサーバ３０は、通信部３１、記憶部３２を備えて構成されている。

通信部３１は、中継サーバ２０との通信を制御する。また、記憶部３２は、外部Ｗｅｂサーバ３０に開設されたＷｅｂページの各コンテンツファイルを記憶している。通信部３１は、中継サーバ２０から受信したＵＲＬのリクエストに応じたファイルを、記憶部３２から読み出して中継サーバ２０に送信する。

尚、図２においては、携帯端末１０は１つだけ記載されているが、中継サーバ２０と通信可能な携帯端末１０は多数存在し、それぞれ個別に中継サーバ２０との通信を行う。また、外部Ｗｅｂサーバ３０もインターネット網中に多数存在し、中継サーバ２０は、それぞれの外部Ｗｅｂサーバ３０と通信することが可能である。このように、どの携帯端末１０からどの外部Ｗｅｂサーバ３０へアクセスする場合であっても、中継サーバ２０を介して通信を行う。

次に、このように構成されたＷｅｂページ閲覧システム１００の動作について説明する。まず、携帯端末１０の表示部１４に、所望のＷｅｂページの表示を行うまでの動作について、図３を用いて説明する。

ユーザは、携帯端末１０の入力装置１３を用いて、閲覧したいＷｅｂページのＵＲＬアドレスを入力する。文字列を直接入力するのではなく、携帯端末１０の図示しない記憶部に登録されているブックマーク等を用いてＵＲＬアドレスを選択してもよい。ＵＲＬアドレスを入力後に入力装置１３の送信ボタンにより送信を指示すると、通信部１１は、入力されたＵＲＬアドレスを中継サーバ２０に送信する（ステップＳ１１）。

尚、中継サーバ２０の図示しない記憶部のブックマークにおいて、ＷｅｂページタイトルとＵＲＬアドレスを保持しておき、これらのＷｅｂページタイトルの中から選択可能に構成してもよい。この場合は、中継サーバ２０は、通信部２１を介して保持しているＷｅｂページタイトルを携帯端末１０に送信し、携帯端末１０は、通信部１１を介してこれを受信する。さらに、処理部１２によって受信したＷｅｂページタイトルを表示部１４に表示させる。ユーザは、表示されたＷｅｂページタイトルの中から所望のＷｅｂページを、入力装置１３を用いて選択する。そして、携帯端末１０は、選択されたＷｅｂページタイトルを通信部１１を介して中継サーバ２０に送信すればよい。

中継サーバ２０は、携帯端末１０から送信されたＵＲＬアドレスを通信部２１を介して受信する（ステップＳ２１）。さらに、通信部２１は、受信したＵＲＬアドレスを、当該ＵＲＬアドレスに該当する外部Ｗｅｂサーバ３０に送信する（ステップＳ２２）。中継サーバ２０のブックマークを用いてＷｅｂページタイトルが選択された場合には、図示しない記憶部から該当するＵＲＬアドレスを読み出し、これを該当する外部Ｗｅｂサーバ３０に送信すればよい。

該当する外部Ｗｅｂサーバ３０は、通信部３１を介してこのＵＲＬアドレスを受信する（ステップＳ３１）。そして、受信したＵＲＬアドレスに該当するＨＴＭＬファイル、ＣＳＳファイル、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔファイル等のコンテンツファイルを記憶部３２から読み出し、通信部３１を介して中継サーバ２０に送信する（ステップＳ３２）。

中継サーバ２０は、外部Ｗｅｂサーバ３０から送信されたコンテンツファイルを受信し（ステップＳ２３）、ＵＩ情報解析部２５により、受信したコンテンツファイルを解析して、ＵＩ情報を抽出する（ステップＳ２４）。ここでのコンテンツファイルの解析方法は特に限定されるものではなく、パースしてタグを抽出するといった公知の手法を用いればよい。

ＵＩ情報解析部２５は、この解析結果に基づいてＵＩメタデータを生成する（ステップＳ２５）。図４は、ＵＩメタデータの生成について説明するための図であり、図４（ａ）は、図４（ｂ）に示すＨＴＭＬファイルを通常のＰＣ等を用いてブラウズした状態を示す図である。尚、図４（ｂ）に示すＨＴＭＬファイルは、不要な部分を適宜省略している。

ＵＩ情報解析部２５は、図４（ｂ）に示すＨＴＭＬファイルからリンクタグや入力フォーム等のＵＩ情報を抽出し、各ＵＩ情報の図４（ａ）における位置座標を算出する。

例えば、図４（ｂ）に示すＨＴＭＬファイルには、テキスト入力欄タグ３０１、ラジオボタンタグ３０２、ラジオボタンタグ３０３、リンクタグ３０４、リンクタグ３０５、及びボタンタグ３０６の、６つのタグが記載されている。ＵＩ情報解析部２５は、ＨＴＭＬファイルからこれらのタグを抽出することにより、各ＵＩ情報２０１〜２０６を抽出する。

また、ＵＩ情報２０１〜２０６は、ＨＴＭＬファイルをブラウズした状態において、図４（ａ）に示す画面上の各位置に配置される。ＵＩ情報解析部２５は、これらのＵＩ情報の開始と終了のＸＹ座標値（左上と右下に相当する座標値）を取得する。座標値の取得方法は特に限定されるものではなく、例えば、画像レンダリング中に記憶、ブラウザから取得等の手法を用いればよい。

このように抽出された各ＵＩ情報とその位置情報は、それぞれのＵＩ情報ＩＤと共に関連付けられ、ＵＩメタデータとして中継サーバ２０の図示しない記憶部に保存される。ここでは、ＵＩ情報ＩＤは、それぞれ２０１〜２０６とする。図５は、ＣＳＶファイルとして保存されたＵＩメタデータを示す図である。レイアウト等の画面表示に関する属性（例えばｓｉｚｅ属性）は、ＵＩメタデータに含まなくてよい。

また、画像変換部２２は、取得したコンテンツファイルをレンダリングし、jpeg形式やbitmap形式等の、携帯端末１０の表示部１４に表示可能な形式の画像ファイルを生成する（ステップＳ２５）。尚、画像ファイルの生成方法は特に限定されるものではなく、公知の手法によって行なえばよい。

図４（ｃ）は、図４（ｂ）に示すＨＴＭＬファイルをレンダリングした画像を示す図である。ここで、図５に示すＵＩメタデータを用いることにより、この画像中のＵＩ情報の位置と種別を知ることができる。例えば、各タグ３０１〜３０６に対応するＵＩ情報は、図４（ｃ）に示す各位置４０１〜４０６に配置されていることがわかり、これらの位置は、図４（ａ）に示すブラウズ状態における各ＵＩ情報２０１〜２０６の配置と同様になっている。この画像ファイルは、ＵＩメタデータと共に中継サーバ２０の図示しない記憶部に保存してもよい。

中継サーバ２０は、ステップＳ２５で生成したＵＩメタデータと画像ファイルを、通信部２１を介して携帯端末１０へ送信する（ステップＳ２６）。このとき、基となったコンテンツファイルを、送信した携帯端末１０や生成したＵＩメタデータと関連付けて図示しない記憶部に記憶しておく。携帯端末１０は、通信部１１を介して、このＵＩメタデータと画像ファイルを受信する（ステップＳ１２）。

次に、ＵＩメタデータと画像ファイルを受信した携帯端末１０の内部処理について、図６を用いて説明する。

携帯端末１０は、通信部１１を介してＵＩメタデータと画像ファイルを受信すると（ステップＳ４１）、処理部１２は、受信したＵＩメタデータに含まれる各ＵＩ情報の位置座標と表示部１４に表示されるカーソルの位置座標とを比較し（ステップＳ４２）、比較結果に基づいて、表示部１４に画像ファイルとＵＩ情報とを表示する（ステップＳ４３）。

例えば、カーソルの位置座標がＵＩ情報の位置座標と重なった時に、該当するＵＩ情報の位置の部分に対してマークを付し、ＵＩ情報が選択可能であることをユーザに認識させる。また、下線を引く、四角で囲う等でもよい。尚、ここでは、ＵＩメタデータに記録された各ＵＩ情報のＸＹ座標値を対角とする矩形状の範囲内にカーソルが位置する場合に、ＵＩ情報の位置座標とカーソルの位置座標とが重なったとみなす。また、重なった場合ではなく、表示されているＵＩ情報の画像上の位置に対して常にこのような表示を行ってもよい。逆に、カーソルの位置座標がＵＩ情報の位置座標と重なった時に、カーソルの色や形状を変更して表示してもよい。

ここで、入力装置１３によりユーザ操作が行われると（ステップＳ４４）、操作内容に応じて、表示部１４の表示を変更する。

例えば、十字キー等による上下左右移動の操作が行われた場合には、操作に応じてカーソル又は画像を移動させる（ステップＳ４５）。

図７は、操作に応じてカーソルが移動する場合を示す図であり、図７（ｂ）は、図７（ａ）の状態から左上移動の操作が行われた場合の表示を示している。ユーザ操作に応じて、カーソル５０２が画面左上にあるＵＩ情報の位置５０１（ここでは、リンク）上に移動されると、ＵＩ情報の位置５０１に下線を引くと共に、カーソル５０２の形状をカーソル５０２´に変更して表示する。

尚、この状態で決定ボタンによる操作を行うことで、後述するようにＵＩ情報の位置５０１に関連付けられたリンク先を表示することができる。

また、ステップＳ４４において拡大・縮小の操作が行われた場合には、操作に応じた倍率に変更して画像を表示する（ステップＳ４６）。

また、ステップＳ４４において決定ボタンによる操作（クリック操作）が行われた場合には、ステップＳ４２における比較結果に基づいて、カーソル位置とＵＩ情報の画像上の位置とが重なっているか否かを判定する（ステップＳ４７）。

カーソル位置がＵＩ情報の画像上の位置と重なっていない場合は、処理部１２はこのクリック操作を無効とし、ステップＳ４２に戻り、同様の処理を行う。

カーソル位置がＵＩ情報の画像上の位置と重なっている場合は、処理部１２は、ＵＩメタデータに基づいてカーソル位置と重なる位置に存在するＵＩ情報の種別を判定する（ステップＳ４８）。

ここで、ＵＩ情報の種別としては、（１）テキスト入力欄等のユーザによる入力が必要なＵＩ情報、（２）チェックボックスやラジオボタン等の画面遷移を伴わず、データ入力の必要もないＵＩ情報、（３）リンク、ボタン等の画面遷移を伴うＵＩ情報、の３つが考えられる。

カーソル位置に存在するＵＩ情報の種別が、（１）テキスト入力欄等のユーザによるデータ入力が必要なＵＩ情報である場合は、まずポップアップ等により表示部１４にデータ入力画面を表示し、ユーザに入力を要求する（ステップＳ４９）。ユーザは、この入力画面において入力装置１３によって必要なデータ入力を行う（ステップＳ５０）。処理部１２は、ユーザ入力に応じて図示しない記憶部に記憶されているＵＩメタデータを書き換える（ステップＳ５１）。書き換えられたＵＩメタデータは、書き換えられたＵＩ情報ＩＤと共に、通信部１１を介して中継サーバ２０に送信される（ステップＳ５２）。

ここで、ＵＩメタデータの書き換えの詳細について、図８、図９を用いて説明する。

図８（ａ）は、図４（ｃ）に示した画像を表示部１４に表示した様子を示す図である。表示された画像上の各位置４０１〜４０６には、図９（ａ）に示すＵＩメタデータに示すように、各ＵＩ情報２０１〜２０６が表示されている。ここで、ユーザが、ＵＩ情報２０１に対応する位置４０１上にカーソル４００を移動させてクリック操作を行うと、図８（ｂ）に示すように、表示部１４にはテキスト入力ポップアップ画面が表示される。

ユーザは、このポップアップ画面において、入力装置１３を用いて所望の文字を入力する。テキスト入力後、入力装置１３によりクリック操作が行われると、処理部１２は、入力されたテキストに基づいて、位置４０１に対応するＵＩ情報２０１のvalue属性を書き換える。ここでは、図８（ｂ）に示すように、ユーザがテキスト入力ポップアップ画面において「shibukawa」と入力しているため、図９（ｂ）に示すように、ＵＩ情報２０１のvalue属性が「shibukawa」と書き換えられている。

この書き換えられたＵＩメタデータは、書き換えられた（実行された）ＵＩ情報ＩＤ（ここでは、２０１）と共に、通信部１１を介して中継サーバ２０に送信される。

次に、対応するＵＩ情報が、（２）画面遷移を伴わず、データ入力の必要もない場合について説明する。

図８（ｃ）に示すＵＩ情報２０２に対応する位置４０２とＵＩ情報２０３に対応する位置４０３には、性別を指定するためのラジオボタンが表示されている。このＵＩ情報２０２とＵＩ情報２０３は、図４に示すように、基となるタグ３０２と３０３が同じname属性を有している。即ち、ＵＩ情報２０２とＵＩ情報２０３のうち、いずれか一方を選択することが可能である。ここで、初期の設定では、図９（ａ）に示すように、ＵＩ情報２０２のchecked属性がtrue、ＵＩ情報２０３のchecked属性がfalseとなっているため、図８（ａ）に示すように、ＵＩ情報２０２が選択された状態となっている。

ここで、ＵＩ情報２０３に対応する位置４０３上にカーソル４００を移動させてクリック操作が行われると、処理部１２は、ＵＩメタデータに基づいて、カーソル位置と重なる位置に存在するＵＩ情報の種別を判定する。

ここでは、ＵＩ情報２０３はラジオボタンであり、ユーザによるデータ入力の必要がなく、また画面遷移を伴わないＵＩ情報であるので、ステップＳ５１に移行し、処理部１２は、図示しない記憶部に記憶されているＵＩメタデータからＵＩ情報２０３に関するデータを書き換える。

図９（ｃ）は、この場合に書き換えられたＵＩメタデータを示す図である。同図に示すように、ＵＩ情報２０３のchecked属性がtrueに書き換えられていると共に、ＵＩ情報２０３と同じname属性を有するＵＩ情報２０２のchecked属性がfalseに書き換えられている。

最後に、対応するＵＩ情報が、（３）画面遷移を伴う場合について説明する。画面遷移を伴うＵＩ情報とは、そのＵＩ情報を実行した結果、現在表示している画像とは異なる画像を表示することになるＵＩ情報を指している。

図８（ｄ）に示すように、ＵＩ情報２０６に対応する位置４０６に表示されているのは送信ボタンであり、位置４０６をクリック操作することにより、タグ３０６の記載に従って別の画面に遷移する。この位置４０６上にカーソル４００を移動させてクリック操作が行われると、処理部１２は、ＵＩメタデータに基づいてカーソル位置と重なる位置に存在するＵＩ情報の種別を判定する。

ここで、ＵＩ情報２０６はボタンであり、画面遷移を伴うＵＩ情報であるので、ステップＳ５２に移行する。そして、ＵＩメタデータと共に、実行されたＵＩ情報ＩＤ（ここでは、２０６）が、通信部１１を介して中継サーバ２０に送信される（ステップＳ５２）。

このように、どの種別のＵＩ情報がクリック操作された場合であっても、ＵＩメタデータと実行されたＵＩ情報ＩＤとが、中継サーバ２０に送信される。

次に、実行されたＵＩメタデータに基づくＷｅｂページ閲覧システム１００の動作について、図１０を用いて説明する。

図１０において、携帯端末１０から、ＵＩメタデータと実行されたＵＩ情報ＩＤが送信されると（ステップＳ６１）、中継サーバ２０は、通信部２１を介してこれを受信する（ステップＳ７１）。

ＵＩ情報解析部２５は、受信したＵＩメタデータと実行されたＵＩ情報ＩＤを解析し、ＵＩメタデータ中のどのＵＩ情報が実行されたのかを解析する（ステップＳ７２）。

また、ＵＩ情報解析部２５は、実行されたＵＩ情報に基づいて、外部Ｗｅｂサーバとの通信が必要であるか否かを判定する（ステップＳ７３）。例えば、リンクボタンが操作され、画面遷移がある場合が該当する。

実行されたＵＩ情報が外部Ｗｅｂサーバとの通信が必要なＵＩ情報である場合は、図示しない記憶部に記憶されたコンテンツファイルから遷移先のＵＲＬアドレスを取得し、該当する外部Ｗｅｂサーバ３０へ送信する（ステップＳ７４）。そして、この外部Ｗｅｂサーバ３０から該当するコンテンツファイルを受信し（ステップＳ７５）、ＵＩ情報解析部２５においてこの遷移先のコンテンツファイルを解析する（ステップＳ７６）。

さらに、ＵＩ情報解析部２５は、この解析結果に基づいて遷移先のＵＩメタデータを生成し、また、画像変換部２２は、遷移先のコンテンツファイルに基づいて画像ファイルを生成する（ステップＳ７７）。この遷移先の画像ファイルとＵＩメタデータとを、通信部２１を介して携帯端末１０に送信する（ステップＳ７８）。

携帯端末１０は、通信部１１を介してこの画像ファイルとＵＩメタデータを受信し、この画像ファイルを遷移先の画面として表示部１４に表示する（ステップＳ６２）。

ステップＳ７３において、実行されたＵＩ情報が外部Ｗｅｂサーバとの通信が不要なＵＩ情報であると判断された場合は、ステップＳ７７へ移行し、この書き換えられたＵＩメタデータと関連するコンテンツファイルを図示しない記憶部から読み出し、書き換えられたＵＩメタデータに基づいて新たな画像ファイルを生成する。また、新たな画像ファイルを生成するのではなく、基のコンテンツファイルの画像と実行されたＵＩ情報ＩＤとに基づいて、実行されたことにより書き換えを要する部分についてだけ、画像を書き換えてもよい。

この新たな画像ファイルとＵＩメタデータとを、通信部２１を介して携帯端末１０に送信する（ステップＳ７８）。

携帯端末１０は、通信部１１を介してこの画像ファイルとＵＩメタデータを受信し、この画像ファイルを表示部１４に表示する（ステップＳ６２）。

例えば、実行されたＵＩ情報が、図８（ａ）に示すＵＩ情報４０１（テキスト入力欄）の場合は、携帯端末１０から、図９（ｂ）に示す書き換えられたＵＩメタデータと、実行されたＵＩ情報ＩＤ２０１が送信される（ステップＳ６１）。中継サーバ２０は、通信部２１を介してこれを受信する（ステップＳ７１）。

画像変換部２２は、この書き換えられたＵＩメタデータと関連するコンテンツファイルを図示しない記憶部から読み出し、書き換えられたＵＩメタデータに基づいて新たな画像ファイルを生成する。この新たな画像ファイルは、図８（ｃ）に示すように、テキスト入力欄の位置にステップＳ５０において入力された文字「shibukawa」が表示された画像となっている。

また、実行されたＵＩ情報が、図８（ｃ）に示すＵＩ情報４０３（ラジオボタン）の場合は、携帯端末１０から、図９（ｃ）に示す書き換えられたＵＩメタデータと、実行されたＵＩ情報ＩＤ２０３が送信される（ステップＳ６１）。中継サーバ２０は、通信部２１を介してこれを受信する（ステップＳ７１）。

画像変換部２２は、この書き換えられたＵＩメタデータと関連するコンテンツファイルを図示しない記憶部から読み出し、書き換えられたＵＩメタデータに基づいて新たな画像ファイルを生成する。この新たな画像ファイルは、図８（ｄ）に示すように、ラジオボタンのチェック位置が位置４０２から位置４０３に変更された画像となっている。

さらに、実行されたＵＩ情報が、図８（ｄ）に示すＵＩ情報４０６（ボタン）の場合は、携帯端末１０から、ＵＩメタデータ（この場合は書き換えられていない）と、実行されたＵＩ情報ＩＤ２０６が送信される（ステップＳ６１）。中継サーバ２０は、通信部２１を介してこれを受信する（ステップＳ７１）。

これを受信した中継サーバ２０は、ＵＩメタデータから遷移先のＵＲＬアドレスを取得し、該当する外部Ｗｅｂサーバ３０から該当するコンテンツファイルを要求して（ステップＳ７４）、受信する（ステップＳ７４）。このコンテンツファイルに基づいて、ＵＩ情報解析部２５においてＵＩメタデータが生成されると共に、画像変換部２２において画像ファイルが生成する（ステップＳ７７）。

この遷移先の画像ファイルとＵＩメタデータとが携帯端末１０に送信され（ステップＳ７８）、この画像ファイルは表示部１４に表示される（ステップＳ６２）。

このように、画面遷移を伴うＵＩ操作がされた場合も、新たな遷移先のＷｅｂページを表示させることができ、さらに、これまでと同様にＵＩ情報の操作も可能である。

以上のように、Ｗｅｂページ閲覧システム１００は、高速で操作性のよいＷｅｂページ閲覧を実現することができる。

〔リッチコンテンツ対応〕
次に、Ｗｅｂページにはリッチコンテンツが組み込まれている場合があるため、以下、リッチコンテンツに対する対応について説明する。

図１１は中継サーバ２０におけるリッチコンテンツ対応の処理内容を示すフローチャートであり、図３に示したステップＳ２６（ＵＩメタデータと画像ファイルの携帯端末１０への送信）の処理後に関して示している。

図１１において、中継サーバ２０の抽出部２３は、Ｗｅｂページにリッチコンテンツが組み込まれている場合に、そのリッチコンテンツ領域を抽出する（ステップＳ９０）。続いて、検出部２４は、前記抽出されたリッチコンテンツ領域から一定の時間間隔で画像をキャプチャし、キャプチャした画像が変化したか否かを判断する（ステップＳ９１、Ｓ９２、Ｓ９３、Ｓ９４）。

即ち、検出部２４は、リッチコンテンツ領域から画像を一定の時間間隔で連続的にキャプチャする画像取得部と、連続的に取得される時間的に前後の２つの画像（今回取得した画像と前回取得した画像）を比較し、両画像間の変化量を検出する変化量検出部と、この検出された変化量に基づいてリッチコンテンツの変化を判断する判断部とから構成されている。

前記画像取得部は、リッチコンテンツ領域から画像を一定の時間間隔で連続的に取得し（ステップＳ９１）、変化量検出部は、今回取得した画像と前回取得した画像（一つ前の画像）とを比較し（ステップＳ９２）、両画像間の変化量を検出する（ステップＳ９３）。

ここで、変化量検出部は、画像取得部により取得された画像を受入すると、その受入した画像を縮小する縮小処理を行う。縮小処理は、画素の間引処理により行うことができる。そして、縮小された今回取得した画像と前回取得した画像との相関を求める。相関は、２つの画像間の同一位置の画素の画素値の差分の絶対値を求め、これを２つの画像の全画素について積算することにより算出することができる。このようにして算出された積算値は、２つの画像の相関を示す評価値となり、積算値が大きい場合には２つの画像の相関は低くなり、積算値が小さい場合には２つの画像の相関は高くなる。

判断部は、上記のようにして求めた２つの画像の変化量（相関値）が、予め設定されている閾値を越えたか否かを判断し（ステップＳ９４）、変化量が閾値を越えた場合（(「Yes」の場合)には、ステップＳ９５に遷移させ、変化量が閾値以下の場合(「No」の場合)には、ステップＳ９１に遷移させる。

ステップＳ９５では、携帯端末１０の表示画面を更新するための画像ファイルを生成する。このようにして生成された画像ファイルは、中継サーバ２０から携帯端末１０へ送信される（ステップＳ９６）。

ステップＳ９４において、変化量が閾値以下の場合(「No」の場合)、及びステップＳ９６において、画像ファイルが送信された場合には、ステップＳ９１に遷移し、ここでリッチコンテンツ領域の画像をキャプチャし、再び上記の処理を繰り返す。

携帯端末１０は、ステップＳ９６において、画像ファイルが送信されると、これを受信し、表示部１４に表示させる。これにより、携帯端末１０の表示部１４に表示されるＷｅｂページの画像は、リッチコンテンツ領域の画像が更新されたものとなる。

図１２にリッチコンテンツの画面遷移の一例を示す。

図１２に示すリッチコンテンツは、１つの動画と３枚の静止画Ｂ１，Ｂ２，Ｂ３とからなり、動画を表示させたのち、３枚の静止画Ｂ１，Ｂ２，Ｂ３を順次スライドショー再生し、再び動画を表示させるように構成されている。また、動画は、シーンＡ１とシーンＡ２とに分かれている。

いま、リッチコンテンツとして動画が表示されている場合、図１１のステップＳ９３では、リッチコンテンツ領域の動画の時系列の前後の画像間の変化量が検出される。ここで、ステップＳ９４において設定された閾値が低い場合、又はリッチコンテンツ領域の画像を取り込む周期が比較的長い場合には、前後の画像の変化量が閾値を越えたと判断されやすくなる。そして、前後の画像の変化量が閾値を越えたと判断されると、上述したように画面更新用の画像ファイルが生成されて携帯端末１０に送信され、携帯端末１０では、リッチコンテンツ領域の画像が更新されたＷｅｂページの画像が表示されることになる。尚、この場合、オリジナルの動画のようには表示されず、アニメーションのような表示になる。

一方、ステップＳ９４において設定された閾値が高い場合、又はリッチコンテンツ領域の画像を取り込む周期が比較的短い場合には、動画の同一シーン内では、前後の画像の変化量は閾値を越えたと判断されにくくなるが、シーンＡ１からシーンＡ２へのシーンの切り替わり時の前後の画像の変化量は、閾値を越えたと判断されることになる。従って、この場合には、動画のシーンの切り替わり時に、画面更新用の画像ファイルが生成されて携帯端末１０に送信され、携帯端末１０では、リッチコンテンツ領域の画像が更新されたＷｅｂページの画像が表示されることになる。

また、図１２に示すようにリッチコンテンツの表示画面が、動画→静止画Ｂ１→静止画Ｂ２→静止画Ｂ３→動画に順次遷移する場合、これらの画面遷移の前後の画像の変化量は、閾値を越えたと判断されることになる。従って、上記リッチコンテンツの画面遷移時に、画面更新用の画像ファイルが生成されて携帯端末１０に送信され、携帯端末１０では、リッチコンテンツ領域の画像が更新されたＷｅｂページの画像が表示されることになる。

ところで、図１２に示すようなリッチコンテンツでは、各画像（動画、３枚の静止画Ｂ１〜Ｂ３）とＵＲＬとが関連付けられている。従って、ユーザが携帯端末１０に表示されているＷｅｂページの画像を見ながら、リッチコンテンツ領域の画像をクリックすると、中継サーバ２０は、その画像に関連付けられたＵＲＬによりＷｅｂサーバをアクセスし、取得したＷｅｂページの画像を携帯端末１０に表示させることになる。

即ち、ユーザは、リッチコンテンツが組み込まれているＷｅｂページを画像として閲覧することができると共に、リッチコンテンツの変化に応じて画面更新されたＷｅｂページを画像として閲覧することができる。これにより、携帯端末１０に表示されたリッチコンテンツをクリック操作した場合に、その表示されているリッチコンテンツに対応したＷｅｂサーバのＷｅｂページを閲覧することができる。

尚、上記リッチコンテンツに対応して新たに取得したＷｅｂページが、テキスト入力欄等のユーザによる入力が必要な場合であっても前述したように入力操作が可能である。

〔その他〕
この実施形態では、リッチコンテンツ領域の画像が一定以上変化すると、携帯端末１０に表示させる画面を更新するようにしたが、これに限らず、画像が一定以上変化した後に、所定時間変化が検出されなくなると（静止画になると）、携帯端末１０に表示させる画面を更新するようにしてもよい。これによれば、リッチコンテンツ領域に動画が表示されている場合には、画面更新は行われず、動画が停止した時に画面更新を行うことができる。

また、中継サーバ２０が事前にリッチコンテンツの画面遷移を解析し、リッチコンテンツ中の所定の画像（複数の画像を含む）を記憶手段に記憶させておき、現在のＷｅｂページのリッチコンテンツ領域の画像と、前記記憶手段に記憶されている画像とが一致した時に、携帯端末１０に表示させる画面を更新するようにしてもよい。

さらに、この実施形態では、リッチコンテンツの変化に応じて携帯端末１０に表示させる画面を更新する際に、該携帯端末１０に表示させる全画像を中継サーバ２０から送信するようにしたが、これに限らず、リッチコンテンツ領域内の画像とその画像の位置情報のみを送信し、携帯端末１０側でリッチコンテンツ領域内の画像のみを更新するようにしてもよい。これによれば、画面更新時の通信量を削減することができる。但し、携帯端末１０は、リッチコンテンツ領域内の画像のみを更新するための機能（画像合成機能）を具備する必要がある。

また、リッチコンテンツは、フラッシュに限らず、例えば、ジャバアプレット（Java Applet）、シルバーライト（Silverlight）等で記述されたコンテンツでもよい。

さらに、本発明は上述した実施の形態に限定されず、本発明の精神を逸脱しない範囲で種々の変形が可能であることは言うまでもない。

１…ＰＣ、２、１４…表示部、１０…携帯端末、１１、２１、３１…通信部、１２、２６…処理部、１３…入力装置、２０…中継サーバ、２２…画像変換部、２３…抽出部、２４…検出部、２５…ＵＩ情報解析部、３０…外部Ｗｅｂサーバ、３２…記憶部、１００…Ｗｅｂページ閲覧システム

Claims (12)

1. 画像の表示が可能な携帯端末と、Ｗｅｂサーバが提供するＷｅｂページを画像化して前記携帯端末に提供する中継サーバとからなり、前記携帯端末によりＷｅｂページを閲覧させるＷｅｂページ閲覧システムであって、
   前記中継サーバは、
   前記携帯端末からＷｅｂページの閲覧要求があると、前記閲覧要求されたＷｅｂページにリッチコンテンツが含まれているか否かを判別し、リッチコンテンツが含まれている場合には、そのリッチコンテンツが表示されるリッチコンテンツ領域を抽出する抽出手段と、
   前記抽出したリッチコンテンツ領域におけるリッチコンテンツの変化を検出する検出手段と、
   前記閲覧要求に応じてＷｅｂページを前記携帯端末での閲覧用画像データに変換する画像変換手段であって、前記検出手段により前記リッチコンテンツ領域におけるリッチコンテンツの変化が検出されると、画面更新のためにＷｅｂページを前記閲覧用画像データに変換する画像変換手段と、
   前記画像変換手段により変換した閲覧用画像データを前記携帯端末に送信する画像データ送信手段と、
   を備えたことを特徴とするＷｅｂページ閲覧システム。
2. 前記検出手段は、前記リッチコンテンツ領域の画像を所定の間隔で取得する画像取得手段と、前記画像取得手段により今回取得した画像と前回取得した画像とを比較し、両画像間の変化量を検出する変化量検出手段と、前記検出された変化量に基づいてリッチコンテンツの変化を判断する判断手段と、からなることを特徴とする請求項１に記載のＷｅｂページ閲覧システム。
3. 前記判断手段は、前記変化量検出手段により検出された変化量が所定の閾値を越えると、リッチコンテンツが変化したと判断することを特徴とする請求項２に記載のＷｅｂページ閲覧システム。
4. 前記判断手段は、前記変化量検出手段により検出された変化量が検出された後、所定時間変化が検出されなくなると、リッチコンテンツが変化したと判断することを特徴とする請求項２に記載のＷｅｂページ閲覧システム。
5. 前記変化量検出手段は、前記画像取得手段により今回取得した画像と前回取得した画像とをそれぞれ縮小させる縮小手段と、前記縮小された画像間の相関値を、前記画像間の変化量を示す評価値として算出する算出手段と、を有することを特徴とする請求項２から４のいずれかに記載のＷｅｂページ閲覧システム。
6. 前記検出手段は、前記リッチコンテンツ領域の画像を所定の間隔で取得する画像取得手段と、前記リッチコンテンツ領域におけるリッチコンテンツの変化後の画像を記憶する記憶手段と、前記画像取得手段により取得された画像と前記記憶手段に記憶された画像とを比較し、両画像の一致度を検出する一致度検出手段と、前記検出された一致度に基づいて前記リッチコンテンツ領域の画像が前記記憶手段に記憶された画像と一致したことが検出されると、リッチコンテンツが変化したと判断する判断手段と、からなることを特徴とする請求項１に記載のＷｅｂページ閲覧システム。
7. 画像の表示が可能な携帯端末と通信し、Ｗｅｂサーバが提供するＷｅｂページを画像化して前記携帯端末に提供する中継サーバであって、
   前記携帯端末からＷｅｂページの閲覧要求があると、前記閲覧要求されたＷｅｂページにリッチコンテンツが含まれているか否かを判別し、リッチコンテンツが含まれている場合には、そのリッチコンテンツが表示されるリッチコンテンツ領域を抽出する抽出手段と、
   前記抽出したリッチコンテンツ領域におけるリッチコンテンツの変化を検出する検出手段と、
   前記閲覧要求に応じてＷｅｂページを前記携帯端末での閲覧用画像データに変換する画像変換手段であって、前記検出手段により前記リッチコンテンツ領域におけるリッチコンテンツの変化が検出されると、画面更新のためにＷｅｂページを前記閲覧用画像データに変換する画像変換手段と、
   前記画像変換手段により変換した閲覧用画像データを前記携帯端末に送信する画像データ送信手段と、
   を備えたことを特徴とする中継サーバ。
8. 前記検出手段は、前記リッチコンテンツ領域の画像を所定の間隔で取得する画像取得手段と、前記画像取得手段により今回取得した画像と前回取得した画像とを比較し、両画像間の変化量を検出する変化量検出手段と、前記検出された変化量に基づいてリッチコンテンツが変化したと判断する判断手段と、からなることを特徴とする請求項７に記載の中継サーバ。
9. 前記判断手段は、前記変化量検出手段により検出された変化量が所定の閾値を越えると、リッチコンテンツが変化したと判断することを特徴とする請求項８に記載の中継サーバ。
10. 前記判断手段は、前記変化量検出手段により検出された変化量が検出された後、所定時間変化が検出されなくなると、リッチコンテンツが変化したと判断することを特徴とする請求項８に記載の中継サーバ。
11. 前記変化量検出手段は、前記画像取得手段により今回取得した画像と前回取得した画像とをそれぞれ縮小させる画像縮小手段と、前記縮小された画像間の相関値を、前記画像間の変化量を示す評価値として算出する算出手段と、を有することを特徴とする請求項８から１０のいずれかに記載の中継サーバ。
12. 前記検出手段は、前記リッチコンテンツ領域の画像を所定の間隔で取得する画像取得手段と、前記リッチコンテンツ領域におけるリッチコンテンツの変化後の画像を記憶する記憶手段と、前記画像取得手段により取得された画像と前記記憶手段に記憶された画像とを比較し、両画像の一致度を検出する一致度検出手段と、前記検出された一致度に基づいて前記リッチコンテンツ領域の画像が前記記憶手段に記憶された画像と一致したことが検出されると、リッチコンテンツが変化したと判断する判断手段と、からなることを特徴とする請求項８に記載の中継サーバ。

Images