JP2013003975A - 情報収集システム及び情報収集方法 - Google Patents

Abstract

【課題】申請手続きのための情報収集に際し、利用者の利便性を簡易に向上させること。
【解決手段】登録情報受付部３１ａは、利用者端末装置１０から情報の収集先となる情報提供サーバの指定と、当該情報提供装置から情報を収集するための収集期間と、利用者が要望する手続きに関する条件と、利用者への通知先とを受け付ける。収集部３４ａは、利用者が指定した情報提供サーバから、当該利用者に関する情報を収集期間にわたって繰り返し収集し、属性情報記憶領域３３ａに格納する。マッチング通知部３４ｂは、格納された情報が、条件と合致しているか否かを判定し、合致する情報が格納されていると判定された場合、利用者が要望する手続きに関する条件と合致する情報が収集された旨を利用者への通知先に通知する。
【選択図】図１

Description

本発明の実施の形態は、情報収集システム及び情報収集方法に関する。

従来、Ｗｅｂサイトを用いた公共系のサービス提供システムとして、医療システムや、年金システム、納税システム等が存在する。医療システムは、例えば、利用者が医療費等、医療情報の取得を行なう際に利用される。また、年金システムは、例えば、利用者が年金額の確認を行なう際に利用される。また、納税システムは、例えば、利用者が確定申告の申請を行なう際に利用される。このように、サービス提供システムは、利用者の目的別に別々に存在しており、利用者は、端末装置のブラウザ等を利用して、自身が利用したいサービス提供システムにアクセスし、医療情報の取得、年金額の確認、確定申告の申請等を実施している。

しかし、目的別に個別のサービス提供システムが存在する形態は、利用者の観点からすると、利便性が悪かった。例えば、確定申告で医療費控除を受ける際、利用者は、医療システムにアクセスして医療費を参照し、参照したデータを、納税システムに再入力する必要がある。つまり、目的別に個別のサービス提供システムが存在する形態は、あるシステムで既に電子データとして保存されているデータを人間が参照し、再度、参照したデータを人間が別のシステムに再入力する必要があるため、効率が悪い。

また、個別の手続きは、上述したように相互に連携しており、例えば、医療費の額によって、確定申告を申請するかどうかが決まる。しかし、確定申告で医療費控除を受けるためには、現状では、人間が医療費の額を確認する手続きと、確定申告する手続きとの独立した２つの手続きが必要となる。

更に、公共系の手続きは、障害者控除等の例でも分かる通り、申請するための条件が細分化されており、収集したデータが、申請条件に合致しているか否かを確認するだけでも、利用者にとっては非常に困難な場合が多い。このため、例えば、障害程度に応じた申請条件等の情報の電子データを保管する別のシステムを設置することが考えられる。かかるシステムに保管されているデータを活用することで、利用者は、申請に際して手続きにより如何なるデータを収集する必要があるのかを判定できる。しかし、申請条件を保管するシステムを設置したとしても、サービス提供システムの形態としては、上記と同様に目的別に個別システムが存在する形態であり、人間を介したデータのやり取りしか実現できず、依然として、利用者の観点からすると、利便性が悪い。

そこで、近年、公共系における利用者の利便性を向上させるために、行政サービスの効率化や、地域情報のネットワーク化が進められている。例えば、ＳＯＡ（Service Oriented Architecture）技術等を用いて、上記の各システムをワンストップのサービス形態で提供することが開始されている。かかる技術では、利用者が複数の公共系のサービス提供システムそれぞれにアクセスして個別の手続きを実行する代わりに、各システムのフロントエンドにポータルシステムが配置される。このポータルシステム上では、複数種類の個々の手続きが一連の手続きとして記述され、その結果、ポータルシステムは、利用者の代わりに、相互に連携する複数の手続きを一括で実行することで、ワンストップサービスを提供することができる。

"ワンストップ電子行政サービスの実現に向けて"、［online］、［平成２３年６月１日検索］、インターネット＜http://e-public.nttdata.co.jp/f/repo/579_j0810/j0810.aspx＞ 篠田隆志他、"地域情報プラットフォームによる地域の変革"、日立評論、Ｖｏｌ．９０ Ｎｏ．０３、２００８．０３、Page.６２−６５ "地域情報化へ向けての基盤整備"、［online］、［平成２３年６月１日検索］、インターネット＜http://www.applic.or.jp/concept/conceptpresentation.pdf＞

ところで、上記した従来の技術は、ポータルシステムに複数種類の手続きをスクリプト等で作成する必要がある。しかし、代表的な処理の流れをスクリプトに記載することはできても、サービス提供システムの数や細分化された処理の数からすると、処理の流れの組み合わせは相当数に上るため、上記した従来の技術を実現するためには、膨大な投資が必要となる。

そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、申請手続きのための情報収集に際し、利用者の利便性を簡易に向上させることができる情報収集システム及び情報収集方法を提供することを目的とする。

本発明の実施の形態に係る情報収集システムは、利用者が利用する利用者端末装置から情報の収集先となる情報提供装置の指定と、当該情報提供装置から情報を収集するための収集期間と、前記利用者が要望する手続きに関する条件と、前記利用者への通知先とを受け付ける受付部と、前記利用者が指定した情報提供装置から、当該利用者に関する情報を前記収集期間にわたって繰り返し収集し、記憶部に格納する収集部と、前記記憶部に格納された情報が、前記受付部が受け付けた条件と合致しているか否かを判定する判定部と、前記判定部により前記記憶部に前記条件と合致する情報が格納されていると判定された場合、前記利用者が要望する手続きに関する条件と合致する情報が収集された旨を前記利用者への通知先に通知する通知部とを備える。

本発明の実施の形態に係る情報収集システム及び情報収集方法は、申請手続きに要する情報収集における利用者の利便性を簡易に向上させることができるという効果を奏する。

図１は、本実施例に係る情報収集システムの構成例を示す図である。 図２は、従来技術を説明するための図である。 図３は、登録情報の一例を説明するための図（１）である。 図４は、登録情報の一例を説明するための図（２）である。 図５は、収集情報記憶領域に格納される情報の一例を説明するための図である。 図６は、マッチング通知部の処理の一例を説明するための図である。 図７は、本実施例に係る情報収集装置の情報登録処理を説明するためのフローチャートである。 図８は、本実施例に係る情報収集装置の情報収集及び通知処理を説明するためのフローチャートである。 図９は、本実施例の効果を説明するための図である。

以下に、本発明に係る情報収集システム及び情報収集方法の実施形態を図面に基づいて詳細に説明する。なお、この実施形態により本発明が限定されるものではない。

まず、図１を用いて、本実施例に係る情報収集システムについて説明する。図１は、本実施例に係る情報収集システムの構成例を示す図である。図１に例示するように、本実施例に係る情報収集システムは、利用者端末装置１０と、情報提供サーバ群２０と、情報収集装置３０とを含む。図１に例示する各装置は、ネットワークを介して相互に通信可能に接続される。

利用者端末装置１０は、利用者が利用するＰＣ（Personal Computer）や携帯電話や、ＰＤＡ（Personal Digital Assistant）等の端末装置である。利用者端末装置１０は、利用者がネットワークを介して外部装置にアクセスするためのブラウザ機能を有する。なお、図１では、利用者端末装置１０を１台のみ示しているが、実施例１に係る情報収集システムは、実際には、異なる複数の利用者それぞれが利用する複数の利用者端末装置１０を含む。

情報提供サーバ群２０は、自装置にアクセスした利用者に対して当該利用者が要望する情報を提供する複数の情報提供サーバから構成される。具体的には、情報提供サーバ群２０の各情報提供サーバは、Ｗｅｂサイトを用いて情報を提供する公共系のサービス提供システムを構成するサーバである。例えば、情報提供サーバは、利用者が医療費等、医療情報の取得を行なう際に利用する医療システムや、利用者が年金額の確認を行なう際に利用する年金システム、利用者が確定申告の申請を行なう際に利用する納税システム等である。すなわち、情報提供サーバは、利用者の目的別に異なるサービスを提供する。

図１では、情報提供サーバ群２０を構成する情報提供サーバとして、情報提供サーバＡ及び情報提供サーバＢを図示している。情報提供サーバＡ及び情報提供サーバＢは、異なる医療機関が各々独立に設置した医療システムであり、設置した医療機関にて行なわれた患者ごとの医療情報を、認証情報を登録した患者に対して提供する。

ここで、従来では、例えば、確定申告で医療費控除を受ける際、利用者は、利用者端末装置１０を用いて、情報提供サーバＡや情報提供サーバＢにアクセスして医療費を参照し、参照したデータを、納税システムに再入力していた。図２は、従来技術を説明するための図である。

例えば、確定申告で医療費控除を受ける際、利用者は、利用者端末装置１０のブラウザ機能を用いて、図２の（Ａ）に示すように、情報提供サーバＡが提供するＷｅｂサイトである「医療ＷｅｂサイトＡ」や、情報提供サーバＡが提供するＷｅｂサイトである「医療ＷｅｂサイトＢ」に複数回アクセスして、医療費情報を収集する。具体的には、利用者は、医療費が１０万円以上になったか否かを確認するために、何度も医療ＷｅｂサイトＡや医療ＷｅｂサイトＢにアクセスし、医療費情報を収集する。そして、利用者は、医療費が１０万円以上になった場合、図２の（Ａ）に示すように、利用者端末装置１０のブラウザ機能を用いて、納税システムが提供するＷｅｂサイトである「確定申告サイト」にアクセスして、医療費情報を再入力することで、医療費控除の申請を行なう。

このように、目的別に個別のサービス提供システムが存在する形態は、あるシステムで既に電子データとして保存されているデータを人間が参照し、再度、参照したデータを人間が別のシステムに再入力する必要がある。このため、目的別に個別のサービス提供システムが存在する形態は、利用者の観点からすると、利便性が悪い。

また、個別の手続きは、上述したように相互に連携しており、例えば、医療費の額によって、確定申告を申請するかどうかが決まる。しかし、確定申告で医療費控除を受けるためには、図２の（Ａ）に示すように、人間が医療費の額を確認する手続きと、確定申告する手続きとの独立した２つの手続きが必要となる。

更に、公共系の手続きは、障害者控除等の例でも分かる通り、申請するための条件が細分化されており、収集したデータが、申請条件に合致しているか否かを確認するだけでも、利用者にとっては非常に困難な場合が多い。このため、例えば、障害程度に応じた申請条件等の情報の電子データを保管する別のシステムを設置することが考えられる。かかるシステムに保管されているデータを活用することで、利用者は、申請に際して手続きにより如何なるデータを収集する必要があるのかを判定できる。しかし、申請条件を保管するシステムを設置したとしても、サービス提供システムの形態としては、図２の（Ａ）に示す一例と同様に目的別に個別システムが存在する形態であり、人間を介したデータのやり取りしか実現できず、依然として、利用者の観点からすると、利便性が悪い。

そこで、近年、公共系における利用者の利便性を向上させるために、行政サービスの効率化や、地域情報のネットワーク化が進められている。例えば、ＳＯＡ（Service Oriented Architecture）技術を用いて、上記の各システムをワンストップのサービス形態で提供することが開始されている。かかる技術では、図２の（Ｂ）に示すように、各システムのフロントエンドにポータルシステムが配置される。このポータルシステム上では、図２の（Ｂ）に示すように、複数種類の個々の処理手続きがスクリプトにて記述されている。

例えば、確定申告で医療費控除を受ける際、利用者は、利用者端末装置１０のブラウザ機能を用いて、図２の（Ｂ）に示すように、ポータルシステムに医療費控除の申請を行なう。医療費控除の申請を受け付けたポータルシステムは、「医療ＷｅｂサイトＡ」、「医療ＷｅｂサイトＢ」及び「確定申告サイト」にアクセスして、バックオフィス連携によりデータ連携を行なうよう指示する。このように、ポータルシステムは、例えば、医療費控除の申請のように相互に連携する複数の手続きを、利用者の代わりに一括で実行することで、ワンストップサービスを提供する。

しかし、ワンストップのサービス形態を実現するためには、ポータルシステムに複数種類の手続きをスクリプト等で作成する必要がある。しかし、代表的な処理の流れをスクリプトに記載することはできても、サービス提供システムの数や細分化された処理の数からすると、処理の流れの組み合わせは相当数に上るため、膨大な投資が必要となる。むしろ、個々の利用者が望む手続きの組合せを簡単に構成可能な仕組みが必要である。

そこで、本実施例では、図１に例示するように、情報収集装置３０が情報提供サーバ群２０のフロントエンドに配置される。

この情報収集装置３０は、以下の処理を行なうことで、申請手続きに要する情報収集における利用者の利便性を簡易に向上させる。すなわち、情報収集装置３０は、利用者が利用する利用者端末装置１０から情報の収集先となる情報提供サーバの指定と、当該情報提供サーバから情報を収集するための収集期間と、利用者が要望する手続きに関する条件と、利用者への通知先とを受け付ける。そして、情報収集装置３０は、利用者が指定した情報提供サーバから、当該利用者に関する情報を収集期間にわたって繰り返し収集し、記憶部に格納する。

そして、情報収集装置３０は、記憶部に格納された情報が、受け付けた条件と合致しているか否かを判定する。そして、情報収集装置３０は、記憶部に条件と合致する情報が格納されていると判定された場合、利用者が要望する手続きに関する条件と合致する情報が収集された旨を利用者への通知先に通知する。

また、本実施例では、更に、情報収集装置３０は、情報収集における安全性を高めるために、更に以下の処理を行なう。すなわち、情報収集装置３０は、情報収集処理を開始する前に、利用者が指定した情報提供サーバへアクセスするための認証情報を用いて、利用者が指定した情報提供サーバとの間で、利用者端末装置１０に代わって認証手続きを行なう。ここで、代理認証のため、情報収集装置３０は、更に、利用者端末装置１０から代理認証処理のための認証情報を受け付ける。

上記した処理を行なうため、本実施例に係る情報収集装置３０は、図１に示すように、受付部３１と、認証部３２と、個人情報記憶部３３と、情報処理部３４とを有する。

以下、本実施例に係る情報収集装置３０が行なう処理の流れに沿って、受付部３１と、認証部３２と、個人情報記憶部３３と、情報処理部３４とについて具体的に説明する。

受付部３１は、利用者端末装置１０を介して利用者から各種情報を受け付けるフロントシステムである。具体的には、受付部３１は、登録情報受付部３１ａ及び通知サービス受付部３１ｂを有する。登録情報受付部３１ａは、情報収集装置３０が上記した情報収集処理、判定処理及び通知処理を行なうための種々の登録情報を、利用者端末装置１０を介して利用者から受け付ける。

具体的には、登録情報受付部３１ａは、利用者端末装置１０から、利用者が自動検出したい申請手続きの情報と、申請手続きに必要な情報の収集先となる情報提供サーバのアドレスと、情報の収集期間と、利用者の通知先アドレスとを受け付ける。また、登録情報受付部３１ａは、更に、利用者端末装置１０から、情報収集装置３０が利用者端末装置１０の利用者を本人認証するための認証情報と、利用者が指定した情報提供サーバが利用者端末装置１０の利用者を本人認証するための認証情報とを受け付ける。図３及び図４は、登録情報の一例を説明するための図である。

例えば、登録情報受付部３１ａは、図３に示すように、「申請手続き」が「医療費控除」であるとする情報を受け付ける。かかる情報を受け付けることで、情報処理部３４が有するマッチング通知部３４ｂ（後述）は、利用者が要望する手続きに関する条件が「医療費の合計が１０万円以上」であることを取得する。すなわち、利用者は、申請手続きの情報を登録することで、自身が要望する手続きに関する条件を登録することとなる。なお、本実施例は、利用者が「申請手続き」を登録する代わりに、具体的な「条件」を登録する場合であっても良い。例えば、利用者は、「医療費控除」の代わりに「医療費の合計が１０万円以上」を登録しても良い。

また、例えば、登録情報受付部３１ａは、図３に示すように、「情報収集先」が「情報提供サーバＡ」であり、「情報提供サーバＡ」のアドレス（ＵＲＬ：Uniform Resource Locator）が「ＵＲＬＡ」であることを受け付ける。また、例えば、登録情報受付部３１ａは、図３に示すように、「情報収集先」が「情報提供サーバＢ」であり、「情報提供サーバＢ」のアドレスが「ＵＲＬＢ」であることを受け付ける。

また、例えば、登録情報受付部３１ａは、図３に示すように、情報収集期間として「収集開始日：２０１１年１月１日」及び「収集終了日：２０１１年１２月３１日」を受け付ける。また、例えば、登録情報受付部３１ａは、図３に示すように、通知先として「１＠ｘｘｘ．ｊｐ」を受け付ける。「１＠ｘｘｘ．ｊｐ」は、利用者端末装置１０の利用者宛のメールアドレスである。なお、通知先となる装置は、利用者端末装置１０である場合に限定されるものではない。例えば、通知先となる装置は、利用者端末装置１０とは異なる利用者が利用する他の装置である場合であっても良い。

また、例えば、登録情報受付部３１ａは、図４の（Ａ）に示すように、情報収集装置３０が利用者端末装置１０の利用者をＩＤ＆パスワード方式により本人認証するための認証情報として、「ＩＤ：ＩＤ（１）、パスワード：Ｐ（１）」を受け付ける。また、例えば、登録情報受付部３１ａは、図４の（Ｂ）に示すように、情報提供サーバＡが利用者端末装置１０の利用者をＩＤ＆パスワード方式により本人認証するための認証情報として、「ＩＤ：ＩＤ（１１）、パスワード：Ｐ（１１）」を受け付ける。また、例えば、登録情報受付部３１ａは、図４の（Ｂ）に示すように、情報提供サーバＢが利用者端末装置１０の利用者をＩＤ＆パスワード方式により本人認証するための認証情報として、「ＩＤ：ＩＤ（１２）、パスワード：Ｐ（１２）」を受け付ける。

そして、登録情報受付部３１ａは、図３で例示した登録情報を、図１に示す個人情報記憶部３３の属性情報記憶領域３３ａに格納する。例えば、登録情報受付部３１ａは、図３で例示した登録情報を図４の（Ａ）で例示した「ＩＤ：ＩＤ（１）」に対応付けて記憶する。

また、登録情報受付部３１ａは、図４で例示した認証情報を、図１に示す認証部３２に設定する。具体的には、登録情報受付部３１ａは、図４の（Ａ）で例示した認証情報を、図１に示す認証部３２が有する利用者認証部３２ａに設定する。また、登録情報受付部３１ａは、図４の（Ｂ）で例示した認証情報を、図１に示す認証部３２が有する代理認証部３２ｂに設定する。例えば、登録情報受付部３１ａは、図４の（Ａ）で例示した「ＩＤ：ＩＤ（１）」に対応付けて図４の（Ｂ）で例示した認証情報を代理認証部３２ｂに設定する。

図１に示す通知サービス受付部３１ｂは、利用者端末装置１０から、利用者の自動通知サービスの申し込みを受け付ける。具体的には、利用者は、利用者端末装置１０を介して、「自動通知サービスの申し込み」用のサイトにアクセスし、先に登録した申請手続きの自動通知サービスの申し込みを行なう。より具体的には、利用者は、利用者端末装置１０を介して、「自動通知サービスの申し込み」用のサイトにて、自身が利用者本人であることを示す認証情報を入力する。例えば、利用者は、利用者端末装置１０を介して、自身が利用者本人であることを示す「ＩＤ：ＩＤ（１）、パスワード：Ｐ（１）」を入力する。

認証情報を受け付けた通知サービス受付部３１ｂは、受け付けた認証情報を通知することで、図１に示す利用者認証部３２ａに本人認証を依頼する。利用者認証部３２ａは、自装置に設定された認証情報の中に、通知された認証情報と一致する認証情報がある場合、利用者本人であると認証する。例えば、利用者認証部３２ａは、「ＩＤ：ＩＤ（１）、パスワード：Ｐ（１）」と一致する認証情報が存在することから、利用者端末装置１０から「自動通知サービスの申し込み」を行なった利用者を利用者本人であると認証する。

そして、利用者認証部３２ａは、本人認証の結果を通知サービス受付部３１ｂに通知する。通知サービス受付部３１ｂは、本人認証が失敗した場合、通知サービスの開始処理を中断する。一方、通知サービス受付部３１ｂは、本人認証が成功した場合、受け付けた認証情報に該当する登録情報に基づいて、通知サービスを開始するよう、図１に示す情報処理部３４に通知する。具体的には、通知サービス受付部３１ｂは、本人認証が成功した認証情報を情報処理部３４に通知することで、受け付けた認証情報に該当する登録情報に基づいて通知サービスを開始することを依頼する。

情報処理部３４は、図１に示すように、収集部３４ａ及びマッチング通知部３４ｂを有する。通知サービス受付部３１ｂからの通知サービス開始指示は、収集部３４ａに通知される。収集部３４ａは、通知サービス開始指示とともに受信した認証情報に該当する登録情報を、属性情報記憶領域３３ａから取得する。例えば、収集部３４ａは、属性情報記憶領域３３ａから「ＩＤ：ＩＤ（１）」に対応付けられている登録情報（図３を参照）を取得する。

収集部３４ａは、属性情報記憶領域３３ａが記憶する登録情報を参照して、利用者が指定した情報提供サーバにアクセスする。例えば、収集部３４ａは、「ＩＤ：ＩＤ（１）」に対応付けられている「情報提供サーバＡ」のアドレス「ＵＲＬＡ」と、「情報提供サーバＢ」のアドレス「ＵＲＬＢ」にアクセスする。かかる場合、情報提供サーバＡ及び情報提供サーバＢそれぞれは、認証情報を要求する。認証情報の要求を受け付けた収集部３４ａは、「ＩＤ：ＩＤ（１）」とともに、「情報提供サーバＡ」及び「情報提供サーバＢ」に対する代理認証処理の要求を図１に示す代理認証部３２ｂに転送する。

代理認証部３２ｂは、「ＩＤ：ＩＤ（１）」に対応付けて設定されている認証情報を用いて、代理認証処理を行なう。例えば、代理認証部３２ｂは、「ＩＤ：ＩＤ（１）」に対応付けられている情報提供サーバＡの「ＩＤ：ＩＤ（１１）、パスワード：Ｐ（１１）」と情報提供サーバＢの「ＩＤ：ＩＤ（１２）、パスワード：Ｐ（１２）」とを、収集部３４ａを介して、「情報提供サーバＡ」及び「情報提供サーバＢ」それぞれに通知する。

かかる代理認証処理により情報収集先の情報提供サーバにて本人認証が成功した後、収集部３４ａは、利用者に関する情報を、情報収集先の情報提供サーバを収集期間に渡って繰り返し収集し、図１に示す個人情報記憶部３３の収集情報記憶領域３３ｂに格納する。

例えば、収集部３４ａは、「収集開始日：２０１１年１月１日」から「収集終了日：２０１１年１２月３１日」まで、一定期間ごとに「情報提供サーバＡ」にそれぞれアクセスして、「ＩＤ：ＩＤ（１１）」に対応付けられている利用者の医療費情報を繰り返し収集する。同様に、収集部３４ａは、「収集開始日：２０１１年１月１日」から「収集終了日：２０１１年１２月３１日」まで、一定期間ごとに「情報提供サーバＢ」にそれぞれアクセスして、「ＩＤ：ＩＤ（１２）」に対応付けられている利用者の医療費情報を繰り返し収集する。一例を挙げると、収集部３４ａは、月末ごとに、代理認証部３２ｂによる代理認証処理を行なって、情報収集先の情報提供サーバから利用者に関する情報を収集する。

これにより、収集情報記憶領域３３ｂには、利用者に関する情報が順次蓄積される。図５は、収集情報記憶領域に格納される情報の一例を説明するための図である。

例えば、収集情報記憶領域３３ｂは、図５の（Ａ）に示すように、収集部３４ａが２０１１年の１月末に情報提供サーバＡ及び情報提供サーバＢから収集した利用者の医療費情報として「２０１１年１月、医療費：５０００円」を記憶する。また、例えば、収集情報記憶領域３３ｂは、図５の（Ｂ）に示すように、収集部３４ａが２０１１年の２月末に情報提供サーバＡ及び情報提供サーバＢから収集した利用者の医療費情報として「２０１１年２月、医療費：６５００円」を追加して記憶する。

同様に、収集情報記憶領域３３ｂは、図５の（Ｃ）に示すように、収集部３４ａが２０１１年の３月末〜１２月末ごとに情報提供サーバＡ及び情報提供サーバＢから収集した利用者の医療費情報を順次追加して記憶する。

図１に示すマッチング通知部３４ｂは、収集情報記憶領域３３ｂに格納された情報が、受け付けた条件と合致しているか否かを判定する。すなわち、マッチング通知部３４ｂは、収集情報記憶領域３３ｂに新規に情報が格納されるごとに、格納された情報を参照し、属性情報記憶領域３３ａに登録された申請手続きに合致した条件となったか否かを判定する。

そして、マッチング通知部３４ｂは、収集情報記憶領域３３ｂに条件と合致する情報が格納されていると判定した場合、利用者が要望する手続きに関する条件と合致する情報が収集された旨を利用者端末装置１０に通知する。図６は、マッチング通知部の処理の一例を説明するための図である。

例えば、マッチング通知部３４ｂは、図５の（Ａ）に示す医療費情報を参照して、図６の（Ａ）に示すように、医療費合計が「５０００円」であると算出する。かかる場合、マッチング通知部３４ｂは、医療費合計が１０万円以上でないことから、登録情報の「医療費控除」に合致した条件となる情報が収集されていないと判定する。

同様に、マッチング通知部３４ｂは、図５の（Ｂ）に示す医療費情報を参照して、図６の（Ｂ）に示すように、医療費合計が「１１５００円」であると算出する。かかる場合も、マッチング通知部３４ｂは、医療費合計が１０万円以上でないことから、登録情報の「医療費控除」に合致した条件となる情報が収集されていないと判定する。

マッチング通知部３４ｂは、かかる処理を月末ごとに繰り返す。そして、例えば、マッチング通知部３４ｂは、図５の（Ｃ）に示す医療費情報を参照して、図６の（Ｃ）に示すように、医療費合計が「１００５００円」であると算出する。かかる場合、マッチング通知部３４ｂは、医療費合計が１１月末時点の「９０５００円」から１０万円以上となったことから、登録情報の「医療費控除」に合致した条件となる情報が収集されたと判定する。そして、マッチング通知部３４ｂは、属性情報記憶領域３３ａの登録情報である「通知：１＠ｘｘｘ．ｊｐ」に対して、図６の（Ｃ）に示すように、通知を行なう。例えば、マッチング通知部３４ｂは、図６の（Ｃ）に示すように、「通知：１＠ｘｘｘ．ｊｐ」宛のメール本文に「医療費控除の申請条件となりました」を記載したメールを送信する。

なお、収集期間において所定間隔で繰り返される収集部３４ａ及びマッチング通知部３４ｂの処理は、上記のように、月末ごとに行なわれる場合に限定されるものではない。例えば、収集期間において繰り返される収集部３４ａ及びマッチング通知部３４ｂの処理は、月初ごとに行なわれる場合や、１０日ごとに行なわれる場合、或いは、１日ごとに行なわれる場合であっても良い。また、収集期間における収集時期は、利用者により登録される場合であっても、情報収集システムの管理者により予め登録される場合であっても良い。

また、上述した一例では、収集期間の終了日において、利用者が登録した条件に合致した情報が収集され、利用者（利用者端末装置１０）に通知が行なわれている。しかし、収集部３４ａ及びマッチング通知部３４ｂの協同処理による自動通知サービスは、収集期間中に利用者が登録した条件に合致した情報が収集された時点で行なわれる。従って、例えば、１０月末の時点で利用者端末装置１０に通知が行なわれる場合もある。

かかる場合、利用者端末装置１０の利用者は、医療費控除の申請を行なう条件となったことを把握することができる。しかし、医療費控除の申請には、収集期間中の医療費の合計が必要となる。

そこで、本実施例は、収集部３４ａが以下の処理を行なっても良い。すなわち、収集部３４ａは、マッチング通知部３４ｂが収集情報記憶領域３３ｂに条件と合致する情報が格納されていると判定した以降も、収集期間が終了するまで情報収集処理及び情報格納処理を継続する。

このように、本実施例は、自動通知サービスが行なわれた後も、利用者による情報収集の利便性を確保するために、収集期間中の情報収集処理及び情報格納処理を継続する場合であっても良い。かかる処理により、利用者は、申請手続きの条件に合致した情報が収集されたことを把握できるとともに、申請手続きに要する全情報を収集情報記憶領域３３ｂから取得することができる。

続いて、図７及び図８を用いて、本実施例に係る情報収集システムを構成する情報収集装置３０の処理の手順を説明する。図７は、本実施例に係る情報収集装置の情報登録処理を説明するためのフローチャートであり、図８は、本実施例に係る情報収集装置の情報収集及び通知処理を説明するためのフローチャートである。

図７に示すように、本実施例に係る情報収集装置３０の登録情報受付部３１ａは、利用者端末装置１０から情報登録の要求を受け付けたか否かを判定する（ステップＳ１０１）。ここで、情報登録の要求を受け付けない場合（ステップＳ１０１否定）、登録情報受付部３１ａは、情報登録の要求を受け付けるまで待機する。

一方、情報登録の要求を受け付けた場合（ステップＳ１０１肯定）、登録情報受付部３１ａは、申請に関する情報を個人情報記憶部３３の属性情報記憶領域３３ａに登録し（ステップＳ１０２）、更に、認証情報を認証部３２に設定し（ステップＳ１０３）、登録処理を終了する。

すなわち、登録情報受付部３１ａは、利用者端末装置１０から受け付けた「情報の収集先となる情報提供サーバに関する情報」と、「情報提供サーバから情報を収集するための収集期間」と、「利用者が要望する手続きに関する条件」と「通知先」とを属性情報記憶領域３３ａに登録する。更に、登録情報受付部３１ａは、利用者端末装置１０の利用者と情報収集装置３０との間での認証情報を利用者認証部３２ａに設定する。また、登録情報受付部３１ａは、情報の収集先との間で代理認証を行なうための認証情報を代理認証部３２ｂに設定する。

そして、図８に示すように、本実施例に係る情報収集装置３０の登録情報受付部３１ａは、利用者端末装置１０から通知サービスの開始要求を受け付けたか否かを判定する（ステップＳ２０１）。ここで、通知サービスの開始要求を受け付けない場合（ステップＳ２０１否定）、登録情報受付部３１ａは、通知サービスの開始要求を受け付けるまで待機する。

一方、通知サービスの開始要求を受け付けた場合（ステップＳ２０１肯定）、登録情報受付部３１ａは、利用者端末装置１０から認証情報（利用者端末装置１０の利用者と情報収集装置３０との間での認証情報）を受け付けたか否かを判定する（ステップＳ２０２）。ここで、認証情報を受け付けない場合（ステップＳ２０２否定）、登録情報受付部３１ａは、認証情報を受け付けるまで待機する。

一方、認証情報を受け付けた場合（ステップＳ２０２肯定）、登録情報受付部３１ａの依頼により、利用者認証部３２ａは、受け付けた認証情報が設定された認証情報に一致するか否かを判定する（ステップＳ２０３）。ここで、一致しない場合（ステップＳ２０３否定）、登録情報受付部３１ａは、通知サービスを終了する。

一方、一致する場合（ステップＳ２０３肯定）、登録情報受付部３１ａは、収集部３４ａに情報収集処理を依頼する（ステップＳ２０４）。収集部３４ａは、本人認証された利用者が登録した収集期間における収集時期であるか否かを判定する（ステップＳ２０５）。ここで、収集期間における収集時期でない場合（ステップＳ２０５否定）、収集部３４ａは、収集期間における収集時期となるまで待機する。一方、収集期間における収集時期である場合（ステップＳ２０５肯定）、収集部３４ａの依頼により、代理認証部３２ｂは、情報収集先との代理認証処理を実行する（ステップＳ２０６）。

そして、収集部３４ａは、代理認証部３２ｂによる代理認証が成功したか否かを判定する（ステップＳ２０７）。ここで、代理認証が失敗した場合（ステップＳ２０７否定）、収集部３４ａは、通知サービスを終了する。

一方、代理認証が成功した場合（ステップＳ２０７肯定）、収集部３４ａは、利用者端末装置１０の利用者に関する情報であり、利用者が要望する手続きに該当する情報があるか否かを判定する（ステップＳ２０８）。ここで、該当する情報がない場合（ステップＳ２０８否定）、収集部３４ａは、ステップＳ２０５に戻って、次の収集時期となるまで待機する。

一方、該当する情報がある場合（ステップＳ２０８肯定）、収集部３４ａは、該当する情報を収集し、収集情報記憶領域３３ｂに格納する（ステップＳ２０９）。そして、マッチング通知部３４ｂは、収集情報記憶領域３３ｂに格納された情報が申請手続きの条件に合致するか否かを判定する（ステップＳ２１０）。ここで、合致しない場合（ステップＳ２１０否定）、マッチング通知部３４ｂの指示により収集部３４ａは、ステップＳ２０５に戻って、次の収集時期となるまで待機する。

一方、合致した場合（ステップＳ２１０肯定）、申請手続きの条件に合致する情報が収集された旨を、利用者端末装置１０に通知し（ステップＳ２１１）、通知サービスを終了する。

なお、収集期間が終了した時点で、申請手続きの条件に合致する情報が収集されていなかった場合、マッチング通知部３４ｂは、申請手続きの条件に合致する情報が収集されなかった旨を、登録された通知先に通知して、通知サービスを終了しても良い。また、上述したように、通知先となる装置は、登録情報によっては、利用者端末装置１０以外の装置であっても良い。

上述したように、本実施例に係る情報収集システムを構成する情報収集装置３０は、利用者自身が要望する申請手続きに関する登録を受け付けて、利用者代理で情報を収集し、申請手続きに必要となる情報を収集した時点で利用者に通知する。

図９は、本実施例の効果を説明するための図である。本実施例では、図９に示すように、利用者は、利用者端末装置１０を介して、登録処理を行なう。かかる登録処理により、情報収集装置３０は、図９に示すように、収集期間において、定期的に「医療ＷｅｂサイトＡ」及び「医療ＷｅｂサイトＢ」に複数回アクセスして、利用者代理で医療費情報を収集する。そして、情報収集装置３０は、図９に示すように、収集した医療費情報が医療費控除の条件を満たした時点で、利用者端末装置１０を介して利用者にプッシュ型で通知する。

このように、利用者が行なう処理は、申請手続きに関する情報の登録処理のみであり、図２の（Ａ）で説明した従来例のように、利用者本人が何度も、情報を提供するシステムにアクセスする必要はない。また、情報収集側では、図２の（Ｂ）で説明した従来例のように、全ての処理手続きの組み合わせをスクリプトで記述するといった用意をする必要がない。

すなわち、本実施例によれば、情報収集側で全ての手続きの組み合わせパターンを用意することなく、利用者が望む手続きの組合せを利用者自身で簡単に構成することができる。また、本実施例によれば、利用者自身が何度も情報収集先にアクセスする必要がない。また、本実施例によれば、利用者本人が収集したい情報が一元的に保存され、収集処理を行なう装置側で収集された情報内容を把握できる。また、本実施例によれば、利用者は、申請手続きに必要な情報が揃っていることを、タイムリーに知ることができる。

従って、本実施例によれば、申請手続きのための情報収集に際し、利用者の利便性を簡易に向上させることができる。

また、情報収集装置３０は、申請手続きに関する情報として情報収集先の認証情報を受け付けることで、利用者に代わって、情報収集先との間で代理認証処理を行なう。従って、本実施例によれば、申請手続きのための情報収集における安全性を確保することができる。

また、本実施例は、通知サービス終了以降も、収集期間が終了するまで情報収集処理及び情報格納処理を継続する場合であっても良いので、申請手続きのための情報収集に際し、利用者の利便性を向上させることができる。

なお、上記の通知サービスが適用される申請としては、上記の医療費控除の申請以外にも、様々な適用例がある。例えば、上記の通知サービスが適用される申請としては、住宅ローンの繰越返済の申請などがある。かかる場合、情報収集装置３０は、年金システムに年金の配布金額を繰り返し収集し、合計金額が所定の金額（例えば、５０万円）となった時点で利用者の通知先に通知し、通知された利用者が住宅ローンを組んだ金融機関のシステムに繰越返済の申請を行なう。

ところで、本実施例で説明した情報収集方法は、上記のように、１台の装置で実行される場合に限定されるものではない。例えば、本実施例で説明した情報収集方法は、受付部３１、認証部３２、個人情報記憶部３３及び情報処理部３４の機能を有する各装置（サーバ）により分散して実行される場合であっても良い。

すなわち、上記の本実施例の説明に用いた図面に示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、マッチング通知部３４ｂは、マッチング部（判定部）と通知部との２つの処理部に分離される場合であっても良い。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

また、上記実施例で説明した情報収集方法は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのＩＰネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、ＭＯ（Magneto-Optical disk）、ＤＶＤ（Digital Versatile Disk）などのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。

１０ 利用者端末装置
２０ 情報提供サーバ群
３０ 情報収集装置
３１ 受付部
３１ａ 登録情報受付部
３１ｂ 通知サービス受付部
３２ 認証部
３２ａ 利用者認証部
３２ｂ 代理認証部
３３ 個人情報記憶部
３３ａ 属性情報記憶領域
３３ｂ 収集情報記憶領域
３４ 情報処理部
３４ａ 収集部
３４ｂ マッチング通知部

Claims (4)

1. 利用者が利用する利用者端末装置から情報の収集先となる情報提供装置の指定と、当該情報提供装置から情報を収集するための収集期間と、前記利用者が要望する手続きに関する条件と、前記利用者への通知先とを受け付ける受付部と、
   前記利用者が指定した情報提供装置から、当該利用者に関する情報を前記収集期間にわたって繰り返し収集し、記憶部に格納する収集部と、
   前記記憶部に格納された情報が、前記受付部が受け付けた条件と合致しているか否かを判定する判定部と、
   前記判定部により前記記憶部に前記条件と合致する情報が格納されていると判定された場合、前記利用者が要望する手続きに関する条件と合致する情報が収集された旨を前記利用者への通知先に通知する通知部と、
   を備えたことを特徴とする情報収集システム。
2. 前記収集部による情報収集処理を開始する前に、前記利用者が指定した情報提供装置へアクセスするための認証情報を用いて、前記利用者が指定した情報提供装置との間で、前記利用者端末装置に代わって認証手続きを行なう代理認証部、
   を更に備え、
   前記受付部は、更に、前記利用者端末装置から前記認証情報を受け付けること、
   を特徴とする請求項１に記載の情報収集システム。
3. 前記収集部は、前記判定部により前記記憶部に前記条件と合致する情報が格納されていると判定された以降も、前記収集期間が終了するまで情報収集処理及び情報格納処理を継続することを特徴とする請求項１又は２に記載の情報収集システム。
4. 利用者が利用する利用者端末装置に接続される情報収集装置によって実行される情報収集方法であって、
   前記利用者端末装置から情報の収集先となる情報提供装置の指定と、当該情報提供装置から情報を収集するための収集期間と、前記利用者が要望する手続きに関する条件と、前記利用者の通知先とを受け付ける受付ステップと、
   前記利用者が指定した情報提供装置から、当該利用者に関する情報を前記収集期間にわたって繰り返し収集し、記憶部に格納する収集ステップと、
   前記記憶部に格納された情報が、前記受付部が受け付けた条件と合致しているか否かを判定する判定ステップと、
   前記判定ステップにより前記記憶部に前記条件と合致する情報が格納されていると判定された場合、前記利用者が要望する手続きに関する条件と合致する情報が収集された旨を前記利用者への通知先に通知する通知ステップと、
   を含んだことを特徴とする情報収集方法。

Images