(57)【要約】【課題】端末でのテキストファイル解析による処理負荷を削減する。【解決手段】端末３００１とコンテンツサーバとの間にプロキシサーバ２００を配置する。プロキシサーバ２００は、端末３００１からの要求に従ってコンテンツサーバからコンテンツを取得する。そして、取得したＸＭＬ／ＨＴＭＬおよびＣＳＳテキストファイルであった場合は、当該テキストファイルを、プロキシサーバ２００にて端末３００１がサポートしているバイナリフォーマットへ変換し、合成バイナリデータを生成してから端末へ送達する。【選択図】図１
2009211191.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツサーバからウェブページのテキストファイルを含むファイル類を取得して端末へ送達するプロキシサーバにおいて、
端末種別に関する情報と、前記端末種別にて処理可能なテキストファイルの内容の合成バイナリ形式に関する情報とを関連付けした情報テーブルを保持する端末能力テーブル保持手段と、
前記端末種別を含むコンテンツの取得要求を端末から受信する受信手段と、
前記端末から受信された取得要求に従って前記テキストファイルをコンテンツサーバから取得する取得手段と、
前記取得手段により取得されたテキストファイルの内容を解析して、前記テキストファイルからリンクされた他のテキストファイルを判断し、前記取得手段を通じて前記リンクされた他のテキストファイルを前記コンテンツサーバから追加取得する関連ファイル追加取得判断手段と、
前記端末能力テーブル保持手段に保持された情報テーブルを参照して、前記取得要求に含まれた端末種別にて処理可能なテキストファイル内容の合成バイナリ形式を判断する形式判断手段と、
前記取得手段により取得されたテキストファイルおよび他のテキストファイルの内容を用いて、前記形式判断手段により判断された合成バイナリ形式に従った合成バイナリデータを生成する合成バイナリデータ生成手段と、
前記合成バイナリデータ生成手段により生成された合成バイナリデータを、前記取得要求を送信した端末へ配信する合成バイナリデータ配信手段と
を備えることを特徴とするプロキシサーバ。
【請求項２】
コンテンツサーバからウェブページのテキストファイルを含むファイル類を取得して端末へ送達するプロキシサーバにおけるウェブページの提供方法であって、
端末種別に関する情報と、前記端末種別にて処理可能なテキストファイルの内容の合成バイナリ形式に関する情報とを関連付けした情報テーブルを保持する端末能力テーブル保持ステップと、
前記端末種別を含むコンテンツの取得要求を端末から受信する受信ステップと、
受信された前記取得要求に従って前記テキストファイルをコンテンツサーバから取得する取得ステップと、
取得された前記テキストファイルの内容を解析して、前記テキストファイルからリンクされた他のテキストファイルを判断する関連ファイル追加取得判断ステップであって、前記取得ステップは前記リンクされた他のテキストファイルを前記コンテンツサーバから追加取得する関連ファイル追加取得判断ステップと、
保持された前記情報テーブルを参照して、前記取得要求に含まれた端末種別にて処理可能なテキストファイル内容の合成バイナリ形式を判断する形式判断ステップと、
前記取得ステップにおいて取得されたテキストファイルおよび他のテキストファイルの内容を用いて、前記形式判断ステップにおいて判断された合成バイナリ形式に従った合成バイナリデータを生成する合成バイナリデータ生成ステップと、
生成された前記合成バイナリデータを、前記取得要求を送信した端末へ配信する合成バイナリデータ配信ステップと
を備えることを特徴とするウェブページの提供方法。
【請求項３】
ユーザから入力されたネットワーク上のリソースを指定する情報に従って最初のコンテンツの取得要求を送信し、前記最初の取得要求に対する最初の応答を受信し、前記最初の応答中からテキストファイルを抽出し、前記テキストファイルを解析して、該テキストファイルからリンクされている他のテキストファイルを認識し、認識された前記他のテキストファイルを取得するための追加の取得要求を送信し、前記追加取得要求に対する追加応答を受信し、前記追加応答中から前記他のテキストファイルを抽出し、抽出された前記テキストファイルおよび他のテキストファイルの内容を解析して、プログラム内部で利用可能なプログラム内部表現へ変換してからプログラム内部で利用する端末であって、
受信した最初の応答が前記テキストファイルおよび他のテキストファイルの内容を含む合成バイナリデータであるかどうかを判断する判断手段と、
前記合成バイナリデータであると判断された場合には、前記最初の応答の内容を前記内部表現へ展開する合成バイナリデータ展開手段と
を備えることを特徴とする端末。
【請求項４】
ユーザから入力されたネットワーク上のリソースを指定する情報に従って最初のコンテンツの取得要求を送信し、前記最初の取得要求に対する最初の応答を受信し、前記最初の応答中からテキストファイルを抽出し、前記テキストファイルを解析して、該テキストファイルからリンクされている他のテキストファイルを認識し、認識された前記他のテキストファイルを取得するための追加の取得要求を送信し、前記追加取得要求に対する追加応答を受信し、前記追加応答中から前記他のテキストファイルを抽出し、抽出された前記テキストファイルおよび他のテキストファイルの内容を解析して、プログラム内部で利用可能なプログラム内部表現へ変換してからプログラム内で利用する端末におけるウェブページの解析方法であって、
受信した最初の応答が前記テキストファイルおよび他のテキストファイルの内容を含む合成バイナリデータであるかどうかを判断する判断ステップと、
前記合成バイナリデータであると判断された場合には、前記最初の応答の内容を前記内部表現へ展開する合成バイナリデータ展開ステップと
を備えることを特徴とするウェブページの解析方法。
【請求項５】
請求項３に記載の端末であって、
受信した前記最初の取得要求に含まれたコンテンツ内容が、前記テキストファイルの内容を含んだ合成バイナリデータであった場合には、前記他のテキストファイルを取得するための追加取得要求は不要であると判断し、前記他のテキストファイルを取得するための追加取得要求の送信を実施しないことを特徴とする端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は端末能力に応じたウェブページ解析時間高速化システムにおけるプロキシサーバ、端末、ウェブ（Ｗｅｂ）ページの提供方法および解析方法に関し、より具体的には、端末からのウェブページ取得要求に応じてコンテンツサーバからコンテンツを取得し、取得されたコンテンツを要求元端末へ返信するプロキシサーバ、および、プロキシサーバへウェブページ取得要求を送信し、それに対する応答を受信する端末、ならびにウェブページの提供方法および解析方法に関する。
【背景技術】
【０００２】
ウェブページ閲覧サービスの高速化を実現する技術として、以下のような方法が知られている。
【０００３】
（１）例えば、取得されるべきコンテンツをコンテンツサーバ側で圧縮し、伝送路上のデータ通信を効率化することで、コンテンツのダウンロードに要する通信時間を短縮する技術が広く採用されている。端末は、受信した前記圧縮済みコンテンツを伸張し、そこから得られたＸＭＬ（Extensible Markup Language）／ＨＴＭＬ（HyperText Markup Language）およびＣＳＳ（Cascading Style Sheets）テキストファイルを解析する。
【０００４】
ここで、ＸＭＬ／ＨＴＭＬは表示されるべき要素（内容）を指示する仕様であり、またＣＳＳは前記要素（内容）をどのように修飾（表示）するかを指示する仕様であり、両者ともＷ３Ｃ（World Wide Web Consortium）により勧告されている国際標準の構造化文書の技術である。
【０００５】
（２）一方、従来のＸＭＬ／ＨＴＭＬはテキストファイルとして記述されている。このため、ＸＭＬ／ＨＴＭＬテキストファイルを取得した端末は、端末内のプログラムがテキストファイルを解析し、利用可能なプログラム内部表現へ変換してからでなければ、ＸＭＬ／ＨＴＭＬファイルの内容を利用することはできない。しかしテキスト解析に要する処理負荷は比較的大きい。特に、デスクトップＰＣと比較して演算能力が劣る移動端末にとっては処理負荷が大きな問題となっている。このような背景の下、標準化団体Ｗ３ＣのＥＸＩ（Ｅｆｆｉｃｉｅｎｔ  ＸＭＬ  Ｉｎｔｅｒｃｈａｎｇｅ） ＷＧでは、ＸＭＬ／ＨＴＭＬファイルの本質的な内容を維持したまま、解析処理をより効率的に実施可能な新たなバイナリフォーマットの勧告化作業を実施中である。
【０００６】
（３）また、その他の取り組みとして、ウェブコンテンツサーバソフトがローカルホスト上のウェブブラウザから送られる対応モードコードを入手し、対応モードコードに応じてＨＴＭＬファイルまたは中間コードファイルを送信する技術が知られている（例えば特許文献１参照）。
【０００７】
（４）また、内部データモデルをサポートしている端末と、内部データモデルをサポートしていないコンテンツサーバとの間に変換コンテンツサーバを置き、コンテンツサーバから取得したＸＭＬ／ＨＴＭＬテキストファイルを、変換コンテンツサーバにて内部データモデルへ変換してから、その変換された内部データモデルを端末へ送達する方法が知られている（例えば特許文献２参照）。
【０００８】
（５）更に、コンテンツ取得を要求してきた端末のメディア処理能力を判断し、コンテンツサーバから取得したコンテンツを当該端末のメディア処理能力に合わせて適宜変換処理を施してから、当該端末へ配信することによって、端末におけるコンテンツ利用の可能性を確保する技術が存在する（例えば特許文献３参照）。
【０００９】
【特許文献１】特開２０００−５７０４４号公報
【特許文献２】特開２００１−５７４５号公報
【特許文献３】特表２００５−５２７８８１号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかし、（１）では、伝送路上における通信の効率化は実現できても、ＸＭＬ／ＨＴＭＬおよびＣＳＳテキストファイルを受信した端末側での、テキスト解析処理の負荷は一切削減することはできない。
【００１１】
また、（２）の場合、端末側およびコンテンツサーバ側の双方で、Ｗ３Ｃ  ＥＸＩ  ＷＧが定めるバイナリフォーマット（以下、「ＥＸＩフォーマット」という）をサポートする必要がある。例えば、端末側がＥＸＩフォーマットをサポートしていても、コンテンツサーバ側がＥＸＩフォーマットをサポートしていなければ、コンテンツサーバ側はテキスト形式のＸＭＬ／ＨＴＭＬファイルを返信してしまうため、端末側の能力を活用することができない。
【００１２】
また、（３）によれば、コンテンツサーバ側および端末側の双方が中間コードに対応していれば、端末からの取得要求に対して、コンテンツサーバ側から中間コード化済みのコンテンツを返信することで、端末側の解析処理負荷を低減することができる。しかし、端末側のみ中間コードに対応していて、コンテンツサーバ側が対応していないような場合、端末からの取得要求に対して、コンテンツサーバ側はＨＴＭＬテキストファイルを返信することになる。このため、端末側はテキストファイルに対する解析処理を実施しなくてはならず、せっかくの端末側の中間コードを処理する能力を活用することができない、という先述と同様の問題が発生する。
【００１３】
更に、（３）によれば、端末側からコンテンツサーバ側へ取得要求を行う際、対応モードコードなる追加情報を併せて送信する必要がある。このため、その分だけ要求信号のデータサイズが増大してしまう、という問題がある。
【００１４】
ところで、今日広く使用されているウェブブラウザの多く（Ｆｉｒｅｆｏｘ、Ｋｏｎｑｕｅｒｏｒ、Ｓａｆａｒｉ等）は、ＪａｖａＳｃｒｉｐｔに対してＸＭＬ／ＨＴＭＬおよびＣＳＳファイルの内容を操作するためのＩ／Ｆを提供するために、ＸＭＬ／ＨＴＭＬおよびＣＳＳファイルの内容を、Ｗ３Ｃで標準化されたＤＯＭ（ドキュメント・オブジェクト・モデル）に則った形式でプログラム内部表現化し、プログラム内に保持する。ここで、ＤＯＭとはＸＭＬ／ＨＴＭＬおよびＣＳＳファイル内容を操作するためのインターフェース仕様を規定しているのみであって、具体的なバイナリフォーマットを定めるものではない。つまり、プログラム内におけるＸＭＬ／ＨＴＭＬおよびＣＳＳファイルのプログラム内部表現のバイナリフォーマットは、プログラム実装に依存しており、互いの実装間での互換性は無いのが一般的である。再びＥＸＩフォーマットについて述べるが、ＥＸＩフォーマットはＷ３Ｃにて勧告化されようとしている汎用フォーマットである。つまり、ＥＸＩフォーマットで記述されたＸＭＬ／ＨＴＭＬファイルを受信した端末は、やはりその内容を解析し、自実装に沿ったプログラム内部表現へ変換しなくてはならない。確かに、ＥＸＩフォーマットの解析処理負荷は、テキストファイルに対する解析処理負荷よりは相対的に小さくなることが期待される。しかし、解析処理負荷の軽減という観点からすれば、まだ改善の余地がある。
【００１５】
また、（４）によれば、変換コンテンツサーバと全端末が、唯一のフォーマットである内部データモデルをサポートすることを前提としている。このため、端末毎にサポートするバイナリフォーマットが異なる状況には対応することができないという問題がある。
【００１６】
このような問題に対処する（５）によれば、端末のメディア処理能力に応じて適切なフォーマットへ変換するコンテンツ変換処理が行われる。しかしながら、特許文献３の技術では、端末が複数のコンテンツを取得する必要がある場合、端末が送信しなければならないＨＴＴＰリクエストの総数を削減することができないという問題がある。
【００１７】
本発明はこのような問題に鑑みてなされたものであり、その目的とするところは、端末におけるウェブページ解析時間を短縮することができるプロキシサーバ、端末、ウェブページの提供方法および解析方法を提供することにある。
【００１８】
また、本発明の目的とするところは、ウェブページ表示のために端末が送信する必要のあるＨＴＴＰリクエストの総数を削減することによって、端末上におけるウェブページ表示完了までに要する総所要時間を短縮することができるプロキシサーバ、端末、ウェブページの提供方法および解析方法を提供することにある。
【課題を解決するための手段】
【００１９】
上記問題を解決するために、本発明では、端末とコンテンツサーバとの間にプロキシサーバを配置し、そのプロキシサーバにて、端末からの要求に従ってコンテンツサーバからウェブページを構成する各コンテンツを取得する過程において、最初に取得したＸＭＬ／ＨＴＭＬテキストファイルの内容を解析する。次いで、そのテキストファイルからリンクされているＣＳＳテキストファイルを追加取得する。そして、取得し終えたＸＭＬ／ＨＴＭＬおよびＣＳＳテキストファイルの内容を、合成バイナリデータ化してから端末へ送達する。このようにして、従来は端末から送信する必要があったＣＳＳテキストファイル取得のためのＨＴＴＰリクエストを、送信不要とした。
【００２０】
また、上記プロキシサーバ上に、端末種別情報と、当該端末種別がサポートしている合成バイナリデータのフォーマットに関する情報とを収録した端末能力テーブルを予め配置して、端末ごとに適切な合成バイナリデータを生成できるようにした。これにより、端末におけるテキストファイル解析の処理負荷を削減することができるようにした。
【００２１】
更に、上記プロキシサーバ上に端末能力テーブルを配置することによって、従来の方法で端末からプロキシサーバへ通知されてくるＵｓｅｒ−Ａｇｅｎｔ情報だけで、当該端末がサポートしている合成バイナリデータのフォーマットを判断できるようにした。
【００２２】
本発明に係るプロキシサーバは、コンテンツサーバからウェブページのテキストファイルを含むファイル類を取得して端末へ送達するプロキシサーバにおいて、端末種別に関する情報と、前記端末種別にて処理可能なテキストファイルの内容の合成バイナリ形式に関する情報とを関連付けした情報テーブルを保持する端末能力テーブル保持手段と、前記端末種別を含むコンテンツの取得要求を端末から受信する受信手段と、前記端末から受信された取得要求に従って前記テキストファイルをコンテンツサーバから取得する取得手段と、前記取得手段により取得されたテキストファイルの内容を解析して、前記テキストファイルからリンクされた他のテキストファイルを判断し、前記取得手段を通じて前記リンクされた他のテキストファイルを前記コンテンツサーバから追加取得する関連ファイル追加取得判断手段と、前記端末能力テーブル保持手段に保持された情報テーブルを参照して、前記取得要求に含まれた端末種別にて処理可能なテキストファイル内容の合成バイナリ形式を判断する形式判断手段と、前記取得手段により取得されたテキストファイルおよび他のテキストファイルの内容を用いて、前記形式判断手段により判断された合成バイナリ形式に従った合成バイナリデータを生成する合成バイナリデータ生成手段と、前記合成バイナリデータ生成手段により生成された合成バイナリデータを、前記取得要求を送信した端末へ配信する合成バイナリデータ配信手段とを備える。
【００２３】
本発明の別の態様によれば、本発明に係るウェブページの提供方法は、コンテンツサーバからウェブページのテキストファイルを含むファイル類を取得して端末へ送達するプロキシサーバにおけるウェブページの提供方法であって、端末種別に関する情報と、前記端末種別にて処理可能なテキストファイルの内容の合成バイナリ形式に関する情報とを関連付けした情報テーブルを保持する端末能力テーブル保持ステップと、前記端末種別を含むコンテンツの取得要求を端末から受信する受信ステップと、受信された前記取得要求に従って前記テキストファイルをコンテンツサーバから取得する取得ステップと、取得された前記テキストファイルの内容を解析して、前記テキストファイルからリンクされた他のテキストファイルを判断する関連ファイル追加取得判断ステップであって、前記取得ステップは前記リンクされた他のテキストファイルを前記コンテンツサーバから追加取得する関連ファイル追加取得判断ステップと、保持された前記情報テーブルを参照して、前記取得要求に含まれた端末種別にて処理可能なテキストファイル内容の合成バイナリ形式を判断する形式判断ステップと、前記取得ステップにおいて取得されたテキストファイルおよび他のテキストファイルの内容を用いて、前記形式判断ステップにおいて判断された合成バイナリ形式に従った合成バイナリデータを生成する合成バイナリデータ生成ステップと、生成された前記合成バイナリデータを、前記取得要求を送信した端末へ配信する合成バイナリデータ配信ステップとを備える。
【００２４】
本発明の別の態様によれば、本発明に係る端末は、本発明に係る端末は、ユーザから入力されたネットワーク上のリソースを指定する情報に従って最初のコンテンツの取得要求を送信し、前記最初の取得要求に対する最初の応答を受信し、前記最初の応答中からテキストファイルを抽出し、前記テキストファイルを解析して、該テキストファイルからリンクされている他のテキストファイルを認識し、認識された前記他のテキストファイルを取得するための追加の取得要求を送信し、前記追加取得要求に対する追加応答を受信し、前記追加応答中から前記他のテキストファイルを抽出し、抽出された前記テキストファイルおよび他のテキストファイルの内容を解析して、プログラム内部で利用可能なプログラム内部表現へ変換してからプログラム内部で利用する端末であって、受信した最初の応答が前記テキストファイルおよび他のテキストファイルの内容を含む合成バイナリデータであるかどうかを判断する判断手段と、前記合成バイナリデータであると判断された場合には、前記最初の応答の内容を前記内部表現へ展開する合成バイナリデータ展開手段とを備える。
【００２５】
本発明の別の態様によれば、本発明に係るウェブページの解析方法は、ユーザから入力されたネットワーク上のリソースを指定する情報に従って最初のコンテンツの取得要求を送信し、前記最初の取得要求に対する最初の応答を受信し、前記最初の応答中からテキストファイルを抽出し、前記テキストファイルを解析して、該テキストファイルからリンクされている他のテキストファイルを認識し、認識された前記他のテキストファイルを取得するための追加の取得要求を送信し、前記追加取得要求に対する追加応答を受信し、前記追加応答中から前記他のテキストファイルを抽出し、抽出された前記テキストファイルおよび他のテキストファイルの内容を解析して、プログラム内部で利用可能なプログラム内部表現へ変換してからプログラム内で利用する端末におけるウェブページの解析方法であって、受信した最初の応答が前記テキストファイルおよび他のテキストファイルの内容を含む合成バイナリデータであるかどうかを判断する判断ステップと、前記合成バイナリデータであると判断された場合には、前記最初の応答の内容を前記内部表現へ展開する合成バイナリデータ展開ステップとを備える。
【００２６】
また、上記端末において、受信した前記最初の取得要求に含まれたコンテンツ内容が、前記テキストファイルの内容を含んだ合成バイナリデータであった場合には、前記他のテキストファイルを取得するための追加取得要求は不要であると判断し、前記他のテキストファイルを取得するための追加取得要求の送信を実施しないものとすることができる。
【発明の効果】
【００２７】
本発明によれば、端末とコンテンツサーバとの間にプロキシサーバを配置し、端末からの要求に従ってコンテンツサーバからコンテンツを取得する。そして、取得したＸＭＬ／ＨＴＭＬおよびＣＳＳテキストファイルであった場合は、当該テキストファイルを、プロキシサーバにて、取得要求してきた端末がサポートしている合成バイナリデータへ合成・変換してから端末へ送達する。従って、端末によるテキストファイルの解析処理を不要にし、端末にかかる解析処理負荷を軽減できるようになる。
【００２８】
また、本発明によれば、プロキシサーバがコンテンツサーバからＸＭＬ／ＨＴＭＬテキストファイルを取得した場合、プロキシサーバにてその内容を解析し、そこからリンクされている全てのＣＳＳテキストファイルを追加取得して、得られた全てのＸＭＬ／ＨＴＭＬおよびＣＳＳテキストファイルを一つの合成バイナリデータとしてから端末へ送達する。従って、本来であれば端末がＣＳＳテキストファイルの取得のために必要であった取得要求信号の送信、および、それに対する応答の受信を不要とし、その分の端末側負荷を削減できるようになる。
【００２９】
また、副次的効果として、端末−プロキシサーバ間の取得要求／応答信号に付随するオーベーヘッド（例えばＴＣＰ／ＩＰヘッダ、ＨＴＴＰヘッダなど）を削減する効果も発揮される。
【発明を実施するための最良の形態】
【００３０】
以下、図面を参照し、本発明の好適な実施の形態について説明する。
【００３１】
図１は、本発明の一実施形態に係るプロキシサーバの機能構成を示すブロック図である。
【００３２】
ファイル取得判断部２９９１では、端末３００１、３００２、３００３から受信した取得要求信号の内容が判断される。
【００３３】
端末能力テーブル保持部２０２には、端末能力テーブルが保存される。
【００３４】
ファイル保存部２９９３には、コンテンツに関わるデータが保存（キャッシュ）される。
【００３５】
通信制御部２９９９では、ネットワーク１００を介して不図示のコンテンツサーバとの通信が行われる。
【００３６】
ファイル保存処理部２９９２では、コンテンツをファイル保存部２９９３へ保存するための処理が行われる。
【００３７】
ファイル読出部２９９４では、ファイル保存部２９９３に保存されたデータの読出しが行われる。
【００３８】
関連ファイル追加取得判断部２０１では、コンテンツとその付随情報（取得元ＵＲＬなど）が受信・解析される。
【００３９】
フォーマット判断部２０３では、端末能力テーブルから、生成すべき合成バイナリデータのフォーマットが判断される。
【００４０】
合成バイナリデータ生成部２０４では、受信したテキストファイルから合成バイナリデータが生成される。
【００４１】
合成バイナリデータ保存処理部２０５では、合成バイナリデータをファイル保存部２９９３内に保存する処理が行われる。
【００４２】
合成バイナリデータ読出部２０６では、ファイル保存部２９９３に保存された合成バイナリデータの読み出し処理が行われる。
【００４３】
通信制御部２９９８では、端末３００１、３００２、３００３との通信が行われる。
【００４４】
プロキシサーバ２００が有するこれらの機能は、当該プロキシサーバを構成するコンピュータのＣＰＵが記憶装置に記憶されたプログラムをメモリに読み出し、当該プログラムの命令を実行することにより達成される。
【００４５】
図２は、本発明の一実施形態に係る端末の機能構成を示すブロック図である。なお、同図は、図１に示す端末３００１、３００２、３００３のいずれにも適用される。
【００４６】
ユーザインターフェース３９１は、ユーザとの対話に利用されるものであり、これによりユーザからの指示が入力される。
【００４７】
通信制御部３９９では、プロキシサーバ２００との通信が行われる。
【００４８】
ファイル種別判断部３０１では、当該受信した応答に含まれる内容が、合成バイナリデータであるかどうか判断される。
【００４９】
合成バイナリデータ展開部３０２では、合成バイナリデータを本来のプログラム内部表現を生成するための所要の展開処理が実施される。
【００５０】
テキストファイル解析部３９８では、ＸＭＬ／ＨＴＭＬおよびＣＳＳテキストファイルが解析される。
【００５１】
ファイル取得要求部３９２では、通信制御部３９９を通じてプロキシサーバ２００に取得要求を送信するための処理が行われる。
【００５２】
内部表現利用部３９７では、プログラム内部表現化されたコンテンツ内容が利用され、これによりディスプレイへのコンテンツの表示処理等が行われる。
【００５３】
端末３００１、３００２、３００３が有するこれら機能は、当該端末を構成するコンピュータのＣＰＵが記憶装置に記憶されたプログラムをメモリに読み出し、当該プログラムの命令を実行することにより達成される。
【００５４】
次に、図３を参照し、本実施形態に係るウェブページの提供方法について説明する。
【００５５】
いま、端末３００１のユーザが、端末上のユーザインターフェース３９１を用い、従来の方法に従ってＷｅｂコンテンツの閲覧を指示したとする。その指示内容に基づいて、ファイル取得要求部３９２は、従来の方法に従って、Ｗｅｂコンテンツの取得要求を生成する。この取得要求は、通信制御部３９９を介して、プロキシサーバ２００へ送達されることになる。
【００５６】
端末３００１からのコンテンツ取得要求を受信した通信制御部２９９８は、当該取得要求信号をファイル取得判断部２９９１へ通知する（ステップＳ４０１）。
【００５７】
ファイル取得判断部２９９１は、従来の方法に則り、当該取得要求信号の内容から、取得要求してきた端末のＵｓｅｒ−Ａｇｅｎｔ情報を検出する。具体的説明のため、ここではＵｓｅｒ−Ａｇｅｎｔ情報が「ＵＡ−ＸＸＸ」であると仮定する。当該Ｕｓｅｒ−Ａｇｅｎｔ情報を検出したファイル取得判断部２９９１は、端末能力テーブル保持部２０２に保持されている端末能力テーブルを参照し、当該取得要求してきた端末がサポートしているフォーマットを、“実装依存ＸＸＸ”であると判断する（ステップＳ４０２）。
【００５８】
図４に、端末能力テーブル保持部２０２に保持される端末能力テーブルの具体例を示す。端末能力テーブル５０１には、Ｕｓｅｒ−Ａｇｅｎｔ種別と、合成バイナリデータのフォーマット情報が関連付けられている。図中、「非対応」とは、合成バイナリデータを受信することができない端末であることを示す。
【００５９】
またファイル取得判断部２９９１は、従来の方法に則り、上記取得要求信号の内容から、コンテンツ取得を問い合わせるべきＵＲＬを判断する。ここで、「ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／」であると検出したとする。また、ファイル保存部２９９３には、取得元ＵＲＬが「ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／」に該当する、“実装依存ＸＸＸ”形式の合成バイナリデータファイルは保存されていないものとする。この場合ファイル取得判断部２９９１は、利用可能なキャッシュファイルが存在しないものと判断し（ステップＳ４０３：判断＝“ＮＯ”）、合成バイナリデータの元となるコンテンツを取得するため、通信制御部２９９９を通じて、従来の方法に従ってコンテンツサーバに対してコンテンツの取得要求を実施する（ステップＳ４０４）。
【００６０】
なお、本実施形態では、合成バイナリデータの元となるコンテンツの取得要求をコンテンツサーバへ送信するようにしたが、当該元コンテンツが従来の方法に従ってプロキシサーバ内にキャッシュされている場合は、当該元コンテンツのキャッシュを従来の方法に従って再利用するようにしても良い。例えば通信制御部２９９９は、該当する元コンテンツがファイル保存部２９９３内にキャッシュされている場合、ファイル読出部２９９４を介して当該元コンテンツを読み出すことも可能であろう。しかし以降においては、説明を簡略化するため、取得要求をコンテンツサーバへ送信するケースに限定して記述する。
【００６１】
ファイル取得判断部２９９１は、取得要求してきた端末が合成バイナリデータをサポートしていることを判断済みである。このため、コンテンツ取得要求に対する応答としてＸＭＬ／ＨＴＭＬテキストファイルを取得できた場合、関連ファイル追加取得判断部２０１に対して、当該ＸＭＬ／ＨＴＭＬテキストファイルの内容を解析したうえで、そこからリンクされているＣＳＳテキストファイルを追加取得するよう、下記のように指示を行っておく。
【００６２】
プロキシサーバ２００からの取得要求に対して、コンテンツサーバからｉｎｄｅｘ．ｈｔｍｌ（ＨＴＭＬテキストファイル）が返信されてきたと仮定する。当該応答を受信（ステップＳ４０５）した通信制御部２９９９は、受信した応答信号中からコンテンツ（上記ｉｎｄｅｘ．ｈｔｍｌ）を抽出する。そして、後の再利用のために、受信した応答信号中から抽出したコンテンツを従来の方法に従って保存（キャッシュ）するよう、ファイル保存処理部２９９２へ指示する。当該指示を受けたファイル保存処理部２９９２は、受信したコンテンツをファイル保存部２９９３へ保存（キャッシュ）する。併せて、通信制御部２９９９は、抽出したコンテンツ（上記ｉｎｄｅｘ．ｈｔｍｌ）とその付随情報（取得元ＵＲＬ等）を、関連ファイル追加取得判断部２０１へ引き渡す。
【００６３】
ＨＴＭＬテキストファイルを受け取った関連ファイル追加取得判断部２０１は、そのテキスト内容を解析して、そこからリンクされているＣＳＳテキストファイル群に関する情報（当該ＣＳＳテキストファイルを取得するために必要となるＵＲＬ等）を抽出する。この情報から、未取得のものが存在すると判断された場合（ステップＳ４０６：判断＝“ＮＯ”）、当該ＣＳＳテキストファイル群を追加取得するため、通信制御部２９９９を通じて、コンテンツサーバに対してコンテンツの追加取得要求を実施する（ステップＳ４０７）。
【００６４】
プロキシサーバ２００からの追加の取得要求に対して、コンテンツサーバからｓｔｙｌｅ．ｃｓｓ（ＣＳＳテキストファイル）が返信されてきたと仮定する。当該応答を受信した通信制御部２９９９は、後の再利用のために、受信した応答信号中から抽出したコンテンツ（上記ｓｔｙｌｅ．ｃｓｓ）を従来の方法に従って保存（キャッシュ）するよう、ファイル保存処理部２９９２へ指示する。当該指示を受けたファイル保存処理部２９９２は、受信したコンテンツをファイル保存部２９９３へ保存（キャッシュ）する。併せて、通信制御部２９９９は、抽出したコンテンツ（上記ｓｔｙｌｅ．ｃｓｓ）とその付随情報（取得元ＵＲＬなど）を、関連ファイル追加取得判断部２０１へ引き渡す。
【００６５】
ＣＳＳテキストファイルを受け取った関連ファイル追加取得判断部２０１は、そのＵＲＬ情報等から、当該ＣＳＳテキストファイル（ｓｔｙｌｅ．ｃｓｓ）が関連しているＨＴＭＬテキストファイル（ｉｎｄｅｘ．ｈｔｍｌ）を判断する。
【００６６】
このような追加の取得要求は、最初に受信されたＨＴＭＬテキストからリンクされている全てのＣＳＳテキストファイルを取得し終えるまで、何度も繰り返されることになる（ステップＳ４０５、Ｓ４０６、Ｓ４０７のループ）。
【００６７】
ここで、ＨＴＭＬテキストファイルおよびＣＳＳテキストファイルの具体例を図５に示す。本実施形態においては、ＨＴＭＬテキストファイル６０１からリンクされているＣＳＳテキストファイル６０２は１個であるため、上記追加取得要求の実施は１回となる。
【００６８】
ＨＴＭＬテキストファイルからリンクされている全てのＣＳＳテキストファイルの取得が完了した（ステップＳ４０６：判断＝“ＹＥＳ”）と判断した関連ファイル追加取得判断部２０１は、それら全てのテキストファイルを、合成バイナリデータ生成部２０４へ引き渡す。
【００６９】
上記全てのテキストファイルを受け取った合成バイナリデータ生成部２０４は、フォーマット判断部２０３から、生成すべき合成バイナリデータのフォーマットに関する情報を入手する。ここでの例では、生成すべき合成バイナリデータのフォーマットは前述のとおり“実装依存ＸＸＸ”である。
ここで、“実装依存ＸＸＸ”フォーマットの例として、合成バイナリデータの具体例を１つ示す。“実装依存ＸＸＸ”フォーマットは、標準化団体Ｗ３Ｃで規定されているＤＯＭ仕様に則した形式であるとする。しかし前述のように、ＤＯＭ仕様ではＸＭＬ／ＨＴＭＬおよびＣＳＳテキスト内容に関するプログラム内部表現の具体的なバイナリフォーマットが規定されているわけではない。そのため、ＤＯＭ仕様に則したプログラム内部表現は、プログラム実装によって変化することになる。図６は、図５の内容を、ＤＯＭ標準仕様に則して、抽象的なツリー構造として書き表したものである。
【００７０】
これをより具体的なプログラム内部表現の一例として更に表現し直したものが図７である。プログラム内部表現では、ノード間のつながりを表現する手段として、例えばＣ言語等に見られるポインタを用いることができる。しかし、ポインタの内容は、一般にプログラムのプロセス毎に変化するものであるため、その内容をそのまま別のプログラムプロセスへ通知しても、意味を成すものにはならない。また、メモリ上に存在するプログラム内部表現では、その全ての内容がメモリ上の１箇所に隙間無く連続して集合しているとは限らない。よって、その内容を通信路上で送達可能とし、その内容を別のプログラムプロセス上で解釈可能とするためには、何らかの直列化（シリアライゼーション）処理が必要である。図７の内容を直列化した一例を図８に示す。以下の説明では、図８の内容を、“実装依存ＸＸＸ”形式として扱う。
【００７１】
再び図３の説明に戻ると、全てのテキストファイルを受け取り、かつ、生成すべき合成バイナリデータのフォーマットに関する情報を入手した合成バイナリデータ生成部２０４は、合成バイナリデータを生成する（ステップＳ４０８）。生成された合成バイナリデータは、当該合成バイナリデータの元となったコンテンツに関する付随情報（コンテンツの取得先ＵＲＬなど）と共に、後の再利用の目的のために合成バイナリデータ保存処理部２０５を介してファイル保存部２９９３内にキャッシュされる。（ステップＳ４１０）、また、合成バイナリデータ生成部２０４は、当該合成バイナリデータを通信制御部２９９８へ引き渡す。
【００７２】
当該合成バイナリデータを受け取った通信制御部２９９８は、コンテンツの取得要求をしてきたＵｓｅｒ−Ａｇｅｎｔ情報が「ＵＡ−ＸＸＸ」であるところの端末へ、要求に対する応答として、当該合成バイナリデータを送達する（ステップＳ４０９）。
【００７３】
続いて、図９を参照し、合成バイナリデータを受信した端末側の動作について説明する。
【００７４】
Ｕｓｅｒ−Ａｇｅｎｔ情報が「ＵＡ−ＸＸＸ」であるところの端末３００１は、通信制御部３９９により、コンテンツ取得要求に対する応答としてプロキシサーバ２００から上記合成バイナリデータを受信（ステップＳ７９１）する。ファイル種別判断部３０１は、当該受信した応答に含まれる内容が、合成バイナリデータであるかどうかを判断する。判断の方法として、例えば、ＨＴＴＰ のＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダの値を用いる、などの方法が考えられる。本実施形態では、合成バイナリデータであると判断（ステップＳ７０１：判断＝“ＹＥＳ”）される。応答信号から抽出された合成バイナリデータは、合成バイナリデータ展開部３０２に渡される。
【００７５】
合成バイナリデータを渡された合成バイナリデータ展開部３０２では、当該合成バイナリデータから、本来のプログラム内部表現を生成するための所要の展開処理を実施し（ステップＳ７０２）、生成されたプログラム内部表現を内部表現利用部３９７へ渡す。ここで、プログラム内部表現プログラムの実装に依存する。また、プログラム内部表現を生成するための所要の展開処理もまたプログラムの実装に依存し、本実施形態では図８の形式から図７への形式への変換に該当する。
【００７６】
合成バイナリデータ展開部３０２は、受け取った合成バイナリデータの内容から、ＣＳＳファイル以外の各種スクリプト／画像等のファイル類がリンクされているかどうかを判断する。そして、各種スクリプト／画像等のファイル類がリンクされていると判断した場合（ステップＳ７０３：判断＝“ＹＥＳ”）には、それらを取得するための追加の取得要求を実施するよう、ファイル取得要求部３９２へ指示し（ステップＳ７９５）、その応答を受信することによってファイルを取得する（ステップＳ７９１）。ただし、ＣＳＳファイルに関するリンクを発見した場合は、既に合成バイナリデータ中に相応の内容が含まれているため、当該ＣＳＳファイルのための追加の取得要求は行わない。
【００７７】
プログラム内部表現化されたコンテンツ内容を渡された内部表現利用部３９７は、従来の方法に従って、当該プログラム内部表現化されたコンテンツ内容を利用する（ステップＳ７９６）。
【００７８】
なお、上記の端末側動作の説明においては、プロキシサーバから合成バイナリデータが送達されてきた場合について述べたが、本発明に従うプロキシサーバが存在しない環境においては、通常のＸＭＬ／ＨＴＭＬおよびＣＳＳテキストファイルが送達されてくる場合も考えられる。ここで、この場合について述べる。
【００７９】
端末３００１は、通信制御部３９９により、コンテンツ取得要求に対する応答として、プロキシサーバ２００から通常のＸＭＬ／ＨＴＭＬおよびＣＳＳテキストファイルを受信する。ファイル種別判断部３０１にて、当該受信した応答信号に含まれる内容が、合成バイナリデータではないと判断（ステップＳ７０１：判断＝“ＮＯ”）し、かつ、解析対象のテキストファイルであると判断（ステップＳ７９２：判断＝“ＹＥＳ”）する。この場合、受信されたＸＭＬ／ＨＴＭＬおよびＣＳＳテキストファイルは、テキストファイル解析部３９８へ渡される。テキストファイル解析部３９８は、従来の方法に従って解析処理を施し（ステップＳ７９３）、生成されたプログラム内部表現を内部表現利用部３９７へ渡す。また、テキストファイル解析部３９８は、受け取ったテキストファイルの内容から、従来の方法に従ってリンクされているファイル群を検出（ステップＳ７９４：判断＝“ＹＥＳ”）する。そして、それらファイル群を取得するための追加の取得要求を実施するよう、ファイル取得要求部３９２へ指示する（ステップＳ７９５）。
【００８０】
ちなみに、通信制御部３９９により受信された、コンテンツ取得要求に対する応答信号に含まれる内容が、合成バイナリデータではなく（ステップＳ７０１：判断＝“ＮＯ”）、また解析対象のテキストファイルでもない（ステップＳ７９２：判断＝“ＮＯ”）場合は、従来の方法に従って、内部表現利用部３９７にて利用される。
【００８１】
（他の実施形態）
以上で、本発明に纏わる基本的な処理の流れの説明は一通り完了した。以下では、再び、図３を参照し、プロキシサーバ側について、更にいくつかの処理の流れについて言及する。
【００８２】
再び、Ｕｓｅｒ−Ａｇｅｎｔ情報が「ＵＡ−ＸＸＸ」であるところの端末３００１から、前回と同じ「ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／」宛のコンテンツ取得要求をプロキシサーバ２００が受信したとする。当該取得要求を受信した通信制御部２９９８は、当該取得要求をファイル取得判断部２９９１へ通知する（ステップＳ４０１）。
【００８３】
ファイル取得判断部２９９１は、従来の方法に則り、当該取得要求信号の内容から、取得要求してきた端末のＵｓｅｒ−Ａｇｅｎｔ情報が「ＵＡ−ＸＸＸ」であると検出する。当該Ｕｓｅｒ−Ａｇｅｎｔ情報を検出したファイル取得判断部２９９１は、端末能力テーブル保持部２０２に保持されている端末能力テーブル（図４）を参照し、当該取得要求してきた端末がサポートしているフォーマットを、“実装依存ＸＸＸ”であると判断する（ステップＳ４０２）。
【００８４】
またファイル取得判断部２９９１は、従来の方法に則り、上記取得要求信号の内容から、コンテンツ取得を問い合わせるべきＵＲＬが「ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／」であると検出する。今回は、ファイル保存部２９９３には、取得元ＵＲＬが「ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／」に該当する、“実装依存ＸＸＸ”形式の合成バイナリデータファイルが保存されているため、ファイル取得判断部２９９１は、利用可能なキャッシュファイルが存在するものと判断し（ステップＳ４０３：判断＝“ＹＥＳ”）し、合成バイナリデータ読出部２０６に対して、該当のキャッシュ済み合成バイナリデータを読み出して、要求元端末３００１へ送達するよう指示する。
【００８５】
当該指示を受けた合成バイナリデータ読出部２０６は、該当の合成バイナリデータを読み出したうえで、通信制御部２９９８を介して、要求元端末３００１へ送達する（ステップＳ４０９）。
【００８６】
次に、Ｕｓｅｒ−Ａｇｅｎｔ情報が「ＵＡ−ＺＺＺ」であるところの端末３００３から、コンテンツ取得要求をプロキシサーバ２００が受信したとする。この場合、本発明に従うプロキシサーバは、当該端末が合成バイナリデータを受信できないことを検出するため、取得要求されたコンテンツについて合成バイナリデータを生成したうえで当該端末へ送達するようなことはしない。プロキシサーバ２００は、従来の方法に従った通常のウェブ・プロキシサーバとして動作することになるが、従来の方法の動作であるため詳細な説明は省略する。
【００８７】
端末−プロキシサーバ間の取得要求／応答のシーケンス例を図１０に示す。図１０の例では、端末−プロキシサーバ間の１組の取得要求／応答によって、端末はＸＭＬ／ＨＴＭＬテキストファイルとＣＳＳテキストファイルの２ファイル分の情報を入手することが可能である。
【００８８】
以上、本発明の好適な実施形態について説明したが、この開示の一部をなす文および図面は、本発明を限定するものであると理解すべきではない。この開示から、当業者には様々な代替実施形態、実施例および運用技術が明らかとなるであろう。
【図面の簡単な説明】
【００８９】
【図１】本発明の一実施形態に係るプロキシサーバが備える機能と、各機能間の関係を示すブロック図である。
【図２】本発明の一実施形態に係る端末が備えるべき機能と、各機能間の関係を図示したものである。
【図３】本発明の一実施形態に係るプロキシサーバにおける処理を示すフロー図である。
【図４】端末能力テーブル保持部にて保持される端末能力テーブルの例を示す図である。
【図５】本発明の一実施形態に係るＨＴＭＬテキストファイルおよびＣＳＳテキストファイルを示す図である。
【図６】本発明の一実施形態に係る図５の内容から生成されるプログラム内部表現を抽象的にツリー構造として表現し直した図である。
【図７】本発明の一実施形態に係る図６の内容を具体化した、プログラム内部表現の内容を示す図である。
【図８】本発明の一実施形態に係る図７の内容を直列化した、合成バイナリデータの内容を示す図である。
【図９】本発明の一実施形態に係る端末の処理を示すフローチャートである。
【図１０】本発明の一実施形態に係る端末−プロキシサーバ−コンテンツサーバ間のＨＴＴＰシーケンスを示す図である。
【符号の説明】
【００９０】
２００  プロキシサーバ
２０１  関連ファイル追加取得判断部
２０２  端末能力テーブル保持部
２０３  フォーマット判断部
２０４  合成バイナリデータ生成部
２０５  合成バイナリデータ保存処理部
２０６  合成バイナリデータ読出部
２９９１  ファイル取得判断部
２９９２  ファイル保存処理部
２９９３  ファイル保存部
２９９４  ファイル読出部
２９９８、２９９９  通信制御部
３０１  ファイル種別判断部
３０２  合成バイナリデータ展開部
３９１  ユーザインターフェース
３９２  ファイル取得要求部
３９７  内部表現利用部
３９８  テキストファイル解析部
３９９  通信制御部
３００１、３００２、３００３  端末
【図１】
2009211191.tif 000003
【図２】
2009211191.tif 000004
【図３】
2009211191.tif 000005
【図４】
2009211191.tif 000006
【図５】
2009211191.tif 000007
【図６】
2009211191.tif 000008
【図７】
2009211191.tif 000009
【図８】
2009211191.tif 000010
【図９】
2009211191.tif 000011
【図１０】
2009211191.tif 000012