Information processing device, information processing method and program

Abstract

To provide an information processing device and propose an optimal financial service to users from a wide range of financial services.SOLUTION: An information processing device includes: an acquisition unit for acquiring input information input by a user on a settlement application installed on a user terminal device; a calculation unit for calculating, on the basis of the input information, for each of a plurality of financial services, a profit that the user will receive by using a financial service; and a display control unit causing the settlement application to display proposal information for proposing the user to use the financial service on the basis of the profit.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to an information processing device, an information processing method, and a program. [Background technology]

[0002] Conventionally, there is known a technology that makes some kind of proposal to a user on a payment app that operates in conjunction with an electronic payment service. For example, Patent Document 1 discloses a technology that proposes to a user to purchase insurance based on payment information related to an electronic payment executed by the user. [Prior art documents] [Patent documents]

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

[0004] However, in the conventional technology, the information used for proposals was limited to payment information, and the proposed items were limited to insurance. As a result, it was sometimes impossible to propose the most suitable financial service to a user of a payment app from a wide range of financial services.

[0005] The present invention has been made taking these circumstances into consideration, and one of its objectives is to provide an information processing device, an information processing method, and a program that can propose the most suitable financial service to a user of a payment app from a wide range of financial services. [Means for solving the problem]

[0006] One aspect of the present invention is an information processing device that includes an acquisition unit that acquires input information entered by a user on a payment app installed on a user terminal device, a calculation unit that calculates, based on the input information, the gain that the user will gain from using each of a plurality of financial services, and a display control unit that displays, on the payment app, proposal information that suggests the user to use the financial service based on the gain. [Effects of the Invention]

[0007] According to one aspect of the present invention, it is possible to provide an information processing device, an information processing method, and a program that can propose the most suitable financial service to a user who uses a payment app from a wide range of financial services. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a diagram illustrating an example of a configuration for realizing an electronic payment service. [Figure 2] This is a sequence diagram (part 1) illustrating the general flow of electronic payment. [Figure 3] This is a sequence diagram (part 2) illustrating the general flow of electronic payment. [Figure 4] FIG. 2 is a configuration diagram of a payment server 100 according to the first embodiment. [Figure 5] FIG. 10 is a diagram showing an example of the contents of user information 172. [Figure 6] FIG. 10 is a diagram showing an example of the contents of affiliated store / store information 176. [Figure 7] FIG. 10 is a diagram showing an example of a top screen IM of the payment application 20. [Figure 8] FIG. 10 is a diagram showing an example of a wallet screen displayed in response to operation of the wallet button WA. [Figure 9] 10 is a diagram showing an example of suggested information regarding the use of payment application 20. FIG. [Figure 10] FIG. 10 is a diagram showing another example of suggested information regarding the use of payment application 20. [Figure 11]FIG. 10 is a diagram showing another example of suggested information regarding the use of payment application 20. [Figure 12] FIG. 10 is a diagram showing another example of suggested information regarding the use of payment application 20. [Figure 13] FIG. 10 is a diagram showing another example of suggested information regarding the use of payment application 20. [Figure 14] FIG. 10 is a diagram showing an example of suggested information that is displayed when user information 172 satisfies a predetermined condition. [Figure 15] FIG. 10 is a diagram showing another example of suggested information that is displayed when the user information 172 satisfies a predetermined condition. [Figure 16] FIG. 10 is a diagram showing another example of suggested information that is displayed when the user information 172 satisfies a predetermined condition. [Figure 17] 10 is a flowchart showing an example of the flow of processing executed by the information management unit 140. [Figure 18] 10 is a flowchart showing another example of the flow of processing executed by the information management unit 140. DETAILED DESCRIPTION OF THE INVENTION

[0009] Hereinafter, with reference to the drawings, embodiments of an information processing device, an information processing method, and a program according to the present invention will be described. Various devices, such as a "server" and an "information processing device," that provide services to users or perform internal analysis, may be implemented as a group of distributed devices, and each device may be operated by a different business. Furthermore, the hardware owner (the cloud server provider) and the business that actually operates the device may also be different. An application program and a payment server work together to provide an electronic payment service. In the following description, the application program is referred to as a "payment app." An electronic payment service is a service that supports payments for the purchase of goods and services at a store. A store is, for example, a physical store (real-world store) that exists in the real world, but may also include a virtual store for e-commerce transactions. A virtual store may also include a store operated by an entity other than the operator of the electronic payment service. In such a case, when making a payment for a purchase at the virtual store, the user is controlled to transition to the interface screen of the electronic payment service. In an electronic payment service, a store is treated as belonging to, for example, an affiliated store (brand), and when a purchase is made at a store, processing such as payment is primarily conducted between the user and the affiliated store. Alternatively, processing such as payment may be carried out between the user and the store.

[0010] [Electronic payment service] Figure 1 shows an example of a configuration for realizing an electronic payment service. The electronic payment service is realized mainly by a payment server 100. The payment server 100 communicates with, for example, one or more user terminal devices 10, one or more first store terminal devices 50, and one or more second store terminal devices 70 via a network NW. The network NW includes, for example, the Internet, a LAN (Local Area Network), a wireless base station, a provider device, etc.

[0011] The user terminal device 10 is, for example, a portable terminal device such as a smartphone or tablet terminal. The user terminal device 10 is a computer device having at least an optical reading function, a communication function, a display function, an input acceptance function, and a program execution function. In the following description, components for realizing these functions are referred to as a camera, a communication device, a touch panel, a CPU (Central Processing Unit), etc. In the user terminal device 10, a processor such as a CPU executes a payment app 20, which operates in cooperation with the payment server 100 to provide electronic payment services to users. The payment app 20 is installed on the user terminal device 10 from, for example, an application store, and controls the camera, communication device, touch panel, etc.

[0012] The first store terminal device 50 is installed, for example, in a store. The first store terminal device 50 is a computer device having at least a product price acquisition function, an optical reading function, a program execution function, and a communication function. The first store terminal device 50 includes a so-called POS (Point of Sale) device, and the product price acquisition function and the optical reading function may be realized by the POS device. The store code image 60 is placed in the store and is a code image such as a QR code (registered trademark) printed on a paper or plastic medium. The store code image 60 may be displayed on a display placed in the store (which may be the display of a terminal device such as a smartphone).

[0013] The second store terminal device 70 is used by the operator of the affiliated store. The second store terminal device 70 is a smartphone, tablet terminal, personal computer, etc. An interface for affiliated stores 72 runs on the second store terminal device 70. The interface for affiliated stores 72 may be an app for affiliated stores or a browser. The interface for affiliated stores 72 accepts coupon settings and the like from the operator of the affiliated store and transmits them to the payment server 100. The second store terminal device 70, which is a smartphone, has the function of displaying a code image corresponding to a store code image and reading the code image displayed by the user terminal device 10 by executing the app for affiliated stores.

[0014] The payment server 100 realizes electronic payment based on payment information received from the user terminal device 10 or the first store terminal device 50. The first store terminal device 50 may include a POS device and an affiliated store server, in which case payment information is sent from the POS device via the affiliated store server to the payment server 100. In the following explanation, this distinction will not be made and it is assumed that payment information is sent from the first store terminal device 50.

[0015] 2 and 3 are sequence diagrams illustrating the general flow of electronic payment. There may be two patterns for electronic payment: Pattern 1 and Pattern 2.

[0016] In the case of pattern 1 (hereinafter referred to as user scan) shown in FIG. 2, the user terminal device 10, with the payment application 20 running, decodes the store code image 60 using its optical reading function (S1). The store code image 60 includes store URL (Uniform Resource Locator) information. This store URL is the domain of the electronic payment service to which store identification information has been added, and is associated with an affiliated store ID, store ID, etc. in the payment server 100 (described below). The payment application 20 sends first payment information including the store URL and account ID to the payment server 100 (S2). The payment server 100 searches for store information (described below) using the affiliated store ID and store ID corresponding to the store URL, acquires the affiliated store name and store name information (S3), and sends this to the payment application 20 (S4). The user enters the payment amount into the user terminal device 10 on the screen displaying the affiliated store name and store name (S5). Then, the user terminal device 10 generates second payment information including at least the payment amount and sends it to the payment server 100 (S6). The payment server 100 makes the electronic payment based on the received second payment information (S7). The payment server 100 then sends a payment completion notice (information for displaying a payment completion screen) to the payment app 20 (S8), and the payment app 20 displays the payment completion screen (S9). Note that when the store code image 60 is displayed on a display installed in the store, the store code image 60 may include information on the payment amount in addition to the store URL. In this case, the step of the user inputting the payment amount is omitted, and the payment amount information is included in the first payment information and sent to the payment server 100. Information on the affiliated store name and store name may be included and displayed on the payment completion screen.

[0017] In the case of pattern 2 (hereinafter referred to as store scan) shown in FIG. 3, the payment app 20 sends a request to issue a one-time code to the payment server 100 when the payment app 20 is launched, when a payment operation is performed in the payment app 20, at the automatic update timing (e.g., every minute), and at other timings (S11). The payment server 100 generates a one-time code (S12) and sends it to the payment app 20 (S13). The payment app 20 displays a code image, such as a QR code or barcode, generated based on the one-time code (S14). The user holds (presents) the display surface of the user terminal device 10 over the first in-store terminal device 50, and the first in-store terminal device 50 decodes the code image using its optical reading function and obtains the one-time code, etc. (S15). The first in-store terminal device 50 then generates payment information including the one-time code, payment amount, affiliated store ID, store ID, etc., and sends it to the payment server 100 (S16). The payment amount information is acquired in advance by reading a barcode, manually entering it, etc. Based on the received information, the payment server 100 identifies the user corresponding to the one-time code and performs electronic payment (S17). Then, the payment server 100 sends a payment completion notice to the payment application 20 (S18), and the payment application 20 displays a payment completion screen (S19).

[0018] Note that electronic payment may be performed using only one of the above patterns. Furthermore, the "account ID" described in FIG. 2 may be other information (e.g., a phone number) that can be used as user identification information. Furthermore, issuing a one-time code may be omitted in store scanning, and the payment application 20 may display a code image generated based on the user's account ID. In this case, the payment server 100 identifies the user corresponding to the account ID instead of identifying the user corresponding to the one-time code.

[0019] [Payment server] FIG. 4 is a configuration diagram of the payment server 100 according to the first embodiment. The payment server 100 includes, for example, a communication unit 110, a payment content providing unit 120, a payment processing unit 130, an information management unit 140, and a storage unit 170. The components other than the communication unit 110 and the storage unit 170 are implemented by, for example, a hardware processor such as a CPU executing a program (software). Some or all of these components may be implemented by hardware (including circuitry) such as a large-scale integration (LSI), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a graphics processing unit (GPU), or may be implemented by a combination of software and hardware. The program may be stored in advance in a storage device (a storage device with a non-transitory storage medium) such as a hard disk drive (HDD) or flash memory, or may be stored in a removable storage medium (a non-transitory storage medium) such as a DVD or CD-ROM, and installed in the storage device by inserting the storage medium into a drive device.

[0020] The storage unit 170 is a HDD, flash memory, RAM (Random Access Memory), etc. The storage unit 170 may be a NAS (Network Attached Storage) device that the payment server 100 can access via a network. The storage unit 170 stores information such as user information 172, payment content information 174, affiliated store / shop information 176, and simulation reference information 178.

[0021] The communication unit 110 is a communication interface for connecting to the network NW, and is, for example, a network interface card.

[0022] The payment content providing unit 120 has, for example, a function of a web server, and provides information (content) for displaying various screens of the electronic payment service to the user terminal device 10. The payment content providing unit 120 reads out necessary content from the payment content information 174 as appropriate and provides it to the user terminal device 10. The user terminal device 10 accepts various inputs from the user while content is being played by the payment application 20, and transmits the above-mentioned payment information and the like to the payment server 100.

[0023] The payment processing unit 130 performs payment processing based on the payment information transmitted by the user terminal device 10 or the first store terminal device 50. The payment processing unit 130 performs payment processing while referring to the user information 172.

[0024] FIG. 5 is a diagram showing an example of the contents of user information 172. User information 172 is an example of user registration information. User information 172 includes, for example, a user URL, account ID, telephone number, and password, as well as email address, user ID, name, address, date of birth, registration date, charge balance, credit card payment settings, credit card limit, credit card payment amount, available credit card payment amount, payment method settings, bank account, credit card number, points held, charge history information, payment history information, and operation history information. The user URL is used for remittance processing between users. Registration of a telephone number and password is required when registering for an electronic payment service. The account ID is issued to the user by the payment server 100, and the user ID can be set by the user (or does not have to be set). The email address, name, address, and date of birth are also information that can be set by the user (or do not have to be set). The registration date is the date on which the user registered for the electronic payment service (the date on which the account was created). Hereinafter, the user's instance (electronic payment account) to which this information is associated will be referred to as an account.

[0025] The charge balance indicates the balance of electronic money set by the user by transferring funds to the account in advance. Transfer methods include transfers from a designated bank's ATM (Automatic Teller Machine) or from a registered bank account. The credit payment setting indicates whether the settings for electronic credit payment have been completed and is set to either "Completed" or "Not Completed." The credit payment limit is the monthly credit payment limit. The credit payment amount is the amount of credit payment already used in the current month. The available credit payment amount is the amount of credit payment available in the current month, calculated by subtracting the credit payment amount from the credit payment limit. While the figure shows only one credit payment limit, in reality, there may also be daily limits, and the lower of these may be set as the credit payment limit. Further details on credit payments will be discussed later. The payment method setting indicates whether the user will currently make electronic payments using the charge balance or by credit payment. The bank account and credit card number are information on the bank account or credit card number (account number, card number) that can be used to deposit funds into the electronic payment service. The charge history information is a history of the user transferring funds to the electronic payment service in advance to increase the charge balance. The payment history information is information that shows the details of the payment made by the user for each payment (date and time, store ID of the store where the purchase was made, payment amount, payment method, etc.). The operation history information is history information that records the buttons pressed by the user on the screen displayed by the payment app 20, the pages to which the user was redirected, etc.

[0026] 6 is a diagram showing an example of the contents of affiliated store / store information 176. The affiliated store / store information 176 includes, for example, a first table 176A in which an affiliated store ID and a store ID are associated with a store URL, a second table 176B in which an affiliated store ID is associated with an affiliated store name, sales amount (described above), and category, and a third table 176C in which a store ID is associated with a store name. In addition to this information, the affiliated store / store information 176 may also include information such as the location of the affiliated store or store, payment patterns, etc.

[0027] The information management unit 140 manages the user information 172 and the affiliated store / store information 176 based on information acquired from the user terminal device 10 and the second store terminal device 70. The information management unit 140 adds new records to, edits, deletes, etc. the user information 172 and the affiliated store / store information 176.

[0028] The information management unit 140 further includes, as functional units, an acquisition unit 142, a calculation unit 144, and a display control unit 146. Using these functional units, the information management unit 140 generates proposal information related to a plurality of financial services (described later), transmits the information to the user terminal device 10, and displays it on the payment application 20. The functions of the acquisition unit 142, calculation unit 144, and display control unit 146 will be described in detail below. The function of the information management unit 140 in the payment server 100 is an example of an "information processing device" in the claims. The information management unit 140 may be configured as a server device separate from the payment server 100, or the functions of the acquisition unit 142, calculation unit 144, and display control unit 146 (described later) may be incorporated into the payment application 20.

[0029] [Electronic Payment] When payment information is acquired from the user terminal device 10 or the first store terminal device 50, the payment processing unit 130 references the user information 172 to acquire the "payment method setting" of the user. For users whose "payment method setting" is set to "charge balance," the payment processing unit 130 performs electronic payment as follows: For example, the payment processing unit 130 performs electronic payment by decreasing the charge balance managed in association with the user ID and increasing the item value of the affiliated store's sales proceeds. The item value of the affiliated store's sales proceeds is not itself used as electronic money, for example, but rather the amount corresponding to the item value of the sales proceeds is transferred to a bank account in a cycle according to an agreement between the affiliated store and the electronic payment service.

[0030] The payment processing unit 130 performs electronic payments for users whose "setting information" is set to "credit payment" as follows. Credit payment is set separately from "credit payment" in cooperation with a credit card company, which is a separate entity from the operator of the electronic payment service. The operator of the electronic payment service acts as the creditor, and allows electronic payments within the credit payment limit, independent of the charge balance. To receive the credit payment service, a user may be required to obtain a credit card provided by the operator of the electronic payment service. The amount used for credit payment is settled in full for one month on the payment date of the following month, for example, by debit from a bank account. In this case, the payment processing unit 130 makes a provisional settlement by adding the settlement amount to the credit payment amount and subtracting the same amount from the available credit payment balance. On the closing date, the payment processing unit 130 performs the process described above to debit the current month's payment on the payment date of the following month, or requests the operator of the credit card company to perform this process. If the settlement amount exceeds the available credit payment balance at the time of provisional settlement, an error notification is returned to the payment app 20.

[0031] Thereafter, the payment application 20 displays, as a payment completion screen, for example, the payment store, the payment amount, and the awarded bonus (points). For example, if a user makes a payment of 500 yen, the information management unit 140 stores 5 yen worth of points, which is equivalent to 1% of the payment amount, in the "owned points" field of the user information 172. The payment processing unit 130 then prioritizes deducting the owned points from the payment amount at the user's next electronic payment, and subtracts the remaining amount from the charge balance or the available amount for later payment. In another embodiment, the bonus may be deducted directly from the payment amount on the day, without being added as points available for payment.

[0032] [Top screen] FIG. 7 is a diagram showing an example of the top screen IM of the payment app 20. A code image CD is displayed on the top screen IM. The code image CD includes, for example, a barcode and a QR code. Text indicating whether to make electronic payment using the remaining balance or by credit card payment (in the figure, "Pay with remaining balance") is also displayed along with the code image CD. This text is drawn by the payment app 20 based on information updated by the payment app 20 each time the selector switch SW is operated. The top screen IM also includes an operation area CA including the selector switch SW and a transition button TB, which will be described later. Note that the "switch" and "button" refer to a graphical user interface (GUI) implemented in cooperation with a touch panel. The selector switch SW accepts an operation to switch between making electronic payment using the remaining balance and by credit card payment. The selector switch SW is set to make electronic payment using the remaining balance by default, and each time the user operates the selector switch SW, the setting switches between making electronic payment using the remaining balance and making electronic payment by credit card payment. In the figure, the explanation "Credit card payment" is displayed, which means that the setting is for electronic payment by credit card. The operation area CA has buttons for instructing the main operations in electronic payment, such as a button to instruct scanning (to start a user scan) and a button to instruct charging. When the transition button TB is operated, the screen transitions to a payment screen that displays the code image used for electronic payment and the available balance. Furthermore, when the wallet button WA is operated, the screen transitions to a wallet screen that displays a chronological list of the user's assets and electronic payment history information.

[0033] Below the operation area CA, a group of buttons (switches) M1 to M5 for launching mini apps are further displayed. Mini apps are apps that run using payment app 20 as a platform and provide some kind of service. Service providers develop mini apps by referencing a Software Development Kit (SDK), which is a program and technical documentation for app development provided by the administrator of payment app 20. Mini apps are apps that run while payment app 20 is running, for example. For example, some or all of the mini apps may be installed when payment app 20 is installed, or some or all of the mini apps may be installed from a service server corresponding to the mini app.

[0034] 7 shows, as an example, an asset management mini-app M1 that provides an asset management service that invests a user's charge balance in financial products such as stocks, investment trusts, and bonds, a donation mini-app M2 that provides a donation service that provides benefits such as goods or services or income deductions in exchange for donating at least a portion of the user's charge balance, an insurance mini-app M3 that provides insurance services provided by an operator of an electronic payment service, a banking mini-app M4 that provides banking services provided by an operator of an electronic payment service, and a mini-app M5 that provides credit card payment services provided by an operator of an electronic payment service. The asset management service, the donation service, the insurance service, the banking service, and the credit card payment service are examples of "financial services" within the scope of the claims.

[0035] [Wallet screen] FIG. 8 is a diagram showing an example of a wallet screen displayed in response to operation of the wallet button WA. The wallet screen includes, for example, an area AR1 for displaying asset information such as the user's available credit card payment balance, charge balance, and owned points, and an area AR2 for displaying the user's electronic payment history in chronological order. The wallet screen allows the user to grasp their current financial situation related to the payment app 20. In other words, a user viewing the wallet screen is interested in their own financial situation. Therefore, the display control unit 146 further displays, on the wallet screen, a button BT1 for transitioning to a screen displaying suggested information for improving the user's financial situation using the payment app 20, along with the above information. When the user presses button BT1, the payment app 20 transitions to a screen displaying suggested information regarding the use of the payment app 20. Button BT1 is an example of an "interface element" in the claims.

[0036] [Suggestions for using payment apps] Fig. 9 is a diagram showing an example of suggested information related to the use of payment application 20. The suggested information screen shown in Fig. 9 is displayed by payment application 20, for example, when button BT1 on the wallet screen shown in Fig. 8 is pressed. The suggested information screen includes, for example, a selection area SE1 for selecting a service for which suggested information is to be displayed, a display area AR3 for displaying an explanation prompting the user to enter input information corresponding to the selected service, an input area IN1 for accepting the input information, a display area AR4 for displaying the results of a simulation using the input information, and a button BT3 for transitioning to a dedicated page for the proposed service.

[0037] As shown in FIG. 9, when a user selects "Asset Management" from selection area SE1, display control unit 146 causes payment application 20 to display, for example, an explanatory text corresponding to "Asset Management" such as "Please enter your monthly investment amount" in display area AR3. Next, when the user confirms the content of the explanatory text and enters the investment amount in input area IN1, acquisition unit 142 acquires the investment amount entered by the user as input information. Next, calculation unit 144 calculates, by simulation, the profit that the user will make from using the asset management service based on the acquired input information.

[0038] In the case of an asset management service, the calculation unit 144 refers to performance information (e.g., yields) of financial products such as stocks, investment trusts (index funds, active funds), or bonds over a predetermined period in the past (e.g., 20 years) and calculates, as a profit, the investment income that would be obtained if the user invested the investable amount in installments or in a lump sum for a predetermined period. In this case, the performance information may be stored in advance in the settlement server 100 as simulation reference information 178, or may be stored in an external information distribution server and acquired by the calculation unit 144 by accessing it. Furthermore, the simulation by the calculation unit 144 may be performed by searching for a portfolio combination that will generate a higher profit based on performance information of the above-mentioned multiple financial products, rather than based on a single piece of performance information.

[0039] When the calculation unit 144 calculates the profit, the display control unit 146 causes the payment application 20 to display, in the display area AR4, proposal information that proposes to the user the use of an asset management service based on the calculated profit. In the case of an asset management service, the display control unit 146 causes the payment application 20 to display, for example, a message that by using the asset management service, there is a possibility of obtaining an investment return equivalent to the profit calculated by the calculation unit 144. When the user presses the button BT3, the display control unit 146 transitions the screen of the payment application 20 to the same service explanation page as when the asset management mini-app M1 shown in the top screen of FIG. 7 is pressed, for example.

[0040] FIG. 10 is a diagram showing another example of suggested information regarding the use of payment app 20. As shown in FIG. 10, when a user selects "Points" from selection area SE1, display control unit 146 causes payment app 20 to display, for example, an explanatory text corresponding to "Points," such as "Please enter your annual income," in display area AR3. Next, when the user confirms the content of the explanatory text and enters their annual income in input area IN1, acquisition unit 142 acquires the annual income entered by the user as input information. Next, calculation unit 144 calculates, by simulation, the gain that the user will make by using the donation service based on the acquired input information.

[0041] In the case of the donation service, the calculation unit 144 refers to, for example, correspondence information between annual income and the amount of points awarded corresponding to the upper limit donation amount eligible for tax deduction, and calculates, as the gain, the points to be acquired when the user donates an amount equivalent to the upper limit donation amount. In this case, the correspondence information may be stored in advance in the payment server 100 as simulation reference information 178, or may be stored in an external information distribution server and acquired by the calculation unit 144 by accessing it.

[0042] When the profit is calculated by the calculation unit 144, the display control unit 146 causes the payment app 20 to display, in the display area AR4, suggestion information that suggests to the user that the user use a donation service based on the calculated profit. In the case of a donation service, the display control unit 146 causes the payment app 20 to display, for example, a message that by using the donation service, the user may be able to obtain points equivalent to the profit calculated by the calculation unit 144. When the user presses the button BT3, the display control unit 146 transitions the screen of the payment app 20 to the same service explanation page as when the user presses the donation mini-app M2 shown on the top screen in FIG. 7, for example.

[0043] FIG. 11 is a diagram showing another example of suggested information related to the use of payment app 20. As shown in FIG. 11, when a user selects "Insurance" from selection area SE1, display control unit 146 causes payment app 20 to display, for example, an explanatory text corresponding to "Insurance" such as "Please enter your monthly life insurance premium" in display area AR3. Next, when the user confirms the content of the explanatory text and enters the monthly life insurance premium in input area IN1, acquisition unit 142 acquires the life insurance premium entered by the user as input information. Next, calculation unit 144 calculates, by simulation, the profit that the user will make from using the insurance service based on the acquired input information.

[0044] In the case of an insurance service, the calculation unit 144, for example, refers to price information of insurance provided by the company's insurance service and calculates the difference between the premium entered by the user and the lowest price of insurance provided by the company's insurance service as the profit. In this case, the insurance price information may be stored in advance in the payment server 100 as simulation reference information 178, or may be stored in an external information distribution server and acquired by the calculation unit 144 by accessing it.

[0045] When the profit is calculated by the calculation unit 144, the display control unit 146 causes the payment application 20 to display, in the display area AR4, suggestion information that suggests to the user that the user use an insurance service based on the calculated profit. In the case of an insurance service, the display control unit 146 causes the payment application 20 to display, for example, a message that the user may be able to save an amount equivalent to the profit calculated by the calculation unit 144 by using the insurance service. When the user presses the button BT3, the display control unit 146 causes the screen of the payment application 20 to transition to the same service explanation page as when the insurance mini-app M3 shown in the top screen of FIG. 7 is pressed, for example.

[0046] FIG. 12 is a diagram showing another example of suggested information regarding the use of payment app 20. As shown in FIG. 12, when a user selects "Bank" from selection area SE1, display control unit 146 causes payment app 20 to display, for example, an explanatory text corresponding to "Bank" such as "Please enter your current bank interest rate" in display area AR3. Next, when the user confirms the content of the explanatory text and enters the bank interest rate in input area IN1, acquisition unit 142 acquires the bank interest rate entered by the user as input information. Next, calculation unit 144 calculates, by simulation, the benefit that the user will receive from using bank services based on the acquired input information.

[0047] In the case of a banking service, the calculation unit 144, for example, refers to interest rate information on deposits provided by the company's banking service and calculates the difference between the bank interest rate entered by the user and the highest interest rate provided by the company's banking service as the profit. In this case, the interest rate information on deposits may be stored in advance in the payment server 100 as simulation reference information 178, or may be stored in an external information distribution server and accessed by the calculation unit 144.

[0048] When the profit is calculated by the calculation unit 144, the display control unit 146 causes the payment application 20 to display, in the display area AR4, suggestion information that suggests to the user that the user use a bank service based on the calculated profit. In the case of a bank service, the display control unit 146 causes the payment application 20 to display, for example, a message that by using the bank service, the user may earn an interest rate equivalent to the profit calculated by the calculation unit 144. When the user presses the button BT3, the display control unit 146 transitions the screen of the payment application 20 to the same service explanation page as when the user presses the bank mini-app M4 shown in the top screen of FIG. 7, for example.

[0049] FIG. 13 is a diagram showing another example of suggested information regarding the use of payment app 20. As shown in FIG. 13, when a user selects "Card" from selection area SE1, display control unit 146 causes payment app 20 to display, for example, a description corresponding to "Card" such as "Please enter the cashback rate of the card you are currently using" in display area AR3. Next, when the user confirms the content of the description and enters the cashback rate in input area IN1, acquisition unit 142 acquires the cashback rate entered by the user as input information. Next, calculation unit 144 calculates, by simulation, the profit that the user will make by using the credit card payment service based on the acquired input information.

[0050] In the case of a credit card payment service, the calculation unit 144 refers to, for example, credit card return rate information provided by the company's credit card payment service, and calculates the difference between the return rate entered by the user and the return rate provided by the company's credit card payment service as the profit. In this case, the return rate information may be stored in advance in the payment server 100 as simulation reference information 178, or may be stored in an external information distribution server and acquired by the calculation unit 144 by accessing it.

[0051] When the profit is calculated by calculation unit 144, display control unit 146 causes payment application 20 to display, in display area AR4, suggestion information that suggests to the user that the user use a credit card payment service based on the calculated profit. In the case of a credit card payment service, display control unit 146 causes payment application 20 to display, for example, a message that the user may benefit from using the credit card payment service by a return rate equivalent to the profit calculated by calculation unit 144. When the user presses button BT3, display control unit 146 transitions the screen of payment application 20 to the same service explanation page as when card mini application M5 shown on the top screen in FIG. 7 is pressed, for example.

[0052] In this way, when a user who is viewing the wallet screen and is assumed to be interested in their own financial situation presses button BT1, payment application 20 transitions the wallet screen to a screen displaying suggested information regarding the use of payment application 20. The user can then select a financial service of interest from among the multiple financial services presented and enter the necessary information to understand the benefits they can obtain. In other words, this allows the most suitable financial service for the user of the payment application to be proposed from a wide range of financial services.

[0053] In the above description, as an example, the display control unit 146 displays the button BT1 on the wallet screen among the various screens displayed by the payment application 20. However, the present invention is not limited to such a configuration, and the button BT1 may be displayed on any screen, such as the top screen, payment completion screen, or charge screen of the payment application 20.

[0054] [Proposal information according to specified conditions] The above description is about a user selecting a financial service that the user is interested in. In yet another embodiment, information management unit 140 may refer to user information 172 of the user to determine whether the user satisfies predetermined conditions, and if it is determined that the user satisfies the predetermined conditions, cause payment application 20 to display suggested information corresponding to the satisfied predetermined conditions. Specific examples of predetermined conditions will be described below.

[0055] FIG. 14 is a diagram showing an example of suggested information displayed when user information 172 satisfies a predetermined condition. As an example, acquisition unit 142 acquires charge history information from user information 172, and when it is determined that the user has charged a predetermined amount or more (or when it is determined that the user has charged a predetermined amount or more in a predetermined period), display control unit 146 causes payment app 20 to display button BT1, for example, on a charge completion screen, for transitioning to a screen displaying suggested information. When the user presses button BT1, as shown in the right part of FIG. 14, display control unit 146 causes payment app 20 to display suggested information related to asset management services. This is because it is assumed that a user who charges a predetermined amount or more is financially well off and has room to manage their assets. At this time, display control unit 146 may display suggested information with an amount equivalent to the charge amount automatically entered in input field IN1.

[0056] Note that the predetermined condition for measuring the user's financial leeway is not limited to the charge amount, and may be, for example, a condition related to the charge balance or the available credit payment amount. For example, the acquisition unit 142 acquires the charge balance or the available credit payment amount from the user information 172, and if the acquired charge balance or the available credit payment amount is equal to or greater than a predetermined amount, the display control unit 146 may cause the payment app 20 to display suggested information about asset management services. As another approach, on the assumption that a user with little savings desires to build assets, if the acquired charge balance or the available credit payment amount is equal to or less than a predetermined amount, the display control unit 146 may cause the payment app 20 to display suggested information about asset management services.

[0057] 15 is a diagram showing another example of suggested information that is displayed when user information 172 satisfies a predetermined condition. As an example, acquisition unit 142 acquires payment history information from user information 172, and when it is determined that the user has made an electronic payment at a store of an affiliated store that belongs to a certain category, display control unit 146 causes payment app 20 to display button BT1, for example, on a payment completion screen, for transitioning to a screen that displays suggested information. When the user presses button BT1, as shown on the right side of FIG. 15, display control unit 146 causes payment app 20 to display suggested information about insurance services that correspond to the category to which the affiliated store at which the electronic payment was made belongs.

[0058] For example, if a user makes an electronic payment at a store of an affiliated store belonging to the "Home Appliances" category, the display control unit 146 displays suggested information about non-life insurance for home appliances. This is because it is assumed that a user who makes an electronic payment at a store of an affiliated store belonging to the "Home Appliances" category is interested in purchasing non-life insurance that compensates for breakdowns in the purchased product. At this time, the display control unit 146 may display the suggested information with an amount equivalent to the payment amount automatically entered in the input field IN1. As another example, if a user makes an electronic payment at a store of an affiliated store belonging to the "Sports" category, the display control unit 146 may display suggested information about sports-related accident insurance. As another example, if a user makes an electronic payment at a store of an affiliated store belonging to the "Medical" category, suggested information about medical insurance may be displayed.

[0059] 16 is a diagram showing another example of suggested information displayed when user information 172 satisfies a predetermined condition. As an example, acquisition unit 142 acquires operation history information of user information 172, and when it is determined that the user has visited a dedicated page of an affiliated store belonging to a certain category (or when it is determined that the user has visited a dedicated page of an affiliated store belonging to a certain category a predetermined number of times or more within a predetermined period), display control unit 146 causes payment application 20 to display button BT1, for example, on the dedicated page of the affiliated store, for transitioning to a screen that displays suggested information. When the user presses button BT1, as shown in the right part of FIG. 15, display control unit 146 causes payment application 20 to display suggested information about insurance services corresponding to the category to which the affiliated store of the dedicated page visited by the user belongs.

[0060] For example, when a user visits a dedicated page of an affiliated store belonging to the "medical" category, the display control unit 146 displays suggested information about medical insurance. This is because it is assumed that a user who visits a dedicated page of an affiliated store belonging to the "medical" category is interested in subscribing to medical insurance. As another example, when a user visits a dedicated page of an affiliated store belonging to the "sports" category, the display control unit 146 may display suggested information about sports-related accident insurance. As another example, when a user visits a dedicated page of an affiliated store belonging to the "medical" category, the display control unit 146 may display suggested information about medical insurance. As another example, when a user visits a dedicated page of an affiliated store belonging to the "finance" category, the display control unit 146 may display suggested information about asset management.

[0061] In this way, by selecting a financial service to be proposed by referring to the user's operation history information, it is possible to propose a financial service before the user actually makes a payment. Note that the operation history information to be referenced is not limited to the user's visits to specialized pages. For example, if a user opens map information included in payment application 20 and taps on a certain affiliated store, it may be determined that the user is interested in the category of that affiliated store, and a financial service to be proposed may be selected.

[0062] In the above description, the acquisition unit 142 refers to the user information 172 one by one to determine whether the specified conditions are met, but the present invention is not limited to such a configuration. The payment application 20 may send notification information indicating that the specified conditions are met to the payment server 100, and in response to the acquisition unit 142 acquiring the notification information, the display control unit 146 may cause the payment application 20 to display suggested information regarding financial services corresponding to the met specified conditions.

[0063] Next, the flow of processing executed by information management unit 140 will be described with reference to Fig. 17. Fig. 17 is a flowchart showing an example of the flow of processing executed by information management unit 140. The processing of the flowchart shown in Fig. 17 is executed when the user accesses a predetermined screen (for example, a wallet screen) of payment application 20.

[0064] First, the acquisition unit 142 acquires from the payment application 20 a notification that the user has accessed a predetermined screen of the payment application 20 (step S100). Next, the display control unit 146 causes the payment application 20 to display a transition button BT1 on the predetermined screen for transitioning to a screen displaying suggested information (step S102). Next, the acquisition unit 142 acquires from the payment application 20 information indicating whether the user has pressed the transition button BT1 (step S104).

[0065] If the acquisition unit 142 acquires information indicating that the user has not pressed the transition button BT1, the information management unit 140 ends the process. On the other hand, if the acquisition unit 142 acquires information indicating that the user has pressed the transition button BT1, the display control unit 146 causes the payment application 20 to display a proposal screen regarding the use of multiple financial services (step S106). Next, the acquisition unit 142 acquires from the payment application 20 information indicating whether input information has been entered on the proposal screen for a certain financial service among the multiple financial services (step S108).

[0066] If the acquisition unit 142 acquires information indicating that no input information has been entered on the proposal screen for a certain financial service, the information management unit 140 terminates the process (step S108). On the other hand, if the acquisition unit 142 acquires information indicating that input information has been entered on the proposal screen for a certain financial service, the calculation unit 144 calculates the benefit that the user will receive from using the financial service based on the input information (step S110). Next, the display control unit 146 causes the payment application 20 to display proposal information that suggests the use of the financial service to the user based on the benefit (step S112). This terminates the process of this flowchart.

[0067] Fig. 18 is a flowchart showing another example of the flow of processing executed by the information management unit 140. The processing of the flowchart shown in Fig. 18 is executed by the information management unit 140 in a predetermined control cycle.

[0068] First, the acquisition unit 142 refers to the user information 172 (step S200). Next, the acquisition unit 142 determines whether the user information 172 satisfies a predetermined condition (step S202). If it is determined that the user information 172 does not satisfy the predetermined condition, the information management unit 140 ends the process. On the other hand, if it is determined that the user information 172 satisfies the predetermined condition, the display control unit 146 causes the payment application 20 to display a transition button BT1 for transitioning to a screen displaying suggested information (step S204). Next, the acquisition unit 142 acquires information indicating whether the user has pressed the transition button BT1 from the payment application 20 (step S206).

[0069] If the acquisition unit 142 acquires information indicating that the user has not pressed the transition button BT1, the information management unit 140 ends the process. On the other hand, if the acquisition unit 142 acquires information indicating that the user has pressed the transition button BT1, the display control unit 146 causes the payment application 20 to display a proposal screen regarding the use of financial services that correspond to predetermined conditions (step S208). Next, the acquisition unit 142 acquires information from the payment application 20 indicating whether input information has been entered on the proposal screen (step S210).

[0070] If the acquisition unit 142 acquires information indicating that no input information has been entered on the proposal screen, the information management unit 140 ends the process (step S210). On the other hand, if the acquisition unit 142 acquires information indicating that input information has been entered on the proposal screen, the calculation unit 144 calculates the benefit that the user will receive from using the financial service based on the input information (step S212). Next, the display control unit 146 causes the payment application 20 to display proposal information that suggests the user to use the financial service based on the benefit (step S214). This ends the process of this flowchart.

[0071] According to the embodiment described above, input information entered by a user on a payment app installed on a user terminal device is acquired, and for each of a plurality of financial services, a profit that the user would make by using the financial service is calculated based on the input information. Based on the profit, proposal information suggesting the use of the financial service to the user is displayed on the payment app. This makes it possible to propose the most suitable financial service to the user using the payment app from a wide range of financial services.

[0072] The above describes the form for carrying out the present invention using an embodiment, but the present invention is not limited to such an embodiment, and various modifications and substitutions can be made within the scope that does not deviate from the gist of the present invention. [Explanation of symbols]

[0073] 10 User terminal device 20. Payment App 100 Payment Server 120 Payment Contents Department 130 Payment processing unit 140 Information Management Department 142 Acquisition Department 144 Calculation Unit 146 Display control unit

Claims

1. an acquisition unit that acquires input information entered by a user on a payment application installed in the user terminal device; a calculation unit that calculates, for each of a plurality of financial services, a profit that the user will make by using the financial service based on the input information; a display control unit that causes the payment application to display proposal information that proposes use of the financial service to the user based on the profit. Information processing device.

2. the display control unit causes the payment app to display an interface element for transitioning to a screen displaying the suggested information on a screen displaying the asset status of the user, among screens of the payment app; The information processing device according to claim 1 .

3. the calculation unit calculates the profit by simulating the use of the financial services using the input information as input, using simulation reference information for each of the plurality of financial services stored in a storage unit; The information processing device according to claim 1 .

4. The acquisition unit acquires, from the payment app, information indicating the charge amount or asset balance of the user on the payment app; the display control unit, when the acquired charge amount or asset balance indicates a predetermined amount or more, causes the payment app to display the proposal information proposing to the user the use of the financial service; The information processing device according to claim 1 .

5. the acquisition unit acquires, from the payment app, information regarding the electronic payment executed by the user using the payment app; the display control unit, when the store where the electronic payment has been made belongs to a predetermined category, causes the payment app to display the suggestion information suggesting to the user the use of the financial service related to the predetermined category; The information processing device according to claim 1 .

6. the acquisition unit acquires, from the payment app, information regarding an operation of the payment app performed by the user; When the store that is the target of the operation belongs to a predetermined category, the display control unit causes the payment app to display the suggestion information that suggests to the user the use of the financial service related to the predetermined category. The information processing device according to claim 1 .

7. The computer Acquires input information entered by the user on the payment application installed on the user terminal device, calculating, for each of a plurality of financial services, a profit that the user will make by using the financial service based on the input information; displaying, on the payment application, proposal information that proposes to the user the use of the financial service based on the profit; Information processing methods.

8. On the computer, Acquires input information entered by a user on a payment application installed on the user terminal device, Calculating, for each of a plurality of financial services, a profit that the user will make by using the financial service based on the input information; displaying, on the payment application, proposal information that proposes to the user the use of the financial service based on the profit; program.

Images