以下、添付した図面を参照して、本発明の一実施形態に係る個人情報保護営業支援システムを詳細に説明する。図1は、本発明の一実施形態に係る個人情報保護営業支援システムを実現するコンピュータシステム全体の構成の例を示している。なお、本実施形態に係る個人情報保護営業支援サービスを、銀行などの金融機関の営業担当者(以下、「営業担当者」)と取引先との間で、リスク性金融商品の売買契約を結ぶ例に適用するが、そのような例に限定されない。また、売買の対象となる商品も、リスク性金融商品に限定されない。
<システム構成>
本実施形態に係る個人情報保護営業支援システムは、個人情報保護営業支援サーバ1、複数のタッチパネル端末2a、2b、・・・、2n(以下、「タッチパネル端末2」)、入力端末3および4を備えている。個人情報保護営業支援サーバ1とタッチパネル端末2とは、3GまたはLTEなどの通信方式を使用した無線ネットワークと、インターネットなどの公衆回線との組み合わせであるオープンネットワーク5を介して相互に接続されている。また、個人情報保護営業支援サーバ1と入力端末3および4とは、イントラネットなどのクローズドネットワーク6を介して相互に接続されている。
個人情報保護営業支援サーバ1は、本実施形態に係る個人情報保護営業支援サービスを提供する事業者(以下、「サービス事業者」)の下に設置され、個人情報保護営業支援サービスに係る主要な処理を実行するコンピューティングデバイスである。個人情報保護営業支援サーバ1は、本サービスを実現する単独のコンピューティングデバイスに実装されてもよく、または従来から存在する銀行システム(オンライン型口座開設サービスなどを提供するシステム)に実装されてもよい。また、個人情報保護営業支援サーバ1は、単独のコンピューティングデバイス(コンピュータサーバ)によって実装されてもよく、または複数のコンピューティングデバイス(コンピュータサーバ)を組み合わせることによって実装されてもよい。
タッチパネル端末2は、営業担当者が保有し、本実施形態に係る個人情報保護営業支援システムを利用するのに使用する携帯型クライアントコンピューティングデバイスである。営業担当者は、タッチパネル端末2の表示部に表示された取引先情報などに基づいて、取引先に対して営業活動を行い、タッチパネル端末2に対する操作を介して、金融商品の売買契約時の署名データなどを登録する。
入力端末3は、サービス事業者の下に設置され、営業担当者がスケジュール情報を入力するために使用する非携帯型クライアントコンピューティングデバイスである。例えば、営業担当者は、所定の取引先を訪問し、営業活動を行うが、その営業活動を行うに際して利用される取引先データなどを利用する予定日(スケジューリングデータ)を入力端末3から入力する。スケジュールデータの詳細は後述する。入力端末3は、サービス事業者のセキュリティポリシーの下、営業担当者が容易に持ち運びをすることができないように厳重に管理されている。入力端末4は、入力端末3と同様にサービス事業者の下に設置され、営業担当者の管理者または上司が営業担当者の訪問記録をチェックするために使用される端末であるが、詳細は後述する。
次に図2を参照して、本発明の実施形態に係る個人情報保護営業支援システムを構成するコンピューティングデバイスの詳細な構成の例を説明する。
個人情報保護営業支援サーバ1は、通信部11、制御部12、主記憶部13、および補助記憶部14を備えており、それらの各要素が相互に内部バスで接続されている。
通信部11は、オープンネットワーク5およびクローズドネットワーク6を介してそれぞれ接続されたタッチパネル端末2および入力端末3との間で、スケジュールデータなどのデータ、制御情報などを送受信する。タッチパネル端末2とのデータの送受信は、符号分割多元接続(CDMA:code division multiple access)、時分割多元アクセス(TDMA:time division multiple access)、周波数分割多元アクセス(FDMA:frequency division multiple access)、または直交周波数分割多元アクセス(OFDMA:orthogonal frequency division multiple access)などの方式で通信されてもよい。
制御部12は、中央処理装置(CPU:central processing unit)とも称され、個人情報保護営業支援サーバ1全体を制御する制御装置、演算装置、主記憶部13とのインタフェース、および周辺機器との入出力装置とのインタフェース、などを備える。制御部12は、上記各構成要素の制御およびデータの演算などを実行し、また、補助記憶部14に格納されている各種プログラムを主記憶部13に読み出して、各種処理を実行する。
主記憶部13は、メインメモリまたは一時記憶装置とも称され、制御部12が直接アクセスすることができる記憶装置である。制御部12は、主記憶部13に格納されている命令を読み取ることによって、各種処理を実行する。また、制御部12が頻繁に操作しているデータも同様の方法で、主記憶部13に格納される。
補助記憶部14は、ハードディスク(HDD:hard disk drive)などに代表される記憶装置であり、後述する取引先データテーブルなどを記憶したデータ記憶部(データベーステーブル)14aを有している。また、補助記憶部14は、制御部12に、本実施形態に係る各種処理を実行させるためのプログラム(図示せず)を格納している。なお、個人情報保護営業支援サーバ1は、データベースマネジメントシステム(DBMS:database management system)を実装し(図示せず)、当該DBMSを制御部12が実行することにより、利用者データテーブルなどのデータベーステーブルの読み出し、レコードの挿入・更新などが実行される。
タッチパネル端末2は、通信部21、制御部22、主記憶部23、補助記憶部24、タッチパネルディスプレイ25、およびカメラ26を備えており、それらの各要素がシステムバスを介して接続されている。
通信部21は、個人情報保護営業支援サーバ1から、オープンネットワーク5を介して、後述する取引先データとの間でデータを送受信する。また、通信部21は、個人情報保護営業支援サーバ1に、オープンネットワーク6を介して、顔画像データなどのデータを送信する。
制御部22は、中央処理装置であり、補助記憶部24に記憶された所定のプログラムを主記憶部23に読み出して、取引先データ参照処理などを実行する。また、制御部22は、上述した各要素の制御、データ演算などを実行する。
主記憶部23は、メインメモリであり、タッチパネル端末2が受信した入力データ、コンピュータ実行可能な命令および当該命令による演算処理後のデータなどを記憶している。
補助記憶部24は、ハードディスクなどの記憶装置であり、取引先データ参照処理などを実行するための所定のプログラムを記憶している。なお、そのようなプログラムは、予め、補助記憶部24に記憶されてもよく、または個人情報保護営業支援サーバ1からダウンロードしてもよい。
タッチパネルディスプレイ25は、個人情報保護営業支援サーバ1から受信した取引先データなどを表示し、営業担当者による所定の入力操作を、抵抗膜方式または静電容量方式などの技術を利用して検出する。タッチパネルディスプレイ25は、指またはスタイラスペンなどによって押圧されると、押圧された位置をX軸およびY軸の座標情報に変換し、押圧開始位置情報として制御部22へ送信する。タッチパネルディスプレイ25はまた、上記押圧が解除されると(指またはスタイラスペンなどを離す)、押圧が解除された位置をX軸およびY軸の座標情報に変換し、押圧終了情報として制御部22へ送信する。
カメラ26は、CCDまたはCMOSなどの撮像素子から構成されたデジタルカメラであり、営業担当者の顔を撮像する。カメラ26によって、営業担当者の顔(特徴パターン)を予め登録し、営業担当者の認証の際に営業担当者の顔を撮像し、登録された特徴パターンと一致するかを判定することによって、顔認証を行う。
次に、図3を参照して、本実施形態に係る個人情報保護営業支援システムが実行する処理の例を説明する。営業担当者は、担当する取引先宅または事業所などに訪問して、影響活動を行う際に使用する、取引先データを利用するスケジュールを決定し、そのスケジュールに従ってデータを使用し、商品説明および売買契約を行うものとする。
<スケジュール登録>
営業担当者は、入力端末3から、自身が担当する取引先に関するデータの利用予定日時、つまり、スケジュールデータを入力する。スケジュールデータは、入力端末3が所定のプログラムを実行することによって、表示部(図示せず)に表示されるスケジュールデータ入力インタフェースから入力される。
まず、営業担当者は、スケジュールデータ入力インタフェースの初期画面から、自身の識別番号(本実施形態では、営業担当者のサービス事業者において割り当てられた社員番号)を入力する。入力した識別番号は、個人情報保護営業支援サーバ1に送信される(ステップS301)。個人情報保護営業支援サーバ1の通信部11が、ステップS301で送信された識別番号を受信すると、制御部12が、その識別番号に基づいて営業担当者の認証を行う。認証が成功すると、制御部12が、当該識別番号に基づいて、取引先データテーブルから該当のレコードを取得する(ステップS302)。取得した取引先データレコードは、入力端末3に送信される。
取引先データテーブルとは、サービス事業者と以前に取引があった取引先情報を記憶したデータベーステーブルである。図4に取引先情報データテーブルの例を示す。取引先データテーブル400は、項目「取引先番号」、「店番号」、「氏名」、「住所」、「提案状況」および「社員番号」を含む。項目「提案状況」は、営業担当者が、該当の取引先に商品の提案を行ったか否かの状態を示しており、例えば、「0:なし」、「1:提案済み」などが設定される。本実施形態では、取引先番号および店番号の組み合わせで取引先を識別しているが、このような形式に限定されず、取引先を識別することが可能な単一の識別番号を割り当ててもよい。項目「社員番号」が、該当の取引先を担当している営業担当者の識別番号であり、取引先情報を登録する際に、営業担当者の識別番号と関連付けて登録される。
図3の説明に戻ると、ステップS303では、スケジュールデータ入力インタフェースの初期画面から、取引先選択画面500aに遷移する。図5にスケジュールデータ入力インタフェースの取引先選択画面500aおよびスケジュールデータ入力画面500bをそれぞれ示している。
取引先選択画面500aは、ステップS302で送信された取引先データレコードが表示され、その中から対象となる取引先を選択する画面である。営業担当者は、ステップS302で送信された取引先データレコード(つまり、自身の識別番号と関連付けられて登録されている取引先データ)のうち、案件管理データ(案件管理データの詳細は後述する)などの機密データの利用対象となる取引先を選択する(選択ボタンを押下する)。取引先を選択すると、スケジュールデータ入力画面500bに遷移する。
スケジュールデータ入力画面500bは、取引先選択画面500aで選択された取引先に関するデータを利用する予定日であるスケジュールデータを入力する画面である。図5に示すように、利用予定日を入力し確定ボタンを押下すると、スケジュールデータが生成され、生成されたスケジュールデータが、入力端末3から個人情報保護営業支援サーバ1に送信される(ステップS303)。スケジュールデータは、少なくとも、営業担当者識別番号(社員番号)、取引先識別番号(取引先番号および店番号)、および利用予定日時を含むが、これらの項目に限定されない。
個人情報保護営業支援サーバ1の通信部11が、ステップS303で送信されたスケジュールデータを受信すると、制御部12は、受信したスケジュールデータの利用予定日に基づいて、スケジュールデータテーブルにレコードを挿入する(ステップS304)。図6にスケジュールデータテーブルの例を示す。
図6は、スケジュールデータテーブル600aおよび情報利用可能管理データテーブル600bをそれぞれ示している。スケジュールデータテーブル600aは、営業担当者がステップS303で説明したようなスケジュールデータの入力に応じて生成される、スケジュール情報を記憶したデータテーブルである。情報利用可能管理データテーブル600bは、後述するバッチ処理によって、スケジュールデータテーブル600aのレコードからレコードが生成されるデータテーブルである。
図6に示すように、スケジュールデータテーブル600aは、ステップS303で受信したスケジュールデータの内容を記憶している。また、項目「処理成否」には、「0:なし」、「1:バッチ処理済み」などが設定される。
ステップS303におけるスケジュールデータテーブル600aへのレコードの追加は、入力端末3を介してのみ許可される。すなわち、営業担当者が自身のタッチパネル端末2を介してスケジュールデータを登録することができない。これは、外部で(つまり、サービス事業者の管理外で)、営業担当者による自由なスケジュールデータの登録を認めないことによって、取引先データなどの利用を最小限にしたものである。
上述したタッチパネル端末2によるスケジュールデータ登録の制限は、例えば、スケジュールデータテーブル600aにレコードを挿入するアプリケーションプログラムに対し、タッチパネル端末2のアクセスを制限する(ポート番号でフィルタリングする)ことによって実現してもよい。また、タッチパネル端末2からは直接アクセスすることができない別のコンピューティングデバイス(例えば、タッチパネル端末2からのアクセスをファイアウォール機能によってフィルタリングする)に、スケジュールデータテーブル600aを記憶することによって実現してもよい。
ステップS304のレコードの挿入では、スケジュールデータテーブル600aのレコードを参照して、同一の社員番号および同一の利用予定日のレコード数をカウントし、既にカウントしたレコード数が20である場合は、スケジュールデータテーブル600aにレコードを挿入せず、入力端末3にエラー応答を返す。つまり、同一の営業担当者が、同日の利用予定日とするスケジュールの入力を最大で20件までに制限している。なお、この20件の制限は例示的なものにすぎず、このような制限件数に限定されない。
図3の説明に戻ると、制御部12は、所定の定期的なタイミングで、スケジュールデータテーブル600aのレコードに基づいて、情報利用可能管理データテーブル600bにレコードを挿入する(ステップS305)。所定のタイミングとは、本実施形態では、日次夜間処理(バッチ処理)を想定しているが、その処理タイミングは特に限定されない。具体的には、バッチ処理の実行日を基準日として、実行日の翌々日となる日付が項目「利用予定日」に設定され、かつ項目「処理成否」に「0:なし」が設定されているスケジュールデータテーブル600aのレコードを抽出して、抽出したデータレコードを、情報利用可能管理データテーブル600bに挿入する。つまり、バッチ処理の実行日が利用予定日の2日前になる未スケジュールデータを、情報利用可能管理データとして、情報利用可能管理データテーブル600bに登録される。
図6のレコードの例で説明すると、バッチ処理の実行日が2015年7月14日の夜間の場合、利用予定日が2015年7月15日および2015年7月16日のレコードのみスケジュールデータ(項目「処理成否」に「0:なし」が設定されているレコード)が処理対象となる(利用予定日が2015年7月17日以降のレコードは処理対象外)。
なお、上記バッチ処理において、2日前のスケジュールデータを処理対象としているのは、バッチ処理がエラーとなった場合を考慮しているからである。仮にバッチ処理がエラーとなっても、その処理日の翌日(つまり、利用予定日の前日夜間)に再度のバッチ処理が実行されるので、バッチ処理のエラーが原因で、営業担当者が営業活動を行うことができなくなる事態を回避することができる。
情報利用可能管理データテーブル600bにレコードが挿入されると、挿入されたレコードに対応する、スケジュールデータテーブル600aのレコードの項目「処理成否」が「1:バッチ処理済み」に更新される。また、本バッチ処理において、情報利用可能管理データテーブル600bから、バッチ処理の実行日以前の利用可能日を有するレコード(つまり、利用可能日が経過したレコード)が削除される(システム日付などの実日付と利用可能日との比較に基づいて、削除するレコードを判定する)。
このように処理することによって、情報利用可能管理データテーブル600bには、利用可能日の2日前以降から利用可能日当日までのレコードのみが存在していることになる。なお、本実施形態では、2日前のレコードが登録の対象となっているが、この日数に限定されない。
<取引先データ参照>
上述したような情報利用可能管理データが作成されている状態で、営業担当者が、自身の保有するタッチパネル端末2を使用して、取引先に対し営業活動を行う際の取引先データを参照する例を、図3のステップS306から説明する。なお、営業担当者が営業活動を行う日付は、2015年7月15日であるものとする。
まず、営業担当者は、タッチパネル端末2のタッチパネルディスプレイ25から自身の社員番号を入力し、カメラ26を使用して自身の顔を撮像する。そして、通信部21が、入力した社員番号および撮像した画像データを、個人情報保護営業支援サーバ1に送信する(ステップS306)。
次に、個人情報保護営業支援サーバ1の通信部11がその社員番号および画像データを受信すると、それらに基づいて顔認証を実行する(ステップS307)。顔認証は、営業担当者の顔を撮像した特徴パターンを社員番号と関連付けて補助記憶部14に予め記憶しており、当該特徴パターンと特徴点などが一致するかを判定することによって実行される。なお、本ステップでの営業担当者の認証は、顔認証に限定されず、社員番号およびパスワードの入力などによる認証、ならびに指紋認証などの生体認証なども含む。
次に、制御部12は、当該社員番号と、本ステップを実行する日付(システム日付などの実日付)とに基づいて、情報利用可能管理データテーブル600bから該当のレコードを全て取得し、タッチパネル端末2に送信する(ステップS308)。ここで、情報利用可能管理データテーブルの項目「利用可能日」と実日付とが一致するレコードのみが取得される。
タッチパネル端末2の通信部21が、ステップS308で送信された情報利用可能管理データレコードを取得すると、そのデータレコードがタッチパネルディスプレイ25の取引先情報表示インタフェースに表示される。
図7に、タッチパネル端末2のタッチパネルディスプレイ25に表示された取引先情報表示インタフェースの例を示す。上述したように、営業担当者が営業活動を行う日付が2015年7月15日であるので、取引先選択画面700aには、ステップS305において情報利用可能管理データテーブル600bに挿入されたレコードのうち、利用可能日に2015年7月15日が設定されたレコードのみが表示される。
取引先選択画面700aで、対象の取引先を選択すると、その選択された取引先の識別番号が個人情報保護営業支援サーバ1に送信される(ステップS309)。個人情報保護営業支援サーバ1の通信部11がその識別番号を受信すると、取引先データテーブル400から該当のレコードを取得し、タッチパネル端末2に送信する(ステップS310)。
タッチパネル端末2の通信部21が、ステップS310で送信された取引先データレコードを取得すると、図7に示す案件選択画面700bに遷移する。案件選択画面700bにおいて、対象の案件を選択すると、その選択された案件の取引先識別番号、提案状況および利用可能日などが個人情報保護営業支援サーバ1に送信される(ステップS311)。個人情報保護営業支援サーバ1の通信部11がその取引先識別番号などを受信すると、それらに基づいて、案件進捗管理データテーブルから該当のレコードを取得し、タッチパネル端末2に送信する(ステップS312)。
図8に案件進捗管理データテーブル800の例を示す。案件進捗管理データテーブル800は、取引先ごとに営業担当者が提案状況などを管理するデータテーブルである。案件進捗管理データテーブル800は、項目「社員番号」、「取引先番号」、「店番号」、「氏名」、「案件番号」、「ステータス」、および「電子サインデータ」を含む。項目「ステータス」は対象となる案件のステータスを示しており、例えば、「0:提案なし」、「1:提案済み」、「2:取引成立」などが設定される。項目「電子サインデータ」は、後述する電子サインデータのイメージファイルの格納先およびファイル名を示している。案件進捗管理データテーブル800は、他に、取引先および案件の対象となる商品に関するデータが含まれることになるが、それらのデータは、図8では省略する。
タッチパネル端末2の通信部21が、ステップS312で送信された取引先データレコードを取得すると、図7に示す取引先詳細情報入力画面700cに遷移する。営業担当者は、取引先詳細情報入力画面700cにおいて、対象の取引先に対する対象の案件に対する詳細情報を入力することになる(職業、年収など)。なお、図示していないが、取引先情報表示インタフェースにおいて、重要事項などの欄が表示され、営業担当者はその重要事項を取引先に参照させて、重要事項を取引先に説明する。
なお、このタッチパネル端末2のタッチパネルディスプレイ25に表示された案件進捗管理データレコードの情報は、紙による印刷、データファイルなどへの出力など、取引先情報を画面表示すること以外にデータを出力することができないよう、制御部22によって制御される。このようにして、取引先情報をディスプレイ画面から参照する以外の手段で、営業担当者が取引先情報を利用することを防止することができる。
図7で説明した取引先情報表示インタフェースにおいて表示された情報を参照し、また詳細情報を入力することによって、図9に示す承認画面(取引先画面)900aに遷移する。承認画面(取引先画面)900aは、取引先が重要事項の説明を受けたことの記録を残すために、取引先がチェックなどを行うための入力画面である。承認画面(取引先画面)900aにおいて、取引先が、チェック欄901a、901bおよび901cにチェックをし、署名欄902に指またはスタイラスペンなどを使用して、サインを行い、確定ボタン903を押下すると、承認画面(担当者画面)900bに遷移する。
図9に示す承認画面(担当者画面)900bは、営業担当者が、取引先からの承認を受けたことの記録を残すために、営業担当者がチェックなどを行うための入力画面である。承認画面(担当者画面)900bにおいて、営業担当者が、チェック欄904a、904bおよび904cにチェックをし、確定ボタン905を押下すると、営業担当者が取引先に対して重要事項の説明などを行ったことの記録として、上記説明した取引先詳細情報、チェック欄にてチェックしたことを示すインジケータ、および署名欄902において入力した電子サインデータなどが、個人情報保護営業支援サーバ1に送信される(ステップS313)。
個人情報保護営業支援サーバ1の通信部11が、ステップS313で送信された電子サインデータなどを受信すると、制御部12は、案件進捗管理データテーブル800の対象のレコードに対し、項目「ステータス」を「1:提案済み」に更新する。また、項目「電子サインデータ」を受信した電子サインデータの格納先ディレクトリ(補助記憶部14内の)およびファイル名で更新する(ステップS314)。また、取引先データテーブル400の対象のレコードに対し、項目「提案状況」を「1:提案済み」に更新する。
タッチパネル端末2では、取引先選択画面700a、案件選択画面700b、取引先詳細情報入力画面700c、および承認画面(取引先画面)900aなどの、それぞれの画面上で表示されるデータは、補助記憶部24には記憶されず、主記憶部23(キャッシュ)のみに記憶される。そして、上述した画面間で遷移する都度、キャッシュに記憶されたデータが削除される。また、上記画面で一定の時間が経過すると、自動でログアウトするよう制御される。
このようにして、タッチパネル端末2においては、取引先データなどの機密情報を一切残さないので、営業担当者による機密情報の不正利用を防止することができる。なお、上述した取引先選択画面700aなどの各画面間で遷移する際に、タッチパネル端末2内には一切のデータが削除されるので、遷移後の画面で再度、取引先データなどを表示する際は、その都度、個人情報保護営業支援サーバ1から情報を取得する。
なお、ステップS308で取引先データレコードが取得されてから、その取引先データレコードが削除されるまでの時間(タッチパネル端末2が、取引先データレコードを削除したことを示すインジケータを、個人情報保護営業支援サーバ1に送信する)を個人情報保護営業支援サーバ1上でログファイル(以下、「参照履歴ログ」)に記録することによって、営業担当者が取引先情報を参照した時間を記録に残すことができる。
参照履歴ログは、例えば、以下の表1に示す項目を記録してもよい。
タッチパネル端末で表示される複数の画面の各々(画面遷移によって各々が表示される)には、各々の画面を識別するための画面識別子が割り当てられている。この割り当てられた識別番号によって、営業担当者がどの画面を参照したかを記録することができる。なお、参照履歴ログは、営業担当者および参照された取引先ごとに1件のデータレコードが記録される。
以上述べたように、サービス事業者の下に設置された入力端末3を介して入力されたスケジュールデータを通じて、タッチパネル端末2からの取引先情報へのアクセスを行っているので、営業担当者は、サービス事業者内でのみ登録したスケジュールデータから作成された情報利用可能管理データに対応する取引先情報しか原則として利用することができない。このように制御することによって、営業担当者による不正な顧客情報の利用を防止することができる。
また、営業担当者が登録したスケジュールデータを、最大で2日分のみのレコードが存在する情報利用可能管理データテーブル600bから取得するので、営業担当者が悪意で大量の顧客データを利用することを防ぐことができる。また、スケジュールデータテーブル600aは、利用予定日ごとに、最大で20件までのレコードのみの登録を許可しているので(その制約に伴って、情報利用可能管理データテーブル600bへのレコードも、利用可能日ごとに20件までしか作成されない)、やはり悪意で大量の顧客データを利用することを防ぐことができる。
次に、図10を参照して、図3で説明した営業担当者による営業活動に応じて、営業担当者と取引先との間で取引が成立するまでに実行される処理を説明する。通常、営業担当者が取引先に訪問し、重要事項の説明を行い、それに対して取引先からの承認を受けてから、後日、取引先に再度訪問し、取引が成立することになる。リスク性商品は、取引先に十分に検討する時間を与える目的で、取引が後日となることが多い。
図10のフローチャートのステップS1001〜S1012、およびS1017〜S1018は、図3で説明した各ステップS301〜S312、およびS313〜S314にそれぞれ対応するので、説明は省略する。なお、本実施形態では、既に取引先への提案を行っているので、ステップS1003におけるスケジュールデータの入力では、対象の案件について、案件進捗管理データテーブル800を参照し、その案件のステータスを引き継いで、スケジュールデータを入力することができる。
このようにして、再度の取引先への訪問を行う場合、係属した案件がある場合、その案件のステータスを個人情報保護営業支援サーバ1上で管理しているので、そのステータスから再度のスケジュール入力を行うことができる。
ステップS1013では、取引先に、取引成立に対する承認として、図3のステップS313と同様に、取引先からのチェックおよび署名をもらうことになるが、その際に、取引先の認証を行う。具体的には、タッチパネル端末2のタッチパネルディスプレイ25に表示された画面に取引先識別番号(本実施形態では、取引先番号および店番号)および所定のパスワードを入力し、個人情報保護営業支援サーバに送信される(ステップS1013)。個人情報保護営業支援サーバの通信部11が、そのパスワードなどを受信すると、制御部12が、第1の認証を行う(ステップS1014)。
第1認証が成功すると、再度、所定の桁数の暗証番号入力欄が表示され、当該暗証番号を入力し、個人情報保護営業支援サーバに送信される(ステップS1015)。個人情報保護営業支援サーバの通信部11が、その暗証番号を入力すると、制御部12が第2の認証を行う(ステップS1015)。いずれの場合も、営業担当者が暗証番号などを除き見ることがないよう、入力画面において、例えば、「覗き見防止シートを装着して下さい」などと、覗き見防止シートの装着を促す表示を行ってもよい。
上記認証において、タッチパネル端末2に近接センサー(図示せず)を実装し、タッチパネルディスプレイ25の所定の方向からの営業担当者の接近を検出したことによって、タッチパネルディスプレイ25に表示された画面を見えなくさせるようにしてもよい(例えば、別の画面をオーバレイする、取引先情報をマスキングするなど)。このように制御することによって、営業担当者が取引先の暗証番号などを覗き見ることを防止することができる。
図9における処理では、最終的に取引先との間で取引が成立することになるので、ステップS1018での案件進捗管理データテーブル800のレコードの更新では、項目「ステータス」に「2:取引成立」などが設定され、これによって、該当の案件が終了する。
上記説明では、スケジュールデータを入力し、バッチ処理によって情報利用可能管理データテーブル600bにレコードが挿入されているが、緊急案件の場合などのために、タッチパネル端末2から、情報利用可能管理データテーブル600bに直接レコードを挿入することができるように制御してもよい。この場合でも、同日の利用可能日のデータを20件までしか登録することができず、かつレコードの削除を排除するように制御される。
<訪問実績チェック>
次に、営業担当者による取引先データレコードの参照履歴と、取引先への訪問実績とのチェック処理の実施形態の例を、図11を参照して説明する。営業担当者が取引先に訪問して、商品の説明・取引を行うと(つまり、その訪問の過程で、対象の取引先データレコードが参照される)、営業担当者は営業所へ戻り、自身が取引先に訪問したことを示す訪問実績データを生成する必要がある。
訪問実績情報は、図12に示す訪問実績情報入力インタフェースから入力される。訪問実績情報入力インタフェースは、入力端末3の表示部に表示される。図12に示すように、訪問実績情報入力インタフェースは、取引先選択画面1200aおよび訪問実績データ入力画面1200bを有している。
まず、営業担当者は、自身の社員番号で認証して、訪問実績情報入力インタフェースにログインする。ログインすると、初期画面が表示され(図示せず)、その初期画面において、訪問実績データを生成する対象となる日付(つまり、営業担当者が実際に取引先を訪問した日付(以下、「訪問日付」)を入力する。
上記入力端末3において入力された社員番号および訪問日付が個人情報保護営業支援サーバ1に送信される(ステップS1101)。そして、個人情報保護営業支援サーバ1の制御部12が、受信した社員番号および訪問日付に基づいて、スケジュールデータテーブル600aから対象のレコードを取得して、入力端末3に送信する(ステップS1102)。
入力端末3上では、取引先選択画面1200aに遷移して、対象の取引先の一覧が表示される。このような状態で、営業担当者が取引先を選択すると、訪問実績データ入力画面1200bに遷移する。
訪問実績データ入力画面1200bは、取引先選択画面1200aで選択された取引先を、営業担当者が実際に訪問した日付を入力する画面である。図12に示すように、訪問日および訪問開始終了日時を入力し確定ボタンを押下すると、訪問実績データが生成され、生成されたスケジュールデータが、入力端末3から個人情報保護営業支援サーバ1に送信される(ステップS1103)。訪問実績データは、少なくとも、営業担当者識別番号(社員番号)、取引先識別番号(取引先番号および店番号)、訪問日時、および登録日(実際に営業担当者が訪問実績データを入力した日付、システム日付などの実日付。)を含むが、これらの項目に限定されない。
個人情報保護営業支援サーバ1の通信部11が訪問実績データを受信すると、制御部12が、その訪問実績データを、訪問実績データテーブル1300に挿入する(ステップS1104)。図13に、訪問実績データテーブル1300の例を示す。
図13に示すように、訪問実績データテーブル1300は、項目「登録日」、「社員番号」、「取引先番号」および「店番号」を含む。これらの項目は、上述した訪問実績データのそれぞれの値が設定される。なお、訪問実績データテーブル1300は、訪問日時などの項目も有しているが、本実施形態における訪問実績チェック処理において使用される項目ではないので省略する。
このようにして、営業担当者による訪問実績が、訪問実績データテーブル1300において管理されることになるが、この訪問実績データの入力は、訪問日の当日、または翌日もしくは翌営業日までに行われる必要があるが、詳細は後述する。
なお、上述した訪問実績データの登録は、所定の条件の下に入力を認めるように制御してもよい。例えば、案件進捗管理データテーブル800の項目「電子サインデータ」に電子サインのイメージデータが記憶されているか否かによって(つまり、上記説明した承認画面(取引先画面)900aの署名欄902でサインがされているか)、訪問実績データの入力を受け付け、または拒否してもよい。代替として、案件進捗管理データテーブル800の項目「ステータス」、または取引先データテーブル400の項目「提案状況」の値によって、訪問実績データの入力を制御してもよい。
次に、個人情報保護営業支援サーバ1の制御部12は、取引先データレコードが参照された当日の夜間バッチ処理によって、上述した参照履歴ログに基づいて参照履歴データテーブル1400にレコードを挿入する(ステップ1105)。図14に参照履歴データテーブル1400の例を示す。
参照履歴データテーブル1400は、項目「参照日」、「参照時間」、「社員番号」、「取引先番号」、「店番号」、「監査内容1」、「監査内容2」、「監査内容3」、「監査内容4」および「査閲フラグ」を含む。項目「参照日」、「参照時間」、「社員番号」、「取引先番号」、「店番号」はそれぞれ、参照履歴ログで記録された内容が設定される。項目「監査内容1」、「監査内容2」、「監査内容3」、および「監査内容4」については、例えば、表2に示すように値が設定されてもよい。
上述したように、参照履歴データテーブル1400にレコードが挿入されることによって、営業担当者による情報利用可能管理データレコードの参照履歴を管理することができる。
このように、訪問実績データテーブル1300および参照履歴データテーブル1400が登録された状態で、それらのデータレコード双方の関連付けチェック処理が実行される。まず、個人情報保護営業支援サーバ1の制御部12は、日次のバッチ処理によって、参照履歴データテーブル1400から対象のレコードを全て取得する(ステップS1106)。ここで、取得されるレコードは、バッチ処理が実行される実日付の1日前または1営業日前の日付が、項目「参照日」に設定されているレコードである。つまり、取引先データレコードを参照することによって生成された参照履歴データレコードが、その翌日または翌営業日に訪問実績との関連付けチェックがされる。
次に、制御部12は、ステップS1106で取得した参照履歴データレコードに含まれる項目「取引先番号」、「店番号」および「社員番号」に基づいて、取引先データテーブル400から対象のレコードを全て取得する(ステップS1107)。この処理によって、1日前または1営業日前に参照された取引先データレコードに対応する取引先を特定することができる。
次に、制御部12は、ステップS1107で取得した取引先データレコードに含まれる項目「取引先番号」および「店番号」に基づいて、訪問実績データテーブル1300から対象のレコードを全て取得する(ステップS1108)。この処理によって、1日前または1営業日前に参照された取引先データレコードに対応する取引先への訪問実績を特定することができる。
次に、制御部12は、ステップS1106で取得した参照履歴データレコード、およびステップS1108で取得した訪問実績データレコードのそれぞれの項目を参照して、後述するアラート対象になるか否かを、レコードごとに判定する(ステップS1109)。ここで、アラート対象になるか否かは、本バッチ処理の実行日(システム日付などの実日付)を基準に、表3に示すように判定される。
表3によって判定することによって、図15に示すように、営業担当者が取引先を訪問してから、その当日または翌日(もしくは翌営業日)以内に訪問実績データの登録(訪問実績登録)が行われない場合、アラート対象になる(つまり、訪問実績登録がされていない場合、または訪問日から翌々日(もしくは翌営業日)以降に訪問実績登録がされた場合)。
ステップS1109でアラート対象のレコードが存在した場合、上記アラート対象となった営業担当者の訪問実績を管理する社員(例えば、営業担当者の管理者または上司、以下「査閲者社員」)が、アラート対象となったことを、図16に示すアラートデータ表示インタフェース1600上で確認することができる。アラートデータ表示インタフェース1600は、査閲者が有する入力端末4の表示部に表示される画面インタフェースである。
具体的には、査閲者社員は入力端末4の表示部に表示された認証画面(図示せず)で、自身の社員番号で認証し(査閲者社員番号は、個人情報保護営業支援サーバ1に送信される)、個人情報保護営業支援サーバ1の制御部12が、その社員番号に基づいて、社員データテーブル1700から対象のレコードを取得する(S1110)。社員データテーブルは、図17に示すように、営業担当者の社員番号と査閲者社員とを関連付けて登録されたデータベーステーブルである。社員データテーブル1700によって、査閲者社員が査閲対象となる営業担当者を特定することができる。
社員データレコードが取得されると、制御部12は、社員データレコードの含まれる「社員番号」に基づいて、制御部12は、ステップS1106で取得した参照履歴データおよびステップS1108で取得した訪問実績データからアラート対象データを作成する(ステップS1120)。このアラート対象データは、少なくとも、ステップS1106で取得した参照履歴データレコードに含まれる項目「監査内容1」、「監査内容2」、「監査内容3」および「監査内容4」、ならびにステップS1110で取得した社員データレコードに含まれる項目「社員番号」および「氏名」などを含む。
次に、制御部12は、ステップ1109でアラート対象と判定された件数を営業担当者ごとに集約し、ステップS1106で取得した参照履歴データレコードに含まれる項目「監査内容1」、「監査内容2」、「監査内容3」および「監査内容4」、ならびにステップS1110で取得した社員データレコードに含まれる項目「社員番号」および「氏名」などを付加して、査閲者社員の入力端末4に送信する(ステップS1130)。
このようにして、図16に示すようにアラートデータが査閲者の入力端末4の表示部に表示される。アラートデータ表示インタフェース1600は、検知日、営業担当者、検知内容および件数を表示する。件数は、ステップS1109でアラート対象と判定されたレコードの件数が表示される。検知内容は、ステップS1109でアラート対象と判定されたアラートの内容が表示される。アラートデータ表示インタフェース1600において、一の営業担当者を選択すると、詳細画面に遷移し、アラート対象と判定された内容が表示される(例えば、参照履歴データの項目「監査内容4」に基づいて、営業担当者が参照して画面名などが表示される)。
なお、上述したように、ステップS1109においてアラート対象と判定された場合、査閲者社員はアラートデータ表示インタフェース1600を通じてアラートデータを確認する必要があるが、一定期間にその参照がされない場合、査閲者社員の入力端末4を介して警告を送信してもよい。具体的には、ステップS1130において制御部12がアラートデータを送信した場合、参照履歴データテーブル1400の「査閲フラグ」が更新され、その項目が一定期間を経過しても更新されない場合、ステップS1110で取得した社員データレコードに含まれる「査閲者アドレス」に警告メールを送信してもよい。
また、アラートデータ表示インタフェース1600が表示されることになる入力端末4は、上述したようなサービス事業者の下に設置される非携帯型端末の形式に限定されず、例えば、タッチパネル端末2のように、オープンネットワーク5を介して個人情報保護営業支援サーバ1と接続された携帯型端末の形式であってもよい。
このようにして、取引先データレコードを参照した営業担当者は、そのレコードに対応する取引先への訪問実績を登録しない限り、アラート対象とみなされて査閲者に報告されることになる。この構成によって、営業担当者は訪問予定がないにも関わらず取引先データレコードを参照するといった不正利用を軽減することができる。また、訪問実績データは、入力端末3からのみ登録を行えるので、営業員が外出先でタッチパネル端末2を使用してデータの参照・登録を繰り返すといった不正行為も防止することができる。なお、上記効果とは逆に、営業担当者の便宜を考慮して、タッチパネル端末2から訪問実績データの登録を行えるようにしてもよい。
以上のように、本実施形態に係る決済方法の説明を詳述したが、実施形態で説明した、取引先データテーブル400およびスケジュールデータテーブル600aなどの具体的なデータ構造は例示的なものにすぎず、特許請求する事項から逸脱しない範囲で変更がされてもよい。また、図3および図10で説明したフローチャートの順序は、特許請求する事項から逸脱しない範囲で変更されてもよく、一部のステップが除外されてもよい。さらに、本実施形態では、銀行などの金融機関がリスク性商品を販売する際の取引先情報を参照する例を説明したが、対象とする情報はこのような情報に限定されず、機密性の高い情報に広く適用される。