利用者が利用する利用者端末装置から情報の収集先となる情報提供装置の指定と、当該情報提供装置から情報を収集するための収集期間と、前記利用者が要望する手続きに関する条件と、前記利用者への通知先とを受け付ける受付部と、前記利用者が指定した情報提供装置から、当該利用者に関する情報を前記収集期間にわたって繰り返し収集し、記憶部に格納する収集部と、前記記憶部に格納された情報が、前記受付部が受け付けた条件と合致しているか否かを判定する判定部と、前記判定部により前記記憶部に前記条件と合致する情報が格納されていると判定された場合、前記利用者が要望する手続きに関する条件と合致する情報が収集された旨を前記利用者への通知先に通知する通知部と、を備えたことを特徴とする情報収集システム。前記収集部による情報収集処理を開始する前に、前記利用者が指定した情報提供装置へアクセスするための認証情報を用いて、前記利用者が指定した情報提供装置との間で、前記利用者端末装置に代わって認証手続きを行なう代理認証部、を更に備え、前記受付部は、更に、前記利用者端末装置から前記認証情報を受け付けること、を特徴とする請求項1に記載の情報収集システム。前記収集部は、前記判定部により前記記憶部に前記条件と合致する情報が格納されていると判定された以降も、前記収集期間が終了するまで情報収集処理及び情報格納処理を継続することを特徴とする請求項1又は2に記載の情報収集システム。利用者が利用する利用者端末装置に接続される情報収集装置によって実行される情報収集方法であって、前記利用者端末装置から情報の収集先となる情報提供装置の指定と、当該情報提供装置から情報を収集するための収集期間と、前記利用者が要望する手続きに関する条件と、前記利用者の通知先とを受け付ける受付ステップと、前記利用者が指定した情報提供装置から、当該利用者に関する情報を前記収集期間にわたって繰り返し収集し、記憶部に格納する収集ステップと、前記記憶部に格納された情報が、前記受付部が受け付けた条件と合致しているか否かを判定する判定ステップと、前記判定ステップにより前記記憶部に前記条件と合致する情報が格納されていると判定された場合、前記利用者が要望する手続きに関する条件と合致する情報が収集された旨を前記利用者への通知先に通知する通知ステップと、を含んだことを特徴とする情報収集方法。ところで、上記した従来の技術は、ポータルシステムに複数種類の手続きをスクリプト等で作成する必要がある。しかし、代表的な処理の流れをスクリプトに記載することはできても、サービス提供システムの数や細分化された処理の数からすると、処理の流れの組み合わせは相当数に上るため、上記した従来の技術を実現するためには、膨大な投資が必要となる。そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、申請手続きのための情報収集に際し、利用者の利便性を簡易に向上させることができる情報収集システム及び情報収集方法を提供することを目的とする。本発明の実施の形態に係る情報収集システムは、利用者が利用する利用者端末装置から情報の収集先となる情報提供装置の指定と、当該情報提供装置から情報を収集するための収集期間と、前記利用者が要望する手続きに関する条件と、前記利用者への通知先とを受け付ける受付部と、前記利用者が指定した情報提供装置から、当該利用者に関する情報を前記収集期間にわたって繰り返し収集し、記憶部に格納する収集部と、前記記憶部に格納された情報が、前記受付部が受け付けた条件と合致しているか否かを判定する判定部と、前記判定部により前記記憶部に前記条件と合致する情報が格納されていると判定された場合、前記利用者が要望する手続きに関する条件と合致する情報が収集された旨を前記利用者への通知先に通知する通知部とを備える。本発明の実施の形態に係る情報収集システム及び情報収集方法は、申請手続きに要する情報収集における利用者の利便性を簡易に向上させることができるという効果を奏する。以下に、本発明に係る情報収集システム及び情報収集方法の実施形態を図面に基づいて詳細に説明する。なお、この実施形態により本発明が限定されるものではない。まず、図1を用いて、本実施例に係る情報収集システムについて説明する。図1は、本実施例に係る情報収集システムの構成例を示す図である。図1に例示するように、本実施例に係る情報収集システムは、利用者端末装置10と、情報提供サーバ群20と、情報収集装置30とを含む。図1に例示する各装置は、ネットワークを介して相互に通信可能に接続される。利用者端末装置10は、利用者が利用するPCPersonalComputerや携帯電話や、PDAPersonalDigitalAssistant等の端末装置である。利用者端末装置10は、利用者がネットワークを介して外部装置にアクセスするためのブラウザ機能を有する。なお、図1では、利用者端末装置10を1台のみ示しているが、実施例1に係る情報収集システムは、実際には、異なる複数の利用者それぞれが利用する複数の利用者端末装置10を含む。情報提供サーバ群20は、自装置にアクセスした利用者に対して当該利用者が要望する情報を提供する複数の情報提供サーバから構成される。具体的には、情報提供サーバ群20の各情報提供サーバは、Webサイトを用いて情報を提供する公共系のサービス提供システムを構成するサーバである。例えば、情報提供サーバは、利用者が医療費等、医療情報の取得を行なう際に利用する医療システムや、利用者が年金額の確認を行なう際に利用する年金システム、利用者が確定申告の申請を行なう際に利用する納税システム等である。すなわち、情報提供サーバは、利用者の目的別に異なるサービスを提供する。図1では、情報提供サーバ群20を構成する情報提供サーバとして、情報提供サーバA及び情報提供サーバBを図示している。情報提供サーバA及び情報提供サーバBは、異なる医療機関が各々独立に設置した医療システムであり、設置した医療機関にて行なわれた患者ごとの医療情報を、認証情報を登録した患者に対して提供する。ここで、従来では、例えば、確定申告で医療費控除を受ける際、利用者は、利用者端末装置10を用いて、情報提供サーバAや情報提供サーバBにアクセスして医療費を参照し、参照したデータを、納税システムに再入力していた。図2は、従来技術を説明するための図である。例えば、確定申告で医療費控除を受ける際、利用者は、利用者端末装置10のブラウザ機能を用いて、図2のAに示すように、情報提供サーバAが提供するWebサイトである医療WebサイトAや、情報提供サーバAが提供するWebサイトである医療WebサイトBに複数回アクセスして、医療費情報を収集する。具体的には、利用者は、医療費が10万円以上になったか否かを確認するために、何度も医療WebサイトAや医療WebサイトBにアクセスし、医療費情報を収集する。そして、利用者は、医療費が10万円以上になった場合、図2のAに示すように、利用者端末装置10のブラウザ機能を用いて、納税システムが提供するWebサイトである確定申告サイトにアクセスして、医療費情報を再入力することで、医療費控除の申請を行なう。このように、目的別に個別のサービス提供システムが存在する形態は、あるシステムで既に電子データとして保存されているデータを人間が参照し、再度、参照したデータを人間が別のシステムに再入力する必要がある。このため、目的別に個別のサービス提供システムが存在する形態は、利用者の観点からすると、利便性が悪い。また、個別の手続きは、上述したように相互に連携しており、例えば、医療費の額によって、確定申告を申請するかどうかが決まる。しかし、確定申告で医療費控除を受けるためには、図2のAに示すように、人間が医療費の額を確認する手続きと、確定申告する手続きとの独立した2つの手続きが必要となる。更に、公共系の手続きは、障害者控除等の例でも分かる通り、申請するための条件が細分化されており、収集したデータが、申請条件に合致しているか否かを確認するだけでも、利用者にとっては非常に困難な場合が多い。このため、例えば、障害程度に応じた申請条件等の情報の電子データを保管する別のシステムを設置することが考えられる。かかるシステムに保管されているデータを活用することで、利用者は、申請に際して手続きにより如何なるデータを収集する必要があるのかを判定できる。しかし、申請条件を保管するシステムを設置したとしても、サービス提供システムの形態としては、図2のAに示す一例と同様に目的別に個別システムが存在する形態であり、人間を介したデータのやり取りしか実現できず、依然として、利用者の観点からすると、利便性が悪い。そこで、近年、公共系における利用者の利便性を向上させるために、行政サービスの効率化や、地域情報のネットワーク化が進められている。例えば、SOAServiceOrientedArchitecture技術を用いて、上記の各システムをワンストップのサービス形態で提供することが開始されている。かかる技術では、図2のBに示すように、各システムのフロントエンドにポータルシステムが配置される。このポータルシステム上では、図2のBに示すように、複数種類の個々の処理手続きがスクリプトにて記述されている。例えば、確定申告で医療費控除を受ける際、利用者は、利用者端末装置10のブラウザ機能を用いて、図2のBに示すように、ポータルシステムに医療費控除の申請を行なう。医療費控除の申請を受け付けたポータルシステムは、医療WebサイトA、医療WebサイトB及び確定申告サイトにアクセスして、バックオフィス連携によりデータ連携を行なうよう指示する。このように、ポータルシステムは、例えば、医療費控除の申請のように相互に連携する複数の手続きを、利用者の代わりに一括で実行することで、ワンストップサービスを提供する。しかし、ワンストップのサービス形態を実現するためには、ポータルシステムに複数種類の手続きをスクリプト等で作成する必要がある。しかし、代表的な処理の流れをスクリプトに記載することはできても、サービス提供システムの数や細分化された処理の数からすると、処理の流れの組み合わせは相当数に上るため、膨大な投資が必要となる。むしろ、個々の利用者が望む手続きの組合せを簡単に構成可能な仕組みが必要である。そこで、本実施例では、図1に例示するように、情報収集装置30が情報提供サーバ群20のフロントエンドに配置される。この情報収集装置30は、以下の処理を行なうことで、申請手続きに要する情報収集における利用者の利便性を簡易に向上させる。すなわち、情報収集装置30は、利用者が利用する利用者端末装置10から情報の収集先となる情報提供サーバの指定と、当該情報提供サーバから情報を収集するための収集期間と、利用者が要望する手続きに関する条件と、利用者への通知先とを受け付ける。そして、情報収集装置30は、利用者が指定した情報提供サーバから、当該利用者に関する情報を収集期間にわたって繰り返し収集し、記憶部に格納する。そして、情報収集装置30は、記憶部に格納された情報が、受け付けた条件と合致しているか否かを判定する。そして、情報収集装置30は、記憶部に条件と合致する情報が格納されていると判定された場合、利用者が要望する手続きに関する条件と合致する情報が収集された旨を利用者への通知先に通知する。また、本実施例では、更に、情報収集装置30は、情報収集における安全性を高めるために、更に以下の処理を行なう。すなわち、情報収集装置30は、情報収集処理を開始する前に、利用者が指定した情報提供サーバへアクセスするための認証情報を用いて、利用者が指定した情報提供サーバとの間で、利用者端末装置10に代わって認証手続きを行なう。ここで、代理認証のため、情報収集装置30は、更に、利用者端末装置10から代理認証処理のための認証情報を受け付ける。上記した処理を行なうため、本実施例に係る情報収集装置30は、図1に示すように、受付部31と、認証部32と、個人情報記憶部33と、情報処理部34とを有する。以下、本実施例に係る情報収集装置30が行なう処理の流れに沿って、受付部31と、認証部32と、個人情報記憶部33と、情報処理部34とについて具体的に説明する。受付部31は、利用者端末装置10を介して利用者から各種情報を受け付けるフロントシステムである。具体的には、受付部31は、登録情報受付部31a及び通知サービス受付部31bを有する。登録情報受付部31aは、情報収集装置30が上記した情報収集処理、判定処理及び通知処理を行なうための種々の登録情報を、利用者端末装置10を介して利用者から受け付ける。具体的には、登録情報受付部31aは、利用者端末装置10から、利用者が自動検出したい申請手続きの情報と、申請手続きに必要な情報の収集先となる情報提供サーバのアドレスと、情報の収集期間と、利用者の通知先アドレスとを受け付ける。また、登録情報受付部31aは、更に、利用者端末装置10から、情報収集装置30が利用者端末装置10の利用者を本人認証するための認証情報と、利用者が指定した情報提供サーバが利用者端末装置10の利用者を本人認証するための認証情報とを受け付ける。図3及び図4は、登録情報の一例を説明するための図である。例えば、登録情報受付部31aは、図3に示すように、申請手続きが医療費控除であるとする情報を受け付ける。かかる情報を受け付けることで、情報処理部34が有するマッチング通知部34b後述は、利用者が要望する手続きに関する条件が医療費の合計が10万円以上であることを取得する。すなわち、利用者は、申請手続きの情報を登録することで、自身が要望する手続きに関する条件を登録することとなる。なお、本実施例は、利用者が申請手続きを登録する代わりに、具体的な条件を登録する場合であっても良い。例えば、利用者は、医療費控除の代わりに医療費の合計が10万円以上を登録しても良い。また、例えば、登録情報受付部31aは、図3に示すように、情報収集先が情報提供サーバAであり、情報提供サーバAのアドレスURL:UniformResourceLocatorがURLAであることを受け付ける。また、例えば、登録情報受付部31aは、図3に示すように、情報収集先が情報提供サーバBであり、情報提供サーバBのアドレスがURLBであることを受け付ける。また、例えば、登録情報受付部31aは、図3に示すように、情報収集期間として収集開始日:2011年1月1日及び収集終了日:2011年12月31日を受け付ける。また、例えば、登録情報受付部31aは、図3に示すように、通知先として1xxx.jpを受け付ける。1xxx.jpは、利用者端末装置10の利用者宛のメールアドレスである。なお、通知先となる装置は、利用者端末装置10である場合に限定されるものではない。例えば、通知先となる装置は、利用者端末装置10とは異なる利用者が利用する他の装置である場合であっても良い。また、例えば、登録情報受付部31aは、図4のAに示すように、情報収集装置30が利用者端末装置10の利用者をIDパスワード方式により本人認証するための認証情報として、ID:ID1、パスワード:P1を受け付ける。また、例えば、登録情報受付部31aは、図4のBに示すように、情報提供サーバAが利用者端末装置10の利用者をIDパスワード方式により本人認証するための認証情報として、ID:ID11、パスワード:P11を受け付ける。また、例えば、登録情報受付部31aは、図4のBに示すように、情報提供サーバBが利用者端末装置10の利用者をIDパスワード方式により本人認証するための認証情報として、ID:ID12、パスワード:P12を受け付ける。そして、登録情報受付部31aは、図3で例示した登録情報を、図1に示す個人情報記憶部33の属性情報記憶領域33aに格納する。例えば、登録情報受付部31aは、図3で例示した登録情報を図4のAで例示したID:ID1に対応付けて記憶する。また、登録情報受付部31aは、図4で例示した認証情報を、図1に示す認証部32に設定する。具体的には、登録情報受付部31aは、図4のAで例示した認証情報を、図1に示す認証部32が有する利用者認証部32aに設定する。また、登録情報受付部31aは、図4のBで例示した認証情報を、図1に示す認証部32が有する代理認証部32bに設定する。例えば、登録情報受付部31aは、図4のAで例示したID:ID1に対応付けて図4のBで例示した認証情報を代理認証部32bに設定する。図1に示す通知サービス受付部31bは、利用者端末装置10から、利用者の自動通知サービスの申し込みを受け付ける。具体的には、利用者は、利用者端末装置10を介して、自動通知サービスの申し込み用のサイトにアクセスし、先に登録した申請手続きの自動通知サービスの申し込みを行なう。より具体的には、利用者は、利用者端末装置10を介して、自動通知サービスの申し込み用のサイトにて、自身が利用者本人であることを示す認証情報を入力する。例えば、利用者は、利用者端末装置10を介して、自身が利用者本人であることを示すID:ID1、パスワード:P1を入力する。認証情報を受け付けた通知サービス受付部31bは、受け付けた認証情報を通知することで、図1に示す利用者認証部32aに本人認証を依頼する。利用者認証部32aは、自装置に設定された認証情報の中に、通知された認証情報と一致する認証情報がある場合、利用者本人であると認証する。例えば、利用者認証部32aは、ID:ID1、パスワード:P1と一致する認証情報が存在することから、利用者端末装置10から自動通知サービスの申し込みを行なった利用者を利用者本人であると認証する。そして、利用者認証部32aは、本人認証の結果を通知サービス受付部31bに通知する。通知サービス受付部31bは、本人認証が失敗した場合、通知サービスの開始処理を中断する。一方、通知サービス受付部31bは、本人認証が成功した場合、受け付けた認証情報に該当する登録情報に基づいて、通知サービスを開始するよう、図1に示す情報処理部34に通知する。具体的には、通知サービス受付部31bは、本人認証が成功した認証情報を情報処理部34に通知することで、受け付けた認証情報に該当する登録情報に基づいて通知サービスを開始することを依頼する。情報処理部34は、図1に示すように、収集部34a及びマッチング通知部34bを有する。通知サービス受付部31bからの通知サービス開始指示は、収集部34aに通知される。収集部34aは、通知サービス開始指示とともに受信した認証情報に該当する登録情報を、属性情報記憶領域33aから取得する。例えば、収集部34aは、属性情報記憶領域33aからID:ID1に対応付けられている登録情報図3を参照を取得する。収集部34aは、属性情報記憶領域33aが記憶する登録情報を参照して、利用者が指定した情報提供サーバにアクセスする。例えば、収集部34aは、ID:ID1に対応付けられている情報提供サーバAのアドレスURLAと、情報提供サーバBのアドレスURLBにアクセスする。かかる場合、情報提供サーバA及び情報提供サーバBそれぞれは、認証情報を要求する。認証情報の要求を受け付けた収集部34aは、ID:ID1とともに、情報提供サーバA及び情報提供サーバBに対する代理認証処理の要求を図1に示す代理認証部32bに転送する。代理認証部32bは、ID:ID1に対応付けて設定されている認証情報を用いて、代理認証処理を行なう。例えば、代理認証部32bは、ID:ID1に対応付けられている情報提供サーバAのID:ID11、パスワード:P11と情報提供サーバBのID:ID12、パスワード:P12とを、収集部34aを介して、情報提供サーバA及び情報提供サーバBそれぞれに通知する。かかる代理認証処理により情報収集先の情報提供サーバにて本人認証が成功した後、収集部34aは、利用者に関する情報を、情報収集先の情報提供サーバを収集期間に渡って繰り返し収集し、図1に示す個人情報記憶部33の収集情報記憶領域33bに格納する。例えば、収集部34aは、収集開始日:2011年1月1日から収集終了日:2011年12月31日まで、一定期間ごとに情報提供サーバAにそれぞれアクセスして、ID:ID11に対応付けられている利用者の医療費情報を繰り返し収集する。同様に、収集部34aは、収集開始日:2011年1月1日から収集終了日:2011年12月31日まで、一定期間ごとに情報提供サーバBにそれぞれアクセスして、ID:ID12に対応付けられている利用者の医療費情報を繰り返し収集する。一例を挙げると、収集部34aは、月末ごとに、代理認証部32bによる代理認証処理を行なって、情報収集先の情報提供サーバから利用者に関する情報を収集する。これにより、収集情報記憶領域33bには、利用者に関する情報が順次蓄積される。図5は、収集情報記憶領域に格納される情報の一例を説明するための図である。例えば、収集情報記憶領域33bは、図5のAに示すように、収集部34aが2011年の1月末に情報提供サーバA及び情報提供サーバBから収集した利用者の医療費情報として2011年1月、医療費:5000円を記憶する。また、例えば、収集情報記憶領域33bは、図5のBに示すように、収集部34aが2011年の2月末に情報提供サーバA及び情報提供サーバBから収集した利用者の医療費情報として2011年2月、医療費:6500円を追加して記憶する。同様に、収集情報記憶領域33bは、図5のCに示すように、収集部34aが2011年の3月末~12月末ごとに情報提供サーバA及び情報提供サーバBから収集した利用者の医療費情報を順次追加して記憶する。図1に示すマッチング通知部34bは、収集情報記憶領域33bに格納された情報が、受け付けた条件と合致しているか否かを判定する。すなわち、マッチング通知部34bは、収集情報記憶領域33bに新規に情報が格納されるごとに、格納された情報を参照し、属性情報記憶領域33aに登録された申請手続きに合致した条件となったか否かを判定する。そして、マッチング通知部34bは、収集情報記憶領域33bに条件と合致する情報が格納されていると判定した場合、利用者が要望する手続きに関する条件と合致する情報が収集された旨を利用者端末装置10に通知する。図6は、マッチング通知部の処理の一例を説明するための図である。例えば、マッチング通知部34bは、図5のAに示す医療費情報を参照して、図6のAに示すように、医療費合計が5000円であると算出する。かかる場合、マッチング通知部34bは、医療費合計が10万円以上でないことから、登録情報の医療費控除に合致した条件となる情報が収集されていないと判定する。同様に、マッチング通知部34bは、図5のBに示す医療費情報を参照して、図6のBに示すように、医療費合計が11500円であると算出する。かかる場合も、マッチング通知部34bは、医療費合計が10万円以上でないことから、登録情報の医療費控除に合致した条件となる情報が収集されていないと判定する。マッチング通知部34bは、かかる処理を月末ごとに繰り返す。そして、例えば、マッチング通知部34bは、図5のCに示す医療費情報を参照して、図6のCに示すように、医療費合計が100500円であると算出する。かかる場合、マッチング通知部34bは、医療費合計が11月末時点の90500円から10万円以上となったことから、登録情報の医療費控除に合致した条件となる情報が収集されたと判定する。そして、マッチング通知部34bは、属性情報記憶領域33aの登録情報である通知:1xxx.jpに対して、図6のCに示すように、通知を行なう。例えば、マッチング通知部34bは、図6のCに示すように、通知:1xxx.jp宛のメール本文に医療費控除の申請条件となりましたを記載したメールを送信する。なお、収集期間において所定間隔で繰り返される収集部34a及びマッチング通知部34bの処理は、上記のように、月末ごとに行なわれる場合に限定されるものではない。例えば、収集期間において繰り返される収集部34a及びマッチング通知部34bの処理は、月初ごとに行なわれる場合や、10日ごとに行なわれる場合、或いは、1日ごとに行なわれる場合であっても良い。また、収集期間における収集時期は、利用者により登録される場合であっても、情報収集システムの管理者により予め登録される場合であっても良い。また、上述した一例では、収集期間の終了日において、利用者が登録した条件に合致した情報が収集され、利用者利用者端末装置10に通知が行なわれている。しかし、収集部34a及びマッチング通知部34bの協同処理による自動通知サービスは、収集期間中に利用者が登録した条件に合致した情報が収集された時点で行なわれる。従って、例えば、10月末の時点で利用者端末装置10に通知が行なわれる場合もある。かかる場合、利用者端末装置10の利用者は、医療費控除の申請を行なう条件となったことを把握することができる。しかし、医療費控除の申請には、収集期間中の医療費の合計が必要となる。そこで、本実施例は、収集部34aが以下の処理を行なっても良い。すなわち、収集部34aは、マッチング通知部34bが収集情報記憶領域33bに条件と合致する情報が格納されていると判定した以降も、収集期間が終了するまで情報収集処理及び情報格納処理を継続する。このように、本実施例は、自動通知サービスが行なわれた後も、利用者による情報収集の利便性を確保するために、収集期間中の情報収集処理及び情報格納処理を継続する場合であっても良い。かかる処理により、利用者は、申請手続きの条件に合致した情報が収集されたことを把握できるとともに、申請手続きに要する全情報を収集情報記憶領域33bから取得することができる。続いて、図7及び図8を用いて、本実施例に係る情報収集システムを構成する情報収集装置30の処理の手順を説明する。図7は、本実施例に係る情報収集装置の情報登録処理を説明するためのフローチャートであり、図8は、本実施例に係る情報収集装置の情報収集及び通知処理を説明するためのフローチャートである。図7に示すように、本実施例に係る情報収集装置30の登録情報受付部31aは、利用者端末装置10から情報登録の要求を受け付けたか否かを判定するステップS101。ここで、情報登録の要求を受け付けない場合ステップS101否定、登録情報受付部31aは、情報登録の要求を受け付けるまで待機する。一方、情報登録の要求を受け付けた場合ステップS101肯定、登録情報受付部31aは、申請に関する情報を個人情報記憶部33の属性情報記憶領域33aに登録しステップS102、更に、認証情報を認証部32に設定しステップS103、登録処理を終了する。すなわち、登録情報受付部31aは、利用者端末装置10から受け付けた情報の収集先となる情報提供サーバに関する情報と、情報提供サーバから情報を収集するための収集期間と、利用者が要望する手続きに関する条件と通知先とを属性情報記憶領域33aに登録する。更に、登録情報受付部31aは、利用者端末装置10の利用者と情報収集装置30との間での認証情報を利用者認証部32aに設定する。また、登録情報受付部31aは、情報の収集先との間で代理認証を行なうための認証情報を代理認証部32bに設定する。そして、図8に示すように、本実施例に係る情報収集装置30の登録情報受付部31aは、利用者端末装置10から通知サービスの開始要求を受け付けたか否かを判定するステップS201。ここで、通知サービスの開始要求を受け付けない場合ステップS201否定、登録情報受付部31aは、通知サービスの開始要求を受け付けるまで待機する。一方、通知サービスの開始要求を受け付けた場合ステップS201肯定、登録情報受付部31aは、利用者端末装置10から認証情報利用者端末装置10の利用者と情報収集装置30との間での認証情報を受け付けたか否かを判定するステップS202。ここで、認証情報を受け付けない場合ステップS202否定、登録情報受付部31aは、認証情報を受け付けるまで待機する。一方、認証情報を受け付けた場合ステップS202肯定、登録情報受付部31aの依頼により、利用者認証部32aは、受け付けた認証情報が設定された認証情報に一致するか否かを判定するステップS203。ここで、一致しない場合ステップS203否定、登録情報受付部31aは、通知サービスを終了する。一方、一致する場合ステップS203肯定、登録情報受付部31aは、収集部34aに情報収集処理を依頼するステップS204。収集部34aは、本人認証された利用者が登録した収集期間における収集時期であるか否かを判定するステップS205。ここで、収集期間における収集時期でない場合ステップS205否定、収集部34aは、収集期間における収集時期となるまで待機する。一方、収集期間における収集時期である場合ステップS205肯定、収集部34aの依頼により、代理認証部32bは、情報収集先との代理認証処理を実行するステップS206。そして、収集部34aは、代理認証部32bによる代理認証が成功したか否かを判定するステップS207。ここで、代理認証が失敗した場合ステップS207否定、収集部34aは、通知サービスを終了する。一方、代理認証が成功した場合ステップS207肯定、収集部34aは、利用者端末装置10の利用者に関する情報であり、利用者が要望する手続きに該当する情報があるか否かを判定するステップS208。ここで、該当する情報がない場合ステップS208否定、収集部34aは、ステップS205に戻って、次の収集時期となるまで待機する。一方、該当する情報がある場合ステップS208肯定、収集部34aは、該当する情報を収集し、収集情報記憶領域33bに格納するステップS209。そして、マッチング通知部34bは、収集情報記憶領域33bに格納された情報が申請手続きの条件に合致するか否かを判定するステップS210。ここで、合致しない場合ステップS210否定、マッチング通知部34bの指示により収集部34aは、ステップS205に戻って、次の収集時期となるまで待機する。一方、合致した場合ステップS210肯定、申請手続きの条件に合致する情報が収集された旨を、利用者端末装置10に通知しステップS211、通知サービスを終了する。なお、収集期間が終了した時点で、申請手続きの条件に合致する情報が収集されていなかった場合、マッチング通知部34bは、申請手続きの条件に合致する情報が収集されなかった旨を、登録された通知先に通知して、通知サービスを終了しても良い。また、上述したように、通知先となる装置は、登録情報によっては、利用者端末装置10以外の装置であっても良い。上述したように、本実施例に係る情報収集システムを構成する情報収集装置30は、利用者自身が要望する申請手続きに関する登録を受け付けて、利用者代理で情報を収集し、申請手続きに必要となる情報を収集した時点で利用者に通知する。図9は、本実施例の効果を説明するための図である。本実施例では、図9に示すように、利用者は、利用者端末装置10を介して、登録処理を行なう。かかる登録処理により、情報収集装置30は、図9に示すように、収集期間において、定期的に医療WebサイトA及び医療WebサイトBに複数回アクセスして、利用者代理で医療費情報を収集する。そして、情報収集装置30は、図9に示すように、収集した医療費情報が医療費控除の条件を満たした時点で、利用者端末装置10を介して利用者にプッシュ型で通知する。このように、利用者が行なう処理は、申請手続きに関する情報の登録処理のみであり、図2のAで説明した従来例のように、利用者本人が何度も、情報を提供するシステムにアクセスする必要はない。また、情報収集側では、図2のBで説明した従来例のように、全ての処理手続きの組み合わせをスクリプトで記述するといった用意をする必要がない。すなわち、本実施例によれば、情報収集側で全ての手続きの組み合わせパターンを用意することなく、利用者が望む手続きの組合せを利用者自身で簡単に構成することができる。また、本実施例によれば、利用者自身が何度も情報収集先にアクセスする必要がない。また、本実施例によれば、利用者本人が収集したい情報が一元的に保存され、収集処理を行なう装置側で収集された情報内容を把握できる。また、本実施例によれば、利用者は、申請手続きに必要な情報が揃っていることを、タイムリーに知ることができる。従って、本実施例によれば、申請手続きのための情報収集に際し、利用者の利便性を簡易に向上させることができる。また、情報収集装置30は、申請手続きに関する情報として情報収集先の認証情報を受け付けることで、利用者に代わって、情報収集先との間で代理認証処理を行なう。従って、本実施例によれば、申請手続きのための情報収集における安全性を確保することができる。また、本実施例は、通知サービス終了以降も、収集期間が終了するまで情報収集処理及び情報格納処理を継続する場合であっても良いので、申請手続きのための情報収集に際し、利用者の利便性を向上させることができる。なお、上記の通知サービスが適用される申請としては、上記の医療費控除の申請以外にも、様々な適用例がある。例えば、上記の通知サービスが適用される申請としては、住宅ローンの繰越返済の申請などがある。かかる場合、情報収集装置30は、年金システムに年金の配布金額を繰り返し収集し、合計金額が所定の金額例えば、50万円となった時点で利用者の通知先に通知し、通知された利用者が住宅ローンを組んだ金融機関のシステムに繰越返済の申請を行なう。ところで、本実施例で説明した情報収集方法は、上記のように、1台の装置で実行される場合に限定されるものではない。例えば、本実施例で説明した情報収集方法は、受付部31、認証部32、個人情報記憶部33及び情報処理部34の機能を有する各装置サーバにより分散して実行される場合であっても良い。すなわち、上記の本実施例の説明に用いた図面に示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散統合して構成することができる。例えば、マッチング通知部34bは、マッチング部判定部と通知部との2つの処理部に分離される場合であっても良い。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、CPUおよび当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。また、上記実施例で説明した情報収集方法は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのIPネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク、CD-ROMCompactDiskReadOnlyMemory、MOMagnetoOpticaldisk、DVDDigitalVersatileDiskなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。