Information processing method, information processing device, and information processing program

Abstract

Provided is an information processing method for a transport plan creation server, comprising: acquiring a transport request including customer identification information, a riding date and time, a riding position, and a get-off position from respective terminals of a plurality of customers who want to transport a vehicle; on the basis of a plurality of transport requests, a temporary transport plan for allocating a plurality of customers to a plurality of vehicles so as to satisfy a predetermined restriction condition is periodically created. And outputs travel notification information for notifying the travel from riding to getting off to the customer allocated to the temporary transport plan to the terminal of the customer allocated to the temporary transport plan.

Description

Technical Field

[0001] This disclosure relates to techniques for creating a transportation plan for transporting multiple customers using multiple vehicles. Background Technology

[0002] In the past, on-demand bus transportation was known. On-demand buses receive transportation requests from multiple customers in real time, including the origin, destination, and departure date and time, and operate while simultaneously adjusting the plan to meet multiple transportation requests and allow multiple customers to board and alight.

[0003] The term "real-time" as used above means that a delivery request is generated during vehicle operation; and if a delivery request is received from a new customer, a definite route containing the fulfillment of that delivery request is returned as a response within that point in time or within a given short fixed time (e.g., 5 minutes). This is known as the Real-time Dial-a-Ride Problem.

[0004] On-demand buses are a transportation service positioned between scheduled buses and taxis. While operating on demand like taxis, allowing customers to specify origin, destination, and departure date and time, on-demand buses also allow multiple customers to share a vehicle, similar to scheduled buses. Fares are set at a level comparable to scheduled buses, or in a price range between scheduled buses and taxis.

[0005] In other words, on-demand bus services are characterized by operation on demand, vehicle sharing, and low fares. Delivery efficiency is improved by operating in response to delivery requests. Delivery efficiency is further improved by multiple customers sharing vehicles. Customer rebates, resulting from improved delivery efficiency, help keep fares low.

[0006] To expand the applicability of on-demand buses, a mechanism is needed for vehicle sharing services that ensure profitability even when transport demand density is low.

[0007] In carpooling services, which are different from on-demand bus services, mechanisms for improving vehicle sharing have been proposed in the past (e.g., see Patent Documents 1 and 2).

[0008] In addition, carpooling services are services that match drivers who provide vehicles with passengers who wish to share a ride.

[0009] However, in the existing technologies described above, carpooling services are envisioned as the application target, thus the execution of transportation is determined, and methods to improve vehicle sharing are proposed. Therefore, methods to ensure the profitability of transportation have not been considered in the past and require further improvement.

[0010] Prior art literature

[0011] Patent documents

[0012] Patent Document 1: JP 2020-13345

[0013] Patent Document 2: JP 2021-89478 Summary of the Invention

[0014] This disclosure is made to solve the above-mentioned problems and aims to provide a technology that can create a transportation plan that ensures the profitability of transportation.

[0015] The information processing method disclosed herein is an information processing method in a computer for creating a transportation plan for transporting multiple customers by multiple vehicles. It obtains transportation requests containing customer identification information, boarding date and time, boarding location, and alighting location from the terminals of the multiple customers who wish to be transported by the vehicles. Based on the multiple transportation requests, it periodically creates temporary transportation plans to allocate the multiple customers to the multiple vehicles to satisfy given constraints. On a first determined date and time for determining the temporary transportation plan, it outputs trip notification information to the terminals of the customers allocated to the temporary transportation plan, informing them of their journey from boarding to alighting.

[0016] According to this disclosure, a transportation plan that ensures the profitability of transportation can be created. Attached Figure Description

[0017] Figure 1 This is a diagram showing the overall structure of the vehicle dispatch management system in Embodiment 1 of this disclosure.

[0018] Figure 2 This is a diagram illustrating an example of bus stop timetable data in Embodiment 1.

[0019] Figure 3 This is a diagram showing an example of the bus stop distance table data in Embodiment 1.

[0020] Figure 4 This is a diagram illustrating an example of vehicle definition data in Embodiment 1.

[0021] Figure 5 This is a diagram illustrating an example of passenger capacity constraint data in Embodiment 1.

[0022] Figure 6 This is a diagram illustrating an example of the detour constraint data in Embodiment 1.

[0023] Figure 7This is a schematic diagram illustrating the actions from receiving the transport request data from the transport plan creation server to sending the trip notification information in Embodiment 1.

[0024] Figure 8 This is a flowchart illustrating the operation of the shipping request receiving unit of the shipping plan creation server in Embodiment 1 of this disclosure.

[0025] Figure 9 This is a first flowchart illustrating the operation of the shipping plan creation unit of the shipping plan creation server in Embodiment 1 of this disclosure.

[0026] Figure 10 This is a second flowchart illustrating the operation of the shipping plan creation unit of the shipping plan creation server in Embodiment 1 of this disclosure.

[0027] Figure 11 This is a third flowchart illustrating the operation of the shipping plan creation unit of the shipping plan creation server in Embodiment 1 of this disclosure.

[0028] Figure 12 This is a fourth flowchart illustrating the operation of the shipping plan creation unit of the shipping plan creation server in Embodiment 1 of this disclosure.

[0029] Figure 13 This is a schematic diagram illustrating the process of creating an initial solution for a temporary transportation plan by the initial solution creation unit in Embodiment 1 of this invention.

[0030] Figure 14 This is a schematic diagram illustrating the process of creating a temporary transportation plan by the improved solution-making unit in Embodiment 1.

[0031] Figure 15 This is a flowchart illustrating the evaluation process of the delivery plan creation server in Embodiment 1.

[0032] Figure 16 This is a flowchart illustrating the operation of the sending unit of the delivery plan creation server in Embodiment 1 of this disclosure.

[0033] Figure 17 This is a diagram illustrating an example of a delivery request input screen displayed on a customer terminal in Embodiment 1.

[0034] Figure 18 This diagram illustrates an example of an adoption notification screen displayed on a customer terminal in Embodiment 1.

[0035] Figure 19 This diagram illustrates an example of a notification screen not displayed on the customer's terminal in Embodiment 1.

[0036] Figure 20 This diagram illustrates an example of a trip notification screen displayed on a customer's terminal in Embodiment 1.

[0037] Figure 21 This diagram illustrates an example of the first message screen displayed on the customer terminal in Embodiment 1.

[0038] Figure 22 This diagram illustrates an example of the second message screen displayed on the customer terminal in Embodiment 1.

[0039] Figure 23 This is a diagram showing the overall structure of the vehicle dispatch management system in Embodiment 2 of this disclosure.

[0040] Figure 24 This is a diagram illustrating an example of the definition data for multiple sub-regions in Embodiment 2.

[0041] Figure 25 This is a flowchart illustrating the operation of the shipping request receiving unit of the shipping plan creation server in Embodiment 2 of this disclosure. Detailed Implementation

[0042] (The insights that form the basis of this disclosure)

[0043] On-demand bus services have structural problems. Typically, on-demand buses are studied and implemented in areas with low transport demand density. This is because, in areas with high transport demand density, dedicated bus services are more efficient than on-demand services.

[0044] On the other hand, if the density of transport requests is too low, vehicle sharing will no longer be viable. In this case, even if the service operates in a manner essentially the same as a taxi, it would operate with larger vehicles at lower fares than taxis. This could lead to a lack of profitability and make continued operation difficult.

[0045] In summary, on-demand bus services are only viable if on-demand operation, vehicle sharing, and low fares are all effectively implemented. However, from the perspective of on-demand operation, areas with low density of transport requests are suitable, while from the perspective of vehicle sharing, areas with high density of transport requests are suitable. Therefore, on-demand buses are suitable for areas with moderate density of transport requests, but such areas are limited.

[0046] Existing technologies envision ride-sharing services as their application target; therefore, the execution of transportation for customers accepting transport requests is determined, and methods to improve vehicle sharing are proposed. Consequently, methods to ensure the profitability of transportation have not been considered in the past. In particular, existing technologies create transport plans that cover all received transport requests, whereas this technology determines the transport plan once all transport requests have been received.

[0047] To address the above issues, the following technology has been disclosed.

[0048] (1) An information processing method in one aspect of the present disclosure involves an information processing method in a computer for making a transportation plan for transporting multiple customers by multiple vehicles, obtaining transportation requests containing customer identification information, boarding date and time, boarding location and alighting location from the terminals of the multiple customers who wish to be transported by vehicles, periodically making temporary transportation plans to allocate the multiple customers to the multiple vehicles to satisfy given constraints based on the multiple transportation requests, and outputting trip notification information to the terminals of the customers allocated to the temporary transportation plan on a first determined date and time for determining the temporary transportation plan to notify the customers allocated to the temporary transportation plan of the trip from boarding to alighting.

[0049] According to this structure, temporary transport plans are periodically created based on multiple transport requests, assigning multiple customers to multiple vehicles to meet given constraints, until a first determined date and time is reached to finalize the temporary transport plan. Therefore, even in areas with low transport demand, transport requests from more customers can be obtained, and more customers can be assigned to multiple vehicles, thus enabling the creation of transport plans that ensure profitability.

[0050] (2) In the information processing method described in (1) above, it is also possible to further output a non-application notification message to the terminal of the customer who has not been assigned to the temporary delivery plan at the second determined date and time for determining the situation that delivery is not possible.

[0051] This structure allows customers to be notified in advance of any inability to ship the goods.

[0052] (3) In the information processing method described in (1) above, the given constraint condition may be that the number of passengers in each of the multiple vehicles is above the lower limit value.

[0053] According to this structure, by making temporary transportation plans so that the number of passengers in each of the multiple vehicles is above the minimum value, the profitability of transportation can be more reliably ensured.

[0054] (4) In the information processing method described in (3) above, the lower limit value may also increase as the transportation distance or transportation time increases.

[0055] According to this structure, since temporary transportation plans are made so that the number of passengers in each of the multiple vehicles increases as the transportation distance or time increases, the profitability of transportation can be ensured even if the transportation distance or time increases, provided that the transportation cost of the vehicles is fixed.

[0056] (5) In the information processing method described in (3) above, the lower limit value may be a fixed number of people, and the transportation cost of the vehicle may increase as the transportation distance or transportation time increases.

[0057] According to this structure, since the transportation cost of the vehicle increases with the length of the transportation distance or time, the profitability of transportation can be ensured even when the number of passengers is small, even if the transportation distance or time is longer.

[0058] (6) In any of the information processing methods described in (1) to (5) above, the given constraint may include: the ratio of the total time of individual transportation of multiple customers assigned to one of the multiple vehicles to the overall transportation time from the initial boarding to the final disembarking of the multiple customers assigned to the one vehicle to a threshold value or less.

[0059] According to this structure, since a temporary transportation plan is made so that the total time of individual transportation of multiple customers assigned to one of the multiple vehicles is less than a threshold ratio from the initial boarding to the final disembarking of the multiple customers assigned to one vehicle, the efficiency and profitability of transportation can be ensured.

[0060] (7) In any of the information processing methods described in (1) to (6) above, it is also possible to further output adoption notification information to the terminals of multiple customers assigned to the temporary transportation plan to notify them that transportation is possible when the temporary transportation plan is made.

[0061] This structure allows customers to be notified in advance that delivery is possible.

[0062] (8) In the information processing method described in (7) above, it is also possible to further output a first standby notification message for notifying the situation of standby time from the time the delivery request is obtained until the adoption notification message is output.

[0063] According to this structure, during the period from obtaining the delivery request to outputting the adoption notification information, a first standby notification message is output to notify the situation of the standby time from the generation of the standby time to the decision on whether delivery can be made.

[0064] Therefore, there is a standby time period during which a customer can be notified from the time the delivery request is sent until the adoption notification information is received.

[0065] (9) In the information processing method described in (7) or (8) above, it is also possible to further output a second standby notification message for notifying the situation of standby time from the generation of the standby notification message to the generation of the trip notification message during the period from the generation of the adoption notification message to the generation of the trip notification message.

[0066] According to this structure, there is a standby time for customer notifications during the period from receiving the adoption notification information to receiving the trip notification information.

[0067] (10) In the information processing method described in (2) above, it is also possible to further output a first standby notification message for notifying the situation of standby time from the time the delivery request is obtained until the time the notification message is not adopted is output during the period from the time the delivery request is obtained until the time ...

[0068] According to this structure, during the period from the receipt of the delivery request to the output of the notification information not adopted, a first standby notification message is output to notify the situation of the standby time from the generation of the standby time to the decision on whether delivery can be made.

[0069] Therefore, there is a standby time period for notifying customers from the time the delivery request is sent until the notification message is received that the notification is not used.

[0070] (11) In any of the information processing methods described in (1) to (10) above, the area where the multiple vehicles transport goods may be divided into at least one sub-area, and the at least one sub-area may be classified into a first sub-area with a transport request generation density higher than a threshold and a second sub-area with a transport request generation density lower than the threshold. Further, if either or both of the boarding location and the alighting location contained in one of the multiple transport requests are within the first sub-area, a transport plan is immediately made based on the one transport request to assign the customer of the one transport request to one vehicle. Further, the trip notification information is output to the terminal of the customer assigned to the made transport plan. In the making of the temporary transport plan, if either or both of the boarding location and the alighting location contained in the one transport request are within the second sub-area, a temporary transport plan is made based on the one transport request to assign the customer of the one transport request to the multiple vehicles so as to satisfy the given constraints.

[0071] In the first sub-region where the density of delivery requests exceeds a threshold, the number of customers wishing to be transported is greater than in the second sub-region where the density of delivery requests is below a threshold. Therefore, if either or both of the boarding and alighting locations included in a single delivery request fall within the first sub-region with high demand, a delivery plan that immediately assigns a customer with a single delivery request to one vehicle can be created, ensuring profitability. Conversely, if either or both of the boarding and alighting locations included in a single delivery request fall within the second sub-region with low demand, by spending some time acquiring delivery requests from more customers, more customers can be assigned to multiple vehicles, thereby ensuring profitability.

[0072] (12) In the information processing method described in (11) above, the number of sub-regions and their size may vary depending on the time period.

[0073] Based on this structure, a density of delivery requests that varies according to time periods can be generated to create a delivery plan that more reliably ensures the profitability of delivery.

[0074] Furthermore, this disclosure can not only realize an information processing method that performs the characteristic processes described above, but also an information processing apparatus having a characteristic structure corresponding to the characteristic processes performed by the information processing method. Furthermore, it can also realize a computer program that enables a computer to execute the characteristic processes contained in such an information processing method. Therefore, in the following other embodiments, the same effect as the information processing method described above can also be achieved.

[0075] (13) The information processing apparatus involved in other aspects of this disclosure is an information processing apparatus for creating a transportation plan for transporting multiple customers by multiple vehicles, comprising: an acquisition unit that acquires transportation requests including customer identification information, boarding date and time, boarding location and alighting location from the terminals of the multiple customers who wish to be transported by the vehicles; a creation unit that periodically creates temporary transportation plans based on the multiple transportation requests to allocate the multiple customers to the multiple vehicles so as to satisfy given constraints; and an output unit that outputs trip notification information to the terminals of the customers allocated to the temporary transportation plan on a first determined date and time for determining the temporary transportation plan, for notifying the customers allocated to the temporary transportation plan of the trip from boarding to alighting.

[0076] (14) The information processing program involved in other aspects of this disclosure is an information processing program for making a transportation plan for transporting multiple customers by multiple vehicles, which enables the computer to function as follows: obtaining transportation requests from the terminals of the multiple customers who wish to be transported by the vehicles, including customer identification information, boarding date and time, boarding location and alighting location; periodically making temporary transportation plans based on the multiple transportation requests to allocate the multiple customers to the multiple vehicles so as to satisfy given constraints; and outputting trip notification information to the terminals of the customers allocated to the temporary transportation plan on a first determined date and time for determining the temporary transportation plan, to notify the customers allocated to the temporary transportation plan of the trip from boarding to alighting.

[0077] (15) Other embodiments of this disclosure involve a non-transitory computer-readable recording medium recording an information processing program, the information processing program being an information processing program for creating a transportation plan for transporting multiple customers by multiple vehicles, causing a computer to function as follows: obtaining from the terminals of the multiple customers who wish to be transported by the vehicles a transportation request containing customer identification information, boarding date and time, boarding location and alighting location; periodically creating temporary transportation plans based on the multiple transportation requests to allocate the multiple customers to the multiple vehicles such that given constraints are met; and, on a first determined date and time for determining the temporary transportation plan, outputting trip notification information to the terminals of the customers allocated to the temporary transportation plan to notify the customers allocated to the temporary transportation plan of their journey from boarding to alighting.

[0078] Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. Furthermore, the embodiments described below represent specific examples of the present disclosure. The numerical values, shapes, constituent elements, steps, and order of steps shown in the following embodiments are examples and do not limit the scope of the present disclosure. Additionally, any constituent element in the following embodiments that is not described in the independent claim representing the highest-level concept is described as an arbitrary constituent element. Moreover, the contents of all embodiments can be combined.

[0079] (Implementation Method 1)

[0080] Figure 1 This is a diagram showing the overall structure of the vehicle dispatch management system in Embodiment 1 of this disclosure.

[0081] Figure 1 The vehicle dispatch management system shown has a transport plan creation server 1 and multiple customer terminals 2.

[0082] Customer terminal 2, such as a smartphone, tablet, or personal computer, is held by a customer who wishes to be transported by vehicle. The vehicle, for example, is a bus transporting multiple people. Customer terminal 2 accepts input from the customer regarding their boarding location, alighting location, and boarding date and time, and sends transport request data, including the customer ID, boarding location, alighting location, and boarding date and time, to transport plan creation server 1. The customer ID is customer identification information used to identify the customer and is pre-stored in the memory of customer terminal 2. Multiple customer terminals 2 have the same basic structure.

[0083] In this embodiment 1, the vehicle's route and parking locations (bus stops) are predetermined. Customers select their boarding and alighting positions from a list of pre-set parking locations along the route. Furthermore, customers input the date and time of their boarding and alighting.

[0084] Furthermore, in this embodiment 1, the boarding and alighting locations are predetermined parking areas (bus stops), but this disclosure is not particularly limited to this; the boarding and alighting locations can be any locations specified by the customer. In this case, the customer can also input the boarding and alighting locations on the map displayed on the customer terminal 2, or input the name of their residence or facility as the boarding and alighting locations on the customer terminal 2.

[0085] In addition, customer terminal 2 can also receive adoption notification information from the shipping plan creation server 1 to notify that shipping is possible, and display the received adoption notification information. Furthermore, customer terminal 2 can also receive a first standby notification information from the shipping plan creation server 1 during the period from obtaining the shipping request data to receiving the adoption notification information, indicating the standby time from the generation of the request to the decision on whether shipping is possible, and display the received first standby notification information.

[0086] In addition, customer terminal 2 can also receive trip notification information from the transportation planning server 1 to inform customers of their journey from boarding to disembarking, and display the received trip notification information. Furthermore, customer terminal 2 can also receive a second standby notification from the transportation planning server 1 during the period from receiving the adoption notification information to receiving the trip notification information, to inform customers of the standby time from the time the trip is generated until it is decided, and display the received second standby notification information. Additionally, customer terminal 2 can also receive a non-adoption notification from the transportation planning server 1 to inform customers of situations where transportation is not possible, and display the received non-adoption notification information.

[0087] The transportation plan creation server 1 creates transportation plans for multiple customers to be transported by multiple vehicles. The transportation plan creation server 1 is connected to multiple customer terminals 2 via a network, such as the Internet.

[0088] The delivery plan creation server 1 includes a setting data storage unit 11, a temporary delivery plan storage unit 12, an unassigned delivery request storage unit 13, a delivery request receiving unit 14, a delivery plan creation unit 15, and a sending unit 16.

[0089] The delivery planning unit 15 is implemented by a processor. The processor may be, for example, a central processing unit (CPU).

[0090] The data storage unit 11, the temporary delivery plan storage unit 12, and the unassigned delivery request storage unit 13 are implemented using a memory. The memory is, for example, composed of ROM (Read Only Memory) or EEPROM (Electrically Erasable Programmable Read Only Memory).

[0091] The delivery request receiving unit 14 and the sending unit 16 are implemented through a communication module.

[0092] The data storage unit 11 pre-stores bus stop timetable data, bus stop distance table data, vehicle definition data, passenger capacity restriction data, and detour restriction data.

[0093] Figure 2 This is a diagram illustrating an example of bus stop timetable data in Embodiment 1.

[0094] Bus timetable data represents the time spent traveling between bus stops. In the bus timetable data, the vertical axis represents the bus stops s1, s2, s3, and s4 at the source of travel, and the horizontal axis represents the bus stops s1, s2, s3, and s4 at the destination of travel. The unit is, for example, minutes. Bus timetable data cannot be a symmetric matrix due to the existence of one-way traffic or differences in traffic volume. In this embodiment 1, the bus timetable data uses fixed values ​​regardless of time period or season, but different values ​​can also be used for each time period or each season.

[0095] Figure 3 This is a diagram showing an example of the bus stop distance table data in Embodiment 1.

[0096] The bus stop distance table data represents the distance of the travel path between bus stops. In the bus stop distance table data, the vertical axis represents the bus stops s1, s2, s3, and s4 of the travel source, and the horizontal axis represents the bus stops s1, s2, s3, and s4 of the travel destination. The unit is, for example, kilometers. Due to the existence of one-way traffic, the bus stop distance table data cannot be a symmetric matrix. In this embodiment 1, the bus stop distance table data uses fixed values ​​regardless of time period or season, but different values ​​can also be used for each time period or each season.

[0097] Figure 4 This is a diagram illustrating an example of vehicle definition data in Embodiment 1.

[0098] Vehicle definition data refers to multiple vehicle IDs used to identify multiple vehicles, and the passenger capacity of each vehicle. For example... Figure 4As shown, in this embodiment 1, the vehicle definition data includes the vehicle IDs of three vehicles: vehicle v1, vehicle v2, and vehicle v3. Furthermore, the vehicle definition data indicates that vehicle v1 has a capacity of 8 people, vehicle v2 has a capacity of 6 people, and vehicle v3 has a capacity of 8 people.

[0099] Figure 5 This is a diagram illustrating an example of passenger capacity constraint data in Embodiment 1.

[0100] The passenger capacity constraint data represents the lower limit of the number of passengers for a standalone transport plan. This constraint is used to ensure the profitability of the transport. In this embodiment 1, the lower limit varies depending on the total transport distance of the standalone transport plan, increasing as the total transport distance increases. For example, if the total transport distance is less than 2km, the lower limit is 2 people; if the total transport distance is 2km or more but less than 4km, the lower limit is 3 people; if the total transport distance is 4km or more but less than 6km, the lower limit is 4 people; if the total transport distance is 6km or more but less than 8km, the lower limit is 5 people; and if the total transport distance is 8km or more, the lower limit is 6 people. Furthermore, the lower limit may also vary depending on the total transport time of the standalone transport plan, increasing as the total transport time increases. For example, the lower limit during off-peak hours may be a value with a relaxed passenger capacity constraint.

[0101] Additionally, an individual transport plan represents the time sequence of ride-hailing and alighting actions for multiple customers assigned to a single vehicle. An individual transport plan includes the scheduled ride-hailing date and time and the scheduled alighting date and time for each customer. Furthermore, a transport plan represents a collection of individual transport plans.

[0102] Figure 6 This is a diagram illustrating an example of the detour constraint data in Embodiment 1.

[0103] The detour constraint data represents a threshold value for the detour associated with an individual delivery plan. In this embodiment 1, the detour is an indicator used to ensure delivery efficiency and to prevent customers going in different directions from being assigned to the same delivery plan. Furthermore, the threshold can vary depending on the time period. For example, the threshold during off-peak hours can be a value that relaxes the detour constraint.

[0104] The delivery request receiving unit 14 obtains delivery request data, including customer ID, boarding date and time, boarding location, and alighting location, from the respective customer terminals 2 of multiple customers who wish to be transported by the vehicle. The delivery request receiving unit 14 receives the delivery request data sent by the customer terminals 2. The delivery request receiving unit 14 stores the received delivery request data in the unallocated delivery request storage unit 13.

[0105] The Unassigned Delivery Request Storage Unit 13 stores delivery request data from customers that have not been assigned to temporary delivery plans.

[0106] The transport planning unit 15 periodically generates temporary transport plans based on multiple transport request data, assigning multiple customers to multiple vehicles to meet given constraints. The transport planning unit 15 stores the generated temporary transport plans in the temporary transport plan storage unit 12. The transport planning unit 15 periodically repeats the generation of temporary transport plans until a first determined date and time is reached for determining the temporary transport plan. The first determined date and time is the date and time preceding the first time from the initial passenger's travel date and time assigned to the temporary transport plan. The first time is, for example, 12 hours. The transport planning unit 15 periodically generates temporary transport plans based on transport request data stored in the unassigned transport request storage unit 13 and temporary transport plans stored in the temporary transport plan storage unit 12, to meet given constraints until the first determined date and time is reached.

[0107] The given constraints include a first constraint that the number of passengers in each of the multiple vehicles is above a lower limit. The lower limit increases as the transport distance or transport time increases. The lower limit is predetermined in the passenger capacity constraint data stored in the setting data storage unit 11.

[0108] In this embodiment 1, the lower limit for the number of participants in the transportation plan is set according to the distance because the transportation service uses a fixed freight rate. This is because the operating loss of a vehicle with a fixed freight rate operating with a small number of passengers increases with the distance. Alternatively, the lower limit could be a fixed number of participants, with the vehicle's transportation fee increasing as the transportation distance or time increases. Furthermore, the lower limit could also be set according to the transportation time, rather than the transportation distance.

[0109] Furthermore, the given constraint includes a second constraint: the ratio of the total individual transport time of multiple customers assigned to one of the multiple vehicles to the overall transport time from the initial boarding to the final disembarking of the multiple customers assigned to one vehicle is below a threshold. This threshold is predetermined in the detour constraint data stored in the setting data storage unit 11.

[0110] The transportation planning unit 15 calculates the ratio of the total individual transportation time for transporting multiple customers individually to one of the multiple vehicles included in the transportation plan to the overall transportation time from the initial boarding to the final disembarking of the multiple customers assigned to one vehicle, as the detour distance. The detour distance is a value obtained by dividing the overall transportation time from the initial boarding to the final disembarking of the multiple customers individually to the total individual transportation time for transporting multiple customers individually to one vehicle included in the transportation plan.

[0111] The detour in this embodiment 1 is characterized by the following formula (1).

[0112] Detour(tour)=TT(tour) / Σpax∈tour TP(pax)···(1)

[0113] In addition, in the above equation (1), Detour(tour) represents the detour distance, TT(tour) represents the total delivery time of the delivery plan tour, and TP(pax) represents the individual delivery time of the case where a customer pax is delivered alone.

[0114] Detour rate is an indicator of the efficiency of a delivery plan. The higher the detour rate, the worse the delivery efficiency. For example, if the threshold is set to 0.7, then the total delivery time of the delivery plan is within a permissible range up to 0.7 times the total delivery time for each individual customer. Furthermore, while ratio is used in the second constraint mentioned above, difference can also be used. Additionally, delivery distance can be used instead of delivery time.

[0115] In addition, in this embodiment 1, the transport planning unit 15 periodically generates temporary transport plans to satisfy both the first constraint condition and the second constraint condition. However, this disclosure is not particularly limited to this. Temporary transport plans may also be generated periodically to satisfy only the first constraint condition, or temporary transport plans may be generated periodically to satisfy only the second constraint condition.

[0116] Temporary transport plan storage unit 12 stores temporary transport plans created by transport plan creation unit 15.

[0117] The transportation planning unit 15 includes an initial solution creation unit 151, an improved solution creation unit 152, and an evaluation unit 153.

[0118] The initial solution generation unit 151 assigns multiple customers to the top-ranked vehicle in the vehicle definition data until the vehicle is full. If the top-ranked vehicle is full, the initial solution generation unit 151 assigns the remaining customers to the next-ranked vehicle in the vehicle definition data. The initial solution generation unit 151 generates a temporary transportation plan that allows customers assigned to each vehicle to board and disembark in the assigned order, which serves as the initial solution.

[0119] Specifically, the initial solution generation unit 151 acquires the transport request data set stored in the unallocated transport request storage unit 13, the temporary transport plan stored in the temporary transport plan storage unit 12, and the vehicle definition data stored in the setting data storage unit 11. The initial solution generation unit 151 generates an initial solution for the temporary transport plan based on the acquired transport request data set, temporary transport plan, and vehicle definition data.

[0120] The solution generation section 152 improves the initial solution of the temporary transportation plan by using steps derived from the Ruin and Recreate method, which is a quasi-optimization algorithm for delivery planning. The Ruin and Recreate method is disclosed, for example, in prior art (Gerhard Schrimpf, Johannes Schneider, Hermann Stamm-Wilbrandt and Gunter Dueck, “Record Breaking Optimization Results Using the Ruin and Recreate Principle”, Journal of Computational Physics 159, 2000, 139-171).

[0121] If the improved set of effective customers becomes a superset of the original set of effective customers, the solution improvement unit 152 updates the solution. Furthermore, the set of effective customers refers to the set of customers included in individual transportation plans within the temporary transportation plan that satisfy both the first and second constraints. The solution improvement unit 152 extracts individual transportation plans that satisfy both the first and second constraints from the solution and adds vehicles to continuously improve the solution.

[0122] Specifically, the improved solution generation unit 152 obtains the initial solution of the temporary transportation plan generated by the initial solution generation unit 151. The improved solution generation unit 152 outputs the obtained initial solution of the temporary transportation plan to the evaluation unit 153, and obtains the evaluation value of the initial solution from the evaluation unit 153.

[0123] The solution improvement generation unit 152 stores the initial solution and its evaluation value of the acquired temporary transportation plan as the current solution and its evaluation value of the temporary transportation plan in memory. The solution improvement generation unit 152 also generates a hypothetical solution for the temporary transportation plan, which replicates the current solution and its evaluation value, along with its evaluation value. Furthermore, the solution improvement generation unit 152 extracts the boarding and alighting behaviors of a given number of customer groups from the hypothetical solution of the temporary transportation plan, and generates a candidate hypothetical solution group by inserting the extracted pairings of boarding and alighting behaviors into multiple parts of the hypothetical solution.

[0124] The solution improvement generation unit 152 outputs a group of candidate hypothetical solutions to the evaluation unit 153, and obtains the evaluation values ​​of each candidate hypothetical solution from the evaluation unit 153. The solution improvement generation unit 152 stores the candidate hypothetical solution with the smallest evaluation value and its evaluation value as the hypothetical solution and evaluation value of the temporary transportation plan in the memory. The solution improvement generation unit 152 determines whether the hypothetical solution of the temporary transportation plan satisfies the first constraint and the second constraint. If the hypothetical solution of the temporary transportation plan satisfies the first constraint and the second constraint, the hypothetical solution and its evaluation value are stored as the current solution and evaluation value of the current solution of the temporary transportation plan in the memory.

[0125] The solution improvement generation unit 152 generates the optimal solution for the temporary transportation plan by repeating the generation of the hypothetical solution for the temporary transportation plan and the update of the current solution a given number of times. After repeating the generation of the hypothetical solution for the temporary transportation plan and the update of the current solution a given number of times, the solution improvement generation unit 152 overwrites the individual transportation plans in the current solution that satisfy the first constraint and the second constraint as temporary transportation plans in the temporary transportation plan storage unit 12. Furthermore, after repeating the generation of the hypothetical solution for the temporary transportation plan and the update of the current solution a given number of times, the solution improvement generation unit 152 overwrites the customer transportation request data contained in the individual transportation plans in the current solution that do not satisfy the first constraint and the second constraint in the unallocated transportation request storage unit 13.

[0126] Evaluation unit 153 obtains the initial solution or hypothetical solution candidate for the temporary transportation plan from improvement solution generation unit 152. Evaluation unit 153 calculates the total transportation time of all vehicles in the initial solution or hypothetical solution candidate for the temporary transportation plan. Evaluation unit 153 calculates the total lag time of the scheduled travel date and time of multiple customers in the initial solution or hypothetical solution candidate for the temporary transportation plan relative to the travel date and time of the transportation request data. Evaluation unit 153 calculates the sum of the total transportation time and the sum of the lag time as the evaluation value. More specifically, evaluation unit 153 calculates the evaluation value based on the following formula (2).

[0127] Evaluation value = Σ_v∈V F1(v) + α*F2(v)···(2)

[0128] In equation (2) above, F1(v) represents the total transport time of vehicle v, F2(v) represents the total lag time of the scheduled travel date of vehicle v relative to the travel date of the transport request data, and V represents the set of vehicles included in the solution of the temporary transport plan. Furthermore, the coefficient α is a given value and is a real number greater than or equal to 0.

[0129] Evaluation unit 153 outputs the evaluation values ​​of the calculated initial solution or hypothetical solution candidate of the temporary transportation plan to improvement solution generation unit 152.

[0130] On the first determined date and time for determining the temporary transportation plan, the sending unit 16 outputs trip notification information to the customer terminal 2 of the customer assigned to the temporary transportation plan, informing the customer of the trip from boarding to disembarking. The sending unit 16 also sends the trip notification information to the customer terminal 2 of the customer assigned to the temporary transportation plan stored in the temporary transportation plan storage unit 12 on the first determined date and time.

[0131] Furthermore, at a second determined date and time used to confirm that delivery is not possible, the sending unit 16 outputs a non-application notification message to the customer terminal 2 of customers who have not been assigned a temporary delivery plan, informing them of the non-application. The second determined date and time is the date and time two hours prior to the customer's travel date and time that has not been assigned a temporary delivery plan. The second time is, for example, 12 hours. At the second determined date and time, the sending unit 16 sends the non-application notification message to the customer terminal 2 of customers who have not been assigned a temporary delivery plan stored in the unassigned delivery request storage unit 13.

[0132] In addition, the first time and the second time can be the same or different.

[0133] Furthermore, when a temporary delivery plan is created by the delivery plan creation unit 15, the sending unit 16 outputs adoption notification information to the customer terminals 2 of multiple customers assigned to the temporary delivery plan, notifying them that delivery is possible. When a temporary delivery plan is created by the delivery plan creation unit 15, the sending unit 16 sends adoption notification information to the customer terminals 2 of customers assigned to the temporary delivery plan stored in the temporary delivery plan storage unit 12.

[0134] Figure 7 This is a schematic diagram illustrating the actions of the transport plan creation server 1 in this embodiment 1 from receiving transport request data to sending trip notification information.

[0135] In addition, Figure 7In order to make it easier to understand, the period from the date and time of travel to the date and time of sending the travel notification information, and the period from the date and time of travel to the date and time of sending the notification information without notification are set to very short periods.

[0136] The delivery request receiving unit 14 received delivery request data from customer c1 at 11:00, delivery request data from customer c2 at 11:01, delivery request data from customer c3 at 11:02, and delivery request data from customer c4 at 11:03.

[0137] At 11:10, the transport planning unit 15 creates a temporary transport plan for multiple customers c1, c2, c3, and c4. Here, the transport planning unit 15 creates a temporary transport plan every 10 minutes. As a result, the transport planning unit 15 creates a first separate transport plan assigning customers c1 and c2 to vehicle v1, and a second separate transport plan assigning customers c3 and c4 to vehicle v2. At this point, the first separate transport plan satisfies the given constraints, but the second separate transport plan does not. Therefore, the transport planning unit 15 creates a temporary transport plan assigning customers c1 and c2 to vehicle v1, but does not create a temporary transport plan assigning customers c3 and c4 to vehicle v2.

[0138] Then, the sending unit 16 sends an adoption notification message to the customer terminals 2 of customers c1 and c2 who are assigned to the temporary delivery plan, to notify them that delivery is possible.

[0139] Subsequently, the delivery request receiving unit 14 received the delivery request data from customer c5 at 11:11 and the delivery request data from customer c6 at 11:12.

[0140] At 11:20, the transport planning unit 15 creates a temporary transport plan for multiple customers c1, c2, c3, c4, c5, and c6. As a result, the transport planning unit 15 creates a first separate transport plan assigning customers c1 and c5 to vehicle v1, a second separate transport plan assigning customers c2 and c4 to vehicle v2, and a third separate transport plan assigning customer c3 to vehicle v3. At this point, the first and second separate transport plans satisfy the given constraints, but the third separate transport plan does not. Therefore, the transport planning unit 15 creates a temporary transport plan assigning customers c1 and c5 to vehicle v1 and a temporary transport plan assigning customers c2 and c4 to vehicle v2, but does not create a temporary transport plan assigning customer c3 to vehicle v3.

[0141] Then, the sending unit 16 sends an adoption notification message to the customer terminals 2 of customers c4 and c5, who are newly assigned to the temporary delivery plan, to inform them that delivery is possible.

[0142] If the current date and time is 11:22 (first determined date and time) before the given time (first time) of customer c1's travel date and time, the temporary transportation plan for customers c1 and c5 is officially determined. The dispatching unit 16 sends a trip notification message to the customer terminal 2 of customer c1, which is assigned to the temporary transportation plan, to inform customer c1 of the trip from boarding to disembarking, and sends a trip notification message to the customer terminal 2 of customer c5, which is assigned to the same temporary transportation plan, to inform customer c5 of the trip from boarding to disembarking.

[0143] Then, at 11:30, the transport planning unit 15 creates a temporary transport plan for multiple customers c2, c3, c4, and c6. As a result, the transport planning unit 15 creates a first separate transport plan to allocate customers c3 and c6 to vehicle 2 v2, and a second separate transport plan to allocate customers c2 and c4 to vehicle 3 v3. At this time, the first separate transport plan does not meet the given constraints, but the second separate transport plan does. Therefore, the transport planning unit 15 creates a temporary transport plan to allocate customers c2 and c4 to vehicle 3 v3, but does not create a temporary transport plan to allocate customers c3 and c6 to vehicle 2 v2.

[0144] If the current date and time is 11:32 (the second determined date and time) before the given time (the second time) of the passenger's travel date and time for customer c3, the sending unit 16 sends a non-application notification message to the customer terminal 2 of customer c3, who has not been assigned a temporary transportation plan, to notify that transportation is not possible.

[0145] If the current date and time is 11:33 (second determined date and time) before the given time (second time) of the passenger's travel date and time for customer c6, the sending unit 16 sends a non-application notification message to the customer terminal 2 of customer c6, who has not been assigned a temporary transportation plan, to notify that transportation is not possible.

[0146] If the current date and time is 11:34 (first determined date and time) before the given time (first time) of customer c2's travel date and time, the temporary transportation plan for customers c2 and c4 is officially determined. The dispatching unit 16 sends a trip notification message to customer terminal 2 of customer c2, which is assigned to the temporary transportation plan, to inform customer c2 of the trip from boarding to disembarking. In addition, it sends a trip notification message to customer terminal 2 of customer c4, which is assigned to the same temporary transportation plan, to inform customer c4 of the trip from boarding to disembarking.

[0147] In existing on-demand bus services, all delivery requests received from customers are unconditionally used to create delivery plans. This leads to problems such as difficulty in ensuring profitability in areas or time periods with low delivery request density.

[0148] In contrast, in the vehicle dispatch management system of this embodiment 1, transport requests received from customers are not directly used. Instead, based on pre-set constraints, transport requests are only used when assigned to a transport plan that ensures profitability. Furthermore, by spending a certain amount of time aggregating transport requests that can be used for ride-sharing, more transport plans that ensure profitability can be created.

[0149] That is, the mechanism of increasing ride-sharing by spending time aggregating delivery requests and the mechanism of ensuring the profitability of delivery can ensure the profitability of delivery while making delivery plans with a high probability, even in areas or time periods where the density of delivery requests is low.

[0150] Next, the operation of the delivery plan creation server 1 in Embodiment 1 of this disclosure will be described.

[0151] Figure 8 This is a flowchart illustrating the operation of the transport request receiving unit 14 of the transport plan creation server 1 in Embodiment 1 of this disclosure. Additionally, Figure 8 The actions shown are triggered by receiving the data request for delivery.

[0152] First, in step S11, the delivery request receiving unit 14 receives delivery request data sent by the customer terminal 2.

[0153] Next, in step S12, the delivery request receiving unit 14 determines whether the date and time of sending the delivery request data is within an acceptable time period. For example, an acceptable time period could be defined as at least 12 hours prior to the travel date and time contained in the delivery request data. Therefore, if the date and time of sending the delivery request data is within an acceptable time period, the delivery request receiving unit 14 accepts the delivery request data; if the date and time of sending the delivery request data is outside an acceptable time period, the delivery request receiving unit 14 does not accept the delivery request data.

[0154] Here, if it is determined that the travel date and time are not within the given time period (step S12 "No"), in step S13, the transport request receiving unit 14 sends an error notification to the customer terminal 2 that sent the transport request data, indicating that the transport request data cannot be accepted.

[0155] On the other hand, if it is determined that the travel date and time are within a given time period (step S12 "Yes"), in step S14, the transport request receiving unit 14 stores the received transport request data in the unallocated transport request storage unit 13.

[0156] Figure 9 This is a first flowchart illustrating the operation of the transport planning generation unit 15 of the transport planning generation server 1 in Embodiment 1 of this disclosure. Figure 10 This is a second flowchart illustrating the operation of the transportation planning generation unit 15 of the transportation planning generation server 1 in Embodiment 1 of this disclosure. Figure 11 This is a third flowchart illustrating the operation of the transport planning generation unit 15 of the transport planning generation server 1 in Embodiment 1 of this disclosure. Figure 12 This is a fourth flowchart illustrating the operation of the transportation planning unit 15 of the transportation planning server 1 in Embodiment 1 of this disclosure. Additionally, Figures 9-12 The actions shown are performed at given intervals, such as every 10 minutes.

[0157] First, in step S21, the initial decoding unit 151 obtains the temporary transportation plan stored in the temporary transportation plan storage unit 12. The initial decoding unit 151 reads the temporary transportation plan from the temporary transportation plan storage unit 12. Alternatively, if no temporary transportation plan is stored in the temporary transportation plan storage unit 12, the initial decoding unit 151 does not obtain the temporary transportation plan.

[0158] Next, in step S22, the initial solution creation unit 151 stores the temporary transportation plan obtained from the temporary transportation plan storage unit 12 as the initial solution into the memory.

[0159] Next, in step S23, the initial solution generation unit 151 refers to the vehicle definition data stored in the setting data storage unit 11 to determine one vehicle that is not included in the initial solution of the temporary transport plan.

[0160] Next, in step S24, the initial solution generation unit 151 determines whether there is a vehicle in the vehicle definition data that is not included in the initial solution of the temporary transport plan.

[0161] Here, if it is determined that there is a vehicle in the vehicle definition data that is not included in the initial solution of the temporary transport plan (step S24 "Yes"), in step S25, the initial solution creation unit 151 obtains at least one transport request data that is less than or equal to the number of passengers of the determined vehicle from the unallocated transport request storage unit 13.

[0162] Next, in step S26, the initial solution generation unit 151 determines whether delivery request data has been obtained from the unallocated delivery request storage unit 13. If there is no delivery request data in the unallocated delivery request storage unit 13, delivery request data is not obtained from the unallocated delivery request storage unit 13.

[0163] Here, if it is determined that delivery request data has been obtained (step S26 "Yes"), in step S27, the initial solution creation unit 151 creates a separate delivery plan so that at least one customer corresponding to at least one delivery request data obtained sequentially boards and disembarks in one vehicle.

[0164] Next, in step S28, the initial solution generation unit 151 adds the generated individual transportation plan to the initial solution of the temporary transportation plan stored in the memory. After the processing in step S28, the process returns to step S23.

[0165] Figure 13 This is a schematic diagram illustrating the process of generating an initial solution for a temporary transportation plan by the initial solution generation unit 151 in Embodiment 1.

[0166] First, the initial solution generation unit 151 obtains the temporary transportation plan stored in the temporary transportation plan storage unit 12 and stores it in memory as the initial solution. Figure 13 In the process, a temporary transport plan is obtained, which includes a separate transport plan for customer c8 and customer c9 for vehicle v4.

[0167] Next, the initial solution generation unit 151 determines one vehicle not included in the initial solution from the vehicle definition data. Then, the initial solution generation unit 151 assigns the determined vehicle to each customer in the delivery request data stored in the unallocated delivery request storage unit 13. At this time, the initial solution generation unit 151 assigns at least one customer corresponding to at least one delivery request data to the vehicle in the topmost column of the vehicle definition data until the vehicle is full. If the vehicle is full, the initial solution generation unit 151 assigns the remaining customers to the vehicles in the next column of the vehicle definition data until the vehicle is full.

[0168] The initial solution to the temporary transportation plan ensures that assigned customers board and alight in the assigned order. Figure 13 In this process, separate transportation plans are made for assigning customers c1, c2, c3 and c4 to vehicle v1, and separate transportation plans are made for assigning customers c5, c6 and c7 to vehicle v2.

[0169] The separate transport plans for vehicle 1 v1 and vehicle 2 v2 are added to the initial solution of the temporary transport plan. Thus, the initial solution of the temporary transport plan is created, which includes the separate transport plans for vehicle 1 v1, vehicle 2 v2, and vehicle 4 v4.

[0170] Back Figure 9 If it is determined that there is no vehicle in the vehicle definition data that is not included in the initial solution of the temporary transport plan (step S24 "No"), or if it is determined that no transport request data has been obtained (step S26 "No"), in step S29, the improved solution creation unit 152 obtains the initial solution of the temporary transport plan created by the initial solution creation unit 151 from the memory.

[0171] Next, in step S30, the improved solution generation unit 152 outputs the initial solution of the obtained temporary transportation plan to the evaluation unit 153.

[0172] Next, in step S31, the evaluation unit 153 performs a solution evaluation process to calculate the evaluation value of the initial solution of the temporary transportation plan created by the initial solution creation unit 151. The solution evaluation process will be described later.

[0173] Next, in step S32, the solution improvement unit 152 obtains the evaluation value of the initial solution of the temporary transportation plan from the evaluation unit 153.

[0174] Next, in step S33, the improved solution generation unit 152 stores the initial solution of the temporary transportation plan generated by the initial solution generation unit 151 and the evaluation value of the initial solution as the current solution of the temporary transportation plan and the evaluation value of the current solution in the memory.

[0175] Next, in step S34, the solution improvement unit 152 creates a hypothetical solution of the temporary transport plan and the evaluation value of the hypothetical solution, which are copies of the current solution of the temporary transport plan stored in the memory and the evaluation value of the current solution.

[0176] Next, in step S35, the improved solution generation unit 152 initializes the count value of the number of processes. That is, the improved solution generation unit 152 sets the count value of the number of processes to 0.

[0177] Next, in step S36, the solution generation unit 152 extracts the boarding and alighting behaviors of a given number of customer groups from the hypothetical solution of the temporary transportation plan. The solution generation unit 152 randomly determines the boarding and alighting behaviors of the extracted customer groups.

[0178] Next, in step S37, the improved solution generation unit 152 obtains the ride-hailing and alighting behaviors of one customer from the extracted ride-hailing and alighting behaviors of the customer group.

[0179] Next, in step S38, the improved solution generation unit 152 lists multiple locations for pairing a customer's boarding and alighting behaviors in the hypothetical solution of the temporary transportation plan, as a group of insertion location pairs. Furthermore, the insertion location pairings must satisfy the following conditions: the insertion location for the boarding behavior belongs to the same vehicle as the alighting behavior and precedes the insertion location for the alighting behavior in the transportation plan; and the result of inserting the boarding and alighting behaviors does not exceed the vehicle's capacity.

[0180] Next, in step S39, the improved solution generation unit 152 generates a candidate group of hypothetical solutions by inserting the insertion part pairing group into the hypothetical solution of the temporary transportation plan.

[0181] Next, in step S40, the improved solution generation unit 152 outputs one of the hypothetical solution candidates from the hypothetical solution candidate group of the temporary transportation plan to the evaluation unit 153.

[0182] Next, in step S41, the evaluation unit 153 performs a solution evaluation process to calculate the evaluation values ​​of the hypothetical solution candidates for the temporary transportation plan generated by the improved solution generation unit 152. The solution evaluation process will be described later.

[0183] Next, in step S42, the improved solution generation unit 152 obtains the evaluation value of the hypothetical solution candidate of the temporary transportation plan from the evaluation unit 153.

[0184] Next, in step S43, the improved solution generation unit 152 determines whether all evaluation values ​​of the candidate hypothetical solutions for the temporary transportation plan have been obtained. If it is determined that all evaluation values ​​of the candidate hypothetical solutions for the temporary transportation plan have not been obtained (step S43 "No"), the process returns to step S40. Then, the improved solution generation unit 152 outputs another candidate hypothetical solution from the candidate hypothetical solutions for the temporary transportation plan that has not yet obtained an evaluation value to the evaluation unit 153.

[0185] On the other hand, if it is determined that all the evaluation values ​​of the candidate hypothetical solutions for the temporary transportation plan have been obtained (step S43 "Yes"), in step S44, the solution improvement unit 152 stores the candidate hypothetical solution with the smallest evaluation value and the evaluation value of the candidate hypothetical solution as the hypothetical solution for the temporary transportation plan and the evaluation value of the hypothetical solution in the memory.

[0186] Next, in step S45, the improvement solution unit 152 determines whether all the boarding and alighting behaviors of the extracted customer group have been obtained. If it is determined that not all the boarding and alighting behaviors of the customer group have been obtained (step S45 "No"), the process returns to step S37. Then, the improvement solution unit 152 obtains the boarding and alighting behaviors of another customer that has not yet been obtained from the boarding and alighting behaviors of the extracted customer group.

[0187] On the other hand, if it is determined that all passenger boarding and alighting behaviors of the customer group have been obtained (step S45 "Yes"), in step S46, the improvement solution unit 152 obtains bus stop distance table data, bus stop timetable data, passenger number restriction data and detour restriction data from the setting data storage unit 11.

[0188] Next, in step S47, the solution improvement unit 152 calculates the transport distance of each individual transport plan in the hypothetical solution of the temporary transport plan based on the obtained bus stop distance table data. The transport distance is the distance from the boarding position of the first passenger to the alighting position of the last passenger. The transport distance of each individual transport plan can be calculated by summing the distances between bus stops.

[0189] Furthermore, when the parking location of the vehicle is not predetermined and the boarding and alighting locations are arbitrary, the improved solution unit 152 can calculate the transport route of each individual transport plan and the transport distance between parking locations based on map information.

[0190] Next, in step S48, the solution improvement unit 152 calculates the detour distance of each individual transport plan in the hypothetical solution of the temporary transport plan based on the obtained bus stop timetable data. The detour distance is a value obtained by dividing the total transport time from the initial boarding to the final disembarking of multiple customers assigned to one of the multiple vehicles in the hypothetical solution of the temporary transport plan by the total time of individual transport of multiple customers assigned to one vehicle. The total transport time and the individual transport time can be calculated by summing the times between bus stops.

[0191] Furthermore, when the parking location of the vehicle is not predetermined and the boarding and alighting locations are arbitrary, the improved solution unit 152 can calculate the delivery route of each individual delivery plan and the delivery time between parking locations based on map information.

[0192] Next, in step S49, the solution improvement unit 152 determines, based on the obtained passenger number constraint data and detour constraint data, whether the hypothetical solution of the temporary transportation plan includes a separate transportation plan that satisfies the first constraint condition and the second constraint condition.

[0193] That is, the solution improvement unit 152 obtains the lower limit value of the number of passengers corresponding to the calculated transportation distance of each individual transportation plan from the passenger number constraint data. If the number of passengers of each individual transportation plan of the assumed solution is above the obtained lower limit value, it determines that the individual transportation plan of the assumed solution satisfies the first constraint condition.

[0194] Furthermore, the solution generation unit 152 obtains a detour threshold from the detour constraint data. If the detour of each individual transport plan is below the obtained threshold, it determines that the individual transport plan of the hypothetical solution satisfies the second constraint condition.

[0195] Here, if the assumed solution for the temporary transportation plan does not contain a single transportation plan that satisfies the first constraint and the second constraint (step S49 "No"), the process proceeds to step S52.

[0196] On the other hand, if the hypothetical solution determined to be a temporary transportation plan includes a separate transportation plan that satisfies both the first and second constraints (step S49 "Yes"), in step S50, the solution improvement unit 152 determines whether the evaluation value of the hypothetical solution is less than the evaluation value of the current solution. Here, if the evaluation value of the hypothetical solution is determined to be greater than or equal to the evaluation value of the current solution (step S50 "No"), the process proceeds to step S52.

[0197] On the other hand, if it is determined that the evaluation value of the hypothetical solution is less than the evaluation value of the current solution (step S50 "Yes"), in step S51, the solution improvement unit 152 replaces the current solution of the temporary transportation plan stored in the memory and the evaluation value of the current solution with the hypothetical solution of the temporary transportation plan and the evaluation value of the hypothetical solution.

[0198] Next, in step S52, the improvement solution generation unit 152 determines whether the count value of the number of processes is a given number. Here, if it is determined that the count value of the number of processes is not a given number (step S52 "No"), in step S53, the improvement solution generation unit 152 increments the count value of the number of processes. After performing the processing in step S53, the process returns to step S36.

[0199] On the other hand, if the count value of the number of processing times is determined to be a given number (step S52 "Yes"), in step S54, the improved solution generation unit 152 refers to the vehicle definition data stored in the setting data storage unit 11 to determine one vehicle that is not included in the current solution of the temporary transport plan.

[0200] Next, in step S55, the solution improvement unit 152 determines whether there is a vehicle in the vehicle definition data that is not included in the current solution of the temporary transport plan.

[0201] Here, if it is determined that there is one vehicle in the vehicle definition data that is not included in the current solution of the temporary transport plan (step S55 "Yes"), in step S56, the solution improvement unit 152 adds the determined vehicle to the current solution of the temporary transport plan. Thus, by adding the vehicle with the unassigned customer to the current solution of the temporary transport plan, a more optimal solution can be created. After processing in step S56, the process returns to step S34.

[0202] On the other hand, if it is determined that there is no vehicle in the vehicle definition data that is not included in the current solution of the temporary transport plan (step S55 "No"), in step S57, the solution improvement unit 152 overwrites and stores the individual transport plan that satisfies the first constraint condition and the second constraint condition in the current solution of the temporary transport plan as a temporary transport plan in the temporary transport plan storage unit 12.

[0203] Next, in step S58, the improved solution creation unit 152 overwrites and stores the customer's delivery request data contained in the individual delivery plans that do not meet the first and second constraints in the current solution of the temporary delivery plan in the unassigned delivery request storage unit 13.

[0204] Figure 14 This is a schematic diagram illustrating the processing of the hypothetical solution for which the improved solution generation unit 152 generates a temporary transportation plan in Embodiment 1.

[0205] The solution generation unit 152 randomly determines the boarding and alighting behaviors of a given number of customers from the hypothetical solution of the temporary transportation plan.

[0206] exist Figure 14 In the process, the boarding and alighting behaviors of customer c6 are extracted from the individual transport plan of vehicle v2, and the boarding and alighting behaviors of customer c8 are extracted from the individual transport plan of vehicle v4.

[0207] Ultimately, the improved solution generation unit 152 pairs and inserts data on customer group boarding and alighting behaviors at the insertion point with the lowest evaluation value. Figure 14 In the separate transportation plan for vehicle v4, the boarding and alighting behaviors of customers c6 and c8 are inserted. Thus, the solution-making unit 152 generates a hypothetical solution for the temporary transportation plan with the minimum evaluation value.

[0208] Next, the explanation Figure 10 Step S31 and Figure 11 The details of the solution evaluation process in step S41.

[0209] Figure 15This is a flowchart illustrating the evaluation process of the delivery plan creation server 1 in Embodiment 1.

[0210] First, in step S61, the evaluation unit 153 obtains either an initial solution for the temporary transportation plan generated by the initial solution generation unit 151 or a candidate hypothetical solution for the temporary transportation plan generated by the improved solution generation unit 152. Figure 10 In the solution evaluation process of step S31, the evaluation unit 153 obtains the initial solution of the temporary transportation plan generated by the initial solution generation unit 151. Furthermore, in Figure 11 In the solution evaluation process of step S41, the evaluation unit 153 obtains the hypothetical solution candidate of the temporary transportation plan made by the solution improvement unit 152.

[0211] Next, in step S62, the evaluation unit 153 obtains bus stop timetable data from the set data storage unit 11.

[0212] Next, in step S63, the evaluation unit 153 initializes the evaluation value. That is, the evaluation unit 153 sets the evaluation value to 0.

[0213] Next, in step S64, the evaluation unit 153 obtains a separate transportation plan for one vehicle from the initial solution or hypothetical solution candidate of the temporary transportation plan.

[0214] Next, in step S65, the evaluation unit 153 determines whether a separate transportation plan for one vehicle has been obtained from the initial solution or the candidate hypothetical solution of the temporary transportation plan.

[0215] Here, if it is determined that a separate transportation plan for one vehicle has been obtained (step S65 "Yes"), in step S66, the evaluation unit 153 calculates the scheduled boarding date and time and the scheduled alighting date and time for each customer allocated to the separate transportation plan for one vehicle. At this time, the evaluation unit 153 calculates the desired boarding date and time contained in the transportation request data of the first customer in line for the separate transportation plan, and uses this as the scheduled boarding date and time for the first customer in line. Then, the evaluation unit 153 calculates the scheduled boarding date and time and the scheduled alighting date and time for the second and subsequent customers by adding the time between bus stops recorded in the bus stop timetable data. However, if a customer's scheduled boarding date and time is earlier than their desired boarding date and time, the vehicle waits at the bus stop until the desired boarding date and time. Therefore, if a customer's scheduled boarding date and time is earlier than their desired boarding date and time, the evaluation unit 153 changes the scheduled boarding date and time to the customer's desired boarding date and time, and calculates the scheduled boarding date and time and the scheduled alighting date and time for subsequent customers.

[0216] Furthermore, when the parking location of the vehicle is not predetermined and the boarding and alighting locations are arbitrary, the evaluation unit 153 can calculate the delivery route of the individual delivery plan and the delivery time between parking locations based on map information.

[0217] Next, in step S67, the evaluation unit 153 calculates the total transport time F1 for one vehicle. At this time, the evaluation unit 153 calculates the total transport time F1 by subtracting the scheduled date and time of the passenger who first boarded the vehicle from the scheduled date and time of the passenger who last boarded the vehicle.

[0218] Next, in step S68, if the scheduled travel date for each customer in a separate transport plan assigned to one vehicle is later than the desired travel date in the transport request data, the evaluation unit 153 calculates the difference between the scheduled travel date and the desired travel date as the lag time, and calculates the total lag time F2 for one vehicle.

[0219] Next, in step S69, the evaluation unit 153 adds the total value F2 of the lag time multiplied by the coefficient α and the total value F1 of the transportation time, and adds the summation value and the evaluation value. After the processing in step S69, the processing returns to step S64. Then, the processing of steps S64 to S69 is performed until individual transportation plans for all vehicles are obtained from the initial solution or hypothetical solution candidate of the temporary transportation plan.

[0220] On the other hand, if it is determined that a separate transportation plan for one vehicle has not been obtained from the initial solution or hypothetical solution candidate of the temporary transportation plan (step S65 "No"), in step S70, the evaluation unit 153 outputs the calculated evaluation value to the improved solution creation unit 152. Figure 10 In the solution evaluation process of step S31, the evaluation unit 153 outputs the calculated evaluation value of the initial solution to the improved solution generation unit 152. Furthermore, in Figure 11 In the solution evaluation process of step S41, the evaluation unit 153 outputs the calculated evaluation value of the hypothetical solution candidate to the improved solution generation unit 152.

[0221] Furthermore, in this embodiment 1, the evaluation unit 153 calculates the total transport time of one vehicle, but this disclosure is not particularly limited to this; the total transport distance of one vehicle can also be calculated. In this case, the evaluation unit 153 uses bus stop distance table data and calculates the total transport distance by summing the distances between each bus stop from the boarding position of the first passenger boarding the vehicle to the alighting position of the last passenger alighting from the vehicle.

[0222] Figure 16This is a flowchart illustrating the operation of the sending unit 16 of the delivery plan creation server 1 in Embodiment 1 of this disclosure. Additionally, Figure 16 The actions shown are performed at given intervals, such as every 1 minute.

[0223] First, in step S81, the sending unit 16 determines whether there are any individual delivery plans stored in the temporary delivery plan storage unit 12 that have not been notified to the customer using notification information. If it is determined that there are no individual delivery plans that have not been notified to the customer using notification information (step S81 "No"), the process proceeds to step S83.

[0224] On the other hand, if it is determined that there are individual delivery plans for which adoption notification information has not been sent to customers (step S81 "Yes"), in step S82, the sending unit 16 sends adoption notification information to the customer terminals 2 of each of the multiple customers assigned to the unnotified individual delivery plans. Alternatively, the sending unit 16 may also assign a notification completion mark to the individual delivery plans for which adoption notification information has been sent. Therefore, it is easy to determine whether there are individual delivery plans for which adoption notification information has not been sent to customers.

[0225] Next, in step S83, the sending unit 16 determines whether there are any delivery request data stored in the unallocated delivery request storage unit 13 that are two hours after the current date and time. If it is determined that there are no delivery request data two hours after the current date and time (step S83 "No"), the process proceeds to step S86.

[0226] On the other hand, if it is determined that there is a delivery request data with a travel date and time that is 2 hours after the current date and time (step S83 "Yes"), in step S84, the sending unit 16 sends a notification message not to be used to the customer terminal 2 of the customer with the travel request data with a travel date and time that is 2 hours after the current date and time.

[0227] Next, in step S85, the sending unit 16 deletes the unassigned shipping request storage unit 13 from the shipping request data of customers who sent the notification information.

[0228] Next, in step S86, the sending unit 16 determines whether there is a separate delivery plan in the temporary delivery plan stored in the temporary delivery plan storage unit 12 for the first customer in line whose travel date and time is after the first time from the current date and time.

[0229] Here, if the passenger who is determined to be without a queue has a separate transport plan for the first time after the current date (step S86 "No"), the process ends.

[0230] On the other hand, if it is determined that the passenger at the front of the queue has a separate transport plan with a travel date and time after the first time from the current date and time (step S86 "Yes"), in step S87, the sending unit 16 sends travel notification information to the customer terminals 2 of each of the multiple customers whose travel dates and times are assigned to the passenger at the front of the queue and are separate transport plans with a travel date and time after the first time from the current date and time.

[0231] Next, in step S88, the sending unit 16 removes the individual delivery plans containing the trip notification information of multiple customers from the temporary delivery plan storage unit 12.

[0232] In addition, the individual transport plans removed from the temporary transport plans are the officially confirmed individual transport plans. The actual operating system with bus operation instructions has functions such as storing the confirmed individual transport plans and instructing buses (drivers) to proceed.

[0233] In this way, temporary transport plans are periodically created based on multiple transport requests, assigning multiple customers to multiple vehicles to meet given constraints, until a first determined date and time is reached to finalize the temporary transport plan. Therefore, even in areas with low transport demand, transport requests from more customers can be obtained, and more customers can be assigned to multiple vehicles, thus enabling the creation of transport plans that ensure profitability.

[0234] Next, the various screens displayed on customer terminal 2 will be explained.

[0235] Figure 17 This is a diagram illustrating an example of a delivery request input screen displayed on the customer terminal 2 in Embodiment 1.

[0236] Multiple customer terminals 2 each have a display unit 21 composed of a liquid crystal display device or a touch panel. For example... Figure 17 As shown, the display unit 21 displays a transport request input screen for accepting the customer's pick-up location, drop-off location, and pick-up date and time. The customer inputs the pick-up location, drop-off location, and pick-up date and time on the displayed transport request input screen. In this embodiment 1, since the vehicle's route and parking locations are predetermined, the customer selects a pick-up location and drop-off location from a plurality of predetermined parking locations.

[0237] The delivery request input screen includes a send button and a cancel button. Clicking or touching the send button sends the delivery request data, including the customer ID, boarding location, alighting location, and boarding date and time, to the delivery planning server 1. Clicking or touching the cancel button cancels the entered boarding location, alighting location, and boarding date and time.

[0238] Figure 18 This diagram illustrates an example of an adoption notification screen displayed on the customer terminal 2 in Embodiment 1.

[0239] Customer terminal 2 receives an acceptance notification message sent by the delivery plan creation server 1. If the acceptance notification message is received, the display unit 21 of customer terminal 2 displays an acceptance notification screen to notify the customer that the delivery request has been accepted. Figure 18 The notification screen shown contains a statement indicating that the customer's delivery request has been accepted.

[0240] Figure 19 This diagram illustrates an example of a notification screen not displayed on the customer terminal 2 in Embodiment 1.

[0241] Customer terminal 2 receives a rejection notification message sent by the delivery plan creation server 1. If a rejection notification message is received, the display unit 21 of customer terminal 2 displays a rejection notification screen to inform the customer that the delivery request has not been accepted. Figure 19 The "Not Accepted" screen shown contains a statement indicating that the customer's shipping request is being accepted.

[0242] Figure 20 This diagram illustrates an example of a trip notification screen displayed on the customer terminal 2 in Embodiment 1.

[0243] Customer terminal 2 receives trip notification information sent by the transportation planning server 1. If trip notification information is received, the display unit 21 of customer terminal 2 displays a trip notification screen to notify the customer of the trip.

[0244] like Figure 20 As shown, once the temporary transportation plan for assigning customers c6, c8, and c9 to vehicle v4 is determined, the sending unit 16 of the transportation plan creation server 1 sends trip notification information to customers c6, c8, and c9 respectively. Figure 20 The trip notification screen shown represents customer C8's trip. The screen includes the vehicle ID of the vehicle C8 is traveling in, the boarding location, the scheduled boarding date and time, the drop-off location, the scheduled drop-off date and time, and the transit points. The transit points indicate the bus stops between customer C8's boarding and drop-off locations.

[0245] exist Figure 20 At 11:12, customer C8 boarded bus V4 at bus stop S8S, passed through bus stops S6S and S6E, and disembarked from bus V4 at bus stop S8E at 11:21.

[0246] In addition, the travel reservation date and time contained in the trip notification information may lag behind the travel date and time contained in the transport request data.

[0247] Furthermore, the operation of customer terminal 2 is as follows: First, customer terminal 2 sends the delivery request data to the delivery plan creation server 1. Next, customer terminal 2 enters standby mode until it receives an adoption notification or a non-adoption notification. Next, customer terminal 2 receives the adoption notification or the non-adoption notification. Next, if customer terminal 2 receives the adoption notification, it enters standby mode until it receives a trip notification. Next, customer terminal 2 receives the trip notification.

[0248] The sending unit 16 can output a first standby notification message during the period from obtaining the delivery request data to outputting whether or not to use the notification message, to notify the customer of the standby time from the generation of the standby information to the decision on whether or not to deliver. That is, the sending unit 16 can send the first standby notification message to the customer terminal 2. The customer terminal 2 can also receive the first standby notification message during the first standby time from sending the delivery request data to receiving the notification message and displaying a first message screen to notify the customer of the generation of the standby time.

[0249] Figure 21 This diagram illustrates an example of the first message screen displayed on the customer terminal 2 in Embodiment 1.

[0250] After sending the delivery request data, the display unit 21 of the customer terminal 2 displays a first message screen for notifying the customer of the generation of the standby time. Figure 21 The first message screen shown contains statements used to notify customers of the standby time. Additionally, the first message screen includes the end date and time of the standby time. The end date and time of the standby time is the date and time obtained by subtracting the second time from the travel date and time contained in the delivery request data.

[0251] Furthermore, the sending unit 16 can output a second standby notification message during the period from outputting the adoption notification message to outputting the trip notification message, to notify the customer of the standby time from the occurrence of the standby time to the trip decision. That is, the sending unit 16 can also send the second standby notification message to the customer terminal 2. The customer terminal 2 can receive the second standby notification message during the second standby time from receiving the adoption notification message to receiving the trip notification message, and display a second message screen to notify the customer of the occurrence of the standby time.

[0252] Figure 22 This diagram illustrates an example of the second message screen displayed on the customer terminal 2 in Embodiment 1.

[0253] After receiving the adoption notification information, the display unit 21 of the customer terminal 2 displays a first message screen for notifying the customer of the generation of standby time. Figure 22 The second message screen shown contains statements used to notify customers of the generated standby time. Additionally, the second message screen includes the end date and time of the standby time. The end date and time of the standby time is the date and time of the first customer's arrival at the front of the queue for their assigned individual transportation plan minus the date and time of the first time.

[0254] (Implementation Method 2)

[0255] The transportation area covered by a transportation company may actually contain a mixture of sub-areas where profitability can be guaranteed and sub-areas where profitability cannot be guaranteed. Furthermore, even within the same sub-area, there may be a mixture of time periods where profitability can be guaranteed and time periods where profitability cannot be guaranteed. In this case, the transportation planning method of Implementation 1 is sufficient to apply only to sub-areas where profitability cannot be guaranteed.

[0256] Therefore, in this second embodiment, a shipping plan creation server that combines the existing shipping plan creation method with the shipping plan creation method of embodiment 1 will be described.

[0257] Figure 23 This is a diagram showing the overall structure of the vehicle dispatch management system in Embodiment 2 of this disclosure.

[0258] Figure 23 The vehicle dispatch management system shown has a transport plan creation server 1A and multiple customer terminals 2.

[0259] The delivery plan generation server 1A includes a setting data storage unit 11A, a temporary delivery plan storage unit 12, an unassigned delivery request storage unit 13, a delivery request receiving unit 14A, a delivery plan generation unit 15, a sending unit 16A, and a real-time delivery plan generation unit 17. Furthermore, in this embodiment 2, the same reference numerals are used for structures identical to those in embodiment 1, and descriptions are omitted.

[0260] In addition to pre-storing bus stop timetable data, bus stop distance table data, vehicle definition data, passenger capacity restriction data, and detour restriction data, the data storage unit 11A also pre-storing multiple sub-area definition data.

[0261] Figure 24 This is a diagram illustrating an example of the definition data for multiple sub-regions in Embodiment 2.

[0262] The area where multiple vehicles operate (the operating area of ​​the transportation company) is divided into at least one sub-region. The set of sub-regions is MECE (Mutually Exclusive and Collectively Exhaustive) relative to the operating area. At least one sub-region is categorized into a first sub-region with a delivery request density above a threshold and a second sub-region with a delivery request density below a threshold. The number and size of the at least one sub-region vary depending on the time period. Multiple sub-region definition data are set for each time period.

[0263] The data storage unit 11A is configured to store, for example, the first sub-region definition data corresponding to the time period from 6:00 to 9:00 and the time period from 16:00 to 20:00, the second sub-region definition data corresponding to the time period from 9:00 to 16:00, and the third sub-region definition data corresponding to the time period from 20:00 to 22:00.

[0264] exist Figure 24 In the diagram, a high-density first sub-region represents a sub-region where the density of transport request generation exceeds a threshold, and a low-density sub-region represents a second sub-region where the density of transport request generation is below a threshold. The first sub-region definition includes two first sub-regions and two second sub-regions. The second sub-region definition includes one second sub-region. The third sub-region definition includes one first sub-region and one second sub-region.

[0265] The transport request receiving unit 14A receives transport request data sent by the customer terminal 2. The transport request receiving unit 14A determines whether either or both of the boarding and alighting locations contained in the transport request data fall within a first sub-region or a second sub-region. If either or both of the boarding and alighting locations contained in the transport request data fall within the first sub-region, the transport request receiving unit 14A outputs the received transport request data to the real-time transport planning unit 17. Conversely, if either or both of the boarding and alighting locations contained in the transport request data fall within the second sub-region, the transport request receiving unit 14A stores the received transport request data in the unallocated transport request storage unit 13.

[0266] The real-time transportation plan generation unit 17 immediately generates a transportation plan that assigns the customer to one vehicle based on the transportation request data received by the transportation request receiving unit 14A. The real-time transportation plan generation unit 17 generates the transportation plan without considering the profitability of the transportation. If either or both of the boarding and alighting locations contained in the transportation request data fall within the first sub-area, the real-time transportation plan generation unit 17 immediately generates a transportation plan based on the transportation request data that assigns the customer to one vehicle.

[0267] Furthermore, the real-time transport planning unit 17 uses the same method as the existing on-demand bus service to create transport plans. Existing transport plan creation methods are disclosed, for example, in prior literature (Hideyuki Nakajima et al., "Smart Access Vehicle System: Installation and Evaluation of a Fully On-Demand Public Transportation Vehicle Dispatch System", Journal of the Society for Information Processing, Vol. 57, No. 4, April 2016, pp. 1290-1302).

[0268] The sending unit 16A outputs trip notification information to the customer terminal 2 of the customer whose trip plan is assigned to the real-time trip plan creation unit 17. That is, the sending unit 16A sends trip notification information to the customer terminal 2 of the customer whose trip plan is assigned to the real-time trip plan creation unit 17.

[0269] If either or both of the boarding and alighting locations contained in the transport request data fall within the second sub-region, the transport planning unit 15 creates a temporary transport plan based on the transport request data, which assigns the customers of the transport request data to multiple vehicles to satisfy given constraints.

[0270] Next, the operation of the delivery plan creation server 1A in Embodiment 2 of this disclosure will be described.

[0271] Figure 25 This is a flowchart illustrating the operation of the transport request receiving unit 14A of the transport plan creation server 1A in Embodiment 2 of this disclosure. Additionally, Figure 25 The actions shown are triggered by receiving the data request for delivery.

[0272] The processing in steps S91 to S93 is due to... Figure 8 The processes in steps S11 to S13 are the same, so the explanation is omitted.

[0273] If the travel date and time are determined to be within a given time period (step S92 "Yes"), in step S94, the transport request receiving unit 14A obtains the sub-region definition data of the time period to which the travel date and time belong in the transport request data from the setting data storage unit 11. For example, if the travel date and time is 13:00, the transport request receiving unit 14A obtains the second sub-region definition data of the time period from 9:00 to 16:00.

[0274] Next, in step S95, the transport request receiving unit 14A determines whether the boarding location contained in the transport request data is within the high-density first sub-region based on the obtained sub-region definition data.

[0275] Here, if the boarding location is determined to be in a low-density first sub-region, that is, if the boarding location is determined to be in a low-density second sub-region (step S95 "No"), in step S96, the transport request receiving unit 14A obtains the bus stop timetable data from the setting data storage unit 11.

[0276] Next, in step S97, the transport request receiving unit 14A uses the bus stop timetable data to calculate the drop-off date and time for the case where only customers who have sent transport request data will be transported from their boarding location to their drop-off location.

[0277] In addition, when the parking location of the vehicle is not predetermined and the boarding and alighting locations are arbitrary, the transport request receiving unit 14A can calculate the transport route and transport time from the boarding location to the alighting location based on map information.

[0278] Next, in step S98, the transport request receiving unit 14A obtains the sub-region definition data of the time period to which the calculated drop-off date and time belong from the setting data storage unit 11. For example, if the drop-off date and time is 13:30, the transport request receiving unit 14A obtains the second sub-region definition data of the time period from 9:00 to 16:00.

[0279] Next, in step S99, the transport request receiving unit 14A determines whether the calculated drop-off location is within the high-density first sub-region based on the obtained sub-region definition data.

[0280] Here, if it is determined that the drop-off location is not in the high-density first sub-region, that is, if it is determined that the drop-off location is in the low-density second sub-region (step S99 "No"), in step S100, the transport request receiving unit 14A stores the received transport request data in the unallocated transport request storage unit 13.

[0281] On the other hand, if it is determined in step S95 that the boarding location is within a high-density first sub-region (step S95 "Yes"), or if it is determined in step S99 that the alighting location is within a high-density first sub-region (step S99 "Yes"), the transport request receiving unit 14A outputs the received transport request data to the real-time transport planning unit 17.

[0282] In this embodiment 2, the transport request receiving unit 14A outputs the received transport request data to the real-time transport planning unit 17 when either the boarding location or the alighting location included in the transport request data is within the first sub-area. However, this disclosure is not particularly limited to this. The transport request receiving unit 14A may also output the received transport request data to the real-time transport planning unit 17 when only the boarding location included in the transport request data is within the first sub-area. Furthermore, the transport request receiving unit 14A may also output the received transport request data to the real-time transport planning unit 17 when only the alighting location included in the transport request data is within the first sub-area. Furthermore, the transport request receiving unit 14A may also output the received transport request data to the real-time transport planning unit 17 when both the boarding location and the alighting location included in the transport request data are within the first sub-area.

[0283] Furthermore, the operation of the transport planning unit 15 and the dispatching unit 16A in Embodiment 2 is the same as that of the transport planning unit 15 and the dispatching unit 16 in Embodiment 1, so the description is omitted.

[0284] Furthermore, in the above embodiments, each component can be constructed by dedicated hardware or implemented by executing software programs suitable for each component. Each component can also be implemented by a program execution unit such as a CPU or processor reading and executing software programs recorded on recording media such as hard disks or semiconductor memory. Alternatively, the program can be implemented using a separate computer system by recording the program on a recording medium and transferring it, or by transferring the program via a network.

[0285] The devices described in this disclosure typically implement part or all of their functionality as integrated circuits, i.e., LSIs (Large Scale Integration). These can be implemented as a single chip, or comprised of one or all of them as single chips. Furthermore, integrated circuit implementation is not limited to LSIs; it can also be implemented by application-specific circuits or general-purpose processors. FPGAs (Field Programmable Gate Arrays) that can be programmed after LSI fabrication, or reconfigurable processors that can reconfigure the connection and settings of the circuit cells within the LSI, can also be used.

[0286] In addition, some or all of the functions of the apparatus involved in the embodiments of this disclosure can be implemented by executing programs through a processor such as a CPU.

[0287] Furthermore, all the figures used above are illustrative for the purpose of illustrating this disclosure, and this disclosure is not limited to the illustrative figures.

[0288] Furthermore, the order in which the steps shown in the flowchart are executed is for illustrative purposes only and may be any other order to achieve the same effect. Additionally, some of the steps described above may be executed simultaneously (in parallel) with other steps.

[0289] Industrial availability

[0290] The technology disclosed herein is useful as a means of creating a transportation plan that ensures the profitability of transportation.

Claims

1. An information processing method, which is an information processing method in a computer for creating a transportation plan for transporting multiple customers by multiple vehicles. The system obtains delivery requests, including customer identification information, boarding date and time, boarding location, and alighting location, from the respective terminals of the multiple customers who wish to have their vehicles delivered. Based on multiple delivery requests, a temporary delivery plan is periodically created to allocate the multiple customers to the multiple vehicles in order to meet given constraints. On the first determined date and time for determining the temporary transportation plan, the terminal assigned to the customer of the temporary transportation plan outputs trip notification information to notify the customer of the trip from boarding to disembarking.

2. The information processing method according to claim 1, wherein, Furthermore, on the second determined date and time used to determine the inability to deliver, a non-dispatch notification message is output to the terminals of customers not assigned to the temporary delivery plan to notify them of the inability to deliver.

3. The information processing method according to claim 1, wherein, The given constraints include the fact that the number of passengers in each of the multiple vehicles is above a lower limit.

4. The information processing method according to claim 3, wherein, The lower limit increases as the transportation distance or transportation time increases.

5. The information processing method according to claim 3, wherein, The lower limit is a fixed number of people. The transportation cost of the vehicle increases as the transportation distance or time increases.

6. The information processing method according to any one of claims 1 to 5, wherein, The given constraint includes: the ratio of the total time of individual transportation of multiple customers assigned to one of the multiple vehicles to the overall transportation time from the initial boarding to the final disembarking of the multiple customers assigned to the one vehicle is below a threshold.

7. The information processing method according to any one of claims 1 to 5, wherein, Furthermore, when the temporary delivery plan is made, an adoption notification message is output to the terminals of the multiple customers assigned to the temporary delivery plan to inform them that delivery is possible.

8. The information processing method according to claim 7, wherein, Furthermore, during the period from obtaining the delivery request to outputting the adoption notification information, a first standby notification information is output to notify the situation of the standby time from the generation of the standby time until a decision is made on whether delivery can proceed.

9. The information processing method according to claim 7, wherein, Furthermore, during the period from the output of the adoption notification information to the output of the trip notification information, a second standby notification information is output to notify that a standby time from the occurrence of the trip decision has been generated.

10. The information processing method according to claim 2, wherein, Furthermore, during the period from obtaining the delivery request to outputting the non-adoption notification information, a first standby notification information is output to notify the situation of the standby time from the generation of the standby time until the decision on whether delivery can be made.

11. The information processing method according to any one of claims 1 to 5, wherein, The area where the multiple vehicles transport goods is divided into at least one sub-area. The at least one sub-region is classified into a first sub-region with a delivery request generation density higher than a threshold and a second sub-region with a delivery request generation density lower than the threshold. Furthermore, if either or both of the boarding location and the alighting location in one of the multiple transport requests fall within the first sub-area, a transport plan is immediately created based on that one transport request to assign the customer of that one transport request to one vehicle. Furthermore, the trip notification information is output to the terminal of the customer assigned to the created delivery plan. In the creation of the temporary transport plan, if either or both of the boarding location and the alighting location included in the 1 transport request are within the second sub-region, the temporary transport plan is created based on the 1 transport request to allocate the customer of the 1 transport request to the plurality of vehicles so as to satisfy the given constraints.

12. The information processing method according to claim 11, wherein, The number and size of the at least one sub-region vary depending on the time period.

13. An information processing apparatus for generating a transportation plan for transporting multiple customers by multiple vehicles. The information processing device includes: The acquisition unit obtains a delivery request containing customer identification information, date and time of travel, travel location, and alighting location from the respective terminals of the plurality of customers who wish to have the vehicle transported. The production department periodically produces temporary transportation plans based on multiple transportation requests, which allocate the multiple customers to the multiple vehicles to meet given constraints. and The output unit, on a first determined date and time for determining the temporary transportation plan, outputs trip notification information to the terminals of customers assigned to the temporary transportation plan, informing the customers of their journey from boarding to disembarking.

14. An information processing program for generating a transportation plan for transporting multiple customers by multiple vehicles. The information processing program enables the computer to perform the following functions: The system obtains delivery requests, including customer identification information, boarding date and time, boarding location, and alighting location, from the respective terminals of the multiple customers who wish to have their vehicles delivered. Based on multiple delivery requests, a temporary delivery plan is periodically created to allocate the multiple customers to the multiple vehicles in order to meet given constraints. On the first determined date and time for determining the temporary transportation plan, the terminal assigned to the customer of the temporary transportation plan outputs trip notification information to notify the customer of the trip from boarding to disembarking.

Images