所定の業務に利用するポータブル端末と、前記業務のための処理を実行する業務デバイスが接続されたデバイス端末と、サーバが通信網を介して接続されている情報端末連携システムにおいて、前記業務を実行する場合、前記ポータブル端末は、前記業務のための処理状況に応じて当該処理の一部を先行処理として前記デバイス端末に処理を依頼する依頼情報であっって前記処理状況を含む依頼情報を、当該依頼情報の送信イミングを定義した先行処理判定情報に従って送信し、前記デバイス端末は、前記ポータブル端末からの前記依頼情報を受信し、前記処理状況に応じて、前記業務デバイスに対して前記先行処理を実行させることを特徴とする情報端末連携システム。請求項1に記載の情報端末連携システムにおいて、前記ポータブル端末は、予め先行処理を行うタイミングを示す先行処理判定情報を記憶しており、当該先行処理判定情報を参照して前記処理状況が先行処理を依頼するタイミングであるかどうかを判定し、先行処理の依頼が可能なタイミングと判断した場合、前記依頼情報送信することを特徴とする情報端末連携システム。請求項1または2のいずれかに記載の情報端末連携システムにおいて、前記通信網には、複数のデバイス端末が接続され、前記ポータブル端末は、前記複数のデバイス端末のそれぞれに、先行処理が可能かを示す問合せ情報を送信し、前記複数のデバイス端末のそれぞれは、自身の専有状況に基づいて、前記問合せ情報に対応した先行処理を含む処理が可能かを判断し、前記ポータブル端末に前記判断の結果である受付可能状況を送信し、前記ポータブル端末は、前記受付可能状況に基づいて前記複数のデバイス端末から前記依頼情報を送信するデバイス端末を決定し、前記決定されたデバイス端末に対して、前記依頼情報を送信することを特徴とする情報端末連携システム。図8のデバイス端末側の先行処理請求項2または3のいずれかに記載の情報端末連携システムにおいて、前記デバイス端末は、前記問合せ情報を受信した場合、前記デバイス端末に接続されている業務デバイスの専有状況を前記受付可能状況として前記ポータブル端末に送信し、前記依頼情報を受信した場合、当該依頼情報に対応する先行処理に対応する業務デバイスに関するデバイス処理フローを取得して前記デバイス処理フローを実行することを特徴とする情報端末連携システム。図9で重み優先の場合請求項3また4のいずれかに記載の情報端末連携システムにおいて、前記ポータブル端末は、前記依頼情報を送信するデバイス端末の決定において、前記複数のデバイス端末のうち、接続されている業務デバイスの中で、専有されている業務デバイスの数が最も多いデバイス端末を、依頼情報を送信するデバイス端末として決定することを特徴とする情報端末連携システム。図9で使用率優先の場合請求項3または4のいずれかに記載の情報端末連携システムにおいて、前記ポータブル端末は、前記依頼情報を送信するデバイス端末の決定において、前記複数のデバイス端末のうち、接続されている業務デバイスの中で、接続されている業務デバイスに対して専有されている業務デバイスの割合が最も高いデバイス端末を、頼情報を送信するデバイス端末として決定選択することを特徴とする情報端末連携システム。所定の業務に利用するポータブル端末と、前記業務のための処理を実行する業務デバイスが接続されたデバイス端末と、サーバが通信網を介して接続されている情報端末連携システムを用いた情報端末連携方法において、前記業務を実行する場合、前記ポータブル端末は、前記業務のための処理状況に応じて当該処理の一部を先行処理として前記デバイス端末に処理を依頼する依頼情報であっって前記処理状況を含む依頼情報を、当該依頼情報の送信イミングを定義した先行処理判定情報に従って送信し、前記デバイス端末は、前記ポータブル端末からの前記依頼情報を受信し、前記処理状況に応じて、前記業務デバイスに対して前記先行処理を実行させることを特徴とする情報端末連携方法。請求項7に記載の情報端末連携方法において、前記ポータブル端末は、予め先行処理を行うタイミングを示す先行処理判定情報を記憶しており、当該先行処理判定情報を参照して前記処理状況が先行処理を依頼するタイミングであるかどうかを判定し、先行処理の依頼が可能なタイミングと判断した場合、前記依頼情報送信することを特徴とする情報端末連携方法。請求項7または8のいずれかに記載の情報端末連携方法において、前記通信網には、複数のデバイス端末が接続され、前記ポータブル端末は、前記複数のデバイス端末のそれぞれに、先行処理が可能かを示す問合せ情報を送信し、前記複数のデバイス端末のそれぞれは、自身の専有状況に基づいて、前記問合せ情報に対応した先行処理を含む処理が可能かを判断し、前記ポータブル端末に前記判断の結果である受付可能状況を送信し、前記ポータブル端末は、前記受付可能状況に基づいて前記複数のデバイス端末から前記依頼情報を送信するデバイス端末を決定し、前記決定されたデバイス端末に対して、前記依頼情報を送信することを特徴とする情報端末連携方法。請求項8または9のいずれかに記載の情報端末連携方法において、前記デバイス端末は、前記問合せ情報を受信した場合、前記デバイス端末に接続されている業務デバイスの専有状況を前記受付可能状況として前記ポータブル端末に送信し、前記依頼情報を受信した場合、当該依頼情報に対応する先行処理に対応する業務デバイスに関するデバイス処理フローを取得して前記デバイス処理フローを実行することを特徴とする情報端末連携方法。請求項8また9のいずれかに記載の情報端末連携方法において、前記ポータブル端末は、前記依頼情報を送信するデバイス端末の決定において、前記複数のデバイス端末のうち、接続されている業務デバイスの中で、専有されている業務デバイスの数が最も多いデバイス端末を、依頼情報を送信するデバイス端末として決定することを特徴とする情報端末連携方法。請求項8または9のいずれかに記載の情報端末連携方法において、前記ポータブル端末は、前記依頼情報を送信するデバイス端末の決定において、前記複数のデバイス端末のうち、接続されている業務デバイスの中で、接続されている業務デバイスに対して専有されている業務デバイスの割合が最も高いデバイス端末を、頼情報を送信するデバイス端末として決定選択することを特徴とする情報端末連携方法。特許文献1では、金融デバイスの使用状況をサーバ側で集中管理することにより、システムの構成変更や多様な業務要求に柔軟かつ効率的に対応することを目指している。複数の情報端末から金融デバイスを利用する場合、複数の情報端末間による金融デバイスの専有タイミングが競合しないように、金融デバイスを効率的に共有する必要があるが、特許文献1は金融デバイスの効率的な処理を目的としたものではなかった。金融デバイスを効率的に共有するには、金融デバイスの専有時間を短縮させる必要がある。そのためには、取引の一連のプロセス全体における取引状況に応じた金融デバイスの使用状況を把握する必要がある。しかし、特許文献1は情報端末上に処理すべき取引があるタイミングでの金融デバイスの使用状況しか確認することができない。本発明の目的は、取引状況に応じて、取引の一連のプロセスの中で金融デバイスに関する処理の一部を先行して実行することにより、営業店内で金融デバイスを利用した取引の時間を短縮させることができる技術を提供することにある。本発明では、前提として、ポータブル端末と連携可能物理的な接続が可能な金融デバイスは限定されているものである。そして、ポータブル端末から金融デバイス等の特定デバイスを利用連携するために、複数の特定デバイスを集約して接続したデバイス端末を用いるこれは、当該システムを利用する営業店内に設置することが好適である。このとき、ポータブル端末はデバイス端末と処理を連携させる際、デバイス端末を利用して、上記の前提制限を満たす特定デバイスおよびその連携すべきタイミングを特定するものである。ポータブル端末においてある取引の一連の処理全体を通常時処理と呼び、通常時処理の中で先行して行うことができる金融デバイスに関する一部分の処理を先行処理と呼び、通常時処理の中で先行処理を行わなかった先行処理以降の残りの処理をデバイス実行時処理と呼ぶことにする。また、現在ないしあるタイミングで行われている取引を取引名と呼び、当該取引の中で現在行われている取引ステップを取引状態と呼び、少なくとも取引名と取引状態から成る現在の取引を識別するための情報を取引状況と呼ぶことにする。なお、対象となる取引はあくまで一例であり、何らかの処理であれば構わない。上記の目的を達成するために、本発明の一例として、金融取引を実行する場合では、ポータブル端末上で行われる取引の一連の処理の中で、取引状況に応じて先行処理を複数のデバイス端末に依頼し、先行処理を受付けることができるデバイス端末の中から、複数のポータブル端末が効率的に複数のデバイス端末を共有できるようにデバイス端末を決定し、決定されたデバイス端末は取引状況に応じて先行処理を行う。より具体的には以下の処理を行う。取引の一連の処理を行うポータブル端末と、金融デバイスが接続された複数のデバイス端末と、サーバが通信網を介して接続されている情報端末連携システムにおいて、ポータブル端末は、取引ステップが進むたびに、先行処理判定情報を参照して先行処理を依頼することが可能なタイミングであるかどうかを判定する。もし現在の取引ステップが先行処理を依頼することが可能なタイミングであれば、当該ポータブル端末は複数のデバイス端末に対して取引状況を送信し、先行処理の受付可否の問合せを行う。各デバイス端末は、当該ポータブル端末から受信した先行処理の受付可否の問合せに対して、取引状況判定情報を参照して当該ポータブル端末から受信した取引状況に応じて、当該デバイス端末に接続されている金融デバイスの専有状況を計算し、その計算結果を受付可能状況として当該ポータブル端末に通知する。当該ポータブル端末は、各デバイス端末から受信した受付可能状況を基にして、各デバイス端末に接続されている金融デバイスの中で、専有されている金融デバイス数が最も多いデバイス端末を先行処理の依頼先として決定する。デバイス端末の利用効率を上げるために、金融デバイスの専有率が高いデバイス端末を優先して先行処理の依頼先に決定するという考え方に基づいている。当該ポータブル端末は、決定されたデバイス端末に対して取引状況および取引データを送信し、先行処理を依頼する依頼情報を送信する。上記で決定されたデバイス端末は、当該ポータブル端末から先行処理の依頼を受信し、当該ポータブル端末から受信した取引状況に応じて、金融デバイスに関する処理を行うデバイス処理フローを取得し、先行処理として取得された当該デバイス処理フローを実行する。当該ポータブル端末は、取引ステップが進むたびに、デバイス実行時処理を依頼することが可能なタイミングであるかどうかを判定する。もし現在の取引ステップがデバイス実行時処理を依頼する依頼情報を送信することが可能なタイミングであれば、当該ポータブル端末は上記で決定されたデバイス端末に対して取引状況および取引データを送信し、デバイス実行時処理を依頼する依頼情報を送信する。上記で決定された当該デバイス端末は、当該ポータブル端末からデバイス実行時処理の依頼を受信し、取引状況判定情報を参照して当該ポータブル端末から受信した取引状況に応じて、金融デバイスに関する処理を行うデバイス処理フローを取得し、デバイス実行時処理として取得された当該デバイス処理フローを実行する。なお、当該ポータブル端末が先行処理の依頼先のデバイス端末を決定するさい、各デバイス端末からの受信した受付可能状況を基にして、各デバイス端末に接続されている金融デバイスの中で、専有されている金融デバイスの割合が最も高いデバイス端末を先行処理の依頼先として決定してもよい。本発明によれば、情報端末での処理状況に応じて、特定デバイス例えば、金融デバイスに関する処理の一部を先行して実行するので、特定デバイスを実際に専有する時間を短縮することができる。また、情報端末は特定デバイスの専有時間を短縮するので、特定デバイスを利用するための待ち時間を減少させることができる。以下、図面を用いて本発明の一実施形態について説明する。本実施形態では、銀行営業店において定期預金を解約するときに、ポータブル端末を金融デバイスと連携させて、定期預金解約取引の一部を先行して処理する情報端末連携システムおよび方法の例を用いる。ただし、本発明の技術的思想は、この例に限定されるものではない。つまり、金融分野以外の取引について適用可能であり、また、取引以外の相談、通知などの業務にも適用可能なものである。なお、本発明で述べるポータブル端末とは、運搬可能なPCPersonalCoputer、タブレット型端末、スレート型端末、スマートフォン、携帯電話などであり、金融商品を取引するためのプログラムが実行可能なコンピュータであればよい。また、金融デバイスとは、現金の入出金を行うキャッシャ、通帳プリンタ通帳記帳機、通帳発行機、認証装置、帳票を読取るスキャナ、磁気/ICIntegratedCircuitカードリーダなど、金融商品を取引するために必要なデバイスである。本実施形態では、以下のような利用シーンを想定する。銀行営業店に来店する顧客は、具体的な目的を持って来店する人だけではなく、そろそろ住宅を購入したいけど、何をすればいいか分からない、銀行でどんな相談にのってもらえるのか、まずは軽く会話をしたい、来店ついでに必要そうな情報を集めたいといった漠然とした気持ちを持った人もいる。行員はポータブル端末を持って営業店内を自由に動き回り、来店顧客のところに出向いてその場で用件を伺って接客を行う。行員は顧客との軽いコミュニケーションの中でヒアリングやアドバイスを行い、具体的な相談や取引に移っていく。営業店内ではローカウンタの設置エリアやカウンタ数が限られているため、行員は顧客にいちいち場所を移動してもらうのではなく、行員は最初に接客したその場例えば、ロビーエリアにある近くのテーブルでポータブル端末を活用して相談や取引に必要な情報の参照、取引データの入力などを行い、そのまま取引を進めていく。行員は顧客との取引を具体的に進め、カード読取り、指静脈認証、現金入出金、記帳、帳票読取りなどの金融デバイスの操作が必要になると、ロビーエリア内に設置された近くのデバイス端末のところに移動して、デバイス端末に接続された金融デバイスを操作する。このとき、実際にデバイス端末の設置場所に移動してから金融デバイスの操作例えば、出金操作を開始するのではなく、デバイス端末の設置場所に移動する前に先行してデバイス端末に金融デバイスの処理の一部を実行させておく。例えば、出金額を計数して現金をスタッカに格納するまでの処理を行っておく。その後、デバイス端末の設置場所に着いたときに、金融デバイスに関する残りの処理を実行する。例えば、キャッシャの投入口をオープンし、スタッカに格納された現金を排出する。以上のような利用シーンにおいて、通常時処理の例は、ポータブル端末で出金額が確定された後に、デバイス端末が出金計数を行い、キャッシャ内部のスタッカに現金を格納し、投入口をオープンし、スタッカに格納された現金を排出する一連の処理である。このとき、先行処理の例は、ポータブル端末で出金額が確定された後に、デバイス端末が出金計数を行い、キャッシャ内部のスタッカに現金を格納するまでの処理である。一方、デバイス実行時処理の例は、キャッシャの投入口をオープンし、スタッカに格納された現金を排出する処理である。このとき、デバイス端末は複数のポータブル端末から同時に先行処理を受付け、先行処理を実行する。つまり、先行処理の段階では複数または1台のポータブル端末がデバイス端末を共有した状態である。一方、行員と顧客がデバイス端末の設置場所に出向き、残りのデバイス実行時処理を行うときは、1台のポータブル端末が当該デバイス端末を専有した状態である。図1は、本実施形態における情報端末連携システムの機能構成例を示す図である。複数のポータブル端末1、複数のデバイス端末2、サーバ3は通信網4を介して接続されている。ポータブル端末1は5個の機能、デバイス端末は3個の機能を備えており、各機器のハードウェアおよびハードウェアを制御するプログラムによってこれらの機能が動作する。ポータブル端末1は、入出力装置としてタッチパネル171を装備している。タッチパネルの代わりにディスプレイ、マウス、キーボードなどであってもよい。また、ポータブル端末1は、非接触ICチップ172、GPSGlobalPositioningSystem173を装備していてもよい。ポータブル端末1の第一の機能は、行員または顧客がポータブル端末1のタッチパネル171を利用して取引データを入力する入力機能11である。ポータブル端末1の第二の機能は、行員または顧客がポータブル端末1のタッチパネル171を利用して入力した取引データの内容、デバイス端末2またはサーバ3から受信したデータの内容、サーバ3から受信した取引画面などを表示する表示機能12である。ポータブル端末1の第三の機能は、ポータブル端末1内部で取扱う情報を管理する記憶機能13である。記憶機能13は、先行処理判定情報131、先行処理管理情報132を管理している。これらの情報は、ポータブル端末1内のメモリ上または外部記憶装置上で保持されている。ただし、これらの情報はサーバ3からポータブル端末1に事前配布されたものであってもよいし、システム起動の際やプログラム実行にサーバ3から動的に取得するものであってもよい。ポータブル端末1の第四の機能は、デバイス端末2およびサーバ3とデータを送受信するための通信機能14である。ポータブル端末1の第五の機能は、取引を行うプログラムを実行し、上記第一から第四の機能および171から173のようなハードウェアを制御する制御機能15である。デバイス端末2は、金融デバイスとしてキャッシャ241、通帳プリンタ242、通帳発行機243、認証装置244、スキャナ245、LBPLaserBeamPrinter246、レシートプリンタ247、MSMagneticStripe/ICカードリーダ248を装備している。ただし、デバイス端末2はこれらの金融デバイスをすべて装備する必要はなく、これら以外の金融デバイスまたは汎用的な表示装置、入力装置、印刷装置などを装備していてもよい。また、各デバイス端末2が同じ金融デバイスを装備した同一構成である必要はなく、デバイス端末2ごとに接続されている金融デバイスが異なっていてもよい。さらに、1台のデバイス端末2に同じ種類の金融デバイスが複数接続されていてもよい。デバイス端末2の第一の機能は、デバイス端末2内部で取扱う情報を管理する記憶機能21である。記憶機能21は、取引状況判定情報211、専有状況管理情報212、デバイス処理フロー情報213を管理している。これらの情報は、デバイス端末2内のメモリ上または外部記憶装置上で保持されている。ただし、これらの情報はサーバ3からデバイス端末2に事前配布され、保持されたものであってもよいし、システム起動時やプログラム実行にポータブル端末1またはサーバ3から動的に取得するものであってもよい。デバイス端末2の第二の機能は、ポータブル端末1およびサーバ3とデータを送受信するための通信機能22である。デバイス端末2の第三の機能は、金融デバイスの処理に関わるプログラムを実行し、上記第一と第二の機能および241から248のようなハードウェアを制御する制御機能23である。サーバ3は、営業店サーバに相当するものである。サーバ3は、ポータブル端末1またはデバイス端末2からの要求に応じて勘定系ホストや情報系サーバと連携し、決済処理、顧客情報照会、取引履歴照会などを行う。通信路4は、専用線、有線LANLocalAreaNetwork、無線LANなどである。特に、ポータブル端末1とデバイス端末2の間の通信は、赤外線通信、非接触IC通信などの近距離無線通信であってもよい。なお、本発明では、運搬可能なポータブル端末1の利用を想定したが、ポータブル端末1を運搬せずに設置場所を固定して利用してもよい。また、ポータブル端末1の代わりに、設置型のPCを利用してもよい。図2は、実施形態の先行処理判定情報131の一例を示す図である。先行処理判定情報131は、取引の中の各処理ステップ例えば、取引の画面遷移において各画面を表示するタイミングで、デバイス端末2に先行処理を依頼することが可能なタイミングであるかどうかを判定するために利用される。取引名1311は、定期新約、口座開設、投信購入、相続などの取引名や取引種類を示す。取引状態1312は、取引名1311で表される取引の中でデバイス端末に先行処理を依頼できる処理ステップ例えば、取引画面の名称や取引画面における操作の種類を示す。例えば、図2の1つめのレコードは、定期満期の取引において、払戻し確定を行った処理ステップのタイミング顧客が払戻し実行確認画面で払戻しを確定したときのタイミングで、デバイス端末2に対して先行処理を依頼することが可能であることを示す。なお、先行処理判定情報131の各レコードは事前に定義、記録されたものである。図3は、実施形態の先行処理管理情報132の一例を示す図である。先行処理管理情報132は、デバイス端末2に先行処理を依頼したかどうかを記録するために利用される。ポータブル端末ID1321は、当該ポータブル端末を識別するためのIDを示す。デバイス端末ID1322は、先行処理を依頼したデバイス端末を識別するためのIDを示す。受付番号1323は、先行処理の依頼を受付けたデバイス端末が先行処理を管理するために発行する番号を示す。なお、ポータブル端末ID1321、デバイス端末ID1322、受付番号1323は一意に識別可能な番号である。例えば、当該ポータブル端末のポータブル端末ID1321の値がP001である場合、先行処理を依頼する前は、まだデバイス端末ID1322と受付番号1323は確定していないので、ポータブル端末ID、デバイス端末ID、受付番号の値はP001、-、-である。以降では、未確定データを-と表記する。この後、当該ポータブル端末はデバイス端末IDがD01であるデバイス端末に先行処理を依頼し、先行処理の受付番号として101が発行された場合、図3の1つめのレコードのように、ポータブル端末ID、デバイス端末ID、受付番号の値をP001、D01、101として先行処理管理情報132に格納する。なお、本実施形態では説明を簡単にするため、1台のポータブル端末では1つの取引のみを行っていると想定する。この場合、先行処理管理情報132のレコード数は高々1であり、受付番号1323は必ずしも必要ない。一方、1台のポータブル端末で複数の取引を行っている場合、先行処理管理情報132のレコード数は複数存在してもよく、受付番号1323は必要になる。図4は、本実施形態の取引状況判定情報211の一例を示す図である。取引状況判定情報211は、ポータブル端末での取引状況に応じて、どの金融デバイスを専有し、またどの処理フローを実行するのかを判定するために利用される。取引状況番号2111は、取引状況判定情報211の各レコードを識別するための番号を示す。なお、取引状況番号2111は一意に識別可能な番号である。取引名2112は取引名や取引種類を示す。取引状態2113は、取引名2112で表される取引の中での処理ステップ例えば、取引画面の名称や取引画面における操作の種類を示す。処理区分2114は、ポータブル端末1の取引状況が当該レコードの取引名2112と取引状態2113の値であったときに、a先行処理を実行するのか、b先行処理を実行した後に、デバイス実行時処理を実行するのか、c通常時処理を実行するのかを示す。このとき、aの場合は先行時、bの場合は実行時、cの場合は通常時を表記する。利用デバイス2115は、ポータブル端末1の取引状況が当該レコードの取引名2112と取引状態2113の値であったときに、利用する金融デバイスの集合を示す。また、cについては、先行処理やデバイス実行時処理を実行せずに、通常時処理を実行してもよい。専有範囲2116は、ポータブル端末1の取引状況が当該レコードの取引名2112と取引状態2113の値であったときに、a当該デバイス端末全体、つまり、デバイス端末自体およびこれに接続される各金融デバイスを専有するのか、b当該デバイス端末の特定の金融デバイスを専有するのかを示す。具体的には、aの場合は端末全体と表記し、bの場合は専有させる金融デバイス名の集合を表記する。デバイス処理フロー名2117は、ポータブル端末1の取引状況が当該レコードの取引名2112と取引状態2113の値であったときに、実行する処理フロー名を示す。例えば、図4の1つめのレコードは、ポータブル端末1の取引状況が定期満期の取引における払戻し確定のステップであるとき、デバイス端末2は先行処理として端末全体を専有し、キャッシャを利用して出金先行処理フローを実行することを示す。ここで、aの専有については、デバイス端末自体を専有するように制御することで、各金融デバイスを専有可能になる。なお、専有範囲2116に特定の金融デバイスが記載されている場合、当該金融デバイスのみを専有するが、当該デバイス端末に接続されたその他の金融デバイスは専有されていないため、複数の処理を並行して実行することができる。例えば、図4の4つめのレコードと7つめのレコードは金融デバイスの専有範囲が競合しないため、さらにこれらの先行処理を実行することができる。一方、専有範囲2116に端末全体と記載されている場合、先行処理であっても端末全体を専有する必要があるので、あるデバイス端末2がすでに他の金融デバイスの先行処理を実行していると、当該デバイス端末2は端末全体の専有を要求するようなポータブル端末1からの先行処理を受付けることはできない。図5は、実施形態の専有状況管理情報212の一例を示す図である。専有状況管理情報212は、デバイス端末2が受付けている先行処理の情報を記録するために利用される。受付番号2121は、当該デバイス端末2で実行している先行処理を識別する番号を示す。ポータブル端末ID2122は、先行処理を受付けているポータブル端末IDを示す。取引状況番号2123は、先行処理を受付けている取引状況を識別するための番号であり、取引状況判定情報211の取引状況番号2111で示されている番号を表記する。例えば、図5は、現在先行処理を1件受付けており、ポータブル端末IDがP001であるポータブル端末1から、取引状況判定情報211の取引状況番号2111が1である先行処理を受付けている実行していることを示す。なお、デバイス端末2が複数の先行処理を受付けている場合には複数のレコードが格納され、まだ先行処理を受付けていない場合にはレコードは存在しない。図6は、本実施形態のデバイス処理フロー情報の一例を示す図である。デバイス処理フロー情報213は、金融デバイスに関する処理フローを取得するために利用される。デバイス処理フロー名2131は金融デバイスに関する処理フローの名称であり、取引状況判定情報211のデバイス処理フロー名2117によって参照される。なお、デバイス処理フロー名2131は一意に識別可能な名称である。デバイス処理フロー内容2132は金融デバイスに関する処理フローの定義であり、フローチャート、シーケンス図などを利用して記述される。例えば、図6の1つめのレコードは、出金先行処理フローの処理フロー内容を定義したものである。出金先行処理フローが呼出されると、デバイスオープン、監視イベント登録、デバイスロック、入金計数禁止、出金計数の処理が順番に実行されることを示す。以下では、ポータブル端末1を利用して取引を行うとき、ポータブル端末1をデバイス端末2と連携させて金融デバイスを利用する処理の流れについて説明する。ポータブル端末1上で取引を行うプログラム以下、単に取引プログラムとも記すを起動すると、表示機能12により取引画面が表示され、入力機能11により画面上の項目やボタンを選択すると次の取引画面が表示される。このような取引プログラムは制御機能15により実行され、取引画面の遷移を繰り返すことにより、取引を完了させることができる。取引プログラムは、サーバ3に配置されたWebアプリケーションであっても、ポータブル端末1にインストールされたプログラムであってもよい。図7は、本実施形態のポータブル端末1において取引を実行するための全体処理フローを示す図である。なお、取引プログラムは現在ないしある時間で実行中の取引名と取引状態をポータブル端末のメモリ上で保持すると仮定する。また、ポータブル端末1は、営業店内に設置されて利用可能なデバイス端末IDの集合もメモリ上で保持すると仮定する。ステップ501では、取引の一連のプロセスの中で取引画面を表示し、行員または顧客により当該取引画面の入力や確認が完了するとステップ502以降の処理を実行する。例えば、定期預金の解約内容を確認し、行員が確認ボタンを押下すると、ステップ502に遷移する。ここで、処理ステップ群55は先行処理を行うための処理ステップの集合であり、処理ステップ群56はデバイス実行時処理または通常時処理を行うための処理ステップの集合である。ステップ502では、この遷移タイミングで先行処理をデバイス端末2に依頼可能であるかどうかを判定する。具体的には、先行処理判定情報141に格納されているレコードを参照し、現在メモリ上で保持されている取引名と取引状態に一致するレコードが存在するかどうかを判定する。もし一致するレコードが存在すればステップ503に遷移し、一致するレコードが存在しなければステップ504に遷移する。例えば、定期満期取引で定期預金を解約することになり、払戻しを確定させた払戻し確定状態であるときに、本ステップが呼びされたとする。先行処理判定情報141のレコードを参照すると、定期満期、払戻し確定レコードが存在するため、ステップ503に遷移する。ステップ503では、複数のデバイス端末2に先行処理を受付けることが可能であるかどうかを問合せる情報を送信し、先行処理の受付けが可能であるデバイス端末2を一つ選択し、先行処理の実行を依頼する。以降の図8で、本処理の詳細を説明する。ステップ504では、この遷移タイミングでデバイス実行時処理または通常時処理をデバイス端末2に依頼可能であるかどうかを判定する。具体的には、取引プログラムの中の処理として金融デバイスに関する処理を依頼するかどうかを判定する。もし金融デバイスに関する処理を依頼する取引状態であればステップ505に遷移し、そうでなければステップ508に遷移する。例えば、定期満期取引で定期預金を解約することになり、払戻しが確定され、現金をキャッシャから排出する取引状態であれば、デバイス実行時処理または通常時処理を行う必要があるので、ステップ505に遷移する。ステップ505では、これまでの取引の一連の処理の中で、デバイス端末2に先行処理を依頼済みであるかどうかを判定する。具体的には、先行処理管理情報142に格納されているレコードを参照し、先行処理を依頼したことを示すレコードが存在するかどうかを調べる。もしレコードが存在すればステップ506に遷移し、存在しなければステップ507に遷移する。例えば、定期満期取引の払戻しを確定処理ステップで先行処理を依頼済みであり、図3のようなレコードが存在する場合は、ステップ506に遷移する。ステップ506では、デバイス端末2に対してすでに先行処理を依頼済みであるため、デバイス端末2にデバイス実行時処理の実行を依頼し、残りの処理を完了させる。以降の図10で、本処理の詳細を説明する。ステップ507では、デバイス端末に対して先行処理を依頼していないため、デバイス端末に通常時処理の実行を依頼し、処理を完了させる。通常時処理は、以降で説明する図8の先行処理と図10のデバイス実行時処理をまとめて順番に行う処理である。ステップ508では、処理ステップ群55または処理ステップ群56の実行結果に基づいて、ステップ501の取引画面の次に表示する取引画面を取得する。ステップ509では、もしステップ508で次の画面が存在しなければ、取引の一連の取引ステップが完了したと判断して、本処理フローを終了させ、それ以外外の場合はまだ取引が続くと判断して、ステップ501に遷移する。図8は、本実施形態のポータブル端末1とデバイス端末2において先行処理を実行するための処理フローを示す図である。図8の処理フローは、図7のステップ503で実行されるものである。ステップ601では、現在の取引プログラムで実行されている取引名および取引状態をポータブル端末1上のメモリから取得する。例えば、取引名は定期満期、取引状態は払戻し確定である。ステップ602では、メモリ内で保持している営業店内で利用可能なデバイス端末2の集合の中から、まだ先行処理の依頼の問合せをしていないデバイス端末2を1つ選択する。ステップ603では、ポータブル端末1は上記ステップ602で選択したデバイス端末2に対して、先行処理の依頼を受付けることができるかどうかを問合せる。このとき、ポータブル端末1はデバイス端末2に対して取引状況としてステップ601で取得した取引名と取引状態を送信する。ステップ604では、デバイス端末2は、取引状況判定情報211に格納されているレコードの中から、ポータブル端末1から受信した取引状況取引名と取引状態に一致するレコードを抽出する。そして、当該レコードの専有範囲2116に定義されている範囲で、デバイス端末2を専有できるかどうかを判定する。具体的には、専有状況管理情報212に格納されているレコードを参照してすでに専有されている専有範囲と、ポータブル端末1から依頼された先行処理として専有を希望する専有範囲が衝突しないかどうかを計算する。例えば、デバイス端末2に通帳発行機が1台接続されており、別の先行処理によってすでに通帳発行機が専有されている場合、新たに通帳発行機を利用しようとしても、利用を希望する金融デバイスの専有範囲が衝突すると判定する。また、専有範囲が端末全体である場合、専有状況管理情報212にレコードが存在すると金融デバイスの専有範囲が衝突すると判定する。本ステップにおいて専有範囲が衝突しない場合、受付可能状況を以下で説明するビット列のデータと定義する。このビット列のデータは、先行処理を受付けたと仮定した場合の専有範囲とする。当該デバイス端末2に接続されている各金融デバイスについて、a専有されているなら1、b専有されていないなら0とする。例えば、デバイス端末2にキャッシャ、通帳発行機、レシートプリンタが接続されていて、先行処理を受付けることにより、通帳発行機とレシートプリンタが専有される場合は、受付可能状況はキャッシャ、通帳発行機、レシートプリンタ=0、1、1というビット列である。もし専有範囲が端末全体である場合は、受付可能状況はキャッシャ、通帳発行機、レシートプリンタ=1、1、1というビット列である。一方、ステップ604において専有範囲が衝突する場合、つまり先行処理の依頼を受付けることができない場合、受付可能状況をNGと定義する。ステップ605では、ステップ604で計算された受付可能状況をポータブル端末1に送信する。なお、上記では、デバイス端末2においてステップ604およびステップ605の処理を行う方法を説明した。別の処理方法として、各デバイス端末2は先行処理を受付可能であるかどうかを計算せず、現在専有されている金融デバイスの情報を単にポータブル端末1に送信し、ポータブル端末1側で受付可能状況を計算する方法でああってもよい。ステップ606では、ポータブル端末1は、デバイス端末2から受信した受付可能状況をメモリ上に保持しておく。このとき、受付可能状況がどのデバイス端末のものであるかを識別できるように、デバイス端末IDと対応付けて管理しておく。ステップ607では、メモリ内で保持されている営業店内で利用可能なデバイス端末の集合の中から、まだ先行処理の依頼の問合せをしていないデバイス端末2が存在するかどうかを判定する。もしまだ問合せをしていないデバイス端末が存在すればステップ602に遷移し、もし存在しなければステップ608に遷移する。ステップ608では、ステップ606において保持されたデバイス端末2から受信した受付可能状況の集合に基づいて、実際に先行処理を依頼するデバイス端末2を決定する。図9は、本実施形態のポータブル端末1において先行処理の依頼先を決定するための処理フローを示す図である。図9の処理フローは、図8のステップ608で実行されるものである。ステップ651では、ステップ606で保持されている受付可能状況の集合の中から、受付不可以外のものを抽出する。つまり、ステップ604で計算された受付可能状況がNG以外のものを抽出する。ただし、もしすべての受付可能状況がNGであれば、図9の処理フローを終了し、図8に戻って先行処理を依頼せずに図8の処理フローを終了する。ここで、各デバイス端末2における受付可能状況について、どの程度金融デバイスが専有されているかを示す指標として重みを導入する。重みの一例は、デバイス端末2に接続されている金融デバイスの中で専有されている金融デバイスの数である。つまり、受付可能状況を示すビット列の中での1の総数である。例えば、受付可能状況がキャッシャ、通帳発行機、レシートプリンタ=0、1、1であれば、重みは2である。重みが大きいほど、デバイス端末2に接続されている金融デバイスの専有率が高いことを示す。ステップ652では、ステップ651で抽出された受付可能状況の集合の中から、重みが最大であるものを抽出する。ステップ653では、ステップ652で抽出された受付可能状況が複数存在すればステップ655に遷移し、それ以外の場合つまり1つ存在する場合はステップ654に遷移する。ステップ654では、ステップ652で抽出された受付可能状況に該当するデバイス端末2を先行処理の依頼先に決定する。ステップ655では、ステップ652で抽出された受付可能状況の集合の中からデバイス端末2を1つ選択し、そのデバイス端末2を先行処理の依頼先に決定する。このときの第一の選択方法は、ポータブル端末1のGPS173およびデバイス端末2の設置場所の位置情報を活用して当該ポータブル端末1から最も近いデバイス端末2を選択する方法である。ただし、ポータブル端末はデバイス端末の位置情報を事前にメモリ上で保持していると仮定する。第二の選択方法は、ポータブル端末1が各デバイス端末2に対して先行処理の受付可否について問合せをしたとき、応答時間が最も短いデバイス端末2を選択する方法である。ただし、ポータブル端末1は応答時間を計測していると仮定する。第三の選択方法は、ポータブル端末1の画面に選択可能なデバイス端末2を表示し、行員に選択してもらう方法である。第四の選択方法は、ポータブル端末1がデバイス端末2を任意に一つ選択する方法である。あるいは、これら以外の選択方法であってもよい。なお、ステップ652では、重みを利用して先行処理の依頼先を抽出したが、別の方法として、使用率が最も高い受付可能状況を抽出する方法であってもよい。使用率とは、デバイス端末2に接続されている金融デバイスの総数に対して、専有されている金融デバイスの割合である。この使用率は、受付可能状況を示すビット列の長さに対する1の割合で計算することができる。例えば、受付可能状況がキャッシャ、通帳発行機、レシートプリンタ、LBP=0、1、1、0であれば、使用率は50である。さらに、先行処理の依頼先を抽出する別の方法として、優先度が最も高い受付可能状況を抽出する方法であってもよい。優先度とは、各デバイス端末2に接続されている金融デバイスに優先順位を付けて、当該デバイス端末2の受付可否状況の値を計算したものである。この優先度は、金融デバイスを優先度の高い順に並べて、受付可能状況を示すビット列を2進数と見なすことにより計算できる。例えば、受付可能状況がキャッシャ、通帳発行機、レシートプリンタ、LBP=0、1、1、0であるとき、優先順位が通帳発行機、キャッシャ、レシートプリンタ、LBPの順番であれば、優先度は2進数表記で1010である。受付可能状況が同じあっても、優先順位がキャッシャ、通帳発行機、LBP、レシートプリンタの順番であれば、優先度は2進数表記で0101つまり101であり。優先度は、後者より前者の方が高い。ステップ609では、現在ポータブル端末1上で実行されている取引プログラムにおける取引データをメモリから取得する。例えば、取引データは口座番号や解約金額出金額などの具体的なデータである。取引データは、メモリ上のデータ以外にも、ポータブル端末内部の外部記憶から取得したデータ、またはサーバから取得したデータであってもよい。ステップ610では、ステップ608において決定された先行処理の依頼先のデバイス端末を示すデバイス端末IDを取得し、そのデバイス端末IDを先行処理管理情報142のデバイス端末ID1322に記録する。例えば、先行処理管理情報142のレコードとしてポータブル端末ID、デバイス端末ID、受付番号=P001、D01、-のようなデータを記録する。ステップ611では、ステップ608において決定された先行処理の依頼先のデバイス端末2に対して、先行処理を依頼する。このとき、ポータブル端末1はポータブル端末ID、ステップ601で取得した取引状況取引名と取引状態、ステップ609で取得した取引データを送信する。ステップ612では、デバイス端末2は取引状況判定情報211に格納されているレコードを参照して、ポータブル端末1から受信した取引状況取引名と取引状態に一致するレコードを抽出し、このレコードの取引状況番号を取得する。そして、新たに受付番号を発行し、本受付番号、ステップ611で送信されたポータブル端末ID、本ステップで取得された取引状況番号をレコードとして専有状況管理情報212に格納する。例えば、図5のようなレコードを格納する。ステップ613では、ステップ612で発行された受付番号をポータブル端末1に送信する。ステップ614では、ポータブル端末1は先行処理管理情報142の該当するレコードの受付番号1323に受信した受付番号を格納する。例えば、先行処理管理情報142のレコードとしてポータブル端末ID、デバイス端末ID、受付番号=P001、D01、-のようなデータが格納されているとき、受付番号が101であれば、ポータブル端末ID、デバイス端末ID、受付番号=P001、D01、101とレコードを更新する。ステップ615では、デバイス端末2は取引フロー情報213を参照して、先行処理として実行する処理フローを取得する。例えば、ステップ612で受信した取引名が定期満期、取引状態が払戻し確定であるとき、取引状況判定情報211に格納されているレコードから1つめのレコードを抽出し、先行処理として実施する出金先行処理フローを取得する。ステップ616では、ステップ615で取得された処理フローを実行する。以上の処理を実行することにより、ポータブル端末1は適切なデバイス端末2に対して先行処理を依頼するとともに、デバイス端末2は効率的に先行処理を実行する。図10は、本実施形態のポータブル端末1とデバイス端末2においてデバイス実行時処理を実行するための処理フローを示す図である。図10の処理フローは、図7のステップ506で実行されるものである。ステップ701では、先行処理管理情報142に格納されているレコードを参照して、先行処理を依頼したデバイス端末2を特定する。ステップ702では、現在の取引プログラムで実行されている取引状況取引名と取引状態および取引データを当該ポータブル端末1上のメモリから取得する。ステップ703では、ステップ701で特定されたデバイス端末2に残りの処理デバイス実行時処理を依頼する。このとき、ステップ702で取得された取引状況取引名と取引状態および取引データに加えて、先行処理管理情報132の当該レコードに格納されている受付番号もあわせてデバイス端末2に送信する。ステップ704では、デバイス端末2は、取引状況判定情報211に格納されているレコードの中から、ポータブル端末1から受信した取引状況取引名と取引状態に一致するレコードを抽出する。このとき、ポータブル端末1から受付番号も受信しているので、専有状況管理情報212に格納されているレコードの中に当該受付番号が存在すれば、デバイス実行時処理を行えばよいと判断することができる。そして、取引状況判定情報211に格納されている当該レコードのデバイス処理フロー名2117に定義されているデバイス処理フローをデバイス処理フロー情報213から取得する。例えば、先行処理として図4の1つめのレコードで定義されている出金先行処理フローを行っている場合は、本ステップでは図4の2つめのレコードに定義されている出金実行処理フローを取得する。ステップ705では、ステップ704で取得された処理フローを実行する。ステップ706では、ステップ705で実行された処理フローの処理結果をポータブル端末1に送信する。ステップ707では、デバイス端末2における先行処理またはデバイス実行時処理が完了したので、専有状況管理情報212から当該レコードを削除する。ステップ708では、ポータブル端末1はデバイス端末2から処理結果を受信し、また、先行処理管理情報142に格納されている当該レコードを削除する。以上の処理を実行することにより、ポータブル端末1はデバイス端末2と連携して取引を完了させることができる。なお、上記実施形態における先行処理として、実際にキャッシャのような金融デバイスを動作させる例を利用した。例えば、先行処理として、出金操作時にキャッシャのスタッカまで現金を格納しておく通帳発行時に通帳に事前印字しておくなどである。先行処理の別の例として、aハードウェアの初期化処理やbソフトウェアの初期化処理であってもよい。例えば、上記aの例はハードウェアのウォームアップである。また上記bの例は、iデバイス端末で実行されるプログラムデバイス処理フローで利用するオブジェクトの初期化オブジェクトの生成、オブジェクトへのデータの事前代入など、あるいはiiサーバからの指静脈データや印鑑の照合データなどの事前取得などである。このような先行処理の場合も、上記実施形態と同様の処理で実現することができる。