(57)【要約】【課題】承認業務の質の安定化を図ることを課題とする。【解決手段】本発明の役席端末２２の処理部２２１は、窓口端末２１から業務に関する承認の依頼を受け付けた場合、当該依頼の内容のうちの承認理由などに基づいて事務規程ＤＢサーバ１３に問い合わせ、事務規程ＤＢサーバ１３から当該依頼の内容に関連する事務規程を受信し、その受信した事務規程と依頼の内容とを表示部２２４の同一画面上に表示させることで、承認業務の質の安定化を図ることができる。【選択図】図１
2010049373.tif 000002
【特許請求の範囲】
【請求項１】
業務に関する承認の依頼を行う者によって操作される承認依頼端末と、
前記業務に関する承認を与える者によって操作され、処理部および表示部を有する承認端末と、
前記承認を行うときに参照すべき留意事項を記憶している留意事項ＤＢ（Data Base）サーバと、
を備え、それぞれが相互に通信可能に接続されている業務承認システムであって、
前記承認端末の処理部は、
前記承認依頼端末から前記業務に関する承認の依頼を受け付けた場合、当該依頼の内容のうちの所定の情報属性に対応するデータに基づいて前記留意事項ＤＢサーバに問い合わせを行い、当該留意事項ＤＢサーバから当該依頼の内容に関連する留意事項の情報を受信し、当該受信した留意事項と前記依頼の内容とを前記表示部の同一画面上に表示させる
ことを特徴とする業務承認システム。
【請求項２】
前記承認端末の処理部は、
前記留意事項ＤＢサーバに問い合わせを行う場合、前記依頼の内容のうちの前記所定の情報属性に対応するデータに基づいて対応するＵＲＬ（Uniform Resource Locator）を生成し、当該ＵＲＬを用いて前記留意事項ＤＢサーバに問い合わせを行う
ことを特徴とする請求項１に記載の業務承認システム。
【請求項３】
前記所定の情報属性は、業務の内容、および、承認理由のうち少なくともいずれかであることを特徴とする請求項１に記載の業務承認システム。
【請求項４】
承認依頼端末と通信可能に接続され、業務に関する承認を行うときに参照すべき留意事項を格納している留意事項ＤＢ（Data Base）を参照可能であり、処理部および表示部を有する承認端末であって、
前記処理部は、
前記承認依頼端末から前記業務に関する承認の依頼を受け付けた場合、当該依頼の内容のうちの所定の情報属性に対応するデータに基づいて前記留意事項ＤＢを参照し、当該留意事項ＤＢから取得した前記依頼の内容に関連する留意事項と前記依頼の内容とを前記表示部の同一画面上に表示させる
ことを特徴とする承認端末。
【請求項５】
前記留意事項ＤＢは、留意事項ＤＢサーバに格納されており、
前記処理部は、
前記留意事項ＤＢを参照する場合、前記依頼の内容のうちの前記所定の情報属性に対応するデータに基づいて対応するＵＲＬ（Uniform Resource Locator）を生成し、当該ＵＲＬを用いて前記留意事項ＤＢサーバに問い合わせを行うことで、前記留意事項ＤＢを参照する
ことを特徴とする請求項４に記載の承認端末。
【請求項６】
前記所定の情報属性は、業務の内容、および、承認理由のうち少なくともいずれかであることを特徴とする請求項４に記載の承認端末。
【請求項７】
業務に関する承認の依頼を行う者によって操作される承認依頼端末と、
前記業務に関する承認を与える者によって操作され、処理部および表示部を有する承認端末と、
前記承認を行うときに参照すべき留意事項を記憶している留意事項ＤＢ（Data Base）サーバと、
を備え、それぞれが相互に通信可能に接続されている業務承認システムによる業務承認方法であって、
前記承認端末の処理部は、
前記承認依頼端末から前記業務に関する承認の依頼を受け付けた場合、当該依頼の内容のうちの所定の情報属性に対応するデータに基づいて前記留意事項ＤＢサーバに問い合わせ、当該留意事項ＤＢサーバから当該依頼の内容に関連する留意事項の情報を受信し、当該受信した留意事項と前記依頼の内容とを前記表示部の同一画面上に表示させる
ことを特徴とする業務承認方法。
【請求項８】
前記承認端末の処理部は、
前記留意事項ＤＢサーバに問い合わせを行う場合、前記依頼の内容のうちの前記所定の情報属性に対応するデータに基づいて対応するＵＲＬ（Uniform Resource Locator）を生成し、当該ＵＲＬを用いて前記留意事項ＤＢサーバに問い合わせを行う
ことを特徴とする請求項７に記載の業務承認方法。
【請求項９】
前記所定の情報属性は、業務の内容、および、承認理由のうち少なくともいずれかであることを特徴とする請求項７に記載の業務承認方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータを用いて業務に関する承認を行う技術に関する。
【背景技術】
【０００２】
近年、高度情報化が進むにつれ、企業などにおける業務に関する承認が、紙媒体ではなく、ネットワーク上などのコンピュータで電子的に行われるようになってきている。業務に関する承認が行われる場面としては、例えば、金融機関の勘定系システム（ネットワーク）において、高額取引や異例取引などに関し、承認依頼者（事務員など）が承認者（役席者など）に承認の依頼を行う場合が考えられる。
【０００３】
そして、承認者が承認業務を行う際には、例えば、承認者が使用する端末の画面上に承認する業務の内容、承認理由、帳票イメージなどが表示され、これらの情報を役席者がチェックした上で承認操作（画面上での「承認」か「非承認」の入力）が行われていた。なお、承認者は、承認業務を行う場合、例えば、電子媒体あるいは紙媒体の留意事項資料（事務規程集など）を参照し、承認理由ごとに定められたチェックポイントに従ってチェックを行なわなければならない。また、承認者は、通常、事前に研修などを受けており、その知識に基づいて留意事項資料を裁量で参照している、というのが現状の運用である。
【０００４】
また、特許文献１では、電子決裁（承認）システムにおいて、コンピュータ操作に習熟していない対象者のためにデジタルペン入力と端末入力とのいずれの使用も可能とした技術が開示されている。
【特許文献１】特開２００８−３３５８７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、特許文献１を含めた従来の技術では、留意事項資料の参照が承認者の裁量となっているので、例えば、参照箇所が間違っている、多忙時は留意事項資料が参照されないなど、承認業務の質が安定しないという問題があった。
そこで、本発明は、前記した問題を解決するためになされたものであり、承認業務の質の安定化を図ることを課題とする。
【課題を解決するための手段】
【０００６】
前記した課題を解決するために、本発明は、業務に関する承認の依頼を行う者によって操作される承認依頼端末と、業務に関する承認を与える者によって操作され、処理部および表示部を有する承認端末と、承認を行うときに参照すべき留意事項を記憶している留意事項ＤＢサーバと、を備え、それぞれが相互に通信可能に接続されている業務承認システムである。
承認端末の処理部は、承認依頼端末から業務に関する承認の依頼を受け付けた場合、当該依頼の内容のうちの所定の情報属性に対応するデータに基づいて留意事項ＤＢサーバに問い合わせを行い、当該留意事項ＤＢサーバから当該依頼の内容に関連する留意事項の情報を受信し、当該受信した留意事項と依頼の内容とを表示部の同一画面上に表示させることを特徴とする。
【０００７】
これにより、承認端末の表示部の同一画面上に、承認する業務の内容と、承認を行う際の留意事項が表示されるので、承認者が留意事項の参照箇所を間違える、あるいは、留意事項を参照しないなどといった問題が発生しにくい。
その他の手段については後記する。
【発明の効果】
【０００８】
本発明によれば、承認業務の質の安定化を図ることができる。
【発明を実施するための最良の形態】
【０００９】
以下、本発明を実施するための最良の形態（以下、「実施形態」という。）について、各図面を参照（言及図以外の図も適宜参照）しながら説明する。本実施形態では、金融機関における勘定系システムにおける業務承認システムについて説明する。なお、勘定系システムとは、金融機関などの組織において会計勘定処理（預金勘定元帳、為替、ＡＴＭ（Automatic Teller's Machine）などに関する処理）を行うコンピュータシステム群を指す。
【００１０】
図１は、本実施形態の業務承認システムを示す全体構成図である。業務承認システムＳは、金融機関の事務センタ１における各装置と営業店２における各装置とを備えて構成され、ネットワーク３によってそれらが通信可能に接続されている。
【００１１】
事務センタ１には、ホストコンピュータ１１、メンテナンス端末１２および事務規程ＤＢ（Data Base）サーバ１３（留意事項ＤＢサーバ）が備えられ、それらがＬＡＮ（Local Area Network）１４によって相互に接続されている。
【００１２】
ホストコンピュータ１１は、前記した会計勘定処理を行う大型のコンピュータ装置あるいはワークステーションなどである。
メンテナンス端末１２は、事務センタ１の事務員がホストコンピュータ１１や事務規程ＤＢサーバ１３のメンテナンスを行うためのコンピュータ装置である。
【００１３】
事務規程ＤＢサーバ１３は、事務規程ＤＢ１３１を格納する記憶部（不図示）、ＣＰＵ（Central Processing Unit）などからなる処理部（不図示）などを備えたサーバ（コンピュータ装置）である。
事務規程ＤＢ１３１は、後記する「取引名目」、「取引内容」および「承認理由」などの情報属性のうちの少なくとも１つ以上を用いて、その関連箇所の情報（承認時の留意事項）を抽出することができるデータベースとして構築されている。
【００１４】
営業店２には、窓口端末２１（承認依頼端末）および役席端末２２（承認端末）が備えられ、それらがＬＡＮ２３によって相互に接続されている。
窓口端末２１は、業務に関する承認の依頼を行う事務員など（以下、「承認依頼者」という。）が操作するコンピュータ装置である。
役席端末２２は、業務に関する承認を与える役席者など（以下、「承認者」という。）が操作するコンピュータ装置であり、処理部２２１、記憶部２２２、入力部２２３、表示部２２４および通信部２２５を備えて構成される。
【００１５】
処理部２２１は、役席端末２２の各種動作を制御する手段であり、例えば、ＣＰＵとＲＡＭ（Random Access Memory）によって実現される。
記憶部２２２は、情報を記憶する手段であり、例えば、ＲＯＭ（Read Only Memory）やＨＤＤ（Hard Disk Drive）などによって実現される。記憶部２２２は、処理部２２１の動作プログラムや業務の承認に関連するデータなどを記憶する。
【００１６】
入力部２２３は、承認者が情報を入力する手段であり、例えば、キーボードやマウスなどによって実現される。入力部２２３は、承認者によって入力された情報を処理部２２１に受け渡す。
表示部２２４は、情報を表示する手段であり、例えば、液晶モニタによって実現される。表示部２２４は、処理部２２１からの指示により、業務の承認に関連するデータなどを表示する。
通信部２２５は、窓口端末２１や事務規程ＤＢサーバ１３などと通信を行うための通信インタフェースである。
【００１７】
図２は、本実施形態の業務承認システムにおける各装置の動作を示すフローチャートである。
まず、窓口端末２１は、承認依頼者による取引名目、取引内容および伝票イメージの入力を受け付け（ステップＳ１）、承認依頼者による承認理由の選択の入力を受け付け（ステップＳ２）、承認依頼者による承認依頼操作の入力を受け付ける（ステップＳ３）。
【００１８】
このステップＳ１〜Ｓ３について、図３を参照して説明する。図３は、窓口端末２１の表示部（不図示）に表示される承認依頼画面例である。承認依頼画面例３００には、領域３０１に取引名目が表示され、領域３０２に取引内容が表示され、領域３０３に伝票イメージが表示され、領域３０４に承認理由が表示され、領域３０５に承認依頼ボタンが表示されている。
【００１９】
領域３０１には、承認依頼者によって、「普通預金出金」、「無通帳支払」、「取引の訂正」、「振込入金」などの具体的な取引名目の内容が入力される。
領域３０２には、承認依頼者によって、領域３０１に表示される取引名目に対応する具体的な内容が入力される。
領域３０３には、承認依頼者のスキャニング操作によって読み込まれた実際の伝票の画像データ（伝票イメージ）が表示される。
【００２０】
領域３０４は、プルダウン形式となっており、承認依頼者によって、「高額支払」、「無通帳支払・解約」、「取引の取消・訂正」、「振込入金（1000万円以上）」などの承認理由のいずれかが選択（入力）される。
領域３０５には、承認依頼者が承認者（役席端末２２）に承認を依頼するときに操作する承認依頼ボタンが表示されている。
【００２１】
つまり、窓口端末２１は、ステップＳ１では領域３０１〜３０３（図３参照）において承認依頼者による取引名目、取引内容および伝票イメージの入力を受け付け、ステップＳ２では領域３０４において承認依頼者による承認理由の選択の入力を受け付け、ステップＳ３では領域３０５において承認依頼者による承認依頼操作の入力を受け付ける。
【００２２】
図２に戻って説明を続けると、ステップＳ３において、窓口端末２１が承認依頼者による承認依頼の入力を受け付けると、窓口端末２１から役席端末２２に取引名目、取引内容、伝票イメージおよび承認理由コード（承認理由に対応するコード（符号））の各情報（以下、総称して「取引情報」という。）が送られる。
【００２３】
取引情報を受け取った役席端末２２において、処理部２２１は、その承認理由コードに対応する事務規程の内容を取得するために、承認理由コードをキーにＵＲＬ（Uniform Resource Locator）を作成し、そのＵＲＬを用いて事務規程ＤＢサーバ１３に問い合わせを行う（ステップＳ４）。このＵＲＬは、例えば、「http://（事務規程ＤＢサーバ１３の識別子）/（承認理由コード）.html」といった形式で作成することができる。
【００２４】
前記問い合わせを受け付けた事務規程ＤＢサーバ１３は、事務規程ＤＢ１３１から該当する事務規程の内容を抽出し、その事務規程の内容を役席端末２２に送信する（ステップＳ５）。
【００２５】
事務規程の内容を受け取った役席端末２２において、処理部２２１は、取引情報とその事務規程の内容を表示部２２４に表示する（ステップＳ６）。
【００２６】
このステップＳ６について、図４を参照して説明する。図４は、役席端末２２の表示部２２４に表示される承認操作画面例である。承認操作画面例４００には、領域４０１に取引名目が表示され、領域４０２に取引内容が表示され、領域４０３に伝票イメージが表示され、領域４０４に承認理由が表示され、領域４０５に印鑑照合ボタンが表示され、領域４０６に承認ボタンが表示され、領域４０７に非承認ボタンが表示され、領域４０８に該当する事務規程が表示される。以下、それらの表示について詳細に説明する。
【００２７】
領域４０１，４０２，４０３および４０４には、承認依頼画面例３００の領域３０１，３０２，３０３および３０４（図３参照）で入力されたそれぞれの内容が表示され、これらはすべて、承認者によって承認業務時にチェックされる情報である。
領域４０５には、承認者が領域４０３の伝票イメージ中の印鑑の照合を行うときに操作する印鑑照合ボタンが表示されている。この印鑑照合ボタンが操作されると、画像認識・照合技術により、伝票イメージ中の印鑑が、正当な印鑑か否かが判定され、その判定結果が例えば領域４０３の片隅に表示される（不図示）。
【００２８】
領域４０６には、承認者が承認をする（承認依頼を認可する）ときに操作する承認ボタンが表示されている。
領域４０７には、承認者が非承認をする（承認依頼を認可しない）ときに操作する非承認ボタンが表示されている。
領域４０８には、ステップＳ５で事務規程ＤＢサーバ１３が役席端末２２に送信した事務規程の内容が表示される。
【００２９】
つまり、ステップＳ６では、領域４０１〜４０４に取引情報が表示され、領域４０８に該当する事務規程が表示される。このような承認操作画面例４００を表示部２２４に表示することで、承認者が参照箇所を間違える、あるいは、事務規程を参照しないなどの問題の発生を抑制し、承認業務の質を安定させることができる。
【００３０】
図２に戻って説明を続けると、ステップＳ７において、役席端末２２の処理部２２１は、承認者による入力部２２３を用いた承認操作の入力を受け付け、通信部２２５を介してその承認結果を窓口端末２１に送信する。承認操作の入力をする際、承認者は、具体的には、表示部２２４の承認操作画面例４００（図４参照）において、領域４０６の承認ボタンか、領域４０７の非承認ボタンのいずれかを、入力部２２３を用いて選択（入力）する。
【００３１】
窓口端末２１は、承認結果を判定し（ステップＳ８）、承認の場合（「承認」）はステップＳ９に進み、非承認の場合（「非承認」）はその旨を表示などしてから処理を終了する。
ステップＳ９において、窓口端末２１は、ホストコンピュータ１１に対して、取引情報と承認結果を送信する。
これを受けて、ホストコンピュータ１１は、取引情報に基づき、取引を処理し、その処理結果を窓口端末２１に送信し（ステップＳ１０）、窓口端末２１はその旨を表示などしてから処理を終了する。
【００３２】
このように、本実施形態の業務承認システムＳによれば、役席端末２２の表示部２２４の同一画面上に取引情報とそれに関連する事務規程を表示することにより、承認者は、承認業務時に事務規程の該当箇所を何らの労力なく参照できる。そして、これにより、承認業務の質を安定させることができる。つまり、承認者が事務規程の参照箇所を間違える、あるいは、事務規程を参照しないなどといった事態を未然に防止することができる。
【００３３】
また、このような仕組みにより、業務内容の変更や関係法令の改正に伴う事務規程の変更が発生した際にも、人的な集合研修などによる知識習得なしで、承認者は、承認業務時に事務規程の該当箇所を適切に参照することができる。
【００３４】
さらに、役席端末２２から事務規程ＤＢサーバ１３に事務規程の問い合わせを行う場合、承認理由コードに基づいてその対応するＵＲＬを生成し、そのＵＲＬを用いて事務規程ＤＢサーバ１３に問い合わせを行うことで、情報処理の単純化および高速化を実現できる。
【００３５】
また、承認者が承認業務時に参照すべき事務規程の箇所は、業務の内容および承認理由のいずれかに依存して決定することが多いと考えられる。そのため、役席端末２２から事務規程ＤＢサーバ１３に対する事務規程の問い合わせを業務の内容および承認理由の少なくともいずれかにすることで、事務規程から適切な情報を抽出することができる。
【００３６】
＜比較例＞
次に、本実施形態の業務承認システムＳによる承認操作画面例４００に対する比較例について、図５を参照して説明する。図５は、承認操作画面例の比較例を示す図である。承認操作画面例５００において、領域５０１〜５０７には、承認操作画面例４００の領域４０１〜４０７と同じ内容が表示される。しかし、承認操作画面例５００では、承認操作画面例４００の領域４０８に対応する情報（事務規程の内容）が表示されないため、承認者は、承認業務時に、事務規程を参照したければ、何らかの手段で事務規程の情報を取得しなければならい。これにより、承認者が事務規程の参照箇所を間違える、あるいは、事務規程を参照しないなどといった問題が発生してしまう。
【００３７】
以上で本実施形態の説明を終えるが、本発明の態様はこれらに限定されるものではない。
例えば、役席端末２２から事務規程ＤＢサーバ１３に事務規程の内容を取得するための問い合わせをする際、承認理由コードをキーに作成したＵＲＬを用いたが、それ以外に、承認理由などの用語を用いてもよく、その場合、事務規程ＤＢサーバ１３でその承認理由などの用語を用いて事務規程ＤＢ１３１に対して検索をかけて必要な情報を抽出し役席端末２２に送信すればよい。
【００３８】
また、図４の承認操作画面例４００では、領域４０８に表示される各事務規程と、それらに対応する領域４０２や領域４０３の各情報を、見やすいように左右に対照させて表示してもよい。
さらに、事務規程ＤＢサーバ１３は、事務センタ１でなくても営業店２にあってもよい。
【００３９】
また、事務規程ＤＢ１３１が役席端末２２に存在する構成となっていてもよい。
さらに、本発明は、金融機関の勘定系システムでなくても、業務に関する承認をネットワーク上で行うシステム全般に適用可能である。
その他、ハードウェアやフローチャートなどの具体的な構成について、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。
【図面の簡単な説明】
【００４０】
【図１】本実施形態の業務承認システムを示す全体構成図である。
【図２】本実施形態の業務承認システムにおける各装置の動作を示すフローチャートである。
【図３】窓口端末の表示部に表示される承認依頼画面例である。
【図４】役席端末の表示部に表示される承認操作画面例である。
【図５】承認操作画面例の比較例を示す図である。
【符号の説明】
【００４１】
１      事務センタ
２      営業店
３      ネットワーク
１１    ホストコンピュータ
１２    メンテナンス端末
１３    事務規程ＤＢサーバ（留意事項ＤＢサーバ）
１４    ＬＡＮ
２１    窓口端末（承認依頼端末）
２２    役席端末（承認端末）
２３    ＬＡＮ
１３１  事務規程ＤＢ（留意事項ＤＢ）
２２１  処理部
２２２  記憶部
２２３  入力部
２２４  表示部
２２５  通信部
Ｓ      業務承認システム
【図１】
2010049373.tif 000003
【図２】
2010049373.tif 000004
【図３】
2010049373.tif 000005
【図４】
2010049373.tif 000006
【図５】
2010049373.tif 000007