JPWO2015052967A1 - サーバ装置、クライアント装置、情報処理方法および記録媒体 - Google Patents

Abstract

【課題】クライアントからのリクエストに応じてサーバがドキュメントを提供するシステムにおいて、サーバの処理能力を活用することによってクライアントへのドキュメントの提供を高速化する。【解決手段】クライアントからのリクエストに応じて、リソースへの参照を含むドキュメントを取得するドキュメント取得部と、リソースを取得するリソース取得部と、ドキュメントおよびリソースのそれぞれに含まれる文字列について短縮された文字列を生成するとともに、文字列と短縮された文字列とを関連付けるレコードを追加する短縮文字列生成部と、ドキュメントおよびリソースにおいて、文字列を短縮された文字列に置換する短縮文字列記述部と、短縮された文字列を含むドキュメントをクライアントに送信するドキュメント送信部と、短縮された文字列を含むリソースをクライアントに送信するリソース送信部とを含むサーバ装置が提供される。【選択図】図１０Ａ

Description

本開示は、サーバ装置、クライアント装置、情報処理方法および記録媒体に関する。

クライアントからのリクエストに応じてサーバがドキュメントを提供するシステムは、例えばＨＴＭＬ（Hyper Text Markup Language）ドキュメントを提供するＷＷＷ（World Wide Web）のように、今日広く普及している。こうしたシステムにおいて、ドキュメントをクライアントに提供するための所要時間、より具体的にはクライアントがリクエストを送信してからドキュメントがクライアントで表示されるまでの時間を短縮することは、長年取り組まれてきた課題である。例えば、特許文献１には、メモリリソースやウェブサービスへのアクセスが制限されている場合でもキャッシュを効率よく利用するために、ウェブサーバにおいてコンテンツをキャッシュする技術が記載されている。

特開２０１１−１０８１０２号公報

しかしながら、例えばＨＴＭＬにおける画像／動画やスクリプトなどのように、様々なリソースを参照するリッチなドキュメントが増加する傾向にあり、上記のような高速化技術のさらなる進歩が求められている。また、サーバやクライアントの処理能力を向上させることも高速化に寄与するが、例えばクライアントがモバイル装置であるような場合には、処理能力の向上は必ずしも容易ではない。

そこで、本開示では、クライアントからのリクエストに応じてサーバがドキュメントを提供するシステムにおいて、サーバの処理能力を活用することによってクライアントへのドキュメントの提供を高速化することを可能にする、新規かつ改良されたサーバ装置、クライアント装置、情報処理方法および記録媒体を提案する。

本開示によれば、クライアントからのリクエストに応じて、リソースへの参照を含むドキュメントを取得するドキュメント取得部と、上記リソースを取得するリソース取得部と、上記ドキュメントおよび上記リソースのそれぞれに含まれる文字列について短縮された文字列を生成するとともに、上記文字列と上記短縮された文字列とを関連付けるレコードを追加する短縮文字列生成部と、上記ドキュメントおよび上記リソースにおいて、上記文字列を上記短縮された文字列に置換する短縮文字列記述部と、上記短縮された文字列を含む上記ドキュメントを上記クライアントに送信するドキュメント送信部と、上記短縮された文字列を含む上記リソースを上記クライアントに送信するリソース送信部とを含むサーバ装置が提供される。

また、本開示によれば、サーバにリクエストを送信するリクエスト送信部と、上記リクエストに応じて上記サーバから送信された、リソースへの参照を含むドキュメントを受信するドキュメント受信部と、上記リソースを受信するリソース受信部と、上記ドキュメントおよび上記リソースに含まれる短縮された文字列と、上記短縮された文字列に対応する文字列との関連付け情報を受信する関連付け情報受信部と、上記関連付け情報に従って上記ドキュメントおよび上記リソースを解釈する文字列解釈部とを含むクライアント装置が提供される。

また、本開示によれば、クライアントからのリクエストに応じて、リソースへの参照を含むドキュメントを取得することと、上記リソースを取得することと、上記ドキュメントおよび上記リソースのそれぞれに含まれる文字列について短縮された文字列を生成するとともに、上記文字列と上記短縮された文字列とを関連付けるレコードを追加することと、上記ドキュメントおよび上記リソースにおいて、上記文字列を上記短縮された文字列に置換することと、上記短縮された文字列を含む上記ドキュメントを上記クライアントに送信することと、上記短縮された文字列を含む上記リソースを上記クライアントに送信することとを含む情報処理方法が提供される。

また、本開示によれば、サーバにリクエストを送信する機能と、上記リクエストに応じて上記サーバから送信された、リソースへの参照を含むドキュメントを受信する機能と、上記リソースを受信する機能と、上記ドキュメントおよび上記リソースに含まれる短縮された文字列と、上記短縮された文字列に対応する文字列との関連付け情報を受信する機能と、上記関連付け情報に従って上記ドキュメントおよび上記リソースを解釈する機能とをコンピュータに実現させるためのプログラムが記録された一時的でない有形の記録媒体が提供される。

以上説明したように本開示によれば、クライアントからのリクエストに応じてサーバがドキュメントを提供するシステムにおいて、サーバの処理能力を活用することによってクライアントへのドキュメントの提供を高速化することができる。

本開示のいくつかの実施形態が適用されるシステムの概略的な構成を示す図である。 本開示の第１の実施形態に係る中間サーバおよびクライアントの概略的な機能構成を示すブロック図である。 本開示の第１の実施形態に係る中間サーバの処理を示すフローチャートである。 本開示の第１の実施形態に係るクライアントの処理を示すフローチャートである。 本開示の第１の実施形態の変形例に係る中間サーバの処理を示すフローチャートである。 本開示の第１の実施形態の変形例に係るクライアントの処理を示すフローチャートである。 本開示の第２の実施形態に係る中間サーバおよびクライアントの概略的な機能構成を示すブロック図である。 本開示の第２の実施形態に係る中間サーバがリクエストを受信する前の処理を示すフローチャートである。 本開示の第２の実施形態に係るクライアントがリクエストを送信する前の処理を示すフローチャートである。 本開示の第３の実施形態に係る中間サーバの概略的な機能構成を示すブロック図である。 本開示の第３の実施形態に係るクライアントの概略的な機能構成を示すブロック図である。 本開示の第３の実施形態に係る中間サーバの処理を示すフローチャートである。 本開示の第３の実施形態に係るクライアントの処理を示すフローチャートである。 本開示の第３の実施形態の変形例に係る中間サーバの処理を示すフローチャートである。 本開示の第４の実施形態に係る中間サーバの概略的な機能構成を示すブロック図である。 本開示の第４の実施形態に係るクライアントの概略的な機能構成を示すブロック図である。 本開示の第４の実施形態に係る中間サーバの処理を示すフローチャートである。 本開示の第４の実施形態に係る中間サーバの処理を示すフローチャートである。 本開示の第４の実施形態に係るクライアントの処理を示すフローチャートである。 本開示の第４の実施形態に係るクライアントの処理を示すフローチャートである。 本開示の第５の実施形態に係る中間サーバの処理を示すフローチャートである。 本開示の第５の実施形態に係るクライアントの処理を示すフローチャートである。 ＪＩＴコンパイラの通常の処理の例を示すフローチャートである。 本開示の第５の実施形態のいくつかの例に係る中間サーバ２００のコンパイラの処理の例を示すフローチャートである。 図１８Ｂの例に係るクライアント３００のＪＩＴコンパイラの処理の例を示すフローチャートである。 本開示の第６の実施形態に係る中間サーバの処理を示すフローチャートである。 本開示の第７の実施形態に係る中間サーバおよびクライアントの概略的な機能構成を示すブロック図である。 本開示の第７の実施形態に係る中間サーバの処理を示すフローチャートである。 本開示の第７の実施形態で適用されうる画像フォーマットに従った画像ファイルの生成処理について説明するための図である。 本開示の第７の実施形態で適用されうる画像フォーマットに従った画像ファイルの生成処理について説明するための図である。 本開示の実施形態に係る情報処理装置のハードウェア構成例を説明するためのブロック図である。

以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書および図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

なお、説明は以下の順序で行うものとする。
１．システム構成
２．第１の実施形態
２−１．機能構成
２−２．処理フロー
２−３．変形例
３．第２の実施形態
３−１．機能構成
３−２．処理フロー
４．第３の実施形態
４−１．機能構成
４−２．処理フロー
４−３．変形例
５．第４の実施形態
５−１．機能構成
５−２．処理フロー
６．第５の実施形態
７．第６の実施形態
８．第７の実施形態
８−１．機能構成
８−２．処理フロー
８−３．トランスコードの例
８−４．フォーマットの例
８−５．デコード処理の例
９．ハードウェア構成
１０．補足

（１．システム構成）
図１は、本開示のいくつかの実施形態が適用されるシステムの概略的な構成を示す図である。図１を参照すると、システム１０は、配信元サーバ１００と、中間サーバ２００と、クライアント３００とを含む。配信元サーバ１００、中間サーバ２００、およびクライアント３００は、例えばインターネットなどのネットワークによって相互に接続されている。

配信元サーバ１００および中間サーバ２００は、いずれも１または複数のサーバ装置によって実現されるサーバである。配信元サーバ１００は、ユーザに提供されるドキュメントと、ドキュメントが参照するリソースとを保持している。ドキュメントおよびリソースは、クライアント３００からのリクエストに応じて、配信元サーバ１００から１または複数の中間サーバ２００を経由して、クライアント３００に配信される。例えば、中間サーバ２００がドキュメントやリソースをキャッシュとして保持し、キャッシュされているドキュメントやリソースを配信元サーバ１００に代わってクライアント３００に配信することによって、クライアント３００に迅速にドキュメントを提供することができる。

また、ドキュメントやリソースの一部は、クライアント３００でもキャッシュとして保持されている。ドキュメントやリソースがクライアント３００で保持されている場合、ネットワークを介したデータの送受信をしなくてもよいため、ドキュメントはより迅速に表示される。ただし、クライアント３００で保持することが可能なキャッシュの量には限界があるため、より多くのキャッシュを保持することが可能な中間サーバ２００を設けることには利点がある。中間サーバ２００は、例えば後述する実施形態のように、キャッシュの保持に限らず、高速化のための様々な処理を実行しうる。中間サーバ２００のうち、最もクライアント３００に近いサーバ（エッジサーバ）とクライアント３００との間の通信は、例えばＨＴＴＰｏｖｅｒＵＤＰ、ＳＰＤＹ（ｏｖｅｒＵＤＰ）、またはＨＴＴＰ／２．０（ｏｖｅｒＵＤＰ）のような所定のプロトコルに統一されていてもよい。

なお、配信元サーバ１００および中間サーバ２００を実現する１または複数のサーバ装置は、ＣＰＵ（Central Processing unit）などのプロセッサを備えた情報処理装置でありうる。また、クライアント３００もプロセッサを備えた情報処理装置によって実現されうる。クライアント３００には、ディスプレイやスピーカなどの出力装置や、タッチパネルなどの入力装置、および撮像装置などがさらに備えられてもよい。より具体的には、例えば、クライアント３００は、スマートフォン、パーソナルコンピュータ、タブレット、メディアプレーヤ、テレビ、ゲーム機などといった装置でありうる。上記の各装置を実現しうる情報処理装置の具体的なハードウェア構成については、後段でさらに詳細に説明する。

システム１０は、例えばＨＴＭＬのようなマークアップ言語で記述されたドキュメントの配信に利用されうる。この場合、リソースは、例えばＪａｖａＳｃｒｉｐｔのようなスクリプトや、ＣＳＳ（Cascading Style Sheets）のようなスタイル定義情報、画像および動画などでありうる。なお、システム１０は、マークアップ言語で記述されたものに限らず、各種のドキュメント、またはドキュメント以外のデータ（画像もしくは動画などを含む）の配信に利用されうる。

（２．第１の実施形態）
（２−１．機能構成）
図２は、本開示の第１の実施形態に係る中間サーバおよびクライアントの概略的な機能構成を示すブロック図である。図２を参照すると、中間サーバ２００は、機能構成として、リクエスト受信部２０２と、ドキュメント取得部２０４と、ドキュメント解析部２０６と、リソース取得部２０８と、識別子生成部２１０と、識別子記述部２１２と、ドキュメント送信部２１４と、リソース送信部２１６とを含む。クライアント３００は、機能構成として、リクエスト送信部３０２と、ドキュメント受信部３０４と、キャッシュ判定部３０６と、リソース受信部３０８と、表示制御部３１０とを含む。

これらの機能構成は、例えば、中間サーバ２００およびクライアント３００をそれぞれ実現する情報処理装置に備えられるプロセッサが、メモリまたは記録媒体に格納されたプログラムに従って動作することによって実現されうる。また、中間サーバ２００におけるキャッシュ２８０、およびクライアント３００におけるキャッシュ３８０は、例えば、それぞれの情報処理装置のストレージまたはメモリによって実現されうる。

（中間サーバ）
中間サーバ２００では、リクエスト受信部２０２がクライアント３００からのリクエストを受信する。リクエストが受信されると、ドキュメント取得部２０４が、リクエストに応じて、リクエストにおいて指定されたドキュメントを取得する。このとき、ドキュメント取得部２０４は、キャッシュ２８０に格納されたドキュメントを内部的に取得してもよい。指定されたドキュメントがキャッシュ２８０に格納されていない場合、ドキュメント取得部２０４は配信元サーバ１００にリクエストを送信し、リクエストに応じて配信元サーバ１００から送信されたドキュメントを取得する。

ドキュメント解析部２０６は、ドキュメント取得部２０４が取得したドキュメントを解析する。より具体的には、ドキュメント解析部２０６は、ドキュメントに含まれるリソースへの参照を検出する。ドキュメント解析部２０６によってリソースへの参照が検出された場合、リソース取得部２０８が、参照されているリソースを取得する。このとき、リソース取得部２０８は、キャッシュ２８０に格納されたリソースを内部的に取得してもよい。参照されているリソースがキャッシュ２８０に格納されていない場合、リソース取得部２０８は配信元サーバ１００にリクエストを送信し、リクエストに応じて配信元サーバ１００から送信されたリソースを取得する。配信元サーバ１００から新たに取得されたリソースは、キャッシュ２８０に格納される。

識別子生成部２１０は、リソース取得部２０８によって取得されたリソースについて、リソースの内容ごとに一意な識別子を生成する。例えば、識別子生成部２１０は、リソースの内容に基づいて所定のアルゴリズムでハッシュを算出してもよい。この場合、算出されたハッシュは、リソースの内容ごとに一意な識別子になりうる。なお、識別子生成部２１０は、必ずしもハッシュをそのまま識別子として利用しなくてもよく、ハッシュに基づいてリソースを同定した上で、別途識別子を生成してリソースに付与してもよい。識別子生成部２１０は、生成した識別子をキャッシュ２８０に格納されているリソースに関連付けてもよい。

より具体的には、例えば、識別子生成部２１０は、リソースを種類に関わらずバイナリデータとみなし、ハッシュ関数を利用して一意な識別子を生成する。ハッシュ関数としては、例えばＭＤ５、ＳＨＡ−１、またはＳＨＡ−２５６などを利用してもよい。さらに、識別子生成部２１０は、１つのリソースについて、複数のハッシュ関数を利用して複数の識別子を生成してもよい。これらの識別子がすべて一致した場合にリソースを同一と判定することで、識別子の一意性をより高めることができる。

後述するように、識別子生成部２１０が生成するリソースの内容ごとに一意な識別子によって、クライアント３００におけるドキュメントの表示を高速化させることができる。上記のハッシュ関数による識別子の生成の例のように、識別子生成部２１０による一意な識別子の生成にもある程度の時間はかかるが、一般に中間サーバ２００の処理能力はクライアント３００よりも高く、また後述する変形例のように識別子の生成と並行してクライアント３００でドキュメントの表示を開始することも可能であるため、結果としてドキュメントの表示の高速化が達成される。

識別子記述部２１２は、識別子生成部２１０によって生成された識別子を、ドキュメントにおけるリソースへの参照に関連付ける。より具体的には、例えば、識別子記述部２１２は、識別子生成部２１０が生成した識別子を、オリジナルの識別子に追加してリソースへの参照に関連付ける。例えば、ＨＴＭＬドキュメントは、ＵＲＬ（Uniform Resource Locator）をオリジナルの識別子とするリソースへの参照を含む。この場合、識別子記述部２１２は、オリジナルの識別子であるＵＲＬを残しつつ、識別子生成部２１０によって生成された識別子、例えばハッシュを追加的にドキュメントに記述してもよい。

一例として、ＨＴＭＬドキュメントに下記の（ａ）に示すようなＵＲＬを含む画像のリソースへの参照が含まれていた場合、識別子記述部２１２は、（ｂ）に示すように、識別子生成部２１０によって生成された識別子であるハッシュ（new_id）を追加的にドキュメントに記述してもよい。
（ａ）<img src=“resource/image001.jpg”/>
（ｂ）<img src=“resource/image001.jpg” new_id=“736f6e7920706174656e74”/>

後述するように、クライアント３００は、ドキュメントの参照に際して、識別子記述部２１２によって追加的に記述された識別子に基づいてリソースのキャッシュの有無を判断し、キャッシュがない場合には中間サーバ２００にリソースをリクエストするように構成されている。しかし、ネットワーク上には、クライアント３００以外のクライアント、つまり追加的に記述された識別子を参照しないクライアントも存在しうる。識別子記述部２１２がオリジナルの識別子を残しておくことによって、そのようなクライアントとの間で下位互換性を確保することができる。

あるいは、識別子記述部２１２は、識別子生成部２１０が生成した識別子によって、ドキュメントにおけるリソースへの参照に含まれるオリジナルの識別子を上書きしてもよい。この場合、例えば、上記の（ａ）に示すようなリソースへの参照は、下記の（ｃ）に示すように書き換えられうる。
（ｃ）<img src=“http://www.xxx.yyy/zzz/736f6e7920706174656e74”/>

この例において、識別子記述部２１２は、ＵＲＬを、中間サーバ２００を示す絶対パスに書き換えるとともに、絶対パスに続けて識別子生成部２１０が生成した識別子を記述している。中間サーバ２００を示す絶対パスは、すべてのリソースで共通して付加される。従って、クライアント３００が上記の例のように書き換えられたオリジナルの識別子に基づいてキャッシュの有無を判断することは、実質的に識別子生成部２１０が生成した識別子に基づいて判断しているのと同じことになる。この場合、クライアントは、追加的に記述された識別子を参照するように構成されていなくてもよい。

ドキュメント送信部２１４は、識別子生成部２１０によって生成された識別子を含むドキュメントをクライアント３００に送信する。後述するように、クライアント３００は、識別子生成部２１０によって生成された識別子に基づいてリソースを参照しながらドキュメントを表示させる。リソース送信部２１６は、ドキュメントで参照されるリソースがクライアント３００でキャッシュされていなかった場合にクライアント３００から送信されるリソースのリクエストに応じて、キャッシュ２８０に格納されたリソースをクライアント３００に送信する。

（クライアント）
クライアント３００では、リクエスト送信部３０２が、例えばユーザ操作に基づいて中間サーバ２００にリクエストを送信する。ドキュメント受信部３０４は、中間サーバ２００がリクエストに応じて送信したドキュメントを受信する。上述の通り、受信されるドキュメントにはリソースへの参照が含まれ、リソースへの参照には中間サーバ２００の識別子生成部２１０によって生成されたリソースの内容ごとに一意な識別子が関連付けられている。上述の通り、ドキュメントにおいて、一意な識別子は、オリジナルの識別子に追加してリソースへの参照に関連付けられていてもよい。

キャッシュ判定部３０６は、ドキュメント受信部３０４が受信したドキュメントにおいて参照されているリソースが、キャッシュ３８０に格納されているか否かを判定する。このとき、キャッシュ判定部３０６は、リソースの内容ごとに一意な識別子に基づいて、リソースがキャッシュ３８０に格納されているか否かを判定する。リソースがキャッシュ３８０に格納されている場合、キャッシュ判定部３０６は格納されたリソースを読み出して表示制御部３１０に提供する。一方、リソースがキャッシュ３８０に格納されていなかった場合、キャッシュ判定部３０６は、中間サーバ２００に当該リソースのリクエストを送信することをリソース受信部３０８に依頼する。

ここで、もし、キャッシュ判定部が判定に用いる識別子が、例えばＵＲＬのようなものであった場合、識別子は必ずしもリソースの内容ごとに一意ではない。それゆえ、リソースの内容が同一であっても、異なるリソースが参照されていると判定される場合がある。例えば、第１の配信元サーバ１００ａから配信される第１のドキュメントによって参照される第１のリソースと、第２の配信元サーバ１００ｂから配信される第２のドキュメントによって参照される第２のリソースとがあるとする。この場合、第１のリソースと第２のリソースとの内容が同一であっても、第１の配信元サーバ１００ａを示すＵＲＬと第２の配信元サーバ１００ｂを示すＵＲＬとが異なるために、第１のリソースおよび第２のリソースへの参照にそれぞれ用いられる識別子（ＵＲＬ）は異なる。従って、キャッシュ判定部は、受信された第２のドキュメントで第２のリソースが参照されているような場合、同じ内容の第１のリソースが既にキャッシュに格納されていても、第２のリソースそのものがキャッシュに格納されていなければ、参照されているリソースがキャッシュに格納されていないと判定しうる。

これに対して、本実施形態に係るクライアント３００のキャッシュ判定部３０６は、リソースの内容ごとに一意な識別子に基づいて、リソースがキャッシュ３８０に格納されているか否かを判定する。この場合、上記の例でいえば、中間サーバ２００の識別子生成部２１０が、第１のリソースと第２のリソースとについて共通する識別子を生成し、キャッシュ判定部３０６は、この共通の識別子に基づいてリソースがキャッシュ３８０に格納されているか否かを判定する。従って、受信された第２のドキュメントで第２のリソースが参照されている場合、同じ内容の第１のリソースが既にキャッシュ３８０に格納されていれば、キャッシュ判定部３０６は、参照されているリソースがキャッシュ３８０に格納されていると判定し、中間サーバ２００にリクエストを送信することなく、キャッシュ３８０に格納されたリソースを再利用して表示制御部３１０に提供することができる。

リソース受信部３０８は、中間サーバ２００にリソースのリクエストを送信し、リクエストに応じて中間サーバ２００から送信されたリソースを受信する。リソース受信部３０８は、受信されたリソースを表示制御部３１０に提供する。また、リソース受信部３０８は、新たに受信されたリソースをキャッシュ３８０に格納する。

表示制御部３１０は、ドキュメント受信部３０４が受信したドキュメントと、ドキュメントにおいて参照されているリソースとに基づいて、クライアント３００のディスプレイにドキュメントを表示させる。上述のように、リソースは、キャッシュ判定部３０６の判定に応じて、キャッシュ３８０から読み出されて再利用されるか、中間サーバ２００から新たに受信される。中間サーバ２００からの受信には通信のための時間がかかるため、再利用されるリソースの割合が高いほど、ドキュメントの表示は高速化されることになる。

本実施形態では、キャッシュ判定部３０６が、リソースの内容ごとに一意な識別子に基づいて、リソースがキャッシュ３８０に格納されているか否かを判定する。それゆえ、例えば同じ配信元サーバ１００から配信されたドキュメントで参照されるリソースのみならず、相異なる配信元サーバ１００から配信された複数のドキュメントでそれぞれ参照されるリソースであっても、内容が同一であれば再利用することができる。従って、ドキュメントの表示にあたって再利用されるリソースの割合が増加し、ドキュメントの表示が高速化されうる。

（２−２．処理フロー）
（中間サーバの処理フロー）
図３は、本開示の第１の実施形態に係る中間サーバの処理を示すフローチャートである。図３を参照すると、まず、リクエスト受信部２０２が、クライアント３００からのリクエストを受信する（Ｓ１０１）。次に、ドキュメント取得部２０４が、リクエストにおいて指定されたドキュメントを取得する（Ｓ１０３）。次に、ドキュメント解析部２０６が、取得されたドキュメントを解析する（Ｓ１０５）。

ここで、ドキュメントの解析においてリソースへの参照が検出された場合（Ｓ１０７のＹＥＳ）、リソース取得部２０８が、参照されているリソースを取得する（Ｓ１０９）。さらに、識別子生成部２１０が、取得されたリソースの内容に基づいて一意な識別子を生成する（Ｓ１１１）。次に、識別子記述部２１２が、生成された一意な識別子を、ドキュメントにおけるリソースへの参照に関連付ける（Ｓ１１３）。Ｓ１０９〜Ｓ１１３は、ドキュメントにおけるリソースへの参照がすべて検出されるまで繰り返し実行されうる。

ドキュメントの解析においてリソースへの参照が検出されなくなった場合、または検出されなかった場合（Ｓ１０７のＮＯ）、ドキュメント送信部２１４が、ドキュメントをクライアント３００に送信する（Ｓ１１５）。その後、クライアント３００からリソースのリクエストが受信された場合（Ｓ１１７のＹＥＳ）、リソース送信部２１６がクライアント３００にリソースを送信する（Ｓ１１９）。リソースのリクエストが受信されなくなった場合、または受信されなかった場合（Ｓ１１７のＮＯ）、中間サーバ２００での処理は終了する。

（クライアントの処理フロー）
図４は、本開示の第１の実施形態に係るクライアントの処理を示すフローチャートである。図４を参照すると、まず、リクエスト送信部３０２が、中間サーバ２００にリクエストを送信する（Ｓ１３１）。次に、ドキュメント受信部３０４が、中間サーバ２００がリクエストに応じて送信したドキュメントを受信する（Ｓ１３３）。ここで、表示制御部３１０は、受信されたドキュメントの表示を開始する（Ｓ１３５）。

ドキュメントにおいてリソースへの参照が発見された場合（Ｓ１３７のＹＥＳ）、キャッシュ判定部３０６が、参照されているリソースがキャッシュ３８０に格納されているか（キャッシュされているか）否かを判定する（Ｓ１３９）。上述のように、キャッシュ判定部３０６は、ドキュメントにおけるリソースへの参照に関連付けられた、リソースの内容ごとに一意な識別子に基づいて、リソースがキャッシュ３８０に格納されているか否かを判定する。

ここで、リソースがキャッシュ３８０に格納されていると判定された場合（Ｓ１３９のＹＥＳ）、キャッシュ判定部３０６はキャッシュ３８０からリソースを読み出して表示制御部３１０に提供する。つまり、キャッシュ判定部３０６および表示制御部３１０はキャッシュされたリソースを再利用する（Ｓ１４１）。一方、リソースがキャッシュ３８０に格納されていないと判定された場合（Ｓ１３９のＮＯ）、リソース受信部３０８が中間サーバ２００にリソースのリクエストを送信する（Ｓ１４３）。リソース受信部３０８は、リクエストに応じて中間サーバ２００が送信したリソースを受信する（Ｓ１４５）。

表示制御部３１０は、再利用されたリソース、または中間サーバ２００から受信されたリソースを参照して、ドキュメントの表示を継続する（Ｓ１４７）。Ｓ１３９〜Ｓ１４７は、ドキュメントにおけるリソースへの参照がすべて発見されるまで繰り返し実行されうる。表示制御部３１０がドキュメントの全体を表示させ、リソースへの参照も発見されなくなった場合、またはリソースへの参照が発見されなかった場合（Ｓ１３７のＮＯ）、クライアント３００はドキュメントの表示を完了する（Ｓ１４９）。

（２−３．変形例）
（中間サーバの処理フロー）
図５は、本開示の第１の実施形態の変形例に係る中間サーバの処理を示すフローチャートである。図５を参照すると、まず、上記で図３を参照して説明した例と同様にＳ１０１〜Ｓ１０５が実行される。

次に、識別子記述部２１２が、ドキュメントの解析によって検出されたリソースへの参照にダミー識別子を関連付ける（Ｓ１６１）。ここで、ダミー識別子は、例えば機械的に生成される一連の識別子であり、必ずしもリソースの内容ごとに一意ではない。識別子記述部２１２は、例えば、ドキュメントの先頭から順に、検出された参照にインクリメンタルな、またはランダムなダミー識別子を関連付ける。このとき、参照されるリソースのオリジナルの識別子（例えばＵＲＬ）が同一であれば、識別子記述部２１２はこれらの参照に同一のダミー識別子を関連付けてもよい。

次に、ドキュメント送信部２１４がドキュメントをクライアント３００に送信する（Ｓ１１５）。この後に、またはこれと並行して、ドキュメントの解析によって検出されたリソースへの参照のそれぞれについて、リソース取得部２０８が参照されているリソースを取得し、識別子生成部２１０が取得されたリソースの内容に基づいて一意な識別子を生成する（Ｓ１０７〜Ｓ１１１）。

検出されたすべての参照についてＳ１０７〜Ｓ１１１の処理が終了すると、識別子記述部２１２が、Ｓ１６１で参照に関連付けられたダミー識別子と、Ｓ１１１で生成された一意な識別子とを関連付ける情報（識別子の関連付け情報）を生成する（Ｓ１６３）。ドキュメント送信部２１４は、識別子の関連付け情報をクライアント３００に送信する（Ｓ１６５）。その後、クライアント３００からリソースのリクエストが受信されれば、リソース送信部２１６がクライアント３００にリソースを送信する（Ｓ１１７，Ｓ１１９）。

（クライアントの処理フロー）
図６は、本開示の第１の実施形態の変形例に係るクライアントの処理を示すフローチャートである。図６を参照すると、まず、上記で図４を参照して説明した例と同様にＳ１３１〜Ｓ１３５が実行される。

ドキュメントにおいてリソースへの参照が発見された場合（Ｓ１３７のＹＥＳ）、キャッシュ判定部３０６は、発見された参照に関連付けられたダミー識別子を一意な識別子に置換した上で（Ｓ１８１）、参照されているリソースがキャッシュ３８０に格納されているか否かを判定する（Ｓ１３９）。図示していないが、Ｓ１８１の時点で、上述した識別子の関連付け情報がドキュメント受信部３０４によって受信されていない場合、つまり、キャッシュ判定部３０６がリソースへの参照にダミー識別子が関連付けられた状態でリソースを参照する場合、キャッシュ判定部３０６は、識別子または識別子の関連付け情報のためのリクエストを中間サーバ２００に送信する。この場合、中間サーバ２００の識別子生成部２１０は、リクエストが受信された参照について、参照されているリソースの内容に基づく一意な識別子の生成を優先的に実行してもよい。

中間サーバ２００の処理能力がクライアント３００に比べて高い場合でも、識別子生成部２１０による一意な識別子の生成にはある程度の時間がかかる。従って、本変形例のように、容易に生成できるダミー識別子が参照に関連付けられたドキュメントを先行してクライアント３００に送信し、クライアント３００で受信されたドキュメントに基づいて表示が開始されるのと並行して中間サーバ２００で一意な識別子の生成を実行することで、クライアント３００でドキュメントの表示が完了するまでの時間をさらに短縮することができる。

（３．第２の実施形態）
（３−１．機能構成）
図７は、本開示の第２の実施形態に係る中間サーバおよびクライアントの概略的な機能構成を示すブロック図である。図７を参照すると、中間サーバ２００は、機能構成として、リソース先行配信部２１８をさらに含む。また、クライアント３００は、機能構成として、リソース先行受信部３１２をさらに含む。

中間サーバ２００のリソース先行配信部２１８は、所定のリソースについて、リクエスト受信部２０２がクライアント３００からリクエストを受信する前に、先行してクライアント３００に送信する。このとき、リソース先行配信部２１８は、リソースを、識別子生成部２１０が生成したリソースの内容ごとに一意な識別子に関連付けてクライアント３００に送信する。

例えば、リソース先行配信部２１８は、識別子生成部２１０によって生成された識別子が、ドキュメントにおいてリソースへの参照に関連付けられた回数をカウントし、この回数に基づいて使用頻度が高いと推定されるリソースをクライアント３００に送信してもよい。識別子生成部２１０によって生成される識別子はリソースの内容ごとに一意であるため、上記のカウントは、ＵＲＬなどに関わらず、リソースの内容ごとに、それぞれのリソースがいろいろなドキュメントにおいて参照された頻度を示すものでありうる。

あるいは、リソース先行配信部２１８は、サービス提供者によって指定されたリソースを、先行してクライアント３００に送信してもよい。例えば、多くのドキュメントで共通して参照されることが予想されるスクリプトの標準ライブラリについては、サービス提供者による設定に従って、リソース先行配信部２１８がクライアント３００に先行して送信しておくことで、ドキュメントを提供する場合にスクリプトのためのリクエストやリクエストに応じたスクリプトの送信にかかる時間を節減することができる。

また、先行して配信されるリソースがスクリプトのようなプログラムである場合、リソース先行配信部２１８は、プログラムをプリコンパイルしてからクライアント３００に送信してもよい。例えば、クライアント３００が、ドキュメントにおいて参照されたプログラムをコンパイルしてから実行する場合、プログラムがキャッシュ３８０に格納されていたとしても、コンパイルにかけられる時間は限られている。一方、中間サーバ２００でリソース先行配信部２１８がプログラムをクライアント３００への送信前にプリコンパイルする場合、コンパイルに十分に時間をかけることができるために、プログラム実行時の動作コンパイルによって十分に最適化することができる。

クライアント３００のリソース先行受信部３１２は、リクエスト送信部３０２が中間サーバ２００にリクエストを送信する前に、中間サーバ２００のリソース先行配信部２１８が送信したリソースを受信する。ここで受信されるリソースは、上記のように、例えば、リソースへの参照に関連付けられた回数に基づいて使用頻度が高いと推定されるリソースであってもよいし、サービス提供者によって指定されたリソースであってもよい。いずれの場合も、リソース先行受信部３１２は、中間サーバ２００から先行して配信されたリソースを受信し、受信したリソースをキャッシュ３８０に格納する。

上述のように、受信されるリソースは、中間サーバ２００において識別子生成部２１０が生成した、リソースの内容ごとに一意な識別子に関連付けられている。リソース先行受信部３１２は、受信したリソースを、この識別子に関連付けてキャッシュ３８０に格納する。これによって、先行して配信されたリソースのオリジナルの識別子（例えばＵＲＬ）に関わらず、先行して配信されたリソースと同一の内容のリソースがドキュメントにおいて参照された場合には、キャッシュ３８０に予め格納されたリソースを利用し、ドキュメントの表示を高速化することができる。

また、先行して配信されるリソースがスクリプトのようなプログラムである場合、リソース先行受信部３１２は、中間サーバ２００のリソース先行配信部２１８によってプリコンパイルされたプログラムを受信してもよい。この場合、リソース先行受信部３１２は、プリコンパイルされたプログラムを、キャッシュ３８０において、例えば画像やＣＳＳなどプログラム以外のリソースとは別の記憶領域に格納してもよい。プリコンパイルされたプログラムは、例えばＷｅｂＣｏｒｅのようなライブラリと共通の記憶領域に格納されうる。これによって、クライアント３００におけるドキュメントの表示時に、参照されているリソースに対応するプリコンパイルされたプログラムにより高速にアクセスすることが可能になりうる。

例えばＨＴＭＬドキュメントにおいて参照されるリソースのサイズの割合では、ＪａｖａＳｃｒｉｐｔなどのスクリプトが画像に次いで大きな割合を占める。また、例えばＪａｖａＳｃｒｉｐｔの参照では、特定のいくつかの標準ライブラリが参照されるケースが大半である。従って、例えばスクリプトの標準ライブラリを予め中間サーバ２００からクライアント３００に配信しておくことで、ドキュメントの表示にあたって高い確率で発生するスクリプトの標準ライブラリのためのリクエストやリソースの送受信を省略し、ドキュメントの表示を高速化することができる。

より具体的には、スクリプトのアップデートがあった場合に、アップデート後のスクリプトがリクエストに先行して中間サーバ２００からクライアント３００に配信されていれば、アップデート後に初めてドキュメントから当該スクリプトが参照される場合であっても、クライアント３００のキャッシュに格納されたスクリプトを利用して迅速にドキュメントを表示することができる。また、上記のような場合に、スクリプトの標準ライブラリがプリコンパイルされていれば、さらなる高速化が可能であることは上述した通りである。スクリプト以外でも、例えばロゴの画像や話題のアイテムの画像など、ドキュメントの表示にあたって参照される可能性が高いと推定されるリソースが予め中間サーバ２００からクライアント３００に配信することは、ドキュメントの表示を高速化することに寄与しうる。

（３−２．処理フロー）
（中間サーバの処理フロー）
図８は、本開示の第２の実施形態に係る中間サーバがリクエストを受信する前の処理を示すフローチャートである。図８を参照すると、まず、リソース先行配信部２１８が、先行して配信するリソースを決定する（Ｓ２０１）。ここで、先行して配信するリソースは、例えば上記のように識別子がドキュメントにおいてリソースへの参照に関連付けられた回数に基づいて決定されてもよいし、サービス提供者によって指定されてもよい。

また、リソース先行配信部２１８は、例えば上述したスクリプトの標準ライブラリのように、使用頻度が高いと推定され、かつアップデートの可能性があるリソースについて、配信元サーバ１００に当該リソースを定期的にリクエストすることによってアップデートの有無を確認し、アップデートがあった場合にはアップデート後のリソースを先行して配信することを決定してもよい。リソース先行配信部２１８は、アップデートの有無の確認のために、識別子生成部２１０による識別子の生成処理を利用してもよい。つまり、識別子生成部２１０がリソースの内容ごとに一意な識別子を生成したときに、生成された識別子が以前に生成された識別子と異なっていれば、リソースにアップデートがあったと判断できる。

次に、リソース先行配信部２１８は、付加的な処理として、先行して配信されるリソースがプログラムであれば、必要に応じてプリコンパイルを実行する（Ｓ２０３）。次に、リソース先行配信部２１８は、リソースをクライアント３００に送信する（Ｓ２０５）。

（クライアントの処理フロー）
図９は、本開示の第２の実施形態に係るクライアントがリクエストを送信する前の処理を示すフローチャートである。図９を参照すると、まず、リソース先行受信部３１２が、中間サーバ２００から配信されたリソースを受信する（Ｓ２１１）。次に、リソース先行受信部３１２は、付加的な処理として、先行して配信されるリソースがプログラムであれば（Ｓ２１３のＹＥＳ）、配信されたリソースを他のリソースとは別の、プログラム用の記憶領域にリソースを格納する（Ｓ２１５）。そうでない場合、リソース先行受信部３１２は、リソースを通常のキャッシュ３８０の記憶領域に格納する（Ｓ２１７）。

なお、リクエスト送信後の中間サーバおよびクライアントの処理フローについては、上記の第１の実施形態と同様であるため詳細な説明を省略する。本実施形態では、上記のようにリクエストの送信に先行して一部のリソースが中間サーバ２００からクライアント３００に送信されているために、例えば図４に示したフローチャートのＳ１３９において、リソースがキャッシュ３８０に格納されていると判定される場合がより多くなる。

（４．第３の実施形態）
（４−１．機能構成）
図１０（図１０Ａおよび図１０Ｂ）は、本開示の第３の実施形態に係る中間サーバおよびクライアントの概略的な機能構成を示すブロック図である。図１０Ａを参照すると、中間サーバ２００は、機能構成として、リクエスト受信部２０２と、ドキュメント取得部２０４と、ドキュメント解析部２０６と、リソース取得部２０８と、リソース解析部２２０と、短縮文字列生成部２２２と、短縮文字列記述部２２４と、ドキュメント送信部２１４と、関連付け情報送信部２２６と、リソース送信部２１６とを含む。図１０Ｂを参照すると、クライアント３００は、機能構成として、リクエスト送信部３０２と、ドキュメント受信部３０４と、リソース受信部３０８と、関連付け情報受信部３１４と、文字列解釈部３１６と、表示制御部３１０とを含む。

これらの機能構成は、例えば、中間サーバ２００およびクライアント３００をそれぞれ実現する情報処理装置に備えられるプロセッサが、メモリまたは記録媒体に格納されたプログラムに従って動作することによって実現されうる。また、中間サーバ２００におけるデータベース２８２、およびクライアント３００におけるデータベース３８２は、例えば、それぞれの情報処理装置のストレージまたはメモリによって実現されうる。

（中間サーバ）
中間サーバ２００では、リクエスト受信部２０２およびドキュメント取得部２０４が、上記の第１の実施形態と同様に、クライアント３００からのリクエストに応じてドキュメントを取得する。また、ドキュメント解析部２０６は、ドキュメント取得部２０４が取得したドキュメントを解析し、ドキュメントに含まれるリソースへの参照を検出する。リソース取得部２０８は、ドキュメント解析部２０６によってリソースへの参照が検出された場合に、参照されているリソースを取得する。

さらに、本実施形態では、ドキュメント解析部２０６が、ドキュメント取得部２０４によって取得されたドキュメントに含まれる短縮可能な文字列を検出する。また、リソース解析部２２０が、リソース取得部２０８によって取得されたリソースに含まれる短縮可能な文字列を検出する。ここで、短縮可能な文字列は、例えば、ドキュメント内の要素や、スタイルで定義されるクラス、プログラムで定義された関数などに与えられる任意の識別子を含む。また、短縮可能な文字列は、ドキュメントやリソースのフォーマットにおける予約語を含んでもよい。さらに、短縮可能な文字列は、ドキュメントにおいて参照されているリソースの識別子や、いわゆる地の文としてドキュメントに記述されている文字列を含んでもよい。

ドキュメント解析部２０６およびリソース解析部２２０によって短縮可能な文字列が検出された場合、短縮文字列生成部２２２が、検出された文字列を短縮した文字列（以下、短縮文字列ともいう）を生成する。例えば、短縮文字列生成部２２２は、元の文字列に基づいて所定のアルゴリズムに従って演算を実行することによって短縮文字列を生成してもよい。後述するように、図示された例において、元の文字列と短縮文字列との関係はデータベース２８２に記録されるため、アルゴリズムは非可逆的なものでよい。あるいは、短縮文字列生成部２２２は、元の文字列に関係なく、インクリメンタルな、またはランダムな短縮文字列を生成してもよい。

ここで、上記の例において、アルゴリズムを利用して短縮文字列を生成する場合、短縮文字列がやや長くなるが、元の文字列が同じであれば自動的に同じ短縮文字列が生成されるため、データベース２８２のレコードを最小限にして検索性を向上させることができる。また、利用するアルゴリズムによっては、元の文字列に対して一意な短縮文字列を生成することができる。

一方、インクリメンタルな、またはランダムな短縮文字列を生成する場合、短縮文字列を極限まで短くできるが（例えば、ドキュメントまたはリソースに含まれる短縮可能な文字列の数を表現可能な最短の長さにすることができる）、そのままではデータベース２８２に短縮可能な文字列（重複したものを含む）の数だけレコードが生成されてしまう。短縮文字列生成部２２２がデータベース２８２を参照し、同じ元の文字列についてまだ短縮文字列が生成されていない場合に新たな短縮文字列を生成するようにすれば、データベース２８２のレコード数を削減することができる。

短縮文字列生成部２２２は、短縮文字列を生成した場合に、元の文字列と短縮文字列とを関連付けるレコード（短縮文字列レコード）をデータベース２８２に追加する。データベース２８２は、例えば、ドキュメントを単位として生成されてもよい。つまり、データベース２８２によって示される元の文字列と短縮文字列との対応づけは、単一のリクエストに応じて送信されるドキュメントと、このドキュメントから参照されるリソースとをスコープとしてもよい。あるいは、データベース２８２は、複数のドキュメントとこれらのドキュメントから参照されるリソースとをスコープとして生成されてもよい。

ここで、生成された短縮文字列について、元の文字列との対応付けがクライアント３００においてデータベース３８２に記録されていることがわかっている場合、短縮文字列生成部２２２は、データベース２８２に短縮文字列レコードを追加しなくてもよい。例えば、ドキュメントやリソースのフォーマットにおける予約語を短縮可能な文字列として扱う場合、予約語は有限であるため、予め短縮文字列を割り当てて、予約語と短縮文字列との対応付けをデータベース２８２およびデータベース３８２に予め記録しておくことが可能である。この場合、短縮文字列生成部２２２は、ドキュメントまたはリソースにおいて検出された予約語について、データベース２８２を参照して予め割り当てられた短縮文字列を生成した上で、データベース２８２への新たなレコードの追加を省略する。

短縮文字列記述部２２４は、短縮文字列生成部２２２によって生成された短縮文字列で、ドキュメントおよびリソースに含まれる元の文字列を置換する。送信されるデータ量の削減、およびクライアント３００における文字列読み取りの処理量の削減のためには、短縮文字列記述部２２４が、ドキュメントおよびリソースにおいて元の文字列を残すことなく、短縮文字列に置換することが望ましい。

ドキュメント送信部２１４は、短縮文字列生成部２２２によって生成された短縮文字列を含む（つまり、元の文字列が短縮文字列に置換された）ドキュメントをクライアント３００に送信する。また、リソース送信部２１６は、同様に元の文字列が短縮文字列に置換されたリソースをクライアント３００に送信する。関連付け情報送信部２２６は、データベース２８２の短縮文字列レコードに基づいて、元の文字列と短縮文字列とを関連付ける情報（以下、関連付け情報ともいう）を生成し、これをクライアント３００に送信する。

ここで、関連付け情報送信部２２６は、クライアント３００側で短縮文字列から元の文字列を復元する必要がある場合に限って、関連付け情報をクライアント３００に送信してもよい。つまり、関連付け情報は、短縮文字列レコードの少なくとも一部を含まなくてもよい。

例えば、短縮文字列生成部２２２が、ドキュメント内の要素や、スタイルで定義されるクラス、プログラムで定義された関数などに与えられる任意の識別子について短縮文字列を生成した場合、ドキュメントおよびリソースを通じて、元の文字列と短縮文字列とが１対１で対応するように短縮文字列を生成している（例えば、元の文字列から所定にアルゴリズムに基づいて短縮文字列を生成したり、データベース２８２を参照して元の文字列について既に短縮文字列が生成されている場合にはその短縮文字列を再利用したりしている）のであれば、クライアント３００側で元の文字列を復元しなくても、要素、クラス、または関数は一意に特定される。このような場合、関連付け情報送信部２２６は、当該短縮文字列についての関連付け情報をクライアント３００に送信しなくてもよい。

また、例えば、ドキュメントまたはリソースにおける予約語について短縮文字列が生成される場合、データベース２８２には予め予約語に対応する短縮文字列に対応する短縮文字列レコードが含まれているが、クライアント３００に送信される関連付け情報には予約語に関する情報が含まれなくてもよい（クライアント３００のデータベース３８２に予約語に関する情報が予め格納されている場合）。

一方、要素、クラス、または関数などについて生成された短縮文字列でも、元の文字列と１対１で対応しない場合（例えば、短縮文字列生成部２２２が短縮文字列の生成にあたってデータベース２８２を参照せず、機械的に割り当てた短縮文字列の情報をデータベースに格納するような場合）や、地の文としてドキュメントに記述されている文字列のように最終的に元の文字列がユーザに提示されるような場合には、関連付け情報送信部２２６がデータベース２８２のレコードに基づいて生成された関連付け情報をクライアント３００に送信する。

（クライアント）
クライアント３００では、リクエスト送信部３０２およびドキュメント受信部３０４が、上記の第１の実施形態と同様に、中間サーバ２００にリクエストを送信し、中間サーバ２００がリクエストに応じて送信したドキュメントを受信する。また、リソース受信部３０８は、中間サーバ２００から送信されたリソースを受信する。受信されたドキュメントおよびリソースは、文字列解釈部３１６に提供される。さらに、本実施形態では、関連付け情報受信部３１４が、中間サーバ２００の関連付け情報送信部２２６から送信された関連付け情報を受信する。関連付け情報受信部３１４は、受信した関連付け情報に基づいて、データベース３８２に短縮文字列レコードを生成する。

文字列解釈部３１６は、データベース３８２を参照して、ドキュメントおよびリソースに含まれる短縮文字列を解釈する。ここで、文字列解釈部３１６は、短縮文字列を元の文字列に書き換える必要はない。本実施形態では、文字列解釈部３１６が、データベース３８２を参照することによってドキュメントおよびリソースに含まれる短縮文字列をそのまま解釈し、その解釈に基づいて表示制御部３１０がドキュメントを表示させることが可能である。

なお、上述の通り、クライアント３００において受信されるドキュメントおよびリソースには、関連付け情報受信部３１４が受信する関連付け情報には含まれない短縮文字列も含まれる。例えば、ドキュメントやリソースのフォーマットにおける予約語について、予め短縮文字列と予約語との対応付けがデータベース３８２に記録されているような場合、関連付け情報受信部３１４が受信する関連付け情報に予約語に対応する短縮文字列は含まれない。

また、例えば、ドキュメント内の要素や、スタイルで定義されるクラス、プログラムで定義された関数などに与えられる任意の識別子について、ドキュメントおよびリソースを通じて、元の文字列と短縮文字列とが１対１で対応するように短縮文字列が生成されていれば、当該短縮文字列に対応する情報は関連付け情報には含まれず、またデータベース３８２にも含まれていなくてもよい。この場合、当該短縮文字列は、クライアント３００においては通常の文字列と同様に扱われ、表示制御部３１０が直接的にこれを解釈してドキュメントを表示させる。

（４−２．処理フロー）
（中間サーバの処理フロー）
図１１は、本開示の第３の実施形態に係る中間サーバの処理を示すフローチャートである。図１１を参照すると、まず、リクエスト受信部２０２が、クライアント３００からのリクエストを受信する（Ｓ３０１）。次に、ドキュメント取得部２０４が、リクエストにおいて指定されたドキュメントを取得する（Ｓ３０３）。次に、ドキュメント解析部２０６が、取得されたドキュメントを解析する（Ｓ３０５）。

ここで、ドキュメントの解析においてリソースへの参照が検出された場合（Ｓ３０７のＹＥＳ）、リソース取得部２０８が参照されているリソースを取得し（Ｓ３０９）、リソース解析部２２０が、取得されたリソースを解析する（Ｓ３１１）。その後、短縮文字列生成部２２２が、ドキュメントおよびリソースで検出された短縮可能な文字列について、短縮文字列を生成する（Ｓ３１３）。このとき、短縮文字列生成部２２２は、元の文字列と短縮文字列とを関連付ける短縮文字列レコードを、データベース２８２に追加する（Ｓ３１５）。

さらに、短縮文字列記述部２２４が、短縮文字列生成部２２２によって生成された短縮文字列によって、ドキュメントおよびリソースに含まれる元の文字列を置換する（Ｓ３１７）。ドキュメントにおける元の文字列の置換が完了すると、ドキュメント送信部２１４が、短縮文字列を含むドキュメントをクライアント３００に送信する（Ｓ３１９）。これと前後して、またはこれと並行して、関連付け情報送信部２２６が、データベース３８２のレコードに基づいて生成された関連付け情報をクライアント３００に送信する（Ｓ３２１）。さらに、リソース送信部２１６がクライアント３００に短縮文字列を含むリソースを送信する（Ｓ３２３）。

（クライアントの処理フロー）
図１２は、本開示の第３の実施形態に係るクライアントの処理を示すフローチャートである。図１２を参照すると、まず、リクエスト送信部３０２が、中間サーバ２００にリクエストを送信する（Ｓ３３１）。次に、ドキュメント受信部３０４が、中間サーバ２００がリクエストに応じて送信した、短縮文字列を含むドキュメントを受信する（Ｓ３３３）。これと前後して、またはこれと並行して、関連付け情報受信部３１４が、中間サーバ２００から送信された関連付け情報を受信する（Ｓ３３５）。関連付け情報受信部３１４は、受信した関連付け情報に基づいてデータベース３８２にレコードを生成する（Ｓ３３７）。また、リソース受信部３０８が、中間サーバ２００が送信した、短縮文字列を含むリソースを受信する（Ｓ３３９）。

Ｓ３３３でドキュメントが受信され、Ｓ３３７でデータベース３８２に短縮文字列レコードが生成されると、文字列解釈部３１６が、データベース３８２を参照して、ドキュメントに含まれる短縮文字列を解釈する（Ｓ３４１）。なお、Ｓ３４１の処理は、例えばＳ３３９の処理と並行して実行されてもよい。Ｓ３３９で受信された、ドキュメントで参照されているリソースについても、文字列解釈部３１６は、データベース３８２を参照して短縮文字列を解釈する（Ｓ３４３）。表示制御部３１０は、文字列解釈部３１６がドキュメントおよびリソースに含まれる短縮文字列を解釈した結果を利用して、ドキュメントを表示させる（Ｓ３４５）。

本実施形態では、中間サーバ２００において、短縮文字列生成部２２２が元の文字列と短縮文字列とを関連付けるレコードをデータベース２８２に追加する。これによって、例えば、短縮文字列の生成にあたってデータベース３８２を参照し、ドキュメントおよびリソースを通じて元の文字列と短縮文字列との関係を１対１の関係にすることができる。この場合、クライアント３００に関連付け情報を送信しなくても、クライアント３００がドキュメントとリソースとのそれぞれに記述された短縮文字列を解釈して、リソースを参照するドキュメントを表示させることが可能である。

あるいは、中間サーバ２００では、関連付け情報送信部２２６が、ドキュメントおよびリソースにおいてそれぞれ生成された短縮文字列と元の文字列とを関連付ける関連付け情報をデータベース２８２のレコードに基づいて生成し、これをクライアント３００に送信してもよい。この場合、例えば、短縮文字列の生成時には元の文字列と短縮文字列との関係が１対１になっていなくても、クライアント３００がドキュメントとリソースとのそれぞれに記述された短縮文字列を解釈して、リソースを参照するドキュメントを表示させることが可能である。

（４−３．変形例）
（中間サーバの処理フロー）
図１３は、本開示の第３の実施形態の変形例に係る中間サーバの処理を示すフローチャートである。図１３を参照すると、まず、上記で図１１を参照して説明した例と同様にＳ３０１〜Ｓ３０５が実行される。

本変形例では、短縮文字列生成部２２２が、ドキュメントで検出された短縮可能な文字列について、先行して短縮文字列を生成する（Ｓ３６１）。このとき、短縮文字列生成部２２２は、元の文字列と短縮文字列とを関連付けるレコードを、データベース２８２に追加する（Ｓ３１５）。さらに、短縮文字列記述部２２４が、データベース２８２のレコードに従って、ドキュメントに含まれる文字列を短縮文字列に置換する（Ｓ３６３）。置換が完了すると、ドキュメント送信部２１４が、短縮文字列を含むドキュメントをクライアント３００に送信する（Ｓ３１９）。ドキュメントの送信と前後して、またはこれと並行して、関連付け情報送信部２２６が、データベース２８２のレコードに基づいて生成された関連付け情報をクライアント３００に送信する（Ｓ３２１）。

ドキュメントおよび関連付け情報の送信後に、またはこれと並行して、ドキュメントの解析においてリソースへの参照が検出された場合（Ｓ３０７のＹＥＳ）、リソース取得部２０８が参照されているリソースを取得し（Ｓ３０９）、リソース解析部２２０が、取得されたリソースを解析する（Ｓ３１１）。その後、短縮文字列記述部２２４が、Ｓ３１５の処理によって生成されたデータベース３８２の短縮文字列レコードに基づいて、リソースに含まれる文字列を短縮文字列に置換する（Ｓ３６５）。その後、リソース送信部２１６が、クライアント３００に短縮文字列を含むリソースを送信する（Ｓ３２３）。

本変形例では、ドキュメントにおける短縮文字列の生成結果に基づいて、リソースの文字列が短縮文字列に置換される。これによって、ドキュメントと関連付け情報とを先行してクライアント３００に送信した上で、リソースについてもドキュメントと整合するように短縮文字列への置換を実行することができる。従って、リソースについての短縮文字列の置換の完了を待つことなく、クライアント３００でドキュメントの表示を開始することができる。

なお、本変形例におけるクライアントの処理フローは、リソース受信部３０８が、ドキュメントおよび関連付け情報が受信された後にリソースを受信する点を除いて、図１２に示したものと同様でありうるため、詳細な説明は省略する。また、上記の本実施形態の説明では、元の文字列と短縮文字列とを関連付ける情報がデータベースに格納される例について説明したが、情報は必ずしもデータベースに格納されなくてもよく、他の例ではファイルなどが用いられてもよい。

（５．第４の実施形態）
（５−１．機能構成）
図１４（図１４Ａおよび図１４Ｂ）は、本開示の第４の実施形態に係る中間サーバおよびクライアントの概略的な機能構成を示すブロック図である。図１４Ａを参照すると、中間サーバ２００は、機能構成として、リクエスト受信部２０２と、ドキュメント取得部２０４と、ドキュメント解析部２０６と、リソース取得部２０８と、識別子生成部２１０と、識別子記述部２１２と、リソース解析部２２０と、短縮文字列生成部２２２と、短縮文字列記述部２２４と、ドキュメント送信部２１４と、関連付け情報送信部２２６と、リソース送信部２１６とを含む。図１４Ｂを参照すると、クライアント３００は、機能構成として、リクエスト送信部３０２と、ドキュメント受信部３０４と、関連付け情報受信部３１４と、文字列解釈部３１６と、キャッシュ判定部３０６と、リソース受信部３０８と、表示制御部３１０とを含む。

これらの機能構成は、例えば、中間サーバ２００およびクライアント３００をそれぞれ実現する情報処理装置に備えられるプロセッサが、メモリまたは記録媒体に格納されたプログラムに従って動作することによって実現されうる。また、中間サーバ２００におけるキャッシュ２８０およびデータベース２８２、ならびにクライアント３００におけるキャッシュ３８０およびデータベース３８２は、例えば、それぞれの情報処理装置のストレージまたはメモリによって実現されうる。

図１４を参照すれば明らかなように、本実施形態は、上記の第１の実施形態と第３の実施形態とを合わせた実施形態である。中間サーバ２００およびクライアント３００の機能構成のそれぞれについては、第１および第３の実施形態において既に説明されているため、詳細な説明を省略する。

（５−２．処理フロー）
続いて、本実施形態の処理フローについて説明する。なお、以下の説明では、第１の実施形態および第３の実施形態のそれぞれの変形例を組み合わせたより複雑な処理フローについて説明するが、変形例ではない例を組み合わせた例についても同様に実現可能であることは容易に理解されるであろう。

（中間サーバの処理フロー）
図１５（図１５Ａおよび図１５Ｂ）は、本開示の第４の実施形態に係る中間サーバの処理を示すフローチャートである。図１５を参照すると、まず、リクエスト受信部２０２が、クライアント３００からのリクエストを受信する（Ｓ４０１）。次に、ドキュメント取得部２０４が、リクエストにおいて指定されたドキュメントを取得する（Ｓ４０３）。次に、ドキュメント解析部２０６が、取得されたドキュメントを解析する（Ｓ４０５）。

ここで、リソース取得部２０８は、ドキュメントで検出されたリソースへの参照について、参照されているリソースを取得する（Ｓ４０７）。識別子生成部２１０は、取得されたリソースの内容に基づいて一意な識別子を生成する（Ｓ４０９）。識別子記述部２１２は、生成された一意な識別子を、ドキュメントにおけるリソースへの参照に関連付ける（Ｓ４１１）。なお、上記の処理は、１または複数のリソースへの参照が検出される度に逐次実行されてもよいし、全部のリソースへの参照が検出されてから一括して実行されてもよい。

上記のＳ４０７〜Ｓ４１１と前後して、または並行して、短縮文字列生成部２２２が、ドキュメントで検出された短縮可能な文字列について、短縮文字列を生成する（Ｓ４１３）。このとき、短縮文字列生成部２２２は、元の文字列と短縮文字列とを関連付ける短縮文字列レコードを、データベース２８２に追加する（Ｓ４１５）。さらに、短縮文字列記述部２２４が、データベース２８２の短縮文字列レコードに従って、ドキュメントに含まれる文字列を短縮文字列に置換する（Ｓ４１７）。なお、図示された例のように、Ｓ４０７〜Ｓ４１１とＳ４１３〜Ｓ４１７とが並行して実行される場合は、ドキュメントにおけるリソースへの参照は、短縮文字列の生成の対象にならなくてもよい。

ここまでの処理が完了すると、ドキュメント送信部２１４が、識別子記述部２１２および短縮文字列記述部２２４によって更新されたドキュメントをクライアント３００に送信する（Ｓ４１９）。これと前後して、またはこれと並行して、関連付け情報送信部２２６が、データベース２８２のレコードに基づいて生成された関連付け情報をクライアント３００に送信する（Ｓ４２１）。

ドキュメントおよび関連付け情報の送信と前後して、またはこれと並行して、リソース解析部２２０が、上記のＳ４０７において取得されたリソースを解析する（Ｓ４２３）。その後、短縮文字列記述部２２４が、ドキュメントについての短縮文字列生成部２２２の処理によって生成されたデータベース２８２の短縮文字列レコードに基づいて、リソースに含まれる文字列を短縮文字列に置換する（Ｓ４２５）。その後、リソース送信部２１６が、クライアント３００からのリソースのリクエストに応じてクライアント３００にリソースを送信する（Ｓ４２７）。

（クライアントの処理フロー）
図１６（図１６Ａおよび図１６Ｂ）は、本開示の第４の実施形態に係るクライアントの処理を示すフローチャートである。図１６を参照すると、まず、リクエスト送信部３０２が、中間サーバ２００にリクエストを送信する（Ｓ４５１）。次に、ドキュメント受信部３０４が、中間サーバ２００がリクエストに応じて送信したドキュメントを受信する（Ｓ４５３）。

ドキュメントの受信と前後して、またはこれと並行して、関連付け情報受信部３１４が、中間サーバ２００から送信された関連付け情報を受信する（Ｓ４５５）。関連付け情報受信部３１４は、受信した関連付け情報に基づいてデータベース３８２に短縮文字列レコードを生成する（Ｓ４５７）。次に、文字列解釈部３１６が、データベース３８２を参照して、ドキュメントに含まれる短縮文字列を解釈する（Ｓ４５９）。表示制御部３１０は、文字列解釈部３１６による解釈に基づいて、受信されたドキュメントの表示を開始する（Ｓ４６１）。

ドキュメントにおいてリソースへの参照が発見された場合（Ｓ４６３のＹＥＳ）、キャッシュ判定部３０６が、受信されたドキュメントにおいて参照されているリソースについて、キャッシュ３８０に格納されているか（キャッシュされているか）否かを判定する（Ｓ４６５）。上述のように、キャッシュ判定部３０６は、ドキュメントにおけるリソースへの参照に関連付けられた、リソースの内容ごとに一意な識別子に基づいて、リソースがキャッシュ３８０に格納されているか否かを判定する。

リソースがキャッシュ３８０に格納されていると判定された場合（Ｓ４６５のＹＥＳ）、キャッシュ判定部３０６はキャッシュ３８０からリソースを読み出して文字列解釈部３１６に提供する。つまり、キャッシュ判定部３０６は、キャッシュ３８０されたリソースを再利用する（Ｓ４６７）。一方、リソースがキャッシュ３８０に格納されていないと判定された場合（Ｓ４６５のＮＯ）、キャッシュ判定部３０６は、中間サーバ２００にリソースのリクエストを送信する（Ｓ４６９）。リソース受信部３０８は、リクエストに応じて中間サーバ２００が送信したリソースを受信する（Ｓ４７１）。

文字列解釈部３１６は、データベース３８２のレコードに基づいて、再利用されたリソース、または中間サーバ２００から受信されたリソースに含まれる短縮文字列を解釈する（Ｓ４７３）。表示制御部３１０は、文字列解釈部３１６がドキュメントおよびリソースに含まれる短縮文字列を解釈した結果を利用して、ドキュメントの表示を継続する（Ｓ４７５）。Ｓ４６５〜Ｓ４７５は、ドキュメントにおけるリソースへの参照がすべて発見されるまで繰り返し実行されうる。表示制御部３１０がドキュメントの全体を表示させ、リソースへの参照も発見されなくなった場合、またはリソースへの参照が発見されなかった場合（Ｓ４６３のＮＯ）、クライアント３００はドキュメントの表示を完了する（Ｓ４７７）。

なお、本実施形態で、リソースについてクライアント３００におけるキャッシュ３８０を利用する場合、リソースに含まれる短縮文字列は、リソースが参照される機会に関わらず同一であることが望ましい。従って、例えば、中間サーバ２００において、短縮文字列生成部２２２が所定のアルゴリズムを利用して短縮文字列を生成し、元の文字列が同じであれば自動的に同じ短縮文字列が生成されるようにしてもよい。あるいは、中間サーバ２００におけるデータベース２８２を複数のドキュメントについて共通で利用することによって、元の文字列が同じであれば同じ短縮文字列が生成されるようにしてもよい。

（６．第５の実施形態）
図１７Ａは、本開示の第５の実施形態に係る中間サーバの処理を示すフローチャートである。なお、図示された一連の処理は、中間サーバ２００を実現する情報処理装置に備えられるプロセッサがメモリまたは記録媒体に格納されたプログラムに従って動作することによって実行されうる。

図１７Ａを参照すると、まず、プロセッサは、クライアント３００からのリクエストを受信する（Ｓ５０１）。次に、プロセッサは、リクエストにおいて指定されたドキュメントを取得する（Ｓ５０３）。上記の他の実施形態と同様に、プロセッサは、ドキュメントを配信元サーバ１００から取得してもよいし、キャッシュから内部的に取得してもよい。次に、プロセッサは、ドキュメントにおいて参照されているリソースを取得する（Ｓ５０５）。リソースも、配信元サーバ１００から取得されてもよいし、キャッシュから内部的に取得されてもよい。

さらに、プロセッサは、取得されたドキュメントおよびリソースに基づいて中間データを生成する（Ｓ５０７）。中間データの生成は、例えば、ＨＴＭＬドキュメントのパースによるＤＯＭ（Document Object Model）の生成、ＣＳＳの処理によるComputed Styleの生成、およびＪａｖａＳｃｒｉｐｔのパースによる中間表現への変換などを含みうる。プロセッサは、生成された中間データをクライアント３００に送信する（Ｓ５０９）。

図１７Ｂは、本開示の第５の実施形態に係るクライアントの処理を示すフローチャートである。なお、図示された一連の処理は、クライアント３００を実現する情報処理装置に備えられるプロセッサがメモリまたは記録媒体に格納されたプログラムに従って動作することによって実行されうる。

図１７Ｂを参照すると、まず、プロセッサは、中間サーバ２００にリクエストを送信する（Ｓ５２１）。次に、プロセッサは、中間サーバ２００がリクエストに応じて送信した、ドキュメントおよびリソースに基づく中間データを受信する（Ｓ５２３）。プロセッサは、受信した中間データに基づいてレイアウトを生成し（Ｓ５２５）、レイアウトに従ってドキュメントを表示させる（Ｓ５２７）。

本実施形態によれば、クライアント３００でドキュメントを表示するための処理の一部が中間サーバ２００で代わりに実行される。中間サーバ２００の処理能力がクライアント３００よりも高ければ、これによってクライアント３００でリクエストを送信してからドキュメントの表示が完了するまでの時間が短縮される。

なお、中間サーバ２００でどのような中間データを生成するかは、ネットワークの状況や、クライアント３００の処理能力などに応じて適宜決定される。例えば、ＨＴＭＬドキュメントに関する上記の３つの例のうち、１つだけが採用されてもよいし、いずれか２つが採用されてもよいし、３つ全部が採用されてもよい。

以下、本実施形態におけるＪａｖａＳｃｒｉｐｔのパースによる中間表現への変換の例について、さらに詳しく説明する。

通常の場合、ＪａｖａＳｃｒｉｐｔは、Ｗｅｂブラウザに組み込まれたＪＩＴ（Just In Time）コンパイラによって、コードの実行時にコンパイルおよび最適化される。最適化によってコードの実行時間は短縮される。しかしながら、ドキュメントの表示に要する時間全体としてみると、コンパイルおよび最適化のための時間がオーバーヘッドとなっており、実行時間の短縮分を相殺している。従って、最適化の効果が十分に発揮されているとはいいがたい。一例では、コンパイルおよび最適化のための時間は、ドキュメントの表示に要する時間全体の１５％〜２５％を占める場合もある。

そこで、本実施形態のいくつかの例では、中間サーバ２００でコンパイラがＪａｖａＳｃｒｉｐｔを予めパースして中間表現に変換することによって、クライアント３００におけるコンパイルや最適化のための処理時間を削減しつつ、最適化による実行時間の短縮効果を得ることができる。また、ＪａｖａＳｃｒｉｐｔが中間表現に変換されることによってコードのデータ量が減少すれば、中間サーバ２００とクライアント３００との間の通信時間も削減することができる。

なお、上記の例においても、クライアント３００でＪＩＴコンパイラによるコンパイルおよび／または最適化が実行されてもよい。例えば、中間サーバ２００のコンパイラがグローバルな最適化を実行するとともに、クライアント３００でＪＩＴコンパイラがさらなる最適化を実行してもよい。あるいは、中間サーバ２００におけるコードの解析結果に基づく最適化のためのヒントとなる情報をドキュメントに付加し、ＪＩＴコンパイラでの最適化をより高速かつ有効的に実施することも可能である。

図１８Ａは、ＪＩＴコンパイラの通常の処理の例を示すフローチャートである。なお、図示された一連の処理は、例えばクライアントを実現する情報処理装置に備えられるプロセッサがメモリまたは記録媒体に格納されたプログラムに従ってＪＩＴコンパイラとして動作することによって実行されうる。

図１８Ａを参照すると、まず、プロセッサは、サーバからドキュメントに伴うリソースとして送信されたＪａｖａＳｃｒｉｐｔのソースを読み込む（Ｓ５３１）。次に、プロセッサは、ＪａｖａＳｃｒｉｐｔをパースし（Ｓ５３３）、ＡＳＴ（Abstract Syntax Tree）を構築する（Ｓ５３５）。ここで、プロセッサは、例えばドキュメントまたはＪＩＴコンパイラの設定情報に基づいて、最適化を実施するか否かを判定する（Ｓ５３７）。最適化を実施する場合、プロセッサは、Ｓ５３５で構築したＡＳＴを高レベル中間表現（ＩＲ：Intermediate Representation）に変換する（Ｓ５３９）。さらに、プロセッサは、高レベルＩＲを最適化する（Ｓ５４１）。続いて、プロセッサは、最適化された高レベルＩＲを、低レベルＩＲに変換する（Ｓ５４３）。プロセッサは、低レベルＩＲについても最適化する（Ｓ５４５）。最適化された低レベルＩＲに基づいて、プロセッサはネイティブコードを生成する（Ｓ５４７）。なお、Ｓ５３７で最適化を実施しない場合、プロセッサは最適化されていないＡＳＴに基づいてネイティブコードを生成する（Ｓ５４７）。

図１８Ｂは、本開示の第５の実施形態のいくつかの例に係る中間サーバ２００のコンパイラの処理の例を示すフローチャートである。なお、図示された一連の処理は、例えば中間サーバ２００を実現する情報処理装置に備えられるプロセッサがメモリまたは記録媒体に格納されたプログラムに従ってコンパイラとして動作することによって実行されうる。

図１８Ｂを参照すると、まず、プロセッサは、処理対象のドキュメントに対応するリソースから、ＪａｖａＳｃｒｉｐｔのソースを読み込む（Ｓ５５１）。次に、プロセッサは、ＪａｖａＳｃｒｉｐｔをパースし（Ｓ５５３）、ＡＳＴを構築する（Ｓ５５５）。ここで、プロセッサは、例えばドキュメントまたはコンパイラの設定情報に基づいて、最適化を実施するか否かを判定する（Ｓ５５７）。最適化を実施する場合、プロセッサは、Ｓ５５５で構築したＡＳＴを高レベルＩＲに変換する（Ｓ５５９）。さらに、プロセッサは、高レベルＩＲを最適化する（Ｓ５６１）。プロセッサは、最適化された高レベルＩＲをクライアント３００に送信する（Ｓ５６３）。なお、Ｓ５５７の判定において最適化を実施しない場合、プロセッサは、最適化されていないＡＳＴをクライアント３００に送信する（Ｓ５６５）。

図１８Ｃは、図１８Ｂの例に係るクライアント３００のＪＩＴコンパイラの処理の例を示すフローチャートである。なお、図示された一連の処理は、例えばクライアント３００を実現する情報処理装置に備えられるプロセッサがメモリまたは記録媒体に格納されたプログラムに従ってＪＩＴコンパイラとして動作することによって実行されうる。

図１８Ｃを参照すると、まず、プロセッサは、中間サーバ２００からコードを受信する（Ｓ５７１）。図１８ＢのＳ５６３，５６５で説明されたように、ここで受信されるコードは、最適化された高レベルＩＲか、最適化されていないＡＳＴである。プロセッサは、例えばドキュメントまたはＪＩＴコンパイラの設定情報に基づいて、最適化を実施するか否かを判定する（Ｓ５７３）。最適化を実施する場合、プロセッサは、受信されたコードが高レベルＩＲであるか否かを判定する（Ｓ５７５）。つまり、クライアント３００側で読み取られる設定情報では最適化を実施することになっていても、中間サーバ２００では最適化が実施されていないことがありうる。このような設定は、例えば後述するような理由によりクライアント３００だけで最適化を実施する方が有利であるような場合に採用されうる。

Ｓ５７５の判定において、受信されたコードが高レベルＩＲではない場合、プロセッサは、受信されたコード（ＡＳＴ）を高レベルＩＲに変換し（Ｓ５７７）、さらに最適化する（Ｓ５７９）。続いて、プロセッサは、高レベルＩＲを低レベルＩＲに変換する（Ｓ５８１）。ここで用いられる高レベルＩＲは、Ｓ５７９で最適化された高レベルＩＲか、中間サーバ２００で生成されて受信されたコードに含まれていた高レベルＩＲである。さらに、プロセッサは、低レベルＩＲを最適化し（Ｓ５８３）、最適化された低レベルＩＲに基づいてネイティブコードを生成する（Ｓ５８５）。

一方、Ｓ５７３の判定において最適化を実施しない場合も、プロセッサは、受信されたコードが高レベルＩＲであるか否かを判定する（Ｓ５８７）。つまり、クライアント３００側で読み取られる設定情報では最適化を実施しないことになっていても、中間サーバ２００では最適化が実施されていることがありうる。このような設定は、例えば後述するような理由により中間サーバ２００だけで最適化を実施する方が有利であるような場合に採用されうる。

Ｓ５８７の判定において、受信されたコードが高レベルＩＲである場合、プロセッサは、高レベルＩＲを低レベルＩＲに変換し（Ｓ５８９）、低レベルＩＲに基づいてネイティブコードを生成する（Ｓ５８５）。一方、受信されたコードが高レベルＩＲではない場合、プロセッサは、受信されたコード（ＡＳＴ）に基づいてネイティブコードを生成する（Ｓ５８５）。

上記の例では、中間サーバ２００のコンパイラによってＪａｖａＳｃｒｉｐｔのパースおよびＡＳＴの構築が実施される。従って、中間サーバ２００からクライアント３００に送信される、ＪａｖａＳｃｒｉｐｔに対応する中間コードのリソースは、少なくともＡＳＴを含む。それゆえ、クライアント３００では、ＡＳＴの構築までに要する時間分のオーバーヘッドが削減される。

なお、中間コードのサイズが大きいと、転送時の通信によるオーバーヘッドが増加するため、ドキュメントの表示に要する時間全体としての短縮にはつながらない可能性がある。そのため、実行時に必要ではない情報、例えばシンボル情報などを中間コードから除去し、さらに使用される文字列を短縮するなどして中間コードを最小化し、中間サーバ２００とクライアント３００との間の通信時間を削減することが望ましい。

さらに、例えばドキュメントまたはコンパイラの設定情報において中間サーバ２００での最適化が有効化されている場合、中間サーバ２００のコンパイラがＡＳＴを高レベルＩＲに変換し、さらに最適化した上でクライアント３００に送信する。この場合、クライアント３００での最適化の処理時間が削減される一方で、中間サーバ２００での最適化によって実行時間は短縮されるため、クライアント３００においてドキュメントの表示に要する時間がさらに短縮されうる。

ただし、一般的には、実行速度の最適化を実施するとコードのサイズは大きくなる傾向があるため、最適化によってコードのサイズが大きくなる場合には、中間サーバ２００で最適化された高レベルＩＲをクライアントに送信するのではなく、最適化のヒント（手順など）を示す情報を付加した上で、最適化前の中間コード（ＡＳＴまたは高レベルＩＲ）をクライアント３００に送信してもよい。この場合、付加された情報に従ってクライアント３００のＪＩＴコンパイラが最適化を実施することによって、通信時間と処理時間との両方を削減できる可能性がある。

（７．第６の実施形態）
図１９は、本開示の第６の実施形態に係る中間サーバの処理を示すフローチャートである。なお、図示された一連の処理は、中間サーバ２００を実現する情報処理装置に備えられるプロセッサがメモリまたは記録媒体に格納されたプログラムに従って動作することによって実行されうる。なお、本実施形態に限り、ドキュメントをＨＴＭＬドキュメント、リソースをＣＳＳとして説明する。

図１９を参照すると、まず、プロセッサは、クライアント３００からのリクエストを受信する（Ｓ６０１）。次に、プロセッサは、リクエストにおいて指定されたＨＴＭＬドキュメントを取得する（Ｓ６０３）。上記の他の実施形態と同様に、プロセッサは、ＨＴＭＬドキュメントを配信元サーバ１００から取得してもよいし、キャッシュから内部的に取得してもよい。次に、プロセッサは、ＨＴＭＬドキュメントにおいて参照されているＣＳＳを取得する（Ｓ６０５）。ＣＳＳも、配信元サーバ１００から取得されてもよいし、キャッシュから内部的に取得されてもよい。

さらに、プロセッサは、ＨＴＭＬドキュメントの要素ごとに、ＣＳＳによって定義されるスタイルを特定する（Ｓ６０７）。ＨＴＭＬドキュメントで階層構造をなす複数のＣＳＳが参照されている場合、Ｓ６０７の処理によって、複数のＣＳＳのうちのどのスタイルの組み合わせが採用されるのかが特定される。プロセッサは、Ｓ６０７の処理の結果に基づいてＣＳＳを更新し（Ｓ６０９）、ドキュメントとともに更新されたＣＳＳをクライアント３００に送信する（Ｓ６１１）。

本実施形態において、クライアント３００は、中間サーバ２００から受信したＨＴＭＬドキュメントおよびＣＳＳに基づいて、ＨＴＭＬドキュメントを表示させる。このときの処理は、通常のＨＴＭＬドキュメントの表示のための処理と同様であるため詳細な説明は省略する。しかしながら、本実施形態の場合、クライアント３００で参照されるＣＳＳは、上述したような中間サーバ２００での処理によって最適化されている。従って、クライアント３００は、ＨＴＭＬドキュメントの各要素について定義されるスタイルを特定するための処理の大部分を省略することができる。従って、中間サーバ２００の処理能力がクライアント３００よりも高ければ、これによってクライアント３００でリクエストを送信してからドキュメントの表示が完了するまでの時間が短縮される。

なお、上記の説明ではリソースをＣＳＳとしたが、ＨＴＭＬドキュメントではＣＳＳとともに画像やスクリプトなどの他のリソースがあわせて参照されてもよい。

（８．第７の実施形態）
（８−１．機能構成）
図２０は、本開示の第７の実施形態に係る中間サーバおよびクライアントの概略的な機能構成を示すブロック図である。図２０を参照すると、中間サーバ２００は、機能構成として、リクエスト受信部２０２と、ドキュメント取得部２０４と、ドキュメント解析部２０６と、リソース取得部２０８と、画像トランスコード部２２８と、画像参照更新部２３０と、ドキュメント送信部２１４と、リソース送信部２１６とを含む。クライアント３００は、機能構成として、リクエスト送信部３０２と、ドキュメント受信部３０４と、リソース受信部３０８と、表示制御部３１０とを含む。

これらの機能構成は、例えば、中間サーバ２００およびクライアント３００をそれぞれ実現する情報処理装置に備えられるプロセッサが、メモリまたは記録媒体に格納されたプログラムに従って動作することによって実現されうる。また、中間サーバ２００におけるキャッシュ２８０、およびクライアント３００におけるキャッシュ３８０は、例えば、それぞれの情報処理装置のストレージまたはメモリによって実現されうる。

（中間サーバ）
中間サーバ２００では、リクエスト受信部２０２およびドキュメント取得部２０４が、上記の第１の実施形態と同様に、クライアント３００からのリクエストに応じてドキュメントを取得する。また、ドキュメント解析部２０６は、ドキュメント取得部２０４が取得したドキュメントを解析し、ドキュメントに含まれるリソースへの参照を検出する。リソース取得部２０８は、ドキュメント解析部２０６によってリソースへの参照が検出された場合に、参照されているリソースを取得する。

ここで、リソース取得部２０８が取得するリソースには、さまざまなフォーマットの画像が含まれる。画像トランスコード部２２８は、取得された画像を所定のフォーマットにトランスコードし、トランスコードされた画像をキャッシュ２８０に格納する。画像参照更新部２３０は、ドキュメントに含まれる画像リソースへの参照を、キャッシュ２８０に格納された、画像トランスコード部２２８によるトランスコード後の画像への参照に更新する。ドキュメント送信部２１４は、参照が更新されたドキュメントをクライアント３００に送信する。リソース送信部２１６は、クライアント３００からのリクエストに応じてキャッシュ２８０に格納されたリソースを送信する。送信されるリソースには、画像トランスコード部２２８によって所定のフォーマットにトランスコードされた画像が含まれうる。

（クライアント）
クライアント３００では、リクエスト送信部３０２およびドキュメント受信部３０４が、上記の第１の実施形態と同様に、中間サーバ２００にリクエストを送信し、中間サーバ２００がリクエストに応じて送信したドキュメントを受信する。表示制御部３１０は、受信されたドキュメントを表示させる。このとき、ドキュメントにおいて参照されているリソースがキャッシュ３８０に格納されていなければ、リソース受信部３０８が中間サーバ２００にリクエストを送信し、リクエストに応じて送信されたリソースを受信する。ここで受信されるリソースには、上記の画像トランスコード部２２８によって所定のフォーマットにトランスコードされた画像が含まれうる。表示制御部３１０は、キャッシュ３８０に格納されたリソース、またはリソース受信部３０８によって受信されたリソースを利用してドキュメントを表示させる。

（８−２．処理フロー）
図２１は、本開示の第７の実施形態に係る中間サーバの処理を示すフローチャートである。図２１を参照すると、まず、リクエスト受信部２０２が、クライアント３００からのリクエストを受信する（Ｓ７０１）。次に、ドキュメント取得部２０４が、リクエストにおいて指定されたドキュメントを取得する（Ｓ７０３）。次に、ドキュメント解析部２０６が、取得されたドキュメントを解析する（Ｓ７０５）。

ここで、ドキュメントの解析において画像への参照が検出された場合（Ｓ７０７のＹＥＳ）、まず、画像参照更新部２３０が、ドキュメントに含まれる画像リソースへの参照を、トランスコード後の画像への参照に更新する（Ｓ７０９）。図示された例では、この時点でまだ画像のトランスコードが実行されていないため、先にトランスコード後の画像のファイル名などの識別子が決定されることになる。決定された識別子は、ドキュメントの参照に記述されるとともに中間サーバ２００のメモリに一時的に記憶され、後に生成されるトランスコードされた画像に関連付けられる。

次に、ドキュメント送信部２１４が、画像リソースへの参照が更新されたドキュメントをクライアント３００に送信する（Ｓ７１１）。ドキュメントの送信後に、またはこれと並行して、リソース取得部２０８が参照されている画像を取得する（Ｓ７１３）。画像トランスコード部２２８は、取得された画像を所定のフォーマットにトランスコードする（Ｓ７１５）。なお、画像トランスコード部２２８は、トランスコードされた画像が既にキャッシュ２８０に格納されていれば、再度のトランスコードの処理を省略してもよい。その後、リソース送信部２１６が、クライアント３００からリソースのリクエストに応じて、トランスコードされた画像を含むリソースをクライアント３００に送信する（Ｓ７１７）。

上述のように、中間サーバ２００の処理能力がクライアント３００に比べて高い場合でも、画像のトランスコードにはある程度の時間がかかる。従って、上記の処理フローのように、トランスコード後の画像の識別子を先に決定しておき、画像への参照が更新されたドキュメントを先行して中間サーバ２００からクライアント３００に送信し、クライアント３００でドキュメントが受信されて表示が開始されるのと並行して中間サーバ２００で画像のトランスコードを実行することで、クライアント３００でドキュメントの表示が完了するまでの時間を短縮することができる。

例えば、ドキュメントにおける画像の参照が少なかったり、参照された画像の多くが既にトランスコードされて中間サーバ２００のキャッシュ２８０に格納されていたりするような場合には、画像トランスコード部２２８が画像のトランスコードを完了した後に、ドキュメント送信部２１４がドキュメントをクライアント３００に送信してもよい。なお、いずれの場合も、クライアント３００における処理は、参照されるリソースにトランスコードされた画像が含まれることを除けば、通常のドキュメントの表示のための処理と同様であるため詳細な説明は省略する。

（８−３．トランスコードの例）
次に、本実施形態における画像のトランスコードの例について、さらに説明する。

通常、配信元サーバ１００から取得されるリソースに含まれる画像は、例えばＪＰＥＧやＰＮＧ、ＧＩＦなど、多種多様なフォーマットで記述されている。しかも、画像がこれらのフォーマットに厳密には従っていない場合もしばしばである。それゆえ、配信元サーバ１００から取得された画像（中間サーバ２００またはクライアント３００でキャッシュされたものを含む）をクライアント３００でデコードするときには、様々なケースを想定する必要があるために処理を最適化することが難しく、処理の効率が必ずしも高くなかった。また、ドキュメントの表示のために中間サーバ２００からクライアント３００に転送されるデータの中では画像が大きな割合を占めることが多く、画像のデータ量を削減する需要も依然として高かった。

そこで、本実施形態では、中間サーバ２００において画像をトランスコードする。例えば、中間サーバ２００の画像トランスコード２８２が、配信元サーバ１００から取得された画像をそれぞれのフォーマットの純正な形式にトランスコードするだけでも、クライアント３００でのデコードをある程度最適化することが可能になり、ドキュメントの表示が高速化されうる。さらに、画像トランスコード２８２が、配信元サーバ１００から取得された画像を、クライアント３００でのデコード処理を最適化することが可能な１または複数の所定のフォーマットにトランスコードすれば、ドキュメントの表示のさらなる高速化が可能である。

（８−４．フォーマットの例）
次に、本実施形態における画像のトランスコードに適用することが可能な、画像のフォーマットの例について、さらに説明する。以下で説明する画像のフォーマットは、例えば本実施形態のような中間サーバにおけるトランスコードに組み合わせて実施されてもよいが、そのような例には限られず、画像フォーマットそれ自体として実施される場合にも様々な利点をもたらしうるものである。つまり、本開示の実施形態には、トランスコードとは独立した、画像のフォーマット（例えば当該フォーマットの画像を扱う画像処理装置または画像処理方法など）が含まれうる。

図２２および図２３は、本開示の第７の実施形態で適用されうる画像フォーマットに従った画像ファイルの生成処理について説明するための図である。ここで説明される処理は、例えば上記の中間サーバ２００の画像トランスコード部２２８によって実行されうる。

まず、図２２に示されるように、ビットマップ形式（ＪＰＥＧやＰＮＧ、ＧＩＦなどを含む）で記述された原画像７００から、ベクター成分７０４と、ビットマップ成分７０６と、近似誤差７０８とが算出される。この処理では、まず、原画像７００を２つの領域群７０２ａ，７０２ｂに分割する（Ｓ７５１）。領域群７０２ａは、空間周波数が低く、かつ広い領域である。一方、領域群７０２ｂは、空間周波数が高く、かつ狭い領域である。領域の分割は、例えば分割統合（split-and-merge）法など、公知の各種の手法によって実現することが可能である。

領域群７０２ａについては、Ｓ７５３〜Ｓ７６１の処理によってベクター成分７０４が生成される。まず、領域群７０２ａに含まれる各領域についてエッジが抽出され、アウトラインがベジエ曲線で近似される（Ｓ７５３）。さらに、近似されたアウトライン内での色の勾配が求められる（Ｓ７５５）。ここで、色の勾配が比較的均一であれば（Ｓ７５７のＹＥＳ）、頂点色を設定して単純補間によって領域の色が表現される（Ｓ７５９）。そうでなければ、領域の色がモデル化して表現される（Ｓ７６１）。モデルとしては、例えば３次元コンピュータグラフィックスのシェーディングモデルなどが適用されうる。シェーディングモデルでは、３次曲面と光源とを設定することで、スペキュラーなどを表現することができる。以上のような処理によって、領域群７０２ａの各領域について、近似されたアウトラインとアウトライン内の色とを表現することによって、ベクター成分７０４を生成することができる。

一方、領域群７０２ｂの各領域については、画像として圧縮することによって（Ｓ７６３）、ビットマップ成分７０６が生成される。Ｓ７６３での画像の圧縮には、例えばＤＣＴ（Discrete Cosine Transform）やＶＱ（Vector Quantization）などの公知の技術が利用されうる。

さらに、領域群７０２ａの領域ではベクター成分７０４と原画像７００との差分、領域群７０２ｂの領域ではビットマップ成分７０６と原画像７００との差分をそれぞれ算出することによって（Ｓ７６５）、ベクター成分７０４およびビットマップ成分７０６と原画像７００との近似誤差７０８を得ることができる。

次に、図２３に示されるように、ベクター成分７０４と、ビットマップ成分７０６と、近似誤差７０８とに基づいて、エンコードされた画像ファイル７１４が生成される。まず、ベクター成分７０４とビットマップ成分７０６とのそれぞれのバウンディングボックス（ｂｂｏｘ）に基づいて原画像７００の領域を分割し、当該分割を示すｋ−ｄツリー７１０を生成する（Ｓ７６７）。さらに、近似誤差７０８をｋ−ｄツリー７１０の領域分割線で振り分けることによって（Ｓ７６９）、近似誤差成分７１２を得ることができる。

このようにして得られたベクター成分７０４と、ビットマップ成分７０６と、ｋ−ｄツリー７１０と、近似誤差成分７１２とをシリアライズすることによって（Ｓ７７１）、画像ファイル７１４が生成される。

画像ファイル７１４では、先頭にｋ−ｄツリー７１０が構造データとして記述される。これによって、描画したい領域の成分を迅速にシークすることができる。続いて、ベクター成分７０４、ビットマップ成分７０６、および近似誤差成分７１２が記述される。なお、ｋ−ｄツリー７１０以外の成分については、画像ファイル７１４内での配列の順番は特に限定されない。

ベクター成分７０４では、各頂点データがｂｂｏｘで正規化されている。従って、仮数部が必要とする有効桁数を削減し、データを圧縮することができる。また、近似誤差成分７１２については、誤差０の領域が大半であればｒｕｎ−ｌｅｎｇｔｈ圧縮が可能である。また、誤差があっても小規模な誤差に分布が集中するはずであるため、ＬＺＷなどのアルゴリズムを用いて圧縮することができる。

ベクター成分７０４は、例えば、ベジエ曲線で囲まれた領域を単色でべた塗りすることを表現する。以下に、ベクター成分７０４の記述内容の一例を示す。なお、例は説明のために記述内容をＰｏｓｔＳｃｒｉｐｔ形式で表現しているが、実際のベクター成分７０４は、例えばバイナリエンコードされた上で圧縮される。
newpath
0 100 moveto
100 50 150 50 250 0 rcurveto
100 -50 150 -50 250 0 rcurveto
closepath
0 .3 1 .0 setcolor
fill

ビットマップ成分７０６は、例えば、矩形領域にビットマップパターンを適用することを表現する。以下に、ビットマップ成分７０６の記述内容の一例を示す。なお、例は説明のために記述内容をＰｏｓｔＳｃｒｉｐｔ形式で表現しているが、実際のビットマップ成分７０６は、例えばバイナリエンコードされた上で圧縮される。なお、xxxx piximageはFill patternとして用いられるビットマップを示す。
newpath
100 100 moveto
100 0 rlineto
0 100 rlineto
-100 0 rlineto
closepath
xxxx piximage
fill

（８−５．デコード処理の例）
次に、上記の例における画像ファイル７１４を、クライアント３００においてデコードするときの処理の例について説明する。

（ダウンロード完了後にデコードする場合）
まず、ダウンロード完了後にデコードする場合の処理について説明する。この場合、クライアント３００の表示制御部３１０は、画像ファイル７１４に含まれるベクター成分７０４を順に描画する。この例では、パスに重複がある場合は、後から描画されたベクター成分７０４のパスが優先される。

次に、表示制御部３１０は、画像ファイル７１４に含まれるビットマップ成分７０６を順に描画する。このとき、ビットマップ成分７０６による描画は、ベクター成分７０４による描画に上書きされる。また、ビットマップ成分７０６の間でパスに重複がある場合は、後から描画されたビットマップ成分７０６のパスが優先される。

次に、表示制御部３１０は、各領域の画像に近似誤差成分７１２を足し合わせる。近似誤差成分７１２は、例えば、ＲＧＢＡ（Red Green Blue Alpha）のそれぞれについて足し合わされてもよい。

（ダウンロード途中で描画する場合）
ダウンロード途中で描画する場合、第１の例として、クライアント３００の表示制御部３１０は、画像ファイル７１４のダウンロードの進捗に合わせて、ベクター成分７０４、ビットマップ成分７０６、および近似誤差成分７１２の順で描画する。これによって、まず広い範囲の色が確定し、その後段階的に画像が詳細化されているような表示が可能になる。

また、第２の例として、クライアント３００の表示制御部３１０は、まず画像ファイル７１４の先頭にあるｋ−ｄツリー７１０をダウンロードする。表示制御部３１０は、ｋ−ｄツリー７１０から、特定の領域に該当するベクター成分７０４、ビットマップ成分７０６、および近似誤差成分７１２へのポインタ情報を得ることができる。そこで、表示制御部３１０は、ファイルシークまたはＨＴＴＰレンジリクエストなどを利用して、上記のポインタ情報によって参照されるベクター成分７０４、ビットマップ成分７０６、および近似誤差成分７１２をダウンロードする。ダウンロードされたデータを用いて、表示制御部３１０は、上記特定の範囲をベクター成分７０４、ビットマップ成分７０６、および近似誤差成分７１２の順に描画し、当該領域についてのデコードを終了する。

以上で説明した本実施形態によれば、例えば、ドキュメントにおいて参照される画像のファイルサイズを削減することによって、通信容量を削減することができる。また、画像が単純なグラデーションや単色での塗りつぶしを含むような場合には、これらの部分をトランスコーディングによってベクター化することによって、デコード処理を高速化することができる。

（９．ハードウェア構成）
次に、図２４を参照して、本開示の実施形態に係る情報処理装置のハードウェア構成について説明する。図２４は、本開示の実施形態に係る情報処理装置のハードウェア構成例を説明するためのブロック図である。図示された情報処理装置９００は、例えば、上記の実施形態におけるサーバおよびクライアントを実現しうる。

情報処理装置９００は、ＣＰＵ（Central Processing unit）９０１、ＲＯＭ（Read Only Memory）９０３、およびＲＡＭ（Random Access Memory）９０５を含む。また、情報処理装置９００は、ホストバス９０７、ブリッジ９０９、外部バス９１１、インターフェース９１３、入力装置９１５、出力装置９１７、ストレージ装置９１９、ドライブ９２１、接続ポート９２３、通信装置９２５を含んでもよい。さらに、情報処理装置９００は、必要に応じて、撮像装置９３３、およびセンサ９３５を含んでもよい。情報処理装置９００は、ＣＰＵ９０１に代えて、またはこれとともに、ＤＳＰ（Digital Signal Processor）またはＡＳＩＣ（Application Specific Integrated Circuit）と呼ばれるような処理回路を有してもよい。

ＣＰＵ９０１は、演算処理装置および制御装置として機能し、ＲＯＭ９０３、ＲＡＭ９０５、ストレージ装置９１９、またはリムーバブル記録媒体９２７に記録された各種プログラムに従って、情報処理装置９００内の動作全般またはその一部を制御する。ＲＯＭ９０３は、ＣＰＵ９０１が使用するプログラムや演算パラメータなどを記憶する。ＲＡＭ９０５は、ＣＰＵ９０１の実行において使用するプログラムや、その実行において適宜変化するパラメータなどを一次記憶する。ＣＰＵ９０１、ＲＯＭ９０３、およびＲＡＭ９０５は、ＣＰＵバスなどの内部バスにより構成されるホストバス９０７により相互に接続されている。さらに、ホストバス９０７は、ブリッジ９０９を介して、ＰＣＩ（Peripheral Component Interconnect/Interface）バスなどの外部バス９１１に接続されている。

入力装置９１５は、例えば、マウス、キーボード、タッチパネル、ボタン、スイッチおよびレバーなど、ユーザによって操作される装置である。入力装置９１５は、例えば、赤外線やその他の電波を利用したリモートコントロール装置であってもよいし、情報処理装置９００の操作に対応した携帯電話などの外部接続機器９２９であってもよい。入力装置９１５は、ユーザが入力した情報に基づいて入力信号を生成してＣＰＵ９０１に出力する入力制御回路を含む。ユーザは、この入力装置９１５を操作することによって、情報処理装置９００に対して各種のデータを入力したり処理動作を指示したりする。

出力装置９１７は、取得した情報をユーザに対して視覚的または聴覚的に通知することが可能な装置で構成される。出力装置９１７は、例えば、ＬＣＤ（Liquid Crystal Display）、ＰＤＰ（Plasma Display Panel）、有機ＥＬ（Electro-Luminescence）ディスプレイなどの表示装置、スピーカおよびヘッドホンなどの音声出力装置、ならびにプリンタ装置などでありうる。出力装置９１７は、情報処理装置９００の処理により得られた結果を、テキストまたは画像などの映像として出力したり、音声または音響などの音声として出力したりする。

ストレージ装置９１９は、情報処理装置９００の記憶部の一例として構成されたデータ格納用の装置である。ストレージ装置９１９は、例えば、ＨＤＤ（Hard Disk Drive）などの磁気記憶部デバイス、半導体記憶デバイス、光記憶デバイス、または光磁気記憶デバイスなどにより構成される。このストレージ装置９１９は、ＣＰＵ９０１が実行するプログラムや各種データ、および外部から取得した各種のデータなどを格納する。

ドライブ９２１は、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリなどのリムーバブル記録媒体９２７のためのリーダライタであり、情報処理装置９００に内蔵、あるいは外付けされる。ドライブ９２１は、装着されているリムーバブル記録媒体９２７に記録されている情報を読み出して、ＲＡＭ９０５に出力する。また、ドライブ９２１は、装着されているリムーバブル記録媒体９２７に記録を書き込む。

接続ポート９２３は、機器を情報処理装置９００に直接接続するためのポートである。接続ポート９２３は、例えば、ＵＳＢ（Universal Serial Bus）ポート、ＩＥＥＥ１３９４ポート、ＳＣＳＩ（Small Computer System Interface）ポートなどでありうる。また、接続ポート９２３は、ＲＳ−２３２Ｃポート、光オーディオ端子、ＨＤＭＩ（High-Definition Multimedia Interface）ポートなどであってもよい。接続ポート９２３に外部接続機器９２９を接続することで、情報処理装置９００と外部接続機器９２９との間で各種のデータが交換されうる。

通信装置９２５は、例えば、通信ネットワーク９３１に接続するための通信デバイスなどで構成された通信インターフェースである。通信装置９２５は、例えば、有線または無線ＬＡＮ（Local Area Network）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、またはＷＵＳＢ（Wireless USB）用の通信カードなどでありうる。また、通信装置９２５は、光通信用のルータ、ＡＤＳＬ（Asymmetric Digital Subscriber Line）用のルータ、または、各種通信用のモデムなどであってもよい。通信装置９２５は、例えば、インターネットや他の通信機器との間で、ＴＣＰ／ＩＰなどの所定のプロトコルを用いて信号などを送受信する。また、通信装置９２５に接続される通信ネットワーク９３１は、有線または無線によって接続されたネットワークであり、例えば、インターネット、家庭内ＬＡＮ、赤外線通信、ラジオ波通信または衛星通信などである。

撮像装置９３３は、例えば、ＣＣＤ（Charge Coupled Device）またはＣＭＯＳ（Complementary Metal Oxide Semiconductor）などの撮像素子、および撮像素子への被写体像の結像を制御するためのレンズなどの各種の部材を用いて実空間を撮像し、撮像画像を生成する装置である。撮像装置９３３は、静止画を撮像するものであってもよいし、また動画を撮像するものであってもよい。

センサ９３５は、例えば、加速度センサ、ジャイロセンサ、地磁気センサ、光センサ、音センサなどの各種のセンサである。センサ９３５は、例えば情報処理装置９００の筐体の姿勢など、情報処理装置９００自体の状態に関する情報や、情報処理装置９００の周辺の明るさや騒音など、情報処理装置９００の周辺環境に関する情報を取得する。また、センサ９３５は、ＧＰＳ（Global Positioning System）信号を受信して装置の緯度、経度および高度を測定するＧＰＳセンサを含んでもよい。

以上、情報処理装置９００のハードウェア構成の一例を示した。上記の各構成要素は、汎用的な部材を用いて構成されていてもよいし、各構成要素の機能に特化したハードウェアにより構成されていてもよい。かかる構成は、実施する時々の技術レベルに応じて適宜変更されうる。

（１０．補足）
本開示の実施形態は、例えば、上記で説明したような情報処理装置（サーバ装置またはクライアント装置）、システム、情報処理装置またはシステムで実行される情報処理方法、情報処理装置を機能させるためのプログラム、およびプログラムが記録された一時的でない有形の媒体を含みうる。なお、上記で説明された複数の実施形態は、特に組み合わせが可能であることが明示されていなくても、本明細書の記載から当業者に自明な範囲で任意に組み合わせて実現することができる。

以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。

なお、以下のような構成も本開示の技術的範囲に属する。
（１）クライアントからのリクエストに応じて、リソースへの参照を含むドキュメントを取得するドキュメント取得部と、
前記リソースを取得するリソース取得部と、
前記ドキュメントおよび前記リソースのそれぞれに含まれる文字列について短縮された文字列を生成するとともに、前記文字列と前記短縮された文字列とを関連付けるレコードを追加する短縮文字列生成部と、
前記ドキュメントおよび前記リソースにおいて、前記文字列を前記短縮された文字列に置換する短縮文字列記述部と、
前記短縮された文字列を含む前記ドキュメントを前記クライアントに送信するドキュメント送信部と、
前記短縮された文字列を含む前記リソースを前記クライアントに送信するリソース送信部と
を備えるサーバ装置。
（２）前記レコードに基づいて生成された前記文字列と前記短縮された文字列との関連付け情報を前記クライアントに送信する関連付け情報送信部をさらに備える、前記（１）に記載のサーバ装置。
（３）前記関連付け情報は、前記レコードの少なくとも一部を含まない、前記（２）に記載のサーバ装置。
（４）前記レコードには前記ドキュメントまたは前記リソースにおける予約語に関する情報が含まれ、前記関連付け情報には前記予約語に関する情報が含まれない、前記（３）に記載のサーバ装置。
（５）前記短縮文字列記述部は、前記ドキュメントに含まれる文字列を前記短縮された文字列に置換した後に、前記ドキュメントについて生成されたレコードに従って前記リソースに含まれる文字列を前記短縮された文字列に置換する、前記（１）〜（４）のいずれか１項に記載のサーバ装置。
（６）前記短縮文字列記述部は、前記ドキュメントが前記クライアントに送信された後に、前記リソースに含まれる文字列を前記短縮された文字列に置換する、前記（５）に記載のサーバ装置。
（７）前記短縮文字列生成部は、前記文字列に基づいて所定の演算を実行することによって前記短縮された文字列を生成する、前記（１）〜（６）のいずれか１項に記載のサーバ装置。
（８）サーバにリクエストを送信するリクエスト送信部と、
前記リクエストに応じて前記サーバから送信された、リソースへの参照を含むドキュメントを受信するドキュメント受信部と、
前記リソースを受信するリソース受信部と、
前記ドキュメントおよび前記リソースに含まれる短縮された文字列と、前記短縮された文字列に対応する文字列との関連付け情報を受信する関連付け情報受信部と、
前記関連付け情報に従って前記ドキュメントおよび前記リソースを解釈する文字列解釈部と
を備えるクライアント装置。
（９）前記リソース受信部は、前記ドキュメントおよび前記関連付け情報が受信された後に前記リソースを受信する、前記（８）に記載のクライアント装置。
（１０）前記文字列解釈部は、前記短縮された文字列の一部を、前記関連付け情報によらずに解釈する、前記（８）または（９）に記載のクライアント装置。
（１１）前記短縮された文字列の一部は、前記ドキュメントまたは前記リソースにおける予約語として解釈される、前記（１０）に記載のクライアント装置。
（１２）クライアントからのリクエストに応じて、リソースへの参照を含むドキュメントを取得することと、
前記リソースを取得することと、
前記ドキュメントおよび前記リソースのそれぞれに含まれる文字列について短縮された文字列を生成するとともに、前記文字列と前記短縮された文字列とを関連付けるレコードを追加することと、
前記ドキュメントおよび前記リソースにおいて、前記文字列を前記短縮された文字列に置換することと、
前記短縮された文字列を含む前記ドキュメントを前記クライアントに送信することと、
前記短縮された文字列を含む前記リソースを前記クライアントに送信することと
を含む情報処理方法。
（１３）サーバにリクエストを送信する機能と、
前記リクエストに応じて前記サーバから送信された、リソースへの参照を含むドキュメントを受信する機能と、
前記リソースを受信する機能と、
前記ドキュメントおよび前記リソースに含まれる短縮された文字列と、前記短縮された文字列に対応する文字列との関連付け情報を受信する機能と、
前記関連付け情報に従って前記ドキュメントおよび前記リソースを解釈する機能と
をコンピュータに実現させるためのプログラムが記録された一時的でない有形の記録媒体。

１０ システム
１００ 配信サーバ
２００ 中間サーバ
２０２ リクエスト受信部
２０４ ドキュメント取得部
２０６ ドキュメント解析部
２０８ リソース取得部
２１０ 識別子生成部
２１２ 識別子記述部
２１４ ドキュメント送信部
２１６ リソース送信部
２１８ リソース先行配信部
２２０ リソース解析部
２２２ 短縮文字列生成部
２２４ 短縮文字列記述部
２２６ 関連付け情報送信部
２２８ 画像トランスコード部
２３０ 画像参照更新部
２８０ キャッシュ
２８２ データベース
３００ クライアント
３０２ リクエスト送信部
３０４ ドキュメント受信部
３０６ キャッシュ判定部
３０８ リソース受信部
３１０ 表示制御部
３１２ リソース先行受信部
３１４ 関連付け情報受信部
３１６ 文字列解釈部
３８０ キャッシュ
３８２ データベース

Claims (13)

1. クライアントからのリクエストに応じて、リソースへの参照を含むドキュメントを取得するドキュメント取得部と、
   前記リソースを取得するリソース取得部と、
   前記ドキュメントおよび前記リソースのそれぞれに含まれる文字列について短縮された文字列を生成するとともに、前記文字列と前記短縮された文字列とを関連付けるレコードを追加する短縮文字列生成部と、
   前記ドキュメントおよび前記リソースにおいて、前記文字列を前記短縮された文字列に置換する短縮文字列記述部と、
   前記短縮された文字列を含む前記ドキュメントを前記クライアントに送信するドキュメント送信部と、
   前記短縮された文字列を含む前記リソースを前記クライアントに送信するリソース送信部と
   を備えるサーバ装置。
2. 前記レコードに基づいて生成された前記文字列と前記短縮された文字列との関連付け情報を前記クライアントに送信する関連付け情報送信部をさらに備える、請求項１に記載のサーバ装置。
3. 前記関連付け情報は、前記レコードの少なくとも一部を含まない、請求項２に記載のサーバ装置。
4. 前記レコードには前記ドキュメントまたは前記リソースにおける予約語に関する情報が含まれ、前記関連付け情報には前記予約語に関する情報が含まれない、請求項３に記載のサーバ装置。
5. 前記短縮文字列記述部は、前記ドキュメントに含まれる文字列を前記短縮された文字列に置換した後に、前記ドキュメントについて生成されたレコードに従って前記リソースに含まれる文字列を前記短縮された文字列に置換する、請求項１〜４のいずれか１項に記載のサーバ装置。
6. 前記短縮文字列記述部は、前記ドキュメントが前記クライアントに送信された後に、前記リソースに含まれる文字列を前記短縮された文字列に置換する、請求項５に記載のサーバ装置。
7. 前記短縮文字列生成部は、前記文字列に基づいて所定の演算を実行することによって前記短縮された文字列を生成する、請求項１〜６のいずれか１項に記載のサーバ装置。
8. サーバにリクエストを送信するリクエスト送信部と、
   前記リクエストに応じて前記サーバから送信された、リソースへの参照を含むドキュメントを受信するドキュメント受信部と、
   前記リソースを受信するリソース受信部と、
   前記ドキュメントおよび前記リソースに含まれる短縮された文字列と、前記短縮された文字列に対応する文字列との関連付け情報を受信する関連付け情報受信部と、
   前記関連付け情報に従って前記ドキュメントおよび前記リソースを解釈する文字列解釈部と
   を備えるクライアント装置。
9. 前記リソース受信部は、前記ドキュメントおよび前記関連付け情報が受信された後に前記リソースを受信する、請求項８に記載のクライアント装置。
10. 前記文字列解釈部は、前記短縮された文字列の一部を、前記関連付け情報によらずに解釈する、請求項８または９に記載のクライアント装置。
11. 前記短縮された文字列の一部は、前記ドキュメントまたは前記リソースにおける予約語として解釈される、請求項１０に記載のクライアント装置。
12. クライアントからのリクエストに応じて、リソースへの参照を含むドキュメントを取得することと、
    前記リソースを取得することと、
    前記ドキュメントおよび前記リソースのそれぞれに含まれる文字列について短縮された文字列を生成するとともに、前記文字列と前記短縮された文字列とを関連付けるレコードを追加することと、
    前記ドキュメントおよび前記リソースにおいて、前記文字列を前記短縮された文字列に置換することと、
    前記短縮された文字列を含む前記ドキュメントを前記クライアントに送信することと、
    前記短縮された文字列を含む前記リソースを前記クライアントに送信することと
    を含む情報処理方法。
13. サーバにリクエストを送信する機能と、
    前記リクエストに応じて前記サーバから送信された、リソースへの参照を含むドキュメントを受信する機能と、
    前記リソースを受信する機能と、
    前記ドキュメントおよび前記リソースに含まれる短縮された文字列と、前記短縮された文字列に対応する文字列との関連付け情報を受信する機能と、
    前記関連付け情報に従って前記ドキュメントおよび前記リソースを解釈する機能と
    をコンピュータに実現させるためのプログラムが記録された一時的でない有形の記録媒体。

Images