デバイス管理システム及びその制御方法
【課題】現金入出金機や通帳プリンタ等を共同利用することで、コストを抑える要求がある。また、金融機関取引の特殊な事情として、一取引に対応して複数のデバイス装置による複数の処理が複合している場合がある。これらを比較的それぞれ近くにまとまっている複数のデバイス装置で処理できる改善が求められている。
【解決手段】複数のデバイスを用いる取引処理の要求を受信する通信部と、通信部で受信した取引処理の要求に対応する複数のデバイスがそれぞれ使用可か判断する制御部とを有するデバイス管理システム。
【解決手段】複数のデバイスを用いる取引処理の要求を受信する通信部と、通信部で受信した取引処理の要求に対応する複数のデバイスがそれぞれ使用可か判断する制御部とを有するデバイス管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
技術分野は、複数の端末装置から複数種・複数台のデバイス装置を管理する技術に関し、特に金融デバイスの管理システムに関する。
【背景技術】
【０００２】
金融営業店システムとは、金融機関の営業店でテラー等によって利用され、勘定取引等を実行するシステムである（特許文献１参照）。
【０００３】
近年、金融営業店システムの分野では、テラーを顧客との相談業務に多く割り当てる等、或る種の業務に特化する特化型店舗等のような店舗形態の個別化・多様化への対応が求められている。それに対し、比較的高価な金融機関向けデバイス装置（現金入出金機や通帳プリンタ等）を共同利用することで、コストを抑えつつそのような要求に応える動きがある。
【０００４】
また、特許文献２には、一つの端末から要求された複数の通帳発行装置に対する複数の発行待ちキューを管理する技術が開示されている。
【０００５】
【特許文献１】特開平５−２０４５８５号公報
【特許文献２】特開平３−２４６６５３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
特許文献２は、複数種のデバイスを管理することを考慮していない。また、複数の取引端末から複数のデバイスへ取引要求がされることを考慮していない。
【０００７】
このため、金融営業店システムにおいて、金融向けデバイスを共同利用しようとした場合、例えば以下のような課題がある。
【０００８】
すなわち、複数種・複数台のデバイス装置を共同で利用するシステムにおいては、どのオペレータの処理により、どのデバイス装置から、どの媒体に出力するかを特定する改善が求められる。なぜなら、例えば、あるオペレータによる出金処理を別のオペレータが受け取ってしまったり、ある通帳に記帳すべき内容を別の通帳に記帳してしまったりといったミスを防ぐためである。
【０００９】
また、金融機関での取引の特殊な事情として、一取引に対応して通帳プリンタによる通帳印字と現金機による現金出金とのように、複数のデバイス装置による複数の処理が複合している場合がある。これらを比較的それぞれ近くにまとまっている複数の金融デバイスでまとめて処理する改善が求められる。なぜなら、それぞれ場所の離れたデバイスで出力されてしまうと、その分、テラーの立ち歩きが多くなり過ぎ業務効率を著しく下げてしまうためである。
【００１０】
また、一取引に複数の処理が複合している場合、その処理順序や処理実行を管理する改善が求められる。なぜなら、例えば、大量の取引内容を通帳に記帳する際に順番を間違えてしまったり、入金したけれど通帳が発行されなかったりしては不完全な取引となってしまうためである。
【００１１】
また、端末からの処理要求に対し、金融デバイスがその処理を実行可否／予定時間等を使用状況や障害状況等により予めチェックする改善が求められる。特許文献２のように、端末からの処理要求を特定のデバイス装置のキューに追加する方式では、そのデバイス装置が混雑していた等の理由で処理が遅れた場合に、端末から処理要求をキャンセルして別の端末に要求しなおす等の必要があり、処理時間の遅延を招きかねないためである。
【課題を解決するための手段】
【００１２】
上記求められている改善のいくつかは例えば、以下の手段によって達成される。
【００１３】
複数のデバイスを用いる取引処理の要求を受信する通信部と、通信部で受信した取引処理の要求に対応する複数のデバイスがそれぞれ使用可か判断する制御部とを有するデバイス管理システム。
【００１４】
複数のデバイスと接続するデバイス管理システムで実行する制御方法であって、オペレータの識別情報の入力を受けるステップと、入力したオペレータの識別情報を送信して、当該識別情報に対応する取引処理の要求を受信するステップと、接続しているデバイスのうち、受信した取引処理に対応するデバイスが待機中かを順次に判断するステップと、待機中でないと判断されたデバイスがあるとき、入力した識別情報に対応する取引処理を実行できないことを出力するステップとを有する。
【００１５】
複数のデバイスの状況を管理するデバイス管理システムで実行する制御方法であって、複数のデバイスを用いる取引処理の要求を受信するステップと、所定のグループに属するデバイスについて、受信した取引処理に対応するデバイス種が使用不可かを順次に判断するステップと、使用不可と判断されたデバイス種があるとき、別のグループに属するデバイスについて、受信した取引処理に対応するデバイス種が使用不可かを順次に判断するステップとを有する。
【００１６】
その他、本願が開示する課題、及びその解決方法は、発明を実施するための形態の欄、及び図面により明らかにされる。
【発明の効果】
【００１７】
例えば、デバイスの共用を可能としつつオペレータの立ち歩きの負荷を軽減することができる。また例えば、オペレータによる通帳等の媒体の受取ミスを防止できる。
【発明を実施するための最良の形態】
【００１８】
図１は、金融機関の営業店の窓口でテラー等のオペレータが操作する取引端末３００と、センタに設置され、各営業店の金融デバイスを管理するデバイス管理サーバ４００と、営業店に設置され、接続された複数の金融デバイスを管理するデバイス管理端末と、勘定系取引等を処理するホストを含むシステムの構成例を示すブロック図である。ホストは既に設置されていることも多いため、これとは別にデバイスを用いる取引を管理するデバイス管理サーバを用意し、個々デバイスの制御の効率を考慮してデバイス管理装置を営業店に設置した例としている。デバイス装置管理システムは、複数種・複数台のデバイス装置を共有して使用するシステムであり、取引端末と、デバイス管理サーバと、デバイス管理端末の少なくとも一つを含むものとする。
【００１９】
取引端末３００は、半導体回路等でプログラムによりデータ処理等を実行するＣＰＵ３１０、情報を記憶するメモリ３２０、勘定系取引を実行する勘定系プログラム３３２やブラウザ等を記憶するハードディスク３３０、取引内容を表示する液晶等のディスプレイ３５０、オペレータからの入力を受け付けるキーボード等の入力部３６０、ホスト１００との通信を行うインタフェース等の通信部３４０を有する端末装置である。勘定系プログラム３３２を取引端末３００に置かず、デバイス管理サーバ２００等のサーバに置いてブラウザを通じて情報の入出力をする形態でも良い。
【００２０】
ホスト１００は、ＣＰＵ１１０、メモリ１２０、取引端末による取引を集中管理するホストプログラム１３２等を記憶するハードディスク１３０、取引端末３００やデバイス管理サーバ２００との通信を行うインタフェース等の通信部１４０を有するサーバ装置である。
【００２１】
デバイス管理サーバ２００は、ＣＰＵ２１０、メモリ２２０、デバイス装置による取引処理実行の要求を格納するデバイス取引ＤＢ２３４とそれを操作するＤＢプログラム２３２とホスト１００からの電文を解析する電文解析部（プログラム）２３３とを記憶するハードディスク２３０、ホスト１００やデバイス管理端末４００との通信を行うインタフェース等の通信部２４０を有するサーバ装置である。
【００２２】
デバイス管理端末４００は、複数種のデバイス４７０や４８０と有線／無線回線を介して接続し、ＣＰＵ４１０、メモリ４２０、接続されたデバイスの動作状況を格納するデバイス構成情報ＤＢ４３３とデバイスを制御するデバイス制御プログラム４３２を記憶するハードディスク４３０、デバイス処理内容を表示するディスプレイ４５０、オペレータからタッチパネル等で入力を受ける入力部４６０、デバイス管理サーバ２００との通信を行う通信部４４０を有する端末装置である。
【００２３】
ＣＰＵ１１０、ＣＰＵ２１０、ＣＰＵ４１０のいずれかを含むものとして制御部ともいう。メモリ１２０、ハードディスク１３０、メモリ２２０、ハードディスク２３０、メモリ４２０、ハードディスク４３０のいずれかを含むものとして記憶部ともいう。
【００２４】
図４は、デバイス管理サーバ２００のデバイス取引ＤＢ２３４のデータテーブル（取引リスト）の例を示す。取引通番項目６００は、取引端末３００から処理要求された取引の通番を示し、若い番号ほど先に申し込まれたことを示す。取引通番が同じ取引処理のグループを特に取引処理グループとも言う。処理が完了すると当該通番が削除され、その通番より後の通番が繰り上がる（例：３番→２番）ようにしてもよい。処理順序項目６１０は、同じ取引通番を持つ処理の順序を示す。例えば、取引通番‘４’の「通帳有り出金 入出金装置」と「通帳有り出金 通帳プリンタ」とは処理順序の番号が小さい前者を先に実行する。取引種別項目６２０は、取引の種別を示し、例えば、通帳に印字する「記帳」、現金を繰り出す「出金」、現金を繰り出してその結果を通帳に印字する「通帳有り出金」、新たな口座を開設する「新規口座開設」がある。オペレータ項目６３０は、処理を実行するオペレータの識別情報（ＩＤ）又はオペレータが操作している端末のＩＤを示す。口座番号項目６４０は、取引の対象となる口座番号を示す。顧客番号（ＣＩＦ）であっても良く、取引対象番号とも総称する。デバイス項目６５０は、処理を実行するデバイス名を示し、例えば、通帳を搬送して印字し頁捲りを実行する「通帳プリンタ」、現金を繰り出す・取り込む「入出金装置」、カードに磁気データやエンボス印字をして発行する「カード発行機」がある。
【００２５】
図５は、デバイス管理端末４００のデバイス構成情報ＤＢ４３３のデータテーブル例である。デバイス項目６６０は、デバイス管理端末４００が管理するデバイス装置を示し、デバイスの種類（デバイス種）や機番を含む。各デバイスは、複数のデバイス管理端末４００毎にグループ化されて属している。状態項目６７０は、デバイス装置の状態を示し、例えば、処理可能を示す「待機中」、装置障害により処理不能（不可）を示す「障害」がある。
【００２６】
図２は、取引端末３００、デバイス管理サーバ２００、ホスト１００、デバイス管理端末４００が実行する処理手順の例を示すフローチャートである。
【００２７】
取引端末３００は、オペレータから入力部３６０により入力された情報を用いてオペレータの認証を行い（ステップ５００）、勘定系プログラム３３２を起動して取引を開始する（ステップ５０２）。オペレータにより取引情報を入力されたら、通信部３４０は取引情報を示す電文をホスト１００に送信して取引処理を要求する（ステップ５０４）。オペレータ認証は、例えばオペレータカードを読み取り暗証番号を入力させて一致チェックを行う等によって実行する。ここではオペレータID（識別情報）‘１’が認証されたとする。暗証番号の入力を不要とすることや、カードに代えて指紋等の生体情報で認証することや、オペレータ自身ではなくオペレータが操作している取引端末のＩＤを送信することでもよい。
【００２８】
ホスト１００は、取引情報を示す電文を受信すると、ホストプログラム１３２を用いて電文を解析し、取引情報に取引通番を付して、ホスト処理結果と要求された取引処理に用いるデバイス種を決定し、デバイス装置による実行命令を含むホスト電文を作成し、通信部１４０を用いてデバイス管理サーバ２００にホスト電文を送信する（ステップ５０６）。
【００２９】
デバイス管理サーバ２００は、ホスト電文を受信すると、電文解析プログラム２３３を用いて電文を解析し、デバイス装置の必要な処理要求を取り出す。取引通番が同じ処理要求がある場合は、デバイス取引ＤＢに格納されている取引順序を参照して取引順序を付加し、ＤＢプログラム２３２を用いてデバイス取引ＤＢ２３４に格納する（ステップ５０８）。
【００３０】
取引情報を入力したオペレータは、デバイス管理端末４００へ移動する。デバイス管理端末４００のＣＰＵ４１０は、オペレータから入力部４６０により入力された情報を用いてオペレータの認証を行い（ステップ５１０）、通信部４４０を用いてオペレータ情報をデバイス管理サーバ２００に送信する。ここでもオペレータID‘１’が認証されたとする。
【００３１】
デバイス管理サーバ２００は、デバイス取引ＤＢ２３４からオペレータ項６３０をキーとして当該オペレータの処理を検索して当該オペレータについてのオペレータ対応取引リスト６０００を作成する。例えば図６は、オペレータID‘１’に対応するオペレータ対応取引リスト６０００の例を示す。各項目は、図４で説明した取引リストと同様である。作成した取引リストを通信部２４０によってデバイス管理端末４００に送信する（ステップ５１２）。このとき作成する取引リストの実行可否項目７１７の初期値は不可、状態項目７１８の初期値は未済であるとする。このとき、オペレータＩＤに対応する取引処理のうち、最も数の小さい取引通番に対応する取引処理だけを送信するようにしても良い。
【００３２】
デバイス管理端末４００のＣＰＵ４１０は、ステップ５１０で認証したオペレータＩＤに対応する処理を含む取引リストを受信したかどうか判断する（ステップ５１４）。デバイス管理サーバ２００から受信した取引リストにステップ５１０で認証したオペレータIDに対応する処理が存在するかどうかチェックすることでも良い。該当する取引処理がない場合はディスプレイ４５０に該当する取引処理がないことを表示して終了する（ステップ５１６）。
【００３３】
該当する取引処理がある場合は、図５のデバイス構成情報ＤＢ４３４から状態項目６７０を取得する（ステップ５１８）。取引処理に用いるデバイス種に対応するデバイス項目６６０の状態項目６７０が「待機中」であれば（ステップ５２０）、オペレータ対応取引リスト６０００において、当該デバイス種に対応する実行可否項目７１７を実行可能に変更する（ステップ５２２）。取引処理に用いるデバイス種に対応する状態項目６７０が障害や処理中等使用不可の状態であれば（ステップ５２０）、オペレータ対応取引リスト６０００において、当該デバイス種に対応する実行可否項目７１７を実行不可のままとする（ステップ５２４）。オペレータ対応取引リスト６０００についてステップ５２２によって更新されたものを、デバイス状態反映取引リスト７０００と呼ぶ。例えば図７は、図６のオペレータ対応取引リスト６０００を図５のデバイス構成情報ＤＢ４３３によってチェックした結果を示す。ステップ５２０では「待機中」であるか否かを判断するとしているが、可／不可を判断する等してもよい。
【００３４】
図３は、図２の処理に引き続くデバイス管理端末４００が実行する処理手順の例を示すフローチャートである。デバイス管理端末４００のＣＰＵ４１０は、デバイス状態反映取引リスト７０００の実行可否項目７２７が実行不可となっている取引処理を検索し（ステップ５３０）、その取引通番項目７２１と同じ取引通番の取引処理の実行可否項目７２７を実行不可とする（ステップ５３２）。例えば、図７のデバイス状態反映取引リスト７０００においては、取引通番‘５’処理順序‘３’のカード発行機による処理が実行不可であるため、同じく取引通番が５である入出金装置及び通帳プリンタによる処理を実行不可とする。デバイス状態反映取引リスト７０００について、ステップ５３２によって更新されたものを通番チェック反映取引リスト８０００と呼ぶ。例えば図８は、図７のデバイス状態反映取引リスト７０００を上記のようにチェックした結果を示す。
【００３５】
ステップ５１２からステップ５３２により実行可能な処理を検索した結果、実行可能な処理がなければ、ディスプレイ４５０に実行不可である処理の件数や必要なデバイスを表示して終了する（ステップ５３６）。図９は、画面表示例を示し、実行不可の取引処理を網掛けで表示している。実行可能な処理があれば、ディスプレイ４５０に実行可能な処理を表示し、オペレータに実行する取引処理を選択させる（ステップ５３８）。このように実行不可の取引も区別して表示することにより、処理を実行するだけでなく実行不可の処理をオペレータに認識させることができる。
【００３６】
オペレータにより処理が選択されると、取引通番項目７４１が同じ処理のうち、処理順序項目７４２が‘１’である処理を実行する（ステップ５４０）。通帳等の媒体を伴う処理の場合は、媒体が不正な媒体でないかチェックし（ステップ５４２）、ＯＫならば処理を継続し、正常終了した場合は該当処理の状態項目７４８を完了とする（ステップ５５２）。媒体が不正な場合はリトライを促し（ステップ５４４）、リトライしない場合は、媒体不正のエラーをディスプレイ４５０に表示し（ステップ５４６）、オペレータによりリカバリ処理を行った後（ステップ５５０）、該当処理の状態７４８を完了とする（ステップ５５２）。処理が正常終了しなかった場合も、オペレータによりリカバリ処理を行った後（ステップ５５０）、該当処理の状態項目７４８を完了とする（ステップ５５２）。取引通番項目７４１が同じ処理で状態項目７４８が未済の処理がないかチェックし（ステップ５５４）、未済の処理があれば、処理順序に従いすべての処理を同様に実行する。例えば、図９の取引通番‘４’処理順序‘１’の処理を実行した結果の取引リストは図１０となり、同じく取引通番‘４’の処理順序‘２’の処理の状態項目７５８が未済であるため、その処理を実行する。これにより、複数の処理を伴う取引において処理の欠落を防止する（トランザクションを保証する）。
【００３７】
一つの取引に伴う処理が全て終了すると、デバイス管理端末４００のＣＰＵ４１０は、通信部４４０を用いて完了した取引情報をデバイス管理サーバ２００に通知する。デバイス管理サーバ２００は完了した処理をデバイス構成情報ＤＢから削除して（又は済として）取引を完了する（ステップ５５６）。
【００３８】
これまで金融機関における一般的な取引に基づき、ホスト１００を経由してデバイス管理サーバ２００にデバイス処理要求を送信するシステムについて説明したが、ホスト１００を経由せず、取引端末３００から直接デバイス管理サーバ２００へデバイス処理要求を送信することも可能である。この場合取引通番はデバイス管理サーバ２００が付与する。
【００３９】
また、以上では、デバイス構成情報ＤＢ４３３を各デバイス管理端末４００に保持するシステムについて説明したが、全てのデバイス管理端末のデバイス構成情報をデバイス管理サーバ２００に保持することでデバイス管理端末の集中管理も可能であり、デバイス管理サーバ２００の機能をホスト１００とデバイス管理端末４００で分担することも可能であるというように、機能の割振変更や取捨選択は適宜適用して実施できる。
【００４０】
また、ステップ５１０でオペレータ認証を実行した後に、そのオペレータの担当取引を当該デバイス管理端末で実行できるかをステップ５１４からステップ５３４で判断したが、取引端末３００からの取引要求がデバイス管理サーバ２００に伝達されたとき、ステップ５０８において、所定のデバイス管理端末４００（に属するデバイス）で取引処理を実行できるかを判断するようにしても良い。この場合、取引端末３００に処理を実行する又は処理を実行可能なデバイス管理端末を通知する。これによりオペレータがデバイス管理端末４００まで行った後にステップ５３６等で取引不可とされてしまうことを防止できる。所定のデバイス管理端末４００で取引処理を実行できないと判断したときには、別のデバイス管理端末（グループ）のデバイスについて調べる。所定のデバイス管理端末については、取引端末３００の配置やオペレータ毎に予め優先順位をつけて定めておいても良いし、取引端末３００からの取引要求とともに処理を希望するデバイス管理端末４００の番号等を送信するようにしても良い。この場合にも、デバイス管理端末４００でオペレータ認証を実施した後に処理を実行するようにすることで、異なるオペレータが通帳等を誤って取得してしまうことを防ぐこともできる。
【００４１】
本実施例は、以下の形態も含む。
（１）取引を実行する取引端末と、種々のデバイスに対する処理要求を格納するデバイス取引ＤＢを備え、取引端末からのデバイス処理要求を管理するデバイス管理サーバと、接続されたデバイスの種類と状態を格納するデバイス構成情報ＤＢを備え、複数種のデバイスを接続するデバイス管理端末とを有するデバイス装置共有システム。
（２）取引を集中制御するホストと、デバイス管理サーバに、取引端末から要求された取引を示すホスト電文を解析してデバイス取引ＤＢに格納する電文解析部を備えることを特徴とするデバイス装置共有システム。
（３）取引端末からのデバイス処理要求をデバイス管理サーバのデバイス取引ＤＢに格納し、デバイス管理端末のデバイス構成情報と認証したオペレータ情報をもとにデバイス取引ＤＢから実行可能な処理を検索して一覧表示し、一覧表示された処理から選択された処理を実行することを特徴とするデバイス装置共有方式。
（４）取引端末からのデバイス処理要求に取引通番と処理順序を付加してデバイス管理サーバのデバイス取引ＤＢに格納し、デバイス管理端末のデバイス構成情報と認証したオペレータ情報をもとにデバイス取引ＤＢから実行可能な処理を検索して一覧表示し、一覧表示された処理から選択された処理を同一通番の処理は処理順序に従って実行することを特徴とするデバイス装置共有方式。
（５）電文解析部で取引端末から要求された取引を示すホスト電文を解析してデバイス取引ＤＢに格納し、デバイス管理端末のデバイス構成情報と認証したオペレータ情報をもとにデバイス取引ＤＢから実行可能な処理を検索して一覧表示し、一覧表示された処理から選択された処理を実行することを特徴とするデバイス装置共有方式。
（６）複数種・複数台のデバイス装置を共有するシステムにおいて、どのオペレータの処理により、どのデバイス装置から、どの媒体に出力するかを特定し、取引に対するデバイス処理の順序やトランザクションを保証することができる。これにより、複数のデバイス装置のうち任意のデバイス装置で処理を実行し、かつオペレーションのミスを防止することができる。よって、店舗カウンター内にデバイス装置を設置し、カウンター外の離れた取引端末で取引を実行する等、システム構成が利用形態に応じて変更されるような状況に柔軟に対応し、また高価なデバイスの導入コストを低減できる。
【００４２】
以上、一実施形態を具体的に説明したが、この具体例に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
【図面の簡単な説明】
【００４３】
【図１】システム構成を示すブロック図の例。
【図２】フローチャートの例（１）。
【図３】フローチャートの例（２）。
【図４】デバイス取引ＤＢのデータテーブル（取引リスト）の例。
【図５】デバイス構成情報ＤＢのデータテーブルの例。
【図６】図４のデータテーブルに対し、ステップ５１２としてオペレータ‘１’で検索を実行した結果の取引リスト（オペレータ対応取引リスト）の例。
【図７】図６の取引リストに対し、ステップ５１８から５２８により図５のデータテーブルでチェックした結果の取引リスト（デバイス状態反映取引リスト）の例。
【図８】図７の取引リストに対し、ステップ５３０を実行した結果の取引リスト（通番チェック反映取引リスト）の例。
【図９】図８の取引リストに対し、ステップ５３６としてディスプレイ４５０に表示した画面例。
【図１０】図９の画面で取引通番４の処理を選択し、処理順序‘１’の処理を実行した後の取引リストの例。
【符号の説明】
【００４４】
１００ ホスト
２００ デバイス管理サーバ
２３４ デバイス取引ＤＢ
３００ 取引端末
４００ デバイス管理端末
４３３ デバイス構成情報ＤＢ
【技術分野】
【０００１】
技術分野は、複数の端末装置から複数種・複数台のデバイス装置を管理する技術に関し、特に金融デバイスの管理システムに関する。
【背景技術】
【０００２】
金融営業店システムとは、金融機関の営業店でテラー等によって利用され、勘定取引等を実行するシステムである（特許文献１参照）。
【０００３】
近年、金融営業店システムの分野では、テラーを顧客との相談業務に多く割り当てる等、或る種の業務に特化する特化型店舗等のような店舗形態の個別化・多様化への対応が求められている。それに対し、比較的高価な金融機関向けデバイス装置（現金入出金機や通帳プリンタ等）を共同利用することで、コストを抑えつつそのような要求に応える動きがある。
【０００４】
また、特許文献２には、一つの端末から要求された複数の通帳発行装置に対する複数の発行待ちキューを管理する技術が開示されている。
【０００５】
【特許文献１】特開平５−２０４５８５号公報
【特許文献２】特開平３−２４６６５３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
特許文献２は、複数種のデバイスを管理することを考慮していない。また、複数の取引端末から複数のデバイスへ取引要求がされることを考慮していない。
【０００７】
このため、金融営業店システムにおいて、金融向けデバイスを共同利用しようとした場合、例えば以下のような課題がある。
【０００８】
すなわち、複数種・複数台のデバイス装置を共同で利用するシステムにおいては、どのオペレータの処理により、どのデバイス装置から、どの媒体に出力するかを特定する改善が求められる。なぜなら、例えば、あるオペレータによる出金処理を別のオペレータが受け取ってしまったり、ある通帳に記帳すべき内容を別の通帳に記帳してしまったりといったミスを防ぐためである。
【０００９】
また、金融機関での取引の特殊な事情として、一取引に対応して通帳プリンタによる通帳印字と現金機による現金出金とのように、複数のデバイス装置による複数の処理が複合している場合がある。これらを比較的それぞれ近くにまとまっている複数の金融デバイスでまとめて処理する改善が求められる。なぜなら、それぞれ場所の離れたデバイスで出力されてしまうと、その分、テラーの立ち歩きが多くなり過ぎ業務効率を著しく下げてしまうためである。
【００１０】
また、一取引に複数の処理が複合している場合、その処理順序や処理実行を管理する改善が求められる。なぜなら、例えば、大量の取引内容を通帳に記帳する際に順番を間違えてしまったり、入金したけれど通帳が発行されなかったりしては不完全な取引となってしまうためである。
【００１１】
また、端末からの処理要求に対し、金融デバイスがその処理を実行可否／予定時間等を使用状況や障害状況等により予めチェックする改善が求められる。特許文献２のように、端末からの処理要求を特定のデバイス装置のキューに追加する方式では、そのデバイス装置が混雑していた等の理由で処理が遅れた場合に、端末から処理要求をキャンセルして別の端末に要求しなおす等の必要があり、処理時間の遅延を招きかねないためである。
【課題を解決するための手段】
【００１２】
上記求められている改善のいくつかは例えば、以下の手段によって達成される。
【００１３】
複数のデバイスを用いる取引処理の要求を受信する通信部と、通信部で受信した取引処理の要求に対応する複数のデバイスがそれぞれ使用可か判断する制御部とを有するデバイス管理システム。
【００１４】
複数のデバイスと接続するデバイス管理システムで実行する制御方法であって、オペレータの識別情報の入力を受けるステップと、入力したオペレータの識別情報を送信して、当該識別情報に対応する取引処理の要求を受信するステップと、接続しているデバイスのうち、受信した取引処理に対応するデバイスが待機中かを順次に判断するステップと、待機中でないと判断されたデバイスがあるとき、入力した識別情報に対応する取引処理を実行できないことを出力するステップとを有する。
【００１５】
複数のデバイスの状況を管理するデバイス管理システムで実行する制御方法であって、複数のデバイスを用いる取引処理の要求を受信するステップと、所定のグループに属するデバイスについて、受信した取引処理に対応するデバイス種が使用不可かを順次に判断するステップと、使用不可と判断されたデバイス種があるとき、別のグループに属するデバイスについて、受信した取引処理に対応するデバイス種が使用不可かを順次に判断するステップとを有する。
【００１６】
その他、本願が開示する課題、及びその解決方法は、発明を実施するための形態の欄、及び図面により明らかにされる。
【発明の効果】
【００１７】
例えば、デバイスの共用を可能としつつオペレータの立ち歩きの負荷を軽減することができる。また例えば、オペレータによる通帳等の媒体の受取ミスを防止できる。
【発明を実施するための最良の形態】
【００１８】
図１は、金融機関の営業店の窓口でテラー等のオペレータが操作する取引端末３００と、センタに設置され、各営業店の金融デバイスを管理するデバイス管理サーバ４００と、営業店に設置され、接続された複数の金融デバイスを管理するデバイス管理端末と、勘定系取引等を処理するホストを含むシステムの構成例を示すブロック図である。ホストは既に設置されていることも多いため、これとは別にデバイスを用いる取引を管理するデバイス管理サーバを用意し、個々デバイスの制御の効率を考慮してデバイス管理装置を営業店に設置した例としている。デバイス装置管理システムは、複数種・複数台のデバイス装置を共有して使用するシステムであり、取引端末と、デバイス管理サーバと、デバイス管理端末の少なくとも一つを含むものとする。
【００１９】
取引端末３００は、半導体回路等でプログラムによりデータ処理等を実行するＣＰＵ３１０、情報を記憶するメモリ３２０、勘定系取引を実行する勘定系プログラム３３２やブラウザ等を記憶するハードディスク３３０、取引内容を表示する液晶等のディスプレイ３５０、オペレータからの入力を受け付けるキーボード等の入力部３６０、ホスト１００との通信を行うインタフェース等の通信部３４０を有する端末装置である。勘定系プログラム３３２を取引端末３００に置かず、デバイス管理サーバ２００等のサーバに置いてブラウザを通じて情報の入出力をする形態でも良い。
【００２０】
ホスト１００は、ＣＰＵ１１０、メモリ１２０、取引端末による取引を集中管理するホストプログラム１３２等を記憶するハードディスク１３０、取引端末３００やデバイス管理サーバ２００との通信を行うインタフェース等の通信部１４０を有するサーバ装置である。
【００２１】
デバイス管理サーバ２００は、ＣＰＵ２１０、メモリ２２０、デバイス装置による取引処理実行の要求を格納するデバイス取引ＤＢ２３４とそれを操作するＤＢプログラム２３２とホスト１００からの電文を解析する電文解析部（プログラム）２３３とを記憶するハードディスク２３０、ホスト１００やデバイス管理端末４００との通信を行うインタフェース等の通信部２４０を有するサーバ装置である。
【００２２】
デバイス管理端末４００は、複数種のデバイス４７０や４８０と有線／無線回線を介して接続し、ＣＰＵ４１０、メモリ４２０、接続されたデバイスの動作状況を格納するデバイス構成情報ＤＢ４３３とデバイスを制御するデバイス制御プログラム４３２を記憶するハードディスク４３０、デバイス処理内容を表示するディスプレイ４５０、オペレータからタッチパネル等で入力を受ける入力部４６０、デバイス管理サーバ２００との通信を行う通信部４４０を有する端末装置である。
【００２３】
ＣＰＵ１１０、ＣＰＵ２１０、ＣＰＵ４１０のいずれかを含むものとして制御部ともいう。メモリ１２０、ハードディスク１３０、メモリ２２０、ハードディスク２３０、メモリ４２０、ハードディスク４３０のいずれかを含むものとして記憶部ともいう。
【００２４】
図４は、デバイス管理サーバ２００のデバイス取引ＤＢ２３４のデータテーブル（取引リスト）の例を示す。取引通番項目６００は、取引端末３００から処理要求された取引の通番を示し、若い番号ほど先に申し込まれたことを示す。取引通番が同じ取引処理のグループを特に取引処理グループとも言う。処理が完了すると当該通番が削除され、その通番より後の通番が繰り上がる（例：３番→２番）ようにしてもよい。処理順序項目６１０は、同じ取引通番を持つ処理の順序を示す。例えば、取引通番‘４’の「通帳有り出金 入出金装置」と「通帳有り出金 通帳プリンタ」とは処理順序の番号が小さい前者を先に実行する。取引種別項目６２０は、取引の種別を示し、例えば、通帳に印字する「記帳」、現金を繰り出す「出金」、現金を繰り出してその結果を通帳に印字する「通帳有り出金」、新たな口座を開設する「新規口座開設」がある。オペレータ項目６３０は、処理を実行するオペレータの識別情報（ＩＤ）又はオペレータが操作している端末のＩＤを示す。口座番号項目６４０は、取引の対象となる口座番号を示す。顧客番号（ＣＩＦ）であっても良く、取引対象番号とも総称する。デバイス項目６５０は、処理を実行するデバイス名を示し、例えば、通帳を搬送して印字し頁捲りを実行する「通帳プリンタ」、現金を繰り出す・取り込む「入出金装置」、カードに磁気データやエンボス印字をして発行する「カード発行機」がある。
【００２５】
図５は、デバイス管理端末４００のデバイス構成情報ＤＢ４３３のデータテーブル例である。デバイス項目６６０は、デバイス管理端末４００が管理するデバイス装置を示し、デバイスの種類（デバイス種）や機番を含む。各デバイスは、複数のデバイス管理端末４００毎にグループ化されて属している。状態項目６７０は、デバイス装置の状態を示し、例えば、処理可能を示す「待機中」、装置障害により処理不能（不可）を示す「障害」がある。
【００２６】
図２は、取引端末３００、デバイス管理サーバ２００、ホスト１００、デバイス管理端末４００が実行する処理手順の例を示すフローチャートである。
【００２７】
取引端末３００は、オペレータから入力部３６０により入力された情報を用いてオペレータの認証を行い（ステップ５００）、勘定系プログラム３３２を起動して取引を開始する（ステップ５０２）。オペレータにより取引情報を入力されたら、通信部３４０は取引情報を示す電文をホスト１００に送信して取引処理を要求する（ステップ５０４）。オペレータ認証は、例えばオペレータカードを読み取り暗証番号を入力させて一致チェックを行う等によって実行する。ここではオペレータID（識別情報）‘１’が認証されたとする。暗証番号の入力を不要とすることや、カードに代えて指紋等の生体情報で認証することや、オペレータ自身ではなくオペレータが操作している取引端末のＩＤを送信することでもよい。
【００２８】
ホスト１００は、取引情報を示す電文を受信すると、ホストプログラム１３２を用いて電文を解析し、取引情報に取引通番を付して、ホスト処理結果と要求された取引処理に用いるデバイス種を決定し、デバイス装置による実行命令を含むホスト電文を作成し、通信部１４０を用いてデバイス管理サーバ２００にホスト電文を送信する（ステップ５０６）。
【００２９】
デバイス管理サーバ２００は、ホスト電文を受信すると、電文解析プログラム２３３を用いて電文を解析し、デバイス装置の必要な処理要求を取り出す。取引通番が同じ処理要求がある場合は、デバイス取引ＤＢに格納されている取引順序を参照して取引順序を付加し、ＤＢプログラム２３２を用いてデバイス取引ＤＢ２３４に格納する（ステップ５０８）。
【００３０】
取引情報を入力したオペレータは、デバイス管理端末４００へ移動する。デバイス管理端末４００のＣＰＵ４１０は、オペレータから入力部４６０により入力された情報を用いてオペレータの認証を行い（ステップ５１０）、通信部４４０を用いてオペレータ情報をデバイス管理サーバ２００に送信する。ここでもオペレータID‘１’が認証されたとする。
【００３１】
デバイス管理サーバ２００は、デバイス取引ＤＢ２３４からオペレータ項６３０をキーとして当該オペレータの処理を検索して当該オペレータについてのオペレータ対応取引リスト６０００を作成する。例えば図６は、オペレータID‘１’に対応するオペレータ対応取引リスト６０００の例を示す。各項目は、図４で説明した取引リストと同様である。作成した取引リストを通信部２４０によってデバイス管理端末４００に送信する（ステップ５１２）。このとき作成する取引リストの実行可否項目７１７の初期値は不可、状態項目７１８の初期値は未済であるとする。このとき、オペレータＩＤに対応する取引処理のうち、最も数の小さい取引通番に対応する取引処理だけを送信するようにしても良い。
【００３２】
デバイス管理端末４００のＣＰＵ４１０は、ステップ５１０で認証したオペレータＩＤに対応する処理を含む取引リストを受信したかどうか判断する（ステップ５１４）。デバイス管理サーバ２００から受信した取引リストにステップ５１０で認証したオペレータIDに対応する処理が存在するかどうかチェックすることでも良い。該当する取引処理がない場合はディスプレイ４５０に該当する取引処理がないことを表示して終了する（ステップ５１６）。
【００３３】
該当する取引処理がある場合は、図５のデバイス構成情報ＤＢ４３４から状態項目６７０を取得する（ステップ５１８）。取引処理に用いるデバイス種に対応するデバイス項目６６０の状態項目６７０が「待機中」であれば（ステップ５２０）、オペレータ対応取引リスト６０００において、当該デバイス種に対応する実行可否項目７１７を実行可能に変更する（ステップ５２２）。取引処理に用いるデバイス種に対応する状態項目６７０が障害や処理中等使用不可の状態であれば（ステップ５２０）、オペレータ対応取引リスト６０００において、当該デバイス種に対応する実行可否項目７１７を実行不可のままとする（ステップ５２４）。オペレータ対応取引リスト６０００についてステップ５２２によって更新されたものを、デバイス状態反映取引リスト７０００と呼ぶ。例えば図７は、図６のオペレータ対応取引リスト６０００を図５のデバイス構成情報ＤＢ４３３によってチェックした結果を示す。ステップ５２０では「待機中」であるか否かを判断するとしているが、可／不可を判断する等してもよい。
【００３４】
図３は、図２の処理に引き続くデバイス管理端末４００が実行する処理手順の例を示すフローチャートである。デバイス管理端末４００のＣＰＵ４１０は、デバイス状態反映取引リスト７０００の実行可否項目７２７が実行不可となっている取引処理を検索し（ステップ５３０）、その取引通番項目７２１と同じ取引通番の取引処理の実行可否項目７２７を実行不可とする（ステップ５３２）。例えば、図７のデバイス状態反映取引リスト７０００においては、取引通番‘５’処理順序‘３’のカード発行機による処理が実行不可であるため、同じく取引通番が５である入出金装置及び通帳プリンタによる処理を実行不可とする。デバイス状態反映取引リスト７０００について、ステップ５３２によって更新されたものを通番チェック反映取引リスト８０００と呼ぶ。例えば図８は、図７のデバイス状態反映取引リスト７０００を上記のようにチェックした結果を示す。
【００３５】
ステップ５１２からステップ５３２により実行可能な処理を検索した結果、実行可能な処理がなければ、ディスプレイ４５０に実行不可である処理の件数や必要なデバイスを表示して終了する（ステップ５３６）。図９は、画面表示例を示し、実行不可の取引処理を網掛けで表示している。実行可能な処理があれば、ディスプレイ４５０に実行可能な処理を表示し、オペレータに実行する取引処理を選択させる（ステップ５３８）。このように実行不可の取引も区別して表示することにより、処理を実行するだけでなく実行不可の処理をオペレータに認識させることができる。
【００３６】
オペレータにより処理が選択されると、取引通番項目７４１が同じ処理のうち、処理順序項目７４２が‘１’である処理を実行する（ステップ５４０）。通帳等の媒体を伴う処理の場合は、媒体が不正な媒体でないかチェックし（ステップ５４２）、ＯＫならば処理を継続し、正常終了した場合は該当処理の状態項目７４８を完了とする（ステップ５５２）。媒体が不正な場合はリトライを促し（ステップ５４４）、リトライしない場合は、媒体不正のエラーをディスプレイ４５０に表示し（ステップ５４６）、オペレータによりリカバリ処理を行った後（ステップ５５０）、該当処理の状態７４８を完了とする（ステップ５５２）。処理が正常終了しなかった場合も、オペレータによりリカバリ処理を行った後（ステップ５５０）、該当処理の状態項目７４８を完了とする（ステップ５５２）。取引通番項目７４１が同じ処理で状態項目７４８が未済の処理がないかチェックし（ステップ５５４）、未済の処理があれば、処理順序に従いすべての処理を同様に実行する。例えば、図９の取引通番‘４’処理順序‘１’の処理を実行した結果の取引リストは図１０となり、同じく取引通番‘４’の処理順序‘２’の処理の状態項目７５８が未済であるため、その処理を実行する。これにより、複数の処理を伴う取引において処理の欠落を防止する（トランザクションを保証する）。
【００３７】
一つの取引に伴う処理が全て終了すると、デバイス管理端末４００のＣＰＵ４１０は、通信部４４０を用いて完了した取引情報をデバイス管理サーバ２００に通知する。デバイス管理サーバ２００は完了した処理をデバイス構成情報ＤＢから削除して（又は済として）取引を完了する（ステップ５５６）。
【００３８】
これまで金融機関における一般的な取引に基づき、ホスト１００を経由してデバイス管理サーバ２００にデバイス処理要求を送信するシステムについて説明したが、ホスト１００を経由せず、取引端末３００から直接デバイス管理サーバ２００へデバイス処理要求を送信することも可能である。この場合取引通番はデバイス管理サーバ２００が付与する。
【００３９】
また、以上では、デバイス構成情報ＤＢ４３３を各デバイス管理端末４００に保持するシステムについて説明したが、全てのデバイス管理端末のデバイス構成情報をデバイス管理サーバ２００に保持することでデバイス管理端末の集中管理も可能であり、デバイス管理サーバ２００の機能をホスト１００とデバイス管理端末４００で分担することも可能であるというように、機能の割振変更や取捨選択は適宜適用して実施できる。
【００４０】
また、ステップ５１０でオペレータ認証を実行した後に、そのオペレータの担当取引を当該デバイス管理端末で実行できるかをステップ５１４からステップ５３４で判断したが、取引端末３００からの取引要求がデバイス管理サーバ２００に伝達されたとき、ステップ５０８において、所定のデバイス管理端末４００（に属するデバイス）で取引処理を実行できるかを判断するようにしても良い。この場合、取引端末３００に処理を実行する又は処理を実行可能なデバイス管理端末を通知する。これによりオペレータがデバイス管理端末４００まで行った後にステップ５３６等で取引不可とされてしまうことを防止できる。所定のデバイス管理端末４００で取引処理を実行できないと判断したときには、別のデバイス管理端末（グループ）のデバイスについて調べる。所定のデバイス管理端末については、取引端末３００の配置やオペレータ毎に予め優先順位をつけて定めておいても良いし、取引端末３００からの取引要求とともに処理を希望するデバイス管理端末４００の番号等を送信するようにしても良い。この場合にも、デバイス管理端末４００でオペレータ認証を実施した後に処理を実行するようにすることで、異なるオペレータが通帳等を誤って取得してしまうことを防ぐこともできる。
【００４１】
本実施例は、以下の形態も含む。
（１）取引を実行する取引端末と、種々のデバイスに対する処理要求を格納するデバイス取引ＤＢを備え、取引端末からのデバイス処理要求を管理するデバイス管理サーバと、接続されたデバイスの種類と状態を格納するデバイス構成情報ＤＢを備え、複数種のデバイスを接続するデバイス管理端末とを有するデバイス装置共有システム。
（２）取引を集中制御するホストと、デバイス管理サーバに、取引端末から要求された取引を示すホスト電文を解析してデバイス取引ＤＢに格納する電文解析部を備えることを特徴とするデバイス装置共有システム。
（３）取引端末からのデバイス処理要求をデバイス管理サーバのデバイス取引ＤＢに格納し、デバイス管理端末のデバイス構成情報と認証したオペレータ情報をもとにデバイス取引ＤＢから実行可能な処理を検索して一覧表示し、一覧表示された処理から選択された処理を実行することを特徴とするデバイス装置共有方式。
（４）取引端末からのデバイス処理要求に取引通番と処理順序を付加してデバイス管理サーバのデバイス取引ＤＢに格納し、デバイス管理端末のデバイス構成情報と認証したオペレータ情報をもとにデバイス取引ＤＢから実行可能な処理を検索して一覧表示し、一覧表示された処理から選択された処理を同一通番の処理は処理順序に従って実行することを特徴とするデバイス装置共有方式。
（５）電文解析部で取引端末から要求された取引を示すホスト電文を解析してデバイス取引ＤＢに格納し、デバイス管理端末のデバイス構成情報と認証したオペレータ情報をもとにデバイス取引ＤＢから実行可能な処理を検索して一覧表示し、一覧表示された処理から選択された処理を実行することを特徴とするデバイス装置共有方式。
（６）複数種・複数台のデバイス装置を共有するシステムにおいて、どのオペレータの処理により、どのデバイス装置から、どの媒体に出力するかを特定し、取引に対するデバイス処理の順序やトランザクションを保証することができる。これにより、複数のデバイス装置のうち任意のデバイス装置で処理を実行し、かつオペレーションのミスを防止することができる。よって、店舗カウンター内にデバイス装置を設置し、カウンター外の離れた取引端末で取引を実行する等、システム構成が利用形態に応じて変更されるような状況に柔軟に対応し、また高価なデバイスの導入コストを低減できる。
【００４２】
以上、一実施形態を具体的に説明したが、この具体例に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
【図面の簡単な説明】
【００４３】
【図１】システム構成を示すブロック図の例。
【図２】フローチャートの例（１）。
【図３】フローチャートの例（２）。
【図４】デバイス取引ＤＢのデータテーブル（取引リスト）の例。
【図５】デバイス構成情報ＤＢのデータテーブルの例。
【図６】図４のデータテーブルに対し、ステップ５１２としてオペレータ‘１’で検索を実行した結果の取引リスト（オペレータ対応取引リスト）の例。
【図７】図６の取引リストに対し、ステップ５１８から５２８により図５のデータテーブルでチェックした結果の取引リスト（デバイス状態反映取引リスト）の例。
【図８】図７の取引リストに対し、ステップ５３０を実行した結果の取引リスト（通番チェック反映取引リスト）の例。
【図９】図８の取引リストに対し、ステップ５３６としてディスプレイ４５０に表示した画面例。
【図１０】図９の画面で取引通番４の処理を選択し、処理順序‘１’の処理を実行した後の取引リストの例。
【符号の説明】
【００４４】
１００ ホスト
２００ デバイス管理サーバ
２３４ デバイス取引ＤＢ
３００ 取引端末
４００ デバイス管理端末
４３３ デバイス構成情報ＤＢ
【特許請求の範囲】
【請求項１】
複数のデバイス種を用いる取引処理の要求を受信する通信部と、
前記通信部で受信した取引処理の要求に対応する複数のデバイスがそれぞれ使用可かを判断する制御部とを有するデバイス管理システム。
【請求項２】
請求項１であって、
前記制御部は、前記複数のデバイスがそれぞれ使用可と判断したとき、所定の順序に従って、当該それぞれのデバイスに処理を実行させるよう制御するデバイス管理システム。
【請求項３】
請求項１であって、
前記複数のデバイスのうちいずれかが使用可と判断しなかったとき、前記取引処理は実行不可であると判断するデバイス管理システム。
【請求項４】
請求項３であって、
前記制御部が前記取引処理は実行不可であることを判断したとき、実行不可であることを画面に表示する表示部をさらに有するデバイス管理システム。
【請求項５】
請求項１であって、
前記複数のデバイスの状態を管理するデバイス構成情報ＤＢを記憶する記憶部を有し、
前記制御部は、前記取引端末から受信した取引要求に対応する複数のデバイス種のそれぞれについて、前記デバイス構成情報ＤＢを調べるデバイス管理システム。
【請求項６】
請求項１であって、
前記制御部は、前記取引処理の要求を、所定のグループに属する複数のデバイスで処理できるか判断し、対応できないと判断したとき、別のグループに属する複数のデバイスで処理できるかを判断するデバイス管理システム。
【請求項７】
請求項６であって、
前記グループは、複数のデバイスに接続するデバイス管理端末毎に区分されているデバイス管理システム。
【請求項８】
請求項１であって、
オペレータの識別情報の入力を受ける入力部を有し、
前記通信部は、前記入力部で受けたオペレータの識別情報を送信して、当該送信に対応する取引処理の要求を受信するデバイス管理システム。
【請求項９】
複数のデバイスと接続するデバイス管理システムで実行する制御方法であって、
オペレータの識別情報の入力を受けるステップと、
入力したオペレータの識別情報を送信して、当該識別情報に対応する取引処理の要求を受信するステップと、
接続しているデバイスのうち、受信した取引処理に対応するデバイスが待機中かを順次に判断するステップと、
待機中でないと判断されたデバイスがあるとき、入力した識別情報に対応する取引処理を実行できないことを出力するステップとを有する。
【請求項１０】
複数のデバイスの状況を管理するデバイス管理システムで実行する制御方法であって、
複数のデバイスを用いる取引処理の要求を受信するステップと、
所定のグループに属するデバイスについて、受信した取引処理に対応するデバイス種が使用不可かを順次に判断するステップと、
使用不可と判断されたデバイス種があるとき、別のグループに属するデバイスについて、受信した取引処理に対応するデバイス種が使用不可かを順次に判断するステップとを有する。
【請求項１】
複数のデバイス種を用いる取引処理の要求を受信する通信部と、
前記通信部で受信した取引処理の要求に対応する複数のデバイスがそれぞれ使用可かを判断する制御部とを有するデバイス管理システム。
【請求項２】
請求項１であって、
前記制御部は、前記複数のデバイスがそれぞれ使用可と判断したとき、所定の順序に従って、当該それぞれのデバイスに処理を実行させるよう制御するデバイス管理システム。
【請求項３】
請求項１であって、
前記複数のデバイスのうちいずれかが使用可と判断しなかったとき、前記取引処理は実行不可であると判断するデバイス管理システム。
【請求項４】
請求項３であって、
前記制御部が前記取引処理は実行不可であることを判断したとき、実行不可であることを画面に表示する表示部をさらに有するデバイス管理システム。
【請求項５】
請求項１であって、
前記複数のデバイスの状態を管理するデバイス構成情報ＤＢを記憶する記憶部を有し、
前記制御部は、前記取引端末から受信した取引要求に対応する複数のデバイス種のそれぞれについて、前記デバイス構成情報ＤＢを調べるデバイス管理システム。
【請求項６】
請求項１であって、
前記制御部は、前記取引処理の要求を、所定のグループに属する複数のデバイスで処理できるか判断し、対応できないと判断したとき、別のグループに属する複数のデバイスで処理できるかを判断するデバイス管理システム。
【請求項７】
請求項６であって、
前記グループは、複数のデバイスに接続するデバイス管理端末毎に区分されているデバイス管理システム。
【請求項８】
請求項１であって、
オペレータの識別情報の入力を受ける入力部を有し、
前記通信部は、前記入力部で受けたオペレータの識別情報を送信して、当該送信に対応する取引処理の要求を受信するデバイス管理システム。
【請求項９】
複数のデバイスと接続するデバイス管理システムで実行する制御方法であって、
オペレータの識別情報の入力を受けるステップと、
入力したオペレータの識別情報を送信して、当該識別情報に対応する取引処理の要求を受信するステップと、
接続しているデバイスのうち、受信した取引処理に対応するデバイスが待機中かを順次に判断するステップと、
待機中でないと判断されたデバイスがあるとき、入力した識別情報に対応する取引処理を実行できないことを出力するステップとを有する。
【請求項１０】
複数のデバイスの状況を管理するデバイス管理システムで実行する制御方法であって、
複数のデバイスを用いる取引処理の要求を受信するステップと、
所定のグループに属するデバイスについて、受信した取引処理に対応するデバイス種が使用不可かを順次に判断するステップと、
使用不可と判断されたデバイス種があるとき、別のグループに属するデバイスについて、受信した取引処理に対応するデバイス種が使用不可かを順次に判断するステップとを有する。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２００６−１２７１７７（Ｐ２００６−１２７１７７Ａ）
【公開日】平成１８年５月１８日（２００６．５．１８）
【国際特許分類】
【出願番号】特願２００４−３１４９９７（Ｐ２００４−３１４９９７）
【出願日】平成１６年１０月２９日（２００４．１０．２９）
【出願人】（５０４３７３０９３）日立オムロンターミナルソリューションズ株式会社 (1,225)
【公開日】平成１８年５月１８日（２００６．５．１８）
【国際特許分類】
【出願日】平成１６年１０月２９日（２００４．１０．２９）
【出願人】（５０４３７３０９３）日立オムロンターミナルソリューションズ株式会社 (1,225)
[ Back to top ]