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

Abstract

(57)【要約】 【課題】 ユーザおよび金融機関の双方が、円滑に電子
商取引を含む資金決済を実現できる。 【解決手段】 情報管理サーバ１２は、種々の金融機関
の金融機関コード、金融機関の名称、店舗コードおよび
店舗の名称を含む情報に基づき、新設および業務引継を
含む業務形態の変更を検出し、その検出内容にしたがっ
て、他店舗の業務を引き継ぐ場合に、前記業務が引き継
がれる他の店舗のレコードとのリンクを形成して、有効
開始日とともに、新たなレコードとして継承データベー
ス１４に登録する。継承データベース１４の情報は、端
末装置１８などに伝達され、端末装置１８に保持された
振込情報が、継承データベースの情報を参照することで
更新される。

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)）、ステップ１２０５以降の処理を繰り返
す。ユーザによる設定情報中、第２の優先度を参照し
て、「店舗優先」と判断された場合（符号１２０３）に
は、店舗コードおよび店舗名称に関して、ステップ１２
０５〜ステップ１２１３とほぼ同様の処理が実行された
後、金融機関コードおよび金融機関名称に関する処理が
実行される。

【００６６】また、図１３において、ユーザによる設定
情報中、第１の優先度が「名称」であった場合につき、
以下に簡単に説明を加える。この場合には、名称突合の
代わりに、コード突合が実行され、その一方、コード突
合に代えて名称突合が実行されることになる。このよう
に、第２の実施の形態によれば、名称或いはコードの一
方が欠落している場合でも、可能であれば、一方から特
定されるコード或いは名称を付与して、レコード中の欠
落を補充することができる。また、名称およびレコード
の双方が存在する場合についても、最新ＤＢを参照し
て、突合することにより、情報に誤りが含まれる恐れを
より少なくすることが可能となる。

【００６７】本発明は、以上の実施の形態に限定される
ことなく、特許請求の範囲に記載された発明の範囲内
で、種々の変更が可能であり、それらも本発明の範囲内
に包含されるものであることは言うまでもない。たとえ
ば、前記実施の形態においては、情報管理サーバ１２に
おいて作成・更新された継承ＤＢが、端末装置１８に与
えられ、端末装置１８中の継承ＤＢが、与えられた情報
にしたがって更新されるように構成されている。しかし
ながら、このような構成に限定されるものではなく、端
末装置１８からの登録により、指定された金融機関コー
ド／名称および店舗コード／名称に変更があった場合
に、その情報のみを、当該端末装置１８に通知するよう
に構成しても良い。この場合には、端末装置１８は継承
ＤＢを保持せず、登録された金融機関コード／名称およ
び店舗コード／名称の情報の履歴のみを保持すれば足り
る。

【００６８】また、前記実施の形態において、日時処理
（図９参照）が、情報管理サーバ１２にて実行され、実
行結果が端末装置１８に通知されるように構成されてい
たが、これに限定されるものではなく、端末装置１８に
おいて、ＰＣ起動時や夜間などに、日時処理が実行さ
れ、自己の継承ＤＢ中のレコード中の有効開始日や有効
終了日を参照して、「有効フラグ」を設定しても良い。

【００６９】

【発明の効果】本発明によれば、ユーザおよび金融機関
の双方が、円滑に電子商取引を含む資金決済を実現可能
とするために、金融機関の情報を一元的に管理するシス
テムを提供することが可能となる。

【図面の簡単な説明】

【図１】 。図１は、本発明の実施の形態にかかるシス
テム全体の概略を示すブロックダイヤグラムである。

【図２】 図２は、本実施の形態にかかる情報管理サー
バにて実行される処理を示すフローチャートである。

【図３】 図３は、本実施の形態にかかる情報管理サー
バにて実行される処理を示すフローチャートである。

【図４】 図４は、本実施の形態にかかる情報管理サー
バにて実行される処理を示すフローチャートである。

【図５】 図５は、本実施の形態にかかる情報管理サー
バにて実行される処理を示すフローチャートである。

【図６】 図６は、本実施の形態にかかる継承ＤＢ中の
レコードに含まれる項目を説明する図である。

【図７】 図７は、本実施の形態にかかる端末装置にて
実行される変換処理を示すフローチャートである。

【図８】 図８は、本実施の形態にかかる端末装置にて
実行される変換処理を示すフローチャートである。

【図９】 図９は、本実施の形態にかかる日時処理を示
すフローチャートである。

【図１０】 図１０は、第２の実施の形態にかかるシス
テム全体の概略を示すブロックダイヤグラムである。

【図１１】 図１１は、第２の実施の形態にかかる最新
ＤＢ中のレコードに含まれる項目を説明する図である。

【図１２】 図１２は、第２の実施の形態にかかる修正
処理を示すフローチャートである。

【図１３】 図１３は、第２の実施の形態にかかる修正
処理を示すフローチャートである。

【図１４】 図１４は、第２の実施の形態にかかる修正
処理を示すフローチャートである。

【符号の説明】

１２ 情報管理サーバ １６ 継承ＤＢ １８ 端末装置 ２０ 金融機関サーバ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 村上 武 東京都千代田区一番町16番 株式会社日本 総合研究所内 (72)発明者 多賀 久美 東京都千代田区一番町16番 株式会社日本 総合研究所内

Claims (12)

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