Payment system, payment method, and program

Abstract

Improve the convenience for users. 【Solution means】The display control unit (101) of the payment system (1) causes the user terminal to display a setting screen for accepting a designation of settings related to installment payment, recurring payment, or bonus payment of payment means available on the user terminal (30). The processing execution unit (102) executes processing related to installment payment, recurring payment, or bonus payment based on the settings.

Description

Technical Field

[0001] The present disclosure relates to a payment system, a payment method, and a program.

Background Art

[0002] Conventionally, payment services provided on user terminals have been known. For example, Patent Document 1 describes a payment system in which a user obtains a split interest-bearing ticket for a user to purchase goods or services sold by a specific member who subscribes to a payment service in installments at the expense of the member, and performs installment payments using the split interest-bearing ticket in a payment application.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, with the technology of Patent Document 1, although a user can perform installment payments using a split interest-bearing ticket, the user cannot make settings related to installment payments on the user terminal. For this reason, with the technology of Patent Document 1, the convenience of the user cannot be sufficiently enhanced. This is not limited to installment payments such as those in Patent Document 1, but is the same for recurring payments or bonus payments. For this reason, with the conventional technology, the convenience of the user cannot be sufficiently enhanced.

[0005] One object of the present disclosure is to enhance the convenience of the user.

Means for Solving the Problems

[0006] The settlement system according to the present disclosure includes a display control unit that causes the user terminal to display a setting screen for accepting a designation of a setting related to installment payment, recurring payment, or bonus payment of settlement means available on the user terminal, and a process execution unit that executes a process related to the installment payment, the recurring payment, or the bonus payment based on the setting.

Effect of the Invention

[0007] The present disclosure can improve user convenience.

Brief Description of the Drawings

[0008]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Figure 24

Figure 25

Figure 26

Figure 27

Figure 28

Figure 29

Figure 30

Figure 31

Figure 32

Figure 33

Figure 34

Figure 35

Figure 36

Figure 37

[0009] [1. First Embodiment] An example of an embodiment of a settlement system, a settlement method, and a program according to the present disclosure, the first embodiment, will be described.

[0010] [1-1. Hardware Configuration of the Settlement System of the First Embodiment] FIG. 1 is a diagram showing an example of the hardware configuration of the settlement system of the first embodiment. For example, the settlement system 1 of the first embodiment includes a settlement server 10, a card server 20, a user terminal 30, and a store terminal 40. Each of the settlement server 10, the card server 20, the user terminal 30, and the store terminal 40 is connected to a network N such as the Internet or a LAN. Note that at least one of the settlement server 10, the card server 20, the user terminal 30, and the store terminal 40 may exist in multiple units.

[0011] The settlement server 10 is a server computer for settlement services. The settlement service is a service that provides users with electronic settlements (cashless settlements). For example, the settlement server 10 includes a control unit 11, a storage unit 12, and a communication unit 13. The control unit 11 includes at least one processor. The storage unit 12 includes at least one of a volatile memory such as a RAM and a non-volatile memory such as a flash memory. The communication unit 13 includes at least one of a communication interface for wired communication and a communication interface for wireless communication.

[0012] The card server 20 is a server computer for card services. The card service is a service operated by an administrator of cards available for payment services (for example, a card company that issues credit cards). Note that the administrator of the cards may or may not be the same as the administrator of the payment service. In the first embodiment, a credit card is described as an example of a card, but the card may be other cards other than a credit card. For example, the card may be a debit card, an electronic money card, a point card, or a transportation card. For example, the card server 20 includes a control unit 21, a storage unit 22, and a communication unit 23. The hardware configurations of the control unit 21, the storage unit 22, and the communication unit 23 may be the same as those of the control unit 11, the storage unit 12, and the communication unit 13, respectively.

[0013] The user terminal 30 is a user's computer. For example, the user terminal 30 is a smartphone, a tablet, a personal computer, or a wearable terminal. The user terminal 30 includes a control unit 31, a storage unit 32, a communication unit 33, an operation unit 34, a display unit 35, and a photographing unit 36. The hardware configurations of the control unit 31, the storage unit 32, and the communication unit 33 may be the same as those of the control unit 11, the storage unit 12, and the communication unit 13, respectively. The operation unit 34 is an input device such as a touch panel or a mouse. The display unit 35 is a display such as a liquid crystal or an organic EL. The photographing unit 36 includes at least one camera.

[0014] The store terminal 40 is a computer of a store where a user makes a payment using a payment service. The store is not limited to a physical store that a user actually visits and may be an online store. For example, the store terminal 40 may be a POS terminal, a self-checkout, a handheld terminal, a smartphone, a tablet, or a personal computer. The store terminal 40 includes a control unit 41, a storage unit 42, a communication unit 43, an operation unit 44, a display unit 45, and a reading unit 46. The hardware configurations of the control unit 41, the storage unit 42, the communication unit 43, the operation unit 44, and the display unit 45 may be the same as those of the control unit 11, the storage unit 12, the communication unit 13, the operation unit 34, and the display unit 35, respectively. The reading unit 46 includes at least one code reader or a reader / writer. The reading unit 46 may include at least one camera.

[0015] Note that the programs stored in the storage units 12, 22, 32, and 42 may be supplied to the payment server 10, the card server 20, the user terminal 30, or the store terminal 40 via the network N. Also, at least one of a reading unit (e.g., a memory card slot) for reading a computer-readable information storage medium and an input / output unit (e.g., a USB port) for inputting / outputting data with an external device may be included in the payment server 10, the card server 20, the user terminal 30, or the store terminal 40. For example, a program stored in the information storage medium may be supplied to the payment server 10, the card server 20, the user terminal 30, or the store terminal 40 via at least one of the reading unit and the input / output unit.

[0016] Also, the payment system 1 may include at least one computer. The computers included in the payment system 1 are not limited to the example of FIG. 1. For example, the payment system 1 may include only the payment server 10 and the user terminal 30. In this case, the card server 20 and the store terminal 40 exist outside the payment system 1. The payment system 1 may include only the payment server 10. In this case, the card server 20, the user terminal 30, and the store terminal 40 exist outside the payment system 1. For example, the payment system 1 may include the payment server 10 and other computers not shown in FIG. 1.

[0017] [1-2. Overview of the First Embodiment] In the first embodiment, a case where the payment service supports a plurality of payment methods is taken as an example. A payment method is a means used for payment. The payment method includes a payment method that can be set as a charging source and a payment source, which will be described later. For example, the payment method may be various cards such as a credit card as an example, electronic money, points, cryptocurrency, a wallet, an account such as a bank account, or other means. Codes such as barcodes or two-dimensional codes are also means for payment, so they correspond to payment methods. Since the payment method may be used for paying the price of goods or services provided by a store (hereinafter simply referred to as paying the price), it can also be called a payment means. The payment service may support only one payment method instead of a plurality of payment methods.

[0018] For example, the user uses the payment service from the payment application stored in the user terminal 30. The payment application is an application provided by the administrator of the payment service. When the user installs the payment application on the user terminal 30 and registers as a member of the payment service, the user can use the payment service from the payment application. For example, when the user operates the user terminal 30 to start the payment application, the user terminal 30 causes the display unit 35 to display the screen of the payment application. Note that the user may use the payment service from an application other than the payment application stored in the user terminal 30 (for example, an application of a credit card company or other non-payment-related application) or a browser.

[0019] FIG. 2 and FIG. 3 are diagrams showing an example of the screen of the payment application. For example, when the payment application is started, as shown in the upper left of FIG. 2, the user terminal 30 causes the display unit 35 to display a code screen SC1 including a code C10 generated based on a code ID that can temporarily identify the user. The code C10 is at least one of a barcode and a two-dimensional code. When the code C10 is read by the reading unit 46 of the store terminal 40, payment is executed based on the code ID obtained from the code C10. The basic flow of payment itself may be the same as that of a known payment service.

[0020] Note that the settlement may be executed by a method other than the method of having the store terminal 40 read the code C10. For example, the settlement may be of a type in which the code displayed on the store terminal 40 is read by the user terminal 30, a type in which the code posted in the store is read by the user terminal 30, a type that is completed only by an operation on the user terminal 30, a type in which the IC chip of the user terminal 30 is used, an online settlement (for example, an account settlement in which the user's account is used, an ID settlement in which the user's ID is used), a carrier settlement that is a settlement by the carrier used by the user terminal 30, or other types. For another example, a settlement may be executed in which the user reads the code on the bill with the user terminal 30 and pays the bill.

[0021] For example, the user can select any payment method as the payment source from among a plurality of payment methods available in the payment application. The payment source is the payment method used by the user for payment. The payment source can also be said to be the payment method that is the basis for payment. When the payment application does not support a plurality of payment methods and supports only one payment method, the user may not particularly need to select a payment source. That is, when the payment method available in the payment application is fixed to one, the user may not particularly need to select a payment source. By setting the priority order for a plurality of payment methods available in the payment application, the payment source may be automatically switched according to the set priority order.

[0022] For example, the code screen SC1 includes a panel P11 that indicates the current payer. In the upper left example of FIG. 2, the panel P11 indicates the information of the credit card "AAA Card" selected as the payer. When the user selects the panel P11, as shown in the upper right of FIG. 2, the user terminal 30 causes the display unit 35 to display a payer selection screen SC2 that includes a panel P20 indicating payment means selectable as the payer. In the upper right example of FIG. 2, the uppermost panel P20 indicates the current payer. When the user changes the payer, the user selects the second and subsequent panels P20. For example, the user can change the payer to electronic money or another credit card.

[0023] In the first embodiment, when a credit card is selected as the payer, the user can use installment payment, deferred payment, or bonus payment for paying the amount using the payment application. Installment payment is a payment method in which the usage amount is paid in multiple installments. Deferred payment is a payment method in which payment is made over a plurality of months so that the monthly payment amount is constant. Bonus payment is a payment method in which payment is made in a lump sum on a predetermined month. The meanings of installment payment, deferred payment, and bonus payment may be well-known meanings.

[0024] Hereinafter, taking the process of the user using installment payment from the payment application as an example, the process of the user using deferred payment or bonus payment from the payment application may be the same. The user may be allowed to arbitrarily select which of installment payment, deferred payment, and bonus payment to use. The payment application may support only installment payment, only deferred payment, only bonus payment, only installment payment and deferred payment, only installment payment and bonus payment, or only deferred payment and bonus payment.

[0025] In the example in the upper right of Figure 2, the payment app supports installment payments for the credit card selected as the payer. The user can specify the installment payment settings from the payer selection screen SC2. The user can pay the amount using the payment app without using installment payments, or can also pay the amount using installment payments with the payment app. In the example in the upper right of Figure 2, the user has not set up installment payments. In this case, when code C10 is read, a lump-sum payment of the credit card selected as the payer is made.

[0026] For example, when the user selects the top panel P20 showing the credit card selected as the payer, as shown in the lower left of Figure 2, the user terminal 30 causes the display unit 35 to display a modal M21 including a panel P210 showing the number of installments, so as to overlap the payer selection screen SC2. In the example in the lower left of Figure 2, when the user selects the top panel P210, the user can specify a setting indicating not to use installment payments. When the user selects the second and subsequent panels P210, the user can specify a setting indicating to use installment payments in the number of installments indicated by the panel P210.

[0027] For example, when the user selects the second and subsequent panels P210, as shown in the lower right of Figure 2, the user terminal 30 erases the modal M21 and displays the installment payment settings specified by the user on the top panel P20. In the example in the lower right of Figure 2, the user has specified a three-installment payment as the installment payment setting. When the user performs an operation to return to the code screen SC1, as shown on the left side of Figure 3, the user terminal 30 displays the installment payment settings specified by the user on the panel P11.

[0028] For example, when the store terminal 40 reads the code C10 displayed on the code screen SC1 on the left side of FIG. 3, installment payment is made based on the installment payment setting specified by the user. In the example on the left side of FIG. 3, installment payment in three installments specified by the user is made. Specifically, the payment from the settlement service or card service to the store (for example, bank transfer) is basically made in a lump sum, but the payment from the user to the credit card administrator (for example, automatic debit) will be made in three installments.

[0029] In the first embodiment, even if the user specifies an installment payment setting, an example is given where it is first processed as a lump sum payment and then changed to an installment payment. The details of the process of changing from a lump sum payment to an installment payment will be described later. When the settlement server 10 executes settlement based on the code ID received from the store terminal 40, as shown on the right side of FIG. 3, the user terminal 30 causes the display unit 35 to display a completion screen SC3 indicating that the payment has been completed. For example, a message indicating that the three installments specified by the user have been accepted is displayed on the completion screen SC3. Note that other information related to installment payment, such as a fee, may be displayed on the completion screen SC3 in addition to the number of times specified by the user.

[0030] When the user uses direct debit or bonus payment in the settlement app, in the same manner as FIGS. 2 and 3, the user may specify a direct debit or bonus payment setting from the payment source selection screen SC2. When the user specifies a direct debit or bonus payment setting, the panel P11 on the code screen SC1 shows the direct debit or bonus payment setting specified by the user. When the store terminal 40 reads the code C10, direct debit or bonus payment is made based on the direct debit or bonus payment setting specified by the user.

[0031] As described above, the settlement system 1 of the first embodiment is configured to display a payer selection screen SC2 for receiving a designation of settings related to installment payment, deferred payment, or bonus payment on the user terminal 30. In the settlement system 1, installment payment, deferred payment, or bonus payment in the use from the settlement application is performed based on the settings specified by the user. Hereinafter, the details of the settlement system 1 of the first embodiment will be described. In the following, it may be described as "installment payment, etc." as an abbreviation for "installment payment, deferred payment, or bonus payment". In the following description, the parts described as "installment payment, etc." can be read as "installment payment, deferred payment, or bonus payment".

[0032] [1-3. Functions Realized by the Settlement System of the First Embodiment] FIG. 4 is a diagram showing an example of functions realized by the settlement system 1 of the first embodiment. Each part realized by the settlement system 1 of the first embodiment can be configured by integrating them into one device or further dispersing the devices in more detail.

[0033] [1-3-1. Functions Realized by the Settlement Server] For example, the settlement server 10 includes a data storage unit 100, a display control unit 101, and a process execution unit 102. The data storage unit 100 is realized by the storage unit 12. Each of the display control unit 101 and the process execution unit 102 is realized by the control unit 11.

[0034] [Data Storage Unit] The data storage unit 100 stores various data in the settlement service. For example, the data storage unit 100 stores a settlement database DB1.

[0035] FIG. 5 is a diagram showing an example of a settlement database DB1. The settlement database DB1 is a database in which various types of information regarding users in the settlement service are stored. For example, the settlement database DB1 stores user IDs, passwords, code IDs, settlement means information, payer information, charging source information, settings such as installment payments, and usage information. The information stored in the settlement database DB1 is not limited to the example in FIG. 5. Other information may be stored in the settlement database DB1.

[0036] The user ID is an example of user identification information that can identify a user. Separate from the user ID, there may be a login account. The login account may be allowed to be freely changed by the user. The login account is also an example of user identification information. The password is information that is verified at the time of login. Since the code ID is also an ID that can identify a user in the settlement service, it is an example of user identification information. The code ID is updated every time the code C10 is displayed. The user identification information may be other information other than the user ID, the login account, and the code ID.

[0037] The settlement means information is information that can identify the settlement means. For example, the settlement means information is information such as a credit card number, information such as an electronic money number, information such as a bank account, or information such as a point card number. The payer information is information that can identify the settlement means selected as the payer. The charging source information is information that can identify the settlement means selected as the charging source. Charging is a process of increasing the balance of a settlement means having a balance. The charging source is the settlement means used for charging. It is the settlement means that serves as the original funds in charging. In the first embodiment, it is assumed that it is possible to charge electronic money from the settlement application. Charging may be a process of increasing the balance of a settlement means other than electronic money.

[0038] The installment payment setting is information indicating the specific setting content specified by the user. For example, the installment payment setting indicates whether to use installment payment or not. The installment payment setting may indicate not only whether to use installment payment or not, but also how to use installment payment (details of installment payment). For example, the installment payment setting may indicate the number of installments (number of payments) in installment payment, the payment amount or number of payments in direct debit, or the payment month in bonus payment. In the first embodiment, the setting specified by the user on the payment source selection screen SC2 is stored in the settlement database DB1.

[0039] Usage information is information related to the usage content of the payment application. The usage information can also be said to be information related to the payment executed from the payment application. In the first embodiment, since the payment is executed not only at the time of paying the price but also at the time of charging, the usage information can also be said to be information related to payment or charging. The usage information may indicate not only the payment made from the payment application but also other information such as the user's operation history with respect to the payment application. For example, when the usage information indicates past usage content, the usage information can also be said to be the usage history of the payment application. The usage information may indicate the content of the payment to be executed in the future. The usage information may include information such as an ID that can identify individual payments.

[0040] For example, when the payment of the price corresponds to the usage of the payment application, the usage information indicates the information of the payment means selected as the payment source, the usage amount, the usage date and time, and the usage store. The usage information may include information on the goods or services to be paid for. When the charge corresponds to the usage of the payment application, the usage information indicates the information of the payment means selected as the charge source, the charge amount, and the charge date and time. When the installment payment setting or the like is specified, the usage information may indicate the installment payment setting or the like specified at the time of usage. For example, the usage information may indicate the number of installments in installment payment, the payment amount or number of payments in direct debit, or the bonus month in bonus payment. The usage information can include any other information.

[0041] For example, when a user uses the payment application, the payment server 10 generates usage information indicating the usage details of the payment application and stores the usage information in the payment database DB1 in association with the user ID of the user. When the user makes a payment using the payment application, the payment server 10 generates usage information indicating the information of the payment method selected as the payment source, the presence or absence of installment payment, the usage amount, the usage date and time, and the usage store, and stores the usage information in the payment database DB1 in association with the user ID of the user. When the user makes a charge using the payment application, the payment server 10 generates usage information indicating the information of the payment method selected as the charge source, the charge amount, the presence or absence of installment payment, and the charge date and time, and stores the usage information in the payment database DB1 in association with the user ID of the user.

[0042] Note that the data stored in the data storage unit 100 is not limited to the above example. The data storage unit 100 may store data related to the payment service. For example, the data storage unit 100 may store data of various screens displayed on the payment application. The data storage unit 100 may store various data in the following description. For example, the data storage unit 100 may store a store database in which various information related to stores where the user can use the payment service is stored.

[0043] [Display control unit] The display control unit 101 causes the user terminal 30 to display the screen of the payment service. For example, the display control unit 101 causes the user terminal 30 to display the screen of the payment application. The display control unit 101 may cause the user terminal 30 to display the screen of another application or browser other than the payment application. For example, the display control unit 101 causes the user terminal 30 to display the screen by transmitting the display data of the screen to be displayed to the user terminal 30. The display data is data indicating all or part of the screen of the payment application. The display data may be in any format, for example, data of a markup language such as HTML, image data, or text data. The data storage unit 100 may store the display data itself transmitted to the user terminal 30, or may store the data necessary for generating the display data.

[0044] For example, the display control unit 101 causes the user terminal 30 to display a payment source selection screen SC2 that accepts designation of settings related to installment payment or the like of payment means available on the user terminal 30. In the first embodiment, since the user can use installment payment or the like for payment of the price, the display control unit 101 causes the user terminal 30 to display a payment source selection screen SC2 that accepts designation of settings for payment of the price to a store where payment means are available. The payment source selection screen SC2 is an example of a setting screen. Therefore, the part that describes the payment source selection screen SC2 can be read as a setting screen. Further, the payment source selection screen SC2 may be a screen on which the payment source (payment method) can be switched or its priority can be set. For example, the setting screen may be another screen such as a home screen, a payment screen, or a payment method management screen.

[0045] The setting screen is a screen that functions as a user interface for accepting designation of settings such as installment payment. The setting screen may include any part of the user interface. For example, the setting screen may include a panel, a button, a checkbox, a slider bar, other input forms, an icon, a link, text, or other images. In the first embodiment, the setting screen may be a screen on the user terminal 30. The setting screen is not limited to the payment source selection screen SC2. For example, the setting screen may be a home screen, a code screen SC1, a payment in progress screen (payment confirmation screen, for example, the confirmation screen SC5 described later), a completion screen SC3, a screen dedicated to settings such as installment payment, a screen of the usage history of the payment application, or other screens. The setting screen may be a screen other than the payment application. For example, in the following, a screen displayed on the browser of the user terminal 30 may correspond to the setting screen.

[0046] In the example of FIG. 2, when the user selects panel P11 of the code screen SC1, the user terminal 30 transmits a display request for the payment source selection screen SC2 to the payment server 10. The display request is data in a predetermined format indicating a request to display the payment source selection screen SC2 (for example, a request defined by a communication protocol such as HTTP, or data in a format defined by an API). When the payment server 10 receives a display request for the payment source selection screen SC2 from the user terminal 30, the display control unit 101 acquires the payment means information and the payment source information of the user who requested the display of the payment source selection screen SC2 from the payment database DB1, and generates display data for the payment source selection screen SC2. The display control unit 101 causes the payment source selection screen SC2 to be displayed on the user terminal 30 by transmitting the display data for the payment source selection screen SC2 to the user terminal 30.

[0047] Note that the display request for the payment source selection screen SC2 may include a user ID, or may include other information that can identify the user ID (for example, a session ID that can identify a session between the payment server 10 and the user terminal 30, or authentication information called a token stored in the user terminal 30). The display control unit 101 may specify which user's payment means information and payment source information should be acquired based on the user ID or other information included in the display request. It is assumed that data indicating the basic layout of the payment source selection screen SC2 is stored in the data storage unit 100. The display control unit 101 may generate the display data for the payment source selection screen SC2 by fitting text, images, etc. corresponding to the payment means information and the payment source information into the layout indicated by the data.

[0048] In addition, the display control unit 101 may include a script for displaying the modal M21 in the display data of the payer selection screen SC2. The script includes a code indicating that the modal M21 is to be displayed when the panel P20 of a payment method allowing installment payment or the like is selected. The user terminal 30 may execute the script to display the modal M21 superimposed on the payer selection screen SC2 without communicating with the payment server 10. Instead of including the script in the display data of the payer selection screen SC2, the display control unit 101 may communicate with the user terminal 30 when the user selects the panel P20 to display the modal M21 superimposed on the payer selection screen SC2. The display control unit 101 may also display the modal M21 superimposed on the payer selection screen SC2 by executing a program code included in the payment application instead of the script.

[0049] [Processing Execution Unit] Based on the settings such as installment payment specified on the setting screen using the payer selection screen SC2 as an example, the processing execution unit 102 executes processing related to installment payment or the like. In the first embodiment, since the user can use installment payment or the like for payment, the processing execution unit 102 executes processing related to installment payment or the like in payment based on the settings such as installment payment specified on the setting screen using the payer selection screen SC2 as an example.

[0050] The processing related to installment payment is processing that is directly or indirectly related to installment payment. For example, the processing related to installment payment may be processing for requesting an installment payment from the card server 20, processing for determining each payment amount in the installment payment, processing for determining the fee in the installment payment, processing for generating usage information indicating that it is the target of installment payment, or other processing. The processing related to installment payment may be simply storing data (data related to installment payment, etc.) in the payment server 10, or may be transmitting data (data related to installment payment, etc.) to the card server 20. In the first embodiment, since the case where the payment for the price is first processed as a lump-sum payment and then changed from a lump-sum payment to an installment payment by the card server 20 is taken as an example, the processing execution unit 102 executes the processing for generating usage information indicating that it is the target of installment payment as processing related to installment payment. The processing execution unit 102 stores the usage information in the payment database DB1, and at an arbitrary timing thereafter, transmits the usage information to the card server 20 and requests a change from a lump-sum payment to an installment payment. All or part of these series of processes may correspond to the processing related to installment payment. The usage information includes information related to payment or charge and information related to settings such as designated installment payment, etc. These pieces of information may be transmitted to the card server 20 at the same time, or may be transmitted to the card server 20 at different timings. The same applies to recurring payments and bonus payments.

[0051] The process related to direct debit is a process directly or indirectly related to direct debit. For example, the process related to direct debit may be a process of requesting direct debit from the card server 20, a process of determining the payment amount or frequency in direct debit, a process of determining the fee in direct debit, a process of generating usage information indicating that it is the object of direct debit, or other processes. In the first embodiment, taking the case where the payment of the price is first processed as a lump-sum payment and then changed from a lump-sum payment to a direct debit by the card server 20 as an example, the process execution unit 102 executes the process of generating usage information indicating that it is the object of direct debit as a process related to direct debit. The process execution unit 102 stores the usage information in the settlement database DB1, and at an arbitrary timing thereafter, transmits the usage information to the card server 20 and requests the change from a lump-sum payment to a direct debit. All or part of these series of processes may correspond to the process related to direct debit.

[0052] The process related to bonus payment is a process directly or indirectly related to bonus payment. For example, the process related to bonus payment may be a process of requesting bonus payment from the card server 20, a process of determining the payment amount in bonus payment, a process of determining the payment month in bonus payment, a process of generating usage information indicating that it is the object of bonus payment, or other processes. In the first embodiment, taking the case where the payment of the price is first processed as a lump-sum payment and then changed from a lump-sum payment to a bonus payment by the card server 20 as an example, the process execution unit 102 executes the process of generating usage information indicating that it is the object of bonus payment as a process related to bonus payment. The process execution unit 102 stores the usage information in the settlement database DB1, and at an arbitrary timing thereafter, transmits the usage information to the card server 20 and requests the change from a lump-sum payment to a bonus payment. All or part of these series of processes may correspond to the process related to bonus payment.

[0053] For example, when the store terminal 40 reads the code C10 on the code screen SC1 by the reading unit 46, it acquires the code ID from the code C10. The store terminal 40 transmits a payment request including the code ID to the payment server 10. The payment request is data in a predetermined format indicating that payment is requested (for example, a request defined by a communication protocol such as HTTP, or data in a format defined by an API). The payment server 10 receives the payment request from the store terminal 40. The processing execution unit 102 acquires the payer information and settings such as installment payment associated with the code ID indicated in the payment request from the payment database DB1. Note that the payer information and settings such as installment payment may be encoded in the code C10 and included in the payment request. Also, although the same applies to other embodiments and modifications, the payment server 10 may receive the payment request from the store terminal 40 or may receive the payment request from the user terminal 30.

[0054] For example, the processing execution unit 102 determines whether to execute processing such as installment payment based on the settings such as installment payment. When the settings such as installment payment indicate not to use installment payment, etc., the processing execution unit 102 does not determine to execute the processing such as installment payment, and when the settings such as installment payment indicate to use installment payment, etc., the processing execution unit 102 determines to execute the processing such as installment payment. In the first embodiment, the processing execution unit 102 generates usage information indicating that it is subject to installment payment, etc., and stores the usage information in the payment database DB1, thereby executing the processing such as installment payment. For example, the usage information may indicate not only information (such as a flag) indicating that it is subject to installment payment, etc., but also detailed setting contents such as the number of installments.

[0055] For example, when there is no installment payment or other such setting, the processing execution unit 102 executes normal payment processing (settlement data processing) that is not an installment payment or the like. This processing may follow the same flow as a known payment service. For example, as normal payment processing, the settlement data is linked from the settlement server 10 to the card server 20, and the card server 20 receives the settlement data, posts it (reflects it in the user's details) after several days, and performs processing for payment. The payment from the user to the card company is processed as a lump sum payment.

[0056] For example, when there is a setting for installment payment or the like, the processing execution unit 102 executes normal payment processing (settlement data processing) and processing for installment payment or the like (data processing for installment payment or the like). The normal payment processing is as described in the previous paragraph. As processing for installment payment or the like, the settlement data and data for installment payment or the like are linked from the settlement server 10 to the card server 20. The card server 20 receives the settlement data and performs various processes such as determination of installment payment or the like, posting, and payment. When it is determined that installment payment or the like is possible, the settlement data is changed from lump sum payment to installment payment and posted. When it is determined that installment payment or the like is not possible, it is posted as a lump sum payment. These determinations are made by the card server 20, and the determination results are linked to the settlement server 10. The settlement server 10 stores the determination results in a database such as the settlement database DB1 and notifies the user.

[0057] Note that the linking of the settlement data and the data for installment payment or the like may be linked separately or may be linked together simultaneously. The timing of the determination of the possibility of installment payment or the like and the posting may be at any timing. These may be performed simultaneously, or the posting may be performed after the determination of the possibility of installment payment or the like. The possibility of installment payment or the like may be determined after the posting. Taking the case where, after the determination of installment payment or the like, those for which installment payment or the like is possible are posted as installment payment or the like as an example, for those for which installment payment or the like is determined to be possible after being posted as a lump sum payment, it may be changed to installment payment or the like.

[0058] For example, the processing execution unit 102 acquires usage information on card payments made during a certain period (e.g., one day) from the settlement database DB1. The processing execution unit 102 transmits the acquired usage information to the card server 20 and requests posting to the card database DB2. Posting is a process of adding information to the usage details of the credit card. The posting itself may be a process adopted in known card services. The processing execution unit 102 may transmit the usage information to the card server 20 and request posting to the card database DB2 immediately after executing the first batch payment process. The card server 20 executes posting to the card database DB2 through the processing of the processing execution unit 201 described later. At that time, the payment of the usage information for which the payment of the amount was first processed as a batch payment is changed to installment payment or the like and posted. As a result, the payment is processed by installment payment or the like.

[0059] Note that the process of changing the initially executed batch payment to installment payment or the like may be executed by the settlement server 10 instead of the card server 20. In this case, the processing execution unit 102 may execute the installment payment or the like process by changing the initially batch payment indicated by the usage information. The processing execution unit 102 transmits the usage information changed to installment payment or the like to the card server 20. When the card server 20 receives the usage information changed to installment payment or the like, the processing execution unit 201 described later executes posting to the card database DB2 based on the usage information.

[0060] [1-3-2. Functions Realized by the Card Server] For example, the card server 20 includes a data storage unit 200 and a processing execution unit 201. The data storage unit 200 is realized by the storage unit 22. The processing execution unit 201 is realized by the control unit 21.

[0061] [Data Storage Unit] The data storage unit 200 stores various data in the card service. For example, the data storage unit 200 stores the card database DB2.

[0062] FIG. 6 is a diagram showing an example of the card database DB2. The card database DB2 is a database in which various types of information about users in the card service are stored. For example, the user ID, password, card information, and usage information are stored in the card database DB2. The information stored in the card database DB2 is not limited to the example of FIG. 6. Other information may be stored in the card database DB2. For example, information indicating the billing details (i.e., information indicating the details of the credit card) may be stored in the card database DB2 separately from the usage information.

[0063] In the first embodiment, the case where the user ID is common in the payment service and the card service is taken as an example, but the user ID of the payment service and the user ID of the card service may be different from each other. When the user ID of the payment service and the user ID of the card service are different from each other, it is assumed that a relationship database indicating the relationship between these user IDs is stored in the data storage unit 200. It may be possible to specify which user has which user ID by means of the relationship database. The relationship database may be stored in the data storage unit 100 of the payment server 10 instead of the data storage unit 200. The relationship database may be stored in another computer other than the payment server 10 or the card server 20, or in an external information storage medium.

[0064] The card information is information about the user's credit card. For example, the card information indicates the credit card number, expiration date, or cardholder name. The usage information is information about the usage of the card in the card service. For example, the usage information may be the usage amount, usage date and time, usage store, or other information. When the card is used, the card server 20 generates usage information and stores it in the card database DB2. The card server 20 generates usage information and stores it in the card database DB2 not only when the payment application is used but also when a plate-shaped card is used.

[0065] [Processing Execution Unit] The processing execution unit 201 executes processes such as installment payments made by the user using the payment application. In the first embodiment, since the payment for the price is first made in a lump sum, the processing execution unit 201 executes card payment for the lump sum payment and stores the usage information in the card database DB2. The processing execution unit 201 executes processes such as installment payments by, after the fact, changing the payment made in a lump sum to an installment payment or the like and posting the payment. For example, the processing execution unit 201 may post by changing the lump sum payment indicated by the usage information stored in the card database DB2 to an installment payment or the like, or may generate posting information separately from the usage information and store it in the card database DB2.

[0066] For example, when the card server 20 obtains the usage information of card payments made during a certain period (for example, one day) from the payment server 10 and receives a posting request, the processing execution unit 201 changes the lump sum payment indicated by the usage information to an installment payment or the like. The processing execution unit 201 posts for installment payments or the like by storing the usage information changed to an installment payment or the like in the card database DB2, or by generating posting information and storing it in the card database DB2. When the change from a lump sum payment to an installment payment or the like is made on the payment server 10 side, the processing execution unit 201 may post by storing the usage information received from the payment server 10 as it is in the card database DB2.

[0067] [1-3-3. Functions Realized by the User Terminal] For example, the user terminal 30 includes a data storage unit 300, an operation reception unit 301, and a display control unit 302. The data storage unit 300 is realized by the storage unit 32. The operation reception unit 301 and the display control unit 302 are realized by the control unit 31.

[0068] [Data Storage Unit] The data storage unit 300 stores data necessary for the user to use the payment service. For example, the data storage unit 300 stores the payment application. When the user uses the payment service from a browser instead of the payment application, the data storage unit 300 stores the browser.

[0069] [Operation Reception Unit] The operation reception unit 301 receives various operations of the user. For example, the operation reception unit 301 receives operations on the payment application. The operation reception unit 301 transmits data indicating the operation content of the user to the payment server 10.

[0070] [Display Control Unit] The display control unit 302 causes various screens to be displayed on the display unit 35. For example, the display control unit 302 causes the code screen SC1, the payment source selection screen SC2, and the completion screen SC3 to be displayed on the display unit 35. The display control unit 302 communicates with the payment server 10, receives the display data of these screens, and causes these screens to be displayed on the display unit 35 based on the display data.

[0071] [1-3-4. Functions Implemented by the Store Terminal] For example, the store terminal 40 includes a data storage unit 400 and a payment request transmission unit 401. The data storage unit 400 is realized by the storage unit 42. The payment request transmission unit 401 is realized by the control unit 41.

[0072] [Data Storage Unit] The data storage unit 400 stores data necessary for store-side processing in the payment service. For example, the data storage unit 400 stores a database in which various information such as the prices of products or services handled by the store is stored. The data storage unit 400 also stores information (such as price) of the product or service to be paid for. The data storage unit 400 may store a store ID that can identify the store. The store terminal 40 may obtain information on the product and price based on the reading result of the barcode of the product, etc., calculate the payment amount, and record it in the data storage unit 400.

[0073] [Payment Request Transmission Unit] The payment request transmission unit 401 transmits a payment request to the payment server 10. For example, when the store terminal 40 reads the code C10 with the reading unit 46, the payment request transmission unit 401 acquires the code ID from the code C10. The payment request transmission unit 401 transmits a payment request including information necessary for payment, such as the code ID, the payment amount, and the store ID, to the payment server 10. The payment request may be a request used in a known payment service. The payment request transmission unit 401 acquires the execution result of the payment from the payment server 10 and completes the payment of the price. These series of processes may also be processes adopted in a known payment service. In the first embodiment, even if a setting such as installment payment is specified, it is first processed as lump-sum payment, so the format of the payment request may be the same whether or not a setting such as installment payment is specified.

[0074] [1-4. Processes Executed in the Payment System of the First Embodiment] FIG. 7 is a diagram showing an example of a process executed in the payment system 1 of the first embodiment. The control units 11, 21, 31, and 41 execute the programs stored in the storage units 12, 22, 32, and 42, respectively, whereby the process of FIG. 7 is executed. In FIG. 7, among the processes executed in the payment system 1, the processes for executing installment payment and the like will be described.

[0075] As shown in FIG. 7, the user terminal 30 starts a payment application and executes a login process for the user to log in to the payment service with the payment server 10 (S100). The user terminal 30 executes a process for causing the payment server 10 to display the code screen SC1 on the display unit 35 (S101). In S101, the payment server 10 issues a new code ID based on a predetermined issuance rule and stores it in the payment database DB1. The payment server 10 transmits the code ID to the user terminal 30. When the user terminal 30 receives the code ID, it causes the code screen SC1 including the code C10 to be displayed on the display unit 35.

[0076] When the user selects panel P11, the user terminal 30 executes a process for displaying a payment source selection screen SC2 between the user terminal 30 and the payment server 10 (S102). In S102, when the payment server 10 receives a display request for the payment source selection screen SC2 from the user terminal 30, the payment server 10 generates display data for the payment source selection screen SC2 based on the payment means information and the payment source information stored in the payment database DB1, and transmits the display data to the user terminal 30. When the user terminal 30 receives the display data for the payment source selection screen SC2 from the payment server 10, the user terminal 30 causes the display unit 35 to display the payment source selection screen SC2.

[0077] When the user selects panel P20 indicating a card that allows installment payment or the like, the user terminal 30 executes a process for causing the display unit 35 to display a modal M21 that accepts the specification of installment payment or the like (S103). In S103, if the display data of the payment source selection screen SC2 includes a script for displaying the modal M21, the user terminal 30 displays the modal M21 based on the script. If the script is not included, the user terminal 30 may obtain the data of the modal M21 from the payment server 10 and display the modal M21. The process for displaying the modal M21 may be shown in the payment application.

[0078] When the user specifies an installment payment or the like setting in the modal M21, the user terminal 30 executes a process for reflecting the installment payment or the like setting specified by the user between the user terminal 30 and the payment server 10 (S104). In S104, the user terminal 30 transmits data indicating the setting specified by the user to the payment server 10. When the payment server 10 receives the data from the user terminal 30, the payment server 10 stores the setting indicated by the data in the payment database DB1 in association with the user ID of the user. Thereafter, the user terminal 30 executes a process for causing the code screen SC1 to be displayed on the display unit 35 again between the user terminal 30 and the payment server 10 (S105). The process of S105 is the same as the process of S101.

[0079] When the code reader 46 of the store terminal 40 reads the code C10 on the code screen SC1, the store terminal 40 sends a payment request to the payment server 10 based on the code ID obtained from the code C10 (S106). When the payment server 10 receives the payment request from the store terminal 40 (S107), it executes a payment process for card payment with the card server 20 (S108). In S108, it is first processed as a lump sum payment.

[0080] The payment server 10 obtains settings such as installment payment stored in the payment database DB1 (S109). The payment server 10 executes a process such as installment payment based on the settings such as installment payment specified by the user (S110). In S110, when the setting such as installment payment indicates that installment payment or the like is to be used, the payment server 10 generates usage information indicating that it is subject to installment payment or the like, and stores the usage information in the payment database DB1 in association with the code ID included in the payment request. The usage information may show details of settings such as the number of installments.

[0081] The payment server 10 executes a process for causing the user terminal 30 to display the completion screen SC3 on the display unit 35 (S111), and this process ends. In S111, the payment server 10 generates display data for the completion screen SC3 based on the processing results of each of S109 and S110, and sends it to the user terminal 30. The user terminal 30 receives the display data for the completion screen SC3 from the payment server 10, and displays the completion screen SC3 on the display unit 35. Thereafter, the payment server 10 executes a process for changing the lump sum payment to an installment payment or the like with the card server 20.

[0082] [Summary of the First Embodiment] The payment system 1 of the first embodiment causes the user terminal 30 to display a payer selection screen SC2 that accepts the specification of settings such as installment payments. The payment system 1 executes processing such as installment payments based on the settings such as installment payments. As a result, the user can use installment payments and the like from the payment application, so that the payment system 1 can improve the convenience for the user. For example, the user can use installment payments and the like by preparing a payment application without preparing a plate-shaped card, so that the user can use various payment methods with the payment application. The user can also complete the settings such as installment payments on the user terminal 30, so that the user can easily use installment payments and the like.

[0083] In addition, the payment system 1 causes the user terminal 30 to display a payer selection screen SC2 that accepts the specification of settings such as installment payments in the payment for the price of goods or services provided by the store. The payment system 1 executes processing such as installment payments in the payment for the price based on the settings such as installment payments. As a result, the user can use installment payments and the like from the payment application in the payment for the price, so that the payment system 1 can improve the convenience for the user in the payment for the price. For example, the user can use installment payments and the like by presenting the code screen SC1 of the payment application without presenting a plate-shaped card at the store, so that the user can use various payment methods with the payment application.

[0084] [2. Second Embodiment] An example of an embodiment of the payment system 1, the payment method, and the program according to the present disclosure, the second embodiment, will be described. In the second embodiment, the description of the same configuration as in the first embodiment will be omitted. For example, the hardware configuration of the payment system 1 may be the same as in the first embodiment.

[0085] [2-1. Outline of the Second Embodiment] In the second embodiment, an example is given where usage conditions are defined for installment payments and the like that are available from the payment application for the user. The usage conditions are the criteria for determining whether or not the use of installment payments and the like from the payment application is permitted. The usage conditions may be any conditions according to the usage content from the payment application. A plurality of usage conditions may be defined for installment payments and the like. For example, the usage conditions may be whether or not the payment for the price of goods or services provided by stores that support installment payments and the like is made, whether or not it is within the range of the usage limit for installment payments and the like, whether or not the usage amount is equal to or more than a predetermined amount, or other conditions. Each of the usage conditions for installment payments, recurring payments, and bonus payments may be the same as each other or may be different from each other. Note that for the corresponding stores, it may be determined based on the attribute information of the store (for example, the industry or category to which the store belongs), or it may be determined based on the credit information of the store (for example, whether there has been any fraud in the past). The usage conditions may be set by the user.

[0086] FIG. 8 is a diagram showing an example of the processing executed in the payment system 1 of the second embodiment. In the second embodiment, as in the first embodiment, an example is given where, after the payment of the price is first processed as a lump-sum payment, the lump-sum payment is changed to an installment payment or the like and processed. Further, an example is given where the change from a lump-sum payment to an installment payment or the like is executed by the card server 20. The change from a lump-sum payment to an installment payment or the like may be executed by the payment server 10, or may be executed by a computer other than the payment server 10 and the card server 20.

[0087] As shown in FIG. 8, when the code C10 on the code screen SC1 is read by the reading unit 46 of the store terminal 40, the payment server 10 communicates with the card server 20 and processes the payment as a lump-sum payment first. This is the same as described in the first embodiment. Even if the setting of an installment payment or the like is specified in the payment application, the store terminal 40 executes the same processing as a normal lump-sum payment. For this reason, even if installment payments and the like become possible in the payment application, there is no modification on the store terminal 40 side, so the man-hours for modification are reduced.

[0088] For example, when a predetermined timing (e.g., a predetermined time on a certain day) arrives, the settlement server 10 transmits usage information processed as a lump-sum payment to the card server 20 and requests the accounting process. As described in the first embodiment, it is assumed that the usage information of payments subject to installment payments or the like indicates that they are subject to installment payments or the like. When the card server 20 receives the usage information from the settlement server 10, it identifies the payments subject to installment payments or the like based on the usage information. The card server 20 determines whether the usage conditions are satisfied based on the usage information of the payments subject to installment payments or the like.

[0089] In the example of FIG. 8, the card server 20 determines whether (usage condition 1) the store for which the payment is made is not a store that does not support installment payments or the like, whether (usage condition 2) the usage is within the usage limit (e.g., installment limit) for installment payments or the like, and whether (usage condition 3) the amount of installment payments or the like is equal to or more than a predetermined amount (e.g., 50 yen). When it is determined that these usage conditions are satisfied, the card server 20 changes the lump-sum payment indicated by the usage information to an installment payment or the like and performs the accounting. When it is determined that these usage conditions are not satisfied, the card server 20 performs the accounting as a lump-sum payment without changing the lump-sum payment indicated by the usage information to an installment payment or the like.

[0090] As described above, the settlement system 1 of the second embodiment determines whether the usage conditions for installment payments or the like are satisfied. The settlement system 1 executes the process of installment payments or the like based on the execution result of the determination. Thereby, the settlement system 1 can prevent installment payments or the like that are not intended by the user, administrator, or the like from being made, thus improving the convenience for the user. Hereinafter, the details of the second embodiment will be described.

[0091] [2-2. Functions Realized by the Settlement System of the Second Embodiment] FIG. 9 is a diagram showing an example of functions realized by the payment system 1 of the second embodiment. In FIG. 9, some of the functions described in the first embodiment are not shown, but the payment system 1 of the second embodiment may include the functions described in the first embodiment. Each part realized by the payment system 1 of the second embodiment can be configured by integrating them into one device or further dispersing the devices more finely.

[0092] Note that the payment system 1 of the second embodiment may not include the functions described in the first embodiment (for example, the function for displaying a setting screen such as the payer selection screen SC2). For example, the payment system 1 of the second embodiment may not include the function for displaying a setting screen using the payer selection screen SC2 as an example. When the payment system 1 of the second embodiment does not include some of the functions described in the first embodiment, in the payment system 1 of the second embodiment, the user may not be able to specify settings such as installment payments from the setting screen. For example, the payment database DB1 may not store settings such as installment payments for each user. These points are the same for the third and fourth embodiments described later.

[0093] For example, when the payment system 1 of the second embodiment does not include the functions described in the first embodiment, the user may specify settings such as installment payments from other places (for example, a browser) other than the payment application. In this case, the setting screen such as the payer selection screen SC2 is not displayed in the payment application, but the user may specify settings such as installment payments from the screen displayed in other places. The payment database DB1 may store settings such as installment payments specified from the screen displayed in other places. These points are the same for the third and fourth embodiments described later.

[0094] For example, when the payment system 1 of the second embodiment does not include the functions described in the first embodiment, the user may declare that they will use installment payment or the like at the store. By operating the store terminal 40, it may be input that the user uses installment payment or the like in the payment application. The store terminal 40 may send a payment request indicating that the user uses installment payment or the like to the payment server 10. The payment request shall also include information corresponding to settings such as the number of installments. The payment server 10 may identify that the user uses installment payment or the like based on the payment request. These points are the same for the third and fourth embodiments described below.

[0095] As described above, an aspect in which the payment system 1 does not include the functions described in the first embodiment but includes the functions described in the second embodiment is within the scope of the present disclosure. Naturally, an aspect in which the payment system 1 includes the functions described in the first embodiment and the functions described in the second embodiment is also within the scope of the present disclosure. These points are matters that those skilled in the art can naturally understand from the description of the present disclosure.

[0096] [2-2-1. Functions Implemented by the Payment Server] For example, the payment server 10 includes a data storage unit 100 and a processing execution unit 102.

[0097] [Data Storage Unit] The data storage unit 100 may be the same as that in the first embodiment.

[0098] [Processing Execution Unit] The processing execution unit 102 may be the same as in the first embodiment. For example, when payment is instructed, if installment payment or the like is not specified, the processing execution unit 102 may process the payment in a lump sum in the same manner as when installment payment or the like is not specified, and execute processing for changing to installment payment or the like. This point is the same as in the first embodiment. The case where installment payment or the like is not specified can also mean the case where the user selects lump sum payment. In other words, the case where installment payment or the like is not specified is the same as the case of a conventional payment service where installment payment or the like cannot be selected. For example, when the processing execution unit 102 receives a payment request from the store terminal 40, it may execute lump sum payment without performing special processing for installment payment or the like.

[0099] For example, when a credit card is selected as the payment source, the processing execution unit 102 executes lump sum card payment with the card server 20. The method of executing the card payment may be the same as a known method. When a payment means other than a card (for example, electronic money, points, or a bank account) is selected as the payment source, the processing execution unit 102 executes lump sum payment with a server computer that manages the other payment means. The method of executing the payment for the other payment means may also be the same as a known method.

[0100] Note that the processing execution unit 102 may have all or part of the functions of the processing execution unit 102 described in the first embodiment. For example, the processing execution unit 102 may determine whether to execute processing for installment payment or the like based on the setting of installment payment or the like in the same manner as the processing execution unit 102 in the first embodiment. When the setting of installment payment or the like is not specified as in the first embodiment, the setting of installment payment or the like may be included in the payment request. The processing execution unit 102 may determine whether to execute processing for installment payment or the like based on these settings of installment payment or the like.

[0101] For example, after executing a preliminary lump-sum payment, the processing execution unit 102 may generate usage information indicating that it is subject to installment payment or the like in the same manner as the processing execution unit 102 in the first embodiment, and store the usage information in the settlement database DB1. For example, the usage information may include not only information (e.g., a flag or the like) indicating that it is subject to installment payment or the like, but also detailed setting contents such as the number of installments. With these pieces of information, it may be possible to identify that the payment is subject to installment payment or the like.

[0102] [2-2-2. Functions Realized by the Card Server] For example, the card server 20 includes a data storage unit 200, a processing execution unit 201, a usage information acquisition unit 202, and a usage condition determination unit 203. Each of the usage information acquisition unit 202 and the usage condition determination unit 203 is realized by the control unit 21. Note that at least one of the usage information acquisition unit 202 and the usage condition determination unit 203 may be realized in the settlement server 10.

[0103] [Data Storage Unit] The data storage unit 200 may be the same as that in the first embodiment. In the second embodiment, the data storage unit 200 stores usage condition data indicating usage conditions. The usage condition data may indicate only one usage condition or a plurality of usage conditions. In the example of FIG. 8, since three usage conditions are defined, the usage condition data indicates the three usage conditions. The usage condition data may be in any format. For example, the usage condition data may be in a table format, a mathematical formula format, a part of a program, a machine learning model, or another format. The usage condition data may be determined by the administrator of the settlement service or the administrator of the card service (card issuer).

[0104] [Usage Information Acquisition Unit] The usage information acquisition unit 202 acquires usage information regarding the use of payment means available on the user terminal 30. In the second embodiment, the case where the usage information indicates the usage content in the past usage is taken as an example. However, as in the modification example described later, the usage information may indicate the usage content in the usage to be performed in the future (future usage). The usage information acquisition unit 202 may acquire usage information indicating the use of the payment application to be the determination target of the usage conditions. The usage information acquisition unit 202 may acquire an arbitrary number of usage information. For example, the usage information acquisition unit 202 may acquire usage information indicating a plurality of usages performed during a certain period. The usage information acquisition unit 202 may acquire the usage information of each of a plurality of users.

[0105] In the second embodiment, similar to the first embodiment, it is assumed that the usage information is stored in the payment database DB1. The usage information acquisition unit 202 acquires the usage information from the payment server 10 that manages the payment database DB1. The usage information may be stored in another database other than the payment database DB1. The usage information acquisition unit 202 may acquire the usage information from another database. The usage information may be stored in another computer other than the payment server 10 or an external information storage medium. The usage information acquisition unit 202 may acquire the usage information from another computer or an external information storage medium.

[0106] In the second embodiment, similar to the first embodiment, the case where the payment of the price corresponds to the use of the payment application is taken as an example. The usage information acquisition unit 202 acquires the usage information in the payment of the price of the goods or services provided by the store where the payment means can be used. For example, the usage information indicates the information of the payment source used in the payment of the price (for example, information capable of identifying the payment means such as a part of the credit card number), the usage amount, the usage date and time, and the usage store. The usage information may indicate whether it is a target of installment payment or the like, or may indicate the details of installment payment or the like (for example, the number of installments).

[0107] In the second embodiment, an example is given where the timing of posting usage information is visited regularly. For example, a predetermined time on a certain day may correspond to the timing of posting usage information. In this case, the usage information acquisition unit 202 determines whether the timing of posting usage information has been visited by determining whether a predetermined time on a certain day has been visited. The time interval between the timings of posting usage information is not limited to one day and may be any time interval. For example, the timing of posting usage information may be visited every few hours, every few days, every week, or other time intervals. When it is determined that the timing of posting usage information has been visited, the usage information acquisition unit 202 acquires usage information including usage date and time during the period from the most recent determination timing to the current time.

[0108] Note that the usage information acquisition unit 202 may also determine whether the timing of posting usage information has been visited by determining whether a predetermined time has elapsed since the usage date and time. In this case, the usage information acquisition unit 202 determines whether the timing of posting usage information has been visited for each individual usage. The usage information acquisition unit 202 acquires the usage information for which it is determined that the timing of posting usage information has been visited. Particularly when the posting timing is not determined, the usage information acquisition unit 202 may acquire usage information from the settlement server 10 each time usage information is generated in the settlement server 10.

[0109] [Usage Condition Determination Unit] The usage condition determination unit 203 determines whether usage conditions regarding the use of payment methods such as installment payments are satisfied based on the usage information acquired by the usage information acquisition unit 202. For example, the usage condition determination unit 203 acquires usage condition data stored in the data storage unit 200 and determines whether the usage information satisfies the usage conditions indicated by the usage condition data. When a plurality of usage conditions are indicated in the usage condition data, the usage condition determination unit 203 determines whether each of the plurality of usage conditions is satisfied.

[0110] In the example of FIG. 8, the usage condition determination unit 203 determines whether Usage Condition 1 is satisfied by determining whether the store subject to payment is not a non-corresponding store such as installment payment based on the usage information acquired by the usage information acquisition unit 202. In other words, the usage condition determination unit 203 determines whether Usage Condition 1 is satisfied by determining whether the store subject to payment is a corresponding store such as installment payment based on the usage information acquired by the usage information acquisition unit 202. There may be corresponding stores that correspond only to a part of installment payment, etc., such as corresponding to installment payment but not to recurring payment.

[0111] For example, the data storage unit 200 stores a correspondence database indicating at least one of corresponding stores and non-corresponding stores. The usage condition determination unit 203 determines whether Usage Condition 1 is satisfied based on the correspondence database. If corresponding stores are defined in the correspondence database, the usage condition determination unit 203 determines that the store indicated by the usage information is a corresponding store if the store is defined in the correspondence database, and determines that the store is a non-corresponding store if the store is not defined in the correspondence database. If non-corresponding stores are defined in the correspondence database, the usage condition determination unit 203 determines that the store indicated by the usage information is a non-corresponding store if the store is defined in the correspondence database, and determines that the store is a corresponding store if the store is not defined in the correspondence database.

[0112] For example, the usage condition determination unit 203 determines whether Usage Condition 3 is satisfied by determining whether the usage is within the user's usage limit based on the usage information acquired by the usage information acquisition unit 202. In other words, the usage condition determination unit 203 determines whether Usage Condition 3 is satisfied by determining whether the usage exceeds the user's usage limit. The usage limit is the range in which installment payment, etc. is possible. The usage limit may also be called an installment limit. The usage limit may be a limit adopted in known installment payment, etc.

[0113] In the second embodiment, assume that the usage limit information indicating the user's usage limit is stored in the card database DB2. The usage limit information may indicate the total amount of the usage limit assigned to the user, or may indicate the remaining amount of the usage limit. The usage condition determination unit 203 identifies the usage limit based on the usage limit information of the user from whom the usage information has been acquired, and determines whether the usage amount indicated by the usage information is within the range of the usage limit. When the usage limit information is stored in a database other than the card database DB2, the usage condition determination unit 203 may acquire the usage limit information from the other database.

[0114] For example, the usage condition determination unit 203 determines whether usage condition 3 is satisfied by determining whether the usage amount such as installment payment is equal to or greater than a predetermined amount based on the usage information acquired by the usage information acquisition unit 202. Assume that the predetermined amount information indicating the predetermined amount is stored in the data storage unit 100. The predetermined amount may be common to all stores, or may be determined for each store or each user. The usage condition determination unit 203 determines whether usage condition 3 is satisfied based on the predetermined amount information stored in the data storage unit 100 and the usage amount indicated by the usage information.

[0115] In the second embodiment, as in the first embodiment, take the case where the payment of the price corresponds to the use of the settlement application as an example. The usage condition determination unit 203 determines whether the usage conditions for the payment of the price are satisfied based on the usage information. The usage condition determination unit 203 determines whether the usage condition indicating whether the user can use installment payment or the like for the payment of the price is satisfied. The method for determining the usage conditions is as described above.

[0116] In the second embodiment, as in the first embodiment, take the case where, first, lump-sum payment is executed and then the lump-sum payment is changed to installment payment or the like for processing as an example. The usage condition determination unit 203 determines whether the usage conditions are satisfied after the first lump-sum payment is executed. For example, when the posting timing of the usage information arrives, the usage condition determination unit 203 determines whether the usage conditions are satisfied based on the usage information.

[0117] Note that the usage condition determination unit 203 may determine only one or two of the usage conditions 1 to 3. The usage condition determination unit 203 may also determine other usage conditions other than the usage conditions 1 to 3. For example, when only a specific product or service is subject to installment payment or the like, the usage condition determination unit 203 may determine whether the usage condition is satisfied by determining whether the product or service is subject to installment payment or the like. When an upper limit number of times (for example, 10 times or less per month) of the number of times of using installment payment or the like that a user can use within a certain period (for example, one month) is determined, the usage condition determination unit may determine whether the usage condition is satisfied by determining whether the upper limit number of times of the number of times of use has been reached.

[0118] [Processing execution unit] Based on the determination result of the usage condition determination unit 203, the processing execution unit 201 executes processing related to installment payment or the like. When it is determined that the usage condition is not satisfied, the processing execution unit 201 does not execute the processing such as installment payment. When it is determined that the usage condition is satisfied, the processing execution unit 201 executes the processing such as installment payment. The processing execution unit 201 executes the processing such as installment payment on the condition that the usage condition is satisfied. The meaning of the processing such as installment payment may be the same as that in the first embodiment. Note that the processing execution unit 201 in the second embodiment may execute the same processing as that in the first embodiment.

[0119] For example, when a plurality of usage conditions are determined, when it is determined that at least some of the usage conditions are not satisfied, the processing execution unit 201 does not execute the processing such as installment payment. When it is determined that all the usage conditions are satisfied, the processing execution unit 201 may execute the processing such as installment payment. When it is determined that a predetermined number or more of the usage conditions are not satisfied, the processing execution unit 201 does not execute the processing such as installment payment. When it is determined that a predetermined number or more of the usage conditions are satisfied, the processing execution unit 201 may execute the processing such as installment payment.

[0120] In the second embodiment, similar to the first embodiment, the case where the payment of the price corresponds to the use of the payment application is taken as an example. Based on the determination result of the use condition determination unit 203, the processing execution unit 201 executes processing such as installment payment in the payment of the price. When it is determined that the use conditions are not satisfied, the processing execution unit 201 does not execute processing such as installment payment in the payment of the price. When it is determined that the use conditions are satisfied, the processing execution unit 201 executes processing such as installment payment in the payment of the price.

[0121] In the second embodiment, similar to the first embodiment, the case where, first, lump-sum payment is executed and then the lump-sum payment is changed to installment payment or the like for processing is taken as an example. After first executing the lump-sum payment, the processing execution unit 201 executes processing such as installment payment in the payment of the price. When it is determined that the use conditions are not satisfied, the processing execution unit 201 processes the lump-sum payment as it is without changing the lump-sum payment in the payment of the price to installment payment or the like. When it is determined that the use conditions are satisfied, the processing execution unit 201 changes the lump-sum payment in the payment of the price to installment payment or the like for processing.

[0122] [2-2-3. Functions Realized by the User Terminal] The functions of the user terminal 30 may be the same as those in the first embodiment.

[0123] [2-2-4. Functions Realized by the Store Terminal] The functions of the store terminal 40 may be the same as those in the first embodiment.

[0124] [2-3. Processing Executed by the Payment System in the Second Embodiment] FIG. 10 is a diagram showing an example of the processing executed by the payment system 1 in the second embodiment. In FIG. 10, among the processing executed by the payment system 1, the processing related to the determination of the use conditions will be described. For example, after the processing of S100 to S111 described in the first embodiment is executed, the processing of FIG. 10 may be executed. The processing of FIG. 10 is executed by the control units 11 and 21 executing the programs stored in the storage units 12 and 22, respectively.

[0125] As shown in FIG. 10, the settlement server 10 determines whether the billing timing of usage information (for example, a predetermined time within a day) has arrived (S200). In S200, the settlement server 10 determines whether the billing timing of usage information has arrived by determining whether the predetermined time has arrived. In S200, if it is determined that the billing timing of usage information has not arrived (S200: N), the process returns to S200 again.

[0126] In S200, if it is determined that the billing timing of usage information has arrived (S200: Y), the settlement server 10 acquires usage information to be the target of usage condition determination from the settlement database DB1 (S201). In S201, the settlement server 10 acquires usage information including the usage date and time during the period from the most recent determination timing to the current time from the settlement database DB1. The settlement server 10 transmits the usage information acquired in S201 to the card server 20 (S202). The card server 20 acquires the usage information from the settlement server 10 (S203).

[0127] The card server 20 identifies payments subject to installment payments or the like based on the usage information, and determines whether the usage conditions are satisfied based on the usage information of the identified payments (S204). In S204, if it is determined that the usage conditions are satisfied (S204: Y), the settlement server 10 changes the usage information determined to satisfy the usage conditions from lump-sum payment to installment payment or the like and performs billing (S205). In S204, if it is determined that the usage conditions are not satisfied (S204: N), the settlement server 10 performs billing for the usage information determined to satisfy the usage conditions as lump-sum payment without executing the process of S205 (S206).

[0128] The card server 20 determines whether the posting of usage information has been completed (S207). In S207, the card server 20 determines whether the processing after S204 has been executed for all usage information subject to installment payments or the like. In S207, if it is determined that the posting of the usage information has not been completed (S207:N), the process returns to the process of S204. The card server 20 posts the usage information that has not yet been posted. In S207, if it is determined that the posting of the usage information has been completed (S207:Y), this process ends.

[0129] [2-4. Summary of the Second Embodiment] The settlement system 1 of the second embodiment acquires usage information regarding the use of settlement means available in the settlement application. The settlement system 1 determines whether usage conditions regarding use such as installment payments are satisfied based on the usage information. The settlement system 1 executes processing such as installment payments based on the determination result of the usage conditions. Thereby, since the settlement system 1 can make the determination of whether the usage conditions are satisfied a condition for executing processing such as installment payments, it is possible to prevent unintended installment payments or the like from being executed by administrators or users of settlement services, etc., and improve the convenience for users. Also from the perspective of administrators and stores, it is possible to prevent unintended installment payments or the like from being executed, so the settlement system 1 can improve the convenience for administrators and stores. For example, the settlement system 1 can prevent installment payments or the like from being made at non-corresponding stores that do not support installment payments or the like. The settlement system 1 can prevent installment payments or the like that exceed the user's usage limit from being made. The settlement system 1 can prevent low-amount installment payments or the like from being made.

[0130] In addition, the settlement system 1 acquires usage information in the payment for the price of goods or services provided by stores where the settlement means are available. The settlement system 1 determines whether usage conditions in the payment for the price are satisfied based on the usage information. The settlement system 1 executes processing in the payment for the price based on the determination result of the usage conditions. Thereby, since the settlement system 1 can prevent unintended installment payments or the like from being executed in the payment for the price, it is possible to improve the convenience for users.

[0131] Also, when payment of the price is instructed, the payment system 1 processes the payment of the price in a lump sum in the same manner as when installment payment or the like is not specified, and executes a process for changing to installment payment or the like. Thereby, the payment system 1 can provide the user with functions such as installment payment without modifying the store terminal 40 side. Even if the usage conditions are not satisfied, the payment system 1 can be processed as a lump sum payment as it is, so that the convenience for the user can also be improved.

[0132] [3. Third Embodiment] An example of an embodiment of the payment system 1, the payment method, and the program according to the present disclosure, a third embodiment, will be described. In the third embodiment, the description of the same configuration as in the first embodiment or the second embodiment will be omitted. For example, the hardware configuration of the payment system 1 may be the same as that in the first embodiment.

[0133] [3-1. Outline of the Third Embodiment] In the third embodiment, an example is given in which the setting of installment payment or the like is automatically canceled based on a predetermined cancellation condition. The cancellation condition is a criterion for determining whether or not the setting of installment payment or the like is canceled. The cancellation condition may be any condition defined in the payment service. A plurality of conditions may be combined as the cancellation condition. For example, the cancellation condition may be that the payment application is used in a state where the setting of installment payment or the like is made, the payment application is terminated, the payment application migrates from the foreground to the background, a predetermined time has elapsed since the setting of installment payment or the like was made, the expiration date set for the code ID has elapsed, or other conditions. The cancellation condition may be that the usage conditions are not satisfied. When the usage conditions are not satisfied, the setting of installment payment or the like may be automatically canceled.

[0134] In the third embodiment, similar to the first and second embodiments, an example is given where a user uses a payment service from a payment app. However, the user may use the payment service from means other than the payment app. For example, the user may cause the browser of the user terminal 30 to display the code C10 and use the payment service from the browser. The user may use the payment service from the IC chip of the user terminal 30 instead of the screen displayed on the user terminal 30 (e.g., touch payment). The user may use the payment service with a card such as an IC card or a magnetic card (physical plate-shaped card) instead of the user terminal 30. The user may use the payment service by biometric authentication without using media such as the user terminal 30 and the card.

[0135] FIG. 11 is a diagram showing an example of processing executed in the payment system 1 of the third embodiment. In the third embodiment, an example is given where the execution of payment in a state where a setting such as installment payment is specified corresponds to a release condition. For example, when the user specifies a setting such as installment payment in the same manner as in the first embodiment, as shown in the upper left of FIG. 11, the user terminal 30 causes the display unit 35 to display a code screen SC1 including a panel P11 indicating that a setting such as installment payment has been made.

[0136] For example, when the code C10 is read by the store terminal 40, as shown in the upper right of FIG. 11, the user terminal 30 causes the display unit 35 to display a completion screen SC3 indicating that the payment for the price has been completed. The completion screen SC3 may be configured to indicate that the installment payment setting or the like has been released. When the user performs an operation to return to the code screen SC1, as shown in the lower left of FIG. 11, the user terminal 30 causes the display unit 35 to display a code screen SC1 including a panel P11 indicating that the installment payment setting or the like has been released. When the user desires to set installment payment or the like for the next payment, the user specifies the installment payment setting or the like again in the same flow as in the first embodiment.

[0137] As described above, the payment system 1 of the third embodiment cancels the installment payment setting or the like based on a cancellation condition where the payment is executed in a state where the installment payment setting or the like is specified. As a result, the user does not need to manually cancel the installment payment setting or the like, so that the payment system 1 can reduce the operation burden on the user and improve the convenience for the user. Hereinafter, the details of the third embodiment will be described.

[0138] [3-2. Functions Realized by the Payment System of the Third Embodiment] FIG. 12 is a diagram showing an example of functions realized by the payment system 1 of the third embodiment. In FIG. 12, some functions described in the first embodiment and the second embodiment are not shown, but the payment system 1 of the third embodiment may include the functions described in the first embodiment and the second embodiment. Each part realized by the payment system 1 of the third embodiment can be configured by being integrated into one device or further dispersing the devices more finely.

[0139] Note that the payment system 1 of the third embodiment may not include at least one of the functions described in the first embodiment (for example, the function for displaying a setting screen such as the payment source selection screen SC2) and the functions described in the second embodiment (for example, the function for determining usage conditions and related functions). For example, the payment system 1 of the third embodiment may execute an installment payment or the like for which usage conditions are not particularly defined. This point is the same for the fourth embodiment described later.

[0140] As described above, an aspect in which the payment system 1 does not include at least one of the functions described in the first embodiment and the functions described in the second embodiment and includes the functions described in the third embodiment is within the scope of the present disclosure. An aspect in which the payment system 1 includes the at least one and the functions described in the third embodiment is, of course, also within the scope of the present disclosure. These points are matters that those skilled in the art can naturally understand from the description of the present disclosure.

[0141] [3-2-1. Functions Realized by the Payment Server] For example, the payment server 10 includes a data storage unit 100, a processing execution unit 102, a setting acquisition unit 104, and a setting release unit 105. The setting acquisition unit 104 and the setting release unit 105 are realized by the control unit 11.

[0142] [Data storage unit] The data storage unit 100 may be the same as in the first embodiment or the second embodiment. In the third embodiment, the data storage unit 100 may store release condition data indicating a release condition. The release condition data may be in any format, for example, a table format, a mathematical formula format, a part of a program, a machine learning model, or other formats. In the example of FIG. 11, it is assumed that the data storage unit 100 stores release condition data indicating that the setting should be released when a payment with a specified installment payment or the like is executed.

[0143] [Setting acquisition unit] The setting acquisition unit 104 acquires settings related to installment payments or the like of payment means available to the user. The function of the setting acquisition unit 104 may be the same as the function described as a part of the processing execution unit 102 in the first embodiment. In the third embodiment, as in the first and second embodiments, taking the case where the payment of the price corresponds to the use of the payment application as an example, the setting acquisition unit 104 acquires settings related to installment payments or the like in the payment of the price.

[0144] In the third embodiment, since the settings related to installment payments or the like are stored in the payment database DB1, the setting acquisition unit 104 acquires the settings related to installment payments or the like from the payment database DB1. For example, the setting acquisition unit 104 acquires the settings related to installment payments or the like associated with the code ID included in the payment request received from the store terminal 40 from the payment database DB1. The settings related to installment payments or the like may be stored in a database other than the payment database DB1. The setting acquisition unit 104 may acquire the settings related to installment payments or the like from other databases. The settings related to installment payments or the like may be stored in a computer other than the payment server 10 or an external information storage medium. The setting acquisition unit 104 may acquire the settings related to installment payments or the like from other computers or external information storage media.

[0145] [Processing execution section] The processing execution unit 102 executes processing related to installment payments, etc., based on the settings for installment payments, etc., acquired by the setting acquisition unit 104. In the second embodiment, as in the first embodiment, an example is given in which payment of a price corresponds to the use of a payment app, and therefore the processing execution unit 102 executes processing for payment of a price, based on the settings for installment payments, etc., acquired by the setting acquisition unit 104. The processing of the processing execution unit 102 may be the same as in the first embodiment. In the third embodiment, as in the first embodiment, an example is given in which, after a lump-sum payment has been executed, the lump-sum payment is changed to installment payments, etc.

[0146] [Cancel settings section] The setting cancellation unit 105 cancels the setting of installment payments, etc., based on a predetermined cancellation condition. Canceling the setting of installment payments, etc., means changing the setting of installment payments, etc., from a state indicating that installment payments, etc., are used to a state indicating that installment payments, etc., are not used. Canceling the setting of installment payments, etc., includes both cases where the setting of installment payments, etc., is canceled when the cancellation condition is met and remains canceled thereafter, and cases where the setting of installment payments, etc., is temporarily canceled when the cancellation condition is met, but is not canceled unless the cancellation condition is met in the next use. For example, deleting the setting of installment payments, etc., stored in the payment database DB1, or changing the setting of installment payments, etc., stored in the payment database DB1 to a value indicating that installment payments, etc., are not used, corresponds to canceling the setting of installment payments, etc.

[0147] For example, when it is determined that the cancellation condition is not satisfied, the setting cancellation unit 105 does not cancel the installment payment or other settings. When it is determined that the cancellation condition is satisfied, the installment payment or other settings are cancelled. The setting cancellation unit 105 may determine whether the cancellation condition is satisfied by a determination method according to the content of the cancellation condition. For example, the setting cancellation unit 105 acquires the cancellation condition data stored in the data storage unit 100 and determines whether the cancellation condition indicated by the cancellation condition data is satisfied. When a plurality of cancellation conditions are indicated in the cancellation condition data, the setting cancellation unit 105 determines whether each of the plurality of cancellation conditions is satisfied.

[0148] For example, the setting cancellation unit 105 determines whether the cancellation condition is satisfied by determining whether the payment (for example, settlement by reading code C10) has been executed. When it is determined that the payment has been executed, the setting is cancelled. The payment here is a payment made in a state where installment payment or other settings have been made. The setting cancellation unit 105 refers to the processing result of the processing execution unit 102 and determines whether the cancellation condition is satisfied by determining whether the payment process corresponding to the settlement request from the store terminal 40 has been executed. The execution of the payment corresponds to the satisfaction of the cancellation condition. The non - execution of the payment corresponds to the non - satisfaction of the cancellation condition.

[0149] In the second embodiment, similar to the first embodiment, taking the case where the payment corresponds to the use of the settlement application as an example, the setting cancellation unit 105 cancels the installment payment or other settings in the payment based on the cancellation condition. For example, when it is determined that the cancellation condition is not satisfied, the setting cancellation unit 105 does not cancel the installment payment or other settings in the payment. When it is determined that the cancellation condition is satisfied, the installment payment or other settings in the payment are cancelled.

[0150] [3 - 2 - 2. Functions Realized by the Card Server] The functions of the card server 20 may be the same as those in the first embodiment or the second embodiment.

[0151] [3-2-3. Functions Implemented on User Terminals] The functions of the user terminal 30 may be the same as those in the first embodiment or the second embodiment.

[0152] [3-2-4. Functions Implemented on Store Terminals] The functions of the store terminal 40 may be the same as those in the first embodiment or the second embodiment.

[0153] [3-3. Processes Executed by the Payment System of the Third Embodiment] FIG. 13 is a diagram showing an example of a process executed by the payment system 1 of the third embodiment. The control units 11, 21, 31, and 41 execute the programs stored in the storage units 12, 22, 32, and 42, respectively, to execute the process of FIG. 13. In FIG. 13, among the processes executed by the payment system 1, mainly, the process for canceling settings such as installment payments will be described.

[0154] As shown in FIG. 13, the processes of S300 to S310 are the same as those of S100 to S110, respectively. When the installment payment and other processes in S310 are executed, the payment server 10 determines that the cancellation condition is satisfied and cancels the installment payment and other settings (S311). In S311, the payment server 10 deletes the installment payment and other settings stored in the payment database DB1. The subsequent process of S312 may be the same as that of S111. Since the installment payment and other settings have been canceled in S311, the payment server 10 may cause the completion screen SC3 to display information such as a message indicating that the installment payment and other settings have been canceled.

[0155] [3-4. Summary of the Third Embodiment] The settlement system 1 of the third embodiment acquires settings such as installment payments. The settlement system 1 executes processing such as installment payments based on the settings such as installment payments. The settlement system 1 cancels the settings such as installment payments based on a predetermined cancellation condition. As a result, the user does not need to manually cancel the settings such as installment payments, so the settlement system 1 can reduce the user's operation burden and improve the user's convenience. For example, the settlement system 1 can prevent installment payments or the like from being made even though the user does not wish for installment payments or the like while the settings such as installment payments remain.

[0156] Also, the settlement system 1 acquires settings such as installment payments in the payment of the price. The settlement system 1 executes processing such as installment payments in the payment of the price based on the settings such as installment payments. The settlement system 1 cancels the settings such as installment payments in the payment of the price based on the cancellation condition. As a result, the user does not need to manually cancel the settings such as installment payments every time the price is paid, so the settlement system 1 can improve the convenience of the user who pays the price.

[0157] Also, the settlement system 1 determines whether the cancellation condition is satisfied by determining whether the payment of the price has been executed, and cancels the setting when it is determined that the payment of the price has been executed. As a result, the settlement system 1 can cancel the settings such as installment payments every time a payment using installment payments or the like is made. For example, when there are few or no users who want to use installment payments or the like continuously, the settlement system 1 can improve the convenience of the user.

[0158] [4. Fourth Embodiment] An example of an embodiment of the settlement system 1, the settlement method, and the program according to the present disclosure, the fourth embodiment, will be described. In the fourth embodiment, descriptions of the same configurations as those in the first to third embodiments are omitted. For example, the hardware configuration of the settlement system 1 may be the same as that in the first embodiment.

[0159] [4-1. Outline of the Fourth Embodiment] In the fourth embodiment, a payment system 1 is taken as an example which does not include at least one of the functions described in the first embodiment (for example, the function for displaying a setting screen such as the payer selection screen SC2), the functions described in the second embodiment (for example, the function for determining usage conditions and related functions), and the functions described in the third embodiment (for example, the function for canceling settings such as installment payments according to cancellation conditions). For example, the payment system 1 may be able to set installment payments or the like from the code screen SC1 without having the functions described in the first embodiment.

[0160] FIG. 14 is a diagram showing an example of the process executed in the payment system 1 of the fourth embodiment. In the fourth embodiment, a case where a setting such as an installment payment is specified for the store terminal 40 when the user makes a payment at the store using the payment application is taken as an example. In the example of FIG. 14, the store terminal 40 is a self-checkout. For example, the user causes the store terminal 40 to read the bar code of the product and performs an operation of selecting a payment method for the store terminal 40. When the user selects code settlement using the code C10 as the payment method, as shown in FIG. 14, the store terminal 40 causes the display unit 45 to display a setting screen SC4 for specifying a setting such as an installment payment.

[0161] For example, the user specifies a setting such as an installment payment from the setting screen SC4. The content that can be specified as the setting such as an installment payment may be the same as that in the first embodiment. However, in the first embodiment, a case where a setting such as an installment payment is specified from the payer selection screen SC2 on the user terminal 30 is taken as an example, while in the fourth embodiment, a case where a setting such as an installment payment is specified from the setting screen SC4 of the store terminal 40 is taken as an example. Although they are different in this respect, the basic setting process may be the same as that in the first embodiment.

[0162] In the example of FIG. 14, a setting screen SC4 when the user selects installment payment is shown. For example, on the setting screen SC4, a button B40 for accepting the specification of the number of installments is displayed. The user can specify any number of installments. When the user specifies the number of installments and causes the store terminal 40 to read the code C10 on the code screen SC1, the store terminal 40 sends a payment request to the payment server 10. The payment request includes settings such as the number of installments specified by the user. Note that the user may be able to specify a setting indicating the use of deferred payment or bonus payment at the store terminal 40.

[0163] For example, when the payment server 10 receives a payment request from the store terminal 40, it determines whether settings such as installment payment are included in the payment request. If the payment server 10 determines that settings such as installment payment are not included in the payment request, it processes the payment request as a lump-sum payment as usual. If the payment server 10 determines that settings such as installment payment are included in the payment request, it processes installment payment and the like in the same manner as in the first embodiment. Also in the fourth embodiment, the determination of usage conditions may be performed in the same manner as in the second embodiment, or the settings such as installment payment may be cancelled after the payment of the price in the same manner as in the third embodiment.

[0164] As described above, the payment system 1 of the fourth embodiment executes processing such as installment payment from the payment application based on settings such as installment payment. For example, the payment system 1 executes processing such as installment payment in a payment using the code C10 on the code screen SC1. In FIG. 14, a setting method different from that of the first embodiment is given as an example, but in the fourth embodiment, settings such as installment payment may be made in the same setting method as in the first embodiment. Therefore, the payment system 1 of the fourth embodiment can also be said to be a payment system 1 of a higher concept that includes the first embodiment. The payment system 1 of the fourth embodiment may be a payment system 1 of a higher concept that at least includes the second embodiment and the third embodiment. Hereinafter, the details of the fourth embodiment will be described.

[0165] [4-2. Functions Realized by the Payment System of the Fourth Embodiment] FIG. 15 is a diagram showing an example of functions realized by the settlement system 1 of the fourth embodiment. In FIG. 15, some of the functions described in the first to third embodiments are not shown, but the settlement system 1 of the fourth embodiment may include the functions described in the first to third embodiments. Each part realized by the settlement system 1 of the fourth embodiment can be configured by integrating it into one device or further dispersing the devices in more detail.

[0166] [4-2-1. Functions Realized by the Settlement Server] For example, the settlement server 10 includes a data storage unit 100, a processing execution unit 102, and a setting acquisition unit 104.

[0167] [Data Storage Unit] The data storage unit 100 may be the same as that in the first to third embodiments. The settlement database DB1 of the fourth embodiment may not store settings such as installment payments.

[0168] [Setting Acquisition Unit] The setting acquisition unit 104 may be the same as that in the third embodiment. In the fourth embodiment, since the settlement of the type in which the code C10 is read is executed, the processing execution unit 102 acquires settings such as installment payments for paying the price of goods or services provided by the store where the code C10 displayed in the settlement application is read. The setting acquisition unit 104 may acquire settings such as installment payments from the settlement database DB1 in the same manner as in the first to third embodiments.

[0169] In the example of FIG. 14, the setting acquisition unit 104 acquires settings such as installment payments specified in the setting screen SC4 displayed on the store terminal 40. For example, the setting acquisition unit 104 acquires settings such as installment payments included in the settlement request from the store terminal 40. In the fourth embodiment, settings such as installment payments may not be stored in the settlement database DB1. In the case of settlement of the type in which the code displayed on the store terminal 40 is read by the user terminal 30, the setting acquisition unit 104 may acquire settings such as installment payments included in the settlement request from the user terminal 30.

[0170] [Processing Execution Unit] The processing execution unit 102 may be the same as that in the first embodiment or the third embodiment. The processing of the processing execution unit 102 may be the same as the processing of the processing execution unit 102 in the second embodiment. In the fourth embodiment, since a settlement of the type in which the code C10 is read is executed, when the code C10 is read at the store, the processing execution unit 102 executes processing such as installment payment based on settings such as installment payment. In the example of FIG. 14, the processing execution unit 102 executes processing such as installment payment based on the settings such as installment payment specified on the setting screen SC4 of the store terminal 40. The processing itself such as installment payment may be the same as that in the first embodiment or the third embodiment. The processing such as installment payment may be the same as the processing of the processing execution unit 102 in the second embodiment.

[0171] [4-2-2. Functions Realized by the Card Server] The functions of the card server 20 may be the same as those in the first to third embodiments.

[0172] [4-2-3. Functions Realized by the User Terminal] The functions of the user terminal 30 may be the same as those in the first to third embodiments.

[0173] [4-2-4. Functions Realized by the Store Terminal] The functions of the store terminal 40 may be the same as those in the first to third embodiments.

[0174] [4-3. Processing Executed by the Payment System in the Fourth Embodiment] FIG. 16 is a diagram showing an example of processing executed by the payment system 1 in the fourth embodiment. The control units 11, 21, 31, and 41 execute the programs stored in the storage units 12, 22, 32, and 42, respectively, whereby the processing in FIG. 16 is executed. In FIG. 16, as in FIG. 14, the case where settings such as installment payment are specified on the setting screen SC4 of the store terminal 40 is taken as an example. However, also in the fourth embodiment, the user may be able to use installment payment or the like in the same flow as the flow described in the first to third embodiments.

[0175] As shown in FIG. 16, the processes of S400 and S401 are the same as the processes of S100 and S101, respectively. The store terminal 40 causes the display unit 45 to display a setting screen SC4 for receiving a designation of installment payment or the like (S402). The store terminal 40 receives a designation of installment payment or the like from the setting screen SC4 (S403). When the code C10 on the code screen SC1 is read by the reading unit 46, the store terminal 40 transmits a payment request based on the code ID obtained from the code C10 to the payment server 10 (S404). When a setting such as installment payment is designated, the payment request includes the setting such as installment payment.

[0176] When the payment server 10 receives a payment request from the store terminal 40 (S405), it executes a process for card payment with the card server 20 (S406). In S406, it is first processed as lump-sum payment. The payment server 10 determines whether the payment request includes a setting such as installment payment (S407). In S407, when it is determined that the payment request includes a setting such as installment payment (S407: Y), the payment server 10 executes processes of S408 to S410 similar to S109 to S111. In S407, when it is determined that the payment request does not include a setting such as installment payment (S407: N), the processes of S408 and S409 are not executed, and the process of S410 is executed.

[0177] [Summary of the Fourth Embodiment] The payment system 1 of the fourth embodiment acquires a setting such as installment payment. The payment system 1 executes a process such as installment payment. As a result, the user can use installment payment or the like from the payment application, so that the payment system 1 can improve the convenience for the user. For example, the user can use installment payment or the like by preparing a payment application without preparing a plate-shaped card, so that the user can use various payment methods with the payment application.

[0178] In addition, the payment system 1 acquires settings such as installment payments for the payment of the price of goods or services provided by the store where the code C10 displayed in the payment application is read. When the code C10 is read at the store, the payment system 1 executes processing such as installment payments based on the settings such as installment payments. As a result, the user can use installment payments and the like with the code C10 of the payment application for the payment of the price, so that the payment system 1 can improve the convenience of the user in the payment of the price. For example, the user can use various payment methods with the payment application because the user can use installment payments and the like by presenting the code screen SC1 of the payment application without presenting a plate-shaped card at the store.

[0179] [5. Modification Example] The present disclosure is not limited to the first to fourth embodiments described above. The present disclosure can be appropriately changed without departing from the gist of the present disclosure. Hereinafter, modification examples regarding each of the first to fourth embodiments will be described.

[0180] [5-1. Modification Example Regarding the First Embodiment] FIG. 17 is a diagram showing an example of functions realized by a modification example regarding the first embodiment. For example, the payment server 10 includes a store information acquisition unit 106, a first correspondence determination unit 107, a second correspondence determination unit 108, a usage condition determination unit 109, and a simulation execution unit 110. Each of the store information acquisition unit 106, the first correspondence determination unit 107, the second correspondence determination unit 108, the usage condition determination unit 109, and the simulation execution unit 110 is realized by the control unit 11.

[0181] [Modification Example 1-1] For example, the setting screen for accepting the designation of settings such as installment payments is not limited to the payment source selection screen SC2. The setting screen may be another screen other than the payment source selection screen SC2. In modification example 1-1, the case where the code screen SC1 corresponds to the setting screen is taken as an example. The display control unit 101 of modification example 1-1 causes the user terminal 30 to display the code screen SC1 including the code C10 related to the payment of the price as the setting screen.

[0182] FIG. 18 is a diagram showing an example of the code screen SC1 of Modification 1-1. As shown in the upper left of FIG. 18, the display control unit 101 causes the user terminal 30 to display the code screen SC1 by transmitting the display data of the code screen SC1, which is the same as that in the upper left of FIG. 2, to the user terminal 30. The user terminal 30 causes the display unit 35 to display the code screen SC1 based on the display data. The code screen SC1 of Modification 1-1 includes parts of a user interface that accepts specifications of settings such as installment payments. In the example in the upper left of FIG. 18, the pull-down P110 of the panel P11 corresponds to the part. The part is not limited to the pull-down P110. The part may be other parts such as buttons or panels.

[0183] Hereinafter, the case where the user specifies an installment payment setting will be taken as an example. For example, when the user selects the pull-down P110, as shown in the upper right of FIG. 18, the user terminal 30 causes the pull-down P110 to display the number of installments that the user can specify. When the user selects the number of installments from the pull-down P110, as shown in the lower left of FIG. 18, the user terminal 30 causes the pull-down P110 to display the number of installments selected by the user. These series of processes may be executed by a script included in the display data of the code screen SC1, or may be executed by the user terminal 30 communicating with the settlement server 10 every time the user operates on the code screen SC1. These series of processes may also be shown in the program code of the settlement application.

[0184] For example, the user terminal 30 transmits to the settlement server 10 the installment payment setting (i.e., data indicating the installment payment setting) specified by the user from the pull-down P110. The settlement server 10 stores the installment payment setting received from the user terminal 30 in the settlement database DB1 in association with the user ID of the user. When the user cancels the installment payment setting from the pull-down P110 (in the example in the upper right of FIG. 18, when the user selects " lump sum payment"), the user terminal 30 transmits a request indicating cancellation of the installment payment setting to the settlement server 10. The settlement server 10 cancels the installment payment setting associated with the user ID of the user based on the request received from the user terminal 30. The meaning of cancellation of the installment payment setting is as described in the third embodiment.

[0185] In addition, when the user designates a rib payment or bonus payment setting, the display of the code screen SC1 may be controlled in the same manner as when the user designates an installment payment setting. For example, the display control unit 101 may cause the user terminal 30 to display the code screen SC1 by transmitting the display data of the code screen SC1 including the parts of the user interface that receive the designation of the rib payment or bonus payment setting to the user terminal 30.

[0186] Also, the method of generating the code C10 included in the code screen SC1 may be the same as in the first embodiment. The display control unit 101 may generate a code ID so as not to overlap with other code IDs, and generate the display data of the code screen SC1 based on the code ID. The process of converting the code ID into the code C10 may be executed on the settlement server 10 side or on the user terminal 30 side. The display control unit 101 may generate all or part of the data necessary for displaying the code screen SC1 including the code C10 for code settlement and the parts of the user interface that receive the designation of settings such as installment payment as the display data of the code screen SC1 and transmit it to the user terminal 30.

[0187] When the code C10 on the code screen SC1 is read at the store, the processing execution unit 102 of Modification Example 1-1 executes processing such as installment payment for payment of the price based on the settings such as installment payment specified on the code screen SC1. For example, when the code C10 is read by the reading unit 46 of the store terminal 40, the store terminal 40 transmits the code ID acquired from the code C10 to the settlement server 10. The processing execution unit 102 executes a lump-sum payment settlement first based on the code ID received from the store terminal 40, and if settings such as installment payment are specified, generates transaction information indicating that it is subject to installment payment or the like and stores it in the settlement database DB1. The processing after the code C10 is read may be the same as that of the first embodiment.

[0188] The settlement system 1 of Modification Example 1-1 causes the user terminal 30 to display the code screen SC1 as a setting screen. When the code C10 on the code screen SC1 is read at the store, the settlement system 1 executes processing such as installment payment for payment of the price based on the settings such as installment payment specified on the code screen SC1. Since the user can directly specify settings such as installment payment from the code screen SC1 displayed at the time of payment, the settlement system 1 can improve the convenience for the user.

[0189] [Modification Example 1-2] For example, when the code screen SC1 corresponds to a setting screen as in Modification Example 1-1, the display control unit 101 may cause the user terminal 30 to display the code screen SC1 that accepts a first operation for starting settings such as installment payment. The first operation is an operation performed before specifying the details of settings such as installment payment. In other words, the first operation is an operation for displaying parts of the user interface that accept specification of the details of settings such as installment payment. The first operation is an operation performed before the second operation described later. The first operation can also be said to be an operation for starting settings such as installment payment. The code screen SC1 includes parts of the user interface that accept the first operation.

[0190] FIG. 19 is a diagram showing an example of the code screen SC1 of Modification 1-2. The code screen SC1 in the upper left of FIG. 19 is the same as the code screen SC1 in the upper left of FIG. 18. In the example in the upper left of FIG. 19, the pull-down P110 corresponds to a part of the user interface that receives the first operation. The user performs the first operation by selecting the pull-down P110. The first operation is not limited to the selection of the pull-down P110. The first operation may be any operation performed from the code screen SC1. For example, the first operation may be an operation of selecting another part such as a button or a panel instead of the pull-down P110.

[0191] When the first operation is performed on the code screen SC1, the display control unit 101 of Modification 1-2 causes the user terminal 30 to display a user interface that receives a second operation for specifying details of settings such as installment payment so as to overlap the code screen SC1. The second operation is an operation performed after the first operation. For example, the second operation may be an operation of specifying the presence or absence of use of installment payment or the like. The second operation may be an operation of specifying the number of installments in installment payment, the payment amount or the number of times in ribo payment, or the bonus month in bonus payment. The second operation can also be said to be an operation for specifying a numerical value indicating settings such as installment payment. In Modification 1-2, the user performs at least two operations including the first operation and the second operation to complete the settings such as installment payment.

[0192] Hereinafter, the case where the user specifies the installment payment setting will be taken as an example. For example, when the first operation is performed, the display control unit 101 causes the user terminal 30 to display the user interface by including a script indicating that the user interface for receiving the second operation is to be displayed in the display data of the code screen SC1. For example, when the user selects the pull-down P110 in the state of the code screen SC1 in the upper left of FIG. 19, as shown in the upper right of FIG. 19, the user terminal 30 executes the script included in the display data of the code screen SC1 and displays the modal M12 including the panel P120 for receiving the specification of the number of installments so as to overlap the code screen SC1.

[0193] In the example in the upper right of FIG. 19, the modal M12 corresponds to a user interface that receives the second operation. The user interface may be other user interfaces other than the modal M12. For example, the user interface may be other user interfaces such as a pop-up or a window. The user interface is displayed so as to overlap all or part of the code screen SC1. In the example in the upper right of FIG. 19, the modal M12 is the same as the modal M21 in the lower left of FIG. 2, but may have a layout different from that of the modal M21.

[0194] For example, the user performs the second operation by selecting a panel P120 indicating the desired number of divisions from the modal M12. When the user selects the panel P120, as shown in the lower left of FIG. 19, the user terminal 30 erases the modal M12 and causes the pull-down P110 to display the number of divisions indicated by the panel P120. These series of processes may be executed by a script included in the display data of the code screen SC1, or may be executed by the user terminal 30 communicating with the settlement server 10 each time the user performs an operation on the code screen SC1. These series of processes may be shown in the program code of the settlement application.

[0195] For example, the user terminal 30 transmits to the settlement server 10 the installment payment setting (that is, data indicating the installment payment setting) specified by the user from the panel P120 of the modal M12. The settlement server 10 stores the installment payment setting received from the user terminal 30 in the settlement database DB1 in association with the user ID of the user. When the user cancels the installment payment setting from the panel P120 of the modal M12 (in the example in the upper right of FIG. 19, when the user selects "none"), the user terminal 30 transmits a request indicating cancellation of the installment payment setting to the settlement server 10. The settlement server 10 cancels the installment payment setting associated with the user ID of the user based on the request received from the user terminal 30.

[0196] In addition, when the user designates a setting for ribo payment or bonus payment, the display of the code screen SC1 may be controlled in the same flow as when the user designates a setting for installment payment. For example, when the first operation is performed, the display control unit 101 may display a user interface for receiving a second operation for designating details of the ribo payment or bonus payment setting so as to be superimposed on the code screen SC1. The display control unit 101 may control this series of processes by transmitting display data including a script indicating this series of processes to the user terminal 30, or may control this series of processes by communicating with the user terminal 30 each time the user performs an operation on the code screen SC1. This series of processes may be indicated in the program code of the payment application.

[0197] Also, although it is different from Modification Example 1-1 in that display control according to the first operation and the second operation is performed, the processing for displaying the code C10 such as the generation of the code ID may be the same as that of Modification Example 1-1. The processing execution unit 102 of Modification Example 1-2 executes processing such as installment payment in the payment of the price based on the details of the setting such as installment payment designated by the second operation. Although it is different from Modification Example 1-1 in that display control according to the first operation and the second operation is performed, the processing after the code C10 is read may be the same as that of Modification Example 1-1.

[0198] The settlement system 1 of Modification Example 1-2 causes the user terminal 30 to display a code screen SC1 for receiving a first operation. When a first operation is performed on the code screen SC1, the settlement system 1 causes the user terminal 30 to display a user interface for receiving a second operation so as to overlap the code screen SC1. The settlement system 1 executes processing such as installment payment in the payment of the price based on the details of settings such as installment payment specified by the second operation. As a result, the user can directly specify settings such as installment payment from the modal M12 that is displayed overlapping the code screen SC1 to be displayed at the time of payment, so that the settlement system 1 can improve the convenience for the user. The modal M12 is displayed so as to overlap the code screen SC1 and has sufficient space for the user to perform the second operation, so that the user can easily specify the details of settings such as installment payment.

[0199] [Modification Example 1-3] For example, before an operation for paying the price is performed, the settlement system 1 may be able to identify in advance which store's price will be paid. In this case, the settlement system 1 may perform a determination as to whether or not the store supports installment payment or the like, and based on the execution result of the determination, cause the user terminal 30 to display a setting screen such as the code screen SC1 or a payment source selection screen SC2.

[0200] The settlement system 1 of Modification Example 1-3 includes a store information acquisition unit 106 and a first correspondence determination unit 107. The store information acquisition unit 106 acquires store information regarding the store before the price is paid. The store information may be a store ID that can identify the store, other information that can search for the store ID (for example, the terminal ID of the store terminal 40), the name of the store, correspondence store information indicating whether the store is a correspondence store that supports installment payment or the like, or other information.

[0201] For example, when the code C10 on the code screen SC1 is read by the store terminal 40 as in the first embodiment, the store information acquisition unit 106 can identify the store where the user is based on the settlement request from the store terminal 40. Also, for example, when the user reads the store code with the user terminal 30, the store information acquisition unit 106 can identify the store where the user is based on the information of the code acquired from the user terminal 30. On the other hand, before reading the code, for example, when the user enters the store or when the time the user stays at a predetermined position exceeds a predetermined time, the store information acquisition unit 106 may acquire store information based on the current position information indicating the current position of the user terminal 30. The user terminal 30 includes a GPS receiver. The user terminal 30 acquires current position information indicating the current position of the user terminal 30 detected by the GPS receiver. In Modification 1-3, the case where the current position of the user terminal 30 is expressed in latitude and longitude is taken as an example. The user terminal 30 transmits the current position information to the settlement server 10. The settlement server 10 receives the current position information from the user terminal 30.

[0202] Note that the current position of the user terminal 30 may be expressed in other information than latitude and longitude. For example, the current position of the user terminal 30 may be expressed in coordinates, an address, or other information different from latitude and longitude. The method by which the user terminal 30 acquires the current position information may be a known method and is not limited to the method using a GPS receiver. For example, the user terminal 30 may acquire the current position information by means of a wireless LAN access point, a mobile base station, or other methods.

[0203] In Modification 1-3, the data storage unit 100 stores a store database in which basic information of stores is stored. The store database is assumed to store a store ID that can identify a store, store position information indicating the position of the store, and corresponding store information indicating whether the store is a corresponding store corresponding to installment payment or the like. Other information such as the name of the store may be stored in the store database. The position of the store may be expressed in latitude and longitude, similar to the current position of the user terminal 30, or may be expressed in other information such as coordinates.

[0204] For example, the store information acquisition unit 106 identifies stores near the current position of the user terminal 30 based on the current position information and the store position information. The vicinity of the current position is a position within a predetermined distance (for example, a predetermined distance such as 10 meters) from the current position. The store information acquisition unit 106 identifies a store within a predetermined distance from the current position indicated by the current position information from among the stores in which the store position information is stored in the store database. The store information acquisition unit 106 acquires the corresponding store information of the identified store as the store information.

[0205] Note that the method for acquiring store information is not limited to the above example. For example, when a code displayed on the store terminal 40 or a code posted in the store is read by the user terminal 30, the store information acquisition unit 106 may acquire the store ID included in these codes as the store information. When the user terminal 30 reads these codes, it acquires the store ID from the codes and transmits it to the payment server 10. The store information acquisition unit 106 may acquire the store ID from the user terminal 30 as the store information. The store information acquisition unit 106 may acquire the corresponding store information associated with the store ID acquired from the user terminal 30 as the store information. For example, the current position may be acquired based on another application linked to the payment application, or another function (for example, the check-in function of the check-in application or the map of the "usable stores" mini-application).

[0206] For example, when a list of stores is displayed on the user terminal 30 and the user selects a store for payment, the store information acquisition unit 106 may acquire the store information of the store selected by the user from the list of stores. Assume that the user terminal 30 stores the store IDs of the stores included in the list of stores displayed in the payment application. When the user selects an arbitrary store from the list of stores, the user terminal 30 transmits the store ID of the store to the payment server 10. The store information acquisition unit 106 acquires the store ID from the user terminal 30 as store information. The store information acquisition unit 106 may acquire the corresponding store information associated with the store ID acquired from the user terminal 30 as store information.

[0207] The first correspondence determination unit 107 determines whether the store corresponds to installment payment or the like based on the store information. For example, when the store ID corresponds to the store information, the first correspondence determination unit 107 acquires the corresponding store information associated with the store ID that is the store information from the store database, and determines whether the corresponding store information indicates a corresponding store, thereby determining whether the store corresponds to installment payment or the like. When the corresponding store information corresponds to the store information, the first correspondence determination unit 107 may determine whether the store corresponds to installment payment or the like by determining whether the corresponding store information that is the store information indicates a corresponding store from the store database.

[0208] Based on the determination result of the first correspondence determination unit 107, the display control unit 101 of Modifications 1-3 causes the user terminal 30 to display a setting screen exemplified by the code screen SC1 or the payment source selection screen SC2. For example, when the first correspondence determination unit 107 determines that the store does not correspond to installment payment or the like, the display control unit 101 does not cause the user terminal 30 to display a setting screen that accepts the specification of installment payment or the like. When the first correspondence determination unit 107 determines that the store corresponds to installment payment or the like, the display control unit 101 causes the user terminal 30 to display a setting screen that accepts the specification of installment payment or the like.

[0209] FIG. 20 is a diagram showing an example of a screen of the settlement application in Modifications 1-3. In FIG. 20, an example is given of a case where settlement of the type in which the code displayed on the store terminal 40 is read by the user terminal 30 is executed. For example, the code includes information necessary for payment (for example, store ID and payment amount). When the user terminal 30 reads the code, it transmits the information included in the code to the settlement server 10. When the settlement server 10 receives the information included in the code from the user terminal 30, the processes of the store information acquisition unit 106 and the first correspondence determination unit 107 are executed. The settlement server 10 specifies the store to be paid (that is, the store to be paid to) and the payment amount based on the information included in the code. The specification of the store and the payment amount may be the same as the mechanism adopted in a known settlement service.

[0210] For example, when the display control unit 101 determines by the first correspondence determination unit 107 that the store does not correspond to installment payment or the like, it causes the user terminal 30 to display a confirmation screen SC5 that does not accept the designation of installment payment or the like settings, as shown on the left side of FIG. 20. In the example on the left side of FIG. 20, the confirmation screen SC5 includes a panel P50 indicating the current payment source. When the user selects the panel P50, the user terminal 30 causes the payment source selection screen SC2 to be displayed on the display unit 35. In the example on the left side of FIG. 20, the confirmation screen SC5 does not include the pull-down P500 described later.

[0211] For example, when the display control unit 101 determines by the first correspondence determination unit 107 that the store corresponds to installment payment or the like, it causes the user terminal 30 to display a confirmation screen SC5 that accepts the designation of installment payment or the like settings, as shown on the right side of FIG. 20. In the example on the right side of FIG. 20, the panel P50 includes a pull-down P500 for designating installment payment or the like settings. The pull-down P500 may be the same as the pull-down P110 on the code screen SC1. The user can specify installment payment or the like settings by selecting the pull-down P110. The confirmation screen SC5 on the right side of FIG. 20 is an example of a setting screen.

[0212] For example, when the user selects panel P50 in the state of the confirmation screen SC5 on the right side of FIG. 20, the display control unit 101 causes the user terminal 30 to display a payment source selection screen SC2 similar to the upper right of FIG. 2. The flow in which settings such as installment payment are specified from the payment source selection screen SC2 may be the same as that in the first embodiment. When the user selects the pull-down P500 within the panel P50, the display control unit 101 may display a modal similar to the modal M21 in FIG. 19 on the confirmation screen SC5. The flow in which settings such as installment payment are specified from the modal may be the same as that in Modification 1-2.

[0213] For example, when the user slides the slider B51 on the confirmation screen SC5, the user terminal 30 sends a payment request to the payment server 10. The payment request sent from the user terminal 30 to the payment server 10 when the slider B51 is slid in the state of the confirmation screen SC5 on the left side of FIG. 20 may be the same as a known payment service. When the processing execution unit 102 receives a payment request from the user terminal 30, it executes processing such as installment payment based on the settings such as installment payment stored in the payment database DB1.

[0214] Note that although it is different from the first embodiment whether the payment request is sent from the store terminal 40 or the user terminal 30, the processing such as installment payment executed by the processing execution unit 102 itself may be the same as that in the first embodiment. Also, in Modification 1-3, since a payment request is sent from the user terminal 30, the settings such as installment payment specified by the user from the confirmation screen SC5 may be included in the payment request. The processing execution unit 102 may execute processing such as installment payment based on the settings such as installment payment included in the payment request.

[0215] The payment system 1 of Modification Examples 1-3 acquires store information before payment for the price is made. The payment system 1 determines whether the store supports installment payments or the like based on the store information. The payment system 1 causes the user terminal 30 to display a setting screen based on the determination result as to whether the store supports installment payments or the like. Thereby, since the payment system 1 can have the user specify settings such as installment payments from a setting screen corresponding to whether the store supports installment payments or the like, the convenience of the user can be effectively enhanced. For example, the payment system 1 can prevent a situation where settings such as installment payments are specified for a payment for a price that does not support installment payments or the like.

[0216] [Modification Example 1-4] For example, in the first embodiment, the case where the user uses installment payments or the like for payment of the price has been described, but the user may use installment payments or the like in other scenarios other than payment of the price. In Modification Example 1-4, the case where the user uses installment payments or the like for charging electronic money will be taken as an example. The installment payments or the like in charging do not mean charging in multiple times. The charging itself is completed in one time. That is, when a certain charging is executed, the balance of the electronic money increases only once.

[0217] The installment payments or the like in charging described in Modification Example 1-4 are the installment payments or the like in the settlement for the source of the charge that is the basis of the charge. For example, assume that the user designates a credit card as the source of the charge and executes a 10,000 yen charge with a 5-installment payment. The balance of the electronic money increases by 10,000 yen immediately after the settlement for the charge is executed. The balance of the electronic money does not increase by 2,000 yen each in 5 times. The debit of the credit card used as the source of the charge is divided into 5 times. Similarly, when ribo payment or bonus payment is specified for charging, the balance of the electronic money increases immediately after the settlement for the charge is executed, and the subsequent debit is divided into multiple times or made in the bonus month.

[0218] FIG. 21 is a diagram showing an example of a setting screen in Modifications 1-4. In the example of FIG. 21, a case where a charge screen SC6 that accepts specification of charge conditions corresponds to the setting screen is taken as an example. In Modifications 1-4, the places described as the charge screen SC6 can be read as the setting screen. The display control unit 101 in Modifications 1-4 causes the user terminal 30 to display a charge screen SC6 that accepts specification of settings in a charge in which a settlement means is used. The display control unit 101 generates display data of the charge screen SC6 and transmits the display data to the user terminal 30, thereby causing the user terminal 30 to display the charge screen SC6.

[0219] For example, as shown in the upper left of FIG. 21, the display control unit 101 causes the user terminal 30 to display a charge screen SC6 including a charge condition input form F60 and a panel P61 indicating a settlement means set as a charge source. The charge condition is a condition for charging. For example, the charge condition may be a charge amount or a remaining balance after charging. Which settlement means to use as a charge source is also a kind of charge condition. The conditions that can be specified as charge conditions may be the same as the conditions used in known charges.

[0220] For example, panel P61 is different from panel P11 on the code screen SC1 in that it indicates the charging source instead of the payment source, but the usage of panel P61 is generally the same as that of panel P11. When the user selects panel P61, as shown in the upper right of FIG. 21, the display control unit 101 may display a charging source selection screen SC7 having the same layout as the payment source selection screen SC2 on the user terminal 30. On the charging source selection screen SC7, a list of payment methods that can be specified as the charging source is displayed. The user may specify settings such as installment payment from the charging source selection screen SC7. In this case, the charging source selection screen SC7 corresponds to the setting screen. The flow in which settings such as installment payment are specified from the charging source selection screen SC7 may be the same as the flow shown in the payment source selection screen SC2 of FIG. 2. Also, the charging source selection screen SC7 may be a screen on which the charging source (charging method) can be switched or its priority can be set. For example, it may be another screen such as the home screen, the payment screen, or the payment method management screen. Although the charging source selection screen SC7 is described separately from the charging screen SC6, it may be the same screen as the charging screen SC6.

[0221] For example, when the user selects a panel P70 of a payment method that is a candidate for the charging source, as shown in the lower left of FIG. 21, the user terminal 30 displays a modal M71 that accepts the specification of settings such as installment payment on the charging source selection screen SC7. A series of processes such as the display of the modal M71 may be the same as the processes for displaying the modal M21 on the payment source selection screen SC2. For example, a series of processes such as the display of the modal M71 may be executed by a script included in the display data of the charging source selection screen SC7. These series of processes may be shown in the program code of the payment application.

[0222] For example, the display control unit 101 may cause the user terminal 30 to display a modal M71 or the like by generating display data including a script and transmitting it to the user terminal 30. When the user designates a setting such as installment payment in the charge from the modal M71, as shown in the lower right of FIG. 21, the setting such as installment payment is reflected on the charge source selection screen SC7. The settlement server 10 acquires the setting such as installment payment from the user terminal 30 and stores the setting such as installment payment in the charge in the settlement database DB1. The setting such as installment payment in the payment of the price and the setting such as installment payment in the charge may be separate from each other or common.

[0223] The processing execution unit 102 of Modification Examples 1-4 executes processing such as installment payment in the charge based on the setting such as installment payment. Similar to the payment of the price, the processing execution unit 102 may first execute a charge as a lump sum payment and then execute a process of changing the lump sum payment to an installment payment or the like, or may execute a settlement for the charge as an installment payment or the like from the beginning without first executing a lump sum payment. For example, when executing a settlement for the charge, the processing execution unit 102 requests the card server 20 to execute the settlement for the charge as an installment payment or the like. The card server 20 executes the settlement for the charge as an installment payment or the like based on the request. The process of the card server 20 executing a settlement such as installment payment may be the same as the process of a known settlement service.

[0224] For example, when the user performs an operation to return to the charging screen SC6 in the lower right state of FIG. 21, the user terminal 30 causes the display unit 35 to display the charging screen SC6 again. In the pull-down P610 of the charging screen SC6, settings such as installment payment specified by the user are included. In this state, when the user selects the button B62 to support the execution of charging, based on the charging conditions and settings such as installment payment specified by the user, the charging process and the installment payment process are executed. When a lump-sum payment is first executed, the charging process may be the same as a known process. The processing execution unit 102 generates usage information including the charge amount, charge date and time, charge source information, and information indicating that it is subject to installment payment in the usage information indicating the use of the charge source from the payment application for charging, and stores it in the payment database DB1.

[0225] The payment system 1 of Modification Examples 1-4 causes the user terminal 30 to display a setting screen for receiving the specification of settings such as installment payment in charging where the payment means is used. The payment system 1 executes processing such as installment payment in charging based on the settings such as installment payment. As a result, the user can use installment payment and the like for charging from the payment application, so that the payment system 1 can improve the convenience of the user in charging from the payment application.

[0226] [Modification Example 1-5] For example, although briefly described in Modification Examples 1-4, the display control unit 101 may cause the user terminal 30 to display the charging screen SC6 for receiving the specification of charging conditions related to charging as a setting screen. For example, when the user selects the pull-down P610, the user terminal 30 may display the number of installments that the user can specify in the pull-down P610. The number of installments displayed in the pull-down P610 may be the same as the number of installments displayed in the pull-down P110 of the code screen SC1 in the upper right of FIG. 18.

[0227] For example, when the user selects the number of installments from the pull-down menu P610, the user terminal 30 may display the number of installments selected by the user on the pull-down menu P610. These series of operations may be the same as the code screen SC1 in FIG. 18. These series of processes may be executed by a script included in the display data of the charge screen SC6, or may be executed by the user terminal 30 communicating with the payment server 10 each time the user operates on the charge screen SC6. These series of processes may also be shown in the program code of the payment application. Similarly, when the ribo payment or bonus payment is executed, the display control unit 101 may display the charge screen SC6 that accepts the designation of the ribo payment or bonus payment settings on the user terminal 30 as a setting screen.

[0228] The processing execution unit 102 of Modification Example 1-5 executes the installment payment process in the charge based on the charge conditions specified on the charge screen SC6 and the settings such as installment payment. Although it is different from Modification Example 1-4 in that the installment payment settings are made on the charge screen SC6, the installment payment process itself in the charge is the same as that in Modification Example 1-4.

[0229] The payment system 1 of Modification Example 1-5 displays the charge screen SC6 that accepts the designation of the charge conditions related to the charge on the user terminal 30 as a setting screen. The payment system 1 executes the process in the charge based on the charge conditions specified on the charge screen SC6 and the settings such as installment payment. Since the user can directly specify the installment payment settings from the charge screen SC6 for inputting the charge conditions, the payment system 1 can improve the convenience for the user.

[0230] [Modification Example 1-6] For example, when the charge screen SC6 corresponds to the setting screen as in Modifications 1-5, the display control unit 101 may cause the user terminal 30 to display the charge screen SC6 that receives the third operation for starting settings such as installment payment. The third operation is an operation performed before specifying the details of settings such as installment payment. In other words, the third operation is an operation for causing a part of the user interface that receives the specification of the details of settings such as installment payment to be displayed. The third operation is an operation performed before the fourth operation described later. The third operation can also be said to be an operation for starting settings such as installment payment. The charge screen SC6 includes parts of the user interface that receive the third operation.

[0231] FIG. 22 is a diagram showing an example of the charge screen SC6 in Modification 1-6. The charge screen SC6 in the upper left of FIG. 22 is the same as the charge screen SC6 in the upper left of FIG. 21. In the example in the upper left of FIG. 22, the pull-down P610 corresponds to a part of the user interface that receives the third operation. The user performs the third operation by selecting the pull-down P610. The third operation is not limited to the selection of the pull-down P610. The third operation may be any operation performed from the code screen SC1. For example, the third operation may be an operation of selecting other parts such as a button or a panel instead of the pull-down P610.

[0232] When the third operation is performed on the charge screen SC6, the display control unit 101 in Modification 1-6 causes the user terminal 30 to display a user interface that receives the fourth operation for specifying the details of settings such as installment payment so as to overlap the charge screen SC6. The fourth operation is an operation performed after the third operation. For example, the fourth operation may be an operation of specifying the use or non-use of installment payment or the like. The fourth operation may be an operation of specifying the number of installments in installment payment, the payment amount or the number of times in direct debit, or the bonus month in bonus payment. The fourth operation can also be said to be an operation for specifying a numerical value indicating settings such as installment payment. In Modification 1-6, the user performs at least two operations including the third operation and the fourth operation to complete the settings such as installment payment.

[0233] Hereinafter, the case where the user designates installment payment settings will be taken as an example. For example, when the third operation is performed, the display control unit 101 includes a script indicating that a user interface for receiving a fourth operation is to be displayed in the display data of the charge screen SC6, thereby causing the user interface to be displayed on the user terminal 30. For example, when the user selects the pull-down P610 in the state of the charge screen SC6 in the upper left of FIG. 22, as shown in the upper right of FIG. 22, the user terminal 30 executes the script included in the display data of the charge screen SC6 and superimposes a modal M63 including a panel P630 for receiving the designation of the number of installments on the charge screen SC6.

[0234] In the example in the upper right of FIG. 22, the modal M63 corresponds to a user interface for receiving a fourth operation. The user interface may be another user interface other than the modal M63. For example, the user interface may be another user interface such as a pop-up or a window. The user interface is displayed so as to superimpose on all or part of the charge screen SC6. Note that in the example in the upper right of FIG. 22, the modal M63 is generally the same as the modal M21 in the lower left of FIG. 2, but may have a layout different from that of the modal M21.

[0235] For example, the user performs a fourth operation by selecting a panel P630 indicating a desired number of installments from the modal M63. When the user selects the panel P630, as shown in the lower left of FIG. 22, the user terminal 30 deletes the modal M63 and displays the number of installments indicated by the panel P630 in the pull-down P610. These series of processes may be executed by a script included in the display data of the charge screen SC6, or may be executed by the user terminal 30 communicating with the settlement server 10 every time the user performs an operation on the charge screen SC6. These series of processes may be shown in the program code of the settlement application.

[0236] For example, the user terminal 30 sends a payment installment setting specified by the user from the panel P630 of the modal M63 to the payment server 10. The payment server 10 stores the payment installment setting received from the user terminal 30 in the payment database DB1 in association with the user ID of the user. When the user cancels the payment installment setting from the panel P630 of the modal M63 (in the example in the upper right of FIG. 22, when the user selects "none"), the user terminal 30 sends a request indicating cancellation of the payment installment setting to the payment server 10. The payment server 10 cancels the payment installment setting associated with the user ID of the user based on the request received from the user terminal 30.

[0237] In addition, when the user specifies a setting for payment by direct debit or bonus payment, the display of the charge screen SC6 may be controlled in the same flow as when the user specifies a setting for payment by installments. For example, when the third operation is performed, the display control unit 101 may display a user interface for receiving a fourth operation for specifying details of the direct debit or bonus payment setting superimposed on the charge screen SC6. The display control unit 101 may control these series of processes by sending display data including a script indicating these series of processes to the user terminal 30, or may control these series of processes by communicating with the user terminal 30 each time the user performs an operation on the charge screen SC6.

[0238] Also, although it is different from Modification Examples 1-5 in that display control according to the third operation and the fourth operation is performed, the processing for charging may be the same as that in Modification Examples 1-5. The processing execution unit 102 in Modification Examples 1-5 executes processing such as payment by installments in charging based on the details of settings such as payment by installments specified by the fourth operation. Although it is different from Modification Examples 1-4 in that display control according to the third operation and the fourth operation is performed, the processing after the execution of charging is instructed may be the same as that in Modification Examples 1-4.

[0239] The payment system 1 of Modification Examples 1-6 causes the user terminal 30 to display a charge screen SC6 that accepts a third operation. When a third operation is performed on the charge screen SC6, the payment system 1 causes the user terminal 30 to display a user interface that accepts a fourth operation so as to overlap the charge screen SC6. The payment system 1 executes processing for charging based on the details of settings such as installment payment specified by the fourth operation. As a result, the user can directly specify settings such as installment payment from the modal M63 that is displayed overlapping the charge screen SC6 displayed at the time of charging, so that the payment system 1 can improve the convenience for the user. The modal M63 is displayed so as to overlap the charge screen SC6 and has sufficient space for the user to perform the fourth operation, so that the user can easily specify the details of settings such as installment payment.

[0240] [Modification Example 1-7] For example, although briefly described in the first embodiment and Modification Examples 1-1 to 1-6, the display control unit 101 may cause the content of settings such as installment payment to be displayed on the setting screen in association with the payment means information regarding the payment means. The payment means information displayed on the setting screen may be the same as the payment means information stored in the payment database DB1, or may be only a part of the information. When the code screen SC1 in the upper left of FIG. 2 corresponds to the setting screen, the payment means information is information on a credit card. For example, the payment means information may be the brand of the credit card, the card name, a part of the credit card number, or other information. The payment means for which the payment means information is displayed on the setting screen is the payment source or the charge source.

[0241] For example, when the payment source selection screen SC2, the charge screen SC6, or the charge source selection screen SC7 corresponds to the setting screen, the display control unit 101 may cause the setting screen to display the content of settings such as installment payment in association with the payment means information of payment means such as a credit card. Displaying the content of settings such as installment payment in association with the payment means information means displaying the payment means information and the content of settings such as installment payment on the same setting screen. The display control unit 101 generates display data of the setting screen showing the payment means information and the content of settings such as installment payment and transmits it to the user terminal 30, thereby causing the user terminal 30 to display the setting screen in which these are associated.

[0242] The payment system 1 of Modification Example 1-7 displays the content of settings such as installment payment on the setting screen in association with the payment means information regarding the payment means. Thereby, the user can confirm both the payment means information and the content of settings such as installment payment on the setting screen, so that the payment system 1 can improve the convenience for the user.

[0243] [Modification Example 1-8] For example, each of the payment source selection screen SC2 described in the first embodiment and the charge source selection screen SC7 described in Modification Example 1-4 is an example of a usage payment means screen that accepts the designation of the usage payment means, which is the payment means used in the user terminal 30. The payment source or the charge source is an example of the usage payment means. The display control unit 101 may cause the user terminal 30 to display, as the setting screen, a usage payment means screen that accepts the designation of the usage payment means, which is the payment means used in the user terminal 30, from among a plurality of payment means available in the user terminal 30. The process for the display control unit 101 to display the payment source selection screen SC2 or the charge source selection screen SC7 as the usage payment means screen is as described in the first embodiment or Modification Example 1-4.

[0244] Note that the usage payment method screen may be any screen other than the payment source selection screen SC2 and the recharge source selection screen SC7. For example, the usage payment method screen may be a screen for specifying the payment methods registered in the payment application. In this case, the display control unit 101 may display a screen for specifying the payment methods registered in the payment application as the setting screen. The usage payment method screen may be a screen for deleting the payment methods registered in the payment application. In this case, the display control unit 101 may display a screen for deleting the payment methods registered in the payment application as the setting screen.

[0245] The processing execution unit 102 of Modification Examples 1-8 executes processing such as installment payment based on the usage payment method specified on the usage payment method screen and settings such as installment payment. For example, the processing execution unit 102 executes processing such as installment payment in the payment of the price based on the payment source selected on the payment source selection screen SC2, which is an example of the usage payment method screen, and settings such as installment payment. This processing is as described in the first embodiment. The processing execution unit 102 executes processing such as installment payment in the recharge based on the recharge source selected on the recharge source selection screen SC7, which is an example of the usage payment method screen, and settings such as installment payment. This processing is as described in Modification Examples 1-4.

[0246] The payment system 1 of Modification Examples 1-8 causes the user terminal 30 to display the usage payment method screen as the setting screen. The payment system 1 executes processing such as installment payment based on the usage payment method specified on the usage payment method screen and settings such as installment payment. Thereby, the user can specify settings such as installment payment on the usage payment method screen for selecting the usage payment method, so that the payment system 1 can effectively improve the convenience for the user.

[0247] [Modification Example 1-9] For example, when the payment application supports multiple payment methods, all of them may support installment payments or the like from the payment application, or only a part of them may support installment payments or the like from the payment application. In Modification Example 1-9, a case where only a specific payment method among the multiple payment methods supported by the payment application supports installment payments or the like from the payment application is taken as an example. In this case, a setting screen may be displayed according to the determination result as to whether or not the specific payment method is used.

[0248] The payment system 1 of Modification Example 1-9 includes a second correspondence determination unit 108. The second correspondence determination unit 108 determines whether or not the payment method corresponds to installment payments or the like in the user terminal 30. For example, the data storage unit 100 stores correspondence payment method data indicating the payment methods corresponding to installment payments or the like. The correspondence payment method data may be in any format. For example, the correspondence payment method data may be in a table format, a mathematical formula format, a part of a program, a machine learning model, or another format. The correspondence payment method data may be determined by the administrator of the payment service or may be determined by the administrator of the card service (card issuer).

[0249] For example, the second correspondence determination unit 108 determines whether or not the user's payment method corresponds to installment payments or the like based on the correspondence payment method data. When only the credit cards issued by a specific credit card company support installment payments or the like, the correspondence payment method data indicates the credit cards of that credit card company. The second correspondence determination unit 108 identifies the credit card company of the user's credit card based on a part of the credit card number (for example, a predetermined number of digits) or the like, and determines whether or not that credit card company supports installment payments or the like. The second correspondence determination unit 108 determines whether or not the payment source or the charge source corresponds to installment payments or the like. Note that this also includes a case where only the credit cards of a specific type issued by a specific credit card company support installment payments or the like.

[0250] The display control unit 101 of Modification Example 1-9 causes the setting screen to be displayed on the user terminal 30 based on the determination result of the second correspondence determination unit 108. For example, when it is determined that the user's payment means does not support installment payment or the like, the display control unit 101 does not cause the setting screen to be displayed on the user terminal 30, and when it is determined that the user's payment means supports installment payment or the like, the display control unit 101 causes the setting screen to be displayed on the user terminal 30. When it is determined that the user's payment means does not support installment payment or the like, the display control unit 101 causes the user terminal 30 to display a setting screen that does not accept the specification of installment payment or the like (for example, a setting screen in which parts of the user interface that accept the specification of installment payment or the like are grayed out, or a setting screen that does not include such parts), and when it is determined that the user's payment means supports installment payment or the like, the display control unit 101 may cause the user terminal 30 to display a setting screen that accepts the specification of installment payment or the like.

[0251] The payment system 1 of Modification Example 1-9 determines whether the payment means supports installment payment or the like on the user terminal 30. The payment system 1 causes the setting screen to be displayed on the user terminal 30 based on the determination result of the determination. Thereby, since the payment system 1 can cause the setting screen corresponding to the determination result of the determination to be displayed on the user terminal 30, the convenience of the user can be effectively improved. For example, the payment system 1 can prevent the setting screen from being displayed even though the payment means does not support installment payment or the like.

[0252] [Modification Example 1-10] For example, the payment server 10 may include a usage condition determination unit 109 having the same function as the usage condition determination unit 203 described in the second embodiment. The usage condition determination unit 109 determines whether the usage conditions regarding the use of installment payment or the like on the user terminal 30 are satisfied. The method for determining the usage conditions may be the same as that in the second embodiment. In Modification Example 1-10, the data storage unit 100 stores usage condition data. The usage condition data may be the same as that in the second embodiment. The specific content of the usage conditions is defined in the usage condition data.

[0253] For example, the usage condition determination unit 109 determines whether the usage conditions are satisfied based on the usage information acquired before the setting such as installment payment is specified. The payment server 10 includes the same functions as the usage information acquisition unit 202 described in the second embodiment. For example, in the type of reading the store code, etc., before the setting such as installment payment is specified, information on the store to be settled and the usage amount can be acquired. Information on the usage limit can also be acquired in advance. The usage condition determination unit 109 determines whether the usage conditions are satisfied based on the usage condition data and the usage information subject to installment payment or the like. The method for determining the usage conditions may be the same as that of the usage condition determination unit 203 described in the second embodiment.

[0254] The display control unit 101 of Modifications 1-10 causes the user terminal 30 to display the setting screen based on the determination result of the usage condition determination unit 109. For example, when it is determined that the usage conditions are not satisfied, the display control unit 101 does not cause the user terminal 30 to display the setting screen, and when it is determined that the usage conditions are satisfied, the display control unit 101 causes the user terminal 30 to display the setting screen. When it is determined that the usage conditions are not satisfied, the display control unit 101 may cause the user terminal 30 to display a setting screen that does not accept the specification of settings such as installment payment (for example, a setting screen in which parts of the user interface that accept the specification of settings such as installment payment are grayed out, or a setting screen that does not include such parts), and when it is determined that the usage conditions are satisfied, the display control unit 101 may cause the user terminal 30 to display a setting screen that accepts the specification of settings such as installment payment.

[0255] The payment system 1 of Modifications 1-10 determines whether the usage conditions regarding the use of installment payment or the like in the user terminal 30 are satisfied. The payment system 1 causes the user terminal 30 to display the setting screen based on the determination result of the determination. As a result, the payment system 1 can cause the user terminal 30 to display a setting screen corresponding to the determination result of the determination, so that the convenience of the user can be effectively improved. For example, the payment system 1 can prevent the setting screen from being displayed even though the usage conditions are not satisfied.

[0256] [Modification 1-11] For example, the display control unit 101 may be able to display on the user terminal 30 a setting screen corresponding to each of a plurality of payment methods available on the user terminal 30. In Modification Example 1-11, as an example of the payment method, two methods are given: a method of reading the code C10 described in the first embodiment by the store terminal 40, and a method of reading the code displayed on the store terminal 40 described in Modification Example 1-3 by the user terminal 30. The display control unit 101 can display each of the code screen SC1 and the confirmation screen SC5 as a setting screen. These display methods are as described in the first embodiment and Modification Example 1-3. It is also as described above that the setting screen is not limited to the code screen SC1 and the confirmation screen SC5.

[0257] The display control unit 101 of Modification Example 1-11 causes the user terminal 30 to display a setting screen corresponding to another payment method so that the setting specified on the setting screen corresponding to one payment method among the plurality of payment methods is carried over to the setting screen corresponding to the other payment method. For example, when the display control unit 101 displays the confirmation screen SC5 after the installment payment or the like is specified on the code screen SC1, the display control unit 101 causes the user terminal 30 to display the confirmation screen SC5 showing the same setting as the installment payment or the like specified on the code screen SC1. When the display control unit 101 displays the code screen SC1 after the installment payment or the like is specified on the confirmation screen SC5, the display control unit 101 causes the user terminal 30 to display the code screen SC1 showing the same setting as the installment payment or the like specified on the confirmation screen SC5.

[0258] The processing execution unit 102 of Modification Example 1-11 executes the processing in the payment method based on the installment payment or the like specified on the setting screen corresponding to each of the plurality of payment methods. Although it is different from the first embodiment in that the installment payment or the like setting is carried over between the setting screens, the installment payment or the like processing itself is the same as that in the first embodiment.

[0259] In the payment system 1 of Modification Example 1-11, among a plurality of payment methods, the settings specified on the setting screen corresponding to one payment method are carried over to the setting screen corresponding to another payment method, and the setting screen corresponding to the other payment method is displayed on the user terminal 30. The payment system 1 executes processing in the payment method based on the settings specified on the setting screen corresponding to each of the plurality of payment methods. As a result, when the user changes the payment method, there is no need to re-enter settings such as installment payments, so the payment system 1 can effectively improve the convenience for the user.

[0260] [Modification Example 1-12] For example, when the usage amount of a payment or charge subject to installment payments or the like is known in advance, a simulation result corresponding to the usage amount may be displayed. The payment system 1 of Modification Example 1-12 includes a simulation execution unit 110. The simulation execution unit 110 executes a simulation related to installment payments or the like. The simulation is to calculate the payment amount (withdrawal amount) per payment, calculate the fee, calculate the period during which the payment occurs, or calculate the payment month.

[0261] The data storage unit 100 of Modification Example 1-12 stores a simulation program for simulations such as installment payments. In the simulation program, a calculation formula for the fee for each setting such as installment payments, a calculation formula for the payment amount per payment, or other calculation formulas are defined. The simulation program may be the same as the programs adopted in known card services or the like. For example, when the user uses installment payments, the simulation execution unit 110 calculates the fee required for installment payments and the payment amount per payment based on the usage amount, the number of installments, and the simulation program. Similarly, when the user uses automatic payments or bonus payments, the simulation execution unit 110 may execute the simulation based on the usage amount, the settings specified by the user, and the simulation program.

[0262] FIG. 23 is a diagram showing an example of the confirmation screen SC5 of Modification Examples 1-12. The display control unit 101 of Modification Examples 1-12 causes the user terminal 30 to display a confirmation screen SC5, which is an example of a setting screen, based on the execution result of the simulation. In the example of FIG. 23, when the user selects the pull-down P500 in the state of the confirmation screen SC5 on the right side of FIG. 20, the user terminal 30 causes a modal M52 for receiving a designation of a setting such as installment payment to be displayed on the confirmation screen SC5. The modal M52 may be the same as the modal M12.

[0263] For example, the simulation execution unit 110 calculates the payment amount for each payment based on the usage amount specified when the code displayed on the store terminal 40 is read and each of a plurality of installment numbers. The display control unit 101 causes the payment amount for each payment to be displayed on the modal M52. The user checks the result of the simulation from the panel P520 and selects the installment number.

[0264] For example, the display control unit 101 may display the simulation result on another setting screen (for example, the code screen SC1, the payment source selection screen SC2, the completion screen SC3, the charge screen SC6, or the charge source selection screen SC7) other than the confirmation screen SC5. When the simulation result is displayed on the completion screen SC3, when the user performs an operation to desire installment payment or the like from the completion screen SC3, the process execution unit 102 may execute a process such as installment payment.

[0265] The payment system 1 of Modification Examples 1-12 executes a simulation regarding installment payment or the like. The payment system 1 causes a setting screen to be displayed on the user terminal 30 based on the execution result of the simulation. As a result, the user can specify a setting such as installment payment while referring to the execution result of the simulation, so that the payment system 1 can effectively improve the convenience for the user.

[0266] [5-2. Modifications Regarding the Second Embodiment] FIG. 24 is a diagram showing an example of a function realized in a modification related to the second embodiment. For example, the settlement server 10 includes a processing execution unit 102, a usage condition determination unit 109, a processing result notification unit 111, a usage information acquisition unit 112, a payment notification unit 113, a change inquiry unit 114, and a response execution unit 115. Each of the processing result notification unit 111, the usage information acquisition unit 112, the payment notification unit 113, the change inquiry unit 114, and the response execution unit 115 is realized by the control unit 11.

[0267] [Modification 2-1] For example, in the second embodiment, the case where a lump-sum payment is first executed when the settlement application is used with a credit card set as the payment source is taken as an example. In this case, the payment from the card service administrator to the store is made in a lump sum, rather than being split. After the first lump-sum payment is executed, the settlement server 10 and the card server 20 cooperate with each other, and when the usage conditions are satisfied, a process of changing the first lump-sum payment to an installment payment or the like is executed.

[0268] Although briefly described in the second embodiment, the processing execution unit 201 may change and process an installment payment or the like to a lump-sum payment when it is determined that the usage conditions are not satisfied. That is, when it is determined that the usage conditions are not satisfied, the processing execution unit 201 posts the payment as a lump-sum payment without changing the first lump-sum payment. Even if the user made a payment with an installment payment or the like set, since it is posted as a lump-sum payment, the card server 20 processes the debit for the payment as a lump-sum payment. The process for the debit of the lump-sum payment may be realized by the same process as a known card service.

[0269] The settlement system 1 of Modification 2-1 changes and processes an installment payment or the like to a lump-sum payment when it is determined that the usage conditions are not satisfied. Thereby, even if an installment payment or the like is specified for a payment where the usage conditions are not satisfied, the settlement system 1 can process it as a lump-sum payment, so that it is possible to prevent the store from not receiving the payment.

[0270] [Modification Example 2-2] For example, when a user makes a payment by specifying a setting such as installment payment, the user may want to know whether the usage conditions were met and the payment was processed as an installment payment, or whether the usage conditions were not met and the payment was not processed as an installment payment. Therefore, in Modification Example 2-2, a case where the processing result of the processing execution unit 201 is notified to the user will be taken as an example.

[0271] The settlement system 1 of Modification Example 2-2 includes a processing result notification unit 111. The processing result notification unit 111 gives a processing result notification regarding the processing result of the processing execution unit 201 to the user of the settlement application. The processing result notification is a notification indicating the processing result of the processing execution unit 201. For example, the processing result notification is a notification indicating whether the usage conditions were met, or a notification indicating whether the user's payment was processed as an installment payment or the like.

[0272] FIG. 25 is a diagram showing an example of a processing result notification. For example, the processing result notification unit 111 uses the notification function of the settlement application to give a processing result notification to the user. The processing result notification unit 111 causes the user terminal 30 to display a notification screen SC8 indicating the notification in the notification function of the settlement application. Various notifications in the settlement application are displayed on the notification screen SC8. In Modification Example 2-2, the processing result notification unit 111 causes the user terminal 30 to display a notification screen SC8 including a processing result notification as one of the notifications in the settlement application. In the example of FIG. 25, the processing result notification includes a message indicating whether the payment specified by the user by specifying a setting such as installment payment was processed as an installment payment or the like.

[0273] Similar to the second embodiment, when the card server 20 determines the usage conditions and performs processing according to the determination result, the settlement server 10 receives, from the card server 20, processing result data indicating the processing result by the card server 20. The processing result data includes payment identification information (for example, an ID assigned to each payment) for identifying the payment processed by the processing execution unit 201, and processing information indicating whether the payment was processed as an installment payment or the like (that is, information indicating whether the usage conditions were met).

[0274] For example, the processing result notification unit 111 performs a processing result notification based on the processing result data. The processing result notification unit 111 refers to the usage information stored in the settlement database and identifies the user who made the payment indicated by the payment identification information included in the processing result data. The processing result notification unit 111 refers to the processing information included in the processing result data for the user and identifies the processing result of the processing execution unit 201. The processing result notification unit 111 performs a processing result notification indicating the identified processing result for the user. When the usage conditions are determined by the settlement server 10, the processing result notification unit 111 may obtain the processing result of the processing execution unit 102 according to the determination result of the usage conditions by the usage condition determination unit 109 described later and perform the processing result notification.

[0275] Note that the processing result notification may be performed by other notification means other than the notification function of the settlement application. For example, the processing result notification unit 111 may perform a processing result notification to the user by e-mail, SMS message, message of a message application, message of SNS, message in an application other than the settlement application, push notification, pop-up notification, or banner notification. Even when the processing result notification unit 111 performs the processing result notification by other notification means, the processing result notification unit 111 may identify how the payment of which user was processed based on the processing result data and perform a processing result notification indicating the execution result of the identification for the user.

[0276] The settlement system 1 of Modification Example 2-2 performs a processing result notification regarding the processing result of the processing execution unit 201 for the user of the settlement application. Thereby, the user can know how the payment for which the user specified settings such as installment payment was processed, so the settlement system 1 can effectively improve the convenience for the user.

[0277] [Modification Example 2-3] For example, in the second embodiment, an example is given where the payment for the price is first processed as a lump sum payment, and then, if the usage conditions are met, the initial lump sum payment is changed to installment payment or the like. Whether the usage conditions are met may be determined at the time when the payment for the price is instructed. The determination of the usage conditions performed when the payment for the price is instructed may be executed by the card server 20. However, in Modification 2-3, an example is given where the determination is executed by the settlement server 10.

[0278] The settlement system 1 of Modification 2-3 includes a usage condition determination unit 109 and a usage information acquisition unit 112. The usage information acquisition unit 112 acquires usage information when a payment for the price is instructed. For example, in the same manner as in the second embodiment, the settlement server 10 receives a settlement request from the store terminal 40. Assume that the settlement request includes at least a part of the usage information (for example, the store ID and the payment amount). When the settlement server 10 receives the settlement request, the usage information acquisition unit 112 of the settlement server 10 acquires at least a part of the usage information included in the settlement request. For information in the usage information that is not included in the settlement request, the usage information acquisition unit 112 may acquire it from the settlement database DB1.

[0279] For example, the usage condition determination unit 109 determines whether the usage conditions are met when a payment for the price is instructed. The usage condition determination unit 109 determines whether the usage conditions are met based on at least a part of the usage information included in the settlement request. In Modification 2-3, it is assumed that the data storage unit 100 stores the usage condition data described in the second embodiment. The usage condition determination unit 109 realized by the settlement server 10 determines whether the usage conditions are met based on the usage condition data stored in the data storage unit 100.

[0280] Taking as an example the case where the same usage conditions 1 to 3 as in the second embodiment are determined, the usage condition determination unit 109 determines whether usage condition 1 is satisfied by determining whether the store ID included in the payment request is not a non-corresponding store. The usage condition determination unit 109 queries the card server 20 for information on the usage limit of the user's card, and determines whether usage condition 2 is satisfied by determining whether the usage amount included in the payment request exceeds the usage limit. The usage condition determination unit 109 determines whether usage condition 3 is satisfied by determining whether the usage amount included in the payment request is equal to or greater than a predetermined amount.

[0281] Based on the determination result of the usage condition determination unit 109, the processing execution unit 102 of Modification 2-3 executes processing such as installment payment. For example, when payment of the price is instructed, the processing execution unit 102 executes processing such as installment payment in the payment of the price based on the determination result of the usage condition determination unit 109. When it is determined that the usage conditions are not satisfied, the processing execution unit 102 does not execute processing such as installment payment. For another example, when it is determined that the usage conditions are not satisfied, the processing execution unit 102 may change installment payment or the like to lump-sum payment and execute normal payment.

[0282] For example, when it is determined that the usage conditions are satisfied, the processing execution unit 102 executes processing such as installment payment. Similar to the second embodiment, the processing execution unit 102 may first process it as a lump-sum payment, or may execute processing for installment payment or the like with the card server 20 at the time of processing the payment request. The method by which the processing execution unit 102 executes processing for installment payment or the like with the card server 20 may be the same as the method adopted in known card services. For example, the processing execution unit 102 may transmit data in a format defined by the API of the card service, which is data for installment payment or the like (for example, data indicating that it is the target of installment payment or the like and the setting of installment payment or the like) to the card server 20, so as to process installment payment or the like at the time of execution of payment.

[0283] When the payment of the price is instructed, the settlement system 1 of Modification Example 2-3 determines whether the usage conditions are satisfied. Based on the determination result of the usage condition determination unit 109 executed when the payment of the price is instructed, the settlement system 1 executes the processing for the payment of the price. As a result, the settlement system 1 can determine whether the usage conditions are satisfied at an earlier stage, so that a more flexible settlement service can be provided to the user. For example, when the code C10 is read by the store terminal 40, the settlement system 1 can notify the user that the installment payment or the like has resulted in an error.

[0284] [Modification Example 2-4] For example, in Modification Example 2-3, when the payment of the price is instructed, a notification indicating the processing result of installment payment or the like may be given to the user. The settlement system 1 of Modification Example 2-4 includes a payment notification unit 113. When the payment of the price is instructed and it is determined that the usage conditions are not satisfied, the payment notification unit 113 gives a payment notification regarding installment payment or the like in the payment of the price to the user of the settlement application. The payment notification is a notification indicating the processing result of installment payment or the like. The payment notification may be the same as the processing result notification described in Modification Example 2-2.

[0285] FIG. 26 is a diagram showing an example of a payment notification. For example, when the payment of the price is instructed and it is determined that the usage conditions are not satisfied, the payment notification unit 113 causes a window W13 showing an error message to be displayed on the code screen SC1. The payment notification unit 113 causes the window W13 to be displayed on the code screen SC1 by transmitting the display data of the window W13 to the user terminal 30. The user terminal 30 displays the window W13 on the code screen SC1 based on the display data. The user closes the window W13, changes the setting to lump-sum payment, executes the settlement again, or pays the price by another settlement method other than the settlement application.

[0286] Note that, also in Modification Example 2-4, when payment is instructed and it is determined that the usage conditions are not satisfied, installment payment or the like may be changed to lump-sum payment for processing. In this case, the payment notification unit 113 may perform payment notification by causing the user terminal 30 to display a completion screen SC3 indicating that installment payment or the like has been changed to lump-sum payment for processing. The completion screen SC3 in this case is an example of payment notification.

[0287] Also, the payment notification may be performed by other notification means than the display of the window W13 on the code screen SC1. For example, the payment notification unit 113 may perform payment notification to the user by notification of the notification function of the payment application, e-mail, SMS message, message of the message application, message of the SNS, message in an application other than the payment application, push notification, pop-up notification, or banner notification. Even when the payment notification unit 113 performs payment notification by other notification means, the payment notification unit 113 may identify how the payment of which user is processed according to the determination result of the usage conditions, and perform a payment notification indicating the execution result of the identification to the user.

[0288] When the payment is instructed and it is determined that the usage conditions are not satisfied, the payment settlement system 1 of Modification Example 2-4 performs a payment notification regarding installment payment or the like in the payment of the price to the user of the payment application. Thereby, the user can know how the payment for which the user specified the installment payment or the like setting is processed, so that the payment settlement system 1 can effectively improve the convenience of the user.

[0289] [Modification Example 2-5] For example, in Modifications 2-3 and 2-4, when payment is instructed but the usage conditions are not met, an inquiry may be made as to whether to change to lump-sum payment and proceed with the processing. The user operates the user terminal 30 to input an answer to the inquiry. Depending on the user's answer, a change from installment payment or the like to lump-sum payment may be made and the payment may be processed. For example, when the usage limit for installment payment is insufficient, the settlement system 1 may make a proposal such as "Do you want to change to installment payment?" to the user as part of the inquiry.

[0290] The settlement system 1 of Modification 2-5 includes a change inquiry unit 114 and an answer execution unit 115. When it is determined that payment is instructed and the usage conditions are not met, the change inquiry unit 114 makes a change inquiry regarding whether to change the installment payment or the like in the payment of the amount due to another payment method on the user terminal 30. The other payment method is a payment method changed to lump-sum payment while keeping the current payer, or a payment method changed to another payer.

[0291] FIG. 27 is a diagram showing an example of a change inquiry. For example, when it is determined that payment is instructed and the usage conditions are not met, the change inquiry unit 114 causes a window W14 for inquiring whether to change to another payment method to be displayed on the code screen SC1. The change inquiry unit 114 causes the window W14 to be displayed on the code screen SC1 by transmitting the display data of the window W14 to the user terminal 30. The window W14 includes a button B140 indicating to change to another payment method and a button B141 indicating not to change to another payment method. In the example of FIG. 27, the change inquiry unit 114 makes a change inquiry as to whether to change to lump-sum payment as another payment method.

[0292] Incidentally, the change inquiry unit 114 may make a change inquiry on a screen other than the code screen SC1. For example, when the store code is read by the user terminal 30 as in Modifications 1-3, the change inquiry unit 114 may make a change inquiry on the confirmation screen SC5. Additionally, for example, in the case of a type of payment where the user selects a store from a list of stores for which payment is to be made, the change inquiry unit 114 may make a change inquiry on the screen that instructs that type of payment. The change inquiry unit 114 may make a change inquiry on other screens on the user terminal 30.

[0293] The response execution unit 115 executes processing according to the response to the change inquiry. The response to the change inquiry is the user's operation in response to the change inquiry. The user makes either a first response indicating a change to another payment method or a second response indicating no change to another payment method in response to the change inquiry. In the example of FIG. 27, the user makes either the first response or the second response by selecting either button B140 or button B141. The response to the change inquiry may be made by an operation on parts of the user interface other than buttons B140 and B141.

[0294] For example, the user terminal 30 identifies the user's response to the change inquiry based on an operation on the operation unit 34 and transmits response data indicating the user's response to the payment server 10. The payment server 10 receives the response data from the user terminal 30. The response execution unit 115 executes processing according to the response to the change inquiry based on the response data. For example, when the response indicates a change to another payment method, the response execution unit 115 executes payment based on the other payment method. In the example of FIG. 27, when the user selects button B140, the response execution unit 115 changes installment payment or the like to lump-sum payment and processes the payment by lump-sum payment. The method of processing the payment by lump-sum payment may be the same as the case where installment payment or the like is not used. That is, the method of processing the payment by lump-sum payment may be the same as a known payment service.

[0295] For example, when the response execution unit 115 indicates in the response that no change to other payment methods is to be made, an error is set without executing the payment. In this case, similar to Modification 2-4, a window W13 showing an error message may be displayed on the code screen SC1. The user may close the window W13, change the setting to lump-sum payment and execute the payment again, or pay the price using a payment method other than the payment application.

[0296] When the payment of the price is instructed and it is determined that the usage conditions are not satisfied, the settlement system 1 of Modification 2-5 makes an inquiry about whether to change the installment payment or the like in the payment of the price to another payment method on the user terminal 30. The settlement system 1 executes processing according to the response to the inquiry about the change. As a result, the user can change to another payment method according to the inquiry about the change, so that the settlement system 1 can execute flexible processing and effectively improve the convenience for the user.

[0297] [Modification 2-6] For example, although briefly described also in the second embodiment, the usage conditions may be conditions regarding whether the store for which payment is to be made supports installment payment or the like. In Modification 2-6, as in the second embodiment, a first lump-sum payment is first executed for the payment of the price, and then, as an example, a case is cited where it is determined by the card server 20 whether the usage conditions are satisfied afterwards. Note that also in Modification 2-6, it may be determined by the settlement server 10 whether the usage conditions are satisfied. That is, also in Modification 2-6, the settlement server 10 may include a usage condition determination unit 109 and a usage information acquisition unit 112.

[0298] The usage information acquisition unit 202 of Modification Example 2-6 acquires store information regarding the store as usage information. The store information is as described in Modification Example 1-3. In Modification Example 2-6, it is assumed that the store ID of the store that is the payment target is included in the usage information as the store information. The usage condition determination unit 203 determines whether the usage conditions are satisfied by determining whether the store supports installment payment or the like based on the store information. In Modification Example 2-6, similar to the second embodiment, the data storage unit 200 stores a correspondence database. The usage condition determination unit 203 may determine whether the store is a corresponding store or a non-corresponding store based on the correspondence database.

[0299] The payment system 1 of Modification Example 2-6 determines whether the usage conditions are satisfied by determining whether the store supports installment payment or the like based on the store information. Thereby, the payment system 1 can prevent a situation where installment payment or the like is used at a store that does not support installment payment or the like.

[0300] [Modification Example 2-7] For example, also in the second embodiment, similar to Modification Example 1-4, installment payment may be used for charging. In Modification Example 2-7, the case where the usage condition determination unit 109 and the usage information acquisition unit 112 are realized in the payment server 10 is taken as an example. Further, in Modification Example 2-7, the case where a charge screen SC6 similar to that in Modification Example 1-4 is displayed is taken as an example.

[0301] For example, the usage information acquisition unit 112 acquires usage information in the charge where the payment means is used. The usage information in the charge indicates the charge conditions specified by the user on the charge screen SC6. The usage information may include charge source information. In Modification 2-7, a case where the charge source information is stored in advance in the payment database DB1 is taken as an example, but the charge source may be specified on the charge screen SC6. In this case, the usage information acquisition unit 112 acquires, from the user terminal 30, charge source information indicating the charge source specified by the user on the charge screen SC6. The usage information acquisition unit 112 acquires usage information by acquiring information such as the charge conditions specified by the user from the user terminal 30.

[0302] For example, the usage condition determination unit 109 determines whether the usage conditions in the charge are satisfied based on the usage information. In Modification 2-7, the fact that a credit card of a specific credit card company is the charge source is described as an example of the usage conditions. Further, it is assumed that the charge information is included in the usage information. For example, the usage condition determination unit 109 determines whether the charge source indicated by the usage information is a credit card of a specific credit card company. If the usage condition determination unit 109 determines that the charge source is not a credit card of a specific credit card company, it determines that the usage conditions are not satisfied. If the usage condition determination unit 109 determines that the charge source is a credit card of a specific credit card company, it determines that the usage conditions are satisfied.

[0303] Note that the usage conditions in Modification 2-7 may also be any other arbitrary conditions as in the second embodiment. For example, the usage condition may be that the charge amount is equal to or greater than a predetermined amount. In this case, it is assumed that the charge amount is included in the usage information. The usage condition determination unit 109 determines whether the charge amount indicated by the usage information is equal to or greater than a predetermined amount. If the usage condition determination unit 109 determines that the charge amount is less than the predetermined amount, it determines that the usage conditions are not satisfied. If the usage condition determination unit 109 determines that the charge amount is equal to or greater than the predetermined amount, it determines that the usage conditions are satisfied.

[0304] Based on the determination result of the usage condition determination unit 109, the processing execution unit 102 of Modification Example 2-7 executes the processing for charging. When it is determined that the usage conditions are not satisfied, the processing execution unit 102 does not execute processing such as installment payment for charging. When it is determined that the usage conditions are satisfied, the processing execution unit 102 executes processing such as installment payment for charging. For example, the processing execution unit 102 executes processing such as installment payment by executing the settlement for charging by means of installment payment or the like. Similar to the payment of the price, as the settlement at the time of charging, the processing execution unit 102 may first perform the processing by lump-sum payment and then execute the processing of changing to installment payment or the like afterwards.

[0305] The settlement system 1 of Modification Example 2-7 acquires usage information for charging in which settlement means is used. Based on the usage information, the settlement system 1 determines whether the usage conditions for charging are satisfied. Based on the result of the determination, the settlement system 1 executes the processing for charging. Thereby, the settlement system 1 can prevent installment payment or the like not intended for charging from being executed, so that the convenience for the user can be improved.

[0306] [Modification Example 2-8] For example, the usage conditions may be conditions for whether installment payment or the like for charging is permitted. Also in Modification Example 2-8, taking as an example the case where the usage condition determination unit 109 and the usage information acquisition unit 112 are realized in the settlement server 10 as in Modification Example 2-7. In Modification Example 2-8, taking as an example the case where whether installment payment or the like for charging is permitted is set for each user as a usage condition other than a specific credit card company or the charging amount described in Modification Example 2-7. For example, the operator of the settlement service may specify for each user whether installment payment or the like for charging is permitted. In this case, it is assumed that permission information indicating whether installment payment or the like for charging is permitted is stored in the settlement database DB1 in association with the user ID.

[0307] When the usage condition determination unit 109 of the settlement server 10 is instructed to charge using a settlement method, it determines whether the usage conditions are met by determining whether to permit installment payments or the like for the charge. For example, the usage condition determination unit 109 determines whether the usage conditions are met by determining whether the permission information stored in the settlement database DB1 indicates permission. If the permission information does not indicate permission, the usage condition determination unit 109 determines that the usage conditions are not met, and if the permission information indicates permission, the usage condition determination unit 109 determines that the usage conditions are met.

[0308] In the settlement system 1 of Modification Example 2-8, when a charge using a settlement method is instructed, it determines whether the usage conditions are met by determining whether to permit installment payments or the like for the charge. Thereby, since the settlement system 1 can determine in real time whether the usage conditions are met at the time of charging, the convenience for the user can be effectively improved.

[0309] [Modification Example 2-9] For example, although briefly described in Modification Example 2-7, the usage conditions may be that a specific settlement method corresponding to installment payments or the like is used. In Modification Example 2-9, the case where the usage condition determination unit 109 and the usage information acquisition unit 112 are realized in the settlement server 10 is taken as an example. Assume that the data storage unit 100 stores data that can identify a settlement method corresponding to installment payments or the like as usage condition data. In Modification Example 2-9, assume that information that can identify the settlement method used by the user is shown in the usage information. The process for the usage information acquisition unit 112 to acquire the usage information may be the same as that in other modification examples.

[0310] For example, the usage condition determination unit 109 determines whether the usage conditions are satisfied by determining whether the settlement means supports installment payment or the like in the user terminal 30 based on the usage information. For example, the usage condition determination unit 109 determines whether the settlement means indicated by the usage information supports installment payment or the like based on the usage condition data. When the usage condition determination unit 109 determines that the settlement means indicated by the usage information does not support installment payment or the like, it determines that the usage conditions are not satisfied. When the usage condition determination unit 109 determines that the settlement means indicated by the usage information supports installment payment or the like, it determines that the usage conditions are satisfied.

[0311] When it is determined that the settlement means does not support installment payment or the like, the processing execution unit 102 of Modification Example 2-9 does not execute the processing such as installment payment. When it is determined that the settlement means supports installment payment or the like, the processing execution unit 102 executes the processing such as installment payment. When installment payment or the like is used for payment of the price as in the second embodiment, the processing execution unit 102 executes the processing such as installment payment for payment of the price when it is determined that the settlement means supports installment payment or the like. When installment payment or the like is used for charging as in Modification Example 2-7, the processing execution unit 102 executes the processing such as installment payment for charging when it is determined that the settlement means supports installment payment or the like.

[0312] The settlement system 1 of Modification Example 2-9 determines whether the usage conditions are satisfied by determining whether the settlement means supports installment payment or the like in the user terminal 30 based on the usage information. Thereby, the settlement system 1 can prevent installment payment or the like from being executed by an unintended settlement means, so that the convenience of the user can be improved.

[0313] [Modification Example 2-10] For example, although it was described as usage condition 3 in the second embodiment, the usage condition determination unit 203 may determine whether the usage condition is satisfied by determining whether the usage amount at the user terminal 30 is equal to or greater than a predetermined amount based on the usage information. This is as described in the second embodiment. The usage conditions may be specified by the user. This is not limited to Modification Example 2-10, and the same applies to the second embodiment and other modification examples. The same also applies to the case of combining the first embodiment, the third embodiment, or the fourth embodiment with the second embodiment.

[0314] The settlement system 1 of Modification Example 2-10 determines whether the usage condition is satisfied by determining whether the usage amount at the user terminal 30 is equal to or greater than a predetermined amount based on the usage information. Thereby, the settlement system 1 can prevent installment payments or the like from being executed in low-amount settlements where installment payments or the like cannot be used.

[0315] [Modification Example 2-11] For example, in Modification Example 2-10, the user may use points or the like for payment or recharge. Therefore, when the usage condition determination unit 203 is used for a different payment method other than the payment method, the usage condition determination unit 203 may determine whether the value obtained by subtracting the amount used for the different payment method from the usage amount is equal to or greater than a predetermined amount. In Modification Example 2-11, when the user performs a recharge of 10,000 yen with a credit card as the recharge source and uses 2,000 yen worth of points for the recharge. In this case, the usage condition determination unit 203 may determine the usage condition based on 8,000 yen obtained by subtracting 2,000 yen, which is the amount used for the recharge, from the recharge amount of 10,000 yen. The settlement server 10 may obtain information on the amount used for the recharge from the user terminal 30.

[0316] The settlement system 1 of Modification Example 2-11 determines whether the value obtained by subtracting the amount used for a different payment method other than the payment method from the usage amount is equal to or greater than a predetermined amount when the different payment method is used. Thereby, the settlement system 1 can appropriately determine the usage conditions for installment payments or the like even when points or the like are used.

[0317] [Modification Example 2-12] For example, although it was described as Usage Condition 2 in the second embodiment, the Usage Condition Determination Unit 203 may determine whether the usage conditions are satisfied by determining whether the usage is within the usage limit range related to installment payment or the like based on the usage information. This point is as described in the second embodiment.

[0318] The payment system 1 of Modification Example 2-12 determines whether the usage conditions are satisfied by determining whether the usage is within the usage limit range related to installment payment or the like based on the usage information. Thereby, the payment system 1 can prevent installment payment or the like exceeding the user's usage limit from being executed.

[0319] [Modification Example 2-13] For example, the payment server 10 may determine some of the usage conditions, and the card server 20 may determine the remaining usage conditions. The Usage Condition Determination Unit 109 of Modification Example 2-13 determines whether at least some of the usage conditions are satisfied based on the usage information when a payment using the user terminal 30 is executed. For example, the Usage Condition Determination Unit 109 of the payment server 10 may determine whether the payment source is a specific payment means at the time of payment. The Usage Condition Determination Unit 203 of the card server 20 may determine whether the remaining usage conditions are satisfied after the payment is executed. The usage conditions determined by each of the payment server 10 and the card server 20 may be any of the usage conditions exemplified in each of the second embodiment and Modification Examples 2-1 to 2-12.

[0320] The payment system 1 of Modification Example 2-13 determines whether at least some of the usage conditions are satisfied based on the usage information when a payment using the user terminal 30 is executed. Thereby, the payment system 1 can execute processing according to the determination result of the usage conditions at the time of execution of the payment. For example, when the payment system 1 notifies the user of the determination result of the usage conditions at the time of execution of the payment, the payment system 1 can allow the user to grasp in real time whether installment payment or the like is possible.

[0321] [5-3. Variations on the Third Embodiment] FIG. 28 is a diagram showing an example of a function realized in a variation on the third embodiment. For example, the settlement server 10 includes a setting cancellation notification unit 116. The setting cancellation notification unit 116 is realized by the control unit 11.

[0322] [Variation 3-1] For example, the cancellation conditions for canceling settings such as installment payments are not limited to the examples of the third embodiment. In Variation 3-1, a case will be given as an example where the store being a non-corresponding store that does not support installment payments or the like corresponds to the cancellation condition. The meaning of a non-corresponding store is as described in the second embodiment and Variation 1-3. In Variation 3-1, it is assumed that the store database described in Variation 1-3 is stored in the data storage unit 100. For example, the store database stores the store ID of each store and corresponding store information indicating whether the store is a corresponding store or a non-corresponding store.

[0323] The setting cancellation unit 105 in Variation 3-1 determines whether the cancellation condition is satisfied by determining whether the store is a non-corresponding store that does not support installment payments or the like, and cancels the installment payment or other settings when it is determined that the store is a non-corresponding store. In Variation 3-1, as in the third embodiment, a case will be given as an example where payment for the price is executed when the code C10 displayed on the user terminal 30 is read by the store terminal 40. For example, the settlement request includes the store ID and the code ID.

[0324] For example, the setting cancellation unit 105 acquires the installment payment or other settings associated with the code ID from the settlement database DB1. When the acquired installment payment or other settings indicate that installment payments or the like are not made, or when the installment payment or other settings do not exist in the settlement database DB1 in the first place, the setting cancellation unit 105 does not perform the process of determining whether to cancel the installment payment or other settings. In this case, lump-sum payment is made as usual.

[0325] For example, when the obtained installment payment or other settings indicate that installment payment or the like is to be made, the setting cancellation unit 105 performs a process of determining whether to cancel the installment payment or other settings. The setting cancellation unit 105 refers to the corresponding store information stored in the store database and acquires the corresponding store information associated with the store ID included in the payment request received from the store terminal 40. When the corresponding store information indicates a corresponding store, the setting cancellation unit 105 does not cancel the installment payment or other settings. That is, when the corresponding store information does not indicate a non-corresponding store, the setting cancellation unit 105 does not cancel the installment payment or other settings. The installment payment or other settings that have not been cancelled may be used as they are for subsequent payments or charges.

[0326] For example, when the corresponding store information indicates a non-corresponding store, the setting cancellation unit 105 cancels the installment payment or other settings. That is, when the corresponding store information does not indicate a corresponding store, the setting cancellation unit 105 cancels the installment payment or other settings. The setting cancellation unit 105 cancels the installment payment or other settings by deleting the installment payment or other settings stored in the payment database DB1 or changing the value of the installment payment or other settings so as to indicate that installment payment or the like is not to be made. When the installment payment or other settings are cancelled by the setting cancellation unit 105, the processing execution unit 102 may process the payment of the price in a lump sum, or may return an error to the user terminal 30 and the store terminal 40 without making the payment of the price.

[0327] The payment system 1 of Modification Example 3-1 determines whether the cancellation condition is satisfied by determining whether the store is a non-corresponding store that does not support installment payment or the like, and cancels the settings when it is determined that the store is a non-corresponding store. Thereby, the payment system 1 can prevent installment payment or the like from being performed when non-corresponding price payment is executed.

[0328] [Modification Example 3-2] For example, in the third embodiment, the case where the setting release unit 105 determines the release condition after the payment is instructed is taken as an example. The setting release unit 105 may be able to obtain information necessary for determining the release condition before the payment is instructed. In this case, the setting release unit 105 may perform the determination of the release condition before the payment is instructed and release the installment payment setting or the like. In Modification 3-2, similar to Modification 1-3, the settlement in the case where the user terminal 30 reads the code displayed on the store terminal 40 is taken as an example.

[0329] FIG. 29 is a diagram showing an example of a screen displayed on the user terminal 30 in Modification 3-2. For example, when the user terminal 30 reads the code displayed on the store terminal 40, as described in Modification 1-3, the user terminal 30 transmits information (for example, store ID and payment amount) included in the code to the settlement server 10. The settlement server 10 receives the information included in the code from the user terminal 30. The setting release unit 105 determines whether the release condition is satisfied based on the information included in the code.

[0330] For example, in the case of the release condition of Modification 3-1, the setting release unit 105 obtains the corresponding store information associated with the store ID indicated by the information included in the code from the store database, and determines whether the store to be paid is the corresponding store. When the payment amount being less than a predetermined amount corresponds to the release condition, the setting release unit 105 may determine whether the release condition is satisfied by determining whether the payment amount received from the user terminal 30 is less than the predetermined amount based on the information on the payment amount.

[0331] For example, when it is determined that the cancellation condition is satisfied, as shown on the left side of FIG. 29, the display control unit 101 causes the user terminal 30 to display a confirmation screen SC5 indicating that the settings such as installment payment specified on the code screen SC1 have been cancelled (for example, a confirmation screen SC5 including a panel P50 indicating that the 3-installment payment setting has been cancelled and changed to lump-sum payment). When it is determined that the cancellation condition is not satisfied, as shown on the right side of FIG. 29, the display control unit 101 causes the user terminal 30 to display a confirmation screen SC5 indicating that the settings such as installment payment specified on the code screen SC1 are not cancelled. The processing after the confirmation screen SC5 is displayed may be the same as that in Modification Example 1-3.

[0332] Note that in Modification Example 3-2 as well, similar to Modification Example 1-3, the payment server 10 may receive current location information from the user terminal 30, and the setting cancellation unit 105 may determine whether the cancellation condition is satisfied based on the current location information. For example, the setting cancellation unit 105 may identify a store near the current location indicated by the current location information and determine whether the cancellation condition is satisfied based on the corresponding store information of the store.

[0333] For example, in Modification Example 3-2 as well, similar to Modification Example 1-3, a type of payment may be executed in which the user selects a store to be paid from a list of stores displayed on the user terminal 30. In this case, the payment server 10 acquires store information indicating the store selected by the user from the user terminal 30. The setting cancellation unit 105 may determine whether the cancellation condition is satisfied based on the corresponding store information of the store indicated by the store information. When the user inputs a payment amount into the payment application, the payment server 10 may acquire the payment amount input by the user from the user terminal 30. The setting cancellation unit 105 may determine whether the cancellation condition is satisfied based on the payment amount acquired from the user terminal 30.

[0334] The payment system 1 in Modification Example 3-2 cancels settings such as installment payment based on the cancellation condition before the payment of the price is instructed. Thereby, the payment system 1 can prevent a situation where installment payment or the like is executed even though installment payment or the like cannot be used.

[0335] [Modification Example 3-3] For example, in the third embodiment, the case where the user uses installment payment or the like for payment has been described. However, the user may use installment payment or the like in other scenarios other than payment. In Modification Example 3-3, the case where the user uses installment payment or the like for charging is taken as an example. The meaning of installment payment or the like in charging is as described in Modification Examples 1-4 and 2-7. The setting acquisition unit 104 of Modification Example 3-3 acquires the setting of installment payment or the like in the charging where the settlement means is used. In Modification Example 3-3, similar to Modification Example 1-4, the setting of installment payment or the like in charging is stored in the settlement database DB1. The setting acquisition unit 104 acquires the setting of installment payment or the like in charging from the settlement database DB1.

[0336] The processing execution unit 102 of Modification Example 3-3 executes the processing of installment payment or the like in charging based on the setting of installment payment or the like in charging. The processing of installment payment or the like in charging may be the same as that in Modification Examples 1-4 and 2-7.

[0337] The setting cancellation unit 105 of Modification Example 3-3 cancels the setting of installment payment or the like in charging based on the cancellation condition. When the charge amount being less than a predetermined amount corresponds to the cancellation condition, the setting cancellation unit 105 determines whether the cancellation condition is satisfied by determining whether the charge amount is less than the predetermined amount based on the charge condition specified by the user before the charge is executed. When the charging source being a settlement means that does not support installment payment or the like corresponds to the cancellation condition, the setting cancellation unit 105 may determine whether the cancellation condition is satisfied by determining whether the charging source is the corresponding settlement means based on the charging source information.

[0338] For example, when the cancellation condition is not satisfied, the setting cancellation unit 105 does not cancel the installment payment setting for charging, etc., and when the cancellation condition is satisfied, it cancels the installment payment setting for charging, etc. The setting cancellation unit 105 cancels the installment payment setting for charging by deleting the installment payment setting for charging stored in the settlement database DB1 or changing the setting value to indicate that installment payment for charging is not to be performed.

[0339] The settlement system 1 of Modification 3-3 acquires the installment payment setting for charging. The settlement system 1 executes the installment payment process for charging based on the installment payment setting for charging. The settlement system 1 cancels the installment payment setting for charging based on the cancellation condition. As a result, the user of the settlement system 1 does not need to manually cancel the installment payment setting for charging, so the settlement system 1 can improve the convenience for the user in charging.

[0340] [Modification 3-4] For example, in Modification 3-3, the cancellation condition may be that charging is executed. The setting cancellation unit 105 determines whether the cancellation condition is satisfied by determining whether charging has been executed. When it is determined that charging has been executed, the installment payment setting, etc. may be cancelled. The execution of charging may be determined by a known method. For example, the setting cancellation unit 105 may determine that charging has been executed when the balance of the electronic money increases, or may determine that charging has been executed based on the execution result of a program indicating a series of processes for charging. The cancellation condition may be the charging amount. For example, when a charge of a certain amount or more has been executed, the installment payment setting, etc. may be cancelled.

[0341] The setting cancellation unit 105 of Modification Example 3-4 may determine whether or not charging has been executed based on the processing result of the processing execution unit 102. When the processing execution unit 102 is not executing the charging process, the setting cancellation unit 105 does not determine that charging has been executed. When the processing execution unit 102 executes the charging process, the setting cancellation unit 105 determines that charging has been executed. When it is not determined that charging has been executed, the setting cancellation unit 105 does not cancel the installment payment or other settings. The installment payment or other settings that have not been canceled may be used for subsequent charges.

[0342] The payment system 1 of Modification Example 3-4 determines whether or not the cancellation condition is satisfied by determining whether or not charging has been executed, and cancels the setting when it is determined that charging has been executed. Thereby, the payment system 1 can cancel the installment payment or other settings every time charging is executed. For example, when there are few users who want to use the installment payment or the like continuously, the payment system 1 can improve the convenience for the users.

[0343] [Modification Example 3-5] For example, the cancellation condition is not limited to the examples of the third embodiment and Modification Examples 3-1 to 3-4. For example, the cancellation condition may be that the payment means used at the user terminal 30, that is, the payment means used, is changed. The setting cancellation unit 105 determines whether or not the cancellation condition is satisfied by determining whether or not the payment means used has been changed, and cancels the installment payment or other settings when it is determined that the payment means used has been changed. The payment means used is the payment source or the charging source.

[0344] For example, when the payer corresponds to the payment and settlement means, the user changes the payer from the payer selection screen SC2. The user terminal 30 transmits the payer information of the payer selected by the user to the settlement server 10. When the settlement server 10 receives the payer information from the user terminal 30, it updates the payer information stored in the settlement database DB1. The setting cancellation unit 105 determines that the payer has been changed when the payer information is updated. When it is not determined that the payer has been changed, the setting cancellation unit 105 does not cancel the installment payment or other settings, and when it is determined that the payer has been changed, the installment payment or other settings are cancelled.

[0345] For example, when the recharge source corresponds to the payment and settlement means, the user changes the payer from the recharge source selection screen SC7. The user terminal 30 transmits the recharge source information of the recharge source selected by the user to the settlement server 10. When the settlement server 10 receives the recharge source information from the user terminal 30, it updates the recharge source information stored in the settlement database DB1. The setting cancellation unit 105 determines that the recharge source has been changed when the recharge source information is updated. When it is not determined that the recharge source has been changed, the setting cancellation unit 105 does not cancel the installment payment or other settings, and when it is determined that the recharge source has been changed, the installment payment or other settings are cancelled.

[0346] The settlement system 1 of Modification Example 3-5 determines whether the cancellation condition is satisfied by determining whether the payment and settlement means has been changed, and when it is determined that the payment and settlement means has been changed, cancels the installment payment or other settings. Thereby, the settlement system 1 can prevent the installment payment or other settings from being carried over when the payment and settlement means is changed. For example, although the user desired installment payment or the like with the previous payment and settlement means, the user may not desire installment payment or the like with the changed payment and settlement means. In such a case, the settlement system 1 can prevent the user from forgetting to cancel the installment payment or other settings and the installment payment or the like being executed with the changed payment and settlement means.

[0347] [Modification Example 3-6] For example, installment payments, etc. may only correspond to specific payment methods. Hereinafter, the payment methods corresponding to installment payments, etc. are referred to as corresponding payment methods. Payment methods that do not correspond to installment payments, etc. are referred to as non-corresponding payment methods. The setting release unit 105 determines whether the used payment method has been changed from the corresponding payment method corresponding to installment payments, etc. to the non-corresponding payment method that does not correspond to installment payments, etc., and may release the setting when it is determined that the used payment method has been changed from the corresponding payment method to the non-corresponding payment method.

[0348] In Modification Example 3-6, the data storage unit 100 stores payment method data in which at least one of the corresponding payment method and the non-corresponding payment method is defined. In the payment method data, only the corresponding payment method may be defined, only the non-corresponding payment method may be defined, or both the corresponding payment method and the non-corresponding payment method may be defined. In Modification Example 3-6, a case where only the credit card of a specific credit card company, "AAA Card", is the corresponding payment method is taken as an example.

[0349] For example, when the used payment method is changed, the setting release unit 105 determines whether the used payment method has been changed from the corresponding payment method to the non-corresponding payment method based on the payment method data. When it is not determined that the used payment method has been changed from the corresponding payment method to the non-corresponding payment method, the setting release unit 105 does not determine that the release condition is satisfied, and when it is determined that the used payment method has been changed from the corresponding payment method to the non-corresponding payment method, the setting release unit 105 determines that the release condition is satisfied. For example, when the used payment method is changed from the credit card "AAA Card" to another payment method, the setting release unit 105 determines that the release condition is satisfied. If the user registers two credit cards "AAA Card" in the payment application and the used payment method is changed from the first credit card "AAA Card" to the second credit card "AAA Card", the setting release unit 105 determines that the release condition is not satisfied.

[0350] For example, when the payment source is changed, the setting release unit 105 determines whether the payment source has been changed from the corresponding payment means to a non-corresponding payment means based on the payment means data. If the setting release unit 105 determines that the payment source has not been changed from the corresponding payment means to a non-corresponding payment means, it does not determine that the release condition is satisfied. If the setting release unit 105 determines that the payment source has been changed from the corresponding payment means to a non-corresponding payment means, it determines that the release condition is satisfied. For example, when the payment source is changed from the credit card "AAA Card" to another payment means, the setting release unit 105 determines that the release condition is satisfied.

[0351] For example, when the charging source is changed, the setting release unit 105 determines whether the charging source has been changed from the corresponding payment means to a non-corresponding payment means based on the payment means data. If the setting release unit 105 determines that the charging source has not been changed from the corresponding payment means to a non-corresponding payment means, it does not determine that the release condition is satisfied. If the setting release unit 105 determines that the charging source has been changed from the corresponding payment means to a non-corresponding payment means, it determines that the release condition is satisfied. For example, when the charging source is changed from the credit card "AAA Card" to another payment means, the setting release unit 105 determines that the release condition is satisfied.

[0352] The payment system 1 of Modification Example 3-6 determines whether the used payment means has been changed from the corresponding payment means to a non-corresponding payment means, and when it is determined that the used payment means has been changed from the corresponding payment means to a non-corresponding payment means, releases settings such as installment payment. As a result, when the user changes the used payment means from the corresponding payment means to a non-corresponding payment means, the payment system 1 does not need to manually release settings such as installment payment. Therefore, the payment system 1 can reduce the operation burden on the user and effectively improve the convenience for the user.

[0353] [Modification Example 3-7] For example, in Modification Example 3-6, when it is determined that the usage payment means has been changed from any one of a plurality of corresponding payment means to another corresponding payment means, the setting cancellation unit 105 may not cancel the installment payment setting or the like. When it is determined that the usage payment means has been changed from any one of a plurality of corresponding payment means to a non-corresponding payment means, the setting cancellation unit 105 may cancel the installment payment setting or the like.

[0354] For example, assume that the user has registered two credit cards, "AAA Card", in the payment application. When the usage payment means is changed from the first credit card "AAA Card" to the second credit card "AAA Card", the setting cancellation unit 105 determines that the cancellation condition is not satisfied. When the usage payment means is changed from either of the two credit cards "AAA Card" to a non-corresponding payment means such as a credit card of another company, the setting cancellation unit 105 determines that the cancellation condition is satisfied.

[0355] For example, if the usage payment means is the payment source, when the payment source is changed from the first credit card "AAA Card" to the second credit card "AAA Card", the setting cancellation unit 105 determines that the cancellation condition is not satisfied. When the payment source is changed from either of the two credit cards "AAA Card" to a non-corresponding payment means such as a credit card of another company, the setting cancellation unit 105 determines that the cancellation condition is satisfied.

[0356] For example, if the usage payment means is the recharge source, when the recharge source is changed from the first credit card "AAA Card" to the second credit card "AAA Card", the setting cancellation unit 105 determines that the cancellation condition is not satisfied. When the recharge source is changed from either of the two credit cards "AAA Card" to a non-corresponding payment means such as a credit card of another company, the setting cancellation unit 105 determines that the cancellation condition is satisfied.

[0357] When it is determined that the payment method in use has been changed from one of the plurality of supported payment methods to another supported payment method, the payment system 1 of Modification Example 3-7 does not cancel the installment payment or other settings. When it is determined that the payment method in use has been changed from one of the plurality of supported payment methods to an unsupported payment method, the installment payment or other settings are cancelled. As a result, when the user changes the payment method in use from one supported payment method to another supported payment method, the payment system 1 does not need to specify the installment payment or other settings again. Therefore, the payment system 1 can reduce the operation burden on the user and effectively improve the convenience for the user.

[0358] [Modification Example 3-8] For example, in Modification Example 3-7, when the payment method in use is changed from one of the plurality of supported payment methods to an unsupported payment method, the setting cancellation unit 105 cancels the installment payment or other settings. Thereafter, when it is determined that the payment method in use has been changed from the unsupported payment method to one of the plurality of supported payment methods, the installment payment or other settings may be applied again. In Modification Example 3-7, it is assumed that the installment payment or other settings before cancellation are held in the payment database DB1. In this case, the setting cancellation unit 105 may cancel the installment payment or other settings by changing the value of a flag indicating whether the installment payment or other settings are valid. The flag may be stored in the payment database DB1. The installment payment or other settings before cancellation may be held in a location other than the payment database DB1.

[0359] For example, assume that the user has registered two credit cards, "AAA Card", in the payment application. When the payment method in use is changed from the first credit card, "AAA Card", to an unsupported payment method, the setting cancellation unit 105 cancels the installment payment setting. The installment payment or other settings before cancellation are held in an arbitrary location such as the payment database DB1. Thereafter, when the payment method in use is changed from the unsupported payment method to the second credit card, "AAA Card", the setting cancellation unit 105 applies the held installment payment or other settings before cancellation again. That is, the setting cancellation unit 105 stores the installment payment or other settings before cancellation in the payment database DB1.

[0360] For example, if the payment and settlement means is the payer, when the payer is changed from the first credit card "AAA Card" to a non - supported payment and settlement means, the setting release unit 105 releases the installment payment setting. The settings such as the installment payment before release are held in an arbitrary location such as the settlement database DB1. Then, when the payer is changed from the non - supported payment and settlement means to the second credit card "AAA Card", the setting release unit 105 reapplies the held settings such as the installment payment before release. That is, the setting release unit 105 stores the settings such as the installment payment before release in the settlement database DB1.

[0361] For example, if the payment and settlement means is the charging source, when the charging source is changed from the first credit card "AAA Card" to a non - supported payment and settlement means, the setting release unit 105 releases the installment payment setting. The settings such as the installment payment before release are held in an arbitrary location such as the settlement database DB1. Then, when the charging source is changed from the non - supported payment and settlement means to the second credit card "AAA Card", the setting release unit 105 reapplies the held settings such as the installment payment before release. That is, the setting release unit 105 stores the settings such as the installment payment before release in the settlement database DB1.

[0362] In the payment and settlement system 1 of Modification Example 3 - 8, when the payment and settlement means is changed from any of a plurality of supported payment and settlement means to a non - supported payment and settlement means, the settings such as the installment payment are released. Then, when it is determined that the payment and settlement means is changed from the non - supported payment and settlement means to any of the plurality of supported payment and settlement means, the settings such as the installment payment are reapplied. As a result, the user does not need to perform an operation to restore the settings such as the installment payment. Therefore, the payment and settlement system 1 can reduce the operation burden on the user and effectively enhance the convenience for the user.

[0363] [Modification Example 3 - 9] For example, the setting cancellation unit 105 determines whether the cancellation condition is satisfied by determining whether an app (payment app or other app) or browser stored in the user terminal 30 has ended. When it is determined that the app or browser has ended on the user terminal 30, the settings such as installment payment may be cancelled. In Modification Example 3-9, when the user performs an operation to end the payment app, the user terminal 30 sends an end notification indicating the end of the payment app to the payment server 10. The end notification is data in a predetermined format indicating the end of the payment app. Note that the operation to end the payment app includes operations such as deleting, updating, restarting, or logging out of the payment app.

[0364] In Modification Example 3-9, a case where the end of the payment app corresponds to the cancellation condition is taken as an example. For example, the setting cancellation unit 105 determines whether the payment app has ended by determining whether it has received an end notification from the user terminal 30. If the setting cancellation unit 105 determines that it has not received an end notification from the user terminal 30, it does not determine that the payment app has ended and does not cancel the settings such as installment payment. When the setting cancellation unit 105 determines that it has received an end notification from the user terminal 30, it determines that the payment app has ended and cancels the settings such as installment payment.

[0365] Note that the user terminal 30 does not necessarily need to send an end notification particularly when the payment app ends. In this case, the setting cancellation unit 105 may determine whether the payment app has ended by determining whether the state of not receiving any information from the payment app has continued for a predetermined time (for example, 10 minutes) or more. When the payment server 10 receives some information from the payment app, it shall save the current date and time as the date and time when it last communicated with the payment app in the data storage unit 100. The setting cancellation unit 105 may perform the above determination based on the saved date and time.

[0366] For example, when it is not determined that the state of not receiving any information from the payment application has continued for a predetermined time or more, the setting release unit 105 does not determine that the payment application has ended and does not release settings such as installment payments. When it is determined that the state of not receiving any information from the payment application has continued for a predetermined time or more, the setting release unit 105 determines that the payment application has ended and releases settings such as installment payments. Even when another application or browser other than the payment application is used, the setting release unit 105 may determine the end of the other application or browser in the same manner as the payment application.

[0367] The payment system 1 of Modification 3-9 determines whether the release condition is satisfied by determining whether an application or browser, taking the payment application as an example, has ended. When it is determined at the user terminal 30 that the payment application has ended, settings such as installment payments are released. As a result, the user does not need to trouble to release settings such as installment payments in preparation for the next startup of the payment application. Therefore, the payment system 1 can effectively improve the convenience for the user. For example, when the user starts the payment application next time, the payment system 1 can prevent unintended installment payments or the like from being made due to remaining settings such as installment payments.

[0368] [Modification 3-10] For example, the setting acquisition unit 104 may acquire a first setting regarding the use of installment payments or the like and a second setting regarding the necessity of releasing the first setting. That is, as one of the settings such as installment payments, the necessity of the process by the setting release unit 105 may be specified. In the payment database DB1 of Modification 3-10, the first setting and the second setting are stored as settings such as installment payments. The setting method of the first setting may be the same as that in the third embodiment. The second setting may be specified by the user or may be specified in advance on the side of the payment system 1.

[0369] The processing execution unit 102 of Modification Example 3-10 executes processing such as installment payment based on the first setting. The first setting is the same as the setting for installment payment and the like in the third embodiment. For example, when the first setting does not indicate the use of installment payment or the like, the processing execution unit 102 does not execute the processing such as installment payment, and when the first setting indicates the use of installment payment or the like, the processing execution unit 102 executes the processing such as installment payment.

[0370] The setting release unit 105 of Modification Example 3-10 releases the first setting based on the second setting and the release condition. For example, when the second setting indicates releasing the first setting, the setting release unit 105 releases the first setting based on the release condition. The process of releasing the first setting based on the release condition may be the same as any one of the third embodiment and Modification Examples 3-1 to 3-9. When the second setting indicates releasing the first setting, the setting release unit 105 does not perform determination or the like of the release condition and does not release the first setting.

[0371] The payment system 1 of Modification Example 3-10 acquires a first setting regarding the presence or absence of use of installment payment or the like and a second setting regarding the necessity of releasing the first setting. The payment system 1 executes processing such as installment payment based on the first setting. The payment system 1 releases the first setting based on the second setting and the release condition. Thereby, since the user can specify whether to release the installment payment setting or not, the payment system 1 can effectively improve the convenience of the user.

[0372] [Modification Example 3-11] For example, when the processing by the setting release unit 105 is executed, the user may be notified that the setting such as installment payment has been released. The payment system 1 of Modification Example 3-11 includes a setting release notification unit 116. The setting release notification unit 116 gives a setting release notification regarding the release of the setting such as installment payment to the user when the setting such as installment payment is released. The setting release notification is a notification indicating that the setting such as installment payment has been released.

[0373] FIG. 30 is a diagram showing an example of a setting cancellation notice. For example, the setting cancellation notice unit 116 issues a setting cancellation notice by causing a message indicating that a setting such as installment payment has been cancelled (in FIG. 30, the message "The installment payment setting has been cancelled...") to be displayed on the completion screen SC3. The setting cancellation notice unit 116 identifies that a setting such as installment payment has been cancelled based on the processing result by the setting cancellation unit 105. When a setting such as installment payment has been cancelled, the setting cancellation notice unit 116 generates display data for the completion screen SC3 indicating that fact and transmits it to the user terminal 30. The setting cancellation notice unit 116 may be a function included in the display control unit 101.

[0374] Also, the setting cancellation notice may be issued by other notification means other than the completion screen SC3. For example, the setting cancellation notice unit 116 may issue a setting cancellation notice to the user by means of a notification of the notification function of the payment application, an e-mail, an SMS message, a message of the message application, an SNS message, a message in an application other than the payment application, a push notification, a pop-up notification, or a banner notification. Even when the setting cancellation notice unit 116 issues a setting cancellation notice by other notification means, the setting cancellation notice unit 116 may identify that the installment payment setting has been cancelled according to the processing result of the setting cancellation unit 105 and issue a setting cancellation notice to the user.

[0375] The payment system 1 of Modification 3-11 issues a setting cancellation notice regarding the cancellation of a setting such as installment payment to the user when the setting such as installment payment has been cancelled. Thereby, since it becomes easier for the user to notice that a setting such as installment payment has been cancelled, the payment system 1 can effectively improve the convenience of the user.

[0376] [5-4. Modifications Regarding the Fourth Embodiment] FIG. 31 is a diagram showing an example of a function realized in a modification related to the fourth embodiment. For example, the settlement server 10 includes a display control unit 101, a usage limit information acquisition unit 117, a usage amount information acquisition unit 118, a charge execution unit 119, a charge inquiry unit 120, a usage history information acquisition unit 121, and an application reception unit 122. Each of the display control unit 101, the usage limit information acquisition unit 117, the usage amount information acquisition unit 118, the charge execution unit 119, the charge inquiry unit 120, the usage history information acquisition unit 121, and the application reception unit 122 is realized by the control unit 11.

[0377] [Modification Example 4-1] For example, although described in the fourth embodiment as well, the setting acquisition unit 104 may acquire settings such as installment payments for payment of the price of goods or services provided by stores where settlement means are available. In Modification Example 4-1, similar to the fourth embodiment, a settlement of the type in which the code C10 displayed on the user terminal 30 is read by the store terminal 40 may be executed, but a case where another type of settlement is executed will be taken as an example. For example, similar to Modification Example 1-3, a settlement of the type in which the code displayed on the store terminal 40 is read by the user terminal 30 may be executed.

[0378] For example, the user terminal 30 acquires information necessary for payment (for example, store ID, payment amount, or other information) from the code displayed on the store terminal 40. The user terminal 30 transmits the information acquired from the code to the settlement server 10. When the settlement server 10 receives the information from the user terminal 30, the display control unit 101 causes the user terminal 30 to display a confirmation screen SC5 similar to FIG. 20. These series of processes may be the same as those in Modification Example 1-3.

[0379] Similar to Modification Examples 1-3, the setting acquisition unit 104 of Modification Example 4-1 may acquire settings such as installment payments specified on the confirmation screen SC5, or may acquire settings such as installment payments specified in advance on the code screen SC1 or the like. Further, as described in the fourth embodiment, the setting acquisition unit 104 may acquire settings such as installment payments specified at a location other than the payment application. The setting acquisition unit 104 may acquire settings such as installment payments specified on the side of the payment system 1.

[0380] The processing execution unit 102 of Modification Example 4-1 executes processing such as installment payments in the payment of the price based on the settings such as installment payments. For example, when the user instructs payment from the confirmation screen SC5, the payment server 10 receives a payment request from the user terminal 30. The processing execution unit 102 executes processing such as installment payments based on the payment request received from the user terminal 30 and the settings such as installment payments. These series of processes may be the same as those in Modification Examples 1-3.

[0381] Note that, also in Modification Example 4-1, similar to Modification Examples 1-3, a payment of a type in which the payment destination store is specified from the list of stores displayed on the user terminal 30 may be executed. In this case, similar to Modification Examples 1-3, settings such as installment payments may be specified from the payment application, or settings such as installment payments may be specified at a location other than the payment application. Modification Example 4-1 differs from Modification Examples 1-3 in that it is not limited to the specification of settings such as installment payments from the payment application.

[0382] The payment system 1 of Modification Example 4-1 includes a display control unit 101. When the payment of the price is completed, the display control unit 101 causes the user terminal 30 to display a completion screen SC3 indicating that the payment of the price has been completed, and a completion screen SC3 indicating that a payment regarding installment payments or the like has been made. Although it differs from the first embodiment in that settings such as installment payments may be specified at a location other than the payment application, the method of displaying the completion screen SC3 may be the same as that of the first embodiment. The display control unit 101 may cause the user terminal 30 to display the completion screen SC3 by generating display data of the completion screen SC3 and transmitting it to the user terminal 30.

[0383] The payment system 1 of Modification Example 4-1 acquires settings such as installment payments in the payment of the price. Based on the settings such as installment payments, the payment system 1 executes processing such as installment payments in the payment of the price. When the payment of the price is completed, the payment system 1 causes the user terminal 30 to display a completion screen SC3 indicating that the payment regarding the installment payment or the like has been made. As a result, when the user uses installment payments or the like in the payment of the price, the user can grasp that the payment of the installment payment or the like has been made on the completion screen SC3. Therefore, the payment system 1 can effectively improve the convenience for the user.

[0384] [Modification Example 4-2] For example, as described in the second embodiment, a usage limit such as an installment payment may be set for the user. In this case, similar to the second embodiment, the user may be allowed to use installment payments or the like within the range not exceeding the usage limit. In Modification Example 4-2, the case where the usage limit of the user is displayed on the user terminal 30 will be taken as an example.

[0385] The payment system 1 of Modification Example 4-2 includes a display control unit 101 and a usage limit information acquisition unit 117. The usage limit information acquisition unit 117 acquires usage limit information regarding a usage limit such as an installment payment. In Modification Example 4-2, it is assumed that the usage limit information described in the second embodiment is stored in the payment database DB1. For example, the usage limit information acquisition unit 117 inquires the card server 20 about the usage limit information and acquires the usage limit information from the card server 20. The usage limit information acquisition unit 117 stores the usage limit information in the payment database. The usage limit information acquisition unit 117 does not necessarily store the usage limit information in the payment database.

[0386] The display control unit 101 causes the user terminal 30 to display a usage limit screen related to the usage limit based on the usage limit information. The usage limit screen is a screen on which the usage limit is displayed among the screens displayed on the user terminal 30. In Modification Example 4-2, as an example of the usage limit screen, the confirmation screen SC5 will be described. The usage limit screen may be other screens than the completion screen SC3. For example, the usage limit screen may be the code screen SC1, the payment source selection screen SC2, the confirmation screen SC5, the charge screen SC6, the charge source selection screen SC7, a screen for the purpose of only checking the usage limit, or other screens.

[0387] FIG. 32 is a diagram showing an example of the confirmation screen SC5 of Modification Example 4-2. For example, the display control unit 101 generates display data of the confirmation screen SC5 showing the usage limit indicated by the usage limit information and transmits it to the user terminal 30. The display control unit 101 may cause the user terminal 30 to display the confirmation screen SC5 showing at least one of the currently used amount using installment payments or the like and the remaining amount of the usage limit. The display control unit 101 may cause the user terminal 30 to display the confirmation screen SC5 including images such as icons or gauges indicating these amounts.

[0388] The payment system 1 of Modification Example 4-2 causes the user terminal 30 to display a usage limit screen based on the usage limit information. Thereby, the user can grasp the usage limit on the usage limit screen on the user terminal 30, so the payment system 1 can effectively improve the convenience of the user.

[0389] [Modification Example 4-3] For example, in Modification Example 4-2, the display control unit 101 may cause the user terminal 30 to display, as the usage limit screen, the code screen SC1 including a code related to the payment of the price and showing the usage limit. When the code C10 on the code screen SC1 is read, the processing execution unit 102 executes processing such as installment payment based on the installment payment setting or the like. The processing of the processing execution unit 102 may be the same as that of the fourth embodiment.

[0390] FIG. 33 is a diagram showing an example of the code screen SC1 of Modification Example 4-3. For example, the display control unit 101 generates display data of the code screen SC1 indicating the usage frame indicated by the usage frame information and transmits it to the user terminal 30. The display control unit 101 may cause the user terminal 30 to display a code screen SC1 indicating at least one of the current amount using installment payment or the like and the remaining amount of the usage frame. The display control unit 101 may cause the user terminal 30 to display a code screen SC1 including an image such as an icon or a gauge indicating these amounts.

[0391] The settlement system 1 of Modification Example 4-3 causes the user terminal 30 to display the code screen SC1 indicating the usage frame as a usage frame screen. When the code C10 of the code screen SC1 is read, the settlement system 1 executes a process such as installment payment based on the installment payment setting or the like. As a result, the user can grasp the usage frame and execute the payment directly on the code screen SC1, so that the settlement system 1 can effectively improve the convenience of the user.

[0392] [Modification Example 4-4] For example, in Modification Examples 4-2 and 4-3, information indicating whether or not the usage amount subject to installment payment or the like is within the range of the usage frame may be displayed on the usage frame screen. The settlement system 1 of Modification Example 4-4 includes a usage amount information acquisition unit 118. The usage amount information acquisition unit 118 acquires usage amount information regarding the usage amount in the user terminal 30. In Modification Example 4-4, similar to Modification Examples 1-3 and 4-2, the case where the code displayed on the store terminal 40 is read by the user terminal 30 is taken as an example. The usage amount information acquisition unit 118 acquires the usage amount information included in the information acquired from the user terminal 30.

[0393] The display control unit 101 of Modification Example 4-4 determines whether the usage amount is within the range of the usage limit based on the usage limit information and the usage amount information, and causes the user terminal 30 to display a usage limit screen indicating the execution result of the determination. For example, the display control unit 101 determines whether the remaining amount of the usage limit indicated by the usage limit information is equal to or greater than the usage amount indicated by the usage amount information. That is, the display control unit 101 determines whether the usage limit indicated by the usage limit information is sufficient for installment payment or the like of the usage amount indicated by the usage amount information. In Modification Example 4-4, as in Modification Example 4-2, the case where the confirmation screen SC5 corresponds to the usage limit screen is taken as an example. Also in Modification Example 4-4, as in Modification Example 4-2, the usage limit screen may be a screen other than the confirmation screen SC5.

[0394] FIG. 34 is a diagram showing an example of the confirmation screen SC5 of Modification Example 4-4. For example, when it is determined that the usage amount is within the range of the usage limit, the display control unit 101 causes the user terminal 30 to display a confirmation screen SC5 indicating that the usage amount is within the range of the usage limit, as shown on the left side of FIG. 34. When it is determined that the usage amount is not within the range of the usage limit, the display control unit 101 causes the user terminal 30 to display a confirmation screen SC5 indicating that the usage amount is not within the range of the usage limit, as shown on the right side of FIG. 34. The display control unit 101 may use other means such as an icon instead of the message as shown in FIG. 34 to display on the confirmation screen SC5 whether the usage amount is within the range of the usage limit.

[0395] The settlement system 1 of Modification Example 4-4 determines whether the usage amount is within the range of the usage limit based on the usage limit information and the usage amount information, and causes the user terminal 30 to display a usage limit screen indicating the execution result of the determination. Thereby, the user can grasp whether the usage limit is sufficient on the usage limit screen, so that the settlement system 1 can effectively improve the convenience for the user.

[0396] [Modification Example 4-5] For example, in the fourth embodiment as well, installment payments or the like may be used for charging, similar to Modifications 1-4, 2-7, and 3-3. In Modification 4-5, it differs from Modification 1-4 in that it is not limited to specifying settings such as installment payments from the payment application, but other aspects may be the same as those of Modification 1-4. In Modification 4-5, it differs from Modification 2-7 in that the usage conditions may not be determined, but other aspects may be the same as those of Modification 1-4. In Modification 4-5, it differs from Modification 3-3 in that the settings for installment payments or the like may not be canceled, but other aspects may be the same as those of Modification 1-4.

[0397] The setting acquisition unit 104 of Modification 4-5 acquires settings such as installment payments in the charge where the payment means is used. For example, the setting acquisition unit 104 acquires the settings such as installment payments in the charge stored in the payment database DB1. The process execution unit 102 executes processes such as installment payments in the charge based on the settings such as installment payments in the charge. These processes may be the same as the processes for acquiring the installment payment settings in the charge in Modifications 1-4, 2-7, and 3-3 and the processes such as installment payments executed based on the settings.

[0398] The payment system 1 of Modification 4-5 includes a charge execution unit 119. The charge execution unit 119 executes a charge based on the result of processes such as installment payments. In a charge, the charge amount may exceed the usage limit. In this case, the charge execution unit 119 of Modification 4-5 does not necessarily make the charge an error and not execute it, but when the charge amount in the charge exceeds the usage limit for installment payments or the like, the charge execution unit 119 of Modification 4-5 executes the charge within the range of the usage limit. For example, the charge execution unit 119 may execute the charge with the remaining amount of the current usage limit as the charge amount, or may execute the charge with a charge amount less than the remaining amount of the current usage limit.

[0399] For example, assume that the remaining amount of the usage limit for installment payments or the like is 8,000 yen. Further, assume that the charge amount is 10,000 yen. In this case, the charge amount will exceed the usage limit. The charge execution unit 119 may execute the charge with 8,000 yen, which is the remaining amount of the usage limit, as the charge amount, or may execute the charge with an amount less than 8,000 yen, which is the remaining amount of the usage limit, as the charge amount. The charge execution unit 119 determines the charge amount so as to fall within the range of the usage limit, and executes the charge based on the determined charge amount.

[0400] The settlement system 1 of Modification Example 4-5 acquires the settings for installment payments or the like in the charge. The settlement system 1 executes the processing for installment payments or the like in the charge based on the settings for installment payments or the like in the charge. When the charge amount in the charge exceeds the usage limit for installment payments or the like, the settlement system 1 executes the charge within the range of the usage limit. Thereby, even if the charge amount exceeds the usage limit, the settlement system 1 can execute the charge within the range of the usage limit, so that the convenience for the user can be improved. For example, since the user does not need to instruct the charge again because the charge has become an error, the settlement system 1 can reduce the operation burden on the user and improve the convenience for the user.

[0401] [Modification Example 4-6] For example, in Modification Example 4-5, it may be possible to inquire the user whether to execute the charge within the range of the usage limit. The settlement system 1 of Modification Example 4-6 includes a charge inquiry unit 120. When the charge amount exceeds the usage limit, the charge inquiry unit 120 makes a charge inquiry to the user regarding whether to execute the charge within the range of the usage limit. In Modification Example 4-6, the case where the inquiry is made on the charge screen SC6 is taken as an example, but the charge inquiry unit 120 may make the charge inquiry on a screen other than the charge screen SC6.

[0402] FIG. 35 is a diagram showing an example of a charge inquiry. For example, when the charge amount exceeds the usage limit, the charge inquiry unit 120 causes a window W64 for inquiring whether to execute a charge within the range of the usage limit to be displayed on the charge screen SC6. The charge inquiry unit 120 causes the window W64 to be displayed on the charge screen SC6 by transmitting the display data of the window W64 to the user terminal 30. The window W64 includes a button B640 indicating execution of a charge within the range of the usage limit and a button B641 indicating non - execution of a charge within the range of the usage limit.

[0403] The charge execution unit 119 of Modification Example 4 - 6 executes a charge within the range of the usage limit based on the answer to the charge inquiry. The answer to the charge inquiry is an operation of the user in response to the charge inquiry. The user makes either a first answer indicating execution of a charge within the range of the usage limit or a second answer indicating non - execution of a charge within the range of the usage limit in response to the charge inquiry. In the example of FIG. 35, the user makes either the first answer or the second answer by selecting either the button B640 or the button B641.

[0404] For example, the user terminal 30 identifies the user's answer to the charge inquiry based on an operation on the operation unit 34 and transmits answer data indicating the user's answer to the settlement server 10. The settlement server 10 receives the answer data from the user terminal 30. The charge execution unit 119 determines whether to execute a charge within the range of the value limit based on the answer to the charge inquiry based on the answer data. If the answer indicates non - execution of a charge within the range of the usage limit, the charge execution unit 119 sets an error without executing the charge. If the answer indicates execution of a charge within the range of the usage limit, the charge execution unit 119 executes a charge within the range of the usage limit.

[0405] When the recharge amount exceeds the usage limit, the payment system 1 of Modifications 4-6 makes a recharge inquiry to the user regarding whether to execute the recharge within the range of the usage limit. The payment system 1 executes the recharge within the range of the usage limit based on the response to the recharge inquiry. As a result, the user can instruct the execution of the recharge within the range of the usage limit according to the recharge inquiry, so that the payment system 1 can execute flexible processing and effectively improve the convenience for the user.

[0406] [Modification 4-7] For example, a screen showing the usage history may be displayed on the user terminal 30. The payment system 1 of Modification 4-7 includes a display control unit 101 and a usage history information acquisition unit 121. The usage history information acquisition unit 121 acquires usage history information regarding the usage history on the user terminal 30. The usage history information is usage information stored in the payment data...

Claims

1. A setting screen that receives a designation of a setting related to installment payment, recurring payment, or bonus payment of payment means available on a user terminal, and as the setting screen that receives the designation of the setting in the payment of the price of a product or service provided by a store where the payment means is available, a display control unit that causes the user terminal to display a code screen including a code related to the payment of the price, A processing execution unit that executes processing related to the installment payment, the recurring payment, or the bonus payment in the payment of the price based on the setting designated on the code screen when the code on the code screen is read by the store, A payment system including the above.

2. The display control unit, Causes the user terminal to display the code screen that receives a first operation for starting the setting, When the first operation is performed on the code screen, causes the user terminal to display a user interface that receives a second operation for designating details of the setting so as to overlap the code screen, The processing execution unit executes the processing in the payment of the price based on the details of the setting designated by the second operation. The payment system according to claim 1.

3. The payment system, A store information acquisition unit that acquires store information about the store before the payment of the price is made, A first correspondence determination unit that determines whether the store corresponds to the installment payment, the recurring payment, or the bonus payment based on the store information, Further includes, The display control unit causes the user terminal to display the setting screen based on the determination result of the first correspondence determination unit. The payment system according to claim 1 or 2.

4. The display control unit causes the user terminal to display the setting screen that receives the designation of the setting in the charge in which the payment means is used, The processing execution unit executes the processing in the charge based on the setting. The payment system according to claim 1 or 2.

5. The display control unit causes the user terminal to display a charge screen that receives a designation of charge conditions related to the charge as the setting screen, The processing execution unit executes the processing in the charge based on the charge conditions and the setting designated on the charge screen. The payment system according to claim 4.

6. The display control unit, Cause the user terminal to display the charging screen for receiving a third operation to start the setting. When the third operation is performed on the charging screen, cause the user terminal to display a user interface for receiving a fourth operation to specify details of the setting so as to be superimposed on the charging screen. The processing execution unit executes the processing in the charging based on the details of the setting specified by the fourth operation. The settlement system according to claim 5.

7. The display control unit causes the setting screen to display the content of the setting in association with settlement means information regarding the settlement means. The settlement system according to claim 1 or 2.

8. The display control unit causes the user terminal to display a usage settlement means screen as the setting screen for receiving a designation of a usage settlement means that is the settlement means used in the user terminal from among a plurality of settlement means available in the user terminal. The processing execution unit executes the processing based on the usage settlement means specified on the usage settlement means screen and the setting. The settlement system according to claim 1 or 2.

9. The settlement system further includes a second correspondence determination unit that determines whether the settlement means corresponds to installment payment, recurring payment, or bonus payment in the user terminal. The display control unit causes the user terminal to display the setting screen based on the determination result of the second correspondence determination unit. The settlement system according to claim 1 or 2.

10. The settlement system further includes a usage condition determination unit that determines whether usage conditions regarding installment payment, recurring payment, or bonus payment in the user terminal are satisfied. The display control unit causes the user terminal to display the setting screen based on the determination result of the usage condition determination unit. The settlement system according to claim 1 or 2.

11. The display control unit is capable of causing the user terminal to display the setting screen corresponding to each of a plurality of settlement methods available in the user terminal, and causes the user terminal to display the setting screen corresponding to another settlement method such that the setting specified on the setting screen corresponding to one settlement method among the plurality of settlement methods is carried over to the setting screen corresponding to the other settlement method. The processing execution unit executes the processing in the payment method based on the setting specified on the setting screen corresponding to each of the plurality of payment methods. The payment system according to claim 1 or 2.

12. The payment system further includes a simulation execution unit that executes a simulation regarding the installment payment, the recurring payment, or the bonus payment. The display control unit causes the setting screen to be displayed on the user terminal based on the execution result of the simulation. The payment system according to claim 1 or 2.

13. A computer A display control step of causing a code screen including a code related to the payment to be displayed on the user terminal, the code screen being a setting screen for receiving a specification of a setting regarding installment payment, recurring payment, or bonus payment of a payment means available on the user terminal and for receiving the specification of the setting in the payment of the price of a product or service provided by a store where the payment means is available. A processing execution step of executing processing related to the installment payment, the recurring payment, or the bonus payment in the payment of the price based on the setting specified on the code screen when the code on the code screen is read by the store. A payment method for executing.

14. A display control unit for causing a code screen including a code related to the payment to be displayed on the user terminal, the code screen being a setting screen for receiving a specification of a setting regarding installment payment, recurring payment, or bonus payment of a payment means available on the user terminal and for receiving the specification of the setting in the payment of the price of a product or service provided by a store where the payment means is available. A processing execution unit for executing processing related to the installment payment, the recurring payment, or the bonus payment in the payment of the price based on the setting specified on the code screen when the code on the code screen is read by the store. A program for causing a computer to function as.

Images