Vehicle dispatch management system, vehicle dispatch management apparatus, vehicle dispatch management method, and program

Abstract

To efficiently dispatch a vehicle within working hours.SOLUTION: A vehicle dispatch management apparatus capable of communicating with a user terminal via a network includes one or more processors. The processor derives a travel value (estimated time of arrival + scheduled pick-up time) associated with traveling of a vehicle on the basis of a pick-up location and a drop-off location added to a vehicle dispatch request received from the user terminal, derives a working condition (equal to or less than remaining working hours) regarding remaining working hours in the vehicle, and does not dispatch the vehicle to the vehicle dispatch request if the travel value does not satisfy the working condition.SELECTED DRAWING: Figure 14

Description

[Technical Field]

[0001] The present invention relates to a vehicle allocation management system, a vehicle allocation management device, a vehicle allocation management method, and a program for managing vehicle allocation. [Background technology]

[0002] There are known technologies for dispatching a taxi in response to a user's request for dispatching a taxi. For example, Patent Document 1 discloses a technology for estimating the arrival times of the user and the taxi at the user's desired boarding location, matching the estimated results, and dispatching a taxi so as to minimize the difference between the estimated results. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Publication No. 2023-027694 Summary of the Invention [Problem to be solved by the invention]

[0004] Recently, the shortage of taxi drivers has become a serious problem in some regions. As a result, there are areas where the supply of taxis is insufficient to meet the demand for taxi dispatch. As a result, the introduction of ride-sharing (Japanese-style ride-sharing), in which ordinary drivers use their own cars to transport users for a fee, is progressing.

[0005] Whether it's a taxi or a ride-sharing vehicle, there are multiple possible working styles, such as daytime shifts, nighttime shifts, or alternate-day shifts. There are also multiple possible pay structures, such as hourly wages, fixed salary, fixed salary plus commission, and full commission. For example, taxi drivers are subject to strict legal regulations governing working hours, so if a driver has a set end time for their shift, they will want to finish work by that time. However, if a driver receives a request for a ride with a distant drop-off location near the end of their shift, it becomes difficult for them to finish work at the end of their shift.

[0006] In view of the above problems, the present invention aims to provide a vehicle dispatch management system, a vehicle dispatch management device, a vehicle dispatch management method, and a program that enable efficient vehicle dispatch during working hours. [Means for solving the problem]

[0007] In order to solve the above problem, in the vehicle dispatch management system of the present invention, which includes a user terminal and a vehicle dispatch management device capable of communicating with the user terminal via a network, the user terminal includes one or more first processors, and the vehicle dispatch management device includes one or more second processors, the first processor sends a vehicle dispatch request to the vehicle dispatch management device, with a boarding location and a disembarking location added in accordance with user input, the second processor derives a driving value associated with the vehicle's travel based on the boarding location and the disembarking location, derives working conditions related to the remaining working time for the vehicle, and does not allocate the vehicle to the vehicle dispatch request if the driving value does not satisfy the working conditions.

[0008] The vehicle dispatch management device of the present invention, which can communicate with a user terminal via a network, has one or more processors, which derive a driving value associated with the vehicle's driving based on the boarding and disembarking locations attached to the dispatch request received from the user terminal, derive working conditions related to the remaining working time for the vehicle, and if the driving value does not satisfy the working conditions, do not assign the vehicle to the dispatch request.

[0009] Another vehicle dispatch management device of the present invention, which can communicate with a user terminal via a network, has one or more processors, which derive a driving value associated with the vehicle's driving based on the boarding and disembarking locations attached to the dispatch request received from the user terminal, derive working conditions related to the remaining working time for each of the multiple vehicles, and can allocate a vehicle whose driving value meets the working conditions to the dispatch request, but will not allocate a vehicle whose driving value does not meet the working conditions.

[0010] The processor may allocate a vehicle whose mileage value satisfies the working conditions and a vehicle that does not have the working conditions to the dispatch request, but may not allocate a vehicle whose mileage value does not satisfy the working conditions.

[0011] Another vehicle dispatch management device of the present invention, which can communicate with a user terminal via a network, has one or more processors, which derive a driving value associated with the vehicle's driving based on the boarding and disembarking locations attached to the dispatch request received from the user terminal, derive working conditions related to the remaining working time for each of the multiple vehicles, and allocates vehicles whose driving values ​​satisfy the working conditions in response to the dispatch request with priority over vehicles whose driving values ​​do not satisfy the working conditions.

[0012] The processor may allocate, in response to the dispatch request, vehicles whose mileage values ​​satisfy the working conditions and vehicles that do not have the working conditions attached, in preference to vehicles whose mileage values ​​do not satisfy the working conditions.

[0013] The travel time may be the sum of the estimated distance time to arrive at the boarding location and the estimated travel time from the boarding location to the disembarking location, and the working condition may be equal to or less than the remaining time of work.

[0014] The travel value may be the sum of the estimated arrival distance to the boarding location and the estimated travel distance from the boarding location to the disembarking location, and the working condition may be less than the travel distance equivalent value of the remaining working time.

[0015] In order to solve the above problem, the vehicle dispatch management method of the present invention has a computer that derives a driving value associated with the vehicle's driving based on the boarding and disembarking locations attached to a vehicle dispatch request received from a user terminal, derives working conditions related to the remaining time of work in the vehicle, and does not assign the vehicle to the vehicle dispatch request if the driving value does not satisfy the working conditions.

[0016] In order to solve the above problem, the program of the present invention causes a computer to derive a driving value associated with the vehicle's driving based on the boarding and disembarking locations attached to a vehicle dispatch request received from a user terminal, derive working conditions related to the remaining working time in the vehicle, and if the driving value does not satisfy the working conditions, not allocate the vehicle to the vehicle dispatch request. [Effects of the Invention]

[0017] According to the present invention, efficient vehicle allocation during working hours is possible. [Brief explanation of the drawings]

[0018] [Figure 1] FIG. 1 is a block diagram for explaining an outline of a vehicle dispatch management system. [Figure 2] FIG. 2 is a block diagram illustrating the configuration of a user terminal. [Figure 3] FIG. 3 is a block diagram illustrating the configuration of the taxi terminal. [Figure 4] FIG. 4 is a block diagram illustrating the configuration of the NRS terminal. [Figure 5] FIG. 5 is a block diagram illustrating the configuration of the business server. [Figure 6] FIG. 6 is a block diagram illustrating the configuration of the vehicle dispatch management server. [Figure 7] FIG. 7 is a sequence diagram showing the flow of processing in a vehicle allocation management method by the vehicle allocation management system. [Figure 8] FIG. 8 is an explanatory diagram for explaining the processing of the dispatch unit. [Figure 9] FIG. 9 is a first explanatory diagram for explaining the pair creation process. [Figure 10] Fig. 10A is a second explanatory diagram for explaining the pair creating process, and Fig. 10B is a third explanatory diagram for explaining the pair creating process. [Figure 11] Fig. 11A is a first explanatory diagram for explaining the matching process, Fig. 11B is a second explanatory diagram for explaining the matching process, and Fig. 11C is a third explanatory diagram for explaining the matching process. [Figure 12] FIG. 12 is an explanatory diagram showing the results of matching by the dispatch unit. [Figure 13] Fig. 13A is a first explanatory diagram for explaining the processing of the dispatch unit, and Fig. 13B is a second explanatory diagram for explaining the processing of the dispatch unit. [Figure 14] Fig. 14A is a first explanatory diagram for explaining the processing of the dispatch unit, and Fig. 14B is a second explanatory diagram for explaining the processing of the dispatch unit. DETAILED DESCRIPTION OF THE INVENTION

[0019] Preferred embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Dimensions, materials, and other specific values ​​shown in the embodiments are merely examples for facilitating understanding of the invention and, unless otherwise specified, do not limit the present invention. In this specification and drawings, elements having substantially the same functions and configurations are designated by the same reference numerals to avoid redundant explanation, and elements not directly related to the present invention are not shown.

[0020] (Vehicle Dispatch Management System 1) FIG. 1 is a block diagram for explaining an overview of a vehicle dispatch management system 1. The vehicle dispatch management system 1 includes a plurality of user terminals 20, a plurality of taxi terminals 30, a plurality of taxi vehicles 32, a plurality of NRS terminals 40, a plurality of NRS vehicles 42, one or more business operator servers 50, and one or more vehicle dispatch management servers 60. In the vehicle dispatch management system 1, NRS vehicles 42 are included in addition to taxi vehicles 32 as commercial vehicles that serve as transportation means for users 2. Here, NRS is an abbreviation for Nippon-style Ride Share or Nihon-gata Ride Share, and refers to a service in which ordinary drivers transport users 2 for a fee using their own cars or the like.

[0021] The user terminal 20 is an electronic device owned by the user 2. The user 2 is a passenger in a commercial vehicle (such as a taxi vehicle 32 or an NRS vehicle 42). Examples of the user terminal 20 include a smartphone, a personal computer, and a tablet PC. In the vehicle dispatch management system 1, there are multiple combinations of users 2 and user terminals 20. Note that the user 2 in this embodiment is not limited to one person, and may refer to multiple people who can ride in one taxi vehicle 32.

[0022] FIG. 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 communicatively connected to an external device, such as a vehicle dispatch management server 60, via a base station 5 and a network 6. The processing device 122 includes a semiconductor integrated circuit including a processor such as a central processing unit (CPU), a read-only memory (ROM) storing programs, and a random access memory (RAM) used as a work area. A user application for the vehicle dispatch management system 1 is installed on the user terminal 20. The processing device 122 runs the program to control the user application and function as a vehicle dispatch request unit 180 that supports the user 2 in inputting a vehicle dispatch request. The display device 124 includes a liquid crystal display, an organic electroluminescence (EL) display, or the like, and displays various information, such as an image of the user application used to make a vehicle dispatch request. The input device 126 includes a touch panel, switches, buttons, keys, a microphone for voice input, etc. superimposed on the display device 124, and accepts input from the user 2, such as information for requesting a vehicle dispatch. The storage device 128 is configured with storage means such as an HDD (Hard Disk Drive), SD memory, SSD (Solid State Drive), etc.

[0023] The taxi terminal 30 is an electronic device loaned to a taxi driver 3 of a taxi vehicle (first vehicle) 32, or an electronic device owned by the taxi driver 3. The taxi terminal 30 is associated with the taxi vehicle 32. Examples of the taxi terminal 30 include a smartphone, a personal computer, and a tablet PC. The taxi terminal 30 is an example of a vehicle terminal (first vehicle terminal).

[0024] FIG. 3 is a block diagram illustrating the configuration of the taxi terminal 30. The taxi 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 communicatively connected to external devices, such as the operator server 50 and the dispatch management server 60, via a base station 5 and a network 6. The processing device 132 includes a semiconductor integrated circuit including a processor (CPU), a ROM storing programs and the like, and a RAM used as a work area. A vehicle application for the dispatch management system 1 is installed in the taxi terminal 30. The processing device 132 controls the vehicle application by running the program and functions as a dispatch response unit 182 that supports the taxi driver 3 in inputting responses to dispatch requests. The display device 134 includes a liquid crystal display and an organic electroluminescence (EL) display, and displays various information, such as a notification that the taxi 32 has been the subject of a dispatch request (dispatch target notification) and information related to the dispatch request (boarding location, user information about the user 2, and disembarking location). Hereinafter, the target of a dispatch request may be referred to as the "dispatch target," and the vehicle that has been dispatched may be referred to as the "dispatch target vehicle." The input device 136 includes a touch panel, switches, buttons, keys, a microphone for voice input, etc. superimposed on the display device 134, and receives input from the taxi driver 3, such as acceptance of the dispatch request. The storage device 138 is composed of storage means such as an HDD, SD memory, or SSD. The taxi terminal 30 can acquire its own position on a map through location identification means such as a GPS (Global Positioning System).

[0025] The taxi driver 3 is a driver who holds a Class 2 driver's license for a standard vehicle and belongs to a taxi business (general passenger automobile transportation business). The taxi vehicle 32 is, for example, a vehicle that belongs to a taxi business and can transport the user 2 as a taxi business for a fee. In the vehicle dispatch management system 1, there are multiple combinations of taxi drivers 3, taxi vehicles 32, and taxi terminals 30. Note that in this embodiment, an example of a four-wheeled taxi (hire car) is given as the taxi vehicle 32 to be dispatched, but the taxi vehicle 32 is not limited to this example, and may include, for example, a motorcycle (motorcycle taxi) or the like as long as it is a vehicle capable of transporting people.

[0026] The NRS terminal 40 is an electronic device owned by the NRS driver 4, and can be placed in the NRS vehicle (second vehicle) 42. Examples of the NRS terminal 40 include a smartphone, a personal computer, and a tablet PC. The NRS driver 4, for example, brings his / her own NRS terminal 40 into the NRS vehicle 42, which is his / her own private car, and drives the NRS vehicle 42. The NRS terminal 40 is not limited to being brought into the vehicle when driving, but may also be pre-installed in the NRS vehicle 42. The NRS terminal 40 is used when the NRS driver 4 is on duty. This makes it possible to use the NRS vehicle 42 as a commercial vehicle in place of the taxi vehicle 32. The NRS terminal 40 is an example of a vehicle terminal (second vehicle terminal).

[0027] FIG. 4 is a block diagram illustrating the configuration of the NRS terminal 40. The NRS terminal 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 communicatively connected to external devices, such as the operator server 50 and the vehicle dispatch management server 60, via the base station 5 and the network 6. The processing device 142 includes a semiconductor integrated circuit including a processor (CPU), a ROM storing programs, and a RAM used as a work area. A vehicle application for the vehicle dispatch management system 1 is installed in the NRS terminal 40. The processing device 142 controls the vehicle application by running the program and functions as a dispatch response unit 184 that supports the NRS driver 4 in inputting responses to vehicle dispatch requests. The display device 144 includes a liquid crystal display and an organic electroluminescence (EL) display, and displays various information, such as a notification that the NRS vehicle 42 has been selected for dispatch (dispatch target notification) and information related to the dispatch request (boarding location, disembarking location, and user information related to the user 2). The input device 146 includes a touch panel, switches, buttons, keys, a microphone for voice input, etc. superimposed on the display device 144, and receives input from the NRS driver 4, such as acceptance of a vehicle dispatch request. The storage device 148 is composed of storage means such as an HDD, SD memory, or SSD. The NRS terminal 40 can obtain its own position on a map through location identification means such as GPS.

[0028] The NRS driver 4 is a driver who holds a Class 1 driver's license for a standard vehicle and is involved in a ride-sharing business (a private vehicle passenger transportation business for a fee). However, in this embodiment, an example will be described in which a taxi business also manages a ride-sharing business based on Article 78, Paragraph 3 of the Road Transportation Act. Therefore, the NRS driver 4 can be said to be a driver who is involved in a taxi business. The NRS driver 4 differs from the taxi driver 3 in that he or she does not hold a Class 2 driver's license for a standard vehicle or may have poor driver qualifications, driving skills, and knowledge. The NRS vehicle 42 is, for example, a vehicle driven by the NRS driver 4 and can transport users 2 for a fee as part of a ride-sharing business. The NRS vehicle 42 can be a private car or an idle taxi vehicle 32. The vehicle dispatch management system 1 has multiple combinations of NRS drivers 4, NRS vehicles 42, and NRS terminals 40. Note that the NRS driver 4 cannot engage in so-called patrol business, which is to search for users 2 who want to ride while driving the taxi vehicle 32, as the taxi driver 3 does. However, in the case of paid passenger transportation by private car based on Article 78, Paragraph 3 of the Road Transportation Act, NRS Driver 4 may charge User 2 a fee (fare) equivalent to that charged for general passenger automobile transportation business as compensation for transporting User 2.

[0029] Such taxi vehicles 32 and NRS vehicles 42 have designated operating areas in which they can operate. A taxi vehicle 32 can operate in the operating area where its taxi business office is located. For example, if the operating area is within Tokyo's special wards, the taxi vehicle 32 can operate in Tokyo's 23 wards, Musashino City, and Mitaka City. The operating area of ​​such a taxi vehicle 32 may be referred to as a transportation area.

[0030] The operating area of ​​the NRS vehicle 42 is included in the operating area of ​​the taxi vehicle 32, and is often narrower than the operating area of ​​the taxi vehicle 32. This is for the following reason. The NRS vehicle 42 is intended to operate in an auxiliary role to the taxi vehicle 32 in areas (or areas and time periods) where a shortage of taxi drivers 3 means that a taxi vehicle 32 cannot be immediately dispatched even if a person wants to ride in it. Therefore, the operating area of ​​the NRS vehicle 42 is set to be limited to areas where a taxi vehicle 32 cannot be immediately dispatched even if a person wants to ride in it. Therefore, the operating area of ​​the NRS vehicle 42 is often narrower than the operating area of ​​the taxi vehicle 32. Furthermore, while the operating area of ​​the taxi vehicle 32 is limited in geographical range, there are no time restrictions, whereas the operating area of ​​the NRS vehicle 42 is not only limited in geographical range, but also in time restrictions, such as only during time periods (including seasons) when the supply of taxi vehicles 32 is insufficient to meet the demand. In this way, a taxi shortage situation in an area, time period, or time zone where there is a shortage of taxi vehicles 32 is considered to be "unavoidable for the public welfare" under Article 78, paragraph 3 of the Road Transportation Act, and a ride-sharing business is permitted. Note that the operating area of ​​the NRS vehicle 42 is managed by a taxi business operator, just like the operating area of ​​the taxi vehicle 32, and is subject to the same regulations as the operating area of ​​the taxi vehicle 32. Note that in this embodiment, an example is given in which the operation of the NRS vehicle 42 is restricted not only in terms of the geographical range of the operating area but also in terms of the time period, but this is not limiting, and there are also cases in which the operating area is restricted only in terms of the geographical range, with no time restrictions.

[0031] Hereinafter, for convenience of explanation, when there is no need to distinguish between taxi vehicle 32 and NRS vehicle 42, automobiles that transport user 2 for a fee, including taxi vehicle 32 and NRS vehicle 42, may be collectively referred to simply as "vehicles." Furthermore, when there is no need to distinguish between taxi driver 3 and NRS driver 4, drivers, including taxi driver 3 and NRS driver 4, may be collectively referred to simply as "drivers." Furthermore, when there is no need to distinguish between taxi terminal 30 and NRS terminal 40, devices possessed by drivers, including taxi terminal 30 and NRS terminal 40, may be collectively referred to simply as "vehicle terminals," display devices of vehicle terminals, including display device 134 and display device 144, may be collectively referred to simply as "vehicle display devices," input devices of vehicle terminals, including input device 136 and input device 146, may be collectively referred to simply as "vehicle input devices," and vehicle dispatch response units of vehicle terminals, including vehicle dispatch response unit 182 and vehicle dispatch response unit 184, may be collectively referred to simply as "vehicle dispatch response units."

[0032] FIG. 5 is a block diagram illustrating the configuration of the business operator server 50. The business operator server 50 is an information processing device (computer) owned by a business operator operating a taxi business. The business operator server 50 manages taxi vehicles 32 driven by taxi drivers 3 belonging to a taxi business and NRS vehicles 42 driven by NRS drivers 4. The business operator server 50 includes a communication device 150, a processing device 152, a display device 154, an input device 156, and a storage device 158. The communication device 150 is communicatively connected to external devices, such as taxi terminals 30, NRS terminals 40, and a vehicle dispatch management server 60, via a network 6. The processing device 152 includes a semiconductor integrated circuit including a processor (CPU), a ROM storing programs, and a RAM used as a work area. By running a program, the processing device 152 functions as a vehicle management unit 186 that manages vehicles belonging to the taxi business. The display device 154 includes a liquid crystal display (LCD) or an organic electroluminescence (EL) display, and displays various information, such as driver or vehicle information, obtained directly from the vehicles or via the vehicle dispatch management server 60. The input device 156 includes a keyboard, a touch panel superimposed on the display device 154, a microphone for voice input, etc., and receives input from an operator at the business. For example, the operator can talk to the driver or check images of the inside and outside of the vehicle, including an image of the driver, through the business server 50. The storage device 158 is composed of storage means such as an HDD, SD memory, or SSD.

[0033] FIG. 6 is a block diagram illustrating the configuration of the vehicle dispatch management server 60. The vehicle dispatch management server (vehicle dispatch management device) 60 is an information processing device (computer) that manages vehicles belonging to a taxi company based on a contract between the vehicle dispatch management company and the taxi company. The vehicle dispatch management server 60 is an example of a vehicle dispatch management device with server functions and is operated by the vehicle dispatch management company. The vehicle dispatch management server 60 can dispatch a vehicle to a user 2 in response to a vehicle dispatch request from a user terminal 20. The vehicle dispatch management server 60 includes a communication device 160, a processing device 162, and a storage device 164. The communication device 160 is communicatively connected to external devices, such as the user terminal 20, the taxi terminal 30, the NRS terminal 40, and the company server 50, via the network 6. The processing device 162 has a semiconductor integrated circuit including a processor (CPU), a ROM storing programs and the like, a RAM used as a work area, and the like. By running programs, the processing device 162 functions as functional units such as a user terminal control unit 170, a vehicle dispatch unit 172, and a vehicle terminal control unit 174. The user terminal control unit 170 controls the user application installed in the user terminal 20. The vehicle allocation unit 172 allocates a vehicle in response to a vehicle allocation request. The vehicle terminal control unit 174 controls the vehicle application installed in the vehicle terminal. The storage device 164 is composed of storage means such as an HDD, SD memory, or SSD, and stores information about the user 2 and the vehicle.

[0034] In the vehicle dispatch management system 1, when allocating a vehicle in response to a vehicle dispatch request (i.e., when dispatching a vehicle), for example, by matching a plurality of vehicle dispatch requests with a plurality of vehicles, one vehicle is allocated to, for example, one vehicle dispatch request from one user 2. Here, matching refers to a process of exclusively associating any vehicle dispatch request with any vehicle in a state where there are multiple vehicle dispatch requests and multiple vehicles. In the following, an example of allocating one vehicle to one vehicle dispatch request will be described, but if multiple users 2 are allowed to ride in one vehicle, so-called carpooling, one vehicle may also be allocated to multiple vehicle dispatch requests from multiple users 2.

[0035] (Vehicle allocation management method) FIG. 7 is a sequence diagram showing the processing flow of the vehicle dispatch management method by the vehicle dispatch management system 1. The vehicle dispatch management system 1 extracts one or more vehicles that can be dispatched from a plurality of vehicles for each dispatch request, and identifies one vehicle to be dispatched through matching. The vehicle dispatch management system 1 then asks the driver of the vehicle that has been selected as the dispatch target vehicle to dispatch the vehicle, and when the driver accepts the dispatch inquiry, the dispatch is confirmed. Each process in the vehicle dispatch management method will be described in detail below.

[0036] (Vehicle dispatch request processing S1) When user 2 wishes to ride in a vehicle, user 2 makes a vehicle dispatch request through user terminal 20. Specifically, vehicle dispatch request unit 180 of user terminal 20 launches a user application for making a vehicle dispatch request. The user application displays a map of a predetermined range including the current location of user terminal 20, and displays vehicles (e.g., taxi vehicles 32 and NRS vehicles 42) located near user terminal 20. Vehicle dispatch request unit 180 accepts user 2's vehicle dispatch request through input device 126. At this time, user 2 can set setting items for the vehicle to be boarded. Vehicle dispatch request unit 180 adds information related to the setting items set by user 2 and transmits the vehicle dispatch request to vehicle dispatch management server 60.

[0037] In addition to the initial setting of desired dispatch, the setting items include, for example, boarding location, disembarking location, payment information, dispatch category, taxi company, vehicle attributes, toll road information, etc.

[0038] The boarding location indicates the location on the map where User 2 wishes to board the vehicle. User 2 can set User 2's current location as the boarding location, or can set a desired location different from User 2's current location as the boarding location. The disembarking location indicates the location on the map where User 2 wishes to disembark. When User 2 sets the boarding location and disembarking location among the setting items, the fare calculated based on the set time, boarding location, and disembarking location is displayed on display device 124. In this way, User 2 can know in advance the fare that will be paid by boarding the vehicle.

[0039] When user 2 limits the vehicle dispatch target to taxi vehicles 32 only, the drop-off location is not required input information but is optional information that can be input. On the other hand, when user 2 includes NRS vehicles 42 in the vehicle dispatch target, the drop-off location is required input information. This is because ride-sharing services based on Article 78, Paragraph 3 of the Road Transportation Act require that the fare be determined in advance as a vehicle dispatch requirement (a requirement for dispatching an NRS vehicle 42). Therefore, when an NRS vehicle 42 is included in the vehicle dispatch target, user 2 must input the drop-off location in addition to the pick-up location in order to calculate the fare in advance. Payment information is information related to the payment of fees associated with vehicle use (e.g., fares and other additional fees). Note that when an NRS vehicle 42 is included in the vehicle dispatch target, in addition to inputting the drop-off location, information related to cashless automatic payment by credit card or the like (e.g., credit card number) is required as payment information. This is because ride-sharing services based on Article 78, Paragraph 3 of the Road Transportation Act require that a vehicle dispatch request be made through a user application and that cashless automatic payment be made as a vehicle dispatch requirement. Here, automatic payment refers to a process in which, after the vehicle arrives at the drop-off location, the driver can charge the user 2 the fee for using the vehicle based on information regarding the user 2's automatic payment, without the user 2 paying cash or inputting information regarding electronic money into the cashless terminal. In this way, the NRS vehicle 42 differs from the taxi vehicle 32 in that the dispatch requirement requires input of information regarding the drop-off location and automatic payment. However, this is not the only example, and the taxi vehicle 32 may also require a dispatch requirement (a requirement that allows the taxi vehicle 32 to be dispatched). For example, in an operation mode such as a hire car that does not operate as a so-called street car, the taxi vehicle 32 also requires input of information regarding the drop-off location and automatic payment as a dispatch requirement, similar to the NRS vehicle 42.

[0040] The dispatch category indicates the category of the vehicle to be dispatched. For example, as described above, taxi drivers 3 often hold Class 2 driver's licenses for standard vehicles and have high driver qualifications, driving skills, knowledge, etc. On the other hand, NRS drivers 4 vary in their driver qualifications, driving skills, knowledge, etc. Furthermore, even drivers who hold Class 2 driver's licenses for standard vehicles are not regularly employed as taxi drivers 3, and there are specific drivers who, for example, rent vehicles from taxi companies to transport users 2. These specific drivers often vary in their driver qualifications, driving skills, knowledge, etc. Note that when dispatching a specific vehicle driven by a specific driver, user 2 must also enter information about the drop-off location and automatic payment, just as with the NRS vehicle 42. Herein, vehicles with different dispatch requirements than taxi vehicle 32, including NRS vehicles 42 and specific vehicles, may be simply referred to as "required vehicles." Because driver qualifications, etc., vary depending on the vehicle, some users 2 may request a taxi vehicle 32 driven by taxi driver 3. In this case, user 2 selects "only taxi vehicles 32" as the dispatch category. On the other hand, if the dispatch target is limited to taxi vehicles 32, user 2 will miss the opportunity to ride in a vehicle with requirements, even in a situation where a vehicle with requirements can be dispatched quickly. Therefore, user 2 may not limit the dispatch target to taxi vehicles 32, but may prefer taxi vehicles 32 and vehicles with requirements so that he or she can board a vehicle quickly. In this case, user 2 should select "taxi vehicles 32 and vehicles with requirements" as the dispatch category.

[0041] Here, a dispatch mode in which a taxi vehicle 32 is assigned to a dispatch request but a vehicle with a condition is not assigned is referred to as a first dispatch mode, and a dispatch mode in which either a taxi vehicle 32 or a vehicle with a condition is assigned to a dispatch request is referred to as a second dispatch mode. User 2 can transition from the first dispatch mode to the second dispatch mode by inputting information about the boarding location, the drop-off location, and automatic payment through the user terminal 20. As described above, user 2 can select "taxi vehicle 32 only" or "taxi vehicle 32 and vehicle with a condition" as the dispatch category. Therefore, even if information about the drop-off location and automatic payment has been input, if user 2 selects "taxi vehicle 32 only" as the dispatch category, the system transitions from the second dispatch mode to the first dispatch mode. User 2 can set the purpose of use of the vehicle (e.g., use for business purposes) or set it so that the drop-off location is not input in advance. In this case, even if the user does not specify and input a dispatch category, only taxi vehicles 32 are automatically dispatched (first dispatch mode). If user 2 does not input the drop-off location in advance, the drop-off location may be communicated directly to the driver, or may be input after getting in via user terminal 20. Furthermore, when user 2 uses taxi vehicle 32 for business purposes, an additional fee may be charged to user 2 personally, or may be charged to the company or business entity to which user 2 belongs.

[0042] In this embodiment, an example will be described in which there are a first dispatch mode and a second dispatch mode as the dispatch mode. However, the present invention is not limited to this example, and if there are other circumstances, such as a cheaper fare to ride in a vehicle with special requirements than in a taxi vehicle 32, a third dispatch mode may be provided as the dispatch mode in which a taxi vehicle 32 is not allocated to a dispatch request, but a vehicle with special requirements is allocated.

[0043] The taxi company indicates the company to which the taxi driver 3 or NRS driver 4 belongs as a taxi business. User 2 can specify the desired taxi company by inputting information into the taxi company setting items. Vehicle attributes indicate the type and equipment of the vehicle. Examples of vehicle attributes include whether or not it is a high-class vehicle (a so-called hire car), whether or not it is wheelchair accessible, and whether or not it has sliding doors. User 2 can specify the attributes of the vehicle he or she wishes to dispatch by inputting information into the vehicle attribute setting items. Toll road information indicates whether or not toll roads, such as expressways, will be used. If the toll road information indicates the use of toll roads, toll roads will be actively included in the route from the pick-up point to the drop-off point.

[0044] (Dispatch request accumulation process S2) The user terminal control unit 170 of the vehicle dispatch management server 60 controls the user application of the user terminal 20 and performs processing corresponding to the dispatch request input through the user application. When the user terminal control unit 170 receives a dispatch request from the user terminal 20, it first identifies which of multiple operating areas the boarding location in the setting items is included in. The user terminal control unit 170 assigns the same identifier (taxi operating area ID) to dispatch requests sent in the same operating area. The user terminal control unit 170 associates the dispatch request received from the user terminal 20, including information on the various setting items described above, with the operating area identifier and the time of receipt of the dispatch request, and sequentially stores them in the storage device 164.

[0045] (Vehicle dispatch request extraction process S3) The vehicle dispatch unit 172 of the vehicle dispatch management server 60 extracts all vehicle dispatch requests that have occurred in a specified business area up to a specified execution timing from among the multiple vehicle dispatch requests stored in the storage device 164. Here, the execution timing indicates the timing at which the vehicle dispatch request extraction process S3 is started for the multiple vehicle dispatch requests, and is expressed, for example, as a time. The execution timing is set periodically and repeatedly at a specified processing interval. Therefore, a new execution timing is set after a specified processing period has elapsed since the vehicle dispatch request extraction process S3 was started at the previous execution timing. Here, the specified processing period is the length of time for which vehicle dispatch requests to be processed at one time are accumulated, and is set to, for example, 5 seconds.

[0046] However, in reality, in the matching started at the previous execution timing, a vehicle to be allocated may not have been determined for a vehicle allocation request. Such vehicle allocation requests for which a vehicle to be allocated has not been determined are carried over to the current execution timing, and matching continues. Therefore, the vehicle allocation unit 172 extracts, as vehicle allocation requests accumulated up to the current execution timing, vehicle allocation requests for which a vehicle to be allocated has not been determined in the previous matching, in addition to vehicle allocation requests accumulated from the previous execution timing to the current execution timing.

[0047] (Vehicle extraction process S4) The vehicle dispatch unit 172 extracts one or more vehicles that satisfy predetermined extraction conditions related to the vehicle dispatch request extracted in the vehicle dispatch request extraction process S3 from among multiple vehicles that can accommodate the user 2. Here, the extraction conditions include the conditions of the various setting items in the vehicle dispatch request, such as the vehicle dispatch category. If the vehicle dispatch category in the vehicle dispatch request is set to "taxi vehicles 32 only," the vehicle dispatch unit 172 extracts only taxi vehicles 32 for the vehicle dispatch request. If the vehicle dispatch category in the vehicle dispatch request is set to "taxi vehicles 32 and vehicles with special requirements," the vehicle dispatch unit 172 extracts taxi vehicles 32 and vehicles with special requirements for the vehicle dispatch request. Another extraction condition is, for example, that the estimated time of arrival at the boarding location is short. Specifically, the extraction condition is, for example, that the distance between the boarding location and the vehicle's current location is within a predetermined distance (e.g., 10 km), or that the estimated time of arrival at the boarding location is within a predetermined time (e.g., 10 minutes). In this case, the distance is the Euclidean distance between the boarding location and the current location of the vehicle, and the estimated arrival time is the time obtained by dividing the Euclidean distance by a predetermined speed (for example, the average speed when the vehicle is in operation). The operating state of the vehicle mainly refers to a pick-up state (a state in which the vehicle is traveling toward the boarding location of user 2) and a hire state (a state in which the vehicle is traveling with user 2 on board), and does not include a stopped state in which the vehicle is waiting for a dispatch request. Furthermore, the dispatch unit 172 may further limit the number of vehicles to be extracted to a predetermined number (for example, 10 vehicles) as an extraction condition, in order of the shortest distance between the boarding location and the current location of the vehicle or the shortest estimated arrival time at the boarding location.

[0048] 8 is an explanatory diagram for explaining the processing of the vehicle dispatch unit 172. FIG. 8 shows four users 2a to 2d who have made vehicle dispatch requests within the service area A, and eleven vehicles 32a, 42b, 32c, 32d, 32e, 42f, 32g, 32h, 42i, 42j, and 32k that exist within the service area A. In this embodiment, seven taxi vehicles 32a, 32c, 32d, 32e, 32g, 32h, and 32k and four NRS vehicles 42b, 42f, 42i, and 42j are shown. It is assumed that the service area A is a service area where the service area of ​​the taxi vehicle 32 and the service area of ​​the NRS vehicle 42 are the same.

[0049] The vehicle allocation unit 172 sets extraction conditions for each of the vehicle allocation requests extracted in the vehicle allocation request extraction process S3, i.e., for each of the vehicle allocation requests 22a to 22d of the users 2a to 2d. Here, the extraction condition is that the distance between the boarding location and the current location of the vehicle is equal to or less than a predetermined distance. Therefore, extraction conditions 24a to 24d, shown by dashed arcs in FIG. 8, are set for each of the vehicle allocation requests 22a to 22d of the users 2a to 2d.

[0050] The vehicle dispatch unit 172 extracts vehicles that satisfy extraction conditions 24a to 24d for each of the vehicle dispatch requests 22a to 22d of users 2a to 2d. For example, the vehicles that satisfy extraction condition 24a for user 2a's vehicle dispatch request 22a are vehicles 32a, 42b, 32c, 32d, and 32e. The vehicles that satisfy extraction condition 24b for user 2b's vehicle dispatch request 22b are vehicles 32e, 42f, 32g, 32h, and 42i. The vehicles that satisfy extraction condition 24c for user 2c's vehicle dispatch request 22c are vehicles 32d, 32e, 42f, 32h, and 42i. The vehicles that satisfy extraction condition 24d for user 2d's vehicle dispatch request 22d are vehicles 32d, 42i, and 42j. The vehicle dispatch unit 172 extracts all of the vehicles 32a, 42b, 32c, 32d, 32e, 42f, 32g, 32h, 42i, and 42j, which are surrounded by solid lines in Figure 8 and satisfy any one of the extraction conditions 24a to 24d for each of the vehicle dispatch requests 22a to 22d, and excludes vehicle 32k, which does not satisfy any of the extraction conditions 24a to 24d, as a vehicle that has no possibility of being dispatched.

[0051] (Pair generation process S5) For each vehicle dispatch request 22 extracted in the vehicle dispatch request extraction process S3, the vehicle dispatch unit 172 extracts at least one pair candidate vehicle that satisfies a predetermined pairing condition from the vehicles 32a, 42b, 32c, 32d, 32e, 42f, 32g, 32h, 42i, and 42j extracted in the vehicle extraction process S4, and associates the extracted pair candidate vehicle with the vehicle dispatch request 22. Here, the pairing condition is that the vehicle's allowable items conform to all of the setting items of the vehicle dispatch request 22. For example, if the vehicle attribute included in the setting items of the vehicle dispatch request 22 is "sliding door compatible," the vehicle dispatch unit 172 determines that the vehicle is "suitable" if the vehicle's allowable items include sliding doors. Furthermore, for example, if the vehicle dispatch category included in the setting items of the vehicle dispatch request 22 is "taxi vehicles 32 only," the vehicle dispatch unit 172 determines that the vehicle is "suitable" if it is a taxi vehicle 32. The vehicle allocation unit 172 determines that a vehicle does not satisfy the pairing conditions if any of the vehicle's allowable items does not match the set items of the vehicle allocation request 22. On the other hand, if the vehicle's allowable items match all of the set items of the vehicle allocation request 22, the vehicle allocation unit 172 associates the vehicle with the vehicle allocation request 22 as a pair candidate vehicle that satisfies the pairing conditions of the vehicle allocation request 22.

[0052] FIG. 9 is a first explanatory diagram illustrating the pair generation process. FIG. 10A is a second explanatory diagram illustrating the pair generation process. FIG. 10B is a third explanatory diagram illustrating the pair generation process. Here, it is assumed that all of the vehicles 32a, 42b, 32c, 32d, 32e, 42f, 32g, 32h, 42i, and 42j extracted by the vehicle allocation unit 172 are compatible with the setting items of the vehicle allocation requests 22a to 22c of users 2a to 2c. Furthermore, it is assumed that the extracted vehicles 32a, 32c, 32d, 32e, 32g, and 32h are compatible with the vehicle allocation category "taxi vehicles 32 only" included in the setting items of the vehicle allocation request 22d of user 2d, but that the extracted vehicles 42b, 42f, 42i, and 42j are not compatible.

[0053] 9, in response to the vehicle dispatch request 22a of the user 2a, the vehicle dispatch unit 172 extracts vehicles that satisfy the pairing conditions of the vehicle dispatch request 22a from the vehicles 32a, 42b, 32c, 32d, 32e, 42f, 32g, 32h, 42i, and 42j, and sets these vehicles as pair candidate vehicles 232a, 242b, 232c, 232d, 232e, 242f, 232g, 232h, 242i, and 242j. Here, the taxi vehicles 32 that satisfy the pairing conditions of the vehicle dispatch request 22 are set as pair candidate vehicles 232, and the NRS vehicle 42 that satisfies the pairing conditions of the vehicle dispatch request 22 is set as pair candidate vehicle 242. Then, the vehicle allocation unit 172 associates the pair candidate vehicles 232a, 242b, 232c, 232d, 232e, 242f, 232g, 232h, 242i, and 242j with the vehicle allocation request 22a of user 2a. Similarly, the vehicle allocation unit 172 associates the pair candidate vehicles 232a, 242b, 232c, 232d, 232e, 242f, 232g, 232h, 242i, and 242j with the vehicle allocation request 22b of user 2b. Furthermore, the vehicle allocation unit 172 associates the pair candidate vehicles 232a, 242b, 232c, 232d, 232e, 242f, 232g, 232h, 242i, and 242j with the vehicle allocation request 22c of user 2c.

[0054] In response to the vehicle dispatch request 22d of the user 2d, the vehicle dispatch unit 172 excludes the NRS vehicles 42b, 42f, 42i, and 42j that do not satisfy the pairing condition of the vehicle dispatch request 22d of the user 2d from the vehicles 32a, 42b, 32c, 32d, 32e, 32g, and 32h, and extracts the taxi vehicles 32a, 32c, 32d, 32e, 32g, and 32h that satisfy the pairing condition of the vehicle dispatch request 22d of the user 2d, and sets these vehicles as pair candidate vehicles 232a, 232c, 232d, 232e, 232g, and 232h. The vehicle dispatch unit 172 then associates the pair candidate vehicles 232a, 232c, 232d, 232e, 232g, and 232h with the vehicle dispatch request 22d of the user 2d. In this way, as shown in FIG. 10A, one or more pair candidate vehicles are associated with each of the vehicle allocation requests 22a to 22d.

[0055] Here, the vehicle dispatch unit 172 determines whether the vehicle is suitable for all the setting items of the vehicle dispatch request 22. However, this is not the only case, and if the vehicle dispatch unit 172 has already determined the suitability of some of the setting items, such as the desired vehicle dispatch or the sales office, the vehicle dispatch unit 172 may omit determining the suitability of those setting items. In this way, the processing load on the vehicle dispatch management server 60 can be reduced.

[0056] Next, the vehicle allocation unit 172 estimates the estimated arrival time of the associated pair candidate vehicle at the boarding location for each of the vehicle allocation requests 22a to 22d, and associates the estimated arrival time with each of the pair candidate vehicles. Since the positional relationship between the user 2 who made the vehicle allocation request 22 and the vehicle differs for each vehicle allocation request 22, the estimated arrival time for each vehicle allocation request 22 will differ even for the same pair candidate vehicle.

[0057] Next, the vehicle dispatch unit 172 sets priorities for the pair candidate vehicles associated with each vehicle dispatch request 22. Here, the priority indicates the order in which the vehicle should be assigned as a vehicle to be dispatched. When setting the priorities, the vehicle dispatch unit 172 recalculates the estimated arrival time at the boarding location. At this time, the shorter the recalculated estimated arrival time, the higher the priority. The recalculated estimated arrival time may be calculated by dividing the Euclidean distance by a predetermined speed, as in the case of the extraction conditions. Alternatively, the recalculated estimated arrival time may be calculated by using a travel time that takes into account the route the vehicle will take to arrive at the boarding location. Furthermore, the vehicle dispatch unit 172 may derive the travel time by taking into account, in addition to the route, the vehicle's current traveling direction at the time of vehicle extraction, the stop time at traffic lights along the route, and the like. Therefore, the vehicle dispatch unit 172 can set priorities using estimated arrival times that are equivalent to or more accurate than the estimated arrival times based on the Euclidean distance used by the vehicle dispatch unit 172 as an extraction condition.

[0058] For example, as shown in Figures 10A and 10B, the vehicle dispatch unit 172 rearranges the pair candidate vehicles 232a, 242b, 232c, 232d, 232e, 242f, 232g, 232h, 242i, and 242j associated with the vehicle dispatch request 22a into pair candidate vehicles 242b, 232d, 232c, 232e, 232a, 242f, 242i, 232h, 232g, and 242j in order of shortest recalculated estimated arrival time. Similarly, the vehicle dispatch unit 172 rearranges the pair candidate vehicles 232a, 242b, 232c, 232d, 232e, 242f, 232g, 232h, 242i, and 242j associated with the vehicle dispatch request 22b into pair candidate vehicles 242i, 232h, 242f, 232e, 232g, 232d, 232a, 242b, 242j, and 232c in order of shortest recalculated estimated arrival time. Furthermore, the vehicle allocation unit 172 rearranges the pair candidate vehicles 232a, 242b, 232c, 232d, 232e, 242f, 232g, 232h, 242i, and 242j associated with the vehicle allocation request 22c into pair candidate vehicles 242i, 232e, 232d, 242f, 232h, 232g, 232c, 242b, 242j, and 232a in order of shortest recalculated estimated arrival times. Furthermore, the vehicle allocation unit 172 rearranges the pair candidate vehicles 232a, 232c, 232d, 232e, 232g, and 232h associated with the vehicle allocation request 22d into pair candidate vehicles 232d, 232e, 232h, 232c, 232g, and 232a in order of shortest recalculated estimated arrival times.

[0059] 10B, one or more pair candidate vehicles are prioritized for each of the vehicle allocation requests 22a to 22d, and one or more combinations of vehicle allocation requests 22 and pair candidate vehicles are generated. Here, it can be seen that the priority of the pair candidate vehicles corresponding to each of the vehicle allocation requests 22a to 22d differs depending on the positional relationship between the users 2a to 2d and the pair candidate vehicles.

[0060] 10B, one or more pair candidate vehicles are associated with each of the vehicle dispatch requests 22a to 22d in a prioritized order, i.e., in the order of shortest expected arrival time at the boarding location. Therefore, the vehicle dispatch management server 60 can assign a vehicle with the shortest expected arrival time at the boarding location by extracting pair candidate vehicles in the order of highest priority for each of the vehicle dispatch requests 22a to 22d.

[0061] Furthermore, here, all vehicles available for dispatch are associated with each of the dispatch requests 22a to 22d, and a priority order is set. This is because there are cases where a vehicle selected as a dispatch target vehicle cannot accept the dispatch request. For example, suppose a vehicle is cruising, accepting a ride request from a user 2 it has spotted along the driving route, and simultaneously receiving a ride request from a user 2 nearby the driving route at the same time as a dispatch request 22 from a user 2a to 2d. In this case, the vehicle will not be able to accept the dispatch request 22 because it will be giving a ride to the nearby user 2. Therefore, even if a vehicle selected as a dispatch target vehicle cannot accept the dispatch request for some reason, the dispatch management server 60 can efficiently assign a vehicle with a short estimated time of arrival at the boarding location to each of the dispatch requests 22a to 22d by extracting a pair candidate vehicle with the next highest priority order.

[0062] However, as shown by the dashed line in Fig. 10B, among vehicle allocation requests 22a to 22d, there may be cases where the pair candidate vehicles with the highest priority overlap in vehicle allocation requests 22b and 22c. In this case, vehicle allocation management server 60 will not be able to appropriately assign pair candidate vehicles as vehicles to be allocated to vehicle allocation requests 22b and 22c. Therefore, vehicle allocation unit 172 matches vehicle allocation requests 22 with pair candidate vehicles.

[0063] (Matching process S6) The vehicle allocation unit 172 matches the vehicle allocation requests 22 with the pair candidate vehicles for a plurality of combinations obtained by multiplying the vehicle allocation requests 22 and the pair candidate vehicles associated in the pair generation process S5. In this matching process, the vehicle allocation requests 22 are matched with the pair candidate vehicles so that one pair candidate vehicle with the highest priority among the at least one pair candidate vehicle associated with each vehicle allocation request 22 does not overlap with at least one pair candidate vehicle associated with another vehicle allocation request 22. For example, the vehicle allocation unit 172 exclusively matches, for each of the vehicle allocation requests 22a to 22d, the pair candidate vehicle that has the shortest average estimated arrival time at the boarding location.

[0064] FIG. 11A is a first explanatory diagram illustrating the matching process, FIG. 11B is a second explanatory diagram illustrating the matching process, and FIG. 11C is a third explanatory diagram illustrating the matching process. As shown in FIG. 11A, one or more pair candidate vehicles are associated with each of vehicle allocation requests 22a to 22d, with priority assigned. Here, vehicle allocation unit 172 attempts to extract the pair candidate vehicle with the highest priority for each of vehicle allocation requests 22a to 22d as the vehicle to be allocated. In other words, by extracting pair candidate vehicle 242b for vehicle allocation request 22a, pair candidate vehicle 242i for vehicle allocation request 22b, pair candidate vehicle 242i for vehicle allocation request 22c, and pair candidate vehicle 232d for vehicle allocation request 22d, vehicle allocation unit 172 can allocate a vehicle with the shortest expected arrival time at the boarding location to each of vehicle allocation requests 22a to 22d.

[0065] Here, the pair candidate vehicle 242b of the vehicle allocation request 22a does not overlap with the pair candidate vehicles 242i and 232d with the highest priority in the other vehicle allocation requests 22b, 22c, and 22d. Therefore, the vehicle allocation unit 172 may determine the pair candidate vehicle 242b of the vehicle allocation request 22a as the vehicle to be allocated. Furthermore, the pair candidate vehicle 232d of the vehicle allocation request 22d does not overlap with the pair candidate vehicles 242b and 242i with the highest priority in the other vehicle allocation requests 22a, 22b, and 22c. Therefore, the vehicle allocation unit 172 may determine the pair candidate vehicle 232d of the vehicle allocation request 22d as the vehicle to be allocated. However, the pair candidate vehicles 242i with the highest priority in the vehicle allocation requests 22b and 22c overlap. Even if the same pair candidate vehicle 242i is simultaneously assigned as a vehicle to be allocated to multiple vehicle allocation requests 22b and 22c, the pair candidate vehicle 242i (NRS vehicle 42i) cannot accept both vehicle allocation requests 22b and 22c at the same time.

[0066] Therefore, the vehicle allocation unit 172 performs an exclusion process to change the combinations of the vehicle allocation requests 22b, 22c and the pair candidate vehicles so that the pair candidate vehicles with the highest priority in each of the vehicle allocation requests 22b, 22c are different. Specifically, the vehicle allocation unit 172 assigns the pair candidate vehicle 242i to one of the vehicle allocation requests 22b, 22c in which the pair candidate vehicle 242i overlaps. Then, for the other vehicle allocation requests 22, the vehicle allocation unit 172 assigns pair candidate vehicles with lower priorities until there are no overlaps between the other vehicle allocation requests 22 and the pair candidate vehicles.

[0067] For example, as shown in FIG. 11B, the vehicle allocation unit 172 assigns pair candidate vehicle 242i to vehicle allocation request 22b, and assigns pair candidate vehicle 232e, which has the next highest priority after pair candidate vehicle 242i, to vehicle allocation request 22c. In this manner, the combinations in which pair candidate vehicles 242b, 242i, 232e, and 232d are assigned to vehicle allocation requests 22a to 22d are defined as pair group A. Similarly, as shown in FIG. 11C, the vehicle allocation unit 172 assigns 242i to vehicle allocation request 22c, and assigns pair candidate vehicle 232h, which has the next highest priority after pair candidate vehicle 242i, to vehicle allocation request 22b. In this manner, the combinations in which pair candidate vehicles 242b, 232h, 242i, and 232d are assigned to vehicle allocation requests 22a to 22d are defined as pair group B. In this manner, it is possible to avoid the highest priority pair candidate vehicle being assigned to multiple vehicle allocation requests 22 in each of pair groups A and B.

[0068] FIG. 12 is an explanatory diagram showing the results of matching by the vehicle allocation unit 172. For example, for each of pair groups A and B, the vehicle allocation unit 172 adds up the estimated arrival times of vehicles at the boarding location for all combinations of the vehicle allocation request 22 and the pair candidate vehicles. Then, the vehicle allocation unit 172 identifies the pair group with the shorter total estimated arrival time as a matching result for the combination of the vehicle allocation request 22 and the vehicle to be allocated. For example, suppose that the total estimated arrival times for pair groups A and B are such that pair group B is smaller than pair group A. In this case, the vehicle allocation unit 172 identifies pair group B with the shorter total estimated arrival time as the matching result. When a pair group (for example, pair group B) is identified as a matching result by the matching of the vehicle allocation unit 172, the combination of pair group B is reflected as shown in Figure 12, and pair candidate vehicle 242b becomes the vehicle to be allocated for vehicle allocation request 22a, pair candidate vehicle 232h becomes the vehicle to be allocated for vehicle allocation request 22b, pair candidate vehicle 242i becomes the vehicle to be allocated for vehicle allocation request 22c, and pair candidate vehicle 232d becomes the vehicle to be allocated for vehicle allocation request 22d.

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

[0070] Note that the matching algorithm between the vehicle allocation requests 22 and the pair candidate vehicles is not limited to the above case, and various matching algorithms can be applied as long as at least one pair candidate vehicle in each vehicle allocation request 22, particularly the pair candidate vehicle with the highest priority, does not overlap with the pair candidate vehicle with the highest priority in another vehicle allocation request 22. For example, the vehicle allocation unit 172 estimates the estimated arrival time of the vehicle at the boarding location for all combinations of the vehicle allocation request 22 and the pair candidate vehicle for each of multiple pair groups A and B. Then, the vehicle allocation unit 172 may identify as the matching result the pair group A or B in which the combination of the vehicle allocation request 22 and the pair candidate vehicle with the longest estimated arrival time is the shortest. Furthermore, the vehicle allocation unit 172 may add up the distances (travel distances) to the boarding location for all combinations of the vehicle allocation request 22 and the pair candidate vehicle for each of the pair groups A and B. In this case, the vehicle allocation unit 172 identifies as the matching result the pair group with the shortest total distance. It should be noted that an existing matching algorithm may be used as the matching algorithm between the vehicle allocation request 22 and the pair candidate vehicle.

[0071] Note that the vehicle allocation unit 172 maintains the priorities of the pair candidate vehicles associated with the vehicle allocation requests 22a to 22d even after pair group B is identified as the matching result. This is because, as described above, if a vehicle selected as a vehicle to be allocated cannot accept the vehicle allocation request for some reason, the pair candidate vehicle with the next highest priority is extracted as a vehicle to be allocated.

[0072] FIG. 13A is a first explanatory diagram illustrating the processing of the vehicle allocation unit, and FIG. 13B is a second explanatory diagram illustrating the processing of the vehicle allocation unit. As described above, once a pair group is identified and the pair candidate vehicle with the highest priority is exclusively determined for each of the vehicle allocation requests 22a to 22d, the pair candidate vehicle is deleted from the pair candidate vehicles associated with the other vehicle allocation requests 22. This is because a pair candidate vehicle only has one opportunity to become a vehicle to be allocated in one matching process. That is, once the vehicle terminal control unit 174 notifies the pair candidate vehicle of information indicating that the pair candidate vehicle has become a vehicle to be allocated, the vehicle terminal control unit 174 does not subsequently notify the pair candidate vehicle of information indicating that the pair candidate vehicle has become a vehicle to be allocated for another vehicle allocation request 22, regardless of whether the vehicle allocation request 22 is accepted. Therefore, a pair candidate vehicle that has already become a vehicle to be allocated for a vehicle allocation request 22 will not become a vehicle to be allocated for another vehicle allocation request 22. In this way, for example, pair candidate vehicles 242b, 232h, 242i, and 232d matched with vehicle allocation requests 22a to 22d are deleted from pair candidate vehicles associated with other vehicle allocation requests 22, as shown in Fig. 13A. In this way, new combinations are generated in which pair candidate vehicles are associated with each of vehicle allocation requests 22a to 22d in descending order of priority, as shown in Fig. 13B.

[0073] Here, an example has been described in which matching is performed so that the pair candidate vehicles with the highest priority do not overlap between vehicle allocation requests 22. However, if the pair candidate vehicles with the second highest priority overlap between vehicle allocation requests 22, matching may not be performed for those pair candidate vehicles. This is for the following reason. The pair candidate vehicle with the highest priority is assigned to the vehicle allocation request 22 as the vehicle to be allocated, and the pair candidate vehicle with the second highest priority is merely a backup in case the pair candidate vehicle with the highest priority does not accept the vehicle allocation request 22. Nevertheless, if the pair candidate vehicle with the second highest priority is exclusively associated with the vehicle allocation request 22, there may be cases in which vehicle allocation is not efficient.

[0074] 13B, the pair candidate vehicle with the next highest priority is pair candidate vehicle 232e. Suppose that vehicle allocation unit 172 matches vehicle allocation requests 22c and 22d with pair candidate vehicle 232e with the next highest priority, and, for example, sets pair candidate vehicle 232e as the pair candidate vehicle with the next highest priority for vehicle allocation request 22c, and changes the pair candidate vehicle with the next highest priority for vehicle allocation request 22d from pair candidate vehicle 232e to pair candidate vehicle 232c. Then, the pair candidate vehicles for vehicle allocation request 22c become {242i, 232e, 242f, ...} in descending order of priority, and the pair candidate vehicles for vehicle allocation request 22d become {232d, 232c, 232g, ...} in descending order of priority after pair candidate vehicle 232e is deleted.

[0075] Here, for example, suppose that pair candidate vehicle 242i, which has the highest priority, accepts the vehicle allocation request for vehicle allocation request 22c, and pair candidate vehicle 232d, which has the highest priority, does not accept the vehicle allocation request for vehicle allocation request 22d. In this case, pair candidate vehicle 232e, which has the next highest priority, will not be the vehicle to be allocated for vehicle allocation request 22c, and pair candidate vehicle 232c, which has the next highest priority, will be the vehicle to be allocated for vehicle allocation request 22d. However, pair candidate vehicle 232e, which has a higher priority than pair candidate vehicle 232c, should actually be the vehicle to be allocated for vehicle allocation request 22d.

[0076] Therefore, the vehicle allocation unit 172 does not perform matching for pair candidate vehicles other than the pair candidate vehicle with the highest priority, and allows overlapping pair candidate vehicles between vehicle allocation requests 22. In this way, even if the pair candidate vehicle with the highest priority does not accept the vehicle allocation request 22, it is possible to appropriately allocate the pair candidate vehicle with the next highest priority.

[0077] Note that if matching is not performed for pair candidate vehicles other than the pair candidate vehicle with the highest priority, it is possible that multiple pair candidate vehicles will become vehicles to be allocated for vehicle allocation request 22. For example, in the example of Figure 13B, pair candidate vehicle 242i matched with vehicle allocation request 22c may not accept vehicle allocation request 22c, and pair candidate vehicle 232d matched with vehicle allocation request 22d may also not accept vehicle allocation request 22d. In this case, the pair candidate vehicles with the next highest priority in vehicle allocation requests 22c and 22d are both pair candidate vehicle 232e.

[0078] However, it is unlikely or impossible that the timing when pair candidate vehicle 242i refuses to accept vehicle allocation request 22c and the timing when pair candidate vehicle 232d refuses to accept vehicle allocation request 22d will be exactly the same. Here, the vehicle allocation management server 60 designates the pair candidate vehicle with the next highest priority as the vehicle to be allocated for the vehicle allocation request 22 whose acceptance was previously refused, and deletes that pair candidate vehicle from the pair candidate vehicles associated with other vehicle allocation requests 22. For example, first, assume that pair candidate vehicle 242i matched with vehicle allocation request 22c does not accept vehicle allocation request 22c, and then pair candidate vehicle 232d matched with vehicle allocation request 22d also does not accept vehicle allocation request 22d. In this case, the vehicle allocation management server 60 designates pair candidate vehicle 232e as the vehicle to be allocated for vehicle allocation request 22c whose acceptance was previously refused, and deletes pair candidate vehicle 232e from the pair candidate vehicles associated with vehicle allocation request 22d. In this way, for example, the pair candidate vehicle 232e will not be the vehicle to be allocated for the vehicle allocation request 22d, so that the pair candidate vehicles will not overlap and become the vehicle to be allocated for all vehicle allocation requests 22.

[0079] (Vehicle dispatch notification process S7) The vehicle terminal control unit 174 of the vehicle dispatch management server 60 controls the vehicle application of the vehicle terminal and performs vehicle dispatch management through the vehicle application. The vehicle terminal control unit 174 notifies the vehicle terminal installed in the vehicle that has become the dispatch target vehicle for the dispatch request 22 of information indicating that the vehicle has become the dispatch target vehicle (dispatch target notification). This dispatch target notification corresponds to a prompt to the driver of the dispatch target vehicle whether or not to accept the dispatch request 22. In this way, the driver of the vehicle recognizes that his or her vehicle has become the dispatch target vehicle, and can consider whether or not to accept the dispatch request 22.

[0080] (Acceptance response processing S8) When the vehicle dispatch response unit of the vehicle terminal arranged in the vehicle receives information indicating that the vehicle has become a vehicle to be dispatched from the vehicle terminal control unit 174, the vehicle dispatch response unit notifies the driver of this fact, for example, via a vehicle display device. When notifying the information, the vehicle terminal may also display information about the vehicle dispatch request 22 (for example, the boarding location, user information about user 2) on the vehicle display device. Note that if a drop-off location has been input by user 2, for example, after the vehicle arrives at user 2's boarding location, the vehicle terminal may display the information about the drop-off location on the vehicle display device as information about the vehicle dispatch request 22. When accepting the vehicle dispatch request 22, the driver accepts the vehicle dispatch request 22 via the vehicle input device of the vehicle terminal, for example, by tapping a position corresponding to a "request acceptance" button displayed on the vehicle display device. The vehicle dispatch response unit transmits information about the acceptance of the vehicle dispatch request 22 (acceptance response), including the acceptance of the vehicle dispatch request 22, to the vehicle dispatch management server 60.

[0081] If the driver cannot accept the vehicle allocation request 22 for some reason, the driver taps the "request reject" button displayed on the vehicle input device of the vehicle terminal to reject the vehicle allocation request 22, or does not tap the position corresponding to "request accept." The vehicle terminal control unit 174 waits for a predetermined time (e.g., 10 seconds) from the time the vehicle allocation target notification is sent, and if it does not receive information regarding acceptance of the vehicle allocation request 22 (acceptance response) from the vehicle terminal during the waiting time, it determines that the driver of the vehicle to be allocated has not accepted the vehicle allocation request 22. In this case, the vehicle allocation unit 172 determines that the vehicle with the second highest priority among the vehicles associated with the vehicle allocation request 22 in the matching process S6 is the new vehicle to be allocated. Next, the vehicle terminal control unit 174 notifies the vehicle terminal of the other vehicle that has become the new vehicle to be allocated of information indicating that the vehicle has become the vehicle to be allocated (vehicle allocation target notification).

[0082] (Vehicle dispatch completion notification process S9) When the vehicle terminal control unit 174 receives information (acceptance response) regarding acceptance of the vehicle allocation request 22 from the vehicle terminal, it confirms the allocation of the vehicle to be allocated in response to the vehicle allocation request 22 and transmits a vehicle allocation completion notification indicating that the vehicle allocation has been confirmed to the vehicle terminal. At this time, information regarding the vehicle allocation request 22, such as the boarding location and the route to the boarding location, is displayed on the vehicle display device of the vehicle terminal. With this configuration, the driver of the vehicle can grasp the information regarding the vehicle allocation request 22, drive an appropriate route toward the boarding location, and quickly find the user 2. Note that if the vehicle to be allocated is a vehicle with requirements (an NRS vehicle 42 or a specified vehicle), the vehicle terminal control unit 174 may display other information, such as the drop-off location in addition to the boarding location, as information regarding the vehicle allocation request 22 on the vehicle display device of the vehicle terminal of such a vehicle.

[0083] (User vehicle dispatch completion notification process S10) When the dispatch of the vehicle to be dispatched in response to the vehicle dispatch request 22 is confirmed, the user terminal control unit 170 transmits a vehicle dispatch completion notification indicating that the vehicle dispatch has been confirmed to the user terminal 20. At this time, the display device 124 of the user terminal 20 displays the location of the vehicle to be dispatched, the estimated arrival time, etc. In this way, the user 2 can appropriately board the vehicle at the boarding location. Note that if the vehicle dispatch unit 172 is unable to assign a vehicle to be dispatched in response to the vehicle dispatch request 22, the vehicle dispatch request 22 temporarily enters a vehicle dispatch failed (vehicle dispatch impossible) state. In this case, the display device 124 of the user terminal 20 displays information indicating that the vehicle dispatch was not possible and information indicating that the vehicle dispatch request 22 can be executed again. The user 2 will execute the vehicle dispatch request 22 again based on this information.

[0084] In the vehicle dispatch management method using the vehicle dispatch management system 1 described above, information on a plurality of vehicle dispatch requests 22 and a plurality of vehicles is accumulated and matched at once. In this case, by shortening the accumulation time, the frequency of execution of the vehicle dispatch matching process (S6) can be increased, thereby enabling efficient vehicle dispatch while maintaining convenience for the user 2.

[0085] (Vehicle work management) Incidentally, whether it is a taxi vehicle 32 or a special-duty vehicle, there are multiple possible working styles, such as daytime work, nighttime work, and alternate-day work. There are also multiple possible salary styles, such as hourly wage, fixed salary, fixed salary plus commission, and full commission. For example, if a driver is not employed full-time and rents a taxi vehicle 32 from a taxi company to transport users 2, and is paid by the hour, the driver's start and end times may be fixed. In this case, if the driver's working style has a fixed end time, the driver will want to finish work by that time. However, if the driver receives a dispatch request with a distant drop-off location near the end of his or her shift, it will be difficult for the driver to finish work at the end of his or her shift. In this case, the dispatch management server 60 dispatches vehicles taking into account the end time of the shift, enabling efficient dispatch within working hours.

[0086] Specifically, when the vehicle dispatch unit 172 of the vehicle dispatch management server 60 receives a vehicle dispatch request 22 from the user terminal 20, it derives a mileage value based on the boarding location and disembarking location added to the vehicle dispatch request 22. The mileage value is a value accumulated as the vehicle travels, and is expressed, for example, as (estimated arrival distance + estimated boarding distance) or (estimated arrival time + estimated boarding time). The estimated arrival distance is the Euclidean distance from the current location of the vehicle to the boarding location, which is derived in advance. The estimated arrival distance may be a distance that takes into account the route the vehicle will take to arrive at the boarding location. The estimated arrival distance may also be a distance that takes into account the current traveling direction of the vehicle, etc., in addition to the route. The estimated boarding distance is the Euclidean distance from the boarding location to the disembarking location, which is derived in advance. The estimated arrival distance may also be a distance that takes into account the route from the boarding location to the disembarking location. The estimated boarding distance may also be a distance that takes into account the current traveling direction of the vehicle, etc., in addition to the route. The estimated arrival time is a value calculated in advance by dividing the estimated arrival distance by a predetermined speed (for example, the average speed when the vehicle is operating). The estimated ride time is a value calculated in advance by dividing the estimated ride distance by a predetermined speed (for example, the average speed when the vehicle is operating). Note that the estimated arrival time and estimated ride time may take into account the time spent stopping at traffic lights along the route. In this way, in this embodiment, the distance or time from the current position of the vehicle to the drop-off location via the pick-up location is calculated as the travel value.

[0087] In the following, for the sake of convenience, the travel value will be described as (estimated arrival time + estimated boarding time). However, the present invention is not limited to this example, and it goes without saying that the travel value can be applied by replacing (estimated arrival time + estimated boarding time) with (estimated arrival distance + estimated boarding distance).

[0088] Furthermore, in this example, the mileage value is calculated by accumulating the distance or time from the current location of the vehicle to the drop-off location via the pick-up location. However, this is not limiting, and the distance or time from the drop-off location to the taxi business (or home) may also be added to the mileage value. In this case, the mileage value is expressed, for example, as (estimated arrival distance + estimated ride distance + estimated return distance) or (estimated arrival time + estimated ride time + estimated return time). The estimated return distance is a Euclidean distance from the drop-off location to the taxi business or home that is calculated in advance. Note that the estimated return distance may be a distance that takes into account the route from the drop-off location to the taxi business or home. The estimated return distance may also be a distance that takes into account the current traveling direction of the vehicle in addition to the route. The estimated return time is a value calculated in advance by dividing the estimated return distance by a predetermined speed (for example, the average speed when the vehicle is operating). Note that the estimated return time may also take into account the time spent stopping at traffic lights along the route.

[0089] In addition, here, the distance or time from the current location of the vehicle to the drop-off location via the boarding location is integrated as the mileage value, but this is not limited to this example. In cases where the boarding location of user 2 is limited within a predetermined range at an event, major facility, etc., and the vehicle waiting location (vehicle location) is also limited within a predetermined range, such as at a taxi agency, a predetermined distance or time can be applied as the estimated arrival distance or estimated arrival time. In this case, the vehicle dispatch unit 172 does not need to derive the estimated arrival distance or estimated arrival time for each vehicle, and can simply derive the estimated boarding distance and estimated boarding time from the boarding location and the drop-off location and use them as the mileage value common to all vehicles, thereby reducing the processing load of the vehicle dispatch unit 172.

[0090] Next, the dispatch unit 172 derives the working conditions for each vehicle. The working conditions are expressed as thresholds for comparing mileage values, and indicate, for example, whether the remaining work time is less than or equal to a predetermined remaining work time or a predetermined remaining work distance. The remaining work time is the time (remaining time) until the end of the vehicle's driver's work shift. Therefore, for example, if the driver's work start time is 7:00 and the work end time is 16:00, and the current time is 15:30, the remaining work time is 30 minutes (16:00-15:30). The remaining work distance is the mileage equivalent of the remaining work time, i.e., the value obtained by multiplying the remaining work time by a predetermined speed (e.g., the average speed when the vehicle is operating); for example, in the above example, it is 20 km ((40 km / h) × 0.5 h). For convenience of explanation, the following description will use the remaining work time as the working condition. However, this is not a limitation, and it goes without saying that the working condition of being equal to or less than the remaining working hours can be replaced with being equal to or less than the remaining working distance. Also, although the working conditions are explained here as being equal to or less than the remaining working hours or the remaining working distance, the working conditions may be replaced with being less than the remaining working hours or the remaining working distance.

[0091] In addition, if the working style of the vehicle driver is a working style with no fixed end time, such as a fixed salary, a fixed salary plus commission system, or a full commission system, and the vehicle is a vehicle that can be dispatched by extending working hours even if the drop-off location is far away, working conditions are not set (working conditions are not attached). Therefore, a driver with a working style with no fixed end time, such as taxi driver 3, does not have a limit on working hours. In this way, a vehicle with no working conditions, such as taxi vehicle 32, can be considered to always satisfy the working conditions. Here, for example, an absolutely large value or ∞ (infinity) is applied as the remaining working time for a vehicle with no working conditions. In this way, a vehicle (vehicle with no working conditions) driven by a driver with a working style with no fixed end time will always satisfy the working conditions regardless of the mileage. In the following explanation, vehicles that satisfy the working conditions include not only vehicles that satisfy the working conditions assuming that working conditions are attached, but also vehicles that do not have working conditions attached in the first place (vehicles that always satisfy the working conditions).

[0092] Furthermore, if the vehicle driver's work style allows for the remaining working time to be extended beyond the work end time, the remaining working time may be calculated by adding the time until the vehicle driver's work end time (remaining time) to the time allowed for extension (for example, 5 minutes). Here, work styles that allow for the remaining working time to be extended beyond the work end time include work styles in which the work end time is considered to be the end even if business ends a few minutes (for example, 5 minutes) after the work end time, and work styles in which the working conditions state that business may end a few minutes after the work end time. Note that the allowable extension time is not limited to 5 minutes and can be determined arbitrarily.

[0093] 14A is a first explanatory diagram for explaining the processing of the vehicle allocation unit 172, and FIG. 14B is a second explanatory diagram for explaining the processing of the vehicle allocation unit 172. If the derived estimated arrival time + estimated boarding time satisfies the work conditions, the vehicle allocation unit 172 allocates the vehicle to the vehicle allocation request 22. For example, if the estimated arrival time is 5 minutes, the estimated boarding time is 15 minutes, and the remaining work time is 30 minutes, as shown in FIG. 14A, (estimated arrival time + estimated boarding time) ≦ remaining work time, and therefore the vehicle allocation unit 172 allocates the vehicle to the vehicle allocation request 22. On the other hand, if the derived estimated arrival time + estimated boarding time does not satisfy the work conditions, the vehicle allocation unit 172 does not allocate the vehicle to the vehicle allocation request 22. For example, if the estimated arrival time is 10 minutes, the estimated boarding time is 30 minutes, and the remaining working time is 30 minutes, then (estimated arrival time + estimated boarding time) > remaining working time, as shown in Figure 14B, and therefore the vehicle dispatch unit 172 does not assign the vehicle to the vehicle dispatch request 22.

[0094] Specifically, in the pair generation process S5, the vehicle allocation unit 172 extracts, for each vehicle allocation request 22, at least one pair candidate vehicle that satisfies a predetermined pair condition from the vehicles extracted in the vehicle extraction process S4 and whose (estimated arrival time + estimated boarding time) is less than or equal to the remaining working time, and associates the extracted pair candidate vehicle with the vehicle allocation request 22. Therefore, if (estimated arrival time + estimated boarding time) is less than or equal to the remaining working time, the vehicle will be included in the pair candidate vehicles, and the vehicle allocation unit 172 can allocate the vehicle to the vehicle allocation request 22. On the other hand, if (estimated arrival time + estimated boarding time) is longer than the remaining working time, the vehicle will not be included in the pair candidate vehicles, and the vehicle allocation unit 172 will not allocate the vehicle to the vehicle allocation request 22.

[0095] With this configuration, when the driver's work end time is determined, the vehicle dispatch unit 172 will only allocate the vehicle to a vehicle dispatch request 22 that is calculated to be able to transport the user 2 within the working hours based on predicted values ​​such as the estimated arrival time and estimated boarding time, so the vehicle driver can finish work within the working hours. This allows for efficient vehicle dispatch within the working hours.

[0096] Furthermore, when there are multiple vehicles, the vehicle allocation unit 172 derives the (estimated arrival time + estimated boarding time) and working conditions for each vehicle, and appropriately allocates a vehicle to the vehicle allocation request 22 according to the relationship. The vehicle allocation unit 172 allocates any vehicle whose derived (estimated arrival time + estimated boarding time) satisfies the working conditions to the vehicle allocation request 22. On the other hand, the vehicle allocation unit 172 does not allocate any vehicle whose derived (estimated arrival time + estimated boarding time) does not satisfy the working conditions to the vehicle allocation request 22.

[0097] Specifically, in the pair generation process S5, the vehicle allocation unit 172 extracts, for each vehicle allocation request 22, at least one pair candidate vehicle that satisfies predetermined pair conditions from the vehicles extracted in the vehicle extraction process S4 and whose (estimated arrival time + estimated boarding time) is less than or equal to the remaining working time, and associates the extracted pair candidate vehicle with the vehicle allocation request 22. Therefore, if (estimated arrival time + estimated boarding time) is less than or equal to the remaining working time, the vehicle will be included in the pair candidate vehicles, and therefore the vehicle may become a vehicle to be allocated. On the other hand, if (estimated arrival time + estimated boarding time) is longer than the remaining working time, the vehicle will not be included in the pair candidate vehicles, and therefore the vehicle will not become a vehicle to be allocated.

[0098] With this configuration, when the driver's work end time is determined, the vehicle dispatch unit 172 only assigns the vehicle to a vehicle dispatch request 22 that is calculated to be able to transport the user 2 within the work hours based on predicted values ​​such as the estimated arrival time and estimated boarding time, so the vehicle driver can finish work within the work hours. This allows for efficient vehicle dispatch within work hours. Furthermore, by avoiding dispatch to vehicles with limited remaining work time due to an hourly wage or other work style, and preferentially dispatching vehicles to vehicles with more time available due to a commission-based or other work style, efficient vehicle dispatch is also possible between vehicles.

[0099] In the above example, the vehicle dispatch unit 172 does not assign a vehicle to the vehicle dispatch request 22 if (estimated arrival time + estimated boarding time) is longer than the remaining work time. However, this is not limited to such a case. If (estimated arrival time + estimated boarding time) is longer than the remaining work time, the vehicle dispatch unit 172 may assign the vehicle with a lower priority than other vehicles whose (estimated arrival time + estimated boarding time) is equal to or less than the remaining work time. For example, if the derived (estimated arrival time + estimated boarding time) is equal to or less than the remaining work time, the vehicle dispatch unit 172 assigns both the vehicle and other vehicles whose (estimated arrival time + estimated boarding time) is equal to or less than the remaining work time to the vehicle dispatch request 22 without prioritizing them. On the other hand, if (estimated arrival time + estimated boarding time) is longer than the remaining work time, the vehicle dispatch unit 172 assigns other vehicles whose (estimated arrival time + estimated boarding time) is equal to or less than the remaining work time to the vehicle dispatch request 22 with priority over the vehicle.

[0100] Specifically, in the pair generation process S5, the vehicle allocation unit 172 matches the vehicle allocation requests 22 with vehicles such that the vehicle with the highest priority among at least one vehicle associated with each vehicle allocation request 22 does not overlap with at least one vehicle associated with another vehicle allocation request 22. At this time, if (estimated arrival time + estimated boarding time) is longer than the remaining time at work, the vehicle allocation unit 172 changes the priority of the vehicle and allocates other vehicles whose (estimated arrival time + estimated boarding time) is less than the remaining time at work over the vehicle. For example, assume that the vehicle allocation unit 172 determines the priority of vehicles for the vehicle allocation request 22 as shown in FIG. 10B. Here, if (estimated arrival time + estimated boarding time) is longer than the remaining time at work, the vehicle allocation unit 172 does not allocate the vehicle with a high priority. For example, in the vehicle allocation request 22a in FIG. 10B, the NRS vehicle 42b (pair candidate vehicle 242b) is associated with the highest priority. If the (estimated arrival time + estimated ride time) for the NRS vehicle 42b is longer than the remaining shift time, the vehicle allocation unit 172 does not allocate the NRS vehicle 42b (pair candidate vehicle 242b) to the highest priority. In this case, for example, in the vehicle allocation request 22a in FIG. 10B, the priorities of the NRS vehicle 42b (pair candidate vehicle 242b) and the taxi vehicle 32d (pair candidate vehicle 232d) are swapped, and the pair candidate vehicles 232d, 242b, 232c, 232e, 232a, 242f, 242i, 232h, 232g, and 242j are associated in descending order of priority. In the matching process S6, the vehicle allocation unit 172 allocates vehicles to the vehicle allocation request 22 based on the priorities of the pair candidate vehicles. Consequently, the taxi vehicle 32 is allocated to the vehicle allocation request 22 with priority over the NRS vehicle 42.

[0101] Here, an example has been described in which the vehicle dispatch unit 172 does not assign the vehicle to the highest priority if (estimated arrival time + estimated boarding time) is longer than the remaining time at work, but this is not a limitation. The vehicle may not be assigned to multiple priorities, from the highest priority, for example, the highest priority and the second highest priority. Also, here, an example has been described in which the vehicle dispatch unit 172 does not assign the vehicle to a high priority if (estimated arrival time + estimated boarding time) is longer than the remaining time at work, but this is not a limitation. The vehicle's priority may be relatively lowered by one or more levels. As a result, other vehicles whose (estimated arrival time + estimated boarding time) is less than the remaining time at work are assigned preferentially over vehicles whose (estimated arrival time + estimated boarding time) is longer than the remaining time at work.

[0102] With this configuration, when the driver's work end time is determined, the vehicle dispatching unit 172 can easily assign the vehicle to a vehicle dispatch request 22 that is calculated to be able to transport the user 2 within the work hours based on predicted values ​​such as the estimated arrival time and estimated boarding time, making it easier for the vehicle driver to finish work within the work hours. This makes it possible to efficiently dispatch vehicles within work hours. Furthermore, since vehicles are preferentially dispatched to vehicles with a commission-based work schedule or other working arrangement that have ample working hours rather than vehicles with limited remaining working hours due to an hourly wage or other working arrangement, efficient vehicle dispatching is also possible between vehicles.

[0103] In this way, the vehicle dispatch management system 1 comprises a user terminal 20 and a vehicle dispatch management device (e.g., a vehicle dispatch management server 60) capable of communicating with the user terminal 20 via a network 6, the user terminal 20 comprising one or more first processors, the vehicle dispatch management device comprising one or more second processors, the first processor transmitting a vehicle dispatch request 22 to the vehicle dispatch management device, with the boarding location and disembarking location added in accordance with input from the user 2, the second processor deriving a driving value (e.g., estimated arrival time + estimated boarding time) associated with the vehicle's travel based on the boarding location and disembarking location, deriving a working condition relating to the remaining working time in the vehicle (e.g., less than or equal to the remaining working time), and not allocating a vehicle to the vehicle dispatch request 22 if the driving value does not satisfy the working condition. With this configuration, when the driver's work end time is determined, the vehicle dispatch unit 172 will only allocate the vehicle to a vehicle dispatch request 22 that is calculated to be able to transport the user 2 within the working hours based on predicted values ​​such as the estimated arrival time and estimated boarding time, so the vehicle driver can finish work within the working hours. This allows for efficient vehicle dispatch within the working hours.

[0104] Furthermore, a vehicle dispatch management device (e.g., vehicle dispatch management server 60), which can communicate with user terminal 20 via network 6, includes one or more processors. The processor derives a mileage value (e.g., estimated arrival time + estimated boarding time) associated with the vehicle's travel based on the boarding and disembarking locations added to vehicle dispatch requests 22 received from user terminal 20, derives a work condition related to the vehicle's remaining work time (e.g., less than or equal to the remaining work time), and does not allocate a vehicle to vehicle dispatch request 22 if the mileage value does not satisfy the work condition. With this configuration, when the driver's work end time is determined, vehicle dispatch unit 172 only allocates the vehicle to vehicle dispatch requests 22 that are calculated to be able to transport user 2 within that work time based on predicted values ​​such as estimated arrival time and estimated boarding time. This allows the vehicle driver to finish work within their work hours. This enables efficient vehicle dispatch within work hours.

[0105] Furthermore, a vehicle dispatch management device (e.g., vehicle dispatch management server 60), which can communicate with user terminal 20 via network 6, includes one or more processors. The processor derives a mileage value (e.g., estimated arrival time + estimated ride time) associated with vehicle travel based on the boarding and disembarking locations attached to vehicle dispatch requests 22 received from user terminal 20, and derives work conditions (e.g., less than or equal to remaining work time) related to the remaining work time for each of the multiple vehicles. Vehicles whose mileage values ​​satisfy the work conditions can be assigned to vehicle dispatch requests 22, but vehicles whose mileage values ​​do not satisfy the work conditions cannot be assigned. With this configuration, when a driver's work end time is determined, the dispatch unit 172 only assigns vehicles to vehicle dispatch requests 22 that are calculated to be able to transport user 2 within that work time based on predicted values ​​such as estimated arrival time and estimated ride time. This allows the vehicle driver to finish work within their work hours. This enables efficient vehicle dispatch within work hours.

[0106] In addition, the processor may allocate vehicles whose mileage meets the work conditions (for example, less than or equal to the remaining working hours) and vehicles that do not have work conditions in response to the vehicle allocation request 22, but may not allocate vehicles whose mileage does not meet the work conditions. This configuration enables efficient vehicle allocation during working hours.

[0107] Furthermore, a vehicle dispatch management device (e.g., vehicle dispatch management server 60), which can communicate with user terminal 20 via network 6, includes one or more processors. The processor derives a mileage value (e.g., estimated arrival time + estimated ride time) associated with vehicle travel based on the boarding and disembarking locations attached to vehicle dispatch requests 22 received from user terminal 20, derives work conditions (e.g., less than or equal to remaining work time) related to the remaining work time for each of the multiple vehicles, and prioritizes vehicle dispatch requests 22 whose mileage values ​​satisfy the work conditions over vehicles whose mileage values ​​do not satisfy the work conditions. With this configuration, when a driver's work end time is determined, the dispatch unit 172 can more easily assign a vehicle to a vehicle dispatch request 22 that is calculated to be able to transport user 2 within the work hours with ample time to spare based on predicted values ​​such as estimated arrival time and estimated ride time, making it easier for the vehicle driver to finish work within the work hours. This enables efficient vehicle dispatch within work hours.

[0108] In addition, the processor may prioritize vehicles whose mileage meets the work condition (e.g., the remaining working hours or less) and vehicles that do not have work conditions over vehicles whose mileage does not meet the work condition in response to a vehicle dispatch request. This configuration enables efficient vehicle dispatch during working hours.

[0109] The mileage value may be the sum of the estimated distance to arrive at the boarding location and the estimated travel time from the boarding location to the disembarking location, and the working condition may be less than or equal to the remaining time of work.The mileage value may be the sum of the estimated distance to arrive at the boarding location and the estimated travel distance from the boarding location to the disembarking location, and the working condition may be less than or equal to the mileage equivalent of the remaining time of work.This configuration can appropriately support the vehicle driver's business during working hours.

[0110] In addition, in the vehicle dispatch management method, the computer derives a mileage value (e.g., estimated arrival time + estimated ride time) associated with the vehicle's travel based on the pick-up and drop-off locations attached to the vehicle dispatch request 22 received from the user terminal 20, derives a work condition related to the vehicle's remaining work time (e.g., less than or equal to the remaining work time), and does not allocate a vehicle to the vehicle dispatch request 22 if the mileage value does not satisfy the work condition. With this configuration, when the driver's work end time is determined, the vehicle dispatch unit 172 will only allocate the vehicle to a vehicle dispatch request 22 that is calculated to be able to transport the user 2 within that work time based on predicted values ​​such as the estimated arrival time and estimated ride time, allowing the vehicle driver to finish work within their work hours. This allows for efficient vehicle dispatch within work hours.

[0111] The program also causes the computer to derive a mileage value (e.g., estimated arrival time + estimated ride time) associated with the vehicle's travel based on the pick-up and drop-off locations added to the vehicle dispatch request 22 received from the user terminal 20, derive a work condition related to the remaining work time for the vehicle (e.g., less than or equal to the remaining work time), and not allocate a vehicle to the vehicle dispatch request 22 if the mileage value does not satisfy the work condition. With this configuration, when the driver's work end time is determined, the dispatch unit 172 will only allocate the vehicle to a vehicle dispatch request 22 that is calculated to be able to transport the user 2 within that work time based on predicted values ​​such as the estimated arrival time and estimated ride time, allowing the vehicle driver to finish work within their work hours. This allows for efficient vehicle dispatch within work hours.

[0112] While the preferred embodiments of the present invention have been described above with reference to the accompanying drawings, it goes without saying that the present invention is not limited to such embodiments. It is clear that those skilled in the art can conceive of various modifications and alterations within the scope of the claims, and it is understood that such modifications and alterations also fall within the technical scope of the present invention.

[0113] Also provided are programs that cause a computer to function as the vehicle dispatch management server 60, and computer-readable storage media, such as flexible disks, magneto-optical disks, ROMs, CDs, DVDs, and BDs, on which the programs are recorded. Here, the program refers to data processing means written in any language or description method.

[0114] It should be noted that the processes shown in this specification do not necessarily have to be performed in chronological order according to the order shown in the flowcharts, and may include parallel or subroutine processes. [Explanation of symbols]

[0115] 1. Vehicle dispatch management system 2 users 3. Taxi Driver 4 NRS Driver 20 User terminal 30 Taxi terminal 32 Taxi vehicles 40 NRS terminals 42 NRS vehicles 50 Business Server 60 Vehicle dispatch management server (vehicle dispatch management device) 170 User terminal control unit 172 Dispatch Department 174 Vehicle terminal control unit 180 Vehicle Dispatch Request Department 182 Dispatch Response Unit 184 Dispatch Response Unit 186 Vehicle Management Department

Claims

1. A user terminal; a vehicle dispatch management device capable of communicating with the user terminal via a network; A vehicle dispatch management system comprising: The user terminal one or more first processors; The vehicle dispatch management device one or more second processors; The first processor: Transmitting a vehicle dispatch request to the vehicle dispatch management device, to which the boarding location and the disembarking location are added in accordance with the user's input; The second processor: deriving a travel value associated with the travel of the vehicle based on the boarding location and the disembarking location; Deriving a work condition regarding the remaining time of work in the vehicle; If the mileage value does not satisfy the working conditions, the vehicle is not allocated to the vehicle dispatch request. Vehicle dispatch management system.

2. A vehicle dispatch management device capable of communicating with a user terminal via a network, one or more processors; the processor: Deriving a travel value associated with the travel of the vehicle based on the boarding location and the disembarking location added to the dispatch request received from the user terminal; Deriving a work condition relating to the remaining time of work in the vehicle; If the mileage value does not satisfy the working conditions, the vehicle is not allocated to the vehicle dispatch request. Vehicle dispatch management device.

3. A vehicle dispatch management device capable of communicating with a user terminal via a network, one or more processors; the processor: Deriving a travel value associated with the travel of the vehicle based on the boarding location and the disembarking location added to the dispatch request received from the user terminal; Deriving work conditions relating to remaining work time for each of the plurality of vehicles; In response to the vehicle dispatch request, a vehicle whose mileage value satisfies the working conditions can be allocated, but a vehicle whose mileage value does not satisfy the working conditions is not allocated. Vehicle dispatch management device.

4. The processor: In response to the dispatch request, a vehicle whose mileage value satisfies the working conditions and a vehicle not having the working conditions can be allocated, but a vehicle whose mileage value does not satisfy the working conditions will not be allocated. The vehicle allocation management device according to claim 3.

5. A vehicle dispatch management device capable of communicating with a user terminal via a network, one or more processors; the processor: Deriving a travel value associated with the travel of the vehicle based on the boarding location and the disembarking location added to the dispatch request received from the user terminal; Deriving work conditions relating to remaining work time for each of the plurality of vehicles; In response to the dispatch request, a vehicle whose mileage value satisfies the working conditions is preferentially allocated over a vehicle whose mileage value does not satisfy the working conditions. Vehicle dispatch management device.

6. The processor: In response to the dispatch request, vehicles whose mileage values ​​satisfy the working conditions and vehicles to which the working conditions are not attached are preferentially allocated over vehicles whose mileage values ​​do not satisfy the working conditions. The vehicle allocation management device according to claim 5.

7. The travel time is a sum of a planned distance time to arrive at the boarding point and a planned travel time from the boarding point to the disembarking point, The vehicle dispatch management device according to claim 2 , wherein the working condition is that the remaining time of work is equal to or less than the remaining time of work.

8. The travel value is a total distance of an estimated arrival distance until arrival at the boarding point and an estimated riding distance from the boarding point to the disembarking point, The vehicle dispatch management device according to claim 2 , wherein the work condition is that the remaining time of work is equal to or less than a value calculated as a driving distance.

9. The computer Deriving a travel value associated with the travel of the vehicle based on the boarding location and the disembarking location added to the dispatch request received from the user terminal; Deriving a work condition relating to the remaining time of work in the vehicle; If the mileage value does not satisfy the working conditions, the vehicle is not allocated to the vehicle dispatch request. Vehicle allocation management method.

10. On the computer, Deriving a travel value associated with the travel of the vehicle based on the boarding location and the disembarking location added to the dispatch request received from the user terminal; Deriving a work condition relating to the remaining time of work in the vehicle; If the mileage value does not satisfy the working conditions, the vehicle is not allocated to the vehicle dispatch request. A program to make it happen.

Images