JP2005227910A - 取引口座情報管理システム及び管理方法 - Google Patents

Abstract

【課題】 ネットバンキングにおいて、金融機関のコンピュータシステムやネットワークに過大な負荷をかけずに、口座情報の更新と取引状況の提供を迅速に行う。
【解決手段】 店舗番号及び顧客番号からなるユーザ識別情報のマスターデータ２６ａと、マスターデータ２６ａと同一の検索用データ２６ｂとを関連付けて格納するユーザ識別情報格納部２６と、取引口座の基礎情報２８と当該口座の取引レコード２９とを関連付けて格納する取引状況格納部２７と、ユーザ識別情報を変更するイベントが発生した場合にマスターデータ２６ａを変更後のユーザ識別情報に更新するマスターデータ更新部３５と、ユーザから取引状況の照会を受付けた場合に、ユーザ識別情報に基づいて検索用データ２６ｂを抽出して取引状況格納部２７から取引状況を検索してユーザに提供する取引状況照会処理部３７とを備えた。
【選択図】 図２

Description

この発明は、インターネットなどのネットワークを通じて顧客の取引状況を提供するネットバンキングにおける口座情報の管理システム及び管理方法に関する。

近年、ＡＤＳＬ（Asymmetric Digital Subscriber Line）や光ファイバー網などの通信インフラの整備や、パーソナルコンピュータ（ＰＣ）や携帯電話を初めとする通信端末の普及に伴い、インターネットを利用した種々のサービスが広く普及してきている。その一例として、金融機関が提供するネットバンキングが挙げられる。ユーザは、自宅のＰＣ等で金融機関のＷＥＢサイトにアクセスしてネットバンキングを利用することで、２４時間いつでも自己の銀行口座の残高や入出金履歴などの情報を確認したり、振込み依頼を行うことができる。また、金融機関にとっては、このネットバンキングは残高照会や振込みの処理等において支店窓口やＡＴＭで受付ける場合に比べて人的負荷やコストを格段に低減できるというメリットがある。

このようなネットバンキングにおける口座情報の管理方法として、例えば特許文献１に開示されている発明が参考となる。
特開２００２−４９７４６号公報

またネットバンキングにおいては、ユーザに過去の取引状況や過去の特定の時点における資産残高等（以下、「取引状況」と総称する）を提供するために、金融機関は各口座の所定期間の履歴情報や資産運用状況を蓄積している。この取引状況の蓄積期間は、従来は過去３ヶ月程度であったが、ユーザから「ネットバンキングにおいても前年の同時期の取引状況と比較したい」「まとまった期間で資産残高の推移を把握したい」といったニーズに応えるべく、過去１２ヶ月間程度に延長されつつある。また、近年のユーザの投資性向の高まりや保有資産の分散ニーズに伴って、ユーザが保有する口座の種別も多様化してきている。例えば、普通預金などに加えて、投資信託や外貨預金などの取引口座を保有するユーザが増えてきている。

ところで、ネットバンキングでユーザに提供される取引状況の一部の情報は、金融機関の勘定系システムから１週間、１ヶ月などの所定期間内の取引履歴や月末等の時点における資産残高のファイルを切り出して集約・加工した上で取込んでいる。そして、ユーザから取引状況の照会があった場合に、このような取引状況のファイルから該当するデータを検索して提供するようにしている。これにより、勘定系システムにアクセスしなくてもネットバンキングシステムによってユーザに取引状況を提供することができるようにし、勘定系システムにアクセスが集中してサーバに過度の負荷がかかって本来の業務処理に支障が出ることを防止している。

ここで、金融機関において店舗を統廃合したり、引越しなどのユーザの都合によって口座を移管する場合、金融機関が管理するユーザ識別情報を変更する必要がある。このユーザ識別情報は、通常、管理する店舗の識別情報と顧客情報とから構成され、このユーザ識別情報にユーザが保有する１又は２以上の取引口座の番号が関連付けられて管理されている。

このような店舗の統廃合等に伴って、前記取引状況ファイルに蓄積している過去の取引状況のユーザ識別情報も同期を取って更新する必要が生じる。このようなユーザ識別情報の更新は、通常は休日深夜などのシステムのメンテナンス時に一括して実行される。

しかし、前記のように取引状況ファイルに蓄積する情報の蓄積期間が延長され、対象口座の数も増加しているため、更新の対象となる取引状況の情報量が膨大なものとなる。例えば、ユーザ毎の取引状況ファイルは、口座の科目や取引内容等に応じて２０前後のテーブルに分割されて勘定系システムから取得して蓄積される。そのため、各テーブルに格納された全ての取引状況のレコードについて更新対象ユーザの取引であるかを判別し、対象ユーザの取引である場合にユーザ識別情報を更新する、という処理を全てのテーブルに対して繰り返し実行しなければならない。

このような取引状況の更新に要する処理時間を以下の条件で試算した。なお、複数のデータテーブル毎の顧客（契約者）数、更新対象件数等は、図６の上段に詳細に示している。
<試算条件>
・４００店舗中、５店舗で統廃合発生
・サーバの処理能力は、１０分当り２．５万件の取引状況レコードの更新可能
・各データテーブル毎に顧客１人当りのレコード数が異なる（１〜３件／人）
・１２ヵ月分蓄積された取引状況を更新
<試算結果>
更新対象件数：データテーブル１の顧客数×（テーブル１の総レコード数÷顧客数）×１２ヶ月×（５店舗÷４００店舗）＋データテーブル２の顧客数×…＝約８１３万件
更新処理時間：８１３万件÷２．５万件×１０分÷６０分＝約５４時間

このように、取引履歴の更新に２日以上も要することになり、この間、金融機関はネットバンキングシステムにおける取引状況の照会サービスを停止若しくは制限する必要がある。

この点、上記した特許文献１には、本来の店舗番号（本籍店舗番号）とは別の管理店舗番号を導入し、これらの番号と口座番号及び取引レコード（入出金項目・入出金額・実行日）とを夫々紐付けしておくことが提案されている。この特許文献１では、店舗の統廃合等に際して、本籍店舗番号と管理店舗番号とが同一の場合には両方の番号を同時に更新し、これらの番号が異なる場合には本籍店舗番号だけを更新することにしている（請求項２３、２４）。

しかし、このような手法は、勘定系システムのマスターデータを更新する場合には採用できる余地があるとしても、ネットバンキングの取引状況の更新には応用できないものである。すなわち、特許文献１では、全ての取引状況を本籍店舗番号及び管理店舗番号に関連付けて蓄積しているため（図９参照）、これらの番号を変更する場合には、上記試算と同様に、膨大な時間を要することになる。また、マスターデータだけを随時更新しておき、取引状況（取引ログテーブル）は更新しないで、ユーザから取引履歴の照会があった場合にマスターデータにアクセスして更新後の履歴情報を検索することも考えられる。しかし、この場合には、勘定系システムへのアクセスが集中して業務処理に影響が出ると共に、照会の度にマスターデータにアクセスする工程が必要となり、取引状況の提供までに時間がかかってネットバンキングの利便性を損なうおそれがある。

本発明は上記の課題を解決するためになされたもので、金融機関のコンピュータシステムやネットワークに過大な負荷をかけずに、口座情報（ユーザ識別情報）の更新と取引状況の提供とを迅速に実行できる口座情報の管理システム及び管理方法を提供することを目的とする。

上述した課題を解決するために、本発明の第１の主要な観点によれば、ユーザが金融機関に保有する取引口座の情報をネットワークを通じて提供するネットバンキングにおける当該口座情報の管理システムであって、金融機関が管理店舗の識別情報に関連付けて生成したユーザ識別情報のマスターデータと、このマスターデータと同一の検索用データとを関連付けて格納するユーザ識別情報格納手段と、前記ユーザ識別情報に関連付けられた当該ユーザの口座毎の取引状況を取得して格納する取引状況格納手段と、前記管理店舗の識別情報を変更するイベントが発生した場合に、変更後のユーザ識別情報を取得して前記ユーザ識別情報格納手段のマスターデータを更新するマスターデータ更新手段と、前記ユーザからネットワークを通じて取引状況の照会を受付けた場合に、前記ユーザ識別情報に基づいてユーザ識別情報格納手段から検索用データを抽出し、この検索用データに関連付けられた当該ユーザの口座の取引状況を前記取引状況格納手段から収集しネットワークを通じて当該ユーザに提供する取引状況出力手段とを備えたことを特徴とする口座情報管理システムが提供される。

このような構成によれば、ネットバンキングシステムは、勘定系システムで管理しているユーザ識別情報とこのユーザ識別情報に関連付けられた取引状況とを取得し、ユーザ識別情報をマスターデータとして保持する。また、このマスターデータと同一の検索用データを格納しておく。店舗の統廃合等のイベントが発生したときには、マスターデータだけを変更し、検索用データは格納時のまま保持する。そして、ユーザから過去の取引状況の照会を受付けた時に、マスターデータではなく、検索用データで取引状況を検索・収集してユーザに提供する。これにより、ユーザ識別情報の変更前に勘定系システムから取得して保存しておいた取引状況の全てを更新しなくても過去の取引状況を収集でき、更新処理を短時間で行うことが可能になる。

すなわち、勘定系システムから取得した時点では、マスターデータとして登録するユーザ識別情報と、取引状況に含まれるユーザ識別情報と、マスターデータと同一の検索用データとは常に一致する。これは、前記イベントが発生して勘定系システムの顧客情報が更新された後でも同様である。そのため、イベント発生後にネットバンキングシステムのマスターデータを更新しても、過去の特定の時点で取得した取引状況に含まれるユーザ識別情報は検索用データによって検索することが可能になる。

また、本発明は、ネットバンキングシステムで蓄積しておいた過去の取引状況を検索用データに基づいて検索・収集できるので、ユーザから照会を受付ける度に勘定系システムにアクセスする必要がなく、サーバやネットワークへの負担を軽減できると共に、取引状況を迅速にユーザに提供できる。

ここで、本明細書において取引状況とは、普通預金口座（日本円、外貨）等の流動性預金口座における入出金の実行日や項目などの取引状況や、投資信託口座や金の取引口座等の資産管理口座における月末等の特定の時点における仮想資産残高・時価評価額などの、定期的にユーザに通知する口座情報の全てを含む概念である。

本発明の一の実施形態によれば、さらに、金融機関の上位システムから所定周期で前記ユーザ識別情報のレコードを取得し、このレコードを識別する情報に関連付けて前記ユーザ識別情報格納手段に格納するユーザ識別情報取得手段を備え、前記マスターデータ更新手段は、前記イベントが発生した場合に、ユーザ識別情報格納手段から更新対象となる１又は２以上のユーザ識別情報レコードを抽出し、抽出したユーザ識別情報レコードのマスターデータを変更後のユーザ市域別情報に更新するものである。

このような構成により、更新対象のユーザ識別情報のレコードを瞬時に特定できマスターデータの更新処理時間をより短縮できる。

本発明の他の実施形態によれば、前記ユーザ識別情報取得手段は、前記取引状況格納手段が取引状況を取得するタイミングで前記ユーザ識別情報のレコードを取得するものである。これにより、取引状況とユーザ識別情報とを紐付けて管理することが容易となる。

本発明の他の実施形態によれば、前記取引状況格納手段は、金融機関の上位システムから所定周期で取引口座の科目・取引内容に応じて複数のデータテーブルに分割された取引状況を取得してこの取引状況をテーブル毎に格納するものであり、前記取引状況出力手段は、ユーザから取引状況の照会を受付けた場合に、前記検索用データに基づいて前記複数のデータテーブル毎に取引状況を収集するものである。

このような構成により、取引状況の取得・管理（検索）を効率的に行え、取引状況の照会処理を短時間で行うことができる。

本発明の他の実施形態によれば、前記マスターデータ更新手段は、金融機関の上位システムがユーザ識別情報を更新するタイミングと異なるタイミングでマスターデータの更新を行うものである。これにより、上位システムの方で更新処理について十分な検証が行われた結果に基づいてユーザ識別情報を更新することができる。

本発明の他の実施形態によれば、前記ユーザ識別情報格納手段は、前記イベントに係るユーザについてイベント発生日を取得して格納するものであり、前記取引状況格納手段は、各口座に対して入出金が実行された日を含む取引状況を取得して格納するものであり、前記取引状況出力手段は、ユーザから取引状況の照会を受付けた場合に、前記ユーザ識別情報格納手段から当該ユーザのイベント発生日を特定し、前記収集した取引状況に含まれる入出金実行日と比較することによって、各取引がイベント発生日よりも前か後かを識別可能にして当該取引状況をユーザに提供するものである。

このような構成によれば、ユーザは、ユーザ識別情報（管理店舗）の変更前後の取引状況を容易に識別することができると共に、変更前後の口座が統一して管理されていることを確認できる。

また、本発明の第２の主要な観点によれば、ユーザが金融機関に保有する取引口座の情報をネットワークを通じて提供するネットバンキングにおける当該口座情報をコンピュータによって管理する方法であって、金融機関が管理店舗の識別情報に関連付けて生成したユーザ識別情報のマスターデータを取得し、このマスターデータと同一の検索用データを生成し、これらのデータを関連付けてユーザ識別情報格納部に格納するユーザ識別情報格納工程と、前記ユーザ識別情報に関連付けられた当該ユーザの口座毎の取引状況を取得して取引状況格納部に格納する取引状況格納工程と、前記管理店舗の識別情報を変更するイベントが発生した場合に、変更後のユーザ識別情報を取得して前記ユーザ識別情報格納部のマスターデータを更新するマスターデータ更新工程と、前記ユーザからネットワークを通じて取引状況の照会を受付けた場合に、前記ユーザ識別情報に基づいてユーザ識別情報格納部から検索用データを抽出し、この検索用データに関連付けられた当該ユーザの口座の取引状況を前記取引状況格納部から収集しネットワークを通じて当該ユーザに提供する取引状況出力工程とを備えたことを特徴とする口座情報管理方法が提供される。

このような構成によれば、上記した第１の主要な観点における取引口座情報管理システムを利用して好適に実行できる取引口座情報提供方法を得ることができる。

本発明によれば、金融機関のコンピュータシステムやネットワークに過大な負荷をかけずに、ユーザ識別情報の更新と取引状況の提供を迅速に実行できる口座情報管理システム及び管理方法を得ることができる。

なお、この発明の他の特徴と顕著な効果は、次の発明を実施するための最良の形態の項の記載と添付した図面とを参照することで、より明確に理解される。

以下、この発明の実施形態を、図面を参照して説明する。まず、図１を参照して、本実施形態の全体構成について説明する。

（全体構成）

この図で符号１で示す口座情報管理システムは、金融機関２が設置・運営するネットバンキングシステム３の一部の機能を構成するシステム（サーバ）である。この口座情報管理システム１は、同じくネットバンキングシステム３を構成する電子メールサーバ４及びＷｅｂサーバ５とＬＡＮ等の専用回線で接続されている。ネットバンキングシステム３は、ＣＣ（Channel Control）サーバ６を介して、金融機関２の契約マスターファイル７と、ＭＣＩＦ（Marketing Customer Information File）サーバ８及び情報系ホスト９を備えた情報系システム１０と、顧客データベース（ＤＢ）１１及び取引口座毎の勘定情報のマスターファイル１２を備えた勘定系システム１３とに夫々接続される。後述するように、前記口座情報管理システム１は、契約マスターファイル７、情報系システム１０若しくは勘定系システム１３から必要な情報を取得する。上記したサーバ４〜６、８やマスターファイル７、１２等は何れも１又は２以上のコンピュータによって構成されている。

口座情報管理システム１は、前記Ｗｅｂサーバ５によってインターネットに接続可能な環境が構築されており、ファイアウォール１４を介して顧客（ユーザ）１５の通信端末（ＰＣや携帯電話等）１６から取引履歴等の口座情報の照会を受付けて提供したり、また、前記勘定系システム１３から取得したユーザ識別情報（店舗番号と顧客番号）や取引状況などの口座情報を管理するものである。なお、金融機関２におけるネットバンキングシステム３や情報系システム１０、勘定系システム１３等のシステム構成は従来周知であるため、以下においては、本発明の特徴に関連する事項について説明する。

（システム構成）

次に、図２を参照して、前記口座情報管理システム１の概略構成を説明する。
このシステム１は、ＣＰＵ１７、ＲＡＭ１８、入出力装置１９、通信デバイス２０が接続されたバス２１に、データ格納部２２と、プログラム格納部２３とを備えている。

データ格納部２２は、前記金融機関２に設置されるサーバ（コンピュータシステム）の記憶領域に確保された一定の領域であり、契約情報格納部２５、ユーザ識別情報格納部２６及び取引状況格納部２７を備えている。

契約情報格納部２５は、前記契約マスターファイル７から取得されたユーザ１５と金融機関２との間で締結されたネットバンキング利用契約の内容（契約期間や可能取引等）と、ネットバンキングシステムにログインする際のユーザＩＤ・パスワードからなる認証情報と、この認証情報に関連付けられたユーザ識別情報（後述する）とを格納している。

ユーザ識別情報格納部２６には、例えば図３に示すように、前記勘定系システム１３から毎月定期的（毎月最終営業日等）に送信されるユーザ識別情報のマスターデータ２６ａ、後述する検索用データ生成部３４が生成した検索用データ２６ｂ、ユーザ識別情報の取得月２６ｃ及び店舗統廃合等のイベント発生日２６ｄが１２ヵ月分蓄積されて格納されている。このユーザ識別情報は、金融機関２に１以上の口座を保有するユーザを識別するためのＩＤであり、例えば、４桁の店舗番号と８桁の顧客番号からなる。ユーザが保有する全ての口座の番号は、このユーザ識別情報に関連付けられて前記勘定系システム１３や契約マスター７によって管理されている。前記マスターデータ２６ａ、検索用データ２６ｂは、このユーザ識別情報格納部２６に格納される時点では、勘定系システム１３で管理されているユーザ識別情報と常に一致している。

取引状況格納部２７には、前記勘定系システム１３から毎月定期的（毎月最終営業日等）に送信される１ヶ月毎の取引状況が１２ヵ月分蓄積されて格納されている。また、この取引状況格納部２７は、図４に示すように、前記ユーザ識別情報２８と、口座番号２９と、当該口座の入出金項目３０ａ、支払／預り金額３０ｂ、３０ｃ及び入出金実行日３０ｄを含む取引状況３０と、取得月３１とを格納するものである。図示は省略するが、投資信託口座などの資産運用を目的とする口座については、月末等の特定の時点における仮想資産残高や理論上の資産残高等が各月の取引レコードとして格納される。ここで、取引状況に関連付けられるユーザ識別情報２８は、この取引状況格納部２７に格納される時点では前記ユーザ識別情報格納部２６に格納されたマスターデータ２６ａ、検索用データ２６ｂ及び勘定系システム１３で管理されているユーザ識別情報と常に一致している。

本実施形態では、取引状況３０は、図５に示すように、取引口座の科目・取引内容に応じて１９のテーブルに分割された状態で勘定系システム１３から取得され、これらのテーブル毎に取引状況格納部２７に蓄積・格納される。これにより、膨大な取引状況の送信や管理（検索等）の効率を向上できる。

これらの各テーブルの契約ユーザ数や履歴情報のレコード数は大きく異なる。具体的には、図６に示すように、口座種別コード＝１の「取引総合レポート‐状況サマリー‐」は、口座を保有している全ての顧客の履歴情報のサマリーであるため、毎月の取引レコード数は顧客数と同数となる。また、口座種別コード＝２の「資産借入明細‐流動性預金」は、全てのユーザが保有していると考えられ入出金も頻繁に行われるため、毎月の取引レコード数はユーザ数よりはるかに多くなる。一方、口座種別コード＝９の「資産借入明細‐金」では、金融機関との間で「金取引」の契約を締結している顧客は少数であり、頻繁に入出金が繰り返されることはないため、取引レコード数は極めて少なくなる。これらの各テーブルは、ユーザ識別情報で紐付けされている。

上記した各格納部２５〜２７はリレーショナルデータベースを構成しており、契約情報格納部２５若しくは取引状況格納部２７とユーザ識別情報格納部２６とは、ユーザ識別情報をキーにして相互にデータを参照可能とされている。

また、図２のプログラム格納部２３は、メインプログラムの他、取引状況取得部３２、ユーザ識別情報取得部３３、検索用データ生成部３４、マスターデータ更新部３５、取引状況の照会受付・認証部３６、及び取引状況照会処理部３７を備えている。これらの各構成要素３２〜３７は、前記金融機関２のサーバ（コンピュータシステム）にインストールされたコンピュータソフトウェアプログラム若しくはそのサブルーチンであり、前記ＣＰＵ１７によってＲＡＭ１８上にロードされて適宜実行されることで後述する各機能を奏するものである。

取引状況取得部３２は、毎月の所定日に前記勘定系システム１３の勘定情報マスターファイル１２にアクセスして直近の１ヶ月分の全ての口座に係る取引状況（取引レコード）を取得して取得日３１と共に前記取引状況格納部２７に格納するものである。なお、毎月の所定日に勘定系システム１３から送信されるデータを取得するようにしても良い。本実施形態では、１２ヵ月分の取引状況を格納するようにしているため、既に１２ヵ月分の取引状況が取引状況格納部２７に格納されている場合には、取得月３１が１３ヵ月前のものを削除した上で最新の取引状況を登録する。

また、この取引状況取得部３２は、ユーザ１５から取引状況の照会があった場合に取引状況照会処理部３７の指示を受けて、このユーザ１５から取得したユーザ識別情報に基いて前記ユーザ識別情報格納部２６から対応する検索用データ２６ｂを特定し、この検索用データ２６ｂに基づいて取引状況格納部２７から当該口座の取引状況を収集する機能も備えている。

ユーザ識別情報取得部３３は、毎月の所定日に金融機関２の勘定系システム１３にアクセスしてユーザ識別情報テーブルを取得し、このテーブルを識別する情報として取得月２６ｃを付して前記ユーザ識別情報格納部２６に格納するものである。このユーザ識別情報テーブルは、前記取引状況と同時に取得することが好ましい。また、取引状況と同様に、取得月２６ｃが１３ヵ月前のものを削除した上で最新のユーザ識別情報を登録する。なお、毎月の所定日に勘定系システム１３から送信されるデータを取得するようにしても良い。

検索用データ生成部３４は、前記ユーザ識別情報取得部３３が取得したユーザ識別情報テーブルについて、前記マスターデータ２６ａをコピーして検索用データ２６ｂを生成し、前記ユーザ識別情報格納部２６に取得月２６ｃと共に登録するものである。この検索用データ生成部３４が生成した検索用データ２６ｂは、生成時においてはマスターデータ２６ａ及び前記取引状況格納部２７に格納されるユーザ識別情報２８と常に一致している。

マスターデータ更新部３５は、店舗の統廃合などのユーザ識別情報を変更するイベントが発生し、前記勘定系システム１３から変更前後のユーザ識別情報を取得して更新の指示を受け付けた場合に、変更前のユーザ識別情報と前記ユーザ識別情報格納部２６の検索用データ２６ｂとを照合して更新対象の口座を特定し、更新対象の全てのユーザ識別情報テーブルのマスターデータ２６ａを変更後のユーザ識別情報に更新するものである。この更新処理は、前記勘定系システム１３によって顧客ＤＢ１１やＭＣＩＦサーバ８のユーザ識別情報が更新された後に行われる。これにより、ユーザ識別情報の更新を検証した後でネットバンキングの更新を行うことができる。

取引状況照会処理部３７は、前記照会受付・認証部３６がユーザ１５から取得したユーザ識別情報に基づいて前記ユーザ識別情報格納部２６から照会に係る口座の検索用データ２６ｂを特定し、この検索用データ２６ｂに基づいて前記取引状況格納部２７から前記複数のテーブル毎に当該口座の取引状況を抽出し、所定の表示レイアウトを生成してネットワークを通じて当該ユーザ１５に提供するものである。

本実施形態では、照会対象口座のイベント発生日２６ｄを特定し、前記取引状況に含まれる入出金実行日２９ｄがこのイベント発生日２６ｄよりも前か後かを識別可能にして当該取引状況をユーザに提供するようにしている。例えば、図６に示すように、口座情報の照会画面において、取引履歴のリスト中に、口座変更後の取引であることを示す記号４０（リスト右欄の「！」）を表示する。図示の例では、平成１５年７月１１日から２２日の間に店舗統廃合などのイベントが発生し口座情報が変更されている。これにより、ユーザ１５は、変更前後の取引を識別することができると共に、変更前後の口座が統一して管理されていることを確認できる。この図の画面は、図７の「お取引レポート」のトップ画面で各口座の取引状況のサマリーを確認したユーザが、例えば流動性預金の内訳ボタン４１を押下した場合に表示される。また、図６に示す記号４０（リスト右欄の「！」）は、前記イベントが発生した月に限って表示するのが好ましい。

（マスターデータの更新時間の試算）

ここで、図６を参照して、前記マスターデータ更新部３５がマスターデータを更新する処理件数や処理時間を試算する。試算条件は、上記従来技術で示したものと同じ条件を用いる。

この図に示す様に、各データテーブル毎の契約顧客数（Ａ）と、顧客毎の１ヵ月の取引レコード件数（Ｂ）とを乗算した１２ヶ月分の総レコード数（Ｃ）の１９テーブルの総合計は約６憶５千万レコードであり膨大な量となっている。ここで、顧客毎の１ヵ月の取引レコード件数（Ｂ）は、図示しないデータテーブル毎の全取引件数をそのデータテーブルの全顧客数（Ａ）で除算した値を概算で示している。

前記取引レコード数（Ｃ）を、試算条件である更新対象店舗比率（この試算条件では５／４００）で除算すると、更新対象レコード数（Ｄ）は約８１３万件となる。これが従来の更新処理を行う場合の対象件数である。

これに対して、本実施形態では、図６の下段に示すように、ユーザ識別情報テーブル（Ａ’）はデータテーブル毎の契約者数とは無関係に、最大値である「１：取引総合レポート‐状況サマリー‐」の顧客数（５００万）と同数となる。また、１２ヵ月の総レコード数（Ｃ’）は、毎月取得するユーザ識別情報テーブル（Ａ’）に単に１２を乗算した値となる。従って、本実施形態における取引履歴の更新対象レコード数（Ｄ’）は、１２ヵ月の総レコード数（Ｃ’）に、試算条件である更新対象店舗比率（５／４００）を乗算した７５万件となる。

この条件で、試算した場合、更新時間は以下のように算出される。
<試算結果>
更新処理時間：７５万件（Ｄ’）÷２．５万件×１０分÷６０分＝５時間

このように、従来の処理時間５４時間が１０分の１以下に短縮できることが分かる。この程度の処理時間であれば、休日の深夜などのシステムメンテナンス時に行うことも十分可能である。

（処理工程）

次に、図９〜図１１のフローチャートを参照して、本発明の処理工程をその機能と共に説明する。

（取引状況及びユーザ識別情報の登録フロー）

まず、図９を参照して、取引状況の取得及びユーザ識別情報の登録フローを説明する。

この処理では、前記取引状況取得部３２が、毎月の最終営業日後の深夜に、前記勘定系システム１３から当月の１ヵ月分の取引状況を取得する（ステップ１）。取得する取引状況は、前述したように１９個のデータテーブルに分割されている。また、同時に前記ユーザ識別情報取得部３３がユーザ識別情報テーブルを取得する（ステップＳ２）。前記した様に、この時点では、ユーザ識別情報テーブルに含まれるユーザ識別情報と取引状況が関連付けられているユーザ識別情報とは、勘定系システム１３で管理されているユーザ識別情報と一致している。

ここで、取引状況及びユーザ識別情報テーブルの取得月２６ｃ、３１に基づいて既に過去１２ヵ月分の情報が登録されていると判別される場合には（ステップＳ３のＹｅｓ）、取得月が１３ヵ月前の１ヵ月分の取引状況及びユーザ識別情報テーブルを検索して削除する（ステップ４）。そして、取得した当月分の取引状況に取得月３１を付して取引状況格納部２７に格納する（ステップＳ５）。

また、前記検索用データ生成部３４は、取得したユーザ識別情報テーブルのマスターデータ（店舗番号と顧客番号）をコピーして検索用データ２６ｂを生成して前記ユーザ識別情報取得部３３に受け渡す（ステップ６）。前記ユーザ識別情報取得部３３は、生成された検索用データ２６ｂと前記取得したユーザ識別情報とを、取得月２６ｃを付してユーザ識別情報格納部２６に格納する（ステップＳ７）。これにより、勘定系システム１３で管理されるユーザ識別情報と同一のユーザ識別情報をマスターデータ及び検索用データとして保持し、かつ、取引状況をこれらの情報に関連付けて登録することができる。なお、取引状況とユーザ識別情報とを、取引状況取得部３２若しくはユーザ識別情報取得部３３によって一括して取得・登録することもできる。この場合は、何れか一方の機能（工程）を省略できる。

（マスターデータの更新フロー）

次に、図１０を参照して前記マスターデータ更新部３５によるマスターデータの更新（洗い換え）処理フローを説明する。この更新処理は、毎月などの所定周期ではなく、月中であっても店舗の統廃合等のイベントが発生する都度行うのが好ましい。

まず、前記マスターデータ更新部３５が、勘定系システム１３からユーザ識別情報の更新情報（変更前後のユーザ識別情報とイベント発生日）を取得して更新の指示を受け付けると（ステップＳ８）、取得した更新情報から更新前のユーザ識別情報（店舗番号と顧客番号）を抽出する（ステップＳ９）。抽出したユーザ識別情報で前記ユーザ識別情報格納部２６のマスターデータ２６ａの欄を検索して更新の対象となるユーザ（ユーザ識別情報テーブル）を特定する（ステップ１０）。

次いで、前記ステップＳ８で取得した更新情報から更新後のユーザ識別情報を抽出する（ステップＳ１１）。抽出したユーザ識別情報を、前記特定した対象ユーザのマスターデータ２６ａの欄に上書きする（ステップＳ１２）。また、更新情報からイベント発生日を抽出して該当欄２６ｄに登録する（ステップＳ１３）。

通常は、更新すべきユーザ識別情報のテーブルは複数あり（最大１２ヵ月分）、また店舗の統廃合によってユーザ識別情報が変更されるユーザは複数いるため、このマスターデータ更新部３３は全ての更新対象テーブル及び全ての更新対象ユーザについて上記したステップＳ９〜Ｓ１３までの処理を実行する（ステップＳ１４）。更新処理が完了した後、前記勘定系システム１３に更新済みの通知を送信する（ステップＳ１５）。

（取引状況の照会処理フロー）

次に、図１１を参照して、取引状況の照会処理フローを参照する。

まず、前記照会受付・認証部３６が、ユーザ１５からＩＤ・パスワードの認証情報を取得して照会を受付けると（ステップＳ１６）、認証情報と前記契約情報格納部２５とを照合してユーザ認証を行う（ステップＳ１７）。

認証が肯定的である場合、前記取引状況照会処理部３７が起動して以下の各処理を行う。すなわち、取得した認証情報に関連付けられたユーザ識別情報を前記契約情報格納部２５から検索し（ステップＳ１８）、このユーザ識別情報に基いてユーザ識別情報格納部２６から当該ユーザの検索用データ２６ｂを特定する（ステップＳ１９）。また、前記取引状況取得部３２に対して、特定された検索用データ２６ｂに基づいて、取引状況格納部２７から当該ユーザの全ての口座（１９テーブル）における取引状況の収集を指示する（ステップＳ２０）。

ここで、特定された照会対象のユーザについてイベント発生日２６ｄが登録されている場合にはマスターデータ２６ａの更新が行われていると判別し（ステップＳ２１のＹｅｓ）、このイベント発生日２６ｄよりも入出金実行日２９ｄが後の取引レコードにフラグを付与する（ステップＳ２２）。この場合の取引レコードは、頻繁に入出金が実行される流動性預金口座の取引履歴に限るのが好ましい。一方、マスターデータ２６ａの更新が行われていない場合には（ステップＳ２１のＮｏ）、ステップＳ２２の工程はスキップされる。

最後に、前記取引状況にフラグが付されているかに基づいて、ユーザ識別情報の変更（店舗の統廃合等）以前の取引状況と変更後の取引状況とを識別可能に表示した取引状況表示インタフェース（図７参照）を所定のレイアウトで生成してユーザ１５の端末１６に出力する（ステップＳ２３）。

なお、この発明は上記の実施形態に限定されるものではなく、発明の要旨を変更しない範囲で種々変形可能である。

例えば、取引状況やユーザ識別情報に含まれる情報、取引状況の表示レイアウト、取引状況やユーザ識別情報のテーブルの保有期間等は上記したものに限られない。例えば、取引状況にユーザが任意に付した口座の識別情報（子供の名前等）を含めてこれを取引状況の表示インタフェースに表示することも可能である。また、取引状況等を１３か月分保有して、前年同月の情報を提供できるようにしても良い。

また、マスターデータの更新のタイミングは、毎月・毎週等の所定周期で行ったり、所定の件数（更新対象の店舗数や対象ユーザ数等）に達した時に行ったり、勘定系システムと同時期に実行するようにしても良い。

本発明の実施形態の全体構成を示す図である。 同、口座情報管理システムの概略構成を示すブロック図である。 ユーザ識別情報格納部のデータ構成を示す図である。 取引状況格納部のデータ構成を示す図である。 取引状況のデータテーブルの一例を示す図である。 データテーブル別の取引レコード数・更新対象レコード数を示す図である。 取引状況の表示インタフェース（お取引状況のサマリー）の例を示す図である。 取引状況の表示インタフェース（流動性預金口座の取引履歴）の例を示す図である。 取引状況及びユーザ識別情報の登録工程を示すフローチャートである。 マスターデータの更新（洗い替え）工程を示すフローチャートである。 取引状況の照会処理工程を示すフローチャートである。

符号の説明

１…口座情報管理システム
２…金融機関
３…ネットバンキングシステム
１１…顧客データベース（ＤＢ）
１２…勘定情報マスターファイル
１３…勘定系システム
１５…顧客（ユーザ）
１６…通信端末
２２…データ格納部
２３…プログラム格納部
２５…契約情報格納部
２６…ユーザ識別情報格納部
２６ａ…マスターデータ
２６ｂ…検索用データ
２６ｃ…ユーザ識別情報の取得月
２６ｄ…イベント発生日
２７…取引状況格納部
２８…ユーザ識別情報
２９…口座番号
３０…取引状況（取引レコード）
３１…取引状況の取得月
３２…取引状況取得部
３３…ユーザ識別情報取得部
３４…検索用データ生成部
３５…マスターデータ更新部
３６…照会受付・認証部
３７…取引状況照会処理部

Claims (12)

1. ユーザが金融機関に保有する取引口座の情報をネットワークを通じて提供するネットバンキングにおける当該口座情報の管理システムであって、
   金融機関が管理店舗の識別情報に関連付けて生成したユーザ識別情報のマスターデータと、このマスターデータと同一の検索用データとを関連付けて格納するユーザ識別情報格納手段と、
   前記ユーザ識別情報に関連付けられた当該ユーザの口座毎の取引状況を取得して格納する取引状況格納手段と、
   前記管理店舗の識別情報を変更するイベントが発生した場合に、変更後のユーザ識別情報を取得して前記ユーザ識別情報格納手段のマスターデータを更新するマスターデータ更新手段と、
   前記ユーザからネットワークを通じて取引状況の照会を受付けた場合に、前記ユーザ識別情報に基づいてユーザ識別情報格納手段から検索用データを抽出し、この検索用データに関連付けられた当該ユーザの口座の取引状況を前記取引状況格納手段から収集しネットワークを通じて当該ユーザに提供する取引状況出力手段と
   を備えたことを特徴とする口座情報管理システム。
2. 請求項１に記載のシステムにおいて、
   さらに、金融機関の上位システムから所定周期で前記ユーザ識別情報のレコードを取得し、このレコードを識別する情報に関連付けて前記ユーザ識別情報格納手段に格納するユーザ識別情報取得手段を備え、
   前記マスターデータ更新手段は、前記イベントが発生した場合に、ユーザ識別情報格納手段から更新対象となる１又は２以上のユーザ識別情報レコードを抽出し、抽出したユーザ識別情報レコードのマスターデータを変更後のユーザ識別情報に更新するものである
   ことを特徴とする口座情報管理システム。
3. 請求項２に記載のシステムにおいて、
   前記ユーザ識別情報取得手段は、前記取引状況格納手段が取引状況を取得するタイミングで前記ユーザ識別情報のレコードを取得するものである
   ことを特徴とする口座情報管理システム。
4. 請求項１に記載のシステムにおいて、
   前記取引状況格納手段は、金融機関の上位システムから所定周期で取引口座の科目・取引内容に応じて複数のデータテーブルに分割された取引状況を取得してこの取引状況をテーブル毎に格納するものであり、
   前記取引状況出力手段は、ユーザから取引状況の照会を受付けた場合に、前記検索用データに基づいて前記複数のデータテーブル毎に取引状況を収集するものである
   ことを特徴とする口座情報管理システム。
5. 請求項１に記載のシステムにおいて、
   前記マスターデータ更新手段は、金融機関の上位システムがユーザ識別情報を更新するタイミングと異なるタイミングでマスターデータの更新を行うものである
   ことを特徴とする口座情報管理システム。
6. 請求項１に記載のシステムにおいて、
   前記ユーザ識別情報格納手段は、前記イベントに係るユーザについてイベント発生日を取得して格納するものであり、
   前記取引状況格納手段は、各口座に対して入出金が実行された日を含む取引状況を取得して格納するものであり、
   前記取引状況出力手段は、ユーザから取引状況の照会を受付けた場合に、前記ユーザ識別情報格納手段から当該ユーザのイベント発生日を特定し、前記収集した取引状況に含まれる入出金実行日と比較することによって、各取引がイベント発生日よりも前か後かを識別可能にして当該取引状況をユーザに提供するものである
   ことを特徴とするシステム。
7. ユーザが金融機関に保有する取引口座の情報をネットワークを通じて提供するネットバンキングにおける当該口座情報をコンピュータによって管理する方法であって、
   金融機関が管理店舗の識別情報に関連付けて生成したユーザ識別情報のマスターデータを取得し、このマスターデータと同一の検索用データを生成し、これらのデータを関連付けてユーザ識別情報格納部に格納するユーザ識別情報格納工程と、
   前記ユーザ識別情報に関連付けられた当該ユーザの口座毎の取引状況を取得して取引状況格納部に格納する取引状況格納工程と、
   前記管理店舗の識別情報を変更するイベントが発生した場合に、変更後のユーザ識別情報を取得して前記ユーザ識別情報格納部のマスターデータを更新するマスターデータ更新工程と、
   前記ユーザからネットワークを通じて取引状況の照会を受付けた場合に、前記ユーザ識別情報に基づいてユーザ識別情報格納部から検索用データを抽出し、この検索用データに関連付けられた当該ユーザの口座の取引状況を前記取引状況格納部から収集しネットワークを通じて当該ユーザに提供する取引状況出力工程と
   を備えたことを特徴とする口座情報管理方法。
8. 請求項７に記載の方法において、
   さらに、金融機関の上位システムから所定周期で前記ユーザ識別情報のレコードを取得し、このレコードを識別する情報に関連付けて前記ユーザ識別情報格納部に格納するユーザ識別情報取得工程を備え、
   前記マスターデータ更新工程は、前記イベントが発生した場合に、ユーザ識別情報格納部から更新対象となる１又は２以上のユーザ識別情報レコードを抽出し、抽出したユーザ識別情報レコードのマスターデータを変更後のユーザ市域別情報に更新するものである
   ことを特徴とする口座情報管理方法。
9. 請求項８に記載の方法において、
   前記ユーザ識別情報取得工程は、前記取引状況格納部が取引状況を取得するタイミングで前記ユーザ識別情報のレコードを取得するものである
   ことを特徴とする口座情報管理方法。
10. 請求項７に記載の方法において、
    前記取引状況格納工程は、金融機関の上位システムから所定周期で取引口座の科目・取引内容に応じて複数のテーブルに分割された取引状況を取得してこの取引状況をテーブル毎に格納するものであり、
    前記取引状況出力工程は、ユーザから取引状況の照会を受付けた場合に、前記検索用データに基づいて前記複数のデータテーブル毎に取引状況を収集するものである
    ことを特徴とする口座情報管理方法。
11. 請求項７に記載の方法において、
    前記マスターデータ更新工程は、金融機関の上位システムがユーザ識別情報を更新するタイミングと異なるタイミングでマスターデータの更新を行うものである
    ことを特徴とする方法。
12. 請求項７に記載の方法において、
    前記ユーザ識別情報格納工程は、前記イベントに係るユーザについてイベント発生日を取得して格納するものであり、
    前記取引状況格納工程は、各口座に対して入出金が実行された日を含む取引状況を取得して格納するものであり
    前記取引状況出力工程は、ユーザから取引状況の照会を受付けた場合に、前記ユーザ識別情報格納部から当該ユーザのイベント発生日を特定し、前記収集した取引状況に含まれる入出金実行日と比較することによって、各取引がイベント発生日よりも前か後かを識別可能にして当該取引状況をユーザに提供するものである
    ことを特徴とする方法。
    

Images