Proposed system, proposed method, and program

Abstract

Improve user convenience. A determination unit (102, 201) of a proposal system (1) determines whether a proposal condition is satisfied for proposing a functional screen for providing a proposed function among a plurality of functions possessed by a payment app stored in a user terminal (20). If it is determined that the proposal condition is satisfied, a proposal unit (103, 202) proposes the functional screen in the payment app.

Description

[Technical Field]

[0001] The present disclosure relates to a proposal system, a proposal method, and a program. [Background technology]

[0002] Conventionally, payment apps that allow users to use multiple functions are known. For example, Patent Document 1 describes a technology in which, based on a program (a type of payment app) stored in an information processing device such as a smartphone, the information processing device displays a screen for selecting payment methods that can be used in stores located within a predetermined range from the current location of the information processing device, and payment is executed by reading the information processing device with a terminal in the store. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Publication No. 2020-021218 Summary of the Invention [Problem to be solved by the invention]

[0004] However, with the technology of Patent Document 1, even if at least one of a plurality of payment methods available to the user is automatically selected, the functions of the payment app are not suggested to the user, and the user is therefore unable to fully understand the functions of the payment app. For this reason, the technology of Patent Document 1 does not sufficiently improve user convenience. This point is not limited to the technology of Patent Document 1, but can be said to be true of conventional payment apps in general.

[0005] One of the purposes of the present disclosure is to improve user convenience. [Means for solving the problem]

[0006] The proposal system of the present disclosure includes a determination unit that determines whether or not proposal conditions regarding the proposal of a functional screen for providing a function to be proposed among multiple functions possessed by a payment app stored in a user terminal are met, and a proposal unit that proposes the functional screen in the payment app when it is determined that the proposal conditions are met. [Effects of the Invention]

[0007] The present disclosure can improve convenience for users. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 2 is a diagram illustrating an example of a hardware configuration of a proposed system. [Figure 2] FIG. 10 is a diagram showing an example of a screen displayed on a user terminal when the user terminal is connectable to a network. [Figure 3] FIG. 10 is a diagram illustrating an example of a screen displayed on a user terminal when the user terminal cannot connect to a network. [Figure 4] FIG. 1 is a diagram illustrating an example of functions realized by the proposed system. [Figure 5] FIG. 10 is a diagram illustrating an example of a payment database. [Figure 6] FIG. 10 is a diagram illustrating an example of a point database. [Figure 7] FIG. 10 is a diagram illustrating an example of processing executed in the proposed system. [Figure 8] FIG. 10 is a diagram illustrating an example of a function realized in a modified example. [Figure 9] FIG. 10 is a diagram showing an example of a screen displayed on a user terminal according to the first modification. [Figure 10] FIG. 13 is a diagram showing an example of a screen displayed on a user terminal in Modification 4. [Figure 11] FIG. 13 is a diagram showing an example of a screen displayed on a user terminal in Modification 5. [Figure 12] FIG. 20 is a diagram showing an example of a screen displayed on a user terminal in Modification 6. [Figure 13]FIG. 20 is a diagram showing an example of a screen displayed on a user terminal in Modification 7. [Figure 14] FIG. 20 is a diagram showing an example of a screen displayed on a user terminal in Modification 9. [Figure 15] FIG. 23 is a diagram showing an example of a screen displayed on a user terminal in Modification 14. DETAILED DESCRIPTION OF THE INVENTION

[0009] [1. Hardware configuration of the proposed system] An example of an embodiment of a proposed system, a proposed method, and a program according to the present disclosure will be described. FIG. 1 is a diagram showing an example of the hardware configuration of the proposed system. For example, the proposed system 1 includes a payment server 10 and a user terminal 20. Each of the payment server 10 and the user terminal 20 is connected to a network N such as the Internet or a LAN. Note that there may be multiple payment servers 10 and multiple user terminals 20.

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

[0011] The user terminal 20 is a user's computer. For example, the user terminal 20 is a smartphone, a tablet, a personal computer, or a wearable terminal. The user terminal 20 includes a control unit 21, a memory unit 22, a communication unit 23, an operation unit 24, and a display unit 25. The hardware configurations of the control unit 21, the memory unit 22, and the communication unit 23 may be similar to those of the control unit 11, the memory unit 12, and the communication unit 13, respectively. The operation unit 24 is an input device such as a touch panel or a mouse. The display unit 25 is a display such as a liquid crystal or organic EL display.

[0012] The program stored in the storage units 12, 22 may be supplied to the payment server 10 or the user terminal 20 via the network N. Also, at least one of a reading unit (e.g., a memory card slot) that reads a computer-readable information storage medium and an input / output unit (e.g., a USB port) that inputs and outputs data to and from an external device may be included in the payment server 10 or the user terminal 20. For example, a program stored in an information storage medium may be supplied to the payment server 10 or the user terminal 20 via at least one of the reading unit and the input / output unit.

[0013] Furthermore, the proposed system 1 may include at least one computer. The computer included in the proposed system 1 is not limited to the example of FIG. 1. For example, the proposed system 1 may include only the user terminal 20. In this case, the payment server 10 exists outside the proposed system 1. The proposed system 1 may include only the payment server 10. In this case, the user terminal 20 exists outside the proposed system 1. The proposed system 1 may include the payment server 10 and other computers not shown in FIG. 1 (for example, a server computer for a point service described below).

[0014] [2. Overview of the proposed system] In this embodiment, an example is taken of a case where a user uses a payment service from a payment app stored in user terminal 20. The payment app is an application provided by the administrator of the payment service. The user can use any payment method with the payment service. For example, the user may use electronic money, a balance not called electronic money, a credit card, a card other than a credit card, points, a bank account, an account other than a bank account, cryptocurrency, a wallet, or other payment methods with the payment service. A payment method can also be called a payment means, as it can be used for making payments.

[0015] For example, a user installs a payment app on user terminal 20 and registers as a member of a payment service. Once the user has completed the membership registration for the payment service, the user can start the payment app on user terminal 20 and use the payment service. Note that the user may also use the payment service from a browser or from an app other than the payment app stored in user terminal 20 (for example, an app provided by a credit card company or other non-payment app).

[0016] FIG. 2 is a diagram showing an example of a screen displayed on user terminal 20 when user terminal 20 is connectable to network N. For example, when a user performs an operation to start user terminal 20 from operation unit 24, user terminal 20 causes display unit 25 to display menu screen SC1 of user terminal 20. Menu screen SC1 displays icon I10 of a payment app stored in user terminal 20. Menu screen SC1 also displays icons of applications other than the payment app. For example, menu screen SC1 also displays icon I11 of an e-commerce app, which is an application for an e-commerce service.

[0017] For example, when a user selects icon I10 to launch the payment app, the payment app communicates with the payment server 10 and displays a home screen SC2 of the payment app on the display unit 25, as shown in the upper right of FIG. 2. The home screen SC2 is a screen that is displayed immediately after the payment app is launched. The home screen SC2 is sometimes called a first view. After transitioning to another screen of the payment app, the user can cause the home screen SC2 to be displayed on the display unit 25 by performing an operation to return to the home screen SC2.

[0018] In the example at the top right of FIG. 2, the home screen SC2 includes a payment code C20 generated based on a payment code ID that can identify the user in the payment service. The payment code C20 is a code for payment. In the example at the top right of FIG. 2, the payment code C20 includes a barcode and a two-dimensional code, but the payment code C20 may be either a barcode or a two-dimensional code. The process of generating the payment code C20 from the payment code ID may be executed by either the payment server 10 or the user terminal 20. The user makes a payment by having a terminal at a store affiliated with the payment service read the payment code C20.

[0019] It should be noted that payment in the payment service may be performed by a method other than having a store terminal read the payment code C20. For example, payment may be performed by reading a code displayed on a store terminal with the user terminal 20, by reading a code posted in the store with the user terminal 20, by completing payment only by operating the user terminal 20, by using an IC chip in the user terminal 20, online payment (e.g., account payment using the user's account or ID payment using the user's ID), carrier payment which is payment by the carrier used by the user terminal 20, or by other methods. Alternatively, for example, payment may be performed by having the user read a code on a bill with the user terminal 20 and pay the bill.

[0020] In this embodiment, an example is given in which a payment app has multiple functions related to payment services. A function is a program or part of a program that indicates information processing for providing a payment service to a user. A payment app is a collection of programs that are each of multiple functions. The programs can also be said to be small programs that make up the payment app. A function may also be data that is referenced or updated by the program. For example, a payment app has a payment function, a money transfer function, and a points function.

[0021] The payment function is a function that executes payment based on the user's payment method. In this embodiment, an example is given in which payment is executed based on the payment method specified by the user. For example, the payment function is a function that executes payment for the price of goods or services sold by a store based on the payment method specified by the user as the payment source. In the example in the upper right of Figure 2, the electronic money "AAA Cash" is specified as the payment source, so the payment function is a function that executes payment based on the electronic money "AAA Cash". The payment function may be similar to the function of a known payment service.

[0022] The remittance function is a function for sending all or part of the balance of a payment method between users. In this embodiment, the electronic money "AAA Cash" corresponds to the remittance function. For example, the remittance function is a function for sending electronic money "AAA Cash" in an amount specified by the user to another user specified by the user. The remittance function may also be a function for a user to receive electronic money "AAA Cash" in an amount specified by another user. The remittance function may be similar to the functions of known payment services.

[0023] The point function is a function for providing a point service to users. The point service is a service for managing points held by users. The point service is linked to a payment service. The point service may be one of the payment services. The point function is a function for providing a point service to users from a payment app. Users can earn and spend points using the point function. The point function may be similar to the function of a known point service. Users can also make payments using points, so the point function is also a type of payment function.

[0024] In this embodiment, the user can switch functions on the home screen SC2 by selecting tab T21. In the example at the top right of FIG. 2, the "Code Payment" tab T21 is selected, so the payment function for making a payment with payment code C20 is selected. For example, when the user selects "Charge / Send" tab T21, the payment app switches the display of the home screen SC2 so that the user can use the remittance function, as shown at the bottom left of FIG. 2. The home screen SC2 for the remittance function includes a button B22 for charging and a button B23 for sending money to another user.

[0025] For example, when a user selects "Point Card" on tab T21, the payment app switches the display of home screen SC2 so that the user can use the point function, as shown in the lower right of FIG. 2. The payment app communicates with payment server 10 or the server computer of the point service, and displays a point code C24 generated based on a point code ID that can identify the user in the point service on home screen SC2. The point code C24 can also be considered an electronic point card. By reading the point code C24 at a store terminal, the user can earn points according to the payment amount.

[0026] In the example at the bottom right of Fig. 2, the point code C24 is a barcode, but the point code C24 may be a two-dimensional code, or may include a barcode and a two-dimensional code. The process of generating the point code C24 from the point code ID may be executed by either the payment server 10 or the user terminal 20. If a server computer of a point service exists separately from the payment server 10, this process may be executed by the server computer of the point service. The process of issuing the point code ID may also be executed by the server computer of the point service.

[0027] Furthermore, in this embodiment, an example is given in which the payment code ID and the point code ID are separate, but the payment code ID and the point code ID may be the same. That is, a user may be identified by a code ID common to the payment service and the point service. In other words, the payment code C20 and the point code C24 may be the same, rather than separate. A common code may be used for each of the payment service and the point service. In this case, the payment function and the point function are provided on the home screen SC2 of the same tab T21.

[0028] In this embodiment, the payment app proposes a screen for a specific function to the user depending on the communication status of the payment app. For example, when the user terminal 20 is in airplane mode, the payment app is offline and cannot connect to the network N, so cannot communicate with other computers. In this case, the payment app proposes a screen for an offline function, which is a function that can be used even offline, to the user. The payment app has an online function, which is a function that can only be used online, and an offline function. The offline function may be a function that can be used only when offline, or a function that can be used both online and offline.

[0029] FIG. 3 is a diagram showing an example of a screen displayed on the user terminal 20 when the user terminal 20 cannot connect to the network N. For example, when the user terminal 20 is in airplane mode, an icon indicating airplane mode is displayed in the upper right corner of the menu screen SC1, as shown in the upper left of FIG. 3. In this state, when the user selects icon I10, the payment app is launched. Because the payment app is in airplane mode, it cannot communicate with the payment server 10. In this case, as shown in the upper right of FIG. 3, the payment app displays a window W25 on the home screen SC2 to suggest a points function, which is an example of an offline function.

[0030] In this embodiment, the payment app stores the offline point code ID before the payment app goes offline. Therefore, the payment app can display the point code C24 even when offline. When the payment app is offline, the user can use the point function based on the offline point code ID. On the other hand, the payment function and money transfer function are online functions. When the payment app is offline, the user cannot use the payment function and money transfer function.

[0031] For example, when the user selects button B250 indicating that he or she wishes to use the point function proposed in window W25, the payment app displays a home screen SC2 for the point function on display unit 25, as shown in the lower left of FIG. 3. For example, the payment app displays a point code C24 generated based on an offline point code ID on home screen SC2 for the point function. Tab T21 is set to "Point Card." When the user reads point code C24 at a store terminal, the user can make a payment using points even if the payment app is offline.

[0032] When the user selects button B251 in the upper right state of Fig. 3, the payment app displays the home screen SC2 of the payment function on the display unit 25. However, because the payment app is offline, the payment code C20 is not displayed on the home screen SC2 of the payment function. Even if the user selects the tab T21 of the money transfer function, a message indicating that the user cannot use the money transfer function is displayed on the home screen SC2 of the money transfer function.

[0033] As described above, the proposed system 1 of this embodiment displays a window W25 on the display unit 25 proposing a home screen SC2 of the points function that can be used offline when the communication status of the payment app is offline. The window W25 allows the user to understand that the points function can be used offline. By selecting the button B250, the user can display the home screen SC2 of the points function without selecting the points function of the tab T21. This allows the proposed system 1 to improve user convenience. Details of the proposed system 1 will be described below.

[0034] [3. Functions realized by the proposed system] 4 is a diagram showing an example of functions realized by the proposed system 1. The units realized by the proposed system 1 of this embodiment can be configured by consolidating them into one device or by distributing the devices into smaller units.

[0035] [3-1. Functions realized by the payment server] For example, the payment server 10 includes a data storage unit 100 and a function providing unit 101. The data storage unit 100 is realized by the storage unit 12. The function providing unit 101 is realized by the control unit 11.

[0036] [Data storage section] The data storage unit 100 stores various data related to the payment service. For example, the data storage unit 100 stores a payment database DB1 and a point database DB2.

[0037] FIG. 5 is a diagram showing an example of payment database DB1. Payment database DB1 is a database that stores various information related to payment services. For example, payment database DB1 stores user ID, login account, password, payment code ID, expiration date, payment method information, payment source information, and charging source information. The information stored in payment database DB1 is not limited to the example of FIG. 5. Other information may also be stored in payment database DB1. For example, payment database DB1 may store other information such as history information and operation information, which will be described in a modified example below.

[0038] A user ID is an example of user identification information that can identify a user. A login account is also an example of user identification information. A login account is user identification information that a user enters to log in to a payment service. The login account may be freely changeable by the user. A user ID is user identification information that is managed separately from the login account. In this embodiment, an example is given of a case where a login account exists in addition to a user ID (where there are at least two pieces of user identification information), but there may be only one piece of user identification information. In other words, the user ID and the login account do not need to be separate. A password is authentication information that is confirmed when logging in.

[0039] The payment code ID is also an ID that can identify a user, and is therefore an example of user identification information. In this embodiment, a case where the payment server 10 issues a payment code ID will be taken as an example. For example, when issuing a payment code ID for a certain user, the payment server 10 issues a new payment code ID so that it does not overlap with other payment code IDs. The payment server 10 associates the new payment code ID and expiration date with the user ID and login account of the user and stores the new payment code ID and expiration date in the payment database DB1. The expiration date may be determined by any method. For example, the expiration date may be a predetermined time after the issuance of the payment code ID.

[0040] The payment code ID may be issued at any timing. For example, the payment server 10 may issue the payment code ID when the payment app is launched, when the expiration date has passed, when the user instructs issuance of the payment code ID, or at other timing. The payment code ID may be issued not by the payment server 10 but by another computer (for example, a server computer that performs authentication at the time of payment). The payment code ID may not have an expiration date. For example, the payment code ID may be a semi-permanently valid ID with no particular expiration date.

[0041] Payment method information is information that can identify a payment method. For example, payment method information is information such as a credit card number, information such as an electronic money number and balance, information such as a bank account and balance, or information such as a point card number. Payment source information is information that can identify a payment method selected as a payment source. A payment source is a payment method used to pay for goods or services handled by a store. Charge source information is information that can identify a payment method selected as a charge source. A charge source is a payment method that serves as the source of funds for charging. Charges can be made to any payment method, such as electronic money. For example, a user can instruct a charge from a payment app.

[0042] FIG. 6 is a diagram showing an example of the point database DB2. The point database DB2 is a database that stores various information related to the point service. For example, the point database DB2 stores a user ID, an online point code ID, an expiration date, an offline point code ID, and the number of points held by the user. The information stored in the point database DB2 is not limited to the example of FIG. 6. Other information may also be stored in the point database DB2. For example, the point database DB2 may store a login account and password for a user to log in to the point service.

[0043] In this embodiment, the case where the user ID for the payment service and the user ID for the point service are the same (where a common user ID is used for the payment service and the point service) is taken as an example, but the user ID for the payment service and the user ID for the point service may be different from each other. When the user ID for the payment service and the user ID for the point service are different from each other, a database showing the correspondence between them is stored in the data storage unit 100. The database may be stored in a computer or information storage medium other than the payment server 10.

[0044] The point code ID is an ID that can identify a user, and is therefore an example of user identification information. In this embodiment, an example is taken of a case where the payment server 10 issues a point code ID. For example, when issuing a point code ID for a certain user, the payment server 10 issues a new point code ID so that it does not overlap with other point code IDs. The payment server 10 associates the new point code ID with the user ID of the user and stores the new point code ID and expiration date in the payment database DB1. The expiration date may be determined by any method. For example, the expiration date may be a predetermined time after the issuance of the point code ID.

[0045] The point code ID may be issued at any timing. For example, the payment server 10 may issue the point code ID when the payment app is started, when the expiration date has passed, when the user instructs the issuance of a point code ID, or at other timing. The point code ID may be issued not by the payment server 10 but by another computer (for example, a computer for a point service). An expiration date may not be set for the point code ID. For example, the point code ID may be a semi-permanently valid ID with no particular expiration date set.

[0046] In this embodiment, an online point code ID and an offline point code ID are stored in the point database DB2. When the communication status of the payment app is online, a point code C24 generated based on the online point code ID is displayed on the home screen SC2, and the online point code ID stored in the point database DB2 is checked. When the communication status of the payment app is offline, a point code C24 generated based on the offline point code ID is displayed on the home screen SC2, and the offline point code ID stored in the point database DB2 is checked.

[0047] The number of points can also be said to be the balance of points held by the user. When points are awarded to a user, the number of points increases. When a user pays with points, the number of points decreases. The flow for a user to use points may be the same as the flow in known point services. When a physical point card is used in addition to a payment app, a point card number that can identify the physical point card may be associated with the number of points and stored in the point database DB2.

[0048] The data stored in the data storage unit 100 is not limited to the above examples. The data storage unit 100 may store various data for at least one of the payment service and the point service. For example, the data storage unit 100 may store data necessary for displaying the home screen SC2 or another screen. The data storage unit 100 may store a program that indicates processing on the payment server 10 side for allowing the user to use each of the multiple functions of the payment app. The data storage unit 100 may store data indicating the correspondence between the proposal conditions described below and the functional screens. This data may identify which functional screen should be proposed when which proposal condition is satisfied.

[0049] [Function provision department] The function providing unit 101 executes processing on the payment server 10 side to provide the user with multiple functions of the payment app. For example, when a user uses the payment function, the function providing unit 101 generates a payment code ID and sends it to the payment app upon receiving a request to generate a payment code ID from the payment app. When a payment is made by reading the payment code C20 at a store terminal, the function providing unit 101 communicates with the store terminal and obtains the payment code ID acquired from the payment code C20. The function providing unit 101 executes the payment based on payment source information associated with the payment code ID, based on the payment database DB1. When another type of payment is made, the function providing unit 101 may execute the payment by communicating with the store terminal, the payment app, or another computer. When a user uses the money transfer function, the function providing unit 101 executes the payment by receiving a request to transfer or charge from the payment app, and executes the transfer to another user designated by the user, or the charge based on the charge amount designated by the user.

[0050] For example, when a user uses a point function, if the communication status of the payment app is online, the function providing unit 101 receives a request to generate a point code ID from the payment app. The function providing unit 101 generates an online point code ID and sends it to the payment app. When the online point code C24 is read by a store terminal, the function providing unit 101 communicates with the store terminal and acquires the online point code ID acquired from the online point code C24. Based on the point database DB2, the function providing unit 101 executes a process to use points within the range of the number of points associated with the online point code ID, or executes a process to increase the points associated with the online point code ID.

[0051] For example, the function providing unit 101 transmits an offline point code ID to the payment app at some timing when communication with the payment app is established. The payment app stores the offline point code ID. In this embodiment, an example is given in which no expiration date is set for the offline point code ID, but an expiration date may also be set for the offline point code ID. The flow after the point code C24 is read by the store terminal is the same as the flow after the online point code C24 is read. Even when the user uses other functions, the function providing unit 101 only needs to execute processing on the payment server 10 side.

[0052] [3-2. Functions implemented on user devices] For example, the user terminal 20 includes a data storage unit 200, a determination unit 201, and a proposal unit 202. The data storage unit 200 is realized by the storage unit 22. The determination unit 201 and the proposal unit 202 are each realized by the control unit 21.

[0053] [Data storage section] The data storage unit 200 stores data necessary for a user to use at least one of a payment service and a point service. For example, the data storage unit 200 stores a payment app. When a user uses a payment service from another app or browser rather than the payment app, the data storage unit 200 stores the other app or browser. The data storage unit 200 may store a payment code ID, an online point code ID, an offline point code ID, or other information. The data storage unit 200 may store data indicating a correspondence between proposal conditions and functional screens, which will be described later. This data may identify which functional screen should be proposed when which proposal condition is met.

[0054] [Judgment section] The determination unit 201 determines whether or not a proposal condition is satisfied for proposing a function screen for providing a proposed function among multiple functions possessed by the payment app stored in the user terminal 20. The proposed function is at least one of the multiple functions. In this embodiment, a point function is used as an example of the proposed function, but the proposed function may be another function. For example, the proposed function may be a payment function, a money transfer function, or another function.

[0055] The function screen is a screen for providing the user with one of a plurality of functions. In other words, the function screen is a screen corresponding to the user interface of one of the plurality of functions. In this embodiment, since the point function is proposed, the home screen SC2 of the point function (home screen SC2 with the "Point Card" tab T21 of the point function selected) corresponds to the function screen. When the payment function is proposed, the home screen SC2 of the payment function (home screen SC2 with the "Code Payment" tab T21 of the payment function selected) corresponds to the function screen. When the money transfer function is proposed, the home screen SC2 of the money transfer function (home screen SC2 with the "Charge / Send" tab T21 of the money transfer function selected) corresponds to the function screen.

[0056] Note that the function screens are not limited to the home screen SC2 of the payment function, the home screen SC2 of the remittance function, and the home screen SC2 of the point function. If at least one of the payment function, the remittance function, and the point function is provided on a screen other than the home screen SC2, the other screen may correspond to the function screen. For example, if the tab T21 is not switched, there may be a screen dedicated to the payment function, a screen dedicated to the remittance function, and a screen dedicated to the point function. In this case, these dedicated screens correspond to the function screens.

[0057] Furthermore, when functions other than the payment function, remittance function, and point function are proposed, the screens for the other functions correspond to the function screens. Furthermore, a certain function may include multiple detailed functions. For example, one payment function may have a credit card function and an electronic money function. In this case, the screen for credit card payment or the screen for electronic money payment corresponds to the function screen. In this embodiment, an example is given in which electronic money charging is performed within the remittance function, but the charging function may be a function separate from the remittance function. In this case, the screen for performing charging corresponds to the function screen.

[0058] For example, if a payment app has a coupon function for managing coupons, a screen for managing coupons corresponds to a functional screen. If a payment app has a setting function for accepting user settings, a screen for accepting user settings designations corresponds to a functional screen. This screen may be a screen for accepting settings for a screen to be displayed immediately after the payment app is launched (in the examples of Figures 2 and 3, the setting of tab T21 selected by default). If a payment app has an authentication function for authentication in a payment service, a screen for performing authentication corresponds to a functional screen. If a payment app has other functions, a screen for providing the user with other functions may correspond to a functional screen.

[0059] The proposal condition is a condition that serves as a criterion for determining whether or not to propose a functional screen to the user. The proposal condition can also be referred to as a trigger for proposing a functional screen to the user. The proposal condition may be any condition associated with the function to be proposed. In this embodiment, an example is given in which the communication status of the payment app corresponds to the proposal condition. However, as in a modified example described below, the proposal condition may also correspond to a condition determined based on other elements such as history information. The determination unit 201 can determine these various proposal conditions. In this embodiment, the proposal condition is determined on the payment app side, and therefore data indicating the proposal condition is included in the payment app. For example, the proposal condition may be defined as part of the program code in the payment app, or may be defined in data referenced by the program code in the payment app.

[0060] For example, the function screen may be a status function screen for providing functions that can be used by the user when the payment app is in a predetermined status among multiple functions. The status of the payment app is the hardware status of the user terminal 20 in which the payment app is stored, or the software status within the payment app. The predetermined status is a status in which it is determined that the proposal condition is met. In other words, the predetermined status is a status that serves as a condition (trigger) for proposing the function to be proposed. The status function screen is a screen for functions that are provided on the condition that the payment app is in a predetermined status, or a screen for functions that can be provided even if the payment app is in a predetermined status.

[0061] In this embodiment, the communication status of the payment app corresponds to the status of the payment app, but the status of the payment app may be other statuses than the communication status of the payment app. For example, the status of the payment app may be the CPU usage rate of the payment app, the memory consumption by the payment app, the CPU usage rate of the entire user terminal 20, the memory consumption of the entire user terminal 20, the location of the user terminal 20, the time period when the payment app was launched, or other statuses.

[0062] For example, when the status function screen corresponds to the function screen, the determination unit 201 determines whether the proposal condition is satisfied by determining whether the payment app is in a predetermined situation. If the determination unit 201 determines that the payment app is not in the predetermined situation, it does not determine that the proposal condition is satisfied, and if it determines that the payment app is in the predetermined situation, it determines that the proposal condition is satisfied. The determination unit 201 acquires current situation information that indicates the current situation of the payment app, and determines whether the current situation information indicates the predetermined situation, thereby determining whether the payment app is in the predetermined situation.

[0063] The method of determining whether the status of the payment app is a communication status will be described later. For example, when the CPU usage rate or memory consumption corresponds to the status of the payment app, the determination unit 201 may acquire the CPU usage rate or memory consumption rate of the payment app based on a known method such as a benchmark test, and determine whether the CPU usage rate or memory consumption rate is in a predetermined status, thereby determining whether the payment app is in a predetermined status.

[0064] For example, when the location of user terminal 20 corresponds to the status of the payment app, determination unit 201 may acquire location information using a GPS receiver, communication unit 23, etc. of user terminal 20, and determine whether the location indicated by the location information is a predetermined location, thereby determining whether the payment app is in a predetermined status. When the time zone when the payment app is launched corresponds to the status of the payment app, determination unit 201 may acquire the current date and time when the payment app is launched, and determine whether the current date and time is in a predetermined time zone, thereby determining whether the payment app is in a predetermined status. Similarly, when the status of the payment app is another status, determination unit 201 may determine whether the payment app is in a predetermined status using a determination method according to the other status.

[0065] For example, the status function screen may be a communication status function screen for providing functions that are available to the user when the communication status of the payment app is a predetermined communication status among multiple functions. The communication status refers to the availability or quality of communication. For example, the communication status may be whether the device is offline, the communication speed, the signal strength, the amount of communication, or other conditions. The predetermined communication status is a situation in which it is determined that the proposal conditions are met. In other words, the predetermined communication status is a communication status that triggers the proposal of the function to be proposed. The communication status function screen is a screen for functions that are provided on the condition that the communication status of the payment app is a predetermined communication status, or a screen for functions that can be provided even if the communication status of the payment app is a predetermined communication status.

[0066] In this embodiment, the case where the predetermined communication status is offline is taken as an example, but the predetermined communication status may be a communication speed below a threshold, a radio wave strength below a threshold, a communication volume above a threshold, an inability to communicate due to an error on the payment server 10 side, or other statuses. The determination unit 201 determines whether the communication status of the payment app is a predetermined communication status by determining whether or not the communication status of the payment app is a predetermined communication status. For example, if the determination unit 201 determines that the communication status of the payment app is not a predetermined communication status, it determines that the payment app is not in a predetermined status, and if the determination unit 201 determines that the communication status of the payment app is a predetermined communication status, it determines that the payment app is in a predetermined status.

[0067] A method for determining whether the predetermined communication status is offline will be described later. For example, if the predetermined communication status corresponds to a communication speed below a threshold, the determination unit 201 may acquire a current communication speed based on a known method and determine whether the current communication speed is below the threshold, thereby determining whether the communication status of the payment app corresponds to the predetermined communication status. If the predetermined communication status corresponds to radio wave strength below a threshold, the determination unit 201 may acquire a current radio wave strength based on a known method and determine whether the current radio wave strength is below the threshold, thereby determining whether the communication status of the payment app corresponds to the predetermined communication status. If the predetermined communication status corresponds to a communication volume equal to or greater than a threshold, the determination unit 201 may acquire a current communication volume based on a known method and determine whether the current communication volume is equal to or greater than a threshold, thereby determining whether the communication volume of the payment app corresponds to the predetermined communication status.

[0068] In this embodiment, the communication status function screen is an offline function screen for providing, among multiple functions, functions that the user can use when the communication status of the payment app is offline. Offline is a state in which the payment app cannot communicate with other devices. In other words, offline is a state in which the user terminal 20 cannot communicate with other devices. For example, offline means that the user terminal 20 is in airplane mode, the user terminal 20 is out of range, the user terminal 20 is not connected to a communication device such as a wireless LAN access point, the communication function of the communication unit 23 is stopped, the payment app is unable to communicate with the payment server 10 (a state in which the payment app does not receive any response from the payment server 10) continues for a predetermined time or more, or other states.

[0069] For example, the determination unit 201 determines whether the communication status of the payment app is a predetermined status by determining whether the communication status of the payment app is offline. If the determination unit 201 determines that the communication status of the payment app is not offline, it determines that the communication status of the payment app is not a predetermined status, and if the determination unit 201 determines that the communication status of the payment app is offline, it determines that the communication status of the payment app is a predetermined status. For example, the determination unit 201 may determine whether the communication status of the payment app is offline by determining whether the user terminal 20 is in airplane mode.

[0070] For example, the determination unit 201 may determine whether the communication status of the payment app is offline by determining whether the user terminal 20 is out of range. The determination unit 201 may determine whether the communication status of the payment app is offline by determining whether the user terminal 20 is connected to a communication device such as a wireless LAN access point. The determination unit 201 may determine whether the communication status of the payment app is offline by determining whether the communication function of the communication unit 23 is stopped. The determination unit 201 may determine whether the communication status of the payment app is offline by determining whether a state in which the payment app cannot communicate with the payment server 10 has continued for more than a predetermined time.

[0071] [Proposal Department] The suggestion unit 202 suggests a functional screen in the payment app when it is determined that the proposal condition is satisfied. That is, the suggestion unit 202 suggests a functional screen in the payment app when the proposal condition is satisfied (triggered). The suggestion unit 202 does not suggest a functional screen in the payment app when it is determined that the proposal condition is not satisfied. When there are multiple proposal conditions, the suggestion unit 202 suggests a functional screen of a function associated with a proposal condition that is determined to be satisfied by the determination unit 201 among the multiple proposal conditions.

[0072] Proposing a functional screen means displaying information proposing the functional screen on the payment app. In this embodiment, it is assumed that data necessary for displaying the information is stored in the data storage unit 200. For example, displaying a user interface part for displaying the functional screen (e.g., a window, a pop-up, a banner, a modal, a button, a panel, or other parts), a screen for transitioning to the functional screen, automatically transitioning to the functional screen, or notifying using the notification function of the payment app corresponds to proposing a functional screen. In the example in the upper right of FIG. 3, displaying window W25 corresponds to proposing a functional screen.

[0073] For example, the user may be allowed to set the tab T21 (default tab T21) to be selected when the payment app is launched. In this case, the suggestion unit 202 may suggest a specific function to the user by recommending the tab T21 of the specific function on a screen for the user to specify settings. Note that the suggestion by the suggestion unit 202 may be made at any timing. For example, the suggestion unit 202 may make the suggestion when the payment app is launched or at any timing while the payment app is launched.

[0074] For example, the suggestion unit 202 may suggest a status function screen in the payment app when it is determined that the payment app is in a predetermined situation. The suggestion unit 202 suggests a function screen in the payment app when the payment app is in a predetermined situation (trigger). The suggestion unit 202 does not suggest a function screen in the payment app when it is determined that the payment app is not in the predetermined situation.

[0075] For example, the suggestion unit 202 may suggest a communication status function screen in the payment app when it is determined that the communication status of the payment app is a predetermined communication status. The suggestion unit 202 suggests a function screen in the payment app when the communication status of the payment app is a predetermined communication status as a condition (trigger). The suggestion unit 202 does not suggest a function screen in the payment app when it is determined that the communication status of the payment app is not a predetermined communication status.

[0076] For example, when it is determined that the communication status of the payment app is offline, the suggestion unit 202 suggests an offline function screen in the payment app. The suggestion unit 202 suggests a function screen in the payment app when the communication status of the payment app is offline as a condition (trigger). When it is determined that the communication status of the payment app is not offline, the suggestion unit 202 does not suggest a function screen in the payment app. In this embodiment, since the user can use the points function even when the communication status of the payment app is offline, the suggestion unit 202 suggests the home screen SC2 of the points function as the offline function screen.

[0077] The offline function screen may be a screen for a function other than the point function. For example, if the user can use the electronic money payment function even when the communication status of the payment app is offline, the suggestion unit 202 may suggest a screen for the electronic money payment function as the offline function screen. For example, if the user can use multiple functions even when the communication status of the payment app is offline, the suggestion unit 202 may suggest a screen displaying only the multiple functions as the offline function screen. If a function is usable both online and offline, the function screen for the function displayed online may be different from the offline function screen for the function displayed offline. For example, if the point function is usable offline, the offline function screen for the point function may have less information than the function screen for the point function when online (for example, displaying only the point code C24, or displaying only information that is actually usable offline).

[0078] [4. Processing performed by the proposed system] Fig. 7 is a diagram showing an example of processing executed by the proposal system 1. Fig. 7 shows, among the processing executed by the proposal system 1, processing for making a proposal according to the determination result of the proposal conditions. The processing of Fig. 7 is executed by the control units 11 and 21 executing programs stored in the storage units 12 and 22, respectively. The steps of Fig. 7 are an example of a proposal method.

[0079] As shown in Fig. 7, when a user performs an operation to start up the user terminal 20 from the operation unit 24, the user terminal 20 displays the menu screen SC1 of the user terminal 20 on the display unit 25 (S1). When the user selects the icon I10, the user terminal 20 starts up the payment app (S2). The user terminal 20 determines whether the communication status of the payment app is offline, thereby determining whether the proposed conditions are met (S3). In S3, the user terminal 20 determines whether the proposed conditions are met by determining whether the current mode is airplane mode, etc.

[0080] If it is determined in S3 that the communication status of the payment app is not offline (S3: N), the user terminal 20 communicates with the payment server 10 and executes a process to display the home screen SC2 (S4), and this process ends. In S4, the home screen SC2 as shown in the upper right of FIG. 2 is displayed on the user terminal 20. If it is determined in S3 that the communication status of the payment app is offline (S3: Y), the user terminal 20 proposes the home screen SC2 of the points function by displaying a window W25 on the home screen SC2 without communicating with the payment server 10 (S5).

[0081] The user terminal 20 identifies the user's operation based on a signal from the operation unit 24 (S6). If the user selects button B250 in S6 (S6:B250), the user terminal 20 displays a home screen SC2 for the point function on the display unit 25 based on the offline point code ID (S7), and the process ends. If the user selects button B251 in S6 (S6:B251), the user terminal 20 displays a home screen SC2 for the payment function that does not include the payment code C20 on the display unit 25 (S8), and the process ends.

[0082] [5. Summary of embodiments] The proposal system 1 of this embodiment determines whether the proposal conditions are satisfied. If the proposal conditions are satisfied, the proposal system 1 proposes a function screen in the payment app. This allows the user to know the existence of a function to be proposed when the proposal conditions are satisfied, so the proposal system 1 can improve user convenience. For example, if the user did not know that the points function could be used even when the payment app's communication status was offline, the user can learn that the points function can be used by using window W25. The user can also display the home screen SC2 of the points function from window W25, so the proposal system 1 can improve user convenience.

[0083] Furthermore, the proposed system 1 determines whether the payment app is in a predetermined situation, thereby determining whether the proposed condition is met. If it is determined that the payment app is in the predetermined situation, the proposed system 1 proposes a status function screen in the payment app. This allows the user to know the existence of functions that can be used when the payment app is in the predetermined situation, thereby improving user convenience.

[0084] Furthermore, the proposed system 1 determines whether the payment app is in a predetermined state by determining whether the communication status of the payment app is a predetermined communication status. If the proposed system 1 determines that the communication status of the payment app is the predetermined communication status, it proposes a communication status function screen in the payment app. This allows the user to know the existence of functions that can be used when the communication status of the payment app is the predetermined communication status, thereby improving user convenience.

[0085] Furthermore, the proposed system 1 determines whether the communication status of the payment app is a predetermined status by determining whether the communication status of the payment app is offline. If the proposed system 1 determines that the communication status of the payment app is offline, it proposes an offline function screen in the payment app. This allows the user to know the existence of functions that can be used when the communication status of the payment app is offline, thereby improving user convenience.

[0086] [6. Modifications] The present disclosure is not limited to the above-described embodiments, and may be modified as appropriate without departing from the spirit of the present disclosure.

[0087] 8 is a diagram showing an example of functions realized in the modified example. For example, the payment server 10 includes a determination unit 102, a proposal unit 103, a history information acquisition unit 104, a location information acquisition unit 105, a facility estimation unit 106, a usage information acquisition unit 107, and an operation information acquisition unit 108. Each of the determination unit 102, the proposal unit 103, the history information acquisition unit 104, the location information acquisition unit 105, the facility estimation unit 106, the usage information acquisition unit 107, and the operation information acquisition unit 108 is realized by the control unit 11.

[0088] In the embodiment, an example has been given in which the process of determining the proposed conditions and the process of proposing a functional screen are each executed by the user terminal 20. In the modified example described below, an example has been given in which these processes are executed by the payment server 10, but in the modified example described below, these processes may also be executed by the user terminal 20. The process of determining the proposed conditions and the process of proposing a functional screen may be shared between the payment server 10 and the user terminal 20.

[0089] [6-1. Variation 1] For example, in the embodiment, the status of the payment app is the communication status, but the status of the payment app is not limited to the communication status. In Modification 1, the status of the payment app is the activation status of the payment app. In the embodiment, the status of the payment app is the activation status of the payment app when the user selects icon I10, but the payment app may be activated due to another app.

[0090] Hereinafter, a factor that launches a payment app is referred to as a launch source. For example, the launch source may be another app other than the payment app, a website, a link in a message such as an email or SMS, or a notification on the user terminal 20. In the first modification, an e-commerce app is used as the launch source, but the launch source may be anything and is not limited to an e-commerce app. For example, the launch source may be another payment app, a points service app, a travel reservation service app, a financial service app, a communication service app, the website of any of these services, a link in a message sent from any of these services, or a notification from any of these services.

[0091] The launch source is installed on the user terminal 20. The launch source is an app that links with the payment app. A known method may be used to launch the payment app from the launch source. For example, the payment app may be launched from the launch source by a method called deep linking. Multiple launch sources may be installed on the user terminal 20. The company that provides the launch source and the company that provides the payment app may be the same or different from each other.

[0092] Fig. 9 is a diagram showing an example of a screen displayed on the user terminal 20 of the first modified example. For example, when the user selects icon I11 in the state shown in the upper left of Fig. 9, the user terminal 20 starts the activation source and displays activation source screen SC3 on the display unit 25, as shown in the upper right of Fig. 9. The activation source screen SC3 displays an icon I30 that allows the user to select a payment function and an icon I31 that allows the user to select a point function. The icons I30 and I31 include information (e.g., a link) for starting the payment app.

[0093] For example, when a user selects icon I30, the payment app is launched, and as shown in the lower left of FIG. 9, the payment app displays the home screen SC2 of the payment function on the display unit 25. When a user selects icon I31, the payment app is launched, and as shown in the lower right of FIG. 9, the payment app displays the home screen SC2 of the point function on the display unit 25. In the example in the lower right of FIG. 9, displaying the home screen SC2 of the point function corresponds to suggesting a function screen. In Variation 1, a function screen is suggested depending on whether the payment app was launched due to the launch source.

[0094] In the example of FIG. 9, when the user selects icon I30, the home screen SC2 of the payment function is displayed; however, icon I30 does not have to be displayed on the launch source screen SC3. For example, when the user selects icon I31, if the user is logged in to the payment service, the home screen SC2 of the points function may be displayed. If the user is not logged in to the payment service or has not registered as a member, the home screen SC2 of the payment function may be displayed after logging in or registering as a member. If the payment app is not installed on the user terminal 20 or if the version of the payment app is old, a website for downloading or updating the payment app may be displayed on the user terminal 20.

[0095] In the first modification, the status function screen described in the embodiment is a launch source function screen for providing functions that can be used by the user when the payment app is launched due to a predetermined launch source. The launch source function screen is a screen for functions that are provided on the condition that the payment app is launched due to the launch source, or a screen for functions that can be provided even if the payment app is launched due to the launch source. In the example at the bottom left of FIG. 9, the home screen SC2 of the payment function corresponds to the status function screen. In the example at the bottom right of FIG. 9, the home screen SC2 of the point function corresponds to the status function screen. The status function screen may be a screen for functions other than the payment function and the point function.

[0096] The payment server 10 of the first modification includes a determination unit 102 and a proposal unit 103. The determination unit 102 determines whether the payment app is in a predetermined situation by determining whether the payment app has been launched due to a launch source. If it is determined that the payment app has not been launched due to a launch source, the determination unit 102 does not determine that the payment app is in the predetermined situation, and if it is determined that the payment app has been launched due to a launch source, the determination unit 102 determines that the payment app is in the predetermined situation.

[0097] For example, when a user performs an operation to start the payment app from the launch source (selection of icons I30 and I31 in the example of FIG. 9), the user terminal 20 transmits a launch notification indicating that the operation has been performed to the payment server 10. The launch notification may include information that can identify the launch source. The launch notification may also include information indicating what operation the user performed (for example, information indicating the function selected by the user).

[0098] For example, the determination unit 102 may determine whether the payment app is in a predetermined state by determining whether a startup notification has been received from the user terminal 20. The startup notification may be sent after the payment app is started or before the payment app is started. The startup notification is sent from the user terminal 20 to the payment server 10 on the condition that an operation to start the payment app has been performed from the startup source.

[0099] The suggestion unit 103 suggests a launch source function screen in the payment app when it is determined that the payment app has been launched due to the launch source. In the first modification, the suggestion unit 103 is realized by the payment server 10, and therefore the suggestion unit 103 suggests a launch source function screen by transmitting data for suggesting a launch source function screen to the user terminal 20. The user terminal 20 executes a process for suggesting the launch source function screen based on the data. In the first modification, the data storage unit 100 stores launch source data indicating the relationship between the launch source and the launch source function screen. When the determination unit 102 determines that the payment app has been launched due to the launch source, the suggestion unit 103 identifies which launch source function screen should be suggested based on the launch source data and suggests the launch source function screen.

[0100] The launch source data can also be considered data indicating the relationship between a suggestion condition and a launch source function screen that is proposed when the suggestion condition is satisfied. In the example of FIG. 9, the launch source data indicates the relationship between the operation that caused the launch source to launch the payment app (e.g., selection of icons I30 and I31) and the launch source function screen. The launch source data indicates that when icon I30 is selected and the payment app is launched, the home screen SC2 of the payment function should be proposed. The launch source data indicates that when icon I31 is selected and the payment app is launched, the home screen SC2 of the point function should be proposed.

[0101] In the example of FIG. 9 , the suggestion unit 103 proposes the home screen SC2 of the payment function or the home screen SC2 of the points function as the activation source function screen by transmitting display data for displaying these home screens SC2 to the user terminal 20. The display data may be data of the entire screen or data of a part of the screen. For example, the display data may be data in a markup language such as HTML, image data, text data, or other data.

[0102] For example, when a user selects icon I30 to launch the payment app from the launch source, the suggestion unit 103 sends display data to the user terminal 20 for displaying a home screen SC2 of the payment function as shown in the lower left of Fig. 9, thereby suggesting the home screen SC2 as the launch source function screen. When a user selects icon I31 to launch the payment app from the launch source, the suggestion unit 103 sends display data to the user terminal 20 for displaying a home screen SC2 of the point function as shown in the lower right of Fig. 9, thereby suggesting the home screen SC2 as the launch source function screen. The user terminal 20 displays the home screen SC2 of the payment function or the home screen SC2 of the point function based on the display data received from the payment server 10.

[0103] In addition, in the first modification, the determination unit 201 and the proposing unit 202 of the user terminal 20 may also execute the process of determining the proposed conditions and the process of proposing the activation source function screen. In this case, the determination unit 201 may determine whether the payment app has been activated due to the activation source by determining whether the user has performed an operation to activate the payment app from the activation source (selection of icons I30 and I31 in the example of FIG. 9). When it is determined that the payment app has been activated due to the activation source, the proposing unit 202 may communicate with the payment server 10 and display the home screen SC2 of the payment function or the home screen SC2 of the point function.

[0104] The proposed system 1 of the first modification determines whether the payment app is in a predetermined state by determining whether the payment app has been launched due to a launch source. When it is determined that the payment app has been launched due to a launch source, the proposed system 1 proposes a launch source function screen in the payment app. This allows the user to know the existence of functions that can be used when the payment app is launched due to a launch source, so the proposed system 1 can improve user convenience. In the example of FIG. 9, the user can display a home screen SC2 with a function corresponding to an operation performed on the launch source screen SC3, so the proposed system 1 can improve user convenience.

[0105] [6-2. Variation 2] For example, the method of determining whether the proposed conditions are satisfied is not limited to the examples described in the embodiment and variant example 1. The functions to be proposed to the user may vary depending on the payment history performed by the user. Variation example 2 takes as an example a case where whether the proposed conditions are satisfied is determined based on the payment history. The function screen of variant example 2 is a payment-related function screen for providing, among multiple functions, payment-related functions related to payments executed from the payment app.

[0106] A payment-related function may be any function related to payment in some way. The payment-related function is not limited to a payment function for paying for goods or services purchased at a store. For example, a point function is an example of a payment-related function, since a user can earn points based on the payment amount when a payment is made. A money transfer function is also an example of a payment-related function, since a change in balance due to a money transfer is a type of payment. A charge function is also an example of a payment-related function, since a payment is made using the payment method of the charge source when a charge is made. For example, the home screen SC2 of the payment function, the home screen SC2 of the money transfer function, and the home screen SC2 of the point function each correspond to a payment-related function screen. A payment-related function may also be a specific payment method used in a payment, such as a credit card, electronic money, or bank account. In other words, a credit card payment function, an electronic money payment function, and a bank account payment function may be separate payment-related functions.

[0107] The proposed system 1 of the second modification includes a history information acquisition unit 104. The history information acquisition unit 104 acquires history information regarding the history of payments made using payment-related functions. The history information is information indicating the usage history of the payment-related functions. For example, the history information may indicate the date and time of payment, the payment amount, the number of payments, the payment location, the number of points awarded for the payment, the balance of electronic money or the like after the payment, information on the payment method set as the payment source, the contents of the purchased product or service, or a combination of these. Since payment methods are used not only for payments but also for charging, the history information may indicate the charge amount, the date and time of charge, information on the payment method set as the charge source, or a combination of these.

[0108] In the second modification, it is assumed that the history information of each of multiple users is stored in the payment database DB1. Therefore, the history information acquisition unit 104 acquires the history information of the user who is the subject of the determination of the proposed conditions from the payment database DB1. The payment server 10 updates the history information of a user each time the user uses a payment-related function. The history information may be stored in a database other than the payment database DB1. For example, if the payment-related function is a point function, the history information may be stored in the point database DB2. The history information acquisition unit 104 may acquire the history information from another database. If the history information is stored in a computer or information storage medium other than the payment server 10, the history information acquisition unit 104 may acquire the history information from the other computer or information storage medium.

[0109] The data storage unit 100 of the second modification stores history proposal data indicating the relationship between proposal conditions determined based on history information and payment-related functional screens to be proposed when the proposal conditions are satisfied. The history proposal data may indicate the relationship between each of a plurality of proposal conditions and the payment-related functional screens. The determination unit 102 and the proposal unit 103 refer to the history proposal data and perform the processes described below.

[0110] The determination unit 102 of the second modification determines whether the proposal conditions are satisfied based on the history information. For example, the determination unit 102 may determine whether the proposal conditions are satisfied by determining whether the payment date and time indicated by the history information is in the current time zone. If the determination unit 102 determines that the payment date and time is not in the current time zone, the determination unit 102 determines that the proposal conditions are not satisfied, and if the determination unit 102 determines that the payment date and time is in the current time zone, the determination unit 102 determines that the proposal conditions are satisfied. The determination unit 102 may determine whether the proposal conditions are satisfied by determining whether the payment amount indicated by the history information is equal to or greater than a threshold. If the determination unit 102 determines that the payment amount is less than the threshold, the determination unit 102 determines that the proposal conditions are not satisfied, and if the determination unit 102 determines that the payment amount is equal to or greater than the threshold, the determination unit 102 determines that the proposal conditions are satisfied.

[0111] For example, the determination unit 102 may determine whether the proposal condition is satisfied by determining whether the number of payments tallied from the history information is equal to or greater than a threshold. If the determination unit 102 determines that the number of payments is less than the threshold, it determines that the proposal condition is not satisfied, and if the determination unit 102 determines that the number of payments is equal to or greater than the threshold, it determines that the proposal condition is satisfied. Similarly, if the history information is other information expressed as a numerical value, the determination unit 102 may determine whether the proposal condition is satisfied by determining whether the numerical value indicated by the other information is equal to or greater than a threshold.

[0112] In the second modification, the suggestion unit 103 suggests a payment-related function screen in the payment app when it is determined that the suggestion conditions are satisfied. The suggestion unit 103 suggests a payment-related function screen in the payment app when it is determined that the suggestion conditions are satisfied, as a condition (trigger). The suggestion unit 103 does not suggest a payment-related function screen in the payment app when it is determined that the suggestion conditions are not satisfied.

[0113] For example, if the suggestion unit 103 determines that the payment date and time indicated by the history information is in the current time zone, it proposes a payment-related function screen for using the payment method used at that payment date and time. If the suggestion unit 103 determines that the payment amount indicated by the history information is equal to or greater than a threshold, it proposes a payment-related function screen for using a specific payment method (e.g., a payment method used in a payment whose payment amount is equal to or greater than a threshold). If the suggestion unit 103 determines that the number of payments indicated by the history information is equal to or greater than a threshold, it proposes a payment-related function screen for using a specific payment method (e.g., the payment method most used in the past). Similarly, if the history information is other information, the suggestion unit 103 may propose a payment-related function screen associated with the proposed conditions.

[0114] The proposed system 1 of the second modification acquires history information regarding the history of payments performed using payment-related functions. Based on the history information, the proposed system 1 determines whether the proposed conditions are met. If it is determined that the proposed conditions are met, the proposed system 1 proposes a payment-related function screen in the payment app. This allows the user to know the payment-related functions according to the history information, thereby improving user convenience.

[0115] [6-3. Variation 3] For example, in Modification 2, the history information may indicate the execution status of payments over a predetermined period. The predetermined period is the period for which history is acquired. The predetermined period may be the entire past period, but in Modification 3, it is assumed to be a partial past period. Furthermore, the predetermined period may be a fixed period of the most recent period (for example, the most recent week, month, or six months), or it does not have to be a recent period. Modification 3 takes the example of the specified period being the most recent month. The history information acquisition unit 104 acquires history information indicating the execution status of payments over the most recent month. Details of the history information are as described in Modification 2.

[0116] The determination unit 102 of the third modification determines whether the proposed conditions are satisfied by determining whether the payment execution status during a predetermined period indicated by the history information is a predetermined status. If the determination unit 102 determines that the payment execution status during the predetermined period is not a predetermined status, it determines that the proposed conditions are not satisfied, and if the determination unit 102 determines that the payment execution status during the predetermined period is a predetermined status, it determines that the proposed conditions are satisfied.

[0117] For example, the determination unit 102 may determine whether the proposal condition is satisfied by determining whether the current time period is a time period in which a relatively large number of payments have been made within a predetermined period. The determination unit 102 may determine whether the proposal condition is satisfied by determining whether the average payment amount of payments made within a predetermined period is equal to or greater than a threshold. The determination unit 102 may determine whether the proposal condition is satisfied by determining whether the number of payments made within a predetermined period is equal to or greater than a threshold. Similarly, when the execution status of payments made within a predetermined period is other information expressed numerically, the determination unit 102 may determine whether the proposal condition is satisfied by determining whether the numerical value indicated by the other information is equal to or greater than a threshold.

[0118] In the third modification, the suggestion unit 103 suggests a payment-related function screen in the payment app when it is determined that the payment execution status indicated by the history information is a predetermined status. The suggestion unit 103 suggests a payment-related function screen in the payment app when it is determined that the payment execution status indicated by the history information is a predetermined status, as a condition (trigger). The suggestion unit 103 does not suggest a payment-related function screen in the payment app when it is determined that the payment execution status indicated by the history information is not a predetermined status. For example, when it is determined that the current time period is a time period in which a relatively large number of payments were made during a predetermined period, the suggestion unit 103 suggests a payment-related function screen for using the payment method used during that time period.

[0119] For example, if the suggestion unit 103 determines that the average payment amount of payments made during a predetermined period is equal to or greater than a threshold, it suggests a payment-related function screen for using a specific payment method (e.g., a payment method with a relatively high or low usage amount). If the suggestion unit 103 determines that the number of payments made during a predetermined period is equal to or greater than a threshold, it suggests a payment-related function screen for using a specific payment method (e.g., a payment method with a relatively high or low usage number). Similarly, if the history information is other information, the suggestion unit 103 may suggest a payment-related function screen associated with the proposed conditions.

[0120] The proposed system 1 of the third modification determines whether the proposed conditions are satisfied by determining whether the payment execution status indicated by the history information is a predetermined status. If the proposed system 1 determines that the payment execution status indicated by the history information is a predetermined status, the proposed system 1 proposes a payment-related function screen in the payment app. This allows the user to know the payment-related functions corresponding to the payment execution status over a predetermined period, thereby improving user convenience.

[0121] [6-4. Variation 4] For example, if a user has previously made a payment using a credit card when shopping at a shopping mall, there is a possibility that the user will make a payment using the same credit card again at the shopping mall. In other words, if a user has previously made a payment at a facility where the user is located, the user may use the same payment method. Therefore, in Variation 4, the facility where the user is located is estimated based on the location of the user terminal 20, and payment-related functions are suggested based on whether or not the user has used a payment method for payment at that facility.

[0122] The proposed system 1 of the fourth modification includes a location information acquisition unit 105 and a facility estimation unit 106. The location information acquisition unit 105 acquires location information related to the user's location. The location information is information that can identify the user's location. The location information may be publicly known information. In the fourth modification, the location information is given as latitude and longitude as an example, but the location information may be in other formats. For example, the location information may be coordinates, an address, information about wireless communication devices, information about mobile base stations, information about terminals located in facilities such as stores, or other information.

[0123] In the fourth modification, an example is taken in which the user terminal 20 includes a GPS receiver. The user terminal 20 acquires location information based on a signal received by the GPS receiver. The user terminal 20 may acquire location information using a Global Navigation Satellite System (GNSS) other than GPS. The user terminal 20 may acquire location information based on a communication result of the communication unit 23. The user terminal 20 may be able to acquire location information based on a known method. For example, the user terminal 20 transmits location information to the payment server 10 at any timing, such as when the payment app is launched. The location information acquisition unit 105 acquires location information from the user terminal 20.

[0124] The location information acquisition unit 105 may acquire location information from a terminal (e.g., a POS terminal) installed in a facility such as a store. The location of the facility may be estimated as the user's location. For example, the terminal (e.g., a POS terminal) installed in the facility may transmit a payment request including location information to the payment server 10 when executing a payment. The payment request is data transmitted at the time of payment. For example, the payment request may include facility information (facility identification information) that can identify a facility such as a store. The location information acquisition unit 105 may acquire the location information included in the payment request. The location information acquisition unit 105 may acquire the location information based on the facility information.

[0125] The data storage unit 100 of the fourth modification stores a facility database that stores various information about facilities where payment services are available. The facility is not limited to a store, but may be other facilities such as public facilities or event facilities. The facility can also be considered to be a member of at least one of the payment service and the point service. The facility database may store information about at least one of facilities that are members of both the payment service and the point service, facilities that are members of the payment service without being members of the point service, and facilities that are members of the point service without being members of the payment service.

[0126] For example, the facility database stores a facility ID that can identify a facility, the facility name, location information about the location of the facility, a description of the facility, an image of the facility, or other information. While Variation 4 takes an example in which the location information is latitude and longitude, similar to the position information, the location information may be in other formats. For example, the location information may be coordinates, an address, information about a wireless communication device, information about a mobile base station, or other information.

[0127] The facility estimation unit 106 estimates the facility where the user is located based on the location information. The facility estimation unit 106 identifies facilities near the location indicated by the location information based on a facility database. The facility estimation unit 106 may identify facilities where the distance between the location indicated by the location information and the location indicated by the location information is less than a threshold, or may identify a predetermined number of facilities in order of shortest distance (e.g., the facility with the shortest distance). The facility estimation unit 106 acquires information such as the facility name of the identified facility from the facility database and provides the facility information to the user. For example, the facility estimation unit 106 provides the user with the facility name, location information of the facility, a description of the facility, an image of the facility, or other information as facility information. The facility estimation unit 106 may estimate the facility where the user is located based on the fact that the payment code C20 is read by the facility terminal.

[0128] The history information in Variation 4 indicates payment-related functions that the user has used in the past. For example, the history information indicates the specific payment method used in the payment-related functions. The history information may also indicate other information such as the payment location. For example, if a user uses electronic money at a facility, the history information indicates that the electronic money was used at the facility. If a user uses a credit card at a facility, the history information indicates that the credit card was used at the facility. When a user makes a payment at a facility, the payment server 10 associates history information, including the facility ID of the facility and information that can identify the payment method used in the payment, with the user ID of the user and stores it in the payment database DB1. The history information acquisition unit 104 acquires the history information.

[0129] The determination unit 102 of the fourth modification determines whether the proposal conditions are satisfied by determining, based on the history information, whether any payment-related functions have been used by the user at the facility in the past. For example, the determination unit 102 determines whether the facility ID of the facility estimated by the facility estimation unit 106 is indicated in the history information and whether information that can identify the payment method used at the facility is indicated in the history information. If the determination unit 102 determines that these are not indicated in the history information, it does not determine that the proposal conditions are satisfied, and if the determination unit 102 determines that these are not indicated in the history information, it determines that the proposal conditions are satisfied.

[0130] FIG. 10 is a diagram showing an example of a screen displayed on the user terminal 20 of Variation 4. When it is determined that the user has previously used a payment-related function at a facility, the suggestion unit 103 suggests a payment-related function screen for the payment-related function in the payment app. For example, as shown in FIG. 10, the suggestion unit 103 suggests the payment-related function screen by displaying a home screen SC2 including a window W25 that suggests using the same payment method as the user previously used at the facility estimated by the facility estimation unit 106 for the payment-related function. When the user selects button B250, the payment server 10 automatically sets the payment method as the payment source. As shown in FIG. 10, the payment function home screen SC2 shows the payment method as the payment source.

[0131] The proposed system 1 of the fourth modification acquires location information. Based on the location information, the proposed system 1 estimates the facility where the user is located. The history information indicates payment-related functions that the user has used in the past. Based on the history information, the proposed system 1 determines whether the proposal conditions are met by determining whether the user has used any payment-related functions at the facility in the past. If the proposed system 1 determines that the user has used any payment-related functions at the facility in the past, the proposed system 1 suggests a payment-related function screen for the payment-related function in the payment app. This allows the user to know the payment-related functions that the user has used at the same facility in the past, thereby improving user convenience.

[0132] [6-5. Variation 5] For example, as in Variations 3 and 4, when suggestions are made based on history information, a payment-related function screen for a payment-related function that the user uses relatively frequently may be suggested, but Variation 5 takes as an example a case where a payment-related function screen for a payment-related function that the user uses relatively little is suggested. As in Variation 4, the history information in Variation 5 indicates payment-related functions that the user has used in the past.

[0133] The determination unit 102 of the fifth modification determines whether the proposal condition is satisfied by determining whether there is a payment-related function that is relatively less used by the user based on the history information. The determination unit 102 determines whether a payment-related function is relatively less used by the user among multiple payment-related functions. A payment-related function that is relatively less used by the user is a payment-related function that is used by the user less than a threshold number of times, a payment-related function that is used the least by the user, or a payment-related function that is ranked low (for example, a rank below a predetermined rank) when ranked in order of most frequently used by the user.

[0134] For example, the determination unit 102 tallies the number of times a user has used each of a plurality of payment-related functions based on the history information. In the case of a credit card payment-related function and an electronic money payment-related function, the determination unit 102 tallies the number of times the credit card payment-related function and the electronic money payment-related function have been used based on the type of payment method indicated in the history information. The determination unit 102 may determine whether the proposal condition is satisfied by determining whether any of these two payment-related functions has a usage count below a threshold. The payment-related functions whose usage counts are to be tallied are not limited to these two. Other payment-related functions, such as a points function, may be tallied, and the points function may be suggested to the user if the points function is relatively less used.

[0135] FIG. 11 is a diagram showing an example of a screen displayed on the user terminal 20 of the fifth modification. When it is determined that a payment-related function is relatively unused by the user, the suggestion unit 103 of the fifth modification proposes a payment-related function screen for the payment-related function in the payment app. For example, if the user is relatively unused to electronic money payment-related functions, the suggestion unit 103 proposes a payment-related function screen by displaying a home screen SC2 including a window W25 proposing the use of electronic money payment-related functions, as shown in FIG. 11. When the user selects button B250, the payment server 10 automatically sets electronic money as the payment source. As shown in FIG. 11, the home screen SC2 for the payment function shows the payment method as the payment source.

[0136] The proposed system 1 of the fifth modification determines whether the proposal condition is satisfied by determining whether there are payment-related functions that the user relatively does not use based on the history information. If the proposed system 1 determines that there are payment-related functions that the user relatively does not use, the proposed system 1 proposes a payment-related function screen for the payment-related function in the payment app. This allows the user to know which payment-related functions they do not normally use, thereby improving user convenience.

[0137] [6-6. Variation 6] For example, in Modifications 2 to 5, the case where whether or not the proposed conditions are satisfied is determined based on history information has been given as an example. Proposal system 1 may determine whether or not the proposed conditions are satisfied based on the payment-related functions used at the time the payment-related functions are used, rather than on the history of payments executed in the past. The function screen of Modification 6, like Modifications 2 to 5, is a payment-related function screen for providing payment-related functions related to payments executed from the payment app, among multiple functions.

[0138] The proposed system 1 of Variation 6 includes a usage information acquisition unit 107. When a payment is made using a payment-related function, the usage information acquisition unit 107 acquires usage information related to the payment to be made. The usage information is information indicating the content of a payment to be made or the content of a payment currently made. For example, the usage information may indicate the date and time of payment, the payment amount, the number of payments, the payment location, the number of points awarded for the payment, the balance of electronic money or the like after the payment, information on the payment method set as the payment source, whether or not the point function was used, or a combination of these. Since payment methods are used not only for payments but also for charging, the usage information may indicate the charge amount, the date and time of charging, information on the payment method set as the charge source, or a combination of these. The usage information acquisition unit 107 generates usage information each time a payment is made. The usage information acquired by the usage information acquisition unit 107 may be stored in the payment database DB1 as history information.

[0139] The determination unit 102 of the sixth modification determines whether the proposed conditions are satisfied based on the usage information. For example, the determination unit 102 may determine whether the proposed conditions for payment functions of payment methods other than points are satisfied by determining whether the usage information indicates the use of a point function. If the determination unit 102 determines that the usage information does not indicate the use of a point function, it determines that the proposed conditions for the payment functions of the other payment methods are not satisfied, and if the determination unit 102 determines that the usage information indicates the use of a point function, it determines that the proposed conditions for the payment functions of the other payment methods are satisfied.

[0140] For example, the determination unit 102 may determine whether the proposed conditions for the point function are satisfied by determining whether the usage information indicates the use of a payment function of another payment method. If the determination unit 102 determines that the usage information does not indicate the use of a payment function of another payment method, it determines that the proposed conditions for the point function are not satisfied, and if the determination unit 102 determines that the usage information indicates the use of a payment function of another payment method, it determines that the proposed conditions for the point function are satisfied.

[0141] For example, the determination unit 102 may determine whether the proposal conditions are satisfied by determining whether the payment method indicated by the usage information is a predetermined payment method. If the determination unit 102 determines that the payment method indicated by the usage information is not a predetermined payment method, it determines that the proposal conditions are not satisfied, and if the determination unit 102 determines that the payment method is a predetermined payment method, it determines that the proposal conditions are satisfied. The determination unit 102 may determine whether the proposal conditions are satisfied by determining whether the payment date and time indicated by the usage information is within a predetermined time period. If the determination unit 102 determines that the payment date and time is not within a predetermined time period, it determines that the proposal conditions are not satisfied, and if the determination unit 102 determines that the payment date and time is within a predetermined time period, it determines that the proposal conditions are satisfied.

[0142] For example, the determination unit 102 may determine whether the proposal condition is satisfied by determining whether the payment amount indicated by the usage information is equal to or greater than a threshold. If the determination unit 102 determines that the payment amount is less than the threshold, it determines that the proposal condition is not satisfied, and if the determination unit 102 determines that the payment amount is equal to or greater than the threshold, it determines that the proposal condition is satisfied. Similarly, if the usage information is other information expressed as a numerical value, the determination unit 102 may determine whether the proposal condition is satisfied by determining whether the numerical value indicated by the other information is equal to or greater than a threshold.

[0143] FIG. 12 is a diagram showing an example of a screen displayed on the user terminal 20 of the sixth modification. The suggestion unit 103 of the sixth modification proposes a payment-related function screen in the payment app when it is determined that the proposal conditions are satisfied. The suggestion unit 103 proposes a payment-related function screen in the payment app when it is determined that the proposal conditions are satisfied, using the determination that the proposal conditions are satisfied as a condition (trigger). The suggestion unit 103 does not propose a payment-related function screen in the payment app when it is determined that the proposal conditions are not satisfied. In the example of FIG. 12, the suggestion unit 103 proposes a payment-related function screen for the payment-related function by displaying a window W40 proposing payment-related functions for a payment method (e.g., electronic money) other than the payment method (e.g., credit card) used by the user on the payment completion screen SC4 indicating that the payment has been completed. When the user selects button B41, the payment source is changed to electronic money, and the home screen SC2 of the payment function is displayed as the payment-related function screen.

[0144] The proposed system 1 of the sixth modification acquires usage information regarding a payment made using a payment-related function when the payment is made using the payment-related function. The proposed system 1 determines whether or not the proposed conditions are met based on the usage information. If it is determined that the proposed conditions are met, the proposed system 1 proposes a payment-related function screen in the payment app. This allows the user to know the payment-related functions according to the usage information, thereby improving user convenience.

[0145] [6-7. Variation 7] For example, in Variation 6, the multiple functions may include, as payment-related functions, a point function in which points are used and a payment function in which a payment method other than points is used. In this case, when one of the point function and the payment function is used, the usage information acquisition unit 107 acquires usage information that can identify the one. The one of the point function and the payment function is either the point function or the payment function that the user has used.

[0146] For example, the usage information acquisition unit 107 acquires usage information indicating that either the point function or the payment function has been used. The usage information may be stored in the payment database DB1, but in variant example 7, it is acquired from a terminal at a facility such as a store. For example, when the facility terminal reads point code C24, it transmits usage information indicating that the point function has been used to the payment server 10. The usage information includes a point code ID acquired from the point code C24. The usage information acquisition unit 107 acquires usage information indicating that the point function has been used from the facility terminal. For example, when the facility terminal reads payment code C20, it transmits usage information indicating that the payment function has been used to the payment server 10. The usage information includes a payment code ID acquired from the payment code C20. The usage information acquisition unit 107 acquires usage information indicating that the payment function has been used from the facility terminal.

[0147] The determination unit 102 of the seventh modification determines whether the proposed conditions for the other of the point function and the payment function are satisfied based on the usage information. The other of the point function and the payment function is the one of the point function and the payment function that is not one of the above-mentioned functions. For example, if the usage information indicates that a payment function of a payment means other than points will be used, the determination unit 102 determines that the proposed conditions for the point function are satisfied. If the usage information indicates that the point function will be used, the determination unit 102 determines that the proposed conditions for the payment function of a payment means other than points are satisfied. These determination methods are as described in the sixth modification.

[0148] FIG. 13 is a diagram showing an example of a screen displayed on user terminal 20 in Modification 7. When it is determined that the other proposed condition is satisfied, proposal unit 103 proposes the other payment-related function screen in the payment app. When it is determined that the other proposed condition is satisfied, proposal unit 103 proposes the other payment-related function screen in the payment app, using as a condition (trigger) that the other proposed condition is satisfied. When it is determined that the other proposed condition is not satisfied, proposal unit 103 does not propose the other payment-related function screen in the payment app. Note that proposal unit 103 may propose the payment function after the user uses the point function, or may propose the point function after the user uses the payment function.

[0149] For example, as shown in the upper part of FIG. 13, when point code C24 is read and the point function is used, it is determined that the proposed conditions for the payment function of a payment method other than points are met. In this case, the suggestion unit 103 automatically transitions from the home screen SC2 of the point function to the home screen SC2 of the payment function, thereby proposing the home screen SC2 of the payment function. As shown in the lower part of FIG. 13, when payment code C20 is read and the payment function is used, it is determined that the proposed conditions for the point function are met. In this case, the suggestion unit 103 automatically transitions from the home screen SC2 of the payment function to the home screen SC2 of the point function, thereby proposing the home screen SC2 of the point function.

[0150] The proposed system 1 of Variation 7 acquires usage information capable of identifying either the point function or the payment function when the function is used. Based on the usage information, the proposed system 1 determines whether the proposed conditions for the other of the point function and the payment function are satisfied. If it determines that the proposed conditions for the other function are satisfied, the proposed system 1 proposes a payment-related function screen for the other function in the payment app. This eliminates the need for the user to switch between the point function and the payment function, thereby improving user convenience. For example, in the upper example of FIG. 13, the proposed system 1 can automatically display the payment code C20 when it detects that the point code C24 has been read from the usage information. In the lower example of FIG. 13, the proposed system can automatically display the point code C24 when it detects that the payment code C20 has been read from the usage information.

[0151] [6-8. Variation 8] For example, in Variation 7, an example is given of a case where, when one of the point function and the payment function is used, it is determined that the proposal conditions for the other function are satisfied. Depending on the facility where the user is located, the other function may not be available. Therefore, in Variation 8, an example is given of a case where it is determined whether the proposal conditions are satisfied by determining whether the other function is available in the facility where the user is located. The proposal system 1 of Variation 8 includes a location information acquisition unit 105 and a facility estimation unit 106. The location information acquisition unit 105 and the facility estimation unit 106 are as described in Variation 4.

[0152] The determination unit 102 of Modification 8 determines whether the other of the point function and the payment function (the one that has not been used earlier) is available at the facility estimated by the facility estimation unit 106, thereby determining whether the other proposed condition for the point function is met. Availability information indicating whether each of the point function and the payment function is available at the facility is stored in the facility database described in Modification 4. Availability information for each facility is associated with the facility ID of the facility and stored in the facility database. The availability information indicates whether only the point function is available, whether only the payment function is available, or whether both the point function and the payment function are available. The determination unit 102 references the availability information for the facility estimated by the facility estimation unit 106 and determines whether the other is available.

[0153] For example, when the execution information indicates use of a point function (when one of the point function and the payment function is the point function), the determination unit 102 determines whether the other function, the payment function, is available at the facility based on the facility availability information estimated by the facility estimation unit 106. When the execution information indicates use of a payment function (when one of the point function and the payment function is the payment function), the determination unit 102 determines whether the other function, the point function, is available at the facility based on the facility availability information estimated by the facility estimation unit 106.

[0154] The suggestion unit 103 of the eighth modification suggests the other payment-related function screen in the payment app when it is determined that the other of the points function and the payment function is available at the facility estimated by the facility estimation unit 106. The suggestion unit 103 suggests the other payment-related function screen in the payment app on the condition that it is determined that the other of the points function and the payment function is available at the facility estimated by the facility estimation unit 106. When it is determined that the other of the points function and the payment function is not available at the facility estimated by the facility estimation unit 106, the suggestion unit 103 does not suggest the other payment-related function screen in the payment app.

[0155] In the example at the top of Fig. 13, when point code C24 is read and the usage information indicates use of the point function, the suggestion unit 103 suggests the home screen SC2 of the payment function to the user on the condition that it is determined that the payment function is available at the facility estimated by the facility estimation unit 106 (i.e., on the condition that the facility is affiliated with the payment service). When payment code C20 is read and the usage information indicates use of the payment function, the suggestion unit 103 suggests the home screen SC2 of the point function to the user on the condition that it is determined that the point function is available at the facility estimated by the facility estimation unit 106 (i.e., on the condition that the facility is affiliated with the point service).

[0156] The proposed system 1 of Variation 8 acquires location information regarding the location of the user terminal 20. Based on the location information, the proposed system 1 estimates the facility where the user is located. The proposed system 1 determines whether the other proposed function is available at the facility, thereby determining whether the other proposed function's conditions are met. If it is determined that the other function is available at the facility, the proposed system 1 proposes a payment-related function screen for the other function in the payment app. This eliminates the need for the user to switch between the point function and the payment function when the other function is available at the facility where the user is located, thereby improving user convenience.

[0157] [6-9. Variation 9] For example, the multiple functions may include a payment function that uses a balance and a balance top-up function. The payment function that uses a balance may be an electronic money payment function, or may be a balance payment function that uses a balance that is not called electronic money. Variation 9 takes as an example a case where a top-up function is suggested depending on the balance when a payment is made using a payment function that uses a balance. Variation 9 takes as an example a case where a top-up function is suggested at the time of payment, but the top-up function may also be suggested at times other than at the time of payment (for example, when the payment app is launched, when the user performs a predetermined operation, or when a predetermined date and time arrives).

[0158] For example, when a payment is made using a payment function that uses a balance, the usage information acquisition unit 107 may acquire usage information regarding the balance after the payment is made. The usage information of variant 9 indicates the balance after payment for the payment function that uses the balance. The balance is the value obtained by subtracting the payment amount from the balance before the payment. Information indicating the balance before the payment is stored in the payment database DB1. The usage information acquisition unit 107 acquires the usage information by calculating the value obtained by subtracting the payment amount included in the payment request received from a store terminal or the like from the balance before the payment indicated by the information. Note that if a charge function is proposed at a time other than the time of payment, the usage information acquisition unit 107 does not need to acquire usage information to propose the charge function.

[0159] The determination unit 102 of the ninth modification determines whether the proposal condition is satisfied by determining whether the balance is less than a threshold. The threshold is assumed to be stored in the data storage unit 100. The threshold may be common to all users, or a value may be set for each user. If the determination unit 102 determines that the balance is equal to or greater than the threshold, the determination unit 102 does not determine that the proposal condition is satisfied. If the determination unit 102 determines that the balance is equal to or greater than the threshold, the determination unit 102 determines that the proposal condition is satisfied. The determination by the determination unit 102 may be performed at the time of payment or at a time other than the time of payment. For example, the determination unit 102 may determine whether the balance is less than a threshold when the payment app is launched, when the user performs a predetermined operation, or when a predetermined date and time arrives, thereby determining whether the proposal condition is satisfied.

[0160] FIG. 14 is a diagram showing an example of a screen displayed on the user terminal 20 according to the ninth modification. The suggestion unit 103 of the ninth modification proposes a function screen of the charge function in the payment app when it is determined that the balance is below the threshold. The suggestion unit 103 proposes a function screen of the charge function in the payment app on the condition that it is determined that the balance is below the threshold. In the example of FIG. 14, the suggestion unit 103 proposes the function screen of the charge function by displaying a window W40 for transitioning to a home screen SC2 of the charge function on the payment completion screen SC4. Note that the suggestion unit 103 may also propose the function screen of the charge function at times other than the time of payment. For example, the suggestion unit 103 may propose the function screen of the charge function on the condition that it is determined that the balance is below the threshold when the payment app is launched, when the user performs a predetermined operation, or when a predetermined date and time arrives.

[0161] For example, when the user selects button B41, the user terminal 20 transitions from the payment completion screen SC4 to the home screen SC2 of the charge function. The home screen SC2 of the charge function is an example of a function screen of the charge function. If the user does not select button B41, the screen does not transition to the home screen SC2 of the charge function. If the suggestion unit 103 determines that the balance is equal to or greater than the threshold, it does not suggest the function screen of the charge function in the payment app. In this case, the window W40 is not displayed on the payment completion screen SC4, and the details of the executed payment are displayed.

[0162] The proposed system 1 of the ninth modification acquires usage information regarding the balance after a payment is made using a payment function that uses the balance. The proposed system 1 determines whether the proposal conditions are met by determining whether the balance is less than a threshold. When it is determined that the balance is less than the threshold, the proposed system 1 proposes a function screen for the charge function in the payment app. This allows the user to immediately use the charge function when the balance falls below the threshold due to a payment, thereby improving user convenience.

[0163] [6-10. Variation 10] For example, depending on the facility where the user is located, the functions available to the user may be limited. Therefore, in Modification 10, an example is given in which functions available in the facility where the user is located are suggested. The proposal system 1 of Modification 10 includes a location information acquisition unit 105 and a facility estimation unit 106. The location information acquisition unit 105 and the facility estimation unit 106 are as described in Modification 4.

[0164] The determination unit 102 of the tenth modification determines whether the function to be proposed is available at the facility estimated by the facility estimation unit 106, thereby determining whether the proposal conditions are satisfied. Availability information indicating whether the function is available at the facility is assumed to be stored in the facility database described in the fourth modification. The availability information indicates the functions available at the facility. The availability information of each facility is associated with the facility ID of the facility and stored in the facility database.

[0165] For example, the determination unit 102 determines whether the proposal conditions are satisfied by referring to the facility availability information estimated by the facility estimation unit 106 and identifying functions available at the facility. The functions available at the facility may be the same as the point function and payment function described in Variation 8, or may be specific types of payment methods available as payment functions, or may be functions other than payment-related functions (e.g., check-in functions). For example, the availability information may indicate payment methods available at each facility from among multiple payment methods such as credit cards, electronic money, and bank accounts. The determination unit 102 determines that the proposal conditions for functions not indicated by the facility availability information are not satisfied, and determines that the proposal conditions for functions indicated by the facility availability information are satisfied.

[0166] The suggestion unit 103 of the tenth modification suggests a function screen in the payment app when it is determined that the function to be suggested is available at the facility estimated by the facility estimation unit 106. The suggestion unit 103 suggests a function screen in the payment app on the condition that it is determined that the function is available at the facility. When it is not determined that the function is available at the facility, the suggestion unit 103 does not suggest a function screen in the payment app.

[0167] For example, when the payment app is launched, the user terminal 20 transmits location information to the payment server 10. When the payment server 10 acquires the location information from the user terminal 20, it estimates the facility where the user is located by processing the location information acquisition unit 105 and the facility estimation unit 106. The determination unit 102 determines whether the proposal conditions for the function are met by identifying functions available at the facility. The suggestion unit 103 proposes the function for which the proposal conditions are determined to be met. For example, the suggestion unit 103 proposes functions available at the facility where the user is located in a window W25 on the home screen SC2 that is displayed after the payment app is launched.

[0168] For example, if only credit cards are accepted at the facility where the user is located, the suggestion unit 103 displays a window W25 on the home screen SC2 suggesting the use of credit card payment-related functions. If only electronic money is accepted at the facility where the user is located, the suggestion unit 103 displays a window W25 on the home screen SC2 suggesting the use of electronic money payment-related functions. Similarly, for other facilities, the suggestion unit 103 makes suggestions by displaying a window W25 on the home screen SC2 indicating payment-related functions available at the facility where the user is located. The suggestion unit 104 similarly suggests other functions based on the determination result of the determination unit 102 when suggesting functions other than payment-related functions.

[0169] The suggestion unit 103 may suggest a function screen in the payment app on the condition that the user's stay time in the facility estimated by the facility estimation unit 106 is equal to or longer than a predetermined time. For example, the suggestion unit 103 may suggest a function screen to a user who does not use payment-related functions even if the stay time is equal to or longer than the predetermined time, thereby encouraging the user to use payment-related functions.

[0170] The proposed system 1 of the tenth modification acquires location information regarding the location of the user terminal 20. The proposed system 1 estimates the facility where the user is located based on the location information. The proposed system 1 determines whether the proposed function is available at the facility, thereby determining whether the proposal conditions are met. If it is determined that the function is available at the facility, the proposed system 1 proposes a function screen in the payment app. This allows the user to know the existence of functions available at the facility where the user is located, thereby improving user convenience.

[0171] [6-11. Variation 11] For example, the method of determining whether the proposal conditions are satisfied is not limited to the examples described in the embodiment and Modifications 1 and 2. The functions that are appropriate to be proposed to the user may be estimated from the user's operations on the payment app. Therefore, Modification 2 provides an example in which whether the proposal conditions are satisfied is determined based on the user's operations on the payment app.

[0172] The proposed system 1 of the 11th modification includes an operation information acquisition unit 108. The operation information acquisition unit 108 acquires operation information related to user operations on the payment app. The operation information is information indicating a history of user operations on the payment app. In the 11th modification, an example is given in which the operation information is an operation unrelated to the functions of the payment app, but the operation information may also indicate the number of times the user has selected each of multiple functions of the payment app. The operation information may be stored in the payment database DB1. The operation information may also indicate the number of times a certain icon in the payment app is selected. The operation information may also indicate the number of times a certain screen is displayed, rather than an indicator such as the number of clicks.

[0173] For example, when an operation is performed on the payment app, the user terminal 20 transmits operation information indicating the operation content to the payment server 10. When the user selects a function, the user terminal 20 may transmit operation information indicating that the function has been selected to the payment server 10. When the payment server 10 receives operation information from the user terminal 20, it stores the operation information in the payment database DB1. If the operation information indicates the number of times each function has been selected, the payment server 10 may update the operation information in the payment database DB1 when receiving operation information from the user terminal 20 so that the number of times the function indicated by the operation information has been selected increases. The operation information stored in the payment database DB1 may indicate each operation by the user, or may indicate the number of times each of multiple functions has been selected.

[0174] The determination unit 102 of the eleventh modification determines whether or not the proposal condition is satisfied based on the operation information. For example, the determination unit 102 determines whether or not the number of times the user has selected a specific icon is equal to or greater than a threshold, thereby determining whether or not the proposal condition is satisfied. The determination unit 102 may determine that the proposal condition is not satisfied when it is determined that the number of times the user has selected a specific icon is less than the threshold, and may determine that the proposal condition is satisfied when it is determined that the number of times the user has selected a specific icon is equal to or greater than the threshold. When it is determined that the proposal condition is satisfied, the proposal unit 103 may suggest to the user a function associated with the icon. Data indicating the relationship between the icon and the function to be suggested is assumed to be stored in advance in the data storage unit 100. The proposal unit 103 may identify the function to be suggested based on the data.

[0175] The proposed system 1 of the modification 11 acquires operation information related to a user's operation in a payment app. Based on the operation information, the proposed system 1 determines whether or not the proposed conditions are satisfied. This allows the user to know the functions corresponding to the operation performed by the user, thereby improving user convenience.

[0176] [6-12. Variation 12] For example, in Modification 11, the determination unit 102 may determine whether or not the proposal condition is satisfied by determining whether or not there is a function that has been used by the user relatively frequently or infrequently, based on the operation information. The determination unit 102 may determine, based on the number of times each function is selected indicated by the operation information, a function that has been used by the user a threshold or more times as a relatively frequently used function. The determination unit 102 may determine, based on the number of times each function is selected indicated by the operation information, functions that have been used by the user up to a predetermined rank in terms of the number of times that each function is selected indicated by the operation information, as a relatively frequently used function. The determination unit 102 may determine, based on the number of times each function is selected indicated by the operation information, a function that has been used by the user a threshold or less times as a relatively infrequent function. The determination unit 102 may determine, based on the number of times each function is selected indicated by the operation information, functions that have been used by the user up to a predetermined rank in terms of the number of times that each function is selected indicated by the operation information, as a relatively infrequent function.

[0177] In the twelfth modification, when it is determined that there is a function that the user has used relatively frequently or infrequently, the suggestion unit 103 suggests a function screen of the function in the payment app. For example, the suggestion unit 103 suggests a function screen of the function that the user has used relatively frequently. When the suggestion is made immediately after the payment app is launched, the suggestion unit 103 suggests the function screen of the function by displaying a window W25 on the home screen SC2 when the payment app is launched, the window W25 proposing the function that the user has used relatively frequently. Instead of displaying the window W25, the suggestion unit 103 may suggest the function screen of the function by displaying the screen itself of the function that the user has used relatively frequently (for example, if the user has used the points function relatively frequently, the home screen SC2 of the points function).

[0178] For example, the suggestion unit 103 may suggest a function screen of a function that the user has used relatively infrequently. When the suggestion is made immediately after the payment app is launched, the suggestion unit 103 suggests the function screen of the function by displaying a window W25 on the home screen SC2 when the payment app is launched, the window W25 suggesting the function that the user has used relatively infrequently. Instead of displaying the window W25, the suggestion unit 103 may suggest the function screen of the function by displaying the screen of the function that the user has used relatively infrequently (for example, if the user has not used the point function relatively often, the home screen SC2 of the point function).

[0179] The proposal system 1 of the modification 12 determines whether the proposal condition is satisfied by determining whether there is a function that the user has used relatively frequently or infrequently based on the operation information. If it is determined that there is a function that the user has used relatively frequently or infrequently, the proposal system 1 proposes a function screen of the function in the payment app. This allows the user to know the existence of functions that the user has used relatively frequently or infrequently, and therefore the proposal system 1 can improve user convenience.

[0180] [6-13. Variation 13] For example, in Modifications 11 and 12, operation information acquisition unit 108 may acquire operation information related to a user operation just before the payment app is closed. Modification 13 takes as an example a case where the operation information indicates a function selected by a user just before the payment app is closed. For example, the operation information may be a payment method selected by a user just before the payment app is closed, or may indicate that a point function was selected by a user just before the payment app is closed. User terminal 20 records a history of user operations performed while the payment app is running in storage unit 22, and when the payment app is closed, transmits operation information indicating the last operation performed to payment server 10.

[0181] For example, the operation information acquisition unit 108 acquires operation information indicating a user operation just before the payment app is terminated by receiving operation information from the user terminal 20. The user terminal 20 may transmit operation information to the payment server 10 every time the user performs some operation, and the operation information acquisition unit 108 may acquire, as operation information regarding a user operation just before the payment app is terminated, operation information acquired just before receiving a notification from the user terminal 20 indicating that the payment app has been terminated.

[0182] The determination unit 102 of the thirteenth modification determines whether or not the proposed conditions are satisfied based on the last operation indicated by the operation information. For example, the determination unit 102 determines whether or not the proposed conditions for the payment method are satisfied based on the payment method indicated by the operation information. The suggestion unit 103 suggests a payment function screen for the payment method selected by the user just before closing the payment app. For example, if the operation information indicates that the payment method selected by the user just before closing the payment app is a credit card, the suggestion unit 103 suggests the credit card payment function the next time the payment app is launched. If the operation information indicates that the user selected a points function just before closing the payment app, the suggestion unit 103 suggests the points function the next time the payment app is launched.

[0183] The proposed system 1 of the modification 13 acquires operation information regarding a user's operation just before the payment app is closed. The proposed system 1 determines whether the proposed conditions are satisfied based on the last operation indicated by the operation information. This allows the user to know the function corresponding to the last operation of the payment app, thereby improving user convenience.

[0184] [6-14. Variation 14] For example, as described in the embodiment, the multiple functions may include a point function in which points are used. In this case, the determination unit 102 may determine whether the proposal condition is satisfied by determining whether limited-time points that can be used in the point function have been granted to the user. Limited-time points are points with a set expiration date. For example, limited-time points are granted to a user by using a payment service or a service other than the payment service. The mechanism for granting limited-time points may be similar to that of known point services.

[0185] In Modification 14, information indicating the presence or absence of limited-time points is stored in point database DB2. Determination unit 102 determines whether or not limited-time points have been granted to the user based on the information stored in point database DB2. If determination unit 102 determines that the user has not been granted limited-time points that can be used in the point function, it may not determine that the proposal condition is met, but if determination unit 102 determines that the user has been granted limited-time points that can be used in the point function, it may determine that the proposal condition is met.

[0186] FIG. 15 is a diagram showing an example of a screen displayed on user terminal 20 in Modification 14. Suggestion unit 103 in Modification 14 proposes a function screen of the point function in the payment app when it is determined that limited-time points have been awarded to the user. Suggestion unit 103 proposes a function screen of the point function in the payment app on the condition that it is determined that limited-time points have been awarded to the user. In the example of FIG. 15, suggestion unit 103 proposes the function screen of the point function by displaying home screen SC2 of the point function together with the balance of limited-time points. When it is not determined that limited-time points have been awarded to the user, suggestion unit 103 does not propose a function screen of the point function in the payment app.

[0187] The proposed system 1 of the modification 14 determines whether the proposal condition is satisfied by determining whether the user has been granted time-limited points that can be used in the point function. When it is determined that the time-limited points have been granted to the user, the proposed system 1 proposes a function screen of the point function in the payment app. This makes it easier for the user to notice the time-limited points, and the proposed system 1 can more easily prevent the time-limited points from expiring without the user realizing their existence.

[0188] [6-15. Other variations] For example, the above modifications may be combined.

[0189] For example, the functions described as being realized by the payment server 10 may be realized by the user terminal 20 or another computer. The functions described as being realized by the payment server 10 may be shared among multiple computers. For example, if a server computer for a point service exists separate from the payment server 10, the functions described as being realized by the payment server 10 may be realized by the server computer for the point service. The functions may be shared between the payment server 10 and the server computer for the point service.

[0190] [7. Notes] For example, the proposed system 1 can also be configured as follows.

[0191] (1) a determination unit that determines whether a proposal condition regarding a proposal of a function screen for providing a function to be proposed among a plurality of functions included in a payment application stored in the user terminal is satisfied; a proposal unit that proposes the functional screen in the payment app when it is determined that the proposal condition is satisfied; A proposal system including: (2) the function screen is a status function screen for providing a function that can be used by a user when the payment application is in a predetermined status, among the plurality of functions; the determination unit determines whether the payment application is in the predetermined state, thereby determining whether the proposal condition is satisfied; the suggestion unit suggests the status function screen in the payment app when it is determined that the payment app is in the predetermined status; The proposed system described in (1). (3) the status function screen is a communication status function screen for providing a function that can be used by the user when the communication status of the payment application is a predetermined communication status, among the plurality of functions; the determination unit determines whether the communication status of the payment application is the predetermined communication status, thereby determining whether the payment application is in the predetermined status; the suggestion unit suggests the communication status function screen in the payment app when it is determined that the communication status of the payment app is the predetermined communication status. (2) The proposed system described above. (4) the communication status function screen is an offline function screen for providing a function that can be used by the user when the communication status of the payment application is offline, among the plurality of functions; the determination unit determines whether the communication status of the payment application is the predetermined status by determining whether the communication status of the payment application is offline; the suggestion unit suggests the offline function screen in the payment app when it is determined that the communication status of the payment app is offline. The proposed system described in (3). (5) the status function screen is a launch source function screen for providing the functions available to the user when the payment application is launched due to a predetermined launch source, the determination unit determines whether the payment app is in the predetermined state by determining whether the payment app has been started due to the start-up source; the suggestion unit, when it is determined that the payment app has been launched due to the launch source, suggests the launch source function screen in the payment app; The proposed system according to any one of (2) to (4). (6) the function screen is a payment-related function screen for providing a payment-related function related to a payment executed from the payment app, among the plurality of functions; The proposed system further includes a history information acquisition unit that acquires history information regarding a history of the payment executed by the payment-related function, The determination unit determines whether the proposal condition is satisfied based on the history information; the suggestion unit suggests the payment-related function screen in the payment app when it is determined that the suggestion condition is satisfied; A proposal system according to any one of (1) to (5). (7) The history information indicates the execution status of the settlement for a predetermined period of time, the determination unit determines whether the execution status of the settlement indicated by the history information is a predetermined status, thereby determining whether the proposal condition is satisfied; the suggestion unit suggests the payment-related function screen in the payment app when it is determined that the execution status of the payment indicated by the history information is the predetermined status. (6) The proposed system described above. (8) The proposed system comprises: a location information acquisition unit that acquires location information relating to a user's location; a facility estimation unit that estimates a facility where the user is located based on the location information; Further comprising: the history information indicates the payment-related functions that the user has used in the past; the determination unit determines whether the proposal condition is satisfied by determining whether the user has used the payment-related function at the facility in the past based on the history information; the suggestion unit, when it is determined that the user has used one of the payment-related functions at the facility in the past, suggests, in the payment app, the payment-related function screen of the payment-related function; The proposed system according to (6) or (7). (9) The history information indicates the payment-related functions that the user has used in the past, the determination unit determines whether the proposal condition is satisfied by determining whether there is a payment-related function that the user has relatively not used, based on the history information; the suggestion unit, when it is determined that there is a payment-related function that is relatively unused by the user, suggests the payment-related function screen of the payment-related function in the payment app; The proposed system according to any one of (6) to (8). (10) the function screen is a payment-related function screen for providing a payment-related function related to a payment executed from the payment app, among the plurality of functions; The proposed system further includes a usage information acquisition unit that acquires usage information regarding the use of the payment-related function when the payment-related function is used, The determination unit determines whether the proposal condition is satisfied based on the usage information; the suggestion unit suggests the payment-related function screen in the payment app when it is determined that the suggestion condition is satisfied; A proposed system according to any one of (1) to (9). (11) The plurality of functions include, as the payment-related functions, a point function in which points are used and a payment function in which a payment method different from the points is used, the usage information acquisition unit acquires the usage information capable of identifying one of the point function and the payment function when the other of the point function and the payment function is used; The determination unit determines whether the proposal condition for the other of the point function and the payment function is satisfied based on the usage information, the proposal unit, when it is determined that the proposal condition of the other party is satisfied, proposes the payment-related function screen of the other party in the payment app; (10) The proposed system described above. (12) The proposed system comprises: a location information acquisition unit that acquires location information relating to a user's location; a facility estimation unit that estimates a facility where the user is located based on the location information; Further comprising: the determination unit determines whether the other of the services is available at the facility, thereby determining whether the proposal condition of the other of the services is satisfied; the suggestion unit, when it is determined that the other of the payment methods is available at the facility, suggests the payment-related function screen of the other of the payment methods in the payment app; The proposed system according to (11). (13) the plurality of functions include a payment function using a balance and a charging function of the balance, and the determination unit determines whether the proposal condition is satisfied by determining whether the balance is less than a threshold value; the suggestion unit suggests the function screen of the charge function in the payment app when it is determined that the balance is less than a threshold value; A proposed system according to any one of (1) to (12). (14) The proposed system comprises: a location information acquisition unit that acquires location information relating to a user's location; a facility estimation unit that estimates a facility where the user is located based on the location information; Further comprising: the determination unit determines whether the function to be proposed is available in the facility, thereby determining whether the proposal condition is satisfied; the suggestion unit suggests the payment-related function screen in the payment app when it is determined that the proposed function is available in the facility. A proposal system according to any one of (1) to (13). (15) The proposed system further includes an operation information acquisition unit that acquires operation information regarding a user's operation in the payment app, The determination unit determines whether the proposal condition is satisfied based on the operation information. A proposal system according to any one of (1) to (14). (16) the determination unit determines whether the proposal condition is satisfied by determining whether there is a function that the user has used relatively frequently or rarely, based on the operation information; the suggestion unit, when it is determined that there is a function that has been used relatively frequently or rarely by the user, suggests the function screen of the function in the payment app; (15) The proposed system according to (15). (17) the operation information acquisition unit acquires the operation information regarding an operation of the user immediately before the payment application is terminated; the determination unit determines whether the proposal condition is satisfied based on the latest operation indicated by the operation information. (15) The proposed system according to (15). (18) the plurality of functions includes a point function in which points are used, the determination unit determines whether or not the proposal condition is satisfied by determining whether or not time-limited points that can be used in the point function have been granted to the user; the suggestion unit suggests the function screen of the point function in the payment app when it is determined that the time-limited points have been granted to the user. A proposal system according to any one of (1) to (17). [Explanation of symbols]

[0192] 1 Proposed system, N network, 10 Payment server, 11, 21 Control unit, 12, 22 Memory unit, 13, 23 Communication unit, 20 User terminal, 24 Operation unit, 25 Display unit, 100 Data storage unit, 101 Function provision unit, 102, 201 Determination unit, 103, 202 Proposal unit, 104 History information acquisition unit, 105 Location information acquisition unit, 106 Facility estimation unit, 107 Usage information acquisition unit, 108 Operation information acquisition unit, 200 Data storage unit, B22, B23, B41 Button, C20 Payment code, C24 Point code, DB1 Payment database, DB2 Point database, I10, I11, I30, I31 Icon, SC1 Menu screen, SC2 Home screen, SC3 Launch screen, SC4 Payment completion screen, T21 Tab, W25 Window, W40 Window, B250,B251 buttons.

Claims

1. a determination unit that determines whether a proposal condition regarding a proposal of a function screen for providing a function to be proposed among a plurality of functions included in a payment application stored in the user terminal is satisfied; a proposal unit that proposes the functional screen in the payment app when it is determined that the proposal condition is satisfied; A proposal system including:

2. the function screen is a status function screen for providing a function that can be used by a user when the payment application is in a predetermined status, among the plurality of functions; the determination unit determines whether the payment application is in the predetermined state, thereby determining whether the proposal condition is satisfied; the suggestion unit suggests the status function screen in the payment app when it is determined that the payment app is in the predetermined status; The recommendation system of claim 1 .

3. the status function screen is a communication status function screen for providing a function that can be used by the user when the communication status of the payment application is a predetermined communication status, among the plurality of functions; the determination unit determines whether the communication status of the payment application is the predetermined communication status, thereby determining whether the payment application is in the predetermined status; the suggestion unit suggests the communication status function screen in the payment app when it is determined that the communication status of the payment app is the predetermined communication status. The proposal system of claim 2 .

4. the communication status function screen is an offline function screen for providing a function that can be used by the user when the communication status of the payment application is offline, among the plurality of functions; the determination unit determines whether the communication status of the payment application is the predetermined status by determining whether the communication status of the payment application is offline; the suggestion unit suggests the offline function screen in the payment app when it is determined that the communication status of the payment app is offline. The proposal system of claim 3 .

5. the status function screen is a launch source function screen for providing the function available to the user when the payment application is launched due to a predetermined launch source, the determination unit determines whether the payment app is in the predetermined state by determining whether the payment app has been launched due to the launch source; the suggestion unit, when it is determined that the payment app has been launched due to the launch source, suggests the launch source function screen in the payment app; A proposal system according to any one of claims 2 to 4.

6. the function screen is a payment-related function screen for providing a payment-related function related to a payment executed from the payment app, among the plurality of functions; The proposed system further includes a history information acquisition unit that acquires history information regarding a history of the payment executed by the payment-related function, The determination unit determines whether the proposal condition is satisfied based on the history information; the suggestion unit suggests the payment-related function screen in the payment app when it is determined that the suggestion condition is satisfied; A proposal system according to any one of claims 1 to 4.

7. The history information indicates the execution status of the settlement for a predetermined period of time, the determination unit determines whether the execution status of the settlement indicated by the history information is a predetermined status, thereby determining whether the proposal condition is satisfied; the suggestion unit suggests the payment-related function screen in the payment app when it is determined that the execution status of the payment indicated by the history information is the predetermined status. The proposal system of claim 6.

8. The proposed system comprises: a location information acquisition unit that acquires location information relating to a user's location; a facility estimation unit that estimates a facility where the user is located based on the location information; Further comprising: the history information indicates the payment-related functions that the user has used in the past; the determination unit determines whether the proposal condition is satisfied by determining whether the user has used the payment-related function at the facility in the past based on the history information; the suggestion unit, when it is determined that the user has used one of the payment-related functions at the facility in the past, suggests, in the payment app, the payment-related function screen of the payment-related function; The proposal system of claim 6.

9. The history information indicates the payment-related functions that the user has used in the past, the determination unit determines whether the proposal condition is satisfied by determining whether there is a payment-related function that the user has relatively not used, based on the history information; the suggestion unit, when it is determined that there is a payment-related function that is relatively unused by the user, suggests, in the payment app, the payment-related function screen of the payment-related function; 7. The proposal system according to claim 6.

10. the function screen is a payment-related function screen for providing a payment-related function related to a payment executed from the payment app, among the plurality of functions; The proposed system further includes a usage information acquisition unit that acquires usage information regarding the use of the payment-related function when the payment-related function is used, The determination unit determines whether the proposal condition is satisfied based on the usage information; the suggestion unit suggests the payment-related function screen in the payment app when it is determined that the suggestion condition is satisfied; A proposal system according to any one of claims 1 to 4.

11. The plurality of functions include, as the payment-related functions, a point function in which points are used and a payment function in which a payment method different from the points is used, the usage information acquisition unit acquires the usage information capable of identifying one of the point function and the payment function when the other of the point function and the payment function is used; The determination unit determines whether the proposal condition for the other of the point function and the payment function is satisfied based on the usage information, the proposal unit, when it is determined that the proposal condition of the other party is satisfied, proposes the payment-related function screen of the other party in the payment app; The recommendation system of claim 10.

12. The proposed system comprises: a location information acquisition unit that acquires location information relating to a user's location; a facility estimation unit that estimates a facility where the user is located based on the location information; Further comprising: the determination unit determines whether the other of the services is available at the facility, thereby determining whether the proposal condition of the other of the services is satisfied; the suggestion unit, when it is determined that the other of the payment methods is available at the facility, suggests the payment-related function screen of the other of the payment methods in the payment app; The recommendation system of claim 11.

13. The plurality of functions include a payment function using a balance and a charging function of the balance, the determination unit determines whether the balance is less than a threshold value, thereby determining whether the proposal condition is satisfied; the suggestion unit suggests the function screen of the charge function in the payment app when it is determined that the balance is less than a threshold value; A proposal system according to any one of claims 1 to 4.

14. The proposed system comprises: a location information acquisition unit that acquires location information relating to a user's location; a facility estimation unit that estimates a facility where the user is located based on the location information; Further comprising: the determination unit determines whether the function to be proposed is available in the facility, thereby determining whether the proposal condition is satisfied; the suggestion unit suggests the function screen in the payment app when it is determined that the proposed function is available in the facility. A proposal system according to any one of claims 1 to 4.

15. The proposed system further includes an operation information acquisition unit that acquires operation information regarding a user's operation in the payment app, The determination unit determines whether the proposal condition is satisfied based on the operation information. A proposal system according to any one of claims 1 to 4.

16. the determination unit determines whether the proposal condition is satisfied by determining whether there is a function that the user has used relatively frequently or rarely, based on the operation information; the suggestion unit, when it is determined that there is a function that has been used relatively frequently or rarely by the user, suggests the function screen of the function in the payment app; The recommendation system of claim 15.

17. the operation information acquisition unit acquires the operation information regarding an operation of the user immediately before the payment application is terminated; the determination unit determines whether the proposal condition is satisfied based on the latest operation indicated by the operation information. The recommendation system of claim 15.

18. the plurality of functions includes a point function in which points are used, the determination unit determines whether or not the proposal condition is satisfied by determining whether or not time-limited points that can be used in the point function have been granted to the user; the suggestion unit suggests the function screen of the point function in the payment app when it is determined that the time-limited points have been granted to the user. A proposal system according to any one of claims 1 to 4.

19. a determination step of determining whether or not a proposal condition regarding the proposal of a function screen for providing a function to be proposed among a plurality of functions possessed by a payment application stored in the user terminal is satisfied; a proposal step of proposing the functional screen in the payment application when it is determined that the proposal condition is satisfied; The proposed method includes:

20. a determination unit that determines whether or not a proposal condition regarding the proposal of a function screen for providing a function to be proposed among a plurality of functions included in the payment application stored in the user terminal is satisfied; a proposal unit that proposes the functional screen in the payment application when it is determined that the proposal condition is satisfied; A program that allows a computer to function as a

Images