WO2025005332A1 - 결제 서비스 제공 방법 및 그 시스템 - Google Patents

결제 서비스 제공 방법 및 그 시스템 Download PDF

Info

Publication number
WO2025005332A1
WO2025005332A1 PCT/KR2023/009494 KR2023009494W WO2025005332A1 WO 2025005332 A1 WO2025005332 A1 WO 2025005332A1 KR 2023009494 W KR2023009494 W KR 2023009494W WO 2025005332 A1 WO2025005332 A1 WO 2025005332A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
payment method
purchase
user
amount
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/KR2023/009494
Other languages
English (en)
French (fr)
Inventor
홍성민
김상률
임병후
문인주
최제헌
이승열
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Coupang Corp
Original Assignee
Coupang Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Coupang Corp filed Critical Coupang Corp
Publication of WO2025005332A1 publication Critical patent/WO2025005332A1/ko
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/14—Payment architectures specially adapted for billing systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/04—Architecture, e.g. interconnection topology
    • G06N3/045—Combinations of networks
    • G06N3/0455—Auto-encoder networks; Encoder-decoder networks
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/227—Payment schemes or models characterised in that multiple accounts are available, e.g. to the payer
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/387—Payment using discounts or coupons
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207—Discounts or incentives, e.g. coupons or rebates
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207—Discounts or incentives, e.g. coupons or rebates
    • G06Q30/0222—During e-commerce, i.e. online transactions
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207—Discounts or incentives, e.g. coupons or rebates
    • G06Q30/0235—Discounts or incentives, e.g. coupons or rebates constrained by time limit or expiration date

Definitions

  • the present disclosure relates to a method for providing a payment service and a system thereof.
  • discount benefits vary depending on the payment method
  • the discount amount may vary depending on the payment method.
  • a technical problem to be solved through some embodiments of the present disclosure is to provide a method and a system for performing the method that can further improve user convenience regarding payment method selection.
  • Another technical problem to be solved by some embodiments of the present disclosure is to provide a method and a system for performing the method, which can prevent a user from unintentionally missing out on payment benefits.
  • Another technical problem to be solved through some embodiments of the present disclosure is to provide a method capable of providing a payment function using multiple payment methods for a single product purchase (so-called 'composite/split/mixed payment' function) and a system for performing the method.
  • a method for providing a payment service is provided, which is performed in at least one computing device, and may include the steps of: receiving a purchase request for at least one product from a user's terminal; acquiring payment method-related information of the user in response to the purchase request, wherein the payment method-related information includes priorities of a plurality of pre-registered payment methods and the priorities are set by the user; acquiring payment benefit information for at least some of the plurality of payment methods; calculating a benefit amount for each of the plurality of payment methods based on the payment benefit information; and determining a purchase payment method for the at least one product from among the plurality of payment methods based on the benefit amount and the priorities.
  • the payment benefit information may include payment benefit information provided by a business operator of an e-commerce service for the at least one product and payment benefit information provided by a business operator of a payment method.
  • the payment benefit information may include payment benefit information according to day of the week, date, and time.
  • the step of determining a purchase payment method for the at least one product may include a step of determining the purchase payment method according to the maximum benefit amount based on a determination that the maximum benefit amount for the plurality of payment methods is greater than or equal to a reference value.
  • the step of determining a purchase payment method for the at least one product may include the step of determining the purchase payment method according to the priority based on a determination that the maximum benefit amount for the plurality of payment methods is less than a threshold value.
  • the payment method related information includes a remaining limit amount calculated based on a payment limit amount set by the user
  • the step of determining the purchase payment method according to the priority may include a step of determining the purchase payment method further based on the remaining limit amounts of the plurality of payment methods.
  • the method further comprises providing a payment interface in which the determined purchase payment method is selected, wherein the payment interface may include an interface for receiving an additional purchase payment method from the user.
  • the method further comprises providing a payment interface in which the determined purchase payment method is selected, wherein the payment interface may include an interface for registering a combination of two or more payment methods from the user or for retrieving a combination of previously registered payment methods based on an input from the user.
  • the payment method-related information includes a performance shortfall amount for each of the plurality of payment methods
  • the payment service providing method may further include a step of determining another purchase payment method among the plurality of payment methods based on the performance shortfall amount.
  • the payment method-related information includes a performance shortfall amount for each of the plurality of payment methods
  • the determined purchase payment method includes a first payment method and a second payment method
  • the payment service providing method may further include a step of determining a payment amount for each of the first payment method and the second payment method based on the performance shortfall amount.
  • a payment service providing system may include a memory storing one or more processors and a computer program executed by the one or more processors, wherein the computer program may include instructions for receiving a purchase request for at least one product from a user's terminal, receiving, in response to the purchase request, payment method-related information of the user, wherein the payment method-related information includes priorities of a plurality of pre-registered payment methods and the priorities are set by the user, obtaining payment benefit information for at least some of the plurality of payment methods, calculating a benefit amount for each of the plurality of payment methods based on the payment benefit information, and determining a purchase payment method for the at least one product among the plurality of payment methods based on the benefit amount and the priorities.
  • a computer program may be stored in a computer-readable recording medium, coupled with a computing device, to execute the steps of: receiving a purchase request for at least one product from a user's terminal; acquiring payment method-related information of the user in response to the purchase request, wherein the payment method-related information includes priorities of a plurality of pre-registered payment methods and the priorities are set by the user; acquiring payment benefit information for at least some of the plurality of payment methods; calculating a benefit amount for each of the plurality of payment methods based on the payment benefit information; and determining a purchase payment method for the at least one product from among the plurality of payment methods based on the benefit amount and the priorities.
  • a payment method i.e., a purchase payment method
  • a payment method to be used for purchasing a product
  • the inconvenience of the user having to carefully select a payment method while considering the payment benefit when purchasing a product can be eliminated.
  • the problem of the user unintentionally missing the payment benefit because he or she is not aware of the benefits of some payment methods can also be solved. Accordingly, the user's satisfaction with the e-commerce service and payment service can be greatly improved.
  • the purchase payment method may be determined based on the priority and payment limit amount set by the user for the previously registered payment methods. In this case, the purchase payment method may be determined by faithfully reflecting the user's explicit intention (e.g., preference for payment method, payment method usage plan).
  • the purchase payment method can be determined based on the insufficient performance amount of the previously registered payment methods. In this case, since the possibility of the payment method achieving performance increases (i.e., the possibility of receiving benefits according to performance achievement increases), the user satisfaction with the e-commerce service and payment service can be further improved.
  • a function for using multiple payment methods for the purchase of a single product may be provided to the user.
  • the user can freely use multiple payment methods to purchase the product, and thus the user's satisfaction with the e-commerce service and payment service can be further improved.
  • a user's purchase payment method can be determined using a deep learning model that has learned payment history data of a large number of users (e.g., user information, product information, payment method information, etc.). Since the learned deep learning model can comprehensively consider the product characteristics, user type, etc. to predict the user's preferred payment method, in this case, the user's preferred payment method can be accurately determined as the purchase payment method.
  • a deep learning model that has learned payment history data of a large number of users (e.g., user information, product information, payment method information, etc.). Since the learned deep learning model can comprehensively consider the product characteristics, user type, etc. to predict the user's preferred payment method, in this case, the user's preferred payment method can be accurately determined as the purchase payment method.
  • FIG. 1 is an exemplary configuration diagram for explaining a payment service providing system according to some embodiments of the present disclosure.
  • FIG. 2 is an exemplary flowchart illustrating a method for providing a payment service according to some embodiments of the present disclosure.
  • Figure 3 is an exemplary flowchart showing the detailed process of the benefit amount calculation step illustrated in Figure 2.
  • FIG. 4 illustrates a payment interface according to some embodiments of the present disclosure.
  • FIG. 5 illustrates a payment interface according to some other embodiments of the present disclosure.
  • FIG. 6 is an exemplary flowchart illustrating a method for providing a payment service according to some other embodiments of the present disclosure.
  • FIG. 7 is an exemplary flowchart illustrating a method for providing a payment service according to some further embodiments of the present disclosure.
  • FIG. 8 is an exemplary flowchart illustrating a method for providing a payment service according to some further embodiments of the present disclosure.
  • FIGS. 9 and 10 are exemplary diagrams for explaining input/output, structure, and learning methods of a deep learning model according to some embodiments of the present disclosure.
  • FIG. 11 is an exemplary flowchart illustrating a method for providing a payment service according to some further embodiments of the present disclosure.
  • FIG. 12 illustrates an exemplary computing device that can implement a payment service providing system according to some embodiments of the present disclosure.
  • FIG. 1 is an exemplary configuration diagram for explaining a payment service providing system (10) according to some embodiments of the present disclosure.
  • the payment service providing system (10) is a computing system that provides a payment service for e-commerce, and may be configured to include a service server (11) and a payment server (12).
  • the payment service providing system (10) may be named an 'e-commerce (or shopping, etc.) service providing system', and one of the service server (11) and the payment server (12) may be called a 'payment service providing system'.
  • the payment service providing system (10) will be abbreviated as 'service system (10)'.
  • the service server (11) is a computing device/system that provides e-commerce (or shopping, etc.) services for various products.
  • the service server (11) can provide e-commerce services for various products through a web and/or app interface, and a user can use the e-commerce service through a web browser and/or app installed on a terminal (13).
  • the service server (11) can store and manage various information/data related to e-commerce services (e.g., information/data on products, users, payment methods registered by users, payment benefits, purchase/payment history, etc.) in a storage. Examples of such information/data will be described later.
  • e-commerce services e.g., information/data on products, users, payment methods registered by users, payment benefits, purchase/payment history, etc.
  • the service server (11) can automatically determine (e.g., recommend) a payment method for a purchased product in various ways and can also provide a payment function using multiple payment methods (so-called 'composite/split/mixed payment' function). By doing so, the convenience and satisfaction of users using e-commerce and payment services can be improved, which will be described in detail with reference to drawings such as FIG. 2 and below.
  • the payment server (12) is a computing device/system that is in charge of payment processing (or approval) functions.
  • the payment server (12) may receive a payment request based on a specific payment method from the service server (11) and, in response, perform payment processing (e.g., approval) with the requested payment method.
  • the payment server (12) may collectively refer to a plurality of payment servers that are in charge of payment processing functions for different payment methods.
  • the payment server (12) may include a first payment server that is in charge of payment processing functions for a first payment method and a second payment server that is in charge of payment processing functions for a second payment method.
  • the payment server (12) can store and manage various information/data (e.g., payment benefits, payment amount, performance amount, performance deficiency amount, payment history, etc.) related to payment method, payment processing, etc. in a storage.
  • the payment server (12) can also provide specific information/data to the service server (11) at the request of the service server (11).
  • the above-described service server (11) and payment server (12) may be implemented in at least one computing device.
  • all functions of the service server (11) may be implemented in one computing device, or the first function of the service server (11) may be implemented in the first computing device and the second function may be implemented in the second computing device.
  • a specific function of the service server (11) may be implemented in a plurality of computing devices.
  • a computing device may include any device having computing capabilities, and for an example of such a device, see FIG. 12. Since a computing device is a collection of interacting components (e.g., memory, processor, etc.), it may sometimes be called a 'computing system'. Of course, the term computing system may also encompass the concept of a collection of interacting computing devices.
  • a computing device is a collection of interacting components (e.g., memory, processor, etc.), it may sometimes be called a 'computing system'.
  • the term computing system may also encompass the concept of a collection of interacting computing devices.
  • the user terminal (13) is a computing device (e.g., mobile computing device, fixed computing device) of a user who uses an e-commerce service.
  • the user terminal (13) may be implemented as any computing device.
  • Users can access the site of an e-commerce service through a terminal (13) to purchase products and can also register frequently used payment methods in advance. Users can also register a combination of two or more payment methods through a terminal (13).
  • the service system (10) and the user terminal (13) can communicate via a network.
  • the network can be implemented as any type of wired/wireless network, such as a local area network (LAN), a wide area network (WAN), a mobile radio communication network, Wibro (Wireless Broadband Internet), etc.
  • LAN local area network
  • WAN wide area network
  • Wibro Wireless Broadband Internet
  • FIG. 2 is an exemplary flowchart illustrating a method for providing a payment service according to some embodiments of the present disclosure.
  • the present embodiments relate to a method for automatically determining a purchase payment method (i.e., a payment method to be used for a purchase) based on payment benefit information.
  • the present embodiments may start with step S21 of receiving a purchase request for at least one product from a user's terminal. For example, when a user clicks a purchase button on a shopping cart page or a product page, the user terminal (13) may transmit a purchase request to the service server (11). At least one product may mean a product subject to payment that belongs to one purchase (e.g., a product in a shopping cart, etc.).
  • step S22 information related to the user's payment method (i.e., information related to previously registered payment methods) may be acquired.
  • the service server (11) may obtain information on payment methods previously registered by the user by searching the storage (e.g., searching with the user's ID, etc.) or may obtain information on payment methods (e.g., insufficient performance amount, etc.) from the payment server (12).
  • the method by which the service server (11) acquires information related to payment methods may be any method.
  • the user's payment method may mean a payment method previously registered by the user with the service server (11).
  • Payment method-related information may include, but is not limited to, the type (category) of the payment method (e.g., rechargeable payment methods such as PayMoney, cards, accounts, simple payments, etc.), the priority of the payment method set by the user, the limit amount of the payment method set by the user (e.g., monthly limit amount), the remaining limit amount (e.g., monthly limit amount - payment (usage) amount for the corresponding month), the payment amount (e.g., payment amount by payment method, total payment amount, etc.), the recharge amount (e.g., PayMoney amount), the performance amount (e.g., the monthly performance amount that must be achieved to receive card benefits), the performance deficiency amount (e.g., monthly performance amount - payment (usage) amount for the corresponding month), etc.
  • the type (category) of the payment method e.g., rechargeable payment methods such as PayMoney, cards, accounts, simple payments, etc.
  • the priority of the payment method set by the user e.
  • step S23 payment benefit information for previously registered payment methods can be obtained.
  • the service server (11) may obtain payment benefit information applicable to a specific payment method from the payment server (12) or may obtain benefit information for a specific payment method by searching information on the Internet.
  • the service server (11) may obtain payment benefit information provided by the business operator of the service server (11) by searching a storage, a product page, etc.
  • the method by which the service server (11) obtains payment benefit information may be any method.
  • the service server (11) may obtain payment benefit information for other payment methods in addition to the user's previously registered payment methods.
  • Payment benefit information may include, without limitation, information on various economic benefits that can be obtained through payment, such as discounts (e.g., product price discounts, billing discounts on payment amounts), cashbacks, point (or pay money) accumulation, coupon issuance, etc.
  • discounts e.g., product price discounts, billing discounts on payment amounts
  • cashbacks e.g., point (or pay money) accumulation
  • coupon issuance e.g., coupon issuance, etc.
  • the payment benefit information may include, for example, first payment benefit information provided by a business operator of an e-commerce service (i.e., a business operator of a service server (11)) and second payment benefit information provided by a business operator of a payment method (i.e., a business operator of a payment server (12)).
  • the first payment benefit information may include, but is not limited to, information such as benefits applicable to specific products (e.g., products in a specific category), benefits provided only to membership subscribers (e.g., discount benefits when paying with a specific payment method), and event-related benefits provided for a certain period of time.
  • benefits applicable to specific products e.g., products in a specific category
  • benefits provided only to membership subscribers e.g., discount benefits when paying with a specific payment method
  • event-related benefits provided for a certain period of time.
  • the second payment benefit information may include, but is not limited to, payment benefit information based on day of the week, date, and time (e.g., discount benefits provided when making payments on a specific day of the week, date, or time).
  • a benefit amount for each of the pre-registered payment methods can be calculated based on the payment benefit information.
  • the benefit amount may be, for example, a discount amount, a cashback amount, an amount corresponding to accumulated points, etc., but is not limited thereto.
  • the service server (11) can calculate a day discount amount for a card among the user's registered cards that provides a discount benefit on the current day of the week (S31, S32), and can similarly calculate corresponding discount amounts (e.g., time discount amount, date discount amount, product discount amount) for other cards (see S33 to S38).
  • corresponding discount amounts e.g., time discount amount, date discount amount, product discount amount
  • a purchase payment method for at least one product may be determined based on the benefit amount.
  • the service server (11) may determine at least one payment method providing the maximum benefit amount as the purchase payment method.
  • the maximum benefit amount may mean the maximum benefit amount calculated by considering whether benefits can be duplicated (summed). For example, if the first card provides a '10%' discount benefit for a monitor worth '500,000 won' in the shopping cart, and the second card provides a '5%' discount benefit for a '1,000,000 won' laptop, and if the two discount benefits can be applied in duplicate, the maximum benefit amount may be calculated as '100,000 won'. In this case, the first card and the second card may be determined together as the purchase payment method, and the payment amounts of the first card and the second card may also be determined according to the maximum benefit amount.
  • the purchase payment method can be provided (e.g., recommended) to the user through a payment interface placed on a payment page (e.g., checkout page).
  • a payment interface e.g., 41 of FIG. 4
  • the service server (11) can also provide the user with the purchase payment method through a separate interface (e.g., a payment method recommendation interface in the form of a pop-up).
  • the payment interface may be configured to allow selection of multiple payment methods in order to provide a composite payment function.
  • examples of such payment interfaces i.e., user interfaces for payment
  • FIGS. 4 and 5 will be briefly described with reference to FIGS. 4 and 5.
  • FIG. 4 illustrates a payment interface (40) according to some embodiments of the present disclosure.
  • the payment interface (40) may include a payment method selection interface (41, 43) and a payment amount input interface (42, 44).
  • the payment method selection interface (e.g., 41) may be implemented as a drop-down list having the user's previously registered payment methods as selectable items, for example, but the scope of the present disclosure is not limited thereto.
  • the payment interface (40) may further include an interface (45, e.g., button) for adding a payment method.
  • an interface for selecting an additional payment method may be further displayed within the payment interface (40) (e.g., the illustrated interface (43, 44) may be added by such user input).
  • the initial value (i.e., the payment amount) of the payment amount interface (42, 44) may be set automatically.
  • the initial value of the payment amount interface (42, 44) may be set to an amount obtained by dividing the total payment amount by the number of selected (to be) payment methods (i.e., an equal division amount).
  • the initial value of the payment amount interface (42, 44) may be set to the amount of the corresponding individual product (e.g., if the number of current payment methods becomes the same as the number of products due to the addition of a payment method, the setting value may be changed from the equal division amount to the amount of the individual product).
  • FIG. 5 illustrates a payment interface (50) according to some other embodiments of the present disclosure.
  • the payment interface (50) is designed in consideration of user input based on mobile gestures, and may be configured to include a first area (51) and a second area (52).
  • selected payment methods (53, 55) and a payment amount input interface (54, 56) may be displayed (located) in the first area (51), and the user's previously registered payment methods (57 to 59) may be displayed (located) in the second area (52).
  • the selected payment method e.g., 55
  • a corresponding payment amount interface e.g., 56
  • the specific payment method e.g., 55
  • a corresponding payment amount interface e.g., 56
  • the payment interface may include (provide) an interface for registering a combination of two or more payment methods or for calling up a combination of pre-registered payment methods based on user input.
  • a user may pre-register a combination of frequently used payment methods (e.g., 'PayMoney' and 'a specific card') and quickly select multiple payment methods to be used for a purchased product by calling up the combination in the payment interface.
  • frequently used payment methods e.g., 'PayMoney' and 'a specific card'
  • a payment service providing method has been described with reference to FIGS. 2 to 5.
  • a payment method i.e., a purchase payment method
  • a payment method to be used for purchasing a product can be automatically determined based on payment benefit information of the user's pre-registered payment methods.
  • the inconvenience of the user having to carefully select a payment method by considering the payment benefit when purchasing a product can be resolved.
  • the problem of the user not recognizing the payment benefits of some payment methods and thus missing the payment benefits can also be resolved. Accordingly, the user's satisfaction with the e-commerce service and payment service can be greatly improved.
  • the present embodiments relate to a method for determining a purchase payment method based on the priority of the payment method and the remaining limit amount.
  • the priority and payment limit amount e.g., monthly payment limit
  • the user can set the priority and payment limit amount of the first card and the second card, respectively, as (1st priority, 100,000 won) and (2nd priority, 50,000 won)
  • the remaining limit amount can be calculated based on the payment limit amount.
  • the present embodiments may also start with step S61 of receiving a purchase request for at least one product. For this, refer further to the description of step S21 described above.
  • step S62 information related to the user's payment method can be obtained.
  • the payment method related information can include the priority of the payment method set by the user and the remaining limit amount.
  • step S22 refer to the description of step S22 described above.
  • step S63 a purchase payment method for at least one product can be determined based on the priority and the remaining limit amount.
  • the purchase payment method thus determined can be provided to the user through a payment interface, and for this, refer to the description of step S25, FIG. 4, and FIG. 5 described above.
  • the service server (11) can determine the first payment method as the purchase payment method.
  • the service server (11) may determine the first payment method and the second payment method (i.e., the payment method with the next priority) as the purchase payment methods.
  • the payment amount of the second payment method may be, for example, a value that is a limit value of the remaining limit amount of the first payment method from the total payment amount, but the scope of the present disclosure is not limited thereto.
  • a payment service providing method can be determined by faithfully reflecting a user's explicit intention (e.g., preference for a payment method, payment method usage plan).
  • the present embodiments relate to a method for determining a purchase payment method based on a performance shortfall amount of the payment method.
  • the present embodiments may also start with step S71 of receiving a purchase request for at least one product. For this, refer further to the description of step S21 described above.
  • step S72 information related to the user's payment method can be obtained.
  • the payment method-related information can include the insufficient performance amount of the previously registered payment methods.
  • step S22 refer to the description of step S22 described above.
  • a purchase payment method for at least one product may be determined based on the performance shortage amount.
  • the service server (11) may determine a payment method among the pre-registered payment methods whose performance shortage amount is greater than or equal to a standard (e.g., a payment method with the highest performance shortage amount, multiple payment methods with performance shortage amounts greater than or equal to a standard) as a purchase payment method.
  • the purchase payment method determined in this way may be provided to the user through a payment interface; for this, refer to the descriptions of step S25, FIG. 4, and FIG. 5 described above.
  • the payment amount of each payment method may be determined based on the performance shortfall amount.
  • the service server (11) may determine the payment amount of each of the first payment method and the second payment method based on the performance shortfall amounts of each of the first payment method and the second payment method.
  • the scope of the present disclosure is not limited thereto.
  • the present embodiments relate to a method for determining a purchase payment method using a deep learning model.
  • the present embodiments may start at step S81 of obtaining a deep learning model trained using payment history data of a plurality of users.
  • step S81 of obtaining a deep learning model trained using payment history data of a plurality of users.
  • FIG. 9 illustrates input and output of a deep learning model (90) according to some embodiments of the present disclosure.
  • the deep learning model (90) may be configured to receive user information, context information, product information, etc., and output (predict) a confidence score (i.e., probability value) for each payment method.
  • the deep learning model (90) may be configured to further receive information (e.g., ID, name, type, payment amount, etc.) of the N-1th (where N is a value greater than or equal to 1) payment method, and output a confidence score for the Nth payment method.
  • the deep learning model (90) may be configured to further output a confidence score for each type of payment method, or may be configured to receive only some of the information exemplified in FIG. 9.
  • User information may include, but is not limited to, demographic information such as gender, age group, membership subscription, etc. If such user information is explicitly given, a deep learning model (90) can be trained to predict a payment method by considering the type (or characteristics) of the user.
  • demographic information such as gender, age group, membership subscription, etc.
  • context information may include, for example, general context information and payment context information.
  • General context information may include, but is not limited to, the time of payment, day of the week, type of user terminal (e.g., mobile terminal, fixed terminal, etc.). If such general context information is explicitly given, the deep learning model (90) can be trained to predict a payment method by taking into account the user's current context.
  • Payment context information may include, but is not limited to, for example, the amount charged to PayMoney (i.e., rechargeable payment method), the account amount, information on payment methods used for previous purchases (e.g., payment method, type of payment method, etc.), information related to previously registered payment methods (e.g., number, priority, remaining limit amount, insufficient performance amount, benefit amount, etc.). If such payment context information is explicitly given, the deep learning model (90) can be trained to predict the payment method by considering the context related to the user's previously registered payment method.
  • the deep learning model (90) can be trained to predict the payment method by considering the context related to the user's previously registered payment method.
  • product information may include, but is not limited to, information such as product ID, name, category, price, and options. If such product information is explicitly given, a deep learning model (90) can be trained to predict a payment method by considering the characteristics of the purchased product.
  • a deep learning model (90) may be configured to include embeddings (101 to 104), an encoder (105), and predictors (106, 107).
  • the number of embeddings (101 to 104) and predictors (106, 107) may vary depending on the case.
  • Embedders (101 to 104) can generate embeddings (e.g., embedding vectors) for input information.
  • the first embedding (101) can generate embeddings for user information
  • the fourth embedding (104) can generate embeddings for product information.
  • Each of the embeddings (101 to 104) may be implemented based on a neural network such as a multi-layer perceptron (MLP), but the scope of the present disclosure is not limited thereto.
  • MLP multi-layer perceptron
  • the encoder (105) can encode the embeddings generated by the embeddings (101 to 104).
  • the encoder (105) can be implemented based on an attention module and an MLP, but the scope of the present disclosure is not limited thereto.
  • the predictors (106, 107) can perform a predetermined task based on the encoding result (i.e., the output of the encoder (105)). As a result, a confidence score for the task can be output.
  • Each of the predictors (106, 107) can be implemented based on a neural network such as a fully-connected layer, but the scope of the present disclosure is not limited thereto.
  • the first predictor (106) may be configured to output (predict) a confidence score for each type of payment method based on the encoding result
  • the second predictor (107) may be configured to output (predict) a confidence score for each payment method based on the encoding result.
  • the type of payment method refers to a category (or group) to which payment methods having the same or similar characteristics belong.
  • the second predictor (107) may be understood to be different from the first predictor (106) in that it performs a prediction by classifying each individual payment method into different classes (e.g., the second predictor (107) classifies 'card 1' and 'card 2' into different classes, but the first predictor (106) classifies 'card 1' and 'card 2' into the same class).
  • the predictors (106, 107) may be configured to further receive information on an (N-1)th (where N is a value greater than or equal to 1) payment method (i.e., a purchase payment method) and perform predictions related to the Nth payment method (e.g., payment method type prediction, payment method prediction, etc.). For example, if the payment history data includes composite payment samples (i.e., data of a case in which a single product is purchased via composite payment), the predictors (106, 107) may perform a task of predicting the Nth payment method when the N-1th payment method is selected using the composite payment samples.
  • N-1th is a value greater than or equal to 1
  • the predictors (106, 107) may perform a task of predicting the Nth payment method when the N-1th payment method is selected using the composite payment samples.
  • the above-described deep learning model (90) can be learned by performing various tasks using payment history data.
  • the payment history data may include user information (i.e., learning user information), product information, context information, and payment method information as illustrated in Fig. 9, and at least a portion of the payment method information may be used as label information for learning.
  • the deep learning model (90) may be trained by performing a first task of predicting the type of payment method (or the Nth payment method) through the first predictor (106).
  • the deep learning model (90) may be trained by performing a second task of predicting the payment method (or the Nth payment method) through the second predictor (107).
  • the deep learning model (90) may also be trained by performing the first task and the second task together.
  • the deep learning model (90) may be configured to further include a third predictor (not shown).
  • the third predictor (not shown) is a neural network that predicts the number of payment methods used for purchasing a single product, and may be, for example, a classifier that predicts whether the number of payment methods is multiple.
  • the deep learning model (90) may be trained by further performing a third task of predicting the number of payment methods (e.g., predicting whether a complex payment is made) through the third predictor (not shown).
  • the deep learning model (90) may be trained using only data (samples) in which the maximum benefit amount is less than a reference value in the payment history data so that the deep learning model (90) can learn the payment method preference of users with the minimum influence of the benefit amount.
  • the deep learning model (90) may be trained in a manner of varying the sample weights (or learning strengths) by considering the maximum benefit amount and the payment method used for the actual purchase (e.g., training is performed with the first weight for samples in which the maximum benefit amount is less than the reference value, training is performed with the second weight higher than the first weight for samples in which the maximum benefit amount is greater than the reference value but the payment method related to the benefit was not used as the payment method for purchase, training is performed with the third weight lower than the first weight for samples in which the maximum benefit amount is greater than the reference value and the payment method related to the benefit was used as the payment method for purchase, etc.).
  • step S82 a purchase request for at least one product may be received from the user's terminal. For this, refer to the description of step S21 described above.
  • step S83 information constituting the input of the deep learning model can be acquired.
  • the service server (11) can acquire user information, information on a product requested for purchase, user's current context information (e.g., general context, payment context), etc. If necessary, the service server (11) can additionally acquire information that does not constitute the input of the deep learning model (e.g., some of the information related to previously registered payment methods).
  • the acquired information can be input into the learned deep learning model to perform prediction on the payment method.
  • the service server (11) can input the information exemplified above (see FIG. 9) into the learned deep learning model (90) to predict the type of payment method, the payment method, the number of payment methods, etc.
  • Such prediction can be performed through corresponding predictors (e.g., 106, 107), and for this, refer to FIG. 10 and the description below.
  • step S85 a purchase payment method for at least one product can be determined based on the prediction result.
  • the purchase payment method thus determined can be provided to the user through a payment interface.
  • the service server (11) can predict the type of payment method through the first predictor (106) of the learned deep learning model (90). Then, the service server (11) can determine a payment method belonging to the predicted type (e.g., a type with a confidence score higher than a standard value) among a plurality of pre-registered payment methods as a purchase payment method.
  • a payment method belonging to the predicted type e.g., a type with a confidence score higher than a standard value
  • the service server (11) can predict a payment method through the second predictor (107) of the learned deep learning model (90). Then, if there is a predicted payment method (e.g., a payment method with a confidence score higher than a reference value) among the multiple payment methods already registered, the service server (11) can determine the predicted payment method as a purchase payment method. If there is no predicted payment method among the multiple payment methods already registered, the service server (11) can predict the type of payment method through the first predictor (106) of the learned deep learning model (90) and determine a payment method belonging to the predicted type as a purchase payment method. Alternatively, the service server (11) can determine the purchase payment method in another manner (e.g., a manner exemplified in FIGS. 2 to 7, etc.).
  • a predicted payment method e.g., a payment method with a confidence score higher than a reference value
  • the service server (11) can determine the predicted payment method as a purchase payment method. If there is no predicted payment method among the multiple payment methods already registered, the service
  • the service server (11) can predict the number of payment methods through the third predictor (not shown) of the learned deep learning model (90). In addition, when the number of predicted payment methods is plural, the service server (11) can perform prediction related to the Nth payment method by further inputting information of the (N-1)th payment method into the learned deep learning model (90). In addition, the service server (110) can determine the purchase payment method based on the prediction result. As a more specific example, the service server (11) can predict the first payment method by further inputting information indicating that it is the first payment method prediction (e.g., a null vector, a vector having a predefined value) into the second predictor (107).
  • the first payment method prediction e.g., a null vector, a vector having a predefined value
  • the service server (11) can predict the second payment method by further inputting information of the first payment method into the second predictor (107). This prediction process can be repeated a number of times predicted by a third predictor (not shown) or a preset number of times, and the predicted payment methods can be determined as the purchase payment methods. As another example, if the first purchase payment method is determined in another manner (e.g., user selection, a manner exemplified in FIGS. 2 to 7, etc.), the service server (11) can further input information on the first purchase payment method into the predictors (106, 107) to perform a prediction on the second purchase payment method.
  • the predictors e.g., 107
  • the payment amount of each payment method may be determined based on the confidence score of each payment method.
  • the service server (11) may determine payment methods with a confidence score higher than a reference value as purchase payment methods and determine the payment amount of each payment method according to the ratio of the confidence scores of the payment methods (i.e., the payment amount of each payment method is determined in proportion to the confidence score).
  • a payment service providing method has been described with reference to FIGS. 8 to 10.
  • a user's purchase payment method can be determined by using a deep learning model (90) that has learned payment history data (e.g., user information, product information, payment method information, etc.) of a plurality of users. Since the learned deep learning model (90) can predict the preferred payment method of the user by comprehensively considering the characteristics of the product, the type of the user, etc., in this case, the preferred payment method of the user can be accurately determined as the purchase payment method.
  • the service server (11) (or service system (10)) can provide a payment service based on various combinations of the above-described embodiments.
  • the service server (11) may determine a purchase payment method for at least one product based on the priority, remaining limit amount, and benefit amount of the user's pre-registered payment methods in response to a purchase request from the user terminal (13) (S111 to S117). Specifically, the service server (11) may determine a purchase payment method according to the maximum benefit amount based on a judgment that the maximum benefit amount is greater than or equal to a reference value (S115, S116), and may determine a purchase payment method according to the priority and remaining limit amount based on a judgment that the maximum benefit amount is less than a reference value (S115, S117).
  • the service server (11) may determine the purchase payment method based on the predicted results of the learned deep learning model (90), the insufficient performance amount, etc.
  • the service server (11) may determine the first payment method (i.e., the payment method associated with the maximum benefit amount) as the purchase payment method for the first product and determine the second payment method as the purchase payment method for the second product.
  • the second payment method may be determined based on the priority, the remaining limit amount, the insufficient performance amount, the prediction result of the learned deep learning model (90), etc.
  • the service server (11) may determine a purchase payment method by comprehensively considering the priority of previously registered payment methods, the remaining limit amount, the insufficient performance amount, and the prediction result of the learned deep learning model (90).
  • FIG. 12 An exemplary computing device (120) capable of implementing a service system (10, e.g., service server (11), payment server (12)) according to some embodiments of the present disclosure will be described with reference to FIG. 12.
  • a service system e.g., service server (11), payment server (12)
  • Figure 12 is an exemplary hardware configuration diagram showing a computing device (120).
  • the computing device (120) may include one or more processors (121), a bus (123), a communication interface (124), a memory (122) for loading a computer program (126) executed by the processor (121), and a storage (125) for storing the computer program (126).
  • processors 121
  • bus 123
  • communication interface 124
  • memory 122
  • storage 125
  • the computing device (120) may further include various components in addition to the components illustrated in FIG. 12.
  • the computing device (120) may be configured in a form in which some of the components illustrated in FIG. 12 are omitted.
  • each component of the computing device (120) will be described.
  • the processor (121) can control the overall operation of each component of the computing device (120).
  • the processor (121) can be configured to include at least one of a CPU (Central Processing Unit), an MPU (Micro Processor Unit), an MCU (Micro Controller Unit), a GPU (Graphic Processing Unit), an NPU (Neural Processing Unit), or any other type of processor well known in the technical field of the present disclosure.
  • the processor (121) can perform operations for at least one application or program for executing operations/methods according to embodiments of the present disclosure.
  • the computing device (120) can have one or more processors.
  • the memory (122) can store various data, commands, and/or information.
  • the memory (122) can load a computer program (126) from the storage (125) to execute operations/methods according to embodiments of the present disclosure.
  • the memory (122) may be implemented as a volatile memory such as RAM, but the technical scope of the present disclosure is not limited thereto.
  • the bus (123) can provide a communication function between components of the computing device (120).
  • the bus (123) can be implemented as various types of buses such as an address bus, a data bus, and a control bus.
  • the communication interface (124) can support wired and wireless Internet communication of the computing device (120).
  • the communication interface (124) can support various communication methods other than Internet communication.
  • the communication interface (124) can be configured to include a communication module well known in the technical field of the present disclosure.
  • the storage (125) can non-temporarily store one or more computer programs (126).
  • the storage (125) can be configured to include non-volatile memory such as a Read Only Memory (ROM), an Erasable Programmable ROM (EPROM), an Electrically Erasable Programmable ROM (EEPROM), a flash memory, a hard disk, a removable disk, or any form of computer-readable recording medium well known in the art to which the present disclosure pertains.
  • ROM Read Only Memory
  • EPROM Erasable Programmable ROM
  • EEPROM Electrically Erasable Programmable ROM
  • flash memory a hard disk, a removable disk, or any form of computer-readable recording medium well known in the art to which the present disclosure pertains.
  • the computer program (126) may include one or more instructions that cause the processor (121) to perform operations/methods according to various embodiments of the present disclosure when loaded into the memory (122). That is, the processor (121) may perform operations/methods according to various embodiments of the present disclosure by executing the one or more instructions.
  • the computer program (126) may include instructions that cause the computer program to perform an operation of receiving a purchase request for at least one product from a user's terminal, an operation of obtaining payment method-related information of the user in response to the purchase request, wherein the payment method-related information includes priorities of a plurality of pre-registered payment methods, and the priorities are set by the user, an operation of obtaining payment benefit information for at least some of the plurality of payment methods, an operation of calculating a benefit amount for each of the plurality of payment methods based on the payment benefit information, and an operation of determining a purchase payment method for at least one product from among the plurality of payment methods based on the benefit amount and the priority.
  • the computer program (126) may include instructions to perform at least some of the steps/operations described with reference to FIGS. 1 through 11.
  • a service system (10, e.g., service server (11)) according to some embodiments of the present disclosure can be implemented via a computing device (120).
  • the computing device (120) illustrated in FIG. 12 may mean a virtual machine implemented based on cloud technology.
  • the computing device (120) may be a virtual machine operating on one or more physical servers included in a server farm.
  • the processor (121), memory (122), and storage (125) illustrated in FIG. 12 may be virtual hardware, and the communication interface (124) may also be implemented as a virtualized networking element such as a virtual switch.
  • a computer program recorded on a computer-readable recording medium can be transmitted to another computing device through a network such as the Internet and installed on the computing device, thereby allowing it to be used on the computing device.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Marketing (AREA)
  • Game Theory and Decision Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Evolutionary Computation (AREA)
  • Artificial Intelligence (AREA)
  • Mathematical Physics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Molecular Biology (AREA)
  • Computational Linguistics (AREA)
  • Biophysics (AREA)
  • Biomedical Technology (AREA)
  • Health & Medical Sciences (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Medical Informatics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

결제 서비스 제공 방법 및 그 시스템이 제공된다. 몇몇 실시예들에 따른 결제 서비스 제공 방법은, 사용자의 단말로부터 적어도 하나의 상품에 대한 구매 요청을 수신하는 단계, 구매 요청에 응답하여, 사용자의 결제수단 관련 정보를 획득하는 단계, 복수의 결제수단들 중 적어도 일부에 대한 결제 혜택 정보를 획득하는 단계, 결제 혜택 정보를 기초로 복수의 결제수단들 각각에 대한 혜택 금액을 계산하는 단계 및 혜택 금액에 기초하여 복수의 결제수단들 중에서 적어도 하나의 상품에 대한 구매 결제수단을 결정하는 단계를 포함할 수 있다. 이러한 방법에 따르면, 상품 구매 시 결제 혜택을 고려하여 신중하게 결제수단을 선택해야 하는 사용자의 번거로움이 해소될 수 있고, 사용자가 일부 결제수단의 혜택을 인지하지 못하여 의도치 않게 결제 혜택을 놓치는 문제도 해결될 수 있다.

Description

결제 서비스 제공 방법 및 그 시스템
본 개시는 결제 서비스 제공 방법 및 그 시스템에 관한 것이다.
전자 상거래(e-commerce) 서비스가 대중화됨에 따라 대다수의 사용자들이 온라인으로 상품을 구매하고 있고, 다양한 결제수단들이 상품 구매에 이용되고 있다.
한편, 결제수단에 따라 할인 혜택이 다르기 때문에, 같은 금액의 상품을 구매하더라도 결제수단 별로 할인 금액이 달라질 수 있다. 하지만, 상품을 구매하는 사용자가 자신이 보유한 결제수단들과 그들의 할인 혜택을 매번 확인하고 할인 금액을 계산하는 것은 상당히 번거로운 일이다.
본 개시의 몇몇 실시예들을 통해 해결하고자 하는 기술적 과제는, 결제수단 선택에 관한 사용자 편의성을 보다 향상시킬 수 있는 방법 및 그 방법을 수행하는 시스템을 제공하는 것이다.
본 개시의 몇몇 실시예들을 통해 해결하고자 하는 다른 기술적 과제는, 사용자가 의도치 않게 결제 혜택을 놓치는 문제를 미연에 방지할 수 있는 방법 및 그 방법을 수행하는 시스템을 제공하는 것이다.
본 개시의 몇몇 실시예들을 통해 해결하고자 하는 또 다른 기술적 과제는, 한 건의 상품 구매에 대해 복수의 결제수단들을 이용한 결제 기능(이른바, '복합/분할/혼합 결제' 기능)을 제공할 수 있는 방법 및 그 방법을 수행하는 시스템을 제공하는 것이다.
본 개시의 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급되지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 개시의 기술분야에서의 통상의 기술자에게 명확하게 이해될 수 있을 것이다.
상술한 기술적 과제를 해결하기 위한 본 개시의 몇몇 실시예들에 따른 결제 서비스 제공 방법은, 적어도 하나의 컴퓨팅 장치에서 수행되는 방법으로서, 사용자의 단말로부터 적어도 하나의 상품에 대한 구매 요청을 수신하는 단계, 상기 구매 요청에 응답하여, 상기 사용자의 결제수단 관련 정보를 획득하는 단계 - 상기 결제수단 관련 정보는 기 등록된 복수의 결제수단들의 우선순위를 포함하고 상기 우선순위는 상기 사용자에 의해 설정된 것임 -, 상기 복수의 결제수단들 중 적어도 일부에 대한 결제 혜택 정보를 획득하는 단계, 상기 결제 혜택 정보를 기초로 상기 복수의 결제수단들 각각에 대한 혜택 금액을 계산하는 단계 및 상기 혜택 금액과 상기 우선순위에 기초하여 상기 복수의 결제수단들 중에서 상기 적어도 하나의 상품에 대한 구매 결제수단을 결정하는 단계를 포함할 수 있다.
몇몇 실시예들에서, 상기 결제 혜택 정보는 상기 적어도 하나의 상품에 대한 전자상거래 서비스의 사업자가 제공하는 결제 혜택 정보와 결제수단의 사업자가 제공하는 결제 혜택 정보를 포함할 수 있다.
몇몇 실시예들에서, 상기 결제 혜택 정보는 요일, 날짜 및 시간에 따른 결제 혜택 정보를 포함할 수 있다.
몇몇 실시예들에서, 상기 적어도 하나의 상품에 대한 구매 결제수단을 결정하는 단계는, 상기 복수의 결제수단들에 대한 최대 혜택 금액이 기준치 이상이라는 판단에 기초하여 상기 최대 혜택 금액에 따라 상기 구매 결제수단을 결정하는 단계를 포함할 수 있다.
몇몇 실시예들에서, 상기 적어도 하나의 상품에 대한 구매 결제수단을 결정하는 단계는, 상기 복수의 결제수단들에 대한 최대 혜택 금액이 기준치 미만이라는 판단에 기초하여 상기 우선순위에 따라 상기 구매 결제수단을 결정하는 단계를 포함할 수 있다.
몇몇 실시예들에서, 상기 결제수단 관련 정보는 상기 사용자에 의해 설정된 결제 한도 금액을 기준으로 계산된 잔여 한도 금액을 포함하고, 상기 우선순위에 따라 상기 구매 결제수단을 결정하는 단계는, 상기 복수의 결제수단들의 잔여 한도 금액에 더 기초하여 상기 구매 결제수단을 결정하는 단계를 포함할 수 있다.
몇몇 실시예들에서, 상기 결정된 구매 결제수단이 선택된 상태의 결제 인터페이스를 제공하는 단계를 더 포함하고, 상기 결제 인터페이스는 상기 사용자로부터 추가 구매 결제수단을 선택받기 위한 인터페이스를 포함할 수 있다.
몇몇 실시예들에서, 상기 결정된 구매 결제수단이 선택된 상태의 결제 인터페이스를 제공하는 단계를 더 포함하고, 상기 결제 인터페이스는 상기 사용자로부터 둘 이상의 결제수단들의 조합을 등록받거나 상기 사용자의 입력에 기초하여 기 등록된 결제수단들의 조합을 불러오기 위한 인터페이스를 포함할 수 있다.
몇몇 실시예들에서, 상기 결제수단 관련 정보는 상기 복수의 결제수단들 각각에 대한 실적 부족 금액을 포함하고, 상기 결제 서비스 제공 방법은 상기 실적 부족 금액에 기초하여 상기 복수의 결제수단들 중에서 다른 구매 결제수단을 결정하는 단계를 더 포함할 수 있다.
몇몇 실시예들에서, 상기 결제수단 관련 정보는 상기 복수의 결제수단들 각각에 대한 실적 부족 금액을 포함하고, 상기 결정된 구매 결제수단은 제1 결제수단 및 제2 결제수단을 포함하며, 상기 결제 서비스 제공 방법은 상기 실적 부족 금액에 기초하여 상기 제1 결제수단과 상기 제2 결제수단 각각의 결제 금액을 결정하는 단계를 더 포함할 수 있다.
상술한 기술적 과제를 해결하기 위한 본 개시의 몇몇 실시예들에 따른 결제 서비스 제공 시스템은, 하나 이상의 프로세서 및 상기 하나 이상의 프로세서에 의해 실행되는 컴퓨터 프로그램을 저장하는 메모리를 포함하고, 상기 컴퓨터 프로그램은 사용자의 단말로부터 적어도 하나의 상품에 대한 구매 요청을 수신하는 동작, 상기 구매 요청에 응답하여, 상기 사용자의 결제수단 관련 정보를 획득하는 동작 - 상기 결제수단 관련 정보는 기 등록된 복수의 결제수단들의 우선순위를 포함하고 상기 우선순위는 상기 사용자에 의해 설정된 것임 -, 상기 복수의 결제수단들 중 적어도 일부에 대한 결제 혜택 정보를 획득하는 동작, 상기 결제 혜택 정보를 기초로 상기 복수의 결제수단들 각각에 대한 혜택 금액을 계산하는 동작 및 상기 혜택 금액과 상기 우선순위에 기초하여 상기 복수의 결제수단들 중에서 상기 적어도 하나의 상품에 대한 구매 결제수단을 결정하는 동작을 위한 인스트럭션들을 포함할 수 있다.
상술한 기술적 과제를 해결하기 위한 본 개시의 몇몇 실시예들에 따른 컴퓨터 프로그램은, 컴퓨팅 장치와 결합되어, 사용자의 단말로부터 적어도 하나의 상품에 대한 구매 요청을 수신하는 단계, 상기 구매 요청에 응답하여, 상기 사용자의 결제수단 관련 정보를 획득하는 단계 - 상기 결제수단 관련 정보는 기 등록된 복수의 결제수단들의 우선순위를 포함하고 상기 우선순위는 상기 사용자에 의해 설정된 것임 -, 상기 복수의 결제수단들 중 적어도 일부에 대한 결제 혜택 정보를 획득하는 단계, 상기 결제 혜택 정보를 기초로 상기 복수의 결제수단들 각각에 대한 혜택 금액을 계산하는 단계 및 상기 혜택 금액과 상기 우선순위에 기초하여 상기 복수의 결제수단들 중에서 상기 적어도 하나의 상품에 대한 구매 결제수단을 결정하는 단계를 실행시키기 위하여 컴퓨터로 판독가능한 기록매체에 저장될 수 있다.
본 개시의 몇몇 실시예들에 따르면, 사용자의 기 등록 결제수단들의 결제 혜택 정보에 기초하여 상품 구매에 이용될 결제수단(즉, 구매 결제수단)이 자동으로 결정될 수 있다. 이러한 경우, 상품 구매 시 결제 혜택을 고려하여 신중하게 결제수단을 선택해야 하는 사용자의 번거로움이 해소될 수 있다. 뿐만 아니라, 사용자가 일부 결제수단의 혜택을 인지하지 못하여 의도치 않게 결제 혜택을 놓치는 문제도 해결될 수 있다. 이에 따라, 전자상거래 서비스와 결제 서비스에 대한 사용자의 만족도는 크게 향상될 수 있다.
또한, 기 등록된 결제수단들에 대해 사용자가 설정한 우선순위와 결제 한도 금액에 기초하여 구매 결제수단이 결정될 수 있다. 이러한 경우, 사용자의 명시적인 의사(e.g., 결제수단에 대한 선호도, 결제수단 사용 계획)를 충실하게 반영하여 구매 결제수단이 결정될 수 있다.
또한, 기 등록된 결제수단들의 실적 부족 금액에 기초하여 구매 결제수단이 결정될 수 있다. 이러한 경우, 결제수단의 실적 달성 가능성이 높아지므로(즉, 실적 달성에 따른 혜택이 주어질 가능성이 높아짐), 전자상거래 서비스와 결제 서비스에 대한 사용자의 만족도는 더욱 향상될 수 있다.
또한, 한 건의 상품 구매에 대해 복수의 결제수단들을 이용하여 결제하는 기능(이른바, '복합/분할/혼합 결제' 기능)이 사용자에게 제공될 수 있다. 이러한 경우, 사용자는 다수의 결제수단들을 자유롭게 이용하여 상품을 구매할 수 있게 되는 바, 전자상거래 서비스와 결제 서비스에 대한 사용자의 만족도는 더욱 향상될 수 있다.
또한, 다수의 사용자들의 결제 이력 데이터(e.g., 사용자 정보, 상품 정보, 결제수단 정보 등)를 학습한 딥러닝 모델을 이용하여 사용자의 구매 결제수단이 결정될 수 있다. 학습된 딥러닝 모델은 상품의 특성, 사용자의 유형 등을 종합적으로 고려하여 해당 사용자의 선호 결제수단을 예측할 수 있기 때문에, 이 경우 해당 사용자가 선호하는 결제수단이 구매 결제수단으로 정확하게 결정될 수 있다.
본 개시의 기술적 사상에 따른 효과들은 이상에서 언급한 효과들로 제한되지 않으며, 언급되지 않은 또 다른 효과들은 아래의 기재로부터 통상의 기술자에게 명확하게 이해될 수 있을 것이다.
도 1은 본 개시의 몇몇 실시예들에 따른 결제 서비스 제공 시스템을 설명하기 위한 예시적인 구성도이다.
도 2는 본 개시의 몇몇 실시예들에 따른 결제 서비스 제공 방법을 나타내는 예시적인 흐름도이다.
도 3은 도 2에 도시된 혜택 금액 계산 단계의 세부 과정을 나타내는 예시적인 흐름도이다.
도 4는 본 개시의 몇몇 실시예들에 따른 결제 인터페이스를 예시한다.
도 5는 본 개시의 다른 몇몇 실시예들에 따른 결제 인터페이스를 예시한다.
도 6은 본 개시의 다른 몇몇 실시예들에 따른 결제 서비스 제공 방법을 나타내는 예시적인 흐름도이다.
도 7은 본 개시의 또 다른 몇몇 실시예들에 따른 결제 서비스 제공 방법을 나타내는 예시적인 흐름도이다.
도 8은 본 개시의 또 다른 몇몇 실시예들에 따른 결제 서비스 제공 방법을 나타내는 예시적인 흐름도이다.
도 9 및 도 10은 본 개시의 몇몇 실시예들에 따른 딥러닝 모델의 입출력, 구조 및 학습 방법을 설명하기 위한 예시적인 도면이다.
도 11은 본 개시의 또 다른 몇몇 실시예들에 따른 결제 서비스 제공 방법을 나타내는 예시적인 흐름도이다.
도 12는 본 개시의 몇몇 실시예들에 따른 결제 서비스 제공 시스템을 구현할 수 있는 예시적인 컴퓨팅 장치를 도시한다.
이하, 첨부된 도면을 참조하여 본 개시의 다양한 실시예들을 상세히 설명한다. 본 개시의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시예들을 참조하면 명확해질 것이다. 그러나, 본 개시의 기술적 사상은 이하의 실시예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 이하의 실시예들은 본 개시의 기술적 사상을 완전하도록 하고, 본 개시가 속한 기술분야에서 통상의 지식을 가진 자에게 본 개시의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 개시의 기술적 사상은 청구항의 범주에 의해 정의될 뿐이다.
본 개시의 다양한 실시예들을 설명함에 있어, 관련된 공지 구성 또는 기능에 대한 구체적인 설명이 본 개시의 요지를 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명은 생략한다.
다른 정의가 없다면, 이하의 실시예들에서 사용되는 용어(기술 및 과학적 용어를 포함)는 본 개시가 속한 기술분야에서 통상의 지식을 가진 자에게 공통적으로 이해될 수 있는 의미로 사용될 수 있으나, 이는 관련 분야에 종사하는 기술자의 의도 또는 판례, 새로운 기술의 출현 등에 따라 달라질 수도 있다. 본 개시에서 사용된 용어는 실시예들을 설명하기 위한 것이며 본 개시의 범주를 제한하고자 하는 것은 아니다.
이하의 실시예들에서 사용되는 단수의 표현은 문맥상 명백하게 단수인 것으로 특정되지 않는 한, 복수의 개념을 포함한다. 또한, 복수의 표현은 문맥상 명백하게 복수인 것으로 특정되지 않는 한, 단수의 개념을 포함한다.
또한, 이하의 실시예들에서 사용되는 제1, 제2, A, B, (a), (b) 등의 용어는 어떤 구성요소를 다른 구성요소와 구별하기 위해 사용되는 것일 뿐, 그 용어에 의해 해당 구성요소의 본질이나 차례 또는 순서 등이 한정되지는 않는다.
이하, 첨부된 도면들을 참조하여 본 개시의 다양한 실시예들에 대하여 상세하게 설명한다.
도 1은 본 개시의 몇몇 실시예들에 따른 결제 서비스 제공 시스템(10)을 설명하기 위한 예시적인 구성도이다.
도 1에 도시된 바와 같이, 실시예들에 따른 결제 서비스 제공 시스템(10)은 전자상거래(e-commerce)를 위한 결제 서비스를 제공하는 컴퓨팅 시스템으로서, 서비스 서버(11)와 결제 서버(12)를 포함하여 구성될 수 있다. 다만, 경우에 따라, 결제 서비스 제공 시스템(10)은 '전자상거래(또는 쇼핑 등) 서비스 제공 시스템'으로 명명될 수도 있고, 서비스 서버(11)와 결제 서버(12) 중 어느 하나의 장치가 '결제 서비스 제공 시스템'으로 칭해질 수도 있다. 이하에서는, 설명의 편의상, 결제 서비스 제공 시스템(10)을 '서비스 시스템(10)'으로 약칭하도록 한다.
서비스 서버(11)는 다양한 상품들에 대한 전자상거래(또는 쇼핑 등) 서비스를 제공하는 컴퓨팅 장치/시스템이다. 가령, 서비스 서버(11)는 웹 및/또는 앱 인터페이스를 통해 다양한 상품들에 대한 전자상거래 서비스를 제공할 수 있고, 사용자는 단말(13)에 설치된 웹 브라우저(web browser) 및/또는 앱(app)을 통해 전자상거래 서비스를 이용할 수 있다.
또한, 서비스 서버(11)는 전자상거래 서비스와 연관된 각종 정보/데이터(e.g., 상품, 사용자, 사용자가 등록한 결제수단, 결제 혜택, 구매/결제 이력 등에 관한 정보/데이터)를 저장소에 저장하고 관리할 수 있다. 이러한 정보/데이터의 예시에 대해서는 후술하도록 한다.
또한, 서비스 서버(11)는 다양한 방식으로 구매 상품에 대한 결제수단을 자동으로 결정(e.g., 추천)할 수 있고 복수의 결제수단들을 이용한 결제 기능(이른바 '복합/분할/혼합 결제' 기능)을 제공할 수도 있다. 그렇게 함으로써, 전자상거래 및 결제 서비스를 이용하는 사용자의 편의성과 만족도가 향상될 수 있는데, 이에 대해서는 도 2 이하의 도면들을 참조하여 상세하게 설명하도록 한다.
다음으로, 결제 서버(12)는 결제 처리(또는 승인) 기능을 담당하는 컴퓨팅 장치/시스템이다. 가령, 결제 서버(12)는 서비스 서버(11)로부터 특정 결제수단에 기반한 결제 요청을 수신하고 이에 응답하여 요청된 결제수단으로 결제 처리(e.g., 승인)를 수행할 수 있다. 결제 서버(12)는 서로 다른 결제수단들에 대한 결제 처리 기능을 담당하는 다수의 결제 서버들을 총칭하는 것일 수도 있다. 가령, 결제 서버(12)는 제1 결제수단에 대한 결제 처리 기능을 담당하는 제1 결제 서버와 제2 결제 수단에 대한 결제 처리 기능을 담당하는 제2 결제 서버를 포함하는 것일 수도 있다.
또한, 결제 서버(12)는 결제수단, 결제 처리 등과 연관된 각종 정보/데이터(e.g., 결제 혜택, 결제 금액, 실적 금액, 실적 부족 금액, 결제 이력 등)를 저장소에 저장하고 관리할 수 있다. 또한, 결제 서버(12)는 서비스 서버(11)의 요청에 따라 특정 정보/데이터를 서비스 서버(11)에게 제공할 수도 있다.
상술한 서비스 서버(11)와 결제 서버(12)는 적어도 하나의 컴퓨팅 장치로 구현될 수 있다. 예를 들어, 서비스 서버(11)의 모든 기능이 하나의 컴퓨팅 장치에서 구현될 수도 있고, 서비스 서버(11)의 제1 기능은 제1 컴퓨팅 장치에서 구현되고 제2 기능은 제2 컴퓨팅 장치에서 구현될 수도 있다. 또는, 서비스 서버(11)의 특정 기능이 복수의 컴퓨팅 장치들에서 구현될 수도 있다.
컴퓨팅 장치는 컴퓨팅 기능을 구비한 임의의 장치를 모두 포함할 수 있으며, 이러한 장치의 일 예시에 관하여서는 도 12를 참조하도록 한다. 컴퓨팅 장치는 다양한 구성요소들(e.g. 메모리, 프로세서 등)이 상호작용하는 집합체이므로, 경우에 따라 '컴퓨팅 시스템'으로 명명될 수도 있다. 물론, 컴퓨팅 시스템이란 용어는 복수의 컴퓨팅 장치들이 상호작용하는 집합체의 개념도 포괄할 수 있다.
사용자 단말(13)은 전자상거래 서비스를 이용하는 사용자 측의 컴퓨팅 장치(e.g., 모바일 컴퓨팅 장치, 고정형 컴퓨팅 장치)이다. 사용자 단말(13)은 어떠한 컴퓨팅 장치로 구현되더라도 무방하다.
사용자는 단말(13)을 통해 전자상거래 서비스의 사이트에 접속하여 상품을 구매할 수 있고 자주 사용하는 결제수단들을 미리 등록할 수도 있다. 사용자는 단말(13)을 통해 둘 이상의 결제수단들의 조합을 등록할 수도 있다.
도시된 바와 같이, 서비스 시스템(10)과 사용자 단말(13)은 네트워크를 통해 통신할 수 있다. 여기서, 네트워크는 근거리 통신망(Local Area Network; LAN), 광역 통신망(Wide Area Network; WAN), 이동 통신망(mobile radio communication network), Wibro(Wireless Broadband Internet) 등과 같은 모든 종류의 유/무선 네트워크로 구현될 수 있다.
지금까지 도 1을 참조하여 본 개시의 몇몇 실시예들에 따른 서비스 시스템(10)의 구성 및 동작에 대하여 개략적으로 설명하였다. 이하에서는, 도 2 이하의 도면들을 참조하여 서비스 시스템(10)에서 수행될 수 있는 다양한 방법들에 대하여 설명하도록 한다.
이하에서는, 이해의 편의를 제공하기 위해, 후술될 방법들의 모든 단계/동작이 도 1에 예시된 환경의 서비스 서버(11)를 중심으로 수행되는 것을 가정하여 설명을 이어가도록 한다. 따라서, 특정 단계/동작의 주체가 생략된 경우, 서비스 서버(11)에서 수행되는 것으로 이해될 수 있다. 다만, 실제 환경에서는, 후술될 방법들의 일부 단계/동작이 결제 서버(12) 또는 다른 컴퓨팅 장치/시스템에서 수행될 수도 있다.
도 2는 본 개시의 몇몇 실시예들에 따른 결제 서비스 제공 방법을 나타내는 예시적인 흐름도이다.
도 2에 도시된 바와 같이, 본 실시예들은 결제 혜택 정보를 기초로 구매 결제수단(즉, 구매에 이용될 결제수단)을 자동으로 결정하는 방법에 관한 것이다.
본 실시예들은 사용자의 단말로부터 적어도 하나의 상품에 대한 구매 요청을 수신하는 단계 S21에서 시작될 수 있다. 가령, 장바구니 페이지 또는 상품 페이지에서 사용자가 구매하기 버튼을 클릭하는 경우, 사용자 단말(13)이 서비스 서버(11)로 구매 요청을 송신할 수 있다. 적어도 하나의 상품은 한 건의 구매에 속하는 결제 대상 상품을 의미할 수 있다(e.g., 장바구니에 담긴 상품 등).
단계 S22에서, 사용자의 결제수단 관련 정보(즉, 기 등록 결제수단들과 관련된 정보)가 획득될 수 있다. 가령, 서비스 서버(11)는 저장소를 조회하여(e.g., 사용자의 ID로 조회하는 등) 해당 사용자가 기 등록한 결제수단들의 정보를 획득할 수도 있고 결제 서버(12)로부터 해당 결제수단들의 정보(e.g., 실적 부족 금액 등)를 획득할 수도 있다. 서비스 서버(11)가 결제수단 관련 정보를 획득하는 방식은 어떠한 방식이 되더라도 무방하다. 이하의 설명에서, 사용자의 결제수단은 사용자가 서비스 서버(11)에 기 등록한 결제수단을 의미할 수 있다.
결제수단 관련 정보는 예를 들어 결제수단의 유형(카테고리)(e.g., 페이머니와 같은 충전형 결제수단, 카드, 계좌, 간편결제 등), 사용자가 설정한 결제수단의 우선순위, 사용자가 설정한 결제수단의 한도 금액(e.g., 월별 한도 금액), 잔여 한도 금액(e.g., 월별 한도 금액 - 해당 월의 결제(사용) 금액), 결제 금액(e.g., 결제수단 별 결제 금액, 총 결제 금액 등), 충전 금액(e.g., 페이머니 금액), 실적 금액(e.g., 카드 혜택을 받기 위해 달성해야 하는 월별 실적 금액), 실적 부족 금액(e.g., 월별 실적 금액 - 해당 월의 결제(사용) 금액) 등을 포함할 수 있으나, 이에 한정되는 것은 아니다.
단계 S23에서, 기 등록된 결제수단들에 대한 결제 혜택 정보가 획득될 수 있다. 가령, 서비스 서버(11)는 결제 서버(12)로부터 특정 결제수단에 적용되는 결제 혜택 정보를 획득할 수도 있고 인터넷 상의 정보를 검색함으로써 특정 결제수단의 혜택 정보를 획득할 수도 있다. 또한, 서비스 서버(11)는 저장소, 상품 페이지 등을 조회하여 서비스 서버(11)의 사업자가 제공하는 결제 혜택 정보를 획득할 수도 있다. 서비스 서버(11)가 결제 혜택 정보를 획득하는 방식은 어떠한 방식이 되더라도 무방하다. 경우에 따라, 서비스 서버(11)는 사용자의 기 등록 결제수단 외에 다른 결제수단들에 대한 결제 혜택 정보를 더 획득할 수도 있다.
결제 혜택 정보는 예를 들어 할인(e.g., 상품 금액 할인, 결제 금액에 대한 청구 할인), 캐시백, 포인트(또는 페이머니) 적립, 쿠폰 지급 등과 같이 결제를 통해 얻을 수 있는 각종 경제적 혜택들의 정보를 제한없이 포함할 수 있다.
또한, 결제 혜택 정보는 예를 들어 전자상거래 서비스의 사업자(즉, 서비스 서버(11)의 사업자)가 제공하는 제1 결제 혜택 정보와 결제수단의 사업자(즉, 결제 서버(12)의 사업자)가 제공하는 제2 결제 혜택 정보를 포함할 수 있다.
제1 결제 혜택 정보는 예를 들어 특정 상품(e.g., 특정 카테고리의 상품 등)에 적용되는 혜택, 멤버십(membership) 가입자에 한하여 제공되는 혜택(e.g., 특정 결제수단으로 결제 시의 할인 혜택 등), 일정 기간 동안 제공되는 이벤트성 혜택 등과 같은 정보를 포함할 수 있으나, 이에 한정되는 것은 아니다.
또한, 제2 결제 혜택 정보는 예를 들어 요일, 날짜 및 시간에 따른 결제 혜택 정보(e.g., 특정 요일, 날짜, 시간에 결제 시에 제공되는 할인 혜택 등)를 포함할 수 있으나, 이에 한정되는 것은 아니다.
단계 S24에서, 결제 혜택 정보를 기초로 기 등록 결제수단들 각각에 대한 혜택 금액이 계산될 수 있다. 여기서, 혜택 금액은 예를 들어 할인 금액, 캐시백 금액, 적립 포인트에 상응하는 금액 등이 될 수 있으나, 이에 한정되는 것은 아니다.
가령, 도 3에 도시된 바와 같이, 서비스 서버(11)는 사용자의 기 등록 카드들 중에서 현재 요일에 할인 혜택이 제공되는 카드에 대해 요일 할인 금액을 계산할 수 있고(S31, S32), 유사한 방식으로 다른 카드들에 대해서도 상응하는 할인 금액(e.g., 시간 할인 금액, 날짜 할인 금액, 상품 할인 금액)을 계산할 수 있다(S33 내지 S38 참고).
단계 S25에서, 혜택 금액을 기초로 적어도 하나의 상품에 대한 구매 결제수단이 결정될 수 있다. 가령, 서비스 서버(11)는 최대 혜택 금액을 제공하는 적어도 하나의 결제수단을 구매 결제수단으로 결정할 수 있다. 여기서, 최대 혜택 금액은 혜택의 중복(합산) 가능 여부를 고려하여 산정된 혜택 금액의 최대치를 의미할 수 있다. 가령, 장바구니에 담긴 '50만원'의 모니터에 대해 제1 카드가 '10%'의 할인 혜택을 제공하고, '100만원'의 노트북에 대해 제2 카드가 '5%'의 할인 혜택을 제공하며, 두가지 할인 혜택이 중복 적용 가능한 경우, 최대 혜택 금액은 '10만원'으로 산정될 수 있다. 이러한 경우, 제1 카드와 제2 카드가 함께 구매 결제수단으로 결정될 수도 있고, 제1 카드와 제2 카드의 결제금액도 최대 혜택 금액에 따라 결정될 수도 있다.
구매 결제수단은 결제 페이지(e.g., 체크아웃 페이지)에 배치된 결제 인터페이스를 통해 사용자에게 제공(e.g., 추천)될 수 있다. 가령, 서비스 서버(11)는 구매 결제수단이 선택된 상태의 결제 인터페이스(e.g., 도 4의 41 등 참고)를 사용자에게 제공할 수 있다. 경우에 따라, 서비스 서버(11)는 별도의 인터페이스(e.g., 팝업 형태의 결제수단 추천 인터페이스)를 통해 사용자에게 구매 결제수단을 제공할 수도 있다.
한편, 결제 인터페이스는 복합 결제 기능을 제공하기 위해 복수의 결제수단들을 선택받을 수 있도록 구성될 수도 있다. 이하, 이해의 편의를 제공하기 위해, 도 4 및 도 5를 참조하여 이러한 결제 인터페이스(즉, 결제를 위한 사용자 인터페이스)의 예시들에 대하여 간략하게 설명하도록 한다.
도 4는 본 개시의 몇몇 실시예들에 따른 결제 인터페이스(40)를 예시하고 있다.
도 4에 도시된 바와 같이, 결제 인터페이스(40)는 결제수단 선택 인터페이스(41, 43)와 결제 금액 입력 인터페이스(42, 44)를 포함할 수 있다. 결제수단 선택 인터페이스(e.g., 41)는 예를 들어 사용자의 기 등록된 결제수단들을 선택 가능 항목들로 갖는 드롭다운 리스트로 구현될 수 있을 것이나, 본 개시의 범위가 이에 한정되는 것은 아니다.
또한, 결제 인터페이스(40)는 결제수단 추가를 위한 인터페이스(45, e.g., 버튼)를 더 포함할 수 있다. 결제수단 추가 인터페이스(45)를 통해 사용자 입력이 수신되면, 추가 결제수단을 선택받기 위한 인터페이스(43, 44 참고)가 결제 인터페이스(40) 내에 더 표시될 수 있다(e.g., 도시된 인터페이스(43, 44)는 그러한 사용자 입력에 의해 추가된 것일 수 있음).
몇몇 실시예들에서는, 결제 금액 인터페이스(42, 44)의 초기값(즉, 결제 금액)이 자동으로 설정될 수도 있다. 가령, 결제 금액 인터페이스(42, 44)의 초기값은 총 결제 금액을 선택된(될) 결제수단의 개수로 나눈 금액(즉, 균등 분할 금액)으로 설정될 수 있다. 또는, 선택된(될) 결제수단의 개수와 상품 개수가 동일한 경우, 결제 금액 인터페이스(42, 44)의 초기값은 대응되는 개별 상품의 금액으로 설정될 수도 있다(e.g., 결제수단 추가에 의해 현재 결제수단의 개수가 상품 개수와 동일해지는 경우, 균등 분할 금액에서 개별 상품의 금액으로 설정값이 변경될 수도 있음).
도 5는 본 개시의 다른 몇몇 실시예들에 따른 결제 인터페이스(50)를 예시하고 있다.
도 5에 도시된 바와 같이, 본 실시예들에 따른 결제 인터페이스(50)는 모바일 제스처 기반의 사용자 입력을 고려하여 설계된 것으로서, 제1 영역(51)과 제2 영역(52)을 포함하여 구성될 수 있다. 여기서, 제1 영역(51)에는 선택된 결제수단들(53, 55)과 결제 금액 입력 인터페이스(54, 56)가 표시(위치)될 수 있고, 제2 영역(52)는 사용자의 기 등록된 결제수단들(57 내지 59)이 표시(위치)될 수 있다.
이러한 실시예들에서, 제2 영역(52)에 표시된 특정 결제수단(e.g., 58)을 제1 영역(51)으로 드래그(drag)하는 사용자 입력이 수신되면, 제1 영역(51)에 선택된 결제수단(e.g., 55)과 이에 대응되는 결제 금액 인터페이스(e.g., 56)가 표시(추가)될 수 있다. 또한, 제1 영역(51)에 표시된 특정 결제수단(e.g., 55)을 제2 영역(52)으로 드래그하는 사용자 입력이 수신되면, 특정 결제수단(e.g., 55)과 이에 대응되는 결제 금액 인터페이스(e.g., 56)가 제1 영역(51)에서 제거될 수 있다. 이러한 경우, 사용자는 드래그와 같은 단순 입력을 통해 결제수단을 선택(또는 선택 취소)할 수 있게 되는 바, 결제수단 선택에 관한 사용자의 편의성이 더욱 향상될 수 있다.
한편, 몇몇 실시예들에서는, 상술한 결제 인터페이스(40, 50 참고)가 둘 이상의 결제수단들의 조합을 등록받거나 사용자 입력에 기초하여 기 등록된 결제수단들의 조합을 불러오기 위한 인터페이스를 포함(제공)할 수도 있다. 가령, 사용자는 자주 사용하는 결제수단의 조합(e.g., '페이머니'와 '특정 카드')을 미리 등록해 놓고, 결제 인터페이스에서 해당 조합을 불러오는 방식으로 구매 상품에 이용될 다수의 결제수단들을 빠르게 선택할 수도 있다.
지금까지 도 2 내지 도 5를 참조하여 본 개시의 몇몇 실시예들에 따른 결제 서비스 제공 방법에 대하여 설명하였다. 상술한 바에 따르면, 사용자의 기 등록 결제수단들의 결제 혜택 정보에 기초하여 상품 구매에 이용될 결제수단(즉, 구매 결제수단)이 자동으로 결정될 수 있다. 이러한 경우, 상품 구매 시 결제 혜택을 고려하여 신중하게 결제수단을 선택해야 하는 사용자의 번거로움이 해소될 수 있다. 뿐만 아니라, 사용자가 일부 결제수단의 결제 혜택을 인지하지 못하여 결제 혜택을 놓치는 문제도 해결될 수 있다. 이에 따라, 전자상거래 서비스와 결제 서비스에 대한 사용자의 만족도는 크게 향상될 수 있다.
이하에서는, 도 6을 참조하여 본 개시의 다른 몇몇 실시예들에 따른 결제 서비스 제공 방법에 대하여 설명하도록 한다. 다만, 본 개시의 명료함을 위해 앞선 실시예들과 중복되는 내용에 대한 설명은 생략하도록 한다.
도 6에 도시된 바와 같이, 본 실시예들은 결제수단의 우선순위와 잔여 한도 금액을 기초로 구매 결제수단을 결정하는 방법에 관한 것이다. 상술한 바와 같이, 기 등록된 결제수단들의 우선순위와 결제 한도 금액(e.g., 월별 결제 한도)은 사용자에 의해 설정될 수 있으며(e.g., 사용자는 제1 카드와 제2 카드 각각의 우선순위와 결제 한도 금액을 (1순위, 10만원)와 (2순위, 5만원)과 같이 설정할 수 있음), 잔여 한도 금액은 결제 한도 금액을 기준으로 하여 계산될 수 있다.
본 실시예들도 적어도 하나의 상품에 대한 구매 요청을 수신하는 단계 S61에서 시작될 수 있다. 이에 대해서는 상술한 단계 S21의 설명 내용을 더 참고하도록 한다.
단계 S62에서, 사용자의 결제수단 관련 정보가 획득될 수 있다. 여기서, 결제수단 관련 정보는 사용자가 설정한 결제수단의 우선순위와 잔여 한도 금액을 포함할 수 있다. 본 단계에 대해서는 상술한 단계 S22의 설명 내용을 더 참고하도록 한다.
단계 S63에서, 우선순위와 잔여 한도 금액을 기초로 적어도 하나의 상품에 대한 구매 결제수단이 결정될 수 있다. 이렇게 결정된 구매 결제수단은 결제 인터페이스를 통해 사용자에게 제공될 수 있는데, 이에 대해서는 상술한 단계 S25, 도 4 및 도 5의 설명 내용을 참고하도록 한다.
예를 들어 부연 설명하면, 우선순위가 가장 높은 제1 결제수단의 잔여 한도 금액이 적어도 하나의 상품의 결제 금액(즉, 총 결제 금액) 이상인 경우, 서비스 서버(11)는 제1 결제수단을 구매 결제수단으로 결정할 수 있다.
다른 예로서, 우선순위가 가장 높은 제1 결제수단의 잔여 한도 금액이 적어도 하나의 상품의 결제 금액(즉, 총 결제 금액) 미만인 경우, 서비스 서버(11)는 제1 결제수단과 제2 결제수단(즉, 다음 우선순위의 결제수단)을 구매 결제수단으로 결정할 수 있다. 이때, 제2 결제수단의 결제 금액은 예를 들어 총 결제 금액에서 제1 결제수단의 잔여 한도 금액을 제한 값이 될 수 있을 것이나, 본 개시의 범위가 이에 한정되는 것은 아니다.
지금까지 도 6을 참조하여 본 개시의 다른 몇몇 실시예들에 따른 결제 서비스 제공 방법에 대하여 설명하였다. 상술한 바에 따르면, 사용자의 명시적인 의사(e.g., 결제수단에 대한 선호도, 결제수단 사용 계획)를 충실하게 반영하여 구매 결제수단이 결정될 수 있다.
이하에서는, 도 7을 참조하여 본 개시의 또 다른 몇몇 실시예들에 따른 결제 서비스 제공 방법에 대하여 설명하도록 한다. 다만, 본 개시의 명료함을 위해 앞선 실시예들과 중복되는 내용에 대한 설명은 생략하도록 한다.
도 7에 도시된 바와 같이, 본 실시예들은 결제수단의 실적 부족 금액에 기초하여 구매 결제수단을 결정하는 방법에 관한 것이다.
본 실시예들도 적어도 하나의 상품에 대한 구매 요청을 수신하는 단계 S71에서 시작될 수 있다. 이에 대해서는 상술한 단계 S21의 설명 내용을 더 참고하도록 한다.
단계 S72에서, 사용자의 결제수단 관련 정보가 획득될 수 있다. 여기서, 결제수단 관련 정보는 기 등록된 결제수단들의 실적 부족 금액을 포함할 수 있다. 본 단계에 대해서는 상술한 단계 S22의 설명 내용을 더 참고하도록 한다.
단계 S73에서, 실적 부족 금액을 기초로 적어도 하나의 상품에 대한 구매 결제수단이 결정될 수 있다. 가령, 서비스 서버(11)이 기 등록된 결제수단들 중에서 실적 부족 금액이 기준치 이상인 결제수단(e.g., 실적 부족 금액이 가장 높은 결제수단, 실적 부족 금액이 기준치 이상인 복수의 결제수단들)을 구매 결제수단으로 결정할 수 있다. 이렇게 결정된 구매 결제수단은 결제 인터페이스를 통해 사용자에게 제공될 수 있는데, 이에 대해서는 상술한 단계 S25, 도 4 및 도 5의 설명 내용을 참고하도록 한다.
몇몇 실시예들에서는, 실적 부족 금액을 기초로 각 결제수단의 결제 금액이 결정될 수도 있다. 가령, 제1 결제수단과 제2 결제수단이 구매 결제수단으로 결정되었다고 가정하자. 이러한 경우, 서비스 서버(11)는 제1 결제수단과 제2 결제수단 각각의 실적 부족 금액에 기초하여 제1 결제수단과 제2 결제수단 각각의 결제 금액을 결정할 수 있다. 이를테면, 서비스 서버(11)는 결제수단들의 실적 부족 금액의 비율에 따라 각 결제수단의 결제 금액을 산정할 수 있다(e.g., 제1 결제수단의 결제 금액 = 구매 상품의 총 결제 금액 * (제1 결제수단의 실적 부족 금액/제2 결제수단의 실적 부족 금액)). 그러나, 본 개시의 범위가 이에 한정되는 것은 아니다.
지금까지 도 7을 참조하여 본 개시의 또 다른 몇몇 실시예들에 따른 결제 서비스 제공 방법에 대하여 설명하였다. 상술한 바에 따르면, 결제수단의 실적 달성 가능성이 높아지므로(즉, 실적 달성에 따른 혜택이 주어질 가능성이 높아짐), 전자상거래 서비스와 결제 서비스에 대한 사용자의 만족도는 더욱 향상될 수 있다.
이하에서는, 도 8을 참조하여 본 개시의 또 다른 몇몇 실시예들에 따른 결제 서비스 제공 방법에 대하여 설명하도록 한다. 다만, 본 개시의 명료함을 위해 앞선 실시예들과 중복되는 내용에 대한 설명은 생략하도록 한다.
도 8에 도시된 바와 같이, 본 실시예들은 딥러닝 모델을 통해 구매 결제수단을 결정하는 방법에 관한 것이다.
본 실시예들은 다수의 사용자들의 결제 이력 데이터를 이용하여 학습된 딥러닝 모델을 획득하는 단계 S81에서 시작될 수 있다. 이하, 이해의 편의를 제공하기 위해, 도 9 및 도 10을 참조하여 예시적인 딥러닝 모델의 구조와 학습 방법에 대하여 설명하도록 한다.
도 9는 본 개시의 몇몇 실시예들에 따른 딥러닝 모델(90)의 입출력을 예시하고 있다.
도 9에 도시된 바와 같이, 실시예들에 따른 딥러닝 모델(90)은 사용자 정보, 컨텍스트 정보, 상품 정보 등을 입력받고 결제수단별 컨피던스 스코어(confidence score, 즉 확률값)를 출력(예측)하도록 구성될 수 있다. 경우에 따라, 딥러닝 모델(90)은 N-1번째(단, N은 1 이상의 값) 결제수단의 정보(e.g., 결제수단의 ID, 명칭, 유형, 결제 금액 등)를 더 입력받아 N번째 결제수단에 대한 컨피던스 스코어를 출력하도록 구성될 수도 있다. 또한, 후술되는 바와 같이 딥러닝 모델(90)은 결제수단의 유형별 컨피던스 스코어 등을 더 출력하도록 구성될 수도 있고, 도 9에 예시된 정보들 중 일부만 입력받는 형태로 구성될 수도 있다.
사용자 정보는 예를 들어 성별, 연령대와 같은 인구통계학적 정보, 멤버십 가입 여부 등을 포함할 수 있으나, 이에 한정되는 것은 아니다. 이러한 사용자 정보가 명시적으로 주어지면, 딥러닝 모델(90)이 사용자의 유형(또는 특성)을 고려하여 결제수단을 예측하도록 학습될 수 있다.
다음으로, 컨텍스트 정보는 예를 들어 일반 컨텍스트 정보와 결제 컨텍스트 정보를 포함할 수 있다.
일반 컨텍스트 정보는 예를 들어 결제가 이루어진 시간, 요일, 사용자 단말의 타입(e.g., 모바일 단말, 고정형 단말 등) 등을 포함할 수 있으나, 이에 한정되는 것은 아니다. 이러한 일반 컨텍스트 정보가 명시적으로 주어지면, 딥러닝 모델(90)이 사용자의 현재 컨텍스트까지 고려하여 결제수단을 예측하도록 학습될 수 있다.
결제 컨텍스트 정보는 예를 들어 페이머니(즉, 충전형 결제수단)에 충전된 금액, 계좌 금액, 이전 구매에 이용된 결제수단 정보(e.g., 결제수단, 결제수단의 유형 등), 기 등록 결제수단과 관련된 정보(e.g., 개수, 우선순위, 잔여 한도 금액, 실적 부족 금액, 혜택 금액 등) 등을 포함할 수 있으나, 이에 한정되는 것은 아니다. 이러한 결제 컨텍스트 정보가 명시적으로 주어지면, 딥러닝 모델(90)이 사용자의 기 등록 결제수단과 관련된 컨텍스트까지 고려하여 결제수단을 예측하도록 학습될 수 있다.
다음으로, 상품 정보는 예를 들어 상품의 ID, 명칭, 카테고리, 금액, 옵션 등의 정보를 포함할 수 있으나, 이에 한정되는 것은 아니다. 이러한 상품 정보가 명시적으로 주어지면, 딥러닝 모델(90)이 구매 상품의 특성을 고려하여 결제수단을 예측하도록 학습될 수 있다.
이하에서는, 도 10을 참조하여 딥러닝 모델(90)의 세부 구조와 학습 방법에 대하여 설명하도록 한다.
도 10에 도시된 바와 같이, 딥러닝 모델(90)은 임베더들(101 내지 104), 인코더(105) 및 예측기들(106, 107)을 포함하여 구성될 수 있다. 임베더들(101 내지 104)과 예측기들(106, 107)의 개수는 경우에 따라 달라질 수도 있다.
임베더들(101 내지 104)은 입력된 정보에 대한 임베딩(e.g., 임베딩 벡터)을 생성할 수 있다. 가령, 제1 임베더(101)는 사용자 정보에 대한 임베딩을 생성할 수 있고 제4 임베더(104)는 상품 정보에 대한 임베딩을 생성할 수 있다. 임베더들(101 내지 104) 각각은 MLP(Multi-Layer Perceptron)와 같은 신경망에 기반하여 구현될 수 있을 것이나, 본 개시의 범위가 이에 한정되는 것은 아니다.
다음으로, 인코더(105)는 임베더들(101 내지 104)에 의해 생성된 임베딩들을 인코딩할 수 있다. 다양한 정보들 간의 연관성을 분석하고 연관성을 기초로 정보들을 취합하기 위해, 인코더(105)는 어텐션(attention) 모듈과 MLP에 기반하여 구현될 수 있으나, 본 개시의 범위가 이에 한정되는 것은 아니다.
다음으로, 예측기들(106, 107)은 인코딩 결과(즉, 인코더(105)의 출력)에 기초하여 미리 정해진 태스크를 수행할 수 있다. 그 결과, 태스크에 대한 컨피던스 스코어가 출력될 수 있다. 예측기들(106, 107) 각각은 완전연결 레이어(fully-connected layer)와 같은 신경망에 기반하여 구현될 수 있을 것이나, 본 개시의 범위가 이에 한정되는 것은 아니다.
구체적으로, 제1 예측기(106)는 인코딩 결과에 기초하여 결제수단의 유형별 컨피던스 스코어를 출력(예측)하도록 구성될 수 있고, 제2 예측기(107)는 인코딩 결과에 기초하여 결제수단별 컨피던스 스코어를 출력(예측)하도록 구성될 수 있다. 여기서, 결제수단의 유형은 동일 또는 유사한 특성을 갖는 결제수단이 속한 카테고리(또는 그룹)을 의미한다. 즉, 제2 예측기(107)는 개별 결제수단 각각을 서로 다른 클래스로 구분하여 예측을 수행하는 점에서, 제1 예측기(106)와 차이가 있는 것으로 이해될 수 있다(e.g., 제2 예측기(107)는 '카드1'과 '카드2'를 다른 클래스로 구분하나, 제1 예측기(106)는 '카드1'과 '카드2'를 동일 클래스로 구분함).
몇몇 실시예들에서는, 도시된 바와 같이, 예측기들(106, 107)이 N-1번째(단, N은 1 이상의 값) 결제수단(즉, 구매 결제수단)의 정보를 더 입력받아 N번째 결제수단 관련 예측(e.g., 결제수단 유형 예측, 결제수단 예측 등)을 수행하도록 구성될 수도 있다. 가령, 결제 이력 데이터가 복합 결제 샘플들(즉, 복합 결제를 통해 한 건의 상품 구매가 이루어진 케이스의 데이터)을 포함하는 경우, 예측기들(106, 107)은 복합 결제 샘플들을 이용하여 N-1번째 결제수단이 선택된 경우에 N번째 결제수단을 예측하는 태스크를 수행할 수도 있다.
상술한 딥러닝 모델(90)은 결제 이력 데이터를 이용하여 다양한 태스크들을 수행함으로써 학습될 수 있다. 이때, 결제 이력 데이터를 도 9에 예시된 바와 같이 사용자 정보(즉, 학습용 사용자 정보), 상품 정보, 컨텍스트 정보 및 결제수단 정보를 포함할 수 있고, 결제수단 정보의 적어도 일부가 학습을 위한 레이블(label) 정보로 이용될 수 있다.
구체적인 예를 들어, 딥러닝 모델(90)은 제1 예측기(106)를 통해 결제수단(또는 N번째 결제수단)의 유형을 예측하는 제1 태스크를 수행함으로써 학습될 수 있다. 또는, 딥러닝 모델(90)은 제2 예측기(107)를 통해 결제수단(또는 N번째 결제수단)을 예측하는 제2 태스크를 수행함으로써 학습될 수도 있다. 물론, 딥러닝 모델(90)은 제1 태스크와 제2 태스크를 함께 수행하는 방식으로 학습될 수도 있다.
몇몇 실시예들에서, 딥러닝 모델(90)은 제3 예측기(미도시)를 더 포함하여 구성될 수도 있다. 제3 예측기(미도시)는 한 건의 상품 구매에 이용된 결제수단의 개수를 예측하는 신경망으로서, 예를 들어 결제수단의 개수가 복수인지 여부를 예측하는 분류기 등이 될 수 있다. 본 실시예들에서, 딥러닝 모델(90)은 제3 예측기(미도시)를 통해 결제수단의 개수를 예측하는 제3 태스크(e.g., 복합 결제 여부 예측)를 더 수행함으로써 학습될 수 있다.
또한, 몇몇 실시예들에서는, 딥러닝 모델(90)이 혜택 금액의 영향이 최소한으로 반영된 사용자들의 결제수단 선호도를 학습할 수 있도록, 결제 이력 데이터에서 최대 혜택 금액이 기준치 미만인 데이터(샘플들)만을 이용하여 딥러닝 모델(90)이 학습될 수도 있다. 또는, 최대 혜택 금액과 실제 구매에 이용된 결제수단을 고려하여 샘플 가중치(또는 학습 강도)를 달리하는 방식으로 딥러닝 모델(90)이 학습될 수도 있다(e.g., 최대 혜택 금액이 기준치 미만인 샘플에 대해서는 제1 가중치로 학습 수행, 최대 혜택 금액이 기준치 이상이나 혜택 관련 결제수단이 구매 결제수단으로 이용되지 않은 샘플에 대해서는 제1 가중치보다 높은 제2 가중치로 학습 수행, 최대 혜택 금액이 기준치 이상이고 혜택 관련 결제수단이 구매 결제수단으로 이용된 샘플에 대해서는 제1 가중치보다 낮은 제3 가중치로 학습 수행하는 등).
다시 도 8을 참조하여 설명한다.
단계 S82에서, 사용자의 단말로부터 적어도 하나의 상품에 대한 구매 요청이 수신될 수 있다. 이에 대해서는 상술한 단계 S21의 설명 내용을 더 참고하도록 한다.
단계 S83에서, 딥러닝 모델의 입력을 구성하는 정보가 획득될 수 있다. 가령, 서비스 서버(11)는 사용자의 정보, 구매 요청된 상품의 정보, 사용자의 현재 컨텍스트 정보(e.g., 일반 컨텍스트, 결제 컨텍스트) 등을 획득할 수 있다. 필요에 따라, 서비스 서버(11)는 딥러닝 모델의 입력을 구성하지 않는 정보(e.g., 기 등록 결제수단 관련 정보 중 일부)를 더 획득할 수도 있다.
단계 S84에서, 획득된 정보를 학습된 딥러닝 모델에 입력하여 결제수단에 관한 예측을 수행할 수 있다. 가령, 서비스 서버(11)는 앞서 예시된 정보들(도 9 참고)을 학습된 딥러닝 모델(90)에 입력하여 결제수단의 유형, 결제수단, 결제수단의 개수 등을 예측할 수 있다. 이러한 예측은 대응되는 예측기들(e.g., 106, 107)을 통해 수행될 수 있는데, 이에 대해서는 도 10과 아래의 설명 내용을 더 참고하도록 한다.
단계 S85에서, 예측 결과에 기초하여 적어도 하나의 상품에 대한 구매 결제수단이 결정될 수 있다. 이렇게 결정된 구매 결제수단은 결제 인터페이스를 통해 사용자에게 제공될 수 있다.
예를 들어, 서비스 서버(11)는 학습된 딥러닝 모델(90)의 제1 예측기(106)를 통해 결제수단의 유형을 예측할 수 있다. 그리고, 서비스 서버(11)는 기 등록된 복수의 결제수단들 중에 예측된 유형(e.g., 컨피던스 스코어가 기준치 이상인 유형)에 속하는 결제수단을 구매 결제수단으로 결정할 수 있다.
다른 예로서, 서비스 서버(11)는 학습된 딥러닝 모델(90)의 제2 예측기(107)를 통해 결제수단을 예측할 수 있다. 그리고, 기 등록된 복수의 결제수단들 중에 예측 결제수단(e.g., 컨피던스 스코어가 기준치 이상인 결제수단)이 존재하는 경우, 서비스 서버(11)는 예측 결제수단을 구매 결제수단으로 결정할 수 있다. 기 등록된 복수의 결제수단들 중에 예측 결제수단이 존재하지 않는 경우라면, 서비스 서버(11)는 학습된 딥러닝 모델(90)의 제1 예측기(106)를 통해 결제수단의 유형을 예측하고, 예측된 유형에 속하는 결제수단을 구매 결제수단으로 결정할 수 있다. 또는, 서비스 서버(11)는 다른 방식(e.g., 도 2 내지 도 7에 예시된 방식 등)으로 구매 결제수단을 결정할 수도 있다.
또 다른 예로서, 서비스 서버(11)는 학습된 딥러닝 모델(90)의 제3 예측기(미도시)를 통해 결제수단의 개수를 예측할 수 있다. 그리고, 예측된 결제수단의 개수가 복수인 경우, 서비스 서버(11)는 N-1번째 결제수단의 정보를 학습된 딥러닝 모델(90)에 더 입력하는 방식으로 N번째 결제수단 관련 예측을 수행할 수 있다. 또한, 서비스 서버(110)는 예측 결과에 기초하여 구매 결제수단을 결정할 수 있다. 보다 구체적인 예로서, 서비스 서버(11)는 첫번째 결제수단 예측임을 나타내는 정보(e.g., 널 벡터, 미리 정의된 값을 갖는 벡터)를 제2 예측기(107)에 더 입력하여 첫번째 결제수단을 예측할 수 있다. 그리고, 서비스 서버(11)는 첫번째 결제수단의 정보를 제2 예측기(107)에 더 입력하여 두번째 결제수단을 예측할 수 있다. 이러한 예측 과정이 제3 예측기(미도시)를 통해 예측된 개수 또는 미리 설정된 횟수만큼 반복될 수 있고, 예측된 결제수단들이 구매 결제수단으로 결정될 수 있다. 다른 예로서, 다른 방식(e.g., 사용자의 선택, 도 2 내지 도 7에 예시된 방식 등)으로 첫번째 구매 결제수단이 결정된 경우, 서비스 서버(11)는 첫번째 구매 결제수단의 정보를 예측기들(106, 107)에 더 입력하여 두번째 구매 결제수단에 관한 예측을 수행할 수도 있다.
한편, 몇몇 실시예들에서는, 결제수단별 컨피던스 스코어에 기초하여 각 결제수단의 결제금액이 결정될 수도 있다. 가령, 서비스 서버(11)는 컨피던스 스코어가 기준치 이상인 결제수단들을 구매 결제수단으로 결정하고 해당 결제수단들의 컨피던스 스코어의 비율에 따라 각 결제수단의 결제 금액을 결정할 수도 있다(즉, 컨피던스 스코어에 비례하도록 각 결제수단의 결제 금액이 결정됨).
지금까지 도 8 내지 도 10을 참조하여 본 개시의 또 다른 몇몇 실시예들에 따른 결제 서비스 제공 방법에 대하여 설명하였다. 상술한 바에 따르면, 다수의 사용자들의 결제 이력 데이터(e.g., 사용자 정보, 상품 정보, 결제수단 정보 등)를 학습한 딥러닝 모델(90)을 이용하여 사용자의 구매 결제수단이 결정될 수 있다. 학습된 딥러닝 모델(90)은 상품의 특성, 사용자의 유형 등을 종합적으로 고려하여 해당 사용자의 선호 결제수단을 예측할 수 있기 때문에, 이 경우 해당 사용자가 선호하는 결제수단이 구매 결제수단으로 정확하게 결정될 수 있다.
지금까지 도 2 내지 도 10을 참조하여 설명된 결제 서비스 제공 방법에 관한 다양한 실시예들은 다양한 형태로 조합될 수 있다. 다시 말해, 서비스 서버(11)(또는 서비스 시스템(10))은 상술한 실시예들의 다양한 조합에 기초하여 결제 서비스를 제공할 수도 있다.
예를 들어, 도 11에 도시된 바와 같이, 서비스 서버(11)는 사용자 단말(13)의 구매 요청에 응답하여 사용자의 기 등록 결제수단들의 우선순위, 잔여 한도 금액 및 혜택 금액에 기초하여 적어도 하나의 상품에 대한 구매 결제수단을 결정할 수도 있다(S111 내지 S117). 구체적으로, 서비스 서버(11)는 최대 혜택 금액이 기준치 이상이라는 판단에 기초하여 최대 혜택 금액에 따라 구매 결제수단을 결정할 수 있고(S115, S116), 최대 혜택 금액이 기준치 미만이라는 판단에 기초하여 우선순위와 잔여 한도 금액에 따라 구매 결제수단을 결정할 수 있다(S115, S117).
다른 예로서, 최대 혜택 금액이 기준치 미만인 경우, 서비스 서버(11)는 학습된 딥러닝 모델(90)의 예측 결과, 실적 부족 금액 등에 기초하여 구매 결제수단을 결정할 수도 있다.
또 다른 예로서, 제1 상품은 최대 혜택 금액과 연관되고(즉, 적용 가능한 결제 혜택이 존재함) 제2 상품은 최대 혜택 금액과 무관한 경우(즉, 적용 가능한 결제 혜택이 없음), 서비스 서버(11)는 제1 상품에 대해서는 제1 결제수단(즉, 최대 혜택 금액과 연관된 결제수단임)을 구매 결제수단으로 결정하고 제2 상품에 대해서는 제2 결제수단을 구매 결제수단으로 결정할 수도 있다. 이때, 제2 결제수단은 우선순위, 잔여 한도 금액, 실적 부족 금액, 학습된 딥러닝 모델(90)의 예측 결과 등에 기초하여 결정될 수 있다.
또 다른 예로서, 서비스 서버(11)는 기 등록 결제수단들의 우선순위, 잔여 한도 금액, 실적 부족 금액, 학습된 딥러닝 모델(90)의 예측 결과를 종합적으로 고려하여 구매 결제수단을 결정할 수도 있다.
이하에서는, 도 12를 참조하여 본 개시의 몇몇 실시예들에 따른 서비스 시스템(10, e.g., 서비스 서버(11), 결제 서버(12))을 구현할 수 있는 예시적인 컴퓨팅 장치(120)에 대하여 설명하도록 한다.
도 12는 컴퓨팅 장치(120)를 나타내는 예시적인 하드웨어 구성도이다.
도 12에 도시된 바와 같이, 컴퓨팅 장치(120)는 하나 이상의 프로세서(121), 버스(123), 통신 인터페이스(124), 프로세서(121)에 의하여 수행되는 컴퓨터 프로그램(126)을 로드(load)하는 메모리(122)와, 컴퓨터 프로그램(126)을 저장하는 스토리지(125)를 포함할 수 있다. 다만, 도 12에는 본 개시의 실시예와 관련 있는 구성요소들만이 도시되어 있다. 따라서, 본 개시가 속한 기술분야의 통상의 기술자라면 도 12에 도시된 구성요소들 외에 다른 범용적인 구성요소들이 더 포함될 수 있음을 알 수 있다. 즉, 컴퓨팅 장치(120)에는 도 12에 도시된 구성요소 이외에도 다양한 구성요소가 더 포함될 수 있다. 또한, 경우에 따라, 도 12에 도시된 구성요소들 중 일부가 생략된 형태로 컴퓨팅 장치(120)가 구성될 수도 있다. 이하, 컴퓨팅 장치(120)의 각 구성요소에 대하여 설명한다.
프로세서(121)는 컴퓨팅 장치(120)의 각 구성의 전반적인 동작을 제어할 수 있다. 프로세서(121)는 CPU(Central Processing Unit), MPU(Micro Processor Unit), MCU(Micro Controller Unit), GPU(Graphic Processing Unit), NPU(Neural Processing Unit) 또는 본 개시의 기술 분야에 잘 알려진 임의의 형태의 프로세서 중 적어도 하나를 포함하여 구성될 수 있다. 또한, 프로세서(121)는 본 개시의 실시예들에 따른 동작/방법을 실행하기 위한 적어도 하나의 애플리케이션 또는 프로그램에 대한 연산을 수행할 수 있다. 컴퓨팅 장치(120)는 하나 이상의 프로세서를 구비할 수 있다.
다음으로, 메모리(122)는 각종 데이터, 명령 및/또는 정보를 저장할 수 있다. 메모리(122)는 본 개시의 실시예들에 따른 동작/방법을 실행하기 위하여 스토리지(125)로부터 컴퓨터 프로그램(126)을 로드할 수 있다. 메모리(122)는 RAM과 같은 휘발성 메모리로 구현될 수 있을 것이나, 본 개시의 기술적 범위가 이에 한정되는 것은 아니다.
다음으로, 버스(123)는 컴퓨팅 장치(120)의 구성요소 간 통신 기능을 제공할 수 있다. 버스(123)는 주소 버스(Address Bus), 데이터 버스(Data Bus) 및 제어 버스(Control Bus) 등 다양한 형태의 버스로 구현될 수 있다.
다음으로, 통신 인터페이스(124)는 컴퓨팅 장치(120)의 유무선 인터넷 통신을 지원할 수 있다. 또한, 통신 인터페이스(124)는 인터넷 통신 외의 다양한 통신 방식을 지원할 수도 있다. 이를 위해, 통신 인터페이스(124)는 본 개시의 기술 분야에 잘 알려진 통신 모듈을 포함하여 구성될 수 있다.
다음으로, 스토리지(125)는 하나 이상의 컴퓨터 프로그램(126)을 비임시적으로 저장할 수 있다. 스토리지(125)는 ROM(Read Only Memory), EPROM(Erasable Programmable ROM), EEPROM(Electrically Erasable Programmable ROM), 플래시 메모리 등과 같은 비휘발성 메모리, 하드 디스크, 착탈형 디스크, 또는 본 개시가 속하는 기술 분야에서 잘 알려진 임의의 형태의 컴퓨터로 읽을 수 있는 기록 매체를 포함하여 구성될 수 있다.
다음으로, 컴퓨터 프로그램(126)은 메모리(122)에 로드될 때 프로세서(121)로 하여금 본 개시의 다양한 실시예들에 따른 동작/방법을 수행하도록 하는 하나 이상의 인스트럭션을 포함할 수 있다. 즉, 프로세서(121)는 상기 하나 이상의 인스트럭션을 실행함으로써, 본 개시의 다양한 실시예들에 따른 동작/방법을 수행할 수 있다.
예를 들어, 컴퓨터 프로그램(126)은 사용자의 단말로부터 적어도 하나의 상품에 대한 구매 요청을 수신하는 동작, 상기 구매 요청에 응답하여, 사용자의 결제수단 관련 정보를 획득하는 동작 - 결제수단 관련 정보는 기 등록된 복수의 결제수단들의 우선순위를 포함하고 우선순위는 사용자에 의해 설정된 것임 -, 복수의 결제수단들 중 적어도 일부에 대한 결제 혜택 정보를 획득하는 동작, 결제 혜택 정보를 기초로 복수의 결제수단들 각각에 대한 혜택 금액을 계산하는 동작 및 혜택 금액과 우선순위에 기초하여 복수의 결제수단들 중에서 적어도 하나의 상품에 대한 구매 결제수단을 결정하는 동작을 수행하도록 하는 인스트럭션들을 포함할 수 있다.
다른 예로서, 컴퓨터 프로그램(126)은 도 1 내지 도 11을 참조하여 설명된 단계들/동작들의 적어도 일부를 수행하도록 하는 인스트럭션들을 포함할 수도 있다.
예시된 바와 같은 경우, 컴퓨팅 장치(120)를 통해 본 개시의 몇몇 실시예들에 따른 서비스 시스템(10, e.g., 서비스 서버(11))이 구현될 수 있다.
한편, 몇몇 실시예들에서, 도 12에 도시된 컴퓨팅 장치(120)는 클라우드 기술에 기반하여 구현된 가상 머신을 의미하는 것일 수도 있다. 가령, 컴퓨팅 장치(120)는 서버 팜(server farm)에 포함된 하나 이상의 물리 서버(physical server)에서 동작하는 가상 머신일 수 있다. 이 경우, 도 12에 도시된 프로세서(121), 메모리(122) 및 스토리지(125) 중 적어도 일부는 가상 하드웨어(virtual hardware)일 수 있으며, 통신 인터페이스(124) 또한 가상 스위치(virtual switch) 등과 같은 가상화된 네트워킹 요소로 구현된 것일 수 있다.
지금까지 도 12를 참조하여 본 개시의 몇몇 실시예들에 따른 서비스 시스템(10)을 구현할 수 있는 예시적인 컴퓨팅 장치(120)에 대하여 설명하였다.
지금까지 도 1 내지 도 12를 참조하여 본 개시의 다양한 실시예들 및 그 실시예들에 따른 효과들을 언급하였다. 본 개시의 기술적 사상에 따른 효과들은 이상에서 언급한 효과들로 제한되지 않으며, 언급되지 않은 또 다른 효과들은 아래의 기재로부터 통상의 기술자에게 명확하게 이해될 수 있을 것이다.
또한, 이상의 실시예들에서 복수의 구성요소들이 하나로 결합되거나 결합되어 동작하는 것으로 설명되었다고 해서, 본 개시의 기술적 사상이 반드시 이러한 실시예에 한정되는 것은 아니다. 즉, 본 개시의 기술적 사상의 목적 범위 안에서라면, 그 모든 구성요소들이 하나 이상으로 선택적으로 결합하여 동작할 수도 있다.
지금까지 설명된 본 개시의 기술적 사상은 컴퓨터로 판독가능한 기록매체 상에 컴퓨터가 판독가능한 코드로 구현될 수 있다. 컴퓨터 판독가능 기록매체에 기록된 컴퓨터 프로그램은 인터넷 등의 네트워크를 통하여 다른 컴퓨팅 장치에 전송되어 해당 컴퓨팅 장치에 설치될 수 있고, 이로써 해당 컴퓨팅 장치에서 사용될 수 있다.
도면에서 동작들이 특정한 순서로 도시되어 있지만, 반드시 동작들이 도시된 특정한 순서로 또는 순차적 순서로 실행되어야만 하거나 또는 모든 도시 된 동작들이 실행되어야만 원하는 결과를 얻을 수 있는 것으로 이해되어서는 안 된다. 특정 상황에서는, 멀티태스킹 및 병렬 처리가 유리할 수도 있다. 이상 첨부된 도면을 참조하여 본 개시의 다양한 실시예들을 설명하였지만, 본 개시가 속한 기술분야에서 통상의 지식을 가진 자는 그 기술적 사상이나 필수적인 특징을 변경하지 않고서 본 개시의 기술적 사상이 다른 구체적인 형태로도 실시될 수 있다는 것을 이해할 수 있다. 그러므로 이상에서 기술한 실시예들은 모든 면에서 예시적인 것이며 한정적인 것이 아닌 것으로 이해해야만 한다. 본 개시의 보호 범위는 아래의 청구범위에 의하여 해석되어야 하며, 그와 동등한 범위 내에 있는 모든 기술 사상은 본 개시에 의해 정의되는 기술적 사상의 권리범위에 포함되는 것으로 해석되어야 할 것이다.

Claims (15)

  1. 적어도 하나의 컴퓨팅 장치에서 수행되는 방법으로서,
    사용자의 단말로부터 적어도 하나의 상품에 대한 구매 요청을 수신하는 단계;
    상기 구매 요청에 응답하여, 상기 사용자의 결제수단 관련 정보를 획득하는 단계 - 상기 결제수단 관련 정보는 기 등록된 복수의 결제수단들의 우선순위를 포함하고 상기 우선순위는 상기 사용자에 의해 설정된 것임 -;
    상기 복수의 결제수단들 중 적어도 일부에 대한 결제 혜택 정보를 획득하는 단계;
    상기 결제 혜택 정보를 기초로 상기 복수의 결제수단들 각각에 대한 혜택 금액을 계산하는 단계; 및
    상기 혜택 금액과 상기 우선순위에 기초하여 상기 복수의 결제수단들 중에서 상기 적어도 하나의 상품에 대한 구매 결제수단을 결정하는 단계를 포함하는,
    결제 서비스 제공 방법.
  2. 제1항에 있어서,
    상기 결제 혜택 정보는 상기 적어도 하나의 상품에 대한 전자상거래 서비스의 사업자가 제공하는 결제 혜택 정보와 결제수단의 사업자가 제공하는 결제 혜택 정보를 포함하는,
    결제 서비스 제공 방법.
  3. 제1항에 있어서,
    상기 결제 혜택 정보는 요일, 날짜 및 시간에 따른 결제 혜택 정보를 포함하는,
    결제 서비스 제공 방법.
  4. 제1항에 있어서,
    상기 적어도 하나의 상품에 대한 구매 결제수단을 결정하는 단계는,
    상기 복수의 결제수단들에 대한 최대 혜택 금액이 기준치 이상이라는 판단에 기초하여 상기 최대 혜택 금액에 따라 상기 구매 결제수단을 결정하는 단계를 포함하는,
    결제 서비스 제공 방법.
  5. 제1항에 있어서,
    상기 적어도 하나의 상품에 대한 구매 결제수단을 결정하는 단계는,
    상기 복수의 결제수단들에 대한 최대 혜택 금액이 기준치 미만이라는 판단에 기초하여 상기 우선순위에 따라 상기 구매 결제수단을 결정하는 단계를 포함하는,
    결제 서비스 제공 방법.
  6. 제5항에 있어서,
    상기 결제수단 관련 정보는 상기 사용자에 의해 설정된 결제 한도 금액을 기준으로 계산된 잔여 한도 금액을 포함하고,
    상기 우선순위에 따라 상기 구매 결제수단을 결정하는 단계는,
    상기 복수의 결제수단들의 잔여 한도 금액에 더 기초하여 상기 구매 결제수단을 결정하는 단계를 포함하는,
    결제 서비스 제공 방법.
  7. 제6항에 있어서,
    상기 복수의 결제수단들의 잔여 한도 금액에 더 기초하여 상기 구매 결제수단을 결정하는 단계는,
    상기 우선순위가 가장 높은 제1 결제수단의 잔여 한도 금액이 상기 적어도 하나의 상품에 대한 결제 금액 미만이라는 판단에 기초하여, 상기 제1 결제수단과 제2 결제수단을 상기 구매 결제수단으로 결정하는 단계 - 상기 제2 결제수단은 상기 제1 결제수단 다음으로 우선순위가 높은 결제수단임 - 를 포함하는,
    결제 서비스 제공 방법.
  8. 제1항에 있어서,
    상기 결정된 구매 결제수단이 선택된 상태의 결제 인터페이스를 제공하는 단계를 더 포함하고,
    상기 결제 인터페이스는 상기 사용자로부터 추가 구매 결제수단을 선택받기 위한 인터페이스를 포함하는,
    결제 서비스 제공 방법.
  9. 제1항에 있어서,
    상기 결정된 구매 결제수단이 선택된 상태의 결제 인터페이스를 제공하는 단계를 더 포함하고,
    상기 결제 인터페이스는 상기 사용자로부터 둘 이상의 결제수단들의 조합을 등록받거나 상기 사용자의 입력에 기초하여 기 등록된 결제수단들의 조합을 불러오기 위한 인터페이스를 포함하는,
    결제 서비스 제공 방법.
  10. 제1항에 있어서,
    상기 결제수단 관련 정보는 상기 복수의 결제수단들 각각에 대한 실적 부족 금액을 포함하고,
    상기 실적 부족 금액에 기초하여 상기 복수의 결제수단들 중에서 다른 구매 결제수단을 결정하는 단계를 더 포함하는,
    결제 서비스 제공 방법.
  11. 제1항에 있어서,
    상기 결제수단 관련 정보는 상기 복수의 결제수단들 각각에 대한 실적 부족 금액을 포함하고,
    상기 결정된 구매 결제수단은 제1 결제수단 및 제2 결제수단을 포함하며,
    상기 실적 부족 금액에 기초하여 상기 제1 결제수단과 상기 제2 결제수단 각각의 결제 금액을 결정하는 단계를 더 포함하는,
    결제 서비스 제공 방법.
  12. 제1항에 있어서,
    결제 이력 데이터를 이용하여 학습된 딥러닝 모델을 획득하는 단계 - 상기 결제 이력 데이터는 학습용 사용자 정보, 학습용 상품 정보 및 학습용 결제수단 정보를 포함함 -;
    상기 사용자의 정보와 상기 적어도 하나의 상품의 정보를 상기 학습된 딥러닝 모델에 입력하여 결제수단에 관한 예측을 수행하는 단계; 및
    상기 예측의 결과에 기초로 상기 복수의 결제수단들 중에서 다른 구매 결제수단을 결정하는 단계를 더 포함하고,
    상기 딥러닝 모델은 상기 학습용 사용자 정보와 상기 학습용 상품 정보를 입력받고 제1 예측기를 통해 결제수단의 유형을 예측하는 제1 태스크와 제2 예측기를 통해 결제수단을 예측하는 제2 태스크를 수행함으로써 학습된 것인,
    결제 서비스 제공 방법.
  13. 제12항에 있어서,
    상기 딥러닝 모델은 제3 예측기를 통해 상품 구매에 이용된 결제수단의 개수를 예측하는 제3 태스크를 더 수행함으로써 학습된 것이고,
    상기 결제수단에 관한 예측을 수행하는 단계는,
    상기 학습된 딥러닝 모델의 상기 제3 예측기를 통해 상기 적어도 하나의 상품에 대한 결제수단의 개수를 예측하는 단계; 및
    상기 예측된 결제수단의 개수가 복수인 경우, 상기 결정된 구매 결제수단의 정보를 상기 학습된 딥러닝 모델에 더 입력하고 상기 학습된 딥러닝 모델의 상기 제2 예측기를 통해 상기 다른 구매 결제수단을 예측하는 단계를 포함하는,
    결제 서비스 제공 방법.
  14. 하나 이상의 프로세서; 및
    상기 하나 이상의 프로세서에 의해 실행되는 컴퓨터 프로그램을 저장하는 메모리를 포함하고,
    상기 컴퓨터 프로그램은:
    사용자의 단말로부터 적어도 하나의 상품에 대한 구매 요청을 수신하는 동작;
    상기 구매 요청에 응답하여, 상기 사용자의 결제수단 관련 정보를 획득하는 동작 - 상기 결제수단 관련 정보는 기 등록된 복수의 결제수단들의 우선순위를 포함하고 상기 우선순위는 상기 사용자에 의해 설정된 것임 -;
    상기 복수의 결제수단들 중 적어도 일부에 대한 결제 혜택 정보를 획득하는 동작;
    상기 결제 혜택 정보를 기초로 상기 복수의 결제수단들 각각에 대한 혜택 금액을 계산하는 동작; 및
    상기 혜택 금액과 상기 우선순위에 기초하여 상기 복수의 결제수단들 중에서 상기 적어도 하나의 상품에 대한 구매 결제수단을 결정하는 동작을 위한 인스트럭션들을 포함하는,
    결제 서비스 제공 시스템.
  15. 컴퓨팅 장치와 결합되어,
    사용자의 단말로부터 적어도 하나의 상품에 대한 구매 요청을 수신하는 단계;
    상기 구매 요청에 응답하여, 상기 사용자의 결제수단 관련 정보를 획득하는 단계 - 상기 결제수단 관련 정보는 기 등록된 복수의 결제수단들의 우선순위를 포함하고 상기 우선순위는 상기 사용자에 의해 설정된 것임 -;
    상기 복수의 결제수단들 중 적어도 일부에 대한 결제 혜택 정보를 획득하는 단계;
    상기 결제 혜택 정보를 기초로 상기 복수의 결제수단들 각각에 대한 혜택 금액을 계산하는 단계; 및
    상기 혜택 금액과 상기 우선순위에 기초하여 상기 복수의 결제수단들 중에서 상기 적어도 하나의 상품에 대한 구매 결제수단을 결정하는 단계를 실행시키기 위하여 컴퓨터로 판독가능한 기록매체에 저장된,
    컴퓨터 프로그램.
PCT/KR2023/009494 2023-06-27 2023-07-05 결제 서비스 제공 방법 및 그 시스템 Ceased WO2025005332A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020230082400A KR102671642B1 (ko) 2023-06-27 2023-06-27 결제 서비스 제공 방법 및 그 시스템
KR10-2023-0082400 2023-06-27

Publications (1)

Publication Number Publication Date
WO2025005332A1 true WO2025005332A1 (ko) 2025-01-02

Family

ID=91330093

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2023/009494 Ceased WO2025005332A1 (ko) 2023-06-27 2023-07-05 결제 서비스 제공 방법 및 그 시스템

Country Status (3)

Country Link
KR (3) KR102671642B1 (ko)
TW (2) TWI901533B (ko)
WO (1) WO2025005332A1 (ko)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20140047402A (ko) * 2012-10-12 2014-04-22 주식회사 케이티 결제 수단 관리 방법 및 그 시스템
KR20150013366A (ko) * 2013-07-25 2015-02-05 에스케이플래닛 주식회사 컨텐츠 구매에 따른 최적의 결제 수단 제공 시스템 및 방법
KR20170017294A (ko) * 2015-08-06 2017-02-15 에스케이플래닛 주식회사 최적 카드 추천 시스템, 결제시점에 따른 가중치 기반의 최적 카드 추천 장치 및 이를 이용한 방법
KR20210043418A (ko) * 2020-05-26 2021-04-21 정재철 복수의 지급 수단을 이용하는 결제 시스템 및 방법
KR102332915B1 (ko) * 2021-03-05 2021-12-01 쿠팡 주식회사 결제 수단의 혜택 정보를 제공하기 위한 장치 및 그 방법
KR102356726B1 (ko) * 2020-09-09 2022-02-07 김승훈 결제를 지원하기 위한 방법, 시스템 및 비일시성의 컴퓨터 판독 가능 기록 매체

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20170040868A (ko) 2015-10-06 2017-04-14 엄민 복합결제모듈을 포함한 분산결제 시스템
KR101826960B1 (ko) * 2016-05-31 2018-03-22 주식회사 하렉스인포텍 모바일 결제 방법 및 그 장치
TW202016835A (zh) * 2018-10-22 2020-05-01 鄭少茵 支付優惠資訊管理系統及其方法
JP2022167462A (ja) * 2021-04-23 2022-11-04 東芝テック株式会社 会計処理システム、クーポン管理装置及びその制御プログラム
CN116308465B (zh) * 2023-05-15 2023-09-01 深圳易派支付科技有限公司 一种基于移动支付的大数据分析系统

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20140047402A (ko) * 2012-10-12 2014-04-22 주식회사 케이티 결제 수단 관리 방법 및 그 시스템
KR20150013366A (ko) * 2013-07-25 2015-02-05 에스케이플래닛 주식회사 컨텐츠 구매에 따른 최적의 결제 수단 제공 시스템 및 방법
KR20170017294A (ko) * 2015-08-06 2017-02-15 에스케이플래닛 주식회사 최적 카드 추천 시스템, 결제시점에 따른 가중치 기반의 최적 카드 추천 장치 및 이를 이용한 방법
KR20210043418A (ko) * 2020-05-26 2021-04-21 정재철 복수의 지급 수단을 이용하는 결제 시스템 및 방법
KR102356726B1 (ko) * 2020-09-09 2022-02-07 김승훈 결제를 지원하기 위한 방법, 시스템 및 비일시성의 컴퓨터 판독 가능 기록 매체
KR102332915B1 (ko) * 2021-03-05 2021-12-01 쿠팡 주식회사 결제 수단의 혜택 정보를 제공하기 위한 장치 및 그 방법

Also Published As

Publication number Publication date
TWI881382B (zh) 2025-04-21
KR102671642B1 (ko) 2024-05-31
KR102743101B1 (ko) 2024-12-16
TWI901533B (zh) 2025-10-11
TW202526750A (zh) 2025-07-01
TW202501357A (zh) 2025-01-01
KR102950600B1 (ko) 2026-04-08
KR20250007450A (ko) 2025-01-14

Similar Documents

Publication Publication Date Title
WO2021020810A1 (en) Learning method of ai model and electronic apparatus
WO2023286895A1 (ko) 서비스 이용과 관련된 혜택 정보를 제공하는 방법 및 이를 위한 전자 장치
WO2022098101A1 (ko) 산지 경매가 기반의 농산물 공급자 중심 역경매 가격 산출 방법 및 시스템
WO2016195404A1 (ko) 수요 예측에 기반한 상품 가격 설정 방법 및 시스템
WO2023249154A1 (ko) 전자 장치 및 그의 정보 제공 방법
WO2022234949A1 (ko) 자동 광고 대행 서버, 광고 대상, 사용자, 또는 매체 정보에 대응하여 랜딩 페이지를 생성하여 제공하는 방법 및 상기 방법을 실행하기 위한 컴퓨터 프로그램
WO2017078414A1 (ko) 휴대용 통신 단말기의 첫 화면을 이용한 컨텐츠 제공방법
WO2024143685A1 (ko) 콘텐츠 추천 방법 및 그 시스템
WO2020171249A1 (ko) 매장 내 수익 데이터를 분석하는 서버 및 방법
WO2025014159A1 (ko) 데이터주체가 주도하고 통제하는 데이터베이스를 기반으로 하는 유저 표출 구매 원인 및 욕구 통찰 방식의 정보 운용 솔루션 제공방법
WO2024248205A1 (ko) 혜택 정보 처리 방법 및 전자 장치
KR102743101B1 (ko) 결제 서비스 제공 방법 및 그 시스템
WO2024005368A1 (ko) 검침 서비스 시스템 및 방법
KR20240109813A (ko) 쇼핑 가이드 서버 및 쇼핑 가이드 에이전트와, 이를 이용한 쇼핑 가이드 방법
WO2023286970A1 (ko) 온라인 광고 대행 서버, 캠페인 정보에 포함된 운영 옵션 정보를 선택적으로 변경하는 온라인 광고 대행 방법 및 상기 방법을 실행하기 위한 컴퓨터 프로그램
WO2024195931A1 (ko) 상품 페이지를 제공하는 방법, 장치 및 기록 매체
WO2025070875A1 (ko) 주문 요청에 대한 결제를 처리하는 방법, 장치 및 기록매체
WO2024195932A1 (ko) 구매 요청 처리 방법 및 전자 장치
WO2025121526A1 (ko) 복수 캠페인 환경에서의 고객별 자동 최적 메시지 생성 시스템 및 방법
WO2025263653A1 (ko) 쇼핑 가이드 서버 및 쇼핑 가이드 에이전트와, 이를 이용한 쇼핑 가이드 방법
WO2025220824A1 (ko) 전자 상거래 플랫폼의 멤버십 관리를 위한 방법, 전자 장치 및 기록 매체
WO2017122995A1 (ko) 수량 정보에 기반한 아이템의 판매 조건 결정 방법 및 장치
WO2024262685A1 (ko) 상품 구매 옵션 제공 방법 및 시스템
WO2025192845A1 (ko) 다중 플랫폼 간의 정보 공유를 위한 장치, 방법 및 기록매체
WO2025216378A1 (ko) 멤버십 가입에 따른 혜택 정보 표시를 위한 장치, 방법 및 기록 매체

Legal Events

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

Ref document number: 23943825

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE