JP2024007274A - Product information management system, product information management server, business operator terminal, consumer terminal, product information provision method, and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a mechanism that allows sellers to attract customers using products as a starting point in a simple way.

SOLUTION: A consumer terminal displays a product part having product information about a product and a button for selection, and transmits an information request to a product information management server when the button is selected. The product information management server manages store information about a store where the product can be purchased or consumed, receives the information request transmitted from the consumer terminal, and transmits the store information to the consumer terminal. The consumer terminal additionally displays the store information transmitted from the product information management server.

SELECTED DRAWING: Figure 1

COPYRIGHT: (C)2024,JPO&INPIT

Description

The present invention relates to a product information management system, a product information management server, a business terminal, a consumer terminal, a product information providing method, and a program.

As a document that discloses the background technology of this technical field, there is Japanese Patent Application Publication No. 2016-181196 (Patent Document 1). This bulletin states, ``When purchasing products that place emphasis on design (e.g., clothing, accessories, furniture, etc.) on websites such as e-commerce sites, users cannot see or touch the actual products. "Users will decide to purchase based only on the information that can be viewed on the website" (see paragraph 0017).
The bulletin also states, ``When viewing a product on a website, the things that influence a user's purchase decision are the shape and color of the product itself, the way the product image is reflected, and the description. ” (see paragraph 0018).

Japanese Patent Application Publication No. 2016-181196

The above-mentioned Patent Document 1 describes the sale of products through an EC site.
When a product seller develops their own e-commerce site, they must invest their own time and money to establish a customer attraction line on their own. This is not limited to e-commerce sites, but also applies to sellers who operate physical stores.
Therefore, the present invention provides a mechanism that allows sellers to attract customers from the product point of view in a simple manner.

In order to solve the above problems, for example, the configurations described in the claims are adopted.
The present application includes a plurality of means for solving the above problems, and one example is a product information management system in which a consumer terminal has product information about the product and product parts having selection buttons. and an information acquisition means that sends an information request to a product information management server when the button is selected, and the product information management server is configured to display a list of products that can be purchased or consumed. a management means for managing store information regarding a store; and an information providing means for receiving the information request transmitted from the consumer terminal and transmitting the store information to the consumer terminal; The display means of the terminal is characterized in that it additionally displays the store information transmitted from the product information management server.

According to the present invention, it is possible to provide a mechanism that allows sellers to attract customers from the product point of view in a simple manner.
Problems, configurations, and effects other than those described above will be made clear by the following description of the embodiments.

FIG. 1 shows an example image of three schemes that constitute an information management scheme. FIG. 2 is a diagram illustrating an example of the benefits of a cross-deployment scheme for branding. FIG. 3 is a diagram illustrating an example of the benefits of the cross-deployment scheme for issue handling information. FIG. 4 is a diagram illustrating an example of the benefits of the cross-deployment scheme for issue handling information. FIG. 5 is a diagram illustrating an example of the benefits of the value provision scheme according to the consumer's intention and history. FIG. 6 shows a configuration example of a product information management system 600. FIG. 7 shows an example of the hardware configuration of the product information management server 610. FIG. 8 shows an example of the hardware configuration of the consumer DD 620. FIG. 9 shows an example of the hardware configuration of the operator's DD 630. FIG. 10 shows an example of a table configuring the database of the product information management server 610. FIG. 11 shows an example of a posting table 1100. FIG. 12 shows an example of a posted brand table 1200. FIG. 13 shows an example of a post evaluation table 1300. FIG. 14 shows an example of a user purchase activity table 1400. FIG. 15 shows an example of a business sales table 1500. FIG. 16 shows an example of a business inventory table 1600. FIG. 17 shows an example of a brand feature table 1700. FIG. 18 shows an example of a preference model table 1800. FIG. 19 shows an example of a preference estimation table 1900. FIG. 20 shows an example of the brand master table 800. FIG. 21 shows an example of a product master table 2100. FIG. 22 shows an example of an area master table 2200. FIG. 23 shows an example of an element master table 2300. FIG. 24 shows an example of a media master table 2400. FIG. 25 shows an example of a business master table 2500. FIG. 26 shows an example of a brand parts setting table 2600. FIG. 27 shows an example of a brand name fluctuation table 2700. FIG. 28 shows an example of a name spelling variation table 2800. FIG. 29 shows an example of a brand information table 2900. FIG. 30 shows an example of a user purchase preference table 3000. FIG. 31 shows an example of a business product table 3100. FIG. 32 shows an example of a business reward program table 3200. FIG. 33 shows an example of a business subscription program table 3300. FIG. 34 shows an example of a delivery cost table 3400. FIG. 35 shows an example of a brand/element relationship table 3500. FIG. 36 shows an example of a brand/media relationship table 3600. FIG. 37 shows an example of a user/brand relationship table 3700. FIG. 38 shows an example of a user/company relationship table 3800. FIG. 39 shows an example of user authentication processing 3900. FIG. 40 shows an example of user ID acquisition processing 4000. FIG. 41 shows an example of business authentication processing 4100. FIG. 42 shows an example of business ID acquisition processing 4200. FIG. 43 shows an example of product/sales/inventory data cooperation processing 4300. FIG. 44 shows an example of parts installation processing 4400. FIG. 45 shows an example of parts installation processing 4500. FIG. 46 shows an example of registration processing 4600. FIG. 47 shows an example of registration processing 4700. FIG. 48 shows an example of sales data cooperation processing 4800. FIG. 49 shows an example of registration processing 4900. FIG. 50 shows an example of registration processing 5000. FIG. 51 shows an example of registration processing 5100. FIG. 52 shows an example of brand parts display processing 5200. FIG. 53 shows an example of map display processing 5300. FIG. 54 shows an example of EC list display processing 5400. FIG. 55 shows an example of product notification processing 5500. FIG. 56 shows an example of product notification processing 5600. FIG. 57 shows an example of customer service processing 5700. FIG. 58 shows an example of a preference model generation flow 5800. FIG. 59 shows an example of a subjective quantitative value correction flow 5900. FIG. 60 shows an example of a generation flow 6000 of the preference estimation table 1900. FIG. 61 shows an example of a reward program registration process 6100. FIG. 62 shows an example of reward program usage processing 6200. FIG. 63 shows an example of program sales processing 6300. FIG. 64 shows an example of product delivery processing 6400. FIG. 65 shows an example of a brand card 6500. FIG. 66 shows an example of a brand page 6600. FIG. 67 shows an example of a screen 6700 that is displayed when a brand card is installed in the business operator DA 622. FIG. 68 shows an example of a screen 6800 that is displayed when a brand page is incorporated into the business DA 622. FIG. 69 shows an example of display options for the face area. FIG. 70 shows an example of display options for the brand introduction area. FIG. 71 shows an example of a registration completion notification screen 7100. FIG. 72 shows an example of a brand card 7200 having a map and the like. FIG. 73 shows an example of a brand card 7300 having a store list. FIG. 74 shows an example of an EC screen 7400 on which a target product is decorated. FIG. 75 shows an example of an application screen 7500 that notifies the target product. FIG. 76 shows an example of an application screen 7600 that notifies the target product. FIG. 77 shows an example of information registration rights for brand parts. FIG. 78 shows an example of a business/brand relationship table 7700.

Examples will be described below with reference to the drawings.
1. Example This example is a cross-company information management scheme.
1-1. Applicable Market The applicable market for this information management scheme is an industry in which the number of products is enormous, the number of manufacturers of those products is also enormous, and the number of sellers, carriers, and recommenders of these products is also enormous. Specifically, the applicable market is the alcoholic beverage industry.

1-2. Terminology The main terms that appear in the explanation below are explained.
DD is an abbreviation for Digital Device. This DD is a general term for various devices that work with the Digital World, such as PCs, smartphones, HDs, projectors, and IoT devices.
DA is an abbreviation for Digital Application. This DA is a general term for various 2D (web sites, EC sites, smartphone apps), 3D, AR, and VR apps provided via each DD.

A manufacturer is a manufacturer or an importer/wholesaler (if they have exclusive sales rights to the target product in a specific region).
In the alcoholic beverage industry, a manufacturer is an alcoholic beverage manufacturer (a brewery, winery, brewery, distillery, etc.).
Sellers include manufacturers, importers/wholesalers, restaurants/retailers, and EC businesses.
Promoters include media/content providers, related organizations/associations, holders of related qualifications, and consumers (people posting on blogs and SNS).
Business operator is a general term for producers, sellers, and promoters.

In addition, "builders," "sellers," and "recommenders" also include those who have been entrusted with work related to this scheme by those who fall under these categories. It is interpreted as

1-3. Overview The information management scheme according to this embodiment is divided into three types: a cross-deployment scheme for brand branding, a cross-deployment scheme for brand handling information, and a value provision scheme according to consumers' intentions and history. FIG. 1 shows example images of these three schemes.

1-3-1. Cross-distribution scheme for brand branding First, the cross-distribution scheme for brand branding is a scheme in which product information prepared by manufacturers is disseminated to business DAs such as sellers and recommenders. In this scheme, sellers and recommenders install tags on their own DAs and display product information as brand parts on their own DAs without having to perform close coordination such as coordination with product masters.
Additionally, sellers and recommenders can also work closely together to place tags on their own DAs.

The brand parts displayed on the DA of the seller etc. include the following information.
(1) Basic information (manufacturer, category, area, etc.)
(2) Attribute information (characteristics, manufacturing method, raw materials, etc.)
(3) Image (image, video, VR space, etc.)
(4) PR content (by maker, by seller)
(5) Consumer reviews (6) Contest award history, media exposure history (7) Map of stores where you can drink/purchase (8) List of EC stores where you can purchase Of these, (2) to (8) are optional, and (5) Items (8) to (8) do not need to be registered by the manufacturer.

The means for realizing the above scheme are as follows.
(1) Means for sellers and recommenders to incorporate branded parts
Mainly by linking product/sales/inventory data, sellers install tags for reading parts in their own DA based on the vendor's unique product ID.
On the other hand, the recommender mainly checks the universal brand ID for each brand and installs a tag for reading parts in his or her DA based on the universal brand ID.
(2) Means for producers to register brand promotion information Producers enter brand promotion information in the registration form of this scheme.

Next, the benefits of the above scheme will be explained. FIG. 2 is a diagram illustrating an example of the benefits of the above scheme.

As shown in the figure, according to this scheme, manufacturers can create product introduction pages with a high degree of freedom, including design. In other words, creators can develop branding that includes not only text information but also design aspects such as faces (still images and videos) and layouts. The creator can then deploy the created pages and information to multiple seller sites as is.
In addition, sellers and the like do not need to prepare basic product information and can add original product introduction parts. Furthermore, sellers and the like can incorporate the page into their own EC, without disconnecting from users.

Additionally, although not shown in the figure, consumers can seamlessly obtain a variety of information about brands of interest.
Additionally, although not shown in the figure, this scheme is not a form in which a third party can incorporate information and functions developed by one specific company (API provider), but rather a number of businesses/consumers input information and functions. This information can be incorporated into their own DA by many businesses/consumers. To explain this format in more detail, rather than simply referencing information entered by many people, information entered by many people can be managed by linking it to the universal stock master. In an aggregated/structured form, many can be incorporated into their own DA.

1-3-2. Cross-distribution scheme for stock handling information The cross-distribution scheme for stock handling information is a scheme in which the stock handling information of sellers is distributed to business DAs such as recommenders. In this scheme, the recommender installs a tag on his/her DA and displays brand handling information as a brand part on his/her DA without performing close coordination such as linking product masters.
In addition, the recommender can also install a tag on his/her own DA through close cooperation.

The stock handling information displayed on the recommender's DA includes the following information.
(1) Map of restaurants and retail stores where you can buy the target brands (2) List of EC stores where you can buy the target brands

The means for realizing the above scheme are as follows.
(1) Means of incorporating branded parts by the recommender
The recommender mainly checks the universal brand ID for each brand and installs a tag for reading parts in his or her DA based on the universal brand ID.
(2) Means for the seller to register handling information Specifically, a means for the seller to directly register the stocks handled, a means for linking the seller's product/sales/inventory data, or a means for linking the sales data of the seller's suppliers. There is a way to do that.

Next, the benefits of the above scheme will be explained. 3 and 4 are diagrams illustrating examples of the benefits of the above scheme.

As shown in FIG. 3, the conventional customer attraction parts are transition destination fixed customer attraction parts. The guidance destinations are plural at most and fixed. As a result, there are cases in which consumers are unable to satisfy two desires: ``I want this product'' and ``I want to buy it here.'' When installing parts, the media will decide not only the products to be introduced, but also the transition destination. Also, if the media wants to set the transition destination by itself, it will have to bear the costs from the creation of the parts.

On the other hand, the customer attraction part of this scheme is a transition destination variable type customer attraction part. The destination of guidance is unlimited and variable. Therefore, consumers can select a DA that suits their area and preferences (it is also possible to have the DA narrowed down automatically). Media can install parts in a way that only satisfies the desire to "introduce this product" without specifying the transition destination. In addition, media can also specify a transition destination and place parts.

Furthermore, as shown in Figure 4, sellers can reduce the cost of attracting customers by participating in a mall, but the degree of freedom in design and functionality is low. If sellers develop their own e-commerce business, they will have a high degree of freedom in terms of design and functionality, but the cost of attracting customers will be extremely high if they use conventional parts to attract customers. On the other hand, if sellers use the customer-attracting parts (in other words, brand-name parts), they have a high degree of freedom in design and function, and the cost of attracting customers is low.

Furthermore, although not shown in the figure, sellers can attract consumers who are highly motivated to purchase the brands they handle through a number of recommendations. A recommender can call consumers to take action on recommended brands without being tied to a specific seller. Consumers can seamlessly find out where they can drink and buy the brand they are interested in.

1-3-3. Value provision scheme according to consumer's intentions and history In the value provision scheme according to consumer's intention and history, the server of this scheme centrally manages consumer preferences and provides added value based on these preferences. This is a scheme that allows sellers to provide services.

Services made available by Seller include the following services:
(1) Product notifications based on customer preferences (2) Customer service based on product characteristics accumulated through consumer evaluations (3) Reward program across sellers (4) Automatic product notification based on consumer preferences Selection, sales and delivery program

The means for realizing the above scheme are as follows.
(1) Means for sellers to incorporate additional functional parts By linking product/sales/inventory data, sellers install tags for reading parts in their own DA based on the company's unique product ID.
(2) Means for consumers to register their preferences Specifically, a means for consumers to press “I want to drink” on brand parts, a means for registering the evaluation of drinks with an app linked to this scheme, or a means for consumers to register their preferences by linking this scheme. There are ways to purchase products through EC.

Next, the benefits of the above scheme will be explained. FIG. 5 is a diagram illustrating an example of the benefits of the above scheme.

As shown in the figure, according to this scheme, the seller does not need to collect preferences from each consumer on his own. Sellers can also provide a better user experience based on the broader consumer preferences they collect.
In addition, consumers can enjoy appropriate UX (such as being reminded of desired products) through various DAs. Additionally, consumers only need to register their preferences in a single place, and the information disclosed to the DA is minimal.

Further, although not shown in the figure, sellers can improve the purchase rate by making appropriate presentations and proposals to first-time consumers. Furthermore, even when visiting a store for the first time, consumers will be able to identify products that match their intentions and preferences.

1-4. Specific Service Contents Next, specific service content provided by the above three schemes will be explained.
1-4-1. Cross-deployment scheme for stock branding The cross-deployment scheme for stock branding provides the following services.
(1) Stock information (basic information, attribute information)
This scheme provides a brand information registration form for sake brewers. Registered stock information is reflected on the "brand card" and "brand page."
(2) Branding branding (PR page)
This scheme provides alcohol-specific branding development services for alcoholic beverage manufacturers. Registered content can be developed into a variety of digital media.

(3) Face design (still images/videos)
This scheme provides a face design setting function for brand cards for sake brewing manufacturers. Sake manufacturers can register their favorite still images or videos as the "face of their brand."
(4) 360-degree product images This scheme provides 360-degree product image shooting and development services for sake brewers. Photographed images can be published on various digital media such as other companies' e-commerce sites.
This scheme also provides a service for restaurants to obtain alcohol labels necessary for creating menus.
This scheme also provides the ability to incorporate product images for e-commerce businesses that sell alcohol.

1-4-2. Cross-deployment scheme for stock handling information The cross-deployment scheme for stock handling information provides the following services.
(1) Expansion of product-based transition destinations This scheme provides a function on the "brand card" to display "stores where you can drink" and "stores where you can buy" the target brand on a map.
Along with this function, this scheme provides the ability for restaurants and liquor stores to register as ``stores where you can drink'' and ``stores where you can buy'' on the ``brand card.'' Additionally, this scheme provides a service for alcohol wholesalers that allows them to register wholesale locations as ``stores where you can drink'' and ``stores where you can buy'' on their ``brand card.''

This scheme also provides a function to display ``sites where you can purchase'' the target issue on the ``issue card''. Along with this function, this scheme provides EC businesses that sell alcohol with the ability to register as a ``purchasing site'' on the ``Brand Card.''

(2) Changing the transition destination according to the user's context This scheme provides a function in which the "purchasing site" in the "brand card" is optimized according to the viewer's area.
This scheme also provides a function that optimizes the ``stores where you can drink'', ``stores where you can buy'', and ``sites where you can buy'' on the ``brand card'' based on the preferences of the viewer.

1-4-3. Expanding the locations where brand parts are incorporated The brand branding cross-deployment scheme and the brand handling information cross-deployment scheme provide the following services.
(1) For sellers This scheme provides a “brand page” for e-commerce businesses that sell alcohol. E-commerce businesses can embed stock pages on their own e-commerce sites without having to prepare stock information on their own.
Along with this function, this scheme provides EC businesses that sell alcohol with a function that allows them to set the output of the map button and cart button on the brand page. Additionally, this scheme provides e-commerce businesses that sell alcohol with a function that allows them to register and limit the destination of the "purchasing site" on the brand page.

(2) For recommenders (appeal function is the same as for sellers)
This scheme provides "brand cards" for media businesses and bloggers. Media businesses etc. can incorporate brand cards into their own sites.
Along with this function, this scheme provides media businesses and bloggers with the ability to set the output of map buttons and cart buttons on brand cards. Additionally, this scheme provides media businesses and bloggers with the ability to register and limit the destination of the "purchase site" on the brand card.

1-4-4. Value provision scheme according to consumer's intentions and history A value provision scheme according to consumer's intention and history provides the following services.
(1) Product notifications based on customer preferences (1-1) For e-commerce sites This scheme is aimed at e-commerce businesses that sell alcohol by highlighting brands that e-commerce site visitors have registered as “want to drink.” Provides the ability to
Additionally, this scheme provides e-commerce businesses that sell alcohol with a function that highlights products recommended to e-commerce site visitors based on their performance as evaluated by those visitors.

(1-2) For restaurants and retail stores This scheme provides a service for restaurants and liquor stores that notifies customers of the brands the store handles that they have registered as “want to drink.” provide.
This scheme also provides a service for restaurants and liquor stores that notifies customers of recommended brands based on customer evaluations from among the brands the store handles.

(2) Customer service based on product characteristics accumulated through consumer evaluations This scheme, for e-commerce businesses that sell alcohol, can incorporate brand recommendation AI that recommends products according to consumer needs and requests. provide services;
This scheme also provides a service for alcoholic beverage manufacturers and alcoholic beverage wholesalers that allows them to incorporate a brand recommendation AI service into their own apps for sales representatives.

(3) Rewards program that cuts across sellers This scheme provides a stamp card function for sake brewers that is independent of the place of purchase. Sake manufacturers will be able to develop promotional plans for consumers regardless of where they purchase the product.
This scheme also provides local governments with a stamp card function for alcohol that does not depend on the place of purchase. Local governments will be able to develop promotional plans for local brands regardless of where they are purchased from.

1-5. Configuration of Example FIG. 6 shows a configuration example of a product information management system 600.
The product information management system 600 includes a product information management server 610, a consumer DD 620, a business DD 630, and a business server 640.

The product information management server 610 that constitutes this system is a server that manages information regarding alcoholic beverages.
The consumer DD 620 is a terminal used by a consumer (also referred to as a "user" in the following description) who drinks alcoholic beverages. This consumer DD620 includes a scheme DA621 and a business operator DA622. A part of this scheme DA621 is incorporated into operator DA622.

The business operator DD630 is a terminal used by a business operator that handles alcoholic beverages. The business DDs 630 include a plurality of business DDs 630, each used by a different manufacturer, and a plurality of business DDs 630, each used by a different seller or recommender. Each business operator DD630 is provided with this scheme DA631.
The business server 640 is a server managed by a business that handles alcoholic beverages.

The product information management server 610 is interconnected with the consumer DD 620, the business DD 630, and the business server 640 via a wired or wireless network, and can send and receive information via this network.
The business server 640 is interconnected with the consumer DD 620 and the business DD 630 via a wired or wireless network, and can send and receive information via this network.
Although only one consumer DD 620, one business DD 630, and one business server 640 are shown in FIG. 6, a plurality of each may be included in the product information management system 600.

Each component of the product information management system 600 may be a mobile terminal such as a smartphone, a tablet, a mobile phone, or a personal digital assistant (PDA), or a wearable terminal such as a glasses-type, wristwatch-type, or clothing-type device. But that's fine. Further, each component device may be a stationary or portable computer, or a server placed on a cloud or a network. Moreover, each component device may be a VR (Virtual Reality) terminal, an AR (Augmented Reality) terminal, or an MR (Mixed Reality) terminal in terms of functions. Alternatively, each component device may be a combination of these multiple terminals. For example, a combination of one smartphone and one wearable terminal can logically function as one terminal. Moreover, each component device may be an information processing terminal other than these.

Each component consists of a processor that runs an operating system, applications, programs, etc., a main storage device such as RAM (Random Access Memory), and auxiliary devices such as IC cards, hard disk drives, SSDs (Solid State Drives), and flash memory. Storage devices, communication control units such as network cards, wireless communication modules, and mobile communication modules; input devices such as touch panels, keyboards, mice, voice input, and input based on motion detection using camera units; monitors and displays, etc. and an output device. Note that the output device may be a device or terminal that transmits information to be output to an external monitor, display, projector, printer, device, or the like.

The main storage device stores various programs, applications, etc. (modules), and when a processor executes these programs and applications, each functional element of the overall system is realized. Note that each of these modules may be implemented in hardware by integrating them or the like. Further, each module may be an independent program or application, or may be implemented as a part of a subprogram or function within one integrated program or application.

In this specification, each module is described as a subject (subject) that performs processing, but in reality, a processor that processes various programs, applications, etc. (modules) executes processing.

Various databases (DB) are stored in the auxiliary storage device. A “database” is a functional element (storage unit) that stores a data set so as to be able to respond to arbitrary data operations (eg, extraction, addition, deletion, overwriting, etc.) from a processor or an external computer. The database implementation method is not limited, and may be, for example, a database management system, spreadsheet software, or a text file such as XML or JSON.

1-5-1. Product information management server 610
FIG. 7 shows an example of the hardware configuration of the product information management server 610.
The product information management server 610 is configured with a server placed on a cloud, for example.
The main storage device 701 of this server includes an authentication module 711, a data linkage module 712, a built-in tag management module 713, a registration information management module 714, an intention/history management module 715, a brand parts information provision module 716, and a map information provision module. 717, EC information provision module 718, product information provision module 719, brand suggestion module 720, reward program management module 721, reward management module 722
Program management module 723, product selection module 724, posting management module 725, evaluation management module 726, model generation module 727, correction module 728
Programs such as a preference estimation module 729 are stored. Each functional element of the product information management server 610 is realized by the processor 703 executing these programs.
Each module will be explained below.

The authentication module 711 performs authentication processing for the user of the consumer DD 620 or the operator using the operator DD 730.

The data linkage module 712 executes linkage processing of product/sales/inventory data with the business server 640 or the business DD 630.
Through this cooperation process, the module manages store information regarding stores where products transmitted from the business server 640 or the like can be purchased or consumed. Specifically, this module manages product information regarding products, product handling information of stores where products can be purchased or consumed, and store information regarding stores. The managed product handling information includes store product inventory information.

Note that the product handling information is registered or updated by any of the following methods.
(1) Manually register each product via the business operator DD 630 used by the store.
(2) Any of the product master, sales data, and inventory data linked with the store is linked with the product information management server 610.
(3) Link sales data of businesses from which the store purchases products with the product information management server 610.

The built-in tag management module 713 manages button setting information for product parts that is set in advance by the product seller or recommender. The product parts referred to here more specifically refer to branded parts. The brand parts include a brand card in card format and a brand page in page format.

The registration information management module 714 manages product-related information sent from the business DD 630. The managed product-related information includes brand promotion information registered by the manufacturer and handled brand information registered by the seller.

The intention/history management module 715 centrally manages product information transmitted from the consumer DD 620. The managed product information is information on brands that the user of the consumer DD 620 wants to drink.
The module also manages performance information sent from the consumer DD620. The managed track record information is information on brands that the user of the consumer DD 620 drinks or favorite brands. This module manages performance information in association with reward program information across stores where products were purchased or consumed.

The brand parts information providing module 716 transmits information regarding product parts to the consumer DD620.
The module transmits product-related information to the consumer DD 620 when a screen incorporating a predetermined code is displayed on the consumer DD 620. Here, the predetermined code is a code for displaying product parts.

The map information providing module 717 receives the information request sent from the consumer DD620 and sends the store information of the physical store that handles the target product to the consumer DD620.
At that time, the module can transmit store information of stores that have the target product in stock. Further, the module is capable of transmitting store information of a store according to the current location of the user of consumer DD620. Further, the module is capable of transmitting store information according to the user preferences of the consumer DD620.

The EC information providing module 718 receives the information request sent from the consumer DD620 and sends the store information of the EC store that handles the target product to the consumer DD620.
At that time, the module can transmit store information of stores that have the target product in stock. Further, the module is capable of transmitting store information of a store according to the current location of the user of consumer DD620. Further, the module is capable of transmitting store information according to the user preferences of the consumer DD620.

The product information providing module 719 transmits product information to the consumer DD620 when the user of the consumer DD620 visits or accesses the store.
Here, the case where the user of the consumer DD 620 visits or accesses a store refers specifically to the case where the user accesses an online store and displays a screen on which a predetermined decoration module is installed by the seller of the product. be. Alternatively, this case is a case where the user visits a physical store and the store sells the target product.
The product information sent to the consumer DD620 by the module is information on products that the user has purchased or consumed, or that the user desires to purchase or consume, or matches the user's preferences based on the information on the products. This is the estimated product information.

The brand proposal module 720 receives the product proposal request sent from the consumer DD620, extracts product information based on the extraction conditions specified by the user, and sends it to the consumer DD620.

The reward program management module 721 manages reward program information transmitted from the operator DD 630 or other communication terminals. The other communication terminals mentioned here are, for example, communication terminals used by local government officials.

The reward management module 722 executes processing to consume accumulated rewards.

The program management module 723 registers information regarding the subscription program received from the business operator DD 630 into the business subscription program table 3300.

Product selection module 724 selects products to be delivered to the user of consumer DD 620 according to the subscription program.

Post management module 725 stores information regarding posts received from consumer DD 620 in transaction DB 741 .

The evaluation management module 726 manages evaluation values that relatively represent evaluations of a plurality of products. Specifically, this module manages a comprehensive evaluation value and element evaluation values regarding a plurality of evaluation axes.

The model generation module 727 generates a preference model based on the comprehensive evaluation value accumulated in the posted brand table 1200 and the applied value stored in the brand feature table 1700.

The correction module 728 calculates the applied value based on the stored values stored in the brand feature table 1700.

The preference estimation module 729 inputs the applied values stored in the brand feature table 1700 into the preference model to estimate the overall evaluation value of each product.

Next, the auxiliary storage device 702 of the product information management server 610 will be explained.
The auxiliary storage device 702 includes databases such as a transaction DB 741, an analysis data DB 742, a master DB 743, a setting DB 744, an element DB 745, and a relationship DB 746. The tables constituting each DB will be described later.

1-5-2. Consumer DD620
FIG. 8 shows an example of the hardware configuration of the consumer DD 620.
The consumer DD 620 is configured with a terminal such as a smartphone, tablet, notebook PC, or desktop PC.
The main storage device 801 of this DD includes an authentication module 811, an intention/history registration module 812, a brand parts display module 813, a map display module 814, an EC list display module 815, a product notification module 816, a proposed brand notification module 817, and a reward module. Programs such as a usage module 818, a posting module 819, an evaluation transmission module 820, and a display module 821 are stored. Each functional element of the consumer DD 620 is realized by the processor 803 executing these programs.
Each module will be explained below.

The authentication module 811 performs user authentication processing of the consumer DD 620.

The intention/history registration module 812 transmits product information of products that the user has purchased or consumed, or that the user desires to purchase or consume, to the product information management server 610.
Further, when the user purchases or consumes a product, the module transmits performance information of the purchase or consumption to the product information management server 610.

The brand parts display module 813 acquires product-related information from the product information management server 610 and displays product parts when displaying a screen in which a code is arbitrarily incorporated by a seller or a recommender. The displayed product parts include the obtained product-related information and selection buttons.
The selection buttons include a first button for displaying store information regarding the physical store, a second button for displaying store information regarding the online store, and a third button for displaying detailed product information. It will be done. When the third button is selected by the user, the module displays the product part whose display area has been expanded to include more detailed information about the product.
The buttons displayed on the product parts are selected in advance by the seller or the recommender and determined by button setting information transmitted from the product information management server 610.

The map display module 814 sends an information request to the product information management server 610 when a map button for a product part is selected by the user. The module displays store information of the store sent from the product information management server 610 in response to the information request on the map.

The EC list display module 815 sends an information request to the product information management server 610 when a cart button for a product part is selected by the user. The module displays store information of stores sent from the product information management server 610 in a list format in response to the information request.

When a user visits or accesses a store, the product notification module 816 requests and obtains product information from the product information management server 610, and notifies the user.
Here, the case where the user visits or accesses a store specifically refers to the case where the user accesses an online store and displays a screen on which a predetermined decoration module is installed by the seller of the product. Alternatively, this case is a case where the user visits a physical store and the store sells the target product.

The product information acquired by the module includes information on products that the user has purchased or consumed, or that the user desires to purchase or consume, or products that are estimated to match the user's preferences based on the information on the product. It is information.
The store visited or accessed by the user is one of a plurality of stores operated by different sellers.

The proposed brand notification module 817 sends a proposal request to the product information management server 610 using customer service parts. The module displays the product information sent from the product information management server 610 in response to the proposal request.
The customer service parts described above are incorporated into the product sales screen and are used when the screen is displayed on the consumer DD 620. Alternatively, the customer service part is incorporated into an application and used when the application is executed on the consumer DD 620.

The reward usage module 818 executes processing for using accumulated rewards.

The posting module 819 generates product posting information according to the user's input operation, and transmits it to the product information management server 610.

The evaluation transmission module 820 transmits the evaluation value of the product input by the user to the product information management server 610.

The display module 821 displays various information. For example, the module displays a product sales screen in which customer service parts are installed by the product seller.

Next, the auxiliary storage device 802 of the consumer DD 620 will be explained.
Auxiliary storage device 802 stores consumer DD data 831. This consumer DD data 831 is, for example, various data received from the product information management server 610.

1-5-3. Operator DD630
FIG. 9 shows an example of the hardware configuration of the operator's DD 630.
The business operator DD 630 is composed of terminals such as smartphones, tablets, notebook PCs, and desktop PCs, for example.
The main storage device 901 of this DD stores programs such as an authentication module 911, a built-in tag setting module 912, an information registration module 913, a code display module 914, a reward program registration module 915, and a program registration module 916. Each functional element of the operator DD 630 is realized by the processor 903 executing these programs.
Each module will be explained below.

The authentication module 911 executes authentication processing of a business operator using the business DD 630.

The embedded tag setting module 912 makes available to a seller or recommender a code for incorporating product-related information into any consumer viewing screen.

The information registration module 913 displays a registration form for the manufacturer to input product information regarding the product, and transmits the product-related information input in the registration form to the product information management server 610. The product-related information to be transmitted can include images related to the product (for example, background images of product parts).
The module also transmits product-related information regarding the product input by the seller or recommender to the product information management server 610.
The module also transmits store information input by the manufacturer, seller, or recommender to the product information management server 610. Note that this module transmits the store information input by the recommender when the recommender incorporates product parts into his/her own medium. Note that the recommender here includes any business that produces and provides screens that incorporate product parts.

The code display module 914 displays a pop-up advertisement containing a QR code (registered trademark).

The reward program registration module 915 displays a registration form for the manufacturer or recommender to input reward program information, and transmits the reward program information input in the registration form to the product information management server 610.

The program registration module 916 registers the subscription program in the product information management server 610.

Next, the auxiliary storage device 902 of the business operator DD 630 will be explained.
Auxiliary storage device 902 stores provider DD data 921. This business DD data 921 is, for example, various data sent to the product information management server 610.

1-5-4. Database FIG. 10 shows an example of tables that constitute the database of the product information management server 610.
Each table will be explained below.

FIG. 11 shows an example of a posting table 1100.
Post table 1100 stores posted information received from consumer DD 620. The table has fields such as a post ID 1101, a user ID 1102, a post type 1103, the number of stocks 1104, and a title 1105. Among these fields, the post type 1103 stores a value indicating the selection criteria for the entry target item at the time of posting. The number of stocks 1104 stores a value indicating whether the posting target is a single stock or multiple stocks.

FIG. 12 shows an example of a posted brand table 1200.
Posted brand table 1200 stores comprehensive evaluation values for brands received from consumer DD 620. The table has fields such as a post ID 1201, a stock number 1202, a stock ID 1203, a comprehensive evaluation (good or bad) 1204, a comprehensive evaluation (like or dislike) 1205, and a comment 1206. Of these fields, the value stored in the stock number 1202 is used as a key between the posted stock table 1200 and the posted evaluation table 1300, considering that the target stock may be changed during post editing. be done. Furthermore, the values stored in the comprehensive evaluation (good or bad) 1204 and the values stored in the comprehensive evaluation (like or dislike) 1205 may be used selectively.

Note that there are, for example, the following methods for linking the brand number and brand ID.
(1) The user of the consumer DD 620 specifies the target brand for each number.
(2) The product information management server 610 analyzes the images uploaded for each number from the consumer DD 620 and identifies the target brand.
(3) The product information management server 610 analyzes the image uploaded from the consumer DD 620, identifies the target brands, and links them sequentially from the left to No. 1, No. 2, and so on.

FIG. 13 shows an example of a post evaluation table 1300.
Posted evaluation table 1300 stores element evaluation values for brands received from consumer DD 620. The table has fields such as a post ID 1301, a brand number 1302, an element ID 1303, and an element evaluation 1304.

FIG. 14 shows an example of a user purchase activity table 1400.
The user purchase activity table 1400 stores the history of activities of the user of the consumer DD 620 with respect to the business operator. The table has fields such as user ID 1401, business ID 1402, action 1403, action location 1404, display inventory 1405, display evaluation 1406, display distance 1407, display price 1408, display CO ₂ 1409, and display location 1410. Note that "displayed" in these fields means that it is displayed as a store where you can drink, a store where you can buy, or an EC store where you can buy.

FIG. 15 shows an example of a business sales table 1500.
The business sales table 1500 stores the history of product sales between businesses. The table includes business ID 1501, category 1502, manufacturer 1503, product ID 1504, product name 1505, buyer 1506, buyer type 1507, buyer phone number 1508, buyer address 1509, buyer business ID 1510, quantity 1511, price 1512, order date and time. 1513, delivery date and time 1514, registration date and time 1515, and other fields. Among these fields, the value of registration date and time 1515 indicates the date and time when the record was registered.

FIG. 16 shows an example of a business inventory table 1600.
The company inventory table 1600 stores the product inventory of the company. The table has fields such as business ID 1601, category 1602, manufacturer 1603, product ID 1604, product name 1605, and inventory 1606.

FIG. 17 shows an example of a brand feature table 1700.
The brand feature table 1700 stores information related to product characteristics stored in the brand master table 2000 and information related to element evaluation obtained by analyzing the information in the posted evaluation table 1300. The table has fields such as brand ID 1701, type A 1702, type B 1703, element ID 1704, stored value 1705, average value 1706, standard deviation 1707, and applied value 1708. Among these fields, type A 1702 stores a value indicating whether the product characteristic value is a subjective value or an objective value. Type B 1703 stores a value indicating whether the product characteristic value is a quantitative value or a qualitative value. The stored value 1705 stores a value set in advance for each product characteristic. In particular, subjective quantitative values are set by the manufacturer or business operator of the brand.

In the applied value 1708, a value converted to dummy data (1) is stored for a qualitative value, and the value of the stored value 1705 is stored as is for an objective quantitative value. On the other hand, regarding the subjective quantitative value, the applied value 1708 stores the value of the stored value 1705 or the value obtained by correcting the value of the stored value 1705 with the value of the average value 1706 and the value of the standard deviation 1707.

FIG. 18 shows an example of a preference model table 1800.
The preference model table 1800 stores a preference model obtained by performing multiple regression analysis on the information in the posted brand table 1200 and the brand feature table 1700. The table has fields such as user ID 1801, category ID 1802, element number 1803, element ID 1804, partial regression coefficient 1805, standard partial regression coefficient 1806, and intercept 1807. Among these fields, the value stored in the standard partial regression coefficient 1806 is a value representing the degree of influence that the product characteristics have on the user's preference.

FIG. 19 shows an example of a preference estimation table 1900.
The preference estimation table 1900 stores the overall evaluation value of each brand estimated using the preference model. The table has fields of user ID 1901, category ID 1902, brand ID 1903, explanatory variable 1904, and objective variable 1905. Among these fields, the explanatory variable 1904 is divided into multiple fields such as element "1" 1906, element "2" 1907, element "3" 1908, and so on. In the example shown in FIG. 19, among these fields, element "1" stores a qualitative value (dummy variable), element "2" 1907 stores an objective quantitative value, and element "3" 1908 stores a qualitative value (dummy variable). stores subjective quantitative values.

The objective variable 1905 is divided into an actual value 1909 and an estimated value 1910. Among these, the actual value 1909 stores the overall evaluation value of the posted brand table 1200, and the estimated value 1910 stores the overall evaluation value estimated using the preference model.

FIG. 20 shows an example of a brand master table 2000.
The brand master table 2000 stores information regarding brands of alcoholic beverages. The table has fields such as parent ID 2001, brand ID 2002, name 2003, category ID 2004, area ID 2005, and maker ID 2006. In addition, in FIG. 20, for convenience of explanation, the brand name is assigned to the brand ID 2002, so an example value of the name 2003 is omitted.

FIG. 21 shows an example of a product master table 2100.
The product master table 2100 stores information regarding alcoholic beverage products. The table has fields such as brand ID 2101, product ID 2102, name 2103, type 2104, container 2105, and quantity 2106. In addition, in FIG. 21, for convenience of explanation, the product name is assigned to the product ID 2102, and therefore the example value of the name 2103 is omitted.

FIG. 22 shows an example of an area master table 2200.
The area master table 2200 stores the hierarchical relationship of administrative divisions. The table has fields such as a parent ID 2201, an area ID 2202, and a name 2203. Note that in FIG. 22, for convenience of explanation, the area name is assigned to the area ID 2202, and therefore the example value of the name 2203 is omitted.

FIG. 23 shows an example of an element master table 2300.
Element master table 2300 stores information regarding product characteristics. The table has fields such as parent ID 2301, element ID 2302, name 2303, and type 2304. Note that in FIG. 23, for convenience of explanation, the element name is assigned to the element ID 2302, and therefore the value of the name 2303 is omitted.

FIG. 24 shows an example of a media master table 2400.
The media master table 2400 stores media information regarding alcoholic beverages. The table has fields such as parent ID 2401, media ID 2402, name 2403, and type 2404. Note that in FIG. 24, for convenience of explanation, the media name is assigned to the media ID 2402, so an example value of the name 2403 is omitted.

FIG. 25 shows an example of a business master table 2500.
Business master table 2500 stores information regarding businesses. The table includes parent ID 2501, business ID 2502, name 2503, type 2504, subtype 2505, presence of EC 2506, physical store 2507, delivery function 2508, telephone number 2509, address 2510, area ID 2511, evaluation 2512, access code 2513, It has fields such as EC URL 2514 and reservation URL 2515.

In addition, in FIG. 25, for convenience of explanation, the business name is assigned to the business ID 2502, and therefore the example value of the name 2503 is omitted.
The "$product_id" portion of the EC URL and reservation URL illustrated in FIG. 25 is replaced with an individual product ID when the URL is used.
The reservation URL "seat-reserve" represents a URL for seat reservation, and "product-reserve" represents a URL for product reservation.

FIG. 26 shows an example of a brand parts setting table 2600.
The brand parts setting table 2600 stores brand part setting information (particularly, brand part setting information that a business operator incorporates into his/her DA). The table has fields such as a business ID 2601, a domain 2602, a map button 2603, a cart button 2604, and a cart URL 2605. Among these fields, the value of domain 2602 indicates the installation domain of brand parts. The value of the map button 2603 indicates whether the map button needs to be displayed. The value of the cart button 2604 indicates whether the cart button needs to be displayed. In the cart URL 2605, when the cart button transition destination is limited to one, that URL is registered.

FIG. 27 shows an example of a brand name fluctuation table 2700.
The brand name variation table 2700 is a table for unifying the name variation of brand IDs and product IDs. The table has fields such as an input name 2701, a brand ID 2702, and a product ID 2703. Note that among these fields, the product ID 2703 is arbitrary. This field is necessary if it is necessary to display the stores that handle each product when the "store where you can buy/EC" button for a specific brand is pressed, and is unnecessary if there is no need to divide the information by product.

FIG. 28 shows an example of a name spelling variation table 2800.
The name spelling variation table 2800 is a table for unifying spelling variations of terms related to alcoholic beverages. The table has fields such as an input name 2801, a target 2802, and a target ID 2803.

FIG. 29 shows an example of a brand information table 2900.
The brand information table 2900 stores information regarding the brand image, PR content, and face pattern for each business operator. The table has fields such as brand ID 2901, business ID 2902, type 2903, and information content 2904. Note that the information content 2904 may store values such as "product_or_label" and "text" instead of "background" shown in FIG. 29.

FIG. 30 shows an example of a user purchase preference table 3000.
The user purchase preference table 3000 stores information regarding the purchase preferences of the user of the consumer DD 620. The table has fields such as a user ID 3001, a target 3002, a first priority 3003, a second priority 3004, a third priority 3005, a _CO2 tolerance range 3006, and a price tolerance range 3007. Among these fields, the values stored in the priority field are as follows.

(1) Inventory Priority is given to stores with a high possibility of acquiring the target brand (2) History Priority is given to stores that have been used frequently within a specified period (3) Evaluation Priority is given to stores with a high reputation from many users (4) Type Predetermined period Priority is given to business formats that are frequently used (Izakaya, Yakiniku, official shops, etc.) (5) Price Priority is given to stores with low sales prices for target brands (6) _{CO2 CO2} emitted during delivery after purchase (theoretical value) ) is given priority (Basically only for EC)
(7) Location Priority is given to stores closest to the current location (basically only physical stores)

The priority value may be determined through analysis of the user purchase activity table 1400, or may be explicitly set by the user on the settings screen.

FIG. 31 shows an example of a business product table 3100.
The business product table 3100 stores information regarding products handled by businesses. The table includes business ID 3101, category 3102, manufacturer 3103, product ID 3104, product name 3105, price 3106, product name (after formatting) 3107, brand ID 3108, product ID 3109, inventory 3110, inventory level 3111, inventory estimation accuracy 3112, It has fields such as sales (predicted value) 3113, inventory (predicted value) 3114, EC URL 3115, registration date and time 3116, and update date and time 3117.

Note that among these fields, the category 3102, manufacturer 3103, product ID 3104, product name 3105, and price 3106 store values received from the business operator. In particular, the product ID 3104 is a product ID unique to the business operator.
Product ID 3109 is arbitrary. This field is necessary if it is necessary to display the stores that handle each product when the "store where you can buy/EC" button for a specific brand is pressed, and is unnecessary if there is no need to divide the information by product.

The values stored in the brand ID 3108 and the product ID 3109 are universal (common) IDs assigned by the product information management server 610.
The value of EC URL 3115 is applied with priority over the value of EC URL 2514 of operator master table 2500.
The value of the registration date and time 3116 indicates the date and time when the record was registered, and the value of the update date and time 3117 indicates the date and time when the record was updated.

FIG. 32 shows an example of a business reward program table 3200.
The business reward program table 3200 stores information regarding reward programs of businesses and the like. Note that the reward program here refers to an incentive system provided by a business operator to good customers who frequently use a service within a certain period of time. Customers can receive benefits and rewards based on the points they earn and their rank.

The table has fields such as a business ID 3201, a program ID 3202, a target 3203, a target ID 3204, a condition 3205, a reward 3206, a website 3207, a name 3208, and a description 3209.

FIG. 33 shows an example of a business subscription program table 3300.
The business subscription program table 3300 stores information regarding subscription programs provided by businesses. The table has fields such as a business ID 3301, a program ID 3302, a budget 3303, a title 3304, and a description 3305.

FIG. 34 shows an example of a delivery cost table 3400.
The delivery cost table 3400 stores information regarding the delivery of products by businesses. The table includes business ID 3401, area ID 3402, final reception time 3403, shipping days 3404, date and time until arrival 3405, delivery cost 3406, CO ₂ at the time of delivery 3407 (theoretical value), storage days 3408, and CO ₂ emitted during storage 3409. , tax rate 3410, and the like.
The values in this table are registered by each business operator.

FIG. 35 shows an example of a brand/element relationship table 3500.
The brand/element relationship table 3500 stores product characteristics for each brand. The table has fields such as brand ID 3501, element ID 3502, element type 3503, and value 3504.

FIG. 36 shows an example of a brand/media relationship table 3600.
The brand/media relationship table 3600 stores media information for each brand. The table has fields such as a brand ID 3601, a media ID 3602, a media type 3603, a section 3604, and a title 3605.

FIG. 37 shows an example of a user/brand relationship table 3700.
The user/brand relationship table 3700 stores information regarding brand preferences for each user of the consumer DD 620. The table has fields such as user ID 3701, brand ID 3702, label 3703, trigger 3704, basis 3705, registration origin business 3706, registration origin information 3707, number of purchases 3708, purchase amount 3709, registration date and time 3710, and the like. Among these fields, the value of registration date and time 3710 indicates the date and time when the record was registered.

FIG. 38 shows an example of a user/company relationship table 3800.
The user/business relationship table 3800 stores information regarding reward exchange for each user of the consumer DD 620. The table includes user ID 3801, user key 3802, business ID 3803, program ID 3804, number of posts (exchanged) 3805, number of purchased books (exchanged) 3806, purchase amount (exchanged) 3807, number of posts (not exchanged) 3808, It has fields such as number of purchased books (not exchanged) 3809, purchase amount (not exchanged) 3810, total number of posts 3811, total number of purchased books 3812, total purchase amount 3813, exchange date and time 3814, registration date and time 3815, and update date and time 3816.

Among these fields, the value of user key 3802 is a user key managed by the operator.
“Exchange” in these fields means exchanging purchase results for rewards.
The value of registration date and time 3815 indicates the date and time when the record was registered, and the value of update date and time 3816 indicates the calculation date and time of the actual value.

Note that in the tables shown in FIGS. 11 to 38 described above, names are stored in the ID field to make the explanation easier to understand. However, in reality, an alphanumeric code is stored in the field, and the name associated with the alphanumeric code is managed separately.

1-6. Operation of Example 1-6-1. User Authentication Processing FIG. 39 shows an example of user authentication processing 3900. The process shown in the figure is executed only once in a certain period of time.
In this process, the user of the consumer DD 620 makes an authentication request (step 3901). Specifically, the user presses a login button, for example. Upon receiving this operation, the authentication module 811 of the consumer DD 620 outputs an authentication form (step 3902). The user inputs authentication information such as an e-mail address and password into this authentication form (step 3903).

The input authentication information is sent to the authentication server, and authentication is performed at the authentication server (step 3904). If this authentication fails, the user re-enters the authentication information. On the other hand, if this authentication is successful, the authentication module 811 will be in a state where the session CD (code) can be obtained for a certain period thereafter (step 3905).
The above is the explanation of the user authentication process 3900.

1-6-2. User ID Acquisition Processing FIG. 40 shows an example of user ID acquisition processing 4000. The process shown in the figure is executed as necessary after user authentication.
In this process, the user of the consumer DD 620 makes some request or input (step 4001). In response to this operation, the consumer DD 620 sends the request/input along with the session CD to the product information management server 610 (step 4002).

Upon receiving this request/input, the authentication module 711 of the product information management server 610 transmits the session CD to the authentication server and requests a user ID (step 4003). The authentication server verifies the session CD (step 4004), and if the session CD is valid, transmits the corresponding user ID to the product information management server 610. By acquiring this user ID, the product information management server 610 can acquire the attribute information of the user (step 4005). After acquiring the user ID, the product information management server 610 executes processing according to the above request/input (step 4006).
The above is the explanation of the user ID acquisition process 4000.

1-6-3. Business Authentication Processing FIG. 41 shows an example of business authentication processing 4100. The process shown in the figure is executed only once in a certain period of time.
In this process, the business operator using the business DD 630 makes an authentication request (step 4101). Specifically, the business operator presses a login button, for example. Upon receiving this operation, the authentication module 911 of the business operator DD 630 outputs an authentication form (step 4102). The business operator enters authentication information such as an e-mail address and password into this authentication form (step 4103).

The input authentication information is sent to the authentication server, and authentication is performed at the authentication server (step 4104). If this authentication fails, the operator re-enters the authentication information. On the other hand, if this authentication is successful, the authentication module 911 will be in a state where the session CD can be obtained for a certain period of time thereafter (step 4105).
The above is the explanation of the business authentication process 4100.

1-6-4. Business ID acquisition processing FIG. 42 shows an example of business ID acquisition processing 4200. The process shown in the figure is executed as necessary after the operator is authenticated.
In this process, the business operator using the business DD 630 makes some request or input (step 4201). In response to this operation, the business operator DD 630 transmits the request/input along with the session CD to the product information management server 610 (step 4202).

Upon receiving this request/input, the authentication module 711 of the product information management server 610 transmits the session CD to the authentication server and requests the business ID (step 4203). The authentication server verifies the session CD (step 4204), and if the session CD is valid, transmits the corresponding business ID to the product information management server 610. By acquiring this business operator ID, the product information management server 610 can acquire attribute information of the business operator (step 4205). After acquiring the business ID, the product information management server 610 executes processing according to the above request/input (step 4206).
The above is the explanation of the business ID acquisition process 4200.

1-6-5. Business Product/Sales/Inventory Data Collaboration Processing FIG. 43 shows an example of business product/sales/inventory data collaboration processing 4300. The processing shown in the figure is executed regularly at a certain frequency, such as daily.
This process is based on the premise that a session has been established between the business server 640 and the product information management server 610, with the access key ensuring uniqueness.
In this process, the business server 640 extracts product, sales, or inventory data and sends it to the product information management server 610 (step 4301). At this time, when transmitting sales data, business server 640 transmits the sales data accumulated since the previous transmission.

Upon receiving the sales data, the data cooperation module 712 of the product information management server 610 stores the data in the company sales table 1500 in association with the company ID (step 4302).
When the data cooperation module 712 receives the inventory data, it associates the data with the business ID and stores it in the business inventory table 1600 (step 4303).

Upon receiving the product data, the data linkage module 712 associates the data with a business ID and creates a business product table 3100 (specifically, business ID 3101, category 3102, manufacturer 3103, product ID 3104, product name 3105, registration date and time 3216) (step 4304).
Note that when storing product data based on sales data, the module aggregates the sales data into product granularity and stores the data.

After storing the product data, the module extracts records that have not been matched with the universal master from the business product table 3100 (step 4305). After extracting the record, the module removes unnecessary symbols from the product name, corrects spelling errors, and arranges the word order (step 4306). Then, the module stores the formatted product name in the business product table 3100 (specifically, the product name (after formatting) 3107).

After storing, the module compares the formatted product name with the product master table 2100 (step 4307). Then, the module stores the brand ID and product ID that are associated with the reformatted product name in the table in the business product table 3100 (specifically, brand ID 3208 and product ID 3209).
Note that product names that do not match in the machine process will be matched manually.

For product names that do not match even through manual processing, the module registers new products and brands (step 4308). Specifically, the module generates a new brand ID and stores the generated ID and brand name in association with each other in the brand master table 2000. The module also generates a new product ID, associates the generated ID with the formatted product name, and stores it in the product master table 2100. Further, the module stores the generated brand ID and product ID in the business product table 3100 (specifically, brand ID 3208 and product ID 3209).
The above is the explanation of the product/sales/inventory data collaboration process 4300.

1-6-6. Parts integration processing (based on the company's unique product ID)
FIG. 44 shows an example of a parts embedding process 4400 for incorporating branded parts or value-added parts. In the process shown in the figure, each part is installed based on the product ID unique to the business operator.
This process assumes that the business authentication process 4100 has been completed.
In this process, the business operator using the business DD 630 accesses the product information management server 610 (step 4401). Along with this access, business ID acquisition processing 4200 is executed, and the built-in tag management module 713 of the product information management server 610 acquires the business ID (step 4402).

Further, in response to the above access, the built-in tag setting module 912 of the business operator DD 630 displays tags for branded parts built-in (step 4403). The business operator installs the displayed tag in the business DA 622 (step 4404). Examples of tags are shown below.
(1) When linking product/sales/inventory data (1-1) For brand cards
<iframe src="https://nomi-log.jp/bcard/?player_cd=xxx&prod_cd=xxx"></iframe>
(1-2) For brand page
<iframe src="https://nomi-log.jp/bpage/?player_cd=xxx&prod_cd=xxx"></iframe>

Note that at the time these tags are displayed on the business operator DD 630, the code (in other words, ID) of the business operator is filled in player_cd.
In the xxx part of prod_cd=xxx, fill in the product code (in other words, product ID) unique to the target business operator that you want to embed, and embed it in any page of the business DA 622.

(2) If product/sales/inventory data is not linked (2-1) For brand cards
<iframe src="https://nomi-log.jp/bcard/?player_cd=xxx&brand_cd=xxx"></iframe>
(2-2) For brand page
<iframe src="https://nomi-log.jp/bpage/?player_cd=xxx&brand_cd=xxx"></iframe>

Note that at the time these tags are displayed on the business operator DD 630, the code (in other words, ID) of the business operator is filled in player_cd.
In the xxx portion of brand_cd=xxx, search for the brand code (in other words, brand ID) of the target brand to be embedded using a predetermined form, fill in the code, and embed it in any page of the business DA 622.

When incorporating value-added parts (specifically, for example, customer service parts) in addition to tags for incorporating brand-name parts, the embedding tag setting module 912 of the business operator DD 630 displays tags for incorporating value-added parts. (Step 4405). The business operator installs the displayed tag in the business DA 622 (step 4406). Examples of tags are shown below.
<iframe src="https://nomi-log.jp/chat/?player_cd=xxx"></iframe>

Note that this tag cannot be embedded unless product/sales/inventory data is linked.
At the time this tag is displayed on the business operator DD 630, player_cd is filled with the code (in other words, ID) of the business operator.
In the xxx part of prod_cd=xxx, fill in the product code (in other words, product ID) unique to the target business operator that you want to embed, and embed it in any page of the business DA 622.

After acquiring the business ID, the built-in tag management module 713 of the product information management server 610 acquires the built-in tag setting contents (step 4407), and sends the brand parts setting form to the built-in tag setting module 912 of the business DD 630. Display it (step 4408). The displayed form is a form for setting whether or not to display a map button, whether or not to display a cart button, and the transition destination of the cart button. The business operator inputs setting details into this form (step 4409).

The built-in tag setting module 912 transmits an update request including the input setting contents to the product information management server 610 (step 4410). Along with this transmission, the business ID acquisition process 4200 is executed, and the built-in tag management module 713 of the product information management server 610 acquires the business ID (step 4411). After acquiring the business ID, the module updates the brand parts setting table 2600 based on the transmitted settings (step 4412). After this update, the built-in tag setting module 912 of the business operator DD 630 displays the update result (step 4413).
The above is the explanation of the parts installation process 4400.

1-6-7. Parts assembly processing (based on universal brand ID)
FIG. 45 shows an example of a parts installation process 4500 for installing branded parts. In the process shown in the same figure, unlike the parts installation process 4400 shown in FIG. 44, brand parts are installed based on a universal brand ID instead of a product ID unique to the business operator.
This process assumes that the business authentication process 4100 has been completed.
In this process, the business operator using the business DD 630 accesses the product information management server 610 (step 4501). With this access, business ID acquisition processing 4200 is executed, and the built-in tag management module 713 of the product information management server 610 acquires the business ID (step 4502).

Further, in response to the above access, the built-in tag setting module 912 of the business operator DD 630 displays a generation form for a tag that incorporates brand parts (step 4503). The business operator inputs all or part of the target stock name into this form (step 4504). The built-in tag setting module 912 transmits each change in the form to the product information management server 610 (step 4505).

The built-in tag management module 713 of the product information management server 610 refers to the brand name fluctuation table 2700 and the brand master table 2000, identifies a brand group that partially matches the input value, and returns the brand name group (step 4506). The built-in tag setting module 912 of the business operator DD 630 displays a supplementary list of the received brand names (step 4507). The business operator selects a target brand from this list (step 4508). The built-in tag setting module 912 transmits the selected or input brand name to the product information management server 610 (step 4509).

The built-in tag management module 713 of the product information management server 610 refers to the brand name variation table 2700 and the brand master table 2000, identifies the brand ID corresponding to the received brand name, and returns it (step 4510). Upon receiving this return, the built-in tag setting module 912 of the business operator DD 630 displays the tag that incorporates the brand parts of the brand (step 4511). The business operator installs the displayed tag in the business DA 622 (step 4512). Examples of tags are shown below.

(1) For brand cards
<iframe src="https://nomi-log.jp/bcard/?player_cd=xxx&brand_cd=xxx"></iframe>
(2) For brand page
<iframe src="https://nomi-log.jp/bpage/?player_cd=xxx&brand_cd=xxx"></iframe>
Furthermore, at the time these tags are displayed on the operator's DD630, the player_cd is filled with the code (in other words, ID) of the operator, and the xxx part of brand_cd=xxx is filled with the brand code (in other words, , brand ID) are filled in.

After acquiring the business ID, the built-in tag management module 713 of the product information management server 610 acquires the built-in tag setting contents (step 4513), and sends the brand parts setting form to the built-in tag setting module 912 of the business DD 630. Display (step 4514). The displayed form is a form for setting whether or not to display a map button, whether or not to display a cart button, and the transition destination of the cart button. The business operator inputs the setting details into this form (step 4515).

The built-in tag setting module 912 transmits an update request including the input setting contents to the product information management server 610 (step 4516). Along with this transmission, the business ID acquisition process 4200 is executed, and the built-in tag management module 713 of the product information management server 610 acquires the business ID (step 4517). After acquiring the business ID, the module updates the brand parts setting table 2600 based on the transmitted settings (step 4518). After this update, the built-in tag setting module 912 of the business operator DD 630 displays the update result (step 4519).
The above is the explanation of the parts installation process 4500.

Note that in step 4504 of the above process, the business operator may input a JAN code, an EAN code, or a product image instead of the brand name as information for specifying the target brand.

1-6-8. Brand Promotion Information Registration Process FIG. 46 shows an example of a registration process 4600 for a manufacturer to register brand promotion information.
This process assumes that the business authentication process 4100 has been completed.
In this process, the information registration module 913 of the business operator DD 630 outputs a registration form (step 4601). The maker inputs registered contents or changed contents into this form (step 4602). The information registration module 913 transmits the input information to the product information management server 610 (step 4603).

Along with this transmission, business ID acquisition processing 4200 is executed, and the registered information management module 714 of the product information management server 610 acquires the business ID (step 4604). After acquiring the business ID, the module updates the DB based on the received input information (step 4605). After the update, the information registration module 913 of the business operator DD 630 displays the update result (step 4606). The relationship between the input information and the table to be updated is as follows.

(1) Basic information (manufacturer, category, area, etc.)
Brand master table 2000
(2) Attribute information (characteristics, manufacturing method, raw materials, etc.)
Brand/element relationship table 3500
Element master table 2300 (if the target attribute is not registered)
(3) Image (image, video, VR space, etc.)
Stock information table 2900

(4) PR content Stock information table 2900
(5) Contest award history, media exposure history Stock/media related table 3600
Media master table 2400 (if target media is not registered)
(6) Map of stores where you can drink/purchase Business product table 3100 or business/brand relationship table 7700 described later
Business master table 2500 (if the target business is not registered)

(7) List of EC stores where you can buy business product table 3100
Business master table 2500 (if the target business is not registered)
(8) Face pattern of brand parts Brand information table 2900
The above is the description of the registration process 4600.

1-6-9. Registration Process for Stocks Handled FIG. 47 shows an example of a registration process 4700 for sellers to directly register stocks they handle.
This process assumes that the business authentication process 4100 has been completed.
Also, in this process, steps 4501 to 4509 of parts installation process 4500 are executed first.

Thereafter, the registered information management module 714 of the product information management server 610 refers to the brand name fluctuation table 2700 and the brand master table 2000 to identify the brand ID corresponding to the brand name received from the business operator DD 630 (step 4701). . The module also acquires a business ID through business ID acquisition processing 4200 (step 4702). After obtaining the business ID, the module registers the identified brand ID in the business product table 3100 as a brand handled by the business (step 4703).
The above is the description of the registration process 4700.

1-6-10. Seller's Product/Sales/Inventory Data Collaboration Process for Registration of Handling Information This data collaboration process is the same as the product/sales/inventory data collaboration process 4300.

1-6-11. Seller's Supplier's Sales Data Cooperation Process FIG. 48 shows an example of the seller's supplier's sales data cooperation process 4800.
In this process, steps 4301 and 4302 of product/sales/inventory data linkage process 4300 are first executed.

Thereafter, the data cooperation module 712 of the product information management server 610 registers the sales destination (buyer) in the sales data with the business operator (step 4801). Specifically, this module registers the sales destination in the business master table 2500 (specifically, business ID 2502, name 2503, type 2504, telephone number 2509, address 2510), and stores the sales destination's business ID. is registered in the business sales table 1500 (specifically, the buyer business ID 1510). At that time, the module registers differences (only unregistered records) and eliminates redundant records as much as possible through name matching.

Next, the module associates the product data with the sales destination business ID and stores it in the business product table 3100 (specifically, business ID 3101, category 3102, manufacturer 3103, product ID 3104, product name 3105, registration date and time). 3216) (step 4802).
Thereafter, steps 4304 to 4306 of product/sales/inventory data linkage processing 4300 are executed.
The above is the explanation of the sales data cooperation process 4800.

1-6-12. Inventory information update process of cooperating businesses Update the inventory quantity, inventory level, and inventory estimation accuracy in the business product table 3100 using one of the following methods.
(1) Linking inventory data of target businesses (data linkage processing 4300)
No additional action by the operator is required. The processing content always reflects the inventory quantity in the business product table 3100. Inventory estimation accuracy is 100%.
(2) Linking sales data of suppliers of target businesses (data linkage processing 4800)
No additional action by the operator is required. The process involves estimating the inventory level based on past trends each time the supplier business sales table 1500 is updated. Inventory estimation accuracy ranges from low to high (depending on past trends).

(3) Linking sales data of target businesses (data linkage processing 4300)
As for the additional measures taken by the business, each time inventory is replenished, the number of items in stock is updated from the management screen. The processing content is to reduce the number of items in stock each time the business sales table 1500 is updated. Inventory estimation accuracy is low to medium (depending on update history).
(4) Direct input by target business operators Additional response by business operators is to update the inventory quantity from the management screen every time there is a change in inventory. There is no particular processing content. Inventory estimation accuracy is low to medium (depending on update history).

1-6-13. “I want to drink” registration process FIG. 49 shows an example of a registration process 4900 for registering a brand that the user of the consumer DD 620 wants to drink.
This process assumes that the user authentication process 3900 has been completed. If the process is not completed, the process transitions to step 4904, which will be described later.

In this process, when the user accesses an arbitrary page (step 4901), the display module 821 of the consumer DD 620 displays the page (step 4902). The displayed page is a page in which the brand parts are incorporated, and along with the display of the page, the process of reading the brand parts (steps 5203 to 5211 of the brand parts display process 5200) is executed (step 4903). This brand part reading process will be described later.

After displaying the page, the user presses the brand part tag button (see reference numeral 6507 in FIG. 65) (step 4904). In response to this operation, consumer DD 620's intention/history registration module 812 transmits a registration request to product information management server 610 (step 4905). A session CD and a universal stock ID are attached to the transmitted request. Upon transmission of this request, user ID acquisition processing 4000 is executed, and intention/history management module 715 of product information management server 610 acquires the user ID (step 4906).

After acquiring the user ID, the module registers the user's intention of “I want to drink” in the user/brand relationship table 3700 (specifically, the user ID 3701, brand ID 3702, and label 3703). After registration, consumer DD 620's intention/history registration module 812 notifies completion of registration (step 4908). FIG. 71 shows an example of a registration completion notification screen 7100.
The above is the description of the registration process 4900.

1-6-14. “Drank” and “Favorite” Registration Process FIG. 50 shows an example of a registration process 5000 for registering brands that the user of the consumer DD 620 drinks or favorite brands.
This process assumes that the user authentication process 3900 has been completed. If the process is not completed, the process transitions to step 5001, which will be described later.

In this process, when the user accesses the posting/evaluation screen (step 5001), the intention/history registration module 812 of the consumer DD 620 displays the posting/evaluation form (step 5002). The user inputs a post or evaluation into this form (step 5003). The intention/history registration module 812 sends the input posting/evaluation registration request to the product information management server 610 with the session CD and brand identification information attached (step 5004). Along with this transmission, the user ID acquisition process 4000 is executed, and the intention/history management module 715 of the product information management server 610 acquires the user ID (step 5005).

After obtaining the user ID, the module identifies the target brand ID from the received brand identification information (step 5006). After specifying the brand ID, the module registers the received post/evaluation in the post table 1100, posted brand table 1200, and posted evaluation table 1300 (step 5007). After registration, the module registers the user's history in the user/brand relationship table 3700 (specifically, user ID 3701, brand ID 3702, label 3703, and basis 3705) (step 5008). At that time, if the user's evaluation is above a certain level, the module registers it as a "favorite" in addition to "drinked".

After registration, the intention/history registration module 812 of the consumer DD 620 notifies the consumer of the completion of registration (step 5009).
The above is the description of the registration process 5000.

In addition, in the above registration process 5000, there are various means by which the user specifies the target brand when registering preferences (drinking intention, drinking history, evaluation history, etc.). For example, there are the following methods.
(1) The user passes the universal stock ID to the server through an action such as pressing a button on an application (stock parts, etc.) that already holds the universal stock ID.
(2) Pass the value input by the user to the server through text input/voice input of the target stock name.
(3) The user passes an image of the target brand (the product itself, a magazine describing the product, etc.) to the server.

1-6-15. “Bought” Registration Process FIG. 51 shows an example of a registration process 5100 for registering a brand purchased by the user of the consumer DD 620.
This process assumes that the linkage of product data has been completed. Furthermore, this process assumes that the user authentication process 3900 has been completed.

When the user performs an access operation in this process (step 5101), the display module 821 of the consumer DD 620 displays the EC screen (step 5102). The user performs the purchase procedure on this EC screen (step 5103). In response to this operation, the display module 821 transmits a payment processing request to the business server 640 (step 5104). The business server 640 processes this payment processing request (step 5105), and as a result, the display module 821 notifies the payment completion (step 5106).

After the notification, the module passes the purchase notification request to the intention/history registration module 812 (step 5107). A business ID and an individual product ID are attached to this request. Upon receiving this request, the intention/history registration module 812 transmits a purchase notification to the product information management server 610 (step 5108). The session CD, business ID, and individual product ID are attached to the sent notification. Upon transmission of this notification, user ID acquisition processing 4000 is executed, and intention/history management module 715 of product information management server 610 acquires the user ID (step 5109).

After acquiring the user ID, the module refers to the business product table 3100 and identifies the brand ID from the received individual product ID (step 5110). After specifying the brand ID, the module stores the user's history in the user/brand relationship table 3700 (specifically, user ID 3701, brand ID 3702, label 3703, trigger 3704, basis 3705, number of purchases 3708, and purchase amount 3709). Register (step 5111).

After registration, consumer DD 620's intention/history registration module 812 notifies completion of registration (step 5112).
The above is the description of the registration process 5100.

1-6-16. Brand Parts Display Processing FIG. 52 shows an example of brand parts display processing 5200.
In this process, when the user accesses an arbitrary page (step 5201), the display module 821 of the consumer DD 620 displays the page (step 5202). The displayed page is a page in which brand parts are incorporated. The module passes the brand parts request to the brand parts display module 813. An individual product ID or universal brand ID and part type information are attached to this request. Here, the parts type information indicates either a brand card or a brand page.

In response to the above request, the brand parts display module 813 transmits a brand parts request to the product information management server 610 (step 5204). A business ID and an individual product ID or a universal brand ID are attached to this request.

When the brand parts information providing module 716 of the product information management server 610 receives the individual product ID, it refers to the business product table 3100 and specifies the target brand ID (step 5205). Then, the module extracts necessary information on brand parts for the target brand (step 5206). The tables referred to and the information extracted at this time are as follows.

(1) Brand master table 2000
Basic information (manufacturer, category, area, etc.)
(2) Brand/element relationship table 3500
Attribute information (characteristics, manufacturing method, raw materials, etc.)

(3) Stock information table 2900
Images (images, videos, VR space, etc.)
PR content Face pattern of brand parts (4) Brand/media relationship table 3600
Contest award history, media exposure history

The module also refers to the brand parts setting table 2600 and extracts brand part output conditions of the target business operator (step 5207).

The brand parts display module 813 of the consumer DD 620 performs output processing according to the above part type information (step 5208). Specifically, the module outputs a brand card when the parts type information indicates "card", and outputs a brand page when the parts type information indicates "page".

The module also performs output processing according to the face pattern (step 5209). Specifically, if the face pattern is "background", this module will adopt the background image or video pattern, if the face pattern is "product_or_label", it will adopt the product/label image pattern, and if the face pattern is "background", it will adopt the product/label image pattern. text”, the pattern is adopted only for text.

The module also performs output processing according to the button settings (step 5210). Specifically, the module determines, depending on the button settings, whether or not a map button needs to be displayed, whether a cart button needs to be displayed, and whether or not it is necessary to limit the transition destination of the cart button.

After going through steps 5208 to 5210 above, the module displays brand parts (step 5211).
The above is the explanation of the brand parts display processing 5200.

In addition, in the above process, the process of converting brand-related information into a display layout may be performed either on the consumer DD 620 side or on the product information management server 610 side.

FIG. 65 shows a brand card 6500 as an example of brand parts.
The brand card 6500 is a display element displayed as part of a page on the web. The card is displayed within a minimum area, and the display area expands when the button is pressed.
This brand card 6500 notifies the basic information of the brand. Specifically, the card notifies the image 6501, name 6502, category 6503, (production) area 6504, and manufacturer 6505 regarding the brand.

Further, this brand card 6500 has an information button 6506, a tag button 6507, a map button 6508, and a cart button 6509.
Among these buttons, the information button 6506 is a button for displaying a brand introduction area (see reference numeral 6602 in FIG. 66), which will be described later.
The tag button 6507 is a button for registering the target brand as "want to drink".
The map button 6508 is a button for displaying stores where the target brand can be consumed or purchased.
The cart button 6509 is a button for displaying EC stores where the target brand can be purchased.

FIG. 66 shows a brand page 6600 as another example of brand parts.
Unlike the brand card 6500, the brand page 6600 is a display element that is displayed in the maximum area from the beginning. If the page is a web site, it will be displayed in a pop-up format or as a page transition destination.

This brand page 6600 has a face area 6601 and a brand introduction area 6602. Among these, the face area 6601 notifies basic information of the brand. Specifically, this area notifies the image 6603, name 6604, category 6605, (production) area 6606, and manufacturer 6607 regarding the brand.
The area also includes a tag button 6608, a map button 6609, and a cart button 6610. The functions of these buttons are the same as the buttons with the same names on the brand card 6500 described above.

On the other hand, the brand introduction area 6602 includes a product information tab 6611, a manufacturer's brand introduction tab 6612, a notification tab 6613, a drinker's word of mouth tab 6614, and an award history tab 6615. By selecting any of these tabs, desired information can be viewed.

FIG. 67 shows an example of a screen 6700 that is displayed when a brand card is installed in the business DA 622. The screen 6700 shown in the figure includes three brand cards 6701 to 6703.

FIG. 68 shows an example of a screen 6800 that is displayed when a brand page is incorporated into the business DA 622. When a specific brand 6801 is clicked on the screen 6800 shown in the figure, a brand page 6802 of the brand is displayed in a pop-up format.

FIG. 69 shows an example of display options for the face area. The display options shown in the figure are common to the brand card and brand page.
FIG. 69(a) shows a face area 6901 that notifies only basic information. The basic information referred to here is the product name 6902, category 6903, (production) area 6904, and manufacturer 6905.

FIG. 69(b) shows a face area 6906 with a product label image. A face area 6906 shown in the same figure notifies basic information as well as a label image 6907 of the product.
FIG. 69(c) shows a face area 6908 with an arbitrary still image or moving image as a background. A face area 6908 shown in the figure notifies basic information with an arbitrary still image or moving image 6909 as a background.

FIG. 70 shows an example of display options for the brand introduction area.
FIG. 70(a) shows an example of a brand introduction area 7001 output by the DA of the manufacturer or seller. The brand introduction area 7001 shown in the figure particularly has a producer brand introduction tab 7002.

FIG. 70(b) shows an example of the brand introduction area 7003 output by the seller's DA. The brand introduction area 7003 shown in the figure has a manufacturer brand introduction tab 7004. In addition, a brief stock introduction 7005 by the seller is written in this area. This stock introduction has been independently registered by the seller.

FIG. 70(c) shows an example of the brand introduction area 7006 output by the seller's DA. The brand introduction area 7006 shown in the figure has a manufacturer brand introduction tab 7007. In addition, the area includes a seller stock introduction tab 7008. This tab is displayed as a result of a detailed stock introduction being registered by the seller.

Note that the creator can freely embed a plurality of images, 360-degree images, and videos in the face area shown in FIG. 70.
Furthermore, content in the brand introduction area can be created freely by the creator. The creator can just fill in the images and text, or they can specify the HTML code. In addition, the producer can set whether or not to display the "reviews from drinkers" and "award history" sections of the brand introduction area.

1-6-17. Map Display Processing FIG. 53 shows an example of map display processing 5300 executed when the map button for brand parts is pressed.
When executing this process, it is optional whether or not the user authentication process 3900 is completed.
In this process, when the user of the consumer DD 620 presses the map button (see reference numeral 6508 in FIG. 65) (step 5301), the map display module 814 of the consumer DD 620 sends a request to the product information management server 610 (step 5302). ). A business ID, universal stock ID, access location, and session CD are attached to this request.

If a session CD is attached to this request, the user ID acquisition process 4000 is executed, and the map information providing module 717 of the product information management server 610 acquires the user ID (step 5303). After acquiring the user ID, the module extracts stores where the target brand can be consumed and purchased (step 5304).

Specifically, the module refers to the business product table 3100 and extracts the business ID associated with the received universal brand ID. Then, the module further refers to the business master table 2500 and selects businesses whose addresses are within a certain range from the received access location and whose type is "restaurant" among the extracted business IDs. Extract the ID as a restaurant where you can drink. The module also refers to the same table and extracts business IDs from the business product table 3100 that have addresses within a certain range from the received access location and whose type is "retail store". The business ID is extracted as a store where it can be purchased.

After extracting the stores where you can drink and where you can buy, if the target user can be specified, the module sorts and/or narrows down the stores where you can drink and where you can buy based on the user's preferences or conditions (step 5305). At this time, the module refers to the user purchase preference table 3000 (target 3002 = physical store). Examples of sorting and filtering are shown below.

(1) When prioritizing availability (inventory status) The module refers to the business product table 3100 and sorts business IDs based on the number of stocks corresponding to the target business ID and brand ID. and/or filter.
(2) When giving priority to the store used The module refers to the user/business relationship table 3800 and sorts and/or narrows down business IDs based on usage history.
(3) When prioritizing frequently used business formats The module refers to the business master table 2500 and the user/business relationship table 3800, and sorts and/or narrows down the business IDs based on the type.

(4) When prioritizing store reputation The module refers to the business master table 2500 and sorts and/or narrows down the business IDs based on the evaluation.
(5) When prioritizing store location (proximity) The module refers to the business master table 2500 and sorts and/or narrows down the business IDs based on the distance between the address and the access location.
(6) When giving priority to price The module refers to the business product table 3100 and sorts and/or narrows down business IDs based on the price corresponding to the target business ID and brand ID.

After sorting and/or narrowing down the stores, the map display module 814 of the consumer DD 620 plots the stores on the map and displays them as a list at the bottom of the map (step 5306). At this time, the display contents of the list are determined depending on the data registration status. For example, whether or not the inventory quantity is displayed is determined depending on whether or not the inventory quantity is registered in the business entity product table 3100, and whether or not a reservation button is displayed is determined depending on whether or not a reservation URL is registered in the business entity master table 2500. It is decided.

FIG. 72 shows an example of a brand card 7200 having a map and the like.
The brand card 7200 has a face area 7201, a map 7202, a list of stores where you can drink 7203, and a list of stores where you can purchase 7204.
Among these, map 7202 shows restaurants where the target brand can be consumed and retail stores where the target brand can be purchased, which are close to the user's current location.

The drinkable restaurant list 7203 is a list of restaurants near the user's current location where the target brand can be served. The list shows a name 7205, inventory level 7206, address 7207, telephone number 7208, and reservation button 7209 for each store.
The store list 7204 is a list of retail stores where the target brand can be purchased near the user's current location. The list shows a name 7205, inventory level 7206, address 7207, telephone number 7208, and reservation button 7209 for each store.

Returning to the explanation of map display processing 5300.
When the user clicks or visits a specific store displayed on the above map or list (step 5307), the map display module 814 sends a request to the product information management server 610 (step 5308). This request is attached with a business ID, universal stock ID, session CD, click target business ID, and activity history information.

If the session CD is attached to this request, the user ID acquisition process 4000 is executed, and the map information providing module 717 of the product information management server 610 acquires the user ID (step 5309). After obtaining the user ID, the module registers the received activity history in the user purchase activity table 1400 (step 5310).

The registered and accumulated activity history is referred to when estimating the user's preferences or conditions (step 5311). This estimation process is performed by analyzing the user purchase activity table 1400, and the top three factors that the user prioritizes are extracted and registered in the user purchase preference table 3000. Further, this estimation process is executed at a certain frequency, such as weekly or monthly.
The above is the explanation of the map display processing 5300.

1-6-18. EC List Display Processing FIG. 54 shows an example of EC list display processing 5400 executed when the cart button for branded parts is pressed.
When executing this process, it is optional whether or not the user authentication process 3900 is completed.
In this process, when the user of the consumer DD 620 presses the cart button (see reference numeral 6509 in FIG. 65) (step 5401), the EC list display module 815 of the consumer DD 620 determines whether the transition destination is limited to one or not. (Step 5402).

As a result of this determination, if the transition destination is limited to one (YES), the module transitions to the set transition destination (step 5403). On the other hand, if the result of this determination is that the transition destination is not limited to one (NO), the module transmits a request for EC stores where the product can be purchased to the product information management server 610 (step 5404). A business ID, universal stock ID, access location, and session CD are attached to this request.

If a session CD is attached to this request, the user ID acquisition process 4000 is executed, and the EC information providing module 718 of the product information management server 610 acquires the user ID (step 5405). After acquiring the user ID, the module extracts an EC store where the target brand can be purchased (step 5406).

Specifically, the module refers to the business product table 3100 and extracts the business ID associated with the received universal brand ID. Then, the module further refers to the business master table 2500 and extracts, from among the extracted business IDs, the business ID in which the EC URL is registered as an EC store where the EC URL can be purchased.

After extracting the EC stores, if the target user can be identified, the module sorts and/or narrows down the EC stores that can be purchased based on the user's preferences or conditions (step 5407). At this time, the module refers to the user purchase preference table 3000 (target 3002 = EC). Examples of sorting and filtering are shown below.

(1) When prioritizing availability (inventory status) The module refers to the business product table 3100 and sorts business IDs based on the number of stocks corresponding to the target business ID and brand ID. and/or filter.
(2) When prioritizing the store used The module refers to the user/business relationship table 3800 and sorts and/or narrows down business IDs based on usage history.
(3) When prioritizing frequently used business formats The module refers to the business master table 2500 and the user/business relationship table 3800, and sorts and/or narrows down the business IDs based on the type.

(4) When prioritizing store reputation The module refers to the business master table 2500 and sorts and/or narrows down the business IDs based on the evaluation.
(5) When giving priority to CO ₂ (theoretical value) required for delivery The module refers to the delivery cost table 3400 and sorts and/or narrows down the business IDs based on CO ₂ at the time of delivery.
(6) When giving priority to price The module refers to the business product table 3100 and sorts and/or narrows down business IDs based on the price corresponding to the target business ID and brand ID.

After sorting and/or narrowing down the stores, the EC list display module 815 of the consumer DD 620 refers to the delivery cost table 3400 to display the delivery cost corresponding to the target business ID and area ID. Extract the cost (step 5408). In addition, when displaying the emitted CO ₂ , the module refers to the delivery cost table 3400 and extracts the delivery CO ₂ corresponding to the target business ID and area ID (step 5409).

After extracting CO ₂ at the time of delivery, the module displays a list of stores (step 5410). At this time, the display contents of the list are determined depending on the data registration status. For example, whether or not to display the scheduled shipping date, scheduled delivery date, and shipping fee is determined depending on whether or not data is registered in the shipping cost table 3400. Whether or not the total price and inventory quantity are displayed is determined depending on whether the price and inventory quantity are registered in the business product table 3100.

FIG. 73 shows an example of a brand card 7300 having a store list.
The brand card 7300 has a face area 7301 and a store list 7302.
Among these, the store list 7302 is a list of EC stores where the target brand can be purchased. The list shows a name 7303, inventory level 7304, scheduled shipping date 7305, scheduled delivery date 7306, shipping fee 7307, total (amount) 7308, and purchase button 7309 for each EC store.

Returning to the explanation of the EC list display processing 5400.
When the user clicks on or visits a specific store displayed on the above list, or makes a purchase at the specific store (step 5411), the EC list display module 815 sends a request to the product information management server 610 (step 5412). This request is attached with a business ID, universal stock ID, session CD, click target business ID, and activity history information.

If a session CD is attached to this request, the user ID acquisition process 4000 is executed, and the EC information providing module 718 of the product information management server 610 acquires the user ID (step 5413). After obtaining the user ID, the module registers the received activity history in the user purchase activity table 1400 (step 5414).

The registered and accumulated activity history is referred to when estimating the user's preferences or conditions (step 5415). This estimation process is performed by analyzing the user purchase activity table 1400, and the top three factors that the user prioritizes are extracted and registered in the user purchase preference table 3000. Further, this estimation process is executed at a certain frequency, such as weekly or monthly.
The above is a description of the EC list display processing 5400.

1-6-19. Product Notification Processing at EC Store FIG. 55 shows an example of product notification processing 5500 based on the visitor's preferences, which is executed at the EC store.
This process assumes that the user authentication process 3900 has been completed.
In this process, when the user of the consumer DD620 accesses the EC store (step 55401), the display module 821 of the consumer DD620 displays the EC screen (step 5502).

Along with this display, the product notification module 816 of the consumer DD 620 transmits a request to the product information management server 610 (step 5503). The session CD and provider ID are attached to this request.

Upon transmission of this request, the user ID acquisition process 4000 is executed, and the product information providing module 719 of the product information management server 610 obtains the user ID (step 5504). After acquiring the user ID, the module registers the user's activity history in the user purchase activity table 1400 (step 5505).

After registration, the module extracts the stocks for which the user has recorded intentions, actions, or ratings (step 5506). Specifically, the module extracts the brand ID and label associated with the acquired user ID from the user/brand relationship table 3700.

In addition, the module extracts brands recommended to the user (step 5507). Specifically, the module extracts from the preference estimation table 1900 a brand ID that is associated with the acquired user ID and whose estimated value is above a certain level, and associates it with the label "recommended".

Then, the module narrows down the product group handled by the target business operator from the brand group extracted in steps 5506 and 5507 (step 5508). Specifically, the module extracts, from the business product table 3100, the target business ID and the business unique product ID associated with the extracted brand ID. After extraction, the module returns the extracted product ID and the corresponding record type (label) information to the consumer DD 620 (step 5509). An example of returned data is shown below.

Product ID label
x231203 I want to drink
x231204 drank
x231205 drank
x231212 I like it
x231212 Recommended

In the consumer DD 620, when the scheme DA 621 changes the display/decoration, the product notification module 816 executes a command to change the display/decoration of the target product (step 5510). Then, the display module 821 changes the display/decoration of the target product according to the command (step 5511).

In this case, for example, when the product ID is "pxyz052" and the record type is "I want to drink," the operator DA 622 will display it in the form of $('.tag4_pxyz052').addClass('view4_wish-to-drink'). The protocol that allows the change of is already shared between (the developer of) the business operator DA 622 and the product information management server 610 in advance.

On the other hand, when the business operator DA 622 changes the display/decoration in the consumer DD 620, the product notification module 816 returns the receipt data as is to the display module 821 (step 5512). Then, the display module 821 changes the display of the business operator DA 622 as appropriate according to the received data (product x behavior type of the accessing user) (step 5513).
This concludes the description of the product notification process 5500.

FIG. 74 shows an example of an EC screen 7400 on which a target product is decorated.
In the screen shown in the figure, a brand 7401 that the user wants to drink is surrounded by a frame 7402 and labeled 7403 as "Brand that the user wants to drink."
Also, on the same screen, a brand 7404 that the user drank is surrounded by a frame 7405 and labeled 7406 as "Brand drunk."

Notification of the target product may be made by changing the size of the target product, changing the background color around the target product, adding a specific mark or icon around the target product, or displaying supplementary information such as a speech bubble around the target product. You can.

When the scheme DA 621 changes the display/decoration in the above product notification process 5500, the business DA 622 cannot obtain the access user's user ID, the recorded product group, and the label. However, since this scheme DA 621 operates on the consumer DD 620, there is a risk that the information obtained within this scheme DA 621 will be obtained if the business operator takes a response that violates the terms of use. However, even in that case, information recorded by the user regarding products other than the handled products will not be leaked.

On the other hand, when the business DA 622 changes the display/decoration in the above process, the business DA 622 can acquire the recorded product group and label, but cannot acquire the user ID of the accessing user. However, if user authentication is performed separately on the business DA 622 side, the business will be able to hold the data as "product group and record type recorded by the user".

1-6-20. Product Notification Process in a Physical Store FIG. 56 shows an example of a product notification process 5600 based on the preferences of a customer, which is executed in a restaurant or retail store.
This process assumes that the business authentication process 4100 has been completed.
In this process, the operator using the operator DD 630 accesses the scheme DA 631 (step 5601). Upon receiving this access, the code display module 914 of the business operator DD 630 displays a pop-up advertisement containing the QR code (registered trademark) (step 5602). The business operator prints this pop-up advertisement and places it in the store (step 5603).

Thereafter, the user of the consumer DD 620 photographs the QR code at the store when visiting the store (step 5604). In response to this photographing, the scheme DA 621 is activated, and the product notification module 816 of the consumer DD 620 transmits a request to the product information management server 610 (step 5605). The session CD and provider ID are attached to this request.

After sending this request, steps 5504 to 5510 of the product notification process 5500 described above are executed. Thereafter, the product notification module 816 of the consumer DD 620 notifies the target product as appropriate (step 5606).

Note that in the above process, the user notifies the product information management server 610 that he/she has visited the store by photographing the QR code. However, instead of photographing the QR code, the user may notify the product information management server 610 of the visit to the store by transmitting the GPS information of the consumer DD 620 to the product information management server 610. In addition, as another modification, RF tags, beacons, Wi-Fi (registered trademark), etc. may be used to detect when a user enters or exits a physical store.

Note that in the above process, the user is notified of the target product via the consumer DD 620, but the notification means of the target product is not limited to the consumer DD 620. For example, the user may be notified of the target product via a display (for example, an electronic signboard) installed at the store. In that case, the product information management server 610 transmits information about the target product to a server managed by the business operator that operates the store. The server that receives the information about the target product causes the information to be displayed on a display installed in the store.

FIG. 75 shows an example of an application screen 7500 that notifies the target product. The screen shown in the figure notifies the user of the brand he or she wants to drink.
FIG. 76 shows an application screen 7600 for notifying target products as another screen example. The screen shown in the figure also notifies the user of the brand he/she wishes to drink. However, the same screen includes a two-axis element evaluation chart 7601.

A plurality of icons 7602 are arranged in this chart 7601. Each icon 7602 represents a brand, and the position of each icon 7602 represents the element evaluation value of the brand with respect to the two evaluation axes.
When the application screen 7600 is displayed on the consumer DD 620, the element evaluation value of the target brand is transmitted from the product information management server 610 to the consumer DD 620.
The above is the explanation of the product notification process 5600.

1-6-21. Customer Service FIG. 57 shows an example of customer service processing 5700 based on product characteristics accumulated through user evaluations.
This process assumes that the linkage of product data has been completed. Furthermore, this process assumes that the user authentication process 3900 has been completed.
When the user performs an access operation in this process (step 5701), the display module 821 of the consumer DD 620 displays the EC screen (step 5702). Along with this display, the proposed brand notification module 817 of the consumer DD 620 displays customer service parts (step 5703). This customer service part presents possible conditions as appropriate.

The user makes various requests for brand suggestions to this customer service part (step 5704). Upon receiving this request, the proposed brand notification module 817 transmits a brand proposal request to the product information management server 610 (step 5705). The session CD, provider ID, and request contents are attached to this request.

Upon transmission of this request, the user ID acquisition process 4000 is executed, and the brand proposal module 720 of the product information management server 610 acquires the user ID (step 5706). After acquiring the user ID, the module analyzes the request content while referring to the name spelling variation table 2800 (step 5707), and determines whether the request has been cleared in a manner that meets the conditions for handling. (Step 5708). As a result of this determination, if the request is not cleared (NO), the proposed stock notification module 817 of the consumer DD 620 checks for missing or ambiguous points (step 5709), and the user answers the question (step 5709). 5710), the proposed brand notification module 817 sends the request again to the product information management server 610 (step 5711).

On the other hand, if the result of the determination in step 5708 is that the request is cleared (YES), the brand proposal module 720 of the product information management server 610 next executes step 5712.
Note that steps 5707 to 5711 described above are repeatedly executed until the request is cleared in a manner that meets the applicable conditions. These steps are performed using a general-purpose language analysis AI (API).

In step 5712, the brand proposal module 720 extracts brands that meet the specified conditions. At this time, the applicable brand extraction conditions are as follows.

(1) Basic information on the brand (category, production area, manufacturer, etc.)
The module extracts a brand ID associated with a specified category ID, area ID, or manufacturer ID from the brand master table 2000.
(2) Brand attribute information (raw materials, manufacturing method, etc.)
The module extracts the brand ID associated with the specified element ID from the brand/element relationship table 3500.
(3) Various characteristics of the brand (suitable for white fish, recommended for celebrations, etc.)
This module extracts a brand ID having a strong feature of the specified element ID from the brand feature table 1700.

(4) Award history and exposure history of the brand (○○ gold award, etc.)
The module extracts the brand ID associated with the specified media ID from the brand/media relationship table 3600.
(5) Intentions and actions of target users (brands they want to drink, brands they have drunk, favorite brands, etc.)
This module extracts the brand ID in which the intention and history specified by the target user are registered from the user/brand relationship table 3700.
(6) Target User's Preferences The module extracts from the preference estimation table 1900 brand IDs that are associated with the target user and whose estimated values are above a certain level.

After extracting the brands, the proposed brand notification module 817 of the consumer DD 620 presents the extracted brands (step 5713). The method of presenting the brand is not limited to text-based, but may also be voice- or image-based.
The above is the explanation of the customer service processing 5700.

In step 5712 of the customer service processing 5700 and step 5507 of the product notification processing 5500 described above, the preference estimation table 1900 is referred to. This preference estimation table 1900 is generated by the following procedure.
(1) Through the registration process 5000, data is accumulated in the posting table 1100, the posting brand table 1200, and the posting evaluation table 1300.
(2) Based on the data accumulated in the above three tables, the preference model table 1800 is updated for each user.

(3) The brand characteristic table 1700 is updated based on the data accumulated in the above three tables and the brand characteristic information registered by the manufacturer.
(4) The preference estimation table 1900 is updated based on the brand feature table 1700 and the preference model table 1800.
The processes (2) to (4) will be explained below.

1-6-22. Generation of Preference Model FIG. 58 shows an example of a preference model generation flow 5800.
This flow is periodically executed by the model generation module 727 of the product information management server 610 for each user and category pair.
In this flow, the model generation module 727 acquires the user ID and category ID to be processed (step 5801).

After acquiring the user ID, etc., the module acquires the comprehensive evaluation value and product characteristic value of each brand. Specifically, the module obtains the post ID associated with the obtained user ID from the post table 1100 (step 5802).
After acquiring the posting ID, the module acquires the brand ID associated with the acquired category ID from the brand master table 2000 (step 5803).

After acquiring the brand ID, the module acquires the overall evaluation value associated with the acquired posted ID and brand ID from the posted brand table 1200 (step 5804).
After acquiring the comprehensive evaluation value, the module acquires the applied value associated with the acquired brand ID from the brand characteristic table 1700 (step 5805).

After obtaining the comprehensive evaluation value and applied value for each brand, the module performs multiple regression analysis based on the obtained comprehensive evaluation value and applied value, and creates a preference model with the overall evaluation as the objective variable and product characteristics as the explanatory variables. Generate (step 5806). At this time, the module may narrow down the elements to be used as explanatory variables to predetermined elements in order to prevent multicollinearity from occurring.
The module stores the partial regression coefficient and standard partial regression coefficient for each element, and the intercept in the preference model table 1800 in association with the acquired user ID and category ID (step 5807).
The above is a description of the preference model generation flow 5800.

1-6-23. Correction of Subjective Quantitative Values FIG. 59 shows an example of a correction flow 5900 for subjective quantitative values.
This flow is executed by the correction module 728 of the product information management server 610.
In this flow, the correction module 728 acquires one element ID to be processed from the brand characteristic table 1700 for the brand to be processed (step 5901). At that time, the module acquires the element ID (that is, the element ID of the subjective quantitative value) that is associated with type A "subjective" and type B "quantitative value" in the stock feature table 1700.

After acquiring the element ID, the module acquires all element evaluation values associated with the acquired element ID from the posted evaluation table 1300 (step 5902).
After acquiring the element evaluation values, the module calculates the average value and standard deviation of the acquired element evaluation values (step 5903).
After the calculation, the module stores the calculated average value and standard deviation in the stock characteristic table 1700 in association with the obtained element ID (step 5904).

After storing, the module acquires the stored value associated with the acquired element ID from the brand feature table 1700 (step 5905).
After obtaining the stored value, the module calculates an applied value based on the obtained stored value and the calculated mean and standard deviation (step 5906). Specifically, the module considers the stored value to be the applied value if it is within the range of the average value ±1σ, and otherwise considers the weighted average value of the stored value and the average value to be the applied value. .
The module stores the calculated application value in the brand feature table 1700 in association with the acquired element ID (step 5907).

After storing, the module determines whether applied values have been calculated for all subjective quantitative values of the stock being processed (step 5908). As a result of this determination, if applied values have not been calculated for all subjective quantitative values, the module executes step 5901. On the other hand, if the applied values have been calculated for all the subjective quantitative values, the module determines whether the applied values have been calculated for all the stocks to be processed (step 5909). As a result of this determination, if the applied values have not been calculated for all the stocks to be processed, the module executes step 5901. On the other hand, when the applied values have been calculated for all the stocks to be processed, the module ends this correction flow.

Through the correction flow described above, the user's actual evaluation can be reflected in the stored values that are stored in advance in the brand feature table 1700.

1-6-24. Generation of preference estimation table 1900 FIG. 60 shows an example of a generation flow 6000 of preference estimation table 1900.
This flow is executed by the preference estimation module 729 of the product information management server 610.
In this flow, the preference estimation module 729 acquires the post ID associated with the target user ID from the post table 1100 (step 6001).
After acquiring the posting ID, the module acquires the brand ID associated with the acquired category ID from the brand master table 2000 (step 6002).

After acquiring the brand ID, the module acquires the overall evaluation value associated with the acquired posted ID and brand ID from the posted brand table 1200 (step 6003).
After acquiring the comprehensive evaluation value, the module acquires the applied value of each element associated with the acquired posting ID from the brand feature table 1700 (step 6004).
After acquiring the applied value, the module stores the acquired user ID, category ID, brand ID, comprehensive evaluation value, and applied value in the preference estimation table 1900 in association with each other (step 6005).

After generating the preference estimation table 1900, the module acquires a preference model associated with the acquired user ID and category ID from the preference model table 1800 (step 6006).
For each brand ID registered in the preference estimation table 1900, the module estimates a comprehensive evaluation value by inputting the applied value into the acquired preference model, and stores the estimated comprehensive evaluation value in the preference estimation table 1900 (step 6007 ). At this time, the module estimates the comprehensive evaluation value only for brand IDs for which the comprehensive evaluation value (actual value) is not registered among the brand IDs registered in the preference estimation table 1900.
The above is the description of the generation flow 6000.

1-6-25. Reward Program Registration Process FIG. 61 shows an example of a reward program registration process 6100 by a business operator.
This process assumes that the business authentication process 4100 has been completed.
In this process, when the business operator accesses the reward registration page (step 6101), the reward program registration module 915 of the business operator DD 630 displays a reward registration form (step 6102). The business operator inputs the target, conditions, and contents into this form (step 6103).

Here, the target is specified by manufacturer (group), production area (group), and category (group).
Conditions include a user's "drinking" post, a "drinking" post based on an image taken by the user, and a history of "buying" from a affiliated seller.
The content includes distributing discount coupons and sending prizes at specific stores.

After inputting the target, etc., the reward program registration module 915 transmits a program registration request to the product information management server 610 (step 6104). The reward program management module 721 of the product information management server 610 registers the received reward program information in the business operator reward program table 3200 (step 6105). After registration, the reward program registration module 915 notifies the completion of registration (step 6106).
The above is a description of the reward program registration process 6100.

1-6-26. Periodic Calculation of Reward Accumulation Status by User Based on the user/brand relationship table 3700, the accumulation status of each reward program registered in the user/company relationship table 3800 is calculated. This calculation is performed at a certain frequency, such as daily.

1-6-27. Reward Program Usage Process by User FIG. 62 shows an example of a reward program usage process 6200 by a user.
This process assumes that the user authentication process 3900 has been completed.
In this process, when the user accesses the reward program page (step 6201), the reward usage module 818 of the consumer DD 620 transmits a status confirmation request to the product information management server 610 (step 6202). A session CD is attached to this request.

Upon transmission of this request, the user ID acquisition process 4000 is executed, and the reward management module 722 of the product information management server 610 acquires the user ID (step 6203). After acquiring the user ID, the module extracts information about the corresponding program from the user/company relationship table 3800 (step 6204). After this extraction, the reward utilization module 818 of the consumer DD 620 outputs the corresponding program and its accumulation status (step 6205). Looking at this output result, the business operator confirms the accumulation status (step 6206).

If the user wants to exchange the accumulated value for a reward, he/she applies for exchange (step 6207). In response to this operation, the reward usage module 818 transmits an exchange request to the product information management server 610 (step 6208). The session CD, program ID, and consumption range information are attached to this request.

Upon receiving this request, the reward management module 722 of the product information management server 610 executes reward consumption processing in the user/business relationship table 3800 (step 6209). Along with this execution, the business server 640 starts a procedure according to the content of the reward (step 6210). After starting the procedure, the reward management module 722 of the product information management server 610 returns the pointer URL of the reward exchange guidance to the consumer DD 620 (step 6211). The reward redemption module 818 of the consumer DD 620 displays a pointer to the received reward redemption guidance (step 6212).
The above is a description of the reward program usage process 6200.

1-6-28. Program Sales Process by Business Operator FIG. 63 shows an example of program sales process 6300 by a business operator. The program referred to here refers to a subscription program.
This process assumes that user authentication process 3900 and business operator authentication process 4100 have been completed.

In this process, the business operator registers the program (steps 6301 and 6302). Specifically, the business operator registers the program ID sending frequency, the unit selling price per sending, and the cost budget per sending in the business server 640. Upon receiving this registration, the program registration module 916 of the business operator DD 630 transmits a program registration request to the product information management server 610 (step 6303). This request is attached with a business ID, a program ID, and cost budget information per sending.

The program management module 723 of the product information management server 610 registers the received information in the business subscription program table 3300 (step 6304).

The display module 821 of the consumer DD 620 sells the program registered in the business server 640 to the user (step 6305). When the user purchases this program (step 6306), the display module 821 requests the business server 640 to process the payment (step 6307). Upon receiving this request, the business server 640 executes payment processing and issues a user key (step 6308). After issuing the user key, the display module 821 notifies the product information management server 610 of the completion of payment (step 6309). The session CD, program ID, and user key are attached to this notification.

In response to this notification, the user ID acquisition process 4000 is executed, and the program management module 723 of the product information management server 610 acquires the user ID (step 6310). After acquiring the user ID, the module associates the user ID, user key, and program ID and registers them in the user/company relationship table 3800 (step 6311).
The above is the explanation of the program sales process 6300.

1-6-29. Product Delivery Process to User FIG. 64 shows an example of product delivery process 6400 to the user. The product referred to here refers to a product delivered pursuant to a subscription program.
In this process, the business server 640 transmits a product selection request to the product information management server 610 (step 6401). A program ID and a user key are attached to this request.

The product selection module 724 of the product information management server 610 extracts the user ID associated with the received program ID and user key from the user/business relationship table 3800 (step 6402). The module also refers to the business subscription program table 3300 and extracts the cost budget associated with the received program ID.

Next, the module refers to the user/brand relationship table 3700 and extracts the brand ID that the user has registered as a "want to drink" or "favorite" (step 6403).
In addition, the module extracts brands recommended to the user (step 6404). Specifically, the module extracts, from the preference estimation table 1900, brand IDs that are associated with the acquired user ID and whose estimated values are above a certain level.

Next, the module narrows down the group of products that are handled by the target business and fit within the budget from the group of extracted brands (step 6405). Specifically, the module extracts from the business entity product table 3100 the target business entity ID, the brand ID extracted in step 6403 or 6404, the brand ID associated with the price below the budget, and the business entity's unique Extract the product ID. At this time, if inventory information is registered in the table, the module extracts products that are in stock.

Next, the module excludes brands sent to the user in the past from the extracted product group (step 6406). Specifically, the module extracts the brand ID associated with the target user ID and target program ID (registration origin information 3707) from the user/brand relationship table 3700. Then, the module excludes the product of the extracted brand from the product group extracted in step 6405.

Next, the module selects the product with the highest recommendation level from the remaining product group (step 6407). Specifically, the module extracts the target user ID and the brand ID associated with the highest actual value or estimated value from the preference estimation table 1900. The module then selects products of the extracted brand.

Next, the module registers the results of selecting target products in the user/brand relationship table 3700 (step 6408). Specifically, the module associates the target user ID with the brand ID extracted in step 6407 in the table, and stores "bought" (label 3703), target business operator ID (registration origin business ID 3706), Register the target program ID (registration origin information 3707).

After registration, the business server 640 starts delivery procedures for the product selected in step 6407 (step 6409).
The above is the explanation of the product delivery process 6400.

2. Modifications The above embodiment may be modified as follows.
(1) In the preference model generation flow 5800, a preference model is generated by multiple regression analysis (see step 5807). However, instead of this, the preference model may be generated using other statistical methods or machine learning methods.

(2) In the above embodiment, alcoholic beverages are assumed to be the target product. However, other palatability products may be adopted as target products instead of alcoholic beverages.

(3) As an application example of brand parts, an application may be adopted in which a seller reuses brand parts for his own sales staff. Such an application allows the manufacturer to distribute pages and PDF files such as campaign information to sales representatives of multiple sellers.

(4) As an application example of the simplified version of brand parts (product images only), a restaurant or a restaurant menu production company can collectively view and select product images registered by each manufacturer, and use the menu for the restaurant. An application that can be linked so that the image group can be imported into the creation application may be adopted.

(5) The application for registering or using the reward program is not limited to this scheme DA621 or 631, but may be an application (in which this module is incorporated) of any business operator.

(6) The performance information accumulated in association with the reward program is not limited to performance information such as "bought", but may also include performance information such as "drinked".

(7) When product handling information is registered in the product information management server 610 based on wholesale sales data, the store may be able to refuse publication of the data using a predetermined form.

(8) Information registration rights for branded parts may be set depending on the position of the business operator.
FIG. 77 shows an example of information registration rights for branded parts that are set according to the positioning of the business operator.
As shown in the figure, the maker of the target brand can register the face settings of brand parts and the maker's brand PR. Here, the face settings of the brand parts are, for example, the product name 6902 and the product label image 6907 illustrated in FIG. 69 . On the other hand, the maker's brand PR is information displayed when the maker's brand introduction tab 6612 illustrated in FIG. 66 is selected.

Next, we will explain the producer agent of the target brand.
The manufacturer's agent for the target brand is a seller who has exclusive sales rights for the target brand in a specific area. In the above embodiment, the maker agent and the maker are collectively referred to as the "maker."
The maker representative of the target brand can register the face settings of the brand parts, the maker's brand PR, and the seller's brand PR. Here, the seller's brand PR is information displayed when the seller's simple brand introduction 7005 illustrated in FIG. 70 or the seller's brand introduction tab 7008 is selected.

Among the information that can be registered by a maker representative, the face settings of brand parts and the maker's brand PR are displayed to consumers accessing the maker representative's sales area.
At that time, such information will be displayed unconditionally if the maker has not registered the target information, and if the maker has registered the target information, the maker's representative will have PR priority rights. Displayed only if the
On the other hand, the seller's brand PR is displayed only in the brand parts installed on the DA operated by the manufacturer's agent.

Next, I will explain about the seller.
This seller does not have exclusive sales rights, but sells the target issue. This seller can only register the seller's brand PR.
The seller's brand PR registered by this seller is displayed only in the brand parts installed on the DA operated by the seller.

The method for determining the position of each business operator is, for example, as follows.
If the access operator ID in the operator DD 630 matches the manufacturer ID of the target brand in the brand master table 2000, the operator is determined to be the manufacturer of the target brand.
If the access operator ID in the operator DD 630 matches the ID of the operator that has exclusive sales rights for the target brand in the operator/brand relationship table 7700 described later, the operator is determined to be the manufacturer's agent for the target brand. be done.
If the access operator ID in the operator DD 630 matches the operator ID that has a sales record of the target brand in the operator/stock relationship table 7700 or the operator product table 3100 (described later), the operator can access the target brand. determined to be a seller.

FIG. 78 shows an example of a business/brand relationship table 7700 for setting information registration rights for each brand for each business.
The business/brand relationship table 7700 includes business ID 7701, brand ID 7702, manufacturer ID 7703, sales area ID 7704, presence/absence of exclusive sales rights 7705, presence/absence of PR priority 7706, registration date/time 7707, update date/time 7708, updater ID 7709, etc. Has a field.

Among these fields, the seller business ID is stored in business ID 7701.
The maker ID 7703 stores the maker ID of the relevant brand.
The sales area ID 7704 stores the ID of the area where the seller sells the relevant brand.
Exclusive sales right presence/absence 7705 stores a value indicating whether or not the user has exclusive sales rights for the brand in the corresponding area.

PR priority presence/absence 7706 stores a value indicating whether or not to give priority to PR content over the creator's content in the corresponding area when the seller has exclusive sales rights.
The registration date and time 7707 stores a value indicating the date and time when the record was registered.
The update date and time 7708 stores a value indicating the date and time when the record was updated.
The updater ID 7709 stores the business ID that updated the information of the record. Note that if the sales area ID, exclusive priority, and PR priority are updated by the manufacturer, the seller cannot update them.

Next, the registration/change conditions for the business/brand relationship table 7700 will be explained.
Each record in this table is added by daily aggregation of the business product table 3100 by brand ID, or added for each brand by the seller or manufacturer using the business DD 630.

The sales area ID, exclusive sales rights, and PR priority rights can be registered by the seller. However, multiple sellers cannot register exclusive sales rights in the same area. An error will be output for such a registration attempt. In the unlikely event that an error occurs, it will be resolved between the parties involved.
Further, the maker can overwrite and change the information, and after the maker updates it, the seller cannot update the sales area ID, exclusive priority right, or PR priority right.

The business/brand relationship table 7700 described above is stored in the auxiliary storage device 702 of the product information management server 610. This table is referred to by the registration information management module 714 in the brand promotion information registration process 4600 described above.
The registration information management module 714 refers to the table and manages the information when the business using the business DD 630 has the right to register product-related information of the target brand, and If we do not have such information, we will not manage that information.

Further, the business/brand relationship table 7700 is referred to by the brand parts information providing module 716 in the brand parts display processing 5200 described above.
The brand parts information providing module 716 transmits product-related information of the target brand to the consumer DD 620 when a screen incorporating a code for displaying product parts is displayed on the consumer DD 620.

At that time, the module stores the product-related information if the consumer DD620 exists in an area that is associated in advance with the business operator (specifically, the manufacturer's agent) that has registered the product-related information. It is transmitted to the consumer DD620.
In addition, the module allows a business that has registered product-related information (specifically, a manufacturer's representative) to have priority rights over a business that has registered similar information (specifically, the manufacturer). If so, the product-related information is transmitted to the consumer DD620.
The brand parts display module 813 of the consumer DD 620 acquires and displays the product-related information transmitted from the product information management server 610.

Note that the present invention is not limited to the above-described embodiments, and includes various modifications. For example, the embodiments described above are described in detail to explain the present invention in an easy-to-understand manner, and the present invention is not necessarily limited to having all the configurations described. Furthermore, it is possible to replace a part of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. Further, it is possible to add, delete, or replace a part of the configuration of each embodiment with other configurations.

Further, each of the above-mentioned configurations, functions, processing units, processing means, etc. may be partially or entirely realized in hardware by designing, for example, an integrated circuit. Furthermore, each of the above configurations, functions, etc. may be realized by software by a processor interpreting and executing a program for realizing each function. Information such as programs, tables, files, etc. that implement each function can be stored in a memory, a recording device such as a hard disk, an SSD (Solid State Drive), or a recording medium such as an IC card, SD card, or DVD.

Further, the control lines and information lines are shown to be necessary for explanation purposes, and not all control lines and information lines are necessarily shown in the product. In reality, almost all components may be considered to be interconnected.
Note that the above-described embodiments disclose at least the configuration described in the claims.

600... Product information management system, 610... Product information management server, 620... Consumer DD, 630... Business DD, 640... Business server, 711... Authentication module, 712... Data linkage module, 713... Built-in tag management module , 714...Registered information management module, 715...Intent/history management module, 716...Brand parts information providing module, 717...Map information providing module, 718...EC information providing module, 719...Product information providing module, 720...Brand proposal module , 721... Reward program management module, 722... Reward management module, 723... Program management module, 724... Product selection module, 725... Post management module, 726... Evaluation management module, 727... Model generation module, 728... Correction module, 729 ... Preference estimation module, 741 ... Transaction DB, 742 ... Analysis data DB, 743 ... Master DB, 744 ... Setting DB, 745 ... Element DB, 746 ... Relationship DB, 811 ... Authentication module, 812 ... Intention/history registration module, 813 ...Brand parts display module, 814...Map display module, 815...EC list display module, 816...Product notification module, 817...Suggested brand notification module, 818...Reward usage module, 819...Posting module, 820...Evaluation sending module, 821 ... Display module, 831 ... Consumer DD data, 911 ... Authentication module, 912 ... Built-in tag setting module, 913 ... Information registration module, 914 ... Code display module, 915 ... Reward program registration module, 916 ... Program registration module, 921 …Business operator DD data

Claims (25)

A product information management system,
Consumer terminals are
Display means for displaying product parts having product information regarding the product and selection buttons;
information acquisition means for transmitting an information request to a product information management server when the button is selected;
The product information management server is
A management means for managing store information regarding stores where the product can be purchased or consumed;
information providing means for receiving the information request transmitted from the consumer terminal and transmitting the store information to the consumer terminal;
The product information management system is characterized in that the display means of the consumer terminal additionally displays the store information transmitted from the product information management server. The product information management system according to claim 1,
A product information management system characterized in that the product parts are display elements incorporated in any screen. The product information management system according to claim 2,
The operator terminal is
A business terminal used by any business that produces and provides the screen has a store registration means for transmitting the store information to the product information management server,
A product information management system, wherein the management means of the product information management server manages the store information transmitted from the vendor terminal. The product information management system according to any one of claims 1 to 3,
The management means of the product information management server manages product information regarding the product, product handling information of a store where the product can be purchased or consumed, and store information regarding the store,
The information providing means of the product information management server transmits store information of a store that handles the product to the consumer terminal,
The product information management system is characterized in that the display means of the consumer terminal additionally displays the store information transmitted from the product information management server on the product parts. The product information management system according to claim 4,
The above product handling information is
Either manually registering each product via a business terminal used by the store; Linking any of the product master, sales data, and inventory data linked with the store with the product information management server; or A product information management system characterized in that the information is registered or updated by collaborating with the product information management server the sales data of businesses from which stores purchase the products. The product information management system according to claim 4,
The product handling information includes product inventory information of the store,
The product information management system is characterized in that the information providing means of the product information management server transmits store information of stores that have the product in stock to the consumer terminal. The product information management system according to any one of claims 1 to 3,
A product information management system, wherein the display means of the consumer terminal displays the store information on a map. The product information management system according to any one of claims 1 to 3,
The information providing means of the product information management server extracts store information corresponding to the current location of the consumer using the consumer terminal from among the store information managed by the management means and provides the information to the consumer terminal. A product information management system characterized by transmitting information to. The product information management system according to any one of claims 1 to 3,
The information providing means of the product information management server extracts store information according to the preferences of the consumer using the consumer terminal from among the store information managed by the management means and transmits the extracted store information to the consumer terminal. A product information management system characterized by transmitting information. The product information management system according to any one of claims 1 to 3,
The button is at least one of a first button for displaying store information regarding a physical store and a second button for displaying store information regarding an online store,
The product information management system is characterized in that the display means of the consumer terminal displays a button selected in advance from among the first button and the second button. The product information management system according to any one of claims 1 to 3,
A product information management system characterized in that the product is alcoholic beverages. A product information management server,
A management means for managing store information regarding stores where products can be purchased or consumed;
information providing means for receiving an information request transmitted from a consumer terminal and transmitting the store information to the consumer terminal;
A product part having product information regarding the product and a selection button is displayed on the consumer terminal, and when the button is selected, the information request is transmitted to the product information management server,
A product information management server characterized in that the store information transmitted from the product information management server is additionally displayed on the consumer terminal. The product information management server according to claim 12,
A product information management server characterized in that the product parts are display elements incorporated in any screen. The product information management server according to claim 13,
The product information management server is characterized in that the management means manages the store information transmitted from a business terminal used by any business that produces and provides the screen. The product information management server according to any one of claims 12 to 14,
The management means manages product information regarding the product, product handling information of a store where the product can be purchased or consumed, and store information regarding the store,
The information providing means transmits store information of a store that handles the product to the consumer terminal,
A product information management server characterized in that the store information transmitted from the product information management server is additionally displayed on the product parts on the consumer terminal. The product information management server according to claim 15,
The above product handling information is
Either manually registering each product via a business terminal used by the store; Linking any of the product master, sales data, and inventory data linked with the store with the product information management server; or A product information management server characterized in that the information is registered or updated by cooperating with the product information management server sales data of businesses from which stores purchase the products. The product information management server according to claim 15,
The product handling information includes product inventory information of the store,
The product information management server is characterized in that the information providing means transmits store information of stores that have the product in stock to the consumer terminal. The product information management server according to any one of claims 12 to 14,
A product information management server, wherein the store information is information displayed on a map on the consumer terminal. The product information management server according to any one of claims 12 to 14,
The information providing means extracts store information corresponding to the current location of the consumer using the consumer terminal from among the store information managed by the management means and transmits it to the consumer terminal. Product information management server. The product information management server according to any one of claims 12 to 14,
The information providing means extracts store information according to the preferences of the consumer using the consumer terminal from among the store information managed by the management means and transmits the extracted store information to the consumer terminal. Product information management server. The product information management server according to any one of claims 12 to 14,
The button is at least one of a first button for displaying store information regarding a physical store and a second button for displaying store information regarding an online store,
The management means further manages preset button setting information,
The information providing means further transmits the button setting information to the consumer terminal,
A product information management server characterized in that, of the first button and the second button, a button corresponding to the button setting information transmitted from the product information management server is displayed on the consumer terminal. The product information management server according to any one of claims 12 to 14,
A product information management server characterized in that the product is alcoholic beverages. Consumer terminals are
Display means for displaying product parts having product information regarding the product and selection buttons;
When the button is selected, information acquisition means transmits an information request to a product information management server and acquires store information managed by the product information management server regarding stores where the product can be purchased or consumed; has
The consumer terminal, wherein the display means additionally displays the acquired store information. A method of providing product information,
a step in which the consumer terminal displays a product part having product information regarding the product and a button for selection;
the consumer terminal, when the button is selected, transmits an information request to a product information management server;
the product information management server managing store information regarding stores where the product can be purchased or consumed;
the product information management server receiving the information request transmitted from the consumer terminal and transmitting the store information to the consumer terminal;
A product information providing method comprising the step of the consumer terminal displaying the store information transmitted from the product information management server. A program for causing a consumer terminal to function as each means according to claim 23.

Images