Product production assistance system and product production assistance method

Abstract

In the present invention, a product production assistance server (1) comprises a primary project database (13) for storing specification information indicating specifications of a product produced in accordance with a request of a specific user, and provides the specification information to another user different from the specific user. Upon receiving a modification request for the specifications indicated by the specification information from the other user, the product production assistance server (1) modifies the specifications in accordance with the modification request, and provides specification information indicating the modified specifications to a producer of the product.

Description

Product Manufacturing Support System and Product Manufacturing Support Method

[0001] The present invention relates to a product manufacturing support system and a product manufacturing support method for supporting the manufacture of various products.

[0002] In recent years, with the diversification of users' preferences for various products, the need for order production has been increasing, and various technologies for supporting this have been proposed. For example, in Patent Document 1, a user who is a purchaser sets conditions such as specifications and prices in advance with an intermediary regarding a made-to-order product, and the intermediary transmits the conditions excluding the price among these to a plurality of sellers to conduct a competition solicitation regarding the made-to-order product. An electronic commerce system is disclosed in which a transaction regarding a made-to-order product is established between the user and the seller based on the presentation of plans from the seller. According to this electronic commerce system, by the involvement of the intermediary, even when the user does not have sufficient knowledge about order production, it becomes possible to transact with the seller with appropriate content.

[0003] Japanese Unexamined Patent Application Publication No. 2002 - 157474

[0004] By the way, information about a product manufactured according to the requirements of a specific user may have high utility value for other users who desire the same type of product. In particular, when that user lacks knowledge and experience regarding order production, this tendency is prominent. Therefore, it is convenient if the information can be shared among many users.

[0005] The present invention has been made in view of such circumstances, and its main object is to provide a product manufacturing support system and a product manufacturing support method that can promote order production of products by enabling other users to share information about products manufactured according to the requirements of a specific user.

[0006] To solve the above problems, a product manufacturing support system according to one aspect of the present invention includes: a storage unit that stores specification information indicating the specifications of a product manufactured according to the requests of a specific user; a first provision unit that provides the specification information to a user other than the specific user; a reception unit that receives a request from the other user to change the specifications indicated by the specification information; a modification unit that changes the specifications in response to the modification request; and a second provision unit that provides specification information indicating the modified specifications to the manufacturer of the product.

[0007] In the above embodiment, the first providing unit may provide the specification information to other users if it obtains consent from the specific user.

[0008] Furthermore, in the above embodiment, the first providing unit may also provide the specification information to the other user if it obtains the consent of the manufacturer.

[0009] Furthermore, in the above embodiment, the system may further include an acquisition unit that obtains conditions, including the price of the product, from the manufacturer, and the first provision unit may further provide the conditions to the other user.

[0010] Furthermore, in the above embodiment, the specifications of the product consist of multiple items, and the receiving unit may disable the acceptance of change requests from other users for specific items among the multiple items.

[0011] Furthermore, in the above embodiment, the receiving unit may be configured to not accept change requests from other users for the specific item specified by the specific user.

[0012] Furthermore, in the above embodiment, a third providing unit may be provided to the other user, which provides specification information indicating the modified specifications in response to a change request received from a user different from the other user.

[0013] Furthermore, in the above embodiment, the third providing unit may, when the receiving unit receives the change request from the other user, provide the other user with specification information indicating the specifications that have been changed in accordance with the change request received from the different user.

[0014] Furthermore, in the above embodiment, the system may further include a purchase request receiving unit that receives requests from other users to purchase the manufactured product without changing its specifications, or to purchase the product with modified specifications.

[0015] Furthermore, the embodiment may further include a calculation unit that calculates the amount of refund to the specific user according to the number of purchases of the product by other users, depending on whether or not the specifications have been changed.

[0016] A product manufacturing support method according to one aspect of the present invention provides specification information indicating the specifications of a product manufactured according to the requests of a specific user to a user other than the specific user, receives a request from the other user to change the specifications indicated by the specification information, changes the specifications in accordance with the change request, and provides specification information indicating the changed specifications to the manufacturer of the product.

[0017] According to the present invention, it is possible to effectively promote the custom manufacturing of various products.

[0018] A block diagram showing the configuration of the product manufacturing support system and its communication destinations. A diagram showing an example layout of the member table that makes up the member database. A diagram showing an example layout of the manufacturer table that makes up the manufacturer database. A diagram showing an example layout of the primary project table that makes up the primary project database. A diagram showing an example layout of the proposal table that makes up the proposal database. A diagram showing an example layout of the completed project table that makes up the completed project database. A diagram showing an example layout of the secondary project table that makes up the secondary project database. A diagram showing an example layout of the improvement request table that makes up the improvement request database. A diagram showing an example layout of the purchase table that makes up the purchase database. A flowchart showing an example of the procedure for primary project registration processing. A diagram showing an example of the primary project registration screen. A diagram showing an example of the input support screen. A flowchart showing an example of the procedure for manufacturer proposal processing. A diagram showing an example of the proposal registration screen. A flowchart showing an example of the procedure for proposal confirmation processing. A diagram showing an example of the proposal display screen. A flowchart showing an example of the procedure for secondary project registration processing. A flowchart showing an example of the procedure for secondary project provision processing. A diagram showing an example of the secondary project display screen. A flowchart showing an example of the procedure for improvement purchase processing. A diagram showing an example of the improvement purchase screen. A diagram showing another example of the improvement purchase screen. A diagram showing another example of the improved purchase screen. A diagram showing another example of the improved product purchase screen. A flowchart showing an example of the procedure for calculating the refund amount.

[0019] Preferred embodiments of the present invention will be described below with reference to the drawings. The embodiments described below are illustrative examples of methods and apparatus for realizing the technical concept of the present invention, and the technical concept of the present invention is not limited to those described below. Various modifications can be made to the technical concept of the present invention within the technical scope described in the claims.

[0020] The product manufacturing support system of this embodiment functions in the following two scenarios in build-to-order production: (1) Primary build-to-order production: The manufacturer produces a product according to the user's requirements. (2) Secondary build-to-order production: The manufacturer produces a product produced in the primary build-to-order production or a product derived from that product, according to the requirements of a different user than the one mentioned above. Below, the configuration of the product manufacturing support system will be described, followed by a description of the operation of the product manufacturing support system for each of the two scenarios described above.

[0021] (System Configuration) Figure 1 is a block diagram showing the configuration of the product manufacturing support system and its communication destinations according to this embodiment. The product manufacturing support system according to this embodiment consists of a product manufacturing support server (hereinafter simply referred to as the "manufacturing support server") 1. This manufacturing support server 1 is a computer system operated by a business operator (hereinafter referred to as the "service provider") that provides product manufacturing support services to each user who wishes to purchase a product and each company (organization or individual conducting business activities) that is the manufacturer of the product, and is connected to a user terminal 2, a manufacturer terminal 3, and a generation AI server 4 via the Internet 101 so as to be able to communicate.

[0022] User terminal 2 is an information terminal used by each user, and consists of, for example, a personal computer, a tablet device, and a smartphone. Producer terminal 3 is an information terminal used by each producer, and, similar to user terminal 2, consists of a personal computer and the like.

[0023] The Generative AI Server 4 is a computer system equipped with a Large-Scale Language Model (LLM) 41. The LLM 41 is a pre-trained machine learning model built using large-scale text data, and when it receives a prompt (question) as input, it outputs a response corresponding to that prompt. For example, the LLM 41 can be a GPT (Generative Pre-trained Transformer), a BERT (Bidirectional Encoder Representations from Transformers), or similar.

[0024] The following describes the detailed configuration of the production support server 1. The production support server 1 consists of one or more computers equipped with a control unit including a CPU, RAM, and ROM, and a storage unit, and the various processes described later are executed by this control unit. The storage unit of the production support server 1 is equipped with the following databases: Member Database (DB) 11, Producer Database (DB) 12, Primary Project Database (DB) 13, Proposal Database (DB) 14, Achievement Database (DB) 15, Secondary Project Database (DB) 16, Improvement Request Database (DB) 17, and Purchase Database (DB) 18. The details of these databases will be described below.

[0025] (A) Member DB 11 The Member DB 11 is a database for storing information about each user. Each user is required to register with the service provider in order to receive product manufacturing support services. The Member DB 11 is constructed based on the information provided by the user during user registration. The information stored in the Member DB 11 is updated as needed based on information received from each user after user registration.

[0026] The Member DB11 consists of multiple tables. Figure 2 shows an example of the layout of one of these tables, the Member table. As shown in Figure 2, the Member table stores information such as the user's name, address, email address, and attributes, linked to a Member ID used to identify each user. These attributes include the user's age, gender, occupation, etc.

[0027] (B) Manufacturer DB12 Manufacturer DB12 is a database for storing information about each manufacturer. Each manufacturer, like users, is required to register with the service provider in order to receive product manufacturing support services. Manufacturer DB12 is built based on the information provided by the manufacturer during the manufacturer registration process. The information stored in Manufacturer DB12 is updated as needed based on information received from each manufacturer after manufacturer registration.

[0028] The Creator DB12 consists of multiple tables. Figure 3 shows an example of the layout of one of these tables, the Creator table. As shown in Figure 3, the Creator table stores information such as the creator's name, address, email address, and attributes, linked to a Creator ID used to identify each creator. These attributes include the creator's projects, areas of expertise, and scale.

[0029] (C) Primary Project DB13 Primary Project DB13 is a database for storing information about primary projects, which are projects that are the target of primary order production. As described later, primary projects are generated in response to requests from users, and at the time of generation and at appropriate intervals, information about the primary project is stored in Primary Project DB13.

[0030] The primary case database 13 consists of multiple tables. Figure 4 shows an example of the layout of one of these tables, the primary case table. As shown in Figure 4, the primary case table stores information such as the primary case ID used to identify each primary case, the member ID of the user who generated the primary case, the name of the primary case, the date and time it occurred, the conditions, the completion status, and the transition status.

[0031] The above conditions are the various conditions (product specifications, price, delivery date, etc.) for the initial project provided by the user. The "Conclusion Status" indicates the status of the conclusion of the order-based production contract for the initial project, and the "Transition Status" indicates the status of the transition from the initial order-based production to the second order-based production.

[0032] In this embodiment, the product specifications included in the above conditions consist of six items: color, size, function, design, material, and weight. Of course, this is merely an example, and the product specifications may consist of other items.

[0033] (D) Proposal DB14 Proposal DB14 is a database for storing information on each proposal for a primary project. Each creator can propose various conditions for a primary project. Proposal DB14 is constructed based on the conditions proposed by the creators.

[0034] The proposal database 14 consists of multiple tables. Figure 5 shows an example of the layout of one of these tables, the proposal table. As shown in Figure 5, the proposal table stores various information such as the proposal ID of the manufacturer who made the proposal, the primary project ID of the primary project to which the proposal is being made, and the conditions related to the proposal, all linked to the proposal ID used to identify each proposal provided by the manufacturer. These conditions are various conditions (specifications, price, delivery date, etc.) for the primary project provided by the manufacturer.

[0035] (E) Contract Conclusion DB15 Contract Conclusion DB15 is a database for storing information about a contract for production of a primary project once that contract has been concluded. Contract Conclusion DB15 consists of multiple tables. Figure 6 shows an example of the layout of one of these tables, the Conclusion Table. As shown in Figure 6, the Conclusion Table stores various information such as the primary project ID of the primary project related to the contract, the manufacturer ID of the manufacturer that concluded the contract, the date and time the contract was concluded, and the terms and conditions related to the contract, all linked to the contract ID used to identify each contract for production. These terms and conditions are the various conditions (specifications, price, delivery date, etc.) for the primary project that were finally agreed upon by the user and the manufacturer.

[0036] (F) Secondary Project DB16 The Secondary Project DB16 is a database for storing information about secondary projects, which are projects that are subject to secondary order production. As described later, secondary projects arise in response to requests from users who are the customers of primary projects, and information about these secondary projects is stored in the Secondary Project DB16 at the time of their occurrence and at appropriate intervals.

[0037] The secondary project database 16 consists of multiple tables. Figure 7 shows an example of the layout of one of these tables, the secondary project table. As shown in Figure 7, the secondary project table stores various information, such as the secondary project ID used to identify each secondary project, the primary project ID of the primary project from which the secondary project originated, the producer ID of the producer in that primary project, the date and time the secondary project occurred, and the items and conditions of the specifications that can be changed. These conditions are various conditions (price, delivery date, etc.) for the secondary project provided by the producer.

[0038] Furthermore, the user who placed the order for the first project can specify which items from the product specifications can be changed. For example, if a user has a preference for color, it is expected that the color will not be changed in the second project. In that case, the user will inform the production support server 1 that items other than color can be changed. In addition, the manufacturer or service provider may specify other specification items that can be changed. The second project DB 16 stores information indicating the specification items that have been designated as changeable by the user, manufacturer, or service provider.

[0039] (G) Improvement Request DB17 The Improvement Request DB17 is a database for storing information on improvement requests for the primary project. Each user provides the production support server 1 with the specifications of the product they want for the secondary project as an improvement request for the primary project. The Improvement Request DB17 is built based on the improvement requests provided by the users.

[0040] The Improvement Request DB17 consists of multiple tables. Figure 8 shows an example of the layout of one of these tables, the Improvement Request table. As shown in Figure 8, the Improvement Request table stores various pieces of information, such as the user's member ID, the secondary case ID of the secondary case to which the improvement request was made, the date and time the improvement request was made, and the content of the improvement request, all linked to a request ID that identifies each improvement request provided by the user.

[0041] (H) Purchase DB18 The purchase DB18 is a database for storing information indicating the purchase details when a user purchases a product obtained through the production of a secondary order. The purchase DB18 is composed of a plurality of tables. FIG. 9 is a diagram showing an example of the layout of a purchase table, which is one of them. As shown in FIG. 9, in the purchase table, for each purchase ID for identifying each purchase, the secondary order ID of the secondary order related to the purchase, the member ID of the user who made the purchase, the purchase date and time, whether there is an improvement in the product specification, and each piece of information such as conditions are stored. These conditions are various conditions (specifications, prices, delivery dates, etc.) for the secondary order finally agreed upon by the user and the producer.

[0042] (System Operation) Next, the operation of the production support server 1 configured as described above will be described separately for two scenarios: primary order production and secondary order production.

[0043] (1) Primary Order Production In primary order production, the production support server 1 executes the following respective processes while collaborating with the user terminal 2, the producer terminal 3, etc. (1a) Primary order registration process for registering a primary order according to the user's request (1b) Producer proposal process for receiving a proposal from the producer for the primary order (1c) Proposal confirmation process for the user to confirm the proposal (1d) Contract establishment support process for supporting the establishment of a production contract related to the primary order Hereinafter, the details of each of these processes will be described.

[0044] (1a) Primary Order Registration Process A user who has completed member registration can register a primary order, which is the target order for primary order production. The primary order registration process is a process executed by the production support server 1 and the user terminal 2 at that time.

[0045] Figure 10 is a flowchart showing an example of the procedure for primary case registration processing. As shown in Figure 10, according to an instruction from a user who wishes to register a primary case, the user terminal 2 transmits a registration request for the primary case to the production support server 1 (S101). When the production support server 1 receives this registration request (S201), it transmits a registration item input request for requesting the input of each item necessary for the registration of the primary case to the user terminal 2 (S202).

[0046] When the user terminal 2 receives the above registration item input request (S102), it displays a primary case registration screen for inputting each item on the display unit (S103). Figure 11 is a diagram showing an example of the primary case registration screen. As shown in Figure 11, the primary case registration screen 201 is provided with input fields for the name, summary, image, and various conditions of the primary case. Here, the various conditions include product specifications such as color and size, budget, quantity, and delivery date, etc.

[0047] In addition, on the primary case registration screen 201, there are provided a "fill in by myself" button 211 for instructing the user to input each item by themselves and an "input support" button 212 for instructing to receive input support from the production support server 1. For example, a user who is familiar with order production clicks the button 211, and a user who is not familiar with order production clicks the button 212.

[0048] The user terminal 2 determines whether the above input support is required based on the button clicked by the user (S104). Here, when the button 211 is clicked, the user terminal 2 determines that input support is not required ( "not required" in S104), makes each input field on the primary case registration screen 201 in an input-enabled state, and accepts the input of each item from the user (S105). As a result, as exemplified in Figure 11, each item is displayed in each input field of the primary case registration screen 201.

[0049] Next, the user terminal 2 transmits registration information, including each item entered by the user, to the production support server 1 (S106). Upon receiving the registration information (S203), the production support server 1 registers each item contained in the registration information into the primary project DB 13 (S204). This completes the registration of the primary project.

[0050] On the other hand, if button 212 on the primary project registration screen 201 is clicked, the user terminal 2 determines that input assistance is needed ("needed" in step S104) and proceeds to the input assistance process. This input assistance process is executed through the cooperation of the user terminal 2, the production support server 1, and the generation AI server 4.

[0051] Figure 12 shows an example of an input support screen displayed on the user terminal 2 during input support processing. Data input and output on the user terminal 2 during this input support processing is performed in a so-called chat format. In the example shown in Figure 12, the words "red suitcase" are entered into the input field (the field on the left side of the page) of the input support screen 202 as information indicating the product the user desires. When this text is passed from the user terminal 2 to the production support server 1, the production support server 1 uses that text to generate a prompt for the generation AI server 4. For example, the production support server 1 generates a prompt such as "You are a manufacturer that performs custom orders. For a customer who wants a red suitcase, please propose the name, overview, color, dimensions, purpose of use, and detailed description of the bag," and sends this to the generation AI server 4.

[0052] The generation AI server 4 uses the LLM 41 to generate a response to the above prompt and sends it to the production support server 1. Upon receiving this response, the production support server 1 organizes it into a predetermined format and sends it to the user terminal 2. The user terminal 2, having received the response from the production support server 1, outputs the response in the output field (the field on the right side of the page) of the input support screen 202.

[0053] If the user has any suggestions for improvements to the product specifications shown in the response, they enter the words indicating those improvements into the input field on the input support screen 202 (for example, "I want a bigger one" as shown in Figure 12). This text is passed to the production support server 1 and processed in the same manner as above, resulting in a response showing the product specifications that reflect the improvements being output to the output field on the input support screen 202.

[0054] The above process is repeated until there are no further improvements needed for the product specifications. As a result, the product specifications desired by the user are output to the output field of the input support screen 202. When the user then instructs the end of the input support process, the primary project registration screen 201 shown in Figure 11 is displayed, and the product specifications output in the output field of the input support screen 202 shown in Figure 12 are copied to each input field on the primary project registration screen 201. In this way, by using the input support process, even users unfamiliar with custom manufacturing can input appropriate information regarding product specifications. The information output in the output field of the input support screen 202 is registered in the primary project DB 13. This completes the registration of the primary project.

[0055] (1b) Maker Proposal Processing: Registered makers can view the contents of primary projects registered by users and propose conditions for those primary projects. The maker proposal processing is a process executed by the production support server 1 and the maker terminal 3 at that time.

[0056] Figure 13 is a flowchart illustrating an example of the procedure for processing a manufacturer's proposal. As shown in Figure 13, the manufacturer's terminal 3 sends a case viewing request to the production support server 1 requesting to view the contents of a primary case, in accordance with the manufacturer's instructions (S301). Upon receiving this case viewing request (S401), the production support server 1 sends case content information to the manufacturer's terminal 3, indicating the contents of primary cases that are registered in the primary case DB 13 and for which a contract has not yet been concluded (S402).

[0057] When the manufacturer terminal 3 receives the above-mentioned project details information (S302), it displays a project display screen on its display unit that shows the information indicated in the project details information (S303). This project display screen displays conditions such as product specifications, budget, and desired delivery date provided by the user.

[0058] The manufacturer reviews the information displayed on the project display screen and considers whether or not they can undertake the project. If they can, they click a designated button on the project display screen to propose product specifications, costs, delivery dates, and other conditions. Upon receiving this click, the manufacturer's terminal 3 displays a proposal registration screen for registering the proposal (S304).

[0059] Figure 14 shows an example of the proposal registration screen described above. As shown in Figure 14, the proposal registration screen 301 has input fields for entering various conditions such as product specifications, estimated unit price, quantity, and delivery date. The manufacturer enters the proposed content for each condition into the input fields, taking into account the user's desired conditions. If there are any unclear points regarding the user's desired conditions, a message indicating that further adjustments will be made will be entered (for example, "Please let us confirm the type of red during the specification adjustment" in Figure 14).

[0060] Furthermore, the proposal registration screen 301 includes an additional input field for entering the reason if the estimated cost exceeds the user's desired budget. The creator will also fill in this input field as needed. If the estimated cost exceeds the user's desired budget, an input field may be provided for entering advice on how to bring the cost within the desired budget. Such advice is often beneficial to the user. For example, information such as "changing the color and size to XX will bring it within the desired budget" may be entered as advice from the creator.

[0061] When the creator terminal 3 receives input of the proposal content from the creator via the input fields of the proposal registration screen 301 (S305), it transmits proposal content information indicating the content of the proposal to the production support server 1 (S306). When the production support server 1 receives the proposal content information (S403), it registers each piece of information contained in the proposal content information in the proposal DB 14 (S404).

[0062] Next, the production support server 1 notifies the user who registered the initial project that a proposal has been received from the producer (S405). This notification is made by means such as email. This allows the user to know that a proposal has been received from the producer for their initial project. If the user wishes to review the proposal, the following proposal confirmation process is performed.

[0063] Furthermore, if many primary projects are registered, it may be difficult for a producer to find a primary project they can handle. Therefore, the degree of matching between each primary project and each producer may be calculated, and the production support server 1 may provide each primary project to each producer according to that degree. For example, the degree of matching between the attributes of each producer registered in the producer DB 12 (production target, areas of expertise, etc.) and each producer's production record, and the content of each primary project may be calculated, and primary projects with a high degree of matching may be provided to producers in order. Alternatively, information such as the product that the producer wants to produce may be obtained from the producer in advance, and that information may be used to calculate the degree of matching mentioned above. This makes it possible to efficiently provide each producer with primary projects that are highly compatible with them.

[0064] (1c) Proposal Confirmation Process: A user who has received a proposal from the producer accesses the production support server 1 using the user terminal 2 to confirm its contents. This initiates the proposal confirmation process.

[0065] Figure 15 is a flowchart showing an example of the procedure for the proposal confirmation process. As shown in Figure 15, the user terminal 2 sends a proposal viewing request to the production support server 1 requesting to view the content of the proposal from the producer, in accordance with the user's instructions (S501). When the production support server 1 receives this proposal viewing request (S601), it sends proposal content information, which shows the content of the proposal from the producer to the user registered in the proposal DB 14, to the user terminal 2 (S602).

[0066] When the user terminal 2 receives the above-mentioned proposal information (S502), it displays a proposal display screen on its display unit, which shows the information indicated in the proposal information (S503). Figure 16 is a diagram showing an example of the proposal display screen. As shown in Figure 16, the proposal display screen 203 displays the information from the proposer, such as product specifications, cost, and delivery date.

[0067] The user reviews the proposal from the manufacturer using the proposal display screen 203 and decides whether or not to commission the manufacturer for production. If the user decides to commission the manufacturer, they click the "Decided" button 231 on the proposal display screen 203; if the user decides not to commission the manufacturer, they click the "Decline" button 232.

[0068] User terminal 2 determines whether a request has been made to the manufacturer by the button clicked by the user (S504). If button 232 is clicked, user terminal 2 determines that no request has been made to the manufacturer (NO in S504) and terminates the process. On the other hand, if button 231 is clicked, user terminal 2 determines that a request has been made to the manufacturer (YES in S504) and proceeds to the condition details negotiation process to negotiate the details of the conditions.

[0069] In the detailed negotiation process described above, the user and the manufacturer negotiate the details of various product conditions (specifications, cost, delivery date, etc.). This negotiation takes place in a chat format using user terminal 2 and manufacturer terminal 3. This allows the final conditions for the product to be finalized, making it ready for order production. This information showing the final conditions is temporarily stored on production support server 1.

[0070] The details of the negotiations conducted during the above-mentioned detailed negotiation process may be automatically aggregated by the production support server 1. For example, the production support server 1 may organize the chat content using natural language processing to create a specification document. By using this specification document in the contract conclusion support process described later, negotiations toward contract conclusion can be carried out smoothly.

[0071] Furthermore, if multiple creators submit proposals for a single initial project, each proposal may be assigned a priority and displayed on the proposal display screen 203 according to that priority (for example, displaying them in order from highest priority). Various criteria can be used to set this priority. For example, the degree of matching between the user's desired conditions for the initial project and the conditions in each proposal may be calculated, and proposals with a high degree of matching may be assigned a higher priority.

[0072] (1d) Contract Formation Support Process After the detailed negotiation process described above, the user and the manufacturer initiate the contract formation support process to conclude the order for production. In this contract formation support process, both the user and the manufacturer confirm the content of the final conditions determined in the detailed negotiation process. Specifically, the user uses user terminal 2 to obtain information indicating the final conditions from production support server 1, confirms the content, and provides information to production support server 1 indicating that the confirmation has been made. Similarly, the manufacturer uses manufacturer terminal 3 to obtain information indicating the final conditions from production support server 1, confirms the content, and provides information to production support server 1 indicating that the confirmation has been made. In this way, once the content of the final conditions has been confirmed by both the user and the manufacturer, production support server 1 requests user terminal 2 to input information indicating whether or not to confirm the order. If the user inputs information indicating that they will confirm the order, production support server 1 notifies the manufacturer accordingly. This concludes the conclusion of the order for production. Production support server 1 registers each piece of information, including the final conditions, in the conclusion DB 15.

[0073] After the order-to-order contract is concluded as described above, the user makes the payment, the manufacturer produces the product, and the finished product is delivered from the manufacturer to the user. This completes the initial order-to-order process.

[0074] (2) Secondary Order Production Users who have received a product through primary order production may consider moving on to secondary order production. For example, if a user desires improvements or developments to the product produced according to their requests, they may decide to move on to secondary order production. As will be described later, in secondary order production, improvements and developments to the product produced in primary order production are carried out by a different user than the user who ordered the primary order production. When a product is produced and sold through secondary order production, the profits are returned to the user who provided the original idea (the customer who ordered the primary order production). Hereinafter, the user who ordered the primary order production will be referred to as the primary user, and the product produced through primary order production will be referred to as the primary product. Similarly, a user who requests changes to the specifications of the primary product in secondary order production, that is, a user who contributes to the improvement and development of the primary product, will be referred to as the secondary user, and the product produced through secondary order production will be referred to as the secondary product. Here, the primary user and the secondary user are different users.

[0075] In secondary order production, the production support server 1 works in cooperation with user terminal 2 and manufacturer terminal 3 to perform the following processes: (2a) Secondary project registration process to register secondary projects in response to requests from primary users; (2b) Secondary project provision process to provide the details of the secondary project to secondary users; (2c) Improvement purchase process to purchase products with improved specifications; (2d) Rebate calculation process to calculate the rebate amount to be paid to primary users. The details of each of these processes will be explained below.

[0076] (2a) Secondary project registration process A primary user can request to register a secondary project, which is a project that is the target of secondary order production. The secondary project registration process is performed by the production support server 1 at that time. Figure 17 is a flowchart showing an example of the procedure for the secondary project registration process. First, the production support server 1 receives a secondary project registration request from the primary user's terminal 2 (S701). This registration request includes the primary project ID of the primary project, which makes it possible to determine which primary project the registration request corresponds to.

[0077] Next, the production support server 1 notifies the primary product manufacturer that a secondary project has occurred (S702). This notification is made, for example, by email. This allows the primary product manufacturer to understand that a secondary project has arisen in response to the primary user's request and is related to the primary project.

[0078] The manufacturer accesses the production support server 1 using the manufacturer terminal 3, and then considers whether production is possible at the same price as the initial project. If they wish to change the price, they enter the estimated amount. The manufacturer also enters the delivery date in the same manner. The manufacturer terminal 3 then transmits condition information, including the information entered in this way, to the production support server 1.

[0079] When the production support server 1 receives condition information transmitted from the producer terminal 3 (S703), it registers each piece of information contained in that condition information in the secondary project DB 16 (S704). This completes the registration of the secondary project.

[0080] In this embodiment, as described above, secondary projects are registered according to the wishes of the primary user. Therefore, if there is no request from the primary user, secondary projects will not be registered, and the specifications of the primary product will not be provided to the secondary user. In other words, if consent is not obtained from the primary user, the specifications of the primary product will not be provided to the secondary user. Thus, situations such as the specifications of the primary product being provided to other users against the wishes of the primary user can be prevented.

[0081] Furthermore, as described above, secondary projects are registered only when condition information is received from the creator. Therefore, if the creator does not consent to the registration of a secondary project and does not transmit the condition information, the secondary project will not be registered. Thus, situations such as the specifications of the primary product being provided to each user against the creator's wishes can be prevented. Alternatively, the production support server 1 may confirm with the creator whether or not they consent to the registration of a secondary project, and if consent is obtained from the creator, the secondary project may be registered.

[0082] (2b) Secondary project provision processing Information regarding secondary projects registered as described above is provided to secondary users who are different from primary users. The secondary project provision processing is a process that is executed by the production support server 1 and the user terminal 2 at that time.

[0083] Figure 18 is a flowchart illustrating an example of the procedure for providing secondary projects. As shown in Figure 18, the user terminal 2 sends a secondary project viewing request to the production support server 1 requesting to view the contents of a secondary project, in accordance with instructions from the secondary user (S801). Upon receiving this secondary project viewing request (S901), the production support server 1 sends secondary project content information, which indicates the contents of the secondary project registered in the secondary project DB 16, to the user terminal 2 (S902).

[0084] When user terminal 2 receives the secondary case details information (S802), it displays a secondary case display screen on its display unit, which shows the information indicated in the secondary case details information (S803).

[0085] Figure 19 shows an example of the secondary project display screen described above. As shown in Figure 19, the secondary project display screen 204 displays two screens: the standard purchase screen 241 and the improved purchase screen 242. The standard purchase screen 241 is used when purchasing a secondary product with the same specifications as the primary product, while the improved purchase screen 242 is used when purchasing a secondary product with modified specifications from the primary product.

[0086] The purchase screen 241 displays an image of the primary product, as well as the name, overview, and price of the primary project. Other specifications of the primary product (color, size, etc.) may also be displayed. Note that the specifications of the primary product may be displayed on a separate screen. The purchase screen 241 also includes a purchase button 243 for prompting the user to make a purchase.

[0087] The improved purchase screen 242 has input fields for entering improvement requests for the primary product. Below the word "Tags," there are selection buttons for each item of product specifications (color, size, etc.). There is also an overview input field 244 for entering an overview of the improvements related to the selected item, a detail input field 245 for entering details of the improvements, an image attachment button 246 for attaching an image, and a submit button 247 for instructing the submission of each entered piece of information to the production support server 1.

[0088] The secondary user refers to the secondary project display screen 204 to decide whether or not to purchase the secondary product. If they decide to purchase, they then decide whether to purchase it without changing the specifications from the primary product ("purchase as is") or to purchase it after changing the specifications ("purchase with modifications"). Here, if the secondary user chooses to "purchase as is," they click the purchase button 243, and if they choose to "purchase with modifications," they enter information into the input fields on the purchase with modifications screen 242.

[0089] Although not shown in Figure 19, the secondary project display screen 204 also includes a "Do Not Purchase" button to indicate that neither "Purchase as is" nor "Purchase with Improvements" should be performed. Secondary users will click the "Do Not Purchase" button if the specifications of the product they wish to purchase differ significantly from those of the primary product.

[0090] Returning to Figure 18, user terminal 2 determines, based on the operation by the secondary user, whether or not to purchase the secondary product, and if so, whether or not to make improvements (S804). If the "Do not purchase" button is clicked, user terminal 2 determines that the secondary user has no intention to purchase (NO in S804) and terminates the process. On the other hand, if the "Purchase" button 243 is clicked, user terminal 2 determines that it has received a purchase request for a secondary product with the same specifications as the primary product ("No improvements" in S804) and sends purchase request information indicating that purchase request to the production support server 1 (S805).

[0091] When the production support server 1 receives the above purchase request information (S903), it notifies the manufacturer that a purchase request has been made for a secondary product with the same specifications as the primary product (S904). This notification is made by means of email or other means. In this case, after payment by the secondary user and production of the secondary product by the manufacturer, the manufactured secondary product is delivered from the manufacturer to the secondary user. The production support server 1 also registers information including the specifications of this secondary product in the purchase DB 18. At this time, information indicating that there were no improvements to the specifications is stored.

[0092] On the other hand, if input is made in the input fields on the improved purchase screen 242, the user terminal 2 determines that it has received a request to purchase a secondary product in which the specifications of the primary product have been changed (in S804, "Improvements Available"), and proceeds to the improved purchase process described below.

[0093] (2c) Improvement Purchase Process Diagram 20 is a flowchart showing an example of the procedure for improvement purchase processing. As shown in Figure 20, the user terminal 2 receives improvement request information regarding product specification improvement requests (change requests) from the secondary user (S1001). This input reception is performed using the improvement purchase screen 242.

[0094] Figures 21A and 21B show an example of the improvement purchase screen 242 when inputting improvement request information. As shown in Figure 21A, below the word "Tag", selection buttons are displayed for items that are specified as changeable in the secondary project DB 16 from the specifications items of the secondary product (in this embodiment, six items: color, size, function, design, material, and weight). In Figure 21A, an example is shown where the selection button is not displayed for the item "Design" because it is not changeable. The secondary user identifies the item they want to improve from these items and selects it. Next, the secondary user enters an overview of the improvement for the selected item in the overview input field 244, and then enters the details of the improvement in the details input field 245. In the example shown in Figure 21B, the selection button for the item "Color" is selected, and the words "Change the color" are entered as the overview of the improvement, and the words "I would like the suitcase body changed from red to blue, and the handle changed to gold" are entered as details. Secondary users can also input images by clicking the image attachment button 246.

[0095] Furthermore, selection buttons for items whose specifications cannot be changed do not necessarily have to be displayed as described above, or they may be displayed but configured to be unselectable. In the latter case, it is preferable that the selection buttons are displayed in a manner that makes it clear they cannot be selected (e.g., colored differently from other selection buttons, with a message such as "Cannot be selected" or an "X" mark).

[0096] As described above, when the user terminal 2 receives the input of improvement request information, and the submission button 247 is clicked by a secondary user, the user terminal 2 sends the improvement request information to the production support server 1 (S1002). When the production support server 1 receives the improvement request information (S1101), it registers each piece of information contained in the improvement request information in the improvement request DB 17 (S1102).

[0097] Next, the production support server 1 extracts improvement request information provided by a secondary user different from the secondary user who provided the improvement information this time from the improvement request DB 17 and sends it to the user terminal 2 (S1103).

[0098] When user terminal 2 receives the above improvement request information (S1003), it displays an improvement purchase screen showing each piece of information included in the improvement request information (S1004). Figures 22A and 22B show an example of the improvement purchase screen. As shown in Figure 22A, the improvement purchase screen 242 displays text (such as "change color") indicating an overview of the improvements proposed by each secondary user, associated with checkboxes and heart marks. When the area containing the text indicating the overview of the improvements is clicked, text indicating the details of the improvements is displayed.

[0099] The heart icon above is a mark placed by secondary users who agree with the improvements. The number displayed next to the heart icon represents the number of times that heart icon has been checked, indicating the number of secondary users who agree with the improvements. The improvements are displayed from top to bottom, with the highest number of heart icons placed next to each improvement.

[0100] The above-mentioned improved purchase screen 242 displays information not only about improvements provided by secondary users who are viewing this improved purchase screen 242, but also about improvements provided by secondary users other than the one in question. Therefore, the secondary user can understand what improvement requests are being proposed by other secondary users and use this information as a reference when purchasing secondary products.

[0101] A secondary user, referring to the above-mentioned improvement purchase screen 242, identifies the improvements they wish to incorporate into the secondary product they wish to purchase and selects those improvements by checking the corresponding checkboxes displayed. Figure 22B shows an example of the improvement purchase screen 242 at that time. As shown in Figure 22B, when the checkbox is checked, the item name and a summary of the improvement are displayed.

[0102] When user terminal 2 receives the selection of improvements from the secondary user as described above (S1005), it sends improvement purchase request information, including information indicating the selected improvements, to the production support server 1 (S1006). When production support server 1 receives this improvement purchase request information (S1104), it notifies the manufacturer that a purchase request has been made for a secondary product with improved specifications from the primary product (S1105). This notification is made by means of email or other means. In this case, after payment by the secondary user and production of the secondary product by the manufacturer, the manufactured secondary product is delivered from the manufacturer to the secondary user. This completes the series of steps for secondary order production. Production support server 1 also registers each piece of information, including the specifications of this secondary product, in the purchase DB 18. At this time, information indicating that the specifications have been improved is stored.

[0103] In this improved purchase process, the same process as the detailed negotiation process for the initial order production described above may be carried out. This will allow for fine-tuning of specifications. Furthermore, as with the initial order production described above, the content of the negotiations may be automatically aggregated by the production support server 1.

[0104] As described above, in this embodiment, it is possible to request the purchase of a secondary product with modified specifications from a primary product. Even if the secondary user is unfamiliar with custom manufacturing, they can refer to the specifications of a primary product that has a track record of custom manufacturing, making it easy to make appropriate specification changes. This promotes secondary custom manufacturing, which is a great benefit for manufacturers as well.

[0105] Furthermore, in this embodiment, as described above, only secondary users who have submitted improvement requests can view improvement requests submitted by other secondary users. Since submitting improvement requests contributes to the improvement and development of the primary product, only those who have done so can enjoy the benefit of being able to view improvement requests from others. However, secondary users who have not submitted improvement requests may also be able to view improvement requests submitted by other secondary users. This would create a positive cycle, for example, where a secondary user who does not have any improvement ideas can come up with new improvement requests by referring to improvement requests submitted by other secondary users.

[0106] In this embodiment, the production support server 1 provides each secondary user with all improvement requests submitted by that user, but it is not limited to this. For example, it may provide only improvement requests related to secondary products that were ultimately purchased to each secondary user, and not provide improvement requests related to secondary products that were not purchased. In this case, improvement requests related to secondary products that were not ultimately purchased but progressed to the detailed negotiation process described above may be provided to each secondary user. Furthermore, it may be decided whether or not to provide improvement requests submitted by a secondary user to other secondary users based on the secondary user's past purchase history of secondary products and their history of submitting improvement requests. Such a configuration offers advantages, such as eliminating the influence of improvement requests irresponsibly submitted by secondary users who have no intention of purchasing.

[0107] Secondary products manufactured through secondary order production can be purchased by users other than the original secondary user who placed the order. For example, each user accesses the production support server 1 using user terminal 2, and a screen for purchasing improved products is displayed on the display of user terminal 2. Figure 23 shows an example of such an improved product purchase screen. As shown in Figure 23, the improved product purchase screen 205 is provided with a display field that shows the name and overview of each improved product, and a details / purchase button 251 for viewing the details of that improved product and instructing the user to purchase it. Each user can identify the improved product they wish to purchase from the displayed improved products and proceed with the purchase procedure by clicking the details / purchase button 251 for the identified improved product.

[0108] By the way, it is also possible to set up a third-stage production run where the manufacturer produces products derived from the second-stage production run based on improvement requests for the second-stage product. However, since it may not be desirable for production to continue indefinitely, it is also possible to prohibit the acceptance of new production orders after the second-stage production run.

[0109] (2d) Processing to calculate the amount of compensation In secondary order production, as described above, benefits are recognized for both the secondary user and the manufacturer, so it is preferable to return the profits to the primary user in the primary order production that formed the basis of the secondary order production. The processing to calculate the amount of compensation to the primary user is performed by the production support server 1.

[0110] Figure 24 is a flowchart showing an example of the procedure for calculating the refund amount. As shown in Figure 24, the production support server 1 calculates the number of secondary products purchased, categorized by whether or not the specifications have been improved, by referring to the purchase DB 18 (S1201). This calculates the number of purchases made "as is" (number of purchases without improvements) and the number of purchases made "improved" (number of purchases with improvements).

[0111] Next, the production support server 1 calculates the amount of compensation to the primary user who ordered the primary product that formed the basis of the secondary product by multiplying the calculated number of purchases by a predetermined compensation rate (S1202). In this case, for example, it is possible to consider that the primary user's contribution is greater for the number of purchases without improvements and apply a higher compensation rate than for the number of purchases with improvements, or to evaluate that the improvement was encouraged and set a higher compensation rate for the number of purchases without improvements than for the number of purchases with improvements. Of course, the same compensation rate may also be applied to the number of purchases with and without improvements. For this reason, the production support server 1 may calculate the total number of purchases of secondary products regardless of whether improvements were made or not and calculate the compensation amount according to that number of purchases.

[0112] By providing the calculated rebate amount to primary users, primary order production will be promoted. This will also promote secondary order production, creating a desirable situation for primary users, secondary users, and manufacturers alike.

[0113] Furthermore, it is conceivable that some form of compensation could be provided not only to primary users but also to secondary users. For example, secondary users who propose improvements that receive support and are adopted by many secondary users could be given a reward amount calculated based on the number of supporters. This is expected to further promote secondary order production.

[0114] (Other Embodiments) In the embodiments described above, the scenes of primary order production and secondary order production were explained, but the present invention can also be applied to the subsequent mass production of products. For example, the production support server 1 determines whether or not to mass-produce based on the number of secondary products purchased in secondary order production and notifies the manufacturer of the result of that determination. For example, if the number of purchases exceeds a predetermined number, it may be determined that there are many potential customers and propose mass production. Alternatively, the production support server 1 may determine which specifications of products should be mass-produced based on the number of purchases of each specification of secondary products and notify the manufacturer of the result of that determination.

[0115] Furthermore, in the above embodiment, the manufacturer is the same for both the primary and secondary order production, but this is not the only way to do so. For example, after obtaining consent from the primary user, the specifications and / or the primary product itself may be provided to a different manufacturer than the primary product manufacturer, and they may be asked whether they can handle secondary order production. Alternatively, the primary user may produce something themselves as the primary product, provide its specifications and other details to each manufacturer, and ask whether they can handle secondary order production. In these cases, the manufacturer who responds that they can handle secondary order production is set as the manufacturer of the secondary product, and the production support server 1 can perform the same processing as in the above embodiment, thereby realizing secondary order production.

[0116] The countries of residence of each manufacturer may be the same or different. When a user selects a manufacturer to commission, the country of residence of the manufacturer can be a useful factor in their decision. Therefore, it is preferable for the production support server 1 to provide the user with information about the country of residence of the manufacturer (e.g., country name or country code). Similarly, since the countries of residence of each user may differ, it is preferable for the production support server 1 to provide the manufacturer with information about the country of residence of each user. It is envisioned that this information will be managed by providing corresponding fields in the member DB 11 and the manufacturer DB 12.

[0117] If information regarding the location of users and creators is managed as described above, the production support server 1 may provide statistically compiled location information. For example, by showing statistical information such as "40% of registered creators are in Japan, 30% are in the United States, and 20% are in Europe," users can understand which regions have a high concentration of creators and use this as a reference when selecting a service provider. On the other hand, for creators, showing statistical information such as "50% of registered users are in Asia, and 30% are in North America" ​​helps them understand which regions have the highest demand. Providing such statistical information can support decision-making for both users and creators and further enhance the convenience of the system.

[0118] 1. Product Production Support Server 11. Member Database 12. Producer Database 13. Primary Project Database 14. Proposal Database 15. Accepted Project Database 16. Secondary Project Database 17. Improvement Request Database 18. Purchase Database 2. User Terminal 3. Producer Terminal 4. Generation AI Server 41. Large-Scale Language Model (LLM) 101. Internet

Claims

1. A product manufacturing support system comprising: a storage unit that stores specification information indicating the specifications of a product manufactured according to the requests of a specific user; a first provision unit that provides the specification information to a user other than the specific user; a reception unit that receives a request from the other user to change the specifications indicated by the specification information; a modification unit that changes the specifications in response to the modification request; and a second provision unit that provides the product manufacturer with specification information indicating the modified specifications.

2. The product manufacturing support system according to claim 1, wherein the first providing unit provides the specification information to the other user when consent is obtained from the specific user.

3. The product manufacturing support system according to claim 2, wherein the first providing unit further provides the specification information to the other user if the manufacturer's consent is obtained.

4. The product manufacturing support system according to claim 3, further comprising an acquisition unit that acquires conditions including the price of the product from the manufacturer, and the first provision unit further provides the conditions to the other user.

5. The product manufacturing support system according to claim 1 or 2, wherein the specifications of the product consist of multiple items, and the receiving unit prevents the acceptance of change requests from other users for a specific item among the multiple items.

6. The product manufacturing support system according to claim 5, wherein the receiving unit is unable to accept change requests from other users for the specific items specified by the specific user.

7. The product manufacturing support system according to claim 1 or 2, further comprising a third providing unit that provides the other user with specification information indicating the modified specifications in response to a change request received from a user different from the other user.

8. The product manufacturing support system according to claim 7, wherein the third providing unit, when the receiving unit receives the change request from the other user, provides the other user with specification information indicating the specifications that have been changed in accordance with the change request received from the different user.

9. The product manufacturing support system according to claim 1 or 2, further comprising a purchase request receiving unit that receives requests from other users to purchase the manufactured product without changing its specifications, or to purchase the product with its specifications changed.

10. The product manufacturing support system according to claim 9, further comprising a calculation unit that calculates the amount of refund to a specific user according to the number of purchases of the product by other users, depending on whether or not the specifications have been changed.

11. A product manufacturing support method comprising: providing specification information indicating the specifications of a product manufactured according to the requests of a specific user to a user other than the specific user; receiving a request from the other user to change the specifications indicated by the specification information; changing the specifications in accordance with the change request; and providing specification information indicating the changed specifications to the manufacturer of the product.

Images