JP2005222243A - 取引承認方法、取引承認プログラム、および取引承認装置 - Google Patents

Abstract

【課題】 銀行等金融機関の諸取引において、取引内容の承認要求が発生した時に、承認権限を有する役席者が確実、迅速に承認を実行できるように、承認権限の選定と権限保有承認者の抽出を自動化し、承認要求の通知を行う取引承認システムを提供する。
【解決手段】
本発明は、承認要求発生時に、該当取引を承認操作できる権限を承認必要理由、取引の実施条件から動的に判定し、それを充足するグレード権限を保有する役席者をログイン役席者の中から選別し、ヒットした役席対象者の端末位置を特定し、承認要求が発生していることを全対象者に同報メッセージ通知できる取引承認方法に関する。
【選択図】図１

Description

銀行等金融機関の諸取引において、取引内容の承認要求が発生した時に、承認権限を有する役席者が確実、迅速に承認を実行できるように、承認権限の選定と権限保有承認者の抽出を自動化し、承認要求の通知を行う取引承認システムを提供する。

資金を会社や個人に融資したりするような銀行等の取引業務においては、取引を決済するにあたって、その取引の規模に応じて、課長、部長、支店長等の職位の承認を得ることが日常的に行われており、その承認作業を複数人に回送する承認ワークフローによる承認システムも提案されている。

しかしながら、従来、電子的な承認システムを導入しているところでも以下のような問題があった。権限を保有する役席者を資格情報から特定し、該当役席者へ承認要求を突きつけるシステムは存在するが（例えば、特許文献１）、従来技術では、メッセージ表示先が固定化されていたり、権限保有者が端末位置を移動した場合に追跡する手段を持たない。また、取引の内容・事例に応じた承認操作権限をきめ細かく分類できなかったために、承認する役席者の保有するグレード権限を該当取引のリスクに応じて選定することが出来なかった。
特開２００２−２０３１１０号公報

このような問題に鑑み、本発明では、承認要求発生時に、該当取引を承認操作できる権限を承認必要理由、取引の実施条件から動的に判定し、それを充足する権限グレードを保有する役席者をログイン役席者の中から選別し、ヒットした役席対象者の端末位置を特定し、承認要求が発生していることを全対象者に同報メッセージ通知できることを特徴とする役席承認システムを実現する。承認要求が発生した時に、システムルール、リスクに応じた適切なグレードの役席者にリアルタイムに要求発生のメッセージ表示を可能とし、迅速な承認操作を促すことを目的とする。

第一の発明は、ネットワークを介してオペレータ端末および役席者端末とが接続される端末管理サーバにおける承認ワークフローの取引承認方法であって、承認要求が発生した際に、取引を承認操作できる権限をオペレータ端末より発せられた承認要求電文から承認必要理由または取引の実施条件を動的に抽出し取得する承認条件取得ステップと、役席者の保有する承認権限が取引内容に応じてグレードで定義された承認要否判定テーブルを参照し、前記承認条件取得ステップにおける承認必要理由および取引の実施条件にもとづいて、それら条件を満足する権限のグレードを検索する権限検索ステップと、前記権限検索ステップにおいて選別された権限のグレードを保有する役席者についてログイン情報テーブルを参照して現在の端末位置を特定し、該当する全対象者に前記承認要求の同報メッセージを通知するメッセージ通知ステップと、を有することを特徴とする取引承認方法に関する。

すなわち、第一の発明によれば、承認条件取得部が、オペレータ端末の承認要求者の発した承認要求電文から承認に必要な取引理由または取引を実施するための条件を自動抽出し、取引を承認操作できる権限を判断し、権限検索部が、取引内容に応じて定義された権限のグレードを保有する役席者が登録された承認要否判定テーブルを参照して、前記承認要求電文の取引条件に対応したグレード権限のある役席者を検索する。

そして、検索の結果ヒットした当該役席者に向けて、メール通知手段が、ログイン情報テーブルを参照して役席者が現在使用している端末を特定し、取引の承認要求に関する同報メッセージを通知する仕組みとしている。

役席者は、端末管理サーバが制御しうる当環境下において、どの店舗の、どの端末位置にいても、また端末位置を動的に変更しても、現在居るその場所において、ログインを実行すればリアルタイムで承認要求の発生を知ることができ、迅速な承認判定操作が可能となる。しいては、窓口顧客の待ち時間短縮につながる。

第二の発明は、前記権限検索ステップにおける承認要否判定テーブルでは、取引の内容または取引リスクの大きさにしたがって、役席者が保有する取引の承認権限が段階的な権限グレードとして定義され、登録されていることを特徴とする上記第一の発明に記載の取引承認方法に関する。

すなわち、第二の発明によれば、承認を必要とする取引の内容、あるいは金額、信用度等のリスクの大きさにしたがって、承認者が保有する権限グレードが定義されているため、客観的で適切な承認者の自動選定が本システムによって実現される。

上記してきた本発明によれば、以下の通りの効果が得られる。

承認対象取引の内容、リスクに応じた承認者の権限を、定義しておくことにより、適切な承認者の選定がシステムで自動化される。また、役席者はサーバ配下の、どの店舗の、どの端末位置にいても、また端末位置を動的に変更してもログオンすればリアルタイムに承認要求の発生を知りうる事が可能で、迅速な承認判定操作が可能となる。さらに、窓口顧客の待ち時間短縮につながる。

以下、図面にもとづいて本発明の実施形態を説明する。

図１は、本発明の実施の形態になる基本システムの構成例を示す。本発明の営業店における取引承認システムは、承認要求者が利用するオペレータ端末１、承認権限を保有する役席者の利用する役席者端末２、およびこれら端末を管理し取引承認のワークフローを制御する端末管理サーバ３が、ＬＡＮ４（ローカルエリアネットワーク）で互いに接続され、さらに、ネットワーク５を介して、センタに配備され、営業店で成立した取引を実行するホスト６と接続している。

図２は、本発明の実施の形態になる営業店システムにおける機能構成例を示す。承認ワークフローで、承認権限を保有する役席者に承認要求等を行う一般のオペレータが利用するオペレータ端末１は、図には示していないが、キーボード、ディスプレイ、入金伝票等の読取を行うＯＣＲ（Optical Character Reader 光学読取機）等の入出力機器を制御する入出力制御部１１、取引の承認依頼等のジョブを制御する取引制御部１２、およびデータやメッセージ等を送受信する通信制御部１３とで構成される。

同様に、承認権限を保有する役席者が使用する役席者端末２は、キーボード、ディスプレイ等の入出力機器を制御する入出力制御部２１、オペレータからの要求に対し対象の承認ワークフローにおいて取引の承認を行う取引制御部２２、およびメッセージの送受信を行う通信制御部２３とで構成される。

端末管理サーバ３は、オペレータ端末１および役席者端末２とのデータおよびメッセージの送受信を行う通信制御部３１、 取引の承認要求するオペレータと承認権限を保有する役席者の複数人にわたる承認ワークフローを管理し、取引承認プログラム３２０を備えるワークフロー制御管理部３２、データベース（ＤＢ）へのデータの格納、該データの取り出しを管理する電子伝票ファイル制御管理部３３、電子伝票ファイルＤＢ１１０、ワークフロー管理テーブル１２０、およびログイン情報管理テーブル１３０が格納された記憶装置で構成される。

さらに、ワークフロー管理テーブル１２０には、取引格納情報テーブル１２１、承認要否判定テーブル１２２、ステージ遷移条件テーブル１２３が格納され、また、ログイン情報管理テーブル１３０には、有効登録者リスト１３１およびログイン情報登録テーブル１３２が格納されている。

また、ワークフロー制御管理部３２では、オペレータの承認要求電文から取引を承認する権限の条件を抽出する承認条件取得部３２１、承認要否判定テーブル１２２を参照して承認に必要な権限グレードを検索する権限検索部３２２、およびその権限グレードを保有する役席者をログイン情報登録テーブル１３２から特定して承認要求のメッセージを通知するメッセージ通知部３２３からなる取引承認プログラム３２０によって、取引承認のワークフローが実行される。

ここで、端末管理サーバ３は、通信制御部３１、ワークフロー制御管理部３２、電子伝票ファイル制御管理部３３、および電子伝票ファイルＤＢ１１０、ワークフロー管理テーブル１２０、ログイン情報管理テーブル１３０が記憶された記憶装置を備えたコンピュータであり、上記の各処理部は、該コンピュータ上であらかじめ内蔵されたプログラムが実行されることによって実現される。

また、オペレータ端末１／役席者端末２は、入出力制御部１１／２１、取引制御部１２／２２、および通信制御部１３／２３を備えたコンピュータであり、上記の各処理部は、該コンピュータ上であらかじめ内蔵されたプログラムが実行されることによって実現される。

なお、これら当該プログラムは、フレキシブルディスク、コンパクトディスク、ＲＯＭ等のコンピュータ読み取り可能な記録媒体に記録され、また、とくに、図には示していないが、内蔵あるいは外部接続された媒体読取装置にセットし、インストールすることによって実行可能な状態としてもよい。

以下に、本発明になる取引承認システムの概要を説明する。

図３は、本発明の実施の形態になる営業店システムにおけるデータの流れを示す。
１）オペレータ端末１において、取引の承認を要求するオペレータが承認要求電文を端末管理サーバ３に送信する。
２）端末管理サーバ３において、受信した当該承認要求電文から取引コードおよび取引データを取得して電子伝票ファイルＤＢ１１０に格納する。同時に、承認要求を受け付けた旨をオペレータ端末１に返信する。
３）端末管理サーバ３において、上記で取得した取引情報にしたがって、承認要否判定テーブル１２２を参照し、承認可能な承認者の権限グレードを検索する。

例えば、識別Ｎｏ２のケースでは、取引金額の大きさが判定され、３００万円未満の案件なら５０、１０００万円を超える案件であれば下限は８０となる。
４）端末管理サーバ３において、承認者ＩＤ、権限グレード、および端末ＩＤ等が格納されたログイン情報登録テーブル１３２を参照し、承認可能な権限グレードを保有する役席者を抽出し、端末位置を特定する。
５）端末管理サーバ３において、上記で抽出された権限グレードを保有する全対象の承認者あてに、承認要求の発生メッセージを同報通知する。

例えば、取引金額が１２００万円の場合であれば、承認要否判定テーブル１２２を参照し、８０以上の権限グレードを保有する承認者あてに、承認要求の発生メッセージが通知されることになる。
６）役席者端末２において、現在使用しているログイン端末にて、端末管理サーバ３からの承認要求の発生メッセージを受信した役席者は、取引の承認を行う。

図４は、本発明の実施の形態になる有効登録者リストの例を示す。有効登録者リスト１３１は、ログイン要求の正当性チェックのために必要とする情報テーブルであり、本テーブルに登録されているオペレータ／役席のみがログイン可能となる。

有効登録者リスト１３１は、「オペレータＩＤ」、オペレータの保有する「権限グレード」、役席者、一般等を区別する「資格種別」、「登録日」、登録の「有効期限」、「パスワード」、および「従業員登録Ｎｏ」の項目についての複数のレコードで構成されている。例えば、第一のレコードでは、オペレータＩＤ１００２１０００１は、権限グレード８０を保有する役席１で、２００１年１０月１１日に登録、有効期限は２００４年１０月１０日であることを示している。

図５は、本発明の実施の形態になるログイン情報登録テーブルの例を示す。

ログイン情報登録テーブル１３２は、「オペレータＩＤ」、オペレータの保有する「権限グレード」、役席者、一般等を区別する「資格種別」、使用端末の「登録時間」、使用端末の「店番号」、および「端末ＩＤ」の項目についての複数のレコードで構成されている。例えば、第一のレコードでは、オペレータＩＤ１００２１０００１は、権限グレード８０を保有する役席１で、店番号１００００１の端末ＩＤ１２３４５６７８に２００１年１０月１１日に登録していることを示している。

図６は、本発明の実施の形態になる取引格納情報テーブルの例を示す。取引格納情報テーブル１２１は、取引が取引画面として保有する項目情報を保持する。電子伝票ファイルＤＢ１１０に格納を行うときの管理データ情報として使用される。

取引格納情報テーブル１２１は、取引を特定する「取引コード」、オペレータ端末１において帳票をＯＣＲ（図示していない）で読み取り、その電子化データを一般のキャラクタデータおよびイメージデータとして格納する「項目識別」、帳票が保有する「保有項目ＩＤ」、そのキャラクタデータの「項目桁数」、および「項目属性コード」の項目についての複数のレコードで構成されている。

例えば、第一のレコードでは、Ａ０１００２１２３４の取引は、項目識別は一般（キャラクタ）で、保有項目ＩＤは０００１、項目の桁数は１０桁であることを示している。

図７は、本発明の実施の形態になる承認要否判定テーブルの例を示す。承認要否判定テーブル１２２は、取引が役席承認を必要とするか否か、また、承認が必要な場合の承認可能グレードを決定するための情報を保持する。取引コードのみでグレードが決定する場合と、取引の実施条件でグレードが決定できるような仕組みを持つ。

承認要否判定テーブル１２２は、取引を特定する「取引コード」、承認を必要とするか否かの「承認要否」、承認要否の判定を取引金額等の取引条件で判定するか否かの「承認要否判定条件」、また、判定条件ありとなった場合の「条件項目ＩＤ１」、「条件項目ＩＤ２」、「承認要否判定条件式」、および「承認可能グレード」の項目についての複数のレコードで構成されている。条件項目ＩＤ１は取引金額ＩＤであり、条件項目ＩＤ２は取引種別ＩＤである。なお、「承認要否」項目の「０」は承認要、「１」は取引条件によって決定することを意味している。

例えば、第一のレコードでは、Ａ０１００２１２３４の取引は、無条件に承認が必要であり、その承認可能なグレードは６０であることを示している。また、第二のレコードでは、取引条件によって承認要否が決定され、取引金額ＩＤを条件項目ＩＤ１とし、承認要否判定条件式は、
取引金額≦１００万円の場合、承認可能グレードは０で承認不要
取引金額＞１００万円の場合、承認可能グレードは６０の承認が必要
となることを示している。

図８は、本発明の実施の形態になるステージ遷移条件テーブルの例を示す。ステージ遷移条件テーブル１２３は、取引毎にワークフローのステージ遷移先の判定条件を保持し、各取引に応じたワークフローをコントロールするための情報を与えるものである。

ステージ遷移条件テーブル１２３は、「取引コード」、「ステージ０遷移条件」、「ステージ１遷移条件」、「ステージ２遷移条件」、「ステージ３遷移条件」、および「ステージ４遷移条件」の項目からなる複数のレコードで構成されている。

例えば、Ａ０１００２１２３４の取引は、ステージ０の遷移条件は、オペレータ端末１からの承認依頼によってステージ１に移行することを示し、端末管理サーバ３の電子ファイルＤＢ１１０に取引コードおよび取引情報が格納される。

ステージ１の遷移条件は、役席者によって承認キーが押下された場合、ステージ２に移行し、否認キーが押下された場合、ステージ３に移行する。また、ステージ２の遷移条件は、取引成立すればステージ４に移行し、取引不成立であればステージ３に移行となる。ステージ３の遷移条件は、完了キーが押下されたときにステージ１に戻り、つぎのジョブ待となり、取引キャンセルキーが押下されればステージ４に移行する。ステージ４では、遷移はなく、最終ステージであることを示している。

図９は、本発明の実施の形態になるステージ遷移の例を示す。本実施例では、取引コードＡ０１００２１２３４の取引におけるステージ遷移の様子を模式的に示したものである。

ステージ０は、承認依頼を受けてその取引情報を格納する状態、ステージ１は、取引が承認待の状態にあり、承認キーの押下によってステージ２へ、否認キーの押下でステージ３へと遷移する。ステージ２は、取引の実行待ちの状態にあり、取引成立によってステージ４へ、取引不成立であればステージ３に遷移する。また、ステージ３は、修正待ちの状態にあり、完了キーの押下でステージ１へ、取引キャンセルキーでステージ４に遷移する。ステージ４は、最終ステージとなる。

以下、本発明の取引承認システムの実施例の詳細に関し、まず、図１０、図１１のシステムデータフローを用いて端末サーバ３における処理フローおよびオペレータ端末１／役席端末２における表示画面のタイミングについて説明し、つぎに、図１２〜図１７を用いて端末管理サーバ３における取引承認処理のフローを、さらに、図１８〜図２３を用いて各端末における表示画面の例を説明する。

図１０は、本発明の実施の形態になる取引承認のシステムデータフローを示す。本実施例のシステムデータフローの中に示した承認処理フロー（図１２〜図１７）および表示画面例（図１８〜図２３）の詳細については、後に詳述する。
１）オペレータ端末１において、クライアントによって、例えば、普通入金の取引が選択され、普通入金取引の初期画面（図１８）にて、完了ボタンが押下されると、取引実施依頼通知が端末管理サーバ３に送信される。それを受けて、端末管理サーバ３では、取引のワークフロー管理テーブル１２０を参照し、取引コードで無条件に承認要否を決定するかあるいは取引の実施条件で決定するかの承認要否を自動判定し、その判定結果がクライアントに電文で取引依頼したクライアントに返送される（図１２−フロー１）。
２）オペレータ端末１において、自動表示されたコメント画面（図１９）において、クライアントは、承認依頼理由、特記事項等のコメントを入力して、管理端末サーバ３に承認依頼の入力情報を送信する。

管理端末サーバ３は、該承認依頼を受け、電子伝票ファイルＤＢ１１０に取引情報を格納処理し、依頼したクライアントに完了通知を発行する。同時に、ワークフロー管理テーブル１２０およびログイン情報管理テーブル１３０を検索して、ヒットした承認権限を保有する役席者全員に承認要求の同報メッセージを役席者端末２に送信する（図１３−フロー２）。そして、役席者端末２の表示画面には、承認要求発生のメッセージ画面（図２０）が表示される。
３）つぎに、役席者端末２では、承認取引要求画面（図２１）が表示され、役席者が、取り出したい案件を条件入力し、完了ボタンを押下することによって、該データが端末管理サーバ３に送信される。その取出依頼を受けて、端末管理サーバ３では、キー情報を取得して電子伝票ファイルＤＢ１１０を検索し、取引案件カウンタの処理を行って返送する（図１４−フロー３）。

その後、役席者端末２において、取出依頼した役席者によりコメント内容および取引内容の確認が行われる。
４）役席者端末２において、役席者によって取出案件が承認されると、該取引承認済の更新依頼が、端末管理サーバ３に送信される。端末管理サーバ３では、取引状態についての更新が行われ、承認依頼したクライアントに向け、オペレータ端末１に承認完了のメッセージ通知を行う（図１５−フロー４）。そして、オペレータ端末１には、システムメッセージ表示域に、承認完了メッセージが表示（図２２）される。

以上、仕掛中の取引が承認終了となった時点で、オペレータ端末１では、承認済取引の取出画面（図２３）にて受付通番や伝票の状態が表示され、クライアントによる取引の状態の確認を可能としている。

その後、オペレータ端末１においては、画面は復元モードとなり、取引の初期画面（図１８）に戻り復元表示される。また、媒体等セット状況の復元操作が行われ、オンラインでの取引実施依頼がオペレータＩＤを付与してセンタのホスト６に送信され、ホスト６にて取引実施処理が行われ取引成立となる。そして結果が媒体印字され排出される。以上のようなシステムデータフローが取引案件毎に繰返し行われる。

図１１は、本発明の実施の形態になるオペレータ／役席者の登録・削除のデータフローを示す。図では、オペレータ端末１と端末管理サーバ３の間のやりとりを示している。
１）オペレータ端末１において、オペレータ登録画面にて、オペレータＩＤおよびパスワードを入力し、承認キーを押下することで、端末管理サーバ３にオペレータ登録の依頼データを送信する。端末管理サーバ３では、該登録データを受け、図１７（フロー５）のフローによって登録依頼のクライアントに対する登録処理を行い、該クライアントへ登録の完了通知を行う。なお、役席者の登録処理も全く同様になされる。
２）オペレータ端末１において、オペレータ削除画面にて、オペ削除キー押下あるいはオペカードの抜き取り等を行うことによって、オレータ削除依頼のデータが端末管理サーバ３に送信される。端末管理サーバ３では、該削除依頼を受け、図１８（フロー６）のフローによって削除依頼のクライアントに対する削除処理を行い、該クライアントへ削除の完了通知を行う。なお、役席者の削除処理も全く同様になされる。

つぎに、図１２〜図１８を用いて承認処理フローを説明する。

図１２は、本発明の実施の形態になる端末管理サーバにおける承認処理フロー１（承認要否）を示す。まず、ステップＳ１１において、オペレータ端末１からの承認要求依頼の電文を受信し、要求依頼電文から承認を得るための依頼理由および取引条件に関する承認依頼情報を抽出する。つぎに、ステップＳ１２において、承認ワークフローにおける対象取引として、承認済か否かを判断する。承認作業が済んでいれば、ステップＳ１９に進み、センタのホスト６に対し、当該取引の実施依頼を行う。

ステップＳ１２で、ワークフローで承認作業が未だであれば、ステップＳ１３において、取引情報の取引コードをキーに承認要否判定テーブル１２２を参照し、取引条件判定にかけるか否かを判断する。

ステップＳ１４において、取引条件判定にかける必要がなければ、ステップＳ１８に進み、役席承認要の旨を承認要求しているオペレータ端末１に通知する。取引条件判定を必要とする取引であれば、ステップＳ１５において、取引格納情報テーブル１２１の条件項目ＩＤと項目情報をもとに、画面入力情報から該当する項目値を取得する。

そして、ステップＳ１６において、承認要否判定テーブル１２１で定義する条件式により、当該取引に承認が必要かを判断する。

ステップＳ１７において、承認が必要であれば、ステップＳ１８に進み、役席承認要の旨を承認要求のオペレータ端末１に返送する。また、承認の必要がなければ、ステップＳ１９で、センタのホスト６への取引実施依頼を行う。

図１３は、本発明の実施の形態になる端末管理サーバにおける承認処理フロー２（取引承認依頼格納）を示す。まず、ステップＳ２１において、オペレータ端末１より送信された承認依頼格納電文から取引情報を取得し、要求種別、取引コード、取引画面情報（項目値、伝票イメージ情報他）、検索キー等のデータを抽出する。

つぎに、ステップＳ２２で、取得データを新規取引案件として電子伝票ファイルＤＢ１１０に格納し、ステップＳ２３において、ステージ遷移条件テーブル１２３から該当取引のステージ遷移情報を取得し、初回のステージを設定する。ステップＳ２４において、サーバが保持している承認待ちステージ（初回ステージ）のカウンタを＋１にする。

ステップＳ２５において、依頼元のオペレータ端末１に格納処理が完了した旨の電文を通知し、ステップＳ２６で、全カウンタ情報を配下のクライアントに同報通知する。ステップＳ２７において、該当取引の承認要否判定テーブル１２２より当該取引の承認の権限グレードの決定方法を参照し、さらに、ステップＳ２８で、必要とされる権限は、取引条件にしたがって決定するか否かを判定する。

ステップＳ２８において、取引条件が判定に必要なら、ステップＳ２９で、承認要否判定テーブル１２２で定義している条件項目と条件判定式を取得し、ステップＳ３０で、取引情報より条件項目値を取得し、条件判定式にしたがって判定し、必要権限値を算定する。そして、ステップＳ３１で、ログイン情報登録テーブル１３２について権限値（権限グレード）をキーに検索し、現在、ログインしていて、かつ必要権限を保有した役席者を検索する。

検索の結果、ステップＳ３２において、当該取引の承認の権限値を保有した役席者が存在すれば、さらに、ステップＳ３３で、ヒットした対象の役席者全員の端末ＩＤをログイン情報登録テーブル１３２から取得し、承認要求が新たに発生した旨の強制メッセージを同報通知する。

また、ステップＳ２８において、承認権限が取引条件の判定を必要としなければ、ステップＳ３１にスキップし、それ以降の処理を行う。

図１４は、本発明の実施の形態になる端末管理サーバにおける承認処理フロー３（取引の取出依頼）を示す。まず、ステップＳ４１において、取出依頼電文より検索キー情報を取得し、ステップＳ４２で、該検索キーにしたがって、電子伝票ファイルＤＢ１１０を検索し、ステップＳ４３の判定で、ヒットする取引案件があれば、ステップＳ４４において、ヒットした取引案件の先頭データを取出し、ステップＳ４５で、取出したデータの取出し中フラグをＯＮにする。そして、ステップＳ４６において、依頼元のクライアントに取り出したデータを通知し、さらに、ステップＳ４７で、該当ステージの案件カウント数を−１にし、全カウンタ情報を配下のクライアント全体に通知する。

また、ステップＳ４３において、検索の結果、ヒットした案件がなければ、ステップＳ４８で、取出依頼のクライアントに「該当ステージの案件なし」とのメッセージを通知する。

図１５は、本発明の実施の形態になる端末管理サーバにおける承認処理フロー４（取引状態の更新依頼）を示す。まず、ステップＳ５１において、案件の更新依頼電文より更新によるステージ遷移先判定キーを取得する。つぎに、ステップＳ５２において、更新対象となる取引のステージ遷移条件テーブル１２３を参照し、ステージの遷移先を決定し、ステップＳ５３で、電子伝票ファイルＤＢ１１０の該当案件情報のステージ情報を更新する。そして、ステップＳ５４において、該当案件の取出中フラグをオフにして、つぎの案件の取出しを可能とし、ステップＳ５５で、ステージの案件カウンタについて、更新承認待は−１とし、承認済は＋１とするカウント処理を行う。

さらに、ステップＳ５６において、全案件のステージカウンタ情報を配下のクライアントに同報通知し、ステップＳ５７で、承認要求格納を行ったクライアントへ承認操作が完了した旨を強制的にメッセージ通知する。

図１６は、本発明の実施の形態になる端末管理サーバにおける承認処理フロー５（オペレータ／役席者ログイン依頼）を示す。まず、ステップＳ６１において、オペレータ（役席者を含む）登録依頼電文よりログイン情報を取得する。つぎに、ステップＳ６２において、オペレータＩＤ、パスワードの有効性について、２重登録がないかをチェックする。ステップＳ６３において、オペレータＩＤ、パスワードが有効データかを判定する。その結果、有効データであれば、ステップＳ６４で、ログイン情報登録テーブル１３２に登録し、ステップＳ６５において、登録完了通知をクライアントに通知する。

また、ステップＳ６３において、オペレータＩＤ、パスワードが有効データでなければ、ステップＳ６６で、ログイン拒否通知メッセージをクライアントへ通知する。

図１７は、本発明の実施の形態になる端末管理サーバにおける承認処理フロー６（オペレータ／役席者ログアウト依頼）を示す。まず、ステップＳ７１において、オペレータ（役席者を含む）からのログアウト依頼電文よりログアウト情報を取得する。つぎに、ステップＳ７２において、ログイン情報登録テーブル１３２に登録されているかをチェックする。ステップＳ７３において、当該取引案件が、有効な依頼であるかを判定する。その結果、有効依頼であれば、ステップＳ７４で、ログイン情報登録テーブル１３２より登録を削除し、ステップＳ７５において、削除完了通知をクライアントに通知する。

また、ステップＳ７３において、有効依頼でなければ、ステップＳ７６で、無効依頼通知メッセージをクライアントへ通知する。

つぎに、図１８〜図２３を用いて各端末における表示画面例を説明する。

図１８は、本発明の実施の形態になるオペレータ端末における表示画面例１（受付応答画面）を示す。本画面は、システム状態表示域２０１、主画面２０２、システムメッセージ表示域２０３、および承認ワークフローの承認済／承認待の各ステージにおける案件カウンタ表示域２０４で構成されている。主画面２０２には、例えば、銀行等の取引における取引種別の画面であり、本例では、普通支払い取引の画面が示されている。案件カウンタには、承認依頼をする前の状態が表示されている。

図１９は、本発明の実施の形態になるオペレータ端末における表示画面例２（承認要求画面）を示す。本画面は、システム状態表示域２０１、主画面２０２、システムメッセージ表示域２０３、承認ワークフローのステージ案件カウンタ表示域２０４、および承認依頼のコメント入力画面２０５で構成されている。

コメント入力画面２０５では、承認要求時、システムが自動的に本画面を取引画面の上に割り込み画面として表示される。本画面例には、承認依頼事由Ａ、オペレータの入力になる補足事項入力Ｂ、システムが自動的に入力する承認項目Ｃ等が示されている。

また、システムメッセージ表示域２０３では、端末管理サーバ３からの通知メッセージが表示される。さらに、承認ワークフローの案件カウンタ表示域２０４には、案件の処理件数が、承認待件数および承認済件数としてカウント更新がなされる。

図２０は、本発明の実施の形態になる役席者端末における表示画面例１（承認要求発生のメッセージ画面）を示す。主画面２０２は役席業務画面と表示され、メッセージ表示域２０３には、端末管理サーバ３から「××××役席承認要求が発生しました」とのメッセージが表示される。そして、案件表示カウンタ２０４には、承認要求の現在の滞留件数が表示される。

図２１は、本発明の実施の形態になる役席者端末における表示画面例２（承認要求取出画面）を示す。主画面２０２には、承認待取出画面として、依頼時分、承認結果を待つか否かの依頼方式、依頼オペレータＩＤ等が表示される。

図２２は、本発明の実施の形態になるオペレータ端末における表示画面例３（承認操作の完了通知画面）を示す。主画面２０２は、業務画面に切り替わり、メッセージ表示域２０３には、「×××承認完了通知を受信しました」との端末管理サーバ３からのメッセージが表示される。また、案件カウンタ表示域２０４は、承認が完了したことにより処理できる案件が、１つカウントされ件数が減ぜられる。

図２３は、本発明の実施の形態になるオペレータ端末における表示画面例４（承認済取引の取出画面）を示す。主画面２０２は、承認済取出となり、受付通番、承認済か否かの伝票の状態が表示される。

以上に説明してきた本発明の実施の態様は、以下の付記に示される。
（付記１） ネットワークを介してオペレータ端末および役席者端末とが接続される端末管理サーバにおける承認ワークフローの取引承認方法であって、
承認要求が発生した際に、取引を承認操作できる権限をオペレータ端末より発せられた承認要求電文から承認必要理由または取引の実施条件を動的に抽出し取得する承認条件取得ステップと、
役席者の保有する承認権限が取引内容に応じてグレードで定義された承認要否判定テーブルを参照し、前記承認条件取得ステップにおける承認必要理由および取引の実施条件にもとづいて、それら条件を満足する権限のグレードを検索する権限検索ステップと、
前記権限検索ステップにおいて選別された権限のグレードを保有する役席者についてログイン情報テーブルを参照して現在の端末位置を特定し、該当する全対象者に前記承認要求の同報メッセージを通知するメッセージ通知ステップと、
を有することを特徴とする取引承認方法。
（付記２） 前記権限検索ステップにおける承認要否判定テーブルでは、取引の内容または取引リスクの大きさにしたがって、役席者が保有する取引の承認権限が段階的な権限グレードとして定義され、登録されていることを特徴とする付記１に記載の取引承認方法。
（付記３） ネットワークを介してオペレータ端末および役席者端末とが接続される端末管理サーバにおける承認ワークフローの取引承認プログラムであって、
コンピュータに、
承認要求が発生した際に、取引を承認操作できる権限をオペレータ端末より発せられた承認要求電文から承認必要理由または取引の実施条件を動的に抽出し取得する承認条件取得ステップと、
役席者の保有する承認権限が取引内容に応じてグレードで定義された承認要否判定テーブルを参照し、前記承認条件取得ステップにおける承認必要理由および取引の実施条件にもとづいて、それら条件を満足する権限のグレードを検索する権限検索ステップと、
前記権限検索ステップにおいて選別された権限のグレードを保有する役席者についてログイン情報テーブルを参照して現在の端末位置を特定し、該当する全対象者に前記承認要求の同報メッセージを通知するメッセージ通知ステップと、
を実行させる取引承認プログラム。
（付記４） ネットワークを介してオペレータ端末および役席者端末とが接続される端末管理サーバにおける承認ワークフローの取引承認装置であって、
承認要求が発生した際に、取引を承認操作できる権限をオペレータ端末より発せられた承認要求電文から承認必要理由または取引の実施条件を動的に抽出し取得する承認条件取得部と、
役席者の保有する承認権限が取引内容に応じてグレードで定義された承認要否判定テーブルを参照し、前記承認条件取得部における承認必要理由および取引の実施条件にもとづいて、それら条件を満足する権限のグレードを検索する権限検索部と、
前記権限検索部において選別された権限のグレードを保有する役席者についてログイン情報テーブルを参照して現在の端末位置を特定し、該当する全対象者に前記承認要求の同報メッセージを通知するメッセージ通知部と、
を有することを特徴とする取引承認装置。
（付記５） 前記メッセージ通知ステップにおいて、前記ログオン情報テーブルには、役席者のログオン時に、役席者のオペレータＩＤとともに使用している端末ＩＤを格納しておき、メッセージ通知に該当する役席者を特定することを特徴とする付記１または付記２に記載の取引承認方法。

本発明の実施の形態になる基本システムの構成例を示す図である。 本発明の実施の形態になる営業店システムにおける機能構成例を示す図である。 本発明の実施の形態になる営業店システムにおけるデータの流れを示す図である。 本発明の実施の形態になる有効登録者リストの例を示す図である。 本発明の実施の形態になるログイン情報登録テーブルの例を示す図である。 本発明の実施の形態になる取引格納情報テーブルの例を示す図である。 本発明の実施の形態になる取引の承認要否判定テーブルの例を示す図である。 本発明の実施の形態になるステージ遷移条件テーブルの例を示す図である。 本発明の実施の形態になるステージ遷移の例を示す図である。 本発明の実施の形態になる取引承認のシステムデータフローを示す図である。 本発明の実施の形態になるオペレータ、役席者の登録・削除のデータフローを示す図である。 本発明の実施の形態になる端末管理サーバにおける承認処理フロー１（承認要否）を示す図である。 本発明の実施の形態になる端末管理サーバにおける承認処理フロー２（承認依頼格納）を示す図である。 本発明の実施の形態になる端末管理サーバにおける承認処理フロー３（取引の取出依頼）を示す図である。 本発明の実施の形態になる端末管理サーバにおける承認処理フロー４（取引状態の更新依頼）を示す図である。 本発明の実施の形態になる端末管理サーバにおける承認処理フロー５（オペレータ／役席者ログイン依頼）を示す図である。 本発明の実施の形態になる端末管理サーバにおける承認処理フロー６（オペレータ／役席者ログアウト依頼）を示す図である。 本発明の実施の形態になるオペレータ端末における表示画面例１（受付応答画面）を示す図である。 本発明の実施の形態になるオペレータ端末における表示画面例２（承認要求画面）を示す図である。 本発明の実施の形態になる役席者端末における表示画面例１（承認要求発生のメッセージ画面）を示す図である。 本発明の実施の形態になる役席者端末における表示画面例２（承認要求取出画面）を示す図である。 本発明の実施の形態になるオペレータ端末における表示画面例３（承認操作の完了通知画面）を示す図である。 本発明の実施の形態になるオペレータ端末における表示画面例４（承認済取引の取出画面）を示す図である。

符号の説明

１ オペレータ端末
２ 役席者端末
３ 端末管理サーバ
４ ＬＡＮ（ローカルエリアネットワーク）
５ ネットワーク
６ ホスト
１１、２１ 入出力制御部
１２、２２ 取引制御部
１３、２３、３１ 通信制御部
３２ ワークフロー制御管理部
３３ 電子伝票ファイル制御管理部
１１０ 電子伝票ファイルＤＢ（データベース）
１２０ ワークフロー管理テーブル
１２１ 取引格納情報テーブル
１２２ 承認要否判定テーブル
１２３ ステージ遷移条件テーブル
１３０ ログオン情報管理テーブル
１３１ 有効登録者リスト
１３２ ログイン情報登録テーブル
３２０ 取引承認プログラム
３２１ 承認条件取得部
３２２ 権限検索部
３２３ メッセージ通知部

Claims (4)

1. ネットワークを介してオペレータ端末および役席者端末とが接続される端末管理サーバにおける承認ワークフローの取引承認方法であって、
   承認要求が発生した際に、取引を承認操作できる権限をオペレータ端末より発せられた承認要求電文から承認必要理由または取引の実施条件を動的に抽出し取得する承認条件取得ステップと、
   役席者の保有する承認権限が取引内容に応じてグレードで定義された承認要否判定テーブルを参照し、前記承認条件取得ステップにおける承認必要理由および取引の実施条件にもとづいて、それら条件を満足する権限のグレードを検索する権限検索ステップと、
   前記権限検索ステップにおいて選別された権限のグレードを保有する役席者についてログイン情報テーブルを参照して現在の端末位置を特定し、該当する全対象者に前記承認要求の同報メッセージを通知するメッセージ通知ステップと、
   を有することを特徴とする取引承認方法。
2. 前記権限検索ステップにおける承認要否判定テーブルでは、取引の内容または取引リスクの大きさにしたがって、役席者が保有する取引の承認権限が段階的な権限グレードとして定義され、登録されていることを特徴とする請求項１に記載の取引承認方法。
3. ネットワークを介してオペレータ端末および役席者端末とが接続される端末管理サーバにおける承認ワークフローの取引承認プログラムであって、
   コンピュータに、
   承認要求が発生した際に、取引を承認操作できる権限をオペレータ端末より発せられた承認要求電文から承認必要理由または取引の実施条件を動的に抽出し取得する承認条件取得ステップと、
   役席者の保有する承認権限が取引内容に応じてグレードで定義された承認要否判定テーブルを参照し、前記承認条件取得ステップにおける承認必要理由および取引の実施条件にもとづいて、それら条件を満足する権限のグレードを検索する権限検索ステップと、
   前記権限検索ステップにおいて選別された権限のグレードを保有する役席者についてログイン情報テーブルを参照して現在の端末位置を特定し、該当する全対象者に前記承認要求の同報メッセージを通知するメッセージ通知ステップと、
   を実行させる取引承認プログラム。
4. ネットワークを介してオペレータ端末および役席者端末とが接続される端末管理サーバにおける承認ワークフローの取引承認装置であって、
   承認要求が発生した際に、取引を承認操作できる権限をオペレータ端末より発せられた承認要求電文から承認必要理由または取引の実施条件を動的に抽出し取得する承認条件取得部と、
   役席者の保有する承認権限が取引内容に応じてグレードで定義された承認要否判定テーブルを参照し、前記承認条件取得部における承認必要理由および取引の実施条件にもとづいて、それら条件を満足する権限のグレードを検索する権限検索部と、
   前記権限検索部において選別された権限のグレードを保有する役席者についてログイン情報テーブルを参照して現在の端末位置を特定し、該当する全対象者に前記承認要求の同報メッセージを通知するメッセージ通知部と、
   を有することを特徴とする取引承認装置。
   

Images