(57)【特許請求の範囲】
【請求項１】
端末とのデータ通信を制御するデータ通信制御部と、預金マスターを管理し、前記端末の操作に応じて口座番号で識別される口座の入出金を処理する口座処理部と、口座名義人である顧客の情報を全ての口座名義人を取引店にかかわらず識別する全店全層のＣＩＦ番号を単位として格納するＣＩＦマスターを管理する顧客情報管理部と、所定の対象を唯一に識別する番号の採番を管理する採番ＤＢとを備え、
前記端末が、前記口座の口座名義人を認証するための印鑑票データを格納する印鑑票データサーバーと接続され、
前記ＣＩＦマスターは、
前記ＣＩＦ番号と、同一の口座名義人が有する全店での口座で共通に使用する全店共通印である印鑑票データの印鑑票番号とを前記ＣＩＦ番号毎に格納する全店共通印セグメントと、  同一の口座名義人が有する取引店内の口座で共通に使用する取引店共通印である印鑑票データの印鑑票番号を前記ＣＩＦ番号毎及び前記取引店の店番毎に格納する取引店セグメントと、
口座番号で識別される口座毎の個別印である印鑑票データの印鑑票番号と、当該口座での口座名義人の認証に全店共通印を使用するか否かを示す全店共通印フラグと、当該口座での口座名義人の認証に取引店共通印を使用するか否かを示す取引店共通印フラグとをＣＩＦ番号毎、前記店番及び前記口座番号毎に格納する口座明細セグメントと、
代理人印等の用途を特定した印である特殊印の印鑑票の種類を示す印鑑票種類コードと、当該種類の印鑑票番号とを口座毎に格納する印鑑票セグメントとを備え、
前記顧客情報管理部は、印鑑票データを登録する際の処理として、
前記端末又は前記口座処理部から口座番号による印鑑票データ登録制御要求を受信した際に、新たな印鑑票データに対して、前記採番ＤＢを参照して、当該印鑑票データを唯一に識別し、当該口座番号とは無関係で当該口座番号から独立した印鑑票番号を採番する印鑑票番号採番機能と、
前記印鑑票データの印鑑が個別印である際には、当該個別印を登録する口座の前記口座明細セグメントに、当該口座番号と、当該採番した印鑑票番号とを格納し、前記全店共通印フラグにＯＦＦを記録し、前記取引店共通印フラグにＯＦＦを記録する個別印登録機能と、
前記印鑑票データの印鑑が全店共通印である際には、当該口座の口座明細セグメントの全店共通印フラグをＯＮを記録し、前記全店共通印セグメントに当該採番した印鑑票番号を格納し、一方、前記印鑑票データの印鑑が取引店共通印である際には、当該口座の口座明細セグメントの取引店共通印フラグをＯＮを記録し、前記取引店共通印セグメントに当該採番した印鑑票番号を格納する共通印登録機能と、
前記印鑑票の印鑑が代理人印等の特殊印である際には、前記印鑑票セグメントに、当該口座番号と、当該印鑑票の種類を示す印鑑票種類コードと、当該採番した印鑑票番号とを格納する特殊印登録機能とを備え、
当該顧客情報管理部は、印鑑票データを照会する際の処理として、
前記端末から口座番号に基づいた印鑑票データの照会があった際に、当該口座番号の口座名義人のＣＩＦ番号を特定する制御をするＣＩＦ番号特定制御機能と、
前記ＣＩＦ番号と前記口座番号とに基づいて前記ＣＩＦマスターの前記各セグメントを参照し、当該参照結果に基づいて、印鑑票番号を特定する印鑑票番号特定機能と、
前記特定した印鑑票番号に基づいて、前記印鑑票データサーバーに格納された印鑑票データを前記端末に表示させる制御をする印鑑票データ表示制御機能と、当該印鑑票データサーバーに当該印鑑票番号の印鑑票データが存在しな際には、当該印鑑票データが未登録であると前記端末に表示させる未登録情報表示制御機能とを備え、
当該顧客情報管理部の前記印鑑票番号特定機能は、前記ＣＩＦマスターの各セグメントを参照して印鑑票番号を特定する際の処理として、
前記印鑑票照会の対象となる口座番号について前記口座明細セグメントの前記全店共通印フラグがＯＮである際には、当該口座番号の印鑑票データとして前記全店共通セグメントに格納された印鑑票番号を特定する全店共通印特定機能と、
前記印鑑票照会の対象となる口座番号について前記口座明細セグメントの前記取引店共通印フラグがＯＮである際には、当該口座番号の印鑑票データとして前記取引店セグメントに格納された印鑑票番号を特定する取引店共通印特定機能と、
前記印鑑票照会の対象となる口座番号について前記口座明細セグメントの前記全店共通印フラグ及び取引店共通印フラグがＯＦＦである際には、当該口座番号の印鑑票データとして当該口座明細セグメントの印鑑票番号を特定する個別印特定機能とを備えたことを特徴とする勘定系システム。
【請求項２】
前記ＣＩＦマスターの各セグメントである全店共通印セグメントと、取引店共通印セグメントと、口座明細セグメントと、印鑑票セグメントとが、それぞれ、改印があった場合の旧印鑑票番号と、改印後の新印鑑票番号を格納し、
前記顧客情報管理部が、前記各セグメントの旧印鑑票番号及び前記新印鑑票番号に基づいて口座に対する改印の履歴を特定する改印履歴特定機能を備えたことを特徴とする請求項１記載の勘定系システム。
【請求項３】
前記顧客情報管理部が、前記印鑑票セグメントの印鑑票種類コードを参照して口座に対する特殊印を特定する特殊印特定機能を備えたことを特徴とする請求項２記載の勘定系システム。
【請求項４】
前記顧客情報管理部が、前記特殊印特定機能によって口座に特殊印が有ると特定された際には、前記印鑑票セグメントの印鑑票種類コードの順序を印鑑票の表示順序とする表示順序制御機能を備えたことを特徴とする請求項３記載の勘定系システム。
【請求項５】
前記口座に対するメモ情報を前記ＣＩＦ番号に唯一のメモ情報として格納する情報セグメントを備え、
前記顧客情報管理部が、前記印鑑票データ表示制御機能によって前記口座番号の口座で使用する前記印鑑票データが前記端末に表示される際に、前記ＣＩＦマスターの情報セグメントに格納されたＣＩＦ番号に唯一のメモ情報を当該端末に表示させる情報表示制御機能を備えたことを特徴とする請求項１記載の勘定系システム。
【請求項６】
前記ＣＩＦマスターの印鑑票セグメントが、代理人印等の用途を特定した印である特殊印又は本人印の印鑑票の種類を示す印鑑票種類コードと、当該種類の印鑑票番号と、この印鑑票番号を改印直後の印鑑票番号とする改印対象であった旧印鑑票番号と、印鑑票番号の新旧を示す新旧フラグとを有し、
前記顧客情報管理部が、改印履歴の管理対象となる印鑑票種類コードが本人印の改印要求を前記端末から受信した場合に、当該本人印の改印を制御する本人印改印制御機能を備え、この本人印改印制御機能は、
当該改印対象の口座番号の口座明細セグメントに旧印鑑票番号が格納されている際には、新たな印鑑票セグメントを作成して当該旧印鑑票番号を印鑑票番号として格納し、且つ当該新たな印鑑票セグメントの新旧フラグを旧に設定する機能と、
前記口座明細セグメントの改印対象の印鑑票番号を旧印鑑票番号として格納し、改印後の新たな印鑑票番号を当該印鑑票セグメントの印鑑票番号に格納する機能とを備えたことを特徴とする請求項１記載の勘定系システム。
【請求項７】
前記顧客情報管理部が、改印対象となる代理人印の印鑑票番号を指定した改印要求を前記端末から受信した場合に、当該代理人印の改印を制御する代理人印改印制御機能を備え、この代理人印改印制御機能は、
前記改印対象に指定された印鑑票番号を印鑑票番号として格納する印鑑票セグメントの新旧フラグをＯＦＦに設定する機能と、
新旧フラグをＯＮとする新たな印鑑票セグメントを作成し、当該印鑑票セグメントの印鑑票番号に改印後の新印鑑票番号を格納し、且つ、当該改印対象の印鑑票番号を旧印鑑票番号として格納する機能とを備えたことを特徴とする請求項６記載の勘定系システム。
【請求項８】
前記口座を新たな口座に移管する移管トランザクションの実行を制御する移管制御部と、各処理を実行するトランザクションの起動を管理し、連動処理を起動する連動起動トランザクションと、連動処理として起動される連動受動トランザクションとを一つのトランザクションとして実行させ、連動起動トランザクションと連動受動トランザクションとの両方が成立したときにコミットさせるトランザクション管理部とを備え、
前記移管制御部が、
移管元の口座番号の指定による移管処理要求を受信し、移管先の新たな口座番号を採番した後に、当該移管先の新たな口座番号と移管元の口座番号とを指定して前記口座処理部による口座開設トランザクションを連動処理として起動する新口座開設起動機能と、
前記口座開設トランザクションによって前記預金マスターに前記新たな口座番号での口座が登録された後に、前記移管元の口座番号と開設された移管先の口座番号とを指定して前記顧客情報管理部による印鑑票番号登録トランザクションを連動処理として起動する印鑑票番号登録起動機能と、
前記印鑑票番号登録トランザクションによって、移管元の口座の口座名義人の前記ＣＩＦマスターの各セグメントに登録された一又は複数の印鑑票番号を移管先の口座に関連した印鑑票番号とするために、移管元の口座番号を移管先の口座番号にする登録がされた後に、移管元の口座番号を指定して前記口座処理部による口座解約トランザクションを連動処理として起動する旧口座解約起動機能と、
前記口座解約トランザクションによって前記預金マスターに移管元の口座の解約処理が行われた後に、前記移管元の口座番号を指定して前記顧客情報管理部による印鑑票番号の抹消トランザクションを連動処理として起動する印鑑票番号抹消起動機能とを備え、
前記口座処理部が、前記口座開設トランザクション及び前記口座解約トランザクションを実行する機能を備え、
前記顧客情報管理部が、前記印鑑票番号登録トランザクション及び前記抹消トランザクションを実行する機能を備えたことを特徴とする請求項１記載の勘定系システム。
【請求項９】
前記移管制御部が、前記移管トランザクションの開始時に前記預金マスターの移管元の口座情報をロックする移管元口座情報ロック制御機能を備えたことを特徴とする請求項８記載の勘定系システム。
【請求項１０】
前記移管処理部が、移管の一括処理要求を受信した場合には、前記移管制御部によって実行制御される移管トランザクションを口座毎にＡＣＩＤ特性を有するトランザクションとして移管元の口座又はＣＩＦ番号が一定数となるまで繰り返し起動させる一括処理制御機能を備えたことを特徴とする請求項８又は９記載の勘定系システム。
【請求項１１】
勘定系システムと、印鑑票データサーバーとを使用して、印鑑票データの登録と、端末への表示とを管理する勘定系システム用プログラムであって、
前記勘定系システムが、
端末とのデータ通信を制御するデータ通信制御部と、預金マスターを管理すると共に前記端末の操作に応じて口座番号で識別される口座の入出金を処理する口座処理部と、口座名義人である顧客の情報を全ての口座名義人を取引店にかかわらず識別する全店全層のＣＩＦ番号を単位として格納するＣＩＦマスターを管理する顧客情報管理部と、所定の対象を唯一に識別する番号の採番を管理する採番ＤＢとを備え、
前記ＣＩＦマスターが、
前記ＣＩＦ番号と、同一の口座名義人が有する全店での口座で共通に使用する全店共通印である印鑑票データの印鑑票番号とを前記ＣＩＦ番号毎に格納する全店共通印セグメントと、
同一の口座名義人が有する取引店内の口座で共通に使用する取引店共通印である印鑑票データの印鑑票番号を前記ＣＩＦ番号毎及び前記取引店の店番毎に格納する取引店セグメントと、
口座番号で識別される口座毎の個別印である印鑑票データの印鑑票番号と、当該口座での口座名義人の認証に全店共通印を使用するか否かを示す全店共通印フラグと、当該口座での口座名義人の認証に取引店共通印を使用するか否かを示す取引店共通印フラグとをＣＩＦ番号毎、前記店番及び前記口座番号毎に格納する口座明細セグメントと、
代理人印等の用途を特定した印である特殊印の印鑑票の種類を示す印鑑票種類コードと、当該種類の印鑑票番号とを口座毎に格納する印鑑票セグメントとを備え、
前記印鑑票データサーバーは、前記端末と接続され、前記口座の口座名義人を認証するための印鑑票データを格納し、
前記勘定系システムの前記顧客情報管理部に所定の機能を実現させるための勘定系システム用プログラムであって、
印鑑票データを登録する際の処理として、前記勘定系システムの前記顧客情報管理部に、
前記端末又は前記口座処理部から口座番号による印鑑票データ登録制御要求を受信した際に、新たな印鑑票データに対して、前記採番ＤＢを参照して、当該印鑑票データを唯一に識別し、当該口座番号とは無関係で当該口座番号から独立した印鑑票番号を採番する印鑑票番号採番機能と、
前記印鑑票データの印鑑が個別印である際には、当該個別印を登録する口座の前記口座明細セグメントに、当該口座番号と、当該採番した印鑑票番号とを格納し、前記全店共通印フラグにＯＦＦを記録し、前記取引店共通印フラグにＯＦＦを記録する個別印登録機能と、
前記印鑑票データの印鑑が全店共通印である際には、当該口座の口座明細セグメントの全店共通印フラグをＯＮを記録し、前記全店共通印セグメントに当該採番した印鑑票番号を格納し、一方、前記印鑑票データの印鑑が取引店共通印である際には、当該口座の口座明細セグメントの取引店共通印フラグをＯＮを記録し、前記取引店共通印セグメントに当該採番した印鑑票番号を格納する共通印登録機能と、
前記印鑑票の印鑑が代理人印等の特殊印である際には、前記印鑑票セグメントに、当該口座番号と、当該印鑑票の種類を示す印鑑票種類コードと、当該採番した印鑑票番号とを格納する特殊印登録機能とを実現させ、
前記口座番号により印鑑票データを照会する際の処理として、前記勘定系システムの前記顧客情報管理部に、
前記端末から口座番号に基づいた印鑑票データの照会があった際に、当該口座番号の口座名義人のＣＩＦ番号を特定する制御をするＣＩＦ番号特定制御機能と、
前記ＣＩＦ番号と前記口座番号とに基づいて前記ＣＩＦマスターの前記各セグメントを参照し、当該参照結果に基づいて、印鑑票番号を特定する印鑑票番号特定機能と、
前記特定した印鑑票番号に基づいて、前記印鑑票データサーバーに格納された印鑑票データを前記端末に表示させる制御をする印鑑票データ表示制御機能と、当該印鑑票データサーバーに当該印鑑票番号の印鑑票データが存在しない場合には、当該印鑑票データが未登録であると前記端末に表示する未登録情報表示制御機能とを実現させ、
前記印鑑票番号特定指令は、前記ＣＩＦマスターの各セグメントを参照して印鑑票番号を特定する際の処理として、前記勘定系システムの前記顧客情報管理部に、
前記印鑑票照会の対象となる口座番号について前記口座明細セグメントの前記全店共通印フラグがＯＮである際には、当該口座番号の印鑑票データとして前記全店共通セグメントに格納された印鑑票番号を特定する全店共通印特定機能と、
前記印鑑票照会の対象となる口座番号について前記口座明細セグメントの前記取引店共通印フラグがＯＮである際には、当該口座番号の印鑑票データとして前記取引店セグメントに格納された印鑑票番号を特定する取引店共通印特定機能と、
前記印鑑票照会の対象となる口座番号について前記口座明細セグメントの前記全店共通印フラグ及び取引店共通印フラグがＯＦＦである際には、当該口座番号の印鑑票データとして当該口座明細セグメントの印鑑票番号を特定する個別印特定機能とを実現させることを特徴とする勘定系システム用プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、印影データや署名データなどの本人認証に用いるデータを管理する方法及びシステムに関する。
【０００２】
【従来の技術】
金融機関では、預金口座からの支払や、手形決済に際して、印鑑の照合や、署名の照合による本人確認を行っている。従来、例えば、予め届出のあった印鑑票の印影や署名と、支払等の依頼書等に捺印された印影等との照合を行っていた。そして、近年、コンピュータシステムの利用により印影データを一元管理し、金融機関の本支店（取引店）に設置された端末に印影データ等を表示する仕組みが提案されている。
【０００３】
特開平８−３３９４２号公報には、端末から口座番号を入力するだけで簡単に印鑑照合を行うことを課題として、印影データの登録番号を口座番号として登録するサーバーと、検索すべき口座の口座番号を送信すると共にこの口座番号に基づいてサーバーから送信される印影データを表示する端末とを備えた印鑑照会システムが開示されている。この公報では、印影データのデータ名に口座番号を用いると共に、一つの口座番号に複数の印影データがある場合には、登録日を用いて管理する旨が開示されている。
【０００４】
特開平１０−４９６６０号公報には、大量の印鑑票データの登録作業における事前準備を簡略にするために、印鑑票データを識別する「検索キー」を用いる旨が開示されている。特開平１１−２３２４５８号公報では、店番、科目、口座番号をキーとして、その口座の印鑑票データを管理する旨が開示されている。この従来例では、印鑑票データを、勘定系ホストとは別に、印鑑照会システムに登録し、管理している。
【０００５】
特開平１１−２３２４５８号公報等に開示された例では、改印等の口座情報の変更があった場合、勘定系ホスト側をまず変更し、この変更データをディスクやオンラインで印鑑照会システムに送信し、自動的に印鑑照会システムの口座情報を変更する手法が開示されている。
【０００６】
【発明が解決しようとする課題】
特開平１１−２３２４５８号公報に開示された従来例では、印鑑の紛失や、印鑑の変更や代理人印等の追加等の印鑑票に関する変更があった場合には、勘定系ホスト側を変更すると共に、ディスク等を用いて印鑑照会システム側を変更する必要があり、事務処理上の負担となる。また、オンラインで送信する例では、勘定系システムと印鑑照会システム間の通信負荷が高まり、また印鑑照会システムでの変更反映処理などのシステム負荷が高くなってしまう。
【０００７】
また、特開平８−３３９４２号公報等に開示された従来例では、印鑑票データの番号を口座番号としているため、例えば店舗の統廃合を行う際に口座番号を変更すると、この口座の移管に伴って印鑑票データの番号を付け替えなければならず、システム運用上の負荷が大きくなり、また確認作業などの事務処理負担も大きい。「口座の移管」は、口座の取引店（営業店）の変更等によって同一の口座について口座番号を変更することをいう。
【０００８】
さらに、印鑑の紛失届けなど、個人認証データの変更があった場合には、その直後から当該紛失等の状態を反映させなければならないため、従来例では、その口座の取引を中断するなどの手続きが必要となり、顧客の利便性を低下させ、また、金融機関側の事務取扱負担を増加させてしまう、という不都合があった。
【０００９】
【発明の目的】
本発明は、共通印を含む印鑑票データの取扱いに関して、人手による事務処理負担を低減し、且つ、システムの運用上のメンテナンスの負担をなくすことのできる勘定系システムを提供することを、その目的とする。
【００１０】
【課題を解決するための手段】
本発明では、端末とのデータ通信を制御するデータ通信制御部と、預金マスターを管理し、前記端末の操作に応じて口座番号で識別される口座の入出金を処理する口座処理部と、口座名義人である顧客の情報を全ての口座名義人を取引店にかかわらず識別する全店全層のＣＩＦ番号を単位として格納するＣＩＦマスターを管理する顧客情報管理部と、所定の対象を唯一に識別する番号の採番を管理する採番ＤＢとを備えている。
前記端末は、前記口座の口座名義人を認証するための印鑑票データを格納する印鑑票データサーバーと接続されている。
本発明では、前記ＣＩＦマスターは、全店共通印セグメントと、取引店セグメントと、口座明細セグメントと、印鑑票セグメントとを備えている。
全店共通印セグメントは、前記ＣＩＦ番号と、同一の口座名義人が有する全店での口座で共通に使用する全店共通印である印鑑票データの印鑑票番号とを前記ＣＩＦ番号毎に格納する。
取引店セグメントは、同一の口座名義人が有する取引店内の口座で共通に使用する取引店共通印である印鑑票データの印鑑票番号を前記ＣＩＦ番号毎及び前記取引店の店番毎に格納する。
口座明細セグメントは、口座番号で識別される口座毎の個別印である印鑑票データの印鑑票番号と、当該口座での口座名義人の認証に全店共通印を使用するか否かを示す全店共通印フラグと、当該口座での口座名義人の認証に取引店共通印を使用するか否かを示す取引店共通印フラグとをＣＩＦ番号毎、前記店番及び前記口座番号毎に格納する。
印鑑票セグメントは、代理人印等の用途を特定した印である特殊印の印鑑票の種類を示す印鑑票種類コードと、当該種類の印鑑票番号とを口座毎に格納する。
そして、前記顧客情報管理部は、前記個人認証データを登録する際に、次の情報処理を行う機能を備える。すなわち、顧客情報管理部は、前記端末又は前記口座処理部から口座番号による印鑑票データ登録制御要求を受信した際に、新たな印鑑票データに対して、前記採番ＤＢを参照して、当該個人認証データを唯一に識別し、当該口座番号とは無関係で当該口座番号から独立した個人認証データ番号を採番する印鑑票番号採番機能と、前記印鑑票データの印鑑が個別印である際には、当該個別印を登録する口座の前記口座明細セグメントに、当該口座番号と、当該採番した印鑑票番号とを格納し、前記全店共通印フラグにＯＦＦを記録し、前記取引店共通印フラグにＯＦＦを記録する個別印登録機能と、前記印鑑票データの印鑑が全店共通印である際には、当該口座の口座明細セグメントの全店共通印フラグをＯＮを記録し、前記全店共通印セグメントに当該採番した印鑑票番号を格納し、一方、前記印鑑票データの印鑑が取引店共通印である際には、当該口座の口座明細セグメントの取引店共通印フラグをＯＮを記録し、前記取引店共通印セグメントに当該採番した印鑑票番号を格納する共通印登録機能と、前記印鑑票の印鑑が代理人印等の特殊印である際には、前記印鑑票セグメントに、当該口座番号と、当該印鑑票の種類を示す印鑑票種類コードと、当該採番した印鑑票番号とを格納する特殊印登録機能とを備えている。
また、本発明では、顧客情報管理部は、印鑑票データを照会する際の処理として、次の情報処理を行う機能を備える。すなわち、顧客情報管理部は、前記口座番号に基づいた前記印鑑票データの照会があった際に、前記端末から口座番号に基づいた印鑑票データの照会があった際に、当該口座番号の口座名義人のＣＩＦ番号を特定する制御をするＣＩＦ番号特定制御機能と、前記ＣＩＦ番号と前記口座番号とに基づいて前記ＣＩＦマスターの前記各セグメントを参照し、当該参照結果に基づいて、印鑑票番号を特定する印鑑票番号特定機能と、当該印鑑票データサーバーに当該印鑑票番号の印鑑票データが存在しな際には、当該印鑑票データが未登録であると前記端末に表示させる未登録情報表示制御機能とを備え、当該特定した前記印鑑票番号に基づいて、前記印鑑票データサーバーに格納された印鑑票データを前記端末に表示させる制御をする印鑑票データ表示制御機能と、当該印鑑票データサーバーに当該印鑑票番号の印鑑票データが存在しない際には、当該印鑑票データが未登録であると前記端末に表示させる未登録表示制御機能とを備えている。
さらに、本発明では、当該顧客情報管理部の前記印鑑票番号特定機能は、前記ＣＩＦマスターの各セグメントを参照して印鑑票番号を特定する際の処理として、次の情報処理を行う機能を備える。すなわち、顧客情報管理部は、前記印鑑票照会の対象となる口座番号について前記口座明細セグメントの前記全店共通印フラグがＯＮである際には、当該口座番号の印鑑票データとして前記全店共通セグメントに格納された印鑑票番号を特定する全店共通印特定機能と、前記印鑑票照会の対象となる口座番号について前記口座明細セグメントの前記取引店共通印フラグがＯＮである際には、当該口座番号の印鑑票データとして前記取引店セグメントに格納された印鑑票番号を特定する取引店共通印特定機能と、前記印鑑票照会の対象となる口座番号について前記口座明細セグメントの前記全店共通印フラグ及び取引店共通印フラグがＯＦＦである際には、当該口座番号の印鑑票データとして当該口座明細セグメントの印鑑票番号を特定する個別印特定機能とを備えた、
という構成を採っている。これにより前述した課題を解決しようとするものである。
【００１１】
本発明では、印鑑票データの番号を口座番号ではなく印鑑票データ専用の番号を用いる。そして、口座番号と印鑑票データ番号とを関連付ける。通常の照会処理では、口座番号から印鑑票データ番号を特定する。そして、印鑑票データを登録する際に、前記採番ＤＢを参照して、当該印鑑票データを唯一に識別し、当該口座番号とは無関係で当該口座番号から独立した印鑑票データ番号を採番するため、口座番号とは独立して印鑑票データを管理することができる。
また、本発明では特に、印鑑票データの登録は、実際のイメージデータなどの登録ではなく、印鑑票データ番号の採番と、口座番号とを関連させ対応付けた印鑑票データ番号管理データを格納することで完了する。従って、口座開設時や改印時など、窓口での事務処理が長時間になることを防止できる。
さらに、本発明では、この印鑑票データ番号の管理を、勘定系システムを用いて行う。このため、紛失等による印鑑票データの使用停止依頼や、印鑑票データの変更依頼があった場合であっても、勘定系システムに接続された端末を操作するのみで、口座番号と印鑑票データ番号との関連付けを更新することができるため、印鑑票データを使用停止とするための事務取扱負担が少ない。
また、口座の移管を行う場合には、印鑑票データ番号を変更することなく、口座番号と印鑑票データ番号との関連付けを更新する処理のみで対応できるため、印鑑票データの番号の付け替えという負荷の大きいメンテナンス処理や、印鑑票データを格納するデータベースのデータ再編成処理を行う必要がない。
そして、本発明では、この印鑑票番号と口座番号の関連付けをＣＩＦマスターで管理するため、全店共通印や取引店共通印の導入及び運用が容易で、これらの共通印の導入により顧客利便性を向上させつつ、事務取扱負担を増加させず、また、システム負荷も小さくすることができる。
【００１２】
【発明の実施の形態】
以下、本発明の実施の形態について図面を参照して説明する。図１は本発明の実施形態の構成例を示すフローチャートである。本実施形態による個人認証データ管理方法は、口座の入出金を処理する勘定系システムを使用して当該口座の口座名義人を認証するための個人認証データを管理する。個人認証データは、支払等の決済を金融機関等の窓口などで請求する人が、口座名義人本人であるか否かを判定するためのデータである。個人認証データは、例えば、印鑑の印影データや、自筆による署名データや、虹彩データや、指紋データなどである。
【００１３】
図１に示すように、本実施形態による個人認証データ管理方法では、まず、口座についての個人認証データを登録する時に、当該個人認証データを唯一に識別する個人認証データ番号を採番する（ステップＳ１，個人認証データ番号採番工程）。個人認証データへの採番は、全ての口座名義人の全ての個人認証データを識別する番号の付与とする。そして、個人認証データの番号は、口座番号とは無関係に独立した番号体系とすると良い。
【００１４】
本実施形態による方法では、続いて、口座番号についての個人認証データに採番された個人認証データ番号と、口座の口座番号とを関連させる（ステップＳ２，関連付け工程）。関連付け工程では、採番した個人認証データ番号と、その口座番号とを関連させる。関連は、例えば、個人認証データ番号と口座番号とを主キーとするデータベースに格納する。この個人認証データ番号と口座番号との対応を格納したデータを、ここでは、個人認証データ番号管理データと呼ぶ。
【００１５】
図１に示す方法では、さらに、口座番号に基づいて個人認証データの照会があった場合には、例えば、口座番号を指定した個人認証データの照会要求を受信した場合には（ステップＳ３）、当該口座番号に関連づけられた個人認証データ番号に応じて当該口座番号に対応する個人認証データを特定する（ステップＳ５，個人認証データ特定工程）。この個人認証データ特定工程Ｓ５は、例えば、口座番号に基づいて個人認証データ管理データを参照し、口座番号に対応する個人認証データ番号を特定する処理である。
【００１６】
本実施形態では、個人認証データの番号を口座番号ではなく、個人認証データに特有な個人認証データ番号としている。これにより、個人認証データの変更があった場合には、新しい個人認証データに新しい個人認証データ番号を採番し、新しい個人認証データ番号と口座番号との関連付けを行うことで、個人認証データの番号等を変更する等のシステム負荷の大きい処理を行うことなく、個人認証データの変更をシステムに反映させることができる。
【００１７】
さらに、本実施形態では、勘定系システムにて個人認証データ番号を管理するため、個人認証データを変更し、古い個人認証データの使用を禁止する場合、例えば、ある口座についての印鑑を変更した場合であっても、変更処理を勘定系システムに登録し、個人認証データ番号管理データを更新した直後から、古い個人認証データを使用不可とすることができ、取引の安全性を十分に確保しつつ、窓口等での事務取扱負担を少なくし、顧客の窓口での待ち時間を短縮することができる。
【００１８】
さらに、店舗の統廃合などで口座番号を変更する場合には、個人認証データ番号と口座番号の関連付けである個人認証データ番号管理データを新しい口座番号に更新するだけで、個人認証データ番号の付け替えや、並べ替え、再編成等のシステム負荷の大きい処理を行う必要がない。
【００１９】
このように、本実施形態では、個人認証データの照会を行う際に、口座番号から個人認証データ番号を特定するステップＳ５による処理が必要となるが、個人認証データを取り扱うための事務処理負担を大幅に軽減し、且つ、口座移管や個人認証データの変更時のシステム負荷を削減することができる。特に、金融機関のシステムは２４時間３６５日の連続運用が求められており、この連続運用に近い運用を行うためには、口座移管を行うためにその口座についての取引を長時間中止することは望ましくない。この点、本実施形態による個人認証データ管理方法では、勘定系システムで２つの番号の関連づけの更新を行うことで口座の移管を実施することができるため、極めて短時間で口座の移管処理を完結させることができる。
【００２０】
本実施形態では、個人認証データは、勘定系システムに格納するのではなく、個人認証データサーバーに格納するようにしても良い。この場合、個人認証データサーバーは、個人認証データを個人認証データ番号と対応させて格納する。この個人認証データサーバーは、個人認証データ番号毎に個人認証データであるイメージデータを記憶する比較的簡易なデータベースとして構築できる。そして、全ての個人認証データにユニークな個人認証データ番号が採番されるため、この個人認証データ番号をファイル名又はファイル名の一部として利用することで、メンテナンスの不要なデータベースとすることができる。個人認証データが数種類ある場合には、個人認証データ番号の全部又は一部をファイル名として、個人認証データの種類に応じたディレクトリを作成し、ツリー状に格納すると良い。
【００２１】
この個人認証データサーバーを勘定系システムに併設する例では、勘定系システムは、個人認証データ番号のデータを表示させる指令を端末に送信する。端末では、この個人認証データ番号のデータを個人認証データサーバーから読み出す処理を行う。図１に示すように、特定した番号の個人認証データが個人認証データサーバーに格納されている場合には（ステップＳ６）、この登録された個人認証データを端末に表示させる（ステップＳ７）。一方、個人認証データサーバーから当該個人認証データを読み出す際に、当該個人認証データ番号に対応する個人認証データが存在しない場合には、当該個人認証データが未登録であると端末１に表示する（ステップＳ８，未登録表示制御工程）。
【００２２】
図１に示す例では、個人認証データの登録は、実際のイメージデータの登録ではなく、個人認証データ番号の採番Ｓ１と、口座番号との関連付けＳ２という勘定系システムでの処理で一旦完了する。すなわち、個人認証データをイメージデータ化して、個人認証データサーバーに格納する作業を待たずに、個人認証データの登録を完了する。これにより、窓口での事務処理が長時間になることを防止し、また、全ての窓口にスキャナー等を配置することなく、本店や地区センター等で事後的に個人認証データのイメージデータ化及びサーバーへの格納を行うことができる。そして、図１に示す例では、個人認証データの表示を行う際に、その個人認証データ番号のデータが個人認証データサーバーに登録されていない場合には、未登録である旨の表示を行う。これにより、その口座に対して個人認証データが登録された事実と、実際の格納が完了していない旨とを端末に表示させることができる。すなわち、本実施形態では、個人認証データの新規登録や、変更の事実自体は、その登録、変更を勘定系システムに登録した直後から個人認証データの照会処理に反映させることができる。
【００２３】
例えば、個人認証データが印影である場合に、印鑑の変更届を受信した場合には、変更先の新たな個人認証データに新しい個人認証データ番号を採番し、この新しい個人認証データ番号と口座番号とを関連させる処理を勘定系システムにて操作する。その直後に他の端末から当該口座についての照会要求があった場合には、図１のステップＳ８の処理によって、個人認証データが未登録である旨の表示がなされる。このように、本実施形態では、個人認証データの登録や変更時に、その進行状況に応じた適切な表示を行うことができる。
【００２４】
図２は本実施形態による個人認証データの変更を登録する処理例を示すフローチャートである。口座番号を指定した個人認証データの更新要求を受信すると（ステップＳ１１）、すなわち、同一の口座に対する新しい個人認証データを登録する場合には、まず、当該新たな個人認証データに新たな個人認証データ番号を採番する（ステップＳ１２）。このステップＳ１２は、図１に示すステップＳ１による処理の一例である。続いて、新しい個人認証データを登録する口座の口座番号と、新たな個人認証データ番号とを関連づける（ステップＳ１３）。このステップＳ１３は、図１に示すステップＳ２による処理の一例である。図２に示す例では、変更された元の個人認証データ番号とその口座番号との関連付けを抹消する。この抹消により、元の個人認証データは使用されなくなる。また、当座勘定などの場合に、個人認証データの変更履歴を格納する場合には、抹消処理ではなく、旧データとしての登録を行うようにしても良い。図２に示す例では、勘定系システムで個人認証データ番号を管理し、そして、更新する新しい個人認証データ番号と口座番号とを関連付けするため、この更新処理の完了直後に、端末での照会処理にて個人認証データの変更が反映される。
【００２５】
図３は、本実施形態による口座の移管処理例を示すフローチャートである。口座の移管要求を受信すると（ステップＳ２１）、勘定系システムでは、新しい口座の開設処理を行う（ステップＳ２２）。例えば、新設又は移管先の店番での口座番号を採番する。そして、移管先の新たな口座番号と移管元の口座番号に対応する個人認証データ番号とを関連付ける（ステップＳ２３）。このステップＳ２３は、図１に示すステップＳ２による処理の一例である。続いて、移管元の口座の解約処理を行う。図３に示す構成により移管処理を行うことで、個人認証データの番号の付け替え等の処理を行う必要がなく、システムメンテナンス負荷が小さく、移管処理を短時間で完了することができる。
【００２６】
図４は、本実施形態による勘定系システムの構成例を示すブロック図である。図４に示す例では、勘定系システムは、営業店等に設置された端末１（１Ａ，１Ｂ，１Ｃ）とのデータ通信を制御するデータ通信制御部６と、端末の操作に応じて口座の入出金を処理すると共に処理結果を端末に送信する口座処理部１０とを備えている。そして、口座処理部１０が、口座についての個人認証データを登録する時に、当該個人認証データを唯一に識別する個人認証データ番号を採番する個人認証データ番号採番機能１２と、口座の口座番号と当該口座番号についての個人認証データに採番された個人認証データ番号とを関連させる関連付け機能１４とを備えている。個人認証データ番号採番機能１２は、図１に示すステップＳ１，図２に示すステップＳ１２等の処理を行う。関連付け機能１４は、図１に示すステップＳ２，図２に示すステップＳ１３，図３に示すステップＳ２３等の処理を行う。
【００２７】
端末１は、支店の窓口に設置され、個人認証データを表示するディスプレイを有する営業店端末１Ａと、ＡＴＭ等の端末１Ｂと、勘定系システムの管理運用に使用するコンソール端末１Ｃとを備える。個人認証データが印影データや署名データである場合には、端末１Ａに印影データや署名データを表示する。また、ＡＴＭ等で暗証番号の一種として虹彩等を用いて本人認証を行う制度が導入されるのであれば、ＡＴＭに虹彩データや指紋データを送信するようにしてもよい。
【００２８】
勘定系システムは、さらに、口座番号に基づいて個人認証データの照会があった場合には、当該口座番号に関連づけられた個人認証データ番号を特定する個人認証データ特定機能１６と、個人認証データ特定機能１６によって特定された個人認証データ番号に基づいて個人認証データの端末１への表示を制御する個人認証データ表示制御機能１８とを備えている。個人認証データ特定機能１６は、図１に示すステップＳ５のように、口座番号に基づいて対応する個人認証データ番号を特定する。
【００２９】
また、図４に示す例では、端末１に、個人認証データを個人認証データ番号と対応させて格納する個人認証データサーバー４を接続している。すなわち、勘定系システムに個人認証データサーバーを併設している。そして、口座処理部１０は、個人認証データ表示制御機能１８の一部として、個人認証データ番号に基づいて個人認証データサーバーに格納された当該個人認証データを端末に表示させる登録データ表示制御機能２０と、当該個人認証データ番号に対応する個人認証データが存在しない場合には、当該個人認証データが未登録であると端末１に表示させる未登録情報表示制御機能２２とを備えている。この２つの機能２０，２２により、図１に示す個人認証データの表示制御（Ｓ７）や、個人認証データが未登録であることの表示制御（Ｓ８）を行う。
【００３０】
図４に示す例では、端末１に、一又は複数の営業店を単位として個人認証データサーバー４から受信した個人認証データを当該個人認証データ番号に基づいてキャッシュするキャッシュＤＢ９を併設している。そして、口座処理部１０は、個人認証データがキャッシュＤＢ９に格納されていない場合に、当該個人認証データを端末１から個人認証データサーバー４へと要求させるキャッシュ使用機能２４を備えている。このキャッシュ使用機能２４は、個人認証データ表示制御機能１８の一部である。
【００３１】
本実施形態では、全ての局面で個人認証データと個人認証データ番号の対応は一対一であるため、キャッシュＤＢ９を利用しやすい。すなわち、キャッシュＤＢ９に登録されているデータと、個人認証データサーバーに登録されているデータは個人認証データ番号に対して常に同一であるため、個人認証データサーバー４に格納されたデータが変更されたか否かを確認せずにキャッシュＤＢ９を用いることができる。使用しない個人認証データを完全に削除し、個人認証データ番号を再利用する場合には、当該再利用のために個人認証データを削除するときに、当該個人認証データ番号のデータをキャッシュＤＢ９から削除する。
【００３２】
図１から図３までに示す処理や、図４に示す構成は、演算手段としてのＣＰＵが所定のプログラムを実行することで実現することができる。勘定系システムのＣＰＵ（図示せず）は、所定のプログラム（指令）に従って各種の演算を行う。ＣＰＵは、各種の処理要求に従ってオンライントランザクションをスケジュール（ルーティング）すると共に、その実行結果を端末１に戻す。ＣＰＵが口座処理用のプログラムを実行することで、勘定系システムは、口座への入出金や各種情報の登録等を処理する。
【００３３】
本実施形態では特に、勘定系システム用プログラムは、個人認証データ（印鑑票データ）を管理するための各種の指令を備える。勘定系システム用プログラムは、口座処理部等を動作させる指令として、例えば、口座についての個人認証データを登録する時に、当該個人認証データを唯一に識別する個人認証データ番号を採番させる個人認証データ番号採番指令（Ｓ１等，機能１２に対応）と、口座の口座番号と当該口座番号についての個人認証データに採番された個人認証データ番号とを関連させる関連付け指令（Ｓ２等，機能１４に対応）と、口座番号に基づいて個人認証データの照会があった場合には、当該口座番号に関連づけられた個人認証データ番号を特定する個人認証データ特定指令（Ｓ４等，機能１６に対応）と、個人認証データ特定指令に応じて特定される個人認証データ番号に基づいて、個人認証データの端末１への表示を制御する個人認証データ表示制御指令（Ｓ７，Ｓ８等，機能１８に対応）とを備える。
【００３４】
勘定系システムのＣＰＵは、これらの指令を実行することで、ステップＳ２等の関連付け処理を実行し、また、図４に示す関連付け機能１４等として動作する。その他、勘定系システム用プログラムが、勘定系システムや印鑑照会システムにて実現すべき各機能や、フローチャートの各工程に応じた指令を備えることで、ＣＰＵは対応する処理を行う。例えば、勘定系システム用プログラムが、個人認証データ番号に対応する個人認証データが個人認証データサーバーに存在しない場合に、当該個人認証データが未登録であると端末に表示させる指令を備えることで、ＣＰＵは、未登録情報表示制御機能２２として動作することができる。
【００３５】
この勘定系システム用プログラムは、磁気テープ（ＭＴ）やディスク等の記録媒体１１Ａに格納されて搬送され、媒体読取部１１によって読み取られる。記録媒体に格納されていた勘定系システム用プログラムは、媒体読取部１１にて読み取られた後、プログラム記憶部に格納される。また、他のホスト装置から通信回線を経由してプログラム記憶部に当該プログラムを提供することもできる。
【００３６】
プログラムについて、ＣＰＵ（演算手段）を「動作させる指令」というときには、各指令のみでＣＰＵを動作させる指令と、プログラム記憶部に予め格納されているオペレーティングシステム等の他のプログラムに依存して当該ＣＰＵを動作させる指令とのいずれかまたは双方を含む。ここでは、「オペレーティングシステム」は広義に解釈している。トランザクションマネージャーや、データベースマネージャー等を含む。
【００３７】
上記関連付け指令は、実際には、口座又は口座名義人に関する情報を管理するデータベースマネージャーに口座番号に対応して個人認証データ番号を引き渡す指令のみで、実際の関連付けたデータの格納は当該関連付け指令ではなく、データベースマネージャーが行うようにしても良い。このように、勘定系システム用プログラムを記憶する記録媒体１１Ａであって、当該プログラムをユーザへ搬送する用途の記録媒体１１Ａには、例えば「所定のデータベースマネージャーに個人認証データ番号を引き渡す指令」のみが格納され、実際のデータの格納等はオペレーティングシステムによって行われる場合がある。これは、動作させようとするコンピュータのオペレーティングシステムやデータベースマネージャー等との関係で定まる。この点、通信回線を介してプログラム（指令）を提供する場合も同様である。
【００３８】
このプログラムとシステム又は方法、搬送媒体等に関する説明は後述する実施形態、実施例においても同様である。特に、同一の名前が付されている機能、工程、指令のそれぞれが対応する点は、各実施形態においても同様である。例えば、勘定系システム用プログラムは、キャッシュ使用機能を実現するには、その機能を実現するためのキャッシュ使用指令を備える。
【００３９】
再度図４を参照すると、図４全体の構成は、個人認証データ照会システムである。個人認証データ照会システムは、営業店等に設置された端末１と、この端末１の操作に応じて口座の入出金を処理すると共に処理結果を端末１に送信する勘定系システムと、端末１と接続され口座の口座名義人の個人認証データを唯一に識別する個人認証データ番号を用いて管理する個人認証データサーバー４と、一又は複数の営業店を単位として個人認証データサーバー４から受信した個人認証データを当該個人認証データ番号に基づいてキャッシュするキャッシュＤＢとを備える。
【００４０】
そして、勘定系システムの口座処理部１０は、図４に示す各機能１２，１４等を備える。このように、勘定系システムで個人認証データ番号と口座番号の関係を関連付けとして管理し、一方、個人認証データについては個人認証データサーバー４に格納する構成とすることで、個人認証データについての登録や変更があった場合に、即座にその変更を勘定系システムに登録しつつ、個人認証データサーバー４では個人認証データ番号によるファイル名でファイルを格納するのみの簡易な構成とすることができる。これにより、個人認証データの管理に関する事務処理負担を軽減すると共に、個人認証データサーバー４での再編成処理を不要とするなど、システム負荷や運用上のメンテナンス負担を軽減する。
【００４１】
以下、個人認証データが印鑑票データであり、個人認証データ番号が印鑑票番号である場合を例に説明する。印鑑票は、自筆の署名と、印鑑の印影とが用紙上に記録される伝票である。印鑑票データは、印鑑票データ全体のイメージや、印影のみの精密なイメージデータや、署名データなどを含む。印鑑票データを扱う例では、個人認証データサーバーを印鑑票データサーバーと呼ぶ。図４を参照すると、勘定系システムは、口座情報及び顧客情報を格納した元帳ファイル２５を備えている。そして、元帳ファイル２５は、印鑑票番号と口座番号の関連付けを印鑑票番号管理データ２６として格納する。また、本人認証に用いる印鑑には、個別の口座毎に登録する個別印と、複数の口座について共通に使用する共通印とがある。
【００４２】
図５は、本実施形態での勘定系システムでの口座開設制御方法の構成例を示すフローチャートである。図５に示す例では、端末１Ａ等から口座開設要求を受信すると（ステップＳ３１）、まず、新設口座に新しい口座番号を採番する（ステップＳ３２，口座番号採番工程）。そして、当該新設口座に関連して印鑑票を受理した場合には（ステップＳ３３，イエス）、当該印鑑票データに印鑑票番号を採番する（ステップＳ３４）。一方、予め登録した共通の印鑑票データを当該新設口座に使用する場合には（ステップＳ３３，ノー）、取引店に共通印が登録されているか否かを確認し、登録されていれば、当該共通の印鑑票番号を特定する（ステップＳ３５）。このステップＳ３３，Ｓ３４及びＳ３５を、印鑑票番号採番特定工程と呼ぶ。ステップＳ３５にて、取引店に共通印が登録されていない場合には、端末１Ａ等にエラーを返し、当該取引店での共通印の登録を促す。
【００４３】
続いて、ステップＳ３４で採番した又はステップＳ３５で特定した印鑑票番号と、新設口座の口座番号とを関連付けする。そして、当該口座番号と印鑑票番号の対応を印鑑票番号管理データ２６として元帳ファイル２５に格納する（ステップＳ３６，開設時管理データ格納工程）。これにより、口座番号に対して共通印の印鑑票番号か、または、個別印の印鑑票番号が印鑑票番号管理データ２６に登録される。
【００４４】
続いて、印鑑票を受理した場合には、採番した印鑑票番号との関係で当該印鑑票データを勘定系システム内又は勘定系システム外の印鑑票データサーバー４Ａへ格納する（ステップＳ３７，印鑑票データ格納工程）。このように印鑑票データの格納が行われると、図４に示す印鑑票照会制御部２８は、印鑑票番号管理データ２６を参照して当該口座番号に関連づけられた印鑑票番号を特定すると共に、当該特定した印鑑票番号に基づいて当該口座の印鑑票データの照会を制御することができる。共通印を用いる場合には、印鑑票番号管理データ２６の登録の直後から共通印の印影を照会することができる。一方、個別印を用いる場合には、当該個別印の印鑑票データが印鑑票データサーバー４Ａに格納されるまでは、当該印鑑票番号のデータが未登録である旨が端末１Ａ等に表示され、印鑑票データの格納後は当該印鑑票の照会が可能となる。
【００４５】
次に、印鑑を新しい印鑑に変更する改印処理を開示する。再度図２を参照すると、口座に関連して印鑑票の変更を受理した場合には（ステップＳ１１）、新しい印鑑票に新たな印鑑票番号を採番する（ステップＳ１２，新印鑑票番号採番工程）。続いて、印鑑票変更対象の口座番号と新たな印鑑票番号とを関連させると共に、当該口座番号と新たな印鑑票番号との対応を印鑑票番号管理データとして元帳ファイル２５に格納する（ステップＳ１３，改印時管理データ格納工程）。さらに、新たな印鑑票データを新たな印鑑票番号との関係で勘定系システム内又は勘定系システム外の印鑑票データサーバー４Ａへ登録する（ステップＳ１３，印鑑票登録工程）。このように改印処理を行うことで、窓口の事務処理負担を最小限とすることができ、改印の受付を短時間で完了させつつ、その直後からは全ての端末１からの照会要求に対して、改印された印影の表示又は改印した印影データの格納中である旨を表示することができる。
【００４６】
次に、口座の移管について、再度図３を参照して説明する。口座の移管は、当該口座に対する入出金要求が完了し、そして他の処理要求を受信しないようにロックした状態で開始する。ここでは、まず、移管する口座に新たな口座番号を採番する（ステップＳ２２，移管先口座番号採番工程）。そして、移管元の口座番号と関連している印鑑票番号を移管先口座番号へ関連させると共に、当該移管先口座番号と印鑑票番号との対応を印鑑票番号管理データ２６として元帳ファイル２５に格納する（ステップＳ２３，移管時管理データ格納工程）。
【００４７】
このよに、本実施形態では、口座番号と印鑑票番号とを併用するため、改印処理や口座の移管処理において印鑑票データのファイル名の変更というシステム負荷の高い処理を行うことなく、勘定系システムでの印鑑票番号管理データの更新という比較的高速に完了する処理のみで移管や改印等の処理を完了することができる。
【００４８】
【実施例】
次に、本発明の実施例を説明する。本実施例では、全店全層ＣＩＦ（Customer Information file）によるＣＩＦデータを用いる。すなわち、全ての顧客を取引店等に関わらず識別するＣＩＦ番号を用いて、顧客の顧客情報を管理する。
【００４９】
図６は、本実施例による印鑑照会システムの構成例を示すブロック図である。印鑑票データを格納する印鑑票データサーバー４Ａと接続された端末１と、預金マスター等を管理すると共に口座の入出金を処理する口座処理部１０と、口座名義人等の顧客の情報を格納するＣＩＦマスター５を管理する顧客情報管理部３０とを備えている。口座処理部１０は、入出金要求などを実行する。例えば、入金金額や出金金額を預金マスター８の取引明細セグメント等に登録する。取引明細セグメント等のルートセグメントに当該口座名義人のＣＩＦ番号を格納しておくと、口座番号に基づいてＣＩＦ番号を特定することができる。例えば、口座処理部１０に口座番号を指定した残高照会を要求すると、残高情報と共にＣＩＦ番号を得ることができる。顧客情報管理部３０は、ＣＩＦマスター５を管理する。ＣＩＦマスター５は、顧客を識別する番号であるＣＩＦ番号別に、口座番号毎、営業店毎又はＣＩＦ番号毎の印鑑票番号を格納している。すなわち、本実施例では、図４に示す印鑑票番号管理データをＣＩＦマスターの項目としている。
【００５０】
顧客情報管理部３０は、端末から口座番号に基づいた印鑑票データの照会があった場合には、当該口座番号の口座名義人のＣＩＦ番号を特定する制御をするＣＩＦ番号特定制御機能３２と、ＣＩＦ番号と口座番号とに基づいてＣＩＦマスター５を参照すると共に、当該参照結果に基づいて、口座番号、営業店又はＣＩＦ番号毎の印鑑票番号を特定する印鑑票番号特定機能３４と、特定した印鑑票番号に基づいて印鑑票データサーバーに格納された印鑑票データを端末１に表示させる制御をする印鑑票データ表示制御機能３６とを備えている。
【００５１】
ＣＩＦ番号特定制御機能３２は、口座処理部１０に当該口座番号の残高照会を行うことで、当該口座名義人のＣＩＦ番号を特定する。印鑑票番号特定機能３４は、ＣＩＦ番号に基づいてＣＩＦマスター５を参照し、当該口座番号に対応する印鑑票番号を特定する。そして、印鑑票データ表示制御機能３６は、端末１Ａに当該印鑑票番号の印鑑票データを表示させる制御をする。端末１Ａでは、印鑑票データ表示制御機能３６から送信された印鑑票番号の印鑑票データをキャッシュＤＢ９又は印鑑票データサーバー４Ａに要求し、受信したデータを表示する。このとき、印鑑票番号に対応する印鑑票データが未格納である場合には、未格納である旨を表示する。
【００５２】
ＣＩＦと関連させて印鑑票番号を管理すると、個別の口座毎の個別印ではなく、その顧客の複数の口座に共通の共通印を管理しやすい。また、口座の属性として印鑑票を管理するのではなく、顧客情報の一部として印鑑票を管理すると、より情報の一元化を図ることができ、印鑑票の登録、改印、口座移管等の処理をより少ないファイル・アクセス回数で実現することができる。
【００５３】
図７は、本実施例によるＣＩＦマスターの詳細構成の一例を示す説明図である。図７に示す例では、ＣＩＦマスター５が、営業店単位の一又は複数の口座の共通印となる印鑑票番号を営業店毎に管理する取引店セグメント６２と、口座単位の印鑑票番号と当該口座が取引店共通印の使用であるか否かを示す取引店共通印フラグとを口座毎に管理する口座明細セグメント６４とを備えている。
【００５４】
そして、顧客情報管理部３０の印鑑票番号特定機能３４が、印鑑票照会の対象となる口座番号について口座明細セグメント６４の取引店共通印フラグがＯＮである場合には、当該口座番号の印鑑票データとして取引店セグメントに格納された印鑑票番号を特定する取引店共通印特定機能３８と、印鑑票照会の対象となる口座番号について口座明細セグメント６４の取引店共通印フラグがＯＦＦである場合には、当該口座番号の印鑑票データとして当該口座明細セグメントの当該口座番号に対応して格納された印鑑票番号を特定する個別印特定機能４０とを備える。この機能３８，４０を備える構成では、個別印と、取引店内で共通の共通印とを取り扱う。これにより、顧客の要望に応じて共通印と個別印とを併用することができる。
【００５５】
また、取引店共通印のみならず、全店共通印も取り扱うことができる。この場合、ＣＩＦマスター５が、全営業店に共通の全店共通印の印鑑票番号を格納する全店共通セグメント（ルートセグメント）６０を備える。そして、口座明細セグメント６４が、各口座番号で使用する印鑑票が全店共通印であるか否かを示す全店共通印フラグを有する。そして、顧客情報管理部３０が、印鑑票照会の対象となる口座番号について口座明細セグメントの全店共通印フラグがＯＮである場合には、当該口座番号の印鑑票データとして全店共通セグメント６０に格納された印鑑票番号を特定する全店共通印特定機能４２を備える。全店全層ＣＩＦを用いると、この全店共通印を比較的簡単に導入し、安定して運用することができる。すなわち、顧客の全ての口座について共通する全店共通印の印鑑票番号をＣＩＦマスター５のルートセグメント６０に格納し、口座明細セグメント６４の全店共通印フラグをＯＮとするだけで、ＣＩＦマスターを参照し、口座番号から全店共通印の印鑑票番号を特定することができる。
【００５６】
また、当座の場合には、手形の決済との関係で旧印を管理する必要がある。この場合、図７に示すように、ＣＩＦマスター５の各セグメントは、改印があった場合の旧印鑑票番号と、改印後の新印鑑票番号とを格納する。すなわち、ルートセグメント６０、取引店セグメント６２、口座明細セグメント６４及び印鑑票セグメント６６は、それぞれ旧印鑑票番号を格納する。印鑑票セグメント６６は、口座番号毎に、旧印鑑票の印鑑票番号と、この旧印鑑票番号に対する旧印の印鑑票番号とを改印数に応じて繰り返し格納する。そして、顧客情報管理部３０は、各セグメント６０，６２，６４，６６の旧印鑑票番号及び印鑑票セグメントの印鑑票番号に基づいて口座に対する改印の履歴を特定する改印履歴特定機能４４を備えている。改印履歴特定機能４４は、印鑑票番号特定機能３４の一部である。
【００５７】
印鑑票セグメント６６を備えることで、何回改印があっても当該印鑑票セグメントを順次増加させることで、その改印の順序を特定しつつ、旧印の印鑑票番号を管理することができる。例えば、印鑑票番号の特定に際して、改印履歴特定機能４４は、口座番号に基づいて口座明細セグメント６４を読み取る。個別印である場合には、全店共通印フラグと、取引店共通印フラグはＯＦＦであり、この口座明細セグメント６４には、現在の個別印鑑票番号が特定されている。そして、ここに旧印鑑票番号が格納されている場合には、この旧印鑑票番号を印鑑票番号とする印鑑票セグメント６６が作成されている。さらに、この印鑑票セグメントに旧印鑑票番号が格納されている場合には、さらに前の旧印鑑票番号が格納されている。このため、印鑑票セグメント６６の新旧の印鑑票番号の連鎖的な関係から、改印の順序を含めて改印履歴を特定することができる。この新旧の印鑑票番号の関係を用いることで、ＩＭＳ等の階層型データベースを用いて印鑑票番号の履歴を管理することができる。
【００５８】
また、印鑑票には、代理人印、別印、小切手印、手形印、連続手形印、外貨預金印などの用途を特定した印影が捺印される。このような特殊印の管理についても、印鑑票セグメント６６を用いることができる。この場合、印鑑票セグメント６６は、代理人印等の特殊印の印鑑票の種類を示す印鑑票種類コードと、当該種類の印鑑票番号と、この印鑑票番号が現在のものであるか否かを示す新旧フラグと、改印された場合の旧印鑑票番号とを格納する。印鑑票種類コードは、本人印：０１、代理人印：０２、別印：０３、小切手印：０４、手形印：０５，連続手形印：０６、外貨預金印０８である。
そして、顧客情報管理部３０は、印鑑票セグメントの印鑑票種類コードを参照して口座に対する特殊印を特定する特殊印特定機能４６を備える。特殊印特定機能４６は、印鑑票番号特定機能２４の一部である。また、特殊印についても、改印履歴を管理するようにしても良い。この場合、改印履歴特定機能４４は、印鑑票セグメントの印鑑票番号に基づいて印鑑票の種類毎に改印の履歴を特定する。また、代理人が複数ある場合には、代理人印ごとに改印の登録をすることで、代理人毎の改印履歴を特定することができる。
【００５９】
図８は、本実施例による印鑑票データの照会処理の一例を示すフローチャートである。照会要求を受信すると、顧客情報管理部３０は、ＣＩＦマスター５の口座明細セグメント６４を読み出す。そして、口座明細セグメント６４の全店共通印フラグがＯＮであれば、ルートセグメント６０の印鑑票番号を読み出す。また、全店共通印フラグがＯＦＦで、取引店共通印フラグがＯＮである場合には、取引店セグメント６２の印鑑票番号を読み出す。一方、全店共通印フラグ及び取引店共通印フラグが共にＯＦＦである場合には、口座明細セグメントの印鑑票番号を読み出す。
【００６０】
続いて、口座について印鑑票セグメントを順次読み出す（ステップＳ８４）。同一の口座について同一種類の印鑑票セグメントが存在する場合には、印鑑票番号と旧印鑑票番号の関係を順次たどることにより、改印履歴を特定する。
【００６１】
また、特殊印がある場合には、印鑑票の表示順序を印鑑票種類コードに基づいて特定するようにしても良い。この場合、顧客情報管理部３０が、印鑑票セグメントの印鑑票種類コードと印鑑票番号とに基づいて、口座についての印鑑票の表示順序を特定する表示順序制御機能３６を備える。機能３６による表示では、まず、現在の印鑑票を印鑑票種類コードの順序で表示し、その後、旧印を印鑑票種類コード順で、その印鑑票種類コード内での新しい順序で表示する。
【００６２】
印鑑票そのものを用いて照合を行う事務処理では、印鑑票の受付担当者が顧客との関係に関する注意事項等を印鑑票にメモし、後日印鑑照合を要する事務処理の担当者がこのメモ情報を参照することが行われていた。本実施例では、印鑑票全体のイメージデータを照会することでメモ情報を確認することもできるが、図６に示す例では、メモ情報を顧客に共通にものとして、印鑑票から切り離して処理する。すなわち、印鑑票は特定の口座に使用するものであるが、このメモ情報は口座に関わらず顧客についての情報であることが多いため、ＣＩＦマスターで管理する。そして、印鑑票データの照会時に、印鑑票データにこのメモ情報を合成する。これにより、同一の顧客については印鑑の種類に関わらずメモ情報を参照することができる。
【００６３】
この例では、図７に示すように、ＣＩＦマスター５が、印鑑票と関係して登録されるメモ情報を格納する情報セグメント６８を備えている。そして、顧客情報管理部３０が、印鑑票データ表示制御機能３６によって印鑑票データが端末１に表示される際に、情報セグメント６８に格納されたメモ情報を当該端末１に表示させる情報表示制御機能５０を備えている。このように、容量の大きい印鑑票データ（イメージデータ）は印鑑票データサーバー４Ａで管理し、一方、数文字からなるメモ情報については、勘定系システムで管理する。そして、情報表示制御機能５０が、印鑑票データにこのメモ情報を合成する。これにより、印鑑票の種類や口座番号によらず、同一の顧客に対して一貫してメモ情報を印鑑票データの一部として表示することができる。
また、ＣＩＦマスター５は、ある世帯（例えば、同一住所で同一名字）に属する個人を名寄せした世帯名寄せや、企業グループを名寄せした企業名寄せ等を格納する関連名寄せセグメント７０と、パソコンサービス等各種の契約の有無を格納する諸契約セグメント７２と、マル優の有無や種類を格納するマル優セグメント等を備える。
【００６４】
図９は、本実施例による印鑑票データの表示例を示す説明図である。図９（Ａ）は、当座勘定印鑑票全体のイメージを端末１Ａに表示した例である。顧客メモ情報は、情報表示制御機能５０による表示である。図９（Ｂ）は、ＣＩＦマスターを走査することで取得した印鑑票登録情報を含む署名データの表示例である。図９（Ｂ）「長野太郎」という表示は、印鑑票番号に基づいて特定した印鑑票データの一種であり、印鑑票データサーバー４Ａから読み出したデータである。そして、印影データ自体は、特別に精密な表示を行う印影表示装置に表示する。この表示例を図９（Ｃ）に示す。また、フラットで精密な表示を行える端末を採用する場合には、印影表示装置を用いずに、端末の画面切り替えで印影データの詳細イメージを表示するようにしても良い。また、２つの印鑑が揃って口座名義人の確認をするような場合には、１つの印影データに当該２つの印鑑の印影を含めるようにするとよい。
【００６５】
本実施例では、種々の情報を合成して印鑑票データとして表示する。例えば、住所、氏名、電話番号等はＣＩＦマスターの基本項目データから読み出した内容である。そして、印鑑票登録状況は、ＣＩＦデータの口座明細セグメント６４や印鑑票セグメント６８等を走査した結果である。「長野太郎」との署名データと、印影表示装置に表示した印影データとは印鑑票データサーバー４Ａ（又はキャッシュＤＢ９）に格納されていたイメージデータである。また、預金マスター５４に登録されている口座に関する情報も表示する。例えば、口座登録情報として、通帳等の喪失や、支払停止の有無などである。
【００６６】
このように、本実施例では、印鑑票データサーバー４Ａは印鑑票番号に応じたファイル名で印鑑票データを格納するのみである。印鑑票番号の管理は、顧客情報の一部として、顧客情報管理部３０がＣＩＦマスターを用いて管理する。また、口座に関する詳細情報は、口座処理部１０が普通預金マスターや定期預金マスター等の預金マスター５４を用いて管理する。そして、種々の目的に応じて、口座情報処理と、顧客情報管理処理とを連動させることで、１つのまとまったトランザクションとして口座の開設や、共通印鑑票の登録や、改印や、口座の移管等の処理を行う。
【００６７】
図６に示す構成は、上述した実施形態と同様に、勘定系システムのＣＰＵが勘定系システム用プログラムを実行することで実現することができる。この場合、勘定系システム用プログラムは、顧客情報管理部を動作させる指令として、端末から口座番号に基づいた印鑑票データの照会があった場合には、当該口座番号の口座名義人のＣＩＦ番号を特定させる制御のためのＣＩＦ番号特定制御指令と、ＣＩＦ番号と口座番号とに基づいてＣＩＦマスター５を参照すると共に、当該参照結果に基づいて、口座番号、営業店又はＣＩＦ番号毎の印鑑票番号を特定させる印鑑票番号特定指令と、特定した印鑑票番号に基づいて前記印鑑票データサーバー４Ａに格納された印鑑票データを端末１に表示させる印鑑票データ表示制御指令とを備える。また、勘定系システムが情報表示制御機能５０を備えるには、勘定系システム用プログラムが当該機能５０を実現するための情報表示制御指令を備えると良い。
【００６８】
次に、口座処理部１０と顧客情報管理部が連動する例を説明する。図６を参照すると、顧客情報管理部３０は、端末１から口座番号に基づいた印鑑票データの照会があった場合には、当該口座番号に基づいて口座処理部１０へ当該口座番号のＣＩＦ番号の照会要求を出力するＣＩＦ番号照会要求機能５５を備えている。そして、口座処理部１０は、ＣＩＦ番号の照会要求を受信した場合には、預金マスター８等を参照して当該口座番号の口座名義人のＣＩＦ番号を顧客情報管理部３０に戻すＣＩＦ番号戻し機能５６を備えている。このように顧客情報管理部３０と口座処理部１０とが連動して処理することで、データの重複格納を排除し、処理の要求に応じて種々のデータベースから情報を読み出すことができる。
【００６９】
口座処理部の開発者が、顧客情報管理部の開発内容の事細かな詳細を知る必要があると、開発負担が大きくなる。逆に、顧客情報管理部の開発者が口座処理の内容の詳細の全てを把握することも難しい。このため、連動処理では、データの受け渡しについて、予め定められたメモリ領域（連動戻りブロック）を用いる。勘定系システムのオペレーティングシステムは、個々の処理要求を受信すると、処理要求に応じたトランザクションを起動する。例えば、口座番号を指定した印鑑票データの照会要求を受信すると、顧客情報管理部３０が起動し、印鑑票データ番号の特定処理を開始する。このとき、ＣＩＦマスター５では、口座番号からＣＩＦ番号を特定するためのデータ構造を有しない。このため、顧客情報管理部３０は、ＣＩＦ番号の照会要求として、当該口座番号の口座についての残高照会を口座処理部に要求する（機能５５）。口座処理部１０では、この口座番号について残高照会処理を行い、その結果を連動戻りブロックに格納する（機能５６）。これにより、顧客情報管理部３０は、当該口座のＣＩＦ番号を取得することができる。口座情報管理部３０は、このＣＩＦ番号に基づいてＣＩＦマスターを探索し、口座番号に基づいて印鑑票番号を特定する。
【００７０】
図１０は、本実施例による勘定系システムでの印鑑票番号の登録制御及び改印制御を行う構成例を示すブロック図である。図１０に示すように、顧客情報管理部３０は、端末１又は口座処理部１０からの印鑑票データ登録制御要求に応じて、新たな印鑑票データに印鑑票番号を採番する印鑑票番号採番機能８０を備えている。そして、顧客情報管理部３０は、印鑑票の印鑑が個別印である場合には、当該個別印を登録する口座の口座明細セグメントに当該採番した印鑑票番号を格納すると共に、共通印フラグをＯＦＦに設定する個別印登録機能８２を備えている。この勘定系システムが全店共通印と取引店共通印を取り扱う場合には、両方のフラグをＯＦＦに設定する。
【００７１】
顧客情報管理部３０は、印鑑票の印鑑が取引店又は全店での共通印である場合には、当該共通印とする口座の口座明細セグメントの共通印フラグをＯＮとすると共に、共通印セグメント６０，６２に当該採番した印鑑票番号を格納する共通印登録機能８４を備えている。共通印セグメントは、取引店セグメント６２又はルートセグメント６０である。共通印登録機能８４は、取引店共通印を登録する場合には、取引店セグメント６２に当該印鑑票番号を格納する。一方、全店共通印を登録する場合には、ルートセグメント６０に印鑑票番号を登録する。
【００７２】
また、顧客情報管理部３０は、印鑑票の印鑑が代理人印等の特殊印である場合には、当該特殊印を登録する口座の印鑑票セグメント６６に当該採番した印鑑票番号を格納する特殊印登録機能８６を備えている。特殊印登録機能８６は、印鑑票データ登録要求に付随する印鑑票の種別に応じて、印鑑票セグメントの印鑑票種類に印鑑票種類コードを格納する。
【００７３】
図１１は本実施例による印鑑票の登録処理の一例を示すフローチャートである。印鑑票の登録要求を受信すると、当該印鑑票に印鑑票番号を採番する（ステップＳ５０）。続いて、その登録要求が個別印の登録要求であるか否かを判定する（ステップＳ５１）。個別印を新規に登録する場合には、まず、登録する口座の口座明細セグメント６４をＣＩＦマスター５に作成する（ステップＳ５２）。続いて、作成した口座明細セグメントに印鑑票番号を格納する（ステップＳ５３）。そして、取引店共通印フラグ及び全店共通印フラグをＯＦＦにする。
【００７４】
取引店共通印の登録要求である場合には、まず、登録する口座の取引店の取引店セグメント６２をＣＩＦマスター５に作成し、一方、すでに取引店セグメントが存在する場合には、これを読み出す（ステップＳ５６）。そして、取引店セグメント６２に印鑑票番号を格納する（ステップＳ５７）。そして、取引店セグメントの取引店共通印フラグをＯＮとする（ステップＳ５８）。また、取引店共通印を利用した口座の開設処理中に、当該口座明細セグメント６４の取引店共通印フラグをＯＮとする（ステップＳ５９）。
【００７５】
全店共通印の登録要求である場合には、ＣＩＦマスター５のルートセグメント６０を読み出し（ステップＳ６０）、そして、このルートセグメント６０に印鑑票番号を格納する（ステップＳ６１）。続いて、ルートセグメント６０の全店共通印フラグをＯＮとする（ステップＳ６２）。また、全店共通印を利用した口座の開設処理中に、当該口座明細セグメント６４の全店共通印フラグをＯＮとする。
【００７６】
特殊印の登録を行う場合には、印鑑票セグメントを作成し、印鑑票種類コードともに印鑑票番号を格納する。
【００７７】
この印鑑票の登録に関する機能を勘定系システムにて実現するには、勘定系システム用プログラムが、顧客情報管理部３０を動作させる指令として、端末１又は口座処理部１０からの印鑑票データ登録制御要求に応じて、新たな印鑑票データに印鑑票番号を採番させる印鑑票番号採番指令（Ｓ５０，機能８０に対応）を備える。このプログラムはさらに、印鑑票の印鑑が個別印である場合には、当該個別印を登録する口座の口座明細セグメント６４を作成させて当該採番した印鑑票番号を格納させると共に、共通印フラグをＯＦＦに設定させる個別印登録指令（ステップＳ５２からＳ５４，機能８２に対応）と、印鑑票の印鑑が取引店又は全店での共通印である場合には、当該共通印とする口座の口座明細セグメントを作成させて共通印フラグをＯＮに設定させると共に、営業店又は全店の口座の共通印となる印鑑票番号を格納する共通印セグメントを作成させて当該採番した印鑑票番号を格納させる共通印登録指令（ステップＳ５６から５８，Ｓ６０からＳ６２，機能８４に対応）とを備える。
【００７８】
また、このプログラムは、印鑑票の印鑑が代理人印等の特殊印である場合には、当該特殊印を登録する口座の印鑑票セグメントを作成させて当該採番した印鑑票番号を格納させる特殊印登録制御指令（機能８６に対応）を備えると良い。
【００７９】
次に、口座開設処理を行う構成例を説明する。図１０に示す例では、勘定系システムは、各種の番号を管理する採番ＤＢ５４を備えている。採番ＤＢ５４は、店番別の口座番号を与えるデータベースとすると良い。そして、未使用の店番での番号を、印鑑票番号とすることもできる。すると、採番処理を共通化することができる。
【００８０】
個別印での口座開設制御を行う例では、口座処理部１０が、端末１から個別印を指定した口座開設要求を受信した場合には、顧客情報管理部３０へ口座番号の採番要求を出力する口座番号採番要求機能５８を備えている。口座番号採番要求機能５８は、連動処理として口座番号の採番要求を出力する。
【００８１】
そして、顧客情報管理部１０は、口座番号の採番要求を受信した場合に、採番ＤＢ５４を参照して口座番号及び印鑑票番号を採番する口座番号採番機能９０と、この口座番号採番機能によって採番された口座番号の口座明細セグメントをＣＩＦマスター５に作成すると共に当該口座明細セグメントに採番した印鑑票番号を格納する個別印登録機能８２と、採番した口座番号及び印鑑票番号を口座処理部１０に戻す口座番号戻し機能８８とを備えている。さらに、口座処理部１０は、前記戻された口座番号に基づいて預金マスター８を更新する預金マスター更新機能５９を備える。
【００８２】
図１２は個別印を用いた口座開設制御の一例を示すシーケンス図である。端末１からＣＩＦ番号と入金金額とを指定した口座開設要求（口座開設オペ）を受信すると、口座処理部１０は、ＣＩＦ番号を指定した口座番号採番要求を連動処理として顧客情報管理部３０に出力する（ステップＳ４２）。顧客情報管理部３０は、採番ＤＢ５４を参照して印鑑票番号を採番し（ステップＳ４３）、続いて、採番ＤＢ５４を参照して口座番号を採番する（ステップＳ４４）。そして、顧客情報管理部３０は、ＣＩＦマスター５の口座明細セグメント６４に、印鑑票番号を格納し、口座明細セグメント６４の取引店共通印フラグ及び全店共通印フラグをＯＦＦとする（ステップＳ４６）。
【００８３】
この印鑑票番号の登録処理が完了すると、顧客情報管理部３０は、連動戻りブロックに採番した口座番号と印鑑票番号とを格納し、処理を口座処理部１０に戻す。口座処理部１０では、開設した口座について入金等の処理を行い、預金マスター５４を更新する（ステップＳ４７）。例えば、指定された入金金額と、ＣＩＦ番号とを預金マスター８に格納する。続いて、口座処理部１０は、印鑑票に印鑑票番号を印字する制御を行う（ステップＳ４８）。これにより、印鑑票と印鑑票番号とが印鑑票の伝票上で確認することができ、印鑑票の印鑑票データサーバー４Ａへの格納処理を行う（ステップＳ４９）。
【００８４】
共通印を用いた口座開設処理を行う例では、共通印の登録処理を口座開設に先立って行う。共通印登録機能８４は、全店共通印を登録する場合には、ルートセグメント６０の全店共通印フラグをＯＮとし、ルートセグメント６０に印鑑票番号を格納する。取引店共通印を登録する場合には、その取引店の取引店セグメント６２を作成し、当該取引店セグメント６２の取引店共通印フラグをＯＮとし、この取引店セグメント６２に印鑑票番号を格納する。共通印の登録後、全店又は取引店の共通印であることを指定して口座開設処理を行う。端末１から全店又は取引店の共通印であることを指定した口座開設要求を受信すると、まず、口座番号採番要求機能５８が、顧客情報管理部３０へ口座番号の採番要求を出力する。そして、口座番号の採番要求を受信した口座番号採番機能９０は、採番ＤＢ５４を参照して口座番号を採番する。
【００８５】
さらに、共通印登録機能８４は、口座番号採番機能９０によって採番された口座番号の口座明細セグメント６４を作成して、当該口座明細セグメントの共通印フラグをＯＮに設定する。共通印登録機能８４は、取引店共通印の場合には、口座明細セグメント６４の取引店共通印をＯＮとする（図１１のステップＳ５９）。また、全店共通印の場合には、口座明細セグメント６４の全店共通印フラグをＯＮとする。これにより、当該口座番号の口座を共通印とすることができる。
【００８６】
そして、口座番号等戻し機能８８が、採番した口座番号を口座処理部１０に戻す。さらに、預金マスター更新機能５９が、戻された口座番号に基づいて預金マスター８を更新する。
【００８７】
次に、本実施例での改印処理を説明する。再度図１０を参照すると、顧客情報管理部３０は、新しい印鑑票が個別印である場合には、口座明細セグメント６４に格納された改印対象の印鑑票番号を旧印鑑票番号として格納すると共に、採番された改印後の新印鑑票番号を当該口座明細セグメント６４の印鑑票番号に格納する個別印改印制御機能９２を備えている。本実施例では、端末１から個別印の改印要求を受信した場合には、印鑑票番号採番機能８０が、当該新しい印鑑票データに印鑑票番号を採番する。そして、顧客情報管理部３０が、まず、口座明細セグメント６４に格納された改印対象の印鑑票番号を旧印鑑票番号として格納する。顧客情報管理部３０は、続いて、採番された改印後の新印鑑票番号を当該口座明細セグメント６４の印鑑票番号に格納する。
【００８８】
また、共通印の改印を行うために、顧客情報管理部３０は、新しい印鑑票の印が共通印である場合には、共通印セグメント６０，６２に格納された改印対象の印鑑票番号を旧印鑑票番号とすると共に、採番された改印後の新印鑑票番号を当該共通印セグメント６０，６２の印鑑票番号に格納する共通印改印制御機能９４を備えている。共通印は、取引店共通印又は全店共通印である。
【００８９】
さらに、改印履歴を管理する印鑑の改印を行うために、顧客情報管理部３０は、当座等の改印履歴の管理対象となる本人印の改印要求を端末１から受信した場合に、当該本人印の改印を制御する本人印改印制御機能９６と、改印対象となる代理人印の印鑑票番号を指定した改印要求を端末１から受信した場合に、当該代理人印の改印を制御する代理人印改印制御機能９８とを備えている。
本人印改印制御機能９６は、当該改印対象の口座番号の口座明細セグメント６４に旧印鑑票番号が格納されているときには、新たな印鑑票セグメント６６を作成して当該旧印鑑票番号を印鑑票番号として格納し、且つ当該新たな印鑑票セグメント６６の新旧フラグを旧に設定する機能と、口座明細セグメント６４の改印対象の印鑑票番号を旧印鑑票番号として格納すると共に、改印後の新たな印鑑票番号を当該印鑑票セグメント６６の印鑑票番号に格納する機能とを備えている。代理人印改印制御機能９８は、改印対象に指定された印鑑票番号を印鑑票番号として格納する印鑑票セグメント６６の新旧フラグをＯＦＦに設定する機能と、新旧フラグをＯＮとする新たな印鑑票セグメント６６を作成すると共に当該印鑑票セグメント６６の印鑑票番号に改印後の新印鑑票番号を格納し、且つ、当該改印対象の印鑑票番号を旧印鑑票番号として格納する機能とを備えている。
【００９０】
図１３は、本実施例による改印処理の一例を示すシーケンス図である。
端末１から改印処理要求（改印オペ）を受信すると、顧客情報管理部３０は、まず、採番ＤＢ５４を参照して改印後の新しい印鑑票番号を採番する。採番ＤＢは店番別のカウンタであり、採番ＤＢ５４は、印鑑票番号に割り当ててある店番での番号を顧客情報管理部３に渡すと、印鑑票番号を１つ増加させ、その値を次回用の印鑑票番号として記憶する。
【００９１】
図１３に示すように、顧客情報管理部３０は、端末１から入力された口座番号に基づいて、口座名義人のＣＩＦ番号の照会を連動処理にて口座処理部１０に依頼する。口座処理部１０は、ＣＩＦ番号を連動戻りブロックに格納して処理を完了する。顧客情報管理部３０は、改印履歴の有無等に応じて、対応するセグメントの更新や作成を行う（ステップＳ７５からＳ７７）。このステップＳ７５からＳ７７での処理は、個別印と共通印の相違や、本人印と代理人印とその他特殊印の相違によって変化する。顧客情報管理部は、改印要求に付加される印鑑票種類番号を参照して印鑑票の種類を特定し、また、口座番号（店番科目口座番号）に基づいて、改印履歴を管理する当座の印鑑であるか否かを特定する。改印履歴を管理しない場合、個別印と共通印の相違に応じて、個別印改印制御機能９２又は共通印改印制御機能９４がセグメントの更新を行う。すなわち、ルートセグメント６０、取引店セグメント６２、口座明細セグメント６４のいずれかに格納された改印対象の印鑑票番号を旧印鑑票番号として格納すると共に（ステップＳ７６）、改印後の新印鑑票番号を対応するセグメントの印鑑票番号として格納する（ステップＳ７７）。この場合、旧印鑑票番号は改印オペレーションの取消の際に利用する。
改印履歴を管理する当座の印鑑である場合には、改印要求で指定された印鑑票種類に基づいて、印鑑票の種類を判定する。当座の本人印である場合には、本人印改印制御機能９６が、改印対象の印鑑票番号を履歴として格納するために、新たに印鑑票セグメント６６を作成して改印対象の印鑑票番号を格納すると共に、当該印鑑票セグメント６６の新旧フラグをＯＦＦとする（ステップＳ７５）。そして、口座明細セグメント６４に格納されていた改印対象の印鑑票番号を旧印鑑票番号として格納する（ステップＳ７６）。続いて、改印後の新しい印鑑票番号を当該口座明細セグメントの印鑑票番号として格納する（ステップＳ７７）。
代理人印の改印では、改印要求に改印対象の代理人印の印鑑票番号が付加されている。この改印対象の印鑑票番号の印鑑票セグメントを読み出し、この新旧フラグを旧とする（ステップＳ７５）。そして、新しい印鑑票セグメントを作成し、付加された改印対象の印鑑票番号を旧印鑑票番号とし（ステップＳ７６）、新しい印鑑票番号を当該作成した印鑑票セグメントに格納する（ステップＳ７７）。そして、この新たな印鑑票セグメントの新旧フラグを新とする。
【００９２】
図１４及び図１５は、改印処理によるＣＩＦマスター５の各セグメントの変更例を示す説明図であり、図中、「フラグ」を「Ｆ」と省略している。図１４（Ａ）は取引店共通印の改印を行う例である。取引店共通印を改印するために、新たな印鑑票の届出を受けると、ステップＳ７２にて印鑑票番号を採番する。例えば、採番ＤＢの印鑑票番号に対応した店番に100-000-103との番号が格納されていると、この番号が今回の新しい印鑑票番号となる。そして、図１４（Ａ）に示すように、改印前の印鑑票番号が100-000-102であるとする。この場合、ステップＳ７６にて、まず、共通印改印前の取引店セグメント６２Ａに格納された印鑑票番号（100-000-102）を、旧印鑑票番号として登録する。続いて、ステップＳ７７にて、今回採番した印鑑票番号（100-000-103）を新たな印鑑票番号として当該取引店セグメント６２Ａに格納する。この例では、新しいセグメントは作成せず、セグメントの更新である。これにより、改印のためのＣＩＦデータの更新が完了する。この更新後に印鑑照会要求があると、印鑑照会制御部２８は、取引店セグメントの印鑑票番号100-000-103の表示を制御する。また、もし改印の取消を要求された場合には、旧印鑑票番号に格納された番号を印鑑票番号として再登録するのみで、改印の取消を実行することができる。
【００９３】
図１４（Ｂ）は、個別印の改印を行う例である。ここでは、採番ＤＢから新しい印鑑票番号として100-000-104を取得したとする。元々の印鑑票番号は口座明細セグメント６４Ａに格納された100-000-001である。ステップＳ７６では、元々の印鑑票番号（100-000-101）を旧印鑑票番号に格納する。そして、ステップＳ７７では、新しい印鑑票番号（100-000-104）を口座明細セグメント６４Ａの印鑑票番号として格納する。また、図１４（Ｂ）に示す例では、この口座が当座勘定であり、改印履歴を管理する。このため、ステップＳ７５にて、印鑑票セグメント６６Ａを作成し、旧印鑑票番号（100-000-001）を印鑑票セグメント６６に本人印（印鑑票種類コード01）として格納し、新旧フラグをＯＦＦ（旧）とする。
【００９４】
この状況で再度改印要求を受信した場合には、例えば、新たな印鑑票番号100-000-105への改印を行う場合には、新たに印鑑票セグメント６６Ｂを作成し、旧印鑑票番号である100-000-104と旧々印鑑票番号である100-000-001とを格納する。印鑑票セグメント６６Ａには、何ら処理を加えず、この印鑑票セグメント６６Ａは、そのまま旧々印鑑票番号である100-000-001を格納する。口座明細セグメント６４Ａには、最新の印鑑票番号である100-000-105と、旧印鑑票番号である100-000-104を格納して更新する。これにより、改印履歴特定機能４４は、口座明細セグメント６４から、印鑑票番号をたどって印鑑票セグメント６６に格納された旧印の印鑑票番号を改印の順序で特定することができる。
図１５は、代理人印の改印の例である。口座明細セグメント６６Ａと本人印についての印鑑票セグメント６６Ａ，６６Ｂとは、図１４（Ｂ）の再改印後の状態とする。その後、二人の代理人Ａ，Ｂがそれぞれ代理人印を登録したとする。この場合、印鑑票セグメント６６Ｃ，Ｄが作成される。ここで、代理人Ｂが改印要求をした場合、代理人Ａの印鑑票番号100-000-106に対する改印ではなく、印鑑票番号100-000-107を改印対象とする改印となる。
従って、ステップＳ７１の代理人Ｂの改印オペでは、改印対象の代理人の印鑑票番号を指定する。すると、口座情報管理部３０は、ステップＳ７５にて、改印対象の印鑑票番号の履歴を管理するために、ステップＳ７５にて、印鑑票セグメント６６Ｄの新旧フラグをＯＦＦ（旧）に更新する。続いて、新たな印鑑票セグメント６６Ｅを作成し、改印対象の旧印鑑票番号100-000-107と、改印後の新たな印鑑票番号100-000-108とを格納する。印鑑票セグメント６６Ｅの新旧フラグはＯＮ（新）とする。
【００９５】
図１３に示すように、ＣＩＦマスターの更新が完了すると、顧客情報管理部は、印鑑票に採番した印鑑票番号を印字する制御を行い（ステップＳ７８）、端末１は、この印鑑票番号を印鑑票の所定位置に印字する。その後、この印鑑票を印字された印鑑票番号に基づいてスキャンし、印鑑票データを印鑑票データサーバー４Ａに格納する。
【００９６】
勘定系システムが図１０等に示す改印制御は、勘定系システムのＣＰＵが、所定の勘定系システム用プログラムを実行することで実現できる。この場合、勘定系システム用プログラムは、顧客情報管理部を動作させる指令として、端末１から個別印又は共通印の改印要求を受信する場合には、当該新しい印鑑票データに印鑑票番号を採番させる印鑑票番号採番指令（ステップＳ７２，機能８０に対応）と、新しい印鑑票の印が個別印である場合には、口座明細セグメント６４に格納された印鑑票番号を旧印鑑票番号として更新させると共に、採番された印鑑票番号を当該口座明細セグメント６４に格納させる個別印改印制御指令（ステップＳ７６からＳ７７等，機能９２に対応）と、新しい印鑑票の印が共通印である場合には、共通印セグメント６０，６２に格納された印鑑票番号を旧印鑑票番号とすると共に前記採番された印鑑票番号を当該共通印セグメント６０，６２に格納させる共通印改印制御指令（ステップＳ７６からＳ７７等，機能９４に対応）とを備える。
【００９７】
図１６は、本実施例による勘定系システムでの印鑑票データの口座移管制御を行う構成例を示すブロック図である。図１６に示すように、本実施例による勘定系システムは、印鑑票データを格納する印鑑票データサーバー４Ａと接続された端末１と、預金マスター８等を管理すると共に口座の入出金を処理する口座処理部１０と、口座名義人等の顧客の情報を格納するＣＩＦマスターを管理する顧客情報管理部３０と、前記口座を新たな口座に移管する移管トランザクションの実行を制御する移管制御部１００と、各処理を実行するトランザクションの起動を管理すると共に連動処理として起動される連動受動トランザクションを当該起動した連動起動トランザクションと一体のＡＣＩＤ特定を満たす一つのトランザクションとして実行させるトランザクション管理部１０２とを備えている。
ＡＣＩＤ特性は、トランザクションの原子性（Atomicity）、一貫性（Consistency）、隔離性（Isolation）及び耐久性（Durability）である。
【００９８】
金融機関の勘定系システムなど、大規模なデータベースに対して正確で一貫性があり障害に対して確実な復旧を可能とするために、トランザクション処理が利用されている。トランザクションは、データベース（ＤＢ）に対する処理の単位として用いられる。トランザクションは、ＤＢに一又は複数の更新を行う。このとき、トランザクションは、その性質によって、全体として成功するか又は全体として失敗するかのいずれかであることが保証される。ＤＢへの全ての更新に成功した場合に、トランザクションは同期点(syncpoint)に達する。すなわち、トランザクションはコミット(commit)する。一般的なトランザクション管理システムでは、同期点に達したトランザクションによる更新はログに記録され、このＤＢへの更新は障害に対して耐久性（Durability）を有する。
【００９９】
一方、トランザクションに含まれる処理のうち一つでも成立しなかった場合には、そのトランザクションはアボート(abort)される。トランザクションがアボートされると、そのトランザクションが行った全ての更新は取り消される。すなわち、トランザクションがアボートされると、トランザクション管理システムは、その時までに実行された全ての更新をロールバックする。このため、トランザクションは、一又は複数のプログラムを実行し、複数の更新を行っていても、全ての更新を正常に実行しコミットするか、又は、ロールバックによりなにも処理しないかのいずれかである。トランザクションは、アプリケーションにとって処理の最小単位となることから、これをトランザクションの原子性（アトミック性，Atomicity）という。
【０１００】
トランザクションは原子性を有するから、プログラマは、ＤＢの更新に際して一貫性・整合性（Consistency）を保つことができる。適用業務プログラム（アプリケーション，ＡＰＰＬ）のプログラマは、他のトランザクションによって参照されるべきではない中間的なデータの算出処理と、この中間的なデータを正常なデータへと変換又は関連させる処理とを１つのトランザクションとして包み込むことで、ＤＢの整合性、データの一貫性を保つことができる。正常なデータへ変換されたことを条件としてコミットするため、中間的なデータの状態でＤＢに格納され、他のトランザクションによってこの中間的なデータが参照されることはない。一方、正常なデータに変換されない場合には、トランザクションがアボートされるため、中間的なデータの算出及び更新もロールバックにより取り消される。
【０１０１】
例えば、口座振替（資金移動）は、ある口座Ａからの数値の減算（出金）と、他の口座Ｂへの数値の加算（入金）とからなる処理である。中間的なデータは、例えばある口座Ａからの数値の減算である。この数値の減算処理と加算処理とを１つのトランザクションとして包み込むことで、口座振替に成功するか、または失敗するかのいずれかであることが保証される。この場合、数値の減算のみ又は加算のみが行われることはない。すなわち、出金と入金とを１つのトランザクションとして処理すると、出金だけが行われ、入金なされないという事態は生じない。
【０１０２】
また、トランザクション間での前後関係を明確に保ち、トランザクション処理中のデータを他のトランザクションが参照できないようにすることで、複数のトランザクションを並行して処理することができる。このように、並列処理や分散処理を行うためには、トランザクション間で扱うデータを相互に隔離（Isolation）しなければならない。このデータの隔離（分離）にはロックが有効である。トランザクションが更新の可能性を持ってデータにアクセスした場合には、そのトランザクションは、そのデータ項目をロックし、必要な更新を行った後に、そのロックを解除する。トランザクションは、ロックされているデータにアクセスしようとすると、そのロックが他のトランザクションによって解除されるまで待機する。これにより、トランザクションの直列性を確保し、トランザクションに隔離性を与え、トランザクションの並列処理・分散処理が可能となる。
【０１０３】
トランザクション管理部１０２は、口座処理部１０や顧客情報管理部３０による処理をトランザクションとして実行させる。このトランザクションは、原子性、一貫性、隔離性、耐久性のＡＣＩＤ特性を有する。口座の開設や、印鑑票番号の登録や、改印や、移管は、ＣＩＦマスター５には登録したが、預金マスター８には登録していないという状況が許されない。このため、開設処理や、移管処理等は、ＡＣＩＤ特性を有する一つのトランザクションとして実行すべきである。一方、ＣＩＦマスターは顧客情報管理部３０によって管理され、また、各種の預金マスターは口座処理部１０によって管理される。顧客情報管理部３０が直接預金マスターを更新するような仕組みは、プログラム実行の安全性の観点から避けるべきであり、このため、口座処理と顧客情報管理処理とは別個のプログラムとして開発される。
【０１０４】
この別個のプログラムとして開発されるものを、１つのトランザクションに包み込む手法として、上述した連動処理がある。連動起動処理は、プログラムの実行中にプログラムの名称（オペコード）を指定して連動受動処理を起動する。連動起動処理は、連動起動メッセージ中に口座番号等の各種のパラメータを付随させる。連動受動処理は、その処理結果を連動戻りブロックという連動起動処理と連動受動処理とで共有するメモリ領域に格納する。この連動戻りブロックのレイアウトを共通にし、また連動起動及び連動受動の際のメモリの使い方を定義する編集定義等を整理することで、口座処理を実行するプログラムは顧客情報管理を実行するプログラムの詳細を検討せずに、編集定義や連動戻りブロックのレイアウトに従って値の受け渡しを行うことができる。例えば、顧客情報管理部３０から普通預金プログラムや、定期預金プログラムへ残高照会を行う場合には、連動戻りブロックのレイアウトを予め定められたレイアウトとすることで、普通用金プログラムや定期預金プログラムの詳細を検討することなく、顧客情報管理部３０の開発を行うことができる。そして、トランザクション管理部１０２が、連動起動処理と連動受動処理とを１つのトランザクションとして管理することで、口座処理と顧客情報管理処理とを別個に開発しつつも、一体化した処理とすることができる。
【０１０５】
また、オペコードとプログラムコードとを関連させるときに、そのオペコードが通常の端末１からのオンライントランザクションとして起動されたのか、または連動受動処理として起動されたかの相違に基づいて、基本的な処理を同一としながら、連動戻りブロックの利用などのプログラム間のインタフェースを変化させることができる。すると、オペコードで特定される基本的な処理内容については、通常の起動と、連動受動処理としての起動とで共通にすることができる。これにより、プログラムコードの行数を大幅に削減することができる。
【０１０６】
図１６に示す例では、移管制御部１００が、移管元の口座番号（旧口座番号）の指定による移管処理要求を受信し、移管先の口座番号（新口座番号）を採番した後に、口座開設トランザクション（Ｓ９６）を、連動処理として、新旧の口座番号を指定して起動する新口座開設起動機能１０６を備えている。口座処理部１０は、口座開設トランザクション（Ｓ９６）を実行する。移管制御部１００又は移管制御部用のプログラムには、口座の開設を行うためのコードを含めない。ここでは、口座処理部１０に口座開設トランザクションを実行させるための連動起動処理を行う。口座処理部１０は、口座開設処理機能１１６による口座開設トランザクション（Ｓ９６）を実行する。口座開設トランザクション（Ｓ９６）では、まず、預金マスター８に新たな口座番号での口座を登録する。そして、旧口座の各種の情報を新口座に登録する。例えば、旧口座の口座残高や自動振替の契約等を新口座に移す。
【０１０７】
また、移管制御部１００は、顧客情報管理部３０による印鑑票番号登録トランザクション（Ｓ９８）を、連動処理として、移管元の口座番号と開設された口座番号とを指定して起動する印鑑票番号登録起動機能１０８を備えている。顧客情報管理部３０は、印鑑票番号登録機能１１８による印鑑票番号登録トランザクション（Ｓ９８）として、例えば図１１等に示す印鑑票番号の登録処理を行う。すなわち、顧客情報管理部３０は、移管元の口座に関連してＣＩＦマスター５に登録された一又は複数の印鑑票番号を、移管先の口座に関連した印鑑票番号としてＣＩＦマスター５に登録する。例えば、印鑑票セグメント６６に格納された口座番号を新口座番号に更新する。取引店セグメント６２や、口座明細セグメント６４の場合には、店番口座番号の変更によってキーが変化するため、新しい取引店セグメント６２や、新しい口座明細セグメント６４を作成し、旧セグメントの印鑑票番号を新しいセグメントに格納する。
【０１０８】
そして、移管制御部１００は、口座処理部１０による口座解約トランザクションＳ１００を、連動処理として、移管元の口座番号を指定して起動する旧口座解約起動機能１１０を備えている。口座処理部１０は、口座解約処理機能１２０による口座解約トランザクション（Ｓ１００）として、移管元の口座解約処理を行う。例えば、口座振替が設定されている場合には新しい口座番号への変更の登録や、移管元の口座をあて名として振込があった場合の資金移動先となる移管先の口座番号を預金マスター８に登録する処理を行う。
【０１０９】
移管制御部１００は、さらに、顧客情報管理部３０による印鑑票番号の抹消トランザクション（Ｓ１０２）を、連動処理として、移管元の口座番号を指定して起動する印鑑票番号抹消起動機能１１２を備えている。顧客情報管理部３０は、抹消機能１２２による抹消トランザクション（Ｓ１０２）として、印鑑票番号の抹消処理を行う。この処理は、移管元の口座番号の口座明細セグメント６４の使用を不可とする処理である。例えば、各部１００，１０，３０がセグメントの削除を行わず、再編成処理時にのみセグメントの削除を行う例では、ＣＩＦマスター５の各セグメントに使用可否フラグを設ける。そして、この抹消処理（Ｓ１０２）では対象セグメントの使用可否フラグをＯＦＦ（不可）に設定する。印鑑票の照合時には、使用可否フラグがＯＦＦであるセグメントの印鑑票番号は使用しない。再編成処理では、使用可否フラグがＯＦＦであるセグメントを削除する。また、顧客情報管理部３０が直接セグメントの削除を行う場合には、この抹消処理は該当するセグメントの削除となる。この印鑑票番号の抹消処理を行うことで、移管元の口座での照会があっても、印鑑票データを端末に表示することがない。
【０１１０】
また、移管制御部１００が、移管トランザクションの開始時に預金マスター８の移管元の口座情報をロックする移管元口座情報ロック制御機能１０４を備えるとよい。移管制御部１００によって、図１６に示す口座処理部１０及び顧客情報管理部３０の機能１１６，１１８，１２０，１２２はＡＣＩＤ特性を満たす一つのトランザクションとして実行される。このため、移管元口座情報ロック制御機能１０４が、移管対象の口座やＣＩＦデータをロックしてから当該各機能を実行させると、移管処理が完了するまでは並行して実行される他のトランザクションによって預金マスター８等の内容が変更される可能性がなくなる。
【０１１１】
このような移管処理は、顧客の要望による取引店の変更だけでなく、店舗の統廃合によって店番が変更する場合に生じる。従って、店舗統廃合による移管処理では、１支店の全口座について処理する必要がある。このため、本実施例では、この移管処理を連続して処理する仕組みを構築している。この例では、移管制御部１００が、移管の一括処理要求を受信した場合には、移管トランザクションを口座毎にＡＣＩＤ特性を有するトランザクションとして移管元の口座又はＣＩＦ番号が一定数となるまで繰り返し起動させる一括処理制御機能１１４を備えている。
【０１１２】
移管の一括処理要求は、バッチ処理を日中に処理する仕組みであるセンター一括処理である。また、口座振替を勘定日前に先日付で処理する先日付完結処理（例えば、特願２０００−２４２３４０号）を採用する場合には、この移管処理は先日付の残高明細が無いことを確認してから処理すると良い。例えば、先日付の振替は全て取消、移管後に移管先の口座で振替を実行する。
【０１１３】
図１７は、本実施例による口座移管処理の一例を示すフローチャートである。トランザクション制御部１０２は、移管の一括処理要求を受信した場合には、移管元の口座情報や口座名義人のＣＩＦデータをロックし、他のトランザクションから隔離する制御をする（ステップＳ９１）。そして、口座処理部１０及び顧客情報管理部３０は、移管元口座情報等をロックする（ステップＳ９２，Ｓ９３）。続いて、移管処理部１００は、移管先の新口座番号を採番し、続いて、新口座開設処理を連動処理として起動する（ステップＳ９５）。口座処理部１０は、連動受動処理である口座開設トランザクションを実行し（ステップＳ９６）、連動受動処理を完了する。続いて、移管処理部１００は、印鑑票番号登録処理を連動処理として起動する。顧客情報管理部３０は、印鑑票番号登録トランザクションを実行する（ステップＳ９８）。このとき、ＣＩＦマスター５に、移管元の旧口座の取引店セグメント６２が格納されている場合には、移管先の取引店での取引店セグメント６２を作成し、移管元の取引店セグメント６２に格納された印鑑票番号等を、移管先の取引店セグメント６２に格納する。移管元の旧口座の口座明細セグメント６４が格納されている場合には、移管先に開設した新口座番号での口座明細セグメント６４を作成し、移管元の口座明細セグメントに格納された印鑑票番号等を、移管先の口座明細セグメントに格納する。印鑑票セグメント６６については、移管元の口座番号を移管先の口座番号へ変更し、更新する。
【０１１４】
図１８は、移管処理での印鑑票番号登録トランザクション（Ｓ９８）によるＣＩＦマスター５の更新例を示す説明図である。図１８に示す例では、各セグメントは使用可否フラグを有する。この例では、移管元の口座番号は、店番210、口座番号123-XXXであり、口座明細セグメント６４Ｂに印鑑票番号100-000-201が格納されているとする。印鑑票番号登録トランザクション（Ｓ９８）は、移管先の新しい店番211で口座番号XX4-57Cの口座明細セグメント６４Ｃを作成し、当該移管元の口座に定義された印鑑票番号100-000-201を格納する。そして、移管元の口座明細セグメント６４Ｂについては、その使用可否フラグをＯＦＦとすることで抹消を行う。また、当該口座に代理人印があり、印鑑票セグメント６６Ｆが格納されていた場合には、新しい口座番号XX4-57Cでの印鑑票セグメント６６Ｆを更新し、代理人印の印鑑票番号100-000-202を登録する。
【０１１５】
個別印を例としたが、共通印の場合にも、例えば、印鑑票番号登録トランザクション（Ｓ９８）は、移管元の口座明細セグメントの取引店共通印フラグがＯＮの場合には、当該口座については取引店共通印を使用するため、移管先の店番での取引店セグメント６２を作成し、印鑑票番号を格納する。そして、移管先の新しい店番で新しい口座番号での口座明細セグメント６４の取引店共通印フラグをＯＮとする。
【０１１６】
続いて、図１７を参照すると、移管処理部１００は、旧口座の解約処理を、連動処理として、旧口座番号を指定して起動する（ステップＳ９９）。口座処理部１０は、旧口座解約トランザクションを連動受動処理として実行する（ステップＳ１００）。さらに、移管処理部１００は、旧口座の印鑑票番号の抹消処理を連動トランザクションとして起動する（ステップＳ１０１）。すると、顧客情報管理部３０は、旧口座の印鑑票番号を抹消する処理を行う（ステップＳ１０２）。抹消処理は、例えば、使用可否フラグをＯＦＦにして、当該セグメントの再編成を待つ。また、口座明細セグメントを削除してもよい。
【０１１７】
移管処理部１００は、１つの口座番号についての移管処理が完了すると、トランザクション制御部１０２に処理を戻す（ステップＳ１０３）。トランザクション制御部１０２では、連続処理によって、次の口座又は次のＣＩＦ番号を指定してステップＳ９１から処理を再開する。
【０１１８】
本実施例では、口座番号を印鑑票番号とするのではなく、特別な印鑑票番号を口座番号とは別に採番し、この印鑑票番号に基づいて印鑑票データを印鑑票データサーバー４Ａに格納する。そして、印鑑票番号と口座番号の関係については、ＣＩＦマスター５にて管理する。これにより、店舗の統廃合が生じても、印鑑票データのファイル名の付け替えや再編成処理を行う必要がなく、勘定系システムにて図１７に示す比較的高速な処理を実行するだけで移管を完了することができる。このため、店舗の統廃合が生じる場合でも、口座の取引を停止する期間を最大限短くすることができ、２４時間３６５日の運用となっても、夜間バッチ処理ではなく、日中のセンター一括処理によって移管を行うこともできる。
【０１１９】
図１６に示す構成及び図１７に示す処理を実現するには、所定の勘定系プログラムを勘定系システムのＣＰＵが実行すれば良い。この勘定系システム用プログラムは、移管制御部を動作させる指令として、下記の指令を備える。
移管元の口座番号の指定による移管処理要求を受信し、移管先の口座番号を採番した後に、口座開設トランザクション（Ｓ９６）を連動処理として起動させる新口座開設起動指令（Ｓ９１，機能１０６に対応）。
口座開設トランザクションＳ９６によって預金マスター８に新たな口座番号での口座が登録された後に、移管元の口座番号と開設された口座番号とを指定して顧客情報管理部３０による印鑑票番号登録トランザクションＳ９８を連動処理として起動させる印鑑票番号登録起動指令（Ｓ９７，機能１０８に対応）。
印鑑票番号登録トランザクションＳ９８によって移管元の口座に関連して前記ＣＩＦマスター５に登録された一又は複数の印鑑票番号を移管先の口座に関連した印鑑票番号としてＣＩＦマスター５に登録された後に、移管元の口座番号を指定して口座処理部１０による口座解約トランザクションＳ１００を連動処理として起動させる旧口座解約起動指令（Ｓ９９，機能１１０に対応）。
口座解約トランザクションＳ１００によって預金マスター８に移管元の口座の解約処理が行われた後に、移管元の口座番号を指定して顧客情報管理部３０による印鑑票番号の抹消トランザクションＳ１０２を連動処理として起動させる印鑑票番号抹消起動指令（Ｓ１０１，機能１１４に対応）。
【０１２０】
また、一括処理制御機能１４を実現するには、一括処理制御機能を実行するための一括処理制御指令を備えるようにすると良い。
【０１２１】
上述したように本実施例によると、口座番号と印鑑票番号とを関連させることで、印鑑票の登録、改印、照会、移管等を行うため、印鑑票登録の順序が限定されることなく、改印や移管等の口座情報の変更毎に印鑑照会システムでの番号の付け替え等のメンテナンスを行う必要がなく、また、改印の順序の保持や、ある口座についての印鑑票の表示順序の調整を容易とすることができる。特に、店舗統廃合による移管があった場合でも、印鑑票の番号の付け替えなどの印鑑票データサーバー側のメンテナンスを行う必要がない。
さらに、本実施例では、印鑑票データのファイル名に口座番号と無関係な印鑑票番号を採用し、且つ、この印鑑票番号と口座番号の関連付けをＣＩＦマスターで管理するため、全店共通印や取引店共通印の導入及び運用が容易で、これらの共通印の導入により顧客利便性を向上させつつ、事務取扱負担を増加させず、また、システム負荷も小さくすることができる。
また、好ましい実施例では、顧客情報管理部と口座処理部との連動処理によって移管等を行うため、プログラム全体の行数を少なくし、且つ、管理するマスター毎に別個の開発が可能となり、さらに、連動戻りブロックのレイアウトの共通化等により普通預金と定期預金の相違によらず顧客情報管理部側のプログラムを開発することができる。
【０１２２】
【発明の効果】
本発明は、印鑑票データのファイル名に口座番号と無関係な印鑑票番号を採用し、且つ、この印鑑票番号と口座番号の関連付けをＣＩＦマスターで管理するため、全店共通印や取引店共通印の導入及び運用が容易で、これらの共通印の導入により顧客利便性を向上させつつ、事務取扱負担を増加させず、また、システム負荷も小さくすることができる。そして、口座番号と印鑑票番号とを関連させることで、印鑑票の登録、改印、照会、移管等を行うため、印鑑票登録の順序が限定されることなく、改印や移管等の口座情報の変更毎に番号の付け替え等のメンテナンスを行う必要がなく、また、改印の順序の保持や、ある口座についての印鑑票の表示順序の調整を容易とすることができる。特に、店舗統廃合による移管があった場合でも、印鑑票の番号の付け替えなどの印鑑票データサーバー側のメンテナンスを行う必要がない。
【図面の簡単な説明】
【図１】図１は本発明の実施形態の構成例を示すフローチャートである。
【図２】図２は本実施形態による個人認証データの変更を登録する処理例を示すフローチャートである。
【図３】図３は、本実施形態による口座の移管処理例を示すフローチャートである。
【図４】図４は、本実施形態による勘定系システムの構成例を示すブロック図である。
【図５】図５は、本実施形態での勘定系システムでの口座開設制御方法の構成例を示すフローチャートである。
【図６】図６は、本実施例による印鑑照会システムの構成例を示すブロック図である。
【図７】図７は、本実施例によるＣＩＦマスターの詳細構成の一例を示す説明図である。
【図８】図８は、本実施例による印鑑票データの照会処理の一例を示すフローチャートである。
【図９】図９は、本実施例による印鑑票データの表示例を示す説明図であり、図９（Ａ）は印鑑票全体のイメージデータの表示例を示す図で、図９（Ｂ）は口座情報や登録されている印鑑票の種類及び数等の表示例を示す図で、図９（Ｃ）は印影イメージの詳細表示例を示す図である。
【図１０】図１０は、本実施例による勘定系システムでの印鑑票番号の登録制御及び改印制御を行う構成例を示すブロック図である。
【図１１】図１１は本実施例による印鑑票番号登録処理の一例を示すフローチャートである。
【図１２】図１２は、本実施例による勘定系システムでの口座開設処理の一例を示すシーケンス図である。
【図１３】図１３は、本実施例による勘定系システムでの印鑑票データの改印処理の一例を示すシーケンス図である。
【図１４】図１４は、改印処理によるＣＩＦセグメントの更新、作成例を示す説明図であり、図１４（Ａ）は共通印の改印処理の一例を示す図で、図１４（Ｂ）は当座勘定の個別印の改印処理の一例を示す図である。
【図１５】図１５は、代理人印の改印履歴を管理する印鑑票の改印処理によるＣＩＦセグメントの更新、作成例を示す説明図である。
【図１６】図１６は、本実施例による勘定系システムでの印鑑票データの口座移管制御を行う構成例を示すブロック図である。
【図１７】図１７は、本実施例による口座移管処理の一例を示すフローチャートである。
【図１８】図１８は、移管処理によるＣＩＦの各セグメントの変更例を示す説明図である。
【符号の説明】
１  端末
３  ネットワーク
４  個人認証データサーバー
４Ａ  印鑑票データサーバー
５  ＣＩＦマスター
６  データ通信制御部
８  預金マスター
９  キャッシュＤＢ
１０  口座処理部
３０  顧客情報管理部
５４  採番ＤＢ
【図１】
0003642421.tif 000002
【図２】
0003642421.tif 000003
【図３】
0003642421.tif 000004
【図４】
0003642421.tif 000005
【図５】
0003642421.tif 000006
【図６】
0003642421.tif 000007
【図７】
0003642421.tif 000008
【図８】
0003642421.tif 000009
【図９】
0003642421.tif 000010
【図１０】
0003642421.tif 000011
【図１１】
0003642421.tif 000012
【図１２】
0003642421.tif 000013
【図１３】
0003642421.tif 000014
【図１４】
0003642421.tif 000015
【図１５】
0003642421.tif 000016
【図１６】
0003642421.tif 000017
【図１７】
0003642421.tif 000018
【図１８】
0003642421.tif 000019