JP7101292B2 - Payment methods and systems - Google Patents

Description

The following description relates to payment methods and systems, and more particularly to techniques that can verify the identity of the recipient of a remittance request in connection with the sender's remittance request.

There are a variety of prior art techniques for the sender to convey a fixed amount to the recipient online. For example, Patent Document 1 relates to a remittance method and a remittance service system capable of remittance using only the recipient's name and mobile phone number, and the sender remittance using only the recipient's name and mobile phone number. Is possible, and by allowing the sender to withdraw the remittance amount from the basic account as soon as the remittance is made, regardless of whether the recipient is a subscriber or not, from the sender's point of view, the remittance is at the time of remittance and the non-subscriber. Explain the technology that allows you to send the remittance amount immediately without worrying about the change in the balance of the account that may occur between the time of receipt of the recipient, and from the recipient's point of view, you can receive the remittance amount at the desired time. There is.

In this way, various conventional techniques have been developed and put into practical use to enable convenient online remittance. However, with the development of such convenient remittance technology, there is a danger that a third party will steal the recipient's information and pretend to be the recipient while approaching and requesting the sender to remit. .. For example, in remittance technology using a messaging service, a third party who hijacks the recipient's messaging account or bank receiving account approaches the sender by pretending to be the recipient while using the messaging service, and has his or her own account. There have been cases such as when requesting remittance to a number. Therefore, there is a demand for a technique capable of selecting such a fake recipient by confirming that the recipient is the recipient even in response to the sender's remittance request.

Korean Published Patent No. 10-2013-0047338

Provided is a payment method and system capable of selecting and proceeding with a method for authenticating a recipient depending on the existence of a past transaction history between the sender requesting a remittance and the recipient.

If there is no past transaction history between the sender and the recipient during the remittance process, the sender can be confident of the recipient by introducing an additional authentication method to prove that the recipient is really the person. To provide payment methods and systems that can protect senders and prevent erroneous remittances.

The process of identifying the sender's withdrawal account and the recipient's receiving account in connection with the remittance request received from the sender's terminal via the network, and the transaction history database of the past transaction history between the withdrawal account and the receiving account. The process of searching from, if the past transaction history does not exist, the transaction history with the other user of the recipient, the conversation record using the messaging service between the sender and the recipient, and the sender's designation. It includes a step of calculating the degree of risk of the recipient based on at least one of the receiving account list, and a step of determining the authentication method of the recipient based on the calculated degree of risk of the recipient. It provides a payment method characterized by that.

A means for identifying the sender's withdrawal account and the recipient's receiving account in connection with the remittance request received from the sender's terminal via the network, and the transaction history database of the past transaction history between the withdrawal account and the receiving account. A means of searching from, if the past transaction history does not exist, the transaction history with the other user of the recipient, the conversation record using the messaging service between the sender and the recipient, and the sender's designation. A means for calculating the degree of risk of the recipient based on at least one of the receiving account lists, and a means for determining the authentication method of the recipient based on the calculated degree of risk of the recipient. Provides a payment system, characterized by inclusion.

It is possible to select and proceed with a method for authenticating the recipient according to the existence or nonexistence of the past transaction history between the sender and the recipient who requested the remittance.

If there is no past transaction history between the sender and the recipient during the remittance process, the sender can be confident of the recipient by incorporating an additional authentication method to prove that the recipient is really who he or she is. It is possible to protect the sender of the remittance and prevent erroneous remittance.

It is a figure which showed the example of the network environment in one Embodiment of this invention. It is a block diagram for demonstrating the internal structure of the electronic device and the server in one Embodiment of this invention. It is a figure which showed the example of the whole structure of the payment system in one Embodiment of this invention. It is a flowchart which showed the example of the remittance process in one Embodiment of this invention. It is a figure which showed the screen example of the sender terminal which transmitted the identity verification message in one Embodiment of this invention. It is a figure which showed the screen example of the sender terminal which transmitted the warning message in one Embodiment of this invention. It is a block diagram which showed the example of the component which the processor of the payment server can include in one Embodiment of this invention. It is a flowchart which showed the example of the payment method which the payment server can execute in one Embodiment of this invention. It is a flowchart which showed the example of the payment method which sends a warning message in one Embodiment of this invention.

Hereinafter, embodiments will be described in detail with reference to the accompanying drawings.

The payment system according to the embodiment of the present invention may be realized by an electronic device and / or a computer device such as a server described below, and the payment method according to the embodiment of the present invention is the above-mentioned electronic device and / or. Or it may be run by the server. For example, a server may be installed and driven with a computer program according to an embodiment of the invention (eg, an operating system and / or an application), and the electronic device may be controlled by the driven computer program of the invention. The payment method according to one embodiment may be executed. The computer program described above may be stored in a computer-readable recording medium in combination with a server implemented by the computer described above to allow the computer to execute a payment method. At this time, the electronic device may be a user terminal device of a sender and a recipient for remittance, which communicates with a server that executes a payment method via a network to receive a remittance service.

FIG. 1 is a diagram showing an example of a network environment according to an embodiment of the present invention. The network environment of FIG. 1 shows an example including a plurality of electronic devices 110, 120, 130, 140, a plurality of servers 150, 160, and a network 170. Such FIG. 1 is merely an example for explaining the present invention, and the number of electronic devices and the number of servers are not limited as in FIG.

The plurality of electronic devices 110, 120, 130, 140 may be fixed terminals or mobile terminals realized by a computer device. Examples of a plurality of electronic devices 110, 120, 130, 140 include smartphones, mobile phones, navigation systems, PCs (personal computers), notebook pancons, digital broadcasting terminals, PDAs (Personal Digital Assistants), and PMPs (Tablet Multimedia Players). ), Tablets, etc. As an example, FIG. 1 shows the shape of a smartphone as an example of the electronic device 1 (110), but in the embodiment of the present invention, the electronic device 1 (110) substantially utilizes a wireless or wired communication method. , One of a variety of physical devices capable of communicating with other electronic devices 120, 130, 140 and / or servers 150, 160 via network 170.

The communication method is not limited, and not only the communication method utilizing the communication network (for example, mobile communication network, wired Internet, wireless Internet, broadcasting network) that can be included in the network 170, but also the short distance between devices. Wireless communication may be included. For example, the network 170 includes a PAN (personal area network), a LAN (local area network), a CAN (campus area network), a MAN (metropolitan area network), a WAN (wise Internet) network, etc. It may include any one or more of the networks. Further, the network 170 may include any one or more of network topologies, including bus networks, star networks, ring networks, mesh networks, star-bus networks, trees or hierarchical networks, etc. It is not limited to these.

Each of the servers 150 and 160 is realized by a computer device or a plurality of computer devices that communicate with a plurality of electronic devices 110, 120, 130, 140 via a network 170 to provide instructions, codes, files, contents, services, and the like. May be done. For example, the server 150 may be a system that provides the first service to a plurality of electronic devices 110, 120, 130, 140 connected via the network 170, and the server 160 is also connected via the network 170. It may be a system that provides a second service to a plurality of electronic devices 110, 120, 130, 140. As a more specific example, the server 150 may be a system that provides a remittance service to a plurality of electronic devices 110, 120, 130, 140 as a first service. Further, the server 160 may be a system that provides a messaging service and a payment service as a second service to a plurality of electronic devices 110, 120, 130, 140. The server 160 that provides the messaging service and the server 150 that provides the remittance service may work together to process the remittance by the messaging service. A person skilled in the art will be able to easily understand the general processing techniques for such remittance services and messaging services from well-known prior art techniques.

FIG. 2 is a block diagram for explaining an internal configuration of an electronic device and a server according to an embodiment of the present invention. FIG. 2 describes the internal configuration of the electronic device 1 (110) and the internal configuration of the server 150 as examples for the electronic device. Further, the other electronic devices 120, 130, 140 and the server 160 may have the same or similar internal configuration as the above-mentioned electronic device 1 (110) or the server 150.

The electronic device 1 (110) and the server 150 may include a memory 211, 221, a processor 212, 222, a communication module 213, 223, and an input / output interface 214, 224, respectively. The memory 211 and 221 are computer-readable recording media and include a RAM (random access memory), a ROM (read only memory), and a permanent mass storage device such as a disk drive. good. Here, a permanent large-capacity storage device such as a ROM or a disk drive may be included in the electronic device 1 (110) or the server 150 as a permanent storage device separate from the memories 211 and 221. Further, the memories 211 and 221 include an operating system and at least one program code (for example, a browser installed and driven in the electronic device 1 (110) and the electronic device 1 (110) for providing a specific service). Code for applications etc. installed in) may be stored. Such software components may be loaded from a computer-readable recording medium separate from the memories 211 and 221. Such other computer-readable recording media may include computer-readable recording media such as floppy (registered trademark) drives, discs, tapes, DVD / CD-ROM drives, and memory cards. In other embodiments, software components may be loaded into memory 211, 221 through communication modules 213, 223, which are not computer readable recording media. For example, at least one program may be based on a program installed by a file provided by a file distribution system that distributes a developer or application installation file (eg, the application described above), memory 211. It may be loaded into 221.

Processors 212 and 222 may be configured to process instructions in a computer program by performing basic arithmetic, logic, and input / output operations. Instructions may be provided to processor 212, 222 by memory 211, 221 or communication modules 213, 223. For example, the processors 212 and 222 may be configured to execute instructions received according to program code stored in a recording device such as memories 211 and 221.

The communication modules 213 and 223 may provide a function for the electronic device 1 (110) and the server 150 to communicate with each other via the network 170, and the electronic device 1 (110) and / or the server 150 may provide other functions. A function for communicating with an electronic device (for example, electronic device 2 (120)) or another server (for example, server 160) may be provided. As an example, a request generated by the processor 212 of the electronic device 1 (110) according to a program code stored in a recording device such as a memory 211 may be transmitted to the server 150 via the network 170 under the control of the communication module 213. .. On the contrary, the control signals, instructions, contents, files and the like provided according to the control of the processor 222 of the server 150 are electronic devices through the communication module 213 of the electronic device 1 (110) via the communication module 223 and the network 170. It may be received at 1 (110). For example, control signals, instructions, contents, files, etc. of the server 150 received through the communication module 213 may be transmitted to the processor 212 and the memory 211, and the contents, files, etc. may be further included in the electronic device 1 (110). It may be stored in a storage medium (permanent storage device described above) that can be stored.

The input / output interface 214 may be a means for an interface with the input / output device 215. For example, the input device may include a device such as a keyboard or mouse, and the output device may include a device such as a display or speaker. As another example, the input / output interface 214 may be a means for an interface with a device that integrates functions for input and output, such as a touch screen. The input / output device 215 may be composed of an electronic device 1 (110) and one device. Also, the input / output interface 224 of the server 150 may be a means for interfacing with a device (not shown) for input or output that can be linked to or included in the server 150. As a more specific example, when the processor 212 of the electronic device 1 (110) processes an instruction of a computer program loaded in the memory 211, it is configured by using the data provided by the server 150 and the electronic device 2 (120). The service screen or content to be generated may be displayed on the display through the input / output interface 214.

Also, in other embodiments, the electronic device 1 (110) and the server 150 may include more components than the components of FIG. However, most prior art components need not be clearly shown in the figure. For example, the electronic device 1 (110) may be realized to include at least a part of the above-mentioned input / output device 215, a transceiver, a GPS (Global Positioning System) module, a camera, various sensors, and a database. It may further include other components such as. As a more specific example, when the electronic device 1 (110) is a smartphone, an acceleration sensor and a gyro sensor generally included in the smartphone, a camera module, various physical buttons, buttons using a touch panel, and input / output. Various components such as ports, vibrators for vibrations, and the like may be realized to be further included in the electronic device 1 (110).

FIG. 3 is a diagram showing an example of the overall structure of a payment system according to an embodiment of the present invention. FIG. 3 shows a payment server 310, a transaction history database 320, a sender terminal 330, and a recipient terminal 340. As an example, the payment server 310 may be realized like the server 150 described above, and the sender terminal 330 and the recipient terminal 340 may be realized like the electronic device 1 (110) described above. The transaction history database 320 may be realized to be included in the payment server 310, but in some embodiments, the transaction history database 320 is included in a device different from the payment server 310, and the other device and the payment server 310 are included in the network. The payment server 310 may be implemented to access the transaction history database 320 by communicating.

Basically, the payment server 310 identifies the target recipient's account by receiving the remittance request from the sender terminal 330, and the requested amount is transferred to the identified recipient's account. Can be processed as follows. Basically, the payment server 310 can identify the withdrawal account of the sender and the receiving account of the recipient in connection with the remittance request received from the sender terminal 330 via the network. As an example, depending on the remittance technique applied to the payment server 310, the remittance request may include the sender's withdrawal account and the recipient's receiving account, or the payment server 310 pre-registers the user's account for remittance. The corresponding account may be extracted by using the identification information (user identifier, messenger account identifier, telephone number, etc.) included in the request. Such a remittance technique itself will be easily understood by those skilled in the art from well-known prior art techniques.

At this time, the payment server 310 may determine whether there is a past transaction history between the sender and the recipient by searching the transaction history database 320 using the specified withdrawal account and receiving account. It is possible to apply different payee authentication methods depending on the existence of such past transaction history. For example, if there is a past transaction history between the sender's withdrawal account and the recipient's receiving account, there is less need to suspect the recipient, so the payment server 310 is a separate payment server 310 for confirming the recipient. You may skip the procedure and process the requested remittance. The process of remittance itself will be readily apparent to those of skill in the art from well-known prior art.

On the other hand, if there is no past transaction history between the sender and the recipient, the payment server 310 may perform a procedure for confirming the recipient. First, the payment server 310 is based on at least one of a transaction history between the recipient and another user, a record of conversations between the sender and the recipient using a messaging service, and a recipient account list specified by the sender. The degree of danger of the recipient may be calculated, and the authentication method of the recipient may be determined according to the calculated degree of danger of the recipient.

For example, the payment server 310 may use the recipient's receiving account to calculate the first degree of risk based on at least one of the number and duration of transactions with other users. If the recipient's receiving account has been used for transactions with other users for a long time, the recipient's first risk is relatively low. Therefore, the first degree of risk may be calculated to be lower as the period is longer. Further, the number of times may also be utilized to determine the degree of first risk of the recipient. In this case, the degree of first risk may be calculated so as to decrease as the number of times increases. Further, when both the number of times and the period are used, a higher weighted value may be given to the period to calculate the first degree of risk. This is because if a large number of transactions have been made recently, the number of times the transaction has been made becomes unreliable.

As another example, the payment server 310 includes the presence or absence of a conversation record using a messaging service between the sender and the recipient, the number of conversations extracted from the conversation record, and the conversation period extracted from the conversation record. The second degree of risk may be calculated by at least one of. For example, if the sender and the recipient have a lot of conversations on the messaging service over a long period of time, it is determined that the risk of the recipient is low, and the payment server 310 has a relatively low degree of second risk. You may calculate. As a more specific example, when the conversation record exists, the payment server 310 has a second risk so that the higher the number of conversations and the longer the conversation period, the lower the degree of the second risk. You may calculate the degree of sex. For this purpose, the payment server 310 may directly store and manage conversation records between users including a messenger server that provides a messaging service, or may be separately implemented with a messenger server (server 160 as an example). A conversation record between the sender and the recipient may be provided in cooperation with each other so as to communicate via the network.

As another example, after the day when User A and User B have a messenger conversation (as an example, May 5th), User B registers a new bank account as a receiving account in the payment server 310 (as an example, May 7th). (Sun) may occur. After the registration of such a receiving account, User A and User B have a messenger conversation for a certain period of time or longer (as an example, May 8 to May 9), and then User A remits money to User B (as an example). May 10th) Consider the situation you are about to do. In this case, the payment server 310 may calculate the second degree of risk based on the period of the messenger conversation record and the registration date of the receiving account.

As another example, the payment server 310 may calculate the third degree of risk depending on whether or not the recipient's receiving account is included in the receiving account list specified by the sender. As an example, the payment server 310 omits the calculation of the first degree of risk and the second degree of risk when the recipient's receiving account is included in the receiving account list specified by the sender, and the recipient's The degree of risk may be set below the threshold.

Thus, the recipient's degree of risk may be calculated using at least one of the above-mentioned first degree of risk, second degree of risk, and third degree of risk. The payment server 310 may proceed to an additional recipient identity verification procedure if the recipient's risk level is greater than or equal to the threshold value, and may proceed to a recipient identity verification procedure if the recipient's risk level is less than the threshold value. You can proceed to the remittance procedure immediately without the need.

The recipient identity verification procedure is performed by processing at least one of a first process in which the payment server 310 sends a warning message to the sender and a second process in which the payment server 310 requests the recipient for an identity verification message. good. As an example, the first process may be a process of sending a warning message to the sender terminal 330 over the network to warn the sender to confirm the recipient. In this case, the payment server 310 can process the sender's remittance request by receiving an acknowledgment to the warning message from the sender terminal 330. In addition, the second process may be a process of requesting the recipient to send an identity verification message. In this case, the payment server 310 does not directly authenticate the identity verification message, but transmits the identity verification message to the sender terminal 330 via the network, and receives an acknowledgment for the identity verification message from the sender terminal 330 via the network. If so, the sender's remittance request can be processed. For this purpose, the identity verification message may include information that allows the sender to authenticate that the recipient is the recipient. For example, the identity verification message contains information about the content that only the sender and the recipient can understand, or includes a photograph (image information including the shooting time information) of the recipient himself / herself, which the recipient receives to the sender. It may include information generated to authenticate the person.

FIG. 4 is a flowchart showing an example of the remittance process in one embodiment of the present invention. The flowchart of FIG. 4 may be executed by the payment server 310.

The stage 410 is an account identification process, and the payment server 310 can specify the sender's withdrawal account and the recipient's receiving account in the stage 410. The method for identifying the sender's withdrawal account and the recipient's receiving account according to the sender's remittance request is as described above.

The stage 420 is a transaction history search process, and the payment server 310 can search the past transaction history between the sender's withdrawal account and the recipient's receiving account from the transaction history database 320 in the transaction history database 320.

Stage 430 is a process of determining whether or not a transaction history exists, and in stage 430, the payment server 310 stores the past transaction history between the sender's withdrawal account and the recipient's receiving account in the transaction history database 320. You can decide if it exists. At this time, step 460 may be executed if the transaction history exists, and step 440 may be executed if the transaction history does not exist.

Step 440 is a risk degree calculation process, and the payment server 310 can calculate the risk degree of the recipient in step 440. An example of calculating the degree of risk of the recipient is as described above.

Step 450 is a process of determining whether the degree of risk is less than the first threshold, and the payment server 310 compares the degree of risk of the recipient with the preset first threshold in step 450. If the degree of risk is less than the first threshold value, step 460 may be executed, and if the degree of risk is greater than or equal to the first threshold value, step 451 may be executed.

Stage 460 is a remittance processing process, in which the payment server 310 processes a process for transferring the amount requested in accordance with the sender's remittance request from the sender's withdrawal account to the recipient's receiving account. Can be done. For example, the payment server 310 may communicate with the server of the bank where the withdrawal and receiving accounts are opened to process the remittance of the requested amount, or request from the withdrawal account to the basic account associated with the payment server 310. After transferring the amount, one of the well-known prior art techniques may be used to process the remittance of the requested amount, such as transferring the requested amount from the basic account to the recipient's receiving account.

Step 451 is a process of determining whether the degree of risk exceeds the second threshold, and the payment server 310 compares the degree of risk of the recipient with the preset second threshold in step 451. If the degree of risk exceeds the second threshold value, step 452 may be executed, and if the degree of risk is equal to or less than the second threshold value, step 454 may be executed.

Step 452 is the process of requesting an identity proof message, and the payment server 310 may request the recipient to deliver the identity proof message in step 452. The identity verification message is as described above.

Step 453 is a process of confirming the recipient by the sender, in which the payment server 310 sends the identity verification message transmitted from the recipient to the sender, and the sender can authenticate the recipient from the identity verification message. The payment server 310 may perform step 460 to process the remittance by receiving a confirmation response to the identity verification message from the sender, but if the confirmation response to the identity verification message is not received from the sender (the sender is the identity verification message). You may cancel the remittance if you receive a revocation response due to the inability to authenticate the recipient, or if you do not receive an acknowledgment after a certain period of time).

Step 454 is a warning message transmission process, and the payment server 310 sends a warning message to the sender in step 454 when the risk level of the recipient is equal to or higher than the first threshold value but is equal to or lower than the second threshold value. be able to. At this time, step 453 may be a process in which the payment server 310 receives the confirmation response of the sender to the warning message. The payment server 310 may execute step 460 to process the remittance if it receives the sender's acknowledgment of the warning message, but if the acknowledgment to the warning message is not confirmed by the sender (sender who received the warning message). If you receive a cancellation response from, or if you do not receive an acknowledgment after a certain period of time), you may cancel the remittance.

In this way, the payment server 310 can have different methods for authenticating the recipient step by step depending on the existence of the transaction history and the degree of danger of the recipient, and if necessary, the method for authenticating the recipient can be different. By providing information for the recipient to prove his / her identity and the sender directly authenticating the recipient, more secure remittance processing becomes possible.

FIG. 5 is a diagram showing a screen example of a sender terminal to which an identity verification message is transmitted according to an embodiment of the present invention. FIG. 5 shows a screen 510 in which the recipient's identity verification message “My nickname is OO” is displayed on the sender terminal 330. The recipient's identity verification message transmitted to the sender terminal 330 may be displayed on the screen 510 of the sender terminal 330 in the form of a pop-up window 520. It will be easily understood by those skilled in the art that such a display form of the identification message is only an example and may be variously different depending on the embodiment.

The sender may authenticate the recipient from such an identity verification message and select the "confirm" button 530 or the "cancel remittance" button 540 depending on the authentication result (as an example, each button is displayed in the touch screen environment. By touching the area with a finger), the payment server 310 allows the sender to confirm the recipient, and can proceed or cancel the remittance.

FIG. 6 is a diagram showing a screen example of a sender terminal to which a warning message is transmitted according to an embodiment of the present invention. FIG. 6 shows a screen 610 in which a warning message transmitted to the sender terminal 330 is displayed. The payment server 310 may send a warning message to the sender terminal 330 to warn the recipient or account number to be confirmed again, and may request the sender to confirm the warning message. When the sender selects the "Confirm" button 630 or the "Cancel Remittance" button 640 (in one example, touch the area where each button is displayed with a finger in the touch screen environment), the payment server 310 advances or cancels the remittance. It becomes possible to do.

FIG. 7 is a block diagram showing an example of components that the processor of the payment server can include in one embodiment of the invention, and FIG. 8 is a block diagram performed by the payment server in one embodiment of the invention. It is a flowchart which showed the example of the payment method which can be done. In this embodiment, an example in which the payment server 310 described above is realized by the server 150 will be described.

FIG. 7 shows an account identification unit 710, a transaction history search unit 720, a risk degree calculation unit 730, an authentication method determination unit 740, and a remittance request processing unit 750 as components that can be included in the processor 222 of the server 150. ing. Such processors 222 and components of the processor 222 may perform steps 810 to 860 included in the payment method of FIG. At this time, the processor 222 and the components of the processor 222 may be realized to execute an instruction by the code of the operating system included in the memory 221 and / or the code of at least one computer program. Here, the components of the processor 222 may be representations of different functions of the processor 222 that are executed by the processor 222 according to the control instructions provided by the code of the computer program stored in the server 150. For example, the processor 222 may read the necessary control instructions from the memory 221 loaded with the instructions related to the control of the server 150, and may execute steps 810 to 860 described below according to the read control instructions. You may control the server 150.

At stage 810, the account identification unit 710 can identify the sender's withdrawal account and the recipient's receiving account in connection with the remittance request received from the sender's terminal via the network.

At stage 820, the transaction history search unit 720 can search the past transaction history between the withdrawal account and the receiving account from the transaction history database. Here, the transaction history database may correspond to the above-mentioned transaction history database 320 with reference to FIG.

In stage 830, the risk degree calculation unit 730 records the transaction history with other users of the recipient, the conversation record using the messaging service between the sender and the recipient, and the conversation record using the messaging service when the past transaction history does not exist. The degree of risk of the recipient can be calculated based on at least one of the receiving account lists specified by the sender. For example, the risk degree calculation unit 730 may use the recipient's receiving account to calculate the first degree of risk, the sender and the recipient, by at least one of the number and duration of transactions with other users. The presence or absence of a conversation record using a messaging service with, the number of conversations extracted from the conversation record, and the second degree of risk calculated by at least one of the conversation periods extracted from the conversation record, In addition, the recipient's risk level may be calculated using at least one of the third risk levels calculated depending on whether the recipient's receiving account list is included in the receiving account list specified by the sender.

At step 840, the authentication method determination unit 740 can determine the authentication method of the recipient based on the calculated degree of risk of the recipient. At this time, the authentication method determination unit 740 may process the second process of requesting the recipient for the identification message depending on the calculated risk level of the recipient.

In stage 850, when the remittance request processing unit 750 requests the recipient for the identity verification message, the remittance request processing unit 750 can send the identity verification message received from the recipient's terminal to the sender.

In stage 860, the remittance request processing unit 750 can process the remittance request of the sender when the confirmation response to the identity verification message is received from the sender.

As described above, the steps 810 to 860 in FIG. 8 may correspond to the embodiment in which the transaction history does not exist and the degree of risk calculated for the recipient exceeds the preset second threshold value. ..

FIG. 9 is a flowchart showing an example of a payment method for transmitting a warning message according to an embodiment of the present invention. The payment method of FIG. 9 may include stages 810 to 840 of stages 810 to 860 of FIG. 8, and may further include stages 910 and 920. Steps 910 and 920 may be performed after step 840.

First, in step 840, the authentication method determination unit 740 can determine the authentication method of the recipient based on the calculated degree of risk of the recipient. At this time, unlike FIG. 8, the authentication method determination unit 740 may process the first process of sending a warning message to the sender depending on the calculated risk level of the recipient.

In step 910, the remittance request processing unit 750 may receive an acknowledgment to the warning message sent to the sender from the sender's terminal.

At step 920, the remittance request processing unit 750 can process the sender's remittance request by receiving an acknowledgment for the warning message.

In such stages 840, 910, and 920 of FIG. 9, there is no transaction history in the search of stage 820, and the degree of risk calculated for the recipient is equal to or higher than the preset first threshold value. And, it may correspond to the embodiment in the case of being equal to or less than the second threshold value.

If the transaction history is present in the search at step 820 of FIG. 8, the processor 222 may process the requested remittance without going through the recipient identity verification procedure. Further, even if the transaction history does not exist, the processor 222 processes the remittance without going through the procedure of the recipient identity verification if the risk level of the recipient is less than the preset first threshold value. It's okay. Not only this, the processor 222 may cancel the remittance process if there is no confirmation response from the sender for the identity verification message or confirmation response from the sender for the warning message.

As described above, according to the embodiment of the present invention, the method for authenticating the recipient according to the existence or nonexistence of the past transaction history between the sender requesting the remittance and the recipient is selected and proceeded. Can be done. In addition, if there is no past transaction history between the sender and the recipient during the remittance process, the sender can be confident of the recipient by incorporating an additional authentication method to prove that the recipient is truly who they say they are. You can do this to protect the sender of the remittance and prevent erroneous remittances.

The system or device described above may be implemented by a hardware component, a software component, or a combination of a hardware component and a software component. For example, the apparatus and components described in the embodiments include, for example, a processor, a controller, an ALU (arithmetic logic unit), a digital signal processor, a microcomputer, an FPGA (field programgate array), a PLU (programmable log unit), and a micro. It may be implemented utilizing one or more general purpose computers or special purpose computers, such as a processor or various devices capable of executing and responding to instructions. The processing device may execute an operating system (OS) and one or more software applications running on said OS. The processing device may also respond to the execution of the software, access the data, store, manipulate, process, and generate the data. For convenience of understanding, one processing device may be described as being used, but one of ordinary skill in the art may include a plurality of processing elements and / or a plurality of types of processing elements. You can understand. For example, the processing device may include multiple processors or one processor and one controller. Also, other processing configurations such as parallel processors are possible.

The software may include computer programs, codes, instructions, or a combination of one or more of these, configuring the processing equipment to operate as desired, or instructing the processing equipment independently or collectively. You may do it. The software and / or data is permanent to any type of machine, component, physical device, virtual device, computer storage medium or device for interpretation based on the processing device or for providing instructions or data to the processing device. It may be materialized or temporarily. The software is distributed on a computer system connected by a network and may be stored or executed in a distributed state. The software and data may be stored on one or more computer-readable recording media.

The method according to the embodiment may be realized in the form of program instructions that can be executed by various computer means and recorded on a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, etc. alone or in combination. The program instructions recorded on the medium may be those specially designed and configured for embodiments, or may be usable known to those skilled in the art of computer software. Examples of computer-readable recording media include hard disks, floppy (registered trademark) disks, magnetic media such as magnetic tapes, optical media such as CD-ROMs and DVDs, and floptic discs. Includes optical magnetic media and hardware devices specially configured to store and execute program instructions such as ROM, RAM, flash memory, and the like. Examples of program instructions include machine language code, such as those generated by a compiler, as well as high-level language code, which is executed by a computer using an interpreter or the like.

As described above, the embodiments have been described based on the limited embodiments and drawings, but those skilled in the art will be able to make various modifications and modifications from the above description. For example, the techniques described may be performed in a different order than the methods described, and / or components such as the systems, structures, devices, circuits described may be in a different form than the methods described. Appropriate results can be achieved even if they are combined or combined, or replaced or replaced by other components or equivalents.

Therefore, even if it is a different embodiment, if it is equivalent to the claims, it belongs to the attached claims.

310: Payment server 320: Transaction history database 330: Sender terminal 340: Recipient terminal

Claims (5)

Specific means for identifying the sender's withdrawal account and the recipient's receiving account in connection with the remittance request received from the sender's terminal via the network.
A search means for searching the transaction history database for the past transaction history between the withdrawal account and the receiving account.
If the past transaction history does not exist, a calculation to calculate the degree of risk of the recipient based on the transaction history with other users of the recipient and at least one of the receiving account list specified by the sender. Means ,
Determining means for processing at least one of the first process of sending a warning message to the sender and the second process of requesting the recipient an identity proof message, depending on the calculated degree of risk of the recipient .
When the recipient is requested to have an identity verification message, a transmission means for transmitting the identity verification message received from the recipient's terminal to the sender, and a transmission means.
A processing means for processing the remittance request of the sender when a confirmation response to the identity verification message is received from the sender.
A payment system characterized by including. The payment system according to claim 1 , further comprising a processing means for processing the remittance request of the sender when the confirmation response to the warning message transmitted to the sender is received from the terminal of the sender. The calculation means for calculating the degree of risk of the recipient is
(1) a first degree of risk calculated by at least one of the number and duration of transactions with the other user using the recipient's receiving account, and (2) specified by the sender. It is characterized in that the risk degree of the recipient is calculated by using at least one of the third risk degree calculated depending on whether the recipient's receiving account is included in the receiving account list. , The payment system according to claim 1 . The payment method performed by the payment system
A specific step of identifying the sender's withdrawal account and the recipient's receiving account in connection with the remittance request received from the sender's terminal via the network.
A search process for searching the transaction history database for the past transaction history between the withdrawal account and the receiving account.
If the past transaction history does not exist, a calculation to calculate the degree of risk of the recipient based on the transaction history with the other user of the recipient and at least one of the receiving account list specified by the sender. Process,
A determination step of processing at least one of the first process of sending a warning message to the sender and the second process of requesting the recipient an identity proof message, depending on the calculated degree of risk of the recipient.
When the recipient is requested to have an identity verification message, the process of transmitting the identity verification message received from the recipient's terminal to the sender, and
A step of processing the remittance request of the sender when a confirmation response to the identity verification message is received from the sender.
A payment method, characterized by including. On the computer
A specific step of identifying the sender's withdrawal account and the recipient's receiving account in connection with the remittance request received from the sender's terminal via the network.
A search process for searching the transaction history database for the past transaction history between the withdrawal account and the receiving account.
If the past transaction history does not exist, a calculation to calculate the degree of risk of the recipient based on the transaction history with the other user of the recipient and at least one of the receiving account list specified by the sender. Process,
A determination step of processing at least one of the first process of sending a warning message to the sender and the second process of requesting the recipient an identity proof message, depending on the calculated degree of risk of the recipient.
When the recipient is requested to have an identity verification message, the process of transmitting the identity verification message received from the recipient's terminal to the sender, and
A step of processing the remittance request of the sender when a confirmation response to the identity verification message is received from the sender.
A computer program to run.

Images