(57)【要約】【課題】定期更新サーバにおいて、ＵＲＬで指定されるデータを定期更新処理の対象とするか否かを判定する。【解決手段】ＵＲＬリスト記憶部１１２には、ネットワーク上のデータを指定する複数のＵＲＬと、各ＵＲＬが定期更新処理の対象であるか否かを表す定期更新フラグとが関連づけて記憶されている。更新実行部１０６は、定期更新フラグがＯＮであるＵＲＬで指定されるデータを、ネットワークを介して定期的に取得し、データ記憶部１０４に記憶させる。要求応答部１０２は、ユーザ端末３０から発信された少なくとも一つのＵＲＬを含むデータ送信要求に応じて、データ記憶部１０４からＵＲＬに対応するデータを検索して送信する。定期更新判定部１１６は、ＵＲＬリスト記憶部１１２内にパラメータ部を除いたアドレス部が同一であるＵＲＬが所定のしきい値以上存在する場合、アドレス部が同一である全てのＵＲＬの定期更新フラグをＯＦＦに設定する。【選択図】図２
2012185738.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク上のデータを指定する複数のＵＲＬと、各ＵＲＬが定期更新処理の対象であるか否かを表す定期更新フラグとが関連づけられて保持されるＵＲＬリスト記憶部と、
前記定期更新フラグがＯＮであるＵＲＬで指定されるデータを、ネットワークを介して定期的に取得する更新実行部と、
前記更新実行部により取得されたデータが保持されるデータ記憶部と、
ユーザ端末から発信された少なくとも一つのＵＲＬを含むデータ送信要求に応じて、前記データ記憶部から前記ＵＲＬに対応するデータを検索して前記ユーザ端末に送信する要求応答部と、
前記ＵＲＬリスト記憶部内にパラメータ部を除いたアドレス部が同一であるＵＲＬが所定のしきい値以上存在する場合、前記アドレス部が同一である全てのＵＲＬの定期更新フラグをＯＦＦに設定する定期更新判定部と、
を備えることを特徴とするデータ更新装置。
【請求項２】
前記少なくとも一つのＵＲＬを含むデータ送信要求を発信したユーザ端末を特定する情報と、該データ送信要求を前記要求応答部が受信した日時を特定する情報とを含む履歴情報がＵＲＬに関連づけて保持される履歴情報記憶部と、
前記ＵＲＬリスト記憶部から定期更新フラグがＯＦＦであるＵＲＬを取得し、取得したＵＲＬに関連づけられた履歴情報を前記履歴情報記憶部から取得し、前記取得したＵＲＬを含むデータ送信要求がなされた回数または前記取得したＵＲＬを含むデータ送信要求を発信したユーザ端末数をカウントし、データ送信要求回数またはユーザ端末数が所定のしきい値以上である場合、前記取得したＵＲＬの定期更新フラグをＯＮに設定する再判定部と、
をさらに備えることを特徴とする請求項１に記載のデータ更新装置。
【請求項３】
前記ＵＲＬリスト記憶部に保持されている各ＵＲＬのパラメータ部に複数の変数名が含まれる場合、該複数の変数名を特定の順序で並び替えたパラメータ部に書き換えるソート部をさらに備えることを特徴とする請求項１または２に記載のデータ更新装置。
【請求項４】
ユーザ端末からの要求に応じてＵＲＬで指定されるデータを送信するデータ更新装置において、該データ更新装置が、
複数のＵＲＬと、各ＵＲＬが定期更新処理の対象であるか否かを表す定期更新フラグとを関連づけてメモリに格納し、
前記定期更新フラグがＯＮであるＵＲＬで指定されるデータを、ネットワークを介して定期的に取得し、
取得されたデータをメモリに格納し、
ユーザ端末から発信された少なくとも一つのＵＲＬを含むデータ送信要求に応じて、前記メモリから前記ＵＲＬに対応するデータを検索して前記ユーザ端末に送信し、
前記メモリ内にパラメータ部を除いたアドレス部が同一であるＵＲＬが所定のしきい値以上存在する場合、前記アドレス部が同一である全てのＵＲＬの定期更新フラグをＯＦＦに設定することを含むデータ更新方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ウェブサーバから定期的にデータを取得するデータ更新技術に関する。
【背景技術】
【０００２】
ネットワークを介してウェブサーバから定期的にデータを取得して保存しておき、ユーザ端末からの要求に応じてデータを送信する定期更新サーバが知られている。一般に、ユーザ端末からのデータ送信要求には、ネットワーク上のデータを指定するＵＲＬ（Uniform Resource Locator）が含まれている。定期更新サーバは、ユーザ端末からデータ送信要求を受信する毎にそれに含まれているＵＲＬをリストに登録しておく。そして、リスト内のＵＲＬで指定されるデータを定期的に取得してデータを更新する定期更新処理を実行する。このような構成により、既に定期更新サーバに登録済みのＵＲＬについては、ユーザ端末が直接ウェブサーバにアクセスすることなく、定期更新サーバからデータを取得することが可能になる。
【０００３】
定期更新サーバ内に記憶されている定期更新対象のＵＲＬが増加するにつれて、定期更新処理の負荷や所要時間も増加してしまうという問題がある。この問題を解決するために、例えば特許文献１には、ウェブサーバデータの更新時刻またはデータサイズ等の更新監視データをサーバ上で管理し、サーバで保持している更新監視データとウェブサーバで保持されている更新監視データに相当するデータとが一致しなくなった場合に、データ更新が必要であると判断するようにしたデータ更新装置が開示されている。これにより、更新監視データが一致する場合にはデータ更新が行われないので、無駄な更新処理を排除することができる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平１０−９１５０８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、ＨＴＴＰ（HyperText Transfer Protocol）プロトコルでは、ＵＲＬにパラメータを付加することが可能である。このパラメータを利用することで、ウェブサーバ上で動作するＣＧＩ（Common Gateway Interface）プログラムなどに引数を受け渡すことが可能になる。パラメータは、地図サイトでの緯度および経度の指定、データベースに対するクエリ、ニュースサイトでのカテゴリの指定などに利用されている。
【０００６】
上述したようなユーザ端末とデータ更新装置の組み合わせにおいて、ユーザ端末で例えば地図サイトを利用する場合、ユーザ端末からは緯度または経度のみが異なる多数のデータ送信要求がデータ更新装置に対して発信される。このため、データ更新装置には、地図サイトを特定するアドレスは同一であるが、パラメータ内の緯度または経度のみが異なる多数のＵＲＬが定期更新処理の対象として記憶されることになる。この場合、ＵＲＬのパラメータ内の緯度および経度が一致するようなデータ送信要求がなされる頻度は非常に少ない。したがって、パラメータのみが異なるようなＵＲＬは、処理負荷および処理時間の観点から定期更新処理の対象とすべきではない。
【０００７】
本発明はこうした状況に鑑みてなされたものであり、その目的は、登録されているＵＲＬで指定されたデータをウェブサーバから定期的に取得するデータ更新装置において、各ＵＲＬの定期更新処理の必要性を判定するための技術を提供することにある。
【課題を解決するための手段】
【０００８】
本発明の一態様は、ネットワーク上のデータを指定する複数のＵＲＬと、各ＵＲＬが定期更新処理の対象であるか否かを表す定期更新フラグとが関連づけて保持されるＵＲＬリスト記憶部と、前記定期更新フラグがＯＮであるＵＲＬで指定されるデータを、ネットワークを介して定期的に取得する更新実行部と、前記更新実行部により取得されたデータが保持されるデータ記憶部と、ユーザ端末から発信された少なくとも一つのＵＲＬを含むデータ送信要求に応じて、前記データ記憶部から前記ＵＲＬに対応するデータを検索して前記ユーザ端末に送信する要求応答部と、前記ＵＲＬリスト記憶部内にパラメータ部を除いたアドレス部が同一であるＵＲＬが所定のしきい値以上存在する場合、前記アドレス部が同一である全てのＵＲＬの定期更新フラグをＯＦＦに設定する定期更新判定部と、を備える。
【０００９】
この態様によると、ＵＲＬリスト内でパラメータ部を除くアドレス部が同一であるＵＲＬの数がしきい値以上である場合、これらのＵＲＬが定期更新処理の対象外とされるので、定期更新の処理負荷および処理時間が軽減される。
【００１０】
前記少なくとも一つのＵＲＬを含むデータ送信要求を発信したユーザ端末を特定する情報と、該データ送信要求を前記要求応答部が受信した日時を特定する情報とを含む履歴情報がＵＲＬに関連づけて保持される履歴情報記憶部と、前記ＵＲＬリスト記憶部から定期更新フラグがＯＦＦであるＵＲＬを取得し、取得したＵＲＬに関連づけられた履歴情報を前記履歴情報記憶部から取得し、前記取得したＵＲＬを含むデータ送信要求がなされた回数または前記取得したＵＲＬを含むデータ送信要求を発信したユーザ端末数をカウントし、データ送信要求回数またはユーザ端末数が所定のしきい値以上である場合、前記取得したＵＲＬの定期更新フラグをＯＮに設定する再判定部と、をさらに備えてもよい。
【００１１】
これによると、一旦定期更新処理の対象外とされたＵＲＬに対して、データ送信要求回数またはユーザ端末数がしきい値以上であるものについては定期更新処理の対象に再設定することで、データ更新装置からウェブサーバへのアクセス頻度を低減できる。
【００１２】
前記ＵＲＬリスト記憶部に保持されている各ＵＲＬのパラメータ部に複数の変数名が含まれる場合、該複数の変数名を特定の順序で並び替えたパラメータ部に書き換えるソート部をさらに備えてもよい。これによると、パラメータ内の変数名の記載順序のみが異なるＵＲＬが、別レコードとしてＵＲＬリスト記憶部に保持されることがなくなる。
【００１３】
本発明の別の態様は、ユーザ端末からの要求に応じてＵＲＬで指定されるデータを送信するデータ更新装置において、該データ更新装置が、複数のＵＲＬと、各ＵＲＬが定期更新処理の対象であるか否かを表す定期更新フラグとを関連づけてメモリに格納し、前記定期更新フラグがＯＮであるＵＲＬで指定されるデータを、ネットワークを介して定期的に取得し、取得されたデータをメモリに格納し、ユーザ端末から発信された少なくとも一つのＵＲＬを含むデータ送信要求に応じて、前記メモリから前記ＵＲＬに対応するデータを検索して前記ユーザ端末に送信し、前記メモリ内にパラメータ部を除いたアドレス部が同一であるＵＲＬが所定のしきい値以上存在する場合、前記アドレス部が同一である全てのＵＲＬの定期更新フラグをＯＦＦに設定することを含むデータ更新方法である。
【００１４】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１５】
本発明によれば、登録されているＵＲＬで指定されたデータをウェブサーバから定期的に取得するデータ更新装置において、各ＵＲＬの定期更新処理の必要性を判定することができる。
【図面の簡単な説明】
【００１６】
【図１】本発明の一実施形態に係る定期更新サーバを含むシステム全体の概略図である。
【図２】定期更新サーバの構成を示すブロック図である。
【図３】ＵＲＬリスト記憶部に保持されているＵＲＬリストの一例を示す図である。
【図４】履歴情報記憶部に保持されている履歴情報の一例を示す図である。
【図５】定期更新判定部による定期更新の必要性を判定する処理のフローチャートである。
【図６】再判定部による、定期更新処理の対象外となったＵＲＬのうち利用頻度の高いＵＲＬを定期更新処理の対象に戻す処理のフローチャートである。
【発明を実施するための形態】
【００１７】
図１は、本発明の一実施形態に係る定期更新サーバ１００を含むシステム全体の概略図である。定期更新サーバ１００は、インターネットまたはＬＡＮ（Local Area Network）等のネットワーク１２を介して、複数のウェブサーバ２０と接続されている。また、ユーザ端末３０は、内蔵のブラウザを用いて、同様のネットワーク１４を介して定期更新サーバ１００にアクセス可能に構成される。ユーザ端末３０は、携帯電話または車載端末などの移動端末であってもよいし、パーソナルコンピュータなどの固定端末であってもよい。
【００１８】
定期更新サーバ１００は、ユーザ端末から以前に要求されたことのあるＵＲＬを記憶しており、これらのＵＲＬについては、ウェブサーバ２０に所定の周期でアクセスしＵＲＬで指定されるデータを取得して、所定の記憶領域に保持している。このため、記憶されているＵＲＬを含むデータ送信要求がユーザ端末３０から定期更新サーバ１００に対して発信された場合、定期更新サーバ１００は、ウェブサーバ２０にアクセスすることなく、そのＵＲＬに対応するデータを記憶領域から検索して、ユーザ端末３０に送信することができる。
【００１９】
図１の構成において、車載端末であるユーザ端末３０からの要求に対して交通情報データを提供するサイトをウェブサーバ２０が構成する場合を考える。ウェブサーバ２０は、例えば"http://aaa/aaa?altitude=39.190321&longtitude=135.025201"のような、車両が走行中の緯度および経度情報を表したＧＥＴメソッドパラメータが付加されたＵＲＬを受け取ると、その緯度および経度付近の交通情報データを出力するように構成されているとする。
【００２０】
一般に、交通情報データの更新頻度は高いので、定期更新サーバ１００は比較的高い頻度でウェブサーバ２０から交通情報データを取得して保持データを更新する必要がある。また、ユーザ端末３０からは緯度または経度のみが異なる多数のデータ送信要求が定期更新サーバ１００に対して発信される。このため、定期更新サーバ１００には、ウェブサーバ２０を特定するアドレスは同一であるが、パラメータ内の緯度または経度のみが異なる多数のＵＲＬが定期更新処理の対象として記憶されることになる。この場合、ＵＲＬのパラメータ内の緯度および経度が一致するようなデータ送信要求がなされる頻度は非常に少ない。
【００２１】
したがって、ＵＲＬのアドレス部は同一であるがパラメータ部が異なるようなＵＲＬについては、処理負荷および処理時間の観点から定期更新処理の対象とすべきではない。本実施形態では、上記のようなＵＲＬを定期更新処理の対象から外すための技術を提供する。
【００２２】
図２は、本実施形態に係る定期更新サーバ１００の構成を示すブロック図である。この構成は、ハードウエア的には、任意のコンピュータのＣＰＵ、メモリ、その他のＬＳＩで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【００２３】
要求応答部１０２は、ユーザ端末３０から発信される、少なくとも一つのＵＲＬを含むデータ送信要求を受け取り、これに含まれるＵＲＬに対応するデータがデータ記憶部１０４に記憶されているか確認する。データ記憶部１０４に含まれていれば、そのデータを読み出してユーザ端末３０に送信する。
【００２４】
データ記憶部１０４に対応するデータがない場合、要求応答部１０２はサーバ通信部１０８にそのＵＲＬを渡し、サーバ通信部１０８はそのＵＲＬで特定されるウェブサーバ２０にアクセスして対応するデータを取得する。取得されたデータはデータ記憶部１０４に記憶されるとともに、要求応答部１０２によってデータ送信要求を発信したユーザ端末３０に送られる。
【００２５】
更新実行部１０６は、ユーザ端末３０からのデータ送信要求に含まれるＵＲＬをＵＲＬリスト記憶部１１２に保持させる。また、ユーザ端末３０から要求応答部１０２に対してデータ送信要求がなされる毎に、履歴情報記憶部１１４内の履歴情報を更新する。履歴情報の詳細については後述する。
【００２６】
図３は、ＵＲＬリスト記憶部１１２に記憶されているＵＲＬリスト７０の一例を示す図である。図示するように、ＵＲＬリスト７０は、ユーザ端末３０からのデータ送信要求に含まれるＵＲＬ７２と、各ＵＲＬが定期更新の対象であるか否かをそれぞれＯＮ、ＯＦＦで表す定期更新フラグ７４と、後述する履歴情報記憶部１１４内の対応する履歴情報を特定する履歴ＩＤ７６を一つのレコードとするリストである。なお、本実施形態では、同一のＵＲＬに対してレコードは一つのみであるとする。
【００２７】
図４は、履歴情報記憶部１１４に記憶されている履歴情報８０の一例を示す図である。履歴情報８０は、ユーザ端末３０から定期更新サーバ１００に対してなされたデータ送信要求の記録であり、ＵＲＬ毎に一つの履歴情報が作られる。図示するように、履歴情報８０には、履歴ＩＤ＝ＩＤ１に関連するＵＲＬ（図３の「http://AAA/aaa」）が要求された日時、すなわち要求応答部１０２がデータ送信要求を受信した日時８２と、その要求を発信したユーザ端末の識別情報であるＭＡＣアドレス８４とが含まれる。識別情報として、ＭＡＣアドレスの代わりに、定期更新サーバ１００へのログイン名、各ユーザ端末のＩＰアドレス等を使用してもよい。
【００２８】
図２に戻り、ソート部１１０は、ＵＲＬリスト記憶部１１２内のＵＲＬを随時アルファベット順にソートする。
【００２９】
更新実行部１０６は、所定の間隔でＵＲＬリスト記憶部１１２内のＵＲＬリストを参照し、定期更新フラグがＯＮであるＵＲＬを取り出して、サーバ通信部１０８に送る。サーバ通信部１０８は、送られたＵＲＬを使用してウェブサーバ２０から対応するデータを取り出し、データ記憶部１０４内のデータを更新する。これによって、定期更新フラグがＯＮであるＵＲＬについては、定期更新サーバ１００によって所定の間隔でデータが更新されるので、各ユーザ端末３０は、既にＵＲＬリスト記憶部１１２に記憶されているＵＲＬについては、最新のデータを迅速に取得することができる。
【００３０】
定期更新判定部１１６は、ＵＲＬリスト記憶部１１２に記憶されているＵＲＬのうちパラメータ部のみが異なるＵＲＬ群については、定期更新が不要であると判定して、それらの定期更新フラグをＯＦＦにセットする。これについては、図５を参照して後述する。
【００３１】
再判定部１１８は、ＵＲＬリスト記憶部１１２に記憶されているＵＲＬのうち定期更新フラグがＯＮであるＵＲＬに関連する履歴情報を参照する。そして、所定回数以上データ更新要求が発行されているＵＲＬ、または所定数以上のユーザ端末からデータ更新要求が発行されているＵＲＬについて、定期更新フラグをＯＮにセットする。これについては、図６を参照して後述する。
【００３２】
図５は、定期更新判定部１１６による定期更新の必要性を判定する処理のフローチャートである。定期更新判定部１１６は、所定の間隔または所定のタイミングで、例えば更新実行部１０６によるＵＲＬ定期更新処理が完了した直後にこの処理を実行する。
【００３３】
以下の説明では、ｉ＝１を初期値として、ＵＲＬリスト７０内のアルファベット順にソートされたＵＲＬ７２を先頭から順にＵＲＬ(ｉ)（但し、ｉ＝０〜Ｎ）と表記する。なお、ＮはＵＲＬリスト７０に含まれる全ＵＲＬ数を表す。
【００３４】
定期更新判定部１１６は、ｉがＮ未満であるか否かを判定する（Ｓ１０）。ｉ＝Ｎ、すなわちＵＲＬリストの最後まで達している場合（Ｓ１０のＮ）、このフローを終了する。ｉ＜Ｎの場合（Ｓ１０のＹ）、定期更新判定部１１６は、ＵＲＬリスト記憶部１１２からＵＲＬ(ｉ)を取得し（Ｓ１２）、これにパラメータ部が含まれるか否かを判定する（Ｓ１４）。ここで、「パラメータ部」とは、例えばＨＴＴＰプロトコルにおけるＧＥＴパラメータのことを指す。一例として、ＵＲＬ(ｉ)が"http://ccc/ccc?p1=v1&p2=v2"である場合、記号?に後続する文字列「p1=v1&p2=v2」のことを以下では「パラメータ部」と称し、記号?の前の"http://ccc/ccc"のような部分を「アドレス部」と称する。
【００３５】
ＵＲＬ(ｉ)がパラメータ部を含まない場合（Ｓ１４のＮ）、ｉを１だけインクリメントして（Ｓ３０）、Ｓ１０に戻る。ＵＲＬ(ｉ)がパラメータ部を含む場合（Ｓ１４のＹ）、定期更新判定部１１６は、ＵＲＬ(ｉ)からパラメータ部を取り除いたアドレス部ＵＲＬａ(ｉ)を一時的に記憶する（Ｓ１６）。このとき、ｊ＝ｉ＋１をセットし、またカウンタＣＮＴをリセットする。
【００３６】
定期更新判定部１１６は、ｊがＮ以下であるかを判定する（Ｓ１８）。ｊがＮより大きい場合（Ｓ１８のＮ）、Ｓ２６に進む。ｊがＮ以下である場合（Ｓ１８のＹ）、定期更新判定部１１６は、ＵＲＬリスト記憶部１１２からＵＲＬ(ｊ)を取得し、これからパラメータ部を取り除いたアドレス部ＵＲＬａ(ｊ)を一時的に記憶する（Ｓ２０）。
【００３７】
続いて、定期更新判定部１１６は、このＵＲＬａ(ｊ)と、ステップ１６で取得したＵＲＬａ(ｉ)とを比較する（Ｓ２２）。両者が一致する場合（Ｓ２２のＹ）、カウンタＣＮＴおよびｊをそれぞれ１だけインクリメントして（Ｓ２４）、Ｓ１８に戻る。Ｓ２２において両者が一致しない場合、Ｓ２６に進む。
【００３８】
Ｓ１８〜Ｓ２４の一連の処理は、ＵＲＬリストのｉ番目であるＵＲＬとアドレス部が同一でありパラメータ部が異なる他のＵＲＬの個数をカウントすることを示している。ＵＲＬリストは予めアルファベット順にソートされているので、この処理によってアドレス部が重複するＵＲＬの個数をカウントすることができる。
【００３９】
Ｓ１８〜Ｓ２４のループの間に、ＵＲＬａ(ｉ)とＵＲＬａ(ｊ)とが一致しなくなるか（Ｓ２２のＮ）、またはＵＲＬリストの最後であるＵＲＬａ(Ｎ)との比較が終わる（すなわちｊ＞Ｎ＋１）と（Ｓ１８のＮ）、定期更新判定部１１６は、カウンタＣＮＴと予め定められたしきい値ＭＩＮ＿ＣＮＴとを比較する（Ｓ２６）。
【００４０】
カウンタＣＮＴがしきい値以下である場合（Ｓ２６のＮ）、Ｓ３２に進む。カウンタＣＮＴがしきい値未満である場合（Ｓ２６のＹ）、ＵＲＬ(ｉ)とアドレス部が共通する全てのＵＲＬ、すなわちＵＲＬ(ｉ)〜ＵＲＬ(ｉ＋ＣＮＴ)の定期更新フラグをＯＦＦに設定する（Ｓ２８）。なお、しきい値ＭＩＮ＿ＣＮＴには、アドレス部が重複するＵＲＬが複数あってもデータ更新処理に影響を及ぼさない上限の数を経験または実験等に基づき設定する。
【００４１】
Ｓ２２までの処理によって、ＵＲＬ(ｉ)とＵＲＬ(ｊ)のアドレス部は異なることが分かっているので、ｉ＝ｊをセットして（Ｓ３２）、Ｓ１０から同様の処理を繰り返す。
【００４２】
このようにして、パラメータ部のみが異なりアドレス部が重複している複数のＵＲＬを定期更新処理の対象外に設定することができる。
【００４３】
図６は、再判定部１１８による、定期更新処理の対象外となったＵＲＬのうち利用頻度の高いＵＲＬを定期更新処理の対象に戻す処理のフローチャートである。
【００４４】
再判定部１１８は、この処理を所定の間隔または所定のタイミングで実行する。例えば、定期更新処理の対象外であるＵＲＬに対するデータ送信要求をユーザ端末から受信し、対応するＵＲＬのデータをウェブサーバ２０から取得してユーザ端末に送信した直後に行われる。以下の説明では、データ送信要求がなされた、定期更新処理の対象外であるＵＲＬを「指定ＵＲＬ」と呼ぶ。
【００４５】
再判定部１１８は、履歴情報記憶部１１４から指定ＵＲＬに関連づけられた履歴情報を取得する（Ｓ４２）。再判定部１１８は、取得した履歴情報のうち日時情報を参照して、定期更新サーバ１００に対して一定の期間内になされたデータ送信要求回数をカウントし、所定のしきい値ＭＩＮ１とを比較する（Ｓ４４）。データ送信要求回数がしきい値以下の場合（Ｓ４４のＮ）、指定ＵＲＬのニーズが低いと考えられるので、定期更新フラグをＯＦＦのままにする。
【００４６】
データ送信要求回数がしきい値より大きい場合（Ｓ４４のＹ）、再判定部１１８は、履歴情報のうち端末識別情報の異同に基づき、定期更新サーバ１００が一定期間内に受信したデータ送信要求の発信元のユーザ端末数をカウントし、このユーザ端末数と所定のしきい値ＭＩＮ２とを比較する（Ｓ４６）。ユーザ端末数がしきい値以下の場合（Ｓ４６のＮ）、指定ＵＲＬのニーズが低いと考えられるので、定期更新フラグをＯＦＦのままにする。ユーザ端末数がしきい値より多い場合（Ｓ４６のＹ）、指定ＵＲＬのニーズが高いと考えられるので、再判定部１１８は指定ＵＲＬの定期更新フラグをＯＮに設定する（Ｓ４８）。
【００４７】
なお、しきい値ＭＩＮ１およびＭＩＮ２は、定期更新対象とされていないＵＲＬに対するデータ送信要求が行われても定期更新サーバの負荷に影響を及ぼさない上限の数を、経験または実験等に基づきそれぞれ設定する。また、Ｓ４４とＳ４６の判定は、いずれか一方のみを行ってもよい。
【００４８】
このようにして、定期更新処理の対象から外れたＵＲＬを、必要に応じて再度定期更新処理の対象に戻すことが可能になる。
【００４９】
例えば、ウェブサーバ２０がニュースを提供するサイトを構成する場合、ユーザ端末３０からは、"http://bbb/bbb?category=sports"のように、ニュースのカテゴリを指定するパラメータが付加されたＵＲＬを含むデータ送信要求が多数発信される。このようなニュースデータの場合は、上述したような交通情報データとは異なり、パラメータ部が同一であるＵＲＬのデータ送信要求もかなりの数となることが考えられる。図６で説明した再判定部１１８の処理によって、このような要求頻度の高いＵＲＬについては、パラメータ部が異なるがアドレス部が同一であるＵＲＬが多数存在しても、定期更新処理の対象に戻すことができる。
【００５０】
ここで、あるユーザ端末から"http://ccc/ccc?p1=v1&p2=v2"のようなＵＲＬを含むデータ送信要求が発信され、別のユーザ端末から"http://ccc/ccc?p2=v2&p1=v1"のようなＵＲＬを含むデータ送信要求が発信された場合を考える。二つのＵＲＬは、変数名p1とp2の記載順序が逆であるが、実質的に同一のデータを要求している。しかしながら、上記の構成では、この二つのＵＲＬが別のレコードとしてＵＲＬリスト記憶部１１２に登録されてしまうという問題がある。
【００５１】
そこで、複数の変数名がパラメータ部に含まれる新たなＵＲＬをＵＲＬリスト記憶部１１２に追加する場合、ソート部１１０は、パラメータ部内の複数の変数名を特定の順序、例えばアルファベット順、ＡＳＣＩＩコード順等で並び替えたＵＲＬに書き換えるようにしてもよい。こうすることで、ＵＲＬリスト記憶部１１２内に、実質的に同内容であるＵＲＬが複数のレコードとして記憶されることがなくなる。
【００５２】
以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【符号の説明】
【００５３】
２０  ウェブサーバ、  ３０  ユーザ端末、  ７０  ＵＲＬリスト、  ７２  ＵＲＬ、  ７４  定期更新フラグ、  ７６  履歴ＩＤ、  ８０  履歴情報、  ８４  ＭＡＣアドレス、  １００  定期更新サーバ、  １０２  要求応答部、  １０４  データ記憶部、  １０６  更新実行部、  １０８  サーバ通信部、  １１０  ソート部、  １１２  ＵＲＬリスト記憶部、  １１４  履歴情報記憶部、  １１６  定期更新判定部、  １１８  再判定部。
【図１】
2012185738.tif 000003
【図２】
2012185738.tif 000004
【図３】
2012185738.tif 000005
【図４】
2012185738.tif 000006
【図５】
2012185738.tif 000007
【図６】
2012185738.tif 000008