JP2015230728A - Transaction system, transaction method, and information recording medium - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a transaction system that enhances the safety when a transaction instructed by a user, who has logged in to a server, after the login is executed.SOLUTION: A user logs in to a server 121 via a first terminal 141. When receiving an instruction of transaction via the first terminal 141 from the user, the server 121 generates a notification to be transferred to a second terminal 161. When the notification is transferred from the server 121, the first terminal 141 or the second terminal 161 encourages the user to perform an input operation for confirming the detail of the transaction. When the input by the user matches the detail of the transaction, the server 121 executes the transaction.

Description

  The present invention is a transaction system for logging in to a server via a first terminal and executing a transaction instructed via the first terminal after login, in a transaction system that increases safety by using the second terminal, The present invention relates to a transaction method using a transaction system, and a non-transitory information recording medium recording a program for realizing the transaction system by a computer.

  Conventionally, a transaction system has been proposed that requires first authentication to log in to a server and requires second authentication to execute a transaction instructed after login. For example, in Internet banking, when accessing a server via an access terminal such as a computer or smartphone via the Internet, login using the user name and the first password (first authentication), and after the login, special authentication is performed. The system that requires a second password (second authentication) is widely used for transfers, transfers, and application for new time deposits, etc. ing.

  In the first authentication and the second authentication, a password predetermined by the user can be used. Also, there is a method in which the server instructs the position of a cell to be extracted from a random number table distributed in advance to the user, and the user designates a number or a character in the cell. In addition, if this is successful after the first authentication is performed via the access terminal, the server transmits the one-time transaction password to the mobile phone, and in the second authentication, the transaction password is input to the access terminal and the server In addition, a system for performing a transaction by transmitting the information to the network has also been proposed (see paragraph 0033 of Patent Document 1).

Special table 2004-509409 gazette

  In recent years, computer viruses that run parasitically on a browser running on an access terminal have monitored the interaction between the user and the server, for example, by rewriting the transaction details such as the transfer destination and transfer amount. An attack to get is occurring. Such an attack is called a MITB (Man In The Browser) attack.

  The MITB attack can be achieved simply by rewriting the contents of the transaction exchanged between the server and the access terminal so that it cannot be seen by the user, so this can be prevented by simply combining the first authentication and the second authentication. It is difficult. Therefore, a technique for effectively preventing such an attack is required.

  The present invention is for solving the above-described problems, and in a transaction system for logging in to a server via the first terminal and executing a transaction instructed after login, the second terminal is used for safety. It is an object of the present invention to provide a transaction system that enhances performance, a transaction method using the transaction system, and a non-transitory information recording medium that records a program for realizing the transaction system by a computer.

The transaction system according to the present invention is:
A transaction system comprising a server, a first terminal, and a second terminal,
When receiving a transaction instruction via the first terminal from a user who has logged into the server via the first terminal, the server generates a notification to be transmitted to the second terminal,
When the notification is transmitted from the server to the second terminal, the first terminal or the second terminal prompts the user for input to confirm details of the transaction,
If the input from the user to the first terminal or the second terminal matches the details of the transaction, the server considers that the user has confirmed the transaction.

  According to the present invention, in a transaction system that logs in to a server via a first terminal and executes a transaction instructed after login, a transaction system that increases safety by using the second terminal, a transaction by the transaction system A method and a non-transitory information recording medium in which a program for realizing the transaction system by a computer is recorded can be provided.

It is explanatory drawing which shows the outline | summary of the transaction system which concerns on the Example of this invention. It is explanatory drawing which shows the mode of the exchange of information in the transaction system which concerns on the Example of this invention. It is a flowchart which shows the flow of the process in the server which concerns on the Example of this invention. 6 is a display example of a login form displayed on the first terminal according to the embodiment of the present invention. 7 is a display example of a transfer form displayed on the first terminal according to the embodiment of the present invention. FIG. 6 is a display example of a standby form displayed on the first terminal according to the embodiment of the present invention. FIG. 7 is a display example of a notification transmitted to a second terminal according to an embodiment of the present invention. FIG. 10 is a display example of an authentication form of a dedicated application that is activated on the second terminal according to the embodiment of the present invention. FIG. FIG. 10 is a display example of an authentication form for requesting a retry at the second terminal according to the embodiment of the present invention. FIG. FIG. 10 is a display example of a standby form indicating that the transaction is canceled at the first terminal according to the embodiment of the present invention. FIG. FIG. 10 is a display example of a cancellation form displayed on the second terminal according to the embodiment of the present invention. FIG. FIG. 10 is a display example of a standby form indicating that the second authentication is successful at the first terminal according to the embodiment of the present invention. FIG. 10 is a display example of a confirmation form displayed on the second terminal according to the embodiment of the present invention. FIG. FIG. 10 is a display example of a standby form indicating that the transaction is completed at the first terminal according to the embodiment of the present invention. FIG. FIG. 10 is a display example of a completion form indicating that the transaction is completed at the second terminal according to the embodiment of the present invention. FIG. FIG. 10 is a display example of a confirmation form displayed on the second terminal according to the embodiment of the present invention. FIG. FIG. 10 is a display example of a confirmation form displayed on the second terminal according to the embodiment of the present invention. FIG. FIG. 6 is a display example of a standby form displayed on the first terminal according to the embodiment of the present invention. FIG. FIG. 10 is a display example of a confirmation form displayed on the second terminal according to the embodiment of the present invention. FIG.

  Embodiments of the present invention will be described below. In addition, this embodiment is for description and does not limit the scope of the present invention. Therefore, those skilled in the art can employ embodiments in which each or all of these elements are replaced with equivalent ones, and these embodiments are also included in the scope of the present invention.

  FIG. 1 is an explanatory diagram showing an outline of a transaction system according to an embodiment of the present invention. Hereinafter, a description will be given with reference to FIG.

  The transaction system 101 according to the present embodiment includes a server 121, a first terminal 141, and a second terminal 161.

  The server 121 provides services such as Internet banking.

  The first terminal 141 is communicably connected to the server 121 via the computer communication network 181 and is used by the user to access the server 121. The user logs in to the server 121 through the first terminal 141 by the first authentication. Typically, a personal computer is employed as the first terminal 141, but a mobile terminal such as a smartphone may be used. In the former case, the first terminal 141 and the server 121 are connected via an Internet connection provider using an optical cable or the like.

  The second terminal 161 is communicably connected to the server 121 via the computer communication network 181, and the user who has logged in to the server 121 indicates the contents of the transaction instructed to the server 121 via the first terminal 141 by the user. Used to confirm. Typically, a mobile terminal such as a smartphone is adopted as the second terminal 161, but a personal computer or the like may be used. In the former case, the second terminal 161 and the server 121 are connected via a mobile phone communication network using wireless or the like.

  In the present embodiment, the first terminal 141 and the second terminal 161 need not be able to communicate with each other. That is, the communication network related to communication between the first terminal 141 and the server 121 and the communication network related to communication between the second terminal 161 and the server 121 pass through different communication paths as described above. It is typical. However, since the first terminal 141 and the second terminal 161 are assumed to be used by the user at the same time, they may be able to communicate with each other via wireless LAN or Bluetooth (registered trademark). In addition, the server 121 may communicate with the server 121 via a common gateway.

  In addition, the first terminal 141 and the second terminal 161 are typically different terminals, but the same terminal may be used depending on the application.

  FIG. 2 is an explanatory diagram showing how information is exchanged in the transaction system according to the embodiment of the present invention. Hereinafter, a description will be given with reference to FIG. In this description, it is assumed that the user name and the first password are used for the first authentication, and the second password is used for the second authentication. Other aspects will be described later.

  As shown in the figure, first, when the user inputs the user name and the first password to the first terminal 141 (201), the first terminal 141 sends the user name and the first password to the server 121 (202). . When the first authentication for the user name and the first password is successful at the server 121 (203), the result is sent from the server 121 to the first terminal 141 (204).

  Thereafter, when the user instructs a low-risk procedure with a relatively low risk, such as a balance inquiry or a deposit / withdrawal history inquiry via the first terminal 141 (205), the server 121 executes the low-risk procedure. The result is sent from the server 121 to the first terminal 141 (207).

  On the other hand, high-risk procedures with relatively high risks such as changes in passwords and user registration information, as well as transactions such as transfers, transfers, time deposit applications, purchases of various financial products, etc. via the first terminal 141 When (transaction) is instructed (208), a notification indicating the contents of the high-risk procedure is transmitted from the server 121 to the second terminal 161 (209).

  In order to transmit the notification from the server 121 to the second terminal 161, it is possible to employ push notifications for applications running on the second terminal 161, as well as SMS (Short Message Service) and electronic It is also possible to adopt transmission using email.

  In addition, the server 121 displays the content of the notification on the screen of the first terminal 141 by encoding a code such as an encrypted character string, a one-dimensional code, or a two-dimensional code. The code displayed on the screen may be photographed using a camera or the like included in the device, and the second terminal 161 may obtain a notification from the photographed code.

  When the notification is transmitted from the server 121, the second terminal 161 requests the user to input the second password (210). If the second terminal 161 and the server collaborate and the second authentication for the second password succeeds (211), the second terminal 161 displays the contents of the transaction specified in the notification on the screen of the second terminal 161. (212) to inform the user.

  When the user makes an input for confirming the content of the transaction displayed on the screen of the second terminal 161 to the second terminal 161 (213), the fact is transmitted to the server 121 (214), and the server 121 Then, the high-risk procedure is executed (215), and the result is sent from the server 121 to the first terminal 141 (216).

  In addition, when a high-risk procedure is executed, the result is also sent to the second terminal 161 (217), and the notice of the details of the transaction is deleted from the user and the result of the executed transaction is displayed. And

  In the present embodiment, the second password input by the user to the second terminal 161 is sent to the server 121, and the server 121 performs second authentication. In conventional Internet banking, it was customary to enter the first password and the second password from one access terminal. In this mode, the first password and the second password are entered from different terminals. Therefore, even if one terminal is attacked by a computer virus, it is possible to prevent damage caused by the MITB attack as much as possible.

  As the second password, a character string or a symbol string determined in advance between the user and the server 121 may be adopted, or a one-time password may be adopted.

  One-time password modes are as follows: (1) First of all, a random number table distributed to the user from the operator of the server 121 (each cell is filled with codes such as numbers, letters, figures, etc.) Is extracted from the first terminal 141 or the second terminal 161, and the second terminal 161 inputs a character string in which the codes in the extracted random number table are arranged. Conceivable. (2) In addition, the server 121 may display the one-time password on the screen of the first terminal 141, and the user may input the displayed one-time password from the second terminal 161. (3) Further, the server 121 displays a random number table on the screen of the first terminal 141, and the user extracts a code from the grid based on the extraction rule assigned to the user, and the code in the extracted random number table is displayed. A method of inputting the arranged character strings at the second terminal 161 can also be adopted.

  In the present embodiment, the contents of the transaction are not displayed on the screen of the second terminal 161 until the second authentication is successful. Therefore, there is an advantage that when the second terminal 161 is lost or stolen, even if a high-risk procedure is started without noticing it, the contents of the transaction do not leak.

  In the present embodiment, the user who sees the content of the transaction to be performed displayed on the screen of the second terminal 161 gives a confirmation instruction if it can be executed. The simplest confirmation method is to tap or click an object (a button or a link displayed on the screen) for executing a transaction, or to press a return key.

  As described above, in the present embodiment, at the time of the second authentication, the user inputs the second password, but the second authentication can have various modifications. In this embodiment, the user confirms the execution of the transaction by tapping or clicking a button or a link displayed on the screen together with the transaction content, but the confirmation may have various modifications. . These modifications will be described later.

  In Internet banking or the like, the server 121 functions as a web server, and a browser program for accessing the server 121 operates on the first terminal 141. In the present embodiment, the first terminal 141 can use a conventional browser as it is. Therefore, hereinafter, a flow of processing in which the server 121 cooperates with the first terminal 141 and the second terminal 161 will be described.

  FIG. 3 is a flowchart showing the flow of processing in the server according to the embodiment of the present invention. Hereinafter, a description will be given with reference to FIG. The server processing shown in this figure is executed by the server 121 executing a server program. In response to this, the first terminal 141 executes a browser program, and the second terminal 161 executes a dedicated application program.

  Here, each program is read by a computer such as a compact disk, flexible disk, hard disk, magneto-optical disk, digital video disk, magnetic tape, ROM (Read Only Memory), EEPROM (Electrically Erasable Programmable ROM), flash memory, semiconductor memory, etc. It can be recorded on possible non-transitory information recording media. This information recording medium can be distributed and sold independently of the computers that constitute the server 121, the first terminal 141, and the second terminal 161.

  Generally, a computer reads a program recorded in a non-transitory information recording medium into a RAM (Random Access Memory) which is a temporary storage device, and then a CPU (Central Processing Unit). Alternatively, the processor executes a command included in the read program. However, in an architecture in which ROM and RAM can be mapped and executed in a single memory space, the CPU directly reads and executes instructions included in the program stored in ROM.

  Further, the above-described program is transmitted from the distribution device or the like via a transitory transmission medium such as a computer communication network, independently of the computer on which the program is executed, from the server 121, the first terminal 141, the second It can be distributed and sold to the terminal 161 or the like. As described above, in the server 121, the first terminal 141, the second terminal 161, and the like, the CPU or the processor cooperates with the RAM or the like to control a NIC (Network Interface Card), a display, a microphone, a speaker, and the like.

  First, the server 121 performs various initializations (step S301), receives a packet sent via the computer communication network (step S302), and examines the contents (step S303).

  If the packet received by the server 121 is an access request transmitted from the first terminal 141 (step S303; access request), a login form for entering a user name and password is transmitted to the first terminal 141. (Step S304), the process returns to Step S302. The access request is transmitted from the first terminal 141 to the server 121 when the user designates a URL (Universal Resource Locator) of the server 121 in a browser operating on the first terminal 141.

  When the browser operating on the first terminal 141 receives the login form, it displays it on the screen. FIG. 4 is a display example of a login form displayed on the first terminal according to the embodiment of the present invention. Hereinafter, a description will be given with reference to FIG.

  The login form 401 includes a user name field 402, a password field 403, and a login button 404. When the user inputs the user name assigned to his / her account in the user name field 402, enters the login password in the password field 403, and clicks the login button 404, the first terminal 141 logs in to the server 121. A request is sent.

  If the packet received by the server 121 is a login request transmitted from the first terminal 141 (step S303; login request), the first authentication is attempted using the user name and password specified in the login request. (Step S305). If the first authentication fails (step S305; failure), the server 121 transmits an error response indicating that the login has failed to the first terminal 141 (step S306), and returns to step S302.

  On the other hand, if the first authentication is successful (step S305; success), the server 121 performs low-risk procedures such as balance inquiry and transaction history inquiry, transfer, transfer, application for time deposit, application for financial products, password change. A start form in which a link to a high-risk procedure or the like is arranged is transmitted to the first terminal 141 (step S307), and the process returns to step S302.

  The first terminal 141 that has received the start form displays this on the browser screen and allows the user to select a desired procedure. Then, a request corresponding to the selected procedure is transmitted from the first terminal 141 to the server 121.

  For example, assume that the user selects a transfer link from the start form. Then, a transfer form is generated and transmitted to the first terminal 141.

  Generation and transmission of the transfer form correspond to simple page transitions that do not involve execution of the transaction itself, and can be considered as a low-risk procedure.

  Generally, if the packet received by the server 121 is a low-risk procedure request transmitted from the first terminal 141 (step S303; low-risk procedure request), the server 121 performs a low-risk procedure corresponding to the request. This is executed (step S308), and the result form is transmitted to the first terminal 141 (step S309), and the process returns to step S302. In the result form, links for executing various processes are arranged thereafter.

  When the transfer form is transmitted to the first terminal 141, the browser of the first terminal 141 displays the transfer form on the screen. FIG. 5 is a display example of a transfer form displayed on the first terminal according to the embodiment of the present invention.

  The transfer form 411 includes a bank name column 412, a branch name column 413, an account type column 414, an account number column 415, an account holder name column 416, a transfer amount column 417, and an execution button 418 for specifying a transfer destination. Is arranged. When the user clicks the execute button 418 after inputting the transfer destination information in each field 412-417, a transfer request is transmitted from the first terminal 141 to the server 121. This transfer request is a high risk transaction. In this example, the transfer destination information is input in one form, but the transfer destination information may be sequentially input by a plurality of ordered page transitions. When the bank name column 412, the branch name column 413, the account type column 414, and the account number column 415 are input, the server 121 obtains the name of the account holder from the database and complements the account holder name column 416. By doing so, the user's direct input may be omitted. In addition, it is possible to assist the user's input by preparing a list box for easily selecting a transfer destination registered in advance.

  In the MITB attack, the contents of the transfer request sent here are rewritten so that money can be transferred to the attacker's account.

  If the packet received by the server 121 is a high-risk procedure request transmitted from the first terminal 141 (step S303; high-risk procedure request), the server 121 performs the procedure specified in the high-risk procedure request. A transaction ID is assigned to (transaction), and a notification indicating the transaction ID and the content of the transaction is generated (step S310). The transaction ID is linked to the high-risk procedure specified by the user, and the server 121 is used to request the high-risk procedure for who the user specified the high-risk procedure by the transaction ID. Information such as which terminal is the first terminal 141 and which stage the progress status of the high-risk procedure is in is managed.

  Then, the server 121 transmits, to the first terminal 141, a standby form indicating the contents of the procedure (transaction) specified in the high-risk procedure request and the transaction ID to the first terminal 141 (step S311).

  Now, when the browser of the first terminal 141 receives the standby form, it displays it on the screen. FIG. 6 is a display example of a standby form displayed on the first terminal according to the embodiment of the present invention.

  As shown in the figure, in the standby form 421, the contents of the high-risk procedure accepted by the server 121 are displayed in the transaction content column 422. Further, the progress status column 423 displays that the second authentication is waiting.

  When the progress status of the high-risk procedure changes, the server 121 transmits a message to that effect to the first terminal 141. In the first terminal 141, the script specified in the standby form 421 is waiting for a progress report to be transmitted from the server 121. When the report is received, a new situation is displayed in the progress column 423. To do. The transaction ID is also specified in the script.

  Further, the standby form 421 is provided with a cancel button 424. When the user operates the cancel button 424 before the second authentication and confirmation through the second terminal 161, a request to that effect is transmitted from the first terminal 141 to the server 121, and the server 121 receives the transaction ID. The suspension of transactions related to is executed as a low-risk procedure. Specifically, the fact that the transaction with the transaction ID is canceled is recorded in a database or the like in association with the transaction ID. A result form indicating the result is sent from the server 121 to the first terminal 141, and the browser of the first terminal 141 displays the result form on the screen.

  In addition, in the MITB attack, the contents of the transaction content field 422 displayed on the standby form 421 may be displayed after being changed to the attacker's account, etc., or modified to the original bank information. In some cases. However, in this embodiment, the contents of the transaction instructed from the first terminal 141 to the server 121 are transmitted to the second terminal 161 as they are.

  Subsequently, the server 121 obtains the destination information of the second terminal 161 registered in advance for the user who has logged in from the first terminal 141 from the database (step S312), and generates the second terminal 161. The notified notification is transmitted (step S313), and the process returns to step S302.

  For notification transmission, push notification for a dedicated application operating on the second terminal 161 can be employed. When the push notification arrives at the second terminal 161, typically, a notification area prepared by the operating system of the second terminal 161 is automatically popped up and displayed. FIG. 7 is a display example of a notification transmitted to the second terminal according to the embodiment of the present invention. In the example shown in the figure, a notification 432 indicating that a notification regarding the high-risk procedure has arrived is displayed in the home screen 431 of the second terminal 161.

  Now, the user taps or clicks the notification 432 displayed on the home screen 431 of the second terminal 161, displays a list of notifications at the notification center, taps or clicks the notification 432, When the icon of the dedicated application is tapped or clicked, the dedicated application is activated. Further, depending on the specifications of the second terminal 161, it may be set so that the dedicated application is automatically activated when a notification arrives.

  In addition, a URL to a web application that performs the same function as the dedicated application may be transmitted to an SMS, a mail address, or the like assigned to the second terminal 161. In this aspect, when the user selects the URL, the browser of the second terminal 161 is activated and the web application is executed.

  Note that the server 121 encodes the content of the notification, such as an encrypted character string, a one-dimensional code, and a two-dimensional code, on the standby form 421 of the first terminal 141, and the user selects a dedicated application. The second terminal 161 may obtain a notification from the photographed code by starting and photographing the code displayed on the standby form 421 using a camera or the like provided in the second terminal 161.

  Now, when the dedicated application is activated on the second terminal 161 to which the notification is transmitted, an authentication form is displayed on the screen of the second terminal 161. FIG. 8 is a display example of an authentication form for a dedicated application activated on the second terminal according to the embodiment of the present invention.

  As shown in this figure, the authentication form 441 includes a password field 442 and an authentication button 443, and a message field 444 displays an instruction to input a password for the second authentication. ing. When the user inputs a transaction password in the password field 442 and taps or clicks the authentication button 443, an authentication request specifying the transaction ID and the transaction password is transmitted from the second terminal 161 to the server 121.

If the packet received by the server 121 is an authentication request transmitted from the second terminal 161 (step S303; authentication request), the server 121 tries the second authentication (step S314). In the second certification, the following information is scrutinized:
(1) Whether the high-risk procedure for the transaction ID specified in the authentication request is ongoing (has not been canceled).
(2) Whether a notification is transmitted to the second terminal 161 of the transmission source related to the transaction ID.
(3) Whether the transaction password specified in the authentication request is valid as the password of the user who specified the high-risk procedure for the transaction ID

  If both of these are established, the second authentication is successful. If the second authentication fails and the failures continue to be less than the threshold number (step S314; threshold number failure), the server 121 prompts the user to re-enter the transaction password for the second terminal 161. (Step S315), and the process returns to step S302.

  FIG. 9 is a display example of an authentication form for requesting a retry at the second terminal according to the embodiment of the present invention. In the authentication form 441 of the second terminal 161, the fact that the server 121 has requested re-input is displayed in the message field 444, and the user can input the transaction password again.

  If the second authentication fails and the failure continues for the threshold number of times or more (step S314; failure for the threshold number of times or more), the server 121 cancels the transaction for the first terminal 141 and the second terminal 161. (Step S316), and the process returns to step S302.

  In the first terminal 141, the script that has received the cancellation notice updates the display of the standby form 421. FIG. 10 is a display example of a standby form indicating that the transaction is canceled at the first terminal according to the embodiment of the present invention. As shown in the figure, the progress status column 423 of the standby form 421 displays that the transaction has been canceled, the cancel button 424 is hidden, and an OK button 425 is displayed instead. When the user operates the OK button 425, the browser transitions to a start form or the like.

  In the second terminal 161, when the dedicated application receives a cancellation notice, the screen display is updated and a cancellation form is displayed. FIG. 11 is a display example of a cancellation form displayed on the second terminal according to the embodiment of the present invention. As shown in this figure, the message column 452 of the cancellation form 451 displays that the transaction has been canceled. When the OK button 453 is tapped, the contents of the message field 452 are deleted, and a management form for the dedicated application is displayed.

  On the other hand, when the second authentication is successful (step S314; success), the server 121 reports the success of authentication to the first terminal 141 and the second terminal 161 (step S317), and returns to step S302.

  In the first terminal 141, the script that has received the success report of the second authentication updates the display of the standby form 421. FIG. 12 is a display example of a standby form indicating that the second authentication is successful at the first terminal according to the embodiment of the present invention. As shown in this figure, the progress status column 423 of the standby form 421 displays that the second authentication has been successful and is waiting for user confirmation at the second terminal 161.

  On the other hand, in the second terminal 161, when the dedicated application receives a report of successful authentication, the display is switched from the authentication form to the confirmation form. FIG. 13 is a display example of a confirmation form displayed on the second terminal according to the embodiment of the present invention. As shown in this figure, in the confirmation form 461, details of the contents of the current transaction are displayed in the message field 462. The details of the contents of the transaction have already been acquired in the second terminal 161 by the previously received notification. Therefore, the content of the high-risk procedure can be displayed in the message field 462 by collating the transaction ID specified in the authentication success report with the content of the received notification.

  In addition, the content of the high-risk procedure is not specified in the notification itself, but the content of the high-risk procedure is specified in the success report transmitted from the server 121 to the second terminal 161 after the second authentication is successful. It's also good.

  In addition, a confirmation button 463 is prepared in the confirmation form 461. When the user taps or clicks confirmation button 463, a confirmation request for specifying a transaction ID is transmitted from second terminal 161 to server 121.

  If there is an error in the contents of the transaction, the stop button 424 may be operated on the standby form 421 displayed on the browser of the first terminal 141. However, a separate cancel button may be provided on the confirmation form 461, and the transaction may be canceled when the user taps the confirmation button.

If the packet received by the server 121 is a confirmation request transmitted from the second terminal 161 (step S303; confirmation request), the server 121 checks the consistency of the confirmation request (step S318). . Specifically, the following items are inspected.
(1) Whether the high-risk procedure for the transaction ID specified in the confirmation request is ongoing (has not been canceled).
(2) Whether the terminal that sent the confirmation request is the second terminal 161 that has succeeded in the second authentication for the transaction ID.

  If the confirmation request does not pass this check (step S318; failure), the transaction cannot be continued, so control proceeds to step S316 and the transaction is stopped.

  On the other hand, if the confirmation request passes this inspection (step S318; success), the server 121 executes a high-risk procedure (step S319). That is, in this embodiment, transfer remittance associated with the transaction ID is performed. Further, the progress status of the transaction linked to the transaction ID is updated to “completed”.

  Server 121 then reports the completion of the transaction to first terminal 141 and second terminal 161 (step S320), and returns to step S302.

  In the first terminal 141, the script that has received the transaction completion report updates the display of the standby form 421. FIG. 14 is a display example of a standby form indicating that the transaction is completed at the first terminal according to the embodiment of the present invention. As shown in the figure, the progress status field 423 and the transaction content field 422 of the standby form 421 indicate that the transaction has been completed. Further, since the transaction is completed, the cancel button 424 is hidden and an OK button 425 is displayed instead. When the user operates the OK button 425, the browser transitions to a start form or the like.

  On the other hand, in the second terminal 161, when the dedicated application receives a report of successful authentication, the display is switched from the confirmation form to the completion form. FIG. 15 is a display example of a completion form indicating that the transaction is completed at the second terminal according to the embodiment of the present invention. In the completion form 471, the history of transactions completed so far is displayed in the history column 472 in a scrollable manner. When the OK button 473 is tapped, a management form for the dedicated application is displayed.

  It is desirable that the dedicated application running on the second terminal 161 automatically switches the form displayed on the screen to the authentication form 441 when a notification is transmitted from the server 121. When the dedicated application supports notifications in a plurality of servers 121, a tab may be prepared for each server 121 so that processing based on a series of forms can be switched for each server 121.

  If the packet received by the server 121 is another type of packet (step S303; other), the server 121 executes a corresponding process (step S321) and returns to step S302.

  Thus, in the present embodiment, the first authentication related to login is performed from the first terminal 141 for the user to access the server 121, and the second authentication related to the high-risk procedure (transaction) is performed from the server 121. This is performed from the second terminal 161 to which the notification is transmitted. Then, after the second authentication is successful, the content of the transaction is presented to the user via the second terminal 161, and after confirming the content on the second terminal 161, the transaction is executed.

  For this reason, even if a MITB attack occurs, the contents of the transaction are transmitted to the user via a route that does not cause the MITB attack, so that damage can be prevented.

  In this embodiment, it is necessary to input a password from the second terminal 161 in the second authentication. Therefore, even if it is a case where the transaction is started without noticing that the second terminal 161 is lost or stolen, the contents of the transaction are not leaked to the person who has found the second terminal 161.

  Since the second authentication is performed based on the information input by the user at the second terminal 161, the transaction confirmation does not necessarily have to be performed from the second terminal 161, and may be performed at the first terminal 141. Good. In this case, as will be described later, it is preferable to combine with a technique that prompts the user to examine the contents of the transaction displayed on the second terminal 161.

  In the above description, in order to facilitate understanding of the operations of the server 121, the first terminal 141, and the second terminal 161, for example, processing when an error occurs is omitted as appropriate. However, these operations and control flow can be appropriately changed according to the system design and site configuration.

  In the above embodiment, the content of the high-risk procedure is not displayed on the screen of the second terminal 161 until the user inputs the second password at the second terminal 161 and the second authentication is successful. In this embodiment, the second authentication is automated.

  In this embodiment, when the server 121 encrypts the content of the notification and the second terminal 161 attempts to decrypt the encrypted notification and succeeds, the second authentication is considered successful. In this aspect, the second terminal 161 functions as an authentication token.

  In this embodiment, it is possible to adopt a mode in which the server 121 and the second terminal 161 each generate a common key for time synchronization as an encryption system. That is, the server 121 encrypts the notification using the common key generated by the server 121. When the encrypted notification is transmitted to the second terminal 161 from the encryption to the expiration of the common key, the second terminal 161 is encrypted with the common key generated by the second terminal 161. Decrypt notifications.

  In addition, public key cryptography can be adopted for this embodiment. That is, the user generates a public key / private key pair by using the second terminal 161 as a notification destination. When the second terminal 161 is registered in the server 121, the public key is transmitted to the server 121. The server 121 encrypts the notification with the public key when sending the notification, and the second terminal 161 decrypts the encrypted notification with the secret key.

  Note that the time synchronization cipher requires sharing the seed between the server 121 and the second terminal 161, but when transmitting the seed from one to the other, the use of public key cryptography further improves security. Can be made.

  In the above aspect, the second authentication is automatically executed and the second password is not necessarily required. However, the second password may be used in order to sufficiently perform the authentication by the user.

  That is, after the second authentication is successful and the content of the high-risk procedure is displayed on the screen of the second terminal 161, the second terminal 161 requests the user to input a transaction password.

  Then, the second terminal 161 and the server 121 cooperate to perform authentication (third authentication) using the input transaction password. If the third authentication is successful, it is considered that the transaction has been confirmed by the user, and the server 121 executes the transaction.

  This aspect is similar in appearance to the Internet banking aspect that is widely used at present, but in this aspect, the contents of the transaction are encrypted in the server 121 and decrypted in the second terminal 161. The MITB attack on one terminal 141 can be invalidated. That is, the user must match the information such as the transfer destination and transfer amount entered by the first terminal 141 with the information such as the transfer destination and transfer amount displayed on the second terminal 161. For example, it can be determined that an attack has occurred.

  In order to suppress the MITB attack, it is necessary for the user to thoroughly examine the contents of the high-risk procedure (transaction) displayed on the screen of the second terminal 161 after the second authentication is successful.

  That is, the user needs to confirm whether the content of the high-risk procedure input at the first terminal 141 matches the content of the high-risk procedure displayed at the second terminal 161. . Therefore, it is desirable to promote a comparison between the two in order to reduce the damage caused by MITB and other attacks. In the present embodiment, the user is encouraged to sufficiently confirm the contents of the transaction displayed on the second terminal 161. This embodiment can also be used in place of confirmation with a transaction password in a mode in which the second authentication is automatically performed.

  FIG. 16 is a display example of a confirmation form displayed on the second terminal according to the embodiment of the present invention. Hereinafter, a description will be given with reference to FIG.

  In the confirmation form 461 shown in the figure, the details of the contents of the current transaction are displayed in the message field 462, but a part of the details is in a hidden form. The part to be turned upside down may be any part of letters and numbers such as the name of the account holder of the transfer destination, the bank name, the branch name, and the account number. In the present embodiment, the second terminal 161 randomly determines the place to be turned over.

  Then, instead of the confirmation button 463, a plurality of option buttons 464 are prepared.

  In the example shown in this figure, one letter of the name of the account holder of the transfer destination is a hidden character (represented by “*” in this figure), and the answer to the hidden character is listed in the choice button 464. ing. The choice button 464 presented here includes one correct answer and a plurality of incorrect answers.

  Since the user should know the contents of the transaction he / she intends to carry out, it should be easy to replenish or fill the part that has been turned upside down. Also, even if the transfer destination is rewritten due to the MITB attack, it tries to examine the part that has been turned upside down, so it can be fully examined and the attack can be easily noticed.

  When the user selects the correct answer from the plurality of option buttons 464, the second terminal 161 considers that the user has confirmed, and transmits a confirmation request to the server 121. If the answer is incorrect, a warning is displayed to review the contents of the transaction again, and the same confirmation form 461 is requested again.

  Instead of using the option button 464, a text field or a list box for the user to input the part that is turned over may be prepared, and a confirmation button 463 may be provided. In this case, if the confirmation button 463 is operated after the user selects the correct answer, the second terminal 161 transmits a confirmation request to the server 121.

  In the above description, the confirmation input is performed on the second terminal 161, but may be performed on the first terminal 141. This is because, in the present embodiment, it is guaranteed that the user has examined the contents of the transaction displayed on the second terminal 161 by causing the user to supplement the portion that has been turned over. In this aspect, when the second terminal 161 randomly determines the place of the hidden character, the correct answer is transmitted from the second terminal 161 to the server 121, or the answer input by the first terminal 141 is sent to the server 121. It is possible to adopt a technique such as transmitting to the second terminal 161 via the terminal and causing the second terminal 161 to make a determination.

  In addition, in the above description, from the viewpoint of improving security, two types of authentication, that is, first authentication at the time of login and second authentication at the time of executing the transaction are adopted. However, when it is applied to a transaction system via a mobile phone mail that has been used in the past without using a dedicated application, the second authentication at the time of executing the transaction can be omitted, or the timing of the second authentication It is also possible to make the destination other than the mobile phone as a destination for providing the input for confirmation by the user.

  That is, the user logs in to the server 121 via the first terminal 141, and when the server 121 receives a transaction instruction from the user via the first terminal 141, the server sends a notification to be transmitted to the second terminal. Generate.

  This notification specifies the details of the transaction (for example, the name of the transfer recipient, bank name, branch name, account type name, account number, and transfer amount). . For example, if you try to make a transaction with the bank name "ABC Bank" branch name "DEF store" account type "GHI account" account number "JKL" holder "MNOP QRS" and transfer amount "TUVWXYZ Yen", it will be hidden The location (denoted by “*” below) is randomly determined and the following transaction content is generated.

  “A * C bank * EF store GHI account, account number * KL, nominee M * OP QR * I am trying to transfer TUV * XYZ yen. If this transfer is correct, the part that is hidden by * Please enter the verification code that contains the letters and numbers from the terminal you are logged into Internet Banking. "

  There may be one or more places to be turned over. In addition, a predetermined part (for example, the last four digits of the account number) may be always hidden or may be determined randomly.

  Then, the server 121 transmits, to the second terminal 161 assigned to the user, a notification specifying the contents of the transaction partially hidden by the hidden characters by e-mail or SMS.

  The user who sees the contents of the transaction displayed on the second terminal 161 that has received the notification arranges the letters, numbers, and symbols that should be filled in the place of the hidden characters in order from the top, and uses this as the confirmation code. In the above example, the confirmation code is “BDJNSW”.

  Then, the user inputs a confirmation code into the first terminal 141. If the confirmation code input from the first terminal 141 matches the column in which the letters and numbers of the parts that were turned upside down when the notification was generated, the server 121 executes the transaction. It is assumed that there was confirmation to approve. In the simplest case, if there is a confirmation, the transaction may be executed by itself. That is, the second authentication using the transaction password can be omitted. This is because a part of the notification is hidden, so that, for example, if the location to be hidden is always selected from the account number, leakage of information called the account number can be prevented.

  In addition, as described above, the confirmation code obtained from the hidden character is used, and the transaction is executed after further authentication by allowing the user to input the transaction password via the first terminal 141 or the second terminal 161. It's also good.

  If the user who sees the notification on the second terminal 161 notices that the transfer destination has been altered due to an MITB attack, etc., the transfer is canceled by operating the cancel button 424 from the first terminal 141, etc. be able to. If the transaction is unrecognized, the user name or password for login may be leaked, and the administrator of the server 121 is contacted.

  Conventionally, a system has been proposed in which authentication is performed by the server 121 specifying a position to be extracted from a random number table distributed in advance to a user and inputting characters or numbers at the position. However, in this aspect, since the character string to be extracted corresponding to the random number table dynamically changes according to the contents of the transaction, the security can be improved as compared with the fixed random number table. In addition, in order to obtain a confirmation code from the hidden characters, it is essential for the user to scrutinize the contents of the transaction. Can also be effectively prevented.

  In the following, various applicable techniques will be described in place of or in addition to the above embodiments.

(Registration procedure)
In each of the above embodiments, it is assumed that the user uses a terminal registered in advance in the server 121 in association with his / her account as the second terminal 161. The following procedure can be adopted for registration.

  First, the user registers his / her contact telephone number at the time of an account contract. Then, the dedicated application is operated on the new second terminal 161 that is desired to be linked to its own account, and the user name and the login password are input.

  When the login from the dedicated application to the server 121 is successful, the server 121 makes a call to the contact telephone number of the user and transmits the registration authentication code by voice.

  When the user inputs an authentication code from a new dedicated application of the second terminal 161, the server 121 performs verification, and if this matches, the new second terminal 161 serves as the notification destination and the user's account. It is tied to.

(one-time password)
As a first authentication method, there is an aspect in which a dedicated application in the second terminal 161 assigned to the user is activated in advance.

  That is, the dedicated application in the second terminal 161 accesses the server 121 at the time of activation and notifies the server 121 that it is operating. When the server 121 receives a login request from the first terminal 141, the dedicated application is running on the second terminal 161 associated with the specified user name, and the password specified in the login request is valid. In some cases, the first authentication is successful and the user is allowed to log in.

  In this mode, a fixed login password can be adopted, and when the dedicated application of the second terminal 161 accesses the server 121, the random number table is acquired from the server 121, and the user can select from the random number table. It is also possible to obtain a one-time password obtained by extracting the contents of the cells based on the extraction rule assigned to the user, and use this as the login password.

  In this aspect, when the user tries to execute the transaction, the dedicated application has already been operated on the second terminal 161, so that the server 121 also sends the notification as in the above embodiment. It can be transmitted to a dedicated application that has already been operated by the two terminals 161.

  The transaction password and input for confirming the transaction may be performed from the second terminal 161 or the first terminal 141 as described above.

  According to this aspect, a plurality of notification terminals can be assigned to the user. When one of the notification terminals is to be used as the second terminal 161, a dedicated application is operated on the terminal, the server 121 is accessed, and then login is started via the first terminal 141. .

  In this aspect, even if a certain notification terminal (for example, a mobile phone that can be connected to a mobile phone communication network that is frequently used) is lost or stolen, another notification terminal (for example, a tablet that can only be connected to Wifi) By performing the second authentication by the terminal, it is possible to cancel the registration of the notification terminal suitable for loss or theft.

(Authentication using face-down characters)
In the above embodiment, in the authentication by the hidden character, the original character / number converted to the hidden character is supposed to be input by the user as the confirmation code, but the random character string assigned to the correct answer option is adopted as the confirmation code. You can also
For example, in the above transfer destination example, in the form in which the last two digits of the account number are always hidden, the following notification is sent.

"I am trying to transfer TUVWXYZ Yen into ABC Bank DEF store GHI account, account number J **, holder MNOP QRS. Enter the confirmation code for that option.
If ** is AB, the verification code is 531338,
If ** is KL, the verification code is 123456,
If ** is QR, the verification code is 779012. ''

  Since the correct answer is KL, the confirmation code is 123456.

  In general, when the part to be turned over is a bank name, a branch name, a name of a nominee, or the like, the letters to be turned over may be characters that are relatively difficult to input, such as English letters, kana, and kanji. In this aspect, since the confirmation code is generated by the server 121, the confirmation code can be configured to be of a character type that can be easily input at the first terminal 141 or the second terminal 161 (for example, only numbers as described above). , User convenience can be achieved.

  In the case where a notification is sent to the second terminal 161 composed of a mobile phone by e-mail and a confirmation code is input to the first terminal 141, the server 121 simply sends one confirmation code. It is difficult to prevent, and even if you send the contents of the transaction together, the MITB attack may succeed if the user does not scrutinize the contents. However, in this aspect, since the content of the transaction is scrutinized by the user, it is possible to effectively prevent the MITB attack regardless of whether the input destination of the confirmation code is the first terminal 141 or the second terminal 161. Is possible.

  This embodiment is a modified example of authentication using the hidden characters in the above embodiment. That is, in the above-described embodiment, part of the details of the transaction is hidden, and the input of the hidden part is directly input to the user, or the user is selected from the options, and the input is converted to the hidden character. If it matches the part, it was decided to execute the transaction. This determines whether or not to execute a transaction based on whether the user input is consistent (consistent) or inconsistent (inconsistent) with the details of the transaction being executed. It corresponds to. In the present embodiment, this criterion is generally adopted in general.

  As shown in FIG. 2, when the server 121 receives a transaction instruction (208) via the first terminal 141, the server 121 sends a notification (209) to the second terminal 161.

  There are the following modes for sending a notification from the server 121 to the second terminal 161.

  (1) When a dedicated application is running on the second terminal 161, a notification is sent from the server 121 to the second terminal 161 via a notification mechanism provided by the operating system running on the second terminal 161. .

  (2) A notification is sent from the server 121 to the second terminal 161 by e-mail or SMS. The e-mail and the like may be in a text format in which the URL to be accessed by the browser of the second terminal 161 is described, or an HTML format in which buttons and links that can be operated by the user are arranged. You may do it.

  (3) From the server 121, a code such as a one-dimensional code or a two-dimensional code is displayed on the screen of the first terminal 141, and the user displays the code on the standby form 421 using the camera provided in the second terminal 161. The second terminal 161 obtains a notification from the photographed code. The information obtained from the code may be a URL to be accessed by the browser of the second terminal 161. When shooting using a dedicated application, only the session information may be obtained from the code.

  (4) When the second terminal 161 is a mobile phone, the server 121 sends a notification to the second terminal 161 by calling the second terminal 161 and making a call using automatic voice. .

  In this way, when a notification is sent to the second terminal 161, a question (quiz) configured based on the details of the transaction to be executed is presented to the user. FIG. 17 is a display example of a confirmation form displayed on the second terminal according to the embodiment of the present invention. Hereinafter, a description will be given with reference to FIG.

  In the example shown in this figure, a question is displayed on the confirmation form 461 of the dedicated application. The notification may be composed of HTML mail, and the confirmation form 461 may be displayed in the mailer, or the confirmation form 461 is displayed by accessing the URL specified in the notification from the browser of the second terminal. You may be made to do.

  In the message field 462 of the confirmation form 461, a question “Please select the name of the correct payee holder” is displayed, and the selection buttons 465a, 465b, 465c and the cancel button 466 are displayed. Yes. Below, the case where it is going to carry out the transaction similar to said Example is demonstrated.

  In other words, in this example, the name of the transfer recipient in the details of the transaction is “MNOP QRS”, and this name is extracted as a correct choice. For this reason, the correct option “MNOP QRS” is presented as an answer to the option button 465b, and when the user selects the option button 465b, the input by the user is consistent with the details of the transaction. . Accordingly, in this case, the transaction is executed assuming that the transaction has been confirmed by the user.

  On the other hand, the answer to the option button 465a is “NOPM SQR”, and the option button 465c is “SOPR MNR”. When the user selects the choice button 465a or 465c, the input by the user contradicts the details of the transaction. In this case, it is assumed that the user has not sufficiently confirmed the content of the transaction, and the transaction is not executed.

  It should be noted that after the user has selected an option that contradicts the details of the transaction, a retry may be allowed up to a predetermined number of times, or the transaction may be stopped immediately.

  The cancel button 466 is used when the user notices that an unauthorized operation has been performed by a third party or that the first terminal 121 has made an erroneous operation.

  In the above example, part of the details of the transaction was randomly hidden, but in the present example, a question (quiz) composed of the details of the transaction is similarly randomized, etc. It is only necessary to select and allow the user to directly input or select a part from options. For example, the last 4 digits of the account number (position and number of digits can be changed) can be entered directly or entered from an option.

  In addition, if the subject of the question is the transfer holder, the answer can be identified by letters such as English letters and kana, so it is easier to find an MITB attack or incorrect input than when the account number or amount is the subject of the question. You might also say that. In this case, although it is unlikely to be used as a bank account, a dictionary of names consisting of words that can be read naturally by the user is prepared in advance, and an incorrect answer option for the name of the bank holder's name The name may be selected at random from this dictionary.

  In addition, by operating the option buttons 465a, 465b, and 465c with the dedicated application, browser, and mailer of the second terminal 161, the input of the transaction confirmation is not given, but the input is given via the first terminal 161. You can also. In this case, similarly to the above-described aspect, when the confirmation code is employed, the user input is simplified.

  In the above example, the second terminal 161 that has received the notification displays the following message on the screen by e-mail or the like.

“Please select the correct name of the recipient and enter the verification code from the first terminal.
NOPM SQR (confirmation code 629)
MNOP QRS (confirmation code 254)
SOPR MNR (confirmation code 931) ''

  FIG. 18 is a display example of a standby form displayed on the first terminal according to the embodiment of the present invention. In the example shown in the figure, a code input field 427 for inputting a confirmation code and an execution button 428 are added to the standby form 421 shown in FIG.

  In this example, when the user inputs the confirmation code “254” into the code input field 427 and operates the execution button 428, the input by the user matches the details of the transaction.

  When a confirmation code other than this is entered in the code input field 427, the input by the user is inconsistent with the details of the transaction, so that the transaction is canceled as in the case where the cancel button 424 is operated. In order to cope with an erroneous input of the confirmation code, it may be configured so that retry can be performed several times.

  In the present embodiment, the second authentication (211) in FIG. 2 can be omitted or simply performed by starting a dedicated application or operating a mailer. That is, in the present embodiment, it can be considered that the second authentication (211) has succeeded because the second terminal 161 is possessed and is operable. Then, a question based on the details of the transaction is presented to the user in place of the display (212) of the entire content of the transaction.

  The user performs confirmation (213) by inputting an answer to the question. This confirmation (213) is input via the second terminal 161 and sent to the server 121 as shown in FIG. Alternatively, it may be input via the first terminal 141 and sent to the server 121 (not shown). At this time, the terminals that can be input may be limited to either one or may be input from both sides. If input from both sides is possible, a confirmation code may be presented in the options 465a, 465b, 465c, and the like.

  It is also possible to present the entire details of the transaction as an option. For example, prepare “ABC Bank DEF Store GHI Account JKL, MNOP QRS, TUVWXYZ Yen” as the correct answer options, and the bank name, account number, amount, account holder, etc. as the incorrect answer options, for example: What is necessary is just to prepare what was changed into the thing different from said correct answer. For example, in the case where notification is made by e-mail, the following words can be adopted.

“Select the correct transaction details and enter the confirmation code from the first device.
BCA Bank EFD store IHG account KLJ, NOPM SQR, XYZTUVW Yen (confirmation code 629)
ABC Bank DEF store GHI account JKL, MNOP QRS, TUVWXYZ Yen (confirmation code 254)
CAB Bank EDF store HIG account LJK, SOPR MNR, VWXYZXY yen (confirmation code 931) ''

  In this example, the incorrect answer options are configured by randomly replacing the characters included in the correct answer options. However, as described above, each item may be configured using a dictionary prepared in advance. good. The above options may be displayed by the dedicated application option buttons 465a, 465b, and 465c to allow the user to select them. In this case, the confirmation code may be omitted. FIG. 19 is a display example of a confirmation form displayed on the second terminal according to the embodiment of the present invention. In this figure, the transaction details of the above-mentioned transfer are displayed as options, and it is considered that the transaction has been confirmed when the user selects the correct option button 465b.

  It is also possible to make an automatic voice call from the server 121 to the second terminal 161 and inform the user of the contents of each message and options by voice. In this case, the user may be allowed to select an option using a push tone of the mobile phone, or a confirmation code transmitted by automatic voice may be input from the first terminal 141.

  The generation of these questions and options may be executed by the server 121, or may be generated by the second terminal 161 in a form in which details of the transaction are transmitted from the server 121 to the second terminal 161.

  In the former mode, a question message and a plurality of options including correct answers and incorrect answers are transmitted from the server to the second terminal 161. Then, information identifying the option selected by the user at the second terminal 161 is sent from the second terminal 161 to the server 121. The server 121 determines whether the user has confirmed the transaction based on whether the information sent from the second terminal 161 matches the correct answer in the generated option.

  In the latter mode, the details of the transaction are transmitted to the second terminal 161, and the second terminal 161 generates a question message and a plurality of options including correct answers and incorrect answers. Whether the option selected by the user is a correct answer is determined by the second terminal 161, and information indicating whether the user has confirmed the transaction is transmitted from the second terminal 161 to the server 121, and the process proceeds. .

  Note that the number of options to be generated may be a predetermined number or may be changed as appropriate according to the situation.

  Now, when the user is operating the first terminal 141 and the first terminal 141 is under an MITB attack, if the user notices unauthorized use, the cancel button 424 of the standby form 421 is used. If you operate, you can cancel the transaction and contact the relevant parties.

  However, when a third party logs in to the server 121 by unauthorized access and tries to execute a transaction, the user may not be able to directly operate the first terminal 141.

  In preparation for such a case, it is desirable to prepare a cancel button 466 that can be used on the second terminal 161 or a function corresponding thereto. For example, the transaction on the first terminal 141 is canceled when the user selects these by using an HTML mail link or button, a text mail URL, a push tone telephone number button for instructing cancellation, etc. Is.

  In this case, the user stops the transaction by operating the second terminal 161. Therefore, the second terminal 161 displays a message indicating that the transaction has been canceled by the user operation.

  On the other hand, there is a possibility that the third terminal 141 is operated by a third party making unauthorized use. Therefore, it is possible to pretend as if the transaction was completed successfully by using a phrase such as “transaction ended”. In this case, the unauthorized third party misunderstands that the fraudulent transaction was successful. On the other hand, the bank's investigating department can post an account related to fraudulent use on the blacklist and earn time to share with each bank.

(Summary)
As described above, the transaction system according to the above embodiment is
A transaction system comprising a server, a first terminal, and a second terminal,
When receiving a transaction instruction via the first terminal from a user who has logged into the server via the first terminal, the server generates a notification to be transmitted to the second terminal,
When the notification is transmitted from the server to the second terminal, the first terminal or the second terminal prompts the user for input to confirm details of the transaction,
If the input from the user to the first terminal or the second terminal matches the details of the transaction, the server is considered to have been confirmed for the transaction by the user. can do.

In this transaction system,
If the input from the user to the first terminal or the second terminal and the details of the transaction contradict each other, the server can be configured to cancel the transaction by the user.

In this transaction system,
When the notification is transmitted from the server to the second terminal, the second terminal has a plurality of options including a correct answer option that matches the transaction details and an incorrect answer option that contradicts the transaction details. Present
The first terminal or the second terminal prompts the user to select one of the presented options as the input,
If the option selected by the input from the user to the first terminal or the second terminal is the correct answer option, the server considers that the user has confirmed the transaction. Can be configured.

In this transaction system,
The plurality of options are associated with different confirmation codes,
Each option of the plurality of options is presented to the user together with a confirmation code associated with each option,
The prompted input is an input of a confirmation code associated with the selected option by the user;
If the input confirmation code is a confirmation code associated with the correct answer option, the server can be configured to consider that the user has confirmed the transaction.

In this transaction system,
Each option of the plurality of options and the confirmation code associated with each option can be configured to be presented to the user by voice via the second terminal.

In this transaction system,
The plurality of options includes an abort option,
If the selected option is the cancel option, the server can be configured to cancel the transaction by the user.

In this transaction system,
If the input is made to the second terminal and the selected option is the cancel option, the server can be configured to notify the administrator of the canceled transaction. .

In this transaction system,
If the input is made to the second terminal and the selected option is the cancel option, the server notifies the user that the transaction has ended via the first terminal. It can be configured to present to the user that the transaction has been canceled via the second terminal.

In this transaction system,
The correct answer option may be configured to be generated by representing details of the transaction.

In this transaction system,
The correct answer option may be generated by extracting a part of the details of the transaction.

In this transaction system,
When the server sends the notification to the second terminal by e-mail, the notification is transmitted from the server to the second terminal,
The input from the user can be configured to be made to the first terminal.

In this transaction system,
The server can be configured such that the notification is transmitted from the server to the second terminal by pushing the notification to the second terminal.

In this transaction system,
The server generates a character string code, a one-dimensional code, or a two-dimensional code as the notification, and the generated character string code, one-dimensional code, or two-dimensional code is transmitted via the first terminal. Present to the user,
The notification may be transmitted from the server to the second terminal by photographing the presented character string code, one-dimensional code, or two-dimensional code by the second terminal. .

The transaction method according to the embodiment is as follows:
A transaction method executed by a transaction system comprising a server, a first terminal, and a second terminal,
When receiving a transaction instruction via the first terminal from a user who has logged into the server via the first terminal, the server generates a notification to be transmitted to the second terminal;
When the notification is transmitted from the server to the second terminal, the first terminal or the second terminal prompts the user to input to confirm details of the transaction;
If the input from the user to the first terminal or the second terminal matches the transaction details, the server considers that the user has confirmed the transaction; and
It can comprise.

The information recording medium according to the above embodiment is
The computer can be configured by a non-transitory information recording medium in which a program for causing a computer to function as a server in the transaction system is recorded.

The information recording medium according to the above embodiment is
The computer can be configured by a non-transitory information recording medium in which a program for causing the computer to function as the second terminal in the transaction system is recorded.

  Various embodiments and modifications can be made to the present invention without departing from the broad spirit and scope of the present invention. The above-described embodiments are for explaining the present invention and do not limit the scope of the present invention. In other words, the scope of the present invention is shown not by the embodiments but by the claims. Various modifications within the scope of the claims and within the scope of the equivalent invention are considered to be within the scope of the present invention.

  This application is based on international application PCT / JP2014 / 064757 filed on Tuesday, June 3, 2014 with the Japan Patent Office as the receiving Office and the United States of America as the designated country. In this specification, the specification, claims, and entire drawings of the international application PCT / JP2014 / 064757 are incorporated by reference.

  The above embodiments can be used by using only a part of the elements as appropriate, or can be used in combination with examples, and such embodiments are also included in the technical scope of the present invention.

  According to the present invention, in a transaction system that logs in to a server via a first terminal and executes a transaction instructed after login, a transaction system that increases safety by using the second terminal, a transaction by the transaction system A method and a non-transitory information recording medium in which a program for realizing the transaction system by a computer is recorded can be provided.

101 trading system
121 servers
141 Terminal 1
161 Terminal 2
181 Computer communication network
401 login form
402 User name field
403 Password field
404 Login button
411 transfer form
412 Bank name field
413 Branch name column
414 Account Type field
415 Account number field
416 Account holder name field
417 Transfer amount column
418 Run button
421 waiting form
422 Transaction details column
423 progress field
424 Cancel button
425 OK button
427 Code input field
428 Submit button
431 home screen
432 Notification
441 authentication form
442 Password field
443 Authentication button
444 Message field
451 Cancellation form
452 Message field
453 OK button
461 confirmation form
462 Message field
463 Confirmation button
464 Choice button
465a, 465b, 465c Choice buttons
466 Cancel button
471 completion form
472 History field
473 OK button

Claims (10)

A transaction system comprising a server, a first terminal, and a second terminal,
When the server receives a transaction instruction from a user who has logged into the server via the first terminal, by receiving details of the transaction via the first terminal, the server receives the transaction instruction. Generate a notification to be communicated to
When the notification is transmitted from the server to the second terminal, the first terminal or the second terminal prompts the user to input a question asking a part of the details of the transaction accepted from the user. ,
If the input from the user to the first terminal or the second terminal matches the details of the transaction, the server considers that the user has confirmed the transaction. . When the notification is transmitted from the server to the second terminal, the second terminal presents the question,
2. The transaction system according to claim 1, wherein the first terminal prompts the user to input the presented question. 2. The transaction system according to claim 1, wherein the second terminal prompts the user to input the question. When the notification is transmitted from the server to the second terminal, the second terminal presents the question,
2. The transaction system according to claim 1, wherein the second terminal prompts the user to input the presented question. The user directly inputs part of the details of the transaction to the question, or the user selects one of a plurality of options including a correct option consisting of part of the details of the transaction, 5. The transaction system according to claim 1, wherein the input is performed. 6. The transaction system according to claim 1, wherein the question is an inquiry about a predetermined number of digits from a predetermined digit position of an account number of a transfer destination related to the transaction. 6. The question according to any one of claims 1 to 5, wherein the question is a question of a name of a bank transfer recipient who is involved in the transaction, a bank name of a bank transfer destination, or a branch name of a bank of a bank transfer destination. The trading system described in. A transaction method executed by a server, a first terminal, and a second terminal,
When the server receives a transaction instruction from a user who has logged into the server via the first terminal, by receiving details of the transaction via the first terminal, the server receives the transaction instruction. Generate a notification to be communicated to
When the notification is transmitted from the server to the second terminal, the first terminal or the second terminal prompts the user to input a question asking a part of the details of the transaction accepted from the user. ,
If the input from the user to the first terminal or the second terminal matches the details of the transaction, the server considers that the transaction has been confirmed by the user. .   8. A non-transitory information recording medium in which a program for causing a computer to function as a server in the transaction system according to claim 1 is recorded.   8. A non-transitory information recording medium in which a program for causing a computer to function as the second terminal in the transaction system according to claim 1 is recorded.

Images