Request mediation system, information processing device, and request mediation method

Abstract

To facilitate agreement among multiple businesses, we aim to achieve mediation that satisfies each business in a way that is acceptable to them. [Solution] The request mediation system comprises a request reception unit, a request feasibility determination unit, a conflict hypergraph creation unit, and a compromise proposal formulation unit. The compromise proposal formulation unit creates one or more compromise proposals for requests based on the conflict hypergraph created by the conflict hypergraph creation unit, identifies one or more compromise proposals from among the one or more, and outputs the identified one or more compromise proposals. The compromise proposal formulation unit has a function to generate a set of requests that have common parts with all the conflicts included in the conflict hypergraph as compromise proposals, and a function to calculate a score for the compromise proposals based on statistics related to either the request or the request creator, or both the request and the request creator, and identifies one or more compromise proposals from among the one or more based on the score.

Description

Technical Field

[0001] The present invention relates to a claim mediation system, an information processing apparatus, and a claim mediation method, and more particularly to a claim mediation system, an information processing apparatus, and a claim mediation method related to consensus formation among multiple operators.

Background Art

[0002] In the cooperation of multiple operators, the requirements of each operator may conflict, and it may be impossible to satisfy all requirements. In such a case, mediation to compromise one of the requirements is necessary, but it takes a great deal of effort and time to correctly grasp the conflicting relationship between the requirements and formulate a compromise plan that all operators can agree on.

[0003] As a technology for assisting in the mediation of claims among multiple operators, Japanese Patent Application Laid-Open No. 2023-136290 (Patent Document 1) states that "when the constraint information that causes the infeasibility of the executable solution is due to the mutual interference between the constraint information, the allowable range review request unit 137 requests re-input to the participating company that has set the constraint information that can obtain the executable solution by deleting any one of the mutually interfering constraint information."

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] In the technology described in Patent Document 1, no consideration is given to fairness among operators, so it is impossible to achieve mediation of claims in a form acceptable to each operator. Therefore, an object of the present invention is to achieve mediation of claims in a form acceptable to each operator.

Means for Solving the Problems

[0006] A typical example of the present invention for solving the above problems is a request mediation system that recommends a request to be compromised from among multiple requests, comprising: a request receiving unit that receives the requests and the creators of the requests; a request feasibility determination unit that determines whether multiple requests can be realized simultaneously; a conflict hypergraph creation unit that generates one or more conflicts, which are sets of requests that cannot be realized simultaneously unless at least one of the subsets of the requests is compromised, based on the determination result of the request feasibility determination unit, and creates a conflict hypergraph, which is a set of the conflicts; and the conflict hypergraph A compromise proposal formulation unit has the following functions: it creates one or more compromise proposals for the requirements based on the conflict hypergraph created by the conflict creation unit, identifies one or more compromise proposals from among the one or more compromise proposals, and outputs the identified one or more compromise proposals; the compromise proposal formulation unit has the function of generating a set of requirements that have common parts with all the conflicts included in the conflict hypergraph as the compromise proposals; and it has the function of calculating a score for the compromise proposals based on statistics relating to either the requirements or the creators of the requirements, or both the requirements and the creators of the requirements, and identifies one or more compromise proposals from among the one or more compromise proposals based on the score.

[0007] Another example of a typical aspect of the present invention is an information processing device having a processor, wherein the processor receives a plurality of requests, associating the requests with the creators of the requests, determines whether the plurality of requests can be realized simultaneously, generates one or more conflicts, which are sets of requests that cannot be realized simultaneously unless at least one of the subsets of the requests is compromised, creates a conflict hypergraph, which is a set of the conflicts, creates one or more sets of requests as compromise solutions based on the conflict hypergraph, has common parts with all the conflicts included in the conflict hypergraph, calculates a score for the compromise solutions based on statistics relating to either the requests and the creators of the requests, or both the requests and the creators of the requests, identifies one or more compromise solutions from the one or more compromise solutions based on the score, and outputs the identified one or more compromise solutions.

[0008] Another example of a typical aspect of the present invention is a request arbitration method using an information processing device having a processor, wherein the processor receives a plurality of requests, associating the requests with the creators of the requests, determines whether the plurality of requests can be realized simultaneously, generates one or more conflicts, which are sets of requests that cannot be realized simultaneously unless at least one of the subsets of the requests is compromised, creates a conflict hypergraph, which is a set of the conflicts, creates one or more sets of requests as compromise proposals based on the conflict hypergraph, has common parts with all the conflicts included in the conflict hypergraph, calculates a score for the compromise proposals based on statistics relating to either the requests and the creators of the requests, or both the requests and the creators of the requests, identifies one or more compromise proposals from the one or more compromise proposals based on the score, and outputs the identified one or more compromise proposals. [Effects of the Invention]

[0009] According to the present invention, it is possible to mediate demands in a way that is acceptable to each company. Other issues, configurations, and effects will be clarified by the following description of embodiments. [Brief explanation of the drawing]

[0010] [Figure 1] Figure 1 shows an example of the software configuration in Example 1. [Figure 2] Figure 2 shows an example of a hardware configuration. [Figure 3] Figure 3 shows an example of the processing flow of the request reception unit. [Figure 4] Figure 4 shows an example of the processing flow of the request extraction unit. [Figure 5] Figure 5 shows an example of the processing flow of the conflict hypergraph creation unit. [Figure 6] Figure 6 shows an example of the processing flow of the requirement feasibility determination unit. [Figure 7] Figure 7 shows an example of the processing flow in the piping plan creation section. [Figure 8] Figure 8 shows an example of the processing flow of the compromise proposal formulation department. [Figure 9] Figure 9 shows an example of the process flow for calculating the score of a compromise when the number of demands included in the compromise is calculated as the score. [Figure 10] Figure 10 shows an example of the process flow for calculating the score of a compromise when the sum of the importance levels of the requirements included in the compromise is calculated as the score. [Figure 11] Figure 11 shows an example of the process flow for calculating the score of a compromise when the distribution among users of the number of requests included in the compromise among the requests created by each user is calculated as the score. [Figure 12] Figure 12 shows an example of the processing flow of the hypergraph display unit. [Figure 13] Figure 13 shows an example of the flow of the planning process. [Figure 14]FIG. 14 is a diagram showing an example of a claim sentence which is an input to the claim extraction unit and a claim JSON which is an output. [Figure 15] FIG. 15 is a diagram showing an example in a certain expression form of a conflict hypergraph. [Figure 16] FIG. 16 is a diagram showing an example in a certain expression form of a compromise plan. [Figure 17] FIG. 17 is a diagram showing an example of a table of a claim DB. [Figure 18] FIG. 18 is a diagram showing an example of a table of a conflict DB. [Figure 19] FIG. 19 is a diagram showing an example of a screen for displaying the current plan and the claims input by the user to the user. [Figure 20] FIG. 20 is a diagram showing an example of a screen for the user to input a claim. [Figure 21] FIG. 21 is a diagram showing an example of a screen for displaying the current plan and the added claims to the user. [Figure 22] FIG. 22 is a diagram showing an example of a screen for displaying the current plan and the claims input by all users to the user. [Figure 23] FIG. 23 is a diagram showing an example of a screen for displaying the plan created by the user. [Figure 24] FIG. 24 is a diagram showing an example of a screen for displaying a plurality of compromise plans to the user. [Figure 25] FIG. 25 is a diagram showing an example of a screen for displaying a hypergraph representing a conflict to the user. [Figure 26] FIG. 26 is a diagram showing an example of a software configuration in Example 2. [Figure 27] FIG. 27 is a hardware configuration diagram for realizing the software configuration of FIG. 26. [Figure 28] FIG. 28 is a diagram showing another example of a screen for displaying a hypergraph representing a conflict to the user.

MODE FOR CARRYING OUT THE INVENTION

[0011] <<Example 1>> The following describes an embodiment in which the present invention is applied to a system in which multiple businesses collaborate to create piping plans for multiple piping routes. In this system, there are two types of users: requesting users, who are businesses that submit requests for piping plans, and mediating users, who mediate requests from multiple requesting users and aim to reach an agreement. In the following, unless it is necessary to specifically distinguish between mediating users and requesting users, they will simply be referred to as users.

[0012] Figure 1 is a software configuration diagram illustrating the processing flow when the present invention is applied to the above system. The processing flow based on the configuration shown in Figure 1 is as follows:

[0013] The request receiving unit 101 receives the request statement 111 (request) from the requesting user 121 and passes it to the request extraction unit 102.

[0014] The request extraction unit 102 creates a prompt 112 based on the request statement 111, inputs it to the generation AI 103, receives a request JSON 113 which is a request formatted in JSON format as output, and passes it to the request reception unit 101.

[0015] The request receiving unit 101 receives the request JSON 113 from the request extraction unit 102 and stores it in the request DB 104 along with the information of the requesting user 121 who entered the request.

[0016] The conflict hypergraph creation unit retrieves one or more request JSON 113 from the request DB 104, inputs the combination of these requests into the request feasibility determination unit 106, and receives a feasibility determination result 114 indicating whether the combined requests can be simultaneously fulfilled. By repeating this process, the unit generates multiple conflicts, which are sets of requests that cannot be simultaneously fulfilled without compromising at least one of them, and stores these sets as a conflict hypergraph 115 in the conflict DB 107.

[0017] In this process, the request feasibility determination unit 106 inputs the combination of request JSON 113 to the piping plan creation unit 110 and obtains a piping plan 118 that satisfies the request as output, thereby determining whether the combined requests can be realized simultaneously.

[0018] The compromise proposal formulation unit 108 retrieves the conflict hypergraph 115 from the conflict DB 107, generates multiple compromise proposals which are sets of requirements that have common parts with all the conflicts contained therein, calculates a score for each of them based on the statistics of the requirements or their creators, and presents one or more compromise proposals, or compromise proposals 116, to the mediation user 120 based on that score.

[0019] The hypergraph display unit 109 retrieves the conflict hypergraph 115 from the conflict DB 107, renders it as a hypergraph with each request as a node and each conflict as a hyperedge, and presents it to the mediation user 120 as a hypergraph diagram 117.

[0020] Figure 2 shows the hardware configuration that realizes the setup shown in Figure 1.

[0021] Server 210 consists of a central processing unit 211, a storage device 212, and a communication device 213. The storage device 212 is implemented as an HDD (Hard Disk Drive), SSD (Solid State Drive), etc. In the software configuration of Figure 1, the request DB 104 and the conflict DB 107 are built on the storage device 212. In the software configuration of Figure 1, the request reception unit 101, request extraction unit 102, conflict hypergraph creation unit 105, request feasibility determination unit 106, compromise proposal formulation unit 108, hypergraph display unit 109, and piping plan creation unit 110 are stored as software modules on the storage device 212 and executed by the central processing unit 211. The communication device 213 is implemented as a NIC (Network Interface Card), etc.

[0022] The mediation user device 220 includes an input device 221, an output device 222, and a communication device 223. The input device 221 is implemented as a mouse or keyboard, the output device 222 is implemented as a display, and the communication device 223 is implemented as a NIC (Network Interface Card).

[0023] Similarly, the requested user device 230 has a configuration that includes an input device 231, an output device 232, and a communication device 233. The input device 231 is implemented as a mouse or keyboard, the output device 232 is implemented as a display, and the communication device 233 is implemented as a NIC (Network Interface Card), etc.

[0024] The mediation user device 220, the requesting user device 230, the server 210, and the externally generated AI service 240 are connected via the internet 250.

[0025] For simplicity, Figure 2 shows only one requesting user device 230, but there may be multiple requesting user devices depending on the number of requesting users.

[0026] Figure 3 is a flowchart showing the processing of the request reception unit 101. The requesting user 121 checks the current piping plan using the output device 232 of the requesting user device 230 and inputs a request statement 111, which is a natural language sentence representing the request, using the input device 231, as well as a numerical value indicating the importance of the request. This input triggers the request reception unit to start processing based on the flowchart in Figure 3.

[0027] The processing of the request receiving unit 101 based on the flowchart in Figure 3 is as follows:

[0028] Step 301: Receive the request statement and its severity level entered by the requesting user.

[0029] Step 302: The request statement is input to the request extraction unit 102, and processing is executed based on the flowchart in Figure 4. The output is a request JSON 113, which is a request formatted in JSON format.

[0030] Step 303: Store the request JSON113, the user identifier of the user who entered the request, and the request's importance level in the request DB104.

[0031] Figure 4 is a flowchart showing the processing of the request extraction unit 102. The processing of the request extraction unit 102 based on the flowchart in Figure 4 is as follows:

[0032] Step 401: Create a prompt 112, which is a message that receives a request statement 111 as input, classifies the contents of the request statement into predetermined categories, extracts the parameters set for each category from the request statement, and outputs them in JSON format.

[0033] Here, the specified categories in the creation of piping plan diagrams include, for example, "specifying the length," "specifying the number of bends," "specifying points to avoid," and "specifying the direction of incidence." The parameters for each category are, for example, "maximum length" and "target route" for "specifying the length," "maximum number of bends" and "target route" for "specifying the number of bends," "coordinates" and "target route" for "specifying points to avoid," and "direction" and "target route" for "specifying the direction of incidence." With this setting, for example, if request statement 111 is given as "The length of route 1 should be 50 meters or less," it is desirable that the category be "specifying the length" and the parameters be "target route: 1, maximum length: 50." If request statement 111 is given as "The number of bends on route 2 should be 5 or less," it is desirable that the category be "specifying the number of bends" and the parameters be "target route: 2, maximum number of bends: 5." If request 111 is given as "Route 3 should not pass through point (20, 10)," the category should preferably be "Specify point to avoid" and the parameters should be "Target route: 3, Coordinates: (20, 10)." If request 111 is given as "Route 1 should enter the endpoint from the east," the category should preferably be "Specify point to avoid" and the parameters should be "Target route: 1, Coordinates: (20, 10)." Furthermore, if a single request 111 contains multiple requests, the category classification and parameter extraction are performed for each request, and the multiple results are output in JSON format as an array. An example of request 111 and its corresponding request JSON 113 is shown in Figure 14.

[0034] Step 402: Prompt 112 is sent to the external generation AI service 240 and input to the generation AI 103 on the external generation AI service 240. The generation AI 103 takes the prompt as input and outputs a request JSON 113, which is a JSON string that has been formatted according to the instructions, and sends it to the server 210.

[0035] Step 403: Check the output format of the request JSON113, which is the output of generated AI103. Specifically, check whether the format of the request JSON113 conforms to the rules of JSON format, whether it is classified into a category other than the specified category, and whether the combination of category and parameter is correct.

[0036] Step 404: If the check in Step 403 results in the format being correct, proceed to Step 407. Otherwise, proceed to Step 405.

[0037] Step 405: Modify the requested JSON113 to conform to the specified format. Specifically, convert any numbers set as strings back to numbers. Perform rule-based processing such as converting English to Japanese.

[0038] Step 406: If the correction is successful through the rule-based processing in Step 405, proceed to Step 407. If it fails, return to Step 402 and reshape the request statement 111 by the generating AI 103.

[0039] Step 407: Output the request JSON113.

[0040] Figure 5 is a flowchart showing the processing of the conflict hypergraph creation unit 105. The conflict hypergraph creation unit 105 generates multiple conflicts, which are sets of requirements that cannot be simultaneously realized unless at least one is compromised, and creates a conflict hypergraph 115, which is a collection of these conflicts.

[0041] The process of the conflict hypergraph creation unit 105 based on the flowchart in Figure 5 is as follows:

[0042] Step 501: Retrieve multiple requests from Request DB104 as Request JSON113. At this time, you may retrieve all requests stored in Request DB104 or only the requests selected by the user.

[0043] Step 502: Initialize the variable k, which represents the number of requests included in the request combination pattern, with k=1.

[0044] Step 503: Generate all possible combinations of selecting k requests from the multiple requests obtained in Step 501.

[0045] Step 504: Select one of the combination patterns of requirements generated in Step 503 whose feasibility has not been determined, and generate a set of requirements based on that combination.

[0046] Step 505: If the set of requests generated in Step 504 contains at least one conflict that has already been obtained as a subset, return to Step 504. This is because the request is clearly a conflict. This mechanism reduces the computational cost required to generate all conflicts. If the set of requests generated in Step 504 does not contain any conflicts that have already been obtained as a subset, proceed to Step 506.

[0047] Step 506: The set of requests generated in Step 504 is input to the request feasibility determination unit 106 as multiple request JSON 113s, and processing is executed based on the flowchart in Figure 6. The output is a determination of whether or not the requests included in the set of requests can be fulfilled simultaneously.

[0048] Step 507: If the result of the determination in step 506 is True, i.e., feasible, proceed to step 509. If the result of the determination in step 506 is False, i.e., unfeasible, proceed to step 508.

[0049] Step 508: Store the set of requests generated in Step 504 as a conflict in Conflict DB 107.

[0050] Step 509: If all the combination patterns generated in Step 503 have been selected in Step 504, proceed to Step 510. If there are any combination patterns that have not been selected in Step 504, return to Step 504.

[0051] Step 510: If k is equal to the number of requests obtained in step 501, terminate the process. Otherwise, proceed to step 511.

[0052] Step 511: Add 1 to k and return to step 503.

[0053] The above steps generate multiple conflicts and store the information needed to create the conflict hypergraph 115 on the conflict DB 107.

[0054] Figure 6 is a flowchart showing the processing of the request feasibility determination unit 106. The request feasibility determination unit 106 receives multiple request JSON 113 corresponding to a set of requests as input and outputs the result of determining whether the requests contained therein can be fulfilled simultaneously.

[0055] The processing of the requirement feasibility determination unit 106 based on the flowchart in Figure 6 is as follows:

[0056] Step 601: The system receives multiple request JSON113s corresponding to a set of requests as input, inputs them into the piping plan creation unit 110, executes processing based on the flowchart shown in Figure 7, and obtains multiple piping plans 118 as output.

[0057] Step 602: If there is a piping plan among the multiple piping plans 118 obtained in Step 601 that satisfies all the requirements included in the set of requirements entered, proceed to Step 603. If not, proceed to Step 604.

[0058] Step 603: Output True.

[0059] Step 604: Output False.

[0060] Here, the request extraction unit 102 performs category classification and parameter extraction on the request statement 111 entered by the user, and creates a request JSON 113. As a result, the request can be used as a constraint on the search space in the piping plan creation unit processing in step 601, and it becomes easy to determine in step 602 whether the piping plan satisfies each request.

[0061] In this example, we determine whether a piping plan exists that satisfies all the requirements by actually creating a piping plan. However, it would also be possible to determine whether the requirements can be simultaneously fulfilled using rule-based methods or machine learning based on the request JSON113 without creating a piping plan.

[0062] Figure 7 is a flowchart showing the processing of the piping plan creation unit 110. The process of the piping plan creation unit based on the flowchart in Figure 7 is as follows:

[0063] Step 701: Receive multiple request JSON113 as input and generate multiple piping plans based on them. Here, multiple piping plans are generated using a known pathfinding method. As the known pathfinding method, methods such as Dijkstra's algorithm, A* algorithm, reinforcement learning, and Multi-Agent Path Finding may be used. In pathfinding, constraints may be imposed on the search space based on the multiple request JSON113, or the objective function may be changed.

[0064] Step 702: Output only the piping plans from among the multiple piping plans generated in Step 701 that satisfy all of the multiple JSON113 requirements.

[0065] Figure 8 is a flowchart showing the processing of the compromise proposal formulation department 108. The processing by the compromise proposal formulation department 108 based on the flowchart in Figure 8 is as follows:

[0066] Step 801: Retrieve the conflict hypergraph 115 from the conflict DB 107. The format of the conflict hypergraph is shown in Figure 15. Figure 15 is an example of a conflict hypergraph consisting of conflicts between the request with request id 1 and the request with request id 2, the request with request id 1 and the request with request id 3, the request with request id 2, the request with request id 4, and the request with request id 5.

[0067] Step 802: Generate multiple compromise solutions, which are sets of requirements that have commonalities with all conflicts in the conflict hypergraph 115 obtained in Step 801. These are sets of requirements that, if all included requirements are compromised, will resolve all conflicts. At this time, compromise solutions with fewer included requirements may be preferentially generated by solving the minimum vertex cover problem on the conflict hypergraph. The solution to the minimum vertex cover problem can be, for example, known greedy algorithms or metaheuristic algorithms, but is not limited to these methods.

[0068] Step 803: For each compromise generated in Step 802, calculate a score based on statistics related to the included requirements, their creators, or both. The method for calculating the score will be described later.

[0069] Step 804: Sort the compromise proposals based on the scores calculated in Step 803. If a lower score was used in Step 803, sort the proposals in ascending order of score. If a higher score was used in Step 803, sort the proposals in descending order of score.

[0070] Step 805: From the top of the compromise proposals sorted in Step 804, a predetermined number of compromise proposals are identified and output. Note that the predetermined number may be 1 (singular) or 2 or more (multiple). The output format of the compromise proposals is shown in Figure 16. Figure 16 is an example of outputting three compromise proposals: a compromise proposal that reconciles the request with request id 1 and the request with request id 5, a compromise proposal that reconciles the request with request id 1 and the request with request id 4, and a compromise proposal that reconciles the request with request id 2 and the request with request id 3.

[0071] As an example of the score calculated in step 803, the number of requirements included in the compromise proposal is calculated using the process shown in the flowchart in Figure 9. By presenting a compromise proposal with the lowest possible score, it is possible to satisfy more requirements.

[0072] Another example of the score calculated in step 803 is the sum of the importance of the requirements included in the compromise proposal, as shown in the flowchart in Figure 10. The process in this case is as follows:

[0073] Step 1001: Obtain the importance of the requirements included in the compromise proposal from the requirements DB104.

[0074] Step 1002: Calculate the sum of the importance of the requirements included in the compromise proposal and output it as a score.

[0075] By proposing a compromise solution with the lowest possible score, it is possible to satisfy the most important requirements.

[0076] Another example of the score calculated in step 803 is the calculation of the distribution among users of the number of requests included in the compromise proposal from the requests created by each user, using the process shown in the flowchart in Figure 11. The process in this case is as follows:

[0077] Step 1101: Retrieve the user identifier of the creator of the request included in the compromise from Request DB104.

[0078] Step 1102: Using the user identifier obtained in Step 1101, calculate the number of requests Ci that are included in the compromise proposal from the requests created by each user i.

[0079] Step 1103: Calculate the variance among Ci users and output it as a score. By proposing a compromise solution with the lowest possible score, fairness among users can be considered.

[0080] Another example of a score to be calculated in step 803 is to calculate a weighted average of the number of requirements included in the compromise, the sum of the importance of the requirements included in the compromise, and the user-to-user variance of the number of requirements included in the compromise.

[0081] Another example involves calculating multiple scores with different priorities in step 803, then in step 804, sorting the compromises using the highest priority score, and for compromises with the same score, sorting them again using the score with the next lower priority. This process is repeated to sort the compromises based on multiple scores.

[0082] Figure 12 is a flowchart showing the processing of the hypergraph display unit 109. The processing of the hypergraph display unit 109 based on Figure 12 is as follows:

[0083] Step 1201: Retrieve the conflict hypergraph from conflict DB107.

[0084] Step 1202: Draw a hypergraph with each request as a node and each conflict as a hyperedge.

[0085] Step 1203: The hypergraph drawn in Step 1202 is sent to the mediation user device 220 and displayed on the output device 222.

[0086] By visualizing and presenting conflict relationships as a hypergraph in this way, it becomes easier to understand complex conflict relationships and to clarify the basis for proposed compromises.

[0087] Figure 13 is a flowchart showing the overall flow of the plan creation process. This flowchart is initiated when the mediation user clicks the plan creation button 2203 in Figure 22. The planning process based on Figure 13 is as follows:

[0088] Step 1301: The system receives multiple request JSON 113s corresponding to a set of requests as input, inputs them into the piping plan creation unit 110, executes processing based on the flowchart shown in Figure 7, and obtains multiple piping plans 118 as output.

[0089] Step 1302: If there is a piping plan 118 obtained in Step 1301 that satisfies all requirements, proceed to Step 1303. Otherwise, proceed to Step 1304.

[0090] Step 1303: Among the piping plans that satisfy all requirements, the piping plan with the fewest sum of bends in the route or the piping plan with the smallest sum of route lengths is displayed on the output device 222 of the arbitration user device 220 on a screen as shown in Figure 23.

[0091] Step 1304: Execute the process of the conflict hypergraph creation unit 105 as shown in the flowchart in Figure 5.

[0092] Step 1305: The process of the compromise proposal formulation unit 108 shown in the flowchart of Figure 8 is executed, and multiple compromise proposals are obtained as output.

[0093] Step 1306: The compromise obtained in Step 1305 is displayed on the output device 222 of the mediation user device 220 on a screen as shown in Figure 24.

[0094] Figure 17 shows an example of a table in the request DB 104. The request DB 104 table in Figure 17 includes a request ID column 1701 that stores a unique ID for each request, a creator column 1702 that stores the identifier of the user who created the request, a request JSON column 1703 that stores the request JSON 113, and a severity column 1704 that stores the severity of the request.

[0095] Figure 18 shows an example of a table in Conflict DB 107. The Conflict DB 107 table in Figure 17 has an id column 1801 that stores a unique id for each record, and a conflict id column 1802 and a request id column 1803 that store conflicts and the requests contained within those conflicts in association.

[0096] Figures 19, 20, and 21 show examples of screens displayed to the requesting user. These screens are displayed by the output device 232. The requesting user operates the screens using the input device 231.

[0097] On the left side of the screen in Figure 19, the current piping plan 1901 is displayed. On the right side of the screen in Figure 19, the request display area 1902 displays requests created by the user. Only requests entered by the requesting user themselves are displayed here; requests entered by other requesting users are not displayed. When the Add Request button 1903 is clicked, the screen displayed to the requesting user transitions to the screen in Figure 20.

[0098] In the lower right corner of the screen in Figure 20, a request input field 2001, an importance input field 2002, an add request button 2003, and a cancel button 2004 are displayed. The request user uses the input device 231 to enter the request statement 111 in the request input field 2001 and a numerical value representing importance in the importance input field 2002. Clicking the add request button 2003 sends the request statement 111 and importance to the server 210, and the request reception unit processing shown in the flowchart of Figure 3 begins. When the request reception unit processing is completed on the server 210, the screen transitions to the screen in Figure 21. If the cancel button 2004 is clicked, the request input is interrupted, and the screen displayed to the request user returns to the screen in Figure 19.

[0099] On the right side of the screen in Figure 21, request 2101, which was entered on the screen in Figure 20, is added.

[0100] When the "Request Input Complete" button 2102 on the screen shown in Figure 21 is clicked, the mediation user is notified that the request input has been completed. The requesting user who clicked this button will no longer be able to input any requests until a new piping plan is presented.

[0101] Figures 22, 23, 24, and 25 show examples of screens displayed to the mediation user. These screens are displayed by output device 222. The mediation user operates the screens using input device 221.

[0102] On the left side of the screen in Figure 22, the current piping plan 2201 is displayed. On the right side of the screen in Figure 22, the request display area 2202 displays all requests created by the requesting users. Unlike the requesting user's screen, the mediating user's screen displays requests from all requesting users. When the plan creation button 2203 is clicked, the plan creation process shown in the flowchart in Figure 13 begins. If a piping plan that satisfies all requests is created, the screen displayed to the mediating user transitions to the screen in Figure 23. If a piping plan that satisfies all requests cannot be created, the screen displayed to the mediating user transitions to the screen in Figure 24.

[0103] On the left side of the screen in Figure 23, a new piping plan 2301 that satisfies all requirements is displayed. When the plan approval button 2302 is clicked, the current piping plans 2201 and 1901 are updated to piping plan 2201. When the plan rejection button 2303 is clicked, the screen displayed to the mediation user returns to the screen in Figure 22.

[0104] On the left side of the screen in Figure 24, the compromise proposal section 2401 is displayed. The compromise proposal section 2401 displays multiple compromise proposals 116, which are the output of the compromise proposal formulation unit 108. The user selects a compromise proposal from the displayed proposals by clicking the compromise proposal selection button 2402. When the conflict graph display button 2403 is clicked, the processing of the hypergraph display unit 109 shown in the flowchart of Figure 11 is started, and the screen transitions to the screen in Figure 25. If the back button 2404 is clicked, the screen returns to the screen in Figure 22.

[0105] The screen in Figure 25 displays the hypergraph Figure 117. If the button 2502, which returns to selecting a compromise, is clicked, the screen returns to the screen in Figure 24. If the back button 2503 is clicked, the screen returns to the screen in Figure 22.

[0106] It should be noted that the present invention is not limited to the embodiments described above, and various modifications are included. For example, the embodiments described above are described in detail to make the present invention easier to understand, and are not necessarily limited to those having all the configurations described. Furthermore, it is possible to replace a part of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. Furthermore, it is possible to add, delete, or replace parts of the configuration of each embodiment with other configurations. In addition, some or all of the above configurations, functions, processing units, processing means, etc., may be realized in hardware, for example, by designing them as integrated circuits. Furthermore, each of the above configurations, functions, etc., may be realized in software by having a processor interpret and execute a program that realizes each function. Information such as programs, tables, files, etc. that realize each function can be stored in memory, a recording device such as a hard disk or SSD (Solid State Drive), or a recording medium such as an IC card, SD card, or DVD.

[0107] <<Example 2>> This embodiment utilizes an internally implemented AI generation server 2740 instead of using the external AI generation service 240 as in Embodiment 1.

[0108] The following describes only the changes from Example 1.

[0109] Figure 26 is a software configuration diagram for this embodiment. Unlike the software configuration diagram in Figure 1 of Embodiment 1, the software configuration in Figure 26 includes the generation AI 103 within the system.

[0110] Figure 27 is a hardware configuration diagram that realizes the software configuration of Figure 26. In the hardware configuration of Figure 2 of Example 1, an external generation AI service 240 is used, whereas in the hardware configuration of Figure 27, a generation AI server 2740 is used. Generation AI 103 is executed on the generation AI server 2740.

[0111] The steps that will be changed are as follows:

[0112] Step 402: Prompt 112 is sent to the generating AI server 2740 and input to the generating AI 103 on the generating AI server 2740. The generating AI 103 takes the prompt as input and outputs a request JSON 113, which is a JSON string that has been formatted according to the instructions, and sends it to the server 210.

[0113] In this way, by executing the generation AI internally within the system, the number of communications with external parties can be reduced, and the impact of malfunctions on external generation AI services can be avoided.

[0114] In Figure 27, the arbitration user device 220, the requesting user device 230, the server 210, and the generating AI server 2740 are connected via the Internet 250, but the generating AI server 2740 may be implemented as software on the server 210.

[0115] <<Example 3>> In this embodiment, the user selects multiple or one requirement to compromise on the hypergraph in the screen shown in Figure 25 of Embodiment 1, and the display method of the hypergraph is changed based on the selected requirements.

[0116] The following describes only the changes from Example 1.

[0117] In this embodiment, the screen shown in Figure 28 is displayed instead of the screen shown in Figure 25 of Embodiment 1.

[0118] In the hypergraph diagram 2801 of the screen in Figure 28, the user can select requirements to compromise on by clicking on nodes in the hypergraph diagram. Nodes representing selected requirements and nodes representing unselected requirements are drawn in different colors. In addition, hyperedges representing conflicts that include selected requirements and hyperedges that do not include selected requirements are drawn in different colors. In this example, requirements 3 and 5 are selected. In this example, hyperedges representing conflicts that include the selected requirement (requirement 3) are drawn in white, hyperedges representing conflicts that include the selected requirement (requirement 5) are drawn in white, and hyperedges that do not include the selected requirements are drawn in black.

[0119] The Add Compromise button 2802 is enabled if the selected set of requirements has commonalities with all conflicts. When the Add Compromise button 2802 is clicked, the compromise based on the selected requirements is added to the Compromise Presentation field 2401 in Figure 24, and the screen transitions to Figure 24.

[0120] By changing the display based on the user's selection of requests in this way, it becomes possible to formulate interactive compromise solutions.

[0121] The present invention can also adopt the following configuration.

[0122] [1] An information processing device having a processor, The aforementioned processor, For multiple requests, the system accepts the requests and their creators, determines whether the multiple requests can be fulfilled simultaneously, generates one or more conflicts based on the determination result, which are sets of requests that cannot be fulfilled simultaneously unless at least one of the subsets of the requests is compromised, creates a conflict hypergraph which is a set of the conflicts, creates one or more sets of requests as compromise solutions based on the conflict hypergraph which have common parts with all the conflicts included in the conflict hypergraph, calculates a score for the compromise solutions based on statistics relating to either the requests and their creators, or both, identifies one or more compromise solutions from the one or more compromise solutions based on the score, and outputs the identified one or more compromise solutions. Information processing device.

[0123] [2] A request arbitration method using an information processing device having a processor, The aforementioned processor, For multiple requests, the system accepts the requests and their creators, determines whether the multiple requests can be fulfilled simultaneously, generates one or more conflicts based on the determination result, which are sets of requests that cannot be fulfilled simultaneously unless at least one of the subsets of the requests is compromised, creates a conflict hypergraph which is a set of the conflicts, creates one or more sets of requests as compromise solutions based on the conflict hypergraph which have common parts with all the conflicts included in the conflict hypergraph, calculates a score for the compromise solutions based on statistics relating to either the requests and their creators, or both, identifies one or more compromise solutions from the one or more compromise solutions based on the score, and outputs the identified one or more compromise solutions. Request mediation method. [Explanation of symbols]

[0124] 101...Request reception unit, 102...Request extraction unit, 103...Generation AI, 105...Conflict hypergraph creation unit, 106...Request feasibility determination unit, 108...Compromise proposal formulation unit, 109...Hypergraph display unit.

Claims

1. A demand mediation system that recommends a demand to be compromised from among multiple demands, A request receiving unit that receives the aforementioned request and associates it with the creator of the aforementioned request, A request feasibility determination unit that determines whether multiple of the aforementioned requests can be fulfilled simultaneously, A conflict hypergraph creation unit generates one or more conflicts, which are sets of requirements that cannot be simultaneously realized unless at least one of the requirements from a subset of the requirements is compromised, based on the determination result of the requirement feasibility determination unit, and creates a conflict hypergraph, which is a set of the conflicts. A compromise proposal formulation unit creates one or more compromise proposals for the requirements based on the conflict hypergraph created by the conflict hypergraph creation unit, identifies one or more compromise proposals from among the one or more compromise proposals, and outputs the identified one or more compromise proposals. It has, The compromise proposal formulation unit has the function of generating a set of requirements that have common parts with all the conflicts included in the conflict hypergraph as the compromise proposal, and the function of calculating a score for the compromise proposal based on statistics relating to either the requirements or the creators of the requirements, or both the requirements and the creators of the requirements, and identifies one or more compromise proposals from among the one or more compromise proposals based on the score. A system for mediating demands.

2. A request mediation system according to claim 1, It has a display unit that presents one or more of the aforementioned compromise proposals identified by the aforementioned compromise proposal formulation unit, A system for mediating demands.

3. A request mediation system according to claim 1, The compromise proposal formulation unit calculates the number of requirements included in the compromise proposal as the score. A system for mediating demands.

4. A request mediation system according to claim 1, The request receiving unit receives the request, the creator of the request, and the importance of the request, and The compromise proposal formulation unit calculates the sum of the importance of the requirements included in the compromise proposal as the score. A system for mediating demands.

5. A request mediation system according to claim 1, The compromise proposal formulation unit calculates a value relating to fairness among the creators of the request as the score. A system for mediating demands.

6. A request mediation system according to claim 1, The request receiving unit receives the request, the creator of the request, and the importance of the request, and The compromise proposal formulation unit calculates a score based on the number of requirements included in the compromise proposal, the sum of the importance levels of the requirements included in the compromise proposal, and the distribution of the number of requirements included in the compromise proposal among the creators of the requirements. A system for mediating demands.

7. A request mediation system according to claim 1, The compromise proposal formulation unit calculates multiple types of scores having different priorities for the compromise proposals, sorts the compromise proposals using the score with the higher priority, and then sorts the compromise proposals with the same score using the score with the next lower priority, repeating this process, and based on the sorting results, identifies one or more compromise proposals from among one or more compromise proposals. A system for mediating demands.

8. A request mediation system according to claim 1, The system includes a hypergraph display unit that displays the conflict hypergraph created by the conflict hypergraph creation unit. A system for mediating demands.

9. A request mediation system according to claim 8, The hypergraph display unit modifies the display based on one or more of the aforementioned requests and the conflicts that include those aforementioned requests. A system for mediating demands.

10. A request mediation system according to claim 1, The system includes a request extraction unit that inputs the request described in natural language into a generating AI and converts it into a category of the request or a combination of the category of the request and one or more parameters representing the request. A system for mediating demands.

11. A request mediation system according to claim 1, The system includes a request extraction unit that sends the request, described in natural language, to an external AI generation service and converts it into a category of the request or into a category of the request and one or more parameters representing the request. A system for mediating demands.

12. An information processing device having a processor, The aforementioned processor, For multiple requests, the system accepts the requests and their creators, determines whether the multiple requests can be fulfilled simultaneously, generates one or more conflicts based on the determination result, which are sets of requests that cannot be fulfilled simultaneously unless at least one of the subsets of the requests is compromised, creates a conflict hypergraph which is a set of the conflicts, creates one or more sets of requests as compromise solutions based on the conflict hypergraph which have common parts with all the conflicts included in the conflict hypergraph, calculates a score for the compromise solutions based on statistics relating to either the requests and their creators, or both, identifies one or more compromise solutions from the one or more compromise solutions based on the score, and outputs the identified one or more compromise solutions. Information processing device.

13. A request arbitration method using an information processing device having a processor, The aforementioned processor, For multiple requests, the system accepts the requests and their creators, determines whether the multiple requests can be fulfilled simultaneously, generates one or more conflicts based on the determination result, which are sets of requests that cannot be fulfilled simultaneously unless at least one of the subsets of the requests is compromised, creates a conflict hypergraph which is a set of the conflicts, creates one or more sets of requests as compromise solutions based on the conflict hypergraph which have common parts with all the conflicts included in the conflict hypergraph, calculates a score for the compromise solutions based on statistics relating to either the requests and their creators, or both, identifies one or more compromise solutions from the one or more compromise solutions based on the score, and outputs the identified one or more compromise solutions. Request mediation method.

Images