JP2007265227A - 口座情報の一括照会更新方法、口座情報の一括照会更新プログラム及び印鑑照会システム - Google Patents

Abstract

【課題】同一顧客の口座情報を一括で照会、更新できる方法、及びそのプログラム、並びに当該プログラムを用いた印鑑照会システムを得る。
【解決手段】店番、科目、及び顧客識別情報をキーにして、該当する口座情報をサーバが有するサーバ記憶手段より一括取得する口座情報取得ステップと、前記口座情報取得ステップで取得した１ないし複数の口座についての更新情報を受け付ける更新情報入力ステップと、前記更新情報入力ステップで受け付けたデータを基に、口座情報を一括更新するための更新処理用データを作成する更新データ作成ステップと、前記更新データ作成ステップで作成したデータをサーバに送信する更新データ送信ステップと、サーバが、口座情報の一括更新処理を行い、処理結果を前記サーバ記憶手段に格納するステップとを有することを特徴とする。
【選択図】図１

Description

本発明は、顧客が有する口座の口座情報を一括で照会または更新する方法及びそのプログラム、並びに印鑑照会システムに関するものである。

従来、口座情報を更新する手間を軽減する方法として、例えば『口座についての前記個人認証データを登録する時に、当該個人認証データを唯一に識別する個人認証データ番号を採番する個人認証データ番号採番工程Ｓ１と、口座の口座番号と当該口座番号についての個人認証データに採番された個人認証データ番号とを関連させる関連付け工程Ｓ２と、口座番号に基づいて個人認証データの照会があった場合には、当該口座番号に関連づけられた個人認証データ番号に応じて当該口座番号に対応する個人認証データを特定する個人認証データ特定工程Ｓ４とを備えた。』というものが提案されている（特許文献１）。
特開２００３−１６２６３３号公報（要約）

従来、金融機関の印鑑照会システムにおいては、顧客識別番号（顧客毎に一意に設定される管理番号、以下顧客コードと呼ぶ）で関連付けられる同一顧客の複数の印鑑データ等の口座情報を照会、更新する際には、個々の口座毎に、店番、科目、口座番号、枝番を逐一入力していた。
しかしながら、上述の方法では、同一の顧客が多数の口座を保持しているような場合には、顧客が住所を変更した際に、当該顧客が保持する全ての口座に対して上記オペレーションを繰り返す必要があり、オペレータの作業負荷が大きく、業務効率向上が難しいという課題があった。
そこで、同一顧客の口座情報を一括で照会、更新できる方法、及びそのプログラム、並びに当該プログラムを用いた印鑑照会システムが望まれていた。

本発明に係る口座情報の一括照会更新方法は、
顧客が有する口座の口座情報を一括で照会または更新する方法であって、
演算手段が、店番、科目、口座番号及び顧客識別情報をキーにして、該当する口座情報を、サーバが有するサーバ記憶手段より一括取得する口座情報取得ステップと、
前記演算手段が、前記口座情報取得ステップで取得した１ないし複数の口座についての更新情報を受け付ける更新情報入力ステップと、
前記演算手段が、前記更新情報入力ステップで受け付けたデータを基に、口座情報を一括更新するための更新処理用データを作成する更新データ作成ステップと、
前記演算手段が、前記更新データ作成ステップで作成したデータをサーバに送信する更新データ送信ステップと、
前記サーバが、前記演算手段が送信したデータを受け付け、当該データに基づいて、口座情報の一括更新処理を行い、処理結果を前記サーバ記憶手段に格納するステップと
を有することを特徴とするものである。

本発明に係る口座情報の一括照会更新方法によれば、
同一顧客が有する複数の口座情報の一括照会、更新が可能になり、これにより、多数の口座を有する顧客が住所変更などを行った際に、オペレータの作業負荷を低減でき、業務効率を向上させることができる。

実施の形態１．
図１は、本発明の実施の形態１に係る口座情報の一括照会更新方法を実現した印鑑照会システムの全体処理フローを説明するものである。
本実施の形態１の説明に際しては、まず図１で全体処理フローを説明し、その後にシステムの全体構成を説明した上で、個々のステップについて説明を加えることとする。
（Ｓ１０１）
本実施の形態１に係る印鑑照会システムのオペレータは、自身のＩＤとパスワードを照会端末の認証画面で入力する。その後、認証サーバは当該ＩＤとパスワードを照合し、結果を照会端末に返信する。
なお、詳細は後述の図３〜図７で説明する。
（Ｓ１０２）
オペレータは、照会端末を操作し、店番、科目及び顧客コードを入力して、該当する口座情報を印鑑ＤＢサーバに照会する。印鑑照会端末の演算手段は、オペレータが入力した店番、科目及び顧客コードをキーにして、該当する口座情報を、サーバが有するサーバ記憶手段より一括取得する。
なお、詳細は後述の図８〜図１２で説明する。
（Ｓ１０３）
ステップＳ１０２の結果、照会端末には、照会結果の口座情報が表示される。
オペレータは、照会端末を操作して更新内容を入力する。照会端末の演算手段は、オペレータの入力内容を受け付ける。
なお、詳細は後述の図１７〜図１８で説明する。
（Ｓ１０４）
照会端末の演算手段は、ステップＳ１０３でオペレータが入力した更新内容を基に、更新対象の口座情報を一括更新するための更新処理用データを作成する。
なお、詳細は後述の図１９及び図２１で説明する。
（Ｓ１０５）
照会端末の演算手段は、ステップＳ１０４で作成したデータを、印鑑ＤＢサーバに送信する。
なお、詳細は後述の図１９及び図２１で説明する。
（Ｓ１０６）
印鑑ＤＢサーバは、ステップＳ１０５で照会端末の演算手段が送信したデータを受け付け、当該データに基づいて、口座情報の一括更新処理を行い、処理結果を記憶手段に格納する。
なお、詳細は後述の図１９及び図２１で説明する。

図２は、本実施の形態１に係る印鑑照会システムの全体構成を説明するものである。
本実施の形態１に係る印鑑照会システムは、印鑑照会端末２０１、認証サーバ２０６、印鑑ＤＢサーバ２０７、印鑑登録端末２１３を有する。
印鑑照会端末２０１、認証サーバ２０６、印鑑ＤＢサーバ２０７及び印鑑登録端末２１３は、ネットワーク２１５で接続されている。
印鑑照会端末２０１は、営業店等に設置され、オペレータが口座情報の照会・更新操作を行うためのものであり、記憶手段２０２、演算手段２０３、表示手段２０４、入力手段２０５を有する。
記憶手段２０２は、図示しない口座情報の一括照会更新プログラムを格納しており、演算手段２０３は、一括照会更新プログラムの指示に基づき、口座情報の一括照会・更新処理を実行する。
印鑑ＤＢサーバ２０７は、サーバセンタに設置されており、サーバ記憶手段２０８を有する。
サーバ記憶手段２０８は、イメージファイルフォルダ２０９、オペレータ管理テーブル２１０、セッション管理テーブル２１１、口座テーブル２１２を格納している。
印鑑登録端末２１３は、サーバセンタに設置されており、顧客が口座を新規開設した際等に印影イメージ、署名イメージ、口座情報の登録などを行うためのものである。
スキャナ２１４は、印鑑登録端末２１３に接続されており、印影イメージや署名イメージを取り込むために用いられる。

ここで、本実施の形態１に係る印鑑照会システムの動作の理解を容易にするために、従来の口座情報の照会・更新シーケンスを、図２４を用いて説明する。

図２４は、従来の印鑑照会システムにおける、口座情報の照会・更新シーケンスを説明するものである。以下、個々のステップについて説明する。
（１）
以下のステップ（２）〜ステップ（９）の処理を、更新対象口座毎に繰り返す。
（２）
印鑑照会システムのオペレータは、更新対象口座の店番・科目・口座番号・枝番をシステムの画面上で入力して、更新対象口座を特定する。次に、更新内容を更新が面上で入力する。
（３）
照会端末の演算手段は、ステップ（２）でオペレータが入力した更新内容を基に、１件分の更新処理用データを作成する。
（４）〜（５）
照会端末の演算手段は、ステップ（３）で作成した更新処理用データを、印鑑ＤＢサーバに送信する。
（６）
印鑑ＤＢサーバは、イメージファイルフォルダ（もしくはデータベース内のバイナリフィールド）に格納されている、該当口座の印影イメージデータと署名イメージデータを更新する。
（７）
印鑑ＤＢサーバは、口座テーブルの該当口座の情報を更新する。
（８）
印鑑ＤＢサーバは、照会端末に更新結果を返信する。
（９）
照会端末は、更新結果を画面表示してオペレータに通知する。

以上のように、従来の印鑑照会端末では、オペレータは更新処理毎に店番・科目・口座番号・枝番をシステムの画面上で入力し、更新処理結果を画面で確認しなければならなかった。
以降では、図１の各ステップの詳細について説明する。

図３は、図１のステップＳ１０１において、オペレータが自身のＩＤとパスワードを入力する際に使用する画面の一例である。
本実施の形態１に係る印鑑照会システムのオペレータは、図３の画面を使用して、あらかじめ自身に割り当てられたＩＤとパスワードを入力し、図３の「ログイン」ボタンを押下する。
その後、オペレータが入力したＩＤとパスワードは、図２の認証サーバ２０６に送信され、認証サーバ２０６は当該ＩＤとパスワードが正当なものか否かを確認する。
認証処理の詳細は、後述の図６で説明する。

図４は、図２におけるオペレータ管理テーブル２１０の構成及びデータ例を説明するものである。以下、各列に付いて説明する。
「オペレータＩＤ」列は、図３の「オペレータＩＤ」欄に入力される文字列に対応するものである。本列の値と、図３の「オペレータＩＤ」欄に入力された値とが一致する場合には、オペレータが入力した「オペレータＩＤ」の値は正当なものとみなされる。
「パスワード」列は、図３の「パスワード」欄に入力される文字列に対応するものである。本列の値と、図３の「パスワード」欄に入力された値とが一致し、かつ上述の「オペレータＩＤ」の値が正当である場合には、オペレータが入力した「オペレータＩＤ」と「パスワード」の組は、正当なものとみなされる。
「オペレータＩＤ」と「パスワード」の組が正当なものであれば、そのオペレータは正当なＩＤとパスワードを割り当てられた者であるとみなされるので、以後の操作を継続できる。
「オペレータ氏名」は、該当するオペレータの氏名等を格納する列である。本列の値は認証処理には直接の関係はないが、オペレータ識別の便宜上設けられたものである。

図５は、図２におけるセッション管理テーブル２１１の構成及びデータ例を説明するものである。以下、各列について説明する。
「セッションＩＤ」列は、認証完了後の照会端末に一意に割り当てられる識別文字列である。詳細は後述の図６〜図７で説明する。
オペレータＩＤは、上記「セッションＩＤ」列の値を割り当てられたオペレータの「オペレータＩＤ」の値である。
「ログイン日時」は、認証処理が完了した日時を表すものである。
「有効期限」は、当該「セッションＩＤ」の有効期限を表し、この期限を過ぎたセッションＩＤは無効となる。セッションＩＤが無効となった後もシステムの操作を継続する場合は、再度の認証処理を要する。本列の値は、通常の業務時間に合わせて設定し、例えば「ログイン日時」から８時間などに設定すればよい。

図６は、図１のステップＳ１０１における詳細処理シーケンスを説明するものである。以下、各ステップについて説明する。
（１）
印鑑照会システムのオペレータは、図３の画面を使用して、自身に割り当てられたＩＤとパスワードを入力する。
（２）
印鑑照会端末２０１の演算手段２０３は、ステップ（１）でオペレータが入力したＩＤとパスワードを認証サーバ２０６に送信する。
（３）
認証サーバ２０６は、ステップ（２）で演算手段２０３が送信したＩＤ／パスワードの組をキーにして、オペレータ管理テーブル２１０を検索する。
（４）
認証サーバ２０６は、ステップ（３）の検索の結果を受けて、該当するＩＤ／パスワードの組がオペレータ管理テーブル２１０に存在するか否かを判断する。
該当する組が存在しなければ、そのＩＤ／パスワードの組は正当でない旨を印鑑照会端末２０１に返信する。
該当する組が存在すれば、ステップ（５）に進む。
（５）
認証サーバ２０６は、一意のセッションＩＤを生成する。
（６）
認証サーバ２０６は、ステップ（５）で生成したセッションＩＤとオペレータＩＤの組を、セッション管理テーブル２１１に格納する。
（７）
認証サーバ２０６は、ステップ（５）で生成したセッションＩＤを、印鑑照会端末２０１に返信する。

図７は、図６で示す認証処理の完了後、オペレータが印鑑照会端末２０１を操作して処理を行う際の詳細処理シーケンスを示すものである。
本実施の形態１に係る印鑑照会システムにおいては、オペレータが印鑑照会端末２０１を操作して処理を行おうとする際には、ＩＤとパスワードの入力が求められる。しかし、都度の処理毎にＩＤとパスワードの入力を求められるのは、オペレータにとって煩雑に耐えない。
そこで、一旦認証処理を完了した後は、システムからログオフ等するまでの間は再度ＩＤとパスワードを入力しなくても済むことが望ましい。
上記を実現するため、本実施の形態１に係る印鑑照会システムでは、図４と図５に示すテーブルを用いて、セッション認証を実現している。
以下、図７の各ステップについて説明する。

（１）
オペレータは、印鑑照会端末２０１を操作して、処理要求を発行する。
（２）
印鑑照会端末２０１の演算手段２０３は、図６のステップ（７）で認証サーバから受け取ったセッションＩＤを、印鑑ＤＢサーバ２０７に送信する。
（３）
印鑑ＤＢサーバ２０７は、ステップ（２）で受け取ったセッションＩＤをキーにして、セッション管理テーブル２１１を検索する。
（４）
印鑑ＤＢサーバ２０７は、ステップ（３）の検索の結果を受けて、該当するセッションＩＤがセッション管理テーブル２１１に存在するか否かを判断する。
該当する組が存在しなければ、システムに正当にログインしていない旨を印鑑照会端末２０１に返信する。
該当するセッションＩＤが存在すれば、ステップ（５）に進む。
（５）
印鑑ＤＢサーバは、ステップ（１）でオペレータが要求した処理を実行する。
（６）
印鑑ＤＢサーバは、ステップ（５）の処理結果を印鑑照会端末２０１に返信する。

図８は、図１のステップＳ１０２で、オペレータが印鑑照会端末２０１を操作して、口座情報を印鑑ＤＢサーバ２０７に照会する際に使用する画面である。
オペレータは、図８の画面で、対象口座の店番、科目及び顧客コードを入力し、口座情報の照会を行う場合は「印鑑照会処理」ボタンを、口座情報の更新を行う場合は「口座データ更新処理」ボタンを押下する。
「印鑑照会処理」ボタン押下時の詳細処理シーケンスについては、後述の図１１で説明する。「口座データ更新処理」ボタン押下時については、後述の図１６で説明する。

図９は、口座テーブル２１２のテーブル構成及びデータ例を説明するものである。以下、各列について説明する。
「顧客コード」列は、顧客を一意に識別するために内部的に付与されたＩＤであり、オペレータが図８の画面で入力する「顧客コード」に対応する。
「口座番号」列は、当該顧客が保有する口座の口座番号である。
「店番」列は、当該口座の店舗番号であり、オペレータが図８の画面で入力する「店番」に対応する。
「科目」列は、顧客の口座の口座種別（普通預金口座／当座預金口座）のことであり、オペレータが図８の画面で入力する「科目」に対応する。
その他の列については、本実施の形態１の動作説明とは関連しないため、説明を省略する。
図９のデータ例においては、１行目のデータと３行目のデータは「顧客コード」が同一であるため、同一顧客が有する口座であることを示している。

図１０は、サーバ記憶手段２０８が格納しているイメージファイルフォルダ２０９の内容を説明するものである。
イメージファイルフォルダ２０９は、印影・署名を記した書面をスキャナ２１４で読み込んだ画像ファイルを、顧客毎に格納している。
図１０に示す例は、「顧客コード」が「１２３４５６」である顧客の画像ファイルを格納したフォルダを開いている様子である。図１０に示す通り、顧客コードを３桁で区切って階層フォルダを構成して顧客毎にフォルダを割り当て、顧客毎のフォルダには画像ファイルが格納されている。画像ファイルには、＜口座番号＞＿印影．ｐｎｇもしくは＜口座番号＞＿署名．ｐｎｇという規則でファイル名が付けられている。
上記のように構成することで、「顧客コード」と「口座番号」を特定すれば、該当する画像ファイルの格納位置を特定することができる。

なお、ファイル及びフォルダ構成は図１０に示すものに限るものではなく、顧客毎の画像ファイルが特定できれば、任意の構成を取ることができる。
また、画像ファイルの形式も任意である。

図１１は、図１のステップＳ１０２で、印鑑照会端末２０１の演算手段２０３が、オペレータが入力した店番、科目、口座番号及び枝番をキーにして、該当する口座情報を、サーバが有するサーバ記憶手段２０８より一括取得する際の詳細処理シーケンスを説明するものである。以下、各ステップについて説明する。
（１）
オペレータは、図８の画面を使用して、一括取得対象口座の店番、科目、顧客コードを入力し、「印鑑照会処理」ボタンを押下する。
（２）
印鑑照会端末２０１の演算手段２０３は、ステップ（１）でオペレータが入力した店番、科目、顧客コードを、印鑑ＤＢサーバ２０７に送信する。
（３）
印鑑ＤＢサーバ２０７は、ステップ（２）で印鑑照会端末２０１が送信した店番、科目、顧客コードをキーにして、口座テーブル２１２を検索する。
（４）
印鑑ＤＢサーバ２０７は、ステップ（３）の検索結果として、該当する口座情報を口座テーブル２１２より一括取得する。
（５）
印鑑ＤＢサーバ２０７は、ステップ（２）で印鑑照会端末２０１が送信した顧客コードをキーにして、イメージファイルフォルダ２０９を検索する。
（６）
印鑑ＤＢサーバ２０７は、ステップ（５）の検索結果として、該当する口座の印影イメージファイルと署名イメージファイルを一括取得する。
（７）
印鑑ＤＢサーバ２０７は、ステップ（４）とステップ（６）で取得した検索結果を基にして、印鑑照会端末２０１に返信するデータを作成する。データ構成については、図１２で説明する。
（８）
印鑑ＤＢサーバ２０７は、ステップ（７）で作成したデータを印鑑照会端末２０１に一括送信する。

図１２は、図１１のステップ（２）で印鑑照会端末２０１が送信するデータと、ステップ（８）で印鑑ＤＢサーバ２０７が送信するデータの構成を説明するものである。

図１２の左図は、図１１のステップ（２）で印鑑照会端末２０１が送信するデータの構成を説明するものである。
「Ｄ１−１」のブロックには、図８の画面でオペレータが入力した「店番」の値が格納されている。
「Ｄ１−２」のブロックには、図８の画面でオペレータが入力した「科目」の値が格納されている。
「Ｄ１−３」のブロックには、図８の画面でオペレータが入力した「顧客コード」の値が格納されている。

図１２の右図は、図１１のステップ（８）で印鑑ＤＢサーバ２０７が送信するデータの構成を説明するものである。
「Ｄ２−０」のブロックには、口座データの取得が成功したか否かを示す内容が格納されている。
「Ｄ２−１−１」のブロックには、取得した１番目の口座データの店番／科目／口座番号／枝番コードが格納されている。これは、口座テーブル２１２の各列の値に該当する。
「Ｄ２−１−２」のブロックには、取得した１番目の口座データの予約コード／解約コードが格納されている。これは、口座テーブル２１２の「予約状態」列の値と「解約状態」列の値に該当する（図９参照）。
「Ｄ２−１−３」のブロックには、図１１のステップ（６）で取得した１番目の口座の印影イメージファイルに相当するバイナリデータが格納されている。
「Ｄ２−１−４」のブロックには、図１１のステップ（６）で取得した１番目の口座の署名イメージファイルに相当するバイナリデータが格納されている。

以上の「Ｄ２−１−１」〜「Ｄ２−１−４」の一連のブロックは、１つの口座情報に相当し、これを１取得単位とする。
図１１のステップ（８）で印鑑ＤＢサーバ２０７が送信するデータには、上記１取得単位のデータが、該当する口座の数と同数含まれている。

図１３は、図１１のステップ（８）終了後、印鑑照会端末２０１に表示される画面の一例を示すものである。
口座テーブル２１２から取得した情報は、図１３の画面の右半面に表示されている。ここでは、図９の１行目のデータが表示されている。
イメージファイルフォルダ２０９から取得した印影イメージファイル及び署名イメージファイルに相当するデータは、図１３の左半面「印」「口座太郎」と示している部分に表示されている。

また、画面下部には操作ボタンが配置されている。
「前口座表示」ボタンは、１つ前の画面で表示していた口座情報を表示するためのボタンであるが、初回表示時には前の画面がないため、押下できないようになっている。
「次口座表示」ボタンは、次の取得口座情報を表示するためのボタンである。
「最初に戻る」ボタンは、取得した口座情報が多数である場合に、最初に表示していた口座情報を簡単に表示できるように設けたボタンである。初回表示時は、現在表示している画面が最初の口座情報であるため、押下できないようになっている。
「キャンセル」ボタンは、図８の画面に戻る際に押下するボタンである。

図１４は、図１３の画面で「次口座表示」ボタンを押下した際の画面イメージを示すものである。
画面右半面には、図９の３行目のデータが表示されている。
また、図１３で押下できないようになっていたボタンが押下できるようになっている。

図１５は、図１１のステップ（３）において、印鑑ＤＢサーバ２０７が店番、科目、顧客コードをキーにして口座テーブル２１２より該当口座情報を取得する際のプログラムコードのサンプルである。以下、簡単に説明する。
（行番号１）
取得した１件分の口座情報を格納するためのオブジェクト「ｖＲｏｗ」を生成している。
（行番号２）
口座テーブル２１２に対して発行するＳＱＬ文を組立てている。
（行番号４）
ＳＱＬ文を実際に発行し、結果をオブジェクト「ｒｓ」に受け取っている。
（行番号５）
取得した口座情報の件数分、繰り返し処理を行う。
（行番号７）
オブジェクト「ｒｓ」に格納されている１行分の口座情報のうち、各列の値を格納するためのオブジェクト「ｖＣｏｌｕｍｎ」を生成している。
（行番号８）
口座テーブル２１２の「顧客コード」列の値を格納している。
（行番号９）
口座テーブル２１２の「口座番号」列の値を格納している。
（行番号１０）
各列の値を格納したオブジェクト「ｖＣｏｌｕｍｎ」を１件分のデータとして、オブジェクト「ｖＲｏｗ」に格納している。

図１６は、オペレータが図８の画面で「口座データ更新処理」ボタンを押下した際の画面イメージを示すものである。
「口座データ更新処理」ボタンを押下すると、一括更新を行うか、逐次更新を行うかの選択肢が表示される。オペレータは、選択肢のいずれかを選択する。

図１７は、オペレータが図１６で「一括更新」を選択した際に表示される画面の一例を示すものである。
図１７の画面の構成は、画面下部の操作ボタンを除けば、図１３の画面構成とほぼ同様である。
オペレータは、図１７の画面を使用して、更新が必要な箇所のデータを入力する。これは、図１のステップＳ１０３での処理に該当する。
例えば「枝番」を変更する場合は、図１７の「枝番」欄の値を変更し、あるいは図示は省略しているが、顧客の住所や電話番号の欄の情報を変更する。ただし、検索キーとして用いた「顧客コード」「店番」「科目」については、変更しないものとする。

「前口座表示」ボタンは、１つ前の画面で表示していた口座情報を表示するためのボタンである。
「リスト表示」ボタンは、図１８の画面を表示するためのボタンである。
「次口座表示」ボタンは、次の取得口座情報を表示するためのボタンである。
「キャンセル」ボタンは、図８の画面に戻る際に押下するボタンである。
「更新実行」ボタンは、更新が必要なデータの入力が終了した後に押下し、印鑑ＤＢサーバに更新要求を発行するためのボタンである。
オペレータは、図１７の画面を使用して、必要な更新情報を入力し、最後に「更新実行」ボタンを押下する。

なお、印影イメージや署名イメージを更新する際には、更新後のイメージファイルをドラッグ＆ドロップするなどの操作によって、図１７に表示されているイメージを置き換える。

図１８は、図１７の「リスト表示」ボタンを押下した際に表示される画面イメージを示すものである。
図１８の画面は、図１７の右半面の主要項目を一覧表示するものである。オペレータは本画面でも更新内容を入力することができる。個々の明細情報を更新する場合は、図１８の「明細」ボタンを押下すれば、該当する口座情報が図１７のような画面で表示され、必要に応じて更新内容を入力する。
なお、「更新実行」ボタン押下時の動作は、図１７の画面と同様である。

図１９は、オペレータが図１７又は図１８で「更新実行」ボタンを押下した際の処理シーケンスを説明するものであり、図１のステップＳ１０４〜ステップＳ１０６の内容が含まれる。以下、各ステップについて説明する。
（１）
オペレータは、図１７又は図１８の「更新実行」ボタンを押下して、印鑑照会端末２０１に更新要求を通知する。
（２）
印鑑照会端末２０１の演算手段２０３は、オペレータが図１７又は図１８で入力した更新内容に基づき、更新処理用のデータを作成する。
本ステップは、図１のステップＳ１０４に相当する。
なお、更新処理用データの構成は、後述の図２２で説明する。
（３）
印鑑照会端末２０１の演算手段２０３は、ステップ（２）で作成した更新処理用のデータを、印鑑ＤＢサーバ２０７に送信する。
本ステップは、図１のステップＳ１０５に相当する。
（４）
印鑑ＤＢサーバ２０７は、ステップ（３）で受け取ったデータに、印影イメージと署名イメージが含まれる場合には、イメージファイルフォルダ２０９に格納されている該当イメージファイルを更新する。
ステップ（４）〜ステップ（６）は、図１のステップＳ１０６に相当する。
（５）
以下のステップ（６）は、ステップ（３）で演算手段２０３が送信した更新処理用データの全件に対して、繰り返し実行される。
ステップ（４）〜ステップ（６）は、図１のステップＳ１０６に相当する。
（６）
印鑑ＤＢサーバ２０７は、ステップ（３）で受け取ったデータを基に、口座テーブル２１２の該当する口座情報を更新する。
ステップ（４）〜ステップ（６）は、図１のステップＳ１０６に相当する。
（７）
印鑑ＤＢサーバ２０７は、更新処理結果を印鑑照会端末２０１に送信する。

図２０は、オペレータが図１６で「逐次更新」を選択した際に表示される画面の一例を示すものである。
図２０の画面の構成は、画面下部の操作ボタンを除けば、図１３の画面構成とほぼ同様である。
オペレータは、図２０の画面を使用して、更新が必要な箇所のデータを逐次入力する。これは、図１のステップＳ１０３での処理に該当する。

「キャンセル」ボタンは、図８の画面に戻る際に押下するボタンである。
「更新せず次口座」ボタンは、現在表示している口座情報の更新処理用データを作成せず、次の口座情報を表示するためのボタンである。
「更新後に次口座」ボタンは、現在表示している口座情報の更新処理用データを作成してから、次の口座情報を表示するためのボタンである。

オペレータは、図２０の画面を使用して、更新が必要な口座については更新内容を入力してから「更新後に次口座」ボタンを押下し、更新が必要ない口座については更新内容を入力せずに「更新せず次口座」ボタンを押下する。
図１８の画面においては、「更新実行」ボタン押下後に実際の更新処理が行われるようにしているが、図２０の画面においては、全ての取得口座情報について上記の処理を実行し終えると、自動的に更新処理が行われる。

図２１は、オペレータが図２０の画面で、全ての取得口座情報についての処理を終えた際に行われる詳細処理シーケンスを説明するものであり、図１のステップＳ１０４〜ステップＳ１０６の内容が含まれる。以下、各ステップについて説明する。
（１）
オペレータは、図１１の処理シーケンスで取得した全ての口座情報について、以下のステップ（２）の処理を実行する。
（２）
オペレータは、図２０の画面を使用して、更新が必要な口座の更新内容を入力し、「更新後に次口座」ボタンを押下する。更新が必要ない口座については、「更新せず次口座」ボタンを押下する。
（３）
印鑑照会端末２０１は、ステップ（２）でオペレータが「更新後に次口座」ボタンを押下した場合は、オペレータが入力した更新内容を基に、１件分の更新処理用データを作成する。
本ステップは、図１のステップＳ１０４に相当する。
なお、更新処理用データの構成は、後述の図２２で説明する。
（４）
オペレータがステップ（２）の処理を全ての取得口座に対して実行した後、印鑑照会端末２０１の演算手段２０３は、ステップ（３）で作成した更新処理用のデータを、印鑑ＤＢサーバ２０７に送信する。
本ステップは、図１のステップＳ１０５に相当する。
（５）
印鑑ＤＢサーバ２０７は、ステップ（４）で受け取ったデータに、印影イメージと署名イメージが含まれる場合には、イメージファイルフォルダ２０９に格納されている該当イメージファイルを更新する。
ステップ（５）〜ステップ（７）は、図１のステップＳ１０６に相当する。
（６）
以下のステップ（７）は、ステップ（４）で演算手段２０３が送信した更新処理用データの全件に対して、繰り返し実行される。
ステップ（５）〜ステップ（７）は、図１のステップＳ１０６に相当する。
（７）
印鑑ＤＢサーバ２０７は、ステップ（４）で受け取ったデータを基に、口座テーブル２１２の該当する口座情報を更新する。
ステップ（５）〜ステップ（７）は、図１のステップＳ１０６に相当する。
（８）
印鑑ＤＢサーバ２０７は、更新処理結果を印鑑照会端末２０１に送信する。

オペレータが図１８、図２０いずれの画面を使用した場合でも、最終的な更新要求は、全ての更新内容を入力し終えた後に印鑑ＤＢサーバ２０７に送信される。
これにより、更新結果を逐一画面表示しながら１件毎に更新内容を入力する必要がなくなるので、オペレータの作業負荷を低減でき、業務効率が向上する。
さらには、更新処理用データを一括して印鑑ＤＢサーバ２０７に送信するので、更新処理毎のトラフィックが発生せず、ネットワーク２１５や印鑑ＤＢサーバ２０７にかける負荷を低減できる。

図２２は、図１９のステップ（３）もしくは図２１のステップ（４）で印鑑照会端末２０１が送信するデータと、図１９のステップ（７）もしくは図２１のステップ（８）で印鑑ＤＢサーバ２０７が送信するデータの構成を説明するものである。

図２２の左図は、図１９のステップ（３）もしくは図２１のステップ（４）で印鑑照会端末２０１が送信するデータの構成を説明するものである。
「Ｄ３−０−１」のブロックには、更新する口座データの予約コード／解約コードが格納されている。これは、口座テーブル２１２の「予約状態」列の値と「解約状態」列の値に該当する（図９参照）。
「Ｄ３−０−２」のブロックには、更新する口座の印影イメージファイルに相当するバイナリデータが格納されている。
「Ｄ３−０−３」のブロックには、更新する口座の署名イメージファイルに相当するバイナリデータが格納されている。
以上の「Ｄ３−０−１」〜「Ｄ３−０−３」の一連のブロックは、全ての更新対象口座について共通のデータである。

「Ｄ３−１」のブロックには、図１８又は図２０の画面でオペレータが入力した、１口座分の店番／科目／口座番号／枝番コードの内容が格納されている。
これを１更新単位として、更新対象件数分のデータが、図２２の左図に示すデータには含まれている。

図２２の右図は、図１９のステップ（７）もしくは図２１のステップ（８）で印鑑ＤＢサーバ２０７が送信するデータの構成を説明するものである。
「Ｄ４−１」のブロックには、更新処理が成功したか否かを示す内容が格納されている。

以上のように、本実施の形態１に係る口座情報の一括照会更新方法によれば、
顧客が有する口座の口座情報を一括で照会または更新する方法であって、
演算手段が、店番、科目及び顧客識別情報をキーにして、該当する口座情報を、サーバが有するサーバ記憶手段より一括取得する口座情報取得ステップと、
前記演算手段が、前記口座情報取得ステップで取得した１ないし複数の口座についての更新情報を受け付ける更新情報入力ステップと、
前記演算手段が、前記更新情報入力ステップで受け付けたデータを基に、口座情報を一括更新するための更新処理用データを作成する更新データ作成ステップと、
前記演算手段が、前記更新データ作成ステップで作成したデータをサーバに送信する更新データ送信ステップと、
前記サーバが、前記演算手段が送信したデータを受け付け、当該データに基づいて、口座情報の一括更新処理を行い、処理結果を前記サーバ記憶手段に格納するステップと
を有するので、
同一顧客が有する複数の口座情報の一括照会、更新が可能になり、これにより、多数の口座を有する顧客が住所変更などを行った際に、オペレータの作業負荷を低減でき、業務効率を向上させることができる。

また、前記演算手段は、
前記更新情報入力ステップにおいては、前記更新情報を更新対象口座毎に逐次受け付け、もしくは全ての更新対象口座の前記更新情報を一括で受け付けて、
前記更新データ作成ステップにおいては、前記更新情報を逐次受け付けたか一括で受け付けたかを問わず、全ての更新対象口座についての前記更新処理用データを一括で作成するので、
オペレータは更新結果を逐一画面表示しながら１件毎に更新内容を入力する必要がなくなり、オペレータの作業負荷を低減でき、業務効率が向上する。

また、前記演算手段は、
前記更新データ送信ステップにおいては、前記更新データ作成ステップで作成したデータを一括でサーバに送信するので、
更新処理毎のトラフィックが発生せず、ネットワーク２１５や印鑑ＤＢサーバ２０７にかける負荷を低減できる。

また、上記に記載の演算手段の処理をコンピュータに実行させる一括照会更新プログラムにより、
上記の一括照会・更新処理を行う端末を、汎用的なコンピュータを用いて実装することができる。

また、本実施の形態１に係る印鑑照会システムによれば、
上記に記載の演算手段の処理を実行するプログラムを格納したクライアント端末と、
上記に記載のサーバとを有し、
前記クライアント端末と前記サーバはネットワークにより接続されているので、
物理的にはなれた営業店などからでも、ネットワーク２１５を介して一括照会・更新処理を行うことができる。

実施の形態２．
実施の形態１に係る印鑑照会システムは、サーバセンタに設置された認証サーバ２０６及び印鑑ＤＢサーバ２０７にて、集中して口座情報の管理を行うものであった。
本発明の実施の形態２に係る印鑑照会システムは、営業店でも口座情報等の管理を行うものである。

図２３は、本実施の形態２に係る印鑑照会システムの全体構成を説明するものである。
図２３の印鑑照会システムでは、実施の形態１における認証サーバ２０６の役割を兼ねた印鑑ＤＢサーバ２２１が営業店にも設置されている。
したがって、印鑑ＤＢサーバ２２１は、実施の形態１の図２におけるサーバ記憶手段２０８に相当する構成を有する。
即ち、印鑑ＤＢサーバ２２１はサーバ記憶手段２１６を有し、サーバ記憶手段２１６は、イメージファイルフォルダ２１７、オペレータ管理テーブル２１８、セッション管理テーブル２１９、口座テーブル２２０を格納している。

オペレータは、印鑑照会端末２０１を操作して、実施の形態１と同様に一括照会・更新処理を行う。処理シーケンス等も、実施の形態１と同様である。
ただし、処理は印鑑ＤＢサーバ２２１内で実行され、処理結果も印鑑ＤＢサーバ２２１が有するサーバ記憶手段２１６に格納される点が実施の形態１と異なる。

サーバ記憶手段２１６に格納されたデータは、夜間バッチなどでサーバセンタに送信され、印鑑ＤＢサーバ２０７が有するサーバ記憶手段２０８の内容が更新される。これにより、両者のデータは同期が保たれる。
このようにすることで、ネットワーク２１５の速度が遅い営業店などにおいても、実施の形態１と同様の一括照会・更新処理を行うことができる。

実施の形態１に係る口座情報の一括照会更新方法を実現した印鑑照会システムの全体処理フローを説明するものである。 実施の形態１に係る印鑑照会システムの全体構成を説明するものである。 ステップＳ１０１において、オペレータが自身のＩＤとパスワードを入力する際に使用する画面の一例である。 オペレータ管理テーブル２１０の構成及びデータ例を説明するものである。 セッション管理テーブル２１１の構成及びデータ例を説明するものである。 ステップＳ１０１における詳細処理シーケンスを説明するものである。 図６で示す認証処理の完了後、オペレータが印鑑照会端末２０１を操作して処理を行う際の詳細処理シーケンスを示すものである。 ステップＳ１０２で、オペレータが印鑑照会端末２０１を操作して、口座情報を印鑑ＤＢサーバ２０７に照会する際に使用する画面である。 口座テーブル２１２のテーブル構成及びデータ例を説明するものである。 サーバ記憶手段２０８が格納しているイメージファイルフォルダ２０９の内容を説明するものである。 図１のステップＳ１０２の詳細処理シーケンスを説明するものである。 印鑑照会端末２０１が送信するデータと、印鑑ＤＢサーバ２０７が送信するデータの構成を説明するものである。 図１１のステップ（８）終了後、印鑑照会端末２０１に表示される画面の一例を示すものである。 図１３の画面で「次口座表示」ボタンを押下した際の画面イメージを示すものである。 図１１のステップ（３）におけるプログラムコードのサンプルである。 オペレータが図８の画面で「口座データ更新処理」ボタンを押下した際の画面イメージを示すものである。 オペレータが図１６で「一括更新」を選択した際に表示される画面の一例を示すものである。 図１７の「リスト表示」ボタンを押下した際に表示される画面イメージを示すものである。 オペレータが図１７又は図１８で「更新実行」ボタンを押下した際の処理シーケンスを説明するものである。 オペレータが図１６で「逐次更新」を選択した際に表示される画面の一例を示すものである。 オペレータが図２０の画面で、全ての取得口座情報についての処理を終えた際に行われる詳細処理シーケンスを説明するものである。 印鑑照会端末２０１が送信するデータと、印鑑ＤＢサーバ２０７が送信するデータの構成を説明するものである。 実施の形態２に係る印鑑照会システムの全体構成を説明するものである。 従来の印鑑照会システムにおける、口座情報の照会・更新シーケンスを説明するものである。

符号の説明

２０１ 印鑑照会端末、２０２ 記憶手段、２０３ 演算手段、２０４ 表示手段、２０５ 入力手段、２０６ 認証サーバ、２０７ 印鑑ＤＢサーバ、２０８ サーバ記憶手段、２０９ イメージファイルフォルダ、２１０ オペレータ管理テーブル、２１１ セッション管理テーブル、２１２ 口座テーブル、２１３ 印鑑登録端末、２１４ スキャナ、２１５ ネットワーク、２１６ サーバ記憶手段、２１７ イメージファイルフォルダ、２１８ オペレータ管理テーブル、２１９ セッション管理テーブル、２２０ 口座テーブル、２２１ 印鑑ＤＢサーバ。

Claims (5)

1. 顧客が有する口座の口座情報を一括で照会または更新する方法であって、
   演算手段が、店番、科目及び顧客識別情報をキーにして、該当する口座情報を、サーバが有するサーバ記憶手段より一括取得する口座情報取得ステップと、
   前記演算手段が、前記口座情報取得ステップで取得した１ないし複数の口座についての更新情報を受け付ける更新情報入力ステップと、
   前記演算手段が、前記更新情報入力ステップで受け付けたデータを基に、口座情報を一括更新するための更新処理用データを作成する更新データ作成ステップと、
   前記演算手段が、前記更新データ作成ステップで作成したデータをサーバに送信する更新データ送信ステップと、
   前記サーバが、前記演算手段が送信したデータを受け付け、当該データに基づいて、口座情報の一括更新処理を行い、処理結果を前記サーバ記憶手段に格納するステップと
   を有することを特徴とする口座情報の一括照会更新方法。
2. 前記演算手段は、
   前記更新情報入力ステップにおいては、前記更新情報を更新対象口座毎に逐次受け付け、もしくは全ての更新対象口座の前記更新情報を一括で受け付けて、
   前記更新データ作成ステップにおいては、前記更新情報を逐次受け付けたか一括で受け付けたかを問わず、全ての更新対象口座についての前記更新処理用データを一括で作成することを特徴とする請求項１に記載の口座情報の一括照会更新方法。
3. 前記演算手段は、
   前記更新データ送信ステップにおいては、前記更新データ作成ステップで作成したデータを一括でサーバに送信することを特徴とする請求項２に記載の口座情報の一括照会更新方法。
4. 請求項１ないし請求項３のいずれかに記載の演算手段の処理をコンピュータに実行させることを特徴とする口座情報の一括照会更新プログラム。
5. 請求項１ないし請求項３のいずれかに記載の演算手段の処理を実行するプログラムを格納したクライアント端末と、
   請求項１ないし請求項３のいずれかに記載のサーバとを有し、
   前記クライアント端末と前記サーバはネットワークにより接続されたことを特徴とする印鑑照会システム。
   

Images