公金収納管理システム、公金収納管理方法及び公金収納管理用プログラム
【課題】納付者が様々な公金取扱機関を介して公金の納付手続をしたことに起因して発生する種々の納付情報を自治体の側での取扱いが容易となるように自治体へ送る。
【解決手段】公金収納管理システム１０は、公金を収納するために必要な情報を自治体から受け取る基本情報受取手段、基本情報受取手段が受け取った情報を案件毎に記録する基本情報記録手段、納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報を公金取扱機関から受け取る納付情報受取手段、基本情報記録手段が情報を記録した案件のうち納付情報受取手段が納付情報を受け取った案件について納付情報受取手段が受け取った納付情報に基いて自治体へ報告する情報を所定の統一された形式で作成する報告情報作成手段、報告情報作成手段が作成した情報を自治体へ送る報告情報送り手段を備える。
【解決手段】公金収納管理システム１０は、公金を収納するために必要な情報を自治体から受け取る基本情報受取手段、基本情報受取手段が受け取った情報を案件毎に記録する基本情報記録手段、納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報を公金取扱機関から受け取る納付情報受取手段、基本情報記録手段が情報を記録した案件のうち納付情報受取手段が納付情報を受け取った案件について納付情報受取手段が受け取った納付情報に基いて自治体へ報告する情報を所定の統一された形式で作成する報告情報作成手段、報告情報作成手段が作成した情報を自治体へ送る報告情報送り手段を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、税金や公共料金等の公金の収納を管理するためのシステム、方法及びプログラムに関し、コンピュータを用いた情報処理の技術分野に属する。
【背景技術】
【０００２】
従来、コンピュータを用いて、自治体が徴収する自動車税や固定資産税あるいは水道料金等の公金の収納を管理する技術が知られている。例えば、特許文献１には、自治体から送信された公金徴収情報に基いて納付義務者毎の公金徴収データを生成し、前記公金徴収データに各データを特定するコード情報を付与した後、前記公金徴収データを反映させた納入通知書を印刷する総合収納管理システムが開示されている。
【０００３】
この総合収納管理システムは、公金納付情報を収納情報としてデータ蓄積手段に蓄積するようになっており、前記納入通知書を受け取った納付義務者が該納入通知書に従って納付をしたときに、その公金納付情報を公金取扱機関から取得し、前記公金納付情報と同内容の収納情報が既にデータ蓄積手段に蓄積されているか否かを照会する。そして、蓄積されていないときは、前記公金納付情報を収納情報としてデータ蓄積手段に蓄積する一方で、蓄積されているときは、２回目の公金納付になるため、収納処理を停止し、これにより、複数の公金取扱機関を介しての公金収納に対応可能であり、かつ公金の二重収納の防止が図られた公金収納管理システムが実現されている。
【０００４】
【特許文献１】特開２００６−９９５０８（段落００２１〜００２３、００２６、００５５）
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ところで、この種の公金収納管理システムは、一般に、自治体と公金取扱機関との間にあって、自治体側と公金取扱機関側との双方から発せられた種々の情報が集中する。したがって、受け取った情報をいったんシステム内に溜め置き、整理し、その中から必要な情報を、必要とする側へ、適正な時期に送ることが望まれている。特に、近年は、納付機会の拡大、納付率の向上及び納付者便宜の増大を図るため、銀行や郵便局等の金融機関の窓口だけでなく、コンビニエンスストアや、インターネットバンキング及びクレジットカードのＷＥＢサイト等、納付者が公金の納付に用いることができる公金取扱機関の種類が増えているので、さらに多方面からの情報の集中が著しい傾向にある。
【０００６】
一方、自治体の側では、督促状の準備や消込作業の準備のために、どの納付者のどの公金がどの公金取扱機関を介していつ納付手続されたか、そしてそれによりいつ自治体の口座へ資金が移動するかといった、納付者が公金の納付手続をしたことに起因して発生する種々の納付情報を必要としている。このような状況の下、公金収納管理システムが、公金取扱機関から受け取った納付情報を公金取扱機関毎に異なる形式で自治体へ送っていたのでは、自治体が受け取る納付情報の形式がバラバラとなり、その結果、自治体の側で納付情報の取扱いが極めて不便なものとなって、当該公金収納管理システムの信頼性ないし商品性が損なわれてしまう、という問題がある。
【０００７】
そこで、本発明は、納付者が様々な公金取扱機関を介して公金の納付手続をしたことに起因して発生する種々の納付情報を自治体の側での取扱いが容易となるように自治体へ送ることが可能な公金収納管理システム、公金収納管理方法及び公金収納管理用プログラムの提供を課題とする。
【０００８】
また、前述したように、この種の公金収納管理システムは、自治体からの情報及び公金取扱機関からの情報が集中するので、納付者個人の重要情報が不用意に漏洩しないように対策する必要がある。さらに、納付者が自己の公金の納付手続が済んでいるか否かの問合せを公金取扱機関や自治体にする場合があり、そのときの問合せに円滑に対応できるように対策する必要もある。
【０００９】
そこで、本発明は、納付者個人の重要情報が不用意に漏洩しないように対策すること、及び、納付者からの問合せに円滑に対応できるように対策することも課題とする。
【課題を解決するための手段】
【００１０】
前記課題を解決するため、本発明では次のような手段を用いる。
【００１１】
まず、請求項１に記載の発明は、自治体の公金収納を管理するシステムであって、公金を収納するために必要な情報を自治体から受け取る基本情報受取手段、この基本情報受取手段が受け取った情報を案件毎に記録する基本情報記録手段、納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報を前記公金取扱機関から受け取る納付情報受取手段、前記基本情報記録手段が情報を記録した案件のうち、前記納付情報受取手段が納付情報を受け取った案件について、該納付情報受取手段が受け取った納付情報に基いて、自治体へ報告する情報を所定の統一された形式で作成する報告情報作成手段、及び、この報告情報作成手段が作成した情報を自治体へ送る報告情報送り手段が備えられていることを特徴とする。
【００１２】
次に、請求項２に記載の発明は、請求項１に記載の公金収納管理システムであって、前記報告情報作成手段は、納付者がいずれの公金取扱機関を介して公金の納付手続をしたかを含む情報を作成すると共に、納付者がインターネットバンキング又はクレジット決済による公金取扱機関を介して公金の納付手続をした場合であっても、納付者の口座情報及びクレジットカード情報を含まない情報を作成することを特徴とする。
【００１３】
次に、請求項３に記載の発明は、請求項１又は２に記載の公金収納管理システムであって、前記納付情報受取手段が受け取った納付情報を案件毎に記録する納付情報記録手段、公金の納付手続が済んでいるか否かの問合せを受け付ける問合せ受付手段、この問合せ受付手段が問合せを受け付けた案件毎に前記納付情報記録手段が記録した納付情報を検索する納付情報検索手段、この納付情報検索手段が検索した納付情報に基いて回答情報を作成すると共に、前記問合せ受付手段が受け付けた問合せが、公金取扱機関を経由した納付者からの問合せであるときは、納付者に関する情報のうち特定の情報を含まない回答情報を作成し、前記問合せ受付手段が受け付けた問合せが、自治体を経由した納付者からの問合せであるときは、納付者の口座情報及びクレジットカード情報を含まない回答情報を作成する回答情報作成手段、及び、この回答情報作成手段が作成した回答情報を公金取扱機関又は自治体へ送る回答情報送り手段が備えられていることを特徴とする。
【００１４】
次に、請求項４に記載の発明は、請求項１から３のいずれかに記載の公金収納管理システムであって、前記基本情報記録手段が記録した情報に基いて納付者へ送る納付通知書を作成する納付通知書作成手段が備えられていることを特徴とする。
【００１５】
次に、請求項５に記載の発明は、請求項４に記載の公金収納管理システムであって、前記基本情報記録手段が情報を記録した案件毎に、案件を特定するコードを乱数を用いて設定する案件特定コード設定手段が備えられ、前記納付通知書作成手段は、この案件特定コード設定手段が設定したコードを付した納付通知書を作成することを特徴とする。
【００１６】
次に、請求項６に記載の発明は、請求項１から５のいずれかに記載の公金収納管理システムであって、前記納付情報受取手段は、納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報として、納付者が公金取扱機関を介して公金の納付手続をしたという手続情報及び自治体の口座へ入金する資金が準備されたという確認情報の２種類の情報を相前後して受け取り、前記報告情報作成手段は、前記納付情報受取手段が前記手続情報を受け取った時点で、該手続情報に基いて、納付者が公金の納付手続をしたことを自治体へ連絡する旨の情報を作成し、前記報告情報送り手段は、前記報告情報作成手段が前記情報を作成した時点で、該情報を自治体へ送ることを特徴とする。
【００１７】
なお、前記請求項１〜６に記載の公金収納管理システムの各手段は、コンピュータの中央処理装置、入力装置、出力装置、通信装置、記録装置等のハードウエア資源と、これらのハードウエア資源を用いて各手段の動作を実現するプログラムとによって構成される。
【００１８】
次に、請求項７に記載の発明は、自治体の公金収納を管理する方法であって、コンピュータを用いて、公金を収納するために必要な情報を自治体から受け取る基本情報受取工程、この基本情報受取工程で受け取った情報を案件毎に記録する基本情報記録工程、納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報を前記公金取扱機関から受け取る納付情報受取工程、前記基本情報記録工程で情報を記録した案件のうち、前記納付情報受取工程で納付情報を受け取った案件について、該納付情報受取工程で受け取った納付情報に基いて、自治体へ報告する情報を所定の統一された形式で作成する報告情報作成工程、及び、この報告情報作成工程で作成した情報を自治体へ送る報告情報送り工程を行うことを特徴とする。
【００１９】
次に、請求項８に記載の発明は、自治体の公金収納を管理するためのプログラムであって、コンピュータを、公金を収納するために必要な情報を自治体から受け取る基本情報受取手段、この基本情報受取手段が受け取った情報を案件毎に記録する基本情報記録手段、納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報を前記公金取扱機関から受け取る納付情報受取手段、前記基本情報記録手段が情報を記録した案件のうち、前記納付情報受取手段が納付情報を受け取った案件について、該納付情報受取手段が受け取った納付情報に基いて、自治体へ報告する情報を所定の統一された形式で作成する報告情報作成手段、及び、この報告情報作成手段が作成した情報を自治体へ送る報告情報送り手段として機能させることを特徴とする。
【００２０】
次に、請求項９に記載の発明は、請求項８に記載の公金収納管理用プログラムであって、コンピュータを前記報告情報作成手段として機能させるときは、納付者がいずれの公金取扱機関を介して公金の納付手続をしたかを含む情報を作成すると共に、納付者がインターネットバンキング又はクレジット決済による公金取扱機関を介して公金の納付手続をした場合であっても、納付者の口座情報及びクレジットカード情報を含まない情報を作成するように機能させることを特徴とする。
【００２１】
次に、請求項１０に記載の発明は、請求項８又は９に記載の公金収納管理用プログラムであって、コンピュータを、前記納付情報受取手段が受け取った納付情報を案件毎に記録する納付情報記録手段、公金の納付手続が済んでいるか否かの問合せを受け付ける問合せ受付手段、この問合せ受付手段が問合せを受け付けた案件毎に前記納付情報記録手段が記録した納付情報を検索する納付情報検索手段、この納付情報検索手段が検索した納付情報に基いて回答情報を作成すると共に、前記問合せ受付手段が受け付けた問合せが、公金取扱機関を経由した納付者からの問合せであるときは、納付者に関する情報のうち特定の情報を含まない回答情報を作成し、前記問合せ受付手段が受け付けた問合せが、自治体を経由した納付者からの問合せであるときは、納付者の口座情報及びクレジットカード情報を含まない回答情報を作成する回答情報作成手段、及び、この回答情報作成手段が作成した回答情報を公金取扱機関又は自治体へ送る回答情報送り手段として機能させることを特徴とする。
【００２２】
次に、請求項１１に記載の発明は、請求項８から１０のいずれかに記載の公金収納管理用プログラムであって、コンピュータを、前記基本情報記録手段が記録した情報に基いて納付者へ送る納付通知書を作成する納付通知書作成手段として機能させることを特徴とする。
【００２３】
次に、請求項１２に記載の発明は、請求項１１に記載の公金収納管理用プログラムであって、コンピュータを、前記基本情報記録手段が情報を記録した案件毎に、案件を特定するコードを乱数を用いて設定する案件特定コード設定手段として機能させると共に、コンピュータを前記納付通知書作成手段として機能させるときは、この案件特定コード設定手段が設定したコードを付した納付通知書を作成するように機能させることを特徴とする。
【００２４】
次に、請求項１３に記載の発明は、請求項８から１２のいずれかに記載の公金収納管理用プログラムであって、コンピュータを前記納付情報受取手段として機能させるときは、納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報として、納付者が公金取扱機関を介して公金の納付手続をしたという手続情報及び自治体の口座へ入金する資金が準備されたという確認情報の２種類の情報を相前後して受け取るように機能させ、コンピュータを前記報告情報作成手段として機能させるときは、前記納付情報受取手段が前記手続情報を受け取った時点で、該手続情報に基いて、納付者が公金の納付手続をしたことを自治体へ連絡する旨の情報を作成するように機能させ、コンピュータを前記報告情報送り手段として機能させるときは、前記報告情報作成手段が前記情報を作成した時点で、該情報を自治体へ送るように機能させることを特徴とする。
【発明の効果】
【００２５】
まず、請求項１に記載の発明によれば、自治体の公金収納を管理するシステムにおいて、基本情報受取手段が、公金を収納するために必要な情報を自治体から受け取り、基本情報記録手段が、基本情報受取手段が受け取った情報を案件毎に記録し、納付情報受取手段が、納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報を公金取扱機関から受け取り、報告情報作成手段が、基本情報記録手段が情報を記録した案件のうち、納付情報受取手段が納付情報を受け取った案件について、納付情報受取手段が受け取った納付情報に基いて、自治体へ報告する情報を所定の統一された形式で作成し、そして、報告情報送り手段が、報告情報作成手段が作成した情報を自治体へ送るから、自治体が受け取る情報の形式が公金取扱機関の種類に関係なく統一されることとなり、その結果、自治体の側での情報の取扱いが容易となって、当該公金収納管理システムの信頼性ないし商品性の向上が図られることとなる。
【００２６】
次に、請求項２に記載の発明によれば、報告情報作成手段が、納付者がいずれの公金取扱機関を介して公金の納付手続をしたかを含む情報を作成すると共に、納付者がインターネットバンキング又はクレジット決済による公金取扱機関を介して公金の納付手続をした場合であっても、納付者の口座情報及びクレジットカード情報を含まない情報を作成するから、たとえ納付者がインターネットバンキングやクレジット決済を利用して公金の納付手続をしても、納付者の口座情報やクレジットカード情報といった重要情報が不用意に自治体の側へ流れることがなくなり、この点において、十全な情報漏洩リスクの低減が図られることとなる。
【００２７】
次に、請求項３に記載の発明によれば、納付情報記録手段が、納付情報受取手段が受け取った納付情報を案件毎に記録し、問合せ受付手段が、公金の納付手続が済んでいるか否かの問合せを受け付け、納付情報検索手段が、問合せ受付手段が問合せを受け付けた案件毎に納付情報記録手段が記録した納付情報を検索し、回答情報作成手段が、納付情報検索手段が検索した情報に基いて回答情報を作成すると共に、問合せ受付手段が受け付けた問合せが、公金取扱機関を経由した納付者からの問合せであるときは、納付者に関する情報のうち特定の情報を含まない回答情報を作成し、問合せ受付手段が受け付けた問合せが、自治体を経由した納付者からの問合せであるときは、納付者の口座情報及びクレジットカード情報を含まない回答情報を作成し、そして、回答情報送り手段が、回答情報作成手段が作成した回答情報を公金取扱機関又は自治体へ送るから、例えば公金取扱機関の側へは、回答情報に付随して、納付者の住所や生年月日あるいは世帯コード等の納付者に関する情報のうち特定の情報が流れることがなくなり、一方、自治体の側へは、回答情報に付随して、納付者の口座情報及びクレジットカード情報等の重要情報が流れることがなくなって、この点において、十全な情報漏洩リスクの低減が図られることとなる。
【００２８】
次に、請求項４に記載の発明によれば、納付通知書作成手段が、基本情報記録手段が記録した情報に基いて納付者へ送る納付通知書を作成するから、自治体の側で納付通知書を作成する手間が省けることとなる。
【００２９】
次に、請求項５に記載の発明によれば、案件特定コード設定手段が、基本情報記録手段が情報を記録した案件毎に、案件を特定するコードを乱数を用いて設定し、そして、納付通知書作成手段が、案件特定コード設定手段が設定したコードを付した納付通知書を作成するから、案件特定コード設定手段が設定するコードが複雑化し、案件特定コード設定手段が設定した案件特定コードから個人を特定することが困難となり、その結果、例えば、納付者が公金の納付手続時に自己の案件特定コードを誤って入力したときには、該当者無しというような警告が出るようになり、納付者が公金の納付手続時に自己の案件特定コードを誤って入力したときに他人のコードに該当してその他人の情報が漏洩するというようなリスクが低減されることとなる。
【００３０】
次に、請求項６に記載の発明によれば、納付情報受取手段が、納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報として、納付者が公金取扱機関を介して公金の納付手続をしたという手続情報及び自治体の口座へ入金する資金が準備されたという確認情報の２種類の情報を相前後して受け取り、報告情報作成手段が、納付情報受取手段が前記手続情報を受け取った時点で、該手続情報に基いて、納付者が公金の納付手続をしたことを自治体へ連絡する旨の情報を作成し、そして、報告情報送り手段が、報告情報作成手段が前記情報を作成した時点で、該情報を自治体へ送るから、自治体の側では、納付者が所定の公金取扱機関を介して公金の納付手続をした段階で早期にその情報を得ることができ、その結果、自治体がすでに公金の納付手続をした納付者に誤って督促状を出してしまう、という問題が解消されることとなる。
【００３１】
次に、請求項７に記載の発明によれば、自治体の公金収納を管理する方法において、コンピュータを用いて、請求項１に記載の各手段が行う工程と同様の工程を行うから、請求項１に記載の公金収納管理システムと同様の効果が得られることとなる。
【００３２】
次に、請求項８から１３に記載の発明によれば、自治体の公金収納を管理するためのプログラムにおいて、コンピュータを、請求項１から６に記載の各手段として機能させるから、このプログラムをコンピュータに搭載すれば、請求項１から６に記載の公金収納管理システムと同様のシステム及び効果が得られることとなる。
【発明を実施するための最良の形態】
【００３３】
以下、図面に基き、本発明の最良の実施の形態を説明する。なお、本実施形態に係る公金収納管理システムは、本発明に係る公金収納管理システムを構成し、本実施形態に係る公金収納管理システムが行う動作は、本発明に係る公金収納管理方法の実施の形態を構成し、本実施形態に係る公金収納管理システムに搭載されているプログラムは、本発明に係る公金収納管理システム用プログラムの実施の形態を構成する。
【００３４】
図１に示すように、本実施形態に係る公金収納管理システム（以下単に「システム」という）１０は、例えば自治体の公金収納業務を代行するために設立された機関である公金収納管理センター（以下単に「センター」という）に備えられている。このシステム１０は、銀行や郵便局の窓口、コンビニエンスストア、インターネットバンキング及びクレジットカードのＷＥＢ収納サイト等の、複数の公金取扱機関を介しての公金収納に対応可能なものである。
【００３５】
システム１０は、コンピュータで構成され、ＣＰＵ等の中央処理装置１１、外部から情報を入力するためのキーボード等の入力装置１２、外部へ情報を出力するためのディスプレイやプリンタ等の出力装置１３、外部機器との情報通信を管理するための通信装置１４、及び、各種プログラムやデータを記録するためのメインメモリやＲＯＭ、ＲＡＭ等の記録装置１５等が、バスを介して相互に接続されている。
【００３６】
記録装置１５は、プログラムが記録されるプログラム記録部１５ａと、データが記録されるデータ記録部１５ｂとを有し、データ記録部１５ｂには、基本情報ＤＢ（データベース：以下同じ）、納付情報ＤＢ、及び資金化日ＤＢが格納されている。
【００３７】
システム１０は、例えば専用のコンピュータネットワーク３１を介して、自治体の通信サーバ２２ないし基幹システム２１と相互に情報通信可能に接続されている。同様に、システム１０は、コンピュータネットワーク３２〜３５を介して、自治体指定金融機関、コンビニエンスストア収納代行会社、ＭＰＮ（マルチペイメントネットワーク）収納センター、及びクレジット収納センターと相互に情報通信可能に接続されている。
【００３８】
次に、図２〜図４を参照して各ＤＢの構造を説明する。なお、以下の図２〜図４、図１４、及び図１６〜図２７において、基本的に、具体例を示した欄以外の「（空欄）」は未入力欄（現在はデータが入力されていないが将来データが入力される欄）であることを示し、「−」は非入力欄（将来もデータが入力されない欄）であることを示し、「---」は何等かの種々様々なデータが入力されている欄であることを示す。
【００３９】
まず、基本情報ＤＢ（基本情報記録手段を構成する）は、公金の収納に必要な基礎的データを登録しておくもので、図２に示すように、自治体側で案件毎に付与された納付書コード（符号ア：以下、異なる図面で同じ符号が付されているデータ同士が相互に対応していることを示す）をキーとして、自治体コード（符号イ）、納付科目、センター側で案件毎に乱数を用いて採番した納付番号（符号ウ）、コンビニ収納キー（公金取扱機関がコンビニエンスストアのときにキーとなるバーコード情報で、少なくとも前記納付番号を包含したもの（換言すれば、前記納付番号を含んでさえいれば、該納付番号のみからなるものでもよいし、他の情報、例えば納付金額や自治体名等の付加的情報を含むものでもよい）である：符号エ）、窓口収納キー（公金取扱機関が金融機関の窓口のときにキーとなるＯＣＲ（optical character reader：光学式文字読取装置）情報で、少なくとも前記納付番号を包含したもの（換言すれば、前記納付番号を含んでさえいれば、該納付番号のみからなるものでもよいし、他の情報、例えば納付金額や自治体名等の付加的情報を含むものでもよい）である：符号オ）、納付金額、及び納付期限といった基礎的データの他、納付者氏名（カナ、漢字）、住所、生年月日、性別、個人番号、及び世帯コードといった納付者個人に関する情報が、検索可能に体系的に登録されている。なお、この図２に示した具体例は、後述する図４１及び図４２に記載した例を採用したものであるが、本実施形態を限定するものではない。
【００４０】
また、納付情報ＤＢ（納付情報記録手段を構成する）は、各案件につき公金の納付状況に関するデータを登録しておくもので、図３に示すように、納付番号（符号ウ）をキーとして、コンビニ収納キー（符号エ）、窓口収納キー（符号オ）、納付金額（符号カ）、納付手続日（符号キ）、状況区分（符号ク）、収納チャンネル（符号ケ）、収納会社（符号コ）、手続情報受信日（符号サ）、確認情報受信日（符号シ）、及び資金化日（符号ス）といった各種の情報が、検索可能に体系的に登録されている。なお、この図３に示した具体例は、後述する図４１及び図４２並びに図６に記載した例を採用したものであるが、本実施形態を限定するものではない。
【００４１】
一方、資金化日ＤＢは、金融機関やコンビニエンスストアあるいはクレジット会社等の各公金取扱機関毎に、納付者による納付手続があってから（納付手続日）、その納付した資金がいつ自治体の口座に入金されるか（資金化日）に関するデータを予め登録しておくもので、図４に示すように、収納会社（符号コ）をキーとして、収納チャンネル（符号ケ）、自治体コード（符号イ）、納付科目、資金化日タイプ、納付手続日後日数、速報通知日後日数、納付手続日範囲（開始）、納付手続日範囲（終了）、及び資金化日といった各種の情報が、検索可能に体系的に登録されている。
【００４２】
ここで、図４に例示した資金化日ＤＢの登録内容の意味を説明する。まず、Ａ銀行は、自治体指定金融機関であり、Ａ銀行の窓口で直接公金の納付手続をすると、その資金が自治体の口座に入金される資金化日は、納付済通（図８、図９参照）のデータ化時に指定されることが登録されている。例えば、図５に示すように、Ａ銀行の窓口に公金が５月２０日に納められたとすると（納付手続日）、翌日の５月２１日にその資金が自治体の口座に入金される（資金化日）。そして、この５月２１日という情報が納付済通のデータ化時に指定されるのである。また、図６に示すように、Ａ銀行の窓口に公金が５月３０日に納められたとすると（納付手続日）、翌日の５月３１日にその資金が自治体の口座に入金される（資金化日）。そして、この５月３１日という情報が納付済通のデータ化時に指定されるのである。
【００４３】
次に、Ｂ銀行は、非指定金融機関であり、Ｂ銀行の窓口で直接公金の納付手続をすると、その資金が自治体の口座に入金される資金化日は、納付手続日の２営業日後であることが登録されている。例えば、図５に示すように、Ｂ銀行の窓口に公金が５月２０日に納められたとすると（納付手続日）、２日後の５月２２日にその資金が自治体の口座に入金される（資金化日）。また、図６に示すように、Ｂ銀行の窓口に公金が５月２９日に納められたとすると（納付手続日）、２日後の５月３１日にその資金が自治体の口座に入金される（資金化日）。
【００４４】
次に、コンビニエンスストアであるＣコンビニで直接公金の納付手続をすると、その資金が自治体の口座に入金される資金化日は、予め月間スケジュールによって決まっていることが登録されている。例えば、図５に示すように、Ｃコンビニに公金が５月２０日に納められたとすると（納付手続日）、５月２０日は５月１５日から５月２５日までの範囲内にあるから、５月３１日にその資金が自治体の口座に入金される（資金化日）。図４には、納付手続日が２００７年５月１５日から２００７年５月２５日までの範囲内にあるとき、資金化日が２００７年５月３１日になることのみ示したが、納付手続日がこれ以外の範囲内にあるときについても併せて登録されている。なお、図５及び図６に記されている「速報通知日」及び「確報通知日」の意味は後ほど明らかになるであろう（図１０、図１１、図１９、図２１参照）。
【００４５】
次に、Ｄ銀行は、納付者が口座を有する金融機関であり、ＷＥＢ収納サイトを介してインターネットバンキングで電子納付手続をすると、その資金が自治体の口座に入金される資金化日は、速報通知日の３営業日後であることが登録されている。例えば、図５に示すように、インターネットバンキングにより、Ｄ銀行の納付者の口座から資金を引き落とす手続が５月２０日にとられたとすると（納付手続日）、３日後の５月２３日にその引き落とされた資金が自治体の口座に入金される（資金化日）。また、図６に示すように、インターネットバンキングにより、Ｄ銀行の納付者の口座から資金を引き落とす手続が５月２８日にとられたとすると（納付手続日）、３日後の５月３１日にその引き落とされた資金が自治体の口座に入金される（資金化日）。
【００４６】
次に、Ｅクレジットは、納付者がカード契約を交わしているクレジット会社であり、ＷＥＢ収納サイトを介してクレジットカードで電子納付手続をすると、それに応じた資金が自治体の口座に入金される資金化日は、速報通知日の３営業日後であることが登録されている。例えば、図５に示すように、クレジットカードにより、公金の納付手続が５月２０日にとられたとすると（納付手続日）、３日後の５月２３日にそれに応じた資金が自治体の口座に入金される（資金化日）。また、図６に示すように、クレジットカードにより、公金の納付手続が５月２８日にとられたとすると（納付手続日）、３日後の５月３１日にそれに応じた資金が自治体の口座に入金される（資金化日）。
【００４７】
なお、図５は、公金の納付手続がすべて同じ日（５／２０）にとられた場合でも、公金取扱機関が異なると資金化日が異なる例を示すものである。これに対し、図６は、公金の納付手続が異なる日にとられた場合に、資金化日が同じ日（５／３１）に揃う例を示している。
【００４８】
次に、システム１０が行う動作を含め、センター（ひいてはシステム１０）による公金収納管理業務を各公金取扱機関毎に説明する。まず、図７を参照して、納付通知書の作成動作を説明する。図７に符号（１）で示すように、自治体の側からセンターへ基本情報がネットワーク３１を介して送信される。
【００４９】
この基本情報は、図１４に示すように、自治体の側で付与された納付書コード（符号ア）をキーとして、納付科目、納付金額、納付期限、納付者氏名（カナ）、納付者氏名（漢字）、住所、生年月日、性別、個人番号、及び世帯コードといった各種の情報を含んでいる。なお、この図１４に示した具体例は、図２に記載した例を採用したものであるが、本実施形態を限定するものではない。
【００５０】
システム１０は、この基本情報を受信すると、その内容を案件毎に基本情報ＤＢに登録する。次いで、システム１０は、この基本情報ＤＢの登録内容に基いて納付通知書を作成し、センターは、これを各納付者へ送付する（符号（２））。
【００５１】
この納付通知書は、図１５に示すように、システム１０が案件毎に乱数を用いて採番した納付番号、コンビニ収納キー（前記納付番号を包含したバーコード情報）、窓口収納キー（前記納付番号を包含したＯＣＲ情報）、納付金額、納付期限、自治体名、納付科目、及び納付者氏名といった各種の情報が記載されている。
【００５２】
ここで、システム１０は、案件毎に基本情報ＤＢを作成すると共に、その基本情報ＤＢの登録内容に基いて、納付情報ＤＢを案件毎に作成する（図３において１つ目の矢印の前の状態：状況区分は「０」である）。
【００５３】
次に、図８を参照して、納付者が指定金融機関の窓口で公金納付手続をする場合を説明する。まず、納付者は、納付通知書を携えて指定金融機関に出向き、窓口で公金を現金納付する（符号（１））。指定金融機関は、この納付者の納付手続を受けて、納付通知書から切り離した納付済通をセンターに届ける（符号（２））。センターでは、この納付済通に記載されている情報をシステム１０に入力し、データ化する。データ化された情報は、窓口納付情報となって、案件毎に納付情報ＤＢに登録される（図３において１つ目の矢印のように変化した後の状態：状況区分が「０」から「１」に更新される）。
【００５４】
この窓口納付情報は、図１６に示すように、窓口収納キー（符号オ）をキーとして、収納会社（符号コ）、納付金額（符号カ）、納付手続日（符号キ）、及び資金化日（符号ス）といった各種の情報を含んでいる。なお、この図１６に示した具体例は、図６に記載した例を採用したものであるが、本実施形態を限定するものではない。また、図１６と図３とは窓口収納キー（符号オ）で紐付けされる。
【００５５】
ここで、資金化日（符号ス）は、納付者がした納付手続に係る資金が自治体の口座に移動する日である。図４に示した資金化日ＤＢを参照すると、自治体指定金融機関の場合、資金化タイプが「４」で、資金化日は納付済通のデータ化時に指定と登録されている。したがって、センターで納付済通に記載されている内容をシステム１０に入力し、データ化する際に、資金化日が決定される。この場合、納付者が現金納付をした金融機関が指定金融機関であるから、その納付手続日の次の営業日に自治体の口座に資金が振り込まれることが分かっている。例えば、納付済通が納付手続日（図５の５／２０）の当日にセンターに届けられて情報がデータ化される場合は、納付済通がセンターに届けられた日（５／２０）の翌日（５／２１）が資金化日とされ、一方、納付済通が納付手続日（図５の５／２０）の翌日にセンターに届けられて情報がデータ化される場合は、納付済通がセンターに届けられた日（５／２１）の当日（５／２１）が資金化日とされる。いずれにせよ、センターでのデータ化時には、資金化日（符号ス）は、図５の例では、５／２１と入力される。
【００５６】
図８に戻り、資金化日になると、符号（３）で示すように、指定金融機関からシステム１０へ入金情報が送信される。この入金情報は、図示しないが、例えば全国銀行協会のフォーマットに準じるものであり、各公金取扱機関から自治体の口座に入金された資金の公金取扱機関別入金情報である。
【００５７】
システム１０は、この入金情報を受信すると、その入金額と、今日が資金化日である案件の納付情報ＤＢの登録データに含まれる納付金額（図３の符号（カ））とを突合し、両金額同士が一致していることを確認したうえで、自治体へ消込情報を送信する（符号（４））。
【００５８】
この消込情報は、図１７に示すように、納付書コード（符号ア）をキーとして、納付科目、納付金額（符号カ）、納付手続日（符号キ）、収納確認日（符号シ）、納付者氏名（カナ）、納付者氏名（漢字）、状況区分（符号ク）、収納チャネル（符号ケ）、収納会社（符号コ）、及び資金化日（符号ス）といった各種の情報を含んでいる。ここで、この消込情報は、図示したように、自治体へ報告する情報が、収納チャネルや収納会社が何であるかに関わらず（すなわち、収納チャネルや収納会社が案件毎に異なっていても）、所定の統一された形式で作成されている。なお、この消込情報においては、状況区分（符号ク）は「３」である（図３において３つ目の矢印のように変化した後の状態：状況区分が「２」から「３」に更新されている）。また、この図１７に示した具体例は、図３に記載した例を採用したものであるが、本実施形態を限定するものではない。また、図１７と図３と図２とは納付番号（符号ウ）及び納付書コード（符号ア）で紐付けされる。
【００５９】
また、図１７に示すように、消込情報には、納付者の口座情報やクレジットカード情報等は含まれていない。なお、本実施形態では、前述したように、図３の納付情報ＤＢに、納付者の口座情報やクレジットカード情報等が記録されないようになっているが、たとえ納付情報ＤＢ等に納付者の口座情報やクレジットカード情報等が記録される場合であっても、つまり、システム１０が納付者の口座情報やクレジットカード情報等を保有している場合であっても、消込情報には、納付者の口座情報やクレジットカード情報等が含まれないようになっているのである。
【００６０】
図８に符号（５）で示すように、資金化日には、指定金融機関から自治体へ入金情報が送信されており、自治体は、この指定金融機関からの入金情報と、システム１０からの消込情報とを突合して、自治体が保有する自治体独自の基本情報ＤＢ及び／又は納付情報ＤＢの登録データの消込みを行うこととなる。その際、消込情報に含まれる収納金額（符号カ）が入金情報に含まれる入金額と一致していることが既にシステム１０の側でチェック済みなので、自治体における前記消込作業が極めて円滑に行われることとなる。
【００６１】
次に、図９を参照して、納付者が非指定の金融機関の窓口で公金納付手続をした場合を説明する。ただし、図８の場合と比べて異なる部分のみ説明を加える。図９の場合が図８の場合と比べて異なる部分は、図９に符号（２）で示すように、納付済通が指定金融機関からではなく非指定金融機関からセンターへ届けられる点である。また、図９に符号（３）で示すように、納付者が納付手続を行った非指定金融機関から、自治体の口座がある指定金融機関へ、資金化日までに資金移動が発生する点である。
【００６２】
そして、資金化日（図１６の符号ス）は、図４に示した資金化日ＤＢを参照すると、非指定金融機関の場合、資金化タイプが「１」で、資金化日は、納付者が納付手続を行った日の２営業日後と登録されている。例えば、納付済通が納付手続日（図５の５／２０）の当日にセンターに届けられた場合は、納付済通がセンターに届けられた日（５／２０）の翌々日（５／２２）が資金化日とされ、一方、納付済通が納付手続日（５／２０）の翌日にセンターに届けられた場合は、納付済通がセンターに届けられた日（５／２１）の翌日（５／２２）が資金化日とされる。いずれにせよ、資金化日（符号ス）は、図５の例では、５／２２と入力される。この入金予定日（符号ス）は、システム１０の側で資金化日ＤＢを参照して決定される。
【００６３】
次に、図１０を参照して、納付者がコンビニエンスストアで公金納付手続をした場合を説明する。まず、図９に符号（１）で示すように、納付者は、納付通知書を携えてコンビニエンスストアに出向き、公金を現金納付する。コンビニエンスストアは、この納付者の納付手続を受けて、コンビニエンスストア収納代行会社へ、納付手続のあったことを、必要事項と共に通知する（符号（２））。コンビニエンスストア収納代行会社は、この通知を受けると、コンビニ納付手続情報（つまり、納付者が公金取扱機関を介して公金の納付手続をしたという手続情報）をセンターへ送信する（符号（３））。
【００６４】
このコンビニ納付手続情報は、図１８に示すように、コンビニ収納キー（符号エ）をキーとして、収納会社（符号コ）、納付金額（符号カ）、納付手続日（符号キ）、資金化日（符号ス）、及び収納確認フラグ（符号セ）といった各種の情報を含んでいる。なお、この図１８に示した具体例は、図６に記載した例を採用したものであるが、本実施形態を限定するものではない。
【００６５】
システム１０は、コンビニ納付手続情報を受信すると、その内容を案件毎に納付情報ＤＢに登録する。その場合、資金化日（図３の符号ス）は、図４に示した資金化日ＤＢを参照すると、コンビニエンスストアの場合、資金化タイプが「３」で、資金化日は、月間スケジュールで決まると登録されている。例えば、納入手続が５／２０にあったとすると、５／２０は図４の納付手続日範囲（開始）〜（終了）に入っているから、資金化日（符号ス）は、図５の例では、５／３１と入力される。この資金化日（符号ス）は、システム１０の側で資金化日ＤＢを参照して決定される。なお、図１８と図３とはコンビニ収納キー（符号エ）で紐付けされる。
【００６６】
次いで、システム１０は、この納付情報ＤＢの登録内容に基いて仮消込情報（速報）を作成し、これを自治体へ送信する（符号（４））。なお、図５の例では、この仮消込情報（速報）は納付手続日の翌日（５／２１）に通知されている。
【００６７】
この仮消込情報（速報）は、図１９に示すように、納付書コード（符号ア）をキーとして、納付科目、納付金額（符号カ）、納付手続日（符号キ）、納付者氏名（カナ）、納付者氏名（漢字）、個人番号、状況区分（符号ク）、収納チャネル（符号ケ）、収納会社（符号コ）、及び資金化日（符号ス）といった各種の情報を含んでいる。これにより、自治体の側で、早い段階で、案件毎に納付手続の有無を確認することができ、納付者が納付手続をしたのに自治体から督促状が送られてきた、というような不具合が未然に防止される。ここで、この仮消込情報（速報）は、図示したように、案件毎に記載内容が異なっていても、所定の統一された形式で作成されている。また、納付者の口座情報やクレジットカード情報等は含まれていない。なお、この図１９に示した具体例は、図３に記載した例を採用したものであるが、本実施形態を限定するものではない。また、図１９と図３と図２とは納付番号（符号ウ）及び納付書コード（符号ア）で紐付けされる。
【００６８】
次いで、図１０に符号（５）で示すように、納付者が納付手続をしたコンビニエンスストアからコンビニエンスストア収納代行会社へ前記納付手続に係る資金が移動する。コンビニエンスストア収納代行会社は、この資金移動に応じて、コンビニ納付確認情報（つまり、自治体の口座へ入金する資金が準備されたという確認情報）をセンターへ送信する（符号（６））。
【００６９】
このコンビニ納付確認情報は、図２０に示すように、コンビニ収納キー（符号エ）をキーとして、収納会社（符号コ）、納付金額（符号カ）、収納確認日（納付手続に係る資金がコンビニエンスストア収納代行会社へ移動した日：符号シ）、資金化日（符号ス）、及び収納確認フラグ（符号セ）といった各種の情報を含んでいる。これにより、資金化日（符号ス）に自治体の口座に資金が確実に入金されることが約束されたことになる。なお、この図２０に示した具体例は、図６に記載した例を採用したものであるが、本実施形態を限定するものではない。
【００７０】
システム１０は、コンビニ納付確認情報を受信すると、その内容を案件毎に納付情報ＤＢに登録する。その場合、状況区分が「１」から「２」に更新される（図３の２つ目の矢印）。なお、図２０と図３とはコンビニ収納キー（符号エ）で紐付けされる。
【００７１】
次いで、システム１０は、この納付情報ＤＢの登録内容に基いて仮消込情報（確報）を作成し、これを自治体へ送信する（符号（７））。なお、図５の例では、この仮消込情報（確報）は５／２６に通知されている。
【００７２】
この仮消込情報（確報）は、図２１に示すように、納付書コード（符号ア）をキーとして、納付科目、納付金額（符号カ）、収納確認日（納付手続に係る資金がコンビニエンスストア収納代行会社へ移動した日：符号シ）、納付者氏名（カナ）、納付者氏名（漢字）、個人番号、状況区分（「２」に更新されている：符号ク）、収納チャネル（符号ケ）、収納会社（符号コ）、及び資金化日（符号ス）といった各種の情報を含んでいる。ここで、この仮消込情報（確報）は、図示したように、案件毎に記載内容が異なっていても、所定の統一された形式で作成されている。また、納付者の口座情報やクレジットカード情報等は含まれていない。なお、この図２１に示した具体例は、図３に記載した例を採用したものであるが、本実施形態を限定するものではない。また、図２１と図３と図２とは納付番号（符号ウ）及び納付書コード（符号ア）で紐付けされる。
【００７３】
次いで、図１０に符号（８）で示すように、コンビニエンスストア収納代行会社から自治体指定金融機関へ納付手続に係る資金が移動する。そして、資金化日になると、符号（９）で示すように、指定金融機関からシステム１０へ入金情報が送信されるのであるが、これ以降の符号（９）〜（１１）は、図８の符号（３）〜（５）と同じであるので、その説明は省略する。
【００７４】
次に、図１１を参照して、納付者がインターネットバンキングのＷＥＢサイト上で納付手続をした場合を説明する。まず、図１１に符号（１）で示すように、納付者は、自己の保有するＰＣ等を用いて、ＭＰＮ（マルチペイメントネットワーク）収納センターのＷＥＢ収納サイトにアクセスする。このとき納付者のＰＣに表れる初期画面Ｗ１を図３８に例示する。納付者は納付通知書に記載されている納付番号（図１５参照）等、必要事項を入力して納付手続ボタンをクリックすると、図３９に示すように、納付手続の続行画面Ｗ２に変わるので、納付者は自己の口座番号を入力して口座情報確認ボタンをクリックする。これにより、図１１に符号（２）で示すように、口座情報が納付者取引金融機関に送られ、符号（３）で示すように、確認情報が返信される。そして、符号（４）で示すように、納付者に対して、納付手続画面（図示せず）が表示されるので、納付者は、その画面上で納付手続を行うこととなる。ＭＰＮ収納センターは、納付者によるこの納付手続に応じて、インターネットバンキング納付手続情報（つまり、納付者が公金取扱機関を介して公金の納付手続をしたという手続情報）をセンターへ送信する（符号（５））。
【００７５】
なお、納付者が図３８に例示した初期画面Ｗ１上で、納付番号等の必要事項を入力して納付手続ボタンをクリックしたとき、すでにこの件の納付手続が済んでいる場合は、二重納付を防止するため、図４０に示すように、納付手続が済んでいることを示す納付状況を表示して今のこの納付手続を中止するようになっている（二重納付防止画面Ｗ３：確認ボタンをクリックすると初期画面Ｗ１に戻る）。
【００７６】
前記インターネットバンキング納付手続情報は、図２２に示すように、納付番号（符号ウ）をキーとして、収納会社（符号コ）、納付金額（符号カ）、納付手続日（符号キ）、資金化日（符号ス）、及び収納確認フラグ（符号セ）といった各種の情報を含んでいる。なお、この図２２に示した具体例は、図６に記載した例を採用したものであるが、本実施形態を限定するものではない。
【００７７】
システム１０は、インターネットバンキング納付手続情報を受信すると、その内容を案件毎に納付情報ＤＢに登録する。その場合、資金化日（図３の符号ス）は、図４に示した資金化日ＤＢを参照すると、インターネットバンキング（ＭＰＮ収納センター）の場合、資金化タイプが「２」で、資金化日は、速報通知日の３営業日後と登録されている。例えば、納付手続が５／２０にあり、当日に自治体の側へ速報が通知されるとすると、資金化日（符号ス）は、図５の例では、５／２３と入力される。この資金化日（符号ス）は、システム１０の側で資金化日ＤＢを参照して決定される。なお、図２２と図３とは納付番号（符号ウ）で紐付けされる。
【００７８】
次いで、システム１０は、この納付情報ＤＢの登録内容に基いて仮消込情報（速報）を作成し、これを自治体へ送信する（符号（６））。なお、図５の例では、この仮消込情報（速報）は納付手続日の当日（５／２０）に通知されている。ただし、この仮消込情報（速報）は、前述の図１９に示した通りであるので、ここでは説明を繰り返さない。
【００７９】
次いで、図１１に符号（７）で示すように、納付者取引金融機関からＭＰＮ収納センターへ前記納付手続に係る資金が移動する。ＭＰＮ収納センターは、この資金移動に応じて、インターネットバンキング納付確認情報（つまり、自治体の口座へ入金する資金が準備されたという確認情報）をセンターへ送信する（符号（８））。
【００８０】
このインターネットバンキング納付確認情報は、図２３に示すように、納付番号（符号ウ）をキーとして、収納会社（符号コ）、納付金額（符号カ）、収納確認日（符号シ）、資金化日（符号ス）、及び収納確認フラグ（符号セ）といった各種の情報を含んでいる。これにより、資金化日（符号ス）に自治体の口座に資金が確実に入金されることが約束されたことになる。なお、この図２３に示した具体例は、図６に記載した例を採用したものであるが、本実施形態を限定するものではない。
【００８１】
システム１０は、インターネットバンキング納付確認情報を受信すると、その内容を案件毎に納付情報ＤＢに登録する。その場合、状況区分が「１」から「２」に更新される（図３の２つ目の矢印）。なお、図２３と図３とは納付番号（符号ウ）で紐付けされる。
【００８２】
次いで、システム１０は、この納付情報ＤＢの登録内容に基いて仮消込情報（確報）を作成し、これを自治体へ送信する（符号（９））。なお、図５の例では、この仮消込情報（確報）は５／２１に通知されている。ただし、この仮消込情報（確報）は、前述の図２１に示した通りであるので、ここでは説明を繰り返さない。
【００８３】
次いで、図１１に符号（１０）で示すように、ＭＰＮ収納センターから自治体指定金融機関へ納付手続に係る資金が移動する。そして、資金化日になると、符号（１１）で示すように、指定金融機関からシステム１０へ入金情報が送信されるのであるが、これ以降の符号（１１）〜（１３）は、図８の符号（３）〜（５）と同じであるので、その説明は省略する。
【００８４】
最後に、図１２を参照して、納付者がクレジットカードのＷＥＢサイト上で納付手続をした場合を説明する。全体の動作の流れは、図１１の場合と類似している。ただし、図１１の場合と異なる部分は、図１２に符号（５）で示すように、収納センターからセンターへ送信されるのは納付手続兼確認情報であり、それに応じて、図１１に符号（６）で示すように、センターから自治体へ送信されるのは、仮消込情報（速報兼確報）である点である。
【００８５】
まず、図１２に符号（１）で示すように、納付者は、自己の保有するＰＣ等を用いて、クレジット収納センターのＷＥＢ収納サイトにアクセスする。このとき納付者のＰＣには前述のインターネットバンキングの場合の図３８の初期画面Ｗ１に類似の画面が表れるが、ここではその図示は省略する。納付者は納付通知書に記載されている納付番号（図１５参照）や自己のカード番号等を入力する。これにより、符号（２）で示すように、カード情報が納付者が契約するクレジット会社に送られ、符号（３）で示すように、認証情報が返信される。そして、符号（４）で示すように、納付者に対して、納付手続画面が表示されるので、納付者は、その画面上で納付手続を行うこととなる。クレジット収納センターは、納付者によるこの納付手続に応じて、クレジット納付手続兼確認情報（つまり、納付者が公金取扱機関を介して公金の納付手続をしたという手続情報であり、かつ、自治体の口座へ入金する資金が準備されたという確認情報）をセンターへ送信する（符号（５））。
【００８６】
このクレジット納付手続兼確認情報は、図２４に示すように、納付番号（符号ウ）をキーとして、収納会社（符号コ）、納付金額（符号カ）、納付手続兼収納確認日（符号シ）、資金化日（符号ス）、及び収納確認フラグ（符号セ）といった各種の情報を含んでいる。なお、この図２４に示した具体例は、図６に記載した例を採用したものであるが、本実施形態を限定するものではない。
【００８７】
システム１０は、クレジット納付手続兼確認情報を受信すると、その内容を案件毎に納付情報ＤＢに登録する。その場合、資金化日（図３の符号ス）は、図４に示した資金化日ＤＢを参照すると、クレジット決済（クレジット収納センター）の場合、資金化タイプが「２」で、資金化日は、速報通知日の３営業日後と登録されている。例えば、納付手続が５／２０にあり、当日に自治体の側へ速報が通知されるとすると、資金化日（符号ス）は、図５の例では、５／２３と入力される。この資金化日（符号ス）は、システム１０の側で資金化日ＤＢを参照して決定される。また、状況区分が「０」から「２」に更新される（図３の１つ目の矢印及び２つ目の矢印）。なお、図２４と図３とは納付番号（符号ウ）で紐付けされる。
【００８８】
次いで、システム１０は、この納付情報ＤＢの登録内容に基いて仮消込情報（速報兼確報）を作成し、これを自治体へ送信する（符号（６））。なお、図５の例では、この仮消込情報（速報兼確報）は納付手続日の当日（５／２０）に通知されている。ただし、この仮消込情報（速報兼確報）は、前述の図２１に示した仮消込情報（確報）に準じて同様なので、ここでは説明を繰り返さない。
【００８９】
次いで、図１２に符号（７）で示すように、クレジット会社からクレジット収納センターへ前記納付手続に係る資金が移動する。これにより、資金化日（符号ス）に自治体の口座に資金が確実に入金されることが約束されたことになる。
【００９０】
次いで、図１２に符号（８）で示すように、クレジット収納センターから自治体指定金融機関へ納付手続に係る資金が移動する。そして、資金化日になると、符号（９）で示すように、指定金融機関からシステム１０へ入金情報が送信されるのであるが、これ以降の符号（９）〜（１１）は、図８の符号（３）〜（５）と同じであるので、その説明は省略する。
【００９１】
ただし、このクレジット決済で公金を納付する場合の特徴として、図１２に符号（１６）で示すように、後日、クレジット会社から納付者の元へ利用代金明細書が送付され、これに伴い、符号（１７）で示すように、クレジット契約に従って納付者の口座から納付手続に係る資金が引き落とされることは、いうまでもない。
【００９２】
以上の基本的動作に加えて、本実施形態においては、図８〜図１２に符号（９９）で示すように、自治体の側からセンターの側へ納付済情報が送信されることがある。つまり、納付者のなかには、納付通知書を携えて、自治体の庁舎へ直接出向き、公金の納付手続をする者がある。この場合、センターには公金取扱機関からの手続情報が入らないので、自治体とセンターとで情報の連携を図るために、自治体の側からセンターの側へ納付済情報が送信されるのである。
【００９３】
この納付済情報は、図２５に示すように、納付書コード（符号ア）をキーとして、納付金額（符号カ）、納付手続日（符号キ）、納付者氏名（カナ）、納付者氏名（漢字）、収納チャネル（符号ケ）、及び収納会社（符号コ）といった各種の情報を含んでいる。システム１０は、この納付済情報を受信すると、その内容を納付情報ＤＢに登録することとなる。なお、図２５と図３と図２とは納付番号（符号ウ）及び納付書コード（符号ア）で紐付けされる。
【００９４】
さらに、本実施形態においては、図１３に示すように、センターとＭＰＮ収納センター（クレジット収納センターでも同じ）との間、及び、センターと自治体との間で、問合せ情報及び回答情報が遣り取りされることがある。次に、この納付状況の問合せ動作を説明する。
【００９５】
つまり、納付者のなかには、公金の二重納付を避けるために、ＷＥＢ収納サイトを通して、収納センターに自己の納付状況を問い合せる者がある（ａ）。この場合、収納センターでは他の公金取扱機関を介しての納付状況が判らないから、納付者からの問合せを受けると、さらにセンターへ問合せを行うこととなる（ｂ）。その結果、センターの側から収納センターの側へ、納付状況の問合せに対する回答として回答情報が送信されることとなる（ｃ）。この回答情報は収納センターから納付者に示される（ｄ）。
【００９６】
同様に、納付者のなかには、公金の二重納付を避けるために、自治体（の職員）に自己の納付状況を問い合せる者がある（ｅ）。この場合、納付通知書には、図１５に図示したように、自治体が付与した納付書コード（符号ア）が記載されておらず、代わりに、センターが採番した納付番号（符号ウ）が記載されているので、納付者はこの納付番号で問合せを行うこととなる。しかし、自治体の側では納付番号が判らないから、納付者からの問合せを受けると、さらにセンターへ問合せを行うこととなる（ｆ）。その結果、センターの側から自治体の側へ、納付状況の問合せに対する回答として回答情報が送信されることとなる（ｇ）。この回答情報は自治体から納付者に伝達される（ｈ）。
【００９７】
このうち、公金取扱機関へ送られる回答情報（ｃ）は、図２６に示すように、納付番号（符号ウ）をキーとして、納付者氏名、状況区分（符号ク）、納付金額（符号カ）、納付手続日（符号キ）、収納チャネル（符号ケ）、及び収納会社（符号：コ）といった各種の情報を含んでいる。ただし、納付者の住所や生年月日、電話番号や個人場号、あるいは世帯コードといった、納付者に関する情報のうちの特定の情報は一切含まれていない。このようにデータを分散することにより、公金取扱機関に対する不必要なデータの漏洩リスクの低減が図られている。なお、この図２６に示した具体例は、図３に記載した例を採用したものであるが、本実施形態を限定するものではない。また、図２６と図３とは納付番号（符号ウ）で紐付けされる。
【００９８】
一方、自治体へ送られる回答情報（ｇ）は、図２７に示すように、納付書コード（符号ア）をキーとして、納付科目、納付者氏名（カナ、漢字）、状況区分（符号ク）、納付金額（符号カ）、納付手続日（符号キ）、収納チャネル（符号ケ）、収納会社（符号コ）、及び資金化日（符号ス）といった各種の情報を含んでいる。ただし、納付者の口座情報やクレジットカード情報は一切含まれていない。このようにデータを分散することにより、自治体に対する不必要なデータの漏洩リスクの低減が図られている。なお、この図２７に示した具体例は、図３に記載した例を採用したものであるが、本実施形態を限定するものではない。また、図２７と図３と図２は納付番号（符号ウ）及び納付書コード（符号ア）で紐付けされる。
【００９９】
なお、本実施形態では、前述したように、図３の納付情報ＤＢに、納付者の口座情報やクレジットカード情報等が記録されないようになっているが、たとえ納付情報ＤＢ等に納付者の口座情報やクレジットカード情報等が記録される場合であっても、つまり、システム１０が納付者の口座情報やクレジットカード情報等を保有している場合であっても、自治体への回答情報（ｇ）には、納付者の口座情報（図１１の符号（２））やクレジットカード情報（図１２の符号（２））等が一切含まれないようになっているのである。
【０１００】
一方、本実施形態では、前述したように、図２の基本情報ＤＢに、納付者氏名の他、住所や生年月日等の納付者個人に関する各種の情報が記録されるようになっているが、このように基本情報ＤＢ等に納付者個人に関する各種の情報が記録される場合であっても、つまり、システム１０が納付者個人に関する各種の情報を保有している場合であっても、公金取扱機関への回答情報（ｃ）には、納付者個人に関する各種の情報のうちの特定の情報が一切含まれないようになっているのである（図２６の例では、納付者氏名だけが含まれている）。
【０１０１】
ここで、納付者が自己の保有するＰＣ等を用いて、収納センターのＷＥＢ収納サイトにアクセスしたときに（ａ）、納付者のＰＣに表れる初期画面Ｗ１は図３８に例示したものと同様である。すなわち、納付者は納付通知書に記載されている納付番号（図１５参照）等、必要事項を入力して納付状況問合せボタンをクリックすると、未納付のときは、図３９の納付手続続行画面Ｗ２に移動し、納付済みのときは、図４０の二重納付防止画面（回答情報）Ｗ３に移動する（ｄ）。
【０１０２】
また、図４１に、自治体（の職員）が納付者からの問合せを受けてセンターに照会する場合に（ｆ）、自治体のシステムに表れる検索条件指定画面Ｗ４を例示し、図４２に、センターからの回答情報（図２８）を受けて自治体のシステムに表れる検索結果画面（検索日付時刻付）Ｗ５を例示した（ｇ）。
【０１０３】
なお、図４１及び図４２は、納付番号（つまり案件）を指定しないで、納付者だけで検索した場合を示すが、図４１の検索条件指定画面Ｗ４で納付番号（納付者から聞いて）を指定すると、図４２の検索結果画面Ｗ５ではその案件のみの結果が表示されるようになっている。
【０１０４】
以下、図２８〜図３７のフローチャートに従って、前記システム１０の具体的動作をさらに詳しく説明する。これらのフローチャートは、本発明に係る公金収納管理システム用プログラムの実施の形態をフローチャートの態様で提供するものである。
【０１０５】
まず、図２８は、システム１０が基本情報の受信時に行う動作のフローチャートである。すなわち、ステップＳ１１で、基本情報を受信すると、ステップＳ１２で、受信した案件毎に乱数を用いて納付番号を採番し、ステップＳ１３で、受信した基本情報に納付番号とコンビニ収納キー（納付番号を含んでいる）と窓口収納キー（納付番号を含んでいる）とを追加して案件毎に基本情報ＤＢに登録する。次いで、ステップＳ１４で、基本情報ＤＢに基き納付通知書を作成した後、ステップＳ１５で、基本情報ＤＢの登録内容に基き納付情報ＤＢを案件毎に作成する。
【０１０６】
次に、図２９は、システム１０が窓口収納情報の登録時に行う動作のフローチャートである。すなわち、ステップＳ２１で、納付済通の記載内容を入力した後、ステップＳ２２で、入力した情報（つまり窓口納付情報）を窓口収納キーをキーにして納付情報ＤＢに登録する。
【０１０７】
次に、図３０は、システム１０が消込情報の送信時に行う動作のフローチャートである。すなわち、ステップＳ３１で、公金取扱機関別の入金情報を自治体指定の金融機関から受信したうえで、ステップＳ３２で、今日が資金化日である全案件を納付情報ＤＢから抽出し、ステップＳ３３で、抽出した案件の納付情報に含まれている納付金額を公金取扱機関別に合計する。次いで、ステップＳ３４で、合計した公金取扱機関別の納付金額と、公金取扱機関別の入金情報とを突合し、差異の無いことを確認する。そして、ステップＳ３５で、納付番号にて基本情報ＤＢを検索し、各案件の納付書コードを読み出した後、ステップＳ３６で、読み出した納付書コードを付して、今日が資金化日の全案件を統合した消込情報を所定の統一された形式で作成して、自治体側へ送信する。
【０１０８】
次に、図３１は、システム１０がコンビニ収納の場合において仮消込情報（速報）の送信時に行う動作のフローチャートである。すなわち、ステップＳ４１で、コンビニ納付手続情報を受信すると、ステップＳ４２で、受信した情報をコンビニ収納キーをキーにして納付情報ＤＢに登録する。次いで、ステップＳ４３で、今日、コンビニ納付手続情報を受信した全案件を納付情報ＤＢから抽出し、ステップＳ４４で、抽出した案件を公金取扱機関（この場合はコンビニエンスストア）毎に統合する。そして、ステップＳ４５で、納付番号にて基本情報ＤＢを検索し、各案件の納付書コードを読み出した後、ステップＳ４６で、読み出した納付書コードを付して、今日、コンビニ納付手続情報を受信した全案件を公金取扱機関（この場合はコンビニエンスストア）毎に統合した仮消込情報（速報）を所定の統一された形式で作成して、自治体側へ送信する。
【０１０９】
次に、図３２は、システム１０が資金化日の決定時に行う動作のフローチャートである。すなわち、ステップＳ５１で、公金納付手続日と資金化日との関係を公金取扱機関毎に資金化日ＤＢに記録し、ステップＳ５２で、公金取扱機関から受信した納付情報に資金化日が含まれているか否かを判定し、含まれているときはそのままエンドとなるが、含まれていないときは、ステップＳ５３で、納付情報に含まれている納付手続日及び公金取扱機関と、資金化日ＤＢに記録されている公金納付手続日と資金化日との関係とから、資金化日を決定する。
【０１１０】
次に、図３３は、システム１０がコンビニ収納の場合において仮消込情報（確報）の送信時に行う動作のフローチャートである。すなわち、ステップＳ６１で、コンビニ収納確認情報を受信すると、ステップＳ６２で、受信した情報をコンビニ収納キーをキーにして納付情報ＤＢに登録する。次いで、ステップＳ６３で、今日、コンビニ納付確認情報を受信した全案件を納付情報ＤＢから抽出し、ステップＳ６４で、抽出した案件を公金取扱機関（この場合はコンビニエンスストア）毎に統合する。そして、ステップＳ６５で、納付番号にて基本情報ＤＢを検索し、各案件の納付書コードを読み出した後、ステップＳ６６で、読み出した納付書コードを付して、今日、コンビニ納付確認情報を受信した全案件を公金取扱機関（この場合はコンビニエンスストア）毎に統合した仮消込情報（確報）を所定の統一された形式で作成して、自治体側へ送信する。
【０１１１】
次に、図３４は、システム１０が同じくインターネットバンキングによるＷＥＢ電子収納の場合において仮消込情報（速報）の送信時に行う動作のフローチャートである。すなわち、ステップＳ７１で、インターネットバンキング納付手続情報を受信すると、ステップＳ７２で、受信した情報を納付番号をキーにして納付情報ＤＢに登録する。次いで、ステップＳ７３で、今日、インターネットバンキング納付手続情報を受信した全案件を納付情報ＤＢから抽出し、ステップＳ７４で、抽出した案件を公金取扱機関（この場合は納付者取引金融機関）毎に統合する。そして、ステップＳ７５で、納付番号にて基本情報ＤＢを検索し、各案件の納付書コードを読み出した後、ステップＳ７６で、読み出した納付書コードを付して、今日、インターネットバンキング納付手続情報を受信した全案件を公金取扱機関（この場合は納付者取引金融機関）毎に統合した仮消込情報（速報）を所定の統一された形式で作成して、自治体側へ送信する。
【０１１２】
次に、図３５は、システム１０が同じくインターネットバンキングによるＷＥＢ電子収納の場合において仮消込情報（確報）の送信時に行う動作のフローチャートである。すなわち、ステップＳ８１で、インターネットバンキング納付確認情報を受信すると、ステップＳ８２で、受信した情報を納付番号をキーにして納付情報ＤＢに登録する。次いで、ステップＳ８３で、今日、インターネットバンキング納付確認情報を受信した全案件を納付情報ＤＢから抽出し、ステップＳ８４で、抽出した案件を公金取扱機関（この場合は納付者取引金融機関）毎に統合する。そして、ステップＳ８５で、納付番号にて基本情報ＤＢを検索し、各案件の納付書コードを読み出した後、ステップＳ８６で、読み出した納付書コードを付して、今日、インターネットバンキング納付確認情報を受信した全案件を公金取扱機関（この場合は納付者取引金融機関）毎に統合した仮消込情報（確報）を所定の統一された形式で作成して、自治体側へ送信する。
【０１１３】
次に、図３６は、システム１０が同じくクレジットカードによるＷＥＢ電子収納の場合において仮消込情報（速報兼確報）の送信時に行う動作のフローチャートである。すなわち、ステップＳ９１で、クレジット納付手続兼確認情報を受信すると、ステップＳ９２で、受信した情報を納付番号をキーにして納付情報ＤＢに登録する。次いで、ステップＳ９３で、今日、クレジット納付手続兼確認情報を受信した全案件を納付情報ＤＢから抽出し、ステップＳ９４で、抽出した案件を公金取扱機関（この場合はクレジット会社）毎に統合する。そして、ステップＳ９５で、納付番号にて基本情報ＤＢを検索し、各案件の納付書コードを読み出した後、ステップＳ９６で、読み出した納付書コードを付して、今日、クレジット納付手続兼確認情報を受信した全案件を公金取扱機関（この場合はクレジット会社）毎に統合した仮消込情報（速報兼確報）を所定の統一された形式で作成して、自治体側へ送信する。
【０１１４】
最後に、図３７は、システム１０が同じく納付状況の問合せ受信時に行う動作のフローチャートである。すなわち、ステップＳ１０１で、収納センター又は自治体から納付状況の問合せを受信すると、ステップＳ１０２で、問合せの納付番号にて納付情報ＤＢを検索し、そして、ステップＳ１０３で、納付者からの問合せが公金取扱機関（ＭＰＮ収納センター又はクレジット収納センター）経由のときは、納付者の特定情報を含まない回答情報を作成し、一方、納付者からの問合せが自治体経由のときは、納付者の口座情報及びクレジットカード情報を含まない回答情報を作成して、ステップＳ１０４で、作成した回答情報を問合せ元（収納センター又は自治体）へ送信する。
【０１１５】
以上のように、本実施形態に係る公金収納管理システム１０においては、自治体の公金収納を管理するにあたり、基本情報受取手段（Ｓ１１）が、公金を収納するために必要な情報（図１４参照）を自治体から受け取り、基本情報記録手段（Ｓ１３）が、基本情報受取手段が受け取った情報を案件毎（納付書コード毎）に記録し（図２参照）、納付情報受取手段（Ｓ２１、Ｓ４１、Ｓ６１、Ｓ７１、Ｓ８１、Ｓ９１）が、納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報（図１６、図１８、図２０、図２２、図２３、図２４参照）を公金取扱機関から受け取り、報告情報作成手段（Ｓ３６）が、基本情報記録手段が情報を記録した案件のうち、納付情報受取手段が納付情報を受け取った案件について、納付情報受取手段が受け取った納付情報に基いて、自治体へ報告する情報（図１７参照）を所定の統一された形式で作成し、そして、報告情報送り手段（Ｓ３６）が、報告情報作成手段が作成した情報（図１７参照）を自治体へ送るから、自治体が受け取る情報の形式が公金取扱機関の種類に関係なく統一されることとなり、その結果、自治体の側での情報の取扱いが容易となって、当該公金収納管理システム１０の信頼性ないし商品性の向上が図られることとなる。
【０１１６】
また、本実施形態に係る公金収納管理システム１０においては、報告情報作成手段（Ｓ３６）が、納付者がいずれの公金取扱機関を介して公金の納付手続をしたか（収納チャネル：符号ケ、収納会社：符号コ）を含む情報（図１７参照）を作成すると共に、納付者がインターネットバンキング又はクレジット決済による公金取扱機関を介して公金の納付手続をした場合であっても、納付者の口座情報（図１１の符号（２））及びクレジットカード情報（図１２の符号（２））を含まない情報を作成するから、たとえ納付者がインターネットバンキングやクレジット決済を利用して公金の納付手続をしても、納付者の口座情報やクレジットカード情報といった重要情報が不用意に自治体の側へ流れることがなくなり、この点において、十全な情報漏洩リスクの低減が図られることとなる。
【０１１７】
また、本実施形態に係る公金収納管理システム１０においては、納付情報記録手段（Ｓ２２、Ｓ４２、Ｓ６２、Ｓ７２、Ｓ８２、Ｓ９２）が、納付情報受取手段が受け取った納付情報（図１６、図１８、図２０、図２２、図２３、図２４参照）を案件毎に記録し、問合せ受付手段（Ｓ１０１）が、公金の納付手続が済んでいるか否かの問合せを受け付け、納付情報検索手段（Ｓ１０２）が、問合せ受付手段が問合せを受け付けた案件毎に納付情報記録手段が記録した納付情報（図３参照）を検索し、回答情報作成手段（Ｓ１０３）が、納付情報検索手段が検索した情報に基いて回答情報（図２６、図２７参照）を作成すると共に、問合せ受付手段が受け付けた問合せが、公金取扱機関を経由した納付者からの問合せであるときは、納付者に関する情報のうち特定の情報を含まない回答情報を作成し（図２６参照）、問合せ受付手段が受け付けた問合せが、自治体を経由した納付者からの問合せであるときは、納付者の口座情報及びクレジットカード情報を含まない回答情報（図２７参照）を作成し、そして、回答情報送り手段（Ｓ１０４）が、回答情報作成手段が作成した回答情報を公金取扱機関又は自治体へ送るから、例えば公金取扱機関の側へは、回答情報に付随して、納付者の住所や生年月日あるいは世帯コード等の納付者に関する情報のうち特定の情報が流れることがなくなり、一方、自治体の側へは、回答情報に付随して、納付者の口座情報及びクレジットカード情報等の重要情報が流れることがなくなって、この点において、十全な情報漏洩リスクの低減が図られることとなる。
【０１１８】
また、本実施形態に係る公金収納管理システム１０においては、納付通知書作成手段（Ｓ１４）が、基本情報記録手段が記録した情報（図２参照）に基いて納付者へ送る納付通知書（図１５参照）を作成するから、自治体の側で納付通知書を作成する手間が省けることとなる。
【０１１９】
また、本実施形態に係る公金収納管理システム１０においては、案件特定コード設定手段（Ｓ１２）が、基本情報記録手段が情報を記録した案件毎に、案件を特定するコード（納付番号：符号ウ、ひいては、コンビニ収納キー：符号エ、及び、窓口収納キー：符号オ）を乱数を用いて設定し、そして、納付通知書作成手段（Ｓ１４）が、案件特定コード設定手段が設定したコードを付した納付通知書を作成するから、案件特定コード設定手段が設定するコードが複雑化し、案件特定コード設定手段が設定した案件特定コードから個人を特定することが困難となり、その結果、例えば、納付者が公金の納付手続時に自己の案件特定コード（納付番号：符号ウ）を誤って入力したときには、該当者無しというような警告が出るようになり、納付者が公金の納付手続時に自己の案件特定コードを誤って入力したときに他人のコードに該当してその他人の情報が漏洩するというようなリスクが低減されることとなる。
【０１２０】
また、本実施形態に係る公金収納管理システム１０においては、納付情報受取手段（Ｓ４１、Ｓ６１、Ｓ７１、Ｓ８１）が、納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報として、納付者が公金取扱機関を介して公金の納付手続をしたという手続情報（図１８、図２２）及び自治体の口座へ入金する資金が準備されたという確認情報（図２０、図２３）の２種類の情報を相前後して受け取り、報告情報作成手段（Ｓ４６、Ｓ７６）が、納付情報受取手段が前記手続情報を受け取った時点で、該手続情報に基いて、納付者が公金の納付手続をしたことを自治体へ連絡する旨の情報を作成し、そして、報告情報送り手段（Ｓ４６、Ｓ７６）が、報告情報作成手段が前記情報を作成した時点で、該情報を自治体へ送るから、自治体の側では、納付者が所定の公金取扱機関を介して公金の納付手続をした段階で早期にその情報を得ることができ、その結果、自治体がすでに公金の納付手続をした納付者に誤って督促状を出してしまう、という問題が解消されることとなる。
【０１２１】
なお、前記実施形態は、本発明の最良の実施形態であるが、特許請求の範囲を逸脱しない限り、さらに種々の変更や改良を加えることができることはいうまでもない。
【産業上の利用可能性】
【０１２２】
以上、具体例を挙げて詳しく説明したように、本発明は、納付者が様々な公金取扱機関を介して公金の納付手続をしたことに起因して発生する種々の納付情報を自治体の側での取扱いが容易となるように自治体へ送ることが可能な技術であるから、また、納付者個人の重要情報が不用意に漏洩しないように対策できる技術であるから、さらに、納付者からの問合せに円滑に対応できるように対策できる技術であるから、コンピュータを用いた情報処理の技術分野、特に、自治体が徴収する自動車税や固定資産税あるいは水道料金等の公金の収納を管理する技術分野において広範な産業上の利用可能性が期待される。
【図面の簡単な説明】
【０１２３】
【図１】本発明の最良の実施の形態に係る公金収納管理システムの構成及び周辺環境を示すブロック図である。
【図２】前記公金収納管理システムが備える基本情報データベースの構造図である。
【図３】同じく納付情報データベースの構造図（状況区分の移り変り状態を含む）である。
【図４】同じく資金化日データベースの構造図である。
【図５】納付手続日が同じでも公金取扱機関が異なると資金化日が異なる例を示すチャート図である。
【図６】公金取扱機関が異なっても資金化日が同じになる例を示すチャート図である。
【図７】納付通知書の作成動作を示すブロック図である。
【図８】指定金融機関での窓口収納の場合における、自治体、公金収納管理センター、納付者及び公金取扱機関の動作を示すブロック図である。
【図９】非指定金融機関での窓口収納の場合における、自治体、公金収納管理センター、納付者及び公金取扱機関の動作を示すブロック図である。
【図１０】コンビニ収納の場合における、自治体、公金収納管理センター、納付者及び公金取扱機関の動作を示すブロック図である。
【図１１】インターネットバンキングによるＷＥＢ電子収納の場合における、自治体、公金収納管理センター、納付者及び公金取扱機関の動作を示すブロック図である。
【図１２】クレジットカードによるＷＥＢ電子収納の場合における、自治体、公金収納管理センター、納付者及び公金取扱機関の動作を示すブロック図である。
【図１３】納付状況の問合せ時における、自治体、公金収納管理センター、納付者及び公金取扱機関の動作を示すブロック図である。
【図１４】自治体から公金収納管理センターへ送られる基本情報の構造図である。
【図１５】公金収納管理センターから納付者へ送られる納付通知書の構造図である。
【図１６】公金収納管理センターでデータ化される窓口納付情報の構造図である。
【図１７】公金収納管理センターから自治体へ送られる消込情報の構造図である。
【図１８】コンビニエンスストア収納代行会社から公金収納管理センターへ送られるコンビニ納付手続情報の構造図である。
【図１９】公金収納管理センターから自治体へ送られる仮消込情報（速報）の構造図である。
【図２０】コンビニエンスストア収納代行会社から公金収納管理センターへ送られるコンビニ納付確認情報の構造図である。
【図２１】公金収納管理センターから自治体へ送られる仮消込情報（確報）の構造図である。
【図２２】マルチペイメントネットワーク収納センターから公金収納管理センターへ送られるインターネットバンキング納付手続情報の構造図である。
【図２３】マルチペイメントネットワーク収納センターから公金収納管理センターへ送られるインターネットバンキング納付確認情報の構造図である。
【図２４】クレジット収納センターからクレジット納付手続兼確認情報の構造図である。
【図２５】自治体から公金収納管理センターへ送られる納付済情報の構造図である。
【図２６】公金収納管理センターからマルチペイメントネットワーク収納センター又はクレジット収納センターへ送られる回答情報の構造図である。
【図２７】公金収納管理センターから自治体へ送られる回答情報の構造図である。
【図２８】公金収納管理システムが基本情報の受信時に行う動作のフローチャートである。
【図２９】同じく窓口納付情報の登録時に行う動作のフローチャートである。
【図３０】同じく消込情報の送信時に行う動作のフローチャートである。
【図３１】同じくコンビニ収納の場合において仮消込情報（速報）の送信時に行う動作のフローチャートである。
【図３２】同じく資金化日の決定時に行う動作のフローチャートである。
【図３３】同じくコンビニ収納の場合において仮消込情報（確報）の送信時に行う動作のフローチャートである。
【図３４】同じくインターネットバンキングによるＷＥＢ電子収納の場合において仮消込情報（速報）の送信時に行う動作のフローチャートである。
【図３５】同じくインターネットバンキングによるＷＥＢ電子収納の場合において仮消込情報（確報）の送信時に行う動作のフローチャートである。
【図３６】同じくクレジットカードによるＷＥＢ電子収納の場合において仮消込情報（速報兼確報）の送信時に行う動作のフローチャートである。
【図３７】同じく納付状況の問合せ受信時に行う動作のフローチャートである。
【図３８】納付者がインターネットバンキングによるＷＥＢ電子収納を行う場合に納付者のＰＣに表れる初期画面である。
【図３９】同じく納付手続きを進める場合に納付者のＰＣに表れる画面である。
【図４０】同じく二重納付を防止して納付手続きを中止する場合に納付者のＰＣに表れる画面である。
【図４１】自治体が納付者からの問合せを受けて公金収納管理センターに照会する場合に自治体のシステムに表れる検索条件指定画面である。
【図４２】同じく自治体のシステムに表れる検索結果画面（検索日付時刻付）である。
【符号の説明】
【０１２４】
１０ 公金収納管理システム
１１ 中央処理装置
１２ 入力装置
１３ 出力装置
１４ 通信装置
１５ 記録装置
３１〜３５ コンピュータネットワーク
【技術分野】
【０００１】
本発明は、税金や公共料金等の公金の収納を管理するためのシステム、方法及びプログラムに関し、コンピュータを用いた情報処理の技術分野に属する。
【背景技術】
【０００２】
従来、コンピュータを用いて、自治体が徴収する自動車税や固定資産税あるいは水道料金等の公金の収納を管理する技術が知られている。例えば、特許文献１には、自治体から送信された公金徴収情報に基いて納付義務者毎の公金徴収データを生成し、前記公金徴収データに各データを特定するコード情報を付与した後、前記公金徴収データを反映させた納入通知書を印刷する総合収納管理システムが開示されている。
【０００３】
この総合収納管理システムは、公金納付情報を収納情報としてデータ蓄積手段に蓄積するようになっており、前記納入通知書を受け取った納付義務者が該納入通知書に従って納付をしたときに、その公金納付情報を公金取扱機関から取得し、前記公金納付情報と同内容の収納情報が既にデータ蓄積手段に蓄積されているか否かを照会する。そして、蓄積されていないときは、前記公金納付情報を収納情報としてデータ蓄積手段に蓄積する一方で、蓄積されているときは、２回目の公金納付になるため、収納処理を停止し、これにより、複数の公金取扱機関を介しての公金収納に対応可能であり、かつ公金の二重収納の防止が図られた公金収納管理システムが実現されている。
【０００４】
【特許文献１】特開２００６−９９５０８（段落００２１〜００２３、００２６、００５５）
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ところで、この種の公金収納管理システムは、一般に、自治体と公金取扱機関との間にあって、自治体側と公金取扱機関側との双方から発せられた種々の情報が集中する。したがって、受け取った情報をいったんシステム内に溜め置き、整理し、その中から必要な情報を、必要とする側へ、適正な時期に送ることが望まれている。特に、近年は、納付機会の拡大、納付率の向上及び納付者便宜の増大を図るため、銀行や郵便局等の金融機関の窓口だけでなく、コンビニエンスストアや、インターネットバンキング及びクレジットカードのＷＥＢサイト等、納付者が公金の納付に用いることができる公金取扱機関の種類が増えているので、さらに多方面からの情報の集中が著しい傾向にある。
【０００６】
一方、自治体の側では、督促状の準備や消込作業の準備のために、どの納付者のどの公金がどの公金取扱機関を介していつ納付手続されたか、そしてそれによりいつ自治体の口座へ資金が移動するかといった、納付者が公金の納付手続をしたことに起因して発生する種々の納付情報を必要としている。このような状況の下、公金収納管理システムが、公金取扱機関から受け取った納付情報を公金取扱機関毎に異なる形式で自治体へ送っていたのでは、自治体が受け取る納付情報の形式がバラバラとなり、その結果、自治体の側で納付情報の取扱いが極めて不便なものとなって、当該公金収納管理システムの信頼性ないし商品性が損なわれてしまう、という問題がある。
【０００７】
そこで、本発明は、納付者が様々な公金取扱機関を介して公金の納付手続をしたことに起因して発生する種々の納付情報を自治体の側での取扱いが容易となるように自治体へ送ることが可能な公金収納管理システム、公金収納管理方法及び公金収納管理用プログラムの提供を課題とする。
【０００８】
また、前述したように、この種の公金収納管理システムは、自治体からの情報及び公金取扱機関からの情報が集中するので、納付者個人の重要情報が不用意に漏洩しないように対策する必要がある。さらに、納付者が自己の公金の納付手続が済んでいるか否かの問合せを公金取扱機関や自治体にする場合があり、そのときの問合せに円滑に対応できるように対策する必要もある。
【０００９】
そこで、本発明は、納付者個人の重要情報が不用意に漏洩しないように対策すること、及び、納付者からの問合せに円滑に対応できるように対策することも課題とする。
【課題を解決するための手段】
【００１０】
前記課題を解決するため、本発明では次のような手段を用いる。
【００１１】
まず、請求項１に記載の発明は、自治体の公金収納を管理するシステムであって、公金を収納するために必要な情報を自治体から受け取る基本情報受取手段、この基本情報受取手段が受け取った情報を案件毎に記録する基本情報記録手段、納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報を前記公金取扱機関から受け取る納付情報受取手段、前記基本情報記録手段が情報を記録した案件のうち、前記納付情報受取手段が納付情報を受け取った案件について、該納付情報受取手段が受け取った納付情報に基いて、自治体へ報告する情報を所定の統一された形式で作成する報告情報作成手段、及び、この報告情報作成手段が作成した情報を自治体へ送る報告情報送り手段が備えられていることを特徴とする。
【００１２】
次に、請求項２に記載の発明は、請求項１に記載の公金収納管理システムであって、前記報告情報作成手段は、納付者がいずれの公金取扱機関を介して公金の納付手続をしたかを含む情報を作成すると共に、納付者がインターネットバンキング又はクレジット決済による公金取扱機関を介して公金の納付手続をした場合であっても、納付者の口座情報及びクレジットカード情報を含まない情報を作成することを特徴とする。
【００１３】
次に、請求項３に記載の発明は、請求項１又は２に記載の公金収納管理システムであって、前記納付情報受取手段が受け取った納付情報を案件毎に記録する納付情報記録手段、公金の納付手続が済んでいるか否かの問合せを受け付ける問合せ受付手段、この問合せ受付手段が問合せを受け付けた案件毎に前記納付情報記録手段が記録した納付情報を検索する納付情報検索手段、この納付情報検索手段が検索した納付情報に基いて回答情報を作成すると共に、前記問合せ受付手段が受け付けた問合せが、公金取扱機関を経由した納付者からの問合せであるときは、納付者に関する情報のうち特定の情報を含まない回答情報を作成し、前記問合せ受付手段が受け付けた問合せが、自治体を経由した納付者からの問合せであるときは、納付者の口座情報及びクレジットカード情報を含まない回答情報を作成する回答情報作成手段、及び、この回答情報作成手段が作成した回答情報を公金取扱機関又は自治体へ送る回答情報送り手段が備えられていることを特徴とする。
【００１４】
次に、請求項４に記載の発明は、請求項１から３のいずれかに記載の公金収納管理システムであって、前記基本情報記録手段が記録した情報に基いて納付者へ送る納付通知書を作成する納付通知書作成手段が備えられていることを特徴とする。
【００１５】
次に、請求項５に記載の発明は、請求項４に記載の公金収納管理システムであって、前記基本情報記録手段が情報を記録した案件毎に、案件を特定するコードを乱数を用いて設定する案件特定コード設定手段が備えられ、前記納付通知書作成手段は、この案件特定コード設定手段が設定したコードを付した納付通知書を作成することを特徴とする。
【００１６】
次に、請求項６に記載の発明は、請求項１から５のいずれかに記載の公金収納管理システムであって、前記納付情報受取手段は、納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報として、納付者が公金取扱機関を介して公金の納付手続をしたという手続情報及び自治体の口座へ入金する資金が準備されたという確認情報の２種類の情報を相前後して受け取り、前記報告情報作成手段は、前記納付情報受取手段が前記手続情報を受け取った時点で、該手続情報に基いて、納付者が公金の納付手続をしたことを自治体へ連絡する旨の情報を作成し、前記報告情報送り手段は、前記報告情報作成手段が前記情報を作成した時点で、該情報を自治体へ送ることを特徴とする。
【００１７】
なお、前記請求項１〜６に記載の公金収納管理システムの各手段は、コンピュータの中央処理装置、入力装置、出力装置、通信装置、記録装置等のハードウエア資源と、これらのハードウエア資源を用いて各手段の動作を実現するプログラムとによって構成される。
【００１８】
次に、請求項７に記載の発明は、自治体の公金収納を管理する方法であって、コンピュータを用いて、公金を収納するために必要な情報を自治体から受け取る基本情報受取工程、この基本情報受取工程で受け取った情報を案件毎に記録する基本情報記録工程、納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報を前記公金取扱機関から受け取る納付情報受取工程、前記基本情報記録工程で情報を記録した案件のうち、前記納付情報受取工程で納付情報を受け取った案件について、該納付情報受取工程で受け取った納付情報に基いて、自治体へ報告する情報を所定の統一された形式で作成する報告情報作成工程、及び、この報告情報作成工程で作成した情報を自治体へ送る報告情報送り工程を行うことを特徴とする。
【００１９】
次に、請求項８に記載の発明は、自治体の公金収納を管理するためのプログラムであって、コンピュータを、公金を収納するために必要な情報を自治体から受け取る基本情報受取手段、この基本情報受取手段が受け取った情報を案件毎に記録する基本情報記録手段、納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報を前記公金取扱機関から受け取る納付情報受取手段、前記基本情報記録手段が情報を記録した案件のうち、前記納付情報受取手段が納付情報を受け取った案件について、該納付情報受取手段が受け取った納付情報に基いて、自治体へ報告する情報を所定の統一された形式で作成する報告情報作成手段、及び、この報告情報作成手段が作成した情報を自治体へ送る報告情報送り手段として機能させることを特徴とする。
【００２０】
次に、請求項９に記載の発明は、請求項８に記載の公金収納管理用プログラムであって、コンピュータを前記報告情報作成手段として機能させるときは、納付者がいずれの公金取扱機関を介して公金の納付手続をしたかを含む情報を作成すると共に、納付者がインターネットバンキング又はクレジット決済による公金取扱機関を介して公金の納付手続をした場合であっても、納付者の口座情報及びクレジットカード情報を含まない情報を作成するように機能させることを特徴とする。
【００２１】
次に、請求項１０に記載の発明は、請求項８又は９に記載の公金収納管理用プログラムであって、コンピュータを、前記納付情報受取手段が受け取った納付情報を案件毎に記録する納付情報記録手段、公金の納付手続が済んでいるか否かの問合せを受け付ける問合せ受付手段、この問合せ受付手段が問合せを受け付けた案件毎に前記納付情報記録手段が記録した納付情報を検索する納付情報検索手段、この納付情報検索手段が検索した納付情報に基いて回答情報を作成すると共に、前記問合せ受付手段が受け付けた問合せが、公金取扱機関を経由した納付者からの問合せであるときは、納付者に関する情報のうち特定の情報を含まない回答情報を作成し、前記問合せ受付手段が受け付けた問合せが、自治体を経由した納付者からの問合せであるときは、納付者の口座情報及びクレジットカード情報を含まない回答情報を作成する回答情報作成手段、及び、この回答情報作成手段が作成した回答情報を公金取扱機関又は自治体へ送る回答情報送り手段として機能させることを特徴とする。
【００２２】
次に、請求項１１に記載の発明は、請求項８から１０のいずれかに記載の公金収納管理用プログラムであって、コンピュータを、前記基本情報記録手段が記録した情報に基いて納付者へ送る納付通知書を作成する納付通知書作成手段として機能させることを特徴とする。
【００２３】
次に、請求項１２に記載の発明は、請求項１１に記載の公金収納管理用プログラムであって、コンピュータを、前記基本情報記録手段が情報を記録した案件毎に、案件を特定するコードを乱数を用いて設定する案件特定コード設定手段として機能させると共に、コンピュータを前記納付通知書作成手段として機能させるときは、この案件特定コード設定手段が設定したコードを付した納付通知書を作成するように機能させることを特徴とする。
【００２４】
次に、請求項１３に記載の発明は、請求項８から１２のいずれかに記載の公金収納管理用プログラムであって、コンピュータを前記納付情報受取手段として機能させるときは、納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報として、納付者が公金取扱機関を介して公金の納付手続をしたという手続情報及び自治体の口座へ入金する資金が準備されたという確認情報の２種類の情報を相前後して受け取るように機能させ、コンピュータを前記報告情報作成手段として機能させるときは、前記納付情報受取手段が前記手続情報を受け取った時点で、該手続情報に基いて、納付者が公金の納付手続をしたことを自治体へ連絡する旨の情報を作成するように機能させ、コンピュータを前記報告情報送り手段として機能させるときは、前記報告情報作成手段が前記情報を作成した時点で、該情報を自治体へ送るように機能させることを特徴とする。
【発明の効果】
【００２５】
まず、請求項１に記載の発明によれば、自治体の公金収納を管理するシステムにおいて、基本情報受取手段が、公金を収納するために必要な情報を自治体から受け取り、基本情報記録手段が、基本情報受取手段が受け取った情報を案件毎に記録し、納付情報受取手段が、納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報を公金取扱機関から受け取り、報告情報作成手段が、基本情報記録手段が情報を記録した案件のうち、納付情報受取手段が納付情報を受け取った案件について、納付情報受取手段が受け取った納付情報に基いて、自治体へ報告する情報を所定の統一された形式で作成し、そして、報告情報送り手段が、報告情報作成手段が作成した情報を自治体へ送るから、自治体が受け取る情報の形式が公金取扱機関の種類に関係なく統一されることとなり、その結果、自治体の側での情報の取扱いが容易となって、当該公金収納管理システムの信頼性ないし商品性の向上が図られることとなる。
【００２６】
次に、請求項２に記載の発明によれば、報告情報作成手段が、納付者がいずれの公金取扱機関を介して公金の納付手続をしたかを含む情報を作成すると共に、納付者がインターネットバンキング又はクレジット決済による公金取扱機関を介して公金の納付手続をした場合であっても、納付者の口座情報及びクレジットカード情報を含まない情報を作成するから、たとえ納付者がインターネットバンキングやクレジット決済を利用して公金の納付手続をしても、納付者の口座情報やクレジットカード情報といった重要情報が不用意に自治体の側へ流れることがなくなり、この点において、十全な情報漏洩リスクの低減が図られることとなる。
【００２７】
次に、請求項３に記載の発明によれば、納付情報記録手段が、納付情報受取手段が受け取った納付情報を案件毎に記録し、問合せ受付手段が、公金の納付手続が済んでいるか否かの問合せを受け付け、納付情報検索手段が、問合せ受付手段が問合せを受け付けた案件毎に納付情報記録手段が記録した納付情報を検索し、回答情報作成手段が、納付情報検索手段が検索した情報に基いて回答情報を作成すると共に、問合せ受付手段が受け付けた問合せが、公金取扱機関を経由した納付者からの問合せであるときは、納付者に関する情報のうち特定の情報を含まない回答情報を作成し、問合せ受付手段が受け付けた問合せが、自治体を経由した納付者からの問合せであるときは、納付者の口座情報及びクレジットカード情報を含まない回答情報を作成し、そして、回答情報送り手段が、回答情報作成手段が作成した回答情報を公金取扱機関又は自治体へ送るから、例えば公金取扱機関の側へは、回答情報に付随して、納付者の住所や生年月日あるいは世帯コード等の納付者に関する情報のうち特定の情報が流れることがなくなり、一方、自治体の側へは、回答情報に付随して、納付者の口座情報及びクレジットカード情報等の重要情報が流れることがなくなって、この点において、十全な情報漏洩リスクの低減が図られることとなる。
【００２８】
次に、請求項４に記載の発明によれば、納付通知書作成手段が、基本情報記録手段が記録した情報に基いて納付者へ送る納付通知書を作成するから、自治体の側で納付通知書を作成する手間が省けることとなる。
【００２９】
次に、請求項５に記載の発明によれば、案件特定コード設定手段が、基本情報記録手段が情報を記録した案件毎に、案件を特定するコードを乱数を用いて設定し、そして、納付通知書作成手段が、案件特定コード設定手段が設定したコードを付した納付通知書を作成するから、案件特定コード設定手段が設定するコードが複雑化し、案件特定コード設定手段が設定した案件特定コードから個人を特定することが困難となり、その結果、例えば、納付者が公金の納付手続時に自己の案件特定コードを誤って入力したときには、該当者無しというような警告が出るようになり、納付者が公金の納付手続時に自己の案件特定コードを誤って入力したときに他人のコードに該当してその他人の情報が漏洩するというようなリスクが低減されることとなる。
【００３０】
次に、請求項６に記載の発明によれば、納付情報受取手段が、納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報として、納付者が公金取扱機関を介して公金の納付手続をしたという手続情報及び自治体の口座へ入金する資金が準備されたという確認情報の２種類の情報を相前後して受け取り、報告情報作成手段が、納付情報受取手段が前記手続情報を受け取った時点で、該手続情報に基いて、納付者が公金の納付手続をしたことを自治体へ連絡する旨の情報を作成し、そして、報告情報送り手段が、報告情報作成手段が前記情報を作成した時点で、該情報を自治体へ送るから、自治体の側では、納付者が所定の公金取扱機関を介して公金の納付手続をした段階で早期にその情報を得ることができ、その結果、自治体がすでに公金の納付手続をした納付者に誤って督促状を出してしまう、という問題が解消されることとなる。
【００３１】
次に、請求項７に記載の発明によれば、自治体の公金収納を管理する方法において、コンピュータを用いて、請求項１に記載の各手段が行う工程と同様の工程を行うから、請求項１に記載の公金収納管理システムと同様の効果が得られることとなる。
【００３２】
次に、請求項８から１３に記載の発明によれば、自治体の公金収納を管理するためのプログラムにおいて、コンピュータを、請求項１から６に記載の各手段として機能させるから、このプログラムをコンピュータに搭載すれば、請求項１から６に記載の公金収納管理システムと同様のシステム及び効果が得られることとなる。
【発明を実施するための最良の形態】
【００３３】
以下、図面に基き、本発明の最良の実施の形態を説明する。なお、本実施形態に係る公金収納管理システムは、本発明に係る公金収納管理システムを構成し、本実施形態に係る公金収納管理システムが行う動作は、本発明に係る公金収納管理方法の実施の形態を構成し、本実施形態に係る公金収納管理システムに搭載されているプログラムは、本発明に係る公金収納管理システム用プログラムの実施の形態を構成する。
【００３４】
図１に示すように、本実施形態に係る公金収納管理システム（以下単に「システム」という）１０は、例えば自治体の公金収納業務を代行するために設立された機関である公金収納管理センター（以下単に「センター」という）に備えられている。このシステム１０は、銀行や郵便局の窓口、コンビニエンスストア、インターネットバンキング及びクレジットカードのＷＥＢ収納サイト等の、複数の公金取扱機関を介しての公金収納に対応可能なものである。
【００３５】
システム１０は、コンピュータで構成され、ＣＰＵ等の中央処理装置１１、外部から情報を入力するためのキーボード等の入力装置１２、外部へ情報を出力するためのディスプレイやプリンタ等の出力装置１３、外部機器との情報通信を管理するための通信装置１４、及び、各種プログラムやデータを記録するためのメインメモリやＲＯＭ、ＲＡＭ等の記録装置１５等が、バスを介して相互に接続されている。
【００３６】
記録装置１５は、プログラムが記録されるプログラム記録部１５ａと、データが記録されるデータ記録部１５ｂとを有し、データ記録部１５ｂには、基本情報ＤＢ（データベース：以下同じ）、納付情報ＤＢ、及び資金化日ＤＢが格納されている。
【００３７】
システム１０は、例えば専用のコンピュータネットワーク３１を介して、自治体の通信サーバ２２ないし基幹システム２１と相互に情報通信可能に接続されている。同様に、システム１０は、コンピュータネットワーク３２〜３５を介して、自治体指定金融機関、コンビニエンスストア収納代行会社、ＭＰＮ（マルチペイメントネットワーク）収納センター、及びクレジット収納センターと相互に情報通信可能に接続されている。
【００３８】
次に、図２〜図４を参照して各ＤＢの構造を説明する。なお、以下の図２〜図４、図１４、及び図１６〜図２７において、基本的に、具体例を示した欄以外の「（空欄）」は未入力欄（現在はデータが入力されていないが将来データが入力される欄）であることを示し、「−」は非入力欄（将来もデータが入力されない欄）であることを示し、「---」は何等かの種々様々なデータが入力されている欄であることを示す。
【００３９】
まず、基本情報ＤＢ（基本情報記録手段を構成する）は、公金の収納に必要な基礎的データを登録しておくもので、図２に示すように、自治体側で案件毎に付与された納付書コード（符号ア：以下、異なる図面で同じ符号が付されているデータ同士が相互に対応していることを示す）をキーとして、自治体コード（符号イ）、納付科目、センター側で案件毎に乱数を用いて採番した納付番号（符号ウ）、コンビニ収納キー（公金取扱機関がコンビニエンスストアのときにキーとなるバーコード情報で、少なくとも前記納付番号を包含したもの（換言すれば、前記納付番号を含んでさえいれば、該納付番号のみからなるものでもよいし、他の情報、例えば納付金額や自治体名等の付加的情報を含むものでもよい）である：符号エ）、窓口収納キー（公金取扱機関が金融機関の窓口のときにキーとなるＯＣＲ（optical character reader：光学式文字読取装置）情報で、少なくとも前記納付番号を包含したもの（換言すれば、前記納付番号を含んでさえいれば、該納付番号のみからなるものでもよいし、他の情報、例えば納付金額や自治体名等の付加的情報を含むものでもよい）である：符号オ）、納付金額、及び納付期限といった基礎的データの他、納付者氏名（カナ、漢字）、住所、生年月日、性別、個人番号、及び世帯コードといった納付者個人に関する情報が、検索可能に体系的に登録されている。なお、この図２に示した具体例は、後述する図４１及び図４２に記載した例を採用したものであるが、本実施形態を限定するものではない。
【００４０】
また、納付情報ＤＢ（納付情報記録手段を構成する）は、各案件につき公金の納付状況に関するデータを登録しておくもので、図３に示すように、納付番号（符号ウ）をキーとして、コンビニ収納キー（符号エ）、窓口収納キー（符号オ）、納付金額（符号カ）、納付手続日（符号キ）、状況区分（符号ク）、収納チャンネル（符号ケ）、収納会社（符号コ）、手続情報受信日（符号サ）、確認情報受信日（符号シ）、及び資金化日（符号ス）といった各種の情報が、検索可能に体系的に登録されている。なお、この図３に示した具体例は、後述する図４１及び図４２並びに図６に記載した例を採用したものであるが、本実施形態を限定するものではない。
【００４１】
一方、資金化日ＤＢは、金融機関やコンビニエンスストアあるいはクレジット会社等の各公金取扱機関毎に、納付者による納付手続があってから（納付手続日）、その納付した資金がいつ自治体の口座に入金されるか（資金化日）に関するデータを予め登録しておくもので、図４に示すように、収納会社（符号コ）をキーとして、収納チャンネル（符号ケ）、自治体コード（符号イ）、納付科目、資金化日タイプ、納付手続日後日数、速報通知日後日数、納付手続日範囲（開始）、納付手続日範囲（終了）、及び資金化日といった各種の情報が、検索可能に体系的に登録されている。
【００４２】
ここで、図４に例示した資金化日ＤＢの登録内容の意味を説明する。まず、Ａ銀行は、自治体指定金融機関であり、Ａ銀行の窓口で直接公金の納付手続をすると、その資金が自治体の口座に入金される資金化日は、納付済通（図８、図９参照）のデータ化時に指定されることが登録されている。例えば、図５に示すように、Ａ銀行の窓口に公金が５月２０日に納められたとすると（納付手続日）、翌日の５月２１日にその資金が自治体の口座に入金される（資金化日）。そして、この５月２１日という情報が納付済通のデータ化時に指定されるのである。また、図６に示すように、Ａ銀行の窓口に公金が５月３０日に納められたとすると（納付手続日）、翌日の５月３１日にその資金が自治体の口座に入金される（資金化日）。そして、この５月３１日という情報が納付済通のデータ化時に指定されるのである。
【００４３】
次に、Ｂ銀行は、非指定金融機関であり、Ｂ銀行の窓口で直接公金の納付手続をすると、その資金が自治体の口座に入金される資金化日は、納付手続日の２営業日後であることが登録されている。例えば、図５に示すように、Ｂ銀行の窓口に公金が５月２０日に納められたとすると（納付手続日）、２日後の５月２２日にその資金が自治体の口座に入金される（資金化日）。また、図６に示すように、Ｂ銀行の窓口に公金が５月２９日に納められたとすると（納付手続日）、２日後の５月３１日にその資金が自治体の口座に入金される（資金化日）。
【００４４】
次に、コンビニエンスストアであるＣコンビニで直接公金の納付手続をすると、その資金が自治体の口座に入金される資金化日は、予め月間スケジュールによって決まっていることが登録されている。例えば、図５に示すように、Ｃコンビニに公金が５月２０日に納められたとすると（納付手続日）、５月２０日は５月１５日から５月２５日までの範囲内にあるから、５月３１日にその資金が自治体の口座に入金される（資金化日）。図４には、納付手続日が２００７年５月１５日から２００７年５月２５日までの範囲内にあるとき、資金化日が２００７年５月３１日になることのみ示したが、納付手続日がこれ以外の範囲内にあるときについても併せて登録されている。なお、図５及び図６に記されている「速報通知日」及び「確報通知日」の意味は後ほど明らかになるであろう（図１０、図１１、図１９、図２１参照）。
【００４５】
次に、Ｄ銀行は、納付者が口座を有する金融機関であり、ＷＥＢ収納サイトを介してインターネットバンキングで電子納付手続をすると、その資金が自治体の口座に入金される資金化日は、速報通知日の３営業日後であることが登録されている。例えば、図５に示すように、インターネットバンキングにより、Ｄ銀行の納付者の口座から資金を引き落とす手続が５月２０日にとられたとすると（納付手続日）、３日後の５月２３日にその引き落とされた資金が自治体の口座に入金される（資金化日）。また、図６に示すように、インターネットバンキングにより、Ｄ銀行の納付者の口座から資金を引き落とす手続が５月２８日にとられたとすると（納付手続日）、３日後の５月３１日にその引き落とされた資金が自治体の口座に入金される（資金化日）。
【００４６】
次に、Ｅクレジットは、納付者がカード契約を交わしているクレジット会社であり、ＷＥＢ収納サイトを介してクレジットカードで電子納付手続をすると、それに応じた資金が自治体の口座に入金される資金化日は、速報通知日の３営業日後であることが登録されている。例えば、図５に示すように、クレジットカードにより、公金の納付手続が５月２０日にとられたとすると（納付手続日）、３日後の５月２３日にそれに応じた資金が自治体の口座に入金される（資金化日）。また、図６に示すように、クレジットカードにより、公金の納付手続が５月２８日にとられたとすると（納付手続日）、３日後の５月３１日にそれに応じた資金が自治体の口座に入金される（資金化日）。
【００４７】
なお、図５は、公金の納付手続がすべて同じ日（５／２０）にとられた場合でも、公金取扱機関が異なると資金化日が異なる例を示すものである。これに対し、図６は、公金の納付手続が異なる日にとられた場合に、資金化日が同じ日（５／３１）に揃う例を示している。
【００４８】
次に、システム１０が行う動作を含め、センター（ひいてはシステム１０）による公金収納管理業務を各公金取扱機関毎に説明する。まず、図７を参照して、納付通知書の作成動作を説明する。図７に符号（１）で示すように、自治体の側からセンターへ基本情報がネットワーク３１を介して送信される。
【００４９】
この基本情報は、図１４に示すように、自治体の側で付与された納付書コード（符号ア）をキーとして、納付科目、納付金額、納付期限、納付者氏名（カナ）、納付者氏名（漢字）、住所、生年月日、性別、個人番号、及び世帯コードといった各種の情報を含んでいる。なお、この図１４に示した具体例は、図２に記載した例を採用したものであるが、本実施形態を限定するものではない。
【００５０】
システム１０は、この基本情報を受信すると、その内容を案件毎に基本情報ＤＢに登録する。次いで、システム１０は、この基本情報ＤＢの登録内容に基いて納付通知書を作成し、センターは、これを各納付者へ送付する（符号（２））。
【００５１】
この納付通知書は、図１５に示すように、システム１０が案件毎に乱数を用いて採番した納付番号、コンビニ収納キー（前記納付番号を包含したバーコード情報）、窓口収納キー（前記納付番号を包含したＯＣＲ情報）、納付金額、納付期限、自治体名、納付科目、及び納付者氏名といった各種の情報が記載されている。
【００５２】
ここで、システム１０は、案件毎に基本情報ＤＢを作成すると共に、その基本情報ＤＢの登録内容に基いて、納付情報ＤＢを案件毎に作成する（図３において１つ目の矢印の前の状態：状況区分は「０」である）。
【００５３】
次に、図８を参照して、納付者が指定金融機関の窓口で公金納付手続をする場合を説明する。まず、納付者は、納付通知書を携えて指定金融機関に出向き、窓口で公金を現金納付する（符号（１））。指定金融機関は、この納付者の納付手続を受けて、納付通知書から切り離した納付済通をセンターに届ける（符号（２））。センターでは、この納付済通に記載されている情報をシステム１０に入力し、データ化する。データ化された情報は、窓口納付情報となって、案件毎に納付情報ＤＢに登録される（図３において１つ目の矢印のように変化した後の状態：状況区分が「０」から「１」に更新される）。
【００５４】
この窓口納付情報は、図１６に示すように、窓口収納キー（符号オ）をキーとして、収納会社（符号コ）、納付金額（符号カ）、納付手続日（符号キ）、及び資金化日（符号ス）といった各種の情報を含んでいる。なお、この図１６に示した具体例は、図６に記載した例を採用したものであるが、本実施形態を限定するものではない。また、図１６と図３とは窓口収納キー（符号オ）で紐付けされる。
【００５５】
ここで、資金化日（符号ス）は、納付者がした納付手続に係る資金が自治体の口座に移動する日である。図４に示した資金化日ＤＢを参照すると、自治体指定金融機関の場合、資金化タイプが「４」で、資金化日は納付済通のデータ化時に指定と登録されている。したがって、センターで納付済通に記載されている内容をシステム１０に入力し、データ化する際に、資金化日が決定される。この場合、納付者が現金納付をした金融機関が指定金融機関であるから、その納付手続日の次の営業日に自治体の口座に資金が振り込まれることが分かっている。例えば、納付済通が納付手続日（図５の５／２０）の当日にセンターに届けられて情報がデータ化される場合は、納付済通がセンターに届けられた日（５／２０）の翌日（５／２１）が資金化日とされ、一方、納付済通が納付手続日（図５の５／２０）の翌日にセンターに届けられて情報がデータ化される場合は、納付済通がセンターに届けられた日（５／２１）の当日（５／２１）が資金化日とされる。いずれにせよ、センターでのデータ化時には、資金化日（符号ス）は、図５の例では、５／２１と入力される。
【００５６】
図８に戻り、資金化日になると、符号（３）で示すように、指定金融機関からシステム１０へ入金情報が送信される。この入金情報は、図示しないが、例えば全国銀行協会のフォーマットに準じるものであり、各公金取扱機関から自治体の口座に入金された資金の公金取扱機関別入金情報である。
【００５７】
システム１０は、この入金情報を受信すると、その入金額と、今日が資金化日である案件の納付情報ＤＢの登録データに含まれる納付金額（図３の符号（カ））とを突合し、両金額同士が一致していることを確認したうえで、自治体へ消込情報を送信する（符号（４））。
【００５８】
この消込情報は、図１７に示すように、納付書コード（符号ア）をキーとして、納付科目、納付金額（符号カ）、納付手続日（符号キ）、収納確認日（符号シ）、納付者氏名（カナ）、納付者氏名（漢字）、状況区分（符号ク）、収納チャネル（符号ケ）、収納会社（符号コ）、及び資金化日（符号ス）といった各種の情報を含んでいる。ここで、この消込情報は、図示したように、自治体へ報告する情報が、収納チャネルや収納会社が何であるかに関わらず（すなわち、収納チャネルや収納会社が案件毎に異なっていても）、所定の統一された形式で作成されている。なお、この消込情報においては、状況区分（符号ク）は「３」である（図３において３つ目の矢印のように変化した後の状態：状況区分が「２」から「３」に更新されている）。また、この図１７に示した具体例は、図３に記載した例を採用したものであるが、本実施形態を限定するものではない。また、図１７と図３と図２とは納付番号（符号ウ）及び納付書コード（符号ア）で紐付けされる。
【００５９】
また、図１７に示すように、消込情報には、納付者の口座情報やクレジットカード情報等は含まれていない。なお、本実施形態では、前述したように、図３の納付情報ＤＢに、納付者の口座情報やクレジットカード情報等が記録されないようになっているが、たとえ納付情報ＤＢ等に納付者の口座情報やクレジットカード情報等が記録される場合であっても、つまり、システム１０が納付者の口座情報やクレジットカード情報等を保有している場合であっても、消込情報には、納付者の口座情報やクレジットカード情報等が含まれないようになっているのである。
【００６０】
図８に符号（５）で示すように、資金化日には、指定金融機関から自治体へ入金情報が送信されており、自治体は、この指定金融機関からの入金情報と、システム１０からの消込情報とを突合して、自治体が保有する自治体独自の基本情報ＤＢ及び／又は納付情報ＤＢの登録データの消込みを行うこととなる。その際、消込情報に含まれる収納金額（符号カ）が入金情報に含まれる入金額と一致していることが既にシステム１０の側でチェック済みなので、自治体における前記消込作業が極めて円滑に行われることとなる。
【００６１】
次に、図９を参照して、納付者が非指定の金融機関の窓口で公金納付手続をした場合を説明する。ただし、図８の場合と比べて異なる部分のみ説明を加える。図９の場合が図８の場合と比べて異なる部分は、図９に符号（２）で示すように、納付済通が指定金融機関からではなく非指定金融機関からセンターへ届けられる点である。また、図９に符号（３）で示すように、納付者が納付手続を行った非指定金融機関から、自治体の口座がある指定金融機関へ、資金化日までに資金移動が発生する点である。
【００６２】
そして、資金化日（図１６の符号ス）は、図４に示した資金化日ＤＢを参照すると、非指定金融機関の場合、資金化タイプが「１」で、資金化日は、納付者が納付手続を行った日の２営業日後と登録されている。例えば、納付済通が納付手続日（図５の５／２０）の当日にセンターに届けられた場合は、納付済通がセンターに届けられた日（５／２０）の翌々日（５／２２）が資金化日とされ、一方、納付済通が納付手続日（５／２０）の翌日にセンターに届けられた場合は、納付済通がセンターに届けられた日（５／２１）の翌日（５／２２）が資金化日とされる。いずれにせよ、資金化日（符号ス）は、図５の例では、５／２２と入力される。この入金予定日（符号ス）は、システム１０の側で資金化日ＤＢを参照して決定される。
【００６３】
次に、図１０を参照して、納付者がコンビニエンスストアで公金納付手続をした場合を説明する。まず、図９に符号（１）で示すように、納付者は、納付通知書を携えてコンビニエンスストアに出向き、公金を現金納付する。コンビニエンスストアは、この納付者の納付手続を受けて、コンビニエンスストア収納代行会社へ、納付手続のあったことを、必要事項と共に通知する（符号（２））。コンビニエンスストア収納代行会社は、この通知を受けると、コンビニ納付手続情報（つまり、納付者が公金取扱機関を介して公金の納付手続をしたという手続情報）をセンターへ送信する（符号（３））。
【００６４】
このコンビニ納付手続情報は、図１８に示すように、コンビニ収納キー（符号エ）をキーとして、収納会社（符号コ）、納付金額（符号カ）、納付手続日（符号キ）、資金化日（符号ス）、及び収納確認フラグ（符号セ）といった各種の情報を含んでいる。なお、この図１８に示した具体例は、図６に記載した例を採用したものであるが、本実施形態を限定するものではない。
【００６５】
システム１０は、コンビニ納付手続情報を受信すると、その内容を案件毎に納付情報ＤＢに登録する。その場合、資金化日（図３の符号ス）は、図４に示した資金化日ＤＢを参照すると、コンビニエンスストアの場合、資金化タイプが「３」で、資金化日は、月間スケジュールで決まると登録されている。例えば、納入手続が５／２０にあったとすると、５／２０は図４の納付手続日範囲（開始）〜（終了）に入っているから、資金化日（符号ス）は、図５の例では、５／３１と入力される。この資金化日（符号ス）は、システム１０の側で資金化日ＤＢを参照して決定される。なお、図１８と図３とはコンビニ収納キー（符号エ）で紐付けされる。
【００６６】
次いで、システム１０は、この納付情報ＤＢの登録内容に基いて仮消込情報（速報）を作成し、これを自治体へ送信する（符号（４））。なお、図５の例では、この仮消込情報（速報）は納付手続日の翌日（５／２１）に通知されている。
【００６７】
この仮消込情報（速報）は、図１９に示すように、納付書コード（符号ア）をキーとして、納付科目、納付金額（符号カ）、納付手続日（符号キ）、納付者氏名（カナ）、納付者氏名（漢字）、個人番号、状況区分（符号ク）、収納チャネル（符号ケ）、収納会社（符号コ）、及び資金化日（符号ス）といった各種の情報を含んでいる。これにより、自治体の側で、早い段階で、案件毎に納付手続の有無を確認することができ、納付者が納付手続をしたのに自治体から督促状が送られてきた、というような不具合が未然に防止される。ここで、この仮消込情報（速報）は、図示したように、案件毎に記載内容が異なっていても、所定の統一された形式で作成されている。また、納付者の口座情報やクレジットカード情報等は含まれていない。なお、この図１９に示した具体例は、図３に記載した例を採用したものであるが、本実施形態を限定するものではない。また、図１９と図３と図２とは納付番号（符号ウ）及び納付書コード（符号ア）で紐付けされる。
【００６８】
次いで、図１０に符号（５）で示すように、納付者が納付手続をしたコンビニエンスストアからコンビニエンスストア収納代行会社へ前記納付手続に係る資金が移動する。コンビニエンスストア収納代行会社は、この資金移動に応じて、コンビニ納付確認情報（つまり、自治体の口座へ入金する資金が準備されたという確認情報）をセンターへ送信する（符号（６））。
【００６９】
このコンビニ納付確認情報は、図２０に示すように、コンビニ収納キー（符号エ）をキーとして、収納会社（符号コ）、納付金額（符号カ）、収納確認日（納付手続に係る資金がコンビニエンスストア収納代行会社へ移動した日：符号シ）、資金化日（符号ス）、及び収納確認フラグ（符号セ）といった各種の情報を含んでいる。これにより、資金化日（符号ス）に自治体の口座に資金が確実に入金されることが約束されたことになる。なお、この図２０に示した具体例は、図６に記載した例を採用したものであるが、本実施形態を限定するものではない。
【００７０】
システム１０は、コンビニ納付確認情報を受信すると、その内容を案件毎に納付情報ＤＢに登録する。その場合、状況区分が「１」から「２」に更新される（図３の２つ目の矢印）。なお、図２０と図３とはコンビニ収納キー（符号エ）で紐付けされる。
【００７１】
次いで、システム１０は、この納付情報ＤＢの登録内容に基いて仮消込情報（確報）を作成し、これを自治体へ送信する（符号（７））。なお、図５の例では、この仮消込情報（確報）は５／２６に通知されている。
【００７２】
この仮消込情報（確報）は、図２１に示すように、納付書コード（符号ア）をキーとして、納付科目、納付金額（符号カ）、収納確認日（納付手続に係る資金がコンビニエンスストア収納代行会社へ移動した日：符号シ）、納付者氏名（カナ）、納付者氏名（漢字）、個人番号、状況区分（「２」に更新されている：符号ク）、収納チャネル（符号ケ）、収納会社（符号コ）、及び資金化日（符号ス）といった各種の情報を含んでいる。ここで、この仮消込情報（確報）は、図示したように、案件毎に記載内容が異なっていても、所定の統一された形式で作成されている。また、納付者の口座情報やクレジットカード情報等は含まれていない。なお、この図２１に示した具体例は、図３に記載した例を採用したものであるが、本実施形態を限定するものではない。また、図２１と図３と図２とは納付番号（符号ウ）及び納付書コード（符号ア）で紐付けされる。
【００７３】
次いで、図１０に符号（８）で示すように、コンビニエンスストア収納代行会社から自治体指定金融機関へ納付手続に係る資金が移動する。そして、資金化日になると、符号（９）で示すように、指定金融機関からシステム１０へ入金情報が送信されるのであるが、これ以降の符号（９）〜（１１）は、図８の符号（３）〜（５）と同じであるので、その説明は省略する。
【００７４】
次に、図１１を参照して、納付者がインターネットバンキングのＷＥＢサイト上で納付手続をした場合を説明する。まず、図１１に符号（１）で示すように、納付者は、自己の保有するＰＣ等を用いて、ＭＰＮ（マルチペイメントネットワーク）収納センターのＷＥＢ収納サイトにアクセスする。このとき納付者のＰＣに表れる初期画面Ｗ１を図３８に例示する。納付者は納付通知書に記載されている納付番号（図１５参照）等、必要事項を入力して納付手続ボタンをクリックすると、図３９に示すように、納付手続の続行画面Ｗ２に変わるので、納付者は自己の口座番号を入力して口座情報確認ボタンをクリックする。これにより、図１１に符号（２）で示すように、口座情報が納付者取引金融機関に送られ、符号（３）で示すように、確認情報が返信される。そして、符号（４）で示すように、納付者に対して、納付手続画面（図示せず）が表示されるので、納付者は、その画面上で納付手続を行うこととなる。ＭＰＮ収納センターは、納付者によるこの納付手続に応じて、インターネットバンキング納付手続情報（つまり、納付者が公金取扱機関を介して公金の納付手続をしたという手続情報）をセンターへ送信する（符号（５））。
【００７５】
なお、納付者が図３８に例示した初期画面Ｗ１上で、納付番号等の必要事項を入力して納付手続ボタンをクリックしたとき、すでにこの件の納付手続が済んでいる場合は、二重納付を防止するため、図４０に示すように、納付手続が済んでいることを示す納付状況を表示して今のこの納付手続を中止するようになっている（二重納付防止画面Ｗ３：確認ボタンをクリックすると初期画面Ｗ１に戻る）。
【００７６】
前記インターネットバンキング納付手続情報は、図２２に示すように、納付番号（符号ウ）をキーとして、収納会社（符号コ）、納付金額（符号カ）、納付手続日（符号キ）、資金化日（符号ス）、及び収納確認フラグ（符号セ）といった各種の情報を含んでいる。なお、この図２２に示した具体例は、図６に記載した例を採用したものであるが、本実施形態を限定するものではない。
【００７７】
システム１０は、インターネットバンキング納付手続情報を受信すると、その内容を案件毎に納付情報ＤＢに登録する。その場合、資金化日（図３の符号ス）は、図４に示した資金化日ＤＢを参照すると、インターネットバンキング（ＭＰＮ収納センター）の場合、資金化タイプが「２」で、資金化日は、速報通知日の３営業日後と登録されている。例えば、納付手続が５／２０にあり、当日に自治体の側へ速報が通知されるとすると、資金化日（符号ス）は、図５の例では、５／２３と入力される。この資金化日（符号ス）は、システム１０の側で資金化日ＤＢを参照して決定される。なお、図２２と図３とは納付番号（符号ウ）で紐付けされる。
【００７８】
次いで、システム１０は、この納付情報ＤＢの登録内容に基いて仮消込情報（速報）を作成し、これを自治体へ送信する（符号（６））。なお、図５の例では、この仮消込情報（速報）は納付手続日の当日（５／２０）に通知されている。ただし、この仮消込情報（速報）は、前述の図１９に示した通りであるので、ここでは説明を繰り返さない。
【００７９】
次いで、図１１に符号（７）で示すように、納付者取引金融機関からＭＰＮ収納センターへ前記納付手続に係る資金が移動する。ＭＰＮ収納センターは、この資金移動に応じて、インターネットバンキング納付確認情報（つまり、自治体の口座へ入金する資金が準備されたという確認情報）をセンターへ送信する（符号（８））。
【００８０】
このインターネットバンキング納付確認情報は、図２３に示すように、納付番号（符号ウ）をキーとして、収納会社（符号コ）、納付金額（符号カ）、収納確認日（符号シ）、資金化日（符号ス）、及び収納確認フラグ（符号セ）といった各種の情報を含んでいる。これにより、資金化日（符号ス）に自治体の口座に資金が確実に入金されることが約束されたことになる。なお、この図２３に示した具体例は、図６に記載した例を採用したものであるが、本実施形態を限定するものではない。
【００８１】
システム１０は、インターネットバンキング納付確認情報を受信すると、その内容を案件毎に納付情報ＤＢに登録する。その場合、状況区分が「１」から「２」に更新される（図３の２つ目の矢印）。なお、図２３と図３とは納付番号（符号ウ）で紐付けされる。
【００８２】
次いで、システム１０は、この納付情報ＤＢの登録内容に基いて仮消込情報（確報）を作成し、これを自治体へ送信する（符号（９））。なお、図５の例では、この仮消込情報（確報）は５／２１に通知されている。ただし、この仮消込情報（確報）は、前述の図２１に示した通りであるので、ここでは説明を繰り返さない。
【００８３】
次いで、図１１に符号（１０）で示すように、ＭＰＮ収納センターから自治体指定金融機関へ納付手続に係る資金が移動する。そして、資金化日になると、符号（１１）で示すように、指定金融機関からシステム１０へ入金情報が送信されるのであるが、これ以降の符号（１１）〜（１３）は、図８の符号（３）〜（５）と同じであるので、その説明は省略する。
【００８４】
最後に、図１２を参照して、納付者がクレジットカードのＷＥＢサイト上で納付手続をした場合を説明する。全体の動作の流れは、図１１の場合と類似している。ただし、図１１の場合と異なる部分は、図１２に符号（５）で示すように、収納センターからセンターへ送信されるのは納付手続兼確認情報であり、それに応じて、図１１に符号（６）で示すように、センターから自治体へ送信されるのは、仮消込情報（速報兼確報）である点である。
【００８５】
まず、図１２に符号（１）で示すように、納付者は、自己の保有するＰＣ等を用いて、クレジット収納センターのＷＥＢ収納サイトにアクセスする。このとき納付者のＰＣには前述のインターネットバンキングの場合の図３８の初期画面Ｗ１に類似の画面が表れるが、ここではその図示は省略する。納付者は納付通知書に記載されている納付番号（図１５参照）や自己のカード番号等を入力する。これにより、符号（２）で示すように、カード情報が納付者が契約するクレジット会社に送られ、符号（３）で示すように、認証情報が返信される。そして、符号（４）で示すように、納付者に対して、納付手続画面が表示されるので、納付者は、その画面上で納付手続を行うこととなる。クレジット収納センターは、納付者によるこの納付手続に応じて、クレジット納付手続兼確認情報（つまり、納付者が公金取扱機関を介して公金の納付手続をしたという手続情報であり、かつ、自治体の口座へ入金する資金が準備されたという確認情報）をセンターへ送信する（符号（５））。
【００８６】
このクレジット納付手続兼確認情報は、図２４に示すように、納付番号（符号ウ）をキーとして、収納会社（符号コ）、納付金額（符号カ）、納付手続兼収納確認日（符号シ）、資金化日（符号ス）、及び収納確認フラグ（符号セ）といった各種の情報を含んでいる。なお、この図２４に示した具体例は、図６に記載した例を採用したものであるが、本実施形態を限定するものではない。
【００８７】
システム１０は、クレジット納付手続兼確認情報を受信すると、その内容を案件毎に納付情報ＤＢに登録する。その場合、資金化日（図３の符号ス）は、図４に示した資金化日ＤＢを参照すると、クレジット決済（クレジット収納センター）の場合、資金化タイプが「２」で、資金化日は、速報通知日の３営業日後と登録されている。例えば、納付手続が５／２０にあり、当日に自治体の側へ速報が通知されるとすると、資金化日（符号ス）は、図５の例では、５／２３と入力される。この資金化日（符号ス）は、システム１０の側で資金化日ＤＢを参照して決定される。また、状況区分が「０」から「２」に更新される（図３の１つ目の矢印及び２つ目の矢印）。なお、図２４と図３とは納付番号（符号ウ）で紐付けされる。
【００８８】
次いで、システム１０は、この納付情報ＤＢの登録内容に基いて仮消込情報（速報兼確報）を作成し、これを自治体へ送信する（符号（６））。なお、図５の例では、この仮消込情報（速報兼確報）は納付手続日の当日（５／２０）に通知されている。ただし、この仮消込情報（速報兼確報）は、前述の図２１に示した仮消込情報（確報）に準じて同様なので、ここでは説明を繰り返さない。
【００８９】
次いで、図１２に符号（７）で示すように、クレジット会社からクレジット収納センターへ前記納付手続に係る資金が移動する。これにより、資金化日（符号ス）に自治体の口座に資金が確実に入金されることが約束されたことになる。
【００９０】
次いで、図１２に符号（８）で示すように、クレジット収納センターから自治体指定金融機関へ納付手続に係る資金が移動する。そして、資金化日になると、符号（９）で示すように、指定金融機関からシステム１０へ入金情報が送信されるのであるが、これ以降の符号（９）〜（１１）は、図８の符号（３）〜（５）と同じであるので、その説明は省略する。
【００９１】
ただし、このクレジット決済で公金を納付する場合の特徴として、図１２に符号（１６）で示すように、後日、クレジット会社から納付者の元へ利用代金明細書が送付され、これに伴い、符号（１７）で示すように、クレジット契約に従って納付者の口座から納付手続に係る資金が引き落とされることは、いうまでもない。
【００９２】
以上の基本的動作に加えて、本実施形態においては、図８〜図１２に符号（９９）で示すように、自治体の側からセンターの側へ納付済情報が送信されることがある。つまり、納付者のなかには、納付通知書を携えて、自治体の庁舎へ直接出向き、公金の納付手続をする者がある。この場合、センターには公金取扱機関からの手続情報が入らないので、自治体とセンターとで情報の連携を図るために、自治体の側からセンターの側へ納付済情報が送信されるのである。
【００９３】
この納付済情報は、図２５に示すように、納付書コード（符号ア）をキーとして、納付金額（符号カ）、納付手続日（符号キ）、納付者氏名（カナ）、納付者氏名（漢字）、収納チャネル（符号ケ）、及び収納会社（符号コ）といった各種の情報を含んでいる。システム１０は、この納付済情報を受信すると、その内容を納付情報ＤＢに登録することとなる。なお、図２５と図３と図２とは納付番号（符号ウ）及び納付書コード（符号ア）で紐付けされる。
【００９４】
さらに、本実施形態においては、図１３に示すように、センターとＭＰＮ収納センター（クレジット収納センターでも同じ）との間、及び、センターと自治体との間で、問合せ情報及び回答情報が遣り取りされることがある。次に、この納付状況の問合せ動作を説明する。
【００９５】
つまり、納付者のなかには、公金の二重納付を避けるために、ＷＥＢ収納サイトを通して、収納センターに自己の納付状況を問い合せる者がある（ａ）。この場合、収納センターでは他の公金取扱機関を介しての納付状況が判らないから、納付者からの問合せを受けると、さらにセンターへ問合せを行うこととなる（ｂ）。その結果、センターの側から収納センターの側へ、納付状況の問合せに対する回答として回答情報が送信されることとなる（ｃ）。この回答情報は収納センターから納付者に示される（ｄ）。
【００９６】
同様に、納付者のなかには、公金の二重納付を避けるために、自治体（の職員）に自己の納付状況を問い合せる者がある（ｅ）。この場合、納付通知書には、図１５に図示したように、自治体が付与した納付書コード（符号ア）が記載されておらず、代わりに、センターが採番した納付番号（符号ウ）が記載されているので、納付者はこの納付番号で問合せを行うこととなる。しかし、自治体の側では納付番号が判らないから、納付者からの問合せを受けると、さらにセンターへ問合せを行うこととなる（ｆ）。その結果、センターの側から自治体の側へ、納付状況の問合せに対する回答として回答情報が送信されることとなる（ｇ）。この回答情報は自治体から納付者に伝達される（ｈ）。
【００９７】
このうち、公金取扱機関へ送られる回答情報（ｃ）は、図２６に示すように、納付番号（符号ウ）をキーとして、納付者氏名、状況区分（符号ク）、納付金額（符号カ）、納付手続日（符号キ）、収納チャネル（符号ケ）、及び収納会社（符号：コ）といった各種の情報を含んでいる。ただし、納付者の住所や生年月日、電話番号や個人場号、あるいは世帯コードといった、納付者に関する情報のうちの特定の情報は一切含まれていない。このようにデータを分散することにより、公金取扱機関に対する不必要なデータの漏洩リスクの低減が図られている。なお、この図２６に示した具体例は、図３に記載した例を採用したものであるが、本実施形態を限定するものではない。また、図２６と図３とは納付番号（符号ウ）で紐付けされる。
【００９８】
一方、自治体へ送られる回答情報（ｇ）は、図２７に示すように、納付書コード（符号ア）をキーとして、納付科目、納付者氏名（カナ、漢字）、状況区分（符号ク）、納付金額（符号カ）、納付手続日（符号キ）、収納チャネル（符号ケ）、収納会社（符号コ）、及び資金化日（符号ス）といった各種の情報を含んでいる。ただし、納付者の口座情報やクレジットカード情報は一切含まれていない。このようにデータを分散することにより、自治体に対する不必要なデータの漏洩リスクの低減が図られている。なお、この図２７に示した具体例は、図３に記載した例を採用したものであるが、本実施形態を限定するものではない。また、図２７と図３と図２は納付番号（符号ウ）及び納付書コード（符号ア）で紐付けされる。
【００９９】
なお、本実施形態では、前述したように、図３の納付情報ＤＢに、納付者の口座情報やクレジットカード情報等が記録されないようになっているが、たとえ納付情報ＤＢ等に納付者の口座情報やクレジットカード情報等が記録される場合であっても、つまり、システム１０が納付者の口座情報やクレジットカード情報等を保有している場合であっても、自治体への回答情報（ｇ）には、納付者の口座情報（図１１の符号（２））やクレジットカード情報（図１２の符号（２））等が一切含まれないようになっているのである。
【０１００】
一方、本実施形態では、前述したように、図２の基本情報ＤＢに、納付者氏名の他、住所や生年月日等の納付者個人に関する各種の情報が記録されるようになっているが、このように基本情報ＤＢ等に納付者個人に関する各種の情報が記録される場合であっても、つまり、システム１０が納付者個人に関する各種の情報を保有している場合であっても、公金取扱機関への回答情報（ｃ）には、納付者個人に関する各種の情報のうちの特定の情報が一切含まれないようになっているのである（図２６の例では、納付者氏名だけが含まれている）。
【０１０１】
ここで、納付者が自己の保有するＰＣ等を用いて、収納センターのＷＥＢ収納サイトにアクセスしたときに（ａ）、納付者のＰＣに表れる初期画面Ｗ１は図３８に例示したものと同様である。すなわち、納付者は納付通知書に記載されている納付番号（図１５参照）等、必要事項を入力して納付状況問合せボタンをクリックすると、未納付のときは、図３９の納付手続続行画面Ｗ２に移動し、納付済みのときは、図４０の二重納付防止画面（回答情報）Ｗ３に移動する（ｄ）。
【０１０２】
また、図４１に、自治体（の職員）が納付者からの問合せを受けてセンターに照会する場合に（ｆ）、自治体のシステムに表れる検索条件指定画面Ｗ４を例示し、図４２に、センターからの回答情報（図２８）を受けて自治体のシステムに表れる検索結果画面（検索日付時刻付）Ｗ５を例示した（ｇ）。
【０１０３】
なお、図４１及び図４２は、納付番号（つまり案件）を指定しないで、納付者だけで検索した場合を示すが、図４１の検索条件指定画面Ｗ４で納付番号（納付者から聞いて）を指定すると、図４２の検索結果画面Ｗ５ではその案件のみの結果が表示されるようになっている。
【０１０４】
以下、図２８〜図３７のフローチャートに従って、前記システム１０の具体的動作をさらに詳しく説明する。これらのフローチャートは、本発明に係る公金収納管理システム用プログラムの実施の形態をフローチャートの態様で提供するものである。
【０１０５】
まず、図２８は、システム１０が基本情報の受信時に行う動作のフローチャートである。すなわち、ステップＳ１１で、基本情報を受信すると、ステップＳ１２で、受信した案件毎に乱数を用いて納付番号を採番し、ステップＳ１３で、受信した基本情報に納付番号とコンビニ収納キー（納付番号を含んでいる）と窓口収納キー（納付番号を含んでいる）とを追加して案件毎に基本情報ＤＢに登録する。次いで、ステップＳ１４で、基本情報ＤＢに基き納付通知書を作成した後、ステップＳ１５で、基本情報ＤＢの登録内容に基き納付情報ＤＢを案件毎に作成する。
【０１０６】
次に、図２９は、システム１０が窓口収納情報の登録時に行う動作のフローチャートである。すなわち、ステップＳ２１で、納付済通の記載内容を入力した後、ステップＳ２２で、入力した情報（つまり窓口納付情報）を窓口収納キーをキーにして納付情報ＤＢに登録する。
【０１０７】
次に、図３０は、システム１０が消込情報の送信時に行う動作のフローチャートである。すなわち、ステップＳ３１で、公金取扱機関別の入金情報を自治体指定の金融機関から受信したうえで、ステップＳ３２で、今日が資金化日である全案件を納付情報ＤＢから抽出し、ステップＳ３３で、抽出した案件の納付情報に含まれている納付金額を公金取扱機関別に合計する。次いで、ステップＳ３４で、合計した公金取扱機関別の納付金額と、公金取扱機関別の入金情報とを突合し、差異の無いことを確認する。そして、ステップＳ３５で、納付番号にて基本情報ＤＢを検索し、各案件の納付書コードを読み出した後、ステップＳ３６で、読み出した納付書コードを付して、今日が資金化日の全案件を統合した消込情報を所定の統一された形式で作成して、自治体側へ送信する。
【０１０８】
次に、図３１は、システム１０がコンビニ収納の場合において仮消込情報（速報）の送信時に行う動作のフローチャートである。すなわち、ステップＳ４１で、コンビニ納付手続情報を受信すると、ステップＳ４２で、受信した情報をコンビニ収納キーをキーにして納付情報ＤＢに登録する。次いで、ステップＳ４３で、今日、コンビニ納付手続情報を受信した全案件を納付情報ＤＢから抽出し、ステップＳ４４で、抽出した案件を公金取扱機関（この場合はコンビニエンスストア）毎に統合する。そして、ステップＳ４５で、納付番号にて基本情報ＤＢを検索し、各案件の納付書コードを読み出した後、ステップＳ４６で、読み出した納付書コードを付して、今日、コンビニ納付手続情報を受信した全案件を公金取扱機関（この場合はコンビニエンスストア）毎に統合した仮消込情報（速報）を所定の統一された形式で作成して、自治体側へ送信する。
【０１０９】
次に、図３２は、システム１０が資金化日の決定時に行う動作のフローチャートである。すなわち、ステップＳ５１で、公金納付手続日と資金化日との関係を公金取扱機関毎に資金化日ＤＢに記録し、ステップＳ５２で、公金取扱機関から受信した納付情報に資金化日が含まれているか否かを判定し、含まれているときはそのままエンドとなるが、含まれていないときは、ステップＳ５３で、納付情報に含まれている納付手続日及び公金取扱機関と、資金化日ＤＢに記録されている公金納付手続日と資金化日との関係とから、資金化日を決定する。
【０１１０】
次に、図３３は、システム１０がコンビニ収納の場合において仮消込情報（確報）の送信時に行う動作のフローチャートである。すなわち、ステップＳ６１で、コンビニ収納確認情報を受信すると、ステップＳ６２で、受信した情報をコンビニ収納キーをキーにして納付情報ＤＢに登録する。次いで、ステップＳ６３で、今日、コンビニ納付確認情報を受信した全案件を納付情報ＤＢから抽出し、ステップＳ６４で、抽出した案件を公金取扱機関（この場合はコンビニエンスストア）毎に統合する。そして、ステップＳ６５で、納付番号にて基本情報ＤＢを検索し、各案件の納付書コードを読み出した後、ステップＳ６６で、読み出した納付書コードを付して、今日、コンビニ納付確認情報を受信した全案件を公金取扱機関（この場合はコンビニエンスストア）毎に統合した仮消込情報（確報）を所定の統一された形式で作成して、自治体側へ送信する。
【０１１１】
次に、図３４は、システム１０が同じくインターネットバンキングによるＷＥＢ電子収納の場合において仮消込情報（速報）の送信時に行う動作のフローチャートである。すなわち、ステップＳ７１で、インターネットバンキング納付手続情報を受信すると、ステップＳ７２で、受信した情報を納付番号をキーにして納付情報ＤＢに登録する。次いで、ステップＳ７３で、今日、インターネットバンキング納付手続情報を受信した全案件を納付情報ＤＢから抽出し、ステップＳ７４で、抽出した案件を公金取扱機関（この場合は納付者取引金融機関）毎に統合する。そして、ステップＳ７５で、納付番号にて基本情報ＤＢを検索し、各案件の納付書コードを読み出した後、ステップＳ７６で、読み出した納付書コードを付して、今日、インターネットバンキング納付手続情報を受信した全案件を公金取扱機関（この場合は納付者取引金融機関）毎に統合した仮消込情報（速報）を所定の統一された形式で作成して、自治体側へ送信する。
【０１１２】
次に、図３５は、システム１０が同じくインターネットバンキングによるＷＥＢ電子収納の場合において仮消込情報（確報）の送信時に行う動作のフローチャートである。すなわち、ステップＳ８１で、インターネットバンキング納付確認情報を受信すると、ステップＳ８２で、受信した情報を納付番号をキーにして納付情報ＤＢに登録する。次いで、ステップＳ８３で、今日、インターネットバンキング納付確認情報を受信した全案件を納付情報ＤＢから抽出し、ステップＳ８４で、抽出した案件を公金取扱機関（この場合は納付者取引金融機関）毎に統合する。そして、ステップＳ８５で、納付番号にて基本情報ＤＢを検索し、各案件の納付書コードを読み出した後、ステップＳ８６で、読み出した納付書コードを付して、今日、インターネットバンキング納付確認情報を受信した全案件を公金取扱機関（この場合は納付者取引金融機関）毎に統合した仮消込情報（確報）を所定の統一された形式で作成して、自治体側へ送信する。
【０１１３】
次に、図３６は、システム１０が同じくクレジットカードによるＷＥＢ電子収納の場合において仮消込情報（速報兼確報）の送信時に行う動作のフローチャートである。すなわち、ステップＳ９１で、クレジット納付手続兼確認情報を受信すると、ステップＳ９２で、受信した情報を納付番号をキーにして納付情報ＤＢに登録する。次いで、ステップＳ９３で、今日、クレジット納付手続兼確認情報を受信した全案件を納付情報ＤＢから抽出し、ステップＳ９４で、抽出した案件を公金取扱機関（この場合はクレジット会社）毎に統合する。そして、ステップＳ９５で、納付番号にて基本情報ＤＢを検索し、各案件の納付書コードを読み出した後、ステップＳ９６で、読み出した納付書コードを付して、今日、クレジット納付手続兼確認情報を受信した全案件を公金取扱機関（この場合はクレジット会社）毎に統合した仮消込情報（速報兼確報）を所定の統一された形式で作成して、自治体側へ送信する。
【０１１４】
最後に、図３７は、システム１０が同じく納付状況の問合せ受信時に行う動作のフローチャートである。すなわち、ステップＳ１０１で、収納センター又は自治体から納付状況の問合せを受信すると、ステップＳ１０２で、問合せの納付番号にて納付情報ＤＢを検索し、そして、ステップＳ１０３で、納付者からの問合せが公金取扱機関（ＭＰＮ収納センター又はクレジット収納センター）経由のときは、納付者の特定情報を含まない回答情報を作成し、一方、納付者からの問合せが自治体経由のときは、納付者の口座情報及びクレジットカード情報を含まない回答情報を作成して、ステップＳ１０４で、作成した回答情報を問合せ元（収納センター又は自治体）へ送信する。
【０１１５】
以上のように、本実施形態に係る公金収納管理システム１０においては、自治体の公金収納を管理するにあたり、基本情報受取手段（Ｓ１１）が、公金を収納するために必要な情報（図１４参照）を自治体から受け取り、基本情報記録手段（Ｓ１３）が、基本情報受取手段が受け取った情報を案件毎（納付書コード毎）に記録し（図２参照）、納付情報受取手段（Ｓ２１、Ｓ４１、Ｓ６１、Ｓ７１、Ｓ８１、Ｓ９１）が、納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報（図１６、図１８、図２０、図２２、図２３、図２４参照）を公金取扱機関から受け取り、報告情報作成手段（Ｓ３６）が、基本情報記録手段が情報を記録した案件のうち、納付情報受取手段が納付情報を受け取った案件について、納付情報受取手段が受け取った納付情報に基いて、自治体へ報告する情報（図１７参照）を所定の統一された形式で作成し、そして、報告情報送り手段（Ｓ３６）が、報告情報作成手段が作成した情報（図１７参照）を自治体へ送るから、自治体が受け取る情報の形式が公金取扱機関の種類に関係なく統一されることとなり、その結果、自治体の側での情報の取扱いが容易となって、当該公金収納管理システム１０の信頼性ないし商品性の向上が図られることとなる。
【０１１６】
また、本実施形態に係る公金収納管理システム１０においては、報告情報作成手段（Ｓ３６）が、納付者がいずれの公金取扱機関を介して公金の納付手続をしたか（収納チャネル：符号ケ、収納会社：符号コ）を含む情報（図１７参照）を作成すると共に、納付者がインターネットバンキング又はクレジット決済による公金取扱機関を介して公金の納付手続をした場合であっても、納付者の口座情報（図１１の符号（２））及びクレジットカード情報（図１２の符号（２））を含まない情報を作成するから、たとえ納付者がインターネットバンキングやクレジット決済を利用して公金の納付手続をしても、納付者の口座情報やクレジットカード情報といった重要情報が不用意に自治体の側へ流れることがなくなり、この点において、十全な情報漏洩リスクの低減が図られることとなる。
【０１１７】
また、本実施形態に係る公金収納管理システム１０においては、納付情報記録手段（Ｓ２２、Ｓ４２、Ｓ６２、Ｓ７２、Ｓ８２、Ｓ９２）が、納付情報受取手段が受け取った納付情報（図１６、図１８、図２０、図２２、図２３、図２４参照）を案件毎に記録し、問合せ受付手段（Ｓ１０１）が、公金の納付手続が済んでいるか否かの問合せを受け付け、納付情報検索手段（Ｓ１０２）が、問合せ受付手段が問合せを受け付けた案件毎に納付情報記録手段が記録した納付情報（図３参照）を検索し、回答情報作成手段（Ｓ１０３）が、納付情報検索手段が検索した情報に基いて回答情報（図２６、図２７参照）を作成すると共に、問合せ受付手段が受け付けた問合せが、公金取扱機関を経由した納付者からの問合せであるときは、納付者に関する情報のうち特定の情報を含まない回答情報を作成し（図２６参照）、問合せ受付手段が受け付けた問合せが、自治体を経由した納付者からの問合せであるときは、納付者の口座情報及びクレジットカード情報を含まない回答情報（図２７参照）を作成し、そして、回答情報送り手段（Ｓ１０４）が、回答情報作成手段が作成した回答情報を公金取扱機関又は自治体へ送るから、例えば公金取扱機関の側へは、回答情報に付随して、納付者の住所や生年月日あるいは世帯コード等の納付者に関する情報のうち特定の情報が流れることがなくなり、一方、自治体の側へは、回答情報に付随して、納付者の口座情報及びクレジットカード情報等の重要情報が流れることがなくなって、この点において、十全な情報漏洩リスクの低減が図られることとなる。
【０１１８】
また、本実施形態に係る公金収納管理システム１０においては、納付通知書作成手段（Ｓ１４）が、基本情報記録手段が記録した情報（図２参照）に基いて納付者へ送る納付通知書（図１５参照）を作成するから、自治体の側で納付通知書を作成する手間が省けることとなる。
【０１１９】
また、本実施形態に係る公金収納管理システム１０においては、案件特定コード設定手段（Ｓ１２）が、基本情報記録手段が情報を記録した案件毎に、案件を特定するコード（納付番号：符号ウ、ひいては、コンビニ収納キー：符号エ、及び、窓口収納キー：符号オ）を乱数を用いて設定し、そして、納付通知書作成手段（Ｓ１４）が、案件特定コード設定手段が設定したコードを付した納付通知書を作成するから、案件特定コード設定手段が設定するコードが複雑化し、案件特定コード設定手段が設定した案件特定コードから個人を特定することが困難となり、その結果、例えば、納付者が公金の納付手続時に自己の案件特定コード（納付番号：符号ウ）を誤って入力したときには、該当者無しというような警告が出るようになり、納付者が公金の納付手続時に自己の案件特定コードを誤って入力したときに他人のコードに該当してその他人の情報が漏洩するというようなリスクが低減されることとなる。
【０１２０】
また、本実施形態に係る公金収納管理システム１０においては、納付情報受取手段（Ｓ４１、Ｓ６１、Ｓ７１、Ｓ８１）が、納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報として、納付者が公金取扱機関を介して公金の納付手続をしたという手続情報（図１８、図２２）及び自治体の口座へ入金する資金が準備されたという確認情報（図２０、図２３）の２種類の情報を相前後して受け取り、報告情報作成手段（Ｓ４６、Ｓ７６）が、納付情報受取手段が前記手続情報を受け取った時点で、該手続情報に基いて、納付者が公金の納付手続をしたことを自治体へ連絡する旨の情報を作成し、そして、報告情報送り手段（Ｓ４６、Ｓ７６）が、報告情報作成手段が前記情報を作成した時点で、該情報を自治体へ送るから、自治体の側では、納付者が所定の公金取扱機関を介して公金の納付手続をした段階で早期にその情報を得ることができ、その結果、自治体がすでに公金の納付手続をした納付者に誤って督促状を出してしまう、という問題が解消されることとなる。
【０１２１】
なお、前記実施形態は、本発明の最良の実施形態であるが、特許請求の範囲を逸脱しない限り、さらに種々の変更や改良を加えることができることはいうまでもない。
【産業上の利用可能性】
【０１２２】
以上、具体例を挙げて詳しく説明したように、本発明は、納付者が様々な公金取扱機関を介して公金の納付手続をしたことに起因して発生する種々の納付情報を自治体の側での取扱いが容易となるように自治体へ送ることが可能な技術であるから、また、納付者個人の重要情報が不用意に漏洩しないように対策できる技術であるから、さらに、納付者からの問合せに円滑に対応できるように対策できる技術であるから、コンピュータを用いた情報処理の技術分野、特に、自治体が徴収する自動車税や固定資産税あるいは水道料金等の公金の収納を管理する技術分野において広範な産業上の利用可能性が期待される。
【図面の簡単な説明】
【０１２３】
【図１】本発明の最良の実施の形態に係る公金収納管理システムの構成及び周辺環境を示すブロック図である。
【図２】前記公金収納管理システムが備える基本情報データベースの構造図である。
【図３】同じく納付情報データベースの構造図（状況区分の移り変り状態を含む）である。
【図４】同じく資金化日データベースの構造図である。
【図５】納付手続日が同じでも公金取扱機関が異なると資金化日が異なる例を示すチャート図である。
【図６】公金取扱機関が異なっても資金化日が同じになる例を示すチャート図である。
【図７】納付通知書の作成動作を示すブロック図である。
【図８】指定金融機関での窓口収納の場合における、自治体、公金収納管理センター、納付者及び公金取扱機関の動作を示すブロック図である。
【図９】非指定金融機関での窓口収納の場合における、自治体、公金収納管理センター、納付者及び公金取扱機関の動作を示すブロック図である。
【図１０】コンビニ収納の場合における、自治体、公金収納管理センター、納付者及び公金取扱機関の動作を示すブロック図である。
【図１１】インターネットバンキングによるＷＥＢ電子収納の場合における、自治体、公金収納管理センター、納付者及び公金取扱機関の動作を示すブロック図である。
【図１２】クレジットカードによるＷＥＢ電子収納の場合における、自治体、公金収納管理センター、納付者及び公金取扱機関の動作を示すブロック図である。
【図１３】納付状況の問合せ時における、自治体、公金収納管理センター、納付者及び公金取扱機関の動作を示すブロック図である。
【図１４】自治体から公金収納管理センターへ送られる基本情報の構造図である。
【図１５】公金収納管理センターから納付者へ送られる納付通知書の構造図である。
【図１６】公金収納管理センターでデータ化される窓口納付情報の構造図である。
【図１７】公金収納管理センターから自治体へ送られる消込情報の構造図である。
【図１８】コンビニエンスストア収納代行会社から公金収納管理センターへ送られるコンビニ納付手続情報の構造図である。
【図１９】公金収納管理センターから自治体へ送られる仮消込情報（速報）の構造図である。
【図２０】コンビニエンスストア収納代行会社から公金収納管理センターへ送られるコンビニ納付確認情報の構造図である。
【図２１】公金収納管理センターから自治体へ送られる仮消込情報（確報）の構造図である。
【図２２】マルチペイメントネットワーク収納センターから公金収納管理センターへ送られるインターネットバンキング納付手続情報の構造図である。
【図２３】マルチペイメントネットワーク収納センターから公金収納管理センターへ送られるインターネットバンキング納付確認情報の構造図である。
【図２４】クレジット収納センターからクレジット納付手続兼確認情報の構造図である。
【図２５】自治体から公金収納管理センターへ送られる納付済情報の構造図である。
【図２６】公金収納管理センターからマルチペイメントネットワーク収納センター又はクレジット収納センターへ送られる回答情報の構造図である。
【図２７】公金収納管理センターから自治体へ送られる回答情報の構造図である。
【図２８】公金収納管理システムが基本情報の受信時に行う動作のフローチャートである。
【図２９】同じく窓口納付情報の登録時に行う動作のフローチャートである。
【図３０】同じく消込情報の送信時に行う動作のフローチャートである。
【図３１】同じくコンビニ収納の場合において仮消込情報（速報）の送信時に行う動作のフローチャートである。
【図３２】同じく資金化日の決定時に行う動作のフローチャートである。
【図３３】同じくコンビニ収納の場合において仮消込情報（確報）の送信時に行う動作のフローチャートである。
【図３４】同じくインターネットバンキングによるＷＥＢ電子収納の場合において仮消込情報（速報）の送信時に行う動作のフローチャートである。
【図３５】同じくインターネットバンキングによるＷＥＢ電子収納の場合において仮消込情報（確報）の送信時に行う動作のフローチャートである。
【図３６】同じくクレジットカードによるＷＥＢ電子収納の場合において仮消込情報（速報兼確報）の送信時に行う動作のフローチャートである。
【図３７】同じく納付状況の問合せ受信時に行う動作のフローチャートである。
【図３８】納付者がインターネットバンキングによるＷＥＢ電子収納を行う場合に納付者のＰＣに表れる初期画面である。
【図３９】同じく納付手続きを進める場合に納付者のＰＣに表れる画面である。
【図４０】同じく二重納付を防止して納付手続きを中止する場合に納付者のＰＣに表れる画面である。
【図４１】自治体が納付者からの問合せを受けて公金収納管理センターに照会する場合に自治体のシステムに表れる検索条件指定画面である。
【図４２】同じく自治体のシステムに表れる検索結果画面（検索日付時刻付）である。
【符号の説明】
【０１２４】
１０ 公金収納管理システム
１１ 中央処理装置
１２ 入力装置
１３ 出力装置
１４ 通信装置
１５ 記録装置
３１〜３５ コンピュータネットワーク
【特許請求の範囲】
【請求項１】
自治体の公金収納を管理するシステムであって、
公金を収納するために必要な情報を自治体から受け取る基本情報受取手段、
この基本情報受取手段が受け取った情報を案件毎に記録する基本情報記録手段、
納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報を前記公金取扱機関から受け取る納付情報受取手段、
前記基本情報記録手段が情報を記録した案件のうち、前記納付情報受取手段が納付情報を受け取った案件について、該納付情報受取手段が受け取った納付情報に基いて、自治体へ報告する情報を所定の統一された形式で作成する報告情報作成手段、及び、
この報告情報作成手段が作成した情報を自治体へ送る報告情報送り手段が備えられていることを特徴とする公金収納管理システム。
【請求項２】
請求項１に記載の公金収納管理システムであって、
前記報告情報作成手段は、納付者がいずれの公金取扱機関を介して公金の納付手続をしたかを含む情報を作成すると共に、納付者がインターネットバンキング又はクレジット決済による公金取扱機関を介して公金の納付手続をした場合であっても、納付者の口座情報及びクレジットカード情報を含まない情報を作成することを特徴とする公金収納管理システム。
【請求項３】
請求項１又は２に記載の公金収納管理システムであって、
前記納付情報受取手段が受け取った納付情報を案件毎に記録する納付情報記録手段、
公金の納付手続が済んでいるか否かの問合せを受け付ける問合せ受付手段、
この問合せ受付手段が問合せを受け付けた案件毎に前記納付情報記録手段が記録した納付情報を検索する納付情報検索手段、
この納付情報検索手段が検索した納付情報に基いて回答情報を作成すると共に、前記問合せ受付手段が受け付けた問合せが、公金取扱機関を経由した納付者からの問合せであるときは、納付者に関する情報のうち特定の情報を含まない回答情報を作成し、前記問合せ受付手段が受け付けた問合せが、自治体を経由した納付者からの問合せであるときは、納付者の口座情報及びクレジットカード情報を含まない回答情報を作成する回答情報作成手段、及び、
この回答情報作成手段が作成した回答情報を公金取扱機関又は自治体へ送る回答情報送り手段が備えられていることを特徴とする公金収納管理システム。
【請求項４】
請求項１から３のいずれかに記載の公金収納管理システムであって、
前記基本情報記録手段が記録した情報に基いて納付者へ送る納付通知書を作成する納付通知書作成手段が備えられていることを特徴とする公金収納管理システム。
【請求項５】
請求項４に記載の公金収納管理システムであって、
前記基本情報記録手段が情報を記録した案件毎に、案件を特定するコードを乱数を用いて設定する案件特定コード設定手段が備えられ、
前記納付通知書作成手段は、この案件特定コード設定手段が設定したコードを付した納付通知書を作成することを特徴とする公金収納管理システム。
【請求項６】
請求項１から５のいずれかに記載の公金収納管理システムであって、
前記納付情報受取手段は、納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報として、納付者が公金取扱機関を介して公金の納付手続をしたという手続情報及び自治体の口座へ入金する資金が準備されたという確認情報の２種類の情報を相前後して受け取り、
前記報告情報作成手段は、前記納付情報受取手段が前記手続情報を受け取った時点で、該手続情報に基いて、納付者が公金の納付手続をしたことを自治体へ連絡する旨の情報を作成し、
前記報告情報送り手段は、前記報告情報作成手段が前記情報を作成した時点で、該情報を自治体へ送ることを特徴とする公金収納管理システム。
【請求項７】
自治体の公金収納を管理する方法であって、
コンピュータを用いて、
公金を収納するために必要な情報を自治体から受け取る基本情報受取工程、
この基本情報受取工程で受け取った情報を案件毎に記録する基本情報記録工程、
納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報を前記公金取扱機関から受け取る納付情報受取工程、
前記基本情報記録工程で情報を記録した案件のうち、前記納付情報受取工程で納付情報を受け取った案件について、該納付情報受取工程で受け取った納付情報に基いて、自治体へ報告する情報を所定の統一された形式で作成する報告情報作成工程、及び、
この報告情報作成工程で作成した情報を自治体へ送る報告情報送り工程を行うことを特徴とする公金収納管理方法。
【請求項８】
自治体の公金収納を管理するためのプログラムであって、
コンピュータを、
公金を収納するために必要な情報を自治体から受け取る基本情報受取手段、
この基本情報受取手段が受け取った情報を案件毎に記録する基本情報記録手段、
納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報を前記公金取扱機関から受け取る納付情報受取手段、
前記基本情報記録手段が情報を記録した案件のうち、前記納付情報受取手段が納付情報を受け取った案件について、該納付情報受取手段が受け取った納付情報に基いて、自治体へ報告する情報を所定の統一された形式で作成する報告情報作成手段、及び、
この報告情報作成手段が作成した情報を自治体へ送る報告情報送り手段として機能させることを特徴とする公金収納管理用プログラム。
【請求項９】
請求項８に記載の公金収納管理用プログラムであって、
コンピュータを前記報告情報作成手段として機能させるときは、納付者がいずれの公金取扱機関を介して公金の納付手続をしたかを含む情報を作成すると共に、納付者がインターネットバンキング又はクレジット決済による公金取扱機関を介して公金の納付手続をした場合であっても、納付者の口座情報及びクレジットカード情報を含まない情報を作成するように機能させることを特徴とする公金収納管理用プログラム。
【請求項１０】
請求項８又は９に記載の公金収納管理用プログラムであって、
コンピュータを、
前記納付情報受取手段が受け取った納付情報を案件毎に記録する納付情報記録手段、
公金の納付手続が済んでいるか否かの問合せを受け付ける問合せ受付手段、
この問合せ受付手段が問合せを受け付けた案件毎に前記納付情報記録手段が記録した納付情報を検索する納付情報検索手段、
この納付情報検索手段が検索した納付情報に基いて回答情報を作成すると共に、前記問合せ受付手段が受け付けた問合せが、公金取扱機関を経由した納付者からの問合せであるときは、納付者に関する情報のうち特定の情報を含まない回答情報を作成し、前記問合せ受付手段が受け付けた問合せが、自治体を経由した納付者からの問合せであるときは、納付者の口座情報及びクレジットカード情報を含まない回答情報を作成する回答情報作成手段、及び、
この回答情報作成手段が作成した回答情報を公金取扱機関又は自治体へ送る回答情報送り手段として機能させることを特徴とする公金収納管理用プログラム。
【請求項１１】
請求項８から１０のいずれかに記載の公金収納管理用プログラムであって、
コンピュータを、
前記基本情報記録手段が記録した情報に基いて納付者へ送る納付通知書を作成する納付通知書作成手段として機能させることを特徴とする公金収納管理用プログラム。
【請求項１２】
請求項１１に記載の公金収納管理用プログラムであって、
コンピュータを、
前記基本情報記録手段が情報を記録した案件毎に、案件を特定するコードを乱数を用いて設定する案件特定コード設定手段として機能させると共に、
コンピュータを前記納付通知書作成手段として機能させるときは、この案件特定コード設定手段が設定したコードを付した納付通知書を作成するように機能させることを特徴とする公金収納管理用プログラム。
【請求項１３】
請求項８から１２のいずれかに記載の公金収納管理用プログラムであって、
コンピュータを前記納付情報受取手段として機能させるときは、納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報として、納付者が公金取扱機関を介して公金の納付手続をしたという手続情報及び自治体の口座へ入金する資金が準備されたという確認情報の２種類の情報を相前後して受け取るように機能させ、
コンピュータを前記報告情報作成手段として機能させるときは、前記納付情報受取手段が前記手続情報を受け取った時点で、該手続情報に基いて、納付者が公金の納付手続をしたことを自治体へ連絡する旨の情報を作成するように機能させ、
コンピュータを前記報告情報送り手段として機能させるときは、前記報告情報作成手段が前記情報を作成した時点で、該情報を自治体へ送るように機能させることを特徴とする公金収納管理用プログラム。
【請求項１】
自治体の公金収納を管理するシステムであって、
公金を収納するために必要な情報を自治体から受け取る基本情報受取手段、
この基本情報受取手段が受け取った情報を案件毎に記録する基本情報記録手段、
納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報を前記公金取扱機関から受け取る納付情報受取手段、
前記基本情報記録手段が情報を記録した案件のうち、前記納付情報受取手段が納付情報を受け取った案件について、該納付情報受取手段が受け取った納付情報に基いて、自治体へ報告する情報を所定の統一された形式で作成する報告情報作成手段、及び、
この報告情報作成手段が作成した情報を自治体へ送る報告情報送り手段が備えられていることを特徴とする公金収納管理システム。
【請求項２】
請求項１に記載の公金収納管理システムであって、
前記報告情報作成手段は、納付者がいずれの公金取扱機関を介して公金の納付手続をしたかを含む情報を作成すると共に、納付者がインターネットバンキング又はクレジット決済による公金取扱機関を介して公金の納付手続をした場合であっても、納付者の口座情報及びクレジットカード情報を含まない情報を作成することを特徴とする公金収納管理システム。
【請求項３】
請求項１又は２に記載の公金収納管理システムであって、
前記納付情報受取手段が受け取った納付情報を案件毎に記録する納付情報記録手段、
公金の納付手続が済んでいるか否かの問合せを受け付ける問合せ受付手段、
この問合せ受付手段が問合せを受け付けた案件毎に前記納付情報記録手段が記録した納付情報を検索する納付情報検索手段、
この納付情報検索手段が検索した納付情報に基いて回答情報を作成すると共に、前記問合せ受付手段が受け付けた問合せが、公金取扱機関を経由した納付者からの問合せであるときは、納付者に関する情報のうち特定の情報を含まない回答情報を作成し、前記問合せ受付手段が受け付けた問合せが、自治体を経由した納付者からの問合せであるときは、納付者の口座情報及びクレジットカード情報を含まない回答情報を作成する回答情報作成手段、及び、
この回答情報作成手段が作成した回答情報を公金取扱機関又は自治体へ送る回答情報送り手段が備えられていることを特徴とする公金収納管理システム。
【請求項４】
請求項１から３のいずれかに記載の公金収納管理システムであって、
前記基本情報記録手段が記録した情報に基いて納付者へ送る納付通知書を作成する納付通知書作成手段が備えられていることを特徴とする公金収納管理システム。
【請求項５】
請求項４に記載の公金収納管理システムであって、
前記基本情報記録手段が情報を記録した案件毎に、案件を特定するコードを乱数を用いて設定する案件特定コード設定手段が備えられ、
前記納付通知書作成手段は、この案件特定コード設定手段が設定したコードを付した納付通知書を作成することを特徴とする公金収納管理システム。
【請求項６】
請求項１から５のいずれかに記載の公金収納管理システムであって、
前記納付情報受取手段は、納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報として、納付者が公金取扱機関を介して公金の納付手続をしたという手続情報及び自治体の口座へ入金する資金が準備されたという確認情報の２種類の情報を相前後して受け取り、
前記報告情報作成手段は、前記納付情報受取手段が前記手続情報を受け取った時点で、該手続情報に基いて、納付者が公金の納付手続をしたことを自治体へ連絡する旨の情報を作成し、
前記報告情報送り手段は、前記報告情報作成手段が前記情報を作成した時点で、該情報を自治体へ送ることを特徴とする公金収納管理システム。
【請求項７】
自治体の公金収納を管理する方法であって、
コンピュータを用いて、
公金を収納するために必要な情報を自治体から受け取る基本情報受取工程、
この基本情報受取工程で受け取った情報を案件毎に記録する基本情報記録工程、
納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報を前記公金取扱機関から受け取る納付情報受取工程、
前記基本情報記録工程で情報を記録した案件のうち、前記納付情報受取工程で納付情報を受け取った案件について、該納付情報受取工程で受け取った納付情報に基いて、自治体へ報告する情報を所定の統一された形式で作成する報告情報作成工程、及び、
この報告情報作成工程で作成した情報を自治体へ送る報告情報送り工程を行うことを特徴とする公金収納管理方法。
【請求項８】
自治体の公金収納を管理するためのプログラムであって、
コンピュータを、
公金を収納するために必要な情報を自治体から受け取る基本情報受取手段、
この基本情報受取手段が受け取った情報を案件毎に記録する基本情報記録手段、
納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報を前記公金取扱機関から受け取る納付情報受取手段、
前記基本情報記録手段が情報を記録した案件のうち、前記納付情報受取手段が納付情報を受け取った案件について、該納付情報受取手段が受け取った納付情報に基いて、自治体へ報告する情報を所定の統一された形式で作成する報告情報作成手段、及び、
この報告情報作成手段が作成した情報を自治体へ送る報告情報送り手段として機能させることを特徴とする公金収納管理用プログラム。
【請求項９】
請求項８に記載の公金収納管理用プログラムであって、
コンピュータを前記報告情報作成手段として機能させるときは、納付者がいずれの公金取扱機関を介して公金の納付手続をしたかを含む情報を作成すると共に、納付者がインターネットバンキング又はクレジット決済による公金取扱機関を介して公金の納付手続をした場合であっても、納付者の口座情報及びクレジットカード情報を含まない情報を作成するように機能させることを特徴とする公金収納管理用プログラム。
【請求項１０】
請求項８又は９に記載の公金収納管理用プログラムであって、
コンピュータを、
前記納付情報受取手段が受け取った納付情報を案件毎に記録する納付情報記録手段、
公金の納付手続が済んでいるか否かの問合せを受け付ける問合せ受付手段、
この問合せ受付手段が問合せを受け付けた案件毎に前記納付情報記録手段が記録した納付情報を検索する納付情報検索手段、
この納付情報検索手段が検索した納付情報に基いて回答情報を作成すると共に、前記問合せ受付手段が受け付けた問合せが、公金取扱機関を経由した納付者からの問合せであるときは、納付者に関する情報のうち特定の情報を含まない回答情報を作成し、前記問合せ受付手段が受け付けた問合せが、自治体を経由した納付者からの問合せであるときは、納付者の口座情報及びクレジットカード情報を含まない回答情報を作成する回答情報作成手段、及び、
この回答情報作成手段が作成した回答情報を公金取扱機関又は自治体へ送る回答情報送り手段として機能させることを特徴とする公金収納管理用プログラム。
【請求項１１】
請求項８から１０のいずれかに記載の公金収納管理用プログラムであって、
コンピュータを、
前記基本情報記録手段が記録した情報に基いて納付者へ送る納付通知書を作成する納付通知書作成手段として機能させることを特徴とする公金収納管理用プログラム。
【請求項１２】
請求項１１に記載の公金収納管理用プログラムであって、
コンピュータを、
前記基本情報記録手段が情報を記録した案件毎に、案件を特定するコードを乱数を用いて設定する案件特定コード設定手段として機能させると共に、
コンピュータを前記納付通知書作成手段として機能させるときは、この案件特定コード設定手段が設定したコードを付した納付通知書を作成するように機能させることを特徴とする公金収納管理用プログラム。
【請求項１３】
請求項８から１２のいずれかに記載の公金収納管理用プログラムであって、
コンピュータを前記納付情報受取手段として機能させるときは、納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報として、納付者が公金取扱機関を介して公金の納付手続をしたという手続情報及び自治体の口座へ入金する資金が準備されたという確認情報の２種類の情報を相前後して受け取るように機能させ、
コンピュータを前記報告情報作成手段として機能させるときは、前記納付情報受取手段が前記手続情報を受け取った時点で、該手続情報に基いて、納付者が公金の納付手続をしたことを自治体へ連絡する旨の情報を作成するように機能させ、
コンピュータを前記報告情報送り手段として機能させるときは、前記報告情報作成手段が前記情報を作成した時点で、該情報を自治体へ送るように機能させることを特徴とする公金収納管理用プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【公開番号】特開２００９−１５６３１（Ｐ２００９−１５６３１Ａ）
【公開日】平成２１年１月２２日（２００９．１．２２）
【国際特許分類】
【出願番号】特願２００７−１７７２０６（Ｐ２００７−１７７２０６）
【出願日】平成１９年７月５日（２００７．７．５）
【出願人】（５０７２２８１７２）株式会社日本総研ソリューションズ (23)
【出願人】（５９７０３４４０６）株式会社 さくらケーシーエス (2)
【公開日】平成２１年１月２２日（２００９．１．２２）
【国際特許分類】
【出願日】平成１９年７月５日（２００７．７．５）
【出願人】（５０７２２８１７２）株式会社日本総研ソリューションズ (23)
【出願人】（５９７０３４４０６）株式会社 さくらケーシーエス (2)
[ Back to top ]