JP5316338B2 - 情報処理装置、データ取得方法及びプログラム - Google Patents
情報処理装置、データ取得方法及びプログラム Download PDFInfo
- Publication number
- JP5316338B2 JP5316338B2 JP2009216286A JP2009216286A JP5316338B2 JP 5316338 B2 JP5316338 B2 JP 5316338B2 JP 2009216286 A JP2009216286 A JP 2009216286A JP 2009216286 A JP2009216286 A JP 2009216286A JP 5316338 B2 JP5316338 B2 JP 5316338B2
- Authority
- JP
- Japan
- Prior art keywords
- display control
- unit
- data
- link destination
- display
- 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.)
- Expired - Fee Related
Links
Images
Classifications
-
- 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/957—Browsing optimisation, e.g. caching or content distillation
- G06F16/9577—Optimising the visualization of content, e.g. distillation of HTML documents
-
- 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/957—Browsing optimisation, e.g. caching or content distillation
- G06F16/9574—Browsing optimisation, e.g. caching or content distillation of access to content, e.g. by caching
Description
本発明は、情報処理装置、データ取得方法及びプログラムに関する。
情報通信技術の発展に伴い、ネットワークの広帯域化が進んでいる。そのため、インターネット等の広域ネットワークを介して伝送されるコンテンツも大容量化してきている。また、広域ネットワーク上で公開されているホームページの多くには、スクリプト処理の実行プログラムが組み込まれており、ホームページ上で動的な処理が行えるよう、ページ構成に工夫が凝らされている。しかし、大容量のコンテンツを読み込んだり、スクリプト処理を実行したりすると、ホームページが完全に表示されるまでに長い時間がかかってしまう。こうした問題に鑑み、ホームページ等、広域ネットワーク上で公開されている情報（以下、ＷＷＷ情報）を予めキャッシュしておき、ユーザからアクセスが要求された場合に予めキャッシュしておいたＷＷＷ情報を表示する技術が開発された。この技術に関し、下記の特許文献１には、効率的にＷＷＷ情報をキャッシュする方法が開示されている。
しかしながら、予めキャッシュしておくＷＷＷ情報を適切に選択するのは難しい。例えば、表示されているページに記載されたリンク先のＷＷＷ情報を全てキャッシュしようとすると、リンク先が多い場合にはＷＷＷ情報の取得自体に長い時間がかかってしまう。また、キャッシュメモリの容量を多く消費してしまう。さらに、キャッシュしようとするＷＷＷ情報を取得するために通信帯域の大部分が占有されてしまう。こうした理由から、ページを素早く表示するためには、単にＷＷＷ情報をキャッシュするだけでなく、ＷＷＷ情報の取得方法に更なる工夫を凝らす必要がある。
ＷＷＷ情報には、ページの表示制御を行うための情報（以下、表示制御情報）が含まれる。また、表示制御情報の中には、ページのレイアウトを規定する情報（以下、レイアウト情報）やクライアント端末にスクリプト処理を実行させるための情報（以下、スクリプト情報）等が含まれる。但し、上記のレイアウト情報やスクリプト情報は、上記の表示制御情報とは別のデータとして扱われることもある。この場合、表示制御情報とレイアウト情報との紐付け情報、及び表示制御情報とスクリプト情報との紐付け情報が、表示制御情報に含まれる。そのため、実質的にレイアウト情報やスクリプト情報が表示制御情報に含まれていることになる。
上記の表示制御情報は、例えば、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）やＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）等の構造化言語により記述されることが多い。これらの構造化言語は、タグを用いて構造単位を定義する記述方式を採用している。そのため、表示制御情報は、タグで囲まれた部分を構造単位として構造化されている。また、上記のレイアウト情報は、ＣＳＳ（Ｃａｓｃａｄｉｎｇ Ｓｔｙｌｅ Ｓｈｅｅｔｓ）等のスタイルシートにより表現されることが多い。さらに、上記のスクリプト情報は、ＪａｖａＳｃｒｉｐｔ（登録商標；以下、ＪＳと表記）、ＥＣＭＡＳｃｒｉｐｔ、ＶＢＳｃｒｉｐｔ（登録商標）等のスクリプト言語により記述されることが多い。
このように、表示制御情報は、（１）レイアウト情報やスクリプト情報を含み、（２）所定の構造単位を基準に構造化されている。通常、ＷＷＷブラウザ等によりＷＷＷ情報を表示する際、表示制御情報が解析され、表示制御情報に含まれる構造単位を基準として表示処理の実行順序やデータの取得順序が決定される。次いで、ＷＷＷブラウザ等により構造単位が相互に紐付けられてＤＯＭ（Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）と呼ばれる表示制御用の構造化データが生成される。次いで、ＷＷＷブラウザ等により生成されたＤＯＭに基づいてデータの取得やデータの表示等が実行される（図１を参照）。
ＤＯＭを構築する際、表示制御情報にスクリプト情報が含まれていると、スクリプト処理の逐次性に起因してデータの取得が遅延したり、表示処理に遅延が発生してしまう。そのため、広域ネットワークの帯域幅が十分に広く確保されていても、スクリプト情報を含む表示制御情報に基づいてページを表示する際には、ページが表示されるまでに、ある程度の待ち時間が生じてしまう。特に、スクリプト処理のステップが入れ子の形になっている場合には、待ち時間がさらに拡大してしまう。
そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、逐次的に実行されるスクリプト処理に起因して生じるページの表示遅延を低減させ、より素早くレイアウトの整ったページを表示することが可能な、新規かつ改良された情報処理装置、データ取得方法及びプログラムを提供することにある。
上記課題を解決するために、本発明のある観点によれば、キー情報による検索の結果が表示されたリンク先の一部を選択するリンク選択部と、前記リンク選択部により選択されたリンク先に存在する、表示画面のレイアウトに関する情報が記述された構造単位を少なくとも含む表示制御データと、前記表示画面のレイアウトに関する情報とを、前記リンク先がユーザ操作によって選択される以前に取得するデータ先読み部と、前記データ先読み部が前記表示制御データを取得したリンク先が前記操作体によって選択された場合に、前記表示制御データを解析して、当該表示制御データに含まれる構造単位を抽出する構造解析部と、前記データ先読み部が前記表示制御データの取得を行ったリンク先が前記ユーザ操作によって選択された場合に、前記構造解析部により抽出された構造単位のうち、スクリプト処理を伴う表示制御に関する情報が記述された構造単位を除き、表示画面のレイアウトに関する情報が記述された構造単位を少なくとも含む前記構造単位を相互に紐付けて、表示制御用の第１構造化データを生成する第１構造化部と、前記データ先読み部が前記表示制御データを取得したリンク先がユーザ操作によって選択された場合に、前記構造単位を相互に紐付けて、表示制御用の第２構造化データを生成する第２構造化部と、前記第１構造化部により生成された前記第１構造化データを用いて表示画面を表示し、前記第２構造化部により前記第２構造化データが生成された段階で、当該第２構造化データを用いて表示画面を表示しなおす表示制御部と、を備える情報処理装置が提供される。
前記情報処理装置は、前記リンク先との接続を確立する接続確立部を更に備え、前記リンク選択部は、表示画面上の位置を指定するために用いられる位置指定オブジェクトの表示位置から所定範囲内に存在する前記リンク先、表示画面に表示された状態にある前記リンク先、および、所定回数以上選択されている前記リンク先の少なくとも何れかを更に選択し、前記接続確立部は、リンク選択部によって更に選択された前記リンク先と、ユーザ操作によって前記リンク先が選択される以前にＴＣＰコネクションを確立してもよい。
前記リンク選択部は、前記リンク先のうち、当該リンク先への往復遅延時間（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）が所定の閾値以上のものを、ＴＣＰコネクションを確立するリンク先として選択してもよい。
前記リンク選択部は、前記リンク先のドメイン名またはＩＰアドレスに応じて、ＴＣＰコネクションを確立するリンク先として選択するか否かを判断してもよい。
前記情報処理装置は、前記表示制御データと、当該表示制御データと関連づけられた関連データと、を取得するデータ取得部を更に備え、前記データ取得部は、前記第２構造化部からのデータ取得要請よりも、前記第１構造化部からのデータ取得要請を優先して扱ってもよい。
前記接続確立部は、前記リンク先のホストアドレスが確定すると、前記表示制御データの先読みまたは前記ＴＣＰコネクションの確立に先立って、前記ホストアドレスに対応するＩＰアドレスを取得してもよい。
前記情報処理装置は、前記第１構造化部及び前記第２構造化部の要請により前記データ取得部が取得した前記表示制御データ及び前記関連データが格納されるキャッシュメモリを更に備え、前記表示制御部は、前記第２構造化データでの表示に要する前記表示制御データが前記キャッシュメモリに全て格納された時点で、当該キャッシュメモリに格納されたデータに基づき表示を切り替えてもよい。
前記第２構造化部は、前記構造解析部により抽出された構造単位のなかに、スクリプト処理を伴う表示制御に関する情報が記述された構造単位が存在しない場合、前記第２構造化データを生成しなくてもよい。
前記情報処理装置は、前記第１構造化データでの表示を行っている際に表示画面に表示している構造単位の履歴を格納する表示履歴格納部を更に備え、前記表示制御部は、前記第２構造化データでの表示に切り替える際、前記表示履歴格納部に格納されている表示履歴に基づいて、表示画面に表示する前記構造単位を選択してもよい。
また、上記課題を解決するために、本発明の別の観点によれば、キー情報による検索の結果が表示されたリンク先の一部を選択するステップと、前記リンク先の一部を選択するステップにて選択されたリンク先に存在する、表示画面のレイアウトに関する情報が記述された構造単位を少なくとも含む表示制御データと、前記表示画面のレイアウトに関する情報とを、前記リンク先がユーザ操作によって選択される以前に取得するステップと、ユーザ操作に先立つ表示制御データの取得ステップにて前記表示制御データを取得したリンク先がユーザ操作によって選択された場合に、前記表示制御データを解析して、当該表示制御データに含まれる構造単位を抽出するステップと、ユーザ操作に先立つ表示制御データの取得ステップにて前記表示制御データを取得したリンク先がユーザ操作によって選択された場合に、前記構造単位を抽出するステップにて抽出された構造単位のうち、スクリプト処理を伴う表示制御に関する情報が記述された構造単位を除き、表示画面のレイアウトに関する情報が記述された構造単位を少なくとも含む前記構造単位を相互に紐付けて、表示制御用の第１構造化データを生成するステップと、ユーザ操作に先立つ表示制御データの取得を行ったリンク先が前記ユーザ操作によって選択された場合に、前記構造単位を相互に紐付けて、表示制御用の第２構造化データを生成するステップと、前記第１構造化データを生成するステップにて生成された前記第１構造化データを用いて表示画面を表示するステップと、前記第２構造化データが生成された段階で、当該第２構造化データを用いて表示画面を表示しなおすステップと、を含むデータ取得方法が提供される。
また、上記課題を解決するために、本発明の更に別の観点によれば、コンピュータに、キー情報による検索の結果が表示されたリンク先の一部を選択するリンク選択機能と、前記リンク選択機能により選択されたリンク先に存在する、表示画面のレイアウトに関する情報が記述された構造単位を少なくとも含む表示制御データと、前記表示画面のレイアウトに関する情報とを、前記リンク先がユーザ操作によって選択される以前に取得するデータ先読み機能と、前記データ先読み機能が前記表示制御データを取得したリンク先がユーザ操作によって選択された場合に、前記表示制御データを解析して、当該表示制御データに含まれる構造単位を抽出する構造解析機能と、前記データ先読み機能が前記表示制御データの取得を行ったリンク先が前記ユーザ操作によって選択された場合に、前記構造解析機能により抽出された構造単位のうち、スクリプト処理を伴う表示制御に関する情報が記述された構造単位を除き、表示画面のレイアウトに関する情報が記述された構造単位を少なくとも含む前記構造単位を相互に紐付けて、表示制御用の第１構造化データを生成する第１構造化機能と、前記データ先読み機能が前記表示制御データを取得したリンク先がユーザ操作によって選択された場合に、前記構造単位を相互に紐付けて、表示制御用の第２構造化データを生成する第２構造化機能と、前記第１構造化機能により生成された前記第１構造化データを用いて表示画面を表示し、前記第２構造化機能により前記第２構造化データが生成された段階で、当該第２構造化データを用いて表示画面を表示しなおす表示制御機能と、を実現させるためのプログラムが提供される。
以上説明したように本発明によれば、スクリプト処理の逐次性に起因して生じるページの表示遅延を低減させ、より素早くレイアウトの整ったページを表示することが可能になる。
以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
［説明の流れについて］
ここで、以下に記載する本発明の実施形態に関する説明の流れについて簡単に述べる。まず、本実施形態に係る技術的構成について詳細に説明するに先立ち、図１〜図６を参照しながら、Ｗｅｂブラウザによるページの表示処理に関する一般的な構成について説明する。次いで、図７〜図９を参照しながら、本発明の第１実施形態に係るＷｅｂページの表示処理シーケンスについて説明する。次いで、図１０、図１１を参照しながら、同実施形態に係る情報処理装置１００の機能構成及び動作について説明する。
ここで、以下に記載する本発明の実施形態に関する説明の流れについて簡単に述べる。まず、本実施形態に係る技術的構成について詳細に説明するに先立ち、図１〜図６を参照しながら、Ｗｅｂブラウザによるページの表示処理に関する一般的な構成について説明する。次いで、図７〜図９を参照しながら、本発明の第１実施形態に係るＷｅｂページの表示処理シーケンスについて説明する。次いで、図１０、図１１を参照しながら、同実施形態に係る情報処理装置１００の機能構成及び動作について説明する。
次いで、図１２〜図１４を参照しながら、同実施形態に係る表示制御方法を適用した場合に得られるページ表示時間の短縮効果について説明する。次いで、図１５〜図１７を参照しながら、ＤＯＭ構造の違いと表示結果の違いとの関係について説明する。次いで、同実施形態に係る技術との対比を行うため、図１８〜図３５を参照しながら、ＨＴＭＬファイルの実行処理について簡単に説明する。次いで、図３６〜図６８を参照しながら、同実施形態に係るＨＴＭＬファイルの実行処理について説明する。
次いで、図６９を参照しながら、本発明の第２実施形態に係るプリフェッチ方法について説明する。次いで、図７０、図７１を参照しながら、プリフェッチ対象の種類に応じた効果の違いを示すと共に、図７２を参照しながら、効果の高いプリフェッチ対象の選択方法について説明する。次いで、図７３、図７４を参照しながら、同実施形態に係る情報処理装置１００の機能構成及び動作について説明する。次いで、図７５を参照しながら、同実施形態に係るプリフェッチ処理の流れについて説明する。次いで、図７６を参照しながら、プリフェッチの種類に応じた効果の違いについて説明する。
次いで、図７７、図７８を参照しながら、同実施形態に係るプリコネクション方法について説明する。次いで、図７９、図８０を参照しながら、プリコネクションによる効果をＴＬＤの違い、及び対象国の違いについて比較する。
次いで、図８１を参照しながら、本発明の第３実施形態に係る近接検知とプリフェッチ処理との連携方法について説明する。次いで、図８２、図８３を参照しながら、同実施形態に係る情報処理装置１００の機能構成及び動作について説明する。次いで、図８４を参照しながら、同実施形態に係るプリフェッチ処理の流れについて説明する。次いで、図８５を参照しながら、同実施形態に係る近接検知に利用可能なインセル型タッチパネルの構成及び動作について説明する。
次いで、図８６を参照しながら、上記の第１〜第３実施形態に係る情報処理装置１００が有する機能を実現することが可能なハードウェア構成例について説明する。最後に、上記の各実施形態の技術的思想について纏め、当該技術的思想から得られる作用効果について簡単に説明する。
（説明項目）
１：はじめに
１−１：Ｗｅｂブラウザの動作
１−２：表示時間の解析結果
２：第１実施形態
２−１：Ｗｅｂブラウザの動作
２−２：情報処理装置１００の機能構成
２−３：情報処理装置１００の動作
２−４：表示時間に関する効果
２−５：ＤＯＭ構造の違いによる表示結果の比較
２−６：ＤＯＭ構築ステップの具体例
３：第２実施形態
３−１：プリフェッチによる効果（検討）
３−２：情報処理装置１００の機能構成
３−３：情報処理装置１００の動作
３−４：プリフェッチ処理の流れ
３−５：プリフェッチによる効果
３−６：プリコネクションによる効果（検討）
４：第３実施形態
４−１：近接検知とプリフェッチ処理の連携
４−２：情報処理装置１００の機能構成
４−３：情報処理装置１００の動作
４−４：近接検知に基づくプリフェッチ処理の流れ
４−５：近接検知が可能なタッチパネルの構成（インセル型タッチパネル）
５：情報処理装置１００のハードウェア構成例
６：まとめ
１：はじめに
１−１：Ｗｅｂブラウザの動作
１−２：表示時間の解析結果
２：第１実施形態
２−１：Ｗｅｂブラウザの動作
２−２：情報処理装置１００の機能構成
２−３：情報処理装置１００の動作
２−４：表示時間に関する効果
２−５：ＤＯＭ構造の違いによる表示結果の比較
２−６：ＤＯＭ構築ステップの具体例
３：第２実施形態
３−１：プリフェッチによる効果（検討）
３−２：情報処理装置１００の機能構成
３−３：情報処理装置１００の動作
３−４：プリフェッチ処理の流れ
３−５：プリフェッチによる効果
３−６：プリコネクションによる効果（検討）
４：第３実施形態
４−１：近接検知とプリフェッチ処理の連携
４−２：情報処理装置１００の機能構成
４−３：情報処理装置１００の動作
４−４：近接検知に基づくプリフェッチ処理の流れ
４−５：近接検知が可能なタッチパネルの構成（インセル型タッチパネル）
５：情報処理装置１００のハードウェア構成例
６：まとめ
＜１：はじめに＞
まず、本発明の実施形態について説明するに先立ち、ＷｅｂブラウザによるＷｅｂページの表示処理について説明する。ここでは、ＨＴＭＬファイルの取得からＷｅｂページの表示までの間にＷｅｂブラウザにより実行される一般的な処理の流れ（以下、表示処理シーケンス）について説明する。
まず、本発明の実施形態について説明するに先立ち、ＷｅｂブラウザによるＷｅｂページの表示処理について説明する。ここでは、ＨＴＭＬファイルの取得からＷｅｂページの表示までの間にＷｅｂブラウザにより実行される一般的な処理の流れ（以下、表示処理シーケンス）について説明する。
［１−１：Ｗｅｂブラウザの動作］
図１には、一般的なＷｅｂブラウザ１０による表示処理シーケンスが示されている。図１に示すように、Ｗｅｂブラウザ１０は、まず、Ｗｅｂサーバ３１０に対してＨＴＭＬファイルをリクエストする（ステップＳ１１）。次いで、Ｗｅｂブラウザ１０は、リクエストに応じてＷｅｂサーバ３１０により送信されたＨＴＭＬファイルを取得する（ステップＳ１２）。次いで、Ｗｅｂブラウザ１０は、取得したＨＴＭＬファイルを解析する（ステップＳ１３）。
図１には、一般的なＷｅｂブラウザ１０による表示処理シーケンスが示されている。図１に示すように、Ｗｅｂブラウザ１０は、まず、Ｗｅｂサーバ３１０に対してＨＴＭＬファイルをリクエストする（ステップＳ１１）。次いで、Ｗｅｂブラウザ１０は、リクエストに応じてＷｅｂサーバ３１０により送信されたＨＴＭＬファイルを取得する（ステップＳ１２）。次いで、Ｗｅｂブラウザ１０は、取得したＨＴＭＬファイルを解析する（ステップＳ１３）。
このとき、Ｗｅｂブラウザ１０は、ＨＴＭＬパーサ１１と呼ばれるパーサ・プログラムを用いてＨＴＭＬの構造を解析する。先に述べた通り、ＨＴＭＬファイルは、構造単位を定義する所定のタグを用いて記述されている。そのため、パーサ・プログラムにより、タグで囲まれた構造単位を抽出したり、構造単位間の関係を解析したりすることができる。ＨＴＭＬパーサ１１は、ＨＴＭＬファイルを解析し、必要に応じて外部リソースをＷｅｂサーバ３２０にリクエストする（ステップＳ１４）。
ここで言う外部リソースとは、例えば、レイアウト情報が記述されたスタイルシートファイルやスクリプト情報が記述されたスクリプトファイル等である。さて、リクエストに応じてＷｅｂサーバ３２０により外部リソースが送信されると、Ｗｅｂブラウザ１０は、Ｗｅｂサーバ３２０により送信された外部リソースを取得する（ステップＳ１５）。ステップＳ１５で取得された外部リソースは、その種類に応じてステップＳ１６、Ｓ１７の処理に利用される。また、ＨＴＭＬパーサ１１により、ＨＴＭＬファイルから抽出された構造単位の情報は、ＤＯＭ１２の構築時に利用される。
ステップＳ１５で取得された外部リソースがＣＳＳファイルである場合、Ｗｅｂブラウザ１０は、ＣＳＳを適用する（ステップＳ１６）。また、ステップＳ１５で取得された外部リソースがスクリプトファイルである場合、Ｗｅｂブラウザ１０は、スクリプトエンジン１３によりスクリプト処理を実行する（ステップＳ１７）。ステップＳ１６、Ｓ１７の処理を実行した後、Ｗｅｂブラウザ１０は、ＤＯＭ１２を構築する。次いで、Ｗｅｂブラウザ１０は、構築したＤＯＭ１２に基づいて各種の描画要素を生成する（ステップＳ１８）。次いで、Ｗｅｂブラウザ１０は、必要に応じてプラグインを読み込み（ステップＳ１９）、Ｗｅｂページを表示する（ステップＳ２０）。
このように、Ｗｅｂページが表示されるまでに様々な処理が実行される。そして、これらの処理の多くはＤＯＭ１２の構築前に実行される。
（ＤＯＭ１２について）
ここで、図２を参照しながら、ＤＯＭ１２の構築処理、及び構築したＤＯＭ１２に基づくＷｅｂページの表示処理について、より詳細に説明する。
ここで、図２を参照しながら、ＤＯＭ１２の構築処理、及び構築したＤＯＭ１２に基づくＷｅｂページの表示処理について、より詳細に説明する。
図２に示すように、ＤＯＭ１２は、ＨＴＭＬパーサ１１により抽出されたＨＴＭＬファイルの各構造単位を紐付けて構築されたツリー構造のことである。より正確には、ＤＯＭ１２は、ＨＴＭＬ（又は、ＸＭＬ）の構造や内容を扱うためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）である。例えば、ＨＴＭＬファイルにＷｅｂページの表示構成を規定するための複数の構造単位（Ａ１〜Ａ７）が含まれているものとする。これらの構造単位は、ＨＴＭＬパーサ１１による解析処理において抽出され、相互に紐付けされてＤＯＭ１２の形に構築される。
但し、図２に例示したＤＯＭ１２のツリー構造は、Ｗｅｂブラウザが内部で認識している構造の概念的な表現である。実際にユーザが見るＷｅｂページは、ＤＯＭ１２のツリー構造に基づいてＷｅｂブラウザ１０のレンダリングエンジンが生成したものである。Ｗｅｂページの表示処理は、Ｗｅｂブラウザ１０が、ＤＯＭ１２を構築した後、ＤＯＭ１２のツリー構造に基づいて表示レイアウトを整え、表示レイアウトの所定位置に画像データやテキストデータ等のコンテンツを埋め込んで完了する。このように、Ｗｅｂページを表示するには、ＤＯＭ１２の構築が前提となる。
［１−２：表示時間の解析結果］
ここで、図３〜図５を参照しながら、ＤＯＭ１２の構築タイミングと、Ｗｅｂページの表示までに要する時間との関係について考察する。
ここで、図３〜図５を参照しながら、ＤＯＭ１２の構築タイミングと、Ｗｅｂページの表示までに要する時間との関係について考察する。
（ダウンロードシーケンスについて）
上記の通り、ＤＯＭ１２の構築は、少なくともＨＴＭＬパーサ１１によるＨＴＭＬファイルの解析、ＣＳＳの適用、及びスクリプト処理の実行が完了した後に行われる。より詳細には、図３のような処理シーケンスが実行される。図３に示す処理シーケンスは、左から右に時間が進むことを前提に記載されている。つまり、左側に記載された処理から順番に実行されるものとする。
上記の通り、ＤＯＭ１２の構築は、少なくともＨＴＭＬパーサ１１によるＨＴＭＬファイルの解析、ＣＳＳの適用、及びスクリプト処理の実行が完了した後に行われる。より詳細には、図３のような処理シーケンスが実行される。図３に示す処理シーケンスは、左から右に時間が進むことを前提に記載されている。つまり、左側に記載された処理から順番に実行されるものとする。
図３に示すように、Ｗｅｂページ等に対するリダイレクトが発生すると、Ｗｅｂブラウザ１０によりＨＴＭＬファイルがダウンロードされる。なお、ファイルをダウンロードする際には、ＤＮＳによる名前解決に要する時間、Ｗｅｂサーバとの間のコネクション確立に要する時間、待ち時間等が必要になる。図３に示した各ファイルのダウンロード時間には、これらの時間も含まれている。ＨＴＭＬファイルのダウンロードが完了すると、Ｗｅｂブラウザ１０は、ダウンロードしたＨＴＭＬファイルを解析する。
そして、Ｗｅｂブラウザ１０は、ＨＴＭＬファイルの解析結果に基づき、必要に応じてＣＳＳファイルやＪＳファイルをダウンロードする。なお、ＣＳＳファイルやＪＳファイルのダウンロードは、ＨＴＭＬファイルの解析途中に実行されてもよい。また、複数のＣＳＳファイル、複数のＪＳファイルがダウンロードされることもある。さらに、ＨＴＭＬファイルの解析結果を受けて画像データ等（Ｉｍａｇｅ ｅｔｃ．）がダウンロードされる。全てのＣＳＳファイル、ＪＳファイルがダウンロードされると、ＤＯＭ１２を構築するための構成要素が確定する。
ＤＯＭ１２を構築するための構成要素が全て揃うと、Ｗｅｂブラウザ１０のレンダリングエンジンによりＤＯＭ１２のレンダリングが開始される。このとき、画像データ等が全てダウンロードされていなくてもよい。また、ある程度レンダリングが進むと、ユーザにより操作可能な状態になる。次いで、画像データ等が全てダウンロードし終わり、ＤＯＭ１２のレンダリングが完了すると、Ｗｅｂページの表示が完了する。この時点で、完全なＷｅｂページの表示が完了する。このように、一般的なＷｅｂブラウザ１０における表示処理のシーケンスにおいては、ＨＴＭＬファイル、ＣＳＳファイル、ＪＳファイルが全てダウンロードし終わるまでＤＯＭ１２は確定しない。
（Ｗｅｂページの表示に要する時間について）
さて、図３に例示したダウンロードシーケンスは、あくまでも処理の順序を示すものである。そのため、図３の例から実際に各処理に要する時間の長さを窺い知ることはできない。そこで、実際にＷｅｂブラウザ１０を利用して各処理に要する時間の長さを測定した結果を図４に示す。
さて、図３に例示したダウンロードシーケンスは、あくまでも処理の順序を示すものである。そのため、図３の例から実際に各処理に要する時間の長さを窺い知ることはできない。そこで、実際にＷｅｂブラウザ１０を利用して各処理に要する時間の長さを測定した結果を図４に示す。
なお、図４の例には実際に測定された時間が示されているが、この時間の実測値自体は測定する環境により変化するものである。そのため、各処理に要する時間の相対的な長短に注目して頂きたい。また、図４には、イニシャルタイムを示す縦ラインと、コンプリートタイムを示す縦ラインとが示されている。ここで言うイニシャルタイムとは、ユーザが操作を開始できるようになるまでの時間を意味する。一方、ここで言うコンプリートタイムとは、全てのファイルやデータがダウンロードされ、完全な形でＷｅｂページが表示されるまでの時間を意味する。
まず、ＣＳＳファイルの処理に注目する。ＣＳＳファイルの処理は、リダイレクトが発生（０ｍｓ）してから２５００ｍｓ程度の時間が経過した時点で開始され、２５００ｍｓ程度の時間継続して実行されている。また、図４の例では、３つのＣＳＳファイルに対する処理が同時に開始されている。
次に、ＪＳファイルの処理に注目する。ＪＳファイルの処理は、ＣＳＳファイルの処理が開始されると同時に開始されている。しかし、この時点では１つのＪＳファイルに対する処理しか開始されていない。２つ目のＪＳファイルは、１つ目のＪＳファイルに対する処理が完了した後で開始されている。この時点でも、１つのＪＳファイルに対する処理しか開始されていない。同様に、全てのＪＳファイルに対する処理が完了するまで、１つずつＪＳファイルに対する処理が実行される。その結果、全てのＪＳファイルの処理に１２０００ｍｓ程度の時間がかかってしまっている。
その後、画像データ等のダウンロードやＤＯＭのレンダリング等が実行され、Ｗｅｂページの表示処理が実行されている。これらの処理は同時並行で実行されるため、Ｗｅｂページの表示に要する処理時間に大きな影響を与えていない。
図４に例示した実測結果から言えることは、Ｗｅｂページの表示までにかかる時間の中でＪＳファイルの処理に要する時間が非常に大きな割合を占めているということである。ＪＳファイルの処理に時間がかかる主な理由は、複数のＪＳファイルに対するダウンロード及び実行が同時並行で行えないことにある。このような事象は、ＪＳファイルが入れ子で定義されている場合に、前のＪＳファイルのダウンロード及び実行が完了するまで次のＪＳファイルのダウンロード及び実行ができないために生じる。ここではＪＳファイルを例に挙げたが、他のスクリプト言語で記述されたスクリプトファイルについても同様のことが言える。
そこで、本件発明者は、ＪＳファイルのダウンロード及び実行を他の処理よりも後に実行する方法を考案した。そして、この方法を適用した場合に得られる効果を推測するため、図５に例示したようなシミュレーションを実施した。その結果、ＪＳファイルのダウンロード及び実行を後に行うようにすると、イニシャルタイムが７秒に短縮された。ちなみに、図４の例ではイニシャルタイムが２２秒であったから、ＪＳファイルのダウンロード及び実行を後回しにすることによりイニシャルタイムが１５秒も短縮されたことになる。但し、図５の例はシミュレーションであり、実際には、ＪＳファイルのダウンロード及び実行を後回しにするための様々な工夫が必要になる。
＜２：第１実施形態＞
上記の通り、Ｗｅｂページの表示に要する時間は、スクリプトファイルのダウンロード及び実行を後回しにすることにより大幅に短縮できる。以下では、スクリプトファイルに対する処理を後回しにするための仕組みについて説明する。本発明の第１実施形態は、このような仕組みを実現するための装置及び方法に関するものである。
上記の通り、Ｗｅｂページの表示に要する時間は、スクリプトファイルのダウンロード及び実行を後回しにすることにより大幅に短縮できる。以下では、スクリプトファイルに対する処理を後回しにするための仕組みについて説明する。本発明の第１実施形態は、このような仕組みを実現するための装置及び方法に関するものである。
［２−１：Ｗｅｂブラウザの動作］
まず、図６〜図９を参照しながら、本実施形態に係るＷｅｂブラウザの処理シーケンスについて説明する。但し、図６に示す処理シーケンスは、本実施形態に係る処理シーケンスと対比するために示した一般的なＷｅｂブラウザの処理シーケンスである。
まず、図６〜図９を参照しながら、本実施形態に係るＷｅｂブラウザの処理シーケンスについて説明する。但し、図６に示す処理シーケンスは、本実施形態に係る処理シーケンスと対比するために示した一般的なＷｅｂブラウザの処理シーケンスである。
（一般的な処理シーケンス）
図６に示すように、一般的なＷｅｂブラウザの処理シーケンスは、先に説明した通り、ＨＴＭＬファイルの処理、｛ＣＳＳファイルの処理、ＪＳファイルの処理｝、ＤＯＭの構築、画像データ等のダウンロードの順番で実行される。つまり、これら一連の処理が１つのスレッド（第１スレッド）により実行される。
図６に示すように、一般的なＷｅｂブラウザの処理シーケンスは、先に説明した通り、ＨＴＭＬファイルの処理、｛ＣＳＳファイルの処理、ＪＳファイルの処理｝、ＤＯＭの構築、画像データ等のダウンロードの順番で実行される。つまり、これら一連の処理が１つのスレッド（第１スレッド）により実行される。
（本実施形態の処理シーケンス）
一方、本実施形態に係る処理シーケンスは、図７に示すように、２つのスレッド（第１スレッド、第２スレッド）により実行される。第１スレッドでは、ＨＴＭＬファイルの処理、ＣＳＳファイルの処理、画像データ等のダウンロードが実行され、ＣＳＳファイルの処理が完了した段階で簡易的なＤＯＭ（以下、仮ＤＯＭ）が構築される。そして、仮ＤＯＭに基づいてＷｅｂページが表示される。
一方、本実施形態に係る処理シーケンスは、図７に示すように、２つのスレッド（第１スレッド、第２スレッド）により実行される。第１スレッドでは、ＨＴＭＬファイルの処理、ＣＳＳファイルの処理、画像データ等のダウンロードが実行され、ＣＳＳファイルの処理が完了した段階で簡易的なＤＯＭ（以下、仮ＤＯＭ）が構築される。そして、仮ＤＯＭに基づいてＷｅｂページが表示される。
一方、第２スレッドでは、ＪＳファイルの処理が実行され、ＪＳファイルの処理が完了した段階で本来のＤＯＭ（以下、本ＤＯＭ）が構築される。さらに、第１スレッドで取得されていない画像データ等がダウンロードされ、本ＤＯＭに基づいてＷｅｂページが表示される。このとき、仮ＤＯＭに基づいて表示されたＷｅｂページは、本ＤＯＭに基づいて表示されるＷｅｂページに更新される（図８を参照）。
先にシミュレーション結果を交えて説明した通り、ＪＳファイルの処理が含まれることによりＤＯＭの構築タイミングが遅れ、結果的にＷｅｂページの表示までに要する時間が長くなっていた。しかし、第１スレッドで構築される仮ＤＯＭの構築は、ＪＳファイルの処理とは無関係に実行される。そのため、仮ＤＯＭの構築は、一般的なＷｅｂブラウザによるＤＯＭの構築タイミングに比べて非常に早いタイミングで実行される。
但し、仮ＤＯＭには、ＪＳファイルの処理に関する構造単位が含まれない。そのため、仮ＤＯＭに基づいて表示されたＷｅｂページは、ＪＳファイルの処理に関する構造単位を含む本ＤＯＭに基づいて表示されたＷｅｂページとは異なる。しかし、本実施形態に係る処理シーケンスは、ＪＳファイルの処理に関する構造単位を含む本ＤＯＭを構築するための第２スレッドによる動作を含んでいる。また、第２スレッドの処理が完了したタイミングで本ＤＯＭに基づくＷｅｂページの表示に切り替わるため、上記Ｗｅｂページの違いによるユーザの違和感は解消される。このように、本実施形態に係る処理シーケンスを適用することにより、素早いＷｅｂページの表示と正しいＷｅｂページの表示との両立という難題を解決することができるのである。
なお、実際には、第１スレッドで構築される仮ＤＯＭと、第２スレッドで構築される本ＤＯＭとの間で、ＤＯＭのノードとなる構造単位のファイルには重複するものがある。そのため、図９に示すように、各ファイルのダウンロードは、ダウンロードマネージャスレッドを実行しておき、ダウンロードマネージャスレッドが取得したファイルを第１及び第２スレッドで利用する方が効率的である。例えば、ダウンロードマネージャスレッドは、ＨＴＭＬファイル、ＣＳＳファイル、ＪＳファイル、画像データ等のダウンロードを一手に引き受ける。但し、ダウンロードするタイミングは図７、図８に示した通りである。
以上、本実施形態に係る処理シーケンスについて説明した。
［２−２：情報処理装置１００の機能構成］
次に、図１０を参照しながら、上記のアイデアを実現することが可能な情報処理装置１００の機能構成について説明する。図１０は、本実施形態に係る情報処理装置１００の機能構成例を示す説明図である。なお、後述する第２及び第３実施形態に係る情報処理装置１００と区別するために、本実施形態に係る情報処理装置１００を情報処理装置１００Ａと表記する場合がある。
次に、図１０を参照しながら、上記のアイデアを実現することが可能な情報処理装置１００の機能構成について説明する。図１０は、本実施形態に係る情報処理装置１００の機能構成例を示す説明図である。なお、後述する第２及び第３実施形態に係る情報処理装置１００と区別するために、本実施形態に係る情報処理装置１００を情報処理装置１００Ａと表記する場合がある。
図１０に示すように、情報処理装置１００は、主に、データ取得部１１０と、構造解析部１２０と、レンダリング部１３０と、表示部１４０とにより構成される。また、レンダリング部１３０は、仮ＤＯＭ生成部１３１と、本ＤＯＭ生成部１３２と、キャッシュメモリ１３３と、表示制御部１３４と、ノード情報格納部１３５とを有する。
リダイレクトが発生すると、まず、データ取得部１１０によりＨＴＭＬファイルがダウンロードされる。そして、データ取得部１１０によりダウンロードされたＨＴＭＬファイルは、構造解析部１２０に入力される。ＨＴＭＬファイルが入力されると、構造解析部１２０は、ＨＴＭＬファイルの構造を解析し、ＨＴＭＬファイルの構造単位を抽出する。そして、構造解析部１２０は、必要に応じてＣＳＳファイル、ＪＳファイルのリクエストをデータ取得部１１０を介してＷｅｂサーバ３１０、３２０に送信する。
リクエストに応じてＷｅｂサーバ３１０、３２０からＣＳＳファイル、ＪＳファイルが送信されると、データ取得部１１０は、送信されたＣＳＳファイル、ＪＳファイルを受信する。データ取得部１１０により受信されたＣＳＳファイル、ＪＳファイルは、構造解析部１２０に入力される。ＣＳＳファイルが入力されると、構造解析部１２０は、入力されたＣＳＳファイルの適用処理を実行する。また、ＪＳファイルが入力されると、構造解析部１２０は、入力されたＪＳファイルを実行する。このとき、必要に応じて順次ＪＳファイルが取得され、構造解析部１２０により実行される。
構造解析部１２０によるＣＳＳファイルの適用結果は仮ＤＯＭ生成部１３１、本ＤＯＭ生成部１３２の双方に入力され、ＪＳファイルの実行結果は本ＤＯＭ生成部１３２に入力される。また、構造解析部１２０は、ＨＴＭＬファイルから抽出した構造単位の情報を仮ＤＯＭ生成部１３１、本ＤＯＭ生成部１３２に入力する。但し、仮ＤＯＭ生成部１３１には、ＪＳファイルの処理に関する構造単位の情報は入力されない。また、構造解析部１２０は、ＨＴＭＬファイルの解析結果に基づき、必要に応じて画像データ等の取得をデータ取得部１１０に要求する。このような要求に応じてデータ取得部１１０により取得された画像データ等は、仮ＤＯＭ生成部１３１、本ＤＯＭ生成部１３２を介して表示制御部１３４に入力される。
上記の通り、仮ＤＯＭ生成部１３１には、ＪＳファイルの処理に関する構造単位を除くＨＴＭＬファイルの構造単位が入力される。そこで、仮ＤＯＭ生成部１３１は、入力された構造単位を相互に紐付けてツリー構造を形成し、仮ＤＯＭを構築する。仮ＤＯＭ生成部１３１により構築された仮ＤＯＭの情報は、表示制御部１３４に入力される。一方、本ＤＯＭ生成部１３２には、ＪＳファイルの処理に関する構造単位を含むＨＴＭＬファイルの構造単位が全て入力される。但し、ＪＳファイルに対する処理の逐次性に起因してＪＳファイルの取得に長い時間がかかるため、全ての構造単位に関する情報やデータが入力されるまでには比較的長い時間を要する。その結果、本ＤＯＭの構築は、仮ＤＯＭの構築後、暫くしてから完了する。
ＪＳファイルの処理に関する情報を含むＨＴＭＬファイルの全構造単位に関する情報が入力されると、本ＤＯＭ生成部１３２は、入力された各構造単位を相互に紐付けてツリー構造を形成し、本ＤＯＭを構築する。そして、本ＤＯＭ生成部１３２により構築された本ＤＯＭの情報は、表示制御部１３４に入力される。また、本ＤＯＭ生成部１３２は、本ＤＯＭに基づくＷｅｂページの表示に必要な画像データ等を全て取得し、キャッシュメモリ１３３に格納する。Ｗｅｂページの表示に必要なデータを全てキャッシュメモリ１３３に格納しておくことにより、仮ＤＯＭに基づいて表示されているＷｅｂページを素早く本ＤＯＭに基づくＷｅｂページに置き換えることが可能になる。
上記の通り、表示制御部１３４には、仮ＤＯＭ生成部１３１から仮ＤＯＭの情報及び画像データ等が入力される。仮ＤＯＭの情報及び画像データ等が入力されると、表示制御部１３４は、仮ＤＯＭに基づいてレンダリングを実施し、仮ＤＯＭに基づくＷｅｂページを生成する。そして、表示制御部１３４は、仮ＤＯＭに基づくＷｅｂページを表示部１４０に表示させる。また、本ＤＯＭ生成部１３２から本ＤＯＭの情報及び画像データ等が入力されると、表示制御部１３４は、本ＤＯＭに基づいてレンダリングを実施し、本ＤＯＭに基づくＷｅｂページを生成する。そして、表示制御部１３４は、仮ＤＯＭに基づくＷｅｂページを本ＤＯＭに基づくＷｅｂページに置き換える。
このとき、表示制御部１３４は、キャッシュメモリ１３３に格納されているＷｅｂページの表示に必要な画像データ等を読み出し、本ＤＯＭに基づくＷｅｂページを表示部１４０に表示させる。但し、キャッシュメモリ１３３にＷｅｂページの表示に必要な画像データ等が格納されていない場合、表示制御部１３４は、データ取得部１１０を介して必要な画像データ等を取得し、取得した画像データ等を用いてＷｅｂページを表示させる。
また、仮ＤＯＭに基づくＷｅｂページの表示中にスクロール等がされた場合、表示制御部１３４は、表示部１４０の基準位置に表示されている構造単位の情報（以下、ノード情報）をノード情報格納部１３５に格納する。そして、本ＤＯＭに基づくＷｅｂページを表示する際、表示制御部１３４は、ノード情報格納部１３５に格納されているノード情報を読み出し、そのノード情報に対応する本ＤＯＭの構造単位が表示部１４０の基準位置に表示されるように、本ＤＯＭに基づくＷｅｂページのスクロール位置を調整する。このような構成にすることにより、仮ＤＯＭに基づくＷｅｂページから本ＤＯＭに基づくＷｅｂページへと切り替わった際に、ユーザに与える違和感を低減させることができる。
以上、本実施形態に係る情報処理装置１００の機能構成について説明した。
［２−３：情報処理装置１００の動作］
次に、図１１を参照しながら、本実施形態に係る情報処理装置１００の動作について説明する。図１１は、本実施形態に係る情報処理装置１００の動作フローを示す説明図である。
次に、図１１を参照しながら、本実施形態に係る情報処理装置１００の動作について説明する。図１１は、本実施形態に係る情報処理装置１００の動作フローを示す説明図である。
図１１に示すように、情報処理装置１００は、まず、ＨＴＭＬファイルを解析し、ＨＴＭＬの記述に関する構造単位、ＣＳＳファイルのダウンロード及び適用に関する構造単位、及びＪＳファイルのダウンロード及び実行に関する構造単位を抽出する（ステップＳ１０１）。次いで、情報処理装置１００は、抽出した構造単位のうち、ＨＴＭＬの記述に関する構造単位と、ＣＳＳファイルに関する構造単位とを相互に紐付けて仮ＤＯＭの生成を開始する（ステップＳ１０２）。次いで、情報処理装置１００は、抽出した構造単位のうち、ＨＴＭＬの記述に関する構造単位と、ＣＳＳファイルに関する構造単位と、ＪＳファイルに関する構造単位とを相互に紐付けて仮ＤＯＭの生成を開始する（ステップＳ１０３）。
次いで、情報処理装置１００は、仮ＤＯＭの生成が完了したか否かを判定する（ステップＳ１０４）。仮ＤＯＭの生成が完了した場合、情報処理装置１００は、ステップＳ１０５の処理に進行する。一方、仮ＤＯＭの生成が完了していない場合、情報処理装置１００は、再びステップＳ１０４の処理に戻る。ステップＳ１０５の処理に進行した場合、情報処理装置１００は、仮ＤＯＭをレンダリングしてＷｅｂページを生成し、表示画面に表示する（ステップＳ１０５）。
次いで、情報処理装置１００は、本ＤＯＭの生成が完了したか否かを判定する（ステップＳ１０６）。本ＤＯＭの生成が完了した場合、情報処理装置１００は、ステップＳ１０７の処理に進行する。一方、本ＤＯＭの生成が完了していない場合、情報処理装置１００は、再びステップＳ１０６の処理に戻る。ステップＳ１０７の処理に進行した場合、情報処理装置１００は、本ＤＯＭをレンダリングしてＷｅｂページを生成し、仮ＤＯＭに基づくＷｅｂページに代えて表示画面に表示して（ステップＳ１０７）、一連の処理を終了する。
以上、本実施形態に係る情報処理装置１００の動作フローについて説明した。
［２−４：表示時間に関する効果］
ここで、図１２〜図１４を参照しながら、本実施形態に係る処理シーケンスを適用した場合に得られる効果について説明する。図１２、図１４には、一般的なＷｅｂブラウザの処理シーケンスにより得られるイニシャルタイムと、本実施形態に係る処理シーケンスにより得られるイニシャルタイムとが対比して示されている。また、図１３には、一般的なＷｅｂブラウザの処理シーケンスにより得られるコンプリートタイムと、本実施形態に係る処理シーケンスにより得られるコンプリートタイムとが対比して示されている。
ここで、図１２〜図１４を参照しながら、本実施形態に係る処理シーケンスを適用した場合に得られる効果について説明する。図１２、図１４には、一般的なＷｅｂブラウザの処理シーケンスにより得られるイニシャルタイムと、本実施形態に係る処理シーケンスにより得られるイニシャルタイムとが対比して示されている。また、図１３には、一般的なＷｅｂブラウザの処理シーケンスにより得られるコンプリートタイムと、本実施形態に係る処理シーケンスにより得られるコンプリートタイムとが対比して示されている。
まず、図１２を参照する。図１２に示すように、Ｗｅｂページの構成や測定環境により異なるものの、本実施形態に係る処理シーケンスを適用した場合にイニシャルタイムが平均で３７％も短縮された。特に、ＪＳを多用しているＷｅｂページにおいて効果が顕著であることが確認された。
次に、図１３を参照する。図１３は、２つのスレッドで実行する本実施形態に係る処理シーケンスと、１つのスレッドで実行する一般的なＷｅｂブラウザの処理シーケンスとの間でコンプリートタイムを比較するものである。図１３から分かるように、本実施形態に係る処理シーケンスの場合には２つのスレッドが動作しているものの、本ＤＯＭに基づくＷｅｂページが完全に表示されるまでの時間は、１つのスレッドで実行される一般的なＷｅｂブラウザによるコンプリートタイムとほぼ同程度である。これは、２つのスレッドが同時並行で処理を実行しているためである。
次に、図１４を参照する。図１４は、高速な光回線を利用してイニシャルタイムの比較を行った結果である。図１４に示すように、帯域幅の広い高速な回線を利用しても、本実施形態に係る処理シーケンスを適用した場合の方が平均で３０％程度高速である。このような結果が得られる要因としては、帯域の立ち上がりの遅さが考えられる。つまり、帯域幅が広い回線を利用しているユーザであっても、本実施形態に係る処理シーケンスを適用することにより効果を体感することができるのである。
以上、本実施形態に係る処理シーケンスを適用した場合に得られる効果について説明した。
［２−５：ＤＯＭ構造の違いによる表示結果の比較］
さて、本実施形態に係る処理シーケンスを適用することによる効果は明らかになったが、仮ＤＯＭに基づくＷｅｂページが見るに耐えないものでは意味がない。そこで、図１５〜図１７を参照しながら、ＤＯＭ構造の違いによる表示結果の違いについて確認しておくことにする。
さて、本実施形態に係る処理シーケンスを適用することによる効果は明らかになったが、仮ＤＯＭに基づくＷｅｂページが見るに耐えないものでは意味がない。そこで、図１５〜図１７を参照しながら、ＤＯＭ構造の違いによる表示結果の違いについて確認しておくことにする。
（Ｄ１：ＨＴＭＬファイルのみ）
まず、図１５を参照する。図１５には、ＨＴＭＬファイルだけを用いて簡易的なＤＯＭを構築し、その簡易的なＤＯＭに基づいてＷｅｂページを表示した場合の表示構成が示されている。ＨＴＭＬファイルだけの場合、レイアウトの指定が特にされていないため、テキストデータＴや画像データＭ１を縦に並べただけの表示結果が得られる。この場合、簡易的なＤＯＭの構造は、図１５に例示したように、ＨＴＭＬタグの構造単位をルートとし、ＨＥＡＤタグ、ＢＯＤＹタグの構造単位を第１階層のノードとするツリー構造を有する。さらに、ＢＯＤＹタグの構造単位の下位階層（第２階層）には、例えば、テキストデータＴに対応するノードと、画像データＭ１に対応するノードとが紐付けられる。
まず、図１５を参照する。図１５には、ＨＴＭＬファイルだけを用いて簡易的なＤＯＭを構築し、その簡易的なＤＯＭに基づいてＷｅｂページを表示した場合の表示構成が示されている。ＨＴＭＬファイルだけの場合、レイアウトの指定が特にされていないため、テキストデータＴや画像データＭ１を縦に並べただけの表示結果が得られる。この場合、簡易的なＤＯＭの構造は、図１５に例示したように、ＨＴＭＬタグの構造単位をルートとし、ＨＥＡＤタグ、ＢＯＤＹタグの構造単位を第１階層のノードとするツリー構造を有する。さらに、ＢＯＤＹタグの構造単位の下位階層（第２階層）には、例えば、テキストデータＴに対応するノードと、画像データＭ１に対応するノードとが紐付けられる。
（Ｄ２：ＨＴＭＬファイル＋ＣＳＳファイル）
次に、図１６を参照する。図１６には、ＨＴＭＬファイルとＣＳＳファイルとを用いて簡易的なＤＯＭを構築し、その簡易的なＤＯＭに基づいてＷｅｂページを表示した場合の表示構成が示されている。この表示構成例は、本実施形態に係る仮ＤＯＭに基づく表示構成に対応する。図１６の例では、ＣＳＳファイルによりレイアウトが指定されるため、テキストデータＴの表示位置や画像データＭ１の表示位置が整っている。
次に、図１６を参照する。図１６には、ＨＴＭＬファイルとＣＳＳファイルとを用いて簡易的なＤＯＭを構築し、その簡易的なＤＯＭに基づいてＷｅｂページを表示した場合の表示構成が示されている。この表示構成例は、本実施形態に係る仮ＤＯＭに基づく表示構成に対応する。図１６の例では、ＣＳＳファイルによりレイアウトが指定されるため、テキストデータＴの表示位置や画像データＭ１の表示位置が整っている。
この場合、簡易的なＤＯＭの構造は、ＨＴＭＬタグの構造単位をルートとし、ＨＥＡＤタグ、ＢＯＤＹタグの構造単位を第１階層のノードとするツリー構造を有する。さらに、ＢＯＤＹタグの構造単位の下位階層（第２階層）には、例えば、テキストデータＴに対応するノードと、画像データＭ１に対応するノードとが紐付けられる。このように、ＣＳＳファイルの適用により、この簡易的なＤＯＭへの書き換え処理は行われないため、簡易的なＤＯＭの構造は、上記ＨＴＭＬファイルのみの場合と実質的に同じである。
（Ｄ３：ＨＴＭＬファイル＋ＣＳＳファイル＋ＪＳファイル）
次に、図１７を参照する。図１７には、ＨＴＭＬファイル、ＣＳＳファイル、及びＪＳファイルを用いてＤＯＭを構築し、そのＤＯＭに基づいてＷｅｂページを表示した場合の表示構成が示されている。この表示構成例は、本実施形態に係る本ＤＯＭに基づく表示構成に対応する。図１７の例では、ＣＳＳファイルによりレイアウトが指定されるため、テキストデータＴの表示位置や画像データＭ２の表示位置が整っている。但し、ＤＯＭノードの内容がＪＳファイルの実行により書き換えられている。図１７の例では、ノードに含まれる画像データＭ１の表示指定が、画像データＭ２の表示指定に書き換えられている。
次に、図１７を参照する。図１７には、ＨＴＭＬファイル、ＣＳＳファイル、及びＪＳファイルを用いてＤＯＭを構築し、そのＤＯＭに基づいてＷｅｂページを表示した場合の表示構成が示されている。この表示構成例は、本実施形態に係る本ＤＯＭに基づく表示構成に対応する。図１７の例では、ＣＳＳファイルによりレイアウトが指定されるため、テキストデータＴの表示位置や画像データＭ２の表示位置が整っている。但し、ＤＯＭノードの内容がＪＳファイルの実行により書き換えられている。図１７の例では、ノードに含まれる画像データＭ１の表示指定が、画像データＭ２の表示指定に書き換えられている。
このように、簡易的なＤＯＭの構造によりＷｅｂページの表示結果には違いが生じる。しかし、本実施形態に係る仮ＤＯＭの構成と同様にＣＳＳファイルに関する構造単位を考慮することで、仮ＤＯＭに基づくＷｅｂページのレイアウトが整い、ユーザに大きな違和感を与えずに必要な情報を提示することが可能になる。
［２−６：ＤＯＭ構築ステップの具体例］
次に、図１８〜図６８を参照しながら、ＤＯＭ構築ステップの具体例について説明する。ここでは比較のために一般的なＷｅｂブラウザによるＤＯＭ構築ステップも示す。図１８〜図３５までの処理ステップは一般的なＷｅｂブラウザによるＤＯＭ構築ステップであり、図３６〜図６８までの処理ステップが本実施形態に係るＤＯＭ構築ステップである。
次に、図１８〜図６８を参照しながら、ＤＯＭ構築ステップの具体例について説明する。ここでは比較のために一般的なＷｅｂブラウザによるＤＯＭ構築ステップも示す。図１８〜図３５までの処理ステップは一般的なＷｅｂブラウザによるＤＯＭ構築ステップであり、図３６〜図６８までの処理ステップが本実施形態に係るＤＯＭ構築ステップである。
（一般的なＷｅｂブラウザによるＤＯＭ構築ステップ）
まず、一般的なＷｅｂブラウザによるＤＯＭ構築ステップについて説明する。ここでは図１８に例示したＨＴＭＬファイルを実行するケースについて説明する。
まず、一般的なＷｅｂブラウザによるＤＯＭ構築ステップについて説明する。ここでは図１８に例示したＨＴＭＬファイルを実行するケースについて説明する。
リダイレクトが発生すると、図１８に示すようなＨＴＭＬファイルがダウンロードされる。次いで、ダウンロードされたＨＴＭＬファイルの構造が解析される。まず、図１９に示すように、ＨＴＭＬファイルの先頭にある＜ｈｔｍｌ＞タグが読み込まれ、＜ｈｔｍｌ＞タグで囲まれた構造単位がＤＯＭのルートとして認識される。次いで、図２０に示すように、＜ｈｅａｄ＞タグが読み込まれ、＜ｈｅａｄ＞タグで囲まれた構造単位がＤＯＭのルートに従属するノードとして認識される。このとき、図２０に示すように、＜ｈｔｍｌ＞タグに相当するルートと、＜ｈｅａｄ＞タグに相当するノードとが紐付けられる。
次いで、図２１に示すように、＜ｍｅｔａ …＞タグが読み込まれ、＜ｍｅｔａ …＞タグで囲まれた構造単位が＜ｈｅａｄ＞タグのノードに従属する下位ノードとして認識される。このとき、図２１に示すように、＜ｈｅａｄ＞タグのノードと、＜ｍｅｔａ …＞タグのノードとが紐付けられる。
次いで、図２２に示すように、＜ｔｉｔｌｅ＞タグが読み込まれ、＜ｔｉｔｌｅ＞タグで囲まれた構造単位が＜ｈｅａｄ＞タグのノードに従属する下位ノードとして認識される。なお、＜ｍｅｔａ …＞タグと＜ｔｉｔｌｅ＞タグとは、同じ＜ｈｅａｄ＞タグに囲まれているため、図２２に示すように、＜ｔｉｔｌｅ＞タグは＜ｈｅａｄ＞タグに従属する。つまり、図２２に示すように、＜ｈｅａｄ＞タグのノードと＜ｔｉｔｌｅ＞タグのノードとが紐付けられる。
次いで、図２３に示すように、＜ｓｃｒｉｐｔ …＞タグが読み込まれ、＜ｓｃｒｉｐｔ …＞タグで囲まれた構造単位が＜ｈｅａｄ＞タグのノードに従属する下位ノードとして認識される。なお、＜ｍｅｔａ …＞タグ、＜ｔｉｔｌｅ＞タグ、及び＜ｓｃｒｉｐｔ …＞タグは、同じ＜ｈｅａｄ＞タグに囲まれているため、図２３に示すように、＜ｓｃｒｉｐｔ …＞タグは＜ｈｅａｄ＞タグに従属する。つまり、図２３に示すように、＜ｈｅａｄ＞タグのノードと＜ｓｃｒｉｐｔ …＞タグのノードとが紐付けられる。なお、＜ｓｃｒｉｐｔ …＞タグのノードは、スクリプト処理の実行に関する構造単位である。
図２３の例では、＜ｓｃｒｉｐｔ …＞タグの構造単位にＪＳのスクリプトファイルが対応付けられている。そのため、＜ｓｃｒｉｐｔ …＞タグが読み出された際、図２４に示すように、ＪＳのスクリプトファイルがダウンロードされ、ダウンロードされたＪＳのスクリプトファイルが実行される。このとき、ＪＳのスクリプトファイルにＤＯＭ構造を変更するような記述が含まれていると、この段階でＤＯＭ構造が変更される。例えば、図２５に示すように、ＪＳのスクリプトファイルに「ｄｏｃｕｍｅｎｔ．ｔｉｔｌｅ＝‘ｎｅｗ ｔｉｔｌｅ’；」と記載されていた場合、＜ｔｉｔｌｅ＞タグの内容が変更されるため、ＤＯＭに含まれる＜ｔｉｔｌｅ＞タグのノードが更新される。
次いで、図２６に示すように、＜ｌｉｎｋ …＞タグが読み込まれ、＜ｌｉｎｋ …＞タグで囲まれた構造単位が＜ｈｅａｄ＞タグのノードに従属する下位ノードとして認識される。なお、＜ｍｅｔａ …＞タグ、＜ｔｉｔｌｅ＞タグ、＜ｓｃｒｉｐｔ …＞タグ、及び＜ｌｉｎｋ …＞タグは、同じ＜ｈｅａｄ＞タグに囲まれているため、図２６に示すように、＜ｌｉｎｋ …＞タグは＜ｈｅａｄ＞タグに従属する。つまり、図２６に示すように、＜ｈｅａｄ＞タグのノードと＜ｌｉｎｋ …＞タグのノードとが紐付けられる。
なお、図２６の例では、＜ｌｉｎｋ …＞タグによりＣＳＳファイルが対応付けられている。そのため、この＜ｌｉｎｋ …＞タグのノードは、レイアウトの定義に関する構造単位である。従って、図２７に示すように、＜ｌｉｎｋ …＞タグが読み出された際、ＣＳＳファイルがダウンロードされ、ダウンロードされたＣＳＳファイルが適用される。例えば、図２７に示すように、ＣＳＳファイルに「ｂｏｄｙ｛ｔｅｘｔ−ａｌｉｇｎ：ｒｉｇｈｔ」と記載されていた場合、テキストデータの表示レイアウトが右詰に設定される。
次いで、図２８に示すように＜ｈｅａｄ＞タグで囲まれた構造単位の終位置を示す＜／ｈｅａｄ＞が読み込まれ、＜ｈｅａｄ＞タグのノードに従属するＤＯＭツリーの構築が完了する。次いで、図２９に示すように、＜ｂｏｄｙ＞タグが読み込まれ、＜ｂｏｄｙ＞タグで囲まれた構造単位がルートに従属するノードとして認識される。つまり、図２９に示すように、ルートと＜ｂｏｄｙ＞タグのノードとが紐付けられる。次いで、図３０、図３１に示すように＜ｂｏｄｙ＞タグで囲まれた構造単位の内容が読み込まれる。
図３１に示すように、＜ｂｏｄｙ＞タグで囲まれた構造単位には、画像データの指定が含まれている。そのため、図３２に示すように、指定された画像データがダウンロードされる。但し、図３２〜図３５に示すように、画像データのダウンロードが進行している最中でもＤＯＭの構築処理は進められる。そして、＜ｂｏｄｙ＞タグで囲まれた構造単位の終位置を示す＜／ｂｏｄｙ＞タグが読み込まれ、＜ｈｔｍｌ＞タグで囲まれた構造単位の終位置を示す＜／ｈｔｍｌ＞タグが読み込まれてＨＴＭＬファイルの解析が終了する。そして、ＤＯＭの生成が完了する。
以上、一般的なＷｅｂブラウザにおけるＤＯＭ構築ステップについて具体的に説明した。上記の通り、一般的なＷｅｂブラウザにおけるＤＯＭ構築ステップには、ＪＳのスクリプトファイルをダウンロード及び実行する工程が含まれている。そのため、スクリプト処理の逐次性に起因してＤＯＭの構築に長い時間がかかってしまう。
（本実施形態に係るＤＯＭ構築ステップ）
次に、本実施形態に係るＤＯＭ構築ステップについて説明する。なお、読み込まれるＨＴＭＬファイルは、図１８に示した上記例と同じもの（図３６を参照）と用いることにする。また、以下の説明において、第１スレッドの処理とは仮ＤＯＭの生成に係る処理を意味し、第２スレッドの処理とは本ＤＯＭの生成に係る処理を意味する。
次に、本実施形態に係るＤＯＭ構築ステップについて説明する。なお、読み込まれるＨＴＭＬファイルは、図１８に示した上記例と同じもの（図３６を参照）と用いることにする。また、以下の説明において、第１スレッドの処理とは仮ＤＯＭの生成に係る処理を意味し、第２スレッドの処理とは本ＤＯＭの生成に係る処理を意味する。
（第１スレッドの処理）
まず、第１スレッドの処理について説明する。
まず、第１スレッドの処理について説明する。
リダイレクトが発生すると、図３６のようにＨＴＭＬファイルがダウンロードされる。次いで、ダウンロードされたＨＴＭＬファイルの構造が解析される。まず、図３７に示すように、ＨＴＭＬファイルの先頭にある＜ｈｔｍｌ＞タグが読み込まれ、＜ｈｔｍｌ＞タグで囲まれた構造単位がＤＯＭのルートとして認識される。次いで、図３８に示すように、＜ｈｅａｄ＞タグが読み込まれ、＜ｈｅａｄ＞タグで囲まれた構造単位がＤＯＭのルートに従属するノードとして認識される。このとき、図３８に示すように、＜ｈｔｍｌ＞タグに相当するルートと、＜ｈｅａｄ＞タグに相当するノードとが紐付けられる。
次いで、図３９に示すように、＜ｍｅｔａ …＞タグが読み込まれ、＜ｍｅｔａ …＞タグで囲まれた構造単位が＜ｈｅａｄ＞タグのノードに従属する下位ノードとして認識される。このとき、図３９に示すように、＜ｈｅａｄ＞タグのノードと、＜ｍｅｔａ …＞タグのノードとが紐付けられる。
次いで、図４０に示すように、＜ｔｉｔｌｅ＞タグが読み込まれ、＜ｔｉｔｌｅ＞タグで囲まれた構造単位が＜ｈｅａｄ＞タグのノードに従属する下位ノードとして認識される。なお、＜ｍｅｔａ …＞タグと＜ｔｉｔｌｅ＞タグとは、同じ＜ｈｅａｄ＞タグに囲まれているため、図４０に示すように、＜ｔｉｔｌｅ＞タグは＜ｈｅａｄ＞タグに従属する。つまり、図４０に示すように、＜ｈｅａｄ＞タグのノードと＜ｔｉｔｌｅ＞タグのノードとが紐付けられる。
次いで、図４１に示すように、＜ｓｃｒｉｐｔ …＞タグが読み込まれる。しかし、本実施形態に係る第１スレッドのＤＯＭ構築ステップにおいては、図４２に示すように、＜ｓｃｒｉｐｔ …＞タグを読み飛ばし、＜ｓｃｒｉｐｔ …＞タグに囲まれた構造単位に関する処理を実行しない。つまり、ＪＳのスクリプトファイルのダウンロード及び実行を行わない。
次いで、図４３に示すように、＜ｌｉｎｋ …＞タグが読み込まれ、＜ｌｉｎｋ …＞タグで囲まれた構造単位が＜ｈｅａｄ＞タグのノードに従属する下位ノードとして認識される。なお、＜ｍｅｔａ …＞タグ、＜ｔｉｔｌｅ＞タグ、＜ｓｃｒｉｐｔ …＞タグ、及び＜ｌｉｎｋ …＞タグは、同じ＜ｈｅａｄ＞タグに囲まれているため、図４３に示すように、＜ｌｉｎｋ …＞タグは＜ｈｅａｄ＞タグに従属する。つまり、図４３に示すように、＜ｈｅａｄ＞タグのノードと＜ｌｉｎｋ …＞タグのノードとが紐付けられる。
なお、図４３の例では、＜ｌｉｎｋ …＞タグによりＣＳＳファイルが対応付けられている。そのため、この＜ｌｉｎｋ …＞タグのノードは、レイアウトの定義に関する構造単位である。従って、図４４に示すように、＜ｌｉｎｋ …＞タグが読み出された際、ＣＳＳファイルがダウンロードされ、ダウンロードされたＣＳＳファイルが適用される。例えば、図４４に示すように、ＣＳＳファイルに「ｂｏｄｙ｛ｔｅｘｔ−ａｌｉｇｎ：ｒｉｇｈｔ」と記載されていた場合、テキストデータの表示レイアウトが右詰に設定される。
次いで、図４５に示すように＜ｈｅａｄ＞タグで囲まれた構造単位の終位置を示す＜／ｈｅａｄ＞が読み込まれ、＜ｈｅａｄ＞タグのノードに従属するＤＯＭツリーの構築が完了する。次いで、図４６に示すように、＜ｂｏｄｙ＞タグが読み込まれ、＜ｂｏｄｙ＞タグで囲まれた構造単位がルートに従属するノードとして認識される。つまり、図４６に示すように、ルートと＜ｂｏｄｙ＞タグのノードとが紐付けられる。次いで、図４７、図４８に示すように＜ｂｏｄｙ＞タグで囲まれた構造単位の内容が読み込まれる。
図４８に示すように、＜ｂｏｄｙ＞タグで囲まれた構造単位には、画像データの指定が含まれている。そのため、図４９に示すように、指定された画像データがダウンロードされる。但し、図４９〜図５２に示すように、画像データのダウンロードが進行している最中でも仮ＤＯＭの構築処理は進められる。そして、＜ｂｏｄｙ＞タグで囲まれた構造単位の終位置を示す＜／ｂｏｄｙ＞タグが読み込まれ、＜ｈｔｍｌ＞タグで囲まれた構造単位の終位置を示す＜／ｈｔｍｌ＞タグが読み込まれてＨＴＭＬファイルの解析が終了する。そして、仮ＤＯＭの生成が完了する。
このように、第１スレッドにおける仮ＤＯＭの構築ステップにおいては、ＪＳのスクリプトファイルのダウンロード及び実行をスキップする。そのため、スクリプト処理の逐次性に起因して生じる処理遅延が発生せず、素早く仮ＤＯＭが構築される。
（第２スレッドの処理）
次に、第２スレッドの処理について説明する。但し、第２スレッドの処理は、第１スレッドの処理と同じタイミングで開始される。また、各種ファイルのダウンロードは、ダウンロードマネージャスレッドにより行われるため、第１スレッドが利用するために既にダウンロードしたファイルを重複してダウンロードする必要はない。
次に、第２スレッドの処理について説明する。但し、第２スレッドの処理は、第１スレッドの処理と同じタイミングで開始される。また、各種ファイルのダウンロードは、ダウンロードマネージャスレッドにより行われるため、第１スレッドが利用するために既にダウンロードしたファイルを重複してダウンロードする必要はない。
リダイレクトが発生すると、図５３に示すように、ＨＴＭＬファイルの構造が解析される。このとき、ダウンロードマネージャスレッドでは、必要なファイルのダウンロードが進行している。まず、図５４に示すように、ＨＴＭＬファイルの先頭にある＜ｈｔｍｌ＞タグが読み込まれ、＜ｈｔｍｌ＞タグで囲まれた構造単位がＤＯＭのルートとして認識される。次いで、図５５に示すように、＜ｈｅａｄ＞タグが読み込まれ、＜ｈｅａｄ＞タグで囲まれた構造単位がＤＯＭのルートに従属するノードとして認識される。このとき、図５５に示すように、＜ｈｔｍｌ＞タグに相当するルートと、＜ｈｅａｄ＞タグに相当するノードとが紐付けられる。
次いで、図５６に示すように、＜ｍｅｔａ …＞タグが読み込まれ、＜ｍｅｔａ …＞タグで囲まれた構造単位が＜ｈｅａｄ＞タグのノードに従属する下位ノードとして認識される。このとき、図５６に示すように、＜ｈｅａｄ＞タグのノードと、＜ｍｅｔａ …＞タグのノードとが紐付けられる。
次いで、図５７に示すように、＜ｔｉｔｌｅ＞タグが読み込まれ、＜ｔｉｔｌｅ＞タグで囲まれた構造単位が＜ｈｅａｄ＞タグのノードに従属する下位ノードとして認識される。なお、＜ｍｅｔａ …＞タグと＜ｔｉｔｌｅ＞タグとは、同じ＜ｈｅａｄ＞タグに囲まれているため、図５７に示すように、＜ｔｉｔｌｅ＞タグは＜ｈｅａｄ＞タグに従属する。つまり、図５７に示すように、＜ｈｅａｄ＞タグのノードと＜ｔｉｔｌｅ＞タグのノードとが紐付けられる。
次いで、図５８に示すように、＜ｓｃｒｉｐｔ …＞タグが読み込まれ、＜ｓｃｒｉｐｔ …＞タグで囲まれた構造単位が＜ｈｅａｄ＞タグのノードに従属する下位ノードとして認識される。なお、＜ｍｅｔａ …＞タグ、＜ｔｉｔｌｅ＞タグ、及び＜ｓｃｒｉｐｔ …＞タグは、同じ＜ｈｅａｄ＞タグに囲まれているため、図５８に示すように、＜ｓｃｒｉｐｔ …＞タグは＜ｈｅａｄ＞タグに従属する。つまり、図５８に示すように、＜ｈｅａｄ＞タグのノードと＜ｓｃｒｉｐｔ …＞タグのノードとが紐付けられる。なお、＜ｓｃｒｉｐｔ …＞タグのノードは、スクリプト処理の実行に関する構造単位である。
図５８の例では、＜ｓｃｒｉｐｔ …＞タグの構造単位にＪＳのスクリプトファイルが対応付けられている。そのため、＜ｓｃｒｉｐｔ …＞タグが読み出された際、図５９に示すように、ＪＳのスクリプトファイルがダウンロードされ、ダウンロードされたＪＳのスクリプトファイルが実行される。このとき、ＪＳのスクリプトファイルにＤＯＭ構造を変更するような記述が含まれていると、この段階でＤＯＭ構造が変更される。例えば、図６０に示すように、ＪＳのスクリプトファイルに「ｄｏｃｕｍｅｎｔ．ｔｉｔｌｅ＝‘ｎｅｗ ｔｉｔｌｅ’；」と記載されていた場合、＜ｔｉｔｌｅ＞タグの内容が変更されるため、本ＤＯＭに含まれる＜ｔｉｔｌｅ＞タグのノードが更新される。
このように、第２スレッドのＤＯＭ構築ステップにおいては、第１スレッドのＤＯＭ構築ステップで読み飛ばされた＜ｓｃｒｉｐｔ …＞タグが読み込まれ、ＪＳのスクリプトファイルのダウンロード及び実行が行われる。
次いで、図６１に示すように、＜ｌｉｎｋ …＞タグが読み込まれ、＜ｌｉｎｋ …＞タグで囲まれた構造単位が＜ｈｅａｄ＞タグのノードに従属する下位ノードとして認識される。なお、＜ｍｅｔａ …＞タグ、＜ｔｉｔｌｅ＞タグ、＜ｓｃｒｉｐｔ …＞タグ、及び＜ｌｉｎｋ …＞タグは、同じ＜ｈｅａｄ＞タグに囲まれているため、図６１に示すように、＜ｌｉｎｋ …＞タグは＜ｈｅａｄ＞タグに従属する。つまり、図６１に示すように、＜ｈｅａｄ＞タグのノードと＜ｌｉｎｋ …＞タグのノードとが紐付けられる。
なお、図６１の例では、＜ｌｉｎｋ …＞タグによりＣＳＳファイルが対応付けられている。そのため、この＜ｌｉｎｋ …＞タグのノードは、レイアウトの定義に関する構造単位である。従って、第１スレッドのＤＯＭ構築ステップと同様にＣＳＳファイルが適用される。例えば、図６１に示すように、ＣＳＳファイルに「ｂｏｄｙ｛ｔｅｘｔ−ａｌｉｇｎ：ｒｉｇｈｔ」と記載されていた場合、テキストデータの表示レイアウトが右詰に設定される。但し、ＣＳＳファイルは、ダウンロードマネージャスレッドにより既にダウンロードされている。
次いで、図６２に示すように＜ｈｅａｄ＞タグで囲まれた構造単位の終位置を示す＜／ｈｅａｄ＞が読み込まれ、＜ｈｅａｄ＞タグのノードに従属するＤＯＭツリーの構築が完了する。次いで、図６３に示すように、＜ｂｏｄｙ＞タグが読み込まれ、＜ｂｏｄｙ＞タグで囲まれた構造単位がルートに従属するノードとして認識される。つまり、図６３に示すように、ルートと＜ｂｏｄｙ＞タグのノードとが紐付けられる。次いで、図６４、図６５に示すように＜ｂｏｄｙ＞タグで囲まれた構造単位の内容が読み込まれる。
図６５に示すように、＜ｂｏｄｙ＞タグで囲まれた構造単位には、画像データの指定が含まれている。そのため、図６５に示すように、指定された画像データがダウンロードされる。但し、第１スレッドのＤＯＭ構築ステップにおいて既にダウンロードされている画像データは改めてダウンロードされない。つまり、ここでダウンロードされるのは、第２スレッドのＤＯＭ構築ステップにおいて新たにダウンロードが必要になった画像データである。図６５の例では、第１スレッドのＤＯＭ構築ステップにおいて同じ画像データがダウンロードされているため、改めて画像データのダウンロードを行う必要はない。
次いで、図６６に示すように、＜ｂｏｄｙ＞タグで囲まれた構造単位の終位置を示す＜／ｂｏｄｙ＞タグが読み込まれる。さらに、図６７に示すように、＜ｈｔｍｌ＞タグで囲まれた構造単位の終位置を示す＜／ｈｔｍｌ＞タグが読み込まれてＨＴＭＬファイルの解析が終了する。そして、図６８に示すように、本ＤＯＭの生成が完了する。
このように、第２スレッドのＤＯＭ構築ステップにおいては、第１スレッドのＤＯＭ構築ステップでスキップされたスクリプトファイルのダウンロード及び実行の処理が行われ、本来構築されるべきＤＯＭ（本ＤＯＭ）が生成される。上記の通り、本ＤＯＭの構築ステップは、一般的なＷｅｂブラウザによるＤＯＭ構築ステップと実質的に同じである。つまり、本ＤＯＭは、ＪＳを含めたＨＴＭＬファイルの構造単位を正規の順番で読み込み、実行してから構築されたものである。従って、本ＤＯＭに基づくＷｅｂページは、制作者の意図を正確に反映したレイアウト及び動作を有するものとなる。
先に説明した通り、第１スレッドにおいて仮ＤＯＭが構築されると、仮ＤＯＭをレンダリングして仮ＤＯＭに基づくＷｅｂページが生成され、画面上に表示される。仮ＤＯＭの構築ステップにはスクリプトファイルのダウンロード及び実行の処理が含まれていないため、仮ＤＯＭに基づくＷｅｂページは素早く表示される。一方、本ＤＯＭの構築が完了すると、本ＤＯＭをレンダリングして本ＤＯＭに基づくＷｅｂページが生成され、仮ＤＯＭに基づくＷｅｂページと差し替えられる。そのため、Ｗｅｂページの制作者が本来意図していた構成を有するＷｅｂページを閲覧することが可能になる。
その結果、素早く必要な情報を取得したいという要求と、Ｗｅｂページ制作者の意図を正確に反映したＷｅｂページを閲覧したいという要求とを共に満たすことが可能になる。このような構成は、モバイルデータ回線のような不安定なネットワーク環境において特に大きな効果を発揮する。また、比較的演算能力の高い機器に適用する方が好ましい。
なお、上記説明においては、第１スレッド、第２スレッドという表現を用いたが、必ずしも２本の実スレッドにより仮ＤＯＭ／本ＤＯＭの構築処理を実行する必要はない。つまり、論理的に２種類の処理を実行することができれば、実スレッドを２本用意して独立に処理を実行することまでは要求されない点に注意されたい。また、上記説明においては、ＨＴＭＬファイルの解析、及びＨＴＭＬファイルに含まれる構造単位に基づくＤＯＭの構築について説明したが、他の構造化言語で記述されたファイルの解析及びツリー構造の構築処理にも応用できる。そして、このような応用例も、本実施形態の技術的範囲に含まれることは言うまでもない。
（変形例等について）
さて、ここまでは、ＨＴＭＬファイルの中にスクリプト処理に関する構造単位が含まれているものとして説明してきた。しかし、実際にはスクリプト処理に関する構造単位が含まれていないＨＴＭＬファイルも多数存在する。スクリプト処理に関する構造単位が含まれていないＨＴＭＬファイルの場合、そのＨＴＭＬファイルから構築される仮ＤＯＭと本ＤＯＭとは同じ構造となる。
さて、ここまでは、ＨＴＭＬファイルの中にスクリプト処理に関する構造単位が含まれているものとして説明してきた。しかし、実際にはスクリプト処理に関する構造単位が含まれていないＨＴＭＬファイルも多数存在する。スクリプト処理に関する構造単位が含まれていないＨＴＭＬファイルの場合、そのＨＴＭＬファイルから構築される仮ＤＯＭと本ＤＯＭとは同じ構造となる。
そこで、仮ＤＯＭの構築ステップを実行中に、ＨＴＭＬファイルがスクリプト処理に関する構造単位を含まないものであることが判明した場合、本ＤＯＭの構築ステップを停止するように変形する。このように変形することにより、本ＤＯＭを生成せずに済むため、本ＤＯＭの生成に要する演算負荷を低減させることができる。なお、本ＤＯＭを生成しないのであるから、仮ＤＯＭに基づくＷｅｂページを本ＤＯＭに基づくＷｅｂページへと差し替える処理も省略される。
また、上記説明においては、Ｗｅｂページ全体を本実施形態に係る技術の適用範囲にしていたが、Ｗｅｂブラウザのタブ単位、ウィンドウ単位、フレーム単位で上記技術を実施することも可能である。また、適用するドメインやＵＲＬ等を指定できるように変形してもよい。さらに、Ｗｅｂブラウジングの際に検出された表示時間の長短に基づいて上記技術を適用すべきサイトを選択し、表示にかかる時間の長いサイトに上記技術を適用するように構成することも可能である。
＜３：第２実施形態＞
次に、本発明の第２実施形態について説明する。本実施形態は、ユーザによりＷｅｂページの表示が要求される前に、Ｗｅｂページの表示に要するファイルを予め取得（プリフェッチ）しておく方法に関する。この方法を用いると、ユーザによりＷｅｂページの表示が要求された後にファイルをダウンロードせずに済むため、Ｗｅｂページの表示までにかかる時間を大幅に短縮することができる。
次に、本発明の第２実施形態について説明する。本実施形態は、ユーザによりＷｅｂページの表示が要求される前に、Ｗｅｂページの表示に要するファイルを予め取得（プリフェッチ）しておく方法に関する。この方法を用いると、ユーザによりＷｅｂページの表示が要求された後にファイルをダウンロードせずに済むため、Ｗｅｂページの表示までにかかる時間を大幅に短縮することができる。
なお、閲覧中のＷｅｂページに記述されている全てのリンク先からＷｅｂページの表示に用いるデータをプリフェッチしておく方法については既に知られている。しかし、閲覧中のＷｅｂページに多数のリンク先が記述されていたり、リンク先のＷｅｂページを表示するためのファイルが大量に存在すると、プリフェッチにより帯域が占有されてしまう。また、プリフェッチしたファイルをキャッシュするのに大容量のメモリが必要になってしまう。一方、ユーザが選択する可能性の高いリンク先を適切に選択することは、ユーザの行動予測を伴うため非常に難しい。また、ユーザの行動予測には高い演算能力が要求されるため、上記第１実施形態に係る技術を求めるような情報処理装置においては実現が困難である。そこで、本実施形態においては、上記第１実施形態に係る技術の利用を前提として、プリフェッチするファイルサイズを抑制する方法を提案する。
［３−１：プリフェッチによる効果（検討）］
ここでは、図６９〜図７２を参照しながら、プリフェッチによる効果について考える。
ここでは、図６９〜図７２を参照しながら、プリフェッチによる効果について考える。
まず、図６９を参照する。上記の通り、本実施形態に係るプリフェッチ方法は、上記第１実施形態に係る技術の利用を前提とするものである。つまり、スクリプトファイルのダウンロード及び実行を後回しにする方法を前提とする。そのため、仮ＤＯＭの構築に要するＨＴＭＬファイル、及びＣＳＳファイルのプリフェッチを考えればよい。また、画像データ等もプリフェッチの対象から外すことで、プリフェッチによりキャッシュすべきデータの量を大幅に削減することができる。このような構成にしても、ある程度レイアウトが整った状態でテキストデータが表示されるため、十分な情報が比較的見やすい形でユーザに提示される。
図７０、図７１は、（ケース１）プリフェッチなし、（ケース２）ＨＴＭＬファイル及びＣＳＳファイルをプリフェッチ、（ケース３）ＨＴＭＬファイル、ＣＳＳファイル、ＪＳファイルをプリフェッチ、（ケース４）全てのファイルをプリフェッチの４通りを比較したものである。
まず、図７０を参照する。図７０の左図は、プリフェッチしたファイル数を比較したものである。一方、図７０の右図は、プリフェッチしたファイルの合計サイズを比較したものである。図７０から分かるように、（ケース４）は、プリフェッチすべきファイル数もファイルサイズも他のケースに比べて桁違いに大きい。つまり、Ｗｅｂページを構成する全てのデータをプリフェッチする一般的なプリフェッチ方法を適用すると、非常に大きなキャッシュメモリが必要になることが分かる。一方、（ケース２）、（ケース３）のようなプリフェッチ方法を用いれば、全てプリフェッチする（ケース４）のプリフェッチ方法に比べてキャッシュすべきデータを減らすことが可能になることが分かる。さらに、上記（ケース２）と上記（ケース３）との比較に注目すると、ＪＳファイルの有無だけでもキャッシュデータの量に顕著な差が生じることが分かる。
次に、図７１を参照する。図７１は、２種類のＷｅｂページについて、上記（ケース１）〜（ケース４）のプリフェッチ方法を適用した場合における表示開始までの時間を比較したものである。当然のことながら、Ｗｅｂページの表示開始に必要なファイルをプリフェッチしている分だけ、上記（ケース２）〜（ケース４）は、表示時間が短くて済んでいる。また、ＪＳ処理の有無について比較すると、ＪＳ処理が生じないことにより得られる時間短縮の効果は顕著である。もちろん、Ｗｅｂページの種類によりＪＳ処理を省略して得られる効果の大きさは異なるが、一概に効果が得られることは分かった。こうした結果から、ＨＴＭＬファイル及びＣＳＳファイルだけをプリフェッチする上記（ケース２）の構成により、キャッシュメモリを節約しつつも、十分な時間短縮の効果が得られるものと期待される。
また、上記第１実施形態の技術と組み合わせ、プリフェッチしたＨＴＭＬファイル及びＣＳＳファイルから仮ＤＯＭを構築し、仮ＤＯＭに基づくＷｅｂページを表示することにより、より素早くＷｅｂページが表示されるものと期待される。なお、プリフェッチの対象とするＷｅｂページの候補としては、図７２に示すように、（候補１）ブックマークリストに登録されているリンク先、（候補２）検索結果に含まれるリンク先の上位所定数のもの、（候補３）閲覧ページ内のリンク先等が考えられる。また、（候補１）、（候補２）、（候補３）の順で所定数のリンク先を選択するようにしてもよい。さらに、これらの候補の組み合わせをユーザが決め、その組み合わせの中から所定数のリンク先を選択するようにしてもよい。
以上説明したように、本実施形態は、ＨＴＭＬファイル及びＣＳＳファイルをプリフェッチする方法を提案するものである。もちろん、ＨＴＭＬファイルは一例であり、ＨＴＭＬファイルに代えて他の構造化言語で記述されたファイルを用いてもよい。また、ＣＳＳファイルは一例であり、ＣＳＳファイルに代えて表示レイアウトを調整するための他の形式のファイルを用いてもよい。いずれにせよ、これら２種類のファイルをプリフェッチしておくことにより、仮ＤＯＭに基づくＷｅｂページをより素早く表示することが可能になる。以下、本実施形態に係るプリフェッチ方法について詳細に説明する。
［３−２：情報処理装置１００の機能構成］
まず、図７３を参照しながら、上記のアイデアを実現することが可能な情報処理装置１００の機能構成について説明する。図７３は、本実施形態に係る情報処理装置１００の機能構成例を示す説明図である。なお、上記第１実施形態及び後述する第３実施形態に係る情報処理装置１００と区別するために、本実施形態に係る情報処理装置１００を情報処理装置１００Ｂと表記する場合がある。
まず、図７３を参照しながら、上記のアイデアを実現することが可能な情報処理装置１００の機能構成について説明する。図７３は、本実施形態に係る情報処理装置１００の機能構成例を示す説明図である。なお、上記第１実施形態及び後述する第３実施形態に係る情報処理装置１００と区別するために、本実施形態に係る情報処理装置１００を情報処理装置１００Ｂと表記する場合がある。
図７３に示すように、情報処理装置１００は、主に、データ取得部１１０と、構造解析部１２０と、レンダリング部１３０と、表示部１４０と、通信部１５０と、リンク選択部１６０とにより構成される。また、レンダリング部１３０は、仮ＤＯＭ生成部１３１と、本ＤＯＭ生成部１３２と、キャッシュメモリ１３３と、表示制御部１３４と、ノード情報格納部１３５とを有する。上記第１実施形態に係る情報処理装置１００Ａとの主な違いは、通信部１５０、及びリンク選択部１６０の有無にある。従って、以下では通信部１５０、及びリンク選択部１６０の機能を中心に説明する。
通信部１５０は、ネットワーク２００を通じてＷｅｂサーバ３１０、３２０と通信するための通信手段である。なお、Ｗｅｂサーバ３１０、３２０からファイルをダウンロードするには、ＤＮＳサーバへとアクセスして名前解決を行ったり、ＴＣＰコネクションを確立したりする必要がある。また、Ｗｅｂサーバ３１０、３２０からリダイレクトを取得する必要もある。通信部１５０は、必要に応じてＷｅｂサーバ３１０、３２０との通信に関する上記処理等を実行する。
また、リンク選択部１６０は、プリフェッチの対象とするリンク先を選択する手段である。上記の通り、プリフェッチの対象とするリンク先として、（候補１）ブックマークリストに登録されているリンク先、（候補２）検索結果に含まれるリンク先の上位所定数のもの、（候補３）閲覧ページ内のリンク先等が考えられる。例えば、（候補２）に設定されている場合、リンク選択部１６０は、検索エンジンにより出力された検索結果に含まれるリンク先を所定数選択する。上記（候補１）（候補３）の場合にも同様に、リンク選択部１６０は、所定数のリンク先を選択する。
さらに、リンク選択部１６０は、選択したリンク先に対し、所定のルールに基づいてプリフェッチの種類を割り当てる。例えば、リンク選択部１６０は、上位Ｎ１個のリンク先に対し、ＨＴＭＬファイル及びＣＳＳファイルをプリフェッチする第１手法を割り当て、次のＮ２個のリンク先に対し、リダイレクトをプリフェッチする第２手法を割り当てる。また、リンク選択部１６０は、次のＮ３個のリンク先に対応するＷｅｂサーバ３１０、３２０に対し、ＴＣＰコネクションを確立させておく第３手法を割り当てたり、ＤＮＳによる名前解決を先行して行っておく第４手法を割り当てたりする。以下、第１手法をファイルプリフェッチ、第２手法をリダイレクトプリフェッチ、第３手法をプリコネクション、第４手法をＤＮＳプリフェッチと呼ぶことにする。
リンク選択部１６０により選択されたリンク先の情報、及び各リンク先に割り当てられたプリフェッチの種類は、データ取得部１１０及び通信部１５０に入力される。
例えば、ファイルプリフェッチ又はリダイレクトプリフェッチに割り当てられたリンク先の情報は、データ取得部１１０に入力される。ファイルプリフェッチに割り当てられたリンク先の情報が入力されると、データ取得部１１０は、入力されたリンク先の情報が示すリンク先からＨＴＭＬファイル及びＣＳＳファイルをダウンロードしてキャッシュする。一方、リダイレクトプリフェッチが割り当てられたリンク先の情報が入力されると、データ取得部１１０は、入力されたリンク先の情報が示すリンク先からリダイレクト用のコードを取得し、必要に応じてリダイレクト先のＵＲＬを読みに行く。
また、プリコネクション又はＤＮＳプリフェッチに割り当てられたリンク先の情報は、通信部１５０に入力される。プリコネクションに割り当てられたリンク先の情報が入力されると、通信部１５０は、入力されたリンク先の情報が示すリンク先との間でＴＣＰコネクションを確立させる。但し、プリコネクションの場合、ファイルのダウンロード等は行われない。一方、ＤＮＳプリフェッチが割り当てられたリンク先の情報が入力されると、通信部１５０は、入力されたリンク先の情報が示すリンク先に接続するための名前解決を行う。但し、ＤＮＳプリフェッチの場合、ＴＣＰコネクションの確立までは行われない。
上記のファイルプリフェッチ、リダイレクトプリフェッチ、プリコネクション、ＤＮＳプリフェッチは、ユーザによりリンク先が指定される前に実行される。ファイルプリフェッチが実行される場合には、ＨＴＭＬファイルが取得された後、ＨＴＭＬファイルの解析が実行され、必要に応じてＣＳＳファイルのダウンロードが実行される。そして、ユーザによりリンク先が指定されると、レンダリング部１３０により仮ＤＯＭ、本ＤＯＭの構築が開始される。仮ＤＯＭ、本ＤＯＭの構築方法、及びＷｅｂページの表示及び差し替え処理については、上記第１実施形態に係る情報処理装置１００Ａの処理と実質的に同じである。従って、詳細な説明は省略することにする。
以上、本実施形態に係る情報処理装置１００の機能構成について説明した。
［３−３：情報処理装置１００の動作］
次に、図７４を参照しながら、本実施形態に係る情報処理装置１００の動作について説明する。図７４は、本実施形態に係る情報処理装置１００の動作フローを示す説明図である。但し、図７４に示した動作フローは、検索エンジンにより検索された結果から、所定数のリンク先を選択し、ファイルプリフェッチを行う構成に関する。
次に、図７４を参照しながら、本実施形態に係る情報処理装置１００の動作について説明する。図７４は、本実施形態に係る情報処理装置１００の動作フローを示す説明図である。但し、図７４に示した動作フローは、検索エンジンにより検索された結果から、所定数のリンク先を選択し、ファイルプリフェッチを行う構成に関する。
図７４に示すように、まず、情報処理装置１００は、検索結果に含まれるリンク先の一部を選択する（ステップＳ２０１）。次いで、情報処理装置１００は、選択したリンク先からＨＴＭＬファイル及びＣＳＳファイルをダウンロードする（ステップＳ２０２）。次いで、情報処理装置１００は、選択したリンク先のいずれかがユーザにより選択されたか否かを判定する（ステップＳ２０３）。ユーザにより選択された場合、情報処理装置１００は、ステップＳ２０４の処理に進行する。一方、ユーザにより選択されていない場合、情報処理装置１００は、再びステップＳ２０３の処理に戻る。
ステップＳ２０４の処理に進行した場合、情報処理装置１００は、ファイルプリフェッチにより予めダウンロードしてキャッシュしておいたＨＴＭＬファイルを解析し、ＨＴＭＬの記述に関する各構造単位、及びＣＳＳファイルに関する構造単位を相互に紐付けて仮ＤＯＭの生成を開始する（ステップＳ２０４）。次いで、情報処理装置１００は、ユーザにより選択されたリンク先からＪＳファイルをダウンロードする（ステップＳ２０５）。次いで、情報処理装置１００は、ＨＴＭＬファイル、ＣＳＳファイル、ＪＳファイルを用いて本ＤＯＭの生成を開始する（ステップＳ２０６）。
次いで、情報処理装置１００は、仮ＤＯＭの生成が完了したか否かを判定する（ステップＳ２０７）。仮ＤＯＭの生成が完了した場合、情報処理装置１００は、ステップＳ２０８の処理に進行する。一方、仮ＤＯＭの生成が完了していない場合、情報処理装置１００は、再びステップＳ２０７の処理に戻る。ステップＳ２０８の処理に進行した場合、情報処理装置１００は、仮ＤＯＭをレンダリングしてＷｅｂページを生成し、生成したＷｅｂページを表示画面に表示する（ステップＳ２０８）。
次いで、情報処理装置１００は、本ＤＯＭの生成が完了したか否かを判定する（ステップＳ２０９）。本ＤＯＭの生成が完了した場合、情報処理装置１００は、ステップＳ２１０の処理に進行する。一方、本ＤＯＭの生成が完了していない場合、情報処理装置１００は、再びステップＳ２０９に戻る。ステップＳ２１０に進行した場合、情報処理装置１００は、本ＤＯＭをレンダリングしてＷｅｂページを生成し、仮ＤＯＭに基づくＷｅｂページと差し替え（ステップＳ２１０）、一連の処理を終了する。
以上、本実施形態に係る情報処理装置１００の動作フローについて説明した。
［３−４：プリフェッチ処理の流れ］
次に、図７５を参照しながら、本実施形態に係るプリフェッチ処理の流れについて説明する。図７５は、本実施形態に係るプリフェッチ処理の流れを示す説明図である。なお、図７５に示す処理は、情報処理装置１００により実行される。
次に、図７５を参照しながら、本実施形態に係るプリフェッチ処理の流れについて説明する。図７５は、本実施形態に係るプリフェッチ処理の流れを示す説明図である。なお、図７５に示す処理は、情報処理装置１００により実行される。
図７５に示すように、まず、リクエストＵＲＬが検索サイトのＵＲＬであるか否かが判定される（ステップＳ３０１）。検索サイトのＵＲＬである場合、処理は、ステップＳ３０２に進行する。一方、検索サイトのＵＲＬでない場合、処理は、ステップＳ３０１に戻る。ステップＳ３０２に進行すると、取得された検索サイトのＨＴＭＬファイルがパースされ、プリフェッチすべきリンク先のリスト（以下、プリフェッチリスト）が抽出される（ステップＳ３０２）。次いで、抽出されたリンク先のうち、ｉ番目のＵＲＬ（Ｘｉ）が既にキャッシュされているか否かが判定される（ステップＳ３０３）。Ｘｉがキャッシュされている場合、処理は、ステップＳ３０７に進行する。一方、Ｘｉがキャッシュされていない場合、処理は、ステップＳ３０４に進行する。
ステップＳ３０４に進行した場合、ＸｉからＨＴＭＬファイルを取得するためのコマンド（ＧＥＴ）が発行され、ＨＴＭＬファイルが取得される（ステップＳ３０４）。次いで、取得されたＨＴＭＬファイルがパースされ、ＨＴＭＬファイルに記述されているＣＳＳファイルのリンク先が抽出される（ステップＳ３０５）。さらに、ＣＳＳファイルを取得するためのコマンド（ＧＥＴ）が発行され、ＣＳＳファイルが取得される（ステップＳ３０５）。次いで、取得されたＨＴＭＬファイル、ＣＳＳファイルがキャッシュされる（ステップＳ３０６）。次いで、プリフェッチリストからＸｉが削除される（ステップＳ３０７）。次いで、プリフェッチリストにｉ＋１番目のＵＲＬ（Ｘ（ｉ＋１））が存在するか否かが判定される（ステップＳ３０８）。Ｘ（ｉ＋１）が存在する場合、処理は、再びステップＳ３０３に戻る。一方、Ｘ（ｉ＋１）が存在しない場合、一連の処理が終了する。
以上、本実施形態に係るプリフェッチ処理の流れについて説明した。なお、ユーザがＵＲＬリンクをクリックした段階でプリフェッチ処理はキャンセルされる。
［３−５：プリフェッチによる効果］
次に、図７６を参照しながら、上記のプリフェッチによる効果について説明する。図７６には、ＤＮＳプリフェッチ、プリコネクション（コネクションプリフェッチ）、リダイレクトプリフェッチ、ファイルプリフェッチ、全ファイルのプリフェッチの効果比較が記載されている。図７６に示すように、全てのファイルをプリフェッチする場合に比べ、本実施形態に係るファイルプリフェッチは、必要通信量が格段に少なくて済んでいる。また、ＤＮＳプリフェッチ、プリコネクション、リダイレクトプリフェッチによる効果も非常に大きい。つまり、本実施形態に係るプリフェッチを適用することにより、プリフェッチによる通信量の増大を抑制することが可能になる。また、ページの表示時間を比較しても、本実施形態に係るファイルプリフェッチと、全てのファイルをプリフェッチした場合とで大きな効果の差はないことが分かる。このように、本実施形態に係るファイルプリフェッチを巧く利用することにより、Ｗｅｂページの表示を十分に高速化しつつ、プリフェッチによるメモリ容量の圧迫や占有帯域の浪費を抑制することが可能になる。
次に、図７６を参照しながら、上記のプリフェッチによる効果について説明する。図７６には、ＤＮＳプリフェッチ、プリコネクション（コネクションプリフェッチ）、リダイレクトプリフェッチ、ファイルプリフェッチ、全ファイルのプリフェッチの効果比較が記載されている。図７６に示すように、全てのファイルをプリフェッチする場合に比べ、本実施形態に係るファイルプリフェッチは、必要通信量が格段に少なくて済んでいる。また、ＤＮＳプリフェッチ、プリコネクション、リダイレクトプリフェッチによる効果も非常に大きい。つまり、本実施形態に係るプリフェッチを適用することにより、プリフェッチによる通信量の増大を抑制することが可能になる。また、ページの表示時間を比較しても、本実施形態に係るファイルプリフェッチと、全てのファイルをプリフェッチした場合とで大きな効果の差はないことが分かる。このように、本実施形態に係るファイルプリフェッチを巧く利用することにより、Ｗｅｂページの表示を十分に高速化しつつ、プリフェッチによるメモリ容量の圧迫や占有帯域の浪費を抑制することが可能になる。
［３−６：プリコネクションによる効果（検討）］
次に、図７７〜図８０を参照しながら、上記のプリコネクションの適用ケースについて検討してみたい。上記の通り、本実施形態に係るファイルプリフェッチ方法、及び仮ＤＯＭに基づくＷｅｂページの表示方法を利用すれば、不安定で低速な回線を利用していても、見やすい形で素早くＷｅｂページを表示することができる。また、プリフェッチにより通信量が増加してしまうのを極力防止することができ、通信費の節約にも繋がる。既に述べていることであるが、全てのリンク先にファイルプリフェッチを適用するのは必ずしも得策であるとは言えない。例えば、ユーザにより選択される可能性の低いリンク先に対してファイルプリフェッチを適用するのは効率が良くない。そこで、プリコネクションを巧く組み合わせ、プリフェッチによる通信量をさらに抑制する方法について考えてみたい。
次に、図７７〜図８０を参照しながら、上記のプリコネクションの適用ケースについて検討してみたい。上記の通り、本実施形態に係るファイルプリフェッチ方法、及び仮ＤＯＭに基づくＷｅｂページの表示方法を利用すれば、不安定で低速な回線を利用していても、見やすい形で素早くＷｅｂページを表示することができる。また、プリフェッチにより通信量が増加してしまうのを極力防止することができ、通信費の節約にも繋がる。既に述べていることであるが、全てのリンク先にファイルプリフェッチを適用するのは必ずしも得策であるとは言えない。例えば、ユーザにより選択される可能性の低いリンク先に対してファイルプリフェッチを適用するのは効率が良くない。そこで、プリコネクションを巧く組み合わせ、プリフェッチによる通信量をさらに抑制する方法について考えてみたい。
図７７に示すように、表示中のＷｅｂページに含まれるリンク先をユーザがクリックする前にリンク先のホストとの間で予めＴＣＰコネクションを確立しておくことが望ましい。また、ユーザがＵＲＬを入力中に、指定先のホストとの間で予めＴＣＰコネクションを確立しておくことも効果的である。また、図７８に示すように、近い未来にユーザによりクリックされる確率の高いリンク先の種類を決めておき、その種類のリンク先に対してプリコネクションを適用することが望ましい。ユーザによるクリックの確率が高いリンク先としては、図７８に示すように、例えば、（選択候補１）検索結果の画面上位に表示されているもの、（選択候補２）閲覧中の画面内に表示されているもの、（選択候補３）閲覧履歴の中で高頻度にアクセスしているもの、（選択候補４）マウスポインタ等、ユーザが操作する操作体の位置から近いリンク先などが挙げられる。
また、上記第１実施形態の技術及び本実施形態に係るプリフェッチやプリコネクションを適用することにより得られる効果が大きいリンク先を選択する方法も考えられる。この場合、選択対象は、例えば、特定のドメイン、国、実測された応答時間、コネクション確立時間の履歴等に基づいて決定される。図７９、図８０に示すように、リンク先ＵＲＬのＴＬＤ（Ｔｏｐ Ｌｅｖｅｌ Ｄｏｍａｉｎ）やリンク先ホストが位置する国により、コネクション確立時間が大きく異なる。図７９は、日本から各ＴＤＬを持つＵＲＬのリンク先に接続した場合におけるコネクション確立時間の比較である。図８０は、日本から各国のリンク先ホストに接続した場合におけるコネクション確立時間の比較である。これらの結果から、リンク先が外国の場合にプリコネクションを行う効果が大きいことが分かる。つまり、外国のリンク先を抽出し、そのリンク先に対してプリコネクションを行い、自国のリンク先に対してはファイルプリフェッチを行う等の使い分けが有効である。
以上、本発明の第２実施形態について説明した。
＜４：第３実施形態＞
次に、本発明の第３実施形態について説明する。本実施形態は、操作体の近接距離を検知することが可能なタッチパネルを用いて適切なタイミングでプリフェッチ（又はプリコネクション）を実行する方法に関する。この方法は、上記第１及び第２実施形態に係る技術を前提とするものであり、当該技術の実用性を向上させるためのものである。
次に、本発明の第３実施形態について説明する。本実施形態は、操作体の近接距離を検知することが可能なタッチパネルを用いて適切なタイミングでプリフェッチ（又はプリコネクション）を実行する方法に関する。この方法は、上記第１及び第２実施形態に係る技術を前提とするものであり、当該技術の実用性を向上させるためのものである。
［４−１：近接検知とプリフェッチ処理の連携］
まず、図８１を参照しながら、本実施形態に係るプリフェッチ方法の概要について説明する。上記の通り、本実施形態に係るプリフェッチ方法は、近接検知が可能なタッチパネルを用いて実現されるものである。ここで言う近接検知とは、指やスタイラス等の操作体がタッチパネルの表面に近づいた場合に、操作体の近づき度合いを検出することを意味する。つまり、ここで想定されているタッチパネルは、操作体とタッチパネルとの距離に相当する情報を検知する機能を有していることになる。なお、このようなタッチパネルの具体例については後述する。
まず、図８１を参照しながら、本実施形態に係るプリフェッチ方法の概要について説明する。上記の通り、本実施形態に係るプリフェッチ方法は、近接検知が可能なタッチパネルを用いて実現されるものである。ここで言う近接検知とは、指やスタイラス等の操作体がタッチパネルの表面に近づいた場合に、操作体の近づき度合いを検出することを意味する。つまり、ここで想定されているタッチパネルは、操作体とタッチパネルとの距離に相当する情報を検知する機能を有していることになる。なお、このようなタッチパネルの具体例については後述する。
さて、本実施形態に係るプリフェッチの仕組みは、図８１に示すように、近接検知されたエリア内に表示されたリンク先に対してプリフェッチを行うというものである。例えば、操作体とタッチパネルとの間の距離が所定の閾値よりも短くなった場合にファイルプリフェッチが開始され、リンク先がタッチされた段階でキャッシュされているファイルを用いてＷｅｂページが表示される。但し、ここで行われるファイルプリフェッチは、上記第２実施形態と同様にＨＴＭＬファイル及びＣＳＳファイルだけをプリフェッチするものである。また、Ｗｅｂページを表示する際には、上記第１実施形態と同様に仮ＤＯＭに基づくＷｅｂページの表示、及び本ＤＯＭに基づくＷｅｂページの差し替えが行われる。
なお、本実施形態に係るプリフェッチの仕組みと、上記第２実施形態に係るプリフェッチの仕組みとの間の大きな違いは、プリフェッチの対象とするリンク先の選択方法にある。上記第２実施形態に係るプリフェッチ方法においては、閲覧中のページ内にあるリンク先を所定数選択したり、検索結果から所定数のリンク先を選択したりしていた。しかし、本実施形態に係るプリフェッチ方法においては、操作体が近接したエリア内のリンク先がプリフェッチの対象として選択される。そのため、選択されるリンク先の数が少なくなる分だけ、上記第２実施形態に係るプリフェッチ方法よりもキャッシュするデータ量が少なくなる。但し、プリフェッチ処理の実行時間が比較的短くなるため、必要に応じてプリコネクションとの組み合わせを考える方がよい場合がある。
例えば、操作体とタッチパネルとの間の距離が閾値Ｌ１より短くなるとプリコネクションを開始し、閾値Ｌ２（Ｌ２＜Ｌ１）より短くなるとファイルプリフェッチを開始するといった段階的なプリフェッチ処理にする方が好ましい場合もある。また、閾値Ｌ１より短い状態が所定時間以上続いた場合にファイルプリフェッチを開始するようにしてもよい。このような構成にすると、ユーザがリンク先を選択するか否かを迷っている時間の間にファイルプリフェッチが完了し、ユーザ選択が行われた後すぐに仮ＤＯＭに基づくＷｅｂページを表示できるようになる。
以上、本実施形態に係るプリフェッチ方法の概要について説明した。
［４−２：情報処理装置１００の機能構成］
次に、図８２を参照しながら、上記のアイデアを実現することが可能な情報処理装置１００の機能構成について説明する。図８２は、本実施形態に係る情報処理装置１００の機能構成例を示す説明図である。なお、上記第１及び第２実施形態に係る情報処理装置１００と区別するために、本実施形態に係る情報処理装置１００を情報処理装置１００Ｃと表記する場合がある。
次に、図８２を参照しながら、上記のアイデアを実現することが可能な情報処理装置１００の機能構成について説明する。図８２は、本実施形態に係る情報処理装置１００の機能構成例を示す説明図である。なお、上記第１及び第２実施形態に係る情報処理装置１００と区別するために、本実施形態に係る情報処理装置１００を情報処理装置１００Ｃと表記する場合がある。
図８２に示すように、情報処理装置１００は、主に、データ取得部１１０と、構造解析部１２０と、レンダリング部１３０と、表示部１４０と、通信部１５０と、リンク選択部１６０と、近接判定部１７０と、タッチパネルＴＰとにより構成される。また、レンダリング部１３０は、仮ＤＯＭ生成部１３１と、本ＤＯＭ生成部１３２と、キャッシュメモリ１３３と、表示制御部１３４と、ノード情報格納部１３５とを有する。上記第２実施形態に係る情報処理装置１００Ｂとの主な違いは、近接判定部１７０、及びタッチパネルＴＰの有無にある。また、リンク選択部１６０の機能にも一部変更がある。従って、以下では近接判定部１７０、及びタッチパネルＴＰの機能を中心に説明する。
まず、タッチパネルＴＰについて説明する。タッチパネルＴＰは、光学センサＳを有する。また、図８２では分けて記載されているが、多くの場合、表示部１４０と一体化されている。上記の通り、タッチパネルＴＰは、操作体の近接を検知する機能を有する。この機能は、タッチパネルＴＰに設けられた光源（又は表示部１４０のバックライト）から操作体に照射された光の反射光を光学センサＳにより検知することで得られる。例えば、操作体により反射された光が強いほど、タッチパネルＴＰの近くに操作体が位置していると判定される。但し、この判断は、近接判定部１７０により実行される。
なお、図８２の例ではタッチパネルＴＰとして光学式タッチパネルを用いる例を挙げているが、近接検知が可能なものであれば、どのような方式のタッチパネルが用いられてもよい。例えば、操作体と画面上に設けられた導電膜との間での静電容量の変化を感知して操作体の位置を検出する静電式のタッチパネルを用いることもできる。静電式タッチパネルの場合、操作体が画面上に近づくにつれて増加する静電容量を監視することにより、操作体の近接距離を判定することができる。但し、以下では説明の都合上、光学式タッチパネルを例に挙げて説明することにする。
近接判定部１７０は、光学センサＳにより検出された反射光の強度に基づき、操作体とタッチパネルＴＰとの間の距離を推定する。また、近接判定部１７０は、反射光の強度分布に基づいて操作体の位置、操作体により形成される陰影の大きさ、操作体により形成される陰影の領域を判定する。ここで言う陰影とは、操作体を挟んでタッチパネルＴＰと対向する位置から操作体を見た際に、光源から射出される光が操作体により遮光されてできる影を意味している。もちろん、光学センサＳには陰影として認識されないが、ここでは操作体が作る像をイメージしやすいように陰影という表現を用いた。なお、この陰影の大きさが大きいほど、操作体とタッチパネルＴＰとの間の距離が近いと言うこともできる。
さて、近接判定部１７０により操作体の位置を示す情報（以下、位置情報）、操作体により形成される陰影の領域を示す情報（以下、領域情報）、及び操作体とタッチパネルＴＰとの間の距離を示す情報（以下、距離情報）は、リンク選択部１６０に入力される。位置情報、領域情報、及び距離情報が入力されると、リンク選択部１６０は、領域情報が示す画面上の領域にリンク先が表示されているか否かを判定する。リンク先が表示されている場合、リンク選択部１６０は、表示されているリンク先を選択すると共に距離情報を参照し、操作体とタッチパネルＴＰとの間の距離が所定の閾値より短いか否かを判定する。所定の閾値より短い場合、リンク選択部１６０は、選択したリンク先にプリフェッチの種類を割り当て、リンク先の情報をデータ取得部１１０又は通信部１５０に入力する。なお、データ取得部１１０及び通信部１５０の動作は、上記第１及び第２実施形態と実質的に同じである。
さて、リンク先にプリフェッチの種類を割り当てる方法は何通りか考えられる。まず、最も基本的な方法は、所定の閾値よりも操作体が近接した場合にファイルプリフェッチを開始させるというものである。少し複雑になるが、例えば、領域情報に複数のリンク先が含まれている場合に、操作体が形成する陰影の中心位置を示す位置情報からの距離に応じて、距離が近いリンク先にファイルプリフェッチを割り当て、距離が遠いリンク先にプリコネクションを割り当てる方法が考えられる。さらに、所定の閾値を２つ設け、第１閾値Ｌ１よりも操作体が近接した場合にプリコネクションを開始し、第２閾値Ｌ２（Ｌ２＜Ｌ１）よりも操作体が近接した場合にプリフェッチを開始するようにリンク先に対して割り当てるプリフェッチの種類を変更する方法が考えられる。これらの割り当て処理は、リンク選択部１６０により実行される。
なお、リンク選択部１６０は、操作体がリンク先に近接している時間に応じてファイルプリフェッチを実行するか否かを判断してもよい。例えば、あるリンク先の上で操作体が所定の閾値よりも近づいた状態で所定時間経過した場合にだけファイルプリフェッチが実行されるようにしてもよい。また、あるリンク先の上で所定の閾値よりも近づいた状態が所定時間維持され、そのリンク先に対してファイルプリフェッチが実行された後、そのリンク先を基準とする所定範囲内のリンク先に対してプリコネクションが実行されるようにしてもよい。また、リンク選択部１６０は、プリコネクションを実行するリンク先が複数存在する場合、所定の基準に則してプリコネクションを実行する順序付けを行ってもよい。例えば、リンク選択部１６０は、所定回数以上選択されているリンク先に対して、より早いプリコネクションを実行してもよい。また、リンク選択部１６０は、リンク先への往復遅延時間（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）が所定の閾値以上となるリンク先に対して、より早いプリコネクションを実行してもよい。また、リンク選択部１６０は、リンク先のドメイン名またはＩＰアドレスに応じて、プリコネクションの実行順序を設定してもよい。このような判定及び実行制御に関する処理は、リンク選択部１６０により実行される。
以上、本実施形態に係る情報処理装置１００の機能構成について説明した。
［４−３：情報処理装置１００の動作］
次に、図８３を参照しながら、本実施形態に係る情報処理装置１００の動作について説明する。図８３は、本実施形態に係る情報処理装置１００の動作フローを示す説明図である。但し、図８３に示した動作フローは、検索エンジンにより検索された結果から、所定数のリンク先を選択し、ファイルプリフェッチを行う構成に関する。
次に、図８３を参照しながら、本実施形態に係る情報処理装置１００の動作について説明する。図８３は、本実施形態に係る情報処理装置１００の動作フローを示す説明図である。但し、図８３に示した動作フローは、検索エンジンにより検索された結果から、所定数のリンク先を選択し、ファイルプリフェッチを行う構成に関する。
図８３に示すように、まず、情報処理装置１００は、操作体と表示画面との間の距離（以下、離隔距離）を検出する（ステップＳ４０１）。次いで、情報処理装置１００は、検出した離隔距離が所定の閾値以下であるか否かを判定する（ステップＳ４０２）。離隔距離が所定の閾値以下である場合、情報処理装置１００は、ステップＳ４０３の処理に進行する。一方、離隔距離が所定の閾値以下でない場合、情報処理装置１００は、再びステップＳ４０１の処理に戻る。ステップＳ４０３の処理に進行した場合、情報処理装置１００は、検索結果に含まれるリンク先の中から、リンク先を表す表示の少なくとも一部が操作体の陰影に対応する領域に含まれるものを選択する（ステップＳ４０３）。
次いで、情報処理装置１００は、選択したリンク先からＨＴＭＬファイル及びＣＳＳファイルをダウンロードする（ステップＳ４０４）。次いで、情報処理装置１００は、選択したリンク先がユーザにより選択されたか否かを判定する（ステップＳ４０５）。リンク先が選択された場合、情報処理装置１００は、ステップＳ４０６の処理に進行する。一方、リンク先が選択されていない場合、情報処理装置１００は、再びステップＳ４０５の処理に戻る。ステップＳ４０６の処理に進行した場合、情報処理装置１００は、予め取得しておいたＨＴＭＬファイルを解析し、ＨＴＭＬの記述に関する各構造単位、ＣＳＳファイルに関する構造単位を相互に紐付けて仮ＤＯＭの生成を開始する（ステップＳ４０６）。
次いで、情報処理装置１００は、ユーザにより選択されたリンク先からＪＳファイルを取得する（ステップＳ４０７）。次いで、情報処理装置１００は、予め取得しておいたＨＴＭＬファイルの解析結果に基づき、ＨＴＭＬの記述に関する各構造単位、ＣＳＳファイルに関する構造単位、ＪＳファイルに関する構造単位を相互に紐付けて本ＤＯＭの生成を開始する（ステップＳ４０８）。次いで、情報処理装置１００は、仮ＤＯＭの生成が完了したか否かを判定する（ステップＳ４０９）。仮ＤＯＭの生成が完了した場合、情報処理装置１００は、ステップＳ４１０の処理に進行する。一方、仮ＤＯＭの生成が完了していない場合、情報処理装置１００は、再びステップＳ４０９の処理に戻る。
ステップＳ４１０の処理に進行した場合、情報処理装置１００は、仮ＤＯＭをレンダリングしてＷｅｂページを生成し、生成した仮ＤＯＭに基づくＷｅｂページを表示画面に表示する（ステップＳ４１０）。次いで、情報処理装置１００は、本ＤＯＭの生成が完了したか否かを判定する（ステップＳ４１１）。本ＤＯＭの生成が完了した場合、情報処理装置１００は、ステップＳ４１２の処理に進行する。一方、本ＤＯＭの生成が完了していない場合、情報処理装置１００は、再びステップＳ４１１の処理に戻る。ステップＳ４１２の処理に進行した場合、情報処理装置１００は、本ＤＯＭをレンダリングしてＷｅｂページを生成し、生成した本ＤＯＭに基づくＷｅｂページを仮ＤＯＭに基づくＷｅｂページに代えて表示画面に表示し（ステップＳ４１２）、一連の処理を終了する。
以上、本実施形態に係る情報処理装置１００の動作フローについて説明した。
［４−４：近接検知に基づくプリフェッチ処理の流れ］
次に、図８４を参照しながら、本実施形態に係る近接検知を用いたプリフェッチ処理の流れについて説明する。図８４は、本実施形態に係る近接検知を用いたプリフェッチ処理の流れを示す説明図である。なお、図８４の例では操作体の一例として指を挙げている。
次に、図８４を参照しながら、本実施形態に係る近接検知を用いたプリフェッチ処理の流れについて説明する。図８４は、本実施形態に係る近接検知を用いたプリフェッチ処理の流れを示す説明図である。なお、図８４の例では操作体の一例として指を挙げている。
図８４に示すように、まず、タッチパネルＴＰから閾値Ａ［ｍｍ］以内で指を検知したか否かが判定される（ステップＳ５０１）。閾値以内で指を検知した場合、処理は、ステップＳ５０２に進行する。一方、閾値以内で指を検知していない場合、処理は、再びステップＳ５０１に戻る。ステップＳ５０２に進行した場合、閾値Ｂ［ｍｓｅｃ］以上の時間、近接検知により指のフォーカスがリンクＣに当たり続けているかが判定される（ステップＳ５０２）。
フォーカスが閾値Ｂ以上当たり続けている場合、処理は、ステップＳ５０３に進行する。一方、フォーカスが閾値Ｂ以上当たり続けていない場合、処理は、再びステップＳ５０１に戻る。ステップＳ５０３に進行した場合、リンクＣに対してファイルプリフェッチが実行される（ステップＳ５０３）。次いで、リンクＣからＤ［ｍｍ２］以内のエリアに存在するリンク群Ｅに対してプリコネクションが実行され（ステップＳ５０４）、一連の処理が終了する。
以上、本実施形態に係るプリフェッチ処理の流れについて説明した。
［４−５：近接検知が可能なタッチパネルの構成（インセル型タッチパネル）］
次に、図８５を参照しながら、近接検知が可能なタッチパネルについて説明する。タッチパネルには、例えば、感圧式、静電気式、光学式など、いくつかの種類がある。感圧式タッチパネルは、操作体がパネルを押圧したときの圧力変化を検知して操作体の位置を検出するものである。静電気式タッチパネルは、パネルに操作体が接触した際に生じる静電気を電気信号として検知し、その検知結果から操作体の位置を検出するものである。光学式タッチパネルとしては、例えば、表示パネルの外枠に設けられた光学センサにより、パネルに接触した操作体の位置や移動方向を検知する方式が良く知られている。
次に、図８５を参照しながら、近接検知が可能なタッチパネルについて説明する。タッチパネルには、例えば、感圧式、静電気式、光学式など、いくつかの種類がある。感圧式タッチパネルは、操作体がパネルを押圧したときの圧力変化を検知して操作体の位置を検出するものである。静電気式タッチパネルは、パネルに操作体が接触した際に生じる静電気を電気信号として検知し、その検知結果から操作体の位置を検出するものである。光学式タッチパネルとしては、例えば、表示パネルの外枠に設けられた光学センサにより、パネルに接触した操作体の位置や移動方向を検知する方式が良く知られている。
また、「インセル型」と呼ばれる光学式タッチパネルも知られている。インセル型の光学式タッチパネル（以下、インセル型タッチパネル）は、表示パネルを構成するガラス基板に設けられた光センサアレイにより、操作体で反射された光を検知して操作体の位置を検知するというものである。表示パネルには、画像を表示するための光源が設けられている。表示パネルに操作体が接触又は近接していると、光源から射出された光が操作体により強く反射され、その反射光が光センサアレイにより受光される。
光センサアレイには、各光センサにより検知された光の強度データを読み出すためのリード回路が接続されている。そのため、操作体により反射された光が光センサアレイにより検知されると、各光センサにより検知された光の強度データがリード回路により読み出される。このようにしてリード回路により読み出された光の強度データは、操作体により反射された光の分布を表している。そのため、リード回路により読み出された光の強度データから像を形成することにより、表示パネルに接触又は近接している操作体の形状が画像として得られる。
なお、ここで得られる画像は、光源から射出された光を操作体が遮光して得られる陰影画像に相当する。このように、インセル型タッチパネルの場合、操作体の形状が画像として得られるため、操作体が作る陰影の面積を算出することができる。そのため、操作体の接触面積を検出することができる。さらに、操作体が表示パネルに近づくほど操作体により遮光される光量が多くなることを考慮すると、陰影の面積に基づいて操作体と表示パネルとの間の距離を推定することができる（図８５を参照）。
例えば、反射光の強度が大きい部分を陰影にして表現すると、図８５のような画像パターンが得られる。操作体の距離が遠い場合には小さな陰影が得られ、操作体の距離が近づくにつれて遮光量が増えるため、陰影の面積が徐々に大きくなる。そのため、陰影の面積を計測することにより、操作体と表示パネルとの間の距離を検知することができる。マルチタッチの場合には複数本の操作体に相当する複数の陰影が得られ、各陰影の面積を計測することにより、各操作体と表示パネルとの間の距離が得られる。
＜５：情報処理装置１００のハードウェア構成例＞
上記の情報処理装置１００（１００Ａ、１００Ｂ、１００Ｃ）が有する各構成要素の機能は、例えば、図８６に示す情報処理装置のハードウェア構成を用いて実現することが可能である。つまり、当該各構成要素の機能は、コンピュータプログラムを用いて図８６に示すハードウェアを制御することにより実現される。なお、このハードウェアの形態は任意であり、例えば、パーソナルコンピュータ、携帯電話、ＰＨＳ、ＰＤＡ等の携帯情報端末、ゲーム機、又は種々の情報家電がこれに含まれる。但し、上記のＰＨＳは、Ｐｅｒｓｏｎａｌ Ｈａｎｄｙ−ｐｈｏｎｅ Ｓｙｓｔｅｍの略である。また、上記のＰＤＡは、Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔの略である。
上記の情報処理装置１００（１００Ａ、１００Ｂ、１００Ｃ）が有する各構成要素の機能は、例えば、図８６に示す情報処理装置のハードウェア構成を用いて実現することが可能である。つまり、当該各構成要素の機能は、コンピュータプログラムを用いて図８６に示すハードウェアを制御することにより実現される。なお、このハードウェアの形態は任意であり、例えば、パーソナルコンピュータ、携帯電話、ＰＨＳ、ＰＤＡ等の携帯情報端末、ゲーム機、又は種々の情報家電がこれに含まれる。但し、上記のＰＨＳは、Ｐｅｒｓｏｎａｌ Ｈａｎｄｙ−ｐｈｏｎｅ Ｓｙｓｔｅｍの略である。また、上記のＰＤＡは、Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔの略である。
図８６に示すように、このハードウェアは、主に、ＣＰＵ９０２と、ＲＯＭ９０４と、ＲＡＭ９０６と、ホストバス９０８と、ブリッジ９１０と、を有する。さらに、このハードウェアは、外部バス９１２と、インターフェース９１４と、入力部９１６と、出力部９１８と、記憶部９２０と、ドライブ９２２と、接続ポート９２４と、通信部９２６と、を有する。但し、上記のＣＰＵは、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔの略である。また、上記のＲＯＭは、Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙの略である。そして、上記のＲＡＭは、Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙの略である。
ＣＰＵ９０２は、例えば、演算処理装置又は制御装置として機能し、ＲＯＭ９０４、ＲＡＭ９０６、記憶部９２０、又はリムーバブル記録媒体９２８に記録された各種プログラムに基づいて各構成要素の動作全般又はその一部を制御する。ＲＯＭ９０４は、ＣＰＵ９０２に読み込まれるプログラムや演算に用いるデータ等を格納する手段である。ＲＡＭ９０６には、例えば、ＣＰＵ９０２に読み込まれるプログラムや、そのプログラムを実行する際に適宜変化する各種パラメータ等が一時的又は永続的に格納される。
これらの構成要素は、例えば、高速なデータ伝送が可能なホストバス９０８を介して相互に接続される。一方、ホストバス９０８は、例えば、ブリッジ９１０を介して比較的データ伝送速度が低速な外部バス９１２に接続される。また、入力部９１６としては、例えば、マウス、キーボード、タッチパネル、ボタン、スイッチ、及びレバー等が用いられる。さらに、入力部９１６としては、赤外線やその他の電波を利用して制御信号を送信することが可能なリモートコントローラ（以下、リモコン）が用いられることもある。
出力部９１８としては、例えば、ＣＲＴ、ＬＣＤ、ＰＤＰ、又はＥＬＤ等のディスプレイ装置、スピーカ、ヘッドホン等のオーディオ出力装置、プリンタ、携帯電話、又はファクシミリ等、取得した情報を利用者に対して視覚的又は聴覚的に通知することが可能な装置である。但し、上記のＣＲＴは、Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅの略である。また、上記のＬＣＤは、Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙの略である。そして、上記のＰＤＰは、Ｐｌａｓｍａ ＤｉｓｐｌａｙＰａｎｅｌの略である。さらに、上記のＥＬＤは、Ｅｌｅｃｔｒｏ−Ｌｕｍｉｎｅｓｃｅｎｃｅ Ｄｉｓｐｌａｙの略である。
記憶部９２０は、各種のデータを格納するための装置である。記憶部９２０としては、例えば、ハードディスクドライブ（ＨＤＤ）等の磁気記憶デバイス、半導体記憶デバイス、光記憶デバイス、又は光磁気記憶デバイス等が用いられる。但し、上記のＨＤＤは、Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅの略である。
ドライブ９２２は、例えば、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリ等のリムーバブル記録媒体９２８に記録された情報を読み出し、又はリムーバブル記録媒体９２８に情報を書き込む装置である。リムーバブル記録媒体９２８は、例えば、ＤＶＤメディア、Ｂｌｕ−ｒａｙメディア、ＨＤ ＤＶＤメディア、各種の半導体記憶メディア等である。もちろん、リムーバブル記録媒体９２８は、例えば、非接触型ＩＣチップを搭載したＩＣカード、又は電子機器等であってもよい。但し、上記のＩＣは、Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔの略である。
接続ポート９２４は、例えば、ＵＳＢポート、ＩＥＥＥ１３９４ポート、ＳＣＳＩ、ＲＳ−２３２Ｃポート、又は光オーディオ端子等のような外部接続機器９３０を接続するためのポートである。外部接続機器９３０は、例えば、プリンタ、携帯音楽プレーヤ、デジタルカメラ、デジタルビデオカメラ、又はＩＣレコーダ等である。但し、上記のＵＳＢは、Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓの略である。また、上記のＳＣＳＩは、Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅの略である。
通信部９２６は、ネットワーク２００に接続するための通信デバイスであり、例えば、有線又は無線ＬＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、又はＷＵＳＢ用の通信カード、光通信用のルータ、ＡＤＳＬ用のルータ、又は各種通信用のモデム等である。また、通信部９２６に接続されるネットワーク２００は、有線又は無線により接続されたネットワークにより構成され、例えば、インターネット、家庭内ＬＡＮ、赤外線通信、可視光通信、放送、又は衛星通信等である。但し、上記のＬＡＮは、Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋの略である。また、上記のＷＵＳＢは、Ｗｉｒｅｌｅｓｓ ＵＳＢの略である。そして、上記のＡＤＳＬは、Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅの略である。
＜６：まとめ＞
最後に、本発明の実施形態に係る技術内容について簡単に纏める。ここで述べる技術内容は、例えば、ＰＣ、携帯電話、携帯ゲーム機、携帯情報端末、情報家電、カーナビゲーションシステム等、種々の情報処理装置に対して適用することができる。
最後に、本発明の実施形態に係る技術内容について簡単に纏める。ここで述べる技術内容は、例えば、ＰＣ、携帯電話、携帯ゲーム機、携帯情報端末、情報家電、カーナビゲーションシステム等、種々の情報処理装置に対して適用することができる。
上記の情報処理装置の機能構成は次のように表現することができる。当該情報処理装置は、リンク選択部と、データ先読み部と、構造解析部と、第１構造化部と、第２構造化部と、表示制御部と、を主に備える。
リンク選択部は、キー情報による検索の結果が表示されたリンク先の一部を選択する。
データ先読み部は、リンク選択部により選択されたリンク先に存在する、表示画面のレイアウトに関する情報が記述された構造単位を少なくとも含む表示制御データと、表示画面のレイアウトに関する情報とを、リンク先がユーザ操作によって選択される以前に取得する。
構造解析部は、データ先読み部が表示制御データを取得したリンク先が前記操作体によって選択された場合に、この表示制御データを解析して、当該表示制御データに含まれる構造単位を抽出する。
第１構造化部は、データ先読み部が表示制御データの取得を行ったリンク先がユーザ操作によって選択された場合に、構造解析部により抽出された構造単位のうち、スクリプト処理を伴う表示制御に関する情報が記述された構造単位を除き、表示画面のレイアウトに関する情報が記述された構造単位を少なくとも含む構造単位を相互に紐付けて、表示制御用の第１構造化データを生成する。
第２構造化部は、データ先読み部が表示制御データを取得したリンク先がユーザ操作によって選択された場合に、構造単位を相互に紐付けて、表示制御用の第２構造化データを生成する。
表示制御部は、第１構造化部により生成された第１構造化データを用いて表示画面を表示し、第２構造化部により第２構造化データが生成された段階で、当該第２構造化データを用いて表示画面を表示しなおす。
かかる構成によれば、スクリプト情報を含む本来の構造化データでの表示画面の表示に先立ち、素早くレイアウトの整ったページを表示することができる。つまり、スクリプト処理の逐次性に起因してページの表示開始が遅れるのを避け、簡易的ではあるが、ある程度見やすいレイアウトで十分な情報を素早くユーザに提示することができる。さらに、ページの制作者が意図する本来のレイアウトを有するページで簡易的なページを差し替えることにより、本来のレイアウトを正確に反映したページをユーザが閲覧できるようになる。その結果、ページの情報を素早く閲覧したいという要望と、本来のレイアウトに基づくページの情報を閲覧したいという要望とを両立させることが可能になる。多くの場合、ユーザが知りたい情報は、上記の簡易的なページにより得られる。しかし、ユーザは、本来制作者が意図した情報の全てが閲覧できているのか不安に思うものである。このような不安は、上記構成にように、制作者の意図を正確に反映させたページをユーザに提示することで払拭される。
（備考）
上記のデータ取得部１１０は、データ先読み部の一例である。上記の仮ＤＯＭ生成部１３１は、第１構造化部の一例である。上記の本ＤＯＭ生成部１３２は、第２構造化部の一例である。上記の通信部１５０は、接続確立部の一例である。上記のノード情報格納部１３５は、表示履歴格納部の一例である。
上記のデータ取得部１１０は、データ先読み部の一例である。上記の仮ＤＯＭ生成部１３１は、第１構造化部の一例である。上記の本ＤＯＭ生成部１３２は、第２構造化部の一例である。上記の通信部１５０は、接続確立部の一例である。上記のノード情報格納部１３５は、表示履歴格納部の一例である。
以上、添付図面を参照しながら本発明の好適な実施形態について説明したが、本発明は係る例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。
１０ Ｗｅｂブラウザ
１１ ＨＴＭＬパーサ
１２ ＤＯＭ
１３ スクリプトエンジン
１００、１００Ａ、１００Ｂ、１００Ｃ 情報処理装置
１１０ データ取得部
１２０ 構造解析部
１３０ レンダリング部
１３１ 仮ＤＯＭ生成部
１３２ 本ＤＯＭ生成部
１３３ キャッシュメモリ
１３４ 表示制御部
１３５ ノード情報格納部
１４０ 表示部
１５０ 通信部
１６０ リンク選択部
１７０ 近接判定部
２００ ネットワーク
３１０、３２０ Ｗｅｂサーバ
Ｓ 光学センサ
ＴＰ タッチパネル
１１ ＨＴＭＬパーサ
１２ ＤＯＭ
１３ スクリプトエンジン
１００、１００Ａ、１００Ｂ、１００Ｃ 情報処理装置
１１０ データ取得部
１２０ 構造解析部
１３０ レンダリング部
１３１ 仮ＤＯＭ生成部
１３２ 本ＤＯＭ生成部
１３３ キャッシュメモリ
１３４ 表示制御部
１３５ ノード情報格納部
１４０ 表示部
１５０ 通信部
１６０ リンク選択部
１７０ 近接判定部
２００ ネットワーク
３１０、３２０ Ｗｅｂサーバ
Ｓ 光学センサ
ＴＰ タッチパネル
Claims (11)
- キー情報による検索の結果が表示されたリンク先の一部を選択するリンク選択部と、
前記リンク選択部により選択されたリンク先に存在する、表示画面のレイアウトに関する情報が記述された構造単位を少なくとも含む表示制御データと、前記表示画面のレイアウトに関する情報とを、前記リンク先がユーザ操作によって選択される以前に取得するデータ先読み部と、
前記データ先読み部が前記表示制御データを取得したリンク先が前記操作体によって選択された場合に、前記表示制御データを解析して、当該表示制御データに含まれる構造単位を抽出する構造解析部と、
前記データ先読み部が前記表示制御データの取得を行ったリンク先が前記ユーザ操作によって選択された場合に、前記構造解析部により抽出された構造単位のうち、スクリプト処理を伴う表示制御に関する情報が記述された構造単位を除き、表示画面のレイアウトに関する情報が記述された構造単位を少なくとも含む前記構造単位を相互に紐付けて、表示制御用の第１構造化データを生成する第１構造化部と、
前記データ先読み部が前記表示制御データを取得したリンク先がユーザ操作によって選択された場合に、前記構造単位を相互に紐付けて、表示制御用の第２構造化データを生成する第２構造化部と、
前記第１構造化部により生成された前記第１構造化データを用いて表示画面を表示し、前記第２構造化部により前記第２構造化データが生成された段階で、当該第２構造化データを用いて表示画面を表示しなおす表示制御部と、
を備える、情報処理装置。 - 前記情報処理装置は、前記リンク先との接続を確立する接続確立部を更に備え、
前記リンク選択部は、表示画面上の位置を指定するために用いられる位置指定オブジェクトの表示位置から所定範囲内に存在する前記リンク先、表示画面に表示された状態にある前記リンク先、および、所定回数以上選択されている前記リンク先の少なくとも何れかを更に選択し、
前記接続確立部は、リンク選択部によって更に選択された前記リンク先と、ユーザ操作によって前記リンク先が選択される以前にＴＣＰコネクションを確立する、請求項１に記載の情報処理装置。 - 前記リンク選択部は、前記リンク先のうち、当該リンク先への往復遅延時間（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）が所定の閾値以上のものを、ＴＣＰコネクションを確立するリンク先として選択する、請求項２に記載の情報処理装置。
- 前記リンク選択部は、前記リンク先のドメイン名またはＩＰアドレスに応じて、ＴＣＰコネクションを確立するリンク先として選択するか否かを判断する、請求項３に記載の情報処理装置。
- 前記情報処理装置は、前記表示制御データと、当該表示制御データと関連づけられた関連データと、を取得するデータ取得部を更に備え、
前記データ取得部は、前記第２構造化部からのデータ取得要請よりも、前記第１構造化部からのデータ取得要請を優先して扱う、請求項１に記載の情報処理装置。 - 前記接続確立部は、前記リンク先のホストアドレスが確定すると、前記表示制御データの先読みまたは前記ＴＣＰコネクションの確立に先立って、前記ホストアドレスに対応するＩＰアドレスを取得する、請求項２に記載の情報処理装置。
- 前記情報処理装置は、前記第１構造化部及び前記第２構造化部の要請により前記データ取得部が取得した前記表示制御データ及び前記関連データが格納されるキャッシュメモリを更に備え、
前記表示制御部は、前記第２構造化データでの表示に要する前記表示制御データが前記キャッシュメモリに全て格納された時点で、当該キャッシュメモリに格納されたデータに基づき表示を切り替える、請求項６に記載の情報処理装置。 - 前記第２構造化部は、前記構造解析部により抽出された構造単位のなかに、スクリプト処理を伴う表示制御に関する情報が記述された構造単位が存在しない場合、前記第２構造化データを生成しない、請求項１に記載の情報処理装置。
- 前記情報処理装置は、前記第１構造化データでの表示を行っている際に表示画面に表示している構造単位の履歴を格納する表示履歴格納部を更に備え、
前記表示制御部は、前記第２構造化データでの表示に切り替える際、前記表示履歴格納部に格納されている表示履歴に基づいて、表示画面に表示する前記構造単位を選択する、請求項１に記載の情報処理装置。 - キー情報による検索の結果が表示されたリンク先の一部を選択するステップと、
前記リンク先の一部を選択するステップにて選択されたリンク先に存在する、表示画面のレイアウトに関する情報が記述された構造単位を少なくとも含む表示制御データを、前記リンク先がユーザ操作によって選択される以前に取得するステップと、
ユーザ操作に先立つ表示制御データの取得を行ったリンク先が前記ユーザ操作によって選択される以前に、前記表示制御データを解析して、当該表示制御データに含まれる構造単位を抽出するステップと、
ユーザ操作に先立つ表示制御データの取得を行ったリンク先が前記ユーザ操作によって選択される以前に、前記構造単位を抽出するステップにて抽出された構造単位のうち、スクリプト処理を伴う表示制御に関する情報が記述された構造単位を除き、表示画面のレイアウトに関する情報が記述された構造単位を少なくとも含む前記構造単位を相互に紐付けて、表示制御用の第１構造化データを生成するステップと、
ユーザ操作に先立つ表示制御データの取得を行ったリンク先が前記ユーザ操作によって選択された場合に、前記構造単位を相互に紐付けて、表示制御用の第２構造化データを生成するステップと、
前記第１構造化データを生成するステップにて生成された前記第１構造化データを用いて表示画面を表示するステップと、
前記第２構造化データが生成された段階で、当該第２構造化データを用いて表示画面を表示しなおすステップと、
を含む、データ取得方法。 - コンピュータに、
キー情報による検索の結果が表示されたリンク先の一部を選択するリンク選択機能と、
前記リンク選択機能により選択されたリンク先に存在する、表示画面のレイアウトに関する情報が記述された構造単位を少なくとも含む表示制御データを、前記リンク先がユーザ操作によって選択される以前に取得するデータ先読み機能と、
前記データ先読み機能が前記表示制御データの取得を行ったリンク先が前記ユーザ操作によって選択される以前に、前記表示制御データを解析して、当該表示制御データに含まれる構造単位を抽出する構造解析機能と、
前記データ先読み機能が前記表示制御データの取得を行ったリンク先が前記ユーザ操作によって選択される以前に、前記構造解析機能により抽出された構造単位のうち、スクリプト処理を伴う表示制御に関する情報が記述された構造単位を除き、表示画面のレイアウトに関する情報が記述された構造単位を少なくとも含む前記構造単位を相互に紐付けて、表示制御用の第１構造化データを生成する第１構造化機能と、
前記データ先読み機能が前記表示制御データを取得したリンク先がユーザ操作によって選択された場合に、前記構造単位を相互に紐付けて、表示制御用の第２構造化データを生成する第２構造化機能と、
前記第１構造化機能により生成された前記第１構造化データを用いて表示画面を表示し、前記第２構造化機能により前記第２構造化データが生成された段階で、当該第２構造化データを用いて表示画面を表示しなおす表示制御機能と、
を実現させるためのプログラム。
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2009216286A JP5316338B2 (ja) | 2009-09-17 | 2009-09-17 | 情報処理装置、データ取得方法及びプログラム |
| EP10173497A EP2320336A3 (en) | 2009-09-17 | 2010-08-20 | Information processing apparatus, data acquisition method, and program |
| US12/871,470 US8478882B2 (en) | 2009-09-17 | 2010-08-30 | Information processing apparatus, data acquisition method, and program |
| CN2010102809385A CN102024012B (zh) | 2009-09-17 | 2010-09-10 | 信息处理设备、数据获取方法、以及程序 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2009216286A JP5316338B2 (ja) | 2009-09-17 | 2009-09-17 | 情報処理装置、データ取得方法及びプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2011065490A JP2011065490A (ja) | 2011-03-31 |
| JP5316338B2 true JP5316338B2 (ja) | 2013-10-16 |
Family
ID=43585685
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2009216286A Expired - Fee Related JP5316338B2 (ja) | 2009-09-17 | 2009-09-17 | 情報処理装置、データ取得方法及びプログラム |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US8478882B2 (ja) |
| EP (1) | EP2320336A3 (ja) |
| JP (1) | JP5316338B2 (ja) |
| CN (1) | CN102024012B (ja) |
Families Citing this family (35)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8732569B2 (en) | 2011-05-04 | 2014-05-20 | Google Inc. | Predicting user navigation events |
| US9769285B2 (en) | 2011-06-14 | 2017-09-19 | Google Inc. | Access to network content |
| US8788711B2 (en) | 2011-06-14 | 2014-07-22 | Google Inc. | Redacting content and inserting hypertext transfer protocol (HTTP) error codes in place thereof |
| US8745212B2 (en) | 2011-07-01 | 2014-06-03 | Google Inc. | Access to network content |
| US8650139B2 (en) | 2011-07-01 | 2014-02-11 | Google Inc. | Predicting user navigation events |
| US8744988B1 (en) | 2011-07-15 | 2014-06-03 | Google Inc. | Predicting user navigation events in an internet browser |
| US8655819B1 (en) | 2011-09-15 | 2014-02-18 | Google Inc. | Predicting user navigation events based on chronological history data |
| US9104664B1 (en) | 2011-10-07 | 2015-08-11 | Google Inc. | Access to search results |
| US9584579B2 (en) | 2011-12-01 | 2017-02-28 | Google Inc. | Method and system for providing page visibility information |
| US20130179844A1 (en) * | 2012-01-06 | 2013-07-11 | Mirko Mandic | Input Pointer Delay |
| US8793235B2 (en) | 2012-01-19 | 2014-07-29 | Google Inc. | System and method for improving access to search results |
| US9946792B2 (en) | 2012-05-15 | 2018-04-17 | Google Llc | Access to network content |
| US8887239B1 (en) | 2012-08-08 | 2014-11-11 | Google Inc. | Access to network content |
| US20140053064A1 (en) | 2012-08-16 | 2014-02-20 | Qualcomm Incorporated | Predicting the usage of document resources |
| US9898445B2 (en) | 2012-08-16 | 2018-02-20 | Qualcomm Incorporated | Resource prefetching via sandboxed execution |
| JP2015207027A (ja) * | 2012-08-31 | 2015-11-19 | パナソニック株式会社 | ウェブページキャッシュ装置、ウェブページキャッシュ方法、プログラム、および集積回路 |
| CN102855318B (zh) * | 2012-08-31 | 2015-05-27 | 北京搜狗信息服务有限公司 | 网页预加载方法与系统 |
| US9141722B2 (en) | 2012-10-02 | 2015-09-22 | Google Inc. | Access to network content |
| EP2924392A4 (en) * | 2012-11-21 | 2016-08-03 | Clarion Co Ltd | INFORMATION PROCESSING DEVICE AND NAVIGATOR CONTROL METHOD |
| JP6057764B2 (ja) * | 2013-02-18 | 2017-01-11 | 三菱電機株式会社 | コンテンツ閲覧装置 |
| US9164609B2 (en) * | 2013-03-13 | 2015-10-20 | Amazon Technologies, Inc. | Managing sensory information of a user device |
| WO2014155663A1 (ja) * | 2013-03-29 | 2014-10-02 | 楽天株式会社 | データ提供装置、データ提供方法及びデータ提供プログラム |
| US10778680B2 (en) * | 2013-08-02 | 2020-09-15 | Alibaba Group Holding Limited | Method and apparatus for accessing website |
| CN103488480A (zh) * | 2013-09-09 | 2014-01-01 | 百度在线网络技术（北京）有限公司 | 一种页面显示方法及系统 |
| US8924850B1 (en) * | 2013-11-21 | 2014-12-30 | Google Inc. | Speeding up document loading |
| WO2015079527A1 (ja) * | 2013-11-28 | 2015-06-04 | 楽天株式会社 | 情報処理装置、情報処理方法及び情報処理プログラム |
| US9740791B1 (en) | 2014-09-23 | 2017-08-22 | Amazon Technologies, Inc. | Browser as a service |
| US9582600B1 (en) * | 2014-09-23 | 2017-02-28 | Amazon Technologies, Inc. | Cloud browser DOM-based client |
| US10417317B2 (en) | 2015-07-27 | 2019-09-17 | Adp, Llc | Web page profiler |
| US10324600B2 (en) * | 2015-07-27 | 2019-06-18 | Adp, Llc | Web page generation system |
| US10742764B2 (en) | 2015-07-27 | 2020-08-11 | Adp, Llc | Web page generation system |
| US10643023B2 (en) * | 2015-09-25 | 2020-05-05 | Oath, Inc. | Programmatic native rendering of structured content |
| CN105597323A (zh) * | 2015-12-25 | 2016-05-25 | 北京像素软件科技股份有限公司 | 一种网络游戏中地形变化的实现方法及系统 |
| US10165071B2 (en) * | 2016-01-15 | 2018-12-25 | Google Llc | Client-side activity monitoring |
| CN107015994B (zh) * | 2016-01-28 | 2020-11-24 | 创新先进技术有限公司 | 网页内容获取方法及装置 |
Family Cites Families (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6055569A (en) * | 1998-01-27 | 2000-04-25 | Go Ahead Software Inc. | Accelerating web access by predicting user action |
| US6993591B1 (en) * | 1998-09-30 | 2006-01-31 | Lucent Technologies Inc. | Method and apparatus for prefetching internet resources based on estimated round trip time |
| US7353276B2 (en) * | 2003-02-13 | 2008-04-01 | Microsoft Corporation | Bi-directional affinity |
| JP2004280405A (ja) | 2003-03-14 | 2004-10-07 | Sony Corp | 情報提供システム及び情報提供方法、並びにコンピュータ・プログラム |
| US20060069618A1 (en) * | 2004-09-27 | 2006-03-30 | Scott Milener | Method and apparatus for enhanced browsing |
| US8732234B2 (en) * | 2005-06-07 | 2014-05-20 | Yahoo! Inc. | Providing relevant non-requested content to a mobile device |
| US20070067305A1 (en) * | 2005-09-21 | 2007-03-22 | Stephen Ives | Display of search results on mobile device browser with background process |
| CN101042695A (zh) * | 2006-03-20 | 2007-09-26 | 腾讯科技（深圳）有限公司 | 一种搜索结果页面缩略显示方法及系统 |
| JP2007272742A (ja) * | 2006-03-31 | 2007-10-18 | Ntt Docomo Inc | 通信端末及び通信方法 |
| US20070299985A1 (en) * | 2006-06-27 | 2007-12-27 | Craig Jeremy S | Systems and methods for template based website construction |
| WO2008078684A1 (ja) * | 2006-12-25 | 2008-07-03 | Access Co., Ltd. | ネットワークシステム |
| JP4901534B2 (ja) * | 2007-03-02 | 2012-03-21 | 株式会社デンソー | 情報通信システム、施設側装置、ユーザ側装置、状態検出装置、更新装置、施設側装置用プログラム、ユーザ側装置用プログラム、状態検出装置用プログラム及び更新装置用プログラム |
| US20080301300A1 (en) * | 2007-06-01 | 2008-12-04 | Microsoft Corporation | Predictive asynchronous web pre-fetch |
| US9083722B2 (en) * | 2007-10-05 | 2015-07-14 | Qualcomm Incorporated | Session initiation protocol registration with ping |
| US9003050B2 (en) * | 2008-04-11 | 2015-04-07 | Mobitv, Inc. | Distributed and scalable content streaming architecture |
-
2009
- 2009-09-17 JP JP2009216286A patent/JP5316338B2/ja not_active Expired - Fee Related
-
2010
- 2010-08-20 EP EP10173497A patent/EP2320336A3/en not_active Withdrawn
- 2010-08-30 US US12/871,470 patent/US8478882B2/en active Active
- 2010-09-10 CN CN2010102809385A patent/CN102024012B/zh not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US8478882B2 (en) | 2013-07-02 |
| EP2320336A3 (en) | 2012-01-18 |
| US20110066732A1 (en) | 2011-03-17 |
| JP2011065490A (ja) | 2011-03-31 |
| CN102024012B (zh) | 2013-05-15 |
| EP2320336A2 (en) | 2011-05-11 |
| CN102024012A (zh) | 2011-04-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5316338B2 (ja) | 情報処理装置、データ取得方法及びプログラム | |
| US8504695B2 (en) | Information processing apparatus, data acquisition method, and program | |
| EP2312469B1 (en) | Information processing apparatus, data display method, and program | |
| US11809511B2 (en) | Speeding up document loading | |
| AU2009287454B2 (en) | New tab pages and bookmark toolbars in a browser | |
| US8943275B1 (en) | Differential storage and eviction for information resources from a browser cache | |
| EP2500834A1 (en) | Method and System for Transferring Application Program Settings Between Applications | |
| JP2011108102A (ja) | ウェブサーバ、ウェブブラウザおよびウェブシステム | |
| JP5793601B2 (ja) | 自動スクロール実行システムおよび方法 | |
| US20130305136A1 (en) | Flip Ahead Input for Content Navigation | |
| US20110126113A1 (en) | Displaying content on multiple web pages | |
| EP3043251A1 (en) | Method of displaying content and electronic device implementing same | |
| WO2018137470A1 (zh) | 用户终端及网页图片资源加载装置与方法、存储介质 | |
| JP7206863B2 (ja) | 表示制御方法、装置、及びプログラム | |
| US20100174986A1 (en) | Apparatus and method for moving to previous website in web browser | |
| JP6142620B2 (ja) | 表示変更プログラム、表示変更方法及び表示変更装置 | |
| JP6091231B2 (ja) | 情報処理装置、コンピュータプログラム | |
| JP2000057078A (ja) | 画面の表示方法及び記憶媒体 | |
| JP2011253301A (ja) | ウェブサイト閲覧システム、サーバ及びサーバ用プログラム | |
| JP2017068715A (ja) | コンテンツ提供プログラム及びコンテンツ提供方法 | |
| KR20150077707A (ko) | 미디어 콘텐츠를 디스플레이할 수 있는 전자 장치, 방법, 및 컴퓨터 판독 가능 저장 매체 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20120910 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20130531 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20130611 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20130624 |
|
| LAPS | Cancellation because of no payment of annual fees |