TWI913100B - Proposal system, proposal methods, and application products - Google Patents

Abstract

The unsettled bill information acquisition unit (303) of the proposal system (1) acquires unsettled bill information regarding unsettled goods or services provided by the user in the first service. The second service information acquisition unit (304) acquires second service information, which is different from the first service, based on the unsettled bill information. The proposal unit (305) proposes the second service information to the user.

Description

Proposal system, proposal methods, and program products

This disclosure relates to the proposal system, proposal methodology, and program product.

Previously, it was known that users could perform checkout services using their own terminals. For example, Patent 1 describes how, once a user performs checkout using a checkout application installed on their terminal, the checkout server selects investment products based on the amount. A mini-application, i.e., a financial application, launched within the checkout application then proposes the purchase of the selected investment products. [Previous Art Documents] [Patent Documents]

[Patent Document 1] Japanese Patent Application Publication No. 2022-104128

[Problem to be Solved by the Invention] However, the technology of Patent 1 proposes the purchase of investment products corresponding to the amount information based on the checkout information of the user's actual checkout. Therefore, it cannot promote the checkout of unsettled goods or services. This is also the case in other prior art, which cannot make proposals corresponding to the user's potential needs for checking out unsettled goods or services.

One of the purposes of this disclosure is to propose solutions that address the latent needs of users. [Means used to solve problems]

The proposal system disclosed herein includes: an outstanding bill information acquisition unit, which acquires outstanding bill information regarding unpaid goods or services for which the user has not yet settled, and which pertains to previously unpaid goods or services provided in the first service; and a second service information acquisition unit, which, based on the previously unpaid bill information, acquires second service information concerning a second service different from the previously mentioned first service; and a proposal unit, which proposes the previously mentioned second service information to the user. [Invention Effects]

This disclosure allows for proposals that address the potential needs of users.

[1. Hardware Configuration of the Proposal System] This section describes an example of the implementation of the proposal system, proposal method, and program disclosed herein. Figure 1 is a diagram illustrating an example of the hardware configuration of the proposal system. For example, the proposal system 1 includes: a first server 10, a second server 20, a checkout server 30, a user terminal 40, and a store terminal 50. Each of the first server 10, the second server 20, the checkout server 30, the user terminal 40, and the store terminal 50 is connected to a network N such as the Internet or a LAN.

The first service server 10 is a server computer providing the first service. In this embodiment, the first service is exemplified as an e-commerce service, but the first service is not limited to e-commerce services. The first service can be any service. For example, the first service can also be an online flea market service, travel booking service, communication service, financial service, video streaming service, salon service (such as beauty salons), restaurant booking service, or other services. For example, a user accesses the first service server 10 through a user terminal 40, thus utilizing the first service. The first service is not limited to online services. The first service can also be an offline service.

For example, the first 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 type of volatile memory such as RAM and non-volatile memory such as flash memory. The communication unit 13 includes at least one type of communication interface for wired communication and communication interface for wireless communication.

The second service server 20 is a server computer for the second service. The second service is a service different from the first service. In this embodiment, it is exemplified by the case where a credit card issuing company provides a service equivalent to the second service. However, the second service can also be an e-commerce service, online flea market service, travel booking service, communication service, financial service, video streaming service, salon service (such as beauty salons), restaurant booking service, or other services different from the first service. For example, a user accesses the second service server 20 through a user terminal 40, thus utilizing the second service. The second service is not limited to online services. The second service can also be an offline service.

For example, the second server 20 includes a control unit 21, a memory unit 22, and a communication unit 23. The hardware configuration of the control unit 21, the memory unit 22, and the communication unit 23 can be the same as that of the control unit 11, the memory unit 12, and the communication unit 13, respectively.

Checkout server 30 is a server computer for the checkout service. The checkout service provides users with electronic checkout (cashless checkout). The checkout service is a service different from Services 1 and 2. For example, the checkout service can be linked with Services 1 and 2. This inter-service linkage means that data transmission and reception are possible. The operators of the checkout service, Services 1, and Services 2 can be the same or different from each other.

For example, the checkout server 30 includes a control unit 31, a memory unit 32, and a communication unit 33. The hardware configuration of the control unit 31, the memory unit 32, and the communication unit 33 can be the same as that of the control unit 11, the memory unit 12, and the communication unit 13, respectively.

User terminal 40 is a user's computer. For example, user terminal 40 is a smartphone, tablet, personal computer, or wearable terminal. User terminal 40 includes: a control unit 41, a memory unit 42, a communication unit 43, an operation unit 44, a display unit 45, and a camera unit 46. The hardware configuration of the control unit 41, memory unit 42, and communication unit 43 can be the same as that of the control unit 31, memory unit 32, and communication unit 33, respectively. The operation unit 44 is an input device such as a touch panel or mouse. The display unit 45 is a display such as a liquid crystal display (LCD) or an organic EL display. The camera unit 46 includes at least one camera.

The store terminal 50 is the computer for a franchised checkout service store. For example, the store terminal 50 can be a POS terminal, handheld terminal, smartphone, tablet, or personal computer. The store terminal 50 includes: a control unit 51, a memory unit 52, a communication unit 53, an operation unit 54, a display unit 55, and a reader 56. The hardware configuration of the control unit 51, memory unit 52, communication unit 53, operation unit 54, and display unit 55 can be the same as that of the control unit 11, memory unit 12, communication unit 13, operation unit 44, and display unit 45, respectively. The reader 56 contains at least one barcode reader or reader-writer. The reader 56 may also contain at least one camera.

Furthermore, the programs stored in memory units 12, 22, 32, 42, and 52 can also be supplied to the first server 10, the second server 20, the checkout server 30, the user terminal 40, or the store terminal 50 via network N. Additionally, at least one of a reading unit (e.g., a memory card slot) for reading computer-readable information memory media and an input/output unit (e.g., a USB port) for data exchange with external machines can also be included in the first server 10, the second server 20, the checkout server 30, the user terminal 40, or the store terminal 50. For example, the program stored in the information memory medium can also be supplied to the first service server 10, the second service server 20, the checkout server 30, the user terminal 40, or the store terminal 50 through at least one of the reading unit and the output unit.

Furthermore, the proposal system 1 only needs to contain at least one computer. The computer contained in the proposal system 1 is not limited to the example in Figure 1. For example, the proposal system 1 may also contain only a checkout server 30 and a user terminal 40. In this case, the first service server 10, the second service server 20, and the store terminal 50 exist outside the proposal system 1. The proposal system 1 may also contain only a checkout server 30. In this case, the first service server 10, the second service server 20, the user terminal 40, and the store terminal 50 exist outside the proposal system 1. For example, the proposal system 1 may also contain a checkout server 30 and other computers not shown in Figure 1.

[2. Overview of the Proposal System] In this embodiment, the user operates the user terminal 40 to utilize the first service, the second service, and the checkout service. For example, the applications for the first service (Application 1), the second service (Application 2), and the checkout service (Application 1) are each installed on the user terminal 40. The user can utilize the first service, the second service, and the checkout service from these applications. Once the user performs the operation required to activate the user terminal 40, the user terminal 40 displays a menu screen representing these applications on the display unit 45.

Figure 2 is an illustration of an example of the screen displayed on the user terminal 40. For example, the menu screen SC1 contains: a small icon I10 for the first application, a small icon I11 for the second application, and a small icon I12 for the checkout application. Once the user selects the small icon I10, the user terminal 40 launches the first application. As shown in the upper right of Figure 2, the user terminal 40 displays the first service screen SC2, which is the top page (first view) of the first service, on the display unit 45. The user can utilize the first service from the first service screen SC2. In this embodiment, the user can utilize an e-commerce service, which is an example of the first service, from the first service screen SC2.

For example, a user can enter any search criteria on the first service screen SC2 to search for goods or services offered in e-commerce services. Once a user browses a screen displaying goods or services, the first service server 10 updates the browsing history information representing the user's browsing history. Once a user adds a goods or service to their favorites, the first service server 10 updates the favorites information representing the user's favorite goods. Once a user adds a goods or service to their shopping cart, the first service server 10 updates the shopping cart information representing the user's shopping cart. This series of processes is the same as those used in known e-commerce services. The processes required for users to purchase goods or services are also the same as known processes.

For example, once the user selects icon I11, the user terminal 40 launches the second application. The user terminal 40 accesses the second service server 20. Although the screen of the second service is omitted in Figure 2, the screen of the second service can be the same as the screens known in the literature. The processing of the user using the second service from the screen of the second service can also be the same as the processing adopted in the known second service. In this embodiment, since the service provided by the card issuer is equivalent to the second service, the user can view credit card details, apply for installment payments, apply for bonus payments, or apply for cash advances. The processing required for these applications can also be the same as the processing adopted in the known second service.

For example, once the user selects the small icon I12, the user terminal 40 launches the checkout application. As shown in the lower left of Figure 2, the user terminal 40 displays the checkout service screen SC3, which is the top-level page of the checkout service, on the display unit 45. The user can utilize the checkout service from the checkout service screen SC3. The user can use any checkout method within the checkout service. A checkout method is the means by which the user uses the checkout process. For example, a checkout method can also be: a credit card, electronic currency, points, encrypted assets, debit card, e-wallet, bank account, or other means. Since barcodes or QR codes are also required for checkout, they are considered equivalent to checkout methods. The means of payment, also known as the means of settlement.

For example, once the checkout application is launched, the user terminal 40 displays a checkout service screen SC3 on the display unit 45, which includes a code C30 generated based on a temporarily identifiable user code ID. The code C30 is at least one of a barcode and a QR code. Once the code C30 is read by the reader 56 of the store terminal 50, checkout is performed based on the code ID obtained from the code C30. In the example of Figure 2, since a credit card is already set as the payment source, a credit card-based checkout is performed. The processing required for checkout is known.

Furthermore, the checkout process is not limited to the type that reads the code C30 displayed on the user terminal 40 using the store terminal 50. Checkout can be any type. For example, checkout can also be: the type that reads the code displayed on the store terminal 50 using the user terminal 40; the type that reads the code displayed in the store using the user terminal 40; the type that can be completed simply by operating the user terminal 40; the type that utilizes the IC chip of the user terminal 40; or other types. Once checkout is complete, as shown in the lower right of Figure 2, the user terminal 40 displays a checkout completion screen SC4 indicating that checkout is complete on the display unit 45.

In this embodiment, if there are goods or services offered in the first service that the user is interested in but has not yet paid for (hereinafter referred to as unpaid goods) or services (hereinafter referred to as unpaid services), then in order to support the user's payment, the second service information I40 regarding the second service will be proposed in the payment completion screen SC4. In the example of Figure 2, the second service information I40 indicates the installment payment application required to support the purchase of the goods or services. The installment payment application is an application provided by the card issuer of the credit card used in the payment.

Furthermore, the installment payment application can be the same as the second application launched via the selection of the icon I11, or it can be a mini-application within the second application, which is a super application. However, in this embodiment, the installment payment application is exemplified as a mini-application within the checkout application, which is a super application. The super application is an application that manages multiple mini-applications. A mini-application is an application that is invoked from the super application. The mini-applications in this embodiment include applications that operate based on the checkout application, which is a super application, but also those required for migration from the checkout application to applications provided by the second service server 20. Even mini-applications can include necessary elements such as the screen display for migration from the checkout application to the website.

For example, the checkout screen SC3 contains an application list L31 that represents a list of mini-applications. Users can select any mini-application from the application list L31. Installment payment applications proposed via the second service information I40 are also displayed in the application list L31. Once the user selects "View All," the user terminal 40 displays mini-applications that cannot be displayed all at once in the application list L31. The application list L31 may also display mini-applications for services other than the first and second services. Links like the application list L31 can also be considered mini-applications.

Furthermore, an integrated application that combines the first application, the second application, and the checkout application can also be installed on the user terminal 30. Within the integrated application, the part required to provide the first service to the user may be the first application, the part required to provide the second service to the user may be the second application, and the part required to provide the checkout service to the user may be equivalent to the checkout application. For example, a smartphone application is usually not a single program, but often a collection of multiple smaller programs (e.g., programs called from the main function that are equivalent to secondary functions). Alternatively, the concept of including multiple programs can be defined as an integrated application, with the smaller programs being the first application, the second application, and the checkout application.

For example, users may not be aware of installment payment applications even when they are not aware of the application overview L31. In such cases, users can become aware of the installment payment application through the second service information I40. For instance, if a user is hesitant about purchasing a high-value, unpaid item or service in the first service, they can realize that they can use an installment payment application to ease the payment burden. That is, the proposal system 1 supports the purchase of unpaid items or services by proposing the installment payment application indicated by the second service information I40.

As described above, the proposal system 1 of this embodiment displays service information I40 on the checkout completion screen SC4 to support the purchase of unsettled goods or services in the first service. In this way, the proposal system 1 can make proposals corresponding to the user's potential needs. Proposals corresponding to potential needs can also be made for purposes other than supporting the purchase of unsettled goods or services. The details of the proposal system 1 are explained below.

[3. Functions Implemented in the Proposal System] Figure 3 is a diagram illustrating one example of the functions implemented in the proposal system 1. The various components implemented in the proposal system 1 can be assembled into a single device or distributed into more subdivided devices, etc.

[3-1. Functions Implemented in the First Service Server] For example, the first service server 10 includes a data memory unit 100 and a first service provision unit 101. The data memory unit 100 is implemented by a memory unit 12. The first service provision unit 101 is implemented by a control unit 11.

[Data Memory Unit] The data memory unit 100 stores the data necessary for the first service. For example, the data memory unit 100 stores the first service database DB1.

Figure 4 is an illustration of an example of the Service 1 database DB1. The Service 1 database DB1 is a database in which various information about users in the Service 1 is stored. For example, the Service 1 database DB1 stores user ID, password, browsing history information, favorites information, and shopping cart information. The Service 1 database DB1 may also store other data. For example, the Service 1 database DB1 may also store at least one of the following: wish list information indicating the goods or services the user wants that have been registered, purchase history information indicating the goods or services the user has purchased in the Service 1, and payment method information regarding the payment methods the user can use in the Service 1.

The user ID for Service 1 is one example of user identification information used to identify a user within Service 1. Alternatively, a login account may exist separately from the user ID. The login account can also be designed to be freely changeable by the user. The password is information that is confirmed upon login. The user ID for Service 1 can be the same as, or different from, at least one of the user IDs for Service 2 and the checkout service. If the user IDs are different, the user ID association is managed in Proposal System 1. For example, at least one of Service 1 server 10, Service 20, and Checkout server 30 manages this association. This association allows identification of which user ID belongs to which user.

Browsing history information refers to: the store ID of the store that provided the user with the goods or services viewed, the ID that identifies the goods or services, and the date and time of browsing. My Favorites information refers to: the store ID of the store that provided the user with the goods or services listed in their favorites, the ID that identifies the goods or services, and the date and time of listing. Shopping cart information refers to: the store ID of the store that provided the user with the goods or services listed in their shopping cart, the ID that identifies the goods or services, the quantity of the goods or services, and the date and time of listing. Browsing history information, My Favorites information, and Shopping cart information are any forms that may be used in known e-commerce services.

Furthermore, the data stored in the data memory unit 100 is not limited to the example described above. The data memory unit 100 only needs to store the data necessary for the first service. For example, the data memory unit 100 may also store a database containing various information about the goods or services provided in the first service (such as the store ID of the store providing the goods or services, the ID used to identify the goods or services, the description of the goods or services, images of the goods or services, the price of the goods or services, the inventory of the goods or services, or other information). The data memory unit 100 may also store data about the various screens displayed on the first application.

[First Service Provision Unit] The first service provision unit 101 provides the first service to the user based on the data stored in the data memory unit 100. In this embodiment, since e-commerce services are equivalent to the first service, the first service provision unit 101 provides various services necessary for the user to conduct e-commerce. In the example of Figure 2, the first service provision unit 101 displays the first service screen SC2 on the user terminal 40 and performs tasks such as product retrieval, product browsing, adding products to favorites, adding products to the shopping cart, and other processing. These processes are the same as those used in known e-commerce services. The same applies to the case where the first service is a service other than e-commerce services. The processing performed by the first service provision department 101 is the same as the processing used in other known services.

[3-2. Functions Implemented in the Second Server] For example, the second server 20 includes a data memory unit 200 and a second service provision unit 201. The data memory unit 200 is implemented by a memory unit 22. The second service provision unit 201 is implemented by a control unit 21.

[Data Memory Unit] The data memory unit 200 stores the data necessary for the second service. For example, the data memory unit 200 stores a database containing various information about users in the second service. In this embodiment, since the service provided by the credit card issuing company is equivalent to the second service, various information about the credit card is stored in the database. For example, the database stores: credit card number, expiration date, name, credit card usage history, payment methods such as lump sum or installment payments, or other information. The data memory unit 200 only needs to store the data corresponding to the second service.

[Second Service Provision Department] The second service provision department 201 provides a second service to the user based on the data stored in the data storage department 200. In this embodiment, since the service provided by the credit card issuing company is equivalent to the second service, the second service provision department 201 provides various services such as viewing credit card usage history and changing payment methods such as lump-sum payment, revolving credit payment, bonus payment, or installment payment. For example, the second service provision department 201 displays the second service screen on the user terminal 40 and processes the user's installment payment application. The processing of installment payment applications is a known process.

[3-3. Functions Implemented in the Checkout Server] For example, the checkout server 30 includes: a data memory unit 300, a checkout execution unit 301, a checkout determination unit 302, an unpaid bill information acquisition unit 303, a second service information acquisition unit 304, and a proposal unit 305. The data memory unit 300 is implemented by a memory unit 32. The checkout execution unit 301, the checkout determination unit 302, the unpaid bill information acquisition unit 303, the second service information acquisition unit 304, and the proposal unit 305 are each implemented by a control unit 31.

[Data Memory Unit] The data memory unit 300 stores the data necessary for the checkout service. For example, the data memory unit 300 stores the checkout service database DB2.

Figure 5 is an illustration of an example of a checkout service database, DB2. The checkout service database DB2 is a database that stores various information about users. For example, DB2 stores: user ID, password, code ID, payment method information, and payment history information. DB2 may also store other data. For example, DB2 may also store: payment source information for payment methods set by the user, or value-added source information for payment methods set by the user as a value-added source for electronic currency. The checkout service database DB2 can also store information such as browsing history, favorites, and shopping cart information obtained from the first service server 10.

The User ID for the checkout service is one example of user identification information used to identify a user during checkout. Alternatively, a login account may exist separately from the User ID. The login account can also be designed to be freely changeable by the user. The password is the information confirmed upon login. The Code ID is also a user ID used to identify the user during checkout. The Code ID is updated each time Code C30 is displayed.

Payment method information refers to information that can be used to identify the payment method a user can use in the payment service. For example, payment method information may include credit card number, electronic currency number, or points card balance. Payment history information refers to information about the user's usage history of the payment service. For example, payment history information may indicate: payment date and time, payment location, payment amount, payment recipient, or a combination of these. Once the user completes the payment, the payment execution unit 301 (described later) updates the payment history information to reflect the details of the payment.

Furthermore, the data stored in the data memory unit 300 is not limited to the example described above. The data memory unit 300 only needs to store the data required for the checkout service. For example, the data memory unit 300 can also store data from various screens displayed on the checkout application.

[Checkout Execution Unit] The checkout execution unit 301 is responsible for executing the checkout process within the checkout service. The processing required for checkout is known. In this embodiment, where the checkout type where the code C30 displayed on the user terminal 40 is read by the store terminal 50, the checkout execution unit 301 executes the checkout based on the checkout request received from the store terminal 50. The checkout execution unit 301 executes the checkout based on the checkout method information associated with the code ID contained in the checkout request received from the store terminal 50, referring to the checkout service database DB2. For example, if a user sets their credit card as the payment source, the checkout execution unit 301 will execute the checkout based on information such as the credit card number indicated in the checkout method information. It is assumed that information such as the amount required for checkout is also included in the checkout request.

Furthermore, the processing performed by the checkout execution unit 301 is not limited to the examples mentioned above. Whether it's the type of processing where the code displayed on the store terminal 50 is read by the user terminal 40, the type of processing where the code revealed in the store is read by the user terminal 40, the type of processing where only an operation on the user terminal 40 is required (e.g., ID checkout or account checkout), the type where the IC chip of the user terminal 40 is utilized, the type of processing where the user terminal 40 uses a telecommunications operator (i.e., telecommunications collection checkout), or other types of checkout, the checkout execution unit 301 performs the checkout by communicating with at least one of the user terminal 40 and the store terminal 50 to obtain the necessary information for checkout. The checkout execution unit 301 updates the user's checkout history information once a checkout is executed to indicate that the checkout has been completed.

[Checkout Determination Unit] The Checkout Determination Unit 302 determines whether, in checkout services different from the first and second services, the user has processed a checkout for a product or service different from the unchecked product or service. The Checkout Determination Unit 302 determines whether the user has processed the checkout based on the processing result of the Checkout Execution Unit 301. That is, the Checkout Determination Unit 302 determines whether the checkout processing performed by the Checkout Execution Unit 301 has been completed. The Checkout Determination Unit 302 determines whether the processing represented in the program executed by the Checkout Execution Unit 301 for the purpose of checkout has been completed. While the product or service being checked out in the checkout service may occasionally be the same as the unchecked product or service, it is assumed that it is fundamentally different from the unchecked product or service.

In this embodiment, it is assumed that the checkout request does not contain information that can identify the goods or services to be checked out (e.g., a JAN code). Therefore, it is assumed that the checkout determination unit 302 does not determine whether the goods to be checked out are different from the unchecked goods, or whether the services to be checked out are different from the unchecked services. The checkout determination unit 302 does not determine what the specific goods or services to be checked out are, but rather determines whether the unchecked goods or services have been checked out by a user.

Furthermore, the checkout request may also include information that identifies the goods or services to be checked out. In this case, the checkout determination unit 302 can also specify the exact goods or services to be checked out. The checkout determination unit 302 can also determine whether the information contained in the checkout request and the goods to be checked out are different from the unchecked goods, or whether the services to be checked out are different from the unchecked services.

[Unpaid Bill Information Acquisition Department] The Unpaid Bill Information Acquisition Department 303 acquires unpaid bill information regarding unpaid goods or services that the user has not yet settled, specifically unpaid goods or services provided in the first service. Unpaid goods or services can also be defined as goods or services that the user has not yet purchased. Unpaid goods or services can be any type of product or service. For example, travel products or content, which do not exist in physical form, can also be considered unpaid goods. Unpaid services can be services that can be booked online (reserved) or services that the user can book in person.

In this embodiment, e-commerce services are used as an example of the first service. Therefore, the unsettled information acquisition unit 303 acquires unsettled information about goods or services that the user is considering purchasing in the e-commerce service. The unsettled goods or services that the user is considering purchasing are those that the user has viewed or that the user has registered for in the first service. For example, the unsettled information acquisition unit 303 acquires the user's unsettled information from the first service server 10.

For example, if the user ID is the same in both the first service and the checkout service, the unpaid bill information acquisition unit 303 sends the user ID of the user who is the target of the unpaid bill information acquisition to the first service server 10 to request the unpaid bill information. The first service server 10 sends the unpaid bill information of the user indicated by the user ID to the checkout server 30, referring to the first service database DB1. The unpaid bill information acquisition unit 303 acquires the unpaid bill information sent by the first service server 10. If the user ID is different in both the first service and the checkout service, at least one of the first service and the checkout service manages the association mapping of the user IDs. The first service and the checkout service can then specify which user's unpaid bill information to acquire or send based on this association mapping.

Unpaid information may not necessarily be information that identifies the specific unpaid goods or services. Unpaid information can be any information relating to unpaid goods or services. In this embodiment, an example is given where the unpaid information indicates the presence or absence of unpaid goods or services. For instance, unpaid information could be a first value indicating that it is an unpaid goods or services, or a second value indicating that it is not an unpaid goods or services. Unpaid information can also be stored in the data memory 100 of the first server 10, or it can be generated by the first server 10.

In addition, unpaid information may also refer to other information regarding unpaid goods or services. For example, unpaid information can also include: the price of unpaid items or services, the price range of unpaid items or services, the quantity of unpaid items or services, the rough category of unpaid items or services, information that can identify the specific unpaid items or services, the total amount of unpaid items or services, the inventory of unpaid items or services, the elapsed time since the user started considering unpaid items or services (e.g., the elapsed time since the user started browsing, the elapsed time since being added to favorites, or the elapsed time since being added to shopping cart), or the store that offers unpaid items or services.

Furthermore, the unpaid bill information acquisition unit 303 can also acquire unpaid bill information from the first service server 10 without requesting it from the first service server 10. For example, if there are unpaid items in the first service server that a user has not yet paid for, the first service server 10 can also send unpaid bill information to the checkout server 30. In this case, the unpaid bill information acquisition unit 303 acquires the unpaid bill information from the first service server 10 without requesting it. The first service server 10 can also send unpaid bill information to the checkout server 30 only if a certain item is in an unpaid state within a specified period. Suppose that the first service server 10 sends the unpaid bill information, along with information that can identify which user the unpaid bill information belongs to (such as user ID), to the checkout server 30.

In this embodiment, the unpaid bill information acquisition unit 303 acquires unpaid bill information only when the checkout determination unit 302 determines that the user has completed the checkout process. If the checkout determination unit 302 does not determine that the user has completed the checkout process, the unpaid bill information acquisition unit 303 does not acquire unpaid bill information.

For example, the unpaid bill information retrieval unit 303 requests unpaid bill information from the first service server 10 when the checkout determination unit 302 determines that the user has completed the checkout. Assume that the user ID of the user who completed the checkout is included in the request for unpaid bill information. The first service server 10 refers to the first service database DB1 and at least one of the following: browsing history information, favorites information, and shopping cart information associated with that user ID, to determine whether there are any unpaid items or services. If the user ID is different in the first service and the checkout service, then as mentioned above, the association with the user ID can be used for mapping.

For example, if the first service server 10 determines that there are unpaid items or services among the at least one of them, it generates unpaid information indicating the existence of unpaid items or services and sends it to the checkout server 30. If the first service server 10 determines that there are no unpaid items or services among the at least one of them, it generates unpaid information indicating that there are no unpaid items or services and sends it to the checkout server 30. The unpaid information acquisition unit 303 acquires the unpaid information generated and sent by the first service server 10. The unpaid information is acquired by the unpaid information acquisition unit 303 using the same process as for other information indicating the presence or absence of unpaid items or services. If the unpaid bill information is already stored in the first service database DB1, then the first service server 10 may not generate the unpaid bill information on the spot.

[Second Service Information Acquisition Unit] The second service information acquisition unit 304 acquires second service information I40, which is different from the first service, based on unchecked billing information. In this embodiment, the second service information acquisition unit 304 acquires second service information I40 regarding the second application required for the user to utilize the second service. That is, although the application for the second service is exemplified as a mini-application, the application for the second service may also be a regular application rather than a mini-application. A regular application is an application that can be launched from a location other than the super application, i.e., the checkout application. For example, the application whose icon is displayed on the menu screen SC1 of the OS on the user terminal 40 is equivalent to a regular application. The application for the second service is the application delivered by the business that provides the second service to the user.

While the second service information I40 could also refer to data about a second service, in this embodiment it refers to an object (such as an image or text) visually presented in the checkout completion screen SC4. The physical data required for displaying the second service information I40 is assumed to be pre-memorized in the data memory unit 300. The second service information acquisition unit 304 acquires the second service information I40 by acquiring this physical data. The physical data required for displaying the second service information I40 may also not be pre-memorized in the data memory unit 300, but may be dynamically generated on-site. In this case, it is assumed that the data forming the basis of the second service information I40 is stored in the data memory unit 300. The second service information acquisition unit 304 generates the second service information I40 based on the data used as the basis.

In this embodiment, the checkout for goods or services different from those not yet checked out is generally conducted during the checkout process. Therefore, the second service information acquisition unit 304 acquires the second service information I40 only when it is determined that the user has checked out for the different goods or services. The second service information acquisition unit 304 does not acquire the second service information I40 unless it is determined that the user has checked out for the different goods or services.

For example, the second service information acquisition unit 304 acquires the second service information I40, which is used to support the settlement of unsettled goods or services. Settlement support includes: reducing the amount per transaction, delaying the settlement period through payment after payment, reducing the total settlement amount through the use of coupons, or a combination of these. In this embodiment, the service provided by the card issuer of a credit card that the user has set as the payment source is equivalent to the second service; therefore, the second service information acquisition unit 304 acquires the second service information I40 of the installment payment application provided by the card issuer.

Furthermore, the second service information acquisition unit 304 can also acquire the second service information I40 of applications other than the installment payment application. For example, these other applications could be: second applications launched via a selection on a thumbnail I11; applications that allow users to use their points; advertising applications that grant points when users view advertisements; applications that allow users to take photos of receipts and upload them; or coupon applications that allow users to obtain coupons. These other applications can also be mini-applications. The physical data required for displaying the second service information I40 of these other applications can also be pre-memorized in the data memory unit 300.

[Proposal Department] Proposal Department 305 proposes the second service information I40 to the user. In this embodiment, Proposal Department 305 proposes the second service information I40 to the user through the checkout application on the user terminal 40. Proposing the second service information I40 to the user refers to sending the data required for displaying the second service information I40 to the user terminal 40 or other computers. In this embodiment, Proposal Department 305 proposes the second service information I40 to the user on the checkout completion screen SC4, which indicates that checkout is complete. The checkout completion screen SC4 is a screen indicating that checkout is complete.

For example, the checkout completion screen SC4 displays information such as: a message indicating that checkout is complete, the checkout location, the checkout date and time, the checkout amount, the checkout recipient, or a combination of these. In this embodiment, the example shown is that the checkout completion screen SC4 is displayed by the proposal unit 305 itself; however, the checkout completion screen SC4 can also be displayed through other functions besides the proposal unit 305. Regardless of the form of the proposal for the second service information I40, the proposal unit 305 can display the second service information I40 in a pop-up window on the checkout completion screen SC4 or overlay it on a new screen, thus proposing the second service information I40 to the user on the checkout completion screen SC4.

For example, the proposal unit 305 generates display data for the checkout completion screen SC4 containing the second service information I40 after the checkout is completed and the second service information acquisition unit 304 has obtained the second service information I40. Display data is the data required to display a certain screen on the user terminal 40. When using a browser, the display data is HTML data. When using a dedicated application such as a checkout application, it is the data used when the application displays a certain screen (e.g., HTML data or image data). The proposal unit 305 proposes the second service information I40 to the user by sending the display data of the checkout completion screen SC4 containing the second service information I40 to the user terminal 40.

In this embodiment, the proposal unit 305 proposes the second service information I40 of the installment payment application to the user when the checkout determination unit 302 determines that the user has completed the checkout. That is, the proposal unit 305 uses the determination that the user has completed the checkout as a condition (triggered) to propose the second service information I40 of the installment payment application to the user. Even when the checkout determination unit 302 has not determined that the user has completed the checkout, the proposal unit 305 can still propose other information, such as advertisements for other services, to the user.

Furthermore, the method of proposing the second service information I40 is not limited to the example described above. The proposal unit 305 proposes the second service information I40 to the user by sending the necessary data for displaying the second service information I40 to the user terminal 40 or other computer. For example, the proposal unit 305 can also propose the second service information I40 to the user by displaying it on a screen other than the checkout completion screen SC4 within the checkout application screen. For example, the proposal unit 305 can also propose the second service information I40 to the user on the pre-checkout screen. Furthermore, the proposal unit 305 can also propose gift information related to the first service to the user on the pre-checkout screen. The proposal unit 305 can propose information based on unchecked billing information on any screen. The proposal unit 305 can also propose the second service information I40 to the user using means other than the checkout application. These other means may include email, SMS, push notifications, banner notifications, or other methods.

Furthermore, the proposal department 305, when proposing the second service information I40 to the user, can also establish a link with the information of unpaid goods or services, and propose the second service information I40. The information of unpaid goods or services includes the name, image, price, store, or a combination thereof. The information of unpaid goods or services can also be included in the unpaid information, or it can be separate data from the unpaid information, obtained from the first service server 10 through the checkout server 30. The information of unpaid goods or services can also simply indicate whether there are unpaid goods or services.

For example, the proposal department 305 can either link the second service information I40 to the specific name of the unpaid goods or services, or it can simply propose the fact that unpaid goods or services exist along with the second service information I40. Information about unpaid goods or services can also be included in the second service information I40. For example, the proposal department 305 can also propose the second service information I40, which asks, "Would you like to use installment payments for the goods you are looking for in the first service?" With this design, the proposal system 1 can more clearly convey the purpose of proposing the second service to the user compared to proposing the second service separately. In addition, for example, Proposal Department 305 may also propose gift information related to gifts associated with Service 1, in addition to Service 2 information I40. The gifts proposed by Proposal Department 305 may also be coupons, points, or other gifts that can be used in Service 1. Proposal Department 305 may also propose Service 2 information I40, which asks, "Would you like to use a coupon for the product you are looking for in Service 1?"

Furthermore, the proposal department 305 can also determine whether the unpaid goods or services shown in the unpaid bill information meet the predetermined conditions, and based on the result of the determination, propose the second service information I40 to the user. The predetermined conditions are the criteria by which the proposal department 305 proposes the second service information I40. Assume that the data representing the predetermined conditions is stored in the data memory department 300. For example, the predetermined conditions may also be: the price of the unpaid goods or services, the store providing them, or other conditions.

[3-4. Functions Implemented in the User Terminal] For example, the user terminal 40 includes: a data memory unit 400, an operation receiving unit 401, and a display control unit 402. The data memory unit 400 is implemented by a memory unit 42. The operation receiving unit 401 and the display control unit 402 are implemented by a control unit 41.

[Data Memory Unit] The data memory unit 400 stores the data needed for users to utilize the checkout service. For example, the data memory unit 400 stores the checkout application. If the user uses the checkout service through a browser instead of the checkout application, the data memory unit 400 stores the browser.

[Operation Processing Unit] Operation processing unit 401 processes various user operations. For example, operation processing unit 401 processes operations related to the checkout application. Operation processing unit 401 sends data representing the user's operation content to the checkout server 30.

[Display Control Unit] The display control unit 402 is responsible for displaying various screens on the display unit 45. For example, the display control unit 402 displays the menu screen SC1, the first service screen SC2, the checkout service screen SC3, and the checkout completion screen SC4 on the display unit 45. The display control unit 402 can also communicate with the first service server 10, the checkout server 30, or other computers to receive the data necessary for displaying these screens and display them on the display unit 45.

[3-5. Functions Implemented in a Store Terminal] For example, a store terminal 50 includes a data memory unit 500 and a checkout execution unit 501. The data memory unit 500 is implemented via a memory unit 52. The checkout execution unit 501 is implemented via a control unit 51.

[Data Memory Unit] The data memory unit 500 stores the data necessary to provide checkout services to users. For example, the data memory unit 500 stores a database containing various information such as the prices of goods or services offered by the store. The data memory unit 500 also stores information about the goods or services for which the user is checking out. The data memory unit 500 may also store information about the location where the store terminal 50 is located.

[Checkout Execution Unit] The checkout execution unit 501 provides checkout services to users. For example, once the store terminal 50 reads code C30 using the reader 56, the checkout execution unit 501 obtains the code ID from code C30. The checkout execution unit 501 obtains the checkout amount based on the results of reading the product's barcode, etc. The checkout execution unit 501 sends the checkout request, containing the code ID, checkout amount, and store location—information necessary for checkout—to the checkout server 30. The checkout request can be any request used in known checkout services. The checkout execution unit 501 retrieves the checkout execution results from the checkout server 30 to complete the checkout process in the store. This series of processes can be any of the processes used in known checkout services.

[4. Processing Performed in the Proposal System] Figures 6 and 7 illustrate an example of processing performed in the proposal system 1. The control units 11, 21, 31, 41, and 51 execute the programs stored in memory units 12, 22, 32, 42, and 52 respectively to perform the processing shown in Figures 6 and 7. It is assumed that when the processing in Figures 6 and 7 is executed, the first application, the second application, and the checkout application have already been installed on the user terminal 40. Furthermore, it is assumed that the user has already completed the registration for the first service, the second service, and the checkout service.

As shown in Figure 6, once the user performs the operation required to activate the user terminal 40, the user terminal 40 displays the menu screen SC1 on the display unit 45 (S1). The user terminal 40 identifies the user's operation based on the detection signal from the operation unit 44 (S2). Here, we take the case where the user selects either icon I10 or I12 as an example. If the user performs other operations such as selecting icon I11, the corresponding processing for that other operation will be executed, and this processing will end.

In S2, if the user selects the icon I10 required to launch the first application (S2: first application), the user terminal 40 launches the first application and performs the processing required to provide the first service to the user between itself and the first service server 10 (S3). In S3, the first service server 10 updates at least one of the browsing history information, favorite information, and shopping cart information stored in the first service database DB1.

In S2, when the user selects the small icon I12 required to launch the checkout application (S2: checkout application), the user terminal 40 launches the checkout application and performs the necessary processing (S4) between itself and the checkout server 30 to display the checkout service screen SC3. In S4, the checkout server 30 logs the user into the checkout service, generates a code ID, and sends the display data of the checkout service screen SC3 to the user terminal 40. The user then allows the code C30 to be read by the store terminal 50. Once the store terminal 50 reads the code C30 from the reading unit 56 (S5), it extracts the code ID from the code C30 and sends a checkout request to the checkout server 30 (S6). Once the checkout server 30 receives the checkout request (S7), it executes the checkout based on the checkout request (S8).

Checkout server 30 determines whether checkout is complete based on the processing result of S8 (S9). That is, in S9, checkout server 30 determines whether the user has completed checkout. If checkout is not determined to be complete (S9: N), the process returns to S9. In S9, if checkout is determined to be complete (S9: Y), checkout server 30 performs the necessary processing to obtain unchecked information between itself and the first service server 10 (S10). Checkout server 30 determines whether the unchecked information indicates the existence of unchecked goods or services (S11). In S11, if the unchecked information does not indicate the existence of unchecked goods or services (S11: N), this process ends. In this case, the checkout completion screen SC4, which does not include the second service information I40, will be displayed on the user terminal 40.

In S11, if the unpaid information indicates the existence of unpaid goods or services (S11: Y), then proceed to Figure 7, where the checkout server 30 obtains the second service information I40 of the installment payment application (S12). The checkout server 30 and the user terminal 40 perform the processing required to propose the second service information I40 of the installment payment application in the checkout completion screen SC4 (S13). In S13, the checkout server 30 generates display data for the checkout completion screen SC4 containing the second service information I40 of the installment payment application and sends it to the user terminal 40. The user terminal 40 displays the checkout completion screen SC4, as shown in the lower right corner of Figure 2, on the display unit 45.

User terminal 40 determines whether the user has selected the second service information I40 (S14). If, in S14, it is not determined that the user has selected the second service information I40 (S14: N), this process ends. If, in S14, it is determined that the user has selected the second service information I40 (S14: Y), user terminal 40 executes the necessary processing between itself and the second service server 20 to provide the second service to the user (S15), and this process ends.

[5. Summary of the Implementation] The proposal system 1 of this implementation obtains the second service information I40 based on outstanding bill information. The proposal system 1 proposes the second service information I40 to the user. The outstanding bill information reflects the user's potential need to purchase outstanding goods or services; therefore, the proposal system 1, by making proposals based on this outstanding bill information, can make proposals corresponding to the user's potential needs. Users can learn about the existence of the second service needed to fulfill their potential needs through the second service information I40, thus the proposal system 1 improves user convenience. The proposal system 1, through the proposal of the second service information I40, motivates users to utilize the second service, thereby promoting the use of the second service.

Furthermore, the proposal system 1 determines whether, during the checkout process, the user has processed a checkout for a different item or service than the unchecked item. If the system determines that the user has processed a checkout for such a different item or service, the proposal system 1 obtains the second service information I40. Therefore, even if the user has processed a checkout for an item or service unrelated to the unchecked item, the proposal system 1 can make a proposal corresponding to the user's potential needs. For example, the proposal system 1 can propose the second service information I40 at the point in time when the user is aware of the purchase, provided that a checkout for a different item or service has been processed. In other words, the proposal system 1 can propose the second service information I40 at a more effective time, thus improving the effectiveness of the second service appeal.

Furthermore, the proposal system 1 proposes a second service information to the user in the checkout completion screen SC4, which indicates that the checkout is complete. In this way, by proposing the second service information I40 to the user in the checkout completion screen SC4, which is easily visible to the user, the proposal system 1 can more effectively present the second service information I40 to the user.

Furthermore, Proposal System 1 obtains the unsettled information of unsettled goods or services that users are considering purchasing in the e-commerce service example of the first service. In this way, Proposal System 1 can make proposals in the e-commerce service that correspond to the potential needs of users.

Furthermore, the proposal system 1 obtains the second service information I40 of the installment payment application. In this way, the proposal system 1 can encourage users to utilize the installment payment application. For example, even if a user is hesitant to purchase a large amount of unpaid goods or services, knowing that an installment payment application exists can encourage them to actively consider purchasing the unpaid goods or services.

Furthermore, the proposal system 1 obtains the second service information I40, which is used to support the checkout of unsettled goods or services. Thus, the proposal system 1 can support the checkout of unsettled goods or services made by the user. For example, even if a user is hesitant to purchase a high-value unsettled item or service, the existence of the second service supporting checkout allows them to actively consider purchasing the unsettled item or service.

[6. Variations] This disclosure is not limited to the embodiments described above. Appropriate changes may be made to this disclosure without departing from its purpose.

Figure 8 is a diagram illustrating one example of the functions implemented in the variant. For example, the checkout server 30 further includes: a user location information acquisition unit 306, a promotional activity information acquisition unit 307, and a checkout information acquisition unit 308. Each of the user location information acquisition unit 306, the promotional activity information acquisition unit 307, and the checkout information acquisition unit 308 is implemented by the control unit 31.

[6-1. Variation 1] For example, a user might want to utilize a second service, such as an installment payment application, when a high amount needs to be paid. Therefore, in cases where the outstanding amount of unpaid goods or services is high, the second service information I40 can also be proposed. The outstanding information in Variation 1 indicates the price of the unpaid goods or services. Assume that the data memory unit 100 in Variation 1 stores a price database representing the prices of various goods or services. The price database can be the same as the databases used in known e-commerce services.

In Variation 1, the second service information acquisition unit 304 acquires the second service information I40 based on the price indicated by the unpaid bill information. The second service information acquisition unit 304 determines whether the price indicated by the unpaid bill information is above a threshold. The threshold is the amount used as the basis for determining whether to display the second service information I40, which is the target of the offer. The threshold can be common to all users or can be specific to each user. For example, different thresholds can be set according to demographic information such as the user's gender or age group. The threshold is stored in the data memory unit 300.

Furthermore, while the example given above illustrates displaying the second service information I40 based on whether the price indicated by the outstanding bill information is below a predetermined threshold, the threshold can also be an amount set by the user. In addition, for example, the second service information acquisition unit 304 can also acquire the second service information I40 based on whether the price indicated by the outstanding bill information exceeds a threshold corresponding to the user's history of using installment payment services. For example, if the user has previously made installment payments, the threshold can also be determined based on the amount of installment payments made by the user. The threshold may also be: the average amount of installment payments made by the user, the amount of the bill for which the user has made more installment payments, or other values.

Furthermore, when proposing the second service information I40 for installment payment services to users, the card issuer can also propose this information to users with a past installment payment history. This is because users who have not used installment payments before are unlikely to use this service. Based on the card issuer's records, eligible users and their criteria (amount, etc.) can be extracted and linked to the checkout service provider. The checkout service provider can then propose the second service information I40 to eligible users. This two-way data sharing between the checkout service provider and the card issuer further strengthens the connection between services.

For example, the second service information acquisition unit 304 will not acquire the second service information I40 if it determines that the price indicated by the unpaid bill information is below the threshold. The proposal unit 305 will not acquire the second service information I40 if it determines that the price indicated by the unpaid bill information is below the threshold. The second service information acquisition unit 304 will acquire the second service information I40 if it is determined that the price indicated by the unpaid bill information is above the threshold. The proposal unit 305 will propose the second service information I40 to the user if it determines that the price indicated by the unpaid bill information is above the threshold.

Furthermore, when there are multiple unpaid items or multiple unpaid services, the second service information acquisition unit 304 can also acquire the second service information I40 based on the price of each of the multiple unpaid items or multiple unpaid services. For example, if there are no unpaid items or unpaid services with prices above a certain threshold, the second service information acquisition unit 304 will not acquire the second service information I40; if there are one or more unpaid items or unpaid services with prices above a certain threshold, then the second service information I40 will be acquired. The second service information acquisition unit 304 can also acquire second service information I40 when there are a certain number (e.g., 5) or more unpaid goods or services with prices above the threshold.

For example, if there are multiple unpaid items or multiple unpaid services, the second service information acquisition unit 304 may obtain their total price (total price). Alternatively, the second service information acquisition unit 304 may obtain the total amount already calculated by the first service server 10, instead of calculating the total price. The second service information acquisition unit 304 may also choose not to obtain the second service information I40 if the total amount is below a threshold, and obtain the second service information I40 if the total amount is above the threshold. The second service information acquisition unit 304 may also calculate an average amount instead of a total amount. The second service information acquisition unit 304 may choose not to acquire the second service information I40 if the average amount is below the threshold, and acquire the second service information I40 if the average amount is above the threshold.

The proposal system 1 in Variation 1 obtains the second service information I40 based on the price indicated by the outstanding bill information. Therefore, the proposal system 1 can propose the second service information I40 to users for whom a proposal of the second service information I40 would be effective. For example, if a user is hesitant to purchase a high-priced outstanding product or service, the proposal system 1 can propose the second service information I40, such as installment payment applications, thus providing the user with more beneficial second service information I40.

[6-2. Variation 2] For example, although the implementation example cites e-commerce services as equivalent to the first service, the first service is not limited to online services, such as e-commerce services. In Variation 2, the example cites the case where the first service is an offline service. An offline service is a service provided in a specific location in the real world. For example, the sale of goods in an appliance store or retail store, the treatment services in a beauty salon or aromatherapy shop, or other services are equivalent to offline services.

The proposal system 1 in Variation 2 includes a user location information acquisition unit 306. The user location information acquisition unit 306 acquires user location information about the user's location. User location information is information that can be used to estimate the user's location. User location information can be publicly known information. For example, user location information can be latitude and longitude, coordinates other than latitude and longitude, access points, or information from communication devices such as mobile base stations, or other information. User location information is detected by the user terminal 40. For example, it can be obtained using the user terminal 40's GPS receiver, communication unit 43, camera unit 46, or other means. The method of acquiring user location information can also be a publicly known method. For example, the user location information acquisition unit 306 can also acquire user location information based on the user's checkout location. The checkout location refers to the location of the store or similar establishment that provides the checkout service. For example, the user location information acquisition unit 306 can also acquire user location information based on terminal identification information used to identify the store's terminal. In this case, it is assumed that data relating the terminal identification information for each store to location information indicating that store's location has been pre-memorized in the data memory unit 300. The user location information acquisition unit 306 acquires the location information associated with the terminal identification information as user location information based on this data. For example, if a user checks out at or near an electronics store, the user location information acquisition unit 306 can also acquire user location information indicating that electronics store. In addition, for example, the user location information acquisition unit 306 can determine multiple checkout locations within a specified period when determining the checkout location. For example, if the user has checked out at two or more specific locations (such as an electronics retail store) within the past month, the user location information acquisition unit 306 can also acquire user location information indicating those locations.

In Variation 2, the case where the GPS receiver of user terminal 40 is used is given as an example. For instance, user terminal 40 obtains user location information based on signals received by the GPS receiver. User terminal 40 sends the user location information obtained using the GPS receiver to the first service server 10. User location information acquisition unit 306 obtains user location information from user terminal 40. User location information acquisition unit 306 can obtain user location information at any point in time. For example, user location information acquisition unit 306 can also obtain user location information at the time when user terminal 40 is activated, the time when the first application is activated, the time when the second application is activated, the time when the checkout application is activated, or other points in time.

The unpaid information acquisition unit 303 in Variation 2 acquires unpaid information for unpaid goods or services based on user location information. For example, the unpaid information acquisition unit 303 can also acquire unpaid information by estimating unpaid goods or services based on user location information, or it can acquire unpaid information from the first service server 10. As an example of unpaid information in Variation 2, information required for identifying unpaid goods or services (such as JAN codes) is explained. Furthermore, unpaid information is not limited to information required for identifying unpaid goods or services. In Variation 2, unpaid information can also be various types of information illustrated in the embodiments, etc.

In Variation 2, it is assumed that location relationship data, which represents the relationship between the location indicated by the user's location information and the unpaid information required for identifying unpaid goods or services, has been pre-memorized in data memory 300. The location relationship data can be in any form. For example, it can be in tabular form, numerical form, part of a program, or a machine learning model. The unpaid goods or services indicated by the unpaid information are goods or services provided at or near the location associated with the unpaid information. "Nearby" refers to the area including the location indicated by the user's location information, or a location within a predetermined distance from the location indicated by the user's location information. Depending on the location, there may be cases where no unpaid goods or services are associated with it.

For example, if an appliance store is located at or near a certain location, unpaid bill information linked to that location using location-based data is considered as unpaid goods or services, indicating the goods or services sold at the appliance store. Since appliance stores offer multiple goods or services, unpaid bill information can represent representative goods or services (e.g., most popular goods or services), as well as featured goods or services or goods or services offered during promotional activities. Similarly, if a beauty salon is located at or near a certain location, unpaid bill information linked to that location using location-based data is considered as unpaid goods or services, indicating the goods or services sold at the beauty salon. The same applies to other locations. Goods or services offered at or near other locations can be indicated in advance in the unsold information of the location relationship data as unsold goods or services.

For example, the unpaid bill information acquisition unit 303 acquires unpaid bill information that is associated with the location indicated by the user's location information based on location relationship data. That is, the unpaid bill information acquisition unit 303 acquires unpaid bill information indicating that goods or services provided at or near the location indicated by the user's location information are unpaid goods or services. The processing by the second service information acquisition unit 304 and the proposal unit 305 after the unpaid bill information is acquired can be the same as in the implementation. When combining variations 1 and 2, the second service information acquisition unit 304 acquires the second service information I40 based on the price of the unpaid goods or services indicated by the unpaid bill information associated with the location indicated by the user's location information.

As shown above, the unpaid bill information acquisition unit 303 can also obtain unpaid bill information by estimating unpaid items or services based on user location information and location relationship data. Alternatively, for example, the unpaid bill information acquisition unit 303 can also obtain unpaid bill information for unpaid items or services from the first service server 10 based on user location information. In this case, it is assumed that location relationship data is stored in the data memory unit 100 of the first service server 10. For example, the unpaid bill information acquisition unit 303 sends user location information to the first service server 10 to query unpaid bill information. The first service server 10, based on location relationship data, sends the unpaid bill information associated with the user location information to the checkout server 30. The unpaid bill information acquisition unit 303 obtains unpaid bill information from the first service server 10. If the first service server 10 can directly obtain the user's location information from the user terminal 40, then the unpaid bill information acquisition unit 303 can also obtain the unpaid bill information from the first service server 10 without querying the first service server 10.

Furthermore, the use of user location information is not limited to the examples described above. For instance, user location information may also be used not for obtaining unpaid bill information, but for proposing second service information I40. For example, the proposal department 305 may also propose second service information I40 to the user based on user location information. Furthermore, the proposal department 305 may also propose second service information I40 to the user based on both unpaid bill information and user location information. In the examples described in the embodiments, unpaid bill information refers to unpaid online goods or services. On the other hand, user location information refers to an offline location. The proposal department 305 may also propose second service information I40 to the user based on unpaid bill information (which is online information) and user location information (which is offline information).

For example, suppose the unpaid bill information represents home appliances offered through online e-commerce services (this could be a specific product or just a product type). Furthermore, suppose the user location information represents the location of an appliance retail store or its vicinity. In this case, the proposal unit 305 proposes a second service information I40 suitable for the home appliance based on this unpaid bill information and user location information. Assume that the combination of the unpaid bill information and user location information, along with the second service information I40 to be proposed to the user, is already stored in the data memory unit 300. The proposal unit 305 proposes the second service information I40 corresponding to the combination of the unpaid bill information and user location information based on this data. The proposal section 305, in addition to the second service information I40, can also propose gift information related to the first service (such as coupons). It is assumed that the necessary data for proposing gift information has also been stored in the data memory section 300.

The proposal system 1 in Variation 2 obtains information on unpaid goods or services based on user location information. Therefore, the proposal system 1 can infer unpaid goods or services based on the user's location and obtain second service information I40. For example, even if the user does not use e-commerce services, the proposal system 1 can still infer whether the user is considering certain unpaid goods or services based on the locations the user has actually visited, and obtain and propose the corresponding second service information I40 for the inferred unpaid goods or services.

Furthermore, the proposal system 1 proposes second service information I40 to the user based on the user's location information. Therefore, the proposal system 1 can provide the best proposal corresponding to the user's location, thus improving user convenience. For example, the user can know the second service information I40 corresponding to their location. If the user is located at or near an appliance store, the user can know the second service information I40 related to appliances. If the user is located at or near a baby product store, the user can know the second service information I40 related to baby products.

[6-3. Variation 3] For example, if a user has registered for a promotional activity, it is highly likely that the user is considering a product or service that is eligible for the promotion. Therefore, unsettled products or services can also be inferred based on the user's registration for the promotional activity. A promotional activity is defined as any activity that can be registered for from the user's terminal 40. In Variation 3, as an example of a promotional activity, a promotional activity for an e-commerce service with the same implementation form is explained.

The proposal system 1 in Variant Example 3 includes a promotional activity information acquisition unit 307. This unit 307 acquires promotional activity information regarding promotional activities that users have registered for in Service 1. Assume that promotional activity information is stored in Service 1 database DB1 in Variant Example 3. This promotional activity information is information that identifies promotional activities that users have registered for. For example, the promotional activity information might include the user's ID for the promotional activity they registered for, and the registration date and time.

In addition, the data memory unit 300 can also remember a database of promotional activities, which stores various information about promotional activities held in the first service. The promotional activity database may also store: the period of the promotion, the name of the promotion, the goods or services that are eligible for the promotion, the participating stores that are eligible for the promotion (for example, once a user registers for a promotion at a participating store, the user is associated with that participating store, and it is determined whether there are any unpaid goods or services provided by that participating store), the specific details of the promotion (such as gifts that the user can receive by registering for the promotion), or other information. Whenever a promotional event is held in Service 1, Server 10 of Service 1 adds the information of the promotional event to the promotional event database.

The unpaid bill information acquisition unit 303 in Variation 3 acquires unpaid bill information based on promotional activity information. As one example of unpaid bill information in Variation 3, it describes information necessary for identifying unpaid goods or services (such as JAN codes). Furthermore, unpaid bill information is not limited to information necessary for identifying unpaid goods or services. In Variation 3, unpaid bill information can also be various types of information illustrated in the embodiments. The unpaid bill information acquisition unit 303 can also acquire unpaid bill information indicating unpaid goods or services for each franchisee who is a recipient of the promotional activity.

In Variation 3, it is assumed that the relationship data representing the promotional activity indicated by the promotional activity information and the unpaid information required for identifying unpaid goods or services, is pre-memorized in the data memory unit 300. The promotional activity relationship data can be in any form. For example, it can be in tabular form, numerical form, part of a program, or a machine learning model. The unpaid goods or services indicated by the unpaid information are the goods or services that are the objects of the promotional activity associated with that unpaid information. With promotional activities, there may be cases where no association is established with any unpaid goods or services.

For example, the unpaid bill information acquisition unit 303 acquires unpaid bill information that is related to the promotional activities indicated in the promotional activity information based on promotional activity relationship data. That is, the unpaid bill information acquisition unit 303 acquires unpaid bill information that represents goods or services provided in the promotional activities indicated in the promotional activity information as unpaid goods or services. The processing of the second service information acquisition unit 304 and the proposal unit 305 after the unpaid bill information is acquired can be the same as in the implementation form. When combining variations 1 and 3, the second service information acquisition unit 304 acquires the second service information I40 based on the price of the unpaid goods or services represented by the unpaid bill information that is related to the promotional activities indicated in the promotional activity information.

The proposal system 1 in Variation 3 obtains outstanding bill information based on promotional information. Therefore, the proposal system 1 can presume outstanding goods or services based on promotional information and obtain second service information I40. For example, if a user has signed up for a promotional activity targeting goods or services that are likely of particular interest to the user, the proposal system 1 can presume whether the user is considering certain outstanding goods or services based on the promotional activity they have signed up for, and obtain and propose the corresponding second service information I40 for the presume outstanding goods or services.

[6-4. Variation 4] For example, although only one primary service is mentioned in the embodiment, there may be multiple primary services. Variation 4 illustrates the case where there are multiple primary services, each distinct from the others. The checkout service can be linked to each of the multiple primary services. For example, the checkout service can be linked to two primary services: the first e-commerce service and the second e-commerce service. The checkout service can also be linked to three or more primary services. Assuming there is a user ID link between the checkout service and the primary services, at least one of the primary service server 10 and the checkout server 30 can identify which user belongs to which user ID.

In Variation 4, it is assumed that there is a first service server 10 for each first service. The checkout server 30 can communicate with the first service servers 10 of each of the plurality of first services. The functions of each first service server 10 are the same as those of the first service server 10 described in the embodiment. Each first service server 10 remembers a first service database DB1 containing various information of users in the first service it provides, and a database containing various information of goods or services provided in the first service it provides.

In Variation 4, the unpaid information acquisition unit 303 acquires unpaid information from each of the plurality of first services. For example, the unpaid information acquisition unit 303 acquires unpaid information on unpaid goods or services provided in each of the plurality of first services from the first service server 10 of that first service. The processing of the unpaid information acquisition unit 303 in acquiring the unpaid information of each first service is as described in the embodiment. The content represented by the unpaid information of a certain first service may also differ from the content represented by the unpaid information of other first services.

In Variation 4, the second service information acquisition unit 304 acquires the second service information I40 based on the unsettled billing information of each of the plurality of first services. For example, the second service information acquisition unit 304 determines whether, among the unsettled billing information of each of the plurality of first services, at least one unsettled billing information indicates that there are unsettled goods or services. The second service information acquisition unit 304 does not acquire the second service information I40 if any unsettled billing information indicates that there are no unsettled goods or services, and acquires the second service information I40 if at least one unsettled billing information indicates that there are unsettled goods or services.

For example, the second service information acquisition unit 304 can also determine whether, among the multiple unsettled information of the first service, there exists a certain number of unsettled information indicating the existence of unsettled goods or services. The second service information acquisition unit 304 may also not acquire the second service information I40 if it is determined that there are no unsettled information indicating the existence of unsettled goods or services, and acquire the second service information I40 if it is determined that there are no unsettled information indicating the existence of unsettled goods or services.

When combining variations 1 and 4, the unpaid information of each of the plurality of first services can also represent the price of unpaid goods or services within that first service. In this case, the second service information acquisition unit 304 can also determine whether the price represented by the unpaid information of each of the plurality of first services is above a threshold. The second service information acquisition unit 304 may also not acquire the second service information I40 if it is determined that the price represented by any unpaid information is below the threshold, and acquire the second service information I40 if it is determined that the price represented by at least one unpaid information is above the threshold.

In addition, for example, the second service information acquisition unit 304 can also calculate the total or average price represented by the unsettled information of each of the plurality of first services, and determine whether the total or the average amount is above a threshold. The second service information acquisition unit 304 may also not acquire the second service information I40 if it is determined that the total or the average amount is below the threshold, and acquire the second service information I40 if it is determined that the total or the average amount is above the threshold.

The proposal system 1 in Variation 4 obtains the second service information I40 based on the unsettled information of each of the multiple first services. In this way, the proposal system 1 can comprehensively consider the potential needs of the users of the multiple first services to make more effective proposals.

[6-5. Variation 5] For example, the second service information acquisition unit 304 can also acquire the second service information I40 related to the application list of applications available on the user's user terminal 40, and specifically the application list including the second application. In Variation 5, as shown in FIG2, not only the second service information I40 representing the second application is proposed, but also the second service information I40 required for displaying the application list including other applications, not only the second application, is proposed. The second service information acquisition unit 304 acquires the second service information I40 of one example described below.

Figure 9 is an illustration of one example of the screen displayed on the user terminal 40 in Variation 5. For example, in the state of the checkout service screen SC3 in the upper left of Figure 9, once the user selects "View All" in the application list L31, as shown in the upper right of Figure 9, the user terminal 40 displays an interactive window M32 containing an application list with more applications to choose from on the display unit 45. Once the user selects any application from the application list in the interactive window M32, the user terminal 40 launches that application.

In Variation 5, once the user completes checkout, as shown in the lower left of Figure 9, the user terminal 40 displays the second service information I40, which represents the links or other information required for displaying the application overview, on the checkout completion screen SC4. The second service information I40 can also be the information required for displaying the application overview L31 of Figure 2. Once the user selects the second service information I40, as shown in the lower right of Figure 9, the user terminal 40 displays an interactive window M41, identical to the interactive window M32, on the display unit 45. The application overview in the interactive window M41 displays an installment payment application, which is one example of the second application.

For example, a user can use the second application by selecting it from the application list displayed in the interactive window M41. The physical data required for displaying the application list is assumed to be stored in the data memory unit 300. The second service information acquisition unit 304 acquires the second service information I40 required for displaying the application list, including the second application, based on this physical data. The process of proposing a service to the user after acquiring the second service information I40 is the same as in the implementation model.

The proposal system 1 in Variation 5 obtains the second service information I40 related to the application list available on the user's terminal, including the second application. The proposal system 1 can propose installment payment applications while also promoting the use of other applications besides the second application.

[6-6. Variation 6] For example, the second service information I40 may also be proposed after considering the checkout information related to the checkout performed in the checkout service. The proposal system 1 of Variation 6 also includes a checkout information acquisition unit 308 that obtains checkout information related to the checkout performed by the user in checkout services different from the first and second services. Sometimes, users will perform the checkout operations from the user terminal 40. For example, the operation required to start the checkout application, the operation required to display code C30, the operation required to have code C30 read by the store terminal 50, or other operations performed by the user are equivalent to the user using the user terminal 40 to perform the checkout. The information processing required for checkout is performed by the checkout execution unit 301.

Checkout information can be any information related to the checkout process. For example, checkout information can be all or part of the information contained in the checkout request received by the checkout server 30 from at least one of the user terminal 40 and the store terminal 50. Checkout information may also be information that is not included in the checkout request, but rather information indicating the result of the checkout process. That is, checkout information can also be information indicating whether the checkout has been completed.

In this embodiment, the checkout information acquisition unit 308 acquires checkout information indicating the amount due at checkout. For example, the checkout information indicating the amount due is included in the checkout request. The checkout information acquisition unit 308 acquires the checkout information included in the checkout request. Since the amount due is displayed in the checkout history information after checkout is executed, the checkout information acquisition unit 308 can also acquire the checkout information by acquiring the portion indicating the amount due from the checkout history information. Furthermore, the checkout information can also indicate other content besides the amount due. For example, the checkout information can also indicate the checkout location, the goods or services being checked, the checkout time, or other information.

In Variation 6, the second service information acquisition unit 304 acquires the second service information I40 based on the checkout information. For example, the second service information acquisition unit 304 determines whether the checkout amount indicated by the checkout information is above a threshold. The threshold is the amount used as the basis for determining whether to acquire the second service information I40. The threshold can be common to all users or can be specific to each user. For example, different thresholds can be set according to demographic information such as the user's gender or age group. The threshold is stored in the data memory unit 300.

For example, the second service information acquisition unit 304 acquires the second service information I40 of the installment payment application if it determines that the billing amount indicated by the billing information is above the threshold. If it determines that the billing amount indicated by the billing information is below the threshold, the second service information acquisition unit 304 does not acquire the second service information I40 of the installment payment application. If it determines that the billing amount indicated by the billing information is below the threshold, the second service information acquisition unit 304 may also acquire other information, such as advertisements, displayed instead of the second service information I40. It is assumed that the data of these other information is also stored in the data memory unit 100.

Furthermore, the second service information acquisition unit 304 can also acquire the second service information I40 based on the checkout location, the goods or services being checked out, the checkout time, or other information indicated in the checkout information. For example, the second service information acquisition unit 304 can also acquire the second service information I40 of the second application provided by the store located at the checkout location indicated in the checkout information. The second service information acquisition unit 304 can also acquire the second service information I40 of the second application provided by the store located near the checkout location indicated in the checkout information. The second service information acquisition unit 304 can also acquire the second service information I40 indicating a coupon for goods or services similar to those being checked out.

Furthermore, the proposal department 305 can also determine the relevance of the checkout information to the unchecked goods or services, and based on the determination, propose second service information I40 to the user. For example, suppose the unchecked goods or services are home appliances. Then, suppose the checkout information indicates that the store or location where the user checked out is a home appliance supermarket. In this case, the proposal department 305 determines that the user is looking for home appliances (i.e., determines that the checkout information is related to the unchecked goods or services), and can also propose second service information I40 related to home appliances to the user. In addition, for example, suppose the unchecked goods or services are baby products. Furthermore, assuming the checkout information indicates that the item purchased by the user is a baby product, or that the store where the user made the checkout is a baby product store, the proposal department 305 can also presume that the user is looking for baby products and propose the second service information I40 related to baby products to the user.

The proposal system 1 in Variation 6 obtains the checkout information related to the user's previous checkout transactions from the checkout service. Based on the checkout information, the proposal system 1 also obtains the second service information I40. Therefore, the proposal system 1 can propose not only the checkout information but also the corresponding second service information I40 from the checkout service side, thus providing the user with more useful information.

[6-7. Other variations] For example, the above variations can also be combined.

For example, in one implementation, a user might use a checkout application to access the checkout service. However, the user could also use a browser on user terminal 40 to access the checkout service. In this case, the user could also have the store terminal 50 read the code C30 displayed in the browser and perform the checkout without specifically using code C30, thus completing the online checkout without going through a store. Online checkout only requires operations on user terminal 40 to be completed. For example, the user could also perform checkout for online e-commerce transactions, e-book services, travel booking services, communication services, or other services from the browser. The proposal system 1 can also propose the second service information I40 in the checkout completion screen SC4 of such online checkout. In this case, the second service information I40 can also be used to propose information required by the checkout application to the user.

For example, the functions described and implemented in checkout server 30 can also be implemented in first server 10, second server 20, user terminal 40, store terminal 50, or other computers. The functions described and implemented in checkout server 30 can also be shared by multiple computers.

1: Proposal System N: Network 10: First Server 11, 21, 31, 41, 51: Control Unit 12, 22, 32, 42, 52: Memory Unit 13, 23, 33, 43, 53: Communication Unit 20: Second Server 30: Checkout Server 40: User Terminal 44, 54: Operation Unit 45, 55: Display Unit 46: Camera Unit 50: Store Terminal 56: Reading Unit 100, 200, 300, 400, 500: Data Memory Unit 301, 501: Checkout Execution Unit 302: Checkout Judgment Unit 303: Unchecked Information Acquisition Unit 304: Second Server Information Acquisition Unit 305: Proposal Unit 306: User Location Information Acquisition Department 307: Promotional Activity Information Acquisition Department 308: Checkout Information Acquisition Department 401: Operations Processing Department 402: Display Control Department C30: Code DB1: First Service Database DB2: Checkout Service Database I10, I11, I12: Icons L31: Application Overview I40: Second Service Information SC1: Menu Screen SC2: First Service Screen SC3: Checkout Service Screen SC4: Checkout Complete Screen

[Figure 1] An illustration of an example of the hardware configuration of a proposal system. [Figure 2] An illustration of an example of the screen displayed on the user terminal. [Figure 3] An illustration of an example of the functions implemented in the proposal system. [Figure 4] An illustration of an example of the first service database. [Figure 5] An illustration of an example of the checkout service database. [Figure 6] An illustration of an example of the processing performed in the proposal system. [Figure 7] An illustration of an example of the processing performed in the proposal system. [Figure 8] An illustration of an example of the functions implemented in the variant example. [Figure 9] An illustration of an example of the checkout completion screen of variant example 5.

10: Server 1

20: Second Service Server

30: Checkout Server

40: User Terminal

50: Shop Terminals

100,200,300,400,500: Data Memory Department

101: First Service Department

201: Second Service Provision Department

301, 501: Checkout Execution Department

302: Checkout Judgment Department

303: Unsettled Bill Information Acquisition Department

304: Second Service Information Acquisition Department

305: Proposal Department

401: Operations and Reception Department

402: Display Control Unit

DB1: First Service Database

DB2: Checkout Service Database

Claims (13)

A proposal system includes: an unpaid bill information acquisition unit, which acquires unpaid bill information regarding unpaid goods or services that a user has not yet settled, and which were previously unpaid goods or services provided in the first service; and a billing determination unit, which determines whether the user has performed a billing transaction for goods or services different from the previously unpaid goods or services in a billing service different from the previously unpaid first service and a billing transaction for a second service different from the previously unpaid first service; and a second service information acquisition unit, which, based on the unpaid bill information, acquires second service information regarding the previously unpaid second service if it is determined that the user performed a previous billing transaction for goods or services different from the previously unpaid first service. The Proposal Department is for users of the previous section to submit the second service information of the previous section. As described in Request 1, the Pre-registration Proposal Department proposes Pre-registration Second Service Information to the Pre-registration User on the checkout completion screen indicating that the Pre-registration checkout has been completed. As described in Request 1 or 2, the proposed system, wherein: The first service mentioned above is an e-commerce service; the outstanding balance information acquisition department acquires outstanding balance information of outstanding goods or services that the user is considering purchasing within the e-commerce service. As described in Request 1 or 2, the proposal system includes: ... A proposal system includes: a user location information acquisition unit that acquires user location information about the user's location; and an unpaid bill information acquisition unit that, based on location relationship data, acquires previous unpaid bill information for previous unpaid goods or services by establishing a relationship between the location indicated by previous user location information and unpaid bill information for previous unpaid goods or services provided in the first service, which is stored in a data memory unit. The Second Service Information Acquisition Department determines the existence of previously unpaid goods or services based on previously unpaid information, and based on the result of the determination, acquires second service information concerning a second service that differs from the previously stated first service; and the Proposal Department proposes previously stated second service information to previously stated users. The proposal system described in request item 1 or 2, wherein: The aforementioned proposal system further includes: a user location information acquisition unit, which acquires user location information about the location of the aforementioned user; and a aforementioned proposal unit, which proposes the aforementioned second service information to the aforementioned user based on the aforementioned user location information. A proposal system includes: a promotional activity information acquisition unit, which acquires promotional activity information regarding promotional activities that users have registered for in the first service; and an outstanding bill information acquisition unit, which, based on the previous promotional activity information, acquires outstanding bill information regarding outstanding goods or services that were provided to previous users in the first service, and which are outstanding goods or services provided in the first service; and a second service information acquisition unit, which, based on the previous outstanding bill information, determines the existence of outstanding goods or services, and, based on the determination result, acquires second service information regarding a second service different from the first service; and a proposal unit, which proposes the previous second service information to previous users. As described in Request 1 or 2, the ... A proposal system comprising: an outstanding bill information acquisition unit, which acquires outstanding bill information regarding unpaid goods or services for which the user has not yet settled, and which pertains to previously unpaid goods or services provided in the first service; and a second service information acquisition unit, which, based on the previously unpaid bill information, determines the existence of previously unpaid goods or services, and based on the determination result, acquires a list of applications available on the user's terminal, including second service information related to the list of previously used applications, which includes second applications required for the previously used user to utilize a second service different from the previously provided first service; and a proposal unit, which proposes the previously used second service information to the previously used user. As described in Request 1 or 2, the Pre-recorded Service 2 Information Acquisition Department acquires the Pre-recorded Service 2 Information used to support the settlement of Pre-recorded Unsettled Goods or Pre-recorded Unsettled Services. As described in Request 1 or 2, the aforementioned proposal system further includes: a checkout information acquisition unit, which acquires checkout information regarding checkouts performed by the previous user in checkout services different from the previous first service and the previous second service; and a previous second service information acquisition unit, which further acquires previous second service information based on the previous checkout information. One proposal method is executed by a computer: A step for obtaining unpaid information involves obtaining unpaid information regarding unpaid goods or services that the user has not yet settled, specifically information concerning previously unpaid goods or services provided in the first service; and a step for determining settlement status involves determining whether the user has settled for goods or services different from those previously unpaid items or services in a settlement service different from the first service and a second service different from the first service; and a step for obtaining second service information involves obtaining second service information regarding the second service based on the unpaid information, in cases where it is determined that the user has settled for goods or services different from those previously settled. The proposal process involves submitting the second service information to the user. A program product, used to enable a computer to perform functions, comprises: an unpaid bill information acquisition unit, which acquires unpaid bill information regarding unpaid goods or services that the user has not yet settled, and which is related to previously unpaid goods or services provided in the first service; a billing determination unit, which determines whether the user has performed a billing transaction for goods or services different from those previously unpaid items or services in a billing service different from the first service or a second service different from the first service; and a second service information acquisition unit, which, based on the unpaid bill information, acquires second service information regarding the second service if it is determined that the user has performed a previous billing transaction for goods or services different from those previously performed. The Proposal Department is for users of the previous section to submit the second service information of the previous section.