Vehicle allocation management system, vehicle allocation management device, vehicle allocation management method, and program

Abstract

To efficiently allocate vehicles.SOLUTION: A vehicle allocation management device (vehicle allocation management server) comprises: a vehicle allocation request storage section for storing a plurality of vehicle allocation requests received from a plurality of user terminals; a vehicle allocation request extraction section for extracting vehicle allocation requests, which are generated until predetermined execution timing in predetermined divided areas, from among the plurality of stored vehicle allocation requests; a vehicle extraction section for extracting vehicles satisfying any one of predetermined extraction conditions corresponding to the extracted vehicle allocation requests; a pair generation section 106 for extracting a pair candidate vehicle satisfying a predetermined pair condition from among the extracted vehicles for each extracted vehicle allocation request and making the pair candidate vehicle correspondent to the vehicle allocation request; a matching section for making matching between the vehicle allocation request and the pair candidate vehicle in such a manner that at least one pair candidate vehicle in each of the extracted vehicle allocation requests does not overlap a pair candidate vehicle of the other extracted vehicle allocation request; and a vehicle notification section for notifying a vehicle terminal, which is disposed in the matched pair candidate vehicle, of information indicating that the vehicle terminal is subjected to the vehicle allocation request.SELECTED DRAWING: Figure 1

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 Art

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

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] When allocating one taxi for a vehicle allocation request by one user, it may be considered to allocate a taxi with the shortest estimated arrival time to the boarding position desired by the user. However, when multiple users make vehicle allocation requests at different times, the taxi allocated to the first user may be located near other users who made vehicle allocation requests later, resulting in inefficient vehicle allocation. Moreover, as long as future vehicle allocation requests cannot be predicted, it is difficult to achieve optimal vehicle allocation for subsequent vehicle allocation requests at the timing when the first user makes a vehicle allocation request.

[0005] In view of such problems, an object of the present invention is to provide a vehicle allocation management system, a vehicle allocation management device, a vehicle allocation management method, and a program capable of efficient vehicle allocation.

Means for Solving the Problems

[0006] In order to solve the above problems, the vehicle allocation management system of the present invention includes a plurality of user terminals and a vehicle allocation management device that allocates vehicles in response to vehicle allocation requests from the user terminals. The user terminal includes a vehicle allocation request unit that transmits the vehicle allocation request to the vehicle allocation management device in response to user input. The vehicle allocation management device includes a vehicle allocation request storage unit that stores a plurality of the vehicle allocation requests received from the plurality of user terminals, a vehicle allocation request extraction unit that extracts the vehicle allocation requests that have occurred up to a predetermined execution timing in a predetermined division area from among the stored plurality of vehicle allocation requests, a vehicle extraction unit that extracts the vehicles that satisfy a predetermined extraction condition in the extracted vehicle allocation requests, a pair generation unit that extracts pair candidate vehicles that satisfy a predetermined pair condition from the extracted vehicles for each of the extracted vehicle allocation requests and associates the pair candidate vehicles with the vehicle allocation requests, a matching unit that matches the vehicle allocation requests and the pair candidate vehicles so that at least one of the pair candidate vehicles corresponding to the extracted vehicle allocation requests does not overlap with the pair candidate vehicles corresponding to the other extracted vehicle allocation requests, and designates one of the pair candidate vehicles corresponding to the vehicle allocation request as the vehicle to be allocated for the vehicle allocation request, and a vehicle notification unit that notifies the vehicle terminal arranged on the vehicle to be allocated for the vehicle allocation request of information indicating that it is the target of the vehicle allocation request.

[0007] In order to solve the above problems, the vehicle allocation management device of the present invention includes a vehicle allocation request storage unit that stores a plurality of vehicle allocation requests received from a plurality of user terminals, and from among the plurality of stored vehicle allocation requests, extracts the vehicle allocation requests that have occurred up to a predetermined execution timing in a predetermined division area, a vehicle extraction unit that extracts a vehicle that satisfies a predetermined extraction condition in the extracted vehicle allocation request, and for each of the extracted vehicle allocation requests, extracts a pair candidate vehicle that satisfies a predetermined pair condition from the extracted vehicles, and a pair generation unit that associates the pair candidate vehicle with the vehicle allocation request, and matches the vehicle allocation request and the pair candidate vehicle so that at least one of the pair candidate vehicles corresponding to the extracted vehicle allocation request does not overlap with the pair candidate vehicles corresponding to the other extracted vehicle allocation requests, and a matching unit that sets one of the pair candidate vehicles corresponding to the vehicle allocation request as the vehicle allocation vehicle that is the target of the vehicle allocation request, and a vehicle notification unit that notifies the vehicle terminal arranged on the vehicle allocation vehicle of information indicating that the vehicle allocation request has become the target.

[0008] The vehicle allocation management device may include a record holding unit that has a record in which the execution timing can be written using the division area as a key, and a work unit that exclusively executes batch processing in units of the division area and the execution timing by writing the execution timing to the record.

[0009] The vehicle allocation requests include a vehicle allocation request in a confirmed state in which the user has confirmed the vehicle allocation request, and an unconfirmed vehicle allocation request in which the vehicle allocation request is unconfirmed. The vehicle allocation request storage unit, the vehicle allocation request extraction unit, the vehicle extraction unit, the pair generation unit, and the matching unit execute respective processes on the unconfirmed vehicle allocation request, and the vehicle notification unit may notify the vehicle terminal of information indicating that the vehicle allocation request has become the target after the vehicle allocation request has shifted from the unconfirmed state to the confirmed state.

[0010] In order to solve the above problems, in the vehicle allocation management method of the present invention, one or more computers accumulate a plurality of vehicle allocation requests received from a plurality of user terminals, and from among the plurality of accumulated vehicle allocation requests, extract the vehicle allocation requests that occurred in a predetermined divided area by a predetermined execution timing, extract vehicles that satisfy a predetermined extraction condition in the extracted vehicle allocation requests, for each of the extracted vehicle allocation requests, extract pair candidate vehicles that satisfy a predetermined pair condition from the extracted vehicles, associate the pair candidate vehicles with the vehicle allocation requests, perform matching between the vehicle allocation requests and the pair candidate vehicles so that at least one of the pair candidate vehicles corresponding to the extracted vehicle allocation requests does not overlap with the pair candidate vehicles corresponding to the other extracted vehicle allocation requests, set one of the pair candidate vehicles corresponding to the vehicle allocation request as a vehicle allocation request vehicle that is the target of the vehicle allocation request, and notify the vehicle terminal arranged on the vehicle allocation request vehicle of information indicating that it has become the target of the vehicle allocation request.

[0011] In order to solve the above problems, the program of the present invention causes a computer to function as a vehicle allocation request accumulation unit that accumulates a plurality of vehicle allocation requests received from a plurality of user terminals, a vehicle allocation request extraction unit that extracts the vehicle allocation requests that occurred in a predetermined divided area by a predetermined execution timing from among the plurality of accumulated vehicle allocation requests, a vehicle extraction unit that extracts vehicles that satisfy a predetermined extraction condition in the extracted vehicle allocation requests, a pair generation unit that extracts pair candidate vehicles that satisfy a predetermined pair condition from the extracted vehicles for each of the extracted vehicle allocation requests and associates the pair candidate vehicles with the vehicle allocation requests, a matching unit that performs matching between the vehicle allocation requests and the pair candidate vehicles so that at least one of the pair candidate vehicles corresponding to the extracted vehicle allocation requests does not overlap with the pair candidate vehicles corresponding to the other extracted vehicle allocation requests, and sets one of the pair candidate vehicles corresponding to the vehicle allocation request as a vehicle allocation request vehicle that is the target of the vehicle allocation request, and a vehicle notification unit that notifies the vehicle terminal arranged on the vehicle allocation request vehicle of information indicating that it has become the target of the vehicle allocation request.

Advantages of the Invention

[0012] According to the present invention, efficient vehicle allocation becomes possible.

Brief Description of Drawings

[0013]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Embodiments for Carrying Out the Invention

[0014] Hereinafter, with reference to the accompanying drawings, preferred embodiments of the present invention will be described in detail. The dimensions, materials, and other specific numerical values shown in such embodiments are merely examples for facilitating the understanding of the invention, and do not limit the present invention unless otherwise specified. In the present specification and drawings, elements having substantially the same functions and configurations are denoted by the same reference numerals to omit redundant explanations, and elements not directly related to the present invention are not shown.

[0015] (Vehicle Allocation Management System 1) FIG. 1 is a block diagram for explaining the outline of the vehicle allocation management system 1. The vehicle allocation management system 1 includes a user terminal 10, a vehicle allocation management server 20, a vehicle 30, and a vehicle terminal 40.

[0016] The user terminal 10 is an electronic device owned by the user 2. Examples of the user terminal 10 include a smartphone, a personal computer, a tablet PC, etc. The user terminal 10 includes a display unit 12, an input unit 14, and a communication unit 16. There are a plurality of user terminals 10 according to the number of users 2. Note that the user 2 in the present embodiment is not limited to one person, and may indicate a plurality of persons who can board the vehicle 30.

[0017] The display unit 12 includes a liquid crystal display and an organic EL (Electro Luminescence), and displays various information such as an image of an application for making a vehicle allocation request. The input unit 14 includes a touch panel and a switch superimposed on the display unit 12, and receives the input of the user 2. The communication unit 16 establishes communication with the outside, for example, the vehicle allocation management server 20, through the base station 3 and the network network 4.

[0018] Further, the user terminal 10 has a semiconductor integrated circuit including a processor (CPU), a ROM storing programs, etc., and a RAM used as a work area. The processor of the user terminal 10 functions as a vehicle allocation request unit 18 described later by operating a program.

[0019] The vehicle allocation management server (vehicle allocation management device) 20 is an information processing device (computer) that manages a vehicle 30 for a user to board. For example, the vehicle allocation management server 20 establishes communication with the outside, such as a user terminal 10 or a vehicle terminal 40, through a network network 4 and a base station 3. The vehicle allocation management server 20 can allocate the vehicle 30 in response to a vehicle allocation request from the user terminal 10. In the present embodiment, when referring to the "vehicle 30", it may indicate not only the actual vehicle 30 but also an identifier capable of specifying the vehicle 30.

[0020] Note that the vehicle allocation management server 20 is composed of one or more information processing devices and can perform distributed processing or parallel processing. When the vehicle allocation management server 20 is composed of a plurality of information processing devices, the plurality of information processing devices may be connected to each other through the network network 4. Each information processing device has a semiconductor integrated circuit including one or more processors, a ROM storing programs, etc., and a RAM used as a work area, etc.

[0021] The processor functions as an instance (execution means) such as a functional unit or unit described later by operating a program. Note that one processor of one information processing device may function as a plurality of instances (multi-threading), a plurality of processors included in one information processing device may each function as an instance, or processors of a plurality of information processing devices may each function as an instance.

[0022] For example, the processor of the vehicle allocation management server 20 functions as a functional unit such as a vehicle allocation request accumulation unit 100, a vehicle allocation request extraction unit 102, a vehicle extraction unit 104, a pair generation unit 106, a matching unit 108, and a vehicle notification unit 110 described later by operating a program. Also, the RAM of the vehicle allocation management server 20 functions as a vehicle allocation storage unit 112 described later.

[0023] The vehicle 30 is, for example, a taxi or a hire car engaged in the business of transporting general passengers, and can transport the user 2. Here, taxis and hire cars are cited as examples of the vehicle 30 that is the subject of a ride request, but this is not the only case, and any vehicle capable of transporting people is sufficient. For example, the vehicle 30 can be a private car (ride share) or a motorcycle (bike taxi). Also, a vehicle terminal 40 is arranged in the vehicle 30. There are a plurality of vehicles 30 and vehicle terminals 40.

[0024] The vehicle terminal 40 is an electronic device provided to the driver of the vehicle 30 and is associated with the vehicle 30. Examples of the vehicle terminal 40 include a smartphone, a personal computer, a tablet PC, etc. The vehicle terminal 40 includes a display unit 42, an input unit 44, and a communication unit 46. Note that an electronic device provided integrally or separately in the vehicle 30 can also function as the vehicle terminal 40.

[0025] The display unit 42 includes a liquid crystal display and an organic EL, and displays various information such as that the own vehicle 30 has become the subject of a ride request (ride request notification) and information regarding the ride request (boarding desired position, user information regarding the user 2). The input unit 44 includes a touch panel and a switch superimposed on the display unit 42, and accepts the driver's input. The communication unit 46 establishes communication with the outside, for example, the ride management server 20, through the base station 3 and the network network 4. Here, matching indicates a process of exclusively associating an arbitrary ride request with an arbitrary vehicle 30 among a plurality of ride requests and a plurality of vehicles 30. In the following, an example of associating one vehicle 30 with one ride request will be described, but when allowing multiple users 2 to share a ride (so-called shared ride) in the vehicle 30, one vehicle 30 may be associated with multiple ride requests by multiple users 2.

[0026] In addition, the vehicle terminal 40 has a semiconductor integrated circuit including a processor, a ROM storing programs and the like, a RAM used as a work area, and the like. The processor of the vehicle terminal 40 functions as a vehicle allocation response unit 48, which will be described later, by operating a program.

[0027] In the vehicle allocation management system 1, for example, one vehicle 30 is allocated to a vehicle allocation request made by one user 2. However, when a plurality of users 2 make vehicle allocation requests at different times, the vehicle 30 allocated to the first user 2 may be located near other users 2 who made vehicle allocation requests later, resulting in inefficient vehicle allocation. Here, vehicle allocation requests generated within a predetermined period are accumulated, and efficient vehicle allocation is performed by matching a plurality of vehicle allocation requests and a plurality of vehicles 30 at once.

[0028] (Vehicle Allocation Management Method) FIG. 2 is a sequence diagram showing the processing flow of the vehicle allocation management method by the vehicle allocation management system 1. The vehicle allocation request unit 18 of the user terminal 10 transmits a vehicle allocation request to the vehicle allocation management server 20 in response to an input from the user 2 (S1). Next, the vehicle allocation request accumulation unit 100 of the vehicle allocation management server 20 accumulates a plurality of vehicle allocation requests received from a plurality of user terminals 10 (S2). Next, the vehicle allocation request extraction unit 102 of the vehicle allocation management server 20 extracts vehicle allocation requests that occurred within a predetermined divided area and up to a predetermined execution timing from among the accumulated plurality of vehicle allocation requests (S3). Next, the vehicle extraction unit 104 of the vehicle allocation management server 20 extracts vehicles that satisfy a predetermined extraction condition in the extracted vehicle allocation requests (S4). Next, the pair generation unit 106 of the vehicle allocation management server 20 extracts pair candidate vehicles that satisfy a predetermined pair condition from the extracted vehicles 30 for each of the extracted vehicle allocation requests, and associates the pair candidate vehicles with the vehicle allocation requests (S5). Next, the matching unit 108 of the vehicle allocation management server 20 performs matching between the vehicle allocation requests and the pair candidate vehicles, and sets one pair candidate vehicle corresponding to the vehicle allocation request as the vehicle to be allocated for the vehicle allocation request (S6).

[0029] When the matching between the vehicle allocation request and the candidate paired vehicles is completed and the vehicle for the vehicle allocation request is determined, the vehicle notification unit 110 of the vehicle allocation management server 20 notifies the vehicle terminal 40 arranged in the vehicle 30 that has become the vehicle for the vehicle allocation request of the information indicating that it is the target of the vehicle allocation request (S7). Next, the vehicle allocation response unit 48 of the vehicle terminal 40 transmits information regarding the acceptance of the vehicle allocation request to the vehicle allocation management server 20 according to the driver's input (S8). Next, the vehicle notification unit 110 of the vehicle allocation management server 20 notifies the vehicle terminal 40 and the user terminal 10 of the completion of the vehicle allocation (S9). In this way, in the vehicle allocation management system 1, one or a plurality of candidate paired vehicles that can be the target of the vehicle allocation request for each vehicle allocation request are extracted from a plurality of vehicles 30, and one vehicle for the vehicle allocation request is specified through matching. Then, when the vehicle 30 that has become the vehicle for the vehicle allocation request accepts the vehicle allocation request, the vehicle allocation is determined. The candidate paired vehicles and the vehicle for the vehicle allocation request both indicate the actual vehicle 30 or an identifier that can identify the vehicle 30. Hereinafter, each process will be described in detail. Here, it is assumed that the number of vehicles 30 is sufficient for the number of vehicle allocation requests.

[0030] (Vehicle Allocation Request Process S1) When the user 2 wishes to take a taxi, the user 2 makes a vehicle allocation request through the user terminal 10. Specifically, the vehicle allocation request unit 18 of the user terminal 10 operates an application for making a vehicle allocation request, and receives the vehicle allocation request of the user 2 through the input unit 14. At this time, the user 2 can set request parameters for the vehicle 30 that the user wishes to board. The vehicle allocation request unit 18 transmits a vehicle allocation request to the vehicle allocation management server 20 including the request parameters.

[0031] As request parameters, in addition to the initial setting of the desired vehicle allocation, for example, the desired boarding location, the business office, and the attributes are included. The desired boarding location indicates the location on the map where User 2 wishes to board Vehicle 30. User 2 can use the current location of User 2 as the desired boarding location as it is, or can set a desired location different from the current location as the desired boarding location. The business office indicates the business office to which Vehicle 30 belongs as a taxi business (passenger automobile transportation business). The attributes indicate the type and equipment of Vehicle 30. Examples of the attributes include whether Vehicle 30 is a high-class vehicle (so-called limousine), whether it can accommodate wheelchair passengers, whether it has a sliding door, etc. Note that the vehicle allocation request unit 18 prompts User 2 to input user information such as the number and clothing of User 2 in order to make it easier for the driver of Vehicle 30 to find User 2, and can include various information such as the user information input through the input unit 14 in the vehicle allocation request and transmit it to the vehicle allocation management server 20.

[0032] (Vehicle Allocation Request Accumulation Process S2) FIG. 3 is an explanatory diagram for explaining the processes of the vehicle allocation request accumulation unit 100 and the vehicle allocation request extraction unit 102. When the vehicle allocation request accumulation unit 100 of the vehicle allocation management server 20 receives a vehicle allocation request from the user terminal 10, it sequentially accumulates the received vehicle allocation request in the vehicle allocation storage unit 112. Specifically, when receiving a vehicle allocation request, the vehicle allocation request accumulation unit 100 identifies in which of a plurality of divided areas the desired boarding location in the request parameters is included. The divided areas indicate, for example, taxi business areas such as wards and cities. The same identifier (taxi business area ID) is assigned to vehicle allocation requests transmitted in the same divided area. As shown in FIG. 3, the vehicle allocation request accumulation unit 100 associates the received vehicle allocation request (request parameters) with the divided area and the reception time of the vehicle allocation request and accumulates them in the vehicle allocation storage unit 112.

[0033] (Vehicle Allocation Request Extraction Process S3) The vehicle allocation request extraction unit 102 of the vehicle allocation management server 20 extracts vehicle allocation requests that occurred up to a predetermined execution timing in a predetermined divided area from among a plurality of vehicle allocation requests stored in the vehicle allocation storage unit 112. Here, the execution timing indicates the timing at which the vehicle allocation request extraction process S3 is started for a plurality of vehicle allocation requests, and is represented by, for example, a time. The execution timing is repeatedly set periodically with a predetermined processing period in between. Therefore, the new current execution timing is set after the processing period from when the vehicle allocation request extraction process S3 was started at the previous execution timing. Here, the processing period is the length of time during which vehicle allocation requests to be processed at one time are accumulated, and is set to, for example, 5 seconds.

[0034] For example, assume that the previous execution timing was 0:00:00 (0 hours 0 minutes 0 seconds). At the current execution timing of 0:00:05, which is after the processing period from the previous execution timing, the vehicle allocation request extraction unit 102 extracts all vehicle allocation requests that are in the divided area A and whose reception times are indicated by times up to 0:00:05, as shown in FIG. 3. Note that the vehicle allocation requests up to the previous execution timing of 0:00:00 have already been extracted by the vehicle allocation request extraction process S3 at the previous execution timing of 0:00:00. Therefore, the vehicle allocation request extraction unit 102 substantially extracts the vehicle allocation requests accumulated during the processing period (5 seconds) from the previous execution timing of 0:00:00 to the current execution timing of 0:00:05.

[0035] However, in reality, in the matching started at the previous execution timing, the vehicle for the vehicle allocation request may not be determined. Such vehicle allocation requests for which the vehicle has not been determined are carried over to the current execution timing, and the matching continues. Therefore, the vehicle allocation request extraction unit 102 extracts, as the vehicle allocation requests accumulated by the current execution timing of 0:00:05, not only the vehicle allocation requests accumulated from the previous execution timing to the current execution timing, but also the vehicle allocation requests for which the vehicle has not been determined by the previous matching.

[0036] Here, an example is given in which the ride request extraction unit 102 extracts all ride requests that occurred up to a predetermined execution timing in a predetermined divided area. However, this is not limited to such a case, and among the ride requests that occurred up to a predetermined execution timing in a predetermined divided area, only those that satisfy a predetermined condition, for example, some ride requests whose request parameters are for high-class vehicles, may be extracted.

[0037] (Vehicle extraction process S4) The vehicle extraction unit 104 extracts vehicles 30 that satisfy a predetermined extraction condition in the ride requests extracted by the ride request extraction unit 102. Here, the extraction condition is, for example, a condition indicating that the estimated arrival time at the desired boarding position is short. Specifically, examples of the extraction condition include, for example, the distance to the desired boarding position being within a predetermined distance (for example, 10 km), or the estimated arrival time at the desired boarding position being within a predetermined time (for example, 10 minutes). Note that the distance in this case is the Euclidean distance between the desired boarding position and the position of the vehicle 30, and the estimated arrival time is the time obtained by dividing the Euclidean distance by a predetermined speed (average speed) determined in advance. Further, the vehicle extraction unit 104 may further limit the number of vehicles 30 to a predetermined number (for example, 10) in ascending order of the distance to the desired boarding position or the estimated arrival time at the desired boarding position.

[0038] FIG. 4 is an explanatory diagram for explaining the processing of the vehicle extraction unit 104. In FIG. 4, four sets of users 2a to 2d who made ride requests within the divided area A and eleven vehicles 30a to 30k existing within the divided area A are shown.

[0039] The vehicle extraction unit 104 sets extraction conditions for each of the ride requests extracted by the ride request extraction unit 102, that is, for each of the ride requests 120a to 120d of the users 2a to 2d. Here, as the extraction condition, it is adopted that the distance to the desired boarding position is within a predetermined distance. Therefore, for each of the ride requests 120a to 120d of the users 2a to 2d, extraction conditions 122a to 122d indicated by arcs in FIG. 4 are set.

[0040] The vehicle extraction unit 104 extracts vehicles 30 that satisfy the extraction conditions 122a to 122d for each of the vehicle allocation requests 120a to 120d of users 2a to 2d. For example, the vehicles 30 that satisfy the extraction condition 122a of the vehicle allocation request 120a of user 2a are vehicles 30a, 30b, 30c, 30d, and 30e. Also, the vehicles 30 that satisfy the extraction condition 122b of the vehicle allocation request 120b of user 2b are vehicles 30e, 30f, 30g, 30h, and 30i. Also, the vehicles 30 that satisfy the extraction condition 122c of the vehicle allocation request 120c of user 2c are vehicles 30d, 30e, 30f, 30h, and 30i. Also, the vehicles 30 that satisfy the extraction condition 122d of the vehicle allocation request 120d of user 2d are vehicles 30d, 30i, and 30j.

[0041] Here, the vehicle extraction unit 104 extracts all vehicles 30 that satisfy any of the extraction conditions 122a to 122d for each of the vehicle allocation requests 120a to 120d. Therefore, the vehicle extraction unit 104 extracts vehicles 30a to 30j. On the other hand, the vehicle extraction unit 104 excludes, as vehicles 30 with no possibility of allocation, a vehicle 30k that exists in the same divided area A but does not satisfy any of the extraction conditions 122a to 122d for the vehicle allocation requests 120a to 120d, for example, the vehicle 30k shown by the dashed line in FIG. 4. In this way, it becomes possible to reduce the processing load on the vehicle allocation management server 20.

[0042] Also, when the vehicle extraction unit 104 extracts vehicles 30 that satisfy the extraction condition 122, it may also extract the allowable parameters of the vehicles. The allowable parameters are parameters corresponding to the desired allocation, business office, and attributes included in the request parameters, and include vehicle status, business office, and attributes. Here, the vehicle status included in the allowable parameters corresponds to the desired allocation included in the request parameters and indicates information on the availability of allocation such as empty vehicle, pick-up, paid driving, payment, and return trip. Note that a vehicle 30 that becomes a vehicle for which a vehicle allocation request is made by the vehicle allocation management method and whose vehicle allocation request 120 is accepted (vehicle allocation is determined) has a vehicle status of pick-up and is treated as a vehicle 30 that is not available for other vehicle allocation requests 120. Also, the business office and attributes included in the allowable parameters are substantially equal to the business office and attributes included in the request parameters.

[0043] Here, the vehicle extraction unit 104 may exclude in advance vehicles 30 that do not meet the tolerance parameters with respect to the request parameters among the vehicles 30 that satisfy the extraction condition 122. For example, the vehicle extraction unit 104 determines whether the vehicle state included in the tolerance parameters of the vehicle 30 is an available empty vehicle for vehicle allocation, and if the vehicle state is a pick-up vehicle or a hired vehicle that cannot be allocated, it is excluded from the candidates for vehicle allocation.

[0044] Note that the vehicle state that can be a candidate for vehicle allocation is not limited to an empty vehicle, and if it is scheduled to be allocable after the current time, it can be allocated. For example, in addition to an empty vehicle, the vehicle extraction unit 104 may use a vehicle 30 whose vehicle state is a notice of an upcoming empty vehicle as a candidate for vehicle allocation. Such a notice of an upcoming empty vehicle indicates a vehicle state that will soon become an empty vehicle. For example, even when transporting user 2 or while user 2 is paying the fare, if the driver of vehicle 30 determines that they can receive a vehicle allocation request 120 as an empty vehicle after a predetermined time (e.g., 2 minutes), the vehicle state can be set as a notice of an upcoming empty vehicle through the input unit 44. Note that a vehicle 30 whose vehicle state is a notice of an upcoming empty vehicle becomes a vehicle for which a vehicle allocation request is made according to this vehicle allocation management method, and when its vehicle allocation request 120 is accepted (when vehicle allocation is confirmed), its vehicle state becomes a pick-up vehicle, and it is treated as a vehicle 30 that cannot be allocated to other vehicle allocation requests 120.

[0045] Also, when the business office is specified by the request parameters, the vehicle extraction unit 104 excludes vehicles 30 that do not belong to that business office. However, even if a vehicle 30 that satisfies the extraction condition 122 of any one of the multiple vehicle allocation requests 120 does not meet the request parameters of any one of the vehicle allocation requests 120, if it meets any of the request parameters of other vehicle allocation requests 120, the vehicle extraction unit 104 does not exclude that vehicle 30 from the vehicle allocation candidates. This is because even if a vehicle 30 has no possibility of becoming a vehicle for which a vehicle allocation request is made for any one of the vehicle allocation requests 120, it may still have the possibility of becoming a vehicle for which a vehicle allocation request is made for other vehicle allocation requests 120.

[0046] Here, as preprocessing for the pair generation process S5, the vehicle extraction unit 104 excludes vehicles 30 that cannot be candidate vehicles for vehicle allocation, for example, vehicle 30k whose distance from the desired boarding position is separated by a predetermined distance or more. Therefore, the vehicles 30 that should be processed by the pair generation unit 106 can be reduced in advance, and the processing load on the vehicle allocation management server 20 is reduced. However, at the stage of the vehicle extraction process S4, the vehicle extraction unit 104 does not determine whether the tolerance parameters conform to all items included in the request parameters. For example, among the vehicle allocation request, desired boarding position, business office, and attributes included in the request parameters, the attributes (type and equipment of the vehicle 30) are not determined. The vehicle extraction unit 104 only performs the minimum filtering for the purpose of reducing the processing load. In this way, the vehicle extraction unit 104 can extract vehicles 30a to 30j that satisfy any of the extraction conditions 122a to 122d corresponding to each of the extracted vehicle allocation requests 120a to 120d.

[0047] (Pair Generation Process S5) For each vehicle dispatch request 120 extracted by the vehicle dispatch request extraction unit 102, the pair generation unit 106 extracts candidate paired vehicles that meet a predetermined pair condition from the vehicles 30 extracted by the vehicle extraction unit 104, and associates the extracted candidate paired vehicles with the vehicle dispatch request 120. Here, the pair condition is that the allowable parameters of the vehicle 30 match all of the request parameters of the vehicle dispatch request 120. For example, when the attribute included in the request parameters of the vehicle dispatch request 120 corresponds to a sliding door, the pair generation unit 106 determines that it "matches" if the attribute included in the allowable parameters of the vehicle 30 has a sliding door. Also, the pair generation unit 106 determines that it "does not match" if the vehicle state included in the allowable parameters of the vehicle 30 is, for example, a vehicle that cannot pick up passengers or is on a paid trip. Here, once a vehicle 30 becomes a vehicle for a vehicle dispatch request 120 by the vehicle dispatch management method, it is highly likely to accept the vehicle dispatch request. Also, if it does not accept the vehicle dispatch request, it is highly likely to be in a state where it cannot currently receive a vehicle dispatch request. Therefore, for other vehicle dispatch requests 120, such a vehicle 30 is determined that the vehicle state included in the allowable parameters of the vehicle 30 "does not match", and is treated as a vehicle 30 that cannot be dispatched.

[0048] If even one of the allowable parameters of the vehicle 30 does not match the request parameters of the vehicle dispatch request 120, the pair generation unit 106 determines that the vehicle 30 does not meet the pair condition. On the other hand, if the allowable parameters of the vehicle 30 match all of the request parameters of the vehicle dispatch request 120, the pair generation unit 106 associates the vehicle 30 with the vehicle dispatch request 120 as a candidate paired vehicle that meets the pair condition of the vehicle dispatch request 120.

[0049] FIG. 5 and FIG. 6 are explanatory diagrams for explaining the processing of the pair generation unit 106. Here, it is assumed that, hypothetically, all the allowable parameters of the vehicles 30a to 30j extracted by the vehicle extraction unit 104 are compatible with the request parameters of the ride requests 120a to 120c of the users 2a to 2c. Also, for the attributes (for example, slide door compatibility) included in the request parameters of the ride request 120d of the user 2d, all the allowable parameters of the vehicles 30b, 30c, 30d, 30e, 30g, 30h, 30i extracted by the vehicle extraction unit 104 are compatible, but it is assumed that the allowable parameters of the vehicles 30a, 30f, 30j shown by the dashed lines in FIG. 5 are not compatible.

[0050] In the example of FIG. 5, for the ride request 120a of the user 2a, the pair generation unit 106 extracts the vehicles 30a to 30j that satisfy the pair conditions of the ride request 120a from the vehicles 30a to 30j extracted by the vehicle extraction unit 104 to obtain pair candidate vehicles 124a to 124j. Then, the pair generation unit 106 associates the pair candidate vehicles 124a to 124j with the ride request 120a of the user 2a. Similarly, the pair generation unit 106 associates the pair candidate vehicles 124a to 124j with the ride request 120b of the user 2b. Also, the pair generation unit 106 associates the pair candidate vehicles 124a to 124j with the ride request 120c of the user 2c. Further, for the ride request 120d of the user 2d, the pair generation unit 106 extracts the vehicles 30b, 30c, 30d, 30e, 30g, 30h, 30i that satisfy the pair conditions of the ride request 120d of the user 2d from the vehicles 30a to 30j extracted by the vehicle extraction unit 104 to obtain pair candidate vehicles 124b, 124c, 124d, 124e, 124g, 124h, 124i. Then, the pair generation unit 106 associates the pair candidate vehicles 124b, 124c, 124d, 124e, 124g, 124h, 124i with the ride request 120d of the user 2d. In this way, as shown in FIG. 6(a), for each of the ride requests 120a to 120d, one or more pair candidate vehicles 124 are associated.

[0051] Here, the pair generation unit 106 determines whether the allowable parameters of the vehicle 30 match all the request parameters of the ride request 120. However, not only in such a case, when the vehicle extraction unit 104 has already determined the compatibility for a part of the request parameters, for example, the desired pick-up and the business office, the pair generation unit 106 may omit the determination of the compatibility for those request parameters. Thus, the processing load on the ride management server 20 can be reduced.

[0052] Subsequently, for each of the ride requests 120a to 120d, the pair generation unit 106 estimates the estimated arrival time at the desired boarding position of the associated pair candidate vehicle 124 and associates it with each of the pair candidate vehicles 124. Since the positional relationship between the user 2 who made the ride request 120 and the vehicle 30 is different for each ride request 120, here, even for the same pair candidate vehicle 124, the estimated arrival time will be different for each ride request 120.

[0053] Subsequently, the pair generation unit 106 sets a priority for each of the pair candidate vehicles 124 associated with each ride request 120. Here, the priority indicates the order in which the vehicle should be the ride request vehicle, and it is assumed that the shorter the estimated arrival time at the desired boarding position, the higher the priority. Note that the estimated arrival time here is the travel time considering the route until the vehicle 30 arrives at the desired boarding position. Also, the pair generation unit 106 may derive the travel time considering, in addition to the route, the travel direction of the vehicle 30 at the time of extraction of the vehicle 30 and the stop time at traffic lights in the route. Therefore, the pair generation unit 106 can set the priority using a more accurate estimated arrival time than the estimated arrival time in the extraction condition 122 (Euclidean distance) used by the vehicle extraction unit 104.

[0054] For example, the pair generation unit 106 arranges the pair candidate vehicles 124a to 124j associated with the ride request 120a in the order of the shortest estimated arrival time at the boarding desired position as the pair candidate vehicles 124b, 124d, 124c, 124e, 124a, 124f, 124i, 124h, 124g, 124j. Similarly, the pair generation unit 106 arranges the pair candidate vehicles 124a to 124j associated with the ride request 120 of user 2b in the order of the shortest estimated arrival time at the boarding desired position as the pair candidate vehicles 124i, 124h, 124f, 124e, 124g, 124d, 124a, 124b, 124j, 124c. Further, the pair generation unit 106 arranges the pair candidate vehicles 124a to 124j associated with the ride request 120 of user 2c in the order of the shortest estimated arrival time at the boarding desired position as the pair candidate vehicles 124i, 124e, 124d, 124f, 124h, 124g, 124c, 124b, 124j, 124a. Also, the pair generation unit 106 arranges the pair candidate vehicles 124b, 124c, 124d, 124e, 124g, 124h, 124i associated with the ride request 120 of user 2d in the order of the shortest estimated arrival time at the boarding desired position as the pair candidate vehicles 124i, 124d, 124h, 124e, 124c, 124g, 124b.

[0055] In this way, as shown in FIG. 6(b), for each of the ride requests 120a to 120d, one or more pair candidate vehicles 124 are assigned priorities, and one or more combinations of the ride request 120 and the pair candidate vehicles 124 are generated. Here, it can be understood that the priorities of the pair candidate vehicles 124 corresponding to each of the ride requests 120a to 120d differ depending on the positional relationships among the users 2a to 2d and the pair candidate vehicles 124.

[0056] As described above, in FIG. 6(b), for each of the ride requests 120a to 120d, one or more pair candidate vehicles 124 are in a state where priorities are assigned, that is, they are associated in the order of the shortest estimated arrival time at the boarding desired position. Therefore, in the ride management server 20, for each of the ride requests 120a to 120d, by extracting the pair candidate vehicles 124 in the order of the highest priority, it is possible to assign the vehicle 30 with the shortest estimated arrival time.

[0057] Also, here, for each of the ride requests 120a to 120d, all the vehicles 30 that can be dispatched are associated and prioritized. This is because there may be a case where the vehicle 30 that has become the ride-request vehicle cannot accept the ride request. For example, assume that in a so-called "flowing" situation where the vehicle 30 accepts the ride request of user 2 found on the driving route, there is a ride request from user 2 near the driving route at the same time as the ride requests 120 of users 2a to 2d. Then, the vehicle 30 cannot accept the ride request 120 in order to pick up user 2 near the driving route. Therefore, even if the vehicle 30 that has become the ride-request vehicle cannot accept the ride request for some reason in the ride management server 20, by extracting the pair candidate vehicle 124 with the next highest priority, it is possible to efficiently assign the vehicle 30 with a short estimated arrival time to each of the ride requests 120a to 120d.

[0058] However, as surrounded by the dashed line in Fig. 6(b), among the ride requests 120a to 120d, there may be a case where the pair candidate vehicles 124 with the highest priority in the ride requests 120b, 120c, and 120d overlap. Then, in the ride management server 20, it becomes impossible to appropriately assign the pair candidate vehicle 124 as the ride-request vehicle to the ride requests 120b, 120c, and 120d. Therefore, the matching unit 108 performs matching between the ride request 120 and the pair candidate vehicle 124.

[0059] (Matching process S6) The matching unit 108 performs matching between the ride request 120 and the pair candidate vehicle 124 for a plurality of combinations of the ride request 120 and the pair candidate vehicle 124 associated by the pair generation unit 106, so that at least one pair candidate vehicle 124 in each ride request 120 does not overlap with the pair candidate vehicle 124 of other ride requests 120.

[0060] Figs. 7 to 9 are explanatory diagrams for explaining the processing of the matching unit 108. As shown in Fig. 7(a), one or a plurality of paired candidate vehicles 124 are associated with each of the vehicle dispatch requests 120a to 120d in a state where they are assigned priorities. Here, the matching unit 108 attempts to extract, for each of the vehicle dispatch requests 120a to 120d, the paired candidate vehicle 124 with the highest priority as the vehicle for the vehicle dispatch request. In this way, if the matching unit 108 extracts the paired candidate vehicle 124b for the vehicle dispatch request 120a, the paired candidate vehicle 124i for the vehicle dispatch request 120b, the paired candidate vehicle 124i for the vehicle dispatch request 120c, and the paired candidate vehicle 124i for the vehicle dispatch request 120d, it will be possible to assign the vehicle 30 with a short scheduled arrival time to each of the vehicle dispatch requests 120a to 120d.

[0061] Here, the paired candidate vehicle 124b of the vehicle dispatch request 120a does not overlap with the paired candidate vehicle 124i with the highest priority in the other vehicle dispatch requests 120b, 120c, and 120d. Therefore, the matching unit 108 may determine the paired candidate vehicle 124b of the vehicle dispatch request 120a as the vehicle for the vehicle dispatch request. However, in the vehicle dispatch requests 120b, 120c, and 120d, the paired candidate vehicles 124i with the highest priority respectively overlap. Even if the same paired candidate vehicle 124i is simultaneously assigned as the vehicle for the vehicle dispatch requests 120b, 120c, and 120d, the paired candidate vehicle 124i (vehicle 30i) cannot accept all of the vehicle dispatch requests 120b, 120c, and 120d simultaneously.

[0062] Therefore, the matching unit 108 performs an exclusive process of changing the combination of the vehicle allocation requests 120b, 120c, 120d and the paired candidate vehicles 124 so that the paired candidate vehicles 124 with the highest priority in each of the vehicle allocation requests 120b, 120c, 120d are different. Specifically, the matching unit 108 allocates the paired candidate vehicle 124i to one of the vehicle allocation requests 120b, 120c, 120d in which the paired candidate vehicle 124i overlaps. Then, for the other vehicle allocation requests 120, the matching unit 108 allocates the paired candidate vehicles 124 with their priorities lowered until there is no overlap between the other vehicle allocation requests 120 and the paired candidate vehicles 124.

[0063] For example, as shown in FIG. 7(b), the matching unit 108 allocates the paired candidate vehicle 124i to the vehicle allocation request 120b, allocates the paired candidate vehicle 124e with the next highest priority after the paired candidate vehicle 124i to the vehicle allocation request 120c, and allocates the paired candidate vehicle 124d with the next highest priority after the paired candidate vehicle 124i to the vehicle allocation request 120d. In this way, the combination in which the paired candidate vehicles 124b, 124i, 124e, 124d are allocated to the vehicle allocation requests 120a to 120d is defined as the pair group A. Similarly, as shown in FIG. 7(c), the matching unit 108 allocates the paired candidate vehicle 124i to the vehicle allocation request 120c, allocates the paired candidate vehicle 124h to the vehicle allocation request 120b, allocates the paired candidate vehicle 124d to the vehicle allocation request 120d, and generates a pair group B. Further, as shown in FIG. 7(d), the matching unit 108 allocates the paired candidate vehicle 124i to the vehicle allocation request 120d, allocates the paired candidate vehicle 124h to the vehicle allocation request 120b, allocates the paired candidate vehicle 124e to the vehicle allocation request 120c, and generates a pair group C. In this way, in each of the pair groups A, B, and C, it is possible to avoid the situation where the paired candidate vehicles 124 with the highest priority are repeatedly allocated to a plurality of vehicle allocation requests 120.

[0064] Note that here, in the ride requests 120b, 120c, and 120d, the candidate paired vehicles 124 with the second highest priority are different. However, depending on the positional relationship between the users 2b to 2d and the candidate paired vehicles 124, the candidate paired vehicles 124 with the second highest priority may also overlap. In this case as well, the matching unit 108 assigns the candidate paired vehicle 124 to one of the ride requests 120 for which the candidate paired vehicle 124 overlaps, and for the other ride requests 120, it may assign the candidate paired vehicle 124 with the priority lowered until the candidate paired vehicle 124 no longer overlaps with the other ride requests 120.

[0065] Next, the matching unit 108, for example, sums the estimated arrival times at the boarding desired positions of the vehicle 30 in all combinations of the ride requests 120 and the candidate paired vehicles 124 for each of the paired groups A, B, and C. Then, the matching unit 108 specifies, as the matching result, the paired group with the shortest total estimated arrival time as the combination of the ride request and the ride request vehicle. For example, in the paired groups A, B, and C, assume that the total estimated arrival times are in the relationship of paired group B < paired group A < paired group C. In this case, the matching unit 108 specifies the paired group B with the shortest total estimated arrival time as the matching result. When a paired group (for example, paired group B) is specified as the matching result by the matching of the matching unit 108, as shown in FIG. 8, the combination of the paired group B is reflected, the candidate paired vehicle 124b becomes the ride request vehicle for the ride request 120a, the candidate paired vehicle 124h becomes the ride request vehicle for the ride request 120b, the candidate paired vehicle 124i becomes the ride request vehicle for the ride request 120c, and the candidate paired vehicle 124d becomes the ride request vehicle for the ride request 120d.

[0066] In this way, by matching a plurality of ride requests and a plurality of vehicles 30 at once, it is possible to comprehensively judge the positional relationship between the position of the user 2 and the position of the vehicle 30 compared to the case of sequentially and individually matching the ride requests, enabling efficient vehicle dispatching.

[0067] Note that the matching algorithm for the ride request 120 and the paired candidate vehicle 124 is not limited to such a case. As long as at least one paired candidate vehicle 124 in each ride request 120, particularly the paired candidate vehicle 124 with the highest priority, does not overlap with the paired candidate vehicle 124 with the highest priority in other ride requests 120, various existing matching algorithms can be applied. For example, the matching unit 108 estimates the estimated arrival time at the boarding desired position of the vehicle 30 for all combinations of the ride request 120 and the paired candidate vehicle 124 for each of the plurality of pair groups A, B, and C. Then, the matching unit 108 may specify, as the matching result, the pair group that includes the combination of the ride request 120 and the paired candidate vehicle 124 with the shortest estimated arrival time among all the pair groups A, B, and C, where the estimated arrival time of the combination of the ride request 120 and the paired candidate vehicle 124 with the longest estimated arrival time in each pair group A, B, and C is the shortest. Further, the matching unit 108 may total the distances (travel distances) to the boarding desired positions of the vehicle 30 for all combinations of the ride request 120 and the paired candidate vehicle 124 for each of the pair groups A, B, and C. In this case, the matching unit 108 specifies the pair group with the shortest total distance as the matching result.

[0068] Note that even after the pair group B is specified as the matching result, the matching unit 108 maintains the priorities of the paired candidate vehicles 124 associated with the ride requests 120a to 120d. This is because, as described above, when the vehicle 30 that has become the ride request vehicle cannot accept the ride request for some reason, the paired candidate vehicle 124 with the next highest priority is extracted as the ride request vehicle.

[0069] However, when a pair group is specified and the pair candidate vehicle 124 with the highest priority is exclusively determined for the vehicle allocation requests 120a to 120d, the pair candidate vehicle 124 is deleted from other vehicle allocation requests 120. This is because the pair candidate vehicle 124 that has already become the vehicle for the vehicle allocation request of the vehicle allocation request 120 will not become the vehicle for other vehicle allocation requests 120. For example, the pair candidate vehicles 124b, 124h, 124i, and 124d that are matched with the vehicle allocation requests 120a to 120d are deleted from other vehicle allocation requests 120 as shown in FIG. 9(a). Thus, as shown in FIG. 9(b), a new combination is generated in which the pair candidate vehicles 124 are associated with the vehicle allocation requests 120a to 120d in descending order of priority.

[0070] Here, an example of performing matching is given such that the pair candidate vehicles 124 with the highest priority do not overlap among the vehicle allocation requests 120. Here, when the pair candidate vehicles 124 with the next highest priority overlap among the vehicle allocation requests 120, it may be possible not to perform matching for the pair candidate vehicles 124. This is for the following reasons. That is, the pair candidate vehicle 124 with the highest priority among the vehicle allocation requests 120 is assigned as the vehicle for the vehicle allocation request, but the pair candidate vehicle 124 with the next highest priority is only a backup in the case where the pair candidate vehicle 124 with the highest priority does not accept the vehicle allocation request 120. Nevertheless, there may be a case where efficient vehicle allocation does not result from exclusively associating the pair candidate vehicle 124 with the next highest priority.

[0071] For example, in the ride requests 120c and 120d of FIG. 9(b), in both cases, the pair candidate vehicle 124 with the next highest priority is the pair candidate vehicle 124e. Suppose the matching unit 108 performs matching between the ride requests 120c and 120d and the pair candidate vehicle 124e with the next highest priority. For example, for the ride request 120c, the pair candidate vehicle 124 with the next highest priority is set as the pair candidate vehicle 124e, and for the ride request 120d, the pair candidate vehicle 124 with the next highest priority is changed from the pair candidate vehicle 124e to the pair candidate vehicle 124c. Therefore, the pair candidate vehicles 124 for the ride request 120c are {124i, 124e, 124f,...} in descending order of priority, and the pair candidate vehicles 124 for the ride request 120d have the pair candidate vehicle 124e deleted and are {124d, 124c, 124g} in descending order of priority.

[0072] Here, for example, suppose that the pair candidate vehicle 124i with the highest priority for the ride request 120c accepts the ride request, and the pair candidate vehicle 124d with the highest priority for the ride request 120d does not accept the ride request. Then, for the ride request 120c, the pair candidate vehicle 124e with the next highest priority will not be the target of the ride request 120, and for the ride request 120d, the pair candidate vehicle 124c with the next highest priority will become the ride request vehicle. However, for the ride request 120d, originally, the pair candidate vehicle 124e with a higher priority than the pair candidate vehicle 124c should be the ride request vehicle.

[0073] Therefore, the matching unit 108 does not perform matching for pair candidate vehicles 124 other than the pair candidate vehicle 124 with the highest priority, and allows the pair candidate vehicles 124 to overlap between ride requests 120. In this way, even if the pair candidate vehicle 124 with the highest priority for the ride request 120 does not accept the ride request, it is possible to appropriately allocate the pair candidate vehicle 124 with the next highest priority.

[0074] In addition, if matching is not performed for pair candidate vehicles 124 other than the pair candidate vehicle 124 with the highest priority in this way, the pair candidate vehicles 124 may overlap as the vehicle for the ride request 120. For example, in the example of FIG. 9(b), if the pair candidate vehicle 124i that has been matched with the ride request 120c does not accept the ride request, and the pair candidate vehicle 124d that has been matched with the ride request 120d may also not accept the ride request. In this case, the pair candidate vehicle 124 with the next highest priority in the ride requests 120c and 120d will both be the pair candidate vehicle 124e.

[0075] However, the timing at which the pair candidate vehicle 124i rejects the acceptance of the ride request 120c should be different from the timing at which the pair candidate vehicle 124d rejects the acceptance of the ride request 120d. Here, in the ride management server 20, for the ride request 120 that has been rejected first, the pair candidate vehicle 124 with the next highest priority is set as the vehicle for the ride request, and that pair candidate vehicle 124 is deleted from other ride requests 120. For example, first, if the pair candidate vehicle 124i that has been matched with the ride request 120c does not accept the ride request, and then the pair candidate vehicle 124d that has been matched with the ride request 120d also does not accept the ride request, the ride management server 20 sets the pair candidate vehicle 124e as the vehicle for the ride request 120c that has been rejected first, and deletes the pair candidate vehicle 124e from the other ride request 120d. In this way, for example, the pair candidate vehicle 124e will not be the target for the ride request 120d, so the pair candidate vehicles 124 will not overlap as the vehicle for all ride requests 120.

[0076] In addition, the matching unit 108 may perform matching step by step with multiple conditions. For example, when there is a ride request reservation for the ride request 120, the matching unit 108 may preferentially identify the pair candidate vehicle 124 that can appropriately execute the ride request 120 with the ride request reservation, and for ride requests 120 other than those with the ride request reservation, for example, identify the pair group with the shortest total arrival scheduled time as the matching result.

[0077] Here, the vehicle dispatch request reservation is to reserve the vehicle dispatch request 120 of vehicle 30 by specifying the desired boarding location and the desired boarding time in advance. The user 2 can set the vehicle dispatch request reservation through the input unit 14 of the user terminal 10. The vehicle dispatch request unit 18 of the user terminal 10 transmits the vehicle dispatch request 120 including the vehicle dispatch request reservation to the vehicle dispatch management server 20. However, even if there is a vehicle dispatch request 120 including the vehicle dispatch request reservation from the user 2, the matching unit 108 of the vehicle dispatch management server 20 does not perform the vehicle dispatch of vehicle 30 yet when it receives the vehicle dispatch request reservation. Then, when it is a predetermined time (for example, 5 minutes) before the desired boarding time, the matching unit 108 starts the matching process together with the other vehicle dispatch requests 120 described above. In this way, by dispatching the nearby vehicle 30 immediately before the vehicle dispatch request reservation of the user 2, efficient vehicle dispatch can be achieved without the vehicle 30 wasting waiting time or traveling unnecessarily long distances.

[0078] Also, for example, when there is a priority vehicle dispatch for the vehicle dispatch request 120, the matching unit 108 may preferentially identify the candidate vehicle pairs 124 that can appropriately execute the vehicle dispatch request 120 with the priority vehicle dispatch, and for the vehicle dispatch requests 120 other than the vehicle dispatch request 120 with the priority vehicle dispatch, for example, identify the pair group with the shortest total scheduled arrival time as the matching result.

[0079] Here, the priority vehicle dispatch is to preferentially execute the vehicle dispatch for the vehicle dispatch request 120 of a specific user 2. Examples of the specific user 2 include those who need a taxi such as disabled people, elderly people, pregnant women, those who continuously use the application, and those who pay additional fees. The user 2 can set the priority vehicle dispatch through the input unit 14 of the user terminal 10. The vehicle dispatch request unit 18 of the user terminal 10 transmits the vehicle dispatch request 120 including the priority vehicle dispatch to the vehicle dispatch management server 20. When there is a priority vehicle dispatch for the vehicle dispatch request 120, the matching unit 108 not only performs the matching process preferentially over the other vehicle dispatch requests 120 described above, but also performs processes such as expanding the distance range of the extraction condition 122, and continuously executes the matching process until the vehicle dispatch is determined.

[0080] In addition, when a vehicle dispatch request reservation and a priority vehicle dispatch are set simultaneously, the matching unit 108 may match the vehicle dispatch request reservation preferentially over the priority vehicle dispatch. With such a configuration, it becomes possible to increase the probability of being able to dispatch a vehicle at the specified desired boarding time. Alternatively, when a vehicle dispatch request reservation and a priority vehicle dispatch are set simultaneously, the matching unit 108 may match the priority vehicle dispatch preferentially over the vehicle dispatch request reservation. With such a configuration, it becomes possible to dispatch a vehicle more preferentially to a person in need of a taxi.

[0081] Also, for example, when the time elapsed since user 2 made a vehicle dispatch request 120 has exceeded a predetermined time (e.g., 1 minute), the matching unit 108 preferentially identifies a pair candidate vehicle 124 that can appropriately execute the vehicle dispatch request 120, and for vehicle dispatch requests 120 other than the vehicle dispatch request 120, for example, may identify as the matching result a pair group with the shortest total arrival scheduled time. At this time, when there are multiple vehicle dispatch requests 120 for which the time elapsed since user 2 made a vehicle dispatch request 120 has exceeded the predetermined time, the matching unit 108 preferentially processes a vehicle dispatch request 120 with a longer elapsed time over a vehicle dispatch request 120 with a shorter elapsed time among those vehicle dispatch requests 120. However, the matching unit 108 preferentially performs the matching process for the above-described vehicle dispatch request reservation and priority vehicle dispatch over such vehicle dispatch requests for which the time elapsed since the user made a vehicle dispatch request has exceeded the predetermined time. In this way, it becomes possible to increase the probability of being able to dispatch a vehicle at the specified desired boarding time or to dispatch a vehicle more preferentially to a person in need of a taxi.

[0082] (Vehicle Dispatch Request Notification Process S7) The vehicle notification unit 110 of the vehicle dispatch management server 20 notifies the vehicle terminal 40 disposed in the vehicle 30 that has become the vehicle for the vehicle dispatch request of information indicating that the vehicle 30 is the target of the vehicle dispatch request 120. In this way, the driver of the vehicle 30 can recognize that his or her vehicle 30 has become the target of the vehicle dispatch request 120.

[0083] (Acceptance Response Process S8) When the vehicle response unit 48 of the vehicle terminal 40 arranged in the vehicle 30 receives information indicating that it has become the target of the vehicle dispatch request 120 from the vehicle notification unit 110, for example, it notifies the driver to that effect through the display unit 42. When the driver approves the vehicle dispatch request 120, the driver accepts the vehicle dispatch request 120 by tapping, for example, a position corresponding to "request approval" through the input unit 44 of the vehicle terminal 40. The vehicle response unit 48 of the vehicle terminal 40 transmits information regarding the approval of the vehicle dispatch request 120, including the approval of the vehicle dispatch request 120, to the vehicle management server 20.

[0084] If the driver cannot approve the vehicle dispatch request 120 for some reason, the driver does not input "request approval" to the input unit 44 of the vehicle terminal 40. If the vehicle notification unit 110 of the vehicle management server 20 waits for the elapse of a predetermined time (for example, 10 seconds) and cannot receive information regarding the approval of the vehicle dispatch request 120, the vehicle notification unit 110 sets the next highest priority pair candidate vehicle 124 among the pair candidate vehicles 124 associated with the vehicle dispatch request 120 as the vehicle for the vehicle dispatch request and notifies information indicating that it has become the target of the vehicle dispatch request 120.

[0085] (Vehicle dispatch completion notification process S9) When the vehicle notification unit 110 receives information regarding the approval of the vehicle dispatch request 120 from the vehicle terminal 40, it determines the vehicle dispatch, and transmits vehicle dispatch completion indicating the determination to the vehicle terminal 40. In addition, the vehicle notification unit 110 transmits the vehicle dispatch completion to the user terminal 10. At this time, information regarding the vehicle dispatch request 120, for example, the desired boarding position, the route to the desired boarding position, user information, etc. is shown on the display unit 42 of the vehicle terminal 40. With such a configuration, the driver of the vehicle 30 can grasp information regarding the vehicle dispatch request 120, quickly drive toward the desired boarding position, and can find the user 2 early.

[0086] In addition, on the display unit 12 of the user terminal 10, the position of the vehicle 30 that has become the vehicle requested for dispatch, the route to the boarding desired position, and the like are shown. In this way, the user 2 can appropriately board the vehicle 30 at the boarding desired position. Note that if the matching unit 108 is unable to assign a vehicle for dispatch to the dispatch request 120, the dispatch request 120 becomes impossible to dispatch. In this case, on the display unit 12 of the user terminal 10, information indicating that dispatch was impossible and information indicating that the dispatch request 120 can be executed again are displayed. The user 2 will execute the dispatch request 120 again based on such information.

[0087] Note that as described above, even when the same pair candidate vehicle 124 becomes a dispatch candidate for a plurality of different dispatch requests 120, the vehicle terminal 40 side avoids duplication of dispatch requests as follows. For example, when the same vehicle 30 becomes a pair candidate vehicle 124 for a plurality of different dispatch requests 120, the vehicle notification unit 110 designates the pair candidate vehicle 124 in one of the plurality of dispatch requests 120 as the vehicle for dispatch and notifies information indicating that it has become the target of the dispatch request 120. When the driver accepts the dispatch request, the vehicle notification unit 110 excludes the pair candidate vehicle 124 from the pair candidate vehicles 124 corresponding to the other dispatch requests 120. In this way, the vehicle 30 is not notified of information indicating that it has also become the target of other dispatch requests 120. Therefore, multiple dispatch request notifications are not made for the same vehicle 30 at the same timing. With such a configuration, it is possible to avoid the same vehicle 30 from becoming a dispatch vehicle for a plurality of different dispatch requests 120 in duplicate.

[0088] In addition, among a plurality of vehicle dispatch requests 120, the vehicle notification unit 110 notifies the vehicle terminal 40 of information indicating that one vehicle dispatch request 120 has been selected as the target. Even when the driver rejects the acceptance of the vehicle dispatch request 120, the vehicle notification unit 110 may exclude the paired candidate vehicle 124 from the candidates for other vehicle dispatch requests 120 and restrict it from becoming the paired candidate vehicle 124 for other vehicle dispatch requests 120 for a predetermined time (for example, 5 minutes). With such a configuration, it is possible to avoid the vehicle dispatch request 120 from being repeatedly notified even though the driver has rejected the vehicle dispatch notification.

[0089] In the vehicle dispatch management method by the vehicle dispatch management system 1 described above, information on a plurality of vehicle dispatch requests 120 and a plurality of vehicles 30 is accumulated and matched at once. Here, by making the accumulation time short, efficient vehicle dispatch becomes possible while maintaining convenience.

[0090] <Batch processing> FIG. 10 is a timing chart for explaining batch processing. As described above, when the vehicle dispatch request accumulation unit 100 receives a vehicle dispatch request 120 from the user terminal 10, it identifies a divided area based on the request parameters of the received vehicle dispatch request 120, associates the divided area and the reception time of the vehicle dispatch request 120 with the vehicle dispatch request 120, and accumulates them in the vehicle dispatch storage unit 112. Then, for example, when the execution timing (0:00:05) arrives, matching between a plurality of vehicle dispatch requests 120 accumulated up to the execution timing (0:00:05) in the divided area A and a plurality of vehicles 30 is executed. As described above, the vehicle dispatch requests accumulated up to the current execution timing include the vehicle dispatch requests 120 accumulated from the previous execution timing to the current execution timing and the vehicle dispatch requests 120 for which the dispatched vehicle has not been determined by the previous matching. Here, the matching between a plurality of vehicle dispatch requests 120 and a plurality of vehicles 30 is realized by the work unit in batch processing.

[0091] The work unit is an instance that, in terms of a divided area and an execution timing unit, performs the matching of a plurality of vehicle dispatch requests 120 and a plurality of vehicles 30, and uses a series of batch processes that notify the vehicle terminal 40 of the vehicle that has become the dispatched vehicle of the information indicating that it has become the target of the vehicle dispatch request 120 as a task. A plurality of work units are provided, and each functions independently of other work units, for example, as the vehicle dispatch request extraction unit 102, vehicle extraction unit 104, pair generation unit 106, matching unit 108, and vehicle notification unit 110 described above.

[0092] Therefore, even if a malfunction occurs in another work unit, the work unit will not be affected and can complete its own batch process. Also, here, all vehicle dispatch requests 120 are divided into batch processes in terms of a divided area and an execution timing unit, and are processed in parallel by a plurality of work units, so it is possible to avoid the processing load from concentrating on one processor. Also, even if the divided area increases, it can be handled by simply increasing the number of work units.

[0093] Here, assume that in the vehicle dispatch management server 20, one processor manages a plurality of work units as a management unit. In this case, the management unit extracts one work unit from which the batch process has not yet been executed from a plurality of work units at each of a plurality of execution timings for a plurality of divided areas, and assigns one batch process to that work unit.

[0094] However, in such a configuration, if the work unit fails to execute the batch process due to a malfunction, the management unit must detect that the work unit has not executed the batch process and further perform the process of assigning that batch process to another work unit. Then, there is a risk that a significant amount of time will be spent until the batch process is properly executed.

[0095] Further, if the management unit assigns batch processing with a batch size of 1 to a plurality of work units, a plurality of different matching results will occur, and there is a risk that the vehicle 30 cannot be appropriately dispatched. Also, if a problem occurs in the management unit itself, it becomes impossible to assign batch processing to the work unit, and the vehicle dispatching management system 1 will stop.

[0096] Therefore, in the present embodiment, the availability of the vehicle dispatching management system 1 is improved by adopting a configuration in which the work unit mainly executes batch processing.

[0097] FIG. 11 is an explanatory diagram for explaining the allocation mode of batch processing to the work unit. Here, the vehicle dispatching management server 20 includes a record holding unit 130 and a work unit 132. The record holding unit 130 is configured by, for example, Redis (REmote DIctionary Server), and has a record (storage area) that can write the execution timing using the divided area as a key. Redis is an open-source in-memory data store DB, which is a database that realizes high speed by deploying data in memory. The record of the record holding unit 130 is updated by the work unit 132 and serves as an index for controlling the execution timing of batch processing. The work unit 132 exclusively executes batch processing in units of the divided area and the execution timing by writing the execution timing into the record. Note that the work unit 132 may exclusively execute batch processing by other exclusive processes such as setting a flag corresponding to the record.

[0098] For example, in FIG. 11, the record holding unit 130 is provided with records each having a plurality of divided regions A, B, C, … as keys. Here, the record having the divided region A as the key will be described. When the execution timing 0:00:05 for the divided region A arrives, as shown in FIG. 11(a), the work unit 132 writes “0:00:05” as the execution timing to the record having the divided region A as the key. Here, it is assumed that, among the work units A, B, and C, the work unit A writes “0:00:05” as the execution timing to the record having the divided region A as the key. In response to writing the execution timing, the work unit A exclusively executes a batch process in units of the divided region A and the execution timing “0:00:05”.

[0099] In this way, when the work unit A writes “0:00:05” as the execution timing and updates the record, the record is locked, and the other work units B and C cannot update the record. Therefore, the other work units B and C cannot execute the batch process in units of the divided region A and the execution timing “0:00:05”. In other words, due to such a record locking mechanism, only one work unit (for example, the work unit A) that has written the execution timing among the work units A, B, and C can exclusively execute the batch process.

[0100] Such a lock continues until the next execution timing in the same divided region A and is automatically released immediately before the next execution timing arrives. For example, the work unit A that has written the record “0:00:05” in the divided region A sets “0:00:10” as the next execution timing to the record holding unit 130. In the record holding unit 130, the lock is released immediately before the set “0:00:10”, and as shown in FIG. 11(b), the execution timing is deleted from the record having the divided region A as the key.

[0101] When the following execution timing 0:00:10 for the division area A arrives, as shown in FIG. 11(b), on the condition that the execution timing is not written (the lock is released) in the record keyed by the division area A, using the SETNX (SET if Not eXists) instruction, a plurality of work units 132 attempt to access the record keyed by the division area A simultaneously. For example, assume that at that time, work units A, C, and E that are not executing batch processing attempt to access the record keyed by the division area A. Here, the work unit C that writes the execution timing "0:00:10" to the record earliest locks the record. Then, the other work units A and E cannot access the record and have to wait again for the lock of another record to be released. And only the work unit C that has locked the record can execute the batch processing specified by the record.

[0102] Here, the record holding unit 130 only holds the records updated by the work unit 132, and by adopting a configuration in which the work unit 132 mainly updates the records and executes batch processing, the availability of the vehicle allocation management system 1 can be improved. Also, even if the number of division areas increases, it is possible to cope by simply increasing the work unit 132. Therefore, for example, it is possible to perform parallel processing of a wide range of taxi business areas such as the whole of Japan simultaneously. Also, by configuring a plurality of work units 132 independently, rolling update becomes possible, and it is possible to update only some of the work units 132 while continuing the matching of a plurality of vehicle allocation requests 120 and a plurality of vehicles 30.

[0103] <Reduction of latency> FIG. 12 is a timing chart showing the flow of the vehicle allocation request 120. Here, it is assumed that within a predetermined division area, four groups of users 2a, 2b, 2c, and 2d each make vehicle allocation requests 120a, 120b, 120c, and 120d, and four vehicles 30 are allocated as the vehicles for the vehicle allocation requests.

[0104] User 2a starts an application on the user terminal 10 he owns and initiates the operation of the car-hailing request 120a. Then, when user 2a sets request parameters and the like and the car-hailing request 120a becomes in a confirmed state, the car-hailing request process S1 and the car-hailing request accumulation process S2 for the car-hailing request 120a are executed. Similarly, when the car-hailing requests 120b, 120c, 120d of users 2b, 2c, 2d become in confirmed states, the car-hailing request process S1 and the car-hailing request accumulation process S2 for the car-hailing requests 120b, 120c, 120d are executed. Then, for the car-hailing requests 120a, 120b, 120c, 120d, after the work unit 132 executes the car-hailing request extraction process S3, the vehicle extraction process S4, the pair generation process S5, and the matching process S6 at once, the car-hailing request notification process S7, the acceptance response process S8, and the car-hailing completion notification process S9 are executed for each of the car-hailing requests 120a, 120b, 120c, 120d.

[0105] In this way, for the car-hailing request process S1 and the car-hailing request accumulation process S2, the processing proceeds asynchronously and independently of other car-hailing requests 120 for each car-hailing request 120. However, for the car-hailing request extraction process S3, the vehicle extraction process S4, the pair generation process S5, and the matching process S6, since all the car-hailing requests 120 generated in terms of the divided area and the execution timing unit are required, they must be executed synchronously at once.

[0106] Then, for example, as shown in FIG. 12, there is no delay in the car-hailing for the car-hailing request 120d received immediately before the current execution timing, but a delay corresponding to the processing period may occur in the car-hailing for the car-hailing request 120a received immediately after the previous execution timing.

[0107] Therefore, here, when it can be determined that the probability of executing the car-hailing request 120 is high, the car-hailing request 120 and the vehicle 30 are pre-matched (hereinafter simply referred to as "pre-matching") without waiting for the confirmed state of the car-hailing request 120.

[0108] FIG. 13 is a timing chart showing the flow of the vehicle allocation request 120. Here too, as in FIG. 12, it is assumed that within a predetermined divided area, four groups of users 2a, 2b, 2c, and 2d each make vehicle allocation requests 120a, 120b, 120c, and 120d, and four vehicles 30 are allocated. FIG. 13(a) shows the case where pre-matching is not performed, and FIG. 13(b) shows the case where pre-matching is performed.

[0109] The vehicle allocation request 120 has a confirmed state in which the user 2 has confirmed the vehicle allocation request 120, and an unconfirmed state in which the vehicle allocation request 120 is unconfirmed before it becomes the confirmed state. However, even when the vehicle allocation request 120 is in the unconfirmed state, there are cases where the request parameters are determined and it is in a matchable state where matching can be performed.

[0110] For example, when the user 2 sets the request parameters through the user terminal 10, in order to make the vehicle allocation request 120, the user 2 performs an operation corresponding to an application through the input unit 14. However, there are cases where the content of the application is incorrect or different from the intended content. Therefore, after the application result is displayed on the display unit 12 of the user terminal 10, the user 2 can cancel the application within a predetermined time (for example, 5 seconds). In this case, when the user 2 performs an operation corresponding to the application, the vehicle allocation request 120 is in an unconfirmed state but in a matchable state, and the vehicle allocation request 120 becomes the confirmed state after a predetermined time has elapsed since the operation.

[0111] Here, as shown in FIG. 13(b), the vehicle allocation request unit 18 of the user terminal 10 transmits the unconfirmed vehicle allocation request 120 to the vehicle allocation management server 20 in response to the matchable state. Such processing corresponds to the vehicle allocation request process S1. Therefore, the unconfirmed vehicle allocation request 120 also includes the request parameters.

[0112] In the vehicle allocation management server 20, for each vehicle allocation request 120 in an undetermined state, a vehicle allocation request accumulation process S2 is executed. That is, the vehicle allocation request accumulation unit 100 sequentially accumulates the received vehicle allocation requests 120 in an undetermined state in the vehicle allocation storage unit 112. When the accumulation of the vehicle allocation requests 120 is completed in units of the divided area and the execution timing, and the execution timing arrives, the work unit 132 executes the vehicle allocation request extraction process S3, the vehicle extraction process S4, the pair generation process S5, and the matching process S6 all at once. Thus, it becomes possible to derive a matching result in advance based on the vehicle allocation requests 120 in an undetermined state.

[0113] Also, when a predetermined time has elapsed from the operation corresponding to the application and the vehicle allocation request 120 becomes a determined state, as shown in FIG. 13(b), the vehicle allocation request unit 18 of the user terminal 10 transmits the determined vehicle allocation request to the vehicle allocation management server 20 again. The vehicle notification unit 110 checks whether it has received the determined vehicle allocation request 120 from the user terminal 10 at intervals of several hundred msec. When the vehicle allocation request 120 shifts from the undetermined state to the determined state, the vehicle allocation request notification process S7 is immediately executed. Thereafter, the approval response process S8 and the vehicle allocation completion notification process S9 are executed.

[0114] Here, an example has been described in which the user terminal 10 transmits the vehicle allocation request 120 in an undetermined state to the vehicle allocation management server 20 in response to the matching-enabled state, and transmits the vehicle allocation request 120 in a determined state to the vehicle allocation management server 20 in response to the determination of the vehicle allocation request 120. However, it is not necessary to transmit again the information (for example, request parameters) that has already been transmitted to the vehicle allocation management server 20 by the vehicle allocation request 120 in an undetermined state as the vehicle allocation request 120 in a determined state. Therefore, the user terminal 10 may transmit the vehicle allocation request 120 in a determined state to the vehicle allocation management server 20 while omitting the information that overlaps with the vehicle allocation request 120 in an undetermined state in response to the determination of the vehicle allocation request 120.

[0115] As can be understood by comparing Fig. 13(a) without prior matching and Fig. 13(b) with prior matching, for example, for ride request 120a, the start of execution after ride request notification process S7 is advanced, and the waiting time until the ride is confirmed for vehicle 30 and user 2a is significantly shortened.

[0116] As described above, when prior matching is performed, after matching process S6 is completed, vehicle notification unit 110 waits for confirmed ride request 120 from user terminal 10. However, user 2 can also cancel the application, and there may be cases where the timing of receiving confirmed ride request 120 cannot be predicted. Thus, if confirmed ride request 120 is not received within a predetermined time (e.g., 10 seconds) after receiving unconfirmed ride request 120, vehicle allocation server 20 cancels the allocation of the ride request vehicle for unconfirmed ride request 120 in the matching process S6. Then, vehicle allocation server 20 targets the cancelled unconfirmed ride request 120 for matching again at the next execution timing in the same divided area. In this way, for the ride request 120, through new ride request extraction process S3, vehicle extraction process S4, pair generation process S5, and matching process S6, vehicle 30 is allocated again.

[0117] Note that vehicle 30 that has become a ride request vehicle due to unconfirmed ride request 120 is likely to accept the ride after receiving confirmed ride request 120, so it is treated as a vehicle 30 that is unavailable for other ride requests 120, and in vehicle extraction process S4, it is determined that the tolerance parameter does not "match" the request parameter.

[0118] As described above, the vehicle allocation management system 1 of the present invention includes a plurality of user terminals 10 and a vehicle allocation management device (for example, a vehicle allocation management server 20) that allocates a vehicle 30 in response to a vehicle allocation request 120 from the user terminal 10. The user terminal 10 includes a vehicle allocation request unit 18 that transmits a vehicle allocation request 120 to the vehicle allocation management device in response to an input from the user 2. The vehicle allocation management device includes a vehicle allocation request storage unit 100 that stores a plurality of vehicle allocation requests 120 received from a plurality of user terminals 10, a vehicle allocation request extraction unit 102 that extracts vehicle allocation requests 120 that have occurred by a predetermined execution timing in a predetermined division area from among the stored plurality of vehicle allocation requests 120, a vehicle extraction unit 104 that extracts a vehicle 30 that satisfies a predetermined extraction condition 122 in the extracted vehicle allocation request 120, a pair generation unit 106 that extracts a pair candidate vehicle 124 that satisfies a predetermined pair condition from the extracted vehicle 30 for each of the extracted vehicle allocation requests 120 and associates the pair candidate vehicle 124 with the vehicle allocation request 120, and a matching unit 108 that matches the vehicle allocation request 120 with the pair candidate vehicle 124 so that at least one pair candidate vehicle 124 corresponding to the extracted vehicle allocation request 120 does not overlap with the pair candidate vehicle 124 corresponding to another extracted vehicle allocation request 120, and sets one pair candidate vehicle 124 corresponding to the vehicle allocation request 120 as the vehicle to be allocated for the vehicle allocation request. The vehicle allocation management system 1 further includes a vehicle notification unit 110 that notifies the vehicle terminal 40 arranged on the vehicle to be allocated for the vehicle allocation request of information indicating that the vehicle allocation request 120 is the target. In such a vehicle allocation management system 1, information on a plurality of vehicle allocation requests 120 and a plurality of vehicles 30 is stored and matched at once. Here, by shortening the storage time, convenience can be maintained while enabling efficient vehicle allocation.

[0119] In addition, a vehicle allocation management device (for example, vehicle allocation management server 20) includes a vehicle allocation request storage unit 100 that stores a plurality of vehicle allocation requests 120 received from a plurality of user terminals 10, a vehicle allocation request extraction unit 102 that extracts vehicle allocation requests 120 that occurred in a predetermined divided area by a predetermined execution timing from among the stored plurality of vehicle allocation requests 120, a vehicle extraction unit 104 that extracts a vehicle 30 that satisfies a predetermined extraction condition in the extracted vehicle allocation request 120, a pair generation unit 106 that extracts a pair candidate vehicle 124 that satisfies a predetermined pair condition from the extracted vehicle 30 for each of the extracted vehicle allocation requests 120 and associates the pair candidate vehicle 124 with the vehicle allocation request 120, and a matching unit 108 that matches the vehicle allocation request 120 with the pair candidate vehicle 124 so that at least one pair candidate vehicle 124 corresponding to the extracted vehicle allocation request 120 does not overlap with the pair candidate vehicle 124 corresponding to another extracted vehicle allocation request 120, and sets one pair candidate vehicle 124 corresponding to the vehicle allocation request 120 as the vehicle to be allocated for the vehicle allocation request 120, and a vehicle notification unit 110 that notifies the vehicle terminal 40 arranged in the vehicle to be allocated for the vehicle allocation request 120 of information indicating that it is the target of the vehicle allocation request 120. In such a vehicle allocation management device, information on a plurality of vehicle allocation requests 120 and a plurality of vehicles 30 is stored and matched at once. Here, by shortening the storage time, convenience can be maintained while enabling efficient vehicle allocation.

[0120] The vehicle allocation management device may include a record holding unit 130 having a record in which the execution timing can be written using the divided area as a key, and a work unit 132 that exclusively executes batch processing in units of the divided area and the execution timing by writing the execution timing to the record.

[0121] With such a configuration, even if a problem occurs in another work unit 132, the work unit 132 will not be affected and can complete its own batch processing. Also, here, all dispatch requests 120 are divided into batch processing in units of divided regions and execution timings, and are processed in parallel by a plurality of work units 132, so it is possible to avoid the processing load from concentrating on one processor. Also, even if the number of divided regions increases, it can be dealt with simply by increasing the number of work units 132. Furthermore, the record holding unit 130 only holds the records updated by the work unit 132, and by adopting a configuration in which the work unit 132 mainly updates the records and executes batch processing, the availability of the vehicle dispatch management system 1 can be improved. Also, even if the number of divided regions increases, it is possible to deal with it simply by increasing the number of work units 132.

[0122] The dispatch requests 120 include dispatch requests 120 in a confirmed state where the user 2 has confirmed the dispatch request 120 and dispatch requests 120 in an unconfirmed state where the dispatch request 120 is unconfirmed. The dispatch request accumulation unit 100, the dispatch request extraction unit 102, the vehicle extraction unit 104, the pair generation unit 106, and the matching unit 108 execute their respective processes on the unconfirmed dispatch requests 120, and the vehicle notification unit 110 may notify the vehicle terminal 40 of information indicating that the vehicle is the target of the dispatch request 120 after the dispatch request 120 has shifted from the unconfirmed state to the confirmed state. With such a configuration, the start of execution after the dispatch request notification process S7 for the dispatch request 120 is advanced, and the waiting time until the vehicle dispatch is confirmed in the vehicle 30 and the user 2 is significantly shortened.

[0123] Also, in the vehicle allocation management method, one or more computers accumulate a plurality of vehicle allocation requests 120 received from a plurality of user terminals 10, and extract vehicle allocation requests 120 that occurred up to a predetermined execution timing in a predetermined division area from among the accumulated plurality of vehicle allocation requests 120. Then, the computers extract vehicles 30 that satisfy a predetermined extraction condition in the extracted vehicle allocation requests 120, and for each of the extracted vehicle allocation requests 120, extract paired candidate vehicles 124 that satisfy a predetermined pairing condition from the extracted vehicles 30. The paired candidate vehicles 124 are associated with the vehicle allocation requests 120, and the vehicle allocation requests 120 and the paired candidate vehicles 124 are matched so that at least one paired candidate vehicle 124 corresponding to an extracted vehicle allocation request 120 does not overlap with the paired candidate vehicles 124 corresponding to other extracted vehicle allocation requests 120. One paired candidate vehicle 124 corresponding to a vehicle allocation request 120 is set as a vehicle to be allocated for the vehicle allocation request, and information indicating that the vehicle allocation request 120 has been selected is notified to a vehicle terminal 40 arranged on the vehicle to be allocated. In such a vehicle allocation management method, information on a plurality of vehicle allocation requests 120 and a plurality of vehicles 30 is accumulated and matched at once. Here, by shortening the accumulation time, convenience can be maintained while enabling efficient vehicle allocation.

[0124] Further, the program causes the computer to function as a ride request storage unit 100 that stores a plurality of ride requests 120 received from a plurality of user terminals 10, a ride request extraction unit 102 that extracts, from among the stored plurality of ride requests 120, the ride requests 120 that have occurred up to a predetermined execution timing in a predetermined division area, a vehicle extraction unit 104 that extracts a vehicle 30 that satisfies a predetermined extraction condition in the extracted ride request 120, a pair generation unit 106 that, for each of the extracted ride requests 120, extracts a pair candidate vehicle 124 that satisfies a predetermined pair condition from the extracted vehicle 30 and associates the pair candidate vehicle 124 with the ride request 120, a matching unit 108 that matches the ride request 120 with the pair candidate vehicle 124 so that at least one pair candidate vehicle 124 corresponding to the extracted ride request 120 does not overlap with the pair candidate vehicle 124 corresponding to another extracted ride request 120, and designates one pair candidate vehicle 124 corresponding to the ride request 120 as the ride request vehicle that is the target of the ride request 120, and a vehicle notification unit 110 that notifies the vehicle terminal 40 arranged in the ride request vehicle of information indicating that the ride request 120 has become the target. In such a program, information on a plurality of ride requests 120 and a plurality of vehicles 30 is stored and matched at once. Here, by making the storage time short, convenience can be maintained while enabling efficient vehicle dispatching.

[0125] As described above, the preferred embodiments of the present invention have been described with reference to the accompanying drawings. Needless to say, the present invention is not limited to such embodiments. It is obvious that those skilled in the art can conceive of various modification examples or correction examples within the scope described in the claims, and it is naturally understood that those also belong to the technical scope of the present invention.

[0126] Also provided are a program that causes a computer to function as the above-described vehicle dispatching management server 20, and a computer-readable storage medium such as a flexible disk, a magneto-optical disk, a ROM, a CD, a DVD, a BD, etc. that records the program. Here, the program refers to data processing means described in any language and description method.

[0127] Note that each process shown in this specification does not necessarily need to be processed in time series in accordance with the order described in the flowchart, and may include parallel processing or processing by subroutines.

Explanation of Signs

[0128] 1 Vehicle Allocation Management System 2 User 10 User Terminal 18 Ride Request Section 20 Vehicle Allocation Management Server (Vehicle Allocation Management Device) 30 Vehicle 40 Vehicle Terminal 100 Ride Request Accumulation Section 102 Ride Request Extraction Section 104 Vehicle Extraction Section 106 Pair Generation Section 108 Matching Section 110 Vehicle Notification Section 112 Vehicle Allocation Memory Section 130 Record Holding Unit 132 Work Unit

Claims

1. A plurality of user terminals, A vehicle dispatch management device that dispatches vehicles in response to vehicle dispatch requests from the user terminals, A vehicle dispatch management system comprising: The user terminal includes: A vehicle dispatch request unit that transmits the vehicle dispatch request to the vehicle dispatch management device according to user input, The vehicle dispatch management device includes: A vehicle dispatch request storage unit that stores a plurality of the vehicle dispatch requests received from the plurality of user terminals, A vehicle dispatch request extraction unit that extracts the vehicle dispatch requests that occurred up to a predetermined execution timing in a predetermined division area from among the stored plurality of vehicle dispatch requests, A vehicle extraction unit that extracts the vehicles that satisfy a predetermined extraction condition in the extracted vehicle dispatch requests, For each of the extracted vehicle dispatch requests, a pair generation unit that extracts pair candidate vehicles that satisfy a predetermined pair condition from the extracted vehicles and associates the pair candidate vehicles with the vehicle dispatch requests, A matching unit that matches the vehicle dispatch requests and the pair candidate vehicles so that at least one of the pair candidate vehicles corresponding to the extracted vehicle dispatch requests does not overlap with the pair candidate vehicles corresponding to the other extracted vehicle dispatch requests, and sets one of the pair candidate vehicles corresponding to the vehicle dispatch request as the vehicle to be dispatched for the vehicle dispatch request, A vehicle notification unit that notifies the vehicle terminal arranged in the vehicle to be dispatched for the vehicle dispatch request of information indicating that it has become the target of the vehicle dispatch request, A vehicle dispatch management system comprising the above.

2. A vehicle dispatch request storage unit that stores a plurality of vehicle dispatch requests received from a plurality of user terminals, A vehicle dispatch request extraction unit that extracts the vehicle dispatch requests that occurred up to a predetermined execution timing in a predetermined division area from among the stored plurality of vehicle dispatch requests, A vehicle extraction unit that extracts the vehicles that satisfy a predetermined extraction condition in the extracted vehicle dispatch requests, For each of the extracted vehicle dispatch requests, a pair generation unit that extracts pair candidate vehicles that satisfy a predetermined pair condition from the extracted vehicles and associates the pair candidate vehicles with the vehicle dispatch requests, A matching unit that matches the vehicle dispatch requests and the pair candidate vehicles so that at least one of the pair candidate vehicles corresponding to the extracted vehicle dispatch requests does not overlap with the pair candidate vehicles corresponding to the other extracted vehicle dispatch requests, and sets one of the pair candidate vehicles corresponding to the vehicle dispatch request as the vehicle to be dispatched for the vehicle dispatch request, A vehicle notification unit that notifies the vehicle terminal arranged in the vehicle to be dispatched for the vehicle dispatch request of information indicating that it has become the target of the vehicle dispatch request, A vehicle dispatch management device comprising the above.

3. A record holding unit having a record in which the execution timing can be written using the division area as a key; A work unit that exclusively executes batch processing in units of the division area and the execution timing by writing the execution timing to the record; The vehicle allocation management device according to claim 2, comprising:

4. The vehicle allocation requests include a confirmed vehicle allocation request in which the user has confirmed the vehicle allocation request, and an unconfirmed vehicle allocation request in which the vehicle allocation request is unconfirmed. The vehicle allocation request storage unit, the vehicle allocation request extraction unit, the vehicle extraction unit, the pair generation unit, and the matching unit execute respective processes on the unconfirmed vehicle allocation requests. The vehicle notification unit notifies the vehicle terminal of information indicating that the vehicle allocation request has become the target after the vehicle allocation request has shifted from the unconfirmed state to the confirmed state. The vehicle allocation management device according to any one of claims 2 or 3.

5. One or more computers Accumulate a plurality of vehicle allocation requests received from a plurality of user terminals; Extract the vehicle allocation requests that have occurred up to a predetermined execution timing in a predetermined division area from among the accumulated plurality of vehicle allocation requests; Extract vehicles that satisfy a predetermined extraction condition in the extracted vehicle allocation requests; For each of the extracted vehicle allocation requests, extract pair candidate vehicles that satisfy a predetermined pair condition from the extracted vehicles, and associate the pair candidate vehicles with the vehicle allocation requests; Perform matching between the vehicle allocation requests and the pair candidate vehicles so that at least one of the pair candidate vehicles corresponding to the extracted vehicle allocation requests does not overlap with the pair candidate vehicles corresponding to the other extracted vehicle allocation requests, and set one of the pair candidate vehicles corresponding to the vehicle allocation request as the vehicle to be allocated for the vehicle allocation request; A vehicle allocation management method for notifying a vehicle terminal arranged in the vehicle to be allocated for the vehicle allocation request of information indicating that the vehicle allocation request has become the target.

6. A computer A vehicle allocation request storage unit that accumulates a plurality of vehicle allocation requests received from a plurality of user terminals; A vehicle allocation request extraction unit that extracts the vehicle allocation requests that have occurred up to a predetermined execution timing in a predetermined division area from among the accumulated plurality of vehicle allocation requests; A vehicle extraction unit that extracts vehicles that satisfy a predetermined extraction condition in the extracted vehicle allocation requests; For each of the extracted vehicle allocation requests, a pair generation unit that extracts pair candidate vehicles that satisfy a predetermined pair condition from the extracted vehicles and associates the pair candidate vehicles with the vehicle allocation request; A matching unit that matches the vehicle allocation request and the pair candidate vehicles so that at least one of the pair candidate vehicles corresponding to the extracted vehicle allocation request does not overlap with the pair candidate vehicles corresponding to the other extracted vehicle allocation requests, and sets one of the pair candidate vehicles corresponding to the vehicle allocation request as the vehicle allocation request vehicle that is the target of the vehicle allocation request; A vehicle notification unit that notifies the vehicle terminal arranged in the vehicle allocation request vehicle of information indicating that the vehicle has become the target of the vehicle allocation request; A program for causing the above to function.

Images