(57)【要約】【課題】被保護顧客の取引の安全性を高めるとともに、被保護顧客および保護者の負担を軽減する。【解決手段】本情報処理装置は、被保護顧客による金融取引の実行を承認する取引条件を記憶する条件記憶手段と、前記被保護顧客による金融取引の実行に係る安全性を示すスコアを記憶するスコア記憶手段と、実行対象の金融取引が前記取引条件を満たすか否かを判定する第１判定手段と、前記第１判定手段による判定結果が否定判定の場合に、前記実行対象の金融取引の実行可否を前記スコアに基づいて判定する第２判定手段と、前記第１判定手段または前記第２判定手段のいずれか一方の判定結果が肯定判定の場合に、前記実行対象の金融取引を実行させる実行手段と、前記実行対象の金融取引の実行結果に基づいて、前記スコア記憶手段に記憶されるスコアを更新する更新手段と、を備える。【選択図】図２
2020154986.tif 000002
【特許請求の範囲】
【請求項１】
被保護顧客による金融取引の実行を承認する取引条件を記憶する条件記憶手段と、
前記被保護顧客による金融取引の実行に係る安全性を示すスコアを記憶するスコア記憶手段と、
実行対象の金融取引が前記取引条件を満たすか否かを判定する第１判定手段と、
前記第１判定手段による判定結果が否定判定の場合に、前記実行対象の金融取引の実行可否を前記スコアに基づいて判定する第２判定手段と、
前記第１判定手段または前記第２判定手段のいずれか一方の判定結果が肯定判定の場合に、前記実行対象の金融取引を実行させる実行手段と、
前記実行対象の金融取引の実行結果に基づいて、前記スコア記憶手段に記憶されるスコアを更新する更新手段と、を備える、
情報処理装置。
【請求項２】
前記第２判定手段は、肯定判定を行うと、前記スコアに基づいて前記金融取引の実行を承認したことを通知する実行通知を前記被保護顧客の保護者に対して通知する、
請求項１に記載の情報処理装置。
【請求項３】
前記更新手段は、前記実行通知の応答として前記保護者による前記被保護顧客の評価結果を受信すると、受信した評価結果に基づいて前記スコア記憶手段に記憶されるスコアを更新する、
請求項２に記載の情報処理装置。
【請求項４】
被保護顧客による金融取引の実行を承認する取引条件と、前記被保護顧客による金融取引の実行に係る安全性を示すスコアとを記憶部に記憶したコンピュータが、
実行対象の金融取引が前記取引条件を満たすか否かを判定する第１判定ステップと、
前記第１判定ステップによる判定結果が否定判定の場合に、前記実行対象の金融取引の実行可否を前記スコアに基づいて判定する第２判定ステップと、
前記第１判定ステップまたは前記第２判定ステップのいずれか一方の判定結果が肯定判定の場合に、前記実行対象の金融取引を実行させる実行ステップと、
前記実行対象の金融取引の実行結果に基づいて、前記記憶部に記憶されるスコアを更新する更新ステップと、を実行する、
情報処理方法。
【請求項５】
被保護顧客による金融取引の実行を承認する取引条件と、前記被保護顧客による金融取引の実行に係る安全性を示すスコアとを記憶部に記憶したコンピュータに、
実行対象の金融取引が前記取引条件を満たすか否かを判定する第１判定ステップと、
前記第１判定ステップによる判定結果が否定判定の場合に、前記実行対象の金融取引の実行可否を前記スコアに基づいて判定する第２判定ステップと、
前記第１判定ステップまたは前記第２判定ステップのいずれか一方の判定結果が肯定判定の場合に、前記実行対象の金融取引を実行させる実行ステップと、
前記実行対象の金融取引の実行結果に基づいて、前記記憶部に記憶されるスコアを更新する更新ステップと、を実行させる、
情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法および情報処理プログラムに関する。
【背景技術】
【０００２】
認知症や老化等により判断力が低下した被保護顧客による取引について、被保護顧客が実行可能な取引の取引条件を事前に設定し、設定した取引条件に合致しない取引を実行不可とすることで、被保護顧客を保護することが提案されている（例えば、特許文献１−４参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１５−０６４６２１号公報
【特許文献２】特開２０１６−０１２２０６号公報
【特許文献３】特開２０１８−１６３６２８号公報
【特許文献４】特開２００７−２１９８８５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
取引条件に合致しない取引を被保護顧客が実行しようとする場合、被保護顧客に設定された保護者に対して当該取引の承認を求めることになる。取引の実行時に保護者の都合がつくとは限らないため、取引の実行に時間を要することになるため被保護顧客に不便を強いることになる。また、保護者にとっては、取引条件外の取引が発生するたびに承認する手間が生じる。事前に個別の取引について保護者に承認を得ておき、任意のタイミングで被保護顧客が取引を実行することも考えられるが、このような場合、被保護顧客は、事前に承認を得た取引内容しか実行できず、多少の金額変更等も行うことができない。取引条件を緩く設定することで被保護顧客の不便や保護者の手間を軽減することも考えられるが、緩い取引条件では被保護顧客を保護する効果を低下させてしまうことになる。
【０００５】
開示の技術の１つの側面は、被保護顧客の取引の安全性を高めるとともに、被保護顧客および保護者の負担を軽減することを課題とする。
【課題を解決するための手段】
【０００６】
開示の技術の１つの側面は、次のような情報処理装置によって例示される。本情報処理装置は、被保護顧客による金融取引の実行を承認する取引条件を記憶する条件記憶手段と、前記被保護顧客による金融取引の実行に係る安全性を示すスコアを記憶するスコア記憶手段と、実行対象の金融取引が前記取引条件を満たすか否かを判定する第１判定手段と、前記第１判定手段による判定結果が否定判定の場合に、前記実行対象の金融取引の実行可否を前記スコアに基づいて判定する第２判定手段と、前記第１判定手段または前記第２判定手段のいずれか一方の判定結果が肯定判定の場合に、前記実行対象の金融取引を実行させる実行手段と、前記実行対象の金融取引の実行結果に基づいて、前記スコア記憶手段に記憶されるスコアを更新する更新手段と、を備える。
【０００７】
金融取引は、例えば、口座からの出金、口座間の送金、株式や投資信託、債券等の売買である。被保護顧客は、例えば、認知症や老化等により判断力が低下した顧客である。被保護顧客は、判断力が低下していない顧客を含んでもよい。開示の技術によれば、本情報処理装置は、登録済みの取引条件を満たさない場合、被保護顧客による金融取引の実行に係る安全性を示すスコアに基づいて金融取引の実行可否を判定する。比較的安全に金融取
引を行うことができる被保護顧客については、スコアに基づく判定によって金融取引を実行可となる場合が増加する。そのため、スコアが高い被保護顧客については、取引条件を少々逸脱しても金融取引の実行が可能になり、被保護顧客の安全性を考慮しつつ、被保護顧客および保護者の利便性を高めることができる。一方、スコアが低い被保護顧客については取引条件を逸脱した金融取引の実行が禁止されやすくなるため、被保護顧客の資産の安全性を高めることができる。
【０００８】
開示の技術は、次の特徴を有してもよい。前記第２判定手段は、肯定判定を行うと、前記スコアに基づいて前記金融取引の実行を承認したことを通知する実行通知を前記被保護顧客の保護者に対して通知する。このような特徴を有することで、取引条件を満たさない取引が実行されたことを保護者に通知することができる。
【０００９】
開示の技術は、次の特徴を有してもよい。前記更新手段は、前記実行通知の応答として前記保護者による前記被保護顧客の評価結果を受信すると、受信した評価結果に基づいて前記スコア記憶手段に記憶されるスコアを更新する。このような特徴を有することで、保護者による評価結果を基にスコアを更新できるため、スコアの信頼性を高めることができる。
【００１０】
開示の技術は、情報処理方法および情報処理プログラムの側面から把握することも可能である。
【発明の効果】
【００１１】
開示の技術によれば、被保護顧客の取引の安全性を高めるとともに、被保護顧客および保護者の負担を軽減することができる。
【図面の簡単な説明】
【００１２】
【図１】図１は、実施形態に係る取引安全システムの一例を示す図である。
【図２】図２は、実施形態に係る取引安全システムの処理ブロックの一例を示す図である。
【図３】図３は、実施形態における顧客管理データベースが有する顧客管理テーブルの一例を示す図である。
【図４】図４は、実施形態における顧客管理データベースが有するスコア管理テーブルの一例を示す図である。
【図５】図５は、実施形態における顧客管理データベースが有する取引履歴テーブルの一例を示す図である。
【図６】図６は、実施形態における条件データベースが有する条件テーブルの一例を示す図である。
【図７】図７は、実施形態における条件データベースが有する許容範囲管理テーブルの一例を示す図である。
【図８】図８は、実施形態における算出基準データベースが有する属性テーブルの一例を示す図である。
【図９】図９は、実施形態における算出基準データベースが有する判断力スコアテーブルの一例を示す図である。
【図１０】図１０は、実施形態における算出基準データベースが有するロック解除スコアテーブルの一例を示す図である。
【図１１】図１１は、実施形態における算出基準データベースが有する乖離率・回数スコアテーブルの一例を示す図である。
【図１２】図１２は、実施形態における算出基準データベースが有する乖離率・金額スコアテーブルの一例を示す図である。
【図１３】図１３は、実施形態に係る取引安全システムの処理フローの一例を示す図である。
【図１４】図１４は、第１変形例に係る取引安全システムの処理ブロックの一例を示す図である。
【図１５】図１５は、第１変形例に係る取引安全システムの処理フローの一例を示す図である。
【図１６】図１６は、第２変形例に係る取引安全システムの処理ブロックの一例を示す図である。
【図１７】図１７は、第２変形例における算出基準データベースが有する事後評価テーブルの一例を示す図である。
【図１８】図１８は、第２変形例に係る取引安全システムのスコア調整処理の処理フローの一例である。
【発明を実施するための形態】
【００１３】
以下、図面を参照して、実施形態について説明する。以下に示す実施形態の構成は例示であり、開示の技術は実施形態の構成に限定されない。
【００１４】
＜実施形態＞
図１は、実施形態に係る取引安全システムの一例を示す図である。実施形態に係る取引安全システム５００は、Ａｕｔｏｍａｔｉｃ  Ｔｅｌｌｅｒ  Ｍａｃｈｉｎｅ（ＡＴＭ）１、管理サーバ２および窓口端末３を含む。ＡＴＭ１、管理サーバ２および窓口端末３は、ネットワーク環境５を介して相互に通信可能に接続される。
【００１５】
ＡＴＭ１は、金融機関が保有する情報処理装置である。ＡＴＭ１は、顧客の指示に応じて、現金の入出金や資金の送金等の取引を実行する。ＡＴＭ１は、顧客が入金した現金をＡＴＭ１が有する格納庫１０６に格納するとともに、顧客の口座への入金処理を管理サーバ２に依頼する。ＡＴＭ１は、顧客から現金の出金を要求されると、出金の可否を管理サーバ２に問い合わせる。問い合わせに対する応答として出金可を管理サーバ２から受信すると、ＡＴＭ１は、格納庫１０６から指定された金額の現金を出金するとともに、顧客の口座への出金処理を管理サーバ２に依頼する。ＡＴＭ１は、顧客から送金を指示されると、送金可否を管理サーバ２に問い合わせる。問い合わせの結果として送金可を受信すると、ＡＴＭ１は、顧客が保有する口座から送金先の口座への送金処理を管理サーバ２に依頼する。ＡＴＭ１は、「取引装置」の一例である。顧客は、「被保護顧客」の一例である。現金の入出金や資金の送金等の取引は、「金融取引」の一例である。
【００１６】
管理サーバ２は、金融機関が保有する情報処理装置である。管理サーバ２は、金融機関のＡＴＭ１および顧客が保有する口座を管理する。管理サーバ２は、ＡＴＭ１からの依頼に応じて、入出金処理や送金処理を行う。また、管理サーバ２は、ＡＴＭ１を用いて取引を行う顧客が実行する取引の実行可否を判定する。管理サーバ２は、「情報処理装置」の一例である。
【００１７】
窓口端末３は、金融機関の店舗において、窓口を担当する行員が使用する情報処理装置である。窓口端末３は、顧客からカードや通帳の紛失に伴う再発行の依頼や、暗証番号の誤入力の回数や暗証番号の累積誤回数を消去して通帳やキャッシュカードのロックを解除するロック解除の依頼を受け付ける。窓口端末３は、カードや通帳の紛失に伴う再発行の依頼やロック解除の依頼を受け付けると、管理サーバ２に報告する。
【００１８】
図１を参照して、ＡＴＭ１、管理サーバ２および窓口端末３のハードウェア構成についてさらに説明する。ＡＴＭ１は、Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ（ＣＰＵ）１０１、主記憶部１０２、補助記憶部１０３、通信部１０４、入出金口１０５、格納庫１０６および接続バスＢ１を含む。ＣＰＵ１０１、主記憶部１０２、補助記憶部１０
３、通信部１０４、入出金口１０５および格納庫１０６は、接続バスＢ１によって相互に接続される。
【００１９】
ＣＰＵ１０１は、マイクロプロセッサユニット（ＭＰＵ）、プロセッサとも呼ばれる。ＣＰＵ１０１は、単一のプロセッサに限定される訳ではなく、マルチプロセッサ構成であってもよい。また、単一のソケットで接続される単一のＣＰＵ１０１がマルチコア構成を有していても良い。ＣＰＵ１０１が実行する処理のうち少なくとも一部は、ＣＰＵ１０１以外のプロセッサ、例えば、Ｄｉｇｉｔａｌ  Ｓｉｇｎａｌ  Ｐｒｏｃｅｓｓｏｒ（ＤＳＰ）、Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ（ＧＰＵ）、数値演算プロセッサ、ベクトルプロセッサ、画像処理プロセッサ等の専用プロセッサで行われても良い。また、ＣＰＵ１０１が実行する処理のうち少なくとも一部は、集積回路（ＩＣ）、その他のディジタル回路によって実行されてもよい。また、ＣＰＵ１０１の少なくとも一部にアナログ回路が含まれても良い。集積回路は、Ｌａｒｇｅ  Ｓｃａｌｅ  Ｉｎｔｅｇｒａｔｅｄ  ｃｉｒｃｕｉｔ（ＬＳＩ）、Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ（ＡＳＩＣ）、プログラマブルロジックデバイス（ＰＬＤ）を含む。ＰＬＤは、例えば、Ｆｉｅｌｄ−Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ（ＦＰＧＡ）を含む。ＣＰＵ１０１は、プロセッサと集積回路との組み合わせであっても良い。組み合わせは、例えば、マイクロコントローラユニット（ＭＣＵ）、Ｓｙｓｔｅｍ−ｏｎ−ａ−ｃｈｉｐ（ＳｏＣ）、システムＬＳＩ、チップセットなどと呼ばれる。情報処理装置１００では、ＣＰＵ１０１が補助記憶部１０３に記憶されたプログラムを主記憶部１０２の作業領域に展開し、プログラムの実行を通じて周辺装置の制御を行う。これにより、情報処理装置１００は、所定の目的に合致した処理を実行することができる。主記憶部１０２および補助記憶部１０３は、ＡＴＭ１が読み取り可能な記録媒体である。
【００２０】
主記憶部１０２は、ＣＰＵ１０１から直接アクセスされる記憶部として例示される。主記憶部１０２は、Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ（ＲＡＭ）およびＲｅａｄ
Ｏｎｌｙ  Ｍｅｍｏｒｙ（ＲＯＭ）を含む。
【００２１】
補助記憶部１０３は、各種のプログラムおよび各種のデータを読み書き自在に記録媒体に格納する。補助記憶部１０３は外部記憶装置とも呼ばれる。補助記憶部１０３には、オペレーティングシステム（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ、ＯＳ）、各種プログラム、各種テーブル等が格納される。ＯＳは、通信部１０４を介して接続される外部装置等とのデータの受け渡しを行う通信インターフェースプログラムを含む。外部装置等には、例えば、コンピュータネットワーク等で接続された、他の情報処理装置および外部記憶装置が含まれる。なお、補助記憶部１０３は、例えば、ネットワーク上のコンピュータ群であるクラウドシステムの一部であってもよい。
【００２２】
補助記憶部１０３は、例えば、Ｅｒａｓａｂｌｅ  Ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ（ＥＰＲＯＭ）、ソリッドステートドライブ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ、ＳＳＤ）、ハードディスクドライブ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ、ＨＤＤ）等である。また、補助記憶部１０３は、例えば、Ｃｏｍｐａｃｔ  Ｄｉｓｃ（ＣＤ）ドライブ装置、Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｃ（ＤＶＤ）ドライブ装置、Ｂｌｕ−ｒａｙ（登録商標）  Ｄｉｓｃ（ＢＤ）ドライブ装置等である。また、補助記憶部１０３は、Ｎｅｔｗｏｒｋ  Ａｔｔａｃｈｅｄ  Ｓｔｏｒａｇｅ（ＮＡＳ）あるいはＳｔｏｒａｇｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ（ＳＡＮ）によって提供されてもよい。
【００２３】
通信部１０４は、例えば、ネットワーク環境５とのインターフェースである。通信部１０４は、ネットワーク環境５を介して外部の装置と通信を行う。
【００２４】
入出金口１０５は、顧客からの紙幣の入金および出金を受け付ける窓口である。ＡＴＭ１は、顧客から入金の指示を受けると、入出金口１０５を開いて紙幣を受け付ける。また、ＡＴＭ１は、顧客から出勤の指示を受けると、入出金口１０５を開いてＡＴＭ１内の紙幣を出金する。
【００２５】
格納庫１０６は、紙幣を格納する格納庫である。格納庫１０６は、実際には金種別に用意されるが、本明細書では簡単のため、ＡＴＭ１は格納庫１０６をひとつ備えるものとする。入出金口１０５を介して入金された紙幣は格納庫１０６に格納される。また、ＡＴＭ１は、顧客から出金を指示されると、指示された額の紙幣を格納庫１０６から取り出し、入出金口１０５を介して出金する。
【００２６】
ＡＴＭ１は、例えば、顧客等からの操作指示等を受け付ける入力部をさらに備えてもよい。このような入力部として、キーボード、タッチパネルあるいは音声入力装置といった入力デバイスを例示できる。
【００２７】
ＡＴＭ１は、例えば、ＣＰＵ１０１で処理されるデータや主記憶部１０２に記憶されるデータを出力する出力部を備えるものとしてもよい。このような、出力部として、Ｃａｔｈｏｄｅ  Ｒａｙ  Ｔｕｂｅ（ＣＲＴ）ディスプレイ、Ｌｉｑｕｉｄ  Ｃｒｙｓｔａｌ  Ｄｉｓｐｌａｙ（ＬＣＤ）、Ｐｌａｓｍａ  Ｄｉｓｐｌａｙ  Ｐａｎｅｌ（ＰＤＰ）、Ｅｌｅｃｔｒｏｌｕｍｉｎｅｓｃｅｎｃｅ（ＥＬ）パネル、有機ＥＬパネルあるいはプリンタといった出力デバイスを例示できる。
【００２８】
管理サーバ２は、ＣＰＵ２０１、主記憶部２０２、補助記憶部２０３、通信部２０４および接続バスＢ２を含む。ＣＰＵ２０１、主記憶部２０２、補助記憶部２０３、通信部２０４および接続バスＢ２のそれぞれは、ＡＴＭ１のＣＰＵ１０１、主記憶部１０２、補助記憶部１０３、通信部１０４および接続バスＢ１のそれぞれと同一の構成であるため、その説明を省略する。
【００２９】
窓口端末は、ＣＰＵ３０１、主記憶部３０２、補助記憶部３０３、通信部３０４および接続バスＢ３を含む。ＣＰＵ３０１、主記憶部３０２、補助記憶部３０３、通信部３０４および接続バスＢ３のそれぞれは、ＡＴＭ１のＣＰＵ１０１、主記憶部１０２、補助記憶部１０３、通信部１０４および接続バスＢ１のそれぞれと同一の構成であるため、その説明を省略する。
【００３０】
＜取引安全システム５００の処理ブロック＞
図２は、実施形態に係る取引安全システムの処理ブロックの一例を示す図である。以下、図２を参照して、実施形態に係る取引安全システム５００の処理ブロックの一例について説明する。
【００３１】
（ＡＴＭ１の処理ブロック）
ＡＴＭ１は、問い合わせ部１１および取引実行部１２を備える。ＡＴＭ１は、主記憶部１０２に実行可能に展開されたコンピュータプログラムをＣＰＵ１０１が実行することで、上記ＡＴＭ１の、問い合わせ部１１および取引実行部１２等の各部としての処理を実行する。
【００３２】
問い合わせ部１１は、顧客から取引の実行を指示されると、指示された取引の実行可否を問い合わせる判定要求を管理サーバ２に送信する。判定要求は、例えば、取引の実行を指示した顧客の顧客ＩＤおよび指示された取引を示す取引情報を含む。取引情報は、例えば、取引の種別（送金、出金等）や取引の対象となる金額を含む。取引実行部１２は、指示された取引が実行可と判定された場合に、取引の実行を行う。取引は、例えば、口座か
らの出金や口座間の送金によって例示できる。
【００３３】
（管理サーバ２の処理ブロック）
管理サーバ２は、登録部２１、第１判定部２２ａ、第２判定部２２ｂ、更新部２３、指示部２４、顧客管理データベース２５、条件データベース２６および算出基準データベース２７を備える。管理サーバ２は、主記憶部２０２に実行可能に展開されたコンピュータプログラムをＣＰＵ２０１が実行することで、上記管理サーバ２の、登録部２１、判定部２２、更新部２３、指示部２４、顧客管理データベース２５、条件データベース２６および算出基準データベース２７等の各部としての処理を実行する。なお、図中では、データベースはＤＢと表記される。
【００３４】
顧客管理データベース２５は、顧客を管理するデータベースである。図３は、実施形態における顧客管理データベースが有する顧客管理テーブルの一例を示す図である。図３に例示される顧客管理テーブル２５１は、「顧客ＩＤ」、「年齢」、「承認者連絡先」の各項目を含む。「顧客ＩＤ」には、顧客を一意に識別するＩＤが格納される。「年齢」には、顧客の年齢が格納される。「承認者連絡先」には、顧客の取引について承認を行う承認者の連絡先（メールアドレス、電話番号等）が格納される。承認者は、顧客の血縁者であってもよいし、血縁者以外の第三者であってもよい。また、承認者は、法律の定めによるものに限られず、任意に設定されたものであってもよい。承認者は、「保護者」の一例である。
【００３５】
図４は、実施形態における顧客管理データベースが有するスコア管理テーブルの一例を示す図である。図４に例示されるスコア管理テーブル２５２は、「顧客ＩＤ」、「紛失回数（１か月）」、「紛失回数（３か月）」、「ロック解除（１か月）」、「ロック解除（３か月）」、「乖離率・回数（１か月）」、「乖離率・回数（３か月）」、「乖離率・回数（１か月）」、「乖離率・回数（３か月）」、「乖離率・金額（１か月）」、「乖離率・金額（３か月）」、「スコア」の各項目を含む。
【００３６】
「顧客ＩＤ」は、顧客管理テーブル２５１の「顧客ＩＤ」と同一であるため、その説明を省略する。「紛失回数（１か月）」には、直近１か月における、キャッシュカードや通帳の紛失回数が格納される。「紛失回数（３か月）」には、直近３か月における、キャッシュカードや通帳の紛失回数が格納される。「ロック解除（１か月）」には、直近１か月における、暗証番号の誤入力の回数や暗証番号の累積誤回数を消去して通帳やキャッシュカードのロックを解除した回数を示す情報が格納される。「ロック解除（３か月）」には、直近３か月における、暗証番号の誤入力の回数や暗証番号の累積誤回数を消去して通帳やキャッシュカードのロックを解除したロック解除の回数を示す情報が格納される。「乖離率・回数（１か月）」には、事前に登録された取引条件において承認された取引回数からの直近１か月における乖離率が格納される。「乖離率・回数（３か月）」には、事前に登録された取引条件において承認された取引回数からの直近３か月における乖離率が格納される。「乖離率・金額（１か月）」には、事前に登録された取引条件において承認された金額からの直近１か月における乖離率が格納される。「乖離率・金額（３か月）」には、事前に登録された取引条件において承認された金額からの直近３か月における乖離率が格納される。「スコア」には、管理サーバ２の更新部２３が算出したスコアが格納される。スコア管理テーブル２５２は、「スコア記憶手段」の一例である。
【００３７】
図５は、実施形態における顧客管理データベースが有する取引履歴テーブルの一例を示す図である。図５に例示される取引履歴テーブル２５３は、「顧客ＩＤ」、「累積金額（１か月）」、「累積金額（３か月）」、「累積回数（１か月）」、「累積金額（３か月）」の各項目を含む。「顧客ＩＤ」は、顧客管理テーブル２５１の「顧客ＩＤ」と同一であるため、その説明を省略する。「累積金額（１か月）」には、１か月の間に顧客が出金ま
たは送金した金額の累積額が格納される。「累積金額（３か月）」には、３か月の間に顧客が出金または送金した金額の累積額が格納される。「累積回数（１か月）」には、１か月の間に顧客が出金または送金した累積回数が格納される。「累積回数（３か月）」には、３か月の間に顧客が出金または送金した累積回数が格納される。すなわち、取引履歴テーブル２５３は、「累積金額（１か月）」、「累積金額（３か月）」、「累積回数（１か月）」、「累積金額（３か月）」の各項目に格納される取引履歴と、「顧客ＩＤ」に格納される顧客ＩＤとを対応付けるテーブルである。
【００３８】
条件テーブル２６は、顧客が実行可能な取引（顧客の取引を承認する承認者が事前に承認した取引）の条件を管理するデータベースである。図６は、実施形態における条件データベースが有する条件テーブルの一例を示す図である。図６に例示される条件テーブル２６１は、「顧客ＩＤ」、「上限金額」、「上限回数」の各項目を含む。「顧客ＩＤ」は、顧客管理テーブル２５１の「顧客ＩＤ」と同一であるため、その説明を省略する。「上限金額」には、送金や出金の１か月当たりの上限額が格納される。「上限回数」には、送金や出金を実行できる１か月あたりの上限回数が格納される。すなわち、条件テーブル２６１は、「上限金額」、「上限回数」の各項目に格納される承認条件と、「顧客ＩＤ」に格納される顧客ＩＤとを対応付けるテーブルである。条件テーブル２６１は、「条件記憶手段」の一例である。
【００３９】
図７は、実施形態における条件データベースが有する許容範囲管理テーブルの一例を示す図である。図７に例示される許容範囲管理テーブル２６２は、「スコア」、「許容範囲」の各項目を含む。「スコア」には、取引を許容する基準となるスコアが格納される。「許容範囲」には、許容される取引金額の変動幅が格納される。すなわち、許容範囲管理テーブル２６２は、「許容範囲」に格納される許容範囲と、「スコア」に格納されるスコアとを対応付けるテーブルである。
【００４０】
算出基準データベース２７は、スコア算出の基準を管理するデータベースである。図８は、実施形態における算出基準データベースが有する属性テーブルの一例を示す図である。図８に例示される属性テーブル２７１は、「スコア」、「年齢」の各項目を含む。「スコア」には、顧客の年齢に基づいて加算されるスコアが格納される。「年齢」には、スコアを加算する基準となる年齢が格納される。
【００４１】
図９は、実施形態における算出基準データベースが有する判断力スコアテーブルの一例を示す図である。図９に例示される判断力スコアテーブル２７２は、「紛失回数（１か月）」、「紛失回数（３か月）」、「スコア」の各項目を含む。「紛失回数（１か月）」には、キャッシュカードや通帳等を１か月以内における紛失する回数の基準が格納される。「紛失回数（３か月）」には、キャッシュカードや通帳等を３か月以内における紛失する回数の基準が格納される。「スコア」には、「紛失回数（１か月）」または「紛失回数（３か月）」に合致する顧客に加算するスコアが格納される。
【００４２】
図１０は、実施形態における算出基準データベースが有するロック解除スコアテーブルの一例を示す図である。図１０に例示されるロック解除スコアテーブル２７３は、「スコア」、「ロック解除（１か月）」、「ロック解除（３か月）」の各項目を含む。「ロック解除（１か月）」には、１か月における、暗証番号の誤入力の回数や暗証番号の累積誤回数を消去して通帳やキャッシュカードのロックを解除した回数の基準が格納される。「ロック解除（３か月）」には、３か月における、暗証番号の誤入力の回数や暗証番号の累積誤回数を消去して通帳やキャッシュカードのロックを解除した回数の基準が格納される。「スコア」には、「ロック解除（１か月）」または「ロック解除（３か月）」に合致する顧客に加算するスコアが格納される。
【００４３】
図１１は、実施形態における算出基準データベースが有する乖離率・回数スコアテーブルの一例を示す図である。図１１に例示される乖離率・回数スコアテーブル２７４は、「スコア」、「乖離率・回数（１か月）」、「乖離率・回数（３か月）」の各項目を含む。「乖離率・回数（１か月）」には、事前に登録された取引条件において承認された取引回数からの１か月間における乖離率の基準が格納される。「乖離率・回数（３か月）」には、事前に登録された取引条件において承認された取引回数からの３か月間における乖離率の基準が格納される。「スコア」には、「乖離率・回数（１か月）」または「乖離率・回数（３か月）」に合致する顧客に加算するスコアが格納される。
【００４４】
図１２に例示される乖離率・金額スコアテーブル２７５は、「スコア」、「乖離率・金額（１か月）」、「乖離率・金額（３か月）」の各項目を含む。「乖離率・金額（１か月）」には、事前に登録された取引条件において承認された取引金額からの１か月間における乖離率の基準が格納される。「乖離率・金額（３か月）」には、事前に登録された取引条件において承認された取引金額からの３か月間における乖離率の基準が格納される。「スコア」には、「乖離率・金額（１か月）」または「乖離率・金額（３か月）」に合致する顧客に加算するスコアが格納される。
【００４５】
図２に戻り、登録部２１は、顧客管理データベース２５のスコア管理テーブル２５２に顧客の初期スコアを登録する。登録部２１は、例えば、新規に口座を開設した顧客についての初期スコアをスコア管理テーブル２５２に登録する。登録部２１は、顧客管理データベース２５の顧客管理テーブル２５１を参照して、新規に登録された顧客の年齢を取得する。登録部２１は、算出基準データベース２７の属性テーブル２７１を参照して、顧客の年齢に対応付けられたスコアを取得する。登録部２１は、取得したスコアをスコア管理テーブル２５２の「スコア」に初期スコアとして登録する。例えば、顧客ＩＤ：ＡＡＡの顧客が新規に登録された場合、登録部２１は、顧客管理テーブル２５１を参照して、顧客ＩＤ：ＡＡＡの年齢として「３１歳」を取得する。登録部２１は、属性テーブル２７１を参照して、３１歳に対応するスコアとして「２」を取得する。登録部２１は、取得したスコア「２」を初期スコアとして、属性テーブル２７１を参照して、登録する。
【００４６】
第１判定部２２ａは、判定要求をＡＴＭ１から受信すると、判定要求に含まれる顧客ＩＤに対応する承認条件が条件データベース２６の条件テーブル２６１に登録されているか否かを判定する。第１判定部２２ａは、判定要求に含まれる顧客ＩＤに対応する承認条件が条件データベース２６の条件テーブル２６１に登録されていない場合、否定判定を行う。
【００４７】
第１判定部２２ａは、承認条件が登録されている場合、判定要求に含まれる取引情報が示す取引が承認条件を満たすか否かを判定する。第１判定部２２ａは、判定要求に含まれる顧客ＩＤに対応付けられた取引履歴を顧客管理データベース２５の取引履歴テーブル２５３から取得する。第１判定部２２ａは、判定要求に含まれる顧客ＩＤに対応付けられた承認条件を条件テーブル２６１から取得する。第１判定部２２ａは、取引履歴と承認条件とから、実行可能な取引の回数と金額とを算出する。
【００４８】
第１判定部２２ａは、例えば、承認条件で設定されている「上限金額」から取引情報に含まれる金額を減算し、「上限回数」から「１」を減算することで、実行可能な取引の回数と金額とを算出する。第１判定部２２ａは、実行可能な取引の回数が１以上であり、かつ、取引条件が示す金額が実行可能な金額以下である場合に、取引情報が示す取引が条件テーブル２６１に登録された条件を満たすと判定する。また、第１判定部２２ａは、実行可能な取引の回数が０、または、取引条件が示す金額が実行可能な金額を超えている場合に、取引情報が示す取引が条件テーブル２６１に登録された条件を満たさないと判定する。第１判定部２２ａは、「第１判定手段」の一例である。
【００４９】
第２判定部２２ｂは、第１判定部２２ａが否定判定を行った場合に、判定要求に含まれる取引情報が示す取引が、条件データベース２６の許容範囲管理テーブル２６２に格納される許容範囲内であるか否かを判定する。第２判定部２２ｂは、判定要求に含まれる顧客ＩＤに対応付けられたスコアを顧客管理データベース２５のスコア管理テーブル２５２から取得する。第２判定部２２ｂは、取得したスコアに対応付けられた許容範囲を許容範囲管理テーブル２６２から取得する。第２判定部２２ｂは、第１判定部２２ａが取得した承認条件に対して、取得した許容範囲を適用することで、スコアに応じた承認条件の調整を行う。第２判定部２２ｂは、取引情報が示す取引が調整後の承認条件を満たすか否かの判定を行う。第２判定部２２ｂは、取引情報が示す取引が調整後の承認条件を満たす場合、肯定判定を行うとともに、顧客管理データベース２５の顧客管理テーブル２５１において当該顧客の顧客ＩＤに対応付けられた連絡先に対し、取引の実行をスコアに基づいて許可した旨の許可通知を送信する。第２判定部２２ｂは、「第２判定手段」の一例である。許可通知は、「実行通知」の一例である。
【００５０】
更新部２３は、顧客管理データベース２５の更新を行う。更新部２３は、例えば、ＡＴＭ１から判定要求を受信すると、判定要求に含まれる取引情報にしたがって、顧客管理データベース２５の取引履歴テーブル２５３を更新する。さらに、更新部２３は、顧客管理データベース２５のスコア管理テーブル２５２を更新する。スコア管理テーブル２５２の更新では、更新部２３は、条件データベース２６の条件テーブル２６１と更新した取引履歴テーブル２５３とを参照して、スコア管理テーブル２５２の、「乖離率・回数（１か月）」、「乖離率・回数（３か月）」、「乖離率・金額（１か月）」、「乖離率・金額（３か月）」を更新する。
【００５１】
更新部２３は、窓口端末３から報告を受信すると、受信した報告にしたがって、顧客管理データベース２５のスコア管理テーブル２５２を更新する。スコア管理テーブル２５２の更新では、更新部２３は、報告にしたがって「紛失回数（１か月）」、「紛失回数（３か月）」、「ロック解除（１か月）」、「ロック解除（３か月）」の更新を行う。
【００５２】
更新部２３は、スコア管理テーブル２５２の項目「紛失回数（１か月）」、「紛失回数（３か月）」、「ロック解除（１か月）」、「ロック解除（３か月）」、「乖離率・回数（１か月）」、「乖離率・回数（３か月）」、「乖離率・金額（１か月）」、「乖離率・金額（３か月）」のいずれかを更新すると、更新した情報を基に、「スコア」を更新する。「スコア」の更新では、更新部２３は、スコア管理テーブル２５２の「紛失回数（１か月）」、「紛失回数（３か月）」、「ロック解除（１か月）」、「ロック解除（３か月）」、「乖離率・回数（１か月）」、「乖離率・回数（３か月）」、「乖離率・金額（１か月）」、「乖離率・金額（３か月）」と算出基準データベース２７に格納された基準とを基に、条件テーブル２６１の「スコア」を更新する。
【００５３】
指示部２４は、第１判定部２２ａまたは第２判定部２２ｂによる判定結果のいずれかが肯定判定の場合に、ＡＴＭ１に対して取引の実行を指示する。また、指示部２４は、第１判定部２２ａおよび第２判定部２２ｂによる判定結果のいずれもが否定判定の場合に、ＡＴＭ１に対して取引の中止を指示する。指示部２４は、「実行手段」の一例である。
【００５４】
（窓口端末３の処理ブロック）
窓口端末３は、受付部３１および報告部３２を備える。窓口端末３は、主記憶部３０２に実行可能に展開されたコンピュータプログラムをＣＰＵ３０１が実行することで、上記窓口端末３の、受付部３１および報告部３２等の各部としての処理を実行する。
【００５５】
受付部３１は、窓口を訪れた顧客からのカードや通帳の再発行の依頼や、通帳やキャッ
シュカードのロックを解除するロック解除等の依頼を受け付ける。報告部３２は、受付部３１が受け付けた依頼を管理サーバ２に報告する。
【００５６】
図１３は、実施形態に係る取引安全システムの処理フローの一例を示す図である。以下、では、図１３を参照して、現金２万円の出金を行う場合を例として説明を行う。また、本処理フロー開始時における、顧客管理テーブル２５１、スコア管理テーブル２５２、取引履歴テーブル２５３、条件テーブル２６１、許容範囲管理テーブル２６２は、それぞれ、図３、図４、図５、図６、図７に例示する状態であるものとする。以下、図１３を参照して、実施形態に係る取引安全システム５００の処理フローの一例について説明する。
【００５７】
Ｓ１では、ＡＴＭ１は、キャッシュカードや通帳等を受け付け、受け付けたキャッシュカードや通帳等から、顧客の顧客ＩＤを取得する。Ｓ２では、ＡＴＭ１は、出金する金額として２万円、取引の種別として出金の取引情報を受信する。ＡＴＭ１の問い合わせ部１１は、Ｓ１で取得した顧客ＩＤとＳ２で受け付けた取引情報を含む判定要求を管理サーバ２に送信する。
【００５８】
Ｓ３では、管理サーバ２は、ＡＴＭ１から判定要求を受信する。管理サーバ２の第１判定部２２ａは、判定要求から顧客ＩＤを取得する。第１判定部２２ａは、取得した顧客ＩＤに対応する承認条件が条件データベース２６の条件テーブル２６１に登録されているか否かを判定する。登録されている場合（Ｓ３でＹＥＳ）、処理はＳ５に進められる。登録されていない場合（Ｓ３でＮＯ）、処理は終了される。
【００５９】
Ｓ４では、管理サーバ２の第１判定部２２ａは、Ｓ３で取得した顧客ＩＤに対応付けられた承認条件を条件テーブル２６１から取得し、判定要求に含まれる取引情報が示す取引が承認条件を満たすか否かを判定する。承認条件を満たす場合（Ｓ４でＹＥＳ）、処理はＳ６に進められる。承認条件を満たさない場合（Ｓ４でＮＯ）、処理はＳ５に進められる。Ｓ４の処理は、「第１判定ステップ」の一例である。
【００６０】
ここで、顧客ＩＤ：ＡＡＡの顧客が送金を行う場合を例にとって、第１判定部２２ａの判定処理について説明する。第１判定部２２ａは、条件テーブル２６１を参照して、顧客ＩＤ：ＡＡＡの上限金額「１０万円」、上限回数「１０回」を承認条件として取得する。第１判定部２２ａは、取引履歴テーブル２５３を参照して、顧客ＩＤ：ＡＡＡの顧客の累積金額（１か月）「３万円」、累積回数（１か月）「３回」を取得する。既に送金または出金を行った金額「３万円」に今回送金対象となる「２万円」を加算すると「５万円」となる。また、既に送金または出金を行った回数「３回」に今回の取引の回数を加算すると「４回」となる。今回の取引によって、金額および回数のいずれも承認条件を満たすため、第１判定部２２ａは、この取引について肯定判定を行う。
【００６１】
続いて、顧客ＩＤ：ＢＢＢの顧客が送金を行う場合を例にとって、第１判定部２２ａの判定処理について説明する。第１判定部２２ａは、条件テーブル２６１を参照して、顧客ＩＤ：ＢＢＢの顧客の上限金額「３万円」、上限回数「１回」を承認条件として取得する。第１判定部２２ａは、取引履歴テーブル２５３を参照して、顧客ＩＤ：ＢＢＢの顧客の累積金額（１か月）「２千円」、累積回数（１か月）「１回」を取得する。既に送金または出金を行った金額「２千円」に今回送金対象となる「２万円」を加算すると「２万２千円」となる。また、既に送金または出金を行った回数「１回」に今回の取引の回数を加算すると「２回」となる。今回の取引によって、金額については承認条件を満たすものの、回数については承認条件を満たさない。そのため、判定部２２ａは、この取引について否定判定を行う。
【００６２】
Ｓ５では、管理サーバ２の第２判定部２２ｂは、スコアを基に取引を許容する許容範囲
を決定し、決定した許容範囲内に取引情報が示す取引が含まれるか否かを判定する。第２判定部２２ｂは、Ｓ３で取得した顧客ＩＤに対応付けられた許容範囲を条件データベース２６の許容範囲管理テーブル２６２から取得する。第２判定部２２ｂは、取得した許容範囲をＳ４で取得した承認条件に適用してスコアに応じた承認条件の調整を行う。第２判定部２２ｂは、判定要求に含まれる取引情報が示す取引が調整後の承認条件を満たすか否かを判定する。調整後の承認条件を満たす場合（Ｓ５でＹＥＳ）、顧客管理データベース２５の顧客管理テーブル２５１において当該顧客の顧客ＩＤに対応付けられた連絡先に対し、取引の実行をスコアに基づいて許可した旨の通知を送信して、処理はＳ６に進められる。調整後の承認条件を満たさない場合（Ｓ５でＮＯ）、処理はＳ７に進められる。Ｓ５の処理は、「第２判定ステップ」の一例である。
【００６３】
ここで、顧客ＩＤ：ＣＣＣの顧客が送金を行う場合を例にとって、第２判定部２２ｂの判定処理について説明する。第２判定部２２ｂは、スコア管理テーブル２５２を参照して、顧客ＩＤ：ＣＣＣの顧客のスコア「１０」を取得する。第２判定部２２ｂは、許容範囲管理テーブル２６２を参照して、スコア「１０」に対応する許容範囲として「＋１０％」を取得する。第２判定部２２ｂは、取得した許容範囲「＋１０％」を顧客ＩＤ：ＣＣＣの上限金額と上限回数とに適用することで、承認条件の調整を行う。調整の結果、承認条件は、上限金額「２２万円」、上限回数「６回（小数点以下を四捨五入している）」となる。第２判定部２２ｂは、取引履歴テーブル２５３を参照して、顧客ＩＤ：ＣＣＣの顧客の累積金額（１か月）「１９万円」、累積回数（１か月）「４回」を取得する。既に送金または出金を行った金額「１９万円」に今回送金対象となる「２万円」を加算すると「２１万」となる。また、既に送金または出金を行った回数「５回」に今回の取引の回数を加算すると「６回」となる。金額および回数のいずれも、調整前の承認条件を満たさないものの、調整後の承認条件を満たす。そのため、第２判定部２２ｂは、この取引について肯定判定を行う。
【００６４】
続いて、顧客ＩＤ：ＢＢＢの顧客が送金を行う場合を例にとって、第２判定部２２ｂの判定処理について説明する。第２判定部２２ｂは、スコア管理テーブル２５２を参照して、顧客ＩＤ：ＢＢＢの顧客のスコア「０」を取得する。第２判定部２２ｂは、許容範囲管理テーブル２６２を参照して、スコア「０」に対応する許容範囲として「取引禁止」を取得する。「取引禁止」であるため、第２判定部２２ｂは、この取引について否定判定を行う。
【００６５】
Ｓ６では、指示部２４は、ＡＴＭ１から受信した問い合わせ要求に含まれる取引情報が示す取引の実行をＡＴＭ１に指示する。指示を受信したＡＴＭ１は、取引を実行する。Ｓ６の処理は、「実行ステップ」の一例である。
【００６６】
Ｓ７では、管理サーバ２の更新部２３は、スコアの更新を行う。更新部２３は、顧客管理データベース２５の取引履歴テーブル２５３の「累積金額（１か月）」、「累積金額（３か月）」のそれぞれに対して「２万円」を加算する。また、更新部２３は、取引履歴テーブル２５３の「累積回数（１か月）」、「累積回数（３か月）」のそれぞれに対して「１回」を加算する。なお、顧客管理データベース２５のスコア管理テーブル２５２については、本処理フローの例ではキャッシュカードや通帳の紛失、ロック解除の処理ではなく、取引回数および取引金額の乖離もないため、実施しない。Ｓ７の処理は、「更新ステップ」の一例である。
【００６７】
＜実施形態の作用効果＞
実施形態では、あらかじめ登録された取引条件に合致しない場合、それぞれの顧客に対して算出されるスコアに基づいて決定される許容範囲を用いて取引条件の調整を行う。スコアが高い（取引を安全に実行する能力が高い）顧客については許容範囲が広くなるため
、より広い範囲の取引が可能なように取引条件が調整される。そのため、スコアが高い顧客については、取引条件を少々逸脱しても取引の実行が可能になるため、顧客の利便性を高めることができる。一方、スコアが低い（取引を安全に実行する能力が高い）顧客については許容範囲が狭い、または、取引の実行が禁止される。そのため、スコアが低い顧客については、厳しい取引条件が適用され、または、取引の実行自体が禁止されるため、スコアの低い顧客の資産についての安全性を高めることができる。
【００６８】
実施形態では、調整した取引条件に基づいて取引を許可した場合、承認者に対して通知を行う。そのため、実施形態によれば、あらかじめ設定した取引条件の範囲外での取引が実行されたことを承認者に認識させることができる。
【００６９】
＜第１変形例＞
第１実施形態では、許容範囲外の取引は実行されない。第１変形例では、許容範囲外の取引であっても、顧客に設定される承認者から当該取引についての承認を得られる場合には取引を実行する構成について説明する。第１実施形態の同一の構成については同一の符号を付し、その説明を省略する。以下、図面を参照して、第１変形例について説明する。
【００７０】
図１４は、第１変形例に係る取引安全システムの処理ブロックの一例を示す図である。図１４に例示される取引安全システム５００ａは、管理サーバ２に代えて管理サーバ２ａを備える点で、第１実施形態に係る取引安全システム５００とは異なる。
【００７１】
管理サーバ２ａは、確認部２８をさらに備える点で、実施形態の管理サーバ２とは異なる。確認部２８は、第２判定部２２ｂが否定判定を行った場合に、当該取引を承認するか否かを承認者に確認する。確認部２８は、顧客管理データベース２５の顧客管理テーブル２５１を参照して、顧客ＩＤに対応付けられた承認者の連絡先を取得する。確認部２８は、取得した連絡先に対して、当該取引の承認の有無を問い合わせる確認依頼を送信する。確認依頼は、例えば、電子メールで送信される。確認部２８は、確認依頼への応答として承認する旨の通知を所定期間内に受信すると、当該取引の承認を得られたものとして肯定判定を行う。確認部２８は、所定期間内に承認依頼への応答を受信しない場合や、否認する旨の通知を所定期間内に受信すると、当該取引の承認を得られなかったものとして否定判定を行う。
【００７２】
図１５は、第１変形例に係る取引安全システムの処理フローの一例を示す図である。図１５に例示される第１変形例に係る取引安全システム５００の処理フローでは、Ｓ５の処理において否定判定されたのちにＴ１の処理が追加される点で、実施形態に係る取引安全システム５００の処理フローとは異なる。以下、図１５を参照して、第１変形例に係る取引安全システム５００の処理フローの一例について説明する。
【００７３】
Ｔ１では、管理サーバ２ａの確認部２８は、第２判定部２２ｂが否定判定を行った取引を承認するか否かを承認者に確認する。確認部２８は、顧客管理データベース２５の顧客管理テーブル２５１において顧客ＩＤに対応付けられた承認者連絡先を宛先として、取引を承認するか否かを確認する確認依頼を送信する。確認部２８が所定期間内に承認する旨の通知を承認者から受信すると（Ｔ１でＹＥＳ）、処理はＳ６に進められる。確認部２８が所定期間内に承認依頼への応答を受信しない場合や、否認する旨の通知を所定期間内に受信した場合（Ｔ１でＮＯ）には、処理はＳ７に進められる。
【００７４】
第１変形例では、許容範囲を超える取引であっても、そのことをもって取引が拒絶されず、承認者の承認が得られた場合には取引を実行できる。そのため、顧客の利便性を高めることができる。また、第１変形例において送信される確認依頼は取引が許容範囲内であれば送信されないため、第１変形例によれば、許容範囲外の取引を実行できる場合を用意
することで顧客の利便性を高めつつ、承認者の負担を軽減することができる。
【００７５】
＜第２変形例＞
実施形態および第１変形例に係る取引安全システムは、調整した取引条件に基づいて取引を許可した場合、承認者に対して通知を行う。第２変形例では、通知した承認者からフィードバックを受け、当該フィードバックを顧客のスコアに反映させる構成について説明する。
【００７６】
図１６は、第２変形例に係る取引安全システムの処理ブロックの一例を示す図である。第２変形例に係る取引安全システム５００ｂは、管理サーバ２に代えて管理サーバ２ｂを備える点で、実施形態に係る取引安全システム５００とは異なる。
【００７７】
管理サーバ２ｂは、算出基準データベース２７に代えて算出基準データベース２７ａを備えるとともに、更新部２３に代えて更新部２３ａを備える点で、実施形態の管理サーバ２とは異なる。算出基準データベース２７ａは、事後評価テーブルを備える点で、算出基準データベース２７と異なる。図１７は、第２変形例における算出基準データベースが有する事後評価テーブルの一例を示す図である。図１７に例示される事後評価テーブル２７６は、「加算スコア」、「評価」の各項目を含む。「評価」には、承認者による顧客に対する評価が格納される。「加算スコア」には、「評価」に応じて加算されるスコアが格納される。
【００７８】
更新部２３ａは、更新部２３の処理に加えて、承認者からのフィードバックに基づいて、顧客管理データベース２５に格納されるスコア管理テーブル２５２の「スコア」を調整する。更新部２３は、フィードバックを受信すると、事後評価テーブル２７６を参照して、受信したフィードバックに対応する「加算スコア」を取得する。更新部２３は、取得した「加算スコア」をスコア管理テーブル２５２の「スコア」に加算する。更新部２３は、例えば、承認者から「問題を感じない」とのフィードバックを受けると、事後評価テーブル２７６において「問題を感じない」との評価に対応する「加算スコア」として「２」を取得し、取得した「２」をスコア管理テーブル２５２の「スコア」に加算する。また、例えば、更新部２３は、承認者から「注意が必要」とのフィードバックを受けると、事後評価テーブル２７６において「注意が必要」との評価に対応する「加算スコア」として「０」を取得し、取得した「０」をスコア管理テーブルの「スコア」に加算する。フィードバックは、「評価結果」の一例である。
【００７９】
図１８は、第２変形例に係る取引安全システムのスコア調整処理の処理フローの一例である。図１８に例示される処理フローは、承認者からのフィードバックを受信したときに開始される。以下、図１８を参照して、第２変形例に係る取引安全システム５００ｂにおけるスコア調整処理の処理フローについて説明する。
【００８０】
Ｊ１では、管理サーバ２の更新部２３ａは、受信したフィードバックから承認者による評価を取得する。フィードバックは、例えば、図１３のＳ５で送信した、取引の実行をスコアに基づいて許可した旨の通知に対する応答として、承認者から送信される。
【００８１】
Ｊ２では、更新部２３ａは、Ｊ１で取得した評価対応する「加算スコア」を算出基準データベース２７ａの事後評価テーブル２７６から取得する。Ｊ３では、更新部２３ａは、顧客管理データベース２５に格納されるスコア管理テーブル２５２の「スコア」に対して、Ｊ２で取得した「加算スコア」の加算を行う。
【００８２】
第２変形例によれば、顧客の「スコア」に対して承認者からのフィードバックを反映させることができるため、「スコア」の信頼性を高めることができる。
【００８３】
＜その他の変形＞
以上説明した実施形態や変形例では、出金および送金を取引の例として説明した。しかしながら、実施形態や変形例における取引が出金や送金に限定されるわけではない。取引は、例えば、株式や投資信託、債券等の売買であってもよい。
【００８４】
以上説明した実施形態や変形例では、ＡＴＭ１によって取引が受け付けられたが、ＡＴＭ１以外の手段によって取引が受け付けられてもよい。取引を受け付ける手段として、例えば、公共交通機関の切符を販売する券売機、インターネットバンキング、キャッシュレジスター（例えば、店舗において店員が応対しない無人のキャッシュレジスター）等が挙げられる。
【００８５】
管理サーバ２の条件テーブル２６は、承認者が事前に個別の取引について承認した臨時条件をさらに記憶してもよい。臨時条件は、例えば、取引を許可する取引金額と当該取引を実行する取引予定日とを含む。このような構成を採用する場合、第１判定部２２ａは、判定要求に含まれる取引情報が示す取引が条件テーブル２６に記憶された取引条件を満たさない場合であっても、臨時条件を満たしていれば、肯定判定を行うことができる。また、第１判定部２２ａが取引条件および臨時条件のいずれも満たさないと判定した場合、第２判定部２２ｂは、取引条件の許容範囲内であるか臨時条件の許容範囲内であれば、肯定判定を行うことができる。このような構成によると、臨時条件についてもスコアに応じた許容範囲が考慮されるため、顧客の利便性を高めるとともに、承認者の負担を軽減することができる。なお、条件テーブル２６は、取引条件と臨時条件の少なくとも一方を記憶するものとしてもよい。
【００８６】
以上で開示した実施形態や変形例はそれぞれ組み合わせる事ができる。
【００８７】
<<コンピュータが読み取り可能な記録媒体>>
コンピュータその他の機械、装置（以下、コンピュータ等）に上記いずれかの機能を実現させる情報処理プログラムをコンピュータ等が読み取り可能な記録媒体に記録することができる。そして、コンピュータ等に、この記録媒体のプログラムを読み込ませて実行させることにより、その機能を提供させることができる。
【００８８】
ここで、コンピュータ等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的、または化学的作用によって蓄積し、コンピュータ等から読み取ることができる記録媒体をいう。このような記録媒体のうちコンピュータ等から取り外し可能なものとしては、例えばフレキシブルディスク、光磁気ディスク、Ｃｏｍｐａｃｔ  Ｄｉｓｃ  Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ（ＣＤ−ＲＯＭ）、Ｃｏｍｐａｃｔ  Ｄｉｓｃ−Ｒｅｃｏｒｄａｂｌｅ（ＣＤ−Ｒ）、Ｃｏｍｐａｃｔ  Ｄｉｓｃ−ＲｅＷｒｉｔｅｒａｂｌｅ（ＣＤ−ＲＷ）、Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｃ（ＤＶＤ）、ブルーレイディスク（ＢＤ）、Ｄｉｇｉｔａｌ  Ａｕｄｉｏ  Ｔａｐｅ（ＤＡＴ）、８ｍｍテープ、フラッシュメモリなどのメモリカード等がある。また、コンピュータ等に固定された記録媒体としてハードディスクやＲＯＭ等がある。
【符号の説明】
【００８９】
１・・・ＡＴＭ
１１・・・問い合わせ部
１２・・・取引実行部
２、２ａ・・・管理サーバ
２２ａ・・・第１判定部
２２ｂ・・・第２判定部
２３・・・更新部
２４・・・指示部
２５・・・顧客管理データベース
２５１・・・顧客管理テーブル
２５２・・・スコア管理テーブル
２５３・・・取引履歴管理テーブル
２６・・・条件データベース
２６１・・・条件テーブル
２６２・・・許容範囲管理テーブル
２７、２７ａ・・・算出基準データベース
２７１・・・属性テーブル
２７２・・・判断力スコアテーブル
２７３・・・ロック解除スコアテーブル
２７４・・・乖離率・回数スコアテーブル
２７５・・・乖離率・金額スコアテーブル
２７６・・・事後評価テーブル
３・・・窓口端末
３１・・・受付部
３２・・・報告部
５・・・ネットワーク環境
１０１、２０１、３０１・・・ＣＰＵ
１０２、２０２、３０２・・・主記憶部
１０３、２０３、３０３・・・補助記憶部
１０４、２０４、３０４・・・通信部
１０５・・・入出金部
１０６・・・格納庫
５００、５００ａ・・・取引安全システム
Ｂ１、Ｂ２、Ｂ３・・・接続バス
【図１】
2020154986.tif 000003
【図２】
2020154986.tif 000004
【図３】
2020154986.tif 000005
【図４】
2020154986.tif 000006
【図５】
2020154986.tif 000007
【図６】
2020154986.tif 000008
【図７】
2020154986.tif 000009
【図８】
2020154986.tif 000010
【図９】
2020154986.tif 000011
【図１０】
2020154986.tif 000012
【図１１】
2020154986.tif 000013
【図１２】
2020154986.tif 000014
【図１３】
2020154986.tif 000015
【図１４】
2020154986.tif 000016
【図１５】
2020154986.tif 000017
【図１６】
2020154986.tif 000018
【図１７】
2020154986.tif 000019
【図１８】
2020154986.tif 000020