Contribution based user-driven commerce system

Abstract

The present invention relates to a contribution-based user-driven commerce system comprising: a user terminal; a contributor terminal; The system includes a server unit that receives a wishlist, which is a list of products selected by a user, from the user terminal, and receives a contribution amount, which is an amount for purchasing the products, from the contributor terminal, and performs the purchase of the products. The server unit includes a product management module that stores and manages product information including the product name, price, stock, and product description of the products included in the wishlist; a sharing module that creates a contribution collection period, which is a period for collecting the contribution amount based on the wishlist, and transmits the wishlist and the contribution collection period to the contributor terminal; a contribution management module that stores the contribution amount received from the contributor terminal and generates contribution history information; and a processing module that, when the total sum of the contribution amounts satisfies the price of the products, receives a purchase approval response from the user terminal, performs the purchase of the products, and generates payment history information. The contribution management module calculates a cumulative contribution amount by summing the contribution amounts collected within the contribution collection period, calculates a contribution progress rate, which is the ratio of the cumulative contribution amount to the price of the products, and transmits the contribution progress rate to the user terminal and the contributor terminal. The processing module provides the contribution status for the wishlist, and if the accumulated contribution amount is less than the price of the product at the time the contribution collection period expires, it transmits a selection request to the user terminal regarding whether to make an additional payment for the shortfall amount or whether to transfer the contribution amount to another product included in the wishlist; if the accumulated contribution amount is greater than or equal to a preset threshold, it additionally transmits to the user terminal whether to extend the contribution collection period, and if it receives a response from the user terminal regarding the additional payment for the shortfall amount, it performs the purchase of the product and generates the payment history information.When a response regarding the transfer of the contribution amount is received from the user terminal, the contribution amount is transferred to other products included in the wishlist, and the contribution history information is updated; when a response regarding the extension of the contribution recruitment period is received from the user terminal, a payment procedure for the period extension cost is executed, and the end time of the contribution recruitment period is updated; and if the purchase approval response is not received for a preset period after the contribution recruitment period has expired, a refund procedure for the contribution amount is initiated based on the contributor identifier and payment method information included in the contribution history information, and the contribution amount is transmitted to the contributor terminal; and the sharing module blocks the creation of a new wishlist and sharing request when the accumulated contribution amount is less than the price of the product, and when the accumulated contribution amount reaches the price of the product, blocks the transmission of the contribution amount, the extension of the contribution recruitment period, and the change of products within the wishlist, and terminates the contribution recruitment period. According to the present invention, a wishlist is created centered on a product selected by a user, and after receiving distributed contributions from multiple contributors by sharing it with acquaintances, automatically depending on whether the contribution amount has accumulated Since purchases can be processed by determining payment eligibility, it is effective in reducing the drop-off issues that frequently occur in existing cart-based commerce structures and improving payment conversion rates. Furthermore, since various follow-up processing options are provided for users even when the contribution amount does not reach the target amount, the user engagement flow can continue flexibly without interruption, and it is effective in being suitable for practical consumption scenarios such as joint gifting or split-payment purchasing.

Description

Technology Field

[0001] The present invention relates to a contribution-based user-driven commerce system. Background Technology

[0002] Generally, e-commerce systems are structured so that consumers select a product and make a payment based on product information provided by the seller. In such a structure, the transaction flow originates from the seller, and while the consumer is the agent of selection and payment, they cannot actively lead the entire purchasing process.

[0003] Furthermore, in the online shopping environment, it frequently occurs that users add specific products to their shopping carts but abandon the process before reaching actual payment. This is analyzed to be due to structural constraints where users must make purchasing decisions independently without external support or assurance, as well as the time and psychological burden associated with completing the purchasing action. In fact, according to a survey on online shopping usage by the Korea Internet & Security Agency, the rate of items in shopping carts ending without payment exceeds 65%, statistically proving the inefficiency of the shopping cart-based flow.

[0004] This structure makes it difficult to flexibly implement various purchasing methods, such as joint purchasing for gifting purposes or shared payments, and can lead to problems such as reduced purchase rates, decreased profitability for operators, and impaired user experience.

[0005] While some conventional contribution-based purchasing systems proposed single-point proxy payments or partial sponsorship payment methods, they had limitations in that the contribution flow was not systematized in a user-centric manner and they could not effectively provide flexible payment logic such as cumulative contribution management, payment condition branching, and period extension or transfer processing.

[0006] Therefore, there is a need to develop a new type of user-centric commerce system that encourages the participation of acquaintances centered on products of interest to the user, collects funds in a specific manner, and leads to a purchase. The problem to be solved

[0007] The objective of the present invention is to provide a contribution-based user-driven commerce system that solves the problems associated with the aforementioned prior art. By devising a technology to resolve these issues, the system enables the sharing of purchasing costs by inducing financial participation from acquaintances based on a user's wishlist, and by configuring the system so that a purchase is automatically made when payment conditions are met based on the contribution amount accumulated over a certain period, thereby shifting the purchasing flow to user-driven control, resolving the problem of cart abandonment, and improving the payment conversion rate. means of solving the problem

[0008] The above objective is achieved, according to the present invention, by a user terminal; a contributor terminal; The system includes a server unit that receives a wishlist, which is a list of products selected by a user, from the user terminal, and receives a contribution amount, which is an amount for purchasing the products, from the contributor terminal, and performs the purchase of the products. The server unit includes a product management module that stores and manages product information including the product name, price, stock, and product description of the products included in the wishlist; a sharing module that creates a contribution collection period, which is a period for collecting the contribution amount based on the wishlist, and transmits the wishlist and the contribution collection period to the contributor terminal; a contribution management module that stores the contribution amount received from the contributor terminal and generates contribution history information; and a processing module that, when the total sum of the contribution amounts satisfies the price of the products, receives a purchase approval response from the user terminal, performs the purchase of the products, and generates payment history information. The contribution management module calculates a cumulative contribution amount by summing the contribution amounts collected within the contribution collection period, calculates a contribution progress rate, which is the ratio of the cumulative contribution amount to the price of the products, and transmits the contribution progress rate to the user terminal and the contributor terminal. The processing module provides the contribution status for the wishlist, and if the accumulated contribution amount is less than the price of the product at the time the contribution collection period expires, it transmits a request to the user terminal to select whether to make an additional payment for the shortfall amount or whether to transfer the contribution amount to another product included in the wishlist. If the accumulated contribution amount exceeds a preset threshold, additionally transmit to the user terminal whether to extend the contribution recruitment period; if a response regarding additional payment for the insufficient amount is received from the user terminal, perform the purchase of the product and generate payment history information; if a response regarding the transfer of the contribution amount is received from the user terminal, transfer the contribution amount to another product included in the wishlist and update the contribution history information; if a response regarding the extension of the contribution recruitment period is received from the user terminal, execute the payment procedure for the period extension cost and update the end time of the contribution recruitment period; if the purchase approval response is not received for a preset period after the contribution recruitment period has expired, initiate a refund procedure for the contribution amount based on the contributor identifier and payment method information included in the contribution history information and transmit the contribution amount to the contributor terminal; and the sharing module blocks the creation of a new wishlist and sharing request if the accumulated contribution amount is less than the price of the product, and if the accumulated contribution amount reaches the price of the product, transmits the contribution amount, the contribution recruitment period This is achieved by a contribution-based user-driven commerce system that blocks extensions and changes to products within the aforementioned wishlist and terminates the aforementioned contribution recruitment period.

[0009] delete

[0010] delete

[0011] delete

[0012] Additionally, the server unit further includes a recommendation module that analyzes the selection history and payment history information of the product based on the wishlist received from a plurality of user terminals to select popular products, and generates recommended product information based on the popular products. Effects of the invention

[0013] According to the present invention, a wishlist is generated centered on a product selected by a user and shared with acquaintances to receive distributed contributions from multiple contributors. Since the payment decision is automatically determined based on the accumulation of the contributed amounts and the purchase is processed, this has the effect of reducing the drop-off problem that frequently occurs in existing shopping cart-based commerce structures and improving the payment conversion rate.

[0014] In addition, since various follow-up options are provided for users even if the contribution amount does not reach the target amount, the user participation flow can continue flexibly without interruption, and it is effective in being suitable for practical consumption scenarios such as joint gifting or cost-sharing purchases.

[0015] Meanwhile, the effects of the present invention are not limited to those mentioned above, and various effects may be included within the scope obvious to a person skilled in the art from the contents described below. Brief explanation of the drawing

[0016] FIG. 1 illustrates the connections between the components of a contribution-based user-driven commerce system according to an embodiment of the present invention, and FIGS. 2 and 3 illustrate an example of an interface of a user terminal of a contribution-based user-driven commerce system according to an embodiment of the present invention, and FIG. 4 illustrates an example of an interface of a contributor terminal of a contribution-based user-driven commerce system according to an embodiment of the present invention, and FIG. 5 illustrates an example of a contribution management module of a contribution-based user-driven commerce system according to an embodiment of the present invention, and FIG. 6 illustrates an example of a processing module of a contribution-based user-driven commerce system according to an embodiment of the present invention. Specific details for implementing the invention

[0017] Hereinafter, some embodiments of the present invention will be described in detail with reference to the exemplary drawings. It should be noted that in assigning reference numerals to the components of each drawing, the same components are given the same reference numeral whenever possible, even if they are shown in different drawings.

[0018] In addition, when describing embodiments of the present invention, if it is determined that a detailed description of related known configurations or functions would hinder understanding of the embodiments of the present invention, such detailed description is omitted.

[0019] In addition, terms such as first, second, A, B, (a), (b), etc., may be used when describing the components of the embodiments of the present invention. These terms are used merely to distinguish the components from other components, and the essence, order, or sequence of the components is not limited by the terms used.

[0020] Additionally, in the specification, the singular form includes the plural form unless specifically stated otherwise in the text. The terms “comprising” and / or “comprising” as used in the specification do not exclude the presence or addition of one or more other components in addition to the mentioned components.

[0021] Additionally, in describing embodiments of the present invention, each "part," "module," or "step" may be implemented through a processor and memory. The term processor should be broadly interpreted to include general-purpose processors, central processing units (CPUs), microprocessors, digital signal processors (DSPs), controllers, microcontrollers, state machines, and the like. In some environments, the term processor may refer to an application-specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable gate array (FPGA), and the like. The term processor may also refer to a combination of processing devices, such as, for example, a combination of a DSP and a microprocessor, a combination of multiple microprocessors, a combination of one or more microprocessors combined with a DSP core, or any other combination of such configurations.

[0022] Furthermore, memory should be broadly interpreted to include any electronic component capable of storing electronic information. Memory may also refer to various types of processor-readable media such as random access memory (RAM), read-only memory (ROM), non-volatile random access memory (NVRAM), programmable read-only memory (PROM), eraseable-programmable read-only memory (EPROM), electrically eraseable PROM (EEPROM), flash memory, magnetic or optical information storage devices, registers, etc. If a processor can read information from memory or write information to memory, memory is said to be in an electronic communication state with the processor, and each "part," "module," or "stage" may be implemented through a program or application based on the processor and memory in an electronic communication state.

[0024] Now, with reference to the attached drawings, a contribution-based user-driven commerce system (100) according to one embodiment of the present invention will be described in detail.

[0025] As illustrated in FIG. 1, a contribution-based driven commerce system (100) according to one embodiment of the present invention includes a user terminal (110), a contributor terminal (120), and / or a server unit (130).

[0026] As illustrated in FIG. 2, the user terminal (110) is a device that allows the user to select a product to register as a wishlist, share the wishlist with the contributor terminal through the server unit (130), check the contribution status in real time, or perform purchase confirmation and subsequent input, and is connected to the server unit (130) via a network.

[0027] The user terminal (110) can be implemented as an electronic device equipped with network communication functions, such as a smartphone, tablet, laptop, desktop, etc., and can provide a user interface through a web browser-based platform or a dedicated application.

[0028] The user terminal (110) receives information about the products listed from the server unit (130), and the user can register products of interest to the wishlist based on this.

[0029] As shown in Fig. 3, for a user creating a wishlist for the first time, guidance messages such as “Add the items you want to receive” or “Share with an acquaintance” or sequential tutorial screens may be displayed to help the user understand the flow.

[0030] The user terminal (110) provides the user with a wishlist sharing link received from the server unit (130), and the user can transmit this to the contributor through various channels such as messenger, SNS, and text message. The wishlist and the contribution recruitment period are provided to the contributor through the contributor terminal (120), and the shared link acts as the starting point of the contribution flow. At this time, the user terminal (110) plays the role of leading the contribution-based commerce flow as the sending point of the sharing procedure.

[0031] Additionally, the user terminal (110) can receive contribution progress information provided in real time from the server unit (130) and display it on the user interface.

[0032] Contribution progress information may include the cumulative contribution amount to date, a list of individual contributors, and the amount short of the target amount, and may be provided visualized in the form of a progress bar, donut chart, percentage figures, etc.

[0033] When the contribution recruitment period ends, if the accumulated contribution amount is greater than or equal to the product price, the user terminal (110) can receive a purchase approval response from the server unit (130) and execute payment by transmitting the user's purchase confirmation input to the server unit (130).

[0034] Additionally, if the accumulated contribution amount after the contribution recruitment period has expired falls short of the product price, the user terminal (110) may receive and display a user interface (UI) screen including a plurality of selectable subsequent processing options along with a guidance message about the situation from the server unit (130).

[0035] For example, options such as “80% has been collected so far. Would you like to pay the remaining 2,000 won?”, “Would you like to transfer a portion of your contribution to another product?”, or “Please pay 1,000 won to extend your contribution period by 3 days” may be displayed on the screen as buttons or pop-ups.

[0036] The user can input options by clicking or touching, and the selected user response is transmitted to the server unit (130) via the user terminal (110). Accordingly, the server unit (130) can perform subsequent processing, or if additional input or confirmation is required, retransmit the request to the user terminal (110) to continuously guide the user's decision-making.

[0037] Meanwhile, the user terminal (110) may be configured to create and share the next wishlist after the collection of contributions for the wishlist is completed, once the sharing of one wishlist is completed.

[0038] This sequential sharing method can clearly separate the flow of contributions and increase the concentration of contributions for each wishlist, and accordingly, the server unit (130) coordinates the sharing request of the user terminal (110) based on the progress status of the wishlist and supports a consistent user experience by providing the user with an interface that guides them to the next step after the wishlist is completed.

[0039] The contributor terminal (120) is connected to the server unit (130) via a network, and can access a wishlist shared by the user, input and transmit a contribution amount for the products included in the wishlist, and check the contribution history and progress.

[0040] The contributor terminal (120) can be implemented as an electronic device equipped with network communication capabilities, such as a smartphone, tablet, laptop, desktop, etc., and can provide a user interface through a web browser-based platform or a dedicated application.

[0041] As illustrated in FIG. 4, the contributor terminal (120) can access a specific wishlist page by connecting to the server unit (130) through a wishlist sharing link received from the user via various channels such as messenger, SNS, and text message. At this time, when the link is clicked, if the contributor has not installed the app, it is connected to an installation page, and after the installation is complete, it can be configured to automatically enter the wishlist screen.

[0042] The server unit (130) can provide a contribution participation screen to the contributor terminal (120) that displays product information included in the wishlist, the contribution recruitment period, the target amount, and the accumulated contribution amount to date, and the contributor can proceed with the contribution by entering a certain amount after checking the nature of the product and the contribution status through the screen.

[0043] For example, an amount input field may be provided along with a guidance message saying, “You can contribute starting from 1,000 won for an acquaintance,” and amount selection buttons such as 1,000 won, 5,000 won, and 10,000 won may be displayed together.

[0044] The user interface of the contributor terminal (120) may be configured in the form of a contribution amount input field, a payment method selection menu, a contribution message input field, etc., and the contributor may input their intention to contribute through this and transmit the information to the server unit (130). The contributor's payment history is stored in the server unit (130), and a result confirmation message or simple receipt information may be displayed to the contributor terminal (120).

[0045] Additionally, the contributor terminal (120) may also include a function that allows the contributor to check their contribution history, make additional contributions to the same wishlist, or share it with others. For example, after the contribution is completed, a share button may be displayed with the phrase “Please share this wishlist with your friends,” and the user may press it to send the wishlist link to a third party.

[0046] The server unit (130) receives a wishlist, which is a list of products selected by the user, from the user terminal (110), and receives a contribution amount, which is an amount for purchasing the products, from the contributor terminal (120), and performs the purchase of the products, and is connected to the user terminal (110) and / or contributor terminal (120) via a network.

[0047] More specifically, the server unit (130) includes a product management module (131), a sharing module (132), a contribution management module (133), and a processing module (134).

[0048] The product management module (131) stores and manages product information including the product name, price, stock, and product description of the products included in the wishlist, and is electrically connected to the sharing module (132) and / or processing module (134).

[0049] The product management module (131) is configured to store and manage product information used in a wishlist-based contribution flow within the server unit (130), and can operate based on one or more product information registered through a user terminal (110) or an operator system.

[0050] Product information includes product name, price, stock and / or product description, and can be used as a default value for all product-related data output to the user terminal (110) and contributor terminal (120).

[0051] The product name is unique text for identifying a product, which can be provided so that the user can verify it when registering a wishlist on the user terminal (110), and the product to be contributed can also be displayed with the same name on the contributor terminal (120). The product name may consist of, for example, “Brand A wireless earphones”, “B Company premium coffee set”, etc.

[0052] The price is a standard amount required for purchasing the product, is automatically set as the contribution target amount when creating the wishlist, and can be used as a standard for calculating the contribution progress rate on the contributor terminal (120).

[0053] Prices can be stored in units of won, and the server unit (130) can perform comparison of accumulated contribution amounts and determination of payment conditions based on prices.

[0054] The inventory is quantity information for determining whether a product can be ordered, and is checked in real time at the time of registering a wishlist on the user terminal (110) and at the time of a payment request through the processing module (134). If the inventory quantity is insufficient or is 0 or less, the product may be processed as unavailable for payment.

[0055] A product description is a summary or detailed description of the product's key characteristics, which may include, for example, product composition, capacity, usage instructions, storage conditions, precautions, manufacturer information, etc.

[0056] The product description can be displayed on the wishlist detail view screen of the user terminal (110) or on the contribution participation screen of the contributor terminal (120), and can support the user's understanding of the product.

[0057] The product management module (131) can retrieve product information when configuring the wishlist and, in conjunction with the processing module (134), provide basic data for determining product payment conditions and processing orders.

[0058] The product management module (131) provides key reference information throughout the entire process from the creation of the wishlist to the progress of contributions and payment processing, and can function as a foundational configuration that maintains the basic data structure of all module operations of the server unit (130).

[0059] The sharing module (132) generates a contribution collection period, which is a period for collecting contribution amounts based on a wishlist, and transmits the wishlist and the contribution collection period to a contributor terminal, and is electrically connected to the product management module (131), the contribution management module (133), and / or the processing module (134).

[0060] When a wishlist is registered from a user terminal (110), the sharing module (132) can perform the function of creating a contribution collection period to collect a contribution amount along with a unique identifier of the wishlist, and creating a unique sharing link including the wishlist and the contribution collection period and transmitting it to the user terminal (110).

[0061] The sharing module (132) controls the start time of the wishlist-based contribution flow and can configure the conditions for entering contribution participation through the contributor terminal (120).

[0062] The sharing module (132) can calculate the start and end times of the contribution recruitment period based on the time when the wishlist is registered, where the contribution recruitment period refers to time information defined so that contributions can be validly accepted for a certain period of time.

[0063] For example, the initial contribution recruitment period can be set to 7 days (168 hours), and the end time of the contribution recruitment period can be calculated as the time of wishlist creation plus 7 days.

[0064] The sharing module (132) can generate a unique sharing link including a wishlist identifier and contribution recruitment period information.

[0065] A unique sharing link allows access to the wishlist from a contributor terminal (120) and may include a unique key that can identify the wishlist and an authentication token to prevent unauthorized access or duplicate participation by the contributor.

[0066] The unique sharing link is transmitted to the user terminal (110), and the user can transmit it to the contributor through various channels such as messenger, text, and SNS, or transmit it directly through the contributor terminal (120).

[0067] When a contributor terminal (120) accesses a unique sharing link, the sharing module (132) can retrieve a wishlist based on the wishlist identification information included in the unique sharing link and control the contributor terminal (120) to display a contribution participation screen.

[0068] The contribution participation screen may include the product name, product price, cumulative contribution amount to date, shortfall compared to the target amount, and remaining time of the contribution recruitment period, and can be displayed in an intuitive format so that contributors can decide whether to contribute and enter the contribution amount.

[0069] The sharing module (132) can control the total amount of contributions entered through the contributor terminal (120) so that it does not exceed the target amount of each product included in the wishlist.

[0070] For example, if the price of a specific product is 59,900 won, the cumulative sum of the contribution amount can only be up to 59,900 won, and any amount exceeding this is not registered as a contribution amount.

[0071] In addition, the contributor terminal (120) is configured to allow input of the contribution amount only up to the remaining amount remaining until the target amount is reached, based on the accumulated contribution amount, and the contribution management module (133), which will be described later, calculates this in real time and outputs it to the contribution participation screen, thereby ensuring the convenience of input by the contributor and clarity in adjusting the contribution amount.

[0072] Additionally, the sharing module (132) can restrict contributions to a wishlist when the contribution amount for a product registered in the wishlist reaches the target amount, even if the contribution recruitment period has not yet ended.

[0073] This is intended to prevent duplicate payments or unnecessary contribution inputs after the contribution is completed. After the goal of the wishlist is achieved, the contribution flow can be terminated in the sharing module (132) so that operations such as entering a new contribution amount, extending the contribution recruitment period, or changing products within the wishlist are not allowed.

[0074] Additionally, the sharing module (132) can be configured to extend the contribution collection period if the total amount of contributions is greater than or equal to a preset threshold, and the extended contribution collection period can be updated to a new end time.

[0075] For example, if the accumulated contribution amount reaches 80% or more of the target amount, the contribution solicitation period can be configured to be extended by 3 days. When the extension condition is satisfied, the sharing module (132) can regenerate a unique sharing link including the updated end time and transmit the link so that it can be output to the contributor terminal (120).

[0076] The contribution management module (133) stores the contribution amount received from the contributor terminal (120) and generates contribution history information, and is electrically connected to the sharing module (132) and / or processing module (134).

[0077] The contribution management module (133) performs the function of aggregating and managing the contribution status in real time on a wishlist basis, and through this, can determine the subsequent operation conditions of the server unit (130) and provide a reference value for controlling the screen output conditions of the user terminal (110) and the contributor terminal (120).

[0078] Here, the contribution amount refers to the amount contributed by the contributor to the total cost of purchasing the items included in the wishlist.

[0079] Additionally, the accumulated contribution amount refers to the sum of all contribution amounts received from multiple contributor terminals (120) for the same wishlist, and can be used as a reference value indicating the total contribution scale for the entire wishlist.

[0080] The target amount can be set as the price of the product included in the wishlist, and the possibility of confirming the purchase, conditions for subsequent processing, and whether to extend the contribution solicitation period can be determined based on whether the accumulated contribution amount has exceeded the target amount.

[0081] The contribution management module (133) generates contribution history information for the received contribution amount, including items such as a wishlist identifier, contributor identifier, time of contribution, and input amount.

[0082] The wishlist identifier is an identification value assigned to uniquely identify each wishlist in the server unit (130), and the contributor identifier is a unique user identification value generated based on the user account or connection session of the contributor terminal (120).

[0083] The time of contribution is the system time based on the server, and may include the exact date and time when the contribution amount was received by the server unit (130).

[0084] The contribution history information generated in the contribution management module (133) can be used to analyze or sort the contribution flow by time unit, user unit, or wishlist unit, and can be used as reference data for subsequent payment processing or user interface configuration.

[0085] The contribution management module (133) can calculate the cumulative contribution amount in real time by summing the contribution amounts received within the contribution recruitment period, based on the target amount received from the product management module (131) and the contribution recruitment period received from the sharing module (132).

[0086] Additionally, the contribution management module (133) calculates the ratio of the current accumulated contribution amount to the target amount, and through this, calculates the contribution progress rate so that it can be linked to the processing module (134) described later to determine subsequent processing.

[0087] As illustrated in FIG. 5, the contribution management module (133) collects the contribution amount received from the contributor terminal (120) in the form of a wishlist, calculates the cumulative contribution amount and contribution progress rate in real time based on the target amount and contribution collection period, and can provide the basis for the contribution status output to the interface of the user terminal (110) and the contributor terminal (120), and can be used as reference data for subsequent condition determination by the processing module (134).

[0088] The processing module (134) receives a purchase approval response from the user terminal (110) when the total sum of the contribution amount satisfies the price of the product, performs the purchase of the product, and generates payment history information, and is electrically connected to the product management module (131) and / or the contribution management module (133).

[0089] As illustrated in FIG. 6, the processing module (134) can send a purchase confirmation request to the user terminal (110) based on the point in time when the accumulated contribution amount collected in wishlist units reaches the target amount, and functions to execute the payment procedure for the product after receiving the user's purchase approval response.

[0090] At this time, the target amount can be set as the price of the product included in the wishlist, and whether it is satisfied can be determined by comparing it with the accumulated contribution amount transmitted in real time from the contribution management module (133).

[0091] A purchase confirmation request may be displayed on the user terminal (110) in the form of a purchase confirmation notification message or a payment confirmation pop-up, and the user may send a response by approving or canceling it.

[0092] When the processing module (134) receives a user’s purchase approval response to a purchase confirmation request from the user terminal (110), it configures payment execution conditions based on product information included in the wishlist from the product management module (131) and can execute an actual payment request through an external payment processing server or a linked payment method.

[0093] For example, when a purchase approval response is received from a user terminal (110), the processing module (134) can call a simple payment method such as automatic card payment or mobile phone micropayment, or a manual payment method such as virtual account deposit or remittance, and check whether the payment is successfully completed.

[0094] In addition, the processing module (134) can perform payment requests by utilizing the payment API of an external payment agency (PG company).

[0095] After receiving the user's purchase approval response, the processing module (134) calls the API of the PG company according to the payment execution conditions, receives the payment result information provided in response thereto, and can store it in an internal system or link it to settlement processing and user interface (UI) configuration.

[0096] The payment processing process of the processing module (134) can be reflected in real time on the interface of the user terminal (110) as guidance messages such as “payment in progress,” “payment successful,” and “payment failed.”

[0097] When payment completion is confirmed, the processing module (134) can generate payment history information including a wishlist identifier, buyer identifier, time of payment, payment method, payment amount, etc.

[0098] Here, the wishlist identifier is an internal identification value for uniquely identifying the wishlist for which payment has been made, and the buyer identifier can be generated based on the user account, login token, or unique user ID of the user terminal (110).

[0099] The payment time is defined as the system time at which the payment is finally approved through the server unit (130), and the payment method may represent an identification value of a payment method selected or pre-registered by the user (e.g., card, mobile phone, account, etc.).

[0100] The payment amount represents the total amount paid for the purchase of the product and can also be used as a reference value to determine whether there is a remaining shortfall by comparing it with the accumulated contribution amount provided by the contribution management module (133). Additionally, the payment amount can be used as a basis for subsequent settlement procedures and the output of payment results on the user terminal (110) or contributor terminal (120), and can function as reference data for the entire payment flow through linkage with the product management module (131) and the contribution management module (133).

[0101] Payment history information generated by the processing module (134) can be transmitted to the user terminal (110) and displayed on the payment completion screen, and at the same time, the contribution flow termination status and payment completion notification can also be delivered to the contributor terminal (120).

[0102] Payment history information is transmitted to an internal operating system or an external payment service integration server linked to subsequent refund, exchange, and delivery procedures, and can form reference data for the entire transaction flow.

[0103] Additionally, the processing module (134) may send a subsequent selection request to the user terminal (110) if the accumulated contribution amount falls short of the target amount at the time the contribution recruitment period expires.

[0104] The subsequent selection request may include a request regarding whether to make an additional payment for the shortfall amount, whether to transfer the contribution amount to another product included in the wishlist, and / or whether to extend the contribution recruitment period, and may be output in the form of a message that induces the user's selection through the user terminal (110).

[0105] For example, options such as “2,000 won is short. Would you like to make an additional payment?”, “Would you like to transfer the contribution to another product?”, or “If you pay 1,000 won, it will be extended for 3 days.” may be displayed on the screen of the user terminal (110) in the form of a button, popup, or dropdown menu, and the user may respond by selecting one or more of these items.

[0106] The selected subsequent input is transmitted from the user terminal (110) to the processing module (134), and the processing module (134) can perform internal condition branching according to each response type.

[0107] A request regarding additional payment for a shortfall amount refers to a request that induces the user to directly pay the shortfall amount to complete the product purchase process when the accumulated contribution amount falls short of the target amount (i.e., the price of the product) of the wishlist at the end of the contribution recruitment period. This request is displayed in the form of an intuitive message through the user terminal (110) and can be structured to induce the user to explicitly input their intention to pay.

[0108] For example, on the user terminal (110), a notification message such as “2,000 won is short. Would you like to make an additional payment?” or “If you pay now, the product will be delivered immediately.” may be displayed in the form of a button, popup, or slide notification.

[0109] When the user selects to pay the insufficient amount according to the instructions, the user's response is transmitted to the processing module (134), and the payment procedure can be performed after configuring the payment conditions in conjunction with the product management module (131) and the contribution management module (133).

[0110] When payment is successfully completed, the processing module (134) can execute the purchase of the product and generate payment history information.

[0111] A request regarding the transfer of a contribution amount to another product included in the wishlist refers to a system request that encourages the transfer and utilization of the contribution to another product within the same wishlist if the accumulated contribution amount has not reached the target amount after the contribution collection period has ended.

[0112] For example, on the user terminal (110), phrases such as “Would you like to transfer the contribution to another product?” or “Try recycling the unused contribution amount.” may be displayed in the form of a button or popup, and the user can directly input the product to be transferred.

[0113] When a user's transfer request is entered, the response is transmitted from the user terminal (110) to the processing module (134), and the processing module (134) can modify the existing contribution history information in conjunction with the contribution management module (133) and re-register the contribution amount to a designated other product.

[0114] In this process, the contribution management module (133) can generate new contribution history information including a contributor identifier, contribution amount, transfer time, target wishlist identifier, etc., and reflect the contribution amount in the cumulative contribution amount of other products.

[0115] A request for an extension of the contribution solicitation period refers to a user request to expand opportunities for contribution participation by further extending the solicitation period under certain conditions after the original period has ended. This request is designed to effectively extend the limited contribution period to encourage the achievement of the target amount.

[0116] For example, on the user terminal (110), phrases such as “If you pay 1,000 won, it will be extended for 3 days,” or “Would you like to extend? The contribution is not yet complete,” may be displayed in the form of a button, popup, or slide, and if the user agrees to the extension request, they can select and enter a payment item.

[0117] When an extension request is entered, the request is transmitted from the user terminal (110) to the processing module (134), and the processing module (134) can execute a payment procedure for the period extension cost after checking the extension conditions (e.g., threshold contribution rate, remaining time, etc.).

[0118] When payment for the period extension cost is successfully completed, the processing module (134) can work in conjunction with the sharing module (132) to update the end time of the contribution recruitment period and create a new contribution recruitment period reflecting the extended end time, which can then be displayed on the contributor terminal (120).

[0119] Additionally, the processing module (134) outputs an extension completion message or a remaining time update result to the user terminal (110) so that the user can check the status in real time.

[0120] Meanwhile, if the processing module (134) does not receive a purchase approval response from the user terminal (110) for a preset period after the contribution recruitment period has expired, it may refund the contribution amount to the contributor terminal (120).

[0121] At this time, the pre-set period may be defined, for example, as 5 days from the end of the contribution recruitment period, and the processing module (134) continuously monitors whether a purchase approval response is transmitted from the user terminal (110) until this period elapses, and if the non-response state is maintained, it may initiate a refund procedure for the contribution amount.

[0122] The process for refunding the contribution amount to the contributor can be performed based on the contributor identifier and payment method information included in the contribution history information, and a user interface including information such as a refund completion message, refund history, and contribution termination notice can be displayed on the contributor terminal (120).

[0123] Through such functions, the processing module (134) can control the end point of the wishlist-based commerce flow and ensure reliable subsequent processing for the user terminal (110) and the contributor terminal (120).

[0124] Meanwhile, the server unit (130) may further include a recommendation module (135) that analyzes product selection history and product payment history information based on a wishlist received from multiple user terminals (110) to select popular products and generates recommended product information based on popular products.

[0125] The recommendation module (135) analyzes the product selection trends of users received from multiple user terminals (110), integrates payment history information to determine the popularity of a specific product, and generates recommended product information, and is electrically connected to the product management module (131), the contribution management module (133), and / or the processing module (134).

[0126] The product selection history refers to the number or frequency with which the same product is included in a wishlist generated from multiple user terminals (110).

[0127] Product selection history can be used as a quantified indicator of user preferences and can be updated in real time based on cumulative figures over a specific period.

[0128] Product selection trends can refer to statistical trend data derived by combining time, user type, category classification, etc., with product selection history.

[0129] For example, if a specific category of product is intensively selected by users of a specific age group, this can be classified as a selection trend by age group, and the recommendation module (135) can recommend the product to similar users based on this trend.

[0130] Popular products are selected based on product selection history and payment history information, and may refer to products that have been included in the wishlist with high frequency from multiple user terminals (110), or products for which the cumulative contribution amount or the number of payment completions for the product has exceeded a preset threshold value.

[0131] The recommendation module (135) selects popular products by comprehensively analyzing product selection history, contribution history, and payment history information, and the popular products can be used as a core basis for recommended product information.

[0132] Recommended product information refers to a result data set generated by the recommendation module (135) by integrating and analyzing the above selection history, selection trends, and payment history information.

[0133] Recommended product information may be popular product recommendation information based on quantitative priority, generated by the recommendation module (135) by integrating and analyzing product selection history, selection trends, and payment history information for the purpose of inducing interest of users or contributors and activating contribution flows.

[0134] Recommended product information may be composed of information blocks that include selection criteria and grounds for recommendation for popular products, and may be displayed on the screen of a user terminal (110) and / or a contributor terminal (120) and used as a content component on an interface.

[0135] The recommendation module (135) can induce active participation in the contribution-based commerce system by performing an auxiliary role of inducing the creation of a wishlist on the user terminal (110) based on recommended product information or inducing contribution participation on the contributor terminal (120).

[0136] For example, recommended product information may include product images, product names, brief descriptions, reasons for recommendation (e.g., “Most selected products,” “Recently paid for”), current attribution progress (e.g., 85% of target amount attributable), and may be composed of user-customized sections (e.g., “Most popular products right now,” “Recently paid products,” “Recommendations based on my interests”).

[0137] Recommended product information is linked with the product management module (131), contribution management module (133), processing module (134), etc. of the server unit (130) to reflect real-time data flow and can be utilized as a key output element for expanding participation and increasing inflow of the contribution-based user-driven commerce system.

[0138] As described above, according to the contribution-based user-driven commerce system (100) of an embodiment of the present invention, a wishlist is created centered on a product selected by the user, and the amount is distributedly contributed by multiple contributors by sharing it with acquaintances. Then, the payment decision is automatically determined based on the accumulation of the contributed amount, and the purchase is processed. This has the effect of reducing the dropout problem that frequently occurs in existing shopping cart-based commerce structures and improving the payment conversion rate.

[0139] In addition, since various follow-up options are provided for users even if the contribution amount does not reach the target amount, the user participation flow can continue flexibly without interruption, and it is effective in being suitable for practical consumption scenarios such as joint gifting or cost-sharing purchases.

[0141] Although all components constituting the embodiments of the present invention have been described above as being combined or operating in combination, the present invention is not necessarily limited to such embodiments. That is, within the scope of the purpose of the present invention, all components may be selectively combined in one or more ways to operate.

[0142] Furthermore, terms such as "include," "compose," or "have" described above, unless specifically stated otherwise, mean that the relevant component may be inherent; therefore, they should be interpreted as allowing for the inclusion of additional components rather than excluding them. All terms, including technical or scientific terms, have the same meaning as generally understood by those skilled in the art to which the present invention pertains, unless otherwise defined. Commonly used terms, such as those defined in advance, should be interpreted in accordance with their meaning in the context of the relevant technology and should not be interpreted in an ideal or overly formal sense unless explicitly defined in the present invention.

[0143] Furthermore, the above description is merely an illustrative explanation of the technical concept of the present invention, and those skilled in the art to which the present invention pertains will be able to make various modifications and variations within the scope of the essential characteristics of the present invention.

[0144] Accordingly, the embodiments disclosed in this invention are intended to illustrate, not limit, the technical concept of the invention, and the scope of the technical concept of the invention is not limited by these embodiments. The scope of protection of this invention shall be interpreted by the claims below, and all technical concepts within an equivalent scope shall be interpreted as being included within the scope of rights of this invention. Explanation of the symbols

[0145] 100: Contribution-based user-driven commerce system according to an embodiment of the present invention 110: User terminal 120: Contributor Terminal 130: Server section 131: Product Management Module 132: Shared Module 133: Contribution Management Module 134: Processing Module 135: Recommendation Module

Claims

Claim 1 The system includes a user terminal; a contributor terminal; and a server unit that receives a wishlist, which is a list of products selected by the user from the user terminal, and receives a contribution amount, which is an amount for purchasing the products, from the contributor terminal to perform the purchase of the products. The server unit includes: a product management module that stores and manages product information including the product name, price, stock, and product description of the products included in the wishlist; a sharing module that creates a contribution collection period, which is a period for collecting the contribution amount based on the wishlist, and transmits the wishlist and the contribution collection period to the contributor terminal; a contribution management module that stores the contribution amount received from the contributor terminal and generates contribution history information; and a processing module that, when the total sum of the contribution amounts satisfies the price of the products, receives a purchase approval response from the user terminal to perform the purchase of the products and generates payment history information. The contribution management module calculates a cumulative contribution amount by summing the contribution amounts collected within the contribution collection period, calculates a contribution progress rate, which is the ratio of the cumulative contribution amount to the price of the products, and [transmits] the contribution progress rate to the user terminal and the contributor The processing module transmits to the terminal to provide the contribution status for the wishlist, and if the accumulated contribution amount is less than the price of the product at the time the contribution recruitment period expires, the processing module transmits a selection request to the user terminal regarding whether to make an additional payment for the shortfall amount or whether to transfer the contribution amount to another product included in the wishlist. If the accumulated contribution amount is greater than or equal to a preset threshold, the method further transmits to the user terminal whether to extend the contribution recruitment period; if a response regarding additional payment for the insufficient amount is received from the user terminal, the method performs the purchase of the product and generates the payment history information; if a response regarding the transfer of the contribution amount is received from the user terminal, the method transfers the contribution amount to other products included in the wishlist and updates the contribution history information; if a response regarding the extension of the contribution recruitment period is received from the user terminal, the method executes a payment procedure for the period extension cost and updates the end time of the contribution recruitment period; if a purchase approval response is not received for a preset period after the contribution recruitment period has expired, the method initiates a refund procedure for the contribution amount based on the contributor identifier and payment method information included in the contribution history information and transmits the contribution amount to the contributor terminal; and the sharing module blocks requests for the creation and sharing of a new wishlist if the accumulated contribution amount is less than the price of the product, and if the accumulated contribution amount reaches the price of the product, the method transmits the contribution amount and the contribution recruitment period A contribution-based user-driven commerce system that blocks extensions and changes to products within the aforementioned wishlist and terminates the aforementioned contribution recruitment period. Claim 2 delete Claim 3 delete Claim 4 delete Claim 5 A contribution-based user-driven commerce system according to claim 1, wherein the server unit further comprises a recommendation module that selects popular products by analyzing the selection history and payment history information of the products based on the wishlist received from a plurality of user terminals, and generates recommended product information based on the popular products.

Images