Vehicle dispatch management device, vehicle dispatch management method, and program

Abstract

This will enable regular and affordable ride-sharing. [Solution] The dispatch management device comprises one or more processors, which set up a plurality of candidate trips 210, each associated with one of a plurality of predetermined travel routes and a transport period, receive a dispatch request (rideshare dispatch request 240) from a user terminal, and assign the dispatch request in parallel to one or more candidate trips 210, where the pick-up and drop-off selection points received from the user terminal 20 that made the dispatch request are included in the travel route and the desired transport time received from the user terminal 20 that made the dispatch request is included in the transport period, and at a predetermined timing before the transport period, one of the candidate trips 210 to which the dispatch request has been assigned is designated as a confirmed trip 212, and a vehicle is assigned to the confirmed trip 212.

Description

Technical Field

[0001] The present invention relates to a vehicle dispatching management device, a vehicle dispatching management method, and a program for managing vehicle dispatching.

Background Art

[0002] A technology for receiving a vehicle dispatching request from a user and dispatching a taxi is known. For example, Patent Document 1 discloses a technology for estimating the arrival times of a user and a taxi at a boarding location desired by the user, matching the estimation results, and dispatching a taxi so that the difference in the estimation results is reduced.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In a taxi dispatching request, so-called shared rides may occur where multiple users ride in one vehicle. In a shared ride, the desired boarding and alighting locations of multiple users may be different from each other. Therefore, if the combination of users sharing the ride, the boarding order, and the alighting order are randomly determined, and the vehicle transports the users according to the determined boarding and alighting orders, the total driving distance may become unnecessarily long, and there is a risk that the transportation cost and the fee per user may increase unnecessarily. Also, since the total driving distance and driving time are likely to change, the boarding and alighting times of the users are not determined, and it is difficult for the users to make plans before boarding or after alighting.

[0005] In view of such problems, an object of the present invention is to provide an information processing device, an information processing method, and a program that enable constant and cost-effective shared rides.

Means for Solving the Problems

[0006] To solve the above problems, the dispatch management device of the present invention, which can communicate with a user terminal via a network, comprises one or more processors, the processor sets up a plurality of candidate trips, each of which is associated with one of a plurality of predetermined travel routes and a transport period, receives a dispatch request from the user terminal, assigns the dispatch request in parallel to one or more candidate trips in which the pick-up and drop-off selection points received from the user terminal that made the dispatch request are included in the travel route and the desired transport time received from the user terminal that made the dispatch request is included in the transport period, and at a predetermined timing before the transport period, designates one of the candidate trips to which the dispatch request has been assigned as a confirmed trip and assigns a vehicle to the confirmed trip. The processor may identify candidate trips such that the number of candidate trips assigned in parallel to each of the multiple dispatch requests is minimized, and the identified candidate trips may be designated as the confirmed trips. The processor may identify candidate trips such that the number of dispatch requests assigned to the candidate trips is two or more, and may designate the identified candidate trips as confirmed trips. The number of set candidate trips is greater than or equal to the number of vehicles, and the processor may remove candidate trips that did not become confirmed trips from the list of confirmed trips. Even after determining the confirmed trip, the processor may accept a new dispatch request and assign the dispatch request to the confirmed trip if certain additional conditions are met. The aforementioned additional condition may be that the vehicle to which the confirmed trip is assigned allows additional users for ride-sharing. The aforementioned additional condition may be that the pick-up and drop-off locations of the new ride request are located on the route of the confirmed trip. The additional conditions may include that a new dispatch request is received before notification that the confirmed trip has been assigned to the vehicle, and that the pick-up and drop-off locations of the new dispatch request are located on the route of the candidate trip that has become the confirmed trip. The additional conditions may also include that a new dispatch request is received before the vehicle reaches a predetermined distance before the first pick-up location in the confirmed trip, and that the pick-up and drop-off locations of the new dispatch request are after the first pick-up location in the confirmed trip. To solve the above problems, the vehicle dispatch management method of the present invention involves a computer setting up a plurality of candidate trips, each associated with one of a predetermined number of driving routes and a transportation period; receiving a dispatch request from a user terminal; assigning the dispatch request in parallel to one or more candidate trips in which the pick-up and drop-off points received from the user terminal that made the dispatch request are included in the driving route and the desired transportation time received from the user terminal that made the dispatch request is included in the transportation period; and at a predetermined timing before the transportation period, designating one of the candidate trips to which the dispatch request has been assigned as a confirmed trip and assigning a vehicle to the confirmed trip. To solve the above problems, the program of the present invention causes a computer to set up a plurality of candidate trips, each associated with one of a predetermined number of travel routes and a transport period; receive a dispatch request from a user terminal; assign the dispatch request in parallel to one or more candidate trips in which the pick-up and drop-off points received from the user terminal that made the dispatch request are included in the travel route and the desired transport time received from the user terminal that made the dispatch request is included in the transport period; and, at a predetermined timing before the transport period, designate one of the candidate trips to which the dispatch request has been assigned as a confirmed trip and assign a vehicle to the confirmed trip. [Effects of the Invention]

[0007] According to the present invention, it becomes possible to have regular and inexpensive ride-sharing. [Brief explanation of the drawing]

[0008] [Figure 1] Figure 1 is a block diagram illustrating the general structure of the dispatch management system. [Figure 2] Figure 2 is a block diagram illustrating the configuration of the user terminal. [Figure 3] Figure 3 is a block diagram illustrating the configuration of the vehicle terminal. [Figure 4] Figure 4 is a block diagram illustrating the configuration of the service provider's server. [Figure 5] Figure 5 is a block diagram illustrating the configuration of the dispatch management server. [Figure 6] Figure 6 is a sequence diagram showing the processing flow of the dispatch management method using the dispatch management system. [Figure 7] This is an explanatory diagram for describing the driving area and the target driving area. [Figure 8] This is an explanatory diagram illustrating terminals, routes, spots, and proposed trips. [Figure 9] Figure 9A is the first explanatory diagram for illustrating the operation of the user terminal control unit. Figure 9B is the second explanatory diagram for illustrating the operation of the user terminal control unit. Figure 9C is the third explanatory diagram for illustrating the operation of the user terminal control unit. Figure 9D is the fourth explanatory diagram for illustrating the operation of the user terminal control unit. [Figure 10] Figure 10A is the fifth explanatory diagram for illustrating the operation of the user terminal control unit. Figure 10B is the sixth explanatory diagram for illustrating the operation of the user terminal control unit. Figure 10C is the seventh explanatory diagram for illustrating the operation of the user terminal control unit. Figure 10D is the eighth explanatory diagram for illustrating the operation of the user terminal control unit. [Figure 11] Figure 11 is an explanatory diagram illustrating the processing in the vehicle dispatch department. [Figure 12] Figure 12 is an explanatory diagram illustrating the processing in the vehicle dispatching department. [Figure 13] Figure 13 is an explanatory diagram illustrating the processing in the vehicle dispatch department. [Figure 14] Figure 14 is a timing chart for explaining the addition of shared rides. [Figure 15] Figure 15 is an explanatory diagram for explaining the processing of the vehicle dispatching unit. [Figure 16] Figure 16 is an explanatory diagram for explaining the processing of the vehicle dispatching unit. [Figure 17] Figure 17 is a flowchart for explaining the trip splitting process. [Figure 18] Figure 18 is an explanatory diagram for explaining the processing of the vehicle dispatching unit. [Figure 19] Figure 19 is an explanatory diagram for explaining the processing of the vehicle dispatching unit. [Figure 20] Figure 20 is an explanatory diagram for explaining the processing of the vehicle dispatching unit. [Figure 21] Figures 21A, 21B, 21C, and 21D are explanatory diagrams for explaining an example of the operation of the user terminal control unit. [Figure 22] Figures 22A, 22B, and 22C are explanatory diagrams for explaining an example of the operation of the user terminal control unit. [Figure 23] Figure 23 is a flowchart showing an example of the operation flow of the vehicle dispatching unit. [Figure 24] Figure 24 is a flowchart for explaining the first example when the shared vehicle is inoperable. [Figure 25] Figure 25 is a flowchart for explaining the second example when the shared vehicle is inoperable. [Figure 26] Figure 26 is a flowchart for explaining the third example when the shared vehicle is inoperable.

Mode for Carrying Out the Invention

[0009] Preferred embodiments of the present invention will be described in detail below with reference to the attached drawings. The dimensions, materials, and other specific numerical values ​​shown in these embodiments are merely examples to facilitate understanding of the invention and do not limit the present invention unless otherwise specified. In this specification and drawings, elements having substantially the same function and configuration are denoted by the same reference numerals to avoid redundant explanations, and elements not directly related to the present invention are omitted from the illustrations.

[0010] (Vehicle dispatch management system 1) Figure 1 is a block diagram illustrating the general structure of the dispatch management system 1. The dispatch management system 1 includes multiple user terminals 20, multiple vehicle terminals 30, multiple vehicles 32, one or more operator servers 40, and one or more dispatch management servers 50.

[0011] User terminal 20 is an electronic device owned by user 2. User 2 is, for example, a passenger (customer) of vehicle 32. Examples of user terminal 20 include smartphones, personal computers, tablet PCs, etc. In the dispatch management system 1, there are multiple combinations of user 2 and user terminal 20. In this embodiment, user 2 is not limited to one person, but may also refer to multiple people who can ride together in one vehicle 32.

[0012] Figure 2 is a block diagram illustrating the configuration of the user terminal 20. The user terminal 20 includes a communication device 120, a processing device 122, a display device 124, an input device 126, and a storage device 128. The communication device 120 is connected to an external source, such as a dispatch management server 50, via a base station 5 and a network 6. The processing device 122 has a semiconductor integrated circuit including a processor such as a CPU (Central Processing Unit), a ROM (Read Only Memory) where programs are stored, and a RAM (Random Access Memory) used as a work area. A user application for the dispatch management system 1 can be installed on the user terminal 20. The processing device 122 activates the user application by running a program and functions as a dispatch request unit 160 that assists in inputting dispatch requests, which are dispatch requests from user 2. Here, dispatch refers to assigning a vehicle 32 to a dispatch request and sending it to the pick-up location.

[0013] The display device 124 includes a liquid crystal display, an organic EL (Electro Luminescence) display, etc., and displays various information such as a user application for requesting a vehicle dispatch. The input device 126 includes a touch panel superimposed on the display device 124, switches, buttons, keys, a microphone for voice input, etc., and receives input from user 2, for example, information for requesting a vehicle dispatch. The storage device 128 is composed of storage means such as an HDD (Hard Disk Drive), SD memory (SD Memory), or SSD (Solid State Drive).

[0014] The vehicle terminal 30 is an electronic device lent to the driver 3 of the vehicle 32, or an electronic device owned by the driver 3, and is used when driving the vehicle 32. Therefore, the vehicle terminal 30 is associated with the vehicle 32 together with the driver 3. In other words, it is sufficient that the vehicle terminal 30 is located (exists) within the vehicle 32 and can be operated and accessed by the driver 3, and it is not limited to being brought into the vehicle at the start of driving; it may also be installed (fixed) in the vehicle 32 beforehand. Examples of vehicle terminals 30 include smartphones, personal computers, tablet PCs, etc.

[0015] Figure 3 is a block diagram illustrating the configuration of the vehicle terminal 30. The vehicle terminal 30 includes a communication device 130, a processing device 132, a display device 134, an input device 136, and a storage device 138. The communication device 130 is connected to an external source, such as the operator server 40 or the dispatch management server 50, via a base station 5 and a network 6. The processing device 132 has a semiconductor integrated circuit including a processor (CPU), ROM for storing programs, RAM used as a work area, etc. A vehicle application for the dispatch management system 1 is installed on the vehicle terminal 30. The processing device 132 controls the vehicle application by running the program and functions as a dispatch response unit 162 that supports response input to dispatch requests by the driver 3.

[0016] The display device 134 includes a liquid crystal display and an organic EL display, and displays various information to the driver 3, such as that his vehicle 32 has become the subject of a dispatch request (dispatch target notification) and information related to the dispatch request (pickup location, drop-off location, user information about user 2). Hereinafter, the subject of a dispatch request may be referred to as the "dispatch target," and the vehicle 32 that has become the dispatch target may be referred to as the "dispatch target vehicle." In addition, the vehicle terminal 30 can function as a fare meter (taxi meter) that automatically calculates the fare according to the distance traveled and the time taken from the pickup location to the drop-off location. In this case, the display device 134 displays information to user 2, for example, indicating the automatically calculated fare. A fare meter realized by such a vehicle terminal 30 may be called a "soft meter" to distinguish it from a dedicated meter fixed to the taxi. The input device 136 includes a touch panel, switches, buttons, keys, a microphone for voice input, etc., superimposed on the display device 134, and accepts input from the driver 3, for example, acceptance of a dispatch request. The storage device 138 is composed of storage means such as an HDD, SD memory, or SSD. The vehicle terminal 30 can obtain its own location on a map through location-determining means such as GPS (Global Positioning System).

[0017] Driver 3 is the crew of vehicle 32. Driver 3 includes taxi drivers and NRS drivers. Here, NRS is an abbreviation for Japanese-style rideshare or Japanese version of rideshare. Taxi drivers are crew members who hold a Class 2 ordinary driver's license and belong to the taxi business (general passenger transport business). NRS drivers are drivers who hold a Class 1 or Class 2 ordinary driver's license and belong to the rideshare business (private vehicle paid passenger transport business). In this embodiment, we will explain using an example in which a taxi operator also manages a rideshare business based on Article 78, Paragraph 3 of the Road Transport Act. However, as a rideshare business, not only "private vehicle utilization business" (Japanese-style rideshare) operated by a taxi operator based on Article 78, Paragraph 3 of the Road Transport Act can be applied, but also "private paid passenger transport" (municipal rideshare) which is applied to areas where local residents have difficulty moving around (transportation-deprived areas) based on Article 78, Paragraph 2 of the Road Transport Act. In the Japanese-style ride-sharing system based on Article 78, Paragraph 3 of the Road Transport Act, an NRS driver can be considered a driver belonging to a taxi operator, and can charge user 2 a fee (fare) equivalent to that of a general passenger transport business as compensation for transporting user 2. However, NRS drivers differ from taxi drivers in that they may not possess a Class 2 ordinary driver's license, and their qualifications, driving skills, and knowledge as drivers may be low. Furthermore, NRS drivers cannot engage in so-called "cruising" by driving their vehicle 32 while searching for users 2 who wish to ride, as taxi drivers do.

[0018] Vehicle 32 is, for example, a vehicle belonging to a taxi operator and can transport user 2 for a fee as part of its taxi business. In the dispatch management system 1, there are multiple combinations of driver 3, vehicle 32, and vehicle terminal 30. In the dispatch management system 1, the commercial vehicle 32 that serves as the means of transport for user 2 includes taxi vehicles driven by taxi drivers and NRS vehicles driven by NRS drivers. In this embodiment, a four-wheeled taxi (hire car) is given as an example of a vehicle 32 to be dispatched, but it is not limited to this example, and vehicle 32 may include, for example, a motorcycle (motorcycle taxi) as long as it is a vehicle capable of transporting people. Also, if driver 3 is an NRS driver, a private car or an idle taxi vehicle can be used as the vehicle 32 to be dispatched.

[0019] Figure 4 is a block diagram illustrating the configuration of the operator server 40. The operator server 40 is an information processing device (computer) owned by a taxi operator that operates a taxi business. The operator server 40 manages vehicles 32 driven by drivers 3 belonging to the taxi business. The operator server 40 includes a communication device 140, a processing device 142, a display device 144, an input device 146, and a storage device 148. The communication device 140 is connected to the outside world via the network 6, for example, a vehicle terminal 30 and a dispatch management server 50. The processing device 142 has a semiconductor integrated circuit including a processor (CPU), ROM in which programs are stored, RAM used as a work area, etc. By running a program, the processing device 142 functions as a vehicle management unit 164 that manages vehicles 32 belonging to the taxi business.

[0020] The display device 144 includes a liquid crystal display and an organic EL display, and displays various information such as information about the driver 3 or the vehicle 32, which is obtained directly from the vehicle 32 or via the dispatch management server 50. The input device 146 includes a keyboard, a touch panel superimposed on the display device 144, a microphone for voice input, etc., and receives input from operators at the taxi company. For example, the operator can communicate with the driver 3 via the operator server 40, or view images of the inside and outside of the vehicle, including an image of the driver 3. The storage device 148 consists of storage means such as an HDD, SD memory, or SSD.

[0021] Figure 5 is a block diagram illustrating the configuration of the dispatch management server 50. The dispatch management server (dispatch management device) 50 is an information processing device (computer) that manages vehicles 32 belonging to a taxi company based on a contract between the dispatch management company and the taxi company. The dispatch management server 50 is an example of a dispatch management device having server functionality and is operated by the dispatch management company. The dispatch management server 50 can dispatch a vehicle 32 to user 2 in response to a dispatch request from user terminal 20. The dispatch management server 50 includes a communication device 150, a processing device 152, and a storage device 154. The communication device 150 is connected to the outside world via the network 6, for example, user terminal 20, vehicle terminal 30, and operator server 40. The processing device 152 has a semiconductor integrated circuit including a processor (CPU), ROM in which programs are stored, RAM used as a work area, etc.

[0022] The processing unit 152 functions as a user terminal control unit 170, a dispatch unit 172, and a vehicle terminal control unit 174 by running a program. The user terminal control unit 170 controls the user application installed on the user terminal 20. The dispatch unit 172 assigns a vehicle 32 in response to a dispatch request. The vehicle terminal control unit 174 controls the vehicle application installed on the vehicle terminal. The storage device 154 is composed of storage means such as an HDD, SD memory, or SSD, and stores information about the user 2 and the vehicle 32.

[0023] The dispatch management system 1 matches multiple dispatch requests with multiple vehicles 32 at once and assigns a vehicle 32 to each dispatch request. Here, matching refers to the process of exclusively associating any dispatch request with any vehicle 32 when multiple dispatch requests and multiple vehicles 32 exist.

[0024] (Request for individual vehicle dispatch) Furthermore, in the dispatch management system 1, there are two types of rides for users 2: solo rides, where one or a group of users 2 ride alone in one vehicle 32, and ride-sharing, where multiple users 2 ride together in one vehicle 32. Here, a dispatch request for solo rides is sometimes referred to as a "solo dispatch request," and a dispatch request for ride-sharing, which allows for sharing with other users 2, is sometimes referred to as a "ride-sharing dispatch request." Here, we will first explain the dispatch management direction based on solo dispatch requests using Figure 6, and then detail the characteristic processing of ride-sharing dispatch requests compared to solo dispatch requests.

[0025] (Vehicle dispatch management method) Figure 6 is a sequence diagram showing the processing flow of the dispatch management method by the dispatch management system 1. The dispatch management system 1 extracts one or more vehicles 32 that could be the target vehicle for each dispatch request from a group of vehicles 32, and identifies one target vehicle through matching. The dispatch management system 1 then contacts the driver 3 of the vehicle 32 that has been identified as the target vehicle for dispatch to request a ride, and if the driver 3 accepts the request, the dispatch for the dispatch request is confirmed. The following describes each process in the dispatch management method in detail.

[0026] (Vehicle dispatch request processing S1) If user 2 wishes to board vehicle 32, user 2 submits a dispatch request through user terminal 20. Specifically, the dispatch request unit 160 of user terminal 20 launches a user application for making a dispatch request. The user application displays a map of a predetermined area including the current location of user terminal 20, as well as vehicles 32 located near user terminal 20. For example, if user 2 wishes to board vehicle 32, user 2 operates the "Dispatch" button. The dispatch request unit 160 receives user 2's dispatch request through the input device 126. At this time, user 2 can set settings for vehicle 32 that user 2 will board. The dispatch request unit 160 adds information about the settings set by user 2 and sends the dispatch request to the dispatch management server 50.

[0027] In addition to the initial ride-hailing preference, the settings include options such as pick-up location, drop-off location, payment information, ride-hailing category, and ride-sharing acceptance information.

[0028] The boarding location indicates the location on the map where User 2 boards the vehicle 32. User 2 can set their current location as the boarding location, or they can set a desired location different from their current location as the boarding location. If multiple Users 2 board at different locations, the boarding location also includes the combined boarding range of those locations. Furthermore, if multiple Users 2 are carpooling, each location on the map where each User 2 boards the vehicle 32 (for example, a spot described later) becomes a boarding location. The alighting location indicates the location on the map where User 2 alights from the vehicle 32. If multiple Users 2 alight at different locations, the alighting location also includes the combined alighting range of those locations. Furthermore, if multiple Users 2 are carpooling, each location on the map where each User 2 alights from the vehicle 32 (for example, a spot described later) becomes a alighting location. When User 2 sets the pick-up and drop-off locations, the fare calculated based on the set time, pick-up location, and drop-off location is displayed on the display device 124. In this way, User 2 can know in advance the fare they will pay by riding in vehicle 32. Note that if User 2 limits the dispatch target to only taxi vehicles, the drop-off location is not required input information but is optional. On the other hand, if User 2 includes NRS vehicles in the dispatch target, the drop-off location becomes required input information.

[0029] The payment information is information regarding the payment of charges associated with the use of vehicle 32 (e.g., fare, other additional charges). If NRS vehicles are included in the dispatch target, in addition to inputting the drop-off location, payment information such as information regarding cashless automatic payment by credit card, etc. (e.g., credit card number) is required. Furthermore, regardless of the target of the dispatch, that is, regardless of whether the dispatched vehicle 32 is an NRS vehicle or a taxi vehicle, payment information such as information regarding cashless automatic payment by credit card, etc., may be required. Also, regardless of whether driver 3 is a taxi driver or an NRS driver, payment information such as information regarding cashless automatic payment by credit card, etc., may be required. The dispatch category indicates the category of vehicle 32 to be dispatched. For example, if user 2 wishes to dispatch a taxi vehicle, they select "Taxi vehicles only" as the dispatch category; if they do not require a taxi vehicle, they select "All vehicles" as the dispatch category.

[0030] The ride-sharing permission information indicates whether or not ride-sharing is permitted in vehicle 32 for user 1, meaning that user 2 can ride together with another user 2. If user 2 is able to set the ride-sharing permission information, they can ride-sharing by setting it to permitted. The dispatch management server 50 may recommend ride-sharing only to user 2 who has permitted ride-sharing. Note that the ride-sharing permission information can be set by user 2 as described above, or it can be set not to be set (the function to set ride-sharing permission information may not be provided).

[0031] (Vehicle dispatch request extraction process S2) The user terminal control unit 170 of the dispatch management server 50 first identifies which of the multiple service areas the pick-up location in the settings item falls into when it receives a dispatch request from the user terminal 20. The user terminal control unit 170 assigns the same identifier, for example, the taxi service area ID, to dispatch requests originating from the same service area. The user terminal control unit 170 associates the service area identifier and the time the dispatch request was received with the dispatch request, which includes the above-mentioned information on various settings items, and sequentially stores them in the storage device 154.

[0032] The dispatch unit 172 of the dispatch management server 50 extracts all dispatch requests that have occurred in a predetermined service area up to a predetermined execution timing from among the multiple dispatch requests stored in the storage device 154. Here, the execution timing indicates the timing at which the dispatch request extraction process S2 is started for multiple dispatch requests, and is expressed, for example, as a time. The execution timing is set repeatedly and periodically with a predetermined processing period in between. Therefore, the current execution timing is set after a predetermined processing period has elapsed since the dispatch request extraction process S2 was started at the previous execution timing. Here, the predetermined processing period is the length of time at which dispatch requests to be processed at once are accumulated, and is set, for example, to 5 seconds.

[0033] (Vehicle allocation process S3) The dispatch unit 172 selects one or more vehicles 32 that meet predetermined selection conditions for the dispatch request extracted in the dispatch request extraction process S2 from among multiple vehicles 32 that can carry user 2. Examples of selection conditions include the distance between the pick-up location and the current location of the vehicle 32 being within a predetermined distance (e.g., 10 km), or the estimated arrival time at the pick-up location being within a predetermined time (e.g., 10 minutes).

[0034] The dispatch unit 172 assigns (matches) vehicles 32 to the dispatch requests extracted in the dispatch request extraction process S2. Specifically, the dispatch unit 172 generates multiple pairs of vehicles 32, each exclusively paired with the same number of vehicles 32 for each dispatch request extracted in the dispatch request extraction process S2. Here, no single dispatch request is associated with multiple vehicles 32, and no single vehicle 32 is associated with multiple dispatch requests. The dispatch unit 172 calculates the average (or sum) of the estimated arrival times to the pick-up location for each pair of vehicles 32. The dispatch unit 172 selects the pair of vehicles with the shortest average estimated arrival time as the final combination, and designates the vehicle 32 paired with the dispatch request as the vehicle to be dispatched. The dispatch unit 172 may also assign a vehicle 32 to a dispatch request only if the vehicle 32 matches all the settings of the dispatch request.

[0035] In this way, by matching multiple dispatch requests with multiple vehicles 32 at once, the relative positions of user 2 and vehicle 32 can be comprehensively determined, compared to matching dispatch requests sequentially and individually, enabling more efficient dispatch.

[0036] (Vehicle dispatch notification process S4) The vehicle terminal control unit 174 of the dispatch management server 50 controls the vehicle application on the vehicle terminal 30 and performs dispatch management through the vehicle application. The vehicle terminal control unit 174 notifies the vehicle terminal 30 located on the vehicle 32 that has become a vehicle to be dispatched in response to a dispatch request, with information indicating that the vehicle 32 has become a vehicle to be dispatched (dispatch target notification). This dispatch target notification is equivalent to asking the driver 3 of the dispatch target vehicle whether or not to accept the dispatch request. In this way, the driver 3 of the vehicle 32 can recognize that their vehicle 32 has become a vehicle to be dispatched and consider whether or not to accept the dispatch request.

[0037] (Acceptance response processing S5) When the dispatch response unit 162 of the vehicle terminal 30, which is installed in the vehicle, receives information from the vehicle terminal control unit 174 indicating that it has become a vehicle to be dispatched, it notifies the driver 3 of this fact, for example, through the display device 134. When notifying the driver of this information, the vehicle terminal 30 may also display information related to the dispatch request (for example, the pick-up location, user information about user 2, etc.) on the display device 134. If the user 2 has entered a drop-off location, for example, after the vehicle 32 arrives at the pick-up location of user 2, the vehicle terminal 30 may display the drop-off location information on the display device 134 as information related to the dispatch request. If the driver 3 accepts the dispatch request, he accepts the dispatch request by tapping the position corresponding to the "Accept Request" button displayed on the display device 134, for example, through the input device 136 of the vehicle terminal 30. The dispatch response unit 162 transmits information regarding the acceptance of the dispatch request (acceptance response), including the acceptance of the dispatch request, to the dispatch management server 50. In some cases, vehicles whose dispatch request has been accepted and whose dispatch has been confirmed are referred to as "confirmed dispatch vehicles."

[0038] (Vehicle dispatch completion notification process S6) When the vehicle terminal control unit 174 receives information regarding acceptance of a dispatch request (acceptance response) from the vehicle terminal 30, it confirms the dispatch of the vehicle to be dispatched in response to the dispatch request and sends a dispatch completion notification to the vehicle terminal 30 indicating that the dispatch has been confirmed. At this time, the display device 134 of the vehicle terminal 30 in the dispatched vehicle displays information regarding the dispatch request, such as the pick-up location and the route to the pick-up location. With this configuration, the driver 3 of the vehicle 32 can grasp the information regarding the dispatch request, drive the appropriate route toward the pick-up location, and find the user 2 early. If the vehicle to be dispatched is an NRS vehicle, the vehicle terminal control unit 174 may also display other information on the display device 134 as information regarding the dispatch request, such as the drop-off location in addition to the pick-up location. The dispatch management server 50 manages the dispatch status, which indicates the status of assigning vehicle 32 to each dispatch request in stages, even after the dispatch has been confirmed. The dispatch statuses include "Dispatch Confirmed," which indicates that the vehicle to be dispatched for the dispatch request has been confirmed; "Arriving Soon," which indicates that vehicle 32 has reached the pick-up location or its vicinity (for example, within 80m); "Arrived," which indicates that the arrival switch has been operated; "In Boarding," which indicates that user 2 has boarded; and "Boarding Complete," which indicates that payment has been completed.

[0039] (User dispatch completion notification process S7) When the user terminal control unit 170 confirms the dispatch of a vehicle in response to a dispatch request, it sends a dispatch completion notification to the user terminal 20 indicating that the dispatch has been confirmed. At this time, the display device 124 of the user terminal 20 shows the location of the dispatched vehicle 32, the estimated arrival time, etc. Thus, user 2 can board the vehicle 32 at the boarding location.

[0040] As explained using Figure 6, when user 2 wishes to ride alone and makes a request for a single ride, at least a pick-up location is set. The dispatch unit 172 promptly assigns a vehicle 32 that is close to the set pick-up location (short estimated arrival time) to the single ride request. Here, the example of matching is given as assigning a vehicle 32 individually to each single ride request, but it is not limited to this case. Multiple single ride requests can be grouped together, and first multiple vehicles 32 can be assigned to the multiple single ride requests, and then matching is performed to individually assign one of the multiple vehicles 32 to each of the multiple single ride requests. In this way, user 2 can quickly board a vehicle 32 at the desired pick-up location.

[0041] (Request for ride-sharing) On the other hand, if user 2 wishes to ride together and requests a ride-sharing service, they will ride in vehicle 32 with other users 2. In ride-sharing, the desired pick-up and drop-off locations for multiple users 2 may differ. Therefore, if the dispatch unit 172 randomly determines the combination of users 2 riding together, the order of pick-up and drop-off, and vehicle 32 transports users 2 according to the determined order, the total distance traveled may become unnecessarily long. In that case, depending on the pick-up and drop-off order of each of the multiple users 2, the advantage of ride-sharing, which is to divide the fare for the same section among multiple users 2, may not be fully utilized, and the transportation cost and the fare per user 2 may increase unnecessarily. In addition, the total distance traveled and travel time are likely to change depending on the pick-up and drop-off order of each of the multiple users 2, so the pick-up and drop-off times for users 2 are not fixed, and it is difficult for users 2 to plan before or after boarding. As a result, user 2 may perceive that even if they share a ride, the fare is not low considering the long and fluctuating travel time, making it difficult for them to see any advantages over riding alone.

[0042] Therefore, in this embodiment, the objective is to transport multiple users 2 at a low cost while suppressing increases and fluctuations in travel time by limiting and fixing the areas and routes in which users 2 can board and alight, and by devising boarding and alighting methods.

[0043] Figure 7 is an explanatory diagram illustrating the driving area 200 and the target driving area 202. In this embodiment, the driving area 200 and the target driving area 202 are set as shown in Figure 7. The driving area 200 represents the area in which a vehicle 32 that may be a vehicle for ride-sharing dispatch travels. Here, the driving area 200 is defined as a highly profitable area where users 2 have a high level of awareness of ride-sharing and a certain number of users 2 who are willing to ride-sharing are expected. The dispatch management system 1 limits the area in which ride-sharing is performed to the driving area 200. Therefore, the ride-sharing rate, which is represented by the number of users 2 riding together in one vehicle 32 as a ride-sharing, can be increased, and the ride-sharing fee set as the fee per person can be reduced accordingly.

[0044] Here, the ride-sharing fee is a fixed fee predetermined for each combination of pick-up and drop-off locations, based on the cost required to carry out the ride-sharing and the expected ride-sharing rate. By making the ride-sharing fee a fixed fee in this way, the fee is determined when User 2 attempts to request a ride-sharing, regardless of the number of other Users 2 who will be riding along. Therefore, User 2 can accept the ride-sharing fee and confidently make a ride-sharing request. Here, the operating area 200 is defined as a highly profitable area where User 2 has a high level of awareness of ride-sharing and a certain number of Users 2 who are willing to ride-sharing are expected. Since a large number of Users 2 can be expected to ride in a single trip, sufficient profit can be expected even with this fixed fee. Therefore, as ride-sharing becomes more widely known, it may be possible to reduce the ride-sharing fee, and through a synergistic effect, it is expected that many Users 2 will utilize ride-sharing.

[0045] In the following explanation, we will use an example where the ride-sharing fare is a predetermined fixed rate. However, the explanation is not limited to this example. It is also possible to adopt a variable fare that changes depending on the number of passengers, such as dividing a fare determined for each combination of pick-up and drop-off locations by the number of users 2 who boarded.

[0046] In this embodiment, a predetermined number of vehicles 32 that are permitted to accommodate ride-sharing are reserved in advance specifically for ride-sharing, and these vehicles 32 may be designated as vehicles that can be dispatched for ride-sharing. Hereinafter, these vehicles 32 that specialize in ride-sharing may be referred to as "ride-sharing vehicles." The dispatch unit 172 assigns ride-sharing dispatch requests, for example, with ride-sharing vehicles as the primary dispatch target. In this embodiment, an example is given in which the dispatch unit 172 primarily dispatches ride-sharing vehicles, but it goes without saying that the dispatch unit 172 may also dispatch ordinary vehicles 32.

[0047] Furthermore, multiple target areas 202 are provided within the driving area 200. The target areas 202 indicate the main areas that serve as targets for ride-sharing. Examples of target areas 202 include stations and facilities where many people pass through. In the example in Figure 7, target areas 202a and 202b are set as target areas 202. In this case, as indicated by arrow A, the ride-sharing vehicle can pick up multiple users 2 in target area 202a, transport multiple users 2 from target area 202a to target area 202b, and drop off multiple users 2 in target area 202b. Also, as indicated by arrow B, the ride-sharing vehicle can pick up multiple users 2 in target area 202b, transport multiple users 2 from target area 202b to target area 202a, and drop off multiple users 2 in target area 202a. In this explanation, we have used an example where there are two target driving areas 202a and 202b within the driving area 200. However, the explanation is not limited to this case; it is also possible to set three or more target driving areas 202.

[0048] In this embodiment, a profitable area where a certain number of users 2 willing to ride together is expected is designated as the target travel area 202, and the main routes for ride-sharing are limited to within the target travel area 202. Therefore, the ride-sharing rate can be increased, and consequently, the ride-sharing fee can be reduced.

[0049] Figure 8 is an explanatory diagram illustrating terminals 204, route 206, spot 208, and candidate trips. Terminals 204 are locations such as stations, facilities, and apartment buildings where a large number of passengers (user 2) are expected to board or alight. For example, there are many places near the target route area 202 where user 2 would like to board or alight. Therefore, terminals 204 are set near the target route area 202. For example, in the example in Figure 8, three terminals 204a, 204b, and 204c are set near the target route area 202a, and three terminals 204d, 204e, and 204f are set near the target route area 202b. Note that among terminals 204, the terminal 204 that serves as the starting point for ride-sharing vehicles is sometimes called the "starting terminal," and the terminal 204 that serves as the ending point for ride-sharing vehicles is sometimes called the "ending terminal." However, the starting and ending points are not limited to Terminal 204; they may also be Spot 208, as described later.

[0050] Furthermore, terminals 204 can be set up not only in the vicinity of the target travel area 202, but also between the target travel area 202 as locations where user 2 wishes to board or alight. For example, in the example in Figure 8, three terminals 204g, 204h, and 204i are set up between target travel area 202a and target travel area 202b. It should be noted that although nine terminals 204a, 204b, 204c, 204d, 204e, 204f, 204g, 204h, and 204i are given and explained here, the number of terminals 204 is not limited to nine.

[0051] The travel route 206 is a route that allows for ride-sharing, connecting terminals 204 located near each of the multiple travel target areas 202. However, there are multiple terminals 204 in the vicinity of each of the travel target areas 202. Therefore, if all routes connecting terminals 204 located near each of the multiple travel target areas 202 are derived, the number of routes becomes enormous. To address this, in this embodiment, a predetermined number of highly profitable routes are extracted from all routes connecting terminals 204 located near each of the multiple travel target areas 202 and designated as the travel route 206. The predetermined number is determined based on the number of ride-sharing users and the number of ride-sharing vehicles associated with the ride-sharing. Alternatively, multiple different highly profitable routes where both the boarding terminal 204 and the alighting terminal 204 are the same can also be designated as the travel route 206. Furthermore, the travel route 206 may be set to include other terminals 204 along its course. In the example shown in Figure 8, six travel routes 206a, 206b, 206c, 206d, 206e, and 206f are set up, connecting terminals 204a and 204b with terminals 204e and 204f.

[0052] Here, the most profitable route is designated as route 206, and the routes on which ride-sharing is implemented are limited to route 206. Therefore, the rate of ride-sharing can be increased, and consequently, ride-sharing fares can be reduced.

[0053] However, if there are many overlapping routes 206 that share the same terminal 204 and spot 208 (described later), there will be many rideshare vehicles traveling on the same route 206, and users 2 who share part of the same route 206 will be dispersed among multiple rideshare vehicles. Therefore, if there are multiple routes with a high overlap rate between terminal 204 and spot 208 (described later), the number of such routes may be limited to form route 206. With this configuration, users 2 who share the same route 206 can be limited to riding in a small number of rideshare vehicles, thereby increasing the rideshare rate and reducing the rideshare fare accordingly.

[0054] In this embodiment, for example, a predetermined number of rideshare vehicles are associated with rideshare passengers, and the vehicles are made to travel back and forth between some terminals 204 located near each of the multiple target travel areas 202, thereby improving the efficiency of transportation for user 2. However, depending on the anticipated route, connections with other travel routes 206 may be poor. For example, the final terminal of a travel route may be far from other terminals 204, and the rideshare vehicles may spend considerable distance and time traveling to the next starting terminal. In this case, the travel time of the rideshare vehicles to the next starting terminal becomes wasted time. Therefore, even if a route is highly profitable, if it has poor connections with other travel routes 206, it may be decided not to designate it as a travel route 206. This configuration makes it possible to improve the efficiency of transportation for user 2.

[0055] In this way, by fixing only the most profitable routes as the route 206, it is possible to transport multiple users 2 at a low cost while suppressing increases and fluctuations in travel time.

[0056] Furthermore, the route 206 may have a time limit. The dispatch unit 172 sets candidate trips, as described later, limited to the pre-set operating hours of the ride-sharing vehicles, for example, between 7:00 and 22:00. However, even within operating hours, if the number of ride-sharing vehicles is less than a predetermined minimum (for example, 3 vehicles), no candidate trips may be set for that time period.

[0057] Spot 208 is a location on the travel route 206 that indicates a place where user 2 can board or alight. Spot 208 is set except in places where boarding is prohibited by law, such as near train stations or bus stops. Spot 208 is also set except in places where boarding or alighting is physically impossible, such as when a guardrail prevents movement from the sidewalk to the roadway. Furthermore, Spot 208 is set at a predetermined distance (e.g., 80m to 100m) or more from adjacent Spot 208. Spot 208 may also be set in a location that is easily recognizable to user 2 by road name, intersection name, road sign, traffic light name, facility name, etc.

[0058] Therefore, once the travel route 206 is set, multiple spots 208 are roughly automatically determined based on the travel route 206. For example, in the example in Figure 8, 10 spots 208a, 208b, 208c, 208d, 206e, 208f, 208g, 208h, 208i, and 208j are set, located on travel routes 206a, 206b, 206c, 206d, 206e, and 206f.

[0059] Furthermore, Terminal 204 is also included in Spot 208 because it is a location on the route 206 and a place where User 2 can board and alight. Although Terminal 204 is an important location in generating the route 206, once the route 206 and Spot 208 are formed, it can only serve as the starting or ending terminal of the route 206, and its function is the same as Spot 208. Therefore, unless there is a need to explain Terminal 204 and Spot 208 separately, Terminal 204 may also be included and referred to as Spot 208.

[0060] In cases where it is necessary to distinguish between boarding and alighting at Spot 208, the Spot 208 used for boarding may be called the "boarding spot," and the Spot 208 used for alighting may be called the "alighting spot." Furthermore, there are Spot 208 locations, such as those near train stations, where alighting is possible but boarding is not.

[0061] Furthermore, even if the starting or ending terminals are different, the routes 206 may partially overlap. In such cases, the spots 208 may also overlap in the overlapping routes 206. In other words, multiple routes 206 may be associated with the same spot 208. This indicates that even if user 2 boards at the same spot 208 and alights at the same spot 208, the routes 206 may not necessarily be the same. Note that while 10 spots 208a, 208b, 208c, 208d, 208e, 208f, 208g, 208h, 208i, and 208j are given as examples here, it goes without saying that the number of spots 208 is not limited to 10.

[0062] A candidate trip is a proposed travel schedule (trip) that associates one of several travel routes 206 with the actual travel period during which the rideshare vehicle will travel. The travel period is expressed as the start time of travel at the starting terminal (e.g., 9:00) to the end time of travel at the final terminal (e.g., 9:15). These start and end times are set to be longer than the time it would take to travel directly from the starting terminal to the final terminal, taking into account the need to pick up and drop off multiple users 2 at intermediate stops 208 and the possibility of encountering traffic congestion.

[0063] In the dispatch management system 1, the acceptance of ride-sharing requests begins a predetermined number of days before the day the ride-sharing service is to take place, for example, four days in advance. Therefore, on a given day, the acceptance of ride-sharing requests for four days later begins, while the acceptance of ride-sharing requests for three days later has already begun the day before.

[0064] When the acceptance of ride-sharing requests begins, no ride-sharing requests have yet been assigned to candidate trips. The dispatch unit 172 assigns each ride-sharing request to a candidate trip whenever it receives one. The dispatch management system 1 may generate the same number of candidate trips as the number of travel routes 206 within the same travel time period, or it may limit the number of candidate trips to less than the number of travel routes 206. In the latter case, the dispatch management system 1 limits the number of candidate trips to less than the number of travel routes 206 based on the past dispatch history of ride-sharing vehicles within the travel time period of the travel area 200, the season, date, weather, etc. Note that within the same time period, the number of travel routes 206 ≤ the number of candidate trips, but since multiple candidate trips are generated in the time direction between 7:00 and 22:00, there is no limit to the number of candidate trips.

[0065] In the dispatch management system 1, a limited number of ride-sharing vehicles are assigned to candidate trips. Therefore, a rough schedule is determined that associates ride-sharing vehicles with candidate trips. As a result, ride-sharing vehicles will pick up user 2 according to this schedule. Consequently, the dispatch management system 1 cannot set candidate trips for times when it is physically impossible for a ride-sharing vehicle to pick up user 2. In this case, it is acceptable not to set candidate trips for time periods (prohibited periods) when it is physically impossible to start a ride-sharing ride due to the location of the ride-sharing vehicle.

[0066] When the dispatch unit 172 receives a ride-sharing request, it refers to several candidate trips for the desired time slot and assigns the ride-sharing request to one of the candidate trips. The dispatch unit 172 confirms the assignment of the ride-sharing request to a candidate trip at a predetermined time before the start of the ride-sharing journey, for example, 25 minutes before, and designates it as a confirmed trip. Here, a confirmed trip is a scheduled operation that associates the route 206 with the transport period, similar to a candidate trip, but differs from a candidate trip in that the scheduled operation is confirmed. In the following, the timing when the assignment of the ride-sharing request to a candidate trip is confirmed (the confirmed trip is determined), which is at a predetermined time before the start of the ride-sharing journey, will simply be referred to as "trip confirmation time." The dispatch unit 172 assigns a ride-sharing vehicle, which is roughly determined by the schedule, to the confirmed trip. However, the dispatching unit 172 may assign to the confirmed trip a ride-sharing vehicle that is closest to the first boarding spot that makes up the confirmed trip route 206 and where user 2 will be boarded (hereinafter sometimes referred to as "the first boarding spot in the confirmed trip").

[0067] When a rideshare vehicle accepts a rideshare request, it heads towards the first pick-up spot on the confirmed trip so as to arrive by the time user 2 picks up at the first pick-up spot on the confirmed trip. In this case, the rideshare vehicle may head towards the first pick-up spot on the confirmed trip via the shortest route.

[0068] (Vehicle dispatch request processing S1) The following details the specific process when User 2 requests a ride-sharing ride, using the dispatch management method explained with reference to Figure 6. First, if User 2 wishes to ride in a ride-sharing vehicle, they submit a ride-sharing request through the user terminal 20 (corresponding to step S1 in Figure 6).

[0069] Figures 9A to 9D are the first to fourth explanatory diagrams illustrating the operation of the user terminal control unit 170. Here, we give an example of assigning a ride-sharing request to a candidate trip based on the desired boarding time of user 2. User 2 launches the user application through the user terminal 20 and performs the operation to request a ride-sharing ride. When user 2 selects the "Select from departure point" button in the message box 230, the ride-sharing request unit 160 of the user terminal 20 displays a map of a predetermined range including the driving area 200 on the display device 124, as shown in Figure 9A, and displays the boarding spot in the driving area 200. The ride-sharing request unit 160 also displays the message "Where will you board from?" in the message box 230 and prompts user 2 to select a boarding spot, for example, "Point A". The ride-sharing request unit 160 transmits the boarding spot selected by user 2 to the ride-sharing management server 50. At this point, it is unclear which direction vehicle 32 should head after passenger 2 has boarded for ride-sharing; therefore, the lane of the boarding spot (which lane the boarding spot is located on) is not restricted.

[0070] The user terminal control unit 170 sends to the user terminal 20 a list of several selectable boarding times for candidate trips available at the boarding spot. The dispatch request unit 160 displays the message "Select departure date and time" in the message box 230, as shown in Figure 9B, and prompts user 2 to select a departure date from "Today," "Tomorrow," and "The day after tomorrow," as well as a boarding time (desired transportation time) from a drum roll. Here, an example is given in which departure dates can be selected from "Today," "Tomorrow," and "The day after tomorrow," allowing selection up to two days from "Today." However, the system is not limited to this example; for example, departure dates from three days in the future, such as four days from "Today," could also be selected. The dispatch request unit 160 sends the boarding time selected by user 2 to the dispatch management server 50.

[0071] The user terminal control unit 170 transmits all selectable drop-off spots to the user terminal 20 for candidate trips that are available for boarding at the boarding spot at the boarding time. The dispatch request unit 160 displays the drop-off spots on the display device 124, as shown in Figure 9C. The user terminal control unit 170 does not transmit drop-off spots to the user terminal 20 for candidate trips that do not include the boarding spot in the candidate trips set for the boarding day. On the other hand, the user terminal control unit 170 transmits drop-off spots to the user terminal 20 for candidate trips that do not include the boarding spot in the candidate trips set for the boarding time. However, if user 2 selects the drop-off spot, the dispatch request unit 160 notifies the user that they cannot drop off at that drop-off spot for the candidate trip at that boarding time. The dispatch request unit 160 displays the message "Where are you going?" in the message box 230 and prompts user 2 to select a drop-off spot, for example, "Point B". The dispatch request unit 160 transmits the drop-off spot selected by user 2 to the dispatch management server 50.

[0072] The user terminal control unit 170 further transmits to the user terminal 20 several candidate trips that allow boarding at the designated boarding spot, alighting at the designated alighting spot, and boarding within a predetermined time range (e.g., -30 minutes to +30 minutes) of the boarding time. The dispatch request unit 160 displays the boarding spot and alighting spot, along with the ride-sharing fare and travel time, on the display device 124, as shown in Figure 9D. At this point, it is not yet determined which candidate trip the user will be assigned to, so the direction the vehicle 32 should go from the boarding spot and the lane at the boarding spot are not yet specified. The dispatch request unit 160 also displays the message "What time will you be riding?" in the message box 230, prompting user 2 to select a candidate trip from a drum roll that allows boarding at the designated boarding spot and alighting at the designated alighting spot. The dispatch request unit 160 transmits the candidate trip selected by user 2 to the dispatch management server 50. In this way, a ride-sharing dispatch request based on the boarding time is assigned to one or more candidate trips.

[0073] In Figure 9D, the boarding time within the travel time is shown as the shortest possible time, for example, "7:36," out of the shortest and longest possible times for the rideshare vehicle to arrive at the boarding spot. This is to avoid making user 2, who is already on board, wait, and to allow user 2 to board immediately as soon as the rideshare vehicle arrives at the boarding spot. On the other hand, the alighting time within the travel time is shown as the longest possible time, for example, "7:56," out of the shortest and longest possible times for the rideshare vehicle to arrive at the alighting spot. This is to avoid disrupting user 2's plans after alighting by showing the longest possible time for the rideshare vehicle to arrive at the alighting spot.

[0074] At this point, since the single candidate trip to which the ride-sharing request will ultimately be assigned has not yet been identified, the user terminal control unit 170 cannot transmit (notify) the candidate trip's route 206, the direction the vehicle 32 should head from the pick-up spot, or the lane of the pick-up spot. Therefore, as shown in Figure 9D, the dispatch request unit 160 can display the pick-up spot and drop-off spot, but cannot display the candidate trip's route 206. However, not limited to this case, when the user terminal control unit 170 causes the dispatch request unit 160 to display the candidate trip's route 206 after the ride-sharing request has been assigned to one or more candidate trips, it may display a route that passes through all terminals 204 and spots 208 in the candidate trip's route 206, regardless of the timing of the assignment. Alternatively, the user terminal control unit 170 may display a route to the dispatch request unit 160 that takes into account shortcuts to terminals 204 and spots 208.

[0075] Figures 10A to 10D are the fifth to eighth explanatory diagrams for illustrating the operation of the user terminal control unit 170. Here, we give an example of assigning a ride-sharing request to a candidate trip based on the desired drop-off time of user 2. When user 2 selects the "Select from destination" button in the message box 230, the ride-sharing request unit 160 of the user terminal 20 displays a map of a predetermined range including the driving area 200 on the display device 124, as shown in Figure 10A, and displays the drop-off spot in the driving area 200. The ride-sharing request unit 160 also displays the message "Where are you going?" in the message box 230 and prompts user 2 to select a drop-off spot, for example, "Point B". The ride-sharing request unit 160 transmits the drop-off spot selected by user 2 to the ride-sharing management server 50. At this point, it is unknown from which direction the vehicle 32 carrying user 2 will head towards the drop-off spot in a ride-sharing arrangement, so the lane of the drop-off spot is not limited.

[0076] The user terminal control unit 170 sends to the user terminal 20 a list of several selectable drop-off time options for candidate trips that can be dropped off at the drop-off spot. The dispatch request unit 160 displays the message "Select arrival date and time" in the message box 230, as shown in Figure 10B, and prompts user 2 to select an arrival date from "Today," "Tomorrow," or "The day after tomorrow," and to select a drop-off time (desired transportation time) from a drum roll. Note that, similar to the departure date, the arrival date may also be selectable from "Today" to a date three days or more in the future. The dispatch request unit 160 sends the drop-off time selected by user 2 to the dispatch management server 50.

[0077] The user terminal control unit 170 transmits to the user terminal 20 all selectable boarding spots for candidate trips that allow disembarking at the designated disembarking spot at the designated disembarking time. The dispatch request unit 160 displays the boarding spots on the display device 124, as shown in Figure 10C. The user terminal control unit 170 does not transmit to the user terminal 20 boarding spots for candidate trips that do not include the designated disembarking spot in the list of candidate trips set for the boarding day. On the other hand, the user terminal control unit 170 transmits to the user terminal 20 boarding spots for candidate trips that do not include the designated disembarking spot in the list of candidate trips set for the designated disembarking time. However, if user 2 selects the boarding spot, the dispatch request unit 160 notifies the user that boarding is not possible at that boarding spot for the candidate trip at that disembarking time. The dispatch request unit 160 displays the message "Where will you board from?" in the message box 230 and prompts user 2 to select a boarding spot, for example, "Point A". The dispatch request unit 160 transmits the pick-up spot selected by user 2 to the dispatch management server 50.

[0078] The user terminal control unit 170 further transmits to the user terminal 20 multiple candidate trips in which the user can board at the boarding spot, alight at the alighting spot, and alight within a predetermined time range (e.g., -30 minutes to +30 minutes) of the alighting time. The dispatch request unit 160 displays the boarding spot and alighting spot, along with the ride-sharing fare and travel time, on the display device 124, as shown in Figure 10D. However, at this point, the single candidate trip to which the ride-sharing dispatch request will ultimately be assigned has not been identified, so the dispatch request unit 160 can display the boarding spot and alighting spot, as shown in Figure 10D, but cannot display the travel route 206 of the candidate trip.

[0079] (Vehicle allocation process S3) In the dispatch management method shown in Figure 6, when user 2 makes a ride-sharing request, the dispatch unit 172 assigns a ride-sharing vehicle to the request (corresponding to step S3 in Figure 6).

[0080] Figures 11 to 13 are explanatory diagrams for explaining the processing of the dispatch unit 172. In Figure 11, for the sake of explanation, three terminals 204a, 204b, and 204c located near the target travel area 202a, three terminals 204d, 204e, and 204f located near the target travel area 202b, and three terminals 204g, 204h, and 204i located between the target travel area 202a and the target travel area 202b are shown. Figure 11 also shows 10 spots 208a, 208b, 208c, 206d, 206e, and 206f located on six travel routes 206a, 206b, 206c, 206d, 206e, and 206f connecting terminals 204a, 204b and terminals 204e and 204f. Here, we will explain ride-sharing in a vehicle traveling from target travel area 202a towards target travel area 202b. In Figure 11, ◎ indicates spot 208 which is terminal 204, and ○ indicates spot 208 which is not terminal 204.

[0081] When the dispatch unit 172 begins accepting ride-sharing requests, it sets up six candidate trips 210a, 210b, 210c, 210d, 210e, and 210f corresponding to the routes 206a, 206b, 206c, 206d, 206e, and 206f, as shown in Figure 11. For the sake of explanation, the six candidate trips 210a, 210b, 210c, 210d, 210e, and 210f are assumed to be in roughly the same time period. As mentioned above, the transportation period (start time to end time) associated with each candidate trip 210 includes a buffer time to allow for multiple users 2 to board and alight at intermediate stops 208.

[0082] After setting each candidate trip 210, the dispatch unit 172 begins accepting ride-sharing requests. The dispatch unit 172 continuously accepts ride-sharing requests using the dispatch request process S1 explained with reference to Figures 9 and 10, and assigns the accepted ride-sharing requests to the candidate trips 210 as needed.

[0083] Suppose that during the relevant time period, user 2a requests a ride-sharing service from terminal 204a to terminal 204d. The dispatch unit 172 assigns terminal 204a as the pick-up spot and terminal 204d as the drop-off spot. In this case, there are three candidate trips 210 (candidate trips 210a, 210b, and 210c) that include both the pick-up and drop-off spots. Therefore, as shown in Figure 12, the dispatch unit 172 assigns the ride-sharing request 240a to any of the three candidate trips 210a, 210b, and 210c. In this way, the dispatch unit 172 simultaneously assigns ride-sharing requests to any one or more candidate trips 210 whose pick-up and drop-off spots are included in the route 206 and whose desired transport time (pick-up time and drop-off time) is included in the transport period. In Figures 12 and beyond, the pick-up locations for ride-sharing request 240 are enclosed by solid lines, and the drop-off locations are enclosed by dashed lines.

[0084] Similarly, suppose user 2b requests a rideshare from terminal 204c to spot 208e. As shown in Figure 12, the dispatch unit 172 assigns a rideshare request 240b to each of the two candidate trips 210a and 210d, with terminal 204c as the pick-up spot and spot 208e as the drop-off spot. In addition, in accordance with user 2c's rideshare request 240c from terminal 204c to terminal 204f, the dispatch unit 172 assigns a rideshare request 240c to each of the three candidate trips 210a, 210b, and 210f, with terminal 204c as the pick-up spot and terminal 204f as the drop-off spot. Furthermore, in accordance with user 2d's ride-sharing request 240d from terminal 204b to spot 208j, the dispatch unit 172 assigns ride-sharing request 240d to both of the two candidate trips 210d and 210e, with terminal 204b as the pick-up spot and spot 208j as the drop-off spot. Also, in accordance with user 2e's ride-sharing request 240e from terminal 204b to terminal 204h, the dispatch unit 172 assigns ride-sharing request 240e to candidate trip 210e, with terminal 204b as the pick-up spot and terminal 204h as the drop-off spot. Furthermore, in accordance with the ride-sharing request 240f from user 2f to terminal 204g to terminal 204e, the dispatch unit 172 assigns the ride-sharing request 240f to both of the two candidate trips 210c and 210e, with terminal 204g as the pick-up spot and terminal 204e as the drop-off spot.

[0085] Then, at the time of trip confirmation, which is a predetermined time before the start of the ride-sharing journey, the dispatch unit 172 determines the allocation of ride-sharing requests 240 to candidate trips 210 in such a way that the number of ride-sharing vehicles assigned to each candidate trip 210 is minimized, that is, in such a way that the ride-sharing rate is maximized. For example, the dispatch unit 172 identifies the candidate trip 210 that has the minimum number of ride-sharing requests 240 assigned to it among all combinations of multiple candidate trips 210 and multiple ride-sharing requests 240. Alternatively, the dispatch unit 172 may determine the allocation of ride-sharing requests 240 to candidate trips 210 in such a way that the number of ride-sharing requests 240 assigned to each candidate trip 210 is maximized, for example, to 2 or more.

[0086] Thus, the dispatch unit 172, for example, as shown by the thick lines in Figure 13, sets candidate trip 210a that enables ride-sharing requests 240a, 240b, and 240c as confirmed trip 212a, and candidate trip 210e that enables ride-sharing requests 240d, 240e, and 240f as confirmed trip 212e.

[0087] When a ride-sharing request is assigned to confirmed trips 212a and 212e, the travel route 206 for the assigned confirmed trips 212a and 212e, the direction the vehicle 32 should head from the pick-up spot, and the lane of the pick-up spot are also identified, and the user terminal control unit 170 can transmit the identified information to the user terminal 20. When the ride-sharing request unit 160 receives the travel route 206, the direction the vehicle 32 should head from the pick-up spot, and the lane of the pick-up spot, it displays this information on the display device 124, for example, on a map. Even if a ride-sharing request is assigned to confirmed trips 212a and 212e, as will be described later, the ride-sharing vehicle may receive new ride-sharing requests until it reaches a predetermined distance before the first pick-up spot on the confirmed trip 212a or 212e, for example, 80m before (arrives). Consequently, a new ride-sharing request may change whether or not the terminals 204 and spot 208 after the first pick-up spot in confirmed trips 212a and 212e are bypassed, potentially altering the actual route. In this case, the user terminal control unit 170 will transmit the modified route 206, the direction the vehicle 32 should head from the pick-up spot based on that route, and the lane of the pick-up spot to the user terminal 20. However, taking into account that the route 206 may be changed in this way, the user terminal control unit 170 may refrain from transmitting (notifying) the route 206, the direction the vehicle 32 should head from the pick-up spot, and the lane of the pick-up spot to the user terminal 20 until the ride-sharing vehicle reaches a predetermined distance before the first pick-up spot in confirmed trips 212a and 212e, and only transmit (notify) this information to the user terminal 20 after the ride-sharing vehicle reaches a predetermined distance before the first pick-up spot in confirmed trips 212a and 212e. In this case, the user terminal control unit 170 may also send (notify) the user terminal 20 of the travel route 206, the direction the vehicle 32 should head from the boarding spot, and the lane of the boarding spot (which lane the boarding spot is set on) to the user terminal 20 when the trip is confirmed or when the vehicle is assigned.Furthermore, when a trip is confirmed or a vehicle is dispatched, the user terminal control unit 170 may transmit (notify) the travel route 206, the direction the vehicle 32 should go from the pickup spot, and the lane of the pickup spot (the exact pickup location) to the user terminal 20, not only to the user 2 who will board at the first pickup spot, but also to other predetermined users 2. In such cases, the user terminal control unit 170 does not necessarily have to transmit (notify) the travel route 206, the direction the vehicle 32 should go from the pickup spot, and the lane of the pickup spot (the exact pickup location) all at once when a trip is confirmed or a vehicle is dispatched. For example, when a trip is confirmed or a vehicle is dispatched, the user terminal control unit 170 may first transmit (notify) the direction the vehicle 32 should go from the pickup spot and the lane of the pickup spot (the exact pickup location) to the user terminal 20, and then transmit (notify) the travel route 206 to the user terminal 20 after reaching a predetermined distance before the first pickup spot. The timing of transmitting each piece of information may be varied.

[0088] Then, when the rideshare vehicle accepts the rideshare dispatch request via confirmed trip 212a, it heads to the first pick-up spot on confirmed trip 212a, namely terminal 204a. The rideshare vehicle will pick up user 2a at terminal 204a at the pick-up time for rideshare dispatch request 240a, pick up users 2b and 2c at terminal 204c at the pick-up times for rideshare dispatch requests 240b and 240c, drop off user 2b at spot 208e at the drop-off time for rideshare dispatch request 240b, drop off user 2a at terminal 204d at the drop-off time for rideshare dispatch request 240a, and drop off user 2c at terminal 204f at the drop-off time for rideshare dispatch request 240c.

[0089] Similarly, when another rideshare vehicle accepts a rideshare request via confirmed trip 212e, it proceeds to the first pick-up spot on confirmed trip 212e, namely terminal 204b. The rideshare vehicle will pick up users 2d and 2e at terminal 204b at the pick-up times specified in rideshare requests 240d and 240e, pick up user 2f at terminal 204g at the pick-up time specified in rideshare request 240f, drop off user 2e at terminal 204h at the drop-off time specified in rideshare request 240e, drop off user 2d at spot 208j at the drop-off time specified in rideshare request 240d, and drop off user 2f at terminal 204e at the drop-off time specified in rideshare request 240f.

[0090] The ride-sharing vehicle will pick up User 2 at the boarding spot. However, if User 2 has not arrived at the boarding spot or is not nearby when the ride-sharing vehicle arrives, the vehicle will wait for a predetermined time, for example, 1 minute, for User 2 to arrive at the boarding spot. Even if the ride-sharing vehicle arrives at the boarding spot before the pre-notified boarding time, the ride-sharing vehicle will wait for User 2 to arrive at the boarding spot until the predetermined time has elapsed from the boarding time. If User 2 does not arrive at the boarding spot after the predetermined time has elapsed, the vehicle will move to the next spot 208 without picking up User 2. This is because, in the case of ride-sharing, other Users 2 will also be riding, and waiting for a late User 2 will not delay the boarding or alighting times of the other Users 2.

[0091] Here, the dispatch unit 172 assigns ride-sharing requests 240 to candidate trips 210 in such a way that the number of ride-sharing vehicles to be assigned is minimized. Therefore, it is possible to minimize the number of ride-sharing vehicles assigned to the same ride-sharing request 240, thereby suppressing increases and fluctuations in travel time and enabling the transportation of multiple users 2 at a low cost.

[0092] Here, we compare the differences in boarding patterns with existing modes of transport such as route buses. For example, with route buses, regardless of whether passengers board at each bus stop, it is not possible to start moving before the predetermined departure time. In this embodiment, as long as the scheduled user 2 is picked up at the boarding spot, it is possible to move to the next spot 208 regardless of the boarding time. Therefore, it is possible to transport multiple users 2 at a low cost while suppressing increases and fluctuations in boarding time.

[0093] In this explanation, we have used an example where the dispatch unit 172 assigns ride-sharing requests 240 to candidate trips 210 in a way that minimizes the number of ride-sharing vehicles to be assigned. However, not limited to this case, if multiple ride-sharing vehicles are available, the number of candidate trips 210 may be limited to the number of available ride-sharing vehicles. In other words, the dispatch unit 172 identifies candidate trips 210 so that the number of candidate trips 210 is equal to the number of ride-sharing vehicles. Therefore, if the number of ride-sharing vehicles is greater than the number of candidate trips 210, there may be cases where the number of candidate trips 210 is not effectively limited.

[0094] Furthermore, if the number of ride-sharing vehicles is fixed and the trip has not yet been finalized, accepting an excessive number of ride-sharing requests 240 could result in the number of finalized trips 212 exceeding the number of ride-sharing vehicles during the same time period. In this case, the dispatch unit 172 may choose not to accept any further ride-sharing requests 240, or it may request that additional ride-sharing vehicles be assigned to the same time period.

[0095] Thus, when candidate trips 210a and 210e become confirmed trips 212a and 212e, the concurrently set candidate trips 210b, 210c, 210d, and 210f become candidate trips 210 that are not executed. Therefore, the dispatch unit 172 removes the candidate trips 210 that did not become confirmed trips 212, such as candidate trips 210b, 210c, 210d, and 210f, from the list of candidates for confirmed trip 212. Here, when a ride-sharing request 240 is received, more candidate trips 210 are set than the number of ride-sharing vehicles, and the candidate trips 210 that did not become confirmed trips 212 are subsequently removed from the list of candidates for confirmed trip 212. Therefore, it is possible to efficiently reduce the number of ride-sharing vehicles while providing many variations of the travel route 206 that user 2 can ride in.

[0096] (Addition of ride-sharing) Once the confirmed trip 212 is determined, the rideshare vehicle will pick up and drop off user 2 according to that confirmed trip 212. However, even after the confirmed trip 212 has been determined, if certain additional conditions are met, a new rideshare dispatch request can be accepted and user 2 can be added to the rideshare.

[0097] One of the additional conditions, related to capacity, is that a ride-sharing vehicle to which a fixed trip 212 is assigned must allow for the addition of user 2 during the ride-sharing. For example, suppose a ride-sharing vehicle has a capacity of 8 people, and fixed trip 212 indicates that 3 user 2 will be riding. In this case, excluding the driver 3 and the 3 user 2, 4 user 2 can be accommodated. On the other hand, if a ride-sharing vehicle has a capacity of 4 people, and fixed trip 212 indicates that 3 user 2 will be riding, then with the driver 3 and the 3 user 2 already on board, it is not possible to add any new user 2.

[0098] Furthermore, one of the additional physical conditions is that the pick-up and drop-off locations for the new ride-sharing request 240 must be on the route 206 of the already confirmed trip 212. Adding ride-sharing means adding the pick-up and drop-off of user 2 on the route 206 of the already confirmed trip 212. Therefore, the dispatch unit 172 will not accept ride-sharing requests 240 that are not on the route 206 of the confirmed trip 212.

[0099] Furthermore, there are two stages of additional time-related conditions. First, the first stage of additional time-related conditions is that a new ride-sharing request 240 is received before the vehicle terminal control unit 174 notifies the ride-sharing vehicle that it has been assigned to confirmed trip 212 (dispatch target notification process S4), and the pick-up and drop-off spots of the new ride-sharing request 240 are located on the route 206 of the candidate trip 210 that has become confirmed trip 212. In this case, the dispatch unit 172 accepts the ride-sharing request 240 where the pick-up spot is after the starting terminal of the candidate trip 210 that has become confirmed trip 212. The schedule is set on the premise that the ride-sharing vehicle can start traveling from the starting terminal of the candidate trip 210. In that case, the ride-sharing vehicle should be able to move to the starting terminal of the candidate trip 210 at the time the vehicle terminal control unit 174 notifies the ride-sharing vehicle that it has been assigned to confirmed trip 212. Therefore, the dispatch unit 172 does not have a problem accepting ride-sharing request 240 where the pick-up spot is at or after the starting terminal of the candidate trip 210.

[0100] While ride-sharing vehicles have a somewhat scheduled schedule, time buffers are included in the confirmed trip 212 to account for delays due to traffic congestion, etc. Therefore, while the trip is confirmed at a predetermined time before the start of the ride-sharing journey, for example 25 minutes before, the timing of the dispatch notification is immediately before the start of the ride-sharing journey, for example 5 minutes before. Here, by accepting ride-sharing dispatch requests 240 until the dispatch notification, the aim is to have as many users 2 as possible ride together and reduce the ride-sharing fare.

[0101] Next, as a second-stage additional time condition, a new ride-sharing request 240 must be received before the ride-sharing vehicle reaches (arrives at) the first pick-up spot in the confirmed trip 212, for example, 80m beforehand, and the pick-up and drop-off spots of the new ride-sharing request 240 must be after the first pick-up spot in the confirmed trip 212. Here, 80m is given as the predetermined distance, but it is not limited to this case, and various values ​​can be set. Also, although a predetermined distance is given as an example here, it is not limited to this case, and a predetermined time, for example, the time obtained by dividing the above predetermined distance by a predetermined speed (for example, the average speed when the ride-sharing vehicle is operating), may be used.

[0102] If the dispatch unit 172 were to accept a ride-sharing request for a ride-sharing vehicle that is a predetermined distance before the first ride-sharing vehicle in the confirmed trip 212, the ride-sharing vehicle would have to change direction or turn back to reach that ride-sharing vehicle. This would force the driver 3 to make significant changes to their travel plan and would also increase the travel time of the ride-sharing vehicle. Therefore, the dispatch unit 172 will not accept ride-sharing dispatch requests for ride-sharing vehicles that have a ride-sharing vehicle that is

[0103] While the trip is confirmed at a predetermined time before the start of the ride-sharing journey, for example 25 minutes before, the timing when the ride-sharing vehicle arrives a predetermined distance before the first pick-up spot in the confirmed trip 212 is just before the start of the ride-sharing journey, for example several tens of seconds before. Here, by accepting ride-sharing dispatch requests 240 until arrival, the aim is to allow as many users 2 as possible to ride together and reduce the ride-sharing fare.

[0104] The reason the final timing for the additional conditions is set as when the ride-sharing vehicle reaches a predetermined distance before the first pick-up spot in confirmed trip 212 is that the details of the ride-sharing contract, namely the ride-sharing user 2 and the pick-up / drop-off spots 208, must be finalized before reaching that predetermined distance.

[0105] Figure 14 is a timing chart illustrating the addition of ride-sharing. Figure 14 shows the aforementioned time-based addition conditions in chronological order. First, when the dispatch unit 172 begins accepting ride-sharing requests, it sets candidate trips 210 and begins accepting ride-sharing requests 240 corresponding to the transportation period of the candidate trips 210. Until the trip is finalized, user 2 can specify spots 208 within the entire range of the pre-set route 206 as pick-up and drop-off spots through the ride-sharing request 240.

[0106] Once a confirmed trip 212 is determined, it is no longer possible to generate a new confirmed trip 212 for that transportation period. Therefore, a new user 2 can only ride along with an already determined confirmed trip 212. Consequently, the available pick-up and drop-off locations for that transportation period are restricted. Here, the restriction on additional ride-sharing changes in two stages.

[0107] In the first stage of adding a ride-sharing passenger, from trip confirmation to dispatch notification, the following two restrictions are imposed: First, the pick-up and drop-off locations desired by user 2 must be located on the route 206 of the candidate trip 210, which has become the confirmed trip 212. Second, the ride-sharing vehicle to which that confirmed trip 212 has been assigned must be in a state where it can accommodate the addition of user 2 for ride-sharing.

[0108] Furthermore, after a ride-sharing notification is issued, the following two restrictions are imposed on the second stage of adding a ride-sharing passenger until the ride-sharing vehicle reaches a predetermined distance before the first pick-up spot on confirmed trip 212, i.e., until it arrives at the destination: First, the pick-up and drop-off spots desired by user 2 must be after the first pick-up spot on confirmed trip 212. Second, the ride-sharing vehicle to which confirmed trip 212 is assigned must be in a state where it can accommodate the addition of user 2 for ride-sharing.

[0109] If these additional conditions are met, User 2 will be able to ride together for the same travel period even after the confirmed trip has been determined, allowing them to quickly take advantage of the discounted ride-sharing option. If the above additional conditions are not met, User 2 can simply make a new ride-sharing request, although the boarding time may be slightly delayed.

[0110] Figure 15 is an explanatory diagram illustrating the processing of the dispatch unit 172. Here, it specifically shows the boarding and alighting procedures when a new user 2 additionally joins the ride after the confirmed trip has been determined.

[0111] Suppose that after a confirmed trip is determined, user 2 makes a ride-sharing request 240g with spot 208c as the boarding spot and spot 208j as the alighting spot before the ride-sharing vehicle reaches a predetermined distance before arriving at the first boarding spot on confirmed trip 212. At this time, if the ride-sharing vehicle associated with confirmed trip 212a allows additional ride-sharing passengers, the dispatch unit 172 assigns the ride-sharing request 240g with spot 208c as the boarding spot and spot 208j as the alighting spot to confirmed trip 212a, as shown by the thick line in Figure 15. In this way, user 2 can board at spot 208c as the fourth passenger and alight at spot 208j as the second passenger, leaving two users 2 behind.

[0112] Once the rideshare vehicle reaches a predetermined distance before arriving at the first pick-up spot on the fixed trip 212, no further users 2 wishing to ride together will be added. In this case, driver 3 only needs to stop at terminals 204 and spots 208 where user 2 should be picked up or dropped off, regardless of the locations of other terminals 204 and spots 208 set on the route 206 of the fixed trip 212. Therefore, driver 3 can travel the shortest route between terminals 204 and spots 208 defined in the fixed trip 212, and can shortcut terminals 204 and spots 208 where user 2 does not need to be picked up or dropped off. However, until the rideshare vehicle reaches a predetermined distance before arriving at the first pick-up spot on the fixed trip 212, driver 3 should not decide to take a shortcut, as there is a possibility of additional users 2 being picked up or dropped off at terminals 204 and spots 208 on the route 206 of the fixed trip 212.

[0113] Thus, the dispatch management device (e.g., dispatch management server 50) that can communicate with the user terminal 20 via the network 6 comprises one or more processors, which set up a plurality of candidate trips 210 to which one of a plurality of predetermined travel routes 206 is associated with a transport period (travel start time to travel end time), receive a dispatch request (e.g., ride-sharing dispatch request 240) from the user terminal 20, and assign the dispatch request in parallel to one or more candidate trips 210 to which the selected pick-up point (e.g., pick-up spot) and selected drop-off point (e.g., drop-off spot) received from the user terminal 20 that made the dispatch request are included in the travel route 206 and the desired transport time (e.g., pick-up time, drop-off time) received from the user terminal 20 that made the dispatch request is included in the transport period, and at a predetermined timing before the transport period (e.g., a predetermined time before the start of the ride-sharing journey), one of the candidate trips 210 to which the dispatch request has been assigned is designated as a confirmed trip 212, and a vehicle (e.g., ride-sharing vehicle) is assigned to the confirmed trip 212. In this way, by limiting and fixing the areas and routes in which user 2 can board and alight, it becomes possible to transport multiple users 2 at a lower cost while suppressing increases and fluctuations in travel time.

[0114] Here, we have provided an example of selecting pick-up and drop-off points from multiple spots represented as locations on a map. However, the process is not limited to this example; ultimately, it is sufficient to select pick-up and drop-off points. For example, pick-up and drop-off points can be selected from multiple spots represented as text points along the route 206 of the selectable candidate trip. In this case, as more ride requests are assigned to the prepared candidate trips, the number of candidate trips that can be assigned to subsequent ride requests decreases. Also, once pick-up and drop-off points are entered, the candidate trips to which ride requests can be assigned are limited to those that allow pick-up and drop-off at those selected points.

[0115] The processor may identify candidate trips 210 in parallel for each of multiple ride-sharing requests (e.g., ride-sharing requests 240) to minimize the number of candidate trips 210 assigned to each request, and may designate the identified candidate trips 210 as confirmed trips 212. This configuration makes it possible to minimize the number of ride-sharing vehicles assigned to the same ride-sharing request 240, thereby suppressing increases and fluctuations in ride time and enabling the transportation of multiple users 2 at a lower cost.

[0116] The processor may identify candidate trips 210 such that the number of ride-sharing requests (e.g., ride-sharing requests 240) assigned to candidate trips is 2 or more, and may designate the identified candidate trips 210 as confirmed trips 212. With this configuration, it is possible to minimize the number of ride-sharing vehicles assigned to the same ride-sharing request 240, thereby suppressing increases and fluctuations in travel time and enabling the transportation of multiple users 2 at a low cost.

[0117] The number of candidate trips 210 set is greater than or equal to the number of vehicles (e.g., carpooling vehicles), and the processor may remove candidate trips 210 that did not become confirmed trips 212 from the list of candidates for confirmed trip 212. This configuration makes it possible to efficiently reduce the number of carpooling vehicles while providing many variations of the travel route 206 that user 2 can carpool on.

[0118] Even after determining the confirmed trip 212, the processor may accept a new dispatch request (for example, a ride-sharing dispatch request 240) if certain additional conditions are met, and assign the dispatch request to the confirmed trip 212. With this configuration, user 2 can take a ride-sharing ride for the same transportation period even after the confirmed trip has been determined, so that they can quickly take advantage of the discounted ride-sharing service.

[0119] An additional condition may be that the vehicle to which the confirmed trip 212 is assigned allows for the addition of user 2 in a ride-sharing arrangement. This configuration allows for the imposition of additional capacity-related conditions.

[0120] An additional condition may be that the pick-up location (e.g., pick-up spot) and drop-off location (e.g., drop-off spot) of a new ride request (e.g., ride-sharing request 240) are located on the route of the confirmed trip 212. This configuration allows for the imposition of additional physical conditions.

[0121] An additional condition may be that a new ride request (e.g., ride-sharing request 240) is received before notification (e.g., ride-sharing notification) that the confirmed trip 212 has been assigned to a vehicle (e.g., a ride-sharing vehicle), and that the pick-up location (e.g., pick-up spot) and drop-off location (e.g., drop-off spot) of the new ride request are located on the route 206 of the candidate trip 210 that became the confirmed trip 212. This configuration allows for the imposition of additional time-related conditions.

[0122] An additional condition may be that a new ride request (e.g., ride-sharing request 240) is received before the vehicle (e.g., ride-sharing vehicle) reaches a predetermined distance before the first pick-up location (e.g., pick-up spot) on the confirmed trip 212, and that the pick-up and drop-off locations (e.g., drop-off spot) of the new ride request are after the first pick-up location on the confirmed trip 212. This configuration allows for the imposition of additional time-related conditions.

[0123] In this embodiment, the dispatch management method involves a computer setting up a plurality of candidate trips 210, each associated with one of a plurality of predetermined travel routes 206 and a transportation period (start time to end time of travel). The computer receives a dispatch request (e.g., a ride-sharing dispatch request 240) from a user terminal 20. The computer assigns the dispatch request in parallel to one or more candidate trips 210 whose selected pick-up point (e.g., pick-up spot) and selected drop-off point (e.g., drop-off spot) received from the user terminal 20 are included in the travel route 206, and whose desired transportation time (e.g., pick-up time, drop-off time) received from the user terminal 20 is included in the transportation period. At a predetermined timing before the transportation period (e.g., a predetermined time before the start of the ride-sharing journey), one of the candidate trips 210 to which the dispatch request has been assigned is designated as a confirmed trip 212, and a vehicle (e.g., a ride-sharing vehicle) is assigned to the confirmed trip 212. In this way, by limiting and fixing the areas and routes in which user 2 can board and alight, it becomes possible to transport multiple users 2 at a lower cost while suppressing increases and fluctuations in travel time.

[0124] The program of this embodiment causes the computer to set up a plurality of candidate trips 210, each associated with one of a plurality of predetermined travel routes 206 and a transport period (start time to end time of travel), receive a dispatch request (e.g., a ride-sharing dispatch request 240) from a user terminal 20, and assign the dispatch request in parallel to one or more candidate trips 210, where the selected pick-up point (e.g., pick-up spot) and selected drop-off point (e.g., drop-off spot) received from the user terminal 20 that made the dispatch request are included in the travel route 206, and the desired transport time (e.g., pick-up time, drop-off time) received from the user terminal 20 that made the dispatch request is included in the transport period, and at a predetermined timing before the transport period (e.g., a predetermined time before the start of the ride-sharing journey), it causes one of the candidate trips 210 to which the dispatch request has been assigned to become a confirmed trip 212, and assigns a vehicle (e.g., a ride-sharing vehicle) to the confirmed trip 212. In this way, by limiting and fixing the areas and routes in which user 2 can board and alight, it becomes possible to transport multiple users 2 at a lower cost while suppressing increases and fluctuations in travel time.

[0125] (Section without passengers) Figure 16 is an explanatory diagram illustrating the processing of the dispatch unit 172. As shown in Figures 11 to 13, the dispatch unit 172 assigns a ride-sharing vehicle to a ride-sharing request 240. For example, as shown in Figure 16, the dispatch unit 172 assigns a ride-sharing request 240h from user 2h to terminal 204a to terminal 204h to any of the two candidate trips 210b and 210c, with terminal 204a as the pick-up spot and terminal 204h as the drop-off spot. Also, the dispatch unit 172 assigns a ride-sharing request 240i from user 2i to terminal 204c to terminal 204g to any of the three candidate trips 210c, 210e, and 210f, with terminal 204c as the pick-up spot and terminal 204g as the drop-off spot. Furthermore, the dispatch unit 172, in accordance with the ride-sharing request 240j from user 2j from spot 208j to terminal 204e, assigns the ride-sharing request 240j to any of the three candidate trips 210c, 210d, and 210e, with spot 208j as the pick-up spot and terminal 204e as the drop-off spot.

[0126] Then, at the time of trip confirmation, which is a predetermined time before the start of the ride-sharing journey, the dispatch unit 172 confirms the assignment of ride-sharing requests 240 to candidate trips 210 so as to minimize the number of ride-sharing vehicles to be assigned. For example, as shown by the thick lines in Figure 16, the dispatch unit 172 sets candidate trip 210c, which enables ride-sharing requests 240h, 240i, and 240j, as confirmed trip 212c. In this way, it becomes possible to realize ride-sharing requests 240h, 240i, and 240j with a single ride-sharing vehicle.

[0127] However, in this confirmed trip 212c, the rideshare vehicle picks up user 2h at terminal 204a at the boarding time for rideshare request 240h, picks up user 2i at terminal 204c at the boarding time for rideshare request 240i, drops off user 2i at terminal 204g at the drop-off time for rideshare request 240i, drops off user 2h at terminal 204h at the drop-off time for rideshare request 240h, picks up user 2j at spot 208j at the boarding time for rideshare request 240j, and drops off user 2j at terminal 204e at the drop-off time for rideshare request 240j. In other words, after dropping off user 2h at terminal 204h, there is a section without any passengers until user 2j is picked up at spot 208j. Even if ride-sharing requests are accepted until the number of users 2 riding together reaches its maximum at the same time, this does not eliminate the possibility of empty sections of the route occurring at a later time.

[0128] In such sections with no passengers, driver 3 must pick up user 2j at the next stop 208j, so he cannot drive the rideshare vehicle while searching for user 2 who wants to ride alone, a practice known as "cruising for passengers." Furthermore, even if user 2 happens to be at stop 208 and wants to ride together, the confirmed trip 212c may not include the drop-off stop that user 2 desires. Even if the confirmed trip 212c includes the drop-off stop that user 2 desires, picking up user 2 may prevent the original user 2 from having a seat later on. Thus, while the rideshare vehicle has space to pick up user 2 in sections with no passengers, it is difficult to pick up user 2 again. Technically, it is possible to accept user 2 to the extent that it does not disrupt subsequent operations, up until just before a section with no passengers occurs, but considering the low probability of such an event occurring and the cost-effectiveness, it is decided not to pick up user 2 in sections with no passengers.

[0129] Thus, if it is not possible to board User 2 in the section without passengers, the passenger status of User 2 in the section with passengers will be divided into sections with passengers, sections without passengers, and sections with passengers when the ride-sharing vehicle reaches a predetermined distance before the first boarding spot in the fixed trip 212. In this case, when setting a fixed fare or fare based on the cost required to carry out ride-sharing and the expected ride-sharing rate for each combination of boarding and alighting locations, and then dividing the fare by the number of Users 2 who were riding in the section with passengers, the question arises as to who will bear the fare for the section without passengers, which is part of the fixed trip 212. Therefore, in this embodiment, the fixed trip 212 is managed so that it does not include any sections without passengers.

[0130] Figure 17 is a flowchart illustrating the trip splitting process. When the dispatch unit 172 determines the confirmed trip 212, it determines whether it has reached a predetermined timing, for example, when the dispatch target notification is issued (S10). The dispatch unit 172 repeats the process in step S10 until the predetermined timing is reached (NO in S10). When the predetermined timing is reached (YES in S10), the dispatch unit 172 determines whether the determined confirmed trip 212 has any sections without passengers (S11). If the confirmed trip 212 has sections without passengers (YES in S11), the dispatch unit 172 splits the confirmed trip 212 with the sections without passengers into multiple sections so that no sections without passengers occur (S12). The dispatch unit 172 then repeats the process from step S11 until there are no more confirmed trips 212 with sections without passengers. If there is no confirmed trip 212 with no passengers (NO in S11), the dispatch unit 172 terminates the trip splitting process.

[0131] The reason why the predetermined timing is set to the time when the vehicle terminal control unit 174 notifies the ride-sharing vehicle that it has been assigned to the confirmed trip 212 is as follows: The more ride-sharing requests 240 there are, the higher the ride-sharing rate of the ride-sharing vehicle tends to be. Therefore, the longer the time that ride-sharing requests 240 are accepted, the higher the ride-sharing rate becomes and the lower the possibility of sections without passengers. However, since the candidate trip 210 is set in advance, the start time of ride-sharing is also fixed, and it is not possible to accept ride-sharing requests 240 indefinitely. However, as mentioned above, at the time when the vehicle terminal control unit 174 notifies the ride-sharing vehicle that it has been assigned to the confirmed trip 212, the ride-sharing vehicle can move to the starting terminal of the candidate trip 210, so there is no problem in accepting ride-sharing requests 240 where the boarding spot is after the starting terminal of the candidate trip 210. Therefore, here, the predetermined timing is set to the time of the ride-sharing notification, and ride-sharing requests 240 are accepted for as long as possible.

[0132] In this example, the designated timing is defined as the time of dispatch notification, but it is not limited to this example; it may also be the time of trip confirmation or acceptance response. Furthermore, from the perspective that accepting ride-sharing request 240 where the boarding spot is after the starting terminal of candidate trip 210 does not pose a problem, the designated timing may be set to the time when the ride-sharing vehicle arrives a predetermined distance before the first boarding spot in confirmed trip 212. Moreover, the designated timing is not limited to the time of dispatch notification, trip confirmation, acceptance response, or the predetermined distance before the first boarding spot; various timings can be adopted as the designated timing, such as an opportunity or time for some kind of processing to be performed before the time when the ride-sharing vehicle arrives a predetermined distance before the first boarding spot in confirmed trip 212. With this configuration, ride-sharing request 240 can be accepted at least until trip confirmation, thus reducing the possibility of sections without passengers.

[0133] Figure 18 is an explanatory diagram illustrating the processing of the dispatch unit 172. The ride-sharing requests 240h, 240i, and 240j in Figure 18 are equivalent to the ride-sharing requests 240h, 240i, and 240j in Figure 16. Therefore, when a dispatch target notification is issued, the dispatch unit 172 sets the one candidate trip 210c that enables the ride-sharing requests 240h, 240i, and 240j as the confirmed trip 212c, as shown by the thick line in Figure 16. However, in the confirmed trip 212c, the section from terminal 204h to spot 208j is a section with no passengers. Therefore, the dispatch unit 172 splits the confirmed trip 212 into two.

[0134] Specifically, the dispatch unit 172 divides the fixed trip 212 into sections before and after the section without passengers. Specifically, the dispatch unit 172 sets a new fixed trip 212c-1, which corresponds to the section before the section without passengers, from terminal 204a where user 2h boards to terminal 204h where user 2h alights. The dispatch unit 172 also sets a new fixed trip 212c-2, which corresponds to the section after the section without passengers, from spot 208j where user 2j boards to terminal 204e where user 2j alights.

[0135] In confirmed trip 212c-1, the rideshare vehicle picks up user 2h at terminal 204a at the pick-up time specified in rideshare request 240h, picks up user 2i at terminal 204c at the pick-up time specified in rideshare request 240i, drops off user 2i at terminal 204g at the drop-off time specified in rideshare request 240i, and drops off user 2h at terminal 204h at the drop-off time specified in rideshare request 240h. At this point, the rideshare boarding under confirmed trip 212 is temporarily terminated. Then, in confirmed trip 212c-2, the same rideshare vehicle picks up user 2j again at spot 208j at the pick-up time specified in rideshare request 240j, and drops off user 2j at terminal 204e at the drop-off time specified in rideshare request 240j. By dividing the fixed trip 212 in this way and excluding the sections without passengers in between, it becomes possible to eliminate the sections without passengers and enable ride-sharing at an appropriate fare.

[0136] Furthermore, as shown in Figure 18, if the fixed trip 212 is divided into fixed trip 212c-1 and fixed trip 212c-2, the dispatch unit 172 may accept new (additional) ride-sharing requests only for the section between spot 208, which is the starting point of fixed trip 212, and spot 208, which is the ending point of fixed trip 212, for the divided fixed trips 212c-1 and 212c-2.

[0137] Alternatively, to avoid creating a section without passengers in confirmed trip 212, one could consider not accepting ride-sharing request 240, which would result in a section without passengers.

[0138] Figures 19 and 20 are explanatory diagrams illustrating the processing of the dispatch unit 172. For example, as shown in Figure 19, the dispatch unit 172, in accordance with the first ride-sharing request 240h from user 2h from terminal 204a to terminal 204h, assigns the ride-sharing request 240h to either of the two candidate trips 210b and 210c, with terminal 204a as the pick-up spot and terminal 204h as the drop-off spot. At this point, the two candidate trips 210b and 210c may become the confirmed trip 212.

[0139] Next, as shown in Figure 19, the dispatch unit 172, in accordance with the second and subsequent ride-sharing request 240i from user 2i to terminal 204c to terminal 204g, provisionally assigns a ride-sharing request 240i to each of the three candidate trips 210c, 210e, and 210f, with terminal 204c as the pick-up spot and terminal 204g as the drop-off spot.

[0140] At this time, the dispatch unit 172 determines whether there is a common candidate trip 210 between the candidate trips 210c, 210e, and 210f to which the second and subsequent ride-sharing requests 240i are assigned, and the candidate trips 210b and 210c of the first ride-sharing request 240h. Here, a common candidate trip 210 means that the pick-up spot, drop-off spot, and desired transport time for ride-sharing requests 240h and 240i are included in the same candidate trip 210's route 206 and transport period. In this case, ride-sharing requests 240h and 240i are both assigned to candidate trip 210c. Therefore, the dispatch unit 172 determines that there is a common candidate trip 210 for ride-sharing requests 240h and 240i.

[0141] Next, the dispatch unit 172 determines whether the ride times of ride-sharing requests 240h and 240i overlap at least partially in the common candidate trip 210c. In this case, users 2h and 2i will be riding together from terminal 204c to terminal 204g. Therefore, the dispatch unit 172 determines that the ride times of ride-sharing requests 240h and 240i overlap at least partially in the common candidate trip 210c. Thus, if ride-sharing requests 240h and 240i have a common candidate trip 210, and the ride times of ride-sharing requests 240h and 240i overlap at least partially in the common candidate trip 210c, the dispatch unit 172 formally assigns user 2i's ride-sharing request 240i from terminal 204c to terminal 204g to the three candidate trips 210c, 210e, and 210f. In this way, the dispatch unit 172 is configured to accept ride-sharing requests 240 in which at least some of the ride times overlap, thus eliminating the possibility of empty sections in the confirmed trip 212.

[0142] Next, as shown in Figure 20, the dispatch unit 172, in accordance with the ride-sharing request 240j from user 2j from spot 208j to terminal 204e, provisionally assigns the ride-sharing request 240j to each of the three candidate trips 210c, 210d, and 210e, with spot 208j as the pick-up spot and terminal 204e as the drop-off spot.

[0143] The dispatch unit 172 determines whether there are any candidate trips 210 that are common to the candidate trips 210c, 210d, and 210e that are provisionally assigned to the second and subsequent ride-sharing requests 240j, and to the candidate trips 210b and 210c of the first ride-sharing request 240h. In this case, ride-sharing requests 240h and 240j are both assigned to candidate trip 210c. Therefore, the dispatch unit 172 determines that there is a common candidate trip 210 for ride-sharing requests 240h and 240j.

[0144] Next, the dispatch unit 172 determines whether the ride times of ride-sharing requests 240h and 240j overlap at least partially in the common candidate trip 210c. However, the ride times of ride-sharing requests 240h and 240j do not overlap. Therefore, the dispatch unit 172 determines that the ride times of ride-sharing requests 240h and 240j do not overlap in the common candidate trip 210c. The dispatch unit 172 then invalidates the provisional assignment of ride-sharing request 240j to candidate trip 210c and prohibits its assignment to candidate trip 210c, as indicated by the "×" in Figure 20.

[0145] Even if the dispatch unit 172 prohibits assigning the ride-sharing request 240j to candidate trip 210c, it may still assign the ride-sharing request 240j to another candidate trip 210 if there are other candidate trips 210 to which it can be assigned. For example, in accordance with the ride-sharing request 240j from user 2j from spot 208j to terminal 204e, the dispatch unit 172 assigns the ride-sharing request 240j to either of the other two candidate trips 210d and 210e, with spot 208j as the pick-up spot and terminal 204e as the drop-off spot. In this way, the dispatch unit 172 can set a confirmed trip 212d that enables the ride-sharing request 240j, for example, as shown by the thick line on the right in Figure 20.

[0146] By configuring the system so that ride-sharing requests that would result in empty sections are not assigned to the same candidate trip 210c, it becomes possible to eliminate empty sections and realize ride-sharing at an appropriate fare.

[0147] Thus, the dispatch management device (e.g., dispatch management server 50) that can communicate with the user terminal 20 via the network 6 comprises one or more processors, and the processor sets up multiple candidate trips 210, each of which is associated with one of a predetermined number of travel routes 206 and a travel period (start time to end time of travel), receives a dispatch request (e.g., ride-sharing dispatch request 240) from the user terminal 20, and the dispatch request is made if the selected pick-up point (e.g., pick-up spot) and selected drop-off point (e.g., drop-off spot) received from the user terminal 20 that made the dispatch request are included in the travel route 206, and the dispatch request was made The system assigns a dispatch request to a candidate trip 210 that includes the desired transportation time (e.g., boarding time, alighting time) received from the user terminal 20 within the transportation period. At a first timing prior to the transportation period (e.g., when the trip is confirmed), the candidate trip 210 to which the dispatch request has been assigned becomes the confirmed trip 212. At a second timing after the first timing (e.g., when a dispatch target is notified), the system determines whether there are any unpassenger sections in the confirmed trip 212 where user 2 is not on board. If there are unpassenger sections, the confirmed trip 212 is divided so that no unpassenger sections occur, and a vehicle (e.g., a ride-sharing vehicle) is assigned to the confirmed trip 212. By dividing the confirmed trip 212 in this way and excluding the unpassenger sections in between, it becomes possible to eliminate unpassenger sections and realize ride-sharing at an appropriate fare.

[0148] The second timing may be after the first timing (for example, when the trip is confirmed) and may be the timing when a vehicle (for example, a ride-sharing vehicle) is assigned to the confirmed trip 212 and notification is given (for example, a dispatch notification). In this way, by extending the time for accepting ride-sharing dispatch requests 240, the ride-sharing rate can be increased and the possibility of sections without passengers can be reduced.

[0149] The second timing may be after the first timing (for example, when the trip is confirmed) and the timing when the vehicle (for example, a ride-sharing vehicle) arrives a predetermined distance (for example, 80m) before the first boarding spot in the confirmed trip 212. In this way, by extending the time for accepting ride-sharing requests 240, the ride-sharing rate can be increased and the possibility of sections without passengers can be reduced.

[0150] The second timing may be the first timing (for example, when the trip is confirmed). With this configuration, ride-sharing requests 240 can be accepted at least until the trip is confirmed, thus reducing the possibility of sections without passengers.

[0151] A dispatch management device that can communicate with a user terminal via a network, comprising one or more processors, wherein the processor sets up multiple candidate trips 210, each associated with one of a predetermined number of travel routes 206 and a travel period (start time to end time of travel), receives a dispatch request (e.g., a ride-sharing dispatch request 240) from a user terminal 20, and if the dispatch request is the first dispatch request, the pick-up location (e.g., pick-up spot) and drop-off location (e.g., drop-off spot) received from the user terminal 20 that made the dispatch request are included in the travel route 206, and the user terminal 20 that made the dispatch request The first dispatch request is assigned to the first candidate trip whose requested transportation time (e.g., boarding time, alighting time) is included in the transportation period. If the dispatch request is the second or later dispatch request, it is assigned to the first candidate trip on the condition that the selected boarding and alighting points are included in the route 206, the requested transportation time is included in the transportation period, and at least part of the boarding time overlaps with the first dispatch request. At a predetermined time before the transportation period (e.g., when the trip is finalized), the first candidate trip to which the dispatch request was assigned becomes the finalized trip 212, and a vehicle is assigned to the finalized trip 212. By configuring the system in this way to avoid assigning ride-sharing requests that would result in sections without passengers to the same candidate trip 210, it is possible to eliminate sections without passengers and realize ride-sharing at an appropriate fare.

[0152] The processor may assign the second or subsequent ride request to a second candidate trip if the ride request is the second or subsequent ride request and does not overlap with the first ride request in terms of travel time, provided that the selected pick-up point (e.g., pick-up spot) and the selected drop-off point (e.g., drop-off spot) are included in the route 206 and the desired transport time is included in the transport period. At a predetermined time before the transport period (e.g., when the trip is finalized), the processor may then designate the second candidate trip to which the ride request was assigned as the finalized trip 212. This configuration makes it possible to eliminate sections without passengers and realize ride-sharing at an appropriate fare.

[0153] The dispatch management method of this embodiment involves a computer setting up multiple candidate trips 210, each associated with one of a predetermined number of travel routes 206 and a transportation period (start time to end time of travel), receiving a dispatch request (e.g., a ride-sharing dispatch request 240) from a user terminal 20, and selecting a travel route 206 that includes the pick-up location (e.g., pick-up spot) and drop-off location (e.g., drop-off spot) received from the user terminal 20 that made the dispatch request, and then selecting a desired transportation time (e.g., pick-up time) received from the user terminal 20 that made the dispatch request. A dispatch request is assigned to a candidate trip 210 whose transport period includes the time (time, disembarkation time). At the first timing prior to the transport period (e.g., when the trip is finalized), the candidate trip 210 to which the dispatch request has been assigned becomes the final trip 212. At the second timing after the first timing (e.g., when a dispatch target is notified), it is determined whether there are any unpassenger sections in the final trip 212 where user 2 is not on board. If there are unpassenger sections, the final trip 212 is divided so that no unpassenger sections occur, and a vehicle (e.g., a ride-sharing vehicle) is assigned to the final trip 212. By dividing the final trip 212 in this way and excluding the unpassenger sections in between, it is possible to eliminate unpassenger sections and realize ride-sharing at an appropriate fare.

[0154] The program of this embodiment sets up multiple candidate trips 210 in the computer, each associated with one of a predetermined number of travel routes 206 and a transport period (start time to end time of travel), receives a dispatch request (e.g., a ride-sharing dispatch request 240) from a user terminal 20, and checks if the selected pick-up point (e.g., pick-up spot) and selected drop-off point (e.g., drop-off spot) received from the user terminal 20 that made the dispatch request are included in the travel route 206, and the desired transport time (e.g., pick-up time, drop-off time) received from the user terminal 20 that made the dispatch request The dispatch request is assigned to candidate trip 210 that includes the vehicle time within the transport period. At the first timing prior to the transport period (for example, when the trip is finalized), the candidate trip 210 to which the dispatch request was assigned becomes the final trip 212. At the second timing after the first timing (for example, when a dispatch target is notified), it is determined whether there are any unpassenger sections in the final trip 212 where user 2 is not on board. If there are unpassenger sections, the final trip 212 is divided so that no unpassenger sections occur, and a vehicle (for example, a ride-sharing vehicle) is assigned to the final trip 212. By dividing the final trip 212 in this way and excluding the unpassenger sections in between, it is possible to eliminate unpassenger sections and realize ride-sharing at an appropriate fare.

[0155] The dispatch management method of this embodiment involves a computer setting up multiple candidate trips 210, each associated with one of a predetermined number of travel routes 206 and a transportation period (start time to end time of travel), receiving a dispatch request (e.g., a ride-sharing dispatch request 240) from a user terminal 20, and if the dispatch request is the first dispatch request, the selected pick-up point (e.g., pick-up spot) and selected drop-off point (e.g., drop-off spot) received from the user terminal 20 that made the dispatch request are included in the travel route 206, and the desired transportation time (e.g., The first dispatch request is assigned to the first candidate trip whose boarding time and alighting time are included in the transport period. If the dispatch request is the second or later dispatch request, it is assigned to the first candidate trip on the condition that the selected boarding and alighting points are included in the route 206, the desired transport time is included in the transport period, and at least part of the boarding time overlaps with the first dispatch request. At a predetermined time before the transport period (for example, when the trip is finalized), the first candidate trip to which the dispatch request was assigned becomes the finalized trip 212, and a vehicle is assigned to the finalized trip 212. By configuring the system so that ride-sharing dispatch requests that would result in sections without passengers are not assigned to the same candidate trip 210, sections without passengers are eliminated, and ride-sharing becomes possible at an appropriate fare.

[0156] The program of this embodiment sets up multiple candidate trips 210 in the computer, each associated with one of a predetermined number of travel routes 206 and a transport period (start time to end time of travel). It receives a dispatch request (e.g., a ride-sharing dispatch request 240) from a user terminal 20. If the dispatch request is the first dispatch request, the selected pick-up point (e.g., pick-up spot) and selected drop-off point (e.g., drop-off spot) received from the user terminal 20 that made the dispatch request are included in the travel route 206, and the desired transport time (e.g., pick-up time, drop-off time) received from the user terminal 20 that made the dispatch request is also included. The first dispatch request is assigned to the first candidate trip whose disembarkation time falls within the transport period. If the dispatch request is the second or later dispatch request, it is assigned to the first candidate trip on the condition that the selected boarding and disembarking points are included in the route 206, the desired transport time is included within the transport period, and at least a portion of the boarding time overlaps with the first dispatch request. At a predetermined time before the transport period (for example, when the trip is finalized), the first candidate trip to which the dispatch request was assigned is designated as the finalized trip 212, and a vehicle is assigned to the finalized trip 212. By configuring the system in this way to avoid assigning ride-sharing requests that would result in sections without passengers to the same candidate trip 210, sections without passengers are eliminated, and ride-sharing becomes possible at an appropriate fare.

[0157] (Call now) As described above, User 2 can travel either alone or with other passengers. For the sake of explanation, transporting User 2 traveling alone may be referred to as "individual transport," and the vehicle 32 carrying User 2 alone may be referred to as "individual transport vehicle." Individual transport is achieved by establishing a one-to-one correspondence between vehicle 32 (individual transport vehicle) and dispatch request (individual dispatch request). Similarly, transporting User 2 traveling with other passengers may be referred to as "shared transport," or simply "shared transport," and the vehicle 32 carrying User 2 may be referred to as "shared transport vehicle." Shared transport is achieved by establishing a correspondence between one vehicle 32 (shared transport vehicle) and one or more dispatch requests (shared transport requests).

[0158] As described above, the dispatch unit 172 begins accepting ride-sharing requests (hereinafter, ride-sharing requests booked in advance may be referred to as reserved ride-sharing requests) a predetermined date before the day the ride-sharing service is to be performed, and assigns each ride-sharing request (reserved ride-sharing request) to a candidate trip 210. Then, when the trip is finalized a predetermined time before the start of the ride-sharing service (for example, 25 minutes before the start of the service), the dispatch unit 172 finalizes the assignment of the ride-sharing request (reserved ride-sharing request) to the candidate trip 210, making it the final trip 212. Furthermore, even after the final trip 212 has been determined, the dispatch unit 172 can accept new ride-sharing requests and add a ride-sharing user 2 if predetermined additional conditions (for example, additional conditions related to capacity, physical additional conditions, and additional conditions related to time) are met. For the sake of explanation, adding a ride-sharing user 2 may be referred to as ride-sharing addition.

[0159] In ride-sharing vehicles, the more users 2 transported in a single trip (e.g., a confirmed trip), the higher the transportation efficiency. Therefore, in ride-sharing vehicles, it is desirable to add more users 2 even after the ride-sharing transportation plan has been decided (e.g., after the confirmed trip has been decided).

[0160] Therefore, in a situation where user 2 wants a ride immediately, the dispatch unit 172 may suggest ride-sharing in addition to solo rides to user terminal 20 before user terminal 20 makes a ride request. For example, user terminal 20 may send solo ride information to the dispatch management server 50 before making a ride request, which is information that includes the user's current desire for a solo ride (information entered for solo rides). When the dispatch unit 172 receives solo ride information from user terminal 20, it may present user terminal 20 with selectable individual transport information, which represents information about a transport plan for individual transport that associates vehicle 32 with the solo ride information on a one-to-one basis, and also present user terminal 20 with selectable ride-sharing transport information, which represents information about a transport plan for ride-sharing that associates one or more ride requests and solo ride information with one vehicle 32. The dispatch unit 172 may also present a lower fare for ride-sharing than for individual transport.

[0161] This allows not only individual transport information but also ride-sharing transport information to be presented to the user terminal 20, encouraging user 2 to use ride-sharing. When user 2 selects the presented ride-sharing transport information, a ride-sharing addition occurs, which can increase the frequency of ride-sharing additions and improve the transport efficiency of the ride-sharing vehicle. In addition, by selecting ride-sharing transport information, user 2 can reduce the amount paid compared to selecting individual transport information.

[0162] Figures 21A to 21D and 22A to 22C are explanatory diagrams illustrating an example of the operation of the user terminal control unit 170. Here, we will give an example where user 2 requests a ride immediately. When user 2 launches the user application through the user terminal 20, the user terminal control unit 170 displays the main screen shown in Figure 21A on the display device 124.

[0163] As shown in Figure 21A, the main screen displays a map of a predetermined area including User 2's current location. The main screen also displays one or more tabs, including, for example, a dispatch request settings tab 310 labeled "Call Now". When User 2 selects the dispatch request settings tab 310, a message box 320 is displayed, as shown in Figure 21A. The message box 320 displays a pick-up location input box 322 where the pick-up location can be entered, a drop-off location input box 324 where the drop-off location can be entered, and a proceed button 326 labeled "Next". As shown in Figure 21A, User 2 can select the pick-up location input box 322 and enter the pick-up location. Note that User 2's current location may be pre-filled as the pick-up location in the pick-up location input box 322.

[0164] As shown in Figure 21B, User 2 can select the drop-off location input box 324 and enter the drop-off location. Alternatively, the drop-off location may be entered into the drop-off location input box 324 when both the drop-off location input box 324 and a location on the map are selected.

[0165] When the dispatch request settings tab 310 labeled "Call Now" is selected and the proceed button 326 labeled "Next" is pressed, the user terminal 20 sends solo ride information, which includes information indicating that the user currently desires a solo ride, to the dispatch management server 50. The user terminal 20 may accept the operation of the proceed button 326 if, for example, a ride location has been entered in at least the ride location input box 322.

[0166] If the boarding location is entered in the boarding location input box 322 and the disembarking location is entered in the disembarking location input box 324, and the proceed button 326 is operated, the individual passenger information sent to the dispatch management server 50 will include information on both the boarding location and the disembarking location. On the other hand, if the boarding location is entered in the boarding location input box 322 but the disembarking location is not entered in the disembarking location input box 324, and the proceed button 326 is operated, the individual passenger information sent to the dispatch management server 50 will include information on the boarding location, but not information on the disembarking location.

[0167] The dispatch unit 172 of the dispatch management server 50 estimates the vehicle 32 that is most likely to be matched if a dispatch request were made, based on the received solo passenger information, and generates individual transport information by associating that vehicle 32 with the solo passenger information. Here, if the received solo passenger information includes information on both the pick-up location and the drop-off location, the dispatch unit 172 generates ride-sharing transport information. The generation of ride-sharing transport information will be described in detail later.

[0168] If the user terminal control unit 170 of the dispatch management server 50 receives information on both the pick-up and drop-off locations, it displays the individual transport information on the display device of the user terminal 20, and also displays the ride-sharing transport information on the display device of the user terminal 20, allowing the user to select the information. For example, as shown in Figure 21C, the message box 320 displays an individual transport display box 330 representing individual transport information labeled "taxi," and a ride-sharing transport display box 332 representing ride-sharing transport information labeled "ride-sharing."

[0169] In Figure 21C, only one ride-sharing display box 332 is shown; however, if there is multiple ride-sharing information, multiple ride-sharing display boxes 332 may be displayed.

[0170] The individual transport display box 330 may display, for example, the approximate time until the individual transport vehicle arrives at the pick-up location, and the individual transport fee. The ride-sharing transport display box 332 may display, for example, the departure time from the pick-up spot, the arrival time at the drop-off spot, and the ride-sharing fee.

[0171] User 2 can select either the individual transport display box 330 or the ride-sharing transport display box 332. In Figure 21C, the selection of the individual transport display box 330 (selection state) may be indicated by making the frame of the individual transport display box 330 thicker or changing its color. As shown in Figure 21C, when the individual transport display box 330 is selected, an individual transport confirmation button 334 labeled "Call a taxi" is displayed. When the individual transport confirmation button 334 is pressed, the user terminal 20 sends an individual transport dispatch request to the dispatch management server 50. An individual transport dispatch request may include information about riding alone and can be rephrased as a regular dispatch request that represents a request for a ride alone at this time. The dispatch unit 172 performs dispatch processing that associates a vehicle with the individual transport dispatch request (regular dispatch request) on a one-to-one basis based on the received individual transport dispatch request. This results in the dispatch of an individual transport. In this case, ride-sharing is not actually added.

[0172] In Figure 21D, the selection status of the ride-sharing display box 332 may be indicated by making the frame of the ride-sharing display box 332 thicker or by changing its color. As shown in Figure 21D, when the ride-sharing display box 332 is selected, a ride-sharing confirmation button 336 labeled "Confirm" is displayed.

[0173] When the ride-sharing confirmation button 336 is pressed, the user terminal control unit 170 displays detailed information about the ride-sharing transportation on the message box 320 of the display device 124, as shown in Figure 22A. For example, the message box 320 displays the fare display box 340, the boarding spot display box 342, and the alighting spot display box 344. The fare display box 340 displays the ride-sharing fare. The boarding spot display box 342 displays information about the boarding spot and the departure time at the boarding spot. The alighting spot display box 344 displays information about the alighting spot and the arrival time at the alighting spot.

[0174] When the user selects the boarding spot display box 342 in Figure 22A, the user terminal control unit 170 displays a boarding spot enlargement map 350, which is an enlargement of the vicinity of the boarding spot on the map, in the message box 320 of the display device 124, as shown in Figure 22B. The boarding spot enlargement map 350 is displayed to include both the boarding spot and the boarding location entered in the boarding location input box 322 (i.e., set by user 2) (hereinafter, the boarding location entered in the boarding location input box 322 may simply be referred to as the "initial boarding location"). The boarding spot enlargement map 350 may also be displayed to include the route from the boarding location (initial boarding location) to the boarding spot. Furthermore, when the user selects the acceptance button 352 labeled "OK" as shown in Figure 22B, the boarding spot enlargement map 350 is closed, and the user can return to the screen shown in Figure 22A.

[0175] When the user selects the drop-off spot display box 344 in Figure 22A, the user terminal control unit 170 displays a drop-off spot enlargement map 360, which is an enlargement of the vicinity of the drop-off spot on the map, in the message box 320 of the display device 124, as shown in Figure 22C. The drop-off spot enlargement map 360 is displayed to include both the drop-off spot and the drop-off location entered in the drop-off location input box 324 (i.e., set by user 2) (hereinafter, the drop-off location entered in the drop-off location input box 324 may simply be referred to as the "initial drop-off location"). The drop-off spot enlargement map 360 may also be displayed to include the route from the drop-off spot to the drop-off location (initial drop-off location). Furthermore, when the user selects the acceptance button 362 labeled "OK" as shown in Figure 22C, the drop-off spot enlargement map 360 is closed, and the user can return to the screen shown in Figure 22A.

[0176] Furthermore, as shown in Figure 22A, when detailed information regarding ride-sharing transportation is displayed, a ride-sharing confirmation button 346 labeled "Arrange" is displayed. When the ride-sharing confirmation button 346 is operated, the user terminal 20 sends a ride-sharing dispatch request to the dispatch management server 50. This ride-sharing dispatch request may include ride-sharing transportation information selected by user 2. Based on the received ride-sharing dispatch request, the dispatch unit 172 processes the addition of user 2 to the confirmed trip 212. This actually adds the ride-sharing based on the selected ride-sharing transportation information.

[0177] Figure 23 is a flowchart showing an example of the operation flow of the dispatch unit 172. The dispatch unit 172 determines whether it has received solo ride information, which includes a request for solo ride at this time, from a user terminal 20 other than the user terminal 20 that made a reservation dispatch request that has already been associated with a confirmed trip (S30). If solo ride information has not been received (NO in S30), the dispatch unit 172 will not process the solo ride information until it is received. Even if solo ride information is received, if the source of the solo ride information is the user terminal 20 that made the reservation dispatch request, the dispatch unit 172 may choose not to process the solo ride information.

[0178] If the dispatch unit 172 receives information about a single passenger from another user terminal 20 (YES in S30), it proceeds to step S31. However, the dispatch unit 172 is not limited to proceeding to step S31 when it receives information about a single passenger from a user terminal 20 different from the user terminal 20 that made the reservation dispatch request. It may also be configured to proceed to step S31 when it receives information about a single passenger from the same user terminal 20 as the user terminal 20 that made the reservation dispatch request. For example, it may be possible to request multiple dispatches from the same user terminal 20. In such a case, the same user terminal 20 may make a request for a single passenger and a request for a ride-sharing passenger, with roughly overlapping timings, or multiple requests for ride-sharing passengers may make a request from the same user terminal 20 with roughly overlapping timings. In other words, it may be possible to send information about a single passenger separately from the reservation dispatch request from the same user terminal 20 that made the reservation dispatch request, before the transportation based on that reservation dispatch request is completed.

[0179] In step S31, the dispatch unit 172 determines whether the received individual passenger information includes both the boarding location (initial boarding location) and the alighting location (initial alighting location) (S31).

[0180] If the received passenger information includes only one of the boarding location or the alighting location (NO in S31), the dispatch unit 172 generates individual transport information based on the received passenger information (S32). For example, the dispatch unit 172 may generate individual transport information designating the vehicle 32 closest to the boarding location among the vehicles 32 to which no dispatch request has been associated as a vehicle 32 that can be dispatched (individual transport vehicle). The dispatch unit 172 then transmits the generated individual transport information to the user terminal 20 and displays the individual transport information on the display device 124 of the user terminal 20 (S33).

[0181] On the other hand, if the received single-ride information includes both the boarding location and the alighting location (YES in S31), the dispatch unit 172 first generates individual transport information in the same manner as in step S32 (S34). Next, the dispatch unit 172 generates ride-sharing transport information based on the received single-ride information (S35).

[0182] For example, the dispatch unit 172 may extract confirmed trips 212 from the currently generated confirmed trips 212 that allow user 2, who has received information about a single ride, to participate in a ride-sharing service. The dispatch unit 172 may also use the information of the extracted confirmed trips 212 as ride-sharing transportation information.

[0183] More specifically, the dispatch unit 172 may extract and use information from among multiple confirmed trips 212 as rideshare transportation information, specifically information for confirmed trips 212 in which the boarding location (initial boarding location) is within a predetermined first distance from the boarding spot. The predetermined first distance may be set to various values, such as 100m, taking into consideration the walking time of the user 2. The distance between the boarding location (initial boarding location) and the boarding spot here may be the distance along the route traveled by the user 2 (in other words, the distance along the road), or it may be the Euclidean distance (in other words, the straight-line distance).

[0184] This allows User 2 to travel a shorter distance (or, in other words, travel time) from their initial boarding location to the boarding spot, for example, on foot (or by bicycle or other means of transportation), thereby improving User 2's convenience.

[0185] Furthermore, the dispatch unit 172 may extract and use information from among multiple confirmed trips 212, specifically those trips where the drop-off location (initial drop-off location) is within a predetermined second distance from the drop-off spot, as ride-sharing transportation information. The predetermined second distance may be set to various values, such as 100m, taking into consideration the walking time of the user 2. The distance between the drop-off spot and the drop-off location (initial drop-off location) here may be the distance along the route traveled by the user 2 (in other words, the distance along the road), or it may be the Euclidean distance (in other words, the straight-line distance).

[0186] This allows user 2 to shorten the distance (in other words, travel time) they have to travel, for example, on foot from the drop-off point to their original drop-off location, thereby improving user convenience.

[0187] Furthermore, the dispatch unit 172 may extract and use information from among multiple confirmed trips 212 as rideshare transportation information, specifically information on confirmed trips 212 in which the boarding location (initial boarding location) is within a predetermined first distance from the boarding spot, and the disembarking location (initial disembarking location) is within a predetermined second distance from the disembarking spot.

[0188] This allows User 2 to shorten the distance (in other words, travel time) they have to travel, for example, on foot from their initial boarding location to the boarding spot, and also shortens the distance (in other words, travel time) they have to travel, for example, on foot from the disembarking spot to their initial disembarking location, thereby improving User 2's convenience.

[0189] Furthermore, the dispatch unit 172 may extract and use information on the confirmed trip 212 from among multiple confirmed trips 212, which has the shortest total distance obtained by adding the distance from the boarding location (initial boarding location) to the boarding spot and the distance from the disembarking location (initial disembarking location) to the disembarking spot, as ride-sharing transportation information.

[0190] As a result, one confirmed trip 212 with the shortest total distance is used as the ride-sharing information, and therefore only one ride-sharing information is presented to the user terminal 20. Consequently, it becomes easier for user 2 to select ride-sharing information compared to a scenario where multiple ride-sharing information is presented.

[0191] Furthermore, the dispatch unit 172 may extract and use information on a confirmed trip 212 as rideshare transportation information, specifically the confirmed trip 212 in which the boarding location (initial boarding location) is within a predetermined first distance from the boarding spot, the disembarking location (initial disembarking location) is within a predetermined second distance from the disembarking spot, and the total distance, calculated by adding the distance from the boarding location (initial boarding location) to the boarding spot and the distance from the disembarking location (initial disembarking location) to the disembarking spot, is the shortest. Note that the unit may also extract and use information on a confirmed trip 212 in which the total distance is less than or equal to a predetermined distance, rather than being limited to the example where the total distance is the shortest.

[0192] As a result, as described above, the distance that user 2 travels, for example on foot, from the initial boarding location to the boarding spot, and the distance that they travel, for example on foot, from the disembarking spot to the initial disembarking location (in other words, the travel time) can be shortened, thereby improving the convenience for user 2. In addition, since one ride-sharing transportation option is presented to the user terminal 20, user 2 will find it easier to select a ride-sharing transportation option.

[0193] Furthermore, the dispatch unit 172 may extract and use, as ride-sharing transport information, the information of the confirmed trip 212 to which the vehicle 32 that is estimated to arrive first at the boarding spot corresponding to the boarding location (initial boarding location) is assigned after the estimated time when user 2 of the user terminal 20 is estimated to arrive at the boarding spot.

[0194] This reduces the time user 2 has to wait for vehicle 32 at the boarding spot, thereby improving user convenience.

[0195] Furthermore, the dispatch unit 172 may extract and use, as ride-sharing transport information, the information of the confirmed trip 212 that, within a predetermined time range, results in the shortest total walking distance for user 2 from among multiple confirmed trips 212. Here, the total walking distance is not Euclidean distance, but the total distance of the route that user 2 can walk. This reduces the total walking distance for user 2, thereby alleviating the burden on user 2.

[0196] Here, several methods for generating ride-sharing transportation information have been provided as examples, but these examples can be combined in various ways. Furthermore, the method for generating ride-sharing transportation information is not limited to the examples provided; various methods can be used.

[0197] Next, the dispatch unit 172 transmits the individual delivery information generated in step S34 and the ride-sharing delivery information generated in step S35 to the user terminal 20, causing the individual delivery information and the ride-sharing delivery information to be displayed on the display device 124 of the user terminal 20 (S36). As a result, both the individual delivery information and the ride-sharing delivery information are displayed on the user terminal 20 (see Figure 21C).

[0198] When ride-sharing information displayed on the display device 124 is selected and a ride-sharing dispatch request is sent, dispatch processing is performed based on the selected ride-sharing information, and dispatch based on said ride-sharing information is confirmed. After the dispatch of the ride-sharing is confirmed, the user terminal control unit 170 may display route guidance from the current location or the initial boarding location to the boarding spot on the display device of the user terminal 20, or it may display route guidance from the drop-off spot to the initial drop-off location on the display device 124 of the user terminal 20.

[0199] Figure 23 illustrates an example where, if the received solo passenger information includes both the boarding location and the alighting location, individual transport information and ride-sharing transport information are presented to the user terminal 20. However, the dispatch unit 172 may, not limited to this example, present individual transport information to the user terminal 20 in a selectable manner, and also present ride-sharing transport information to the user terminal 20 in a selectable manner, if the received solo passenger information includes at least the boarding location. Furthermore, the dispatch unit 172 may, if the received solo passenger information includes at least the alighting location, present individual transport information to the user terminal 20 in a selectable manner, and also present ride-sharing transport information to the user terminal 20 in a selectable manner.

[0200] Thus, the dispatch management device (e.g., dispatch management server 50) that can communicate with the user terminal 20 via a network is equipped with one or more processors. When a processor receives solo ride information from the user terminal 20, which is information that the user currently desires to ride alone, it presents the user terminal 20 with selectable individual transport information, which represents information about a transport plan for individual transport that associates a vehicle 32 with the solo ride information on a one-to-one basis, and also presents the user terminal 20 with selectable ride-sharing transport information, which represents information about a transport plan for ride-sharing that associates one or more dispatch requests and the solo ride information with one vehicle 32. This configuration makes it possible to encourage the user 2 to use ride-sharing. When the user 2 selects the presented ride-sharing transport information, a ride-sharing addition occurs, thus improving the frequency of ride-sharing additions.

[0201] The processor may receive information about a single passenger, and if the information includes the boarding and alighting locations, it may also present ride-sharing information to the user terminal 20 in an optional format. With this configuration, ride-sharing information can be appropriately generated and presented.

[0202] The processor sets up multiple candidate trips 210, each associated with one of several predetermined travel routes 206 and a transport period (start time to end time). It receives a reservation dispatch request from the user terminal 20, which represents a ride-sharing request (e.g., a ride-sharing request 240). The processor assigns the reservation dispatch request to one or more candidate trips 210, where the selected pick-up point (e.g., pick-up spot) and alighting point (e.g., alighting spot) received from the user terminal 20 that made the reservation dispatch request are included in the travel route 206, and the desired transport time (e.g., pick-up time, alighting time) received from the user terminal 20 that made the reservation dispatch request is included in the transport period. At the start of the ride-sharing trip (for example, a predetermined time before the start of the ride-sharing trip), one of the candidate trips 210 to which the reservation dispatch request has been assigned is designated as the confirmed trip 212, a vehicle (for example, a ride-sharing vehicle) is assigned to the confirmed trip 212, and solo ride information is received from at least one of the user terminals 20 that made the reservation dispatch request and another user terminal 20 that is different from the user terminal 20 that made the reservation dispatch request. If the solo ride information includes a boarding location, the information of the confirmed trip 212 whose boarding location is within a predetermined first distance from the boarding selection point may be presented to the user terminal 20 that sent the solo ride information as ride-sharing transportation information. With this configuration, the distance that user 2 has to travel from the boarding location to the boarding selection point can be shortened, thereby improving the convenience of user 2.

[0203] The processor sets up multiple candidate trips 210, each associated with one of several predetermined travel routes 206 and a transport period (start time to end time). It receives a reservation dispatch request from the user terminal 20, which represents a ride-sharing request (e.g., a ride-sharing request 240). The processor assigns the reservation dispatch request to one or more candidate trips 210, where the selected pick-up point (e.g., pick-up spot) and alighting point (e.g., alighting spot) received from the user terminal 20 that made the reservation dispatch request are included in the travel route 206, and the desired transport time (e.g., pick-up time, alighting time) received from the user terminal 20 that made the reservation dispatch request is included in the transport period. At the start of the ride-sharing trip (for example, a predetermined time before the start of the ride-sharing trip), one of the candidate trips 210 to which the reservation dispatch request has been assigned is designated as the confirmed trip 212, a vehicle (for example, a ride-sharing vehicle) is assigned to the confirmed trip 212, and solo ride information is received from at least one of the user terminals 20 that made the reservation dispatch request and another user terminal 20 that is different from the user terminal 20 that made the reservation dispatch request. If the solo ride information includes a drop-off location, the information of the confirmed trip 212 whose drop-off location is within a predetermined second distance from the drop-off selection point may be presented to the user terminal 20 that sent the solo ride information as ride-sharing transport information. With this configuration, the distance that user 2 has to travel from the drop-off selection point to the drop-off location can be shortened, thereby improving the convenience of user 2.

[0204] The processor sets up multiple candidate trips 210, each associated with one of several predetermined travel routes 206 and a transport period (start time to end time of travel). It receives a reservation dispatch request from the user terminal 20, which represents a ride-sharing request (e.g., a ride-sharing request 240). The processor assigns the reservation dispatch request to one or more candidate trips 210, where the selected pick-up point (e.g., pick-up spot) and alighting point (e.g., alighting spot) received from the user terminal 20 that made the reservation dispatch request are included in the travel route 206, and the desired transport time (e.g., pick-up time, alighting time) received from the user terminal 20 that made the reservation dispatch request is included in the transport period. The processor then sets up multiple candidate trips 210, each associated with one of several predetermined travel routes 206 and a transport period (e.g., a ride-sharing trip). A predetermined time before the start of the trip, one of the candidate trips 210 to which the reservation dispatch request has been assigned is designated as the confirmed trip 212, a vehicle (e.g., a ride-sharing vehicle) is assigned to the confirmed trip 212, and solo ride information is received from at least one of the user terminals 20 that made the reservation dispatch request and another user terminal 20 that is different from the user terminal 20 that made the reservation dispatch request. If the solo ride information includes a pick-up location and a drop-off location, the information of the confirmed trip 212 with the shortest total distance (the sum of the distance from the pick-up location to the selected pick-up location and the distance from the drop-off location to the selected drop-off location) is presented to the user terminal 20 that sent the solo ride information as ride-sharing transport information. With this configuration, since one confirmed trip 212 with the shortest total distance is used as ride-sharing transport information, only one piece of ride-sharing transport information is presented to the user terminal 20, and as a result, user 2 can more easily select ride-sharing transport information compared to a configuration in which multiple pieces of ride-sharing transport information are presented.

[0205] The processor sets up multiple candidate trips 210, each associated with one of several predetermined travel routes 206 and a transport period (start time to end time of travel). It receives a reservation dispatch request from the user terminal 20, which represents a ride-sharing request (e.g., a ride-sharing request 240). The reservation dispatch request is assigned to one or more candidate trips 210, where the selected pick-up point (e.g., pick-up spot) and selected drop-off point (e.g., drop-off spot) received from the user terminal 20 that made the reservation dispatch request are included in the travel route 206, and the desired transport time (e.g., pick-up time, drop-off time) received from the user terminal 20 that made the reservation dispatch request is included in the transport period. At a predetermined timing before the transport period (e.g., a predetermined time before the start of the ride-sharing trip), If the user terminal 2 receives solo ride information from at least one of the candidate trips 210 to which the reservation dispatch request has been assigned, and the user terminal 20 that sent the solo ride information receives information on the confirmed trip 212 to which the vehicle (e.g., a ride-sharing vehicle) that is estimated to arrive first at the pick-up location corresponding to the pick-up location is estimated to arrive after the estimated time when the user terminal 20 will arrive at the pick-up location corresponding to the pick-up location is estimated to arrive first, then the user terminal 20 that sent the solo ride information may be presented with the information on the confirmed trip 212 to which the vehicle (e.g., a ride-sharing vehicle) is estimated to arrive first at the pick-up location corresponding to the pick-up location is estimated to arrive first, as ride-sharing transport information.

[0206] In this vehicle dispatch management method, when the computer receives information from the user terminal 20 that includes a request for a solo ride at the present time, it presents the user terminal 20 with selectable individual transport information, which represents information about a transport plan for individual transport that associates a vehicle 32 with the solo transport information on a one-to-one basis, and also presents the user terminal 20 with selectable ride-sharing transport information, which represents information about a transport plan for ride-sharing that associates one or more dispatch requests and solo transport information with one vehicle 32. This configuration makes it possible to encourage the user 2 to use ride-sharing. When the user 2 selects the presented ride-sharing transport information, a ride-sharing addition occurs, thus improving the frequency of ride-sharing additions.

[0207] The program of this embodiment causes the computer, upon receiving solo ride information from the user terminal 20, which includes information indicating a desire for solo rides at the present time, to selectively present individual transport information to the user terminal 20, which represents information regarding a one-to-one transport plan that associates a vehicle 32 with the solo ride information on a one-to-one basis, and also to selectively present shared transport information to the user terminal 20, which represents information regarding a shared transport plan that associates one or more dispatch requests and solo ride information with one vehicle 32. This configuration encourages the user 2 to use shared transport. When the user 2 selects the presented shared transport information, a shared transport addition occurs, thus improving the frequency of shared transport additions.

[0208] (Individual shipping, disassembled) As described above, when the dispatch unit 172 determines the trip a predetermined time before the start of the ride-sharing journey (for example, 25 minutes before the start of the journey), it determines the assignment of the ride-sharing dispatch request to the candidate trip 210 and designates it as the confirmed trip 212. The dispatch unit 172 assigns a vehicle 32 (for example, a ride-sharing vehicle) to the confirmed trip 212. When a ride-sharing vehicle assigned to the confirmed trip 212 accepts the ride-sharing dispatch request, it heads to the first pick-up spot on the confirmed trip 212 so as to arrive by the time user 2 picks up at the first pick-up spot on the confirmed trip 212.

[0209] Here, after a rideshare vehicle is assigned to confirmed trip 212 and the rideshare transportation plan is determined, there may be cases where the rideshare vehicle becomes unable to transport passengers before the rideshare transportation begins, for example, due to a malfunction in the rideshare vehicle or the driver becoming ill. In such cases, if the rideshare transportation that was reserved is not carried out, it may reduce convenience for multiple users 2. The following describes the first example of a case where a rideshare vehicle becomes unable to transport passengers before the start of transportation.

[0210] Figure 24 is a flowchart illustrating the first example of when a rideshare vehicle is unable to transport passengers. After assigning a rideshare vehicle to the confirmed trip 212, the dispatch unit 172 determines whether a predetermined timing has been reached (S40). The predetermined timing may be, for example, the deadline for accepting the dispatch notification. Note that the predetermined timing is not limited to the example timing, but may be set to various timings under the condition that the departure time of the first pick-up spot on the confirmed trip 212 (in other words, the start time of the rideshare transport) has not elapsed. The dispatch unit 172 repeats the process of step S40 until the predetermined timing is reached (NO in S40).

[0211] When a predetermined timing is reached (YES in S40), the dispatch unit 172 determines whether the ride-sharing vehicle assigned to the confirmed trip 212 is unavailable for transport (S41). For example, the dispatch unit 172 may determine that the ride-sharing vehicle is unavailable if it does not receive an acceptance response to the dispatch notification within the acceptance deadline. Alternatively, the dispatch unit 172 may determine that the ride-sharing vehicle is unavailable if it receives a response from the ride-sharing vehicle indicating it is unavailable for transport in response to the dispatch notification before reaching the predetermined timing in step S40.

[0212] If it is determined that the transport is not impossible (in other words, that it is transportable) (NO in S41), the dispatch unit 172 terminates the series of processes shown in Figure 24.

[0213] If it is determined that the vehicle cannot be transported (YES in S41), the dispatch unit 172 performs the first untransported vehicle matching process (S42) and terminates the series of processes shown in Figure 24.

[0214] The first transportation failure matching process is a process that associates each of the multiple ride-sharing dispatch requests associated with the ride-sharing vehicle that has become unable to transport with vehicle 32 on a one-to-one basis.

[0215] In other words, the dispatch unit 172 performs the first transportation failure matching process described above, thereby breaking down the multiple ride-sharing dispatch requests associated with the ride-sharing vehicles that have become unable to transport into multiple individual dispatches. As mentioned above, individual dispatches differ from ride-sharing transport in that they involve transporting a single user 2, and are realized by a one-to-one correspondence between the vehicle 32 and the dispatch request.

[0216] In this way, a ride-sharing request associated with a ride-sharing vehicle that has become unable to transport its passengers is broken down into individual transport requests, allowing the transportation of user 2 in that ride-sharing request to be achieved by replacing it with an individual transport. As a result, even if the ride-sharing vehicle assigned to confirmed trip 212 becomes unable to transport its passengers, the situation in which user 2's transportation is not carried out can be avoided, and the decrease in convenience for user 2 in ride-sharing can be suppressed.

[0217] Furthermore, in the ride-sharing matching method, as described above, a ride-sharing dispatch request is assigned to a candidate trip 210, a confirmed trip 212 is determined from the candidate trip 210, and a vehicle 32 is associated with the confirmed trip 212. In contrast, in the first transportation failure matching process, a one-to-one correspondence is made between the vehicle 32 and the dispatch request. That is, in the first transportation failure matching process, the vehicle 32 to be transported is determined by a different individual transport matching method than the ride-sharing matching method. Therefore, even if a ride-sharing vehicle becomes unable to transport, transportation can still be carried out for each user 2, and from this point of view, a decrease in convenience for user 2 can be suppressed.

[0218] Furthermore, the vehicle 32 newly assigned in the first transportation failure matching process may be, for example, a vehicle specializing in individual transport (individual transport vehicle). An individual transport vehicle is a vehicle that does not allow ride-sharing and is distinct from a ride-sharing vehicle. By assigning an individual transport vehicle to the newly assigned vehicle 32, there are no other passengers besides user 2, so user 2 does not have to worry about other people, and the individual transport vehicle can arrive directly at the pick-up and drop-off locations. From this point of view as well, a decrease in user 2's convenience can be suppressed.

[0219] Furthermore, if the dispatch unit 172 performs the first inability to transport matching process, it may set the transportation fee for each of the multiple dispatches generated by the first inability to transport matching process to be the same as the transportation fee that would have been charged if the vehicle 32 that became unable to transport had carried out the transport. In other words, the dispatch unit 172 may set the transportation fee for the individual transport by the vehicle 32 newly associated by the first inability to transport matching process to be substantially the same as the original ride-sharing fee. This makes it possible to suppress a decrease in the financial benefit to user 2 from requesting ride-sharing.

[0220] Furthermore, when the dispatch unit 172 receives a normal dispatch request that indicates a request for a single-passenger ride at the current time, it may perform a normal matching process that associates vehicle 32 with the normal dispatch request on a one-to-one basis. The dispatch unit 172 may also prioritize the execution of the first transportation failure matching process over the normal matching process. In this example, in the first transportation failure matching process, the new vehicle 32 is preferentially assigned to the ride-sharing dispatch request associated with the ride-sharing vehicle that has become unable to be transported. This makes it possible to appropriately avoid situations where transportation is delayed even if a ride-sharing vehicle becomes unable to be transported, and to further suppress the decrease in convenience for user 2.

[0221] Thus, the dispatch management device (e.g., dispatch management server 50) that can communicate with the user terminal 20 via a network comprises one or more processors, which set up multiple candidate trips 210, each associated with one of a predetermined number of travel routes 206 and a transportation period (start time to end time of travel), receive a dispatch request (e.g., ride-sharing dispatch request 240) from the user terminal 20, and ensures that the selected pick-up point (e.g., pick-up spot) and selected drop-off point (e.g., drop-off spot) received from the user terminal 20 that made the dispatch request are included in the travel route 206, and that the desired transportation time (e.g., pick-up time, drop-off time) received from the user terminal 20 that made the dispatch request is included in the transportation period. The system assigns dispatch requests to one or more candidate trips 210, and at a predetermined time before the transportation period (for example, a predetermined time before the start of the ride-sharing journey), one of the candidate trips 210 to which the dispatch requests have been assigned is designated as a confirmed trip 212, and a vehicle (for example, a ride-sharing vehicle) is assigned to the confirmed trip 212. If the vehicle (for example, a ride-sharing vehicle) assigned to the confirmed trip 212 becomes unable to transport before the start of transportation, a first transportation failure matching process is performed for each of the multiple dispatch requests associated with the vehicle that became unable to transport, thereby breaking down the multiple dispatch requests associated with the vehicle that became unable to transport into multiple dispatches. With this configuration, even if a ride-sharing vehicle becomes unable to transport, it is possible to avoid a situation where the transportation of user 2 is not carried out, and the decrease in convenience for user 2 in ride-sharing can be suppressed.

[0222] When the processor receives a normal dispatch request that indicates a request for a single-passenger vehicle at the present time, it may perform a normal matching process to establish a one-to-one correspondence between vehicle 32 and the normal dispatch request, and the first inability to transport matching process may be executed with higher priority than the normal matching process. With this configuration, even if the first inability to transport matching process is performed after an inability to transport a shared vehicle occurs, the priority given to the first inability to transport matching process allows for the dispatch of a new vehicle 32 to be confirmed relatively soon after the inability to transport a shared vehicle occurs. As a result, situations that would cause delays in transportation can be appropriately avoided.

[0223] If the processor performs the first inability to transport vehicle matching process, it may set the transportation fee for each of the multiple vehicle assignments generated by the first inability to transport vehicle matching process to be the same as the transportation fee that would have been charged if the vehicle that became unable to transport vehicle had carried out the transport. This configuration can suppress the reduction in the financial benefit to user 2 from requesting a ride-sharing.

[0224] The dispatch management method of this embodiment involves a computer setting up a plurality of candidate trips 210, each associated with one of a plurality of predetermined travel routes 206 and a transportation period (start time to end time of travel). The computer receives a dispatch request (e.g., a ride-sharing dispatch request 240) from a user terminal 20 and assigns the dispatch request to one or more candidate trips 210, where the selected pick-up point (e.g., pick-up spot) and selected drop-off point (e.g., drop-off spot) received from the user terminal 20 that made the dispatch request are included in the travel route 206, and the desired transportation time (e.g., pick-up time, drop-off time) received from the user terminal 20 that made the dispatch request is included in the transportation period. At a predetermined time before the start of the ride-sharing journey (for example, a predetermined time before the start of the ride-sharing journey), one of the candidate trips 210 to which the dispatch request has been assigned is designated as the confirmed trip 212, and a vehicle (for example, a ride-sharing vehicle) is assigned to the confirmed trip 212. If the vehicle assigned to the confirmed trip 212 (for example, a ride-sharing vehicle) becomes unable to transport before the start of transport, a first inability to transport matching process is performed for each of the multiple dispatch requests associated with the vehicle that became unable to transport, thereby breaking down the multiple dispatch requests associated with the vehicle that became unable to transport into multiple dispatches. With this configuration, even if a ride-sharing vehicle becomes unable to transport, it is possible to avoid a situation where the transport of user 2 is not performed, and the decrease in convenience for user 2 in ride-sharing can be suppressed.

[0225] The program of this embodiment sets up a plurality of candidate trips 210 in the computer, each associated with one of a plurality of predetermined travel routes 206 and a transport period (start time to end time of travel), receives a dispatch request (e.g., a ride-sharing dispatch request 240) from a user terminal 20, assigns the dispatch request to one or more candidate trips 210 in which the selected pick-up point (e.g., pick-up spot) and selected drop-off point (e.g., drop-off spot) received from the user terminal 20 that made the dispatch request are included in the travel route 206, and the desired transport time (e.g., pick-up time, drop-off time) received from the user terminal 20 that made the dispatch request is included in the transport period, and transports At a predetermined time before the scheduled period (for example, a predetermined time before the start of a ride-sharing trip), one of the candidate trips 210 to which a dispatch request has been assigned is designated as a confirmed trip 212, and a vehicle (for example, a ride-sharing vehicle) is assigned to the confirmed trip 212. If the vehicle assigned to the confirmed trip (for example, a ride-sharing vehicle) becomes unable to transport before the start of transport, a first transport failure matching process is performed for each of the multiple dispatch requests associated with the vehicle that became unable to transport, which associates each dispatch request with a vehicle (for example, a private transport vehicle) on a one-to-one basis, thereby causing the multiple dispatch requests associated with the vehicle that became unable to transport to be broken down into multiple dispatches. With this configuration, even if a ride-sharing vehicle becomes unable to transport, it is possible to avoid a situation where the transport of user 2 is not performed, and the decrease in convenience for user 2 in ride-sharing can be suppressed.

[0226] (Ride-sharing rematching) In the above example, when a shared vehicle became unable to transport before the start of transport, the multiple shared transport requests associated with the unable-to-transport vehicle were broken down into multiple individual transport requests. However, the handling of cases where a shared vehicle becomes unable to transport before the start of transport is not limited to this example. Below, we will explain a second example of a case where a shared vehicle becomes unable to transport before the start of transport.

[0227] Figure 25 is a flowchart illustrating a second example of a situation where a shared vehicle becomes unable to transport passengers. Below, we will refer to Figure 25 to explain the differences from Figure 24, and for convenience, we will omit explanations of points that are substantially the same as those in Figure 24.

[0228] If it is determined in step S41 that the vehicle cannot be transported (YES in S41), the dispatch unit 172 performs a second untransported vehicle matching process (S52) and terminates the series of processes shown in Figure 25.

[0229] The second delivery failure matching process includes assigning a dispatch request to one or more candidate trips 210 for a dispatch request assigned to a confirmed trip to which the vehicle 32 that has become unable to be transported has been assigned, designating one of the candidate trips 210 to which the dispatch request has been assigned as a confirmed trip 212, and assigning vehicle 32 to the confirmed trip 212. The second delivery failure matching process may also include unlinking the vehicle 32 that has become unable to be transported from the dispatch request. If unlinking is included, the second delivery failure matching process proceeds from assigning the unlinked dispatch request to one or more candidate trips 210 onwards.

[0230] In other words, the second transportation failure matching process performs essentially the same process as the ride-sharing matching process performed under normal circumstances when no transportation failure has occurred. By performing the above-described second transportation failure matching process, the dispatch unit 172 will perform the ride-sharing matching process again for each of the multiple dispatch requests that were associated with the vehicle 32 that has become unable to transport.

[0231] For example, suppose that vehicle 32, which has become unable to transport, has been associated with both a dispatch request from the first user and a dispatch request from the second user. When the ride-sharing matching process is performed again, it is possible that the ride-sharing arrangement may be restructured so that, for example, the first user and the second user each ride in separate vehicles.

[0232] As a result, even if a vehicle 32 becomes unable to transport, the second transportation failure matching process is performed, allowing ride-sharing to be carried out appropriately and preventing a decrease in convenience for user 2 in ride-sharing.

[0233] Furthermore, if the dispatch unit 172 has performed the second inability to transport matching process and there are dispatch requests for which a vehicle 32 has not been associated, it may perform the first inability to transport matching process to associate the dispatch requests with the vehicle 32 on a one-to-one basis for those dispatch requests for which a vehicle 32 has not been associated even after the second inability to transport matching process. This prevents omissions in associating the vehicle 32 with the dispatch requests, even if there are dispatch requests for which a vehicle 32 has not been associated even after the second inability to transport matching process, and appropriately avoids situations in which the transport of user 2 is not performed.

[0234] Furthermore, the dispatch unit 172 may prioritize the execution of the second transportation failure matching process over the normal matching process shown in the first example. In this example, in the second transportation failure matching process, dispatch requests that have been unassociated with rideshare vehicles that have become unable to transport are preferentially associated with the new confirmed trip 212. As a result, even if a rideshare vehicle becomes unable to transport, the dispatch request can be appropriately assigned to the vehicle on the new confirmed trip 212, thereby appropriately avoiding a situation where user 2's transportation is not performed and further suppressing the decrease in convenience for user 2.

[0235] Thus, a dispatch management device (e.g., a dispatch management server 50) that can communicate with a user terminal via a network comprises one or more processors, which set up a plurality of candidate trips 210, each associated with one of a plurality of predetermined travel routes 206 and a transport period (start time to end time of travel), receive a dispatch request (e.g., a ride-sharing dispatch request 240) from a user terminal 20, and assigns one or more candidate trips 210 to which the selected pick-up point (e.g., pick-up spot) and selected drop-off point (e.g., drop-off spot) received from the user terminal 20 that made the dispatch request are included in the travel route 206, and the desired transport time (e.g., pick-up time, drop-off time) received from the user terminal 20 that made the dispatch request is included in the transport period. The system assigns a dispatch request, and at a predetermined time before the transportation period, designates one of the candidate trips 210 to which the dispatch request was assigned as a confirmed trip 212, assigns a vehicle (e.g., a ride-sharing vehicle) to the confirmed trip 212, and if the vehicle (e.g., a ride-sharing vehicle) assigned to the confirmed trip 212 becomes unable to transport before the start of transportation, a second transportation failure matching process is performed, which includes assigning the dispatch request to one or more candidate trips 210 to the said confirmed trip to which the vehicle (e.g., a ride-sharing vehicle) became unable to transport, designating one of the candidate trips 210 to which the dispatch request was assigned as a confirmed trip 212, and assigning a vehicle (e.g., a ride-sharing vehicle) to the confirmed trip 212. With this configuration, even if a vehicle 32 becomes unable to transport, ride-sharing transportation can be properly carried out, and a decrease in the convenience of user 2 in ride-sharing can be suppressed.

[0236] If the processor has performed a second inability to transport vehicle matching process and there are dispatch requests for which no vehicle has been assigned, it may perform a first inability to transport vehicle matching process to assign a dispatch request to a vehicle on a one-to-one basis for those dispatch requests for which no vehicle has been assigned after the second inability to transport vehicle matching process. With this configuration, even if there are dispatch requests for which no vehicle 32 has been assigned after the second inability to transport vehicle matching process, it is possible to prevent omissions in assigning vehicle 32 to dispatch requests and appropriately avoid situations in which user 2's transport is not performed.

[0237] The dispatch management method of this embodiment involves a computer setting up multiple candidate trips 210, each associated with one of a predetermined number of travel routes and a transportation period (start time to end time of travel), receiving a dispatch request (e.g., a ride-sharing dispatch request 240) from a user terminal 20, assigning the dispatch request to one or more candidate trips 210, where the selected pick-up point (e.g., pick-up spot) and selected drop-off point (e.g., drop-off spot) received from the user terminal 20 that made the dispatch request are included in the travel route 206, and the desired transportation time (e.g., pick-up time, drop-off time) received from the user terminal 20 that made the dispatch request is included in the transportation period, and at a predetermined timing before the transportation period, The system then performs a second inability to transport matching process, which includes: designating one of the candidate trips 210 to which a dispatch request has been assigned as a confirmed trip 212; assigning a vehicle (e.g., a ride-sharing vehicle) to the confirmed trip 212; and if the vehicle (e.g., a ride-sharing vehicle) assigned to the confirmed trip 212 becomes unable to transport before the start of transport, the system assigns the dispatch request to one or more candidate trips 210 to which the inability to transport vehicle (e.g., a ride-sharing vehicle) has been assigned; designating one of the candidate trips 210 to which a dispatch request has been assigned as a confirmed trip 212; and assigning a vehicle (e.g., a ride-sharing vehicle) to the confirmed trip 212. With this configuration, even if an inability to transport vehicle 32 occurs, ride-sharing transport can be carried out appropriately, and a decrease in the convenience of user 2 in ride-sharing can be suppressed.

[0238] The program of this embodiment sets up a plurality of candidate trips 210 in the computer, each associated with one of a plurality of predetermined travel routes 206 and a transport period (start time to end time of travel), receives a dispatch request (e.g., a ride-sharing dispatch request 240) from a user terminal 20, assigns the dispatch request to one or more candidate trips 210 in which the selected pick-up point (e.g., pick-up spot) and selected drop-off point (e.g., drop-off spot) received from the user terminal 20 that made the dispatch request are included in the travel route 206, and the desired transport time (e.g., pick-up time, drop-off time) received from the user terminal 20 that made the dispatch request is included in the transport period, and assigns the dispatch request to a predetermined timing before the transport period. In the matching process, one of the candidate trips 210 to which the dispatch request is assigned is designated as the confirmed trip, and a vehicle (e.g., a ride-sharing vehicle) is assigned to the confirmed trip 212. If the vehicle (e.g., a ride-sharing vehicle) assigned to the confirmed trip 212 becomes unable to transport before the start of transport, a second transportation failure matching process is performed, which includes assigning the dispatch request to one or more candidate trips 210 to the confirmed trip to which the vehicle (e.g., a ride-sharing vehicle) became unable to transport, designating one of the candidate trips 210 to which the dispatch request is assigned as the confirmed trip 212, and assigning a vehicle (e.g., a ride-sharing vehicle) to the confirmed trip 212. With this configuration, even if a vehicle 32 becomes unable to transport, ride-sharing transport can be properly carried out, and a decrease in convenience for user 2 in ride-sharing can be suppressed.

[0239] (Change of shared vehicle) The following describes a third example of a situation where a shared vehicle becomes unable to transport passengers before the start of transport.

[0240] Figure 26 is a flowchart illustrating a third example of a situation where a shared vehicle becomes unable to transport passengers. Below, we will refer to Figure 26 to explain the differences from Figure 24, and for convenience, we will omit explanations of points that are substantially the same as those in Figure 24.

[0241] If it is determined in step S41 that transportation is impossible (YES in S41), the dispatch unit 172 performs the third transportation failure matching process (S62) and terminates the series of processes shown in Figure 25.

[0242] The third transportation failure matching process is the process of assigning a vehicle 32 that does not currently have a dispatch request assigned to it, and which is different from the vehicle that became unable to transport, to the confirmed trip 212 to which the rideshare vehicle that became unable to transport is assigned.

[0243] In other words, the dispatch unit 172 maintains a ride-sharing dispatch system by associating one or more dispatch requests with one vehicle 32 by performing the third transportation failure matching process described above.

[0244] In this way, ride-sharing can be carried out as scheduled simply by changing the assigned vehicle 32. As a result, even if the initially assigned ride-sharing vehicle becomes unavailable, it is possible to avoid a situation where user 2's transportation is not carried out, thereby mitigating a decrease in convenience for user 2 in ride-sharing.

[0245] Furthermore, the vehicle 32 newly assigned in the third transportation failure matching process may be, for example, a ride-sharing vehicle specifically for ride-sharing. By making the newly assigned vehicle 32 a ride-sharing vehicle, the original ride-sharing transportation plan can be continued and the ride-sharing transportation can be properly executed.

[0246] Furthermore, the dispatch unit 172 may prioritize the third transportation failure matching process over the normal matching process shown in the first example. In this example, in the third transportation failure matching process, a new vehicle 32 is preferentially assigned to the confirmed trip 212 to which the rideshare vehicle that has become unable to transport is assigned. As a result, even if a rideshare vehicle becomes unable to transport, a new vehicle 32 can be appropriately assigned, thereby appropriately avoiding a situation where the transport for user 2 is not performed, and further suppressing the decrease in convenience for user 2.

[0247] Furthermore, if the dispatch unit 172 has performed the third inability to transport matching process and there are dispatch requests for which a vehicle 32 has not been associated, it may perform the second inability to transport matching process for those dispatch requests for which a vehicle 32 has not been associated. In addition, if the dispatch unit 172 has performed the second inability to transport matching process and there are dispatch requests for which a vehicle 32 has not been associated, it may perform the first inability to transport matching process for those dispatch requests for which a vehicle 32 has not been associated. By doing so, even if there are dispatch requests for which a vehicle 32 has not been associated after the third inability to transport matching process, it is possible to prevent omissions in associating the vehicle 32 with the dispatch request, and to appropriately avoid a situation in which the transport of user 2 is not carried out.

[0248] Thus, the dispatch management device of the present invention (e.g., dispatch management server 50) that can communicate with a user terminal via a network comprises one or more processors, which set up a plurality of candidate trips 210, each associated with one of a plurality of predetermined travel routes 206 and a transport period (travel start time to travel end time), receive a dispatch request (e.g., ride-sharing dispatch request 240) from a user terminal 20, and ensures that the selected pick-up point (e.g., pick-up spot) and selected drop-off point (e.g., drop-off spot) received from the user terminal 20 that made the dispatch request are included in the travel route 206, and the desired transport time (e.g., pick-up time, drop-off time) received from the user terminal 20 that made the dispatch request The system assigns dispatch requests to one or more candidate trips 210 included in the transport period, and at a predetermined time before the transport period (for example, a predetermined time before the start of the ride-sharing journey), one of the candidate trips 210 to which the dispatch requests have been assigned is designated as a confirmed trip 212, a vehicle (for example, a ride-sharing vehicle) is assigned to the confirmed trip 212, and if the vehicle assigned to the confirmed trip 212 (for example, a ride-sharing vehicle) becomes unable to transport before the start of transport, a third ride-sharing failure matching process is performed to assign a different vehicle (for example, a ride-sharing vehicle) to the confirmed trip 212, thereby maintaining ride-sharing arrangements where one or more dispatch requests are associated with one vehicle 32. With this configuration, even if a ride-sharing vehicle becomes unable to transport, it is possible to avoid a situation where the transport of user 2 is not performed, and the decrease in convenience for user 2 in ride-sharing can be suppressed.

[0249] If the processor has performed a third-stage unavailable-transport matching process and there are dispatch requests for which no vehicle has been assigned, it may perform a second-stage unavailable-transport matching process for those dispatch requests for which no vehicle has been assigned, which includes assigning the dispatch requests to one or more candidate trips, designating one of the candidate trips to which the dispatch requests have been assigned as a confirmed trip, and assigning a vehicle to the confirmed trip. With this configuration, even if there are dispatch requests for which no vehicle 32 has been assigned after the third-stage unavailable-transport matching process, it is possible to prevent omissions in the assignment of vehicle 32 to dispatch requests, and to appropriately avoid a situation in which user 2's transportation is not performed.

[0250] Furthermore, the first, second, and third examples described above may be combined as appropriate when handling the case where a ride-sharing vehicle becomes unable to transport before the start of transport. For example, if the dispatch unit 172 determines that transport is impossible, it may perform the third transport-impossibility matching process, and if there are no suitable ride-sharing vehicles available for assignment, it may perform the first transport-impossibility matching process. If the dispatch unit 172 determines that transport is impossible, it may perform the first transport-impossibility matching process, and if there are no suitable vehicles available for assignment, it may perform the third transport-impossibility matching process. By appropriately combining the first, second, and third examples described above, the decrease in convenience for user 2 in ride-sharing can be further suppressed.

[0251] (Breakdown into multiple dispatches) The following describes a fourth example of a situation where a shared vehicle becomes unable to transport passengers before the start of transport. This fourth example is a broader concept than the first and second examples above, both of which describe situations where a shared vehicle becomes unable to transport passengers before the start of transport.

[0252] In the fourth example, when the dispatch unit 172 receives multiple ride-sharing requests, it assigns one ride-sharing vehicle to each of the multiple ride-sharing requests. When a predetermined time is reached, the dispatch unit 172 determines whether the assigned ride-sharing vehicle is unable to transport passengers. For example, the dispatch unit 172 may determine that the ride-sharing vehicle is unable to transport passengers if it does not receive an acceptance response to the dispatch notification within the acceptance deadline.

[0253] If the dispatch unit 172 determines that the assigned rideshare vehicle is unable to transport the passengers, it decomposes the multiple dispatch requests associated with the rideshare vehicle that has become unable to transport the passengers into multiple dispatches. For example, the dispatch unit 172 may decompose the requests into multiple dispatches by performing the first unacceptable-transport matching process described above, or it may decompose the requests into multiple dispatches by performing the second unacceptable-transport matching process described above.

[0254] As described above, the dispatch management device of the present invention (e.g., dispatch management server 50), which can communicate with a user terminal via a network, comprises one or more processors. The processors receive dispatch requests (e.g., ride-sharing dispatch requests 240) from the user terminal, assign one vehicle (e.g., a ride-sharing vehicle) to multiple dispatch requests, and if the assigned vehicle becomes unable to transport before the start of transport, the processors decompose the multiple dispatch requests associated with the vehicle that became unable to transport into multiple dispatches. With this configuration, even if a ride-sharing vehicle becomes unable to transport, it is possible to avoid a situation where the transport of user 2 is not carried out, and the decrease in convenience for user 2 in ride-sharing can be suppressed.

[0255] When the processor receives a normal dispatch request that currently requests a single-passenger ride, it may perform a normal matching process that associates a vehicle (e.g., a private transport vehicle) with the normal dispatch request on a one-to-one basis. The process of breaking down multiple dispatch requests associated with a vehicle that has become unable to transport (e.g., a ride-sharing vehicle) into multiple dispatches may be performed with priority over the normal matching process. With this configuration, breaking down multiple dispatch requests associated with a vehicle that has become unable to transport into multiple dispatches takes priority over the normal matching process, allowing for the determination of a new vehicle 32 relatively soon after a ride-sharing vehicle becomes unable to transport. As a result, situations that would cause delays in transport can be appropriately avoided.

[0256] Preferred embodiments of the present invention have been described above with reference to the attached drawings, but it goes without saying that the present invention is not limited to these embodiments. It is clear to those skilled in the art that various modifications or alterations can be conceived within the scope of the claims, and these will naturally also fall within the technical scope of the present invention.

[0257] For example, when user 2 requests a ride-sharing service, they may be able to specify the seat they will sit in in vehicle 32. Such seat specification may be limited to cases where not all seats are occupied (there are empty seats) in candidate trip 210. Alternatively, even if all seats are occupied in candidate trip 210, user 2 may be able to specify a seat that has not yet been assigned. Furthermore, not only in candidate trip 210, but also in confirmed trip 212, user 2 may be able to specify a seat that has not yet been assigned after a predetermined time following trip confirmation. Note that any one of these processes may be performed, or multiple processes may be performed.

[0258] Furthermore, if User 2 reserves a seat, an additional charge may be incurred only for User 2 who made the seat reservation. Such an additional charge can be implemented with either a fixed or variable fare. Alternatively, while no additional charge may be added to the overall fare, the fare ratio may be adjusted when calculating the pro-rata price for User 2 who made a seat reservation, so that User 2 who made a seat reservation is charged more than User 2 who did not. This way, User 2 who made a seat reservation benefits from being able to sit in their desired seat, while User 2 who did not make a seat reservation benefits from a lower fare. Such a variation in fare ratio cannot be implemented with a fixed fare, but it can be implemented with a variable fare. Furthermore, if, after a seat reservation has been made, the individual delivery breakdown (first delivery failure matching process) is performed, which breaks down multiple ride-sharing requests into multiple individual deliveries, the individual delivery breakdown may be performed at the same fare as when a seat reservation was made, or it may be performed at the normal fare as if no seat reservation had been made. In the latter case, user 2, who has not reserved a seat, may find that the fare, which was initially reduced, returns to its original price when the individual seating arrangement is broken up. However, in return, they can benefit from a more comfortable ride due to the individual seating arrangement.

[0259] Furthermore, a program that enables the computer to function as the dispatch management server 50, and a storage medium such as a computer-readable flexible disk, magneto-optical disk, ROM, CD, DVD, or BD on which the program is recorded are also provided. Here, "program" refers to a data processing means written in any language or writing method.

[0260] Furthermore, the processes described herein do not necessarily have to be performed chronologically in the order shown in the timing chart; they may include parallel or subroutine processing. [Explanation of Symbols]

[0261] 1. Dispatch Management System 2 users 3 Drivers 20 User Terminals 50 Dispatch Management Server 160 Dispatch Request Department 170 User Terminal Control Unit 172 Dispatch Department 174 Vehicle Terminal Control Unit

Claims

1. A dispatch management device that can communicate with a user terminal via a network, Equipped with one or more processors, The aforementioned processor, Multiple candidate trips are set, each associated with a predetermined route and transportation period. Upon receiving a dispatch request from the user terminal, The dispatch request is assigned in parallel to one or more candidate trips in which the pick-up and drop-off locations received from the user terminal that made the dispatch request are included in the travel route, and the desired transport time received from the user terminal that made the dispatch request is included in the transport period. At a predetermined time prior to the aforementioned transportation period, one of the candidate trips to which the dispatch request has been assigned will be designated as a confirmed trip. Assigning a vehicle to the aforementioned confirmed trip Vehicle dispatch management system.

2. The aforementioned processor, The candidate trips are identified such that the number of candidate trips assigned to each of the multiple aforementioned dispatch requests in parallel is minimized. The dispatch management device according to claim 1, wherein the identified candidate trip is set as the confirmed trip.

3. The aforementioned processor, The candidate trips are identified such that the number of dispatch requests assigned to the candidate trips is two or more. The dispatch management device according to claim 1, wherein the identified candidate trip is set as the confirmed trip.

4. The number of set candidate trips is greater than or equal to the number of vehicles. The aforementioned processor, The dispatch management device according to claim 1, which removes candidate trips that did not become confirmed trips from the list of candidates for confirmed trips.

5. The aforementioned processor, Even after the aforementioned confirmed trip has been determined, if the specified additional conditions are met, the vehicle dispatch request will be accepted again. The dispatch management device according to claim 1, which assigns the dispatch request to the confirmed trip.

6. The dispatch management device according to claim 5, wherein the additional condition is that the vehicle to which the confirmed trip is assigned allows the addition of users in a ride-sharing arrangement.

7. The dispatch management device according to claim 5, wherein the additional condition is that the pick-up and drop-off locations of the new dispatch request are located on the route of the confirmed trip.

8. The dispatch management device according to claim 5, wherein the additional condition is that a new dispatch request is received before the notification that the confirmed trip has been assigned to the vehicle, and the pick-up and drop-off locations of the new dispatch request are on the route of the candidate trip that has become the confirmed trip.

9. The dispatch management device according to claim 5, wherein the additional condition is that a new dispatch request is received before the vehicle reaches a predetermined distance before the first pick-up location in the confirmed trip, and the pick-up location and drop-off location of the new dispatch request are after the first pick-up location in the confirmed trip.

10. Computers Multiple candidate trips are set, each associated with a predetermined route and transportation period. Receive dispatch requests from user terminals. The dispatch request is assigned in parallel to one or more candidate trips in which the pick-up and drop-off locations received from the user terminal that made the dispatch request are included in the travel route, and the desired transport time received from the user terminal that made the dispatch request is included in the transport period. At a predetermined time prior to the aforementioned transportation period, one of the candidate trips to which the dispatch request has been assigned will be designated as a confirmed trip. Assigning a vehicle to the aforementioned confirmed trip Vehicle dispatch management method.

11. On the computer, Multiple candidate trips are set, each associated with a predetermined route and transportation period. Receive dispatch requests from user terminals. The dispatch request is assigned in parallel to one or more candidate trips in which the pick-up and drop-off locations received from the user terminal that made the dispatch request are included in the travel route, and the desired transport time received from the user terminal that made the dispatch request is included in the transport period. At a predetermined time prior to the aforementioned transportation period, one of the candidate trips to which the dispatch request has been assigned will be designated as a confirmed trip. Assigning a vehicle to the aforementioned confirmed trip A program to perform a task.

Images