JP5770354B1 - サーバシステム及びリクエスト実行制御方法 - 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）を携帯端末１１に送信し、携帯端末１１からそのＵＲＬへのアクセスを受けた場合に、検索結果（未確認パラメータ）を携帯端末１１に表示（途中表示）してもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

実施例１及び２では、ユーザシステムは、同一ユーザの複数のユーザ端末であるが、実施例３では、ユーザシステムは、同一ユーザの１つのユーザ端末内の異なる複数の通信ＡＰＰ（アプリケーションプログラム）である。すなわち、実施例３では、「通信ＡＰＰ」が、実施例１及び実施例２の少なくともいずれかにおける「ユーザ端末」に対応する。

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

実施例３では、ユーザは、１つのユーザ端末、例えば携帯端末１１のみで、オンライン送金のようなリクエストをサーバシステム１３に実行させることができる。

具体的には、携帯端末１１の記憶デバイス１１３には、複数の通信ＡＰＰ６０１が記憶されており、プロセッサ１１２によりそれら複数の通信ＡＰＰ６０１の少なくとも１つが実行される。複数の通信ＡＰＰ６０１は、異なる複数種類の通信媒体をそれぞれ経由して通信する複数のＡＰＰである。なお、通信媒体の種類の具体例としては、インターネット通信、ＳＭＳ（Short Message Service）通信、音声通信（例えばインターネットとは異なるネットワーク（例えば電話網）経由の音声通信）等がある。従って、例えば、通信ＡＰＰとしては、インターネット経由の通信を行うＷｅｂブラウザ、ＳＭＳ通信を行うＳＭＳ通信ＡＰＰ、インターネットとは異なるネットワーク経由の音声通信のための音声通信ＡＰＰ等がある。

実施例３が例えば実施例１に適用される場合、図３のＳ３０１は、携帯端末１１における第１の通信ＡＰＰにより行われ、図３のＳ３０４（途中確認）は、携帯端末１１における第２の通信ＡＰＰにより行われ、図３のＳ３０６（最終確認）は、携帯端末１１における第１又は第３の通信ＡＰＰにより行われてよい。実施例３が例えば実施例２に適用される場合、図５のＳ５０１は、携帯端末１１における第１の通信ＡＰＰにより行われ、図５のＳ５０４（第１最終確認）は、携帯端末１１における第２の通信ＡＰＰにより行われ、図５のＳ５０５（第２最終確認）は、携帯端末１１における第１又は第３の通信ＡＰＰにより行われてよい。第１〜第３の通信ＡＰＰのうちの少なくとも１つが、Ｗｅｂブラウザでよく、それ以外の通信ＡＰＰは、Ｗｅｂブラウザが利用する通信媒体とは異なる種類の通信媒体を利用する通信ＡＰＰでよい。なお、実施例１及び２の各々では、ＰＣ１２及び携帯端末１１の各々において、Ｗｅｂブラウザ経由で、情報入力（例えば送金先口座情報等のパラメータ入力や、回答入力等）や情報表示（例えば最終表示等）が行われてよい。

以上の通り、実施例３では、リクエスト実行までの一連の流れにおいて、同一ユーザ端末内の異なる通信ＡＰＰ６０１が使用される。いずれかの通信ＡＰＰ６０１が不正プログラムに感染していることにより、入力された情報（パラメータ及び回答のいずれか）が改ざんされても、不正なリクエストの実行を回避でき、且つ、それを、同じリクエストパラメータを複数の通信ＡＰＰ６０１に入力することなく実現できる。

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

実施例４は、実施例１〜３のうちの少なくとも１つに適用できる。実施例４では、少なくとも１つのユーザ端末（上記実施例ではＰＣ１２及び携帯端末１１）で実行される複数のＡＰＰ（通信ＡＰＰ）のうちの少なくとも１つのＡＰＰが、「ワンタイムＡＰＰ」である。本実施例で言う「ワンタイムＡＰＰ」とは、リクエスト実行までの一連の手続きにおいてサーバシステム１３（又は別のプログラムソース（例えばサーバシステム１３以外のサーバ））において生成されユーザ端末に送信されるＡＰＰであり、且つ、使用可能回数が１回である又は使用可能期間が一定期間であるＡＰＰである。つまり、本実施例において、「ワンタイム」とは、１回又は一定期間を意味する。なお、１回の使用とは、起動したＡＰＰにより表示された画面に対して所定のユーザ操作がされること（例えば、「送信」又は「回答」等の所定のボタンが押されること）でよい。一定期間の使用とは、ワンタイムＡＰＰがユーザ端末に受信されてから（又はユーザ端末で初めて起動してから）の経過時間が所定の閾値になるまでの使用でよい。ワンタイムＡＰＰは、Ｗｅｂブラウザのようにインターネットを経由して通信するＡＰＰでもよいし、インターネットと異なる種類の通信媒体を経由して通信するＡＰＰでもよい。

予めユーザ端末にインストールされているＡＰＰ（例えばＷｅｂブラウザ）には、やがて、不正プログラムが侵入することがあり得るが、本実施例では、上記一連の手続きにおいて必要なタイミングで生成されユーザ端末に送信されたＡＰＰであるワンタイムＡＰＰが実行される。ワンタイムＡＰＰは、必要なタイミングで生成され送信されるので、不正プログラムが侵入するおそれは低く、故に、そのＡＰＰからサーバシステム１３に送信される情報（回答）が不正に改ざんされるおそれは低い。

また、本実施例では、図３のＳ３０１及び図５のＳ５０１のような初回入力で使用されるＡＰＰは、ワンタイムＡＰＰでなくてよく、図３のＳ３０４のような途中確認、及び、図３のＳ３０６、図５のＳ５０３及び図５のＳ５０５のような最終確認のうちの少なくとも１つで使用されるＡＰＰが、ワンタイムＡＰＰでよい。特に、ＯＫ／ＮＧの最終確認のためのＡＰＰがワンタイムＡＰＰであれば、途中確認や初回入力のためのＡＰＰがワンタイムＡＰＰであることに比べて、ワンタイムＡＰＰの作成が簡単なこと、及び、ワンタイムＡＰＰのデータサイズが小さいこと、のうちの少なくとも１つの効果が期待できる。例えば、最終確認のためのＡＰＰに関しては、最終確認のために表示される全ての情報（例えばリクエストパラメータ）をＡＰＰにとってのパラメータ（入力値）とし、ＯＫかＮＧの回答を受け付けるインターフェース（例えばボタン）だけを構成要素とするシンプルなＡＰＰ構成とすることが期待できる。故に、複数タイプのリクエストの実行に適用できる汎用性の高いワンタイムＡＰＰとすることも期待できる。

また、ワンタイムＡＰＰのユーザ端末への送信として、ユーザ端末からのＡＰＰリクエストに応答してダウンロードされるいわゆるプル送信でなく、ユーザ端末からのＡＰＰリクエスト無しに送信されるいわゆるプッシュ送信が採用されてよい。また、ワンタイムＡＰＰの生成完了がプッシュでユーザ端末に通知され、その通知がユーザ端末で起動された場合に、ワンタイムＡＰＰをユーザ端末にダウンロードするか否かの問合せがユーザ端末のプロセッサにより表示され、ダウンロードするとの回答が入力された場合に、ユーザ端末のプロセッサによりワンタイムＡＰＰがダウンロードされてよい。

図７は、実施例４に係るワンタイムＡＰＰ送信の第１の例を示す。

この第１の例は、実施例１（図３に示したオンライン送金流れ）にワンタイムＡＰＰ送信が適用された例である。

サーバプロセッサ７３２（サーバシステム７１３内のプロセッサ）は、図３のＳ３０５に代えて、Ｓ７０５を行う。すなわち、サーバプロセッサ７３２は、Ｓ３０１及びＳ３０４で入力された全てのリクエストパラメータ（及び回答内容）を入力値として含んだ最終確認用ワンタイムＡＰＰ７００を生成し、生成した最終確認用ワンタイムＡＰＰ７００を、ＰＣ１２に送信する。最終確認用ワンタイムＡＰＰ７００は、最終確認のためのＡＰＰである。具体的には、例えば、最終確認用ワンタイムＡＰＰ７００は、入力値の表示のための機能と、最終回答の受付の機能（例えば最終回答ＯＫ／ＮＧのそれぞれのボタン）とを有する。

ＰＣ１２が、最終確認用ワンタイムＡＰＰ７００を受信する。ＰＣ１２では、Ｓ３０６に代えて、Ｓ７０６が行われる。すなわち、ＰＣ１２において、最終確認用ワンタイムＡＰＰ７００が、例えば手動又は自動で、起動する。起動した最終確認用ワンタイムＡＰＰ７００は、内部に埋め込まれている入力値（リクエストパラメータ及び回答内容）を表示する。最終確認用ワンタイムＡＰＰ７００は、表示した入力値の正否の回答（送金のようなリクエストの実行についてのＯＫ／ＮＧを含む）をユーザから受け、入力された回答を、サーバシステム７１３に送信する。

図８は、実施例４に係るワンタイムＡＰＰ送信の第２の例を示す。

この第２の例は、実施例１（図３に示したオンライン送金流れ）と実施例３の組合せにワンタイムＡＰＰ送信が適用された例である。

すなわち、Ｓ３０１、Ｓ３０４及びＳ７０６は、携帯端末１１で行われる。Ｓ３０１は、第１種の通信媒体経由の通信を行う第１の通信ＡＰＰにより行われる。Ｓ３０４は、第２種の通信媒体（第１種の通信媒体と異なる）経由の通信を行う第２の通信ＡＰＰにより行われる。Ｓ７０５で生成される最終確認用ワンタイムＡＰＰ８００は、携帯端末１１で実行可能なＡＰＰであり、第３種（又は第１種）の通信媒体経由の通信を行う通信ＡＰＰである。

なお、Ｓ３０１、Ｓ３０４及びＳ７０６は、携帯端末１１に代えてＰＣ１２で行われてもよい。

図９は、実施例４に係るワンタイムＡＰＰ送信の第３の例を示す。

この第３の例は、実施例２（図５に示したオンライン送金流れ）にワンタイムＡＰＰ送信が適用された例である。

サーバプロセッサ９３２（サーバシステム９１３内のプロセッサ）は、図５のＳ５０４に代えて、Ｓ９０４を行う。すなわち、サーバプロセッサ７３２は、Ｓ５０１で入力された全てのリクエストパラメータ（及びＳ５０３で入力された回答内容）を入力値として含んだ最終確認用ワンタイムＡＰＰ８００を生成し、生成した最終確認用ワンタイムＡＰＰ８００を、ＰＣ１２に送信する。

ＰＣ１２が、最終確認用ワンタイムＡＰＰ８００を受信する。ＰＣ１２では、Ｓ５０５に代えて、Ｓ９０５が行われる。すなわち、ＰＣ１２において、最終確認用ワンタイムＡＰＰ８００が、例えば手動又は自動で、起動する。起動した最終確認用ワンタイムＡＰＰ７００は、内部に埋め込まれている入力値（リクエストパラメータ及び回答内容）を表示する。最終確認用ワンタイムＡＰＰ７００は、表示した入力値の正否の回答（送金のようなリクエストの実行についてのＯＫ／ＮＧを含む）をユーザから受け、入力された回答を、サーバシステム７１３に送信する。

図１０は、実施例４に係るワンタイムＡＰＰ送信の第４の例を示す。

この第４の例は、実施例２（図５に示したオンライン送金流れ）と実施例３の組合せにワンタイムＡＰＰ送信が適用された例である。

すなわち、Ｓ５０１、Ｓ５０３及びＳ９０５は、携帯端末１１で行われる。Ｓ５０１は、第１種の通信媒体経由の通信を行う第１の通信ＡＰＰにより行われる。Ｓ５０３は、第２種の通信媒体（第１種の通信媒体と異なる）経由の通信を行う第２の通信ＡＰＰにより行われる。Ｓ９０４で生成される最終確認用ワンタイムＡＰＰ９００は、携帯端末１１で実行可能なＡＰＰであり、第３種（又は第１種）の通信媒体経由の通信を行う通信ＡＰＰである。

なお、Ｓ５０１、Ｓ５０３及びＳ９０５は、携帯端末１１に代えてＰＣ１２で行われてもよい。

第１〜第４の例において、最終確認用ワンタイムＡＰＰは、その１回の使用後、又は、ユーザ端末に受信されてから（又は起動してから）一定期間経過後、そのワンタイムＡＰＰを受信したユーザ端末において無効となってよい。ユーザ端末においてＡＰＰが無効になるとは、ＡＰＰが起動しないことでもよいし、ＡＰＰが起動してもユーザからＡＰＰが回答を受け付けないことでもよいし、ユーザ端末からＡＰＰが消去される（アンインストールされる）ことでもよい。例えば、最終確認用ワンタイムＡＰＰが入力値の正否の回答をサーバシステムに送信したことを契機に、又は、最終確認用ワンタイムＡＰＰがユーザ端末に受信されてから（又は起動してから）一定期間経過したことを契機に、その最終確認用ワンタイムＡＰＰが、ユーザ端末のＯＳ（オペレーティングシステム）の所定の機能をコールすることにより、ユーザ端末からアンインストールされてよい（つまり確認用ワンタイムＡＰＰの使用回数上限が１回でよい）。ワンタイムＡＰＰのユーザ端末からのアンインストールは、ユーザからの明示に指示に応答して行われてもよいし、ユーザからの明示の指示無しに行われてもよい。

以上が、実施例４に係るワンタイムＡＰＰ送信の例である。

ワンタイムＡＰＰを、ユーザ端末側の全ての処理のために作成するのではなく、最終確認のためだけに作成することができる。最終確認のためのＡＰＰがワンタイムＡＰＰであれば、上述したように、途中確認や初回入力のためのＡＰＰがワンタイムＡＰＰであることに比べて、ワンタイムＡＰＰの作成が簡単なこと、及び、ワンタイムＡＰＰのデータサイズが小さいこと、のうちの少なくとも１つの効果が期待できる。

また、最終確認のためのＡＰＰがワンタイムＡＰＰであれば、ＰＣ１２及び携帯端末１１の両方が不正プログラムに侵入されていたとしても、不正なリクエストの実行を回避できる。

以下、図９に示す流れを例に取り説明するが、まず、ＰＣ１２及び携帯端末１１の両方が不正プログラムに侵入されている場合に起こり得る問題を説明する。

ＰＣ１２に、サービス利用に関係する不正プログラムが侵入していた場合（具体的には、例えば、ユーザがサービス利用のために使用する特定の通信ＡＰＰ（例えばＷｅｂブラウザ）が不正プログラムに感染していた場合）、ユーザから入力された正しいリクエストパラメータが不正なリクエストパラメータに書き換えられてサーバシステム９１３に送信され得る。そして、携帯端末１１にも不正プログラムが侵入しているとすると、携帯端末１１を用いた第１最終確認では、不正なリクエストパラメータが正しいリクエストパラメータに書き戻されて携帯端末１１に表示され得る。この場合、ユーザは、第１最終確認においてＯＫを回答することになる。その後、ＰＣ１２を用いた第２最終確認が行われるが、ＰＣ１２にも不正プログラムが侵入しているので、ＰＣ１２を用いた最終確認でも、不正なリクエストパラメータが正しいリクエストパラメータに書き戻されて携帯端末１１に表示され得る。この場合、ユーザは、第２最終確認においてもＯＫを回答することになる。従って、不正なリクエストが実行され得る。

この流れにおいて、最終確認用ワンタイムＡＰＰが生成及び送信されることで、第２最終確認において、不正なリクエストパラメータが正しいリクエストパラメータに書き戻されることを防ぐことが期待できる。すなわち、最終確認用ワンタイムＡＰＰに埋め込まれた入力値は、不正なリクエストパラメータであり、且つ、上述したように、最終確認用ワンタイムＡＰＰには不正プログラムは侵入していない。このため、ＰＣ１２において起動した最終確認用ワンタイムＡＰＰは、埋め込まれている不正なリクエストパラメータをそのまま表示することとなる。このため、ユーザは、リクエストパラメータが不正であることに気付くので、第２最終確認においてＯＫをサーバシステム９１３に回答することを回避できる。結果として、不正なリクエストの実行を回避できる。

第３の例に限らず他の例でも、不正なリクエストの実行を同様に回避できる。

以上、幾つかの実施例を説明したが、本発明はそれらの実施例に限定されない。

例えば、本発明は、オンライン送金のリクエスト以外のリクエスト全般に適用することができる。

また、実施例１においても、最終確認の結果としての回答が「ＯＫ」から「ＮＧ」に改ざんされる或いは「ＮＧ」から「ＯＫ」に改ざんされるおそれがあるが、そのような改ざんがされたとしても、実施例１と実施例２を組合せることにより、すなわち、実施例１でも第１及び第２の最終表示及び最終確認を行うことにより、不正なリクエスト実行（送金処理の実行）を回避することができる。なお、実施例１と実施例２の組合せにおいて、リクエストパラメータの入力に使用されるユーザ端末の数と、最終確認に使用されるユーザ端末の数は同じであっても違っていてもよい。例えば、リクエストパラメータの入力に３以上のユーザ端末が使用され、最終確認には２つのユーザ端末が使用されてもよい。

また、実施例２において、第１の最終画面がＰＣ１２に表示され、その後に、第２の最終画面が携帯端末１１に表示されてもよい。つまり、リクエストパラメータを入力したユーザ端末に第１の最終画面が表示されてもよい。

また、例えば、第１及び第２ユーザ端末の両方がＰＣでもよい。しかし、第１及び第２ユーザ端末の少なくとも一方が、管理者であっても書換え不可能な記憶領域を有する種類のユーザ端末（例えばスマートフォンのようなスマートデバイス）であってよい。

また、例えば、選択されたリクエスト以外の未処理リクエストに対応した送金先口座情報２０５及び送金金額２０６のうちの少なくとも１つが削除されるタイミングは、最終画面に対する回答（例えば、第２の最終確認の結果としての回答）が入力される前であればよい。

また、例えば、サーバプロセッサ１３２は、ＰＣ１２及び携帯端末１２の少なくとも１つについて、リクエストパラメータが入力されてから別のユーザ端末に切り替える前に、入力されたリクエストパラメータを、そのパラメータを入力したユーザ端末に表示し、入力に誤りがあったとユーザが判断した場合にはユーザからパラメータの修正又は再入力を受け付けてもよい。サーバプロセッサ１３２は、パラメータの修正又は再入力後に、ユーザ端末の切り替えを行ってもよい。

また、例えば、実施例４において、作成されたワンタイムＡＰＰは、リクエストパラメータ等の入力値の電子署名（以下、入力値署名）と、ワンタイムＡＰＰそれ自体の電子署名（以下、ＡＰＰ署名）とのうちの少なくとも一方を含んでよい。入力値署名がワンタイムＡＰＰに含まれていれば、そのワンタイムＡＰＰを受信したユーザ端末が、受信したワンタイムＡＰＰ内の入力値の正当性を、そのワンタイムＡＰＰ内の入力値署名に基づいて判断できる。ＡＰＰ署名がワンタイムＡＰＰに含まれていれば、そのワンタイムＡＰＰを受信したユーザ端末が、そのワンタイムＡＰＰの正当性を、そのワンタイムＡＰＰ内のＡＰＰ署名に基づいて判断できる。

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

Claims (13)

1. 同一のユーザの複数のユーザ端末のうち第１のユーザ端末を含む少なくとも１つのユーザ端末から前記ユーザにより入力されるべき複数のリクエストパラメータを受け付けるパラメータ受付手段と、
   受け付けた複数のリクエストパラメータのうち前記ユーザによる確認が済んでいないリクエストパラメータである未確認パラメータを、前記同一のユーザの複数のユーザ端末のうち、前記第１のユーザ端末とは別の第２のユーザ端末を含む少なくとも１つのユーザ端末に表示させる未確認パラメータ表示手段と、
   前記同一のユーザの複数のユーザ端末のうち、前記第２のユーザ端末を含む２以上のユーザ端末から、それぞれ、リクエスト実行か非実行かの回答を受け付け、前記２以上のユーザ端末からそれぞれ受け付けた２以上の回答のいずれもがリクエスト実行を表す回答であれば、前記受け付けた複数のリクエストパラメータに従いリクエストを実行するリクエスト実行制御手段と
   を備えるサーバシステム。
2. 前記未確認パラメータ表示手段が、
   未確認パラメータを含みリクエスト実行か否かの最終確認のための情報である第１の最終情報を前記第２のユーザ端末に表示させ、
   前記第１の最終情報が含む未確認パラメータと同じ未確認パラメータを含みリクエスト実行か否かの最終確認のための情報である第２の最終情報を、受け付けられた第１の回答がリクエスト実行を表す回答である場合に、前記２以上のユーザ端末のうちの、前記第１のユーザ端末、又は、前記第１及び第２のユーザ端末以外のいずれかのユーザ端末である第３のユーザ端末に表示させる、
   請求項１記載のサーバシステム。
3. 前記未確認パラメータ表示手段が、前記第２の最終情報に加えて、前記第１の回答を、前記第１又は第３のユーザ端末に表示させる、
   請求項２記載のサーバシステム。
4. 前記パラメータ受付手段が、前記複数のリクエストパラメータを前記第１のユーザ端末を含む少なくとも２つのユーザ端末から分けて受け付けるようになっており、
   前記パラメータ受付手段は、受け付けたリクエストパラメータの入力に使用されたユーザ端末と別のユーザ端末でありその受け付けたリクエストパラメータである未確認パラメータが表示されたユーザ端末から、そのリクエストパラメータとは別のリクエストパラメータを受け付ける、
   請求項１乃至３のうちのいずれか１項に記載のサーバシステム。
5. 前記パラメータ受付手段は、リクエスト毎にリクエストＩＤとリクエストパラメータとリクエスト状態とを管理するための管理情報に、受け付けたリクエストパラメータを登録するようになっており、
   前記リクエスト実行制御手段は、前記２以上の回答の全てを受け付ける前に、対象のリクエスト以外の未処理のリクエストに対応した所定のリクエストパラメータを前記管理情報から削除するようになっており、
   前記２以上の回答の各々は、リクエスト実行を表す場合、前記対象のリクエストのリクエストＩＤを含み、
   前記リクエスト実行制御手段は、前記対象のリクエストのＩＤに対応したリクエストを前記管理情報から特定し、特定したリクエストについて前記所定のリクエストパラメータが前記管理情報に登録されていれば、前記特定したリクエストを実行する、
   請求項１乃至４のうちのいずれか１項に記載のサーバシステム。
6. 以下の（ａ）及び（ｂ）をｎ回繰り返すことで（ｎは２以上の整数）、同一のユーザの複数のユーザ端末のうちの少なくとも２つのユーザ端末から前記ユーザにより入力されるべき複数のリクエストパラメータを受け付ける手段と、
   （ａ）前記ユーザにより入力されるべき複数のリクエストパラメータのうちの一部であり未入力のリクエストパラメータをユーザ端末から受け付けること、
   （ｂ）（ａ）で受け付けたリクエストパラメータを、（ａ）で受け付けたリクエストパラメータの入力に使用されたユーザ端末と別のユーザ端末に表示させること、
   前記複数のユーザ端末のうちのいずれかのユーザ端末からリクエスト実行か非実行かの回答を受け付け、前記受け付けた回答がリクエスト実行を表す回答であれば、前記受け付けた複数のリクエストパラメータに従いリクエストを実行するリクエスト実行制御手段と
   を備え、
   ｋ回目の（ａ）におけるユーザ端末は、（ｋ−１）回目の（ｂ）においてリクエストパラメータが表示されたユーザ端末又はそのユーザ端末とは別のユーザ端末である（ｋは２≦ｋ≦ｎを満たす整数）、
   サーバシステム。
7. 同一のユーザの複数のユーザ端末のうち第１のユーザ端末を含む少なくとも１つのユーザ端末から前記ユーザにより入力されるべき複数のリクエストパラメータを受け付け、
   受け付けた複数のリクエストパラメータのうち前記ユーザによる確認が済んでいないリクエストパラメータである未確認パラメータを、前記同一のユーザの複数のユーザ端末のうち、前記第１のユーザ端末とは別の第２のユーザ端末を含む少なくとも１つのユーザ端末に表示させ、
   前記同一のユーザの複数のユーザ端末のうち、前記第２のユーザ端末を含む２以上のユーザ端末から、それぞれ、リクエスト実行か非実行かの回答を受け付け、前記２以上のユーザ端末からそれぞれ受け付けた２以上の回答のいずれもがリクエスト実行を表す回答であれば、前記受け付けた複数のリクエストパラメータに従いリクエストを実行する、
   リクエスト実行制御方法。
8. 以下の（ａ）及び（ｂ）をｎ回繰り返すことで（ｎは２以上の整数）、同一のユーザの複数のユーザ端末のうちの少なくとも２つのユーザ端末から前記ユーザにより入力されるべき複数のリクエストパラメータを受け付け、
   （ａ）前記ユーザにより入力されるべき複数のリクエストパラメータのうちの一部であり未入力のリクエストパラメータをユーザ端末から受け付けること、
   （ｂ）（ａ）で受け付けたリクエストパラメータを、（ａ）で受け付けたリクエストパラメータの入力に使用されたユーザ端末と別のユーザ端末に表示させること、
   前記複数のユーザ端末のうちのいずれかのユーザ端末からリクエスト実行か非実行かの回答を受け付け、前記受け付けた回答がリクエスト実行を表す回答であれば、前記受け付けた複数のリクエストパラメータに従いリクエストを実行し、
   ｋ回目の（ａ）におけるユーザ端末は、（ｋ−１）回目の（ｂ）においてリクエストパラメータが表示されたユーザ端末又はそのユーザ端末とは別のユーザ端末である（ｋは２≦ｋ≦ｎを満たす整数）、
   リクエスト実行制御方法。
9. １つのユーザ端末における複数のＡＰＰ（アプリケーションプログラム）であり異なる複数種類の通信媒体をそれぞれ経由して通信する複数の通信ＡＰＰのうち第１の通信ＡＰＰを含む少なくとも１つの通信ＡＰＰからユーザにより入力されるべき複数のリクエストパラメータを受け付けるパラメータ受付手段と、
   受け付けた複数のリクエストパラメータのうち前記ユーザによる確認が済んでいないリクエストパラメータである未確認パラメータを、前記複数の通信ＡＰＰのうち、前記第１の通信ＡＰＰとは別の第２の通信ＡＰＰを含む少なくとも１つの通信ＡＰＰにより前記ユーザ端末に表示させる未確認パラメータ表示手段と、
   前記複数の通信ＡＰＰのうち、前記第２の通信ＡＰＰを含む２以上の通信ＡＰＰから、それぞれ、リクエスト実行か非実行かの回答を受け付け、前記２以上の通信ＡＰＰからそれぞれ受け付けた２以上の回答のいずれもがリクエスト実行を表す回答であれば、前記受け付けた複数のリクエストパラメータに従いリクエストを実行するリクエスト実行制御手段と
   を備えるサーバシステム。
10. 以下の（ａ）及び（ｂ）をｎ回繰り返すことで（ｎは２以上の整数）、１つのユーザ端末における複数のＡＰＰ（アプリケーションプログラム）であり異なる複数種類の通信媒体をそれぞれ経由して通信する複数の通信ＡＰＰのうちの少なくとも２つの通信ＡＰＰからユーザにより入力されるべき複数のリクエストパラメータを受け付ける手段と、
    （ａ）前記ユーザにより入力されるべき複数のリクエストパラメータのうちの一部であり未入力のリクエストパラメータを前記ユーザ端末の通信ＡＰＰから受け付けること、
    （ｂ）（ａ）で受け付けたリクエストパラメータを、（ａ）で受け付けたリクエストパラメータの入力の際に経由した通信媒体の種類と異なる種類の通信媒体経由で、（ａ）で受け付けたリクエストパラメータの入力に使用された通信ＡＰＰと別の通信ＡＰＰにより前記ユーザ端末に表示させること、
    前記複数の通信ＡＰＰのうちのいずれかの通信ＡＰＰからリクエスト実行か非実行かの回答を受け付け、前記受け付けた回答がリクエスト実行を表す回答であれば、前記受け付けた複数のリクエストパラメータに従いリクエストを実行するリクエスト実行制御手段と
    を備え、
    ｋ回目の（ａ）における通信ＡＰＰは、（ｋ−１）回目の（ｂ）においてリクエストパラメータが表示された通信ＡＰＰ又はその通信ＡＰＰとは別の通信ＡＰＰである（ｋは２≦ｋ≦ｎを満たす整数）、
    サーバシステム。
11. リクエスト実行か非実行かの回答を出す少なくとも１つの通信ＡＰＰが、使用可能回数が１回である又は使用期間が一定期間のＡＰＰであるワンタイムＡＰＰであり、
    前記ワンタイムＡＰＰは、前記複数のリクエストパラメータを受け付けたことを契機に、前記複数のリクエストパラメータを含むＡＰＰとして生成され、前記ユーザ端末に送信されたＡＰＰである、
    請求項９又は１０記載のサーバシステム。
12. 同一のユーザの複数のユーザ端末のうち第１のユーザ端末を含む少なくとも１つのユーザ端末から前記ユーザにより入力されるべき複数のリクエストパラメータを受け付けるパラメータ受付手段と、
    受け付けた複数のリクエストパラメータのうち前記ユーザによる確認が済んでいないリクエストパラメータである未確認パラメータを、前記同一のユーザの複数のユーザ端末のうち、前記第１のユーザ端末とは別の第２のユーザ端末を含む少なくとも１つのユーザ端末に表示させる未確認パラメータ表示手段と、
    前記同一のユーザの複数のユーザ端末のうち、前記第２のユーザ端末を含む２以上のユーザ端末から、それぞれ、リクエスト実行か非実行かの回答を受け付け、前記２以上のユーザ端末からそれぞれ受け付けた２以上の回答のいずれもがリクエスト実行を表す回答であれば、前記受け付けた複数のリクエストパラメータに従いリクエストを実行するリクエスト実行制御手段と
    を備え、
    前記リクエスト実行制御手段は、リクエスト実行か非実行かの回答をユーザ端末で実行されるＡＰＰから受け付けるようになっており、
    リクエスト実行か非実行かの回答を出すＡＰＰが、使用可能回数が１回である又は使用期間が一定期間のＡＰＰであるワンタイムＡＰＰであり、
    前記ワンタイムＡＰＰが、前記複数のリクエストパラメータを受け付けたことを契機に、前記複数のリクエストパラメータを含むＡＰＰとして生成され、前記２以上のユーザ端末のうちの少なくとも１つに送信されたＡＰＰである、
    サーバシステム。
13. 以下の（ａ）及び（ｂ）をｎ回繰り返すことで（ｎは２以上の整数）、同一のユーザの複数のユーザ端末のうちの少なくとも２つのユーザ端末から前記ユーザにより入力されるべき複数のリクエストパラメータを受け付ける手段と、
    （ａ）前記ユーザにより入力されるべき複数のリクエストパラメータのうちの一部であり未入力のリクエストパラメータをユーザ端末から受け付けること、
    （ｂ）（ａ）で受け付けたリクエストパラメータを、（ａ）で受け付けたリクエストパラメータの入力に使用されたユーザ端末と別のユーザ端末に表示させること、
    前記複数のユーザ端末のうちのいずれかのユーザ端末からリクエスト実行か非実行かの回答を受け付け、前記受け付けた回答がリクエスト実行を表す回答であれば、前記受け付けた複数のリクエストパラメータに従いリクエストを実行するリクエスト実行制御手段と
    を備え、
    ｋ回目の（ａ）におけるユーザ端末は、（ｋ−１）回目の（ｂ）においてリクエストパラメータが表示されたユーザ端末又はそのユーザ端末とは別のユーザ端末であり（ｋは２≦ｋ≦ｎを満たす整数）、
    前記リクエスト実行制御手段は、リクエスト実行か非実行かの回答をユーザ端末で実行されるＡＰＰから受け付けるようになっており、
    リクエスト実行か非実行かの回答を出すＡＰＰが、使用可能回数が１回である又は使用期間が一定期間のＡＰＰであるワンタイムＡＰＰであり、
    前記ワンタイムＡＰＰが、前記複数のリクエストパラメータを受け付けたことを契機に、前記複数のリクエストパラメータを含むＡＰＰとして生成され、前記ユーザ端末に送信されたＡＰＰである、
    サーバシステム。

Images