図面 (/)

技術 情報管理システム及び情報管理方法

出願人 みずほ情報総研株式会社
発明者 岩原興一河端隆宏
出願日 2012年5月30日 (8年6ヶ月経過) 出願番号 2012-123083
公開日 2013年12月12日 (7年0ヶ月経過) 公開番号 2013-250629
状態 特許登録済
技術分野 検索装置 金融・保険関連業務,支払い・決済 計算機におけるファイル管理
主要キーワード 即時反映 移行期間中 プロセス管理プログラム 移管対象 日次業務 移行作業 OFFフラグ 移管処理
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2013年12月12日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (6)

課題

逐次、更新されるデータを管理する既存システムを新しいシステム移行させるための情報管理システム及び情報管理方法を提供する。

解決手段

店頭端末12からの取引要求電文を受信した現行システム40は、取引処理を実行し、取引結果電文を送信する。この場合、次期システム60の顧客管理情報を更新させるためのデータヘッダ新設する。そして、取引結果電文を受信した次期システム60の制御部61は、顧客管理情報を更新する。ATM端末10やネット取引サーバ11において取引が行なわれた場合、現行システム40は、取引連携電文をバックエンドハブ50に送信する。そして、バックエンドハブ50から更新依頼電文を受信した次期システム60は、顧客管理情報の更新処理を実行する。また、個別移管処理において、次期システム60は、移管元移管先移行状態を特定し、この移行状態に応じて口座情報や顧客管理情報を更新する。

概要

背景

稼働中の現行システム新規ステム移行する場合、特にシステム規模が大きい場合や.取り扱うデータ量が多い場合には、移行作業の負担が大きい。例えば、現行システムとともに、新規システムとを並行して稼動させ、現行システムにおいて逐次、更新されるデータを新規システムにバッチ処理により反映させる場合もある。しかしながら、この場合には、データ更新タイムラグが生じ、円滑なデータ利用が困難になることがある。

そこで、データの移行に必要とされる処理を効率化し、営業休止日等を設けなくても、旧システムデータベースから新システムのデータベースに移行させるための技術が検討されている(例えば、特許文献1参照。)。この文献に記載された技術においては、時刻規制して行われる窓口業務自動機業務日次業務の終了毎に、業務の終了時点変更操作が不要となったデータ群のみを旧システムのデータベースから抽出して新システムのデータベースに登録する。

また、顧客業務時間を変更・停止することなく大規模データベース新旧サーバ間で移行させるためのシステムも検討されている(例えば、特許文献2参照。)。この文献に記載された技術においては、移行期間初日においては、3世代バックアップを用いることで現行運用時間中もディスクコピーによる移行中も顧客業務可能な状態とする。そして、移行期間中、顧客業務日においては、差分管理モードに変更し、移行期間中顧客業務終了までの更新データを差分コピーで移行する。

概要

逐次、更新されるデータを管理する既存システムを新しいシステムに移行させるための情報管理システム及び情報管理方法を提供する。店頭端末12からの取引要求電文を受信した現行システム40は、取引処理を実行し、取引結果電文を送信する。この場合、次期システム60の顧客管理情報を更新させるためのデータヘッダ新設する。そして、取引結果電文を受信した次期システム60の制御部61は、顧客管理情報を更新する。ATM端末10やネット取引サーバ11において取引が行なわれた場合、現行システム40は、取引連携電文をバックエンドハブ50に送信する。そして、バックエンドハブ50から更新依頼電文を受信した次期システム60は、顧客管理情報の更新処理を実行する。また、個別移管処理において、次期システム60は、移管元移管先移行状態を特定し、この移行状態に応じて口座情報や顧客管理情報を更新する。

目的

本発明は、上述した問題に鑑みてなされたものであり、その目的は、逐次、更新されるデータを管理する既存システムを新しいシステムに移行させるための情報管理システム及び情報管理方法を提供する

効果

実績

技術文献被引用数
1件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

取引装置と接続され、取引処理を行なう現行システムと、前記現行システムにおいて行なわれた取引処理についての取引ログを記録する取引ログ記憶部と、新たに取引を管理する新規ステムと、前記新規システムにおいて利用される管理対象情報更新ログを記録した更新ログ記憶部とからなる情報管理システムであって、前記現行システムが、前記取引装置から取得した取引情報に基づいて取引処理を行ない、前記取引ログ記憶部に取引ログを記録し、前記取引処理についての完了情報を前記取引装置に出力し、前記新規システムが、前記完了情報に基づいて管理対象情報を更新し、前記更新ログ記憶部に更新ログを記録し、前記取引ログ記憶部に記録された取引ログと前記更新ログ記憶部に記録された更新ログとを比較し、両者に不整合が生じている場合には、注意喚起を出力することを特徴とする情報管理システム。

請求項2

前記取引ログ記憶部に記録された取引ログが、前記更新ログ記憶部に記録された更新ログに含まれていない場合、前記現行システムから前記新規システムへの通信状況情報を取得し、前記通信状況情報において障害情報が含まれている場合には、この障害情報を前記注意喚起に含めることを特徴とする請求項1に記載の情報管理システム。

請求項3

前記取引ログ記憶部に記録された取引ログが、前記更新ログ記憶部に記録された更新ログに含まれていない場合、前記新規システムのシステム稼働状況情報を取得し、前記システム稼働状況情報において障害情報が含まれている場合には、この障害情報を前記注意喚起に含めることを特徴とする請求項1又は2に記載の情報管理システム。

請求項4

前記取引ログ記憶部に記録された取引ログに対応して、前記更新ログ記憶部に記録された更新ログにエラー情報が記録されている場合には、前記取引ログ記憶部に記録された取引ログに基づいて、前記新規システムにおける情報を更新することを特徴とする請求項1〜3のいずれか一つに記載の情報管理システム。

請求項5

前記更新ログ記憶部に記録された更新ログが、前記取引ログ記憶部に記録された取引ログに含まれていない場合には、注意喚起を出力することを特徴とする請求項1〜4のいずれか一つに記載の情報管理システム。

請求項6

前記取引処理の管理対象情報が前記新規システムにおいて利用可能となっている場合には、前記完了情報に基づいて情報を更新し、前記取引処理の管理対象情報が前記新規システムにおいて利用可能となっていない場合には、バッチ処理により管理対象情報を更新することを特徴とする請求項1〜5のいずれか一つに記載の情報管理システム。

請求項7

取引装置と接続され、取引処理を行なう現行システムと、前記現行システムにおいて行なわれた取引処理についての取引ログを記録する取引ログ記憶部と、新たに取引を管理する新規システムと、前記新規システムにおいて利用される管理対象情報の更新ログを記録した更新ログ記憶部とからなる情報管理システムを用いて、情報を管理するための方法であって、前記現行システムが、前記取引装置から取得した取引情報に基づいて取引処理を行ない、前記取引ログ記憶部に取引ログを記録し、前記取引処理についての完了情報を前記取引装置に出力し、前記新規システムが、前記完了情報に基づいて管理対象情報を更新し、前記更新ログ記憶部に更新ログを記録し、前記取引ログ記憶部に記録された取引ログと前記更新ログ記憶部に記録された更新ログとを比較し、両者に不整合が生じている場合には、注意喚起を出力することを特徴とする情報管理方法

技術分野

0001

本発明は、逐次、更新されるデータを管理する既存システムを新しいシステム移行させるための情報管理システム及び情報管理方法に関する。

背景技術

0002

稼働中の現行システム新規システムに移行する場合、特にシステム規模が大きい場合や.取り扱うデータ量が多い場合には、移行作業の負担が大きい。例えば、現行システムとともに、新規システムとを並行して稼動させ、現行システムにおいて逐次、更新されるデータを新規システムにバッチ処理により反映させる場合もある。しかしながら、この場合には、データ更新タイムラグが生じ、円滑なデータ利用が困難になることがある。

0003

そこで、データの移行に必要とされる処理を効率化し、営業休止日等を設けなくても、旧システムデータベースから新システムのデータベースに移行させるための技術が検討されている(例えば、特許文献1参照。)。この文献に記載された技術においては、時刻規制して行われる窓口業務自動機業務日次業務の終了毎に、業務の終了時点変更操作が不要となったデータ群のみを旧システムのデータベースから抽出して新システムのデータベースに登録する。

0004

また、顧客業務時間を変更・停止することなく大規模データベース新旧サーバ間で移行させるためのシステムも検討されている(例えば、特許文献2参照。)。この文献に記載された技術においては、移行期間初日においては、3世代バックアップを用いることで現行運用時間中もディスクコピーによる移行中も顧客業務可能な状態とする。そして、移行期間中、顧客業務日においては、差分管理モードに変更し、移行期間中顧客業務終了までの更新データを差分コピーで移行する。

先行技術

0005

特開2004−110319号公報(第1頁、図1
特開2009−230586号公報(第1頁、図1

発明が解決しようとする課題

0006

上述の特許文献1、2に記載された技術では、業務終了後にシステム移行データ移行を行なう場面が想定されている。しかしながら、現行システムにおいて更新されるデータを新規システムに即時反映させる必要がある場合もある。例えば、金融機関における口座情報のように、各種取引を行なうための基盤となる情報がある。このような情報の更新タイミング遅れると、取引管理や顧客対応を円滑に行なうことができなくなる。

0007

また、現行システムにおいて、複数種類取引端末が接続されていることがある。例えば、金融機関で用いられているシステムにおいては、複数のチャンネル現金自動預払機、窓口、インターネット等)において取引が行なわれている。このような現行システムから新規システムにシステム移行する場合、取引装置から現行システムに至るまでのプロセスが異なる場合もある。この場合には、各チャネルのプロセスを考慮してデータ更新を行なう必要がある。

0008

また、一度にシステム移行できない場合には、店舗毎にシステム移行していく必要があるが、この場合には、旧システムを利用する店舗や、新システムを利用する店舗等が混在することになる。そして、顧客との取引状況によっては、移行期間中に顧客対応を行なう取扱店舗が変更になることもある。このような場合にも、現行システムで管理されているデータと、新規システムで管理されているデータとの不整合を防止する必要がある。

0009

本発明は、上述した問題に鑑みてなされたものであり、その目的は、逐次、更新されるデータを管理する既存システムを新しいシステムに移行させるための情報管理システム及び情報管理方法を提供することにある。

課題を解決するための手段

0010

上記問題点を解決するために、請求項1に記載の発明は、取引装置と接続され、取引処理を行なう現行システムと、前記現行システムにおいて行なわれた取引処理についての取引ログを記録する取引ログ記憶部と、新たに取引を管理する新規システムと、前記新規システムにおいて利用される管理対象情報更新ログを記録した更新ログ記憶部とからなる情報管理システムであって、前記現行システムが、前記取引装置から取得した取引情報に基づいて取引処理を行ない、前記取引ログ記憶部に取引ログを記録し、前記取引処理についての完了情報を前記取引装置に出力し、前記新規システムが、前記完了情報に基づいて管理対象情報を更新し、前記更新ログ記憶部に更新ログを記録し、前記取引ログ記憶部に記録された取引ログと前記更新ログ記憶部に記録された更新ログとを比較し、両者に不整合が生じている場合には、注意喚起を出力することを要旨とする。

0011

請求項2に記載の発明は、請求項1に記載の情報管理システムにおいて、前記取引ログ記憶部に記録された取引ログが、前記更新ログ記憶部に記録された更新ログに含まれていない場合、前記現行システムから前記新規システムへの通信状況情報を取得し、前記通信状況情報において障害情報が含まれている場合には、この障害情報を前記注意喚起に含めることを要旨とする。

0012

請求項3に記載の発明は、請求項1又は2に記載の情報管理システムにおいて、前記取引ログ記憶部に記録された取引ログが、前記更新ログ記憶部に記録された更新ログに含まれていない場合、前記新規システムのシステム稼働状況情報を取得し、前記システム稼働状況情報において障害情報が含まれている場合には、この障害情報を前記注意喚起に含めることを要旨とする。

0013

請求項4に記載の発明は、請求項1〜3のいずれか一つに記載の情報管理システムにおいて、前記取引ログ記憶部に記録された取引ログに対応して、前記更新ログ記憶部に記録された更新ログにエラー情報が記録されている場合には、前記取引ログ記憶部に記録された取引ログに基づいて、前記新規システムにおける情報を更新することを要旨とする。

0014

請求項5に記載の発明は、請求項1〜4のいずれか一つに記載の情報管理システムにおいて、前記更新ログ記憶部に記録された更新ログが、前記取引ログ記憶部に記録された取引ログに含まれていない場合には、注意喚起を出力することを要旨とする。

0015

請求項6に記載の発明は、請求項1〜5のいずれか一つに記載の情報管理システムにおいて、前記取引処理の管理対象情報が前記新規システムにおいて利用可能となっている場合には、前記完了情報に基づいて情報を更新し、前記取引処理の管理対象情報が前記新規システムにおいて利用可能となっていない場合には、バッチ処理により管理対象情報を更新することを要旨とする。

0016

請求項7に記載の発明は、取引装置と接続され、取引処理を行なう現行システムと、前記現行システムにおいて行なわれた取引処理についての取引ログを記録する取引ログ記憶部と、新たに取引を管理する新規システムと、前記新規システムにおいて利用される管理対象情報の更新ログを記録した更新ログ記憶部とからなる情報管理システムを用いて、情報を管理するための方法であって、前記現行システムが、前記取引装置から取得した取引情報に基づいて取引処理を行ない、前記取引ログ記憶部に取引ログを記録し、前記取引処理についての完了情報を前記取引装置に出力し、前記新規システムが、前記完了情報に基づいて管理対象情報を更新し、前記更新ログ記憶部に更新ログを記録し、前記取引ログ記憶部に記録された取引ログと前記更新ログ記憶部に記録された更新ログとを比較し、両者に不整合が生じている場合には、注意喚起を出力することを要旨とする。

0017

(作用)
請求項1又は7に記載の発明によれば、現行システムが、取引装置から取得した取引情報に基づいて取引処理を行ない、取引ログ記憶部に取引ログを記録し、取引処理についての完了情報を取引装置に出力する。次に、新規システムが、完了情報に基づいて管理対象情報を更新し、更新ログ記憶部に更新ログを記録する。そして、取引ログ記憶部に記録された取引ログと更新ログ記憶部に記録された更新ログとを比較し、両者に不整合が生じている場合には、注意喚起を出力する。これにより、現行システムにおいて管理されているデータと新規システムにおいて管理されているデータとに不整合が生じた場合、注意喚起することができる。

0018

請求項2に記載の発明によれば、取引ログ記憶部に記録された取引ログが、更新ログ記憶部に記録された更新ログに含まれていない場合、現行システムから新規システムへの通信状況情報を取得する。そして、通信状況情報において障害情報が含まれている場合には、この障害情報を注意喚起に含める。これにより、現行システムから新規システムへのデータ通信における障害を不整合の原因として出力し、対応することができる。

0019

請求項3に記載の発明によれば、取引ログ記憶部に記録された取引ログが、更新ログ記憶部に記録された更新ログに含まれていない場合、新規システムのシステム稼働状況情報を取得し、システム稼働状況情報において障害情報が含まれている場合には、この障害情報を注意喚起に含める。これにより、新規システムにおいて生じた障害を不整合の原因として出力し、対応することができる。

0020

請求項4に記載の発明によれば、取引ログ記憶部に記録された取引ログに対応して、更新ログ記憶部に記録された更新ログにエラー情報が記録されている場合には、取引ログ記憶部に記録された取引ログに基づいて、新規システムにおける情報を更新する。これにより、新規システムにおいて生じたエラーを不整合の原因として出力し、対応することができる。

0021

請求項5に記載の発明によれば、更新ログ記憶部に記録された更新ログが、取引ログ記憶部に記録された取引ログに含まれていない場合には、注意喚起を出力する。これにより、現行システムにおける問題を原因として出力し、対応することができる。

0022

請求項6に記載の発明によれば、取引処理の管理対象情報が新規システムにおいて利用可能となっている場合には、完了情報に基づいて情報を更新し、取引処理の管理対象情報が新規システムにおいて利用可能となっていない場合には、バッチ処理により情報を更新する。これにより、システム移行状態に応じて、新規システムへのデータ更新を変更することができる。

発明の効果

0023

本発明によれば、逐次、更新されるデータを管理する既存システムを新しいシステムに移行させるための情報管理システム及び情報管理方法を提供することができる。

図面の簡単な説明

0024

本発明の実施形態のシステム概略図。
本発明の実施形態の処理手順の説明図。
本発明の実施形態の処理手順の説明図。
本発明の実施形態の処理手順の説明図であって、(a)は個別移管処理、(b)追い付き処理の説明図。
本発明の実施形態の処理手順の説明図。

実施例

0025

以下、本発明を具体化した一実施形態を図1図5に基づいて説明する。本実施形態では、金融機関において取引に用いる各種端末から取引情報を取得しながら、取引管理を行なうシステム(現行システム)を新しい次期システムに切り替える場合を説明する。ここでは、すべての処理を一時期に切り替えるのではなく、取引を行なう店舗を考慮しながら、順次、切り換えを行なう場合を想定する。

0026

本実施形態では、図1に示すように、ATM端末10、ネット取引サーバ11、店頭端末12等の取引装置において入力された取引についての取引処理を行なう。ATM端末10、ネット取引サーバ11は、ネットワークを介して、現行システム40に接続される。また、店頭端末12は、ネットワークを介して、締上システム20に接続される。

0027

更に、ネットワークには、障害監視システム管理者端末が接続されている(図示せず)。この障害監視システムは、各システムの障害情報(システム稼働状況情報)や、通信経路障害情報を蓄積する。これらの障害情報には、障害発生日時、障害復旧日時、障害発生場所(システム)、障害内容に関するデータを含める。また、管理者端末は、システム管理者が利用するコンピュータ端末である。

0028

そして、各取引についての取引情報を用いて、現行システム40において取引処理を実行する。更に、次期システム60において、この取引を行なう顧客についての顧客管理処理を実行する。この顧客管理処理は、現行システム40と次期システム60とをデータ連携させるために、オンライン連携ディレード連携とによって行なわれる場合を想定する。オンライン連携においては、現行システム40における取引処理に引き続き、次期システム60において連続して顧客管理処理を実行する連携処理である。ディレード連携においては、現行システム40における取引処理の取引ログに基づいて、取引処理とは別個の処理により、次期システム60において、オンライン連携に準じた顧客管理処理を実行する連携処理である。

0029

ATM端末10は、キャッシュカード現金を用いての取引を行なう現金自動預払機である。このATM端末10は、タッチパネルディスプレイを備えており、預金口座への入金や預金口座からの現金引出、指定された振込先口座への入金等を行なう場合に用いられる。

0030

ネット取引サーバ11は、インターネットを介して、ネットバンキングサービスを管理するコンピュータシステムである。ネット取引サーバ11は、ログイン認証された利用者のコンピュータ端末からの指示に基づいて、利用者口座から振込先口座への振込等を行なう場合に用いられる。

0031

店頭端末12は、金融機関店舗の窓口に設置されたコンピュータ端末である。この店頭端末12は、ディスプレイ等の出力手段や、キーボードポインティングデバイス等の入力手段を備えており、来店顧客との取引を行なう場合等に、窓口の取引担当者によって用いられる。

0032

ATM端末10、ネット取引サーバ11、店頭端末12において、取引入力が行なわれた場合、それぞれの取引装置に設けられた取引情報記憶部(図示せず)に、取引種別コード顧客コード取引内容に関する取引情報を記録する。そして、ATM端末10、ネット取引サーバ11、店頭端末12は、入力された取引情報を含めた取引要求電文を送信する。この取引要求電文には、それぞれの取引装置を特定するための識別コード(ATM端末コードや店舗コード、ネット取引サーバ等)や、取引についての取引種別コード、顧客コードや取引内容に関するデータを含める。

0033

そして、ATM端末10やネット取引サーバ11は、入力された取引についての取引要求電文を、直接、現行システム40に送信する。また、店頭端末12は、入力された取引についての取引要求電文を、締上システム20を介して、現行システム40に送信する。

0034

締上システム20は、店舗毎の取引状況を管理するコンピュータシステムである。この締上システム20は、締上管理部21、締上情報記憶部22、更新ログ記憶部23を備えている。

0035

締上管理部21は、店頭端末12から受信した取引要求電文に基づいて、取引が行なわれた店舗を特定し、この店舗の締上情報(取引状況)を締上情報記憶部22に記録する。
締上情報記憶部22には、店舗毎の取引状況を管理するための締上管理レコードが記録される。この締上管理レコードには、店舗コード、取引日時、取引電文コード、取引内容に関するデータが含まれる。

0036

店舗コードデータ領域には、取引が行なわれた店舗を特定するための識別子に関するデータが記録される。
取引日時データ領域には、取引が行なわれた年月日及び時刻に関するデータが記録される。

0037

取引電文コードデータ領域には、店頭端末12から受信した取引要求電文を特定するための識別子に関するデータが記録される。
取引内容データ領域には、この店舗で行なわれた取引の内容(取引種別取引金額等)に関するデータが記録される。そして、店舗コード、取引種別毎に、取引金額を総計することにより、この店舗の取引状況を把握することができる。

0038

更新ログ記憶部23には、締上情報についての更新ログレコードが記録される。この更新ログレコードには、店舗コード、更新日時、取引電文コードに関するデータが記録される。

0039

店舗コードデータ領域には、取引が行なわれた店舗を特定するための識別子に関するデータが記録される。
更新日時データ領域には、締上管理レコードを更新した年月日及び時刻に関するデータが記録される。
取引電文コードデータ領域には、店頭端末12から受信した取引要求電文を特定するための識別子に関するデータが記録される。

0040

現行システム40は、金融機関の顧客との取引を管理するために設けられている既存のコンピュータシステム(勘定系システム)である。この現行システム40は、取引処理部411、更新検知部412、口座元帳記憶部42、取引ログ記憶部43を備えている。

0041

取引処理部411は、取引要求電文に基づいて、口座元帳記憶部42や取引ログ記憶部43を更新する処理を実行する。この取引処理部411には、オンライン連携の対象となる取引(口座情報反映が必要な取引)を識別するための連携対象特定テーブルを保持させておく。本実施形態では、後述するように、店頭端末12から受信した取引要求電文がオンライン連携の対象となる。そして、取引処理部411は、連携対象特定テーブルに記録された取引種別の取引結果電文に対しては、次期システム60の顧客管理情報を更新させるためのデータヘッダ新設する処理を行なう。

0042

更新検知部412は、取引要求電文に基づいて行なわれた取引処理に対応して、新たに取引連携電文を生成して送信する処理を実行する。この更新検知部412は、本実施形態では、ディレード連携の対象となる取引を抽出する。本実施形態では、後述するように、ATM端末10、ネット取引サーバ11から受信した取引要求電文がディレード連携の対象となる。

0043

口座元帳記憶部42には、顧客が保有する口座についての元帳データが記録される。この元帳データは、顧客が口座を開設した場合に登録され、顧客との間で取引が行なわれた場合に更新される。この元帳データには、口座識別子取引年月日、取引内容、口座残高に関するデータが記録される。

0044

口座識別子データ領域には、各口座を特定するための識別子(店舗コード、口座種別口座番号)に関するデータが記録される。
取引年月日データ領域には、この口座を用いて取引が行なわれた年月日に関するデータが記録される。

0045

取引内容データ領域には、この口座を用いての取引内容(入金、出金等を特定するためのフラグや取引金額等)が記録される。
口座残高データ領域には、この取引を完了した時の残高金額に関するデータが記録される。

0046

取引ログ記憶部43には、取引についての取引ログデータが記録される。この取引ログデータは、現行システム40において取引処理が実行された場合に記録される。取引ログデータには、取引日時、電文コードに関するデータが記録される。

0047

取引日時データ領域には、取引処理が行なわれた年月日及び時刻に関するデータが記録される。
電文コードデータ領域には、取引処理に用いた取引要求電文を特定するための識別子に関するデータが記録される。

0048

バックエンドハブ50は、現行システム40から取得した取引連携電文に基づいて、次期システム60に送信する更新依頼電文を生成する処理を実行する。
次期システム60は、この金融機関の顧客との取引を管理するために、新たに設けられたコンピュータシステム(新規システムとしての勘定系システム)である。この次期システム60は、制御部61、システム移行判定情報記憶部62、口座情報記憶部63、口座対応テーブル記憶部64、顧客管理情報記憶部65を備えている。

0049

制御部61は、制御手段(CPU、RAM及びROM等)を備えており、後述する処理(顧客情報管理段階、ログ照合段階、リカバリ支援段階を含む処理)を行なう。このため、プロセス管理プログラムを実行することにより、顧客情報管理手段611、ログ照合手段612、リカバリ支援手段613として機能する。

0050

顧客情報管理手段611は、バックエンドハブ50から取得した更新依頼電文に基づいて、口座情報記憶部63、顧客管理情報記憶部65を更新する処理を実行する。
ログ照合手段612は、現行システム40に記録されている取引ログと、締上システム20に記録されている更新ログとを比較して、取引ログと更新ログとの不整合の有無を確認する処理を実行する。
リカバリ支援手段613は、不整合を検知した場合に、取引ログに基づいて次期システム60のデータを更新する処理を実行する。

0051

システム移行判定情報記憶部62には、各店舗におけるシステム移行状態を判定するための移行判定テーブルが記録されている。この移行判定テーブルは、システム移行を行なった場合に更新される。移行判定テーブルには、店舗コード、口座種別に対してシステム移行状況に関するデータが記録される。

0052

店舗コードデータ領域には、各店舗を特定するための識別子に関するデータが記録される。
口座種別データ領域には、口座の種類を特定するための識別子に関するデータが記録される。
システム移行状況データ領域には、この店舗における口座種別について、システム移行済かどうかを判定するためのフラグ(未済フラグ又は移行済フラグ)が記録される。

0053

口座情報記憶部63には、次期システム60において、顧客の口座を管理するための口座管理レコードが記録される。この口座管理レコードには、システム内口座番号、顧客コード、口座活動状況に関するデータが記録される。

0054

システム内口座番号データ領域には、システム専用で口座を特定するために用いられる識別子に関するデータが記録される。顧客に提供する顧客用口座識別子(移管元口座移管先口座を特定するための口座番号)は個別移管により変更されるが、システム内口座番号は一意であるため、両者を関連付けることができる。

0055

顧客コードデータ領域には、口座を保有する各顧客を特定するための識別子に関するデータが記録される。
口座活動状況データ領域には、口座を利用することができるかどうかを識別するためのフラグが記録される。口座が活動中の場合にはONフラグが記録され、口座が停止中の場合にはOFFフラグが記録される。

0056

口座対応テーブル記憶部64には、現行システム40において管理される口座番号と、次期システムにおいて管理される口座番号とについて、口座状況を管理するための口座対応管理レコードが記録されている。この口座対応管理レコードには、システム内口座番号、顧客用口座識別子、移管解約状況や移管入金状況に関するデータが記録される。

0057

システム内口座番号データ領域には、システム専用で口座を特定するために用いられる識別子に関するデータが記録される。
顧客用口座識別子データ領域には、顧客に対して提供され、顧客が保有している口座を特定するための識別子(店舗コード、口座種別、口座番号)に関するデータが記録される。

0058

移管解約状況データ領域や移管入金状況データ領域には、顧客用口座の解約や入金の要否を判定するためのフラグが記録される。各データ領域には、初期値としてOFFフラグが記録される。そして、移管元口座となる場合には、移管解約状況データ領域にONフラグ、移管入金状況データ領域にOFFフラグが記録される。一方、移管先口座となる場合には、移管解約状況データ領域にOFFフラグ、移管入金状況データ領域にONフラグが記録される。

0059

顧客管理情報記憶部65には、管理対象情報として、顧客を管理するための顧客管理レコードが記録される。顧客管理レコードは、顧客との取引を開始した場合に登録され、顧客についての情報(口座情報や属性情報)が変更される度に更新される。この顧客管理レコードには、顧客コード、口座識別子、顧客属性に関するデータが記録される。

0060

顧客コードデータ領域には、この金融機関における各顧客を特定するための識別子に関するデータが記録される。
口座識別子データ領域には、この顧客が保有している口座を特定するための識別子に関するデータが記録される。
顧客属性データ領域には、この顧客に関する情報(氏名、住所連絡先貸出の有無等)に関するデータが記録される。

0061

次に、以上のように構成されたシステムにおいて、取引管理を行なう場合についての手順を図2図5に基づいて説明する。

0062

(オンライン連携)
まず、図2を用いて、オンライン連携を説明する。このオンライン連携は、店頭端末12において取引が行なわれた場合に実行される。

0063

ここでは、まず、店頭端末12は、取引要求電文の送信処理を実行する(ステップS1−1)。具体的には、店頭端末12は、取引担当者の入力に基づいて、取引要求電文を生成し、締上システム20に送信する。

0064

次に、締上システム20は、取引要求電文の受信処理を実行する(ステップS1−2)。具体的には、締上システム20の締上管理部21は、店頭端末12から取引要求電文を受信する。そして、締上管理部21は、取引要求電文を送信した店頭端末12の店舗コードを特定し、締上管理レコードを生成する。そして、締上管理部21は、締上情報記憶部22に締上管理レコードを仮登録する。更に、締上管理部21は、更新ログを更新ログ記憶部23に記録する。

0065

次に、締上システム20は、送信先制御処理を実行する(ステップS1−3)。具体的には、締上システム20の締上管理部21は、取引要求電文を現行システム40に転送する。

0066

次に、現行システム40は、取引要求電文の受信処理を実行する(ステップS1−4)。具体的には、現行システム40の取引処理部411は、締上システム20からの取引要求電文を受信する。

0067

次に、現行システム40は、取引処理を実行する(ステップS1−5)。具体的には、現行システム40の取引処理部411は、受信した取引要求電文に基づいて、口座元帳記憶部42に記録された口座元帳データを更新する。更に、取引処理部411は、この取引要求電文についての取引ログを取引ログ記憶部43に記録する。

0068

次に、現行システム40は、取引結果電文の送信処理を実行する(ステップS1−6)。具体的には、現行システム40の取引処理部411は、取引処理についての取引結果電文を生成する。この場合、取引処理部411は、オンライン連携対象の取引要求電文に対応した取引結果電文に対して、次期システム60の顧客管理情報を更新させるためのデータヘッダを新設する。そして、取引処理部411は、この取引結果電文を締上システム20に送信する。

0069

次に、締上システム20は、取引結果電文の受信処理を実行する(ステップS1−7)。具体的には、締上システム20の締上管理部21は、現行システム40からの取引結果電文を受信する。そして、締上管理部21は、仮登録された締上管理レコードを本登録する。

0070

次に、締上システム20は、送信先の制御処理を実行する(ステップS1−8)。具体的には、締上システム20の締上管理部21は、新設されたデータヘッダに基づいて、現行システム40から受信した取引結果電文を次期システム60に転送する。

0071

次に、次期システム60の制御部61は、取引結果電文の受信処理を実行する(ステップS1−9)。具体的には、制御部61の顧客情報管理手段611は、締上システム20からの取引結果電文を受信する。

0072

次に、次期システム60の制御部61は、顧客管理情報の更新処理を実行する(ステップS1−10)。具体的には、制御部61の顧客情報管理手段611は、受信した取引結果電文に基づいて、口座情報記憶部63、口座対応テーブル記憶部64、顧客管理情報記憶部65を更新する。なお、登録されていない口座についての取引処理や、登録されていない顧客管理情報についての取引処理はエラーとなる。

0073

次に、次期システム60の制御部61は、取引結果電文の送信処理を実行する(ステップS1−11)。具体的には、制御部61の顧客情報管理手段611は、取引結果電文を締上システム20に送信する。

0074

次に、締上システム20は、取引結果電文の受信処理を実行する(ステップS1−12)。具体的には、締上システム20の締上管理部21は、次期システム60からの取引結果電文を受信する。そして、締上システム20は、更新ログ記憶部23に更新ログを記録する。ここで、次期システム60から、エラー情報を取得した場合には、このエラー情報を更新ログ記憶部23に記録する。

0075

次に、締上システム20は、送信先の制御処理を実行する(ステップS1−13)。具体的には、締上システム20の締上管理部21は、取引を行なった店頭端末12において受信できるように、取引結果電文において新設されたデータヘッダを削除する。そして、締上管理部21は、取引結果電文を店頭端末12に送信する。

0076

次に、店頭端末12は、取引結果電文の受信処理を実行する(ステップS1−14)。具体的には、店頭端末12は、締上システム20からの取引結果電文を受信する。これにより、取引担当者は取引を完了する。

0077

(ディレード連携)
次に、図3を用いて、ディレード連携を説明する。このディレード連携は、ATM端末10やネット取引サーバ11において取引が行なわれた場合に実行される。

0078

まず、ATM端末10を用いてのディレード連携を説明する。
ここでは、ATM端末10は、取引要求電文の送信処理を実行する(ステップS2−1)。具体的には、ATM端末10は、入力された取引情報に基づいて、取引要求電文を生成する。そして、ATM端末10は、現行システム40に対して、取引要求電文を送信する。

0079

次に、現行システム40は、取引要求電文の受信処理を実行する(ステップS2−2)。具体的には、現行システム40の取引処理部411は、ATM端末10からの取引要求電文を受信する。

0080

次に、現行システム40は、ステップS1−5と同様に、取引処理を実行する(ステップS2−3)。
次に、現行システム40は、取引結果電文の送信処理を実行する(ステップS2−4)。具体的には、現行システム40の取引処理部411は、ATM端末10に対して取引結果電文を送信する。

0081

そして、ATM端末10は、取引結果電文の受信処理を実行する(ステップS2−5)。この場合、ATM端末10は、取引結果電文に基づいて、取引結果をATM端末10のタッチパネルディスプレイに出力する。

0082

次に、ネット取引サーバ11を用いてのディレード連携を説明する。
ここでは、ネット取引サーバ11は、取引要求電文の送信処理を実行する(ステップS3−1)。具体的には、ネット取引サーバ11は、インターネットを介して接続されている利用者端末から、取引情報を取得する。次に、ネット取引サーバ11は、取得した取引情報に基づいて、取引要求電文を生成する。そして、ネット取引サーバ11は、現行システム40に対して、取引要求電文を送信する。

0083

次に、現行システム40は、取引要求電文の受信処理を実行する(ステップS3−2)。具体的には、現行システム40の取引処理部411は、取引要求電文を受信する。
次に、現行システム40は、ステップS1−5と同様に、取引処理を実行する(ステップS3−3)。

0084

次に、現行システム40は、取引結果電文の送信処理を実行する(ステップS3−4)。具体的には、現行システム40の取引処理部411は、ネット取引サーバ11に対して取引結果電文を送信する。

0085

そして、ネット取引サーバ11は、取引結果電文の受信処理を実行する(ステップS3−5)。具体的には、ネット取引サーバ11は、取引結果を受信する。そして、ネット取引サーバ11は、インターネットを介して接続されている利用者端末に対して、取引結果を送信する。

0086

そして、現行システム40は、取引更新の検知処理を実行する(ステップS4−1)。具体的には、現行システム40の更新検知部412は、取引処理部411において実行された取引処理に基づいて、取引更新を検知する。

0087

次に、現行システム40は、取引連携電文の送信処理を実行する(ステップS4−2)。具体的には、現行システム40の更新検知部412は、取引の更新を検知した場合には、取引連携電文を作成する。この取引連携電文には、取引対象の口座識別子、取引内容に関するデータを含める。そして、更新検知部412は、取引連携電文をバックエンドハブ50に送信する。

0088

バックエンドハブ50は、取引連携電文の受信処理を実行する(ステップS4−3)。具体的には、バックエンドハブ50は、現行システム40から取引連携電文を受信する。
次に、バックエンドハブ50は、電文変換処理を実行する(ステップS4−4)。具体的には、バックエンドハブ50は、受信した取引連携電文に基づいて、更新依頼電文を作成する。この更新依頼電文には、取引連携電文に含まれる口座識別子や取引内容に関するデータを含める。

0089

次に、バックエンドハブ50は、更新依頼電文の送信処理を実行する(ステップS4−5)。具体的には、バックエンドハブ50は、作成した更新依頼電文を締上システム20に送信する。

0090

次に、締上システム20は、更新依頼電文の受信処理を実行する(ステップS4−6)。具体的には、締上システム20の締上管理部21は、バックエンドハブ50から更新依頼電文を受信する。

0091

次に、締上システム20は、送信先の制御処理を実行する(ステップS4−7)。具体的には、締上システム20の締上管理部21は、バックエンドハブ50から受信した更新依頼電文を次期システム60に転送する。

0092

次に、次期システム60の制御部61は、更新依頼電文の受信処理を実行する(ステップS4−8)。具体的には、制御部61の顧客情報管理手段611は、締上システム20から更新依頼電文を受信する。

0093

次に、次期システム60の制御部61は、顧客管理情報の更新処理を実行する(ステップS4−9)。具体的には、制御部61の顧客情報管理手段611は、受信した更新依頼電文に基づいて、口座情報記憶部63、口座対応テーブル記憶部64を更新する。

0094

次に、次期システム60の制御部61は、更新結果電文の送信処理を実行する(ステップS4−10)。具体的には、制御部61の顧客情報管理手段611は、更新結果電文を締上システム20に送信する。

0095

次に、締上システム20は、更新結果電文の受信処理を実行する(ステップS4−11)。具体的には、締上システム20の締上管理部21は、次期システム60から更新結果電文を受信する。

0096

次に、締上システム20は、送信先の制御処理を実行する(ステップS4−12)。具体的には、締上システム20の締上管理部21は、次期システム60から受信した更新結果電文をバックエンドハブ50に転送する。

0097

次に、バックエンドハブ50は、更新結果電文の受信処理を実行する(ステップS4−13)。具体的には、バックエンドハブ50は、締上システム20から更新結果電文を受信する。

0098

(個別移管処理)
次に、図4(a)を用いて、個別移管処理を説明する。この処理は、口座を移管元店舗から移管先店舗に移管させる場合に実行される。

0099

まず、次期システム60の制御部61は、電文の受信処理を実行する(ステップS5−1)。具体的には、制御部61の顧客情報管理手段611は、オンライン連携については、現行システム40から、締上システム20を介して、取引結果電文を受信する。また、顧客情報管理手段611は、ディレード連携については、締上システム20を介して、更新依頼電文を受信する。

0100

次に、次期システム60の制御部61は、口座種別の特定処理を実行する(ステップS5−2)。具体的には、制御部61の顧客情報管理手段611は、取引結果電文、更新依頼電文に基づいて、取引が行なわれた口座種別を特定する。

0101

次に、次期システム60の制御部61は、移管元、移管先の移行状態の特定処理を実行する(ステップS5−3)。具体的には、制御部61の顧客情報管理手段611は、システム移行判定情報記憶部62から、口座種別に応じて移管元店舗、移管先店舗のシステム移行状況データを取得する。

0102

次に、次期システム60の制御部61は、更新パターンの特定処理を実行する(ステップS5−4)。具体的には、制御部61の顧客情報管理手段611は、移管元、移管先のシステム移行状況に応じて、以下の更新パターンを特定する。

0103

更新パターンにおいて、次期システム60の制御部61は、両者(移管元、移管先)はシステム移行済かどうかについての判定処理を実行する(ステップS5−5)。具体的には、制御部61の顧客情報管理手段611は、システム移行判定情報記憶部62において、移管元店舗コード及び移管先店舗コードに対して移行済フラグが記録されている場合には、移管元、移管先はシステム移行済と判定する。

0104

更新パターンにおいて、両者がシステム移行済と判定した場合(ステップS5−5において「YES」の場合)、次期システム60の制御部61は、移管解約処理を実行する(ステップS5−6)。具体的には、制御部61の顧客情報管理手段611は、移管のために、移管元口座の解約処理を行なう。この場合、制御部61の顧客情報管理手段611は、口座情報記憶部63に記録された口座管理レコードの口座活動状況データ領域にOFFフラグを記録する。更に、顧客情報管理手段611は、口座対応テーブル記憶部64に登録した口座対応管理レコードの移管解約状況データ領域にONフラグを記録する。そして、顧客情報管理手段611は、顧客管理情報記憶部65に記録された顧客管理レコードから、解約された口座識別子を削除する。

0105

更に、次期システム60の制御部61は、移管開設処理を実行する(ステップS5−7)。具体的には、制御部61の顧客情報管理手段611は、移管のための移管先口座を開設し、この口座に対して移管元口座の残高入金処理を行なう。そして、この場合、制御部61の顧客情報管理手段611は、口座情報記憶部63、口座対応テーブル記憶部64に、開設した口座についての口座管理レコード、口座対応管理レコードを登録する。そして、顧客情報管理手段611は、口座情報記憶部63に登録した口座管理レコードの口座活動状況データ領域にONフラグを記録する。更に、顧客情報管理手段611は、口座対応テーブル記憶部64に登録した口座対応管理レコードの移管入金状況データ領域にONフラグを記録する。そして、顧客情報管理手段611は、顧客管理情報記憶部65に記録された顧客管理レコードに、開設された口座識別子を追加する。

0106

移管元、移管先の少なくとも一方がシステム移行済でないため、更新パターンにおいて、両者がシステム移行済以外と判定した場合(ステップS5−5において「NO」の場合)、次期システム60の制御部61は、移管先のみシステム移行済かどうかについての判定処理を実行する(ステップS5−8)。具体的には、制御部61の顧客情報管理手段611は、システム移行判定情報記憶部62において、移管元店舗コードに対して未済フラグ、移管先店舗コードに対して移行済フラグが記録されている場合には、移管先のみシステム移行済みと判定する。

0107

更新パターンにおいて、移管先のみシステム移行済と判定した場合(ステップS5−8において「YES」の場合)、次期システム60の制御部61は、ステップS5−7と同様に、移管開設処理を実行する(ステップS5−9)。

0108

次に、次期システム60の制御部61は、追い付き処理対象登録処理を実行する(ステップS5−10)。具体的には、後述する追い付き処理において、移管のために、移管元口座の解約処理を実行する。

0109

更新パターンにおいて、移管先のみシステム移行済でないと判定した場合(ステップS5−8において「NO」の場合)、次期システム60の制御部61は、移管元のみシステム移行済かどうかについての判定処理を実行する(ステップS5−11)。具体的には、制御部61の顧客情報管理手段611は、システム移行判定情報記憶部62において、移管元店舗コードに対して移行済フラグ、移管先店舗コードに対して未済フラグが記録されている場合には、移管元のみシステム移行済みと判定する。

0110

更新パターンにおいて、移管元のみシステム移行済と判定した場合(ステップS5−11において「YES」の場合)、次期システム60の制御部61は、ステップS5−6と同様に、移管解約処理を実行する(ステップS5−12)。

0111

次に、次期システム60の制御部61は、追い付き処理対象の登録処理を実行する(ステップS5−13)。具体的には、後述する追い付き処理において、移管のために、移管先口座の開設処理、入金処理を実行する。

0112

一方、移管元のみシステム移行済でないと判定した場合(ステップS5−11において「NO」の場合)、移管元、移管先のいずれもがシステム移行済みでないこととなる。この場合には、次期システム60の制御部61は、追い付き処理対象の登録処理を実行する(ステップS5−14)。具体的には、後述する追い付き処理において、移管のために、移管元口座の解約処理、移管先口座の開設処理、入金処理を実行する。

0113

(追い付き処理)
次に、図4(b)を用いて、追い付き処理を説明する。この処理は、オンライン連携、ディレード連携において、取引内容を反映することができなかった口座について、定期的に行なわれるバッチ処理である。

0114

ここでは、まず、次期システム60の制御部61は、取引ログの取得処理を実行する(ステップS6−1)。具体的には、制御部61の顧客情報管理手段611は、現行システム40の取引ログ記憶部43から、前回の追い付き処理以降に登録された取引ログを取得する。

0115

次に、次期システム60の制御部61は、移行未済情報の抽出処理を実行する(ステップS6−2)。具体的には、制御部61の顧客情報管理手段611は、システム移行判定情報記憶部62から、システム移行されていない店舗(移行未済店舗)の店舗コードを取得する。そして、顧客情報管理手段611は、取引ログ記憶部43から取得した取引ログの中で、移行未済店舗の店舗コードに関連付けられた取引ログを抽出する。

0116

次に、次期システム60の制御部61は、移管解約についてのデータ更新処理を実行する(ステップS6−3)。具体的には、制御部61の顧客情報管理手段611は、移行未済店舗の取引ログに基づいて、移管元口座を特定する。そして、制御部61は、ステップS5−6と同様に、移管元口座についての移管解約処理を実行する。

0117

次に、次期システム60の制御部61は、移管開設についてのデータ更新処理を実行する(ステップS6−4)。具体的には、制御部61の顧客情報管理手段611は、移行未済店舗の取引ログに基づいて、移管先口座を特定する。そして、制御部61は、ステップS5−7と同様に、移管先口座についての移管開設処理を実行する。

0118

次に、次期システム60の制御部61は、移管対象口座以外のデータ更新処理を実行する(ステップS6−5)。具体的には、制御部61の顧客情報管理手段611は、移行未済店舗の取引ログに基づいて移管取引以外の口座についても、口座情報記憶部63、顧客管理情報記憶部65を更新することにより、システム移行されていない店舗についての口座情報、顧客管理情報の追い付き処理を行なう。

0119

更新確認処理
次に、図5を用いて、更新確認処理を説明する。
ここでは、まず、次期システム60の制御部61は、取引ログの取得処理を実行する(ステップS7−1)。具体的には、制御部61のログ照合手段612は、現行システム40の取引ログ記憶部43から,前回の更新確認処理以降に新たに登録された取引ログを取得する。

0120

次に、次期システム60の制御部61は、更新ログの取得処理を実行する(ステップS7−2)。具体的には、制御部61のログ照合手段612は、締上システム20の更新ログ記憶部23から、前回の更新確認処理以降に新たに登録された更新ログを取得する。

0121

次に、次期システム60の制御部61は、ログ突合によるチェック処理を実行する(ステップS7−3)。具体的には、制御部61のログ照合手段612は、取引ログと更新ログとを比較する。

0122

次に、次期システム60の制御部61は、不整合があるかどうかについての判定処理を実行する(ステップS7−4)。具体的には、制御部61のログ照合手段612は、取引ログと更新ログとに相違がある場合には不整合と判定する。

0123

取引ログと更新ログとに相違がなく、不整合でないと判定した場合(ステップS7−4において「NO」の場合)、次期システム60の制御部61は、更新確認処理を終了する。
一方、不整合と判定した場合(ステップS7−4において「YES」の場合)、次期システム60の制御部61は、取引ログのエラーかどうかについての判定処理を実行する(ステップS7−5)。具体的には、制御部61のログ照合手段612は、更新ログの内容が取引ログに含まれていない場合には、取引ログのエラーと判定する。

0124

取引ログのエラーと判定した場合(ステップS7−5において「YES」の場合)、次期システム60の制御部61は、注意喚起処理を実行する(ステップS7−6)。具体的には、制御部61のログ照合手段612は、管理者端末に対して、注意喚起メッセージを出力する。この注意喚起メッセージには、現行システム40の障害等によるエラーにより、取引ログが不足していることを含める。

0125

取引ログのエラーでないと判定した場合(ステップS7−5において「NO」の場合)、次期システム60の制御部61は、障害情報の取得処理を実行する(ステップS7−7)。具体的には、制御部61のログ照合手段612は、障害監視システムから、通信経路障害情報を取得する。更に、ログ照合手段612は、障害監視システムから、締上システム20や次期システム60の障害情報を取得する。

0126

次に、次期システム60の制御部61は、更新ログのエラー情報の取得処理を実行する(ステップS7−8)。具体的には、制御部61のログ照合手段612は、更新ログ記憶部23の更新ログにおいてエラー情報を特定する。そして、ログ照合手段612は、登録されていない口座についての取引処理や、登録されていない顧客管理情報についての取引処理等についてのエラー情報を取得する。

0127

次に、次期システム60の制御部61は、リカバリ対象かどうかについての判定処理を実行する(ステップS7−9)。具体的には、制御部61のログ照合手段612は、通信経路障害情報を取得した場合には、リカバリ対象と判定する。また、締上システム20や次期システム60の障害情報を取得した場合にも、リカバリ対象と判定する。

0128

リカバリ対象と判定した場合(ステップS7−9において「YES」の場合)、次期システム60の制御部61は、不整合原因を特定して注意喚起処理を実行する(ステップS7−10)。具体的には、制御部61のログ照合手段612は、管理者端末に対して、不整合原因を含めた注意喚起メッセージを出力する。この不整合原因としては、通信障害システム障害が含まれる。

0129

次に、次期システム60の制御部61は、取引ログに基づいてリカバリ処理を実行する(ステップS7−11)。具体的には、制御部61のログ照合手段612は、現行システム40から取得した取引ログに基づいて、顧客管理情報記憶部65に記録された顧客管理データを更新する。

0130

なお、リカバリ対象でないと判定した場合(ステップS7−9において「NO」の場合)、次期システム60の制御部61は、注意喚起処理を実行する(ステップS7−6)。この場合には、管理者端末に対して、原因が不明の不整合が生じていることを示す注意喚起メッセージを出力する。

0131

以上、本実施形態によれば、以下のような効果を得ることができる。
(1)本実施形態によれば、オンライン連携において、現行システム40は、取引結果電文の送信処理を実行する(ステップS1−6)。そして、締上システム20は、取引結果電文の受信処理(ステップS1−7)、送信先の制御処理(ステップS1−8)を実行する。そして、次期システム60の制御部61は、取引結果電文の受信処理を実行する(ステップS1−9)。これにより、取引要求電文に基づく一連の処理の中で、次期システム60にデータを反映させることができる。

0132

(2)本実施形態によれば、ディレード連携において、現行システム40は、取引更新の検知処理(ステップS4−1)、取引連携電文の送信処理(ステップS4−2)を実行する。そして、取引連携電文を受信したバックエンドハブ50は、電文変換処理(ステップS4−4)、更新依頼電文の送信処理(ステップS4−5)を実行する。これにより、取引要求電文に基づく一連の処理とは別の処理により、次期システム60にデータを反映させることができる。

0133

(3)本実施形態によれば、個別移管処理においては、次期システム60の制御部61は、移管元、移管先の移行状態の特定処理を実行する(ステップS5−3)。そして、次期システム60の制御部61は、移管元、移管先の移行状態に応じて、更新パターンの特定処理を実行する(ステップS5−4)。ここで、システム移行済みでない店舗の口座や顧客管理情報については、追い付き処理対象の登録処理を実行する(ステップS5−10、S5−13、S5−14)。これにより、システム移行中であっても、移管元店舗、移管先店舗のシステム移行状態に基づいて、移管元口座、移管先口座についての管理情報を更新することができる。

0134

(4)本実施形態の追い付き処理によれば、次期システム60の制御部61は、取引ログの取得処理(ステップS6−1)、移行未済情報の抽出処理(ステップS6−2)を実行する。そして、制御部61は、移管解約についてのデータ更新処理(ステップS6−3)、移管開設についてのデータ更新処理(ステップS6−4)、移管対象口座以外のデータ更新処理(ステップS6−5)を実行する。これにより、移行未済店舗についても、現行システム40のデータを次期システム60に反映させることができる。

0135

(5)本実施形態によれば、更新確認処理において、次期システム60の制御部61は、取引ログの取得処理(ステップS7−1)、更新ログの取得処理(ステップS7−2)、ログ突合によるチェック処理(ステップS7−3)を実行する。そして、取引ログのエラーと判定した場合(ステップS7−5において「YES」の場合)、次期システム60の制御部61は、注意喚起処理を実行する(ステップS7−6)。これにより、現行システム40において管理されているデータと、次期システム60において管理されているデータとの不整合を検出することができる。

0136

また、次期システム60の制御部61は、障害情報の取得処理(ステップS7−7)、更新ログのエラー情報の取得処理(ステップS7−8)を実行する。そして、リカバリ対象と判定した場合(ステップS7−9において「YES」の場合)、次期システム60の制御部61は、不整合原因を特定して注意喚起処理(ステップS7−10)、取引ログに基づいてリカバリ処理(ステップS7−11)を実行する。これにより、現行システム40における取引ログに基づいて、次期システム60のデータを更新することができる。

0137

なお、上記実施形態は以下のように変更してもよい。
・上記実施形態では、金融機関において取引に用いる各種端末から取引情報を取得しながら、取引管理を行なうシステム(現行システム)を新しい次期システムに切り替える場合を想定した。そして、ATM端末10、ネット取引サーバ11、店頭端末12等の取引装置において入力された取引についての取引処理を行なう。本願発明適用範囲は金融機関のシステムに限定されるものではなく、現行システムを新規システムにシステム移行させる場合に適用することができる。

0138

・上記実施形態では、顧客管理情報記憶部65に記録される顧客管理情報を、管理対象情報として用いた。管理対象情報は、これに限定されるものではない。
・上記実施形態では、現行システム40は、取引結果電文の送信処理を実行する(ステップS1−6)。この場合、取引処理部411は、取引要求電文に対応した取引結果電文に対して、次期システム60の顧客管理情報を更新させるためのデータヘッダを新設する。このデータヘッダの新設は、締上システム20において行なうようにしてもよい。この場合には、締上システム20に、オンライン連携の対象となる取引を識別するための連携対象特定テーブルを保持させておく。そして、締上システム20は、連携対象特定テーブルに記録されている取引の取引結果電文に対して、次期システム60に転送するためのデータヘッダを新設する。

0139

・上記実施形態では、オンライン連携とディレード連携とによって行なう場合を想定したが、いずれか一方のみを利用することも可能である。

0140

10…ATM端末、11…ネット取引サーバ、12…店頭端末、20…締上システム、21…締上管理部、22…締上情報記憶部、23…更新ログ記憶部、40…現行システム、411…取引処理部、412…更新検知部、42…口座元帳記憶部、43…取引ログ記憶部、50…バックエンドハブ、60…次期システム、61…制御部、611…顧客情報管理手段、612…ログ照合手段、613…リカバリ支援手段、62…システム移行判定情報記憶部、63…口座情報記憶部、64…口座対応テーブル記憶部、65…顧客管理情報記憶部。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ