JP2015215910A - Server system and request execution control method - Google Patents
Server system and request execution control method Download PDFInfo
- Publication number
- JP2015215910A JP2015215910A JP2015126169A JP2015126169A JP2015215910A JP 2015215910 A JP2015215910 A JP 2015215910A JP 2015126169 A JP2015126169 A JP 2015126169A JP 2015126169 A JP2015126169 A JP 2015126169A JP 2015215910 A JP2015215910 A JP 2015215910A
- Authority
- JP
- Japan
- Prior art keywords
- request
- user
- parameter
- received
- app
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 43
- 238000004891 communication Methods 0.000 claims abstract description 92
- 238000012790 confirmation Methods 0.000 claims description 69
- 230000004044 response Effects 0.000 claims description 48
- 230000008569 process Effects 0.000 description 34
- 230000005540 biological transmission Effects 0.000 description 16
- 238000012545 processing Methods 0.000 description 14
- 230000004075 alteration Effects 0.000 description 9
- 238000012546 transfer Methods 0.000 description 6
- 241000700605 Viruses Species 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 238000004590 computer program Methods 0.000 description 2
- 238000012937 correction Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000007704 transition Effects 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
Images
Landscapes
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Information Transfer Between Computers (AREA)
Abstract
Description
本発明は、概して、クライアントサーバシステムでのリクエスト実行制御に関する。 The present invention generally relates to request execution control in a client-server system.
クライアントサーバシステムでは、一般に、ユーザが、サーバシステムに対してユーザ登録を行い、ユーザ端末(クライアント)を使用してサーバシステムにログインできた場合に(ユーザ認証が成功した場合に)、ユーザ端末からサーバシステムに対しリクエストを入力(送信)することができる。「ユーザ端末」は、通信機能を有する情報処理端末であり、例えば、デスクトップ型又はモバイル型のパーソナルコンピュータ、スマートフォンのようなスマートデバイス、又は携帯電話機等がある。 Generally, in a client server system, when a user registers with the server system and can log in to the server system using a user terminal (client) (when user authentication is successful), the user terminal A request can be input (transmitted) to the server system. The “user terminal” is an information processing terminal having a communication function, such as a desktop or mobile personal computer, a smart device such as a smartphone, or a mobile phone.
サーバシステムに対するリクエストの1つとして、オンライン送金のリクエストがある。オンライン送金では、一般に、ユーザは、ユーザ端末を使用して、リクエストパラメータ(リクエストで指定するパラメータ)として、送金先口座情報(例えば、送金先の金融機関名、支店名、口座種別及び口座番号を含む情報)と、送金金額とをサーバシステムに入力し、最後に、入力完了のための操作(例えば、サーバシステムから提供された画面上の所定のボタンをクリックすること)を行う。これにより、サーバシステムにより、オンライン送金リクエストが、入力されたリクエストパラメータに従い実行される。すなわち、入力された送金先口座情報が表す送金先口座に、入力された送金金額が送金される。 One request to the server system is an online remittance request. Generally, in online remittance, a user uses a user terminal to specify remittance destination account information (for example, the name of a financial institution at the remittance, branch name, account type, and account number) as request parameters (parameters specified in the request). Information) and the remittance amount are input to the server system, and finally, an operation for completing the input (for example, clicking a predetermined button on the screen provided from the server system) is performed. Thereby, the online remittance request is executed by the server system according to the input request parameters. That is, the input remittance amount is transferred to the remittance destination account represented by the input remittance destination account information.
しかし、中間者攻撃(例えばMITB(Man In The Browser))と呼ばれる攻撃により(例えば、ユーザ端末がスパイアイのようなコンピュータウィルスに感染することにより)、ユーザ端末に入力されサーバシステムに送信される送金金額及び送金先口座情報が、悪意のある第三者の望む不正な情報に書き変えられ、不正な送金金額が、不正な送金先に振り込まれてしまうおそれがある。 However, a remittance that is input to the user terminal and transmitted to the server system by an attack called a man-in-the-middle attack (for example, MITB (Man In The Browser)) (for example, when the user terminal is infected with a computer virus such as spy eye) There is a risk that the money amount and remittance destination account information will be rewritten into incorrect information desired by a malicious third party, and the incorrect remittance amount will be transferred to the illegal remittance destination.
不正なオンライン送金を回避するためにトランザクション署名を使用することが考えられる。具体的には、例えば、ユーザが、自身で署名(トランザクション署名)をリクエストに添付し、リクエストと署名のペアをサーバシステムに送信する。この場合、署名の計算を行うデバイスは、ユーザがオンライン送金のために使用するユーザ端末とは別のデバイスである。別デバイスは、例えば、ハードトークン又はモバイル端末(例えば、携帯電話機、或いはスマートフォンのようなスマートデバイス)である。トークンは、例えば、特許文献1及び2に開示されている。
It is conceivable to use transaction signatures to avoid unauthorized online transfers. Specifically, for example, the user attaches a signature (transaction signature) to the request, and transmits a request / signature pair to the server system. In this case, the device that calculates the signature is a device different from the user terminal that the user uses for online remittance. Another device is, for example, a hard token or a mobile terminal (for example, a smart phone such as a mobile phone or a smartphone). The token is disclosed in
トランザクション署名の使用では、ユーザ端末と別デバイスのそれぞれに同じリクエストパラメータ(例えば、同じ送金先口座情報及び送金金額)を入力しなくてはならない。 In the use of a transaction signature, the same request parameters (for example, the same remittance destination account information and remittance amount) must be input to each of the user terminal and another device.
トランザクション署名の使用は、オンライン送金のリクエストに限らず、ユーザ端末(クライアント)からサーバシステムに入力可能な様々なリクエストについても適用し得る。しかし、ユーザ端末と別デバイスのそれぞれに同じリクエストパラメータを入力しなくてはならないという問題がある。 The use of the transaction signature is not limited to an online remittance request, but can also be applied to various requests that can be input from the user terminal (client) to the server system. However, there is a problem that the same request parameter must be input to each of the user terminal and another device.
サーバシステムが、同一のユーザの複数のユーザ端末又は通信APP(アプリケーションプログラム)のうちの少なくとも1つのユーザ端末又は通信APPからユーザにより入力されるべき複数のリクエストパラメータを受け付け、複数のユーザ端末又は通信APPのうちの2以上のユーザ端末又は通信APPから、それぞれ、リクエスト実行か非実行かの回答を受け付け、2以上のユーザ端末又は通信APPからそれぞれ受け付けた2以上の回答のいずれもがリクエスト実行を表す回答であれば、受け付けた複数のリクエストパラメータに従いリクエストを実行する。 The server system receives a plurality of request parameters to be input by a user from at least one user terminal or communication APP (application program) of the same user, and the plurality of user terminals or communication Accepts a request execution or non-execution response from two or more user terminals or communication APPs of the APP, respectively, and both of the two or more responses received from the two or more user terminals or communication APPs execute the request execution, respectively. If it is an answer, the request is executed according to the received request parameters.
リクエスト実行か非実行かの回答を出す少なくとも1つの通信APPが、使用可能回数が1回である又は使用期間が一定期間のAPPであるワンタイムAPPでよい。ワンタイムAPPは、複数のリクエストパラメータを受け付けたことを契機に、複数のリクエストパラメータを含むAPPとして生成され、ユーザ端末に送信されたAPPでよい。 The at least one communication APP that issues a response indicating whether the request is executed or not executed may be a one-time APP in which the number of usable times is one or the APP is used for a certain period. The one-time APP may be an APP generated as an APP including a plurality of request parameters and transmitted to the user terminal when a plurality of request parameters are received.
いずれかのユーザ端末又は通信APPが不正プログラムに感染していることにより、入力された情報(パラメータ及び回答のいずれか)が改ざんされても、不正なリクエストの実行を回避でき、且つ、それを、同じリクエストパラメータを複数のユーザ端末又は通信APPに入力することなく実現できる。 Since any user terminal or communication APP is infected with a malicious program, even if the input information (either parameter or answer) is falsified, execution of an illegal request can be avoided, and This can be realized without inputting the same request parameters to a plurality of user terminals or communication APPs.
以下、サーバシステムが提供するサービスとしてオンライン送金を例に取り、図面を参照して、幾つかの実施例を説明する。 Hereinafter, some examples will be described with reference to the drawings, taking online remittance as a service provided by the server system.
なお、以下の実施例では、リクエストは、必要なリクエストパラメータと、最終確認の結果としての回答「OK」(リクエスト実行の回答)との両方が揃った場合に実行される。実施例1は、ユーザが入力すべき複数のリクエストパラメータを複数のユーザ端末から分けて入力する例であり、実施例2は、最終確認の結果としての回答「OK」を複数のユーザ端末からそれぞれ入力する例である。実施例1と2の組合せ、すなわち、ユーザが入力すべき複数のリクエストパラメータを複数のユーザ端末から分けて入力し、且つ、最終確認の結果としての回答「OK」を複数のユーザ端末からそれぞれ入力することも可能である。また、実施例1及び実施例2では、ユーザシステムは、同一ユーザの複数のユーザ端末であるが、実施例3では、ユーザシステムは、1つのユーザ端末内の異なる複数の通信APP(アプリケーションプログラム)である。すなわち、実施例3では、「通信APP」が、実施例1及び実施例2の少なくともいずれかにおける「ユーザ端末」に対応する。また、実施例4では、実施例1〜3の少なくとも1つに適用可能であり、サーバシステムからワンタイムAPP(アプリケーションプログラム)がユーザ端末に送信される。 In the following embodiment, a request is executed when both a necessary request parameter and an answer “OK” (answer for request execution) as a result of final confirmation are obtained. The first embodiment is an example in which a plurality of request parameters to be input by a user are input separately from a plurality of user terminals. In the second embodiment, an answer “OK” as a result of the final confirmation is received from a plurality of user terminals. This is an example of input. A combination of the first and second embodiments, that is, a plurality of request parameters to be input by a user are input separately from a plurality of user terminals, and an answer “OK” as a result of the final confirmation is input from a plurality of user terminals. It is also possible to do. In the first embodiment and the second embodiment, the user system is a plurality of user terminals of the same user. In the third embodiment, the user system is a plurality of different communication APPs (application programs) in one user terminal. It is. That is, in the third embodiment, “communication APP” corresponds to the “user terminal” in at least one of the first and second embodiments. The fourth embodiment is applicable to at least one of the first to third embodiments, and a one-time APP (application program) is transmitted from the server system to the user terminal.
図1は、実施例1に係るクライアントサーバシステム全体の構成を示す。 FIG. 1 illustrates a configuration of the entire client server system according to the first embodiment.
本実施例では、各ユーザは、複数のユーザ端末、例えば第1及び第2ユーザ端末を使用して、サーバシステム13が提供するサービスを使用する。言い換えれば、サーバシステム13は、第1ユーザ端末から入力された第1情報と、第2ユーザ端末から入力された第2情報とを使用して、送金を実行する。第1ユーザ端末の一例が、デスクトップ型のPC(Personal Computer)12であり、第2ユーザ端末の一例が、携帯端末11である。PC12及び携帯端末11が、オンライン送金のようなサービスを提供するサーバシステム13と、通信ネットワーク(例えばインターネット)を介して通信する。
In this embodiment, each user uses a service provided by the
PC12は、記憶デバイス121と、通信インターフェイスデバイス123と、入力デバイス125と、表示デバイス124と、それらに接続されたプロセッサ122とを有する。入力デバイス125は、ユーザが情報を入力するために使用するデバイスであり、例えば、キーボード及びポインティングデバイスである。表示デバイス124は、情報を表示するデバイスであり、例えば液晶表示デバイスである。「記憶デバイス」は、本実施例において、1以上の記憶デバイスの集合を意味し、主記憶デバイス(例えば揮発性又は不揮発性のメモリ)と、補助記憶デバイスとのうちの少なくとも主記憶デバイスを含んでよい。補助記憶デバイスは、例えば、HDD(Hard Disk Drive)及びSSD(Solid State Drive)のうちの少なくとも一方でよい。「通信インターフェイスデバイス」は、本実施例において、1以上の通信インターフェイスデバイスの集合を意味し、通信ネットワークを介して外部装置と無線通信又は有線通信する。「プロセッサ」は、本実施例において、1以上のプロセッサの集合を意味し、それぞれのプロセッサは典型的にはマイクロプロセッサ(例えばCPU(Central Processing Unit))でよく、少なくとも1つのプロセッサが、処理の一部(例えば暗号化又は復号化)を行う専用ハードウェア回路(例えばASIC(Application Specific Integrated Circuit))を含んでもよい。
The PC 12 includes a
携帯端末11は、携帯型のユーザ端末であり、例えば、スマートフォンである。スマートフォンは、スマートデバイスの一種である。スマートデバイスは、単なる計算処理だけではなく、多種多様な用途に使用可能な多機能のデバイスであり、典型的には、iPhone(登録商標)のようなスマートフォン、及び、iPad(登録商標)のようなタブレットPCである。携帯端末11は、タッチパネル型ディスプレイ111と、記憶デバイス113と、通信インターフェイスデバイス114と、それらに接続されたプロセッサ112とを有する。タッチパネル型ディスプレイ111は、入力デバイスと表示デバイスが一体になったデバイスである。
The
サーバシステム13は、1以上の計算機であり、記憶デバイス131と、通信インターフェイスデバイス133と、それらに接続されたプロセッサ132とを有する。サーバシステム13は、1以上のサーバを含んだシステムでよい。その1以上のサーバは、物理サーバであっても仮想サーバであってもよい。プロセッサ132が、ユーザ認証及びデバイス認証のうちの少なくとも1つの認証を行うサービスを提供してもよい。例えば、プロセッサ132が、PC12についてはユーザ認証によりユーザの正当性(サーバシステム13に対してユーザ登録済のユーザであるか否か)をチェックし、携帯端末11についてはデバイス認証より携帯端末11の正当性(サーバシステム13に対してデバイス登録済のデバイスであるか否か)をチェックしてもよい。つまり、プロセッサ132は、同一ユーザについて、デバイス登録されたユーザ端末以外のユーザ端末の一例であるPC12と、デバイス登録されたユーザ端末の一例である携帯端末11と通信する。また、プロセッサ132は、オンライン送金サービスを提供する。具体的には、例えば、記憶デバイス131が、ユーザ毎に送金元口座情報を記憶し、且つ、ユーザ操作管理情報を記憶してよい。
The
図2は、ユーザ操作管理情報の構成を示す。 FIG. 2 shows a configuration of user operation management information.
ユーザ操作管理情報200は、例えばテーブルであり、プロセス(ユーザによる操作に従い入力されたリクエストパラメータが指定されることになるリクエスト)毎にレコードを有する。各レコードは、プロセスID201、ユーザID202、リクエスト種類203、送金元口座情報204、送金先口座情報205、送金金額206及び状態207を有する。プロセスID201は、プロセスのIDである。ユーザID202は、プロセスに対応したユーザのIDである。リクエスト種類203は、ユーザにより行われた操作に従うリクエスト種類(例えば、送金、残高照会等)を表す情報である。送金元口座情報204は、リクエストパラメータの一例であり、ユーザに対応した送金元口座を表す情報である。送金先口座情報205は、リクエストパラメータの一例であり、送金先口座を表す情報である。送金元口座情報204及び送金先口座情報205は、それぞれ、例えば、銀行名、支店名、口座種類(例えば、普通、当座)、口座番号及び口座名義人名を含む。リクエストパラメータ204及び205のうちの各々について、全てのパラメータ要素がユーザにより入力されてもよいし、一部のパラメータ要素がユーザにより入力され一部のパラメータ要素から残りのパラメータ要素がサーバシステム13のプロセッサ132により取得されてもよい。送金金額206は、リクエストパラメータの一例であり、送金する金額を表す。状態207は、プロセスの状態(例えば、未処理、処理中及び処理済のいずれであるか)を表す。
The user
本実施例では、送金元口座情報は、PC12を使用してログインしたユーザのユーザ情報(例えばユーザ認証において使用される情報でありユーザ登録において登録されたユーザID及びパスワード)に関連付けられている情報でよく、送金先口座情報は、携帯端末11を使用するユーザにより入力された情報(例えば、銀行名、支店名、口座種類及び口座番号)と、その情報から取得された情報(例えば口座名義人名)とを含んだ情報でよい。サーバシステム13のプロセッサ132は、所定種類のリクエストがPC12のユーザにより選択された場合、選択されたリクエスト種類の新たなリクエストに対応したレコードをユーザ操作管理情報200に追加し、追加したレコードに、新たなリクエストに割り振ったプロセスID201、その選択のための操作をしたユーザのユーザID202、選択されたリクエスト種類203、操作をしたユーザに対応した送金元口座情報204、及び、状態207「未処理」を登録する。選択されたリクエスト種類が「送金」の場合、サーバシステム13のプロセッサ132が、携帯端末11のユーザにより入力された情報を基に送金先口座情報及び送金金額を特定したならば、その送金先口座情報205及び送金金額206を、上記新たなリクエストに対応したレコードに追記する。そして、プロセッサ132は、選択された操作に対応した状態207を「未処理」から「処理中」に更新し、そのリクエストを完了した場合(例えば、送金元口座から送金先口座に送金金額を移動した場合)、状態207を「処理中」から「処理済」に更新する。
In this embodiment, the remittance source account information is information associated with user information of a user who has logged in using the PC 12 (for example, information used for user authentication and registered in user registration and user ID). The remittance destination account information may be information input by a user using the mobile terminal 11 (for example, bank name, branch name, account type and account number) and information obtained from the information (for example, account holder name). ). When a predetermined type of request is selected by the user of the
以下、本実施例で行われる処理を説明する。 Hereinafter, processing performed in the present embodiment will be described.
事前に、サーバシステム13のプロセッサ(以下、サーバプロセッサ)132は、ユーザ登録とデバイス登録を行う。ユーザ登録では、サーバプロセッサ132は、ユーザ認証のためのユーザID及びパスワードを含んだユーザ情報(例えば電子メールアドレスを含んでよい)と、ユーザの送金元口座を表す送金元口座情報とをユーザ端末(例えばPC12)から受けて記憶デバイス131に登録する。デバイス登録では、サーバプロセッサ132は、デバイス認証のための電子署名(例えばユーザID(メッセージ)及び署名)を携帯端末11に発行する。電子署名に含まれるユーザIDは、ユーザ認証で使用されるユーザIDと同じユーザIDでよい。これにより、デバイス登録された携帯端末11とそのユーザが関連付けられる。なお、携帯端末11とユーザの関連付けの方法としては、例えば、ユーザ毎にユーザIDと携帯端末11の個体識別番号との組合せを記憶デバイス131が記憶する等、他の方法が採用されてよい。また、デバイス登録に代えて又は加えて、携帯端末11の電話番号及び電子メールアドレスがユーザ毎に記憶デバイス131に登録されてよい。一ユーザにつき、送金元口座は、複数存在してもよい。なお、送金元口座情報は、オンライン送金の都度にユーザにより入力されてもよい。
In advance, a processor (hereinafter referred to as a server processor) 132 of the
ユーザ登録及びデバイス登録の後、ユーザは、サーバシステム13が提供するオンライン送金サービスを使用することができる。オンライン送金では、PC12と携帯端末11という2つのユーザ端末が使用される。本実施例は、PC12と携帯端末11の一方だけがスパイアイのようなコンピュータウィルスに感染していることはあっても、PC12と携帯端末11が両方ともコンピュータウィルスに感染していることは無いとの前提に基づく。
After user registration and device registration, the user can use the online money transfer service provided by the
図3は、オンライン送金の流れを示す。図4は、オンライン送金における画面遷移を示す。以下、オンライン送金の流れを、図3を主に参照して説明し、適宜、図4を参照することとする。なお、以下の説明では、オンライン送金のためにユーザがPC12を使用してサーバシステム13にログインしている状態(ユーザID及びパスワードを使用したユーザ認証が済んでいる状態)であるとする。また、以下の説明では、サーバシステム13からユーザ端末に提供(送信)された情報(例えば画面)がユーザ端末の表示デバイスに表示されることを、サーバシステム13がユーザ端末に情報を表示する、と簡略することにする。また、以下の説明では、PC12とサーバシステム13間の通信は、通信インターフェイスデバイス123及び133を通じて行われることとし、携帯端末11とサーバシステム13間の通信は、通信インターフェイスデバイス114及び133を通じて行われる。また、サーバシステム13によりユーザ端末に情報(画面)が表示される流れでは、ユーザ端末の記憶デバイス(例えばメモリ)に少なくとも一時的に情報が記憶され、記憶デバイスに記憶されている情報が表示される。また、サーバシステム13により表示される画面は、GUI(Graphical User Interface)であるとする。また、サーバシステム13からユーザ端末に表示される情報は、ユーザ端末のプロセッサで実行されるWebブラウザ(図示せず)(又は専用アプリケーションプログラム)により実行される。また、ユーザによる情報の入力は、ユーザが使用するユーザ端末の入力デバイスを使用して行われる。また、「情報の入力」とは、キーボード(物理的なキーボードでもスクリーンキーボードでもよい)のような入力デバイスを用いたマニュアル入力であってもよいし、複数の選択肢(情報)からクリック等の操作により情報を選択することであってもよい。また、サーバシステム13、PC12及び携帯端末11の各々について、プロセッサにより処理が行われるが、プロセッサは、コンピュータプログラムを実行することにより処理を行うことができる。コンピュータプログラムは、プログラム配布サーバからダウンロードされてもよいし、可搬型の記録媒体からインストールされてもよい。プログラム配布サーバは、サーバシステム13の中にあってもよいし外にあってもよい。
FIG. 3 shows the flow of online remittance. FIG. 4 shows a screen transition in online remittance. Hereinafter, the flow of online remittance will be described with reference mainly to FIG. 3, and FIG. 4 will be referred to as appropriate. In the following description, it is assumed that the user is logged in to the
サーバプロセッサ132は、ログインしているユーザが使用しているPC12に、リクエスト種類選択画面(図4の401)を表示する。サーバプロセッサ132は、リクエスト種類選択画面401からPC12のユーザによりリクエスト種類「送金」が選択され「送信」ボタンが押下されたことを特定し(図3のS301)、ユーザ操作管理情報200を更新する(図3のS302)。具体的には、例えば、サーバプロセッサ132は、レコードをユーザ操作管理情報200に追加し、追加したレコードに、「送金」に対応した新たなリクエストのプロセスID201(サーバプロセッサ132が割り振ったID)、「送金」を選択したユーザのユーザID202、リクエスト種類203「送金」、「送金」を選択したユーザに対応した送金元口座情報204、及び、状態207「未処理」を登録する。なお、サーバシステム13のプロセッサ132は、ユーザから送金元口座情報(但し、送金元口座の名義人名は含まないでよい)の入力を受け付ける画面をPC12に表示し、「送金」の選択に加えて、送金元口座情報の入力をPC12経由でユーザから受けてもよい。また、ユーザに複数の送金元口座情報が関連付けられている場合、サーバプロセッサ132が、PC12のユーザから、ユーザ所望の送金元口座情報の選択を受けてよい。
The
サーバプロセッサ132は、「送金」を選択したユーザのユーザID202とリクエスト種類203「送金」と状態207「未処理」とを含んだ全てのレコードを検索し、PC12ではなく携帯端末11に、検索結果(見つかったレコードのリスト)を表す未処理リスト画面(図4の403)を表示する(図3のS303)。
The
ここでの表示は、途中表示である。具体的には、本実施例において、1つのリクエストについてユーザにより入力されるべき複数のリクエストパラメータのうちの一部のリクエストパラメータがユーザにより入力済の段階で未確認パラメータを表示することを「途中表示」と言い、途中表示された未確認パラメータが正しいか否かの確認を「途中確認」と言う。途中表示に使用されるユーザ端末(例えば携帯端末11)は、途中表示される未確認パラメータ(又はそれの基になる情報)の入力に使用されたユーザ端末(例えばPC12)とは別のユーザ端末である。途中表示は、最終的なリクエスト実行/非実行(OK/NG)を受け付けるための表示ではない。ユーザは、携帯端末11に表示された未処理リスト画面403を見て、PC12に対する操作に従う未確認パラメータを確認することができる。「未確認パラメータ」とは、ユーザ端末を使用して入力されたリクエストパラメータが正しく入力されたか否かの確認が未だユーザによりされていないパラメータである。
The display here is an intermediate display. Specifically, in this embodiment, it is indicated that an unconfirmed parameter is displayed when a part of a plurality of request parameters to be input by the user for one request is already input by the user. And confirming whether or not the unconfirmed parameter displayed in the middle is correct is referred to as “halfway confirmation”. The user terminal (for example, the portable terminal 11) used for the intermediate display is a user terminal different from the user terminal (for example, the PC 12) used for inputting the unconfirmed parameter (or the information on which it is displayed) displayed in the middle. is there. The intermediate display is not a display for accepting final request execution / non-execution (OK / NG). The user can confirm the unconfirmed parameter according to the operation on the
PC12から携帯端末11への切り替えは、以下のように行われてよい。具体的には、例えば、サーバプロセッサ132は、検索が終了した場合に、デバイス登録済のデバイス(実施例では携帯端末11)を使用してサーバシステム13にログインすることのメッセージをPC12に表示する等の方法により、ユーザに携帯端末11を使用したログインを指示してよい。サーバプロセッサ132は、携帯端末11からのログインを、デバイス認証をパスした場合に許可し、その後、検索結果(未確認パラメータ)を携帯端末11に表示(途中表示)してもよい。携帯端末11のログインは、PC12を使用したユーザのログイン前に行われていてもよい。或いは、例えば、サーバプロセッサ132は、検索結果のURL(Uniform Resource Locator)を記載した電子メール又はSMS(Short Message Service)を携帯端末11に送信し、携帯端末11からそのURLへのアクセスを受けた場合に、検索結果(未確認パラメータ)を携帯端末11に表示(途中表示)してもよい。
Switching from the
表示される検索結果は、未処理リクエスト毎に、リクエスト種類203及び送金元口座情報204を含む。なお、本実施例では、検索結果における見つかった未処理リクエストが、送金先口座情報205及び送金金額206の少なくとも1つを含んでいることはない。なぜなら、後述するように、リクエストの実行についてNG(非実行)が回答された又はリクエストの実行についての回答が未入力のまま一定時間が経過した(タイムアウト)の場合には、それらのリクエストパラメータ205及び206の少なくとも1つが、サーバプロセッサ132により削除されるからである。
The displayed search result includes a
サーバプロセッサ132は、未処理リスト画面403から携帯端末11のユーザが所望する未処理リクエストの選択を受け付ける。ここでは、ユーザにより選択された未処理リクエストは、「送金」であるとする。サーバプロセッサ132は、ユーザにより選択された未処理リクエスト「送金」について残りのリクエストパラメータの入力を受け付けるための画面、すなわち、送金先口座情報及び送金金額の入力画面(図4の404)を携帯端末11に表示する。サーバプロセッサ132は、送金先口座情報(但し、名義人名の入力は不要でよい)と送金金額の入力を受け、且つ、「送信」ボタンの押下を受ける(図3のS304)。
The
サーバプロセッサ132は、選択された未処理リクエスト「送金」に対応した状態207を「未処理」から「処理中」に更新し、そのリクエスト「送金」に対応したレコードに、入力された送金先口座情報205及び送金金額206を追記し、最終画面(図4の406)を、携帯端末11ではなくPC12に表示する(図3のS305)。
The
ここでの表示は、最終表示である。具体的には、本実施例において、1つのリクエストについてユーザにより入力されるべき複数のリクエストパラメータの全てが入力済の段階で未確認パラメータを表示することを「最終表示」と言い、最終表示された未確認パラメータが正しいか否かの確認を「最終確認」と言う。最終表示に使用されるユーザ端末(例えばPC12)も、最終表示される未確認パラメータ(又はそれの基になる情報)の入力に使用されたユーザ端末(例えば携帯端末11)とは別のユーザ端末である。つまり、本実施例では、ユーザ端末を使用して入力されたリクエストパラメータが、そのパラメータの入力に使用されたユーザ端末とは別のユーザ端末に表示されるようになっている。ユーザは、PC12に表示された最終画面406を見て、携帯端末11に入力された未確認パラメータを確認することができる。具体的には、最終画面406は、S304で選択されたリクエスト「送金」に対応するレコードに登録されているリクエストパラメータ、例えば、プロセスID201と、送金元口座情報204と、送金先口座情報(携帯端末11により入力画面404で入力されたリクエストパラメータ)205と、送金金額(携帯端末11により入力画面404で入力されたリクエストパラメータ)206とを表示する。最終画面406が表示するリクエストパラメータのうち、少なくとも送金先口座情報及び送金金額(携帯端末11により入力されたリクエストパラメータ)が、未確認パラメータである。
The display here is the final display. Specifically, in this embodiment, displaying all unconfirmed parameters at the stage where all of a plurality of request parameters to be input by the user for one request are already input is called “final display”, and is finally displayed. The confirmation of whether or not the unconfirmed parameters are correct is called “final confirmation”. The user terminal (for example, the PC 12) used for the final display is also a user terminal different from the user terminal (for example, the mobile terminal 11) used for inputting the unconfirmed parameter (or the information on which the final display is performed). is there. That is, in this embodiment, the request parameter input using the user terminal is displayed on a user terminal different from the user terminal used for inputting the parameter. The user can check the unconfirmed parameters input to the
最終表示は、最終的なリクエスト実行/非実行(OK/NG)を受け付けるための表示である。PC12のユーザは、最終画面406に対して、OK(リクエスト実行)かNG(リクエスト非実行)かを回答する。具体的には、ユーザは、最終画面406が表すリクエストパラメータが全て正しく送金が実行されてもよければ、「OK」ボタンを押下する。一方、ユーザは、最終画面406が表すリクエストパラメータに誤りがある又は送金を実行したくなければ、「NG」ボタンを押下する(或いは、最終画面406を閉じる)。サーバプロセッサ132は、最終画面406に対して「OK」又は「NG」という回答を受ける(S306)。
The final display is a display for accepting final request execution / non-execution (OK / NG). The user of the
サーバプロセッサ132は、回答「NG」を受けた場合(又は、最終画面406を表示してから回答が未入力のまま一定時間が経過した場合)、最終画面406に表示されたリクエストパラメータのうち送金先口座情報205及び送金金額206の少なくとも1つを、ユーザ操作管理情報200から削除する。
When the
一方、サーバプロセッサ132は、回答「OK」を受けた場合、リクエストの実行、つまり送金処理を実行する。具体的には、回答「OK」は、プロセスID(最終画面406上のプロセスID)を指定した実行指示である。サーバプロセッサ132は、回答「OK」(実行指示)で指定されているプロセスIDに対応したリクエストを実行する。すなわち、サーバプロセッサ132は、実行指示で指定されているプロセスIDに対応したレコードを特定し、そのレコード上のユーザID202が、PC12のユーザのユーザIDであり、且つ、そのレコードに送金元口座情報204及び送金金額206が登録されていれば、リクエストに従う送金処理を実行し、その送金処理を完了した場合、特定したレコード上の状態207を「処理中」から「処理済」に更新する(S307)。その送金処理は、送金元口座(特定したレコード上の送金元口座情報204が表す口座)から送金先口座(特定したレコード上の送金先口座情報205が表す口座)へ送金金額(特定したレコード上の送金金額206が表す金額)を移動する処理である。
On the other hand, when the
なお、携帯端末11からPC12への切り替えは、以下のように行われてよい。具体的には、例えば、PC12とサーバシステム13が図3のS301以降も互いに通信可能に接続されたままの状態にあり、PC12のプロセッサ122がサーバシステム13に繰り返し問合せを発行し(ポーリングし)、サーバプロセッサ132が、携帯端末11に表示された入力画面404の「送信」ボタンが押下された後に(レコードに送金先口座情報205及び送金金額206が登録された後に)受けた問合せに対して、最終画面406をPC12に表示してもよい。或いは、例えば、サーバプロセッサ132が、PC12から携帯端末11に切り替わった場合にPC12を一旦サーバシステム13からログアウトし、携帯端末11に表示された入力画面404の「送信」ボタンが押下された後に(レコードに送金先口座情報205及び送金金額206が登録された後に)PC12の再度のログインを受けた場合に、最終画面406をPC12に表示してもよい。
Note that switching from the
以上の実施例1では、ユーザ端末を使用して入力されたリクエストパラメータが、そのパラメータの入力に使用されたユーザ端末とは別のユーザ端末に表示されるようになっている。このため、リクエストパラメータを入力したユーザ端末とそのリクエストパラメータが表示されるユーザ端末の一方で不正プログラムによりリクエストパラメータが改ざんされても他方のユーザ端末でその改ざんを検知することができる。 In the above Example 1, the request parameter input using the user terminal is displayed on a user terminal different from the user terminal used for inputting the parameter. For this reason, even if the request parameter is falsified by an unauthorized program on one of the user terminal that has input the request parameter and the user terminal on which the request parameter is displayed, the other user terminal can detect the falsification.
また、実施例1では、ユーザ操作管理情報200が用意される。ユーザ操作管理情報200に複数の未処理のリクエストのリクエストパラメータが保持される。つまり、複数のリクエストを登録し保留(未処理)の状態のまま保持しておくことができる。そして、未処理リクエストについては、送金先口座情報205及び送金金額206の少なくとも1つがユーザ操作管理情報200に登録されていないので、未処理リクエストが誤って又は不正に実行されてしまうことは無い。
In the first embodiment, user
以下、実施例1を考察する。 Example 1 is considered below.
PC12及び携帯端末11のうちの1つが、コンピュータウィルスのような不正プログラムにより中間者攻撃(例えばMITB)を受け得るとする。また、サーバシステム13のサービス(オンライン送金)を利用するユーザに対して、中間者攻撃により不正送金を行う攻撃者(悪意のある第三者)の目的は、主に、以下の(G1)及び(G2)のうちの少なくとも1つ、
(G1)架空のリクエスト(本実施例ではオンライン送金)をサーバシステム13に実行させる、
(G2)ユーザが行おうとしているリクエストのリクエストパラメータを異なるリクエストパラメータに改ざんしてサーバシステム13に実行させる、
であるとする。
Assume that one of the
(G1) cause the
(G2) The request parameter of the request that the user is going to make is altered to a different request parameter and executed by the
Suppose that
この場合、以下の(R1)及び(R2)のうちの少なくとも1つ、
(R1)サーバシステム13がリクエストを処理する前までにユーザが不正(改ざん)を検知できること、
(R2)攻撃者によって改ざんされたリクエストがサーバシステム13に処理され得ない、
が望まれる。一般に、中間者攻撃による不正なオンライン送金は、ユーザが不正を検知できなく、改ざんされたリクエストであってもサーバシステムに処理され得ることが原因で行われてしまうからである。
In this case, at least one of the following (R1) and (R2):
(R1) that the user can detect fraud (falsification) before the
(R2) A request altered by an attacker cannot be processed by the
Is desired. This is because, generally, illegal online remittance due to a man-in-the-middle attack is performed because the user cannot detect fraud and even a falsified request can be processed by the server system.
実施例1において、PC12が不正プログラムに感染しているとする。
In the first embodiment, it is assumed that the
この場合、以下の(X1)〜(X3)のうちの少なくとも1つ、
(X1)S301でPC12からサーバシステム13に送信された情報(選択された操作を表す情報)、
(X2)S305でサーバシステム13によりPC12に表示された最終画面406、
(X3)S306でPC12からサーバシステム13に送信された回答「OK」中のプロセスID、
が、改ざんされる恐れがある。
In this case, at least one of the following (X1) to (X3):
(X1) Information (information indicating the selected operation) transmitted from the
(X2) The
(X3) Process ID in the reply “OK” transmitted from the
However, there is a risk of falsification.
しかし、(X1)〜(X3)のいずれが改ざんされても、ユーザがサーバシステム13の処理前にその改ざんを検知できるか、又は、不正リクエストが実際には処理されないようにすることができる。具体的には、以下の(Y1)〜(Y3)の通りである。
(Y1)(X1)の情報が改ざんされた場合、ユーザは、その改ざんを、S304で携帯端末11に表示される未処理リスト画面403を見て検知できる。なぜなら、(X1)の情報が改ざんされていれば、改ざん後の情報が、未処理リスト画面403に表示されるか、或いは、情報それ自体が未処理リスト画面403に存在しないからである。
(Y2)(X2)の最終画面406に表示されるリクエストパラメータが改ざんされるのは、(X1)の情報が改ざんされた場合である。そうでなければ、最終画面406に表示されるリクエストパラメータを改ざんする理由がないからである。(X1)の情報の改ざんは、上記(Y1)の通り検知可能である。
(Y3)(X3)のプロセスIDが改ざんされた場合、別のプロセスIDがサーバシステム13に指定されることになる。しかし、ユーザがS304で選択したリクエスト以外の未処理リクエストについては送金先口座情報205及び送金金額206の少なくとも1つが削除されているので、別のプロセスIDが指定されても、保留中の未処理リクエストに従う送金処理が実行されることはない。また、別のプロセスIDを有するレコード上のユーザID202が別ユーザのユーザIDであれば、送金処理が実行されることはない。
However, even if any of (X1) to (X3) is tampered with, the user can detect the tampering before the processing of the
(Y1) When the information of (X1) is falsified, the user can detect the falsification by looking at the
(Y2) The request parameter displayed on the
(Y3) When the process ID of (X3) has been tampered with, another process ID is designated to the
以上の通り、PC12が不正プログラムに感染していても、安全性の要件(R1)及び(R2)が満たされる。
As described above, even if the
一方、実施例1において、携帯端末11が不正プログラムに感染しているとする。
On the other hand, in the first embodiment, it is assumed that the
この場合、以下の(P1)及び(P2)のうちの少なくとも1つ、
(P1)S304でサーバシステム13により携帯端末11に表示された画面403、
(P2)S304で携帯端末11によりサーバシステム13に送信されたリクエストパラメータ(入力画面404に入力されたリクエストパラメータ)
が、改ざんされる恐れがある。
In this case, at least one of the following (P1) and (P2):
(P1) a
(P2) Request parameter transmitted to the
However, there is a risk of falsification.
しかし、(P1)及び(P2)の情報のいずれが改ざんされても、ユーザは、最終画面406を見ることで、その改ざんを検知できる。このため、要件(R1)が満たされる。
However, regardless of which of the information (P1) and (P2) has been tampered with, the user can detect the tampering by looking at the
また、PC12が不正プログラムに感染し、攻撃者がPC12から架空のリクエストをサーバシステム13に送っても、送金先口座情報及び送金金額をサーバシステム13はPC12から受け付けないため、S307で送金処理が実行されることはない。このため、要件(R2)が満たされる。
Even if the
以下、実施例2を説明する。その際、実施例1との相違点を主に説明し、実施例1との共通点については説明を省略又は簡略する。 Example 2 will be described below. At that time, differences from the first embodiment will be mainly described, and description of common points with the first embodiment will be omitted or simplified.
実施例1では、ユーザが入力すべき複数のリクエストパラメータがPC12及び携帯端末11から分けて入力されるが、実施例2では、ユーザが入力すべき複数のリクエストパラメータの全てがPC12から入力され、最終確認の結果としての回答「OK」がPC112及び携帯端末11からそれぞれ入力される。
In the first embodiment, a plurality of request parameters to be input by the user are separately input from the
図5は、実施例2に係るオンライン送金の流れを示す。 FIG. 5 shows a flow of online remittance according to the second embodiment.
サーバプロセッサ132が、リクエスト種類の選択と、ユーザが入力すべき複数のリクエストパラメータ(送金先口座情報及び送金金額を含む)を受け付ける画面をPC12に表示し、リクエスト種類「送金」とユーザが入力すべき複数のリクエストパラメータをPC12から受ける(S501)。サーバプロセッサ132は、入力された複数のリクエストパラメータをユーザ操作管理情報200に登録し、且つ、実施例1と同様の方法で最終画面を生成し、最終画面(以下、第1の最終画面)を、PC12ではなく携帯端末11に表示する(S502)。
The
ユーザは、携帯端末11に表示された第1の最終画面が表示する未確認パラメータが正しいか否かの確認、つまり、第1の最終確認を行い、その確認結果に従い回答をサーバシステム13に対し入力する(S503)。回答が「OK」の場合、回答「OK」は、第1の最終画面に表示されたプロセスIDが指定された実行指示でよい。
The user confirms whether or not the unconfirmed parameter displayed on the first final screen displayed on the
サーバプロセッサ132は、携帯端末11から、最終画面に対する回答を受け、受けた回答が「OK」の場合、或いは、受けた回答が「OK」か「NG」かに関わらず、上記と同様の最終画面(以下、第2の最終画面)を、PC12に表示する(S504)。なお、携帯端末11から受けた回答が「NG」であっても第2の最終画面が表示される場合には、PC12に、携帯端末11から入力された回答が「OK」か「NG」かを表す情報が表示されてもよい。その情報は、第2の最終画面が表示する情報に含まれていてもよいし、第2の最終画面の表示とは別に表示されてもよい。
The
ユーザは、PC12に表示された第2の最終画面が表示するリクエストパラメータが正しいか否かの確認、つまり、第2の最終確認を行い、その確認結果に従い回答をサーバシステム13に対し入力する(S505)。なお、回答が「OK」の場合、回答「OK」は、第2の最終画面に表示されたプロセスIDが指定された実行指示でよい。また、第2の最終画面が表示するリクエストパラメータも、「未確認パラメータ」と呼ばれてよい。なぜなら、第2の最終画面が表示するリクエストパラメータは、第1の最終画面で既に表示されたパラメータであるものの、第2の最終確認が済んでいないリクエストパラメータだからである。
The user confirms whether or not the request parameter displayed on the second final screen displayed on the
サーバプロセッサ132は、PC12から回答を受ける。サーバプロセッサ132は、携帯端末11からの回答とPC12からの回答の両方が「OK」の場合にのみ、回答「OK」で指定されているプロセスIDに対応したリクエストに従う送金処理を実行する(S506)。言い換えれば、サーバプロセッサ132は、携帯端末11からの回答とPC12からの回答の少なくとも一方が「NG」の場合(又は、携帯端末11とPC12の少なくとも一方でタイムアウトが生じた場合)、リクエストに従う送金処理を行わない。
The
実施例2によれば、PC12が不正プログラムに感染している場合、S501でPC12からサーバシステム13に送信された少なくとも1つのリクエストパラメータが改ざんされるおそれがある。しかし、そのような改ざんがされたならば、携帯端末11に表示される第1の最終画面からその改ざんを検知することができる。
According to the second embodiment, when the
また、実施例2によれば、携帯端末11が不正プログラムに感染している場合、携帯端末11から送信される回答「OK」中のプロセスIDが改ざんされるおそれがある。しかし、そのような改ざんがされたとしても、保留中の未処理リクエストに従う送金処理が実行されることはない。なぜなら、ユーザがS501で選択したリクエスト以外の未処理リクエストについては送金先口座情報及び送金金額の少なくとも1つが削除されているからである。
Further, according to the second embodiment, when the
また、実施例2によれば、携帯端末11が不正プログラムに感染している場合、携帯端末11から送信される回答が「OK」から「NG」に改ざんされるおそれがある。しかし、そのような改ざんがされたならば、携帯端末11からの回答とPC12からの回答の両方が「OK」の場合にのみリクエストを実行する(送金処理を実行する)という条件が満たされないので、不正な送金処理の実行は回避できる。また、そのような改ざんがされたならば、PC12に第2の最終画面が表示されないので(又は、携帯端末11からの回答を表す情報がPC12に表示されるので)、その改ざんを検知できる。
Further, according to the second embodiment, when the
また、実施例2によれば、携帯端末11が不正プログラムに感染している場合、携帯端末11から送信される回答が「NG」から「OK」に改ざんされるおそれがある。しかし、そのような改ざんがされたならば、「NG」を回答したにも関わらずPC12に第2の最終画面が表示されるので(又は、携帯端末11からの回答を表す情報がPC12に表示されるので)、その改ざんを検知できる。
Further, according to the second embodiment, when the
また、実施例2によれば、PC12が不正プログラムに感染している場合、PC12から送信される回答が「OK」から「NG」に改ざんされるおそれがある。しかし、そのような改ざんがされたならば、携帯端末11からの回答とPC12からの回答の両方が「OK」の場合にのみリクエストを実行する(送金処理を実行する)という条件が満たされないので、不正な送金処理の実行は回避できる。また、リクエストが実行されないままになるという事実から、そのような改ざんがされたことの可能性を検知できる。
Further, according to the second embodiment, when the
また、実施例2によれば、PC12が不正プログラムに感染している場合、PC12から送信される回答が「NG」から「OK」に改ざんされるおそれがある。しかし、第2の最終確認で「NG」を回答するのであれば、第1の最終確認で既に「NG」を回答していると考えられるので、その改ざんが問題になるおそれはない。
Further, according to the second embodiment, when the
以上が、実施例2の説明である。 The above is the description of the second embodiment.
なお、最終表示及び最終確認には、PC12及び携帯端末11のような2台のユーザ端末に限らず、3以上のユーザ端末が使用されてもよい。すなわち、サーバプロセッサ132は、複数のユーザ端末から、それぞれ、リクエスト実行か非実行かの回答を受け付け、同一ユーザについてリクエスト実行を表す回答が所定数以上集まった場合に(つまり、リクエスト実行を回答したユーザ端末の数が所定数以上の場合に)、受け付けた複数のリクエストパラメータに従いリクエストを実行することができる。複数の回答をそれぞれ出す複数のユーザ端末に、リクエストパラメータを入力したユーザ端末が含まれていなくてもよい。例えば、サーバプロセッサ132は、リクエストパラメータの入力元のユーザ端末とは別の2以上のユーザ端末に最終表示を行いそれら別の2以上のユーザ端末からそれぞれ回答(OK又はNG)を受け付けてもよい。
Note that the final display and final confirmation are not limited to two user terminals such as the
また、最終表示及び回答の受け付けは、シーケンシャルに行われることに代えて、パラレルに行われてよい。すなわち、サーバプロセッサ132は、並行して、2以上のユーザ端末に最終画面を表示し回答(OK/NG)を受け付けてよい。サーバプロセッサ132は、全ての回答が揃い、且つ、全ての回答が「OK」の場合に、リクエストを実行してよい。また、サーバプロセッサ132は、リクエスト実行した旨のメッセージを、最後に受け付けた回答の入力元ユーザ端末に表示してよい。
Further, the final display and the reception of the answer may be performed in parallel instead of being performed sequentially. That is, the
以下、実施例3を説明する。その際、実施例1及び2との相違点を主に説明し、実施例1及び2との共通点については説明を省略又は簡略する。 Example 3 will be described below. At that time, the differences from the first and second embodiments will be mainly described, and the description of the common points with the first and second embodiments will be omitted or simplified.
実施例1及び2では、ユーザシステムは、同一ユーザの複数のユーザ端末であるが、実施例3では、ユーザシステムは、同一ユーザの1つのユーザ端末内の異なる複数の通信APP(アプリケーションプログラム)である。すなわち、実施例3では、「通信APP」が、実施例1及び実施例2の少なくともいずれかにおける「ユーザ端末」に対応する。 In the first and second embodiments, the user system is a plurality of user terminals of the same user. In the third embodiment, the user system is a plurality of different communication APPs (application programs) in one user terminal of the same user. is there. That is, in the third embodiment, “communication APP” corresponds to the “user terminal” in at least one of the first and second embodiments.
図6は、実施例3に係るクライアントサーバシステム全体の構成を示す。 FIG. 6 illustrates a configuration of the entire client server system according to the third embodiment.
実施例3では、ユーザは、1つのユーザ端末、例えば携帯端末11のみで、オンライン送金のようなリクエストをサーバシステム13に実行させることができる。
In the third embodiment, the user can cause the
具体的には、携帯端末11の記憶デバイス113には、複数の通信APP601が記憶されており、プロセッサ112によりそれら複数の通信APP601の少なくとも1つが実行される。複数の通信APP601は、異なる複数種類の通信媒体をそれぞれ経由して通信する複数のAPPである。なお、通信媒体の種類の具体例としては、インターネット通信、SMS(Short Message Service)通信、音声通信(例えばインターネットとは異なるネットワーク(例えば電話網)経由の音声通信)等がある。従って、例えば、通信APPとしては、インターネット経由の通信を行うWebブラウザ、SMS通信を行うSMS通信APP、インターネットとは異なるネットワーク経由の音声通信のための音声通信APP等がある。
Specifically, a plurality of communication APPs 601 are stored in the
実施例3が例えば実施例1に適用される場合、図3のS301は、携帯端末11における第1の通信APPにより行われ、図3のS304(途中確認)は、携帯端末11における第2の通信APPにより行われ、図3のS306(最終確認)は、携帯端末11における第1又は第3の通信APPにより行われてよい。実施例3が例えば実施例2に適用される場合、図5のS501は、携帯端末11における第1の通信APPにより行われ、図5のS504(第1最終確認)は、携帯端末11における第2の通信APPにより行われ、図5のS505(第2最終確認)は、携帯端末11における第1又は第3の通信APPにより行われてよい。第1〜第3の通信APPのうちの少なくとも1つが、Webブラウザでよく、それ以外の通信APPは、Webブラウザが利用する通信媒体とは異なる種類の通信媒体を利用する通信APPでよい。なお、実施例1及び2の各々では、PC12及び携帯端末11の各々において、Webブラウザ経由で、情報入力(例えば送金先口座情報等のパラメータ入力や、回答入力等)や情報表示(例えば最終表示等)が行われてよい。
When the third embodiment is applied to, for example, the first embodiment, S301 in FIG. 3 is performed by the first communication APP in the
以上の通り、実施例3では、リクエスト実行までの一連の流れにおいて、同一ユーザ端末内の異なる通信APP601が使用される。いずれかの通信APP601が不正プログラムに感染していることにより、入力された情報(パラメータ及び回答のいずれか)が改ざんされても、不正なリクエストの実行を回避でき、且つ、それを、同じリクエストパラメータを複数の通信APP601に入力することなく実現できる。 As described above, in the third embodiment, different communication APPs 601 in the same user terminal are used in a series of flow until request execution. Since any communication APP 601 is infected with a malicious program, even if the input information (either parameter or answer) is falsified, it is possible to avoid execution of an illegal request, and for the same request This can be realized without inputting parameters to a plurality of communication APPs 601.
以下、実施例4を説明する。その際、実施例1〜3との相違点を主に説明し、実施例1〜3との共通点については説明を省略又は簡略する。 Example 4 will be described below. At that time, differences from the first to third embodiments will be mainly described, and description of common points with the first to third embodiments will be omitted or simplified.
実施例4は、実施例1〜3のうちの少なくとも1つに適用できる。実施例4では、少なくとも1つのユーザ端末(上記実施例ではPC12及び携帯端末11)で実行される複数のAPP(通信APP)のうちの少なくとも1つのAPPが、「ワンタイムAPP」である。本実施例で言う「ワンタイムAPP」とは、リクエスト実行までの一連の手続きにおいてサーバシステム13(又は別のプログラムソース(例えばサーバシステム13以外のサーバ))において生成されユーザ端末に送信されるAPPであり、且つ、使用可能回数が1回である又は使用可能期間が一定期間であるAPPである。つまり、本実施例において、「ワンタイム」とは、1回又は一定期間を意味する。なお、1回の使用とは、起動したAPPにより表示された画面に対して所定のユーザ操作がされること(例えば、「送信」又は「回答」等の所定のボタンが押されること)でよい。一定期間の使用とは、ワンタイムAPPがユーザ端末に受信されてから(又はユーザ端末で初めて起動してから)の経過時間が所定の閾値になるまでの使用でよい。ワンタイムAPPは、Webブラウザのようにインターネットを経由して通信するAPPでもよいし、インターネットと異なる種類の通信媒体を経由して通信するAPPでもよい。
The fourth embodiment can be applied to at least one of the first to third embodiments. In the fourth embodiment, at least one APP among a plurality of APPs (communication APPs) executed by at least one user terminal (
予めユーザ端末にインストールされているAPP(例えばWebブラウザ)には、やがて、不正プログラムが侵入することがあり得るが、本実施例では、上記一連の手続きにおいて必要なタイミングで生成されユーザ端末に送信されたAPPであるワンタイムAPPが実行される。ワンタイムAPPは、必要なタイミングで生成され送信されるので、不正プログラムが侵入するおそれは低く、故に、そのAPPからサーバシステム13に送信される情報(回答)が不正に改ざんされるおそれは低い。
Although an unauthorized program may intrude into an APP (for example, a Web browser) installed in the user terminal in advance, in the present embodiment, it is generated and transmitted to the user terminal at a necessary timing in the above series of procedures. One-time APP, which is a registered APP, is executed. Since the one-time APP is generated and transmitted at a necessary timing, there is a low possibility that an unauthorized program will intrude. Therefore, there is a low possibility that information (answer) transmitted from the APP to the
また、本実施例では、図3のS301及び図5のS501のような初回入力で使用されるAPPは、ワンタイムAPPでなくてよく、図3のS304のような途中確認、及び、図3のS306、図5のS503及び図5のS505のような最終確認のうちの少なくとも1つで使用されるAPPが、ワンタイムAPPでよい。特に、OK/NGの最終確認のためのAPPがワンタイムAPPであれば、途中確認や初回入力のためのAPPがワンタイムAPPであることに比べて、ワンタイムAPPの作成が簡単なこと、及び、ワンタイムAPPのデータサイズが小さいこと、のうちの少なくとも1つの効果が期待できる。例えば、最終確認のためのAPPに関しては、最終確認のために表示される全ての情報(例えばリクエストパラメータ)をAPPにとってのパラメータ(入力値)とし、OKかNGの回答を受け付けるインターフェース(例えばボタン)だけを構成要素とするシンプルなAPP構成とすることが期待できる。故に、複数タイプのリクエストの実行に適用できる汎用性の高いワンタイムAPPとすることも期待できる。 Further, in this embodiment, the APP used for the first input as in S301 in FIG. 3 and S501 in FIG. 5 does not have to be a one-time APP, and an intermediate confirmation as in S304 in FIG. The APP used in at least one of the final confirmations such as S306 of FIG. 5, S503 of FIG. 5 and S505 of FIG. 5 may be a one-time APP. In particular, if the APP for final confirmation of OK / NG is a one-time APP, the creation of a one-time APP is easier compared to the one-time APP for the intermediate confirmation or initial input, In addition, at least one of the effects of a small one-time APP data size can be expected. For example, with regard to APP for final confirmation, all information (for example, request parameters) displayed for final confirmation is used as an APP parameter (input value), and an interface for accepting an OK or NG response (for example, a button) It can be expected to have a simple APP configuration with only the component. Therefore, a highly versatile one-time APP that can be applied to the execution of multiple types of requests can be expected.
また、ワンタイムAPPのユーザ端末への送信として、ユーザ端末からのAPPリクエストに応答してダウンロードされるいわゆるプル送信でなく、ユーザ端末からのAPPリクエスト無しに送信されるいわゆるプッシュ送信が採用されてよい。また、ワンタイムAPPの生成完了がプッシュでユーザ端末に通知され、その通知がユーザ端末で起動された場合に、ワンタイムAPPをユーザ端末にダウンロードするか否かの問合せがユーザ端末のプロセッサにより表示され、ダウンロードするとの回答が入力された場合に、ユーザ端末のプロセッサによりワンタイムAPPがダウンロードされてよい。 Further, as a transmission to the user terminal of the one-time APP, a so-called push transmission that is transmitted without an APP request from the user terminal is adopted instead of a so-called pull transmission that is downloaded in response to an APP request from the user terminal. Good. Further, when the user terminal is notified of the completion of the generation of the one-time APP and the notification is activated on the user terminal, an inquiry as to whether or not to download the one-time APP to the user terminal is displayed by the processor of the user terminal. When a response to download is input, the one-time APP may be downloaded by the processor of the user terminal.
図7は、実施例4に係るワンタイムAPP送信の第1の例を示す。 FIG. 7 illustrates a first example of one-time APP transmission according to the fourth embodiment.
この第1の例は、実施例1(図3に示したオンライン送金流れ)にワンタイムAPP送信が適用された例である。 This first example is an example in which one-time APP transmission is applied to the first embodiment (online remittance flow shown in FIG. 3).
サーバプロセッサ732(サーバシステム713内のプロセッサ)は、図3のS305に代えて、S705を行う。すなわち、サーバプロセッサ732は、S301及びS304で入力された全てのリクエストパラメータ(及び回答内容)を入力値として含んだ最終確認用ワンタイムAPP700を生成し、生成した最終確認用ワンタイムAPP700を、PC12に送信する。最終確認用ワンタイムAPP700は、最終確認のためのAPPである。具体的には、例えば、最終確認用ワンタイムAPP700は、入力値の表示のための機能と、最終回答の受付の機能(例えば最終回答OK/NGのそれぞれのボタン)とを有する。
The server processor 732 (the processor in the server system 713) performs S705 instead of S305 in FIG. That is, the server processor 732 generates a final confirmation one-
PC12が、最終確認用ワンタイムAPP700を受信する。PC12では、S306に代えて、S706が行われる。すなわち、PC12において、最終確認用ワンタイムAPP700が、例えば手動又は自動で、起動する。起動した最終確認用ワンタイムAPP700は、内部に埋め込まれている入力値(リクエストパラメータ及び回答内容)を表示する。最終確認用ワンタイムAPP700は、表示した入力値の正否の回答(送金のようなリクエストの実行についてのOK/NGを含む)をユーザから受け、入力された回答を、サーバシステム713に送信する。
The
図8は、実施例4に係るワンタイムAPP送信の第2の例を示す。 FIG. 8 illustrates a second example of one-time APP transmission according to the fourth embodiment.
この第2の例は、実施例1(図3に示したオンライン送金流れ)と実施例3の組合せにワンタイムAPP送信が適用された例である。 The second example is an example in which the one-time APP transmission is applied to the combination of the first embodiment (online remittance flow shown in FIG. 3) and the third embodiment.
すなわち、S301、S304及びS706は、携帯端末11で行われる。S301は、第1種の通信媒体経由の通信を行う第1の通信APPにより行われる。S304は、第2種の通信媒体(第1種の通信媒体と異なる)経由の通信を行う第2の通信APPにより行われる。S705で生成される最終確認用ワンタイムAPP800は、携帯端末11で実行可能なAPPであり、第3種(又は第1種)の通信媒体経由の通信を行う通信APPである。
That is, S301, S304, and S706 are performed by the
なお、S301、S304及びS706は、携帯端末11に代えてPC12で行われてもよい。
Note that S301, S304, and S706 may be performed by the
図9は、実施例4に係るワンタイムAPP送信の第3の例を示す。 FIG. 9 illustrates a third example of one-time APP transmission according to the fourth embodiment.
この第3の例は、実施例2(図5に示したオンライン送金流れ)にワンタイムAPP送信が適用された例である。 The third example is an example in which the one-time APP transmission is applied to the second embodiment (online remittance flow shown in FIG. 5).
サーバプロセッサ932(サーバシステム913内のプロセッサ)は、図5のS504に代えて、S904を行う。すなわち、サーバプロセッサ732は、S501で入力された全てのリクエストパラメータ(及びS503で入力された回答内容)を入力値として含んだ最終確認用ワンタイムAPP800を生成し、生成した最終確認用ワンタイムAPP800を、PC12に送信する。
The server processor 932 (the processor in the server system 913) performs S904 instead of S504 in FIG. That is, the server processor 732 generates the final confirmation one-
PC12が、最終確認用ワンタイムAPP800を受信する。PC12では、S505に代えて、S905が行われる。すなわち、PC12において、最終確認用ワンタイムAPP800が、例えば手動又は自動で、起動する。起動した最終確認用ワンタイムAPP700は、内部に埋め込まれている入力値(リクエストパラメータ及び回答内容)を表示する。最終確認用ワンタイムAPP700は、表示した入力値の正否の回答(送金のようなリクエストの実行についてのOK/NGを含む)をユーザから受け、入力された回答を、サーバシステム713に送信する。
The
図10は、実施例4に係るワンタイムAPP送信の第4の例を示す。 FIG. 10 illustrates a fourth example of one-time APP transmission according to the fourth embodiment.
この第4の例は、実施例2(図5に示したオンライン送金流れ)と実施例3の組合せにワンタイムAPP送信が適用された例である。 The fourth example is an example in which the one-time APP transmission is applied to the combination of the second embodiment (online remittance flow shown in FIG. 5) and the third embodiment.
すなわち、S501、S503及びS905は、携帯端末11で行われる。S501は、第1種の通信媒体経由の通信を行う第1の通信APPにより行われる。S503は、第2種の通信媒体(第1種の通信媒体と異なる)経由の通信を行う第2の通信APPにより行われる。S904で生成される最終確認用ワンタイムAPP900は、携帯端末11で実行可能なAPPであり、第3種(又は第1種)の通信媒体経由の通信を行う通信APPである。
That is, S501, S503, and S905 are performed by the
なお、S501、S503及びS905は、携帯端末11に代えてPC12で行われてもよい。
Note that S501, S503, and S905 may be performed by the
第1〜第4の例において、最終確認用ワンタイムAPPは、その1回の使用後、又は、ユーザ端末に受信されてから(又は起動してから)一定期間経過後、そのワンタイムAPPを受信したユーザ端末において無効となってよい。ユーザ端末においてAPPが無効になるとは、APPが起動しないことでもよいし、APPが起動してもユーザからAPPが回答を受け付けないことでもよいし、ユーザ端末からAPPが消去される(アンインストールされる)ことでもよい。例えば、最終確認用ワンタイムAPPが入力値の正否の回答をサーバシステムに送信したことを契機に、又は、最終確認用ワンタイムAPPがユーザ端末に受信されてから(又は起動してから)一定期間経過したことを契機に、その最終確認用ワンタイムAPPが、ユーザ端末のOS(オペレーティングシステム)の所定の機能をコールすることにより、ユーザ端末からアンインストールされてよい(つまり確認用ワンタイムAPPの使用回数上限が1回でよい)。ワンタイムAPPのユーザ端末からのアンインストールは、ユーザからの明示に指示に応答して行われてもよいし、ユーザからの明示の指示無しに行われてもよい。 In the first to fourth examples, the one-time APP for final confirmation is the one-time APP after the first use or after a certain period of time has elapsed since it was received (or activated) by the user terminal. It may be invalid at the received user terminal. When APP is invalidated in a user terminal, APP may not be activated, APP may not be accepted even if APP is activated, or APP is deleted from the user terminal (uninstalled) It may be. For example, when the final confirmation one-time APP has transmitted an answer to the server system whether the input value is correct or not, or after the final confirmation one-time APP is received (or started) by the user terminal. When the period has elapsed, the final confirmation one-time APP may be uninstalled from the user terminal by calling a predetermined function of the OS (operating system) of the user terminal (that is, the confirmation one-time APP). Can be used once). The uninstallation of the one-time APP from the user terminal may be performed in response to an explicit instruction from the user or may be performed without an explicit instruction from the user.
以上が、実施例4に係るワンタイムAPP送信の例である。 The above is an example of one-time APP transmission according to the fourth embodiment.
ワンタイムAPPを、ユーザ端末側の全ての処理のために作成するのではなく、最終確認のためだけに作成することができる。最終確認のためのAPPがワンタイムAPPであれば、上述したように、途中確認や初回入力のためのAPPがワンタイムAPPであることに比べて、ワンタイムAPPの作成が簡単なこと、及び、ワンタイムAPPのデータサイズが小さいこと、のうちの少なくとも1つの効果が期待できる。 One-time APP can be created only for final confirmation, not for all processing on the user terminal side. If the APP for final confirmation is a one-time APP, as described above, it is easier to create a one-time APP compared to the one-time APP for an intermediate confirmation or initial input, and The effect of at least one of the small one-time APP data size can be expected.
また、最終確認のためのAPPがワンタイムAPPであれば、PC12及び携帯端末11の両方が不正プログラムに侵入されていたとしても、不正なリクエストの実行を回避できる。
If the APP for final confirmation is a one-time APP, even if both the
以下、図9に示す流れを例に取り説明するが、まず、PC12及び携帯端末11の両方が不正プログラムに侵入されている場合に起こり得る問題を説明する。
Hereinafter, the flow shown in FIG. 9 will be described as an example. First, problems that may occur when both the
PC12に、サービス利用に関係する不正プログラムが侵入していた場合(具体的には、例えば、ユーザがサービス利用のために使用する特定の通信APP(例えばWebブラウザ)が不正プログラムに感染していた場合)、ユーザから入力された正しいリクエストパラメータが不正なリクエストパラメータに書き換えられてサーバシステム913に送信され得る。そして、携帯端末11にも不正プログラムが侵入しているとすると、携帯端末11を用いた第1最終確認では、不正なリクエストパラメータが正しいリクエストパラメータに書き戻されて携帯端末11に表示され得る。この場合、ユーザは、第1最終確認においてOKを回答することになる。その後、PC12を用いた第2最終確認が行われるが、PC12にも不正プログラムが侵入しているので、PC12を用いた最終確認でも、不正なリクエストパラメータが正しいリクエストパラメータに書き戻されて携帯端末11に表示され得る。この場合、ユーザは、第2最終確認においてもOKを回答することになる。従って、不正なリクエストが実行され得る。
When a malicious program related to service use has infiltrated into the PC 12 (specifically, for example, a specific communication APP (for example, a Web browser) used by the user for using the service was infected with the malicious program) ), The correct request parameter input by the user can be rewritten to an invalid request parameter and transmitted to the server system 913. If an unauthorized program has also entered the
この流れにおいて、最終確認用ワンタイムAPPが生成及び送信されることで、第2最終確認において、不正なリクエストパラメータが正しいリクエストパラメータに書き戻されることを防ぐことが期待できる。すなわち、最終確認用ワンタイムAPPに埋め込まれた入力値は、不正なリクエストパラメータであり、且つ、上述したように、最終確認用ワンタイムAPPには不正プログラムは侵入していない。このため、PC12において起動した最終確認用ワンタイムAPPは、埋め込まれている不正なリクエストパラメータをそのまま表示することとなる。このため、ユーザは、リクエストパラメータが不正であることに気付くので、第2最終確認においてOKをサーバシステム913に回答することを回避できる。結果として、不正なリクエストの実行を回避できる。
In this flow, by generating and transmitting the final confirmation one-time APP, it can be expected to prevent the invalid request parameter from being written back to the correct request parameter in the second final confirmation. That is, the input value embedded in the final confirmation one-time APP is an invalid request parameter, and as described above, no unauthorized program has entered the final confirmation one-time APP. For this reason, the final confirmation one-time APP activated in the
第3の例に限らず他の例でも、不正なリクエストの実行を同様に回避できる。 The execution of an illegal request can be similarly avoided in other examples as well as the third example.
以上、幾つかの実施例を説明したが、本発明はそれらの実施例に限定されない。 Although several embodiments have been described above, the present invention is not limited to these embodiments.
例えば、本発明は、オンライン送金のリクエスト以外のリクエスト全般に適用することができる。 For example, the present invention can be applied to all requests other than online money transfer requests.
また、実施例1においても、最終確認の結果としての回答が「OK」から「NG」に改ざんされる或いは「NG」から「OK」に改ざんされるおそれがあるが、そのような改ざんがされたとしても、実施例1と実施例2を組合せることにより、すなわち、実施例1でも第1及び第2の最終表示及び最終確認を行うことにより、不正なリクエスト実行(送金処理の実行)を回避することができる。なお、実施例1と実施例2の組合せにおいて、リクエストパラメータの入力に使用されるユーザ端末の数と、最終確認に使用されるユーザ端末の数は同じであっても違っていてもよい。例えば、リクエストパラメータの入力に3以上のユーザ端末が使用され、最終確認には2つのユーザ端末が使用されてもよい。 Also in the first embodiment, there is a possibility that the answer as a result of the final confirmation may be falsified from “OK” to “NG”, or may be falsified from “NG” to “OK”. Even if the first embodiment and the second embodiment are combined, that is, the first and second final display and the final confirmation are performed also in the first embodiment, an illegal request execution (execution of remittance processing) is performed. It can be avoided. In the combination of the first embodiment and the second embodiment, the number of user terminals used for inputting request parameters may be the same as or different from the number of user terminals used for final confirmation. For example, three or more user terminals may be used for inputting request parameters, and two user terminals may be used for final confirmation.
また、実施例2において、第1の最終画面がPC12に表示され、その後に、第2の最終画面が携帯端末11に表示されてもよい。つまり、リクエストパラメータを入力したユーザ端末に第1の最終画面が表示されてもよい。
In the second embodiment, the first final screen may be displayed on the
また、例えば、第1及び第2ユーザ端末の両方がPCでもよい。しかし、第1及び第2ユーザ端末の少なくとも一方が、管理者であっても書換え不可能な記憶領域を有する種類のユーザ端末(例えばスマートフォンのようなスマートデバイス)であってよい。 Further, for example, both the first and second user terminals may be PCs. However, at least one of the first and second user terminals may be a type of user terminal (for example, a smart device such as a smartphone) having a storage area that cannot be rewritten even by an administrator.
また、例えば、選択されたリクエスト以外の未処理リクエストに対応した送金先口座情報205及び送金金額206のうちの少なくとも1つが削除されるタイミングは、最終画面に対する回答(例えば、第2の最終確認の結果としての回答)が入力される前であればよい。
In addition, for example, the timing at which at least one of the remittance
また、例えば、サーバプロセッサ132は、PC12及び携帯端末12の少なくとも1つについて、リクエストパラメータが入力されてから別のユーザ端末に切り替える前に、入力されたリクエストパラメータを、そのパラメータを入力したユーザ端末に表示し、入力に誤りがあったとユーザが判断した場合にはユーザからパラメータの修正又は再入力を受け付けてもよい。サーバプロセッサ132は、パラメータの修正又は再入力後に、ユーザ端末の切り替えを行ってもよい。
In addition, for example, the
また、例えば、実施例4において、作成されたワンタイムAPPは、リクエストパラメータ等の入力値の電子署名(以下、入力値署名)と、ワンタイムAPPそれ自体の電子署名(以下、APP署名)とのうちの少なくとも一方を含んでよい。入力値署名がワンタイムAPPに含まれていれば、そのワンタイムAPPを受信したユーザ端末が、受信したワンタイムAPP内の入力値の正当性を、そのワンタイムAPP内の入力値署名に基づいて判断できる。APP署名がワンタイムAPPに含まれていれば、そのワンタイムAPPを受信したユーザ端末が、そのワンタイムAPPの正当性を、そのワンタイムAPP内のAPP署名に基づいて判断できる。 Further, for example, in the fourth embodiment, the created one-time APP includes an electronic signature of an input value such as a request parameter (hereinafter referred to as an input value signature) and an electronic signature of the one-time APP itself (hereinafter referred to as an APP signature). May be included. If the input value signature is included in the one-time APP, the user terminal that has received the one-time APP determines the validity of the input value in the received one-time APP based on the input value signature in the one-time APP. Can be judged. If the APP signature is included in the one-time APP, the user terminal that has received the one-time APP can determine the validity of the one-time APP based on the APP signature in the one-time APP.
11…携帯端末、12…PC、13…サーバシステム 11 ... mobile terminal, 12 ... PC, 13 ... server system
Claims (13)
受け付けた複数のリクエストパラメータのうち前記ユーザによる確認が済んでいないリクエストパラメータである未確認パラメータを、前記複数のユーザ端末のうちの少なくとも1つのユーザ端末に表示させる未確認パラメータ表示手段と、
前記複数のユーザ端末のうちの2以上のユーザ端末から、それぞれ、リクエスト実行か非実行かの回答を受け付け、前記2以上のユーザ端末からそれぞれ受け付けた2以上の回答のいずれもがリクエスト実行を表す回答であれば、前記受け付けた複数のリクエストパラメータに従いリクエストを実行するリクエスト実行制御手段と
を備えるサーバシステム。 Parameter accepting means for accepting a plurality of request parameters to be input by the user from at least one user terminal among a plurality of user terminals of the same user;
Unconfirmed parameter display means for displaying an unconfirmed parameter that is a request parameter that has not been confirmed by the user among the plurality of received request parameters, on at least one user terminal of the plurality of user terminals;
From two or more user terminals of the plurality of user terminals, a response indicating whether the request is executed or not is received, respectively, and each of the two or more responses received from the two or more user terminals indicates request execution. If it is an answer, a server system comprising request execution control means for executing a request according to the plurality of accepted request parameters.
未確認パラメータを含みリクエスト実行か否かの最終確認のための情報である第1の最終情報を前記2以上のユーザ端末のうちのいずれかのユーザ端末である第1のユーザ端末に表示させ、
前記第1の最終情報が含む未確認パラメータと同じ未確認パラメータを含みリクエスト実行か否かの最終確認のための情報である第2の最終情報を、受け付けられた前記第1の回答がリクエスト実行を表す回答である場合に、前記2以上のユーザ端末のうちの前記第1のユーザ端末以外のいずれかのユーザ端末である第2のユーザ端末に表示させ、又は、前記第2の最終情報と受け付けられた前記第1の回答を表す情報とを前記第2のユーザ端末に表示させる、
請求項1記載のサーバシステム。 The unconfirmed parameter display means
Displaying first final information, which is information for final confirmation of whether or not the request is executed, including an unconfirmed parameter, on a first user terminal that is one of the two or more user terminals,
The first response received represents the second final information, which includes the same unconfirmed parameter as the unconfirmed parameter included in the first final information, and is the second final information that is information for final confirmation as to whether or not the request is executed. If it is an answer, it is displayed on a second user terminal that is one of the two or more user terminals other than the first user terminal, or is accepted as the second final information. And displaying information representing the first answer on the second user terminal,
The server system according to claim 1.
請求項1又は2記載のサーバシステム。 The unconfirmed parameter that is the received request parameter is displayed by the unconfirmed parameter display unit on a user terminal different from the user terminal used for inputting the request parameter received by the parameter receiving unit.
The server system according to claim 1 or 2.
前記パラメータ受付手段は、受け付けたリクエストパラメータの入力に使用されたユーザ端末と別のユーザ端末でありその受け付けたリクエストパラメータである未確認パラメータが表示されたユーザ端末から、そのリクエストパラメータとは別のリクエストパラメータを受け付ける、
請求項3記載のサーバシステム。 The parameter receiving means is configured to receive the plurality of request parameters separately from at least two user terminals among the plurality of user terminals,
The parameter receiving means is a user terminal that is different from the user terminal used for inputting the received request parameter, and from the user terminal in which the unconfirmed parameter that is the received request parameter is displayed, a request different from the request parameter. Accept parameters,
The server system according to claim 3.
前記リクエスト実行制御手段は、前記2以上の回答の全てを受け付ける前に、対象のリクエスト以外の未処理のリクエストに対応した所定のリクエストパラメータを前記管理情報から削除するようになっており、
前記2以上の回答の各々は、リクエスト実行を表す場合、前記対象のリクエストのリクエストIDを含み、
前記リクエスト実行制御手段は、前記対象のリクエストのIDに対応したリクエストを前記管理情報から特定し、特定したリクエストについて前記所定のリクエストパラメータが前記管理情報に登録されていれば、前記特定したリクエストを実行する、
請求項1乃至4のうちのいずれか1項に記載のサーバシステム。 The parameter receiving means is configured to register the received request parameter in the management information for managing the request ID, the request parameter, and the request state for each request.
The request execution control unit is configured to delete a predetermined request parameter corresponding to an unprocessed request other than the target request from the management information before receiving all of the two or more responses.
When each of the two or more responses represents request execution, the request ID of the target request includes
The request execution control means identifies a request corresponding to the ID of the target request from the management information, and if the predetermined request parameter is registered in the management information for the identified request, the identified request is Run,
The server system according to any one of claims 1 to 4.
(a)前記ユーザにより入力されるべき複数のリクエストパラメータのうちの一部であり未入力のリクエストパラメータをユーザ端末から受け付けること、
(b)(a)で受け付けた複数のリクエストパラメータを、(a)で受け付けたリクエストパラメータの入力に使用されたユーザ端末と別のユーザ端末に表示させること、
前記複数のユーザ端末のうちのいずれかのユーザ端末からリクエスト実行か非実行かの回答を受け付け、前記受け付けた回答がリクエスト実行を表す回答であれば、前記受け付けた複数のリクエストパラメータに従いリクエストを実行するリクエスト実行制御手段と
を備えるサーバシステム。 Means for repeating the following (a) and (b) until receiving a plurality of request parameters to be input by the user from at least two of the plurality of user terminals of the same user;
(A) receiving a request parameter that is a part of a plurality of request parameters to be input by the user and is not input from the user terminal;
(B) displaying a plurality of request parameters received in (a) on a user terminal different from the user terminal used for inputting the request parameters received in (a);
Accepting a request execution or non-execution response from any one of the plurality of user terminals, and executing the request according to the received plurality of request parameters if the received response is a response indicating request execution A server system comprising request execution control means.
受け付けた複数のリクエストパラメータのうち前記ユーザによる確認が済んでいないリクエストパラメータである未確認パラメータを、前記複数のユーザ端末のうちの少なくとも1つのユーザ端末に表示させ、
前記複数のユーザ端末のうちの2以上のユーザ端末から、それぞれ、リクエスト実行か非実行かの回答を受け付け、前記2以上のユーザ端末からそれぞれ受け付けた2以上の回答のいずれもがリクエスト実行を表す回答であれば、前記受け付けた複数のリクエストパラメータに従いリクエストを実行する、
リクエスト実行制御方法。 Receiving a plurality of request parameters to be input by the user from at least one user terminal among the plurality of user terminals of the same user;
An unconfirmed parameter that is a request parameter that has not been confirmed by the user among a plurality of received request parameters is displayed on at least one user terminal of the plurality of user terminals,
From two or more user terminals of the plurality of user terminals, a response indicating whether the request is executed or not is received, respectively, and each of the two or more responses received from the two or more user terminals indicates request execution. If it is an answer, execute the request according to the accepted plurality of request parameters.
Request execution control method.
(a)前記ユーザにより入力されるべき複数のリクエストパラメータのうちの一部であり未入力のリクエストパラメータをユーザ端末から受け付けること、
(b)(a)で受け付けたリクエストパラメータを、(a)で受け付けたリクエストパラメータの入力に使用されたユーザ端末と別のユーザ端末に表示させること、
前記複数のユーザ端末のうちのいずれかのユーザ端末からリクエスト実行か非実行かの回答を受け付け、前記受け付けた回答がリクエスト実行を表す回答であれば、前記受け付けた複数のリクエストパラメータに従いリクエストを実行する、
リクエスト実行制御方法。 The following (a) and (b) are repeated until a plurality of request parameters to be input by the user are received from at least two user terminals among the plurality of user terminals of the same user,
(A) receiving a request parameter that is a part of a plurality of request parameters to be input by the user and is not input from the user terminal;
(B) displaying the request parameter received in (a) on a user terminal different from the user terminal used for inputting the request parameter received in (a);
Accepting a request execution or non-execution response from any one of the plurality of user terminals, and executing the request according to the received plurality of request parameters if the received response is a response indicating request execution To
Request execution control method.
受け付けた複数のリクエストパラメータのうち前記ユーザによる確認が済んでいないリクエストパラメータである未確認パラメータを、前記複数のユーザ端末のうちの少なくとも1つのユーザ端末に表示させる未確認パラメータ表示手段と、
前記複数種類の通信APPのうちの2以上の通信APPから、それぞれ、リクエスト実行か非実行かの回答を受け付け、前記2以上の通信APPからそれぞれ受け付けた2以上の回答のいずれもがリクエスト実行を表す回答であれば、前記受け付けた複数のリクエストパラメータに従いリクエストを実行するリクエスト実行制御手段と
を備えるサーバシステム。 A plurality of request parameters to be input by the user from at least one communication APP among a plurality of communication APPs which are a plurality of APPs (application programs) in the user terminal and communicate via different types of communication media. Parameter accepting means for accepting;
Unconfirmed parameter display means for displaying an unconfirmed parameter that is a request parameter that has not been confirmed by the user among the plurality of received request parameters, on at least one user terminal of the plurality of user terminals;
Each of two or more communication APPs out of the plurality of types of communication APPs receives a response indicating whether the request is executed or not executed, and each of the two or more responses received from the two or more communication APPs executes the request. A server system comprising request execution control means for executing a request in accordance with the received plurality of request parameters.
(a)前記ユーザにより入力されるべき複数のリクエストパラメータのうちの一部であり未入力のリクエストパラメータを前記ユーザ端末の通信APPから受け付けること、
(b)(a)で受け付けた複数のリクエストパラメータを、(a)で受け付けたリクエストパラメータの入力の際に経由した通信媒体の種類と異なる種類の通信媒体経由で前記ユーザ端末に表示させること、
前記複数の通信APPのうちのいずれかの通信APPからリクエスト実行か非実行かの回答を受け付け、前記受け付けた回答がリクエスト実行を表す回答であれば、前記受け付けた複数のリクエストパラメータに従いリクエストを実行するリクエスト実行制御手段と
を備えるサーバシステム。 The following (a) and (b) are changed from the at least two communication APPs among the plurality of communication APPs that communicate via a plurality of different types of communication media that are a plurality of APPs (application programs) in the user terminal. Means to repeat until receiving a plurality of request parameters to be input by the user;
(A) receiving a request parameter that is a part of a plurality of request parameters to be input by the user and is not input from the communication APP of the user terminal;
(B) displaying the plurality of request parameters received in (a) on the user terminal via a communication medium of a type different from the type of the communication medium passed in inputting the request parameter received in (a);
Accepting a request execution or non-execution response from any one of the plurality of communication APPs, and executing the request according to the received plurality of request parameters if the received response is a response indicating request execution A server system comprising request execution control means.
前記ワンタイムAPPは、前記複数のリクエストパラメータを受け付けたことを契機に、前記複数のリクエストパラメータを含むAPPとして生成され、ユーザ端末に送信されたAPPである、
請求項9又は10記載のサーバシステム。 At least one communication APP that gives a response indicating whether the request is executed or not executed is a one-time APP that can be used once or an APP that has a fixed period of use,
The one-time APP is an APP that is generated as an APP including the plurality of request parameters and transmitted to the user terminal when the plurality of request parameters are received.
The server system according to claim 9 or 10.
受け付けた複数のリクエストパラメータのうち前記ユーザによる確認が済んでいないリクエストパラメータである未確認パラメータを、前記複数のユーザ端末のうちの少なくとも1つのユーザ端末に表示させる未確認パラメータ表示手段と、
前記複数のユーザ端末のうちの2以上のユーザ端末から、それぞれ、リクエスト実行か非実行かの回答を受け付け、前記2以上のユーザ端末からそれぞれ受け付けた2以上の回答のいずれもがリクエスト実行を表す回答であれば、前記受け付けた複数のリクエストパラメータに従いリクエストを実行するリクエスト実行制御手段と
を備え、
前記リクエスト実行制御手段は、リクエスト実行か非実行かの回答をユーザ端末で実行されるAPPから受け付けるようになっており、
リクエスト実行か非実行かの回答を出すAPPが、使用可能回数が1回である又は使用期間が一定期間のAPPであるワンタイムAPPであり、
前記ワンタイムAPPが、前記複数のリクエストパラメータを受け付けたことを契機に、前記複数のリクエストパラメータを含むAPPとして生成され、前記2以上のユーザ端末のうちの少なくとも1つに送信されたAPPである、
サーバシステム。 Parameter accepting means for accepting a plurality of request parameters to be input by the user from at least one user terminal among a plurality of user terminals of the same user;
Unconfirmed parameter display means for displaying an unconfirmed parameter that is a request parameter that has not been confirmed by the user among the plurality of received request parameters, on at least one user terminal of the plurality of user terminals;
From two or more user terminals of the plurality of user terminals, a response indicating whether the request is executed or not is received, respectively, and each of the two or more responses received from the two or more user terminals indicates request execution. If it is an answer, it comprises request execution control means for executing a request in accordance with the accepted plurality of request parameters,
The request execution control means is adapted to receive an answer indicating whether the request is executed or not executed from the APP executed on the user terminal,
The APP that gives a response indicating whether the request is executed or not executed is a one-time APP in which the number of usable times is one or the APP is used for a certain period of time.
When the one-time APP receives the plurality of request parameters, the one-time APP is an APP generated as an APP including the plurality of request parameters and transmitted to at least one of the two or more user terminals. ,
Server system.
(a)前記ユーザにより入力されるべき複数のリクエストパラメータのうちの一部であり未入力のリクエストパラメータをユーザ端末から受け付けること、
(b)(a)で受け付けた複数のリクエストパラメータを、(a)で受け付けたリクエストパラメータの入力に使用されたユーザ端末と別のユーザ端末に表示させること、
前記複数のユーザ端末のうちのいずれかのユーザ端末からリクエスト実行か非実行かの回答を受け付け、前記受け付けた回答がリクエスト実行を表す回答であれば、前記受け付けた複数のリクエストパラメータに従いリクエストを実行するリクエスト実行制御手段と
を備え、
前記リクエスト実行制御手段は、リクエスト実行か非実行かの回答をユーザ端末で実行されるAPPから受け付けるようになっており、
リクエスト実行か非実行かの回答を出すAPPが、使用可能回数が1回である又は使用期間が一定期間のAPPであるワンタイムAPPであり、
前記ワンタイムAPPが、前記複数のリクエストパラメータを受け付けたことを契機に、前記複数のリクエストパラメータを含むAPPとして生成され、前記ユーザ端末に送信されたAPPである、
サーバシステム。 Means for repeating the following (a) and (b) until receiving a plurality of request parameters to be input by the user from at least two of the plurality of user terminals of the same user;
(A) receiving a request parameter that is a part of a plurality of request parameters to be input by the user and is not input from the user terminal;
(B) displaying a plurality of request parameters received in (a) on a user terminal different from the user terminal used for inputting the request parameters received in (a);
Accepting a request execution or non-execution response from any one of the plurality of user terminals, and executing the request according to the received plurality of request parameters if the received response is a response indicating request execution Request execution control means for
The request execution control means is adapted to receive an answer indicating whether the request is executed or not executed from the APP executed on the user terminal,
The APP that gives a response indicating whether the request is executed or not executed is a one-time APP in which the number of usable times is one or the APP is used for a certain period of time.
When the one-time APP receives the plurality of request parameters, the one-time APP is an APP that is generated as an APP including the plurality of request parameters and transmitted to the user terminal.
Server system.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2015126169A JP2015215910A (en) | 2014-01-20 | 2015-06-24 | Server system and request execution control method |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2014007645 | 2014-01-20 | ||
JP2014007645 | 2014-01-20 | ||
JP2015126169A JP2015215910A (en) | 2014-01-20 | 2015-06-24 | Server system and request execution control method |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2014233475A Division JP5770354B1 (en) | 2014-01-20 | 2014-11-18 | Server system and request execution control method |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2015215910A true JP2015215910A (en) | 2015-12-03 |
Family
ID=54187167
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2014233475A Active JP5770354B1 (en) | 2014-01-20 | 2014-11-18 | Server system and request execution control method |
JP2015126169A Pending JP2015215910A (en) | 2014-01-20 | 2015-06-24 | Server system and request execution control method |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2014233475A Active JP5770354B1 (en) | 2014-01-20 | 2014-11-18 | Server system and request execution control method |
Country Status (1)
Country | Link |
---|---|
JP (2) | JP5770354B1 (en) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP6718698B2 (en) * | 2016-03-03 | 2020-07-08 | 株式会社エヌ・ティ・ティ・データ | Unauthorized Transaction Detection Method, Unauthorized Transaction Detection System, Unauthorized Transaction Detection Device, and Program |
-
2014
- 2014-11-18 JP JP2014233475A patent/JP5770354B1/en active Active
-
2015
- 2015-06-24 JP JP2015126169A patent/JP2015215910A/en active Pending
Also Published As
Publication number | Publication date |
---|---|
JP2015156203A (en) | 2015-08-27 |
JP5770354B1 (en) | 2015-08-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10367905B2 (en) | Integration framework and user interface for embedding transfer services into applications | |
US20210319091A1 (en) | Multiple device credential sharing | |
US20160253664A1 (en) | Attestation by proxy | |
KR101148627B1 (en) | Method and apparatus for preventing phishing attacks | |
US7770002B2 (en) | Multi-factor authentication | |
CN109922035B (en) | Password resetting method, request terminal and verification terminal | |
JP6113678B2 (en) | Authentication apparatus, authentication system, and authentication method | |
US11902272B1 (en) | Online security center | |
US10616209B2 (en) | Preventing inter-application message hijacking | |
US20140089261A1 (en) | System and Method for Maintaining Device State Coherency | |
US20130106916A1 (en) | Drag and drop human authentication | |
KR20170140215A (en) | Methods and systems for transaction security | |
JP5563951B2 (en) | Information input method, information input system, information input device, and computer program | |
US10904011B2 (en) | Configuration updates for access-restricted hosts | |
JP5197681B2 (en) | Login seal management system and management server | |
EP3716564B1 (en) | Method for resetting password, request terminal and check terminal | |
JP5770354B1 (en) | Server system and request execution control method | |
JPWO2015019398A1 (en) | Screen display program | |
US20230291724A1 (en) | Method and system for authenticating a user in a session initiated on a computing device | |
JP6354382B2 (en) | Authentication system, authentication method, authentication apparatus, and program | |
JP6454493B2 (en) | Authentication system, authentication method, and authentication program | |
JP2017151859A (en) | Information processing device and program | |
JP2015038691A (en) | Transfer processing system and method by action pattern authentication | |
JP2019153139A (en) | Special fraud prevention system and method | |
JP4701651B2 (en) | Program, server device, and control method |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20171031 |
|
RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20171102 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20171101 |