JPWO2015052967A1 - サーバ装置、クライアント装置、情報処理方法および記録媒体 - Google Patents
サーバ装置、クライアント装置、情報処理方法および記録媒体 Download PDFInfo
- Publication number
- JPWO2015052967A1 JPWO2015052967A1 JP2015541455A JP2015541455A JPWO2015052967A1 JP WO2015052967 A1 JPWO2015052967 A1 JP WO2015052967A1 JP 2015541455 A JP2015541455 A JP 2015541455A JP 2015541455 A JP2015541455 A JP 2015541455A JP WO2015052967 A1 JPWO2015052967 A1 JP WO2015052967A1
- Authority
- JP
- Japan
- Prior art keywords
- resource
- character string
- document
- client
- shortened
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/10—Text processing
- G06F40/12—Use of codes for handling textual entities
- G06F40/14—Tree-structured documents
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/10—Text processing
- G06F40/12—Use of codes for handling textual entities
- G06F40/131—Fragmentation of text files, e.g. creating reusable text-blocks; Linking to fragments, e.g. using XInclude; Namespaces
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/10—Text processing
- G06F40/166—Editing, e.g. inserting or deleting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
- G06F16/9566—URL specific, e.g. using aliases, detecting broken or misspelled links
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/10—Text processing
- G06F40/12—Use of codes for handling textual entities
- G06F40/134—Hyperlinking
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Audiology, Speech & Language Pathology (AREA)
- General Health & Medical Sciences (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computational Linguistics (AREA)
- Health & Medical Sciences (AREA)
- Artificial Intelligence (AREA)
- Information Transfer Between Computers (AREA)
- Document Processing Apparatus (AREA)
- Facsimiles In General (AREA)
Abstract
【課題】クライアントからのリクエストに応じてサーバがドキュメントを提供するシステムにおいて、サーバの処理能力を活用することによってクライアントへのドキュメントの提供を高速化する。【解決手段】クライアントからのリクエストに応じて、リソースへの参照を含むドキュメントを取得するドキュメント取得部と、リソースを取得するリソース取得部と、ドキュメントおよびリソースのそれぞれに含まれる文字列について短縮された文字列を生成するとともに、文字列と短縮された文字列とを関連付けるレコードを追加する短縮文字列生成部と、ドキュメントおよびリソースにおいて、文字列を短縮された文字列に置換する短縮文字列記述部と、短縮された文字列を含むドキュメントをクライアントに送信するドキュメント送信部と、短縮された文字列を含むリソースをクライアントに送信するリソース送信部とを含むサーバ装置が提供される。【選択図】図10A
Description
本開示は、サーバ装置、クライアント装置、情報処理方法および記録媒体に関する。
クライアントからのリクエストに応じてサーバがドキュメントを提供するシステムは、例えばHTML(Hyper Text Markup Language)ドキュメントを提供するWWW(World Wide Web)のように、今日広く普及している。こうしたシステムにおいて、ドキュメントをクライアントに提供するための所要時間、より具体的にはクライアントがリクエストを送信してからドキュメントがクライアントで表示されるまでの時間を短縮することは、長年取り組まれてきた課題である。例えば、特許文献1には、メモリリソースやウェブサービスへのアクセスが制限されている場合でもキャッシュを効率よく利用するために、ウェブサーバにおいてコンテンツをキャッシュする技術が記載されている。
しかしながら、例えばHTMLにおける画像/動画やスクリプトなどのように、様々なリソースを参照するリッチなドキュメントが増加する傾向にあり、上記のような高速化技術のさらなる進歩が求められている。また、サーバやクライアントの処理能力を向上させることも高速化に寄与するが、例えばクライアントがモバイル装置であるような場合には、処理能力の向上は必ずしも容易ではない。
そこで、本開示では、クライアントからのリクエストに応じてサーバがドキュメントを提供するシステムにおいて、サーバの処理能力を活用することによってクライアントへのドキュメントの提供を高速化することを可能にする、新規かつ改良されたサーバ装置、クライアント装置、情報処理方法および記録媒体を提案する。
本開示によれば、クライアントからのリクエストに応じて、リソースへの参照を含むドキュメントを取得するドキュメント取得部と、上記リソースを取得するリソース取得部と、上記ドキュメントおよび上記リソースのそれぞれに含まれる文字列について短縮された文字列を生成するとともに、上記文字列と上記短縮された文字列とを関連付けるレコードを追加する短縮文字列生成部と、上記ドキュメントおよび上記リソースにおいて、上記文字列を上記短縮された文字列に置換する短縮文字列記述部と、上記短縮された文字列を含む上記ドキュメントを上記クライアントに送信するドキュメント送信部と、上記短縮された文字列を含む上記リソースを上記クライアントに送信するリソース送信部とを含むサーバ装置が提供される。
また、本開示によれば、サーバにリクエストを送信するリクエスト送信部と、上記リクエストに応じて上記サーバから送信された、リソースへの参照を含むドキュメントを受信するドキュメント受信部と、上記リソースを受信するリソース受信部と、上記ドキュメントおよび上記リソースに含まれる短縮された文字列と、上記短縮された文字列に対応する文字列との関連付け情報を受信する関連付け情報受信部と、上記関連付け情報に従って上記ドキュメントおよび上記リソースを解釈する文字列解釈部とを含むクライアント装置が提供される。
また、本開示によれば、クライアントからのリクエストに応じて、リソースへの参照を含むドキュメントを取得することと、上記リソースを取得することと、上記ドキュメントおよび上記リソースのそれぞれに含まれる文字列について短縮された文字列を生成するとともに、上記文字列と上記短縮された文字列とを関連付けるレコードを追加することと、上記ドキュメントおよび上記リソースにおいて、上記文字列を上記短縮された文字列に置換することと、上記短縮された文字列を含む上記ドキュメントを上記クライアントに送信することと、上記短縮された文字列を含む上記リソースを上記クライアントに送信することとを含む情報処理方法が提供される。
また、本開示によれば、サーバにリクエストを送信する機能と、上記リクエストに応じて上記サーバから送信された、リソースへの参照を含むドキュメントを受信する機能と、上記リソースを受信する機能と、上記ドキュメントおよび上記リソースに含まれる短縮された文字列と、上記短縮された文字列に対応する文字列との関連付け情報を受信する機能と、上記関連付け情報に従って上記ドキュメントおよび上記リソースを解釈する機能とをコンピュータに実現させるためのプログラムが記録された一時的でない有形の記録媒体が提供される。
以上説明したように本開示によれば、クライアントからのリクエストに応じてサーバがドキュメントを提供するシステムにおいて、サーバの処理能力を活用することによってクライアントへのドキュメントの提供を高速化することができる。
以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書および図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
なお、説明は以下の順序で行うものとする。
1.システム構成
2.第1の実施形態
2−1.機能構成
2−2.処理フロー
2−3.変形例
3.第2の実施形態
3−1.機能構成
3−2.処理フロー
4.第3の実施形態
4−1.機能構成
4−2.処理フロー
4−3.変形例
5.第4の実施形態
5−1.機能構成
5−2.処理フロー
6.第5の実施形態
7.第6の実施形態
8.第7の実施形態
8−1.機能構成
8−2.処理フロー
8−3.トランスコードの例
8−4.フォーマットの例
8−5.デコード処理の例
9.ハードウェア構成
10.補足
1.システム構成
2.第1の実施形態
2−1.機能構成
2−2.処理フロー
2−3.変形例
3.第2の実施形態
3−1.機能構成
3−2.処理フロー
4.第3の実施形態
4−1.機能構成
4−2.処理フロー
4−3.変形例
5.第4の実施形態
5−1.機能構成
5−2.処理フロー
6.第5の実施形態
7.第6の実施形態
8.第7の実施形態
8−1.機能構成
8−2.処理フロー
8−3.トランスコードの例
8−4.フォーマットの例
8−5.デコード処理の例
9.ハードウェア構成
10.補足
(1.システム構成)
図1は、本開示のいくつかの実施形態が適用されるシステムの概略的な構成を示す図である。図1を参照すると、システム10は、配信元サーバ100と、中間サーバ200と、クライアント300とを含む。配信元サーバ100、中間サーバ200、およびクライアント300は、例えばインターネットなどのネットワークによって相互に接続されている。
図1は、本開示のいくつかの実施形態が適用されるシステムの概略的な構成を示す図である。図1を参照すると、システム10は、配信元サーバ100と、中間サーバ200と、クライアント300とを含む。配信元サーバ100、中間サーバ200、およびクライアント300は、例えばインターネットなどのネットワークによって相互に接続されている。
配信元サーバ100および中間サーバ200は、いずれも1または複数のサーバ装置によって実現されるサーバである。配信元サーバ100は、ユーザに提供されるドキュメントと、ドキュメントが参照するリソースとを保持している。ドキュメントおよびリソースは、クライアント300からのリクエストに応じて、配信元サーバ100から1または複数の中間サーバ200を経由して、クライアント300に配信される。例えば、中間サーバ200がドキュメントやリソースをキャッシュとして保持し、キャッシュされているドキュメントやリソースを配信元サーバ100に代わってクライアント300に配信することによって、クライアント300に迅速にドキュメントを提供することができる。
また、ドキュメントやリソースの一部は、クライアント300でもキャッシュとして保持されている。ドキュメントやリソースがクライアント300で保持されている場合、ネットワークを介したデータの送受信をしなくてもよいため、ドキュメントはより迅速に表示される。ただし、クライアント300で保持することが可能なキャッシュの量には限界があるため、より多くのキャッシュを保持することが可能な中間サーバ200を設けることには利点がある。中間サーバ200は、例えば後述する実施形態のように、キャッシュの保持に限らず、高速化のための様々な処理を実行しうる。中間サーバ200のうち、最もクライアント300に近いサーバ(エッジサーバ)とクライアント300との間の通信は、例えばHTTPoverUDP、SPDY(overUDP)、またはHTTP/2.0(overUDP)のような所定のプロトコルに統一されていてもよい。
なお、配信元サーバ100および中間サーバ200を実現する1または複数のサーバ装置は、CPU(Central Processing unit)などのプロセッサを備えた情報処理装置でありうる。また、クライアント300もプロセッサを備えた情報処理装置によって実現されうる。クライアント300には、ディスプレイやスピーカなどの出力装置や、タッチパネルなどの入力装置、および撮像装置などがさらに備えられてもよい。より具体的には、例えば、クライアント300は、スマートフォン、パーソナルコンピュータ、タブレット、メディアプレーヤ、テレビ、ゲーム機などといった装置でありうる。上記の各装置を実現しうる情報処理装置の具体的なハードウェア構成については、後段でさらに詳細に説明する。
システム10は、例えばHTMLのようなマークアップ言語で記述されたドキュメントの配信に利用されうる。この場合、リソースは、例えばJavaScriptのようなスクリプトや、CSS(Cascading Style Sheets)のようなスタイル定義情報、画像および動画などでありうる。なお、システム10は、マークアップ言語で記述されたものに限らず、各種のドキュメント、またはドキュメント以外のデータ(画像もしくは動画などを含む)の配信に利用されうる。
(2.第1の実施形態)
(2−1.機能構成)
図2は、本開示の第1の実施形態に係る中間サーバおよびクライアントの概略的な機能構成を示すブロック図である。図2を参照すると、中間サーバ200は、機能構成として、リクエスト受信部202と、ドキュメント取得部204と、ドキュメント解析部206と、リソース取得部208と、識別子生成部210と、識別子記述部212と、ドキュメント送信部214と、リソース送信部216とを含む。クライアント300は、機能構成として、リクエスト送信部302と、ドキュメント受信部304と、キャッシュ判定部306と、リソース受信部308と、表示制御部310とを含む。
(2−1.機能構成)
図2は、本開示の第1の実施形態に係る中間サーバおよびクライアントの概略的な機能構成を示すブロック図である。図2を参照すると、中間サーバ200は、機能構成として、リクエスト受信部202と、ドキュメント取得部204と、ドキュメント解析部206と、リソース取得部208と、識別子生成部210と、識別子記述部212と、ドキュメント送信部214と、リソース送信部216とを含む。クライアント300は、機能構成として、リクエスト送信部302と、ドキュメント受信部304と、キャッシュ判定部306と、リソース受信部308と、表示制御部310とを含む。
これらの機能構成は、例えば、中間サーバ200およびクライアント300をそれぞれ実現する情報処理装置に備えられるプロセッサが、メモリまたは記録媒体に格納されたプログラムに従って動作することによって実現されうる。また、中間サーバ200におけるキャッシュ280、およびクライアント300におけるキャッシュ380は、例えば、それぞれの情報処理装置のストレージまたはメモリによって実現されうる。
(中間サーバ)
中間サーバ200では、リクエスト受信部202がクライアント300からのリクエストを受信する。リクエストが受信されると、ドキュメント取得部204が、リクエストに応じて、リクエストにおいて指定されたドキュメントを取得する。このとき、ドキュメント取得部204は、キャッシュ280に格納されたドキュメントを内部的に取得してもよい。指定されたドキュメントがキャッシュ280に格納されていない場合、ドキュメント取得部204は配信元サーバ100にリクエストを送信し、リクエストに応じて配信元サーバ100から送信されたドキュメントを取得する。
中間サーバ200では、リクエスト受信部202がクライアント300からのリクエストを受信する。リクエストが受信されると、ドキュメント取得部204が、リクエストに応じて、リクエストにおいて指定されたドキュメントを取得する。このとき、ドキュメント取得部204は、キャッシュ280に格納されたドキュメントを内部的に取得してもよい。指定されたドキュメントがキャッシュ280に格納されていない場合、ドキュメント取得部204は配信元サーバ100にリクエストを送信し、リクエストに応じて配信元サーバ100から送信されたドキュメントを取得する。
ドキュメント解析部206は、ドキュメント取得部204が取得したドキュメントを解析する。より具体的には、ドキュメント解析部206は、ドキュメントに含まれるリソースへの参照を検出する。ドキュメント解析部206によってリソースへの参照が検出された場合、リソース取得部208が、参照されているリソースを取得する。このとき、リソース取得部208は、キャッシュ280に格納されたリソースを内部的に取得してもよい。参照されているリソースがキャッシュ280に格納されていない場合、リソース取得部208は配信元サーバ100にリクエストを送信し、リクエストに応じて配信元サーバ100から送信されたリソースを取得する。配信元サーバ100から新たに取得されたリソースは、キャッシュ280に格納される。
識別子生成部210は、リソース取得部208によって取得されたリソースについて、リソースの内容ごとに一意な識別子を生成する。例えば、識別子生成部210は、リソースの内容に基づいて所定のアルゴリズムでハッシュを算出してもよい。この場合、算出されたハッシュは、リソースの内容ごとに一意な識別子になりうる。なお、識別子生成部210は、必ずしもハッシュをそのまま識別子として利用しなくてもよく、ハッシュに基づいてリソースを同定した上で、別途識別子を生成してリソースに付与してもよい。識別子生成部210は、生成した識別子をキャッシュ280に格納されているリソースに関連付けてもよい。
より具体的には、例えば、識別子生成部210は、リソースを種類に関わらずバイナリデータとみなし、ハッシュ関数を利用して一意な識別子を生成する。ハッシュ関数としては、例えばMD5、SHA−1、またはSHA−256などを利用してもよい。さらに、識別子生成部210は、1つのリソースについて、複数のハッシュ関数を利用して複数の識別子を生成してもよい。これらの識別子がすべて一致した場合にリソースを同一と判定することで、識別子の一意性をより高めることができる。
後述するように、識別子生成部210が生成するリソースの内容ごとに一意な識別子によって、クライアント300におけるドキュメントの表示を高速化させることができる。上記のハッシュ関数による識別子の生成の例のように、識別子生成部210による一意な識別子の生成にもある程度の時間はかかるが、一般に中間サーバ200の処理能力はクライアント300よりも高く、また後述する変形例のように識別子の生成と並行してクライアント300でドキュメントの表示を開始することも可能であるため、結果としてドキュメントの表示の高速化が達成される。
識別子記述部212は、識別子生成部210によって生成された識別子を、ドキュメントにおけるリソースへの参照に関連付ける。より具体的には、例えば、識別子記述部212は、識別子生成部210が生成した識別子を、オリジナルの識別子に追加してリソースへの参照に関連付ける。例えば、HTMLドキュメントは、URL(Uniform Resource Locator)をオリジナルの識別子とするリソースへの参照を含む。この場合、識別子記述部212は、オリジナルの識別子であるURLを残しつつ、識別子生成部210によって生成された識別子、例えばハッシュを追加的にドキュメントに記述してもよい。
一例として、HTMLドキュメントに下記の(a)に示すようなURLを含む画像のリソースへの参照が含まれていた場合、識別子記述部212は、(b)に示すように、識別子生成部210によって生成された識別子であるハッシュ(new_id)を追加的にドキュメントに記述してもよい。
(a)<img src=“resource/image001.jpg”/>
(b)<img src=“resource/image001.jpg” new_id=“736f6e7920706174656e74”/>
(a)<img src=“resource/image001.jpg”/>
(b)<img src=“resource/image001.jpg” new_id=“736f6e7920706174656e74”/>
後述するように、クライアント300は、ドキュメントの参照に際して、識別子記述部212によって追加的に記述された識別子に基づいてリソースのキャッシュの有無を判断し、キャッシュがない場合には中間サーバ200にリソースをリクエストするように構成されている。しかし、ネットワーク上には、クライアント300以外のクライアント、つまり追加的に記述された識別子を参照しないクライアントも存在しうる。識別子記述部212がオリジナルの識別子を残しておくことによって、そのようなクライアントとの間で下位互換性を確保することができる。
あるいは、識別子記述部212は、識別子生成部210が生成した識別子によって、ドキュメントにおけるリソースへの参照に含まれるオリジナルの識別子を上書きしてもよい。この場合、例えば、上記の(a)に示すようなリソースへの参照は、下記の(c)に示すように書き換えられうる。
(c)<img src=“http://www.xxx.yyy/zzz/736f6e7920706174656e74”/>
(c)<img src=“http://www.xxx.yyy/zzz/736f6e7920706174656e74”/>
この例において、識別子記述部212は、URLを、中間サーバ200を示す絶対パスに書き換えるとともに、絶対パスに続けて識別子生成部210が生成した識別子を記述している。中間サーバ200を示す絶対パスは、すべてのリソースで共通して付加される。従って、クライアント300が上記の例のように書き換えられたオリジナルの識別子に基づいてキャッシュの有無を判断することは、実質的に識別子生成部210が生成した識別子に基づいて判断しているのと同じことになる。この場合、クライアントは、追加的に記述された識別子を参照するように構成されていなくてもよい。
ドキュメント送信部214は、識別子生成部210によって生成された識別子を含むドキュメントをクライアント300に送信する。後述するように、クライアント300は、識別子生成部210によって生成された識別子に基づいてリソースを参照しながらドキュメントを表示させる。リソース送信部216は、ドキュメントで参照されるリソースがクライアント300でキャッシュされていなかった場合にクライアント300から送信されるリソースのリクエストに応じて、キャッシュ280に格納されたリソースをクライアント300に送信する。
(クライアント)
クライアント300では、リクエスト送信部302が、例えばユーザ操作に基づいて中間サーバ200にリクエストを送信する。ドキュメント受信部304は、中間サーバ200がリクエストに応じて送信したドキュメントを受信する。上述の通り、受信されるドキュメントにはリソースへの参照が含まれ、リソースへの参照には中間サーバ200の識別子生成部210によって生成されたリソースの内容ごとに一意な識別子が関連付けられている。上述の通り、ドキュメントにおいて、一意な識別子は、オリジナルの識別子に追加してリソースへの参照に関連付けられていてもよい。
クライアント300では、リクエスト送信部302が、例えばユーザ操作に基づいて中間サーバ200にリクエストを送信する。ドキュメント受信部304は、中間サーバ200がリクエストに応じて送信したドキュメントを受信する。上述の通り、受信されるドキュメントにはリソースへの参照が含まれ、リソースへの参照には中間サーバ200の識別子生成部210によって生成されたリソースの内容ごとに一意な識別子が関連付けられている。上述の通り、ドキュメントにおいて、一意な識別子は、オリジナルの識別子に追加してリソースへの参照に関連付けられていてもよい。
キャッシュ判定部306は、ドキュメント受信部304が受信したドキュメントにおいて参照されているリソースが、キャッシュ380に格納されているか否かを判定する。このとき、キャッシュ判定部306は、リソースの内容ごとに一意な識別子に基づいて、リソースがキャッシュ380に格納されているか否かを判定する。リソースがキャッシュ380に格納されている場合、キャッシュ判定部306は格納されたリソースを読み出して表示制御部310に提供する。一方、リソースがキャッシュ380に格納されていなかった場合、キャッシュ判定部306は、中間サーバ200に当該リソースのリクエストを送信することをリソース受信部308に依頼する。
ここで、もし、キャッシュ判定部が判定に用いる識別子が、例えばURLのようなものであった場合、識別子は必ずしもリソースの内容ごとに一意ではない。それゆえ、リソースの内容が同一であっても、異なるリソースが参照されていると判定される場合がある。例えば、第1の配信元サーバ100aから配信される第1のドキュメントによって参照される第1のリソースと、第2の配信元サーバ100bから配信される第2のドキュメントによって参照される第2のリソースとがあるとする。この場合、第1のリソースと第2のリソースとの内容が同一であっても、第1の配信元サーバ100aを示すURLと第2の配信元サーバ100bを示すURLとが異なるために、第1のリソースおよび第2のリソースへの参照にそれぞれ用いられる識別子(URL)は異なる。従って、キャッシュ判定部は、受信された第2のドキュメントで第2のリソースが参照されているような場合、同じ内容の第1のリソースが既にキャッシュに格納されていても、第2のリソースそのものがキャッシュに格納されていなければ、参照されているリソースがキャッシュに格納されていないと判定しうる。
これに対して、本実施形態に係るクライアント300のキャッシュ判定部306は、リソースの内容ごとに一意な識別子に基づいて、リソースがキャッシュ380に格納されているか否かを判定する。この場合、上記の例でいえば、中間サーバ200の識別子生成部210が、第1のリソースと第2のリソースとについて共通する識別子を生成し、キャッシュ判定部306は、この共通の識別子に基づいてリソースがキャッシュ380に格納されているか否かを判定する。従って、受信された第2のドキュメントで第2のリソースが参照されている場合、同じ内容の第1のリソースが既にキャッシュ380に格納されていれば、キャッシュ判定部306は、参照されているリソースがキャッシュ380に格納されていると判定し、中間サーバ200にリクエストを送信することなく、キャッシュ380に格納されたリソースを再利用して表示制御部310に提供することができる。
リソース受信部308は、中間サーバ200にリソースのリクエストを送信し、リクエストに応じて中間サーバ200から送信されたリソースを受信する。リソース受信部308は、受信されたリソースを表示制御部310に提供する。また、リソース受信部308は、新たに受信されたリソースをキャッシュ380に格納する。
表示制御部310は、ドキュメント受信部304が受信したドキュメントと、ドキュメントにおいて参照されているリソースとに基づいて、クライアント300のディスプレイにドキュメントを表示させる。上述のように、リソースは、キャッシュ判定部306の判定に応じて、キャッシュ380から読み出されて再利用されるか、中間サーバ200から新たに受信される。中間サーバ200からの受信には通信のための時間がかかるため、再利用されるリソースの割合が高いほど、ドキュメントの表示は高速化されることになる。
本実施形態では、キャッシュ判定部306が、リソースの内容ごとに一意な識別子に基づいて、リソースがキャッシュ380に格納されているか否かを判定する。それゆえ、例えば同じ配信元サーバ100から配信されたドキュメントで参照されるリソースのみならず、相異なる配信元サーバ100から配信された複数のドキュメントでそれぞれ参照されるリソースであっても、内容が同一であれば再利用することができる。従って、ドキュメントの表示にあたって再利用されるリソースの割合が増加し、ドキュメントの表示が高速化されうる。
(2−2.処理フロー)
(中間サーバの処理フロー)
図3は、本開示の第1の実施形態に係る中間サーバの処理を示すフローチャートである。図3を参照すると、まず、リクエスト受信部202が、クライアント300からのリクエストを受信する(S101)。次に、ドキュメント取得部204が、リクエストにおいて指定されたドキュメントを取得する(S103)。次に、ドキュメント解析部206が、取得されたドキュメントを解析する(S105)。
(中間サーバの処理フロー)
図3は、本開示の第1の実施形態に係る中間サーバの処理を示すフローチャートである。図3を参照すると、まず、リクエスト受信部202が、クライアント300からのリクエストを受信する(S101)。次に、ドキュメント取得部204が、リクエストにおいて指定されたドキュメントを取得する(S103)。次に、ドキュメント解析部206が、取得されたドキュメントを解析する(S105)。
ここで、ドキュメントの解析においてリソースへの参照が検出された場合(S107のYES)、リソース取得部208が、参照されているリソースを取得する(S109)。さらに、識別子生成部210が、取得されたリソースの内容に基づいて一意な識別子を生成する(S111)。次に、識別子記述部212が、生成された一意な識別子を、ドキュメントにおけるリソースへの参照に関連付ける(S113)。S109〜S113は、ドキュメントにおけるリソースへの参照がすべて検出されるまで繰り返し実行されうる。
ドキュメントの解析においてリソースへの参照が検出されなくなった場合、または検出されなかった場合(S107のNO)、ドキュメント送信部214が、ドキュメントをクライアント300に送信する(S115)。その後、クライアント300からリソースのリクエストが受信された場合(S117のYES)、リソース送信部216がクライアント300にリソースを送信する(S119)。リソースのリクエストが受信されなくなった場合、または受信されなかった場合(S117のNO)、中間サーバ200での処理は終了する。
(クライアントの処理フロー)
図4は、本開示の第1の実施形態に係るクライアントの処理を示すフローチャートである。図4を参照すると、まず、リクエスト送信部302が、中間サーバ200にリクエストを送信する(S131)。次に、ドキュメント受信部304が、中間サーバ200がリクエストに応じて送信したドキュメントを受信する(S133)。ここで、表示制御部310は、受信されたドキュメントの表示を開始する(S135)。
図4は、本開示の第1の実施形態に係るクライアントの処理を示すフローチャートである。図4を参照すると、まず、リクエスト送信部302が、中間サーバ200にリクエストを送信する(S131)。次に、ドキュメント受信部304が、中間サーバ200がリクエストに応じて送信したドキュメントを受信する(S133)。ここで、表示制御部310は、受信されたドキュメントの表示を開始する(S135)。
ドキュメントにおいてリソースへの参照が発見された場合(S137のYES)、キャッシュ判定部306が、参照されているリソースがキャッシュ380に格納されているか(キャッシュされているか)否かを判定する(S139)。上述のように、キャッシュ判定部306は、ドキュメントにおけるリソースへの参照に関連付けられた、リソースの内容ごとに一意な識別子に基づいて、リソースがキャッシュ380に格納されているか否かを判定する。
ここで、リソースがキャッシュ380に格納されていると判定された場合(S139のYES)、キャッシュ判定部306はキャッシュ380からリソースを読み出して表示制御部310に提供する。つまり、キャッシュ判定部306および表示制御部310はキャッシュされたリソースを再利用する(S141)。一方、リソースがキャッシュ380に格納されていないと判定された場合(S139のNO)、リソース受信部308が中間サーバ200にリソースのリクエストを送信する(S143)。リソース受信部308は、リクエストに応じて中間サーバ200が送信したリソースを受信する(S145)。
表示制御部310は、再利用されたリソース、または中間サーバ200から受信されたリソースを参照して、ドキュメントの表示を継続する(S147)。S139〜S147は、ドキュメントにおけるリソースへの参照がすべて発見されるまで繰り返し実行されうる。表示制御部310がドキュメントの全体を表示させ、リソースへの参照も発見されなくなった場合、またはリソースへの参照が発見されなかった場合(S137のNO)、クライアント300はドキュメントの表示を完了する(S149)。
(2−3.変形例)
(中間サーバの処理フロー)
図5は、本開示の第1の実施形態の変形例に係る中間サーバの処理を示すフローチャートである。図5を参照すると、まず、上記で図3を参照して説明した例と同様にS101〜S105が実行される。
(中間サーバの処理フロー)
図5は、本開示の第1の実施形態の変形例に係る中間サーバの処理を示すフローチャートである。図5を参照すると、まず、上記で図3を参照して説明した例と同様にS101〜S105が実行される。
次に、識別子記述部212が、ドキュメントの解析によって検出されたリソースへの参照にダミー識別子を関連付ける(S161)。ここで、ダミー識別子は、例えば機械的に生成される一連の識別子であり、必ずしもリソースの内容ごとに一意ではない。識別子記述部212は、例えば、ドキュメントの先頭から順に、検出された参照にインクリメンタルな、またはランダムなダミー識別子を関連付ける。このとき、参照されるリソースのオリジナルの識別子(例えばURL)が同一であれば、識別子記述部212はこれらの参照に同一のダミー識別子を関連付けてもよい。
次に、ドキュメント送信部214がドキュメントをクライアント300に送信する(S115)。この後に、またはこれと並行して、ドキュメントの解析によって検出されたリソースへの参照のそれぞれについて、リソース取得部208が参照されているリソースを取得し、識別子生成部210が取得されたリソースの内容に基づいて一意な識別子を生成する(S107〜S111)。
検出されたすべての参照についてS107〜S111の処理が終了すると、識別子記述部212が、S161で参照に関連付けられたダミー識別子と、S111で生成された一意な識別子とを関連付ける情報(識別子の関連付け情報)を生成する(S163)。ドキュメント送信部214は、識別子の関連付け情報をクライアント300に送信する(S165)。その後、クライアント300からリソースのリクエストが受信されれば、リソース送信部216がクライアント300にリソースを送信する(S117,S119)。
(クライアントの処理フロー)
図6は、本開示の第1の実施形態の変形例に係るクライアントの処理を示すフローチャートである。図6を参照すると、まず、上記で図4を参照して説明した例と同様にS131〜S135が実行される。
図6は、本開示の第1の実施形態の変形例に係るクライアントの処理を示すフローチャートである。図6を参照すると、まず、上記で図4を参照して説明した例と同様にS131〜S135が実行される。
ドキュメントにおいてリソースへの参照が発見された場合(S137のYES)、キャッシュ判定部306は、発見された参照に関連付けられたダミー識別子を一意な識別子に置換した上で(S181)、参照されているリソースがキャッシュ380に格納されているか否かを判定する(S139)。図示していないが、S181の時点で、上述した識別子の関連付け情報がドキュメント受信部304によって受信されていない場合、つまり、キャッシュ判定部306がリソースへの参照にダミー識別子が関連付けられた状態でリソースを参照する場合、キャッシュ判定部306は、識別子または識別子の関連付け情報のためのリクエストを中間サーバ200に送信する。この場合、中間サーバ200の識別子生成部210は、リクエストが受信された参照について、参照されているリソースの内容に基づく一意な識別子の生成を優先的に実行してもよい。
中間サーバ200の処理能力がクライアント300に比べて高い場合でも、識別子生成部210による一意な識別子の生成にはある程度の時間がかかる。従って、本変形例のように、容易に生成できるダミー識別子が参照に関連付けられたドキュメントを先行してクライアント300に送信し、クライアント300で受信されたドキュメントに基づいて表示が開始されるのと並行して中間サーバ200で一意な識別子の生成を実行することで、クライアント300でドキュメントの表示が完了するまでの時間をさらに短縮することができる。
(3.第2の実施形態)
(3−1.機能構成)
図7は、本開示の第2の実施形態に係る中間サーバおよびクライアントの概略的な機能構成を示すブロック図である。図7を参照すると、中間サーバ200は、機能構成として、リソース先行配信部218をさらに含む。また、クライアント300は、機能構成として、リソース先行受信部312をさらに含む。
(3−1.機能構成)
図7は、本開示の第2の実施形態に係る中間サーバおよびクライアントの概略的な機能構成を示すブロック図である。図7を参照すると、中間サーバ200は、機能構成として、リソース先行配信部218をさらに含む。また、クライアント300は、機能構成として、リソース先行受信部312をさらに含む。
中間サーバ200のリソース先行配信部218は、所定のリソースについて、リクエスト受信部202がクライアント300からリクエストを受信する前に、先行してクライアント300に送信する。このとき、リソース先行配信部218は、リソースを、識別子生成部210が生成したリソースの内容ごとに一意な識別子に関連付けてクライアント300に送信する。
例えば、リソース先行配信部218は、識別子生成部210によって生成された識別子が、ドキュメントにおいてリソースへの参照に関連付けられた回数をカウントし、この回数に基づいて使用頻度が高いと推定されるリソースをクライアント300に送信してもよい。識別子生成部210によって生成される識別子はリソースの内容ごとに一意であるため、上記のカウントは、URLなどに関わらず、リソースの内容ごとに、それぞれのリソースがいろいろなドキュメントにおいて参照された頻度を示すものでありうる。
あるいは、リソース先行配信部218は、サービス提供者によって指定されたリソースを、先行してクライアント300に送信してもよい。例えば、多くのドキュメントで共通して参照されることが予想されるスクリプトの標準ライブラリについては、サービス提供者による設定に従って、リソース先行配信部218がクライアント300に先行して送信しておくことで、ドキュメントを提供する場合にスクリプトのためのリクエストやリクエストに応じたスクリプトの送信にかかる時間を節減することができる。
また、先行して配信されるリソースがスクリプトのようなプログラムである場合、リソース先行配信部218は、プログラムをプリコンパイルしてからクライアント300に送信してもよい。例えば、クライアント300が、ドキュメントにおいて参照されたプログラムをコンパイルしてから実行する場合、プログラムがキャッシュ380に格納されていたとしても、コンパイルにかけられる時間は限られている。一方、中間サーバ200でリソース先行配信部218がプログラムをクライアント300への送信前にプリコンパイルする場合、コンパイルに十分に時間をかけることができるために、プログラム実行時の動作コンパイルによって十分に最適化することができる。
クライアント300のリソース先行受信部312は、リクエスト送信部302が中間サーバ200にリクエストを送信する前に、中間サーバ200のリソース先行配信部218が送信したリソースを受信する。ここで受信されるリソースは、上記のように、例えば、リソースへの参照に関連付けられた回数に基づいて使用頻度が高いと推定されるリソースであってもよいし、サービス提供者によって指定されたリソースであってもよい。いずれの場合も、リソース先行受信部312は、中間サーバ200から先行して配信されたリソースを受信し、受信したリソースをキャッシュ380に格納する。
上述のように、受信されるリソースは、中間サーバ200において識別子生成部210が生成した、リソースの内容ごとに一意な識別子に関連付けられている。リソース先行受信部312は、受信したリソースを、この識別子に関連付けてキャッシュ380に格納する。これによって、先行して配信されたリソースのオリジナルの識別子(例えばURL)に関わらず、先行して配信されたリソースと同一の内容のリソースがドキュメントにおいて参照された場合には、キャッシュ380に予め格納されたリソースを利用し、ドキュメントの表示を高速化することができる。
また、先行して配信されるリソースがスクリプトのようなプログラムである場合、リソース先行受信部312は、中間サーバ200のリソース先行配信部218によってプリコンパイルされたプログラムを受信してもよい。この場合、リソース先行受信部312は、プリコンパイルされたプログラムを、キャッシュ380において、例えば画像やCSSなどプログラム以外のリソースとは別の記憶領域に格納してもよい。プリコンパイルされたプログラムは、例えばWebCoreのようなライブラリと共通の記憶領域に格納されうる。これによって、クライアント300におけるドキュメントの表示時に、参照されているリソースに対応するプリコンパイルされたプログラムにより高速にアクセスすることが可能になりうる。
例えばHTMLドキュメントにおいて参照されるリソースのサイズの割合では、JavaScriptなどのスクリプトが画像に次いで大きな割合を占める。また、例えばJavaScriptの参照では、特定のいくつかの標準ライブラリが参照されるケースが大半である。従って、例えばスクリプトの標準ライブラリを予め中間サーバ200からクライアント300に配信しておくことで、ドキュメントの表示にあたって高い確率で発生するスクリプトの標準ライブラリのためのリクエストやリソースの送受信を省略し、ドキュメントの表示を高速化することができる。
より具体的には、スクリプトのアップデートがあった場合に、アップデート後のスクリプトがリクエストに先行して中間サーバ200からクライアント300に配信されていれば、アップデート後に初めてドキュメントから当該スクリプトが参照される場合であっても、クライアント300のキャッシュに格納されたスクリプトを利用して迅速にドキュメントを表示することができる。また、上記のような場合に、スクリプトの標準ライブラリがプリコンパイルされていれば、さらなる高速化が可能であることは上述した通りである。スクリプト以外でも、例えばロゴの画像や話題のアイテムの画像など、ドキュメントの表示にあたって参照される可能性が高いと推定されるリソースが予め中間サーバ200からクライアント300に配信することは、ドキュメントの表示を高速化することに寄与しうる。
(3−2.処理フロー)
(中間サーバの処理フロー)
図8は、本開示の第2の実施形態に係る中間サーバがリクエストを受信する前の処理を示すフローチャートである。図8を参照すると、まず、リソース先行配信部218が、先行して配信するリソースを決定する(S201)。ここで、先行して配信するリソースは、例えば上記のように識別子がドキュメントにおいてリソースへの参照に関連付けられた回数に基づいて決定されてもよいし、サービス提供者によって指定されてもよい。
(中間サーバの処理フロー)
図8は、本開示の第2の実施形態に係る中間サーバがリクエストを受信する前の処理を示すフローチャートである。図8を参照すると、まず、リソース先行配信部218が、先行して配信するリソースを決定する(S201)。ここで、先行して配信するリソースは、例えば上記のように識別子がドキュメントにおいてリソースへの参照に関連付けられた回数に基づいて決定されてもよいし、サービス提供者によって指定されてもよい。
また、リソース先行配信部218は、例えば上述したスクリプトの標準ライブラリのように、使用頻度が高いと推定され、かつアップデートの可能性があるリソースについて、配信元サーバ100に当該リソースを定期的にリクエストすることによってアップデートの有無を確認し、アップデートがあった場合にはアップデート後のリソースを先行して配信することを決定してもよい。リソース先行配信部218は、アップデートの有無の確認のために、識別子生成部210による識別子の生成処理を利用してもよい。つまり、識別子生成部210がリソースの内容ごとに一意な識別子を生成したときに、生成された識別子が以前に生成された識別子と異なっていれば、リソースにアップデートがあったと判断できる。
次に、リソース先行配信部218は、付加的な処理として、先行して配信されるリソースがプログラムであれば、必要に応じてプリコンパイルを実行する(S203)。次に、リソース先行配信部218は、リソースをクライアント300に送信する(S205)。
(クライアントの処理フロー)
図9は、本開示の第2の実施形態に係るクライアントがリクエストを送信する前の処理を示すフローチャートである。図9を参照すると、まず、リソース先行受信部312が、中間サーバ200から配信されたリソースを受信する(S211)。次に、リソース先行受信部312は、付加的な処理として、先行して配信されるリソースがプログラムであれば(S213のYES)、配信されたリソースを他のリソースとは別の、プログラム用の記憶領域にリソースを格納する(S215)。そうでない場合、リソース先行受信部312は、リソースを通常のキャッシュ380の記憶領域に格納する(S217)。
図9は、本開示の第2の実施形態に係るクライアントがリクエストを送信する前の処理を示すフローチャートである。図9を参照すると、まず、リソース先行受信部312が、中間サーバ200から配信されたリソースを受信する(S211)。次に、リソース先行受信部312は、付加的な処理として、先行して配信されるリソースがプログラムであれば(S213のYES)、配信されたリソースを他のリソースとは別の、プログラム用の記憶領域にリソースを格納する(S215)。そうでない場合、リソース先行受信部312は、リソースを通常のキャッシュ380の記憶領域に格納する(S217)。
なお、リクエスト送信後の中間サーバおよびクライアントの処理フローについては、上記の第1の実施形態と同様であるため詳細な説明を省略する。本実施形態では、上記のようにリクエストの送信に先行して一部のリソースが中間サーバ200からクライアント300に送信されているために、例えば図4に示したフローチャートのS139において、リソースがキャッシュ380に格納されていると判定される場合がより多くなる。
(4.第3の実施形態)
(4−1.機能構成)
図10(図10Aおよび図10B)は、本開示の第3の実施形態に係る中間サーバおよびクライアントの概略的な機能構成を示すブロック図である。図10Aを参照すると、中間サーバ200は、機能構成として、リクエスト受信部202と、ドキュメント取得部204と、ドキュメント解析部206と、リソース取得部208と、リソース解析部220と、短縮文字列生成部222と、短縮文字列記述部224と、ドキュメント送信部214と、関連付け情報送信部226と、リソース送信部216とを含む。図10Bを参照すると、クライアント300は、機能構成として、リクエスト送信部302と、ドキュメント受信部304と、リソース受信部308と、関連付け情報受信部314と、文字列解釈部316と、表示制御部310とを含む。
(4−1.機能構成)
図10(図10Aおよび図10B)は、本開示の第3の実施形態に係る中間サーバおよびクライアントの概略的な機能構成を示すブロック図である。図10Aを参照すると、中間サーバ200は、機能構成として、リクエスト受信部202と、ドキュメント取得部204と、ドキュメント解析部206と、リソース取得部208と、リソース解析部220と、短縮文字列生成部222と、短縮文字列記述部224と、ドキュメント送信部214と、関連付け情報送信部226と、リソース送信部216とを含む。図10Bを参照すると、クライアント300は、機能構成として、リクエスト送信部302と、ドキュメント受信部304と、リソース受信部308と、関連付け情報受信部314と、文字列解釈部316と、表示制御部310とを含む。
これらの機能構成は、例えば、中間サーバ200およびクライアント300をそれぞれ実現する情報処理装置に備えられるプロセッサが、メモリまたは記録媒体に格納されたプログラムに従って動作することによって実現されうる。また、中間サーバ200におけるデータベース282、およびクライアント300におけるデータベース382は、例えば、それぞれの情報処理装置のストレージまたはメモリによって実現されうる。
(中間サーバ)
中間サーバ200では、リクエスト受信部202およびドキュメント取得部204が、上記の第1の実施形態と同様に、クライアント300からのリクエストに応じてドキュメントを取得する。また、ドキュメント解析部206は、ドキュメント取得部204が取得したドキュメントを解析し、ドキュメントに含まれるリソースへの参照を検出する。リソース取得部208は、ドキュメント解析部206によってリソースへの参照が検出された場合に、参照されているリソースを取得する。
中間サーバ200では、リクエスト受信部202およびドキュメント取得部204が、上記の第1の実施形態と同様に、クライアント300からのリクエストに応じてドキュメントを取得する。また、ドキュメント解析部206は、ドキュメント取得部204が取得したドキュメントを解析し、ドキュメントに含まれるリソースへの参照を検出する。リソース取得部208は、ドキュメント解析部206によってリソースへの参照が検出された場合に、参照されているリソースを取得する。
さらに、本実施形態では、ドキュメント解析部206が、ドキュメント取得部204によって取得されたドキュメントに含まれる短縮可能な文字列を検出する。また、リソース解析部220が、リソース取得部208によって取得されたリソースに含まれる短縮可能な文字列を検出する。ここで、短縮可能な文字列は、例えば、ドキュメント内の要素や、スタイルで定義されるクラス、プログラムで定義された関数などに与えられる任意の識別子を含む。また、短縮可能な文字列は、ドキュメントやリソースのフォーマットにおける予約語を含んでもよい。さらに、短縮可能な文字列は、ドキュメントにおいて参照されているリソースの識別子や、いわゆる地の文としてドキュメントに記述されている文字列を含んでもよい。
ドキュメント解析部206およびリソース解析部220によって短縮可能な文字列が検出された場合、短縮文字列生成部222が、検出された文字列を短縮した文字列(以下、短縮文字列ともいう)を生成する。例えば、短縮文字列生成部222は、元の文字列に基づいて所定のアルゴリズムに従って演算を実行することによって短縮文字列を生成してもよい。後述するように、図示された例において、元の文字列と短縮文字列との関係はデータベース282に記録されるため、アルゴリズムは非可逆的なものでよい。あるいは、短縮文字列生成部222は、元の文字列に関係なく、インクリメンタルな、またはランダムな短縮文字列を生成してもよい。
ここで、上記の例において、アルゴリズムを利用して短縮文字列を生成する場合、短縮文字列がやや長くなるが、元の文字列が同じであれば自動的に同じ短縮文字列が生成されるため、データベース282のレコードを最小限にして検索性を向上させることができる。また、利用するアルゴリズムによっては、元の文字列に対して一意な短縮文字列を生成することができる。
一方、インクリメンタルな、またはランダムな短縮文字列を生成する場合、短縮文字列を極限まで短くできるが(例えば、ドキュメントまたはリソースに含まれる短縮可能な文字列の数を表現可能な最短の長さにすることができる)、そのままではデータベース282に短縮可能な文字列(重複したものを含む)の数だけレコードが生成されてしまう。短縮文字列生成部222がデータベース282を参照し、同じ元の文字列についてまだ短縮文字列が生成されていない場合に新たな短縮文字列を生成するようにすれば、データベース282のレコード数を削減することができる。
短縮文字列生成部222は、短縮文字列を生成した場合に、元の文字列と短縮文字列とを関連付けるレコード(短縮文字列レコード)をデータベース282に追加する。データベース282は、例えば、ドキュメントを単位として生成されてもよい。つまり、データベース282によって示される元の文字列と短縮文字列との対応づけは、単一のリクエストに応じて送信されるドキュメントと、このドキュメントから参照されるリソースとをスコープとしてもよい。あるいは、データベース282は、複数のドキュメントとこれらのドキュメントから参照されるリソースとをスコープとして生成されてもよい。
ここで、生成された短縮文字列について、元の文字列との対応付けがクライアント300においてデータベース382に記録されていることがわかっている場合、短縮文字列生成部222は、データベース282に短縮文字列レコードを追加しなくてもよい。例えば、ドキュメントやリソースのフォーマットにおける予約語を短縮可能な文字列として扱う場合、予約語は有限であるため、予め短縮文字列を割り当てて、予約語と短縮文字列との対応付けをデータベース282およびデータベース382に予め記録しておくことが可能である。この場合、短縮文字列生成部222は、ドキュメントまたはリソースにおいて検出された予約語について、データベース282を参照して予め割り当てられた短縮文字列を生成した上で、データベース282への新たなレコードの追加を省略する。
短縮文字列記述部224は、短縮文字列生成部222によって生成された短縮文字列で、ドキュメントおよびリソースに含まれる元の文字列を置換する。送信されるデータ量の削減、およびクライアント300における文字列読み取りの処理量の削減のためには、短縮文字列記述部224が、ドキュメントおよびリソースにおいて元の文字列を残すことなく、短縮文字列に置換することが望ましい。
ドキュメント送信部214は、短縮文字列生成部222によって生成された短縮文字列を含む(つまり、元の文字列が短縮文字列に置換された)ドキュメントをクライアント300に送信する。また、リソース送信部216は、同様に元の文字列が短縮文字列に置換されたリソースをクライアント300に送信する。関連付け情報送信部226は、データベース282の短縮文字列レコードに基づいて、元の文字列と短縮文字列とを関連付ける情報(以下、関連付け情報ともいう)を生成し、これをクライアント300に送信する。
ここで、関連付け情報送信部226は、クライアント300側で短縮文字列から元の文字列を復元する必要がある場合に限って、関連付け情報をクライアント300に送信してもよい。つまり、関連付け情報は、短縮文字列レコードの少なくとも一部を含まなくてもよい。
例えば、短縮文字列生成部222が、ドキュメント内の要素や、スタイルで定義されるクラス、プログラムで定義された関数などに与えられる任意の識別子について短縮文字列を生成した場合、ドキュメントおよびリソースを通じて、元の文字列と短縮文字列とが1対1で対応するように短縮文字列を生成している(例えば、元の文字列から所定にアルゴリズムに基づいて短縮文字列を生成したり、データベース282を参照して元の文字列について既に短縮文字列が生成されている場合にはその短縮文字列を再利用したりしている)のであれば、クライアント300側で元の文字列を復元しなくても、要素、クラス、または関数は一意に特定される。このような場合、関連付け情報送信部226は、当該短縮文字列についての関連付け情報をクライアント300に送信しなくてもよい。
また、例えば、ドキュメントまたはリソースにおける予約語について短縮文字列が生成される場合、データベース282には予め予約語に対応する短縮文字列に対応する短縮文字列レコードが含まれているが、クライアント300に送信される関連付け情報には予約語に関する情報が含まれなくてもよい(クライアント300のデータベース382に予約語に関する情報が予め格納されている場合)。
一方、要素、クラス、または関数などについて生成された短縮文字列でも、元の文字列と1対1で対応しない場合(例えば、短縮文字列生成部222が短縮文字列の生成にあたってデータベース282を参照せず、機械的に割り当てた短縮文字列の情報をデータベースに格納するような場合)や、地の文としてドキュメントに記述されている文字列のように最終的に元の文字列がユーザに提示されるような場合には、関連付け情報送信部226がデータベース282のレコードに基づいて生成された関連付け情報をクライアント300に送信する。
(クライアント)
クライアント300では、リクエスト送信部302およびドキュメント受信部304が、上記の第1の実施形態と同様に、中間サーバ200にリクエストを送信し、中間サーバ200がリクエストに応じて送信したドキュメントを受信する。また、リソース受信部308は、中間サーバ200から送信されたリソースを受信する。受信されたドキュメントおよびリソースは、文字列解釈部316に提供される。さらに、本実施形態では、関連付け情報受信部314が、中間サーバ200の関連付け情報送信部226から送信された関連付け情報を受信する。関連付け情報受信部314は、受信した関連付け情報に基づいて、データベース382に短縮文字列レコードを生成する。
クライアント300では、リクエスト送信部302およびドキュメント受信部304が、上記の第1の実施形態と同様に、中間サーバ200にリクエストを送信し、中間サーバ200がリクエストに応じて送信したドキュメントを受信する。また、リソース受信部308は、中間サーバ200から送信されたリソースを受信する。受信されたドキュメントおよびリソースは、文字列解釈部316に提供される。さらに、本実施形態では、関連付け情報受信部314が、中間サーバ200の関連付け情報送信部226から送信された関連付け情報を受信する。関連付け情報受信部314は、受信した関連付け情報に基づいて、データベース382に短縮文字列レコードを生成する。
文字列解釈部316は、データベース382を参照して、ドキュメントおよびリソースに含まれる短縮文字列を解釈する。ここで、文字列解釈部316は、短縮文字列を元の文字列に書き換える必要はない。本実施形態では、文字列解釈部316が、データベース382を参照することによってドキュメントおよびリソースに含まれる短縮文字列をそのまま解釈し、その解釈に基づいて表示制御部310がドキュメントを表示させることが可能である。
なお、上述の通り、クライアント300において受信されるドキュメントおよびリソースには、関連付け情報受信部314が受信する関連付け情報には含まれない短縮文字列も含まれる。例えば、ドキュメントやリソースのフォーマットにおける予約語について、予め短縮文字列と予約語との対応付けがデータベース382に記録されているような場合、関連付け情報受信部314が受信する関連付け情報に予約語に対応する短縮文字列は含まれない。
また、例えば、ドキュメント内の要素や、スタイルで定義されるクラス、プログラムで定義された関数などに与えられる任意の識別子について、ドキュメントおよびリソースを通じて、元の文字列と短縮文字列とが1対1で対応するように短縮文字列が生成されていれば、当該短縮文字列に対応する情報は関連付け情報には含まれず、またデータベース382にも含まれていなくてもよい。この場合、当該短縮文字列は、クライアント300においては通常の文字列と同様に扱われ、表示制御部310が直接的にこれを解釈してドキュメントを表示させる。
(4−2.処理フロー)
(中間サーバの処理フロー)
図11は、本開示の第3の実施形態に係る中間サーバの処理を示すフローチャートである。図11を参照すると、まず、リクエスト受信部202が、クライアント300からのリクエストを受信する(S301)。次に、ドキュメント取得部204が、リクエストにおいて指定されたドキュメントを取得する(S303)。次に、ドキュメント解析部206が、取得されたドキュメントを解析する(S305)。
(中間サーバの処理フロー)
図11は、本開示の第3の実施形態に係る中間サーバの処理を示すフローチャートである。図11を参照すると、まず、リクエスト受信部202が、クライアント300からのリクエストを受信する(S301)。次に、ドキュメント取得部204が、リクエストにおいて指定されたドキュメントを取得する(S303)。次に、ドキュメント解析部206が、取得されたドキュメントを解析する(S305)。
ここで、ドキュメントの解析においてリソースへの参照が検出された場合(S307のYES)、リソース取得部208が参照されているリソースを取得し(S309)、リソース解析部220が、取得されたリソースを解析する(S311)。その後、短縮文字列生成部222が、ドキュメントおよびリソースで検出された短縮可能な文字列について、短縮文字列を生成する(S313)。このとき、短縮文字列生成部222は、元の文字列と短縮文字列とを関連付ける短縮文字列レコードを、データベース282に追加する(S315)。
さらに、短縮文字列記述部224が、短縮文字列生成部222によって生成された短縮文字列によって、ドキュメントおよびリソースに含まれる元の文字列を置換する(S317)。ドキュメントにおける元の文字列の置換が完了すると、ドキュメント送信部214が、短縮文字列を含むドキュメントをクライアント300に送信する(S319)。これと前後して、またはこれと並行して、関連付け情報送信部226が、データベース382のレコードに基づいて生成された関連付け情報をクライアント300に送信する(S321)。さらに、リソース送信部216がクライアント300に短縮文字列を含むリソースを送信する(S323)。
(クライアントの処理フロー)
図12は、本開示の第3の実施形態に係るクライアントの処理を示すフローチャートである。図12を参照すると、まず、リクエスト送信部302が、中間サーバ200にリクエストを送信する(S331)。次に、ドキュメント受信部304が、中間サーバ200がリクエストに応じて送信した、短縮文字列を含むドキュメントを受信する(S333)。これと前後して、またはこれと並行して、関連付け情報受信部314が、中間サーバ200から送信された関連付け情報を受信する(S335)。関連付け情報受信部314は、受信した関連付け情報に基づいてデータベース382にレコードを生成する(S337)。また、リソース受信部308が、中間サーバ200が送信した、短縮文字列を含むリソースを受信する(S339)。
図12は、本開示の第3の実施形態に係るクライアントの処理を示すフローチャートである。図12を参照すると、まず、リクエスト送信部302が、中間サーバ200にリクエストを送信する(S331)。次に、ドキュメント受信部304が、中間サーバ200がリクエストに応じて送信した、短縮文字列を含むドキュメントを受信する(S333)。これと前後して、またはこれと並行して、関連付け情報受信部314が、中間サーバ200から送信された関連付け情報を受信する(S335)。関連付け情報受信部314は、受信した関連付け情報に基づいてデータベース382にレコードを生成する(S337)。また、リソース受信部308が、中間サーバ200が送信した、短縮文字列を含むリソースを受信する(S339)。
S333でドキュメントが受信され、S337でデータベース382に短縮文字列レコードが生成されると、文字列解釈部316が、データベース382を参照して、ドキュメントに含まれる短縮文字列を解釈する(S341)。なお、S341の処理は、例えばS339の処理と並行して実行されてもよい。S339で受信された、ドキュメントで参照されているリソースについても、文字列解釈部316は、データベース382を参照して短縮文字列を解釈する(S343)。表示制御部310は、文字列解釈部316がドキュメントおよびリソースに含まれる短縮文字列を解釈した結果を利用して、ドキュメントを表示させる(S345)。
本実施形態では、中間サーバ200において、短縮文字列生成部222が元の文字列と短縮文字列とを関連付けるレコードをデータベース282に追加する。これによって、例えば、短縮文字列の生成にあたってデータベース382を参照し、ドキュメントおよびリソースを通じて元の文字列と短縮文字列との関係を1対1の関係にすることができる。この場合、クライアント300に関連付け情報を送信しなくても、クライアント300がドキュメントとリソースとのそれぞれに記述された短縮文字列を解釈して、リソースを参照するドキュメントを表示させることが可能である。
あるいは、中間サーバ200では、関連付け情報送信部226が、ドキュメントおよびリソースにおいてそれぞれ生成された短縮文字列と元の文字列とを関連付ける関連付け情報をデータベース282のレコードに基づいて生成し、これをクライアント300に送信してもよい。この場合、例えば、短縮文字列の生成時には元の文字列と短縮文字列との関係が1対1になっていなくても、クライアント300がドキュメントとリソースとのそれぞれに記述された短縮文字列を解釈して、リソースを参照するドキュメントを表示させることが可能である。
(4−3.変形例)
(中間サーバの処理フロー)
図13は、本開示の第3の実施形態の変形例に係る中間サーバの処理を示すフローチャートである。図13を参照すると、まず、上記で図11を参照して説明した例と同様にS301〜S305が実行される。
(中間サーバの処理フロー)
図13は、本開示の第3の実施形態の変形例に係る中間サーバの処理を示すフローチャートである。図13を参照すると、まず、上記で図11を参照して説明した例と同様にS301〜S305が実行される。
本変形例では、短縮文字列生成部222が、ドキュメントで検出された短縮可能な文字列について、先行して短縮文字列を生成する(S361)。このとき、短縮文字列生成部222は、元の文字列と短縮文字列とを関連付けるレコードを、データベース282に追加する(S315)。さらに、短縮文字列記述部224が、データベース282のレコードに従って、ドキュメントに含まれる文字列を短縮文字列に置換する(S363)。置換が完了すると、ドキュメント送信部214が、短縮文字列を含むドキュメントをクライアント300に送信する(S319)。ドキュメントの送信と前後して、またはこれと並行して、関連付け情報送信部226が、データベース282のレコードに基づいて生成された関連付け情報をクライアント300に送信する(S321)。
ドキュメントおよび関連付け情報の送信後に、またはこれと並行して、ドキュメントの解析においてリソースへの参照が検出された場合(S307のYES)、リソース取得部208が参照されているリソースを取得し(S309)、リソース解析部220が、取得されたリソースを解析する(S311)。その後、短縮文字列記述部224が、S315の処理によって生成されたデータベース382の短縮文字列レコードに基づいて、リソースに含まれる文字列を短縮文字列に置換する(S365)。その後、リソース送信部216が、クライアント300に短縮文字列を含むリソースを送信する(S323)。
本変形例では、ドキュメントにおける短縮文字列の生成結果に基づいて、リソースの文字列が短縮文字列に置換される。これによって、ドキュメントと関連付け情報とを先行してクライアント300に送信した上で、リソースについてもドキュメントと整合するように短縮文字列への置換を実行することができる。従って、リソースについての短縮文字列の置換の完了を待つことなく、クライアント300でドキュメントの表示を開始することができる。
なお、本変形例におけるクライアントの処理フローは、リソース受信部308が、ドキュメントおよび関連付け情報が受信された後にリソースを受信する点を除いて、図12に示したものと同様でありうるため、詳細な説明は省略する。また、上記の本実施形態の説明では、元の文字列と短縮文字列とを関連付ける情報がデータベースに格納される例について説明したが、情報は必ずしもデータベースに格納されなくてもよく、他の例ではファイルなどが用いられてもよい。
(5.第4の実施形態)
(5−1.機能構成)
図14(図14Aおよび図14B)は、本開示の第4の実施形態に係る中間サーバおよびクライアントの概略的な機能構成を示すブロック図である。図14Aを参照すると、中間サーバ200は、機能構成として、リクエスト受信部202と、ドキュメント取得部204と、ドキュメント解析部206と、リソース取得部208と、識別子生成部210と、識別子記述部212と、リソース解析部220と、短縮文字列生成部222と、短縮文字列記述部224と、ドキュメント送信部214と、関連付け情報送信部226と、リソース送信部216とを含む。図14Bを参照すると、クライアント300は、機能構成として、リクエスト送信部302と、ドキュメント受信部304と、関連付け情報受信部314と、文字列解釈部316と、キャッシュ判定部306と、リソース受信部308と、表示制御部310とを含む。
(5−1.機能構成)
図14(図14Aおよび図14B)は、本開示の第4の実施形態に係る中間サーバおよびクライアントの概略的な機能構成を示すブロック図である。図14Aを参照すると、中間サーバ200は、機能構成として、リクエスト受信部202と、ドキュメント取得部204と、ドキュメント解析部206と、リソース取得部208と、識別子生成部210と、識別子記述部212と、リソース解析部220と、短縮文字列生成部222と、短縮文字列記述部224と、ドキュメント送信部214と、関連付け情報送信部226と、リソース送信部216とを含む。図14Bを参照すると、クライアント300は、機能構成として、リクエスト送信部302と、ドキュメント受信部304と、関連付け情報受信部314と、文字列解釈部316と、キャッシュ判定部306と、リソース受信部308と、表示制御部310とを含む。
これらの機能構成は、例えば、中間サーバ200およびクライアント300をそれぞれ実現する情報処理装置に備えられるプロセッサが、メモリまたは記録媒体に格納されたプログラムに従って動作することによって実現されうる。また、中間サーバ200におけるキャッシュ280およびデータベース282、ならびにクライアント300におけるキャッシュ380およびデータベース382は、例えば、それぞれの情報処理装置のストレージまたはメモリによって実現されうる。
図14を参照すれば明らかなように、本実施形態は、上記の第1の実施形態と第3の実施形態とを合わせた実施形態である。中間サーバ200およびクライアント300の機能構成のそれぞれについては、第1および第3の実施形態において既に説明されているため、詳細な説明を省略する。
(5−2.処理フロー)
続いて、本実施形態の処理フローについて説明する。なお、以下の説明では、第1の実施形態および第3の実施形態のそれぞれの変形例を組み合わせたより複雑な処理フローについて説明するが、変形例ではない例を組み合わせた例についても同様に実現可能であることは容易に理解されるであろう。
続いて、本実施形態の処理フローについて説明する。なお、以下の説明では、第1の実施形態および第3の実施形態のそれぞれの変形例を組み合わせたより複雑な処理フローについて説明するが、変形例ではない例を組み合わせた例についても同様に実現可能であることは容易に理解されるであろう。
(中間サーバの処理フロー)
図15(図15Aおよび図15B)は、本開示の第4の実施形態に係る中間サーバの処理を示すフローチャートである。図15を参照すると、まず、リクエスト受信部202が、クライアント300からのリクエストを受信する(S401)。次に、ドキュメント取得部204が、リクエストにおいて指定されたドキュメントを取得する(S403)。次に、ドキュメント解析部206が、取得されたドキュメントを解析する(S405)。
図15(図15Aおよび図15B)は、本開示の第4の実施形態に係る中間サーバの処理を示すフローチャートである。図15を参照すると、まず、リクエスト受信部202が、クライアント300からのリクエストを受信する(S401)。次に、ドキュメント取得部204が、リクエストにおいて指定されたドキュメントを取得する(S403)。次に、ドキュメント解析部206が、取得されたドキュメントを解析する(S405)。
ここで、リソース取得部208は、ドキュメントで検出されたリソースへの参照について、参照されているリソースを取得する(S407)。識別子生成部210は、取得されたリソースの内容に基づいて一意な識別子を生成する(S409)。識別子記述部212は、生成された一意な識別子を、ドキュメントにおけるリソースへの参照に関連付ける(S411)。なお、上記の処理は、1または複数のリソースへの参照が検出される度に逐次実行されてもよいし、全部のリソースへの参照が検出されてから一括して実行されてもよい。
上記のS407〜S411と前後して、または並行して、短縮文字列生成部222が、ドキュメントで検出された短縮可能な文字列について、短縮文字列を生成する(S413)。このとき、短縮文字列生成部222は、元の文字列と短縮文字列とを関連付ける短縮文字列レコードを、データベース282に追加する(S415)。さらに、短縮文字列記述部224が、データベース282の短縮文字列レコードに従って、ドキュメントに含まれる文字列を短縮文字列に置換する(S417)。なお、図示された例のように、S407〜S411とS413〜S417とが並行して実行される場合は、ドキュメントにおけるリソースへの参照は、短縮文字列の生成の対象にならなくてもよい。
ここまでの処理が完了すると、ドキュメント送信部214が、識別子記述部212および短縮文字列記述部224によって更新されたドキュメントをクライアント300に送信する(S419)。これと前後して、またはこれと並行して、関連付け情報送信部226が、データベース282のレコードに基づいて生成された関連付け情報をクライアント300に送信する(S421)。
ドキュメントおよび関連付け情報の送信と前後して、またはこれと並行して、リソース解析部220が、上記のS407において取得されたリソースを解析する(S423)。その後、短縮文字列記述部224が、ドキュメントについての短縮文字列生成部222の処理によって生成されたデータベース282の短縮文字列レコードに基づいて、リソースに含まれる文字列を短縮文字列に置換する(S425)。その後、リソース送信部216が、クライアント300からのリソースのリクエストに応じてクライアント300にリソースを送信する(S427)。
(クライアントの処理フロー)
図16(図16Aおよび図16B)は、本開示の第4の実施形態に係るクライアントの処理を示すフローチャートである。図16を参照すると、まず、リクエスト送信部302が、中間サーバ200にリクエストを送信する(S451)。次に、ドキュメント受信部304が、中間サーバ200がリクエストに応じて送信したドキュメントを受信する(S453)。
図16(図16Aおよび図16B)は、本開示の第4の実施形態に係るクライアントの処理を示すフローチャートである。図16を参照すると、まず、リクエスト送信部302が、中間サーバ200にリクエストを送信する(S451)。次に、ドキュメント受信部304が、中間サーバ200がリクエストに応じて送信したドキュメントを受信する(S453)。
ドキュメントの受信と前後して、またはこれと並行して、関連付け情報受信部314が、中間サーバ200から送信された関連付け情報を受信する(S455)。関連付け情報受信部314は、受信した関連付け情報に基づいてデータベース382に短縮文字列レコードを生成する(S457)。次に、文字列解釈部316が、データベース382を参照して、ドキュメントに含まれる短縮文字列を解釈する(S459)。表示制御部310は、文字列解釈部316による解釈に基づいて、受信されたドキュメントの表示を開始する(S461)。
ドキュメントにおいてリソースへの参照が発見された場合(S463のYES)、キャッシュ判定部306が、受信されたドキュメントにおいて参照されているリソースについて、キャッシュ380に格納されているか(キャッシュされているか)否かを判定する(S465)。上述のように、キャッシュ判定部306は、ドキュメントにおけるリソースへの参照に関連付けられた、リソースの内容ごとに一意な識別子に基づいて、リソースがキャッシュ380に格納されているか否かを判定する。
リソースがキャッシュ380に格納されていると判定された場合(S465のYES)、キャッシュ判定部306はキャッシュ380からリソースを読み出して文字列解釈部316に提供する。つまり、キャッシュ判定部306は、キャッシュ380されたリソースを再利用する(S467)。一方、リソースがキャッシュ380に格納されていないと判定された場合(S465のNO)、キャッシュ判定部306は、中間サーバ200にリソースのリクエストを送信する(S469)。リソース受信部308は、リクエストに応じて中間サーバ200が送信したリソースを受信する(S471)。
文字列解釈部316は、データベース382のレコードに基づいて、再利用されたリソース、または中間サーバ200から受信されたリソースに含まれる短縮文字列を解釈する(S473)。表示制御部310は、文字列解釈部316がドキュメントおよびリソースに含まれる短縮文字列を解釈した結果を利用して、ドキュメントの表示を継続する(S475)。S465〜S475は、ドキュメントにおけるリソースへの参照がすべて発見されるまで繰り返し実行されうる。表示制御部310がドキュメントの全体を表示させ、リソースへの参照も発見されなくなった場合、またはリソースへの参照が発見されなかった場合(S463のNO)、クライアント300はドキュメントの表示を完了する(S477)。
なお、本実施形態で、リソースについてクライアント300におけるキャッシュ380を利用する場合、リソースに含まれる短縮文字列は、リソースが参照される機会に関わらず同一であることが望ましい。従って、例えば、中間サーバ200において、短縮文字列生成部222が所定のアルゴリズムを利用して短縮文字列を生成し、元の文字列が同じであれば自動的に同じ短縮文字列が生成されるようにしてもよい。あるいは、中間サーバ200におけるデータベース282を複数のドキュメントについて共通で利用することによって、元の文字列が同じであれば同じ短縮文字列が生成されるようにしてもよい。
(6.第5の実施形態)
図17Aは、本開示の第5の実施形態に係る中間サーバの処理を示すフローチャートである。なお、図示された一連の処理は、中間サーバ200を実現する情報処理装置に備えられるプロセッサがメモリまたは記録媒体に格納されたプログラムに従って動作することによって実行されうる。
図17Aは、本開示の第5の実施形態に係る中間サーバの処理を示すフローチャートである。なお、図示された一連の処理は、中間サーバ200を実現する情報処理装置に備えられるプロセッサがメモリまたは記録媒体に格納されたプログラムに従って動作することによって実行されうる。
図17Aを参照すると、まず、プロセッサは、クライアント300からのリクエストを受信する(S501)。次に、プロセッサは、リクエストにおいて指定されたドキュメントを取得する(S503)。上記の他の実施形態と同様に、プロセッサは、ドキュメントを配信元サーバ100から取得してもよいし、キャッシュから内部的に取得してもよい。次に、プロセッサは、ドキュメントにおいて参照されているリソースを取得する(S505)。リソースも、配信元サーバ100から取得されてもよいし、キャッシュから内部的に取得されてもよい。
さらに、プロセッサは、取得されたドキュメントおよびリソースに基づいて中間データを生成する(S507)。中間データの生成は、例えば、HTMLドキュメントのパースによるDOM(Document Object Model)の生成、CSSの処理によるComputed Styleの生成、およびJavaScriptのパースによる中間表現への変換などを含みうる。プロセッサは、生成された中間データをクライアント300に送信する(S509)。
図17Bは、本開示の第5の実施形態に係るクライアントの処理を示すフローチャートである。なお、図示された一連の処理は、クライアント300を実現する情報処理装置に備えられるプロセッサがメモリまたは記録媒体に格納されたプログラムに従って動作することによって実行されうる。
図17Bを参照すると、まず、プロセッサは、中間サーバ200にリクエストを送信する(S521)。次に、プロセッサは、中間サーバ200がリクエストに応じて送信した、ドキュメントおよびリソースに基づく中間データを受信する(S523)。プロセッサは、受信した中間データに基づいてレイアウトを生成し(S525)、レイアウトに従ってドキュメントを表示させる(S527)。
本実施形態によれば、クライアント300でドキュメントを表示するための処理の一部が中間サーバ200で代わりに実行される。中間サーバ200の処理能力がクライアント300よりも高ければ、これによってクライアント300でリクエストを送信してからドキュメントの表示が完了するまでの時間が短縮される。
なお、中間サーバ200でどのような中間データを生成するかは、ネットワークの状況や、クライアント300の処理能力などに応じて適宜決定される。例えば、HTMLドキュメントに関する上記の3つの例のうち、1つだけが採用されてもよいし、いずれか2つが採用されてもよいし、3つ全部が採用されてもよい。
以下、本実施形態におけるJavaScriptのパースによる中間表現への変換の例について、さらに詳しく説明する。
通常の場合、JavaScriptは、Webブラウザに組み込まれたJIT(Just In Time)コンパイラによって、コードの実行時にコンパイルおよび最適化される。最適化によってコードの実行時間は短縮される。しかしながら、ドキュメントの表示に要する時間全体としてみると、コンパイルおよび最適化のための時間がオーバーヘッドとなっており、実行時間の短縮分を相殺している。従って、最適化の効果が十分に発揮されているとはいいがたい。一例では、コンパイルおよび最適化のための時間は、ドキュメントの表示に要する時間全体の15%〜25%を占める場合もある。
そこで、本実施形態のいくつかの例では、中間サーバ200でコンパイラがJavaScriptを予めパースして中間表現に変換することによって、クライアント300におけるコンパイルや最適化のための処理時間を削減しつつ、最適化による実行時間の短縮効果を得ることができる。また、JavaScriptが中間表現に変換されることによってコードのデータ量が減少すれば、中間サーバ200とクライアント300との間の通信時間も削減することができる。
なお、上記の例においても、クライアント300でJITコンパイラによるコンパイルおよび/または最適化が実行されてもよい。例えば、中間サーバ200のコンパイラがグローバルな最適化を実行するとともに、クライアント300でJITコンパイラがさらなる最適化を実行してもよい。あるいは、中間サーバ200におけるコードの解析結果に基づく最適化のためのヒントとなる情報をドキュメントに付加し、JITコンパイラでの最適化をより高速かつ有効的に実施することも可能である。
図18Aは、JITコンパイラの通常の処理の例を示すフローチャートである。なお、図示された一連の処理は、例えばクライアントを実現する情報処理装置に備えられるプロセッサがメモリまたは記録媒体に格納されたプログラムに従ってJITコンパイラとして動作することによって実行されうる。
図18Aを参照すると、まず、プロセッサは、サーバからドキュメントに伴うリソースとして送信されたJavaScriptのソースを読み込む(S531)。次に、プロセッサは、JavaScriptをパースし(S533)、AST(Abstract Syntax Tree)を構築する(S535)。ここで、プロセッサは、例えばドキュメントまたはJITコンパイラの設定情報に基づいて、最適化を実施するか否かを判定する(S537)。最適化を実施する場合、プロセッサは、S535で構築したASTを高レベル中間表現(IR:Intermediate Representation)に変換する(S539)。さらに、プロセッサは、高レベルIRを最適化する(S541)。続いて、プロセッサは、最適化された高レベルIRを、低レベルIRに変換する(S543)。プロセッサは、低レベルIRについても最適化する(S545)。最適化された低レベルIRに基づいて、プロセッサはネイティブコードを生成する(S547)。なお、S537で最適化を実施しない場合、プロセッサは最適化されていないASTに基づいてネイティブコードを生成する(S547)。
図18Bは、本開示の第5の実施形態のいくつかの例に係る中間サーバ200のコンパイラの処理の例を示すフローチャートである。なお、図示された一連の処理は、例えば中間サーバ200を実現する情報処理装置に備えられるプロセッサがメモリまたは記録媒体に格納されたプログラムに従ってコンパイラとして動作することによって実行されうる。
図18Bを参照すると、まず、プロセッサは、処理対象のドキュメントに対応するリソースから、JavaScriptのソースを読み込む(S551)。次に、プロセッサは、JavaScriptをパースし(S553)、ASTを構築する(S555)。ここで、プロセッサは、例えばドキュメントまたはコンパイラの設定情報に基づいて、最適化を実施するか否かを判定する(S557)。最適化を実施する場合、プロセッサは、S555で構築したASTを高レベルIRに変換する(S559)。さらに、プロセッサは、高レベルIRを最適化する(S561)。プロセッサは、最適化された高レベルIRをクライアント300に送信する(S563)。なお、S557の判定において最適化を実施しない場合、プロセッサは、最適化されていないASTをクライアント300に送信する(S565)。
図18Cは、図18Bの例に係るクライアント300のJITコンパイラの処理の例を示すフローチャートである。なお、図示された一連の処理は、例えばクライアント300を実現する情報処理装置に備えられるプロセッサがメモリまたは記録媒体に格納されたプログラムに従ってJITコンパイラとして動作することによって実行されうる。
図18Cを参照すると、まず、プロセッサは、中間サーバ200からコードを受信する(S571)。図18BのS563,565で説明されたように、ここで受信されるコードは、最適化された高レベルIRか、最適化されていないASTである。プロセッサは、例えばドキュメントまたはJITコンパイラの設定情報に基づいて、最適化を実施するか否かを判定する(S573)。最適化を実施する場合、プロセッサは、受信されたコードが高レベルIRであるか否かを判定する(S575)。つまり、クライアント300側で読み取られる設定情報では最適化を実施することになっていても、中間サーバ200では最適化が実施されていないことがありうる。このような設定は、例えば後述するような理由によりクライアント300だけで最適化を実施する方が有利であるような場合に採用されうる。
S575の判定において、受信されたコードが高レベルIRではない場合、プロセッサは、受信されたコード(AST)を高レベルIRに変換し(S577)、さらに最適化する(S579)。続いて、プロセッサは、高レベルIRを低レベルIRに変換する(S581)。ここで用いられる高レベルIRは、S579で最適化された高レベルIRか、中間サーバ200で生成されて受信されたコードに含まれていた高レベルIRである。さらに、プロセッサは、低レベルIRを最適化し(S583)、最適化された低レベルIRに基づいてネイティブコードを生成する(S585)。
一方、S573の判定において最適化を実施しない場合も、プロセッサは、受信されたコードが高レベルIRであるか否かを判定する(S587)。つまり、クライアント300側で読み取られる設定情報では最適化を実施しないことになっていても、中間サーバ200では最適化が実施されていることがありうる。このような設定は、例えば後述するような理由により中間サーバ200だけで最適化を実施する方が有利であるような場合に採用されうる。
S587の判定において、受信されたコードが高レベルIRである場合、プロセッサは、高レベルIRを低レベルIRに変換し(S589)、低レベルIRに基づいてネイティブコードを生成する(S585)。一方、受信されたコードが高レベルIRではない場合、プロセッサは、受信されたコード(AST)に基づいてネイティブコードを生成する(S585)。
上記の例では、中間サーバ200のコンパイラによってJavaScriptのパースおよびASTの構築が実施される。従って、中間サーバ200からクライアント300に送信される、JavaScriptに対応する中間コードのリソースは、少なくともASTを含む。それゆえ、クライアント300では、ASTの構築までに要する時間分のオーバーヘッドが削減される。
なお、中間コードのサイズが大きいと、転送時の通信によるオーバーヘッドが増加するため、ドキュメントの表示に要する時間全体としての短縮にはつながらない可能性がある。そのため、実行時に必要ではない情報、例えばシンボル情報などを中間コードから除去し、さらに使用される文字列を短縮するなどして中間コードを最小化し、中間サーバ200とクライアント300との間の通信時間を削減することが望ましい。
さらに、例えばドキュメントまたはコンパイラの設定情報において中間サーバ200での最適化が有効化されている場合、中間サーバ200のコンパイラがASTを高レベルIRに変換し、さらに最適化した上でクライアント300に送信する。この場合、クライアント300での最適化の処理時間が削減される一方で、中間サーバ200での最適化によって実行時間は短縮されるため、クライアント300においてドキュメントの表示に要する時間がさらに短縮されうる。
ただし、一般的には、実行速度の最適化を実施するとコードのサイズは大きくなる傾向があるため、最適化によってコードのサイズが大きくなる場合には、中間サーバ200で最適化された高レベルIRをクライアントに送信するのではなく、最適化のヒント(手順など)を示す情報を付加した上で、最適化前の中間コード(ASTまたは高レベルIR)をクライアント300に送信してもよい。この場合、付加された情報に従ってクライアント300のJITコンパイラが最適化を実施することによって、通信時間と処理時間との両方を削減できる可能性がある。
(7.第6の実施形態)
図19は、本開示の第6の実施形態に係る中間サーバの処理を示すフローチャートである。なお、図示された一連の処理は、中間サーバ200を実現する情報処理装置に備えられるプロセッサがメモリまたは記録媒体に格納されたプログラムに従って動作することによって実行されうる。なお、本実施形態に限り、ドキュメントをHTMLドキュメント、リソースをCSSとして説明する。
図19は、本開示の第6の実施形態に係る中間サーバの処理を示すフローチャートである。なお、図示された一連の処理は、中間サーバ200を実現する情報処理装置に備えられるプロセッサがメモリまたは記録媒体に格納されたプログラムに従って動作することによって実行されうる。なお、本実施形態に限り、ドキュメントをHTMLドキュメント、リソースをCSSとして説明する。
図19を参照すると、まず、プロセッサは、クライアント300からのリクエストを受信する(S601)。次に、プロセッサは、リクエストにおいて指定されたHTMLドキュメントを取得する(S603)。上記の他の実施形態と同様に、プロセッサは、HTMLドキュメントを配信元サーバ100から取得してもよいし、キャッシュから内部的に取得してもよい。次に、プロセッサは、HTMLドキュメントにおいて参照されているCSSを取得する(S605)。CSSも、配信元サーバ100から取得されてもよいし、キャッシュから内部的に取得されてもよい。
さらに、プロセッサは、HTMLドキュメントの要素ごとに、CSSによって定義されるスタイルを特定する(S607)。HTMLドキュメントで階層構造をなす複数のCSSが参照されている場合、S607の処理によって、複数のCSSのうちのどのスタイルの組み合わせが採用されるのかが特定される。プロセッサは、S607の処理の結果に基づいてCSSを更新し(S609)、ドキュメントとともに更新されたCSSをクライアント300に送信する(S611)。
本実施形態において、クライアント300は、中間サーバ200から受信したHTMLドキュメントおよびCSSに基づいて、HTMLドキュメントを表示させる。このときの処理は、通常のHTMLドキュメントの表示のための処理と同様であるため詳細な説明は省略する。しかしながら、本実施形態の場合、クライアント300で参照されるCSSは、上述したような中間サーバ200での処理によって最適化されている。従って、クライアント300は、HTMLドキュメントの各要素について定義されるスタイルを特定するための処理の大部分を省略することができる。従って、中間サーバ200の処理能力がクライアント300よりも高ければ、これによってクライアント300でリクエストを送信してからドキュメントの表示が完了するまでの時間が短縮される。
なお、上記の説明ではリソースをCSSとしたが、HTMLドキュメントではCSSとともに画像やスクリプトなどの他のリソースがあわせて参照されてもよい。
(8.第7の実施形態)
(8−1.機能構成)
図20は、本開示の第7の実施形態に係る中間サーバおよびクライアントの概略的な機能構成を示すブロック図である。図20を参照すると、中間サーバ200は、機能構成として、リクエスト受信部202と、ドキュメント取得部204と、ドキュメント解析部206と、リソース取得部208と、画像トランスコード部228と、画像参照更新部230と、ドキュメント送信部214と、リソース送信部216とを含む。クライアント300は、機能構成として、リクエスト送信部302と、ドキュメント受信部304と、リソース受信部308と、表示制御部310とを含む。
(8−1.機能構成)
図20は、本開示の第7の実施形態に係る中間サーバおよびクライアントの概略的な機能構成を示すブロック図である。図20を参照すると、中間サーバ200は、機能構成として、リクエスト受信部202と、ドキュメント取得部204と、ドキュメント解析部206と、リソース取得部208と、画像トランスコード部228と、画像参照更新部230と、ドキュメント送信部214と、リソース送信部216とを含む。クライアント300は、機能構成として、リクエスト送信部302と、ドキュメント受信部304と、リソース受信部308と、表示制御部310とを含む。
これらの機能構成は、例えば、中間サーバ200およびクライアント300をそれぞれ実現する情報処理装置に備えられるプロセッサが、メモリまたは記録媒体に格納されたプログラムに従って動作することによって実現されうる。また、中間サーバ200におけるキャッシュ280、およびクライアント300におけるキャッシュ380は、例えば、それぞれの情報処理装置のストレージまたはメモリによって実現されうる。
(中間サーバ)
中間サーバ200では、リクエスト受信部202およびドキュメント取得部204が、上記の第1の実施形態と同様に、クライアント300からのリクエストに応じてドキュメントを取得する。また、ドキュメント解析部206は、ドキュメント取得部204が取得したドキュメントを解析し、ドキュメントに含まれるリソースへの参照を検出する。リソース取得部208は、ドキュメント解析部206によってリソースへの参照が検出された場合に、参照されているリソースを取得する。
中間サーバ200では、リクエスト受信部202およびドキュメント取得部204が、上記の第1の実施形態と同様に、クライアント300からのリクエストに応じてドキュメントを取得する。また、ドキュメント解析部206は、ドキュメント取得部204が取得したドキュメントを解析し、ドキュメントに含まれるリソースへの参照を検出する。リソース取得部208は、ドキュメント解析部206によってリソースへの参照が検出された場合に、参照されているリソースを取得する。
ここで、リソース取得部208が取得するリソースには、さまざまなフォーマットの画像が含まれる。画像トランスコード部228は、取得された画像を所定のフォーマットにトランスコードし、トランスコードされた画像をキャッシュ280に格納する。画像参照更新部230は、ドキュメントに含まれる画像リソースへの参照を、キャッシュ280に格納された、画像トランスコード部228によるトランスコード後の画像への参照に更新する。ドキュメント送信部214は、参照が更新されたドキュメントをクライアント300に送信する。リソース送信部216は、クライアント300からのリクエストに応じてキャッシュ280に格納されたリソースを送信する。送信されるリソースには、画像トランスコード部228によって所定のフォーマットにトランスコードされた画像が含まれうる。
(クライアント)
クライアント300では、リクエスト送信部302およびドキュメント受信部304が、上記の第1の実施形態と同様に、中間サーバ200にリクエストを送信し、中間サーバ200がリクエストに応じて送信したドキュメントを受信する。表示制御部310は、受信されたドキュメントを表示させる。このとき、ドキュメントにおいて参照されているリソースがキャッシュ380に格納されていなければ、リソース受信部308が中間サーバ200にリクエストを送信し、リクエストに応じて送信されたリソースを受信する。ここで受信されるリソースには、上記の画像トランスコード部228によって所定のフォーマットにトランスコードされた画像が含まれうる。表示制御部310は、キャッシュ380に格納されたリソース、またはリソース受信部308によって受信されたリソースを利用してドキュメントを表示させる。
クライアント300では、リクエスト送信部302およびドキュメント受信部304が、上記の第1の実施形態と同様に、中間サーバ200にリクエストを送信し、中間サーバ200がリクエストに応じて送信したドキュメントを受信する。表示制御部310は、受信されたドキュメントを表示させる。このとき、ドキュメントにおいて参照されているリソースがキャッシュ380に格納されていなければ、リソース受信部308が中間サーバ200にリクエストを送信し、リクエストに応じて送信されたリソースを受信する。ここで受信されるリソースには、上記の画像トランスコード部228によって所定のフォーマットにトランスコードされた画像が含まれうる。表示制御部310は、キャッシュ380に格納されたリソース、またはリソース受信部308によって受信されたリソースを利用してドキュメントを表示させる。
(8−2.処理フロー)
図21は、本開示の第7の実施形態に係る中間サーバの処理を示すフローチャートである。図21を参照すると、まず、リクエスト受信部202が、クライアント300からのリクエストを受信する(S701)。次に、ドキュメント取得部204が、リクエストにおいて指定されたドキュメントを取得する(S703)。次に、ドキュメント解析部206が、取得されたドキュメントを解析する(S705)。
図21は、本開示の第7の実施形態に係る中間サーバの処理を示すフローチャートである。図21を参照すると、まず、リクエスト受信部202が、クライアント300からのリクエストを受信する(S701)。次に、ドキュメント取得部204が、リクエストにおいて指定されたドキュメントを取得する(S703)。次に、ドキュメント解析部206が、取得されたドキュメントを解析する(S705)。
ここで、ドキュメントの解析において画像への参照が検出された場合(S707のYES)、まず、画像参照更新部230が、ドキュメントに含まれる画像リソースへの参照を、トランスコード後の画像への参照に更新する(S709)。図示された例では、この時点でまだ画像のトランスコードが実行されていないため、先にトランスコード後の画像のファイル名などの識別子が決定されることになる。決定された識別子は、ドキュメントの参照に記述されるとともに中間サーバ200のメモリに一時的に記憶され、後に生成されるトランスコードされた画像に関連付けられる。
次に、ドキュメント送信部214が、画像リソースへの参照が更新されたドキュメントをクライアント300に送信する(S711)。ドキュメントの送信後に、またはこれと並行して、リソース取得部208が参照されている画像を取得する(S713)。画像トランスコード部228は、取得された画像を所定のフォーマットにトランスコードする(S715)。なお、画像トランスコード部228は、トランスコードされた画像が既にキャッシュ280に格納されていれば、再度のトランスコードの処理を省略してもよい。その後、リソース送信部216が、クライアント300からリソースのリクエストに応じて、トランスコードされた画像を含むリソースをクライアント300に送信する(S717)。
上述のように、中間サーバ200の処理能力がクライアント300に比べて高い場合でも、画像のトランスコードにはある程度の時間がかかる。従って、上記の処理フローのように、トランスコード後の画像の識別子を先に決定しておき、画像への参照が更新されたドキュメントを先行して中間サーバ200からクライアント300に送信し、クライアント300でドキュメントが受信されて表示が開始されるのと並行して中間サーバ200で画像のトランスコードを実行することで、クライアント300でドキュメントの表示が完了するまでの時間を短縮することができる。
例えば、ドキュメントにおける画像の参照が少なかったり、参照された画像の多くが既にトランスコードされて中間サーバ200のキャッシュ280に格納されていたりするような場合には、画像トランスコード部228が画像のトランスコードを完了した後に、ドキュメント送信部214がドキュメントをクライアント300に送信してもよい。なお、いずれの場合も、クライアント300における処理は、参照されるリソースにトランスコードされた画像が含まれることを除けば、通常のドキュメントの表示のための処理と同様であるため詳細な説明は省略する。
(8−3.トランスコードの例)
次に、本実施形態における画像のトランスコードの例について、さらに説明する。
次に、本実施形態における画像のトランスコードの例について、さらに説明する。
通常、配信元サーバ100から取得されるリソースに含まれる画像は、例えばJPEGやPNG、GIFなど、多種多様なフォーマットで記述されている。しかも、画像がこれらのフォーマットに厳密には従っていない場合もしばしばである。それゆえ、配信元サーバ100から取得された画像(中間サーバ200またはクライアント300でキャッシュされたものを含む)をクライアント300でデコードするときには、様々なケースを想定する必要があるために処理を最適化することが難しく、処理の効率が必ずしも高くなかった。また、ドキュメントの表示のために中間サーバ200からクライアント300に転送されるデータの中では画像が大きな割合を占めることが多く、画像のデータ量を削減する需要も依然として高かった。
そこで、本実施形態では、中間サーバ200において画像をトランスコードする。例えば、中間サーバ200の画像トランスコード282が、配信元サーバ100から取得された画像をそれぞれのフォーマットの純正な形式にトランスコードするだけでも、クライアント300でのデコードをある程度最適化することが可能になり、ドキュメントの表示が高速化されうる。さらに、画像トランスコード282が、配信元サーバ100から取得された画像を、クライアント300でのデコード処理を最適化することが可能な1または複数の所定のフォーマットにトランスコードすれば、ドキュメントの表示のさらなる高速化が可能である。
(8−4.フォーマットの例)
次に、本実施形態における画像のトランスコードに適用することが可能な、画像のフォーマットの例について、さらに説明する。以下で説明する画像のフォーマットは、例えば本実施形態のような中間サーバにおけるトランスコードに組み合わせて実施されてもよいが、そのような例には限られず、画像フォーマットそれ自体として実施される場合にも様々な利点をもたらしうるものである。つまり、本開示の実施形態には、トランスコードとは独立した、画像のフォーマット(例えば当該フォーマットの画像を扱う画像処理装置または画像処理方法など)が含まれうる。
次に、本実施形態における画像のトランスコードに適用することが可能な、画像のフォーマットの例について、さらに説明する。以下で説明する画像のフォーマットは、例えば本実施形態のような中間サーバにおけるトランスコードに組み合わせて実施されてもよいが、そのような例には限られず、画像フォーマットそれ自体として実施される場合にも様々な利点をもたらしうるものである。つまり、本開示の実施形態には、トランスコードとは独立した、画像のフォーマット(例えば当該フォーマットの画像を扱う画像処理装置または画像処理方法など)が含まれうる。
図22および図23は、本開示の第7の実施形態で適用されうる画像フォーマットに従った画像ファイルの生成処理について説明するための図である。ここで説明される処理は、例えば上記の中間サーバ200の画像トランスコード部228によって実行されうる。
まず、図22に示されるように、ビットマップ形式(JPEGやPNG、GIFなどを含む)で記述された原画像700から、ベクター成分704と、ビットマップ成分706と、近似誤差708とが算出される。この処理では、まず、原画像700を2つの領域群702a,702bに分割する(S751)。領域群702aは、空間周波数が低く、かつ広い領域である。一方、領域群702bは、空間周波数が高く、かつ狭い領域である。領域の分割は、例えば分割統合(split-and-merge)法など、公知の各種の手法によって実現することが可能である。
領域群702aについては、S753〜S761の処理によってベクター成分704が生成される。まず、領域群702aに含まれる各領域についてエッジが抽出され、アウトラインがベジエ曲線で近似される(S753)。さらに、近似されたアウトライン内での色の勾配が求められる(S755)。ここで、色の勾配が比較的均一であれば(S757のYES)、頂点色を設定して単純補間によって領域の色が表現される(S759)。そうでなければ、領域の色がモデル化して表現される(S761)。モデルとしては、例えば3次元コンピュータグラフィックスのシェーディングモデルなどが適用されうる。シェーディングモデルでは、3次曲面と光源とを設定することで、スペキュラーなどを表現することができる。以上のような処理によって、領域群702aの各領域について、近似されたアウトラインとアウトライン内の色とを表現することによって、ベクター成分704を生成することができる。
一方、領域群702bの各領域については、画像として圧縮することによって(S763)、ビットマップ成分706が生成される。S763での画像の圧縮には、例えばDCT(Discrete Cosine Transform)やVQ(Vector Quantization)などの公知の技術が利用されうる。
さらに、領域群702aの領域ではベクター成分704と原画像700との差分、領域群702bの領域ではビットマップ成分706と原画像700との差分をそれぞれ算出することによって(S765)、ベクター成分704およびビットマップ成分706と原画像700との近似誤差708を得ることができる。
次に、図23に示されるように、ベクター成分704と、ビットマップ成分706と、近似誤差708とに基づいて、エンコードされた画像ファイル714が生成される。まず、ベクター成分704とビットマップ成分706とのそれぞれのバウンディングボックス(bbox)に基づいて原画像700の領域を分割し、当該分割を示すk−dツリー710を生成する(S767)。さらに、近似誤差708をk−dツリー710の領域分割線で振り分けることによって(S769)、近似誤差成分712を得ることができる。
このようにして得られたベクター成分704と、ビットマップ成分706と、k−dツリー710と、近似誤差成分712とをシリアライズすることによって(S771)、画像ファイル714が生成される。
画像ファイル714では、先頭にk−dツリー710が構造データとして記述される。これによって、描画したい領域の成分を迅速にシークすることができる。続いて、ベクター成分704、ビットマップ成分706、および近似誤差成分712が記述される。なお、k−dツリー710以外の成分については、画像ファイル714内での配列の順番は特に限定されない。
ベクター成分704では、各頂点データがbboxで正規化されている。従って、仮数部が必要とする有効桁数を削減し、データを圧縮することができる。また、近似誤差成分712については、誤差0の領域が大半であればrun−length圧縮が可能である。また、誤差があっても小規模な誤差に分布が集中するはずであるため、LZWなどのアルゴリズムを用いて圧縮することができる。
ベクター成分704は、例えば、ベジエ曲線で囲まれた領域を単色でべた塗りすることを表現する。以下に、ベクター成分704の記述内容の一例を示す。なお、例は説明のために記述内容をPostScript形式で表現しているが、実際のベクター成分704は、例えばバイナリエンコードされた上で圧縮される。
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
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
ビットマップ成分706は、例えば、矩形領域にビットマップパターンを適用することを表現する。以下に、ビットマップ成分706の記述内容の一例を示す。なお、例は説明のために記述内容をPostScript形式で表現しているが、実際のビットマップ成分706は、例えばバイナリエンコードされた上で圧縮される。なお、xxxx piximageはFill patternとして用いられるビットマップを示す。
newpath
100 100 moveto
100 0 rlineto
0 100 rlineto
-100 0 rlineto
closepath
xxxx piximage
fill
newpath
100 100 moveto
100 0 rlineto
0 100 rlineto
-100 0 rlineto
closepath
xxxx piximage
fill
(8−5.デコード処理の例)
次に、上記の例における画像ファイル714を、クライアント300においてデコードするときの処理の例について説明する。
次に、上記の例における画像ファイル714を、クライアント300においてデコードするときの処理の例について説明する。
(ダウンロード完了後にデコードする場合)
まず、ダウンロード完了後にデコードする場合の処理について説明する。この場合、クライアント300の表示制御部310は、画像ファイル714に含まれるベクター成分704を順に描画する。この例では、パスに重複がある場合は、後から描画されたベクター成分704のパスが優先される。
まず、ダウンロード完了後にデコードする場合の処理について説明する。この場合、クライアント300の表示制御部310は、画像ファイル714に含まれるベクター成分704を順に描画する。この例では、パスに重複がある場合は、後から描画されたベクター成分704のパスが優先される。
次に、表示制御部310は、画像ファイル714に含まれるビットマップ成分706を順に描画する。このとき、ビットマップ成分706による描画は、ベクター成分704による描画に上書きされる。また、ビットマップ成分706の間でパスに重複がある場合は、後から描画されたビットマップ成分706のパスが優先される。
次に、表示制御部310は、各領域の画像に近似誤差成分712を足し合わせる。近似誤差成分712は、例えば、RGBA(Red Green Blue Alpha)のそれぞれについて足し合わされてもよい。
(ダウンロード途中で描画する場合)
ダウンロード途中で描画する場合、第1の例として、クライアント300の表示制御部310は、画像ファイル714のダウンロードの進捗に合わせて、ベクター成分704、ビットマップ成分706、および近似誤差成分712の順で描画する。これによって、まず広い範囲の色が確定し、その後段階的に画像が詳細化されているような表示が可能になる。
ダウンロード途中で描画する場合、第1の例として、クライアント300の表示制御部310は、画像ファイル714のダウンロードの進捗に合わせて、ベクター成分704、ビットマップ成分706、および近似誤差成分712の順で描画する。これによって、まず広い範囲の色が確定し、その後段階的に画像が詳細化されているような表示が可能になる。
また、第2の例として、クライアント300の表示制御部310は、まず画像ファイル714の先頭にあるk−dツリー710をダウンロードする。表示制御部310は、k−dツリー710から、特定の領域に該当するベクター成分704、ビットマップ成分706、および近似誤差成分712へのポインタ情報を得ることができる。そこで、表示制御部310は、ファイルシークまたはHTTPレンジリクエストなどを利用して、上記のポインタ情報によって参照されるベクター成分704、ビットマップ成分706、および近似誤差成分712をダウンロードする。ダウンロードされたデータを用いて、表示制御部310は、上記特定の範囲をベクター成分704、ビットマップ成分706、および近似誤差成分712の順に描画し、当該領域についてのデコードを終了する。
以上で説明した本実施形態によれば、例えば、ドキュメントにおいて参照される画像のファイルサイズを削減することによって、通信容量を削減することができる。また、画像が単純なグラデーションや単色での塗りつぶしを含むような場合には、これらの部分をトランスコーディングによってベクター化することによって、デコード処理を高速化することができる。
(9.ハードウェア構成)
次に、図24を参照して、本開示の実施形態に係る情報処理装置のハードウェア構成について説明する。図24は、本開示の実施形態に係る情報処理装置のハードウェア構成例を説明するためのブロック図である。図示された情報処理装置900は、例えば、上記の実施形態におけるサーバおよびクライアントを実現しうる。
次に、図24を参照して、本開示の実施形態に係る情報処理装置のハードウェア構成について説明する。図24は、本開示の実施形態に係る情報処理装置のハードウェア構成例を説明するためのブロック図である。図示された情報処理装置900は、例えば、上記の実施形態におけるサーバおよびクライアントを実現しうる。
情報処理装置900は、CPU(Central Processing unit)901、ROM(Read Only Memory)903、およびRAM(Random Access Memory)905を含む。また、情報処理装置900は、ホストバス907、ブリッジ909、外部バス911、インターフェース913、入力装置915、出力装置917、ストレージ装置919、ドライブ921、接続ポート923、通信装置925を含んでもよい。さらに、情報処理装置900は、必要に応じて、撮像装置933、およびセンサ935を含んでもよい。情報処理装置900は、CPU901に代えて、またはこれとともに、DSP(Digital Signal Processor)またはASIC(Application Specific Integrated Circuit)と呼ばれるような処理回路を有してもよい。
CPU901は、演算処理装置および制御装置として機能し、ROM903、RAM905、ストレージ装置919、またはリムーバブル記録媒体927に記録された各種プログラムに従って、情報処理装置900内の動作全般またはその一部を制御する。ROM903は、CPU901が使用するプログラムや演算パラメータなどを記憶する。RAM905は、CPU901の実行において使用するプログラムや、その実行において適宜変化するパラメータなどを一次記憶する。CPU901、ROM903、およびRAM905は、CPUバスなどの内部バスにより構成されるホストバス907により相互に接続されている。さらに、ホストバス907は、ブリッジ909を介して、PCI(Peripheral Component Interconnect/Interface)バスなどの外部バス911に接続されている。
入力装置915は、例えば、マウス、キーボード、タッチパネル、ボタン、スイッチおよびレバーなど、ユーザによって操作される装置である。入力装置915は、例えば、赤外線やその他の電波を利用したリモートコントロール装置であってもよいし、情報処理装置900の操作に対応した携帯電話などの外部接続機器929であってもよい。入力装置915は、ユーザが入力した情報に基づいて入力信号を生成してCPU901に出力する入力制御回路を含む。ユーザは、この入力装置915を操作することによって、情報処理装置900に対して各種のデータを入力したり処理動作を指示したりする。
出力装置917は、取得した情報をユーザに対して視覚的または聴覚的に通知することが可能な装置で構成される。出力装置917は、例えば、LCD(Liquid Crystal Display)、PDP(Plasma Display Panel)、有機EL(Electro-Luminescence)ディスプレイなどの表示装置、スピーカおよびヘッドホンなどの音声出力装置、ならびにプリンタ装置などでありうる。出力装置917は、情報処理装置900の処理により得られた結果を、テキストまたは画像などの映像として出力したり、音声または音響などの音声として出力したりする。
ストレージ装置919は、情報処理装置900の記憶部の一例として構成されたデータ格納用の装置である。ストレージ装置919は、例えば、HDD(Hard Disk Drive)などの磁気記憶部デバイス、半導体記憶デバイス、光記憶デバイス、または光磁気記憶デバイスなどにより構成される。このストレージ装置919は、CPU901が実行するプログラムや各種データ、および外部から取得した各種のデータなどを格納する。
ドライブ921は、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリなどのリムーバブル記録媒体927のためのリーダライタであり、情報処理装置900に内蔵、あるいは外付けされる。ドライブ921は、装着されているリムーバブル記録媒体927に記録されている情報を読み出して、RAM905に出力する。また、ドライブ921は、装着されているリムーバブル記録媒体927に記録を書き込む。
接続ポート923は、機器を情報処理装置900に直接接続するためのポートである。接続ポート923は、例えば、USB(Universal Serial Bus)ポート、IEEE1394ポート、SCSI(Small Computer System Interface)ポートなどでありうる。また、接続ポート923は、RS−232Cポート、光オーディオ端子、HDMI(High-Definition Multimedia Interface)ポートなどであってもよい。接続ポート923に外部接続機器929を接続することで、情報処理装置900と外部接続機器929との間で各種のデータが交換されうる。
通信装置925は、例えば、通信ネットワーク931に接続するための通信デバイスなどで構成された通信インターフェースである。通信装置925は、例えば、有線または無線LAN(Local Area Network)、Bluetooth(登録商標)、またはWUSB(Wireless USB)用の通信カードなどでありうる。また、通信装置925は、光通信用のルータ、ADSL(Asymmetric Digital Subscriber Line)用のルータ、または、各種通信用のモデムなどであってもよい。通信装置925は、例えば、インターネットや他の通信機器との間で、TCP/IPなどの所定のプロトコルを用いて信号などを送受信する。また、通信装置925に接続される通信ネットワーク931は、有線または無線によって接続されたネットワークであり、例えば、インターネット、家庭内LAN、赤外線通信、ラジオ波通信または衛星通信などである。
撮像装置933は、例えば、CCD(Charge Coupled Device)またはCMOS(Complementary Metal Oxide Semiconductor)などの撮像素子、および撮像素子への被写体像の結像を制御するためのレンズなどの各種の部材を用いて実空間を撮像し、撮像画像を生成する装置である。撮像装置933は、静止画を撮像するものであってもよいし、また動画を撮像するものであってもよい。
センサ935は、例えば、加速度センサ、ジャイロセンサ、地磁気センサ、光センサ、音センサなどの各種のセンサである。センサ935は、例えば情報処理装置900の筐体の姿勢など、情報処理装置900自体の状態に関する情報や、情報処理装置900の周辺の明るさや騒音など、情報処理装置900の周辺環境に関する情報を取得する。また、センサ935は、GPS(Global Positioning System)信号を受信して装置の緯度、経度および高度を測定するGPSセンサを含んでもよい。
以上、情報処理装置900のハードウェア構成の一例を示した。上記の各構成要素は、汎用的な部材を用いて構成されていてもよいし、各構成要素の機能に特化したハードウェアにより構成されていてもよい。かかる構成は、実施する時々の技術レベルに応じて適宜変更されうる。
(10.補足)
本開示の実施形態は、例えば、上記で説明したような情報処理装置(サーバ装置またはクライアント装置)、システム、情報処理装置またはシステムで実行される情報処理方法、情報処理装置を機能させるためのプログラム、およびプログラムが記録された一時的でない有形の媒体を含みうる。なお、上記で説明された複数の実施形態は、特に組み合わせが可能であることが明示されていなくても、本明細書の記載から当業者に自明な範囲で任意に組み合わせて実現することができる。
本開示の実施形態は、例えば、上記で説明したような情報処理装置(サーバ装置またはクライアント装置)、システム、情報処理装置またはシステムで実行される情報処理方法、情報処理装置を機能させるためのプログラム、およびプログラムが記録された一時的でない有形の媒体を含みうる。なお、上記で説明された複数の実施形態は、特に組み合わせが可能であることが明示されていなくても、本明細書の記載から当業者に自明な範囲で任意に組み合わせて実現することができる。
以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
なお、以下のような構成も本開示の技術的範囲に属する。
(1)クライアントからのリクエストに応じて、リソースへの参照を含むドキュメントを取得するドキュメント取得部と、
前記リソースを取得するリソース取得部と、
前記ドキュメントおよび前記リソースのそれぞれに含まれる文字列について短縮された文字列を生成するとともに、前記文字列と前記短縮された文字列とを関連付けるレコードを追加する短縮文字列生成部と、
前記ドキュメントおよび前記リソースにおいて、前記文字列を前記短縮された文字列に置換する短縮文字列記述部と、
前記短縮された文字列を含む前記ドキュメントを前記クライアントに送信するドキュメント送信部と、
前記短縮された文字列を含む前記リソースを前記クライアントに送信するリソース送信部と
を備えるサーバ装置。
(2)前記レコードに基づいて生成された前記文字列と前記短縮された文字列との関連付け情報を前記クライアントに送信する関連付け情報送信部をさらに備える、前記(1)に記載のサーバ装置。
(3)前記関連付け情報は、前記レコードの少なくとも一部を含まない、前記(2)に記載のサーバ装置。
(4)前記レコードには前記ドキュメントまたは前記リソースにおける予約語に関する情報が含まれ、前記関連付け情報には前記予約語に関する情報が含まれない、前記(3)に記載のサーバ装置。
(5)前記短縮文字列記述部は、前記ドキュメントに含まれる文字列を前記短縮された文字列に置換した後に、前記ドキュメントについて生成されたレコードに従って前記リソースに含まれる文字列を前記短縮された文字列に置換する、前記(1)〜(4)のいずれか1項に記載のサーバ装置。
(6)前記短縮文字列記述部は、前記ドキュメントが前記クライアントに送信された後に、前記リソースに含まれる文字列を前記短縮された文字列に置換する、前記(5)に記載のサーバ装置。
(7)前記短縮文字列生成部は、前記文字列に基づいて所定の演算を実行することによって前記短縮された文字列を生成する、前記(1)〜(6)のいずれか1項に記載のサーバ装置。
(8)サーバにリクエストを送信するリクエスト送信部と、
前記リクエストに応じて前記サーバから送信された、リソースへの参照を含むドキュメントを受信するドキュメント受信部と、
前記リソースを受信するリソース受信部と、
前記ドキュメントおよび前記リソースに含まれる短縮された文字列と、前記短縮された文字列に対応する文字列との関連付け情報を受信する関連付け情報受信部と、
前記関連付け情報に従って前記ドキュメントおよび前記リソースを解釈する文字列解釈部と
を備えるクライアント装置。
(9)前記リソース受信部は、前記ドキュメントおよび前記関連付け情報が受信された後に前記リソースを受信する、前記(8)に記載のクライアント装置。
(10)前記文字列解釈部は、前記短縮された文字列の一部を、前記関連付け情報によらずに解釈する、前記(8)または(9)に記載のクライアント装置。
(11)前記短縮された文字列の一部は、前記ドキュメントまたは前記リソースにおける予約語として解釈される、前記(10)に記載のクライアント装置。
(12)クライアントからのリクエストに応じて、リソースへの参照を含むドキュメントを取得することと、
前記リソースを取得することと、
前記ドキュメントおよび前記リソースのそれぞれに含まれる文字列について短縮された文字列を生成するとともに、前記文字列と前記短縮された文字列とを関連付けるレコードを追加することと、
前記ドキュメントおよび前記リソースにおいて、前記文字列を前記短縮された文字列に置換することと、
前記短縮された文字列を含む前記ドキュメントを前記クライアントに送信することと、
前記短縮された文字列を含む前記リソースを前記クライアントに送信することと
を含む情報処理方法。
(13)サーバにリクエストを送信する機能と、
前記リクエストに応じて前記サーバから送信された、リソースへの参照を含むドキュメントを受信する機能と、
前記リソースを受信する機能と、
前記ドキュメントおよび前記リソースに含まれる短縮された文字列と、前記短縮された文字列に対応する文字列との関連付け情報を受信する機能と、
前記関連付け情報に従って前記ドキュメントおよび前記リソースを解釈する機能と
をコンピュータに実現させるためのプログラムが記録された一時的でない有形の記録媒体。
(1)クライアントからのリクエストに応じて、リソースへの参照を含むドキュメントを取得するドキュメント取得部と、
前記リソースを取得するリソース取得部と、
前記ドキュメントおよび前記リソースのそれぞれに含まれる文字列について短縮された文字列を生成するとともに、前記文字列と前記短縮された文字列とを関連付けるレコードを追加する短縮文字列生成部と、
前記ドキュメントおよび前記リソースにおいて、前記文字列を前記短縮された文字列に置換する短縮文字列記述部と、
前記短縮された文字列を含む前記ドキュメントを前記クライアントに送信するドキュメント送信部と、
前記短縮された文字列を含む前記リソースを前記クライアントに送信するリソース送信部と
を備えるサーバ装置。
(2)前記レコードに基づいて生成された前記文字列と前記短縮された文字列との関連付け情報を前記クライアントに送信する関連付け情報送信部をさらに備える、前記(1)に記載のサーバ装置。
(3)前記関連付け情報は、前記レコードの少なくとも一部を含まない、前記(2)に記載のサーバ装置。
(4)前記レコードには前記ドキュメントまたは前記リソースにおける予約語に関する情報が含まれ、前記関連付け情報には前記予約語に関する情報が含まれない、前記(3)に記載のサーバ装置。
(5)前記短縮文字列記述部は、前記ドキュメントに含まれる文字列を前記短縮された文字列に置換した後に、前記ドキュメントについて生成されたレコードに従って前記リソースに含まれる文字列を前記短縮された文字列に置換する、前記(1)〜(4)のいずれか1項に記載のサーバ装置。
(6)前記短縮文字列記述部は、前記ドキュメントが前記クライアントに送信された後に、前記リソースに含まれる文字列を前記短縮された文字列に置換する、前記(5)に記載のサーバ装置。
(7)前記短縮文字列生成部は、前記文字列に基づいて所定の演算を実行することによって前記短縮された文字列を生成する、前記(1)〜(6)のいずれか1項に記載のサーバ装置。
(8)サーバにリクエストを送信するリクエスト送信部と、
前記リクエストに応じて前記サーバから送信された、リソースへの参照を含むドキュメントを受信するドキュメント受信部と、
前記リソースを受信するリソース受信部と、
前記ドキュメントおよび前記リソースに含まれる短縮された文字列と、前記短縮された文字列に対応する文字列との関連付け情報を受信する関連付け情報受信部と、
前記関連付け情報に従って前記ドキュメントおよび前記リソースを解釈する文字列解釈部と
を備えるクライアント装置。
(9)前記リソース受信部は、前記ドキュメントおよび前記関連付け情報が受信された後に前記リソースを受信する、前記(8)に記載のクライアント装置。
(10)前記文字列解釈部は、前記短縮された文字列の一部を、前記関連付け情報によらずに解釈する、前記(8)または(9)に記載のクライアント装置。
(11)前記短縮された文字列の一部は、前記ドキュメントまたは前記リソースにおける予約語として解釈される、前記(10)に記載のクライアント装置。
(12)クライアントからのリクエストに応じて、リソースへの参照を含むドキュメントを取得することと、
前記リソースを取得することと、
前記ドキュメントおよび前記リソースのそれぞれに含まれる文字列について短縮された文字列を生成するとともに、前記文字列と前記短縮された文字列とを関連付けるレコードを追加することと、
前記ドキュメントおよび前記リソースにおいて、前記文字列を前記短縮された文字列に置換することと、
前記短縮された文字列を含む前記ドキュメントを前記クライアントに送信することと、
前記短縮された文字列を含む前記リソースを前記クライアントに送信することと
を含む情報処理方法。
(13)サーバにリクエストを送信する機能と、
前記リクエストに応じて前記サーバから送信された、リソースへの参照を含むドキュメントを受信する機能と、
前記リソースを受信する機能と、
前記ドキュメントおよび前記リソースに含まれる短縮された文字列と、前記短縮された文字列に対応する文字列との関連付け情報を受信する機能と、
前記関連付け情報に従って前記ドキュメントおよび前記リソースを解釈する機能と
をコンピュータに実現させるためのプログラムが記録された一時的でない有形の記録媒体。
10 システム
100 配信サーバ
200 中間サーバ
202 リクエスト受信部
204 ドキュメント取得部
206 ドキュメント解析部
208 リソース取得部
210 識別子生成部
212 識別子記述部
214 ドキュメント送信部
216 リソース送信部
218 リソース先行配信部
220 リソース解析部
222 短縮文字列生成部
224 短縮文字列記述部
226 関連付け情報送信部
228 画像トランスコード部
230 画像参照更新部
280 キャッシュ
282 データベース
300 クライアント
302 リクエスト送信部
304 ドキュメント受信部
306 キャッシュ判定部
308 リソース受信部
310 表示制御部
312 リソース先行受信部
314 関連付け情報受信部
316 文字列解釈部
380 キャッシュ
382 データベース
100 配信サーバ
200 中間サーバ
202 リクエスト受信部
204 ドキュメント取得部
206 ドキュメント解析部
208 リソース取得部
210 識別子生成部
212 識別子記述部
214 ドキュメント送信部
216 リソース送信部
218 リソース先行配信部
220 リソース解析部
222 短縮文字列生成部
224 短縮文字列記述部
226 関連付け情報送信部
228 画像トランスコード部
230 画像参照更新部
280 キャッシュ
282 データベース
300 クライアント
302 リクエスト送信部
304 ドキュメント受信部
306 キャッシュ判定部
308 リソース受信部
310 表示制御部
312 リソース先行受信部
314 関連付け情報受信部
316 文字列解釈部
380 キャッシュ
382 データベース
Claims (13)
- クライアントからのリクエストに応じて、リソースへの参照を含むドキュメントを取得するドキュメント取得部と、
前記リソースを取得するリソース取得部と、
前記ドキュメントおよび前記リソースのそれぞれに含まれる文字列について短縮された文字列を生成するとともに、前記文字列と前記短縮された文字列とを関連付けるレコードを追加する短縮文字列生成部と、
前記ドキュメントおよび前記リソースにおいて、前記文字列を前記短縮された文字列に置換する短縮文字列記述部と、
前記短縮された文字列を含む前記ドキュメントを前記クライアントに送信するドキュメント送信部と、
前記短縮された文字列を含む前記リソースを前記クライアントに送信するリソース送信部と
を備えるサーバ装置。 - 前記レコードに基づいて生成された前記文字列と前記短縮された文字列との関連付け情報を前記クライアントに送信する関連付け情報送信部をさらに備える、請求項1に記載のサーバ装置。
- 前記関連付け情報は、前記レコードの少なくとも一部を含まない、請求項2に記載のサーバ装置。
- 前記レコードには前記ドキュメントまたは前記リソースにおける予約語に関する情報が含まれ、前記関連付け情報には前記予約語に関する情報が含まれない、請求項3に記載のサーバ装置。
- 前記短縮文字列記述部は、前記ドキュメントに含まれる文字列を前記短縮された文字列に置換した後に、前記ドキュメントについて生成されたレコードに従って前記リソースに含まれる文字列を前記短縮された文字列に置換する、請求項1〜4のいずれか1項に記載のサーバ装置。
- 前記短縮文字列記述部は、前記ドキュメントが前記クライアントに送信された後に、前記リソースに含まれる文字列を前記短縮された文字列に置換する、請求項5に記載のサーバ装置。
- 前記短縮文字列生成部は、前記文字列に基づいて所定の演算を実行することによって前記短縮された文字列を生成する、請求項1〜6のいずれか1項に記載のサーバ装置。
- サーバにリクエストを送信するリクエスト送信部と、
前記リクエストに応じて前記サーバから送信された、リソースへの参照を含むドキュメントを受信するドキュメント受信部と、
前記リソースを受信するリソース受信部と、
前記ドキュメントおよび前記リソースに含まれる短縮された文字列と、前記短縮された文字列に対応する文字列との関連付け情報を受信する関連付け情報受信部と、
前記関連付け情報に従って前記ドキュメントおよび前記リソースを解釈する文字列解釈部と
を備えるクライアント装置。 - 前記リソース受信部は、前記ドキュメントおよび前記関連付け情報が受信された後に前記リソースを受信する、請求項8に記載のクライアント装置。
- 前記文字列解釈部は、前記短縮された文字列の一部を、前記関連付け情報によらずに解釈する、請求項8または9に記載のクライアント装置。
- 前記短縮された文字列の一部は、前記ドキュメントまたは前記リソースにおける予約語として解釈される、請求項10に記載のクライアント装置。
- クライアントからのリクエストに応じて、リソースへの参照を含むドキュメントを取得することと、
前記リソースを取得することと、
前記ドキュメントおよび前記リソースのそれぞれに含まれる文字列について短縮された文字列を生成するとともに、前記文字列と前記短縮された文字列とを関連付けるレコードを追加することと、
前記ドキュメントおよび前記リソースにおいて、前記文字列を前記短縮された文字列に置換することと、
前記短縮された文字列を含む前記ドキュメントを前記クライアントに送信することと、
前記短縮された文字列を含む前記リソースを前記クライアントに送信することと
を含む情報処理方法。 - サーバにリクエストを送信する機能と、
前記リクエストに応じて前記サーバから送信された、リソースへの参照を含むドキュメントを受信する機能と、
前記リソースを受信する機能と、
前記ドキュメントおよび前記リソースに含まれる短縮された文字列と、前記短縮された文字列に対応する文字列との関連付け情報を受信する機能と、
前記関連付け情報に従って前記ドキュメントおよび前記リソースを解釈する機能と
をコンピュータに実現させるためのプログラムが記録された一時的でない有形の記録媒体。
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2013211281 | 2013-10-08 | ||
JP2013211281 | 2013-10-08 | ||
JP2013244017 | 2013-11-26 | ||
JP2013244017 | 2013-11-26 | ||
PCT/JP2014/067695 WO2015052967A1 (ja) | 2013-10-08 | 2014-07-02 | サーバ装置、クライアント装置、情報処理方法および記録媒体 |
Publications (1)
Publication Number | Publication Date |
---|---|
JPWO2015052967A1 true JPWO2015052967A1 (ja) | 2017-03-09 |
Family
ID=52812788
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2015541455A Pending JPWO2015052967A1 (ja) | 2013-10-08 | 2014-07-02 | サーバ装置、クライアント装置、情報処理方法および記録媒体 |
Country Status (6)
Country | Link |
---|---|
US (1) | US10282403B2 (ja) |
EP (1) | EP3056997A4 (ja) |
JP (1) | JPWO2015052967A1 (ja) |
CN (1) | CN105593831A (ja) |
BR (1) | BR112016007270A2 (ja) |
WO (1) | WO2015052967A1 (ja) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10380247B2 (en) | 2016-10-28 | 2019-08-13 | Microsoft Technology Licensing, Llc | Language-based acronym generation for strings |
CN112434231B (zh) * | 2020-11-05 | 2023-09-08 | 北京奇艺世纪科技有限公司 | 一种数据处理方法、装置及电子设备 |
CN114329262B (zh) * | 2021-12-20 | 2022-07-26 | 江苏云工场信息技术有限公司 | 一种基于cdn的动态文档生成方法及装置 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002073451A (ja) * | 2000-08-24 | 2002-03-12 | Tenik Kk | モバイルシステム、サーバからクライアントへhtmlフアイルを送信する方法及びその装置 |
JP2007272740A (ja) * | 2006-03-31 | 2007-10-18 | Ntt Docomo Inc | 展開装置、圧縮通信システム及び圧縮通信方法 |
US20130173782A1 (en) * | 2011-12-29 | 2013-07-04 | Israel Ragutski | Method and system for ensuring authenticity of ip data served by a service provider |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6578078B1 (en) * | 1999-04-02 | 2003-06-10 | Microsoft Corporation | Method for preserving referential integrity within web sites |
JP2004310490A (ja) | 2003-04-08 | 2004-11-04 | I-Accele Corp | インターネットアクセス高速化システム |
US20070055931A1 (en) | 2003-05-14 | 2007-03-08 | Hiroaki Zaima | Document data output device capable of appropriately outputting document data containing a text and layout information |
JP2004362538A (ja) | 2003-05-14 | 2004-12-24 | Sharp Corp | 文書データ変換装置、携帯電話装置、文書データ変換方法、文書データ変換プログラム、および文書データ変換プログラムを記録したコンピュータ読取可能な記録媒体 |
US7698269B2 (en) * | 2005-11-29 | 2010-04-13 | Yahoo! Inc. | URL shortening and authentication with reverse hash lookup |
US7808975B2 (en) * | 2005-12-05 | 2010-10-05 | International Business Machines Corporation | System and method for history driven optimization of web services communication |
JP2009128945A (ja) | 2007-11-19 | 2009-06-11 | Canon Inc | データ処理装置及び方法並びにプログラム |
JP2011108102A (ja) | 2009-11-19 | 2011-06-02 | Sony Corp | ウェブサーバ、ウェブブラウザおよびウェブシステム |
US8346920B2 (en) * | 2010-07-15 | 2013-01-01 | Srr Patent Holdings, Llc | Managing network resource requests |
WO2012016034A1 (en) * | 2010-07-28 | 2012-02-02 | Openwave Systems Inc. | System and method for providing network resource identifier shortening service to computing devices |
-
2014
- 2014-07-02 CN CN201480054819.4A patent/CN105593831A/zh active Pending
- 2014-07-02 US US15/026,805 patent/US10282403B2/en active Active
- 2014-07-02 WO PCT/JP2014/067695 patent/WO2015052967A1/ja active Application Filing
- 2014-07-02 BR BR112016007270A patent/BR112016007270A2/pt not_active IP Right Cessation
- 2014-07-02 EP EP14853046.2A patent/EP3056997A4/en not_active Ceased
- 2014-07-02 JP JP2015541455A patent/JPWO2015052967A1/ja active Pending
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002073451A (ja) * | 2000-08-24 | 2002-03-12 | Tenik Kk | モバイルシステム、サーバからクライアントへhtmlフアイルを送信する方法及びその装置 |
JP2007272740A (ja) * | 2006-03-31 | 2007-10-18 | Ntt Docomo Inc | 展開装置、圧縮通信システム及び圧縮通信方法 |
US20130173782A1 (en) * | 2011-12-29 | 2013-07-04 | Israel Ragutski | Method and system for ensuring authenticity of ip data served by a service provider |
Also Published As
Publication number | Publication date |
---|---|
WO2015052967A1 (ja) | 2015-04-16 |
EP3056997A4 (en) | 2017-04-19 |
BR112016007270A2 (pt) | 2017-08-01 |
EP3056997A1 (en) | 2016-08-17 |
CN105593831A (zh) | 2016-05-18 |
US10282403B2 (en) | 2019-05-07 |
US20160217115A1 (en) | 2016-07-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109947512B (zh) | 一种文本适配显示方法、装置、服务器及存储介质 | |
US10360694B2 (en) | Methods and devices for image loading and methods and devices for video playback | |
WO2010037168A1 (en) | Systems, methods, and computer readable media for providing applications style functionality to a user | |
CN109785939A (zh) | 基于云技术的医学影像显示方法、装置、设备及存储介质 | |
US9286228B2 (en) | Facilitating caching in an image-processing system | |
US20150067037A1 (en) | Communication apparatus and communication method | |
KR101568947B1 (ko) | 폰트 파일을 다운로드하는 방법 및 시스템 | |
WO2015052967A1 (ja) | サーバ装置、クライアント装置、情報処理方法および記録媒体 | |
JP6323461B2 (ja) | サーバ装置、クライアント装置、情報処理方法および記録媒体 | |
CN109254954B (zh) | 文件处理方法和装置、计算设备及存储介质 | |
KR101334589B1 (ko) | 전자문서 레이아웃 유지를 위한 폰트처리 방법 및 이를 위한 프로그램을 기록한 컴퓨터로 판독가능한 기록매체 | |
CN109933735B (zh) | 调度方法、网页渲染方法、网页显示方法及其设备 | |
KR20140133125A (ko) | 클라이언트에서 서버가 제공하는 웹 페이지를 브라우즈하는 방법 및 이를 위한 장치 | |
CN106548010B (zh) | 一种dicom影像远程浏览的方法及装置 | |
RU2634221C2 (ru) | Способ и устройство для отрисовки представления электронного документа на экране | |
CN114244912B (zh) | 数据传输方法、装置、计算机设备及存储介质 | |
CN106933826B (zh) | 数据预处理方法及装置 | |
JP4697979B2 (ja) | グラフィック命令送信装置及びグラフィック命令送信方法 | |
US10699059B2 (en) | Character updating method and apparatus | |
CN116244580A (zh) | 基于模型的数据预测方法、模型生成方法、装置及产品 | |
JP5894320B1 (ja) | 情報処理装置及び情報処理プログラム | |
JP6607805B2 (ja) | 情報処理装置及び情報処理プログラム | |
CN117692706A (zh) | 一种视频处理方法、装置、设备、可读存储介质及产品 | |
CN114936192A (zh) | 一种文件动态压缩混淆和双向缓存方法及*** | |
CN116974984A (zh) | 私有云产品文档的处理方法、装置、计算机设备 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20170510 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20180313 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20180911 |