Vehicle dispatch management system, vehicle dispatch reservation management method, and computer program

Abstract

To implement reservation status management so that a user can freely perform vehicle dispatch search while preventing double booking.SOLUTION: A vehicle dispatch management system includes a reservation status management unit which shifts a reservation status of a demand in accordance with a user request. The reservation status management unit is configured to shift a reservation status of a target demand from "unfixed" to "fixed" when there is no other "tentatively fixed" demand in the same time zone for the same vehicle as the target demand and when reservation condition identifiers currently assigned to the vehicle and the time zone of the target demand coincide with a reservation condition identifier of the target demand. The reservation status management unit defines reservation condition identifiers currently assigned to the vehicle and the time zone of the "unfixed" demand, as a reservation condition identifier of the demand, and modifies the reservation condition identifiers currently assigned to the vehicle and the time zone of the demand to new reservation condition identifiers when the "tentatively fixed" demand shifts to "fixed" status.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to a vehicle allocation management system, a vehicle reservation management method, and a computer program.

Background Art

[0002] Demand-responsive transportation that realizes carpooling to meet the demands of multiple users is known. Demand-responsive transportation is a carpooling-type public transportation service that operates according to reservations made in advance by users. Regarding demand-responsive transportation, for example, a reservation management technique described in Patent Document 1 is known. In this technique, in order to encourage multiple users to ride on the same vehicle trip, a proposal for a ride reservation is made to users who may share a ride based on past riding histories. As an interface of a user terminal for making a reservation, one that inputs and transmits reservation information such as a desired date and time, a boarding location, and a dropping-off location, and when the seat reservation is successful, confirms the reservation and displays the reservation result is disclosed.

[0003] In addition, Non-Patent Document 1 describes a vehicle allocation technique based on trip units considering departures and arrivals from a base in order to realize an operation of waiting for a vehicle that is not in service at a base, which is particularly necessary when using an autonomous vehicle in demand-responsive transportation.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Non-Patent Documents

[0005]

Non-Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0006] However, in the above-described conventional technology, it is impossible to meet various needs of users who are interested in on-demand transportation and want to freely search for vehicle reservations without the intention of making a reservation, or users who want to check the scheduled departure time from the departure place and the scheduled arrival time at the destination before finalizing a reservation. In order to meet the various needs of such users, as reservation states, in addition to "confirmation" of a reservation, a "non-confirmed" state in which no restrictions are imposed on other vehicle reservation searches and confirmation of a reservation, and a "provisional confirmation" state in which no restrictions are imposed on other vehicle reservation searches but restrictions are imposed on confirmation of other reservations can be considered. On the other hand, in reservation state management, it is required to perform transitions of each reservation state while checking the consistency of the reservations. Here, in on-demand transportation, since it is a major feature that a high degree of freedom can be given to the travel route, pick-up and drop-off points, pick-up and drop-off times, etc., it is difficult to manage reservations independently for each established operation section or seat like train reservations for the Shinkansen.

[0007] The present invention has been made in consideration of such circumstances, and an object thereof is to realize reservation state management that achieves both free vehicle reservation search and measures to prevent duplication of reservations in a demand-type vehicle operation management system that operates vehicles according to reservations.

Means for Solving the Problems

[0008] 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, and the "Second State" of a 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 demand reservation The system includes a reservation status management unit that manages the reservation status and transitions the reservation status of a demand in response to a user request, and the transition condition that permits the transition of the reservation status of a target demand from "first state" to "second state" includes the fact 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 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. death , 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". It is a vehicle dispatch management system. One aspect of the present invention is a dispatch management system described above, wherein the "third state" of a demand reservation 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 state 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, and 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 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. 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 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".

[0009] 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 demand reservation state is defined as "first state" and "second state", the "first state" of the demand reservation state is a state in which there are no restrictions on dispatch searches and transitions in the reservation state of other demands other than the said demand, the "second state" of the demand reservation state 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 from the "first state" to the "second state" of the reservation state of other demands other than the said demand, and The system includes a reservation status management step that manages the reservation status of a demand and transitions the reservation status of a demand in response to a user request, wherein the transition condition that permits the transition of the reservation status of a target demand 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 the "second state" reservation status, and 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. death , 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". This is a method for managing vehicle dispatch reservations.

[0010] One aspect of the present invention provides a computer for a demand-type dispatch management system that operates vehicles according to reservations, with "First State" and "Second State" as the reservation status of the demand. The "First State" of the demand reservation is a state in which there are no restrictions on dispatch searches and reservation status transitions for other demands besides the one in question. The "Second State" of the demand reservation is a state in which there are no restrictions on dispatch searches for other demands besides the one in question, but there are restrictions on the transition of other demands from the "First State" to the "Second State". The system manages the reservation status of the demand and the user - A computer program for executing a reservation state management step that transitions the reservation state of a demand in response to a request, wherein the transition condition that permits the transition of the reservation state of a target demand 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 the "second state" reservation state, and the reservation state management step determines whether or not to transition the reservation state of the target demand from "first state" to "second state" based on the transition condition, and changes the reservation state of the target demand to "second state" according to the result of the determination. death , 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". It is a computer program. [Effects of the Invention]

[0011] 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 balances flexible vehicle search with measures to prevent reservation overlaps. [Brief explanation of the drawing]

[0012] [Figure 1] This block diagram shows an example configuration of a dispatch management system according to one embodiment. [Figure 2] This is a diagram illustrating an example of a trip according to one embodiment. [Figure 3] This figure shows an example of the operation of a dispatch management system according to one embodiment. [Figure 4]This is an explanatory diagram illustrating the reservation state and state transitions of a demand according to one embodiment. [Figure 5] This is an explanatory diagram illustrating an example of a reservation state transition according to one embodiment. [Figure 6] This is an explanatory diagram illustrating an example of a reservation state transition according to one embodiment. [Figure 7] This is an explanatory diagram illustrating the correspondence between a trip and a reservation condition identifier according to one embodiment. [Figure 8] This figure shows an example of the configuration of the display screen of a terminal device according to one embodiment. [Figure 9] This figure shows an example of the configuration of the display screen of a terminal device according to one embodiment. [Figure 10] This figure shows an example of the configuration of the display screen of a terminal device according to one embodiment. [Figure 11] This figure shows an example of the configuration of the display screen of a terminal device according to one embodiment. [Figure 12] This figure shows an example of the configuration of the display screen of a terminal device according to one embodiment. [Figure 13] This figure shows an example of the configuration of the display screen of a terminal device according to one embodiment. [Modes for carrying out the invention]

[0013] 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.

[0014] 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 it 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 it returns to the base.

[0015] 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 a WAN (Wide Area Network), a LAN (Local Area Network), etc. This WAN includes, for example, a mobile phone network, a PHS (Personal Handy-phone System) network, a PSTN (Public Switched Telephone Network), a dedicated communication line network, and a VPN (Virtual Private Network).

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

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

[0018] Based on the route search results, the management server 100 creates a new operating schedule for a vehicle that departs from the first base at the first time, passes through the pick-up and drop-off locations, and returns to the first or second base at the second time. Based on the newly created operating schedule and the existing operating schedules of one or more vehicles already in operation, the management server 100 determines whether the operation of the new operating schedule is feasible. The management server 100 determines whether it is possible to form a trip for the new demand alone, provided that the time period of the trip for the new demand alone does not overlap with the time period of an existing trip.

[0019] If the management server 100 determines that the new operating schedule is feasible, it creates a passenger reservation response addressed to terminal device 20-1, which contains the new operating schedule. The management server 100 sends the created passenger reservation response to terminal device 20-1. Terminal device 20-1 receives the passenger reservation response sent by the management server 100 and displays the new operating schedule included in the received passenger reservation response.

[0020] 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 on which the in-vehicle unit 30 is installed 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 on which the in-vehicle unit 30 is installed 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.

[0021] The terminal devices 20-1, 20-2, 20-3, in-vehicle unit 30, and management server 100 included in the dispatch management system 1 will be described in order below.

[0022] (Terminal device) Terminal devices 20-1, 20-2, and 20-3 are implemented by, for example, personal computers, mobile phones, tablets, smartphones, PHS (Personal Handy-phone System), or PDAs (Personal Digital Assistants).

[0023] Terminal device 20-1 is a portable device carried by the user. The user uses terminal device 20-1 to make a reservation for 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 actions.

[0024] Bus reservations include instant reservations and advance reservations. Instant reservations are for when you wish to board immediately, and require specifying information about your boarding location and drop-off location. Examples of information specifying the boarding and drop-off locations include place names and other information indicating a location. When an instant reservation is made, the reservation information includes information specifying the boarding location and drop-off location.

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

[0026] The ride reservation application causes terminal device 20-1 to create a ride reservation request addressed to management server 100, which includes ride reservation information. The ride reservation application causes terminal device 20-1 to send the ride reservation request it created to management server 100. The ride reservation application causes terminal device 20-1 to receive the ride reservation response sent by management server 100 and to process the ride reservation information contained in the received ride reservation response.

[0027] Terminal device 20-2 is a device used, for example, by a person sitting in the driver's seat of a vehicle. For example, terminal device 20-2 may be fixed in 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 terminal device 20-2. An operation application is installed on terminal device 20-2. The operation application causes terminal device 20-2 to receive information related to the operation of the vehicle, such as information identifying the user's boarding location, information identifying the alighting location, and route information, which is transmitted by the management server 100. Based on the received information related to the operation of the vehicle, the operation application causes terminal device 20-2 to display the boarding location, alighting location, and route information on the map displayed on the display unit.

[0028] 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 display unit of terminal device 20-2 is pressed, the operation application causes terminal device 20-2 to create operation information destined for management server 100, which includes information indicating the time of pressing and information indicating the boarding or alighting location corresponding to the pressed location. The operation application causes terminal device 20-2 to send the created operation information to management server 100.

[0029] 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.

[0030] (onboard device) The in-vehicle unit 30 is installed in the vehicle VE. The in-vehicle unit 30 has an in-vehicle application installed. 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 autonomous driving system of that vehicle VE. 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.

[0031] (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.

[0032] 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.

[0033] 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 transmits the dispatch request output by the dispatch processing unit 106 to the in-vehicle unit 30.

[0034] The storage unit 110 is implemented by, for example, RAM, ROM, HDD, flash memory, or a hybrid storage device that combines several 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 bases where vehicles are stationed (hereinafter referred to as "base ID") and location information of the bases in association with each other. The storage unit 110 also 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.

[0035] 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.

[0036] The reservation condition identifier information 110d has 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 is different for each vehicle. Furthermore, the reservation condition identifier is different for each time slot, even for the same vehicle. In addition, the reservation condition identifier is changed according to predetermined update conditions. As a result, the reservation condition identifier information 110d has 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.

[0037] 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.

[0038] 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.

[0039] The dispatch processing unit 106 obtains 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 capacity, information indicating the base of the waiting area, rest time information, current location information, and status information. Based on the obtained vehicle ID, information indicating the vehicle's operating schedule, information indicating the vehicle's capacity, information indicating the base of the waiting area, 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.

[0040] The vehicle allocation processing unit 106 performs processing on the premise that vehicles without demand during operation wait at the designated bases. The vehicle allocation processing unit 106 performs operation management in terms of trips. Here, the trip will be described.

[0041] FIG. 2 is a diagram for explaining an example of a trip. Let the boarding location (departure point) included in the reservation information (demand) be O (Origin), and the alighting location (destination) be D (Destination). The vehicle arrival time at the boarding location (departure point) is t O and the vehicle arrival time at the destination is t D Let the departure time from the base be t BS and the arrival time at the base be t BG In this way, a series of operations from the vehicle departing from the base at time t BS , passing through the transit points (boarding location, alighting location) of each demand, and arriving at the base at time t BG is called a trip.

[0042] In the example of FIG. 2, Trip 1 and Trip 2 are shown. As shown in FIG. 2, there may be cases where a plurality of trips are formed during the operation time of a day. Trip 1 is a series of operations where the vehicle departs from base BS1 at time t BS1 , arrives at the boarding location O1 at time t O1 , arrives at the alighting location D1 at time t D1 , and arrives at base BG1 at time t BG1 . Trip 2 is a series of operations where the vehicle departs from base BG2 at a time later than time t BG1 , which is time t BS2 , arrives at the boarding location O2 at time t O2 , arrives at the boarding location O3 at time t O3 , arrives at the alighting location D2 at time t D2 , arrives at the alighting location D3 at time t D3 , and arrives at base BG2 at time t BG2 .

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

[0044] The route search unit 108 acquires information identifying the boarding location and information identifying the alighting location output by the dispatch processing unit 106. The route search unit 108 acquires information associating the base ID of the base where the vehicle is waiting with the location information of the base, which is stored in the storage unit 110. Based on the acquired information identifying the boarding location and alighting location, and the information associating the base ID of the base where the vehicle is waiting with the location information of the base, 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 to which the vehicle will go after the alighting location. The base where the vehicle to be dispatched to the boarding location is waiting and the base to which the vehicle will go 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 to which the vehicle will go after the alighting location. Here, the first base and the second base are stored in the storage unit 110.

[0045] The route search unit 108 searches for a route from the first base to the second base via the boarding and alighting locations, based on the acquired information identifying the boarding location, information identifying the alighting 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 from the first base to the second base via the boarding and alighting locations along that route.

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

[0047] The dispatch processing unit 106 acquires information indicating the result of the route search output by the route search unit 108 and information indicating the result of deriving the required time. Based on the acquired information indicating the result of the route search and the result of deriving the required time, the dispatch processing unit 106 determines whether or not dispatch is possible.

[0048] 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 are any parts of the trip created for the new demand alone that overlap with existing trips in chronological order. If the dispatch processing unit 106 determines that there are no parts that overlap with existing trips in chronological order, 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.

[0049] Figure 3 shows an example of the operation of the dispatch management system according to this embodiment. Figure 3 shows an example of a trip. The trip shown in Figure 3 is when the vehicle is at time t O1min From time t O1max Arriving at boarding location O1 during the time t O1max The vehicle must depart from boarding location O1 at time t. D1min From time t D1max Assume that you must arrive at drop-off location D1 during that time.W This is the time between the departure time from the boarding location and a predetermined time before the departure time. W This is defined as the waiting time available at the demand pick-up location (departure point). R This is the time when arrival at the drop-off location is guaranteed (even with additional delays, arrival will be at this time at the latest) and the time between that time and a predetermined time before that time. R This is defined as buffer time to absorb delays caused by trips that are expected to be added in the future, and is called buffer time before arrival. Equations (1) and (2) hold true. t O1max -t O1min =T W (1) t D1max -t D1min =T R (2) From equation (1), condition t O1 The constraint is t O1min ≤t O1 ≤t O1max Therefore, from equation (2), t D1 The constraint is t D1min ≤t D1 ≤t D1max This is the result.

[0050] 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.

[0051] (If an instant booking is made) If an immediate booking is made, the vehicle is considered to be currently waiting at the first location. The dispatch processing unit 106 determines the earliest possible departure time for the vehicle waiting at the first location. BS Let the remaining time t O1 t D1 t BG This is the travel time between each point output by the route search unit 108 at time t BS A trip is formed by sequentially adding to these. At this time, the dispatch processing unit 106 determines the time t O1max at this time t O1 Let time t D1min at this time tD1 Let's assume that.

[0052] (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 will process the desired departure time. O1 Let time t O1 The departure time from the first base to arrive at boarding point O1 is t BS Let's assume the remaining time t D1 t BG Similar to the case of instant booking, the travel time between each point output by the route search unit 108 is time t BS A trip is formed by adding these values ​​in order. If a desired arrival time is specified, the dispatch processing unit 106 will process the desired arrival time. D1max And the arrival time t D1max t is determined by D1min The time of t D1 Let's assume the remaining time t BS t O1 t BG Similar to the case of instant booking, the travel time between each point output by the route search unit 108 is time t D1 A trip is formed by subtracting from in order.

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

[0054] 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 new demand trip 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~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 alone. If the dispatch processing unit 106 determines that dispatch is possible, it creates a ride reservation response addressed to 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.

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

[0056] (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," "Tentatively Confirmed," "Confirmed," and "Cancelled."

[0057] 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.

[0058] If the reservation status management unit 109 receives a request for boarding reservation information from the reception unit 104 and it is a "provisional reservation confirmation" that specifies a reservation status of "unconfirmed", it checks whether the predetermined transition conditions are met and then changes the reservation status of the said demand from "unconfirmed" to "provisional reservation confirmation".

[0059] If the reservation status management unit 109 receives a request for boarding reservation information from the reception unit 104 and it is a "confirmed reservation" that specifies a "provisionally confirmed" reservation status, it checks whether the predetermined transition conditions are met and then changes the reservation status of the said demand from "provisionally confirmed" to "confirmed".

[0060] If the reservation status management unit 109 receives a request for boarding reservation information from the reception unit 104 and it is for a reservation cancellation, it changes the reservation status of the specified demand to "cancelled".

[0061] Here, with reference to Figure 5, an example of the reservation state transition process 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 reservations (reservation 1 and reservation 2) from two users are for the same vehicle and the same time slot, and are made at approximately the same time.

[0062] First, Demand R1 of Reservation 1, received at the reception desk 104, becomes an "unconfirmed" reservation due to the creation of a new reservation R1a. At this "unconfirmed" stage, Demand R1 of Reservation 1 does not restrict other reservations, so Demand R2 of Reservation 2, received immediately afterward at the reception desk 104, similarly becomes an "unconfirmed" reservation due to the creation of a new reservation R2a. Next, Demand R1 of Reservation 1 transitions to a "provisionally confirmed" reservation due to the provisional reservation confirmation R1b. At this point, Demand R1 of Reservation 1, now in the "provisionally confirmed" state, restricts the transition of reservation states for other reservations in order to guarantee the transition from the "provisionally confirmed" to the "confirmed" state. Specifically, if there is a demand in the "provisionally confirmed" state, other demands for the same vehicle and time slot are restricted from transitioning from the "unconfirmed" to the "provisionally confirmed" state.

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

[0064] 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 demands with a "Confirmed" reservation status. The process for generating a "Not Confirmed" reservation status demand involves generating a new demand and registering it in the storage unit 110 as a "Not Confirmed" reservation status, obtaining a reservation condition identifier (reservation condition ID) that identifies the 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.

[0065] (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".

[0066] (Transition from reservation status "tentatively confirmed" to "confirmed") The conditions for allowing a demand with a reservation status of "provisionally confirmed" (target demand) to transition to a reservation status of "confirmed" are unconditional. The process of transitioning a demand with a reservation status of "provisionally confirmed" (target demand) 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 that vehicle and time slot in the reservation condition identifier information 110d to a new reservation condition identifier.

[0067] (Transition from reservation status "Unconfirmed," "Tentatively Confirmed," and "Confirmed" to "Cancelled") The conditions for allowing a reservation status of "Unconfirmed," "Tentatively Confirmed," and "Confirmed" (target demand) to be changed to a reservation status of "Cancelled" are unconditional. The process of changing a reservation status of "Unconfirmed," "Tentatively Confirmed," 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.

[0068] 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 demand in reservation state "unconfirmed" is generated until the demand transitions to reservation state "confirmed". The reservation state management unit 109 measures the elapsed time from when a demand in reservation state "unconfirmed" is generated, and when the demand transitions to each reservation state, that is, when it transitions from "unconfirmed" to "provisionally confirmed" or from "provisionally confirmed" to "confirmed", it includes in the transition conditions that the measured elapsed time is less than or equal to a predetermined reservation confirmation grace period.

[0069] 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).

[0070] 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 the 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.

[0071] 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.

[0072] As a concrete example, we will explain how the reservation condition identifier is used in the reservation state transition processing performed by the reservation state management unit 109, with reference to Figure 6. Figure 6 is an explanatory diagram of an example of a reservation state transition according to this embodiment. Figure 6 shows an example in which, similar to Figure 5, reservations (reservation 1 and reservation 2) from two users are made for the same vehicle and the same time slot, and are made at approximately the same time.

[0073] First, the demand R1 of reservation 1, which was received at 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 obtains the reservation condition identifier Rid1 currently assigned to the vehicle (vehicle and time slot) for the dispatch of reservation 1's demand R1, which was found by the dispatch processing unit 106, from the reservation condition identifier information 110d, and records the obtained reservation condition identifier in the demand information 110a as the reservation condition identifier for reservation 1's demand R1. At this "unconfirmed" reservation stage, the demand R1 of reservation 1 does not restrict other reservations.

[0074] Next, demand R2 of reservation 2, which was received by the reception unit 104 immediately after reservation 1, becomes an "unconfirmed" reservation status by creating a new reservation R2a. At this time, the reservation status management unit 109 obtains 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 obtained 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.

[0075] 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 conflict among multiple users regarding the reservation status of "unconfirmed". For example, if there are multiple demands R1 and R2 with the same reservation condition identifier, Rid1 currently assigned to the vehicle (vehicle and time slot) that are recorded in the demand information 110a, the reservation status management unit 109 may notify the terminal device 20-1 of each user of all of the "unconfirmed" demands R1 and R2 that multiple users have made vehicle reservations with the "unconfirmed" reservation status. This allows the unit to notify each user of all of the "unconfirmed" demands R1 and R2 that there is currently a competition among multiple users for the vehicle reservations with the "unconfirmed" reservation status. For example, if there is at least one demand R1 with a reservation status of "unconfirmed" that has the same reservation condition identifier Rid1 currently assigned to the vehicle (vehicle and time slot) as recorded in the demand information 110a, the reservation status management unit 109 may notify the terminal device 20-1 of the user of another demand R2 with a reservation status of "unconfirmed" that multiple users have made a vehicle reservation with a reservation status of "unconfirmed". This allows the user of the new demand R2 with a reservation status of "unconfirmed" to be notified that there is currently a competition among multiple users for that vehicle reservation with a reservation status of "unconfirmed".

[0076] Next, Demand R1 of Reservation 1 transitions to the "Provisionally Confirmed" reservation status by Reservation Provisional Confirmation R1b. At this time, the Reservation Status Management Unit 109 confirms that Demand R1 of Reservation 1 satisfies the transition conditions from the "Unconfirmed" reservation status to the "Provisionally Confirmed" status. As described above, these transition conditions are "Condition A1: There are no other demands with the same vehicle and time slot as the target demand R1 in the "Unconfirmed" reservation status that are in the "Provisionally Confirmed" status" 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 status, so Condition A1 is satisfied. Also, at this point, the reservation condition identifier currently assigned to the vehicle and time slot of Demand R1 of Reservation 1 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 of demand R1 of reservation 1 from "unconfirmed" to "provisionally confirmed".

[0077] 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'".

[0078] 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 the 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, the above condition B2 is not satisfied. Therefore, since the transition condition is not satisfied, 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 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".

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

[0080] Therefore, in this embodiment, when a demand R1 in the reservation state "provisionally confirmed" transitions to the reservation state "confirmed," the reservation condition identifier "Rid1" currently assigned to the vehicle and time slot of the demand R1 is changed to a new reservation condition identifier "Rid1'." Furthermore, as a transition condition for transitioning the demand R2 of reservation 2 from the reservation state "unconfirmed" to "provisionally confirmed," "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 the condition A2 is met, the condition B2 is not met for the demand R2 of reservation 2, and the state transition from "unconfirmed" to "provisionally confirmed" cannot be made, thus preventing the vehicle dispatch reservation for reservation 2 from being confirmed in conjunction with the vehicle dispatch reservation for reservation 1, which has already been confirmed.

[0081] 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 reservation state of "provisionally confirmed" to a reservation state of "confirmed," and satisfying the opportunity to generate new demands in the reservation state of "unconfirmed."

[0082] 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, but 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 has the most up-to-date reservation condition identifier for each vehicle and each 30-minute time slot.

[0083] The trip J1 shown in Figure 7(1) applies to a single vehicle VE_1 and is set to span 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 reservation condition identifiers corresponding to the time period "13:30 to 14:00" for the vehicle VE_1.

[0084] The trip J2 shown in Figure 7(2) applies to a single vehicle VE_2 and is set to span the 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 period "13:00 to 13:30", the time period "13:30 to 14:00", and the time period "14:00 to 14:30" for the vehicle VE_2.

[0085] 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.

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

[0087] (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., touch panel) of the terminal device 20-1. Figures 8-13 show examples of the configuration of the display screen of the terminal device according to this embodiment.

[0088] 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 sent to the terminal device 20-1.

[0089] Figure 8 shows an example of the initial state of the vehicle reservation screen 400. In the ride-hailing 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.).

[0090] In display section 402, users can select options related to ride-hailing searches. Radio buttons allow selection of "Cart only" or "Integrated search." If the user selects "Cart only," the search will use only on-demand vehicles. On the other hand, if the user selects "Integrated search," the search will include ride-hailing options that combine on-demand vehicles with other public transport. In addition, the information selected in the "Refuse ride-sharing" checkbox and the "Number of passengers" dropdown list in display section 402 will both be used in the ride-hailing search process.

[0091] 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 address input button, or selecting from the map displayed in display section 404. The display section 405 includes a vehicle search button, a search results display area, a provisional confirmation button, and a cancel button.

[0092] In the dispatch reservation screen 400 of 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.

[0093] Figure 9 shows an example of the dispatch reservation screen 400 when a suitable dispatch is found through the dispatch search. The reservation status management unit 109, having found a suitable dispatch through the dispatch search, creates a new demand with a reservation status of "unconfirmed" at this stage.

[0094] In the dispatch reservation screen 400 of 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. In addition, 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, the 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 the operation information.

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

[0096] In the dispatch reservation screen 400 in Figure 9, when a 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 request for provisional confirmation of 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".

[0097] Figure 11 shows an example of the dispatch reservation screen 400 when the reservation status of a demand is changed to "provisionally confirmed". In the dispatch reservation screen 400 of Figure 11, a button to confirm the reservation ("Yes") and a button to cancel the reservation ("No") are provided at the end of the display section 405. If the button to cancel the reservation ("No") is pressed at this stage, the operation information is sent 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 "provisionally confirmed" to "cancelled" in response to the cancellation request based on the operation information.

[0098] In the dispatch reservation screen 400 in Figure 11, when a 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 "provisionally confirmed" to "confirmed" in response to the reservation confirmation request based on the ride reservation information obtained via the reception unit 104.

[0099] 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 message indicating that the reservation is confirmed, and then displays buttons to select the next screen to display ("Back to Top", "Continue").

[0100] Figure 13 shows an example of a screen configuration displaying reservation information for a demand with a reservation status of "Confirmed". Users can check detailed information about a reservation for a demand with a reservation status of "Confirmed" using the reservation status details screen shown in Figure 13. Users can also cancel a 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, and the reservation status management unit 109 changes the reservation status of the demand from "Confirmed" to "Cancelled" in response to the cancellation request based on this operation information.

[0101] 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," "provisionally confirmed," and "confirmed." The reservation status of "unconfirmed" for a demand means that there are no restrictions on dispatch searches and reservation status transitions for other demands, while the reservation status of "provisionally confirmed" for a demand means that there are no restrictions on dispatch searches for other demands, but there are restrictions on the transition from the reservation status of "unconfirmed" to "provisionally confirmed" for other demands. The "Confirmed" status of a demand reservation restricts dispatch searches for other demands besides the one in question. The system includes a reservation condition identifier information storage unit (reservation condition identifier information 110d of storage unit 110) that stores the latest reservation condition identifier for each vehicle and time slot, a demand information storage unit (demand information 110a of storage unit 110) that stores demand-related information indicating each user's demand and the reservation condition identifier for each demand, and manages the reservation status of demands and transitions the reservation status of demands in response to user requests. The system includes a reservation status management unit, and the transition conditions that permit the transition of the reservation status of a target demand from "unconfirmed" to "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 storage unit. The reservation status management unit records new demands for which the dispatch search has been successful as having a reservation status of "unconfirmed", and records demands with a reservation status of "unconfirmed". The reservation condition identifier currently assigned to the vehicle and time slot of the demand 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 the demand in the reservation condition identifier information storage unit to a new reservation condition identifier. Based on the transition conditions, the reservation status management unit determines whether or not to transition the reservation status of the target demand from "unconfirmed" to "provisionally confirmed."Based on the results of the determination, the reservation status of the relevant demand will be changed to "provisionally confirmed."

[0102] With the configuration according to 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 generate a "pending" demand and check the ride search results. Users who intend to confirm a reservation can change a "pending" demand to a "tentatively confirmed" reservation, then check the estimated departure time from the departure point and the estimated arrival time at the destination, and then confidently change a "tentatively confirmed" demand to a "confirmed" reservation without the risk of reservation overlap. Thus, according to this embodiment, in a demand-type ride-hailing management system that operates vehicles according to reservations, it is possible to achieve reservation status management that balances free ride-hailing search with measures to prevent reservation overlap.

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

[0104] Although embodiments of the present invention have been described in detail above with reference to the drawings, the specific configuration is not limited to these embodiments, and design modifications and the like are also included within the scope of the gist of the present invention.

[0105] 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.

[0106] 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" used to transmit 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. [Explanation of Symbols]

[0107] 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

1. 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.

2. 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.

3. 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.

4. 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.

5. The aforementioned reservation status management unit notifies the terminal device of the user of the demand reservation in "First Status" that there is a conflict among multiple users regarding the vehicle dispatch reservation in the "First Status" reservation status. The dispatch management system according to claim 1.

6. 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 aforementioned 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.

7. 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 aforementioned 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.

Images