JP2012146095A - 取引制御システム、および取引制御方法 - Google Patents

Abstract

【課題】操作中の端末での取引ができない場合であっても取引を継続させることが可能な取引制御システム、および取引制御方法を提供する。
【解決手段】管理サーバは、複数の端末のそれぞれに接続されるデバイスの状態、および取引の手順と手順で必要となるデバイスと手順におけるデバイスの動作とを対応付けた構成テーブルを記憶する記憶部と、取引端末から、取引の続行可能な状態にある取引端末の検索要求を受けた場合に、構成テーブルから取引の続行可能な取引端末を特定し、特定した取引の続行可能な取引端末に取引を続行させる指示と、取引を続行させるために必要なデバイスと手順におけるデバイスの動作とを対応付けた抽出リストとを送信する構成管理部と、を備え、取引端末のうちの取引の続行を要求する第１の端末は、管理サーバから構成テーブルを取得し、取得した構成テーブルに含まれる手順に従って取引を実行する。
【選択図】図１

Description

本発明は、ＡＴＭなどの取引装置、取引端末を介して、現金の入出金などを用いた取引を支援する技術に関し、特に、複数のデバイスを用いる取引に関する。

現在、金融機関において、ＡＴＭなどの端末では、カードユニット、現金を取り扱う紙幣ユニット・硬貨ユニット、通帳記帳機、レシートプリンタなど、様々なデバイスを組み合わせて取引がなされる。

特許文献１では、本来想定されていたデバイスが接続されていない端末でも同じ目的を果たす別のデバイスが接続されていれば、動的にそのデバイスを利用できるようにすることで、取引を継続させる、という方法が開示されている。これは、例えば「取引明細出力」という目的を果たすために、業務アプリケーションとしては「通帳記帳機」というデバイスを想定していたが、同じ目的を果たすことができると定義されたデバイス（電子的なメモリへ取引明細を出力できるＩＣカードユニット）が接続されていれば、通帳記帳機が接続されていなくとも取引を継続できるようにする方法である。

特開２００７−３１６７８６号公報

しかし、利用者が利用している端末に、必要なデバイスが接続されていない場合、あるいは、デバイスが接続されていても、例えば紙幣ユニットであれば出金のための紙幣が不足していて使えない場合や、故障や用紙詰まりなどで使えない場合などでは、端末内部での監視プログラムでデバイスの状態を把握し、利用者が当該業務を実行できないようにするか、そもそも端末を利用できないような制限をかけることがある。この点について、特許文献１では考慮されておらず、単に端末を利用できないように閉塞させておくだけでは、端末の利用効率が低下してしまうという問題がある。

例えば、ＡＴＭにおいては、タッチパネルやカードユニットなどが利用できれば、比較的端末の占有時間が長時間となる取引内容の入力までは完了でき、占有時間は比較的短時間となる現金の取扱のみを他の端末で実行できるようにすることで、単に障害が発生した端末を閉塞しておくだけの場合と比較して、機器の利用効率の向上に寄与することができるが、上記従来技術ではこの点について考慮されていない。

本発明は、上記に鑑みてなされたものであって、操作中の端末での取引ができない場合であっても取引を継続させることが可能な取引制御システム、および取引制御方法を提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明にかかる取引制御システムは、デバイスに接続され、利用者との間で所定の取引を行う複数の取引端末と、前記取引端末のそれぞれを管理する管理サーバとがネットワークを介して接続された取引制御システムであって、前記管理サーバは、前記複数の端末のそれぞれに接続される前記デバイスの状態、および前記取引の手順と前記手順で必要となる前記デバイスと前記手順におけるデバイスの動作とを対応付けた構成テーブルを記憶する記憶部と、前記取引端末から、前記取引の続行可能な状態にある取引端末の検索要求を受けた場合に、前記構成テーブルから前記取引の続行可能な取引端末を特定し、特定した前記取引の続行可能な取引端末に前記取引を続行させる指示と、前記取引を続行させるために必要な前記デバイスと前記手順におけるデバイスの動作とを対応付けた抽出リストとを送信する構成管理部と、を備え、前記取引端末のうちの前記取引の続行を要求する第１の端末は、前記管理サーバから前記構成テーブルを取得し、取得した前記構成テーブルに含まれる前記手順に従って前記取引を実行し、または前記手順が続行可能でないと判定された場合に、前記抽出リストを生成する第１の実行管理部と、前記デバイスの状態に基づいて次に実行する手順が実行可能であるか否かを判定し、次に実行する手順が実行可能ではないと判定した場合に、前記第１の実行管理部が生成した前記抽出リストを前記管理サーバに送信し、前記デバイスが利用可能な前記取引端末の検索要求を行う端末制御部と、を備え、前記取引端末のうちの前記取引の続行を受け入れる第２の端末は、前記管理サーバから、前記取引を続行させる指示と、前記抽出リストとを受信した場合に、前記抽出リストに含まれる前記デバイスの動作に基づいて、前記デバイスを利用する前記取引を続行させる第２の実行管理部と、を備えることを特徴とする。

また、本発明は、上記取引制御システムで実行される取引制御方法である。

本発明によれば、操作中の端末での取引ができない場合であっても取引を継続させることが可能な取引制御システム、および取引制御方法を提供することができる。

本発明の一実施形態のシステム構成図である。 本発明の一実施形態における金融端末のデバイス状態を保持するテーブルである。 図１の端末制御部の処理手順を示すフローチャートである。 図１の業務アプリケーション実行管理部で解釈される業務手順を示すフローチャートである。 図３のステップ３０３「必要デバイスリスト更新」処理で更新されるデバイス利用可能性リストを保持するテーブルである。 本発明の第二の実施形態を示すシステム構成図である。

以下に添付図面を参照して、本発明にかかる取引制御システム、および取引制御方法の実施の形態を詳細に説明する。以下では、本発明にかかる取引制御システム、および取引制御方法を、銀行等の金融機関に設置された取引端末（例えば、ＡＴＭ（Automated teller machine））に適用した場合について説明しているが、特にこれに限定されるものではない。

図１は、本実施形態のシステム構成図である。端末に接続されたデバイスの状態、および端末から入力された案件を管理する連携サーバ１００に、利用者が取引内容を入力したり、キャッシュカードや現金など各種媒体を取り扱ったりするデバイスが接続された取引端末１１０が、ネットワークを介して複数接続されている。

連携サーバ１００は、取引端末に接続されているデバイスの状態を保存する構成管理テーブル１０１と、そのテーブルを読み書きするための構成管理部１０２と、を有している。また、利用者が利用中にデバイスが使えなくなった場合に、他の端末へ移動する際、それまでに入力や処理がなされた取引を仕掛中案件として一時保存しておくための仕掛中案件ＤＢ１０３と、そのデータを読み書きするための案件管理部１０４と、を有している。

取引端末１１０は、様々な業務を、定義された手順に従って実行していく端末制御部１１１と、業務自身の進行状態やそれまでに入力された取引内容、処理を実行するときに必要となるデバイスの情報を保持した業務アプリケーション実行管理部１１２とを有し、取引を遂行するために各種情報を入出力したり、現金やカードなどのメディアをハンドリングしたりするためのデバイス１１３が接続されている。

図２は、構成管理部１０２が管理する構成管理テーブル１０１の構成を示したものである。これによって端末のデバイス状態が管理される。構成管理テーブル１０１は、管理対象となる端末が設置されている店舗のＩＤである店番２０１、少なくとも店舗内で一意に端末を識別できる機番２０２、および、端末に接続されているデバイスの状態をデバイスごとに管理するデバイス状態２０３から構成される。デバイス状態とは、デバイスの種類ごとに定義された状態が記録される。例えば、紙幣ユニットにおける状態としては、「使用可能」という正常な状態や、「１０００円札切れ」「５０００円札切れ」「入金不可」など、各種の障害が組み合わさっていてもそれぞれを識別できるコードとして管理する。構成管理テーブル１０１のデバイス状態は、端末においてデバイスが動作し終わった時、あるいは、動作させようとしたときに障害が発生したときなど、デバイスの状態の変化が検出された時に、取引端末１１０の端末制御部１１１からデバイスの状態の変更通知を構成管理部１０２が受けて、更新される。

図３、図４は、それぞれ端末制御部１１１の処理の流れ、および業務アプリケーション実行管理部１１２が管理する例としてとりあげる業務の処理の流れである。業務の流れは、図４に示すように、実行される処理の流れ（手順）と、各処理において利用されるデバイスと、その動作とが対応付けて定義された業務手順データとして設定されている。図４では、現金振込の流れを例にとって記述した業務アプリケーションの手順を示している。なお、業務アプリケーションの手順については、例えば、連携サーバ１００の構成管理テーブル１０１や、他の記憶部（不図示）に記憶され、取引端末１１０の業務アプリケーション実行管理部１１２がこれを呼び出して実行するものとする。以降、例として、各端末のデバイスの状態は図２の構成管理テーブル１０１の通りであり、利用者が店番「００１」機番「０１」の端末を使って取引を開始したとする。具体的な取引の内容は、１００００円を現金振込するもので、このとき手数料が２１０円発生し、１１０００円を紙幣で投入し、釣銭として７９０円を硬貨で出金されるものとする。

業務アプリケーション実行管理部１１２は、業務手順データに設定された定義に従って、どこまで処理が進んでいるのかを管理する。端末制御部１１１は、業務アプリケーション実行管理部１１２と連携し、各業務の処理を１ステップずつ実行する。このときに、利用するデバイスおよびその動作について、自端末で実行可能かどうかを確認する。実行可能でなければ、可能な端末を検索し、その端末に処理を引き継ぐ。処理が引き継がれた先の端末では、同様な動作によって業務アプリケーション完了まで処理を実行していく。

利用者は端末で処理を始めると、端末制御部１１１は、取引を選択するための操作画面をディスプレイ等の表示部（不図示）に一旦表示し、表示部が利用者から取引の選択を受け付けることで、これから実行する業務が決定される（ステップ３０１）。利用者が取引を選択すると、端末制御部１１１は、業務アプリケーション実行管理部１１２に、当該業務の業務手順データに設定された定義を読み込むように伝え、業務アプリケーション実行管理部１１２は、当該業務の定義を読み込む。この業務アプリケーション実行管理部１１２が行う処理の流れについては、図４を用いて後述する。

次に、端末制御部１１１は、業務アプリケーション実行管理部１１２に対して、これから実行しようとしている処理以降の処理で必要となる可能性のあるデバイス、および動作のリストを取得するように指示し、業務アプリケーション実行管理部１１２は、業務手順データにアクセスし、これらの情報を取得する（ステップ３０２）。この段階では、業務が実行された直後であるので、業務アプリケーション実行管理部１１２が認識している業務の進行状態は、図４の各ステップが開始されるところである。

業務アプリケーション実行管理部１１２は、これから実行するステップ４０１以降の処理を順に追っていき、処理の分岐があるところでは両者の処理を網羅するようにすることで、各処理ステップで利用可能性のあるデバイスおよびその処理をリストアップ（抽出）していく。ここで、ステップ４０３には、「[硬貨Ｕ]」という表記としているが、これは、硬貨ユニットはオプションであり、利用不可でなくても実行可能であることを示している。

この手順により、業務アプリケーション実行管理部１１２がリストアップしたステップ４０１以降で利用される可能性のあるデバイスと、そのデバイスを使用する動作とを対応付けたデバイス利用可能性リスト５０は、図５に示す通りとなる。端末制御部１１１は、業務アプリケーション実行管理部１１２がリストアップしたデバイス利用可能性リスト５０を更新する（ステップ３０３）。

端末制御部１１１は、次に処理する実行内容を取得するように指示し、業務アプリケーション実行管理部１１２はその指示に従って業務手順データから次に処理する実行内容を取得する（ステップ３０４）。次の動作がなければ処理は終了であり、次の動作があれば処理を続行する（ステップ３０５）。

端末制御部１１１は、業務アプリケーション実行管理部１１２がステップ３０４で取得した処理を自分の端末で実行可能かどうかを判断する（ステップ３０６）。この判断は、自分の端末に接続されているデバイスと、そのデバイスの状態と、取得してきた処理内容のうち、デバイスにかかわる処理内容を比較することでなされる。すなわち、端末制御部１１１は、デバイスをキーにして連携サーバ１００の構成管理テーブル１０１にアクセスし、実行しようとしているデバイスが、接続されていない状態であったり、接続されていたとしても何らかの障害により動作ができない場合には実行不可として判断し、接続状態や動作可能な状態、あるいはデバイスを利用しないような処理の場合には、実行可能と判断する。

ステップ３０６において、端末制御部１１１が実行可能と判断した場合（ステップ３０６；Ｙｅｓ）は、ステップ３０５で取得してきた処理を実行する（ステップ３０７）。そして、端末制御部１１１は、ステップ３０２からステップ３０７を、自端末で実行できなくなるか、業務手順データによって定義された各処理が全て終了するまで続ける。

例えば、図４に示したような現金振込の場合、端末制御部１１１は、ステップ４０１において振込先を決め、ステップ４０２において振込金額および手数料を決め、入金されるべき金額が決まる。ここで取り上げている例で言えば、振込額と手数料の合計は１０２１０円となる。その後、端末制御部１１１は、業務処理のステップ４０３において投入口（不図示）から入金を受け付ける。入金金額以上の現金が投入されたら、端末制御部１１１は、ステップ４０５として決済処理を実行する。入金金額が決済で消費された金額（ここでは、振込金額と手数料の合計額）よりも多ければ、釣銭が出金されることになる。例として取り上げた業務においては、７９０円の出金となる。釣銭は硬貨での出金が必要となるが（ステップ４０８からステップ４１１へと進む）、図１の構成管理テーブル１０１に示したように、店番「００１」機番「０１」の端末では端末内の硬貨が少なく、釣銭を出金できない状態（硬貨切れの状態）である。これは、業務処理がステップ４１１へと進んだ段階で、端末制御部の動作であるステップ３０６において、当該処理が実行できない（ステップ３０６；Ｎｏ）、という判断になる。

端末制御部１１１は、ステップ３０８において、図５で示したようなデバイス利用可能性リスト５０を参照し、以降の処理で利用されるデバイスと動作リストの内容とを連携サーバ１００に送信し、連携サーバ１００の構成管理部１０２は、それらの情報をキーとして、動作リストに示された処理が実行可能な端末を検索する。この例では、以降の処理で必要なデバイスはタッチパネル、硬貨ユニット、レシートプリンタであり、それぞれ入力、出金、印字の操作ができれば良い。構成管理部１０２は、図１に示した構成管理テーブル１０１にアクセスし、取引端末１１０から送信されたデバイス名をキーとして、利用可能であるものを検索し、代用可能な取引端末１１０を特定する。この例では、上述したタッチパネル、硬貨ユニット、レシートプリンタの全てが利用可能である端末は、店番「００１」機番「０２」および店番「００２」機番「０４」であるが、機番「０４」は他の店舗への移動となるため、構成管理部１０２は、同じ店舗内の端末である機番「０２」の端末を、代用可能な取引端末１１０を特定する。

そして、連携サーバ１００の構成管理部１０２は、代用可能な取引端末１１０（検索候補）を特定できたか否かを判定し（ステップ３０９）、代用可能な取引端末１１０を特定できないと判定した場合（ステップ３０９；Ｎｏ）、そもそも仕掛中の当該業務は完遂できないため、今までに処理した内容を全て取り消す処理を実行する（ステップ３１１）。なお、このとき、別の検索方法も考えられる。すなわち、全ての処理を実行できる端末がないと判定された場合において、直後のステップの処理のみを実行できるような端末を検索結果として出力された場合には、ステップＳ３０９においては代用可能な取引端末１１０があると判定することも可能である。

一方、連携サーバ１００の構成管理部１０２は、代用可能な取引端末１１０を特定できたと判定した場合（ステップ３０９；Ｙｅｓ）、利用者の移動手続きを行うために、顧客が操作中の取引端末１１０において、現在仕掛中の取引内容を連携サーバの案件管理部１０４に依頼し、案件管理部１０４は、引継ぎに必要な情報を利用者に提示する（ステップ３１０）。引継ぎに必要な情報とは、例えば案件管理部１０４が発行する、操作中の取引を特定するための識別子（受付番号）である。なお、本実施の形態では、硬貨ユニットが硬貨切れの状態であるため、図４に示した業務アプリケーションの処理の流れのうち、ステップ４１１〜４１３の各処理については、後述するように、代用可能な取引端末１１０で行われることとなる。

引継ぎの処理の例としては、（１）端末制御部１１１が、操作中の取引端末１１０の表示部（不図示）に受付番号を画面に提示し、利用者がその番号を記憶して、移動先の代用可能な取引端末１１０の表示部から入力する方法、(２)受付番号をレシートプリンタで印字し、その番号を移動先の代用可能な取引端末１１０の表示部から利用者が操作して入力する方法、（３）端末制御部１１１が、キャッシュカードの挿入や排出を行うカード取扱機構（不図示）に指示し、外部記憶装置（ＩＣカードの記憶領域など）に当該受付番号を記録させ、移動先の代用可能な取引端末１１０側のカード取扱機構が読み取る方法など、が考えられる。また、（４）引継ぎ情報の中に操作中の取引データを含めて記録すると、移動先の代用可能な取引端末１１０側の処理では連携サーバ１００との通信を行うことなく、以降の処理を続行させることができる。操作中の取引データの例としては、金額や取引種別、顧客番号等の取引を特定するための情報に加え、図４に示した手順の最初から最後までの各処理においてどこまで処理が実行されたかを示す処理経過情報（例えば、処理完了済みステップにはフラグを設定する等）を、各処理ステップに対応付けて設定し、代用可能な取引端末１１０の端末制御部１１１が以降の処理を実行する際に、その取引データを参照し、処理が完了していない（例えば、フラグが設定されていない）処理ステップから取引を続行させる。

上記の方法（１）（２）および（３）の実現方法としては、連携サーバ１００の案件管理部１０４は、操作中の取引データを一意に識別できる識別子を発行し、その識別子と上述した取引データとを対応付けて仕掛中案件ＤＢ１０４に格納する。例えば、単純には当日受け付けた案件の順に番号を振っていくことにより受付番号を採番することができる。

連携サーバ１００の案件管理部１０４は、その識別子を、登録元となった取引端末１１０に送信し、取引端末１１０の端末制御部１１１は、その識別子を表示部（不図示）に表示させ、利用者は、表示された識別子を参照する。このほか、参照できるようにする方法として、レシートプリンタで当該受付番号を印字する方法、および、受付番号を外部記憶装置に保存する方法がある。さらに受付番号を印字する方法としては、単に数字を印字するだけでなく、機械読取が可能なバーコードとして印刷し、引継ぎ先の端末での自動入力を可能とする方法がある。

引継ぎ先の取引端末１１０の表示部が、元の取引端末１１０で受け取った識別子の入力を受け付けると、引継ぎ先の取引端末１１０の端末制御部１１１は、連携サーバ１００の案件管理部１０４に、その識別子を送信し、案件管理部１０４は、受信した識別子をキーとして、途中で中断していた取引データを仕掛中案件ＤＢ１０３の中から特定し、要求元である引継ぎ先の取引端末１１０に送信し、その取引端末１１０の端末制御部１１１は、受信した取引データを参照して、以降の処理を続行させる。

また、上記（４）の実現方法としては、上述した識別子および取引データをＸＭＬ（Extensible Markup Language）等のデータフォーマットで出力することが可能である。

引継ぎすべき情報の記録および引き継ぎ先での入力方法としては、そのまま文字列として紙に印字して、引継ぎ先で紙をスキャンして文字認識する方法、バーコードのような機械読取が可能な形式で印字し、引継ぎ先で当該コードを認識する方法、外部記憶装置に記録して引継ぎ先で読み込む方法などがある。

代用可能な移動先の取引端末１１０において、端末制御部１１１は、利用者がキャッシュカードをカード取扱機構（不図示）が受け付けると、移動先の端末の端末制御部１１１は、例えば、図３に示したステップ３０１において、引継ぎのための識別子の入力を表示部（不図示）から受け付ける。そして、端末制御部１１１は、受け付けられた識別子を、連携サーバ１００に送信し、連携サーバ１００の案件管理部１０４は、受信した識別しに対応する取引データを取得し、取得した取引データを取引端末１１０に送信する。そして、端末制御部１１１は、受信した取引データを参照し、取引端末１１０の各部（例えば、紙幣ユニットや硬貨ユニット、レシートプリンタ等のデバイス）を制御して、取引を続行可能な状態にスタンバイさせ、以降の処理を続行させる。

このように、取引端末１１０に接続されているデバイス１１３の状態を管理し、当該取引端末１１０で実行される業務アプリケーションの進行状況に応じて必要となるデバイス１１３の利用可否を確認し、目的のデバイス１１３が利用不可であることが分かった時点で、当該デバイス１１３を利用可能な他の取引端末１１０を検索する。さらに、それまで実行されていた業務アプリケーションの状態を仕掛中案件として一時保留し、目的のデバイス１１３が利用可能な端末から仕掛中案件を引き継ぎ、当該業務アプリケーションの実行を継続させているので、取引端末に接続されているデバイスが、業務を完遂するまでの要件を満たしていないという理由で当該業務を実行できないようにするのではなく、目的のデバイスが接続されている他の端末を組み合わせて利用することで業務を完遂できるようになり、端末の利用効率を向上させることができる。すなわち、操作中の端末での取引ができない場合であっても取引を継続させることを可能とさせ、端末の利用効率を向上させることができる。

なお、各端末の状態は、集中的に管理する連携サーバ１００において管理しても良いし、各取引端末１１０でのみ管理して、必要に応じて取引端末１１０間で情報交換するようにしても良い。また、業務アプリケーションの状態を一時保留する際には、当該業務アプリケーションにかかわる状態を連携サーバ１００のデータベースなどに集中的に管理するようにしても良いし、各取引端末１１０でのみ保存しておき、引継ぎが発生した際に、取引端末１１０間で情報を受け渡せるようにしても良い。さらに、取引の内容を利用者が持ち歩けるようにするために、識別子や取引データを紙面に印字したりＩＣカードのような情報を記録・再生可能な外部記憶装置に保存するようにしたりしても良い。この場合、前記のようにサーバや端末内で案件を管理する必要はなくなる。

また、本発明の別の実施の形態として、図６に示すように、連携サーバを設けずに、端末内に案件管理部６０１、および、構成管理部６０２を設けるような構成も考えられる。このときには、仕掛中の案件やデバイスの状態は、当該取引端末１１０に関するもののみを管理するようになる。また、他の取引端末１１０の構成情報を一元的に管理できなくなるので、取引端末１１０の記憶部等に、他の取引端末１１０を連携先候補として一覧で記憶した通信先定義６０３として保持し、取引端末１１０間で利用者が移動する際には、相互に情報交換できるようにする。例えば、通信先定義は、対象端末の店番・機番、および端末のネットワークアドレスなど、通信を確立するのに必要な情報を含め、これらの情報を取引端末１１０間で交換させる。端末間で案件を引き継ぐ際には、（１）案件を一意に識別する情報に加えて、引継ぎ元となる端末の識別子も合わせて出力し、引継ぎ先から当該案件を取得できるようにする方法、および、（２）引継ぎ情報に案件の情報を含める方法がある。これらの実現方法は、それぞれ連携サーバがある構成で説明した方法により実現できる。

なお、本発明は、上記実施の形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化し、異なる実施の形態にわたる構成要素を適宜組み合わせても良い。

１００ 連携サーバ
１１０ 取引端末
１０２ 構成管理部
１０４ 案件管理部
１１１ 端末制御部
１１２ 業務アプリケーション実行管理部。

Claims (8)

1. デバイスに接続され、利用者との間で所定の取引を行う複数の取引端末と、前記取引端末のそれぞれを管理する管理サーバとがネットワークを介して接続された取引制御システムであって、
   前記管理サーバは、前記複数の端末のそれぞれに接続される前記デバイスの状態、および前記取引の手順と前記手順で必要となる前記デバイスと前記手順におけるデバイスの動作とを対応付けた構成テーブルを記憶する記憶部と、
   前記取引端末から、前記取引の続行可能な状態にある取引端末の検索要求を受けた場合に、前記構成テーブルから前記取引の続行可能な取引端末を特定し、特定した前記取引の続行可能な取引端末に前記取引を続行させる指示と、前記取引を続行させるために必要な前記デバイスと前記手順におけるデバイスの動作とを対応付けた抽出リストとを送信する構成管理部と、を備え、
   前記取引端末のうちの前記取引の続行を要求する第１の端末は、前記管理サーバから前記構成テーブルを取得し、取得した前記構成テーブルに含まれる前記手順に従って前記取引を実行し、または前記手順が続行可能でないと判定された場合に、前記抽出リストを生成する第１の実行管理部と、
   前記デバイスの状態に基づいて次に実行する手順が実行可能であるか否かを判定し、次に実行する手順が実行可能ではないと判定した場合に、前記第１の実行管理部が生成した前記抽出リストを前記管理サーバに送信し、前記デバイスが利用可能な前記取引端末の検索要求を行う端末制御部と、を備え、
   前記取引端末のうちの前記取引の続行を受け入れる第２の端末は、前記管理サーバから、前記取引を続行させる指示と、前記抽出リストとを受信した場合に、前記抽出リストに含まれる前記デバイスの動作に基づいて、前記デバイスを利用する前記取引を続行させる第２の実行管理部と、
   を備えることを特徴とする取引制御システム。
2. 前記第１の端末は、前記端末制御部が、前記第１の端末自身に接続されている前記デバイスの状態を検出し、検出した前記デバイスと前記デバイスの状態を前記管理サーバに送信し、
   前記管理サーバは、前記第１の端末から前記デバイスの状態を受信した場合に、前記デバイスをキーとして前記構成管理テーブルに含まれる前記デバイスの状態を更新する、
   ことを特徴とする請求項１に記載の取引制御システム。
3. 前記管理サーバは、前記記憶部が、前記手順のうちの次に実行する手順が実行可能ではないと判定された場合における実行途中の手順と実行途中の取引の状態を示す取引データと前記実行途中の手順を識別するための識別情報とを対応付けた仕掛データベースを記憶し、
   前記第１の端末から前記実行途中の手順と前記取引データとを受信した場合に、受信した前記実行途中の手順と前記取引データと前記識別情報とを前記仕掛データベースに記憶させる案件管理部をさらに備え、
   前記第１の端末は、前記第１の実行管理部が、前記デバイスの状態に基づいて次に実行する手順が実行可能ではないと判定した場合に、前記実行途中の手順と前記取引データとを前記管理サーバに送信し、または前記識別情報を前記管理サーバから受信し、
   前記第２の端末は、前記第２の実行管理部が、前記利用者から受け付けた前記識別情報をキーとして前記管理サーバから前記実行途中の手順と前記取引データを取得することにより、前記取引を続行させる、
   ことを特徴とする請求項１または２に記載の取引制御システム。
4. 前記第１の端末は、前記第１の実行管理部が、前記実行途中の手順と前記取引データとを外部媒体に出力し、
   前記第２の端末は、前記第２の実行管理部が、前記外部媒体に出力された前記実行途中の手順と前記取引データを読み込んで、前記取引を続行させる、
   ことを特徴とする請求項３に記載の取引制御システム。
5. デバイスに接続され、利用者との間で所定の取引を行う複数の取引端末と、前記取引端末のそれぞれを管理する管理サーバとがネットワークを介して接続された取引制御システムで行われる取引制御方法であって、
   前記管理サーバから前記複数の端末のそれぞれに接続される前記デバイスの状態、および前記取引の手順と前記手順で必要となる前記デバイスと前記手順におけるデバイスの動作とを対応付けた構成テーブルを取得し、取得した前記構成テーブルに含まれる前記手順に従って前記取引を実行するステップと、
   前記デバイスの状態に基づいて次に実行する手順が実行可能であるか否かを判定するステップと、
   前記手順が続行可能でないと判定された場合に、前記取引を続行させるために必要な前記デバイスと前記手順におけるデバイスの動作とを対応付けた抽出リストを生成するステップと、
   次に実行する手順が実行可能ではないと判定された場合に、前記抽出リストを前記管理サーバに送信し、前記デバイスが利用可能な前記取引端末の検索要求を行うステップと、
   前記取引端末から、前記取引の続行可能な状態にある取引端末の検索要求を受けた場合に、前記構成テーブルから前記取引の続行可能な取引端末を特定し、特定した前記取引の続行可能な取引端末に前記取引を続行させる指示と前記抽出リストとを送信するステップと、
   前記管理サーバから、前記取引を続行させる指示と、前記抽出リストとを受信した場合に、前記抽出リストに含まれる前記デバイスの動作に基づいて、前記デバイスを利用する前記取引を続行させるステップと、
   を含むことを特徴とする取引制御方法。
6. 前記取引端末自身に接続されている前記デバイスの状態を検出し、検出した前記デバイスと前記デバイスの状態を前記管理サーバに送信するステップと、
   前記取引端末から前記デバイスの状態を受信した場合に、前記デバイスをキーとして前記構成管理テーブルに含まれる前記デバイスの状態を更新するステップと、
   を含むことを特徴とする請求項５に記載の取引制御方法。
7. 前記取引端末から前記手順のうちの次に実行する手順が実行可能ではないと判定された場合における実行途中の手順と実行途中の取引の状態を示す取引データとを受信した場合に、受信した前記実行途中の手順と前記取引データと前記実行途中の手順を識別するための識別情報とを対応付けた仕掛データベースに記憶させるステップと、
   前記デバイスの状態に基づいて次に実行する手順が実行可能ではないと判定された場合に、前記実行途中の手順と前記取引データとを前記管理サーバに送信するステップと、
   前記識別情報を前記管理サーバから受信するステップと、
   前記利用者から受け付けた前記識別情報をキーとして前記管理サーバから前記実行途中の手順と前記取引データを取得することにより、前記取引を続行させるステップと、
   を含むことを特徴とする請求項５または６に記載の取引制御方法。
8. 前記実行途中の手順と前記取引データとを外部媒体に出力するステップと、
   前記外部媒体に出力された前記実行途中の手順と前記取引データを読み込んで、前記取引を続行させるステップと、
   を含むことを特徴とする請求項７に記載の取引制御方法。

Images