JP2007140893A - 営業店システムにおける取引連携方法 - Google Patents

Abstract

【課題】
口座を有しない顧客やこれから口座を設けようとする顧客（カードなどを有しない）の取引に関して、営業店システムの各端末（装置）での連携処理は考慮されていなかった。
【解決手段】
上記の課題を解決するために、本発明では、顧客が口座を有しない場合、口座を有しなくとも実行可能な取引を抽出し、また、入力された取引についての（仮の）権限を発行する。そして、この権限を利用して複数の取引端末を連携して、取引を可能にする。この権限に関しては，取引用のカードを発行することが含まれる。また、個人を特定するために、指や手のひらの静脈を含む生体情報を用いることも含まれる。
【選択図】 図１

Description

本発明は、いわゆる営業店において、２以上の端末装置が連携して顧客から要求される取引を実現する技術に関する。

従来、２以上の端末装置が連携して取引を実現するものとして、特許文献１がある。特許文献１においては、プレ端末装置で取引情報およびバイオメトリクスデータを入力しておき、自動取引装置で取引を開始すると、顧客のバイオメトリクスデータを取得し、プレ端末装置で入力されたものと比較して本人確認を行う。本人確認がされると、プレ端末装置で入力された取引情報に基づいた取引が開始される。

特開平１１−４５３６４号公報

しかしながら、特許文献１においては、予め顧客が口座を有することを前提としている。これは、００１４項にあるようにホストコンピュータから顧客に対する預貯金データを取得、との記載から明らかである。このため、口座を有しない顧客やこれから口座を設けようとする顧客（カードなどを有しない）の取引は対応できないとの問題がある。

また、顧客が１つの取引を行うことしか記載されていない。つまり、顧客が一度の来店で複数の取引を希望する場合に関しては，考慮されていない。このため、特許文献１においては、１つ目の取引が終わったあと、再度プレ端末から取引を開始しなければならない。

上記の課題を解決するために、本発明では、顧客が口座を有しない場合、口座を有しなくとも実行可能な取引を抽出し、また、入力された取引についての（仮の）権限を発行する。この権限に関しては，取引用のカードを発行することが含まれる。また、個人を特定するために、指や手のひらの静脈を含む生体情報を用いることも含まれる。

また、本発明には、２以上の取引が要求された場合、自動取引装置でそれらの取引に必要な合計金額を含む「総合」取引情報を提示することも含まれる。

詳細には、本発明には以下の態様が含まれる。取引に関する情報処理を実行する営業店サーバとネットワークを介して接続された複数の取引端末を有する営業店システムにより前記取引に関する制御を実行する営業店システムにおける取引連携方法において、前記複数の取引端末に含まれる第１の取引端末が、前記顧客から取引内容を含む取引要求を受付け、前記第１の取引端末が、本人を確認するための本人確認情報を受付け、当該取引で使用する個人（取引）識別情報の入力を受付け、前記営業店サーバは、前記第１の取引端末から前記取引要求および前記個人（取引）識別情報を受信し、前記営業店サーバは、前記取引要求で特定される取引のための手続きを受付ける第２の取引端末を特定して、前記第１の取引端末に通知し、前記第１の取引端末は、通知された前記第２の取引端末を特定する情報を出力し、前記第２の取引端末は、前記顧客の操作に応じて、個人（取引）識別情報を入力し、前記第２の取引端末は、前記営業店サーバに、入力された前記個人（取引）識別情報を送信し、前記営業店サーバは、送信された前記個人（取引）識別情報を用いて、前記顧客の要求した取引を特定して、前記第２の取引端末に送信し、前記第２の取引端末は、前記取引を実行するために操作を促す表示を出力する。なお、個人（取引）識別情報は、当該取引にのみ使用するものであってもよい。但し、これは一旦取引が終了した後、他の顧客もしくは当該顧客が使用するものを妨げるものでない。

また、上記の処理において、以下の処理を実行することも本発明の態様に含まれる。

前記第１の取引端末は、前記顧客から当該顧客が口座を有しない旨の情報を受付けて、前記顧客が可能な取引を表示して、表示された取引に対する前記顧客の選択により前記取引要求を受ける。

前記第１の取引端末は、前記顧客から当該顧客が口座を有しない旨の情報を受付けて、口座を有しない者が可能な取引を特定して、前記顧客が可能な取引を表示する。

前記第１の取引端末は、前記顧客から当該顧客が口座を有しない旨の情報を受付けて、前記営業店サーバに送信し、前記営業店サーバが、口座を有しない者が可能な取引を特定して、特定された前記取引を示す情報を、前記第１の取引端末に送信し、前記第１の取引端末は、受信した情報に基づいて、前記顧客が可能な取引を表示する。

前記第1の取引端末が前記顧客から複数の取引についての取引要求を受付けたとき、前記営業店サーバが前記第２の取引端末として複数の取引端末を特定した場合、前記第１の取引端末に特定された複数の取引端末を通知し、前記第1の取引端末は、通知された前記複数の取引端末を特定する情報を出力する。

前記第１の取引端末は、前記複数の取引に含まれる第１の取引についての第１の取引要求を受付け、前記第１の取引で要求される第１の本人確認情報を特定して、当該第１の本人確認情報の入力を前記顧客から受付け、前記複数の取引に含まれる第２の取引についての第２の取引要求を受付け、前記第２の取引で要求される第２の本人確認情報を特定して、当該第２の本人確認情報と前記第１の本人確認情報を比較し、前記比較の結果、前記第２の取引に特有な本人確認情報を特定して、当該特有な本人確認情報の入力を促す表示を出力する。

前記営業店サーバは、前記特定された前記複数の取引端末から最初に前記顧客を誘導する入金取引端末を特定し、前記複数の取引で前記顧客が入金すべき合計金額を算出し、前記当該入金取引端末に対して、算出された前記合計金額を前記入金取引端末に通知し、前記入金取引端末は、前記合計金額を表示することにより、前記顧客に対して入金を促す。

前記入金取引端末は、前記顧客から受付けられた入金金額を計数し、計数された入金金額が前記合計金額に不足する場合、前記複数の取引から前記入金金額で対応可能な取引を表示し、前記顧客が表示された取引に対する選択を受付けて、前記営業店サーバに送信し、前記営業店サーバは、前記選択に応じて、前記複数の取引の管理情報を制御する。

前記営業店サーバは、前記選択に応じて、前記選択された取引の管理情報に対して取引実施と制御し、および／または前記選択されなかった取引の管理情報に対して取引不実施と制御する。

前記入金取引端末は、前記複数の取引の取引から、優先順位に従って前記取引可能な取引を表示する。

前記前記優先順位は、前記複数の取引それぞれの金額の大小、支払い期日および取引種別の少なくとも１つに従って決定する。

前記優先順位は、前記入金取引端末もしくは営業店サーバが決定する。

前記営業店サーバは、前記第1の取引端末から受信した前記本人確認情報を記憶し、前記取引の終了状態を、前記複数の取引端末のいずれかの通知に基づいて判定し、前記「終了状態」が検知された場合、記憶された前記本人確認情報を消去する。なお、終了状態とは、所定の段階まで終了であり、顧客入力終了、取引終了、当該営業店から情報を出したとき、入力等終了後一定期間後などが含まれる。

前記第２の取引端末として、複数の取引端末が特定された場合、前記営業店サーバは、前記複数の第２の取引端末のうち、最後に誘導する最終取引端末を特定し、特定された前記最終取引端末は、前記取引を実行するための情報である取引実施通知を、前記営業店サーバに送信し、前記営業店サーバは、前記取引実施通知を受信した場合、前記「終了状態」と判定して、前記記憶された前記本人確認情報を消去することを特徴とする営業店システムにおける取引連携方法。

なお、本発明には、上述の処理を実行する営業店システム、営業店サーバ、その他処理装置およびコンピュータで読取可能な媒体に格納されたプログラムも含まれる。また、このプログラムはネットワークを介して配信されてもよい。

本発明によれば、口座が無い顧客にも連携処理による取引を実現することが可能になる。また、２以上の取引についても連携処理による取引が可能になる。

本発明の実施の形態について、図面を用いて説明する。本実施の形態は、金融機関の営業店システム（窓口システム）を例に説明するが、本発明はそれに限定されるものではない。

まず、本実施の形態におけるシステム構成図を図1に示す。本システムは、営業店システムサーバ１３０がネットワーク１９１を介して営業店１００内の各装置に、またネットワーク１９０を介して営業店外１１０に存在する各装置に接続されている。各コンピュータ(装置)は、メモリ、ハードディスクを含む記憶装置、ＣＰＵなどの処理装置を有し、記憶装置に格納されたプログラムに従って、処理装置が情報処理を実行するものである。ここで、営業店１００の各装置としては、携帯端末(含む携帯電話)１０１、金融デバイス１０２、顧客操作型専用端末１０４、情報／相談端末１０５、自動取引装置（ATM）１０６および窓口端末１０７が含まれる。また、営業店外１１０に存在する装置としては顧客操作型端末１１１がある。また、その他、顧客のパーソナルコンピュータや携帯電話であってもよい。また、ネットワーク１９１は当該営業店の専用回線(含むいわゆるイントラネット)とし、ネットワーク１９０としてインターネットを利用してもよい。

また、営業店システムサーバ１３０には、ＣＰＵを含む処理部１０００と記憶装置を有し、処理部１３０は記憶装置に格納されたプログラムに従って、各処理を実行する。プログラムは、取引状態を制御する取引状態制御部１３１、顧客の誘導先の装置（端末）を決定する誘導先決定部１３２およびシシステム間の連携を行うシステム連携部１３３を含む。また、記憶装置には、仮カード・指静脈情報を格納する仮カード・指静脈情報保持テーブル２０００、顧客の取引情報を格納する取引情報テーブル３０００、顧客の誘導先（装置、端末）を決定するために用いる誘導先テーブル４０００を記憶する。

以下、図５および図６のフローチャートを用いて、本実施の形態の処理内容を説明する。まず、図5を用いて、取引受付処理を説明する。

まず、顧客が、顧客操作型端末１０４（もしくは１１１）での操作を行う。顧客操作型端末１０４とは、顧客が操作可能で、営業店への来訪の受付け処理などを行うもので、いわゆるタッチパネルなどの入力デバイスを有する。また、表示画面も有している。

顧客操作型端末１０４は、初期状態として、待受け画面を表示する（５０１）。例えば、図７（ａ）に示すような顧客からの入力を促す画面を表示する。次に、顧客からの入力（画面に触れる）ことを検知した場合、ステップ５０２に進む。つまり、図７（ｂ）に示すようなカードの挿入を促すカード挿入画面を表示する。また、図７（ｂ）に示すように「カードはない」との選択ボタンも表示する。ここで、顧客がカード（すなわち、キャッシュカードなど）を挿入した場合、取引画面を表示し、表示された取引から顧客が選択した取引を開始する。つまり、ＩＣカードに記載された内容および選択された取引内容に応じて誘導先を表示する。

ステップ５０３において、顧客操作型端末１０４が顧客から「カードはない」とのボタンの押下を検知した場合には、ステップ５０４に進む。

ステップ５０４では、図７（ｃ）に示すような顧客がこれから行う取引を選択（もしくは指示）するための取引メニューを表示する。ここで、取引画面は、カード挿入の場合とカードなしの場合で変えてもよい。つまり、カード（もしくは口座）を有する顧客と有しない顧客で、可能な取引を変える。例えば、カード有りの場合、当該営業店で取引可能な取引を表示するのに対し、カードなしの場合、振込、新規口座開設、税公金支払い、両替に限定してもよい。このために、顧客操作型端末１０４では、各取引とカードの有無により取引可能か否かを示す情報を対応付けて記憶しておき、この内容に基づいて表示を制御する。

また、ステップ５０４は、顧客が誤ったカードをステップ５０３で挿入した場合に、上記の表示を行ってもよい。つまり、顧客操作型端末１０４は、カードに記憶された銀行識別情報に基づいて、当該営業店の所属する銀行のカードか否かを判定し、否と判定した場合ステップ５０４に進む。なお、直接ステップ５０４に進まず、エラーメッセージを表示したり、エラーメッセージの表示からステップ５０４に進だりしてもよい。

次に、ステップ５０５において、顧客操作型端末１０４は、顧客から取引（メニュー）の選択を受付け、その選択内容を検知する。本実施の形態では、振込が選択されたものとして説明する。

ステップ５０６において、顧客操作型取引端末１０４は、ステップ５０５での取引選択（検知）を受け、当該取引に必要な「本人確認資料」を読み込むための画面を表示する。振込の場合でも、マネーロンダリングの問題があるので、本人を確認するための情報が必要になる。ここでは、図７（ｄ）に示すように運転免許証の挿入を要求する画面を表示する。

これに応じて,顧客が運転免許証を挿入すると、顧客操作型端末１０４は、運転免許証の挿入を検知し（ステップ５０７）、本運転免許証の読取、顧客に返却（挿入口もしくは返却口に出力）する８ステップ５０８）。この際、図７（ｅ）に示すような画面を表示してもよい。なお、運転免許証の読み取りとは、スキャナ等での光学的にイメージデータを読み取ることが含まれる。また、読み取られたイメージデータに対して文字認識処理を実行してもよい。

ステップ５１０において、顧客操作型端末１０４は、ステップ５０４、５０５で選択された取引つまり現金振込に必要な取引情報の入力を促す取引情報入力画面を表示する。まず、図７（ｆ）〜図８（ｂ）に示すような画面を表示する。図７（ｆ）〜図８（ｂ）ではそれぞれ顧客の氏名、顧客の電話番号、振込先の金融機関名、振込先の支店名、振込先の口座の科目、振込先の口座番号および振込金額の入力を促す。なお、ここで受付ける取引情報は、振込先およびその金額をシステム側で特定できる情報であればよく、上述した情報以外であってもよい。また、顧客の氏名、電話番号などの顧客を特定するための情報は無くともよい。

ステップ５１１で、顧客操作型端末１０４は、取引情報の入力（確認）を検知し、この取引情報およびステップ５０６で読み込んだ本人確認情報を、営業店システムサーバ１０３に送信する。なお、ステップ５１１において、顧客操作型端末１０４は、顧客を特定するための情報（氏名）と本人確認情報（運転免許証の氏名）を比較して、一致しない場合、表示画面にエラーメッセージを表示し、顧客に再入力を促してもよい。なお、顧客操作型端末１０４は、図８（ｃ）に示すように取引内容を表示し、確認入力を促してもよい。

次に、ステップ５５１で、営業店システムサーバ１０３は、送信された取引情報および本人確認情報を受信して、記憶装置に格納する。なお、取引情報は、取引情報テーブル３０００に格納される。この際、本取引を識別する取引識別情報を発行し、これも対応付けて格納する。このように格納した場合、確認情報を顧客操作型端末１０４に通知する。なお、この通知には、本取引を識別する取引識別情報が含まれる。

ステップ５１２で、顧客操作型端末１０４は、他の取引である次取引（現金振込であっても他の振込先など別取引とするものは含まれる）の有無の確認をするための自取引確認画面を表示する。この画面例としては、図８（ｃ）に示すものがある。

ステップ５１３で、顧客操作型端末１０４は、次取引確認画面に対する顧客の入力内容を検知する。図８（ｃ）に示す自取引確認画面で「振込先を追加」の選択を検知した場合、ステップ５１０に戻り上述した処理を繰り返す。また、「次取引実施」の選択を検知した場合、ステップ５０４に戻る。この場合の処理の内容に関しては後述する。さらに、「確認」の選択を検知した場合、ステップ５１４に進む。この内容に関しても後述する。

次に、「次取引実施」の選択を検知した場合にステップ５０４に戻った場合の処理について、説明する。まず、ステップ５０４で、顧客操作型端末１０４は、カードなしの取引メニューを表示する。これは、本実施の形態では、カードなしの顧客を例に説明しているためである。そして、ステップ５０５では、顧客操作型端末１０４は、顧客から取引（メニュー）の選択を受付ける。ここで、選択された取引と先に選択された取引の内容を比較する。この結果、一致する場合には、ステップ５１０に進み同様の処理を行う。また、一致しない場合、予め各取引（メニュー）に対応付けて記憶された当該取引に必要な本人確認情報の比較を行う。つまり、先に選択された取引に対応付けられた本人確認情報と今回選択された取引に対応付けられた本人確認情報を比較する。この結果、一致する場合および先に選択された取引の本人確認情報に今回選択された取引の本人確認情報が含まれる場合には、ステップ５１０に進む。比較の結果、不足する本人確認情報がある場合には、不足する本人確認情報の入力を促すよう、ステップ５０７に進む。

その後、ステップ５０７〜５１０を実行し、ステップ５１１に進む。ステップ５１１では、本人確認情報および取引情報を送信するが、本実施の形態のように先に送信がある場合には、ステップ５５１で送信される取引識別情報を送信する。なお、この取引識別情報は、先に送信した取引情報等との対応付けすることができるものであればよい。このため、先に送信された取引識別情報を所定の規則で変換したものであってもよいし、同じものであってもよい。以上で、「次取引実施」の場合の説明を終わる。

次に、ステップ５１４以降の処理について説明する。ステップ５１４では、顧客操作型端末１０４は、本取引における各端末（装置）間の連携を行うための情報入力を促す表示をする。本実施の形態では、仮カードの発行もしくは指静脈登録のいずれかを選択するようにする（図８（ｅ）参照）。なお、これら以外の方法、例えば他の生体情報（指紋、虹彩など）を使ったり、識別情報を画面上に表示してこれを顧客が記憶したりするようにしてもよい。

ステップ５１５では、顧客操作型端末１０４では、ステップ５１４の表示画面に対する選択を、顧客操作型端末１０４が顧客から受付ける。この結果、仮カードの選択を検知した場合、ステップ５１６に進む。また、指静脈登録の選択を検知した場合、ステップ５１８に進む。

まず、仮カードの場合について、説明する。ステップ５１６で、顧客操作型端末１０４は、本人確認情報を受付ける。これは、営業店の店員（行員）が、顧客に対して質問をしたり、目視したりした結果を受付ける。これは、顧客操作型端末１０４が店員からの入力を受付けてもよいし、窓口端末１０７などの装置に対して店員が入力し、これをネットワークを介して顧客操作型端末１０４が受信してもよい。さらに店員が確認するのでなく、顧客が自身の情報を入力し、本人確認情報を営業店システムサーバ１０３から検索して、これを表示し、顧客自身に確認させてもよい。なお、本人確認中には、図８（ｈ）に示すような表示を画面上に行っていてもよい。そして、確認結果を受けつけた場合、図８（ｉ）に示すような本人の情報を表示してもよい。

この情報（入力）を受付けると、ステップ５１７で、顧客操作型端末１０４は「仮カード」（本取引の連携に用いるカード）を発行する。ここで、仮カードの発行とは、当該顧客操作型端末１０４内に保管され、本カードの識別情報である仮カードＩＤが格納された仮カードを出力することが含まれる。また、仮カードＩＤとステップ５５１で通知された取引識別情報を、顧客操作型端末１０４から営業店システムサーバ１０３に送信する。つまり、顧客操作型端末１０４では、仮カードから仮カードＩＤを読み出し、またステップ５５１で通知され記憶装置に格納した取引識別情報を読み出し、これらを送信する。さらに、保管される仮カードには、仮カードＩＤを記憶しておかず、本人確認を受け、仮カードＩＤを顧客操作型端末１０４が生成し、これを仮カードに書き込むように構成してもよい。この場合、仮カードＩＤを上記の取引識別情報としてもよいし、生成した仮カードＩＤと取引識別情報を仮カードに書き込んでもよい。

この送信を受け、ステップ５５２で、営業店システムサーバ１０３は、図２に示す仮カード・指静脈情報保持テーブル２０００に送信された情報を格納する。つまり、送信された仮カードＩＤを２２００へ、取引識別情報を２１００に仮ＩＤとして格納する。ここで、図２では仮ＩＤが１つしかないが、複数の取引識別情報がある場合、１つのセル（エリア）中に複数の仮ＩＤを格納してもよいし、複数のレコードに分けて格納してもよい。

また、本実施の形態では、仮カードＩＤと仮ＩＤ（取引識別情報）は別のものとして扱っているが、同じもの（もしくは互いに所定の関係を有するもの）としてもよい。この場合、予め顧客操作型端末１０４に保管される仮カードには仮カードＩＤを格納しておかなくともよい。ステップ５１７で、顧客操作型端末１０４は、取引識別情報を仮カードに書込み、これを用いてもよい。この場合には、仮カード・指静脈情報保持テーブル２０００には、仮カードＩＤを格納するエリアを設けなくともよい。さらに、仮カードは、店員が保持し、本人確認が完了した場合に、手渡しで顧客に渡してもよい。以上で、ステップ５１５で仮カードとなった場合の説明を終わる。

次に、ステップ５１５で、指静脈登録となった場合について、説明する。ステップ５１８において、顧客操作型端末１０４は、指静脈登録実施画面を表示する。例えば、図８（ｆ）に示すような指をリーダに置くことを促す表示をする。なお、リーダに関しては特に図示しないが、顧客操作型端末１０４と一体になっているものであってもよいし、ケーブル等で接続されているものであってもよい。

ステップ５１８に応じて顧客が指をリーダに置いた場合、ステップ５１９で顧客操作型端末１０４はリーダを介して顧客の指静脈情報を読み取る。読取がされた場合、図８（ｇ）に示す表示画面を表示し、ステップ５２０に進む。ステップ５２０では、ステップ５１６と同様の処理を実行です。そして、確認された場合、ステップ５１７と同様に、指静脈情報と取引識別情報を、顧客操作型端末１０４から営業店システムサーバ１０３に送信し、仮カード・指静脈情報保持テーブル２０００に格納する。先にステップ５１７で説明したように指静脈情報を仮カードＩＤと同じように扱ってもよい。但し、指静脈情報と仮ＩＤとして扱う（処理）する場合には、以下のように処理を行う。まず、取引識別情報と指静脈を受信した営業店システムサーバ１０３は、ステップ５５１で格納された取引識別情報を指静脈に置き換える。この上で、仮カード・指静脈情報保持テーブル２０００には指静脈情報を格納する。なお、仮カード・指静脈情報保持テーブル２０００は、仮カードの情報もしくは指静脈の情報のみを登録するようにしてもよい。

次に、ステップ５５３で、営業店システムサーバ１０３は、仮カードＩＤ（指静脈情報、仮ＩＤ）で識別される取引について、その顧客の誘導先を判断する。営業店システムサーバ１０３には、各取引に対応させて、その取引で用いる取引端末をテーブルとして記憶しておく（例えば、現金振込−ＡＴＭ、税公金支払い−窓口端末）。本テーブルとステップ５５１で格納された情報を突き合わせて、顧客が要求している取引に用いる端末（装置）を特定する。また、各取引もしくは各端末の誘導先の優先順位をテーブルとして記憶しておく。そして、特定された端末もしくは入力されている取引に用いて、誘導先の順位を定める。例えば、ＡＴＭ−１、窓口端末―２、情報／相談端末―３と順位付けて記憶してもよいし、ぞれぞれの端末（取引）のいずれが優先（もしくは後になるか）を示すマトリックスとして記憶しておいてもよい。さらに、各端末の種別毎としてもよいし、個々の端末ごとに優先順位を記憶していてもよい。

これを受け、本実施の形態では、営業店システムサーバ１０３が誘導先を順位付けして特定し、これを顧客操作型端末１０４に送信する。また、本誘導先を営業店システムサーバ１０３は記憶しておく。

これを受け、ステップ５２１において、顧客操作型端末１０４では、取引受付が完了した旨の表示を図８（ｊ）のように行う。この際、受付票（紙）を出力してもよい。この受付票には、仮ＩＤを2次元バーコードや数値として印刷してもよいし、また、取引内容（金額を含む）や誘導先を印刷していてもよい。また、顧客操作型端末１０４は、図９（ａ）に示すような、誘導先を示す情報を表示する。以上で、受付処理についての説明を終わる。なお、以上の受付処理において、顧客操作型端末１０４は、営業店システムサーバ１０３からステップ５５１の通知を受信したことを条件に、顧客操作型端末１０４に記憶した本人確認情報を消去してもよい。また、条件としては、ステップ５５３の誘導先に関する情報を受信したこととしてもよい。さらにこれらの場合、表示画面もしくは受付伝票に消去した旨を出力してもよい。

さらに、顧客操作型端末１１１すなわち、営業店外１１０に設置された顧客操作型端末が使用された場合、誘導画面として営業店を特定する情報（地図、営業店名など）を出力してもよい。この営業店を特定する情報は、上述した端末を特定する情報と併せて、もしくは連続的に表示してもよい。これらの場合、当該顧客操作型端末１１１は、誘導する営業店を予め記憶しておいてもよいし、複数の営業店の情報を有し、それぞれで可能な取引を示す情報を対応付けて記憶しておいてもよい。さらに、可能な取引を示す情報としては、端末（装置）を特定する情報を用いてもよい。

続いて、図６を用いて受付後の取引に関する処理について、説明する。まず、顧客は、図９（ａ）の表示に従って、ＡＴＭ１０６へ移動する。

ＡＴＭ１０６では、図９（ｂ）もしくは２９に示すような待受画面を表示している（ステップ６０１）。例えば、当該端末がＡＴＭ以外の機能も有する場合、ＡＴＭ機能を実行可能な状況の際に、図９（ｂ）に示す待受画面を表示する。この待受画面に顧客がタッチしたことを検知すると、図９（ｃ）に示すカード挿入画面に遷移する。なお、上述したとおり、図９（ｃ）を待受画面として使用してもよい。

次に、カード挿入画面に対する入力を検知すると、入力の内容に従ってＡＴＭ１０６は以下のように、識別情報を取り込み、営業店システムサーバ１０３に送信する（ステップ６０３）。ここで、識別情報とは、取引、仮カード、顧客のうち少なくとも１つを識別するものである。（１）仮カードの挿入を検知した場合、当該仮カードに格納された仮カード情報を読み取り、営業店システムサーバ１０３に送信する。仮カード情報には、仮カードＩＤが含まれる。また、取引情報識別情報が格納されている場合には、これも仮カード情報に含めてもよい。（２）カード挿入画面に対して「カードはない」を押下されたことを検知した場合、図９（ｄ）に示すような「指」（生体）をリーダに置くように促す表示を行う。この表示において、指の置き方の説明をアニメーションや文字で表示してもよい。そして、ＡＴＭ１０６は、この表示に応じて指がリーダに置かれた場合、その生体情報である指静脈情報をリーダを介して読み取る。そして、ＡＴＭ１０６は、読み取られた指静脈情報を、営業店システムサーバ１０３に送信する。

次に、ステップ６５１において、営業店システムサーバ１０３は、受信した識別情報の認証処理を実行する。受信した認証情報に対応する情報を仮カード・指静脈情報保持テーブル２０００から検索する。検索された情報があった場合、当該情報に対応する取引情報を取引情報テーブル３０００から検索し、ＡＴＭ１０６に送信する。以下、仮カード使用と指静脈情報使用に分けてその処理内容を説明する。

（１）仮カードＩＤ：取引情報として仮カードＩＤ＝１２３４５６７を受信したとする。この仮カードＩＤをキーに、仮カード・指静脈情報保持テーブル２０００を検索すると、仮カードＩＤ＝１２３４５６７の仮ＩＤが３００９８１１を検索する。次に、検索された仮カードＩＤをキーに、取引情報テーブル３０００を検索すると、以下の２つの取引情報を検索する。
取引情報１：取引名称＝振込み、ステータス＝未入金、取引内容＝20000円、××向け
取引情報２：取引名称＝税公金支払い、ステータス＝事前入力済み、取引内容＝3500円、○○県
ここで、検索された取引情報１、２は、所定のテーブルに格納する。この際、仮ＩＤも対応付けて記録してもよい。この記録する際、本取引情報１，２が記録されているか確認してから記録する。この確認処理は、仮ＩＤを用いて行ってもよい。また、テーブルへの記録の代わりに、取引情報テーブル３００に検索されたことを示す情報（例：フラグ）を記録してもよい。

なお、送信される取引識別情報が、仮ＩＤ（取引識別情報）を含む場合、これをキーに取引情報テーブル３０００を検索してもよい。

そして、営業店システムサーバ１０３は、検索された取引情報から取引情報１を抽出する。この抽出の処理は以下のようにして行う。ステップ６５１において、ＡＴＭ１０６の端末種別を識別する端末種別識別情報「ＡＴＭ」を受信する。この端末種別情報「ＡＴＭ」をキーに、誘導先テーブル４０００（誘導先）から取引名称「振込み」を検索する。この取引名称「振込み」を含む取引情報は取引情報１のため、本取引は取引情報１で特定する。

またさらに、営業店システムサーバ１０３は、取引情報１と２の金額を合算する。この結果、取引情報１および合算された合計金額をＡＴＭ１０６に送信する。なお、送信前に、ステータスを確認し、入金済など取引済であることを示す場合は、取引終了である旨の情報を送信する。この際、ステップ５５３で記憶された誘導先を用いて、次に誘導する端末を特定する情報を送信してもよい。ここで、ＡＴＭに対応する取引が複数検索された場合、そのそれぞれを送信する。

なお、ここでは、取引情報１，２の合計金額を算出したが、この処理は省いてもよい。この場合、取情報２の取引を実行させる際、再度入金をさせるようにする。

（２）指静脈情報：指静脈情報を用いる場合も基本的には、（１）仮カードＩＤを用いる処理と同様である。違いは、用いる情報が異なる点であり、その他の処理は同様である。

なお、取引情報の取引内容は取引の内容を特定するものであり、少なくとも金額および振込み先などの相手を特定する情報が含まれる。相手を特定する情報としては、口座番号、銀行名、などが含まれる。

次に、ステップ６０４において、ＡＴＭ１０６は、受信した取引情報（含む合計金額）を取引内容確認画面として、表示する。取引内容確認画面は、図９（ｅ）に示すように、取引名称、取引金額、取引先が含まれる。このように、送信された取引情報そのものでなく、変換（一部抽出を含む）を行ってもよい。なお、ＡＴＭでの取引が複数ある場合、所定の順序で取引情報を表示してもよいし、複数の取引情報に関する情報を表示し、取引の選択を促すようにしてもよい。ここで、取引内容確認画面に対する「確認」の押下を検知すると、ステップ６０５に遷移する。

ステップ６０５では、ＡＴＭ１０６は、図９（ｆ）に示すような振込み（のための入金）を促す画面を表示する。そして、入金を受付けると貨幣をカウントし、問題がなければ入金がされたことを示す入金情報を営業店システムサーバ１０３に送信する。入金情報には、当該取引の仮ＩＤ（仮カードＩＤ、指静脈情報）を含めてもよい。

また、ステップ６０５で、ＡＴＭ１０６は、図９（ｇ）〜３５のような表示を行ってもよい。図９（ｇ）では、処理中である場合に表示をし、図９（ｆ）にはカウントした結果を表示する。そして「確認」が押下されたことを検知すると、上述した送信を行い、また、図９（ｉ）に示すような画面を表示し、明細票およびおつりがある場合には、おつりを出力する。

なお、ステップ６０５で、入金された貨幣が上記の合計金額に不足ことを検知した場合、以下のように処理を実行する。
（１）不足している金額が、次のどの状態かを判定する。（ａ）取引情報１、２共に不足する、（ｂ）取引情報１，２いずれか一方を支払うと他方は不足する、（ｂ）−１取引情報１の分は足りているが、取引情報２の金額を加えると不足する、（ｂ）−２取引情報２の分は足りているが、取引情報１の金額を加えると不足する、（ｂ）−３取引情報１，２との単独ならそれぞれ支払えるが両方には不足する。
（２）（ａ）と判定した場合、エラーメッセージを表示し、不足分の入金を促す。これでも不足する場合には、先に入金した貨幣を返却する。
（３）（ｂ）−１，２のいずれかと判定した場合には、その旨を表示する。その表示内容は、不足していること、不足している取引（「振込み」(取引情報１)もしくは「税公金支払い」（取引情報２））、不足金額、入金金額で支払い可能な取引のみ支払うことの選択のためのボタンが含まれる。ここで、ボタンが押下されたことを検知すると、取引可能な取引についての処理を上述したとおり進める。但し、不足分の取引に関しては、取引中止を示す中止情報を営業店システムサーバ３に送信する。なお、（２）と同様に、入金がない場合は取引を終了し、入金金額を返却する。
（４）（ｂ）−３と判定した場合、（３）両方支払うには不足していることおよび再入金もしくはいずれか一方の選択を促すボタンを表示する。また、この代わりに、予め定められた優先順の高い取引を実行することを承認させるボタンを表示してもよい。以降、（３）と同様の処理を実行する。

ステップ６５２では、営業店システムサーバ１０３は、入金情報を受信すると、取引情報テーブル３０００のステータスの書き換えを行う。つまり、仮ＩＤ３００９８１１のステータスを「未入金」から「入金済」に変更する。また、検索された取引情報（取引情報１，２）を格納したテーブルから取引情報１を消去する。消去の代わりに、入金済であることを示す情報を書き込んでもよい。また、本テーブルでなく、取引情報テーブル３０００にフラグを記録した場合、本フラグを消去する。

なお、営業店システムサーバ１０３が、中止情報を受信した場合、検索された取引情報を格納したテーブルから該当する取引情報を消去もしくは中止（もしくは終了）を示すフラグの書込みを行う。また、取引情報テーブル３０００に記録したフラグを消去してもよい。

ステップ６５３で、営業店システムサーバ１０３は、他の誘導先の有無を判断する。これは、ステップ６５１で検索された取引情報を用いて判断する。すなわち、検索された取引情報を格納したテーブルに、残っている取引情報を抽出する。残っている取引情報とは、消去されず残っているもの、フラグが処理未済となっているものである。また、取引情報テーブル３０００を用いる場合には、フラグが記録されているものを抽出する。この結果、取引情報が抽出された場合には、他の誘導先があると判断する。そして、営業店システムサーバ１０３は、ステップ６５１で説明した方法と同様の処理を行うことで、他の誘導先を特定する。また、この誘導先の特定は、ステップ５５３で記録された誘導先を用いて判断してもよい。

本実施の形態では、（取引情報２により）窓口端末が特定されたものとして説明する。営業店システムサーバ１０３は、ＡＴＭ１０６に、次の誘導先が「窓口端末」であることを示す情報を送信する。また、無い場合は、他の誘導先が無いことを示す情報を送信してもよいし、特に情報を送信しなくともよい。また、送信される情報は、営業店システムサーバ１０３で処理を行ったことを示す確認情報と送信してもよい。

ステップ６０６で、ＡＴＭ１０６は、営業店システムサーバ１０３から受信した情報に基づいて、誘導先の有無を判断する。情報に誘導先を示す情報がある場合には有りと判断し、ステップ６１０に進み、受信した情報に基づいて誘導先「窓口端末」を示す情報を表示する（図９（ｊ））。また、仮カードがある場合には、仮カードを出力し、顧客が引き取れるようにする。

誘導先が無しと判断された場合、ステップ６０７に進む。ステップ６０７で、ＡＴＭ１０６は、本取引に仮カードが利用されたかを判断し、有る場合には仮カードを回収し（ステップ６０８）、ステップ６０９に進み取引を終了する。また、仮カードの利用がないと判断された場合には。ステップ６０７からステップ６０９に進み、取引を終了する。

次に、他の誘導先（取引）がある場合について、窓口端末１０７を用いた税公金支払いを例に説明する。なお、本窓口端末１０７は、静脈情報もしくは仮カードの情報を読み取り可能なものであり、営業店の店員が操作する。顧客は、ＡＴＭ１０６で表示に基づいて、窓口端末１０７に移動する。

まず、窓口端末１０７は、ステップ６２１で、仮カード・指静脈認証認証検知処理を行う。つまり、ＡＴＭ１０６が行ったステップ６０３と同様の処理を行う。これを受けてステップ６７１で、営業店システムサーバ１０３は、ステップ６５１と同様の処理を行う。但し、ステップ６７１で対応する端末（装置）が「窓口端末」１つもしくは取引情報が１つであると検索した場合には、合計金額を算出しなくともよい。ここでは、合計金額を算出しない場合として説明する。このため、営業店システムサーバ１０３が窓口端末１０７へ、取引情報２を送信する。

そして、ステップ６２２で、窓口端末１０７は、取引情報２に基づいて、取引のための処理を店員の操作に応じて実行する。そして、伝票のチェックなどが済み取引が終了して、店員が完了指示を入力した場合、この取引完了情報を営業店システムサーバ１０３に送信する。

ステップ６７１では、営業店システムサーバ１０３は、ステップ６５２やステップ６５３と同様の処理を実行する。ここで、本例ではステップ６７１で対応する端末（装置）が「窓口端末」１つもしくは取引情報が１つであると検索した場合であるので、取引（顧客の手続き）が終了したことを示す情報を生成して、これを窓口端末１０７に通知する。

これを受けて、ステップ６２３で窓口端末１０７は、仮カードの有無を判定する。なお、このステップは、店員が有無を判断し、これを受付けることで行ってもよい。なお、この判断はステップ６０７と同様に行う。そして、カードがあると判断した場合、ステップ６２４に進みカードを回収し、処理を終了する。また、仮カードがないと判断した場合には、そのまま処理を終了する。なお、仮カードの回収は店員が人手を介して行ってもよい。

最後に、営業店システムサーバ１０３は、上記の取引完了情報の受信、もしくは取引終了通知の送信を条件に、ステップ５５１で格納した本人確認情報を消去してもよい。この場合、取引終了通知に、消去した旨の情報を含め、窓口端末１０７に消去した旨の表示を行ってもよい。また、窓口端末１０７は、取引終了通知に消去した旨の情報が含まれない場合でも、取引終了通知の受信を条件に、消去した旨の表示をおこなってもよい。

以上で、本実施の形態についての説明を終わる。本例は、金融機関での営業店を例に説明したが、他の例（金融機関に対する代理店など）にも適用可能であり、本例に限定されるものではない。

本発明の一実施の形態のシステム構成図。 仮カード・指静脈情報保持テーブル２０００を示す図。 取引情報テーブル３０００を示す図。 誘導先テーブル４０００を示す図。 本発明の一実施の形態の受付処理を説明するフローチャート。 本発明の一実施の形態の取引処理を説明するフローチャート。 端末でのガイダンス画面を示す図（その１） 端末でのガイダンス画面を示す図（その２） 端末でのガイダンス画面を示す図（その３）

符号の説明

１０１…携帯端末、１０２…金融デバイス、１３０…営業店システムサーバ、１１１、１０４…顧客操作型端末、１０５…情報／相談端末、１０６…ＡＴＭ、１０７…窓口端末、１９０、１９１…ネットワーク

Claims (14)

1. 取引に関する情報処理を実行する営業店サーバとネットワークを介して接続された複数の取引端末を有する営業店システムにより前記取引に関する制御を実行する営業店システムにおける取引連携方法において、
   前記複数の取引端末に含まれる第１の取引端末が、前記顧客から取引内容を含む取引要求を受付け、
   前記第１の取引端末が、本人を確認するための本人確認情報を受付け、当該取引で使用する個人取引識別情報の入力を受付け、
   前記営業店サーバは、前記第１の取引端末から前記取引要求および前記個人取引識別情報を受信し、
   前記営業店サーバは、前記取引要求で特定される取引のための手続きを受付ける第２の取引端末を特定して、前記第１の取引端末に通知し、
   前記第１の取引端末は、通知された前記第２の取引端末を特定する情報を出力し、
   前記第２の取引端末は、前記顧客の操作に応じて、個人取引識別情報を入力し、
   前記第２の取引端末は、前記営業店サーバに、入力された前記個人取引識別情報を送信し、
   前記営業店サーバは、送信された前記個人取引識別情報を用いて、前記顧客の要求した取引を特定して、前記第２の取引端末に送信し、
   前記第２の取引端末は、前記取引を実行するために操作を促す表示を出力することを特徴する営業店システムにおける取引連携方法。
2. 請求項１の記載の営業店システムにおける取引連携方法において、
   前記第１の取引端末は、前記顧客から当該顧客が口座を有しない旨の情報を受付けて、前記顧客が可能な取引を表示して、
   表示された取引に対する前記顧客の選択により前記取引要求を受けることを特徴とする営業店システムにおける取引連携方法。
3. 請求項２に記載の営業店システムにおける取引連携方法において、
   前記第１の取引端末は、前記顧客から当該顧客が口座を有しない旨の情報を受付けて、口座を有しない者が可能な取引を特定して、前記顧客が可能な取引を表示することを特徴とする営業店システムにおける取引連携方法。
4. 請求項２に記載の営業店システムにおける取引連携方法において、
   前記第１の取引端末は、前記顧客から当該顧客が口座を有しない旨の情報を受付けて、前記営業店サーバに送信し、
   前記営業店サーバが、口座を有しない者が可能な取引を特定して、特定された前記取引を示す情報を、前記第１の取引端末に送信し、
   前記第１の取引端末は、受信した情報に基づいて、前記顧客が可能な取引を表示することを特徴とする営業店システムにおける取引連携方法。
5. 請求項１に記載の営業店システムにおける取引連携方法において、
   前記第1の取引端末が前記顧客から複数の取引についての取引要求を受付けたとき、前記営業店サーバが前記第２の取引端末として複数の取引端末を特定した場合、前記第１の取引端末に特定された複数の取引端末を通知し、
   前記第1の取引端末は、通知された前記複数の取引端末を特定する情報を出力することを特徴とする営業店システムにおける取引連携方法。
6. 請求項５に記載の営業店システムにおける取引連携方法において、
   前記第１の取引端末は、
   前記複数の取引に含まれる第１の取引についての第１の取引要求を受付け、
   前記第１の取引で要求される第１の本人確認情報を特定して、当該第１の本人確認情報の入力を前記顧客から受付け、
   前記複数の取引に含まれる第２の取引についての第２の取引要求を受付け、
   前記第２の取引で要求される第２の本人確認情報を特定して、当該第２の本人確認情報と前記第１の本人確認情報を比較し、
   前記比較の結果、前記第２の取引に特有な本人確認情報を特定して、当該特有な本人確認情報の入力を促す表示を出力することを特徴とする営業店システムにおける取引連携方法。
7. 請求項５または６のいずれかに記載の営業店システムにおける取引連携方法において、
   前記営業店サーバは、
   前記特定された前記複数の取引端末から最初に前記顧客を誘導する入金取引端末を特定し、
   前記複数の取引で前記顧客が入金すべき合計金額を算出し、
   前記当該入金取引端末に対して、算出された前記合計金額を前記入金取引端末に通知し、
   前記入金取引端末は、前記合計金額を表示することにより、
   前記顧客に対して入金を促すことを特徴とする営業店システムにおける取引連携方法。
8. 請求項７に記載の営業店システムにおける取引連携方法において、
   前記入金取引端末は、前記顧客から受付けられた入金金額を計数し、計数された入金金額が前記合計金額に不足する場合、前記複数の取引から前記入金金額で対応可能な取引を表示し、前記顧客が表示された取引に対する選択を受付けて、前記営業店サーバに送信し、
   前記営業店サーバは、前記選択に応じて、前記複数の取引の管理情報を制御することを特徴とする営業店システムにおける取引連携方法。
9. 請求項８に記載の営業店システムにおける取引連携方法において、
   前記営業店サーバは、前記選択に応じて、前記選択された取引の管理情報に対して取引実施と制御し、および／または前記選択されなかった取引の管理情報に対して取引不実施と制御することを特徴とする営業店システムにおける取引連携方法。
10. 請求項８または９のいずれかに記載の営業店システムにおける取引連携方法において、
    前記入金取引端末は、前記複数の取引の取引から、優先順位に従って前記取引可能な取引を表示することを特徴とする営業店システムにおける取引連携方法。
11. 請求項１０に記載の営業店システムにおける取引連携方法において、
    前記前記優先順位は、前記複数の取引それぞれの金額の大小、支払い期日および取引種別の少なくとも１つに従って決定することを特徴とする営業店システムにおける取引連携方法。
12. 請求項１１に記載の営業店システムにおける取引連携方法おいて、
    前記優先順位は、前記入金取引端末もしくは営業店サーバが決定することを特徴とする営業店システムによる取引連携方法。
13. 請求項１乃至１２のいずれかに記載の営業店システムにおける取引連携方法において、
    前記営業店サーバは、前記第1の取引端末から受信した前記本人確認情報を記憶し、前記取引の終了状態を、前記複数の取引端末のいずれかの通知に基づいて判定し、前記「終了状態が検知された場合、記憶された前記本人確認情報を消去することを特徴とする営業店システムにおける取引連携方法。
14. 請求項１３に記載の営業店システムにおける取引連携方法において、
    前記第２の取引端末として、複数の取引端末が特定された場合、
    前記営業店サーバは、前記複数の第２の取引端末のうち、最後に誘導する最終取引端末を特定し、
    特定された前記最終取引端末は、前記取引を実行するための情報である取引実施通知を、前記営業店サーバに送信し、
    前記営業店サーバは、前記取引実施通知を受信した場合、前記終了状態と判定して、前記記憶された前記本人確認情報を消去することを特徴とする営業店システムにおける取引連携方法。
    

Images