JP3613550B2 - ウェブページ取得サービスシステム、サーバ、ウェブページ取得方法、記憶媒体及びプログラム伝送装置 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、インターネットに接続してウェブサーバからウェブページを取得し閲覧する作業を支援するウェブページの取得サービスに関する。
【０００２】
【従来の技術】
今日広く普及しているインターネットでは、ユーザの生活パターンに応じて、アクセスの量に時間的な偏りが生じている。すなわち、多くのインターネット・ユーザは日中に仕事を持っているため、個人的な要件でインターネットを利用するユーザは夜間にアクセスする場合が多い。したがって、夜間の通信量が増大し、回線が混雑することとなる。
【０００３】
通信ネットワークにおいて、通信量が増大すると、これに伴ってデータ転送に要する時間が長くなる。そのため、インターネットにおいても、夜間の回線混雑時には、ユーザが所望のサイトへのリクエストを送信してから当該サイトのウェブページソースがダウンロードされるまでの待ち時間が長くなり、作業効率が悪い。
また、一般ユーザの多くは、インターネットに接続するために、電話回線を用いたダイヤルアップ接続を行う。そのため、データ転送に長時間を要することによって回線接続の時間が長くなると、それだけ回線使用料も増加することとなり、経済的にも好ましくない。
一方、プロバイダにおいても、特定の時間帯にアクセスが集中すると、サーバの負担が増大するため、サービスが低下するおそれがある。
【０００４】
回線が混雑している時間帯にインターネットにアクセスすることを回避する手段として、自動巡回プログラムがある。自動巡回プログラムは、ユーザのクライアントマシンに搭載され、予め設定された時刻に自動的にプロバイダにアクセスして、インターネットに接続する。そして、予め登録されたサイトに自動的にリクエストを送信して、所望のウェブページソースをダウンロードする。
この自動巡回プログラムを、回線が混雑していない時間帯に動作するように設定しておけば、ウェブページソースを取得するための待ち時間を減らすことができる。
【０００５】
また、プロバイダのサーバには、通常、ユーザがアクセスしたサイトのウェブページソースを一時的に保持するキャッシュ機能がある。したがって、ユーザが頻繁にアクセスするサイトのウェブページに関しては、サーバのキャッシュメモリにデータが残っている間に再度リクエストがなされたならば、サーバに保持されているウェブページソースを当該ユーザのクライアントマシンに送ることができる。この場合、プロバイダと該当サイトとの間におけるリクエストの送信及びウェブページソースの返送が行われないため、その分だけユーザの待ち時間を減らすことができる。
【０００６】
【発明が解決しようとする課題】
上述したように、多くのユーザがインターネットにアクセスする時間帯は、そのアクセスによる通信量の増加のために、ユーザにとっては、待ち時間が長く作業効率の低下を招くと共に、回線使用料が増大し経済的でないという問題があった。
また、プロバイダにおいても、アクセスの集中によりサーバの負担が増大するという問題があった。
【０００７】
ユーザが回線混雑時のアクセスを回避するために自動巡回プログラムを用いる場合、当該ユーザに関しては、待ち時間の増加及び回線使用料の増大を抑えることができるものの、相当数のユーザがアクセスする時間帯としてそれぞれ異なる時間を選ぶのでなければ、プロバイダにおけるサーバの負担は軽減しない。
【０００８】
また、上述したように、通常、プロバイダのサーバにはキャッシュ機能があるが、キャッシュメモリに蓄えられたデータは、キャッシュメモリがいっぱいになると古いものから順に機械的に削除されてしまうため、ユーザがアクセスしようとするときに、必ずしも所望のデータが残っているとは限らず、ユーザの要求に答えられるものではなかった。
【０００９】
そこで本発明は、回線混雑時におけるユーザのアクセスに対して、待ち時間を短縮させると共に、プロバイダにおけるサーバの負担を軽減させることを目的とする。
【００１０】
また、本発明は、プロバイダにおいて、ユーザの要求を考慮して効率的にサイトへのアクセスを支援するシステムを提供することを目的とする。
【００１１】
【課題を解決するための手段】
かかる目的のもと、本発明は、通信ネットワークに接続されたウェブページ取得サーバとユーザ端末とを備え、このユーザ端末は、種々の取得条件を指定したウェブページ取得要求をウェブページ取得サーバに送信し、このウェブページ取得サーバは、ユーザ端末から受信したウェブページ取得要求の取得条件にしたがって、通信ネットワーク上のウェブサーバからウェブページソースを取得して保持し、このウェブページソースを、ウェブページ取得要求の取得条件にしたがって、ユーザ端末に転送することを特徴としている。
【００１２】
ここで、このユーザ端末は、ウェブページ取得要求の取得条件として、ウェブページソースを取得するための時間的条件を設定し、このウェブページ取得サーバは、このウェブページ取得要求にて設定された時間的条件に応じて、ウェブページソースを取得し、ユーザ端末に転送することを特徴としている。
時間的条件としては、ユーザ端末からウェブページ取得サーバに対してウェブページの転送要求を行う時刻を設定することができる。
このような構成とすることにより、ユーザは、所望のウェブページを所望の時間に確実に取得できる点で好ましい。
【００１３】
さらにここで、このウェブページ取得サーバは、ウェブページ取得要求にて設定された時間的条件と通信ネットワークにおける通信量の多少とを考慮してウェブページソースを取得するためのスケジューリングを行うことを特徴としている。
このような構成とすることにより、回線混雑時を避けてウェブページの取得が行われるため、ウェブページ取得サーバにおける負荷を軽減することができる点で好ましい。
【００１４】
またここで、このユーザ端末は、ウェブページ取得要求の取得条件として、ウェブページソースを取得する期限を指定し、このウェブページ取得サーバは、このウェブページ取得要求にて指定された取得期限の間にこのウェブページソースを取得することを特徴としている。
このような構成とすることにより、所望の期間内におけるウェブページソースを取得できる点で優れている。取得期限は、その開始と終了のいずれも指定することができる。
【００１５】
さらにここで、ウェブページ取得サーバは、複数のユーザ端末から同一のウェブページに対するウェブページ取得要求を受信した場合に、この複数のウェブページ取得要求に対して、対応するウェブページソースを１回取得して保持し、かつこのウェブページソースを、このウェブページ取得要求を送信した各ユーザ端末に転送することを特徴としている。
このような構成とすることにより、重複したウェブページ取得要求をまとめて処理することができるため、ウェブページ取得サーバにおける負荷を軽減させることができる点で好ましい。
【００１６】
また、本発明は、インターネットへの接続サービスを提供するプロバイダにおいて、ウェブページの取得条件を指定したウェブページ取得要求をユーザから受け付ける要求受付部と、このウェブページ取得要求の取得条件にしたがって、ウェブサーバからウェブページソースを取得して保持するウェブページ取得保存部と、このウェブページソースを、このウェブページ取得要求の取得条件にしたがって、このウェブページ取得要求を発信したユーザに転送する転送制御部とを備えることを特徴としている。
【００１７】
ここで、この転送制御部は、ウェブページ取得要求に従ってウェブページ取得保存部により取得され保持されているウェブページソースを、書庫ファイルにまとめて転送することを特徴としている。
このような構成とすることにより、ユーザは取得したウェブページソースをローカルな単一のファイルとして扱うことができる点で好ましい。
【００１８】
さらにここで、この転送制御部は、ウェブページソースの転送先であるユーザの端末装置において一度に受信できるデータファイルのサイズが限られている場合に、ウェブページ取得保存部に保持されているウェブページソースをこの端末装置が受信可能なサイズに分割した上で、各々書庫ファイルにまとめることを特徴としている。
このような構成とすれば、ユーザの端末装置が一度に受信できるデータファイルのサイズが小さい場合にも、ウェブページの取得サービスを受けることができる点で好ましい。
【００１９】
またここで、この転送制御部は、ウェブページ取得保存部に保持されているウェブページソースのリンクを、個々のウェブページソースのＵＲＬに基づく絶対的なリンクから、相対的なリンクに置き換えた上で転送することを特徴としている。
このような構成とすることにより、ユーザの端末装置において、ウェブページをローカルなファイルとして扱うことができる。
【００２０】
また、本発明は、通信ネットワーク上に設けられたウェブページ取得サーバによるウェブページ取得方法において、ウェブページの取得条件を指定したウェブページ取得要求をユーザから受け付けるステップと、このウェブページ取得要求の取得条件に基づいて、ウェブページソースを取得するためのスケジュールを作成するステップと、作成されたスケジュールにしたがって、通信ネットワーク上のウェブサーバからウェブページソースを取得して保持するステップと、このウェブページソースを、ウェブページ取得要求の取得条件にしたがって、ユーザに転送するステップとを含むことを特徴としている。
【００２１】
ここで、このスケジュールを作成するステップは、ウェブページ取得要求にて指定されたウェブページソースを取得するための時間的条件に従い、かつ通信ネットワークにおける通信量の多少に応じて、ウェブページ取得サーバ自身の負荷が少なくなるように、このウェブページ取得要求にて要求されるウェブページソースを取得する時間を決定するステップを含むことを特徴としている。
このような構成とすれば、回線混雑時を避けてウェブページを取得することができるため、効率的にウェブページの取得作業を行うことができる点で好ましい。
【００２２】
さらにここで、このスケジュールを作成するステップは、ウェブページ取得要求を受け付けるステップにおいて、複数のユーザから同一のウェブページに対するウェブページ取得要求を受け付けた場合に、各ウェブページ取得要求において指定されたウェブページを取得するための時間的条件を比較して、ウェブサーバからウェブページソースを取得する動作を行う回数ができるだけ少なくなるようにスケジュールを作成するステップを含むことを特徴としている。
このような構成とすれば、重複したウェブページ取得要求をまとめて処理することができるため、効率良くウェブページの取得作業を行うことができる点で好ましい。
【００２３】
また、本発明は、インターネットに接続した情報端末装置によるウェブページの取得方法において、プロバイダに対してウェブページの取得条件を指定したウェブページ取得要求を送信するステップと、このウェブページ取得要求の取得条件に含まれる時間的条件に基づいてプロバイダに対してウェブページの転送を要求するステップと、このウェブページの転送要求に応じてプロバイダから転送された、ウェブページの取得条件に適うウェブページソースを受信するステップとを含むことを特徴としている。
【００２４】
ここで、このウェブページの転送を要求するステップは、プロバイダからのウェブページを取得したことを知らせる通知を受信した場合に、このウェブページ取得要求の取得条件に含まれる時間的条件に関わらずに、プロバイダに対してウェブページの転送を要求するステップを含むことを特徴としている。
このような構成とすれば、プロバイダにおいて所望のウェブページが取得された後、任意のタイミングでこのウェブページを閲覧できる点で好ましい。
【００２５】
さらにここで、ウェブページソースを受信するステップにおいて、このウェブページを書庫ファイルの形式で受信することができる。
【００２６】
また、本発明は、コンピュータに実行させるプログラムをこのコンピュータの入力手段が読取可能に記憶した記憶媒体において、このプログラムは、ウェブページの取得条件を指定したウェブページ取得要求をユーザから受け付ける処理と、このウェブページ取得要求の取得条件に基づいて、ウェブページソースを取得するためのスケジュールを作成する処理と、作成されたスケジュールにしたがって、通信ネットワーク上のウェブサーバからウェブページソースを取得して保持する処理と、このウェブページソースを、このウェブページ取得要求の取得条件にしたがって、ユーザに転送する処理とをこのコンピュータに実行させることを特徴としている。
このような構成とすれば、このプログラムをインストールした全てのコンピュータにおいて、ウェブページ取得サービスを実施できる点で好ましい。
【００２７】
さらにまた、本発明は、コンピュータに、ウェブページの取得条件を指定したウェブページ取得要求をユーザから受け付ける処理と、このウェブページ取得要求の取得条件に基づいて、ウェブページソースを取得するためのスケジュールを作成する処理と、作成されたスケジュールにしたがって、通信ネットワーク上のウェブサーバからウェブページソースを取得して保持する処理と、このウェブページソースを、このウェブページ取得要求の取得条件にしたがって、ユーザに転送する処理とを実行させるプログラムを記憶する記憶手段と、この記憶手段からこのプログラムを読み出してこのプログラムを送信する送信手段とを備えたことを特徴としている。
このような構成とすれば、このプログラムをダウンロードした全てのコンピュータにおいて、ウェブページ取得サービスを実施できる点で好ましい。
【００２８】
【発明の実施の形態】
以下、添付図面に示す実施の形態に基づいてこの発明を詳細に説明する。
図１は、本実施の形態によるウェブページ取得サービスの概念を説明する図であり、図２は、本実施の形態におけるウェブページ取得サービスを実現するシステムの全体構成を示す図である。
【００２９】
図１を参照すると、本実施の形態によるサービスは、ユーザ１２０とウェブサイト１３０との間に介在するプロバイダ１１０により提供される。図２を参照すると、本実施の形態を実現するシステムは、インターネット２００に接続されたウェブページ取得サーバ２１０と、ユーザ端末２２０と、ウェブサーバ２３０とで構成される。
図１において、プロバイダ１１０には図２に示すウェブページ取得サーバ２１０が設置される。ユーザ１２０はユーザ端末２２０を操作して、ウェブページ取得サーバ２１０により提供されるサービスを享受する。ウェブサイト１３０はウェブサーバ２３０上に構築され、種々のウェブページソースを提供する。
【００３０】
図１を参照して本実施の形態によるサービスの概要を説明する。
ユーザ１２０は、プロバイダ１１０にアクセスし、当該プロバイダ１１０に対して、所望のウェブサイト１３０からウェブページを取得するための要求と当該ユーザ１２０のプロファイルとを送信する。ただし、ユーザ１２０のプロファイルはプロバイダ１１０に一度通知されていれば良く、アクセスのたびに送信する必要はない。プロバイダ１１０は、ユーザ１２０からの要求を受け付け、これに基づいてウェブサイト１３０からウェブページを取得して保持する。そして、ユーザ１２０の要求の内容に応じて、ユーザ１２０に対して通知を行い、ウェブページを転送する。
【００３１】
図３は、プロバイダ１１０に設定されるウェブページ取得サーバ２１０の構成を説明する図である。
図３において、符号３１０は要求受付部であり、ユーザ端末２２０から送信されたウェブページ取得要求及びプロファイルを受け付けて管理する。符号３２０はウェブページ取得保存部であり、要求受付部３１０で受け付けたユーザ端末２２０からのウェブページ取得要求に応じてウェブサーバ２３０からウェブページを取得し保存する。符号３３０は転送制御部であり、ウェブページ取得保存部３２０により取得されたウェブページのユーザ端末２２０への転送を制御する。
【００３２】
図４は、ユーザ１２０がユーザ端末２２０から送信するユーザプロファイルのフォーマットの例を示す図である。
ユーザプロファイルには、図示のように、ユーザ１２０に通知を行うための電子メール（Ｅ−ｍａｉｌ： Ｅｌｅｃｔｒｏｎｉｃ ｍａｉｌ）アドレス、ユーザ端末２２０が一度に受信できるデータの最大サイズ（最大転送サイズ）、転送するデータサイズが当該最大転送サイズを超える場合に分割転送をするか否かといった情報が含まれる。また、当該ユーザ１２０が定期的な取得を希望するウェブページのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）、当該ウェブページの取得頻度、取得する深さといった情報を含めることもできる。
【００３３】
ユーザプロファイルに含まれる情報において、分割転送を行うことを指定しておけば、転送するウェブページのデータサイズが最大転送サイズを超えている場合に、当該最大転送サイズ以内のサイズにデータファイルを分割して複数回に分けて転送を行うようにプロバイダ１１０に要求できる。分割転送を行わないことを指定している場合は、最大転送サイズ分のデータのみを転送することとなる。
ウェブページのＵＲＬとしては、ウェブブラウザに管理されているブックマークのデータリストを用いることもできる。
ウェブページの取得頻度とは、指定されたＵＲＬのウェブページを取得する頻度を指定する。図示の例では、ｗｗｗ．ａａａ．ｃｏ．ｊｐというＵＲＬを持つウェブページは月曜日、水曜日、金曜日の週３回取得し、ｗｗｗ．ｂｂｂ．ｃｏ．ｊｐ／ｎｅｗｓというＵＲＬを持つウェブページは毎日取得すると指定されている。例えば、ニュース等を提供しているウェブサイト１３０では、記事の内容が毎日更新されるので、毎日ウェブページを取得し、あまり頻繁には更新されないウェブサイト１３０は、数日おきにウェブページを取得するように設定することができる。
取得する深さは、ウェブページのリンクをどこまで辿ってウェブページソースを取得するかを指定する。例えば、ニュースを提供するウェブサイト１３０では、ウェブページの第１階層に各ニュースのヘッドラインが記述され、第２階層に各記事の内容を記述する。そこで、このようなウェブサイト１３０でどのようなニュースがあるかだけを知るためにウェブページを取得しようとするならば、第１階層を取得する深さとして指定する。また、各記事の内容までを取得したいのであれば、第２階層までを取得する深さとして指定する。
【００３４】
図５は、ユーザ１２０がユーザ端末２２０から送信するウェブページ取得要求のフォーマットの例を示す図である。
ウェブページ取得要求には、取得しようとするウェブページのＵＲＬのリスト、当該ウェブページをダウンロードする時刻、取得する深さといった情報が含まれる。また、当該ウェブページを取得する期限を指定することもできる。
【００３５】
ウェブページ取得要求に含まれる情報において、ウェブページをダウンロードする時刻を指定することによって、プロバイダ１１０に対していつまでに当該ウェブページをダウンロードすれば良いかを知らせることができる。
ウェブページのダウンロード時刻とは別に、当該ウェブページの取得期限を指定することにより、当該ウェブページのいつの時点における情報を取得するかを指定することができる。例えば、ニュースを提供するウェブサイト１３０からニュースに関するウェブページをダウンロードする場合、ウェブページの取得が早過ぎるとニュースが古くなってしまう。また、取得するウェブページの内容によっては、いつまでに取得しなければならないといった要請もあり得る。そこで、ウェブページの取得期限を指定して、適切な時期にウェブページを取得するようにすることができる。
【００３６】
なお、図４、図５に示したユーザプロファイル及びウェブページ取得要求に含まれる情報は例示に過ぎない。実際には、ウェブページのＵＲＬや取得する深さといった必須の情報の他、提供するサービスに応じて種々の情報を入力できるようにフォーマットを構成することができる。また、予めユーザ情報として登録しておくユーザプロファイルの情報と、必要に応じて所望の内容で送信するウェブページ取得要求の情報とを組み合わせることにより、種々のサービスを享受することができる。
【００３７】
要求受付部３１０は、上述したユーザプロファイル及びウェブページ取得要求を受け付けてユーザ１２０の情報を管理する。図３を参照すると、要求受付部３１０は、ユーザ１２０から受け取ったユーザプロファイルを管理するプロファイル管理部３１１と、ウェブページ取得要求を管理する要求管理部３１２とを備える。プロファイル管理部３１１は、受け付けたユーザプロファイルを、ユーザ管理データベース３４０に格納して管理する。そして、ウェブページ取得要求と共に、後述するスケジューリング処理のためにウェブページ取得保存部３２０に送る。要求管理部３１２は、受け付けたウェブページ取得要求をスケジューリング処理のためにウェブページ取得保存部３２０に送る。
【００３８】
ウェブページ取得保存部３２０は、要求受付部３１０から受け取ったユーザプロファイル及びウェブページ取得要求に基づいてウェブページを取得するためのスケジューリング処理を行うスケジューリング部３２１と、スケジューリング部３２１により作成されたスケジュールにしたがってウェブサーバ２３０からウェブページを取得するウェブページ取得部３２２とを備える。ウェブページ取得部３２２により取得されたウェブページソースはウェブページ保存データベース３５０に格納される。
【００３９】
転送制御部３３０は、ユーザ１２０に対して所望のウェブページを取得したことを電子メールにより通知する通知部３３１と、ウェブページ保存データベース３５０に格納されているウェブページにおけるリンクの付け替えを行うリンク処理部３３２と、リンクの付け替えが済んだウェブページをユーザ１２０に転送するｆｔｐ／ｈｔｔｐ転送部３３３とを備える。
【００４０】
図６は、本実施の形態におけるウェブページ取得サーバ２１０の動作を概略的に説明するフローチャートである。
初期条件として、ユーザプロファイルは既にプロバイダ１１０に送られており、ユーザ管理データベース３４０に格納されてプロファイル管理部３１１に管理されているものとする。そして、プロバイダ１１０によりインターネット接続サービスを受けている複数のユーザ１２０が、ユーザ端末２２０を用いてプロバイダ１１０にアクセスし、ユーザプロファイル及びウェブページ取得要求を送信したものとする。
【００４１】
図６を参照すると、まず、要求受付部３１０の要求管理部３１２が、ウェブページ取得要求を受信し、プロファイル管理部３１１にて管理されているユーザプロファイルの情報を加味して要求統合処理を行う（ステップ６０１）。要求統合処理とは、複数のユーザ１２０から受け取ったウェブページ取得要求を統合して取得しようとするウェブページのリスト（以下、取得リストと称す）を作成する処理である。この際、重複している要求は一つにまとめ、重複のない取得リストを作成する。ここで、重複している要求を統合するのは、複数のユーザ１２０からのウェブページ取得要求に対して、当該ウェブページを１回取得することで対応することにより、ウェブページ取得サーバ２１０の負担を軽減するためである。
なお、ウェブページ取得要求は、複数のユーザ端末２２０から随時入力されるので、所定の時点でウェブページ取得要求の受付をロックして、要求統合処理を行う。
【００４２】
図７は、二つのウェブページ取得要求を統合して重複のない取得リストを作成する例を説明する図である。
図７を参照すると、取得リスト７０３は、取得するウェブページごとに、当該ウェブページの取得を要求しているユーザ名、ダウンロード時刻、ＵＲＬ、取得する深さ、取得期限等の情報が登録されている。図示のフォーマットによれば、これらの情報が下記のように記述されている。
［ユーザ名］｜ダウンロード時刻｜ＵＲＬ｜取得する深さ｜取得期限
【００４３】
図７において、ユーザＩＤ「０１」を持つユーザ１２０（以下、このユーザ１２０をユーザ０１と表記する）のウェブページ取得要求７０１では、取得するウェブページのＵＲＬとしてｗｗｗ．ａａａ．ｃｏ．ｊｐとｗｗｗ．ｂｂｂ．ｃｏ．ｊｐとが指定されている。また、ユーザＩＤ「０２」を持つユーザ１２０（以下、このユーザ１２０をユーザ０２と表記する）のウェブページ取得要求７０２では、取得するウェブページのＵＲＬとしてｗｗｗ．ａａａ．ｃｏ．ｊｐとｗｗｗ．ｃｃｃ．ｃｏｍとが指定されている。すなわち、これらのウェブページ取得要求７０１、７０２は、ｗｗｗ．ａａａ．ｃｏ．ｊｐが重複している。これらを統合して取得リスト７０３を作成すると、図示のように、ｗｗｗ．ａａａ．ｃｏ．ｊｐのレコードにおけるユーザ名のフィールドには、ユーザ０１、０２が記述される。ここで、ｗｗｗ．ａａａ．ｃｏ．ｊｐのウェブページに関して、ユーザ０１は第１階層のみの取得を要求するが、ユーザ０２は第２階層までの取得を要求しているので、取得リスト７０３の深度のフィールドには、深い方の２階層までを取得するように記述される。また、ｗｗｗ．ａａａ．ｃｏ．ｊｐに関しては、ユーザ０１、０２のいずれも取得期限を指定していないので、ダウンロード時刻までの適当な時間に当該ウェブページソースを取得するように設定することができる。
同様にして、ｗｗｗ．ｂｂｂ．ｃｏ．ｊｐのレコードにおける各フィールドには、ウェブページ取得要求７０１から取得された情報が記述され 、ｗｗｗ．ｃｃｃ．ｃｏｍのレコードにおける各フィールドには、ウェブページ取得要求７０２から取得された情報が記述される。
【００４４】
さらに、要求受付部３１０の要求管理部３１２は、生成された取得リスト７０３から、ウェブページのＵＲＬと当該ウェブページを要求しているユーザ１２０との対応関係を示すテーブルを作成し、転送制御部３３０に渡す。
図８は、図７の取得リスト７０３から作成された対応テーブルの例を説明する図である。
図８を参照すると、取得リスト７０３において同一のレコードに記述されていたＵＲＬとユーザ名とが対応付けられている。ｗｗｗ．ａａａ．ｃｏ．ｊｐについては、ユーザ０１、０２の両方が取得を要求しているので、ＵＲＬに対応するユーザ名にユーザ０１、０２の両方が記述されている。
また、図において、ＵＲＬの後にあるアスタリスク「＊」は、当該ＵＲＬのウェブページからアスタリスクの数だけリンクを辿って得られたウェブページであることを示す。すなわち、２行目のレコードのｗｗｗ．ａａａ．ｃｏ．ｊｐ／＊ とあるのは、ｗｗｗ．ａａａ．ｃｏ．ｊｐのウェブページから１階層リンクを辿って得られたウェブページとユーザとの対応を示す。
【００４５】
図６において、次に、ウェブページ取得保存部３２０のスケジューリング部３２１が、取得リスト７０３に基づいてウェブページを取得するためのスケジュールを作成する（ステップ６０２）。スケジュールは、取得リスト７０３に対して所定のスケジューリングルールを適用することにより作成される。スケジューリングルールとしては、システムが提供するサービス内容に応じて種々のルールを採用することができる。例えば、基本的なルールとして、
１．ダウンロード時刻の早いウェブページを優先的に取得する。
２．ネットワークにおける通信量が少ない時間帯に取得処理を行う。
といったルールを設定し、さらに、ウェブサーバ２３０がダウンしていた場合は一定時間後に再度取得処理を行う、というような特殊な態様に応じたルールを組み合わせることができる。
【００４６】
図９は、図７に示した取得リストから上記スケジューリングルール１及び２に基づいて作成されたスケジュールの例を説明する図である。
図９を参照すると、作成されたスケジュール９０１は、取得するウェブページごとに、ウェブページのＵＲＬ、ウェブサーバ２３０にアクセスする時刻、取得する深さ、取得期限などの情報が記述される。図示のフォーマットによれば、これらの情報が下記のように記述されている。
ＵＲＬ｜アクセス時刻｜取得する深さ｜取得期限
【００４７】
図９のスケジュール９０１によれば、ｗｗｗ．ａａａ．ｃｏ．ｊｐのウェブページソースを１０時に、ｗｗｗ．ｃｃｃ．ｃｏｍのウェブページソースを１１時に、ｗｗｗ．ｂｂｂ．ｃｏ．ｊｐのウェブページソースを１４時にそれぞれ取得するようにスケジューリングされている。なお、ｗｗｗ．ｃｃｃ．ｃｏｍ 及びｗｗｗ．ｂｂｂ．ｃｏ．ｊｐに関しては、それぞれ取得すべき期限が指定されており、ｗｗｗ．ｃｃｃ．ｃｏｍは３月７日までに、ｗｗｗ．ｂｂｂ．ｃｏ．ｊｐは３月５日以後で３月７日までに取得する。ここで、取得リスト７０３において、ｗｗｗ．ｂｂｂ．ｃｏ．ｊｐのダウンロード時刻がｗｗｗ．ｃｃｃ．ｃｏｍのダウンロード時刻よりも早いにも関わらず、ｗｗｗ．ｃｃｃ．ｃｏｍのウェブページソースを先に取得するようにスケジューリングされているのは、ｗｗｗ．ｃｃｃ．ｃｏｍが米国のウェブサイト１３０に存在するために、米国のネットワーク回線が空いている時間帯に合わせて当該ウェブページソースを取得するためである。
【００４８】
図６において、次に、ウェブページ取得保存部３２０のウェブページ取得部３２２が、スケジューリング部３２１により作成されたスケジュール９０１にしたがって、ウェブサーバ２３０から目的のウェブページを取得する（ステップ６０３）。この際、２階層以上のウェブページを取得する場合は、リンクを１階層辿るごとに当該リンク先のウェブページのＵＲＬを新たに取得することとなる。そこで、新たに得られた当該ＵＲＬを加えて再帰的にスケジュール９０１の作成を行うことが必要である。すなわち、スケジュール９０１はウェブページの取得に伴ってダイナミックに更新される。
【００４９】
図１０は、ウェブページを取得しながら再帰的にスケジュール９０１を作成する処理を説明するフローチャートである。
図１０を参照すると、まず、スケジューリング部３２１が、要求受付部３１０にて作成された取得リスト７０３に基づいてウェブページを取得するためのスケジュール９０１を作成する（ステップ１００１）。そして、ウェブページ取得部３２２が、スケジュール９０１中に未処理のＵＲＬがあるかどうかを調べ、あるならば、当該ＵＲＬのウェブページをスケジュール９０１にしたがって取得する（ステップ１００２、１００３）。
次に、スケジュール９０１の当該ウェブページにおける取得する深さを参照して、取得したウェブページ中のリンク先のソースを取得する必要があるかどうかを調べる（ステップ１００４）。取得する必要がなければステップ１００２に戻り、取得する必要があれば、当該リンク先のＵＲＬを取得リスト７０３に追加し（ステップ１００５）、改めてスケジューリングを行ってステップ１００２に戻る（ステップ１００６）。
ステップ１００２において、スケジュール９０１中のＵＲＬを全て取得したならば、処理を終了する。
【００５０】
以上のようにして取得されたウェブページは、ウェブページ保存データベース３５０に順次格納される。ウェブページ保存データベース３５０は、仮想的な木構造を構築して取得したウェブページを保存する。この仮想的な木構造により、ウェブサーバ２３０のディレクトリ構造を再現する。
図１１は、ウェブページ保存データベース３５０の仮想的な木構造を説明する図である。同図において、ルートノード１１０１にドメイン名が記述され、子ノード１１０２〜１１０８にそれぞれウェブサーバ２３０におけるディレクトリの名前が記述される。また、各ウェブページのＨＴＭＬファイルや画像ファイルは、ウェブサーバ２３０におけるファイル構造と同じ構造となり、対応するディレクトリの下に保存される。
図１１の例では、ルートノード１１０１のｗｗｗ．ａａａ．ｃｏ．ｊｐの下に二つのディレクトリ（ノード１１０２、１１０３）と一つのファイル（ｉｎｄｅｘ．ｈｔｍｌ）とがある。ＵＲＬ形式で表すと、ｗｗｗ．ａａａ．ｃｏ．ｊｐ／ｓｅｒｖｉｃｅｓ／、ｗｗｗ．ａａａ．ｃｏ．ｊｐ／ｓｏｆｔｗａｒｅ／及びｗｗｗ．ａａａ．ｃｏ．ｊｐ／ｉｎｄｅｘ．ｈｔｍｌである。また、ノード１１０２のディレクトリｓｅｒｖｉｃｅｓの下に、さらに二つのディレクトリ（ノード１１０４、１１０５）と一つのファイル（ｉｎｄｅｘ．ｈｔｍｌ）とがある。ＵＲＬ形式で表すと、ｗｗｗ．ａａａ．ｃｏ．ｊｐ／ｓｅｒｖｉｃｅｓ／ｅ−ｂｕｓｉｎｅｓｓ／、ｗｗｗ．ａａａ．ｃｏ．ｊｐ／ｓｅｒｖｉｃｅｓ／ｉｔ−ｃｏｎｓｌ／及びｗｗｗ．ａａａ．ｃｏ．ｊｐ／ｓｅｒｖｉｃｅｓ／ｉｎｄｅｘ．ｈｔｍｌである。
【００５１】
なお、ファイルシステムの規則によって、ＵＲＬに用いられるｗｗｗ．ａａａ．ｃｏ．ｊｐのようなドメイン名はファイル名として許されないため、各ドメイン名にはユニークなＩＤを付ける。ユーザ１２０に対してウェブページソースを転送する際には、当該ＩＤを使用することができる。また、ドメイン名に付加されたＩＤと対応するドメイン名の組を対応テーブルに登録する。さらに、各ウェブページにある画像ファイル名は、重複する可能性が高いため、同様にユニークなＩＤを付して、画像フォーマットをディレクトリ名としたディレクトリの下に置く。このＩＤと画像ファイルの名前の組みも対応テーブルに登録する。
図１２に、図１１の木構造に対して作成された対応テーブルの例を示す。
【００５２】
図６において、所定のウェブページ取得要求に対応するウェブページが取得されると、次に、転送制御部３３０の通知部３３１が、当該ウェブページ取得要求を送信したユーザ１２０に対し、ウェブページを取得したことを示す通知を電子メールにて行う（ステップ６０４）。
ユーザ１２０は、ダウンロード時刻、または電子メールによるウェブページ取得の通知を確認した際に、プロバイダ１１０にアクセスしてウェブページソースのダウンロードを要求する。
【００５３】
プロバイダ１１０のウェブページ取得サーバ２１０においてユーザ１２０からのダウンロード要求を受け取ると、要求受付部３１０のプロファイル管理部３１１が、当該ユーザ１２０のプロファイルをユーザ管理データベース３４０から読み出して、当該ダウンロード要求と共に転送制御部３３０に渡す。
転送制御部３３０における動作は、ユーザプロファイルにおいて分割転送を行うように指定してある場合と指定していない場合とで異なる。以下、簡単のため、分割転送を行う指定がない場合について説明し、次に分割転送を行う指定がある場合について説明する。
【００５４】
図６において、転送制御部３３０のリンク処理部３３２が、ウェブページ保存データベース３５０から該当するウェブページソースを読み出し、リンク処理を行う（ステップ６０５）。リンク処理とは、ウェブページのリンクをＵＲＬに基づく絶対的（ｄｙｎａｍｉｃ）なリンクから、ウェブページ保存データベース３５０における当該木構造中の相対的（ｌｏｃａｌ）なリンクに付け替える処理である。当該ウェブページソースがユーザ端末２２０に送られた後、ユーザ１２０がウェブページのリンクを辿ろうとした際に、リンクが絶対的なリンクのままであると、インターネット２００を介してウェブサイト１３０にアクセスしてしまうので、ローカルな動作を維持するために上記のリンク処理を行う。
【００５５】
なお、リンク処理部３３２は、要求受付部３１０の要求管理部３１２にて作成された、ウェブページのＵＲＬと当該ウェブページを要求しているユーザ１２０との対応関係を示すテーブル（図８参照）を参照し、リンク処理の対象となったウェブページソースを要求しているユーザ１２０が他にいないか調べる。そして、当該ウェブページソースを要求しているユーザ１２０が他にいないならば、ウェブページ保存データベース３５０から当該ウェブページソースを消去し、対応テーブルから当該ウェブページソースに関するレコードを削除する。
図１３は、図８に示した対応テーブル８０１に対して、ユーザ０１の要求するウェブページソースが全てダウンロードされた対応テーブル８０１の状態を示す図である。図１３を参照すると、ｗｗｗ．ａａａ．ｃｏ．ｊｐは、ユーザ０１によってダウンロードされたものの、ユーザ０２にも要求されているので、レコードは削除されていない。したがって、当該ウェブページソースもウェブページ保存データベース３５０に残されている。そして、当該レコードのユーザＩＤが「０２」のみに変更されている。また、ユーザ０１のみが要求していたｗｗｗ．ｂｂｂ．ｃｏ．ｊｐ／ｎｅｗｓ及びｗｗｗ．ｂｂｂ．ｃｏ．ｊｐ／ｎｅｗｓ／＊ のウェブページソースについては、ユーザ０１のダウンロードが済んだので、当該レコードが対応テーブル８０１から削除される。これに伴って、当該ウェブページソース自体もウェブページ保存データベース３５０から消去される。
【００５６】
なお、ダウンロード時刻が過ぎても、ユーザ１２０からダウンロード要求がなされない場合、当該ウェブページソースの処分については種々の方法が考えられる。例えば、ユーザ１２０からのダウンロード要求があるまで保持し続けても良いし、一定期間経過後に消去しても良い。さらに、ダウンロード時刻が過ぎた時点で直ちに消去するような設定とすることもできる。これらの処分の方法については、ユーザプロファイルにて指定することができる。
【００５７】
図１４は、ｗｗｗ．ａａａ．ｃｏ．ｊｐのウェブページの第２階層までをダウンロードを要求した場合におけるリンク処理の様子を示す図である。
図１４において、ｗｗｗ．ａａａ．ｃｏ．ｊｐ／ｉｎｄｅｘ．ｈｔｍｌのウェブページ及び当該ウェブページ中に記述された二つのリンク先であるｗｗｗ．ａａａ．ｃｏ．ｊｐ／ｓｅｒｖｉｃｅｓ／ｉｎｄｅｘ．ｈｔｍｌ及びｗｗｗ．ａａａ．ｃｏ．ｊｐ／ｓｏｆｔｗａｒｅ／ｉｎｄｅｘ．ｈｔｍｌのウェブページがダウンロードされる。そこで、リンク処理部は、図１２に示した対応テーブルを参照し、ｗｗｗ．ａａａ．ｃｏ．ｊｐ／ｉｎｄｅｘ．ｈｔｍｌの中の絶対リンクを相対リンクに直す。図示の例では、”ｈｔｔｐ：／／ｗｗｗ．ａａａ．ｃｏ．ｊｐ／ｓｅｒｖｉｃｅｓ／”の記述が”ｓｉｔｅ１２／ｓｅｒｖｉｃｅｓ／ｉｎｄｅｘ．ｈｔｍｌ”に変更されている。
これに対し、ｗｗｗ．ａａａ．ｃｏ．ｊｐ／ｓｅｒｖｉｃｅｓ／ｉｎｄｅｘ．ｈｔｍｌ及びｗｗｗ．ａａａ．ｃｏ．ｊｐ／ｓｏｆｔｗａｒｅ／ｉｎｄｅｘ．ｈｔｍｌのウェブページにあるリンク先、すなわち、ｗｗｗ．ａａａ．ｃｏ．ｊｐ／ｓｅｒｖｉｃｅｓ／及びｗｗｗ．ａａａ．ｃｏ．ｊｐ／ｓｏｆｔｗａｒｅ／のディレクトリ（図１１のノード１１０２及びノード１１０３）以下のウェブページはダウンロードされないため、絶対リンクは変更されない。図示の例では、”ｈｔｔｐ：／／ｗｗｗ．ａａａ．ｃｏ．ｊｐ／ｓｅｒｖｉｃｅｓ／ｅ−ｂｕｓｉｎｅｓｓ／”及び”ｈｔｔｐ：／／ｗｗｗ．ａａａ．ｃｏ．ｊｐ／ｓｅｒｖｉｃｅｓ／ｉｔ−ｃｏｎｓｌ／”の記述がそのまま残されている。
【００５８】
以上のリンク処理により、ｗｗｗ．ａａａ．ｃｏ．ｊｐのウェブページの第２階層までをダウンロードしたユーザ端末２２０において、ｗｗｗ．ａａａ．ｃｏ．ｊｐ に相当するｓｉｔｅ１２のウェブページをブラウザにて表示し、リンク先を呼び出すと、当該ウェブページと共にダウンロードされたウェブページが表示される。すなわち、ローカルな動作となる。そしてさらに、第２階層より先のリンク先を呼び出そうとする場合に、初めてインターネット２００に接続し該当するウェブサイト１３０にアクセスすることとなる。
【００５９】
図６において、上記リンク処理が行われた後、転送制御部３３０のｆｔｐ／ｈｔｔｐ転送部３３３が、リンク処理の施されたウェブページソースをアーカイブして（書庫ファイルに変換して）ユーザ１２０へ転送する（ステップ６０６）。
図１５は、ユーザ１２０へ転送されるウェブページソースの木構造を示す図である。
図１５には、ユーザＩＤ「０１」を持つユーザ１２０が、ｗｗｗ．ａａａ．ｃｏ．ｊｐに相当するｓｉｔｅ１２を含むいくつかのウェブページソースをダウンロードする場合の木構造である。ｓｉｔｅ１２のウェブページソースに関しては、第３階層までダウンロードする。図示のように、ドメイン名をユニークなＩＤに置き換えた他は、ウェブページ保存データベース３５０に保存した時に使うディレクトリ構造をそのまま使用している。ユーザ１２０に転送されるウェブページソースは、図示の木構造におけるディレクトリの下にある全てのファイルである。
【００６０】
ユーザプロファイルにおいて、分割転送を行うことを指定されている場合は、ユーザ１２０からウェブページソースのダウンロード要求を受け取った後の動作において、分割転送の要否を確認し、必要ならば分割転送を行う。
図１６は、分割転送の指定がなされている場合の転送制御部３３０の動作を説明するフローチャートである。
図１６を参照すると、転送制御部３３０は、要求受付部３１０からユーザ１２０のダウンロード要求と当該ユーザ１２０のプロファイルとを受け取ると（ステップ１６０１）、まず、転送するウェブページソースのデータサイズが最大転送サイズを越えているかどうかを判断する（ステップ１６０２）。ウェブページソースのデータサイズが最大転送サイズを超えていなければ、図６に示した動作と同様に、リンク処理部３３２が当該ウェブページソースのリンクを付け替え、ｆｔｐ／ｈｔｔｐ転送部３３３が当該ウェブページソースをユーザ１２０に転送する（ステップ１６０３、１６０４）。
【００６１】
一方、ウェブページソースのデータサイズが最大転送サイズを超えているならば、まず、ウェブページソースを当該ユーザ端末２２０の最大転送サイズごとに分割する。この際、リンクが途切れないようにするため、できるだけ深さ方向の接続を維持するように分割する。そして、分割した各データファイルのリスト（分割ファイルリスト）を作成する（ステップ１６０５）。
この分割処理の対象は、図１５に示したようなウェブページソースの木構造であるため、分割された各データファイルは、元の木構造の部分木となっている。
【００６２】
次に、分割ファイルリスト中に未処理のデータファイルがあるかどうかを調べ（ステップ１６０６）、あるならば、当該データファイルの一つに対してリンク処理部３３２がリンク処理を行い（ステップ１６０７）、当該データファイルをアーカイブしてユーザ１２０へ転送する（ステップ１６０８）。
分割ファイルリスト中の未処理のデータファイルに対して順次ステップ１６０７、１６０８の処理を行い、分割された全てのデータファイルを転送し終えたならば、処理を終了する（ステップ１６０６）。
【００６３】
分割して転送されたファイルは、複数のデータファイルのままであっても良いし、ユーザ端末２２０に受信された後に単一のファイルにまとめられるようにしても良い。単一のファイルにまとめることとすれば、ユーザ端末２２０においてローカルなファイルとして扱う場合にも、リンクが途切れてしまうことがない。
【００６４】
以上のようにして、ユーザ１２０は、所望のウェブページを集めたデータファイルをまとめてプロバイダ１１０からダウンロードできるため、当該ウェブページを閲覧するために各ウェブサイト１３０にアクセス要求を送信する必要がない。また、この時点では、ウェブページソースのダウンロードにおいても、ユーザ端末２２０とウェブページ取得サーバ２１０との間でのみデータ転送が行われ、ウェブサーバ２３０とウェブページ取得サーバ２１０との間のデータ転送は発生しない。したがって、ユーザ１２０において、ウェブページを閲覧するための待ち時間が大幅に短縮されることとなる。
【００６５】
また、プロバイダ１１０においては、予めユーザ１２０のウェブページ取得要求を受け付けておき、ネットワーク回線の通信量が少ない時間帯にウェブページを取得するためのウェブサーバ２３０への接続を行い、かつ複数のユーザ１２０による共通のウェブページ取得要求に関しては、それらをまとめて１回のアクセスで対応することができる。したがって、プロバイダ１１０におけるサーバの負担が大幅に軽減されることとなる。
【００６６】
【発明の効果】
以上説明したように、本発明によれば、回線混雑時におけるユーザのアクセスに対して、待ち時間を短縮させると共に、プロバイダにおけるサーバの負担を軽減させるサービスを提供することができる。
【００６７】
また、本発明によればプロバイダにおいて、ユーザの要求を考慮して効率的にサイトへのアクセスを支援するシステムを提供することができる。
【図面の簡単な説明】
【図１】本実施の形態によるウェブページ取得サービスの概念を説明する図である。
【図２】本実施の形態におけるウェブページ取得サービスを実現するシステムの全体構成を示す図である。
【図３】プロバイダに設定されるウェブページ取得サーバの構成を説明する図である。
【図４】ユーザがユーザ端末から送信するユーザプロファイルのフォーマットの例を示す図である。
【図５】ユーザがユーザ端末から送信するウェブページ取得要求のフォーマットの例を示す図である。
【図６】本実施の形態におけるウェブページ取得サーバの動作を概略的に説明するフローチャートである。
【図７】二つのウェブページ取得要求を統合して重複のない取得リストを作成する例を説明する図である。
【図８】図７の取得リストから作成された対応テーブルの例を説明する図である。
【図９】図７に示した取得リストから作成されたスケジュールの例を説明する図である。
【図１０】ウェブページを取得しながら再帰的にスケジュール９０１を作成する処理を説明するフローチャートである。
【図１１】ウェブページ保存データベースの仮想的な木構造を説明する図である。
【図１２】図１１の木構造に対して作成された対応テーブルの例を示す図である。
【図１３】図８の対応テーブルにおいて、ユーザ０１の要求するウェブページソースが全てダウンロードされた状態を示す図である。
【図１４】ｗｗｗ．ａａａ．ｃｏ．ｊｐのウェブページの第２階層までをダウンロードを要求した場合におけるリンク処理の様子を示す図である。
【図１５】ユーザへ転送されるウェブページソースの木構造を示す図である。
【図１６】分割転送の指定がなされている場合の転送制御部の動作を説明するフローチャートである。
【符号の説明】
１１０…プロバイダ、１２０…ユーザ、１３０…ウェブサイト、２００…インターネット、２１０…ウェブページ取得サーバ、２２０…ユーザ端末、２３０…ウェブサーバ、３１０…要求受付部、３１１…プロファイル管理部、３１２…要求管理部、３２０…ウェブページ取得保存部、３２１…スケジューリング部、３２２…ウェブページ取得部、３３０…転送制御部、３３１…通知部、３３２…リンク処理部、３３３…ｆｔｐ／ｈｔｔｐ転送部、３４０…ユーザ管理データベース、３５０…ウェブページ保存データベース

Claims (13)

1. 通信ネットワークに接続されたウェブページ取得サーバと複数のユーザ端末とを備え、
   前記複数のユーザ端末は、
   ウェブページソースを取得するための時間的条件を指定したウェブページ取得要求を前記ウェブページ取得サーバに送信し、
   前記ウェブページ取得サーバは、
   前記複数のユーザ端末から同一のウェブページソースに対する前記ウェブページ取得要求を受信した場合に、各ウェブページ取得要求において指定された前記時間的条件を比較して、ウェブページソースを取得する動作を行う回数が少なくなるようにスケジュールを作成し、当該スケジュールにしたがって、通信ネットワーク上のウェブサーバからウェブページソースを取得して保持し、
   前記ウェブページソースを前記複数のユーザ端末に転送することを特徴とするウェブページ取得サービスシステム。
2. 前記ウェブページ取得サーバは、前記ウェブページ取得要求にて指定された前記時間的条件と前記通信ネットワークにおける通信量の多少とを考慮して前記スケジュールを作成することを特徴とする請求項１に記載のウェブページ取得サービスシステム。
3. 前記複数のユーザ端末は、
   前記ウェブページソースを取得するための取得条件を指定した前記ウェブページ取得要求を前記ウェブページ取得サーバに送信し、
   前記ウェブページ取得サーバは、
   前記複数のユーザ端末から受信した前記ウェブページ取得要求の取得条件にしたがって、通信ネットワーク上のウェブサーバからウェブページソースを取得することを特徴とする請求項１に記載のウェブページ取得サービスシステム。
4. 前記複数のユーザ端末は、
   前記ウェブページ取得要求の取得条件として、前記ウェブページソースを取得する期限を指定し、
   前記ウェブページ取得サーバは、
   前記ウェブページ取得要求にて指定された前記取得期限の間に前記ウェブページソースを取得することを特徴とする請求項３に記載のウェブページ取得サービスシステム。
5. 前記複数のユーザ端末は、
   前記ウェブページ取得要求の取得条件として、ウェブページの階層を指定し、
   前記ウェブページ取得サーバは、
   前記ウェブページ取得要求にて指定された前記ウェブページの階層における前記ウェブページソースを取得することを特徴とする請求項３に記載のウェブページ取得サービスシステム。
6. インターネットへの接続サービスを提供するプロバイダにおけるサーバであって、
   ウェブページソースを取得するための時間的条件を指定したウェブページ取得要求を複数のユーザから受け付ける要求受付部と、
   前記要求受付部にて前記複数のユーザからの同一のウェブページソースに対する前記ウェブページ取得要求を受け付けた場合に、各ウェブページ取得要求において指定された前記時間的条件を比較して、ウェブページソースを取得する動作を行う回数が少なくなるようにスケジュールを作成し、当該スケジュールにしたがって、通信ネットワーク上のウェブサーバからウェブページソースを取得して保持するウェブページ取得保存部と、
   前記ウェブページ取得保存部にて取得した前記ウェブページソースを前記複数のユーザに転送する転送制御部とを備えることを特徴とするサーバ。
7. 前記転送制御部は、前記ウェブページ取得要求に従って前記ウェブページ取得保存部により取得され保持されている前記ウェブページソースを、書庫ファイルにまとめて転送することを特徴とする請求項６に記載のサーバ。
8. 前記転送制御部は、前記ウェブページソースの転送先であるユーザの端末装置において一度に受信できるデータファイルのサイズが限られている場合に、前記ウェブページ取得保存部に保持されている前記ウェブページソースを当該端末装置が受信可能なサイズに分割した上で、各々書庫ファイルにまとめることを特徴とする請求項７に記載のサーバ。
9. 前記転送制御部は、前記ウェブページ取得保存部に保持されている前記ウェブページソースのリンクを、個々のウェブページソースのＵＲＬに基づく絶対的なリンクから、相対的なリンクに置き換えた上で転送することを特徴とする請求項６に記載のサーバ。
10. 通信ネットワーク上に設けられたウェブページ取得サーバによるウェブページ取得方法において、
    ウェブページソースを取得するための時間的条件を指定したウェブページ取得要求を複数のユーザから受け付けるステップと、
    前記複数のユーザから同一のウェブページソースに対する前記ウェブページ取得要求を受け付けた場合に、各ウェブページ取得要求において指定された前記時間的条件を比較して、ウェブページソースを取得する動作を行う回数が少なくなるようにスケジュールを作成するステップと、
    作成されたスケジュールにしたがって、通信ネットワーク上のウェブサーバからウェブページソースを取得して保持するステップと、
    前記ウェブページソースを前記複数のユーザに転送するステップとを含むことを特徴とするウェブページ取得方法。
11. 前記スケジュールを作成するステップは、
    前記ウェブページ取得要求にて指定された前記時間的条件に従い、かつ通信ネットワークにおける通信量の多少に応じて、ウェブページ取得サーバ自身の負荷が少なくなるように、当該ウェブページ取得要求にて要求されるウェブページソースを取得する時間を決定するステップを含むことを特徴とする請求項１０に記載のウェブページ取得方法。
12. コンピュータに実行させるプログラムを当該コンピュータの入力手段が読取可能に記憶した記憶媒体において、
    前記プログラムは、
    ウェブページソースを取得するための時間的条件を指定したウェブページ取得要求を複数のユーザから受け付ける処理と、
    前記複数のユーザから同一のウェブページソースに対する前記ウェブページ取得要求を受け付けた場合に、各ウェブページ取得要求において指定された前記時間的条件を比較して、ウェブページソースを取得する動作を行う回数が少なくなるようにスケジュールを作成する処理と、
    作成されたスケジュールにしたがって、通信ネットワーク上のウェブサーバからウェブページソースを取得して保持する処理と、
    前記ウェブページソースを前記複数のユーザに転送する処理とを前記コンピュータに実行させることを特徴とする記憶媒体。
13. コンピュータに、ウェブページソースを取得するための時間的条件を指定したウェブページ取得要求を複数のユーザから受け付ける処理と、前記複数のユーザから同一のウェブページソースに対する前記ウェブページ取得要求を受け付けた場合に、各ウェブページ取得要求において指定された前記時間的条件を比較して、ウェブページソースを取得する動作を行う回数が少なくなるようにスケジュールを作成する処理と、作成されたスケジュールにしたがって、通信ネットワーク上のウェブサーバからウェブページソースを取得して保持する処理と、前記ウェブページソースを前記複数のユーザに転送する処理とを実行させるプログラムを記憶する記憶手段と、
    前記記憶手段から前記プログラムを読み出して当該プログラムを送信する送信手段とを備えたことを特徴とするプログラム伝送装置。

Images