JP7735615B1 - Information processing system and information processing method - Google Patents

Abstract

To meet the needs of providers who want to encourage content related to products to be actively posted on SNS, to encourage content created by those who have purchased products to be posted, and to encourage content that conforms to policies to be posted.
[Solution] The control system 1 has the functions of accepting proof of purchase of the target product from users participating in a purchase campaign conducted by the provider for the target product, notifying the results of checks conducted on the proof of purchase, and granting benefits to users who pass; and accepting target product-related content for posting on SNS from users participating in a posting campaign, notifying users of the results of video screening, and deriving and granting rewards for the posts based on the target product-related content posted on SNS by users who pass the video screening.
[Selected Figure] Figure 2

Description

This disclosure relates to an information processing system and information processing method that provide services.

In recent years, social networking sites (SNSs) have become popular, allowing anyone to post videos (including short videos or reels, which are approximately 15 to 60 seconds long), still images, and other content, and allowing viewers to view the content. In the following, when simply referring to SNS, unless otherwise specified, it will be assumed to refer to a content posting (sharing) type of SNS. Examples of SNSs are Instagram and TikTok (both are registered trademarks). On this type of SNS, content that includes product introductions is sometimes posted. Here, "products" includes not only tangible objects, but also e-books, music for streaming, games for streaming, and other intangible media, as well as services.

Content introducing products includes "content primarily intended for advertising/promotion" (hereinafter referred to as "advertising-only content") created by product providers (for example, manufacturers that develop, manufacture, and sell products), "content for one of the purposes of advertising/promotion" (hereinafter referred to as "influencer content") created by so-called influencers at the request of providers, and "content introducing products" (hereinafter referred to as "general contributor content") created by general contributors who are neither providers nor influencers. It has become clear that general contributor content has a strong influence on consumers as advertising/promotion or word-of-mouth, just as much as advertising-only content and influencer content. Patent Document 1 describes the following technology related to SNS. Specifically, Patent Document 1 describes a system that accurately predicts the evaluation value of content (posted information) and supports the selection of influencers suitable for requesting content posting.

JP 2023-94970 A

As mentioned above, content by general contributors has a strong influence on consumers as promotion/advertising or word-of-mouth. Therefore, providers have a need to create an environment in which general contributors actively create content about the products they offer and post it on social media, thereby effectively promoting/advertising the products and promoting their sales. With regard to content, providers also have a need to ensure that "content created by people who have actually purchased the product" is posted on social media. People who have actually purchased the product know how the product was actually sold in stores (including online shops) and how much it was actually sold for. Having such people create content can be expected to provide a thorough introduction that is in line with the product's actual substance. Furthermore, providers have a need to ensure that content posted conforms to the provider's policies. If the content does not conform to the provider's policies, it not only fails to appeal to consumers about the product's appeal, but may even create a negative impression.

This disclosure has been made to solve these problems, and aims to meet the needs of providers: those who want to create an environment in which general contributors can actively create and post product-related content to social media; those who want content created by people who have actually purchased a product to be posted to social media; and those who want content that conforms to policies to be posted.

In order to solve the above-mentioned problems, the present disclosure has the following configuration: An information processing system comprising an information processing unit having the following functions: a function to accept proof of purchase of a target product from users participating in a purchase campaign run by a provider for the target product, notify the users of the check results of a purchase check conducted on the proof of purchase, and grant a reward to the users who pass the purchase check; and a function to accept target product-related content, which is content related to the target product to be posted on SNS, from users who pass the purchase check and are participating in a posting campaign run by the provider for the target product, notify the users of the review results of a video review conducted on the target product-related content, derive a reward for the post in response to the posting of the target product-related content on the SNS by the users who pass the video review, and grant the derived reward to the users.

According to the present disclosure configured as described above, users can earn rewards by using a service realized by the functions of an information processing system to post content related to products provided by providers to SNS. This meets the needs of providers who want to create an environment in which general contributors actively create product-related content and post it to SNS. Furthermore, according to the present disclosure, in order to receive rewards for posting content in a service realized by the functions of an information processing system, users must submit proof of purchase of the product and pass a check on that information. Therefore, content posted using the posting promotion service is created by users who have actually purchased and used the product. This meets the needs of providers who want content created by actual product purchasers to be posted to SNS. Furthermore, according to the present disclosure, in a service realized by the functions of an information processing system, content is reviewed, and content that passes the review is eligible for rewards. This makes it possible to eliminate content that does not meet the provider's policies during the review process, meeting the needs of providers who want content that meets those policies to be posted.

FIG. 1 is a diagram illustrating an example of the configuration of a control system according to an embodiment. FIG. 2 is a block diagram illustrating an example of the functional configuration of each device in the control system according to an embodiment. FIG. 1 is a diagram illustrating an overview of campaign-related services. FIG. 10 is a diagram showing an example of the contents of a purchase CP management record. FIG. 10 is a diagram showing an example of the contents of a posted CP management record. FIG. 10 is a diagram used to explain each period related to a post CP. 10 is a flowchart showing an information processing method performed by a user terminal and an information processing server. FIG. 10 is a diagram illustrating an example of a purchase CP details screen. FIG. 10 is a diagram showing an example of the contents of purchase CP participation unit information. 10 is a flowchart showing an information processing method performed by a user terminal and an information processing server. FIG. 10 is a diagram showing an example of a pass notification screen. FIG. 10 is a diagram illustrating an example of a posted CP details screen. FIG. 10 is a diagram showing an example of content of post CP participation unit information. 10 is a flowchart illustrating an information processing method performed by the information processing server. 10A and 10B are diagrams showing the contents of a sales status management record and measurement range-specific information. FIG. 10 is a diagram showing an example of a transition relationship screen in an initial state. FIG. 10 is a diagram illustrating an example of a transitional relationship graph. FIG. 10 is a diagram showing an example of a correlation screen in an initial state. FIG. 10 is a diagram illustrating an example of a correlation diagram. FIG. 10 is a diagram illustrating an example of an information input screen. FIG. 10 is a diagram illustrating an example of an information input screen. 10 is a flowchart illustrating an information processing method performed by a provider terminal and an information processing server. FIG. 1 illustrates the input and output of a trained model. FIG. 10 is a diagram illustrating an example of a simulation screen. FIG. 10 is a diagram illustrating an example of a simulation screen. 10 is a flowchart illustrating an information processing method performed by the information processing server. 10 is a flowchart illustrating an information processing method performed by the information processing server. 10 is a flowchart illustrating an information processing method performed by the information processing server. FIG. 10 is a diagram illustrating an example of a condition setting screen. FIG. 10 is a diagram showing an example of an implemented CP list screen. FIG. 10 is a diagram illustrating an example of a processing result display screen. FIG. 10 is a diagram illustrating an example of a blog. FIG. 1 illustrates an example of the configuration of an information processing system.

An embodiment of the present disclosure will now be described with reference to the drawings. FIG. 1 is a diagram showing an example configuration of a control system 1 (information processing system) according to this embodiment. As shown in FIG. 1, the control system 1 includes an information processing server 2 (information processing system, server, computer), one or more user terminals 3 (information processing system, terminal, computer), and one or more provider terminals 4 (information processing system, terminal, computer). The information processing server 2, user terminals 3, and provider terminals 4 can all be connected to a network N, which may include the Internet, a telephone network, or other communication networks.

The information processing server 2 is a server equipped with the functions of providing campaign-related services, information provision services, and simulation services. These services will be described later. Hereinafter, the services provided by the information processing service will be collectively referred to as the "Service." Furthermore, the entity (organization) that manages the information processing server 2 and thereby operates the Service will be referred to as the "Administrator." In Figure 1 and Figure 2, described below, the information processing server 2 is represented by a single block. However, this does not mean that the information processing server 2 is composed of a single server device. The information processing server 2 may be composed of a virtual server. The information processing server 2 may also be composed of multiple server devices. In this case, the server devices that make up the information processing server 2 may include a web server or a web application server. Furthermore, in this case, the information processing server 2 may be composed of multiple server devices whose load is distributed by a load balancer. In this case, each of the server information processing units 10 of the multiple server devices, or a combination of multiple server information processing units 10, functions as the "information processing unit."

The user terminal 3 is a terminal used by a user. In this embodiment, a user refers to a person who can use campaign-related services. In this embodiment, the first SNS is an SNS that implements a video posting (sharing) function that allows unspecified individuals to post so-called short videos (including reels) and allows viewers to play (view) the short videos. In the first SNS, short videos correspond to "content." Examples of this type of SNS include Instagram and TikTok (both registered trademarks). The first SNS supports so-called hashtags, and posters can assign hashtags to short videos posted to the first SNS. Hashtags are used for searching and grouping short videos within the first SNS. In addition, in the first SNS, a posting URL is issued by the first SNS system in response to the posting of a short video. The posting URL is a unique value for each short video, and functions as identification information for the posting URL and as an address for accessing the short video. Additionally, the first SNS supports engagement through so-called "likes," allowing viewers to give a "like" to a short video they have played, indicating a positive evaluation. Note that the reason the SNS targeted for short videos in the campaign-related services is one of the first SNSs is for simplicity of explanation, and the number and type of targeted SNSs can of course be arbitrary.

The user terminal 3 can be of any type. For example, a tablet computer (including so-called smartphones), a notebook computer, a desktop computer, or a wearable device can function as the user terminal 3.

The provider terminal 4 is a terminal used by a provider. In this embodiment, a provider refers to a company that sells (provides) products. Products include not only tangible objects but also e-books, music for distribution, games for distribution, tickets, certain rights, and other intangible media. Products also include services and other intangible offerings. Products are sold, for example, at retail stores, specialty stores, online shops, and download services. For example, a provider could be a company (a manufacturer) that develops, manufactures, and sells cosmetics, home appliances, beverages, automobiles, and other products. Another example of a provider could be a company that provides housekeeping services, nursing care services, repair services, medical services, and other services. As described below, a provider is an entity that provides purchase CP registration information and post CP registration information (both of which are described below) to the operator in campaign-related services. A provider is also an entity that uses information provision services and simulation services. In this embodiment, a provider is a concept that includes not only organizations but also individuals belonging to an organization, and may be expressed as "a provider uses the provider terminal 4." Like the user terminal 3, the provider terminal 4 can be of any type.

Figure 2 is a block diagram showing an example of the functional configuration of the information processing server 2, user terminal 3, and provider terminal 4. As shown in Figure 2, the information processing server 2 includes, as its functional configuration, a server information processing unit 10 (information processing unit), a server communication unit 11, and a server storage unit 12. The user terminal 3 includes, as its functional configuration, a user terminal information processing unit 13 (information processing unit), a user terminal communication unit 14, a user terminal display unit 15, a user terminal input unit 16, and a user terminal storage unit 17. The provider terminal 4 includes, as its functional configuration, a provider terminal information processing unit 18 (information processing unit), a provider terminal communication unit 19, a provider terminal display unit 20, a provider terminal input unit 21, and a provider terminal storage unit 22.

The server information processing unit 10 comprises a processing device including a processor and a primary storage device. The server information processing unit 10 executes processing by having the processing device read into the primary storage device and execute a program stored in the storage area of the server storage unit 12 (or another storage area). In other words, the server information processing unit 10 executes processing through cooperation between hardware and software. The server communication unit 11 comprises a communication device including a communication control device and a network interface. The server communication unit 11 communicates with external devices via the communication device under the control of the server information processing unit 10. The server storage unit 12 stores data in non-volatile memory. The non-volatile memory is, for example, a hard disk drive (or other magnetic storage device), ROM, or flash memory.

As shown in FIG. 2, the server storage unit 12 stores a user management database 30. The user management database 30 is a database for managing user information. A record (hereinafter referred to as a "user management record") is registered in the user management database 30 for each user. The user management record associates information about the user's attributes, information about the user's account, and other information about the user with a user ID (identification information for identifying the user).

The user terminal information processing unit 13 comprises a processing device including a processor and a primary storage device. The processing device reads a program stored in the storage area of the user terminal storage unit 17 (or another storage area) into the primary storage device and executes it, thereby executing the program. In other words, the user terminal information processing unit 13 executes processing through cooperation between hardware and software. The user terminal communication unit 14 comprises a communication device including a communication control device and a network interface. The user terminal communication unit 14 communicates with external devices via the communication device under the control of the user terminal information processing unit 13. The user terminal display unit 15 comprises an LCD panel, an organic EL panel, or other display device. The user terminal display unit 15 displays images on the display device under the control of the user terminal information processing unit 13. The user terminal input unit 16 detects input to the input device and outputs the detection result to the user terminal information processing unit 13. Examples of input devices include a keyboard, mouse, touch panel, and camera. The user terminal storage unit 17 stores data in non-volatile memory.

The provider terminal information processing unit 18, provider terminal communication unit 19, provider terminal display unit 20, provider terminal input unit 21, and provider terminal memory unit 22 each have the same hardware configuration and functions realized by the hardware configuration as the user terminal information processing unit 13, user terminal communication unit 14, user terminal display unit 15, user terminal input unit 16, and user terminal memory unit 17. In the following explanation, it is assumed that communication by the information processing server 2 is appropriately performed by the server communication unit 11, and a detailed explanation of the communication itself will be omitted. The same applies to communication by the user terminal 3 and the provider terminal 4.

As shown in FIG. 2, a dedicated application AP1 (hereinafter referred to as "user-dedicated application AP1") is installed on the user terminal 3. A dedicated application AP2 (hereinafter referred to as "provider-dedicated application AP2") is installed on the provider terminal 4. Hereinafter, the user-dedicated application AP1 and the provider-dedicated application AP2 are collectively referred to as the "dedicated application AP." The dedicated application AP is dedicated software that implements functions such as providing various screens related to the various services provided by the information processing server 2, sending and receiving various information between the information processing server 2 and other external devices, and executing other processes related to the service. Even if not specifically mentioned below, the user terminal information processing unit 13 and the provider terminal information processing unit 18 basically execute processes using the functions of the dedicated application AP (including the terminal's OS, web applications that can use the dedicated application AP, and other programs that can interact with the dedicated application AP). Even if not specifically mentioned below, the user terminal information processing unit 13 and the provider terminal information processing unit 18 execute the following processes as necessary. That is, the user terminal information processing unit 13 and the provider terminal information processing unit 18 communicate with the server information processing unit 10 (or an information processing unit of another external device; the same applies below) as needed to obtain information necessary for processing. In particular, when displaying various screens, the user terminal information processing unit 13 and the provider terminal information processing unit 18 obtain information necessary for screen display from the server information processing unit 10. The user terminal information processing unit 13 and the provider terminal information processing unit 18 also communicate with the server information processing unit 10 as needed to request processing execution and obtain processing results. In the following, the display of various screens by the user terminal information processing unit 13 on the user terminal display unit 15 using the dedicated app AP or other program functions may be expressed simply as "the user terminal information processing unit 13 displays a screen." The same applies to displays by the provider terminal information processing unit 18.

Next, an overview of the campaign-related service will be explained, focusing on one provider and one user. Figure 3 is a diagram used to explain this overview. In Figure 3, the block on the right represents one provider, provider SX, the block in the middle represents the service operator, and the block on the left represents one user, user UX. In the explanation of Figure 3, "service operator" is a collective term for the information processing server 2, the operator, and other entities involved in the provision/operation of the campaign-related service.

Provider SX can run purchase campaigns and posting campaigns for desired products from among the products it offers. Hereinafter, purchase campaigns will be referred to as "purchase CPs" and posting campaigns will be referred to as "posting CPs." Purchase CPs and posting CPs will be collectively referred to as "the CP in question." The product that is the subject of the CP in question will be referred to as the "target product." A purchase CP is a campaign that awards a specified bonus when a user purchases the target product corresponding to the purchase CP and submits proof of purchase (e.g., a receipt; details will be provided later) to the service operator. Hereinafter, a bonus related to a purchase CP will be referred to as a "purchase bonus." A posting CP is a campaign that awards a specified reward when a user posts a short video to the first SNS about the product corresponding to the posting CP. Hereinafter, a reward related to a posting CP will be referred to as a "posting reward."

In the explanation of Figure 3, it is assumed that provider SX implements the CP in question for product IX that it provides. As shown in Figure 3, when implementing the CP in question for product IX, provider SX provides purchase CP registration information and post CP registration information to the service operator (step S1). The purchase CP registration information and post CP registration information are described in detail below.

Purchase CP registration information is information related to a purchase CP. The purchase CP registration information includes information necessary to implement the purchase CP, as well as information necessary to display the purchase CP overview block and purchase CP details screen 31 described below. More specifically, the purchase CP registration information includes at least the purchase CP name, target product introduction information, purchase CP benefit rules, receipt submission period, purchase rules, and purchase CP participation rules.

Purchased CP name is the name of the purchased CP.

Target product introduction information is information that introduces and explains the target product. Target product introduction information includes, for example, an image of the product (for example, an image of the product's appearance or an image showing how it is being used; it can be a photograph or illustration, and can be a still image or video), the product name, a description of the product, the unit price of the product, and the product's selling points.

Purchase CP bonus rules are rules regarding purchase bonuses granted to users in response to the submission of a receipt. In this embodiment, when a user provides a receipt for a purchase CP, a fixed cashback amount set for that purchase CP is cashed back (refunded) to the user. Based on this, purchase CP bonus rules include at least information indicating a fixed cashback amount (hereinafter referred to as a "fixed cashback amount").

The receipt submission period is the period during which a receipt can be submitted at the purchase CP. Proof of purchase submitted within the receipt submission period will be eligible for purchase benefits.

Purchase rules are rules for purchasing target products. Users can receive cashback on purchase CP only if they purchase the target product in accordance with the purchase rules. Examples of purchase rules include "products with the product name XX must be purchased," "target products must be purchased at a specific store/a store in a specific chain/a store in a specific area/a specific online shop," or "specific accessories must be purchased at the same time."

Purchase CP participation rules are rules regarding participation in a purchase CP. For example, a purchase CP participation rule may state that "one user can only submit a receipt once for a purchase CP." In this embodiment, a user is considered to have participated in a purchase CP when they purchase a target product related to one purchase CP.

Post CP registration information is information related to the post CP. The post CP registration information includes information necessary for implementing the post CP, as well as information necessary for displaying the post CP outline block 32 and post CP details screen 33 described below. The post CP registration information includes at least the post CP name, target product introduction information, post CP reward rules, video posting period, video creation rules, post CP participation rules, and a group of tags corresponding to the target product.

Posted CP name is the name of the posted CP.

The contents of the target product introduction information are as described above.

The posting CP reward rules are rules for calculating the amount of posting reward awarded to users who participate in a posting CP. In this embodiment, the amount of posting reward awarded to user UX in a posting CP is calculated using the formula "number of views of short video x unit reward price." In this formula, "number of views of short video" refers to the cumulative number of views over a seven-day period, with the posting date of the short video being the first day. Furthermore, in this formula, "unit reward price" refers to the price per view. Based on this, the posting CP reward rules include a "unit reward price." Furthermore, in this embodiment, the provider is required to set a maximum total posting reward amount (hereinafter referred to as the "total reward limit") for the posting CP in the form of a reward budget. Once the total posting rewards payable to users (hereinafter referred to as the "cumulative total reward") reaches the total reward limit, the posting reward will no longer increase for all users, even if their short videos are played. Based on this, the posting CP reward rules include a "total reward limit." To elaborate on the total reward limit, for example, suppose that a posting CP has only three participants, users U1, U2, and U3, and the total reward limit is 1,000 yen. If, at a certain timing T1, user U1's reward (the reward amount derived from the number of views at timing T1) is 200 yen, user U2's reward is 100 yen, and user U3's reward is 50 yen, the cumulative total reward for users U1, U2, and U3 (350 yen) does not reach the total reward limit (1,000 yen). Therefore, there is no limit on the increase in posting rewards for users U1, U2, and U3 at timing T1. Meanwhile, suppose that at timing T2, which is later than timing T1, user U1's reward is 500 yen, user U2's reward is 300 yen, and user U3's reward is 200 yen. In this case, since the cumulative total reward amount (1,000 yen) for users U1, U2, and U3 has reached the total reward limit (1,000 yen), the posting reward amount for users U1, U2, and U3 will no longer increase.

The video submission period is the period during which short videos can be submitted to the submission CP. Short videos submitted within the video submission period are eligible for submission rewards.

The video creation rules are rules (including recommendations) regarding the content of short videos created for the target product (i.e., short videos eligible for posting rewards). For example, the video creation rules include information about scenes that must be included/are recommended to be included in the short video, information indicating the content of captions that must be included/are recommended to be included, the manner in which the target product is introduced that must be observed, prohibited words, prohibited actions, recommended words, or recommended actions. Assuming the target product is shampoo, some specific examples of the video creation rules are as follows:
- There must be a scene of shampooing hair for at least 10 seconds.
- It is recommended to include a caption with the words "refreshing" in the scene.
・In terms of the Pharmaceutical Affairs Law, the word ○○ must not be used.
Competing products must not be included in the photo.
- The scene introducing the product must take up at least one-third of the entire video.
The video creation rules are created with one consideration being whether or not they conform to the provider's policies. For example, if a provider has a policy that the content of short videos should include sufficient promotion/advertising within the short video, that the content should not be offensive to viewers, and that the length of the video should not be too short or too long, the video creation rules should be such that this policy is reflected in the content of the short video.

The post CP participation rules are rules regarding participation in a post CP. For example, a post CP participation rule may state that "one user can only post a short video in a post CP once." In this embodiment, it is considered that a user has participated in a purchase CP when the participation button on the post CP details screen 33 for one post CP is selected.

The target product tag group is a collection of one or more (basically multiple) hashtags. Campaign-related services require that the target product tag group be assigned (associated as tags) when posting a short video in a posting CP to the first SNS. The target product tag group includes a tag indicating the category to which the target product belongs (hereinafter referred to as the "target product category tag"). For example, if the target product is a commercially available shampoo containing high-alcohol content, and the categories of the shampoo are assumed to be shampoo, commercially available shampoo, and high-alcohol shampoo, the target product category tags would be "#shampoo", "#commercial shampoo", and "#high-alcohol shampoo". In addition, given that hashtags are primarily used for searches, the target product tag group may include hashtags that indicate the provider (e.g., "#○○Company" if the provider's name is ○○Company), hashtags that indicate the operator (e.g., "#△△Company" if the operator's name is △△Company), hashtags that indicate campaign-related services (e.g., "#□□Service" if the service's name is □□Service), or hashtags that indicate that the short video is related to a promotion (e.g., #PR).

Note that if the operator has rules that must be followed, the purchase CP registration information and post CP registration information are set in accordance with those rules. Of course, the provider does not have to set all of the purchase CP registration information and post CP registration information; instead, the operator can set only part of the information, or the provider and operator can work together to set it. In Figure 3, a single provider SX provides purchase CP registration information and post CP registration information to the service operator, but in reality, various providers will provide purchase CP registration information and post CP registration information for various target products. It is also permissible for a single provider to provide purchase CP registration information and post CP registration information for multiple target products at the same time. These are the details of purchase CP registration information and post CP registration information.

The provider SX provides purchase CP registration information and post CP registration information, for example, by inputting various information into a user interface provided by the provider-only app AP2. Also, for example, the provider SX provides purchase CP registration information and post CP registration information by uploading a file containing various information to the information processing server 2.

When the server information processing unit 10 receives the purchase CP registration information, it registers one record in the purchase CP management database 34 stored in the server storage unit 12. The server information processing unit 10 begins managing purchase CPs by registering a record in the purchase CP management database 34. The purchase CP management database 34 is a database for managing purchase CPs, and a record is registered for each purchase CP. Hereinafter, records in the purchase CP management database 34 will be referred to as "purchase CP management records." Figure 4 is a diagram showing the contents of a purchase CP management record. As shown in Figure 4, the purchase CP management record has the following fields: purchase CP-ID <F>, purchase CP registration information <F>, and purchase CP participation management <F>. Note that <F> is a convenient symbol indicating that the corresponding term is a field or item in which some value is stored. The purchase CP-ID <F> stores the purchase CP-ID (identification information that identifies the purchase CP) of the corresponding purchase CP. Purchase CP registration information <F> stores purchase CP registration information. Purchase CP participation <F> is described below. The server information processing unit 10 generates a unique purchase CP-ID and registers a purchase CP management record in the purchase CP management database 34, which includes the generated purchase CP-ID, the received purchase CP registration information, and appropriate initial values.

Furthermore, upon receiving the posting CP registration information, the server information processing unit 10 registers one record in the posting CP management database 35 stored in the server storage unit 12. The server information processing unit 10 begins managing posting CPs by registering a record in the posting CP management database 35. The posting CP management database 35 is a database for managing posting CPs, and a record is registered for each posting CP. Hereinafter, the records in the posting CP management database 35 will be referred to as "posting CP management records." Figure 5 is a diagram showing the contents of a posting CP management record. As shown in Figure 5, the posting CP management record has the following fields: posting CP-ID <F>, posting CP registration information <F>, posting CP participation management <F>, cumulative total reward amount <F>, limit reached flag <F>, number of related video posts <F>, number of related video views <F>, number of related video likes <F>, and category related <F>. The posting CP-ID<F> stores the posting CP-ID (identification information that identifies the posting CP) of the corresponding posting CP. The posting CP registration information<F> stores the posting CP registration information. The other fields are described below. The server information processing unit 10 generates a unique posting CP-ID and registers a posting CP management record in the purchase CP management database 35 that includes the generated posting CP-ID, the received posting CP registration information, and appropriate initial values.

Now, referring to Figure 3, the service administrator provides user UX with information introducing purchase CPs (hereinafter referred to as "purchase CP introduction information") (step S2). Specifically, the service administrator provides user UX with a screen on which user UX can view purchase CP introduction information for ongoing purchase CPs (not limited to purchase CPs of provider SX). User UX views the screen, recognizes the ongoing purchase CPs and the target products corresponding to each purchase CP, and decides to participate if there is a purchase CP that user UX would like to participate in (step S3). Here, it is assumed that user UX has decided to participate in a purchase CP related to product IX of provider SX. Note that in step S2, purchase CP introduction information is provided, but information introducing posted CPs (hereinafter referred to as "posted CP introduction information") is not provided.

After determining the purchase CP for product IX from provider SX, user UX purchases product IX in accordance with the purchase rules (step S4). At the time of purchasing product IX, the posted CP has not been introduced to user UX, and therefore user UX is unaware that the posted CP has been implemented. User UX obtains or prepares proof of purchase upon purchase. Purchase proof is data that serves as evidence that the selected target product was purchased, and is predetermined for each purchase type. For example, when a product is purchased at a physical store, the purchase proof is a photographed image (or a scanned image) of the receipt issued at the time of purchase. When a product is purchased at an online shop, the purchase proof is a receipt or a screenshot image of the purchase history page. The need for purchase proof, the contents of the purchase proof for each product type, and other matters related to the purchase proof are notified to each user in advance using a predetermined method.

After purchasing product IX, user UX submits proof of purchase using a specified user interface of the campaign-related service (step S5). The service operator accepts the submitted proof of purchase and checks the proof of purchase, primarily to determine whether product IX was purchased in accordance with the purchase rules (step S6). Hereinafter, the check performed on the proof of purchase is referred to as the "purchase check." In this example, it is assumed that the purchase check in step S6 is passed. The service operator notifies user UX of the check result indicating pass (step S7). At that time, the service operator provides user UX with posted CP introduction information (step S7). As described below, the posted CP introduction information includes a tag group corresponding to the target product. Note that if the purchase check fails, the service operator notifies user UX of the failure but does not notify user UX of the posted CP introduction information. In this case, no purchase benefits are granted to user UX. As such, in this embodiment, the posted CP is introduced only to user UX who has submitted proof of purchase and passed the purchase check—in other words, to user UX who has already purchased the target product. Therefore, the campaign-related service does not violate the Specified Commercial Transactions Act.

If the check results in a pass, the service operator grants the purchase benefit to user UX (step S8). In this embodiment, the service operator provides user UX with a fixed cashback amount in return for providing proof of purchase.

User UX recognizes the posted CP based on the posted CP introduction information and decides to participate in the posted CP (step S9). However, participation in the posted CP is optional, and of course, participation is not required. User UX who has decided to participate in the posted CP creates a short video related to product IX in accordance with the video creation rules (step S10). Next, User UX uses a specified user interface of the campaign-related service to submit the created short video (file) to the service operator (step S11).

The service operator accepts the submitted short video and reviews it, primarily based on whether it was created in accordance with the video creation rules (Step S12). Hereinafter, the review conducted on the short video will be referred to as the "video review." In this example, it is assumed that the short video passes the video review in Step S12. The service operator notifies User UX of the review result indicating a pass (Step S13). If the review result is not a pass, the service operator notifies User UX of the review result indicating a fail. In this case, the created short video will not be eligible for posting rewards, and User UX will not be able to receive posting rewards. Upon receiving the notification of passing, User UX posts the short video to the first SNS after adding a group of tags corresponding to the target product (Step S14). In response to the post, the first SNS system issues a posting URL, which User UX acquires. User UX then uploads the posting URL to the service operator using a specified user interface of the campaign-related service (Step S15).

After that, when the service operator is ready to derive the posting reward, they derive the posting reward in accordance with the posting CP reward rules (step S16). In this embodiment, the service operator derives the posting reward by multiplying the cumulative number of views of the short video over a seven-day period from when the short video was posted on the first SNS (the day it was posted is counted as day 1) by the reward unit price. After deriving the posting reward, the service operator grants the posting reward to user UX (step S17). This concludes the overview of campaign-related services.

Next, we will explain the terms related to posting CPs: the survey period, video posting period, and reward period. Figure 6 is a diagram used to explain each period. In this embodiment, a survey period, video posting period, and reward period are considered for each posting CP. The survey period for a posting CP is the period during which various surveys and information collection are conducted for that posting CP. The various surveys and information collection will be explained later. In Figure 6, the survey period runs from August 1 to August 31. The video posting period for a posting CP is the period during which users can post short videos for that posting CP. Short videos posted outside the posting period are not eligible for posting rewards. In this embodiment, as a simplified example, the start and end timings of the posting period are assumed to be fixed. However, the posting period can also be variable, with the start or end determined depending on the fulfillment of certain conditions. The survey period is assumed to be a period that at least encompasses the posting period. In Figure 6, the posting period runs from August 10 to August 20. The reward period is the period during which the number of views of a short video posted by a user is counted to derive a posting reward. The start and end times of the reward period may vary depending on the user. In this embodiment, the posting reward is determined based on the number of views over a seven-day period, with the day the short video is posted being the first day. Therefore, the reward period for a given user is the period from the day the user posted the short video to seven days later. In Figure 6, the reward period for user U1 is shown as August 10th to August 16th, and the reward period for user U2 is shown as August 15th to August 22nd.

Next, the operation of the control system 1 related to the campaign-related service will be described. In the following description of the operation of the control system 1 related to the campaign-related service, a "noted user" will be assumed as one of the users. The noted user has registered an account with the campaign-related service and can log in to that account. Logging in may be performed using login information issued specifically by the campaign-related service, or through ID linking with another service. The noted user also registers information related to their first SNS account and other information related to the first SNS in their own account. This allows the server information processing unit 10 of the information processing server 2 to access the noted user's resources held by the first SNS system via the Web API provided by the first SNS and obtain information about the noted user. The server information processing unit 10 appropriately obtains information required to send an access request (e.g., information equivalent to a usage license and registration certificate) from the first SNS system. Note that the noted user's consent has been obtained in advance in an appropriate manner before the information processing server 2 can send and receive information about the noted user via the Web API.

First, we will explain the operation of the control system 1 regarding purchase CP. Figure 7 is a flowchart showing an example of the operation of the user terminal 3 and the information processing server 2 regarding purchase CP. The symbol FA indicates the information processing method by the user terminal 3, and the symbol FB indicates the information processing method by the information processing server 2.

As shown in flowchart FA, the user launches the user-specific app AP1 on the user terminal 3 and instructs the display of the purchase CP list screen (step SA1). In response to this instruction, the user terminal information processing unit 13 cooperates with the server information processing unit 10 to display the purchase CP list screen on the user terminal display unit 15 (step SA2). The purchase CP list screen is a screen that includes a purchase CP overview block (not shown) that outlines each ongoing purchase CP. The purchase CP overview block displays information outlining the corresponding eligible product, the purchase CP benefit rules (fixed cashback amount), and the receipt submission period. However, the information displayed in this block is not limited to the example shown. For each purchase CP shown on the purchase CP list screen and each posted CP corresponding to each purchase CP, purchase CP registration information and posted CP registration information have been provided in advance by the provider, as shown in step S1 of FIG. 3, and corresponding records have been registered in the purchase CP management database 34 and the posted CP management database 35.

Each purchase CP summary block on the purchase CP list screen is selectable. If the user of interest finds a purchase CP that interests them, they select the purchase CP summary block corresponding to that purchase CP (step SA3). When a purchase CP summary block for a purchase CP is selected, the user terminal information processing unit 13 displays a purchase CP details screen 31 corresponding to that purchase CP (step SA4). Figure 8 is a diagram showing an example of the purchase CP details screen 31. As shown in Figure 8, the purchase CP details screen 31 displays information introducing the target product (reference numeral 38), purchase CP benefit rules (fixed cashback amount) (reference numeral 39), receipt submission period (reference numeral 40), purchase rules (reference numeral 41), purchase CP participation rules (reference numeral 42), and other information related to the purchase CP. The user of interest can understand the details of the purchase CP by referring to this screen. The user terminal information processing unit 13 displays the purchase CP list screen and the purchase CP details screen 31 based on the purchase CP management database 34. The information displayed in the purchase CP overview block and purchase CP details screen 31 corresponds to purchase CP introduction information.

The noted user refers to the purchase CP details screen 31 for the desired purchase CP and then decides which purchase CP to participate in. Naturally, the noted user can decide not to participate in a purchase CP, or can decide to participate in multiple purchase CPs, but in this example, the noted user has decided to participate in one purchase CP. Hereinafter, the purchase CP that the noted user has decided to participate in will be referred to as the "noteworthy purchase CP," and the target product corresponding to the noteworthy purchase CP will be referred to as the "noteworthy target product." Furthermore, the post CP corresponding to the noteworthy purchase CP (= post CP made targeting the noteworthy product) will be referred to as the "noteworthy post CP."

The noted user then purchases the noted product in accordance with the purchase rules listed on the purchase CP details screen 31 for the noted purchase CP. In this embodiment, the noted user is deemed to have participated in the noted purchase CP through this purchase. When purchasing the noted product, the user is aware that a purchase CP corresponding to the noted product is currently running, but is unaware that a posting CP corresponding to the product is currently running. After purchasing the noted product, the noted user stores data corresponding to the purchase evidence in the user terminal storage unit 17. For example, if the noted user purchases the noted product at a physical store, the noted user receives and stores the receipt. The noted user then photographs or scans the receipt to generate image data, and the image data is stored in the user terminal storage unit 17 of the user terminal 3. For example, if the user terminal 3 is a smartphone, the noted user photographs the receipt with the smartphone's camera. Then, the OS functions to register captured image data based on the captured image in the electronic album. For example, when a user of interest purchases a product of interest from an online shop, the user of interest takes a screenshot of the receipt or purchase history page to generate image data, and the image data is stored in the user terminal storage unit 17 of the user terminal 3. Hereinafter, receipts, receipts, purchase history pages, and other data corresponding to proof of purchase will be referred to as "purchase proof data." Purchase proof data corresponds to proof of purchase.

Referring to FIG. 7, after the purchase evidence data has been stored in the user terminal storage unit 17, the noted user performs the following tasks. That is, the noted user launches the user-specific app AP1 on the user terminal 3 and performs a predetermined operation to instruct the display of a screen for uploading purchase evidence data related to the noted purchase CP. This screen provides various user interfaces for uploading purchase evidence data related to the noted purchase CP to the information processing server 2. Next, the noted user uses this screen to instruct the upload of the purchase evidence data to the information processing server 2 (step SA5). In response to this instruction, the user terminal information processing unit 13 transmits (uploads) the purchase evidence data to the server information processing unit 10 (step SA6).

Upon receiving the purchase proof data, the server information processing unit 10 registers purchase CP participation unit information (step SB1). Step SB1 will be described in detail below. In this embodiment, when purchase proof is submitted for a certain purchase CP, the server information processing unit 10 manages it as a single "purchase CP participation unit." Hereinafter, the purchase CP participation unit corresponding to the target user will be referred to as the "target purchase CP participation unit." Then, in step SB1, the server information processing unit 10 first generates purchase CP participation unit information.

Figure 9 is a diagram showing an example of the contents of one piece of purchase CP participation unit information. As shown in Figure 9, the purchase CP participation unit information includes at least the following fields: purchase CP participation unit ID <F>, user ID <F>, purchase evidence <F>, and check pass/fail <F>. The purchase CP participation unit ID <F> stores the purchase CP participation unit ID (identification information for identifying the purchase CP participation unit) of the corresponding purchase CP participation unit. The user ID <F> stores the user ID (identification information for identifying the user) of the corresponding user. The purchase evidence <F> stores purchase evidence data. The check pass/fail <F> stores a check pass/fail flag for managing the check results of the purchase check on the purchase evidence. The initial value of this flag is off. In step SB1, the server information processing unit 10 generates purchase CP participation unit information including a unique purchase CP participation unit ID, the user ID of the user of interest, the received purchase evidence data, and an appropriate initial value. Next, the server information processing unit 10 additionally registers the generated purchase CP participation unit information in the purchase CP participation management <F> of the purchase CP management record corresponding to the purchase CP of interest in the purchase CP management database 34. In this way, purchase CP participation unit information for each purchase CP participation unit is stored in the purchase CP participation management <F> of the purchase CP management record. This completes the details of step SB1.

The process in which the server information processing unit 10 receives purchase proof data and registers purchase CP participation unit information including that data in the purchase CP management database 34 corresponds to "the process of accepting purchase proof as proof of purchase of the target product from the user who selected the target product." However, the specific content of the process of accepting purchase proof is not limited to the content exemplified in this embodiment. This process may be any process as long as it is a process of obtaining purchase proof.

After step SB1, the server information processing unit 10 executes a check process (step SB2). The check process checks the contents of the purchase evidence data (i.e., checks the purchase evidence). The check performed during the check process corresponds to a "purchase check." Specifically, the server information processing unit 10 uses the purchase evidence data to determine whether the target product has been purchased in accordance with the purchase rules. For example, the server information processing unit 10 converts the purchase evidence data into text using OCR technology, extracts elements necessary for the above determination from the text data (e.g., product name, product price, or purchase quantity; these elements vary depending on the purchase rules), and performs the above determination based on the extracted elements. Here, the check pass/fail <F> in the purchase CP participation unit information stores a check pass/fail flag (default value is off) for managing the check results for the purchase evidence. If the server information processing unit 10 determines that the target product has been purchased in accordance with the purchase rules, it determines the check result as pass and changes the value of the check pass/fail flag in the purchase CP participation unit information corresponding to the target purchase CP participation unit to on. Note that unless the check is passed, the flag will not be set to the on value. This concludes the details of the check process.

Regarding the check process, at least part of the process using OCR technology may be performed using AI-OCR that has been machine-learned using a specified machine learning method. In addition, in the check process, some or all of the determination of whether the target product has been purchased in accordance with the purchase rules may be performed manually. In addition to determining whether the target product has been purchased in accordance with the purchase rules, checks may also be performed from other perspectives, such as whether fraud has occurred.

After step SB2, the server information processing unit 10 notifies the noted user that the purchase check of the purchase proof has been completed (step SB3). In this embodiment, the server information processing unit 10 performs this notification via push notification using the OS functions of the user terminal 3. Information required for push notification (e.g., device identification information) is registered for each user in the user management database 30. Push notifications are sent via banners, alerts, badges, or other means. Note that the notification method is not limited to the method exemplified in this embodiment. Notification may also be sent by email or other methods.

After step SB3, the server information processing unit 10 determines whether the purchase check has been passed (step SB4). If the check has not been passed (step SB4: NO), the server information processing unit 10 terminates processing. In this case, the purchase bonus is not granted to the noted user. On the other hand, if the check has been passed (step SB4: YES), the server information processing unit 10 executes bonus granting-related processing (step SB5). Bonus granting-related processing is processing for granting a bonus to the noted user. Bonus granting-related processing only needs to be processing for granting a reward to the noted user; the granting does not have to be completed by this processing. For example, if the bonus is granted in the form of a fixed cashback amount to an electronic wallet provided to each user in a campaign-related service, the server information processing unit 10 executes processing to grant an appropriate fixed cashback amount to the wallet. Furthermore, if the bonus is granted by transferring funds to the noted user's account, the server information processing unit 10 executes processing related to the transfer. In this case, the transfer-related processing does not need to be the entire series of processes required for the transfer, but may be only part of the process. For example, if the awarding of a benefit to the noted user is carried out based on information recorded in a specified database, the server information processing unit 10 records the appropriate information in that database. For example, if the awarding of a benefit to the noted user is carried out by an operator of the management company, the server information processing unit 10 notifies the operator of the necessary information. Note that the server information processing unit 10 may also be configured to notify the noted user when the awarding of the benefit has been completed. This concludes the description of the operation of the control system 1 regarding purchase CP.

Next, we will explain the operation of the control system 1 regarding posted CPs. Figure 10 is a flowchart showing the information processing method of the user terminal 3 and the information processing server 2 regarding posted CPs. The symbol FC indicates the information processing method of the user terminal 3, and the symbol FD indicates the information processing method of the information processing server 2.

As described above, once the purchase check of the purchase evidence is completed, a push notification indicating this is sent to the user terminal 3 of the noted user. In response to the push notification, the noted user launches the user-specific app AP1 and instructs the display of the check result screen (step SC1). In response to this instruction, if the purchase check fails, the user terminal information processing unit 13 displays a failure notification screen (not shown) as the check result screen. The failure notification screen displays information indicating the failure. The screen may also be configured to display information indicating the reason for the failure. However, the failure notification screen does not display any information about the noted post CP.

On the other hand, if the purchase check is passed, the user terminal information processing unit 13, in response to the instruction of step SC1, displays a pass notification screen 43 as the check result screen (step SC2). Figure 11 is a diagram showing an example of the pass notification screen 43. As shown in Figure 11, the pass notification screen 43 displays information that the purchase check has been passed and that a purchase bonus will be granted. By referring to the pass notification screen 43, the user of interest can recognize that they have passed the purchase check and will be able to enjoy the purchase bonus.

As shown in FIG. 11, the success notification screen 43 displays information that a featured post CP is currently being held for the featured product, as well as a post CP overview block 32 introducing the featured post CP. The post CP overview block 32 displays information outlining the featured product (including the product name, price, and photo), the number of users already participating in the featured post CP, the post CP reward rules (including the reward unit price), and the corresponding SNS type. The post CP overview block 32 also displays the total reward limit, cumulative total reward amount, and remaining reward amount. As described above, the cumulative total reward amount is the total amount of posting rewards currently determined for the featured post CP. The remaining reward amount is the value obtained by subtracting the cumulative total reward amount from the total reward limit. The cumulative total reward amount <F> in the post CP management record is stored as the cumulative total reward amount. As described below, the server information processing unit 10 derives the cumulative total reward amount as appropriate and updates the cumulative total reward amount stored in the cumulative total reward amount <F> in the post CP management record.

In this way, the server information processing unit 10 has a function to notify the user of information introducing the posting campaign when notifying the user that the purchase check result has passed. Therefore, by referring to the pass notification screen 43, the user can recognize that the featured post CP is being held and that they can participate in the featured post CP. Furthermore, the server information processing unit 10 has a function to provide the user with the relationship between the total reward limit and the cumulative total reward amount before participating in the purchase CP. Therefore, the user can accurately grasp how much time is left until the cumulative total reward amount reaches the total reward limit, and can recognize how quickly they should post their short video. In other words, the user can be motivated to post a short video as soon as possible.

The posted CP outline block 32 is selectable on the success notification screen 43. If the featured user wishes to participate in the featured posted CP or wish to learn more about the featured posted CP, the featured user selects the posted CP outline block 32 (step SC3). In response to this selection, the user terminal information processing unit 13 displays the posted CP details screen 33 (step SC4). FIG. 12 is a diagram illustrating an example of the posted CP details screen 33. As shown in FIG. 12, the posted CP details screen 33 displays information introducing the featured posted CP (including information about the featured product). The posted CP details screen 33 illustrated in FIG. 12 displays "information introducing the featured product" (reference numeral 44), posted CP reward rules (reference numeral 45), video posting period (reference numeral 46), posted CP participation rules (reference numeral 47), video creation rules (reference numeral 48), and a group of tags corresponding to the target product (reference numeral 49). A notice is displayed near the group of tags corresponding to the target product stating that the hashtags included in the group of tags corresponding to the target product displayed when posting the short video must be added in order.

Note that some of the information displayed on the post CP details screen 33 (for example, a group of tags corresponding to the target product) may not be displayed on the post CP details screen 33, but may be provided by the user via other means. Furthermore, information other than the example information displayed on the post CP details screen 33 may be displayed. When displaying the post CP overview block 32 and the post CP details screen 33, the server information processing unit 10 obtains the necessary data from the post CP management database 35 and other information sources. The information displayed in the block and on the screen corresponds to post CP introduction information.

The process by which the user terminal information processing unit 13 displays the posted CP details screen 33 on the user terminal display unit 15 includes a "process of providing a group of tags corresponding to the target product."

As shown in FIG. 12, the posted CP details screen 33 displays a join button 36 that is selected when participating in a featured posted CP. In this example, the featured user wishes to participate in the featured posted CP and selects the join button 36 (step SC5). In this embodiment, each user is considered to have participated in the posted CP by selecting the join button 36. When the join button 36 is selected, the user terminal information processing unit 13 notifies the server information processing unit 10 of this (step SC6).

As shown in flowchart FD, upon receiving the notification of step SC6, the server information processing unit 10 registers post CP participation unit information (step SD1). Step SD1 will be described in detail below. In this embodiment, when an application to participate in a certain post CP is made (selection of the participation button 36), the server information processing unit 10 manages this as a single "post CP participation unit." Hereinafter, the post CP participation unit corresponding to the user of interest will be referred to as the "post CP participation unit of interest." Then, in step SD1, the server information processing unit 10 first generates post CP participation unit information.

Figure 13 is a diagram showing an example of the contents of one piece of post CP participation unit information. As shown in Figure 13, the post CP participation unit information includes the following fields: post CP participation unit ID <F>, user ID <F>, short video <F>, review result <F>, post URL <F>, reward eligible plays <F>, provisional reward amount <F>, final reward amount <F>, unit plays <F>, and unit likes <F>. The post CP participation unit ID <F> stores the post CP participation unit ID (identification information for identifying the post CP participation unit) of the corresponding post CP participation unit. The user ID <F> stores the user ID of the corresponding user. Other fields will be described later.

In step SD1, the server information processing unit 10 generates posting CP participation unit information including a unique posting CP participation unit ID, the user ID of the noted user, and an appropriate initial value. Next, the server information processing unit 10 additionally registers the generated posting CP participation unit information in the posting CP participation management <F> of the posting CP management record corresponding to the noted posting CP in the posting CP management database 35. In this way, posting CP participation unit information is stored for each posting CP participation unit in the posting CP participation management <F> of the posting CP management record. This concludes the details of step SD1.

After selecting the participation button 36 and participating in the featured post CP, the featured user performs the following tasks. That is, the featured user creates a short video in accordance with the video creation rules. For simplicity's sake, in this embodiment, the video file in which the short video is recorded will also be referred to as a "short video." Hereinafter, short videos created by featured users will be referred to as "featured short videos." The content of short videos that comply with the video creation rules will basically introduce or promote/advertise a product by showing the product's appearance, a user using the product, or providing a verbal explanation of the product.

Referring to Figure 10, after creating the featured short video, the featured user performs the following tasks. That is, the user launches the user-specific app AP1 on the user terminal 3 and performs a predetermined operation to instruct the display of a screen for uploading a short video related to the featured post CP. This screen provides various user interfaces for uploading the short video related to the featured post CP to the information processing server 2. Next, the user uses this screen to instruct the information processing server 2 to upload the featured short video (step SC7). In response to this instruction, the user terminal information processing unit 13 transmits (uploads) the featured short video to the server information processing unit 10 (step SC8).

When the server information processing unit 10 receives the featured short video, it executes the following process (step SD2). That is, the server information processing unit 10 stores the featured short video in the short video <F> (Figure 13) of the post CP participation unit information corresponding to the featured post CP participation unit in the post CP management database 35. The process in which the server information processing unit 10 receives the short video and stores it in a specified field corresponds to the "process of accepting content for posting to SNS, created for the target product by a featured user who has passed the check." However, the specific content of the accepting process is not limited to the process exemplified in this embodiment, and may be any process that acquires a short video (content).

After step SD2, the server information processing unit 10 executes a video review process (step SD3). The video review process is a process for reviewing the content of uploaded short videos. Specifically, the provider (or the operator, or both the provider and the operator) manually reviews the uploaded short videos. The video review primarily focuses on whether the content of the short video complies with the video creation rules. As mentioned above, the video creation rules are created with compliance with the provider's policies as one of the criteria. Therefore, short videos with content that does not comply with the provider's policies will not pass the video review and will be rejected. Of course, the review may also consider other criteria in addition to compliance with the video creation rules. Furthermore, some or all of the video review may be performed automatically by the server information processing unit 10 (or another information processing unit).

After the video review is completed, the provider notifies the server information processing unit 10 of the results. This notification is made, for example, by entering the video review results into a user interface provided by the server information processing unit 10. Here, the review pass/fail <F> of the post CP participation unit information stores a review pass/fail flag (default value is off) for managing the review results of the video review. If the video review results in a pass, the server information processing unit 10 changes the value of the review pass/fail flag of the post CP participation unit information corresponding to the featured post CP participation unit to an on value. Note that this flag will not be set to an on value unless the video passes the review. This completes the details of the video review process.

After step SD3, the server information processing unit 10 notifies the noted user of the results of the video review (step SD4). The notification may be made by any method as long as the noted user is ultimately made aware of the results of the video review. For example, the notification may be made by push notification or email. The processing of step SD4 corresponds to the "process of notifying the user of the review results of the content review." The noted user becomes aware of the results of the video review in response to the notification of step SD4. If the noted short video does not pass the video review, the noted short video will not be eligible for a posting reward, and therefore the noted user will not be able to receive a posting reward as compensation for posting the noted short video. On the other hand, if the video review passes, the noted user posts the noted short video to the first SNS. At that time, the noted user tags the noted short video with a group of tags corresponding to the target product related to the noted post CP before posting. In response to the post, a posting URL is issued by the first SNS system, and the noted user obtains the posting URL.

After obtaining the posting URL, the noted user performs the following tasks. That is, the noted user launches the user-specific app AP1 on the user terminal 3 and performs a predetermined operation to display a screen for notifying the posting URL. This screen provides various user interfaces for notifying the information processing server 2 of the posting URL related to the noted posting CP. The noted user uses this screen to instruct the information processing server 2 to notify the posting URL (step SC9). In response to this instruction, the user terminal information processing unit 13 transmits the posting URL to the server information processing unit 10 (step SC10). Upon receiving the notification of the posting URL, the server information processing unit 10 executes the following process (step SD5). That is, the server information processing unit 10 stores the posting URL in the posting URL<F> (Figure 13) of the posting CP participation unit information corresponding to the noted posting CP participation unit in the posting CP management database 35.

Then, the server information processing unit 10 executes the following process for each featured post CP participation unit. That is, the server information processing unit 10 acquires the daily number of plays (views) of the featured short video and the daily number of likes for the featured short video from the first SNS system for each day from the posting date through the last day of the survey period. The daily number of plays of the short video means the total number of times the short video was played (viewed) in one day (1 day). Hereinafter, this number of plays will be referred to as the "daily unit number of plays." Furthermore, the daily number of likes for the short video means the total number of "likes" given to the short video in one day. Hereinafter, this number of likes will be referred to as the "daily unit number of likes." The server information processing unit 10 acquires the daily unit number of plays and the daily unit number of likes for a given day at a predetermined timing after they become available.

Here, unit view count information is stored in the unit view count <F> (Figure 13) of the posting CP participation unit information. The unit view count information stores the daily total unit view count associated with the date. Furthermore, unit likes <F> (Figure 13) of the posting CP participation unit information stores unit likes information. The unit likes information stores the daily total unit likes associated with the date. Each time the server information processing unit 10 obtains the daily total unit view count, it updates the unit view count information to reflect this, and similarly, each time it obtains the daily total unit likes, it updates the unit likes information to reflect this. As a result, the unit view count information for the featured short video will record the daily total unit view count for each day from the posting date to the last day of the survey period. Furthermore, the unit likes information for the featured short video will record the daily total unit likes for each day from the posting date to the last day of the survey period.

The server information processing unit 10 acquires the daily unit number of plays and the daily unit number of likes using a web API provided by the first SNS. In doing so, the server information processing unit 10 uses the posting URL of the featured short video as "information identifying the featured short video" to be included as a parameter (query) in the web API. As mentioned above, the server information processing unit 10 has the authority to access the resources of the featured user via the web API. Note that the server information processing unit 10 may not acquire the daily unit number of plays itself from the first SNS, but may instead acquire information necessary to derive the daily unit number of plays and use this to derive the daily unit number of plays. The same applies to the daily unit number of likes and other information. In the following, the server information processing unit 10 acquires information from the first SNS using a web API provided by the first SNS or some other method as appropriate, and the acquisition method will not be mentioned.

Furthermore, the server information processing unit 10 periodically acquires the number of reward-eligible plays for the target user during the reward period and uses the acquired number of reward-eligible plays to derive a provisional reward amount. The number of reward-eligible plays is the number of plays eligible for posting rewards, and is, in principle, the cumulative number of plays during the reward period. However, as described above and explained in detail below, if the cumulative total reward amount exceeds the total reward limit, the increase in the total video reward amount is limited. Therefore, the server information processing unit 10 will not increase the number of reward-eligible plays, even during the reward period, after the cumulative total reward amount exceeds the total reward limit (if the limit reached flag in the corresponding posting CP management record is on, as described below). The provisional reward amount is the number of reward-eligible plays multiplied by the reward unit price. In other words, the provisional reward amount is a provisional reward amount. As described above, any method can be used to acquire the number of reward-eligible plays. The number of reward-eligible plays <F> in the posting CP participation unit information is stored as the number of reward-eligible plays, and the provisional reward amount <F> is stored as the provisional reward amount. The server information processing unit 10 obtains the number of reward-eligible plays and updates the number of reward-eligible plays and provisional reward amount in the post CP participation unit information each time a provisional reward amount is derived.

Referring to flowchart FD in FIG. 10, the server information processing unit 10 monitors whether it is time to derive the reward amount for the noted user (step SD6). This timing is basically the timing after the reward period for the noted user has elapsed. If this timing has arrived (step SD6: YES), the server information processing unit 10 executes a reward amount derivation process (step SD7). This process derives the reward amount of the posting reward to be awarded to the noted user. The server information processing unit 10 acquires the necessary information and then derives the reward amount in accordance with the reward rules. To describe the process in detail in this embodiment, the server information processing unit 10 acquires a provisional reward amount corresponding to the noted post CP participation unit from the posting CP management database 35 and sets this as the final reward amount. The finalized reward amount is stored in the determined reward amount <F> of the posting CP participation unit information. After deriving the reward amount, the server information processing unit 10 stores the derived reward amount in the reward amount <F> of the posting CP participation unit information corresponding to the noted post CP participation unit. As mentioned above, the provisional reward amount is calculated by multiplying the number of views during the reward period by the reward unit price. In this way, the server information processing unit 10 according to this embodiment has the function of deriving the reward by multiplying the number of views of the target product-related content on SNS during a certain period by the reward unit price corresponding to the post CP.

After step SD7, the server information processing unit 10 executes reward-granting related processing (step SD8). The reward-granting related processing is processing for granting a posting reward to the noted user. Like the bonus-granting related processing, the reward-granting related processing only needs to be processing for granting a posting reward to the noted user, and the granting does not have to be completed by this processing. The processing of steps SD7 and SD8 corresponds to "processing for deriving a reward for posting content and granting the reward to the user after content is posted to SNS by a user who has passed the screening." This concludes the description of the operation of the control system 1 regarding posting CP.

As described above, the server information processing unit 10 and the user terminal information processing unit 13 have the functionality to provide the campaign-related services described above. This provides the following benefits. Specifically, with the above configuration, users can earn posting rewards (rewards) by using the campaign-related services implemented by the functions of the information processing system to post content related to products provided by providers to SNS. This meets the needs of providers who want to create an environment in which general contributors actively create product-related content and post it to SNS. Furthermore, with the above configuration, in order to receive posting rewards for posting content in the campaign-related services implemented by the functions of the information processing system, users must submit proof of purchase of the product and pass a check (purchase check) conducted on the proof of purchase. Therefore, content posted using the campaign-related services is created by users who actually purchased and used the product. This meets the needs of providers who want content created by actual purchasers of the product to be posted to SNS. Furthermore, with the above configuration, the campaign-related services implemented by the functions of the information processing system screen content, and content that passes the screening is eligible for rewards. This makes it possible to eliminate content that does not comply with the provider's policies during the review process, meeting the provider's needs to ensure that only content that complies with the provider's policies is posted.

<Example of operation of control system 1 regarding total remuneration upper limit>
Next, an example of the operation of the control system 1 regarding the total reward limit will be described. As described above, in this embodiment, the total reward limit for a posting CP is defined based on the reward budget set by the provider. The server information processing unit 10 has a function to limit the increase in each user's posting reward if the cumulative total reward for the posting CP exceeds the total reward limit. In other words, once the total posting reward to be paid to each user reaches the total reward limit, the posting reward will no longer increase for all users, even if their short videos are played. Below, the operation of the control system 1 regarding the above points will be described, focusing on one posting CP.

Symbol FE in Figure 14 is a flowchart showing an example of the operation of the information processing server 2. As shown in Figure 14, the server information processing unit 10 monitors whether the measurement timing has arrived (step SE1). The measurement timing refers to the timing for measuring the cumulative total reward amount. The measurement timing may be a periodic timing (for example, every minute, every hour, every six hours, or every day), or may be a predetermined timing. When it is determined that the measurement timing has arrived (step SE1: YES), the server information processing unit 10 derives the cumulative total reward amount (step SE2). In step SE2, the server information processing unit 10 derives the cumulative total reward amount by adding up the provisional reward amounts of each user participating in the posting CP. However, any method for deriving the cumulative total reward amount may be used. The cumulative total reward amount <F> in the posting CP management record is stored as the cumulative total reward amount. The server information processing unit 10 updates the cumulative total reward amount <F> to an appropriate value each time the cumulative total reward amount is calculated.

After step SE2, the server information processing unit 10 determines whether the cumulative total reward amount exceeds the total reward upper limit (step SE3). If it does not (step SE3: NO), the server information processing unit 10 proceeds to step SE1. On the other hand, if the cumulative total reward amount exceeds the total reward upper limit (step SE3: YES), the server information processing unit 10 limits the increase in the posting reward for each user thereafter (step SE4). Specifically, the server information processing unit 10 changes the upper limit reached flag of the appropriate posting CP management record in the posting CP management database 35 to an ON value. If the upper limit reached flag is ON, the server information processing unit 10 does not increase the reward-eligible views for each user. Therefore, by changing the upper limit reached flag to an ON value, the increase in the posting reward is limited.

The above configuration can motivate users to participate in the posting CP as soon as possible, thereby activating the posting CP.

<Example of operation of control system 1 in information provision service>
Next, the operation of the control system 1 in the information provision service will be described. First, the operation of the information processing server 2, which is a prerequisite for providing the information provision service, will be described. In the following description, a short video related to a target product posted to the first SNS using a campaign-related service will be referred to as a "target product-related short video" (target product-related content).

The above describes an example in which a featured user posts a featured short video about a featured product related to a featured post CP to the first SNS using the flowchart in Figure 10. In a campaign-related service, a large number of users will post short videos to the first SNS for each post CP. Then, for each post CP, the server information processing unit 10 acquires the daily number of target product-related short videos posted (hereinafter referred to as the "daily number of related video posts"), the daily number of views of target product-related short videos (hereinafter referred to as the "daily number of related video views"), and the daily number of likes for target product-related short videos (hereinafter referred to as the "daily number of related video likes") for each post CP on a daily basis during the survey period. The daily number of related video posts refers to the total number of target product-related short videos posted in one day. For example, suppose that target product-related short videos M1, M2, and M3 are posted by multiple different users for a certain post CP on a given day. In this case, the number of daily related video posts for that posting CP for that day is "3." As described above, in a posting CP, the posting URL is notified to the server information processing unit 10 in response to a user posting a short video. Based on this, the server information processing unit 10 counts the number of such notifications in one day for each posting CP and obtains the number of daily related video posts for each posting CP. However, the method of obtaining this number of posts is not limited to the method illustrated above.

The daily related video views refer to the total number of times the target product-related short videos were played (viewed) in a single day. For example, suppose target product-related short videos M1, M2, and M3 are posted for a certain posted CP, and on a single day, video M1 is played three times, video M2 is played five times, and video M3 is played four times. In this case, the daily related video views for that posted CP for that single day would be 12 (3 + 5 + 4). As described above, the posted CP management database 35 manages the daily unit views for each posted CP participation unit. Therefore, the server information processing unit 10 obtains the daily related video views by adding up the daily unit views for the corresponding posted CP participation units. However, the method for obtaining the view count is not limited to the method illustrated above. The daily related video likes refer to the total number of likes given to the target product-related short videos in a single day. For example, suppose that short videos M1, M2, and M3 related to a target product are posted for a certain post CP, and on a given day, video M1 received 8 likes, video G2 received 5 likes, and video G3 received 6 likes. In this case, the total number of daily related video likes for that post CP for that day is 19 (8 + 5 + 6). As described above, the post CP management database 35 manages the number of daily likes for each post CP participation unit. Therefore, the server information processing unit 10 obtains the total number of daily related video likes by adding up the total number of daily likes for each appropriate post CP participation unit. However, the method of obtaining the number of likes is not limited to the method described above. The server information processing unit 10 obtains the total number of daily related video posts, the total number of daily related video views, and the total number of daily related video likes for a given day at a predetermined timing after these data become available.

Here, the number of related video posts <F> (Figure 5) in the posted CP management record stores related video post count information. The related video post count information stores the daily number of related video posts associated with the date. The server information processing unit 10 updates the related video post count information to reflect the daily number of related video posts obtained, in accordance with the acquisition of the daily number of related video posts. As a result, the information stores the daily number of related video posts for each day during the survey period. Also, the number of related video views <F> (Figure 5) in the posted CP management record stores related video play count information. The related video play count information stores the daily number of related video plays associated with the date. The server information processing unit 10 updates the related video play count information to reflect the daily number of related video views obtained, in accordance with the acquisition of the daily number of related video plays. As a result, the information stores the daily number of related video plays for each day during the survey period. Also, the number of related video likes <F> (Figure 5) in the posted CP management record stores related video like count information. The related video like count information records the daily related video like count in association with the date. The server information processing unit 10 updates the related video like count information to reflect the daily related video like count obtained. As a result, the information records the daily related video like count for each day during the survey period.

Furthermore, for each target product category tag in relation to the posting CP, the server information processing unit 10 acquires the daily number of posts (hereinafter referred to as the "daily category video posting count"), the daily number of views (hereinafter referred to as the "daily category video views"), and the daily number of likes (hereinafter referred to as the "daily category video likes") of short videos tagged with each tag for each day during the survey period. Note that a short video tagged with a target product category tag refers to a short video tagged with that target product category tag in the first SNS, regardless of whether it was posted using a posting CP. For example, a short video tagged with #shampoo refers to a short video tagged with #shampoo in the first SNS, regardless of whether a posting CP was used.

For example, suppose the target product tag group for a target product is #XX Company, #△△ Company, #□□ Service, #PR, #Shampoo, #Commercial Shampoo, and #High-Alcohol-Based Shampoo. Of these, #Shampoo, #Commercial Shampoo, and #High-Alcohol-Based Shampoo are the category tags to which the target product belongs. In this case, the server information processing unit 10 obtains the daily number of category video posts, the daily number of category video views, and the daily number of category video likes for each of #Shampoo, #Commercial Shampoo, and #High-Alcohol-Based Shampoo. Here, the daily number of category video posts for #Shampoo on a given day refers to the total number of short videos posted to the first SNS with the #Shampoo tag attached on that day. The short videos are not limited to short videos related to the target product. Furthermore, the daily number of category video views for #Shampoo on a given day refers to the total number of views for each of the short videos with the #Shampoo tag attached on that day. Additionally, the total number of likes for #shampoo daily category videos on a given day refers to the total number of "likes" given to short videos related to #shampoo on that day.

The server information processing unit 10 acquires the daily number of category video posts, daily number of category video views, and daily number of category video likes at a predetermined timing after this information becomes available. The server information processing unit 10 also acquires this information using a web API related to the first SNS. However, the method for acquiring this information is not limited; for example, if a tool or service that can acquire this information is provided, the server information processing unit 10 may be configured to acquire this information using the tool or service.

Furthermore, the server information processing unit 10 derives the daily post count category share, daily view count category share, and daily like count category share for each category tag of the target product for the posted CP on a daily basis during the survey period. The daily post count category share for a given day (1 day) is calculated using the following formula F1:
(Formula F1) Category share of total daily posts for that day = total daily related video posts for that day / total daily category video posts for that day As shown in formula F1, the category share of total daily posts indicates the proportion of the number of short videos posted related to the target product in a certain category to the total number of posts related to that category.
The share of a category in the total number of daily plays for one day can be calculated using the following formula F2.
(Formula F2) Category share of total daily views for that day = total daily related video views for that day / total daily category video views for that day As shown in formula F2, the category share of total daily views indicates the proportion of views of short videos related to the target product in a certain category to the total number of views for that category.
The daily total likes category share for one day can be calculated using the following formula F3.
(Equation F3) Category share of total daily likes for that day = total daily related video likes for that day / total daily category video likes for that day As shown in equation F3, the category share of total daily likes indicates the proportion of likes for short videos related to the target product in a certain category to the total number of likes for that category.
Hereinafter, the category share of daily posts, the category share of daily views, and the category share of daily likes will be collectively referred to as the "category share." As shown in formulas F1 to F3, the category share is "the ratio of the index value of a predetermined index related to posts, views, or engagement of content related to the target product to the index value of a predetermined index related to posts, views, or engagement of content tagged with the category belonging to the target product."

Here, the category related <F> (Figure 5) of the posting CP management record has a category management <F> (first category management <F>, second category management <F>, ..., Nth category management <F>) field for each category tag to which the target product belongs. Category management <F> stores category video post count information, category video view count information, category video like count information, post count category share information, view count category share information, and like count category share information. Each piece of information is associated with a date and stores the daily category video post count, daily category video view count, daily category video like count, daily post count category share, daily view count category share, and daily like count category share. The server information processing unit 10 appropriately updates the category video post count information to reflect the daily category video post count obtained. Other information is updated in a similar manner. The above is the processing performed by the server information processing unit 10 as a prerequisite for providing the information provision service.

Next, we will explain the sales status management database 50 stored in the server storage unit 12. The sales status management database 50 has a record for each posted CP. Hereinafter, one record in the sales status management database 50 is referred to as a sales status management record. Figure 15 (A) is a diagram showing the contents of a sales status management record. As shown in Figure 15 (A), the sales status management record has the fields Posted CP-ID<F> and Sales Status Management<F>. Posted CP-ID<F> stores the posted CP-ID of the corresponding posted CP. Sales status management<F> stores measurement range-specific information for each measurement range. A measurement range refers to the range in which the sales quantity and sales amount of a target product are managed together. The sales quantity of a target product is the number of units sold or the sales volume of the target product. For example, assume that there are at least stores JP1, JP2, JP3, JP4, and JP5 that sell the target product, and that stores JP1 to JP4 are physical stores and store JP5 is an online shop. Furthermore, stores JP1 and JP2 belong to region AR1, stores JP3 and JP4 belong to region AR2, and stores JP1 and JP4 are affiliated stores of chain KR1. In such a case, each of stores JP1 to JP5 could be a measurement range. Alternatively, all stores could be a measurement range. In this case, the total sales quantity of the target product at stores JP1 to JP5 would be the "sales quantity in the measurement range (all stores)," and the total sales amount of the target product at all stores would be the "sales in the measurement range (all stores)." Alternatively, region AR1 (stores JP1 and JP2), region AR2 (stores JP3 and JP4), and chain KR1 (stores JP1 and JP4) could each be a measurement range. The above are examples of several measurement ranges, but these are merely examples, and the measurement range is not limited to the examples. Furthermore, the measurement range is basically set by the provider.

Figure 15 (B) is a diagram showing the contents of the information by measurement range. As shown in Figure 15 (B), the measurement range information has the following fields: measurement range ID <F>, measurement range name <F>, sales quantity <F>, and sales amount <F>. The measurement range ID <F> stores the measurement range ID (identification information) of the corresponding measurement range. The measurement range name stores the name assigned to the corresponding measurement range. The sales quantity <F> stores measurement range sales quantity information. This information stores daily measurement range sales quantity information associated with the date for each day belonging to the survey period. This information is the daily sales quantity of the target product in the measurement range (as mentioned above, if the measurement range spans multiple stores, it is the sum of the sales quantities of multiple stores). Sales amount <F> stores measurement range sales information. This information stores daily measurement range sales information associated with the date for each day belonging to the survey period. This information is the daily sales amount in the measurement range (as mentioned above, if the measurement range spans multiple stores, this is the total sales amount from multiple stores).

Hereinafter, the number of daily related video posts (indicator), the number of daily related video views (indicator), the number of daily related video likes (indicator), the category share of daily posts (indicator), the category share of daily views (indicator), and the category share of daily likes (indicator) are collectively referred to as "SNS-related indicators." Note that <indicator> is a convenient symbol indicating that the corresponding term is (the name of) an indicator with a value (index value). The number of daily related video posts (indicator) and the category share of daily posts (indicator) are SNS-related indicators related to the "posting" of content related to the target product. Furthermore, the number of daily related video views (indicator) and the category share of daily views (indicator) are SNS-related indicators related to the "viewing" of content related to the target product. Furthermore, the number of daily related video likes (indicator) and the category share of daily likes (indicator) are SNS-related indicators related to the "engagement" of content related to the target product.

In the following explanation, the daily measurement range sales volume <indicator> and the daily measurement range sales volume <indicator> are collectively referred to as "sales-related indices." Both the daily measurement range sales volume <indicator> and the daily measurement range sales volume <indicator> correspond to indices related to the sales (sales performance) of the target product. In the following explanation, the daily post count category share <indicator>, the daily view count category share <indicator>, and the daily like count category share <indicator> are collectively referred to as "category share <indicator>."

Next, an example of the operation of the control system 1 in an information provision service will be described. Simply put, the information provision service is a service that provides the relationship between the posting, viewing, or engagement status of target product-related content posted for a post CP and the sales status of the target product. In the information provision service, the provider is provided with a transition relationship screen 51 and a correlation screen 52, broadly speaking. First, the operation of the control system 1 related to the transition relationship screen 51 will be described below. The provider launches the provider-specific app AP on the provider terminal 4 and instructs the display of the transition relationship screen 51. The provider has registered an account with the information provision service and logs in to that account as necessary. The server information processing unit 1 also authenticates the provider and appropriately performs other necessary processing as necessary.

In response to an instruction to display the transition relationship screen 51, the provider terminal information processing unit 18 works in cooperation with the server information processing unit 10 to display the initial state transition relationship screen 51 on the provider terminal display unit 20. FIG. 16 is a diagram showing the initial state transition relationship screen 51. Here, the transition relationship screen 51 displays a diagram showing the relationship between the trend in the index values of SNS-related indicators and the trend in the index values of sales-related indicators for the measurement range specified by the provider for the specified posting CP during the period (but within the survey period). As shown in FIG. 16, the transition relationship screen 51 has a transition relationship input area 53. The transition relationship input area 53 has an input field 54 for entering the posting CP, an input field 55 for entering the period, an input field 56 for entering the SNS-related indicator, an input field 57 for entering the measurement range, and an input field 58 for entering the sales-related indicator.

For each input field, a value can be selected from a pull-down menu, and the pull-down menu displays all selectable values. For input field 54, a pull-down menu listing the names of posted CPs is displayed. The provider enters information into each input field on the transition relationship screen 51 and selects the confirm button 59 to confirm the input. Hereinafter, a posted CP designated by a provider will be referred to as a "designated posted CP," a designated period will be referred to as a "designated period," a designated SNS-related indicator will be referred to as a "designated SNS-related indicator," a designated measurement range will be referred to as a "designated measurement range," and a designated sales-related indicator will be referred to as a "designated sales-related indicator." The same applies to the correlation screen 52, described below.

When it detects that the Confirm button 59 has been selected, the server information processing unit 10 executes the following process. That is, the server information processing unit 10 references the posting CP management database 35 and obtains the index value of the designated SNS-related index belonging to the designated period for the designated posting CP. For example, suppose the designated posting CP is designated posting CP (CX), the designated period is 8/1 to 8/31, and the designated SNS-related index is the daily number of related video posts <index>. In this case, the server information processing unit 10 references the related video post count information in the posting CP management record corresponding to the designated posting CP (CX) and obtains each of the daily numbers of related video posts belonging to the designated period.

Furthermore, the server information processing unit 10 references the sales status management database 50 and obtains the index values of the designated sales-related indicators for the designated measurement range belonging to the designated period for the designated post CP. For example, suppose the designated post CP is designated post CP (CX), the designated period is 8/1 to 8/31, the designated measurement range is "Area A," and the designated sales-related indicator is daily measurement range sales quantity <index>. In this case, the server information processing unit 10 references the "measurement range sales quantity information corresponding to Area A" in the sales status management record corresponding to the designated post CP (CX) and obtains each of the daily measurement range sales quantities belonging to the designated period.

The server information processing unit 10 then generates display data for displaying a transition relationship screen 51 on which a transition relationship graph 60 showing the relationship between the transition in index values of SNS-related indexes and the transition in index values of sales-related indexes is displayed. Specific examples of this graph will be described later. The server information processing unit 10 then transmits the display data to the provider terminal information processing unit 18. The provider terminal information processing unit 18 receives the display data and displays the transition relationship graph 60 on the transition relationship screen 51 based on the display data.

Figure 17 is a diagram showing an example of a trend relationship graph 60. The trend relationship graph 60 is a composite graph that shows, on the same time axis, the trend in the index value of a SNS-related index related to the SNS situation and the trend in the index value of a sales-related index related to the sales situation. Figure 17 shows an example of a trend relationship graph 60 when the designated SNS-related index is the "number of daily related video posts" and the designated sales-related index is the "daily sales volume within the measurement range." The trend relationship graph 60 clearly indicates the period during which posting is permitted. In the trend relationship graph 60 of Figure 17, the trend in the daily sales volume within the measurement range during the designated period is shown by a bar graph, and the trend in the number of daily related video posts is shown by a line graph on the same time axis. By referring to the trend relationship graph 60 illustrated in Figure 17, providers can visually and intuitively grasp the relationship between the trend in the number of daily related video posts and the trend in the daily sales volume within the measurement range. This allows providers to accurately understand the impact that the number of short videos posted related to the target product has on the actual sales volume of the target product, as well as the causal relationship between the number of daily related videos posted and the daily sales volume measured. Providers can then use the knowledge gained here in future promotion/advertising strategies for the product.

Providers can freely change various elements by changing the information entered in the trend-related input area 53. In particular, providers can freely change the SNS-related indicators and sales-related indicators. This allows providers to refer to the relationship between the trends in the indicator values of various combinations of SNS-related indicators and sales-related indicators, and based on this relationship, they can understand the relationship between SNS status and sales status, the impact of one on the other, and the causal relationship between one and the other. In particular, SNS-related indicators include category share (indicator). Here, the daily post count category share (indicator) is the proportion (share rate) of short videos related to the target product that introduce or promote/advertise the target product among short videos related to the category to which the target product belongs. It can be said to be an important indicator in that it reflects the trends/status of short videos in the same category. The same applies to the daily view count category share (indicator) and the daily like count category share (indicator). In this embodiment, the information provision service allows providers to understand the relationship between the trends in the indicator values of such important indicators and the trends in the indicator values of sales-related indicators, providing great convenience to providers. The same advantage in terms of category occupancy rate applies to the correlation screen 52.

The transition relationship graph 60 is information showing "the relationship between the SNS status, which indicates the status of posting, viewing, or engagement of target product-related content, which is content related to the target product posted to SNS using the campaign-related service (posting CP), and the sales status, which indicates the sales status of the target product," "the relationship between the trends in the index values of SNS-related indicators related to posting, viewing, or engagement of target product-related content and the trends in the index values of sales-related indicators related to sales of the target product," and "the relationship between the trends in category share and the trends in the index values of sales-related indicators related to sales of the target product." The process by the provider terminal information processing unit 18 of displaying the transition relationship screen 51 (particularly the transition relationship graph 60) on the provider terminal display unit 20 corresponds to the process of providing the provider with the relationship between the SNS status and sales status.

In this embodiment, when posting a short video related to a target product in a posting CP, it is mandatory to add a group of tags corresponding to the target product, and this group of tags corresponding to the target product includes a category tag to which the target product belongs. Therefore, this category tag to which the target product belongs can be effectively used to derive an accurate category share.

Next, the operation of the control system 1 regarding the correlation screen 52 will be described. In response to instructions from the provider, the provider terminal information processing unit 18 works in cooperation with the server information processing unit 10 to display the correlation screen 52 on the provider terminal display unit 20. Figure 18 is a diagram showing the correlation screen 52 in its initial state. Here, the correlation screen 52 displays the correlation between the index value of a specified SNS-related index and the index value of a specified sales-related index for a posted CP specified by the provider. As shown in Figure 18, the correlation screen 52 has a correlation input area 62. This area has an input field 63 for entering the posted CP, an input field 64 for entering the SNS-related index, an input field 65 for entering the measurement range, and an input field 66 for entering the sales-related index. The provider enters information into each input field in this area and selects the confirm button 67 to confirm the input.

When it detects that the Confirm button 67 has been selected, the server information processing unit 10 executes the following process. That is, the server information processing unit 10 references the post CP management database 35 and obtains the index values of the designated SNS-related indicators that belong to the survey period for the designated post CP. The server information processing unit 10 further references the sales status management database 50 and obtains the index values of the designated sales-related indicators that belong to the survey period for the designated post CP. Next, the server information processing unit 10 generates a combination of the index values of the designated SNS-related indicators and the index values of the designated sales-related indicators for each day that belongs to the survey period. Hereinafter, each of these combinations will be referred to as a "plot value," and a set of plot values will be referred to as a "plot value set." For example, if the survey period is August 1 to August 31, 2024, the designated SNS-related indicator is the daily view count category share <indicator>, and the designated sales-related indicator is the daily measurement range sales volume <indicator>, the server information processing unit 10 obtains the "daily view count category share and daily measurement range sales volume on August 1" (plotted values), the "daily view count category share and daily measurement range sales volume on August 2" (plotted values), etc. The server information processing unit 10 then eliminates outliers and plot values that meet the exclusion conditions. The rules for identifying outliers and the exclusion conditions are determined in advance with the aim of obtaining an appropriate correlation. For example, an exclusion condition is that when the SNS-related indicator is the daily post count category share <indicator>, "the daily post count category share is below a certain value."

The server information processing unit 10 generates display data for displaying the correlation screen 52 on which a correlation table 68 showing the correlation between the index values of SNS-related indicators and the index values of sales-related indicators is displayed. Specific examples of graphs will be described later. The server information processing unit 10 then transmits the display data to the provider terminal information processing unit 18. The provider terminal information processing unit 18 receives the display data and displays the correlation table 68 on the correlation screen 52 based on the display data.

Figure 19 is a diagram showing an example of a correlation table 68. The correlation table 68 shows the correlation between the index values of SNS-related indicators related to SNS status and the index values of sales-related indicators related to sales status. Specifically, the correlation table 68 displays a scatter plot in which plot values consisting of combinations of index values are plotted, and an approximation curve is displayed within the scatter plot. Figure 19 shows an example of a correlation table 68 in which the designated SNS-related indicator is the daily view count category share and the designated sales-related indicator is the daily measurement range sales volume. The correlation table 68 in Figure 19 displays a scatter plot of the daily view count category share and the daily measurement range sales volume, and an approximation curve is displayed on the scatter plot. By referring to the correlation table 68 shown in Figure 19, providers can visually and intuitively grasp the correlation between the daily view count category share and the daily measurement range sales volume. This allows providers to accurately understand the impact that the size of the daily view count category share has on the actual sales volume of the target product, as well as the causal relationship between the daily view count category share and the daily measured range sales volume. Providers can then use the knowledge gained here in future product promotion/advertising strategies.

Now, providers can freely change various elements by changing the information input into the correlation input area 62. This allows providers to understand the relationship between SNS status and sales status, the impact one has on the other, and the causal relationship between one and the other for various combinations of SNS-related indicators and sales-related indicators. In particular, SNS-related indicators include category share <indicator>. As mentioned above, these indicators are important, and that this embodiment makes it possible to derive accurate values for these indicators.

The correlation table 68 is information showing the "relationship between the SNS status, which indicates the status of posting, viewing, or engagement of target product-related content, which is content related to the target product posted to SNS using campaign-related services (posting CP), and the sales status, which indicates the sales status of the target product," "the correlation between the index values of SNS-related indicators and the index values of sales-related indicators," and "the correlation between the category share and the index values of sales-related indicators." The process by the provider terminal information processing unit 18 of displaying the correlation screen 52 (particularly the correlation table 68) on the provider terminal display unit 20 corresponds to the process of providing the provider with the relationship between the SNS status and the sales status.

In this embodiment, the plotted values were combinations of index values of SNS-related indicators and sales-related indicators on the same day. In this regard, the plotted values may also be combinations of index values of SNS-related indicators and sales-related indicators that are separated by a certain amount.

As described above, according to this embodiment, providers are provided with information on the relationship between the status of posting, viewing, or engagement of content related to a product posted to SNS using campaign-related services (posting CP) and the status of product sales. Therefore, providers can recognize the relationship between the status of content posting, viewing, or engagement and the status of product sales, and with this recognition, can understand the impact that the status of content posting, viewing, or engagement has on product sales. This meets the needs of providers who want to understand the impact that the status of content posting, viewing, or engagement has on product sales.

<Example of operation of control system 1 in simulation service>
Next, the operation of the control system 1 in the simulation service will be described. Simply put, the simulation service is a service that simulates the relationship between the reward budget (= maximum total reward amount) set by the provider for a posting CP and its influence on social media. The following explanation assumes that the provider is considering implementing a posting CP for a specific product. Hereinafter, this specific product will be referred to as the "planned product."

The provider launches the provider-specific app AP on the provider terminal 4 and instructs the display of the information input screen 70. In response to this instruction, the provider terminal information processing unit 18 cooperates with the server information processing unit 10 to display the information input screen 70 on the provider terminal display unit 20. FIG. 20 is a diagram showing an example of the information input screen. As shown in FIG. 20, the information input screen 70 has an input field 71 for inputting a hashtag for the planned product. A hashtag for the planned product is a hashtag that is expected to be assigned to the planned product on the first SNS (or another SNS), and typically indicates the product name of the planned product. As shown in FIG. 20, the information input screen 70 has an input field 72 for inputting a hashtag for a competing product that competes with the planned product. Hashtags for multiple different products can be input as hashtags for competing products. The information input screen 70 also has an input field 73 for inputting a reward budget, an input field 74 for inputting the category of the planned product, and an input field 75 for inputting the unit price of the planned product. The provider enters information into each input field on the information input screen 70 and selects the confirm button 76. Figure 21 shows an example of the information input screen 70 with information entered into each input field. Hereinafter, the hashtag of the planned product entered into input field 71 will be referred to as the "planned product hashtag." The hashtag of the competing product entered into input field 72 will be referred to as the "competing product hashtag." The reward budget entered into input field 73 will be referred to as the "input reward budget." The category entered into input field 74 will be referred to as the "input category." The unit price entered into input field 75 will be referred to as the "planned product unit price."

Figure 22 is a flowchart showing an example of the operation of the provider terminal 4 and the information processing server 2 after the Confirm button 76 is selected. Flowchart FF shows the information processing method by the provider terminal 4, and flowchart FG shows the information processing method by the information processing server 2. As shown in flowchart FF, when the Confirm button 76 is selected by the provider (step SF1), the provider terminal information processing unit 18 notifies the provider of this and transmits each piece of information entered on the information input screen 70 to the server information processing unit 10 (step SF2). As shown in flowchart FG, the server information processing unit 10 acquires each piece of information entered on the information input screen 70 (step SG1).

The server information processing unit 10 then executes an SNS information acquisition process (step SG2). Step SG2 will be described in detail below. First, the server information processing unit 10 acquires the number of posts and views on the first SNS of "short videos with the planned product hashtag" over the most recent week (the seven-day period (including the previous day) prior to the previous day). Hereinafter, this number of posts will be referred to as the "most recent number of planned product posts," and this number of views will be referred to as the "most recent number of planned product views." Furthermore, the server information processing unit 10 acquires the number of posts and views on the first SNS of "short videos with the competing product hashtag" over the most recent week for each competing product. Hereinafter, this number of posts will be referred to as the "most recent number of competing product posts," and this number of views will be referred to as the "most recent number of competing product views." This concludes the details of step SD2.

After step SG2, the server information processing unit 10 executes a pre-implementation share rate derivation process (step SG3). In step SG3, the server information processing unit 10 derives the most recent post count share rate and the most recent play count share rate using the following formulas.
・Recent post share rate = Number of recent posts for planned products / (Number of recent posts for planned products + Number of recent posts for all competing products)
・Recent Views Share Rate = Recent Views of Scheduled Product / (Recent Views of Scheduled Product + Recent Views of All Competing Products)
The above is the details of step SD3.

After step SG3, the server information processing unit 10 executes a process for deriving a predicted post-implementation share rate (step SG4). The process of step SG4 is described in detail below. The process of step SG4 is performed for the purpose of deriving a predicted post-implementation share rate for the number of posts and a predicted post-implementation share rate for the number of views. The predicted post-implementation share rate for the number of posts is a predicted value for the post share rate a certain period of time after the posting CP is implemented, assuming that a posting CP is implemented for the planned product under the input reward budget. The certain period is a period during which the implementation of the posting CP has a sufficient impact on the posting status/view status of the first SNS. The post share rate is the ratio calculated by dividing the number of short videos posted with the planned product hashtag by the number of short videos posted with the planned product hashtag + the number of short videos posted with a competing product hashtag. The predicted post-implementation share rate for the number of views is the predicted post share rate for the number of posts after the implementation, with the "number of posts" replaced by the "number of views."

Here, the server storage unit 12 stores the trained model MD1. Figure 23 is a diagram showing the input and output of the trained model MD1. As shown in Figure 23, the trained model MD1 is a machine-learned model that takes as input the reward budget, the planned product category, the planned product unit price, the pre-implementation post count share rate, and the pre-implementation view count share rate, and outputs the post count predicted share rate and the post count predicted share rate. The trained model MD1 is fully trained using training data prepared using the track record of past post CPs.

In step SD4, the server information processing unit 10 inputs the input remuneration budget, input category, and planned product unit price obtained in step SG1, as well as the pre-implementation post count share rate and pre-implementation view count share rate derived in step SD3, into the trained model MD1, and obtains the post count predicted post count share rate and post-implementation predicted view count share rate output from the trained model MD1. This completes the details of step SG4.

After step SG4, the server information processing unit 10 generates and transmits display data for a simulation screen 77 (described below) using the processing results of steps up to SD4 (step SG5). The provider terminal information processing unit 18 receives the display data and displays the simulation screen 77 (step SE3). Figure 24 is a diagram showing an example of the simulation screen 77. Note that the simulation screen 77 in Figure 24 is a screen in the case where the input to the information input screen 70 is the same as that shown in Figure 21. As shown in Figure 24, the simulation screen 77 displays the number of upcoming posts for the planned product, the upcoming number of posts for the planned product, the number of upcoming posts for the competing product, and the number of upcoming views for the competing product. Specific dates within the past week are also displayed. Furthermore, the simulation screen 77 displays combinations of the pre-implementation share rate of posts and the predicted post rate of posts after implementation. Corresponding to each combination, a calculation method for the post rate share rate and the input reward budget are displayed. Furthermore, the simulation screen 77 displays combinations of the pre-implementation share rate of views and the predicted post rate of views after implementation. The calculation method for the view share rate and the input reward budget amount are displayed in association with the combination. By referring to simulation screen 77, the user can see how the view share rate and view share rate will change before and after a post CP is implemented for a planned product under the input reward budget, and can effectively use this information to determine how much the reward budget should be or whether to implement a post CP.

As shown in FIG. 24, the simulation screen 77 has a revised budget input field 78. An arbitrary reward budget can be entered in the revised budget input field 78. When a reward budget (for convenience, referred to as the "revised reward budget") is entered in the revised budget input field 78 and the re-simulation button 79 is selected, the server information processing unit 10 cooperates with the provider terminal information processing unit 18 to derive a predicted post share rate and a predicted view share rate after implementation based on the revised reward budget. The provider terminal information processing unit 18 displays these share rates on the simulation screen 77. FIG. 25 shows the predicted post share rate and the predicted view share rate after implementation based on the revised reward budget. Using the simulation screen 77, the provider can recognize the predicted post share rate and the predicted view share rate for the desired reward budget, and can effectively use this recognition to determine how much the reward budget should be or whether to implement a post CP. Note that the simulation screen 77 may be configured to display information on either the view share rate or the post share rate, rather than displaying information on both.

As described above, the server information processing unit 10 has a function to accept a specified reward budget amount from a provider who is planning to run a posting CP for a planned product, and a function to predict how the share of posts or views for the planned product on SNS will change when the reward budget amount for the posting CP is the specified amount. The provider terminal information processing unit 18 has a function to provide the prediction results (information on the simulation screen 77) to the provider. With this configuration, the provider can refer to the prediction results and use them as useful information when setting the reward budget.

The above describes one embodiment of the present disclosure, but the above embodiment merely illustrates one example of how the present disclosure may be implemented, and the technical scope of the present disclosure should not be interpreted as being limited thereby. In other words, the present disclosure can be implemented in various forms without departing from its gist or main features. Below, we present variations of the above embodiment. The following variations may be implemented in combination if they can be combined.

<First Modification>
In the above embodiment, the value of the remuneration unit price was a fixed value determined by the provider. On the other hand, the server information processing unit 10 according to the first modification dynamically changes the remuneration unit price according to the popularity of the target product, so that the lower the popularity, the higher the value. An example of the operation of the control system 1 according to this modification is shown below.

Symbol FH in Figure 26 is a flowchart showing an information processing method by the information processing server 2 according to this modified example. As shown in flowchart FH, the server information processing unit 10 executes a popularity derivation process (step SH1). Step SH1 will be described in detail below. In this modified example, a trained model MD2 is prepared that takes as input the parameter values of one or more parameters that affect the popularity of the target product (hereinafter referred to as "popularity-related parameters") and outputs a popularity (assumed to be a score ranging from 0 to 100 points). The trained model MD2 is sufficiently trained using training data based on past performance. Popularity-related parameters include, for example, the price and category of the target product, image data of the target product's appearance, information about products competing with the target product, and information about the target product's purchasing demographic (although, of course, they are not limited to these).

In step SH1, the server information processing unit 10 acquires the parameter values of each popularity-related parameter. The server information processing unit 10 acquires parameter values registered in advance by the provider or operator (or another party), and also acquires parameter values, for example, from the Internet. After acquiring the parameter values of each popularity-related parameter, the server information processing unit 10 derives the popularity using the acquired parameter values and the trained model MD2. This concludes the details of step SH1.

After step SH1, the server information processing unit 10 executes a reward unit price adjustment process (step SH2). Step SH1 is described in detail below. In this variant, a base reward unit price that serves as the basis for the reward unit price is set by the provider or administrator. A table defining the relationship between popularity and rate of change is prepared in advance. However, this table defines the rate of change so that the higher the popularity, the lower the reward unit price, and the lower the popularity, the higher the reward unit price. In step SH1, the server information processing unit 10 uses this table to identify the rate of change corresponding to the popularity, and derives the (final) reward unit price by multiplying the reward unit price by the rate of change. As a result, the lower the popularity, the higher the reward unit price. This concludes the details of step SH2.

This modification can motivate users to participate in posting CPs for less popular target products, thereby promoting the activation of campaign-related services.

The method for deriving the popularity is not limited to the above-mentioned method. An example of the method is shown below.
The popularity level is manually determined and registered. The server information processing unit 10 acquires the registered popularity level.
The server information processing unit 10 generates a prompt that includes information about factors that influence the popularity of the target product and requests that the popularity of the target product be derived. The server information processing unit 10 transmits the generated prompt to a server equipped with a large-scale language model. The server information processing unit 10 receives a response sentence from the server and derives the popularity based on the received response sentence.

The method for adjusting the remuneration unit price is not limited to the method illustrated above. Examples of such methods are shown below.
A formula (which may be a trained model) for deriving the unit reward price is prepared in advance using popularity, base unit reward price, and other information as parameters. However, the formula is such that the higher the popularity, the lower the unit reward price, and vice versa. The server information processing unit 10 uses the formula to derive the unit reward price.

<Second Modification>
The server information processing unit 10 according to this modification has a function of dynamically changing the content of the benefit related to the purchase campaign according to the popularity of the target product, so that the lower the popularity, the greater the benefit the user receives. For example, if the benefit of the purchase campaign is a fixed cashback amount, the server information processing unit 10 increases the fixed cashback amount the lower the popularity of the target product, and decreases the fixed cashback amount the higher the popularity. Furthermore, for example, if the benefit of the purchase campaign is a cashback amount equivalent to a cashback rate, the server information processing unit 10 increases the cashback rate the lower the popularity of the target product, and decreases the cashback rate the higher the popularity. Note that the methods exemplified in the first modification can be applied to the method of deriving the popularity and the method of dynamically changing the content of the benefit.

This modified example can motivate users to participate in purchase CPs for less popular target products, thereby promoting the activation of campaign-related services.

<Third Modification>
The server information processing unit 10 according to the third modification has the following functions: a function for managing user ranks; a function for deriving a user's rank grade by reflecting at least one of actions related to the user in a purchase CP and actions related to the user in a post CP; and a function for modifying the content of purchase benefits (benefits) or posting rewards (posts) according to the user's rank grade so that the higher the grade, the greater the benefit the user will receive, or for executing actions that benefit the user when the user's rank grade increases. Note that a user-related action is a concept that includes both actions performed by the user and actions performed on the user. This also applies to the other modifications. Below, an example of the operation of the control system 1 according to this modification is shown.

In this modified example, a rank is assigned to each user. The available rank grades (types) are bronze rank, silver rank, gold rank, and platinum rank. The rank is registered in a user management data record in the user management database 30. That is, the server information processing unit 10 manages each user's rank using the user management database 30. Symbol FI in Figure 27 is a flowchart showing an information processing method by the information processing server 2 according to this modified example. Flowchart FI is processing executed by the server information processing unit 10 for a single user. As shown in flowchart FI, the server information processing unit 10 monitors whether a factor that changes the user's rank has occurred (step SI1). In this embodiment, the factors that change the rank are when the user passes a purchase check and when the user passes a video screening.

If a change factor occurs (step SI1: YES), the server information processing unit 10 derives the user's rank grade (step SI2). Step SI2 is described in detail below. In this variation, the number of times the purchase check has been passed (hereinafter referred to as the "number of times the purchase check has been passed") and the number of times the video review has been passed (hereinafter referred to as the "number of times the video review has been passed") are registered in the user management record for each user. Furthermore, a calculation formula is prepared in advance to derive the rank grade using the number of times the purchase check has been passed and the number of times the video review has been passed as input parameters. The calculation formula is designed to derive a higher grade the more times the purchase check has been passed and the more times the video review has been passed. In step SI2, the server information processing unit 10 references the user's user management record and obtains the number of times the purchase check has been passed and the number of times the video review has been passed. The server information processing unit 10 then uses the obtained information and the above calculation formula to derive the user's rank grade.

After step SI2, the server information processing unit 10 determines whether the user's grade has increased (step SI3). If the user's grade has not increased (step SI3: NO), the server information processing unit 10 proceeds to step SI1. If the user's grade has increased (step SI3: YES), the server information processing unit 10 executes rank increase processing (action) corresponding to the increased (changed) grade (step SI4), and proceeds to step SI1. The processing of step SI4 is described in detail below.

In this modified example, a rank increase process (action) to be executed is predetermined for each increased (changed) grade. Note that the content of the rank increase process for different grades may be the same. The rank increase process is a process that provides benefits to the user. Below, examples of rank increase processes are shown focusing on the silver rank and gold rank. However, it goes without saying that the examples are not limited to the following.
When a user is promoted to Silver rank, 200 points are awarded as predetermined points that the user can use, and when a user is promoted to Gold rank, 250 points are awarded as predetermined points that the user can use. However, the points awarded for Silver rank and Gold rank may be the same value.
When you are promoted to Silver rank and when you are promoted to Gold rank, you will be given a designated coupon, ticket, or gift certificate. The contents of the coupon, ticket, or gift certificate for Silver rank and the coupon, ticket, or gift certificate for Gold rank may be the same or different.

Furthermore, the server information processing unit 10 changes the content of the purchase benefit for the purchase CP or the posting reward for the posting CP depending on the user's rank grade so that the higher the grade, the greater the benefit the user will receive. Below, an example of the processing by the server information processing unit 10 related to changing the content of the purchase benefit or posting reward is shown. However, it goes without saying that the following examples are not limiting.
The server information processing unit 10 increases the fixed cashback amount (or the cashback rate if the cashback amount is determined by the cashback rate) for the purchase CP as the rank grade increases.
The server information processing unit 10 increases the unit price of reward for a post CP as the rank grade increases.
The server information processing unit 10 notifies users of a predetermined grade or higher of the purchase CP in advance.

This modified example can motivate users to participate in purchase CPs and posting CPs, encouraging the activation of campaign-related services.

The following application examples can be applied to this modification. This also applies to the fourth modification, which will be described later.
The "user actions" used to derive the rank grade are not limited to those exemplified.
The method of deriving the rank grade is not limited to the exemplified method. That is, the method of deriving the rank grade may be any method that results in a higher grade the more times the purchase check or video review is passed. In other words, the method may be any method that results in a higher grade the more frequently campaign-related services are used and the greater the contribution of the services to activation.

<Fourth Modification>
The server information processing unit 10 according to the fourth modification has the following functions: a function for managing a user's provider compatibility rank for each provider; a function for deriving a grade of a user's provider compatibility rank for a provider by reflecting at least one of actions related to the user in a purchase campaign conducted by that provider and actions related to the user in a posting campaign conducted by that provider; and a function for changing the content of a purchase benefit or posting reward related to that provider according to the grade of the user's provider compatibility rank related to that provider so that the higher the grade, the greater the benefit the user will receive, or for executing an action that will benefit the user related to that provider when the grade of the user's provider compatibility rank related to that provider is increased. An example of the operation of the control system 1 according to this modification is shown below.

In this modified example, a provider correspondence rank is set for each user for each provider. For example, for a given user, a different rank is set for each provider, such as a provider correspondence rank for provider A, a provider correspondence rank for provider B, etc. The grades (types) of provider correspondence ranks are bronze, silver, gold, and platinum. The provider ranks are registered in the user management data record of the user management database 30. That is, the server information processing unit 10 manages each user's provider correspondence rank using the user management database 30. Symbol FJ in Figure 28 is a flowchart showing an information processing method by the information processing server 2 according to this modified example. Flowchart FJ is processing executed by the server information processing unit 10 for a given user. As shown in flowchart FJ, the server information processing unit 10 monitors whether any factor that causes a change in the provider correspondence rank has occurred for the user (step SJ1). In this embodiment, the factors that cause the provider rank corresponding to a provider to fluctuate are whether the user passes the purchase check for a purchased CP conducted by that provider, and whether the user passes the video review for a posted CP conducted by that provider.

If any of the fluctuation factors occurs (step SJ1: YES), the server information processing unit 10 executes the following process (step SJ2). Hereinafter, the provider corresponding to the provider correspondence rank for which the fluctuation factor occurred will be referred to as the "processing target provider." In step SJ2, the server information processing unit 10 derives the grade of the processing target provider's provider correspondence rank for the user (step SJ2). As with the third variant, the server information processing unit 10 performs this derivation using the number of times the purchase check related to the processing target provider has passed, the number of times the video review related to the processing target provider has passed, and a pre-prepared calculation formula.

After step SJ2, the server information processing unit 10 determines whether the grade of the user's provider score has increased (step SJ3). If the user's grade has not increased (step SJ3: NO), the server information processing unit 10 proceeds to step SJ1. If the user's grade has increased (step SJ3: YES), the server information processing unit 10 executes rank increase processing (action) corresponding to the increased (changed) grade (step SJ4) and proceeds to step SJ1. The processing of step SJ4 is described in detail below.

In this modified example, a rank increase process (action) to be executed is predetermined for each increased (changed) grade. The rank increase process is a process that provides benefits to the user in relation to the processing target provider. Below, examples of rank increase processes are shown focusing on the silver rank and gold rank. However, the examples are not limited to the following examples.
When a user is promoted to Silver rank, 200 points are awarded as predetermined points that can be used in the services provided by the processing target provider, and when a user is promoted to Gold rank, 250 points are awarded as predetermined points. However, the points awarded for the Silver rank and the Gold rank may be the same value.
When a user is promoted to Silver rank and when a user is promoted to Gold rank, a predetermined coupon, ticket, or gift certificate provided by the processing target provider is distributed. Note that the content of the coupon, ticket, or gift certificate for Silver rank may be the same as or different from the content of the coupon, ticket, or gift certificate for Gold rank.

Furthermore, the server information processing unit 10 changes the content of the benefit for the purchased CP related to the processing target provider or the reward for the posted CP according to the user's rank grade so that the higher the grade, the greater the benefit the user will receive. Below, an example of the processing by the server information processing unit 10 related to changing the content of the benefit or reward is shown. However, it goes without saying that the processing is not limited to the following example.
- The higher the grade of the provider correspondence rank, the higher the fixed cashback amount (or the cashback rate if the cashback amount is determined by the cashback rate) for the purchase CP implemented by the provider to be processed, the server information processing unit 10 will set.
The server information processing unit 10 increases the unit price of reward for a posting CP performed by a processing target provider as the provider's rank becomes higher.
The server information processing unit 10 notifies users of a predetermined grade or higher of the purchase CP of the processing target provider in advance.

This modified example can motivate users to participate in purchase CPs and posting CPs, thereby promoting campaign-related services. Furthermore, users can be given the opportunity/motivation to continue and repeatedly participate in purchase CPs and posting CPs related to a single provider, thereby improving provider satisfaction with campaign-related services.

<Fifth Modification>
The server information processing unit 10 according to the fifth modification has a function of managing the history of actions taken by users in a purchase campaign or a posting campaign, a function of displaying a screen on a display unit accessible by a provider on which conditions can be set using past actions taken by users, and a function of extracting users based on the conditions set by the provider. An example of the operation of the control system 1 according to this modification is shown below.

In this modified example, a history (log) of actions related to the user in purchase CPs and a history (log) of actions related to the user in post CPs are registered in the user management record for each user. That is, the server information processing unit 10 uses the user management database 30 to manage the "history of actions related to the user in purchase CPs or post CPs." The history registered in the user management record includes information necessary to determine whether the fixed conditions and extraction conditions described below are met.

The provider terminal information processing unit 18 in this modified example cooperates with the server information processing unit 10 to display a condition setting screen 80 on the provider terminal display unit 20 in response to a provider request. Figure 29 is a diagram showing an example of the condition setting screen 80. As shown in Figure 29, the condition setting screen 80 displays each individual condition. On this screen, check boxes 81 are used to select any one or more individual conditions. The extraction conditions are constructed by ANDing the selected one or more individual conditions. Individual conditions are broadly divided into "conditions using past user actions" and "conditions related to user attributes or personality." Focusing on the first individual condition on the condition setting screen 80 in Figure 29, the individual condition is "a person who has passed a purchase check for a purchased CP ("our company" or "our company and other companies") within the last ○ days." This individual condition corresponds to a "condition using past user actions." Furthermore, if we look at the third individual condition on the screen, it is "a person who has passed the purchase check for CP purchased by (our company) or (our company and other companies) at least x times in the past." This individual condition corresponds to "a condition that utilizes past user actions." Furthermore, if we look at the fifth individual condition on the screen, it is a condition related to age group, which corresponds to "a condition related to the user's attributes or personality."

The provider can use the condition setting screen 80 to set extraction conditions consisting of a combination of individual conditions and instruct the extraction of users based on the extraction conditions. When this instruction is received, the server information processing unit 10 references the user management database 30, extracts users who match the extraction conditions, and displays a screen showing information about each of the extracted users. User information displayed on the screen includes item values for predetermined items (e.g., name, age, gender, "user action history in purchase campaigns or posting campaigns," rank or provider response rank), telephone number, or email address).

The provider can then take a predetermined action (for example, announcing a purchase campaign, introducing a new product, or distributing coupons) for the extracted users. The provider may also be able to instruct the execution of a predetermined action using a dedicated app AP, and the server information processing unit 10 and user terminal information processing unit 13 may then execute the predetermined action in response to the instruction.

This modified example allows providers to extract (group) users from a variety of perspectives that reflect the users' past actions, enabling them to provide users with more tailored services that are better suited to their needs.

The following application examples can be applied to the fifth variant. Note that the example of individual conditions illustrated in Figure 29 is merely an example. In particular, with regard to the "conditions using past actions related to the user," conditions using actions related to the user can be broadly defined. Furthermore, as individual conditions, conditions using the rank related to the third variant or the provider correspondence rank related to the fourth variant can be defined.

<Sixth Modification>
The server information processing unit 10 according to this modification has a function of issuing an image introducing an application link or campaign for a purchase CP or post CP designated by the provider in response to a request from the provider. An example of the operation of the control system 1 according to this modification is shown below.

The provider launches the provider-specific app AP2 on the provider terminal 4 and performs a predetermined operation to instruct the display of the implemented CP list screen 82. In response to this instruction, the provider terminal information processing unit 18 displays the implemented CP list screen 82 on the provider terminal display unit 20. Figure 30 is a diagram showing an example of the implemented CP list screen 82. As shown in Figure 30, the implemented CP list screen 82 displays a list of purchase CPs and posted CPs that the provider is currently running, as well as link issue buttons 83 associated with each campaign. The provider can select the link issue button 83 for the desired CP.

When the link issue button for one of the CPs in question is selected, the server information processing unit 10 issues an application link (app link, universal link) for that one of the CPs in question. The application link for that one of the CPs in question is a link that, when selected on the user terminal 3, launches a dedicated app AP and displays an "introduction screen for that one of the CPs in question" provided by the functions of the dedicated app AP on the user terminal display unit 15. The server information processing unit 10 issues an application link for each type of OS expected for the user terminal 3.

Furthermore, the server information processing unit 10 issues a link (URL) for accessing the site where the CP in question is introduced. Hereinafter, this link will be referred to as the "site link."

Furthermore, the server information processing unit 10 generates a current CP introduction image 84 that introduces the current CP. The current CP introduction image 84 is image data in a specified file format. The current CP introduction image 84 includes, for example, information equivalent to the information displayed in the purchase CP overview block or post CP overview block 32 described above.

After issuing the application link and site link and generating the CP introduction image 84, the provider terminal information processing unit 18 works in cooperation with the server information processing unit 10 to display a processing result display screen 85 showing these on the provider terminal display unit 20. Figure 31 is a diagram showing an example of the processing result display screen 85. As shown in Figure 31, the processing result display screen 85 displays application links for each OS type. Each application link can be copied and pasted. The screen also displays the CP introduction image 84. The CP introduction image 84 can be downloaded to the provider terminal 4. The provider can notify their customers of the application link and CP introduction screen by communication tools, email, notification via an application, or other means.

<Seventh Modification>
The server information processing unit 10 according to the seventh modification has a function of generating and providing a tag for displaying a link to access an introduction screen for the purchase campaign or posting campaign on the screen viewed by the viewer. An example of the operation of the control system 1 according to the seventh modification is shown below.

In the seventh variant, a navigation link is displayed on the online shop's web page, blog, "screen provided by a specified app," or other "screen viewed by the viewer." The navigation link is a "link to access the purchase CP introduction screen on the campaign-related service site" or a "purchase CP application link." The purchase CP application link is a link that, when selected on the user terminal 3, launches a dedicated application AP, accesses the "introduction screen for that particular CP" provided by the dedicated application AP's functions, and displays that screen on the user terminal display unit 15.

Figure 32 is an example of a "blob web page" on which a navigation link is displayed. The blog illustrated in Figure 32 is a blog about the use of Product X, for which a purchase CP and a posting CP are currently being offered. The blog displays a link button 87 indicating a "link to the product X purchase CP introduction screen" (which may be an app link for the product X purchase CP). By simply selecting the link button 87, viewers can access and display the product X purchase CP introduction screen. In the example of Figure 32, the server information processing unit 10 generates an HTML tag for displaying the link button 87 as a navigation link and provides it to the blog creator (or the blog platform provider). The blog creator displays the link button 87 on the block by incorporating the HTML tag into the blog's HTML file.

This modified example makes it possible to introduce purchase CPs or post CPs more effectively using a wider variety of methods.

<Other Modifications>
In the above embodiment, the purchase CP is disclosed to users who have not participated in the purchase CP, and the posting CP is introduced only to users who have passed the purchase check. In this regard, a combination of the purchase CP and the posting CP may be disclosed to users who have not participated in the purchase CP.
The purchase benefits of the purchase CP are not limited to those exemplified in the above embodiment. For example, the purchase benefits may be points, a predetermined right, or a right to receive a predetermined discount.
The method of deriving the posting reward illustrated in the above embodiment is merely an example. For example, an upper limit of the posting reward may be set for each user, or a fixed amount may be awarded for posting a short video, or the posting reward may be adjusted based on factors other than the number of views. Furthermore, a fixed amount corresponding to the act of posting a short video may be included in the reward amount.
In the above embodiment, the posted CP may be introduced when the completion of the granting of the purchase benefit is reported.
In the above embodiment, the remuneration unit price may be set by the administrator instead of the provider.

In the above embodiment, the content was a short video. However, the content is not limited to a short video. For example, the content may be a long video, text, audio, or still image. Furthermore, in the above embodiment, the content was a short video, so the content was viewed by playing it. However, the content should be viewed by an appropriate means depending on the type of content.
In the above embodiment, the SNS to which content is posted in the campaign-related service is one of the first SNSs. However, the number of SNSs to which the campaign-related service is posted is not limited to one, and may be multiple. In this case, the relationship between the SNS status and the sales status may be provided for each SNS, or the relationship between the SNS status and the sales status for multiple SNSs may be provided. For the SNS status for multiple SNSs, the number of posts and the number of views (plays) are the total values for each SNS.
The information registered in each database in the above embodiment is an example. For example, the post CP management database 35 stores at least information necessary for calculating a posting reward.
The information held in one database in the above embodiment may be distributed and held in multiple databases, or the information held in multiple databases may be held in one database. In other words, the method of holding data is not limited to the method exemplified in the above embodiment. As an example, a separate database for managing case-specific information may be provided.

The SNS-related indicators are not limited to the indicators exemplified in the above embodiment. For example, the SNS-related indicator related to engagement exemplified in the above embodiment is an indicator related to the number of likes, but it may be an indicator related to engagement other than "likes" (for example, comments, retweets, reposts, number of saves). Furthermore, for example, the daily total of the number of daily related video posts (indicator) may be expressed in other units of time, such as monthly total, weekly total, or per hour. This also applies to other indicators.
The SNS status is not limited to the examples given in the above embodiment. In other words, the SNS status may be any status indicating the posting, viewing, or engagement status of the target product-related short video (target product-related content).
Sales-related indices are not limited to the indices exemplified in the above embodiment. In other words, sales-related indices may be indices related to sales (sales performance) of the target product.
The sales status is not limited to the examples given in the above embodiment. In other words, the sales status may be anything that indicates the sales status of the target product.

In the above embodiment, the transition relationship graph 60 and the correlation table 68 are used as examples of information showing the relationship between the SNS status and the sales status. However, the information is not limited to the transition relationship graph 60 and the correlation table 68. Various types of graphs can be used as the information. The relationship may also be shown in a table format.
In the above embodiment, when displaying the transition relationship graph 60 and the correlation table 68 in the information providing service, the server information processing unit 10 generates display data and displays the screen each time. In this regard, the display data (which may be image data) for the transition relationship graph 60 or the correlation table 68 may be prepared in advance. Alternatively, the provider terminal information processing unit 18 may generate the display data for the transition relationship graph 60 or the correlation table 68.

The functional blocks shown in the above embodiments can be realized by any hardware or by a combination of any hardware and any software. In other words, these functional blocks are not limited to specific hardware. Furthermore, the order of the processes in the flowcharts of the above embodiments may be changed, the processes may be divided into smaller parts, processes may be added, or processes may be deleted, as long as the purpose can be achieved.
In the above embodiment, some or all of the data stored in the server storage unit 12 may be stored in a storage unit of an external device accessible by the server information processing unit 10 .
In the above embodiment, all or part of the processes described as being executed by the user-dedicated application AP1 may be executed by a browser.
The embodiments may include providing a program executed by a computer of the information processing server 2, the user terminal 3, or the provider terminal 4. The embodiments may also include providing a recording medium on which the program is recorded in a computer-readable manner. The recording medium may be a magnetic or optical recording medium or a semiconductor memory device. Specific examples include portable or fixed recording media such as flexible disks, hard disk drives (HDDs), CD-ROMs (compact disk read-only memories), DVDs (digital versatile disks), Blu-ray (registered trademark) discs, magneto-optical disks, flash memories, and card-type recording media.

- In the above embodiment, a device having a certain function is not limited to the device exemplified as a device having that function. For example, focus is placed on the function of providing (displaying) the post CP details screen 33 (referred to as the "first function") and the function of deriving a posting reward (referred to as the "second function"). In the above embodiment, as shown in (A) of Figure 33, the server information processing unit 10 of the information processing server 2 has the second function, and the user terminal information processing unit 13 of the user terminal 3 has the first function. In this configuration, the combination of the information processing server 2 and the user terminal 3 functions as an "information processing system." Furthermore, the server information processing unit 10 and the user terminal information processing unit 13 each function as an "information processing unit." On the other hand, as shown in (B) of Figure 33, the user terminal information processing unit 13 of the user terminal 3 may have the first function and the second function. In this configuration, the user terminal 3 functions as an "information processing system," and the user terminal information processing unit 13 functions as an "information processing unit." Furthermore, as shown in FIG. 33(C), the server information processing unit 10 may have a first function and a second function. In this configuration, the information processing server 2 functions as an "information processing system," and the server information processing unit 10 functions as an "information processing unit." Note that when the information processing units of multiple devices (e.g., the server information processing unit 10 and the user terminal information processing unit 13) each function as an "information processing unit," the functions provided in each information processing unit are not limited. A single function may also be realized by multiple information processing units. Furthermore, the device that realizes a certain function may be a device other than the information processing server 2, the user terminal 3, and the provider terminal 4.

1. Control system (information processing system)
2. Information processing server (information processing system)
3. User terminal (information processing system)
4. Provider terminal (information processing system)
10 Server information processing unit (information processing unit)
13 User terminal information processing unit (information processing unit)
18 provider terminal information processing unit (information processing unit)

Claims (21)

A function of accepting proof of purchase of a target product from users who participate in a purchase campaign conducted by a provider for the target product, notifying the users of the results of a purchase check conducted on the proof of purchase, and granting benefits to the users who pass the purchase check;
an information processing unit having a function of accepting target product-related content, which is content related to the target product, for posting on SNS from users who have passed the purchase check and are participating in a posting campaign conducted by the provider for the target product, notifying the users of the results of a video review conducted on the target product-related content, deriving a reward for the post in accordance with the posting of the target product-related content on the SNS by the users who have passed the video review, and granting the derived reward to the users. The information processing unit
The information processing system according to claim 1, further comprising a function of deriving the reward by multiplying the number of views of the target product-related content on the SNS for a certain period of time by a reward unit price corresponding to the posting campaign. A total reward limit for the posting campaign is determined based on a reward budget set by the contributor;
The information processing unit
The information processing system according to claim 2, further comprising a function for limiting the increase in the rewards of each of the users participating in the posting campaign if the total cumulative reward amount of each of the users participating in the posting campaign exceeds the total reward upper limit. The information processing unit
The information processing system according to claim 3, further comprising a function of providing the user with the relationship between the total reward limit and the cumulative total reward before the user participates in the posting campaign. The information processing unit
receiving a designation of the amount of the reward budget from the provider who intends to conduct the posting campaign for the planned product;
predicting how the share of the number of posts or views of the planned product on the SNS will change when the amount of the reward budget for the posting campaign is a specified amount;
The information processing system according to claim 3 , further comprising a function of providing the provider with a prediction result. The information processing unit
The information processing system according to claim 2, further comprising a function of dynamically changing the remuneration unit price in accordance with the popularity of the target product so that the lower the popularity, the higher the remuneration unit price. The information processing unit
The information processing system according to claim 1, further comprising a function of dynamically changing the content of the benefit according to the popularity of the target product so that the lower the popularity, the greater the benefit the user receives. The information processing unit
The information processing system according to claim 1, characterized in that it has a function of providing the provider with the relationship between the SNS status indicating the posting, viewing or engagement status of the target product-related content posted on the SNS and the sales status indicating the sales status of the target product. The information processing unit
The information processing system according to claim 8, characterized in that it has a function of providing a relationship between the trend in index values of SNS-related indexes relating to posting, viewing or engagement of the target product-related content and the trend in index values of sales-related indexes relating to sales of the target product. The information processing unit
The information processing system according to claim 8, characterized in that it has a function of providing the provider with a correlation between index values of SNS-related indexes relating to posting, viewing or engagement of the target product-related content and index values of sales-related indexes relating to sales of the target product. The information processing unit
a function of providing the user with a tag group that includes one or more tags that can be used on the SNS, the tag group including a target product category tag that indicates the category to which the target product belongs, and that is required to be assigned to the target product related content when the target product related content is posted on the SNS, in relation to the posting campaign;
a function of providing the provider with a relationship between a change in category share and a change in the index value of a sales-related index relating to sales of the target product;
The information processing system described in claim 8, characterized in that the category occupancy rate is the ratio of the index value of a specified index related to the posting, viewing or engagement of the content related to the target product to the index value of a specified index related to the posting, viewing or engagement of the content to which the target product belongs category tag is assigned. The information processing unit
a function of providing the user with a tag group for the posting campaign, the tag group including one or more tags that can be used on the SNS, including a target product category tag that indicates the category to which the target product belongs, and which is required to be assigned to the target product-related content when the target product-related content is posted on the SNS;
a function of providing the provider with a correlation between a category share and an index value of a sales-related index relating to sales of the target product;
The information processing system described in claim 8, characterized in that the category occupancy rate is the ratio of the index value of a specified index related to the posting, viewing or engagement of the content related to the target product to the index value of a specified index related to the posting, viewing or engagement of the content to which the target product belongs category tag is assigned. The information processing unit
a function for managing the rank of the user;
a function of deriving a rank grade of the user by reflecting at least one of an action related to the user in the purchase campaign and an action related to the user in the posting campaign;
The information processing system according to claim 1, further comprising a function of changing the content of the benefit or the reward depending on the rank grade of the user so that the higher the rank, the greater the benefit the user will receive, or of executing an action that will benefit the user when the rank grade of the user increases. The information processing unit
a function of managing the provider correspondence rank of the user for each of the providers;
a function of deriving a grade of the provider correspondence rank of the user by reflecting, for one provider, at least one of an action regarding the user in the purchase campaign implemented by the one provider and an action regarding the user in the posting campaign implemented by the one provider;
The information processing system according to claim 1, further comprising a function to change the content of the benefit or reward related to a provider according to the grade of the provider correspondence rank related to the user's provider so that the higher the grade, the greater the benefit the user will receive, or to execute an action to benefit the user with respect to the provider when the grade of the provider correspondence rank related to the user's provider increases. The information processing unit
a function for managing a history of actions related to the user in the purchase campaign or the posting campaign;
a function of displaying a screen on a display unit that can be referenced by the provider, on which conditions can be set using past actions related to the user;
The information processing system according to claim 1 , further comprising a function of extracting the users based on the conditions set by the provider. The information processing unit
The information processing system according to claim 1, characterized in that it has a function of issuing an application link or an image introducing the purchase campaign or posting campaign specified by the provider in response to a request from the provider. The information processing unit
The information processing system according to claim 1, further comprising a function for generating and providing a tag for displaying a link to access an introduction screen for the purchase campaign or the posting campaign on a screen viewed by a viewer. The information processing unit
18. The information processing system according to claim 1, wherein when notifying the user that the check result of the purchase check has passed, the information introducing the posting campaign is notified to the user. The information processing unit
a function of providing the user with purchase rules for purchasing the target product in relation to the purchase campaign;
The information processing system of any one of claims 1 to 17, further comprising a function of notifying the user of the check results of the purchase check performed on the proof of purchase from the viewpoint of whether the target product was purchased in accordance with the purchase rules. The information processing unit
a function of providing the user with creation rules for creating the target product-related content in relation to the posting campaign;
The information processing system according to any one of claims 1 to 17, further comprising a function of notifying the user of the review results of the video review conducted on the target product-related content from the viewpoint of whether the target product-related content has been created in accordance with the creation rules. an information processing unit of the information processing system receiving proof of purchase of the target product from users participating in a purchase campaign implemented by a provider for the target product, notifying the users of the results of a purchase check conducted on the proof of purchase, and granting a benefit to the users who pass the purchase check;
an information processing unit having a function of accepting target product-related content, which is content related to the target product, for posting on SNS from users who have passed the purchase check and are participating in a posting campaign conducted by the provider for the target product, notifying the users of the results of a video review conducted on the target product-related content, deriving a reward for the post in accordance with the posting of the target product-related content on the SNS by the users who have passed the video review, and granting the derived reward to the users.