JP2007316773A

JP2007316773A - 住所管理システム

Info

Publication number: JP2007316773A
Application number: JP2006143429A
Authority: JP
Inventors: Fumiaki Honma; 史明本間; Tomoyuki Kokubu; 知幸國分; Kazuyuki Ikejima; 一幸池嶋; Tatsuya Kusano; 達也草野
Original assignee: Promise Co Ltd
Current assignee: Promise Co Ltd
Priority date: 2006-05-23
Filing date: 2006-05-23
Publication date: 2007-12-06

Abstract

【課題】住民票データの請求及び登録を自動化し、顧客の住所を確実且つ効率的に管理する。
【解決手段】請求サーバ１４は、まず請求の対象となる顧客を所定の抽出条件に基づいて抽出し（Ｓ１０１）、住民票データの請求先となる役所サーバ１９を選定した後（Ｓ１０２）、住民票データを請求するための住民票請求データを作成する（Ｓ１０３）。次に、住民票データの請求に必要な所定の手数料を指定の銀行口座に振り込んだ後（Ｓ１０４）、振込時に得られた振込番号を住民票請求データに追加し、住民票請求データを役所サーバ１９に送信する（Ｓ１０５）。役所サーバ１９は住民票請求データを処理し（Ｓ１０６）、その請求に対する回答データを送信する。回答データを受信した請求サーバ１４は、この回答データに含まれる顧客識別コードを用いて住民票データベース１２にアクセスし、属性履歴データベースや住民票データベースを更新する（Ｓ１０７、Ｓ１０８）。
【選択図】図６

Description

本発明は、住所管理システムに関し、特に、住民票データを利用して住所を管理する住所管理システムに関するものである。

個人融資を行っている金融機関等では、顧客情報をデータベースで管理しており、延滞のお知らせ等、顧客への重要書類の送付を行う場合には、データベース内の住所情報を用いて各支店が個別に送付処理を行っている。しかし、顧客が住所を変更している場合には、データベースに登録された住所に書類を送付したとしても転居先不明により返送されてしまい、顧客に書類を受け取らせることができない場合がある。そのような場合は、電話等にて顧客と連絡を取る努力をするが、どうしても連絡を取れない場合には、役所へ顧客の住民票の写しを請求し、顧客の現住所を確認する作業が行われている。

一方、近年は住民基本台帳ネットワーク（以下、「住基ネット」という）の導入により、行政システムのＩＴ化が進みつつある。これにより、住民票の写しを請求する者は、住民票の写しの交付を受けるために管轄の市区町村の役所窓口までわざわざ出向かなくても、近隣の役所窓口から手続を行うことが可能となっている。また、住民票の写し等の証明書を自動発行するシステムも存在している（例えば、特許文献１参照）。この種のシステムは、請求の対象となる者の住民票データを住民票台帳データベースから検索し、当該住民票データを所定のフォーマットにて印刷・発行するものである。
特開２００３−１０８６９４号公報

金融機関等が住民票の写しを請求する場合、支店ごとに請求の対象となる顧客を抽出した後、各市区町村の役所と郵便でやりとりしているため、多数の顧客の住民票の写しを請求した場合には、非常に多くの手間や時間がかかるだけでなく、郵送先を間違えるおそれもあるため、個人情報の漏洩にもつながるという問題がある。また、顧客が住所を何度も変更している場合、同じ顧客の住民票を何度も請求しなければならないという問題もある。

一方、住基ネットによれば、任意の市区町村の役所窓口で顧客の住民票の写しを請求することも可能であるが、請求した住所に顧客が籍を置いたことがない場合には、たとえ住基ネットであっても住民票の写しを提供することができない。このような場合、顧客が届け出ている可能性のある別の住所で住民票の写しを新たに請求し直さなければならいため、現住所にたどり着くまでには、たとえ住基ネットが構築されていたとしても手間と時間がかかることに変わりはない。

したがって、本発明の目的は、住民票データの請求及び登録を自動化し、顧客の住所を確実且つ効率的に管理することが可能な住所管理システムを提供することにある。

本発明の上記目的は、少なくとも顧客の住所を含む属性情報の履歴を管理する属性履歴データベースと、顧客の住民票データの履歴を管理する住民票データベースと、住民票データを保有する役所サーバとネットワークを介して接続可能な請求サーバとを備え、請求サーバは、属性履歴データベース又は住民票データベースの情報を用いて顧客の住民票請求データを作成する住民票請求データ作成部と、住民票請求データを役所サーバに送信すると共に、役所サーバからの回答データを受信する送受信部と、住民票データの請求に先立ち、当該請求に必要な所定の手数料の振込処理をインターネット上で行う振込処理部を備え、住民票請求データ作成部は、役所サーバ側において手数料の納付確認に必要な所定の識別番号を住民票請求データに含めることを特徴とする住所管理システムによって達成される。この場合、所定の識別番号は、手数料の振込時に受け取った振込番号であることが好ましい。振込番号を用いた場合には、他の特別なデータを用意することなく、役所サーバ側で振込状況を確認することができる。

本発明において、送受信部は、認証局より発行された電子証明書を住民票請求データと共に送信することが好ましい。これによれば、住民票請求データの信頼性を確保することができる。

本発明によれば、住民票データの請求時に必要な手数料の納付を一連の請求処理と関連させて自動で行うことができる。したがって、住民票データの請求及び登録を自動化し、顧客の住所を確実且つ効率的に管理することが可能な住所管理システムを提供することができる。

以下、添付図面を参照しながら、本発明の好ましい実施の形態について詳細に説明する。

図１は、本発明の好ましい実施形態に係る住所管理システム１０の構成を示す模式図である。

図１に示すように、住所管理システム１０は、顧客の属性情報の履歴を管理する属性履歴データベース１１と、顧客の住民票データの履歴を管理する住民票データベース１２と、全国の役所に関する情報が登録された役所データベース１３と、属性履歴データベース１１、住民票データベース１２及び役所データベース１３の情報をもとに住民票データを請求する請求サーバ１４と、請求サーバ１４に接続されたオペレータ端末１５とを備えている。請求サーバ１４は、インターネット１６を介して銀行システム１７、認証局１８及び役所サーバ１９に接続されている。銀行システム１７は、インターネット上で銀行業務を行ういわゆるインターネットバンキングシステムである。認証局１８は、電子証明書を発行し、通信相手が本人（ここでは金融機関Ｘ）であることを証明するインターネット上の第三者機関である。役所サーバ１９（１９Ａ乃至１９Ｃ）は、住民票データを管理するサーバであって、市区町村単位で構成されており、これらは住基ネット２０を介して相互に接続されている。

図２は、属性履歴データベース１１の構成を示す模式図である。

図２に示すように、属性履歴データベース１１には、新規登録時から現在までの顧客の属性情報の履歴が登録されている。顧客の属性情報は「顧客識別コード」を用いて顧客単位で管理されており、属性情報としては、主に「登録年月日」、「顧客識別コード」、「氏名」、「生年月日」、「性別」、「住所」、「電話番号」、「勤務先情報」等を挙げることができる。また、属性履歴データベース１１には、融資に関する基本契約書（以下、単に「契約書」という）のイメージデータなども登録されており、この契約書には、住民票の写しや戸籍の附票を本人以外の者が請求する場合に要求されることがある委任状の要素が含まれている。なお、属性情報はこれらに限定されるものではなく、顧客に関する他のどのような情報であってもよい。また、婚姻等によって氏名が変更となった場合や、転居によって住所や電話番号が変更となった場合には、主として顧客の申告により、その変更内容が変更年月日と共に登録される。なお、属性履歴データベース１１に登録された情報は原則として顧客の自己申告によるものであり、例えば住所について言えば、住民票に登録された住所と必ずしも一致するものではない。

図３は、住民票データベース１２の構成を示す模式図である。

図３に示すように、住民票データベース１２には、新規登録時から現在までに取得された顧客の住民票データの内容が登録されている。また、住民票を請求したが、除票等により最終居住地を確認できなかった場合にも、その旨が住民票データベース１２に登録される。住民票データは「顧客識別コード」を用いて顧客単位で管理されており、住民票データとしては、主に、「請求年月日」、「氏名」、「住所」、「転出予定先住所」、「除票理由」等を挙げることができるが、これらに限定されるものではない。なお、住民票データの請求は、居所不明な場合等、必要な場合にのみ行われるので、すべての顧客の住民票データが必ず存在しているわけではなく、顧客によっては住民票データが全く存在しない場合もある。

図４は、役所データベース１３の構成の一例を示す模式図である。

図４に示すように、役所データベース１３には、「都道府県名」４１、「市区町村名」４２、全国の市区町村に割り振られている「住所コード」４３、各市区町村を管轄する役所サーバ１９のアドレス情報（「役所サーバアドレス」）４４、各役所において住民票の請求時に要求される「役所要求データ」４５が登録されている。

図５は、請求サーバ１４の構成を機能的に示すブロック図である。

図５に示すように、請求サーバ１４は、住民票データの請求の対象となる顧客を所定の抽出条件に基づいて抽出する顧客抽出部５１と、属性履歴データベース１１や住民票データベース１２の情報を用いて顧客の住民票請求データを作成する住民票請求データ作成部５２と、住民票データの請求に先立ち、住民票データの請求に必要な所定の手数料の振込処理をインターネット上で行う振込処理部５３と、役所サーバ１９に住民票請求データ等を送信すると共に、役所サーバ１９からの回答データ等を受信する送受信部５４と、回答データを処理して種々の判定を行う判定部５５と、回答データの内容を属性履歴データベース１１や住民票データベース１２に記録する記録部５６とを備えている。判定部５５は、回答データの住所が住民票請求データの住所と異なるか否かを判定したり、回答データに転出予定先住所があるか否かを判定したりするなど、回答データに対する種々の判定処理を行う。なお、図示の各部は物理的に別個の構成要素である必要はなく、コンピュータがプログラムを実行することによって達成される機能であってもよい。

上述した顧客への書類送付業務においては、属性履歴データベース１１に記録された顧客の最新の住所（現住所）が利用されるが、何らかの理由で現住所を確認する必要がある場合には住民票データの請求が行われる。「住民票データ」とは、役所窓口で書面にて交付される「住民票の写し」に相当する電子データである。なお、本発明において、「住民票」とは、役所で登録されている住民票だけでなく、戸籍の附票などの役所で登録されているその他の書類も含む概念である。以下、図６のフローチャートを参照しながら、住民票データの請求手順について詳細に説明する。

住民票データを請求する場合、請求サーバ１４は、まず請求の対象となる顧客を所定の抽出条件に基づいて抽出する（Ｓ１０１）。抽出条件としては、例えば、顧客の居所不明が判明した日から一定期間を経過した場合を挙げることができる。郵送書類が転居先不明で返送されてきた場合など、顧客の居所不明が判明した場合にはその旨が属性履歴データベース１１に登録され、請求サーバ１４がその情報をもとに期限を監視することにより請求対象者が抽出される。また、住民票データベース１２に登録された最新の住民票データ（図３の第Ｙ回請求）の請求日から一定期間を経過した場合や、当該住民票データの請求結果を抽出条件としてもよく、さらには顧客の現住所を抽出条件とすることもできる。例えば、前回請求した住民票データが転出予定を示すものであり、且つ住所が「東京都千代田区」である顧客について、前回の住民票データの請求日から一定期間を経過した場合を請求の対象として抽出することも可能である。また、本システムを顧客の債権管理に利用する場合には、請求サーバ１４とは別に債権管理サーバ（不図示）を用意し、債権管理サーバが顧客の債権状況を監視し、延滞が一定期間経過した顧客や請求残高が一定額を超えた顧客を住民票請求の対象として抽出し、請求サーバ１４に対して住民票データの請求処理を開始するよう要求してもよい。

次に、請求サーバ１４は、住民票データの請求先となる役所サーバ１９を選定する（Ｓ１０２）。役所サーバ１９の選定には役所データベース１３が利用され、属性履歴データベース１１に示された顧客の現住所をもとに役所サーバアドレスが決定される。

次に、請求サーバ１４は、住民票データを請求するための住民票請求データを作成する（Ｓ１０３）。住民票請求データは、役所窓口で書面にて提出する「住民票の写しの交付請求書」に相当する電子データであって、図７に示すように、役所サーバ１９が要求する所定のフォーマットを有し、「請求データＮｏ．」７１、「振込番号」７２、「氏名」７３、「生年月日」７４、「住所」７５、「役所要求データ」７６、「要求形式（単票・履歴）」７７、「顧客識別コード」７８等の情報が含まれている。「役所要求データ」７６は、住民票データの請求時に役所サーバから要求されるデータであり、具体的には住民票データの請求に関する契約書のイメージデータである。ただし、請求先によっては必要でない場合もあるため、その場合は空欄となる。なお、住民票請求データには、ユーザが自由に使用可能なデータ領域（ユーザ領域）が確保されており、「顧客識別コード」７８はそのような領域に記録されていている。「振込番号」７２は、後述する振込処理が完了した後に補充される。

次に、請求サーバ１４は、住民票データの請求に先立ち、銀行システム１７にアクセスし、住民票データの請求に必要な所定の手数料を指定の銀行口座に振り込む（Ｓ１０４）。このとき、請求サーバ１４は銀行システム１７から振込番号の通知を受けるが、振込番号は住民票請求データに追加され、後述する振込状況の確認に利用される。

次に、請求サーバ１４は住民票請求データを送信する（Ｓ１０５）。住民票請求データは、認証局１８が発行する電子証明書とともに、管轄の役所サーバ１９（例えば、役所サーバ１９Ａ）に送信される。

次に、住民票請求データを受信した役所サーバ１９は、住民票請求データを処理し（Ｓ１０６）、その請求に対する回答データを送信する。

図８は、役所サーバ１９による処理手順を示すフローチャートである。

図８に示すように、役所サーバ１９は、まず住民票請求データに含まれる電子証明書を認証局１８に照会し、電子証明書の有効性とその金融機関Ｘであるか否かを確認する（Ｓ２０１）。電子証明書が有効であり、請求元の金融機関と電子証明書の金融機関が合致した場合（Ｓ２０２Ｙ）、役所サーバ１９は、住民票請求データに示された「振込番号」７２を用いて手数料の振込状況を確認する（Ｓ２０３）。所定の手数料の振込を確認できた場合（Ｓ２０４Ｙ）、役所サーバ１９は、役所要求データを要求している場合に限り、役所要求データの有無を確認する（Ｓ２０５Ｙ、Ｓ２０６）。役所要求データが不要な場合（Ｓ２０５Ｎ）又は役所要求データが添付されている場合（Ｓ２０７Ｙ）、役所サーバ１９は、顧客の住民票を検索し、住民票が存在する場合には、回答データとして住民票データを作成する（Ｓ２０８Ｙ、２０９）。

一方、電子証明書が有効でない場合、または電子証明書の金融機関と請求元の金融機関が相違する場合（Ｓ２０２Ｎ）、所定の手数料の納付を確認できない場合（Ｓ２０４Ｎ）、及び必要な役所要求データが添付されていない場合（Ｓ２０７Ｎ）には、役所サーバ１９は、回答データとしてそれぞれのエラーコードを作成する（Ｓ２１２、Ｓ２１３、Ｓ２１４）。また、該当する住民票が存在しない場合、役所サーバ１９は、その旨を示す回答データを作成する（Ｓ２０８Ｎ、Ｓ２１５）。

その後、役所サーバ１９は、住民票請求データに含まれている「顧客識別コード」７８を回答データに付与した後、回答データを請求サーバ１４に送信する（Ｓ２１０、Ｓ２１１）。

回答データを受信した請求サーバ１４は、この回答データの内容に基づいてデータベースを更新する（Ｓ１０７、Ｓ１０８）。

図９は、回答データとして住民票データを受信したときの処理手順を示すフローチャートである。

図９に示すように、請求サーバ１４は、回答データに含まれる顧客識別コードを用いて住民票データベース１２にアクセスし（Ｓ３０１）、回答データを住民票データベース１２に記録する（Ｓ３０２）。次に、請求サーバ１４は、回答データの内容を確認し（Ｓ３０３）、回答データが住民票データであり、かつ除票を示すものでない場合には（Ｓ３０４Ｙ、Ｓ３０５Ｎ）、顧客識別コードを用いて属性履歴データベース１１にアクセスし（Ｓ３０６）、住民票データの住所と属性履歴データベース１１の現住所とを比較する（Ｓ３０７）。そして、両者が一致しない場合には（Ｓ３０８Ｎ）、オペレータ端末１５のディスプレイに属性履歴データベース１１の住所変更について許可を求める変更確認画面を表示させる（Ｓ３０９）。変更確認画面は、図１０に示すように、「属性履歴データベースの現住所」８１、「住民票データの住所」８２、「変更」ボタン８３及び「キャンセル」ボタン８４により構成され、「変更」ボタン８３がクリックされたとき（Ｓ３１０）、請求サーバ１４は属性履歴データベース１１の現住所を住民票データの住所に置き換え、それまでの現住所を過去の住所として記録する（Ｓ３１１）。

一方、回答データが転出による除票を示す場合（Ｓ３０４Ｙ、Ｓ３０５Ｙ、Ｓ３１２Ｙ）、請求サーバ１４は、回答データに示された転出先住所をもとに住民票請求データを新たに作成し、転出先住所を管轄する役所サーバ１９（例えば、役所サーバ１９Ｂ）に対して住民票データを再請求する（Ｓ３１３）。なお、再請求手順は、図６のステップＳ１０３以降に示したものと略同様である。

以上説明したように、本実施形態によれば、請求サーバ１４が請求の対象となる顧客を一定条件下で抽出し、次に請求先となる役所サーバ１９を選定し、当該役所サーバ１９に対して所定の住民票請求データを送信するので、従来、各支店で個別に行っていた住民票の写しの請求作業を一括で行うことができ、各支店での作業負担を大幅に軽減することができる。また、支店ごとに手作業で郵送により行っていた住民票の写しの請求作業を自動化することができ、住民票の写しを請求してから取得するまでにかかる時間を大幅に短縮することができる。さらに、役所側における住民票の交付時の封入ミスや送付ミス、書面にて交付される住民票の写しの記載内容を電子化する際の入力ミスを回避することもでき、顧客情報の漏洩を防止することもできる。したがって、住民票データの請求及び登録を自動化することができ、顧客の住所を確実且つ効率的に管理することができる。

また、本実施形態によれば、住民票請求データに振込番号を含め、納付確認が得られた場合には、住民票データが役所サーバ１９からオンラインで配信されるので、住民票データの請求時に必要な手数料の納付を一連の請求処理と連動させて自動で行うことができる。特に、手数料の納付確認に必要な所定の識別番号として振込番号を用いた場合には、他の特別なデータを用意することなく、役所サーバ側で振込状況を確認することができる。

また、本実施形態によれば、住民票請求データに電子証明書をさらに含め、電子証明書が有効であり、請求元の金融機関と電子証明の金融機関が合致し、かつ納付確認が得られた場合には、住民票データが役所サーバ１９からオンラインで配信されるので、住民票データの不正な請求を確実に防止することができる。

また、本実施形態によれば、住民票請求データに顧客識別コードを含めて送信し、役所サーバ１９側ではこの顧客識別コードを回答データに含めて返信するので、請求サーバ１４側では顧客識別コードを用いて属性履歴データベースや住民票データベースの内容を一意に特定することができ、住所の登録、確認、更新等を容易に行うことができる。

本発明は、以上の実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲内で種々の変更を加えることが可能であり、これらも本発明の範囲に包含されるものであることは言うまでもない。

例えば、上記実施形態においては、住民票請求データに顧客識別コードを含める場合について説明したが、本発明はこのような場合に限定されるものではなく、住民票請求データに顧客識別コードを含めないようにすることも可能である。この場合、回答データの「氏名」、「住所」及び「生年月日」から顧客識別コードを検索した後、顧客の属性情報を特定することができる。

また、上記実施形態においては、住民票請求データに契約書等の役所要求データが含まれてない場合、役所サーバ１９は回答データとしてエラーコードを直ちに送信しているが、エラーコードを送信する前に、役所サーバ１９から請求サーバ１４に対し、役所要求データの必要通知を送信してもよい。この場合、役所要求データの必要通知を受信した請求サーバ１４が役所サーバ１９に役所要求データを一定期間内に返信することにより、役所サーバ１９によるその後の処理が進められ、回答データが送信される。さらに、役所要求データの必要通知を受けた請求サーバ１４は、住民票データベース１２内に含まれる「役所要求データ」４５の内容を自動的に更新してもよい。このようにすれば、役所要求データの登録が常に最新の状態となるので、その後の処理において役所要求データの送信の不備を確実に防止することができる。

また、上記実施形態においては、住民票データの請求時に必要な役所要求データとして住民票の請求に関する契約書のイメージデータを例に挙げたが、金融機関への借入状況を示す顧客の利用残高データであってもよい。これによれば、住民票データの請求の目的の証明がさらに容易となる。

また、上記実施形態においては、図９のステップＳ３０７〜Ｓ３１１及び図１０に示したように、受信した住民票データの住所と属性履歴データベースの現住所とを比較し、両者が一致しない場合にはオペレータ端末１５上に変更確認画面を表示し、変更確認画面上で変更の指示があった場合に属性履歴データベースを書き換えているが、ステップＳ３０９〜Ｓ３１０を省略し、住民票データの住所と属性履歴データベースの現住所とが一致しない場合に、住民票データの住所を用いて属性履歴データベースを自動的に更新するようにしてもよい。

図１は、本発明の好ましい実施形態に係る住所管理システム１０の構成を示す模式図である。図２は、属性履歴データベース１１の構成を示す模式図である。図３は、住民票データベース１２の構成を示す模式図である。図４は、役所データベース１３の構成を示す模式図である。図５は、請求サーバ１４の構成を機能的に示すブロック図である。図６は、住所管理システム１０による住民票データの請求手順の一例を詳細に示すフローチャートの一部である。図７は、住民票請求データの構成を示す図である。図８は、役所サーバ１９による処理手順を示すフローチャートである。図９は、回答データとして住民票データを受信したときの処理手順を示すフローチャートである。図１０は、オペレータ端末１５のディスプレイに表示される変更確認画面の構成を示す図である。

符号の説明

１０住所管理システム
１１属性履歴データベース
１２住民票データベース
１３役所データベース
１４請求サーバ
１５オペレータ端末
１６インターネット
１７銀行システム
１８認証局
１９役所サーバ
１９Ａ〜１９C 役所サーバ
２０住基ネット
４１「都道府県名」データ
４２「市区町村名」データ
４３「住所コード」
４４「役所サーバアドレス」
４５「役所要求データ」
５１顧客抽出部
５２住民票請求データ作成部
５３振込処理部
５４送受信部
５５判定部
５６記録部
７１「請求データＮｏ．」データ
７２「振込番号」データ
７３「氏名」データ
７４「生年月日」データ
７５「住所」データ
７６「役所要求データ」
７７「要求形式（単票・履歴）」データ
７８「顧客識別コード」
８０変更確認画面
８１属性履歴データベースの現住所
８２住民票データの住所
８３「変更」ボタン
８４「キャンセル」ボタン

Claims

少なくとも顧客の住所を含む属性情報の履歴を管理する属性履歴データベースと、
顧客の住民票データの履歴を管理する住民票データベースと、
住民票データを保有する役所サーバとネットワークを介して接続可能な請求サーバとを備え、
前記請求サーバは、
前記属性履歴データベース又は前記住民票データベースの情報を用いて前記顧客の住民票請求データを作成する住民票請求データ作成部と、
前記住民票請求データを前記役所サーバに送信すると共に、前記役所サーバからの回答データを受信する送受信部と、
前記住民票データの請求に先立ち、当該請求に必要な所定の手数料の振込処理をインターネット上で行う振込処理部を備え、
前記住民票請求データ作成部は、役所サーバ側において手数料の納付確認に必要な所定の識別番号を前記住民票請求データに含めることを特徴とする住所管理システム。
前記所定の識別番号は、前記手数料の振込時に受け取った振込番号であることを特徴とする請求項１に記載の住所管理システム。
前記送受信部は、認証局より発行された電子証明書を前記住民票請求データと共に送信することを特徴とする請求項１又は２に記載の住所管理システム。