WO2018110723A1 - 지불 방법 및 시스템 - Google Patents

지불 방법 및 시스템 Download PDF

Info

Publication number
WO2018110723A1
WO2018110723A1 PCT/KR2016/014581 KR2016014581W WO2018110723A1 WO 2018110723 A1 WO2018110723 A1 WO 2018110723A1 KR 2016014581 W KR2016014581 W KR 2016014581W WO 2018110723 A1 WO2018110723 A1 WO 2018110723A1
Authority
WO
WIPO (PCT)
Prior art keywords
sender
receiver
risk
degree
recipient
Prior art date
Application number
PCT/KR2016/014581
Other languages
English (en)
French (fr)
Korean (ko)
Inventor
최원준
Original Assignee
라인 가부시키가이샤
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 라인 가부시키가이샤 filed Critical 라인 가부시키가이샤
Priority to JP2019530182A priority Critical patent/JP6941255B2/ja
Priority to PCT/KR2016/014581 priority patent/WO2018110723A1/ko
Priority to CN201680090166.4A priority patent/CN109891450B/zh
Publication of WO2018110723A1 publication Critical patent/WO2018110723A1/ko
Priority to JP2021081042A priority patent/JP7101292B2/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance

Definitions

  • the following description relates to a payment method and system, and more particularly, to a technology capable of verifying whether or not the recipient of a remittance request is subject to the sender's remittance request.
  • Korean Patent Laid-Open Publication No. 10-2013-0047338 relates to a remittance method and a remittance service system that allow remittances using only the recipient's name and mobile phone number, and the remitter uses only the recipient's name and mobile phone number.
  • Remittances can be made and the money is withdrawn immediately to the parent's account at the time the remitter remitts, regardless of whether the remittee is a member. It describes a technique that allows money to be sent immediately and the recipient can transfer money at any time.
  • the present invention provides a payment method and system capable of selecting and proceeding a method for authenticating a receiver according to the existence of past transaction history between a sender and a receiver requesting remittance.
  • At least one processor implemented to execute computer readable instructions, the at least one processor configured to access the remittance account of the sender and the receiving account of the receiver in connection with a remittance request received over the network from the sender's terminal. Specify a past transaction history between the remittance account and the receiving account from a transaction history database, and if the past transaction history does not exist, a transaction history with other users of the receiver, messaging between the sender and the receiver Calculating a degree of risk of the receiver based on at least one of a conversation record through a service and a list of receiving accounts designated by the sender, and determining an authentication method of the receiver based on the calculated degree of risk of the receiver; Provide a payment system.
  • a method for authenticating the receiver may be selected and proceed.
  • FIG. 1 is a diagram illustrating an example of a network environment according to an embodiment of the present invention.
  • FIG. 2 is a block diagram illustrating an internal configuration of an electronic device and a server according to an embodiment of the present invention.
  • 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. 4 is a flowchart illustrating an example of a remittance process according to an embodiment of the present invention.
  • FIG. 5 is a diagram illustrating an example of a screen of a sender terminal receiving an identity verification message according to one embodiment of the present invention.
  • FIG. 6 is a diagram illustrating an example of a screen of a sender terminal receiving a warning message according to an embodiment of the present invention.
  • FIG. 7 is a block diagram illustrating an example of components that may be included in a processor of a payment server according to an embodiment of the present invention.
  • FIG. 8 is a flowchart illustrating an example of a payment method that can be performed by a payment server according to an embodiment of the present invention.
  • FIG. 9 is a flowchart illustrating an example of a payment method for transmitting an alert message according to an embodiment of the present invention.
  • the payment system according to the embodiments of the present invention may be implemented through a computer device such as an electronic device and / or a server, which will be described later, and the payment method according to the embodiments of the present invention is described above. It can be performed through.
  • a computer program for example, an operating system and / or an application
  • the payment method according to the example can be performed.
  • the above-described computer program may be stored in a computer-readable recording medium in combination with the above-described computer-implemented server to execute a payment method on a computer.
  • the electronic device may be a user terminal device of a sender and a receiver for remittance for receiving a remittance service by communicating through a network with a server executing a payment method.
  • FIG. 1 is a diagram illustrating an example of a network environment according to an embodiment of the present invention.
  • the network environment of FIG. 1 illustrates an example including a plurality of electronic devices 110, 120, 130, and 140, a plurality of servers 150 and 160, and a network 170.
  • 1 is an example for describing the present invention, and the number of electronic devices or the number of servers is not limited as shown in FIG. 1.
  • the plurality of electronic devices 110, 120, 130, and 140 may be fixed terminals or mobile terminals implemented as computer devices.
  • Examples of the plurality of electronic devices 110, 120, 130, and 140 include a smart phone, a mobile phone, a navigation device, a computer, a notebook computer, a digital broadcasting terminal, a personal digital assistant (PDA), and a portable multimedia player (PMP). Tablet PC).
  • FIG. 1 illustrates the shape of a smart phone as an example of the electronic device 1 110, in the embodiments of the present invention, the electronic device 1 110 may use a wireless or wired communication method to substantially connect the network 170. It may mean one of various physical devices that can communicate with other electronic devices 120, 130, 140 and / or servers 150, 160.
  • the communication method is not limited, and may include not only a communication method using a communication network (for example, a mobile communication network, a wired internet, a wireless internet, a broadcasting network) that the network 170 may include, but also a short range wireless communication between devices.
  • the network 170 may include a personal area network (PAN), a local area network (LAN), a campus area network (CAN), a metropolitan area network (MAN), a wide area network (WAN), and a broadband network (BBN). And one or more of networks such as the Internet.
  • the network 170 may also include any one or more of network topologies, including bus networks, star networks, ring networks, mesh networks, star-bus networks, trees, or hierarchical networks, but It is not limited.
  • Each of the servers 150 and 160 communicates with the plurality of electronic devices 110, 120, 130, and 140 through the network 170 to provide a command, code, file, content, service, or the like. It may be implemented in devices.
  • the server 150 may be a system that provides a first service to a plurality of electronic devices 110, 120, 130, and 140 connected through the network 170, and the server 160 may also have a network ( It may be a system that provides a second service to the plurality of electronic devices 110, 120, 130, and 140 connected through the 170.
  • the server 150 may be a system that provides a remittance service to a plurality of electronic devices 110, 120, 130, and 140 as a first service.
  • the server 160 may be a system that provides a messaging service or a payment service as a second service to the plurality of electronic devices 110, 120, 130, and 140.
  • a server 160 providing a messaging service and a server 150 providing a money transfer service may be linked to each other to process a transfer through a messaging service.
  • General processing techniques for such remittance services or messaging services will be readily understood by those skilled in the art through well known prior art.
  • 2 is a block diagram illustrating an internal configuration of an electronic device and a server according to an embodiment of the present invention. 2 illustrates an internal configuration of the electronic device 1 110 and the server 150 as an example of the electronic device. In addition, the other electronic devices 120, 130, 140, or the server 160 may also have the same or similar internal configuration as the aforementioned electronic device 1 110 or the server 150.
  • the electronic device 1 110 and the server 150 may include memories 211 and 221, processors 212 and 222, communication modules 213 and 223, and input / output interfaces 214 and 224.
  • the memories 211 and 221 are computer-readable recording media, and may include non-volatile permanent storage devices such as random access memory (RAM), read only memory (ROM), and disk drives.
  • non-volatile mass storage device such as a ROM and a disk drive may be included in the electronic device 1 110 or the server 150 as a separate permanent storage device that is separated from the memories 211 and 221.
  • the memory 211, 221 includes an operating system and at least one program code (for example, a browser installed and driven in the electronic device 1 110 or an application installed in the electronic device 1 110 to provide a specific service). Code) can be stored. These software components may be loaded from a computer readable recording medium separate from the memories 211 and 221. Such a separate computer-readable recording medium may include a computer-readable recording medium such as a floppy drive, a disk, a tape, a DVD / CD-ROM drive, a memory card, and the like. In other embodiments, software components may be loaded into the memory 211, 221 through the communication module 213, 223 rather than a computer readable recording medium.
  • the at least one program is based on a memory (based on a program (for example, the above-described application) installed by files provided through a network by a file distribution system that distributes installation files of developers or applications). 211, 221.
  • Processors 212 and 222 may be configured to process instructions of a computer program by performing basic arithmetic, logic, and input / output operations. Instructions may be provided to the processors 212, 222 by the memory 211, 221 or the communication modules 213, 223. For example, the processors 212 and 222 may be configured to execute a command received according to a program code stored in a recording device such as the memory 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 through the network 170, and the electronic device 1 110 and / or the server 150 may communicate with each other. May provide a function for communicating with another electronic device (eg, electronic device 2 120) or another server (eg, server 160). For 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 the memory 211 may be controlled by the server 170 through the network 170 under the control of the communication module 213. 150).
  • control signals, commands, contents, files, and the like provided according to the control of the processor 222 of the server 150 are transmitted to the communication module of the electronic device 1 110 via the communication module 223 and the network 170 ( It may be received by the electronic device 1110 through 213.
  • the control signal, command, content, file, etc. of the server 150 received through the communication module 213 may be transmitted to the processor 212 or the memory 211, and the content, file, etc. may be transferred to the electronic device 1.
  • 110 may be stored as a storage medium (permanent storage described above) that may further include.
  • the input / output interface 214 may be a means for interfacing with the input / output device 215.
  • the input device may include a device such as a keyboard or a mouse, and the output device may include a device such as a display or a speaker.
  • the input / output interface 214 may be a means for interfacing with a device in which functions for input and output are integrated into one, such as a touch screen.
  • the input / output device 215 may be configured as one device with the electronic device 1110.
  • the input / output interface 224 of the server 150 may be a means for interfacing with an apparatus (not shown) for input or output that may be connected to or included in the server 150.
  • the processor 212 of the electronic device 1110 uses data provided by the server 150 or the electronic device 2 120 in processing a command of a computer program loaded in the memory 211.
  • the service screen or the content may be displayed on the display through the input / output interface 214.
  • the electronic device 1 110 and the server 150 may include more components than those of FIG. 2. However, it is not necessary to clearly show most of the prior art components.
  • the electronic device 1 110 may be implemented to include at least some of the above-described input / output devices 215 or other components such as a transceiver, a global positioning system (GPS) module, a camera, various sensors, a database, and the like. It may further include elements.
  • GPS global positioning system
  • an acceleration sensor when the electronic device 1 110 is a smartphone, an acceleration sensor, a gyro sensor, a camera module, various physical buttons, a button using a touch panel, an input / output port, and vibration for a smartphone generally include Various components such as a vibrator may be implemented to be further included in the electronic device 1 110.
  • 3 is a diagram showing an example of the overall structure of a payment system according to an embodiment of the present invention.
  • 3 shows a payment server 310, a transaction history database 320, a sender terminal 330 and a receiver terminal 340.
  • the payment server 310 may be implemented as the server 150 described above, and the transmitter terminal 330 and the receiver terminal 340 may be implemented as the electronic device 1 (110) described above.
  • the transaction history database 320 may be implemented to be included in the payment server 310, but according to an embodiment, the transaction history database 320 is included in a separate device from the payment server 310 so that the separate device and the payment server 310 communicate through a network. By doing so, payment server 310 may be implemented to access transaction history database 320.
  • the payment server 310 may receive a remittance request through the sender terminal 330 to identify an account of the receiver, which is a target person, and process the requested amount to be remitted to the account of the identified receiver.
  • the payment server 310 may specify the remittance account of the sender and the receiving account of the receiver in relation to the remittance request received from the sender terminal 330 through the network.
  • the transfer request may include the sender's remittance account and the receiver's receiving account, the payment server 310 registers the user's account in advance, and the remittance request is The corresponding account may be extracted using the identification information (user identifier, messenger account identifier, phone number, etc.) to be included.
  • This remittance technique itself will be readily understood by those skilled in the art using conventional techniques that are well known.
  • the payment server 310 may determine whether there is a past transaction history between the sender and the receiver by searching the transaction history database 320 using the specified remittance account and the receiving account, Different recipient authentication methods can be applied depending on their existence. For example, if there is a past transaction history between the sender's remittance account and the receiver's recipient account, the payment server 310 skips the procedure for verifying a separate recipient and sends the requested remittance because there is less need to doubt the recipient. Can be processed. The processing of the remittance itself will be readily understood by those skilled in the art using conventional techniques that are well known.
  • the payment server 310 may proceed with the procedure for identifying the receiver. First, the payment server 310 may calculate the degree of risk of the receiver based on at least one of a transaction history of the receiver with other users, a conversation record between the sender and the receiver through a messaging service between the sender and the receiver, and a list of receiving accounts designated by the sender. The authentication method of the recipient can be determined based on the calculated degree of danger of the recipient.
  • the payment server 310 may calculate the first degree of risk according to at least one of the number and duration of transactions with other users using the receiver's receiving account. If the recipient's receiving account is an account that has been used for a long time already in a transaction with other users, the recipient's first risk may be relatively low. Thus, the first degree of risk can be calculated to be lower as the time period is longer. The number of times may also be used to determine the first degree of risk of the recipient. In this case, the first degree of risk may be calculated to be lower as the number of times increases. In addition, when both the number and the period are used, the first degree of risk may be calculated by giving higher weight to the period. This is because, in the case of a large number of transactions recently, the reliability of the number of transactions is lowered.
  • the payment server 310 may determine the second degree of risk according to at least one of the presence or absence of a chat record through the messaging service between the sender and the receiver, the number of conversations extracted through the chat record, and the duration of the conversation extracted through the chat record. Can be calculated For example, if the sender has already had many conversations with the recipient over a long period of time through the messaging service, the payment server 310 may calculate the second degree of risk relatively low since it may determine that the recipient is at low risk. As a more specific example, when there is a conversation record, the payment server 310 may calculate the second degree of risk so that the number of conversations is higher, and the longer the conversation period, the lower the second degree of risk.
  • the payment server 310 directly includes a messenger server that provides a messaging service and directly stores and manages a conversation record between users, or communicates with a messenger server (for example, the server 160) implemented separately. Can be provided with a conversation record between the sender and the receiver.
  • a messenger server for example, the server 160
  • user B After the date when user A and user B conducted an instant messenger (for example, May 5), user B registers a new bank account with the payment account 310 as a receiving account (for example, May 7). I can do it. After registration of the receiving account, user A and user B conduct a messenger conversation for a certain period of time (for example, May 8 to May 9), after which user A sends money to user B (for example, May 10) can be considered. In this case, the payment server 310 may calculate the second degree of risk based on the period according to the messenger conversation record and the registration date of the receiving account.
  • the payment server 310 may calculate the third degree of risk according to whether the receiver's receiving account is included in the receiving account list designated by the sender. For example, if the receiver's receiving account is included in the list of receiving accounts specified by the sender, the payment server 310 omits the calculation of the first degree of risk and the second degree of risk, and sets the degree of risk of the recipient to a threshold or less. Can be.
  • the degree of risk of the receiver may be calculated using at least one of the above-described first degree of risk, second degree of risk and third degree of risk.
  • the payment server 310 may proceed with an additional recipient identification process if the recipient's risk level is greater than or equal to the threshold. If the recipient's risk level is less than the threshold, the payment server 310 may proceed with the remittance process without having to perform a separate recipient identification process. have.
  • the separate recipient identity verification process may proceed as the payment server 310 processes at least one of a first process of sending a warning message to the sender and a second process of requesting the identity verification message to the recipient.
  • the first process may be a process of sending a warning message over the network to the sender terminal 330 to warn the sender to confirm the recipient.
  • the payment server 310 may process the remittance request of the sender in response to receiving the confirmation response to the warning message from the sender terminal 330.
  • the second process may also be a process for requesting the recipient to send a proof of identity message.
  • the payment server 310 does not directly authenticate the identity certificate message, but transmits the identity certificate message to the sender terminal 320 through the network, and confirms the identity message through the network from the sender terminal 320.
  • the sender's request can be processed.
  • the identity verification message may include information that allows the sender to authenticate that the recipient is the recipient.
  • a proof-of-identity message may contain information about what the sender and receiver know only about each other, or include a picture of the recipient (image information including shooting time information). It may include information generated to authenticate the.
  • FIG. 4 is a flowchart illustrating an example of a remittance process according to an embodiment of the present invention.
  • the flowchart of FIG. 4 may be performed by the payment server 310.
  • Step 410 is an account specification process, and the payment server 310 may specify the sender's sending account and the receiver's receiving account in step 410.
  • the method of specifying the sender's sending account and the receiver's receiving account according to the sender's request for transmission has been described.
  • Step 420 is a transaction history search process
  • the payment server 310 may search the past transaction history between the sender's transmitting account and the receiver's receiving account in the transaction history database 320 in step 420.
  • Step 430 is a process of determining whether a transaction history exists, the payment server 310 in the transaction history database 320 in step 430 whether there is a past transaction history between the sender's sending account and the receiver's receiving account. Can be determined.
  • step 460 may be performed if there is a transaction history
  • step 440 may be performed if there is no transaction history.
  • Step 440 is a risk level calculation process
  • the payment server 310 may calculate the risk level of the recipient in step 440.
  • An example of calculating the degree of risk of the recipient has been described in detail 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 receiver with the preset first threshold in step 450 and the degree of risk is the first threshold. If less than step 460, if the degree of risk is above the first threshold step 451 may be performed.
  • Step 460 is a remittance processing process
  • the payment server 310 may process a process for transferring the requested amount from the sender's remittance account to the receiver's receiving account in step 460 according to the sender's remittance request .
  • the payment server 310 communicates with the server of the bank where the remittance account and the receiving account are opened to process the transfer of the requested amount or transfer the requested amount from the remittance account to the parent account associated with the payment server 310.
  • the transfer can then be processed according to the requested amount through one of the well known arts, such as transferring the requested amount from the parent 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 recipient's degree of risk with a preset second threshold in step 451 to determine the degree of risk being second.
  • Step 452 may be performed if the threshold is exceeded, and step 454 may be performed if the degree of risk is less than or equal to the second threshold.
  • Step 452 is a process of requesting a proof of identity message, the payment server 310 may request to forward the identity verification message to the recipient in step 452.
  • the identity message has been described in detail above.
  • Step 453 is a sender verification process
  • the payment server 310 may send the identity verification message transmitted from the receiver to the sender so that the sender authenticates the receiver through the identity verification message.
  • the payment server 310 may process step 460 in response to receiving a confirmation response to the identity verification message from the sender, and if the confirmation response to the identity verification message is not confirmed from the sender (I
  • the attestation message allows the sender to authenticate the recipient, so that a cancellation response is received, or if an acknowledgment is not received for a certain period of time), or the transfer can be cancelled.
  • Step 454 is a warning message sending process, where the payment server 310 may send a warning message to the sender if the recipient's degree of risk is above the first threshold but below the second threshold in step 454.
  • step 453 may be a process in which the payment server 310 receives an acknowledgment of the sender for the warning message. If the payment server 310 receives the sender's acknowledgment for the alert message, it may perform step 460 to process the transfer, and if the acknowledgment for the alert message is not confirmed from the sender (warning message) If a cancellation response is received from the sender that has received the message or an acknowledgment is not received for a certain period of time), the transfer can be cancelled.
  • the payment server 310 may vary in a method for authenticating the receiver step by step depending on the existence of the transaction history and the degree of risk of the receiver, and if necessary, the sender directly provides the information for the receiver to authenticate himself / herself. By allowing the recipient to authenticate, more secure transfer processing is possible.
  • FIG. 5 is a diagram illustrating an example of a screen of a sender terminal receiving an identity verification message according to one embodiment of the present invention.
  • FIG. 5 shows a screen 510 in which the sender terminal 330 displays the receiver's identity message "My nickname is OO."
  • the identity verification message of the receiver transmitted to the sender terminal 330 may be displayed on the screen 510 of the sender terminal 330 in the form of a popup window 520. It will be readily understood by those skilled in the art that the display form of the identity verification message may be variously changed according to an embodiment as an example.
  • the sender can authenticate the recipient through this identity verification message, and select the "OK” button 530 or the “Cancel money transfer” button 540 depending on the authentication (for example, the area where each button is displayed in the touch screen environment). Touch with a finger), the payment server 310 may confirm the receiver from the sender to proceed with the transfer or cancel the transfer.
  • 6 is a diagram illustrating an example of a screen of a sender terminal receiving a warning message according to an embodiment of the present invention.
  • 6 illustrates a screen 610 in which a warning message delivered 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 the account number to be checked once again, and request the sender to confirm the response to the warning message.
  • the sender selects the "confirm" button 630 or the "cancel transfer” button 640 (for example, a finger touches an area where each button is displayed in a touchscreen environment), the payment server 310 proceeds with the transfer or Or you can cancel the transfer.
  • FIG. 7 is a block diagram illustrating an example of a component that a processor of a payment server may include, according to an embodiment of the present invention.
  • FIG. 8 is a flowchart of a payment server according to an embodiment of the present invention. It is a flowchart which shows the example of a payment method. In the present embodiments, an example in which the payment server 310 described above is implemented as the server 150 will be described.
  • the processor 222 and the components of the processor 222 may perform steps 810 to 860 included in the payment method of FIG. 8.
  • the processor 222 and the components of the processor 222 may be implemented to execute instructions according to code of an operating system and / or code of at least one computer program included in the memory 221.
  • the components of the processor 222 are representations of different functions of the processor 222 performed by the processor 222 in accordance with control instructions provided by the code of the computer program stored in the server 150. Can be heard.
  • the processor 222 may read a necessary control command from the memory 221 loaded with a command related to the control of the server 150, and the steps 810 to 860 to be described later according to the read control command.
  • the server 150 may be controlled to perform.
  • the account specifying unit 710 may specify the sender's remittance account and the receiver's receiving account in connection with the transfer request received from the sender's terminal through the network.
  • the transaction history search unit 720 may retrieve a past transaction history between the remittance account and the receiving account from the transaction history database.
  • the transaction history database may correspond to the transaction history database 320 described above with reference to FIG. 3.
  • the risk level calculation unit 730 if there is no past transaction history, the transaction history with the other users of the receiver, the conversation history through the messaging service between the sender and the receiver, and the list of receiving accounts specified by the sender
  • the degree of risk of the recipient can be calculated based on at least one.
  • the risk level calculator 730 may record the first risk level, the conversation between the sender and the receiver, based on at least one of the number and duration of transactions with other users using the receiver's receiving account.
  • the receiver's receiving account is included in the list of receiving accounts specified by the sender, and the second degree of risk calculated according to at least one of the presence or absence of a message, the number of conversations extracted from the conversation history, and the duration of the conversations extracted from the conversation history
  • the degree of danger of the recipient can be calculated using at least one of the third degree of risk, which is calculated according to whether there is.
  • the authentication method determination unit 740 may determine the authentication method of the receiver based on the calculated degree of risk of the receiver. At this time, the authentication method determination unit 740 may process the second process for requesting the identity verification message to the recipient according to the calculated degree of risk of the recipient.
  • step 850 when the transfer request processing unit 750 requests the identity verification message to the receiver, it may send the identity verification message received from the terminal of the receiver to the sender.
  • step 860 when the remittance request processing unit 750 receives a confirmation response to the identity verification message from the sender, the remittance request processing unit 750 may process the remittance request of the sender.
  • the steps 810 to 860 of FIG. 8 may correspond to an embodiment in which there is no transaction history, and the degree of risk calculated for the receiver exceeds a second predetermined threshold.
  • FIG. 9 is a flowchart illustrating an example of a payment method for transmitting an alert message according to an embodiment of the present invention.
  • the payment method of FIG. 9 may include steps 810 to 840 of steps 810 to 860 of FIG. 8, and may further include steps 910 and 920. Steps 910 and 920 may be performed after step 840.
  • the authentication method determination unit 740 may determine the authentication method of the receiver based on the calculated degree of risk of the receiver. On the other hand, the authentication method determination unit 740 may process the first process of sending a warning message to the sender according to the calculated degree of risk of the receiver, unlike in FIG.
  • the transfer request processing unit 750 may receive an acknowledgment for the warning message sent to the sender from the sender's terminal.
  • the remittance request processor 750 may process the remittance request of the sender according to the receipt of the confirmation response to the warning message.
  • Steps 840, 910, and 920 of FIG. 9 are embodiments in which there is no transaction history found in step 820, and the degree of risk calculated for the receiver is greater than or equal to a predetermined first threshold and less than or equal to a second threshold. May correspond to.
  • the processor 222 may process the requested remittance without any other receiver identity verification process. In addition, even if there is no transaction history, the processor 222 may process the remittance without any other receiver identification process if the degree of risk of the receiver is less than the first threshold. In addition, the processor 222 may cancel the transfer process when there is no sender's confirmation response to the identity verification message or the sender's confirmation response to the warning message.
  • the system or apparatus described above may be implemented as a hardware component, a software component or a combination of hardware components and software components.
  • the devices and components described in the embodiments are, for example, processors, controllers, arithmetic logic units (ALUs), digital signal processors, microcomputers, field programmable gate arrays (FPGAs).
  • ALUs arithmetic logic units
  • FPGAs field programmable gate arrays
  • PLU programmable logic unit
  • the processing device may execute an operating system (OS) and one or more software applications running on the operating system.
  • the processing device may also access, store, manipulate, process, and generate data in response to the execution of the software.
  • processing device includes a plurality of processing elements and / or a plurality of types of processing elements. It can be seen that it may include.
  • the processing device may include a plurality of processors or one processor and one controller.
  • other processing configurations are possible, such as parallel processors.
  • the software may include a computer program, code, instructions, or a combination of one or more of the above, and configure the processing device to operate as desired, or process it independently or collectively. You can command the device.
  • Software and / or data may be any type of machine, component, physical device, virtual equipment, computer storage medium or device in order to be interpreted by or to provide instructions or data to the processing device. It can be embodied in.
  • the software may be distributed over networked computer systems so that they may be stored or executed in a distributed manner.
  • Software and data may be stored on one or more computer readable recording media.
  • the method according to the embodiment may be embodied in the form of program instructions that can be executed by various computer means and recorded in 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 media may be those specially designed and constructed for the purposes of the embodiments, or they may be of the kind well-known and available to those having skill in the computer software arts.
  • Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tape, optical media such as CD-ROMs, DVDs, and magnetic disks, such as floppy disks.
  • Examples of program instructions include not only machine code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like.
PCT/KR2016/014581 2016-12-13 2016-12-13 지불 방법 및 시스템 WO2018110723A1 (ko)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2019530182A JP6941255B2 (ja) 2016-12-13 2016-12-13 支払い方法および支払いシステム
PCT/KR2016/014581 WO2018110723A1 (ko) 2016-12-13 2016-12-13 지불 방법 및 시스템
CN201680090166.4A CN109891450B (zh) 2016-12-13 2016-12-13 支付方法及系统
JP2021081042A JP7101292B2 (ja) 2016-12-13 2021-05-12 支払い方法およびシステム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/KR2016/014581 WO2018110723A1 (ko) 2016-12-13 2016-12-13 지불 방법 및 시스템

Publications (1)

Publication Number Publication Date
WO2018110723A1 true WO2018110723A1 (ko) 2018-06-21

Family

ID=62559826

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2016/014581 WO2018110723A1 (ko) 2016-12-13 2016-12-13 지불 방법 및 시스템

Country Status (3)

Country Link
JP (2) JP6941255B2 (zh)
CN (1) CN109891450B (zh)
WO (1) WO2018110723A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6799837B1 (ja) * 2020-01-24 2020-12-16 株式会社Ｇｅｎｅｓｉｓ 電子通貨利用情報システム及び電子通貨利用方法
KR20210127383A (ko) * 2020-04-14 2021-10-22 삼성전자주식회사 블록체인 주소로 암호화폐를 송금하는 전자 장치와 이의 동작 방법

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050131816A1 (en) * 1999-05-14 2005-06-16 Britto Mark J. Computer-based funds transfer system
KR100847710B1 (ko) * 2006-06-08 2008-07-23 이베이 인크. 복수의 당사자들 간의 소액결제의 용이화
US20140052633A1 (en) * 2012-08-15 2014-02-20 Ebay Inc. Payment in a chat session
KR101388654B1 (ko) * 2012-03-13 2014-04-24 주식회사 한국프라임테크놀로지 금융사기 의심거래 모니터링 시스템 및 방법
KR20160140969A (ko) * 2014-12-16 2016-12-07 페이스북, 인크. 당일 결제 거래의 용이화

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4350678B2 (ja) * 2005-03-25 2009-10-21 富士通株式会社 金融取引処理装置
JP2007102620A (ja) * 2005-10-06 2007-04-19 Oki Electric Ind Co Ltd 現金振込システム
CN101093569A (zh) * 2006-06-23 2007-12-26 上海浦东发展银行股份有限公司 一种电子汇款方法
JP5549088B2 (ja) * 2009-03-13 2014-07-16 沖電気工業株式会社 不正取引防止システム及び不正取引防止方法
US20110055061A1 (en) * 2009-08-25 2011-03-03 American International Group, Inc. Method and system for retaining customers with interrupted payment streams
KR20130015139A (ko) * 2011-08-02 2013-02-13 인포뱅크 주식회사 음성통화 기반 송금처리 방법 및 시스템
CN103365819A (zh) * 2012-03-30 2013-10-23 周燕 具有网络转账与收支功能的电子计算器及其网络转账方法
CN103049851A (zh) * 2012-12-27 2013-04-17 中国建设银行股份有限公司 一种基于交易数据的反欺诈监控方法和装置
KR20140147303A (ko) * 2013-06-19 2014-12-30 주식회사 우리은행 자금 이동 모니터링 방법 및 이를 실행하는 서버
CN103578031A (zh) * 2013-11-14 2014-02-12 交通银行股份有限公司 一种快捷转账方法及系统
CN104679777B (zh) * 2013-12-02 2018-05-18 中国银联股份有限公司 一种用于检测欺诈交易的方法及系统
CN104021472A (zh) * 2014-05-30 2014-09-03 中国工商银行股份有限公司 身份验证方法及系统
US20160104132A1 (en) * 2014-10-08 2016-04-14 Facebook, Inc. Performing risk checks for electronic remittances
US20160104133A1 (en) * 2014-10-08 2016-04-14 Facebook, Inc. Facilitating sending and receiving of remittance payments
CN105429948B (zh) * 2015-10-28 2018-12-25 东莞酷派软件技术有限公司 一种危险账户的识别方法及装置
CN105654303B (zh) * 2015-12-31 2022-02-11 拉扎斯网络科技（上海）有限公司 一种高风险用户识别方法及装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050131816A1 (en) * 1999-05-14 2005-06-16 Britto Mark J. Computer-based funds transfer system
KR100847710B1 (ko) * 2006-06-08 2008-07-23 이베이 인크. 복수의 당사자들 간의 소액결제의 용이화
KR101388654B1 (ko) * 2012-03-13 2014-04-24 주식회사 한국프라임테크놀로지 금융사기 의심거래 모니터링 시스템 및 방법
US20140052633A1 (en) * 2012-08-15 2014-02-20 Ebay Inc. Payment in a chat session
KR20160140969A (ko) * 2014-12-16 2016-12-07 페이스북, 인크. 당일 결제 거래의 용이화

Also Published As

Publication number Publication date
JP2020502651A (ja) 2020-01-23
JP2021185477A (ja) 2021-12-09
JP7101292B2 (ja) 2022-07-14
JP6941255B2 (ja) 2021-09-29
CN109891450A (zh) 2019-06-14
CN109891450B (zh) 2023-09-22

Similar Documents

Publication Publication Date Title
US20210256431A1 (en) Methods for unlocking shared bikes
JP6882924B2 (ja) 互いに異なるユーザ識別体系を利用して登録されたユーザを識別するサーバ間のサービス連動方法、システムおよびコンピュータプログラム
CN107370657B (zh) 设备间应用程序联动方法及系统
WO2015026126A1 (ko) 보안이 강화된 모바일카드 함께쓰기 서비스 방법 및 시스템
CN109387217B (zh) 导航方法、计算机可读存储介质及导航服务器
EP3744067A1 (en) Method and apparatus for managing user authentication in a blockchain network
WO2018030554A1 (ko) 메시지 기반 통지를 제공하기 위한 방법 및 시스템
WO2018160039A1 (ko) 분할 기능을 이용한 자동 인증 처리 방법 및 시스템
WO2020213763A1 (ko) 블록체인과는 다른 형식의 저장소에 저장되는 블록체인 데이터를 검증하는 방법 및 시스템
JP2021022938A (ja) 位置離脱による通知を提供する装置およびプログラム
JP7101292B2 (ja) 支払い方法およびシステム
WO2019235653A1 (ko) 근거리 무선 통신을 기반으로 근처 지인을 파악하기 위한 방법과 시스템 및 비-일시적인 컴퓨터 판독 가능한 기록 매체
WO2019053589A1 (en) SYSTEM AND METHOD FOR USER AUTHENTICATION
WO2020096072A1 (ko) 디앱에서 요구하는 높은 트랜잭션 처리량을 효율적으로 블록체인에서 처리하기 위한 방법 및 시스템
JP6446499B2 (ja) 決済を処理する方法およびシステム
KR20200044167A (ko) 메신저 봇을 이용하여 ＩｏＴ 기기를 제어하기 위한 방법, 시스템, 및 비-일시적인 컴퓨터 판독가능한 기록 매체
KR101800127B1 (ko) 웹―앱 연동 간편 로그인을 위한 방법 및 시스템
US10523668B2 (en) Authentication method with enhanced security based on eye recognition and authentication system thereof
WO2018092948A1 (ko) 송금 방법 및 시스템
CN108111374A (zh) 同步设备列表的方法、装置、设备和计算机存储介质
WO2019156263A1 (ko) 대화방을 3차원 형태로 제공하는 방법과 시스템 및 비-일시적인 컴퓨터 판독 가능한 기록 매체
AU2019246929A1 (en) A System and Method for Providing Authentication and Authorisation for a Person to Perform Specific Instructions (Tasks)
WO2019172463A1 (ko) 프로필 사진을 추천하는 방법과 시스템 및 비-일시적인 컴퓨터 판독 가능한 기록 매체
WO2021125399A1 (ko) 블록체인에서의 스마트 컨트랙트를 이용한 에스크로 거래 방법 및 시스템
WO2019240305A1 (ko) 사용 정도에 기초하여 대화방을 처리하는 방법과 시스템 및 비-일시적인 컴퓨터 판독가능한 기록 매체

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16923850

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019530182

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16923850

Country of ref document: EP

Kind code of ref document: A1