Over-the-counter sales support system for requested commodity

Abstract

To provide a store with information useful for suppressing defective stock and disposal loss of a requested commodity when receiving a request of a commodity desired to be sold over the counter from a user and selling the commodity over the counter.SOLUTION: There is provided a system that receives a request for a product desired to be sold at a store from a user and supports sales of the product (requested product) related to the request at the store. The predicted total number of purchases of a requested product by a user who has made a request (request user) at a store is calculated on the basis of history information of products purchased at the store by the request user. On the basis of the predicted total number of purchases, recommendation information about the over-the-counter sales of the requested commodity is generated and transmitted to the information terminal of the store.SELECTED DRAWING: Figure 6

Description

[Technical Field]

[0001] The present disclosure relates to a system that receives requests from users for products they wish to sell in stores and supports the in-store sales of the requested products. [Background technology]

[0002] Japanese Patent Application Laid-Open Publication No. 2016-071450 discloses a system that allows users of a chain store to request products they would like to see in the chain store. When this conventional system receives a request for a desired product from a user terminal, it registers the request as request information. In addition to information about the desired product, the request information includes optional information such as the name of the store where the user plans to purchase the desired product, the day of the week, and the time period. The decision of whether to accept the request is left to each store in the chain store. When the desired product is placed in the store in response to the request, a notification to that effect is sent to the user terminal that sent the request.

[0003] In addition to JP 2016-071450 A, examples of documents showing the technical state of the art in the technical field related to the present disclosure include JP 2007-102481 A and JP 2023-092350 A. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2016-071450 A [Patent Document 2] International Publication No. 2021 / 095290 Summary of the Invention [Problem to be solved by the invention]

[0005] According to the conventional system described above, by taking into consideration optional information such as the store name, day of the week, and time of day, it may be possible to narrow down the store and date and time that the user plans to visit and sell the desired product in-store. Furthermore, by sending a notification to the user's terminal, it may be possible to encourage the user to purchase the desired product in-store. However, the decision as to whether to purchase the desired product in-store is up to the user, and there is a possibility that the desired product will not be purchased in-store. Selling the desired product in-store without considering such possibilities carries the risk of generating dead stock and waste.

[0006] One objective of the present disclosure is to provide a technology that can provide a store with information useful for reducing dead stock and waste of requested products when a request for a product to be sold in-store is received from a user and the product is sold in-store. [Means for solving the problem]

[0007] The in-store sales support system for requested products according to the present disclosure is a system that accepts requests from users for products they wish to sell in a store and supports the store in selling the requested products, and has the following features. The system includes one or more storage devices and one or more processors. The one or more storage devices store user information about the user and request acceptance information. The one or more processors are configured to perform various processes. The user information includes identification information of the user and history information of products purchased by the user at the store. The acceptance information includes requesting user identification information indicating the user who requested the requested product. The one or more processors are configured to perform the following processes: identifying historical information about products purchased by the requesting user based on the user's identification information and the requesting user's identification information; calculating a predicted total number of purchases of the requested product by the requesting user at the store based on the historical information about the purchases of the requested product by the requesting user; generating recommended information about in-store sales of the requested product based on the predicted total number of purchases of the requested product by the requesting user; and transmitting the recommended information to an information terminal of the store. [Effects of the Invention]

[0008] According to the in-store sales support system for requested products disclosed herein, a predicted total number of purchases of the requested product by the requesting user at the store is calculated based on the purchase history information of the product at the store by the requesting user. Furthermore, based on this predicted total number of purchases, recommendation information regarding in-store sales of the requested product is generated and transmitted to an information terminal of the store. The recommendation information generated based on the predicted total number of purchases of the requested product by the requesting user is expected to reduce dead stock and waste compared to when the requested product is sold in-store simply according to the total number of requests for the requested product by the requesting user. [Brief explanation of the drawings]

[0009] [Figure 1] 1 is a diagram illustrating a configuration example of a store sales support system for a requested product according to an embodiment of the present disclosure. [Figure 2] 10A and 10B are diagrams illustrating an example of various information used in the request voting process. [Figure 3] 10 is a flowchart illustrating an example of a request voting process. [Figure 4] 10 is a flowchart illustrating an example of a request voting process. [Figure 5] 10 is a flowchart illustrating an example of a request voting process. [Figure 6]10 is a flowchart illustrating an example of processing performed to add recommended information regarding in-store sales that are the subject of a request vote. DETAILED DESCRIPTION OF THE INVENTION

[0010] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. In each drawing, the same or corresponding parts are denoted by the same reference numerals, and the description thereof will be simplified or omitted.

[0011] 1. System configuration example FIG. 1 is a diagram illustrating an example of the configuration of a requested product in-store sales support system (hereinafter also simply referred to as "system") according to an embodiment of the present disclosure. Illustrated in FIG. 1 are a requested product voting system 10, a payment system 20, a store management terminal 30, and a vote acceptance terminal 40. These elements constitute the system according to the embodiment.

[0012] The system according to the embodiment supports commercial activities in a way that benefits both the store ST and the user US. The store ST is, for example, a tenant store (e.g., a grocery store, a general merchandise store, or a restaurant) that rents a section of a facility and operates in that space. Examples of the facility include commercial facilities (e.g., shopping malls and commercial buildings). The user US is a consumer of the products sold by the store ST. The user US is, for example, a resident of the town or city where the store ST is located.

[0013] The voting system 10 provides a service (hereinafter also referred to as the "request voting service") that covers everything from collecting the needs of the user US based on a request vote by the user US to encouraging the user US to visit the store ST and purchase products.

[0014] The voting system 10 includes a communication device 11, one or more processors 12 (hereinafter simply referred to as "processors 12"), and one or more storage devices 13 (hereinafter simply referred to as "storage devices 13"). The communication device 11 communicates with the payment system 20, the store management terminal 30, and the vote acceptance terminal 40 via a wired or wireless communication network.

[0015] The processor 12 executes various processes. Examples of the processor 12 include a general-purpose processor, a specific-purpose processor, a central processing unit (CPU), a graphics processing unit (GPU), an application specific integrated circuit (ASIC), and a field-programmable gate array (FPGA). The storage device 13 stores various information required for various processes. Examples of the storage device 13 include a volatile memory, a non-volatile memory, a hard disk drive (HDD), and a solid state drive (SSD).

[0016] The processor 12 may execute a computer program. The computer program is stored in, for example, the storage device 13. The computer program may be recorded on a computer-readable recording medium. The functions of the voting system 10 may be realized by cooperation between the processor 12 executing the computer program and the storage device 13.

[0017] The payment system 20 provides a service (payment service) for payment of at least one of the products sold at the store ST and the services provided at the store ST. The basic configuration of the payment system 20 is the same as that of the voting system 10. That is, the payment system 20 includes a communication device, one or more processors (hereinafter simply referred to as "processors"), and one or more storage devices (hereinafter simply referred to as "storage devices").

[0018] The storage device of the payment system 20 stores a database of various information related to the payment service (e.g., product transaction data, product master data). The processor of the payment system 20 executes processing related to payment for products by the user US. In the payment processing, the processor authenticates the user US (e.g., facial recognition) using, for example, a camera installed in the store ST. Once authentication is complete, the processor accepts the payment operation by the user US using the payment function of the vote acceptance terminal 40. Once payment is complete, the processor transmits the payment result of the user US to the store ST (e.g., the vote acceptance terminal 40). The processor also transmits payment information to the voting system 10. The payment information includes information such as the identification information of the user US who made the payment, and the details, quantity, and amount of the product for which payment has been completed by the user US.

[0019] The store management terminal 30 is an information terminal that manages the products sold by the store ST. The basic configuration of the store management terminal 30 is the same as that of the voting system 10. As part of the management of the products sold by the store ST, the store management terminal 30 manages ordering products to wholesalers and receiving products. The store management terminal 30 sends and receives various information related to the request voting service to and from the voting system 10.

[0020] The vote acceptance terminal 40 is an information terminal operated by the user US. The basic configuration of the vote acceptance terminal 40 is the same as that of the voting system 10. Examples of the vote acceptance terminal 40 include an information terminal of the store ST (e.g., an in-store tablet) used to pay for products at the store ST, and an information terminal of the user US (e.g., a smartphone) used for this payment. The vote acceptance terminal 40 transmits and receives various information related to the request voting service to and from the voting system 10.

[0021] 2. Request Voting The various processes executed by the processor 12 include processes related to request voting (hereinafter also referred to as "request voting processes"). The storage device 13 stores various types of information used in the request voting processes. Figure 2 is a diagram illustrating an example of the various types of information used in the request voting processes. In the example shown in Figure 2, the various types of information include store information DST and user information DUS. When there are multiple stores ST that use the request voting service, the store information DST and user information DUS are managed for each store ST that uses the request voting service.

[0022] In the example shown in FIG. 2, the store information DST includes identification information of the store ST that uses the request voting service, sales product information, sales history information, voting holding information, and voting result information.

[0023] The identification information includes, for example, the ID number of the store ST and the attributes of the store ST (for example, business format, business scale). The sales product information includes, for example, the ID number of a product currently on sale at the store ST and the attributes of this product. The sales product information is acquired from an information terminal of the store ST (for example, the store management terminal 30). The attributes of a product are set by appropriately combining elements that make up the product's master data (for example, category, size, weight, color, sales target, release date, etc.). The sales history information is generated based on payment information from the payment system 20. The sales history information includes, for example, the ID number of a sold product, the date and time of sale of this product, the number sold, the sales price, and the ID number of the purchaser.

[0024] The voting information is information related to the request voting. The voting information includes, for example, the ID number of the request voting, the voting theme (e.g., "Sweets that make you feel spring"), the voting acceptance period (e.g., the start date and time and the end date and time), and information on the voting target (e.g., the ID number, attributes, estimated selling price, product image, description, etc.). The voting information is acquired from an information terminal of the store ST (e.g., the store management terminal 30). The voting result information is information related to the result of the request voting. The voting result information includes, for example, the ID number of the request voting, the voting theme, the voting acceptance period, and information on the voting target (e.g., the voting ranking, the number of votes, the vote percentage, etc.).

[0025] Here, the voting targets included in the voting information include products currently being sold by the store ST (existing products) and products that the store ST is considering stocking and selling in the near future (for example, next month) (new products). Examples of new products include products newly produced by manufacturers and products that are already on the market but have not yet been sold by the store ST. New products also include improved products that are released after improving existing products. Even if the store ST has been selling existing products, when an improved product is released, the improved product is treated as a new product. Note that existing products and improved products are distinguished by, for example, referring to the product's master data (release date).

[0026] In the example shown in FIG. 2, the user information DUS also includes identification information, purchase history information, and voting history information of the user US.

[0027] The identification information includes the ID number of the user US, the attributes of the user US (e.g., gender, age, family composition), and the preferences of the user US (purchasing preferences, voting preferences, etc.). The identification information may also include the identification information of the information terminal of the user US and facial image information required for authenticating the user US. The purchase history information includes the ID number of the product that the user US purchased at the store ST, the attributes of this product, and information on the purchase date and time, number of units purchased, and purchase price of this product. The voting history information is information related to the history of when the user US cast a vote in response to a request vote proposal made by the store ST. Examples of voting history information include the ID number of the request vote, the voting target for which the user US voted, the attributes of the voting target, the voting date and time, and the total number of votes for the voting target.

[0028] The flow of the request voting process will be described with reference to Figures 3, 4 and 5. Figures 3, 4 and 5 are flowcharts showing an example of the request voting process performed by the voting system 10 (processor 12).

[0029] The processing routine shown in Fig. 3 is repeatedly executed at predetermined intervals (for example, every day, week, or month). In the processing routine shown in Fig. 3, first, store information DST is acquired (step S11). An example of the configuration of the store information DST is as described with reference to Fig. 2.

[0030] Following the processing of step S11, it is determined whether or not there is a request to hold a vote (step S12). For example, if the store information DST (voting information) acquired in step S11 has been updated, it is determined that there is a request to hold a vote.

[0031] If the determination result in step S12 is negative, the current process ends. If the determination result in step S12 is positive, voting proposal information is generated (step S13). The voting proposal information is information that proposes a request vote for a voting target to the user US of the store ST from which the store information DST was obtained. The voting proposal information is generated based on the voting holding information obtained in step S11. The voting proposal information is generated, for example, by assigning multiple voting targets to each request vote ID number or voting theme.

[0032] The processing routine shown in Fig. 4 is executed repeatedly at a predetermined interval during the voting acceptance period for the request vote. In the processing routine shown in Fig. 4, first, it is determined whether or not payment information has been received (step S21). As already explained, the payment information is transmitted from the payment system 20 to the voting system 10 when the user US pays for a product at the store ST.

[0033] If the determination result of step S21 is negative, this processing ends. If the determination result of step S21 is positive, vote proposal information is sent (step S22). The destination of the proposed vote information is the vote acceptance terminal 40 used by the user US to pay for the product. The vote acceptance terminal 40 is an information terminal of the store ST (e.g., an in-store tablet) or an information terminal of the user US (e.g., a smartphone).

[0034] Following the processing of step S22, it is determined whether or not voting response information has been received (step S23). The voting response information is information that is input to the voting reception terminal 40 by operation of the user US as a response to the voting proposal information output from the voting reception terminal 40. Whether or not voting response information has been received is determined, for example, based on whether or not the voting response information has been received before a predetermined time has elapsed since the transmission of the voting proposal information.

[0035] If the determination result in step S23 is negative, this processing ends. If the determination result in step S23 is positive, feedback information (FB information) based on the interim voting results is generated and transmitted (step S24). The interim voting results are real-time information generated based on voting result information that sequentially reflects response information during the voting acceptance period. The feedback information generated in step S24 is intended for user US (request user, hereinafter also referred to as "user USr") who responded (voted) in response to the voting proposal. Examples of feedback information include the number of interim votes for each of multiple voting targets. By feeding back such interim information to user USr, the preferences of other users USr can be learned. It is also possible to give user USr a sense of satisfaction that they are cooperating with the management of store ST.

[0036] The processing routine shown in Fig. 5 is repeatedly executed at predetermined intervals (for example, every day, week, or month). In the processing routine shown in Fig. 5, first, store information DST and user information DUS are acquired (step S31). Configuration examples of the store information DST and user information DUS are as described with reference to Fig. 2.

[0037] Following the process of step S31, it is determined whether or not the voting acceptance period has ended (step S32). Whether or not the voting acceptance period has ended is determined based on the voting opening information or the voting result information (voting acceptance period).

[0038] If the determination result in step S32 is negative, this processing ends. If the determination result in step S32 is positive, feedback information (FB information) based on the final voting result is generated and transmitted (step S33). The final voting result is the final information that reflects all of the response information during the voting acceptance period. The feedback information generated in step S33 includes information directed to user US and information directed to store ST that requested the holding of the vote. The feedback information may be provided to user US who responded (voted) in response to the voting proposal (i.e., user USr), or to user US who did not respond (vote) (non-requesting user, hereinafter also referred to as "user USnr").

[0039] An example of feedback information for user US is the final number of votes for multiple voting targets. By feeding back such final information to user US, it is possible to provide user USr with information about the possibility that the voting target for which he or she voted will be available for purchase at store ST in the near future. It is also possible to provide user USnr with information that a request vote has been held and about the possibility that the voting target will be available for purchase at store ST in the near future. Feedback information for user US can be sent by, for example, identifying the information terminal of user US based on user information DUS (identification information).

[0040] The feedback information for the store ST is transmitted to an information terminal of the store ST (for example, the store management terminal 30). The feedback information for the store ST includes the final number of votes for each of the multiple voting targets, the attributes of the users US who voted for each voting target, and the like. By feeding back each final number of votes to the store ST, the store ST can be provided with information to consider when deciding whether to replace a product. Each final number of votes may also be a sales forecast for each voting target. In this case, the sales forecast can be made using a prediction model (statistical model) based on machine learning. The attributes of the users US who voted for the voting targets can be generated, for example, based on user information DUS (voting history information). By feeding back the attributes of the users US to the store ST, it becomes possible to provide the store ST with information to select voting targets for subsequent request votes.

[0041] 3. Recommended information for in-store sales In the embodiment, consider the case where, if the final number of votes for a certain voting object is 1 or more, the store ST decides to sell this voting object in-store. The reason for this is that if a voting object with a final number of votes of 1 or more is sold in the store ST, it is expected that the user US who voted for this voting object (i.e., user USr) will purchase it. However, it is up to the user US to decide whether to purchase the voting object in-store, and as a result, there is a possibility that the voting object will not be purchased in-store.

[0042] Therefore, in the embodiment, in the request voting process, a process is performed to add recommended information about the in-store sale to be voted for to feedback information to the store ST that requested the holding of the vote. Figure 6 is a flowchart showing an example of the process performed by the voting system 10 (processor 12) to add recommended information about the in-store sale to be voted for. Note that the processing routine shown in Figure 6 is performed, for example, as a subroutine of the process of step S33 shown in Figure 5.

[0043] 6, first, the store information DST and the user information DUS are acquired (step S41). The process of step S41 is the same as the process of step S31 in FIG.

[0044] Following the processing of step S41, user USr (requesting user) and user USnr (non-requesting user) are identified (step S42). In the processing of step S42, for example, based on store information DST (voting holding information) and user information DUS (voting history information), users US who participated in the request voting during the voting acceptance period (i.e., users USr) and users US who did not participate (i.e., users USnr) are identified. By performing the processing of step S42, the user information DUS of user USr and the user information DUS of user USnr are each identified.

[0045] Following the processing of step S42, the predicted total number Nr of purchases of the voting target by user USr is calculated (step S43). In the processing of step S43, first, the attributes of the voting target for which user USr voted in the request voting during the voting acceptance period are identified based on the user information DUS (voting history information) of user USr identified in the processing of step S42. Next, based on the attributes of the voting target and user information DUS (purchase history information) of user USr, products having attributes identical to or similar to the attributes of the voting target (hereinafter also referred to as "equivalent products EGr") are identified from among the products purchased in the past by user USr.

[0046] By identifying the equivalent product EGr, the purchase history of the equivalent product EGr by the user USr is identified. The purchase history of the equivalent product EGr includes information indicating the user USr's purchasing tendency for the equivalent product EGr, such as the purchase date and time and the number of units purchased. In the processing of step S43, if the voting target is sold in a store, the predicted total number Nr of purchases of the voting target by the user USr is calculated under the assumption that the purchasing tendency of the voting target by the user USr will match the purchasing tendency of the equivalent product EGr. The predicted total number Nr of purchases can be calculated using, for example, a prediction model (statistical model) based on machine learning. The predicted total number Nr of purchases may be for a short period (e.g., a few days or a week) or a long period (e.g., a month or several months). The predicted total number Nr of purchases is an example of recommended information regarding in-store sales of the voting target.

[0047] Following the processing of step S43, the predicted total number Nnr of purchases for which user USnr will vote is calculated (step S44). In the processing of step S44, first, based on the attributes of user USr and the attributes of user USnr, users USnr having the same or similar attributes as user USr (hereinafter also referred to as "equivalent users USe") are identified. Equivalent users USe may be identified from among users USnr having the same or similar product purchase history as user USr, or from among users USnr having the same or similar preferences as user USr.

[0048] By identifying the equivalent user USe, the product purchase history of the equivalent user USe is identified. In the processing of step S44, next, based on the attributes of the voting target of the request vote during the voting acceptance period and the product purchase history of the equivalent user USe, a product (hereinafter also referred to as "equivalent product EGnr") having the same or similar attributes as the voting target is identified from among the products previously purchased by the equivalent user USe. By identifying the equivalent product EGnr, the purchase history of the equivalent product EGnr by the equivalent user USe is identified.

[0049] The purchase history of the equivalent product EGnr includes information indicating the equivalent user USe's purchasing tendency for the equivalent product EGnr, such as the purchase date and time and the number of units purchased. In the processing of step S44, if the voting target is sold in a store, the equivalent user USe's purchasing tendency for this voting target will be consistent with the purchasing tendency for the equivalent product EGnr, and the predicted total purchase number Nnr of the voting target by the equivalent user USe is calculated. The predicted total purchase number Nnr is also an example of recommended information regarding in-store sales of the voting target.

[0050] In the processing of steps S43 and S44, the parameters used in calculating the predicted total purchase quantity Nr (step S43) and the predicted total purchase quantity Nnr (step S44) may be added as supplementary information to the predicted total purchase quantity Nr and the predicted total purchase quantity Nnr as recommended information regarding the in-store sales being voted for.

[0051] Following the processing of step S44, the predicted total purchase quantity Nr of the voting target by user USr is corrected (step S45). In the processing of step S45, first, the attributes of the voting target for which user USr voted in the request vote during the voting acceptance period are identified based on the user information DUS (voting history information) of user USr identified in the processing of step S42. Next, an equivalent product EGr is identified based on the attributes of the voting target for which user USr voted in the request vote during the voting acceptance period and the user information DUS (purchase history information) of user USr. Up to this point, the processing is the same as that of step S43.

[0052] In the processing of step S45, next, based on the attributes of the voting target for which user USr voted in request voting during the voting acceptance period and user information DUS (voting history information) of user USr, a product (hereinafter also referred to as "equivalent product EGer") having attributes identical to or similar to the attributes of the voting target is identified from among the voting targets (past requested products) for which user USr voted in past request voting. By identifying the equivalent product EGer, the voting history of user USr for the equivalent product EGer is identified. The voting history of user USr for the equivalent product EGer includes the total number of votes for the equivalent product EGer in past request voting (i.e., the total number of requests).

[0053] In step S45, the total number of purchases of the equivalent product EGr by user USr is divided by the total number of votes (total number of requests) for the equivalent product EGr by user USr, thereby calculating the request fulfillment rate by user USr (0<fulfillment rate≦1.0). In step S45, under the assumption that the higher the request fulfillment rate, the higher the purchase rate of this voting target if it were sold in stores, the predicted total purchase number Nr of the voting target by user USr calculated in step S43 is corrected based on the request fulfillment rate.

[0054] Following the processing of step S45, the in-store sales risk of the voting target is predicted based on the attributes of the voting target of the request vote during the voting acceptance period (step S46). In the processing of step S46, for example, based on the attributes (planned sales price) of the voting target, it is predicted that selling many voting targets with high planned sales prices in-store will pose a risk to the store ST (large losses in the event of dead stock). The in-store sales risk is also an example of recommended information regarding in-store sales of the voting target.

[0055] In another example, based on the attributes (size) of the voting target, it is predicted that selling a large number of large voting targets at the same time in the store will pose a risk to the store ST (taking up display space for other products). In yet another example, based on the attributes (expiration date, best-before date) of the voting target, it is predicted that selling a large number of voting targets with expiration dates at the same time in the store will pose a risk to the store ST (large losses due to disposal). In yet another example, based on the attributes (category, sales target) of the voting target, it is predicted that the voting target will compete with products currently being sold in the store ST, posing a risk to the store ST (a decrease in sales of existing products).

[0056] 4.Effects As described above, according to the embodiment, a request voting process is performed. The request voting process collects voting result information for products currently on sale by the store ST (existing products) and products that the store ST is considering stocking and selling in the near future (new products), and generates and transmits various types of feedback information to the user US and the store ST.

[0057] In particular, according to the embodiment, recommendation information based on the predicted total purchase numbers Nr and NNr of the voting target is added to the feedback information for the store ST. Therefore, it is expected that dead stock and waste loss can be reduced compared to when the voting target is sold in stores simply according to the total number of requests for the voting target by the user USr. [Explanation of symbols]

[0058] 10... Voting system, 11... Communication device, 12... Processor, 13... Storage device, 20... Payment system, 30... Store management terminal, 40... Voting reception terminal, ST... Store, US... User, DUS... User information, DST... Store information

Claims

1. A system for receiving a request from a user for a product that the user wishes to sell at a store and supporting the store in selling the requested product, comprising: one or more storage devices in which user information about the user and information about the acceptance of the request are stored; one or more processors that perform various processes; the user information includes identification information of the user and history information of products purchased by the user at the store; the reception information includes identification information of a requesting user that indicates the user who requested the requested product; the one or more processors: a process of identifying history information of products purchased by the requesting user based on the user identification information and the requesting user identification information; A process of calculating a predicted total purchase quantity of the requested product by the requesting user at the store based on purchase history information of the requested product by the requesting user; generating recommendation information regarding in-store sales of the requested product based on the predicted total number of purchases of the requested product by the requesting user; a process of transmitting the recommendation information to an information terminal of the store; The in-store sales support system for requested products is characterized by:

2. 10. The system of claim 1, The reception information further includes attributes of the requested product, The history information of the purchased products by the user includes attributes of the purchased products and the number of purchased products; A process of calculating a predicted total number of purchases of the requested product by the requesting user, and a process of identifying, from the purchase history information of the requested product, history information of an equivalent product having the same or similar attributes as the requested product, based on the attributes of the requested product and the attributes of the purchased product included in the purchase history information of the requested product by the requesting user; The total number of predicted purchases of the requested product by the requesting user is calculated based on the number of purchases of the equivalent product included in the history information of the equivalent product having the same or similar attributes as the requested product. The in-store sales support system for requested products is characterized by the above.

3. 3. The system according to claim 1 or 2, The history information of the purchased products by the user includes attributes of the purchased products and the number of purchased products; The user information further includes history information of requests made by the user; The history information of requests made by the user includes attributes of products requested by the user in the past and a total number of requests for the products requested in the past; the one or more processors further a process of identifying history information of requests made by the requesting user based on the user identification information and the requesting user identification information; a process of identifying historical information of an equivalent product having the same or similar attributes as the previously requested product from the historical information of the purchased product based on attributes of the previously requested product included in the historical information of the request by the requesting user and attributes of the purchased product included in the historical information of the purchased product by the requesting user; and calculating a request fulfillment rate by the requesting user based on the number of purchases of equivalent products having the same or similar attributes as the previously requested product, which is included in history information of the equivalent products, and the total number of requests for the previously requested product, which is included in history information of requests by the requesting user; The total number of predicted purchases of the requested product by the requesting user is corrected based on the request fulfillment rate. The in-store sales support system for requested products is characterized by the above.

4. 3. The system according to claim 1 or 2, The user information further includes attributes of the user; the one or more processors further a process of identifying attributes of the requesting user and attributes of a non-requesting user indicating the user who has not requested the requested product, based on the user identification information and the requesting user identification information; A process of identifying an equivalent user having the same or similar attributes as the requesting user from among the non-requesting users based on the attributes of the requesting user and the attributes of the non-requesting users; and calculating a predicted total number of purchases of the requested product by the equivalent user based on purchase history information of the equivalent user; The recommendation information is generated based on a predicted total number of purchases of the requested product by the requesting user and a predicted total number of purchases of the requested product by the equivalent users. The in-store sales support system for requested products is characterized by the above.

5. 5. The system of claim 4, The reception information further includes attributes of the requested product, The history information of the purchased products by the user includes attributes of the purchased products and the number of purchased products; A process of calculating a predicted total number of purchases of the requested product by the equivalent user, and a process of identifying historical information of an equivalent product having the same or similar attributes as the requested product from the historical information of the purchased product based on the attributes of the requested product and the attributes of the purchased product included in the historical information of the purchased product by the equivalent user, The predicted total number of purchases of the requested product by the equivalent user is calculated based on the number of purchases of the equivalent product included in the history information of the equivalent product having the same or similar attributes as the requested product. The in-store sales support system for requested products is characterized by the above.

Images