Information processing device, method, program

Abstract

In the complex dispatch planning process involving various requirements, this invention provides a dispatch planning method, program, and information processing device that automatically outputs efficient dispatch plans tailored to actual operations, significantly reducing the workload of dispatchers. [Solution] The method acquires case information for multiple moving cases involving long-distance transport, including requirements for designated flights with fixed delivery dates or consolidated flights with flexible delivery periods. It identifies the multiple moving cases into confirmed cases where vehicle assignments have already been finalized and unconfirmed cases. Confirmed flights assigned to confirmed cases are protected as exempt from changes to the vehicle assignment plan. Under conditions that satisfy the remaining capacity of the confirmed flights and the requirements for designated and consolidated flights, the method calculates a new flight assignment plan that optimizes the unconfirmed cases to minimize the number of flights and maximize the loading rate. The plan is then finalized and output as data for screen display.

Description

Technical Field

[0001] The present disclosure relates to an information processing apparatus, a method, and a program.

Background Art

[0002] Various technologies related to vehicle dispatch systems are known. Patent Document 1 discloses a technology that is a vehicle dispatch system, which uses telephone numbers to identify each customer and stores addresses frequently used by each customer, thereby enabling the server of a dispatch center to operate efficiently.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problem to be Solved by the Invention

[0004] In dispatch planning involving long-distance trunk transportation, particularly in moving services and the like, unlike simple long-distance transportation of luggage, the unloading work at the origin of the move and the loading work at the destination of the move (arrangement of personnel) are linked. Furthermore, there exist unique and complex requirements, such as the mixture of cases with a specified delivery date and cases that may be delivered at any time within a delivery period of several days. It is extremely difficult to solve the dispatch planning so as to fill the empty capacity of trucks without waste and minimize the total number of service trips while satisfying such complex constraints. For this reason, the work of formulating dispatch plans relies heavily on the personal craftsmanship of skilled dispatch personnel, and there has been a problem that a great deal of labor and time is required on site.

[0005] This invention has been made in view of the above problems, and aims to provide a dispatch planning method, program, and information processing device that can automatically output an efficient dispatch plan that is in line with actual operations in dispatch planning work, in which complex requirements are intertwined, and can significantly reduce the workload of dispatchers. [Means for solving the problem]

[0006] According to one embodiment of the present disclosure, a method for scheduling transportation is provided which is performed by a computer having a processor. The method includes the steps of: the computer's processor obtaining case information for a plurality of moving cases involving long-distance transport, including requirements for designated flights with fixed delivery dates or consolidated flights with flexible delivery periods; identifying the plurality of moving cases into confirmed cases, for which transportation has already been determined, and unconfirmed cases, for which transportation has not yet been determined; protecting confirmed flights to which confirmed cases have been assigned as exempt from changes to the transportation schedule; and outputting a new flight allocation plan that minimizes the number of flights and maximizes the loading rate, with the unconfirmed cases being optimized, under the conditions that the remaining capacity of the confirmed flights and the requirements for designated flights and consolidated flights are met. [Effects of the Invention]

[0007] According to the present invention, for multiple moving projects involving long-distance transport, the requirements for designated or consolidated shipments are obtained, and the projects are identified as confirmed projects with confirmed vehicle assignments and unconfirmed projects. Then, after protecting the confirmed routes assigned to confirmed projects as exempt from changes to the vehicle assignment plan, a new route assignment plan is output that optimizes the unconfirmed projects to minimize the number of routes and maximize the loading rate, while satisfying the remaining capacity and the requirements of each route.

[0008] This allows for the protection of already established routes, such as those designated by on-site dispatchers, while simultaneously re-optimizing unconfirmed cases. As a result, the creation of complex long-distance dispatch plans can be automated, significantly reducing the workload on personnel and eliminating reliance on individual expertise. Furthermore, by using a mathematical approach to maximize load factors and minimize the number of trips, it becomes possible to reduce unnecessary truck operations and optimize transportation costs. [Brief explanation of the drawing]

[0009] [Figure 1] Figure 1 is a schematic diagram illustrating the overall concept of automatic dispatch planning in the dispatch planning optimization system according to this embodiment. [Figure 2] Figure 2 is a conceptual diagram showing the calculation process of the allocation plan by the multi-layer optimization engine 140. [Figure 3] Figure 3 is a conceptual diagram illustrating the process of refining the dispatch plan through algorithmic Repair (automatic repair process). [Figure 4] Figure 4 is a conceptual diagram of a platform that enables the standardization of available slots into transaction units and their inter-company sharing. [Figure 5] Figure 5 is a block diagram showing the overall configuration of the vehicle dispatch planning optimization system 1 according to this embodiment. [Figure 6] Figure 6 is a block diagram showing the internal functional configuration of the dispatch planning server 100 according to this embodiment. [Figure 7] Figure 7 shows an example of the data structure of a case information table 700, which is stored in the case information database 121 of the storage unit 120 and used as input data for identification processing and multi-layer optimization calculations by the control unit 130 (processor). [Figure 8] Figure 8 shows an example of the data structure of the flight information table 800, which is stored in the flight plan database 122 of the memory unit 120 and used by the control unit 130 (processor) for generating dispatch plans, protecting confirmed flights, and extracting available slots. [Figure 9]Figure 9 shows an example of an intermediate data structure 900 (candidate pattern matrix) generated by the candidate pattern generation unit 141 and the same-day round-trip matching unit 142 of the multilayer optimization engine 140, and temporarily held in the intermediate data holding area 123 of the storage unit 120. [Figure 10] Figure 10 shows an example of the data structure of the worker resource table 1000, which is acquired from an external personnel and shift management system 310 via the communication unit 110 and stored temporarily or permanently in the storage unit 120. [Figure 11] Figure 11 shows an example of the data structure of the available slot transaction table 1100, which is built within the database of the storage unit 120 and used by the transaction management unit 132 to manage the distribution, matching, and settlement of available slots (transaction tickets 420) on the common platform 430. [Figure 12] Figure 12 is a flowchart showing the overall procedure of the dispatch planning process executed by the control unit 130 (processor) of the dispatch planning server 100 according to this embodiment, in accordance with the dispatch planning optimization program. [Figure 13] Figure 13 is a flowchart showing more detailed calculation steps of the data processing pipeline executed by the multilayer optimization engine 140 (candidate pattern generation unit 141, same-day round-trip matching unit 142, and ILP solver execution unit 143). [Figure 14] Figure 14 is a flowchart showing the detailed calculation procedure of the automatic repair process that the automatic repair processing unit 144 of the multilayer optimization engine 140 autonomously performs within the system to seek further efficiency improvements (reduction in the number of flights) to the initial solution 300 output by the integer linear programming (ILP) solver (ILP solver execution unit 143). [Figure 15] Figure 15 is a flowchart showing the detailed processing steps of the manual Repair loop (human-AI interaction) performed between the dispatch planning server 100 and the base terminal 200. [Figure 16]FIG. 16 is a flowchart illustrating specific procedures of converting vacant slots into transaction units and publishing them to a platform, which are executed by the transaction management unit 132 of the vehicle allocation planning server 100 after a series of optimization and automatic repair processes by the multi-layer optimization engine 140 are completed. [Figure 17] FIG. 17 illustrates an example of the configuration of a vehicle allocation plan / condition setting screen 1700 generated by the vehicle allocation planning server 100 according to the present embodiment and displayed on the display of the base terminal 200 via the communication network 50. [Figure 18] FIG. 18 illustrates an example of the configuration of a vehicle allocation planning result / manual Repair operation screen 1800 generated by the vehicle allocation planning server 100 according to the present embodiment and displayed on the display of the base terminal 200 via the communication network 50. [Figure 19] FIG. 19 illustrates an example of the configuration of a vacant slot transaction platform screen 1900 generated by the transaction management unit 132 of the vehicle allocation planning server 100 and displayed on the display of the other operator terminal 320 (or the in-house base terminal 200) via the communication network 50. [Mode for Carrying Out the Invention]

[0010] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. In the following description, the same components are denoted by the same reference numerals. Their names and functions are also identical. Therefore, detailed descriptions thereof will not be repeated.

[0011] <Overview of Embodiment> Prior to the description of the specific system configuration and processing flow for each drawing, the overall outline of the vehicle allocation plan optimization system according to the present embodiment, the problems to be solved, and the technical configuration for solving the same will be described.

[0012] <1. Background and Problems to be Solved> In dispatching for moving services involving long-distance trunk line transportation, unlike general logistics (such as home delivery), it is necessary to simultaneously satisfy extremely complex and multi-dimensional constraints, such as the coexistence of "scheduled deliveries" with strict delivery dates and "consolidated deliveries" with more flexible timeframes, the three-dimensional spatial packing of household goods, the prohibition of consolidating certain types of goods, and the "availability of workers (personnel) shifts" at each base.

[0013] Traditionally, attempting to automate the process by inputting all these constraints into a single mathematical optimization solver (such as integer linear programming) presented a technical challenge: the number of combinations would balloon astronomically, leading to a "computational explosion" where a solution could not be obtained within a practical timeframe. In addition, the "black-boxed perfect solution" unilaterally output by the system often overwhelmed and destroyed customer service and considerations (such as assigning specific drivers) that experienced dispatchers had built up over many years, resulting in extremely low practical acceptance. Furthermore, the "several m³ of spatial void" and "several days of schedule flexibility" that inevitably remain in the truck bed even after optimization have been overlooked as mere loading losses.

[0014] <2. Technical configuration for solving the problem (outline of this embodiment)> To solve the above-mentioned problems, the system according to this embodiment employs a "collaborative architecture between humans and AI" that integrates the following four main technical approaches.

[0015] Firstly, the system focuses on "protecting confirmed shipments and optimizing gaps." The system strictly protects shipments already confirmed by dispatchers or manually locked as "immutable constants" in the mathematical model, and only packs unconfirmed shipments based on the remaining truck "capacity (spatial gaps)" and "overlap of time windows (temporal gaps)." This dramatically reduces the computational search space while respecting human intent.

[0016] Secondly, there is the "construction of a multi-layer optimization engine." To prevent computational explosion, instead of immediately seeking an exact solution, the system first uses heuristics (empirical algorithms such as bin packing and round-trip matching) to pre-generate feasible "one-way, same-day round-trip candidate patterns" and prune them. Then, integer linear programming (ILP) is applied to the narrowed-down matrix to solve a two-stage objective function (lexicographical optimization) of "minimizing the number of flights" and "maximizing priority," employing a multi-layer pipeline structure.

[0017] Thirdly, there is the "autonomous and collaborative Repair loop." The ILP performs "automatic Repair (combining flights and adding round trips)" to the initial solution output by the system, greedily searching for further efficiency improvements. At the same time, the front-end GUI provides a "manual Repair" interaction, triggered when an employee manually pins (locks) a specific flight, which recalculates and displays the differences for only the remaining cases in milliseconds.

[0018] Fourthly, there is "tight coupling with external resources (worker shifts, other vendor platforms)." As an optimization constraint, available shift slots for workers are dynamically obtained from external systems, and the delivery date is calculated based on the day when arrangements for both trucks and personnel are finalized. Furthermore, any remaining spatial and temporal leeway in the cargo area is converted into digital assets such as "transaction tickets," and a transaction management function is provided to buy, sell, and exchange them with other businesses on a common platform (automatic merging of dispatch data and settlement).

[0019] <3. Main effects obtained by the present invention> By adopting this configuration, the system avoids computational overload in long-distance moving dispatching, where complex constraints are intertwined, and can output dispatch plans that achieve a high level of balance between "minimizing the total number of trips" and "maximizing the loading rate" with a practical response speed of, for example, a few seconds to tens of seconds. Furthermore, it functions as a "co-pilot" that works closely with dispatchers' decision-making and instantly assists with filling in troublesome gaps, dramatically reducing the workload on the ground while achieving high acceptability. Moreover, by building an ecosystem that allows for the sharing of vacant slots that cannot be filled internally through a common industry market, it achieves extremely excellent effects such as improving the utilization rate and optimizing logistics resources beyond the framework of a single company.

[0020] Below, we will explain in detail, step by step, the specific configuration and processing procedures of the system that embodies the overall concept described above, with reference to the diagrams.

[0021] Figure 1 is a schematic diagram showing the overall concept of automated dispatch planning in the dispatch planning optimization system according to this embodiment. This system does not aim solely to completely automate (black-box) dispatch planning, but rather to organically utilize the operational know-how and flexible decision-making (human judgment) cultivated by skilled dispatchers through years of experience. It has a "human-AI collaborative architecture" that respects and protects definitive human judgments as data, while supplementing the computationally intensive combinatorial optimization domain with an optimization engine 120 incorporated into the control unit of the information processing device (computer).

[0022] As shown in Figure 1, the data set of moving cases processed by this system (moving case information 100) is a collection of multiple moving cases (order data) involving long-distance trunk line transportation. The data for each moving case includes, in addition to household goods volume data indicating information on the origin and destination and the volume of goods (and 3D dimensions and attributes of special items, etc.), attribute information that includes at least the requirements for a "designated delivery" where the delivery date is fixed to a specific single day, and the requirements for a "consolidated delivery" where a predetermined range of leeway (for example, several days to about a week) is allowed for the delivery period.

[0023] The case identification process 110 (case identification unit), operated by the processor of the information processing device, scans and identifies / classifies multiple moving case information 100 taken in from an external source or storage unit via the communication unit, in the stage before calculating the dispatch plan, into "confirmed cases 10" for which the assignment to a specific route (truck slot) has already been confirmed by a user such as a dispatch manager, and "unconfirmed cases 20" for which the dispatch (assignment destination) has not yet been decided, based on data attributes (for example, status flags provided in the case data).

[0024] Next, the system identifies (deploys into memory) the routes to which the identified confirmed cases 10 have already been assigned as "confirmed routes 30," and strictly "protects" them as areas that are not subject to change (protected area / black box area) in subsequent automatic dispatch plan recalculation processes (optimization algorithms). Specifically, it either completely excludes the data associated with the confirmed routes 30 (such as the list of assigned cases) from the set of variables in the mathematical optimization model of the multi-layer optimization engine described later, or formulates it as a "fixed constant (unchangeable constraint)" in the mathematical model, thereby executing a control that locks it from recalculation by the algorithm. This prevents existing routes prepared in advance by dispatchers based on, for example, customer agreements or specific local circumstances (e.g., route considerations for specific skilled drivers, special loading restrictions for household goods, or strict time specifications by shippers) from being unintentionally modified or overwritten by the system's recalculations.

[0025] Then, the optimization engine 120 scans the interior (cargo bed capacity) of the protected, confirmed delivery 30 and calculates the "remaining capacity (spatial gap)," which is the spatial leeway where cargo can still be loaded, by subtracting the existing allocated cargo amount from the truck's maximum loading capacity. The optimization engine 120 also compares the delivery schedule of the confirmed delivery 30 with the various schedule conditions (time window constraints) of the identified designated and consolidated deliveries, and, for example, taking into account the travel lead time required for long-distance transport, determines and works backward whether the delivery date of the confirmed delivery falls within the grace period for the consolidated delivery, thereby dynamically analyzing and calculating the "temporal gap," which is the temporal leeway. Then, only the "undetermined cases 20" for which the dispatch plan has not yet been decided are treated as the pure optimization target (the set of real variables in the mathematical model). Within the limits that satisfy the capacity constraint that the amount of household goods in the undetermined cases 20 must be less than or equal to the remaining capacity and the time window constraint that it must match the time gap, these are either additionally allocated to the remaining capacity (spatial gap) of the confirmed flights 30, or efficiently allocated (packed) to new flights that are automatically arranged (ticketed) based on the departure and arrival locations and time window constraints of the undetermined cases 20 when the capacity is exceeded.

[0026] Through this optimization process, the system (optimization engine 120) calculates and outputs a new dispatch plan 40 (optimal dispatch result data) that achieves both "minimizing the total number of dispatches (number of trucks) required for actual transportation" and "maximizing the cargo bed loading rate for each dispatch." The AI ​​(optimization engine 120) autonomously fills in the "spatial and temporal gaps" in the results (finalized dispatches) previously assembled by humans through advanced mathematical optimization, presenting the user with "an extremely efficient dispatch pattern that could not have been noticed by human cognitive abilities alone," providing high convenience in the form of labor savings and cost reductions in trunk line dispatch operations.

[0027] Figure 2 is a conceptual diagram showing the calculation process of the allocation plan by the multi-layer optimization engine 140. Unlike systems that input all constraints and cases into a single mathematical optimization solver to find a solution, this system employs a multi-layer pipeline structure that combines "heuristic candidate generation (Layer A, B)" and "exact optimization using integer linear programming (ILP)" to avoid computational explosion caused by the complex time windows (specified delivery / consolidated delivery) and loading constraints specific to moving operations.

[0028] As shown in Figure 2, the multilayer optimization engine 140 first takes a set of unconfirmed cases 200 as input data and uses a predetermined construction heuristic (such as a multilayer bin packing algorithm) to generate multiple "one-way candidate patterns 210" in memory that represent variations of one-way trips (Layer A: generation of one-way patterns). In generating these one-way candidate patterns 210, for example, multiple unconfirmed cases that are geographically close, such as when the departure terminal and destination terminal are exactly the same or belong to the same delivery area code set in the system, are grouped together, and a combination is searched for in which the sum of their household goods volume (m^3) does not exceed the maximum loading capacity of the truck (for example, about 50 m^3 for a 10-ton truck). Furthermore, physical and operational constraints, such as prohibiting the combination of luggage belonging to specific customers (for example, unintentionally splitting luggage belonging to the same customer onto multiple flights) and prohibiting the co-loading of luggage of extremely different sizes on the same flight (for example, avoiding the co-loading of heavy and light items to avoid the risk of luggage damage), are evaluated in advance, and impossible combinations that violate these constraints are excluded from the candidates beforehand.

[0029] Next, as the second stage of processing, the multilayer optimization engine 140 dynamically searches for and combines pairs of one-way patterns from the vast number of generated one-way candidate patterns 210 that satisfy geographical consistency between departure and arrival terminals, such as the destination terminal for the outbound journey being the same as the departure terminal for the return journey, or the empty vehicle transfer distance (or travel time) between the two terminals being within a predetermined threshold (e.g., 50 km), and that also satisfy the overlap condition (time window constraint; in this example, June 2nd or 3rd overlaps) of the possible arrival dates for the outbound journey (e.g., June 1st to June 3rd) and the possible departure dates for the return journey (e.g., June 2nd to June 4th). (Layer B: Round-trip matching). Then, based on the evaluation criterion of maximizing the utilization rate of trucks and quickly moving them to the next operation, the engine automatically sets the earliest day (earliest day) in the overlap period between the outbound and return journeys as the common turnaround day, thereby generating a "same-day round-trip candidate pattern 220" that allows one vehicle to efficiently perform round-trip operations. By performing this two-stage heuristic-based filtering (clipping), combinations that were originally impossible to execute and which are preferable to exclude from the calculation can be removed before the ILP solver 240 performs the calculation, thereby further optimizing the computation space.

[0030] The resulting sets of "one-way candidate patterns 210" and "same-day round-trip candidate patterns 220" are combined into a single larger "pool of candidate patterns 230". This pool 230 contains a mixture of patterns with partial overlap (for example, several thousand to tens of thousands of combinations).

[0031] Finally, as the third stage of exact optimization, the multi-layer optimization engine 140 inputs this pool 230 into an integer linear programming (ILP) model. Specifically, it sets binary variables to indicate whether or not to adopt each candidate pattern in pool 230, and the ILP solver 240 solves the mathematical model using a multi-stage objective function while satisfying the assignment constraint (equality constraint, etc.) that "all moving cases are assigned exactly once to one of the adopted flights (patterns) (no duplication or omissions)." More specifically, as "Stage 1," it first solves the objective function to minimize the total number of flights (number of trucks consumed), and then fixes (adds) the obtained optimal value of the minimum number of flights as a new constraint condition. Then, in "Stage 2," the objective function is set to equalize the loading rate of each flight (for example, minimizing the sum of the absolute error between the loading rate of each flight and the target value so that it can be handled by ILP, or maximizing the minimum loading rate, etc.) or to maximize a specific priority (for example, the sum of the business requirement scores assigned to each pattern), and the problem is re-solved (lexicographical optimization method). In this way, from the countless options that make up pool 230, the "optimal combination of patterns 250" that best satisfies the needs of the field while minimizing the total number of flights is mathematically and precisely determined and extracted as a definitive solution.

[0032] In this way, by using heuristics that reflect on-site moving know-how to pre-generate "meaningful options (one-way and round-trip tickets)" and employing a multi-layered structure in which the ILP solver 240 selects the "most efficient combination" from among them, it becomes possible to output a more accurate long-distance dispatch plan (with as little wasted empty vehicle or loading loss as possible) within a practical timeframe (for example, a few seconds to tens of seconds).

[0033] Figure 3 is a conceptual diagram illustrating the refinement process of the dispatch plan through algorithmic Repair (automatic repair process). The optimization engine in this system does not simply use the "optimal combination of patterns (initial solution) 300" output by the aforementioned integer linear programming (ILP) solver as the final definitive solution. Instead, it dynamically searches for further room to reduce the number of flights (breaking the limits of optimization) through an automatic iterative improvement algorithm within the system.

[0034] As shown in Figure 3, the algorithmic Repair process broadly incorporates two local search algorithms: "integrated repair process 310" and "round-trip additional repair process 320," which are executed iteratively like puzzle-like block operations.

[0035] First, in the integrated repair process 310, multiple flights included in the initial solution 300 output from the ILP solver are sorted, for example, in descending order of loading rate. From these, pairs of flights (e.g., flight A and flight B) are greedily extracted, where the loading rate is below a predetermined threshold (e.g., 50%) and the travel routes (e.g., both from Tokyo to Osaka) and dates (time windows, e.g., departure on June 1st and departure on June 2nd) overlap or are adjacent to each other. Then, the data of the moving cases (household goods volume blocks) assigned to these two flights are combined in memory, and it is determined whether it is possible to fit everything within the loading capacity of one flight (integrated flight C, for example, changing the vehicle type (upsizing) from two 4-ton truck flights to one 10-ton truck flight) (at this time, geometric interference detection within the cargo bed based on the aforementioned 3D dimension data is also performed), and whether or not it violates operational constraints such as the prohibition of mixing specific cargo on the same flight. If possible, the engine will be repaired to "consolidate" flights A and B into a single flight C, resulting in a "minus one flight" in the total number of flights.

[0036] Next, in the round-trip additional repair process 320, the system extracts the flights planned as "one-way flights" in the initial solution 300 (for example, one-way flight D from Terminal X to Terminal Y). Then, from the database of unconfirmed cases or other inefficient flights (for example, flights with a loading rate of less than 30%), the system automatically searches for a moving case (return cargo block E) that matches the return journey of the one-way flight D (the reverse direction from Terminal Y to Terminal X) and satisfies the time window (for example, the cargo can be unloaded from Terminal Y on or after the day of arrival of one-way flight D at Terminal Y). If a suitable return cargo block E is found, the system dynamically "combines" it as the return journey of one-way flight D, repairing it into a round-trip flight pattern using a single vehicle. Any other case data that remains unmatched as a result of dismantling the inefficient flights is temporarily returned to the database of unconfirmed cases, and data control is performed to reallocate it to an available slot in another flight in a subsequent iterative loop. This eliminates the need for a separate freight service that would have been arranged to transport return cargo block E, resulting in a further reduction in the overall number of freight services.

[0037] The optimization engine iteratively executes the integrated repair process 310 and the round-trip additional repair process 320 in a loop, applying multiple search logics sequentially or alternately, for example, first applying the integrated repair process 310 until no further improvement is observed, then applying the round-trip additional repair process 320, and if improvement is obtained there, returning to the integrated repair process 310 again, until the solution no longer improves (i.e., predetermined convergence conditions are met, such as the total number of flights no longer decreasing, or the average loading rate no longer improving even if the total number of flights remains the same).

[0038] As shown in the bottom row of Figure 3, after executing this automatic Repair loop process, it is determined whether the total number of flights calculated for the repaired pattern combination is lower than the total number of flights in the initial solution 300. Only if the number of flights is lower, the engine discards the initial solution 300 and adopts the efficient repaired pattern combination as the "new flight allocation plan (improved solution) 330," which is then output to the screen, etc.

[0039] In this way, by combining macro-level overall optimization using ILP (initial solution 300) with micro-level automated Repair (local search) optimized for the characteristics of moving operations, it is possible to further reduce "spatial gaps of a few m³" and "slight overlaps in schedules" that might be missed by mathematical solvers alone, thereby maximizing the effect of reducing the number of trucks required for actual transportation.

[0040] Figure 4 is a conceptual diagram of a platform that enables the standardization of available slots into transaction units and their inter-company sharing. This system not only improves dispatch efficiency within a single company, but also transforms the "unavoidable spatial and temporal leeway" that arises after optimization into valuable digital assets, functioning as an industry transaction infrastructure (ecosystem) involving various businesses.

[0041] As shown in Figure 4, the information processing device (optimization engine 140) scans the final allocation plan 400 output after optimization processing such as automatic repair, and automatically extracts flights 410 whose loading rate is less than a predetermined threshold (e.g., 90%) and which do not have flags set such as security constraints that prohibit consolidation with other companies' cargo. The device then calculates the physical "remaining capacity (m^3)" for the extracted flights 410 and the temporal "acceptable free time slot (e.g., an additional loading slot of several days in a specific section, calculated backward from the grace period for delivery of the consolidation flight)" for consolidation flights with sufficient time in the schedule.

[0042] Normally, these empty slots would be treated simply as "loading losses (waste)," but in this system, these calculated remaining capacity and empty slots are redefined (packaged) within the system as "digital units (e.g., transaction tickets or digital tokens linked to space and time) 420" that can be exchanged and traded with other companies and partner companies. Specifically, in this packaging process, each empty slot is assigned a unique ticket ID within the system, and a data record is generated that is linked to metadata such as the originating flight ID, departure and arrival terminals, remaining capacity (m^3), available period, and consideration for the exchange (price, exchange points, etc.).

[0043] The system outputs these digitized transaction tickets 420 as information that can be provided to a common platform (available slot trading market) 430 built on the network, and makes it public. The common platform 430 is connected to be accessible not only to dispatchers using the company's own system, but also to the terminals of external partner companies and other businesses 440.

[0044] Other companies 440 can view transaction tickets 420 on the common platform 430 and purchase these digital units (transaction tickets 420) or exchange / share them with their own available slots to use as "transportation" for their own moving jobs (cargo). When the system receives a purchase (or exchange) request from another company 440 and a match is made, it automatically adds (inserts) the other company's moving job data (cargo volume, origin and destination, etc.) to the allocation list of the company's own service 410, which is the source of the corresponding transaction ticket 420, and links and confirms it as new dispatch data that combines the cargo of the company and the other company. If the transaction type is "exchange (barter)", the system performs a join control that mutually inserts (cross-packs) the moving job data of both parties into each other's service information tables. Specifically, if the transaction target is "remaining capacity," the aforementioned insert process confirms spatial consolidation. If the transaction target is "flexible scheduling," the system automatically shifts (changes) the operating schedule of its own flights 410 within the available period defined in the ticket to match the specified date of another company's 440 project, thereby completing the packing. Furthermore, in synchronization with the confirmation of this data consolidation, the system autonomously executes electronic expense settlement processing (or digital token transfer processing) between the seller and buyer based on the price or point rate assigned to the ticket, via the settlement subsystem of the common platform 430. This series of dispatch data consolidation and settlement processing is controlled as a distributed transaction, and if an exception such as a communication error or constraint violation occurs in any processing stage, the system immediately discards (rolls back) all changes to strictly ensure data consistency.

[0045] By adopting this system configuration, companies that implement this system can not only use it as a tool to streamline dispatch operations, but also create a "trading platform for buying and selling available slots" among competitors. As a result, the convenience for system users will be further improved.

[0046] <1 Configuration Diagram> Figure 5 is a block diagram showing the overall configuration of the vehicle dispatch planning optimization system 1 according to this embodiment.

[0047] As shown in Figure 5, the dispatch planning optimization system 1 comprises a dispatch planning server 100, multiple base terminals 200 (e.g., base terminals 200A, 200B, ...), and an external system 300, all connected to each other via a communication network 50 for data communication. The communication network 50 is a secure information communication network constructed using, for example, the Internet, an intranet, a VPN (Virtual Private Network), a dedicated communication line, a mobile communication network, or a combination thereof.

[0048] The dispatch planning server 100 is an information processing device that runs the multi-layer optimization engine 140 and the available slot trading platform (common platform 430), which are the core of this system. Specifically, it is built as a distributed computing architecture (for example, a group of virtual servers or containers built on a cloud environment) that separates and coordinates a group of web servers that distribute requests via a load balancer and a group of background workers that asynchronously execute computationally intensive multi-layer optimization processing via a queue. The dispatch planning server 100 receives data on moving cases (for example, a CSV file containing attribute information such as departure and arrival terminals, volume of household goods, specified dates, and desired period for consolidated shipments) sent in batch processing from each base terminal 200, as well as manual confirmation operations from users (triggers for manual Repair), in real time via asynchronous communication using REST APIs, WebSockets, etc., executes an optimization algorithm to calculate a new flight allocation plan 40, and distributes the results to each terminal. In this process, the Web servers of the dispatch planning server 100 do not immediately start calculations upon receiving an optimization request. Instead, they generate a hash value of the input data (e.g., a cryptographic hash such as SHA256), issue a unique job ID, register the status (e.g., PENDING) in the database, and then immediately return the job ID to the base terminal 200 (e.g., HTTP status 202) to perform asynchronous job acceptance control. While responding to periodic polling (status acquisition requests) from the base terminal 200 with progress updates, the background workers execute the actual multi-layer optimization process. Furthermore, the system also includes a job operation management function that checks the calculated hash value and, if a similar input request has been executed in the past, skips heavy mathematical calculations and immediately returns the existing calculation results as a cache. This function also restricts simultaneous execution of optimization jobs by the same user through mutual exclusion.

[0049] The base terminal 200 is an information processing terminal (e.g., personal computer, tablet, smartphone, etc.) used by dispatchers (users) at each terminal branch located throughout the country. Dispatchers access the dispatch planning server 100 via a rich front-end program such as a Single Page Application (SPA) using JavaScript, etc., running on the web browser of the base terminal 200, and perform interactive operations such as specifying confirmed cases 10, visually confirming the dispatch plan (assignment plan 40) presented by the AI ​​(viewing Gantt charts, etc.), and "locking" specific flights (protecting them as non-changeable). In the communication between this base terminal 200 and the dispatch planning server 100, in order to maintain a secure authentication state, an authentication token (e.g., JWT, etc.) is stored as a cookie with secure attributes (e.g., httpOnly attribute or SameSite attribute) that prevent direct access from JavaScript on the browser, and shielding control is performed to securely transfer and attach the token to the API request header via a front-end proxy server (routing handler, etc.). This ensures a high level of security for the business system.

[0050] The external system 300 is a group of external systems that exchange data with the dispatch planning server 100 via APIs (Application Programming Interfaces), etc., and includes, for example, a personnel / shift management system 310 and terminals for other vendors 320.

[0051] The personnel and shift management system 310 is a database system that manages data on the availability of workers (drivers and moving staff) at each terminal branch (shift availability). When the dispatch planning server 100 performs optimization calculations for consolidated shipments, it dynamically retrieves (fetches) resource information from the personnel and shift management system 310 in bulk just before the start of the calculation process and loads it into memory. It then determines the delivery date by including not only the available capacity of the truck bed but also the "availability of workers (for example, the number of available loading workers at the originating terminal and unloading workers at the destination terminal on the relevant date and time)" as a condition. In other words, even if there is sufficient remaining capacity in the truck, it determines that it is impossible to execute (constraint violation) on dates when there is a shortage of workers at either the originating or destination terminal, and calculates the optimal delivery date when both truck slots and worker slots are available.

[0052] The third-party terminal 320 is a terminal used by personnel from partner companies and competitors located outside of the company's ecosystem. The third-party terminal 320 is used to access the "available slot trading market" published on the common platform 430 by the dispatch planning server 100, to view the remaining capacity of digitized flights and the acceptance slots (transaction tickets 420) for consolidated flights, and to carry out purchase and transfer procedures. Once this procedure is completed, the third-party terminal 320 sends the other company's moving case data to the dispatch planning server 100 via API. The dispatch planning server 100 receives the data via an encrypted communication path such as TLS (Transport Layer Security), after secure authentication and authorization processing using standard protocols such as OAuth and JWT (JSON Web Token). The dispatch planning server 100 then performs data linkage, converting (mapping) the other company's data structure to fit the schema of its own internal database, and automatically incorporating it into the allocation plan for the corresponding flights.

[0053] This network configuration means that the system is not merely a closed dispatch tool confined to a single location, but rather integrates a nationwide network of locations and connects to HR resources (HR / shift management system 310) and external partner companies (other vendor terminals 320), realizing a highly scalable system ecosystem from a hardware perspective.

[0054] Figure 6 is a block diagram showing the internal functional configuration of the dispatch planning server 100 according to this embodiment. The dispatch planning server 100 is configured as a general server computer or a virtual computing instance on the cloud, and includes at least a communication unit 110, a storage unit 120, and a control unit 130, which are connected to each other via defined signal lines such as buses so that they can communicate data with one another.

[0055] The communication unit 110 is a communication interface circuit (such as a LAN card) for sending and receiving data between the base terminals 200 and external systems 300 via the communication network 50. The communication unit 110 receives relocation information transmitted from the base terminals 200 and passes it to the control unit 130, and also transmits the allocation plan 40 calculated by the control unit 130 to the base terminals 200.

[0056] The storage unit 120 is composed of volatile memory such as RAM (Random Access Memory) and non-volatile storage devices such as HDD (Hard Disk Drive) and SSD (Solid State Drive). The storage unit 120 stores a vehicle dispatch plan optimization program to be executed by the control unit 130 (processor), and also has various databases necessary for processing, including a case information database 121 for storing the requirements of moving cases, a transportation plan database 122 for storing transportation plan data, and an intermediate data storage area 123 for temporarily holding candidate patterns generated during the calculation process.

[0057] The control unit 130 is a processor such as a CPU (Central Processing Unit) or GPU (Graphics Processing Unit), and by reading and executing programs stored in the memory unit 120, it functions as a case identification unit 131, a multi-layer optimization engine 140, and a transaction management unit 132.

[0058] The case identification unit 131 identifies multiple moving cases obtained via the communication unit 110 into confirmed cases 10 and unconfirmed cases 20 by referring to, for example, status flags in the input data. It also performs a process to protect (lock) the flights to which confirmed cases 10 are assigned by activating the confirmed flag in the database and excluding them from the variables of the subsequent mathematical model (or treating them as constants), thereby preventing changes to the dispatch plan.

[0059] The multi-layer optimization engine 140 is a mathematical calculation engine that processes the system. In order to generate a vehicle dispatch plan at high speed while satisfying the complex constraints specific to moving operations, it is equipped with internal functional blocks that can be independently or organically linked, including a "candidate pattern generation unit 141," a "same-day round-trip matching unit 142," an "ILP solver execution unit 143," and an "automatic repair processing unit 144." Specifically, the multi-layer optimization engine 140 controls parallel computation (multithreaded processing) using the multi-core resources of the control unit 130 (processor), and also manages the exclusive deployment and sharing of intermediate data objects passed between each functional block into the memory space on the intermediate data holding area 123.

[0060] The candidate pattern generation unit 141 (heuristics unit) reads out moving-specific constraints (such as limits on the size of household goods and the prohibition of consolidating specific items on the same trip) from the storage unit 120 based on the information of the unconfirmed cases 20 identified by the case identification unit 131, and generates multiple one-way trip candidate patterns using a predetermined bin packing algorithm, such as the FFD (First-Fit Decreasing) method, which prioritizes allocating truck capacity to cases with larger amounts of household goods. The generated one-way candidate patterns are temporarily expanded into the intermediate data storage area 123.

[0061] The same-day round-trip matching unit 142 dynamically searches for and combines pairs from among multiple one-way candidate patterns held in the intermediate data holding area 123 that satisfy geographical conditions (for example, the distance of empty vehicle transfer between both terminals is within a predetermined threshold of 50 km) and overlap conditions for the outbound and return trips (for example, time window constraints such as the date obtained by adding a predetermined operational lead time to the scheduled arrival date of the outbound trip being included within the acceptable range of the return trip's loading period) to generate a "same-day round-trip candidate pattern" for a single vehicle. At this time, the earliest date within the overlap period between the possible arrival date of the outbound trip and the possible departure date of the return trip is determined as the common turnaround date.

[0062] The ILP solver execution unit 143 uses the vast number of candidate patterns generated by the candidate pattern generation unit 141 and the same-day round-trip matching unit 142 and stored in the intermediate data holding area 123 as input variables for a mathematical model (for example, a binary variable indicating whether or not to adopt each candidate pattern), and uses integer linear programming (ILP) to derive the combination of patterns that minimizes the total number of trips, such as the number of trucks consumed, while satisfying constraints such as "all undecided cases 20 are assigned to one of the adopted patterns without excess or deficiency" (or relaxed constraints that allow for unassigned cases while imposing a high penalty cost), as the first stage, and as the second stage, selects and extracts the final optimal combination (initial solution 300) by taking into account priorities, etc.

[0063] The automatic repair processing unit 144 (automatic Repair processing unit) executes a local search algorithm to seek further efficiency improvements within the system for the initial solution 300 selected by the ILP solver execution unit 143. Specifically, it repeatedly performs "integrated repair processing 310" to combine multiple flights with low loading rates into one in memory, and "round-trip additional repair processing 320" to combine undetermined cases 20 in the opposite direction with one-way flight patterns to make them round trips. If the total number of flights decreases further than the initial solution 300, it adopts the repaired plan as a new allocation plan 40 and executes control to permanently overwrite and save the improved solution data in memory to the flight information table 800 of the flight plan database 122 via transaction processing.

[0064] The transaction management unit 132 calculates the remaining capacity of flights whose loading rate falls below a predetermined threshold and the available slots (empty slots) of consolidated flights with available time slots after optimization by the multi-layer optimization engine 140. By assigning and linking metadata such as a unique ticket ID, departure and arrival terminal, remaining capacity value, and available period to these, it defines (packages) the data as a digital unit (transaction ticket 420) that can be exchanged and traded with other operators. It then controls the output and publication to the common platform 430 via a Web API using a structured data format such as JSON (JavaScript Object Notation) format.

[0065] In this way, the dispatch planning server 100 reduces the explosion of computational complexity as much as possible by having multiple independent algorithm modules (141 to 144) function in a multi-layer pipeline on the hardware resources of the control unit 130 (processor), thereby realizing a more accurate dispatch planning output within a practical timeframe.

[0066] <2 Data Structure> Figure 7 shows an example of the data structure of the case information table 700, which is stored in the case information database 121 of the storage unit 120 and used as input data for identification processing and multi-layer optimization calculations by the control unit 130 (processor). The case information table 700 has a relational database data structure (or key-value type data structure) for managing the requirements and physical constraints of individual moving cases subject to long-distance transport on a record-by-record basis, and each record is provided with the following multiple management fields.

[0067] The "Case ID (Moving ID) 701" field stores identification information (e.g., a UUID or sequential number) to uniquely identify each moving case within the system.

[0068] The "Case Type (Specified / Consolidated Flag) 702" field stores, as a logical value (flag) or identification code, the classification requirement for whether the relevant moving case is a "specified delivery" with a fixed delivery date, or a "consolidated delivery" with a predetermined range of delivery periods allowed. The case identification unit 131 instantly identifies and classifies the acquired group of cases into specified deliveries and consolidated deliveries by scanning the value of this field.

[0069] The "Household Goods Volume / Size (Volume Information) 703" field stores the total volume of the goods in the case (e.g., numerical data in m^3 units) and size information of custom-made large furniture, etc. (e.g., 3D dimension data of width x depth x height, or attribute flags indicating that the items are long and heavy and cannot be disassembled). The candidate pattern generation unit 141 of the multi-layer optimization engine 140 calculates the cumulative value of this Household Goods Volume / Size 703 to determine whether or not it exceeds the maximum capacity constraint of the transport route (truck bed), and simultaneously performs geometric interference checks of each item with respect to the truck bed space (spatial dimensions of length, width, and height) based on the 3D dimension data (e.g., checking whether a long piece of furniture that cannot be disassembled and is 2.5m in length fits within the remaining depth dimension of the truck bed). Furthermore, it is also possible to include data on the total weight (kg) of the household goods in this field, and it is used not only for volume but also for determining whether or not it exceeds the maximum load weight limit of the vehicle based on the Road Traffic Act, etc. These multifaceted constraint assessments generate a list of physically feasible one-way candidate patterns 210.

[0070] The "Large / Small Package Mixing Prohibition Flag 704" field is a data item that embodies the "mixing prohibition condition that restricts the mixing of specific packages on the same flight." Specifically, it is a control flag to prevent the assignment of "cases with extremely large amounts of household goods (e.g., large-scale moves with household goods of 30 m^3 or more)" and "cases with extremely small amounts of household goods (e.g., small-scale moves for single persons with household goods of 5 m^3 or less)" to the same flight. In moving operations, loading and unloading large-scale cases takes a long time, so mixing small-scale cases on the same trunk line can significantly delay and strain the delivery schedule for the small-scale cases (on-site operational constraints). When the candidate pattern generation unit 141 detects that this Large / Small Package Mixing Prohibition Flag 704 in the acquired record is set to enabled (True), it uses this as a trigger for condition determination and calculates the difference in household goods volume between this case and other undetermined cases that are to be combined on the same flight. If the difference is calculated to be greater than or equal to a predetermined value (for example, 20 m³), ​​it functions as a control flag that excludes (restricts) combinations during the automatic selection generation stage to prevent cases with large size discrepancies from being mixed within the same flight pattern.

[0071] The "Loading Period (Time Window) 705" field and the "Delivery Period (Time Window) 706" field store the moving schedule (date conditions). For designated shipments, a specific single date is stored in "Delivery Period 706," and for consolidated shipments, the range of dates (period data) from the start date to the end date for which loading is permitted is stored in "Delivery Period 706." The same-day round-trip matching unit 142 compares and calculates these period data (for example, it calculates a date by adding a predetermined operational lead time required for long-distance travel and unloading work to a specific date (arrival date at the destination) included in the "Delivery Period 706" of the outbound case, and then determines the logical AND whether the added date overlaps with the permitted range of the "Loading Period 705" of the return case), thereby dynamically calculating an optimized "same-day round-trip" pattern (same-day round-trip candidate pattern 220) in which the outbound and return schedules are consistent in actual operation. In this case, the added operational lead time is not a fixed value. Instead, the system can be configured to dynamically determine the lead time based on the distance traveled, for example, by referring to a distance master between the departure and arrival terminals. For instance, it could be set to "0 days (the same day) if the distance is less than 500km" or "1 day (the next day) if the distance is between 500km and 1000km."

[0072] In this way, by defining physical constraints (703, 704) and time window constraints (705, 706) specific to moving operations as static data models within the case information table 700, the control unit 130 can read these attributes and dynamically bind them to the algorithm's conditional expressions (constraint expressions). As a result, a more practical automated dispatch plan is realized that also conforms to the judgment criteria of experienced dispatchers on site.

[0073] Figure 8 shows an example of the data structure of the flight information table 800, which is stored in the flight plan database 122 of the storage unit 120 and used by the control unit 130 (processor) for generating dispatch plans, protecting confirmed flights, and extracting available slots. The flight information table 800 has a data structure for managing the status of individual flights (truck dispatch slots and flight schedules) managed by the system on a record basis, and each record is provided with the following multiple management fields.

[0074] The "Flight ID 801" field stores identification information (flight number or unique code) to uniquely identify individual scheduled or planned flights (for example, a trunk line flight from Tokyo Terminal to Osaka Terminal) within the system.

[0075] The "Vehicle Used / Maximum Capacity 802" field stores the type of truck assigned to the flight (e.g., 10-ton truck, 4-ton truck, etc.) and the physical maximum load capacity of its cargo bed (e.g., numerical data in m³ units).

[0076] The "Assigned Case List 803" field stores the case IDs of one or more moving cases currently assigned to the relevant flight as array data or relational information. In addition to simply listing cases, it is also possible to structure the data to also hold metadata indicating the packing results, such as the "3D coordinates X,Y,Z of each piece of cargo with the lower left rear of the cargo bed as the origin (0,0,0)" and the "loading order" (for example, array data showing the reverse order of unloading) that takes into account the efficiency of loading and unloading.

[0077] The "Remaining Capacity 804" field calculates the current "available volume (m^3)" of the cargo area by subtracting the total amount of household goods for all moving cases registered in the assignment case list 803 from the maximum capacity 802. This value is recalculated in real time triggered by system events such as provisional assignment during the search process by the optimization engine 140, when cases are combined or separated during the automatic repair (Repair) process, or when a user performs a manual editing operation, and is stored in a database record. The multi-layer optimization engine 140 refers to this remaining capacity 804 data and uses the total amount of household goods for the additional unconfirmed cases 20 to be assigned as a constraint (for example, sum of household goods for additional cases ≤ remaining capacity 804) to determine which slot in the moving schedule the unconfirmed cases 20 can be assigned to (slip into). Furthermore, the transaction management unit 132 extracts shipments in which the remaining capacity 804 exceeds a predetermined threshold (for example, 10% or more of the maximum loading capacity, or a spatial margin of 5 m³ or more as a physical volume) after the final plan output, and uses these as base data for transaction tickets 420 to be published on the common platform 430.

[0078] The "Confirmed Flag 805" field stores control information (logical flag) to "protect confirmed flights from being subject to changes in the dispatch schedule." When a dispatcher confirms (locks) a specific flight via the user interface, or when the system determines in the initial identification process that the dispatch is already confirmed, "1 (True / Protected)" is written to this Confirmed Flag 805. Note that this Confirmed Flag 805 is not simply an on / off logical value, but can also be configured to store multi-level control values ​​according to the protection level, such as "partial lock (status value = 1) that fixes existing cases but allows additional loading into available slots" and "complete lock (status value = 2) that completely prohibits the addition of other cases," such as charter flights and security cases.

[0079] The multi-layer optimization engine 140 (ILP solver execution unit 143 and automatic repair processing unit 144) scans this confirmed flag 805 when executing optimization calculations, and for records where the flag is valid, it performs control that does not modify the contents of the "assigned case list 803" in any way (for example, fixing the binary variable indicating the assignment of the relevant flight and case in the ILP mathematical model to "1", prohibiting deletion, and only allowing addition to an available slot, treating it as a constant rather than a variable). This further protects intentional and implicit human decision-making, such as special requests from customers or considerations for specific drivers on site.

[0080] The "Operation Schedule / Route 806" field stores the departure point (departure terminal), destination (arrival terminal), departure date and time, and arrival date and time (schedule information) of the flight in question. The multi-layer optimization engine 140 compares and matches this Operation Schedule / Route 806 with the loading period 705 and delivery period 706 of the aforementioned case information table 700 (for example, it evaluates whether the departure date and time of the flight in question falls after the "start date and time of the loading period 705 of the case + loading time" and whether the arrival date and time (or unloading completion date and time) falls before the end date and time of the delivery period 706 as an inequality condition. Here, the "loading time" is not a fixed value, but rather a value that the system dynamically calculates by adding a "+45 minute special work addition" when special cargo such as a piano is included to a basic calculation formula such as "30 minutes per 10 m^3 of household goods"), thereby calculating an operation schedule 40 that clears all temporal and spatial constraints.

[0081] In this way, by adopting a data structure that integrates and stores dynamic dispatch status (803, 804, 806) and control flags (805) to protect human judgment within the flight information table 800, the dispatch planning server 100 (system) can stably and deterministically execute a dispatch logic that collaborates between humans and AI, "respecting and protecting past human achievements while focusing on available space (remaining capacity 804) and optimizing it with technology."

[0082] Figure 9 shows an example of an intermediate data structure 900 (candidate pattern matrix) generated by the candidate pattern generation unit 141 and the same-day round-trip matching unit 142 of the multilayer optimization engine 140, and temporarily held in the intermediate data holding area 123 of the storage unit 120.

[0083] To further reduce the computational explosion that would occur if complex time windows and loading constraints specific to moving operations were directly incorporated into the ILP (Integer Linear Programming) model, this system pre-generates combinations of several feasible moving cases (unconfirmed cases 20) as a "packaged single delivery option (candidate pattern)". The intermediate data structure 900 shown in Figure 9 manages these numerous pre-generated options on a record basis, and each record contains the following data items.

[0084] The "Pattern ID 901" field is an identifier used to uniquely identify each generated candidate pattern.

[0085] The "Pattern Type 902" field stores classification information (identification flags) indicating whether the pattern is a one-way "one-way operation" (e.g., type code '1') or a "same-day round-trip operation" where the outbound and return journeys are carried out by a single vehicle (e.g., type code '2').

[0086] The "Associated Case List (Assigned Case Group) 903" field stores, as an array, a set of case IDs for 20 unconfirmed cases that will be transported and processed together if this pattern is "adopted" as the final solution (for example, a set of JOB_001 and JOB_003). In this case, not only is it a simple set of IDs, but packing metadata such as the loading order and 3D placement coordinates within the truck bed for each case, derived in the prior heuristic calculation stage, is also included and stored, linked to each case ID.

[0087] The "Number of Trucks Consumed (Cost Coefficient) 904" field indicates the number of vehicles that need to be arranged to execute the pattern. Normally, this value is "1" for a one-way pattern, but even for a same-day round-trip pattern, the number of vehicles consumed while handling two trips (outbound and return) is calculated as "1". This value functions as a coefficient in the objective function of Stage 1 (minimizing the total number of trips) in ILP.

[0088] The "Route / Turnaround Date 905" field stores the departure and arrival terminals and operating date for the pattern (for example, "Departure from Tokyo, Arrival in Osaka, Operating Date: June 2nd"). In the case of a same-day round trip pattern, the "Turnaround Date (Earliest Date)" calculated from the overlap of the outbound and return dates (for example, if the possible arrival dates for the outbound trip are June 1st to 3rd, and the possible departure dates for the return trip are June 2nd to 4th, the earliest date within the overlapping period, "June 2nd") is recorded here.

[0089] The multilayer optimization engine 140 inputs this intermediate data structure 900 to the ILP solver execution unit 143 as a huge "assignment matrix (constant matrix)" where, for example, the columns represent "each candidate pattern (a binary decision variable x_j ∈ {0, 1} indicating whether or not to adopt it)", the rows represent "all undecided cases 20 (constraints)", and the element a_ij of each cell indicates "whether or not the pattern j contains the case i (1 if it does, 0 otherwise)".

[0090] The ILP solver execution unit 143 reads this matrix and constructs a multi-stage mathematical model. Specifically, in the first stage (Stage 1), it sets a relaxed constraint equation (i.e., Σj a_ij x_j + y_i = 1) that is based on the equation constraint of the Set Partitioning Problem, which states that "all undecided cases 20 (case i) are included exactly once in one of the adoption patterns," while introducing a dummy variable y_i ∈ {0, 1} that indicates the unassigned state of case i in order to avoid physical impossibility (error). Then, it derives the optimal solution with the objective function being that "the sum of the number of trucks consumed in the adopted patterns 904 (cost coefficient c_j) and the sum of the unassigned penalty (a sufficiently large constant M) are minimized" (i.e., minimizing Σj c_j x_j + Σi M y_i). Furthermore, in the second stage (Stage 2), the optimal minimum cost C^* obtained in the first stage is fixed as a new constraint (i.e., Σj c_j x_j + Σi M y_i = C^*), and lexicographical optimization is performed to solve the objective function (i.e., maximization of Σj p_j x_j) using the priority score p_j pre-assigned to each pattern j, thereby mathematically searching for and determining the 250 optimal combinations of patterns (decision variable x_j) that best match the business requirements. Here, the priority score p_j is a weighting parameter that is dynamically calculated and assigned at the generation stage of each pattern based on the rules of an evaluation table defined in advance in the memory unit 120, etc., for example, "+100 points for patterns that use the company's own flight resources, -50 points for patterns that arrange external chartered vehicles, or +200 points for patterns that include flights designated by VIP customers."

[0091] In this way, by eliminating "impossible combinations" based on physical and temporal constraints in advance (clipping) during the generation stage (heuristics) of the intermediate data structure 900, and by having the ILP solver execution unit 143 focus on solving what could be called "pure combinatorial optimization puzzles," it becomes possible to achieve a higher level of both system response speed (practicality) and output result accuracy.

[0092] Figure 10 shows an example of the data structure of the worker resource table 1000, which is acquired from an external personnel and shift management system 310 via the communication unit 110 and stored temporarily or permanently in the storage unit 120.

[0093] This system can optimize vehicle dispatch and delivery dates by simultaneously considering not only the "spatial availability (capacity)" of the truck bed, but also the resource constraints of "people (workers and drivers)" that are essential for executing moving projects. The worker resource table 1000 has a structure that manages the daily worker dispatch capacity (resource information) at each terminal location nationwide on a record basis, and specifically includes the following fields.

[0094] The "Location ID 1001" field stores a code (for example, a location code for Tokyo, Osaka, Nagoya, etc.) that uniquely identifies the terminal branches and sales offices of the moving company that are distributed throughout the country.

[0095] The "Date 1002" field stores the specific date (calendar data, and, if necessary, time zone shifts such as "AM / PM") that the resource is managed for.

[0096] The "Work Type / Skill Classification 1003" field stores identification codes that indicate the roles and qualifications of personnel involved in moving work (for example, 'W01' for loading workers, 'S01' for piano specialists, etc.). Specifically, it defines classifications such as "trunk line drivers" who can drive long-distance trunk line trucks, "loading workers" who perform loading work at the origin of the move, and "loading workers" who perform loading work at the destination, as well as skill attribute information such as "piano specialists" and "art specialists" who require advanced packing techniques. Furthermore, it is possible to configure the system to include metadata such as each worker's years of experience and skill level (for example, a numerical rating from 1 to 5) based on internal evaluations, in addition to simple role classifications.

[0097] The "Total Available Slots (Upper Limit) 1004" field stores the maximum number of people (or total working hours: man-hours) of the relevant occupation who can work (be booked) at the relevant location on a specific date and time.

[0098] The "Assigned Slot 1005" field stores the number of personnel (or working hours) currently tied up by other confirmed dispatch plans or local (short-distance) moving jobs. In calculating this working time, for example, the total time obtained by adding the travel time required for round trip from each base to the job site (e.g., 1 hour) to the actual working time at the job site (e.g., 2 hours) is strictly blocked (occupied) as the personnel's time slot.

[0099] The "Remaining Available Slots (Availability) 1006" field calculates the remaining amount of personnel resources that can be freely reconfigured and allocated at this time, by subtracting the allocated slots 1005 from the total available slots 1004. This value is recalculated and stored in real time, triggered by events such as updates to attendance (leave, etc.) data in the external personnel and shift management system 310, or dispatch confirmation events for other projects in the system itself.

[0100] When the multi-layer optimization engine 140 (ILP solver execution unit 143) outputs an allocation plan 40 for a "consolidated shipment" with a wide delivery period, it dynamically reads data on the "remaining available slots 1006" for the corresponding date and time at the "source base" and "destination base" of the relevant case from the worker resource table 1000. The multi-layer optimization engine 140 determines that execution is impossible (constraint violation) on dates when the remaining truck capacity 804 is met, but the remaining available slots 1006 for dispatch workers at the dispatch source (or delivery workers at the destination) are "zero" (or less than the number of workers required for the case). Specifically, in mathematical models such as the aforementioned ILP, an inequality constraint is introduced: "The sum of the required number of workers for all assigned cases on a specific date (for example, the number calculated based on the value of the amount of household goods 703 in the case information table 700, using a predetermined conversion table where 1 person is required if the amount is less than 15m^3, and 2 people if it is between 15m^3 and 30m^3, and also based on additional rules such as adding +1 person to the basic number if the physical environment of the building at the site is, for example, "3rd floor or higher without an elevator") ≤ 1006 remaining available slots for that date." Furthermore, if the data for a moving case includes the attribute "piano transport," individual skill constraints are dynamically added, such as making "1006 remaining available slots for piano specialists ≥ 1" a mandatory condition, and control is executed to dynamically determine the optimal date (delivery date) by working backward so that the remaining available slots of 1006 at both locations remain positive and greater than the required number of people.

[0101] In this way, by adopting a data structure that achieves a dynamic tight coupling between the company's "personnel shift management" and "vehicle dispatch planning (logistics)" via the worker resource table 1000, it is possible to prevent operational errors (rework) in the vehicle dispatch planning field, such as "the truck has been arranged, but there are not enough workers for loading and unloading on the day."

[0102] By introducing this system, not only dispatchers but also labor and shift managers at each location will be able to enjoy the convenience of this system (dispatch planning server 100).

[0103] Figure 11 shows an example of the data structure of the available slot transaction table 1100, which is built within the database of the storage unit 120 and used by the transaction management unit 132 to manage the distribution, matching, and settlement of available slots (transaction tickets 420) on the common platform 430.

[0104] This system defines the "remaining capacity of operating routes (remaining capacity 804)" and "acceptance slots for consolidated routes" resulting from the company's dispatch optimization not as mere surplus space, but as independent assets (digital units) that can be traded with other operators. The available slot trading table 1100 has a structure that manages the transaction status of each available slot (trading ticket 420) listed and published on the common platform 430 in token or ticket format on a record basis, and specifically includes the following fields.

[0105] The "Transaction Ticket ID 1101" field stores an identifier (token ID) that uniquely identifies each available asset (digital unit) extracted and published on the common platform 430 within the system.

[0106] The "Original Flight ID 1102" field stores the flight ID of a specific flight operated by the company that is the source (origin) of the available slot. This dynamically creates a relationship with the flight information table 800 in the flight planning database 122. If the original flight's schedule is changed or canceled, the system detects the update event and automatically updates the transaction status 1106 of the transaction ticket in this table to "Publication Suspended" or "Condition Changed." If the transaction has already been completed, an alert notification is sent to other vendor terminals 320 via API, enabling real-time coordinated control.

[0107] The "Provider ID 1103" field stores a code that identifies the business that is offering the available slot. This code is used to identify which business is providing the slot when this common platform 430 functions as a de facto standard shared among multiple different moving companies.

[0108] The "Available Slot Type / Asset Attribute 1104" field stores the specific characteristics of the available slot being traded. The values ​​defined include categories such as "Remaining Capacity (m^3)," which indicates the physical available volume of the truck's cargo bed, or "Flexible Schedule Slot," which indicates the capacity to accept cargo from other companies by taking advantage of the flexibility in delivery dates for consolidated shipments.

[0109] The "Transactionable Quantity / Conditions 1105" field stores the amount of resources and transportation routes available to other businesses. For example, it might store data such as "20m^3" for remaining capacity, "any two days between 2026 / 06 / 01 and 06 / 05" for flexible scheduling, and the target transportation section (e.g., from Tokyo Terminal to Osaka Terminal). Furthermore, this field may also store constraint data used for error detection during matching, such as unacceptable cargo attributes (e.g., no mixed shipments of perishable goods, pets, or extremely large furniture).

[0110] The "Transaction Status 1106" field stores the current distribution phase of the corresponding transaction ticket 420 as a logical value or status code. Specifically, it dynamically updates states such as "Open (Offering)" indicating that the ticket is waiting to be purchased by other vendors on the common platform 430, "Transaction Completed (Hold)" indicating that a match with another vendor has been made, and "Settlement Completed (Closed)" indicating that the actual transportation work and settlement of expenses between vendors have been completed. The system autonomously executes the state transition to "Settlement Completed" when it receives, for example, an API notification from the driver terminal indicating the completion of transportation work or a payment completion callback from an external payment subsystem. In addition to these normal transitions, if an error in the settlement process or a cancellation request from the buyer is detected, abnormal state transitions are also defined and managed, which either roll back the transaction status 1106 from "Transaction Completed (Hold)" back to "Open" or update it to "Invalid (Cancelled)".

[0111] The "Price / Exchange Conditions 1107" field stores the consideration (for example, an amount in legal tender or a unique point / token rate circulating within the common platform 430) when other businesses lend or purchase the available slot. In this case, the data structure for the consideration can not only hold a fixed price, but also calculation rules (such as a coefficient of variation for dynamic pricing) to automatically change the price according to the number of days remaining until the scheduled departure date and the market supply and demand balance. These calculation rules can store step-by-step rules such as "discount 30% of the base price when there are 3 days or less remaining until the departure date," or specific calculation formulas such as "multiply the base price by a surcharge coefficient α proportional to the excess demand rate when the total number of searches (demand) on the platform for the relevant segment exceeds the available slots (supply) (for example, offered price = base price × (1 + α))," and the consideration is recalculated in real time each time a viewing request is made.

[0112] The transaction management unit 132 automatically creates and adds a record to the available slot transaction table 1100, triggered by the completion of calculations by the multi-layer optimization engine 140, and publishes it as listing information on the web interface of the common platform 430. When a purchase request is received from another operator's terminal (other operator's terminal 320) via the communication unit 110, the transaction management unit 132 performs exclusive control (transaction lock) to prevent duplicate purchases from others, and performs a final verification of whether the size of the target package and the conditions prohibiting consolidation match the conditions of the relevant flight. Specifically, it performs an inequality check to determine whether the volume of the package included in the purchase request is less than or equal to the remaining capacity of the transaction ticket, and performs a logical operation to determine whether there are any overlaps between the attributes of the purchasing package and the unacceptable attributes on the ticket side (whether the logical AND is an empty set). More specifically, if the unacceptable attribute is stored as an array of attribute codes, such as "pet (code P01)" and "fresh produce (code F01)," the system performs a verification process to check whether these codes are included in the cargo attribute array within the purchase request data by scanning the array (or performing a bitmask operation). If the verification passes, the transaction status 1106 is changed from "Public" to "Transaction Completed," and the system executes a control to automatically insert the buyer's relocation case data into the assignment case list 803 of the flight information table 800 linked to the original flight ID 1102.

[0113] In this way, by adopting a structure in which "space and time leeway" is objectified and managed in a database as a precise digital transaction unit (transaction ticket ID 1101) using the vacant slot transaction table 1100, an inter-company sharing ecosystem (common platform 430) operates systematically and autonomously, further promoting more active interaction throughout the industry.

[0114] <3 operations> Figure 12 is a flowchart showing the overall procedure of the dispatch planning process executed by the control unit 130 (processor) of the dispatch planning server 100 according to this embodiment, in accordance with the dispatch planning optimization program. This process is triggered, for example, when a dispatching officer operating each base terminal 200 instructs the execution of optimization via the user interface.

[0115] First, in step S1201, the case identification unit 131 obtains data (case information) for multiple moving cases involving long-distance transportation via the communication unit 110. This case information includes requirements for "designated shipments" with fixed delivery dates, requirements for "consolidated shipments" with flexible delivery periods, the size of household goods including 3D dimensional data, and constraint data specific to moving operations, such as flags prohibiting the mixing of large and small items and the required skill classifications of workers.

[0116] In step S1202, the case identification unit 131 identifies whether each of the acquired moving cases is a "confirmed case 10" where the dispatch has already been confirmed by the user, or an "unconfirmed case 20" where the dispatch has not yet been decided. This identification is performed systematically, for example, by conditional branching judgments of status codes included in the input data (CSV, JSON, etc.) (e.g., '0: unconfirmed', '1: manually confirmed', etc.) or by referring to the registration status of the operation plan database 122 (for example, by evaluating whether the assigned flight ID of the case record is NULL).

[0117] In step S1203, the case identification unit 131 identifies the flight (confirmed flight 30) to which the identified confirmed case 10 has already been assigned, and protects (locks) that flight as "not subject to change" in the subsequent optimization algorithm's dispatch plan. Specifically, in the mathematical model handed over to the optimization engine, it fixes the decision variable related to the assignment of that flight as an immutable constant (for example, forcibly setting the adoption variable x_j for the corresponding pattern in ILP to 1), or performs data control to exclude cases already assigned to that flight from the array data to be searched.

[0118] In step S1204, the multilayer optimization engine 140 performs a multilayer optimization process (a calculation process combining heuristics and ILP) to calculate a new flight allocation plan 40, with only the unconfirmed cases 20 as the pure optimization target. At this time, the multilayer optimization engine 140 mathematically searches for the optimal combination of puzzles that minimizes the total number of flights and maximizes the loading rate of each flight, while satisfying various constraints such as the "remaining capacity 804 of confirmed flights 30" protected in step S1203, and the time window requirements for designated flights and consolidated flights. Specifically, it pre-generates candidate patterns for one-way and same-day round trips that satisfy the constraints in memory using predetermined heuristics, inputs them into an integer linear programming (ILP) model, and performs multi-stage mathematical optimization (lexicographical optimization) consisting of a first stage that minimizes the number of trucks consumed and a second stage that takes priority into account, thereby deriving the optimal solution while keeping the computational load down.

[0119] In step S1205, the control unit 130 finalizes the new flight allocation plan 40 (result data) calculated by the multi-layer optimization engine 140, and outputs it in a structured data format suitable for rendering on the front end (for example, a JSON format that uses the ID of each flight as the key and hierarchically holds an array of IDs of assigned cases and timestamp information indicating the loading and unloading of each case) for display data to be drawn on the screen of each base terminal 200 (for example, a Gantt chart format drawing data with each flight arranged on the vertical axis and time on the horizontal axis). As a result, the user is presented with a more efficient and waste-free plan in which the unconfirmed cases 20 are neatly packed into the complex empty slots that even experienced personnel might overlook.

[0120] Subsequently, the system evaluates the actual loading rate of each flight in the outputted plan. If the condition is met that there is a flight with a low loading rate (for example, a loading rate below a predetermined threshold of 90%), the system extracts the remaining capacity 804 of the relevant flight, digitizes it, and publishes it to the common platform 430 (processing by the transaction management unit 132), thus ending the entire flow of the automated dispatch plan.

[0121] Figure 13 is a flowchart showing more detailed calculation steps of the data processing pipeline executed by the multilayer optimization engine 140 (candidate pattern generation unit 141, same-day round-trip matching unit 142, and ILP solver execution unit 143).

[0122] First, in step S1301, the candidate pattern generation unit 141 receives a set of unconfirmed cases 20 from the case identification unit 131 as input, and reads out loading constraints specific to the moving domain (such as limits on the amount and size of household goods, and conditions prohibiting the consolidation of specific items on the same shipment) from the database.

[0123] In step S1302, the candidate pattern generation unit 141 iteratively executes a predetermined multi-layer bin packing algorithm (construction heuristic) within the range that satisfies the loading constraint, and generates multiple "one-way candidate patterns 210" in memory consisting of combinations of executable undetermined cases 20 (Layer A: generation of one-way patterns). Specifically, in addition to a greedy method that sorts and assigns cases in descending order of the amount of household goods, the unit iteratively executes processes such as switching sorting criteria using multiple different evaluation axes, such as "descending order of total weight of luggage" and "prioritizing cases that include long furniture (e.g., 2m or more in length)," and a randomized algorithm that intentionally shuffles the evaluation order of cases using random numbers, thereby intentionally creating a variety of packing variations from the same group of cases.

[0124] In step S1303, the same-day round-trip matching unit 142 scans the set of generated one-way candidate patterns 210 and determines the consistency of the geographical departure and arrival terminals (for example, whether the distance between the outbound arrival point and the return departure point is within 50 km), and whether there is any overlap in the dates of the "possible arrival date for the outbound trip" and the "possible departure date for the return trip" (time window constraint).

[0125] In step S1304, the same-day round-trip matching unit 142 dynamically combines pairs of one-way candidate patterns 210 that satisfy the schedule overlap conditions, and automatically defines the "earliest day" in the overlapping period of the outbound and return journeys as a common turnaround day (for example, if the possible arrival dates for the outbound journey are from June 1st to 3rd and the possible departure dates for the return journey are from June 2nd to 4th, the unit sets "June 2nd," which is the earliest of the overlapping June 2nd and 3rd, as the turnaround day), thereby generating a "same-day round-trip candidate pattern 220" (Layer B: round-trip matching).

[0126] In step S1305, the multilayer optimization engine 140 performs candidate clipping (pruning) on ​​the entire set of generated one-way candidate patterns 210 and same-day round-trip candidate patterns 220 based on predetermined conditions (for example, wasteful patterns with extremely low loading rates, such as those with a loading rate of less than 30%, patterns with negative profit margins where the estimated operating costs exceed fare revenue, or patterns that exceed the driver's legal working hours (for example, 9 hours of driving per day)), and constructs an intermediate data pool (intermediate data holding area 123) to store the input variables for the ILP solver. This reduces the variable space (number of columns in the matrix) that the ILP searches to a computationally feasible and realistic size.

[0127] In step S1306, the ILP solver execution unit 143 applies the mathematical model (integer linear programming) of "Stage 1 (minimizing the number of flights)," which is the first stage of the two-stage optimization process, to the matrix data (intermediate data structure 900) of candidate patterns expanded in the intermediate data pool (intermediate data holding area 123). Under the constraint that all undetermined cases 20 are allocated without omission or duplication, the ILP solver strictly finds the optimal solution (or a set of equivalent solutions) of the combination of patterns that minimizes the total number of flights (number of trucks consumed). In this process, in order to realize the requirement of "using as many as possible," a dummy variable y_i is introduced into the model that allows for unallocated cases but incurs an extremely high penalty cost M (for example, 10 times the normal cost of arranging one truck). The objective function is set as minimizing the sum of cost and penalty (i.e., Σj c_j x_j + Σi M y_i), thereby formulating the solution so that even if it is physically impossible to allocate all cases, the solver does not produce an error and obtains a feasible solution.

[0128] In step S1307, the ILP solver execution unit 143 fixes the condition for the minimum number of flights (the minimum optimal value C^* of cost and penalty) obtained in Stage 1 (or adds it as a constraint equation Σj c_j x_j + Σi M y_i = C^*), and then applies the mathematical model of the second stage, "Stage 2 (priority tie-breaking)". Here, the objective function is the "priority (for example, a linear sum of weight coefficients p_j based on priority, such as assigning a high weight coefficient to patterns that include designated flights and a penalty coefficient to patterns with inefficient routes)" which has been set in advance for each case or for each route, and maximizes Σj p_j x_j. From among the multiple equivalent solutions that may occur in Stage 1 (multiple solutions with the same number of flights but different combinations), it pinpoints (ties down) the optimal combination of 250 patterns that best match the business requirements.

[0129] In step S1308, the multilayer optimization engine 140 finalizes and outputs the combination of candidate patterns ultimately adopted by the two-stage optimization by ILP as the "initial solution 300 for the vehicle dispatch plan," and terminates the flow of this algorithm pipeline.

[0130] In this way, by pre-constructing "one-way / round-trip patterns (210, 220)" that incorporate the physical and operational constraints of moving using heuristics (S1301 to S1305), and entrusting the rigorous mathematical selection of their combinations to the ILP solver execution unit 143 (S1306 to S1307) using a two-stage objective function, a robust and faster automated dispatch engine is realized that can keep computational explosions under control while flexibly adapting to on-site priorities and unexpected conditions.

[0131] Figure 14 is a flowchart showing the detailed calculation procedure of the automatic repair process that the automatic repair processing unit 144 of the multilayer optimization engine 140 autonomously performs within the system to seek further efficiency improvements (reduction in the number of flights) to the initial solution 300 output by the integer linear programming (ILP) solver (ILP solver execution unit 143).

[0132] First, in step S1401, the automatic repair processing unit 144 acquires the combination of patterns (initial solution 300 for the dispatch plan) output from the ILP solver execution unit 143, and records the total number of trips (initial number of trucks) in the initial solution 300 as the initial value of the evaluation value in memory (storage unit 120).

[0133] In step S1402, the automatic repair processing unit 144 calculates and examines the loading rate of each flight in the acquired plan, and extracts pairs of low-load flights whose loading rate is below a predetermined threshold (e.g., 50%), and pairs of flights that are close together in terms of travel route (e.g., the departure and arrival points are the same, or are in adjacent areas such as within a 30km radius in a straight line) or schedule (e.g., the difference in departure dates is the same in absolute value or within 1 day (±1 day)).

[0134] In step S1403, the automatic repair processing unit 144 performs a "Combine Repair" on the extracted pair of flights. Specifically, it merges all the moving case data (assigned case list 803) assigned to the two flights into one flight in memory, and determines whether it fits within the range of the maximum loading capacity of the vehicle used (vehicle used, maximum capacity 802), as well as performing a geometric interference check within the cargo bed based on the aforementioned 3D dimensional data, to determine whether it is physically possible to pack into one vehicle without deviating from various constraints specific to moving (such as the prohibition of mixing large and small items). If packing is possible, it forcibly merges these two flights into one flight, performing a repair that reduces the total number of flights by "one flight".

[0135] In step S1404, the automatic repair processing unit 144 extracts records of "one-way flights" in the plan for which no cases are assigned to the return trip.

[0136] In step S1405, the automatic repair processing unit 144 executes a "round-trip repair process 320" on the extracted one-way flights. Specifically, it temporarily dismantles the unconfirmed cases 20 in the database or other inefficient flights (e.g., flights with a loading rate of less than 30%) in memory and extracts cases from which it dynamically searches for moving cases (return cargo) that satisfy the travel route and time window constraints (e.g., the time after the driver's legal rest period (e.g., 11 consecutive hours) has been added to the arrival time of the one-way flight) of the return flight, for the reverse direction (return journey, for example, if the outbound journey is from Tokyo to Osaka, the return journey is from Osaka to Tokyo). If a return cargo that meets the conditions is found, it is combined with the return journey of the one-way flight to repair the flight pattern into a round-trip flight. This eliminates the need for another flight that would have been arranged separately to transport the return cargo, and as a result, further reduces the total number of flights.

[0137] In step S1406, the automatic repair processing unit 144 determines whether it has reached a "locally optimal solution" where no further improvement of the solution (reduction in the number of flights) can be expected, based on a series of local searches performed by the integrated repair process 310 in step S1403 and the round-trip additional repair process 320 in step S1405 (for example, whether it has exhausted the search for all verifiable pairs of flights and combinations of return cargo, or whether it has reached a pre-set upper limit on the number of iterations (e.g., 100 times) or the upper limit on the calculation time (e.g., 10 seconds)). If there is still room for improvement in the solution (for example, if at least one repair was successful in the previous search and the number of flights decreased) (step S1406·No), the process immediately returns to step S1402 and iteratively executes the repair loop targeting the new flight combinations after the update.

[0138] If the solution improvement stops (step S1406 · Yes), the process proceeds to step S1407. In step S1407, the automatic repair processing unit 144 compares the total number of flights in the final plan after iterative repair with the total number of flights in the initial solution 300 recorded in step S1401, and determines whether the total number of flights has "decreased" compared to the initial solution 300.

[0139] If the total number of flights decreases below the initial solution 300 (step S1407, Yes), the process proceeds to step S1408, where the automatic repair processing unit 144 discards the initial solution 300 and adopts and updates the improved plan after the repair as the "new flight allocation plan (improved solution 330)".

[0140] On the other hand, if an attempt at automatic repair fails to reduce the total number of flights below the initial solution of 300 due to constraints (step S1407·No), the process proceeds to step S1409, where the automatic repair processing unit 144 maintains the allocation state of the initial solution 300 without updating the solution (confirming it as the maintenance solution).

[0141] After completing the processing in step S1408 or step S1409, the multilayer optimization engine 140 terminates the series of automatic repair processing flows and passes the finalized plan data (allocation plan 40) to the next step (such as outputting to the user screen).

[0142] Thus, by incorporating a procedure (S1402 to S1406) that autonomously and greedily iteratively executes "integration" and "reciprocal processing" from a micro perspective within the system after a comprehensive macro optimization (ILP), it becomes possible to fill in even the smallest gaps at the field level (a few m³ of cargo space (remaining capacity 804) or overlapping schedules on a daily basis) that tend to be overlooked due to the mathematical characteristics of the solver, thereby maximizing the reduction effect on the total number of trips in actual operations.

[0143] Figure 15 is a flowchart detailing the processing steps of the manual Repair loop (human-AI interaction) executed between the dispatch planning server 100 and the base terminal 200. Unlike the "automatic repair (algorithmic Repair)" within the system shown in Figure 14, this process defines a "collaborative repair process" in which the system follows and recalculates based on explicit decisions made by a human (dispatcher).

[0144] First, in step S1501, the control unit 130 of the dispatch planning server 100 transmits the data of the flight allocation plan (initial plan 40, or improved solution 330, which is the plan after automatic repair) calculated by the multi-layer optimization engine 140 to the base terminal 200 via the communication unit 110, and displays the dispatch planning results (dispatch planning results / manual repair operation screen 1800) such as a Gantt chart on the display of the base terminal 200.

[0145] In step S1502, the control unit 130 receives confirmation and editing operations from the user regarding the displayed dispatch plan via the user interface (dispatch plan result / manual repair operation screen 1800) of the base terminal 200. Here, the user selects a specific dispatch from among the multiple dispatches presented that matches the specific circumstances of the site (for example, "I want the driver of this dispatch to drive this route," or "I absolutely want this cargo delivered on this day"), or a dispatch that the system has packed very well. In addition, if necessary, the user can perform manual editing, such as manually transferring a specific item to a different date or dispatch using drag-and-drop operations with the mouse pointer before the lock operation, or manually fine-tuning the departure date and time of a dispatch. After these confirmations and edits, the user performs a "manual confirmation (lock)" operation on the relevant dispatch via the protection state switching unit 1820.

[0146] In step S1503, the control unit 130 determines whether the manual confirmation operation has been performed. If the confirmation operation has not been performed (for example, if the entire plan is approved as is, or if the process is terminated) (step S1503 No), the flow of this manual Repair loop ends.

[0147] If a confirmation operation is performed (step S1503, Yes), the process proceeds to step S1504. In step S1504, the case identification unit 131 activates (updates to True) the "Confirmed Flag 805" in the flight information table 800 for flights (and associated relocation cases) that have been manually confirmed by the user's modification operation. As a result, the flight is locked as a new "Confirmed Case 10" and is protected from modification in subsequent calculations. Specifically, not only the combination of assigned cases (assigned case list 803), but also the framework information itself, such as the departure and arrival terminals and schedule (flight schedule / route 806) of the flight, is strictly fixed as constant parameters that cannot be changed in the system.

[0148] In step S1505, the multilayer optimization engine 140 maintains and protects the remaining capacity 804 of the manually confirmed flights and the framework of existing confirmed flights (confirmed flights 30), while performing real-time recalculations (re-optimization) on the "remaining unconfirmed cases 20" that have not yet been confirmed. Specifically, it strictly locks and protects the data of relocation cases (deletions and relocations) already registered in the "assigned case list 803" of the manually confirmed flights as constants in the mathematical model, while executing data control to maintain the value of the "remaining capacity 804" of the flight in the mathematical model as an effective free capacity constraint for adding (packing) the remaining unconfirmed cases 20. In this case, the multilayer optimization engine 140 re-executes the heuristics and ILP processing pipeline (S1301 to S1308) shown in Figure 13, but in the candidate pattern generation stage, in addition to patterns for completely new flights, it prioritizes generating patterns that "add unconfirmed cases 20 to the remaining capacity of manually confirmed flights" and inputs them to the ILP solver. In generating these additional loading patterns, geographical tolerance constraints, such as "whether the detour distance of the original flight route due to passing through the loading / unloading locations of the additional unconfirmed cases 20 is within a predetermined upper limit (e.g., 30 km)," are also evaluated and determined. Furthermore, because the number and combinations (decision variables) of unconfirmed cases 20 to be optimized have been dramatically reduced by manual confirmation compared to the initial calculation, the solver's search space is greatly reduced, the calculation converges with an extremely short response speed of a few seconds (e.g., on the order of milliseconds), and autonomously calculates a new flight allocation plan 40 that optimally fills in the remaining puzzle once again.

[0149] In step S1506, the control unit 130 transmits the data of the new allocation plan 40 recalculated in step S1505 to the base terminal 200 and redraws (updates) the dispatch plan result on the screen (dispatch plan result / manual repair operation screen 1800). During this redraw, the user interface of the base terminal 200 performs rendering control that dynamically updates only the allocation blocks of unconfirmed cases and the timeline of new flights that have changed due to the recalculation, while keeping the drawing elements (graphics) of manually confirmed flights fixed on the screen, via asynchronous communication (e.g., Ajax). Furthermore, if the puzzle becomes physically impossible to complete due to the user's manual confirmation (addition of strong constraints), resulting in unassigned cases (unavailable cargo) that cannot be assigned to any flight, the case is highlighted in a separate frame (alert area) on the screen, and visual feedback is dynamically provided to the user, prompting them to relax the constraints or take alternative action. Subsequently, the process returns to step S1502, and this interaction (loop) of "human manual confirmation → AI real-time recalculation" continues repeatably until the user is completely satisfied with the overall plan and performs the final confirmation operation.

[0150] In this way, instead of the system unilaterally providing a "black box complete solution," by offering a "co-pilot" type UI / UX (dispatch planning results / manual repair operation screen 1800) where the system immediately accepts the user's intentional intervention (pinning) and, as the remaining task, quickly assists with filling in the gaps that might otherwise be burdensome for humans, the system can provide dispatchers with a sense of trust in a "competent assistant that works like an extension of the delivery person's hands and feet."

[0151] Figure 16 is a flowchart showing the specific steps for the transaction management unit 132 of the dispatch planning server 100 to convert available slots into transaction units and publish them to the platform, after a series of optimization and automatic repair processes by the multi-layer optimization engine 140 have been completed. This process defines an important data processing procedure for extracting "spatial leeway in truck beds" and "schedule flexibility (temporal leeway)" that could not be fully utilized in the process of improving the efficiency of dispatching within the company, and converting them into digital assets that can be traded with other companies.

[0152] First, in step S1601, the transaction management unit 132 starts processing triggered by the final output of the dispatch plan (allocation plan 40) from the multi-layer optimization engine 140, and reads records of all created flights from the flight information table 800 of the flight plan database 122.

[0153] In step S1602, the transaction management unit 132 calculates the "actual loading rate" for each individual flight based on the total volume and total weight of the allocated items recorded in the record for each flight. In calculating this actual loading rate, for example, the ratio of the allocated volume to the maximum volume of the truck (volume loading rate) and the ratio of the allocated weight to the maximum load weight (weight loading rate) are calculated separately, and the higher of the two values ​​is adopted as the overall actual loading rate for that flight. Then, it is determined whether or not there are any flights with low loading rates where the calculated actual loading rate falls below a "predetermined threshold (for example, a loading rate of 90%)" set in advance in the storage unit 120. If there are no flights with loading rates below the threshold (step S1602, No), it is determined that all flights are fully loaded and there are no available slots that can be offered to the outside, and this flow is terminated.

[0154] If there are flights with a capacity below the threshold (Step S1602, Yes), the process proceeds to Step S1603. In Step S1603, the Transaction Management Unit 132 accurately calculates the physical capacity, for example, "remaining capacity 804 (m^3)", by subtracting the volume of the currently allocated order from the maximum capacity of the relevant flight. Furthermore, if the order allocated to the flight is a "consolidated shipment", the unit also calculates the time "acceptable slot (flexible schedule slot)" that allows for the acceptance of additional cargo from other companies, by working backward from the grace period (time window). Specifically, if the flight is scheduled to operate on June 2nd, and the allowable delivery period 706 of the consolidated shipment is from June 1st to June 5th, the unit dynamically extracts and defines the difference (the margin in the time window), which is four days before and after, as the "acceptable slot" that allows for the acceptance of additional cargo or a shift in the operating date.

[0155] In step S1604, the transaction management unit 132 binds the remaining capacity 804 (spatial information) or available slot (time information) calculated in step S1603 with data on the flight route (departure and arrival terminals) and flight schedule of the relevant flight using an external key in a relational database (or encapsulates it in a structured data format such as JSON), and redefines it as an "independent digital unit (transaction ticket 420)" that can be exchanged and traded with other operators. Specifically, it creates a unique transaction ticket ID 1101 in the available slot transaction table 1100 built in the storage unit 120, adds metadata such as the provider operator ID and price / exchange conditions, and inserts it as a new record (object-created). In this case, regarding the metadata of price and exchange conditions, the transaction management unit 132 calculates a standard price in proportion to the size of the remaining capacity 804 calculated above, and then multiplies it by a coefficient of variation that corresponds to the number of days remaining until the scheduled departure date (prices decrease as it approaches the departure date, etc.) and the supply and demand balance in the market for the relevant section (for example, the system calculates the ratio of the number of searches for the relevant section in the past 24 hours to the number of available tickets currently on the market, and if the number of searches (demand) is more than twice the number of tickets (supply), the coefficient of variation is set to 1.5 times, etc.) to automatically calculate and assign the consideration for the transfer (price, required number of points, etc.) in real time.

[0156] In step S1605, the transaction management unit 132 outputs and publishes the data of the transaction tickets 420 that have been created and stored in the vacant slot transaction table 1100 to the common platform 430 (vacant slot transaction market) via the communication unit 110. This makes the vacant slots searchable and viewable in real time via the web browsers of other broker terminals 320.

[0157] In step S1606, the transaction management unit 132 monitors and determines whether it has received a "purchase request" or "transfer request" for the publicly available transaction ticket 420 via the network from an external cooperating company or other business operator (other business operator terminal 320) that has accessed the common platform 430. If no purchase request is received within the specified period (step S1606 No), this public processing flow is terminated (the ticket maintains the "publicly available" status).

[0158] If a purchase request is received from another business operator (step S1606, Yes), the process proceeds to step S1607. In step S1607, the transaction management unit 132 dynamically updates the transaction status 1106 in the available slot transaction table 1100 for the relevant ticket from "Available" to "Transaction Completed (Hold)". During this update, the transaction management unit 132 executes row-level exclusive control on the database (transaction lock, for example, by executing the "SELECT FOR UPDATE" syntax or distributed lock using an in-memory data store) to reliably prevent duplicate purchases (double booking) due to simultaneous access from other terminals. Then, it automatically inserts (appends) the moving case data (amount of cargo and origin / destination) of the other business operator that has made the purchase request into the allocation case list 803 of the corresponding original flight's flight information table 800, and executes dispatch data join control to fill the available space in the company's trucks with the cargo of the other company. Immediately before this insert, the multi-layer optimization engine 140 constructs a virtual dispatch state by temporarily merging the buyer's cargo volume and attributes with its own original freight. It then performs a geographical verification to check whether the maximum capacity 802 of the freight is exceeded, whether it violates operational constraints such as the prohibition of mixed cargo of large and small items, and whether the detour distance (or increased travel time) of the original freight due to passing through the buyer's cargo loading and unloading location falls within a predetermined acceptable threshold. After confirming that there are no errors through these final re-verifications, the actual insert process is finalized.

[0159] In step S1608, the transaction management unit 132 calls and executes the expense settlement process (or point / token granting / deducting process) between the provider and the buyer via the settlement subsystem of the common platform 430 (or an external settlement gateway API). Then, provided that it receives a successful response from the settlement subsystem regarding the electronic fund transfer, it changes the status of the ticket in the database to "Settlement Complete (Closed)" and terminates the entire flow of the series of transactions for unitizing available credit.

[0160] In this way, by implementing a procedure (S1602 to S1605) to convert the "waste" (unused space) in the cargo area that still occurs after optimization into "digital transaction units (transaction tickets 420)" that the system can autonomously settle, an efficient collaborative operation ecosystem that transcends the framework of a single company will operate autonomously.

[0161] <4 Screen Examples> Figure 17 shows an example of the configuration of a dispatch planning and condition setting screen 1700 generated by the dispatch planning server 100 according to this embodiment and displayed on the display of the base terminal 200 via the communication network 50. This dispatch planning and condition setting screen 1700 functions as an integrated graphical user interface (GUI) for dispatchers (users) to get an overview of the overall status of the moving case to be processed and to set various conditions and give execution instructions to the multi-layer optimization engine 140.

[0162] As shown in Figure 17, the dispatch planning and condition setting screen 1700 mainly consists of a "case list display area 1710" and an "operation button area 1730".

[0163] The case list display area 1710 is an area that displays data from multiple acquired moving cases (confirmed cases 10 and unconfirmed cases 20) in a tabular format. Specifically, triggered by a screen activation request, the base terminal 200 retrieves the relevant data from the case information database 121 of the dispatch planning server 100 via communication and performs initial rendering control to dynamically draw it into table elements on the screen. As a result, detailed information such as the "case ID," "specified / consolidated shipment classification," "amount of household goods," and "delivery period" for each case is displayed for each record.

[0164] Furthermore, each record within the case list display area 1710 is associated with a "status display unit 1720". The status display unit 1720 visually indicates whether the case identified by the system (case identification unit 131) is "confirmed (not subject to changes in the dispatch plan)" or "unconfirmed (subject to optimization)". For example, by referring to the value of the "confirmed flag 805" in the internal flight information table 800 of the system, a lock icon is added to "confirmed" cases (confirmed cases 10), the entire row is grayed out, or a specific background color is applied, allowing the user to intuitively understand that the case is strictly protected from recalculation by the multi-layer optimization engine 140. On the other hand, for "unconfirmed" cases (unconfirmed cases 20), a pen (pencil) icon is added to indicate that they are subject to editing or automatic dispatch, or a specific background color (e.g., light green or light blue) is applied to indicate an active state, making the visual contrast with confirmed cases 10 clearer.

[0165] The operation button area 1730 contains multiple operation buttons for inputting various instructions to the system, arranged side-by-side on the same screen as the case list display area 1710. This operation button area 1730 includes, for example, "condition setting buttons" in the form of toggle switches for turning on / off constraints specific to moving (such as the prohibition of mixing large and small loads, or the priority assignment of specific skilled drivers), a "manual confirmation button" for manually changing a specific case selected from the list using a checkbox, etc., to confirmed, and an "optimization execution button" (an operation button related to the processing described in this embodiment) for starting a multi-layer optimization process (flow in Figure 12) targeting only the unconfirmed cases 20 in the backend. When a user switches various constraints by operating the "condition setting button," the truth value or numerical data indicating the setting status is temporarily held as "condition setting parameters" in the memory of the base terminal 200 or the session management area of ​​the dispatch planning server 100 until the optimization is executed. In this case, as a dynamic display control on the front-end side, for example, if the "prohibition of mixing large and small items" condition is enabled (turned on), the system can automatically identify items with large volume discrepancies between records in the item list display area 1710, and when the checkbox for one item is selected, the other is automatically disabled (deactivated) and highlighted in red, thus performing dynamic UI linkage control. Furthermore, when the user selects and presses the "manual confirmation button," the confirmed flag of one or more of the relevant items selected via the checkboxes in the list is dynamically rewritten (a bulk process is performed to update them all to True when multiple items are selected), and the status display section 1720 on the screen is immediately updated (re-rendered) simultaneously via asynchronous communication to a lock icon, etc.

[0166] The dispatch planning and condition setting screen 1700 according to this embodiment integrates and arranges detailed information of the target case, the "confirmed / unconfirmed protection status (status display section 1720)" described in this embodiment, and the "group of operation buttons (operation button area 1730)" for performing optimization, all within a single screen.

[0167] This screen configuration allows users to grasp the overall picture of the cases and the distribution of "unchangeable protected items (confirmed cases 10)" at a glance within the same field of view, without having to navigate between multiple screens (for example, the case details screen and the conditions setting screen). As a result, in long-distance dispatch operations involving complex constraints, the cognitive burden on users (the effort required to check information) is significantly reduced, making it much easier to decide which case to start with or whether to activate the multi-layer optimization engine 140 in the current situation.

[0168] Furthermore, multiple operation button groups (operation button area 1730) are arranged in close proximity to the target data confirmation area (case list display area 1710) on the same screen, and one of these is the "optimization execution button" according to this embodiment, which can be selected. This minimizes the user's eye movement and operation steps from reading the information on the screen to inputting execution instructions to the system. Moreover, when the "optimization execution button" is pressed, the system executes a control to temporarily disable (deactivate) the operation of the optimization execution button, and dynamically lays out and displays a progress indicator (loading spinner, progress bar, etc.) on the screen to clearly indicate that calculations are in progress. In parallel with this control, the temporarily held condition setting parameters and the data group of unconfirmed cases 20 are immediately sent to the multi-layer optimization engine 140, and after the calculation is completed, the system seamlessly transitions to the dispatch plan result screen, which will be described later in Figure 18. Thus, even though the system operates a complex dispatch algorithm in the background, its operability is further improved.

[0169] Figure 18 shows an example of the configuration of the dispatch plan result / manual repair operation screen 1800 generated by the dispatch plan server 100 according to this embodiment and displayed on the display of the base terminal 200 via the communication network 50. This dispatch plan result / manual repair operation screen 1800 graphically displays the flight assignment plan 40 (dispatch plan result) calculated by the multi-layer optimization engine 140 and functions as a human-AI collaborative user interface that allows the user (dispatcher) to intuitively intervene and confirm operations for a specific flight.

[0170] As shown in Figure 18, the dispatch plan result / manual repair operation screen 1800 is mainly composed of the "planning result display area 1810" and the "operation control area 1830" being included within the same screen.

[0171] The planning result display area 1810 is an area that visualizes the calculation results by the multi-layer optimization engine 140 (optimization engine) or the current dispatch status in chronological order. Specifically, it has a Gantt chart-style layout with each dispatch (truck slot) arranged on the vertical axis and a time axis such as the date on the horizontal axis, and an individual "dispatch timeline 1811" is drawn in each row. Inside each dispatch timeline 1811, "case assignment blocks 1812" corresponding to the volume and schedule of the moving case (designated dispatch or consolidated dispatch) assigned to that dispatch are displayed as a puzzle-like graphic packed without gaps. Specifically, through program rendering control, the width of each block is dynamically rendered in proportion to the "time occupied (or distance traveled)", and the height or a specific background color is dynamically rendered in proportion to the size of the "volume occupied (amount of household goods)", thereby visualizing the physical occupancy status of the cargo bed. In this case, when the user hovers (overlays) the mouse pointer or other object over the case assignment block 1812 or clicks it, detailed information about the case (e.g., case ID, customer name, details of the amount of household goods, conditions for the specified date or delivery period, etc.) is dynamically overlaid in the form of a tooltip or pop-up window, and information is immediately presented to the user to evaluate the suitability of each shipment in detail. Furthermore, within the timeline, the size of the aforementioned remaining capacity 804, which represents loading loss (blank space), is visually juxtaposed and indicated by a blank area shaded with a specific identification color (e.g., light gray or red to indicate unassigned space) or by a numerical indicator showing the remaining loading percentage (%).

[0172] Furthermore, a "protection state switching unit 1820" is individually provided in a proximity to each flight timeline 1811 (for example, next to the flight number display). The protection state switching unit 1820 is a toggle-type GUI switch that switches between a logical state of fixing the dispatch status of the relevant flight and excluding it from further changes, or allowing the system to reschedule, and is represented, for example, by an icon resembling a lock. If, as mentioned above, there are multiple protection levels for the confirmed flag, this icon may be configured as a visually distinguishable multi-state icon, such as a "yellow half-open lock (partial lock that only allows additional loading)" and a "red fully closed lock (full lock that prohibits any additions)."

[0173] The user evaluates the allocation results (such as loading rate and efficiency of the route) presented in the planning results display area 1810, and selects a specific flight that matches the on-site conditions, or a superior flight that the user wishes to maintain, by selecting (clicking, etc.) the protection status switching unit 1820, thereby transitioning it to manual confirmation (lock enabled state). Specifically, this selection operation triggers event-driven control, which sends an asynchronous status change request from the base terminal 200 to the dispatch planning server 100. The confirmed flag 805 in the aforementioned flight information table 800 is dynamically enabled (updated to True), and the icon of the protection status switching unit 1820 on the screen is dynamically reversed and rendered from an "unlocked state" to a "locked state" graphic. In conjunction with this, as a front-end control, all manual editing operations such as drag-and-drop on the case assignment block 1812 within the flight timeline 1811 are disabled, and the flight transitions to a state where it is strictly protected in subsequent re-optimization processes.

[0174] The operation control area 1830 has multiple operation buttons arranged together so that a user who has checked the information on the screen can immediately input the next action. In this operation control area 1830, for example, a "save plan button" for confirming and saving the current plan result, a "filter button" for changing the display conditions, and a "recalculation execution button (an operation button related to the process described in this embodiment) 1831" are arranged side by side.

[0175] When a user locks some flights using the protection state switching unit 1820 and selects the recalculation execution button 1831, a manual repair trigger is sent to the dispatch planning server 100, and a real-time recalculation (re-optimization) is started targeting only the remaining unconfirmed cases 20 while maintaining the remaining capacity 804 of the locked flights. After the recalculation is complete, the dispatch planning server 100 receives the updated assignment plan data 40, and the base terminal 200 dynamically rewrites and redraws (updates) only the placement graphics of the other flight timelines 1811 that are not locked (manually confirmed) and the "case assignment blocks 1812" related to the unconfirmed cases. During this differential update, visual animation effects such as temporary highlighting (blinking or highlighting with a specific color) are applied to blocks to which new cases have been assigned or blocks whose placement has been moved, so that the user can instantly recognize which parts of the plan have been changed by the AI ​​recalculation. Furthermore, if the remaining undecided cases become physically unallocable (no solution found in the mathematical model) due to the user excessively locking out slots, a warning message will be displayed at the top of the screen via a toast notification, and a feedback UI for exception handling will be provided to prompt the user to partially unlock (relax constraints).

[0176] The dispatch plan result / manual repair operation screen 1800 according to this embodiment adopts a configuration in which a graphical dispatch result (plan result display area 1810), an individual lock mechanism (protection state switching unit 1820), and a group of instruction buttons for the whole system (operation control area 1830) are organically integrated and arranged within a single screen.

[0177] This screen configuration allows users to visually evaluate the availability of trucks (804 remaining slots) and their allocation status over time, and simply by shifting their gaze within the same screen, they can instantly decide which flights should be locked (protected) and intuitively lock them on the spot. This eliminates the need for screen transitions in the entire thought process, from data evaluation to selecting which flights to protect, further reducing cognitive load and making complex trunk line dispatch decisions much easier.

[0178] Furthermore, within the operation control area 1830, several buttons necessary for general data management are arranged side by side, and one of these elements is the "recalculation execution button 1831" for initiating manual repair. In this way, by arranging multiple controls on the same screen that is continuous with the result display area (planning result display area 1810) and the individual operation unit (protection state switching unit 1820), users can complete a series of interactive collaborative tasks such as "viewing results," "locking a specific flight," and "instructing the remaining recalculations" with minimal pointing operations and manual steps. Therefore, despite being a complex system running advanced and heavy mathematical optimization algorithms in the background, it achieves light and easy operability (excellent accessibility) for on-site operators on the base terminal 200.

[0179] Figure 19 shows an example of the configuration of the available slot trading platform screen 1900, which is generated by the transaction management unit 132 of the dispatch planning server 100 and displayed on the display of other vendor terminals 320 (or the company's own branch terminal 200) via the communication network 50. This available slot trading platform screen 1900 functions as an integrated trading user interface for viewing, comparing, buying, selling, and exchanging "digital units (transaction tickets 420)" extracted as a result of optimization and automatic repair processing in the company's system.

[0180] As shown in Figure 19, the available slot trading platform screen 1900 is mainly composed of the "trading ticket list display area 1910" and the "operation activation area 1930" all contained within the same screen.

[0181] The transaction ticket list display area 1910 is an area that displays multiple transaction tickets 420 currently published on the platform and awaiting purchase or lending offers from other businesses in a matrix or card format. Each ticket's display row (or display card) clearly shows detailed resource attribute information for each record, such as "Transaction Ticket ID 1101", "Segment (Departure / Destination)", "Transactionable Amount / Schedule Conditions 1105", and "Consideration (Price / Points) 1107".

[0182] Furthermore, within this transaction ticket list display area 1910, an "asset attribute / status display section 1920" is provided, corresponding to each individual ticket. The asset attribute / status display section 1920 dynamically displays the asset type (available slot type / asset attribute 1104) of the available slot, whether it is "remaining capacity 804 (spatial information)," which is the physical space on the truck's cargo bed, or "flexible schedule slot (time information)," which is based on the grace period of the time window for consolidated shipments, and the current transaction phase (transaction status 1106), such as "publicly available," using identification codes and visual metaphors (for example, a "three-dimensional icon such as a cardboard box" to indicate a spatial slot, a "calendar icon" to indicate a schedule slot, or gradual coloring such as blue or yellow according to the remaining capacity). This allows other businesses viewing the listing to instantly distinguish and understand the physical and temporal nature of the available slots being offered.

[0183] The operation activation area 1930 contains multiple operation controls (groups of buttons) arranged side-by-side on the same screen, allowing viewers to immediately input the next action for the transaction ticket 420 displayed on the screen. This operation activation area 1930 includes, for example, a "show details button" for checking a specific ticket in detail, a "search filter button" for narrowing down the displayed items by a specific route or date, a "message button" for contacting the seller of the ticket in question, and a "purchase approval button (an operation button related to the process described in this embodiment) 1931," all laid out together.

[0184] When a user from another company selects a ticket from the transaction ticket list display area 1910 that matches the requirements of their own moving project (cargo), and then, using the pull-down menu or modal window displayed on the screen, specifies their own unassigned project that matches the conditions of the ticket to be traded (for example, details of a project such as "Tokyo to Osaka, 15m^3 of household goods") while previewing it, selects the purchase approval button 1931 (click or tap, etc.). This operation triggers a matching request to be sent from the other company's terminal 320 to the dispatch planning server 100 via asynchronous communication (for example, sending JSON format data via the HTTPS protocol), containing the other company's moving project data (cargo volume, desired date and time, etc.), and the automatic update and data joining control of the available slot transaction table 1100 and the flight information table 800 (flow in Figure 16) is immediately executed. Then, on the screen of the other vendor terminal 320 that has received a successful response from the data linking control, the asset attribute / status display section 1920 of the corresponding transaction ticket 420 is dynamically re-rendered (updated) from "Public" to a visual graphic meaning "Transaction Completed". On the other hand, if the dispatch planning server 100 fails to acquire the exclusive control lock due to simultaneous access conflict with other vendors (receives an error response), the other vendor terminal 320's front-end processing immediately displays an error message as a pop-up and executes an exception process that dynamically fades out and deletes the corresponding transaction ticket 420 from the transaction ticket list display area 1910.

[0185] The available slot trading platform screen 1900 according to this embodiment adopts a configuration in which a display area (trading ticket list display area 1910, asset attribute / status display area 1920) that clearly displays detailed information and characteristics of the circulating digital assets (trading tickets 420) and a group of operation buttons (operation activation area 1930, purchase / acceptance button 1931) for completing the actual trading procedure are organically integrated and arranged within a single screen.

[0186] This screen configuration allows users from other businesses who wish to purchase or use available slots to quickly compare and match the requirements of their own moving projects (amount of household goods and delivery dates) with the specific spatial and temporal attributes (1104, 1105) of available slot tickets (transaction tickets 420) supplied to the market within the same field of view. Specifically, when a user from another business enters (or selects) the volume and section of their moving project into a dedicated input form (not shown) on the screen, the front-end program, upon detecting this input event, sends an asynchronous search query to the dispatch planning server 100 in real time. Based on the returned dataset of transaction tickets 420 that meet the conditions, the system reconstructs the screen elements (DOM tree) and dynamically presents only the matching tickets in the transaction ticket list display area 1910, either by highlighting them or sorting them in order of relevance (for example, in order of smallest difference between the volume of the company's project and the remaining capacity of the ticket, resulting in the least loading loss, or in order of shortest straight-line distance between departure and arrival terminals). This completely eliminates the cumbersome screen transitions involved in repeatedly switching between screens or comparing multiple windows in the thought process of selecting the optimal available asset, dramatically reducing cognitive load. As a result, it becomes even easier to make quick and accurate resource allocation decisions between companies.

[0187] Furthermore, a group of operation buttons (operation activation area 1930) is located adjacent to the area for confirming the target ticket information (transaction ticket list display area 1910), and one of these buttons is the "purchase / transfer approval button 1931" according to this embodiment, which is selectable. By adopting this configuration, which completes the transition from information confirmation to procedure within the same control space, the user can perform a series of rights transfer and vehicle dispatch combination processes, such as "browsing the market," "selecting the desired ticket," and "approving the purchase / transfer," with minimal eye movement and pointing. In other words, the front-end operation of exploring the resource market on the Web and the back-end distributed transaction processing, such as automatic insertion into inter-vendor databases and settlement, are deterministically linked through a single button operation (1931). Therefore, while it is an advanced cross-platform system (common platform 430) involving complex database linkages between businesses, settlement systems, and automated insertion processing into dispatch assignment lists (assignment case list 803) in the background, it achieves extremely light and easy operation for the businesses using it, and exhibits excellent effects in further promoting participation in the ecosystem and revitalizing and improving the convenience of transactions.

[0188] <Variation>

[0189] (1) Information processing system that performs language processing in response to prompt input Each process in the above embodiment may be performed by an information processing system that performs language processing in response to prompt input. Alternatively, an AI agent may autonomously define tasks and perform processing in response to prompts. As an example of an information processing system that performs language processing in response to prompt input, an example was described in which a prompt is sent to a server of a large-scale language model service, which is an external information processing system, and the results generated by the server of the large-scale language model service in response to the prompt are received.

[0190] Alternatively, instead of using an external information processing system, a large-scale language model may be run on the terminal to perform processing in response to prompts. Alternatively, the large-scale language model may be run on a server that holds the information to be included in the prompts.

[0191] As described above, the information processing system that performs language processing in response to prompt input may be an external information processing system different from the service provided by the server, the server may have the functionality of the information processing system, or it may run on a terminal. The terminal may have a processor such as a GPU (Graphics Processing Unit) for running a large-scale language model, and this processor may enable the large-scale language model to perform language processing in response to prompt input. For example, the server may provide a large-scale language model to run on the terminal, and the terminal may be required to build an information processing system that performs language processing.

[0192] <Other> In the above description, "processor" refers to one or more processors. At least one processor is typically a microprocessor such as a CPU (Central Processing Unit), but may be other types of processors such as a GPU (Graphics Processing Unit). At least one processor may be single-core or multi-core.

[0193] Furthermore, at least one processor may be a broad-sense processor, such as a hardware circuit that performs some or all of the processing (e.g., an FPGA (Field-Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit)).

[0194] Furthermore, in the above explanation, the term "xxx table" is sometimes used to describe information that yields an output for a given input. This information can be data with any structure, or it can be a learning model such as a neural network that generates an output for a given input. Therefore, "xxx table" can be referred to as "xxx information."

[0195] Furthermore, the above description is merely an example of the structure of each table; one table may be divided into two or more tables, or all or part of two or more tables may constitute a single table.

[0196] Furthermore, while the above explanation sometimes uses "program" as the subject to describe the process, a program is executed by a processor and performs defined processes using the memory and / or interface as appropriate. Therefore, the subject of the process may also be the processor (or a device such as a controller that has that processor).

[0197] The program may be installed on a device such as a computer, or it may reside on a program distribution server or a computer-readable (e.g., non-temporary) recording medium. Furthermore, in the following description, two or more programs may be implemented as a single program, or one program may be implemented as two or more programs.

[0198] A network consists of various mobile communication systems, such as the internet, LANs, and wireless base stations. For example, a network includes 3G, 4G, and 5G mobile communication systems, LTE (Long Term Evolution), and wireless networks that can connect to the internet via designated access points (e.g., Wi-Fi®). When connecting wirelessly, communication protocols include, for example, Z-Wave®, ZigBee®, and Bluetooth®. When connecting via a wired connection, the network also includes connections made directly via USB (Universal Serial Bus) cables, etc.

[0199] Furthermore, by distributing all or part of each hardware configuration across multiple computers and connecting them to each other via a network, a computer can be virtually realized. Thus, the concept of a computer includes not only computers housed in a single enclosure or case, but also virtualized computer systems.

[0200] Furthermore, each of the above-mentioned configurations, functions, processing units, processing means, etc., may be implemented in hardware, either partially or entirely, by designing them as integrated circuits, for example. The present invention can also be implemented by software program code that realizes the functions of the embodiment. In this case, a storage medium on which the program code is recorded is provided to a computer, and the processor of that computer reads the program code stored in the storage medium. In this case, the program code read from the storage medium itself realizes the functions of the embodiment described above, and the program code itself and the storage medium on which it is stored constitute the present invention. Examples of storage media used to supply such program code include flexible disks, CD-ROMs, DVD-ROMs, hard disks, SSDs, optical disks, magneto-optical disks, CD-Rs, magnetic tapes, non-volatile memory cards, ROMs, and the like.

[0201] Furthermore, the program code that implements the functions described in this embodiment can be implemented in a wide range of programming or scripting languages, such as assembler, C / C++, Perl, Shell, PHP, and Java (registered trademark).

[0202] Furthermore, the program code for the software that implements the functions of the embodiment may be distributed via a network and stored in a storage means such as a computer's hard disk or memory, or in a storage medium such as a CD-RW or CD-R, and the computer's processor may read and execute the program code stored in the storage means or storage medium.

[0203] The functions realized by the components described herein may be implemented in a circuit or processing circuitry, including general-purpose processors, application-specific processors, integrated circuits, ASICs (Application Specific Integrated Circuits), CPUs (a Central Processing Unit), conventional circuits, and / or combinations thereof, programmed to realize the functions described herein. A processor is considered to be a circuit or processing circuitry, including transistors and other circuits. A processor may be a programmed processor that executes a program stored in memory.

[0204] In this specification, circuitry, unit, and means are hardware programmed to perform or execute the functions described herein. Such hardware may be any hardware disclosed herein, or any hardware known to be programmed to perform or execute the functions described herein.

[0205] If the hardware is a processor that is considered to be a type of circuitry, then the circuitry, means, or unit is a combination of hardware and software used to constitute the hardware and / or processor.

[0206] While several embodiments of this disclosure have been described above, these embodiments can be implemented in a variety of other forms, and various omissions, substitutions, and modifications are permitted without departing from the spirit of the invention. These embodiments and their variations are included in the scope and spirit of the invention, as well as in the claims and their equivalents.

[0207] In the above embodiment, each device (terminal device, server, etc.) can also be considered as an information processing device. That is, the collection of each device can be considered as a single "information processing device," and the system may be formed as a collection of multiple devices. The way in which the multiple functions required to realize the system according to this embodiment are allocated to one or more hardware can be appropriately determined in consideration of the processing capacity of each hardware and / or the specifications required for the system.

[0208] In the above embodiment, the server may distribute a program to be executed on the terminal in the service provided by the server, and the terminal may perform the processing after installing the program, or the processing may be appropriately divided between the terminal and the server. For example, each of the processes in the above embodiment can be performed on the terminal or on the server.

[0209] The embodiments described above do not unduly limit the scope of the disclosure as defined in the claims. Furthermore, not all components shown in the embodiments are essential components of the disclosure. Also, the figures are schematic and not necessarily strictly illustrative.

[0210] Furthermore, while identification numbers are used as identification information for various objects in the above explanation, other types of identification information (for example, identifiers including letters or symbols) may also be used.

[0211] Furthermore, in the above explanation, when describing similar elements without distinction, a reference code (or a common code among reference codes) may be used, and when describing similar elements with distinction, the element's identification number (or reference code) may be used.

[0212] Furthermore, in the above explanation, the control lines and information lines shown are those deemed necessary for the explanation, and do not necessarily represent all control lines and information lines in the actual product. All components may be interconnected.

[0213] (Note) The details described in each of the above embodiments are noted below.

[0214] (Note 1) A method for scheduling transportation performed by a computer equipped with a processor, the method comprising: the steps of: obtaining case information for multiple moving cases involving long-distance transport, including requirements for designated flights with fixed delivery dates or consolidated flights with flexible delivery periods; identifying the multiple moving cases into confirmed cases where transportation has already been determined and unconfirmed cases where transportation has not yet been determined; protecting confirmed flights to which confirmed cases have been assigned as exempt from changes to the transportation schedule; and outputting a new flight allocation plan that optimizes the unconfirmed cases, under conditions that satisfy the remaining capacity of the confirmed flights and the requirements for designated flights and consolidated flights, thereby minimizing the number of flights and maximizing the loading rate.

[0215] (Note 2) The step of outputting a new flight allocation plan targeting only unconfirmed cases for optimization is the method described in Appendix 1, which generates the allocation plan to further satisfy constraints related to the moving business, including size information of the amount of household goods included in the moving case, and consolidation prohibition conditions that restrict the consolidation of specific items on the same flight.

[0216] (Note 3) The step of outputting a new flight allocation plan targeting only unconfirmed cases is the method described in any of the appendices 1 to 2, which includes: generating multiple candidate patterns for one-way flights using predetermined heuristics based on information on unconfirmed cases; generating a candidate pattern for a round trip on the same day using one vehicle by combining the generated candidate patterns for one-way flights that satisfy the overlap condition of the possible arrival date for the outbound flight and the possible departure date for the return flight; and selecting the combination of patterns that minimizes the number of flights from the set of generated candidate patterns for one-way flights and candidate patterns for round trips on the same day using integer linear programming (ILP).

[0217] (Note 4) The method described in Appendix 3, wherein the step of outputting a new flight allocation plan with only undetermined cases as the target of optimization further includes the steps of iteratively executing an integration repair process that combines multiple flights into one flight, and a round-trip additional repair process that combines a reverse flight pattern with a one-way flight pattern, using the selected combination of patterns as the initial solution, and if the number of flights decreases from the initial solution due to the iterative execution, adopting the repaired combination of patterns as the new flight allocation plan.

[0218] (Note 5) The method further includes the steps of: the computer processor accepting a manual modification operation via a user interface to confirm flights for specific pending cases in the outputted new flight allocation plan; protecting the flights confirmed by the modification operation as new confirmed cases and exempting them from modification; and recalculating and outputting a flight allocation plan in real time for the remaining pending cases.

[0219] (Note 6) The method further includes the step of a computer processor obtaining resource information indicating the availability of workers at the origin and destination of multiple moving cases, and outputting an allocation plan for consolidated shipments included in unconfirmed cases, which dynamically determines the delivery date of the consolidated shipments to satisfy the condition of the availability of workers based on the resource information, in addition to the remaining capacity of confirmed shipments, according to any one of the methods described in Appendix 1 to 5.

[0220] (Note 7) The method is the method according to any one of the appendices 1 to 6, further comprising the steps of: having a computer processor calculate in the output allocation plan the remaining capacity of flights whose load factor falls below a predetermined threshold, or the available slots for periods during which consolidated flights can be accepted; defining the calculated remaining capacity or available slots as digital units that can be exchanged or traded with other operators, and outputting them as information that can be provided on a common platform.

[0221] (Note 8) A dispatch planning program executed by a computer equipped with a processor, the program causing the processor to perform the following steps: acquire case information for multiple moving cases involving long-distance transport, including requirements for designated flights with fixed delivery dates or consolidated flights with flexible delivery periods; identify the multiple moving cases into confirmed cases where dispatch has already been determined and unconfirmed cases where dispatch has not yet been determined; protect confirmed flights to which confirmed cases have been assigned as exempt from changes to the dispatch plan; and output a new flight allocation plan that optimizes unconfirmed cases, under conditions that satisfy the remaining capacity of confirmed flights and the requirements for designated flights and consolidated flights, thereby minimizing the number of flights and maximizing the loading rate.

[0222] (Note 9) Information processing device for dispatch planning, comprising a control unit, the information processing device comprising: the steps of: acquiring case information for multiple moving cases involving long-distance transport, including requirements for designated flights with fixed delivery dates or consolidated flights with flexible delivery periods; identifying the multiple moving cases into confirmed cases where dispatch has already been determined and unconfirmed cases where dispatch has not yet been determined; protecting confirmed flights to which confirmed cases have been assigned as exempt from changes to the dispatch plan; and outputting a new flight allocation plan that optimizes unconfirmed cases, under conditions that satisfy the remaining capacity of confirmed flights and the requirements for designated flights and consolidated flights, thereby minimizing the number of flights and maximizing the loading rate.

Claims

1. A method for scheduling a vehicle, which is performed by a computer equipped with a processor, wherein the computer's processor is For multiple moving cases involving long-distance transport, the process involves obtaining case information that includes requirements for either a fixed delivery date or a consolidated delivery period with a flexible delivery timeframe, and The steps include identifying the aforementioned multiple moving cases into confirmed cases where vehicle assignments have already been finalized and unconfirmed cases where vehicle assignments have not yet been finalized, The steps include protecting the confirmed flights to which the aforementioned confirmed cases have been assigned from being subject to changes in the vehicle dispatch schedule, A method comprising the steps of: outputting a new flight allocation plan that minimizes the number of flights and maximizes the loading rate, with the undecided cases as the target for optimization, under the conditions that the remaining capacity of the confirmed flights and the requirements of the designated flights and the consolidated flights are met.

2. The method according to claim 1, wherein the step of outputting a new flight allocation plan with only the aforementioned undetermined cases as the target for optimization further satisfies constraints relating to the moving business, including size information of the amount of household goods included in the moving case, and a consolidation prohibition condition that restricts the consolidation of specific items on the same flight.

3. The step of outputting a new flight allocation plan, with only the aforementioned undecided cases as the target for optimization, Based on the information of the aforementioned unconfirmed cases, the steps include generating multiple candidate patterns for one-way operations using predetermined heuristics, The steps include: generating candidate patterns for a round trip on the same day using one vehicle by combining those that satisfy the overlapping conditions of the possible arrival date for the outbound trip and the possible departure date for the return trip from the generated candidate patterns for one-way trips; The method according to claim 1, comprising the step of selecting a combination of patterns that minimizes the number of flights from the generated set of candidate patterns for one-way flights and candidate patterns for round trips on the same day, using integer linear programming (ILP).

4. The step of outputting a new flight allocation plan, with only the aforementioned undecided cases as the target for optimization, The process involves repeatedly performing an integration repair process that combines multiple flights into one flight, and a round-trip additional repair process that combines a flight pattern in the reverse direction with a one-way flight pattern, using the selected combination of patterns as the initial solution. The method according to claim 3, further comprising the step of adopting the combination of the repaired patterns as the new flight allocation plan if the number of flights decreases from the initial solution as a result of the repeated execution.

5. The method further includes the step of the computer's processor accepting a manual modification operation via a user interface to confirm a flight for a specific pending case with respect to the outputted new flight allocation plan, The method according to claim 1, further comprising the steps of: protecting the flights confirmed by the modification operation as new confirmed cases and exempting them from modification; and recalculating and outputting the flight allocation plan in real time for the remaining unconfirmed cases.

6. The method further includes the step of the computer's processor obtaining resource information indicating the available slots for workers at the source and destination of the multiple moving cases, The method according to claim 1, wherein the step of outputting the allocation plan for the consolidated shipment included in the pending cases dynamically determines the delivery date of the consolidated shipment so as to satisfy the condition of the remaining capacity of the confirmed operating flights as well as the availability of available slots for workers based on the resource information.

7. The method further includes the step of the computer processor calculating, in the outputted allocation plan, the remaining capacity of flights whose loading rate falls below a predetermined threshold, or the available slots for the period during which the consolidated flights can be accepted. The method according to claim 1, further comprising the steps of defining the calculated remaining capacity or available slot as a digital unit that can be exchanged or traded with other businesses, and outputting it as information that can be provided on a common platform.

8. A dispatch planning program executed by a computer equipped with a processor, wherein the program is performed by the processor, For multiple moving cases involving long-distance transport, the process involves obtaining case information that includes requirements for either a fixed delivery date or a consolidated delivery period with a flexible delivery timeframe, and The steps include identifying the aforementioned multiple moving cases into confirmed cases where vehicle assignments have already been finalized and unconfirmed cases where vehicle assignments have not yet been finalized, The steps include protecting the confirmed flights to which the aforementioned confirmed cases have been assigned from being subject to changes in the vehicle dispatch schedule, A program that performs the steps of: outputting a new flight allocation plan that minimizes the number of flights and maximizes the loading rate, with the undecided cases as the target for optimization, under the conditions that satisfy the remaining capacity of the confirmed flights and the requirements of the designated flights and the consolidated flights.

9. A vehicle dispatch planning information processing device comprising a control unit, wherein the control unit is For multiple moving cases involving long-distance transport, the process involves obtaining case information that includes requirements for either a fixed delivery date or a consolidated delivery period with a flexible delivery timeframe, and The steps include identifying the aforementioned multiple moving cases into confirmed cases where vehicle assignments have already been finalized and unconfirmed cases where vehicle assignments have not yet been finalized, The steps include protecting the confirmed flights to which the aforementioned confirmed cases have been assigned from being subject to changes in the vehicle dispatch schedule, An information processing device comprising the steps of: outputting a new flight allocation plan that minimizes the number of flights and maximizes the loading rate, with the undecided cases as the target for optimization, under the conditions that satisfy the remaining capacity of the confirmed flights and the requirements of the designated flights and the consolidated flights.

Images