JP6257998B2 - 携帯端末活用取引システムおよび方法 - Google Patents

Description

本発明は、複数の情報処理装置を連携させて所定の処理を実行するための技術に関する。その中でも特に、情報処理装置としての携帯端末における取引の事前入力の状況に応じて最適な来店先店舗を提示し、来店後に携帯端末と取引を実行するための業務端末を連携させることで、来店後の残りの取引を効率的に実現するための技術に関する。

現在、様々なサービスが提供されるとき、取引を行う複数の情報処理装置を連携することで、取引に関する情報処理が行われている。例えば、取引物を取り扱う取引においてその取引時間を早めることができる取引方法及びそれを実行するための自動取引装置については、特許文献１に記載されている。その概要は、ホストコンピュータと通信して、取引物を取り扱う所定の取引を実行する自動取引装置を利用した取引方法において、携帯通信端末により、自動取引装置との取引で必要な取引情報をホストコンピュータに送信し、さらに、ホストコンピュータにより生成、記憶、送信される取引情報に対応する取引認証情報を受信し、自動取引装置により、携帯通信端末から送信される取引認証情報を受信し、さらに、受信した取引認証情報をホストコンピュータに送信し、ホストコンピュータから受信する取引認証情報に対応する応答情報に基づいて、取引を実行する取引方法が提供され、自動取引装置との取引で必要な処理をあらかじめ、携帯通信端末を利用して行い、あらかじめ行われたその先行処理に関連する情報（取引認証情報）を携帯通信端末から自動取引装置に送信することで、あらためて取引に必要な情報を自動取引装置に入力する必要がなくなり、その分、取引時間の短縮を図ることができることを特徴とするものである。

また、外出先等でも、顧客が最適な店舗案内を受けることができる店内案内装置については、特許文献２に記載されている。その概要は、携帯電話機のような端末機器より発信された現在地位置情報と取引要求情報に基づいて、現在地位置に近い場所に所在する店舗であって現時刻で取引要求に対応できる店舗を取引可能店舗検索部によって店舗情報記憶手段に記憶されている店舗情報より検索し、道順検索部によって現在地位置より取引可能店舗検索部によって検索された店舗までの道順を地図情報記憶手段に記憶されている地図情報より検索し、店舗情報、店舗までの道順を示す地図情報を発信元の端末機器に対して送信することを特徴とするものである。

特許第４０７６９５４号公報 特開２００２−２３６７６９号公報

特許文献１では、来店前に携帯端末を使って取引の事前入力を行い、来店時に携帯端末を自動取引装置と連携させることにより、来店後の取引時間を短縮させることが可能である。このとき、事前に携帯端末に入力すべき項目と来店後に自動取引装置に表示される画面フローは固定化されている。現金の入出金や振込みなどの単純な取引の場合、事前に必要な入力項目をすべて入力することは可能である。

しかし、投資信託や定期預金の購入などの入力項目の多い取引の場合、来店前に入力できる範囲で入力を行い、未入力項目については来店後に行員にアドバイスをもらいながら取引内容を決定したい場合がある。特許文献１では、このように顧客が希望する範囲（入力できる項目または入力したい項目）で入力することができない。

また、顧客によっては認証手段として暗証番号の入力（例えば４桁の数字の入力）を希望する顧客もいれば、生体情報認証（例えば指静脈認証）を希望する顧客もいる。さらに、顧客によっては取引画面のガイダンスの方式（取引画面の進め方）を初心者向けに分かりやすく表示する「親切方式」を希望する顧客もいれば、必要最小限の表示にとどめて取引時間を短縮させた「簡略方式」（例えば、確認画面の表示を省略）を希望する顧客もいる。特許文献１では、上述のように、事前に携帯端末に入力すべき項目と来店後に自動取引装置に表示される画面フローは固定化されているため、顧客の希望に合わせた取引手段で取引を行うことができない。

一方、特許文献２では、携帯端末の位置情報と取引種別に基づいて、最適な店舗（現在地から近い店舗、希望取引の取り扱い可能な店舗、混雑の少ない店舗）を案内することが可能である。

しかし、事前の取引入力の状況や顧客による取引手段の希望によっては、どこの店舗に行けば最適であるのかを判断することができない。例えば、事前入力の段階で購入したい投資信託商品を決定している顧客は、来店後に諸手続きを行うだけでよいので、行員のサポートは必要ないが、まだ購入したい投資信託商品を決定していない顧客は、来店後に商品知識を持った行員が対応する必要がある。また、来店後に残りの取引（商品比較やシミュレーション）を大画面ディスプレイを見ながら操作したい場合、どこの店舗に行けば利用可能な大画面ディスプレイのある端末が設置されているか分からない。
本発明では、情報処理装置（携帯端末を含む）を利用した取引における効率化を図ることが課題となる。

上述の課題を解決するために、本発明では、携帯端末を活用して取引の事前入力を行う場合に、当該事前入力の状況（内容）を含む顧客の状況（希望する取引手段やそのときの事前入力の状況）に応じた、最適な店舗を特定するものである。このことで、顧客を最適な店舗に誘導することが可能になる。なお、本願での「最適な店舗」とは、顧客の状況示す複数の要因（入力の状況など）を反映された店舗であり、少なくともその一部を満たしたもののうち、最もこれら複数の要因に適合したものである。

また、本発明の一態様として、携帯端末で入力された情報を用いてサーバ側が連携して「最適な店舗」を特定することも含まれる。

このより具体的な内容について、以下、記載する。所定の取引の一部を事前に行う携帯端末と、その取引の残りの処理を実行するための業務端末と、サーバが通信網を介して接続されているとする。携帯端末は、携帯端末を使って取引の事前入力を行う利用者が希望する取引手段を格納したパーソナライズ情報、取引種別ごとに取引内容の事前入力に必要な入力項目が定義された入力テンプレート情報、入力テンプレート情報に対して利用者による事前入力内容を保持した取引入力情報、利用者が利用可能な口座情報を保持する。また、これら各情報が、携帯端末自身が保持しなくとも、アクセス可能であればよい。

ここで、サーバは、各店舗で取り扱い可能な取引や店舗の位置情報を保持した店舗情報、各銀行内の店舗に設置されている端末と端末に装備されているデバイスに関する情報をまとめた店舗端末・デバイス情報、各銀行内における一つの取引プロセスの中で個々の操作（取引操作と呼ぶ）に必要なデバイスに関する情報をまとめた取引操作・デバイス対応情報、さらに、銀行ごとの行員スキルに関する情報や、銀行ごとの各店舗の端末使用状況や各行員の対応状況に関する情報などを保持する。

利用者からの来店前における希望する取引種別について携帯端末上での選択入力を受付け、入力できる範囲または入力したい範囲で取引内容の入力を受付け、取引入力情報として保持する。利用者からの携帯端末での取引内容の事前入力を終わらせると、サーバから上記情報を取得する。そして、取引の事前入力の内容（取引入力情報）、希望する取引手段（パーソナライズ情報）、サーバから取得した上記情報（店舗情報など）を基にして、利用者の最適な来店先店舗を計算する。具体的には、来店後に利用者の残りの取引を行うための取引プロセスに必要な端末・デバイスを設置した店舗を来店先店舗の候補として抽出する。さらに、店舗での端末・デバイスの使用状況、対応可能なスキルを持つ行員の接客状況、来店先店舗までの移動距離などの情報を基にして、来店先店舗の候補を絞り込む。これにより、利用者の状況（希望する取引手段やそのときの事前入力の状況）に応じて、利用者に最適な来店先店舗を提示することができるので、利用者は提示された来店先店舗の候補の中から来店先店舗を決定して来店する。

利用者の入力・指示に応じて、来店後に携帯端末内部に保持している取引入力情報とパーソナライズ情報を店舗内に設置されている業務端末に送信する。業務端末は、受信した取引入力情報とパーソナライズ情報を基にして、取引の残りの処理を行うための取引プロセスを構築する。具体的には、通常の取引プロセスに対して、パーソナライズ情報を参照して、取引プロセスの中から利用者にとって不要な処理を除外する。さらに、取引入力情報を参照して、取引プロセスの中から利用者にとって入力済みの処理を除外する。これにより、利用者は事前入力の状況と希望する取引手段に応じて、取引を完了させるために必要な残りの項目のみを入力するだけでよい。

業務端末上で上記構築された取引プロセスに従った利用者からの入力、つまり、取引の残りの入力項目の入力を受付ける。業務端末は、入力が完了すると、取引を実行するシステムと取引情報を連携させて取引実行を完了させる。

本発明によれば、事前入力に即した取引処理の効率化が図れるとの効果を奏する。

本発明の一実施形態における携帯端末活用取引システムの機能構成例を示す図である。 本発明の一実施形態の入力テンプレート情報の一例を示す図である。 本発明の一実施形態のパーソナライズ情報の一例を示す図である。 本発明の一実施形態の取引入力情報の一例を示す図である。 本発明の一実施形態の口座情報の一例を示す図である。 本発明の一実施形態の店舗情報の一例を示す図である。 本発明の一実施形態の店舗端末・デバイス情報の一例を示す図である。 本発明の一実施形態の取引操作・デバイス対応情報の一例を示す図である。 本発明の一実施形態の取引を実行するための全体処理フローを示す図である。 本発明の一実施形態の最適な来店先店舗を計算するための処理フローを示す図である。 本発明の一実施形態の来店後に取引プロセスを構築する考え方を示す図である。

以下、図面を用いて本発明の一実施形態について説明する。
本実施形態では、銀行営業店において投資信託や定期預金商品など購入する際に、顧客は携帯端末で事前に入力できる範囲で入力を行い、そのときの入力の状況や顧客の希望する取引手段に基づいて、最適な来店先店舗を顧客に提示し、来店後に携帯端末と業務端末を連携させることで、取引の残りの入力や操作を行う携帯端末活用取引システムおよび方法の例を用いる（つまり、金融分野の取引を例に説明する）。ただし、本発明の技術的思想は、この例に限定されるものではない。つまり、金融分野以外の取引についても適用可能であり、また、取引以外の相談などの業務にも適用可能なものである。

なお、本発明で述べる「顧客」とは、銀行サービスを受ける利用者（エンドユーザ）を示す。「携帯端末」とは、運搬可能なＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｐｕｔｅｒ）、タブレット型端末、スマートフォン、携帯電話などを示し、金融商品を取引するためのプログラムが実行可能なコンピュータ（情報処理装置）であればよい。「業務端末」とは、店舗に設置されて取引を行うＰＣや専用装置などを示し、金融商品を取引するためのプログラムが実行可能なコンピュータ（情報処理装置）であればよい。「取引」とは、投資信託購入、口座開設、相続相談、振込み、入出金など、銀行営業店またはインターネットバンキングなどで提供されている各種サービスを示す。つまり、取引は申込書の作成、申込内容の確認、現金の支払いなど、一連の取引プロセスから成り立っていると考える。

本実施形態では、以下のような利用シーンを想定する。現金の入出金や振込みなどの単純な取引の場合、事前に必要な入力項目をすべて入力することは可能である。しかし、投資信託や定期預金の購入などの入力項目の多い取引の場合、来店前に入力できる範囲で入力を行い、未入力項目については来店後に行員にアドバイスをもらいながら取引内容を決定したい場合がある。また、顧客によっては認証手段として暗証番号の入力（例えば４桁の数字の入力）を希望する顧客もいれば、生体情報認証（例えば指静脈認証）を希望する顧客もいる。さらに、顧客によっては取引画面のガイダンスの方式（取引画面の進め方）を初心者向けに分かりやすく表示する「親切方式」を希望する顧客もいれば、必要最小限の表示にとどめて取引時間を短縮させた「簡略方式」（例えば、確認画面の表示を省略）を希望する顧客もいる。つまり、事前に入力したい範囲（または入力できる範囲）や希望する取引手段は、顧客によって異なっていると想定する。

また、事前入力の段階で購入したい投資信託商品を決定した顧客は、来店後に諸手続きを行うだけでよいので、行員のサポートは必要ないが、まだ購入したい投資信託商品を決定していない顧客は、来店後に商品知識を持った行員が対応する必要がある。また、来店後に残りの取引（商品比較やシミュレーション）を大画面ディスプレイを見ながら操作したい場合、大画面ディスプレイを設置した店舗に来店する必要がある。つまり、顧客が求めるサービスに応えるために、必要な行員やデバイスを備えた店舗に顧客を誘導しなければならない。ここで、「デバイス」とは、業務端末に装備された大画面ディスプレイ、生体認証装置、現金入出金機、通帳記帳機など、金融商品を取引するために必要な装置である。
以上より、顧客が携帯端末で事前入力を行ったときに、事前の入力状況、希望する取引手段、必要な行員スキルや端末・デバイスを擁した店舗であるかなどの状況に応じて、顧客に最適な来店先店舗を提示する必要がある。

図１は、本実施形態における携帯端末活用取引システムの機能構成例を示す図である。複数の携帯端末１、複数のサーバ２、複数の業務端末３は通信網４を介して接続されている。このとき、携帯端末１とサーバ２間の通信網４は無線通信網（ローカル無線ネットワークや携帯電話網など）であっても、有線通信網であってもよい。同様に、携帯端末１と業務端末３間は無線通信網であっても、有線通信網であってもよく、さらにローカル無線通信技術（例えば、ＮＦＣ（Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）、赤外線通信など）を利用して接続されていてもよい。

携帯端末１は５個の機能、サーバ２は２個の機能、業務端末３は５個の機能を備えており、各機器のハードウェアおよびハードウェアを制御するプログラムによってこれらの機能が動作する。つまり、ソフトウェアたるプログラムに従って、携帯端末のハードウェア資源である演算部での演算で各機能を実行する。

携帯端末１の第一の機能は、携帯端末１の表示装置に情報を表示する画面表示機能１１である。表示装置は、例えば、携帯端末１に内蔵された液晶ディスプレイである。画面表示機能１１は、顧客によって携帯端末１に入力された内容や、サーバ２や業務端末３から受信した情報を表示する。携帯端末１の第二の機能は、顧客が取引の内容を事前入力する事前入力機能１２である。取引内容の「事前入力」とは、例えば、来店前に申込書の一部分だけ作成するなど、来店前に取引プロセスの一部を完了させておくことを意味する。このとき、事前入力された情報は、以降で説明する情報管理機能１３において管理される。携帯端末１の第三の機能は、携帯端末１内部で取り扱う情報を管理する情報管理機能１３である。情報管理機能１３は、入力テンプレート情報１３１、パーソナライズ情報１３２、取引入力情報１３３、口座情報１３４を管理している。これらの情報は、携帯端末１内のメモリ上または外部記憶装置上で保持されている。

携帯端末１の紛失の際に、これらの各情報が外部に流出して不正利用されないように、これらの各種情報は安全に管理されているものとする。例えば、暗号化機能を持つセキュリティ機能付きＳＤ（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）カード（メモリカード）や、耐タンパモジュールなどを利用することで、これらの各種情報を安全に管理することができる。携帯端末１の第四の機能は、事前入力機能１２によって入力され、情報管理機能１３で管理されている各種情報を用いて、事前入力の内容と希望する取引手段に応じて最適な来店先店舗を計算する最適店舗計算機能１４である。最適店舗計算機能１４の具体的な処理内容については、以降の図１０で説明する。携帯端末１の第五の機能は、携帯端末１とサーバ２間または携帯端末１と業務端末３間で各種情報を送受信する送受信機能１５である。以降では、携帯端末１とサーバ２間は携帯電話網で接続され、携帯端末１と業務端末３間はローカル無線技術を使って接続されているとする。

サーバ２の第一の機能は、携帯端末１とサーバ２間で各種情報を送受信する送受信機能２１である。サーバ２の第二の機能は、サーバ２内部で取り扱う情報を管理する情報管理機能２２である。情報管理機能２２は、店舗情報２２１、店舗端末・デバイス情報２２２、取引操作・デバイス対応情報２２３を管理している。これらの各種情報は、サーバ２内のメモリ上または外部記憶装置上で保持されている。これら各機能は、ソフトウェアたるプログラムに従って、サーバ２のハードウェア資源である演算部での演算で実行される。

業務端末３の第一の機能は、携帯端末１と業務端末３間で各種情報を送受信する送受信機能３１である。業務端末３の第二の機能は、携帯端末１から受信した事前入力の内容に応じて、来店後に行う残りの取引プロセスを構築する取引プロセス構築機能３２である。取引プロセス構築機能３２の具体的な処理内容については、以降の図１１で説明する。業務端末３の第三の機能は、業務端末３に接続された表示装置に情報を表示する画面表示機能３３である。表示装置は、例えば、業務端末３に内蔵された液晶表示パネル、外部接続された大画面ディスプレイや液晶プロジェクタなどである。画面表示機能３３は、以降で説明する入力機能３４において顧客によって入力された内容や、携帯端末１から受信した情報を表示する。業務端末３の第四の機能は、取引プロセス構築機能３２によって作成された取引プロセスに従って、顧客が来店後に残りの取引内容を入力する入力機能３４である。業務端末３の第五の機能は、顧客が入力した取引内容の情報を既存の業務システムに取引情報を引き渡すシステム連携機能３５である。なお、既存の業務システムは、業務端末３内部で起動している別のプログラムであっても、通信網を介して接続されている外部システムで起動しているプログラムであってもよい。

図２は、本発明の一実施形態の入力テンプレート情報１３１の一例を示す図である。入力テンプレート情報１３１は、取引種別ごとに定義されており、取引内容を事前入力するときに必要な入力項目を定義したものである。取引種別とは、例えば、投資信託購入、口座開設など、取引の種類を表す。この入力テンプレート情報１３１は、事前入力機能１２において顧客が取引内容を事前入力するときに利用される。

例えば、図２の例では、投資信託を購入するときに、取引内容の事前有力に必要な入力項目を示す。列１３１１の１行目の「取引種別」は、この入力テンプレート情報は「投資信託購入」（以下では単に「投信購入」と呼ぶ）に関するものであることを示し、２行目以降の「商品名」「購入金額」「口座番号」などは、投信購入の事前入力に必要な入力項目であることを示す。

なお、入力テンプレート情報１３１は、取引する銀行に依存せず銀行間で共通利用可能なものとして定義する。もし取引する銀行によって足りない入力項目がある場合は、来店後に業務端末を用いて不足分を入力する。あるいは、取引する銀行ごとに入力テンプレート情報１３１を定義してもよい。

図３は、本発明の一実施形態のパーソナライズ情報１３２の一例を示す図である。パーソナライズ情報１３２は、取引にあたって顧客が希望する取引手段を定義したものである。このパーソナライズ情報１３２は、事前入力機能１２において顧客が取引内容を事前入力するときに利用される。

例えば、図３の例では、認証手段１３２１として「暗証番号入力」（例えば、４桁の数字を入力）または「生体認証」（例えば、指静脈認証）のどちらかを選択できるとき、「生体認証」を希望することを示す。同様に、ガイダンス方式１３２２として「親切方式」（取引に慣れていない顧客向けに補足説明を表示したり、確認画面を追加表示する方式）または「簡略方式」（取引に慣れている顧客向けに取引時間を短縮できるように必要最小限の確認画面のみを表示する方式）のどちらかを選択できるとき、「簡略方式」を希望することを示す。さらに、優先順序１３２３は、取引の事前入力の状況に応じて最適な来店先店舗を提示するときに、「移動距離」「店舗混雑度」「行員スキル」のどれを優先して提示するかを示すものである。この例では、「店舗混雑度」「行員スキル」「移動距離」の順番で優先することを示す。なお、図３に示すパーソナライズ情報１３２は一例であり、この例に限定されるものではない。
なお、パーソナライズ情報１３２は、事前に定義されており、携帯端末１の内部に格納されているものとする。

図４は、本発明の一実施形態の取引入力情報１３３の一例を示す図である。取引入力情報１３３は、選択された入力テンプレート情報１３１に対して、取引の事前入力内容を保持したものである。顧客は、事前入力機能１２によって、携帯端末１の内部に格納されている取引プログラムを通して、取引内容を順番または一括して入力していく。例えば、取引プログラムの一番目の画面で購入したい投資信託商品を選択し、二番目の画面で購入金額を入力し、三番目の画面で購入資金の振込元口座を選択する、という取引プロセスを通して、取引内容を順番に入力していく。または、一つの画面の中で「商品選択タブ」「金額入力タブ」「口座入力タブ」のように複数タブが表示されていて、タブを切り替えながら取引内容を入力していく。このとき、取引プログラムを通して入力された項目を順次取引入力情報１３３の中で保持しておく。

なお、顧客によっては、「購入したい投資信託の商品や金額は決まっており、購入資金の支払いだけは来店して現金で支払いたい」という顧客もいれば、「購入したい投資信託の金額は決まっているが、商品については悩んでいるので、来店して行員に相談しながら決めたい」という顧客もいる。つまり、事前入力できる取引内容の範囲は、そのときの顧客の状況によって異なる。そこで、取引入力情報１３３は、入力テンプレート情報１３１に定義された入力項目（例えば、商品名、購入金額、口座番号など）のすべてを入力する必要はなく、顧客がそのときの状況に応じて入力できる範囲や入力したい範囲で入力すればよい。

例えば、図４の例では、現在の事前入力を行っている取引種別１３３１は「投信購入」であり、商品名１３３２はまだ入力されていないことを示す。このとき、入力されていない項目を「−」と表記する。一方、購入金額１３３３は「５００、０００円」と入力済みであり、口座情報１３３４は「貯蓄＃１」で選択済みであることを示す。なお、口座情報については以降の図５で説明する。また、図３の例では、パーソナライズ情報１３２の認証手段１３２１として「生体認証」を希望しているため、暗証番号の入力は不要である。そこで、図４の暗証番号１３３５は入力項目として利用されてないため、「（不要）」と表記する。以上のように、取引入力情報１３３は、すでに入力済みの項目、まだ入力されていない項目、入力する必要のない項目から成り立っている。

図５は、本発明の一実施形態の口座情報１３４の一例を示す図である。口座情報１３４は複数の口座情報を保持することができ、各行が一つの口座情報を示している。各行の口座名１３４１は各口座を一意に識別するための名称、銀行１３４２は当該口座の銀行名、店舗１３４３は当該口座の店舗名、口座番号１３４４は当該口座の口座番号、種別１３４５は当該口座の種類（例えば、普通預金口座、当座預金口座など）、名義人名１３４６は当該口座を保有する名義人名称を示す。これらの項目以外にも、銀行コードや店舗コードなどの情報があってもよく、この例に限定されるものではない。なお、銀行名に対応する銀行コードや店舗名に対応する店舗コードは数値によって定められているため、これらの銀行コードや店舗コードを参照することによって、銀行名と銀行コード、店舗名と店舗コードを対応付けることができる。実際に取引を行うプログラム上ではこれらの銀行コードや店舗コードを使って処理される。

例えば、図５の例では、２つの口座情報が格納されており、一つ目の口座情報は「貯蓄＃１という口座名で識別され、○○銀行の戸塚支店に口座番号１２３４５６７の普通預金口座があり、名義人名は山田太郎である」ことを示す。
なお、口座名１３４１は、取引入力情報１３３の口座情報１３３４の選択内容として利用することができる。例えば、図４の例では口座情報１３３４として「貯蓄＃１」が選択されており、その「貯蓄＃１」の具体的な口座情報は図５の１行目の口座情報であることを示す。

図６は、本発明の一実施形態の店舗情報２２１の一例を示す図である。店舗情報２２１は各銀行内の店舗に関する情報をまとめた一覧であり、各行が一つの店舗に関する情報を示している。各行の店舗２２１１は店舗の名称、営業時間２２１２は当該店舗の営業時間、取扱取引２２１３は当該店舗で取り扱っている取引種別、店舗位置２２１４は店舗の位置情報（ここでは、緯度・経度情報）を示す。これらの項目以外にも、営業時間、住所、テレビ窓口の有無などの情報があってもよく、この例に限定されるものではない。

例えば、図６の例では、複数の店舗情報が格納されており、一つ目の店舗情報は「戸塚支店の営業時間は９：００から１５：００までであり、投信購入、外貨送金・両替を取り扱っており、店舗の（緯度、経度）は（３５．４０５０６、１３９．５３９１５）である」ことを示す。
なお、店舗情報２２１は銀行ごとにサーバ１内で保持されており、携帯端末１内部の事前入力機能１２を実装する取引プログラムからの送信要求によって携帯端末１内で利用可能なものである。

図７は、本発明の一実施形態の店舗端末・デバイス情報２２２の一例を示す図である。店舗端末・デバイス情報２２２は各銀行内の店舗に設置されている業務端末と、業務端末に装備されているデバイスに関する情報をまとめた一覧であり、各行が一つの業務端末に関する情報を示している。ここで、業務端末とは、顧客と行員との間で双方向に取引を進める相談系の端末（単に相談端末とも呼ぶ）や、入出金や振込みなどの決済処理を中心に行う決済系の端末（単に決済端末とも呼ぶ）などを意味する。また、デバイスとは、大画面ディスプレイやタッチパネルなどの汎用装置や、現金入出金機や通帳記帳機などの金融系業務に特化して利用される金融専門装置などを意味する。

店舗端末・デバイス情報２２２は、顧客の事前入力の状況に応じて最適な来店先店舗を計算するときに活用されるものであるが、銀行内のすべての店舗のすべての業務端末を順次検索する方法では処理時間が増大する可能性がある。そこで、顧客の現在地と取引種別に関する情報を基に検索範囲を絞り込むことで、検索時間の高速化を実現する。具体的には、各店舗の位置情報（緯度、経度）または市町村区分を基に地域をグループ化する。例えば、同じ区内にある戸塚支店と東戸塚支店を同じ地域グループとし、別の区内にある横浜支店は別の地域グループとする。同様に、取引内容によって利用する端末を決定することができるため、取引種別を基に取引をグループ化する。例えば、相談系の取引を一つの取引グループとし、決済系の取引を別の取引グループとする。以上より、事前入力の内容に基づいて一つ（または隣接する複数）の地域グループと取引グループが決まれば、この両者を満たす店舗のみを来店先店舗の候補として抽出すればよいので、検索・絞り込みに要する処理時間を短縮することができる。

このとき、店舗端末・デバイス情報２２２の各行の地域グループ２２２１は上記の地域グループを識別するための名称、取引グループ２２２２は上記の取引グループを識別するための名称、店舗２２２３は店舗の名称、端末２２２４は当該店舗に設置されている業務端末の名称、デバイス２２２５は当該端末に装備されているデバイスの一覧を示す。

例えば、図７の例では、複数の店舗内端末の情報が格納されており、一つ目の店舗内端末の情報は「戸塚支店に設置されている相談端末＃１にはデバイスとして生体認証装置と双方ディスプレイが装備されており、地域グループはＲ１、取引グループはＴ１に属する」ことを示す。
なお、店舗端末・デバイス情報２２２は銀行ごとにサーバ２内に保持されており、携帯端末１内部の事前入力機能１２を実装する取引プログラムからの送信要求によって携帯端末１内で利用可能なものである。

図８は、本発明の一実施形態の取引操作・デバイス対応情報２２３の一例を示す図である。取引操作・デバイス対応情報２２３は、各銀行内における一つの取引プロセスの中で個々の操作（取引操作と呼ぶ）に必要なデバイスとの対応関係をまとめた一覧である。一つの取引操作に対して、複数のデバイスがあってもよい。
例えば、図８の例では、複数の取引操作と必要デバイスの対応関係が格納されており、一つ目の対応関係は「ある取引プロセスの中で取引操作２２３１として生体認証が必要な場合、必要デバイス２２３２として生体認証装置を必要とする」ことを示す。
なお、取引操作・デバイス対応情報２２３は銀行ごとにサーバ２内に保持されており、携帯端末１内部の事前入力機能１２を実装する取引プログラムからの送信要求によって携帯端末１内で利用可能なものである。

サーバ２の情報管理機能２２によって管理されている情報は、上記の店舗情報２２１、店舗端末・デバイス情報２２２、取引操作・デバイス対応情報２２３以外の情報があってもよい。

一つ目の例として、銀行ごとに行員スキルに関する情報を保持することが考えられる。具体的には、銀行内の行員ごとに、勤務先の店舗や対応可能な取引スキルなどを一覧化した情報である。例えば、「戸塚支店に勤務している行員Ａさんは相談系業務全般に対応するスキルを有する」「横浜支店に勤務している行員Ｂさんは相談系業務の中で投信購入とローン商品購入に対応するスキルを有する」などの情報である。

また、二つ目の例として、銀行ごとに各店舗の端末使用状況や各行員の対応状況に関する情報を保持することが考えられる。具体的には、各店舗内での業務端末の空き状況（現在、取引のため何台専有され、何台空いているか）や行員スキル別の行員の接客状況（現在、どの行員が接客中で、どの行員が接客待ちか）などを一覧化した情報である。例えば、「現在、戸塚支店の相談端末＃１と相談端末＃２は空いているが、相談端末＃３は専有されている」「現在、横浜支店の行員Ｘさんと行員Ｙさんは接客中であるが、行員Ｚさんは接客待ちである」などの情報である。なお、現在の状況だけではなく、将来予測される状況を併せて持つことも可能である。これは、店舗内の番号札発券機による発券情報や、インターネットなどのオンライン来店予約による来店予約情報を取得することで、将来の状況を予測することが可能である。

図９は、本発明の一実施形態の取引を実行するための全体処理フローを示す図である。図９の処理フローは、顧客が来店前に携帯端末１を使って取引内容を事前入力する処理と、来店後に携帯端末１の入力内容を業務端末３に送信して取引の残りの操作を完了させる処理から成る。来店前の処理は以降で説明する携帯端末１のステップ１６１からステップ１６５とサーバ２のステップ２３１であり、来店後の処理は以降で説明する携帯端末１のステップ１６６からステップ１６８と業務端末３のステップ３６１からステップ３６５である。さらに、携帯端末１の事前入力機能１２はステップ１６１からステップ１６４、最適店舗計算機能１４はステップ１６５、送受信機能１５はステップ１６４およびステップ１６６からステップ１６８で利用され、サーバ２の送受信機能２１はステップ２３１、業務端末３の送受信機能３１はステップ３６１、ステップ３６２、ステップ３６５、取引プロセス構築機能３２はステップ３６３、入力機能３４はステップ３６４、システム連携機能３５はステップ３６５で利用される。各ステップの詳細については以降で説明する。

ステップ１６１では、顧客が携帯端末１の内部に格納されている取引プログラムを起動し、事前入力を行う取引種別を選択する。例えば、取引プログラムを起動すると、取引のメニュー画面（振込み、投信購入、口座開設など選択可能取引一覧）が表示され、そのメニューの中から顧客が希望する取引を選択する。ここでは、投信購入を選択したとする。

ステップ１６２では、ステップ１６１で選択した取引種別に対応する入力テンプレートに関する情報を入力テンプレート情報１３１から取得し、パーソナライズ情報１３２を参照して、入力テンプレートの中から入力に必要のない入力項目を除外する。例えば、投信購入に対応する図２のような入力テンプレート情報１３１を取得し、図３のようなパーソナライズ情報１３２の認証手段１３２１を参照することで、入力テンプレート情報１３１の中の暗証番号の入力欄への入力が不要であると判断し、図４のように暗証番号１３３５の入力欄には「（不要）」と印を付与する。

ステップ１６３では、取引プログラム上で顧客が入力できる範囲または入力したい範囲で取引内容を事前に入力し、取引入力情報１３３に入力内容を保持しておく。取引プログラムは取引内容を入力する取引プロセス（入力画面）を提供しており、顧客はその取引プロセス（入力画面）に従って、取引内容を入力していく。もし事前入力できない項目や事前入力したくない項目があれば、その項目の入力をスキップする。このとき、入力のスキップの処理は、取引プログラム上に項目の入力をスキップさせるボタンを提供するなどすれば、一般的な技術で実装可能である。例えば、投信購入の場合、購入する商品については来店後に行員と相談したいので事前には入力せず、購入金額については５００、０００円と決めているので事前に入力すると仮定する。このとき、図４のように取引入力情報１３３の商品名１３３２には「−」と印が付与され、購入金額１３３３には「５００、０００円」と入力される。また、顧客が投信購入の支払い口座を決めている場合は、口座情報１３４を参照して、取引入力情報１３３の口座情報１３３４に、口座情報１３４の口座名１３４１を選択して入力する。

ステップ１６４では、ステップ１６３までの事前入力内容に応じて、顧客の最適な来店先店舗を計算するために必要な情報の送信をサーバ２に要求し、サーバ２から各種情報を受信する。このとき、ステップ１６３において、顧客が利用する銀行を決めている場合は、その銀行のサーバに対して情報送信を要求する。一方、顧客が利用する銀行を決めていない場合は、口座情報１３４を参照して、口座情報１３４の中で保持されているすべての銀行のサーバに対して情報送信を要求する。そして、以降のステップ１６５では、すべての銀行のサーバから受信した各種情報をまとめて、最適な来店先店舗を計算する。

サーバ２のステップ２３１では、携帯端末１からの情報送信の要求を受けて、サーバ２内で管理している各種情報（店舗情報２２１、店舗端末・デバイス情報２２２、取引操作・デバイス対応情報２２３、行員スキルに関する情報、各店舗の端末使用状況や各行員の対応状況に関する情報など）を取得して、携帯端末１に送信する。

ステップ１６５では、ステップ１６３で入力された事前入力の内容と、ステップ１６４でサーバから受信した各種情報などを基にして、顧客の最適な来店先店舗を計算する。具体的な処理フローを図１０で説明する。

図１０は、本発明の一実施形態の最適な来店先店舗を計算するための処理フローを示す図である。本処理は、４つの処理ブロック（Ａ）顧客の残りの取引プロセスとして必要な要件（残りの取引に必要な端末・デバイス）を絞り込む「要件絞り込み処理ブロック」１７１（以降で説明するステップ１６５１およびステップ１６５２）、（Ｂ）来店先店舗の候補を計算する処理時間を高速化するために来店先店舗の検索対象グループを絞り込む「検索対象絞り込み処理ブロック」１７２（以降で説明するステップ１６５３およびステップ１６５４）、（Ｃ）顧客が希望する順番で具体的な来店先店舗をさらに絞り込んでいく「来店先店舗絞り込み処理ブロック」１７３（以降で説明するステップ１６５５からステップ１６５８）、（Ｄ）絞り込まれた来店先店舗の候補を顧客に提示する「来店先店舗提示処理ブロック」１７４（以降で説明するステップ１６５９）を順番に実行していく。

ステップ１６５１では、ステップ１６３で入力された取引入力情報１３３を取得する。例えば、図４のような取引入力情報１３３を取得する。
ステップ１６５２では、ステップ１６５１で取得した取引入力情報１３３を参照することで、まだ入力されていない入力項目を抽出する。例えば、図４の例の場合、「−」の印が付与されている商品名がまだ入力されておらず、生体認証とシミュレーションはまだ実施されておらず、約款確認もまだ行われていないことが分かる。そして、サーバ２から取得した取引操作・デバイス対応情報２２３を参照することで、これらの未入力・未操作項目を実行するために必要な端末・デバイスを抽出する。例えば、図８のような取引操作・デバイス対応情報２２３を参照して、商品名１３３２を決定するときの取引操作（ここでは商品選択とする）に必要なデバイスとして双方向ディスプレイを抽出する。同様に、まだ生体認証を実施していないので、生体認証に必要なデバイスとして生体認証装置を抽出する。

ステップ１６５３では、銀行内の店舗端末・デバイス情報２２２を参照して、検索対象グループ（ここでは、地域グループと取引グループ）を特定する。地域グループに関しては、携帯端末１に装備されているＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）を活用して、現在の位置情報（緯度、経度）を取得し、現在地に該当する地域グループ（または、現在地に加えて隣接する複数の地域グループでもよい）を特定する。取引グループに関しては、ステップ１６５２において抽出されたデバイスの集合を基に、これらのデバイスを活用する取引グループを特定する。デバイスの集合と取引グループとの対応付けについては、対応表を保持することで実装可能である。例えば、図７の例では、地域グループをＲ１、取引グループをＴ１と特定する。

ステップ１６５４では、店舗端末・デバイス情報２２２を参照して、ステップ１６５３で特定された地域グループと取引グループに該当する店舗を抽出することで、来店先店舗の候補を絞り込む。このとき、地域グループと取引グループに該当する店舗を特定することで、以降の店舗を絞り込む処理時間を短縮することができる。例えば、図７の例では、地域グループがＲ１であり、かつ取引グループがＴ１であるような行（１行目、２行目、４行目などのレコード）を抽出することで、来店先店舗の候補として戸塚支店、東戸塚支店などに絞り込む。

ステップ１６５５では、パーソナライズ情報１３２の優先順序１３２３を参照して、来店先店舗を決定するための優先順序を確定させる。例えば、図３の例では、１番目の優先項目が店舗混雑度であり、２番目の優先項目が対応可能な行員スキルであり、３番目の優先項目が来店先店舗までの移動距離であるため、以降のステップにおいて、１番目の優先項目（店舗混雑度）を最初のステップ１６５６で行い、２番目の優先項目（行員スキル）をその次のステップ１６５７で行い、３番目の優先項目（移動距離）を最後のステップ１６５８で行う。なお、優先順序１３２３の順序付けが異なれば、ステップ１６５６からステップ１６５８の実行順序もそれに合わせて変更する。また、パーソナライズ情報１３２の優先順序１３２３は図３で示した３項目に限定される必要はなく、２項目であっても、４項目以上あってもよく、内容も移動距離、店舗混雑度、行員スキル以外の項目であってもよい。その場合、ステップ１６５６以降のステップも優先順序１３２３の各項目に対応させて処理を実施する。

ステップ１６５６では、ステップ１６４でサーバ２から取得した「銀行ごとの各店舗の端末使用状況や各行員の対応状況に関する情報」を参照して、ステップ１６５４で絞り込まれた来店先店舗の候補の中から、混雑していない店舗を絞り込む。つまり、店舗に設置されている複数の端末すべてが別の顧客の取引で利用されている場合、混雑していると判断して、来店先店舗の候補から除外する。あるいは、端末すべてではなく、予め別途定めた端末台数（または端末割合）以上が利用されている場合に、来店先店舗の候補から除外してもよい。また、利用中か否かに加え、故障などで使用不可の端末が一定数以上（含むすべての端末）かで判断してもよい。

ステップ１６５７では、ステップ１６４でサーバ２から取得した「銀行ごとの行員スキルに関する情報」を参照して、ステップ１６５６で絞り込まれた来店先店舗の候補の中から、顧客の残りの取引の接客に適したスキルを持つ行員がおり、かつその行員が接客可能な（接客中ではない）店舗を絞り込む。つまり、適切なスキルを持つ行員が接客できない店舗を、来店先店舗の候補から除外する。これは、取引毎に当該取引で要求されるスキルを記憶しておき、今回の取引のスキルと、行員毎に記録された当該行員の有するスキルを比較することで判断される。

ステップ１６５８では、ステップ１６４でサーバ２から取得した店舗情報２２１を参照して、ステップ１６５７で絞り込まれた来店先店舗の候補の中から、顧客の現在地により近い店舗を予め定めた一定数以下になるように絞り込む。顧客の現在地は携帯端末１のＧＰＳを利用して取得することが可能であり、店舗位置は店舗情報２２１の店舗位置２２１４から取得可能であるため、緯度と経度の情報を活用して移動距離を計算することが可能である。あるいは、外部の第三者サービスとして、道路情報を考慮した２地点間の移動ルートを表示し、その移動距離を計算するサービスが提供されているので、このようなサービスを活用してもよい。

ステップ１６５９では、ステップ１６５８で絞り込まれた来店先店舗の候補を顧客に提示する。予め、顧客に提示する来店先店舗の候補数の上限値を設定して、顧客に提示してもよい。もしステップ１６５４およびステップ１６５６からステップ１６５８の絞り込みの処理の中で、来店先店舗の候補数が顧客に提示する上限値を下回るとき、絞り込みの処理はそのステップまでとし、残りの絞り込みのステップを実行せず、図１０の処理を終了させる。つまり、来店先店舗の候補数がゼロになる手前の処理までを行うようにする。

図９の各ステップの説明に戻る。ステップ１６５の処理を終えることで、顧客に対して事前入力内容と顧客の希望する取引手段に応じて最適な来店先店舗が提示されるので、顧客はそれに従って、来店先店舗を決定して来店する。以降のステップは店舗に来店した後のステップである。

携帯端末１のステップ１６６では、顧客は店舗で残りの取引を行うために、携帯端末１と業務端末３との間で情報の送受信を行う通信の接続処理を行う。
業務端末３のステップ３６１では、携帯端末１からの通信の接続要求に応じて、接続処理を行い、通信路の接続を確立する。例えば、ローカル無線通信により携帯端末１と業務端末３の間で端末間のペアリング処理を行い、この処理により互いの端末間で情報を送受信することができるようにする。なお、業務端末３は、図１０の処理により、顧客が残りの取引を行うために必要なデバイスを備えた端末である。

携帯端末１のステップ１６７では、ステップ１６６の接続処理を受けて、携帯端末１内に格納されている取引入力情報１３３とパーソナライズ情報１３２を業務端末３に送信する。
業務端末３のステップ３６２では、携帯端末１から取引入力情報１３３とパーソナライズ情報１３２を受信し、業務端末３の内部で保持しておく。
業務端末３のステップ３６３では、ステップ３６２で受信した取引入力情報１３３とパーソナライズ情報１３２を参照して、取引の残りの処理を行うための取引プロセスを構築する。取引プロセスの構築については、以降の図１１で説明する。

図１１は、本発明の一実施形態の来店後に取引プロセスを構築する考え方を示す図である。（ａ）通常の取引プロセス３６３１は、事前入力を行わなかった場合にすべての項目を入力するときの取引プロセスを示している。（ｂ）パーソナライズ情報を反映させた取引プロセス３６３２は、ステップ３６２で受信したパーソナライズ情報１３２を参照して、上記（ａ）の取引プロセスの中から顧客にとって入力や操作の不要な処理を除外したものである。例えば、顧客は認証手段１３２１として生体認証を希望しているため、顧客に対して明示的に認証手段を選択する画面を表示する必要はない。そこで、上記（ａ）の取引プロセスの中から「認証手段判断」と「暗証番号入力」の処理を除外することができる。また、顧客はガイダンス方式１３２２として簡略方式を希望しているため、取引プロセスの中で明示的に確認画面を表示する必要がない。そこで、上記（ａ）の取引プロセスの中から「確認」の処理を除外することができる。さらに、（ｃ）事前入力・操作済み項目を反映させた取引プロセス３６３３は、ステップ３６２で受信した取引入力情報１３３を参照して、上記（ｂ）の取引プロセスの中から顧客にとって入力済みの処理を除外したものである。例えば、顧客は購入金額１３３３をすでに事前入力済みであるため、取引プロセスの中から「金額入力」の処理を除外することができる。以上のように取引プロセスを構築することで、顧客は事前入力の状況や希望する取引手段に応じて、残りの項目を入力することができる。

このとき、顧客に対して、上記（ｃ）のように構築された取引プロセスに従って、残りの項目を入力する画面が表示される。一方、業務端末３のシステム上では、上記（ａ）のような通常の取引プロセスを実行するプログラムが動作している。例えば、「金額入力」画面を顧客に表示することなく取引プログラムが自動的に入力済みデータを代入し、「認証手段判断」画面も顧客に表示することなく自動的に遷移先を判断する。つまり、実際に動作している取引プログラムは上記（ａ）のような処理を行っているが、すでに入力済みの項目に対してはプログラムが自動的に入力内容の代入処理を行うため、顧客にとっては上記（ｃ）のような処理の画面しか表示されないことを意味する。

業務端末３のステップ３６４では、顧客はステップ３６３で構築された取引プロセスに従って、まだ完了していない残りの項目を入力したり、残りの操作を行う。例えば、図４の例では、双方向ディスプレイを活用して行員と相談しながら購入したい投資信託の商品を選択したり、購入商品の確認のために生体認証を行ったりする。

業務端末３のステップ３６５では、取引プログラムはステップ３６４で入力が完了した取引情報を、取引を実行するシステム（例えば、勘定系システム）と連携させて取引の実行を完了させる。取引を実行するシステムは業務端末３内部のシステムであっても、通信網を介して外部に接続されたシステムであってもよい。取引が完了すると、業務端末３は携帯端末１に対して取引完了通知を送信する。

携帯端末１のステップ１６８では、業務端末３から取引完了通知を受信して、取引入力情報１３３を削除する。以上のステップによって、一連の取引をすべて完了させることができる。

以下（１）から（５）に、上記説明の補足を述べる。
（１）図１と図９の説明において、顧客は携帯端末１を使って取引の事前入力を行うと説明した。一方、携帯端末１ではなく、設置型端末（例えば、デスクトップ型ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ））や可搬型端末（例えば、ノート型ＰＣ）でもよい。つまり、携帯端末１の内部で行っていたステップ１６１からステップ１６５の処理を設置型端末または可搬型端末で行い、ステップ１６４までに得られた取引入力情報１３３とパーソナライズ情報１３２を携帯端末１に転送し、来店先店舗では携帯端末１と業務端末３を通信させることで、ステップ１６６以降の残りの処理を行う。これらの処理が完了すると、携帯端末１、設置型端末または可搬型端末に保持されている取引入力情報１３３とパーソナライズ情報１３２を削除する。

（２）図１と図９の説明において、取引の事前入力を行う取引プログラムは顧客の携帯端末１の内部に格納されていると説明した。一方、携帯端末１の内部ではなく、取引プログラムの実体をＷｅｂアプリケーションとしてサーバ２に配置してもよい。このとき、入力テンプレート情報１３１、パーソナライズ情報１３２、取引入力情報１３３、口座情報１３４は、ＣｏｏｋｉｅやＨＴＭＬ５のローカルストレージなどの機能を活用して、携帯端末１の内部にローカル保存することができる。あるいは、これらの情報をサーバ２上で保管し、ステップ３６１において来店先店舗で携帯端末１と業務端末３の接続処理を行った後、ステップ３６２において業務端末３がサーバ２からこれらの情報を取得する方法であってもよい。ただし、この場合、取引したい銀行を事前に決めておき、その銀行のサーバ２上の取引プログラムを利用し、その銀行のサーバ２上に事前入力の内容を送信する。一方、図９では、取引したい銀行を事前に決めておかなくても、事前入力することが可能である。

（３）最適な来店先店舗を計算する際、ステップ１６５３では、店舗端末・デバイス情報２２２の中に地域グループと取引グループを設定することで、検索対象グループの絞り込みを行った。しかし、これらの地域グループと取引グループ以外にも、支店の規模（大規模店舗、中規模店舗、小規模店舗）、有人店舗か無人店舗などを基にグループ化してもよい。

（４）最適な来店先店舗を計算する際、ステップ１６５６では、店舗の混雑状況として、オンラインによる予約状況や番号札発券機の発券状況を参照して、店舗内の混雑の状況を判断した。顧客によっては、今からすぐに来店するのではなく、時間帯を指定して来店したい場合も考えられる。そこで、取引の事前入力の際に来店時間帯を指定してもよく、その場合は、予約情報や現在の混雑状況を基にしてその時間帯の店舗の混雑状況を推測するものとする。

（５）最適な来店先店舗を計算する際、ステップ１６５８では、顧客の現在地からより近い店舗を優先すると説明した。しかし、顧客の現在地ではなく、例えば、顧客の出張先の情報を地図上から選び、その位置情報を活用して、出張先からより近い店舗を優先してもよい。あるいは、現在地から出張先に行く途中の移動ルート上により近い店舗を優先してもよい。

以上の本実施形態によれば、利用者側は、事前の入力状況や希望する取引手段に応じて来店先店舗を知ることができるので、自分の状況に合った適切なサービスを受けることができ、店舗での待ち時間の減少やサービスの分かりやすさの向上につながる。また、サービス提供者側（例えば、銀行）は、行員による支援を必要とする利用者や特定の端末・デバイスを必要とする利用者を適切な店舗に誘導することができるので、行員は支援を必要とする利用者に絞って支援でき、店舗全体としての行員にかかる業務負荷や、端末・デバイスの稼動状況を適正化することができる。

１ 携帯端末
２ サーバ
３ 業務端末
４ 通信網

Claims (11)

1. 所定の取引を事前に行う携帯端末と、前記取引の残りの処理を実行するための業務端末と、サーバが通信網を介して接続されている携帯端末活用取引システムにおいて、
   前記携帯端末は、前記携帯端末に対して前記取引の事前入力を行う利用者が希望する取引手段を含むパーソナライズ情報を取得し、前記サーバから各店舗の業務端末と使用状況や取引に対応可能な行員の接客状況をまとめた混雑情報を取得し、前記利用者が事前に任意に入力した取引入力情報と前記パーソナライズ情報と前記混雑情報を基にして、事前入力されなかった残りの取引を処理する最適な来店先店舗を計算し、
   前記業務端末は、来店先店舗で前記携帯端末から前記パーソナライズ情報と前記取引入力情報を受信し、前記残りの取引の処理を完了させることを特徴とする携帯端末活用取引システム。
2. 請求項１に記載の携帯端末活用取引システムにおいて、
   前記携帯端末は、前記残りの取引を処理する最適な来店先店舗の計算において、前記取引の事前入力において入力されなかった取引入力項目を抽出し、前記サーバから受信した取引入力項目と必要な業務端末または業務デバイスを対応付けした取引操作・デバイス対応情報を基にして、前記入力されなかった取引入力項目を入力または操作するために必要な業務端末を絞り込むことを特徴とする携帯端末活用取引システム。
3. 請求項２に記載の携帯端末活用取引システムにおいて、
   前記携帯端末は、前記残りの取引を処理する最適な来店先店舗の計算において、前記絞り込まれた業務端末に対して、前記業務端末が設置されており、かつ前記業務端末が利用者の来店希望時間帯に利用可能である店舗を来店先店舗の候補することを特徴とする携帯端末活用取引システム。
4. 請求項３に記載の携帯端末活用取引システムにおいて、
   前記携帯端末は、前記残りの取引を処理する最適な来店先店舗の計算において、各店舗の位置情報に基づいて複数に分類された地域グループと、各店舗で対応可能な取引の種類に基づいて複数に分類された取引グループを基にして、店舗一覧から来店先店舗を計算する範囲を絞り込むことを特徴とする携帯端末活用取引システム。
5. 請求項３または４のいずれかに記載の携帯端末活用取引システムにおいて、
   前記携帯端末は、前記残りの取引を処理する最適な来店先店舗の計算において、前記サーバから、各店舗に勤務する行員と、前記行員が対応可能な接客スキルと、前記行員の時間帯ごとの接客予定をまとめた行員スキルに関する情報を基にして、
   前記残りの取引の処理を実行するために必要な接客スキルを有する行員が勤務しており、かつ前記行員が利用者の来店希望時間帯に接客可能である店舗を来店先店舗の候補として絞り込むことを特徴とする携帯端末活用取引システム。
6. 請求項３から５のいずれかに記載の携帯端末活用取引システムにおいて、
   前記携帯端末は、前記残りの取引を処理する最適な来店先店舗の計算において、利用者の現在地に近い店舗、利用者の移動先に近い店舗、または現在地から移動先への移動ルートに近い店舗を優先して来店先店舗の候補として絞り込むことを特徴とする携帯端末活用取引システム。
7. 請求項３から６のいずれかに記載の携帯端末活用取引システムにおいて、
   前記携帯端末は、前記残りの取引を処理する最適な来店先店舗の計算において、前記パーソナライズ情報の中に来店先店舗を絞り込むための優先度を示す項目を保持し、利用者の希望に応じて前記項目に優先順序を付与し、前記優先順序に基づいて来店先店舗の候補の絞り込みを行うことを特徴とする携帯端末活用取引システム。
8. 請求項３から７のいずれかに記載の携帯端末活用取引システムにおいて、
   前記携帯端末は、特定の銀行に依存せず、銀行間で共通的に利用可能な取引入力テンプレートを保持し、前記取引入力テンプレートを活用して取引内容を事前入力することを特徴とする携帯端末活用取引システム。
9. 請求項１から８のいずれかに記載の携帯端末活用取引システムにおいて、
   前記業務端末は、前記携帯端末から受信した前記パーソナライズ情報と前記取引入力情報を基にして、利用者の希望しない取引手段およびすでに入力済みの項目を取引プロセスから除外することで、利用者には残りの取引入力項目のみを入力させるように取引プロセスを構築することを特徴とする携帯端末活用取引システム。
10. 所定の取引を事前に行う設置型端末または可搬型端末と、前記設置型端末または可搬型端末から事前に入力された取引入力情報を保持する携帯端末と、前記取引の残りの処理を実行するための業務端末と、サーバが通信網を介して接続されている携帯端末活用取引システムにおいて、
    前記設置型端末または可搬型端末は、前記設置型端末または可搬型端末に対して前記取引の事前入力を行う利用者が希望する取引手段を含むパーソナライズ情報を取得し、前記サーバから各店舗の業務端末と使用状況や取引に対応可能な行員の接客状況をまとめた混雑情報を取得し、前記利用者が事前に任意に入力した取引入力情報と前記パーソナライズ情報と前記混雑情報を基にして、事前に入力されなかった残りの取引を処理する最適な来店先店舗を計算し、
    前記携帯端末は、前記設置型端末または可搬型端末から前記取引入力情報を受信、保持し、
    前記業務端末は、来店先店舗で前記携帯端末から前記パーソナライズ情報と前記取引入力情報を受信し、前記残りの取引の処理を完了させることを特徴とする携帯端末活用取引システム。
11. 所定の取引を事前に行う携帯端末と、前記取引の残りの処理を実行するための業務端末と、サーバが通信網を介して接続されている携帯端末活用取引システムを用いた携帯端末活用取引方法において、
    前記携帯端末は、前記携帯端末に対して前記取引の事前入力を行う利用者が希望する取引手段を含むパーソナライズ情報を取得し、前記サーバから各店舗の業務端末と使用状況や取引に対応可能な行員の接客状況をまとめた混雑情報を取得し、前記利用者が事前に任意に入力した取引入力情報と前記パーソナライズ情報と前記混雑情報を基にして、事前入力されなかった残りの取引を処理する最適な来店先店舗を計算し、
    前記業務端末は、来店先店舗で前記携帯端末から前記パーソナライズ情報と前記取引入力情報を受信し、前記残りの取引の処理を完了させることを特徴とする携帯端末活用取引方法。

Images