JP4231655B2 - 金融機関情報一元管理システム、および、金融機関情報の管理方法 - Google Patents

Description

【０００１】
【発明が属する技術分野】
本発明は、金融機関や店舗名の業務引継ぎなどの情報を一元的に管理するシステムおよび管理方法に関する。
【０００２】
【従来の技術】
旧来、金融機関への振込み、預入などは、直接金融機関の窓口で行うものであり、顧客が、銀行名、支店名を記入すれば振込を実施できる。しかしながら、端末装置を利用した電子商取引等においては、端末装置により、振込をしたい銀行、支店の、定められた「銀行コード」および「支店コード」を特定して、当該特定された口座への送金などを実行する必要があるため、金融機関や店舗を特定する情報を把握することが重要となっている。
【０００３】
【発明が解決しようとする課題】
ところで、昨今の金融機関の再編成・統廃合の動きにより、銀行コードおよび銀行名（金融機関コード／名称）ならびに支店コードおよび支店名（店舗コード／名称）を示す情報が大幅に変更となり、端末装置にて保持された情報を一定のタイミングで変更しなかった場合に、円滑に所望の取引を実行することが困難となる。
【０００４】
また、ユーザだけでなく、決済受託金融機関にとっても、無効となった金融機関を特定する情報によって、振込先や引き落とし先の金融機関が不明となるという事態が生じうる。
本発明は、ユーザおよび金融機関の双方が、円滑に電子商取引を含む資金決済を実現可能とするために、金融機関の情報を一元的に管理するシステムを提供することを目的とする。
【０００５】
【課題を解決するための手段】
本発明の目的は、種々の金融機関の金融機関コード、金融機関の名称、店舗コードおよび店舗の名称を含む情報を受理する情報受理手段と、前記情報に基づき、新設および業務引継を含む業務形態の変更を検出する変更検出手段と、前記変更検出手段における検出内容にしたがって、他店舗の業務を引き継ぐ場合に、前記業務が引き継がれる他の店舗のレコードとのリンクを形成して、有効開始日とともに、新たなレコードとして継承データベースに登録する情報処理手段と、前記有効開始日を検索して、処理の実行時点で有効となっている店舗のレコードを特定する日時処理手段とを備えたことを特徴とする金融機関情報一元管理システムにより達成される。
【０００６】
本発明によれば、金融機関の店舗ごとのレコードの間に、業務引継ぎを示すリンクを形成し、かつ、現時点で有効となっている店舗のレコードが特定されるようになっている。したがって、レコード間のリンクをたどることにより、現時点で有効な店舗を特定する情報（金融機関コード、金融機関の名称、店舗コード、店舗の名称）を取得することが可能となる。継承データベース自体或いは継承データベースから抽出した情報を、電子商取引を含む資金決済を実行するクライアントマシンに伝達することにより、クライアントマシンにおいては適切な金融機関および店舗を特定する情報を利用することができる。これにより、ユーザ側および金融機関の双方において円滑な電子商取引を含む資金決済を実現することが可能となる。
【０００７】
なお、金融機関コード、金融機関の名称、店舗コードおよび店舗の名称を含む情報の情報源は、金融機関、金融機関の団体に限定されるものではなく、他の機関などから取得しても良い。
好ましい実施態様においては、前記情報処理手段が、他店舗の業務を引き継ぐ場合に、当該他の店舗のレコードに付与された、業務引継の世代数を示す世代番号をインクリメントして、自己のレコードの世代番号として設定するように構成されている。このような世代管理により、レコードの検索対象を世代により特定し、或いは、世代ごとの金融機関コードや店舗コードの出力などが可能となる。
【０００８】
また、好ましい実施態様においては、前記情報処理手段が、継承ＤＢ中の他のレコードを検索して、金融機関コード、金融機関の名称、店舗コードおよび店舗の名称が同一であるようなレコードを見出した場合に、当該レコードおよび他のレコードに、情報の重複を示す重複フラグをセットするように構成されている。たとえば、いったん廃止になった店舗が、時間を追って復活した場合に、これが過去に存在した店舗と同一のコードや名称を有していることを特定することができる。たとえば、重複フラグがセットされた場合には、このレコードの情報を提示する場合に、他の店舗に、金融機関コードや店舗コードが同一であることを示す情報を付加し、ユーザなどに注意すべきことを通知することができる。
【０００９】
また、別の好ましい実施態様においては、前記変更検出手段の検出内容にしたがって、前記情報処理手段が、廃止される店舗の情報に基づき、廃止される店舗のレコードに、廃止となる日を示す有効終了日を付与するとともに、廃止フラグをセットするように構成されている。
【００１０】
さらに、別の好ましい実施態様においては、情報処理手段が、レコードの有効開始日を参照して、当該有効開始日が、前記処理を実行する日以前である場合には、当該レコードが有効であることを示す有効フラグをセットするように構成されている。
【００１１】
より好ましくは、日時処理手段が、レコードの有効開始日が、当該処理の実行日以前である場合には、有効フラグをセットし、かつ、レコードの有効終了日が、当該処理の実行日以後である場合には、有効フラグをリセットするように構成されている。たとえば、深夜のバッチ処理により、日時処理手段が起動して、フラグのセット／リセットを実行することにより、継承データベースの状態を最新のものに維持することが可能となる。
【００１２】
また、別の好ましい実施態様においては、情報処理手段が、レコードのリンクを参照して、前記レコードの店舗の業務を引き継ぐ他の店舗が存在する場合に、当該レコードが最新世代であることを示す最新世代フラグをリセットし、それ以外の場合に、最新世代フラグをセットするように構成されている。
【００１３】
また、本発明の目的は、金融機関情報を管理するサーバにおいて、種々の金融機関の金融機関コード、金融機関の名称、店舗コードおよび店舗の名称を含む情報を受理するステップと、前記情報に基づき、新設および業務引継を含む業務形態の変更を検出する変更するステップと、前記変更検出手段における検出内容にしたがって、他店舗の業務を引き継ぐ場合に、前記業務が引き継がれる他の店舗のレコードとのリンクを形成して、有効開始日とともに、新たなレコードとして継承データベースに登録するステップと、前記継承データベース中の所定の情報を、所定のクライアントコンピュータに通知するステップとを備えたことを特徴とする金融機関情報一元管理方法によっても達成される。
【００１４】
好ましい実施態様においては、さらに、前記クライアントコンピュータにおいて、前記通知される情報にしたがって、当該クライアントコンピュータにて保持する継承データベースを更新するステップを備えている。
より好ましい実施態様においては、さらに、前記クライアントコンピュータにおいて、前記更新された継承データベースを参照して、当該クライアントコンピュータにて保持する情報に含まれる、金融機関コード、金融機関の名称、店舗コードおよび／または店舗の名称の情報を更新するステップを備えている。
【００１５】
また、前記クライアントコンピュータにおいて、種々の金融機関に関する金融機関コード、金融機関の名称、店舗コードおよび店舗の名称を含む最新の情報を収容した最新データベースを受理するステップと、前記最新データベースを参照して、前記クライアントコンピュータにて保持する情報を修正するステップとを備えているのが望ましい。
【００１６】
別の好ましい実施態様においては、さらに、前記サーバにおいて、クライアントコンピュータから金融機関コード、金融機関の名称、店舗コードおよび店舗の名称を示す情報を受理し、当該クライアントコンピュータに関連付けて登録するステップと、前記継承データベースに新たに登録された情報のうち、前記登録された情報に関連するものを検出するステップと、検出されたレコードから抽出される所定の情報を、前記クライアントコンピュータに通知するステップとを備え、
前記クライアントコンピュータにおいて、通知された情報により、当該クライアントコンピュータにて保持する金融機関コード、金融機関の名称、店舗コードおよび／または店舗の名称の情報を更新するステップを備えている。
【００１７】
【発明の実施の形態】
以下、添付図面を参照して、本発明の実施の形態につき説明を加える。図１は、本発明の実施の形態にかかるシステム全体の概略を示すブロックダイヤグラムである。図１に示すように、システムには、金融機関コードを変換し、金融機関コードの継承などを示す必要なデータを作成する情報管理サーバ１２と、前記データを蓄積する継承データベース（ＤＢ）１４とが設けられている。
【００１８】
情報管理サーバ１２は、インターネット１６に接続され、インターネット１６に接続された金融機関や金融機関の団体のサーバ２０−１、２０−２、・・・から、金融機関コード／名称や店舗コード／名称に関する種々の情報（集積情報）を、当該インターネット１６を介して受理する（符号１００−１参照）。或いは、金融機関や団体から、テープなどの可搬記憶媒体１１０を利用して、オフラインで集積情報が与えられても良い。
【００１９】
また、情報管理サーバ１２は、金融機関との間で、インターネット１６を介したオンライン取引をしているユーザの端末装置１８−１、１８−２、…に、更新した継承ＤＢ１４の情報を伝達することができる。これは、インターネット１６を介したオンラインのものでも良いし（符号１０１−１参照）、或いは、フレキシブルディスクやＣＤ−ＲＯＭなどの可搬記憶媒体１１２を利用したオフラインのものでもよい（符号１０１−２参照）。
【００２０】
なお、本実施の形態においては、インターネット１６を介した通信により、場合によって、集積情報や継承ＤＢ１４の情報を授受しているが、これに限定されるものではなく、ＷＡＮなど他のネットワークが利用されても良いことは言うまでもない。また、ユーザの端末装置１８が、金融機関のサーバ２０にアクセスすることにより電子商取引が実行されるのみならず、金融機関のサーバ間において、インターネットや他のネットワークが利用されて、資金決済が行われていることも言うまでもない。
【００２１】
以下、図２〜図６のフローチャートなどを参照して、情報管理サーバ１２における処理をより詳細に説明する。図２は、本実施の形態にかかる情報管理サーバ１２にて実行される処理を示すフローチャートである。情報管理サーバ１２は、金融機関サーバ２０から、種々の情報を収集、集積し、これを継承ＤＢ１４を構築するための元データとする（ステップ２００）。このように集積された情報を集積情報と称する。
本実施の形態においては、金融機関から、金融機関コード／名称や店舗コード／名称を受理して、金融機関自体或いは店舗の統廃合によるコードの変更、新規店舗の開店などを識別し、かつ、変更等にかかる金融機関や店舗の継承情報、つまり、どの金融機関や店舗の業務が引き継がれているかを示す情報を作成している。
【００２２】
より詳細には、集積情報のレコードを読み込んだ後（ステップ２０１）、当該レコード中の内容、特に、後述する金融機関コードおよび名称、並びに、店舗コードおよび名称を参照して、当該レコードに関して、その内容が何を示すかを識別する（ステップ２０２）。ここに、レコードとは、後述するように、ある金融機関の店舗に関する種々の情報を保持するデータ集合体の単位をいう。
【００２３】
ステップ２０２においては、新規の金融機関や店舗の設立／開店（新設）、金融機関や店舗の廃止（廃止）、金融機関コード／名称や店舗コード／名称の変更（変更）があるか否かが判断される。たとえば、店舗の統廃合に際して、一方の店舗が存続店舗として残って業務を引き継ぎ、もう一方が廃止される場合や、両店舗が廃止され、新たに、両店舗の業務を引き継ぐ新規店が立ち上げられる場合がある。たとえば、前者において、存続店舗に関するレコードの内容を参照することにより、ステップ２０２において「変更有」と判断されて、ステップ２０３以降の処理に進む。その一方、廃止される店舗に関するレコードの内容を参照することにより、ステップ２０２において「新設／廃止」と判断されて、ステップ２０６の処理に進む。
【００２４】
また、レコードを参照した結果、内容に変更がない（ステップ２０２で「変更無」）の場合には、読み込まれるべき他のレコードがあるか否かが判断され（ステップ２０７）、処理が繰り返される。
【００２５】
ステップ２０２において「変更有」と判断された場合につき、以下に説明を加える。この場合には、次に、変更情報ＤＢが有るか否かが判断される（ステップ２０３）。実際には、これは、継承ＤＢ１４中に、金融機関コードおよび店舗コードをもつレコードがすでに存在しているか否かを判断することにより実現される。ステップ２０３でノー(No)と判断された場合には、第１の更新処理（継承ＤＢ１４への新規なレコード作成処理）が実行される（ステップ２０４）。これに対して、すでに継承ＤＢ１４中に、レコードが存在している場合（ステップ２０３でイエス(Yes)）には、第２の更新処理（もとのレコードと関連付けたレコードの作成処理）が実行される（ステップ２０５）。これら処理をより詳細に説明するのに先立って、継承ＤＢ１４中のレコードにつき、図６を参照して説明を加える。
【００２６】
図６に示すように、継承ＤＢ１４中のレコードには、「リンク」、「世代No.（ナンバー）」、「業態」、「金融機関コード」、「店舗コード」、「出張所コード」、「金融機関名（カナおよび漢字）」、「店舗名（カナおよび漢字）」が含まれる。「リンク」は、金融機関や店舗の業務がどのように引き継がれたかを示すものである。このリンクにより、業務が引き継がれた旧金融機関や旧店舗の情報を特定することができる。リンクは、後述するように、新規継承情報追加時、つまり、第１の更新処理により、新たなレコードが作られるときに設定され、既存情報については同一採番となる。また、「世代No.」により、統廃合により何代にわたって業務が引き継がれたかを知ることができる。さらに、レコードには、種々のフラグが設けられる。これらについては、後に詳述する。
【００２７】
図３および図４は、ステップ２０４の第１の更新処理をより詳細に示すフローチャートである。まず、リンク情報が新たに採番される（ステップ３０１）とともに、世代情報が採番される（ステップ３０２）。次いで、金融機関情報の書き込みが実行され、情報管理サーバ１２に与えられた情報に基づき、レコードを構成する種々の項目（たとえば、図６に示すＮｏ．３〜Ｎｏ．１０の項目）に値が付与される（ステップ３０３）。次いで、金融機関コードや店舗コードが重複した他のレコードが存在するか否かが判断される（ステップ３０４）。ステップ３０４においてイエス(Yes)と判断された場合には、当該レコードにおいて、「重複フラグ」を「１」とする（ステップ３０５）。
【００２８】
次いで、引継があるか否かが判断される（ステップ３０６）。これは、書き込まれた情報にかかる店舗が廃止店舗となり、他の店舗に吸収される（その業務が引き継がれる）ことを見出すためのステップである。ステップ３０６においてイエス(Yes)と判断されると、当該レコードの「引継フラグ」に「１」がセットされ（ステップ３０７）、かつ、引継ぎ先のリンクが、リンク情報として加えられる（ステップ３０８）。引継フラグが「１」であることは、当該レコードにかかる店舗が廃止され、別リンクにかかる店舗に業務が引き継がれていることを意味する。
【００２９】
さらに、情報が有効となる日（有効開始日）が読み込まれ（ステップ３０９）、有効日が処理日より先であるか過去であるかが判断される（ステップ４０１）。以下、情報の有効日が先（つまり将来）であるか、過去であるか、過去の場合には、引継ぎの有無によって、レコード中の他の各種フラグがセットされる。たとえば、有効日が先である場合（ステップ４０１で、「有効日先日付」）には、「最新世代フラグ」が「ＯＮ」つまり「１」とする一方、「有効フラグ」が「ＯＦＦ」つまり「０」にセットされる（ステップ４０２、４０３）。最新世代フラグは、当該レコードの情報が最新の継承店であることを示すものである。また、有効フラグとは、処理時（日時）において、レコードの情報が有効であるか否かを示している。つまり、ステップ４０２、４０３のフラグ設定により、このレコードが、最新であるが、いまだ当該情報が有効になる日付に至っていないことが示される。
【００３０】
その一方、ステップ４０１で「有効日過去日付」と判断され、かつ、ステップ３０７で設定された「引継フラグ」が「０」である場合（ステップ４０４でノー(No)）には、最新世代フラグが「ＯＮ］つまり「１」にセットされるとともに、「有効フラグ」が「ＯＮ」つまり「１」にセットされる（ステップ４０５、４０６）。これらフラグ設定により、当該レコードが示す情報が、最新のものであり、かつ、有効であることが示される。
【００３１】
また、ステップ４０１で「有効日過去日付」と判断され、かつ、「引継ぎフラグ」が「１」である場合（ステップ４０４でイエス（Yes））には、「最新世代フラグ」が「ＯＦＦ」つまり「０」、「有効フラグ」が「ＯＦＦ」つまり「０」、および、「廃止フラグ」が「ＯＮ」つまり「１」に、それぞれセットされる（ステップ４０７〜４０９）。これらフラグ設定により、当該レコードが示す情報が、最新ではなく、また、有効ではなく、すでに店舗が廃止されていることを示している。廃止フラグとは、該当する金融機関の店舗が廃店となったことを示す識別子である。
【００３２】
ここで、フラグについて、再度、簡単に説明を加える。有効フラグとは、該当する金融機関の店舗の情報が有効であることを識別し、また、引継フラグとは、統廃合などにより、業務が他店舗に引き継がれることを識別するものである。また、有効終了日とは、該当する情報が、有効である期間が終了する日を指す。
このようなフラグ設定の後、当該レコードの更新日付を書き込むことにより（ステップ４１０）、第１の更新処理が終了する。
【００３３】
次に、ステップ２０５の第２の更新処理につき、図５のフローチャートを参照して、より詳細に説明を加える。第２の更新処理は、第１の更新処理により、すでに、金融機関の店舗に関するレコードが継承ＤＢ１４に作成されていた場合に、当該金融機関の店舗に変更が生じた場合に実行されるものである。
第２の更新処理においては、まず、継承ＤＢ１４に記憶された現世代のレコードの情報が抽出されるとともに、新たなレコードとして、今回読み込まれた情報である新世代の情報が書き込まれる（ステップ５０１、５０２）。現世代のレコードは、金融機関コードや店舗コードをキーとして抽出することができる。
【００３４】
次いで、新たな（新世代の）レコードに、現世代のレコードのリンクが引き継がれるとともに、新たなレコードの世代番号(No.)として、現世代の世代番号に「１」を加えたものがセットされる（ステップ５０３、５０４）。次いで、新たなレコードに、金融機関情報の書き込みが実行され、情報管理サーバ１２に与えられた情報に基づき、レコードを構成する種々の項目（たとえば、図６に示すＮｏ．３〜Ｎｏ．１０の項目）に値が付与される（ステップ５０５）。
【００３５】
この後、図３のステップ３０４〜３０９および図４のステップ４０１〜４１０と同様の処理が実行される（ステップ５０６）。つまり、これ以降の処理では、各種フラグの書き込み、フラグに基づく他のフラグのセットなどが実行される。このように、第２の更新処理においては、既に継承ＤＢ１４に登録された店舗に何らかの変更（たとえば、廃止など）が生じた際に、これに応答して、当該店舗のレコードとのリンクを保ちつつ、世代が１つ加えられた新たなレコードが作られる。したがって、第２の更新処理を繰り返すことにより、金融機関や店舗の統廃合が繰り返されても、店舗のレコードを適切にさかのぼることができ、かつ、どの情報が現時点で有効であるかも判断することが可能となる。
【００３６】
図２に戻って、ステップ２０２において、情報が「新設／廃止」にかかるものと判断された場合には、確保処理が実行される（ステップ２０６）。確保処理においては、新設／廃止にかかる金融機関の店舗の情報が、一時的に確保される。たとえば、継承ＤＢ１４や他の記憶装置の所定の領域に、この情報を記憶しておけばよい。これは、後述するように、すべての読込情報に対して更新処理が完了した後、新設／廃止にかかるフラグや日付を更新するための確保情報更新処理（ステップ２０９）にて利用される。
【００３７】
すべての読込情報に関して、必要な処理が実行されると（ステップ２０７でノー(No)、確保処理にて確保された情報が存在するか否かが判断される（ステップ２０８）。ステップ２０８でイエス(Yes)、つまり、何れかの読込情報に関して確保処理が実行されていると判断されると、確保情報更新処理が実行される（ステップ２０９）。確保情報更新処理においては、一時的に確保された情報を参照して、当該情報が示す金融機関コードや店舗コードを参照して、該当するレコードの廃止フラグを更新する。つまり、廃止された店舗に関して、「廃止フラグ」を「０」にセットする。
【００３８】
上述した処理が完了することで、継承ＤＢの更新処理が終了する（ステップ２１０）。情報管理サーバ１８にて作成された継承ＤＢ中の情報は、インターネットを介して、或いは、可搬記憶媒体により、ユーザの端末装置１８に与えられる（図１の符号１０１−１、１０１−２参照）。
【００３９】
端末装置１８においては、取得した情報に基づいて、自己のＤＢ内で管理されている情報を更新することにより、金融機関コードや店舗コードの変更に対応したＤＢを作成する。図７および図８は、端末装置におけるデータ変換処理を示すフローチャートである。まず、端末装置１８は、変換対象となる情報（変換先情報）、たとえば、端末装置１８に保持されている振込情報のレコードを抽出して（ステップ７０１、７０２）、当該抽出したレコードの金融機関コード／名称、および、店舗コード／名称に基づき、自己のＤＢ（端末装置１８の継承ＤＢ）中の対応するレコードを特定して、当該レコードのデータを読み込む（ステップ７０３）。
【００４０】
ここで、自己のＤＢ中に対応するレコードが存在しなかった場合（ステップ７０４でノー(No)）には、不要情報として、レコードが存在しなかったことを外部ファイルに書き出しておく（ステップ８０１）。書き出された外部ファイルは、最終的に出力される。
【００４１】
ステップ７０４でイエス（Yes）と判断された場合には、抽出されたレコードと、自己のＤＢ中に記憶されていたレコードとの間で、種々のフラグを比較して、必要な処理を実行する（ステップ７０５〜７０８）。たとえば、重複フラグの有無（ステップ７０５）が判断され、重複フラグが「１」である場合には（ステップ７０５でイエス(Yes)）、指定設定判断が実行される（ステップ８０２）。基本的には、ある金融機関、および、金融機関に属する店舗の店舗コードは、重複の無いように設定されている。しかしながら、同一の場所にあって一度廃止された店舗が時間の経過の後復活した場合に、過去と同じ支店名が付与され、金融機関コード／名称および店舗コード／名称が一致する可能性がある。そこで、重複フラグを判断して、変換先情報（新しいレコード）を参照して、重複する店舗が存在する場合には、これをユーザに通知するようにしている。
【００４２】
指定設定判断とは、ユーザ側が、重複情報の通知のために設定した条件を判断することをいう。ユーザは、あらかじめ、どの程度の日付までさかのぼって重複の有無を判断するかを示す、変換対象日付を指定することができる。また、ユーザは、重複が存在した場合に、これを「不要情報」と識別させて、外部ファイルに出力させるか、或いは、「変換不能情報」として、外部ファイルに出力させるかを指定することができるとともに、「日付識別」、つまり、重複したレコードを比較して、より現在に近い日付の情報を利用させるように設定することもできる。
【００４３】
ユーザによる設定を参照して、ユーザが、重複を「変換不要情報」或いは「変換不能情報」と設定している場合には、ステップ８０１において、変換不要情報或いは変換不能情報として外部ファイルが書き出される。その一方、ユーザにより「日付識別」が設定されている場合には、所定の変換情報、つまり、新たなレコードが取得されて（ステップ８０３）、元のレコードが新たなレコードに書き換えられる（ステップ８０４）。
【００４４】
同様に、有効世代がある場合、つまり、新たなレコード中の有効フラグが「１」である場合にも（ステップ７０６でイエス（Yes））、新たなレコードの取得およびレコードの書き換えが実行される（ステップ８０３、８０４）。レコードが書き換えられると、これが、変換情報として外部ファイルに書き出される。これは変換結果履歴として端末装置１８内に蓄積される。なお、変換結果履歴には、上記正常に変換されたことを示す情報のほか、変換不要情報や変換不能情報が含まれる。
【００４５】
その一方、有効フラグが「０」である場合（ステップ７０６でノー(No)）には、新たなレコード中の廃止フラグの有無が判断される（ステップ７０７）。廃止フラグが「１」である場合（ステップ７０７でイエス(Yes)）には、変換情報が無いと判断して（ステップ８０５）、変換不能情報が書き出される（ステップ８０６）。その一方、廃止フラグがない場合には、引継ぎ先の有無、つまり、新しいレコード中に引継ぎフラグおよび引継ぎリンクが存在するか否かが判断される（ステップ７０８）。
【００４６】
ステップ７０８でノー(No)と判断された場合には、ステップ８０５および８０６に進む。その一方、ステップ７０８でイエス(Yes)、つまり、引継ぎフラグが「１」で引継ぎリンクが存在していれば、新たなレコードから引継ぎリンクが取得され（ステップ７０８）、当該引継ぎリンクに示すレコードを取り出して、ステップ７０４以降の処理を繰り返す。これにより、引継ぎ先に関して、レコードの書き換えなどが実行され得る。
【００４７】
このようにして、情報管理サーバ１２から与えられた情報に基づいて、端末装置１８において、当該端末装置１８が有する情報の変換が実現される。情報管理サーバ１２から与えられたすべてのレコードに対して処理が実行されると、ステップ８０４にて正常に変換されたことを示す外部ファイル、並びに、不要情報および更新不能情報が、ユーザに提示される。ユーザは、提示された情報を参照することで、継承ＤＢ中の何れかの情報に変化があったか、或いは、どの情報について重複が存在し、或いは、どの情報について変換が不能であったかを知ることができる。
【００４８】
ユーザが端末装置１８を操作して、所定の金融機関のサーバ２０との間で電子商取引を実行する際に、ユーザが取引している金融機関名や店舗名をキーとして、端末装置１８の継承ＤＢが参照され、現在有効で（「有効フラグ」が「１」）、かつ、最新世代（「最新世代フラグ」＝「１」）であるような金融機関コードおよび店舗コードが特定され、当該金融機関コードおよび店舗コードを有する店舗の口座への預金の移動が可能となる。
また、継承ＤＢは、ユーザの口座から他行の口座への振込みの際にも利用され得る。この場合に、他行の店舗を指定する際に、継承ＤＢを検索すればよい。
【００４９】
次に、情報管理サーバ１２における日時処理につき説明を加える。この日時処理は、夜間にいわゆるバッチ処理にて、その日をもって廃止になる店舗や、その日に新設される店舗を特定して、その店舗に関するレコードのフラグを書き換えるとともに、ユーザなどに通知するためのＤＢ（アナウンスＤＢ）を作成している。
【００５０】
より詳細には、まず、継承ＤＢ１４中の各レコード中の、有効開始日が抽出される（ステップ９０１）。次いで、有効開始日が、処理が実行された日と同一（つまり、当日）であるか否かが判断される（ステップ９０２）。当日である場合（ステップ９０２で「該当」）には、対応するレコードの「有効フラグ」が「ＯＮ」つまり「１」にセットされるとともに（ステップ９０３）、当該レコード中の所定の情報（たとえば、金融機関コード／名称および店舗コード／名称）がアナウンスＤＢに追加される（ステップ９０４）。このような処理をすべてのレコードに関して実行することにより（ステップ９０５参照）、当該処理が実行された日に新たに営業を開始される店舗に関するレコードを有効とすることができる。また、当該実行日に店舗の営業が開始されたことをユーザなどに通知することができる。
【００５１】
同様に、廃止される店舗に関しても、各レコード中の有効終了日が抽出され（ステップ９０８）、処理の実行日に該当する有効終了日があれば（ステップ９０７で「該当」）、関連するレコードの「有効フラグ」が「ＯＦＦ」つまり「０」にセットされ（ステップ９０８）、当該レコード中の所定の情報がアナウンスＤＢに追加される（ステップ９０９）。
作成されたアナウンスＤＢ中のデータは、情報管理サーバ１２の管理者に提示されるとともに、端末装置１８に、たとえば、インターネット１６を介して、メールなどの形式で送信される。これにより、端末装置１８のユーザは、店舗の廃止や新設をタイムリーに知ることが可能となる。
【００５２】
このように、本実施の形態によれば、各種金融機関からの金融機関コード／名称、店舗コード／名称を受理すると、情報処理サーバが、関連するレコードを見出して、店舗の廃止や継承などを把握しつつ、新たなレコードを継承ＤＢに記憶する。出来上がった継承ＤＢの情報は、端末装置１８に与えられ、当該端末装置に保持された継承ＤＢが、与えられた情報に基づき更新（データ変換）される。これにより、端末装置１８においては、金融機関や店舗の継承を適切に把握することができ、正しい金融機関コード／名称および店舗コード／名称を用いた取引が可能となる。
【００５３】
次に、本発明の第２の実施の形態につき説明を加える。端末装置１８に保持されている振込情報のレコードには、金融機関コード／名称および店舗コード／名称のすべてが含まれず、たとえば、コードのみが含まれる場合などがある。また、上記金融機関コード／名称および店舗コードおよび名称が含まれていても、ユーザの誤入力などによる誤記が含まれている場合もある。このようなレコードについては、第１の実施の形態にかかるデータ変換処理によって、変換することができなかった。そこで、第２の実施の形態においては、このように、項目に欠落がある場合でも、当該欠落を埋め合わせるような処理を付加している。
【００５４】
図１０は、第２の実施の形態にかかるシステム全体の概略を示すブロックダイヤグラムである。第２の実施の形態においては、情報管理サーバ１２が、金融機関の最新情報を保持した最新ＤＢ１５を備えている。図１１に示すように、最新ＤＢ１５のレコードには、項目として、金融機関の名称の後半に付与されている、「銀行」、「信託銀行」など業種ごとに与えられた総称に関する情報（業態情報）、金融機関自体の情報（機関情報）、店舗の情報（店舗情報）、電話番号情報、住所情報などが含まれる。また、図示しないが、最新ＤＢ１５のレコードには、外国為替取扱店であるか、或いは、手形交換所であるかなどを示す種々の付加情報が含まれる。
【００５５】
たとえば、業態情報は、都市銀行、地方銀行、信託銀行、長期信用銀行など、銀行の業種（カテゴリー）を示す。また、呼称コードとは、銀行の店舗の呼称（たとえば、本店、本所、支店、支所、出張所など）に対応して付与されるコード（番号）であり、呼称要不要コードとは、本店など、店舗名そのものに呼称が含まれるため、結果として呼称コードが不要であることを明示するために利用される。
母店情報とは、出張所、特別出張所など、店舗が、ある支店と関連付けされている場合に、これを特定するために利用される情報である。
【００５６】
情報管理サーバ１２は、金融機関やその団体から送られてきた最新の情報から、上記項目を抽出したレコードを生成し、最新ＤＢ１５として保持する。また、第２の実施の形態において、情報管理サーバ１２は、生成した継承ＤＢとともに、上記最新ＤＢの内容を、インターネットを介して、或いは、可搬記憶媒体により、ユーザの端末装置１８に与える（図１０の符号１０１−１、１０１−２参照）。
【００５７】
端末装置１８においては、第１の実施の形態と同様に、まず、与えられた継承ＤＢを利用したデータ変換処理が実行される（図７および図８参照）。その後、項目の欠落や誤入力などによる誤記を含むレコードに対して、一定の修正を加えるため、変換対象となる情報（変換先情報）に対して、修正処理が実行される。
図１２ないし図１４は、修正処理をより詳細に示すフローチャートである。ここでは、まず、ユーザがあらかじめ設定した修正設定情報が読み込まれる（ステップ１２０１）。修正設定情報には、名称或いはコードのいずれかを優先的に処理するかを示す第１の優先度、修正対象が複数存在する場合に修正不能・修正なしのいずれかの設定、および、金融機関或いは店舗のいずれかを優先的に処理するかを示す第２の優先度が含まれる。
【００５８】
第１の優先度において、「名称」を優先することが設定されると、名称に基づきコードが特定され、その一方、「コード」を優先することが設定されると、コードに基づき名称が特定される。また、第２の優先度は、通常、「金融機関優先」がデフォルトとして設定されている。
第２の優先度が参照され（ステップ１２０２）、これが「金融機関優先」となっていた場合には、修正対象となる情報のレコードが読み込まれ（ステップ１２０４）、その情報において、金融機関名称およびコードがどのような態様になっているかが識別される（ステップ１２０５）。なお、第２の優先度が「店舗優先」になっていた場合（符号１２０３参照）については、後に簡単に述べる。
【００５９】
レコードの情報において、コードのみが存在し、名称が存在しない場合（符号１２０６）、名称のみが存在し、コードが存在しない場合（符号１２０７）、コードおよび名称の双方が存在する場合（符号１２０８）、並びに、コードおよび名称の双方ともが存在しない場合（符号１２０９）が起こりうる。本実施の形態においては、これらそれぞれに該当するレコードについて、以下に述べるような処理が施される。
【００６０】
図１３に示すように、コードのみが存在し、名称が存在しない場合には、最新ＤＢの情報を参照して、当該レコード中のコードが唯一なものであれば（ステップ１３０１でイエス(Yes)）、最新ＤＢにおいて当該コードと関連付けられた金融機関の名称を、上記レコードの金融機関名称として付与する（ステップ１３０２）。その一方、コードが唯一なものでなければ、当該レコードに関する更新不能情報が作られる（ステップ１３０３）。更新不能情報は、たとえば、処理の終了時にユーザに提示され、ユーザに対して更新ができないことを知らしめ、そのレコードを手動により修正するための機会を与えるために利用される。
【００６１】
また、名称のみが存在し、コードが存在しない場合にも、最新ＤＢ中の情報を参照して、レコード中の名称が唯一なものであれば（ステップ１３０４でイエス(Yes)）、最新ＤＢにおいて、当該名称と関連付けられた金融機関のコードを、上記レコードの金融機関コードとして付与する（ステップ１３０５）。
図１４に示すように、コードおよび名称の双方が存在する場合には、第１の優先度が参照されて、以下の処理が、コードを優先して考慮すべきか、或いは、名称を優先して考慮すべきかが判断される（ステップ１４０１）。名称を優先すべき場合については（符号１４０２）、後に簡単に述べる。
【００６２】
コードを優先すべき場合には、最新ＤＢを参照して、処理対象となっているレコード中のコードと同一のコードを有する、最新ＤＢ中のレコードを特定し、当該レコード中の名称が、処理対象となっているレコード中の名称と一致するか動かが判断される（ステップ１４０３）。つまり、最新ＤＢ中にある同一のコードと紐付けされた名称と、処理対象となるレコード中の名称とを突合する。双方の名称が一致した場合には（ステップ１４０３でイエス(Yes)）、図１２の処理に戻る。その一方、双方の名称が一致しない場合には（ステップ１４０３でノー(No)）、金融機関コードから取得できる業態の呼称を、その名称に付加して、再度突合を行う（ステップ１４０５）。
【００６３】
ステップ１４０５でノー(No)と判断された場合には、さらにコード突合を実行して、該当するようなレコードが最新ＤＢ中に存在するか否かが判断される（ステップ１４０６）。ステップ１４０５或いは１４０６において、イエス(Yes)と判断されれば、一致する情報が存在するため、図１２に戻る。その一方、ステップ１４０６においてノー(No)である場合には、ユーザの設定情報が参照され、修正不要とすべきか、修正不能とすべきかが判断される（ステップ１４０７）。修正不能とすべき設定がされていた場合には、後にユーザに提示するための修正不能情報が書き込まれる（ステップ１４０８）。
【００６４】
名称およびコードの双方とも存在しない場合には、ユーザの設定にしたがって、場合によって修正不能情報が作られる（ステップ１４０７、１４０８）。
このように、ステップ１２０５における識別結果に応じた処理を実行した後、いままでの処理により修正不能情報が作られていたか否かが判断される（図１２のステップ１２１２）。図１２の例では、金融機関を優先して考慮し、金融機関名称および金融機関コードの有無に基づき、必要な処理を実行した。そこで、修正不能情報が作られなかった場合（ステップ１２１２でノー(No)）、つまり、金融機関に関しては、場合によって修正が施されている場合には、店舗コードおよび名称に関する処理を施す必要がある。そこで、ステップ１２１３を介して、ステップ１２０５に戻り、店舗コードおよび名称について、同様の処理が施されることになる。
【００６５】
このようにして、あるレコードに関する修正処理が終了すると、次情報、つまり、次のレコードが読み込まれ、これが存在すれば（ステップ１２１５でイエス(Yes)）、ステップ１２０５以降の処理を繰り返す。
ユーザによる設定情報中、第２の優先度を参照して、「店舗優先」と判断された場合（符号１２０３）には、店舗コードおよび店舗名称に関して、ステップ１２０５〜ステップ１２１３とほぼ同様の処理が実行された後、金融機関コードおよび金融機関名称に関する処理が実行される。
【００６６】
また、図１３において、ユーザによる設定情報中、第１の優先度が「名称」であった場合につき、以下に簡単に説明を加える。この場合には、名称突合の代わりに、コード突合が実行され、その一方、コード突合に代えて名称突合が実行されることになる。
このように、第２の実施の形態によれば、名称或いはコードの一方が欠落している場合でも、可能であれば、一方から特定されるコード或いは名称を付与して、レコード中の欠落を補充することができる。また、名称およびレコードの双方が存在する場合についても、最新ＤＢを参照して、突合することにより、情報に誤りが含まれる恐れをより少なくすることが可能となる。
【００６７】
本発明は、以上の実施の形態に限定されることなく、特許請求の範囲に記載された発明の範囲内で、種々の変更が可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。
たとえば、前記実施の形態においては、情報管理サーバ１２において作成・更新された継承ＤＢが、端末装置１８に与えられ、端末装置１８中の継承ＤＢが、与えられた情報にしたがって更新されるように構成されている。しかしながら、このような構成に限定されるものではなく、端末装置１８からの登録により、指定された金融機関コード／名称および店舗コード／名称に変更があった場合に、その情報のみを、当該端末装置１８に通知するように構成しても良い。この場合には、端末装置１８は継承ＤＢを保持せず、登録された金融機関コード／名称および店舗コード／名称の情報の履歴のみを保持すれば足りる。
【００６８】
また、前記実施の形態において、日時処理（図９参照）が、情報管理サーバ１２にて実行され、実行結果が端末装置１８に通知されるように構成されていたが、これに限定されるものではなく、端末装置１８において、ＰＣ起動時や夜間などに、日時処理が実行され、自己の継承ＤＢ中のレコード中の有効開始日や有効終了日を参照して、「有効フラグ」を設定しても良い。
【００６９】
【発明の効果】
本発明によれば、ユーザおよび金融機関の双方が、円滑に電子商取引を含む資金決済を実現可能とするために、金融機関の情報を一元的に管理するシステムを提供することが可能となる。
【図面の簡単な説明】
【図１】 。図１は、本発明の実施の形態にかかるシステム全体の概略を示すブロックダイヤグラムである。
【図２】 図２は、本実施の形態にかかる情報管理サーバにて実行される処理を示すフローチャートである。
【図３】 図３は、本実施の形態にかかる情報管理サーバにて実行される処理を示すフローチャートである。
【図４】 図４は、本実施の形態にかかる情報管理サーバにて実行される処理を示すフローチャートである。
【図５】 図５は、本実施の形態にかかる情報管理サーバにて実行される処理を示すフローチャートである。
【図６】 図６は、本実施の形態にかかる継承ＤＢ中のレコードに含まれる項目を説明する図である。
【図７】 図７は、本実施の形態にかかる端末装置にて実行される変換処理を示すフローチャートである。
【図８】 図８は、本実施の形態にかかる端末装置にて実行される変換処理を示すフローチャートである。
【図９】 図９は、本実施の形態にかかる日時処理を示すフローチャートである。
【図１０】 図１０は、第２の実施の形態にかかるシステム全体の概略を示すブロックダイヤグラムである。
【図１１】 図１１は、第２の実施の形態にかかる最新ＤＢ中のレコードに含まれる項目を説明する図である。
【図１２】 図１２は、第２の実施の形態にかかる修正処理を示すフローチャートである。
【図１３】 図１３は、第２の実施の形態にかかる修正処理を示すフローチャートである。
【図１４】 図１４は、第２の実施の形態にかかる修正処理を示すフローチャートである。
【符号の説明】
１２ 情報管理サーバ
１６ 継承ＤＢ
１８ 端末装置
２０ 金融機関サーバ

Claims (8)

1. 種々の金融機関の金融機関コード、金融機関の名称、店舗コードおよび店舗の名称を含む情報を受理する情報受理手段と、
   前記情報に基づき、新設および業務引継を含む業務形態の変更を検出する変更検出手段と、
   金融機関コード、金融機関の名称、店舗コード、店舗の名称、および、業務引継の世代数を示す世代番号を含む複数のレコードを格納した継承データベースと、
   前記変更検出手段における検出内容にしたがって、前記継承データベース中、金融機関コードおよび店舗コードが同一の、現世代のレコードを抽出し、当該抽出されたレコードとのリンク、金融機関コード、金融機関の名称、店舗コード、店舗の名称、前記抽出されたレコード中の世代番号より新しい世代番号、および、有効開始日を含む新たなレコードを生成して前記継承データベースに登録する情報処理手段と、
   前記有効開始日を検索して、処理の実行時点で有効となっている店舗のレコードを特定する日時処理手段と、
   前記継承データベース中の所定の情報を、クライアントコンピュータに通知する情報通知手段と、を備え、
   前記情報処理手段が、前記継承データベース中の他のレコードを検索して、金融機関コードおよび店舗コードが同一であるようなレコードを見出した場合に、当該レコードおよび他のレコードに、情報の重複を示す重複フラグをセットするように構成された金融機関情報管理サーバと、
   前記金融機関情報管理サーバから通知される継承データベース中の所定の情報を受け入れ、受け入れた情報にしたがって、自身が保持する、金融機関コード、金融機関の名称、店舗コードおよび店舗の名称を含む振込情報のレコードを更新する更新手段を備え、
   前記更新手段が、自己が保持するレコードに対応する、前記継承データベース中の所定の情報に含まれるレコードに、重複フラグが存在する場合に、重複が存在することを示す外部ファイルを生成し、当該外部ファイルを出力するように構成されたクライアントコンピュータと、
   を備えたことを特徴とする金融機関情報一元管理システム。
2. さらに、前記金融機関情報管理サーバが、
   前記変更検出手段の検出内容にしたがって、前記情報処理手段が、廃止される店舗の情報に基づき、廃止される店舗のレコードに、廃止となる日を示す有効終了日を付与するとともに、廃止フラグをセットするように構成されたことを特徴とする請求項１に記載の金融機関情報一元管理システム。
3. 前記金融機関情報管理サーバの情報処理手段が、レコードの有効開始日を参照して、当該有効開始日が、前記処理を実行する日以前である場合には、当該レコードが有効であることを示す有効フラグをセットするように構成されたことを特徴とする請求項１または２に記載の金融機関情報一元管理システム。
4. 前記金融機関情報管理サーバの日時処理手段が、レコードの有効開始日が、当該処理の実行日以前である場合には、有効フラグをセットし、かつ、レコードの有効終了日が、当該処理の実行日以前である場合には、有効フラグをリセットするように構成されたことを特徴とする請求項２または３に記載の金融機関情報一元管理システム。
5. 前記金融機関情報管理サーバの情報処理手段が、レコードのリンクを参照して、前記レコードの店舗の業務を引き継ぐ他の店舗が存在する場合に、当該レコードが最新世代であることを示す最新世代フラグをリセットし、それ以外の場合に、最新世代フラグをセットするように構成されたことを特徴とする請求項１ないし４の何れか一項に記載の金融機関情報一元管理システム。
6. 金融機関コード、金融機関の名称、店舗コード、店舗の名称、および、業務引継の世代数を示す世代番号を含む複数のレコードを格納した継承データベースを備えた、金融機関情報を管理する金融機関情報管理サーバにおいて、種々の金融機関の金融機関コード、金融機関の名称、店舗コードおよび店舗の名称を含む情報を受理する情報受理ステップと、
   前記情報に基づき、新設および業務引継を含む業務形態の変更を検出する変更する変更検出ステップと、
   前記変更検出手段における検出内容にしたがって、前記継承データベース中、金融機関コードおよび店舗コードが同一の、現世代のレコードを抽出し、当該抽出されたレコードとのリンク、金融機関コード、金融機関の名称、店舗コード、店舗の名称、前記抽出されたレコード中の世代番号より新しい世代番号、および、有効開始日を含む新たなレコードを生成して前記継承データベースに登録する情報処理ステップと、
   前記継承データベース中の所定の情報を、所定のクライアントコンピュータに通知する情報通知ステップとを備え、
   前記情報処理ステップが、
   前記継承データベース中の他のレコードを検索して、金融機関コードおよび店舗コードが同一であるようなレコードを見出した場合に、当該レコードおよび他のレコードに、情報の重複を示す重複フラグをセットするステップを有し、
   金融機関コード、金融機関の名称、店舗コードおよび店舗の名称を含む振込情報のレコードを保持するクライアントコンピュータにおいて、
   前記金融機関情報管理サーバから通知される継承データベース中の所定の情報を受け入れ、受け入れた情報にしたがって、自身が保持する、金融機関コード、金融機関の名称、店舗コードおよび店舗の名称を含む振込情報のレコードを更新する更新ステップを備え、
   前記更新ステップが、自己が保持するレコードに対応する、前記継承データベース中の所定の情報に含まれるレコードに、重複フラグが存在する場合に、重複が存在することを示す外部ファイルを生成し、当該外部ファイルを出力するステップを有することを特徴とする金融機関情報一元管理方法。
7. 前記金融機関情報管理サーバにおいて、
   前記継承データベースに基づき、前記種々の金融機関に関する金融機関コード、金融機関の名称、店舗コードおよび店舗の名称のレコードを含む、金融機関の最新の情報を収容した最新データベースを生成するステップと、
   前記最新データベースを、前記クライアントコンピュータに通知するステップと、を備え、
   前記クライアントコンピュータにおいて、前記最新データベースを受理するステップと、
   前記最新データベースを参照して、前記クライアントコンピュータにて保持する前記振込情報を修正するステップと、を備えたことを特徴とする請求項６に記載の方法。
8. さらに、前記金融機関管理サーバにおいて、前記クライアントコンピュータから金融機関コード、金融機関の名称、店舗コードおよび店舗の名称を示す情報を受理し、当該クライアントコンピュータに関連付けて登録するステップと、
   前記継承データベースに新たに登録されたレコードのうち、前記登録された情報に関連するものを検出するステップと、
   検出されたレコードから抽出される所定の情報を、前記クライアントコンピュータに通知するステップとを備え、
   前記クライアントコンピュータにおいて、通知された情報により、当該クライアントコンピュータにて保持する振込情報のレコードを更新するステップを備えたことを特徴とする請求項６に記載の方法。

Images