オペレータ承認条件設定システム
【課題】昇進や移転等により人事が変わり、その都度、オペレータ情報は変わることになる。人事情報が変わるごとに人事情報ＤＢサーバとＡＰ／ＤＢサーバの各データベースを整合させて正しく変えなければならないが、人事側役席端末からと営業店側役席端末からそれぞれ各データベースサーバを独立して操作することになり、それぞれの誤入力や未入力という問題が発生する。
【解決手段】、センタの、各営業店のオペレータの各データベースを保有するＡＰ／ＤＢサーバおよび人事情報ＤＢサーバを互いに連携し、営業店の各窓口端末とＬＡＮ接続した役席端末と、これら端末を上記ＡＰ／ＤＢサーバと接続し、本部の役席端末を上記人事情報ＤＢサーバと接続し、人事情報ＤＢサーバの人事情報データベースの変更とＡＰ／ＤＢサーバの各ＤＢの変更があった場合に互いに比較して変更データに整合するように変更させて登録することを特徴とする。
【解決手段】、センタの、各営業店のオペレータの各データベースを保有するＡＰ／ＤＢサーバおよび人事情報ＤＢサーバを互いに連携し、営業店の各窓口端末とＬＡＮ接続した役席端末と、これら端末を上記ＡＰ／ＤＢサーバと接続し、本部の役席端末を上記人事情報ＤＢサーバと接続し、人事情報ＤＢサーバの人事情報データベースの変更とＡＰ／ＤＢサーバの各ＤＢの変更があった場合に互いに比較して変更データに整合するように変更させて登録することを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、銀行等の金融機関における営業店端末のオペレータのランクに応じたオペレータ承認条件設定システムに関する。
【背景技術】
【０００２】
従来の金融機関窓口のオペレータによる窓口端末（現金処理装置）の処理は、その操作に携わるオペレータには、その地位や身分に応じたランク付けがなされており、そのランク付けは、各営業店の役席が個々に設定しているものであり、そのランクに応じた業務範囲（承認条件設定値）内での処理作業は、役席者の承認を必要としないで行うことができ、その業務範囲外の処理については、処理毎に役席者の承認を必要としている。そして、その承認条件は初期設定時に個々のオペレータ毎にすべての承認条件データを設定している。
【０００３】
そこで、オペレータの苗字やランク等の変更によってその登録情報や承認条件を変更する場合は、図６に示す如く、本部の人事役員端末からセンタにある人事情報を管理するための人事情報データベース（以下ＤＢ）サーバの人事情報ＤＢを変更し、業務アプリケーションプログラム（以下ＡＰ）と各種ＤＢを集中管理する管理サーバとしての機能をもつＡＰ／ＤＢサーバのオペレータ毎承認条件ＤＢの承認条件およびオペレータ情報ＤＢの登録情報を営業店の役席端末がそれぞれ変更している。
【０００４】
また、窓口端末側にて、低いランクのオペレータが処理操作中に承認条件設定値以上の処理で役席者の承認を必要とするときに、承認要求を役席端末に通知する手段と、その役席端末側にて、役席者が承認必要オペレータの操作内容を確認する確認手段と、役席端末側にて役席者が上記承認必要オペレータからの承認要求を許可するとき１回限り有効な暗証番号を発行する暗証番号発行手段とを設けた技術があり、これによって、オペレータの窓口端末と役席端末との間を送信で承認情報を通知する方法がある（例えば、特許文献１参照）。
【特許文献１】特開平１１−２５９７３３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかし、企業においては昇進や移転等により人事が変わるもので、その都度、オペレータ情報は変わることになる。人事情報が変わるごとに人事情報ＤＢサーバとＡＰ／ＤＢサーバの各ＤＢを整合させて正しく変えなければならないが、上述した従来の技術においては、人事側役席端末からと営業店側役席端末からそれぞれ各ＤＢを独立して操作することになり、入力時の違い、それぞれの誤入力や未入力という問題が発生する。
【０００６】
また、オペレータのＩＤカードを発行する作業はホストとの取引であり、ホスト取引成立後に、営業店の役席端末はセンタのＡＰ／ＤＢサーバのオペレータ情報およびオペレータ毎承認条件をそれぞれ整合させて設定しなければならないという問題がある。
本発明は、このような問題を解決することを課題とする。
【課題を解決するための手段】
【０００７】
そこで本発明は、センタの、各営業店のオペレータの各ＤＢを保有するＡＰ／ＤＢサーバおよび人事情報ＤＢサーバを互いに連携し、営業店の各窓口端末とＬＡＮ接続した役席端末と、これら端末を上記ＡＰ／ＤＢサーバと接続し、本部の役席端末を上記人事情報ＤＢサーバと接続し、人事情報ＤＢサーバの人事情報ＤＢの変更とＡＰ／ＤＢサーバの各ＤＢの変更があった場合に互いに比較して変更データに整合するように変更させて登録することを特徴とする。
【０００８】
また、本部の役席端末からホストのオペレータデータにＩＤカード登録操作を行うことにより、オペレータデータにＩＤ番号登録し、登録されたＩＤ番号を、ホストより、センタのＡＰ／ＤＢサーバにファイル転送し、受領したデータについて、自動でＡＰ／ＤＢサーバのＤＢに登録すること特徴とする。
【発明の効果】
【０００９】
このようにした本発明は、ＡＰ／ＤＢサーバと人事情報ＤＢサーバの相互のＤＢ情報が同時に変更されると共に不整合の発生をなくすことができることになる。
また、ホスト取引であるＩＤカード発行操作と連動してＡＰ／ＤＢサーバへの登録を同時に行うことにより、ホストのオペレータデータとＡＰ／ＤＢサーバのオペレータ毎承認条件データとの間に相違の発生がなくなり、円滑な運用を行うことができることになる。
【発明を実施するための最良の形態】
【００１０】
以下、図面を参照して本発明による実施例を説明する。
図１はオペレータ承認システムの概略説明図である。
図において、１は営業店であり、各オペレータが操作する窓口端末２と役席者が操作する役席端末３とがある。
４はセンタであり、上記営業店１および本部人事５とそれぞれ公衆網を介して接続しており、ＡＰ／ＤＢサーバ６と人事情報ＤＢサーバ７を有し、互いに連携している。
【００１１】
ＡＰ／ＤＢサーバ６に、各オペレータのオペレータ情報ＤＢ６１および各オペレータの承認条件ＤＢ６２を保有する。このオペレータ毎承認条件ＤＢ６２が保有する承認条件とは、例えば、図示する如く、各オペレータのＩＤ番号、各オペレータの役職情報、その各オペレータの支払取扱い限度額（その金額を超えると役席承認が必要になる金額。）等を関連付けた情報である。
【００１２】
なお、オペレータ毎承認条件ＤＢ６２は、ＡＰ／ＤＢサーバ６で他のＤＢと共に管理するのではなく、オペレータ情報およびオペレータ毎承認条件の管理機能をもたせたオペレータ管理サーバを別に設けてもよい。
また、ＡＰ／ＤＢサーバ６には、端末で行う業務のための業務ＡＰが格納されている。
また、人事情報ＤＢサーバ７に、各オペレータの人事情報ＤＢ７１を保有する。この人事情報ＤＢ７１が保有する情報とは、例えば、図示する如く、各オペレータのＩＤ番号、行員番号、氏名、ランク情報等である。
【００１３】
８はホストであり、各オペレータのＩＤ番号等のオペレータデータ８１を保有する。
つぎに、窓口端末２と役席端末３の処理システムを図２のブロック図を用いて説明する。
窓口端末２は、ＣＰＵ（セントラル・プロセッシング・ユニット）２０１により制御される。ＣＰＵ２０１は、表示操作部２０２、記憶部２０３、通信制御部２０４とそれぞれ電気的に接続されることにより、各部の制御を行うようになっている。
【００１４】
窓口端末２は、オペレータのログイン時、あるいは起動時に、ＡＰ／ＤＢサーバ６から業務ＡＰをダウンロードして実行するものとするが、窓口端末に業務ＡＰを予め格納しておいてもかまわない。その場合、ＡＰ／ＤＢサーバ６は、各種ＤＢの管理サーバとしてのみ動作する。
また、窓口端末２は、オペレータのログイン時に、ＡＰ／ＤＢサーバ６からログインしたオペレータのＩＤに基づきそのオペレータの承認条件をダウンロードして、承認条件として記憶する。承認条件は、オペレータのログオフと共に消去される。
【００１５】
なお、オペレータは、オペレータ毎に発行されるＩＤカードをカードリーダに通してログインを行う。
上記記憶部２０３には、各部を制御する制御プログラムを格納するメモリが設けられ、この制御プログラムをＣＰＵ２０１に読み込むことにより、ＣＰＵ２０１が各部の制御を行う。
【００１６】
また、役席端末３は、ＣＰＵ（セントラル・プロセッシング・ユニット）３０１により制御される。ＣＰＵ３０１は、表示操作部３０２、記憶部３０３、通信制御部３０４とそれぞれ電気的に接続されることにより、各部の制御を行うようになっている。
上記記憶部３０３には、各部を制御する制御プログラムを格納するメモリが設けられ、この制御プログラムをＣＰＵ３０１に読み込むことにより、ＣＰＵ３０１が各部の制御を行う。
【００１７】
本発明の処理システムによる承認機能は、図１に示す如くである。すなわち、本発明の処理システムにおいて、支店内ＬＡＮには、複数の窓口端末２が接続されていると共に少なくとも１台の役席端末３が接続されているものとする。
【００１８】
態様例１
上述した構成によると、ＡＰ／ＤＢサーバ６と人事情報ＤＢサーバ７は連携しているために、本部人事５の役席端末９から人事情報編集機能によって人事情報ＤＢサーバ７に人事情報ＤＢ７１の変更がなされると、人事情報ＤＢサーバ７はＡＰ／ＤＢサーバ６の同一ＩＤのオペレータの各ＤＢ６１、６２についてデータを比較し、異なっている（未変更）情報を自動的に変更された情報に整合させるように変更してＡＰ／ＤＢサーバ６に仮登録する。
【００１９】
そこで、ＡＰ／ＤＢサーバ６の変更通知部は、各ＤＢ６１、６２が変更され仮登録の状態となった旨のメッセージを営業店１の役席端末３に送り、役席端末３のＣＰＵ３０１は表示操作部３０２に受信した内容を表示する。役席がその内容を確認し、表示操作部３０２より確認済み入力を行うことによって、役席端末３から確認済み通知がＡＰ／ＤＰサーバ６に送られる。ＡＰ／ＤＢサーバ６は確認済み通知を受信すると、仮登録状態を本登録状態とする。
【００２０】
これにより、人事情報ＤＢサーバ７の変更内容が自動的にＡＰ／ＤＢサーバ６にも登録される。例えば、オペレータのランク情報が変更された場合は、ＡＰ／ＤＢサーバ６のＤＢ６１、６２にもそのランク情報が反映される。また、その場合、オペレータランクと図示しない承認条件の対応テーブルから対応する承認条件を取得してあわせて変更する。
なお、仮登録の間は、元の登録情報も保存され、もし仮登録の間にオペレータ情報やオペレータ毎の承認条件等にアクセスがあった場合は、ＡＰ／ＤＢサーバ６のＤＢ管理部は元の登録情報を出力する。
【００２１】
また同様に、営業店１の役席端末３からＡＰ／ＤＢサーバ６のＤＢ６１および／もしくは６２のメンテナンスが行われると、人事情報ＤＢサーバ７の同一ＩＤのオペレータの人事情報ＤＢ７１を比較し、異なっている（未登録）情報を自動的に整合させるように変更して人事情報ＤＢサーバ７に仮登録する。
そこで、人事情報ＤＢサーバ７の人事情報ＤＢ７１が変更された旨のメッセージを本部人事５の役席端末９に送り、役席がその内容を確認し、確認済み入力によって自動的に人事情報ＤＢサーバ７にも登録される。詳細な処理および仮登録時の扱いは、前述の人事情報ＤＢ７１の変更がＡＰ／ＤＢサーバ６のＤＢ６１、６２に反映する場合と同様である。
【００２２】
以上によって、ＡＰ／ＤＢサーバ６と人事情報ＤＢサーバ７の相互のＤＢ情報が同時に変更されると共に不整合の発生をなくすことができる。
【００２３】
態様例２
つぎに、オペレータのＩＤカードを発行（新規発行および再発行）する処理を説明する。
新規オペレータのＩＤカードの登録は、ホスト８のオペレータデータ８１に登録することによって行われる。
そこで、図３に示す如く、本部５の役席端末９からホスト８にＩＤカード登録操作を行うことにより、オペレータデータ８１に登録することができる。このデータの内容は、例えば、図示する如く、オペレータのＩＤ番号、氏名（カナ・漢字）、カード種類（ランク）、店番、再発行回数等である。
【００２４】
本部５の役席端末９からホスト８のオペレータデータ８１にＩＤカード登録操作を行うことにより、オペレータデータ８１にＩＤ番号登録される。なお、このとき設定されたパスワードは、オペレータ情報のパスワードと発行時暗証番号にセットされ、初期パスワードの位置付けとなる。
登録されたＩＤ番号は、ホスト８より、センタ４のＡＰ／ＤＢサーバ６にファイル転送する。
【００２５】
受領したデータについて、自動でＡＰ／ＤＢサーバ６の各ＤＢ６１、６２に登録する。
このように設定されたオペレータ毎承認条件情報は、営業店１の当該オペレータが、窓口端末２に自己の当該ＩＤ番号等を入力してログインすることにより、センタ４のＡＰ／ＤＢサーバ６に保有されている当該オペレータのオペレータ毎承認条件データとして取り出すことができることになる。
【００２６】
以上によって、ホスト取引であるＩＤカード発行操作と連動してＡＰ／ＤＢサーバ６への登録を同時に行うことにより、ホスト８のオペレータデータ８１とＡＰ／ＤＢサーバ６のオペレータ毎承認条件データ６２との間に相違の発生がなくなり、円滑な運用を行うことができる。
【００２７】
態様例３
つぎに、各オペレータがＩＤカードでログインする際に用いるパスワードにはセキュリティ対策として有効期限（通常は７５日）が設けられており、長期出張等などで一定期間使用（ログイン）しないでパスワードの変更操作を行わなかった場合には、当該オペレータは端末にＡＰ／ＤＢサーバ６からログインすることが不可能（ログインロック状態）となる。
【００２８】
ログインロック状態になってしまった場合、ログインロック解除の権限（ランク）を有するオペレータ（役席）によってその役席端末３からログインロック解除操作を行うことができる。
図４に示す如く、役席端末３からセンタ４のＡＰ／ＤＢサーバ６にログインロック解除を行う対象オペレータＩＤを転送する。
【００２９】
これにより、ＡＰ／ＤＢサーバ６のオペレータ毎承認条件ＤＢ６２のパスワード更新日の変更を行うことができ、当該ログインロック解除日がパスワード有効期限最終日となるように設定する。
これによってログインロックが解除され、役席端末３にログインロックが解除された旨のメッセージが送信され、確認キーによって終了する。
【００３０】
そこで、当該オペレータは窓口端末２によってパスワード変更操作を行い、以降通常の業務を行うことができることになる。
さらに、営業店1の役席者が窓口端末のログインロックの解除ができない事情が生じた場合やその役席端末がログインロックになってしまった場合は、図５に示す如く、本部の役席端末９からセンタ４のＡＰ／ＤＢサーバ６にログインロック解除を行う対象オペレータＩＤを転送する。
【００３１】
これにより、ＡＰ／ＤＢサーバ６のオペレータ毎承認条件データベース６２のパスワード更新日の変更を行うことができ、当該ログインロック解除日がパスワード有効期限最終日となるように設定する。
これによってログインロックが解除され、役席端末９にログインロックが解除された旨のメッセージが送信され、確認キーによって終了する。
【００３２】
そこで、本部の当該役席者からの通知により営業店の当該オペレータは窓口端末２によってパスワード変更操作を行い、以降通常の業務を行うことができることになる。
【図面の簡単な説明】
【００３３】
【図１】態様例１を示す概略説明図
【図２】窓口端末と役席端末の説明図
【図３】態様例２を示す概略説明図
【図４】態様例３を示す概略説明図
【図５】態様例３を示す概略説明図
【図６】従来例の概略説明図
【符号の説明】
【００３４】
１ 営業店
２ 窓口端末
３ 役席端末
４ センタ
５ 本部人事
６ ＡＰ／ＤＢサーバ
６１ オペレータ情報ＤＢ
６２ オペレータ毎承認条件ＤＢ
７ 人事情報ＤＢサーバ
７１ 人事情報ＤＢ
８ ホスト
８１ オペレータデータ
９ 本部役席端末
２０１ ＣＰＵ
２０２ 表示操作部
２０３ 記憶部
２０４ 通信制御部
３０１ ＣＰＵ
３０２ 表示操作部
３０３ 記憶部
３０４ 通信制御部
【技術分野】
【０００１】
本発明は、銀行等の金融機関における営業店端末のオペレータのランクに応じたオペレータ承認条件設定システムに関する。
【背景技術】
【０００２】
従来の金融機関窓口のオペレータによる窓口端末（現金処理装置）の処理は、その操作に携わるオペレータには、その地位や身分に応じたランク付けがなされており、そのランク付けは、各営業店の役席が個々に設定しているものであり、そのランクに応じた業務範囲（承認条件設定値）内での処理作業は、役席者の承認を必要としないで行うことができ、その業務範囲外の処理については、処理毎に役席者の承認を必要としている。そして、その承認条件は初期設定時に個々のオペレータ毎にすべての承認条件データを設定している。
【０００３】
そこで、オペレータの苗字やランク等の変更によってその登録情報や承認条件を変更する場合は、図６に示す如く、本部の人事役員端末からセンタにある人事情報を管理するための人事情報データベース（以下ＤＢ）サーバの人事情報ＤＢを変更し、業務アプリケーションプログラム（以下ＡＰ）と各種ＤＢを集中管理する管理サーバとしての機能をもつＡＰ／ＤＢサーバのオペレータ毎承認条件ＤＢの承認条件およびオペレータ情報ＤＢの登録情報を営業店の役席端末がそれぞれ変更している。
【０００４】
また、窓口端末側にて、低いランクのオペレータが処理操作中に承認条件設定値以上の処理で役席者の承認を必要とするときに、承認要求を役席端末に通知する手段と、その役席端末側にて、役席者が承認必要オペレータの操作内容を確認する確認手段と、役席端末側にて役席者が上記承認必要オペレータからの承認要求を許可するとき１回限り有効な暗証番号を発行する暗証番号発行手段とを設けた技術があり、これによって、オペレータの窓口端末と役席端末との間を送信で承認情報を通知する方法がある（例えば、特許文献１参照）。
【特許文献１】特開平１１−２５９７３３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかし、企業においては昇進や移転等により人事が変わるもので、その都度、オペレータ情報は変わることになる。人事情報が変わるごとに人事情報ＤＢサーバとＡＰ／ＤＢサーバの各ＤＢを整合させて正しく変えなければならないが、上述した従来の技術においては、人事側役席端末からと営業店側役席端末からそれぞれ各ＤＢを独立して操作することになり、入力時の違い、それぞれの誤入力や未入力という問題が発生する。
【０００６】
また、オペレータのＩＤカードを発行する作業はホストとの取引であり、ホスト取引成立後に、営業店の役席端末はセンタのＡＰ／ＤＢサーバのオペレータ情報およびオペレータ毎承認条件をそれぞれ整合させて設定しなければならないという問題がある。
本発明は、このような問題を解決することを課題とする。
【課題を解決するための手段】
【０００７】
そこで本発明は、センタの、各営業店のオペレータの各ＤＢを保有するＡＰ／ＤＢサーバおよび人事情報ＤＢサーバを互いに連携し、営業店の各窓口端末とＬＡＮ接続した役席端末と、これら端末を上記ＡＰ／ＤＢサーバと接続し、本部の役席端末を上記人事情報ＤＢサーバと接続し、人事情報ＤＢサーバの人事情報ＤＢの変更とＡＰ／ＤＢサーバの各ＤＢの変更があった場合に互いに比較して変更データに整合するように変更させて登録することを特徴とする。
【０００８】
また、本部の役席端末からホストのオペレータデータにＩＤカード登録操作を行うことにより、オペレータデータにＩＤ番号登録し、登録されたＩＤ番号を、ホストより、センタのＡＰ／ＤＢサーバにファイル転送し、受領したデータについて、自動でＡＰ／ＤＢサーバのＤＢに登録すること特徴とする。
【発明の効果】
【０００９】
このようにした本発明は、ＡＰ／ＤＢサーバと人事情報ＤＢサーバの相互のＤＢ情報が同時に変更されると共に不整合の発生をなくすことができることになる。
また、ホスト取引であるＩＤカード発行操作と連動してＡＰ／ＤＢサーバへの登録を同時に行うことにより、ホストのオペレータデータとＡＰ／ＤＢサーバのオペレータ毎承認条件データとの間に相違の発生がなくなり、円滑な運用を行うことができることになる。
【発明を実施するための最良の形態】
【００１０】
以下、図面を参照して本発明による実施例を説明する。
図１はオペレータ承認システムの概略説明図である。
図において、１は営業店であり、各オペレータが操作する窓口端末２と役席者が操作する役席端末３とがある。
４はセンタであり、上記営業店１および本部人事５とそれぞれ公衆網を介して接続しており、ＡＰ／ＤＢサーバ６と人事情報ＤＢサーバ７を有し、互いに連携している。
【００１１】
ＡＰ／ＤＢサーバ６に、各オペレータのオペレータ情報ＤＢ６１および各オペレータの承認条件ＤＢ６２を保有する。このオペレータ毎承認条件ＤＢ６２が保有する承認条件とは、例えば、図示する如く、各オペレータのＩＤ番号、各オペレータの役職情報、その各オペレータの支払取扱い限度額（その金額を超えると役席承認が必要になる金額。）等を関連付けた情報である。
【００１２】
なお、オペレータ毎承認条件ＤＢ６２は、ＡＰ／ＤＢサーバ６で他のＤＢと共に管理するのではなく、オペレータ情報およびオペレータ毎承認条件の管理機能をもたせたオペレータ管理サーバを別に設けてもよい。
また、ＡＰ／ＤＢサーバ６には、端末で行う業務のための業務ＡＰが格納されている。
また、人事情報ＤＢサーバ７に、各オペレータの人事情報ＤＢ７１を保有する。この人事情報ＤＢ７１が保有する情報とは、例えば、図示する如く、各オペレータのＩＤ番号、行員番号、氏名、ランク情報等である。
【００１３】
８はホストであり、各オペレータのＩＤ番号等のオペレータデータ８１を保有する。
つぎに、窓口端末２と役席端末３の処理システムを図２のブロック図を用いて説明する。
窓口端末２は、ＣＰＵ（セントラル・プロセッシング・ユニット）２０１により制御される。ＣＰＵ２０１は、表示操作部２０２、記憶部２０３、通信制御部２０４とそれぞれ電気的に接続されることにより、各部の制御を行うようになっている。
【００１４】
窓口端末２は、オペレータのログイン時、あるいは起動時に、ＡＰ／ＤＢサーバ６から業務ＡＰをダウンロードして実行するものとするが、窓口端末に業務ＡＰを予め格納しておいてもかまわない。その場合、ＡＰ／ＤＢサーバ６は、各種ＤＢの管理サーバとしてのみ動作する。
また、窓口端末２は、オペレータのログイン時に、ＡＰ／ＤＢサーバ６からログインしたオペレータのＩＤに基づきそのオペレータの承認条件をダウンロードして、承認条件として記憶する。承認条件は、オペレータのログオフと共に消去される。
【００１５】
なお、オペレータは、オペレータ毎に発行されるＩＤカードをカードリーダに通してログインを行う。
上記記憶部２０３には、各部を制御する制御プログラムを格納するメモリが設けられ、この制御プログラムをＣＰＵ２０１に読み込むことにより、ＣＰＵ２０１が各部の制御を行う。
【００１６】
また、役席端末３は、ＣＰＵ（セントラル・プロセッシング・ユニット）３０１により制御される。ＣＰＵ３０１は、表示操作部３０２、記憶部３０３、通信制御部３０４とそれぞれ電気的に接続されることにより、各部の制御を行うようになっている。
上記記憶部３０３には、各部を制御する制御プログラムを格納するメモリが設けられ、この制御プログラムをＣＰＵ３０１に読み込むことにより、ＣＰＵ３０１が各部の制御を行う。
【００１７】
本発明の処理システムによる承認機能は、図１に示す如くである。すなわち、本発明の処理システムにおいて、支店内ＬＡＮには、複数の窓口端末２が接続されていると共に少なくとも１台の役席端末３が接続されているものとする。
【００１８】
態様例１
上述した構成によると、ＡＰ／ＤＢサーバ６と人事情報ＤＢサーバ７は連携しているために、本部人事５の役席端末９から人事情報編集機能によって人事情報ＤＢサーバ７に人事情報ＤＢ７１の変更がなされると、人事情報ＤＢサーバ７はＡＰ／ＤＢサーバ６の同一ＩＤのオペレータの各ＤＢ６１、６２についてデータを比較し、異なっている（未変更）情報を自動的に変更された情報に整合させるように変更してＡＰ／ＤＢサーバ６に仮登録する。
【００１９】
そこで、ＡＰ／ＤＢサーバ６の変更通知部は、各ＤＢ６１、６２が変更され仮登録の状態となった旨のメッセージを営業店１の役席端末３に送り、役席端末３のＣＰＵ３０１は表示操作部３０２に受信した内容を表示する。役席がその内容を確認し、表示操作部３０２より確認済み入力を行うことによって、役席端末３から確認済み通知がＡＰ／ＤＰサーバ６に送られる。ＡＰ／ＤＢサーバ６は確認済み通知を受信すると、仮登録状態を本登録状態とする。
【００２０】
これにより、人事情報ＤＢサーバ７の変更内容が自動的にＡＰ／ＤＢサーバ６にも登録される。例えば、オペレータのランク情報が変更された場合は、ＡＰ／ＤＢサーバ６のＤＢ６１、６２にもそのランク情報が反映される。また、その場合、オペレータランクと図示しない承認条件の対応テーブルから対応する承認条件を取得してあわせて変更する。
なお、仮登録の間は、元の登録情報も保存され、もし仮登録の間にオペレータ情報やオペレータ毎の承認条件等にアクセスがあった場合は、ＡＰ／ＤＢサーバ６のＤＢ管理部は元の登録情報を出力する。
【００２１】
また同様に、営業店１の役席端末３からＡＰ／ＤＢサーバ６のＤＢ６１および／もしくは６２のメンテナンスが行われると、人事情報ＤＢサーバ７の同一ＩＤのオペレータの人事情報ＤＢ７１を比較し、異なっている（未登録）情報を自動的に整合させるように変更して人事情報ＤＢサーバ７に仮登録する。
そこで、人事情報ＤＢサーバ７の人事情報ＤＢ７１が変更された旨のメッセージを本部人事５の役席端末９に送り、役席がその内容を確認し、確認済み入力によって自動的に人事情報ＤＢサーバ７にも登録される。詳細な処理および仮登録時の扱いは、前述の人事情報ＤＢ７１の変更がＡＰ／ＤＢサーバ６のＤＢ６１、６２に反映する場合と同様である。
【００２２】
以上によって、ＡＰ／ＤＢサーバ６と人事情報ＤＢサーバ７の相互のＤＢ情報が同時に変更されると共に不整合の発生をなくすことができる。
【００２３】
態様例２
つぎに、オペレータのＩＤカードを発行（新規発行および再発行）する処理を説明する。
新規オペレータのＩＤカードの登録は、ホスト８のオペレータデータ８１に登録することによって行われる。
そこで、図３に示す如く、本部５の役席端末９からホスト８にＩＤカード登録操作を行うことにより、オペレータデータ８１に登録することができる。このデータの内容は、例えば、図示する如く、オペレータのＩＤ番号、氏名（カナ・漢字）、カード種類（ランク）、店番、再発行回数等である。
【００２４】
本部５の役席端末９からホスト８のオペレータデータ８１にＩＤカード登録操作を行うことにより、オペレータデータ８１にＩＤ番号登録される。なお、このとき設定されたパスワードは、オペレータ情報のパスワードと発行時暗証番号にセットされ、初期パスワードの位置付けとなる。
登録されたＩＤ番号は、ホスト８より、センタ４のＡＰ／ＤＢサーバ６にファイル転送する。
【００２５】
受領したデータについて、自動でＡＰ／ＤＢサーバ６の各ＤＢ６１、６２に登録する。
このように設定されたオペレータ毎承認条件情報は、営業店１の当該オペレータが、窓口端末２に自己の当該ＩＤ番号等を入力してログインすることにより、センタ４のＡＰ／ＤＢサーバ６に保有されている当該オペレータのオペレータ毎承認条件データとして取り出すことができることになる。
【００２６】
以上によって、ホスト取引であるＩＤカード発行操作と連動してＡＰ／ＤＢサーバ６への登録を同時に行うことにより、ホスト８のオペレータデータ８１とＡＰ／ＤＢサーバ６のオペレータ毎承認条件データ６２との間に相違の発生がなくなり、円滑な運用を行うことができる。
【００２７】
態様例３
つぎに、各オペレータがＩＤカードでログインする際に用いるパスワードにはセキュリティ対策として有効期限（通常は７５日）が設けられており、長期出張等などで一定期間使用（ログイン）しないでパスワードの変更操作を行わなかった場合には、当該オペレータは端末にＡＰ／ＤＢサーバ６からログインすることが不可能（ログインロック状態）となる。
【００２８】
ログインロック状態になってしまった場合、ログインロック解除の権限（ランク）を有するオペレータ（役席）によってその役席端末３からログインロック解除操作を行うことができる。
図４に示す如く、役席端末３からセンタ４のＡＰ／ＤＢサーバ６にログインロック解除を行う対象オペレータＩＤを転送する。
【００２９】
これにより、ＡＰ／ＤＢサーバ６のオペレータ毎承認条件ＤＢ６２のパスワード更新日の変更を行うことができ、当該ログインロック解除日がパスワード有効期限最終日となるように設定する。
これによってログインロックが解除され、役席端末３にログインロックが解除された旨のメッセージが送信され、確認キーによって終了する。
【００３０】
そこで、当該オペレータは窓口端末２によってパスワード変更操作を行い、以降通常の業務を行うことができることになる。
さらに、営業店1の役席者が窓口端末のログインロックの解除ができない事情が生じた場合やその役席端末がログインロックになってしまった場合は、図５に示す如く、本部の役席端末９からセンタ４のＡＰ／ＤＢサーバ６にログインロック解除を行う対象オペレータＩＤを転送する。
【００３１】
これにより、ＡＰ／ＤＢサーバ６のオペレータ毎承認条件データベース６２のパスワード更新日の変更を行うことができ、当該ログインロック解除日がパスワード有効期限最終日となるように設定する。
これによってログインロックが解除され、役席端末９にログインロックが解除された旨のメッセージが送信され、確認キーによって終了する。
【００３２】
そこで、本部の当該役席者からの通知により営業店の当該オペレータは窓口端末２によってパスワード変更操作を行い、以降通常の業務を行うことができることになる。
【図面の簡単な説明】
【００３３】
【図１】態様例１を示す概略説明図
【図２】窓口端末と役席端末の説明図
【図３】態様例２を示す概略説明図
【図４】態様例３を示す概略説明図
【図５】態様例３を示す概略説明図
【図６】従来例の概略説明図
【符号の説明】
【００３４】
１ 営業店
２ 窓口端末
３ 役席端末
４ センタ
５ 本部人事
６ ＡＰ／ＤＢサーバ
６１ オペレータ情報ＤＢ
６２ オペレータ毎承認条件ＤＢ
７ 人事情報ＤＢサーバ
７１ 人事情報ＤＢ
８ ホスト
８１ オペレータデータ
９ 本部役席端末
２０１ ＣＰＵ
２０２ 表示操作部
２０３ 記憶部
２０４ 通信制御部
３０１ ＣＰＵ
３０２ 表示操作部
３０３ 記憶部
３０４ 通信制御部
【特許請求の範囲】
【請求項１】
センタの、各営業店のオペレータの承認条件を管理するオペレータ管理サーバおよびオペレータの人事情報を含む人事情報管理サーバを互いに連携し、
営業店の各窓口端末とＬＡＮ接続した役席端末と、これら端末を上記オペレータ管理サーバと接続し、
本部の役席端末を上記人事情報管理サーバと接続し、
人事情報管理サーバの人事情報データベースまたはオペレータ管理サーバの各データベースの一方が変更された場合に、変更されたオペレータのデータを互いに比較して変更データに整合させて登録することを特徴とするオペレータ承認条件設定システム。
【請求項２】
センタの、各営業店のオペレータの承認条件を管理するオペレータ管理サーバ及びオペレータの人事情報を含む人事情報管理サーバを互いに連携し、
営業店の各窓口端末とＬＡＮ接続した役席端末と、これら端末を上記オペレータ管理サーバと接続し、
あるオペレータＩＤについて人事情報管理サーバの人事情報データベースのオペレータランクが変更された場合に、オペレータ管理サーバのデータベースの当該オペレータＩＤのデータと変更されたオペレータのデータを互いに比較してオペレータランクを変更することを特徴とするオペレータ承認条件設定システム。
【請求項３】
オペレータ管理サーバのデータベースの当該オペレータＩＤのオペレータランクを変更すると共にオペレータランクに対応させて承認条件データを変更することを特徴とする請求項２に記載のオペレータ承認条件設定システム。
【請求項４】
センタの、各営業店のオペレータの承認条件を管理するオペレータ管理サーバおよびオペレータの人事情報を含む人事情報管理サーバを互いに連携し、
営業店の各窓口端末とＬＡＮ接続した役席端末と、これら端末を上記オペレータ管理サーバと接続し、
本部の役席端末を上記人事情報管理サーバと接続し、
本部の役席端末からホストのオペレータデータにＩＤカード登録操作を行うことにより、オペレータデータにＩＤ番号登録し、登録されたＩＤ番号を、ホストより、センタのオペレータ管理サーバに転送し、オペレータ管理サーバのデータベースに登録すること特徴とするオペレータ承認条件設定システム。
【請求項５】
センタの、各営業店のオペレータの承認条件を管理するオペレータ管理サーバおよびオペレータの人事情報を含む人事情報管理サーバを互いに連携し、
営業店の各窓口端末とＬＡＮ接続した役席端末と、これら端末を上記オペレータ管理サーバと接続し、
本部の役席端末を上記人事情報管理サーバと接続し、
オペレータのＩＤがログインロック状態になってしまった場合、営業店もしくは本部の権限を有する役席端末からセンタのオペレータ管理サーバにログインロック解除を行う対象オペレータＩＤを転送し、これにより、オペレータ管理サーバの対象オペレータのパスワード更新日の変更を行い、当該ログインロック解除日がパスワード有効期限最終日となるように設定することを特徴とするオペレータ承認条件設定システム。
【請求項１】
センタの、各営業店のオペレータの承認条件を管理するオペレータ管理サーバおよびオペレータの人事情報を含む人事情報管理サーバを互いに連携し、
営業店の各窓口端末とＬＡＮ接続した役席端末と、これら端末を上記オペレータ管理サーバと接続し、
本部の役席端末を上記人事情報管理サーバと接続し、
人事情報管理サーバの人事情報データベースまたはオペレータ管理サーバの各データベースの一方が変更された場合に、変更されたオペレータのデータを互いに比較して変更データに整合させて登録することを特徴とするオペレータ承認条件設定システム。
【請求項２】
センタの、各営業店のオペレータの承認条件を管理するオペレータ管理サーバ及びオペレータの人事情報を含む人事情報管理サーバを互いに連携し、
営業店の各窓口端末とＬＡＮ接続した役席端末と、これら端末を上記オペレータ管理サーバと接続し、
あるオペレータＩＤについて人事情報管理サーバの人事情報データベースのオペレータランクが変更された場合に、オペレータ管理サーバのデータベースの当該オペレータＩＤのデータと変更されたオペレータのデータを互いに比較してオペレータランクを変更することを特徴とするオペレータ承認条件設定システム。
【請求項３】
オペレータ管理サーバのデータベースの当該オペレータＩＤのオペレータランクを変更すると共にオペレータランクに対応させて承認条件データを変更することを特徴とする請求項２に記載のオペレータ承認条件設定システム。
【請求項４】
センタの、各営業店のオペレータの承認条件を管理するオペレータ管理サーバおよびオペレータの人事情報を含む人事情報管理サーバを互いに連携し、
営業店の各窓口端末とＬＡＮ接続した役席端末と、これら端末を上記オペレータ管理サーバと接続し、
本部の役席端末を上記人事情報管理サーバと接続し、
本部の役席端末からホストのオペレータデータにＩＤカード登録操作を行うことにより、オペレータデータにＩＤ番号登録し、登録されたＩＤ番号を、ホストより、センタのオペレータ管理サーバに転送し、オペレータ管理サーバのデータベースに登録すること特徴とするオペレータ承認条件設定システム。
【請求項５】
センタの、各営業店のオペレータの承認条件を管理するオペレータ管理サーバおよびオペレータの人事情報を含む人事情報管理サーバを互いに連携し、
営業店の各窓口端末とＬＡＮ接続した役席端末と、これら端末を上記オペレータ管理サーバと接続し、
本部の役席端末を上記人事情報管理サーバと接続し、
オペレータのＩＤがログインロック状態になってしまった場合、営業店もしくは本部の権限を有する役席端末からセンタのオペレータ管理サーバにログインロック解除を行う対象オペレータＩＤを転送し、これにより、オペレータ管理サーバの対象オペレータのパスワード更新日の変更を行い、当該ログインロック解除日がパスワード有効期限最終日となるように設定することを特徴とするオペレータ承認条件設定システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２００８−２５０７６６（Ｐ２００８−２５０７６６Ａ）
【公開日】平成２０年１０月１６日（２００８．１０．１６）
【国際特許分類】
【出願番号】特願２００７−９２３２９（Ｐ２００７−９２３２９）
【出願日】平成１９年３月３０日（２００７．３．３０）
【出願人】（００００００２９５）沖電気工業株式会社 (6,645)
【Ｆターム（参考）】
【公開日】平成２０年１０月１６日（２００８．１０．１６）
【国際特許分類】
【出願日】平成１９年３月３０日（２００７．３．３０）
【出願人】（００００００２９５）沖電気工業株式会社 (6,645)
【Ｆターム（参考）】
[ Back to top ]