JP5198004B2 - ウェブサーバおよびウェブ表示端末 - Google Patents

Description

この発明は、通信技術に関連し、特に、ウェブページを閲覧するための技術、に関する。

近年、コンピュータの普及とネットワーク技術の進展にともない、ネットワークを介した電子情報の交換が盛んになっている。ウェブブラウザがインストールされたウェブ表示端末さえあれば、ユーザは世界中のウェブページを閲覧できる。

ウェブ閲覧技術を支えているのは、ＨＴＴＰ（HyperText Transfer Protocol）とよばれる通信プロトコルである。ウェブ表示端末においてＵＲＬ（Uniform Resource Locator）を指定すると、適切なウェブサーバにウェブページの取得要求が送信され、ウェブサーバはＨＴＭＬ（HyperText Markup Language）やＸＨＴＭＬ（eXtensible HyperText Markup Language）形式のウェブページをウェブ表示端末に送信する。ウェブページは複数回に分けて送信されることも多い。ウェブ表示端末は、受信したウェブページを画面表示させる。

このようにウェブページの表示に際しては、ウェブ表示端末とウェブサーバの間で複数回の通信アクセスが発生する。通信アクセス回数が多くなると、表示待ち時間が長くなり、ユーザの快適性が損なわれることになる。

そこで、多くのウェブブラウザはページキャッシュ機能を搭載している。たとえば、ウェブページＡの次にウェブページＢを表示させた後、ウェブページＡを再表示させるとする。ページキャッシュ機能によれば、１回目の表示に際して取得されたウェブページＡはウェブ表示端末に保持（キャッシュ）される。このため、２回目のウェブページＡの表示では、ウェブサーバにアクセスしなくてもキャッシュされているウェブページＡをそのまま再表示させることができる。ページキャッシュ機能によれば、再表示時においてウェブサーバに対する通信アクセスが不要となるため、全体としての通信アクセス回数を抑制できる。
特開２００４−２１３２８０号公報 特開２００６−１３９６１４号公報

一般的なページキャッシュ機能は、過去に取得されたウェブページを保持しておくことにより、再表示に備える機能である。これに対し、本発明者は、ウェブページの取得要求順序には規則性、すなわちなんらかの傾向が現れやすいという点に着目した。たとえば、あるユーザは、頻繁にウェブページＡやウェブページＢを要求するが、ウェブページＣを要求することは滅多にないかもしれない。また、ウェブページＡのあとにはウェブページＤが要求されやすいという一般的な傾向があるかもしれない。そこでこのようなウェブページの取得要求傾向に鑑みて、将来的に取得要求される可能性が高いウェブページを予測し、実際に表示される前に取得しておけば、いっそう軽快なウェブページの閲覧が可能であると本発明者は想到した。

本発明は、本発明者による上記着眼点に基づいて完成された発明であり、その主たる目的は、ウェブページを閲覧にともなう快適性を向上させるための技術、を提供することにある。

本発明のある態様は、ウェブブラウザを搭載したウェブ表示端末と通信ネットワークを介して接続されるウェブサーバに関する。
このウェブサーバは、ユーザの属性に応じたウェブページ間の関連を示す関連情報を保持し、ウェブ表示端末からウェブページの取得要求を受信すると、取得要求されたウェブページだけでなく、取得要求元のユーザの属性と関連情報に基づいて特定される別のウェブページも送信する。

本発明の別の態様もまた、ウェブブラウザを搭載したウェブ表示端末と通信ネットワークを介して接続されるウェブサーバに関する。
このウェブサーバは、ウェブ表示端末からウェブページの取得要求を受信すると、取得要求されたウェブページだけでなく、このウェブ表示端末のユーザが過去において当該ウェブページを取得要求した後に取得要求したことがある別のウェブページも送信する。

本発明のさらに別の態様もまた、ウェブブラウザを搭載したウェブ表示端末と通信ネットワークを介して接続されるウェブサーバに関する。
このウェブサーバは、ウェブ表示端末からウェブページの取得要求を受信すると、取得要求されたウェブページだけでなく、過去において当該ウェブページが取得要求された後に取得要求されることが多かった別のウェブページも送信する。

本発明のさらに別の態様は、ウェブ表示端末に関する。
このウェブ表示端末は、ウェブページのアドレスが指定されると、指定されたアドレスのウェブページを取得して画面表示させる。また、ウェブページの取得要求履歴を参照し、過去においてこのウェブページの取得要求後に取得要求した別のウェブページも取得する。

なお、以上の構成要素の任意の組合せ、本発明を方法、システム、記録媒体、コンピュータプログラムにより表現したものもまた、本発明の態様として有効である。

本発明によれば、ユーザにとっていっそう快適なウェブ閲覧技術を実現できる。

図１は、ウェブシステム３１０のハードウェア構成図である。
ウェブシステム３１０においては、ウェブサーバ１００ａ、１００ｂ、１００ｃなどの複数のウェブサーバ（以下、単に「ウェブサーバ１００」とよぶ）が、ウェブ表示端末２００ａ、２００ｂ、２００ｃなどの複数のウェブ表示端末（以下、単に「ウェブ表示端末２００」とよぶ）とインターネット３００を介して接続されている。

ウェブ表示端末２００は、インターネット３００を介してウェブサーバ１００にアクセスし、所望のウェブページを取得する。まず、ウェブ表示端末２００のユーザは、ウェブページを特定するためのアドレスとしてＵＲＬを入力する。ＵＲＬは、ハイパーリンクのクリックにより入力されてもよい。ウェブ表示端末２００は、ＵＲＬにより特定されるウェブページの取得要求（以下、単に「ページリクエスト」とよぶ）をウェブサーバ１００に送信する。ページリクエストを受け取ったウェブサーバ１００は、要求されているウェブページをウェブ表示端末２００に送信する。ウェブ表示端末２００は、こうして受信したウェブページを画面表示させる。

本実施例においてページリクエストが送信される状況として、ＵＲＬ等のユーザによる明示的な指定によりウェブページを取得する場合と、ユーザによる明示的な指定がなくともウェブ表示端末２００からウェブページを暗黙的に取得する場合を示す。前者におけるページリクエストと後者におけるページリクエストを区別するときには、それぞれ「明示リクエスト」、「暗黙リクエスト」とよぶことにする。特に区別しない場合には、単に「ページリクエスト」とよぶことにする。

図２は、ウェブサーバ１００の機能ブロック図である。
ここに示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。図９に示すウェブ表示端末２００の機能ブロック図についても同様である。
ここでは、各部の機能を中心として説明し、それらの連携、データ構造、作用については、図３以降に関連して詳述する。

ウェブサーバ１００は、通信部１１０、データ処理部１２０およびデータ保持部１３０を含む。
通信部１１０は、ウェブ表示端末２００との通信を担当する。データ処理部１２０は、通信部１１０やデータ保持部１３０から取得されたデータを元にして各種のデータ処理を実行する。データ処理部１２０は、通信部１１０とデータ保持部１３０の間のインタフェースの役割も果たす。データ保持部１３０は、各種データを保持するための記憶領域である。

通信部１１０：
通信部１１０は、ページ送信部１１２と要求受信部１１６を含む。要求受信部１１６は、ウェブ表示端末２００からページリクエストを受信する。ページ送信部１１２は、要求されたウェブページをウェブ表示端末２００に送信する。ページ送信部１１２に含まれる推奨送信部１１４は、「推奨メッセージ」とよばれるデータをウェブ表示端末２００に送信する。推奨メッセージについては、「推奨型」に関連して後述する。

データ処理部１２０：
データ処理部１２０は、関連ページ特定部１２２と更新処理部１２４を含む。関連ページ特定部１２２は、明示リクエストされるウェブページ（以下、「指定ページ」という）に対して関連するウェブページ（以下、「関連ページ」という）を特定する。関連ページの特定方法として、「Ａ．ユーザ属性型」、「Ｂ．ユーザ要求履歴型（Ｓ）」、「Ｃ．統計要求履歴型」、「Ｄ．ユーザ要求履歴型（Ｃ）」の４種類の考え方を開示するが、詳しくは後述する。更新処理部１２４は、各ウェブページに対するアクセスに応じてデータ保持部１３０の各種データを更新する。詳しくは後述する。

データ保持部１３０：
データ保持部１３０は、ページ保持部１３２、ユーザ属性保持部１３４、関連情報保持部１３６、要求履歴保持部１３８および統計履歴保持部１４０を含む。
ページ保持部１３２は、さまざまなウェブページのデータをＵＲＬと対応づけて保持する。
なお、データ保持部１３０に含まれるデータの全部または一部は、ウェブサーバ１００とは異なる外部のデータベースに保持されてもよい。この場合、ウェブサーバ１００は、外部のデータベースから適宜必要な範囲にてデータを取得し、ハードディスクやメモリ、キャッシュ等に一時的に保持して処理することにより、本実施例と同等の機能を発揮させることができる。

ユーザ属性保持部１３４と関連情報保持部１３６は、ユーザ属性型による関連ページ特定方法に関わる。ユーザ属性保持部１３４は、ウェブ表示端末２００のユーザとそのユーザ属性を対応づけた「ユーザ属性情報」を保持する。ページリクエストには、ユーザを特定するためのユーザＩＤが含まれるので、ページリクエストを受け取ったときその送信要求元のユーザを特定できる。あるいは、ＩＰアドレスやポート番号等によりユーザを特定してもよい。ユーザ属性とは、たとえば、年齢や性別などの身体に関する属性、世帯構成や居住地、趣味などの生活に関する属性、年収や職種などの社会的地位に関する属性等、ユーザに特有の情報であればよい。また、ユーザが開設する金融口座から保有株式や預金残高等の資産情報が得られるときには、このような資産情報をユーザ属性として利用してもよい。関連情報保持部１３６は、ユーザ属性を指定ページの組合せに関連ページを対応づける「関連情報」を保持する。関連情報保持部１３６のデータ構造については図３に関連して後述する。

要求履歴保持部１３８は、ユーザ要求履歴型（Ｓ）に関わる。要求履歴保持部１３８は、ユーザごとのウェブページの取得要求履歴を示す「要求履歴情報」を保持する。更新処理部１２４は、明示リクエストが受信されるごとに要求履歴情報を更新する。要求履歴保持部１３８のデータ構造については図５に関連して後述する。

統計履歴保持部１４０は、統計要求履歴型に関わる。統計履歴保持部１４０は、全体としてのウェブページの取得要求傾向を示す「統計履歴情報」を保持する。更新処理部１２４は、明示リクエストが受信されるごとに統計履歴情報を更新する。統計履歴保持部１４０のデータ構造については図７に関連して後述する。

本実施例においては、更新処理部１２４は、要求受信部１１６が明示リクエストを受信するごとに要求履歴情報や統計履歴情報を更新する。
変形例として、要求履歴保持部１３８と統計履歴保持部１４０は、外部装置から送信される要求履歴情報や統計履歴情報を保持してもよい。あるいは、要求履歴保持部１３８や統計履歴保持部１４０は、要求履歴情報や統計履歴情報を所与の情報として保持してもよい。

まず、Ａ．ユーザ属性型、Ｂ．ユーザ要求履歴型（Ｓ）、Ｃ．統計要求履歴型のそれぞれについて説明する。その後、ウェブ表示端末２００による関連ページの特定方法としてＤ．ユーザ要求履歴型（Ｃ）を説明する。

［Ａ．ユーザ属性型］
図３は、関連情報保持部１３６のデータ構造図である。
指定ページ欄１４２は指定ページを示す。ユーザ属性欄１４４はユーザ属性を示す。同図においては、ユーザの年齢を「２０歳以下」の未成年層、「２１歳以上３０歳以下」の若年層、「３１歳以上６０歳以下」の壮年層、「６１歳以上」の老年層の４つの年齢層に分類している。

関連情報は、ユーザ属性と指定ページの組合せに対して関連ページを対応づける。同図に示す関連情報によれば、未成年層のユーザはウェブページＡを取得要求した後に、ウェブページＢ、Ｃ、Ｄを取得要求する可能性が高いとして設定されている。一方、壮年層のユーザは、ウェブページＡを取得要求した後には、ウェブページＣ、Ｅ、Ｆを取得要求する可能性が高いとして設定されている。また、老年層のユーザは、ウェブページＡを取得要求した後には、ウェブページＦ、Ｈを取得要求する可能性が高いとして設定されている。

関連情報は、ウェブサーバ１００の管理者が任意に設定すればよい。たとえば、若年層ユーザはウェブページＡの次にウェブページＢにアクセスする傾向があるという知見が得られたとする。この場合、管理者は、若年層およびウェブページＡに対してウェブページＢを関連づければよい。

あるいは、ウェブページＡの内容とウェブページＢの内容の関連性から関連情報を設定してもよい。たとえば、ウェブページＡが公開中の映画の一覧を示すページであり、ウェブページＡのアニメ映画欄をクリックするとアニメ映画の一覧を示すウェブページＤが表示されるとする。一方、ウェブページＡの任侠映画欄をクリックすると任侠映画の一覧を示すウェブページＦが表示されるとする。アニメ映画に最も興味をもつのは未成年層、任侠映画に最も興味をもつのは老年層であると想定する。この場合、管理者は、未成年層およびウェブページＡに対してウェブページＤを関連づけ、老年層およびウェブページＡに対してウェブページＦを関連づけてもよい。
このように、関連情報においては、ユーザ属性ごとに、ある指定ページが明示リクエストされたとき、新たに明示リクエストされる可能性が高いウェブページが関連づけられる。

明示リクエストが受信されると、関連ページ特定部１２２は、まず、ユーザ属性情報を参照してリクエスト元のユーザのユーザ属性を特定する。そして、関連情報を参照し、明示リクエストによる指定ページとユーザ属性の組合せに対応づけられているウェブページを関連ページとして特定する。たとえば、若年層のユーザがウェブページＡを明示リクエストしてきたときには、ウェブページＢ、Ｃ、Ｅが関連ページとして特定されることになる。

ページ送信部１１２は、明示リクエストされた指定ページに加えて、関連ページ特定部１２２により特定された関連ページもウェブ表示端末２００に送信する。上記例の場合、ページ送信部１１２は、指定ページＡだけでなく、関連ページＢ、Ｃ、Ｅも送信することになる。ウェブ表示端末２００は、指定ページＡを画面表示させ、関連ページＢ、Ｃ、Ｅをローカルストレージに保持（キャッシュ）しておく。このユーザが、管理者の予想通り関連ページＢを表示させようとしたときには、既に保持されているウェブページＢがそのまま表示されることになる。このため、初めて表示されるウェブページＢでありながら、ローカルストレージからの読み出しにより画面表示させることができる。
このように、ユーザ属性と指定ページの組合せから将来的に要求される可能性が高い関連ページを予測しておき、ユーザによって実際に取得要求される前に関連ページを送信しておくことにより、表示ページの切り換え時における通信待ち時間の発生を抑制できる。

ここでは、ユーザ属性として年齢を例として説明したが、その他のユーザ属性についての関連情報を別途設定してもよい。たとえば、あるユーザ「０１」には「２４歳、岡山県在住」という２種類のユーザ属性が登録されているとする。また、「岡山県」という居住地に関するユーザ属性と指定ページＡの組合せには、関連ページＢ、Ｆ、Ｉが設定されているとする。図３の年齢層に関する関連情報においては「２４歳（若年層）」というユーザ属性と指定ページＡの組合せには、関連ページＢ、Ｃ、Ｄが設定されている。関連ページ特定部１２２は、このユーザ「０１」が指定ページＡを明示リクエストしてきたときには、論理和計算によりウェブページＢ、Ｃ、Ｄ、Ｆ、Ｉを関連ページとして特定してもよいし、論理積計算によりウェブページＢのみを関連ページとして特定してもよい。
また、資産情報に基づいて関連情報を特定してもよい。たとえば、あるユーザ「０２」がＡ社の株式保有者である場合、ユーザ「０２」はＡ社に関するウェブページに興味を持つ可能性が高いと考えられる。一例として、Ａ社株の株式分割を伝えるウェブページと、Ａ社株保有者というユーザ属性に対する関連ページとして対応づけてもよい。また、資産情報に基づいて関連ページを特定する場合、ユーザの資産内容が変化するごとに動的に関連情報を変化させることができる。

変形例として、ウェブページの取得要求履歴に基づいて動的に関連情報を生成・更新してもよい。
たとえば、所定期間において、未成年層ユーザがウェブページＡを明示リクエストした後、ウェブページＢ、Ｃ、Ｄ、Ｅを明示リクエストした回数がそれぞれ３０回、２５回、１５回、５回であるとする。この場合、未成年層と指定ページＡの組合せについての関連ページは、その取得回数が所定回数、たとえば、１０回以上であるウェブページＢ、Ｃ、Ｄとして特定されてもよい。このように回数についての閾値条件を設定し、ユーザ属性に応じた各ウェブページの取得要求実績に基づいて関連ページを特定してもよい。
あるいは、ウェブページＢ、Ｃ、Ｄ、Ｅのうち取得回数の多い順に上位数ページ、たとえば、上位２ページを関連ページとして特定してもよい。上記例の場合、未成年層と指定ページＡについての関連ページはウェブページＢ、Ｃとなる。

回数ではなく、確率により関連ページを特定してもよい。上記例の場合、未成年層ユーザがウェブページＡを明示リクエストした後、ウェブページＢ、Ｃ、Ｄ、Ｅを明示リクエストする確率は、
ウェブページＢ＝３０÷（３０＋２５＋１５＋５）＝４０％
ウェブページＣ＝２５÷（３０＋２５＋１５＋５）＝約３３％
ウェブページＤ＝１５÷（３０＋２５＋１５＋５）＝２０％
ウェブページＥ＝５÷（３０＋２５＋１５＋５）＝約７％
となる。関連ページ特定部１２２は、この確率が所定確率、たとえば、３５％以上となるウェブページを関連ページとして特定してもよい。この場合、ウェブページＢのみが関連ページとなる。
このように、指定ページの取得要求後に取得要求された回数に関して定められる条件の成否に基づいて、関連ページを特定してもよい。これは、後に説明するユーザ要求履歴型（Ｓ）、統計要求履歴型、ユーザ要求履歴型（Ｃ）についても同様である。

関連情報を動的に更新する場合、更新処理部１２４は、ユーザごとに、あるウェブページが明示リクエストされた後にどのウェブページが明示リクエストされているかに応じて関連情報を更新する。このような態様によれば、取得要求実績に応じて関連情報を動的に更新することができるため、より合理的に関連ページを特定しやすくなる。

図４は、ユーザ属性型におけるウェブページ取得処理過程を示すシーケンス図である。
まず、ウェブ表示端末２００のユーザは、ＵＲＬの指定やハイパーリンクのクリックにより、取得対象のウェブページを指定する（Ｓ１０）。指定されたウェブページが既に保持されている場合、いいかえればローカルストレージにキャッシュされているときには（Ｓ１２のＹ）、ウェブサーバ１００にアクセスすることなく指定ページを読み出して表示させる（Ｓ２０）。一方、キャッシュされていないときには（Ｓ１２のＮ）、ウェブ表示端末２００は明示リクエストをウェブサーバ１００に送信する（Ｓ１４）。

ウェブサーバ１００の要求受信部１１６が明示リクエストを受信すると、ページ送信部１１２はページ保持部１３２に保持されている指定ページを読み出して、ウェブ表示端末２００に送信する（Ｓ１６）。ウェブ表示端末２００は、受信した指定ページを画面表示させる（Ｓ１８）。

一方、関連ページ特定部１２２は、明示リクエストに含まれるユーザＩＤによりユーザを特定する（Ｓ２４）。次に、関連ページ特定部１２２は、ユーザ属性情報を参照して、ユーザ属性を特定し（Ｓ２６）、関連情報を参照してユーザ属性と指定ページから関連ページを特定する（Ｓ２８）。ページ送信部１１２は、特定された一以上の関連ページをウェブ表示端末２００に送信する（Ｓ３０）。ウェブ表示端末２００はこの関連ページを保持しておき、将来の表示に備える（Ｓ２２）。

ウェブ表示端末２００における指定ページ表示処理の負荷を考慮して、ページ送信部１１２は指定ページを送信後、所定時間、たとえば、１０秒程度待機した上で、関連ページを送信してもよい。このようなタイムラグを設ければ、通信ビジーでないときに関連ページを送信しやすくなるため、ウェブ表示端末２００が一時的に過負荷となるのを防ぎやすくなる。これは、後に説明するユーザ要求履歴型（Ｓ）、統計要求履歴型についても同様である。

ウェブ表示端末２００に状況からみて将来的に明示リクエストされる可能性が高い関連ページを保持させておくことにより、Ｓ１２におけるキャッシュのヒット率を向上させることができる。通常、あるウェブページＡを表示させているときに新たに別のウェブページＢを表示させるときには、Ｓ１４、Ｓ１６に示す通信アクセスが発生する。ユーザ属性型による関連ページ特定方法によれば、ユーザ属性に応じて将来的に取得が予想される関連ページをあらかじめ送信しておくことができるため、新たなウェブページを表示させるときの処理負荷、特に、通信アクセスにともなう処理負荷を軽減できる。したがって、軽快にページ切り換え可能なウェブ閲覧技術が実現される。図４に示すシーケンスの場合、Ｓ１８にて指定ページを表示させているときにバックグラウンドで関連ページの取得・保持が実行されるため、ユーザは関連ページ取得処理を意識する必要はない。

［Ｂ．ユーザ要求履歴型（Ｓ）］
図５は、要求履歴保持部１３８のデータ構造図である。
ユーザ欄１５０はユーザＩＤを示す。日付欄１５２は、アクセス日時を示す。要求履歴欄１５４は、ユーザごとのウェブページの取得要求履歴を示す。

ユーザＩＤ「０１」のユーザ（以下、単に「ユーザ（０１）」と表記する）は、２００７年６月１４日には、ウェブページＡ、Ｂ、Ｃ、Ｂ、Ｄ、Ｂ、・・の順にウェブページを明示リクエストしている。要求履歴欄１５４を参照すると、ユーザ（０１）は、２００７年６月１４日から１６日の３日間において、ウェブページＡを取得要求した後に、Ｂを４回、Ｃを１回、Ｄを１回、Ｅを２回、Ｈを１回取得要求している。関連ページ特定部１２２は、この取得回数が所定回数、たとえば、２回以上となるウェブページを、ユーザ（０１）と指定ページＡの組合せに対する関連ページとして特定する。この例では、ウェブページＢとＥが関連ページとして特定されることになる。

一方、ユーザ（０２）は、同期間において、ウェブページＡを取得要求した後に、Ｄを３回、Ｇを２回、Ｈを３回、Ｉを１回、Ｊを３回取得要求している。このため、関連ページ特定部１２２は、ユーザ（０２）と指定ページＡの組合せに対する関連ページとして、ウェブページＤ、Ｇ、Ｈ、Ｊを特定する。

明示リクエストが受信されると、関連ページ特定部１２２は、まず、要求履歴情報を参照してリクエスト元のユーザと指定ページから関連ページを特定する。ページ送信部１１２は、指定ページだけでなく関連ページもウェブ表示端末２００に送信する。ウェブ表示端末２００は、指定ページを画面表示させ、関連ページをローカルストレージに保持しておく。ユーザのページ要求履歴に応じて将来的に要求される可能性が高い関連ページを予測しておき、ユーザによって実際に取得要求される前に関連ページを送信しておくことにより、表示ページの切り換え時における通信待ち時間の発生を抑制できる。

ニューズサイトやブログなど特定のウェブページを毎日見るユーザも多い。あるユーザは、会社に出勤した後にウェブページＡ、Ｂ、Ｃを確認したあとに仕事に取りかかるという習慣を持っているかもしれない。この場合、ウェブページＡが明示リクエストされたときには、ウェブページＢやＣも明示リクエストされる可能性が高い。ユーザ要求履歴型によれば、ユーザ個々の習慣に鑑みて関連ページを特定できる。

更新処理部１２４は、ユーザごとに、あるウェブページが明示リクエストされた後にどのウェブページが明示リクエストされているかに応じて要求履歴情報を更新する。

なお、指定ページの取得要求直後に取得要求されたウェブページを関連ページとして特定してもよい。この場合には、ユーザ（０１）と指定ページＡの組合せについての関連ページは、Ｂ、Ｈ、Ｅとなり、ユーザ（０２）と指定ページＡの組合せについての関連ページは、Ｄのみとなる。

また、ウェブページＡの取得要求直後に取得要求されたウェブページはそれ以降に取得されたウェブページよりも重み付けされるように関連度を算出してもよい。たとえば、直後取得のウェブページの関連度を「２」、それ以降に取得されるウェブページの関連度を「１」とすると、ユーザ（０１）と指定ページＡの組合せについては、Ｂの関連度＝２＋１＋１＋１＝５、Ｃの関連度＝１、Ｄの関連度＝１、Ｅの関連度＝１＋２＝３、Ｈの関連度＝２となる。この関連度について定められる条件の成否に基づいて関連ページを特定してもよい。たとえば、関連度が所定値以上となるウェブページを関連ページとして特定してもよい。

図６は、ユーザ要求履歴型（Ｓ）におけるウェブページ取得処理過程を示すシーケンス図である。
同図においてＳ１０からＳ２２までに示す処理の内容は、図４において同一の符号を付して説明した処理の内容と同等である。

関連ページ特定部１２２は、明示リクエストが受信されると、送信元のユーザを特定する（Ｓ４０）。関連ページ特定部１２２は、要求履歴情報を参照して、送信元のユーザと指定ページから関連ページを特定する（Ｓ４２）。ページ送信部１１２は、特定された一以上の関連ページをウェブ表示端末２００に送信する（Ｓ４４）。ウェブ表示端末２００はこの関連ページを保持しておき、将来の表示に備える（Ｓ２２）。

ユーザ要求履歴型による関連ページの特定方法によれば、ユーザの過去のアクセス履歴から将来的に取得が予想される関連ページをあらかじめ送信しておくことができるため、新たなウェブページを表示させるときの処理負荷、特に、通信アクセスにともなう処理負荷を軽減できる。図６に示すシーケンスの場合においても、Ｓ１８にて指定ページを表示させているときにバックグラウンドで関連ページの取得・保持が実行されるため、ユーザは関連ページ取得処理を意識する必要はない。

［Ｃ．統計要求履歴型］
図７は、統計履歴保持部１４０のデータ構造図である。
指定ページ欄１６０は指定ページを示す。次回ページ欄１６２は、指定ページの直後に取得要求されるウェブページ（以下、「次回ページ」とよぶ）を示す。次々回ページ欄１６４は、次回ページの次に取得要求されるウェブページ（以下、「次々回ページ」とよぶ）を示す。

たとえば、指定ページＡの次回ページとして、ウェブページＢが選択される確率は４０％であるがウェブページＤが選択される確率は１０％である。また、指定ページＡの次々回ページとして、ウェブページＣが選択される確率は２０％であり、ウェブページＢが選択される確率は１０％である。統計要求履歴型による関連ページ特定方法の場合、関連ページ特定部１２２は、次回ページまたは次々回ページとして選択される確率が所定確率、たとえば、３０％以上となるウェブページを関連ページとして特定する。この場合、ウェブページＢがウェブページＡの関連ページとして特定される。

あるいは、次回ページとしての選択確率と次々回ページとしての選択確率の加算値が所定確率、たとえば、５０以上となるウェブページを関連ページとして特定してもよい。同図によれば、指定ページＡに関しては、ウェブページＢの加算値＝４０＋１０＝５０、ウェブページＣの加算値＝２０＋２０＝４０となる。次々回ページよりも次回ページの方に重み付けをして加算値を計算してもよい。関連ページ特定部１２２は、この加算値が所定の閾値、たとえば、４０以上となるウェブページを関連ページとして特定してもよい。この場合、ウェブページＢとＣが関連ページとして特定される。

明示リクエストが受信されると、関連ページ特定部１２２は、統計履歴情報を参照して指定ページについての関連ページを特定する。ページ送信部１１２は、指定ページだけでなく関連ページもウェブ表示端末２００に送信する。ウェブ表示端末２００は、指定ページを画面表示させ、関連ページをローカルストレージに保持しておく。多数のユーザによるページ要求履歴から統計的に計算される統計履歴情報に基づいて将来的に要求される可能性が高い関連ページを予測し、実際に関連ページが取得要求される前に送信しておくことにより、表示ページの切り換え時における通信待ち時間の発生を抑制できる。

ウェブページの取得要求履歴には、なんらかの傾向が現れることがある。たとえば、マネーサプライの推移を示すウェブページがチェックされるときには、消費者物価指数の推移を示すウェブページもチェックされることが多いかもしれない。また、メジャーリーグニュースを示すウェブページがチェックされたときには、日本のプロ野球のニュースもチェックされる可能性が高いかもしれない。統計要求履歴型によれば、複数のユーザによる統計的なアクセス傾向に鑑みて関連ページを特定できる。

更新処理部１２４は、あるウェブページが明示リクエストされた後にどのウェブページが明示リクエストされているかに応じて統計履歴情報を更新する。

図８は、統計要求履歴型におけるウェブページ取得処理過程を示すシーケンス図である。
同図においてＳ１０からＳ２２までに示す処理の内容は、図４において同一の符号を付して説明した処理の内容と同等である。

関連ページ特定部１２２は、明示リクエストが受信されると、統計履歴情報を参照して、指定ページに対する関連ページを特定する（Ｓ５０）。ページ送信部１１２は、特定された一以上の関連ページをウェブ表示端末２００に送信する（Ｓ５２）。ウェブ表示端末２００はこの関連ページを保持しておき、将来の表示に備える（Ｓ２２）。

統計要求履歴型による関連ページの特定方法によれば、統計的なアクセス傾向から将来的に取得が予想される関連ページをあらかじめ送信しておくことができるため、新たなウェブページを表示させるときの処理負荷、特に、通信アクセスにともなう処理負荷を軽減できる。図８に示すシーケンスの場合においても、Ｓ１８にて指定ページを表示させているときにバックグラウンドで関連ページの取得・保持が実行されるため、ユーザは関連ページ取得処理を意識する必要はない。

以上においては、ユーザ属性型、ユーザ要求履歴型（Ｓ）、統計要求履歴型のいずれにおいても、ウェブサーバ１００が関連ページをウェブ表示端末２００に能動的に送信するとして説明した。
変形例として、ウェブ表示端末２００からの暗黙リクエストを受けてから関連ページを送信するとしてもよい。以下、このような関連ページ送信方法を「推奨型」とよぶことにし、既述した関連ページ送信方法を「能動型」として区別する。

推奨型の場合、関連ページ特定部１２２が関連ページを特定すると、推奨送信部１１４は関連ページを通知するための推奨メッセージをウェブ表示端末２００に送信する。ウェブ表示端末２００は推奨メッセージを受け取ると、推奨メッセージに対する応答メッセージとして、関連ページについてのページリクエストを送信する。関連ページは、ユーザが明示的にアドレス指定にすることにより特定されるウェブページではない。したがって、この関連ページについてのページリクエストは暗黙リクエストである。暗黙リクエストには、推奨メッセージに含まれていた関連ページのページＩＤがそのまま含まれる。ウェブサーバ１００は、暗黙リクエストを受信すると、関連ページをウェブ表示端末２００に送信する。

能動型の場合、推奨メッセージや暗黙リクエストといった通信プロセスを経ることなく、ウェブサーバ１００が関連ページを送信できるため、推奨型よりも通信アクセスの回数を抑制しやすいというメリットがある。
推奨型の場合、ウェブ表示端末２００の側で関連ページの取得要求タイミングを制御できるというメリットがある。ウェブ表示端末２００は、推奨メッセージを受信すると、ネットワークインタフェースやＣＰＵの処理負荷に鑑みて、自らにとって都合のいいタイミングにて暗黙リクエストを送信すればよい。より具体的には、ＣＰＵの使用率やメモリの使用率、ネットワークインタフェースにおける受信パケット数等が所定値以下であることを条件として暗黙リクエストを送信してもよい。また、推奨メッセージが示す関連ページを既にローカルストレージに保持しているときには、暗黙リクエストを送信する必要はない。このような場合には、関連ページの送信プロセスそのものを発生させなくて済むというメリットもある。

ウェブ表示端末２００は、ＲＳＳ（Rich Site Summary）の仕組みにより、あらかじめ監視対象としたいウェブページを登録しておいてもよい。ウェブ表示端末２００は、この登録されているウェブページを関連ページとして特定し、ローカルストレージに保持しておいてもよい。ＲＳＳに登録されるウェブページは、ユーザにとって興味のあるウェブページであると考えられるため、このようなウェブページを事前取得しておくことにより、Ｓ１２におけるキャッシュヒット率を向上させることができる。

［Ｄ．ユーザ要求履歴型（Ｃ）］
ユーザ要求履歴型（Ｃ）による関連ページ特定方法は、ユーザ要求履歴型（Ｓ）の関連ページ特定方法と基本的な考え方において共通である。上述したユーザ要求履歴型（Ｓ）の場合、ウェブサーバ１００はユーザごとの取得要求履歴に応じて関連ページを特定した。これに対して、ユーザ要求履歴型（Ｃ）では、ウェブ表示端末２００がユーザによるウェブページの取得要求履歴に応じて関連ページを特定する。

図９は、ウェブ表示端末２００の機能ブロック図である。
ウェブ表示端末２００は、ユーザインタフェース処理部２１０、通信部２３０、データ処理部２２０およびデータ保持部２４０を含む。
ユーザインタフェース処理部２１０は、ユーザインタフェース処理全般を担当する。通信部２３０は、ウェブサーバ１００との通信を担当する。データ処理部２２０は、ユーザインタフェース処理部２１０や通信部２３０、データ保持部２４０から取得されたデータを元にして各種のデータ処理を実行する。データ処理部２２０は、ユーザインタフェース処理部２１０、通信部２３０およびデータ保持部２４０の間のインタフェースの役割も果たす。データ保持部２４０は、各種データを保持するための記憶領域である。

ユーザインタフェース処理部２１０：
ユーザインタフェース処理部２１０は、ページ指定部２１２、ページ選択部２１４、ページ表示部２１６および履歴表示部２１８を含む。
ページ指定部２１２は、ユーザから指定ページのアドレスの入力を受け付ける。ページ表示部２１６は、指定ページを画面表示させる。ページ選択部２１４は、図１０に関連して詳述する履歴表示画面２５０において、関連ページを選択するためのユーザの入力を受け付ける。履歴表示部２１８は、履歴表示画面２５０を画面表示させる。

通信部２３０：
通信部２３０は、ページ要求部２３２、ページ取得部２３４および推奨受信部２３６を含む。
ページ要求部２３２は、ページリクエストをウェブサーバ１００に送信する。ページ取得部２３４は、ウェブサーバ１００からウェブページを受信する。推奨受信部２３６は、ウェブサーバ１００から推奨メッセージを受信する。推奨受信部２３６の機能は、ユーザ属性型、ユーザ要求履歴型（Ｓ）、統計要求履歴型のいずれかが推奨型のときには必要であるが、それ以外、たとえば、ユーザ要求履歴型（Ｃ）やユーザ属性型の能動型の場合などでは必須構成ではない。

データ保持部２４０：
データ保持部２４０は、要求履歴保持部２４２とページキャッシュ部２４４を含む。要求履歴保持部２４２は、図５の要求履歴保持部１３８のデータ構造と同様のデータ構造にて、ウェブ表示端末２００のユーザによるウェブページの取得要求履歴を示す要求履歴情報を保持する。ページキャッシュ部２４４は、関連ページ等、ウェブサーバ１００から受信したウェブページを保持する。既に述べた「ローカルストレージ」に相当する。

データ処理部２２０：
データ処理部２２０は、関連ページ特定部２２２と更新処理部２２４を含む。関連ページ特定部２２２は、要求履歴情報を参照して、指定ページに対する関連ページを特定する。関連ページの特定方法については、ユーザ要求履歴型（Ｓ）に関して、特に図５に関連して説明した内容と同様である。更新処理部２２４は、ウェブページが取得要求されるごとに要求履歴情報を更新する。

図１０は、ユーザ要求履歴型（Ｃ）におけるウェブページ取得処理過程を示すシーケンス図である。
同図においてＳ１０からＳ２２までに示す処理の内容は、図４において同一の符号を付して説明した処理の内容と同等である。

関連ページ特定部１２２は、要求履歴情報を参照して、指定ページに対する関連ページを特定する（Ｓ６０）。ページ要求部２３２は、特定された一以上の関連ページをウェブサーバ１００に取得要求する（Ｓ６２）。このときの取得要求は暗黙リクエストの送信によりなされる。ウェブサーバ１００は、要求された関連ページをウェブ表示端末２００に送信する（Ｓ６４）。ウェブ表示端末２００は関連ページをローカルストレージ、すなわち、ページキャッシュ部２４４に保持しておき、以降の表示に備える（Ｓ２２）。
ユーザ要求履歴型（Ｃ）による関連ページ特定方法によれば、ユーザによるウェブページの取得要求履歴に応じて将来的に取得が予想される関連ページをあらかじめ受信しておくことにより、ページ切り換えの快適性を向上させることができる。図１０に示すシーケンスの場合においても、Ｓ１８にて指定ページを表示させているときにバックグラウンドで関連ページの取得・保持が実行されるため、ユーザは関連ページ取得処理を意識する必要はない。また、ユーザ要求履歴型（Ｃ）の場合、既存のウェブサーバに特段の機能追加が不要であるため、ウェブシステム３１０に導入しやすいというメリットがある。

図１１は、履歴表示画面２５０の画面図である。
履歴表示部２１８は、ユーザから指示されると要求履歴情報を図１１に示す態様にて画面表示させる。履歴表示画面２５０には所定期間、たとえば、１日分の要素履歴情報が画面表示される。アイコン２６０ａ〜２６０ｆは、それぞれウェブページを特定するためのページＩＤである。
たとえば、２００７年６月１９日において、ウェブ表示端末２００のユーザは、アイコン２６０ａに示されるウェブページ（以下、「ページａ」と表記する）を表示させた後、ページｂ、ｃ、ｄと順番に表示させ、いったんページａに戻った後、今度はページｅ、ｆの順に表示させたとする。履歴表示画面２５０においては、このような表示順序を反映したかたちにてアイコン２６０が並んで表示される。
更新処理部２２４は、ウェブページの表示切り換えが発生するごとに要求履歴情報を更新する。

履歴表示画面２５０において、アイコン２６０上にマウスカーソルを合わせると、該当ページについての関連ページのページＩＤがポップアップ表示される。
また、ユーザがアイコン２６０上にて左クリックすると、ページ選択部２１４は対象となるアイコン２６０を特定し、履歴表示部２１８は該当アイコン２６０上にチェックマークをつける。同図においては、ページｂとページｆにチェックマークがつけられている。チェックマークは、将来的に関連ページとして特定されるべきウェブページを明示的に指定するために付与される。同図に示す例の場合、ページａに対してはページｂ、ｆが関連ページとして明示指定される。また、ページｅに対してはページｆが関連ページとして明示指定される。

要求履歴保持部２４２においては、チェックマークの付与に基づくウェブページ間の関連性が設定される。チェックマーク付与後、ユーザが指定ページａの表示を指示したとき、関連ページ特定部２２２はチェックマークの付与されているページｂ、ｆを関連ページとして特定することになる。このように、ユーザは履歴表示画面２５０にて明示的に関連ページを設定できる。

以上、ウェブサーバ１００およびウェブ表示端末２００を実施例に基づいて説明した。
ウェブサーバ１００やウェブ表示端末２００によれば、ユーザ属性、ユーザごとのウェブページの取得要求履歴、あるいは、統計的なウェブページ取得要求傾向に基づいて、将来的に取得される可能性が高い関連ページを先読みできる。この先読みがヒットするほど、ウェブページ切り換え時における通信待ち時間の発生を抑制しやすくなる。

以上、本発明を実施例をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

なお、本実施例においては、更新処理部１２４は、明示リクエストが受信されると、要求履歴情報や統計履歴情報、あるいは、関連情報を更新するとして説明した。ウェブ表示端末２００は、ウェブページの切り換え時においては、キャッシュヒットの成否に関わらず、切り換え対象となるウェブページのページＩＤとユーザＩＤを含む「ページ切換メッセージ」をウェブサーバ１００に送信してもよい。ウェブサーバ１００の要求受信部１１６がこのページ切換メッセージを受信すると、更新処理部１２４は、要求履歴情報や統計履歴情報、あるいは、関連情報を更新するとしてもよい。このような態様によれば、キャッシュヒットして、明示リクエストが送信されない場合であっても、ウェブサーバ１００はウェブ表示端末２００においてどのようなウェブページが表示対象となっているかをより正確に検知できる。

なお、ユーザ属性型、ユーザ要求履歴型（Ｓ）、統計要求履歴型およびユーザ要求履歴型（Ｃ）のうちの２以上を組み合わせてもよい。たとえば、ユーザ属性により、指定ページに対する複数の関連ページを一次候補として特定し、これら複数の一次候補のうち、統計的に取得要求されることが多い関連ページを最終的に関連ページとして特定してもよい。

ウェブシステムのハードウェア構成図である。 ウェブサーバの機能ブロック図である。 関連情報保持部のデータ構造図である。 ユーザ属性型におけるウェブページ取得処理過程を示すシーケンス図である。 要求履歴保持部のデータ構造図である。 ユーザ要求履歴型（Ｓ）におけるウェブページ取得処理過程を示すシーケンス図である。 統計履歴保持部のデータ構造図である。 統計要求履歴型におけるウェブページ取得処理過程を示すシーケンス図である。 ウェブ表示端末の機能ブロック図である。 ユーザ要求履歴型（Ｃ）におけるウェブページ取得処理過程を示すシーケンス図である。 履歴表示画面の画面図である。

符号の説明

１００ ウェブサーバ、 １１０ 通信部、 １１２ ページ送信部、 １１４ 推奨送信部、 １１６ 要求受信部、 １２０ データ処理部、 １２２ 関連ページ特定部、 １２４ 更新処理部、 １３０ データ保持部、 １３２ ページ保持部、 １３４ ユーザ属性保持部、 １３６ 関連情報保持部、 １３８ 要求履歴保持部、 １４０ 統計履歴保持部、 １４２ 指定ページ欄、 １４４ ユーザ属性欄、 １５０ ユーザ欄、 １５２ 日付欄、 １５４ 要求履歴欄、 １６０ 指定ページ欄、 １６２ 次回ページ欄、 １６４ 次々回ページ欄、 ２００ ウェブ表示端末、 ２１０ ユーザインタフェース処理部、 ２１２ ページ指定部、 ２１４ ページ選択部、 ２１６ ページ表示部、 ２１８ 履歴表示部、 ２２０ データ処理部、 ２２２ 関連ページ特定部、 ２２４ 更新処理部、 ２３０ 通信部、 ２３２ ページ要求部、 ２３４ ページ取得部、 ２３６ 推奨受信部、 ２４０ データ保持部、 ２４２ 要求履歴保持部、 ２４４ ページキャッシュ部、 ２５０ 履歴表示画面、 ２６０ アイコン、 ２６２ チェックボックス、 ３００ インターネット、 ３１０ ウェブシステム。

Claims (3)

1. ウェブブラウザを搭載したウェブ表示端末と通信ネットワークを介して接続され、
   ウェブページを保持するページ保持部と、
   ウェブ表示端末のユーザの属性として、ユーザ属性情報を保持するユーザ属性保持部と、
   ウェブ表示端末から、ウェブページの取得要求を受信する要求受信部と、
   取得要求されたウェブページである指定ページを取得要求元のウェブ表示端末に送信するページ送信部と、
   指定ページと、指定ページに関連づけられているウェブページであって指定ページが取得要求された場合にその次に取得要求される可能性が高いウェブページである関連ページとの組み合わせがユーザの属性ごとに示された関連情報を保持する関連情報保持部と、
   前記取得要求元のウェブ表示端末のユーザについてのユーザ属性情報と前記関連情報に基づいて、前記ページ送信部において送信した指定ページに関連づけられている関連ページを特定する関連ページ特定部と、を備え、
   前記ページ送信部は、前記指定ページに加えて、前記特定された関連ページも前記取得要求元のウェブ表示端末に送信することを特徴とするウェブサーバ。
2. 前記ページ送信部は、前記関連ページの送信に際しては、前記特定された関連ページを示す推奨メッセージを前記取得要求元のウェブ表示端末に送信し、前記推奨メッセージに対する応答メッセージを受信したことを条件として前記関連ページを送信することを特徴とする請求項１に記載のウェブサーバ。
3. 表示対象となるウェブページのアドレスを指定するためのユーザによる入力を検出するページ指定部と、
   通信ネットワークを介して、前記指定されたアドレスのウェブページを指定ページとして取得するページ取得部と、
   指定ページを画面表示させるページ表示部と、
   ウェブページの取得要求履歴を示す要求履歴情報を保持する要求履歴保持部と、
   前記要求履歴情報を参照し、過去に取得要求されたウェブページのページＩＤを取得要求順に並べて画面表示させる履歴表示部と、
   ユーザによるページＩＤの選択を検出するページ選択部と、
   前記要求履歴情報を参照し、過去において前記指定ページの取得要求後に取得要求したウェブページのうち、ユーザにより選択されたページＩＤに対応するウェブページを将来的に取得要求される可能性が高いウェブページである関連ページとして特定する関連ページ特定部と、を備え、
   前記ページ取得部は、前記指定ページに加えて、前記特定された関連ページも取得することを特徴とするウェブ表示端末。

Images