Sales support system

Abstract

To provide a sales support system that can sufficiently increase the number of commodities and services that are dealt with on the Internet to increase the sales, and can easily achieve addition, innovation, and diversification of a sales format and process control.SOLUTION: A sales support system comprises: code creation means that creates a source code for starting predetermined processing for commodity data stored in a center server; embedding means that embeds the source code created by the code creation means in a predetermined portion of the commodity data stored in the center server; commodity data providing means that causes the center server to provide, to a shop, the commodity data in which the source code is embedded by the embedding means; and web page creation means that allows a shop server to create a web page based on the commodity data provided by the commodity data providing means. The start of the predetermined processing is requested by a user on the web page created by the web page creation means, and thereby the predetermined processing is performed.SELECTED DRAWING: Figure 28

Description

Technical Field

[0001] The present invention relates to a sales support system, and particularly to a sales support system that can enrich the number of products and services handled on the Internet, increase sales, and easily add, renovate, diversify sales forms, and manage processes.

Background Art

[0002] Conventionally, in order to facilitate users and avoid missing orders, shops have had to prevent stockouts as much as possible. For this reason, they have taken measures such as always maintaining a certain amount of inventory and predicting demand to conduct efficient inventory management.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, ensuring inventory always incurs costs and inventory management is also complicated. In addition, in order for sales businesses handling products and services to fully facilitate users' search for products and services and increase sales, as one measure, it is desirable to increase the number of products and services handled and enrich the products and services available for sale. By doing so, it is considered that the frequency of purchases, reservations, deliveries, takeouts, catalog requests, etc. of products and services will increase, and it will also be easier to secure repeat customers. However, each sales business has a limit to the number of products and services it handles, and enriching the number of products and services incurs costs, and there is a risk that the burden of inventory management and warehouse costs will increase rapidly. Furthermore, if existing stores could be transformed into malls or reciprocal sales platforms that allow other retailers to participate, the number of products and services offered could be increased without the burden of inventory management. However, this would require significant modifications to the sales systems of existing stores to enable mallization and reciprocal sales. In addition, there are many technical challenges that need to be addressed when listing products and services on the website, such as grouping similar products and services together and standardizing genre structure and list formats. Furthermore, some retailers may want to diversify their business beyond their current model by expanding or innovating their online sales methods, such as offering online product purchases, reservations, delivery, takeout, coupon applications, catalog requests, live commerce, and price comparisons, or by expanding sales to foreigners. They may also want to manage processes related to the production and delivery of goods and services. In these cases, there was a risk of burden on each retailer in terms of system development and modification. In some cases, the human burden of performing these sales tasks was not adequately avoided. Furthermore, it is desirable to be able to determine how to efficiently implement the aforementioned mall-style sales, cross-selling, and diversification strategies. It is also desirable to be able to predict and propose the extent to which these mall-style sales strategies will be effective and lead to increased sales for shops. Additionally, it is desirable to be able to make efficient decisions and suggestions regarding the procurement of newly added products.

[0005] This invention has been made in view of the above-mentioned conventional problems, and aims to provide a sales support system that can increase sales by enriching the number of goods and services handled online, and that can easily add, refresh, diversify sales formats and manage processes. [Means for solving the problem]

[0006] Therefore, the present invention (Claim 1) is characterized in that: a shop server where shop product data is stored and a web page for the product data is generated; product data collection means for collecting the shop's product data by at least one of the methods of providing and collecting; a central server for storing the product data collected by the product data collection means; code generation means for generating source code for starting a predetermined process with respect to the product data stored on the central server; embedding means for embedding the source code generated by the code generation means into a predetermined location of the product data stored on the central server; product data provision means for providing the shop with the product data in which the embedding means has been embedded from the central server; web page creation means for the shop server to create a web page based on the product data provided by the product data provision means; and in the web page created by the web page creation means, the predetermined process is performed when a user requests the start of the predetermined process.

[0007] The central server generates source code to initiate a predetermined process using the product data collected by the product data collection method. This generated source code is then embedded in the designated locations within the product data stored on the central server. The shop server then creates a web page based on this product data provided by the central server. This allows shops to easily perform specific processes on web pages, or to incorporate specific processes without modification.

[0008] Furthermore, the present invention (Claim 2) is characterized in that a shop server stores product data of a shop and generates a web page for the product data; product data collection means collects the shop's product data by at least one of providing and collecting; a central server stores the product data collected by the product data collection means; replacement means, etc., by the shop server replacing the source code in a predetermined location on the web page for the product data, or embedding it in a predetermined location on the web page for the product data; web page creation means, by the shop server creating the web page on which the source code has been replaced, etc., by the replacement means; and in the web page created by the web page creation means, the predetermined processing is performed when a user requests the start of the predetermined processing.

[0009] The shop server replaces the source code in a designated location on the product data web page with the source code necessary to initiate the specified processing of the product data, or embeds it in a designated location on the product data web page. The shop server then creates the web page with the source code replaced or modified. This allows shops to easily incorporate specific processes into their web pages.

[0010] Furthermore, the present invention (Claim 3) is characterized in that a shop server stores a web page on which the shop's product data is posted and makes the web page available for users to view via the Internet; a product data collection means for collecting the shop's product data by at least one of the methods of providing and collecting; a central server for storing the product data collected by the product data collection means; source code embedded in the web page for generating a link to start a predetermined process; a web page creation means for the central server to create a web page which is the destination of the link and which contains at least one of the product data; and the predetermined process is performed on the web page created by the web page creation means when a user requests the start of the predetermined process.

[0011] This allows for easy implementation of specific processes even if buttons, anchor text, or other elements necessary for performing those processes are not present on the web page. Updating product data is also simple.

[0012] Furthermore, the present invention (Claim 4) is characterized in that the shop is composed of at least one provider shop which is the source of product data and a recipient shop which is the recipient of said product data, and the web page is created by the web page creation means based on the product data provided by the provider shop and the product data of the recipient shop.

[0013] The partner shop can handle product data provided by the source shop via a central server. This increases the number of products available at the partner shop, making it easy for them to implement mall-like structures, reciprocal sales, and collaborative sales. Furthermore, web pages can be created based on product data from both the partner and source shops. Therefore, programs can be easily incorporated to perform specific processing not only on the partner shop's product data but also on the product data provided by the source shop.

[0014] Furthermore, the present invention (claim 5) is characterized in that the central server performs a process of embedding at least one of the following into a predetermined location in the product data of the shop or into a screen generated via the source code: the shop name of the shop, a comment, a search input field, a search button, a breadcrumb trail, a link button, a list of retailers, a language selection box, and a translation of a predetermined language.

[0015] The central server embeds the shop's name, comments, search input field, search button, breadcrumb trail, link button, retailer list, language selection box, and translations in a specified language into designated locations within the shop's product data, or into screens generated via source code. This allows shops to add information about their shops and products without any modification burden on them. Furthermore, if a shop handles products from other shops, users can use this information to recognize those other shops' products and confirm those other shops as the delivery source. If a list of retailers is embedded in a designated location within the shop's product data, the shop can easily incorporate a program to perform the required processing for the shops listed in this retailer list without requiring any modifications. Furthermore, the shop can easily incorporate the program to perform the required processing without any modifications.

[0016] Furthermore, the present invention (claim 6) comprises: a management screen provided on the central server; specification data setting means for pre-setting specification data necessary for each shop to make inquiries to users on the management screen; inquiry generation means for generating a page including an inquiry to the user based on the specification data set by the specification data setting means; inquiry display means for displaying the page generated by the inquiry generation means to the user in a program that performs predetermined processing; and response result storage means for storing the user's response result to the inquiry on the page displayed by the inquiry display means on the central server.

[0017] Each shop pre-configures the necessary specification data for making inquiries to users during the sales, reservation, delivery, and information request processes via its management screen. This allows shops to maintain their own unique specifications without having to conform to the specifications of other shops or the central server. When a provider shop participates in a mall, mutual sales, or partnership sales with partner shops, it is expected that each shop will have its own unique specifications for sales, reservations, delivery, and information requests. Even in such cases, each shop can participate while maintaining its own unique specifications.

[0018] Furthermore, the present invention (claim 7) comprises a management screen provided on the central server, specification data setting means for pre-setting specification data necessary for each shop to manage the process of the product data on the management screen, process management generation means for generating a page that manages the process for the shop, including at least one of the product production order, product production time, product production completion, and product delivery, based on the specification data set by the specification data setting means, and display means for displaying the page generated by the process management generation means to the shop.

[0019] This allows shops to easily perform required processes and manage product development processes. Saving the response results to pages displayed by the display device allows for adjustments and analysis, and also helps in sales management by providing information on product order status.

[0020] Furthermore, the present invention (claim 8) is characterized in that, by a program that performs the predetermined processing, the original text posted on the web page is separated into a plurality of blocks, and for each block, the original text and the translated text for the original text are displayed side by side to the user.

[0021] By displaying the original text and the translated text side-by-side for each block, users can easily read and make accurate judgments about the information. Furthermore, the present invention includes a database for storing the products held by a plurality of stores, summarizing means for summarizing the products of the stores stored in the database for each type of product, web page generation means for generating the products of the stores summarized by the summarizing means as a store list on a web page, and a link for foreign customers disposed in the web page or the store list, and foreign customer purchase processing operates based on a click by a user of the link.

[0022] Furthermore, the present invention (claim 9) is configured to include basic attributes in which the purchase degree by attribute is summarized for each product based on the purchase information of a plurality of purchasers including at least one attribute such as age, gender, hobbies, business type, and usage, a plurality of products purchased by a user at a store, purchase attributes summarized by attribute based on the purchase information of the plurality of products at the store or the basic attributes, and determination means for determining the magnitude of the purchase demand by the user based on the purchase attributes.

[0023] Summarize the purchase attributes by attribute based on the purchase information at the store and the basic attributes. Then, determine the magnitude of the purchase demand by the user based on this purchase attribute. As a result, the purchase demand at this store can be evaluated by attribute. Therefore, in the case of an attribute with a large purchase demand at this store, the magnitude of this purchase demand can be utilized to further enhance sales, or in the case of an attribute with a small purchase demand, the purchase demand can be reinforced, leading to an increase in the store's sales.

[0024] Furthermore, the present invention (claim 10) is characterized in that, for an attribute determined by the determination means to have a large purchase demand, it is determined to add or purchase product data having the same attribute based on the basic attributes, or to display product data of other stores on the store's website for sale.

[0025] For attributes that are judged to have high purchase demand in the shop, product data with the same attributes can be added based on the basic attributes, and decisions can be made regarding the actual procurement of those products. In addition, product data from other stores can be posted on the shop's website for sales purposes. This allows the shop to enrich its product lineup and lead to increased sales.

[0026] Furthermore, the present invention (claim 11) is characterized in that, when the determination means determines that the purchase demand is small, the shop's product data is posted on another store's e-commerce site for sale.

[0027] For attributes where the shop's purchase demand is deemed low, the shop's product data will be listed on other online shopping sites for sale. This will allow the shop to earn sales profits and increase its overall sales.

[0028] Furthermore, the present invention (claim 12) comprises basic attributes that summarize the degree of purchase by attribute for each product based on purchase information of multiple purchasers including at least one of the following attributes: age, gender, hobbies and preferences, industry, and use; product data collection means for collecting data on multiple products handled by a shop; sales attributes that summarize the data on multiple products based on the basic attributes; multiple products purchased by users at the shop; purchase attributes that summarize the data on multiple products based on purchase information at the shop or the basic attributes; and comparison means for comparing the sales attributes and the purchase attributes with respect to the attributes.

[0029] Sales attributes are compiled for multiple product data based on basic attributes. Conversely, purchase attributes are compiled based on shop purchase information and basic attributes. Then, these sales attributes and purchase attributes are compared. By compiling purchase and sales attributes for each shop in this way and evaluating them through comparison, it is possible to visualize and clarify the shop's purchase demand and strengths and weaknesses in terms of sales. It becomes easy to determine whether the product lineup matches the purchase demand for the products. As a result, shops can leverage their strengths in purchase demand to further strengthen sales and improve their product lineup, or, if there is a mismatch between purchase demand and the product lineup, they can reinforce areas where purchase demand is weak, leading to increased sales. [Effects of the Invention]

[0030] As described above, according to the present invention, the central server generates source code to initiate predetermined processing on product data collected by the product data collection means, and by embedding this generated source code into predetermined locations in the product data stored on the central server, shops can easily, or without modification, incorporate a program to perform predetermined processing on web pages. [Brief explanation of the drawing]

[0031] [Figure 1] System Configuration Diagram of This Sales Support System [Figure 2] Example of a list of retailers [Figure 3] Configuration diagram of the central server [Figure 4] Diagram showing the relationship between data in the provider-recipient correspondence table. [Figure 5] Server configuration diagram of the supplier shop [Figure 6] Server configuration diagram of the service provider shop [Figure 7] A flowchart illustrating how product data from each supplier shop is collected, updated, and how data sets are generated. [Figure 8]A flowchart showing how to collect and update product data from partner shops. [Figure 9] A flowchart showing the process for preparing a list of dealers. [Figure 10] Examples of elements that represent features [Figure 11] A flowchart showing how to create a list of retailers from the remaining products of the supplier shop. [Figure 12] A flowchart illustrating the search process and the processing method for the list page on the web page of the providing shop. [Figure 13] Conceptual diagram of the search results list [Figure 14A] Flowchart showing how to create a product details page (Part 1) [Figure 14B] Flowchart showing how to create a product details page (Part 2) [Figure 14C] Flowchart showing how to create a product details page (Part 3) [Figure 15] Product details page schematic (Part 1) [Figure 16] Product details page schematic (part 2) [Figure 17] Product details page schematic (part 3) [Figure 18] Product details page schematic (part 4) [Figure 19A] A flowchart (Part 1) showing an alternative method for creating product detail pages. [Figure 19B] A flowchart (part 2) showing an alternative method for creating product detail pages. [Figure 19C] A flowchart (part 3) showing an alternative method for creating product detail pages. [Figure 20] A diagram showing the relationship between the receiving shop and the providing shop. [Figure 21] Conceptual diagram showing sales history data of the partner shop. [Figure 22] Conceptual diagram showing sales history data from the providing shop. [Figure 23] Conceptual diagram showing sales history data when the providing shop is also the receiving shop. [Figure 24] Flowchart showing how to request information via the internet (Part 1) [Figure 25] An example of embedding the source code for a "Request Information" button in the appropriate place within the product description on the product details page. [Figure 26] Flowchart showing how to request information via the internet (Part 2) [Figure 27] Examples of setting specifications in the administration screen [Figure 28] A flowchart (Part 1) illustrating the case where partner shops introduce delivery systems and other mechanisms through reciprocal sales, partnership sales, and mall integration. [Figure 29] Example screen showing a delivery button placed in the product description. [Figure 30] Example screen with a delivery button. [Figure 31] Flowchart (Part 2) illustrating the implementation of delivery and other systems. [Figure 32] Example of an inquiry screen [Figure 33] Examples of website applications for delivery and similar systems. [Figure 34] Example of a database classified by business type code [Figure 35] Examples of management data for each business operator [Figure 36] Example of an order screen on an information terminal [Figure 37] Process diagram screen (part 1) [Figure 38] Process diagram screen (part 2) [Figure 39] Process diagram screen (part 3) [Figure 40] Process diagram screen (part 4) [Figure 41] Process diagram screen (part 5) [Figure 42] Examples of web pages for foreigners that include parallel text of the original and translated versions. [Figure 43] An example of making shop product data searchable by foreigners. [Figure 44] An example of making it possible for foreigners to search directly from a shop's existing web page. [Figure 45] Example of a bilingual list with symbols [Figure 46] Japanese examples separated by segment and term, and displayed freely on the homepage. [Figure 47] An example where the "Overseas User Purchase" button is displayed in the retailer list. [Figure 48] A diagram explaining the method for analyzing basic attributes. [Figure 49] Diagram explaining the method for analyzing sales attributes [Figure 50] Diagram explaining the method for analyzing purchase attributes [Figure 51] Comparison of purchase attributes and sales attributes [Figure 52] Examples of the effects of implementing a mall system [Figure 53] An example of how a shop's unique features have been further enhanced through partnerships. [Figure 54] Setting attributes in the management tool [Modes for carrying out the invention]

[0032] The following describes a first embodiment of the present invention. Figure 1 shows a system configuration diagram of this sales support system. In Figure 1, the Internet 10 is connected to information terminals such as personal computers 3 and smartphones 5 used by users. The Internet 10 is also connected to the server 4 of provider shops 2, which operate e-commerce sites for shopping malls, shops, manufacturers, etc., that provide product data. Here, product data may include service data, and e-commerce sites may include service provider websites (the same applies hereafter). Service providers include, for example, restaurants, cafeterias, dry cleaners, flower shops, confectionery shops, cram schools, hotels, and other service industries. In the figure, provider shops 2-1, 2-2, and 2-3 indicate that there are multiple provider shops 2. These provider shops 2 operate their own websites, but they are not necessarily required to have a website.

[0033] Product data provided by supplier shop 2's server 4 is received by the central server 6 via the internet 10. The central server 6 also crawls supplier shop 2's website and collects product data from the homepage based on predetermined definitions. The central server 6 then performs a predetermined analysis on the product data. Subsequently, the central server 6 provides the product data to the server 7 of the recipient shop 1 via API (Application Programming Interface) or CSV file, either in the form of a list of retailers for each product (described later) or as individual products without a list of retailers. Here, the list of retailers is, for example, a list of shops that handle and sell the same product a, as shown in Figure 2. Here, product a may include service data, and shops may include stores operated by businesses that handle services (the same applies hereafter). Provider Shop 1 operates e-commerce sites such as shopping malls and individual shops, and has its own website 9. However, it is also possible to build a new e-commerce site without having website 9. Provider Shop 1's server 7 can download product data, including a list of retailers, via the central server 6's API or CSV files. However, it is also acceptable to download only product data, such as individual product data, without the retailer list. This allows Provider Shop 1 to create an e-commerce mall with participation from multiple provider shops 2, engage in reciprocal sales where shops sell each other's products, or implement collaborative sales where only one of the partnered shops sells products.

[0034] Figure 3 shows the configuration diagram of the central server 6. This central server 6 includes a calculation unit 11 that performs calculations, a display and operation unit 13, and a communication unit 15 that communicates data via the Internet 10 with the outside world. In addition, the product data collection and analysis unit 20 has a patrol program 21 and a product data analysis program 23 built into it. The patrol program 21 periodically patrols the web pages of the providing shop 2 and the receiving shop 1 to collect product data such as product name, manufacturer name, model number, price, shipping cost, specifications, product description, product image, URL of the product details page, genre name, and JAN code from the HTML source code of the web pages according to predetermined definitions.

[0035] Furthermore, in the product data collection and analysis unit 20, this product data can be provided via CSV file or registered manually, in addition to being collected through a mobile system. The mobile system is adopted to make it convenient for the providing shop 2 by reducing the amount of manual work required. However, it is also possible to provide the data via CSV file or register it manually without performing a mobile system. Alternatively, it is also possible to perform a mobile system while also allowing provision of CSV file data or manual registration. It is also possible to register the data only when it is updated.

[0036] The product data analysis program 23 uses the large amount of product data collected by the patrol program 21 to group shops that handle the same product into a single retailer list using a predetermined logic described later, and also extracts products for which a retailer list has not been generated (hereinafter referred to as individual products). It also performs processes such as generating HTML source code and embedding it in the product description text. User Support and Management Program 25 includes programs that automate user interactions and management of users and shops. Examples of these programs include reservation programs, order programs, delivery programs, catalog request programs, coupon application programs, cash back programs, takeout programs, price negotiation programs, and programs for foreign buyers.

[0037] Furthermore, the database 30 of the center server 6 includes a retailer list database 31 that stores multiple retailer lists, a retailer shop database 33 that stores the shop name, site URL, product sales conditions, etc. of retailer shop 2, a retailer shop database 35 that stores the shop name, site URL, product sales conditions, etc. of retailer shop 1, a retailer-recipient correspondence database 37 that stores which retailer shop 2 is affiliated with for each retailer shop 1, as shown in Figure 4, a retailer shop product database 39 that stores product data currently sold by retailer shop 2, a retailer shop product database 41 that stores product data currently sold by retailer shop 1, a sales history management database 43 that backs up sales history management data for retailer shop 2 or retailer shop 1 if requested, an individual product database 45 that stores individual products within retailer shop 2 for which a retailer list has not been generated, and a user correspondence / management database 47 that stores user information and management information used by the user correspondence / management program 25.

[0038] On the other hand, as shown in Figure 5, the server 4 of the provider shop 2 includes a communication unit 55 for communication over the Internet 10, including the central server 6, a management unit 57 necessary for operating the mail-order system that the provider shop 2 had been using even before the application of this embodiment, and a customer database 59.

[0039] Furthermore, this embodiment includes a database 60. However, the database 60 may be built as a server independent of the server originally owned by the provider shop 2. This database 60 includes a supplier shop sales history management database 61 that manages the sales history of products handled by supplier shop 2 at supplier shop 2, a supplier shop sales history management database 63 that manages the sales history of products handled by supplier shop 2 at supplier shop 1, and a supplier shop product database 65 that stores products handled by supplier shop 2. However, some or all of this database 60 may be stored on the central server 6.

[0040] Furthermore, as shown in Figure 6, the server 7 of the customer shop 1 includes a communication unit 75 for communication over the Internet 10, including the central server 6, a management unit 77 necessary for operating the mail-order system that the customer shop 1 had been using even before the application of this embodiment, and a customer database 81. In this embodiment, it also includes a web page creation unit 79 and a database 80. However, the web page creation unit 79 and the database 80 may be built as servers independent of the server originally owned by the customer shop 1. The web page creation unit 79 also includes, although not shown in the diagram, a product detail page creation unit for creating product detail pages, a list page creation unit for creating list pages, and a search results list creation unit for creating search results lists. This database 80 includes a provider shop sales history management database 83 that manages the sales history of products handled by provider shop 2 at recipient shop 1, a recipient shop sales history management database 85 that manages the sales history of products handled by recipient shop 1 at recipient shop 1, a recipient shop product database 87 that stores products handled by recipient shop 1, and an individual product database 89 that stores each downloaded product. However, some or all of this database 80 may be stored on the central server 6.

[0041] Next, we will explain, based on the flowchart in Figure 7, how to collect product data from each supplier shop 2, update this product data, and generate a data set. In Step 1 of Figure 7 (abbreviated as S1 in the figure; the same applies hereafter), the patrol program 21 visits the web pages on each provider shop 2's site and collects product data posted on these web pages. In Step 2, the patrol program 21 updates the previously acquired product data, including product name, price, description, shipping cost, points awarded for purchasing the product, genre name, manufacturer name, specifications, etc., with the latest collected data. However, for products that are registered, updated, or deleted by users on a specific site, such as used goods, it is not always necessary to collect and update data through this patrol process.

[0042] In step 3, the central server 6 stores the product data from each supplier shop 2, which was updated in step 2, as a supplier product data set in the supplier shop product database 39. However, the data may also be stored separately for each supplier shop 2 instead of being stored as a supplier product data set. Step 4 repeats this process periodically at a fixed frequency. This allows product data to be acquired and updated without burdening each provider shop 2. However, this process may also be performed by providing CSV data, or by manual registration, updating, and deletion. A combination of these methods is also acceptable. Furthermore, when each provider shop 2 updates product data, it may be possible to instruct the system to perform at least one check or to acquire data only for the updated product data.

[0043] Next, we will explain how to collect product data from supplier shop 1 and update this product data, based on the flowchart in Figure 8. In step 5 of Figure 8, the patrol program 21 visits the web pages on the site of the supplier shop 1 and collects product data posted on these web pages. In step 6, the patrol program 21 updates the product name, price, description, shipping cost, points, genre name, manufacturer name, specifications, etc. of the previously acquired product data with the latest collected data, in the same way as in step 2.

[0044] In step 7, the central server 6 determines whether product data for the same product has been deleted, and whether product data that was previously deleted has been restored. Product data is deleted in cases such as when a product is discontinued or out of stock. Even if a product has been deleted, if it is subsequently restocked, the product details page may be restored, and the content of the description may be changed accordingly. Then, in step 8, the central server 6 saves a record of the deletion of product data in the customer shop's product database 41, and a record of the restoration of product data in the restoration of product data. The purpose of saving this record of deletion and restoration is to prevent duplicate listings of products.

[0045] In step 9, it is desirable to temporarily remove discontinued or out-of-stock items from the database, anticipating that they may be reintroduced in the future. Then, in step 10, this process is repeated periodically at a fixed frequency. This allows product data to be acquired and updated without burdening the recipient shop 1. However, this process may also be performed by providing CSV data, or by manual registration, updating, and deletion. A combination of these methods is also acceptable. Furthermore, when recipient shop 1 updates product data, it may be necessary to instruct the system to perform at least one check or to acquire data only for the updated products. Additionally, the product data of this recipient shop 1 may be added to the source product data set.

[0046] Next, we will explain the process for preparing the list of dealers based on the flowchart in Figure 9. In Figure 9, the product data analysis program 23 starts processing in step 15, and in step 17, the product data analysis program 23 reads the supplier product data set. Then, in step 19, the product data analysis program 23 reads the i-th product from the product data stored in the supplier shop product database 41 for supplier shop 1, which is stored in the supplier shop database 35. In step 21, the product data analysis program 23 finds the product from supplier shop 2 that corresponds to this i-th product in the supplier product data set.

[0047] The analysis in this case involves, for example, the product data analysis program 23 extracting elements that represent characteristics used to group identical products from the large amount of product data collected by the patrol program 21. This is because each supplier shop 2 often sells the same product, and these characteristic elements are used to group identical products into a single set.

[0048] Here, an element is defined as follows: for product names, each word separated by a space; for manufacturer names, the word with the company name (e.g., "Co., Ltd.") removed; for model numbers, the text itself representing the model number is an element; for specifications, the specification data corresponding to each specification item is an element; for product descriptions, the nouns in the description are elements; and the JAN code is also an element. An example of an element representing a feature is shown in Figure 10.

[0049] Each product has a corresponding feature element, and each feature element consists of at least one element. These feature elements can be set manually, or some elements can be set manually, while the remaining elements are obtained through automated analysis of product data, resulting in a combined set. In the automated approach, it is desirable to use common elements for each product, such as the product name, model number, specifications, unit indicating quantity (capacity), and manufacturer name. Alternatively, AI (artificial intelligence) can be used to automatically set these elements by analyzing product data. Note that feature elements can consist only of the model number or only the JAN code.

[0050] Alternatively, product images can be included as feature elements. In this case, for example, the product image can be separated into multiple pixel data points both vertically and horizontally. This pixel data can then be used for comparison. The product data analysis program 23 applies elements representing the characteristics of each product, which are generated for each product, to the product data collected from each supplier shop 2. From this product data, products possessing these elements are extracted as identical products. The product data from each supplier shop 2 that are extracted as identical products are compiled into a list of retailers, including at least one shop that sells each product, and stored in the retailer list database 31. In the case of product data where it is difficult to set elements representing characteristics, identical or related product data may be manually grouped together. In this way, product data that is manually set and product data that is automatically set may be mixed.

[0051] Furthermore, by sorting the prices of the shops listed in this retailer list from lowest to highest, you can compare prices for each individual product. The shops listed in this retailer list can include shops that handle used goods or individual sellers. In step 23, the central server 6 determines whether a store list already exists in the store list database 31 for this i-th product. If a store list exists, the process proceeds to step 25, where the central server 6 associates the i-th product (the product from the receiving shop 1) with the product from the providing shop 2 found in step 21, using the existing store list.

[0052] On the other hand, if no retailer list exists in step 23, the process proceeds to step 27, where the central server 6 saves the product data found in step 21 as a new retailer list in the retailer list database 31. In step 29, the central server 6 removes the associated products from the product data of the providing shop 2. This is to retain the individual products. However, if it is acceptable for the associated products and individual products to be listed redundantly in the search results list or list page of the receiving shop 1, the process in step 29 may be omitted. In step 31, the central server 6 determines whether there is any remaining product data in the receiving shop 1, and as long as there is, the central server 6 repeats the process from step 19.

[0053] Then, in step 35, the central server 6 saves the products that were not associated with the retailer list as individual products in the individual product database 45. Through the above process, both the retailer list and individual products are generated. The data for the products belonging to the retailer list and the individual products generated here are constantly updated by the processes described in Figures 7 and 8 above.

[0054] Next, we will explain how to create a list of retailers from the remaining products of supplier shop 2, based on the flowchart in Figure 11. In Figure 11, in step 41, the central server 6 reads the remaining product data of the provider shop 2. In step 43, if a product belonging to the recipient shop 1 is deleted and then re-established on the recipient shop 1 side, and it is possible to list it as a product on the provider shop 2 side, the central server 6 deletes the product data with the retailer list and the individual product. This is to prevent duplicate registration of the retailer list. However, if it is acceptable for product data with the retailer list and individual products to be listed multiple times in the search results list and list page of the recipient shop 1, the process in step 43 may be omitted. In step 45, the central server 6 reads the i-th product from the product data of provider shop 2 stored in the provider shop product database 39. In step 47, the central server 6 finds the product of provider shop 2 corresponding to this i-th product from the remaining product data of provider shop 2. The process here is the same as the product analysis method in step 21.

[0055] Next, in step 49, the central server 6 determines whether a retailer list already exists for this i-th product. If a retailer list exists, the process proceeds to step 51, where the central server 6 adds the product from supplier shop 2, found in step 47, to the existing retailer list. On the other hand, if step 49 determines that no retailer list exists, the process proceeds to step 53, where the central server 6 saves the product data found in step 47 as a new retailer list in the retailer list database 31.

[0056] In step 55, the central server 6 removes the associated products from the product data of the supplier shop 2. This is to retain the individual products. However, if it is acceptable for the associated products and individual products to be listed redundantly in the search results list or list page of the recipient shop 1, the process in step 55 may be omitted. In step 57, the central server 6 determines whether there is any remaining product data from the supplier shop 2, and repeats the process from step 45 as long as there is remaining data. Then, in step 59, the central server 6 saves the products that were not associated as part of the retailer list as individual products in the individual product database 45. In this case, similar to step 101 described later, the supplier shop ID of supplier shop 2 corresponding to the supplier shop ID of supplier shop 1 is read from the supplier-supplier correspondence table 37. Then, for each supplier shop 1, the product data corresponding to the supplier shop 2 to which it belongs is extracted and saved. In other words, an individual product database 45 can be created for each supplier shop 1. Through the above process, a list of retailers and individual products are generated from the remaining product data of supplier shop 2 after the process shown in Figure 9. Note that the data for the products belonging to the retailer list and the individual products generated here are constantly updated through the processes described in Figures 7 and 8. When creating the retailer list, it is also possible to generate a single set by combining the source product data set and the product data of destination shop 1, and then associate this set with individual products in the same way as in step 19 or step 45 above to generate the retailer list and individual products.

[0057] Next, we will explain the search process and the processing method for the list page on the web page of provider shop 1, based on the flowchart in Figure 12. In Figure 12, in step 71, a user visiting the website 9 of provider shop 1 performs a search. In this case, the server 7 of provider shop 1 searches the customer database 81 of provider shop 1 in step 73 using the search keywords entered by the user in the search input field of the web page. In this search, search items such as genre names and specifications may be added to the search keywords. Here, server 7 temporarily stores the search results data and the number of searches. This customer database 81 is a database of products that provider shop 1 originally owned. Prior to applying this embodiment, the search results list was provided to the user based solely on searches of this customer database 81. Note that customer database 81 may not be included in server 7, but may exist on a separate server in the form that provider shop 1 originally owned. This is to avoid modifying the existing server owned by provider shop 1 as much as possible and to use it as is.

[0058] Meanwhile, in step 75, server 7 passes this search keyword to central server 6. In this search, genre names and specification search items may be added to the search keyword. In step 77, central server 6 searches the dealer list database 31 and individual product database 45 for this search keyword that it has received. Then, in step 79, central server 6 extracts the dealer list of products that match this search keyword, as well as individual products that are not associated with the dealer list. However, if the individual product database 45 is a compilation of all supplier shops 1, then, as described above, the supplier shop ID of supplier shop 2 corresponding to the supplier shop ID of supplier shop 1 is read from the supplier-supplier correspondence table 37. Then, for individual products, the product data corresponding to supplier shop 2 belonging to this supplier shop 1 is extracted. In step 81, the central server 6 provides this product data and search results via API. Ideally, the product data should be provided in quantities such as 20 items per page of the search results list, to reduce transmission time and server load. Used items may also be included in this product data.

[0059] In step 83, the server 7 of the client shop 1 accesses the API to receive product data. In step 85, the server 7 saves the received product data to the client shop's product database 87 and the individual product database 89. In step 87, the server 7 creates a web page based on this product data in the web page creation unit 79. However, it is desirable that the product data be combined with the product data found in step 73. It is also desirable that the search results be the sum of the search results from step 73 and the product data received via the API. The order in which the product data search results are displayed can be freely determined by the client shop 1. For example, the client shop 1's product data may be displayed first, followed by the product data received via the API, or the product data may be mixed together according to predetermined conditions as appropriate. In step 89, the created web page is provided to the user as a search results list. A conceptual diagram of the search results list at this time is shown in Figure 13.

[0060] In Figure 13, for example, the conventional search results yield 1,000 items, and the products listed (1 to 5) are the result of searching only the customer database (81). In contrast, in this embodiment, for example, the search results include product data received via API, bringing the total to 2,000 items. The breakdown of the added product data is as follows: Product 10 in the figure is product data that is not handled by the receiving shop 1, but has a retailer list on the newly generated product details page. Also, Product 11 is not handled by the receiving shop 1, but its product details page was created based on individual product data provided by the providing shop 2. In this way, the number of search results can be significantly increased. Therefore, users who want to find all the products they need can perform efficient searches. Furthermore, a retailer list has been added to the product details pages of many of the existing products (1 to 5). However, although not shown in the diagram, the product data obtained from the search in step 73 and the product data received via the API may not be combined. The product data received via the API may be displayed in a separate section or as related products on the product details page. Alternatively, only products with added retailer lists may be combined, while individual products may be displayed in a separate section. Alternatively, the central server 6 may perform a search using keywords on the data stored in the customer shop product database 41, the individual product database 45, and the retailer list database 31, and then send the search results to customer shop 1 via API. In this case, the burden of searching on customer shop 1 is eliminated. The flowchart in Figure 12 illustrates the creation of a search results page, but the process is similar for creating a list page, so a detailed explanation will be omitted. However, when creating a list page, product data is searched using keywords such as genre name or genre code. Also, when creating a list page, the number of products that can be displayed may be limited to a certain number and selected manually, for reasons such as prioritizing the visibility of products from supplier shop 1.

[0061] If the size of the receiving shop 1 is small, all product data from the search results can be provided via API or CSV file. However, if the shop is large, receiving all product data and saving it to the receiving shop's product database 87 would place a heavy communication burden on the shop, and in the case of list pages, there is a risk that the product data will become outdated. Therefore, it is desirable to send the product data from the search results and list pages from the receiving shop 1 each time a transmission request is received, for example, one page at a time (20 items per page). This transmission request can be, for example, one page at a time. By providing a limited number of products in this way, real-time performance can be ensured and the communication burden can be reduced. Therefore, as described above, client shop 1 can continue to use its existing server equipment. Equipment changes will be minimal. Even if client shop 1's database capacity is small, it can still handle a large amount of product data. Since the search targets remain the same—only the product data originally owned by client shop 1—the search load will not increase. Consequently, the search speed can be maintained even with existing server equipment. Furthermore, there is no need to consider data updates for the data handled by the central server 6's database.

[0062] Furthermore, the customer database 81 of the receiving shop 1 may include data stored in the individual product database 45 and data related to the receiving shop 1 from the store list database 31. That is, the central server 6 provides product data to the receiving shop 1 via a CSV file, API, etc. In this case, the central server 6 may combine all of the product data of the receiving shop 1, the data stored in the individual product database 45, and the data stored in the store list database 31 before providing it. However, it is possible to omit some or all of the product data from supplier shop 1, such as price, stock quantity, shipping fee, and points, from the CSV file in order to prioritize management by supplier shop 1. In particular, it is desirable to omit at least one of the items, price and stock quantity. Alternatively, even if the data is included in the CSV file, it is acceptable to ensure that the product data of supplier shop 1 is not updated with that data when it is imported.

[0063] Furthermore, as will be discussed later, the list of retailers may be provided embedded within the product description text, for example, in the form of HTML source code. Furthermore, the server 7 of the service provider shop 1 may search the customer database 81 of the service provider shop 1 in step 73 for the search keywords entered by the user in the search input field of the web page. In this case, the processing in steps 75 to 89 can be omitted. Therefore, no modifications are necessary. The list may also be created based on the product data provided via this CSV file or API, etc. Alternatively, instead of modifying and using the server equipment of provider shop 1, a new server facility may be set up for provider shop 1. In this case, provider shop 1's website may be set up within central server 6. This website can also use the custom domain set up by provider shop 1.

[0064] Next, we will explain how to create a product details page based on the flowchart in Figure 14. In Figure 14, in step 91, the user visits the website 9 of the provider shop 1. In step 93, the user selects and clicks on product a from the search results or list on the website 9 of the provider shop 1. At this point, product a may be a product of provider shop 1 or a product of provider shop 2, as described above. In step 95, the provider shop ID of provider shop 1 and the product ID corresponding to product a are extracted from the database 80 by the server 7 of provider shop 1 and sent to the central server 6.

[0065] In step 97, the central server 6 searches the store list table of the store list database 31 based on the received product ID. Then, in step 99, the central server 6 determines whether a store list for product a exists. If it is determined in step 99 that a store list for product a exists, the server proceeds to step 101. In step 101, the central server 6 reads the provider shop ID of provider shop 2 corresponding to the provider shop ID of provider shop 1 from the provider-provider correspondence table 37 shown in Figure 4. Then, in step 103, the central server 6 extracts the product data corresponding to provider shop 2 from the store list for product a. There may be multiple provider shops 2. Note that if provider shop 2 is a flea market, multiple provider shops 1 may be associated with one provider shop 2. However, instead of creating a provider-recipient correspondence table 37, an independent server (or database) may be set up for each provider shop 1. Then, for each server, product data corresponding to provider shop 2, which has been designated in advance, may be extracted from the list of retailers of product a. Alternatively, the extraction process of product data for this designated provider shop 2 may be performed on the server 7 on the provider shop 1 side, rather than on the central server 6. Or, instead of creating a provider-recipient correspondence table 37, a database for provider shop 2 may be combined for each provider shop 1. Then, product data corresponding to provider shop 2 may be extracted from this database, based on the list of retailers of product a.

[0066] Subsequently, in step 105, the central server 6 sorts the product data according to the default sorting order of the provider shop 1 that has been registered with the central server 6 in advance. This default sorting order is, for example, by price (lowest first), by product name of provider shop 2, by number of clicks, by rating of provider shop 2, etc., and is determined at the discretion of provider shop 1 or by predetermined judgment conditions of the central server 6. However, this sorting may also be performed on the server 7 side of provider shop 1. In step 107, the central server 6 provides this product data along with the existence code of the retailer list via API. On the other hand, if it is determined in step 99 that the retailer list for product a does not exist, the process proceeds to step 109. Then, in step 109, the central server 6 provides the retailer list non-existence code via API.

[0067] In step 111, the server 7 of the receiving shop 1 accesses the API via the communication unit 75. In step 113, the server 7 checks for the existence code of the retailer list. If the existence code of the retailer list exists in step 115, the process proceeds to step 117, where the server 7 receives product data from the central server 6 via the API. The received product data includes the shop ID, etc. The shop ID may be added to the product name by the central server 6, etc. At least one of the following may be added: shop ID, product code, and shop name. This shop ID, etc. may be added only for products from the providing shop 2. The product code also includes the service code (the same applies below). In step 119, server 7 determines whether product a belongs to shop 1.

[0068] However, the central server 6 can also determine whether or not product a belongs to supplier shop 1. If it does belong to supplier shop 1, the process proceeds to step 121, where server 7 adds the sorted list of retailers to the product data of supplier shop 1 for product a. Then, in step 125, the web page creation unit 79 of server 7 for supplier shop 1 imports this product data and creates a product details page.

[0069] A schematic diagram of the product details page at this time is shown in Figure 15. Specifically, in Figure 15, the product details page 100 displays the product image, price, product description, and purchase button 101 of product a originally owned by the supplier shop 1 in an easily viewable central part of the page, and at least one supplier shop 2 that sells this product is listed as a retailer list 103 for this product. This retailer list 103 includes the retailer name, selling price, and shipping cost for product a from supplier shop 2, but may also include the product name, product image, etc. Furthermore, retailer list 103 may be displayed as a separate page via a link. This link may lead to a different website. Additionally, when a user clicks on supplier shop 2 listed in retailer list 103, they may be able to view more detailed product data, including a detailed description of product a from supplier shop 2, as shown in Figure 18 below, on the product details page of supplier shop 1. Furthermore, a purchase button 101 may be placed on the product details page of supplier shop 2. Alternatively, clicking on supplier shop 2 listed in the retailer list 103 could link to the shopping cart, but this would require modification. By linking to the product details page of supplier shop 1 as described above, modification becomes unnecessary.

[0070] This product details page will be posted on the website of supplier shop 1, but it can also be hosted on a separate website. However, if adding the shop name to the product details page in the manner shown in Figure 18 would require modification of server 7, the central server 6 may automatically add the shop name and a comment containing the shop name (for example, "This product is shipped from shop A") in the appropriate place (for example, at the top) within the product name or product description to avoid modification. It is desirable that the text be emphasized, decorated, or enclosed in parentheses to make it stand out. At this time, at least one of the following may be added: shop ID, product code, and shop name. The shop ID, etc., may be added only for products from supplier shop 2.

[0071] The data for the retailer list 103, as well as the link URL to the product image of product a originally owned by the receiving shop 1, the price, and the product description text, will be prepared on the central server 6 in the form of an API or CSV file. The receiving shop 1's server 7 may read this data manually or automatically. In this case, the retailer list 103 data, written in the form of HTML source code, may be included in an appropriate place (for example, at the bottom) of the product description text. It is desirable that the processing of including this HTML source code in the product description text is performed by the calculation unit 11 on the central server 6. In this case, by reading the CSV file etc. on the server 7, the retailer list 103 can be displayed in the product description without any special modifications. However, if the receiving shop 1's web page creation program only supports text and not HTML source code when generating the product description, it is sufficient to simply modify the web page creation program to support HTML source code.

[0072] This allows users to easily get a sense of the market price and make a purchase, as multiple shops are listed on the product details page for product A that the user is looking for. The increased number of retailers also increases the likelihood that the user will purchase from at least one of the shops. Furthermore, the risk of losing sales opportunities due to lack of stock is reduced. Furthermore, services independently offered by this provider shop 1, such as point accrual and card payment, can also be applied to product purchases at this provider shop 2, thereby further enhancing services for users.

[0073] On the other hand, if step 119 determines that product a does not belong to supplier shop 1, the process proceeds to step 123, where server 7 extracts one of the shops belonging to the retailer list as a representative shop and adds it to the sorted retailer list. Then, in step 125, the web page creation unit 79 of server 7 at supplier shop 1 imports this product data and creates a product details page. A schematic diagram of the product details page at this time is shown in Figure 16.

[0074] Specifically, in Figure 16, the product details page 110 displays the product image, price, product description, and purchase button 101 for product a, which is not owned by supplier shop 1 but is owned by supplier shop 2, which has been selected as a representative shop. The shop name 113 of supplier shop 2, which sells this product, is also included. The method for selecting supplier shop 2 as the representative shop is arbitrary, but one shop may be selected by server 7 or central server 6 based on criteria such as price or sales performance.

[0075] Furthermore, at least one remaining supplier shop 2 that sells product a is listed as the retailer list 115 for this product. The name of the retailer shop 2 that sells product a, the selling price, and the shipping cost are listed here, but the product name, product image, etc. may also be included. The retailer list 115 may also be displayed as a separate page via a link. Furthermore, when a user clicks on a supplier shop 2 listed in this retailer list 115, more detailed product data, including a detailed description of product a from supplier shop 2 as shown in Figure 18 below, may be made available as a product details page on supplier shop 1. A purchase button 101 may also be placed on this product details page of supplier shop 2. In this case, although product a was not originally sold by supplier shop 1, it can now be sold using a product details page created based on the product data of supplier shop 2. Therefore, it becomes possible to sell products even without inventory, leading to increased sales opportunities. Furthermore, the created product details page can be included in search results lists and general lists, enriching the range of products available. Increasing the number of products searchable also improves the accuracy of product searches by users. For the participating shop 1, this serves as a stepping stone to developing a new genre and allows them to predict its effects before making a full-scale entry into the market.

[0076] Even if the product is out of stock at supplier shop 1, the user can purchase it from retailer list 115. Therefore, this prevents the loss of purchase opportunities due to stock shortages at supplier shop 1. For supplier shop 1, this reduces the need to constantly maintain inventory, thus alleviating the burden of inventory management. In step 127, product detail pages 100 and 110 for product a are displayed on the information terminal of the requesting user.

[0077] On the other hand, if no store list existence code is found in step 115, the process proceeds to step 129, where server 7 checks for a store list non-existence code. Then, in step 131, server 7 determines whether product a belongs to supplier shop 1. If it does, the process proceeds to step 133, where server 7 displays the product details page for product a from supplier shop 1 to the user.

[0078] A schematic diagram of the product details page at this time is shown in Figure 17. Specifically, in Figure 17, the product details page 120 displays the product image, price, product description, and purchase button 101 of product a, which is originally owned by the supplier shop 1, in an easily viewable central part of the page. In other words, the structure of this page is what the supplier shop 1 was originally using even before the application of this embodiment. If in step 131 this product a is not a product belonging to the supplier shop 1, the process proceeds to step 135, where server 7 receives individual product data from central server 6 via API. The individual product data is the product data stored in individual product database 45.

[0079] In step 137, create a product details page for the product from provider shop 2 that received this item. Figure 18 shows a schematic diagram of the product details page at this time. Specifically, in Figure 18, the product details page 130 displays the product image, price, product description, and purchase button 101 of product a, which is not owned by the supplier shop 1 but is owned by the supplier shop 2, in a clearly visible central part of the page. The shop name 133 of the supplier shop 2, which sells this product, is also included.

[0080] In this case, although product a was not originally sold by supplier shop 1, it can now be sold using a product details page created based on the individual product data of supplier shop 2. Therefore, it becomes possible to sell products even without inventory, leading to increased sales opportunities. This also makes it easier to secure repeat customers. Furthermore, it can be listed in search results lists and catalog lists, enriching the range of products available. Increasing the number of products searchable also improves the accuracy of product searches by users. For supplier shop 1, the need to constantly maintain inventory is reduced, and the burden of inventory management is lessened even if the number of products increases. The anxiety of running out of stock is also reduced. The central server 6 determines whether product a is listed in the retailer list and whether product a belongs to supplier shop 1. Server 7 may read the results of this determination via API and then create the product detail pages shown in Figures 15 to 18 based on those results. Alternatively, the central server 6 may create each product detail page and pass it via API. Furthermore, the functions of server 7 may be located on the central server 6. In this case, the website of supplier shop 1 is built on central server 6.

[0081] Next, we will explain another method for creating product detail pages based on the flowchart in Figure 19. Elements identical to those in Figure 14 are given the same reference numerals and their explanations are omitted. In the product detail page creation process described up to Figure 14, the product data analysis program 23 analyzes the supplier product data set stored in the supplier shop product database 39 to find identical products and generate a list of retailers. Subsequently, the product detail pages are created by narrowing down the list of retailers to supplier shops 2 corresponding to the destination shop 1.

[0082] In contrast, another method involves analyzing the product table of supplier shop 2 corresponding to supplier shop 1 to find identical products, and then creating a product details page using a retailer list obtained by logically adding the results. In Figure 19, in step 91, the user visits the website 9 of the provider shop 1, and in step 93, the user clicks on product a from the search results or list. In step 95, the provider shop ID and the product ID corresponding to product a are sent to the central server 6.

[0083] In step 101, the central server 6 reads the provider shop ID of provider shop 2 corresponding to the provider shop ID of provider shop 1 from the provider-provider correspondence table 37. Then, in step 141, the central server 6 reads the respective product tables of each provider shop 2. The product data belonging to this product table is stored in the provider shop product database 39 and is constantly updated by the patrol program 21, etc. However, it is also possible to read the product tables of all provider shops 2. Alternatively, as explained in Figure 14, it is also possible to set up an independent server (or database) for each provider shop 1 without providing the provider-provider correspondence table 37.

[0084] In step 143, the product data analysis program 23 narrows down the product data in the product table by at least one of the following: model number, JAN code, product name, or product image, which belong to the product ID. The analysis method at this time is the same as the processing in step 21. In step 145, the central server 6 creates a retailer list by sorting the extracted results. Then, it saves this created retailer list to the retailer list database 31. Note that in some cases, the result of narrowing down in step 143 may be zero, in which case a retailer list is not created.

[0085] In step 99, the central server 6 determines whether a list of retailers for product a exists. If it is determined in step 99 that a list of retailers for product a exists, the process proceeds to step 105. In step 105, the central server 6 sorts the product data according to the default sorting order of the destination shop 1 that is pre-registered with the central server 6. In step 107, the central server 6 provides this product data along with the retailer list existence code via API.

[0086] On the other hand, if it is determined in step 99 that there is no store list for product a, the process proceeds to step 109. In step 109, the central server 6 provides a store list non-existence code via API. In step 111, the server 7 of the receiving shop 1 accesses the API via the communication unit 75. From step 113 onward, perform the same process as in the flowchart in Figure 14 to create product detail pages for four different configurations. Furthermore, as described in the search process performed on the web page of the service provider shop 1, the central server 6 may periodically provide the service provider shop 1 with this data by consolidating all of the service provider shop 1's product data, the data stored in the individual product database 45, and the data stored in the retailer list database 31, saving this data as a CSV file, or by providing it via an API, etc.

[0087] in this case, (1) The product name must include at least one of the following: shop ID, product code, and shop name. This makes it easier to identify that the product is from supplier shop 2. (2) Include a comment containing the shop name in the appropriate place within the product name or product description. For example, if the product details page is for a product from supplier shop 2, a comment will be inserted; if it is not for a product from supplier shop 2, no comment will be inserted. (3) The product description shall include, for example, the data of the retailer list 103 in the form of HTML source code in appropriate places. For example, if the data of the retailer list 103 exists, this HTML source code shall be included in the product description; otherwise, this HTML source code shall not be included in the product description. It is desirable to provide product data that has undergone at least one of the processes (1) to (3) from the central server 6 to the receiving shop 1 via a CSV file or API.

[0088] However, the shop ID, comment text, HTML source code, etc. mentioned above may be added to the text data displayed on the product details page of the supplier's online store, in addition to being included in the product name and product details page. Furthermore, the comment text, retailer list 103, shop name, etc. may be displayed as image-based text data in the image field, etc. This ensures that products sold at supplier shop 1 can be reliably identified by the central server 6 and supplier shop 2. Furthermore, it is easier for users to understand that the product is from supplier shop 2 and that the shipping origin is supplier shop 2. Additionally, there is no need to create a separate space on the product details page to display the retailer list 103. The shopping cart already provided by supplier shop 1 can be used as is. The processes (1) to (3) allow for support of four different types of product details pages. Therefore, supplier shop 1 can implement this system without modification. However, some or all of the product data from supplier shop 1, such as price and inventory levels (which require real-time information), may be omitted from the CSV file or API to prioritize management on the supplier shop 1 side. Alternatively, these fields may be left blank. Conversely, the data included in the CSV file or API may be limited to the product details and product name, and only these may be updated.

[0089] Furthermore, for CSV files and APIs, the receiving shop 1 exports the data including all items and the data belonging to those items. In this case, the exported data can be used for analysis on the central server 6. The export by the recipient shop 1 and the uploading of the exported data to the central server 6 may be performed manually, but may also be automated. This exported data may be separated into product data from the recipient shop 1 and product data from the provider shop 2. On the other hand, the CSV files and APIs provided by the central server 6 are imported by the receiving shop 1. In this case, the import is performed on all data, but it is possible to choose not to update the data for items that require real-time processing, such as the price and inventory quantity of products in the receiving shop 1's product data, among the imported items. Alternatively, it is possible to update only the product data of the providing shop 2, and not update the product data of the receiving shop 1.

[0090] The data download from the central server 6 and the import process at the receiving shop 1 can be performed manually, but they can also be automated. Furthermore, the CSV file or API format may include four design templates corresponding to the creation of each of the four types of product detail pages, but it is also possible to use fewer, more common design templates, such as a single design template. In this case, some items may become unnecessary depending on the four types, but these unnecessary items can be handled by leaving them blank, for example. Alternatively, the web page creation unit 79 may automatically add or omit the necessary HTML source code to the designated parts of the design template depending on the type.

[0091] For example, depending on whether or not the CSV file contains data for the retailer list, the web page creation unit 79 may or may not add the HTML source code for the retailer list to a designated part of the product details page design template (for example, the appropriate location to the right of the product description). This allows the use of a common design template for both cases where the retailer list exists and where it does not. By using a common design template, modifications can be eliminated or minimized at the supplier shop 1. When these four types are handled using a common design template, or when the retailer list is included on the product details page, or when the shop ID is included in the product name, the determination of whether or not the product belongs to the supplier shop in steps 113 and 129 (retailer list non-existence code) and steps 115 and 131 (whether or not the product belongs to the supplier shop) becomes unnecessary. Furthermore, if the system is configured without modification using the existing supplier shop 1, it is difficult to directly link to the shopping cart from each supplier shop 2 in the retailer list, as explained in step 125. Therefore, it is desirable to prepare individual product detail pages linked from each supplier shop 2 in the retailer list, and to link to the shopping cart from the purchase button placed on these product detail pages.

[0092] Note that a list of retailers does not necessarily have to be created or published. Furthermore, the search results list, list page, and related products section may only display product detail pages for individual products, as shown in Figures 17 and 18. Additionally, the provider shop 1 may be able to select whether or not to create a list of retailers, whether or not to include the list on product detail pages, etc., and whether or not to display product detail pages only for individual products, in the management screen 201 described later. Moreover, if a product from provider shop 2 exists that is identical to a product from provider shop 1, the search results list may display the product from provider shop 1, etc., but exclude the product from provider shop 2. This display option may also be freely selectable in the management screen 201.

[0093] Furthermore, the management screen 201 may allow users to freely choose whether or not to include the product data of supplier shop 1 in the list of retailers. Also, the management screen 203, described later, may allow supplier shop 2 to freely choose whether or not to include the product data of supplier shop 2 in the list of retailers. Furthermore, through the management screen 201 of the provider shop 1, the provider shop 1 can specify at least one of the following: genre, manufacturer name, brand name, specifications, product name, etc. It is desirable that searching by search keyword also be possible. The central server 6 then receives the specified genre, etc. data from the provider shop 1 and then filters the product data in the retailer list database 31 and the individual product database 45 based on this genre, etc. However, depending on the wishes or choices of the provider shop 1, it is also possible to filter the product data only in the individual product database 45.

[0094] Subsequently, the central server 6 sends the filtered product data to the server 7 of the receiving shop 1 via API or CSV file. The web page creation unit 79 of the receiving shop 1 imports the received product data, creates a list page and related product web pages, and displays them to the user. The list page is created by mixing the newly added products with the products that were originally available. However, as mentioned above, they may also be displayed in a separate section. However, it is also possible to display a list of products received via API or CSV file on the management screen 201 of the provider shop 1, allowing the provider shop 1 to select the necessary products. In this case, specifying the required genre would allow the selection of products belonging to that genre to be made.

[0095] Furthermore, in this case, it may be possible to allow users to select which category of products from supplier shop 2 belongs to in recipient shop 1. Data related to the selected product is sent to the central server 6. In this case, only the product data related to the selected product is filtered at the central server 6 and then provided from the central server 6 via API. Alternatively, the product data for the selected product may be filtered at the calculation unit 71 of the server 7 of the receiving shop 1. The web page creation unit 79 of the receiving shop 1 takes the filtered product data, creates a list page and related product web pages, and displays them to the user. Product data may be transferred via CSV file between the central server 6 and the server 7 of the customer shop 1, rather than via API. This allows supplier shop 1 to list only the necessary product data from supplier shop 2's genres that are common to the genres originally listed on supplier shop 1, thereby strengthening its sales capabilities while adhering to supplier shop 1's website product listing policy.

[0096] However, processing via the management screen 201 of the recipient shop 1 can also be performed on the central server 6. Similarly, the provider shop 2 may also be able to select the products and genres that it can provide to the recipient shop 1. Furthermore, in this case, it may be possible to select which genre of products in receiving shop 1 the products of providing shop 2 belong to. The selection of products and genres that can be provided to receiving shop 1, and the genre association, may be performed on the central server 6 side. In addition, the management screen 203 of providing shop 2 may allow the selling price of products when providing product data to receiving shop 1 to be adjusted to a price different from the price on providing shop 2's own e-commerce site.

[0097] Next, we will explain the purchase process. When the purchase button 101 is clicked on the product details page for product a in Figures 15 to 18, product a is added to a shopping cart (not shown). Similarly, when the purchase button (not shown) for supplier shop 2, listed in the retailer list columns 103 and 115, is clicked, product a from supplier shop 2 is added to the shopping cart. Furthermore, if you click on this provider shop 2, you may be able to view more detailed product data, including a detailed description of product a from provider shop 2 as shown in Figure 18, as a product details page on provider shop 1. Then, you may click the purchase button 101 on this product details page. Subsequently, the payment processing is carried out by the supplier shop 1. The supplier shop 2 is notified that product a has been purchased, and the supplier shop 2 then proceeds with shipping product a.

[0098] Furthermore, instead of processing payments on the receiving shop 1 side, the payment processing for product purchases may be handled by the providing shop 2 side. In this case, for example, when a user clicks the purchase button 101 or a shop listed in the retailer list 103 or 115 on the product details page of product a, the user is directed to the product details page of providing shop 2, which is linked in the purchase button 101 or retailer list 103 or 115. The user can then purchase the product. A certain amount may be charged as a sales commission each time a click is made. The number of clicks can be counted by the receiving shop 1 side or by the central server 6 side. Alternatively, similar to so-called affiliate processing, the payment processing for product purchases could be handled by the provider shop 2, and a sales commission could be generated when the central server 6 confirms that the user purchased product a from provider shop 2 via the product details page of provider shop 1.

[0099] Next, we will explain the management system between the receiving shop 1 and the providing shop 2. Figure 20 shows the relationship between Shop A of Provider Shop 1 and Provider Shops 2-1, 2-2, and 2-3, which are partnered with Shop A. Provider Shop 2-3 also has partnerships with Provider Shop B and Provider Shop C of Provider Shop 1. The management tool for this sales support system is installed on each shop's server. However, the management tool may be installed only on the provider shop's side. Alternatively, instead of installing the management tool on each shop's server, the management tool for each shop may be located on the central server 6.

[0100] When product a from supplier shop 2 is purchased at supplier shop 1's shop A, data such as the supplier shop name, product information for product a, the name of the user who made the purchase, and the shipping address for product a are automatically transmitted or analyzed via the central server 6 at the time of purchase, and received by the communication unit 55 of supplier shop 2's server 4. This data is then stored in the management unit 77 of supplier shop 1's server 7 and can be viewed on the management screen 201 controlled by the display / operation unit 73. This data is also stored in the management unit 57 of supplier shop 2's server 4 and can be viewed on the management screen 203 controlled by the display / operation unit 53. Note that management screens 201 and 203 may also be made accessible via a browser through the central server 6.

[0101] However, the information may also be transmitted to the provider shop's server 4 via an email automatically sent from the provider shop's server 7 when a purchase is made, either via communication or in conjunction with communication. This email may be a copy of the sales confirmation email sent from server 7 to the user. If only an email is sent and no communication is made, the necessary information should be predefined so that the server 4 program can extract it from the email text. However, the email text may also be sent to the central server 6, where it is analyzed, and the results of the analysis are sent back to server 4. The results of the analysis may then be made viewable on the central server 6's management screen 201 or management screen 203. The email contains text such as the shop name of the supplier shop 1, product information for product a, purchase price, purchase date and time, the name of the user who made the purchase, and the shipping address for product a. Furthermore, as explained in step 117, if the shop ID or similar information is added to the product name on the central server 6 side, the shop name can be determined by analyzing this code.

[0102] Furthermore, when product a, which was ordered by supplier shop 2, is shipped to the user, the user clicks a "shipping complete" button (not shown) displayed on the management screen 203. In this case, contrary to the above, the information is transmitted via the communication unit 55 of server 4 of supplier shop 2 and received by server 7 of recipient shop 1. The data indicating that shipping is complete is stored in the management unit 77 of server 7 of recipient shop 1 and can also be viewed on the management screen 201 controlled by the display / operation unit 73.

[0103] This data is also stored in the management unit 57 of server 4 of supplier shop 2, and can be viewed on the management screen 203 controlled by the display / operation unit 53. Notification of shipment completion is sent to the user via email from server 4 of supplier shop 2 or server 7 of recipient shop 1. Furthermore, if the management screen 203 is installed on the central server 6, the "shipping complete" button will be displayed on the management screen 203 via the central server 6. Also, if the management screen 201 is installed on the central server 6, the data indicating shipping completion can be viewed on the management screen 201 via the central server 6. In this case, the shipping completion notification will be sent to the user via email from the central server 6. Furthermore, the management unit 57 of server 4 in supplier shop 2 and the management unit 77 of server 7 in recipient shop 1 store inventory quantities and sales commissions calculated by calculation units 51 and 71 based on the product sales history. These inventory quantities and sales commissions may also be calculated by the calculation unit 11 of the central server 6.

[0104] Next, we will explain how to manage sales history data. Figure 21 is a conceptual diagram showing how sales history data stored in the management unit 77 of server 7 of supplier shop 1 is displayed on the management screen 201. The management screen 201 records the sales history of products handled by supplier shop 1 (our company) and the sales history of products from each supplier shop 2 in chronological order.

[0105] For example, on January 6th at 9:00 AM, a product handled by the company was sold on the website 9 of supplier shop 1. Then, at 10:00 AM on January 6th, product 1 from supplier shop 2-1 was sold. Therefore, the number of units sold for product 1 from supplier shop 2-1 is incremented by 1. Subsequently, at 8:00 AM on January 7th, product 2 from supplier shop 2-2 was sold. Therefore, the number of units sold for product 2 from supplier shop 2-2 is incremented by 1. Sales are recorded in a similar manner thereafter.

[0106] However, the management unit 77 of server 7 may manage and display the sales history of its own products and the sales history of products from each supplier shop 2 separately. Also, clicking on product 1 will allow users to view the sales history for product 1 only. By clicking on the shop name or switching tabs, users can also view the sales history and sales performance for each shop. The calculation unit 71 of server 7 can calculate the sales commission. For example, if a total of 3 units of product 1 from supplier shop 2-1 have been sold up to this point, and the unit sales commission is 100 yen, then the calculation would be 100 yen x 3 units = 300 yen.

[0107] Figure 22 is a conceptual diagram showing how sales history data stored in the management unit 57 of server 4 on the provider shop 2-3 side is displayed on the management screen 203. The management screen 203 records the sales history of products purchased at each recipient shop 1, as well as the sales history and inventory levels of products (the provider shop 2-3) in chronological order. However, the management unit 57 of server 4 may also manage and display the sales history of its own products and the sales history of products from each supplier shop 1 separately. For example, let's say initially, supplier shop 2-3 had 5 units of product 3 in stock. Then, in Figure 22, the history shows that 1 unit of product 3 from supplier shop 2-3 was sold at 11:00 AM on January 9th at shop A of recipient shop 1. This sale is also recorded in the history of recipient shop 1, as shown in Figure 21, indicating that product 3 was sold at 11:00 AM on January 9th.

[0108] At this point, the calculation unit 51 of server 4 on the supplier shop 2-3 side decrements the inventory of product 3 by 1 to 4. At 12:00 PM on January 9th, one unit of product 3 was sold at supplier shop 2-3 (our own shop). Therefore, the calculation unit 51 decrements the inventory of product 3 by one unit to make it 3 units. Subsequently, at 1:00 PM on January 9th, one unit of product 3 from supplier shop 2-3 was sold at the website of customer shop 1, store B. Therefore, the calculation unit 51 decrements the inventory of product 3 by one unit to make it 2 units. In this way, sales history and inventory management can be viewed together. Furthermore, if the management screens 201 and 203 are installed on the central server 6, the calculation units 51 and 71 will be provided on the central server 6.

[0109] Figure 23 shows an example where provider shop 2-3 is also provider shop 1. In this case, for example, in Figure 20, shop A and provider shops 2-3 may both serve as provider and recipient. Even in this case, management is possible using the same administration screen 203. However, it may be possible to view the administration screen for provider shop 2 and the administration screen for recipient shop 1 separately. Switching between them using tabs may also be possible. Furthermore, this so-called reciprocal sales relationship between shops may be established, for example, between provider shop 2-3 and multiple partners. Also, a shop is free to decide whether to take the position of provider shop 2 or provider shop 1.

[0110] Furthermore, while the central server 6 may determine the availability and quantity of a product based on the web page of the supplier shop 2, the supplier shop 2 may also send this data to the central server 6. For products that are out of stock, the central server 6 will send a notification to the supplier shop 1 via API. However, in this case, the API may choose not to provide the product data for that product.

[0111] Furthermore, the sales history and inventory management data can be managed not only for affiliated shops and marketplaces but also for non-affiliated shops and marketplaces within this sales support system. In this case, sales data will be received from these shops and marketplaces via email, and the email content will be automatically analyzed and published as described above. You can receive this sales data email directly from this shop or mall, or you can set up to receive forwarded emails. As a result, supplier shop 1 can be transformed into an online shopping mall with participation from multiple supplier shops 2. In this case, the existing online shopping system of supplier shop 1 can be used as is, with little to no modifications required to create the mall. Even if supplier shop 1 is newly deployed within the central server 6, it is possible to create an easy-to-use mall where similar products are grouped together, or where products from multiple supplier shops 2 are handled. Furthermore, mutual sales between shops and sales of partner shops handling each other's products can be easily implemented with little to no modifications required, even without the physical movement of goods.

[0112] Furthermore, you may inform your partners with whom you engage in reciprocal sales or partnership sales about the details of your store's promotional campaigns through management screens 201 and 203, and solicit shops that will support the campaign. Campaign announcements can be made to both the receiving shop 1 and the providing shop 2. In this case, it is desirable to have the same campaign period across all shops and for multiple shops to run a common campaign. Whether or not to run a joint campaign is left to each shop's discretion. Specifically, although the diagram is omitted, the management screens 201 and 203 will have tabs for "Submit a campaign proposal" and "Read campaign proposals from other stores." Clicking the "Submit a campaign proposal" tab will open a page where the campaign period can be set. Then, it will be possible to set the scope of the campaign, such as whether it will apply to all of the store's products, some products, or a specific category.

[0113] Furthermore, you can select the details of the campaign. These campaign details can include things like free shipping, adding a bonus item, free shipping for orders above a certain amount, a percentage of the purchase price back in cash, discounts, or point rewards. If funding is required, you can select the source of that funding. You can also freely write the campaign details by entering text in a text box. You can also choose whether to send the campaign to all partner shops or to select recipients from a list of partner shops displayed in a pop-up window. After making these selections and pressing the send button, the campaign details will be sent to the specified recipients.

[0114] On the other hand, clicking the "Read Campaign Proposals from Other Stores" tab allows you to view campaign proposals from other stores. This page lists the names of the shops that submitted campaign proposals, the campaign period, key points of the campaign, and links to the details page. Clicking the link to the details page will show you the details of the proposal. If your store also supports this campaign, click the "Support" button. If there are items that require a response, you can respond by selecting options or entering text into the text box. This allows partner shop 1 to run a campaign with the same content not only for its own products but also for products from multiple participating supplier shops 2. Alternatively, multiple participating shops can run the same campaign simultaneously. As a result, a collaborative relationship is built between shops engaged in reciprocal and partner sales, and sales power can be strengthened under a common campaign.

[0115] Next, we will explain how shops can implement systems such as delivery, information requests, coupon application, takeout, reservations, orders, services for foreign customers, live commerce, and video advertising. First, we will explain how to implement these systems in existing shops. Center Server 6 allows existing shops to apply to implement these systems. These include: Delivery, which delivers meals to homes and offices via the internet; Information Request, which allows users to request necessary materials online; Coupon Application, which allows users to use issued coupons online; Takeout, which allows online pickup of goods; Reservation, which allows online reservations for accommodations, restaurant tables, and product purchases; Cash Rebate, which allows online purchases of goods at a cash discount; and Price Negotiation, which allows online price negotiation with a virtual store clerk. The Foreigner Purchase option allows foreign users, whether overseas or domestic, who are not fluent in Japanese, to order and purchase domestically sold products.

[0116] Next, we will explain using the example of requesting information via the internet. As shown in the flowchart in Figure 24, in step 151, similar to steps 1 to 4 in Figure 7, the central server 6 collects product data from shop K, which has submitted a request for information, for example. This data collection may be performed automatically by the patrol program 21 on shop K's e-commerce site, or it may be done by providing a CSV file or by manual work. Data acquisition and input may also be performed only when there are updates, rather than every time the site is patrolled. Then, in step 153, the product data analysis program 23 on the center server 6 automatically embeds source code in HTML format into the appropriate place (for example, the top part of the product description 141) in the product description text 141 displayed on the product details page 140 as shown in Figure 25. The source code contains the URL of the link destination, which includes the image URL of the information request button 143, the shop ID, and the product code as parameters. The image of the information request button 143 is prepared in the database 30 on the center server 6. The product code is embedded according to the product displayed on each product details page 140. However, a script to display the information request button 143 may also be embedded as source code in the product description text 141. The script may be composed of, for example, JavaScript (registered trademark), and the information request button 143 may be placed on the product details page 140, or a pop-up screen may be displayed and the information request button 143 may be placed on that screen. Alternatively, a link may be generated on the product details page 140, and clicking this link may display a pop-up screen. By checking for matches between the product data collected in step 151 and the previously acquired product data, it can be determined that product data has been added, deleted, or updated. Accordingly, the product data analysis program 23 on the center server 6 edits the product data that has been added, deleted, or updated. At this time, the source code for the document request button 143 is automatically embedded for the added or updated product data.

[0117] In step 155, the central server 6 saves the processed product data to a CSV file and provides this CSV file to store K, or provides it to store K's server via API. In step 157, store K imports this CSV file, or retrieves the product data via API, and the web page creation section of store K's server feeds this product data into the design template, automatically creating the product details page 140. Importing the CSV file can be done manually or automatically.

[0118] Next, in step 161 of Figure 26, a user visiting the online shopping site of store K clicks the "Request Information" button 143 on the product details page 140. In this case, in step 163, the destination URL, which includes the shop ID and product code as parameters, is sent to the central server 6. Then, in step 165, the central server 6 receives this URL, and in step 167, the shop ID and product code are parsed. In step 169, the user support and management program 25 is activated, and the necessary items and content corresponding to the shop ID and product code are read from the user support and management database 47 on the central server 6 side.

[0119] It is desirable that K Store pre-register the items and content required for this document request on the management screen of the center server 6. The user-facing items among those set here will be displayed to the user during the processing of the user support / management program 25. Specifically, based on the required items and content read from the user support / management database 47, a screen is created that includes inquiries to the user, selection and registration of required items, and notifications, which will be displayed during the document request processing. Subsequently, the user responds to the screen displayed in step 171 by selecting and registering required items. After the document request processing is complete, in step 173, the center server 6 notifies the user and K Store of the completion of the request via screen and email. This allows K store to easily add the information request button 143 without any modifications. This applies not only to the information request button 143, but also to buttons for delivery, coupon application, takeout, reservations, cash back, price negotiation, purchase, foreign purchase, and live commerce start. Instead of just adding one button, multiple buttons can be added as needed.

[0120] Next, we will explain how to display different purchase processing screens to users when a partner shop 1, which engages in reciprocal sales, partnership sales, and mall-like operations, introduces mechanisms for purchase, delivery, information requests, coupon application, takeout, reservations, orders, and purchases by foreigners, both between partner shop 1 and provider shop 2, and for each provider shop 2. When engaging in reciprocal sales, partner sales, or mall-based sales, it is possible to use the existing purchase processing system of supplier shop 1 as is. In this case, if the specifications for purchase processing are the same or can be uniformly standardized between supplier shop 1 and each supplier shop 2, there is no problem in continuing to process transactions based on the same specifications of supplier shop 1 as before. However, when businesses in the same industry, such as those providing delivery services, engage in reciprocal sales, discrepancies in specifications regarding delivery and manufacturing times may occur between the receiving shop 1 and each providing shop 2, or between each providing shop 2 itself. The following describes a method to facilitate participation in reciprocal and collaborative sales by compensating for these discrepancies in specifications through settings on the management screen of the central server 6. Note that when reciprocal sales are conducted between businesses in different industries, the differences in specifications become more pronounced, but participation can be encouraged by defining unique specifications for each providing shop 2 using a similar setting method.

[0121] To give an example regarding delivery, let's assume that the preparation time, delivery fee, and delivery company differ between the receiving shop 1 and each providing shop 2. In such a case, each providing shop 2 would set the time from receiving an order to completing product production, the delivery time, the delivery fee, and the specifications of the delivery company in advance on the management screen 205 provided by the central server 6, as shown in Figure 27. However, these specifications can be changed depending on the requests of the business. Therefore, it is desirable for the central server 6 to group the specifications for each business in a way that makes it easy for each business to select, and to prepare the necessary settings and specifications for each business in advance and save them in the user support / management database 47. For example, the settings could be "standard time from receiving an order to completing production" or "standard time until delivery," and the specifications could be "5 minutes," "10 minutes," "15 minutes," etc. It is desirable that these specifications be selectable by the business, but it may also be possible to allow free entry. When displaying the management screen 205 to a business operator, the central server 6 first reads the business details of each business operator, which are pre-registered, from the database 30. It then extracts the setting items and specifications that match those business details from the user support and management database 47, and automatically creates and displays a web page for the management screen 205 tailored to each business operator. Furthermore, it is desirable to separate each business into parts that are common to all businesses and parts that are not, and to have businesses first set or fill in the common parts, and then set or fill in the non-common parts as special items. The information set or entered by the businesses here will be stored in the user support and management database 47.

[0122] Next, we will explain how to implement a delivery system, etc., following the flowchart. As shown in the flowchart in Figure 28, in step 181, similar to steps 1 to 4 in Figure 7 and steps 5 to 10 in Figure 8, the central server 6 collects product data from the recipient shop 1 and each provider shop 2 that have applied to provide delivery. This data collection may be done automatically by the patrol program 21, but it may also be done by providing a CSV file or by manual work. Data acquisition and data entry may be done only when there are updates, rather than every time a patrol is performed.

[0123] In step 183, the central server 6 extracts only the products from the provider shop 2's product data that have been previously selected by the recipient shop 1. That is, the recipient shop 1 may include all of the acquired product data in the subsequent processing, or it may select only the necessary products that it wishes to list in its store. The selection of necessary products can be done on the central server 6's management screen. Note that the product data from provider shop 2 may also be those selected by provider shop 2. Subsequently, in step 185, the center server 6 performs the following editing on the product data of each provider shop 2 and the product data of the recipient shop 1 selected in step 183. Specifically, the product data analysis program 23 automatically generates source code in HTML format for this product data, which includes the image URL of the delivery button, the shop ID, and the product code as parameters for the link destination URL. The generated source code is then automatically added to the appropriate location (for example, at the top) in the product description 161 of both the receiving shop 1 and each providing shop 2. Figure 29 shows an example screen where the generated delivery button 163 is placed at the top of the product description 161 of providing shop 2. In this case, no modification is necessary. The source code may also be composed of a script as described above (the same applies below).

[0124] Furthermore, the purchase button 101 shown in Figure 5, which is originally displayed on the product details page by the supplier shop 1, may be modified to be removed from the product details page. Furthermore, as shown in the example of the product details page 170 of supplier shop 2 in Figure 30, the source code for the generated delivery button 173 may be embedded in the same location as the source code for the originally placed purchase button 101 or order button by modifying the server 7. Alternatively, the delivery button 173 may be displayed alongside the purchase button 101 or order button. The delivery button 173 may also be displayed at the top of the header section of the product details page 170. In these cases, it is desirable for the button to be displayed with a comment. It may also be displayed as a banner. Images for the delivery buttons 163 and 173 are prepared in the database 30 of the central server 6. This method of replacing or embedding the source code for the delivery button 173 is applicable even if the shop does not engage in reciprocal sales, partner sales, or mall operations. The source code for delivery button 173 is an HTML-formatted source code containing the URL of the link destination, which includes the image URL and shop ID of the delivery button as parameters. It is desirable to provide this source code to the receiving shop 1 with the parameter section corresponding to the product code left blank. The web page creation unit 79 of the server 7 on the receiving shop 1 side then generates the product details page 170 by embedding the product code assigned by the receiving shop 1 into this blank section. The product code is generated to correspond to the product listed on each product details page 170. Since this product code is already recognized by the central server 6 from the product data collected in step 181, the central server 6 can process deliveries smoothly for each product. However, the product code may be one generated by the central server 6 at the receiving shop 1. Even in this case, processing can be done with a common product code, so the central server 6 can process deliveries smoothly for each product. Furthermore, the central server 6 may obtain the URL of the product details page 170 and parse the product code contained within that URL. When a link button such as the delivery button 173 is clicked, the source URL is sent to the central server 6 as a parameter attached to the link URL, so the central server 6 can obtain this source URL. Alternatively, the URL of the product details page 170 may be obtained by a script and sent to the central server 6. The shop name can be identified by extracting the domain from the URL. With the product code and shop data obtained in this way, the central server 6 can refer to the database 30 to identify the product and smoothly process deliveries and other operations for each product. The source code including the link URL can be provided as a common one-line source code for all product detail pages on the shop side. Even if shops are engaging in reciprocal sales, partner sales, or marketplace operations, it's simple because you only need to embed a common source code into all product detail pages. If you're using a design template, you only need to modify one place. Furthermore, when identifying products on the central server 6, a script can be embedded in the appropriate place on product details page 170 to retrieve the title or product name. If the title is extracted, the product name can be extracted from this title. This can then be used to identify the product. In some cases, the shop name can also be extracted from this title, but the shop name can also be extracted from the source code of product details page 170. Alternatively, instead of placing the "Request Information" button (143) and the "Delivery" buttons (163 and 173) on product detail pages 140, 160, and 170, you can embed anchor text instead. In this case, the source code should contain the anchor text, not the image URLs of the "Request Information" or "Delivery" buttons.

[0125] In step 187, the central server 6 automatically adds the shop name and a comment containing this shop name (for example, "This product is from store A and will be shipped from store A") to the appropriate place (e.g., the top) in the product name and product description 161 and 171. This addition is performed on the product data of each providing shop 2, as shown in the comment 165 embedded at the top of product description 161 in Figure 29 and at the top of product description 171 in Figure 30, but is not necessary for the product data of receiving shop 1. It is desirable that the text be emphasized, decorated, or enclosed in parentheses to make it stand out. The embedding of the comment 165 is done by inserting text and tags into product description 161 and 171 at the central server 6, so no modification is required on the receiving shop 1 side. However, it is not limited to insertion; some text or images in product description 161 and 171 may be edited by deleting or changing them to make them stand out. Additionally, the shop name and comment text may be embedded within the source code generated in step 185. Furthermore, the shop name and comment text may be displayed in a pop-up screen or similar screen generated by the aforementioned script. The shop name and comment text may also include translations into other languages. Furthermore, for the product data of the receiving shop 1 and the providing shop 2, for example, at the bottom of product descriptions 161 and 171, the text translated into another language by the central server 6 may be embedded. The same applies to product description 141. In this case as well, no modification is required on the shop's side. Then, a request for information button 143 and delivery buttons 163 and 173 may be placed above or below this translated text. Furthermore, by determining whether the product data collected in step 151 has been added, deleted, or updated, it is possible to automatically embed translated text accordingly. Therefore, no effort is required on the shop's end.

[0126] In step 189, the central server 6 provides the processed product data to the receiving shop 1 as a CSV file or via API. In step 191, the receiving shop 1 manually or automatically imports this CSV file or retrieves the product data via API, and the web page creation unit 79 feeds this product data into the design template, automatically creating product detail pages 160 and 170. This applies not only to delivery buttons, but also to buttons for requesting information, applying coupons, takeout, making reservations, cashback, price negotiation, purchase, foreign purchases, live commerce start, and video advertising. At least one of these buttons may be placed on product detail pages 160 and 170. Multiple buttons may also be placed side by side.

[0127] Alternatively, instead of embedding a delivery button, the retailer lists 103 and 115 may be used as lists of retailers that offer delivery. When a user clicks on a shop listed in retailer lists 103 and 115, the delivery process for that shop, prepared by the central server 6, may operate in the same manner as described above. Furthermore, when a user clicks on a shop listed in retailer lists 103 and 115, the central server 6 may generate a product details page based on the product data of the supplier shop 2 and display it to the user, with a delivery button placed on that page. Furthermore, when a user clicks on a shop listed in the retailer lists 103 and 115, the supplier shop 1 generates individual product detail pages 120 and 130, as shown in Figures 17 and 18, for example. A delivery button may then be embedded on that page using the method described above. Alternatively, product detail pages 160 and 170 may contain buttons or anchor text with embedded URLs that link to a webpage containing a list of retailers that offer delivery.

[0128] In step 201 of Figure 31, a user visiting the e-commerce site of supplier shop 1 clicks the delivery buttons 163 and 173 on product detail pages 160 and 170. However, it is also possible to have the anchor text clicked instead of the buttons. In this case, in step 203, a link URL containing the shop ID and product code as parameters is sent to the central server 6. Then, in step 205, the central server 6 receives this URL, and in step 207, the shop ID and product code are parsed. In step 209, the user support and management program 25 of the central server 6 operates and generates, for example, an order screen based on this shop ID and product code, and delivers it to the user's information terminal, such as a personal computer 3 or smartphone 5. However, on product detail pages 160 and 170, links may be embedded instead of delivery buttons 163 and 173, and when these links are clicked, the product detail page created on the central server 6 may be displayed. This product detail page may include a product description, comments, product name, and notes regarding ordering. Translations of these into other languages ​​may also be included. Furthermore, an order screen may be generated after clicking the delivery button displayed on this product detail page. The same applies to product detail page 140. In step 211, the user enters the order quantity on this order screen and sends it to the central server 6. Then, in step 213, the central server 6 receives the order quantity data.

[0129] In step 215, the configuration specification data, which is pre-configured for each business and stored in the user support and management database 47, is read from the management screen 205 in Figure 27. In step 217, the current number of orders and the date and time of the orders are read. Then, in step 219, the user support and management program 25 calculates the time until product completion and the time until delivery based on the contents of the configuration specification data and the current number of orders and the date and time of the orders. However, this calculation may be estimated by AI based on a large amount of historical data. In step 221, based on this calculation result and the configuration specification data, the user support and management program 25 automatically generates an inquiry screen 207 for the user from the supplier shop 2, as shown in Figure 32. This inquiry screen 207 indicates that the purchased product is from supplier shop 2, and displays the necessary information for delivery based on the information previously registered by supplier shop 2.

[0130] This allows for the display of an inquiry screen 207 with detailed information tailored to each providing shop 2. Furthermore, users can clearly identify the shop providing the product and the delivery location. In step 223, when the user responds to the inquiry screen 207 and presses the "Next" button, the process proceeds to payment, and then in step 225, the order is confirmed. Subsequently, in step 227, order confirmation emails are sent to the user, providing shop 1, and providing shop 2. As a result, even if the receiving shop 1 and each providing shop 2 require different delivery specifications, takeout specifications, reservation specifications, etc., in the case of mutual sales, partner sales, or mall integration, it can be easily accommodated.

[0131] Next, we will explain how to integrate online orders and in-store orders for delivery and other services. The following explanation uses a ramen shop as an example, as shown on product details page 180 in Figure 33. In this example of a ramen shop (Shop A), we assume that most of the product data is listed on this webpage and that there are no order buttons. A delivery button 183 is placed in an appropriate location on this webpage. The source code for delivery button 183 is an HTML-formatted source code containing the URL of the link destination, which includes the image URL or anchor text of the delivery button, the shop ID, and the business type code as parameters. The parameters may also include group IDs for each group of multiple products. This source code is generated by the center and provided to the ramen shop (Shop A). The business type code is a code associated with settings and specifications that are pre-prepared for each type of business and stored in the user support and management database 47, as shown in Figure 34. However, a business type code is not required if a shop only operates one type of business. Also, the source code for the delivery button may be embedded in the web page for all products listed on the product details page 180.

[0132] When the delivery button 183 is clicked on the product details page 180, the user support and management program 25 on the central server 6 generates the product details page 190 and provides it to the user's information terminal. This product details page 190 is generated by the user support and management program 25 reading product data stored in the database 30, which is acquired using the method described in step 151. Each product listed on this product details page 190 has an order button 191. This product details page 190 may list only one product, but as shown in Figure 33, it is also possible to list multiple products in accordance with the content of the product details page 180.

[0133] When a user clicks the order button 191, the process is almost identical to that of steps 201 and beyond. In addition to the order button 191, buttons such as a request for information button, a coupon application button, a takeout button, a reservation button, a cash back button, a price negotiation button, a button for foreign buyers, a live commerce start button, and video advertisements may be placed alongside it. Furthermore, product details page 190 may display product data from provider shop 2 through reciprocal sales or partnership sales. In this case, a comment such as "This product data is from provider shop 2 and will be shipped from provider shop 2" can be added in an appropriate place on product details page 190. Since product details page 190 is created on the center server 6, the location of the comment can be arbitrarily determined by the center. Product details page 190 may also be created in other languages ​​on the center server 6. Furthermore, by collecting product data as in step 181 and determining when this product data has been added, deleted, or updated, it is possible to automatically add, delete, or update product data for products listed on product details page 190. Therefore, no effort is required on the part of the shop.

[0134] Next, I will explain how this ramen shop (Shop A) manages orders, sales, and other related matters. On the management screen 205 of this ramen shop (Shop A), the products and settings corresponding to Code 1, which is the business type code for the ramen shop, are read from the user-supported management database 47 (see Figure 34) and displayed. A specific example of the management screen 205 for this ramen shop (Shop A) is omitted. The ramen shop (Shop A) selects or enters specifications for each setting item displayed on this management screen 205 in advance. For example, for soy sauce ramen, the preparation time at this shop is 5 minutes, so 5 minutes is selected from the options of 5 minutes, 10 minutes, 15 minutes, and 20 minutes displayed in the selection box. The entered data is saved in the user-responsive management database 47, as shown in Figure 35. In addition to this soy sauce ramen, the number of orders that can be made simultaneously is also entered on the management screen 205. At this shop, the number of soy sauce ramen that can be made simultaneously is 5, so 5 is entered in the user-responsive management database 47. Also, the maximum number of orders that this shop can accept is set in the user-responsive management database 47. At this shop, it is set to 10. However, it may also be possible to set how many different types of products can be processed simultaneously.

[0135] It should be noted that ramen restaurants typically have physical locations. Therefore, it is desirable to support orders from physical stores in addition to online orders. Orders from physical stores are placed using an information terminal such as a touch-panel PC 3 or smartphone 5 connected via the central server 6 and the internet 10. It is desirable that this order processing is done by downloading a predetermined application to the information terminal. Figure 36 shows an example of a screen displayed on the information terminal. On the order screen 210, the product image 211 displays the product name and a photograph. Clicking the increment button 213 increases the number in the count display field 215 by one. Conversely, clicking the decrement button 217 decreases the number in the count display field 215 by one. The tables in the seating area of ​​this physical store are numbered. By entering the table number of the customer who placed the order in the table number input field 219, it is possible to identify whose order it is. The method of inputting the table number is arbitrary, such as entering numbers or clicking on an image. Afterward, when the send button 221 is clicked, the product ID, order quantity, table number, and order date and time of the ordered items are sent to the central server 6 and saved to the user support and management database 47.

[0136] Next, the user support and management program 25 of the central server 6 reads the data stored in the user support and management database 47 and performs the following processing. The user support and management program 25 creates the process diagram screen 240 shown in Figure 37 based on data read from the user support and management database 47, and displays it on the information terminal. The process diagram screen 240 in Figure 37 depicts, for example, the progress toward completion of three products ordered online and in physical stores at different times, in chronological order. The process diagram screen 240 displays the currently processed cases from left to right in order of the date and time the orders were received.

[0137] The process for product a will display, for example, that it is a product ordered by user α via the internet. Similarly, the processes for products b and c will display that they are orders from users with table numbers 3 and 6, respectively. The process diagrams for products a, b, and c will shift to the left as time progresses. In the example in Figure 37, products a, b, and c are currently in production at the present time. The length of each process for products a, b, and c corresponds to the production time predetermined by store A for each product. However, the processes may be displayed in order of order date and time with the same length, ignoring the production time. The length may also be shorter.

[0138] For simplicity, let's assume that store A has a maximum of 3 orders. In this case, orders from the 4th onwards will be placed in the pending orders column 250. Clicking the stop / play button 241 will fix the process diagram in that position. This is used, for example, when you want to temporarily pause the production work. Clicking it again will resume from that point. Clicking the record / play button 243 will record the flow of the process. This allows you to check the process and review the settings later. Also, moving the knob 245a on the scroll bar 245 left or right will move the processes for products a, b, and c in conjunction. For example, if production is likely to be delayed, move knob 245a to the right to adjust. If production is likely to be finished early, move knob 245a to the left to adjust. Clicking the arrow buttons 245b and 245c on the scroll bar 245 will move knob 245a in that direction by a predetermined unit of time.

[0139] Then, once production is complete, dragging and dropping the completed product to the left will briefly display a completion mark, after which the data will disappear from the screen. Alternatively, a completion box could be displayed on the left side of the process diagram screen 240, where users can drag and drop the product. Completed products are saved as finished products in the user support / management database 47. At the same time, in the pending items column 250, the user support / management program 25 extracts the next pending product d. As a result, as shown in Figure 38, product d disappears from the pending items column 250. This product d is then displayed on the process diagram screen 240, following product a, whose process has disappeared. Therefore, store A can manage the product creation process and also see which products need to be made next and which products are pending.

[0140] The production process for a product can be forcibly interrupted. For example, as shown in Figure 38, product f is originally ordered later than product e. However, if you need to produce product f earlier for some reason, you can drag and drop product f from the pending orders column 250 to the left of the process diagram screen 240, which shows the currently processing order. As a result, as shown in Figure 39, product f will automatically replace product d. Product d will then return to the pending orders column 250. Therefore, in the pending orders column 250, product d will still be the next pending item.

[0141] Next, we will explain how to create products in batches. When it is possible to create multiple servings of the same or similar product at once, the process is done in batches. For example, creating five servings of the same soy sauce ramen at once, or creating several similar ramen dishes with different toppings at once. In Figure 40, for example, if products d1, d2, and d3 are all the same type of soy sauce ramen and can be created at once, the user support / management program 25 removes products d1, d2, and d3 from the standby case column 250. Then, it moves them to the process diagram screen 240 as a combined process for products d1, d2, and d3. In this case, store A creates three servings of products d1, d2, and d3 all at once. In store A's case, the number of items that can be created at once is set to five in the user support / management database 47, so it is possible to create up to three at once. At this time, it is also possible to set how much the time increases when one additional identical product is created. For example, adding one item increases the time by one minute, adding two items increases the time by two minutes, and so on. Furthermore, in physical stores, the completion of a product can be linked to the payment process. The user support and management program 25 can track the order status of products, allowing for immediate calculation of the total sales amount for both online and physical stores.

[0142] Next, we will explain the delivery and takeout process. For deliveries, as shown in Figure 41, the estimated completion time for each item can be determined from the process diagram, and the user support and management program 25 notifies available delivery personnel of the estimated completion time. In the case of takeout, the user is notified of the estimated completion time for the item. For deliveries, the delivery person only needs to go to the store to pick up the item by the estimated completion time. Map data can be stored in the user support and management database 47 in advance, and the user support and management program 25 can read the distance on the map from the location of store A on the map and the address of the user who is the delivery destination, estimate the delivery time from this distance, and notify the user who placed the order of the estimated arrival time. The estimated completion time and estimated delivery time for each item may also be notified. The calculation of the estimated completion time and estimated delivery time for each item as described above corresponds to one aspect of the calculation method shown in step 219 of Figure 31. This allows shops to easily implement delivery and other systems. Furthermore, it enables process management not only for online orders but also for orders placed in physical stores.

[0143] Next, I will explain the process for publishing a shop's webpage to foreigners. Figure 42 shows an example of how to display the content of a product details page for foreign users, using parallel text of the original and translated text on a webpage. In Figure 42, product details page 260 has Japanese original text 1 and original text 2 between image 1 and image 2, original text 3 between image 2 and image 3, and original text 4 below image 3. Product details page 260 is a page published by the shop on its own server. The servers include server 7 of provider shop 1 and server 4 of provider shop 2. Original text 1 and original text 2 are continuous sentences, and there is no design divider such as a line between original text 1 and original text 2. The product description 261 contains a link button 263 to proceed to product details page 270 which contains parallel text of the original and translated text generated by the central server 6, and a comment 265 informing users that a webpage for foreigners is available. The link button 263 and comment text 265 were embedded in the product description text 261 by the product data analysis program 23 using the method described in steps 153 and 185. The product details page 260 was created by the web page creation unit of the shop server, which received this product data from the central server 6. Note that the comment text 265 and link button 263 may also contain comments as icons.

[0144] Images 1, 2, and 3, and original texts 1, 2, 3, and 4 on product details page 270 are reproductions of those on product details page 260. The original text is generally separated at the locations of line breaks in the HTML source code of product details page 260. Text is also separated at the locations of images. However, in the case of long texts where the number of lines up to a line break exceeds the predetermined number of lines, it is preferable to separate the text at the location of the first occurrence of "." after a predetermined number of lines. Below the original text 1, the machine-translated text 1, created by the central server 6, is placed. This machine translation can be performed in real time, or it can extract and display translations stored on the central server 6. In the case of real-time translation, only the products requested by the button will be translated, thus reducing the load on the central server 6. However, translation 1 may be partially or entirely translated by a person. The order in which images and original text appear on product details page 270 should ideally be the same as the order in which images and original text appear in the HTML source code of product details page 260. However, images alone or original text alone may be displayed together. In addition, in the example of Figure 42, the parallel text is arranged so that the original text and translation are side by side vertically on the same page, but the original text and translation may also be arranged on the left and right sides separated by a vertical dividing line. In this case, it is desirable that the positions of the first lines of original text 1 and translation 1, original text 2 and translation 2, etc., be at the same height to facilitate comparison. When the "Add to Cart" button 271 is clicked, the purchase process prepared by the central server 6 proceeds.

[0145] Furthermore, a selection box 267 may be placed in the product description 261 or on the product details page 270 so that the user can select the language they wish to use. A translation will then be generated for the language selected. It is desirable that the language remains selected once it has been chosen. When a language is selected in the selection box 267, the product details page created in that language may be displayed immediately. In the above explanation, the product details page 270 was described as being generated by the central server 6 and displayed on the user's information terminal. However, the product data for the parallel text of the original and translated texts may be generated by the central server 6 and provided to the shop, and the shop server may then input this product data into the design template of the product details page 260 to create the web page and display it on the user's information terminal. In this case, as described in steps 153 and 185, the product data analysis program 23 embeds the translated text, a purchase button, and comments into the shop's product data. The translated text may be displayed side by side, corresponding to the original text block as shown in Figure 42, or it may be placed together at the bottom of the product description 261 without being separated into blocks. When the embedded purchase button is clicked, the purchase process on the central server 6 is executed. However, the purchase button may not be embedded on the central server 6, and the purchase may be made using the shop's purchase button 101. By displaying the original text and the translated text side-by-side for each block, users can easily read and make accurate judgments about the information. Regarding how the original and translated texts are presented to users, the product details page generated by the central server 6 will initially only display the translated text. A parallel text button can then be placed in an appropriate location on this product details page. When this button is clicked, a comparison of the original and translated texts, as shown on product details page 270, will be displayed. For example, it would be easier to read if the original text had a background color, while the translated text remained in white. No system modifications are required on the shop's end to perform the above processing. Furthermore, this processing is not limited to access from overseas, but can also be used by foreigners residing in Japan. As explained in the example in Figure 30 and the example of the delivery button 173, the comment text 265 and link button 263 may be placed in appropriate locations on the homepage. Furthermore, the comment text 265 and link button 263 may be placed on the product detail pages of both the partner shop 1 and the provider shop 2, where reciprocal sales, partner sales, and mall-like sales are taking place. The comment text 265 may include messages such as that foreigners can purchase this product, that this product will be shipped from provider shop 2, that this product is a prohibited export item, or that a live commerce event will be held. It may also include multiple messages. This message can be edited by the shop by entering text into a text box on the management screen of the central server 6. Alternatively, the shop may select from pre-prepared text. If this message is embedded in the detail text by the central server 6, no modification is required on the shop's side. On the other hand, if this message is placed in an appropriate location on the homepage, the necessary script is provided as source code, and the shop embeds it in the product detail page. This message may be editable for each product, or it is desirable that it be editable as a common message for all products.

[0146] Next, we will explain the process of making the shop's product data searchable by foreigners. In Figure 43, the shop's existing web page 280 includes a search input field 281 and a search button 283. A link button 285 is placed adjacent to these. It is also desirable to place a language selection box 267. When the user clicks the link button 285, they are redirected to a search page 290 created and provided by the central server 6. When the user enters a search query in the designated language in the search input field 291 and clicks the search button 293, the database 30 on the central server 6 is searched, and a list of search results is displayed on the search page 290. It is desirable that the designated language is the language selected in the language selection box 267. Furthermore, the product names and descriptions of all products collected in steps 151 and 181 shall be translated into at least one target language and stored in the database 30 of the center server 6. However, only the product names may be translated. However, the keywords entered in the search input fields 281 and 291 may be translated into a translated term by the center server 6, and the search may be performed using that translated term. Alternatively, keywords may be entered in Japanese in the search input fields 281 and 291, translated into a foreign language by the center server 6, and then the search may be performed, or keywords may be entered in a foreign language, translated into Japanese by the center server 6, and then the search may be performed. In this case, since translation of all product data is not required, the translation load on the central server 6 is reduced. Also, if there is not a one-to-one relationship between Japanese words and foreign language words, and multiple candidates appear, it is desirable to present these candidates to the user and allow them to select one. Then, a search is performed on the central server 6's database 30 for the keyword selected by the user. The search may be performed only on product names. The search results list may be displayed in the language selected in the language selection box 267 located on web page 280 or search page 290, or it may be displayed in Japanese. It is desirable that the language be maintained once selected. However, even without a language selection, the language type may be determined from the keywords entered in the search input field, and the search may be performed in that language. Clicking on the product name 295 displayed in the search results will display the product details page 270. The search input field 281, search button 283, link button 285, and language selection box 267 may be located in a pop-up screen generated by a script embedded in web page 280.

[0147] Next, we will explain the process of making it possible for foreigners to search directly from the shop's existing web page. The product description 301 of the existing product details page 300 of the shop shown in Figure 44 contains a search input field 303 that allows foreigners to search directly in their native language, a search button 305 for performing a search, and a comment 307. A language selection box 267 may also be embedded. This comment 307 consists of text or an image and indicates that keywords in a specified language can be entered in the search input field 303 and that a search can be performed using the search button 305. When keywords are entered in a specified language in the search input field 303 and the user clicks the search button 305, the product data stored in the database 30 of the central server 6 is searched using these keywords. The search results are then generated as a search results list web page on the central server 6.

[0148] Additionally, a breadcrumb trail (309) can be included in the product description (301). When a user clicks on this breadcrumb trail (307), they can access a list page or similar. This list page may be a webpage created on the shop server, or it may be a webpage created on the central server (6). The search input field 303, search button 305, comment text 307, selection box 267, and breadcrumb trail 309 were embedded in the product description 301 by the product data analysis program 23 in the manner described in steps 153 and 185. The product details page 300 was created by the web page creation unit of the shop server, which received this product data from the central server 6. The search input field 303, search button 305, comment text 307, selection box 267, and breadcrumb trail 309 may be embedded at the bottom of the product description 301. However, in this case, only the comment text 307 may be left at the top to make the message more prominent. Furthermore, a script for generating a popup screen may be embedded in product description 261 or product description 301, generating a popup screen that includes a link button 263, comment text 265, language selection box 267, search input field 303, search button 305, comment text 307, breadcrumb trail 309, etc. In the case of a supplier shop 1 that engages in reciprocal sales, partner sales, or mall-like activities, the central server 6 may translate all product data from supplier shop 2, or it may translate only the product data from the supplier shop 2 that is desired. Alternatively, the central server 6 may embed translated comments 265, link buttons 263 and 285, as well as search input fields 303, search buttons 305, comments 307, breadcrumb trails 309, etc., only on the product detail pages of the product data from the desired supplier shop 2. No system modifications are required on the shop's side even when performing the above processing.

[0149] Next, we will explain how to enable foreigners to perform searches using accurate translations. As shown in Figure 45, the original Japanese text in the detailed description is divided into sections, for example, at each period ".". Each section is then assigned a sequential number 311. The same number 313 is assigned to the foreign language translation corresponding to the text within that section. The same procedure is followed for product names. The detailed description and product names may be extracted from the database 30, or they may be extracted in real time from the shop's product details page. The code 313 is linked to the central server 6, and when code 313 is clicked, the central server 6 can see which part of the text has been selected. When the code 313 of the translated text is clicked, the original Japanese text corresponding to that code 313 is separated into segments and terms, as shown in Figure 46, and displayed on the homepage in a selectable manner. In this case, it is desirable that corresponding segments and terms in the original Japanese text and the translated text be displayed with the same background color. However, it is not limited to the same background color; the same numbers or codes may also be used. A checkbox 315 is provided at the beginning of each Japanese segment and term. The same applies to product names.

[0150] When checkbox 315 is selected, the selected Japanese segment or term is automatically entered into the search input field. Alternatively, the selected Japanese segment or term may be placed on the clipboard. In this case, selection is simple; just select the Japanese term with the same background color as the translation. Alternatively, selecting the translation will automatically enter the corresponding Japanese segment or term into the search input field. Furthermore, when the translation is selected, the corresponding Japanese segment or term may be highlighted with a prominent color or border. Select this Japanese segment or term if it is satisfactory. Alternatively, both the Japanese and translation sides may be selectable. When multiple Japanese segments or terms are selected, they will be entered into the search input field as an OR option. When the search button is pressed, a search is performed on the Japanese database. The search results are displayed as a search results list. At this time, the translated text in a foreign language may be extracted from the database and displayed, or it may be translated into a foreign language in real time and displayed. Even if the translation includes terms with unclear correspondences, terms with missing correspondences, or situations where the same term is not given a background color, or if there are gaps in the terminology due to lack of color, foreigners can still select appropriate Japanese terms within the context by specifying terms that are within a narrow range enclosed by adjacent corresponding colors. This makes it easy for foreigners to search by selecting appropriate terms from the text. Since these terms are translated within the context of the text, the translation accuracy is high. Therefore, highly accurate searches can be performed in Japanese. Furthermore, the search is limited to a Japanese database, resulting in low search load.

[0151] As mentioned earlier, the product details page generated by the central server 6 will initially only display the translated text. Each section of this translated text will be assigned a sequential number 313. When a number 313 is clicked, the corresponding Japanese text, similarly assigned a number 311, will be displayed. Checkboxes 315 may be provided at the beginning of each segment and term in this Japanese text. Furthermore, the search method described above for foreigners may be provided as an application program for personal computers and smartphones, or as a browser plug-in application.

[0152] Next, we will explain the process that allows foreigners to purchase goods through a list of retailers. As shown in Figure 47, when a link or button indicating that international shipping is available or that foreigners can purchase, which is placed appropriately on the product details page, is clicked, or when a language is selected in the language selection box 267, or when it is determined by analyzing the IP address that the purchase is by a foreigner or the access is from overseas, the store list 317 will display a foreigner purchase button 319 or a link or anchor text, separate from the link to the local shop or the product details page listing the shop's products. However, the store list 317 may have the foreigner purchase button 319 placed there from the beginning, regardless of this determination. When the foreigner purchase button 319 or the link or anchor text is clicked, the product details page for foreigners purchasing from the selected shop will be opened. However, instead of opening the product details page, the purchase process may be executed directly. Furthermore, while this product details page for foreigners purchasing and the purchase process are created and disclosed by the central server 6, the page displaying the foreigner purchase button 319 or the link or anchor text may also be created and disclosed by the central server 6.

[0153] If shops are engaged in reciprocal sales, partnership sales, or mall-like operations, a foreign purchase button 319 or a link or anchor text will be displayed for the retailer lists 103 and 115 shown on the product detail pages of both the partner shop 1 and the provider shop 2. However, it is also possible to proceed from the retailer lists 103 and 115 to the individual product detail pages, and to utilize the foreign purchase button or link 263 or anchor text located on those pages. Retailer lists 103 and 115 were compiled by the product data analysis program 23. However, this process can also be applied to the list of retailers that are not illustrated on so-called price comparison websites. Then, as mentioned above, a link or button indicating that foreigners can purchase the product, or a language selection box 267, can be placed in an appropriate location on the product details page that lists the retailers, and processing for foreign purchases can be performed. This makes it easy for foreigners to find shops that sell the product and to find and purchase the cheapest product. This list of retailers may also be provided as an application program for PCs and smartphones, or as a browser plug-in application.

[0154] Next, we will explain how to efficiently introduce the services mentioned above, including reciprocal sales, partnership sales, mall-style sales, and diversification, to shops. First, in order to predict the effects of implementation on the shop, we will evaluate the current situation regarding the shop's product sales and demand for product purchases. In order to conduct this evaluation, we will first analyze purchase data for each product and calculate basic attributes. Specifically, we will analyze the basic attributes for each product based on payment data such as POS data, credit card data, point data, and cashless payment data. These basic attributes are data that analyzes what kind of people purchased each product. These basic attributes are data obtained by collecting purchase data for the same product from many shops and analyzing it by linking it to the attributes of the people who purchased that product. Attributes include, for example, age group, gender, hobbies and preferences, industry, intended use, domestic or overseas demand, number of purchasers, sales revenue, number of visitors, number of overseas visitors, etc. (the same applies hereafter). Data obtained using the access analysis tools described later may also be added to these attributes.

[0155] To analyze basic attributes, as shown in Figure 48, purchase data for the same product 1 is collected and analyzed from multiple shops. The example in Figure 48 is an example of data summarizing the gender and age group of purchasers of product 1. It is assumed that product 1 was purchased by 10,000 people at shops nationwide. From the analysis results of POS data, etc., it can be seen that 90% of the purchasers were female, and in terms of age group, 1,000 people in their 20s made purchases, so the purchase rate for people in their 20s is 10%. Attribute-based analysis can also be performed on other aspects such as hobbies and preferences, industry, intended use, domestic or overseas demand, and the number of overseas visitors. Examples of hobbies and preferences include people who like mountains, the sea, games, reading, physical activity, and music. Industries include office work, technology, sales, etc. Intended use includes young women, elderly people, etc.

[0156] In Figure 48, the analysis results of the number of purchasers based on age group are normalized for ease of understanding. For example, as shown in Figure 48, the normalized data for each age group for product 1 is 10% for teenagers, 10% for those in their 20s, 20% for those in their 30s, 20% for those in their 40s, 30% for those in their 50s, and 10% for those in their 60s. Figure 48 also shows a basic attribute graph 321 for product 1, created based on this normalized data. This normalized basic attribute data for each age group is similarly analyzed for many other products besides product 1. The data from these analyses is then stored on the central server 6. However, the central server may be independent.

[0157] Next, we will explain how to determine sales attributes for each online shop using this basic attribute data. Sales attributes are an analysis of what kind of products (e.g., age group, gender, etc.) this online shop targets, or what kind of products appeal to what kind of people the online shop lists on its website. However, sales attributes may also be analyzed based on the genre of the online shop. To determine sales attributes, first, product data for online shop 1 is collected from its website or as a CSV file. This online shop 1 corresponds to supplier shop 1, supplier shop 2, or a candidate shop for these. Then, for each product belonging to online shop 1, the normalized basic attribute data for each product is read and aggregated. For example, for simplicity, let's assume that online shop 1 lists three products, product 1, product 2, and product 3, on its online store. Then, as shown in Figure 49, the basic attributes of these three products are read from the central server 6, and if the attribute is age group, a subtotal is calculated for each age group.

[0158] In the example in Figure 49, for teenagers, the basic attributes of product 1 (10%), product 2 (5%), and product 3 (5%) are read from the central server 6 and subtotaled to arrive at 20%. Similarly, the same data is aggregated for other age groups. After aggregation and normalization, the normalized data for each age group of online shop 1 is as follows, as shown in Figure 49: 7% for teenagers, 8% for those in their 20s, 12% for those in their 30s, 33% for those in their 40s, 27% for those in their 50s, and 13% for those in their 60s. Based on this normalized data, a sales attribute graph 323 for each age group of online shop 1 is created in Figure 49. Looking at the sales attribute graph 323, it can be seen that online shop 1 is an online shopping site that features many products targeting users in their 40s and 50s. Furthermore, as sales attributes, the percentage of best-selling products and the percentage of high-profit margin products handled by this online shop 1 may be calculated and displayed graphically along with sales attribute graph 323. Here, the percentage of best-selling products is the ratio of the number of products generally recognized as best-selling products among the products handled by this online shop 1 to the total number of products in this online shop 1. The percentage of high-profit margin products is the ratio of the number of products that are expected to have a high profit margin among the products handled by this online shop 1 to the total number of products in this online shop 1.

[0159] Next, we will explain how to determine the purchase attributes for each shop. Purchase attributes refer to characteristics that analyze purchase demand based on attributes, indicating which types of people (e.g., age group, gender, etc.) are most likely to make a purchase in a particular shop or category. Purchase attributes are analyzed as shown in Figure 50, based on POS data, credit card data, point data, cashless payment data, etc., implemented by online shop 1. Specifically, by analyzing the purchase data from online shop 1, if the desired attribute is age group, the number of purchasers in each age group is analyzed, such as 100 purchasers in their teens, 400 purchasers in their twenties, etc. The results are then created in Purchase Attribute Graph 325. Normalization is performed for readability, but it is not required.

[0160] Based on the number of purchasers, the number of visitors by age group is estimated. When estimating the number of visitors, data conversion is performed from empirical or measured values. For example, if it is generally assumed that α% of visitors actually make a purchase, the number of visitors to online shop 1 can be estimated by dividing the number of purchasers by α%. Similarly, if the number of purchasers for each genre is determined, the number of visitors for each genre can be estimated. α% is not a fixed value and should ideally be adjusted to reflect actual circumstances, such as environmental factors and transaction conditions. Furthermore, while the above explanation described estimating the number of visitors based on POS data, credit card data, point data, and payment data such as cashless payments, it is also possible to obtain the number of visitors using data analyzed by browser plugins or management tools. This could include, for example, analysis using website access analysis tools such as Google Analytics. Attributes such as hobbies and preferences can also be obtained in a similar manner. Attribute data obtained using such access analysis tools may be used together with attribute data obtained from POS data, etc. If obtaining one set of attribute data is difficult or highly uncertain, the other set of attribute data may be used instead. Purchase attributes may be divided into purchaser attributes, which summarize the number of people who purchased products at online shop 1, and visitor attributes, which summarize the number of visitors who visited online shop 1.

[0161] Furthermore, online shop 1 may lack sufficient purchase data if the number of actual buyers is small or if it has only recently implemented POS systems. In such cases, purchase attributes are calculated using the same method as sales attributes and used as estimates. Specifically, normalized basic attribute data for each product is read from the product data of products actually purchased at online shop 1 and aggregated. This can then be used as a general trend in purchase attributes. Alternatively, the number of visitors for each genre can be estimated as follows: Analyze the purchasers for each genre by age group using POS data, etc. Based on this analysis data, determine the number of purchasers for each age group within each genre. Based on this data, estimate the number of visitors for each age group within each genre by dividing the number of purchasers by α%, as described above. However, in this case, it is desirable to use a value based on experience or actual measurements for each genre for α%.

[0162] Next, we will explain how to increase shop sales based on purchase and sales attributes. The purchase attribute graph is created based on the number of purchasers. However, if the number of visitors is estimated based on the number of purchasers calculated from POS data, etc., the number of purchasers and the number of visitors are proportional before any adjustments are made, so the purchase attribute graph will have the same characteristics as the visitor number graph. In this case, the purchase attribute graph can be rephrased as the visitor number graph. Figure 51 shows an example where a threshold of K people is set for the purchase attribute representing the number of visitors. The value of K is, for example, 50,000 per month, and is a value that can be changed as appropriate according to the actual situation. For simplicity, Figure 51 shows only the purchase attribute for the 20s age group, and the purchase attribute for other age groups is omitted. Figure 51 shows an example where the number of visitors in their 20s exceeds the threshold of K people. In this case, it can be inferred that there is high purchase demand from users in their 20s. When the purchase attribute is divided into purchaser attribute and visitor attribute, the threshold of K people is set for each.

[0163] On the other hand, Figure 51 also shows sales attributes as a comparison for the same age group in their 20s. S% is set as the threshold for these sales attributes. One way to set the value of S is to take the average value of the values ​​in the normalization column for each attribute shown in Figure 49, and set it to β times that average value. The value of β is, for example, 1.5. Another way to set the value of S is to assume that the 20s age group has the highest peak value among all age groups, as shown in Figure 51, and set the threshold for sales attributes to, for example, S% of this peak value. The value of S is, for example, 60. This threshold for sales attributes and the method of setting it can be changed as appropriate to suit the actual situation. In the example in Figure 51, the sales attribute for the 20s age group exceeds the threshold of S%, so it can be determined that the sales attribute for the 20s age group is strong. That is, it can be determined that it is a shop that stocks many products for people in their 20s.

[0164] As shown in the example in Figure 51, when the number of visitors in their 20s exceeds the threshold of K people, and the sales attribute of those in their 20s exceeds the threshold of S%, then the trends in the characteristics of both sales and purchase attributes for this group of 20-somethings coincide, both exceeding the threshold. Therefore, continuing sales at online shop 1 as is will not cause any problems, as profits can be expected from sales to those in their 20s. However, given the large number of visitors in their 20s, it would be worthwhile to leverage this characteristic and consider selling products from other stores with fewer users in their 20s through reciprocal sales, mall development, or partnership sales. Furthermore, it can be suggested to add products with strong basic attributes to people in their 20s to the e-commerce site of online shop 1. This suggestion may be to add product data to the site, or it may be to actually suggest sourcing the products. When determining the basic attributes, it is desirable to judge whether the same attributes are present or not, or whether the same attributes have a strength that exceeds a predetermined threshold. In addition, it may be possible to prioritize suggesting the sourcing of similar products to past best-selling products that have the same attributes or exceed the threshold, or products intended to be used together.

[0165] By analyzing and evaluating the attributes of online shop 1, it is possible to procure products that are suitable for the shop's unique attributes. In this process, it may be suggested that best-selling products be procured or that products with high profit margins be procured. If the profit margin and sales amount can be estimated, it is also possible to calculate and display the increase in sales amount and profit amount for online shop 1. Multiple products may also be displayed as potential products for procurement. Furthermore, even if two websites have high demand from consumers in their 20s, a partnership may be proposed. In this case, if the products offered by each site differ, mutual sales can be used to enrich the product lineup and lead to increased sales. On the other hand, if the products offered by each site overlap, a list of retailers may be created. In this case, it is desirable to select niche product groups (for example, so-called long-tail products) and best-selling products to offer a balanced selection. It may also be proposed to create a new product category that differs from the categories offered by online shop 1.

[0166] Multiple potential partners may be proposed. Potential partner shops, product data to be added to the site, and potential products for procurement can be automatically detected. When detecting based on attributes, filtering and searching may be performed using multiple attributes, such as combinations of age group and gender, age group, gender, hobbies and preferences, number of people, number of products, sales revenue, etc. These attributes may be based on data obtained through calculations, data obtained from access analysis tools, or data entered by shops as described later. Furthermore, if the sales attributes of online shop 1 are shown in Figure 49 and the purchase attributes are shown in Figure 50, as can be seen from Figure 50, online shop 1's purchase attributes among customers in their 40s and 50s are weak. Therefore, it is possible to propose to online shop 1 that it partner with supplier shop 1, which is skilled at selling products to customers in their 40s and 50s, and have them sell the products. It is desirable to find a candidate supplier shop 1 on a site where the purchase attributes among customers in their 40s and 50s are above a certain threshold. Candidate supplier shops 1 can be detected automatically.

[0167] On the other hand, as can be seen from Figure 50, online shop 1 has high demand for products aimed at people in their 20s and 30s, so it is possible to sell products from other shops that are not good at selling to this age group as partner shop 1. In this case, a candidate partner shop 2 would be a site with weak purchasing attributes for products aimed at people in their 20s and 30s. It would be even more desirable if this site had strong sales attributes for people in their 20s and 30s, because it is likely to have a collection of products aimed at people in their 20s and 30s. Candidate partner shop 2 can be detected automatically. The attribute judgment can be made more finely, for example, by targeting women in their 20s and 30s. The graphs for sales attributes and purchase attributes can be created separately for men and women, and by age group. However, the candidates for provider shop 2 do not necessarily have to be limited to sites with weak purchasing attributes. Sites with strong purchasing attributes can also be designated as provider shop 2.

[0168] Furthermore, for online shop 1, which has high demand for products aimed at people in their 20s and 30s, it may be suggested that they actually stock products aimed at people in their 20s and 30s. Whether a product is aimed at people in their 20s and 30s can be determined by whether the basic attributes of the product (the 20-30 age range) exceed a predetermined threshold. In this case, multiple products with high profit margins or high purchase rates (bestsellers) may be suggested as product candidates, and the shop may be asked to stock the selected product. Other attributes (such as women) may also be taken into consideration when making this decision. Although not shown in the diagram, if the peak value of purchase attributes (or number of visitors) is consistently below the threshold of K people across all age groups, then it is desirable to have the products sold at Shop 1, which has good purchase attributes across all age groups, as this will lead to increased sales. On the other hand, if the lower limit of purchase attributes (or number of visitors) is always above the threshold of K people for all age groups, then the number of visitors is K or more for all age groups and the purchase attributes are good, so the supplier shop 1 can sell all of the products of the supplier shop 2. Furthermore, Figure 52 shows an example where stores F, G, and H are added as partner shops to store E, which has been converted into a mall. As shown in Figure 52, even if store E has widespread weaknesses in its sales attributes, these weaknesses can be compensated for by the outstanding characteristics of the sales attributes of the partner shops F, G, and H. Furthermore, Figure 53 shows an example of how the characteristics of shops and genres can be further enhanced through partnerships such as mutual sales. In Figure 53, the sales and purchase attributes of store I already have outstanding characteristics, but through the partnership with store J, these characteristics can be doubled, as shown by the dotted line.

[0169] Furthermore, candidates for supplier shop 1 and supplier shop 2 can be narrowed down and searched by specifying attributes such as the characteristics and themes of the partner shops that your store wishes to partner with, as shown in Figure 54, using the management tool. Similarly, it may be possible to narrow down and search by attributes for products that you wish to list on the site or stock, or for genres. In Figure 54, the "E-commerce site theme" 327 may be a selectable selection box or allow text input. Candidates for supplier shop 1 and supplier shop 2 are automatically filtered and displayed based on the theme selected by the shop. Examples of themes include direct from producer, regional, brand, specialty products, local sake, size-specific fashion, cash discounts, etc. The theme may be selected by the shop or by the operator.

[0170] Furthermore, as shown in the age group selection 329 of Figure 54, it may be possible to select the age group of the partner shop that the store wishes to collaborate with. The selected age groups may then be prioritized in order of preference. In this case, the number of candidate partner shop 1 and candidate provider shop 2 will be narrowed down based on the selected age groups. However, this age group may be selected separately for purchase attributes and sales attributes. Similarly, it is possible to specify gender (331), hobbies and preferences (335), industry (337), purpose (339), service (341), etc. Furthermore, in the visitor count setting (333), it is possible to specify the total number of visitors to the desired partner shop and the number of visitors by age group. It may also be possible to specify the number of visitors by genre. Although not shown in the diagram, it may also be possible to specify the number of products and sales figures for the desired partner shop. However, the selected data may not be used to narrow down candidates in this way, but rather to narrow down the overall shop data.

[0171] Furthermore, although Figure 54 explains how to specify the attributes required of a partner, such specifications may also be used to register information about one's own shop, such as its characteristics and themes, so that other shops can search for it. In cases where automatic calculation of attribute data is not successful, manually registered data may be used for searching. When attempting to partner with another shop through reciprocal sales, collaborative sales, or mall integration, you can specify the K value of purchase attributes or the S% of sales attributes as conditions for the partnership with the other party. For example, you might want the other shop to have fewer than 20,000 purchases per month for the same attribute 'a', and a sales attribute of 50% or more. Alternatively, you might not specify any conditions for purchase attributes, but want the sales attribute to be 60% or more for all attributes (e.g., age groups). When multiple candidate shops appear in the search results, you can further narrow down the candidates by another attribute 'b'. You can also calculate purchase and sales attributes for each genre and specify the K value of purchase attributes or the S% of sales attributes. You can also specify the percentage of best-selling products or high-profit margin products that you handle.

[0172] By summarizing purchase and sales attributes for each e-commerce site and evaluating them through comparisons, it becomes possible to visualize and clarify the strengths and weaknesses of each site in terms of purchase demand and sales. This makes it easy to determine whether the product lineup matches the purchase demand for the products. Furthermore, it becomes easy to narrow down the list of potential partner shops that meet the desired criteria. This allows businesses to leverage the strengths of their e-commerce sites to further enhance sales, and to address areas where there is a mismatch between product demand and product mix, thereby increasing sales. Mutual sales, partnership sales, and mall integration can be implemented without modification, making it easy to sell other stores' products in your own store, or to have other stores sell your products. Similarly, stopping and restarting the process is also easy. This process can be done on a shop-by-shop, genre-by-genre, or product-by-product basis. This allows shops to freely design and create the unique characteristics they desire. Furthermore, it is possible to conduct trial sales of individual products through partnerships, analyze the results, and then actually stock those products. This analysis can be performed accurately for each attribute. Consequently, this leads to a reduction in shop risk.

[0173] Furthermore, the attribute evaluations of hobbies and preferences analyzed using the aforementioned purchase and sales attributes can also be used in so-called affiliate advertising. In this case, affiliate advertisers can run effective advertisements by placing them on media that match the analysis results of purchase and sales attributes with the hobbies and preferences of their customers. Furthermore, by evaluating attributes such as whether the access is from overseas, the user's country of origin, number of accesses, hobbies and preferences, and age group, it can be used to enable foreigners to purchase products. This allows for the implementation of the aforementioned programs for foreign purchases and helps identify products that will appeal to overseas users. Furthermore, the aforementioned analysis and evaluation based on purchase and sales attributes can also be applied to participating stores in e-commerce malls. It can also be applied not only to goods but also to services. It can be applied not only to online shops but also to physical stores. Furthermore, the present invention can be modified in various ways as long as it does not deviate from the spirit of the invention, and it goes without saying that the present invention also applies to such modified versions. [Explanation of Symbols]

[0174] 1. Provider Shop 2. Supplier Shop 3. Personal computer (information terminal) 4. Provider shop server 5. Smartphone (information terminal) 6. Center Server 7. Provider shop server 9. Website of the supplier shop 10 Internet 11, 51, 71 calculation section 15, 55, 75 Communications Department 20 Product Data Collection and Analysis Department 21 Traveling Program 23 Product Data Analysis Program 25 User Support and Management Programs 30. Database on the central server 31 Dealer List Database 33 Source Shop Database 35 Supplier Shop Database 37. Provider-Provider Corresponding Database 39. Source Shop Product Database 41. Supplier Shop Product Database 43 Sales History Management Database 45 Individual Product Database 47. User Support and Management Database 57, 77 Management Department 59 Customer database of the provider's shop server 60. Database of the providing shop server 61. Provider Shop Sales History Management Database 63. Sales History Management Database for Partner Shops 65 Source Shop Product Database 79 Web page creation section 80 Database of the destination store 81 Customer database of the destination store 83 Database for managing the sales history of the source store 85 Database for managing the sales history of the destination store 87 Database of products in the destination store 89 Individual product database 100, 110, 120, 130, 140, 160, 170, 190, 260, 270, 300 Product detail pages 101 Purchase button 103, 115, 317 List of sales stores 113, 133 Store names of the source store 141, 161, 171, 261, 301 Product descriptions 143 Invoice request button 163, 173 Delivery button 165, 265, 307 Comment text 191 Order button 201, 203, 205 Management screen 207 Inquiry screen 210 Order screen 213 Increment button 217 Decrement button 219 Table number input field 240 Process drawing screen 245 Scroll bar 250 Pending case column 263, 285 Link button 271 "Add to cart" button 280 Existing web pages of the store 281, 291, 303 Search input field 283, 293, 305 Search button 290 Search page 309 Breadcrumb list 311 Serial number attached to the original text 313 Serial number attached to the translated text 315 Check box 319 Foreigner Purchase Button 321 Basic Attribute Graph 323 Sales Attribute Graph 325 Purchase Attribute Graph

Claims

[Claim 1] a shop server in which product data of a shop is stored and a web page of the product data is generated; A product data collection means for collecting the product data of the shop by at least one of providing and collecting the product data; a center server for storing the product data collected by the product data collection means; a code generating means for generating a source code for starting a predetermined process for the product data stored in the center server; embedding means for embedding the source code generated by the code generating means into a predetermined portion of the product data stored in the center server; a product data providing means for providing the product data in which the source code is embedded by the embedding means to the shop via the center server; a web page creation means for creating the web page by the shop server based on the product data provided by the product data providing means; The sales support system is characterized in that the predetermined process is performed in response to a user's request to start the predetermined process on the web page created by the web page creation means.

Images