JP2019153139A - 特殊詐欺防止システム及び方法 - Google Patents

Abstract

【課題】通話の設定時間内における詐欺用語データの発現度から詐欺の危険度を判定する技術があるが、振り込め詐欺において使用される言葉は様々であり、そのような様々な言葉を予め登録しておくことは困難である。【解決手段】サーバシステムが、第１の者により第１の情報処理端末に入力され金銭の引出し及び移動のうちのいずれかに関する１以上のリクエストパラメータを受け付け、その１以上のリクエストパラメータの少なくとも一部を見てリクエスト実行許否を回答することの依頼である回答依頼を、第２の者の情報処理端末に送信する。サーバシステムは、回答がリクエスト実行拒否を表す場合、上記１以上のリクエストパラメータに従うリクエストを非実行とする。【選択図】図６

Description

本発明は、概して、特殊詐欺の防止のための技術に関する。

振り込め詐欺の防止に関する技術として、特許文献１の技術が知られている。特許文献１によれば、通話の設定時間内における詐欺用語データの発現度から詐欺の危険度を判定することができる。

特許第６１１９０３２号明細書

振り込め詐欺において使用される言葉は様々であり、そのような様々な言葉を予め登録しておくことは困難である。

また、特許文献１の発明は、電話を利用する振り込め詐欺にのみ有効であり、電話以外の方法が使用される振り込め詐欺や、振り込め詐欺以外の特殊詐欺を防ぐことはできない。

なお、警察庁によれば、「特殊詐欺」とは、面識のない不特定の者に対し、電話その他の通信手段を用いて、預貯金口座への振込みその他の方法により、現金等をだまし取る詐欺をいい、振り込め詐欺（オレオレ詐欺、架空請求詐欺、融資保証金詐欺及び還付金等詐欺）及び振り込め詐欺以外の特殊詐欺（金融商品等取引名目の特殊詐欺、ギャンブル必勝情報提供名目の特殊詐欺、異性との交際あっせん名目の特殊詐欺及びその他の特殊詐欺）を総称したものを言う。

電話等を受けた本人がたとえ騙されてもその本人の現金等の金銭が不特定の者に渡ることを防ぐ。具体的には、サーバシステムが、第１の者（典型的には本人）により第１の情報処理端末に入力され金銭の引出し及び移動のうちのいずれかに関する１以上のリクエストパラメータを受け付ける。サーバシステムが、受け付けた１以上のリクエストパラメータの少なくとも一部を見てリクエスト実行許否を回答することの依頼である回答依頼を、第２の者の情報処理端末である第２の情報処理端末に送信する。サーバシステムが、第２の情報処理端末からリクエスト実行許否に関する回答を受け付ける。サーバシステムが、上記受け付けた回答がリクエスト実行拒否を表す回答の場合、上記受け付けた１以上のリクエストパラメータに従うリクエストを非実行とする。

現金等の金銭が不特定の者に渡ることを防止でき、結果として、特殊詐欺を防止できる。

実施例１に係るクライアントサーバシステム全体の構成を示す。 ユーザ操作管理情報の構成を示す。 実施例１に係るオンライン送金の流れを示す。 図３の流れにおける画面遷移の一例を示す。 実施例２に係るオンライン送金の流れを示す。 実施例３に係る特殊詐欺防止システムの一例を示す。 ＡＴＭの画面遷移の一例を示す。 スマホの画面遷移の一例を示す。

以下、本発明の幾つかの実施例を説明する。

なお、本発明の幾つかの実施例に係る特殊詐欺防止システムは、実施例１〜実施例３に例示のリクエスト実行制御技術、具体的には、中間者攻撃（例えばＭＩＴＢ（Man In The Browser））と呼ばれる攻撃により不正な送金金額が不正な送金先に振り込まれてしまうことを防止する技術を応用することで実現することが期待できる。

そこで、まず、リクエスト実行制御技術の実施例１及び２を説明する。なお、実施例１及び２において、「ユーザ端末」は、通信機能を有する情報処理端末であり、例えば、デスクトップ型又はモバイル型のパーソナルコンピュータ、スマートフォンのようなスマートデバイス、又は携帯電話機等がある。

図１は、実施例１に係るクライアントサーバシステム全体の構成を示す。

本実施例では、各ユーザは、複数のユーザ端末、例えば第１及び第２ユーザ端末を使用して、サーバシステム１３が提供するサービスを使用する。言い換えれば、サーバシステム１３は、第１ユーザ端末から入力された第１情報と、第２ユーザ端末から入力された第２情報とを使用して、送金を実行する。第１ユーザ端末の一例が、デスクトップ型のＰＣ（Personal Computer）１２であり、第２ユーザ端末の一例が、携帯端末１１である。ＰＣ１２及び携帯端末１１が、オンライン送金のようなサービスを提供するサーバシステム１３と、通信ネットワーク（例えばインターネット）を介して通信する。

ＰＣ１２は、記憶デバイス１２１と、通信インターフェースデバイス１２３と、入力デバイス１２５と、表示デバイス１２４と、それらに接続されたプロセッサ１２２とを有する。入力デバイス１２５は、ユーザが情報を入力するために使用するデバイスであり、例えば、キーボード及びポインティングデバイスである。表示デバイス１２４は、情報を表示するデバイスであり、例えば液晶表示デバイスである。「記憶デバイス」は、本実施例において、１以上の記憶デバイスの集合を意味し、主記憶デバイス（例えば揮発性又は不揮発性のメモリ）と、補助記憶デバイスとのうちの少なくとも主記憶デバイスを含んでよい。補助記憶デバイスは、例えば、ＨＤＤ（Hard Disk Drive）及びＳＳＤ（Solid State Drive）のうちの少なくとも一方でよい。「通信インターフェースデバイス」は、本実施例において、１以上の通信インターフェースデバイスの集合を意味し、通信ネットワークを介して外部装置と無線通信又は有線通信する。「プロセッサ」は、本実施例において、１以上のプロセッサの集合を意味し、それぞれのプロセッサは典型的にはマイクロプロセッサ（例えばＣＰＵ（Central Processing Unit））でよく、少なくとも１つのプロセッサが、処理の一部（例えば暗号化又は復号化）を行う専用ハードウェア回路（例えばＡＳＩＣ（Application Specific Integrated Circuit））を含んでもよい。

携帯端末１１は、携帯型のユーザ端末であり、例えば、スマートフォンである。スマートフォンは、スマートデバイスの一種である。スマートデバイスは、単なる計算処理だけではなく、多種多様な用途に使用可能な多機能のデバイスであり、典型的には、iPhone（登録商標）のようなスマートフォン、及び、iPad（登録商標）のようなタブレットＰＣである。携帯端末１１は、タッチパネル型ディスプレイ１１１と、記憶デバイス１１３と、通信インターフェースデバイス１１４と、それらに接続されたプロセッサ１１２とを有する。タッチパネル型ディスプレイ１１１は、入力デバイスと表示デバイスが一体になったデバイスである。

サーバシステム１３は、１以上の計算機であり、記憶デバイス１３１と、通信インターフェースデバイス１３３と、それらに接続されたプロセッサ１３２とを有する。サーバシステム１３は、１以上のサーバを含んだシステムでよい。その１以上のサーバは、物理サーバであっても仮想サーバであってもよい。プロセッサ１３２が、ユーザ認証及びデバイス認証のうちの少なくとも１つの認証を行うサービスを提供してもよい。例えば、プロセッサ１３２が、ＰＣ１２についてはユーザ認証によりユーザの正当性（サーバシステム１３に対してユーザ登録済のユーザであるか否か）をチェックし、携帯端末１１についてはデバイス認証より携帯端末１１の正当性（サーバシステム１３に対してデバイス登録済のデバイスであるか否か）をチェックしてもよい。つまり、プロセッサ１３２は、同一ユーザについて、デバイス登録されたユーザ端末以外のユーザ端末の一例であるＰＣ１２と、デバイス登録されたユーザ端末の一例である携帯端末１１と通信する。また、プロセッサ１３２は、オンライン送金サービスを提供する。具体的には、例えば、記憶デバイス１３１が、ユーザ毎に送金元口座情報を記憶し、且つ、ユーザ操作管理情報を記憶してよい。

図２は、ユーザ操作管理情報の構成を示す。

ユーザ操作管理情報２００は、例えばテーブルであり、プロセス（ユーザによる操作に従い入力されたリクエストパラメータが指定されることになるリクエスト）毎にレコードを有する。各レコードは、プロセスＩＤ２０１、ユーザＩＤ２０２、リクエスト種類２０３、送金元口座情報２０４、送金先口座情報２０５、送金金額２０６及び状態２０７を有する。プロセスＩＤ２０１は、プロセスのＩＤである。ユーザＩＤ２０２は、プロセスに対応したユーザのＩＤである。リクエスト種類２０３は、ユーザにより行われた操作に従うリクエスト種類（例えば、送金、残高照会等）を表す情報である。送金元口座情報２０４は、リクエストパラメータの一例であり、ユーザに対応した送金元口座を表す情報である。送金先口座情報２０５は、リクエストパラメータの一例であり、送金先口座を表す情報である。送金元口座情報２０４及び送金先口座情報２０５は、それぞれ、例えば、銀行名、支店名、口座種類（例えば、普通、当座）、口座番号及び口座名義人名を含む。リクエストパラメータ２０４及び２０５のうちの各々について、全てのパラメータ要素がユーザにより入力されてもよいし、一部のパラメータ要素がユーザにより入力され一部のパラメータ要素から残りのパラメータ要素がサーバシステム１３のプロセッサ１３２により取得されてもよい。送金金額２０６は、リクエストパラメータの一例であり、送金する金額を表す。状態２０７は、プロセスの状態（例えば、未処理、処理中及び処理済のいずれであるか）を表す。

本実施例では、送金元口座情報は、ＰＣ１２を使用してログインしたユーザのユーザ情報（例えばユーザ認証において使用される情報でありユーザ登録において登録されたユーザＩＤ及びパスワード）に関連付けられている情報でよく、送金先口座情報は、携帯端末１１を使用するユーザにより入力された情報（例えば、銀行名、支店名、口座種類及び口座番号）と、その情報から取得された情報（例えば口座名義人名）とを含んだ情報でよい。サーバシステム１３のプロセッサ１３２は、所定種類のリクエストがＰＣ１２のユーザにより選択された場合、選択されたリクエスト種類の新たなリクエストに対応したレコードをユーザ操作管理情報２００に追加し、追加したレコードに、新たなリクエストに割り振ったプロセスＩＤ２０１、その選択のための操作をしたユーザのユーザＩＤ２０２、選択されたリクエスト種類２０３、操作をしたユーザに対応した送金元口座情報２０４、及び、状態２０７「未処理」を登録する。選択されたリクエスト種類が「送金」の場合、サーバシステム１３のプロセッサ１３２が、携帯端末１１のユーザにより入力された情報を基に送金先口座情報及び送金金額を特定したならば、その送金先口座情報２０５及び送金金額２０６を、上記新たなリクエストに対応したレコードに追記する。そして、プロセッサ１３２は、選択された操作に対応した状態２０７を「未処理」から「処理中」に更新し、そのリクエストを完了した場合（例えば、送金元口座から送金先口座に送金金額を移動した場合）、状態２０７を「処理中」から「処理済」に更新する。

以下、本実施例で行われる処理を説明する。

事前に、サーバシステム１３のプロセッサ（以下、サーバプロセッサ）１３２は、ユーザ登録とデバイス登録を行う。ユーザ登録では、サーバプロセッサ１３２は、ユーザ認証のためのユーザＩＤ及びパスワードを含んだユーザ情報（例えば電子メールアドレスを含んでよい）と、ユーザの送金元口座を表す送金元口座情報とをユーザ端末（例えばＰＣ１２）から受けて記憶デバイス１３１に登録する。デバイス登録では、サーバプロセッサ１３２は、デバイス認証のための電子署名（例えばユーザＩＤ（メッセージ）及び署名）を携帯端末１１に発行する。電子署名に含まれるユーザＩＤは、ユーザ認証で使用されるユーザＩＤと同じユーザＩＤでよい。これにより、デバイス登録された携帯端末１１とそのユーザが関連付けられる。なお、携帯端末１１とユーザの関連付けの方法としては、例えば、ユーザ毎にユーザＩＤと携帯端末１１の個体識別番号との組合せを記憶デバイス１３１が記憶する等、他の方法が採用されてよい。また、デバイス登録に代えて又は加えて、携帯端末１１の電話番号及び電子メールアドレスがユーザ毎に記憶デバイス１３１に登録されてよい。一ユーザにつき、送金元口座は、複数存在してもよい。なお、送金元口座情報は、オンライン送金の都度にユーザにより入力されてもよい。

ユーザ登録及びデバイス登録の後、ユーザは、サーバシステム１３が提供するオンライン送金サービスを使用することができる。オンライン送金では、ＰＣ１２と携帯端末１１という２つのユーザ端末が使用される。本実施例は、ＰＣ１２と携帯端末１１の一方だけがスパイアイのようなコンピュータウィルスに感染していることはあっても、ＰＣ１２と携帯端末１１が両方ともコンピュータウィルスに感染していることは無いとの前提に基づく。

図３は、オンライン送金の流れを示す。図４は、オンライン送金における画面遷移を示す。以下、オンライン送金の流れを、図３を主に参照して説明し、適宜、図４を参照することとする。なお、以下の説明では、オンライン送金のためにユーザがＰＣ１２を使用してサーバシステム１３にログインしている状態（ユーザＩＤ及びパスワードを使用したユーザ認証が済んでいる状態）であるとする。また、以下の説明では、サーバシステム１３からユーザ端末に提供（送信）された情報（例えば画面）がユーザ端末の表示デバイスに表示されることを、サーバシステム１３がユーザ端末に情報を表示する、と簡略することにする。また、以下の説明では、ＰＣ１２とサーバシステム１３間の通信は、通信インターフェースデバイス１２３及び１３３を通じて行われることとし、携帯端末１１とサーバシステム１３間の通信は、通信インターフェースデバイス１１４及び１３３を通じて行われる。また、サーバシステム１３によりユーザ端末に情報（画面）が表示される流れでは、ユーザ端末の記憶デバイス（例えばメモリ）に少なくとも一時的に情報が記憶され、記憶デバイスに記憶されている情報が表示される。また、サーバシステム１３により表示される画面は、ＧＵＩ（Graphical User Interface）であるとする。また、サーバシステム１３からユーザ端末に表示される情報は、ユーザ端末のプロセッサで実行されるＷｅｂブラウザ（図示せず）（又は専用アプリケーションプログラム）により実行される。また、ユーザによる情報の入力は、ユーザが使用するユーザ端末の入力デバイスを使用して行われる。また、「情報の入力」とは、キーボード（物理的なキーボードでもスクリーンキーボードでもよい）のような入力デバイスを用いたマニュアル入力であってもよいし、複数の選択肢（情報）からクリック等の操作により情報を選択することであってもよい。また、サーバシステム１３、ＰＣ１２及び携帯端末１１の各々について、プロセッサにより処理が行われるが、プロセッサは、コンピュータプログラムを実行することにより処理を行うことができる。コンピュータプログラムは、プログラム配布サーバからダウンロードされてもよいし、可搬型の記録媒体からインストールされてもよい。プログラム配布サーバは、サーバシステム１３の中にあってもよいし外にあってもよい。

サーバプロセッサ１３２は、ログインしているユーザが使用しているＰＣ１２に、リクエスト種類選択画面（図４の４０１）を表示する。サーバプロセッサ１３２は、リクエスト種類選択画面４０１からＰＣ１２のユーザによりリクエスト種類「送金」が選択され「送信」ボタンが押下されたことを特定し（図３のＳ３０１）、ユーザ操作管理情報２００を更新する（図３のＳ３０２）。具体的には、例えば、サーバプロセッサ１３２は、レコードをユーザ操作管理情報２００に追加し、追加したレコードに、「送金」に対応した新たなリクエストのプロセスＩＤ２０１（サーバプロセッサ１３２が割り振ったＩＤ）、「送金」を選択したユーザのユーザＩＤ２０２、リクエスト種類２０３「送金」、「送金」を選択したユーザに対応した送金元口座情報２０４、及び、状態２０７「未処理」を登録する。なお、サーバシステム１３のプロセッサ１３２は、ユーザから送金元口座情報（但し、送金元口座の名義人名は含まないでよい）の入力を受け付ける画面をＰＣ１２に表示し、「送金」の選択に加えて、送金元口座情報の入力をＰＣ１２経由でユーザから受けてもよい。また、ユーザに複数の送金元口座情報が関連付けられている場合、サーバプロセッサ１３２が、ＰＣ１２のユーザから、ユーザ所望の送金元口座情報の選択を受けてよい。

サーバプロセッサ１３２は、「送金」を選択したユーザのユーザＩＤ２０２とリクエスト種類２０３「送金」と状態２０７「未処理」とを含んだ全てのレコードを検索し、ＰＣ１２ではなく携帯端末１１に、検索結果（見つかったレコードのリスト）を表す未処理リスト画面（図４の４０３）を表示する（図３のＳ３０３）。

ここでの表示は、途中表示である。具体的には、本実施例において、１つのリクエストについてユーザにより入力されるべき複数のリクエストパラメータのうちの一部のリクエストパラメータがユーザにより入力済の段階で未確認パラメータを表示することを「途中表示」と言い、途中表示された未確認パラメータが正しいか否かの確認を「途中確認」と言う。途中表示に使用されるユーザ端末（例えば携帯端末１１）は、途中表示される未確認パラメータ（又はそれの基になる情報）の入力に使用されたユーザ端末（例えばＰＣ１２）とは別のユーザ端末である。途中表示は、最終的なリクエスト実行／非実行（ＯＫ／ＮＧ）を受け付けるための表示ではない。ユーザは、携帯端末１１に表示された未処理リスト画面４０３を見て、ＰＣ１２に対する操作に従う未確認パラメータを確認することができる。「未確認パラメータ」とは、ユーザ端末を使用して入力されたリクエストパラメータが正しく入力されたか否かの確認が未だユーザによりされていないパラメータである。

ＰＣ１２から携帯端末１１への切り替えは、以下のように行われてよい。具体的には、例えば、サーバプロセッサ１３２は、検索が終了した場合に、デバイス登録済のデバイス（実施例では携帯端末１１）を使用してサーバシステム１３にログインすることのメッセージをＰＣ１２に表示する等の方法により、ユーザに携帯端末１１を使用したログインを指示してよい。サーバプロセッサ１３２は、携帯端末１１からのログインを、デバイス認証をパスした場合に許可し、その後、検索結果（未確認パラメータ）を携帯端末１１に表示（途中表示）してもよい。携帯端末１１のログインは、ＰＣ１２を使用したユーザのログイン前に行われていてもよい。或いは、例えば、サーバプロセッサ１３２は、検索結果のＵＲＬ（Uniform Resource Locator）を記載した電子メール又はＳＭＳ（Short Message Service）を携帯端末１１に送信し、携帯端末１１からそのＵＲＬへのアクセスを受けた場合に、検索結果（未確認パラメータ）を携帯端末１１に表示（途中表示）してもよい。

表示される検索結果は、未処理リクエスト毎に、リクエスト種類２０３及び送金元口座情報２０４を含む。なお、本実施例では、検索結果における見つかった未処理リクエストが、送金先口座情報２０５及び送金金額２０６の少なくとも１つを含んでいることはない。なぜなら、後述するように、リクエストの実行についてＮＧ（非実行）が回答された又はリクエストの実行についての回答が未入力のまま一定時間が経過した（タイムアウト）の場合には、それらのリクエストパラメータ２０５及び２０６の少なくとも１つが、サーバプロセッサ１３２により削除されるからである。

サーバプロセッサ１３２は、未処理リスト画面４０３から携帯端末１１のユーザが所望する未処理リクエストの選択を受け付ける。ここでは、ユーザにより選択された未処理リクエストは、「送金」であるとする。サーバプロセッサ１３２は、ユーザにより選択された未処理リクエスト「送金」について残りのリクエストパラメータの入力を受け付けるための画面、すなわち、送金先口座情報及び送金金額の入力画面（図４の４０４）を携帯端末１１に表示する。サーバプロセッサ１３２は、送金先口座情報（但し、名義人名の入力は不要でよい）と送金金額の入力を受け、且つ、「送信」ボタンの押下を受ける（図３のＳ３０４）。

サーバプロセッサ１３２は、選択された未処理リクエスト「送金」に対応した状態２０７を「未処理」から「処理中」に更新し、そのリクエスト「送金」に対応したレコードに、入力された送金先口座情報２０５及び送金金額２０６を追記し、最終画面（図４の４０６）を、携帯端末１１ではなくＰＣ１２に表示する（図３のＳ３０５）。

ここでの表示は、最終表示である。具体的には、本実施例において、１つのリクエストについてユーザにより入力されるべき複数のリクエストパラメータの全てが入力済の段階で未確認パラメータを表示することを「最終表示」と言い、最終表示された未確認パラメータが正しいか否かの確認を「最終確認」と言う。最終表示に使用されるユーザ端末（例えばＰＣ１２）も、最終表示される未確認パラメータ（又はそれの基になる情報）の入力に使用されたユーザ端末（例えば携帯端末１１）とは別のユーザ端末である。つまり、本実施例では、ユーザ端末を使用して入力されたリクエストパラメータが、そのパラメータの入力に使用されたユーザ端末とは別のユーザ端末に表示されるようになっている。ユーザは、ＰＣ１２に表示された最終画面４０６を見て、携帯端末１１に入力された未確認パラメータを確認することができる。具体的には、最終画面４０６は、Ｓ３０４で選択されたリクエスト「送金」に対応するレコードに登録されているリクエストパラメータ、例えば、プロセスＩＤ２０１と、送金元口座情報２０４と、送金先口座情報（携帯端末１１により入力画面４０４で入力されたリクエストパラメータ）２０５と、送金金額（携帯端末１１により入力画面４０４で入力されたリクエストパラメータ）２０６とを表示する。最終画面４０６が表示するリクエストパラメータのうち、少なくとも送金先口座情報及び送金金額（携帯端末１１により入力されたリクエストパラメータ）が、未確認パラメータである。

最終表示は、最終的なリクエスト実行／非実行（ＯＫ／ＮＧ）を受け付けるための表示である。ＰＣ１２のユーザは、最終画面４０６に対して、ＯＫ（リクエスト実行）かＮＧ（リクエスト非実行）かを回答する。具体的には、ユーザは、最終画面４０６が表すリクエストパラメータが全て正しく送金が実行されてもよければ、「ＯＫ」ボタンを押下する。一方、ユーザは、最終画面４０６が表すリクエストパラメータに誤りがある又は送金を実行したくなければ、「ＮＧ」ボタンを押下する（或いは、最終画面４０６を閉じる）。サーバプロセッサ１３２は、最終画面４０６に対して「ＯＫ」又は「ＮＧ」という回答を受ける（Ｓ３０６）。

サーバプロセッサ１３２は、回答「ＮＧ」を受けた場合（又は、最終画面４０６を表示してから回答が未入力のまま一定時間が経過した場合）、最終画面４０６に表示されたリクエストパラメータのうち送金先口座情報２０５及び送金金額２０６の少なくとも１つを、ユーザ操作管理情報２００から削除する。

一方、サーバプロセッサ１３２は、回答「ＯＫ」を受けた場合、リクエストの実行、つまり送金処理を実行する。具体的には、回答「ＯＫ」は、プロセスＩＤ（最終画面４０６上のプロセスＩＤ）を指定した実行指示である。サーバプロセッサ１３２は、回答「ＯＫ」（実行指示）で指定されているプロセスＩＤに対応したリクエストを実行する。すなわち、サーバプロセッサ１３２は、実行指示で指定されているプロセスＩＤに対応したレコードを特定し、そのレコード上のユーザＩＤ２０２が、ＰＣ１２のユーザのユーザＩＤであり、且つ、そのレコードに送金元口座情報２０４及び送金金額２０６が登録されていれば、リクエストに従う送金処理を実行し、その送金処理を完了した場合、特定したレコード上の状態２０７を「処理中」から「処理済」に更新する（Ｓ３０７）。その送金処理は、送金元口座（特定したレコード上の送金元口座情報２０４が表す口座）から送金先口座（特定したレコード上の送金先口座情報２０５が表す口座）へ送金金額（特定したレコード上の送金金額２０６が表す金額）を移動する処理である。

なお、携帯端末１１からＰＣ１２への切り替えは、以下のように行われてよい。具体的には、例えば、ＰＣ１２とサーバシステム１３が図３のＳ３０１以降も互いに通信可能に接続されたままの状態にあり、ＰＣ１２のプロセッサ１２２がサーバシステム１３に繰り返し問合せを発行し（ポーリングし）、サーバプロセッサ１３２が、携帯端末１１に表示された入力画面４０４の「送信」ボタンが押下された後に（レコードに送金先口座情報２０５及び送金金額２０６が登録された後に）受けた問合せに対して、最終画面４０６をＰＣ１２に表示してもよい。或いは、例えば、サーバプロセッサ１３２が、ＰＣ１２から携帯端末１１に切り替わった場合にＰＣ１２を一旦サーバシステム１３からログアウトし、携帯端末１１に表示された入力画面４０４の「送信」ボタンが押下された後に（レコードに送金先口座情報２０５及び送金金額２０６が登録された後に）ＰＣ１２の再度のログインを受けた場合に、最終画面４０６をＰＣ１２に表示してもよい。

以上の実施例１では、ユーザ端末を使用して入力されたリクエストパラメータが、そのパラメータの入力に使用されたユーザ端末とは別のユーザ端末に表示されるようになっている。このため、リクエストパラメータを入力したユーザ端末とそのリクエストパラメータが表示されるユーザ端末の一方で不正プログラムによりリクエストパラメータが改ざんされても他方のユーザ端末でその改ざんを検知することができる。

また、実施例１では、ユーザ操作管理情報２００が用意される。ユーザ操作管理情報２００に複数の未処理のリクエストのリクエストパラメータが保持される。つまり、複数のリクエストを登録し保留（未処理）の状態のまま保持しておくことができる。そして、未処理リクエストについては、送金先口座情報２０５及び送金金額２０６の少なくとも１つがユーザ操作管理情報２００に登録されていないので、未処理リクエストが誤って又は不正に実行されてしまうことは無い。

以下、実施例１を考察する。

ＰＣ１２及び携帯端末１１のうちの１つが、コンピュータウィルスのような不正プログラムにより中間者攻撃（例えばＭＩＴＢ）を受け得るとする。また、サーバシステム１３のサービス（オンライン送金）を利用するユーザに対して、中間者攻撃により不正送金を行う攻撃者（悪意のある第三者）の目的は、主に、以下の（Ｇ１）及び（Ｇ２）のうちの少なくとも１つ、
（Ｇ１）架空のリクエスト（本実施例ではオンライン送金）をサーバシステム１３に実行させる、
（Ｇ２）ユーザが行おうとしているリクエストのリクエストパラメータを異なるリクエストパラメータに改ざんしてサーバシステム１３に実行させる、
であるとする。

この場合、以下の（Ｒ１）及び（Ｒ２）のうちの少なくとも１つ、
（Ｒ１）サーバシステム１３がリクエストを処理する前までにユーザが不正（改ざん）を検知できること、
（Ｒ２）攻撃者によって改ざんされたリクエストがサーバシステム１３に処理され得ない、
が望まれる。一般に、中間者攻撃による不正なオンライン送金は、ユーザが不正を検知できなく、改ざんされたリクエストであってもサーバシステムに処理され得ることが原因で行われてしまうからである。

実施例１において、ＰＣ１２が不正プログラムに感染しているとする。

この場合、以下の（Ｘ１）〜（Ｘ３）のうちの少なくとも１つ、
（Ｘ１）Ｓ３０１でＰＣ１２からサーバシステム１３に送信された情報（選択された操作を表す情報）、
（Ｘ２）Ｓ３０５でサーバシステム１３によりＰＣ１２に表示された最終画面４０６、
（Ｘ３）Ｓ３０６でＰＣ１２からサーバシステム１３に送信された回答「ＯＫ」中のプロセスＩＤ、
が、改ざんされる恐れがある。

しかし、（Ｘ１）〜（Ｘ３）のいずれが改ざんされても、ユーザがサーバシステム１３の処理前にその改ざんを検知できるか、又は、不正リクエストが実際には処理されないようにすることができる。具体的には、以下の（Ｙ１）〜（Ｙ３）の通りである。
（Ｙ１）（Ｘ１）の情報が改ざんされた場合、ユーザは、その改ざんを、Ｓ３０４で携帯端末１１に表示される未処理リスト画面４０３を見て検知できる。なぜなら、（Ｘ１）の情報が改ざんされていれば、改ざん後の情報が、未処理リスト画面４０３に表示されるか、或いは、情報それ自体が未処理リスト画面４０３に存在しないからである。
（Ｙ２）（Ｘ２）の最終画面４０６に表示されるリクエストパラメータが改ざんされるのは、（Ｘ１）の情報が改ざんされた場合である。そうでなければ、最終画面４０６に表示されるリクエストパラメータを改ざんする理由がないからである。（Ｘ１）の情報の改ざんは、上記（Ｙ１）の通り検知可能である。
（Ｙ３）（Ｘ３）のプロセスＩＤが改ざんされた場合、別のプロセスＩＤがサーバシステム１３に指定されることになる。しかし、ユーザがＳ３０４で選択したリクエスト以外の未処理リクエストについては送金先口座情報２０５及び送金金額２０６の少なくとも１つが削除されているので、別のプロセスＩＤが指定されても、保留中の未処理リクエストに従う送金処理が実行されることはない。また、別のプロセスＩＤを有するレコード上のユーザＩＤ２０２が別ユーザのユーザＩＤであれば、送金処理が実行されることはない。

以上の通り、ＰＣ１２が不正プログラムに感染していても、安全性の要件（Ｒ１）及び（Ｒ２）が満たされる。

一方、実施例１において、携帯端末１１が不正プログラムに感染しているとする。

この場合、以下の（Ｐ１）及び（Ｐ２）のうちの少なくとも１つ、
（Ｐ１）Ｓ３０４でサーバシステム１３により携帯端末１１に表示された画面４０３、
（Ｐ２）Ｓ３０４で携帯端末１１によりサーバシステム１３に送信されたリクエストパラメータ（入力画面４０４に入力されたリクエストパラメータ）
が、改ざんされる恐れがある。

しかし、（Ｐ１）及び（Ｐ２）の情報のいずれが改ざんされても、ユーザは、最終画面４０６を見ることで、その改ざんを検知できる。このため、要件（Ｒ１）が満たされる。

また、ＰＣ１２が不正プログラムに感染し、攻撃者がＰＣ１２から架空のリクエストをサーバシステム１３に送っても、送金先口座情報及び送金金額をサーバシステム１３はＰＣ１２から受け付けないため、Ｓ３０７で送金処理が実行されることはない。このため、要件（Ｒ２）が満たされる。

以下、実施例２を説明する。その際、実施例１との相違点を主に説明し、実施例１との共通点については説明を省略又は簡略する。

実施例１では、ユーザが入力すべき複数のリクエストパラメータがＰＣ１２及び携帯端末１１から分けて入力されるが、実施例２では、ユーザが入力すべき複数のリクエストパラメータの全てがＰＣ１２から入力され、最終確認の結果としての回答「ＯＫ」がＰＣ１１２及び携帯端末１１からそれぞれ入力される。

図５は、実施例２に係るオンライン送金の流れを示す。

サーバプロセッサ１３２が、リクエスト種類の選択と、ユーザが入力すべき複数のリクエストパラメータ（送金先口座情報及び送金金額を含む）を受け付ける画面をＰＣ１２に表示し、リクエスト種類「送金」とユーザが入力すべき複数のリクエストパラメータをＰＣ１２から受ける（Ｓ５０１）。サーバプロセッサ１３２は、入力された複数のリクエストパラメータをユーザ操作管理情報２００に登録し、且つ、実施例１と同様の方法で最終画面を生成し、最終画面（以下、第１の最終画面）を、ＰＣ１２ではなく携帯端末１１に表示する（Ｓ５０２）。

ユーザは、携帯端末１１に表示された第１の最終画面が表示する未確認パラメータが正しいか否かの確認、つまり、第１の最終確認を行い、その確認結果に従い回答をサーバシステム１３に対し入力する（Ｓ５０３）。回答が「ＯＫ」の場合、回答「ＯＫ」は、第１の最終画面に表示されたプロセスＩＤが指定された実行指示でよい。

サーバプロセッサ１３２は、携帯端末１１から、最終画面に対する回答を受け、受けた回答が「ＯＫ」の場合、或いは、受けた回答が「ＯＫ」か「ＮＧ」かに関わらず、上記と同様の最終画面（以下、第２の最終画面）を、ＰＣ１２に表示する（Ｓ５０４）。なお、携帯端末１１から受けた回答が「ＮＧ」であっても第２の最終画面が表示される場合には、ＰＣ１２に、携帯端末１１から入力された回答が「ＯＫ」か「ＮＧ」かを表す情報が表示されてもよい。その情報は、第２の最終画面が表示する情報に含まれていてもよいし、第２の最終画面の表示とは別に表示されてもよい。

ユーザは、ＰＣ１２に表示された第２の最終画面が表示するリクエストパラメータが正しいか否かの確認、つまり、第２の最終確認を行い、その確認結果に従い回答をサーバシステム１３に対し入力する（Ｓ５０５）。なお、回答が「ＯＫ」の場合、回答「ＯＫ」は、第２の最終画面に表示されたプロセスＩＤが指定された実行指示でよい。また、第２の最終画面が表示するリクエストパラメータも、「未確認パラメータ」と呼ばれてよい。なぜなら、第２の最終画面が表示するリクエストパラメータは、第１の最終画面で既に表示されたパラメータであるものの、第２の最終確認が済んでいないリクエストパラメータだからである。

サーバプロセッサ１３２は、ＰＣ１２から回答を受ける。サーバプロセッサ１３２は、携帯端末１１からの回答とＰＣ１２からの回答の両方が「ＯＫ」の場合にのみ、回答「ＯＫ」で指定されているプロセスＩＤに対応したリクエストに従う送金処理を実行する（Ｓ５０６）。言い換えれば、サーバプロセッサ１３２は、携帯端末１１からの回答とＰＣ１２からの回答の少なくとも一方が「ＮＧ」の場合（又は、携帯端末１１とＰＣ１２の少なくとも一方でタイムアウトが生じた場合）、リクエストに従う送金処理を行わない。

実施例２によれば、ＰＣ１２が不正プログラムに感染している場合、Ｓ５０１でＰＣ１２からサーバシステム１３に送信された少なくとも１つのリクエストパラメータが改ざんされるおそれがある。しかし、そのような改ざんがされたならば、携帯端末１１に表示される第１の最終画面からその改ざんを検知することができる。

また、実施例２によれば、携帯端末１１が不正プログラムに感染している場合、携帯端末１１から送信される回答「ＯＫ」中のプロセスＩＤが改ざんされるおそれがある。しかし、そのような改ざんがされたとしても、保留中の未処理リクエストに従う送金処理が実行されることはない。なぜなら、ユーザがＳ５０１で選択したリクエスト以外の未処理リクエストについては送金先口座情報及び送金金額の少なくとも１つが削除されているからである。

また、実施例２によれば、携帯端末１１が不正プログラムに感染している場合、携帯端末１１から送信される回答が「ＯＫ」から「ＮＧ」に改ざんされるおそれがある。しかし、そのような改ざんがされたならば、携帯端末１１からの回答とＰＣ１２からの回答の両方が「ＯＫ」の場合にのみリクエストを実行する（送金処理を実行する）という条件が満たされないので、不正な送金処理の実行は回避できる。また、そのような改ざんがされたならば、ＰＣ１２に第２の最終画面が表示されないので（又は、携帯端末１１からの回答を表す情報がＰＣ１２に表示されるので）、その改ざんを検知できる。

また、実施例２によれば、携帯端末１１が不正プログラムに感染している場合、携帯端末１１から送信される回答が「ＮＧ」から「ＯＫ」に改ざんされるおそれがある。しかし、そのような改ざんがされたならば、「ＮＧ」を回答したにも関わらずＰＣ１２に第２の最終画面が表示されるので（又は、携帯端末１１からの回答を表す情報がＰＣ１２に表示されるので）、その改ざんを検知できる。

また、実施例２によれば、ＰＣ１２が不正プログラムに感染している場合、ＰＣ１２から送信される回答が「ＯＫ」から「ＮＧ」に改ざんされるおそれがある。しかし、そのような改ざんがされたならば、携帯端末１１からの回答とＰＣ１２からの回答の両方が「ＯＫ」の場合にのみリクエストを実行する（送金処理を実行する）という条件が満たされないので、不正な送金処理の実行は回避できる。また、リクエストが実行されないままになるという事実から、そのような改ざんがされたことの可能性を検知できる。

また、実施例２によれば、ＰＣ１２が不正プログラムに感染している場合、ＰＣ１２から送信される回答が「ＮＧ」から「ＯＫ」に改ざんされるおそれがある。しかし、第２の最終確認で「ＮＧ」を回答するのであれば、第１の最終確認で既に「ＮＧ」を回答していると考えられるので、その改ざんが問題になるおそれはない。

以上が、実施例２の説明である。

なお、最終表示及び最終確認には、ＰＣ１２及び携帯端末１１のような２台のユーザ端末に限らず、３以上のユーザ端末が使用されてもよい。すなわち、サーバプロセッサ１３２は、複数のユーザ端末から、それぞれ、リクエスト実行か非実行かの回答を受け付け、同一ユーザについてリクエスト実行を表す回答が所定数以上集まった場合に（つまり、リクエスト実行を回答したユーザ端末の数が所定数以上の場合に）、受け付けた複数のリクエストパラメータに従いリクエストを実行することができる。複数の回答をそれぞれ出す複数のユーザ端末に、リクエストパラメータを入力したユーザ端末が含まれていなくてもよい。例えば、サーバプロセッサ１３２は、リクエストパラメータの入力元のユーザ端末とは別の２以上のユーザ端末に最終表示を行いそれら別の２以上のユーザ端末からそれぞれ回答（ＯＫ又はＮＧ）を受け付けてもよい。

また、最終表示及び回答の受け付けは、シーケンシャルに行われることに代えて、パラレルに行われてよい。すなわち、サーバプロセッサ１３２は、並行して、２以上のユーザ端末に最終画面を表示し回答（ＯＫ／ＮＧ）を受け付けてよい。サーバプロセッサ１３２は、全ての回答が揃い、且つ、全ての回答が「ＯＫ」の場合に、リクエストを実行してよい。また、サーバプロセッサ１３２は、リクエスト実行した旨のメッセージを、最後に受け付けた回答の入力元ユーザ端末に表示してよい。

以下、実施例３を説明する。その際、実施例１及び２との相違点を主に説明し、実施例１及び２との共通点については説明を省略又は簡略する。

実施例３が、特殊詐欺防止システムに関わる。一般に、「ユーザ」とは、利用者、使用者という意味の英単語であるが、ＩＴの分野では、「機器やソフトウェア、システム、サービスなどを使う人や集団のことを指す」と規定されている。そこで、「同一のユーザ」を、本人と、チェック代理人とする。本人は、典型的には、引出されようとする又は移動されようとする金銭の所有者（当該金銭の口座の持ち主）である。本人は、第１の者の一例である。チェック代理人は、典型的には、本人の家族、友人又は上司のような本人の関係者である。チェック代理人は、第２の者の一例である。実施例１及び２で言えば、本人のユーザ端末は、例えばＰＣ１２でよく、チェック代理人のユーザ端末は、例えば携帯端末１１でよい。

図６は、実施例３に係る特殊詐欺防止システムの一例を示す。

第１の情報処理端末の一例として、ＡＴＭ（Automated Teller Machine）６０２がある。本実施例では、ＡＴＭ６０２は、銀行（金融機関の一例）に設置されている当該銀行に専用のＡＴＭでもよいし、コンビニエンスストアのような場所に設置されている汎用のＡＴＭ（例えばキオスク端末）でもよい。

第２の情報処理端末の一例として、チェック代理人が使用するスマホ（スマートフォン）６０１がある。

サーバシステムの一例として、金融機関のサーバシステム６０３がある。サーバシステム６０３が、特殊詐欺防止システムの全部又は一部である。

以下、本実施例で行われる処理の流れを説明する。なお、本実施例において、送金や現金引出しといったリクエストの実行／非実行がチェック代理人の判断に委ねられることは、下記のうちの少なくとも１つが満たされている場合でよい。なお、下記（β）に関し、上限金額やＡＴＭ場所等の様々な要素のうちの少なくとも１つに関する条件は、本人又は運営者等によって決定されて良い。当該条件も、サーバシステム６０３に登録されて良い。
（α）チェック代理人の判断に委ねることを示す本人の意思がサーバシステム６０３に登録されていること。
（β）リクエストに関わる要素（例えば、少なくとも１つのリクエストパラメータ、又は、第１の者に使用される情報処理端末）が所定の条件を満たしていること（例えば、送金金額又は現金引出し金額が上限金額を超えている、又は、利用されるＡＴＭが設置されている場所（例えば支店）が所定の場所のＡＴＭである）。

第１の者が、本人のキャッシュカードをＡＴＭ６０２に挿入し、１以上のリクエストパラメータ（例えば、送金先と送金金額、或いは、現金引出しで引出す金額）を入力する。ＡＴＭ６０２が、当該１以上のリクエストパラメータを関連付けたリクエスト（例えば、送金又は現金引出し）をサーバシステム６０３に送信する。なお、「第１の者」は、典型的には本人であるが、搾取等により本人のキャッシュカードを持つ特殊詐欺犯であることも考えられる。

サーバシステム６０３は、当該１以上のリクエストパラメータを関連付けたリクエストを受け付けた場合、当該リクエストの内容確認（入力されたパラメータの確認）の依頼をＡＴＭ６０２に出す（Ｓ６２）。ＡＴＭ６０２は、入力されたパラメータを表示する。第１の者が、内容のＯＫ又はＮＧをＡＴＭ６０２に入力する。ＡＴＭ６０２が、入力された回答ＯＫ／ＮＧをサーバシステム６０３に返す（Ｓ６３）。なお、図７の左側が、Ｓ６２のときのＡＴＭ６０２の表示画面の一例を示し、図７の右側が、Ｓ６３のときのＡＴＭ６０２の表示画面の一例を示す。

一方、サーバシステム６０３は、Ｓ６１のリクエストを受け付けた場合、当該リクエストの内容確認（入力されたパラメータの確認）の依頼を、スマホ６０１にも出す（Ｓ６２´）。Ｓ６２´は、例えば、サーバシステム６０３によって、上述の（α）及び（β）のうちの少なくとも１つ（又は全て）が満たされていると判定された場合に、実行されてよい。スマホ６０１（例えば、専用アプリ）は、入力されたパラメータを表示する。チェック代理人が、内容のＯＫ又はＮＧをスマホ６０１に入力する。スマホ６０１が、入力された回答ＯＫ／ＮＧをサーバシステム６０３に返す（Ｓ６３´）。なお、図８の左側が、Ｓ６２´のときのスマホ６０１の表示画面の一例を示し、図８の右側が、Ｓ６３´のときのスマホ６０１の表示画面の一例を示す。

サーバシステム６０３は、Ｓ６３の回答とＳ６３´の回答の両方がＯＫなら、リクエスト（例えば、送金又は現金引出し）を実行するが、Ｓ６３の回答とＳ６３´の回答の少なくとも１つがＮＧなら、リクエストを実行しない。これにより、特殊詐欺を防止できる。なお、サーバシステム６０３は、Ｓ６３´の回答を一定時間経っても受領しない場合、リクエストを取り消しとする。

ところで、本実施例によれば、送金（振込）処理の場合、本人は、チェック代理人の操作を待つことなくＡＴＭ６０２から離れることができる。すなわち、チェック代理人のスマホ６０１での操作に従う回答が、ＯＫであれば、サーバシステム６０３により自動的に送金（振込）が行われ、ＮＧの場合は、リクエスト（送金（振込））は非実行となる（例えば取消される）。

また、本実施例によれば、現金引出し（出金）の場合、チェック代理人の回答がサーバシステム６０３に届くまで第１の者によりＡＴＭ６０２が独占されることを防ぐことが望ましい。

そこで、サーバシステム６０３は、受け付けた１以上のリクエストパラメータが、ＡＴＭ６０２から受けた現金引出しに関するパラメータの場合、当該現金引出しの可否を追って回答することを第１の者に通知すると共にＡＴＭ６０２とキャッシュカードとの接続を解除して当該現金引出しに関する処理を一時終了とすることをＡＴＭ６０２に指示する。サーバシステム６０３は、ここまでの処理の内容を保持する。サーバシステム６０３は、スマホ６０１から回答を受け付けた場合、当該回答の内容を、所定の出力媒体から出力する。回答の内容を伝える方法として、例えば、下記のうちのいずれかの方法を採用することができる。
（方法１）キャッシュカードを再度ＡＴＭ６０２に入れたときに、回答が表示される。
（方法２）ＡＴＭ６０２から番号札を出力し、銀行の担当者より、チェック代理人の回答を知らせて貰う。
（方法３）ＡＴＭ６０２から番号札を出力し、所定の場所に設けられている電光掲示板経由で、チェック代理人の回答を表示する。
（方法４）本人の情報処理端末（例えばスマホ）にメール等によりチェック代理人の回答を知らせる。
（方法５）本人のキャッシュカード経由でチェック代理人の回答を知らせる。キャッシュカードにそのような機能の搭載が難しい場合、それに替わるカード等を最初のＡＴＭ操作時に出力する。

（方法４）及び（方法５）については，振込処理でも採用可能である。

キャッシュカードの機能や構成等に関して、下記のうちの少なくとも１つが採用されてよい。なお、現金引出しのリクエストの内容（パラメータ）はサーバシステム６０３に保持されているため、再度引き出す金額を入力する必要は無い。
（Ａ）キャッシュカードがサーバシステム６０３との通信機能を有していて、チェック代理人の回答を（例えば即時に）知らせる。
（Ｂ）（Ａ）に関し、チェック代理人の回答によって、キャッシュカードから出る音や振動が異なる。
（Ｃ）（Ａ）に関し、チェック代理人の回答によって、キャッシュカードの点灯するランプや、点灯する色や等が異なる。
（Ｄ）チェック代理人の回答に関するコメント等の情報（例えば、回答の内容についての理由、チェック代理人からのコメント、並びに、チェック代理人の電話番号）が表示される。
（Ｅ）振り込め詐欺のような特殊詐欺に対する注意事項や振り込め詐欺撲滅キャンペーンのマーク並びに警察への連絡電話番号等が表示される（予めキャッシュカードに印字されていてもよい）。
（Ｆ）キャッシュカードが、現金引出しで引き出す金額の入力を受け付ける番号キーと現金引出しのリクエストの入力ボタンとを有していて、キャッシュカードが、第１の情報処理端末として機能する。当該現金引出しのリクエストの送信後、（Ａ）〜（Ｄ）のような方法でキャッシュカードがチェック代理人の回答をサーバシステム６０３から受けて出力する。その後にキャッシュカードがＡＴＭ６０２に挿入されれば、現金引出しを行える。

以上、幾つかの実施例を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実行することが可能である。例えば、現金引出し可能な情報処理端末としては、ＡＴＭの他に、店舗に設置されているレジスタのような他の端末が採用されてもよい。

１１…携帯端末、１２…ＰＣ、１３…サーバシステム

Claims (3)

1. 第１の者により第１の情報処理端末に入力され金銭の引出し及び移動のうちのいずれかに関する１以上のリクエストパラメータを受け付けるリクエストパラメータ受付手段と、
   前記受け付けた１以上のリクエストパラメータの少なくとも一部を見てリクエスト実行許否を回答することの依頼である回答依頼を、第２の者の情報処理端末である第２の情報処理端末に送信する回答依頼手段と、
   前記第２の情報処理端末からリクエスト実行許否に関する回答を受け付ける回答受付手段と、
   前記受け付けた回答がリクエスト実行拒否を表す回答の場合、前記受け付けた１以上のリクエストパラメータに従うリクエストを非実行とするリクエスト実行制御手段と
   を備えるサーバシステム。
2. 前記リクエスト実行制御手段は、前記受け付けた１以上のリクエストパラメータが、ＡＴＭ（Automated Teller Machine）としての前記第１の情報処理端末から受けた現金引出しに関するパラメータの場合、当該現金引出しの可否を追って回答することを前記第１の者に通知すると共に前記ＡＴＭとキャッシュカードとの接続を解除して当該現金引出しに関する処理を一時終了とすることを前記ＡＴＭに指示し、
   前記リクエスト実行制御手段は、前記第２の情報処理端末から前記回答を受け付けた場合、当該回答の内容を、所定の出力媒体から出力する、
   請求項１に記載のサーバシステム。
3. 前記所定の出力媒体が、前記キャッシュカードである、
   請求項２に記載のサーバシステム。