KR20190032970A - Method of generating dept information related to money transfer - Google Patents

Abstract

Disclosed is a method for generating a bond linked to remittance comprising: a bond DB for storing bond information between users; a bond DB for storing bond information between first users from a first user terminal; a remitting unit for receiving from the first user terminal a remittance instruction of a first amount from a first user account to a second user account and remitting the remittance; and a bond management unit for generating bond information comprising creditor information including the first user information, debtor information including the second user information, and payment information including the first amount information and storing the generated bond information in the bond DB.

Description

[0001] FIELD OF THE INVENTION [0002]

Embodiments of the invention relate to a method of generating bonds in conjunction with remittance.

The bond means the right of a creditor to claim a certain act on the debtor, such as 'pay money' or 'deliver the goods'. If the debtor does not voluntarily do the action, the creditor may bring a suit to the court and force it to do so.

The act of borrowing money from someone else in everyday life generates a bond, no matter how small. It is becoming more common to borrow a small amount of money between users with Dutch Fake activated. However, even though it is a tangible bond, it is easily forgotten due to the small amount of money, or it is forgotten because it is neglected for reasons such as filing a claim.

Embodiments of the present invention provide a method of generating a bond in conjunction with remittance.

One embodiment of the present invention is a transaction processing system comprising: a receipt DB for storing receipt information between users; A remitting unit for receiving a remittance instruction of the first amount from the first user terminal to the second user account and remitting the remittance; And a creditor generating unit configured to receive a creditor creation request corresponding to the remittance processing and to receive creditor information including information of the first user corresponding to receipt of the request for generating a bond, And a bond management unit for generating bond information including benefit information including the one-amount information and storing the generated bond information in the bond DB.

Other aspects, features, and advantages will become apparent from the following drawings, claims, and detailed description of the invention.

These general and specific aspects may be implemented by using a system, method, computer program, or any combination of systems, methods, and computer programs.

According to the embodiments of the present invention, since the remittance service and the bond management service are provided in conjunction with each other, an effect of managing the bond information securely and accurately based on the remittance details actually generated occurs.

1 schematically shows a service providing system according to an embodiment of the present invention.
2A is a block diagram schematically illustrating a service providing apparatus 100 according to an embodiment of the present invention.
2B is a block diagram schematically illustrating a terminal control apparatus 200 according to an embodiment of the present invention.
FIG. 3A is a flowchart illustrating a remittance service and a method for providing a bond management service in accordance with an embodiment of the present invention.
4A is a flowchart illustrating a remittance service and a method for providing a bond management service in accordance with another embodiment of the present invention.
FIG. 3B is an example of a screen in which the information received in step 34 of FIG. 3A is displayed on the second user terminal 22.
FIG. 4B is an example of a screen displayed on the first user terminal 21 for final selection of a settlement target bond.
FIG. 4C shows another example of the screen displayed on the first user terminal 21 for the final selection of the settlement target bond.
4D is another example of the screen displayed on the first user terminal 21 for the final selection of the settlement target bond.
5A is a flowchart illustrating a messenger service according to an exemplary embodiment of the present invention.
5B is an example of a friend list screen displayed on the user terminal 20. [
FIG. 5C is an example of a screen displayed when the display element 524 is selected in the screen of FIG. 5B.
FIG. 5D is an example of a screen in which a list of bonds is displayed on the first user terminal 21. FIG.
5E is another example of the friend list screen displayed on the user terminal 20. [
5F is another example of the friend list screen displayed on the user terminal 20. [
FIG. 5G is an example of a screen that can be displayed on the user terminal 20 when the first display element 524 shown in FIG. 5F is selected.
FIG. 6 is a flowchart illustrating a method of generating bond information according to an embodiment.
FIG. 6A is an example of a screen for requesting a bond creation according to an embodiment.
6B is an example of a screen displayed when an icon is selected on the screen of FIG. 6A.
6C is a flowchart illustrating a method of generating bond information according to an embodiment.
FIG. 6D is an example of a screen for requesting remittance according to an embodiment.
FIG. 6E is an example of a screen displayed when an icon is selected on the screen of FIG. 6C.
FIG. 6F is an example of a screen displayed on the first user terminal after the money is input on the screen of FIG. 6E and confirmation is selected and the transfer is completed.
6G is an example in which a plurality of divided messages are shown.
FIG. 6H is an example of a screen displaying an information input window for further inputting the bond information.

BRIEF DESCRIPTION OF THE DRAWINGS The present invention is capable of various modifications and various embodiments, and specific embodiments are illustrated in the drawings and described in detail in the detailed description. The effects and features of the present invention and methods of achieving them will be apparent with reference to the embodiments described in detail below with reference to the drawings. However, the present invention is not limited to the embodiments described below, but may be implemented in various forms.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings, wherein like reference numerals refer to like or corresponding components throughout the drawings, and a duplicate description thereof will be omitted .

In the following embodiments, the terms first, second, and the like are used for the purpose of distinguishing one element from another element, not the limitative meaning. In the following examples, the singular forms "a", "an" and "the" include plural referents unless the context clearly dictates otherwise. In the following embodiments, terms such as inclusive or possessive are intended to mean that a feature, or element, described in the specification is present, and does not preclude the possibility that one or more other features or elements may be added. In the drawings, components may be exaggerated or reduced in size for convenience of explanation. For example, the size and thickness of each component shown in the drawings are arbitrarily shown for convenience of explanation, and thus the present invention is not necessarily limited to those shown in the drawings.

1 schematically shows a service providing system according to an embodiment of the present invention.

Referring to FIG. 1, a service providing system includes a server 10 for providing services and a user terminal 20 for receiving services. The communication network 30 and the arrows shown in Fig. 1 mean that the server 10 and the user terminal 20 can transmit / receive data via the communication network 30. Fig.

The user terminal 20 may be a PC, a smart phone, a tablet, a notebook, or the like, and may be connected to a web / mobile site related to the server 10 or a service dedicated application (hereinafter, Can be installed and executed. The user terminal 20 can perform a service-wide operation such as service screen configuration, data input, data transmission / reception, and data storage under the control of a connection of a web / mobile site or a service application. In FIG. 1, a first user terminal 21, a second user terminal 22 and a third user terminal 23 are illustrated as an example to explain that a plurality of user terminals 20 may exist. Each of the user terminals 20 can access the server 10 through the communication network 30 and use the remittance service.

The server 10 serves to provide one or more services to a user terminal 20 as a client. Basically, the server 10 can provide a remittance service between users.

The server 10 may provide a bond management service. For example, the server 10 may store the bond information between the user terminals 20, and may provide the bond management service based on the bond information to the user terminal 20. The bond management service can refer to all services based on bond information among users such as bond creation, bond editing, bond inquiry, bond status indication, and bond status based notification.

The server 10 can provide a remittance service and a bond management service in cooperation with each other. The server 10 can provide a bond management service interlocked with a remittance service and can provide a remittance service interlocked with the bond management service.

The server 10 can provide a messenger service. The server 10 can provide a remittance service, a bond management service, and a messenger service in cooperation with each other. The server 10 may provide at least one of a remittance service and a debt management service and a messenger service in cooperation with each other.

In the following, the term "bond information" means information about the bond, which is the right of the creditor to demand payment to the debtor. The bond information may include creditor information, debtor information, and benefit information. In describing the embodiments of the present invention, an explanation will be given of an example in which the payment is money transfer (including transfer between accounts). The benefit information may include the amount of the bond, the timing of delivery, and information about interest.

Hereinafter, " user " may refer to a user terminal, " creditor " may refer to a creditor terminal, and " debtor " It is understood that the user terminal may include a creditor terminal and / or a debtor terminal.

Hereinafter, various embodiments for handling remittance and bond information management associated therewith will be described, and a sender who sends money can be referred to as a first user, and a receiver who receives money can be referred to as a second user.

2A is a block diagram schematically illustrating a service providing apparatus 100 according to an embodiment of the present invention.

The service providing apparatus 100 may be provided on the server 10 side.

Referring to FIG. 2A, the service providing apparatus 100 may include a storage device 21 for storing data and a processor 22 for processing data.

The storage device 21 includes an account DB 211 for storing user account information of users and at least one information associated with a user account; And a bond DB 212 for storing bond information between users. In the account DB 211, information necessary for remittance, for example, financial account information associated with a user's login account and / or financial account information of another user can be stored. The financial account information of the other user may include information on accounts remitted through the processor 22 and / or account information optionally stored for remittance. The financial account information may be stored dependent on the user's login account. The financial account information may include already existing financial account information, but the present invention is not limited thereto, and may include virtual account information linked with user account information. The virtual account information may be directly linked to the financial account of the user, but is not limited thereto. It may be a virtual account existing in the user, or a notification about a virtual account that the user will open in the future . The user account information may include a name, an ID, and / or a nickname of users applied to the messenger service and / or the messenger application.

The processor 22 may include a remitter 221 for providing a remittance service, a bond management unit 222 for providing a bond management service, and a messenger management unit 223 for providing a messenger service.

The remitter 221 according to an embodiment processes remittance between user accounts. The remitter 221 receives the remittance request from the remitter terminal, and can process remittance from the remitter account to the remitter account in response to the remittance request. The remittance request may include the receiver account information and the remittance amount information. The remittance request may include authentication information, such as a password, for authenticating the sender account. The information included in the remittance request may be received simultaneously or sequentially. A request for remittance can be made to the receiver's account. The request for remittance may be requested to the receiver's account information stored in the receiver's account in accordance with the request for remittance. In this case, the request for remittance may include a request for remittance of the real currency from the sender account to the receiver's account, including but not limited to a request for remittance of the virtual currency from the sender account to the receiver account . At this time, the virtual money may include securities that can be converted into money, such as cyber money and / or vouchers, which can be used in a limited and / or unrestricted space. Which can be applied to all embodiments described herein.

The remitter 221 according to one embodiment can provide a remittance service linked to a messenger service. The remitter 221 can receive the remittance request from the user through the messenger application. For example, the user can designate the receiver through the messenger application, generate a remittance request to remit the remittee, and the remittance unit 221 can receive the remittance request.

According to an example, the remitter 221 first charges the remitter with the virtual money in the virtual account of the sender, and then transfers the remitted money to the virtual account and / or the linked account of the receiver as virtual money and / or real money You can send money.

Meanwhile, the remitter 221 may process remittance between log-in accounts subscribed to the service provided according to an embodiment of the present invention or may transfer money between accounts of other financial institutions stored corresponding to the login account , Login account, and account of another financial institution. The remittance-related embodiment by the remittance unit 221 described in this specification can be applied to both remittance between login accounts, remittance between financial institutions' accounts, and remittance environment between a login account and a financial institution account. In addition, in the remittance-related embodiment by the remittance unit 221, not only direct remittance among users but also remittance of the remittance amount to the virtual account of the sender with virtual money, And / or the remittance environment in which the user is allowed to remit money in virtual currency and / or real currency to a linked account.

The bond management unit 222 according to an embodiment manages the bond information stored in the bond DB 212 and provides a bond management service.

The bond management unit 222 receives the bond creation request from the user, generates the bond information corresponding to the bond creation request, and stores the generated bond information in the bond DB 212. [ The bond information may include the benefit information, and the benefit information may further include the interest rate in addition to the bond amount. The bond creation request received from the user may include interest information, and the bond management unit 222 may set the interest rate of the bond information based on the interest information included in the bond creation request.

The bond creation request may include creditor information, debtor information, benefit information, and may be received from the creditor or debtor. When the bond creation request is received from the creditor, the bond management unit 222 can send a request for consent to the bond information to the debtor with reference to the debtor information, and can receive the agreement from the debtor. Conversely, when a bond creation request is received from the debtor, the bond management unit 222 can transmit a consent request for the bond information to the creditor by referring to the creditor information, and can receive the agreement from the creditor. The bond management unit 222 may omit the consent to the creditor for the bond creation request received from the debtor.

The bond creation request as described above can be interlocked with the remittance processing described above. For example, the bond creation request can be made automatically or automatically at the request of the sender in response to the remittance request of the sender.

The process for remittance and / or the creation of a bond as described above can be equally applied to the editing of settlement and / or bond information described later.

The bond management unit 222 may register the bond information with the consent of the creditor and / or the debtor who is a party to the bond, as the party that transmitted the bond creation request may have consented to the bond information.

The bond management unit 222 can edit the bond information stored in the bond DB 212. [

The bond management unit 222 receives the reimbursement information from the user and can edit the bond information stored in the reimbursement DB 212 based on the reimbursement information. The reimbursement information may include the bond identification information for specifying the bond information, and the reimbursement contents (for example, the reimbursed amount). The bond management unit 222 may delete the amount of the redeemed amount from the amount of the bond, and may delete the redeemable amount if the amount of the redeemed amount is no longer available. The deletion of the bond may mean to completely delete the bond information from the bond DB 212, but is not limited thereto. For example, the bond management unit 222 may store the bond settlement information and deactivate the bond information, but may leave the bond information in the bond DB 212 so that it can be inquired later.

Meanwhile, the bond identification information of the reimbursement information can be replaced with the information of the other user. In this case, the bond management unit 222 can inquire the bond information existing between the first user who is the user who transmitted the settlement information and the second user included in the settlement information, and edit the bond information by referring to the settlement contents. In this process, the bond management unit 222 may request the first user to select which of the one or more pieces of bond information to be edited, and edit the bond information selected by the first user.

When the bond management unit 222 receives the settlement information from the first user, the bond management unit 222 may transmit a consent request to the second user, which is the party of the settlement target bond and the counterpart of the first user. The consent request may include information corresponding to the reimbursement information received from the first user. For example, information on a reimbursable bond, and reimbursement contents. The bond management unit 222 can edit the bond information after receiving the consent of the second user.

The creditor information and the debtor information described above may include login account information subscribed to a service provided according to an embodiment of the present invention. If both the creditor information and the debtor information include the login account information, the bond management unit 222 provides the other service provided according to an embodiment of the present invention, for example, a bond management service linked to a remittance service and / or a messenger service can do.

The bond management unit 222 can provide a bond management service linked to the remittance service. The bond management unit 222 can suggest a bond creation and / or bond editing to the user based on the remittance history.

The bond management unit 222 can provide a bond management service linked to the messenger service. The user can designate the other party through the messenger application, and transmit the bond creation request between the designated party and the partner to the bond management unit 222. [

A messenger management unit 223 according to an embodiment provides a messenger service between users.

Users subscribed to a service provided according to an embodiment of the present invention can specify a predetermined relationship with another user and can use a messenger service capable of exchanging messages with another user specified in a predetermined relationship. The relationship between the users can be stored in the account DB 211. [ Hereinafter, the predetermined relationship is referred to as " friend " for the sake of convenience. That is, the user can use the messenger service provided by the messenger management unit 223 to exchange messages with other users designated as friends.

The messenger management unit 223 can provide the friend list through the service application. The messenger management unit 223 can receive the friend list request from the user terminal and inquire the account designated as the friend of the user in the account DB 211. [ According to an example, the messenger management unit 223 can transmit the information of the friend account that has been displayed to the user terminal, and the user terminal uses the friend account information received from the messenger management unit 223 to configure the friend list as a screen, can do. According to another example, the messenger management unit 223 can directly construct a friend list using the inquired friend account information and provide the friend list to the user terminal. Embodiments in which the messenger management unit 223 provides a friend list may be implemented through one or more of the above-mentioned two implementations.

The buddy list may include one or more panels that can briefly display the information of each user designated as buddies. One panel can correspond to one user and can display information of one user. In the panel, a user name (or nickname) that can identify the user can be displayed by default. It may be replaced with a photograph that identifies the user. The panel may further display texts (status messages, etc.) directly input by the user.

According to one embodiment of the present invention, the friend list provided by the messenger management unit 223 includes the bond information with the friend. For example, if the messenger management unit 223 provides the first user with a friend list, and the friend of the first user includes the second user, the friend list includes the bond information between the first user and the second user.

According to one embodiment, the panel included in the buddy list may include a display element that can represent the bond information with each user. The display element provides information about bond information that exists between a friend and a friend. For example, the display element may include one or more icons. These display elements are relative and can be displayed only in relation to individual friends included in the friend list, and can be prevented from being exposed to other users. For example, the display element only provides the bond information between the person who requested the friend list and the friend included in the friend list, so that the bond information between the other persons may not be retrieved.

According to one example, the display element may include an icon that provides information in the form of text directly to the user by displaying text therein. For example, the amount of the bond can be directly displayed inside the icon.

According to another example, the display element may include an icon that provides information visually in accordance with predetermined rules. For example, the icon may visually indicate only the presence or absence of a bond. For example, the display element may include a predetermined icon that is displayed only when the bond information with the user exists. The predetermined icon may be a color, a shape, a shape, a point, a flag, and the like. According to the present example, a specific icon may be displayed only on a panel of a user in which there is information on bonds of the plurality of panels listed in the friend list. The user can see the list of friends provided by the messenger service, and intuitively and quickly check which user I am in bond with.

According to one embodiment, the icons included in the display element may be displayed in one or more states depending on the state of the bond. The icons included in the display elements can be displayed in different colors depending on the status of the bonds. For example, the icon may be displayed in a first color if the bond to which the creditor is present, and a second color other than the first color if the bond to which the debtor is present is present. Icons can be displayed as many as the number corresponding to the number of bonds.

According to one example, the display element includes as many icons as the number of bonds, and each icon can display the amount of each bond. According to another example, the indicator element may include one icon indicating the sum of the amounts of each bond. In this case, the case in which the amount of the debt is larger and the case in which the amount of the bond is larger can be distinguished and displayed by using the icon display state (color, etc.). According to another example, the indicator element may include one icon indicating the sum of the amounts of the bonds for which the user is the creditor, and another icon indicating the sum of the amounts of the bonds for which the user is the debtor.

According to one example, the messenger management unit 223 can display the display element in the friend list only with respect to the bond that I am the debtor. Optionally, the messenger management unit 223 can display the display element in the friend list only with respect to the creditor who is the creditor.

Alternatively, the messenger management unit 223 may display only the buddies whose display elements are displayed in the buddy list as a list. For example, you can display only a list of friends who are in bond with you, or you can only show a list of friends who are in debt with you.

According to one example, the display element may be displayed superimposed with other information displayed on the panel. For example, the display element may be displayed in a specific figure at a specific position based on the user's profile image. According to another example, the display element may be displayed as a frame, photo effect, or the like, which is superimposed on the user's profile image.

2B is a block diagram schematically illustrating a terminal control apparatus 200 according to an embodiment of the present invention.

The terminal control apparatus 200 may be provided on the user terminal 20 side.

Referring to FIG. 2B, the terminal control apparatus 200 includes a processor 23. The processor 23 includes a service application execution unit 231 and a display control unit 232. [

In FIG. 2B, only the processor is shown in order to prevent the characteristics of the present embodiment to be described below from being blurred, and only components related to the present embodiment are shown inside the processor. Therefore, other general-purpose components other than the components shown in FIG. 2B may be further included in the terminal control device 200, for example, a configuration for communication, a configuration for input / output, a memory, and the like.

The service application execution unit 231 executes a service application stored in a memory or the like, and can control data processing related to the service application. The user terminal 20 may include a display unit (not shown) for displaying a screen, and the display control unit 232 controls display of the display unit.

FIG. 3A is a flowchart illustrating a remittance service and a method for providing a bond management service in accordance with an embodiment of the present invention.

The flowchart shown in FIG. 3A includes the steps performed between the first user terminal 21, the server 10, and the second user terminal 22. Therefore, the description of the flowchart shown in FIG. 3A will be made with reference to the components of the user terminal 20 and the server 10 shown in FIGS. 1 and 2B. FIG. 3A is a flowchart showing an example of a method in which the server 10 performs the remittance and the reimbursement processing of the corresponding creditor information when the first user remits the second user.

In step 31, the first user terminal 21 sends a remittance command to the server 10 from the first user account to the second user account. The remittance command may include sender account information, receiver account information, and remittance amount information.

In step 32, the remitting unit 221 of the server 10 performs a remittance process corresponding to the remittance command. In detail, the remitter 221 remits the amount to be remitted from the first user account to the second user account.

In one embodiment, the remittance process 32 by the remittance unit 221 may include transferring money from the account of the first user to the account of the second user. Where the account can include a real financial account and / or a virtual account on cyber, and the money can include real money and / or virtual money.

In another embodiment, the remittance process 32 according to the remitting unit 221 includes the steps of: transferring from the account of the first user to the virtual account of the first user, And a third step of remitting the account of the second user from the virtual account of the second user to the account of the second user, and a multi-step remittance process including at least one of the steps. Alternatively, such a multi-step transfer process may include a transfer process through a plurality of intermediate transfer accounts other than the above-described transfer process.

In step 33, the bond management unit 222 of the server 10 inquires the bond DB 212 for the bond information corresponding to the remittance processed in step 32. In detail, at step 33, the bond management unit 222 inquires whether the first user is designated as the debtor and the second user has the creditor information designated as the creditor. The bond management unit 222 can select reimbursement target bond information from the inquired bond information. The bond management unit 222 can select reimbursement bond information in consideration of the information included in the remittance command received in step 31 or information related to the remittance processed in step 32. [

In step 34, the server 10 may transmit a reimbursement approval request for the remittance details processed in step 32 and reimbursement approval information selected in step 33 to the second user terminal 22. Step 34 may be performed by the bond management unit 222. [ However, if the data provided in step 34 is provided through a messenger according to an embodiment of the present invention, in step 34, the creditor management part 222 generates a message including the data to be provided, and the messenger management part 223 generates Message to the second user terminal 22 via the messenger.

At step 35, the second user can confirm the information received at step 34, and the second user terminal 22 can transmit the revalidation acknowledgment to the server 10. [ For example, the second user can check whether the details sent to him / her and the to-be-redeemed bond information match each other, and can approve the agreement if he agrees to repay the corresponding bond information.

In step 36, the server 10 can update the bond information stored in the bond DB as the corresponding bond information is reimbursed. Here, the update of the bond information may be at least one of storing the reimbursement fact for the bond information, reducing the amount of the bond, deactivating the bond information, and deleting the bond information. In one embodiment, the bond management unit 222 determines, based on one or more conditions, that the amount of the remittance is less than the actual remittance amount, The target bond information can be selected. For example, the bond management unit 222 can select the bond information having the same bond amount as the remittance amount. The bond management unit 222 can select the bond information having a bond amount smaller than the remittance amount. The bond management unit 222 can preferentially select the bond information having a high interest rate. The bond management unit 222 can select a plurality of bond information, and in this case, the total sum of bond amounts of a plurality of bond information can be selected to be equal to the remittance amount. For example, if the remittance amount is 10,000 won, and the first user who is the debtor and the second user is the creditor exists in the first bond due to the bond amount of 3000 and the second bond due to 7000, the bond management part 222 The first bond and the second bond can be selected as reimbursable bonds.

According to one embodiment, in step 33, the bond management unit 222 may select the old receivable information preferentially as the reimbursable receivable information in consideration of the receipt creation date. The bond management unit 222 may select one or more bond information as a reimbursement target according to the priority order and may not select the bond information any more when the total sum of the bond amounts of the selected bond information exceeds the remittance amount. For example, the bond management unit 222 selects the redemption target bond information one by one according to the priority order, compares the total sum of the bond amounts of the selected bond information with the remittance amount, and if the total sum of the bond amounts is less than the remittance amount, The process of selecting another target bond information can be repeatedly performed. According to this, when the total amount of the bonds exceeds the remittance amount, the bond management unit 222 does not further select the reimbursable bond information, and proceeds to the next step.

The priority of such reimbursement may be determined by the user in advance.

According to one embodiment, the total sum of bond amounts of the selected plurality of bond information may be greater than the remittance amount. In this case, in step 36, the bond management unit 333 may partially redeem some of the bond information as a part of the amount thereof. That is, only a part of the bond amount can be reduced for at least some of the bond information.

For example, assume that the remittance amount in Step 33 is 50,000 KRW, and the first user is a debtor and the second user is a creditor, as shown in Table 1 below.

Bond identification no. date Price One 2017/6/1 20,000 2 2017/7/1 20,000 3 2017/8/1 20,000 ... ... ...

In this example, the bond management unit 222 may sequentially select the first bond, the second bond, and the third bond as reimbursable bonds. The total bond amount of the selected bond is 60,000 won, so it exceeds 50,000 won. If the first bond, the second bond, and the third bond are finally approved by the first user and / or the second user as the reimbursable bond, at step 36, the bond management unit 222 transmits the first bond, the second bond, The third bond can be repaid. In step 36, the bond management unit 222 can select a bond to be redeemed on the same basis as when a plurality of bonds are redeemed, on the same basis as when the redeemable bond is selected. For example, you can preferentially repay old bonds with a date.

For example, when the bond management unit 222 repayment of the first bond, the second bond, and the third bond with the remittance of 50,000 won, the bond management unit 222 can preferentially repay the oldest bond have.

According to one example, in step 36, the bond amount of the bond information updated by the bond management unit 222 may not match the remittance amount. In this case, the bond management unit 222 may update the bond information by reducing the smaller of the bond amount and the remittance amount from the bond amount.

For example, when the bond manager 222 redeems the first bond, the bond manager 222 reduces the smaller of the bond amount (20,000) and the remittance amount (50,000) (20,000) from the first bond, (20,000) and the remaining amount (30,000), whichever is the smaller amount (20,000), is deducted from the amount of the second bond, so that the second bond is fully redeemed (3), the amount of the bond (20,000) and the amount of remittance (10,000), whichever is the smaller of the amount of the bond (10,000) have. The third bond can be partially repaid (10,000) of the total bond amount (20,000), and the bond amount can be updated to 10,000 won.

In this example, when the bond management unit 222 selects the redeemable bond or performs the redeem processing, it is described that the date of the bond is given a higher priority in the oldest order, but the criterion of the priority is not limited thereto.

According to one embodiment, at step 33, the bond management unit 222 may select reimbursement target bond information according to the user's selection. For example, the user can select at least one creditor to be redeemed through the first user terminal 21 in advance, and then execute the transfer command 31 for the amount corresponding to the amount. At this time, the remittance amount may be the sum of the bonds subject to reimbursement, but is not limited thereto, and may be less than or more than the sum of the bonds subject to reimbursement. In this case, the reordering order can be determined according to the priority reordering order described above.

FIG. 3B is an example of a screen in which the information received in step 34 of FIG. 3A is displayed on the second user terminal 22.

FIG. 3B is an example of a screen in which information is provided in the form of a message in the messenger service, and the information is displayed through a messenger.

3B, the information provided from the server 10 may be displayed as a message 302 in the dialog window 301 between the first user and the second user. In detail, the information provided from the server 10 may be displayed in the dialog window 301 in the form of a message 302 transmitted by the first user to the second user. In the example of FIG. 3B, the message 302 includes the remittance history ("10,000 won has been transferred from XXX") and reimbursement bond information 303. If the second user selects agreement 304, the process proceeds to step 35 of FIG. If the second user selects rejection 305, the process does not proceed to step 35 of FIG. 3A and the process may end. The rejection 305 icon may not be displayed.

4A is a flowchart illustrating a remittance service and a method for providing a bond management service in accordance with another embodiment of the present invention. In detail, Fig. 4A shows an example in which the flow chart shown in Fig. 3A further includes steps 331 to 332. Fig.

In FIG. 4A, steps 31 to 33 and steps 34 to 36 may be similarly applied to the description of FIG. 3A.

The bond management unit 222 of the server 10 at step 331 may provide the final selection request for settlement of the bond information selected at step 33 to the first user terminal 21 and provide the bond information selected at step 33 . In step 332, the first user terminal 21 confirms the receipt information received in step 331, and transmits the final selection of the bond information to be reimbursed to the server 10 by linking the transfer request in step 32.

According to one embodiment, steps 34 to 35 in Fig. 4A may be omitted. In other words, since the debtor has the option of reimbursing the debts prior to the debtor, he / she can select the debt to be reimbursed from the debtor and not require approval from the creditor. In this case, when the bond management unit 222 receives the final selection of the bond information from the first user at step 332, the process immediately proceeds to step 36 where the bond management unit 222 updates the corresponding bond information in the bond DB 212 to process the bond have.

By performing the steps 331 and 332 in this way, it is possible to carry out the reimbursement process in accordance with the intention of the first user who is the sender.

According to one embodiment of the present invention, at step 33, the bond management unit 222 may select more than one bond information. The plurality of bond information thus selected may be provided as a candidate for reimbursement target bond information to the first user in step 331. In step 332, the first user may transmit the reimbursement target bond information desired by the user among the plurality of bond information provided in step 331 You can choose directly.

According to one embodiment, the bond management unit 222 may provide all the bond information in which the first user is the debtor and the second user is the creditor to the first user terminal 21 as candidates for the reimbursable bond information. In this case, the first user terminal 21 can directly select a bond to be repaid.

FIG. 4B is an example of a screen displayed on the first user terminal 21 for final selection of a settlement target bond.

The bond management unit 222 of the server 10 may provide the first user terminal 21 with a message indicating that the remittance has been completed and reimbursement bond information to the first user terminal 21, And can be displayed on the screen of the terminal 21.

According to one embodiment, the first user terminal 21 may display the information received from the server 10 in the pop-up window 401 in step 331 of FIG. 4A. In Fig. 4B, a message indicating that the remittance has been completed and reimbursement target bond information 402 are displayed in the pop-up window 401. Fig. If the first user selects the agreement 403, the process proceeds to step 332 of FIG. 4A, and a subsequent procedure for approving the second user for the corresponding bond may proceed. If the first user selects rejection 404, the process does not proceed to step 332 of FIG. 4A and the process may end.

FIG. 4C shows another example of the screen displayed on the first user terminal 21 for the final selection of the settlement target bond.

The bond management unit 222 of the server 10 may provide the first user terminal 21 with a message indicating that the remittance has been completed and a candidate list of reimbursable bond information, And may be displayed on the screen of the first user terminal 21. [ According to one embodiment, the first user terminal 21 can display the information received from the server 10 in the pop-up window 411 in step 331 of FIG. 4A.

According to one embodiment, the bond management unit 222 may provide a candidate list including one or more candidates of reimbursable bond information. Each candidate may contain more than one bond information. The total amount of bonds of each candidate can be matched with the remittance amount.

Referring to FIG. 4C, a candidate list 412 provided from the bond management unit 222 is displayed. The candidate list 412 may include a first candidate 413 and a second candidate 414. Each candidate may consist of one or more bonds. In the example of FIG. 4C, the first candidate 413 includes one bond, and the second candidate 414 includes two bonds. In this example, the remittance amount may be 10,000 won, the total amount of the bond amount of the first candidate 413 is 10,000 won, and the total amount of the bond amount of the second candidate 414 is 4,000 + 6,000 = 10,000.

The first user may select the option 415 of the first candidate 413 or the second candidate 414 and then click the selection 416 to proceed to step 332 of FIG. In the example of FIG. 4C, since the second candidate 414 has been selected, if the first user clicks the selection 416, the process proceeds to step 332 of FIG. 4A and the two pieces of bond information included in the second candidate 414 are re- Information indicating that the bond information has been finally selected is transmitted to the server 10, and subsequent steps are performed. If the first user clicks cancellation 417, it does not proceed to step 332 of FIG. 4A and the process ends.

4D is another example of the screen displayed on the first user terminal 21 for the final selection of the settlement target bond.

According to an embodiment of the present invention, the bond management unit 222 may provide the first user terminal 21 with a list of all the bond information in which the first user is the debtor and the second user is the creditor. In this case, the first user can select one or more credits to be reimbursed. In the example of FIG. 4D, a pop-up window 411 is shown that displays a list 412 that includes a first candidate 413, a second candidate 414, and a third candidate 418.

4D, the first user may select the option 415 of the second candidate 414 and the third candidate 418, and then click the selection 416 to proceed to step 332 of FIG. 4A.

5A is a flowchart illustrating a messenger service according to an exemplary embodiment of the present invention.

The flowchart shown in FIG. 5A includes the steps performed between the first user terminal 21 and the server 10. Therefore, the description of the flowchart shown in FIG. 5A will be made with reference to the components of the user terminal 20 and the server 10 shown in FIGS. 1 and 2B.

In step 51, the first user terminal 21 requests the friend list from the server 10. The friend list request transmitted in step 51 includes the account information of the first user.

In step 52, the messenger management unit 223 of the server 10 refers to the first user account information included in the friend list request received in step 51, and sends the other user specified as the friend relationship with the first user to the account DB 211 ). In step 52, the messenger management unit 223 inquires the creditor DB 212 for the creditor information of the first user. In one embodiment, the messenger management unit 223 can inquire the bond information, which is the first user, within the scope of the bonds stored in the bond DB 212, for example, the bonds having an amount of bonds larger than zero. Accordingly, the bonds whose liquidation has been completed may not be retrieved.

In step 53, the messenger management unit 223 provides the friend information and the receipt information, which are inquired in step 52, to the first user terminal 21. [ The bond information includes bond information existing between the first user and the friend. The messenger management unit 223 can provide friend information (name, picture, status message, etc.) for each of a plurality of friends, and can provide bond information corresponding to each friend.

In step 54, the first user terminal 21 displays the friend list in accordance with the friend information and the receipt information received in step 53. The friend list includes a panel corresponding to each of the friends included in the friend list, and each panel displays information of each friend. The panel may include indicator elements for providing the bond information. In this manner, the first user terminal 21 can display the friend information and the bond information received in step 53 in association with each other on one screen. Linking the friend information and the bond information may be to list the friend information and display the bond information associated with the friend together with the corresponding friend information. The bond information associated with a friend may be the bond information that each friend is designated as a creditor or a debtor.

According to one example, in step 54, the service application execution unit 231 of the first user terminal 21 may directly configure the friend list screen according to the friend information and the receipt information received in step 53, and the display control unit 232 Can display the configured screen on the display unit.

According to another example, in step 53, the messenger management unit 223 may provide a friend list screen displaying friend information and bond information, and in step 54, the display control unit 232 displays the friend list screen received in step 53, Can be displayed.

5B is an example of a friend list screen displayed on the user terminal 20. [

Referring to FIG. 5B, the friend list screen can display and display the panels 510 for displaying information of friends. 5B shows a first panel 511 corresponding to friend 1, a second panel 512 corresponding to friend 2, a third panel 513 corresponding to friend 3, and a fifth panel 515 corresponding to friend 5, Is displayed.

In the example of FIG. 5B, a photograph 521 of the user, a name 522, and a status message 523 are displayed on the panel 510. On the other hand, in the example of FIG. 5B, unlike the other panels, the first panel 511 is further provided with a display element 524 for displaying bond-related information. In one embodiment of the present invention, the indication of the status message 523 may be omitted.

The screen of FIG. 5B is a friend list screen of the first user displayed on the first user terminal 21. FIG. The display element 524 may be displayed on a panel of a user having a bond relationship with the first user. As described above, the friend list provided according to the embodiment of the present invention can display the bond information with the friend together with the friend information. Here, the user having a bond relationship with the first user may mean a debtor of the bond in which the first user is the creditor, or a creditor of the bond in which the first user is the debtor.

The indicator element 524 may indicate the amount of the bond. The indicator element 524 may indicate that a bond exists between the first user and the friend 1 and that the bond amount is 5000 won.

According to one embodiment, the user may select display element 524 to request functionality associated with the bond. For example, a notification message may be sent to the friend 1 (AAA), or a remittance command may be transmitted to the server 10 for reimbursement of the amount of the bond. According to one example, when the display element 524 is selected, a message automatically generated using the bond information according to a predetermined rule may be transmitted to the friend 1 (AAA).

FIG. 5C is an example of a screen displayed when the display element 524 is selected in the screen of FIG. 5B.

According to one embodiment, other functions may be provided when the display element 524 is selected, depending on whether the first user is a creditor or a debtor. For example, if the first user is the creditor of the bond displayed in the display element 524, a notification may be sent to the friend 1 who is the debtor when the first user selects the display element 524. On the other hand, if the first user is the debtor of the bond displayed in the indicator element 524, the remittance function may be provided. For example, when the first user selects the display element 524, an extension window 530 as shown in FIG. 5C is displayed, and an icon 531 for remitting the extension window 530 may be displayed . When the first user selects the remittance icon (531), a remittance command may be transmitted to the server (10).

At this time, the remittance command may include the bond information corresponding to the bond displayed on the display element 524. [ The remitting unit 221 of the server 10 receives the remittance command including the remittance information from the first user and sends remittance of the amount of the remittance to the account of the friend 1 designated as the creditor of the remittance information in the account of the first user Can be processed. After the transfer is processed, the bond management unit 222 can update the bond information stored in the bond DB 212 that the bond has been redeemed. The bond management unit 222 may request the approval of the friend 1 as the creditor for the reimbursement processing of the bond information included in the remittance command and may update the bond information after the approval of the friend 1 is received .

According to an example, the first user may specify remittance information, and then input a remittance amount to transmit the remittance command to the server 10. [ In this case, the remittance order may include the bond information and remittance amount. Remittance may be equal to, but not limited to, the amount of the bond, and may be less than or greater than the amount of the bond. The remitting unit 221 of the server 10 can perform a process of remitting the remittance amount included in the remittance order to the account of the friend 1 designated as the creditor of the remittance information included in the remittance order in the account of the first user . After the transfer is processed, the bond management unit 222 may update the bond information stored in the bond DB 212 by reducing the remittance amount from the bond amount of the bond information included in the remittance command. If the remittance exceeds the amount of the bond, the bond may be deemed to have been fully repaid.

In this example as well, the receivable management unit 222 may request approval of the friend 1 as the creditor for the reimbursement processing of the receipt information included in the remittance command before the receipt of the bond information update, and update the receipt information after receiving the approval of the friend 1 .

As in the above-described embodiments, when the remittance command includes the bond information, the bond management unit 222 can select the settlement information included in the remittance command as reimbursement target bond information, The process of finally selecting the target bond information may be omitted.

FIG. 5D is an example of a screen in which a list of bonds is displayed on the first user terminal 21. FIG.

According to one embodiment, when the first user transmits the remittance command to the server 10, by designating the remittance target information, the remittance command including the remittance information can be transmitted to the server 10. [ FIG. 5C shows an example in which the first user specifies the bond information. However, the present invention is not limited thereto.

For example, the first user may request the server 10 for a list of the bond information associated with the first user, and the server 10 may send a list of bond information associated with the first user to the first user terminal 21 . The first user terminal 21 may display a list of the bond information associated with the first user, as shown in FIG. 5D.

Referring to FIG. 5D, a list of bonds including the first bond 541, the second bond 542, and the third bond 543 is shown. The first user can select one or more specific bond information using the option 544 button and click on the remittance 545 icon to transmit the remittance command including the selected bond information to the server 10. [

However, the GUI for specifying the bond information and transmitting the remittance command is not limited to that shown in the drawings. For example, if one of the bonds is selected on the screen of FIG. 5D, the extended window providing the remittance function can be displayed as in the case of selecting the display element 524 in the above-described embodiments, and the remittance function provided in the extended window To select a remittance command.

The bond information associated with the first user may be a bond in which the first user is a debtor, a bond in which the first user is a creditor, or a bond in which the first user is a debtor or creditor.

FIG. 6 is a flowchart illustrating a method of generating bond information according to an embodiment.

Referring to FIG. 6, in step 61, the first user terminal 21 transmits a bond creation request to the server 10. The bond creation request includes debtor information and benefit information. The bond creation request may further include creditor information, i.e., its own information.

In step 62, the bond management unit 222 of the server 10 refers to the debtor information included in the bond creation request received in step 61, and transmits a request for consent for generating the bond to the second user terminal 22 corresponding to the debtor send. The consent request basically includes creditor information and benefit information, and may further include the debtor information.

At step 63, the second user terminal 22 sends a consent to the bond creation.

In step 64, the bond management unit 222 of the server 10 generates the bond information and stores it in the receipt DB 212.

Meanwhile, FIG. 6 shows an example in which the creditor requests the bond creation and the debtor agrees, but the present embodiment can be reversed. For example, a debtor may request to generate a bond and generate bond information with the consent of the creditor.

6, steps 61 and 63 may be performed by the service application execution unit 231 provided in the first user terminal 21 and the second user terminal 22, respectively.

Meanwhile, the bond creation request may correspond to any one of a plurality of types. For example, the bond creation request may correspond to any one of a first type requesting only the generation of a bond, and a second type requesting both a bond creation and a remittance.

If the bond creation request in step 61 is of the second type, the server 10 may generate the bond information in step 64, store it in the bond DB 212, and perform the remittance corresponding to the bond creation request. The remittance corresponding to the bond creation request may be to remit the amount corresponding to the payment information from the account corresponding to the creditor information included in the bond creation request to the account corresponding to the debtor information.

FIG. 6A is an example of a screen for requesting a bond creation according to an embodiment.

According to one embodiment, when the first panel 511 of AAA displayed on the friend list is selected, the terminal control apparatus 200 can display the detailed page 611 corresponding to the selected friend. Although the detail page 611 is shown as a pop-up form, it may be displayed on the entire screen to cover the entire existing friend list screen, or may be displayed on a part of the existing friend list screen.

The detail page 611 displays personal information including the photographs and names of the selected friends, and function icons. As an example of a function icon, an icon 612 that provides a 1: 1 chat function with a selected friend and an icon 613 that provides a bond creation function are shown. On the other hand, the icon 613 shown in FIG. 6A provides a function of generating a second type of request that requests both bond creation and transfer, so that the text " lend money " is displayed on the icon 613 can see.

6B is an example of a screen displayed when the icon 613 is selected on the screen of FIG. 6A. Referring to FIG. 6B, the terminal control apparatus 200 may display an information input window 621 for receiving information related to the bond creation function corresponding to the selection of the icon 613. The information input window 621 may provide an area for inputting money. If the first user directly inputs the amount and selects the confirmation 622, the inputted amount information, the first user information, the second user information (in this example, the second user who is to receive money is the counterpart AAA A bond creation request may be sent to the server 10. The user can cancel the display of the information input window 621 by selecting the cancel 623.

On the other hand, after the confirmation 632 is selected, an authentication procedure for using the transmission request of the bond creation request may be provided. For example, a procedure for requesting the user's personal authentication information (e.g., biometric information, password, etc.) may be provided, and the personal authentication information is transmitted to the server 10 together with the bond creation request, . ≪ / RTI > However, the personal authentication information does not necessarily have to be transmitted simultaneously with the bond creation request, and the transmission of the individual authentication information and the bond creation request may be temporally separated. For example, after the personal authentication information is first transmitted to the server 10 and the first user is authenticated, a bond creation request may be transmitted to the server 10.

The display method of the information input window 621 is not limited to the pop-up method as shown in Fig. 6B.

Meanwhile, the service providing system according to an embodiment of the present invention associates the bond information management service with the remittance service. In response to the bond creation request, the bond information is generated and stored in the bond DB, And the money transfer service. For example, the server 10 having received the bond creation request transmits a consent request to the terminal of the counterpart user, receives a consent from the counterpart user, generates a bond corresponding to the bond creation request, and stores the bond in the bond DB And can perform remittance from the first user to the second user.

According to the present embodiment, the user can request bond creation and transfer at the same time with one request.

6C is a flowchart illustrating a method of generating bond information according to an embodiment.

Referring to FIG. 6C, in step 631, the first user terminal 21 transmits a remittance command to the server 10. In step 632, the server 10 processes the remittance. With respect to the remittance command and remittance processing, the remittance-related embodiments described above with reference to Figs. 3A and 4A can be applied.

In step 633, after the transfer is completed, the first user terminal 21 can transmit a request for generating a bond to the server 10 based on the remittance history. At this time, the bond creation request can replace the debtor information and benefit information by including remittance information. The remittance information may directly include the receiver information and the remittance amount information but may include only the remittance identification information. The server 10 may inquire the remittance details corresponding to the remittance identification information, .

In step 634, the bond management unit 222 of the server 10 refers to the receiver information obtained by referring to the bond creation request received in step 633, and notifies the second user terminal 22 corresponding to the receiver to the second user To the borrower as a borrower. The consent request basically includes creditor (same as the sender in this example) information and benefit information (same as remittance amount in this example), and may further include information of the debtor (same as the receiver in this example).

At step 635, the second user terminal 22 sends a consent to the bond creation.

In step 636, the bond management unit 222 of the server 10 generates the bond information and stores it in the bond DB 212. [ The generated bond information may include information of the first user as the creditor information, information of the second user as the debtor information, and remittance amount information of the step 632 as the payment information.

On the other hand, steps 634 and 635 may be omitted.

6C, steps 631, 633, 634 and 635 may be performed by the service application execution unit 231 provided in the first user terminal 21 and the second user terminal 22, respectively.

In this example, the bond creation request is a first type that requests only the creation of a bond.

FIG. 6D is an example of a screen for requesting remittance according to an embodiment.

According to one embodiment, when the first panel 511 of AAA displayed on the friend list is selected, the terminal control apparatus 200 can display the detailed page 611 corresponding to the selected friend.

On the other hand, the function icon displayed on the detail page 611 may include a remittance icon 614.

FIG. 6E is an example of a screen displayed when the icon 614 is selected on the screen of FIG. 6C. 6D, the terminal control apparatus 200 may display an information input window 641 for receiving information related to remittance in response to the selection of the icon 614. The information input window 641 may provide an area for inputting an amount. If the first user directly inputs the amount and selects the confirmation (642), the inputted amount information, the first user information, the second user information (in this example, the second user who is to receive the money is AAA . A remittance request including the information of the remittance request may be transmitted to the server 10.

On the other hand, after the confirmation 642 is selected, an authentication procedure for using the remittance function may be provided. For example, a procedure for requesting personal authentication information (e.g., biometric information, password, etc.) of the user may be provided, and the personal authentication information may be transmitted to the server 10 together with the remittance request to authenticate the first user Can be used.

The display method of the information input window 641 is not limited to the pop-up method as shown in Fig. 6E. When the cancellation 643 is selected, the display of the information input window 641 is ended.

FIG. 6F is an example of a screen displayed on the first user terminal 21 after the money is inputted and the confirmation 542 is selected on the screen of FIG. 6E and the remittance is completed.

FIG. 6F is an example of a screen displayed through a messenger to allow a request for creating a bond. 6F, the information provided from the server 10 may be displayed as a message 652 in the dialog window 651 between the first user and the second user. In detail, the information provided from the server 10 may be displayed in the dialog window 651 in the form of a message 652 sent by the first user to the second user. In the example of Fig. 6f, the message 652 includes a transfer history ("10,000 won has been transferred to AAA") and a message ("Do you want to generate a bond") to guide the bond creation request.

If the first user selects agreement 653, the bond creation request described in step 633 of FIG. 6C may be transmitted to the server 10. If the first user selects rejection 654, the process does not proceed to step 633 of FIG. 6C and the process may end. The rejection 654 icon may not be displayed.

On the other hand, the message 652 shown in FIG. 6F can be divided into a plurality of messages, an example of which is shown in FIG. 6G.

Referring to FIG. 6G, the transfer details of the information provided from the server 10 may be included in the first message 6521 and displayed. Thereafter, a message 6522 may be displayed to guide the bond creation request.

If the agreement 653 is selected on the screen of FIG. 6F or FIG. 6G, the first user terminal 20 can display an information input window 661 for further inputting the bond information as shown in FIG. 6H .

The information input window 661 includes an area for receiving a bond name. The information input window 661 may display information corresponding to the transfer details. For example, the remittance amount may be displayed.

When the first user inputs the name of the bond and selects the confirmation 662, the bond creation request described in step 633 of FIG. 6C is transmitted to the server 10, and the bond creation request includes the bond name . When the cancellation 663 is selected, the display of the information input window 661 is ended, and the process does not proceed to Step 633.

In the embodiments of the present invention, the service providing system provides the bond information management service and the remittance service in connection with each other, so that the user does not need to directly match the remittance details and the bond information and manually manage them, Bond information management is possible. Also, since the messenger service is provided in a more coordinated manner, data can be effectively transmitted and received based on the messenger service, and various information can be effectively provided to the user in the messenger service.

Meanwhile, the methods according to embodiments of the present invention can be implemented in a general-purpose digital computer that can be created as a program that can be executed by a computer and operates the program using a computer-readable recording medium. The computer-readable recording medium includes a storage medium such as a magnetic storage medium (e.g., ROM, floppy disk, hard disk, etc.), optical reading medium (e.g., CD ROM, As another example of the medium, a recording medium or a storage medium managed by a site or a server that supplies or distributes an application store or various other software to distribute the application may be mentioned.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is to be understood that the invention is not limited to the exemplary embodiments, and that various changes and modifications may be made therein without departing from the scope of the present invention. Accordingly, the true scope of the present invention should be determined by the technical idea of the appended claims.

10: Server
20: User terminal
30: Network
100: Service providing device
210: Storage device
211: Account DB
212: Bond DB
220: Processor
221:
222: Creditor Management Department
223: messenger management section
220:
230: Processor
231: Service application execution part
232:

Claims (1)

A bond DB for storing bond information between users;
A remitting unit for receiving a remittance instruction of the first amount from the first user terminal to the second user account and remitting the remittance; And
Receiving creditor creation request corresponding to the remittance processing, receiving creditor information including information of the first user in response to receipt of the bond creation request, debtor information including information of the second user, And a bond management unit for generating bond information including benefit information including amount information and storing the generated bond information in the bond DB
How to create bonds linked to remittances.

Images