(57)【要約】【課題】営業店の多様な業務、店舗構成への対応を低コストで可能とし、事務フローの変更に伴うアプリケーションのカスタマイズも容易にする。【解決手段】複数の端末１１１〜１１５、複数の金融デバイス１１６〜１１９を有する複数の営業店１０２と電算センタ１０３とを備え、電算センタ内のＡＰサーバ１３１に金融デバイスの制御指示を行う複数のデバイス系コンポーネント１５１と各種業務システム１３７を利用するための複数の上位アクセスコンポーネント１５２と業務ロジックとして記述されている複数の業務系コンポーネント１５３とこれらコンポーネントを順に呼び出すコンポーネントフロー制御部１４４とを備え、事前に定義されたコンポーネントフロー定義情報の呼出順序に従ってコンポーネントフロー制御部がコンポーネントを順に呼び出すことで、ＡＰサーバ側で営業店事務のアプリケーションを実現する。【選択図】  図１
2004348309.tif 000002
【特許請求の範囲】
【請求項１】
顧客もしくは店員が操作する複数種類の操作端末と複数種類の処理デバイスとを有する複数の営業店と、前記営業店の前記操作端末からの入力操作によりアクセスされるサーバと前記サーバから必要に応じてアクセスされる業務システムとを有する電算センタとが、ネットワークを介して接続された営業店フロー制御システムであって、
前記サーバは、前記操作端末からの入力データの受付及び前記操作端末の画面の生成を行う端末入出力制御部と、前記営業店に設置されている前記処理デバイスの制御指示を行うための複数のデバイス系コンポーネントと、前記電算センタの業務システムをアクセスするための複数の上位アクセスコンポーネントと、前記サーバ内の業務ロジックとして記述されている複数の業務系コンポーネントとを備えることを特徴とする営業店フロー制御システム。
【請求項２】
請求項１記載の営業店フロー制御システムにおいて、
前記サーバは、前記操作端末からの入力操作に従って、前記デバイス系コンポーネント及び前記上位アクセスコンポーネント及び前記業務系コンポーネントを実行することを特徴とする営業店フロー制御システム。
【請求項３】
請求項２記載の営業店フロー制御システムにおいて、
前記サーバは、前記コンポーネントの呼出順序が定義されたコンポーネントフロー定義情報を管理するコンポーネントフロー管理部と、前記コンポーネントフロー定義情報に従って前記コンポーネントを順に呼び出すコンポーネントフローエンジンとを含むコンポーネントフロー制御部を備えることを特徴とする営業店フロー制御システム。
【請求項４】
請求項３記載の営業店フロー制御システムにおいて、
前記コンポーネントフロー定義情報は、前記営業店毎に異なるフローを提供できるよう、前記操作端末においる複数画面の遷移を含めた一連の業務の流れを定義することを特徴とする営業店フロー制御システム。
【請求項５】
請求項１記載の営業店フロー制御システムにおいて、
前記デバイス制御コンポーネントは、前記操作端末と前記処理デバイスとの対応付けを管理するテーブルを備え、
前記操作端末は、前記処理デバイスを利用する場合に、前記テーブルを参照して、利用する処理デバイスを決定することを特徴とする営業店フロー制御システム。
【請求項６】
顧客が来店する営業店内に配置された複数種類の操作端末及び前記営業店内に配置された複数種類の処理デバイスであって前記操作端末からの要求に応じた業務を処理する処理デバイスと、ネットワークを介して接続され、かつ前記営業店外部に配置された制御システムにおいて、
前記操作端末からの要求に応じた業務に応じた処理フローを定義したフロー管理情報を記憶する記憶装置と、
前記操作端末とのデータの入出力を制御する端末入出力制御部と、
各種類の処理デバイスに対応して設けられ、前記処理デバイスを制御する複数種類のデバイス制御部と、
前記各操作端末からの要求に応じて業務内容を判別し、前記記憶装置内のフロー管理情報を参照して前記業務内容に応じた処理フローを決定し、前記処理フローに基づいて前記複数種類のデバイス制御部の中から動作させるべきデバイス制御部を決定するフロー制御部を備えることを特徴とする制御システム。
【請求項７】
請求項６記載の制御システムにおいて、
前記記憶装置は、前記処理デバイスが配置される営業店の識別情報を記憶し、
前記デバイス制御部は、前記記憶装置内の前記営業店の識別情報を参照して、前記端末入出力制御部へ要求した操作端末と同一営業店内の処理デバイスを選択し、選択された前記処理デバイスを制御することを特徴とする制御システム。
【請求項８】
請求項６記載の制御システムにおいて、
前記記憶装置は、前記処理デバイスの占有状態情報を記憶し、
前記デバイス制御部は、前記記憶装置内の前記占有状態情報を参照して、占有されていない処理デバイスを選択し、選択された前記処理デバイスを制御することを特徴とする制御システム。
【請求項９】
請求項６記載の制御システムにおいて、
前記記憶装置は、前記操作端末と前記処理デバイスの対応付け情報を記憶し、
前記デバイス制御部は、前記記憶装置内の前記対応付け情報を参照して、前記端末入出力制御部へ要求した操作端末に対応付けられた処理デバイスがあるか否かを判別し、前記処理デバイスがあると判別された場合に、対応付けがある処理デバイスを制御し、前記処理デバイスがないと判別された場合に、対応付けがない処理デバイスの中から動作させるべき処理デバイスを選択し、選択された前記処理デバイスを制御することを特徴とする制御システム。
【請求項１０】
請求項６記載の制御システムにおいて、
前記フロー制御部は、前記処理フローに基づいて動作させるべき処理デバイスの種類を決定し、前記複数種類のデバイス制御部から前記動作させるべき種別の処理デバイスに対応するデバイス制御部を、前記動作させるべきデバイス制御部として決定することを特徴とする制御システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、営業店内に複数種類の操作端末、複数種類の処理デバイスを有し、来店した顧客に対し複数の操作端末、複数の処理デバイスを利用して営業店の業務を実現するシステム、方法及びプログラムに係り、特に、金融機関で利用されるシステム等に関する。
【０００２】
【従来の技術】
特許文献１では、サーバに、複数の業務コンポーネント、業務コンポーネントを呼び出して実行するためのプログラムである業務フローメソッド、及び業務処理毎に必要な業務フローメソッドを格納するためのプログラムである業務フロークラスを用意し、業務フローメソッドにより業務コンポーネントを順に呼び出す方法が提示されている。
【０００３】
【特許文献１】特開２００２−９１７８０号公報
【０００４】
【発明が解決しようとする課題】
営業店では、さまざまな金融デバイスが存在し、画面操作のみでなく、これら金融デバイスの動作手順も含めた一連の流れが事務フローとして規定されている。
【０００５】
しかし、特開２００２−９１７８０号公報に記載されている従来技術は、サーバノードにあるコンポーネントを順に呼び出すのみであり、特に、物理的な配置や、デバイスの制御については、示していない。
【０００６】
今後の営業店システムでは、必要最小限の金融デバイスの構成で、各端末から、金融デバイスの制御も含めた多様な業務を、営業店事務の一連のフローで実現することが求められる。
【０００７】
本発明の目的は、営業店内の処理デバイスへ指示を行う操作端末を汎用化することにより、操作端末及び処理デバイスの使用効率を向上するシステム等を提供することである。
【０００８】
本発明の目的は、営業店内の処理デバイスの制御機能をセンタに集中させることにより、制御機能のメンテナンスやカスタマイズの作業効率が向上し、ユーザの作業負担を低減するシステム等を提供することである。
【０００９】
本発明の目的は、営業店内の処理デバイスの制御機能をセンタに集中させて営業店内の処理デバイスへ指示を行う操作端末を汎用化したことにより、制御機能の開発効率を向上するシステム等を提供することである。
【００１０】
本発明の目的は、営業店内の処理デバイスの制御機能をセンタに配置することにより、営業店をコンパクト化できるシステム等を提供することである。
【００１１】
【課題を解決するための手段】
本発明は、顧客もしくは行員が操作する複数種類の操作端末（例えば、受付端末、ロビー端末、窓口端末、後方端末、自動機）と、複数種類の処理デバイス（スキャナ、伝票プリンタ、現金入出金機、通帳発行記帳機）とを有する複数の営業店と、営業店の操作端末からの入力操作によりアクセスされるサーバと、サーバから必要に応じてアクセスされる各種業務システムとを有する電算センタとを、ネットワークを介して接続する営業店システムであって、サーバは、操作端末からの入力データの受付及び操作端末の画面の生成を行う端末入出力制御部と、営業店に設置されている処理デバイスの制御指示を行うための複数のデバイス系コンポーネントと、電算センタにある各種業務システムをアクセスするための複数の上位アクセスコンポーネントと、サーバ内の業務ロジックとして記述されている複数の業務系コンポーネントとを備え、操作端末からの入力操作に従って、サーバ内のコンポーネントを順に実行することで、処理デバイスの制御も含めた営業店業務を実行する。このとき、サーバにて営業店にある処理デバイスの占有状態を管理し、サーバからの指示により処理デバイスの動作を制御する。なお、サーバは、金融機関によっては、各営業店に設置してもよい。
【００１２】
本発明は、サーバ内に、コンポーネントフロー制御部を備え、コンポーネントフロー制御部内に、コンポーネントの呼出順序が定義されたコンポーネントフロー定義情報を管理するコンポーネントフロー管理部と、コンポーネントフロー定義情報に従ってコンポーネントを順に呼び出すコンポーネントフローエンジンとを備えるのが好ましい。そして、コンポーネントフロー定義情報のカスタマイズにより、営業店の業務を実現する。ここで、コンポーネントフローの定義を容易にするために、画面の入出力や、各金融デバイスの動作、勘定系ホストへの送受信といった、営業店における事務処理の１ステップをコンポーネント、メソッドの単位として提供する。さらに、コンポーネントフロー定義情報は、営業店毎に異なるフローを提供できるようにし、一端末において複数の画面遷移も含めた一連の事務の流れを定義できるようにする。
【００１３】
本発明は、操作端末からの要求に応じた業務に応じた処理フローを定義したフロー管理情報を記憶する記憶装置と、操作端末とのデータの入出力を制御する端末入出力制御部と、各種類の処理デバイスに対応して設けられ、処理デバイスを制御する複数種類のデバイス制御部（例えば、デバイス系コンポーネント）と、各操作端末からの要求に応じて業務内容を判別し、記憶装置内のフロー管理情報を参照して業務内容に応じた処理フローを決定し、処理フローに基づいて複数種類のデバイス制御部の中から動作させるべきデバイス制御部を決定するフロー制御部（例えば、コンポーネントフロー制御部）を備える。
【００１４】
【発明の実施の形態】
以下、本発明について、実施形態とともに図を参照して詳細に説明する。
【００１５】
図１は、本発明のシステム構成を示す図である。このシステムは、ネットワーク１０１を介して、顧客が来店する複数の営業店１０２、電算センタ１０３が接続されている。
【００１６】
営業店１０２は、端末として、営業店の入口近くに置かれ、来店した顧客が受付を行う受付端末１１１と、顧客により特定の取引を行ったり、顧客がロビーにて待ち時間に自由に操作可能なロビー端末１１２と、窓口にて行員が顧客と直接応対するときに操作する窓口端末１１３と、窓口の後方にある行員のエリアにて行員が操作する後方端末１１４と、ＡＴＭのように顧客が操作し取引を完結させる自動機１１５とを備えている。また、営業店１０２は、処理を実行する金融デバイスとして、窓口にて顧客が記入した伝票や顧客が持参した本人確認資料などをイメージデータとして読み込むスキャナ１１６と、伝票を印刷したり認証印字を行う伝票プリンタ１１７と、現金の入出金を行う現金入出金機１１８と、通帳の発行や記帳を行う通帳発行記帳機１１９とを備えている。さらに、営業店１０２には、金融デバイスの制御を行うデバイス制御サーバ１２０を備えている。デバイス制御サーバ１２０には金融デバイスを制御するミドルウエアが収められている。なお、デバイス制御サーバ１２０は各銀行や店舗の設置形態により電算センタ１０３内に設置されていてもよい。また、デバイス制御サーバの機能が営業店１０２の各端末内に収められていてもよい。各端末や各金融デバイスは、ローカル・エリア・ネットワーク及びルータを介して、ネットワーク１０１に接続されている。ＡＰサーバ１３１から、直接に、各端末や各金融デバイスを制御可能である。
【００１７】
また、電算センタ１０３は、本発明のシステムにおける営業店業務アプリケーションが実装されているＡＰサーバ１３１と、ＡＰサーバ１３１から各サブシステムを利用する際に経由するハブサーバ１３２と、顧客の口座情報や入出金、貸付や借入情報が統括的に記録されている元帳１３３を管理する勘定系ホスト１３４と、各種の顧客情報１３５を管理する顧客情報管理サーバ１３６と、この銀行の各種の業務を実現している各種業務システム１３７とを備えている。銀行によっては、ハブサーバ１３２を設置せず、ＡＰサーバ１３１から直接他サーバ、システムにアクセスしてもよい。
【００１８】
ＡＰサーバ１３１内には、ＷＷＷサーバ１４１と、営業店１０２内の各端末に対しての入出力データの制御を行う端末入出力制御部１４２と、営業店業務アプリケーションを実現するための各部品となる複数のコンポーネント１４３と、これらコンポーネントを順番に呼び出す制御を行うコンポーネントフロー制御部１４４と、ワークフロー制御部１４５とを備えている。ここで、ＷＷＷサーバ１４１と端末入出力制御部１４２はＡＰサーバ１３１とは別のサーバに収められていてもよい。
【００１９】
コンポーネント１４３は、営業店１０２内にある金融デバイスを動作させるための部品となるデバイス系コンポーネント１５１と、勘定系ホスト１３４などの各種業務システムにアクセスするための上位アクセスコンポーネント１５２と、ＡＰサーバ１３１内のみで実行される業務系コンポーネント１５３から成る。デバイス系コンポーネント１５１は、各金融デバイスの種類毎にある。デバイス系コンポーネント１５１は、各営業店１０２の金融デバイス構成の定義情報や現在の状態を管理するデバイス管理部１５４に接続されている。業務系コンポーネント１５３は、端末からの入力データのチェック（例えば、データの数値範囲や桁数、データ間の相関）や、ＡＰサーバ１３１内に記憶されているデータの検索を行う。
【００２０】
コンポーネントフロー制御部１４４は、業務のパターン毎にコンポーネント１４３をどの順序で呼び出すかの定義情報や現在の状態を管理するコンポーネントフロー管理部１６１と、これら情報に従って順にコンポーネント１４３を呼び出すエンジンであるコンポーネントフローエンジン１６２とから成る。
【００２１】
ワークフロー制御部１４５は、各営業店１０２内で複数端末に跨って一取引を行う場合に各取引の状態や業務データを管理するためのワークフロー管理部１７１と、これら状態、業務データなどの情報に従ってステータスを遷移させていくワークフローエンジン１７２とから成る。
【００２２】
なお、コンポーネント１４３、コンポーネントフロー制御部１４４、ワークフロー制御部１４５は、それぞれ別のサーバ上で実装されてもいてもよい。また、コンポーネント１４３内の各コンポーネントはそれぞれが別のサーバ上で実装されてもいてもよい。
【００２３】
各制御部、各管理部、各コンポーネント、各エンジンの機能は、処理装置（例えば、ＣＰＵ）によって実現される。各テーブルや各官吏データは、記憶装置（例えば、ハードディスク装置）に記憶されている。処理装置は、記憶装置へアクセスし、記憶装置内のテーブルを参照することができ、管理データを読み出すことができる。
【００２４】
図２は、業務を実行する際に営業店１０２内の各端末から電算センタ１０３のＡＰサーバ１３１に送信されるデータのフォーマットであり、各業務で共通的な情報となるヘッダ情報２０１と各業務で個別に定義された情報となる業務データ２０２とから構成される。ヘッダ情報２０１は、業務を実行する端末が所属する営業店を一意に識別するための店番２１１、業務を実行する端末がロビー端末１１２なのか窓口端末１１３なのかなど端末の分類を識別するための端末分類２１２、営業店１０２内の端末を一意に識別するための機番２１３、実行すべき業務を識別するための業務ＩＤ２１４、取り扱っている案件を一意に識別するための案件ＩＤ２１５などから構成される。
【００２５】
図３は、コンポーネントフロー制御部１４４のコンポーネントフロー管理部１６１で管理される定義情報であるコンポーネントフロー管理テーブルであり、業務を一意に識別するための業務ＩＤ３０１と、業務が実行される端末の分類を識別するための端末分類３０２と、業務データの値によって利用されるコンポーネントフローが異なる場合に定義される分岐条件３０３と、コンポーネントフローを識別するフローＩＤ３０４とから構成される。本テーブルは、端末からＡＰサーバ１３１に対して、業務の実行を行うようデータが送信された際に、図２に示す端末からの送信データ内にある業務ＩＤ３０１と、端末分類３０２と、業務データの値による分岐条件３０３とから、利用すべきコンポーネントフローの種別を示すフローＩＤ３０４を取得することに利用される。
【００２６】
図４は、コンポーネントフロー制御部１４４のコンポーネントフロー管理部１６１で管理されるデータであるコンポーネントフロー状態管理データであり、案件を一意に識別する案件ＩＤ４０１と、業務ＩＤ４０２と、フローＩＤ４０３と、フローＩＤで規定されているフロー中現在どのステータスにあるかを示すステータス４０４とから構成される。案件ＩＤ４０１は、ある顧客の取引を実行するとき、最初に利用される端末から１回目にデータがＡＰサーバ１３１に送信された際に、ＡＰサーバ１３１にて付与されるものである。また、ＡＰサーバ１３１にて業務のステータスを保持する必要がある場合に、その案件を示す案件ＩＤ４０１と、業務ＩＤ４０２と、フローＩＤ４０３とともに現在のステータス４０４をコンポーネントフロー状態管理データに格納する。
【００２７】
図５は、デバイス管理部１５４で管理される定義情報であるデバイス構成定義テーブルであり、営業店１０２を識別する店番５０１と、金融デバイスの種類を識別するデバイス種別５０２と、営業店１０２内の金融デバイスを一意に識別するためのデバイス番号５０３と、金融デバイスがあらかじめいずれかの端末に対応付けられているかどうかを示す対応付け有無５０４と、対応付けられている場合にいずれの端末と対応付けられているかを示す対応機番５０５とから構成される。対応付けられているとは、専用に使用することが決められていることをいう。端末と金融デバイスの対応付けは、１対１でもよいし、１対Ｎ（Ｎは２以上の整数）、Ｎ対１でもよい。ある金融デバイスにおいて、それを利用するための端末が店舗内のデバイス構成によりあらかじめ定められている場合には、対応付けを行っておく。例えば、窓口にて、窓口端末１１３の横に通帳発行記帳機１１９が設置されていて、窓口端末１１３で通帳を記帳する際には必ずこの通帳発行記帳機１１９を利用する場合などである。営業店１０２内のさまざまな端末から共有して利用される場合には、対応付け有無５０４を無と定義しておく。また、対応機番５０５で定義される機番の数は金融デバイスの種別により異なる。
【００２８】
図６は、デバイス系コンポーネント１５１のデバイス管理部１５４で管理されるデータであるデバイス状態管理データであり、店番６０１と、デバイス種別６０２と、デバイス番号６０３と、デバイスが現在いずれかの端末に占有されているかどうかを示す占有ステータス６０４と、占有されている場合にいずれの端末に占有されているかどうかを示す占有機番６０５とから構成される。デバイス状態管理データには、あらかじめ店番６０１と、デバイス種別６０２と、デバイス番号６０３とが、図５のデバイス構成定義テーブルに従って格納されており、営業店業務の実行中に占有を行ったり、解除したりすることで、占有ステータス６０４、占有機番６０５のデータが更新される。
【００２９】
次に、図７〜図１０のフロー図を用いて、本発明の処理の詳細を説明する。
【００３０】
まず図７を用いて、営業店１０２内の各端末における業務の処理手順を説明する。図７ではロビー端末１１２、窓口端末１１３などの端末と、ＡＰサーバ１３１内の端末入出力制御部１４２と、コンポーネントフロー制御部１４４それぞれで実行される処理を記述している。
【００３１】
まず、端末上に画面が表示されている（ステップ７０１）。画面上で必要な入力を行い、入力データをＡＰサーバ１３１に送信する（ステップ７０２）。ステップ７０２で送信するデータフォーマットは図２で示されているものである。端末入出力制御部１４２では、受信した入力データをコンポーネントフロー制御部１４４が規定するフォーマットに編集し、コンポーネントフロー制御部１４４に送信する（ステップ７０３）。
【００３２】
コンポーネントフロー制御部１４４では、送信された案件に案件ＩＤが付与済かどうかの判定を行い（ステップ７０４）、付与済でなければ、案件ＩＤを付与する（ステップ７０５）。案件ＩＤとは、本システムで案件毎に一意となる番号である。本案件が最初にシステム処理される際に付与されるものであり、最初に端末からＡＰサーバ１３１に送信されるデータには格納されていないことになる。なお、複数端末で跨って一取引を実現する場合には、２番目以降の端末で取引の続きを実行する際にはすでに案件ＩＤが付与されている。
【００３３】
そして、フロー呼出処理を実行し（ステップ７０６）、コンポーネントのフローが順に定義されているコンポーネントフロー定義情報に従って順にコンポーネントが呼び出されることで処理を実行する。
【００３４】
コンポーネントフロー定義情報を参照し、次に画面表示後、フローの呼び出しが残っているかどうかを判定し（ステップ７０７）、残っていれば、フロー中の現在のステータスをコンポーネントフロー状態管理データに保持し（ステップ７０８）、必要な業務データを保持する（ステップ７０９）。業務データを保持する方法については、ＤＢへの格納、ＡＰサーバ１３１のメモリへの保持などいずれの方法でもよい。
【００３５】
そして、出力データを返信し（ステップ７１０）、端末入出力制御部１４２では、返信された出力データにより、画面を生成、端末に返信し（ステップ７１１）、端末上に画面を表示する（ステップ７１２）。本画面上にてまだ取引の処理が残っている場合には、同様にステップ７１３からステップ７２２を繰り返す。
【００３６】
本システムで定義するコンポーネントフローは、端末からの１回のリクエストによりＡＰサーバ上で呼び出されるフローの範囲のみでなく、１つの端末において、複数画面の遷移により、画面遷移の間に複数回ＡＰサーバ上で呼び出されるフローを含んだ業務の一連の流れを定義することができる。本システムでは、ステップ７０８、７０９により、フロー中のステータス、業務データを保持することにより、２回目以降に端末からＡＰサーバ１３１に送信された場合にフローに従って、引続きの処理を実行する。
【００３７】
次に、図８のフロー図を用いて、図７におけるステップ７０６のフロー呼出処理の処理手順を説明する。図８では、コンポーネントフロー制御部１４４内のコンポーネントフローエンジン１６２と、コンポーネントフロー管理部１６１それぞれで実行される処理を記述している。
【００３８】
まず、コンポーネントフローエンジン１６２は、入力データをコンポーネントフロー管理部１６１に送信する（ステップ８０１）。コンポーネントフロー管理部１６１では、受信した入力データを参照して、実行すべきフローを判別し（ステップ８０２）、フローＩＤをコンポーネントフローエンジン１６２に返信する（ステップ８０３）。
【００３９】
次に、コンポーネントフローエンジン１６２から、コンポーネントフロー管理部１６１に対し、次に呼び出すべきコンポーネントを問合せ（ステップ８０４）、コンポーネントフロー管理部１６１では、次に呼び出すべきコンポーネントが存在するかどうかを判定し（ステップ８０５）、存在すれば該当するコンポーネントを返信し（ステップ８０６）、コンポーネントをコンポーネントフローエンジン１６２が呼び出すことで処理を実行する（ステップ８０７）。コンポーネントの実行が完了すれば、ステップ８０４からステップ８０７を繰り返し、ステップ８０５にて次に呼び出すべきコンポーネントがなければ（フローが完了であれば）、出力データの編集依頼をコンポーネントフローエンジン１６２からコンポーネントフロー管理部１６１に行い（ステップ８０８）、フロー管理部では出力データを編集し（ステップ８０９）、返信する（ステップ８１０）。
【００４０】
次に、図９のフロー図を用いて、図８におけるステップ８０２のフロー判別処理の処理手順を説明する。
【００４１】
まず、送信された入力データ中の案件ＩＤを参照し、案件ＩＤが図４に示したコンポーネントフロー状態管理データに登録済かどうかを判定する（ステップ９０１）。登録済であれば、コンポーネントフロー状態管理データからフローＩＤを取得し（ステップ９０２）、本処理は終了する。登録済でなければ、以下を実行する。
【００４２】
まず、入力データを解析し（ステップ９０３）、業務ＩＤを取得（ステップ９０４）、端末分類を取得（ステップ９０５）する。次に図３に示すコンポーネントフロー管理テーブルを参照し、ステップ９０４、９０５で取得した業務ＩＤ、端末分類により、分岐条件を取得する（ステップ９０６）。取得した分岐条件に条件が記述されているかどうかを判定し（ステップ９０７）、記述されていれば、分岐するために必要なデータを入力データより取得する（ステップ９０８）。このデータにより、分岐条件を判断し、コンポーネントフロー管理テーブルからフローＩＤを取得する（ステップ９０９）。
【００４３】
次に、図１０のフロー図を用いて、コンポーネントフローエンジン１６２からデバイス系コンポーネントが呼び出された場合のデバイス制御処理の処理手順を説明する。図１０では、デバイス系コンポーネント１５１と、デバイス管理部１５４と、営業店１０２内のデバイス制御サーバ１２０と、各デバイスで実行される処理を記述している。
【００４４】
コンポーネントフローエンジン１６２よりデバイス系コンポーネント１５１が呼び出される（ステップ１００１）。デバイス系コンポーネント１５１では、まず、利用すべき金融デバイスの占有を行うために、デバイス管理部１５４に対し、現在すでに占有しているかどうかの確認を行う（ステップ１００２）。デバイス管理部１５４では、デバイス状態管理データの占有ステータス６０４と、占有機番６０５とを参照することにより端末がすでに金融デバイスを占有済かどうかを示す占有状態情報を取得する（ステップ１００３）。占有状態情報により占有済かどうかを判定し（ステップ１００４）、占有済であれば、金融デバイスのデバイス番号をデバイス系コンポーネント１５１に返す。占有済でなければ、デバイス構成定義テーブルより、端末が現在利用しようとしている種類の金融デバイスの対応付けがされているかどうかの情報を取得する（ステップ１００５）。対応付けデバイスの有無を判定し（ステップ１００６）、対応付けが有なら、デバイス状態管理データを参照することで占有できるかどうかを確認し（ステップ１００７）、占有ができれば（ステップ１００８）、デバイス状態管理データの該当するデバイスの欄の占有ステータス６０４と、占有機番６０５とを更新することで、端末に金融デバイスを割り当てる（ステップ１０１１）。占有ができなければ、一定時間待ち、再度ステップ１００７を行うことで、占有ができるようになるまで待つ。ステップ１００６において、対応付けデバイスが無なら、デバイス構成定義テーブル内の店番５０１が端末の店番である金融デバイスのうち、対応付け有無５０４が無である金融デバイスで、デバイス状態管理データ内の占有ステータス６０４が無となっている金融デバイスを検索する（ステップ１００９）。該当する金融デバイスがあるかどうかを判定し（ステップ１０１０）、あればステップ１０１１で金融デバイスを割り当てる。該当する金融デバイスがない場合は、一定時間待ち、再度ステップ１００９を行うことで、占有ができるようになるまで待つ。ステップ１０１１にて割り当てられた後、該当する金融デバイスのデバイス番号をコンポーネントに返信する。
【００４５】
そして、デバイス系コンポーネント１５１は、デバイス制御サーバ１２０に対し、デバイス番号を渡して金融デバイスの処理の指示を行う（ステップ１０１２）。デバイス制御サーバは渡されたデバイス番号により、該当する金融デバイスに対し、金融デバイスの処理の指示を行い（ステップ１０１３）、金融デバイスが動作する（ステップ１０１４）。
【００４６】
金融デバイスの動作が終了すると、デバイス系コンポーネント１５１では、デバイス処理指示が端末における取引での最終指示かどうかを判定し（ステップ１０１５）、最終指示であれば、デバイス管理部１５４は占有の解除を行う（ステップ１０１６）。ステップ１０１６ではデバイス状態管理データの占有ステータス６０４を無に更新し、占有機番６０５のデータを削除する。なお、ステップ１０１５にて、最終指示でなければ、金融デバイスをそのまま占有し続けることとするため、占有の解除は行わない。例えば、通帳発行記帳機１１９において、通帳の吸入を行った場合、通帳は通帳発行記帳機１１９の中に入ったままであり、次に同一端末から別の指示が必ず発生するため、占有を解除してはならない。
【００４７】
次に、図１１〜１４のフロー図を用いて、新規口座開設取引と支払取引の例を用いて具体的に処理の詳細を説明する。本実施形態は、窓口端末１１３での取引の例である。
【００４８】
まず、新規口座開設取引の例について説明する。
【００４９】
図１１が、ロビー端末１１２で取引データを先行入力した後の、窓口端末１１３における新規口座開設取引を実行するためのコンポーネントフローの例である。
【００５０】
まず、取引入力画面の表示を行い（ステップ１１０１）、入力後、勘定系ホスト１３４に対し、ＣＩＦ登録を行い（ステップ１１０２）、伝票プリンタ１１７を用いて入力データを伝票として出力し（ステップ１１０３）、次の画面である伝票の読込指示画面を表示する（ステップ１１０４）。次に、スキャナ１１６を用いて伝票の読込みを行い（ステップ１１０５）、勘定系ホストの実行指示画面を表示する（ステップ１１０６）。次に、現金入出金機１１８に挿入された現金の計数を行い、計数された金額と入力データ中の金額が合っているかどうかのチェックを行い（ステップ１１０７）、合っていれば、勘定系ホストにデータを送信し（ステップ１１０８）、その結果により、現金入出金機１１８にて入金現金を収納し（ステップ１１０９）、通帳発行記帳機１１９にて通帳の発行と記帳を行い（ステップ１１１０）、伝票プリンタ１１７にて認証印字を行い（ステップ１１１１）、完了したことを示す画面を表示する（ステップ１１１２）。
【００５１】
図１２を用いて、図１１のコンポーネントフローに従った、新規口座開設取引の処理手順を説明する。
【００５２】
まず、ロビー端末１１２で先行入力された取引データを表示する取引入力画面を窓口端末１１３上に表示する（ステップ１２０１）。行員が入力内容を確認し、完了ボタンを押下すると、ＡＰサーバ１３１に入力データを送信する。ＡＰサーバ１３１では、端末入出力制御部１４２で、入力データを編集し（ステップ１２０２）、コンポーネントフロー制御部１４４に渡す。コンポーネントフロー制御部１４４では、図１１のコンポーネントフローに従い、図７〜図９に示したフロー図に従って順にコンポーネントを呼び出す。この例では、まず、ＣＩＦ登録のコンポーネントを呼び出し、勘定系ホスト１３４に送信する（ステップ１２０３）。次に伝票の出力のコンポーネントを呼び出し、伝票プリンタ１１７に伝票を出力する（ステップ１２０４）。図１１のコンポーネントフローでは次が読込画面の表示であるため、いったんコンポーネントの呼び出しは終了し、データとステータスをコンポーネントフロー制御部１４４で保持し（ステップ１２０５）、出力データを端末入出力制御部１４２に返す。端末入出力制御部１４２では、出力データにより、次画面である読込画面を生成し（ステップ１２０６）、窓口端末１１３に返信し、窓口端末１１３上に読込画面を表示する（ステップ１２０７）。
【００５３】
次に、行員は出力された伝票を受取り、顧客に伝票を渡し、印鑑の押印を依頼する。そして、押印済の伝票、免許証などの本人確認資料、口座開設のための入金現金を行員が顧客から受け取り、本人確認を行い、伝票をスキャナ１１６の上にセットし、窓口端末１１３で表示されている読込画面上の読込ボタンを押下すると、ＡＰサーバ１３１に入力データを送信する。ＡＰサーバではステップ１２０２と同様に、入力データを編集し（ステップ１２０８）、コンポーネントフロー制御部１４４に渡す。コンポーネントフロー制御部１４４では、ステップ１２０５にてデータとステータスを保持しているため、それらを取得することで、図１１のコンポーネントフローのステップ１１０５から実行し、スキャナ１１６により伝票の読込を行う（ステップ１２０９）。次の処理が実行画面の表示であるため、いったんコンポーネントの呼び出しは終了し、再度データとステータスをコンポーネントフロー制御部１４４で保持し（ステップ１２１０）、出力データを端末入出力制御部１４２に返す。端末入出力制御部１４２では、出力データにより、次画面である実行画面を生成し（ステップ１２１１）、窓口端末１１３に返信し、窓口端末１１３上に実行画面を表示する（ステップ１２１２）。
【００５４】
次に、行員は先に受け取った現金を現金入出金機１１８に、伝票を伝票プリンタ１１７にセットし、窓口端末１１３で表示されている実行画面上の完了ボタンを押下すると、ＡＰサーバ１３１に入力データを送信する。ＡＰサーバではステップ１２０２と同様に、入力データを編集し（ステップ１２１３）、コンポーネントフロー制御部１４４に渡す。コンポーネントフロー制御部４４では、ステップ１２１０にてデータとステータスを保持しているため、それらを取得することで、図１１のコンポーネントフローのステップ１１０７から実行し、順に、現金計数、金額のチェック（ステップ１２１４）、勘定系ホスト送信（ステップ１２１５）、入金現金の収納（ステップ１２１６）、通帳の発行、記帳（ステップ１２１７）、認証印字（ステップ１２１８）の処理を行うコンポーネントを順に呼び出す。そして、次が完了画面の表示で終了のため、出力データを端末入出力制御部１４２に返す。端末入出力制御部１４２では、出力データにより、次画面である完了画面を生成し（ステップ１２２１）、窓口端末１１３に返信し、窓口端末１１３上に完了画面を表示し（ステップ１２２１）、本処理を終了する。
【００５５】
次に、支払取引の例について説明する。
【００５６】
図１３が、窓口にて伝票をスキャナ１１６によりイメージ読込みした後の、窓口端末１１３における支払取引を実行するためのコンポーネントフローの例である。
【００５７】
まず、取引入力画面の表示を行い（ステップ１３０１）、入力後、印鑑照合を行い（ステップ１３０２）、勘定系ホストにデータを送信し（ステップ１３０３）、その結果により、現金入出金機１１８にて現金を出金し（ステップ１３０４）、通帳発行記帳機１１９にて通帳の記帳を行い（ステップ１３０５）、伝票プリンタ１１７にて認証印字を行い（ステップ１３０６）、完了したことを示す画面を表示する（ステップ１３０７）。図１３のフローは、端末からＡＰサーバ１３１へのリクエストが１回のみの例である。
【００５８】
図１４を用いて、図１３のフローに従った、支払取引の処理手順を説明する。
【００５９】
まず、窓口にてスキャナ１１６により伝票を読み取って文字認識された取引データを表示する取引入力画面を窓口端末１１３上に表示する（ステップ１４０１）。行員が入力内容を確認し、完了ボタンを押下すると、ＡＰサーバ１３１に入力データを送信する。ＡＰサーバ１３１では、端末入出力制御部１４２で、入力データを編集し（ステップ１４０２）、コンポーネントフロー制御部１４４に渡す。コンポーネントフロー制御部１４４では、図１３のコンポーネントフローに従い、図７〜図９に示したフロー図に従って順にコンポーネントを呼び出す。この例では、まず、印鑑照合のコンポーネントを呼び出し、印鑑サブシステムに対し、印鑑照合を行う（ステップ１４０３）。次に、勘定系ホスト１３４に送信し（ステップ１４０４）、その結果により、順に、現金の出金（ステップ１４０５）、通帳の記帳（ステップ１４０６）、認証印字（ステップ１４０７）の処理を行うコンポーネントを順に呼び出す。そして、次が完了画面の表示で終了のため、出力データを端末入出力制御部１４２に返す。端末入出力制御部１４２では、出力データにより、次画面である完了画面を生成し（ステップ１４０８）、窓口端末１１３に返信し、窓口端末１１３上に完了画面を表示し（ステップ１４０９）、本処理を終了する。
【００６０】
本発明の実施形態によれば、必要最小限の金融デバイスの構成によるコスト削減を実現し、各端末から、金融デバイスの制御も含めた多様な業務が行える。また、今後のチャネルの拡大、新商品の拡大などの業務多様化に伴う営業店業務フロー変更に伴ったアプリケーションのカスタマイズが容易となる。
【００６１】
本発明の実施形態によれば、アプリケーション、デバイスの管理を一元的にサーバで行うようにすることで、さまざまな端末から本システムを利用できるようになり、各端末のメンテナンスの負荷も軽減できる。また、ＡＰサーバのコンポーネント機能として、営業店における事務処理の１ステップをコンポーネント、メソッドの単位としたコンポーネントを提供し、これらコンポーネントを順に呼び出すコンポーネントフロー制御部を提供することで、営業店事務の開発を容易にすることができる。
【００６２】
尚、本発明は、金融機関に適用するのが好適であるが、複数の営業店をセンタで管理するものであれば金融機関に限らず適用可能である。
【００６３】
【発明の効果】
本発明によれば、営業店内の処理デバイスの制御機能をセンタに集中させて営業店内の処理デバイスへ指示を行う操作端末を汎用化する、即ち、処理デバイスの種類に依存せずどの端末からでも処理デバイスへ指示できるようにしたことにより、操作端末及び処理デバイスの使用効率を向上する。
【００６４】
本発明によれば、営業店内の処理デバイスの制御機能をセンタに集中させることにより、その制御機能のメンテナンスやカスタマイズも集中して行うことができ、制御機能のメンテナンスやカスタマイズの作業効率が向上し、ユーザの作業負担を低減できる。
【００６５】
本発明によれば、営業店内の処理デバイスの制御機能をセンタに集中させて営業店内の処理デバイスへ指示を行う操作端末を汎用化したことにより、制御機能の開発効率を向上する。
【００６６】
本発明によれば、営業店内の処理デバイスの制御機能をセンタに配置することにより、営業店をコンパクト化できる。
【図面の簡単な説明】
【図１】実施形態のシステム構成である。
【図２】取引を行う際に端末から送信するデータのフォーマットである。
【図３】コンポーネントフロー制御部のコンポーネントフロー管理部が管理するコンポーネントフロー管理テーブルのデータ例である。
【図４】コンポーネントフロー制御部のコンポーネントフロー管理部が管理するコンポーネントフロー状態管理データのデータ例である。
【図５】デバイス管理部が管理するデバイス構成定義テーブルのデータ例である。
【図６】デバイス管理部が管理するデバイス状態管理データのデータ例である。
【図７】各端末での処理を示すフロー図である。
【図８】コンポーネントフローを呼び出す処理の詳細を示すフロー図である。
【図９】コンポーネントフローを判別する処理の詳細を示すフロー図である。
【図１０】デバイス制御処理を示すフロー図である。
【図１１】窓口端末での新規口座開設取引のコンポーネントフローの例である。
【図１２】新規口座開設取引の処理を示すフロー図である。
【図１３】窓口端末での支払取引のコンポーネントフローの例である。
【図１４】支払取引の処理を示すフロー図である。
【符号の説明】
１０１…ネットワーク、１０２…営業店、１０３…電算センタ、１１１…受付端末、１１２…ロビー端末、１１３…窓口端末、１１４…後方端末、１１５…自動機、１１６…スキャナ、１１７…伝票プリンタ、１１８…現金入出金機、１１９通帳発行記帳機、１２０…デバイス制御サーバ、１３１…ＡＰサーバ、１４３…コンポーネント、１４４…コンポーネントフロー制御部、１４５…ワークフロー制御部。
【図１】
2004348309.tif 000003
【図２】
2004348309.tif 000004
【図３】
2004348309.tif 000005
【図４】
2004348309.tif 000006
【図５】
2004348309.tif 000007
【図６】
2004348309.tif 000008
【図７】
2004348309.tif 000009
【図８】
2004348309.tif 000010
【図９】
2004348309.tif 000011
【図１０】
2004348309.tif 000012
【図１１】
2004348309.tif 000013
【図１２】
2004348309.tif 000014
【図１３】
2004348309.tif 000015
【図１４】
2004348309.tif 000016