JP2012230445A - 情報端末連携システムおよび方法 - Google Patents

Abstract

【課題】営業店内で金融デバイスを利用した取引の時間を短縮できる情報端末連携システムおよび方法を提供する。
【解決手段】ポータブル端末は取引の中の各処理ステップで、デバイス端末に先行処理を依頼できるかどうかを取引状況に基づいて判定し（ステップ５０２）、もし先行処理の依頼が可能であれば各デバイス端末に対して先行処理の受付可否を問合せ、各デバイス端末からの問合せ結果から先行処理を依頼するデバイス端末を決定して先行処理を依頼し（ステップ５０３）、当該デバイス端末はポータブル端末の取引状況に基づいて金融デバイスに関する処理フローを実行する。ポータブル端末はその後の取引を完了させる処理ステップで、当該デバイス端末に対して先行処理として実行されていない以降の残りの処理を依頼し（ステップ５０６）、当該デバイス端末はポータブル端末の取引状況に基づいて金融デバイスに関する処理フローを実行する。
【選択図】図７

Description

本発明は、複数の情報処理装置（以下、情報端末）を連携させて、所定の処理を実行するための技術に関する。その中でも特に、情報端末としてのポータブル端末と金融デバイスが接続された情報端末を連携させて、金融デバイスを利用した取引を効率的に処理できる技術に関する。なお、金融デバイスには、金融営業店で利用されるキャッシャ、通帳プリンタ、認証装置などが含まれる。

現在、様々なサービスを提供するための情報処理を複数の情報端末を連携して実行することが行われている。例えば、システムの構成変更や多様な業務要求に柔軟かつ効率的に対応し、運営コストを低減する金融デバイス集中管理システム、金融デバイス集中管理方法、金融デバイス集中管理プログラムについては、特開２００５−２１６００２号公報(特許文献１)に記載されている。その概要は、営業店について取得した営業状況情報に該当する業務フローを特定するフロー特定部と、業務フローに伴って利用される金融デバイスの情報を取得すると共に該当金融デバイスの属性情報を抽出するデバイス情報取得部と、デバイス状態データベースより営業店に備わる各金融デバイスの利用状況を抽出しそのうち利用状況が利用可能となっているものを利用デバイスとして特定するデバイス特定部と、利用デバイスに関する利用方式を構成管理情報データベースより抽出し当該利用方式に応じたクライアントに顧客情報、業務フローの情報、および当該業務フローにおける金融デバイスに対する処理命令を送信する処理命令出力部とからシステムを構成することを特徴とするものである。

特開２００５−２１６００２号公報

特許文献１では、金融デバイスの使用状況をサーバ側で集中管理することにより、システムの構成変更や多様な業務要求に柔軟かつ効率的に対応することを目指している。複数の情報端末から金融デバイスを利用する場合、複数の情報端末間による金融デバイスの専有タイミングが競合しないように、金融デバイスを効率的に共有する必要があるが、特許文献１は金融デバイスの効率的な処理を目的としたものではなかった。金融デバイスを効率的に共有するには、金融デバイスの専有時間を短縮させる必要がある。そのためには、取引の一連のプロセス全体における取引状況に応じた金融デバイスの使用状況を把握する必要がある。しかし、特許文献１は情報端末上に処理すべき取引(タスク)があるタイミングでの金融デバイスの使用状況しか確認することができない。

本発明の目的は、取引状況に応じて、取引の一連のプロセスの中で金融デバイスに関する処理の一部を先行して実行することにより、営業店内で金融デバイスを利用した取引の時間を短縮させることができる技術を提供することにある。

本発明では、前提として、ポータブル端末と連携可能（物理的な接続が可能）な金融デバイスは限定されているものである。そして、ポータブル端末から金融デバイス等の特定デバイスを利用（連携）するために、複数の特定デバイスを集約して接続した「デバイス端末」を用いる（これは、当該システムを利用する営業店内に設置することが好適である）。このとき、ポータブル端末はデバイス端末と処理を連携させる際、デバイス端末を利用して、上記の前提（制限）を満たす特定デバイスおよびその連携すべきタイミングを特定するものである。

ポータブル端末においてある取引の一連の処理全体を「通常時処理」と呼び、通常時処理の中で先行して行うことができる金融デバイスに関する一部分の処理を「先行処理」と呼び、通常時処理の中で先行処理を行わなかった先行処理以降の残りの処理を「デバイス実行時処理」と呼ぶことにする。

また、現在（ないしあるタイミングで）行われている取引を「取引名」と呼び、当該取引の中で現在行われている取引ステップを「取引状態」と呼び、少なくとも取引名と取引状態から成る現在の取引を識別するための情報を「取引状況」と呼ぶことにする。なお、対象となる「取引」はあくまで一例であり、何らかの処理であれば構わない。

上記の目的を達成するために、本発明の一例として、金融取引を実行する場合では、ポータブル端末上で行われる取引の一連の処理の中で、取引状況に応じて先行処理を複数のデバイス端末に依頼し、先行処理を受付けることができるデバイス端末の中から、複数のポータブル端末が効率的に複数のデバイス端末を共有できるようにデバイス端末を決定し、決定されたデバイス端末は取引状況に応じて先行処理を行う。より具体的には以下の処理を行う。

取引の一連の処理を行うポータブル端末と、金融デバイスが接続された複数のデバイス端末と、サーバが通信網を介して接続されている情報端末連携システムにおいて、ポータブル端末は、取引ステップが進むたびに、先行処理判定情報を参照して先行処理を依頼することが可能なタイミングであるかどうかを判定する。もし現在の取引ステップが先行処理を依頼することが可能なタイミングであれば、当該ポータブル端末は複数のデバイス端末に対して取引状況を送信し、先行処理の受付可否の問合せを行う。

各デバイス端末は、当該ポータブル端末から受信した先行処理の受付可否の問合せに対して、取引状況判定情報を参照して当該ポータブル端末から受信した取引状況に応じて、当該デバイス端末に接続されている金融デバイスの専有状況を計算し、その計算結果を受付可能状況として当該ポータブル端末に通知する。

当該ポータブル端末は、各デバイス端末から受信した受付可能状況を基にして、各デバイス端末に接続されている金融デバイスの中で、専有されている金融デバイス数が最も多いデバイス端末を先行処理の依頼先として決定する。デバイス端末の利用効率を上げるために、金融デバイスの専有率が高いデバイス端末を優先して先行処理の依頼先に決定するという考え方に基づいている。当該ポータブル端末は、決定されたデバイス端末に対して取引状況および取引データを送信し、先行処理を依頼する依頼情報を送信する。

上記で決定されたデバイス端末は、当該ポータブル端末から先行処理の依頼を受信し、当該ポータブル端末から受信した取引状況に応じて、金融デバイスに関する処理を行うデバイス処理フローを取得し、先行処理として取得された当該デバイス処理フローを実行する。

当該ポータブル端末は、取引ステップが進むたびに、デバイス実行時処理を依頼することが可能なタイミングであるかどうかを判定する。もし現在の取引ステップがデバイス実行時処理を依頼する（依頼情報を送信する）ことが可能なタイミングであれば、当該ポータブル端末は上記で決定されたデバイス端末に対して取引状況および取引データを送信し、デバイス実行時処理を依頼する依頼情報を送信する。

上記で決定された当該デバイス端末は、当該ポータブル端末からデバイス実行時処理の依頼を受信し、取引状況判定情報を参照して当該ポータブル端末から受信した取引状況に応じて、金融デバイスに関する処理を行うデバイス処理フローを取得し、デバイス実行時処理として取得された当該デバイス処理フローを実行する。

なお、当該ポータブル端末が先行処理の依頼先のデバイス端末を決定するさい、各デバイス端末からの受信した受付可能状況を基にして、各デバイス端末に接続されている金融デバイスの中で、専有されている金融デバイスの割合が最も高いデバイス端末を先行処理の依頼先として決定してもよい。

本発明によれば、情報端末での処理状況に応じて、特定デバイス（例えば、金融デバイス）に関する処理の一部を先行して実行するので、特定デバイスを実際に専有する時間を短縮することができる。また、情報端末は特定デバイスの専有時間を短縮するので、特定デバイスを利用するための待ち時間を減少させることができる。

本発明の一実施形態における情報端末連携システムの機能構成例を示す図である。 本発明の一実施形態の先行処理判定情報の一例を示す図である。 本発明の一実施形態の先行処理管理情報の一例を示す図である。 本発明の一実施形態の取引状況判定情報の一例を示す図である。 本発明の一実施形態の専有状況管理情報の一例を示す図である。 本発明の一実施形態のデバイス処理フロー情報の一例を示す図である。 本発明の一実施形態のポータブル端末において取引を実行するための全体処理フローを示す図である。 本発明の一実施形態のポータブル端末とデバイス端末において先行処理を実行するための処理フローを示す図である。 本発明の一実施形態のポータブル端末において先行処理の依頼先を決定するための処理フローを示す図である。 本発明の一実施形態のポータブル端末とデバイス端末においてデバイス実行時処理を実行するための処理フローを示す図である。

以下、図面を用いて本発明の一実施形態について説明する。
本実施形態では、銀行営業店において定期預金を解約するときに、ポータブル端末を金融デバイスと連携させて、定期預金解約取引の一部を先行して処理する情報端末連携システムおよび方法の例を用いる。ただし、本発明の技術的思想は、この例に限定されるものではない。つまり、金融分野以外の取引について適用可能であり、また、取引以外の相談、通知などの業務にも適用可能なものである。

なお、本発明で述べる「ポータブル端末」とは、運搬可能なPC（Ｐｅｒｓｏｎａｌ Ｃｏｐｕｔｅｒ）、タブレット型端末、スレート型端末、スマートフォン、携帯電話などであり、金融商品を取引するためのプログラムが実行可能なコンピュータ(情報処理装置)であればよい。また、「金融デバイス」とは、現金の入出金を行うキャッシャ、通帳プリンタ（通帳記帳機）、通帳発行機、認証装置、帳票を読取るスキャナ、磁気／ＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）カードリーダなど、金融商品を取引するために必要なデバイスである。

本実施形態では、以下のような利用シーンを想定する。銀行営業店に来店する顧客は、具体的な目的を持って来店する人だけではなく、「そろそろ住宅を購入したいけど、何をすればいいか分からない」、「銀行でどんな相談にのってもらえるのか、まずは軽く会話をしたい」、「来店ついでに必要そうな情報を集めたい」といった漠然とした気持ちを持った人もいる。行員はポータブル端末を持って営業店内を自由に動き回り、来店顧客のところに出向いてその場で用件を伺って接客を行う。行員は顧客との軽いコミュニケーションの中でヒアリングやアドバイスを行い、具体的な相談や取引に移っていく。営業店内ではローカウンタの設置エリアやカウンタ数が限られているため、行員は顧客にいちいち場所を移動してもらうのではなく、行員は最初に接客したその場（例えば、ロビーエリアにある近くのテーブル）でポータブル端末を活用して相談や取引に必要な情報の参照、取引データの入力などを行い、そのまま取引を進めていく。行員は顧客との取引を具体的に進め、カード読取り、指静脈認証、現金入出金、記帳、帳票読取りなどの金融デバイスの操作が必要になると、ロビーエリア内に設置された近くのデバイス端末のところに移動して、デバイス端末に接続された金融デバイスを操作する。このとき、実際にデバイス端末の設置場所に移動してから金融デバイスの操作（例えば、出金操作）を開始するのではなく、デバイス端末の設置場所に移動する前に先行してデバイス端末に金融デバイスの処理の一部を実行させておく。例えば、出金額を計数して現金をスタッカに格納するまでの処理を行っておく。その後、デバイス端末の設置場所に着いたときに、金融デバイスに関する残りの処理を実行する。例えば、キャッシャの投入口をオープンし、スタッカに格納された現金を排出する。

以上のような利用シーンにおいて、通常時処理の例は、「ポータブル端末で出金額が確定された後に、デバイス端末が出金計数を行い、キャッシャ内部のスタッカに現金を格納し、投入口をオープンし、スタッカに格納された現金を排出する一連の処理」である。このとき、先行処理の例は、「ポータブル端末で出金額が確定された後に、デバイス端末が出金計数を行い、キャッシャ内部のスタッカに現金を格納するまでの処理」である。一方、デバイス実行時処理の例は、「キャッシャの投入口をオープンし、スタッカに格納された現金を排出する処理」である。

このとき、デバイス端末は複数のポータブル端末から同時に先行処理を受付け、先行処理を実行する。つまり、先行処理の段階では複数（または１台）のポータブル端末がデバイス端末を共有した状態である。一方、行員と顧客がデバイス端末の設置場所に出向き、残りのデバイス実行時処理を行うときは、１台のポータブル端末が当該デバイス端末を専有した状態である。

図１は、本実施形態における情報端末連携システムの機能構成例を示す図である。複数のポータブル端末１、複数のデバイス端末２、サーバ３は通信網４を介して接続されている。ポータブル端末１は５個の機能、デバイス端末は３個の機能を備えており、各機器のハードウェアおよびハードウェアを制御するプログラムによってこれらの機能が動作する。

ポータブル端末１は、入出力装置としてタッチパネル１７１を装備している。タッチパネルの代わりにディスプレイ、マウス、キーボードなどであってもよい。また、ポータブル端末１は、非接触ＩＣチップ１７２、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）１７３を装備していてもよい。ポータブル端末１の第一の機能は、行員または顧客がポータブル端末１のタッチパネル１７１を利用して取引データを入力する入力機能１１である。ポータブル端末１の第二の機能は、行員または顧客がポータブル端末１のタッチパネル１７１を利用して入力した取引データの内容、デバイス端末２またはサーバ３から受信したデータの内容、サーバ３から受信した取引画面などを表示する表示機能１２である。ポータブル端末１の第三の機能は、ポータブル端末１内部で取扱う情報を管理する記憶機能１３である。記憶機能１３は、先行処理判定情報１３１、先行処理管理情報１３２を管理している。これらの情報は、ポータブル端末１内のメモリ上または外部記憶装置上で保持されている。

ただし、これらの情報はサーバ３からポータブル端末１に事前配布されたものであってもよいし、システム起動の際やプログラム実行にサーバ３から動的に取得するものであってもよい。ポータブル端末１の第四の機能は、デバイス端末２およびサーバ３とデータを送受信するための通信機能１４である。ポータブル端末１の第五の機能は、取引を行うプログラムを実行し、上記第一から第四の機能および１７１から１７３のようなハードウェアを制御する制御機能１５である。

デバイス端末２は、金融デバイスとしてキャッシャ２４１、通帳プリンタ２４２、通帳発行機２４３、認証装置２４４、スキャナ２４５、ＬＢＰ（Ｌａｓｅｒ Ｂｅａｍ Ｐｒｉｎｔｅｒ）２４６、レシートプリンタ２４７、ＭＳ（Ｍａｇｎｅｔｉｃ Ｓｔｒｉｐｅ）／ＩＣカードリーダ２４８を装備している。ただし、デバイス端末２はこれらの金融デバイスをすべて装備する必要はなく、これら以外の金融デバイスまたは汎用的な表示装置、入力装置、印刷装置などを装備していてもよい。また、各デバイス端末２が同じ金融デバイスを装備した同一構成である必要はなく、デバイス端末２ごとに接続されている金融デバイスが異なっていてもよい。さらに、１台のデバイス端末２に同じ種類の金融デバイスが複数接続されていてもよい。デバイス端末２の第一の機能は、デバイス端末２内部で取扱う情報を管理する記憶機能２１である。記憶機能２１は、取引状況判定情報２１１、専有状況管理情報２１２、デバイス処理フロー情報２１３を管理している。これらの情報は、デバイス端末２内のメモリ上または外部記憶装置上で保持されている。ただし、これらの情報はサーバ３からデバイス端末２に事前配布(配信)され、保持されたものであってもよいし、システム起動時やプログラム実行にポータブル端末１またはサーバ３から動的に取得するものであってもよい。デバイス端末２の第二の機能は、ポータブル端末１およびサーバ３とデータを送受信するための通信機能２２である。デバイス端末２の第三の機能は、金融デバイスの処理に関わるプログラムを実行し、上記第一と第二の機能および２４１から２４８のようなハードウェアを制御する制御機能２３である。

サーバ３は、営業店サーバに相当するものである。サーバ３は、ポータブル端末１またはデバイス端末２からの要求に応じて勘定系ホストや情報系サーバと連携し、決済処理、顧客情報照会、取引履歴照会などを行う。

通信路４は、専用線、有線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、無線ＬＡＮなどである。特に、ポータブル端末１とデバイス端末２の間の通信は、赤外線通信、非接触ＩＣ通信などの近距離無線通信であってもよい。

なお、本発明では、運搬可能なポータブル端末１の利用を想定したが、ポータブル端末１を運搬せずに設置場所を固定して利用してもよい。また、ポータブル端末１の代わりに、設置型のＰＣを利用してもよい。

図２は、実施形態の先行処理判定情報１３１の一例を示す図である。先行処理判定情報１３１は、取引の中の各処理ステップ（例えば、取引の画面遷移において各画面を表示するタイミング）で、デバイス端末２に先行処理を依頼することが可能なタイミングであるかどうかを判定するために利用される。取引名１３１１は、定期新約、口座開設、投信購入、相続などの取引名や取引種類を示す。取引状態１３１２は、取引名１３１１で表される取引の中でデバイス端末に先行処理を依頼できる処理ステップ（例えば、取引画面の名称や取引画面における操作の種類）を示す。例えば、図２の１つめのレコードは、定期満期の取引において、払戻し確定を行った処理ステップのタイミング（顧客が払戻し実行確認画面で払戻しを確定したときのタイミング）で、デバイス端末２に対して先行処理を依頼することが可能であることを示す。なお、先行処理判定情報１３１の各レコードは事前に定義、記録されたものである。

図３は、実施形態の先行処理管理情報１３２の一例を示す図である。先行処理管理情報１３２は、デバイス端末２に先行処理を依頼したかどうかを記録するために利用される。ポータブル端末ＩＤ１３２１は、当該ポータブル端末を識別するためのＩＤを示す。デバイス端末ＩＤ１３２２は、先行処理を依頼したデバイス端末を識別するためのＩＤを示す。受付番号１３２３は、先行処理の依頼を受付けたデバイス端末が先行処理を管理するために発行する番号を示す。なお、ポータブル端末ＩＤ１３２１、デバイス端末ＩＤ１３２２、受付番号１３２３は一意に識別可能な番号である。例えば、当該ポータブル端末のポータブル端末ＩＤ１３２１の値が「Ｐ００１」である場合、先行処理を依頼する前は、まだデバイス端末ＩＤ１３２２と受付番号１３２３は確定していないので、（ポータブル端末ＩＤ、デバイス端末ＩＤ、受付番号）の値は（Ｐ００１、−、−）である。以降では、未確定データを「−」と表記する。この後、当該ポータブル端末はデバイス端末ＩＤが「Ｄ０１」であるデバイス端末に先行処理を依頼し、先行処理の受付番号として「１０１」が発行された場合、図３の１つめのレコードのように、（ポータブル端末ＩＤ、デバイス端末ＩＤ、受付番号）の値を（Ｐ００１、Ｄ０１、１０１）として先行処理管理情報１３２に格納する。

なお、本実施形態では説明を簡単にするため、１台のポータブル端末では１つの取引のみを行っていると想定する。この場合、先行処理管理情報１３２のレコード数は高々１であり、受付番号１３２３は必ずしも必要ない。一方、１台のポータブル端末で複数の取引を行っている場合、先行処理管理情報１３２のレコード数は複数存在してもよく、受付番号１３２３は必要になる。

図４は、本実施形態の取引状況判定情報２１１の一例を示す図である。取引状況判定情報２１１は、ポータブル端末での取引状況に応じて、どの金融デバイスを専有し、またどの処理フローを実行するのかを判定するために利用される。取引状況番号２１１１は、取引状況判定情報２１１の各レコードを識別するための番号を示す。なお、取引状況番号２１１１は一意に識別可能な番号である。取引名２１１２は取引名や取引種類を示す。取引状態２１１３は、取引名２１１２で表される取引の中での処理ステップ（例えば、取引画面の名称や取引画面における操作の種類）を示す。処理区分２１１４は、ポータブル端末１の取引状況が当該レコードの取引名２１１２と取引状態２１１３の値であったときに、（ａ）先行処理を実行するのか、（ｂ）先行処理を実行した後に、デバイス実行時処理を実行するのか、（ｃ）通常時処理を実行するのかを示す。このとき、（ａ）の場合は「先行時」、（ｂ）の場合は「実行時」、（ｃ）の場合は「通常時」を表記する。利用デバイス２１１５は、ポータブル端末１の取引状況が当該レコードの取引名２１１２と取引状態２１１３の値であったときに、利用する金融デバイスの集合を示す。また、（ｃ）については、先行処理やデバイス実行時処理を実行せずに、通常時処理を実行してもよい。専有範囲２１１６は、ポータブル端末１の取引状況が当該レコードの取引名２１１２と取引状態２１１３の値であったときに、（ａ）当該デバイス端末全体、つまり、デバイス端末自体およびこれに接続される各金融デバイスを専有するのか、（ｂ）当該デバイス端末の特定の金融デバイスを専有するのかを示す。具体的には、（ａ）の場合は「端末全体」と表記し、（ｂ）の場合は専有させる金融デバイス名の集合を表記する。デバイス処理フロー名２１１７は、ポータブル端末１の取引状況が当該レコードの取引名２１１２と取引状態２１１３の値であったときに、実行する処理フロー名を示す。例えば、図４の１つめのレコードは、ポータブル端末１の取引状況が定期満期の取引における払戻し確定のステップであるとき、デバイス端末２は先行処理として端末全体を専有し、キャッシャを利用して出金先行処理フローを実行することを示す。ここで、（ａ）の専有については、デバイス端末自体を専有するように制御することで、各金融デバイスを専有可能になる。

なお、専有範囲２１１６に特定の金融デバイスが記載されている場合、当該金融デバイスのみを専有するが、当該デバイス端末に接続されたその他の金融デバイスは専有されていないため、複数の処理を並行して実行することができる。例えば、図４の４つめのレコードと７つめのレコードは金融デバイスの専有範囲が競合しないため、さらにこれらの先行処理を実行することができる。一方、専有範囲２１１６に端末全体と記載されている場合、先行処理であっても端末全体を専有する必要があるので、あるデバイス端末２がすでに他の金融デバイスの先行処理を実行していると、当該デバイス端末２は端末全体の専有を要求するようなポータブル端末１からの先行処理を受付けることはできない。

図５は、実施形態の専有状況管理情報２１２の一例を示す図である。専有状況管理情報２１２は、デバイス端末２が受付けている先行処理の情報を記録するために利用される。受付番号２１２１は、当該デバイス端末２で実行している先行処理を識別する番号を示す。ポータブル端末ＩＤ２１２２は、先行処理を受付けているポータブル端末ＩＤを示す。取引状況番号２１２３は、先行処理を受付けている取引状況を識別するための番号であり、取引状況判定情報２１１の取引状況番号２１１１で示されている番号を表記する。例えば、図５は、現在先行処理を１件受付けており、ポータブル端末ＩＤがＰ００１であるポータブル端末１から、取引状況判定情報２１１の取引状況番号２１１１が１である先行処理を受付けている（実行している）ことを示す。なお、デバイス端末２が複数の先行処理を受付けている場合には複数のレコードが格納され、まだ先行処理を受付けていない場合にはレコードは存在しない。

図６は、本実施形態のデバイス処理フロー情報の一例を示す図である。デバイス処理フロー情報２１３は、金融デバイスに関する処理フローを取得するために利用される。デバイス処理フロー名２１３１は金融デバイスに関する処理フローの名称であり、取引状況判定情報２１１のデバイス処理フロー名２１１７によって参照される。なお、デバイス処理フロー名２１３１は一意に識別可能な名称である。デバイス処理フロー内容２１３２は金融デバイスに関する処理フローの定義であり、フローチャート、シーケンス図などを利用して記述される。例えば、図６の１つめのレコードは、出金先行処理フローの処理フロー内容を定義したものである。出金先行処理フローが呼出されると、デバイスオープン、監視イベント登録、デバイスロック、入金計数禁止、出金計数の処理が順番に実行されることを示す。

以下では、ポータブル端末１を利用して取引を行うとき、ポータブル端末１をデバイス端末２と連携させて金融デバイスを利用する処理の流れについて説明する。ポータブル端末１上で取引を行うプログラム（以下、単に取引プログラムとも記す）を起動すると、表示機能１２により取引画面が表示され、入力機能１１により画面上の項目やボタンを選択すると次の取引画面が表示される。このような取引プログラムは制御機能１５により実行され、取引画面の遷移を繰り返すことにより、取引を完了させることができる。取引プログラムは、サーバ３に配置されたＷｅｂアプリケーションであっても、ポータブル端末１にインストールされたプログラムであってもよい。

図７は、本実施形態のポータブル端末１において取引を実行するための全体処理フローを示す図である。なお、取引プログラムは現在（ないしある時間で）実行中の取引名と取引状態をポータブル端末のメモリ上で保持すると仮定する。また、ポータブル端末１は、営業店内に設置されて利用可能なデバイス端末ＩＤの集合もメモリ上で保持すると仮定する。

ステップ５０１では、取引の一連のプロセスの中で取引画面を表示し、行員または顧客により当該取引画面の入力や確認が完了するとステップ５０２以降の処理を実行する。例えば、定期預金の解約内容を確認し、行員が確認ボタンを押下すると、ステップ５０２に遷移する。

ここで、処理ステップ群５５は先行処理を行うための処理ステップの集合であり、処理ステップ群５６はデバイス実行時処理または通常時処理を行うための処理ステップの集合である。

ステップ５０２では、この遷移タイミングで先行処理をデバイス端末２に依頼可能であるかどうかを判定する。具体的には、先行処理判定情報１４１に格納されているレコードを参照し、現在メモリ上で保持されている取引名と取引状態に一致するレコードが存在するかどうかを判定する。もし一致するレコードが存在すればステップ５０３に遷移し、一致するレコードが存在しなければステップ５０４に遷移する。例えば、「定期満期」取引で定期預金を解約することになり、払戻しを確定させた「払戻し確定」状態であるときに、本ステップが呼びされたとする。先行処理判定情報１４１のレコードを参照すると、（定期満期、払戻し確定）レコードが存在するため、ステップ５０３に遷移する。

ステップ５０３では、複数のデバイス端末２に先行処理を受付けることが可能であるかどうかを問合せる情報を送信し、先行処理の受付けが可能であるデバイス端末２を一つ選択し、先行処理の実行を依頼する。以降の図８で、本処理の詳細を説明する。

ステップ５０４では、この遷移タイミングでデバイス実行時処理または通常時処理をデバイス端末２に依頼可能であるかどうかを判定する。具体的には、取引プログラムの中の処理として金融デバイスに関する処理を依頼するかどうかを判定する。もし金融デバイスに関する処理を依頼する取引状態であればステップ５０５に遷移し、そうでなければステップ５０８に遷移する。例えば、「定期満期」取引で定期預金を解約することになり、払戻しが確定され、現金をキャッシャから排出する取引状態であれば、デバイス実行時処理または通常時処理を行う必要があるので、ステップ５０５に遷移する。

ステップ５０５では、これまでの取引の一連の処理の中で、デバイス端末２に先行処理を依頼済み(依頼情報を送信済みか、以下、同様)であるかどうかを判定する。具体的には、先行処理管理情報１４２に格納されているレコードを参照し、先行処理を依頼したことを示すレコードが存在するかどうかを調べる。もしレコードが存在すればステップ５０６に遷移し、存在しなければステップ５０７に遷移する。例えば、「定期満期」取引の「払戻しを確定」処理ステップで先行処理を依頼済みであり、図３のようなレコードが存在する場合は、ステップ５０６に遷移する。

ステップ５０６では、デバイス端末２に対してすでに先行処理を依頼済みであるため、デバイス端末２にデバイス実行時処理の実行を依頼し、残りの処理を完了させる。以降の図１０で、本処理の詳細を説明する。

ステップ５０７では、デバイス端末に対して先行処理を依頼していないため、デバイス端末に通常時処理の実行を依頼し、処理を完了させる。通常時処理は、以降で説明する図８の先行処理と図１０のデバイス実行時処理をまとめて順番に行う処理である。

ステップ５０８では、処理ステップ群５５または処理ステップ群５６の実行結果に基づいて、ステップ５０１の取引画面の次に表示する取引画面を取得する。

ステップ５０９では、もしステップ５０８で次の画面が存在しなければ、取引の一連の取引ステップが完了したと判断して、本処理フローを終了させ、それ以外外の場合はまだ取引が続くと判断して、ステップ５０１に遷移する。

図８は、本実施形態のポータブル端末１とデバイス端末２において先行処理を実行するための処理フローを示す図である。図８の処理フローは、図７のステップ５０３で実行されるものである。

ステップ６０１では、現在の取引プログラムで実行されている取引名および取引状態をポータブル端末１上のメモリから取得する。例えば、取引名は「定期満期」、取引状態は「払戻し確定」である。

ステップ６０２では、メモリ内で保持している営業店内で利用可能なデバイス端末２の集合の中から、まだ先行処理の依頼の問合せをしていないデバイス端末２を１つ選択する。

ステップ６０３では、ポータブル端末１は上記ステップ６０２で選択したデバイス端末２に対して、先行処理の依頼を受付けることができるかどうかを問合せる。このとき、ポータブル端末１はデバイス端末２に対して取引状況としてステップ６０１で取得した取引名と取引状態を送信する。

ステップ６０４では、デバイス端末２は、取引状況判定情報２１１に格納されているレコードの中から、ポータブル端末１から受信した取引状況（取引名と取引状態）に一致するレコードを抽出する。そして、当該レコードの専有範囲２１１６に定義されている範囲で、デバイス端末２を専有できるかどうかを判定する。具体的には、専有状況管理情報２１２に格納されているレコードを参照してすでに専有されている専有範囲と、ポータブル端末１から依頼された先行処理として専有を希望する専有範囲が衝突しないかどうかを計算する。例えば、デバイス端末２に通帳発行機が１台接続されており、別の先行処理によってすでに通帳発行機が専有されている場合、新たに通帳発行機を利用しようとしても、利用を希望する金融デバイスの専有範囲が衝突すると判定する。また、専有範囲が「端末全体」である場合、専有状況管理情報２１２にレコードが存在すると金融デバイスの専有範囲が衝突すると判定する。

本ステップにおいて専有範囲が衝突しない場合、受付可能状況を以下で説明するビット列のデータと定義する。このビット列のデータは、先行処理を受付けたと仮定した場合の専有範囲とする。当該デバイス端末２に接続されている各金融デバイスについて、（ａ）専有されているなら「１」、（ｂ）専有されていないなら「０」とする。例えば、デバイス端末２にキャッシャ、通帳発行機、レシートプリンタが接続されていて、先行処理を受付けることにより、通帳発行機とレシートプリンタが専有される場合は、受付可能状況は「（キャッシャ、通帳発行機、レシートプリンタ）＝（０、１、１）」というビット列である。もし専有範囲が端末全体である場合は、受付可能状況は「（キャッシャ、通帳発行機、レシートプリンタ）＝（１、１、１）」というビット列である。一方、ステップ６０４において専有範囲が衝突する場合、つまり先行処理の依頼を受付けることができない場合、受付可能状況を「ＮＧ」と定義する。

ステップ６０５では、ステップ６０４で計算された受付可能状況をポータブル端末１に送信する。

なお、上記では、デバイス端末２においてステップ６０４およびステップ６０５の処理を行う方法を説明した。別の処理方法として、各デバイス端末２は先行処理を受付可能であるかどうかを計算せず、現在専有されている金融デバイスの情報を単にポータブル端末１に送信し、ポータブル端末１側で受付可能状況を計算する方法でああってもよい。

ステップ６０６では、ポータブル端末１は、デバイス端末２から受信した受付可能状況をメモリ上に保持しておく。このとき、受付可能状況がどのデバイス端末のものであるかを識別できるように、デバイス端末ＩＤと対応付けて管理しておく。

ステップ６０７では、メモリ内で保持されている営業店内で利用可能なデバイス端末の集合の中から、まだ先行処理の依頼の問合せをしていないデバイス端末２が存在するかどうかを判定する。もしまだ問合せをしていないデバイス端末が存在すればステップ６０２に遷移し、もし存在しなければステップ６０８に遷移する。

ステップ６０８では、ステップ６０６において保持されたデバイス端末２から受信した受付可能状況の集合に基づいて、実際に先行処理を依頼するデバイス端末２を決定する。

図９は、本実施形態のポータブル端末１において先行処理の依頼先を決定するための処理フローを示す図である。図９の処理フローは、図８のステップ６０８で実行されるものである。

ステップ６５１では、ステップ６０６で保持されている受付可能状況の集合の中から、受付不可以外のものを抽出する。つまり、ステップ６０４で計算された受付可能状況が「ＮＧ」以外のものを抽出する。ただし、もしすべての受付可能状況が「ＮＧ」であれば、図９の処理フローを終了し、図８に戻って先行処理を依頼せずに図８の処理フローを終了する。

ここで、各デバイス端末２における受付可能状況について、どの程度金融デバイスが専有されているかを示す指標として「重み」を導入する。重みの一例は、デバイス端末２に接続されている金融デバイスの中で専有されている金融デバイスの数である。つまり、受付可能状況を示すビット列の中での「１」の総数である。例えば、受付可能状況が「（キャッシャ、通帳発行機、レシートプリンタ）＝（０、１、１）」であれば、重みは「２」である。重みが大きいほど、デバイス端末２に接続されている金融デバイスの専有率が高いことを示す。

ステップ６５２では、ステップ６５１で抽出された受付可能状況の集合の中から、重みが最大であるものを抽出する。

ステップ６５３では、ステップ６５２で抽出された受付可能状況が複数存在すればステップ６５５に遷移し、それ以外の場合（つまり１つ存在する場合）はステップ６５４に遷移する。

ステップ６５４では、ステップ６５２で抽出された受付可能状況に該当するデバイス端末２を先行処理の依頼先に決定する。

ステップ６５５では、ステップ６５２で抽出された受付可能状況の集合の中からデバイス端末２を１つ選択し、そのデバイス端末２を先行処理の依頼先に決定する。このときの第一の選択方法は、ポータブル端末１のＧＰＳ１７３およびデバイス端末２の設置場所の位置情報を活用して当該ポータブル端末１から最も近いデバイス端末２を選択する方法である。ただし、ポータブル端末はデバイス端末の位置情報を事前にメモリ上で保持していると仮定する。第二の選択方法は、ポータブル端末１が各デバイス端末２に対して先行処理の受付可否について問合せをしたとき、応答時間が最も短いデバイス端末２を選択する方法である。ただし、ポータブル端末１は応答時間を計測していると仮定する。第三の選択方法は、ポータブル端末１の画面に選択可能なデバイス端末２を表示し、行員に選択してもらう方法である。第四の選択方法は、ポータブル端末１がデバイス端末２を任意に一つ選択する方法である。あるいは、これら以外の選択方法であってもよい。

なお、ステップ６５２では、重みを利用して先行処理の依頼先を抽出したが、別の方法として、「使用率」が最も高い受付可能状況を抽出する方法であってもよい。使用率とは、デバイス端末２に接続されている金融デバイスの総数に対して、専有されている金融デバイスの割合である。この使用率は、受付可能状況を示すビット列の長さに対する「１」の割合で計算することができる。例えば、受付可能状況が「（キャッシャ、通帳発行機、レシートプリンタ、ＬＢＰ）＝（０、１、１、０）」であれば、使用率は「５０％」である。

さらに、先行処理の依頼先を抽出する別の方法として、「優先度」が最も高い受付可能状況を抽出する方法であってもよい。優先度とは、各デバイス端末２に接続されている金融デバイスに優先順位を付けて、当該デバイス端末２の受付可否状況の値を計算したものである。この優先度は、金融デバイスを優先度の高い順に並べて、受付可能状況を示すビット列を２進数と見なすことにより計算できる。例えば、受付可能状況が「（キャッシャ、通帳発行機、レシートプリンタ、ＬＢＰ）＝（０、１、１、０）」であるとき、優先順位が通帳発行機、キャッシャ、レシートプリンタ、ＬＢＰの順番であれば、優先度は２進数表記で「１０１０」である。受付可能状況が同じあっても、優先順位がキャッシャ、通帳発行機、ＬＢＰ、レシートプリンタの順番であれば、優先度は２進数表記で「０１０１」（つまり「１０１」）であり。優先度は、後者より前者の方が高い。

ステップ６０９では、現在ポータブル端末１上で実行されている取引プログラムにおける取引データをメモリから取得する。例えば、取引データは口座番号や解約金額（出金額）などの具体的なデータである。取引データは、メモリ上のデータ以外にも、ポータブル端末内部の外部記憶から取得したデータ、またはサーバから取得したデータであってもよい。

ステップ６１０では、ステップ６０８において決定された先行処理の依頼先のデバイス端末を示すデバイス端末ＩＤを取得し、そのデバイス端末ＩＤを先行処理管理情報１４２のデバイス端末ＩＤ１３２２に記録する。例えば、先行処理管理情報１４２のレコードとして「（ポータブル端末ＩＤ、デバイス端末ＩＤ、受付番号）＝（Ｐ００１、Ｄ０１、−）」のようなデータを記録する。

ステップ６１１では、ステップ６０８において決定された先行処理の依頼先のデバイス端末２に対して、先行処理を依頼する。このとき、ポータブル端末１はポータブル端末ＩＤ、ステップ６０１で取得した取引状況（取引名と取引状態）、ステップ６０９で取得した取引データを送信する。

ステップ６１２では、デバイス端末２は取引状況判定情報２１１に格納されているレコードを参照して、ポータブル端末１から受信した取引状況（取引名と取引状態）に一致するレコードを抽出し、このレコードの取引状況番号を取得する。そして、新たに受付番号を発行し、本受付番号、ステップ６１１で送信されたポータブル端末ＩＤ、本ステップで取得された取引状況番号をレコードとして専有状況管理情報２１２に格納する。例えば、図５のようなレコードを格納する。

ステップ６１３では、ステップ６１２で発行された受付番号をポータブル端末１に送信する。

ステップ６１４では、ポータブル端末１は先行処理管理情報１４２の該当するレコードの受付番号１３２３に受信した受付番号を格納する。例えば、先行処理管理情報１４２のレコードとして「（ポータブル端末ＩＤ、デバイス端末ＩＤ、受付番号）＝（Ｐ００１、Ｄ０１、−）」のようなデータが格納されているとき、受付番号が「１０１」であれば、「（ポータブル端末ＩＤ、デバイス端末ＩＤ、受付番号）＝（Ｐ００１、Ｄ０１、１０１）」とレコードを更新する。

ステップ６１５では、デバイス端末２は取引フロー情報２１３を参照して、先行処理として実行する処理フローを取得する。例えば、ステップ６１２で受信した取引名が「定期満期」、取引状態が「払戻し確定」であるとき、取引状況判定情報２１１に格納されているレコードから１つめのレコードを抽出し、先行処理として実施する「出金先行処理フロー」を取得する。

ステップ６１６では、ステップ６１５で取得された処理フローを実行する。

以上の処理を実行することにより、ポータブル端末１は適切なデバイス端末２に対して先行処理を依頼するとともに、デバイス端末２は効率的に先行処理を実行する。

図１０は、本実施形態のポータブル端末１とデバイス端末２においてデバイス実行時処理を実行するための処理フローを示す図である。図１０の処理フローは、図７のステップ５０６で実行されるものである。

ステップ７０１では、先行処理管理情報１４２に格納されているレコードを参照して、先行処理を依頼したデバイス端末２を特定する。

ステップ７０２では、現在の取引プログラムで実行されている取引状況（取引名と取引状態）および取引データを当該ポータブル端末１上のメモリから取得する。

ステップ７０３では、ステップ７０１で特定されたデバイス端末２に残りの処理（デバイス実行時処理）を依頼する。このとき、ステップ７０２で取得された取引状況（取引名と取引状態）および取引データに加えて、先行処理管理情報１３２の当該レコードに格納されている受付番号もあわせてデバイス端末２に送信する。

ステップ７０４では、デバイス端末２は、取引状況判定情報２１１に格納されているレコードの中から、ポータブル端末１から受信した取引状況（取引名と取引状態）に一致するレコードを抽出する。このとき、ポータブル端末１から受付番号も受信しているので、専有状況管理情報２１２に格納されているレコードの中に当該受付番号が存在すれば、デバイス実行時処理を行えばよいと判断することができる。そして、取引状況判定情報２１１に格納されている当該レコードのデバイス処理フロー名２１１７に定義されているデバイス処理フローをデバイス処理フロー情報２１３から取得する。例えば、先行処理として図４の１つめのレコードで定義されている「出金先行処理フロー」を行っている場合は、本ステップでは図４の２つめのレコードに定義されている「出金実行処理フロー」を取得する。

ステップ７０５では、ステップ７０４で取得された処理フローを実行する。
ステップ７０６では、ステップ７０５で実行された処理フローの処理結果をポータブル端末１に送信する。

ステップ７０７では、デバイス端末２における先行処理またはデバイス実行時処理が完了したので、専有状況管理情報２１２から当該レコードを削除する。
ステップ７０８では、ポータブル端末１はデバイス端末２から処理結果を受信し、また、先行処理管理情報１４２に格納されている当該レコードを削除する。

以上の処理を実行することにより、ポータブル端末１はデバイス端末２と連携して取引を完了させることができる。

なお、上記実施形態における先行処理として、実際にキャッシャのような金融デバイスを動作させる例を利用した。例えば、先行処理として、「出金操作時にキャッシャのスタッカまで現金を格納しておく」「通帳発行時に通帳に事前印字しておく」などである。先行処理の別の例として、（ａ）ハードウェアの初期化処理や（ｂ）ソフトウェアの初期化処理であってもよい。例えば、上記（ａ）の例はハードウェアのウォームアップである。また上記（ｂ）の例は、（ｉ）デバイス端末で実行されるプログラム（デバイス処理フロー）で利用するオブジェクトの初期化（オブジェクトの生成、オブジェクトへのデータの事前代入など）、あるいは（ｉｉ）サーバからの指静脈データや印鑑の照合データなどの事前取得などである。このような先行処理の場合も、上記実施形態と同様の処理で実現することができる。

金融、公共、流通などの分野において、ポータブル端末を利用してデバイスを操作するシステムおよび方法として利用可能である。

１ ポータブル端末
２ デバイス端末
３ サーバ
４ 通信網

Claims (12)

1. 所定の業務に利用するポータブル端末と、前記業務のための処理を実行する業務デバイスが接続されたデバイス端末と、サーバが通信網を介して接続されている情報端末連携システムにおいて、
   前記業務を実行する場合、前記ポータブル端末は、前記業務のための処理状況に応じて当該処理の一部を先行処理として前記デバイス端末に処理を依頼する依頼情報であっって前記処理状況を含む依頼情報を、当該依頼情報の送信イミングを定義した先行処理判定情報に従って送信し、
   前記デバイス端末は、前記ポータブル端末からの前記依頼情報を受信し、前記処理状況に応じて、前記業務デバイスに対して前記先行処理を実行させることを特徴とする情報端末連携システム。
2. 請求項１に記載の情報端末連携システムにおいて、
   前記ポータブル端末は、予め先行処理を行うタイミングを示す先行処理判定情報を記憶しており、当該先行処理判定情報を参照して前記処理状況が先行処理を依頼するタイミングであるかどうかを判定し、先行処理の依頼が可能なタイミングと判断した場合、前記依頼情報送信することを特徴とする情報端末連携システム。
3. 請求項１または２のいずれかに記載の情報端末連携システムにおいて、
   前記通信網には、複数のデバイス端末が接続され、
   前記ポータブル端末は、前記複数のデバイス端末のそれぞれに、先行処理が可能かを示す問合せ情報を送信し、
   前記複数のデバイス端末のそれぞれは、自身の専有状況に基づいて、前記問合せ情報に対応した先行処理を含む処理が可能かを判断し、前記ポータブル端末に前記判断の結果である受付可能状況を送信し、
   前記ポータブル端末は、前記受付可能状況に基づいて前記複数のデバイス端末から前記依頼情報を送信するデバイス端末を決定し、
   前記決定されたデバイス端末に対して、前記依頼情報を送信することを特徴とする情報端末連携システム。
4. （図８のデバイス端末側の先行処理）
   請求項２または３のいずれかに記載の情報端末連携システムにおいて、
   前記デバイス端末は、前記問合せ情報を受信した場合、前記デバイス端末に接続されている業務デバイスの専有状況を前記受付可能状況として前記ポータブル端末に送信し、前記依頼情報を受信した場合、当該依頼情報に対応する先行処理に対応する業務デバイスに関するデバイス処理フローを取得して前記デバイス処理フローを実行することを特徴とする情報端末連携システム。
5. （図９で「重み」優先の場合）
   請求項３また４のいずれかに記載の情報端末連携システムにおいて、
   前記ポータブル端末は、前記依頼情報を送信するデバイス端末の決定において、前記複数のデバイス端末のうち、接続されている業務デバイスの中で、専有されている業務デバイスの数が最も多いデバイス端末を、依頼情報を送信するデバイス端末として決定することを特徴とする情報端末連携システム。
6. （図９で「使用率」優先の場合）
   請求項３または４のいずれかに記載の情報端末連携システムにおいて、
   前記ポータブル端末は、前記依頼情報を送信するデバイス端末の決定において、前記複数のデバイス端末のうち、接続されている業務デバイスの中で、接続されている業務デバイスに対して専有されている業務デバイスの割合が最も高いデバイス端末を、頼情報を送信するデバイス端末として決定選択することを特徴とする情報端末連携システム。
7. 所定の業務に利用するポータブル端末と、前記業務のための処理を実行する業務デバイスが接続されたデバイス端末と、サーバが通信網を介して接続されている情報端末連携システムを用いた情報端末連携方法において、
   前記業務を実行する場合、前記ポータブル端末は、前記業務のための処理状況に応じて当該処理の一部を先行処理として前記デバイス端末に処理を依頼する依頼情報であっって前記処理状況を含む依頼情報を、当該依頼情報の送信イミングを定義した先行処理判定情報に従って送信し、
   前記デバイス端末は、前記ポータブル端末からの前記依頼情報を受信し、前記処理状況に応じて、前記業務デバイスに対して前記先行処理を実行させることを特徴とする情報端末連携方法。
8. 請求項７に記載の情報端末連携方法において、
   前記ポータブル端末は、予め先行処理を行うタイミングを示す先行処理判定情報を記憶しており、当該先行処理判定情報を参照して前記処理状況が先行処理を依頼するタイミングであるかどうかを判定し、先行処理の依頼が可能なタイミングと判断した場合、前記依頼情報送信することを特徴とする情報端末連携方法。
9. 請求項７または８のいずれかに記載の情報端末連携方法において、
   前記通信網には、複数のデバイス端末が接続され、
   前記ポータブル端末は、前記複数のデバイス端末のそれぞれに、先行処理が可能かを示す問合せ情報を送信し、
   前記複数のデバイス端末のそれぞれは、自身の専有状況に基づいて、前記問合せ情報に対応した先行処理を含む処理が可能かを判断し、前記ポータブル端末に前記判断の結果である受付可能状況を送信し、
   前記ポータブル端末は、前記受付可能状況に基づいて前記複数のデバイス端末から前記依頼情報を送信するデバイス端末を決定し、
   前記決定されたデバイス端末に対して、前記依頼情報を送信することを特徴とする情報端末連携方法。
10. 請求項８または９のいずれかに記載の情報端末連携方法において、
    前記デバイス端末は、前記問合せ情報を受信した場合、前記デバイス端末に接続されている業務デバイスの専有状況を前記受付可能状況として前記ポータブル端末に送信し、前記依頼情報を受信した場合、当該依頼情報に対応する先行処理に対応する業務デバイスに関するデバイス処理フローを取得して前記デバイス処理フローを実行することを特徴とする情報端末連携方法。
11. 請求項８また９のいずれかに記載の情報端末連携方法において、
    前記ポータブル端末は、前記依頼情報を送信するデバイス端末の決定において、前記複数のデバイス端末のうち、接続されている業務デバイスの中で、専有されている業務デバイスの数が最も多いデバイス端末を、依頼情報を送信するデバイス端末として決定することを特徴とする情報端末連携方法。
12. 請求項８または９のいずれかに記載の情報端末連携方法において、
    前記ポータブル端末は、前記依頼情報を送信するデバイス端末の決定において、前記複数のデバイス端末のうち、接続されている業務デバイスの中で、接続されている業務デバイスに対して専有されている業務デバイスの割合が最も高いデバイス端末を、頼情報を送信するデバイス端末として決定選択することを特徴とする情報端末連携方法。

Images