ネットワーク上のデータを指定する複数のURLと、各URLが定期更新処理の対象であるか否かを表す定期更新フラグとが関連づけられて保持されるURLリスト記憶部と、前記定期更新フラグがONであるURLで指定されるデータを、ネットワークを介して定期的に取得する更新実行部と、前記更新実行部により取得されたデータが保持されるデータ記憶部と、ユーザ端末から発信された少なくとも一つのURLを含むデータ送信要求に応じて、前記データ記憶部から前記URLに対応するデータを検索して前記ユーザ端末に送信する要求応答部と、前記URLリスト記憶部内にパラメータ部を除いたアドレス部が同一であるURLが所定のしきい値以上存在する場合、前記アドレス部が同一である全てのURLの定期更新フラグをOFFに設定する定期更新判定部と、を備えることを特徴とするデータ更新装置。前記少なくとも一つのURLを含むデータ送信要求を発信したユーザ端末を特定する情報と、該データ送信要求を前記要求応答部が受信した日時を特定する情報とを含む履歴情報がURLに関連づけて保持される履歴情報記憶部と、前記URLリスト記憶部から定期更新フラグがOFFであるURLを取得し、取得したURLに関連づけられた履歴情報を前記履歴情報記憶部から取得し、前記取得したURLを含むデータ送信要求がなされた回数または前記取得したURLを含むデータ送信要求を発信したユーザ端末数をカウントし、データ送信要求回数またはユーザ端末数が所定のしきい値以上である場合、前記取得したURLの定期更新フラグをONに設定する再判定部と、をさらに備えることを特徴とする請求項1に記載のデータ更新装置。前記URLリスト記憶部に保持されている各URLのパラメータ部に複数の変数名が含まれる場合、該複数の変数名を特定の順序で並び替えたパラメータ部に書き換えるソート部をさらに備えることを特徴とする請求項1または2に記載のデータ更新装置。ユーザ端末からの要求に応じてURLで指定されるデータを送信するデータ更新装置において、該データ更新装置が、複数のURLと、各URLが定期更新処理の対象であるか否かを表す定期更新フラグとを関連づけてメモリに格納し、前記定期更新フラグがONであるURLで指定されるデータを、ネットワークを介して定期的に取得し、取得されたデータをメモリに格納し、ユーザ端末から発信された少なくとも一つのURLを含むデータ送信要求に応じて、前記メモリから前記URLに対応するデータを検索して前記ユーザ端末に送信し、前記メモリ内にパラメータ部を除いたアドレス部が同一であるURLが所定のしきい値以上存在する場合、前記アドレス部が同一である全てのURLの定期更新フラグをOFFに設定することを含むデータ更新方法。ところで、HTTPHyperTextTransferProtocolプロトコルでは、URLにパラメータを付加することが可能である。このパラメータを利用することで、ウェブサーバ上で動作するCGICommonGatewayInterfaceプログラムなどに引数を受け渡すことが可能になる。パラメータは、地図サイトでの緯度および経度の指定、データベースに対するクエリ、ニュースサイトでのカテゴリの指定などに利用されている。上述したようなユーザ端末とデータ更新装置の組み合わせにおいて、ユーザ端末で例えば地図サイトを利用する場合、ユーザ端末からは緯度または経度のみが異なる多数のデータ送信要求がデータ更新装置に対して発信される。このため、データ更新装置には、地図サイトを特定するアドレスは同一であるが、パラメータ内の緯度または経度のみが異なる多数のURLが定期更新処理の対象として記憶されることになる。この場合、URLのパラメータ内の緯度および経度が一致するようなデータ送信要求がなされる頻度は非常に少ない。したがって、パラメータのみが異なるようなURLは、処理負荷および処理時間の観点から定期更新処理の対象とすべきではない。本発明はこうした状況に鑑みてなされたものであり、その目的は、登録されているURLで指定されたデータをウェブサーバから定期的に取得するデータ更新装置において、各URLの定期更新処理の必要性を判定するための技術を提供することにある。本発明の一態様は、ネットワーク上のデータを指定する複数のURLと、各URLが定期更新処理の対象であるか否かを表す定期更新フラグとが関連づけて保持されるURLリスト記憶部と、前記定期更新フラグがONであるURLで指定されるデータを、ネットワークを介して定期的に取得する更新実行部と、前記更新実行部により取得されたデータが保持されるデータ記憶部と、ユーザ端末から発信された少なくとも一つのURLを含むデータ送信要求に応じて、前記データ記憶部から前記URLに対応するデータを検索して前記ユーザ端末に送信する要求応答部と、前記URLリスト記憶部内にパラメータ部を除いたアドレス部が同一であるURLが所定のしきい値以上存在する場合、前記アドレス部が同一である全てのURLの定期更新フラグをOFFに設定する定期更新判定部と、を備える。この態様によると、URLリスト内でパラメータ部を除くアドレス部が同一であるURLの数がしきい値以上である場合、これらのURLが定期更新処理の対象外とされるので、定期更新の処理負荷および処理時間が軽減される。前記少なくとも一つのURLを含むデータ送信要求を発信したユーザ端末を特定する情報と、該データ送信要求を前記要求応答部が受信した日時を特定する情報とを含む履歴情報がURLに関連づけて保持される履歴情報記憶部と、前記URLリスト記憶部から定期更新フラグがOFFであるURLを取得し、取得したURLに関連づけられた履歴情報を前記履歴情報記憶部から取得し、前記取得したURLを含むデータ送信要求がなされた回数または前記取得したURLを含むデータ送信要求を発信したユーザ端末数をカウントし、データ送信要求回数またはユーザ端末数が所定のしきい値以上である場合、前記取得したURLの定期更新フラグをONに設定する再判定部と、をさらに備えてもよい。これによると、一旦定期更新処理の対象外とされたURLに対して、データ送信要求回数またはユーザ端末数がしきい値以上であるものについては定期更新処理の対象に再設定することで、データ更新装置からウェブサーバへのアクセス頻度を低減できる。前記URLリスト記憶部に保持されている各URLのパラメータ部に複数の変数名が含まれる場合、該複数の変数名を特定の順序で並び替えたパラメータ部に書き換えるソート部をさらに備えてもよい。これによると、パラメータ内の変数名の記載順序のみが異なるURLが、別レコードとしてURLリスト記憶部に保持されることがなくなる。本発明の別の態様は、ユーザ端末からの要求に応じてURLで指定されるデータを送信するデータ更新装置において、該データ更新装置が、複数のURLと、各URLが定期更新処理の対象であるか否かを表す定期更新フラグとを関連づけてメモリに格納し、前記定期更新フラグがONであるURLで指定されるデータを、ネットワークを介して定期的に取得し、取得されたデータをメモリに格納し、ユーザ端末から発信された少なくとも一つのURLを含むデータ送信要求に応じて、前記メモリから前記URLに対応するデータを検索して前記ユーザ端末に送信し、前記メモリ内にパラメータ部を除いたアドレス部が同一であるURLが所定のしきい値以上存在する場合、前記アドレス部が同一である全てのURLの定期更新フラグをOFFに設定することを含むデータ更新方法である。なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。本発明によれば、登録されているURLで指定されたデータをウェブサーバから定期的に取得するデータ更新装置において、各URLの定期更新処理の必要性を判定することができる。図1は、本発明の一実施形態に係る定期更新サーバ100を含むシステム全体の概略図である。定期更新サーバ100は、インターネットまたはLANLocalAreaNetwork等のネットワーク12を介して、複数のウェブサーバ20と接続されている。また、ユーザ端末30は、内蔵のブラウザを用いて、同様のネットワーク14を介して定期更新サーバ100にアクセス可能に構成される。ユーザ端末30は、携帯電話または車載端末などの移動端末であってもよいし、パーソナルコンピュータなどの固定端末であってもよい。定期更新サーバ100は、ユーザ端末から以前に要求されたことのあるURLを記憶しており、これらのURLについては、ウェブサーバ20に所定の周期でアクセスしURLで指定されるデータを取得して、所定の記憶領域に保持している。このため、記憶されているURLを含むデータ送信要求がユーザ端末30から定期更新サーバ100に対して発信された場合、定期更新サーバ100は、ウェブサーバ20にアクセスすることなく、そのURLに対応するデータを記憶領域から検索して、ユーザ端末30に送信することができる。図1の構成において、車載端末であるユーザ端末30からの要求に対して交通情報データを提供するサイトをウェブサーバ20が構成する場合を考える。ウェブサーバ20は、例えばhttpaaaaaaaltitude39190321longtitude135025201のような、車両が走行中の緯度および経度情報を表したGETメソッドパラメータが付加されたURLを受け取ると、その緯度および経度付近の交通情報データを出力するように構成されているとする。一般に、交通情報データの更新頻度は高いので、定期更新サーバ100は比較的高い頻度でウェブサーバ20から交通情報データを取得して保持データを更新する必要がある。また、ユーザ端末30からは緯度または経度のみが異なる多数のデータ送信要求が定期更新サーバ100に対して発信される。このため、定期更新サーバ100には、ウェブサーバ20を特定するアドレスは同一であるが、パラメータ内の緯度または経度のみが異なる多数のURLが定期更新処理の対象として記憶されることになる。この場合、URLのパラメータ内の緯度および経度が一致するようなデータ送信要求がなされる頻度は非常に少ない。したがって、URLのアドレス部は同一であるがパラメータ部が異なるようなURLについては、処理負荷および処理時間の観点から定期更新処理の対象とすべきではない。本実施形態では、上記のようなURLを定期更新処理の対象から外すための技術を提供する。図2は、本実施形態に係る定期更新サーバ100の構成を示すブロック図である。この構成は、ハードウエア的には、任意のコンピュータのCPU、メモリ、その他のLSIで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。要求応答部102は、ユーザ端末30から発信される、少なくとも一つのURLを含むデータ送信要求を受け取り、これに含まれるURLに対応するデータがデータ記憶部104に記憶されているか確認する。データ記憶部104に含まれていれば、そのデータを読み出してユーザ端末30に送信する。データ記憶部104に対応するデータがない場合、要求応答部102はサーバ通信部108にそのURLを渡し、サーバ通信部108はそのURLで特定されるウェブサーバ20にアクセスして対応するデータを取得する。取得されたデータはデータ記憶部104に記憶されるとともに、要求応答部102によってデータ送信要求を発信したユーザ端末30に送られる。更新実行部106は、ユーザ端末30からのデータ送信要求に含まれるURLをURLリスト記憶部112に保持させる。また、ユーザ端末30から要求応答部102に対してデータ送信要求がなされる毎に、履歴情報記憶部114内の履歴情報を更新する。履歴情報の詳細については後述する。図3は、URLリスト記憶部112に記憶されているURLリスト70の一例を示す図である。図示するように、URLリスト70は、ユーザ端末30からのデータ送信要求に含まれるURL72と、各URLが定期更新の対象であるか否かをそれぞれON、OFFで表す定期更新フラグ74と、後述する履歴情報記憶部114内の対応する履歴情報を特定する履歴ID76を一つのレコードとするリストである。なお、本実施形態では、同一のURLに対してレコードは一つのみであるとする。図4は、履歴情報記憶部114に記憶されている履歴情報80の一例を示す図である。履歴情報80は、ユーザ端末30から定期更新サーバ100に対してなされたデータ送信要求の記録であり、URL毎に一つの履歴情報が作られる。図示するように、履歴情報80には、履歴ID=ID1に関連するURL図3のhttpAAAaaaが要求された日時、すなわち要求応答部102がデータ送信要求を受信した日時82と、その要求を発信したユーザ端末の識別情報であるMACアドレス84とが含まれる。識別情報として、MACアドレスの代わりに、定期更新サーバ100へのログイン名、各ユーザ端末のIPアドレス等を使用してもよい。図2に戻り、ソート部110は、URLリスト記憶部112内のURLを随時アルファベット順にソートする。更新実行部106は、所定の間隔でURLリスト記憶部112内のURLリストを参照し、定期更新フラグがONであるURLを取り出して、サーバ通信部108に送る。サーバ通信部108は、送られたURLを使用してウェブサーバ20から対応するデータを取り出し、データ記憶部104内のデータを更新する。これによって、定期更新フラグがONであるURLについては、定期更新サーバ100によって所定の間隔でデータが更新されるので、各ユーザ端末30は、既にURLリスト記憶部112に記憶されているURLについては、最新のデータを迅速に取得することができる。定期更新判定部116は、URLリスト記憶部112に記憶されているURLのうちパラメータ部のみが異なるURL群については、定期更新が不要であると判定して、それらの定期更新フラグをOFFにセットする。これについては、図5を参照して後述する。再判定部118は、URLリスト記憶部112に記憶されているURLのうち定期更新フラグがONであるURLに関連する履歴情報を参照する。そして、所定回数以上データ更新要求が発行されているURL、または所定数以上のユーザ端末からデータ更新要求が発行されているURLについて、定期更新フラグをONにセットする。これについては、図6を参照して後述する。図5は、定期更新判定部116による定期更新の必要性を判定する処理のフローチャートである。定期更新判定部116は、所定の間隔または所定のタイミングで、例えば更新実行部106によるURL定期更新処理が完了した直後にこの処理を実行する。以下の説明では、i=1を初期値として、URLリスト70内のアルファベット順にソートされたURL72を先頭から順にURL但し、i=0~Nと表記する。なお、NはURLリスト70に含まれる全URL数を表す。定期更新判定部116は、iがN未満であるか否かを判定するS10。i=N、すなわちURLリストの最後まで達している場合S10のN、このフローを終了する。i<Nの場合S10のY、定期更新判定部116は、URLリスト記憶部112からURLを取得しS12、これにパラメータ部が含まれるか否かを判定するS14。ここで、パラメータ部とは、例えばHTTPプロトコルにおけるGETパラメータのことを指す。一例として、URLがhttpccccccp1v1p2v2である場合、記号に後続する文字列p1v1p2v2のことを以下ではパラメータ部と称し、記号の前のhttpccccccのような部分をアドレス部と称する。URLがパラメータ部を含まない場合S14のN、iを1だけインクリメントしてS30、S10に戻る。URLがパラメータ部を含む場合S14のY、定期更新判定部116は、URLからパラメータ部を取り除いたアドレス部URLaを一時的に記憶するS16。このとき、j=i1をセットし、またカウンタCNTをリセットする。定期更新判定部116は、jがN以下であるかを判定するS18。jがNより大きい場合S18のN、S26に進む。jがN以下である場合S18のY、定期更新判定部116は、URLリスト記憶部112からURLを取得し、これからパラメータ部を取り除いたアドレス部URLaを一時的に記憶するS20。続いて、定期更新判定部116は、このURLaと、ステップ16で取得したURLaとを比較するS22。両者が一致する場合S22のY、カウンタCNTおよびjをそれぞれ1だけインクリメントしてS24、S18に戻る。S22において両者が一致しない場合、S26に進む。S18~S24の一連の処理は、URLリストのi番目であるURLとアドレス部が同一でありパラメータ部が異なる他のURLの個数をカウントすることを示している。URLリストは予めアルファベット順にソートされているので、この処理によってアドレス部が重複するURLの個数をカウントすることができる。S18~S24のループの間に、URLaとURLaとが一致しなくなるかS22のN、またはURLリストの最後であるURLaとの比較が終わるすなわちj>N1とS18のN、定期更新判定部116は、カウンタCNTと予め定められたしきい値MIN_CNTとを比較するS26。カウンタCNTがしきい値以下である場合S26のN、S32に進む。カウンタCNTがしきい値未満である場合S26のY、URLとアドレス部が共通する全てのURL、すなわちURL~URLの定期更新フラグをOFFに設定するS28。なお、しきい値MIN_CNTには、アドレス部が重複するURLが複数あってもデータ更新処理に影響を及ぼさない上限の数を経験または実験等に基づき設定する。S22までの処理によって、URLとURLのアドレス部は異なることが分かっているので、i=jをセットしてS32、S10から同様の処理を繰り返す。このようにして、パラメータ部のみが異なりアドレス部が重複している複数のURLを定期更新処理の対象外に設定することができる。図6は、再判定部118による、定期更新処理の対象外となったURLのうち利用頻度の高いURLを定期更新処理の対象に戻す処理のフローチャートである。再判定部118は、この処理を所定の間隔または所定のタイミングで実行する。例えば、定期更新処理の対象外であるURLに対するデータ送信要求をユーザ端末から受信し、対応するURLのデータをウェブサーバ20から取得してユーザ端末に送信した直後に行われる。以下の説明では、データ送信要求がなされた、定期更新処理の対象外であるURLを指定URLと呼ぶ。再判定部118は、履歴情報記憶部114から指定URLに関連づけられた履歴情報を取得するS42。再判定部118は、取得した履歴情報のうち日時情報を参照して、定期更新サーバ100に対して一定の期間内になされたデータ送信要求回数をカウントし、所定のしきい値MIN1とを比較するS44。データ送信要求回数がしきい値以下の場合S44のN、指定URLのニーズが低いと考えられるので、定期更新フラグをOFFのままにする。データ送信要求回数がしきい値より大きい場合S44のY、再判定部118は、履歴情報のうち端末識別情報の異同に基づき、定期更新サーバ100が一定期間内に受信したデータ送信要求の発信元のユーザ端末数をカウントし、このユーザ端末数と所定のしきい値MIN2とを比較するS46。ユーザ端末数がしきい値以下の場合S46のN、指定URLのニーズが低いと考えられるので、定期更新フラグをOFFのままにする。ユーザ端末数がしきい値より多い場合S46のY、指定URLのニーズが高いと考えられるので、再判定部118は指定URLの定期更新フラグをONに設定するS48。なお、しきい値MIN1およびMIN2は、定期更新対象とされていないURLに対するデータ送信要求が行われても定期更新サーバの負荷に影響を及ぼさない上限の数を、経験または実験等に基づきそれぞれ設定する。また、S44とS46の判定は、いずれか一方のみを行ってもよい。このようにして、定期更新処理の対象から外れたURLを、必要に応じて再度定期更新処理の対象に戻すことが可能になる。例えば、ウェブサーバ20がニュースを提供するサイトを構成する場合、ユーザ端末30からは、httpbbbbbbcategorysportsのように、ニュースのカテゴリを指定するパラメータが付加されたURLを含むデータ送信要求が多数発信される。このようなニュースデータの場合は、上述したような交通情報データとは異なり、パラメータ部が同一であるURLのデータ送信要求もかなりの数となることが考えられる。図6で説明した再判定部118の処理によって、このような要求頻度の高いURLについては、パラメータ部が異なるがアドレス部が同一であるURLが多数存在しても、定期更新処理の対象に戻すことができる。ここで、あるユーザ端末からhttpccccccp1v1p2v2のようなURLを含むデータ送信要求が発信され、別のユーザ端末からhttpccccccp2v2p1v1のようなURLを含むデータ送信要求が発信された場合を考える。二つのURLは、変数名p1とp2の記載順序が逆であるが、実質的に同一のデータを要求している。しかしながら、上記の構成では、この二つのURLが別のレコードとしてURLリスト記憶部112に登録されてしまうという問題がある。そこで、複数の変数名がパラメータ部に含まれる新たなURLをURLリスト記憶部112に追加する場合、ソート部110は、パラメータ部内の複数の変数名を特定の順序、例えばアルファベット順、ASCIIコード順等で並び替えたURLに書き換えるようにしてもよい。こうすることで、URLリスト記憶部112内に、実質的に同内容であるURLが複数のレコードとして記憶されることがなくなる。以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。