Method for providing group-based payment to user of messenger service, server, and user terminal

Abstract

Provided are a method, a server, and a user terminal for providing a group-based payment to a user of a messenger service.SOLUTION: A method for providing a group-based settlement to a user of a messenger service according to the present invention includes a step S210 of identifying a group consisting of a plurality of users of the messenger service, a step S220 of acquiring information on a group-based settlement of the at least one general user from a device of a representative user, a step S240 of receiving settlement request information of the group-based settlement from a device of a first general user, and a step S250 of providing a settlement-related message to the device of the representative user through the messenger service based on the authority information of the first general user.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present invention relates to a method, a server and a user terminal for providing group-based payment to users of a messenger service. [Background technology]

[0002] With the development of mobile communication technology and the widespread use of mobile smart devices, messenger services that provide communication functions through instant messages such as text, images, and voice have become widespread. As a result, communication between users that was previously conducted via voice calls and short message services (SMS) has largely been replaced by messenger services.

[0003] These messenger services provide a function that connects users with each other through friend relationships. The messenger service provides a friend list of other users who are friends with the user. In addition, the messenger service may provide services to friends that are not available to non-friends (such as sending gifts or money).

[0004] As a result, services have recently emerged that allow users to manage people who correspond to family, friends, romantic partners, etc. as a group and provide differentiated functions for the group. As such group-based services have become more popular, there has been an increasing demand for additional new group-based functions. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Republic of Korea Patent No. 10-1568311 (2015.11.05) Summary of the Invention [Problem to be solved by the invention]

[0006] The present invention aims to provide group-based payments to users of messenger services.

[0007] The present invention aims to improve user convenience by approving group-based payments requested by users of a messenger service or applying messages for payments through the messenger service.

[0008] The present invention aims to provide a service that allows a representative user to receive an approval request message through a chat room of a messenger service and enter an approval interaction for a group-based payment approval request, thereby enabling payment to be made in a convenient manner. [Means for solving the problem]

[0009] The method for providing group-based payment to users of a messenger service of the present invention is a method in which a server provides group-based payment to users of a messenger service, and includes the steps of identifying a group consisting of a plurality of users of the messenger service (wherein the group includes a representative user and at least one general user), acquiring authority information for group-based payment of the at least one general user from the terminal of the representative user, receiving payment request information for the group-based payment from the terminal of a first general user, and providing a payment-related message to the terminal of the representative user through the messenger service based on the authority information of the first general user.

[0010] In one embodiment of the present invention, the payment-related message may be provided through a chat room in which the representative user and the first general user participate.

[0011] In one embodiment of the present invention, if the chat room already exists, the payment-related message may be provided through the existing chat room.

[0012] In one embodiment of the present invention, if the authority information of the first general user is such that the group-based payment can be made on the condition that the representative user approves the payment, the payment-related message may include an approval request message for requesting the representative user to approve the payment.

[0013] In one embodiment of the present invention, the approval request message may include an approval interface for the group-based payment requested by the first general user.

[0014] In one embodiment of the present invention, the method may further include the steps of receiving approval information for the approval request message from the representative user's terminal, and providing a payment completion message for the group-based payment of the first general user to at least one of the representative user's terminal and the first general user's terminal.

[0015] In one embodiment of the present invention, the payment completion message may be provided through a chat room other than the approval request message.

[0016] In one embodiment of the present invention, if the authority information of the first general user is that the group-based payment can be made based on the prior approval of the representative user, the payment-related message includes a payment completion message for the group-based payment of the first general user, and the payment completion message can be provided through an information provision chat room that provides information on the payment function.

[0017] In one embodiment of the present invention, the information providing chat room may be a chat room in which the representative user and the server performing the payment function participate.

[0018] In one embodiment of the present invention, the step of acquiring the authority information may include a step of providing the representative user's terminal with information on at least one general user and an authority setting interface capable of setting at least one authority information corresponding to each of the general users, and a step of receiving setting information corresponding to the authority setting interface from the representative user's terminal.

[0019] In one embodiment of the present invention, the authority information may include information regarding the authority of the corresponding general user to make the group-based payment subject to payment approval by the representative user, and information regarding the authority to make the group-based payment based on prior approval by the representative user.

[0020] In one embodiment of the present invention, the authority information may include information on a payment limit and a permitted number of times for the group-based payment for the general user.

[0021] In one embodiment of the present invention, the group further includes an approver, and if the authority information of the first general user is such that the group-based payment is possible on the condition of payment approval from at least one of the representative user and the approvers, the payment-related message includes an approval request message associated with content requesting payment approval from the representative user and at least one of the approvers, and the approval request message can be applied through a chat room in which the representative user, at least one of the approvers, and the first general user participate.

[0022] In one embodiment of the present invention, the group-based payment includes at least one payment method, and the step of receiving the payment request information includes the steps of providing a selection interface for selecting one of the at least one payment method in the group-based payment to the terminal of the first general user, and receiving selection information corresponding to the selection interface from the terminal of the first general user, and the payment-related message may be further generated based on the payment method selected by the first general user.

[0023] A method for providing group-based payment to users of a messenger service of the present invention includes a memory and a processor coupled to the memory and configured to execute instructions stored in the memory, the processor being configured to perform each step of the method. Preferably, the processor is configured to perform the steps of identifying a group consisting of multiple users of the messenger service (wherein the group includes a representative user and at least one general user), acquiring authority information for group-based payment for the at least one general user from a terminal of the representative user, receiving payment request information for the group-based payment from a terminal of a first general user, and providing a payment-related message to the terminal of the representative user through the messenger service based on the authority information of the general user.

[0024] The method for providing group-based payment to users of a messenger service of the present invention is a method for a user terminal to perform group-based payment through a messenger service, and includes the steps of displaying information about a group including a representative user and at least one general user (wherein the user of the user terminal corresponds to the representative user), displaying an authority setting interface capable of setting at least one authority information corresponding to each of the general users, receiving input of setting interaction for the authority setting interface, and displaying a payment-related message generated in response to a first general user's payment request for the group-based payment (wherein the payment-related message is generated as a predetermined type of message based on the authority information of the first general user).

[0025] In one embodiment of the present invention, the payment-related message is displayed through a chat room in which the user and the first general user participate.

[0026] The user terminal for providing group-based payment to users of a messenger service of the present invention includes a memory and a processor coupled to the memory and configured to execute instructions stored in the memory, wherein the processor is configured to perform each step of the method. Preferably, the processor is configured to perform the following steps: displaying information about a group including a representative user and at least one general user (wherein the user of the user terminal corresponds to the representative user), displaying an authority setting interface for setting at least one piece of authority information corresponding to each of the general users, receiving input of a setting interaction for the authority setting interface, and displaying a payment-related message generated in response to a payment request for group-based payment from a first general user (wherein the payment-related message is generated as a predetermined type of message based on the authority information of the first general user). [Effects of the Invention]

[0027] The present invention has the advantage of being able to provide group-based payments to users of messenger services.

[0028] The present invention has an advantage in that it can improve user convenience by providing a message regarding approval or payment of a group-based payment requested by a user of a messenger service through the messenger service.

[0029] The present invention has an advantage that, in response to a request for approval of a group-based payment, a representative user can receive an approval request message through a chat room of a messenger service and input approval information, thereby enabling payment to be made in a convenient manner. [Brief explanation of the drawings]

[0030] [Figure 1] 1 is a diagram illustrating an example of a network environment according to an embodiment of the present invention. [Figure 2] 1 is a flowchart illustrating a method by which a server of the present invention provides group-based payment to users of a messenger service. [Figure 3] 10 is a flowchart illustrating a specific method for performing step S250 in FIG. 2 when conditional payment authority is granted to the first general user. [Figure 4] 10 is a flowchart illustrating a specific method for performing step S250 of FIG. 2 even when the prepayment authority for the first general user is permitted. [Figure 5] 10 illustrates exemplary screens during a process in which a representative user terminal and a first general user terminal perform group-based payment according to an embodiment of the present invention. [Figure 6] 10 illustrates exemplary screens during a process in which a representative user terminal and a first general user terminal perform group-based payment according to an embodiment of the present invention. [Figure 7]10 illustrates exemplary screens during a process in which a representative user terminal and a first general user terminal perform group-based payment according to an embodiment of the present invention. [Figure 8] 10 illustrates exemplary screens during a process in which a representative user terminal and a first general user terminal perform group-based payment according to an embodiment of the present invention. [Figure 9] 10 illustrates exemplary screens during a process in which a representative user terminal and a first general user terminal perform group-based payment according to an embodiment of the present invention. [Figure 10] 10 illustrates exemplary screens during a process in which a representative user terminal and a first general user terminal perform group-based payment according to an embodiment of the present invention. [Figure 11] 10 illustrates exemplary screens during a process in which a representative user terminal and a first general user terminal perform group-based payment according to an embodiment of the present invention. [Figure 12] 10 illustrates exemplary screens during a process in which a representative user terminal and a first general user terminal perform group-based payment according to an embodiment of the present invention. [Figure 13] 10 illustrates exemplary screens during a process in which a representative user terminal and a first general user terminal perform group-based payment according to an embodiment of the present invention. [Figure 14] 10 illustrates exemplary screens during a process in which a representative user terminal and a first general user terminal perform group-based payment according to an embodiment of the present invention. [Figure 15] 10 is a flowchart illustrating a method for a representative user terminal to perform group-based payment for users of a messenger service according to the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0031] Hereinafter, the embodiments disclosed herein will be described in detail with reference to the accompanying drawings, and the same or similar components will be denoted by the same reference numerals regardless of the drawing numbers, and redundant descriptions thereof will be omitted. Furthermore, in describing the embodiments disclosed herein, if a detailed description of related publicly known technology is deemed to obscure the gist of the embodiments disclosed herein, the detailed description thereof will be omitted.

[0032] Terms including ordinal numbers such as first, second, etc. may be used to describe various components, but the components are not limited by the terms. The terms are used only to distinguish one component from another.

[0033] A singular expression includes a plural expression unless the context clearly dictates otherwise.

[0034] In this application, the steps described may be performed in any order except where a specific causal relationship dictates that the steps be performed in the listed order.

[0035] In this application, the terms "comprise" or "have" and the like are intended to specify the presence of any feature, number, step, operation, component, part, or combination thereof stated in the specification, but should be understood as not precluding the presence or possible addition of one or more other features, numbers, steps, operations, components, parts, or combinations thereof.

[0036] The present invention will now be described with reference to the accompanying drawings.

[0037] FIG. 1 is a diagram illustrating an example of a network environment according to an embodiment of the present invention.

[0038] The network environment according to one embodiment of the present invention shown in Fig. 1 may include a server 10 and a user terminal 20. The user terminal may include a representative user terminal 20 and at least one general user terminal. Fig. 1 exemplarily illustrates a first general user terminal 30 and a second general user terminal 40 as general user terminals.

[0039] Hereinafter, for convenience, the representative user's terminal 20 will be referred to as the representative user terminal 20, the general user's terminal will be referred to as the general user terminal, the first general user's terminal 30 will be referred to as the first general user terminal 30, and the second general user's terminal 40 will be referred to as the second general user terminal 40.

[0040] The network is not limited in its communication method and can include not only communication methods that utilize communication networks (for example, mobile communication networks, wired Internet, wireless Internet, and broadcasting networks) but also short-range wireless communication.

[0041] The server 10 may be embodied as a computer device or multiple computers that provide instructions, codes, files, content, services, etc. The server 10 may be a server 10 that can communicate with a user terminal through a network and send and receive information.

[0042] The server 10 may include a processor 11 , a memory 12 and a communication unit 13 .

[0043] The processor 11 controls the overall operation of the memory 12 and the communication unit 13 and can provide a messenger service to the user terminal. The messenger service provides a conversation (chat) function between user terminals through instant messages.

[0044] The memory 12 functions as a storage medium and can store a plurality of application programs run by the server 10, as well as data and instructions for the operation of the server 10. In one embodiment, the memory 12 can store an application associated with a messenger service.

[0045] Such memory 12 may be provided as hardware in the form of various storage devices such as ROM, RAM, flash drive, hard drive, etc., and / or in the form of web storage.

[0046] The communication unit 13 can communicate with the user terminal 30 via a network in a wired or wireless manner.

[0047] The server 10 of the present invention can provide a messenger service for user terminals. Specifically, the server 10 provides a message conversation room (chat room) where users can send and receive messages to each other as a messenger service. Here, messages include text, images, videos, audio, files, contact information, location information, participant voting information, etc.

[0048] Such messenger services allow users to connect with each other through friend relationships. Friendship relationships can be formed between users through a friend request and acceptance, or by fulfilling certain conditions, such as at least one user having the other user's phone number saved. In some cases, messenger services may provide services to users who are not friends, but the types of services they offer may be more limited than those for users who are friends.

[0049] The server 10 can manage users of the messenger service as groups. Specifically, managing users as groups means that the server 10 manages two or more user accounts by assigning them to the same group code according to a certain standard. Groups can be created according to various standards. For example, groups can include family account groups, company account groups, and alumni account groups.

[0050] Here, a family account group refers to a group of two or more users who are related by family relationship. Family relationships can be determined by various criteria, such as direct ascendants, descendants, collateral blood relatives, within four relatives, or within six relatives.

[0051] The server 10 can provide group-based payment to users of a messenger service. The server 10 can identify a group consisting of multiple messenger service users. A group can include a representative user and at least one general user. The server 10 can receive authority setting information for group-based payment of at least one general user from the representative user terminal 20 and set authority information for group-based payment of at least one general user based on the authority setting information. When the server 10 receives payment request information for group-based payment from the first general user terminal 30, it can generate a predetermined type of payment-related message based on the authority information of the first general user and provide it to the representative user terminal 20 through the messenger service.

[0052] Here, group-based payment means that group members (including a representative user and general users) are associated with the group and make payments using pre-registered payment methods. Therefore, using group-based payment, group members can make payments using payment methods registered by other group members. Conditions can be set for group-based payment so that it can be made only to at least some of the group members. The payment method for group-based payment can be the payment method of the representative user, and the representative user can register the payment method on the server 10. Furthermore, group members can share and check the details of payments made by all group members through group-based payment.

[0053] In the following, we have explained that a general user requests and makes a payment on a group basis, but in some cases, a representative user can also request and make a payment on a group basis.

[0054] Here, the representative user is designated as the user who represents the group. The representative user can set the authority information for group-based payments for general users and can decide whether to approve group-based payments requested by general users.

[0055] Here, a general user can be a member of a group other than the representative user. A general user can be granted authority information for group-based payment by the representative user. A general user can request and make a group-based payment using the authority information for group-based payment.

[0056] Here, the authority information may be authority information for group-based payment set for each general user. The authority for group-based payment may be classified into various types. For example, the authority types may include approval-conditional payment authority and pre-approval payment authority.

[0057] Conditional payment authority means that when a general user requests a group-based payment, the group-based payment can be made subject to the representative user's payment approval. Pre-approval payment authority means that the representative user approves the group-based payment of the general user in advance before the general user requests the group-based payment, and the general user can make the group-based payment without the representative user's separate approval. When the representative user pre-approves the group-based payment of the general user, the representative user can limit the conditions such as the payment amount and payment content.

[0058] Here, the payment-related message may be at least one of an approval request message requesting approval for the group-based payment from the representative user, a payment completion message indicating that the group-based payment has been completed, and a payment rejection message indicating that the group-based payment has been rejected. Payment-related messages may be provided through different types of chat rooms depending on their type or content, as will be described in detail below.

[0059] The user terminals 20, 30, 40 may include a communication unit 21, 31, 41, an input unit 22, 32, 42, an output unit 23, 33, 43, a memory 24, 34, 44, and a processor 25, 35, 45.

[0060] The communication units 21, 31, and 41 can communicate with the server 10 or other terminals in a wired or wireless manner.

[0061] The input units 22, 32, and 42 can receive various information through user operations and input actions, and can be a touch screen module, a keyboard, a mouse, a button, a camera, a stylus, a mouse, or the like.

[0062] The user terminals 20, 30, and 40 can receive user interaction inputs through the input units 22, 32, and 42. Interaction means that the user operates the input unit to input information that reflects the user's selection or intention, etc. For example, interactions can include touching a touchscreen, clicking a mouse, typing on a keyboard, inputting sound into a microphone, taking an image with a camera, and recognizing the operation of a motion sensor.

[0063] The output units 23, 33, and 43 may output various information. The output units 23, 33, and 43 may be a display device, a speaker, a vibration generator, a tactile generator, etc. In some cases, the output units 23, 33, and 43 may be a device (e.g., Bluetooth earphones) that is connected to a user terminal via a wired or wireless method (e.g., short-range wireless communication such as Bluetooth®) and receives and outputs a signal.

[0064] The memories 24, 34, and 44 function as storage media and can store a plurality of application programs run on the user terminals 20, 30, and 40, as well as data and instructions for operation of the user terminals 20, 30, and 40. The memories 24, 34, and 44 can be provided as hardware in the form of various storage devices such as ROM, RAM, flash drive, hard drive, etc., and / or in the form of web storage.

[0065] In one embodiment, the memories 24, 34, 44 may store applications associated with messenger services and processing authentication.

[0066] The processors 25, 35, 45 control the overall operation of the communication units 21, 31, 41, the input units 22, 32, 4, the output units 23, 33, 43, and the memories 24, 34, 44, and can execute applications associated with the messenger service.

[0067] The representative user terminal 20 displays information about a group including a representative user and at least one general user, displays an authority setting interface that allows the representative user to set at least one piece of authority information corresponding to each general user, and can receive setting interaction inputs for the authority setting interface from the representative user. When a first general user requests group-based payment, the representative user terminal 20 can display a payment-related message generated in response to the payment request for group-based payment. Here, the payment-related message can be generated as a predetermined type of message based on the authority information of the first general user.

[0068] The general user terminal displays an interface that allows the general user to select group-based payment as one of the payment methods via a network such as the Internet, and receives an interaction input from the general user selecting group-based payment as the payment method, and can request group-based payment from the server 10. The general user terminal can also display a payment-related message generated in response to the payment request for group-based payment. Here, the payment-related message can be generated as a predetermined type of message based on the authority information of the first general user.

[0069] Referring now to FIG. 2, an embodiment of a method for providing group-based payment to users of a messenger service by the server 10 of the present invention will be described.

[0070] FIG. 2 is a flow chart illustrating a method by which the server 10 of the present invention provides group-based payment to users of a messenger service.

[0071] In step S210, the server 10 identifies a group consisting of multiple users of the messenger service. The server 10 can identify a group for a user based on a request from the user of the messenger service or user condition information. A group can include a representative user and at least one general user. For the sake of convenience, the general user will be described below as including a first general user and a second general user. However, the present invention can include a case where there is only one general user, and a case where there are three or more general users.

[0072] In step S220, the server 10 receives authority setting information for group-based payment for at least one general user from the representative user terminal 20.

[0073] The representative user terminal 20 can receive input of authority setting information for group-based payment for general users and provide it to the server 10. Specifically, the representative user terminal 20 can display an authority setting interface that can set at least one piece of authority information corresponding to each general user, and can receive input of setting interactions for the authority setting interface from the representative user. The server 10 can receive authority setting information corresponding to the setting interaction input by the representative user.

[0074] In some cases, the server 10 may additionally request and receive authentication information that can authenticate the representative user along with the authority setting information from the representative user terminal 20. Here, the authentication information may be related to a certificate that can be executed in conjunction with the messenger service of the present invention.

[0075] The authority setting information is information for setting authority information for a general user regarding group-based payment. Specifically, authority information for a general user regarding group-based payment can be set, changed, and / or revoked using the authority setting information.

[0076] The authority conferral for group-based payments of general users may be classified into at least one predetermined type. For example, the types of authority information may include approval-conditional payment authority information, pre-approved payment authority information, etc. The authority setting information may be content on how to set or change at least one of the authority information for each general user.

[0077] In step S230, the server 10 sets the authorization information for group-based payment of at least one general user based on the authorization setting information.

[0078] The server 10 sets the authority information for the group-based payment of the general user based on the authority setting information received in step S220. By setting such authority information, it is possible to determine whether the general user can request the group-based payment in the subsequent steps, and whether approval of the representative user is required to proceed with the group-based payment.

[0079] In step S240, the server 10 receives payment request information for group-based payment from the first general user terminal 30.

[0080] Here, the first general user may be a member who has been granted authority for group-based payment by the representative user. In this case, the first user terminal 30 displays an interface that allows the first general user to select group-based payment as one of payment methods via a network such as the Internet, and may receive an interaction input from the first general user selecting group-based payment as the payment method. The server 10 may respond to this interaction and receive payment request information for group-based payment from the first general user terminal 30.

[0081] In step S250, the server 10 generates a predetermined type of payment-related message based on the authority information of the first general user, and provides it to the representative user terminal 20 through the messenger service.

[0082] The server 10 can generate different types of payment-related messages depending on how the authority information of the first general user is set.

[0083] For example, if the authority information of the first general user indicates that payment authority with approval conditions is permitted, the server 10 may generate an approval request message as a payment-related message. The approval request message may include an approval interface that allows the representative user to approve the group-based payment of the first general user.

[0084] As another example, if the authority information of the first general user indicates that pre-approval payment authority is granted, the server 10 may proceed with the payment immediately based on the pre-approval content without generating the above-mentioned approval request message, and may generate a payment completion message. The payment completion message may include content regarding the group-based payment made by the first general user.

[0085] Specific methods for providing payment-related messages to the representative user terminal 20 according to the above two examples will be described below with additional reference to other drawings.

[0086] Such a payment-related message generated by the server 10 can be provided to the representative user terminal 20 through a messenger service. Specifically, the payment-related message can be provided through a chat room of the messenger service in which at least one of the representative user and the first general user participates.

[0087] As described above, since payment-related messages are provided to the representative user terminal 20 through the messenger service, the representative user can receive payment-related messages through the messenger service, which is a method that the representative user has already used and is familiar with, rather than through a separate application or web page related to group-based payment.

[0088] Hereinafter, with reference to FIG. 3, a method for providing a payment-related message to the representative user terminal 20 through a messenger service when the approval-conditional payment authority for the first general user is granted will be described.

[0089] FIG. 3 is a flowchart illustrating a specific method for performing step S250 in FIG. 2 when conditional payment authority is granted to the first general user.

[0090] If the first general user is granted approval-conditional payment authority, the payment-related message can include a first payment-related message and a second payment-related message. The first payment-related message is an approval request message, and the second result-related message can be either a payment completion message or a payment rejection message, determined depending on whether approval is granted. After the first payment-related message is provided first, the second payment-related message can be determined and provided depending on whether approval is granted by the representative user. The above content will be explained in detail according to each step below.

[0091] In step S301, the server 10 may generate an approval request message as a first payment-related message. The approval request message may include information on the group-based payment requested by the first general user and an approval interface that allows the representative user to approve the group-based payment requested by the first general user.

[0092] In step S302, the server 10 provides the approval request message generated in step S301 to the representative user terminal 20 through a chat room. The chat room can be a chat room in which the representative user and the first general user participate. Such a chat room can be a one-to-one chat room in which only the representative user and the first general user participate, or a group chat room in which other participants participate in addition to the representative user and the first general user.

[0093] There may be cases where a chat room for transmitting an approval request message has already been created and exists. In such cases, the server 10 can transmit the approval request message through the already existing chat room. For example, it is assumed that the approval request message is provided through a one-on-one chat room in which a representative user and a first general user participate, and that a one-on-one chat room already exists because there is a chat history between the representative user and the first general user through a messenger service. In such cases, the server 10 can transmit the approval request message through the already existing one-on-one chat room.

[0094] In this case, the relevant one-on-one chat room can display the chat contents exchanged between the representative user and the first general user through the existing one-on-one chat room. If the representative user and the first general user share the details of the group-based payment requested by the first general user and the need for approval for it through the existing one-on-one chat room, the representative user can easily check the shared contents while remaining in the same chat room without leaving the chat room where the approval request message was sent.

[0095] In addition, in some cases, after an approval request message is sent through the one-to-one chat room, the representative user and the first general user can chat through the one-to-one chat room about the content of the group-based payment requested by the first general user and the need for approval for it. In this case, there is an advantage that the representative user and the first general user can chat with the first general user while staying in the same chat room without leaving the chat room where the approval request message was sent.

[0096] The representative user can decide whether to approve the corresponding group-based payment in response to the approval request message received in step S302. Specifically, the representative user can input the decision result to the terminal through an interaction corresponding to an approval interface or a rejection interface included in and / or linked to the approval request message. Depending on the decision result of the representative user, either step S303 or step S305 can be selectively performed.

[0097] When the representative user inputs an interaction to approve the approval request message, step S303 is performed.

[0098] In step S303, the server 10 receives approval information in response to the approval request message from the representative user terminal 20.

[0099] In some cases, the server 10 may additionally request and receive authentication information that can authenticate the representative user along with the approval information from the representative user terminal 20. Here, the authentication information may relate to a certificate that can be executed in conjunction with the messenger service of the present invention. Since both the approval request message and the authentication information are provided to the representative user through the messenger service, there is an advantage that the representative user can perform various functions for group-based payment at once through the messenger service.

[0100] After confirming the approval information, the server 10 performs the group-based payment requested by the first general user. If the group-based payment requested by the first general user is successfully completed in step S303, the server 10 performs the subsequent step S304.

[0101] In step S304, the server 10 provides a payment completion message for the group-based payment requested by the first general user to at least one of the representative user terminal 20 and the first general user terminal 30. The payment completion message may correspond to a secondary payment-related message.

[0102] The payment completion message may include information on the group-based payment for which the payment has been completed and information that the payment has been successfully completed. In some cases, the payment completion message may further include link information that allows access to the history of existing group-based payments for the corresponding group.

[0103] This payment completion message may be provided through the same chat room as the above-mentioned approval request message, or through another chat room. If the payment completion message is provided through another chat room, the other chat room may not be a chat room between the representative user and the first general user, but may be a chat room in which either the representative user or the first general user and the server 10 performing or managing the group-based payment function participate as speakers. In some cases, this chat room may not be a chat room in which an actual user of the messenger service is the chat partner, but may be a chat room in which the server 10 or a chatbot operated by the server 10 is the chat partner, and may not be a chat room whose main purpose is to exchange conversations between users, but may be a chat room whose main purpose is to receive information from the server 10 or the chatbot.

[0104] If a payment completion message is provided through a chat room in which the representative user and the first general user participate, like an approval request message, the representative user and the first general user can chat about the details of the payment completion through the corresponding chat room.

[0105] If the representative user inputs an interaction to reject the approval in response to the approval request message, step S305 is performed.

[0106] In step S305, the server 10 receives approval refusal information in response to the approval request message from the representative user terminal 20.

[0107] After checking the approval / rejection information, the server 10 stops the group-based payment requested by the first general user without proceeding any further. If the group-based payment requested by the first general user is rejected and stopped in step S305, the server 10 proceeds to step S306.

[0108] In step S306, the server 10 provides a payment rejection message for the group-based payment requested by the first general user to at least one of the representative user terminal 20 and the first general user terminal 30. The payment rejection message may correspond to a secondary payment-related message.

[0109] The payment rejection message may include information about the rejected group-based payment and the reason for the rejection (such as refusal of approval by the representative user). In some cases, the payment rejection message may further include link information that allows access to the history of existing group-based payments for the group.

[0110] This payment rejection message can be provided in the same chat room as the above-mentioned approval request message or in a different chat room in the same manner as the payment completion message is provided. The method for providing the payment rejection message through a chat room is similar to the above-mentioned payment completion message in some respects, so a detailed description will be omitted.

[0111] Hereinafter, with reference to FIG. 4, a method for providing a payment-related message to the representative user terminal 20 through a messenger service when pre-approval payment authority is granted to the first general user will be described.

[0112] FIG. 4 is a flowchart illustrating a specific method for performing step S250 in FIG. 2 when the pre-approved payment authority is granted to the first general user.

[0113] If pre-approved payment authority is granted for the first general user, the payment-related message may be a payment completion message or a payment rejection message depending on whether the group-based payment requested by the first general user meets the conditions of pre-approved payment authority.

[0114] In step S401, the server 10 determines whether the group-based payment requested by the first general user satisfies the pre-approval authority conditions. The representative user can add conditions for the first general user's pre-approval payment while inputting authority setting information for the first general user's group-based payment. For example, the conditions for the pre-approval payment can be a single payment amount limit, a total payment amount limit for a specific period (e.g., one month), a limit on the number of payments in a specific period, and restrictions on payment content.

[0115] In step S401, the server 10 may selectively perform either step S402 or step S403 depending on the determination result.

[0116] If the server 10 determines in step S401 that the group-based payment requested by the first general user satisfies the condition for pre-approval payment authority, step S402 is performed.

[0117] In step S402, the server 10 provides at least one of the representative user terminal 20 and the first general user terminal 30 with a payment completion message for the group-based payment requested by the first general user.

[0118] The content and method of providing the payment completion message in step S402 are substantially the same as those in step S304, and for the sake of convenience, a detailed description of step S402 will be omitted.

[0119] If the server 10 determines in step S401 that the group-based payment requested by the first general user does not satisfy the pre-approval payment authority condition, step S403 or step S301 shown in Fig. 3 is performed. Which step out of step S403 and step S301 is performed may depend on the policy for the service stored in the server 10 or the setting of the representative user terminal 20.

[0120] When step S403 is performed, the server 10 provides at least one of the representative user terminal 20 and the first general user terminal 30 with a payment rejection message for the group-based payment requested by the first general user.

[0121] The payment rejection message may include information about the rejected group-based payment and the reason for the rejection (e.g., not meeting the pre-approved payment authorization conditions). In some cases, the payment rejection message may further include link information that allows access to the history of existing group-based payments for the corresponding group.

[0122] The method of providing the payment rejection message in step S403 is substantially the same as that in step S306. For convenience of explanation, the explanation of step S403 will be omitted.

[0123] Even if it is determined that the group-based payment requested by the first general user terminal does not satisfy the conditions for pre-approval payment authority without performing step S403, the payment may be immediately rejected but approval may be requested from the representative user. In this case, step S301 is performed, and then the subsequent steps (steps S302 to S306) described with reference to FIG. 3 may be performed.

[0124] 5 through 12, examples of how the server 10 described with reference to FIGS. 2 through 4 can provide group-based payments to users of a messenger service will now be described.

[0125] 5 to 12 are exemplary diagrams illustrating screens in the process of the representative user terminal 20 and the first general user terminal 30 performing group-based payment according to an embodiment of the present invention.

[0126] FIG. 5 illustrates a screen in which the representative user terminal 20 receives and displays related information from the server 10 after the server 10 has performed step S210 in FIG.

[0127] Referring to Figure 5, the representative user terminal 20 displays information about a group made up of messenger users. The information about the group may include information about the users who make up the group. Specifically, the representative user terminal 20 may display information about the representative user 510 and information about general users 520 as information about the group. Although not shown in Figure 5, the representative user terminal 20 may also display group-based payment authority information for the members who make up the group together with the information about the group.

[0128] In addition, the representative user terminal 20 can display an interface 530 that can be linked to a page where the group-based payment authority information of the members of the group can be set. When the representative user inputs an interaction to the corresponding interface 530, the screen shown in Fig. 6 can be displayed.

[0129] FIG. 6 illustrates a screen displayed before step S220 in FIG. 2, in which the representative user terminal 20 can input authority setting information for group-based payment, in order for the server 10 to perform step S220.

[0130] Referring to FIG. 6, the representative user terminal 20 can display authority setting interfaces (610 to 680) that can set at least one piece of authority information corresponding to each general user.

[0131] The authority information that can be set by the representative user can be displayed in multiple types. The types of authority information that can be set can be set hierarchically. In other words, if the representative user primarily approves group-based payments for specific users, they can secondarily select detailed payment authority. Detailed payment authority can be divided into pre-approval payment authority (payment in advance) and approval-conditional payment authority (payment after approval).

[0132] Pre-approval payment authority means that the representative user approves the payment in advance so that the relevant user can immediately make a payment using the registered payment method. Also, approval-conditional payment authority means that the representative user approves the payment request sent by the relevant user to the representative user and makes the payment.

[0133] Specifically, if the representative user inputs an allow (ON) interaction for the group-based payment interface 610, 640, interfaces 620, 630, 650, 660 that allow the user to determine the detailed payment authority of the user can be displayed. If the representative user inputs a non-allow (OFF) interaction for the group-based payment interface 670, the interfaces that allow the user to determine the detailed payment authority of the user can not be displayed.

[0134] When the representative user interacts with the setting interface (610 to 670) for the payment authority, the authority setting information for changing the status of the payment authority of the corresponding user can be transmitted to the server 10.

[0135] Although not shown in Fig. 6, if the representative user allows pre-approval (pre-approval) payment authority, the representative user terminal 20 may further display an interface through which the user can input conditions for pre-approval. Also, if the representative user terminal 20 does not display a separate interface through which the user can input conditions for pre-approval (pre-approval), this may mean that the conditions for pre-approval are set as predetermined. When the representative user inputs an interaction on the authority information setting application interface 680 of Fig. 6, the server 10 receives authority setting information for group-based payment (S220) and sets the authority information for group-based payment (S230).

[0136] FIG. 7 illustrates a screen that is displayed before step S240 in order for the server 10 to perform step S240 of FIG. 2, in which the first general user terminal 30 can select payment request information for group-based payment.

[0137] 7(a), the first general user terminal 30 can display information 710 about the product to be paid for and at least one payment method to be selected. The first general user can input an interaction to the group-based payment interface 720 from the at least one payment method displayed.

[0138] Unlike (a) of FIG. 7, if the first general user does not have any payment authority for group-based payment, group-based payment may not be displayed as a selectable payment method. Lack of payment authority for group-based payment may occur, for example, when payment authority is not obtained from the representative user or when the first general user is not included in the group. In some cases, if the first general user is included in a group but does not have payment authority from the representative user, information about group-based payment may be displayed as a selectable payment method, but may be displayed in an inactive state, meaning that payment is not possible due to lack of payment authority. Also, an interface (not shown) may be displayed that allows the first general user to request payment authority from the representative user.

[0139] In FIG. 7(a), when a first general user inputs an interaction to the group-based payment interface 720, the screen displayed thereafter may differ depending on the authority information of the first general user for group-based payment.

[0140] If the authority information for the group-based payment of the first general user indicates that the authorization for payment with approval conditions is permitted, a screen such as that shown in Figure 7(b) may be displayed after the first general user inputs an interaction to the group-based payment interface 720 in Figure 7(a). Referring to Figure 7(b), the screen may include information 730 that an approval request message has been sent to the representative user of the group and information 740 regarding the group-based payment for which the first general user has requested approval.

[0141] If the authority information for the first general user for group-based payment is that pre-approved payment authority is permitted, after the first general user inputs an interaction to the group-based payment interface 720 in (a) of Figure 7, a similar screen as Figure 10 or Figure 11 and / or with some content changed depending on the situation may be displayed.

[0142] 8 to 12 illustrate screens in a state where the server 10 executes step S250 of FIG. 2 and at least one of the representative user terminal 20 and the first general user terminal 30 receives and displays a payment-related message from the server 10. For ease of explanation, it will be assumed that all of FIGS. 8 to 12 are screens displayed on the representative user terminal 20. However, all of the general user terminals constituting the group in FIGS. 8 to 12 may also display the same screens, or similar screens with some content modified by authority.

[0143] FIG. 8 illustrates a screen in which the server 10 executes steps S301 and S302 of FIG. 3 and the representative user terminal 20 receives and displays a payment-related message from the server 10.

[0144] Figure 8 shows a screen in which the server 10 generates an approval request message as a first payment-related message and provides it to the representative user terminal 20 when the authority information for the group-based payment of the first general user who requested the group-based payment is approved as conditional payment authority.

[0145] 8, the approval request messages 810 and 820 may be provided through chat rooms 801 and 802 of a messenger service in which at least one of the representative user and the first general user participates. Specifically, as shown in FIG. 8, the chat rooms may be one-on-one chat rooms 801 and 802 in which only the representative user and the first general user participate.

[0146] As shown in Figure 8(a), if there is no existing chat room for transmitting an approval message, a new chat room 801 can be created and an approval request message 810 can be provided. The approval request message 810 can include information 811 on the group-based payment requested by the first general user and a request detail display interface 812. Although not shown in Figure 8(a), a chat can be conducted between the representative user and the first general user through the chat room 801.

[0147] 8(b), if a chat room for transmitting an approval request message already exists, an approval request message 820 can be provided through the existing chat room 802. The approval request message 820 can include information 821 on the group-based payment requested by the first general user and a request detail display interface 822.

[0148] 8(b), since it is an existing chat room 801, the history of chats 831 and 832 between the representative user and the first general user can be displayed through the chat room 802 before the approval request message 820 is displayed. Also, after the approval request message 820 is displayed, chats 833 and 834 between the representative user and the first general user can be displayed through the chat room 802.

[0149] The representative user and the first general user can discuss the details of the group-based payment requested by the first general user through the chat rooms 801 and 802. In this case, the representative user and the first general user can chat with the first general user while remaining in the same chat room 801 and 802 without leaving the chat room 801 and 802 where the approval request message 810 and 820 was delivered.

[0150] The approval request message 810 may be displayed in a form in which a first general user is the speaker 813 in the chat room 801, as shown in Figure 8(a). However, in some cases, the approval request message 820 may be displayed in a form in which the server 10 that executes or manages the group-based payment is the speaker 823, as shown in Figure 8(b).

[0151] In FIG. 8, when the representative user inputs an interaction on the request detail display interface 812, 822 of the approval request message 810, 820, the screen of FIG. 9 may be displayed.

[0152] FIG. 9 illustrates a detailed display screen of the approval request message generated by the server 10 in step S301 of FIG. 3 and provided to the representative user terminal 20 in step S302.

[0153] Referring to FIG. 9, the detailed display screen of the approval request message may include information 910 requesting approval for the group-based payment requested by the first general user, detailed content 920 of the group-based payment requested by the first general user, a validity period 930 during which the representative user can approve, and interfaces 941, 942 for approval / rejection.

[0154] Although not shown in FIG. 9, when the representative user enters an interaction with the rejection interface 941 to reject approval for a group-based payment requested by the first general user, an interface may be displayed that allows the reason for rejection to be entered.

[0155] When the representative user inputs an interaction to the approval interface 942 to approve the group-based payment requested by the first general user, at least one of the screens of FIG. 10 and FIG. 11 can be displayed on the representative user terminal 20.

[0156] 10 and 11 show screens on which the payment completion message and the payment rejection message provided by the server 10 in step S304, step S306, step S402 or step S403 of FIGS. 3 and 4 are displayed.

[0157] 10(a), a payment completion message can be displayed. The payment completion message can include an interface 1030 that can view payment completion information 1010 for the group-based payment, details 1020 of the completed group-based payment, and the overall payment details of the group-based payment.

[0158] 10(b), a payment rejection message can be displayed. The payment rejection message can include payment rejection information 1040 for the group-based payment, details 1050 of the rejected group-based payment, and an interface 1060 that allows viewing of the entire group-based payment breakdown.

[0159] Referring to FIG. 11, the payment completion message can be provided through chat rooms 1101 and 1102 for providing information other than the chat rooms in which the representative user and the first general user participate.

[0160] 11, the chat rooms 1101 and 1102 may display payment-related messages in a format in which the server 10 that executes or manages the group-based payment function is the speaker 1113 and 1123. In some cases, the chat rooms 1101 and 1102 may be chat rooms in which the server 10 or a chatbot operated by the server 10 is the other party 1113 and 1123, and the main purpose of the chat rooms may not be to exchange conversations with each other but to receive information from the server 10 or the chatbot. Therefore, in such chat rooms 1101 and 1102, the representative user may be restricted from inputting messages.

[0161] 11(a), a payment completion message 1110 can be displayed. The payment completion message 1110 can include detailed content 1111 of the group-based payment for which the payment has been completed and an interface 1112 for viewing the entire payment history of the group-based payment.

[0162] 11(b), a payment rejection message 1120 can be displayed. The payment rejection message 1120 can include detailed content 1121 of the rejected group-based payment and an interface 1122 that allows viewing of the entire payment breakdown of the group-based payment.

[0163] When the representative user interacts with the interfaces 1030, 1060, 1112, and 1122 that allow the user to view the entire breakdown of a group-based payment, a screen that allows the user to view the entire breakdown of a group-based payment, as shown in FIG. 12, can be displayed.

[0164] FIG. 12 illustrates a screen displayed on the representative user terminal 20 to display a breakdown of the entire group-based payment.

[0165] 12, various information related to group-based payment can be displayed. Specifically, information 1201 about the user, an interface 1202 for setting payment authority for members of the group-based payment, information 1220 about the overall payment details of the group-based payment, and information 1230 about the current status of the periodic payment of the group-based payment can be displayed.

[0166] In some cases, information about group-based payment such as that shown in Figure 12 can be accessed not only by the representative user but also by general users. When information about group-based payment such as that shown in Figure 12 is displayed on a general user terminal, information 1201 about the user can be changed to the corresponding general user, and interface 1202 that allows setting payment authority for members of the group-based payment can be deactivated and / or changed to another interface and displayed. For example, interface 1202 that allows setting payment authority can be changed to an interface (not shown) that requests the representative user to change their own authority information.

[0167] Hereinafter, with reference to FIGS. 13 and 14, another embodiment of a method for the server 10 of the present invention to provide group-based payment to users of a messenger service will be described.

[0168] 13 and 14 are exemplary diagrams illustrating screens during the process in which the representative user terminal 20 performs group-based payment according to another embodiment of the present invention.

[0169] 13, information 13010 on additional approvers who can approve group-based payments other than the representative user may be displayed for group members. The additional approvers may be designated by the representative user. An interface may be displayed that allows the representative user to designate additional approvers.

[0170] The approval authority of an additional approver can be defined in various ways. For example, when either the representative user or the additional approver approves a request for approval of a group-based payment, the approval of the group-based payment can be completed. However, in some cases, the approval of the group-based payment can be completed only when both the representative user and the additional approver approve the request for approval of the group-based payment.

[0171] In some cases, the approval authority of the additional approver can be determined depending on the amount and content of the group-based payment. For example, if the amount of the group-based payment is 100,000 won or less, the additional approver has sole approval authority, but if the amount is over 100,000 won, the additional approver does not have sole approval authority.

[0172] 14, when an additional approver is designated, an approval request message 1410 can be provided through a chat room 1401 including the representative user, the additional approver, and a first general user. If a corresponding chat room 1401 has already been created, the approval request message 1410 can be provided through the corresponding existing chat room, and if no chat room has already been created, a new chat room can be created and the approval request message 1410 can be provided.

[0173] As shown in FIG. 14, if an additional approver has the authority to approve the approval request message 1410, he or she can approve the group-based payment independently through the corresponding chat room 1401.

[0174] As shown in FIG. 14, the representative user, the additional approver, and the first general user can conduct a chat (1421 to 1424) regarding group-based payment through the chat room 1401 to which the approval request message 1410 is provided.

[0175] Hereinafter, a method for the representative user terminal 20 of the present invention to perform group-based payment for users of a messenger service will be described with reference to FIG.

[0176] FIG. 15 is a flowchart illustrating a method for the representative user terminal 20 of the present invention to perform group-based payment for users of a messenger service.

[0177] The method of the representative user terminal 20 performing group-based payment is the same as the method of the server 10 providing group-based payment described with reference to Figures 2 to 12, except for the entity performing the execution. Therefore, for ease of explanation, some of the same content as that described above in the method of the representative user terminal 20 performing group-based payment will be substituted for the above content.

[0178] In step S1510, the representative user terminal 20 displays information about the representative user and a group including at least one general user. Step S1510 corresponds to step S210 executed by the server 10. An example screen of the representative user terminal 20 in step S1510 is shown in FIG.

[0179] In step S1520, the representative user terminal 20 displays an authority setting interface that allows the user to set at least one piece of authority information corresponding to each general user. In step S1530, the representative user terminal 20 receives input of a setting interaction for the authority setting interface. Steps S1520 and S1530 correspond to steps S220 and S230 executed by the server 10. Example screens of the representative user terminal 20 in steps S1520 and S1530 are shown in FIG. 6.

[0180] In step S1540, the representative user terminal 20 displays a payment-related message generated in response to the first general user's request for group-based payment. Step S1540 corresponds to step S250 executed by the server 10. Exemplary screens of the representative user terminal 20 in step S1510 are shown in Figures 8 to 12.

[0181] The technical features disclosed in each embodiment of the present invention are not limited to the corresponding embodiment, and as long as they are not mutually incompatible, the technical features disclosed in each embodiment can be combined and applied to different embodiments.

[0182] Therefore, although each embodiment will be described focusing on its respective technical features, as long as the technical features are not mutually exclusive, they can be combined and applied.

[0183] The present invention is not limited to the above-described embodiments and the accompanying drawings, and various modifications and variations are possible from the viewpoint of those skilled in the art to which the present invention pertains. Therefore, the scope of the present invention should be determined not only by the claims of this specification but also by equivalents of the claims. [Explanation of symbols]

[0184] 10: Server 20: Representative user terminal 30: First general user terminal 40: Second general user terminal

Claims

1. 1. A method for providing group-based payments to users of a messenger service by a server, comprising: Identifying a group consisting of a plurality of users of the messenger service, the group including a representative user and at least one general user; acquiring authority information for group-based payment of the at least one general user from the terminal of the representative user; receiving payment request information for the group-based payment from a terminal of a first general user; providing a payment-related message to the representative user's terminal through the messenger service based on the authority information of the first general user; A method for providing group-based payments to users of a messenger service.

2. 10. The method of claim 1, The payment-related message is provided through a chat room in which the representative user and the first general user participate.

3. 3. The method of claim 2, The payment-related message is If the chat room already exists, the method provides the chat room through the already existing chat room.

4. 10. The method of claim 1, When the authority information of the first general user is such that the group-based payment is possible subject to payment approval by the representative user, the payment-related message includes an approval request message for requesting payment approval from the representative user.

5. 5. The method of claim 4, The approval request message includes an approval interface for group-based payment requested by the first general user.

6. 5. The method of claim 4, receiving approval information for the approval request message from the representative user's terminal; The method further includes a step of providing a payment completion message for the group-based payment of the first general user to at least one of the terminal of the representative user and the terminal of the first general user.

7. 7. The method of claim 6, The payment completion message is provided through a chat room other than the approval request message.

8. 10. The method of claim 1, If the authority information of the first general user is that the group-based payment can be made based on the prior approval of the representative user, the payment-related message includes a payment completion message for the group-based payment of the first general user; The payment completion message is provided through an information providing chat room that provides information about payment functions.

9. 9. The method of claim 8, The information providing chat room is a chat room in which the representative user and the server that performs the payment function participate.

10. 10. The method of claim 1, The step of obtaining the authority information includes: providing an authority setting interface to the terminal of the representative user, which can set information for at least one general user and at least one authority information corresponding to each of the general users; receiving setting information corresponding to the authority setting interface from the terminal of the representative user.

11. 11. The method of claim 10, The authority information is Information regarding the authority of the corresponding general user to make the group-based payment on the condition that the representative user approves the payment; and information regarding the authority to make the group-based payment based on the prior approval of the representative user.

12. 11. The method of claim 10, A method in which the authority information includes a payment limit for the group-based payment for the general user and information on the number of times it can be made.

13. 10. The method of claim 1, The group further includes an approver; If the authority information of the first general user is that the group-based payment is possible on the condition of payment approval from at least one of the representative user and the authorized approvers, the payment-related message includes an approval request message associated with content requesting payment approval from the representative user and at least one of the authorized approvers, The approval request message is sent through a chat room in which the representative user, at least one of the approvers, and the first general user participate.

14. 10. The method of claim 1, The group-based payment includes at least one payment instrument; The step of receiving the payment request information includes: providing a selection interface for selecting one of the at least one payment means in the group-based payment to the terminal of the first general user; receiving selection information corresponding to the selection interface from the terminal of the first general user; The payment-related message is generated further based on a payment method selected by the first general user.

15. A server that provides group-based payment to users of a messenger service, Memory and a processor coupled to the memory and configured to execute instructions contained in the memory; The processor identifies a group consisting of a plurality of users of a messenger service, the group including a representative user and at least one general user; The processor is configured to perform the steps of the method according to any one of claims 1 to 14. server.

16. A method for a user terminal to perform group-based payment through a messenger service, a step of displaying information for a group including a representative user and at least one general user (wherein the user of the user terminal corresponds to the representative user); displaying an authority setting interface capable of setting at least one piece of authority information corresponding to each of the general users; receiving a setting interaction input for the authority setting interface; and displaying a payment-related message generated in response to a payment request for the group-based payment from a first general user (wherein the payment-related message is generated as a predetermined type of message based on the authority information of the first general user). A method for making group-based payments through a messenger service.

17. 17. The method of claim 16, The payment-related message is displayed through a chat room in which the user and the first general user participate.

18. the user terminal including a memory; and a processor coupled to the memory and configured to execute instructions contained in the memory; The processor is configured to perform the steps of the method according to any one of claims 16 to 17. User terminal.

19. A computer program stored in a storage medium for executing the method of any one of items 1 to 14, 16, and 17 in combination with hardware.

Images