JP7855038B2 - Vehicle dispatch management system, vehicle dispatch reservation management method, and computer program - Google Patents

Description

This invention relates to a vehicle dispatch management system, a vehicle reservation management method, and a computer program.

On-demand transport is a type of shared public transport service that meets the demands of multiple users. It operates according to reservations made by users in advance.
Regarding on-demand transportation, for example, the reservation management technology described in Patent Document 1 is known. This technology encourages multiple users to ride the same vehicle by suggesting ride reservations to users who are likely to ride together based on their past ride history. The interface disclosed for the user terminal making a reservation allows the user to input and transmit reservation information such as the desired date and time, boarding location, and alighting location, and if the seat reservation is successful, the reservation is confirmed and the reservation result is displayed.

Furthermore, Non-Patent Document 1 describes a dispatching technology based on trip units that consider departures and returns from base stations, which is particularly necessary when using autonomous vehicles in on-demand transportation, in order to enable the operation of vehicles waiting at base stations while not in service.

Patent No. 6432205

Aoi Koizuka, Tomohiko Ogishi, "Study of a Demand-Based Transportation Dispatch System in Anticipation of the Use of Autonomous Vehicles," Proceedings of the 2020 Society Conference of the Institute of Electronics, Information and Communication Engineers, B-15-11, September 1, 2020.

However, the conventional technologies described above cannot meet the diverse needs of users who are interested in on-demand transportation and wish to freely search for rides, even if they do not intend to make a reservation, or users who wish to check the estimated departure time from their departure point and the estimated arrival time at their destination before confirming a reservation. To address these diverse user needs, it is conceivable to have reservation statuses other than "confirmed," such as an "unconfirmed" state that does not restrict other ride searches or reservation confirmations, and a "provisionally confirmed" state that does not restrict other ride searches but does restrict other reservation confirmations. On the other hand, reservation status management requires checking the consistency of reservations while transitioning between each reservation status. Here, a major characteristic of on-demand transportation is the great degree of flexibility in travel routes, pick-up/drop-off points, and pick-up/drop-off times, making it difficult to manage reservations independently for each predetermined operating section or seat, as is the case with Shinkansen (bullet train) reservations.

This invention was made in consideration of these circumstances, and its objective is to realize a reservation status management system that balances flexible vehicle search with measures to prevent reservation overlaps in a demand-type dispatch management system that operates vehicles according to reservations.

One aspect of the present invention is a demand-type dispatch management system that operates vehicles according to reservations, wherein the reservation status of a demand is defined as "first state" and "second state", the "first state" of a demand is a state in which there are no restrictions on dispatch searches and transitions in the reservation status of other demands other than the said demand, the "second state" of a demand is a state in which there are no restrictions on dispatch searches of other demands other than the said demand, but there are restrictions on the transition of other demands from the "first state" to the "second state", and the system includes a reservation status management unit that manages the reservation status of a demand and transitions the reservation status of a demand according to a user request, and sets the reservation status of the target demand to "first state" The dispatch management system includes a transition condition that permits a transition from "first state" to "second state," which includes the absence of other demands of the same vehicle and time slot as the target demand that are in the "second state" reservation status, and the reservation status management unit determines whether or not to transition the reservation status of the target demand from "first state" to "second state" based on the transition condition, and changes the reservation status of the target demand to "second state" according to the result of the determination, and the reservation status management unit is able to generate a new demand in the "first state" reservation status even if the vehicle and time slot of the new demand overlap with the vehicle and time slot of other demands in the "second state" reservation status at the time of generation of the new demand in the "first state" reservation status.
One aspect of the present invention is a dispatch management system described above, wherein the "third state" of the demand reservation status is a state that restricts dispatch searches for other demands other than the said demand, and further comprises a reservation condition identifier information storage unit that stores the latest reservation condition identifier for each vehicle and time slot, and a demand information storage unit that stores demand-related information indicating each user's demand and a reservation condition identifier for each demand, and the transition condition that permits the transition of the reservation status of the target demand from the "first state" to the "second state" is the same vehicle as the said target demand and The vehicle dispatch management system is configured such that there are no other demands in the same time slot whose reservation status is "second state", and the reservation condition identifier in the reservation condition identifier information storage unit currently assigned to the vehicle and time slot of the target demand matches the reservation condition identifier of the target demand in the demand information storage unit. When a demand in reservation status "second state" transitions to reservation status "third state", the reservation status management unit changes the reservation condition identifier in the reservation condition identifier information storage unit currently assigned to the vehicle and time slot of the demand to a new reservation condition identifier.
One aspect of the present invention is a dispatch management system described above, wherein the "third state" of the demand reservation status is a state in which dispatch searches for other demands other than the said demand are restricted, the "fourth state" of the demand reservation status is a state in which a request to cancel the said demand reservation has been received, and further comprising a reservation condition identifier information storage unit that stores the latest reservation condition identifier for each vehicle and time slot, and a demand information storage unit that stores demand-related information indicating each user's demand and a reservation condition identifier for each demand, thereby allowing the reservation status of the target demand to transition from the "first state" to the "second state". The conditions for enabling a transition are that there are no other demands of the same vehicle and time slot as the target demand that are in the "second state" reservation status, and that the reservation condition identifier currently assigned to the vehicle and time slot of the target demand in the reservation condition identifier information storage unit matches the reservation condition identifier of the target demand in the demand information storage unit. The reservation status management unit changes the reservation condition identifier currently assigned to the vehicle and time slot of the demand in the reservation condition identifier information storage unit to a new reservation condition identifier when a demand in the "third state" reservation status transitions to the "fourth state" reservation status.
One aspect of the present invention is a dispatch management system in which the reservation status management unit measures the elapsed time since a demand for a reservation status "first status" was generated, and includes as a transition condition for each reservation status of the demand that the elapsed time is less than or equal to a predetermined reservation confirmation grace period.
One aspect of the present invention is a dispatch management system in which the reservation status management unit notifies the terminal device of the user of the demand in reservation status "first status" that there is a competition among multiple users for a dispatch reservation of the demand in reservation status "first status".

One aspect of the present invention is a dispatch reservation management method executed by a demand-type dispatch management system that operates vehicles according to reservations, wherein the reservation status of a demand is defined as a "first state" and a "second state", the "first state" of the demand is a state in which there are no restrictions on dispatch searches and transitions in the reservation status of other demands other than the said demand, the "second state" of the demand is a state in which there are no restrictions on dispatch searches of other demands other than the said demand, but there are restrictions on the transition of other demands from the "first state" to the "second state", and the method includes a reservation status management step of managing the reservation status of a demand and transitioning the reservation status of a demand according to a user request, and the reservation status of the target demand The transition condition that permits the transition from "first state" to "second state" includes the absence of other demands of the same vehicle and time slot as the target demand that are in "second state" reservation status, the reservation status management step determines whether or not to transition the reservation status of the target demand from "first state" to "second state" based on the transition condition, changes the reservation status of the target demand to "second state" according to the result of the determination, and the reservation status management step is capable of generating a new demand even if, at the time of generation of a new demand in reservation status "first state", the vehicle and time slot of the new demand overlap with the vehicle and time slot of other demands in reservation status "second state", thus providing a vehicle dispatch reservation management method.

One aspect of the present invention is a computer for a demand-type dispatch management system that operates vehicles according to reservations, wherein the computer is provided with "first state" and "second state" as the reservation state of the demand, the "first state" of the demand is a state in which there are no restrictions on dispatch searches and reservation state transitions for other demands other than the said demand, the "second state" of the demand is a state in which there are no restrictions on dispatch searches for other demands other than the said demand, but there are restrictions on the transition of other demands from the "first state" to the "second state", and the computer program for managing the reservation state of the demand and executing a reservation state management step that transitions the reservation state of the demand in response to a user request, the target demand The transition condition that permits the transition of the reservation status from "first state" to "second state" includes the absence of other demands of the same vehicle and time slot as the target demand that are in the "second state" reservation status, the reservation status management step determines whether or not to transition the reservation status of the target demand from "first state" to "second state" based on the transition condition, and changes the reservation status of the target demand to "second state" according to the result of the determination, and the reservation status management step is a computer program that can generate a new demand in the "first state" reservation status even if the vehicle and time slot of the new demand overlap with the vehicle and time slot of other demands in the "second state" reservation status at the time of generation of the new demand in the "first state" reservation status.

According to the present invention, in a demand-type dispatch management system that operates vehicles according to reservations, it is possible to achieve reservation status management that simultaneously enables flexible dispatch search and measures to prevent reservation duplication.

This block diagram shows an example configuration of a dispatch management system according to one embodiment. This is a diagram illustrating an example of a trip according to one embodiment. This figure shows an example of the operation of a dispatch management system according to one embodiment. This is an explanatory diagram illustrating the reservation state and state transitions of a demand according to one embodiment. This is an explanatory diagram illustrating an example of a reservation state transition according to one embodiment. This is an explanatory diagram illustrating an example of a reservation state transition according to one embodiment. This is an explanatory diagram illustrating the correspondence between a trip and a reservation condition identifier according to one embodiment. This figure shows an example of the configuration of the display screen of a terminal device according to one embodiment. This figure shows an example of the configuration of the display screen of a terminal device according to one embodiment. This figure shows an example of the configuration of the display screen of a terminal device according to one embodiment. This figure shows an example of the configuration of the display screen of a terminal device according to one embodiment. This figure shows an example of the configuration of the display screen of a terminal device according to one embodiment. This figure shows an example of the configuration of the display screen of a terminal device according to one embodiment.

Embodiments of the present invention will be described below with reference to the drawings.
Figure 1 is a block diagram showing an example configuration of a dispatch management system according to one embodiment. The dispatch management system 1 according to this embodiment is a demand-type traffic management system. In a demand-type traffic management system, vehicles are operated according to user reservations.

In this embodiment, vehicle dispatch management is performed on a trip basis. A trip refers to a series of operations by a single vehicle, from the time the vehicle departs from the base, through one or more on-demand transit points (departure point (boarding location) or destination (drop-off location)), until it returns to the base at the time of return to the base.

The dispatch management system 1 comprises terminal devices 20-1, 20-2, and 20-3, an in-vehicle unit 30, and a management server 100. Terminal devices 20-1, 20-2, and 20-3, the in-vehicle unit 30, and the management server 100 are connected via a network NW. The network NW is a wireless or wired communication network. This network NW includes the internet and intranets. Specifically, the network NW is an information and communication network composed of WANs (Wide Area Networks), LANs (Local Area Networks), etc. This WAN includes, for example, mobile phone networks, PHS (Personal Handy-phone System) networks, PSTN (Public Switched Telephone Networks), dedicated communication line networks, and VPNs (Virtual Private Networks).

Terminal device 20-1 is used by the user. The user performs a vehicle reservation operation on terminal device 20-1. When reserving a vehicle, the user specifies information identifying the boarding location and information identifying the alighting location. Based on the user's operation, terminal device 20-1 creates a vehicle reservation request, including the vehicle reservation information (demand), addressed to the management server 100. The vehicle reservation information includes information identifying the boarding location and information identifying the alighting location. Terminal device 20-1 sends the created vehicle reservation request to the management server 100.

The management server 100 receives a passenger reservation request transmitted by the terminal device 20-1. The management server 100 stores location information of the bases where vehicles are stationed. The management server 100 retrieves the passenger reservation information contained in the received passenger reservation request and, based on the retrieved passenger reservation information and the stored location information of the bases, searches for a route from the first base to the first or second base, via the boarding and alighting locations.

The management server 100 creates a new vehicle operation schedule based on the route search results, departing from the first base at the first time, passing through the pick-up and drop-off locations, and returning to the first or second base at the second time. The management server 100 determines whether the new operation schedule is feasible based on the created new operation schedule and the existing operation schedules of one or more vehicles already in operation. The management server 100 determines whether a new trip can be formed based on whether the time period of the new demand trip does not overlap with the time period of existing trips.

If the management server 100 determines that the new service schedule is feasible, it creates a passenger reservation response addressed to terminal device 20-1, which contains the new service schedule. The management server 100 then transmits the created passenger reservation response to terminal device 20-1. Terminal device 20-1 receives the passenger reservation response transmitted by the management server 100 and displays the new service schedule included in the received passenger reservation response.

Furthermore, the management server 100 creates a dispatch request addressed to the in-vehicle unit 30, which includes the new operation schedule. The management server 100 sends the created dispatch request to the in-vehicle unit 30. The in-vehicle unit 30 receives the dispatch request sent by the management server 100. If the vehicle VE equipped with the in-vehicle unit 30 is a manually driven vehicle, the in-vehicle unit 30 displays the new operation schedule included in the received dispatch request. If the vehicle VE equipped with the in-vehicle unit 30 is an autonomous vehicle, the in-vehicle unit 30 outputs the new operation schedule included in the received dispatch request to the autonomous driving system of the vehicle VE.

The following describes the terminal devices 20-1, 20-2, 20-3, the in-vehicle unit 30, and the management server 100 included in the dispatch management system 1, in order.

(Terminal device)
Terminal devices 20-1, 20-2, and 20-3 are implemented by, for example, a personal computer, a mobile phone, a tablet, a smartphone, a PHS (Personal Handy-phone System), or a PDA (Personal Digital Assistant).

Terminal device 20-1 is a portable device carried by the user. The user uses terminal device 20-1 to reserve a ride. A ride reservation application is installed on terminal device 20-1. The ride reservation application causes terminal device 20-1 to create ride reservation information based on the user's operations.

There are two types of reservations for bus travel: instant reservations and advance reservations. Instant reservations are for when you wish to board immediately, and require specifying information about your boarding location and your alighting location. Examples of information specifying the boarding and alighting locations include place names and other location-specific information. When an instant reservation is made, the reservation information includes information specifying the boarding location and the alighting location.

On the other hand, advance reservations are made when a passenger wishes to specify a boarding or alighting time. This requires specifying the boarding location, the alighting location, and the desired departure or alighting time. When an advance reservation is made, the reservation information includes the boarding location, the alighting location, and the desired departure or alighting time.

The passenger reservation application causes terminal device 20-1 to create a passenger reservation request, including passenger reservation information, addressed to management server 100. The passenger reservation application then sends the passenger reservation request created by terminal device 20-1 to management server 100. Finally, the passenger reservation application causes terminal device 20-1 to receive the passenger reservation response sent by management server 100 and process the passenger reservation information contained in the received response.

The terminal device 20-2 is a device used, for example, by the person sitting in the driver's seat of a vehicle. For example, the terminal device 20-2 may be fixed to the driver's seat, like a car navigation system. An example of a person sitting in the driver's seat of a vehicle is the driver. However, if the vehicle is an autonomous vehicle, the conductor may use the terminal device 20-2. The terminal device 20-2 has a driving application installed. The driving application causes the terminal device 20-2 to receive information related to the vehicle's operation, such as information identifying the user's boarding location, information identifying the alighting location, and route information, transmitted by the management server 100. Based on the received vehicle operation information, the driving application displays the boarding location, alighting location, and route information on the map displayed on the display unit of the terminal device 20-2.

The operation application causes terminal device 20-2 to perform processing related to vehicle operation. When a location corresponding to a boarding or alighting location on the map displayed on the terminal device 20-2 is pressed, the operation application causes terminal device 20-2 to create operation information destined for the management server 100. This information includes information indicating the time of the press and information indicating the corresponding boarding or alighting location. The operation application then causes terminal device 20-2 to transmit the created operation information to the management server 100.

Terminal device 20-3 is a device used by passengers in a vehicle. For example, terminal device 20-3 may be fixed in the driver's seat, like a car navigation system. Terminal device 20-3 may be used by users who do not normally carry a smartphone or tablet. A vehicle operation status notification management application is installed on terminal device 20-3. The vehicle operation status notification application causes terminal device 20-3 to receive user boarding information, alighting information, and route information transmitted by the management server 100. Based on the received user boarding information, alighting information, and route information, the vehicle operation status notification application displays the boarding and alighting locations and route information on the map displayed on the display unit of terminal device 20-3. However, depending on the environment in which terminal device 20-3 is used, the content displayed on terminal device 20-3 may be restricted to protect privacy.

(onboard equipment)
The in-vehicle unit 30 is installed in the vehicle VE. An in-vehicle application is installed on the in-vehicle unit 30. The in-vehicle application is software that operates within the vehicle VE. The in-vehicle application causes the in-vehicle unit 30 to transmit the vehicle VE's location information and CAN (Controller Area Network) data to the management server 100. If the vehicle VE on which the in-vehicle unit 30 is installed is an autonomous vehicle, the in-vehicle unit 30 cooperates with the vehicle VE's autonomous driving system. In this case, the in-vehicle application causes the in-vehicle unit 30 to receive route information transmitted by the management server 100 and outputs the received route information to the autonomous driving system.

(Management server)
The management server 100 includes a communication unit 102, a reception unit 104, a vehicle dispatch processing unit 106, a route search unit 108, a reservation status management unit 109, and a storage unit 110.

Each function of the management server 100 is realized by the management server 100 being equipped with computer hardware such as a CPU (Central Processing Unit) and memory, and the CPU executing computer programs stored in memory. The management server 100 may be configured using a general-purpose computer device, or it may be configured as dedicated hardware. For example, the management server 100 may be implemented using a personal computer, server, or industrial computer. For example, the management server 100 may be configured using a server computer connected to a communication network such as the Internet. Furthermore, each function of the management server 100 may be implemented using cloud computing. Also, the management server 100 may be implemented by a single computer, or its functions may be distributed across multiple computers. Furthermore, the management server 100 may be configured to launch a website using, for example, a WWW system.

The communication unit 102 is implemented by a communication module. The communication unit 102 communicates with other devices such as terminal devices 20-1, 20-2, 20-3, and the in-vehicle unit 30 via the network NW. The communication unit 102 receives the ride reservation request transmitted by terminal device 20-1. The communication unit 102 also transmits the ride reservation response output by the dispatch processing unit 106 to terminal device 20-1. The communication unit 102 also transmits the dispatch request output by the dispatch processing unit 106 to the in-vehicle unit 30.

The storage unit 110 is implemented using, for example, RAM, ROM, HDD, flash memory, or a hybrid storage device combining multiple of these. The storage unit 110 stores a program (dispatch management application) executed by the management server 100. The storage unit 110 also stores identification information of the vehicle waiting locations (hereinafter referred to as "location ID") and location information of those locations, associated with each other. Furthermore, the storage unit 110 stores various data necessary for the management server 100 to dispatch vehicles. For example, the storage unit 110 stores demand information 110a, vehicle information 110b, user information 110c, and reservation condition identifier information 110d as data necessary for dispatching vehicles.

The demand information 110a includes one or more demand-related pieces of information that associate the user's identification information (hereinafter referred to as "user ID") with the boarding reservation information included in the boarding reservation request transmitted by the user's terminal device 20-1 and the processing status of the boarding reservation. In addition, the demand information 110a has a reservation condition identifier for each demand.
Vehicle information 110b includes one or more vehicle-related pieces of information that associate vehicle identification information (hereinafter referred to as "vehicle ID"), information indicating the vehicle's operating schedule, information indicating the vehicle's capacity, information indicating a waiting location such as a base ID, rest time information, conductor information, current location information, and status information.
User information 110c includes one or more user-related pieces of information that associate information indicating the user's name, information indicating the user's gender, information indicating the user's age, and information indicating the user's status.

The reservation condition identifier information 110d contains the latest reservation condition identifier. The reservation condition identifier is an identifier that identifies a vehicle and time slot, and is assigned to each vehicle and time slot. Therefore, the reservation condition identifier differs for each vehicle. Furthermore, the reservation condition identifier differs for each time slot, even for the same vehicle. Also, the reservation condition identifier is changed according to predetermined update conditions. As a result, the reservation condition identifier information 110d contains the latest reservation condition identifier for each vehicle and time slot. The latest reservation condition identifier for a given vehicle and time slot is the reservation condition identifier currently assigned to that vehicle and time slot.

The reception unit 104 receives the boarding reservation request received by the communication unit 102 and obtains the boarding reservation information included in the received boarding reservation request.
The reservation status management unit 109 obtains the boarding reservation information acquired by the reception unit 104. Based on the boarding reservation information acquired by the reception unit 104, the reservation status management unit 109 executes the demand reservation status management process.

The dispatch processing unit 106 receives a dispatch calculation request along with the passenger reservation information from the reservation status management unit 109. Based on the acquired passenger reservation information, the dispatch processing unit 106 updates the demand information 110a stored in the storage unit 110.

The dispatch processing unit 106 retrieves the following information from the vehicle information 110b stored in the storage unit 110: the vehicle ID included in each of the one or more pieces of vehicle-related information, information indicating the vehicle's operating schedule, information indicating the vehicle's passenger capacity, information indicating the waiting location base, rest time information, current location information, and status information. Based on the retrieved vehicle ID, information indicating the vehicle's operating schedule, information indicating the vehicle's passenger capacity, information indicating the waiting location base, rest time information, current location information, status information, and location information of the base where the vehicle will be kept waiting, the dispatch processing unit 106 determines whether it is possible to dispatch a vehicle that satisfies the passenger reservation information.

The dispatch processing unit 106 processes vehicles that are not currently in operation on the premise that they will wait at the designated base. The dispatch processing unit 106 manages operations on a trip basis. Here, we will explain what a trip is.

Figure 2 is a diagram illustrating an example of a trip. The boarding location (departure point) included in the ride reservation information (demand) is denoted as O (Origin), and the disembarking location (destination) is denoted as D (Destination). The vehicle's arrival time at the boarding location (departure point) is denoted as t _O , and the vehicle's arrival time at the destination is denoted as t _D. The departure time from the base is denoted as t _BS , and the return time to the base is denoted as t _BG . A series of operations in which a vehicle departs the base at time t _BS , passes through each demand's intermediate points (boarding and disembarking locations), and returns to the base at time t _BG is called a trip.

In the example in Figure 2, Trip 1 and Trip 2 are shown. As shown in Figure 2, multiple trips may be formed during a day's operating hours. Trip 1 is a series of operations in which the vehicle departs from base BS1 at time t _BS1 , arrives at boarding location O1 at time t _O1 , arrives at disembarking location D1 at time t _D1 , and returns to base BG1 at time t _BG1 . Trip 2 is a series of operations in which the vehicle departs from base BG2 at time t _BS2 , which is later than time t _BG1 , arrives at boarding location O2 at time t _O2 , arrives at boarding location _O3 at time t _O3 , arrives at disembarking location D2 at time t _D2 , arrives at disembarking location D3 at time t D3, and returns to base BG2 at time t _BG2 .

The dispatch processing unit 106 acquires information identifying the boarding location and information identifying the alighting location, which are included in the ride reservation information. The dispatch processing unit 106 outputs the acquired information identifying the boarding location and alighting location to the route search unit 108.

The route search unit 108 acquires information identifying the boarding location and information identifying the alighting location, which are output by the vehicle dispatch processing unit 106. The route search unit 108 also acquires information associating the base ID of the base where the vehicle is waiting with the base location information, which is stored in the storage unit 110. Based on the acquired information identifying the boarding location, the information identifying the alighting location, the base ID of the base where the vehicle is waiting, and the base location information, the route search unit 108 selects the base ID of the base where the vehicle to be dispatched to the boarding location is waiting, and the base ID of the base the vehicle will go to after the alighting location. The base where the vehicle to be dispatched to the boarding location is waiting and the base the vehicle will go to after the alighting location may be the same or different. The following explanation will continue with the case where a first base is selected as the base where the vehicle to be dispatched to the boarding location is waiting, and a second base is selected as the base the vehicle will go to after the alighting location. Here, the first base and the second base are stored in the storage unit 110.

The route search unit 108 searches for a route from the first base to the second base, via the pick-up and pick-up locations, based on the acquired information identifying the pick-up location, information identifying the pick-up location, the base ID of the first base where the vehicle is waiting, and the location information of the first base. It then derives the time required to travel along that route from the first base to the second base, via the pick-up and pick-up locations.

For example, the route search unit 108 searches for the shortest route from the first base to the second base, via the pick-up and drop-off locations, and derives the time required to travel from the first base to the second base via that route. For example, the route search unit 108 derives the time required to travel from the first base to the pick-up location, from the pick-up location to the drop-off location, and from the drop-off location to the second base. The route search unit 108 outputs information indicating the route search results and information indicating the derived time to the dispatch processing unit 106.

The dispatch processing unit 106 acquires information indicating the route search results output by the route search unit 108 and information indicating the estimated time required. Based on the acquired information indicating the route search results and the estimated time required, the dispatch processing unit 106 determines whether or not dispatching a vehicle is possible.

The dispatch processing unit 106 determines whether it is possible to create a trip for the new demand alone. Specifically, the dispatch processing unit 106 determines whether there is any overlap in the timeline of the trip created for the new demand alone with existing trips. If the dispatch processing unit 106 determines that there is no overlap in the timeline with existing trips, it determines that it is possible to create a trip for the new demand alone and that dispatch is possible.
The following describes the process by which the dispatch processing unit 106 determines whether there are any overlapping parts with existing trips in chronological order.

Figure 3 is a diagram showing an example of the operation of the dispatch management system according to this embodiment. Figure 3 shows an example of a trip. In the trip shown in Figure 3, it is assumed that the vehicle must arrive at the pick-up location _O1 between time t _{O1 min} and time t _{O1 max} , and depart from the pick-up location _O1 at time t O1 max. It is also assumed that the vehicle must arrive at the drop-off location _D1 between time t _{D1 min} and time t _{D1 max} . _TW is the time between the time of departure from the pick-up location and a predetermined time before the departure time. _TW is defined as the waiting time at the demand pick-up location (departure point). _TR is the time between the time that guarantees arrival at the drop-off location (even with additional delays, arrival will be at this time at the latest) and a predetermined time before that time. _TR is the time to absorb delays due to trips that are expected to be added in the future, and is defined as buffer time until arrival. Equations (1) and (2) hold true.
t _O1max - t _O1min = T _W (1)
t _D1max - t _D1min = T _R (2)
From equation (1), the constraint for condition t _O1 is t _{O1 min} ≤ t _O1 ≤ t _{O1 max} . From equation (2), the constraint for t _D1 is t _{D1 min} ≤ t _D1 ≤ t _{D1 max} .

Regarding whether a trip can be formed based solely on a new demand, we will explain this separately for cases where an immediate booking is made and cases where a pre-booking is made.

(If an instant booking is made)
If an immediate reservation is made, the vehicle is assumed to be waiting at the first base. The dispatch processing unit 106 sets the earliest possible departure time of the vehicle waiting at the first base as t _BS , and forms a trip by sequentially adding the travel time between each point output by the route search unit 108 to time t _BS for the remaining times t _O1 , t _D1 , and t _BG . At this time, the dispatch processing unit 106 sets time t _{O1 max} as time t _O1 at this point, and time t _{D1 min} as time t _D1 at this point.

(Advance reservation required)
Regarding whether a trip can be formed as a standalone new demand when a reservation has been made in advance, we will explain this separately for cases where a desired departure time is specified and cases where a desired arrival time is specified.
If a desired departure time is specified, the dispatch processing unit 106 sets the desired departure time as t _O1 and the departure time from the first base to arrive at boarding point _O1 at time t _O1 as t _BS . The remaining times t _D1 and t _BG are formed by sequentially adding the travel times between each point output by the route search unit 108 to time t _BS , similar to the case of instant booking, to form the trip.
If a desired arrival time is specified, the dispatch processing unit 106 sets the desired arrival time as t _D1max and the time t _D1min determined by the arrival time t _D1max as t _D1 . The remaining times t _BS , t _O1 , and t _BG are formed by subtracting the travel time between each point output by the route search unit 108 from time t _D1 in the same way as in the case of immediate booking, thereby forming the trip.

From the above, it can be seen that, in both cases—whether immediate booking or advance booking—the formation of a trip based on a new demand alone is represented by the time-series relationship shown in Figure 3.

The dispatch processing unit 106 determines whether a trip is valid for a new demand on its own. Specifically, the dispatch processing unit 106 determines whether the time period from tBS to tBG of the trip for the new demand on its own overlaps with the time period of an existing trip.
The dispatch processing unit 106 determines that dispatch is possible if the time period tBS to tBG of the new demand trip does not overlap with the time period of an existing trip, and therefore a trip can be formed for the new demand trip alone. If the dispatch processing unit 106 determines that dispatch is possible, it creates a ride reservation response addressed to the terminal device 20-1, which includes information indicating that dispatch is possible, information identifying the trip, and information indicating the reservation status of the demand. The reservation status of the demand will be described later. The dispatch processing unit 106 outputs the created ride reservation response to the communication unit 102.
When the dispatch processing unit 106 determines that dispatch is possible and the reservation status of the relevant demand is "confirmed," it creates a dispatch request addressed to the in-vehicle unit 30, which includes information identifying the trip. The dispatch processing unit 106 outputs the created dispatch request to the communication unit 102.

The dispatch processing unit 106 determines that dispatching is impossible if the time period tBS to tBG of a new demand-only trip overlaps with the time period of an existing trip, making it impossible to form a trip for the new demand-only trip. If the dispatch processing unit 106 determines that dispatching is impossible, it creates a ride reservation response addressed to terminal device 20-1, including information indicating that dispatching is impossible. The dispatch processing unit 106 outputs the created ride reservation response to the communication unit 102.

(Reservation Status Management Department, Vehicle Dispatch Reservation Management Method)
The reservation status management unit 109 and the vehicle dispatch reservation management method according to this embodiment will be described in detail below.
Figure 4 is an explanatory diagram of the demand reservation status and status transitions according to this embodiment. As shown in Figure 4, there are four types of demand reservation statuses: "Unconfirmed,""TentativelyConfirmed,""Confirmed," and "Cancelled."

The reservation status management unit 109 executes demand reservation status management processing based on the boarding reservation information received by the reception unit 104.
If the reservation status management unit 109 receives a request for ride reservation information from the reception unit 104 for "new reservation creation," it sends a dispatch calculation request to the dispatch processing unit 106. The dispatch processing unit 106 searches for a vehicle that meets the ride reservation information based on trips consisting of existing "confirmed" reservation demands. If a suitable vehicle is found, the reservation status management unit 109 generates new demand information as a "pending" reservation demand and stores the generated new demand information in the storage unit 110.

If the reservation status management unit 109 receives a request for boarding reservation information from the reception unit 104 that specifies a "tentative reservation confirmation" for a "pending" reservation status, it checks whether the predetermined transition conditions are met, and then changes the reservation status of that demand from "pending" to "tentatively confirmed."

The reservation status management unit 109, upon receiving a request for boarding reservation information from the reception unit 104, if it specifies a "reservation confirmed" reservation for a demand with a "provisionally confirmed" reservation status, checks whether the predetermined transition conditions are met, and then changes the reservation status of that demand from "provisionally confirmed" to "confirmed."

The reservation status management unit 109 changes the reservation status of the specified demand to "cancelled" if the reservation information request received by the reception unit 104 is for a reservation cancellation.

Here, with reference to Figure 5, an example of the reservation state transition processing performed by the reservation state management unit 109 according to this embodiment will be explained. Figure 5 is an explanatory diagram of an example of a reservation state transition according to this embodiment. Figure 5 shows an example where two reservations (reservation 1 and reservation 2) from two users are for the same vehicle and the same time slot, and were made at approximately the same time.

First, the demand R1 for reservation 1, received at reception desk 104, becomes an "unconfirmed" reservation via new reservation creation R1a. At this "unconfirmed" stage, the demand R1 for reservation 1 does not restrict other reservations. Therefore, the demand R2 for reservation 2, immediately received at reception desk 104, similarly becomes an "unconfirmed" reservation via new reservation creation R2a. Next, the demand R1 for reservation 1 transitions to a "provisionally confirmed" reservation state via provisional reservation confirmation R1b. At this point, the "provisionally confirmed" demand R1 for reservation 1 restricts the transition of other reservations to ensure the transition from "provisionally confirmed" to "confirmed." Specifically, if a "provisionally confirmed" demand exists, other demands for the same vehicle and time slot are restricted from transitioning from the "unconfirmed" to "provisionally confirmed" state.

Therefore, in the example in Figure 5, the demand R2 for reservation 2 is received by the reception unit 104 immediately after the provisional confirmation R1b of reservation 1. However, due to the constraint imposed by the demand R1 of reservation 1, which is in the "provisionally confirmed" state, the transition from the "unconfirmed" to "provisionally confirmed" state fails. On the other hand, the demand R1 of reservation 1, which is in the "provisionally confirmed" state, transitions to the "confirmed" reservation state upon the reservation confirmation R1c received by the reception unit 104, and the trip information for the demand R1 of reservation 1 in the demand information 110a managed by the storage unit 110 is updated.

Next, we will explain the transition conditions and transition processes for the reservation state.
(Generating a demand with a reservation status of "Unconfirmed")
The condition for allowing the generation of a "Not Confirmed" reservation status demand is that the dispatch processing unit 106 finds a vehicle that satisfies the ride reservation information. The dispatch processing unit 106 searches for a vehicle that satisfies the ride reservation information (dispatch search) based on trips consisting of existing "Confirmed" reservation status demands. Therefore, if the dispatch processing unit 106 finds a vehicle that satisfies the ride reservation information, the trip for the new demand alone will not overlap with the trip consisting of a "Confirmed" reservation status demand. The process for generating a "Not Confirmed" reservation status demand involves generating a new demand and registering it in the storage unit 110 as "Not Confirmed," obtaining a reservation condition identifier (reservation condition ID) that identifies the vehicle (vehicle and time slot) for the new demand found by the dispatch processing unit 106 from the reservation condition identifier information 110d, and recording the obtained reservation condition identifier in the demand information 110a as the reservation condition identifier for the new demand.

(Transition from reservation status "Unconfirmed" to "Tentatively Confirmed")
The conditions for allowing a demand with a reservation status of "unconfirmed" (target demand) to transition to a reservation status of "provisionally confirmed" are that there are no other demands of the same vehicle and time slot as the target demand that have a reservation status of "provisionally confirmed", and that the reservation condition identifier currently assigned to the vehicle and time slot of the target demand matches the reservation condition identifier of the target demand in the demand information 110a. The reservation condition identifier currently assigned to a vehicle and time slot is the reservation condition identifier of that vehicle and time slot in the reservation condition identifier information 110d. The process of transitioning a target demand with a reservation status of "unconfirmed" to a reservation status of "provisionally confirmed" involves changing the registration of the reservation status of the target demand from "unconfirmed" to "provisionally confirmed".

(Transition from reservation status "tentatively confirmed" to "confirmed")
The conditions for allowing a demand (target demand) with a reservation status of "provisionally confirmed" to transition to a reservation status of "confirmed" are unconditional. The process of transitioning a demand (target demand) with a reservation status of "provisionally confirmed" to a reservation status of "confirmed" involves changing the reservation condition identifier currently assigned to the vehicle and time slot of the target demand to a new reservation condition identifier, and updating the trip information in the demand information 110a that includes the target demand. The process of changing a reservation condition identifier currently assigned to a vehicle and time slot to a new reservation condition identifier involves changing the reservation condition identifier of the vehicle and time slot in the reservation condition identifier information 110d to a new reservation condition identifier.

(Transition from reservation status "Unconfirmed,""TentativelyConfirmed," and "Confirmed" to "Cancelled")
The conditions for allowing a reservation status of "Unconfirmed,""TentativelyConfirmed," and "Confirmed" (target demand) to be changed to a reservation status of "Cancelled" are unconditional. The process of changing a reservation status of "Unconfirmed,""TentativelyConfirmed," and "Confirmed" (target demand) to a reservation status of "Cancelled" involves deregistering the target demand. Furthermore, the process of changing a reservation status of "Confirmed" (target demand) to a reservation status of "Cancelled" involves changing the reservation condition identifier currently assigned to the vehicle and time slot of the target demand to a new reservation condition identifier, and updating the trip information in the demand information 110a that includes the target demand.

Furthermore, a condition for the reservation confirmation grace period may be added to the above-mentioned reservation state transition conditions. This reservation confirmation grace period condition sets an upper limit (reservation confirmation grace period) on the elapsed time from when a "unconfirmed" reservation state demand is generated until that demand transitions to a "confirmed" reservation state. The reservation state management unit 109 measures the elapsed time from when a "unconfirmed" reservation state demand is generated, and includes the condition that the measured elapsed time is less than or equal to the predetermined reservation confirmation grace period when transitioning between reservation states of that demand, i.e., when transitioning from "unconfirmed" to "provisionally confirmed" or from "provisionally confirmed" to "confirmed".

Next, we will explain the reservation condition identifier in detail.
The reservation condition identifier is an identifier that identifies the vehicle and time slot, and is assigned to each vehicle and time slot. Therefore, the reservation condition identifier is different for each vehicle. Furthermore, the reservation condition identifier will be different for each time slot, even for the same vehicle. An example of a reservation condition identifier is the combination of the vehicle ID of the vehicle to which it is assigned and the current time when the reservation condition identifier is updated (new assignment or change of existing value).

The reservation condition identifier functions as a flag to confirm that there have been no changes to the trip corresponding to the vehicle and time slot of a new demand, from the time the dispatch processing unit 106 performs a dispatch search to generate a new demand with a reservation status of "unconfirmed." This point will be explained below.

In this embodiment, it is guaranteed that a demand in the reservation state "provisionally confirmed" can transition from the reservation state "provisionally confirmed" to "confirmed".
On the other hand, new demands with a reservation status of "unconfirmed" can be generated if they do not overlap with trips (vehicles and time slots) consisting of demands with a reservation status of "confirmed" as determined by the dispatch processing unit 106's dispatch search. In other words, even if the vehicle and time slot of a new demand with a reservation status of "unconfirmed" overlap with a trip (vehicles and time slots) consisting of demands with a reservation status of "tentatively confirmed" at the time of generation of the new demand, the new demand can still be generated. This is because, since users do not necessarily confirm reservations with a reservation status of "tentatively confirmed," the generation of new demands with a reservation status of "unconfirmed" is not restricted by demands with a reservation status of "tentatively confirmed" in order to respond to the dispatch search needs of other users, thereby expanding the opportunities for generating new demands with a reservation status of "unconfirmed."
To ensure both the transition of "provisionally confirmed" demands to "confirmed" and the expansion of opportunities for generating new "unconfirmed" demands, reservation condition identifiers are used.

Referring to Figure 6 as a specific example, the method of using the reservation condition identifier in the reservation state transition processing performed by the reservation state management unit 109 will be explained. Figure 6 is an explanatory diagram of an example of a reservation state transition according to this embodiment. Similar to Figure 5, Figure 6 shows an example where two reservations (Reservation 1 and Reservation 2) from two users are for the same vehicle and the same time slot, and were made at approximately the same time.

First, the demand R1 of reservation 1, received by the reception unit 104, becomes an "unconfirmed" reservation due to the creation of a new reservation R1a. At this time, the reservation status management unit 109 retrieves the reservation condition identifier Rid1 currently assigned to the vehicle (vehicle and time slot) for the vehicle dispatch processing unit 106 from the reservation condition identifier information 110d, and records the retrieved reservation condition identifier as the reservation condition identifier for the demand R1 of reservation 1 in the demand information 110a. At this "unconfirmed" reservation stage, the demand R1 of reservation 1 does not restrict other reservations.

Next, demand R2 of reservation 2, which was received by the reception unit 104 immediately after reservation 1, becomes an "unconfirmed" reservation status due to new reservation creation R2a. At this time, the reservation status management unit 109 retrieves the reservation condition identifier Rid1 currently assigned to the vehicle (vehicle and time slot) for demand R2 of reservation 2 found by the dispatch processing unit 106 from the reservation condition identifier information 110d, and records the retrieved reservation condition identifier as the reservation condition identifier for demand R2 of reservation 2 in the demand information 110a. Therefore, at this point, the same reservation condition identifier Rid1 is recorded in the demand information 110a for both demand R1 of reservation 1 and demand R2 of reservation 2, for which the same vehicle (vehicle and time slot) was found.

At this stage, the reservation status management unit 109 may also notify the terminal device 20-1 of each user who has made a reservation for a "unconfirmed" on-demand vehicle that there is a competition among multiple users for such reservations.
For example, if there are multiple "unconfirmed" demands R1 and R2 with the same reservation condition identifier, Rid1, currently assigned to the vehicle and time slot, as recorded in the demand information 110a, the reservation status management unit 109 may notify the terminal devices 20-1 of each user of all "unconfirmed" demands R1 and R2 that multiple users have made reservations for vehicle dispatch with an "unconfirmed" reservation status. This allows the unit to notify each user of all "unconfirmed" demands R1 and R2 that there is currently a competition among multiple users for that "unconfirmed" vehicle dispatch reservation.
For example, if there is at least one "unconfirmed" demand R1 in the demand information 110a with the same reservation condition identifier Rid1 as the reservation condition identifier Rid1 currently assigned to the vehicle (vehicle and time slot) to be reserved, the reservation status management unit 109 may notify the terminal device 20-1 of the user of another "unconfirmed" demand R2 in the demand information 110a, informing them that multiple users have made a reservation for a vehicle in the "unconfirmed" state. This allows the user of the new "unconfirmed" demand R2 to be notified that there is currently a competition among multiple users for that "unconfirmed" vehicle reservation.

Next, Demand R1 of Reservation 1 transitions to the "Provisionally Confirmed" reservation state by Reservation Provisional Confirmation R1b. At this time, the Reservation State Management Unit 109 confirms that Demand R1 of Reservation 1 satisfies the transition conditions from the "Unconfirmed" reservation state to the "Provisionally Confirmed" reservation state. As described above, these transition conditions are "Condition A1: There are no other demands of the same vehicle and time slot as the target demand R1 in the "Unconfirmed" reservation state that are in the "Provisionally Confirmed" reservation state" and "Condition B1: The reservation condition identifier currently assigned to the vehicle and time slot of the target demand R1 matches the reservation condition identifier Rid1 of the target demand R1 in the demand information 110a." At this point, Demand R2 of Reservation 2 is still in the "Unconfirmed" reservation state, so Condition A1 is satisfied. Furthermore, at this point, the reservation condition identifier currently assigned to the vehicle and time slot for Reservation 1's Demand R1 is "Rid1," so condition B1 is also satisfied. Therefore, since the transition condition is met, the reservation status management unit 109 changes the reservation status registration for Reservation 1's Demand R1 from "Unconfirmed" to "Tentatively Confirmed."

Next, Demand R1 of Reservation 1, which has entered the "Provisionally Confirmed" reservation state, transitions to the "Confirmed" reservation state upon confirmation R1c received by the reception unit 104. At this time, the reservation status management unit 109 changes the reservation condition identifier "Rid1" currently assigned to the vehicle and time slot of Demand R1 of Reservation 1 to a new reservation condition identifier "Rid1'", and updates the corresponding information in Demand Information 110a with the changed reservation condition identifier "Rid1'" as the reservation condition identifier for Demand R1 of Reservation 1. The process of changing the reservation condition identifier "Rid1" currently assigned to the vehicle and time slot of Demand R1 of Reservation 1 to a new reservation condition identifier "Rid1'" involves changing the reservation condition identifier "Rid1" for the vehicle and time slot in the reservation condition identifier information 110d to the new reservation condition identifier "Rid1'".

Next, for Reservation 2, Demand R2 is received by the reception unit 104 as a request for provisional reservation confirmation immediately after Reservation 1's reservation confirmation R1c. At this time, the reservation status management unit 109 confirms that Reservation 2's Demand R2 satisfies the transition conditions from reservation status "unconfirmed" to "provisionally confirmed". As described above, these transition conditions are "Condition A2: There are no other demands with the same vehicle and time slot as the target demand R2 in reservation status "unconfirmed" that have a reservation status of "provisionally confirmed"" and "Condition B2: The reservation condition identifier currently assigned to the vehicle and time slot of the target demand R2 matches the reservation condition identifier Rid1 of the target demand R2 in the demand information 110a". At this point, Reservation 1's Demand R1 is in reservation status "confirmed", and there are no other demands with the same vehicle and time slot as Reservation 2's Demand R2 that have a reservation status of "provisionally confirmed", so Condition A2 is satisfied. On the other hand, at this point, the reservation condition identifier currently assigned to the vehicle and time slot of Reservation 2's Demand R2 (i.e., the reservation condition identifier for that vehicle and time slot in the reservation condition identifier information 110d) has changed to "Rid1'", and therefore does not match the reservation condition identifier Rid1 for Demand R2 in the demand information 110a. Consequently, condition B2 is not met. Therefore, since the transition condition is not met, the reservation status management unit 109 does not transition the reservation status of Reservation 2's Demand R2 from "Unconfirmed" to "Tentatively Confirmed". The reservation status management unit 109 then notifies the user's terminal device 20-1 of Reservation 2 that the vehicle dispatch reservation for Reservation 2 cannot be transitioned from the reservation status "Unconfirmed" to "Tentatively Confirmed".

In the example shown in Figure 6, the demand R2 for reservation 2 satisfies condition A2: "There are no other demands with the same vehicle and time slot as the target demand R2, which is in the 'unconfirmed' state, that are in the 'provisionally confirmed' state." This is because the other demand R1, which uses the same vehicle and time slot as the target demand R2, transitioned from the 'provisionally confirmed' state to the 'confirmed' state. Therefore, in this case, the target demand R2 should not be transitioned from the 'unconfirmed' state to the 'provisionally confirmed' state. This is because if the target demand R2 is transitioned from the 'unconfirmed' state to the 'provisionally confirmed' state, it becomes necessary to guarantee that the target demand R2 can transition from the 'provisionally confirmed' state to the 'confirmed' state, which could lead to the possibility of the vehicle dispatch reservation for reservation 2 overlapping with the vehicle dispatch reservation for reservation 1, which has already been confirmed.

Therefore, in this embodiment, when a demand R1 in the "provisionally confirmed" reservation state transitions to the "confirmed" reservation state, the reservation condition identifier "Rid1" currently assigned to the vehicle and time slot of demand R1 is changed to a new reservation condition identifier "Rid1'". Furthermore, as a transition condition for transitioning demand R2 of reservation 2 from the "unconfirmed" reservation state to the "provisionally confirmed" state, "Condition B2: The reservation condition identifier currently assigned to the vehicle and time slot of the target demand matches the reservation condition identifier of the target demand in the demand information 110a." As a result, even if condition A2 is met, demand R2 of reservation 2 will not meet condition B2 and will not transition from the "unconfirmed" reservation state to the "provisionally confirmed" state. This prevents reservation 2 from being confirmed in conjunction with reservation 1, which has already been confirmed.

Thus, according to this embodiment, by using a reservation condition identifier, it is possible to achieve the exceptional effect of simultaneously guaranteeing the state transition from a "provisionally confirmed" reservation to a "confirmed" reservation, and satisfying the opportunity to generate new "unconfirmed" reservations.

Figure 7 is an explanatory diagram illustrating the correspondence between trips and reservation condition identifiers according to this embodiment. Reservation condition identifiers are assigned to each vehicle and time slot; however, in the example shown in Figure 7, time slots are defined in 30-minute intervals. Therefore, for each vehicle, a different value is assigned to the reservation condition identifier for each 30-minute time slot. Furthermore, a different value is assigned to the reservation condition identifier for each vehicle. Consequently, the reservation condition identifier information 110d contains the most up-to-date reservation condition identifier for each vehicle and each 30-minute time slot.

The trip J1 shown in Figure 7(1) applies to a single vehicle, VE_1, and spans two time periods: "13:00 to 13:30" and "13:30 to 14:00". Therefore, trip J1 is associated with reservation condition identifiers corresponding to the time period "13:00 to 13:30" and "13:30 to 14:00" for the target vehicle, VE_1.

The trip J2 shown in Figure 7(2) applies to a single vehicle, VE_2, and is set to span three time periods: "13:00 to 13:30", "13:30 to 14:00", and "14:00 to 14:30". Therefore, trip J2 is associated with reservation condition identifiers corresponding to the time periods "13:00 to 13:30", "13:30 to 14:00", and "14:00 to 14:30" for the target vehicle VE_2.

The reservation status management unit 109 refers to the reservation condition identifier associated with the target trip when a new demand is generated or when the reservation status of an existing demand changes.

The above is a detailed explanation of the reservation status management unit 109.

(How to book a ride)
Next, the vehicle reservation method according to this embodiment will be explained using an example of a screen displayed on the display device (e.g., a touch panel) of the terminal device 20-1. Figures 8 to 13 show examples of the configuration of the display screen of the terminal device according to this embodiment.

The screens shown in Figures 8-13 are generated based on the dispatch reservation data transmitted between the terminal device 20-1 and the management server 100. The display data for the screens shown in Figures 8-13 may be generated by the terminal device 20-1, or it may be generated by the management server 100 and transmitted to the terminal device 20-1.

Figure 8 shows an example of the initial state of the vehicle reservation screen 400.
In the dispatch reservation screen 400 of Figure 8, the display section 401 shows the user information of the user making the reservation (user ID, registration date, name, nickname, gender, age group, phone number, email address, home address, remarks, etc.).

In display section 402, users can select options related to ride-hailing searches. Radio buttons allow selection between "Cart Only" and "Integrated Search." If the user selects "Cart Only," the search will use only on-demand vehicles. Conversely, if the user selects "Integrated Search," the search will include ride-hailing options combining on-demand vehicles with other public transport. Furthermore, the information selected in the "Refuse Ride-Sharing" checkbox and the "Number of Passengers" dropdown list in display section 402 is used in the ride-hailing search process.

In display section 403, the user selects the departure point and destination and specifies the time (instant booking, desired departure time, desired arrival time). The departure point and destination can be specified by searching in the input form, specifying the home address using the home input button, or selecting from the map displayed in display section 404.
The display section 405 is equipped with a vehicle dispatch search button, a search results display area, a provisional confirmation button, and a cancel button.

In the dispatch reservation screen 400 shown in Figure 8, when a user enters the necessary information in the display sections 402 and 403 and then presses the dispatch search button, the ride reservation information, including the entered information, is sent from the terminal device 20-1 to the management server 100 as a ride reservation request. In the management server 100, the reservation status management unit 109 performs a dispatch search from the dispatch processing unit 106 in response to a request to create a new reservation based on the ride reservation information obtained via the reception unit 104.

Figure 9 shows an example of the dispatch reservation screen 400 when a suitable dispatch is found through the dispatch search. Since a suitable dispatch was found through the dispatch search, the reservation status management unit 109 creates a new demand with a reservation status of "Unconfirmed" at this stage.

In the dispatch reservation screen 400 shown in Figure 9, the display section 405 displays the estimated departure time, estimated arrival time, departure location information, destination information, number of passengers, and vehicle ID of possible dispatches found through the dispatch search in the search results display field, and also displays a provisional confirmation button and a cancel button. Furthermore, the map in the display section 404 displays the route from the departure location to the destination corresponding to the information displayed in the display section 405. If the cancel button is pressed at this stage, this operation information is transmitted from the terminal device 20-1 to the management server 100, and the reservation status management unit 109 changes the reservation status of the demand from "unconfirmed" to "cancelled" in response to the cancellation request based on this operation information.

On the other hand, Figure 10 shows an example of the dispatch reservation screen 400 when no available dispatches are found through the dispatch search. In this case, no new demand is created, and when the user presses the OK button, the initial state of the dispatch reservation screen 400 shown in Figure 8 is displayed again.

In the dispatch reservation screen 400 shown in Figure 9, when the user presses the provisional confirmation button, the ride reservation information, including the operation information, is sent from the terminal device 20-1 to the management server 100 as a ride reservation request. In the management server 100, the reservation status management unit 109, in response to the provisional confirmation request based on the ride reservation information obtained via the reception unit 104, confirms that the conditions for transitioning from the reservation status "unconfirmed" to "provisionally confirmed" are met, and then changes the reservation status of the demand from "unconfirmed" to "provisionally confirmed."

Figure 11 shows an example of the dispatch reservation screen 400 when the demand reservation status is changed to "provisionally confirmed." In the dispatch reservation screen 400 of Figure 11, buttons for confirming the reservation ("Yes") and canceling the reservation ("No") are provided at the end of the display section 405. If the "No" button is pressed at this stage, this operation information is transmitted from the terminal device 20-1 to the management server 100. The reservation status management unit 109 then changes the reservation status of the demand from "provisionally confirmed" to "cancelled" in response to the cancellation request based on this operation information.

In the dispatch reservation screen 400 shown in Figure 11, when the user presses the button to confirm the reservation ("Yes"), the ride reservation information, including the operation information, is sent from the terminal device 20-1 to the management server 100 as a ride reservation request. In the management server 100, the reservation status management unit 109 changes the reservation status of the demand from "Provisional Confirmation" to "Confirmed" in response to the reservation confirmation request based on the ride reservation information obtained via the reception unit 104.

Figure 12 shows an example of the dispatch reservation screen 400 when the demand reservation status is changed to "Confirmed." The dispatch reservation screen 400 in Figure 12 displays a confirmation of the reservation and then displays buttons to select the next screen to display ("Back to Top," "Continue").

Figure 13 shows an example of a screen configuration displaying reservation information for a demand with a reservation status of "Confirmed." Users can view detailed information about a reservation for a demand with a reservation status of "Confirmed" using the reservation status details screen shown in Figure 13. Furthermore, users can cancel the reservation for a demand with a reservation status of "Confirmed" using the reservation cancellation button provided on the reservation status details screen shown in Figure 13. When the reservation cancellation button is pressed on the reservation status details screen in Figure 13, this operation information is transmitted from the terminal device 20-1 to the management server 100. The reservation status management unit 109 then changes the reservation status of the demand from "Confirmed" to "Cancelled" in response to the cancellation request based on this operation information.

As described above, according to this embodiment, in a demand-type dispatch management system that operates vehicles according to reservations, the reservation status of a demand is set to "Unconfirmed," "Tentatively Confirmed," and "Confirmed." The reservation status of "Unconfirmed" for a demand is a state in which there are no restrictions on dispatch searches and reservation status transitions for other demands other than the demand in question. The reservation status of "Tentatively Confirmed" for a demand is a state in which there are no restrictions on dispatch searches for other demands other than the demand in question, but there are restrictions on the transition from the reservation status of "Unconfirmed" to "Tentatively Confirmed" for other demands other than the demand in question. The "Confirmed" state is a state in which dispatch searches for other demands besides the one in question are restricted. The system includes a reservation condition identifier information storage unit (reservation condition identifier information 110d of storage unit 110) which stores the latest reservation condition identifier for each vehicle and time slot, a demand information storage unit (demand information 110a of storage unit 110) which stores demand-related information indicating each user's demand and a reservation condition identifier for each demand, and a reservation status management unit which manages the reservation status of demands and transitions the reservation status of demands according to user requests. The transition conditions that permit the transition of a demand's reservation status from "unconfirmed" to "provisionally confirmed" are that there are no other demands with the same vehicle and time slot as the target demand that have a reservation status of "provisionally confirmed", and that the reservation condition identifier currently assigned to the vehicle and time slot of the target demand matches the reservation condition identifier of the target demand in the demand information storage unit. The reservation status management unit records new demands for which the dispatch search was successful as having a reservation status of "unconfirmed", and records the reservation condition identifier currently assigned to the vehicle and time slot of demands with a reservation status of "unconfirmed". The reservation condition identifier in the separate information storage unit is stored in the demand information storage unit as the reservation condition identifier for the demand. When a demand with a reservation status of "provisionally confirmed" transitions to a reservation status of "confirmed," the reservation status management unit changes the reservation condition identifier currently assigned to the vehicle and time slot of that demand in the reservation condition identifier information storage unit to a new reservation condition identifier. The reservation status management unit then determines, based on the transition conditions, whether or not to transition the reservation status of the target demand from "unconfirmed" to "provisionally confirmed," and changes the reservation status of the target demand to "provisionally confirmed" according to the result of this determination.

With the configuration of this embodiment, users who are interested in on-demand transportation but do not intend to confirm a reservation and wish to search for available rides can freely create a "pending" demand and check the ride search results. Furthermore, users who intend to confirm a reservation can change their "pending" demand to a "provisionally confirmed" reservation, then check the estimated departure time from the departure point and the estimated arrival time at the destination, and then confidently change the "provisionally confirmed" demand to a "confirmed" reservation without the risk of reservation overlap. Thus, this embodiment provides the effect of achieving reservation status management that balances flexible ride searching with measures to prevent reservation overlap in a demand-type ride-hailing management system that operates vehicles according to reservations.

Furthermore, this will enable improvements in overall service quality, such as in on-demand transportation services, thereby contributing to Goal 9 of the United Nations' Sustainable Development Goals (SDGs): "Build resilient infrastructure, promote sustainable industrialization and foster innovation."

The embodiments of the present invention have been described in detail above with reference to the drawings. However, the specific configuration is not limited to these embodiments, and design modifications and other changes that do not depart from the spirit of the present invention are also included.

Alternatively, computer programs for realizing the functions of each of the above-mentioned devices may be recorded on a computer-readable recording medium, and the programs recorded on this recording medium may be loaded into a computer system and executed. Note that the term "computer system" here may include hardware such as an operating system and peripheral devices.
Furthermore, "computer-readable recording media" refers to writable non-volatile memory such as flexible disks, magneto-optical disks, ROMs, and flash memory, portable media such as DVDs (Digital Versatile Discs), and storage devices such as hard disks built into computer systems.

Furthermore, "computer-readable recording media" also includes volatile memory (such as DRAM (Dynamic Random Access Memory)) within computer systems that act as servers or clients when programs are transmitted via networks such as the Internet or communication lines such as telephone lines, which retain programs for a certain period of time.
Furthermore, the above program may be transmitted from a computer system that stores the program in a memory device or the like to another computer system via a transmission medium or by transmission waves within the transmission medium. Here, the "transmission medium" for transmitting the program refers to a medium that has the function of transmitting information, such as a network (communication network) like the Internet or a communication line (communication line) like a telephone line.
Furthermore, the above program may be intended to implement some of the functions described above. It may also be a so-called differential file (differential program) that can implement the aforementioned functions in combination with programs already recorded in the computer system.

1…Dispatch Management System, 20-1, 20-2, 20-3…Terminal Devices, 30…In-vehicle Devices, 100…Management Server, 102…Communication Unit, 104…Reception Unit, 106…Dispatch Processing Unit, 108…Route Search Unit, 109…Reservation Status Management Unit, 110…Storage Unit, 110a…Demand Information, 110b…Vehicle Information, 110c…User Information, 110d…Reservation Condition Identifier Information, VE…Vehicle, NW…Network

Claims (7)

In a demand-based dispatch management system that operates vehicles according to reservations,
The demand reservation status is divided into "First State" and "Second State".
The "First State" of a demand booking status means that there are no restrictions on the dispatch search and booking status transitions for other demands besides the one in question.
The "second state" of a demand booking does not restrict dispatch searches for other demands, but it does restrict the transition of other demands from the "first state" to the "second state."
It includes a reservation status management unit that manages the reservation status of demand and transitions the reservation status of demand in accordance with user requests.
The transition condition that allows the reservation status of the target demand to change from "first state" to "second state" includes the condition that there are no other demands of the same vehicle and time slot as the target demand that are in "second state" reservation status.
The reservation status management unit determines whether or not to transition the reservation status of the target demand from "first state" to "second state" based on the transition conditions, and changes the reservation status of the target demand to "second state" according to the result of the determination.
The aforementioned reservation status management unit can generate a new demand in reservation status "first status" even if the vehicle and time slot of the new demand overlap with the vehicle and time slot of other demands in reservation status "second status".
Vehicle dispatch management system. The "third state" of a demand booking is a state that restricts the dispatch search for other demands besides the one in question.
A reservation condition identifier is assigned to each vehicle and time slot.
A reservation condition identifier information storage unit stores the latest reservation condition identifier for each vehicle and time slot,
The system further includes a demand information storage unit that stores demand-related information indicating the demand of each user and a reservation condition identifier for each demand,
The transition conditions that permit the transition of the reservation status of the target demand from "first state" to "second state" are that there are no other demands of the same vehicle and time slot as the target demand whose reservation status is "second state", and that the reservation condition identifier in the reservation condition identifier information storage unit currently assigned to the vehicle and time slot of the target demand matches the reservation condition identifier of the target demand in the demand information storage unit.
When a demand in reservation state "second state" transitions to reservation state "third state", the reservation state management unit changes the reservation condition identifier currently assigned to the vehicle and time slot of the said demand in the reservation condition identifier information storage unit to a new reservation condition identifier.
The dispatch management system according to claim 1. The "third state" of a demand booking is a state that restricts the dispatch search for other demands besides the one in question.
The "fourth state" of a demand reservation indicates that a request to cancel the reservation for that demand has been received.
A reservation condition identifier is assigned to each vehicle and time slot.
A reservation condition identifier information storage unit stores the latest reservation condition identifier for each vehicle and time slot,
The system further includes a demand information storage unit that stores demand-related information indicating the demand of each user and a reservation condition identifier for each demand,
The transition conditions that permit the transition of the reservation status of the target demand from "first state" to "second state" are that there are no other demands of the same vehicle and time slot as the target demand whose reservation status is "second state", and that the reservation condition identifier in the reservation condition identifier information storage unit currently assigned to the vehicle and time slot of the target demand matches the reservation condition identifier of the target demand in the demand information storage unit.
When a demand in reservation state "third state" transitions to reservation state "fourth state", the reservation state management unit changes the reservation condition identifier currently assigned to the vehicle and time slot of the said demand in the reservation condition identifier information storage unit to a new reservation condition identifier.
The dispatch management system according to claim 1. The reservation status management unit measures the elapsed time since the creation of a "first state" reservation, and includes as a transition condition for each reservation status of the said demand that the elapsed time is less than or equal to a predetermined reservation confirmation grace period.
The dispatch management system according to claim 1. The aforementioned reservation status management unit notifies the terminal device of the user of the demand reservation in "First Status" that there is a competition among multiple users for the same reservation status.
The dispatch management system according to claim 1. A dispatch reservation management method implemented by a demand-type dispatch management system that operates vehicles according to reservations,
The demand reservation status is divided into "First State" and "Second State".
The "First State" of a demand booking status means that there are no restrictions on the dispatch search and booking status transitions for other demands besides the one in question.
The "second state" of a demand booking does not restrict dispatch searches for other demands, but it does restrict the transition of other demands from the "first state" to the "second state."
Includes a reservation status management step that manages the reservation status of demand and transitions the reservation status of demand in response to user requests.
The transition condition that allows the reservation status of the target demand to change from "first state" to "second state" includes the condition that there are no other demands of the same vehicle and time slot as the target demand that are in "second state" reservation status.
The reservation status management step determines whether or not to transition the reservation status of the target demand from "first state" to "second state" based on the transition conditions, and changes the reservation status of the target demand to "second state" according to the result of the determination.
The aforementioned reservation status management step allows for the creation of a new demand in reservation status "first status" even if the vehicle and time slot of the new demand overlap with the vehicle and time slot of other demands in reservation status "second status".
How to manage vehicle dispatch reservations. The computer in the on-demand dispatch management system that operates vehicles according to reservations,
The demand reservation status is divided into "First State" and "Second State".
The "First State" of a demand booking status means that there are no restrictions on the dispatch search and booking status transitions for other demands besides the one in question.
The "second state" of a demand booking does not restrict dispatch searches for other demands, but it does restrict the transition of other demands from the "first state" to the "second state."
A computer program for managing the reservation status of demand and executing a reservation status management step that transitions the reservation status of demand in response to user requests,
The transition condition that allows the reservation status of the target demand to change from "first state" to "second state" includes the condition that there are no other demands of the same vehicle and time slot as the target demand that are in "second state" reservation status.
The reservation status management step determines whether or not to transition the reservation status of the target demand from "first state" to "second state" based on the transition conditions, and changes the reservation status of the target demand to "second state" according to the result of the determination.
The aforementioned reservation status management step allows for the creation of a new demand in reservation status "first status" even if the vehicle and time slot of the new demand overlap with the vehicle and time slot of other demands in reservation status "second status".
Computer program.