JP3186720B2

JP3186720B2 - 銀行対外系業務処理装置及び振分け用プログラムを記憶した記憶媒体

Info

Publication number: JP3186720B2
Application number: JP33692398A
Authority: JP
Inventors: 仁志渡邉
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 1998-11-27
Filing date: 1998-11-27
Publication date: 2001-07-11
Anticipated expiration: 2018-11-27
Also published as: JP2000163492A

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、銀行対外系業務処
理装置に係り、特に、旧ホストから新ホストへ処理を移
行させる銀行対外系業務処理装置に関する。

【０００２】

【従来の技術】従来、銀行業務対外系移行判定（全銀ベ
ーシック手順）にてホスト装置を新しいものに更新する
には、一度に切替える必要があった。また例えば、デー
タを磁気テープなどに格納し、この磁気テープを新しい
ホスト装置に移動させていた。これに対し、特開平８−
３１４７７２号公報には、現在のホストと新しいホスト
とをファイル移行装置で接続し、オンラインでファイル
を転送する手法が開示されている。

【０００３】また、旧ホストから新ホストへ移行は、業
務別または企業別のみ行っていた。このような移行判定
プログラムは、発信系業務、各着信系業務の全６業務
を、業務または企業毎に移行していたため、着信系業務
においては、まず開局要求電文を一度新旧の両ホストへ
送信し、続いて、開始要求電文を受信時に初めて業務移
行判定を行っていた。開始要求電文以降の取引電文は、
この業務移行判定結果により、旧ホスト、または新ホス
トと送受信を行っていた。

【０００４】

【発明が解決しようとする課題】しかしながら、この従
来の移行判定機能には、次のような問題があった。第１
に、業務単位の一括移行のため、旧ホスト、及び新ホス
トに同内容の企業情報を持つ必要がある、という不都合
があった。これは、データ伝送、ＤＢ照会、金融経済は
企業単位に移行出来たが、リアルタイム照会、振込振替
は、企業別に移行が出来なかった為である。

【０００５】第２に、開局要求電文を両ホストへ送信す
るため、待ち合わせ制御が必要となる、という不都合が
あった。これは、端末からの２ｎｄ電文である開始要求
により業務が認識出来るため、１ｓｔ電文である開局要
求を振り分ける先を考慮しなければならない。この為、
両ホストからの待ち合わせにより、端末への開局回答電
文に遅延が発生してしまう。

【０００６】

【発明の目的】本発明は、係る従来例の有する不都合を
改善し、特に、全銀ベーシック手順に基づく端末から要
求を業務別および企業別、店舗別に旧ホストから新ホス
トへ段階的に移行させることのできる銀行対外系業務処
理装置を提供することを、その目的とする。

【０００７】

【課題を解決するための手段】そこで、本発明では、全
銀ベーシック手順にて端末から要求される処理のうち一
部の処理提供を終了した旧ホスト手段と、この旧ホスト
手段にて提供を終了した一部の処理が移行されると共に
当該一部の処理を前記端末に提供する新ホスト手段と、
前記端末から要求される処理が新ホスト手段又は旧ホス
ト手段のどちらで提供されるかを判定する移行判定手段
とを備えている。しかも、旧ホスト手段は、前記端末か
ら要求される処理について企業コードに対応する企業別
処理毎に新旧の移行を判定する企業別移行判定部を備え
ている。そして、移行判定手段は、前記端末から要求さ
れる処理について処理内容の業務別および店舗別の処理
毎に新旧の移行を判定する業務店舗別移行判定部と、こ
の業務店舗別移行判定部によって判定された業務店舗別
の移行判定結果と前記企業別移行判定部によって判定さ
れた企業別の移行判定結果とに基づいて前記端末から要
求される処理を新ホスト又は旧ホストへ振分ける振分け
部とを備えた、という構成を採っている。これにより前
述した目的を達成しようとするものである。

【０００８】端末から全銀ベーシック手順での処理が要
求されると、旧ホスト手段は、企業別処理毎に新旧のい
ずれかを判定する。そして、移行判定手段は、端末から
要求される処理について業務別および店舗別に新旧の移
行を判定する。移行判定手段は、この企業別の判定と、
業務、店舗別の判定に基づいて当該要求の処理を旧ホス
ト又は新ホストへ振分ける。

【０００９】

【発明の実施の形態】以下、本発明の実施の形態を図面
を参照して説明する。

【００１０】本実施形態は、銀行対外系業務（全銀ベー
シック手順）において、旧ホストから新ホストへ、業務
別、及び店別に振り分ける（移行）機能を提供するもの
である。このため、移行判定手段となるフロントエンド
プロセッサ（ＦＥＰ）を設ける。

【００１１】全銀ベーシック手順における業務には、発
信系業務、着信系業務に二分されるが、着信系業務にお
いては更に、集信系のデータ伝送（集信）、照会系のデ
ータ伝送（集信照会）、ＤＢ照会、リアルタイム照会、
振込振替、金融経済に分けられる。また、全銀ベーシッ
ク手順着信系業務では、端末からの１ｓｔ電文である開
局要求電文に、モード、企業コード等が含まれており、
端末からの２ｎｄ電文である開始要求電文にファイル名
（サービス種別のようなもの）、店番等が含まれてい
る。

【００１２】着信系業務を業務／店別に移行する際、店
番が含まれる電文は、通常、端末からの２ｎｄ電文であ
る開始要求電文であるため、店別移行をするには、開始
要求電文まで受信しなければならない。また、業務にお
いても一概に店別で振り分けることは出来ない。なぜか
というと、業務によっては、開始要求電文に店番がセッ
トされず、開局要求に含まれる企業コードにより判定し
なければならない為である。

【００１３】本実施形態では、第１に、端末からの開局
要求電文を旧ホストに送信し、旧ホスト内にて企業別移
行判定を行う。旧ホストによる判定結果は、開局回答電
文に添付しＦＥＰに送信することになる。ＦＥＰでは、
その結果を共有メモリ内に退避しておく。第２に、端末
からの開始要求電文受信時に、開始要求電文内ファイル
名より業務を判定し、その業務により先に退避した企業
別移行判定結果、または開始要求電文内の店番のどちら
かを店別移行判定情報として得る。そして最後に、事前
にＦＥＰに登録してある移行状態情報と、開局要求から
開始要求までに取得した情報を基に、業務、及び店別の
移行状態を判定し、旧ホスト、または新ホストへ開始要
求電文以降の取引電文を送受信することになり、旧ホス
トから新ホストへの業務及び店別移行を円滑に図ること
になる。本実施形態では、これらの特徴のすべてまたは
一部によって、旧ホストと新ホストの振分けを行い、こ
れにより、旧ホストから新ホストへの段階的な移行を実
現する。

【００１４】＜第１実施形態＞図１は本発明の第１の実
施形態の構成を示すブロック図である。図１に示すよう
に、本実施形態による銀行対外系業務処理装置は、全銀
ベーシック手順にて端末１から要求される処理のうち一
部の処理提供を終了した旧ホスト手段３と、この旧ホス
ト手段３にて提供を終了した一部の処理が移行されると
共に当該一部の処理を前記端末１に提供する新ホスト手
段４と、前記端末１から要求される処理が新ホスト手段
４又は旧ホスト手段３のどちらで提供されるかを判定す
る移行判定手段（ＦＥＰ）２とを備えている。

【００１５】そして、本実施形態では、旧ホスト手段３
が、前記端末１から要求される処理について企業コード
に対応する企業別処理毎に新旧の移行を判定する企業別
移行判定部１５を備えている。しかも、移行判定手段
（ＦＥＰ）２は、前記端末１から要求される処理につい
て処理内容の業務別および店舗別の処理毎に新旧の移行
を判定する業務店舗別移行判定部１４と、この業務店舗
別移行判定部１４によって判定された業務店舗別の移行
判定結果と前記企業別移行判定部１５によって判定され
た企業別の移行判定結果とに基づいて前記端末から要求
される処理を新ホスト又は旧ホストへ振分ける振分け部
１３とを備えている。

【００１６】移行処理手段であるＦＥＰ２、旧ホスト３
および新ホスト４はそれぞれコンピュータで実現するこ
とができる。このとき、各手段として機能が独立してい
るのであれば、三者を一台のコンピュータで実現しても
良いし、または４台以上の複数のコンピュータを並列に
使用しても良い。一般的には、新旧の移行処理が終了す
るとＦＥＰの移行判定手段は不要となるため、この移行
判定手段２を独立した装置とするか、または、旧ホスト
手段を実現するコンピュータの一部の機能としてもよ
い。もちろん、移行判定手段２は新ホスト手段４を実現
するコンピュータの一部の機能として実現するようにし
ても良い。

【００１７】企業別移行判定部１５は、旧ホスト手段に
予め格納されている企業マスタファイル１６に特別に定
義される新旧移行情報に基づいて企業別の移行の有無を
判定する。このため、旧ホスト手段３と新ホスト手段４
とで企業マスタファイルをそれぞれ備える必要がなく、
さらに、移行判定手段２上にて新たに企業マスタファイ
ルを設ける必要もない。

【００１８】図１に示す例では、移行判定手段２は、前
記業務店舗別移行判定部１１によって判定された業務店
舗別の移行判定結果と前記企業別移行判定部１５によっ
て判定された企業別の移行判定結果とを特定の端末１の
特定処理の移行判定結果データとして記憶する判定結果
記憶部１２を備えている。特定処理というのは、たとえ
ば、すでに要求された処理と同一の処理である。そし
て、振分け部１３は、前記端末１から要求される処理の
新旧の移行について前記判定結果記憶部１２に移行判定
結果データが格納されている場合には当該端末からの要
求について当該移行判定結果データに従って処理を振分
けを行う機能を備える。このような処理を行うことで、
すでに判定した移行結果を利用して振分け処理を高速に
行うことが可能となる。

【００１９】この図１に示した構成は、１台または複数
のコンピュータと、このコンピュータを駆動するプログ
ラムとにより実現することができる。コンピュータは、
演算を行うＣＰＵと、このＣＰＵの主記憶となるＲＡＭ
と、各種記憶部となると共に実行するプログラムファイ
ルを記憶するハードディスクなどの補助記憶装置とを備
えている。プログラムファイルは、可搬性のある記憶媒
体に格納されて当該コンピュータに供給される。この記
憶媒体は、ＣＤ―ＲＯＭやフロッピー（登録商標）ディ
スクなどデータを不揮発的に記憶しておくものであれ
ば、どのようなものでもよい。また、他のホスト装置か
ら通信回線を経由して補助記憶装置にプログラムを供給
することもできる。

【００２０】この記憶媒体には予め各種プログラムが格
納されていて、本実施形態では特に、銀行対外系業務処
理装置を使用して前記端末から要求される処理を前記旧
ホスト又は前記新ホストの一方へ振分ける振分け用プロ
グラムを備えている。この振分け用プログラムは、前記
旧ホスト手段３を動作させるための旧ホスト用プログラ
ムと、前記移行判定手段２を動作させるための移行判定
手段用プログラムとを有する。そして、旧ホスト用プロ
グラムは当該旧ホストを動作させる指令として、前記端
末から要求される処理について企業コードに対応する企
業別処理毎に新旧の移行を判定させる企業別移行判定指
令を備えている。一方、移行判定手段用プログラムは、
当該移行判定手段２を動作させる指令として、前記端末
から要求される処理について処理内容の業務別および店
舗別の処理毎に新旧の移行を判定させる業務店舗別移行
判定指令と、この業務店舗別移行判定指令に応じて判定
される業務店舗別の移行判定結果と前記企業別移行判定
指令に応じて判定される企業別の移行判定結果とに基づ
いて前記端末から要求される処理を新ホスト又は旧ホス
トへ振分ける振分けさせる振分け指令とを備えている。
この振分けプログラムが実行されると、図１示す構成の
主要部が実現される。

【００２１】図２は、開局要求電文と開始要求電文とに
より新旧の移行判定を行う例を示すブロック図である。
この例では、図１に示した移行判定手段（ＦＥＰ）２
が、前記端末１から開局要求電文が送信された時には当
該開局要求電文を前記旧ホスト３へ送信すると共に当該
開局要求電文中の企業コードに応じて前記旧ホストによ
って判定された企業別判定結果を前記判定結果記憶部１
２に格納する開局要求電文処理部２１，２２と、前記端
末１から前記開始要求電文を受信したときに当該開始要
求電文中の業務種別データと店番データとを前記業務店
舗別移行判定部１１に入力すると共に当該業務店舗別移
行判定部１１によって判定された業務店舗別の移行判定
結果を前記判定結果記憶部１２に格納する開始要求電文
処理部２３とを備えている。

【００２２】図２を参照すると、本実施形態は、エンド
ユーザである端末１と、業務、店別移行を判定するＦＥ
Ｐ２と、現行ホストである旧ホスト３、及びＦＥＰでの
移行済み業務を処理する新ホスト４とを含む。端末１
は、ＮＴＴ網を介し、全銀ベーシック手順により対外系
取引を行う。

【００２３】ＦＥＰ２は、図３、図４を元に業務、店別
移行判定を行うプログラム制御を持ち、それを判定する
ための図５に示す移行情報をあらかじめ共有メモリ（移
行状態情報記憶部１４）に記憶している。また、開局回
答電文受信時に必要条件を格納する領域、移行判定結果
を格納する領域（判定結果記憶部１２）を共有メモリ上
に備えている。

【００２４】旧ホスト３は、通常、現行ホストとして運
用されているが、新ホスト４への移行のために、開局要
求電文受信の際、電文中の企業コードにより移行済み対
象企業か否かを判定するプログラム制御を備えている。
また、移行済み取引として、開局要求レベルで取引が終
了したとしても、次取引に影響の出ない制御も併せて備
えている。

【００２５】新ホスト４は、移行期間中（全業務移行
前）において、開始要求電文より受信するシーケンスを
備えており、旧ホストからの業務移行を徐々に行える構
成を備えている。最終的には、開局要求電文からの取引
も可能となる。

【００２６】次に、図２乃至図６を参照して本実施例の
動作について詳細に説明する。

【００２７】着信系業務では、まず、端末１より着呼要
求がある。ＦＥＰ２が着呼許可を与えると、端末１は開
局要求電文を送信する。ＦＥＰ２では、開局要求電文を
受信した際、まず、図６のステップＡ１により、移行完
了であれば新ホスト４へ、未移行であれば旧ホスト３へ
電文を送信し、そして、移行中であれば処理を継続す
る。移行中の場合、処理２１（ステップＡ４）にて、前
取引で使用した移行判定用領域（共有メモリ）をクリア
し（図５移行情報以外）、旧ホスト３へ開局要求電文
を送信する。

【００２８】旧ホスト３は開局要求電文を受信すると、
処理３１にて企業別移行判定を行い、この判定結果を開
局回答電文に添付してＦＥＰ２へ送信する。ＦＥＰ２で
は、回答電文受信により処理２２を実行する。すなわ
ち、ＦＥＰ２内の共有メモリ上に、開局回答電文より
「モード」「アプリケーションＩＤ」「旧ホスト企業別
移行判定結果」を退避（ステップＡ２、Ａ６、及びＡ１
１）し、続いて、端末１へ開局回答電文を送信する。

【００２９】次に、ＦＥＰ２は、端末１より開始要求電
文を受信し、処理２３（ステップＡ５、及びＡ１２）を
行う。この処理２３が、本実施例での当移行判定処理の
メイン処理となる。まず処理２３では、開始要求電文よ
り「ファイル名」を取得し、図４より業務を認識し、開
始回答電文受信時に退避した「モード」「アプリケーシ
ョンＩＤ」、及び開始要求電文内「アクセスＩＤ」と業
務とで店番（又は退避済みの企業別移行判定結果）を取
得する。店番取得方式は、図３に示す手法による。

【００３０】こうして取得した業務、店番をキーにし、
移行情報（図５）を検索する。検索方式は以下のとおり
である。（１）該当業務の業務別移行状態を判定する。・移行完了ならば、移行済みとし新ホスト４へ（ステッ
プＡ８）・移行中ならば、次処理（２）へ・未移行ならば、未移行とし旧ホスト３へ（ステップＡ
９）（２）該当業務の全店移行状態を判定する。・全店移行完了ならば、移行済みとし新ホスト４へ（ス
テップＡ８）・上記以外ならば、店別移行中として次処理（３）へ（３）該当業務の業務別移行済情報を判定する。・先に取得した店番、または企業別移行判定結果が登録
されていれば、移行済みとし新ホスト４へ（ステップＡ
８）・登録されていなければ、未移行とし旧ホストへ（ステ
ップＡ９）上記（１），（２），（３）により判定された移行結果
を、共有メモリに退避し、ステップＡ８、及びＡ９によ
り各ホストへ開始要求電文を送信する。

【００３１】この時点で、現在行っている取引は、移行
判定済みとなり、開始回答電文以降の取引電文は、全て
移行判定結果に基づいて、旧ホスト３、又は新ホスト４
へと振り分けられることになる。仮にステップＡ１０に
処理が移るパターンとしては、通常、開始要求電文を受
信するフェーズで、開始要求以外の電文を端末１より受
信した場合で、不正電文受信扱いとしてエラー処理を行
う。

【００３２】最後に、旧ホスト３、及び新ホスト４にお
ける発信系業務の移行判定は、各ホストからの開局要求
電文受信時、当初発信元端末により移行判定を行い結果
を共有メモリに退避することにより、開局回答電文以降
の取引電文をステップＡ２、またはＡ３にて、それぞれ
のホストに振り分けることになる。

【００３３】ここで、移行期間中における着信系業務の
具体的な本実施例の動作を、ＤＢ照会を一例とし説明す
る。ＤＢ照会業務用の移行情報（図５）は、以下の通り
とする。（１）業務移行状態‥‥‥‥‥移行中（２）全店移行状態‥‥‥‥‥全店移行完了以外（３）業務別移行済店情報‥‥講習店番、代表店番

【００３４】まず、端末１より開局要求電文を受信し、
処理２１にて移行情報（図５）以外の共有メモリをクリ
ア後、旧ホストへ電文を送信する。旧ホスト３では処理
３１にて移行対象企業と判断し、開局回答電文の企業別
移行判定結果項目に代表店番をセットし、ＦＥＰ２へ開
局回答電文を送信する。ＦＥＰ２は、旧ホストより受信
した開局回答電文より、処理２２にて、モード、アプリ
ケーションＩＤ、企業別移行判定結果を共有メモリに退
避し、端末１へと開局回答電文を送信する。

【００３５】次に端末１より開始要求電文を受信し、処
理２３（ステップＡ５、及びＡ１２）を行う。処理２３
では、第１処理として、ファイル名より業務をＤＢ照会
と認識する（図４）。第２処理として、第１処理で取得
した業務と、開局回答受信時に退避したモード、アプリ
ケーションＩＤとで、図３に基づき店番を取得する。

【００３６】ここでは、ＤＢ照会ということで、開局回
答電文受信に退避した企業別移行判定結果を店番として
扱う。移行対象企業の場合、代表店番がセットされてい
る。第３処理として、移行情報（図５）と取得した業
務、店番を元に業務／店別移行判定を行うと、移行情報
内の業務別移行済店情報と取得した店番がマッチしたこ
とにより「移行済み」と判定される。最後に、移行判定
結果を共有メモリに退避し、新ホスト４（ステップＡ
８）へ電文を振り分ける。以降、取引電文は全て移行結
果に従うため、全て新ホスト４へと振り分けられること
になる。

【００３７】上述したように本実施形態によると、次の
効果を奏する。第１の効果は、従来の全銀ベーシック手
順において困難であった業務別、及び店別移行が、旧ホ
ストにおける開局要求電文受信時の企業別移行判定処理
と、ＦＥＰにおける開始要求電文受信時の業務、及び店
別移行判定処理により、容易に行えるようになったこと
が挙げられる。また、第２の効果は、旧ホスト３におい
て、既存の企業マスタファイルを利用し、企業別移行判
定を行うため、ＦＥＰでの資源削減と処理速度向上に繋
がる。

【００３８】また、図１の移行状態情報記憶部１４に格
納する移行情報の更新は、端末へのサービスを中断して
行う。銀行対外系業務処理装置に停止日がある場合に
は、その停止の際にＦＥＰと新旧ホストのプログラムお
よびデータを更新する。この更新は、まず、紙ベースの
移行情報を確定し、この移行情報に基づいてＦＥＰ２の
共通テーブルを更新する。そして、新旧ホストも同様に
プログラム等を更新する。このため、ＦＥＰおよび新旧
ホストは同一の移行情報レベルで立ち上げる。ここで、
不具合が発生した場合には、一旦システムを停止してプ
ログラムを入替えるか、または、旧ホスト側にて移行情
報を戻すことにより対応する。このように、旧ホスト側
に移行情報を戻すだけで復帰ができるため、新旧の移行
に伴う開発コストが低減される。また、２４時間運転で
は、例えば、対外回線の停止（発着呼不可）等により移
行情報の更新中は取引を不可とする。

【００３９】＜第２実施形態＞次に、企業移行情報の判
定をＦＥＰ２にて行う実施形態を説明する。この例で
は、図１に示した移行判定手段（ＦＥＰ）２が、前記端
末１から要求される業務種類別に、全店舗移行完了、移
行中又は全店舗未移行の３種類の状態を示す業務別移行
状態情報と、当該業務別移行状態が移行中である場合に
移行済又は未移行の店舗および企業の一覧情報とを記憶
した移行状態情報記憶部１４を備えている。

【００４０】さらに、ＦＥＰ２は、前記端末１から要求
される処理について前記移行状態情報記憶部１４中の業
務別移行状態情報に基づいて移行中か否かを判定すると
共に移行中の場合には当該移行状態情報記憶部中の店舗
又は企業の一覧情報に基づいて店舗又は企業別に移行状
態を判定する業務店舗企業別移行判定部１１Ａと、この
業務店舗企業別移行判定部１１Ａによって判定された業
務店舗企業別の移行判定結果に基づいて前記端末から要
求される処理を新ホスト又は旧ホストへ振分ける振分け
部１３とを備える。

【００４１】図７は第２実施形態での構成例を示す図２
に対応したブロック図である。図７に示す例では、ＦＥ
Ｐ２が、符号２４Ａで示す企業情報ファイルを有し、企
業コードの移行状態を判定する手段２４を備えている。
図８に記号情報の一例を示す。図８に示す例では、移行
の完了した企業名を登録する。

【００４２】図９は第２実施形態の処理例を示すフロー
チャートである。図９に示す例では、図６に示す処理と
異なる点を符号Ｂ１，２，Ｂ３で示す。端末１より着呼
要求があると、ＦＥＰ２が着呼許可を与えることにより
端末１は開局要求電文を送信する。ＦＥＰ２では、開局
要求電文を受信した際、まず、図９のステップＡ１によ
り、移行完了であれば新ホスト４へ、未移行であれば旧
ホスト３へ電文を送信し、移行中であれば処理を継続す
る。ここでは、移行中とし説明を続けると、処理２１
（ステップＡ４）にて、前取引で使用した移行判定用領
域（共有メモリ）をクリアし（図５移行情報以外）、
旧ホスト３へ開局要求電文を送信する。

【００４３】ＦＥＰ２では、旧ホストからの開局回答電
文により処理２２を実行する。処理の内容としては、Ｆ
ＥＰ２内共有メモリ上に、開局回答電文より「モード」
「アプリケーションＩＤ」「企業コード」を退避（ステ
ップＡ２、Ａ６、及びＢ１）後、端末１へ開局回答電文
を送信する。

【００４４】次に、ＦＥＰ２は端末１より開始要求電文
を受信し、処理２３（ステップＡ５、Ｂ２、及びＢ３）
を行う。ここが当移行判定処理のメイン処理となる。処
理２３では、開局回答電文受信時に退避した企業コード
を元に、企業情報ファイル（図８）を検索し、企業別移
行判定結果を得る（移行対象企業の場合、共有メモリに
代表店番を退避しておく。）。そして、開始要求電文よ
り「ファイル名」を取得し、図４より業務を認識後、開
始回答電文受信時に退避した「モード」「アプリケーシ
ョンＩＤ」、及び開始要求電文内「アクセスＩＤ」と業
務とで店番（又は退避済みの企業別移行判定結果）を取
得する。店番取得方式は、図３によるものとする。

【００４５】こうして取得した業務、店番をキーにし、
移行情報（図５）を検索する。検索方式は以下のとおり
である。（１）該当業務の業務別移行状態を判定する。・移行完了ならば、移行済みとし新ホスト４へ（ステッ
プＡ８）・移行中ならば、次処理（２）へ・未移行ならば、未移行とし旧ホスト３へ（ステップＡ
９）（２）該当業務の全店移行状態を判定する。・全店移行完了ならば、移行済みとし新ホスト４へ（ス
テップＡ８）・上記以外ならば、店別移行中として次処理（３）へ（３）該当業務の業務別移行済情報を判定する。・先に取得した店番、または企業別移行判定結果が登録
されていれば、移行済みとし新ホスト４へ（ステップＡ
８）・登録されていなければ、未移行とし旧ホストへ（ステ
ップＡ９）

【００４６】上記（１），（２），（３）により判定さ
れた移行結果を、共有メモリに退避し、ステップＡ８、
及びＡ９により各ホストへ開始要求電文を送信する。

【００４７】この時点で、現在行っている取引は、移行
判定済みとなり、開始回答電文以降の取引電文は、全て
移行判定結果に基づいて、旧ホスト３、又は新ホスト４
へと振り分けられることになる。仮にステップＡ１０に
処理が移るパターンとしては、通常、開始要求電文を受
信するフェーズで、開始要求以外の電文を端末１より受
信した場合で、不正電文受信扱いとしてエラー処理を行
うことになる。

【００４８】最後に、旧ホスト３、及び新ホスト４にお
ける発信系業務の移行判定は、各ホストからの開局要求
電文受信時、当初発信元端末により移行判定を行い結果
を共有メモリに退避することにより、開局回答電文以降
の取引電文をステップＡ２、またはＡ３にて、それぞれ
のホストに振り分けることになる。ここで、移行期間中
における着信系業務の具体的な本実施例の動作を、ＤＢ
照会を一例とし説明する。

【００４９】ＤＢ照会業務用の移行情報（図５）は、以
下の通りとする。（１）業務移行状態‥‥‥‥‥移行中（２）全店移行状態‥‥‥‥‥全店移行完了以外（３）業務別移行済店情報‥‥講習店番、代表店番

【００５０】まず、端末１より開局要求電文を受信し、
処理２１にて移行情報（図５）以外の共有メモリをクリ
ア後、旧ホストへ電文を送信、開局回答電文を旧ホスト
３より受信する。ＦＥＰ２では、旧ホストより受信した
開局回答電文より、処理２２にて、モード、アプリケー
ションＩＤ、企業コードを共有メモリに退避後（ステッ
プＢ１）、端末１へと開局回答電文を送信する。

【００５１】その後、端末１より開始要求電文を受信
し、処理２３（ステップＡ５、Ｂ２）、及び処理２４
（ステップＢ３）を行う。処理２３では、開局回答電文
受信時に退避した企業コードを元に、企業別移行判定処
理（企業情報ファイルを検索し、移行対象企業ならば、
共有メモリに代表店番を退避。）を行う。第２実施形態
では、移行対象企業として、代表店番を退避する。次
に、処理２４（ステップＢ３）の第１処理として、ファ
イル名より業務をＤＢ照会と認識する（図４）。第２処
理として、第１処理で取得した業務と、開局回答受信時
に退避したモード、アプリケーションＩＤとで、図３に
基づき店番を取得する。ここでは、ＤＢ照会ということ
で、企業別移行判定結果を店番として扱う。第３処理と
して、移行情報（図５）と取得した業務、店番を元に業
務／店別移行判定を行うと、移行情報（図５）内の業務
別移行済店情報と取得した店番がマッチしたことにより
「移行済み」と判定される。最後に、移行判定結果を共
有メモリに退避し、新ホスト４（ステップＡ８）へ電文
を振り分ける。以降、取引電文は全て移行結果に従うた
め、全て新ホスト４へと振り分けられることになる。

【００５２】

【発明の効果】本発明は以上のように構成され機能する
ので、これによると、端末から全銀ベーシック手順での
処理が要求されると、旧ホスト手段は、企業別処理毎に
新旧のいずれかを判定し、移行判定手段が、端末から要
求される処理について業務別および店舗別に新旧の移行
を判定すると共に、この企業別の判定と、業務、店舗別
の判定に基づいて当該要求の処理を旧ホスト又は新ホス
トへ振分けるため、業務別かつ各店舗、企業毎に旧ホス
トから新ホストへ処理を移すことができ、すると、段階
的に旧ホストから新ホストへ業務を移行することによ
り、移行した新ホストでの処理に不具合が発生しても他
の業務への影響を少なくすることができ、このため、旧
ホストを新ホストへ移行させる際のリスクを軽減するこ
とができ、また、旧ホストから新ホストへ一度へ入替え
るのではなく、段階的に業務を移すことが可能となる
と、開発作業を段階的に行うことができ、すると、開発
後の試験の日程の確保などが容易となり、さらに、本発
明では、企業別処理の判定を旧ホストで行うため、移行
判定のために新たに企業データの一式を設けることな
く、既存のデータを利用して移行判定を行うことがで
き、このため、移行判定手段での処理負担を軽減するこ
とができ、従って、移行判定処理を高速に行うことがで
きるという従来にない優れた銀行対外系業務処理装置を
提供することができる。

【図面の簡単な説明】

【図１】本発明の第一の実施形態の構成を示すブロック
図である。

【図２】図１に示した実施形態の具体的構成例を示すブ
ロック図である。

【図３】図２に示した構成で使用する端末から要求され
る業務内容と処理モード等との関係を示す説明図であ
る。

【図４】図２に示した構成で使用する電文のファイル名
と業務の対応例を示す説明図である。

【図５】図２に示した構成で使用する移行情報の一例を
示す説明図である。

【図６】第１実施形態の動作例を示すフローチャートで
ある。

【図７】第２実施形態の具体的構成例を示すブロック図
である。

【図８】図７に示す構成で使用する企業情報の一例を示
す説明図である。

【図９】図７に示した第２実施形態の動作例を示すフロ
ーチャートである。

【符号の説明】

１端末２移行判定手段（ＦＥＰ）１１業務店舗別移行判定部１２判定結果記憶部１３振分け部１４移行状態情報記憶部１５企業別移行判定部

Claims

(57)【特許請求の範囲】

【請求項１】全銀ベーシック手順にて端末から要求さ
れる処理のうち一部の処理提供を終了した旧ホスト手段
と、この旧ホスト手段にて提供を終了した一部の処理が
移行されると共に当該一部の処理を前記端末に提供する
新ホスト手段と、前記端末から要求される処理が新ホス
ト手段又は旧ホスト手段のどちらで提供されるかを判定
する移行判定手段とを備え、前記旧ホスト手段は、前記端末から要求される処理につ
いて企業コードに対応する企業別処理毎に新旧の移行を
判定する企業別移行判定部を備え、前記移行判定手段は、前記端末から要求される処理につ
いて処理内容の業務別および店舗別の処理毎に新旧の移
行を判定する業務店舗別移行判定部と、この業務店舗別
移行判定部によって判定された業務店舗別の移行判定結
果と前記企業別移行判定部によって判定された企業別の
移行判定結果とに基づいて前記端末から要求される処理
を新ホスト又は旧ホストへ振分ける振分け部とを備えた
ことを特徴とする銀行対外系業務処理装置。
【請求項２】前記移行判定手段は、前記業務店舗別移
行判定部によって判定された業務店舗別の移行判定結果
と前記企業別移行判定部によって判定された企業別の移
行判定結果とを特定の端末の特定処理の移行判定結果デ
ータとして記憶する判定結果記憶部を備えると共に、前記振分け部は、前記端末から要求される処理の新旧の
移行について前記判定結果記憶部に移行判定結果データ
が格納されている場合には当該端末からの要求について
当該移行判定結果データに従って処理を振分けを行う機
能を備えたことを特徴とする請求項１記載の銀行対外系
業務処理装置。
【請求項３】前記移行判定手段は、前記端末から開局
要求電文が送信された時には当該開局要求電文を前記旧
ホストへ送信すると共に当該開局要求電文中の企業コー
ドに応じて前記旧ホストによって判定された企業別判定
結果を前記判定結果記憶部に格納する開局要求電文処理
部と、前記端末から開始要求電文を受信したときに当該
開始要求電文中の業務種別データと店番データとを前記
業務店舗別移行判定部に入力すると共に当該業務店舗別
移行判定部によって判定された業務店舗別の移行判定結
果を前記判定結果記憶部に格納する開始要求電文処理部
とを備えたことを特徴とする請求項２記載の銀行対外系
業務処理装置。
【請求項４】前記移行判定手段は、前記端末から要求
される業務種類別に、全店舗移行完了、移行中又は全店
舗未移行の３種類の状態を示す業務別移行状態情報と、
当該業務別移行状態が移行中である場合に移行済又は未
移行の店舗の一覧情報とを記憶した移行状態情報記憶部
を備え、前記業務店舗別移行判定部は、前記端末から要求される
処理について前記移行状態情報記憶部中の業務別移行状
態情報に基づいて移行中か否かを判定すると共に移行中
の場合には当該移行状態情報記憶部中の店舗の一覧情報
に基づいて店舗別に移行状態を判定する機能を備えたこ
とを特徴とする請求項１記載の銀行対外系業務処理装
置。
【請求項５】全銀ベーシック手順にて端末から要求さ
れる処理のうち一部の処理提供を終了した旧ホスト手段
と、この旧ホスト手段にて提供を終了した一部の処理が
移行されると共に当該一部の処理を前記端末に提供する
新ホスト手段と、前記端末から要求される処理が新ホス
ト手段又は旧ホスト手段のどちらで提供されるかを判定
する移行判定手段とを備た銀行対外系業務処理装置を使
用して前記端末から要求される処理を前記旧ホスト又は
前記新ホストの一方へ振分ける振分け用プログラムを記
憶した記憶媒体であって、当該振分け用プログラムは、前記旧ホスト手段を動作さ
せるための旧ホスト用プログラムと、前記移行判定手段
を動作させるための移行判定手段用プログラムとを含
み、前記旧ホスト用プログラムは当該旧ホストを動作させる
指令として、前記端末から要求される処理について企業
コードに対応する企業別処理毎に新旧の移行を判定させ
る企業別移行判定指令を備え、前記移行判定手段用プログラムは当該移行判定手段を動
作させる指令として、前記端末から要求される処理につ
いて処理内容の業務別および店舗別の処理毎に新旧の移
行を判定させる業務店舗別移行判定指令と、この業務店
舗別移行判定指令に応じて判定される業務店舗別の移行
判定結果と前記企業別移行判定指令に応じて判定される
企業別の移行判定結果とに基づいて前記端末から要求さ
れる処理を新ホスト又は旧ホストへ振分ける振分けさせ
る振分け指令とを備えたことを特徴とする振分け用プロ
グラムを記憶した記憶媒体。
【請求項６】全銀ベーシック手順にて端末から要求さ
れる処理のうち一部の処理提供を終了した旧ホスト手段
と、この旧ホスト手段にて提供を終了した一部の処理が
移行されると共に当該一部の処理を前記端末に提供する
新ホスト手段と、前記端末から要求される処理が新ホス
ト手段又は旧ホスト手段のどちらで提供されるかを判定
する移行判定手段とを備え、前記移行判定手段は、前記端末から要求される業務種類
別に、全店舗移行完了、移行中又は全店舗未移行の３種
類の状態を示す業務別移行状態情報と、当該業務別移行
状態が移行中である場合に移行済又は未移行の店舗およ
び企業の一覧情報とを記憶した移行状態情報記憶部を備
えると共に、前記移行判定手段は、前記端末から要求される処理につ
いて前記移行状態情報記憶部中の業務別移行状態情報に
基づいて移行中か否かを判定すると共に移行中の場合に
は当該移行状態情報記憶部中の店舗又は企業の一覧情報
に基づいて店舗又は企業別に移行状態を判定する業務店
舗企業別移行判定部と、この業務店舗企業別移行判定部
によって判定された業務店舗企業別の移行判定結果に基
づいて前記端末から要求される処理を新ホスト又は旧ホ
ストへ振分ける振分け部とを備えたことを特徴とする銀
行対外系業務処理装置。